INICIAO CIENTFICA - COTAS

RELATRIO FINAL
1.1. NOME DO BOLSISTA: Tiago Xavier Cruz 1.2. TERMO DE OUTORGA N BOL 1.4. TELEFONE / CONTATO: (73) 88044071 1.6. CPF N.: 041563845-35 1.8. ORIENTADOR: Martha Ximena Torres Delgado 1.9. INSTITUIO: Universidade Estadual de Santa Cruz 1.11. UNIDADE / DEPARTAMENTO: Departamento de Cincias Exatas e Tecnolgicas 2. PERODO ABRANGIDO PELO RELATRIO: 10 / 03 / 2012 1.10. SIGLA: UESC 1.12. REA: /20 1.3. PEDIDO N /20

1.5. EMAIL: tiagoxavier18@yahoo.com.br 1.7. IDENTIDADE N.: 12616184-40

a 15/09/2012

3. TTULO DO PROJETO DE PESQUISA: Desenvolvimento de protocolos de comunicao usando a linguagem VHDL sobre FPGA

4. METODOLOGIA EMPREGADA: Bluetooth um protocolo de comunicao sem fio capaz de comunicar dois ou mais dispositivos baseando-se na arquitetura cliente-servidor [1]. O estudo geral do Bluetooth, realizado durante este projeto, pretendeu proporcionar uma maior compreenso sobre o funcionamento bsico deste protocolo, as principais camadas que o compem e como se d a comunicao entre elas. Este estudo foi bastante importante para auxiliar no desenvolvimento deste trabalho, pois com base nele podemos propor a descrio em VHDL dos circuitos que implementem suas funcionalidades [2][3][4][5]. (melhorar) Buscamos entender basicamente as piconets, unidades bsicas de um sistema Bluetooth, e as scatternets, rede constituda por mais de uma piconet, como mostrado na Figura 1 [6]. Uma caracterstica notria a presena de um nico dispositivo mestre em cada piconet, sendo que quando um escravo em uma piconet atua como o dispositivo mestre em outra, configura-se a topologia scatternet [1].

Figura 1 Piconet em funcionamento mestre escravo bsico (a), piconet com mltiplos escravos (b) e scatternet Quanto s camadas, percebemos que o padro Bluetooth tem muitos protocolos agrupados livremente em camadas. A estrutura de camadas no segue o modelo OSI ou qualquer outro modelo conhecido, entretanto, a arquitetura bsica dele est estruturada como na Figura 2 [1].

Figura 2 Pilha de Protocolos Bluetooth Nesta primeira fase de estudo, o foco foi direcionado ao grupo de protocolos de transporte, onde se encontra a camada L2CAP, Figura 3 [6]. A metodologia utilizada, buscando obter um aprendizado completo sobre os protocolos de transporte seguiu o esquema mostrado na Tabela 1 e descrito nos pargrafos seguintes.

Figura 3 Comunicao entre as camadas do Grupo de protocolos de transporte.

Tabela 1 Etapas para estudo do Grupo de protocolos de transporte ETAPAS CAMADA Etapa 1 Etapa 2 Etapa 3 Etapa 4 RF (Camada de rdio) Baseband (Camada de banda bsica) udio e Link Manager L2CAP

Foi feito um estudo sobre a camada de rdio do protocolo, pois percebemos a importncia de compreender num nvel mais baixo (bits) o que o protocolo fazia com os pacotes e comandos que recebia das camadas superiores. Esta camada, basicamente, move os bits do mestre para o escravo (Cliente-Servidor). Ela um sistema de baixa potncia com um alcance de 10 metros, operando na banda ISM de 2,4GHz, fornecendo uma taxa de dados igual a 1Mbps [1][6]. Em uma etapa posterior, o foco do nosso estudo foi direcionado camada Baseband, camada de banda bsica do Bluetooth. Percebemos que esta camada transforma o fluxo bruto de bits em quadros e define alguns formatos importantes. Em sua forma mais simples, o mestre de cada piconet define uma srie de slots de tempo de 625us, com as transmisses do mestre nos slots pares e as transmisses dos escravos nos slots mpares. Essa a tradicional multiplexao por diviso de tempo [1][6]. Cada quadro transmitido sobre um canal lgico, chamado de enlace, entre o mestre e um escravo. Com base nos estudos, verificou-se que existem dois tipos de enlaces, o ACL (Asynchronous Connection-Less) e o SCO (Synchronous Connection Oriented), sendo que o ACL o mais importante em nosso estudo, pois o tipo de enlace usado para dados oriundos da camada L2CAP, foco do projeto [6]. Durante a fase final do projeto, nossos esforos se concentraram em concluir o estudo sobre o protocolo L2CAP (Logical Link Control and Adaptation Protocol), outra parte da subcamada MAC no Bluetooth e a implementao das suas funcionalidades. O estudo foi realizado usando como base a especificao Bluetooth v2.1, a qual descreve as funcionalidades essenciais que devem ser providas pela camada, bem como a forma de interfaceamento com as demais camadas adjacentes. (Teoria sobre a camada L2CAP) O Protocolo de Controle e Adaptao de Enlace Lgico (L2CAP) permite que aplicaes de camadas superiores transmitam e recebam pacotes de at 64 KB, trabalhando apenas com um enlace do tipo ACL. Ela est localizada logo acima do protocolo de Banda Bsica (Baseband) do Bluetooth e, assim como o LMP (Link Manager Protocolo), protocolo de controle de acesso ao meio ou gerenciador de enlace, confia nos mecanismos de deteco de erro realizados pela camada de Banda Bsica. Dentre as caractersticas do L2CAP esto a simplicidade e o baixo overhead, o que o torna apropriado para dispositivos com pouca memria e capacidade de computao limitada, como celulares, computadores de mo e PDAs. O overhead aliado tambm de uma caracterstica desejada pelo Bluetooth, que a eficincia energtica, pois permite um alto aproveitamento da banda sem por isso consumir muita potncia. Outra caracterstica do protocolo que ao contrrio do LMP, a L2CAP tem a capacidade de se comunicar com outros protocolos, como o protocolo de descoberta de servios (SDP - Service Discovery Protocol), RFCOMM e especificaes de controle de telefonia (TCS - Telephony Control Specifications). Alm disso, apesar de aplicaes que envolvem udio e telefonia estarem associadas trabalharem em enlaces SCO da Banda Bsica, comunicaes que trabalham com udio em forma de pacotes (Telefonia IP, por exemplo) tambm podem se comunicar com o L2CAP e os pacotes so tratados como dados comuns. Entretanto, o estudo realizado com base na especificao proporcionou apenas a compreenso geral da camada, como descrito anteriormente, bem como de suas funcionalidades. Este documento possui um carter muito generalista, no descrevendo com clareza as especificaes funcionais necessrias para uma implementao direta a partir dele. O carter generalista verificado neste documento de especificao ruim para o objetivo do projeto, no entanto devemos considera-lo, pois a elaborao deste documento foi realizada com o intuito de servir como base para os fabricantes do dispositivo, proporcionando uma maior liberdade de implementao para cada um deles. Ainda assim, esta fase de pesquisa bibliogrfica forneceu uma lista de requisitos e funcionalidades que devem ser implementados como servios disponibilizados pelo protocolo. A Figura 4 [6] divide a camada L2CAP em seus componentes arquiteturais. Ela mostra como ocorrem as comunicaes com outras camadas e onde as funcionalidades podem atuar. A descrio geral das atividades realizadas por cada uma das funcionalidades

apresentado na Tabela 2.

Figura 4 Arquitetura em blocos da camada L2CAP Tabela 2 Funcionalidades propostas pela L2CAP Funcionalidade Descrio Multiplexao de protocolo/canal Durante a configurao do canal, essa funo usada para encaminhar o pedido de conexo ao protocolo da camada superior correta. O controle do tamanho dos pacotes das camadas superiores dado ao L2CAP. Ela faz segmentaes e remontagens de acordo com a necessidade. Usado quando diferentes fluxos de dados rodam num mesmo enlace lgico L2CAP em canais distintos. Nesse caso, cada canal pode pedir controle individual de fluxo. Essa funcionalidade opcional. No caso da aplicao requerer uma taxa de erro menor que a Banda Bsica pode oferecer, o L2CAP fornece tratamento opcional de checagem de erros e retransmisso dos PDUs locais. As camadas inferiores podem precisar com tamanhos de pacotes diferentes dos criados pela segmentao do L2CAP. Para resolver esse problema a camada cria fragmentos para atender as especificaes das camadas inferiores. possvel que, durante o estabelecimento da conexo L2CAP, os dois dispositivos Bluetooth troquem informaes a respeito da QoS esperada.

Segmentao e Remontagem

Controle de Fluxo por Canal L2CAP

Controle de Erro e Retransmisses

Fragmentao e Recombinao

Qualidade de Servio

Outra caracterstica que pode ser compreendida durante o estudo da especificao foi o formato dos pacotes de dados usados pelo protocolo. Os pacotes so conhecidos como PDUs e um PDU L2CAP possui um formato

dependente do canal de comunicao que ser utilizado. No caso de uma canal orientado a conexo, um PDU nomeado de quadro bsico de informao, ou quadro B (Figura 5).

Figura 5 - Quadro B Na Figura 5, o campo referente ao tamanho indica o tamanho da carga til de informao, em octetos. Esse campo ocupa 2 octetos do PDU e tamanho da carga til pode variar de 0 a 65535 octetos. O campo ID do Canal tambm de 2 octetos e indica o ponto final de destino do pacote no canal. O campo carga til de informao, por sua vez, contm a informao propriamente dita e pode ter de 0 a 65535 octetos de tamanho. Com base nas informaes adquiridas a partir da especificao, tentamos propor um implementao para a funcionalidade que trabalha com o controle de fluxo dos canais L2CAP. Para isso, verificamos que cada ponto final de um canal L2CAP referido por um identificador no canal (CID - Channel ID). Existem vrios tipos de CIDs e a Tabela 3 mostra alguns, listando suas respectivas funes. Tabela 3 Identificadores do canal CIDs Funcionalidade Descrio 0x0000 0x0001 0x0002 0x0003-0x003F 0x0040-0xFFFF Identificador nulo Canal de sinalizao Canal de recepo sem conexo Reservado Alocado Dinamicamente

O identificador nulo (0x0000) um valor invlido e no deve ser usado. J os identificadores de 0x0001 a 0x003F esto reservados para funes especficas do protocolo. Os restantes so liberados para o uso das implementaes, desde que dois canais L2CAP no se comuniquem simultaneamente utilizando o mesmo CID Figura 6.

Figura 6 Comunicaes entre entidades L2CAP

A seta bidirecional representa um canal orientado a conexo onde os CIDs identificam cada ponto final do canal. A unidirecional representa um canal sem conexo onde o fluxo restrito a uma direo apenas. Neste caso, o CID da fonte representa o grupo de dispositivos que recebem os dados. No destino, o CID 0x0002 que identifica um canal sem conexo Por ltimo, a seta preta representa um canal reservado, que o canal de sinalizao. Ele serve para criar e estabelecer canais orientados a conexo, alm de negociar mudanas nas configuraes dos canais. Com base nestes dados, percebemos que a especificao no recomendava nenhum tipo de controle de fluxo especfico, passando esta responsabilidade para a implementao da camada. Dessa forma, a proposta foi usar o protocolo stop & wait, muito conhecido em redes de computadores, e um buffer do tipo FIFO para o armazenamento temporrio dos dados at que pudessem ser absorvidos. Neste protocolo, o emissor envia um pacote de cada vez, de seguida espera por um "acknowledgment" (ACK) do receptor, s depois de receber o dado que este pode enviar outro pacote. O receptor, por sua vez, s envia o ACK ao emissor se possui espao suficiente no "buffer" de recepo. Este mecanismo permitiu que PDUs no formato L2CAP pudessem ser enviadas, numa plataforma de simulao.
5. CONCLUSES: Percebemos que para a implementao de um protocolo de comunicao fatores como funcionamento do protocolo, parmetros de entrada e sada de dados, bem como parmetros de configurao, devem ser considerados e analisados criteriosamente. Devemos levar em conta, tambm, que algumas especificaes de dispositivos nem sempre possuem um completude na descrio de seus requisitos, muitas delas descrevem funcionalidades apenas de maneira geral, como foi o nosso caso. Entretanto, cabe ao implementador escolher qual a melhor abordagem a ser escolhida, levando sempre em considerao as necessidades de sua aplicao. O presente projeto proporcionou um grande aprendizado sobre as necessidades e dificuldades que podem ser encontradas quando propomos implementar um protocolo de comunicao deste nvel. Trabalhar com protocolos que atuam no nvel de camadas proporciona uma grande quantidade de desafios, dado a sua complexidade. 6. REFERNCIAS: [1] Tanenbaum, A. S., Redes de Computadores. Traduo da quarta edio. Elsevier, 2003, 945p. [2] Manual da placa Basys da Digilent (Xilinx). Disponvel em: <http://digilentinc.com/Products/Detail.cfm?NavPath=2,400,797&Prod=NEXY >. Acesso em: 20 de maro. 2012, 11:03:00. [3] Manual do ISE 9.2 da Xilinx. Disponvel em: < http://www.xilinx.com/itp/3_1i/ >. Acesso em: 20 de maro. 2012, 11:14:00. [4] Chu, Pong P. (2008), FPGA prototyping b VHDL examples. Editora Wile Interscience,. 440 p. [5] Ercegovac, M., Lang, T. and Moreno, J. (2000) Introduo aos sistemas digitais. Traduo: Jos Carlos Barbosa dos santos. Porto alegre: Bookman, 2000. 453 p. [6] Especificao Core Bluetooth V1.1, V2.1 e V3.0. Disponvel em <http://www.bluetooth.com >. Acesso em: 15 de maro de 2012. 7. ASSINATURA DO BOLSISTA 8. DATA: _____/______/______ ASSINATURA DO ORIENTADOR 9. PARECER DO ORIENTADOR:

10. PARECER DA INSTITUIO: