douglas vidal teixeira técnicas e middlewares para...

Douglas Vidal Teixeira

Técnicas e Middlewares para adaptação dinâmica de fluxos multimídia

MONOGRAFIA

COMUNICAÇÕES MÓVEIS

DEPARTAMENTO DE INFORMÁTICA

Programa de Pós-Graduação em Informática

Rio de Janeiro, dezembro de 2007

PUC-RIO Comunicações Móveis – 2/2007 – Prof. Markus Endler

ÍNDICE

1 Introdução 5

2 Técnicas entre aplicação e camadas inferiores 9

2.1. Compressão temporal de vídeo MPEG utilizando protocolo de

transporte baseado em taxa , com prioridades e estimação pró-ativa do

atraso dos pacotes 9

2.2. Controle de admissão de fluxos divididos em sub-camadas e

esquema para modulação dinâmica da interface rádio em redes sem fio

colaborativas 14

3 Middlewares para adaptação do fluxo em função do canal 21

3.1. Framework com suporte a QoS através de reconfiguração de fluxos

multimídia baseado em relatórios RSTP 21

3.2. Middleware para adaptação dinâmica através de relatórios SNMP 28

4 Conclusões 35

5 Referências 37


ÍNDICE DE FIGURAS

Figura 1: Mecanismo baseado em taxa controle de congestionamento do MMTP

....................................................................................................................... 11

Figura 2: Formato de um GOP do padrão MPEG ................................................. 12

Figura 3: Arquitetura da aplicação de streaming sobre MMTP ............................ 13

Figura 4: Rede ad-hoc de teste com os possíveis enlaces entre os nós e os

respectivos valores de RSI em dB ................................................................. 18

Figura 5: Estrutura do Middleware e do proxy para adaptação dinâmica ............. 22

Figura 6: Código exemplo do APSL ..................................................................... 23

Figura 7: Funcionamento do middleware de QoS diante de mudanças dinâmicas

na apresentação.............................................................................................. 24

Figura 8: Cenário para avaliação do Middleware de QoS..................................... 25

Figura 9: Validação do middleware – multiplexação dos fluxos em uma vídeo

conferência de acordo com as restrições de exibição do usuário. ................. 26

Figura 10: Taxa de perda de pacotes diante de modificação dinâmica do

codificador ..................................................................................................... 27

Figura 11: Taxa de quadros por segundo na aplicação cliente .............................. 28

Figura 12: Estrutura do middleware que utiliza o SNMP para a adaptação

dinâmica dos fluxos....................................................................................... 29

Figura 13: Formato da tabela no servidor de controle com as informações dos

usuários.......................................................................................................... 30

Figura 14: Procedimento de comunicação entre as entidades do middleware ...... 32

Figura 15: Comprovação do funcionamento do middleware através de

implementação e recepção de um fluxo em um PocketPC............................ 33


ÍNDICE DE TABELAS

Tabela 1: Avaliação da aplicação em comparação com streaming sobre

RAW UDP .................................................................................................... 13

Tabela 2: Fluxos da simulação definidos por nó de origem e destino, sub-

camadas hierarquizadas, qualidades e taxa de bits ............................. 18

Tabela 3: Número de fluxos admitidos............................................................ 19

Tabela 4: Valores médios de RSI (dB) para dois tipos de fluxos e os dois

esquemas de funcionamento de modulação da interface sem fio...... 19

Tabela 5: Relação da taxa da interface com a qualidade da apresentação

e suas configurações para áudio e vídeo ............................................... 31

Tabela 6: Relação do percentual de nível de sinal percebido com taxa da

interface........................................................................................................ 33

1 Introdução

Transmissão de fluxos multimídia trata-se de um serviço amplamente

difundido atualmente na Internet. Diversos provedores já disponibilizam de

ferramentas e mecanismos que possibilitam aos usuários o acesso a este tipo de

conteúdo. As ferramentas mais conhecidas são o Windows Media Player

(WINDOWS MEDIA PLAYER, 2007) e o Real Player (REALNETWORKS,

2007).

Entretanto, as novas tecnologias de acesso das chamadas 3ª e 4ª geração irão

permitir também o acesso à rede de dados em altas taxas para os dispositivos

móveis celulares. Outra vertente para a difusão do acesso com altas taxas para

usuários móveis é a popularização das redes locais sem fio (WLAN’s), que

utilizam o padrão IEEE 802.11. Devido ao baixo custo da tecnologia e à facilidade

de implementação, as WLAN’s estão se tornando cada vez mais numerosas,

proporcionando a cobertura de áreas cada vez maiores devido a novas técnicas de

acesso (que ampliam a cobertura do sinal) e de modelos de configuração (como o

padrão 802.11r que possibilita roaming entre múltiplos pontos de acesso ou as

redes mesh que possibilitam a incorporação de múltiplos roteadores sem fio a uma

mesma WLAN).

Percebe-se, portanto, que o acesso com altas taxas está cada vez mais

próximo do usuário móvel. Porém, até o presente momento, não foi padronizado

nenhum paradigma que incorpore esta nova configuração de acesso da melhor

maneira possível. A estrutura atual de acesso, principalmente para conteúdos

disponíveis na Internet, está consolidada sobre paradigmas e protocolos

desenvolvidos para redes onde os usuários são elementos estáticos. Um exemplo

desta afirmação é o protocolo de transporte mais utilizado pelas aplicações, o

TCP, cujas deficiências para redes móveis vêm sido discutidas com bastante

ênfase nos últimos anos (ELAARG, 2002).

Com o objetivo de mitigar tais limitações ou simplesmente de aprimorar a

qualidade do acesso para as aplicações mantendo a estrutura atual, principalmente

endler

trata-se -> é um serviço

endler

endler

paradigma não se padroniza!

Técnicas e Middlewares para adaptação dinâmica de fluxos multimídia Página 6

em virtude da ampla utilização da Internet, diversos mecanismos e técnicas vêm

sendo propostos, principalmente em camadas elevadas (acima da camada de

Transporte1), como por exemplo, o RTSP (Real Time Streaming Protocolo; RTP,

2003) que é uma estrutura na camada de sessão para a troca de relatórios sobre a

qualidade da transmissão, utilizando o RTP como protocolo de transporte. O

presente trabalho tem o objetivo de explorar algumas destas técnicas, enfocando

em aplicações destinadas à apresentação de fluxos multimídia.

A transmissão em tempo real de fluxos multimídia (streaming) é uma

aplicação baseada nos requisitos exigidos para transmissões em tempo real, como

em telefonia e broadcast de canais de TV. Ou seja, suportam mais perdas e menos

atraso na entrega dos quadros do que uma aplicação http (Hypertext Transport

Protocol), por exemplo. Neste sentido, o importante para a uma aplicação de

streaming é a continuidade da apresentação com o menor jitter possível. Portanto,

sacrificar alguns quadros para a manutenção do jitter em torno de zero e/ou a

diminuir a qualidade da apresentação para a diminuição do tamanho dos pacotes,

são opções possíveis que uma aplicação de fluxos multimídia permite. Ou seja, ao

mesmo tempo em que tais aplicações exigem rigorosos requisitos de qualidade de

transmissão, diversos outros mecanismos podem ser utilizados. Em redes móveis

onde as condições do canal são muito mais dinâmicas em comparação com redes

cabeadas, estes mecanismos passam a desempenhar um papel de importância

ainda maior para a continuidade da apresentação.

As técnicas disponíveis atualmente na Internet para streaming são:

• Stored Audio and Video Streaming. Trata-se da técnica mais

difundida pela popularização de provedores de conteúdo. É baseada

na existência de um cliente que faz a demanda pelo fluxo a um

servidor que a contém armazenada. O fluxo é enviado na rede com

restrições de tráfego de tempo real definidos pela taxa de

apresentação da mídia. À medida que os pacotes são entregues no

cliente, são imediatamente decodificados e apresentados, diminuindo

os atrasos necessários para a “bufferização” do arquivo inteiro. Neste

mecanismo a mídia entregue pode ser armazenada ou não (os

1 Por camadas entenda-se o modelo de camadas OSI.

endler

são opções possíveis que uma aplicação de fluxos multimídia permite.


quadros que chegam são decodificados, apresentados e, em seguida,

descartados), dependendo da arquitetura da aplicação. Tais

aplicações podem controlar a taxa da apresentação e as restrições de

atraso2 e perda de pacotes são as menos restritivas em comparação

com as demais técnicas descritas abaixo.

• Live Audio and Video. Representa a uma nova categoria de

aplicações multimídia que estão sendo incorporadas às redes de

pacotes, onde um conteúdo é gerado em tempo real por um servidor

e transmitido (por exemplo, em regime de broadcast) para os

usuários. Geralmente, nestas aplicações o conteúdo transmitido não

é proposto para ser armazenado nos receptores, em vista das próprias

limitações de espaço físico dos mesmos. Este tipo de técnica engloba

IPTV, por exemplo. As restrições de atraso já são mais restritivas em

vista da geração ininterrupta do conteúdo. Taxa de perda de pacotes

do canal não é um fator tão restritivo, pois o fluxo majoritário é

apenas unidirecional (fonte para receptores), permitindo que a vazão

seja totalmente aproveitada para a adição de overhead proveniente

de mecanismos de correções de erros. Além disto, pode-se utilizar

“bufferização” de pequena escala (em torno de centenas de

milésimos de segundos) para a manutenção do jitter sem grandes

perdas na qualidade da apresentação.

• Real Time Interactive Audio and Video Streaming. Similar à

técnica anterior, com a adição da interatividade. Neste tipo de

streaming, tanto o atraso quanto a perda de pacotes são

extremamente restritivos. Não existe mais um cliente e um servidor:

todos os participantes são fonte e destino, simultaneamente, gerando

uma alta taxa de tráfego em tempo real. Gastos em overhead

geralmente não são toleráveis em vista do alto consumo de banda

requerido. Além disso, o canal ainda é assimétrico pois um indivíduo

pode se comunicar com vários ao mesmo tempo, transmitindo em

2 O termo “manutenção do atraso”, quando empregado para tráfego em tempo real (tráfego

gerado em taxas fixas), implica diretamente na manutenção do jitter em torno de zero.

endler

está

endler

incorporadas


regime de broadcast e recebendo os múltiplos streams individuais

em regime unicast. Tal situação pode aumentar ainda mais a

complexidade dos mecanismos empregados nas camadas de

transporte e aplicação para a manutenção do atraso e da qualidade

da apresentação, respectivamente.

Este trabalho tem o propósito de analisar algumas soluções que mais se

destacaram dentro de uma ampla pesquisa no tocante de técnicas e middlewares

atualmente propostos ou desenvolvidos, para a adaptação “on the fly” da

qualidade dos fluxos multimídia em função da qualidade do canal de transmissão

de dados. Em vista disto, as soluções consideradas são apenas às que incorporam

ao contexto do par transmissor-receptor as questões de Qualidade de Serviço em

redes de pacotes, isto é: banda necessária, taxa de perda de pacotes, taxa de erro

de bits do canal, atraso fim a fim, atraso nos enlaces das rotas, desconexões

devido à handoffs e baixa relação sinal-interferência percebida no canal de

comunicação sem fio. Middlewares cujo escopo do contexto do usuário móvel

foge às condições de transmissão, como limitações de displays, memória,

processamento, etc, não estão dentro do escopo do presente trabalho. Exemplos de

Middlewares que adaptam o fluxo multimídia dentro destes parâmetros de

contexto são o GRACE (YUAN et al, 2003), iConnect plug-in (WIJNANTS,

2006) e o trabalho descrito por MOHAPATRA (2003) cuja preocupação é o

consumo de energia.

O restante do trabalho está dividido da seguinte maneira: no capítulo 2 será

abordado uma técnica e um modelo analítico que adaptam o fluxo aplicando

compressão temporal e divisão em sub-camadas, respectivamente, através de

mecanismos nas camadas de transporte, de rede e de enlace (MAC); capítulo 3

apresenta dois middlewares que reduzem a qualidade do vídeo através da

modificação de diferentes parâmetros, como mudança de codificadores e extração

de fluxos multiplexados, baseado em medições de rede, provenientes de

mecanismos existentes nas aplicações, como relatórios do RTSP e do SNMP

(Simple Network Management Protocolo); capítulo 4 finaliza com comparações e

conclusões.

endler

no tocante de -> em

endler

as questões -> parâmetros de ...

endler

Middlewares cujo escopo do contexto do usuário móvel foge às condições de transmissão,

2 Técnicas entre aplicação e camadas inferiores

Neste capítulo serão abordadas técnicas que utilizam informações da

qualidade do fluxo multimídia provenientes da aplicação em conjunto com

parâmetros particulares de camadas inferiores, como por exemplo, o atraso médio

do canal (camada de rede) ou a modulação vigente na interface de rede (camada

de enlace).

2.1.Compressão temporal de vídeo MPEG utilizando protocolo de transporte baseado em taxa, com prioridades e estimação pró-ativa do atraso dos pacotes

TEIXEIRA e MAGALHÃES (2005) propõem um framework que atua na

camada de aplicação e na camada de transporte. Trata-se de uma aplicação que

utiliza um protocolo de transporte desenvolvido para a entrega de fluxos

multimídia, com a capacidade de utilizar múltiplas interfaces (se presentes) para o

envio balanceado do fluxo.

O protocolo em questão é o MMTP (MAGALHÃES e KRAVETS, 2001),

“Multimedia Multiplexing Transport Protocol”, ainda não padronizado e com

implementação sobre UDP (ainda não existe módulo de sistema operacional). A

pertinência deste protocolo é sobre a falta de suporte especializado, dentre os

atuais protocolos de transporte presentes, para fluxos multimídia. Os autores

defendem que UDP pode causar congestionamentos nos gargalos por não prover

nenhum tipo de controle nem verificação do atraso do canal. Ainda, os

proponentes do MMTP afirmam que o RTP provê apenas um cabeçalho à

estrutura do UDP, deixando todo o controle de fluxo e de congestionamento a

cargo da aplicação, que necessita do suporte dos relatórios enviados pelo

RTCP/RTSP.

O MMTP é baseado em taxa (rate based). A transmissão realizada em

intervalos regulares, definidos de acordo com a aplicação. Ele utiliza o envio

periódico de pacotes de sondagem para a estimação do atraso médio do canal,

através da técnica de packet pair probing (um pacote pequeno é enviado seguido

endler

pertinência????

endler

é sobre a falta de suporte especializado (Não entendí)

endler

Encurtar o título de subseção


do envio de outro, de tamanho bem maior, permitindo que o atraso seja estimado

na recepção através da comparação dos timestamps do atraso entre os pacotes de

sondagem). O receptor e o transmissor também trocam, periodicamente, as

informações para a estimativa de ambos os sentidos do canal. A sondagem

permite a estimação do momento em que um determinado pacote efetivamente

será entregue, já que o envio é regular, baseado na taxa imposta pela aplicação.

Pacotes a serem enviados cuja estimativa de entrega excede o atraso permitido,

são descartados na aplicação, evitando congestionamentos.

Pacotes que eventualmente são perdidos no caminho devido ao

congestionamento na rede, são percebidos na recepção de acordo com a avaliação

histórica dos prazos estimados. Isto é, um pacote cuja estimativa não excede o

prazo, quando não é entregue, faz com que o protocolo verifique na recepção se os

anteriores estavam excedendo as estimativas. Se a estimativa estava sendo

excedida, é assumido descarte no transmissor, caso contrário é assumido perda por

congestionamento e esta informação é entregue para o transmissor que diminuirá a

taxa de envio. Este mecanismo exige a ordenação e buffers para os pacotes. Esta

característica também é utilizada para a multiplexação através de múltiplas

interfaces, se presentes. Desta forma, se um transmissor dispõe de duas conexões

distintas de rede, a transmissão é balanceada através das estimativas de cada canal

e da taxa exigida pela aplicação (Figura 1).


Figura 1: Mecanismo baseado em taxa controle de congestionamento do

MMTP

Ainda, o MMTP pode dar prioridades diferentes para os pacotes

transmitidos. Desta forma, pacotes de alta prioridade podem ser retransmitidos se

ainda estiverem dentro do prazo de entrega, enquanto que pacotes com a

prioridade mais baixa não sofrem nenhum tipo de retransmissão, mesmo se ainda

estiverem com tempo e banda disponíveis, aliviando o tráfego global do percurso.

Esta última característica pode ser empregada para o envio de quadros

MPEG. O padrão divide quadros de imagem em 12 sub-quadros, formando um

GOP (Group of Frames). Cada GOP divide os seus sub-quadros em 1 quadro do

tipo I (Intra-frame), 2 do tipo F (Forward Predicted Frame) e 9 do tipo B

(Bidirectionally predicted frame), através de relações temporais (vide Figura 2).

Quadros do tipo I são os maiores e mais importantes. Eles contêm a imagem

principal. Quadros do tipo F contêm alterações sofridas pelo quadro original I em

função do tempo. São menores do que os quadros I. Os quadros do tipo B são os


menores e fazem a relação entre as mudanças ocorridas entre os quadros I e F. São

os menores em relação a todos os outros.

Figura 2: Formato de um GOP do padrão MPEG

Seguindo esta relação, a aplicação particiona os quadros do fluxo e utiliza os

cabeçalhos do padrão MPEG para a estimativa do atraso e do tipo de quadro.

Desta forma, ao acionar o MMTP, a aplicação entrega os quadros para serem

empacotados de acordo com a prioridade requerida por cada um. A prioridade

empregada é mesma imposta pela relação temporal do GOP MPEG. Desta forma,

o fluxo é apresentado de acordo com taxa exigida de exibição e com compressão

temporal (descarte de quadros B, F e no pior dos casos I), de acordo com as

condições do canal. A estrutura da aplicação está apresentada na Figura 3.


Figura 3: Arquitetura da aplicação de streaming sobre MMTP

As bordas da aplicação (parse e mpeg_play) se comunicam com o MMTP

via porta UDP, preferencialmente via pipe local. A aplicação foi avaliada através

de comparação com UDP, com o envio de um vídeo com um total de 100 quadros

(416 KB), sem áudio, em canais com diferentes capacidades de vazão e sem

tráfego concorrente. Na recepção é contabilizado o número de quadros que

chegam e são efetivamente decodificados. Os resultados podem ser vistos na

Tabela 1.

Tabela 1: Avaliação da aplicação em comparação com streaming sobre RAW

UDP

Quando o canal é muito ruim (9,6 kbps), o MMTP entrega menos quadros

do que UDP em vista do não cumprimento dos prazos, enquanto que o UDP fará o

envio de qualquer forma. À medida que a capacidade do canal aumenta (19,2 até

115,200 kbps), o MMTP consegue melhor utilização do canal por descartar

(bit por seg)

endler

(indicar fonte)

endler

(indicar fonte)


quadros na origem, diferentemente do UDP que sofrerá mais perdas em função

das colisões causadas pela própria aplicação. Quando existe banda suficiente para

acomodar o fluxo, ambos os protocolos se comportam de maneira semelhante.

Pode-se concluir que a aplicação consegue otimizar a apresentação

multimídia mesmo quando as condições do canal estão aquém do esperado,

penalizando a qualidade em níveis gradativos. Entretanto, cabe ressaltar que a

estrutura só pode ser aplicada para mídias que permitem a divisão em sub-fluxos

com prioridades diferenciadas. Entretanto, o MMTP tem que ser avaliado quanto

ao overhead imposto pelas sondagens e pelos relatórios trocados. Além disto, a

abordagem do MMTP de prever a banda disponível pode tornar o seu

funcionamento abaixo do esperado quando estiver concorrendo com tráfego

gerado por protocolos de transporte mais agressivos, como os próprios TCP e

UDP.

2.2. Controle de admissão de fluxos divididos em sub-camadas e esquema para modulação dinâmica da interface rádio em redes sem fio colaborativas

MASTRONAARDE et al (2007) propõe um algoritmo de controle de

admissão baseado em prioridades dos fluxos multimídia e dos requerimentos de

transmissão exigidos (taxa de bit e atraso). O objetivo do trabalho é propor um

esquema cross-layer para redes onde a transmissão de dados é realizada através de

múltiplos saltos (que permita relaying) e com múltiplas rotas possíveis entre os

nós. Exemplos são redes mesh ou redes ad-hoc corporativas (onde existe uma

exigência dos nós participantes permitirem o encaminhamento do tráfego para

outros nós). Desta forma cada nó pode escolher se deve ou não agregar um

determinado fluxo ao tráfego de dados corrente e por qual rota o fluxo deverá ser

entregue.

A técnica é baseada na idéia de particionar um determinado fluxo

multimídia em vários sub-fluxos ou sub-camadas divididas em grupos de

qualidade. A qualidade de cada camada depende da prioridade e da taxa requerida

pelo fluxo. A prioridade de cada camada do fluxo depende de fatores específicos

de codificação, compressão (se houver) e restrições de prazos de entregas

(deadlines). A idéia original é obtida no trabalho de SHANKAR et al (2004) e

exemplos do procedimento do procedimento de particionamento de um fluxo em

endler

Encurtar o subtítulo


outros sub-fluxos com diferentes prioridades pode ser obtido em TURAGA e

VAN DER SCHAAR (2005). A prioridade de cada fluxo fornece também o grau

da distorção que ele pode sofrer no procedimento de particionamento.

O algoritmo funciona da seguinte maneira: um nó recebe vários fluxos de

vizinhos para o destino va, cada fluxo fx é associado a uma condição de

propagação entre va e o nó; Bx é a taxa requerida pelo fluxo; cada fluxo é

transmitido em um enlace com uma vazão esperada a

xG , dependente do valor da

taxa de interface a

xT , dada em função da modulação a

xθ e da probabilidade de

perda de pacote a

xε , dada em função do tamanho do pacote Lx e do nó de destino.

Desta forma infere-se a

xG da seguinte forma:

onde

e ( )a

xe θ é a taxa de erro de bit dada por

onde S é a relação sinal interferência no enlace (RSI) e µ e δ são constantes

específicas da interface rádio.

Periodicamente em intervalos de tempo pré-definidos, cada nó realiza a

medição da vazão esperada e compara com a taxa exigida pelo fluxo Bx. Se a

xG <

Bx o fluxo não será entregue, caso contrário o espera-se que o fluxo seja entregue

à taxa Bx.

Cada fluxo é enviado de acordo com a sua prioridade de camada, garantindo

desta forma eqüidade na distribuição dos fluxos. Todos os nós vizinhos que têm

fluxos a receber e condição de banda, o recebe por camada de prioridade. A

heurística também permite verificação de possíveis gargalos entre os nós,

permitindo que o nó intermediário não envie determinado fluxo se estes não


puderem ser entregues em condições mínimas de qualidade e de prazo de entrega.

Esta percepção de possíveis gargalos evita colisões e aumenta o atraso global da

rede. A admissão do fluxo é decidida em cada nó através da métrica. Entretanto,

os autores também propõem dois outros algoritmos de admissão: um baseado nas

informações obtidas dos fluxos já admitidos sobre os gargalos da rede e retirando-

os, portanto, da lista de possíveis caminhos; o outro é baseado na estimativa

realizada na origem até o destino, definindo no início da transmissão as rotas para

os sub-fluxos.

Obviamente, existe uma sinalização extra (overhead) para que haja a correta

sincronização entre os nós. Três grupos de informações de controle são trocados:

o primeiro grupo de informações é associado às características do fluxo, como a

taxa Bx, as prioridades (definidas pela codificação, etc) λx e as qualidades

associadas às diferentes camadas (dependente dos dois fatores anteriores na

relação); o segundo grupo de informações são as condições do canal como o RSI e

as taxas de perda de pacotes e de erro de bit; o terceiro grupo de informações

equivale às rotas associadas a cada fluxo.

Os autores também propõem um esquema entre a aplicação e a camada

MAC para a determinação do número ótimo do limite de retransmissões de

datagramas, de acordo com os prazos de entrega de cada pacote (a priori o número

de retransmissões definido para o padrão IEEE 802.11 é 7; ANSI/IEEE, 2003):

Onde Deadlinejx é o prazo para a decodificação do pacote jx, toverhead é o

atraso resultante aos procedimentos de ack’s e de escalonamento de transmissão

(pooling); tcur é o tempo atual e o é a operação “floor”. A partir deste limite, os

autores conseguem inferir o número médio de retransmissões utilizando a

probabilidade de erro de pacote:


Em seguida, utilizando o tamanho do pacote e a taxa da interface, é inferido

o tempo médio gasto para a entrega de um pacote:

Então, para os primeiros ηx pacotes do fluxo o tempo médio de entrega é

dado por:

ηx vai depender do tempo de pooling que cada nó possui para realizar a

transmissão ou do tempo médio obtido. O valor de tempo que maximizar a relação

, onde TSI(RX)rx

a é a parcela de

tempo que o nó de destino va disponibiliza para receber pacotes do fluxo x.

Para a validação, os autores realizaram simulações com nós utilizando

interfaces sem fio 802.11a com taxa máxima de 54Mbps, 8 níveis de modulações,

permitindo desta forma 8 diferentes valores para taxas de interfaces

dinamicamente. A rede de teste é dada pela Figura 4, os tipos dos fluxos

inseridos na rede, com suas prioridades λ, taxas de bits, possíveis sub-camadas e

os nós de origem e destino estão relatados na Tabela 2.


Figura 4: Rede ad-hoc de teste com os possíveis enlaces entre os nós e os

respectivos valores de RSI em dB

Tabela 2: Fluxos da simulação definidos por nó de origem e destino, sub-

camadas hierarquizadas, qualidades e taxa de bits

Os números de fluxos admitidos estão na Tabela 3.


Tabela 3: Número de fluxos admitidos

Número de sub-fluxos admitidos

ψ1 ψ2 ψ3 ψ4

2 2 4 4

Para ilustrar o esquema de otimização na escolha das taxas das interfaces,

uma outra simulação na mesma rede de testes foi realizada. O esquema dinâmico

proposto foi comparado contra a opção de utilizar o número de retransmissões e o

valor da modulação da interface, fixas (no caso, o número de retransmissões e a

modulação foram escolhidos a partir das médias obtidas nas simulações com

esquema dinâmico). Dois fluxos foram testados durante o tempo de envio de 300

quadros (quadros de vídeo), repetidos 3 vezes. O resultado está na Tabela 4.

Tabela 4: Valores médios de RSI (dB) para dois tipos de fluxos e os dois

esquemas de funcionamento de modulação da interface sem fio

v4 � v11 v2 � v9

Modulação dinâmica 27,31 34,57

N° de retransmissões e

taxa de interface fixas

24,96 29,09

Os resultados presentes na Tabela 2 conformam a eficácia do algoritmo em

manter a eqüidade na recepção dos fluxos entre os usuários. Os dois primeiros

pares transmissor-receptores disputavam a mesma região, ambos exigindo fluxos

com alta taxa de bits e, portanto, ambos foram penalizados perdendo as duas

últimas sub-camadas menos importantes. Os dois outros pares transmissor-

receptores também disputavam a mesma região, porém o último fluxo requerido

era menos exigente em termos de taxa de bits, permitindo que os recursos na rede

suportassem ambas as mídias com todas as suas sub-camadas.

A Tabela 3 demonstrou que o mecanismo de modulação da interface de rede

permitiu um ganho de até 5dB na RSI. Esse ganho pode ser considerado alto,

porém exige uma operação em conjunto e sincronizada entre um nó e seus


vizinhos. Ele é conseguido pelo ajuste entre fonte e receptor, diminuindo ou

aumentando a potência sincronamente. Isto permite que a RSI entre o conjunto

dos nós.

Os resultados não são comparativos, pois não foi utilizado nenhum outro

algoritmo concorrente nas simulações. Os testes para o módulo de adaptação

poderiam ser comparados com os que são aplicados nas interfaces de fabricantes

conhecidos. Entretanto, os resultados corroboram a idéia principal do algoritmo

que é fazer uma distribuição justa do conteúdo, em função das condições de QoS

presentes na rede. Adicionalmente, o algoritmo permite que seja proposto um

esquema para a modulação da taxa da interface que proporciona um ganho

significativo na qualidade da transmissão. Uma idéia similar para a utilização dos

múltiplos caminhos pode ser visto no proxy-framework proposto em MUSHTAQ

e AHMED (2006), validado através de simulações e com uma abordagem

matemática menos exigente, dependente de RTSP para a avaliação da rede.

3 Middlewares para adaptação do fluxo em função do canal

Neste capítulo serão abordados dois middlewares que provêem o envio de

fluxos multimídia com adaptação dinâmica em função de condições de rede e do

equipamento do cliente. O primeiro utiliza o RTSP para obter parâmetros de perda

da rede e realizar adaptações previstas pela aplicação. O segundo utiliza uma

versão alterada do SNMP para as estimativas e também realiza modificações

previstas. Ambos são baseados em ferramentas proprietárias.

3.1. Framework com suporte a QoS através de reconfiguração de fluxos multimídia baseado em relatórios RSTP

LAYAIDA et al (2004) construíram um framework com o principal

objetivo de facilitar o desenvolvimento de aplicações. O framework provê uma

linguagem de alto nível que é compilada para lidar com módulos de baixo nível

destinados a codificação e recodificação das mídias, e com a obtenção das

estimativas de rede (taxa de perda de pacotes e RTT). Entretanto, os valores para a

determinação dos níveis de QoS ainda devem ser impostos pelo desenvolvedor da

aplicação.

Basicamente, o módulo de adaptação é montado sobre um middleware

baseado em uma estrutura de servidores e proxys. Ele provê uma API que recebe e

decodifica código XML para operar nas camadas inferiores do middleware. De

acordo com as condições impostas pela aplicação, módulos são inseridos,

removidos, conectados e desconectados. A validação do módulo é corroborada

com uma aplicação web que provê vídeo conferência, implementado em um

proxy.

A estrutura da middleware e do proxy podem ser vistos na Figura 5.

Existem três níveis básicos que dividem as funcionalidades do middleware: nível

de especificação, nível de controle e nível de execução. O nível de especificação

define construtores para a aplicação através de uma linguagem XML denominada

APSL (AdaPtive media Streaming Language). A linguagem provê um conjunto de

funções simplificadas para a verificação da qualidade da rede e das ações que


serão aplicadas nos fluxos. O nível de controle faz a tradução do APSL para o

nível de execução. O nível de execução incorpora os componentes de

processamento de mídia, incluindo os protocolos de transporte (TCP/UDP/RTP),

os protocolos de aplicação (HTTP, RTSP) e componentes de processamento de

mídia (codificadores, eliminador de quadros, configuradores de resolução e

mixers de áudio e vídeo). O middleware foi escrito em C++ na plataforma de

desenvolvimento Microsoft.NET e utilizando a biblioteca DirectX SDK (Software

Development Kit) versão 9.

Figura 5: Estrutura do Middleware e do proxy para adaptação

dinâmica

A Figura 6 exemplifica o APSL através de um trecho de código.


Figura 6: Código exemplo do APSL

O código realiza cinco tarefas: recebe o fluxo via UDP (tag “Input”),

decodifica (tag “Decoder”), especifica as dimensões (“Resizer”), recodifica em

MPEG (“Enconder”) com formato do tipo “32” através do parâmetro “fmt” (os

números que especificam o tipo de codificação são previstos pelo RTP) e por

último envia sobre RTP para o destino (“Output”).

O segmento de código marcado na Figura 6 especifica as condições que

devem ser analisadas com os níveis de QoS requeridos e as ações que deverão ser

tomadas para a acionar o procedimento de re-configuração do fluxo. As tags

“Probes” definem os eventos (“Events”) e as tags “Condition” especificam as

ações (“Action”). No caso, duas políticas foram definidas.

A primeira política especificada, identificada por “EVT1”, define que se a

perda de pacotes exceder a 10%, a qualidade do codificador é diminuída (um

mesmo codificador para um determinado tipo de vídeo pode ter diferentes níveis

de codificação dentro da biblioteca utilizada pelos módulos empregados). A

segunda política é mais radical (“EVT2”), quando a perda exceder 50% de perda,

o codificador será alterado para H261, previsto através do código de formato

(“fmt”) “31”. A primeira modificação exige uma mudança leve, alterando-se a


qualidade do vídeo com ações “get/setQuality” no componente em já em

utilização, não exigindo que o streaming seja interrompido. A segunda mudança é

estrutural e exige a mudança do componente que realiza a codificação. O

componente é removido e um novo é alocado. Esta alteração provoca paralisação

da apresentação em andamento. Basicamente o middleware provê apenas estes

dois tipos de ações: alteração da qualidade do codificador e alteração do

codificador. As implicações nas camadas inferiores (controle e execução) das

ações descritas acima estão destacadas na Figura 7.

Figura 7: Funcionamento do middleware de QoS diante de mudanças

dinâmicas na apresentação

No proxy, os módulos presentes na camada de execução realizam, na ordem

da Figura 7: a recepção do fluxo RTP do transmissor, a decodificação dentro do

formato recebido (no caso MPEG), o redimensionamento imposto pelo cliente e

suas restrições de equipamentos, a correção do redimensionamento (determinados

formatos de imagens exigem valores específicos nas dimensões da apresentação),

a codificação do fluxo a ser enviado (módulo que é removido e inserido para

modificações estruturais ou simplesmente re-configurado para alterações leves) e

o envio via RTP. O último módulo (RTP sender) é o que recebe as estatísticas


enviadas pelos relatórios do RTSP de perda de pacotes e atraso médio. Estas

informações alimentam os módulos do gerenciador de recodificação (camada de

controle) que possui as especificações de QoS fornecidas pelo usuário. Quando

uma mudança estrutural é requerida, a camada de controle envia a informação no

início da seqüência de recebimento do fluxo (MPEG Decoder) para não “cortar” o

andamento o fluxo durante o procedimento de remoção e inserção.

Para a avaliação da proposta, foi montado um esquema que proporciona

uma sessão de vídeo conferência mediante um servidor proxy. O cenário está

demonstrado na Figura 8. O servidor é um desktop Pentiun 4 e os clientes são

PDA’s Compac iPAC H3970, processador de 400 MHz, 64 MB de RAM, sistema

operacional Pocket PC OS e acesso à rede via WLAN (802.11b) à 2 Mbps.

Figura 8: Cenário para avaliação do Middleware de QoS

O primeiro teste consistiu na entrada de um quinto elemento em uma

sessão de vídeo conferência já em andamento. Sem o proxy, o novo usuário não

teria como visualizar as outras quatro sessões dos usuários. Com o proxy, é

percebida as restrições de tamanho da imagem e os fluxos dos usuários

participantes são multiplexados, formando apenas um único fluxo (um novo

vídeo) que é enviado para o usuário dentro das dimensões adequadas (vide Figura

9). A qualidade na taxa da apresentação também obteve ganho. Sem o proxy, cada


fluxo recebido por um usuário era apresentado a uma taxa de aproximadamente 10

quadros/segundo para cada um. Com o proxy, a apresentação foi realizada na taxa

padrão do fluxo transmitido (no caso H261), 25 quadros/segundo.

Figura 9: Validação do middleware – multiplexação dos fluxos em uma

vídeo conferência de acordo com as restrições de exibição do usuário.

Em seguida, foi avaliado o ganho proporcionado pela recodificação. O

exemplo consistiu no envio de um fluxo MPEG em uma rede com taxa de perda

de pacotes crescente até o patamar de 50%. Neste momento o codificador é

alterado para H261 automaticamente pelo proxy. Durante a transição ocorre uma

paralisação de aproximadamente 500 ms na apresentação. Os autores relatam que

no servidor esta paralisação durou apenas 15 ms e que o restante do atraso

adicional é devido à adaptação da aplicação no cliente (destacado na Figura 10).

Após a mudança, a taxa de perda de pacotes fica abaixo de 10%, de acordo com


os autores, em função também da adaptação do terminal às novas condições (vide

Figura 10).

Figura 10: Taxa de perda de pacotes diante de modificação dinâmica do

codificador

Uma melhor visualização dos efeitos da recodificação pode ser analisada na

Figura 11 onde é demonstrada, para o mesmo experimento, a variação na taxa de

quadros por segundo no cliente. O tempo de ausência do vídeo também está

destacado. Pode ser observado que após a re-configuração, o fluxo atinge a taxa

padrão de 25 quadros/segundo.


Figura 11: Taxa de quadros por segundo na aplicação cliente

O middleware proposto fornece uma API de alto nível e de fácil utilização

para os desenvolvedores de aplicações multimídia. Entretanto, a solução é

proprietária e dependente dos relatórios do RTSP, que podem não ser

suficientemente acurados para reportar as condições reais de rede.

3.2. Middleware para adaptação dinâmica através de relatórios SNMP

O middleware apresentado em NU et al (2004) representa uma configuração

dos módulos do framework amplamente adotadas por outros middlwares, como o

“MOCHA” (REJAIE e KANGASHARJU, 2001)3, por exemplo, onde existe uma

estrutura cabeada dando suporte à usuários de uma, ou mais WLANs. Entretanto,

o diferencial da abordagem de NU et al é a utilização do SNMP para a avaliação

das condições de rede ao invés de RTSP/RTCP. A estrutura pode ser vista na

Figura 12.

3 Cabe ressaltar que o MOCHA implementa um esquema de popularidade das mídias

oferecidas pelo servidor de conteúdo para realizar um esquema de bufferização nos proxys da rede

e, consequentemente, o envio otimizado de acordo com a demanda dos usuários.


Figura 12: Estrutura do middleware que utiliza o SNMP para a

adaptação dinâmica dos fluxos

O middleware funciona da seguinte maneira: o servidor SNMP avalia o

nível de sinal dos usuários móveis (RSI) constantemente, com granularidade de 5

minutos (customizável); o nível de sinal, atingindo determinados níveis

configurados, aciona o processo de modificação que poder ser: modificação da

taxa do vídeo, eliminação do fluxo do vídeo, mantendo somente o fluxo de áudio

ou eliminação total do fluxo quando não há mais condições de manter a

apresentação em um determinado nível de qualidade. Esta última ação é

significativa quando a banda total da rede é considerada. Evitar uma transmissão

que seria mal sucedida pode permitir a liberação de recursos, úteis para outras

transmissões que estão em andamento.

Os níveis RSI são comparados com as respectivas taxas de interface wi-fi

por uma relação pré-existente. As taxas impostas pela RSI são comparadas com as

taxas exigidas pelos fluxos multimídia, estabelecendo, desta forma, os níveis que

acionam mudanças nos fluxos.

Ainda, de acordo com a Figura 12, dois servidores são utilizados, um para o

armazenamento das mídias e outra para a realização de controle. O servidor de

mídia utiliza soluções proprietárias da Microsoft. Para a codificação, é empregado

o “Windows Media Encoder”, que utiliza o formato de arquivos “Windows Media


Streams”. Para a realização das mudanças enviadas pelo servidor de controle, é

utilizado o “Microsoft Multimedia Services”. O controlador de mídia é uma

implementação do middleware (“Media Control Server”), desenvolvido em C# na

plataforma Microsoft .NET. Como o foco do middleware são PDA’s, as mídias

armazenadas são configuradas, a priori, com dimensões e taxas previstas pelo

padrão H261 (menos exigente do que MPEG).

O controlador de mídia é a inteligência do procedimento de adaptação

dinâmica. Ele possui duas entidades: o “http service” e o “Bandwidth Alert

Acceptation service”. O “http service” mantém tabelas de todos os usuários

móveis da rede, com o endereço IP, um timestamp indicando o tempo que o

usuário está dentro da estrutura e a taxa requerida pela apresentação (vide Figura

13). Estas tabelas mantêm os estados dos usuários quanto às mídias que estão

sendo transmitidas. Desta forma o controlador de mídia sabe qual a qualidade da

apresentação que o usuário está experimentando segundo os padrões presentes na

Erro! Fonte de referência não encontrada..

Figura 13: Formato da tabela no servidor de controle com as

informações dos usuários


Tabela 5: Relação da taxa da interface com a qualidade da apresentação e

suas configurações para áudio e vídeo

A banda disponível para cada usuário é avaliada constantemente pelo

“Bandwidth Alert Acceptation service” em comunicação direta com o servidor

SNMP. A banda é comparada com a taxa da apresentação de cada usuário,

presente nas tabelas mantidas no servidor de controle. Quando a taxa da

apresentação não está de acordo com a banda disponível para o determinado

usuário, o servidor SNMP envia uma mensagem para o “Bandwidth Alert

Acceptation service”, que informa a mudança para o “http service”. O “http

service”, por sua vez, aciona o servidor de streaming de mídia (Media Stream

Server) com a ação necessária de re-configuração. Este procedimento está descrito

na Figura 14. Durante o procedimento de adaptação, a apresentação sofre com

atraso imposto pelo procedimento de re-bufferização aplicado pelo “Media Stream

Server“, entretanto a sessão estabelecida inicialmente não é desfeita, evitando,

segundo os autores, atrasos muitos maiores.


Figura 14: Procedimento de comunicação entre as entidades do

middleware

O servidor SNMP permite configuração via XML em conjunto com banco

de dados. Ele precisa manter as informações da qualidade de rede atualizadas

constantemente, mesmo para os usuários móveis onde as variações do canal de

transmissão são mais dinâmicas. Para tanto, é necessária uma entidade portável,

instalada nos clientes, escrita em JAVA Ela é baseada em uma solução

corporativa existente para redes sem fio, o OpenNMS. A informação obtida na

realidade não é a banda disponível no canal para o usuário, mas sim o nível de

sinal presente. Este nível é comparado segundo os padrões da Tabela 6 para a

estimativa da taxa da interface, valor que efetivamente será utilizado na

comparação com a taxa exigida pela apresentação.


Tabela 6: Relação do percentual de nível de sinal percebido com taxa da

interface

Os autores do middleware não avaliaram comparativamente o protótipo. Ao

invés disto, eles comprovam a efetividade através da implementação e utilização

do middleware em um Pocket PC (Figura 15).

Figura 15: Comprovação do funcionamento do middleware através de

implementação e recepção de um fluxo em um PocketPC


O uso do SNMP não é a melhor solução para a avaliação da qualidade de

redes sem fio por não permitir intervalos muito pequenos de estimação (na ordem

de milesegundos). Porém, apresenta uma abordagem nova que pode ser

promissora, principalmente para a previsão das condições de determinadas

localidades em ambientes abertos, em função de determinada hora do dia, através

dos históricos que são mantidos pelo SNMP. A adaptação do fluxo prevê poucos

estágios que são basicamente controlados pela solução proprietária da Microsoft.

4 Conclusões

Neste trabalho foram abordadas algumas soluções para a adaptação

dinâmica de fluxos multimídia, em função do canal de transmissão. Esta

adaptação é vital para redes sem fio onde o canal de propagação implica em uma

variabilidade muito maior ao canal de transmissão de dados. A manutenção

dinâmica da apresentação visa manter a apresentação, com mínimas interrupções,

mesmo diante de mudanças no canal sem fio, ocasionadas pela mobilidade do

usuário ou por mecanismos de propagação do sinal rádio: reflexões, difrações,

refrações e sombreamentos. Manter a apresentação mesmo à custa da diminuição

da qualidade, pode aumentar muito a satisfação do usuário móvel, índice que é de

grande interesse pelos provedores de conteúdo ou de infra-estrutura de acesso.

O trabalho apresentado abordou técnicas e middlewares existentes para este

intuito. Dentre as técnicas abordadas, duas foram contempladas: a primeira

utilizando um protocolo de transporte baseado em taxa e outra utilizando as

múltiplas rotas em uma rede ad-hoc distribuída. Ambas as técnicas propostas são

baseadas em medições constantes na rede através de sondagens da troca de

pacotes de controle. Ambas necessitam que as mídias que possam ser

decompostas em camadas com diferentes prioridades. As variações nas condições

de rede são absorvidas através da remoção e inserção das camadas durante a

apresentação. A primeira possui protótipo implementado e resultados preliminares

comparativos apenas com UDP. A segunda apresenta um algoritmo mais

sofisticado e robusto, que permite além da escolha otimizada da admissão dos

fluxos, a implementação de um esquema de configuração dinâmica da taxa da

interface sem fio, proporcionando maior ganho no canal de transmissão.

Entretanto, a segundo somente foi avaliada mediante simulações.

Dentre os middlewares, as soluções contempladas são, pelo menos em parte,

proprietárias. Elas permitem adaptação do fluxo mediante avaliação da rede

proveniente de mecanismos distintos. A primeira utiliza os relatórios do RTSP e a

segunda avaliação do nível de sinal pelo SNMP. O RTSP é utilizado para reportar


a taxa de perda de pacotes. Este indicador está sujeito à disrupções abruptas na

transmissão que podem influenciar nos relatórios, fazendo com que cheguem tarde

demais para a aplicação. Ainda, o mecanismo implica em gasto adicional de

banda. A medição via SNMP pode ser mais útil, pois qualifica a rede de maneira

mais otimizada e pode, através de customizações, proporcionar mecanismos de

prevenção, ativando as mudanças nos fluxos antecipadamente. Entretanto, está

limitada à medição somente na última milha contemplada pela estrutura sem fio

enquanto que o RTSP faz a estimativa fim-a-fim.

Cada proposta apresenta suas melhorias, mediante abordagens distintas.

Certamente, a montagem de uma estrutura para o acesso rádio através de uma

estrutura proporcionada por middlewares, baseada em entidades distintas de um

framework, representa a melhor convergência das soluções propostas. Uma

abordagem interessante seria unir medições fim-a-fim entre servidores de

conteúdo e proxys com o RTSP e, na última milha (entre o proxy e os clientes),

através de um servidor SNMP. Na última milha, o protocolo de transporte pode

ser trocado pelo MMTP, mediante o controle da parcela de banda disponível para

cada um dos protocolos: TCP, UDP e MMTP. A parcela deve ser controlada em

vista da abordagem tímida do MMTP diante de protocolos mais agressivos.


5 Referências

ANSI/IEEE Std 802.11, 1999 Edition (R2003), 802.11: Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, IEEE, LAN/MAN Standard, 1999 (Revisto em 2003).

ELAARG, H. "Improving TCP Performance over Mobile Networks," ACM Computing Surveys, V 34, N 3. Setembro de 2002.

JMF – Java Media Framework. Pacote de bibliotecas em Java que incorporam ferramentas para exibição, transmissão e captação de fluxos multimídia. Página: http://java.sun.com/products/java-media/jmf/. Última atualização em Novembro de 2004.

LAYAIDA, O.; ATALLAH, S. B.; HAGIMONT, D. “Reconfiguration-

based QoS Management in Multimedia Streaming Applications”. Proceedings of the 30th EUROMICRO Conference (EUROMICRO’04). Rennes, França. Setembro de 2004.

LI, B.; JEON, W.; KALTER, W.; NAHRSTEDT, K.; SEO, J.-H. "Adaptive

Middleware Architecture for a Distributed Omnidirectional Visual Tracking

System" in Proceedings of SPIE Multimedia Computing and Networking 2000, Janeiro de 2000, pp. 101--112.

MAGALHAES, L. C.; KRAVETS R. “MMTP: Multimedia Multiplexing

Transport Protocol” The First Workshop on Data Communications in Latin America and the Caribbean SIGCOMM-LA 2001, 2001.

MASTRONARDE, N.; TURAGA, D. S.; VAN DER SCHAAR M. “Collaborative Resource Exchanges for Peer-to-Peer Video Streaming Over

Wireless Mesh Networks” in IEEE Journal on Selected Áreas in Communications, VOL. 25, NO. 1, Janeiro de 2007.

MoCA – Móbile Collaboration Architecture. Página: http://www.lac.inf.puc-rio.br/moca/overview.html. Último acesso em Novembro de 2007.

MOHAPATRA, S.; CORNEA, R.; DUTT, N.; NICOLAU A.; VENKATASUBRAMANIAN, N. “Integrated Power Management for Video

Streaming to Mobile Handheld Devices”. ACM - MM’03. Berkley, CA. Novembro de 2003.

MUSHTAQ, M. E AHMED, T. “Adaptive Packet Video Streaming Over

P2P Networks Using Active Measurements”. Proceedings of the 11th IEEE Symposium on Computers and Communications (ISCC'06). 2006.


NU, Y.; ZHU, Y.; LI, H. “Bandwidth Adaptive Multimedia Streaming for PDA

Applications over WLAN environment”. IEEE International Symposium on Industrial Electronics. Maio de 2004.

REALNETWORKS. Disponível em: http://www.realnetworks.com/products/index.html. Acessada em Novembro de 2007.

REJAIE, R. E KANGASHARJU, J. “Mocha: A Quality Adaptive

Multimedia Proxy Cache for Internet Streaming”. NOSSDAV’01, 25-26 de Junho, 2001.

RTP – Real Time Protocol.IETF RFC 3550 - http://www.rfc-editor.org/rfc/rfc3550.txt. Julho de 2003..

SHANKAR, S.; HU, Z; VAN DER SCHAAR, M. “Cross-layer optimized

transmission of wavelet video over IEEE 802.11a/e WLANs” in Proc.Packet Video, Dezembro de 2004.

TEIXEIRA, D.; MAGALHÃES, L. C. “A Free Software Streaming-Video

Application based on MMTP”. WFS 2005 – 6th International Workshop on Free Software, Porto Alegre, Brasil. Julho de 2005.

TURAGA, D. S.; VAN DER SCHAAR, M. “Cross-layer aware packetization strategies for optimized wireless multimedia transmission” in Proc. IEEE ICIP, Setembro de 2005.

WIJNANTS, M.; CORNELISSEN, B. LAMOTTE, W. DE VLEESCHAUWER, B. “An Overlay Network Providing Application-Aware

Multimedia Services”. ACM AAA-IDEA ’06. Pisa, Itália. Outubro de 2006.

WINDOWS MEDIA PLAYER. Aplicativo da Microsoft para apresentação de streamings multmídia. Disponível em : www.microsoft.com/windows/windowsmedia/. Acessada em Novembro de 2007.

YUAN, W.; NAHRSTEDT, K.; ADVE, S. V.; JONES, D.; KRAVETS, R. “Design and Evaluation of a Cross-Layer Adaptation Framework for Mobile

Multimedia Systems”. SPIE/ACM - Multimedia Computing and Networking Conference (MMCN), 2003.

douglas vidal teixeira técnicas e middlewares para...

Documents