UNIVERSIDADE FEDERAL DE SANTA CATARINA José Cé Júnior U …

UNIVERSIDADE FEDERAL DE SANTA CATARINA PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA

COMPUTAÇÃO

José Cé Júnior

UMA ABORDAGEM SEMÂNTICA PARA ESPECIFICAÇÃO DE QOS DE SERVIÇOS DE COMUNICAÇÃO USANDO PARÂMETROS DE QOE

Dissertação submetida à Universidade Federal de Santa Catarina como parte dos requisitos para obtenção do grau de Mestre em Ciência da

Computação.

Prof. Roberto Willrich, Dr.

Florianópolis, maio de 2010.

UMA ABORDAGEM SEMÂNTICA PARA ESPECIFICAÇÃO DE QOS DE SERVIÇOS DE COMUNICAÇÃO USANDO PARÂMETROS DE QOE

José Cé Júnior Esta Dissertação foi julgada adequada para obtenção do título de

Mestre em Ciência da Computação, Área de concentração Sistemas de Computação e aprovada em sua forma final pelo Programa de Pós-Graduação em Ciência da Computação.

___________________________________ Prof. Mario Antonio Ribeiro Dantas, Dr.

Coordenador do Curso

Banca Examinadora

___________________________________ Prof. Roberto Willrich, Dr.

Orientador – UFSC

___________________________________ Prof. Renato Fileto, Dr.

UFSC

___________________________________ Prof. Frank Augusto Siqueira, Dr.

UFSC

___________________________________ Prof. José Leomar Todesco, Dr.

UFSC – EGC

iii

AGRADECIMENTOS Agradeço a todas as pessoas que se fizeram presentes, de corpo

ou alma, no entendimento desse trabalho. Agradecimento especial a minha família, esposa Madalena, mi-

nha filha Lavínia, meu filho Otávio e minha mãe por se prestar a ajudar-nos a cuidar dos bebês enquanto estudávamos. Foram inúmeros os mo-mentos, nesse tempo de dedicação ao trabalho do mestrado, entre outros as idas e vindas de Florianópolis, em que fiquei sem dar a atenção ne-cessária a essas pessoas tão especiais na minha vida.

Aos colegas, de mestrado Achilles pelas discussões das dúvidas e ao colega Fabian por estar sempre disponível para sanar algumas dúvi-das referentes à implementação.

Ao professor e orientador Roberto pela sua paciência, nas várias reuniões pessoais e via Skype, para me guiar nas várias idéias e dúvidas que iam surgindo ao longo do período; dedicação, disponibilidade e compreensão, além da sua competência nos ajustes e nas melhorias su-geridas a este trabalho.

A todos vocês o meu muito obrigado!

iv

SUMÁRIO

AGRADECIMENTOS .....................................................................................III L ISTA DE FIGURAS ......................................................................................VI L ISTA DE TABELAS ....................................................................................VII L ISTA DE ABREVIATURAS .........................................................................VIII RESUMO ....................................................................................................... X ABSTRACT ...................................................................................................XI 1. INTRODUÇÃO ..........................................................................................12

1.1 OBJETIVOS...........................................................................................15 1.2 JUSTIFICATIVA E MOTIVAÇÕES............................................................15 1.3 CONTRIBUIÇÃO DO TRABALHO ............................................................16 1.4 TRABALHOS RELACIONADOS...............................................................17 1.5 ESTRUTURA DA DISSERTAÇÃO.............................................................18

2. QOS E QOE .............................................................................................20 2.1 QOS NA REDE ......................................................................................20 2.1.1 APLICAÇÕES E SEUS REQUISITOS DE QOS..........................................20 2.1.2 PRINCIPAIS SOLUÇÕES DE QOS..........................................................21 2.1.3 NEGOCIAÇÃO E INVOCAÇÃO DE SERVIÇOS........................................22 2.2 QOE.....................................................................................................23 2.2.1 DEFINIÇÃO DE QOE...........................................................................24 2.3 MAPEAMENTO DE QOE EM QOS ..........................................................25 2.4 QOE E QOS EM VOIP ...........................................................................26 2.4.1 MOS.................................................................................................27 2.4.2 FATOR R............................................................................................28 2.4.3 OUTROS MÉTODOS OBJETIVOS DE QOE EM VOIP.............................29 2.5 QOE EM OUTRAS APLICAÇÕES..............................................................30 2.5.1 MAPEAMENTO DE QOE EM QOS EM VOIP ........................................30 2.6 CONSIDERAÇÕES SOBRE O CAPÍTULO...................................................32

3. NEGOCIAÇÃO DE QOS EM SERVIÇOS WEB ............................................33 3.1 SERVIÇOS WEB E A NEGOCIAÇÃO DE SERVIÇOS..................................33 3.1.1 COMPOSIÇÃO DE SERVIÇOS WEB ......................................................34 3.1.2 PUBLICAÇÃO, BUSCA E DESCOBERTA DE SERVIÇOS WEB.................34 3.1.3 NEGOCIAÇÃO DE SERVIÇOS WEB......................................................35 3.2 FUNCIONAMENTO DOS SERVIÇOS WEB ................................................35 3.3 SERVIÇOS WEB COM QOS....................................................................37 3.3.1 PROPOSTAS DE QOS EM SERVIÇOS WEB ...........................................37 3.3.2 LINGUAGENS DE ESPECIFICAÇÃO DE ACORDO DE NÍVEL DE SERVIÇO

..................................................................................................................38 3.3.3 DESCOBERTA E SELEÇÃO DE SERVIÇOS WEB COM QOS....................39 3.4 SERVIÇOS WEB SEMÂNTICOS...............................................................40

v

3.4.1 ONTOLOGIA ......................................................................................41 3.4.2 LINGUAGENS PARA ESPECIFICAÇÃO DE METADADOS.......................43 3.4.3 LINGUAGENS PARA CRIAÇÃO DE ONTOLOGIAS.................................44 3.4.3.1 LINGUAGENS BASEADAS EM LÓGICA DE PRIMEIRA ORDEM ..........44 3.4.3.2 LINGUAGENS BASEADAS EM HTML E XML PARA APLICAÇÕES DA

WEB SEMÂNTICA .......................................................................................46 3.4.4 ONTOLOGIAS PARA DESCRIÇÃO DE SERVIÇOS WEB SEMÂNTICOS....51 3.4.4.1 OWL –S ........................................................................................51 3.4.5 ONTOLOGIAS DE QOS PARA SERVIÇOS WEB SEMÂNTICOS ...............51 3.4.6 LINGUAGEM BASEADA EM REGRAS - SWRL .....................................52 3.5 CONSIDERAÇÕES SOBRE O CAPÍTULO ..................................................53

4. NETQOSONT ..........................................................................................55 4.1 MÓDULOS DA ONTOLOGIA...................................................................55 4.1.1 MÓDULO BASE .................................................................................56 4.1.2 MÓDULO DA CAMADA DE ENLACE ...................................................56 4.1.3 MÓDULO DA CAMADA INTERNET.....................................................56 4.1.4 MÓDULO DA CAMADA DE TRANSPORTE...........................................57 4.1.5 MÓDULOS DA CAMADA DE APLICAÇÃO E USUÁRIO .........................57 4.1.6 EQUIVALÊNCIAS ENTRE QOSSPEC....................................................57 4.2 CENÁRIO DE USO.................................................................................58 4.3 ANÁLISE DA NETQOSONT QUANTO AO MAPEAMENTO DE QOE EM QOS..................................................................................................................59 4.4 CONSIDERAÇÕES SOBRE O CAPÍTULO ..................................................60

5. ESTENDENDO A NETQOSONT COM REGRAS DE M APEAMENTO ..........61 5.1 NOVOS CONCEITOS E INDIVÍDUOS........................................................61 5.1.1 MÓDULO DA CAMADA DE USUÁRIO..................................................61 5.1.2 MÓDULO DA CAMADA DE APLICAÇÃO..............................................62 5.1.3 MÓDULO DA CAMADA INTERNET......................................................63 5.1.4 MAPEAMENTO DE QOS/QOE ............................................................63 5.2 CENÁRIO ILUSTRATIVO E DE TESTE.....................................................68 5.2.1 ONTOLOGIAS UTILIZADAS.................................................................68 5.2.2 ESPECIFICANDO A QUALIDADE DESEJADA.........................................70 5.2.3 TRATAMENTO DA SOLICITAÇÃO DO USUÁRIO ..................................71 5.3 CONSIDERAÇÕES SOBRE O CAPÍTULO ..................................................75

6. CONCLUSÕES E TRABALHOS FUTUROS..................................................76 7. REFERÊNCIAS BIBLIOGRÁFICAS ............................................................78

vi

L ISTA DE FIGURAS

FIGURA 1. ETAPAS PARA A GARANTIA DE QOE.........................................25 FIGURA 2. TECNOLOGIAS UTILIZADAS NA DESCRIÇÃO DOS SERVIÇOS WEB. FONTE: [69]. ................................................................................................36 FIGURA 3. DESCOBERTA DOS SERVIÇOS WEB COM QOS. FONTE: [83]. ......40 FIGURA 4. EVOLUÇÃO DAS TECNOLOGIAS WEB. FONTE: [86]...................42 FIGURA 5. MÓDULOS DA NETQOSONT. FONTE: [13]................................55 FIGURA 6. EQUIVALÊNCIA ENTRE QOSSPECS. FONTE: [13].......................58 FIGURA 7. ONTOLOGIA DE ESPECIFICAÇÃO DE QOE.................................63 FIGURA 8. REGRA DE MAPEAMENTO EM MOS-MAPPING. ........................67 FIGURA 9. CENÁRIO ILUSTRATIVO............................................................68 FIGURA 10. ONTOLOGIA NSPQOSONT.......................................................69 FIGURA 11. ESPECIFICAÇÃO DE QOS SOLICITADA . .....................................70 FIGURA 12. INTERFACE DO APLICATIVO DE ESPECIFICAÇÃO DE QOE.........71 FIGURA 13. INTERFACE DO APLICATIVO DE IMPORTAÇÃO DE QOE. ...........72 FIGURA 14. INDIVÍDUOS GERADOS E RESULTADO DA INFERÊNCIA. .............74

vii

L ISTA DE TABELAS

TABELA 1. REQUISITOS DE QOS DAS APLICAÇÕES. FONTE: [24]...............21 TABELA 2. RELAÇÃO CODEC MOS. FONTE: [51]. ...................................28 TABELA 3. CATEGORIA DE TRANSMISSÃO DA FALA. FONTE: [53]..............29 TABELA 4. PARÂMETROS QOE X PARÂMETROS DE QOS BASEADO EM [61]... ................................................................................................31

viii

L ISTA DE ABREVIATURAS

ADPCM Adaptative Differential PCM API Application Programming Interface BE Best-Effort COBOL COmmon Business Oriented Language CODEC Compression and Decompression Components CoS Class of Service CS-ACELP Algebraic-ACELP CSS Cascading Style Sheets DARPA Defense Advanced Research Project Agency DiffServ Differentiated Services DTD Document Type Definition F-logic Frame Logic HTTP HyperText Transfer Protocol HTTPS HyperText Transfer Protocol Secure IDL Interface Description Language IETF Internet Engineering Task Force IntServ Integrated Services IP Internet Protocol IPDV IP Packet Delay Variation IPTV Internet Protocol Television ISI Information Sciences Institute ITU-T International Telecommunication Union KMI Knowledge Media Institute KSL Knowledge Systems Laboratory LD-CELP Low-Delay, Code-Excited Linear Prediction Mbps Megabits por segundo MG-CP Media Gateway Control Protocol MOS Mean Opinion Score MPLS Multiprotocol Label Switching MSE Mean Square Error NSP Network Service Provider OCML Operational Conceptual Modelling Language OIL Ontology Inference Layer OKBC Open Knowledge Base Connectivity OLM Ontology Markup Language ORB Object Request Brokers OWD One Way Delay OWL Web Ontology Language OWL-S Semantic Markup for Serviços Web

ix

PAMS Perceptual Analysis Measurement System PCM Pulse Code Modulation PESQ Perceptual Evaluation of Speech Quality PLR Packet Loss Rate PSNR Peak Signal to Noise Ratio PSQM Perceptual Speech Quality Measurements PSTN Public Switched Telephone Network PT Payload Type QC Quality Class QML QOS Modelling Language QoE Quality of Experience QoEBiz Quality of Business QoS Quality of Service RDF MSS Model and Syntax Specification RDF Resource Definition Framework RSVP Resource Reservation Protocol RTCP Real Time Control Protocol RTP Real Time Protocol SHOE Simple HTML Ontology Extensions SIP Session Initiation Protocol SLA Service Level Agreement SLS Service Level Specification SOAP Simple Object Access Protocol SWRL Semantic Web Rule Language SWS Web Service Semânticos UDDI Universal Description, Discovery and Integration URI Uniform Resource Identifier VoIP Voice over Internet Protocol VQM Video Quality Metric Web World Wide Web WS Web Service WSB Web Service Broker WSDL Serviços Web Description Language WSLA Serviços Web Level Agreement WSML Serviços Web Modeling Language WSOL Web Service Offering Language XML eXtensible Markup Language XMPP Extensible Messaging and Presence Protocol XOL Ontology Exchange Language XSLT Web Service Modeling Language

x

RESUMO Em diversas operações relacionadas ao gerenciamento com Qua-

lidade de Serviço (QoS), é necessário especificar os níveis de qualidade através de parâmetros de QoS. A maioria dos trabalhos sobre gerencia-mento de QoS adota um conjunto fixo de parâmetros de QoS no nível de rede. Em muitas situações onde os seres humanos são as aplica-ções/serviços finais, idealmente, a qualidade dos serviços de rede deve ser especificada usando parâmetros de Qualidade de Experiência (QoE). No entanto, a adoção de parâmetros de QoE para especificar a QoS da rede exige mecanismos eficientes no mapeamento de QoE em parâme-tros de QoS da rede. Este trabalho propõe um mapeamento de QoS e QoE utilizando uma abordagem de base ontológica que pode ser utiliza-do durante várias operações relacionadas com o gerenciamento de QoS. O uso da proposta é ilustrada para suportar um serviço de negociação VoIP.

xi

ABSTRACT In various operations related to Quality of Service (QoS)

management is necessary to specify the levels of quality through QoS parameters. Most of the works on QoS management adopt a fixed set of QoS parameters at the network level. In many situations where humans are the applications/services end-users, ideally the quality of network services should be specified using Quality of Experience (QoE) parameters. However, the adoption of QoE parameters to specify the network QoS requires efficient mechanisms on QoE mapping into network QoS parameters. This paper proposes a QoE and QoS mapping using an Ontology based approach that can be used during various operations related with QoS management. The use of our proposal is illustrated to support a Voice over IP service negotiation.

12

1. INTRODUÇÃO Atualmente, a maior parte das redes instaladas oferece serviços

de transporte do tipo melhor esforço (Best–Effort), onde não existe ne-nhuma garantia sobre a qualidade da transferência de dados. Neste tipo de serviço, os pacotes de dados transmitidos podem ser perdidos, en-frentar atrasos não esperados, apresentar variações sensíveis no atraso, além de não contarem com uma taxa de bits mínima garantida. O servi-ço de comunicação do tipo melhor esforço pode ser suficiente para vá-rias aplicações, como transferência de arquivos, navegação Web e cor-reio eletrônico. Entretanto, várias outras aplicações simplesmente não podem operar adequadamente em tal ambiente. Aplicações de tempo-real, como videoconferência, tele-medicina e ensino a distância, por exemplo, necessitam de certas garantias dos serviços de rede que não são fornecidas pelo serviço de melhor esforço.

O avanço das tecnologias das redes de alta velocidade favorece o surgimento de novos serviços e aplicações que por sua vez exigem cada vez mais recursos de rede para seu funcionamento adequado. O atendi-mento a estes requisitos pode ser alcançado pela implantação de meca-nismos de gerenciamento da Qualidade de Serviço (QoS). Existem al-gumas soluções para o gerenciamento da QoS, sendo que a arquitetura de Serviços Diferenciados (DiffServ) [1] é uma das mais populares.

O ITU-T [2] define a QoS para os serviços de rede como o efeito combinado do desempenho do serviço que determina o grau de satisfa-ção do usuário de um serviço. Em geral, medições e a própria QoS são, geralmente, definidas em termos de parâmetros de desempenho de rede, não em termos de satisfação para o usuário final.

O gerenciamento de QoS em redes de computadores é importante para que os serviços disponibilizados possuam algum nível de garantia de qualidade, de modo que possam ser adequadamente caracterizados e conhecidos pelos usuários. O interesse da comunidade científica pelo tema QoS foi reforçado à medida que as redes IP passaram a ser utiliza-das também como meio de transporte de dados com requisitos temporais críticos.

As principais arquiteturas de fornecimento de QoS foram desen-volvidas dentro do IETF (Internet Engineering Task Force). A arquite-tura IntServ (Integrated Services) [3] utiliza o protocolo de sinalização RSVP (Resource Reservation Protocol) capaz de reservar recursos ao longo do caminho de um fluxo. A arquitetura DiffServ (Differentiated Services) [3] procura fornecer QoS através da priorização e tratamento especial de fluxos agregados, enquanto que o protocolo MPLS (Multi-

13

protocol Label Switching) [4] identifica rotas inteiras que devem ser utilizadas.

Durante a subscrição do serviço, Cliente e NSP (Network Service Provider) assinam um contrato contendo Acordos de Nível de Serviços (SLA – Service Level Agreement), formalizando os termos e as circuns-tâncias do oferecimento do serviço. Um SLA contém uma lista de Acor-dos do Nível de Serviço (SLSs – Service Level Agreements) que permite especificar a QoS do tráfego considerado essencial para o cliente. Após a contratação do serviço, os usuários podem invocar/usar os serviços. Existem dois tipos de invocação de serviços [5] rever: invocação implí-cita, onde o tráfego receberá o nível de QoS definido estaticamente em algum SLS; invocação explícita, onde o usuário pode solicitar a QoS para uma sessão de comunicação em particular. As soluções atuais de negociação e invocação explícita de serviços com QoS adotam métricas de desempenho ao nível IP, como atraso (OWD – One Way Delay), variação de atraso (IPDV – IP Packet Delay Variation) e taxa de perdas de pacotes (PLR – Packet Loss Rate).

Diversos trabalhos demonstram que a experiência do usuário é mais importante do que qualquer mecanismo técnico utilizado no interi-or da rede ([6], [7], [8]). A experiência do usuário pode ser qualificada em termos de parâmetros de QoE (Quality of Experience) que é a quali-dade percebida de maneira subjetiva pelo usuário. [9] define QoE como sendo a aceitabilidade de uma aplicação ou serviço, como percebida de forma subjetiva pelo usuário final. A QoE é influenciada por todos os componentes envolvidos na comunicação fim a fim, incluindo o próprio usuário, o terminal, a rede e a infra-estrutura do serviço. Além disso, esta aceitabilidade pode ser influenciada pelas expectativas do usuário e pelo contexto. É por isso que a QoE é medida normalmente de modo subjetivo pelo usuário. Mesmo sendo subjetiva, a qualidade de experi-ência deve ser tratada. Por exemplo, o gerenciamento dos recursos das redes de computadores poderia ser mais eficiente se fosse levada em conta a alocação dos recursos definidos pelos usuários. Um exemplo de parâmetro de QoE é o MOS (Mean Opinion Score) [10], que pode ser usado para medir a qualidade de voz em aplicações de Voz sobre IP (VoIP).

Em muitas situações, expressar a QoS por meio de parâmetros de rede não é natural para um cliente ou usuário do serviço de rede. Pois, muitas vezes eles não conhecem o efeito de um parâmetro de QoS con-figurado na camada de rede para expressar a qualidade da aplicação. Portanto, em aplicações/serviços aonde o usuário final seja um humano (por exemplo, aplicações de VoIP e videoconferências), o nível do ser-

14

viço prestado pode ser especificado utilizando parâmetros de QoE. Por exemplo, se um usuário negocia um nível de serviço para VoIP, seria mais simples e compreensível negociar a qualidade em termos de MOS do que parâmetros de rede do tipo atraso, variação de atraso e taxa de perdas de pacote.

O problema gerado pela flexibilidade em termos de parâmetros de qualidade para especificar a QoS é o mapeamento dos parâmetros de mais alto nível, em parâmetros de qualidade tratados e controlados pelo provedor. Até mesmo o mapeamento em termos de unidades e métricas utilizadas pode ser necessário (p.e., segundo em milissegundo, bytes por segundo em bits por segundo). Por exemplo, caso o usuário utilize pa-râmetros de QoE para especificar a qualidade, o provedor deve reconhe-cer este parâmetro e mapear em garantias de qualidade ao nível de rede. E, no caso de soluções baseadas em Classes de Serviço (CoS), é neces-sário identificar a qual classe de serviço o tráfego pertence. O mesmo problema de mapeamento pode ocorrer durante o processo de negocia-ção entre NSPs.

Na área de Serviços Web, o problema de heterogeneidade de pa-râmetros de QoS também é um problema durante a seleção e negociação de serviços ([11], [12]). Nos Serviços Web semânticos, a ontologia for-nece um mecanismo para uma especificação que pode ser uma ponte para as diferentes terminologias semânticas e métricas relacionadas com a negociação de serviço. As vantagens do uso de ontologias são a inteli-gibilidade, interoperabilidade, transparência e extensibilidade.

Em [13] é proposta a ontologia NetQoSOnt, que oferece uma in-teroperabilidade semântica em termos de parâmetros usados na especifi-cação de QoS. Ela permite expressar relações de equivalência entre especificações de QoS em diferentes níveis (p.e., usuário, aplicação, transporte, rede e enlace). Como será tratado mais adiante, esta forma de relacionar especificações de QoS em diferentes níveis usando equiva-lências tem um problema de granularidade. Uma especificação de QoS é equivalente em uma outra especificação pré-definida na ontologia.

A NetQoSOnt permite expressar a equivalência entre especifica-ções de QoE e de QoS a nível de rede. Como será tratado mais adiante, esta forma de mapear QoE em QoS usando equivalências tem um pro-blema de granularidade. Uma especificação de QoE é mapeada em uma especificação de QoS pré-definida na ontologia.

15

1.1 OBJETIVOS Objetivo Geral Este trabalho propõe um aprimoramento na ontologia NetQo-

SOnt, oferecendo recursos para o efetivo mapeamento entre especifica-ções de QoE e QoS nos mais diversos níveis da rede. A solução propos-ta consiste em expressar a semântica das regras na linguagem SWRL (Semantic Web Rule Language) [14], além de utilizar recursos da API OWL versão 2.0 e da linguagem Java.

Objetivos Específicos Ao final da dissertação, pretende-se alcançar os objetivos especí-

ficos listados a seguir: • Analisar a ontologia NetQoSOnt quanto a forma de ma-

peamento entre especificações de QoS. • Estender a ontologia NetQoSOnt para permitir que as es-

pecificações de QoE sejam combinadas com os parâme-tros de QoS, resultando no mapeamento da QoS para a QoE.

• Criar regras semânticas em SWRL para prover o mape-amento.

• Especificar alguns conceitos de QoE na área de VoIP, como MOS, Fator R e Qualidade Subjetiva (excelente, bom, regular, insatisfatório, ruim).

• Desenvolver um protótipo onde é possível especificar os conceitos de QoE para validar a proposta.

1.2 JUSTIFICATIVA E MOTIVAÇÕES

O que motivou a escrever sobre esse tema foi a necessidade de

permitir aos usuários e clientes dos serviços de rede com QoS especifi-car seus requisitos de qualidade em termos de parâmetros de QoE de mais alto nível, que são de mais fácil entendimento. É mais simples o usuário de um serviço de comunicação pedir uma QoS, definindo uma especificação de QoE em alto nível, do que ter o conhecimento sobre o que é necessário, em temos de parâmetros de rede, ao nível de rede. Ou então, usando um exemplo, quando um usuário pede MOS>=4.34, ele está na verdade pedindo ao provedor do serviço de comunicação uma especificação de QoS, no entendimento dele. E para isso o provedor precisa ter o entendimento do que o usuário está solicitando.

16

Para permitir que o cliente/usuário utilize parâmetros de mais alto nível para expressar suas necessidades de QoS, é preciso existir um mecanismo que converta as solicitações de QoS do provedor para os níveis superiores da arquitetura TCP/IP. É necessário que as especifica-ções realizadas pelo usuário/cliente sejam “entendidas” pelas NSPs. Portanto, é necessário determinar os requisitos de desempenho de rede que devem ser atendidos de forma a garantir a qualidade do usuário.

Nas pesquisas por trabalhos correlatos (seção 1.4), foram encon-tradas poucas contribuições relacionadas com o uso de ontologias de QoS e QoE com mapeamentos de QoS para QoE. Neste trabalho, inves-tiga-se o uso de ontologias e regras para especificar o mapeamento de parâmetros de QoS. O uso de ontologias para realizar este mapeamento tem várias vantagens. Além de o mapeamento ser realizado de forma dinâmica, ou seja, o NSP importando as definições de QoE da ontologia da organização, sabe o que pode ser garantido para suas CoSs, vários parâmetros podem ser definidos na sua ontologia. Um NSP pode definir parâmetros de QoS com nomes comuns a sua ontologia e outro NSP define os mesmos parâmetros porém com nomes diferentes. Então a ontologia se encarrega do entendimento desses parâmetros.

1.3 CONTRIBUIÇÃO DO TRABALHO

Como apresentado anteriormente, considera-se um requisito im-

portante dos sistemas de gerenciamento de QoS que a especificação de QoS possa ser feita através de parâmetros ao nível da Qualidade de Ex-periência (QoE), que é a qualidade observada pelo usuário final. No entanto essa flexibilidade exige mecanismos eficientes para receber uma QoE e combiná-la com os parâmetros de QoS para atender as expectati-vas do usuário dos serviços. Além disso, diferentes tipos de aplicações podem adotar diferentes parâmetros de QoE e métricas.

A NetQoSOnt não expressa relações de mapeamento entre parâ-metros, apenas de equivalência, fazendo com que a ontologia fique atre-lada a parâmetros de rede sempre fixos. A presente dissertação propõe uma abordagem semântica para solucionar o problema de terminologia e relacionamento entre parâmetros de QoS em QoE. Algumas limitações da NetQoSOnt quanto a expressão de relações de mapeamento entre parâmetros via o uso da linguagem SWRL. O uso de regras que especi-ficam o mapeamento de parâmetros provê um maior dinamismo na tra-dução da QoS para o QoE, de forma que novos parâmetros de QoS e QoE podem ser facilmente criados e dinamicamente “entendidos” pelas partes.

17

O dinamismo está associado ao fato de que para cada especifica-ção em nível de usuário, tem-se um resultado gerado automaticamente para cada CoS do NSP, na ontologia.

Outra vantagem da abordagem proposta é que a especificação formal dos conceitos é mantida por cada entidade, uma vez que as regras SWRL são genéricas e independem dos vocabulários usados interna-mente por cada organização.

1.4 TRABALHOS RELACIONADOS

Na pesquisa por trabalhos correlatos procurou-se catalogar os

projetos que apresentam pesquisas com temas relacionados com geren-ciamento de QoS; estabelecimento e gerenciamento de acordos em ní-veis de Serviços Web e em nível de serviços de transporte de dados ou de comunicação; mapeamentos de QoS em QoE; mapeamento de QoE em QoS.

Atualmente tem-se tecnologias sofisticadas e os resultados da in-vestigação em matéria de suporte de QoS em Serviços Web de diferentes domínios. Isso é explicado nos trabalhos documentados em [15], [16], [17].

Para a definição de uma solução de gerenciamento de QoS na Web Semântica é necessário a adoção de uma ontologia de QoS. As duas principais propostas de ontologia de QoS são a QoSOnt [17] e a OWL-QoS [18]. Ambas foram desenvolvidas a partir da OWL-S.

Uma ontologia para especificação semântica de QoS em redes de computadores foi desenvolvida em [13], levando em conta aspectos relacionados às principais tecnologias [17] e [18] que pudessem contri-buir para o campo da pesquisa, chamada de NetQoSOnt. A NetQoSOnt pode ser usada como base de abordagem semântica de gerenciamento de QoS para selecionar, negociar, invocar e monitorar serviços.

Nesse trabalho é proposto uma extensão da ontologia NetQo-SOnt, como meio formal e extensível para realizar a especificação de QoE usando parâmetros de níveis de serviço, incluindo parâmetros de qualidade percebida e parâmetros das camadas de rede. A NetQoSOnt permite expressar relações de equivalência entre especificações de QoS em diferentes níveis. Por exemplo, ela permite expressar a equivalência entre especificações de QoE e de QoS em nível de rede. No entanto, esta forma de mapear QoE em QoS usando equivalências tem um problema de granularidade. Uma especificação de QoE é mapeada em uma especi-ficação de QoS pré-definida na ontologia. A NetQoSOnt foi concebida para trabalhar com classes equivalentes. Os relacionamentos são possí-

18

veis graças ao conceito de equivalência de conceitos (classes) em onto-logia.

O trabalho proposto visa melhor a ontologia existente, incluindo, por exemplo, fórmulas implementadas por outros autores que serão responsáveis pela tradução dos parâmetros de rede, definidos pelo pro-vedor, em parâmetros de QoE, definidos pelo cliente. Os parâmetros de QoE resultantes da aplicação das fórmulas poderão ser comparados, via reasoner, usando a ontologia, com os parâmetros de QoE solicitados pelo usuário. Dessa forma se pode gerar, de maneira dinâmica, valores de QoE para as classes de serviço do provedor. Com isso se obtêm in-formações sobre quais classes de serviço de um provedor podem atender determinadas solicitações de QoE dos usuários.

Na busca por trabalhos relacionados a mapeamento de QoS em QoE usando ontologias, chama atenção uma plataforma baseada em agentes para mapear qualidade de serviço em qualidade de experiência. A proposta está definida em [19]. Nela os autores propõem ainda uma ontologia para a qualidade de experiência [20]. No entanto nesse traba-lho não são apresentados exemplos de uso da ontologia, nem resultados, deixando tudo como trabalho futuro, o que é uma deficiência para a área acadêmica e pesquisa.

Em [7] é proposto um modelo de QoE chamado de QoBiz (Qua-lity of Business). Esse modelo trata de métricas de qualidades referentes à Experiência e a Qualidade de Negócio. Já em [8], o modelo QC (Qua-lity Class) propõe a identificação do nível de qualidade no qual os usuá-rios estão interessados.

Nenhuma das obras citadas acima aborda as ontologias para es-pecificar requisitos de QoE e especificações de QoS, tampouco o mape-amento dos parâmetros de qualidade de serviço em qualidade de experi-ência. Alguns trabalhos relevantes [21], [22], citados na seção 2.3, usam ontologias de QoE, realizam o mapeamento, mas não fazem uso da ri-queza semântica das regras SWRL. As ontologias não são capazes, so-zinhas, de deduzir novos conhecimentos partindo dos já existentes, essa funcionalidade pode ser conseguida com o uso de regras semânticas juntamente com a representação ontológica.

1.5 ESTRUTURA DA DISSERTAÇÃO

O primeiro capítulo trata de alguns problemas ainda por serem re-

solvidos no gerenciamento de QoS em nível de comunicação de dados e da descrição dos objetivos.

19

O segundo capítulo aborda conceitos sobre QoS e QoE. Como cenário ilustrativo, este capítulo apresenta conceitos de QoS e QoE em aplicações de Voz sobre IP.

O terceiro capítulo apresenta os serviços Web, a negociação dos serviços, a descoberta, a qualidade, os serviços Web semânticos, as ontologias, o processo de negociação e as linguagens de ontologia para QoS. A idéia desse capítulo é abordar os conceitos de serviços na Web, fazendo uma analogia com o conceito de repositórios de ontologias, onde os provedores de serviços podem publicar (classes de serviços) e resgatar informações sobre a necessidade de mapeamentos dos parâme-tros qualitativos dos clientes.

O quarto capítulo descreve a ontologia NetQoSOnt, o conteúdo de cada um de seus módulos e como eles funcionam.

O quinto capítulo apresenta a extensão proposta da ontologia NetQoSOnt e os testes que foram executados. Aqui são apresentados os detalhes da ontologia estendida, tais como a inclusão da camada de ma-peamento e a ocorrência do mapeamento nos diferentes níveis. O capítu-lo também explica a metodologia dos testes e as ferramentas utilizadas para validação da proposta.

O sexto capítulo aborda as conclusões e trabalhos futuros.

20

2. QOS E QOE A QoS nos serviços de redes é definida pela ITU-T [2] como o

efeito combinado do desempenho do serviço que determina o grau de satisfação do usuário de um serviço. Em geral, medições e a própria QoS são, geralmente, definidas em termos de parâmetros de desempe-nho de rede, não em termos de satisfação para o usuário final. O pressu-posto fundamental para o provimento tradicional é que por trás da medi-da da QoS, se relacione a QoE para o usuário final.

Este capítulo aborda conceitos de QoS e de QoE em aplicações de tempo real e relaciona os conceitos com funções matemáticas, usadas para mapear parâmetros de QoS/QoE.

2.1 QOS NA REDE

O conceito de Qualidade de Serviço (Quality of Service – QoS)

foi introduzido pela ISO para mensurar a qualidade de serviços ofereci-da por uma rede de comunicações, ou seja, refletir o quanto ela é capaz de atender às expectativas de seus usuários através dos serviços que ela disponibiliza [23].

2.1.1 APLICAÇÕES E SEUS REQUISITOS DE QOS

A QoS solicitada ao NSP depende dos requisitos específicos das

aplicações. Aplicações de áudio e vídeo exigem a garantia de uma vazão mínima, baixo retardo e baixa variação de retardo, mas são ligeiramente tolerantes a erros e perdas. A perda de alguns quadros em fluxo de ví-deo, por exemplo, não é suficiente para comprometer a percepção do usuário com relação ao conteúdo da informação audiovisual. Por outro lado, aplicações de transferência de arquivos como FTP são intolerantes a erros, mas não necessitam de garantias de retardo ou vazão, embora uma transferência mais rápida traga mais satisfação para o usuário. A Tabela 1 apresenta os requisitos de QoS de algumas aplicações multimí-dia e de tempo real.

21

Requisitos de QoS

Voz FTP E-mail Vídeo

Broadcat Vídeo

Interativo Largura de

Banda Baixa a Média

Baixa Baixa Alta Alta

Descarte de Pacotes

Média Média Média Média Média

Atraso Alta Baixa Baixa Baixa Alta Jitter Alta Baixa Baixa Média Alta

Tabela 1. Requisitos de QoS das Aplicações. Fonte: [24]. No que diz respeito às necessidades de QoS, o IETF classifica as

aplicações em dois grandes grupos [25]: as de tempo-real e as elásticas. Nas aplicações de tempo real, os dados são esperados por um certo tem-po para que sejam considerados úteis. Estas aplicações são subdivididas em tolerantes – aquelas que suportam violações do limite de retardo e intolerantes – aquelas que não suportam violações ocasionais. Nas apli-cações elásticas, a utilidade dos dados não está relacionada ao seu tem-po.

Muitas aplicações tempo-real são adaptativas, que procuram ade-quar-se às condições da rede a cada instante. Como exemplo se pode adotar uma aplicação de vídeo que varia a sua taxa de geração de dados trocando o codificador de vídeo ou reduzindo a resolução, o número de cores e o número de quadros de vídeo apresentados por segundo.

Em aplicações tempo-real intolerantes, como por exemplo, apli-cações de voz, quando o atraso é alto, ocorre a perda de QoS, ocasio-nando eco e sobreposição de conversação. Já para aplicações elásticas a sensibilidade ao atraso é baixa. Independente do grau de sensibilidade do atraso para as aplicações é imprescindível estabelecer limiares e con-figurar a rede para que a mesma possa atender as solicitações nos tem-pos estipulados, evitando com isto a perda dos pacotes.

2.1.2 PRINCIPAIS SOLUÇÕES DE QOS

No contexto da Internet existem dois modelos para implementar

QoS: serviços Integrados (IntServ) e serviços diferenciados (DiffServ) [3].

O modelo IntServ é baseado em reserva de recursos. Antes do i-nicio da comunicação, a fonte emissora solicita à fonte receptora a alo-cação de recursos através do protocolo RSVP tais como largura de ban-da e tempo de duração da conexão. O modelo IntServ é caracterizado pela alocação de recursos para dois tipos de serviços: (i) serviços garan-tidos para aplicações que necessitam de um atraso constante, e (ii) servi-

22

ços de carga controlada para aplicações que requerem segurança e des-tacam o serviço de melhor esforço (BE - Best Effort).

Na proposta do modelo DiffServ a implementação da QoS ocorre com base na definição de tipos de serviços sobre o tráfego da rede para atender o nível de serviço desejado de cada aplicação, como por exem-plo, voz, vídeo e dados. Para prover diferenciação os pacotes são marca-dos de acordo com as Classes de Serviço (CoS - Class of Services) pré-determinadas no campo DS (Differentiated Service Field) do cabeçalho IP. As CoS definidas são: EF (Expedited Forwarding) e AF (Assured Forwarding). A classe AFNM define quatro classes (N=4) com três ní-veis de prioridade de descarte (M=3) em cada classe, ou seja, um pacote IP que pertence a uma classe AF i e j tem determinada prioridade de descarte, onde 1<= i <=N e 1<= j <=M [26]. Por exemplo, serviços premium pertencem a classe EF e serviços assegurados pertencem a classe AF.

O desempenho do serviço é gerido através de um conjunto de pa-râmetros de rede tais como atraso, variação de atraso – jitter, perda de pacotes e taxa de transferência [25].

2.1.3 NEGOCIAÇÃO E INVOCAÇÃO DE SERVIÇOS

Existem ao menos três atores na oferta de um serviço com QoS:

Cliente é uma entidade com permissões legais para se subscrever (se registrar) ao serviço oferecido pela Provedora de Serviço (NSP – Net-work Service Provider); Usuário é uma entidade, autorizada pelo Clien-te, que invoca/usa o serviço; e a NSP é a entidade que oferece os servi-ços para os Usuários/Clientes. Note-se que em serviços de redes, nor-malmente uma provedora de Serviços atue também como Clien-te/Usuário de outras Provedoras de serviços parceiros.

Durante a subscrição, o Cliente e sua NSP assinam um contrato de negócio, chamado de Acordo de Nível de Serviço (SLA – Service Level Agreement), especificando os termos e as circunstâncias do ofere-cimento do serviço, incluindo a rede e os aspectos de pagamen-to/faturamento. Um SLA contém uma lista de Especificação do Nível de Serviço (SLSs – Service Level Agreements) que permite especificar a QoS do tráfego considerado essencial para o cliente.

Dentre outros parâmetros, um SLS especifica a QoS a ser garan-tida para um determinado tráfego. Esta especificação contém a faixa admissível de valores para um conjunto de parâmetros de QoS (p.e. atraso, variação de atraso, taxa de perdas de pacote). Por exemplo, um provedor de acesso de redes sem fio pode garantir que, dentro de sua

23

área de cobertura, a potência do seu sinal nunca será menor que certo percentual. Outro exemplo seria o de uma NSP que pode garantir que, dentro de seu domínio, a transmissão de pacotes nunca terá um atraso maior que 100 ms.

Hoje em dia, diversas NSPs adotam o provisionamento estático de QoS, onde elas alocam os recursos de rede de maneira off-line, de acordo com os SLAs acordados com os seus clientes. Diversas pesquisas recentes propõem esquemas de provisionamento dinâmico de QoS, mais adaptados à flexibilidade e à automatização desejada aos serviços de rede com garantias de QoS. No provisionamento dinâmico, os relacio-namentos entre NSPs, clientes e usuários são complicados. Diferente de um SLA estático negociado manualmente entre um cliente e um Prove-dor de Serviços, os esquemas dinâmicos do provisionamento de QoS permitem a clientes e fornecedores automaticamente (re)negociarem SLAs e permitem também aos usuários especificarem o nível requerido de QoS (SLS) durante a invocação do serviço.

Tradicionalmente, cada SLS define o nível de QoS a ser garanti-do a partir de um conjunto de pares parâmetro-valor (ou faixa de valo-res). Atualmente não há um padrão que defina os parâmetros de SLS e métricas. Uma tentativa de padronização foi feita no contexto do projeto Tequila [27], que produziu um Draft IETF [28] propondo as linhas guias para a definição de parâmetros de SLS, incluindo OWD (One Way De-lay) [29], PLR (Packet Loss Rate) [30] e IPDV (IP Packet Delay Varia-tion) [31].

Devido a esta falta de padronização em termos de parâmetros de SLA/SLS, as NSPs (Network Services Provider) podem adotar diferen-tes parâmetros e métricas que podem ser usadas para expressar a QoS. Estas métricas e valores podem estar até ligadas ao tipo de solução de QoS ou até mesmo nomes comerciais dos serviços oferecidos. Similar a [27], a maior parte dos trabalhos atuais utilizam os parâmetros de quali-dade em nível de rede para especificar a QoS. Por exemplo, no caso da NSP adotar a solução DiffServ, para cada SLS ela pode utilizar a classe de serviço que será usada para atender a qualidade solicitada.

2.2 QOE

Sabe-se que o desempenho de um serviço de rede é gerido através

do um conjunto de parâmetros de rede, porém essas métricas não repre-sentam a totalidade da qualidade de experiência (QoE – Quality of Ex-perience) a partir da expectativa do usuário. Em vez disso, elas repre-

24

sentam apenas alguns parâmetros de desempenho de rede que podem, algumas vezes, afetar a experiência do usuário.

De acordo com a tendência do mercado para a convergência de redes, uma necessidade tem despertado o interesse de se medir de forma objetiva e sistemática a qualidade da voz recebida por uma das partes envolvidas na comunicação.

O termo QoE – Quality of Experience pode ser considerado rela-tivamente novo para a compreensão de alguns recursos de multimídia. Algumas aplicações multimídia têm impulsionado a utilização do termo na indústria de telecomunicações, como por exemplo, aplicações VoIP e aplicações de TV.

2.2.1 DEFINIÇÃO DE QOE

Existem várias definições para QoE. Abaixo são apresentadas al-

gumas destas definições encontradas na literatura: • “As características das sensações, percepções e opiniões das

pessoas em relação à interação com seus ambientes. Essas ca-racterísticas podem ser agradáveis e prazerosas ou desagra-dáveis e frustrantes”. [32].

• “A totalidade da Qualidade de mecanismos de serviço, desde que assegure uma transmissão suave de áudio e vídeo através de rede IP” [33].

• “O desempenho global de um sistema do ponto de vista dos u-suários. QoE é uma medida fim a fim dos níveis de desempe-nho na perspectiva do utilizador e um indicador de quanto o sistema atende as necessidades dos utilizadores” [34].

• “A experiência da percepção do usuário que está sendo apresen-tada pela camada de aplicação, onde o aplicativo funciona como uma interface front-end do usuário que apresenta o re-sultado global da qualidade individual dos serviços” [35].

Percebe-se que todas essas definições ficam em uma camada de abstração em relação à QoS. [35] considera que essa camada de abstra-ção é uma pseudo-camada e é uma extensão da camada de aplicação definida pelo modelo OSI [36]. Então se pode ver a definição de QoE como sendo uma extensão da QoS tradicional no sentido da QoE forne-cer informações sobre serviços fornecidos a partir de um ponto de vista do usuário [37].

25

2.3 MAPEAMENTO DE QOE EM QOS Do ponto de vista do usuário, em muitos casos é mais adequado

utilizar parâmetros dos níveis de QoE ou de aplicação. Por exemplo, é mais simples o usuário especificar a qualidade de uma aplicação de voz em parâmetros de QoE ou em parâmetros de aplicação do que em parâ-metros de rede. Mas o cliente também precisa usar parâmetros de de-sempenho de redes para especificar o nível de QoS de tráfegos agrega-dos e serviços que não têm o usuário final (humanos).

O mapeamento de QoE em QoS leva em consideração as expecta-tivas exigidas pelo cliente em relação ao desempenho fim a fim envolvi-dos na comunicação, incluindo o próprio usuário, o terminal, a rede e a infra-estrutura do serviço.

A Figura 1 ilustra a necessidade de mapeamento de QoE em QoS e a identificação dos mecanismos de QoS providos pela NSP. É de suma importância se determinar os requisitos de QoS necessários a nível de rede para garantir a QoE, e depois, usando estes requisitos é possível determinar qual serviço de rede (de encaminhamento de tráfego) atende a estas necessidades.

Identificação

dos requisitos

de QoE

Identificação

dos requisitos

de QoS

Definição da

arquitetura

das tecnologias

Métricas de QoE•MOS•FatorR•Qualidade

Métricas de QoS•Atraso•Perda•Jitter

Serviços de rede da NSP•IntServ•DiffServ

•EF•AF (ouro, prata, bronze, BE)

Figura 1. Etapas para a garantia de QoE.

Algumas tentativas de mapeamento de qualidade subjetiva em re-

quisitos objetivos ao nível de rede já foram propostas na literatura ([19], [20], [21], [22], [38]).

Alguns trabalhos, como [21], [22], [39] propõem soluções de ma-peamento usando a qualidade percebida pelo usuário QoP para QoS, em termos de expressões matemáticas e outras.

26

Em [21] é apresentada uma proposta de um framework baseado em ontologias, regras e representações semânticas matemáticas, para cálculo automático da qualidade do nível de serviço percebida pelos clientes dos serviços telemáticos. Isso é feito usando uma ferramenta matemática, destinada a mapear a qualidade técnica e a qualidade de experiência. Porém, o trabalho proposto não detalha a ontologia propos-ta, nem mesmo através de exemplos.

Ambos os trabalhos [21], [22] usam ontologias de QoE, realizam o mapeamento, mas não fazem uso da riqueza semântica das regras SWRL.

Uma proposta de uma plataforma baseada em agentes para mape-ar qualidade de serviço em qualidade de experiência é apresentada em [19], no qual os autores propõem ainda uma ontologia para a qualidade de experiência [20]. No entanto, nesses trabalhos não são apresentados exemplos de uso da ontologia, nem resultados, deixando tudo como trabalho futuro.

2.4 QOE E QOS EM VOIP

O serviço de telefonia pública tradicional utiliza a rede PSTN

(Public Switched Telephone Network), o que significa que quando uma chamada é feita, é estabelecido um circuito dedicado de um telefone até o outro. Décadas de conhecimento e experiência permitiram ao serviço fornecido pela PSTN alcançar a alta qualidade e a disponibilidade que possui hoje. As redes a comutação a circuitos garante taxa de bits, atraso limitado e constante (sem variação). O nível de qualidade esperada da rede PSTN é denominado de “cinco-noves”, o que significa que a rede como um todo deve estar disponível e funcional para 99,999% do tempo [40].

O serviço telefônico fornecido pela VoIP ocorre de maneira bem diferente daquele oferecido pelas PSTNs. Ao invés da comutação a cir-cuito, a conexão telefônica em VoIP é por comutação de pacotes, onde múltiplos dispositivos computacionais compartilham recursos de rede com a comunicação de dados. O serviço oferecido pela rede geralmente é do tipo melhor esforço, que, ao contrário da comutação a circuito, não fornece garantias de qualidade, gerando um problema na implementação da VoIP [41].

A tecnologia VoIP só pode ser utilizada nas redes de pacotes gra-ças à implementação de protocolos específicos (RTP, RTCP, H323, SIP, MG-CP, MECAGO) [42] e codificadores que suportam a digitalização da voz, com qualidade.

27

Os principais codecs de voz usados em aplicações de VoIP são o G.711 [43], G.723 [44], G.726 [45], G.728 [46] e G.729 [47].

No sentido de se medir a qualidade da voz recebida por uma das partes envolvidas na comunicação, são desenvolvidos métodos subjeti-vos e objetivos de medida de qualidade da voz, cujo objetivo é determi-nar qual seria a opinião do ouvido humano ao escutar um sinal sonoro transmitido pelo conjunto de dispositivos e protocolos envolvidos na comunicação VoIP. Nesta dissertação é considerado que estes métodos resultam em parâmetros de QoE.

Os principais parâmetros de QoE em VoIP são o MOS (Mean Opinion Score) [10] e o Fator R [48]. Além destes, outros métodos obje-tivos poderiam ser aplicados para se obter parâmetros aos mapeamentos de QoE em nível de usuário, como o PESQ (Perceptual Evaluation of Speech Quality) citado em [48], o PAMS (Perceptual Analysis Measu-rement System) [49] e o PSQM (Perceptual Speech Quality Measure-ments) [50].

2.4.1 MOS

O MOS (Mean Opinion Score) [10] foi originalmente empregado

para auxiliar na concepção, pesquisa e desenvolvimento da telefonia digital. É um padrão numérico usado para mensurar e reportar a quali-dade da voz após a compressão ou transmissão.

De acordo com o ITU-T P.800 [10] a quantificação do valor de MOS são feitos em um grupo de ouvintes. Os ouvintes dão a cada amos-tra de voz uma classificação de 1 a 5, sendo que esse valor quantifica a qualidade de voz, sendo: 1 – ruim; 2 – pobre; 3 – razoável; 4 – bom; 5 – excelente. Ao usar o MOS com ouvintes humanos, um grupo de pessoas ouve o áudio e dá opiniões sobre a qualidade da chamada. É solicitado a essas pessoas que opinem sobre as chamadas, variando de muito boa até muito ruim, pontuando-as de 5 a 1. Em seguida, a média do valor MOS representa um índice de referência.

Uma pontuação adequada, segundo o ITU-T, para o serviço de te-lefonia seria um valor de MOS igual ou superior a 4. Quando o MOS diminui para um valor até 3.5, alguns usuários podem achar a qualidade de voz inaceitável. Quando o MOS fica abaixo de 3,5, os usuários fica-rão insatisfeitos e chamada torna-se inviável. Um MOS abaixo de 2,6 caracteriza uma péssima chamada.

Abaixo está listada a média do MOS relacionado com alguns co-decs comumente utilizados em chamadas VoIP, Tabela 2.

28

CODEC MOS G.711 4,34 iLBC 4,14 AMR 4,14 G.729 3,92

G.723.1 3,9 GSM EFR 3,8

G.726 ADPCM 3,8 G.729a 3,7 G.723.1 3,65 GSM FR 3,5

Tabela 2. Relação CODEC MOS. Fonte: [51]. Como a obtenção da pontuação do MOS é um procedimento de

difícil reprodução, foram propostos alguns métodos objetivos para esti-mar a qualidade da voz, entre outros o E-Model [47] e o PESQ (Percep-tual Evaluation of Speech Quality), que foi apresentado em [48] e poste-riormente padronizado pelo ITU-T P.862 [52]. O PESQ associa um valor de MOS a uma amostra de fala degradada comparada à amostra original. Este padrão pode ser usado para identificar atrasos na transmis-são.

2.4.2 FATOR R

O E-Model tem como saída um valor único que varia de 0 a 100,

chamado de Fator R, que é usado para estimar a percepção da qualidade da voz para o usuário.

Os valores do método Fator R são convertidos para valores de MOS, conforme Equação 1.

Para R < 0: MOS = 1

Para 0 < R < 100: MOS = 1 + 0,035R + 7.10-6R(R-60)(100-R) Para R > 100: MOS = 4,5

Equação 1. Conversão de Fator R em MOS. Fonte: [47]. O Fator R é descrito em categorias de valores conforme a Tabela

3 [53]. Por exemplo, os usuários normalmente ficam muito satisfeitos

quando o Fator R estiver entre 90 e 100, que é equivalente a um MOS entre 4,34 e 4,5. Quando o Fator R for maior ou igual a 80 e menor que 90, os usuários ficam satisfeitos e isso equivale a um MOS entre 4,03 e 4,34. Quando o Fator R for maior ou igual a 70 e menor que 80, alguns

29

usuários ficam insatisfeitos, o que equivale a um MOS entre 3,60 e 4,03. Quando o Fator R for maior ou igual a 60 e menor que 70, muitos usuá-rios ficam insatisfeitos, o que equivale a um MOS entre 3,10 e 3,60. Agora quando o Fator R for maior ou igual a 0 e menor que 60, pratica-mente todos os usuários ficam insatisfeitos, o que equivale a um MOS entre 1,00 e 3,10.

Fator R MOS Satisfação do usuário

90 ≤ R < 100 4,34 – 4,50 Muito satisfeitos 80 ≤ R < 90 4,03 – 4,34 Satisfeitos 70 ≤ R < 80 3,60 – 4,03 Alguns insatisfeitos 60 ≤ R < 70 3,10 – 3,60 Muitos insatisfeitos 0 ≤ R < 60 1,00 – 3,10 Quase todos insatisfeitos

Tabela 3. Categoria de transmissão da fala. Fonte: [53].

2.4.3 OUTROS MÉTODOS OBJETIVOS DE QOE EM VOIP O PESQ (Perceptual Evaluation of Speech Quality), que foi apre-

sentado em [48] e posteriormente padronizado pelo ITU-T P.862 [52] associa um valor de MOS a uma amostra de fala degradada comparada à amostra original. Este padrão pode ser usado para identificar atrasos na transmissão.

O PAMS [54] é um método perceptual da avaliação objetiva da qualidade da voz que retorna a pontuação de qualidade em duas diferen-tes escalas, de 1 a 5, similar ao MOS, que é a qualidade auditiva e a de esforço de compreensão [10].

O PSQM [50] é um método perceptual de medida objetiva da qualidade da voz e encontra-se definido na recomendação da ITU-T [54]. Esse método leva em consideração a pontuação, que varia de zero (qualidade perfeita) a infinito e dá um peso maior para distorções aditi-vas do que para distorções atenuantes. Similarmente, a modelagem cog-nitiva aplica pesos diferentes para a influência do ruído no cômputo da pontuação [55].

A pontuação final dada pelo PSQM indica o grau de degradação de qualidade subjetiva devida à codificação da fala [54]. Uma pontuação zero indica qualidade perfeita. Valores mais altos indicam níveis cres-centes de degradação. Na prática, os piores índices ficam entre quinze e vinte [55].

Além desses ainda foram desenvolvidos o PSQM+ [54] e o MNB [54]. Mas estes e os padrões PSQM, , PESQ e PAMS não são apropria-dos para medir a qualidade da chamada em uma rede de dados. São

30

baseados na telefonia mais tradicional, tratando a rede de dados como uma grande caixa preta analógica. Não sendo baseados em rede de da-dos, não conseguem lidar com atraso, variação de atraso e perda de pa-cote. Também não possuem escalabilidade, o que permitiria avaliar a qualidade de centenas ou milhares de chamadas simultâneas. O E-Model é o padrão recomendado para a avaliação da qualidade da chamada VoIP [39].

2.5 QOE EM OUTRAS APLICAÇÕES

Na área de televisão (IPTV – Internet Protocol Television) [56], a

QoE também é medida através de testes subjetivos usando-se o MOS, como especificado pelo ITU-R BT.500-11 [57], onde amostras de vídeo são exibidas para os telespectadores, que são convidados a avaliá-las em uma sala. A classificação MOS para TV é análogo ao VoIP, ou seja, varia entre 1 e 5. Para determinação do valor de MOS, um grupo de telespectadores é selecionado e se reúne em uma sala. A partir da classi-ficação atribuída a cada caso é determinado o MOS.

Alguns métodos quantitativos de medição da qualidade de vídeo têm sido desenvolvidos. Uma medição tradicional é o PSNR (“Peak Signal to Noise Ratio”) [58]. Outros exemplos são o VQM (Video Qua-lity Metric) que se utiliza de um algoritmo e medidas para cálculo de erros, o MSE (Mean Square Error) e o PSRN. Além destes, existem outras propostas [59] e [60] com o objetivo de melhorar a medição da qualidade de vídeo.

2.5.1 MAPEAMENTO DE QOE EM QOS EM VOIP

Os diversos parâmetros de QoE de VoIP medem a qualidade ao

nível do usuário do serviço de VoIP. Para serem garantidos, alguns re-cursos precisam ser configurados na rede.

Como introduzido na seção 2.1.3, os parâmetros de QoS ao nível de rede mais adotados são o atraso (OWD – One Way Delay), a variação de atraso (IPDV – IP Packet Delay Variation) e a taxa de perdas de pacotes (PLR – Packet Loss Rate). Em [61], os autores apresentam os limites de desempenho dos parâmetros de QoS de rede que devem ser garantidos para atingir o valor máximo de MOS dos codecs de voz. Estes limites são apresentados na Tabela 4. Por exemplo, para o G.711 atingir o valor de MOS de 4,5 é necessário que a rede garanta um limite de atraso de 150 ms, uma taxa de perda inferior a 1,5 %, uma variação de atraso de 40 ms e uma taxa de bits de 64 kbps.

31

QoS em nível de Usuário QoS em nível de Rede

PT Codec MOS Qualidade Fator R

Atraso (ms)

Perda (%)

Jitter (ms)

Taxa (Kbps)

0 G.711 4,5 Excelente 100 150 1,5 40 64 96 a

127 G.726 4,34 Boa 90 250 3 75 32

15 G.728 4,03 Regular 80 350 15 125 16 18 G.729 3,6 Insatisfatória 70 450 25 225 8 4 G.723 3,1 Ruim 60 600 25 225 6,4

Tabela 4. Parâmetros QoE x parâmetros de QoS baseado em [61]. A coluna PT (Payload Type) da Tabela 4 é um campo do protoco-

lo RTP (Real Time Protocol) que identifica o tipo de mídia transportada no pacote IP. Este campo do pode ser verificado pela aplicação recepto-ra para determinar como tratar o dado, passando este para um decodifi-cador adequado. Todos os codecs citados têm uma identificação prede-terminada a não ser o codec G.726 que recebe uma identificação através de um valor dinâmico que varia entre 96 a 127, o que em muitos casos recebe a identificação 96 que é o padrão.

Em [62] é proposta uma função matemática, apresentada na Equação 2, que modela a relação entre MOS e os parâmetros de rede usando um conjunto de dados disponibilizados em [63]. A análise dos dados juntamente com o uso de técnicas de ajuste de curvas, derivou a função que ao receber como parâmetros a taxa de perdas de pacotes e o atraso, gera um valor de MOS, demonstrado na Equação 2.

MOS = T – αp + βd – ηd 2 + φd 3

Equação 2. Parâmetros de rede formulados à QoE. Fonte: [62]. Na Equação 2, os parâmetros são: α=0.195, β=2.64x10-3,

η=1.86x10-5, φ=1.22x10-8, T representa o MOS do codificador sem perdas e atraso, p é a perda na rede e d representa o atraso.

As propostas acima definem como mapear, e não como os siste-mas envolvidos no gerenciamento da QoS podem adquirir o conheci-mento de como mapear novos parâmetros de QoS e QoE. Em [19] e [20], os autores propõem, respectivamente, uma plataforma baseada em agentes para mapear QoS de rede para QoE e uma ontologia para QoE. No entanto, as ontologias propostas pelos artigos não é usada para re-solver, de fato, o mapeamento entre QoS e QoE. Ela foi usada para co-municação entre agentes e o mapeamento é feito via tabelas.

32

2.6 CONSIDERAÇÕES SOBRE O CAPÍTULO

O capítulo apresentou conceitos de QoE e de QoS em nível de

usuário e em nível de rede, descreveu os principais parâmetros de QoE para as principais aplicações de rede em tempo real, como VoIP e TV, e finalmente especificou as funções de mapeamento de QoS em QoE. Estas funções serão usadas nos próximos capítulos, na ontologia e no cenário de teste de uma aplicação VoIP.

Na NetQoSOnt [13] é proposta uma ontologia de especificação de QoS para serviços de redes. A ontologia pode ser usada como base de abordagens semânticas, permitindo que se desenvolvam operações de gerenciamento de QoS, tais como seleção, negociação, invocação e monitoramento de serviços. No entanto, essa proposta não apresenta uma solução ideal para realizar o mapeamento de QoS/QoE. Neste sen-tido, um dos objetivos desta dissertação consiste em analisar e propor formas de realizar o efetivo mapeamento de QoS/QoE na NetQoSOnt. Essas análises e propostas são apresentadas nos capítulos 4 e 5.

Os métodos subjetivos citados MOS e Fator R são utilizados na implementação do protótipo e na ontologia de especificação de QoE para expressar a satisfação dos usuários. Para fazer o mapeamento des-ses métodos foram utilizadas regras escritas na sintaxe SWRL. A com-binação da ontologia e das regras permite que a QoE seja combinada com parâmetros de QoS e traduzida em parâmetros de QoE de forma automática e flexível. Flexível, pois novos parâmetros de QoE podem ser definidos e o NSP pode adquirir este conhecimento via a importação desta nova ontologia.

Como também apresentado, não foram encontradas soluções ba-seadas em semântica para especificação do mapeamento de QoE em QoS, e vice versa. No quinto capítulo será apresentada uma ontologia de especificação de QoE para a aplicação VoIP. Esta ontologia poderá ser estendida com novos parâmetros e com outras aplicações, tais como IPTV e vídeoconferência.

33

3. NEGOCIAÇÃO DE QOS EM SERVIÇOS WEB Atualmente, entre os sistemas Web, duas tecnologias têm se des-

tacado: a tecnologia Serviços Web e a Web Semântica [64]. A primeira visa interoperabilidade entre sistemas heterogêneos, distribuídos na Web. A segunda faz referência a uma extensão da Web atual, onde os dados e os serviços são associados ao seu significado, permitindo buscas mais inteligentes. Os serviços semânticos tiveram sua origem na con-vergência dessas duas tecnologias.

Garantir a QoS na Web é um desafio significativo e crítico devi-do à natureza dinâmica e imprevisível da Internet. As aplicações da Internet, com diferentes características e requisitos, competem pelos recursos de rede e de servidores geralmente sem diferenciação nos ser-viços oferecidos pelos servidores e pela rede.

Este capítulo tem por objetivo apresentar o processo de negocia-ção de QoS em Serviços Web. O escopo deste estudo limita-se na apre-sentação de conceitos importantes para o entendimento da proposta, incluindo a descrição das linguagens envolvidas, da descoberta e com-posição dos Serviços Web e dos Serviços Web semânticos.

3.1 SERVIÇOS WEB E A NEGOCIAÇÃO DE SERVIÇOS

Um serviço Web é um sistema de software interoperável projeta-

do para suportar interação de máquina a máquina (sem a intervenção humana) sobre a rede [65]. A tecnologia de Serviços Web permite que aplicações diferentes possam se comunicar em sistemas integrados. Cada aplicação pode ter a sua própria linguagem e é responsabilidade dos Serviços Web a tradução para uma linguagem universal, como o XML (eXtensible Markup Language).

Para se descrever os Serviços Web, utilize-se uma notação padro-nizada – XML [66], que permite descrever as funcionalidades, a locali-zação, o modo de invocação e os protocolos utilizados para isto. Para existir uma negociação de um serviço Web, é necessário que um prove-dor ofereça ou publique seus serviços, de modo que o serviço possa ser descoberto e invocado.

Os serviços Web são implementados pelos NSPs. Quando dois ou mais provedores trabalham de modo colaborativo para criar um serviço Web mais sofisticado, tem-se uma composição de serviços. Após isso ocorre a publicação, onde o provedor anuncia a descrição dos serviços para que os consumidores possam encontrá-la. Em seguida ocorre a descoberta, na qual uma aplicação consumidora recupera uma descrição

34

do serviço via um servidor de registros. Na etapa de invocação, a aplica-ção consumidora invoca ou inicia uma interação com um serviço Web, utilizando as informações contidas na descrição do serviço.

3.1.1 COMPOSIÇÃO DE SERVIÇOS WEB

Esta etapa está relacionada com a implementação de serviços por

parte de organizações provedoras. A implementação pode ser feita dire-tamente pelas próprias organizações fornecedores que desejam disponi-bilizar um serviço eletrônico, ou então a partir de pedidos de potenciais organizações consumidoras que podem estar interessadas nos serviços.

Um processo de negócio pode ser realizado por apenas uma orga-nização ou por organizações parceiras. Quando duas ou mais empresas trabalham cooperativamente para criar um serviço Web mais sofistica-do, tem-se uma composição de serviços.

Os serviços Web são descritos usando uma linguagem de descri-ção de serviços, a WSDL (Web Service Description Language) [67] que utiliza um formato XML que permite que os serviços sejam descritos. Tipicamente usado para gerar código para o cliente e o servidor e para configuração.

3.1.2 PUBLICAÇÃO, BUSCA E DESCOBERTA DE SERVIÇOS WEB

Nessa etapa ocorre a troca de informações entre organizações

fornecedoras e organizações consumidoras. A divulgação de serviços é realizada pelos fornecedores, enquanto que os consumidores realizam buscas de serviços e comparações entre eles. A busca pode ser baseada em características funcionais e não funcionais. Informações sobre as garantias de QoS podem ser anunciadas pelas organizações fornecedo-ras. A descoberta de parcerias ocorre quando existe a compatibilidade entre serviços publicados e serviços procurados. Essas atividades devem ser executadas com o apoio de facilidades de busca e descoberta.

Uma vez que um serviço Web é definido usando WSDL, é neces-sária alguma forma de torná-lo conhecido para uso. Isso é feito através do registro UDDI (Universal Description, Discovery, and Integration) [68]. O UDDI funciona como um catálogo de serviços que fornece mé-todos para publicar e descobrir metadados sobre Serviços Web. Dessa forma, provedores de serviços podem publicar a existência de seus ser-viços para que potenciais usuários os encontrem. O registro UDDI ar-mazena uma descrição do serviço (conforme o tipo de negócio, dividin-

35

do por categorias e organizado hierarquicamente) e a localização do mesmo (binding).

3.1.3 NEGOCIAÇÃO DE SERVIÇOS WEB

Essa fase envolve ofertas e contra ofertas. Essa etapa estabelece

como o processo de negócio deverá ser realizado entre as organizações fornecedora e consumidora.

Existem alguns objetivos que fazem parte de uma negociação, tais como preço, disponibilidade e as operações. Outros elementos tam-bém podem ser encontrados, como por exemplo, os protocolos, as regras para validação, os parâmetros aceitáveis, entre outros.

3.2 FUNCIONAMENTO DOS SERVIÇOS WEB

Conforme descrito anteriormente, os serviços Web podem ser

descritos usando a WSDL, publicados com o uso do UDDI e descober-tos através de um mecanismo de busca padrão. Os clientes e provedores usam o protocolo SOAP (Simple Object Access Protocol) [69] para a troca de mensagens. O SOAP é o protocolo para comunicação que en-capsula os dados transferidos no formato XML. O protocolo SOAP estende o XML para que aplicações clientes possam enviar facilmente parâmetros para aplicações servidoras e então receber e entender o do-cumento XML retornado. Graças à simplicidade de um arquivo XML (texto puro), dados são facilmente trafegados entre sistemas de compu-tadores com arquiteturas e formatos de dados heterogêneos. O transporte é realizado pelos protocolos HTTP (HyperText Transfer Protocol) e HTTPS (HyperText Transfer Protocol Secure). Também é possível usar outros protocolos, como XMPP (Extensible Messaging and Presence Protocol) [70].

Os sistemas podem ser descritos usando a combinação das tecno-logias citadas acima e serem independentes de implementação e plata-forma. Como ilustrado na Figura 2, este nível de combinação requer o uso integrado de SOAP, WSDL e UDDI para prover uma infra-estrutura dinâmica e transparente dos Serviços Web.

36

Figura 2. Tecnologias utilizadas na descrição dos Serviços Web. Fonte:

[69]. A construção e a posterior comunicação dos serviços Web usando

diferentes plataformas, só é possível graças à utilização dos padrões descritos acima.

O XML é utilizado para representar a estrutura dos dados, nas mensagens que são recebidas e enviadas, independentes da linguagem de programação na qual a aplicação foi construída. A linguagem de programação torna-se transparente com o uso do XML. As chamadas às operações para publicar, localizar e invocar um Web Service, conside-rando os parâmetros de entrada e saída, são compiladas no protocolo SOAP. Os serviços (que podem ser operações, mensagens, parâmetros) são descritos usando a linguagem WSDL. A pesquisa e descoberta, que é executada pelos clientes para localizarem algum serviço que precisem, usam o registro UDDI.

Quando um solicitante faz a chamada de um serviço, usando para isso a linguagem WSDL, o intermediador verifica no repositório UDDI a possibilidade de satisfazer a solicitação. Caso encontre a solicitação, de acordo com a publicação feita pelo provedor de serviços, o solicita-dor utiliza o protocolo SOAP para a efetiva comunicação fim a fim entre solicitante e provedor.

Um documento XML pode conter tags, que são definidas na lin-guagem DTD (Document Type Definition), esboçando um esquema para descrever dados semi-estruturados e extensíveis. Ficando a informação organizada em um arquivo de forma hierárquica, podendo ser estendida conforme o domínio do problema.

Isso proporciona uma dinâmica na arquitetura, baseando-se nos padrões descrito acima, que impulsiona todo o potencial deste modelo, ao atacar um dos principais pontos fracos dos sistemas distribuídos: a interoperabilidade entre as aplicações, independente de sistemas opera-cionais, linguagens de programação, modelos e ambientes proprietários.

37

Os serviços podem ser implementados usando qualquer lingua-gem de programação (Java, C++ ou Visual Basic, por exemplo) e em qualquer plataforma. Um cliente de um serviço Web também pode ser escrito usando qualquer linguagem e em qualquer plataforma. Por e-xemplo, um cliente escrito em Delphi na plataforma Windows pode utilizar informações de um serviço Web escrito em Java na plataforma Linux. O cliente não precisa se preocupar como o serviço foi implemen-tado. Ou seja, os Serviços Web dependem da habilidade das partes para se comunicar mesmo que usem plataformas diferentes [71].

Um serviço Web também poderá ser facilmente localizado na In-ternet, uma vez estando publicado na grande rede e registrado em um catálogo de Serviços Web. A comunicação feita via HTTP também ga-rante que a comunicação entre as aplicações acontecerá mesmo com a presença de firewalls ou proxies, já que a porta default 80 não é nor-malmente bloqueada [71].

Desse modo, a reusabilidade, a interoperabilidade e a facilidade de uso são as grandes vantagens desta tecnologia.

3.3 SERVIÇOS WEB COM QOS

Nesta seção serão apresentadas algumas propostas de especifica-

ção de QoS em Serviços Web, linguagens de especificação de atributos não funcionais de um SLA e a uma proposta de descoberta e seleção de Serviços Web com QoS.

3.3.1 PROPOSTAS DE QOS EM SERVIÇOS WEB

Embora não existindo um padrão universalmente aceito para es-

pecificar a QoS, nem mesmo uma lista de parâmetros de qualidade, algumas propostas foram publicadas na tentativa de especificar a QoS através de uma lista de parâmetros [27], [72]. Tais propostas apresentam um conjunto de parâmetros de qualidade de desempenho de rede, tais como atraso, variação de atraso, taxa de perda de pacotes.

De acordo com [13], “uma lista pré-definida de parâmetros de qualidade ao nível de rede não é uma solução geral para especificar a QoS. Idealmente, estas soluções deveriam permitir a especificação de QoS com transparência de parâmetros de qualidade usados. Desta for-ma, diferentes parâmetros de QoS poderiam ser usados de acordo com o propósito dos clientes, usuários e provedores de serviço. Com isto, os clientes e usuários poderiam adotar parâmetros de QoS quantitativos e

38

qualitativos, nos mais diversos níveis, como parâmetros de qualidade percebida, de aplicação e mesmo do nível de rede” [13].

3.3.2 LINGUAGENS DE ESPECIFICAÇÃO DE ACORDO DE NÍVEL DE SERVI-

ÇO Existem diversas propostas de linguagens de especificação de a-

cordo de nível para Serviços Web, tais como HQML [73], QML (QOS Modelling Language) [74], SLAng [75], WSLA (Services Web Level Agreement) [76], [77], [78], WSML (Services Web Modeling Language) [79], WS-Agreement [80]) e WSOL (Web Service Offering Language) [81].

Tanto a linguagem WSLA quanto a WSML foram concebidas pa-ra promover a negociação personalizada de SLA (Service Level Agree-ments). A linguagem WSOL é utilizada para fazer a descrição dos servi-ços oferecidos, em XML. Na Figura 3 pode-se ter uma idéia do uso das linguagens. Nas etapas 2, 5 e 6.

A WSLA abrange acordos personalizados entre um provedor e um consumidor em um ambiente de Serviços Web. No acordo são defi-nidas as obrigações das partes envolvidas, as características do serviço; parâmetros; níveis; obrigações; compensação apropriada para o caso de violações dos níveis de serviços. A obrigação de um provedor consiste em executar um serviço conforme garantias consentidas para parâmetros do serviço no nível técnico, tais como tempo de resposta, disponibilida-de e taxa de serviço [78].

O framework WSLA consiste em uma linguagem flexível e ex-tensível baseado em esquema de XML e uma arquitetura baseada em tempo de execução. A linguagem permite a definição de garantias de qualidade para Serviços Web. A arquitetura provê mecanismos para verificar atributos de serviços de acordo com uma especificação WSLA [78].

A linguagem WSDL é um formato para descrever a funcionalida-de abstrata de um serviço Web e os detalhes de uma descrição de servi-ço. Um documento WSLA é referência de um documento WSDL e complementa a definição de serviço com informações para a gerência de SLAs. Enquanto uma descrição de serviço, por exemplo, em WSDL define uma interface de serviço Web, a especificação de WSLA define o acordo em características de desempenho, o modo de avaliar e medir. Assim, WSLA complementa a linguagem de descrição de serviço, como WSDL.

39

A WSML (Web Service Modeling Language) é uma linguagem para especificação de ontologias e diferentes aspectos de Serviços Web. Ela provê uma sintática e uma semântica para a linguagem WSMO (Web Service Modeling Ontology) [82].

Embora WSLA e WSML promovam um conceito de negociação individual e personalizada, uma investigação tem desenvolvido uma noção de prestação de diversas classes de Serviço, para um único servi-ço, que diferem entre si em nível de QoS e gerenciamento, bem como uma relação de preços. Diferentes classes de serviços são formalmente descritas na linguagem WSOL [81].

A partir da combinação das informações contidas no SLA, descri-tas nos perfis de usuário, rede e SLA, e das informações dos perfis de serviço, são definidos os serviços necessários para a execução de uma determinada aplicação. Para auxiliar na determinação do serviço neces-sário, os perfis de serviço podem conter regras especificadas em SWRL [21]. Essa abordagem permite que os componentes responsáveis pela negociação dinâmica com QoS sejam independentes das variações pro-vocadas pelas mudanças e inclusões de novos serviços e regras.

3.3.3 DESCOBERTA E SELEÇÃO DE SERVIÇOS WEB COM QOS

Uma proposta para a descoberta e seleção de serviços com QoS é

apresentada em [83] e ilustrada na Figura 3. A seguir são descritas as etapas de acordo com a publicação dos autores [83]:

• O provedor de serviços publica seus serviços nos registros do UDDI. Os serviços disponíveis no UDDI são identificados atra-vés de uma interface única;

• Os clientes perguntam ao Agenciador (WSB – Web Service Broker – este tem o propósito de acelerar a pesquisa) sobre os serviços que implementam uma determinada interface e aten-dem os requisitos necessários de QoS;

• Se o WSB não possui os recursos sobre as exigências solicita-das pelos clientes, o WSB irá solicitar ao UDDI os Serviços Web de acordo com a chave da interface de um ou mais regis-tros UDDI;

• Os registros UDDI retornam uma lista de serviços que imple-mentam a chave da interface;

• O WSB pede ao provedor de serviços descrições desses servi-ços com requisitos de QoS, por exemplo, arquivos em WSDL;

• Os provedores retornam as suas descrições com QoS oferecida;

40

• O WSB compara a qualidade oferecida pelo serviço contra a qualidade requisitada pelo usuário;

• O WSB retorna o serviço mais adequado para o cliente, depois da comparação efetuada no passo 7;

• O cliente invoca diretamente o serviço com os requisitos de QoS solicitados. Neste momento, os requisitos de QoS relativos ao desempenho da rede são mapeados sobre a tecnologia de transporte.

Figura 3. Descoberta dos Serviços Web com QoS. Fonte: [83].

3.4 SERVIÇOS WEB SEMÂNTICOS

A Web semântica proposta por Berners–Lee [84] é uma evolução

da Web atual, cujo o objetivo consiste em dar significado semântico aos dados armazenados nos servidores e páginas Web, de forma que os mesmos possam ser processados e interpretados tanto por agentes de software quanto por humanos.

A Web semântica só é possível graças ao uso de ontologias, pois elas fornecem o vocabulário necessário para definir a estrutura e a se-mântica de documentos, de forma que possam ser compreendidos pelas máquinas, possibilitando pesquisas inteligentes na Web. A ontologia também permite o compartilhamento do conhecimento de um domínio que pode ser partilhado entre pessoas e aplicações.

O objetivo desta seção consiste em descrever os serviços Web semânticos e as linguagens propostas para dar significado semântico aos serviços Web.

41

3.4.1 ONTOLOGIA

O termo ontologia, segundo descrito em [85], “é uma especifica-

ção formal explícita de uma conceitualização compartilhada”, onde: • Conceitualização: modelo abstrato de algum fenômeno do

mundo, cujos conceitos foram identificados como relevan-tes para aquele fenômeno. Ou ainda, uma estruturação da realidade da forma como ela é percebida e organizada por um agente, independente do vocabulário utilizado.

• Explícita: significa dizer que o conjunto de conceitos utili-zados e as restrições aplicadas são, previamente e explici-tamente, definidos.

• Formal: espera-se que uma ontologia seja processável por um computador, o que exclui definições em linguagem na-tural, por exemplo. Ou seja, refere-se ao fato de que a onto-logia passa ser manipulada ou processada.

• Compartilhada: descreve um conhecimento consensual, que é utilizado por mais de um indivíduo e aceito por um grupo ou comunidades.

Uma ontologia possui as propriedades de compartilhamento, ou seja, o entendimento sobre conceitos para comunicação entre agentes e a filtragem de modelos de abstração, onde uma ontologia define o que deveria ser extraído de um sistema.

Uma ontologia é composta por cinco diferentes tipos de compo-nentes, conforme segue:

• Classes: define os conceitos do domínio ou tarefas, geral-mente organizados em taxonomias. Em uma ontologia uni-versitária: estudante e professor são duas classes, por e-xemplo.

• Relações: um tipo de interação entre conceitos do domínio, exemplos: subclass-of, is-a, io.

• Funções: caso especial de relações onde o n-ésimo elemen-to é único para os n-1 elementos precedentes. Exemplo: preço de um carro usado.

• Axiomas: são sentenças verdadeiras, como por exemplo, se um estudante está matriculado na disciplina X e Y é pré-requisito de X, então o aluno já cursou Y.

• Instâncias: representam elementos específicos. Exemplo: o estudante João é uma instância da classe Estudante.

42

Com o propósito de integrar a Web Semântica aos Serviços Web, foram desenvolvidas novas linguagens para descrição e composição de serviços, mostradas na Figura 4 [86]. Essa integração ainda está em curso, e as atuais extensões semânticas do UDDI [87], [88] não garan-tem a compatibilidade e performance necessárias.

Figura 4. Evolução das tecnologias Web. Fonte: [86].

De acordo com [89], o atual padrão WSDL opera em nível sintá-

tico faltando a semântica para representar as necessidades e capacidades dos Serviços Web. A semântica pode melhorar a reusabilidade do soft-ware e descoberta, facilitar significativamente a composição de serviços da Web e permitir a integração das aplicações legadas como parte do processo de integração.

O documento de Serviços Web Semânticos define um mecanismo para associar anotações semânticas com serviços da Web que são descri-tos utilizando WSDL. Os tipos de informações semânticas que são úteis em descrever um Serviços Web englobam os conceitos definidos pela comunidade Web Semântica em OWL-S [90] e outros esforços [91], [92].

O uso de Serviços Web em conjunto com as tecnologias da Web semântica tem gerado interesse de pesquisa nessa área, por parte da comunidade científica. O objetivo das pesquisas é desenvolver Serviços Web Semânticos (WSDL-S), conforme [93], que possam solucionar alguns dos problemas advindos das tecnologias para Serviços Web (WSDL, SOAP, UDDI). Um exemplo destes problemas é a falta de informação semântica, que, por exemplo, torna o processo de descoberta e invocação de Serviços Web um processo manual. A partir da integra-ção dos Serviços Web com a Web Semântica, os provedores de serviços poderão se beneficiar dessa integração ao anotarem semanticamente seus serviços, com alguma linguagem de marcação semântica, o que possibilitará aos agentes de software: descobrir, selecionar e executar Serviços Web de forma automática.

43

Nas seções seguintes serão abordas as principais linguagens para criação e especificação de ontologias e metadados.

3.4.2 LINGUAGENS PARA ESPECIFICAÇÃO DE METADADOS

Para especificar metadados na Web, em geral são usadas as lin-

guagens RDF (Resource Definition Framework) [94] e suas duas especi-ficações: RDF MSS (Model and Syntax Specification) [94] e RDF S-chema [95], todas baseadas em XML (eXtensible Markup Language).

A RDF é uma aplicação XML recomendada pelo W3C para codi-ficar, fazer o intercâmbio e reutilizar metadados normalizados. Em ou-tras palavras, RDF é um vocabulário XML para descrever recursos da Internet e que fornece um mecanismo para organizar, descrever e nave-gar em Web sites. Seu propósito é permitir a interoperabilidade entre aplicações.

A RDF é desenhado para facilitar ao software perceber o sufici-ente sobre um Website, de modo que possa descobrir recursos, catalogar o conteúdo do site, escalonar esse conteúdo, perceber que possui o con-teúdo e sob que termos e a que preço este pode ser usado [94].

Um statement RDF faz declarações sobre recursos contidos em uma classe, usando uma propriedade e tendo com resultado da aplicação dessa propriedade ao recurso, um valor. Um statement pode ser visto como uma tripla composta por três elementos: recurso (sujeito), propri-edade (predicado) e valor (objeto). Um recurso pode ser qualquer coisa identificável por um URI (Uniform Resource Identifier) [96].

O parser (analisador) RDF é responsável por ler, verificar a sin-taxe RDF, transformar o código escrito na sintaxe RDF num conjunto de triplas e, eventualmente, num grafo RDF. Este último não passa de uma representação gráfica desse conjunto de triplas: um grafo em que cada propriedade, ou predicado, é representado por um arco. Os sujeitos e os objetos que, sendo recursos, podem também ser sujeitos de outra propri-edade.

O RDF está dividido em duas partes, compreendendo duas espe-cificações diferentes:

• O RDF MSS (Model and Syntax Specification) que é uma re-comendação do W3C e que apresenta um modelo para repre-sentar metadados RDF, assim como uma sintaxe para codificar e transportar metadados de uma forma que maximize a intero-perabilidade de servidores e clientes Web desenvolvidos inde-pendentemente [94];

44

• O RDF Schema Specification [95] que é uma especificação candidata do W3C desde 2000 e que define uma linguagem de especificação de esquemas.

Com o RDF Schema, podem-se desenhar e implementar de uma forma consistente, vocabulários de metadados específicos. Estes podem, ainda, ser mais desenvolvidos no seio de outros projetos gerando, assim, uma rede de esquemas de metadados.

3.4.3 LINGUAGENS PARA CRIAÇÃO DE ONTOLOGIAS

A Web Semântica tem sido desenvolvida através de iniciativas de

desenvolvimento de linguagens de marcação que permitem a construção de ontologias.

Para a construção das ontologias é necessário o uso de linguagens que representem o conhecimento e a semântica das informações na Web, possibilitando a troca de dados entre ambientes heterogêneos. As linguagens utilizadas para construção de ontologias são, em geral, divi-didas em dois grupos:

• as linguagens baseadas em uma lógica de primeira ordem: Loom, Ontolingua, OCML, F-Logic.

• as linguagens para aplicações da Web semântica baseadas em XML (eXtensible Markup Language): XOL, OML, O-IL, DAM+OIL, OWL e baseadas em HTML (Hyper Text Markup Language): SHOE.

3.4.3.1 LINGUAGENS BASEADAS EM LÓGICA DE PRIMEIRA ORDEM

As linguagens baseadas em lógica de primeira ordem são usadas

principalmente para representação do conhecimento, sendo que algumas delas foram desenvolvidas a partir da adaptação de linguagens já exis-tentes para esta finalidade e outras foram desenvolvidas especificamente para construção de ontologias [97].

A seguir, são apresentadas as linguagens baseadas em lógica de primeira ordem.

3.4.3.1.1. LOOM

A Loom provê uma linguagem e um ambiente para a construção

de aplicações inteligentes, desenvolvida pelo ISI (Information Sciences Institute - University of Southern California) [98]. A mesma foi projeta-

45

da para trabalhar com sistema de representação do conhecimento, usado para prover suporte conclusivo para a parte declarativa da linguagem, constituída por definições, regras definidas pela aplicação, regras defini-das de forma padrão e fatos. Loom contempla:

Um mecanismo dedutivo, chamado classificador, que usa proibi-ções, unificações semânticas e tecnologia orientada a objetos com o objetivo de compilar o conhecimento declarativo inserido em uma rede projetada para sustentar de forma eficiente a dedução on-line de proce-dimentos de consulta.

A representação de conceitos, taxonomias, relações n-árias, fun-ções, axiomas e regras de produção.

Um raciocínio limitado a classificações automáticas (taxonomias podem ser criadas automaticamente para a definição de conceitos), che-cagem de consistência e execução de regras de produção.

3.4.3.1.2. ONTOLINGUA

A Ontolingua [99] consiste de uma linguagem e um ambiente co-

laborativo para navegação, criação, edição e uso de ontologias, foi de-senvolvida pelo KSL (Knowledge Systems Laboratory – Stanford Uni-versity), sua sintaxe e semântica foram desenvolvidas com base na lin-guagem KIF (Knowledge Interchange Format). KIF é uma linguagem formal para troca de conhecimento entre sistemas computacionais muito diferentes.

A ontolíngua é compatível com múltiplas linguagens de represen-tação, provendo suporte para definição de classes, relações, funções, objetos e teorias. Faz a conversão de ontologias para diferentes forma-tos, tais como COBOL, IDL, ORB etc. Traduz definições escritas em uma linguagem declarativa em formas que são aceitas para entrada de dados em diversos sistemas de representação do conhecimento.

É uma linguagem com desenvolvimento compartilhado de onto-logias, ou seja, as ontologias construídas na Ontolingua podem ser com-partilhadas por múltiplos usuários e grupos de pesquisa, cada um usando seu próprio sistema de representação.

3.4.3.1.3. OCML

A Operational Conceptual Modelling Language (OCML) [100] é

uma linguagem de modelagem desenvolvida pelo KMI (Knowledge Media Institute – Open University). Possui muita similaridade com a

46

Ontolingua, porém apresenta componentes adicionais a esta, que são: regras dedutivas e de produção e definições operacionais para funções.

A OCML permite especificação e operacionalização de funções, relações, classes, instâncias e regras, além de apresentar uma poderosa checagem de restrições, que podem checar restrições de tipo e de cardi-nalidade, associadas às relações, slots (relações) e classes.

3.4.3.1.4. F-LOGIC

A Frame Logic (F-logic) foi desenvolvida na Universidade de

Karlsruhe na Alemanha, integra frames em primeira ordem e cálculo de predicados, sustentando o mesmo relacionamento para o paradigma de orientação a objetos que o cálculo de predicados mantém para a progra-mação relacional.

A F-logic é um formalismo lógico que descreve, de maneira lim-pa e declarativa, os mais diversos aspectos estruturais de linguagens baseadas em frames e orientadas a objetos, usados na representação do conhecimento e dados. Além disso, é adequado para a definição, execu-ção de consultas e manipulação de esquemas de bancos de dados [101].

As principais características incluem: identidade de objetos, obje-tos complexos, métodos para consulta, classes, herança, polimorfismo, encapsulamento, entre outros. Através desta linguagem é possível a representação de conceitos, taxonomias, relações binárias, funções, axi-omas, instâncias e regras dedutivas.

3.4.3.2 LINGUAGENS BASEADAS EM HTML E XML PARA APLICAÇÕES

DA WEB SEMÂNTICA A seguir serão apresentadas as linguagens usadas especialmente

em ambientes Web, tendo impacto principal sobre aplicações da Web Semântica. A linguagem SHOE tem sua sintaxe baseada em HTML, todas as demais linguagens listadas abaixo, possuem sintaxe baseada em XML e são adotadas como linguagens padrão para troca de informações na Web.

3.4.3.2.1. SHOE

A linguagem Simple HTML Ontology Extensions (SHOE) [102] é

uma extensão do HTML, compatível com XML, criada para incorporar conteúdo com informação semântica legível pelas máquinas e nos do-cumentos encontrados na Web através de anotações em páginas HTML.

47

A linguagem SHOE inclui um mecanismo de definição de onto-logias, instâncias de dados em páginas Web e de classificação hierárqui-ca de documentos HTML. Isto é feito a partir de classes e regras de restrições que especificam relacionamentos e hierarquias entre instân-cias, a partir de um conjunto de tags acrescidos ao HTML padrão. SHOE dispõe de primitivas de modelagem tanto para especificar quanto para entender ontologias. Cada página declara quais ontologias são utili-zadas, o que torna possível a realização de buscas mais inteligentes. SHOE permite a representação de categorias (classes), relações n-árias, regras de inferências e regras para a especificação das ontologias [103].

3.4.3.2.2. XOL

A Ontology Exchange Language (XOL) [104] foi desenvolvida

pelo SRI International (Stanford Research Institute), criada inicialmente para intercambiar ontologias na área de bioinformática. Foi realizado um estudo que concluiu que nenhuma ontologia existente satisfazia as exi-gências da área da bioinformática. O grupo precisava de uma linguagem semântica que fosse orientada a objetos para representar o conhecimento e que tivesse uma sintaxe XML.

3.4.3.2.3. OML

Ontology Markup Language (OML) é uma linguagem de especi-

ficação de ontologias baseada em lógica descritiva e grafos conceituais. A OML permite a representação de conceitos organizados em taxono-mias, relações e axiomas em lógica de primeira ordem. [105].

3.4.3.2.4. OIL

A Ontology Inference Layer (OIL) é uma linguagem que teve o-

rigem no projeto On-To-Knowledge. Foi criada com o objetivo de repre-sentar e intercambiar ontologias. É compatível com os padrões do W3C, inclui XML, RDF e as primitivas de modelagem de RDFSchema. As aplicações que suportam apenas RDF podem entender, pelo menos par-cialmente, um documento OIL. A especificação completa dessa lingua-gem pode ser consultada em [106]. A OIL é estruturada através de três tecnologias, segundo [72]:

• Lógica descritiva: provê suporte eficiente para raciocínio e se-mântica formal;

48

• Sistema Baseados em Frames: usa primitivas definidas pela OKBC (Open Knowledge Base Connectivity);

• Linguagens da Web: relaciona dados semi-estruturados e os pa-drões do modelo RDF para integração e troca de informações.

Para a criação de ontologias, a OIL provê definições para classes e slots e um conjunto limitado de axiomas e as ontologias são descritas através de três camadas [107]:

• Nível de objeto: para instâncias concretas; • Primeiro meta nível: para definições ontológicas; • Segundo meta nível: para descrever as características da onto-

logia.

3.4.3.2.5. DAML+OIL As linguagens OIL e DAML deram origem à linguagem DA-

ML+OIL, uma nova proposta do consórcio W3C, para servir como pon-to de partida para as atividades da Web Semântica quanto à definição da Ontology Web Language (OWL), para a representação de ontologias e metadados e que inclui inúmeras construções novas (primitivas para a Web Semântica), que aumentaram bastante o poder da linguagem [72].

A criação da DAML+OIL foi motivada pelo fato da XML não conseguir expressar as relações existentes entre os conceitos representa-dos nos seus documentos. Através da união das linguagens DAML e OIL, surge a DAML+OIL [108]. A mesma foi desenvolvida em con-formidade com os padrões de linguagens estabelecidos pela W3C pelo US-American/European Committee no contexto da DAML, um projeto da DARPA (Defense Advanced Research Project Agency).

Existem várias diferenças entre as linguagens OIL e DA-ML+OIL. Elas existem principalmente devido ao fato de que DA-ML+OIL foi baseada em RDF. Assim, algumas construções em RDF são possíveis em DAML+OIL, mas não em OIL. A DAML+OIL provê primitivas de modelagens mais ricas, comumente encontradas na lógica descritiva [103].

As idéias das partes baseadas em frames da OIL foram retiradas e as asserções (afirmações) são feitas em termos de um conjunto limitado de axiomas. Como resultado a linguagem trabalha melhor como uma plataforma para entrega de ontologias que o RDF, mas tem limitações como uma linguagem para o desenvolvimento de ontologias, por causa da remoção das construções baseadas em frames [103].

49

A DAML+OIL substitui a OIL e acrescenta algumas característi-cas [72]:

• Introduz os tipos de dados do XML Schema tais como inteiros, cadeias (strings) e reais. Propriedades são diferenciadas em du-as classes disjuntas: propriedades do objeto (object properties) cujo valor é uma instância de uma classe e propriedades de tipo de dados (data-type properties), cujo valor é uma instância dos tipos de dados do XML Schema;

• A possibilidade de importar explicitamente outra ontologia DAML+OIL, contendo definições que se aplicam à ontologia DAML+OIL atual;

• Definir enumerações. Segundo descrito em [72] a DAML+OIL usa a sintaxe da RDF, é

considerada como uma extensão de RDF Schema, devido ao acréscimo de propriedades de OIL.

As principais características da DAML+OIL estão descritas em [109] e [110]. Entretanto, por basear-se no RDS Schema alguns aspectos de semântica não puderam ser reconciliados com o DAML+OIL. Tam-bém falta ao DAML+OIL uma teoria padrão para inferências, sendo então definida a linguagem OWL.

3.4.3.2.6. OWL

A Web Ontology Language é a linguagem que foi criada pelo

grupo de trabalho Web-Ontology da W3C, com o objetivo de construir uma nova linguagem de marcação de ontologias para a Web Semântica. Ela é baseada nas linguagens OIL e DALM-OIL e desde fevereiro de 2004 é a considerada a linguagem padrão para especificação de ontolo-gia segundo a W3C [110].

A OWL permite descrever conceitos de um domínio de aplicação e a relação entre conceitos através de vários conjuntos de operadores. É baseada em modelo de lógica que torna possível que os conceitos sejam descritos e bem definidos e permite que motores de inferência verifi-quem se as declarações e as definições da ontologia são mutuamente consistentes e ajuda manter a hierarquia corretamente.

A OWL provê mais facilidades para expressar significados e se-mântica, superando XML, RDF e também RDFS em razão de fornecer vocabulário adicional com uma semântica formal [111]. Tais facilidades ocorrem pelo motivo da OWL utilizar uma lógica explícita para a lin-guagem. Essa lógica é baseada em Lógicas de Descrição, que consistem

50

de uma família de lógicas que são fragmentos, descendentes da lógica de primeira ordem.

Para atender aos requisitos da linguagem, descritos em profundi-dade por [112], foram criadas três linguagens, de acordo com sua ex-pressividade [113]:

OWL Lite: abrange a expressividade de frames e lógica de descri-ção com algumas restrições. Por exemplo, a cardinalidade máxima ou mínima assume apenas os valores 0 ou 1. Apesar disso, a linguagem é dotada de riqueza semântica, sendo, por isto, ideal para usuários inician-tes e desenvolvedores que preferem frames à lógica de descrição. Traba-lha hierarquia de classes e simples restrições.

OWL DL: garante completude, decidibilidade e toda a expressivi-dade da lógica de descrições, almejando satisfazer engenheiros de co-nhecimento familiarizados com esta tecnologia. Classes podem ser cons-truídas por união, interseção e complemento, pela enumeração de ins-tâncias e podem ter disjunções. Tipos são mantidos cuidadosamente separados (por exemplo, uma classe não pode ser instância e proprieda-de ao mesmo tempo).

OWL Full: fornece a expressividade de OWL e a liberdade de u-sar RDF, inclusive permitindo novas metaclasses, já que elas são sub-classes definidas em RDF Schema. Fazendo uso mais complexo, não há garantia de computabilidade com isso, há dificuldade de implementar software de “raciocínio” e inferência.

Uma ontologia criada em OWL é composta por três componen-tes:

• Classes: equivalente a uma concreta representação de termos. Além disso, elas representam um conjunto de indivíduos;

• Propriedades: equivalente a relações binárias individuais; • Indivíduos: representam objetos em um domínio particular que

foi formalizado e é referenciado como instâncias de classes. A linguagem OWL é construída sobre o RDF e RDF Schema e u-

tiliza a sintaxe baseada em RDF/XML. Como o RDF/XML não tem uma sintaxe legível, outras formas sintáticas foram definidas [72]:

• Uma sintaxe baseada em XML que não segue as convenções do RDF e é mais legível por humanos;

• Uma sintaxe abstrata mais compacta e legível que a sintaxe XML ou a sintaxe RDF/XML;

• Uma sintaxe gráfica baseada nas convenções do UML (Unified Modeling Language).

51

3.4.4 ONTOLOGIAS PARA DESCRIÇÃO DE SERVIÇOS WEB SEMÂNTICOS Os serviços Web descritos WSDL não possuem informações se-

mânticas, no entanto estas informações são primordiais para descoberta, invocação e composição automática de serviços. Como proposta, tem-se a OWL-S.

3.4.4.1 OWL –S

OWL–S (Semantic Markup for Serviços Web) [90] é uma lingua-

gem de descrição de Serviços Web, que une a WSDL com a informação semântica do OWL, sendo organizada em três módulos: Profile; Process Model e Grounding.

O Profile [86] descreve as capacidades e características adicio-nais de Serviços Web, com base nas transformações que esses serviços produzem, auxiliando na decisão do requisitante quando este utiliza um determinado serviço Web.

O Process Model [86] especifica o protocolo de interação, que possibilita ao requisitante saber, num dado momento da transação, que informação enviar e receber do fornecedor. Esse módulo distingue dois tipos de processos: atômicos e compostos. Os atômicos fornecem des-crições abstratas das informações trocadas com os requisitantes, corres-pondendo às operações que o fornecedor pode executar diretamente. Os compostos são usados para descrever coleções de processos (atômicos ou compostos), organizados através de algum tipo de estrutura de con-trole de fluxo.

O Grounding [86] descreve como processos atômicos são trans-formados em mensagens concretas, de modo que possam ser trocados via rede ou através de uma chamada de procedimento. É definido como um mapeamento “um para um” de processos atômicos para a especifica-ção de descrições WSDL.

3.4.5 ONTOLOGIAS DE QOS PARA SERVIÇOS WEB SEMÂNTICOS

Para a definição de uma solução de gerenciamento de QoS na

Web semântica é necessária a adoção de uma ontologia de QoS. As duas principais propostas de ontologia de QoS são a QoSOnt [17] e a OWL-QoS [18] (antes conhecida por DAML-QoS) [114]. Ambas foram de-senvolvidas a partir da OWL-S. Além dessas duas propostas, uma nova ontologia para especificação semântica de Qos em redes de computado-res, a NetQoSOnt, foi desenvolvida [13].

52

A NetQoSOnt [13] é uma ontologia de QoS orientada a especifi-cação de QoS. Faz uso de uma lista extensível de parâmetros de QoS em qualquer nível dos serviços de redes. A ontologia permite especificar os parâmetros de QoS e métricas; especificar relacionamentos entre parâ-metros e métricas; interpretar automaticamente os parâmetros realizando comparações de maneira automática.

A OWL-QoS [18] foi concebida para a descoberta e medição de serviços, definindo parâmetros de desempenho de Serviços Web semân-ticos, e é divida em três camadas. A camada Perfil de QoS é utilizada para definir e possibilitar comparações entre os perfis de QoS. A camada Propriedades de QoS é utilizada para definir as propriedades em si, seus domínios e restrições de alcance. E a camada Métricas de QoS é utiliza-da para definição e medição de métricas. Existe um mecanismo especí-fico, desenvolvido na própria ontologia, utilizado para a comparação dos parâmetros de desempenho. Existem algumas limitações constatadas nessa ontologia. A de maior relevância, em conformidade com a propos-ta apresentada nessa dissertação, é o fato não se ter condições de mode-lar valores de limite para os parâmetros de QoS.

A QoSOnt [17] concentra definições de métricas e os mecanis-mos que permitem a conversão de diferentes unidades de medidas de QoS, para Serviços Web semânticos. Assim como a OWL-QoS, a Qo-SOnt foi desenvolvida usando a versão 1.0 da OWL. Nessa ontologia fala-se em um algoritmo usado para realizar a comparação dos parâme-tros de desempenho, mas na realidade isso não fica claro na proposta. O fato de usarem a versão 1.0 da OWL, segundo os autores do trabalho, pode ser contornado com o uso do XML, mas isso também não é expos-to de maneira que se possa ter um entendimento claro sobre a validade dessas informações.

3.4.6 LINGUAGEM BASEADA EM REGRAS - SWRL

As linguagens baseadas em regras tiveram a iniciativa centrada

em uma linguagem de marcação baseada em XML. O XML pode ser utilizado para vários tipos de regras, como por exemplo, negócios e conversões, como apresentado nas seções anteriores.

O Semantic Web Rule Language (SWRL) se tornou um padrão do W3C quando foi apresentada no ano de 2004. Combinando um trabalho desenvolvido pela DARPA Agent Markup Language (DAML) e pela linguagem RuleML. A linguagem foi submetida ao W3C no final de 2005.

53

É uma linguagem baseada na OWL. Ela permite escrever regras para raciocínio onde se infere um novo conhecimento. Usando a OWL podemos, por exemplo, utilizar alguns valores disponíveis através de medições na rede, feitas pelo provedor, numa ontologia e as suas instân-cias.

Porém como toda linguagem, a SWRL possui limitações [21]: quando se tem um elevado número de características, as regras se tor-nam longas e difíceis de entender e gerenciar. Além do que, operações matemáticas complexas, como integrais, por exemplo, não são suporta-das pela linguagem. Existem maneiras de solucionar esse problema usando outras linguagens matemáticas associadas com a SWRL, como por exemplo, o OpenMath juntamente com o MathML, neste caso usa-se sintaxe, de acordo com a linguagem de programação, para se traba-lhar com a SWRL.

Uma regra SWRL contém um antecedente que é igual ao corpo e um conseqüente que é igual a cabeça. Exemplo: o céu está nublado e a meteorologia prevê chuva (corpo ou antecedente). Então usa-se galocha e leva-se guarda-chuva (conseqüente). Tanto o antecedente quanto o conseqüente possuem conjunções positivas de átomos representadas pelo símbolo "?". Se todos os átomos no corpo são verdadeiros, então todos os átomos na cabeça também são verdadeiros.

A SWRL trabalha com built-ins, que são métodos definidos para serem usados, nas sintaxes, em regras. Os métodos contêm um conjunto de operadores matemáticos e rotinas para manipulação de strings e da-dos. O prefixo convencional da SWRL é swrlb.

Nessa dissertação a SWRL foi utilizada para representar as regras de mapeamento localizadas dentro de indivíduos, que estão organizados na ontologia da organização e da NSP.


Baseando-se na realização dos estudos apresentados, pesquisou-

se o uso de ontologias para descrever características no contexto da negociação dinâmica de QoS para serviços de comunicação, concen-trando-se na solução de problemas relacionados com uma abordagem semântica.

O uso da tecnologia de Serviços Web oferece uma solução consis-tente, com uma grande quantidade de ferramentas e padrões bem defini-dos. Além disso, o uso de ontologias e a incorporação de semântica em seus padrões possibilitam uma interessante migração das atuais soluções

54

proprietárias, de descoberta e composição de serviços, para uma arquite-tura distribuída baseada na Web semântica.

Ainda nesse capítulo foram abordadas as principais linguagens usadas para a criação de ontologias, pois para a construção das mesmas é necessário o uso de linguagens que representem o conhecimento e a semântica das informações em documentos que podem ser relacionados entre ambientes heterogêneos.

Segundo a W3C, a OWL é a linguagem padrão para especifica-ção de ontologia pelo fato da mesma prover maior facilidade para ex-pressar significados e semântica, superando XML, RDF e RDFS, pois fornece um vocabulário adicional com uma semântica formal. As onto-logias propostas nesta dissertação são criadas usando OWL 2.0.

A SWRL, combinada com o RuleML, permite escrever regras pa-ra raciocínio onde se infere um novo conhecimento. Nessa dissertação as regras são descritas em sintaxes SWRL e interpretadas por uma espé-cie de compilador de regras feito em Java, especificamente para a versão 2.0 da linguagem e especialmente para as regras definidas nesse traba-lho. No entanto, as regras funcionam de maneira genérica, procurando manter os conceitos usados no vocabulário de cada organização, de-monstrando a flexibilidade da ontologia e do aplicativo Java.

55

4. NETQOSONT Essa dissertação faz uma abordagem semântica para o mapea-

mento de QoE e QoS, analisando a NetQoSOnt e mostrando a possibili-dade de especificação de parâmetros de QoE e QoS em níveis diferentes, mas que representam o mesmo conceito.

A ontologia NetQoSOnt [13] é uma ontologia de QoS onde é permitido que se desenvolvam operações de gerenciamento de QoS, tais como seleção de serviços, negociação/monitoramento de SLA e invoca-ção de serviços.

Este capítulo revisa os principais conceitos da NetQoSOnt.

4.1 MÓDULOS DA ONTOLOGIA A Figura 5 apresenta os módulos da NetQoSOnt. Como visto nes-

ta figura, a NetQoSOnt está organizada em módulos separados para as camadas da pilha TCP/IP. A idéia da utilização em camadas é a questão do mapeamento entre parâmetros dependentes ou independentes de tecnologia.

Figura 5. Módulos da NetQoSOnt. Fonte: [13].

56

4.1.1 MÓDULO BASE

O módulo Base é constituído de alguns conceitos de base, que

fornecem recursos genéricos a serem reutilizados nos outros módulos. O conceito Layer identifica uma camada, permitindo organizar os concei-tos e a extensão do modelo proposto através da adição de novas cama-das, usadas para mapear novos conceitos dependentes de tecnologia. Os conceitos Address e Field são usados, respectivamente, para identificar uma entidade de rede e um campo de um protocolo qualquer.

O conceito Parameter é a base para especificação de QoS. QoSS-pec define a especificação de QoS e é usado para descrever, por exem-plo,uma classe de serviço de um provedor na Camada de Internet ou os requisitos de um usuário na Camada do Usuário.

NetQoSOnt utiliza conceitos da MUO (Measurement Units Onto-logy) [115], uma ontologia de unidades criada para representar unidades de medida. Em NetQoSOnt, a diversidade entre as unidades de medida usadas por provedor ou clientes é resolvida com o Measure que é sub-classe de QualityValue, uma classe da MUO.

4.1.2 MÓDULO DA CAMADA DE ENLACE

O Módulo da Camada de Enlace define conceitos relacionados à

camada de enlace da pilha TCP/IP. Os conceitos LinkAddress e MA-CAddress são usados para endereçamento. O LinkPerformanceParame-ter permite a definição de novos parâmetros e os respectivos valores literais. Para definir as especificações de QoS nesta camada deve-se criar subclasses de QoSSpec. Os parâmetros de desempenho do nível de enlace normalmente estão relacionados à tecnologia de enlace e de rede local, sendo assim, uma classe derivada de QoSSpec nessa camada não expressa diretamente qualidade fim a fim.

4.1.3 MÓDULO DA CAMADA INTERNET

O Módulo da Camada de Internet define conceitos relacionados à

camada Internet da pilha TCP/IP. O IPAddress e o InternetAddress des-crevem os endereços na camada de rede. Os parâmetros de qualidade são derivados de InternetPerformanceParameter. Um NSP pode definir suas CoSs criando subclasses de QoSSpec. Ou então um cliente ou usuá-rio pode expressar seus requisitos no momento da negociação ou invo-cação de serviços com QoS.

57

4.1.4 MÓDULO DA CAMADA DE TRANSPORTE

No módulo da Camada de Transporte são definidos conceitos re-

lacionados aos campos de cabeçalho do TCP e UDP. Nenhum parâmetro de QoS do nível de transporte foi definido no momento. De qualquer maneira, a qualidade percebida pelas aplicações é influenciada direta-mente pela qualidade oferecida pelos protocolos da camada de transpor-te (pois a camada de aplicação utiliza o sistema de comunicação via a camada de transporte).

4.1.5 MÓDULOS DA CAMADA DE APLICAÇÃO E USUÁRIO

Os parâmetros de QoS podem ser definidos nos níveis de aplica-

ção e usuário. Os desenvolvedores de aplicações e organizações podem definir novos conceitos para expressar qualidade no nível aplicativo ou de usuário (QoE). As classes derivadas de QoSSpec criadas nestas ca-madas referenciam conceitos das camadas inferiores. Estas classes po-dem especificar QoS quantitativa ou qualitativa e geralmente expressam qualidade fim a fim.

A NetQoSOnt modela a comparação de parâmetros como um problema de herança de conceitos da ontologia. Desse modo, ao usar um motor de inferência e gerar uma hierarquia com os novos conceitos cria-dos um NSP pode descobrir quais de suas CoSs atendem a demanda consultando o motor por quais de suas subclasses de QoSSpec são sub-classes da especialização de QoSSpec que representa o pedido do clien-te.

4.1.6 EQUIVALÊNCIAS ENTRE QOSSPEC

A Figura 6 ilustra como NetQoSOnt especifica equivalências en-

tre especificações de QoS. Este exemplo considera que uma organização de normalização em VoIP define faixas de valores de MOS e a QoS que deve ser atendida ao nível de rede para garantir a qualidade de voz. No exemplo da Figura 6 é apresentado apenas a faixa MOS≥4 e o parâmetro de rede atraso (OWD – One Way Delay). Mas na ontologia que foi de-senvolvida, foram utilizados também os parâmetros variação de atraso e taxa de perda de pacotes.

Usando NetQoSOnt, a organização de normalização poderia pu-blicar a QoSSpec MOS4 (representando MOS≥4) na camada usuário e a QoSSpec MOS4IP na camada de rede, com parâmetro para atraso

58

MOS4OWD. A medida deste atraso é definida em MOS4OWDMeasure como sendo < 15ms (conforme [61]). Para definir a equivalência de QoS entre MOS4 no nível usuário e MOS4IP no nível rede, é usada a relação de equivalência de conceitos em ontologias (equivalence-to).

Figura 6. Equivalência entre QoSSpecs. Fonte: [13].

4.2 CENÁRIO DE USO

Para ilustrar a aplicação de NetQoSOnt, suponha que um usuário

solicite MOS≥3.9 para uma NSP que tenha uma solução de QoS cujo tráfego possa ser mapeado em 3 classes de serviço: CoSA, CoSB e BE. Para utilizar NetQoSOnt, esta NSP deve publicar a qualidade oferecida por estas classes no domínio da provedora. A Figura 6 ilustra a especifi-cação da QoS oferecida pelas classes CoSA e CoSB. Esta figura apresen-ta unicamente o parâmetro atraso (OWD). Considere que a medida deste atraso de CoSA é definida em CoSAOWDMeasure como sendo < 10ms, e analogamente, CoSB possui um atraso CoSBOWD como sendo < 100ms.

59

Como na ontologia não existe ainda definido uma QoSSpec MOS3.9, o sistema proposto por [13], realiza a criação de uma classe MOS3.9. Usando um motor de inferência, as QoSSpec podem classificar hierarquicamente as diversas classes QoSSpec. Este motor de inferência analisa os intervalos definidos pelas subclasses de Measure e como 10 < 15 < 100, infere que CoSAOWDMeasure é subclasse de MOS4OWDMeasure, que por sua vez é subclasse de CoSBOWDMeasu-re. Por conseqüência, é inferido que CoSAOWD é subclasse de MOS4OWD, que por sua vez é subclasse de CoSBOWD. Finalmente, o processo de inferência define que CoSA é subclasse de MOS4IP, que por sua vez é subclasse de CoSB. Desse modo, CoSA é inferido como sendo um conceito mais restrito que MOS4IP e seu equivalente MOS4, o que significa que a oferta de CoSA atende aos requisitos de MOS4 (MOS≥4). De modo análogo, é verificado que MOS4 é subclasse de MOS3.9 (qualidade maior), ou seja, se MOS4 é atendido, MOS3.9 tam-bém é atendido. Assim, consultando o motor de inferência e descobrin-do quais das suas especializações de QoSSpec são subclasses das especi-alizações de QoSSpec do pedido do cliente, o NSP consegue descobrir que CoSA atende a solicitação do usuário.

4.3 ANÁLISE DA NETQOSONT QUANTO AO MAPEAMENTO DE QOE EM

QOS Esta seção analisa a ontologia NetQoSOnt quanto ao mecanismo

de mapeamento de QoE em QoS. Para tal, será utilizado o cenário ilus-trativo da seção 4.2.

A ontologia NetQoSOnt não define regras de mapeamento, e sim relações de equivalências entre especificações de QoS. Isto gera algu-mas limitações que serão explicadas usando o exemplo descrito na seção 4.2.

A primeira limitação é quanto a expressão de mapeamentos entre especificações de QoS para QoE de diferentes níveis. Um exemplo é a relação entre MOS, atraso e perdas definida na Equação 2 (seção 2.5.1). Atualmente, a NetQoSOnt permite especificar certas faixas de MOS, e os valores absolutos de atraso e perdas de pacotes que a rede deve ga-rantir. Mas outras combinações de valores de atraso e perdas de pacotes também poderiam garantir o mesmo MOS.

Usando a NetQoSOnt, uma organização de normalização em QoSSpec uma qualidade subjetiva de MOS4 com valor MOS>=4.0 na camada de Usuário e uma QoSSpec, na camada Internet, MOS4IP com parâmetro de atraso MOS4OWD, definido em Measure como

60

MOS4OWDMeasure<15ms. Para definir a equivalência de QoS entre MOS4 na camada de usuário e MOS4IP na camada de rede, é usada a relação de equivalência de conceitos em ontologias (equivalent-to). Percebe-se que a organização já publicou, previamente, a especificação de QoE e quando um usuário solicita uma outra especificação de QoE, por exemplo MOS>=3.9, como foi apresentado na seção da NetQoSOnt, já existe uma especificação de MOS disponibilizada pela organização que pode atender a esse MOS. Levando em consideração que o provedor publicou as suas CoSs, conforme explicado na seção da NetQoSOnt, a CoSA atende as expectativas do usuário.

A segunda limitação é quanto ao aspecto de otimização de uso de recursos de rede. Como se pode perceber, a especificação do usuário (MOS≥3.9) foi de certo modo classificada em uma das QoSSpec já defi-nidas na ontologia (MOS≥4), o que pode resultar na necessidade de se garantir QoS de rede acima do pretendido pelo usuário.

Através do exemplo é evidenciado a falta de granularidade na NetQoSOnt. Percebe-se que a organização de normalização, previamen-te publica uma solução de QoS com valor definido. Antes mesmo de o usuário solicitar um pedido, já se encontra na ontologia uma resposta a solicitação. Se o usuário pede um parâmetro de QoE MOS com va-lor>=3.9, deve ser criada uma especificação exatamente com esse valor na ontologia da organização. Nota-se então que as solicitações dos usuá-rios são atendidas por CoSs do provedor que deveriam atender a outras especificações, o que se entende por falta de granularidade, por conta da organização.

Percebe-se claramente que isso não é flexível, pois as condições de equivalência de QoS apresentadas pela NetQoSOnt, podem ser me-lhoradas com o efetivo mapeamento.


Este capítulo apresentou a NetQoSOnt, uma ontologia de especi-

ficação de QoS, suas camadas e suas classes, o processo de equivalência entre especificações em diferentes camadas numa arquitetura de rede, e no final foi feita uma análise do que pode ser melhorado na ontologia.

O próximo capítulo aborda a extensão da NetQoSOnt para resol-ver as limitações de recursos de rede e quanto a expressão de mapea-mentos dinâmicos.

61

5. ESTENDENDO A NETQOSONT COM REGRAS DE MAPEAMENTO Motivado pelas limitações da NetQoSOnt apontadas anteriormen-

te, na seção 4.3, a arquitetura da ontologia NetQoSOnt é estendida para permitir o mapeamento dinâmico, em tempo de execução, de especifica-ções de QoS/QoE. A especificação deste mapeamento é feita através de regras SWRL armazenadas em indivíduos na estrutura da ontologia estendida.

A ampliação da ontologia NetQoSOnt apresentada neste trabalho resultou em novos conceitos e indivíduos necessários para descrição formalizada do mapeamento de especificações de QoS, incluindo um novo módulo na ontologia, chamado de Mapeamento de QoS/QoE. Es-tes elementos estão ilustrados na Figura 7, onde, a título ilustrativo, são apresentados apenas conceitos e indivíduos necessários ao mapeamento de QoE/QoS em aplicações VoIP. Por simplificação, esta figura não apresenta alguns dos módulos da NetQoSOnt.

5.1 NOVOS CONCEITOS E INDIVÍDUOS

Em [13] e [116], todas as especificações e requisitos eram classes

especializadas de QoSSpec. A interpretação é diferente na presente pro-posta, onde as especificações de QoS da NSP são representadas por indivíduos e os requisitos de QoS dos usuários são classes. Essa varia-ção foi necessária, pois na SWRL padrão não é possível aplicar regras à classes, somente a indivíduos.

Serão explicados os módulos da camada de Usuário, de Aplica-ção, Internet e de Mapeamento QoS/QoE. Os demais módulos não serão descritos, pois não houveram alterações, permanecendo de acordo com o definido na NetQoSOnt.

5.1.1 MÓDULO DA CAMADA DE USUÁRIO

Na NetQoSOnt, o módulo usuário representa recursos relaciona-

dos à QoE. Em especial, esta camada define UserPerformanceParame-ter, uma especialização do conceito Parameter. A Figura 7 apresenta exemplos de especializações de UserPerformanceParameter na área de VoIP: MOS, RFactor e SubjectiveQuality. O conceito MOS permite que o usuário possa especificar a sua QoE através do método subjetivo MOS. O conceito RFactor permite que o usuário possa especificar a sua QoE através do método subjetivo Fator R. O conceito SubjectiveQuality permite que o usuário possa especificar a sua QoE através do método

62

subjetivo excelente, bom, regular, insatisfatório ou ruim. Ao se especifi-car a QoE, usando um dos parâmetros de performance especificados acima, cada uma das classes MOS, RFactor e SubjectiveQuality relacio-na (mappingTo) a especificação com o indivíduo da camada de mapea-mento que possui a regra específica em SWRL.

5.1.2 MÓDULO DA CAMADA DE APLICAÇÃO

A Figura 7 apresenta dois conceitos no módulo camada de aplica-

ção, que são ApplicationParameter e Codec. ApplicationParameter é uma especialização do conceito Parameter, e Codec é uma especializa-ção de ApplicationParameter que é utilizado para especificar os codecs selecionados pelo usuário em uma aplicação VoIP, por exemplo. Os diversos codecs são representados por indivíduos de Codec. Nesses indivíduos se encontram os valores do campo PayloadType (PT). Os valores são definidos na classe padrão, Measure, usando a propriedade de objeto hasMeasure e a propriedade de dado qualityLiteralvalue . A Tabela 4 apresenta alguns exemplos de valores de PT para os codecs mais utilizados em aplicações de VoIP.

63

Base

Mapeamento de QoS/QoE

Camada de Aplicação

Camada Usuário

Parameter

QoSQoEMapping

RFactorMapping

MOSMapping

SubjectiveQualityMapping

QoStoRfactor-SWRL

QoStoMOS-SWRL

QoStoSubjectveQuality-SWRL

UserPerformanceParameter

MOSRFactorSubjective

Quality

ApplicationParameter

Codec

is-a is-a

is-a

is-a

is-a

is-a

is-a

is-a

is-a

io

io

io

G711

io

mappingTo mappingTo

mappingTo

QoSSpec

CoS is-a

Camada Internet

hasParameter

Figura 7. Ontologia de Especificação de QoE.

5.1.3 MÓDULO DA CAMADA INTERNET

Na camada Internet foi definida uma especialização (is-a) de

QoSSpec chamada CoS (CoS é classe na ontologia). Uma NSP pode representar suas classes de serviço criando indivíduos da QoSSpec CoS. Em cada um destes indivíduos são definidas as garantias de QoS em termos de parâmetros da camada de Internet, como atraso, variação de atraso e taxa de perdas.

Na NetQoSOnt os parâmetros dessa camada são definidos em classes. Foi necassário criar indivíduos para representar os parâmetros atraso, variação de atraso e taxa de perdas porque as regras SWRL exi-gem valores desses parâmetros. Quando as classes são valoradas não se pode extrair o valor delas. A linguagem SWRL só consegue trabalhar com valores expressos em indivíduos.

5.1.4 MAPEAMENTO DE QOS/QOE

64

Na NetQoSOnt original, as relações de equivalência entre especi-ficações de QoS são criadas de forma manual e estáticas, o que torna pouco flexível o uso de equivalência de conceitos em ontologias. No sentido de se ter uma flexibilidade quanto ao mapeamento dos parâme-tros de QoS propõe-se aqui um novo módulo na ontologia NetQoSOnt, chamado módulo de Mapeamento de QoS/QoE, que define formalmente as regras de mapeamento entre QoS/QoE. Estas regras são especificadas usando a linguagem SWRL.

Um novo conceito chamado de QoSQoEMapping é usado para explicitar o mapeamento de especificações de QoS/QoE. Este conceito está relacionado com o conceito Parameter através de uma propriedade de um objeto chamada mappingTo. Essa propriedade relaciona um indi-víduo que contém regras de mapeamento com uma subclasse de Para-meter. Para declarar o mapeamento das especificações de QoS são defi-nidas especializações da classe QoSQoEMapping.

A Figura 7 apresenta três exemplos de especializações de QoS-QoEMapping definindo regras de mapeamento de especificações de QoS em QoE na área de VoIP: RFactorMapping, MOSMapping e Sub-jectiveQualityMapping. Também é definido um indivíduo de cada espe-cialização de QoSQoEMapping. Estes indivíduos mantêm as regras de mapeamento entre especificações QoS/QoE na sintaxe SWRL. Por e-xemplo, para os conceitos MOSMapping, RFactorMapping e Subjecti-veQualityMapping, tem-se respectivamente, os seguintes indivíduos: QoStoMOS-SWRL, QoStoRFactor-SWRL e QoStoSubjectiveQuality-SWRL. As especializações de QoSQoEMapping são criadas, por exem-plo, por organizações de normalização de aplicações requerendo QoS, empresas também podem publicar conceitos de QoS para seus produtos. Por exemplo, uma empresa fornecedora de um software proprietário de VoIP poderia oferecer a seus usuários chamadas com diferentes níveis de QoS, utilizando para isso especificações de qualidade subjetiva defi-nidas na forma de nomes proprietários. Além disso, as especializações também são usadas para organizar os indivíduos que contém as regras de mapeamento, e principalmente para prover flexibilidade na inserção de novas regras de mapeamento, conforme descrito a seguir.

A Figura 8 apresenta as regras de mapeamento inseridas no indi-víduo QoStoMOS-SWRL. Elas permitem determinar um valor de MOS a partir dos parâmetros atraso e perda de pacotes, ou seja, elas são uma representação SWRL da Equação 2. Para esta medida, deve-se conside-rar o codec utilizado. Por uma questão de simplificação, a Figura 8 apre-senta apenas a regra de mapeamento para o codec G.711 (PT igual a 0).

65

Percebe-se que as regras são genéricas para os parâmetros de atraso e perda definidos na NSP.

CODEC(?codec)^hasMeasure(?PAYLOADCodec,?codec) ^swrlb:equal(?PAYLOADCodec,0.0)->swrlb:add(?T,4.5) CoS(?classesProvedor) ^hasParameterOWD(?parametroIndividuoAtraso,?classesProvedor) ^hasMeasure(?valorIndividuoAtraso,?parametroIndividuoAtraso) ^hasParametePLR(?parametroIndividuoPerda,?classesProvedor) ^hasMeasure(?valorIndividuoPerda,?parametroIndividuoPerda) ^swrlb:add(?a,0.195)^swrlb:divide(?b,?valorIndividuoPerda,100) ->swrlb:multiply(?valor1,?a,?b) swrlb:add(?c,?T)->swrlb:subtract(?valor2,?c,?valor1) swrlb:pow(?d,10.0,-3) ^swrlb:multiply(?e,2.64,?d)^swrlb:add(?f,?valorIndividuoAtraso,0.0) ->swrlb:multiply(?valor3,?e,?f) swrlb:add(?g,?valorIndividuoAtraso,0.0) ->swrlb:multiply(?valor4,?valorIndividuoAtraso,?g) swrlb:pow(?h,10.0,-5)^swrlb:multiply(?i,1.86,?h) ->swrlb:multiply(?valor5, ?i,?valor4) swrlb:add(?j, ?valorIndividuoAtraso,0.0) ->swrlb:multiply(?valor6, ?j, ?j, ?j) swrlb:pow(?k,10.0,-8)^swrlb:multiply(?l,1.22,?k) ->swrlb:multiply(?valor7,?l,?valor6) swrlb:add(?valor8, ?valor2,?valor3)^swrlb:add(?valor9,?valor5,0.0) ->swrlb:subtract(?valor10,?valor8,?valor9) swrlb:add(?valor11,?valor10,0.0) ->swrlb:add(?valorFinal,?valor11,?valor7); CODEC(?codec)^hasMeasure(?PAYLOADCodec,?codec) ^swrlb:equal(?PAYLOADCodec,96.0)->swrlb:add(?T,4.34) CoS(?classesProvedor) ^hasParameterOWD(?parametroIndividuoAtraso,?classesProvedor) ^hasMeasure(?valorIndividuoAtraso,?parametroIndividuoAtraso) ^hasParameterPLR(?parametroIndividuoPerda,?classesProvedor) ^hasMeasure(?valorIndividuoPerda,?parametroIndividuoPerda) ^swrlb:add(?a,0.195)^swrlb:divide(?b,?valorIndividuoPerda,100) ->swrlb:multiply(?valor1,?a,?b) swrlb:add(?c,?T)->swrlb:subtract(?valor2,?c,?valor1) swrlb:pow(?d,10.0,-3) ^swrlb:multiply(?e,2.64,?d)^swrlb:add(?f,?valorIndividuoAtraso,0.0) ->swrlb:multiply(?valor3,?e,?f) swrlb:add(?g,?valorIndividuoAtraso,0.0) ->swrlb:multiply(?valor4,?valorIndividuoAtraso,?g) swrlb:pow(?h,10.0,-5)^swrlb:multiply(?i,1.86,?h) ->swrlb:multiply(?valor5, ?i,?valor4) swrlb:add(?j, ?valorIndividuoAtraso,0.0) ->swrlb:multiply(?valor6, ?j, ?j, ?j) swrlb:pow(?k,10.0,-8)^swrlb:multiply(?l,1.22,?k) ->swrlb:multiply(?valor7,?l,?valor6) swrlb:add(?valor8, ?valor2,?valor3)^swrlb:add(?valor9,?valor5,0.0) ->swrlb:subtract(?valor10,?valor8,?valor9) swrlb:add(?valor11,?valor10,0.0) ->swrlb:add(?valorFinal,?valor11,?valor7); CODEC(?codec)^hasMeasure(?PAYLOADCodec,?codec) ^swrlb:equal(?PAYLOADCodec,15.0)->swrlb:add(?T,4.03) CoS(?classesProvedor) ^hasParameterOWD(?parametroIndividuoAtraso,?classesProvedor)

66

^hasMeasure(?valorIndividuoAtraso,?parametroIndividuoAtraso) ^hasParameterPLR(?parametroIndividuoPerda,?classesProvedor) ^hasMeasure(?valorIndividuoPerda,?parametroIndividuoPerda) ^swrlb:add(?a,0.195) ^swrlb:divide(?b,?valorIndividuoPerda,100) ->swrlb:multiply(?valor1,?a,?b) swrlb:add(?c,?T) ->swrlb:subtract(?valor2,?c,?valor1) swrlb:pow(?d,10.0,-3)^swrlb:multiply(?e,2.64,?d) ^swrlb:add(?f,?valorIndividuoAtraso,0.0) ->swrlb:multiply(?valor3,?e,?f) swrlb:add(?g,?valorIndividuoAtraso,0.0) ->swrlb:multiply(?valor4,?valorIndividuoAtraso,?g) swrlb:pow(?h,10.0,-5)^swrlb:multiply(?i,1.86,?h) ->swrlb:multiply(?valor5, ?i,?valor4) swrlb:add(?j, ?valorIndividuoAtraso,0.0) ->swrlb:multiply(?valor6, ?j, ?j, ?j) swrlb:pow(?k,10.0,-8)^swrlb:multiply(?l,1.22,?k) ->swrlb:multiply(?valor7,?l,?valor6) swrlb:add(?valor8, ?valor2,?valor3) ^swrlb:add(?valor9,?valor5,0.0) ->swrlb:subtract(?valor10,?valor8,?valor9) swrlb:add(?valor11,?valor10,0.0) ->swrlb:add(?valorFinal,?valor11,?valor7); CODEC(?codec)^hasMeasure(?PAYLOADCodec,?codec) ^swrlb:equal(?PAYLOADCodec,18.0)->swrlb:add(?T,3.6) CoS(?classesProvedor) ^hasParameterOWD(?parametroIndividuoAtraso,?classesProvedor)^hasMeasure(?valorIndividuoAtraso,?parametroIndividuoAtraso) ^hasParameterPLR(?parametroIndividuoPerda,?classesProvedor) ^hasMeasure(?valorIndividuoPerda,?parametroIndividuoPerda) ^swrlb:add(?a,0.195) ^swrlb:divide(?b,?valorIndividuoPerda,100) ->swrlb:multiply(?valor1,?a,?b) swrlb:add(?c,?T)->swrlb:subtract(?valor2,?c,?valor1) swrlb:pow(?d,10.0,-3)^swrlb:multiply(?e,2.64,?d) ^swrlb:add(?f,?valorIndividuoAtraso,0.0) ->swrlb:multiply(?valor3,?e,?f) swrlb:add(?g,?valorIndividuoAtraso,0.0) ->swrlb:multiply(?valor4,?valorIndividuoAtraso,?g) swrlb:pow(?h,10.0,-5)^swrlb:multiply(?i,1.86,?h) ->swrlb:multiply(?valor5, ?i,?valor4) swrlb:add(?j, ?valorIndividuoAtraso,0.0) ->swrlb:multiply(?valor6, ?j, ?j, ?j) swrlb:pow(?k,10.0,-8)^swrlb:multiply(?l,1.22,?k) ->swrlb:multiply(?valor7,?l,?valor6) swrlb:add(?valor8, ?valor2,?valor3)^swrlb:add(?valor9,?valor5,0.0) ->swrlb:subtract(?valor10,?valor8,?valor9) swrlb:add(?valor11,?valor10,0.0) ->swrlb:add(?valorFinal,?valor11,?valor7); CODEC(?codec)^hasMeasure(?PAYLOADCodec,?codec) ^swrlb:equal(?PAYLOADCodec,4.0)->swrlb:add(?T,3.1) CoS(?classesProvedor) ^hasParameterOWD(?parametroIndividuoAtraso,?classesProvedor) ^hasMeasure(?valorIndividuoAtraso,?parametroIndividuoAtraso) ^hasParameterPLR(?parametroIndividuoPerda,?classesProvedor) ^hasMeasure(?valorIndividuoPerda,?parametroIndividuoPerda) ^swrlb:add(?a,0.195)^swrlb:divide(?b,?valorIndividuoPerda,100)

67

->swrlb:multiply(?valor1,?a,?b) swrlb:add(?c,?T)->swrlb:subtract(?valor2,?c,?valor1) swrlb:pow(?d,10.0,-3) ^swrlb:multiply(?e,2.64,?d)^swrlb:add(?f,?valorIndividuoAtraso,0.0) ->swrlb:multiply(?valor3,?e,?f) swrlb:add(?g,?valorIndividuoAtraso,0.0) ->swrlb:multiply(?valor4,?valorIndividuoAtraso,?g) swrlb:pow(?h,10.0,-5)^swrlb:multiply(?i,1.86,?h) ->swrlb:multiply(?valor5, ?i,?valor4) swrlb:add(?j, ?valorIndividuoAtraso,0.0) ->swrlb:multiply(?valor6, ?j, ?j, ?j) swrlb:pow(?k,10.0,-8)^swrlb:multiply(?l,1.22,?k) ->swrlb:multiply(?valor7,?l,?valor6) swrlb:add(?valor8, ?valor2,?valor3)^swrlb:add(?valor9,?valor5,0.0) ->swrlb:subtract(?valor10,?valor8,?valor9) swrlb:add(?valor11,?valor10,0.0) ->swrlb:add(?valorFinal,?valor11,?valor7);

Figura 8. Regra de Mapeamento em MOS-Mapping. As regras de mapeamento exemplificadas na Figura 8 são defini-

das com builtins (relações). Os métodos apresentam argumentos genéri-cos, como por exemplo “?x”. Por exemplo, “?classesProvedor” repre-sentam os indivíduos CoS do provedor e T o MOS máximo do codec (4.5 para o G.711), como apresentado na Tabela 4. Os argumentos pas-sam valores aos métodos de soma (swrlb:add), divisão (swrlb:divide), multiplicação (swrlb:multiply) e potenciação (swrlb:pow). Existem ain-da argumentos que representam variáveis do tipo “?valorx”, onde x é um número indicando que a função foi separada em variáveis. Por exemplo, a variável “valor1” recebe a multiplicação do argumento “a” pelo argu-mento “b”. Para representar a Equação 2 em SWRL foi necessário inter-pretar a Equação 2 usando variáveis auxiliares (valor1, valor2, etc) que recebem valores de operações executadas pelos métodos e argumentos.

As regras de mapeamento existentes nos indivíduos QoStoRFac-tor-SWRL e QoStoSubjectiveQuality-SWRL, usam a Equação 1 e a Tabela 4 para mapear parâmetros de QoE como Fator R e Qualidade Percebida para parâmetros de MOS. O mapeamento é realizado de for-ma unidirecional, ou seja, para mapear QoS de rede em MOS deve ser publicado um indivíduo que contém esta regra.

68

5.2 CENÁRIO ILUSTRATIVO E DE TESTE Esta seção apresenta um cenário de uso da ontologia proposta

servindo também como cenário de teste. Este cenário ilustra a aplicação da proposta durante o processo de negociação de SLA. No cenário ilus-trado na Figura 9, o cliente inicia a negociação de um SLS para um trá-fego VoIP entre a matriz e a filial de sua corporação. O cliente neste caso informa o codec utilizado nas chamadas, G.711, e que ele deseja uma qualidade MOS≥4.34 para estas chamadas.

VoIPQoSOnt

NetQoSOnt

NSPQoEOnt

SLS VoIP contendo uma QoSSpec QoSVoIPMatrizFilial

NSP

Figura 9. Cenário Ilustrativo.

Para simular o comportamento do provedor e do cliente foi cons-

truído um protótipo usando os recursos da linguagem de programação Java, da API OWL 1.0 e 2.0 [111]. Para analisar as inconsistências e realizar a inferência com as ontologias foi usado o motor de inferência Pellet [117].

5.2.1 ONTOLOGIAS UTILIZADAS

Para este cenário ilustrativo foram definidas duas ontologias, a

VoIPQoEOnt, como apresentada na Figura 7 (com exceção do conceito CoS) e a ontologia NSPQoSOnt, que especifica a QoS oferecida pelas CoSs da NSP (Figura 10). As ontologias foram construídas usando a ferramenta Protégé 4.0 [118].

A ontologia VoIPQoEOnt é usada para especificar os parâmetros de QoE da área de VoIP e regras de mapeamento apresentadas na seção 5.1.4. Considera-se que VoIPQoEOnt tenha sido definida e publicada por uma organização de padronização de conceitos de VoIP. No caso,

69

esta suposta organização publicou a ontologia em http://organizacaoVoIP.org/VoIPQoEOnt.owl.

A ontologia NSPQoSOnt representa os conceitos de QoS defini-dos pela NSP. Esta ontologia é representada na Figura 10. Por uma questão de simplificação esta figura apresenta apenas a métrica de de-sempenho atraso, no entanto, outras métricas de desempenho tais como jitter e perda de pacotes foram consideradas. Essa ontologia define três indivíduos CoS: CoSA, CoSB e CoSBE. A CoSA possui um parâmetro CoSAPLR que representa a perda que essa classe oferece. A medida dessa perda é definida em CoSAPLRMeasure como sendo < 1 %. A CoSA ainda possui um parâmetro CoSAOWD que representa o atraso que essa classe oferece. A medida desse atraso é definida em CoSA-OWDMeasure como sendo < 140 ms. A CoSB possui um parâmetro CoSBPLR que representa a perda que essa classe oferece. A medida dessa perda é definida em CoSBPLRMeasure como sendo < 3 %. A CoSB ainda possui um parâmetro CoSBOWD que representa o atraso que essa classe oferece. A medida desse atraso é definida em CoS-BOWDMeasure como sendo < 250 ms. A CoSBE possui um parâmetro BEPLR que representa a perda que essa classe oferece. A medida dessa perda é definida em BEPLRMeasure como sendo < 25 %. A CoSBE ainda possui um parâmetro BEOWD que representa o atraso que essa classe oferece. A medida desse atraso é definida em BEOWDMeasure como sendo < 1000 ms.

InternetPerformance

Parameter

BEOWDio

CoSBOWD

BE

CoSBio CoSBOWD

Measure

BEOWDMeasure

CoSAOWDCoSAio CoSAOWD

Measure

hasParameterOWD hasMeasure

hasMeasure

hasMeasure

io

iohasParameterOWD

hasParameterOWD

io

CoS

Figura 10. Ontologia NSPQoSOnt.

70

5.2.2 ESPECIFICANDO A QUALIDADE DESEJADA

A Figura 11 apresenta as classes e indivíduos utilizados para re-

presentar a QoS negociada no SLS. Este SLS em negociação deve con-ter uma QoSSpec, chamada aqui de Client1. Ela tem associado dois parâmetros, o codec G.711 (indivíduo definido na VoIPQoEOnt) consi-derado para as chamadas VoIP e o parâmetro de QoS. Este último é definido como uma especialização da classe http://organizacaoVoIP.org/VoIPQoEOnt.owl#MOS, chamado Cli-ent1MOS, que tem uma medida agregada, Client1FaixaMOS. Essa me-dida tem um valor, qualityLiteralValue double≥4.34. Este valor foi de-clarado no indivíduo MOSG711ClientMeasure.

QoSSpec Parameter Measure

is-a

UserPerformanceParameter

hasParameterhasMeasure

Especificação da QoS solicitada

Client1MOSis-a

Client1FaixaMOS

is-a

hasMeasure

Client1

is-a

hasParameter

hasParameterio

MOSG711ClientMeasure

G711

VoIPQoSOnt

NetQoSOnt

Figura 11. Especificação de QoS Solicitada.

Um módulo do protótipo foi criado para simular a especificação

da QoSSpec contida no SLS VoIP. Conforme ilustra a Figura 12, a inter-face do aplicativo permite que o usuário possa expressar a qualidade do serviço desejado através de MOS, Fator R ou Qualidade Percebida. Após a escolha do parâmetro de QoE é feita a inserção dos dados na ontologia da organização pela NSP, ou seja, na ontologia de especifica-ção de QoE, aqui denominada de VoIPQoEOnt. Esses dados são gera-dos dinamicamente pelo módulo da aplicação.

71

Figura 12. Interface do Aplicativo de Especificação de QoE.

5.2.3 TRATAMENTO DA SOLICITAÇÃO DO USUÁRIO Quando da negociação do SLS VoIP, o sistema de negociação de

SLA/SLS da NSP deve aceitar/renegociar ou recusar o SLS solicitado. Isto envolve a verificação da disponibilidade de recursos para atender ao pedido. Dentre estas informações, é necessário que a NSP verifique se ela possui uma CoS que atenda a solicitação do usuário. Para isso, ela deve verificar se alguma CoS permite atender a qualidade solicitada pelo usuário MOS≥4.34.

Considere aqui que a NSP não conheça ainda o conceito de MOS. A proposta deste trabalho permite que a NSP consiga importar este con-ceito e avaliar se uma CoS oferece a qualidade necessária. O procedi-mento inicia pela importação dos conceitos usados no SLS para a onto-logia NSPQoSOnt.

Outro módulo de software foi desenvolvido para simular o siste-ma de negociação de SLS (Figura 13). Ao receber a requisição do clien-te, este módulo deve verificar se a especificação da QoE já é de seu conhecimento. Caso afirmativo, ela já sabe qual CoS atende a solicita-ção do usuário. Se a NSP ainda não conhece a especificação de QoE, ele usa a URL da organização VoIP (http://organizacaoVoIP.org/VoIPQoEOnt.owl) como referência para a importação da ontologia VoIPQoEOnt.

72

Figura 13. Interface do Aplicativo de Importação de QoE.

Conhecida a especificação de QoS em negociação, é necessário

agora que a NSP compare esta especificação com o nível de qualidade oferecido pelas suas CoSs. Ou seja, comparar uma especificação de QoS ao nível do usuário com uma especificação de QoS ao nível de rede. Para permitir esta comparação, é necessário mapear as especificações de QoS das CoSs em especificações de QoE usando os mesmos parâmetros de QoE usados pelo cliente. A solução adotada para tal é gerar dinami-camente indivíduos QoSSpec com parâmetro MOS equivalentes a quali-dade especificada pela QoSSpec que define os parâmetros de desempe-nho garantidos pelas CoSs. Além dos indivíduos QoSSpec são necessá-rios gerar indivíduos MOS e Measure para expressar o parâmetro da QoSSpec da especificação e o seu valor.

Para determinar o MOS mínimo garantido pelas CoSs, o sistema de negociação de SLA deve interpretar as regras de mapeamento da ontologia mantidas no indivíduo QoStoMOS-SWRL identificado pela relação mappingTo (Figura 7). Essa relação é responsável pela ligação da solicitação de MOS, especificada na camada de usuário com o indi-víduo QoStoMOS-SWRL, da classe MOSMapping.

Pelo fato da linguagem SWRL não permitir que os valores resul-tantes das regras possam ser inseridos em ontologias diretamente como indivíduos, precisa-se de funcionalidades na aplicação para prover esse recurso. Para tal, o módulo do protótipo utiliza um interpretador SWRL,

73

implementado em java para a análise das regras mantidas no indivíduo QoStoMOS-SWRL e a instanciação dos indivíduos. Como as regras estão definidas em indivíduos numa ontologia que foi desenvolvida na versão 2.0 da OWL e esta versão não possui os métodos na linguagem SWRL, precisou-se criar um interpretador para ler essas regras, no protótipo implementado em java. As regras descritas na Figura 8 usam métodos da versão 1.0 da OWL, então o interpretador foi desenvolvido e usado para ler os métodos da versão 1.0 da OWL API dentro da ontologia desenvolvida na versão 2.0 da OWL API. A ferramenta Protegé, e ne-nhum plugin existente, oferece suporte para utilizar as regras desenvol-vidas, responsável por proporcionar o desenvolvimento das ontologias, classes, indivíduos e relacionamentos. A aplicação desenvolvida em java, usando os métodos da OWL API cria e insere os indivíduos de QoSSpec especificando valores para MOS resultantes na ontologia do provedor. Estas operações são realizadas com base nas regras de mape-amento definidas nos indivíduos no módulo de Mapeamento de QoS/QoE.

De acordo com os parâmetros de rede publicados para cada CoS da NSP (atraso, perda e jitter), e o conhecimento do tipo de codec da especificação, o módulo Java interpreta as regras de mapeamento exis-tente no indivíduo QoStoMOS-SWRL através da relação explicada e gera os novos indivíduos. A Figura 14 apresenta os indivíduos gerados a partir da análise das regras. Os indivíduos QoSSpec QoSSpec-MOSG711CoSA, QoSSpecMOSG711CoSB e QoSSpecMOSG711BE representam especificações de QoS usando o parâmetro MOS e conside-rando o codec G.711 de qualidade equivalente as QoSSpec CoSA, CoSB e BE. Ou seja, os níveis de qualidade são equivalentes, apenas expressos usando parâmetros de diferentes camadas de rede. Os indivíduos MOSG711CoSAMeasure (double=4.54), MOSG711CoSAMeasure (dou-ble=4.18) e MOSG711CoSAMeasure (double=0.69) mantém os valores máximos de MOS garantidas pelas CoS.

74

Client1MOS Client1FaixaMOS

hasMeasure

Client1

hasParameter

MOSG711CoSA MOSG711CoSAMeasurehasParameterhasMeasure

ioio

QoSSpecMOSG711CoSA

QoSSpecMOSG711CoSB

QoSSpecMOSG711BE

MOSG711CoSB

MOSG711BE

MOS

is-a

hasParameter

hasParameter

io

io

io

MOSG711CoSBMeasure

MOSG711BEMeasure

hasMeasure

hasMeasure

io

Figura 14. Indivíduos gerados e resultado da inferência.

Depois de gerados estes indivíduos, o módulo de negociação de

SLS deve usar um motor de inferência para identificar quais das suas CoSs atendem a especificação do usuário. Sendo a QoSSpec Cliente1 a formalização da qualidade desejada pelo cliente, para verificar qual CoS atende a qualidade basta identificar qual dos indivíduos QoSSpec gera-dos é membro da classe Cliente1.

Para classificar os membros em classes, o motor de inferência a-nalisa os intervalos definidos pelas subclasses e valores dos indivíduos de Measure. Como a classe Client1FaixaMOS tem um valor, dou-ble≥4.34, e o indivíduo MOSG711CoSAMeasure tem um double≥4.54, então este indivíduo é inferido como da classe Client1FaixaMOS. As-sim, MOSG711CoSA é indivíduo da classe Client1MOS e por conse-qüência QoSSPecMOSG711CoSA é indivíduo da classe Client1. O que se conclui que CoSA tem limites de desempenho que atendem a solici-tação do usuário. Note que esta constatação é automática, obtida pelo protótipo desenvolvido que utiliza o motor de inferência Pellet. Esta operação automática permitiu verificar a aplicabilidade da ontologia proposta nas operações relacionadas à comparação de especificações de QoS.

Aqui se percebe a flexibilidade obtida pela ontologia proposta. O provedor não conhecendo a especificação de QoE, feita pelo usuário, consegue gerar dinamicamente instâncias na camada de usuário da sua

75

ontologia. Essas instâncias só foram especificadas devido às regras de mapeamento implementadas em indivíduos na organização VoIP.


Este capítulo apresentou a extensão para a ontologia NetQoSOnt.

Uma extensão que permite que parâmetros de QoE possam ser especifi-cados por humanos, em nível de usuário, e o provedor consiga entender as solicitações e saber responder se tem recursos de rede que possam atender aos requisitos do usuário.

O processo de mapeamento, usando regras na linguagem SWRL, traz flexibilidade aos provedores de serviço e às organizações de norma-lização de serviços. Flexível, pois novos parâmetros de QoE podem ser definidos e o NSP pode adquirir este conhecimento via a importação desta nova ontologia.

A extensão proposta da NetQoSOnt contribuiu de modo significa-tivo, pois novas funcionalidades foram adicionadas. (i) A inserção da camada Mapeamento de QoS/QoE, permite realizar o mapeamento de especificações em todas as camadas da ontologia. (ii) A inserção dinâ-mica e em tempo de execução da especificação de QoE, antes realizada de forma manual. (iii) Novas regras de mapeamento podem ser realiza-das como, por exemplo, a inserção de uma solicitação do tipo PESQ. (iv) As regras SWRL foram estruturadas de modo genérico, o que per-mite manter as terminologias usadas em cada organização.

O cenário de teste envolveu o desenvolvimento de um protótipo, que teve sua programação desenvolvida e facilitada devido a disponibi-lidade dos recursos existentes na versão 1.0 da OWL API.

Uma dificuldade encontra foi o fato da ferramenta Protégé versão 4.0 não possuir plugin do SWRL. Desta forma, um estudo teve que ser realizado quanto as sintaxes da SWRL para poder construir um interpre-tador específico para analisar as regras existentes no individuo da onto-logia.

Com os experimentos realizados, pôde-se testar a solução propos-ta, onde a qualidade pôde ser especificada usando valores de MOS, e uma NSP pôde usar a ontologia para inferir quais requisitos de rede foram necessários para atender a QoS solicitada

76

6. CONCLUSÕES E TRABALHOS FUTUROS Como visto na dissertação, o uso de abordagens semânticas para

especificação de QoS permite que os clientes e usuários dos serviços de comunicação com QoS possam expressar os níveis de qualidade desejá-veis usando diversos parâmetros de QoS. Uma proposta apresentada na dissertação foi a NetQoSOnt, uma ontologia de QoS onde é permitido que se desenvolvam operações de gerenciamento de QoS, tais como seleção de serviços, negociação/monitoramento de SLA e invocação de serviços.

No entanto, a NetQoSOnt apresentou algumas limitações, como por exemplo: a ausência de regras de mapeamento, a maneira como expressa as equivalências entre especificações de QoE/QoS de diferen-tes níveis e quanto ao aspecto da otimização de uso de recursos de rede.

Esta dissertação apresentou o aprimoramento na ontologia Net-QoSOnt, oferecendo recursos para o efetivo mapeamento entre especifi-cações de QoE em especificações de QoS nos mais diversos níveis da rede. Com isso se conseguiu obter uma flexibilidade em termos de valo-res de QoS/QoE e uma melhora significativa quanto à questão da granu-laridade.

Usando a ontologia construída para especificar as solicitações de QoE, um cliente pôde iniciar uma negociação de um SLS para um tráfe-go VoIP entre a matriz e a filial de sua corporação, usando um dos três métodos subjetivos propostos nesta dissertação: MOS, Fator R e Quali-dade Subjetiva. Nesta ontologia houve a adição da camada de mapea-mento chamada de Mapeamento de QoS/QoE. Foi criada uma classe QoSQoEMapping, com a finalidade de permitir o mapeamento entre todas as camadas da ontologia. Indivíduos foram criados para permitir a inserção de regras de mapeamento.

O processo de mapeamento, usando regras na linguagem SWRL, traz flexibilidade aos provedores de serviço e às organizações de norma-lização de serviços. Flexível, pois novos parâmetros de QoE podem ser definidos e a NSP pode adquirir este conhecimento via a importação desta nova ontologia.

Neste capítulo foi apresentado um estudo de caso para ilustrar a proposta e também serviu para validá-la. Além da ferramenta Protégé, o cenário de teste envolveu o desenvolvimento de um protótipo em java, que teve sua programação facilitada devido a disponibilidade de recur-sos existentes na OWL API.

77

Os experimentos realizados foram bem sucedidos especificando-se parâmetros de QoE e de QoS nas ontologias e através do processo de inferência chegou-se na solução esperada da abordagem.

Como trabalhos futuros, pode-se incluir a especificação de novos parâmetros de QoE e QoS, bem como os indivíduos que especificam novas regras de mapeamento entre parâmetros de QoE/QoS. Outro tra-balho futuro é a validação da proposta em ambiente reais de negociação de SLA/SLS e invocação explícita de serviços com QoS.

78

7. REFERÊNCIAS BIBLIOGRÁFICAS

[1] Black, S., Black, D., Nichols, K., Baker, F., Cisco Systems, Torrent Networking Technologies, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers - RFC 2474, IETF, 1998.

[2] ITU-T, “Network performance objectives for IP-based services”, Recommendation Y.1540 ed., May 2002. Series Y.

[3] Integrated Services Over Diffserv Networks. Página da World Wide Web. url: http://www.ietf.org/rfc/rfc2998.txt. Acessado em abril de 2008.

[4] MPLS Architecture. Página da World Wide Web. url: http://www.ietf.org/rfc/rfc3031.txt. Acessado em abril de 2008.

[5] Goderis, D., et aa. (2003). “Service Level Specification Semantics and Parameters”. Em http://tools.ietf.org/html/drafttequila-sls-02.

[6] Kilkki, Kalevi. “Quality of Experience in Communications Ecosystem. Journal of Universal Computer Science”, vol. 14, no. 5 (2008), 615-624 submitted: 1/11/07, accepted: 28/2/08, appeared: 1/3/08.

[7] Moorsel, Aad P.A van. Metrics for the Internet Age: Quality of Experience and Quality of Business. HP Labs Technical Report HPL-2001-179.

[8] Alfano, Marco. User requirements and resource control for cooperative multimedia applications. LNCS: Multimedia Appli-cations, Services and Techniques - ECMAST '97, volume 1242, Springer, 1997, pp. 537-552.

[9] SG12 TD 44 Rev.1 (March 2004), “Definition of Quality of Experience (QoE)”, Liaison statement from SG 12 to SG 2.

[10] ITU-T Recommendation P.800. "Methods for subjective determination of transmission quality".

[11] Wang, G.; Chen, A.; Wang, C.; Fung, C.; Uczekaj, S., “Integrated quality of service (QoS) management in service-oriented enterprise architectures”, Enterprise Distributed Object Computing Conference, 2004. EDOC 2004. Proceedings. Eighth IEEE International, vol., no., pp. 21-32, 20-24 Sept. 2004.

[12] Hung, P.C.K.; Haifei Li; Jun-Jang Jeng, “WS-Negotiation: an overview of research issues”, System Sciences, 2004. Proceedings of the 37th Annual Hawaii International Conference on , vol., no., pp. 10 pp.-, 5-8 Jan. 2004.

79

[13] Prudêncio, A. C.; Willrich, R.; Said Tazi; Diaz, M. “Quality of Service Specifications: A Semantic Approach”. In: IEEE International Symposium on Network Computing and Application, 2009, Cambridge, MA. 8th IEEE International Symposium on Network Computing and Application, 2009.

[14] W3C, “SWRL: A Semantic Web Rule Language Combining OWL and RuleML”. W3C Member Submission 21 May 2004. http://www.w3.org/Submission/SWRL/. Acessado em agosto de 2009.

[15] Sanchez-Macian, A., Lopez, D., Lopez de Vergara, J.E., Pastor, E.: A Framework for the Automatic Calculation of Quality of Experience in Telematic Services. In: Proc. of the 130th HP-OVUA Workshop, Côte d'Azur, France (290033).

[16] Andrieux, A., Czajkowski, K. , Dan, A., Keahey, K. , Ludwig, H. , Kakata, T., Pruyne, J., Rofrano, J., Tuecke, S., Xu, M. Serviços Web Agreement Specification (WS-Agreement) GFD 1034 Recommendation. Open Grid Forum (290034).

[17] Dobson, G., Russell, L., Sommerville, I. QoSOnt: a QoS Ontology for Service-Centric Systems. In: Proc. of the 301st Euromicro conference on Software Engineering and Advanced Applications. IEEE Computer Society, Washington DC (290032) 80-834.

[18] Zhou, C., Chia, L. e Lee, B. (2005). “QoS Measurement Issues With DAML-QoS Ontology”. IEEE International Conference On E-Business Engineering, pág. 395-402.

[19] M. Siller; J. Woods, “Using an agent based platform to map quality of service to experience in conventional and active networks,” Communications, IEE Proceedings- , vol.153, no.6, pp.828-840, Dec. 2006.

[20] Gallo, E.; Siller, M.; Woods, J., “An Ontology for the Quality of Experience framework,” Systems, Man and Cybernetics, 2007. ISIC. IEEE International Conference on , vol., no., pp.1540-1544, 7-10 Oct. 2007.

[21] A. Sánchez-Macián, D. López, J. E. López de Vergara, E. Pastor, “A Framework for the Automatic Calculation of Quality of Experience in Telematic Services”. 13th Openview University Association Workshop (HP-OVUA 2006), Sophia Antipolis, France, May 2006.

[22] Ghinea, C., and Thomas, J.: “An approach towards mapping quality of perception to quality of service in multimedia

80

communications”. IEEE Workshop on Multimedia Signal Processing, 1999, pp. 497–502.

[23] International Organization for Standardization. Quality of Service Basic Framework – outline. ISO / IEC JTC1 / SC21 / WG1 N1145, 1994.

[24] Tang, K.; Gerla, M. Fair Sharing of MAC under TCP in Wireless Ad Hoc Networks. IEEE Multiaccess, Mobility and Teletraffic for Personal Communications (MMT’99) (Veneza, Itália, October, 1999).

[25] ITU-T, “Recommendation E.800: QoS Terms and Definitions related to Quality of Service and Network Performance including dependability,” August, 1994.

[26] Heinanen, J., Baker, F., Weiss W., Wroclawski J. Assured Forwarding PHB Group, RFC 2597, IETF, 1999. url:. http://tools.ietf.org/html/rfc2597. Acessado em maio de 2010.

[27] Tequila Consortium, “SrNP: Service Negotiation Protocol,” http://www.ist-tequila.org/deliverables, Oct. 2001. X. Fu, et al., “NSIS: A New Extensible IP Signaling Protocol Suite,” IEEE Communications Magazine, Vol. 43, No. 10, pp 133- 141, 2005.

[28] Goderis Danny, T'joens Yves, Zaccone Carmelo, Jacquenet Christian, Memenios George, Pavlou George, Egan Richard, Griffin David, Georgiadis Leonidas. Service Level Specification Semantics, Parameters and negotiation requirements, Internet Draft <draft-tequila-diffserv-sls-00.txt>, 2000.

[29] Almes, G., Kalidindi, S., Zekauskas, M. A. One-way Packet Loss Metric for IPPM, RFC 2680, 1999.

[30] Almes, G., Kalidindi, S., Zekauskas, M. A. A One-way Delay Metric for IPPM, RFC 2679, 1999.

[31] Demichellis, C. Chimento, P. IP Packet Delay Variation Metric for IP Performance Metrics (IPPM). RFC 3393, 2002.

[32] A. S. Patrick, et al., “A QoE Sensitive Architecture for Advanced Collaborative Environments,” in Proceedings of the First International Conference on Quality of Service in Heterogeneous Wired/Wireless Networks, 2004.

[33] T. M. O’ Neil, “Quality of Experience and Quality of Service for IP Video Conferencing”, Polycom, Whitepaper, 2002.

[34] J. Goodchild, “Integrating data, voice and video – Part II,” IP Video Implementation and planning guide, United States Telecom Association, 2005.

[35] M. Siller and J. Woods, “Improving quality experience for multimedia services by QoS arbitration on a QoE framework,” in

81

Proceedings of the 13th Packed Video Workshop 2003, Nantes, France, 2003.

[36] B. Bauer and A. S. Patrick. (2004, January 6). A Human Factors Extension to the Seven-Layer OSI Reference Model. [Online]. Available: http://www.andrewpatrick.ca/OSI/10layer.html.

[37] D. Lopez, F. Gonzalez, L. Bellido, and A. Alonso, “Adaptive multimedia streaming over IP based on customer oriented metrics,” in Proceedings of the Seventh IEEE International Symposium on Computer Networks, 2006, pp. 185-191.

[38] Ghinea, G., and Thomas, J.: “Quality of perception to quality of service mapping using a dynamically recongurable communication system”. GLOBECOM’99: IEEE Global Telecommunications Conf., 1999, Vol. 4, pp. 2061–2065.

[39] Walker, J. Q.; Hicks, J. T. Taking Charge of Your VoIP Project. Indianapolis, IN 46240 USA: Cisco Press, 2004. p.200-400.

[40] Willrich, R. Apostila do Curso Sistemas Multimídia Distribuídos. Universidade Federal de Santa Catarina. Dezembro de 2010.

[41] Hersent, O., Guide, D., Petit, J., Telefonia IP – Comunicação Multimídia Baseada em Pacotes. Addison Wesley. São Paulo 2002.

[42] ITU-T, G.711. G.711: Pulse code modulation (PCM) of voice frequencies. Recommendation G.711, novembro 1988. Disponí-vel em url: http://www.itu.int/rec/T-REC-G.711/e. Acesso em de-zembro 2009.

[43] ITU-T, G.723. G.723: Extensions of Recommendation G.721 adaptive differential pulse code modulation to 24 and 40 kbit/s for digital circuit multiplication equipment application. Recom-mendation G.723, novembro 1988. Disponível em url: http://www.itu.int/rec/T-REC-G.723/e. Acesso em dezembro 2009.

[44] ITU-T, G.726. G.726: 40, 32, 24, 16 kbit/s Adaptive Differential Pulse Code Modulation (ADPCM). Recommendation G.726, de-zembro 1990. Disponível em url: http://www.itu.int/rec/T-REC-G.726/e. Acesso em dezembro 2009.

[45] ITU-T, G.728. G.728: Coding of speech at 16 kbit/s using low-delay code excited linear prediction. Recommendation G.726, se-tembro 1992. Disponível em url: http://www.itu.int/rec/T-REC-G.728/e. Acesso em dezembro 2009.

[46] ITUT-T, G.729. G.729: Coding of speech at 8 kbit/s using conjugate-structure algebraic-code-excited linear prediction (CS-ACELP). Recommendation G.729, janeiro 2007. Disponível em

82

url: http://www.itu.int/rec/T-REC-G.729/e. Acesso em dezembro 2009.

[47] ITU-T Recommendation G.107. “The E-Model, a computational model for use in transmission planning”. Genève, mar 2003.

[48] Rix, A., Beerends, J., Hollier, M., e Hekstra, A. “Perceptual evaluation of speech quality (PESQ) a new method for speech quality assessment of telephone networks and codecs”. IEEE ICASSP, vol. 2, pp. 749-752, 2001.

[49] Psytechnics Group. PAMS: Measuring speech quality over networks as the customers hear it. Psytechnics White Paper. United Kingdom, May 2001.

[50] Clark, Alan. Comparison of Extended E Model with PSQM and PAMS. Committee T1, Standards Project T1A1-17, Document Number T1A1.1/2001-027. [USA], 2001.

[51] Cisco, 2006. Understanding Codecs: Complexity, Hardware Support, MOS, and Negotiation. Document ID: 14069, 02 Febru-ary 2006. Disponível em url: http://www.cisco.com/en/US/tech/tk1077/technologies_tech_note09186a00800b6710.shtm. Acesso em novembro 20009.

[52] ITU-T Recommendation P.862, Perceptual evaluation of speech quality (PESQ): “An objective method for end-to-end speech quality assessment of narrow-band telephone networks and speech codecs”. Genève, 2001.

[53] ITU-T Recommendation G.113. Appendix I. “Provisional planning values for the equipment impairment factor Ie and packet-loss robustness factor Bpl”. Genève, maio 2002.

[54] ITU-T Recommendation P.861, Objective quality measurement of telephone-band speech codecs. Genève, 1996.

[55] Anderson, John, Methods for Measuring Perceptual Speech Quality. Agilent Technologies White Paper. USA, May 2001.

[56] M. A. Schwartz, “Enabling a Quality IPTV Customer Experience”, Telcordia, Whitepaper, 2005.

[57] ITU-R Recommendation ITU-R BT.500-11, Methodology for the subjective assessment of the quality of television pictures. (Question ITU-R 211/11).

[58] Huynh-Thu, Q.; Ghanbari, M., “Scope of validity of PSNR in image/video quality assessment”. Electronics Letters , vol.44, no.13, pp.800-801, June 19 2008.

[59] ITU-T P.910, “Subjective video quality assessment methods for multimedia applications,” Sep 1999.

83

[60] Wang, Y. “Survey of Objective Video Quality Measurements,” Tech report, Worcester Polytechnic Institute. Junho de 2006.

[61] ETSI TS 101 329-5 v1.1.1. “Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON) Release 3; End-to-end Quality of Service in TIPHON systems; Part 5: Quality of Service (QoS) measurement methodologies”. France, nov. 2000.

[62] Fujimoto, K., Ata, S., e Murata, M. “Adaptive playout buffer algorithm for enhancing perceived quality of streaming applications”. IEEE GLOBECOM, no. 1, pp. 2463-2469, Novembro 2002.

[63] Savolaine, C. “QoS/VoIP overview”. IEEE CQR International. Workshop, 2001.

[64] Santos, D.B.A. dos; Ribeiro, C.M.F.A. Utilizando Tecnologia Semântica para Descoberta Automática de Web Services. I Con-gresso de Pesquisa e Inovação da Rede Norte Nordeste de Educa-ção Tecnológica - Natal, RN, 2006.

[65] W3C (World Wide Web Consortium). Web Services Architecture. W3C Working Group Note 11 February 2004. Dis-ponível em: http://www.w3.org/TR/ws-arch/#concepts_and_relationships. Acessado em abril de 2008.

[66] W3C. Página da World Wide Web. url: http://www.w3.org/XML/Schema. Acessado em abril de 2008.

[67] W3C. Web Services Description Language (WSDL). Página da World Wide Web. url: WSDL. “Web Service Definition Language”, W3C, http://www.w3.org/TR/wsdl. Acessado em a-bril de 2008.

[68] UDDI Spec Technical Committee Specification Draft. UDDI Version 3.0.2. Página da World Wide Web. url: http://uddi.org/pubs/uddi_v3.htm, 2004. Acessado em abril de 2008.

[69] The “application/soap+xml” media type. Página da World Wide Web. url: http://www.ietf.org/rfc/rfc3902.txt. Acessado em abril de 2008.

[70] XMPP Core. Página da World Wide Web. url: http://www.ietf.org/rfc/rfc3920.txt. Acessado em abril de 2008.

[71] Guia de Orientação para Implementação – Serviços Web. Página da World Wide Web. url: http://i3gov.softwarepublico.gov.br/wikiws/docs/GuiaOrientacaoWSv0.pdf. Acessado em abril de 2008.

84

[72] Rodríguez, M.A.C., Gabeiras, J.E., Burakowski, W., Beben, A., Sliwinski, J., Dugeon, O., Mingozzi, E., Stea, G., Diaz, M. e Ba-resse, L. (2008). “EuQoS: End-To-End QoS over Heterogeneous Networks”. Em Innovations in NGN: Future Network and Services (KINGN). First ITU-T Kaleidoscope Academic Confe-rence, pág. 177-184.

[73] Salsano, S., Ricciato, F., Winter, M., Gerald Eichler, G., Thomas, A., Fuenfstueck, F., Ziegler, T. e Brandauer, C. (2000). “Definition and usage of SLSs in the AQUILA consortium”. Página da World Wide Web. url: http://tools.ietf.org/draft/draft-salsano-aquila-sls/draft-salsano-aquilasls-00.txt.

[74] Svend Frolund and Jari Kointen. QML: A Language for Quality of Services Specificaion. Página da World Wide Web. url: http://www.hpl.hp.com/techreports/98/HPL-98-10.html.

[75] D. Lamanna et al. SLAng: A Language for Defining Service Level Agreements. Página da World Wide Web. url: http://www.cs.ucl.ac.uk/staff/w.emmerich/publications/FTDCS03.

[76] Heiko Ludwig et al. Web Service Level Agreements (WSLA) Project. Página da World Wide Web. url: http://www.research. ibm.com/wsla/.

[77] Keller A.; Ludwing H. The WSLA Framework: Specifying and Monitoring Service Level Agreements for Web Services. Journal of Network and Systems Management, Volume 11, Number 1, March 2003 , pp. 57-81(25).

[78] Web Service Level Agreements (WSLA). Página da World Wide Web. url: http://www.research.ibm.com/wsla/about.html. Aces-sado em abril de 2008.

[79] A. Sánchez-Macián, J.E. López de Vergara, E. Pastor, L. Bellido. A system for monitoring, assessing and certifying Quality of Service in telematic services. Universidad Politécnica de Madrid, Ciudad Universitaria, Madrid 2980310, Spain. Universidad Au-tónoma de Madrid, Ciudad Universitaria de Cantoblanco, Madrid 2980319, Spain.

[80] A. Andrieux, C. Czajkowski, A. Dan, K. Keahey, H. Ludwig, J. Pruyne, J. Rofrano, S. Tuecke, M. Xu, “Serviços Web Agreement Specification (WS-Agreement)”, June 2005.

[81] Mcguinness, D. L. Ontologies Come of Age. “Spinning the Semantic Web: Bringing the World Wide Web to Its Full Potential”, Dieter Fensel, Jim Hendler, Henry Lieberman, and

85

Wolfgang Wahlster (editors), pp. 1341-1931, ISBN: 0-293329-033293029-1, MIT Press, 290030.

[82] The Web Service Modeling Language WSML. Página da World Wide Web. url: http://www.wsmo.org/wsml/wsml-syntax. Aces-sado em dezembro de 2008.

[83] Tian, M.; Gramm, A.; Naumowicz, T.; Ritter, H.; Freie, J.S. A Concept for QoS Integration in Web Services. Fourth International Conference on 13 Dec. 2003.

[84] Berners-Lee, T.; Hendler, J.; Lassila, O. “The Semantic Web”, Scientific American, edição de maio de 2001.

[85] Gruber, T. R. A translation approach to portable ontology. Knowledge Acquisition, 5(2): 199-220, 1993.

[86] Forte, Marcos; Souza, Wanderley Lopes de; Prado, Antonio Francisco do. Utilizando Ontologias e Serviços Web na Compu-tação Ubíqua. Publicado no XX Simpósio Brasileiro de Engenha-ria de Software em 2006.

[87] Naumenko A. et al. (2005) “Using UDDI for Publishing Metadata of the Semantic Web”, In: M. Bramer and V. Terziyan (Eds.): Industrial Applications of Semantic Web, Proceedings of the 1st International IFIP/WG12.5 Working Conference IASW-2005, Jyväskylä, Finland, Springer, IFIP, pp. 141-159.

[88] Srínívasan N., Paoluccí M., Sycara K., (2005) “Adding OWL-S to UDDI, implementation and throughput”. Robotics Institute, Carnegie Mellon University, USA.

[89] Web Service Semantics - WSDL-S. Página da World Wide Web. url: http://www.w3.org/Submission/WSDL-S/. Acessado em abril de 2008.

[90] Martin, D. (2004) “OWL-S: Semantic Markup for Serviços Web”, DAML. Página da World Wide Web. url: http://www.daml.org/services/owl-s/1.1/.

[91] Meteor-S: Semantic Serviços Web and Processes. Página da World Wide Web. url: http://lsdis.cs.uga.edu/projects/meteor-s/. Acessado em abril de 2008.

[92] Web Service Modeling Ontology. Página da World Wide Web. url: http://www.wsmo.org/. Acessado em abril de 2008.

[93] W3C. Página da World Wide Web. url: http://www.w3.org/Submission/WSDL-S/. Acessado em abril de 2008.

[94] Lassila, O.; Swick, R. R. (Ed.). Resource framework: model and syntax specification. [S. l.] : W3C Consortium, 1999. Disponível em: <http://www.w3.org/ TR/REC-rdf-syntax/>.

86

[95] Brickley, D.; Guha, R. V. (Ed.). Resource description framework schema specification 1.0: W3C candidate recommendation. [S. l.] : W3C Consortium, 2000. Disponível em: <http://www.w3.org/TR/2000/CR-rdf-schema-20000327/>.

[96] Harold, E. R. XML bible. Foster City : IDG Books Worldwide, 1999.

[97] Corcho, O.; Fernández-Loópez, M.; Gómez-Péres, A. OntoWeb – Tecnical Roadmap v 1.0. , [S.l.], 2001.

[98] Loom. LOOMProject Home Page - Overview: Loom Knowledge Representation and Reasoning System. Disponível em: http://www.isi.edu/isd/loom/loom-home.html Acesso em: ago 2009.

[99] Gruber, T. R. Ontolingua: A Mechanism to Support Portable Ontologies. Technical Report, Knowledge Systems Laboratory, Stanford University, Stanford, June 1992.

[100] Domingue, J.; Motta, E.; Garcia, O. C. Knowledge Modelling in WebOnto and OCML: A User Guide. , [S.l.], 1992.

[101] Kifer, M.; Lausen, G.; WU, J. Logical Foudations of Object-Oriented and Frame-Based Languages. Journal of the Association for Computing Machinery, [S.l.], May 1995.

[102] Luke, S.; Heflin, J. SHOE 1.01. Proposed Specification. SHOE Project. April 2000. Disponível em http://www.cs.umd.edu/projects/plus/SHOE/spec.html. Acesso em ago 2009.

[103] Su, X. Ilebrekke, L. A Comparative Study of Ontology Languages and Tools. Caise 02. Toronto, Canadá, mai. de 2002.

[104] Karp, R.; Chaudhri, V.; Thomere, J. XOL: An XML-Based Ontology Exchange Language. Aug. 1999. Disponível em <http://www.ai.sri.com/~pkarp/xol>. Acesso em 09 Ago. 2009.

[105] Kent, R. Conceptual Knowledge Markup Language. Nov. 1998. Disponível em <http://www.ontologos.org/CKML/CKML%200.2.html>. Acesso em 09 Ago. 2009.

[106] Horrocks, I. et al. The Ontology Inference Layer OIL. Technical Report. University of Amsterda. 2000. Disponível em http://www.ontoknowledge.org/oil/TR/oil.long.html. Acesso em 09 Ago. 2009.

[107] Lopes, José Geraldo Rodrigues Campos. Matching Semântico de Recursos Computacionais em Ambientes de Grade com múltiplas Ontologias. Dissertação Mestrado em Informática, Universidade de Brasília, 2005.

87

[108] Horrocks, I. et al. Reference description of the DAML+OIL ontology markup language. 2001. Disponível em http://www.daml.org/2001/03/reference.html. Acesso em 10 Ago. de 2009.

[109] Connolly, D. et al., DAML+OIL (March 2001) Reference Description, World Wide Web Consortium, Note 18, Dez. 2001. Disponível em <http://www.w3.org/TR/daml+oil-reference>. Acesso em 01 Set. 2001.

[110] Mcguinness, D. et al. DAML+OIL: An Ontology Language for the Semantic Web. IEEE Inteligent Systems. v. 17, n. 5, p. 72-80, Set. 2002.

[111] OWL API. “The OWL API”. URL: http://owlapi.sourceforge.net/.

[112] Horrocks. I.; Patel-Schneider, P. F.; Harmelen, F. V. From SHIQ and RDF to OWL: The Making of a Web Ontology Language. Journal of the Web Semantics, v. 1, n. 1, 2003, p.7-26.

[113] Freitas, F. L. G. Ontologias e a Web Semântica. XXIII Congresso Sociedade Brasileira de Computação – SBC’2003. Anais. v.8. III Jornada de Mini-Cursos de Inteligência Artificial . Livro Texto. p. 1-52.

[114] C. Zhou, L. Chia, and B. Lee, “DAML-QoS Ontology for Web Services”, Proceeding of the International Conference on Web Services 2004 (ICWS04), San Diego, California, USA, July 2004.

[115] D. Berrueta and L. Polo, “Measurement Units Ontology”, URL: http://idi.fundacionctic.org/muo/muo-vocab.html, 2008.

[116] Willrich, R.; Vicente, L. H.; Uriarte, R. B.; Prudêncio, A. C.; Cé, J. J. “Invocação Dinâmica de Serviços com QoS em Sessões Mul-timídia SIP”. I2TS, 2009, Florianópolis, SC, Brazil. 8th Internati-onal Information and Telecommunication Technologies Sympo-sium, 2009.

[117] Sirin, E. et al. (2007). “Pellet: The Open Source OWL DL Reasoner”. Em Web Semantics: Science, Services and Agents on the World Wide Web, vol. 5(2), pág. 51-52.

[118] BMIR (2009). “The Protégé Ontology Editor and Knowledge Acquisition System”. Em http://protege.stanford.edu/.

UNIVERSIDADE FEDERAL DE SANTA CATARINA José Cé Júnior U …

Documents

Transcript of UNIVERSIDADE FEDERAL DE SANTA CATARINA José Cé Júnior U …