tecnologias de comunicacao sem fio

Tecnologias de comunicao sem fio

Tecnologias para Dispositivos Mveis

Prof. George H. Silva

O que Computao Mvel

Definio:

Acesso a informao a qualquer lugar, a qualquer momento

TECDM 2

Uma definio mais tcnica

Processamento

Mobilidade

Comunicao sem fio

TECDM 3

Processamento

Dispositivo de processamento porttil e tipos variados

Pode ser levado para qualquer lugar

No deve contar com fonte de energia inesgotvel

TECDM 4

Mobilidade

No importa onde voc esteja

Idealmente, mas na prtica

TECDM 5

reas sem cobertura por falta de justificativa econmica ou dificuldades tcnicas: Tuneis Oceano reas pouco populosas

Evoluao da Comunicao sem fio

TECDM 6

1989 Produtos usando 900 MHz. 20 milhes de pessoas usavam os sistemas 1G. IEEE comea a trabalhar em um padro industrial para WLAN. 1991 Validao dos padres TDMA e CDMA nos EUA. Introduo da tecnologia micro celular. 1992 Introduo do sistema celular Pan-Europeu GSM (Global System for Mobile Communications, originalmente Groupe Spciale Mobile). 1994 Servios CDMA e TDMA. Produtos usando 2.4 GHz so produzidos. - Ericsson Comunicao entre telefones celulares e acessrios utilizando sinais de rdio (MCLink). 1997 Aps sete anos de pesquisa e desenvolvimento, aprovao do padro IEEE 802.11 Wireless. O projeto MCLink despertou interesse de outras empresas(Ericsson, Intel, IBM, Toshiba e Nokia).

Criado o consrcio Bluetooth SIG (Special Interest Group) para desenvolver padres que garantissem o uso dessa tecnologia. 1999 Padres IEEE 802.11b e 802.11a, com freqncias de 2,4 e 5 GHz (taxas de 11 e 54 Mbps). Criada a Wireless Ethernet Compatibility Alliance (WECA), para garantir a interoperabilidade entre dispositivos de diferentes fabricantes. 2000 Surgiram os primeiros hot spots. A WECA lanou o selo Wireless Fidelity (Wi-Fi). 2001 A companhia americana de cafeterias Starbucks implementou hot spots em sua rede de lojas. Os pesquisadores Scott Fluhrer, Itsik Mantin e Adi Shamir demonstraram que o protocolo de segurana Wired Equivalent Privacy (WEP) inseguro. 2002 A WECA passou a se chamar Wi-Fi Alliance (WFA) e lanou o protocolo Wi-Fi Protected Access (WPA) em substituio ao protocolo WEP. 2003 Padro IEEE 802.11g (2,4 GHz, 54 Mbps). Padro IEEE 802.11f (implementao de handoff). 2003 Surgimento de tecnologia 3G.

Taxas de 5 a 10 Mbps. Telefonia mvel de longo alcance. Acesso Internet em alta velocidade e Vdeo telefonia.

At dezembro de 2007, 190 redes 3G j operavam em 40. 2004 A especificao 802.11i aumentou a segurana, definindo melhores procedimentos para autenticao, autorizao e criptografia. 2005 Aprovada a especificao 802.11e, agregando qualidade de servio (QoS) s redes IEEE 802.11. 2006 Implementaes do padro 802.11n, que usa mltiplas antenas para transmisso e recepo, Multiple-Input Multiple-Output (MIMO), atingindo taxa nominal de transmisso de at 600 Mbps.

Comunicao sem fio

Existem vrios tipos de redes sem fio: WLAN

WWAN

WSPAN

WSN

WBAN

Existem diferentes tipos de tecnologiad que implementam essasredes: WiFi, Bluetooth, 2xG, 3G, 4G, IEEE 802.{11, 15, 16},

TECDM 7

TECDM 8

Multiplexao

consiste em agrupar vrios canais de informao no relacionados, de modo a transmiti-los simultaneamente em um mesmo meio fsico:

cabo,

enlace de rdio,

satlite,

fibra tica,

etc

TECDM 9

A multiplexao uma operao que consiste em agrupar vrios canais de informao no relacionados, de modo a transmiti-los simultaneamente em um mesmo meio fsico (cabo, enlace de rdio, satlite, fibra tica, etc) sem que haja mistura ou interferncia dos canais. A demultiplexao a separao dos canais, recuperando a informao individual de cada canal. Os motivos econmicos so os que determinam o uso da multiplexao nas mais diversas situaes. Apesar de um sistema que utiliza a multiplexao necessitar de mais equipamentos, muitas vezes o custo do equipamento multiplexador pode ser compensado pela economia gerada ao se compartilhar um mesmo meio de transmisso entre z canais

Tipos de multiplexao

multiplexao por diviso do espectro de frequncias

multiplexao por diviso do tempo

multiplexao por diviso de comprimento de onda.

TECDM 10

Multiplexao por Diviso de Freqncias

designada uma faixa de frequnia para cada canal:

TECDM 11

Multiplexao por Diviso de Frequncias FDM Na multiplexao por diviso de frequncias designada uma faixa de frequncia para cada canal. O sinal deve ser deslocado em frequncia para sua posio antes de ser realizada a multiplexao dos canais. O deslocamento do canal at uma posio especfica do espectro de frequncias feita atravs de um processo de modulao. Este processo deve ser feito de tal forma que o sinal modulado no interfira nos outros canais a serem multiplexados. A multiplexao FDM basicamente uma separao em frequncia dos z canais a serem multiplexados, resultando em uma sobreposio no tempo dos sinais. Em telefonia, a FDM implementada atravs de modulao AM - SSB, sendo designada uma faixa de 4 kHz para cada canal telefnico (300 a 3400 Hz)

Multiplexao por Diviso de Tempo

Os canais so amostrados, e suas amostras distribudas periodicamente no tempo atravs de um dos processo de modulao por pulsos

TECDM 12

Multiplexao por Diviso de Tempo - TDM Na multiplexao por diviso de tempo os z canais so amostrados, e suas amostras distribudas periodicamente no tempo atravs de um dos processos de modulao por pulsos. Desta forma os pulsos em uma linha multiplex TDM correspondem a intercalao dos pulsos de vrios canais. A criao do sinal TDM feita atravs da amostragem sincronizada de diversos canais, sendo que os pulsos de cada canal so deslocados no tempo em relao aos outros.

TECDM 13

Multiplexao por diviso de comprimento de onda

simplesmente a Combinao de Mltiplos Sinais pticos, com diferentes Comprimentos de Onda (Cores), devidamente espaados entre si e que so injetados e se propagam em uma mesma Fibra ptica.

TECDM 14

Multiplexao por Diviso de Comprimento de onda - WDM A multiplexao por diviso de comprimento de onda utilizada em sistema com fibras ticas, em conjunto com a multiplexao TDM, visando ampliar o uso da fibra com taxas de transmisso atravs de diodos LASER, e transmitido em uma nica fibra. O nmero de comprimento de ondas multiplexada utilizadas so 2, 4, 16, 40, 64 sendo as taxas de TDM 2.5Gbit/s, 10 Gbit/s e 40 Gbit/s. Nesta multiplexao cada sinal TDM transformado em um comprimento de onda diferente.

Wireless Local Area Network (WLAN)

Tecnologia: 802.11 {a, b, g, n, ac}

Aplicaes: Redes locais privadas e corporativas

Alcance: 30 ~ 100m

Velocidade: 54Mbps ~ 6.930 Gbps

TECDM 15

Uma WLAN usa ondas de rdio para transmitir dados e conectar dispositivos Internet e sua rede e aplicativos corporativos. No passado, considerava-se que as redes com fio eram mais rpidas do que as LANs sem fio. No entanto, hoje as LANs sem fio minimizaram essa diferena Os roteadores atuam como pontos de acesso na WLAN. Voc pode estender o alcance de uma WLAN com pontos de acesso sem fio adicionais em vrios locais. Os dispositivos de recepo, como laptops, telefones celulares e tablets tambm devem estar preparados para conectar WLAN. A segurana e a velocidade da WLAN aumentaram drasticamente nos ltimos anos. Para aumentar a segurana, necessrio: - Autenticao de usurios, para evitar acesso no autorizado a recursos de rede. - Criptografia de dados para proteger a integridade e a privacidade de dados transmitidos.

Specificao 802.11

TECDM 16

Segurana

WEP

WPA2-personal

WPA2-enterprise AES

TPKI

EAP

Estudo de Caso: Aeroporto da Frana

TECDM 17

O protocolo WEP, sigla de "Privacidade Equivalente de Redes com Fios", foi o pioneiro no assunto de proteo de redes sem fio, tendo sido lanado como um padro de segurana neste tipo de rede em 1997. Ele utiliza o algoritmo de criptografia RC4, que apontado por muitos como seu principal ponto negativo. Mesmo estando obsoleto no quesito segurana, o WEP continua sendo amplamente utilizado em residncias de todo o mundo, reflexo da falta de informao dos usurios de redes sem fio e da insistncia de fabricantes de pontos de acesso em permitir que ele seja um dos padres de segurana. Falhas Existem diversas falhas conhecidas h mais de uma dcada no protocolo WEP. Elas so muitas vezes exploradas por pessoas maliciosas que desejam prejudicar o uso da rede sem fio ou simplesmente obter acesso Internet. Entre as falhas mais graves, encontram-se a presente no mecanismo de confirmao de recebimento de quadros WEP, a possibilidade de inundao da rede com quadros repetidos e a fragilidade do algoritmo RC4. Acesso de Estranhos Dentre os diversos ataques existentes para a obteno da chave secreta utilizada no WEP, alguns se destacam pela simplicidade e tempo de execuo muito baixos, da ordem de minutos: Fora Bruta: A chave secreta do WEP possui 40 bits, valor relativamente alto, mas que, com o uso de ataques de dicionrio, isto , atravs da utilizao de nomes que so comumente utilizados, torna-se plausvel sua execuo. Conexo: Durante a conexo de um suplicante ao ponto de acesso, o desafio passa em claro e logo depois encriptado. Assim, possvel ter acesso ao mesmo contedo das duas formas, facilitando o processo de obteno da chave secreta.

Escuta: Existem outros tipos de ataque que conseguem recuperar a chave secreta a partir da escuta do trfego por alguns minutos, at que o valor do vetor de inicializao se repita. O maior agravante do processo de encriptao do WEP a utilizao da chave secreta (que no provisria), em todas as etapas. Assim, a descoberta deste valor significa a utilizao da rede at que o mesmo seja trocado pelo administrador da mesma. Wi-Fi Protected Access O protocolo WPA, sigla de "Acesso Protegido a Wi-Fi", foi criado em 2002 pela WFA (Wi-Fi Alliance) como postulante a substituto do WEP. Durante a sua concepo, foi dado um enfoque maior na correo das falhas de segurana encontradas neste protocolo. Dentre as melhorias propostas, a mais significativa foi a utilizao do algoritmo RC4 de uma forma mais segura, dentro do protocolo TKIP. Em 2004, a WFA lanou o sucessor do WPA, o WPA2, aps a descoberta de algumas falhas de segurana presentes no TKIP. Assim, para tentar contorn-las, ele foi substudo pelo protocolo CCMP, que faz uso de um algoritmo de criptografia simtrica muito robusto e amplamente utilizado, o AES. Extensible Authentication Protocol Tanto o WEP quanto o WPA possuem duas verses distintas, uma de uso pessoal, ou PSK (sigla de Chave Previamente Compartilhada, do ingls "Pre-Shared Key"), e outra de uso comercial. A grande diferena entre elas reside no fato de, enquanto a primeira funciona a partir do compartilhamento de uma chave secreta entre o usurio e o servidor, a outra requer um mtodo de autenticao parte, que realizado pelo protocolo EAP. O protocolo EAP, sigla de Protocolo de Autenticao Estendvel (do ingls "Extensible Authentication Protocol"), um arcabouo que permite que um usurio se autentique em um servidor especfico a fim de receber mensagens provenientes do ponto de acesso. Este servidor trabalha com o uso do protocolo RADIUS (Servio de Autenticao Remota de Chamada de Usurio) e tanto pode ser representado pelo ponto de acesso quanto por uma outra mquina dedicada a este fim. O primeiro passo para a conexo em uma rede sem fio que trabalho com o EAP o envio de uma mensagem de Requisio para o ponto de acesso. Este, por sua vez, retorna um pedido da identidade que o suplicante possui. Ao receber a resposta do suplicante, o ponto de acesso a envia diretamente para o servidor RADIUS. Ele, ento, cria um desafio pelo qual o suplicante deve passar com o uso da senha que ele possui. Assim, caso este responda de maneira correta, ter acesso rede sem fio; caso contrrio, receber uma mensagem de falha de conexo. Por fim, se o protocolo usado para encriptao for o WPA ou WPA2, ento ocorre o acordo entre o suplicante e o ponto de acesso a fim de decidir os valores de chaves temporais que sero usadas durante a comunicao.

Wireless Wide Area Network (WWAN)

TECDM 18

Tecnologia: GSM/GPRS, CDMA, WCDMA, 3G, 4G

Aplicaes: Telefones Celular e aparelhos com modem

Alcance: rea urbana, suburban e rural

Velocidade: 14.4Kbps ~ 1 Gbps

Caractersticas

Voz

Dados

SMS

MMS

Triangulao por GPRS

TECDM 19

Classes de SMS Class 0: Indicates that this message is to be displayed on the MS immediately and a message delivery report is to be sent back to the SC. The message does not have to be saved in the MS or on the SIM card (unless selected to do so by the mobile user). Class 1: Indicates that this message is to be stored in the MS memory or the SIM card (depending on memory availability). Class 2: This message class is Phase 2 specific and carries SIM card data. The SIM card data must be successfully transferred prior to sending acknowledgement to the SC. An error message will be sent to the SC if this transmission is not possible. Class 3: Indicates that this message will be forwarded from the receiving entity to an external device. The delivery acknowledgement will be sent to the SC regardless of whether or not the message was forwarded to the external device. MMS messages are delivered in a completely different way from SMS. The first step is for the sending device to encode the multimedia content in a fashion similar to sending a MIME e-mail (MIME content formats are defined in the MMS Message Encapsulation specification). The message is then forwarded to the carrier's MMS store and forward server, known as the MMSC (Multimedia Messaging Service Centre). If the receiver is on another carrier, the relay forwards the message to the recipient's carrier using the Internet.[5] Once the MMSC has received a message, it first determines whether the receiver's handset is "MMS capable", that it supports the standards for receiving MMS. If so, the content is extracted and sent to a temporary storage server with an HTTP front-end. An SMS "control message" containing the URL of the content is then sent to the recipient's handset to trigger the receiver's WAP browser to open and receive the content from the embedded URL. Several other messages are exchanged to indicate status of the delivery attempt.[6] Before

delivering content, some MMSCs also include a conversion service that will attempt to modify the multimedia content into a format suitable for the receiver. This is known as "content adaptation". If the receiver's handset is not MMS capable, the message is usually delivered to a web based service from where the content can be viewed from a normal internet browser. The URL for the content is usually sent to the receiver's phone in a normal text message. This behavior is usually known as the "legacy experience" since content can still be received by a phone number, even if the phone itself does not support MMS. Mtodos de Geolocalizao H trs populares maneiras de um agente de usurio descobrir sua posio no globo: Geolocalizao IP o mtodo usado pela maioria dos navegadores web em computadores. Atravs de consultas whois e servios de localizao de IP, vai determinar a cidade ou regio em que voc est. Triangulao GPRS Dispositivos conectados a uma rede de celulares e sem um GPS, ou com o GPS desligado, podem determinar sua posio pela triangulao das antenas GPRS prximas. bem mais preciso que o mtodo baseado em IP, vai mostrar em que parte do bairro voc est. GPS o mtodo mais preciso. Em condies ideais, a margem de erro de apenas 5 metros. Triangulao de antenas: http://developer.android.com/guide/topics/location/strategies.html

GSM - Groupe Spciale Mobile

Fase 1

- Telefonia (voz);- Chamadas de emergncia;- SMS;- Dados0.3 a 9.6 kbps- Transmisso de pacotes assncronos.

Fase 2

- e-mail;- Voz a meia taxa- Melhorias no SMS;- Servios de dados- Transmisso sncrona e dedicada de pacotes;- Servios adicionais

Fase 2+

- GPRS

TECDM 20

O GSM usa o TDMA (Acesso Mltiplo por Diviso de Tempo) e o FDMA (Acesso Mltiplo por Diviso da Frequncia). As frequncias disponveis so divididas em duas bandas O padro Groupe Spciale Mobile (GSM) foi criado inicialmente para ser um modelo pan-europeu pela Conference of European Postal and Telecommunications (CEPT), mas rapidamente viu-se que seria um padro com mbito internacional, assim em 1991, comearam a implantar o Global System for Mobile Communications (GSM) que era o primeiro padro GSM destinado utilizao internacional. Dentre vrias caractersticas do GSM destacam-se roaming internacional, alto grau de flexibilidade, infraestrutura e terminais de baixo custo, sinais de alta qualidade e segurana da linha [5]. A Unio Internacional de Telecomunicaes (UIT) inicialmente alocou frequncias de 935-960 MHz para downlink, da estao de telecomunicaes para o terminal mvel, e de 890-915 MHz para uplink, do terminal mvel estao, para o padro GSM 900. O terminal mvel, ou estao mvel (MS), juntamente com o Mdulo de Identificao do Assinante (SIM), certamente so os elementos mais conhecidos. O SIM um carto inteligente composto de um processador e um chip de memria que armazena as configuraes e identificao do usurio. Sem o SIM o terminal mvel fica inoperante. O BSS constitudo pela Estao Radiobase ou Estao Transceptora (BTS) e o Controlador de Estao Radiobase (BSC). O BSS realizar a interao entre a BTS e o terminal mvel. A BTS contm a antena, que com sua potncia devidamente regulada, ir definir o tamanho da

clula. O BSC tem a funo de monitorar e controlar um nmero de estaes radio base que definido pelo fabricante, podendo ser dezenas ou at centenas de BTS. O NSS o subsistema encarregado de fazer as conexes e o controle de bancos de dados requeridos durante uma chamada. constitudo pela Central de comutao de servios mveis (MSC), o registro local (HLR), o centro de autenticao (AuC), o registro de visitante (VLR) e o registro de identidade de equipamento (EIR). O MSC responsvel pela atribuio de canais aos usurios e a execuo e controle do handover, equivalente aohandoff no GSM. a parte central do NSS. O HLR o banco de dados que armazena os dados e a identidade dos usurios de sua regio de abrangncia e o AuC atua como parte integral ao HLR, autenticando os usurios. O VLR um banco de dados que contm informaes temporrias sobre assinantes que esto em roaming e requere ao HLR do visitante, dados sobre o mesmo. Por fim, o EIR foi criado para localizar e barrar possveis equipamentos roubados ou clonados. O OSS interage com os outros subsistemas, como o ISDN (Integrated Service Digital Network) entre outros, dando a oportunidade aos engenheiros de monitorar e gerenciar o sistema. Este subsistema tambm responsvel pela tarifao. Juntos os subsistemas iro registrar o usurio e realizar a chamada, encaminhando-a e registrando-a. Fase 1 Fase inicial, oferecia: - Telefonia (voz); - Chamadas de emergncia; - SMS (mensagens curtas) ponto a ponto e ponto multiponto; - Dados sncronos e assncronos (0.3 a 9.6 kbps); - Transmisso de pacotes assncronos. Fase 2 - Servios de e-mail; - Voz a meia taxa (half rate). Esse servio permite ampliar o nmero de usurios, abrindo mo de certa parcela da qualidade da voz; - Melhoras no SMS; - Servios de dados, como informaes sobre tempo, clima, esportes, entre outros; - Transmisso sncrona e dedicada de pacotes; - Servios adicionais como identificador de chamadas, chamada restrita, teleconferncia. Fase 2+ Introduziu o servio de dados por pacotes em altas taxas de transmisso (GPRS-General Packet Radio Service) na rede GSM. .

TECDM 21

Arquitetura da rede GSM

GPRS

TECDM 22

Redes de dados

TECDM 23

Tecnologia Mximo Download Mximo Upload

UMTS 2 Mb/s 384 Kb/s

HSPA 14,4 Mb/s 5,76 Mb/s

HSPA+ 168 Mb/s 22 Mb/s

LTE 300 Mb/s 75 Mb/s

Wireless Personal Area Network (WPAN)

uma rede para interligar dispositivos centrados na rea de trabalho de uma pessoa individualmente

TECDM 24

Uma rede para interligar dispositivos centrados na rea de trabalho de uma pessoa individualmente - em que as conexes so sem fio. O PAN sem fio baseado no padro IEEE 802.15. Os dois tipos de tecnologias sem fio so utilizados para WPAN so o Bluetooth e o Infrared Data Association.2

A principal tecnologia WPAN a tecnologia Bluetooth, lanada pela Ericsson em 1994, propondo um dbito terico de 1 Mbps para um alcance mximo de cerca de trinta de metros. O Bluetooth, conhecido tambm sob o nome IEEE 802.15.1, possui a vantagem de consumir muito pouca energia, o que o torna particularmente adaptado a uma utilizao em pequenos perifricos.

TECDM 25

Wireless Sensor Network (WSN)

Grupo de sensores disperses dedicados a monitorar e armazenaralguma informao do ambiente e organizer a informao numalocalidade central

TECDM 26

Wireless sensor network (WSN) refers to a group of spatially dispersed and dedicated sensors for monitoring and recording the physical conditions of the environment and organizing the collected data at a central location. WSNs measure environmental conditions like temperature, sound, pollution levels, humidity, wind speed and direction, pressure, etc.

TECDM 27

Exemplos de redes de sensores: - monitoramento de radiao em usina nuclear - Campo de batalha - Aplicaes para agricultura

Mobile Ad Hoc Network

Uma rede de computadores ad hoc aquela na qual todos os terminais funcionam como roteadores, encaminhando de forma comunitria as comunicaes advindas dos terminais vizinhos

TECDM 28

Em telecomunicaes, redes ad hoc so um tipo de rede que no possui um n ou terminal especial - geralmente designado como ponto de acesso - para o qual todas as comunicaes convergem e que as encaminha para os respectivos destinos. Assim, uma rede de computadores ad hoc aquela na qual todos os terminais funcionam como roteadores, encaminhando de forma comunitria as comunicaes advindas dos terminais vizinhos Redes ad hoc podem ser classificadas utilizando-se vrios parmetros. Redes simtricas ou assimtricas - Redes simtricas so aquelas em que todos os ns tm igual capacidade e dividem responsabilidades similares, ao passo que nas redes assimtricas, as capacidades de diferentes ns (tais como raio de transmisso, capacidade de processamento, velocidade de movimento etc.) e suas responsabilidades (como a de efetuar roteamento), variam de n para n. Tipo de trfego a ser transmitido pelos ns - O trfego pode ser de dados normais ou de dados em tempo real para aplicaes multimdia, como som e vdeo. Os esquemas e protocolos usados nas diferentes camadas de ns so em geral modelados para adaptar-se ao trfego transmitido. Mtodos de roteamento empregados nas vrias redes - De modo geral, a classificao do tipo de roteamento pode ser unicast, multicast ou geocast. Mtodos de endereamento podem ser baseados no host, no contedo ou at mesmo na capacidade.

Exemplo de rede Ad Hoc

TECDM 29

Wireless Body Area Network - WBAN

TECDM 30

Body Area Network ou Wireless Body Area Network uma rede sem fio de dispositivos computacionais wearables. Essa rede consiste de vrios sensores e atuadores conectados a uma unidade central que pode permitir acesso Internet. Esse conceito est muito ligado a idia da Internet das Coisas ou Internet of Things (IoT). Aplicaes mais provveis, acompanhamento e preveno de doenas, maximizao de resultados de atletas, etc

Bluetooth

Principal tecnologia para WPAN

Transmisso por ondas de rdio a 2.45GHz

Especificao Cada canal dividido em slots de 625 microsegundos Pacotes podem ter at 5 slots de tempo de tamanho Cada pacote deve ter no mximo 2.745 bits Utiliza a tcnica de espalhamento espectral por salto de

frequncia (spread-spectrum frequency hopping)

TECDM 31

Na tcnica de spread-spectrum frequency hopping, um dispositivo usa 79 frequncias diferentes escolhidas aleatoriamente dentro de uma faixa definida. O transmissor troca de frequncia 1600 vezes por Segundo. A empresa que iniciou o desenvolvimento do Bluetooth foi a Ericsson. Os membros fundadores do Bluetooth Special Interest Group so: - Ericsson, Nokia, IBM, Intel e Toshiba Hoje j so mais de 1900 membros.

Bluetooth ver. 1.0

Vantagens Wireless

Sem necessidade de configurao

Baixo consumo de energia

Grande adoo da indstria

Disvantagens Curto alcance (10 metros)

Velocidade de transmisso baixa (1 Mbps)

Alto custo

TECDM 32

O release 1.2 da especificao do Bluetooth definiu tambm um canal de piconet adaptado que apresenta as seguintes caractersticas: As frequncias nas quais um escravo transmite so as mesmas que o mestre acabou de transmitir. Ou seja, no h um salto de frequncia entre um pacote do mestre e o pacote do escravo que vem logo a seguir. possvel excluir algumas frequncias entre as 79 disponveis para a sequncia de salto de frequncias, que so marcadas como fora de uso. Evita-se desta forma a utilizao de frequncias com alto grau de interferncia. Alm destes canais existem ainda dois outros canais fsicos utilizados em funes de gerenciamento: inquiry scan e page canal. O release 2 da especificao do Bluetooth definiu um novo modo de operao, o Enhanced Data Rate EDR, que possibilitou aumentar a taxa da dados na interface rdio para 2 ou 3 Mbit/s (at 2,1 Mbit/s para a camada de aplicao), mantendo a mesma taxa de smbolos de 1 MS/s. O release 3 da especificao do Bluetooth introduziu um novo modo de operao, o Alternate MAC/PHY AMP, que permitiu o uso de protocolos alternativos nas camadas fsica (PHY) e de controle de acesso ao meio (MAC) na interface rdio, para aumentar a taxa de dados para at 54 Mbit/s (at 24 Mbit/s para a camada de aplicao). Adicionalmente, o novo release inclui o uso da faixa de 5 GHz para a comunicao entre os dispositivos. Os aperfeioamentos do release 3 tm como objetivo principalmente propiciar o uso das conexes Bluetooth em aplicaes que necessitam grandes transferncias de dados, ou em aplicaes de vdeo streaming sincronizado.

O release 4 atualizou a especificao do Bluetooth para dar suporte aos dispositivos de baixo consumo de energia (Low Energy) at a Camada L2CAP, ao Attribute Protocol (ATT) e ao Generic Attribute Profile (GATT), e para habilitar os High Speed Controller Subsystems.

Piconet

TECDM 33

Uma piconet uma rede Blootooth formada por at 8 dispositivos, sendo 1 mestre e os demais escravos. Todos os dispositivos esto sincronizados ao relgio e sequncia de salto de frequncia (hopping) do mestre. Em uma piconet toda comunicao ocorre entre mestre e escravos. No existe comunicao direta entre escravos em uma piconet. Em um determinado local podem existir vrias piconets independentes. Cada piconet tem um canal fsico diferente, isto um dispositivo mestre diferente e um relgio e sequncia de salto de frequncia independentes Um dispositivo Bluetooth pode participar concorrentemente em duas ou mais piconets, no podendo ser no entanto mestre de mais de umapiconet. Como o canal fsico que caracteriza a piconet definido pelo relgio e endereo do dispositivo mestre impossvel ser o mestre de duas ou mais piconets . Um dispositivo pode ser escravo em vrias piconets independentes.

Scatternet

TECDM 34

Um dispositivo Bluetooth que um membro de duas ou mais piconets dito estar envolvido em uma scatternet. O envolvimento em uma scaternet no implica necessariamente em qualquer funo ou capacidade de roteamento no dispositivo Bluetooth. Os protocolos do Bluetooth no oferecem esta funcionalidade, que responsabilidade de protocolos de mais alto nvel.

Perfis

Os perfis pr-definidos visam garantir a interoperabilidadeentre dispositivos Controle de udio e Vdeo

Impresso

Telefone sem fio

Acesso Genrico Agenda Telefnica

Sensor de batimento cardaco

etc

TECDM 35

http://www.teleco.com.br/tutoriais/tutorialblue/pagina_3.asp Os releases 1.0 e 1.1 da especificao do Bluetooth eram divididos em duas sees: especificao principal (Core) e definies dos profiles(perfis). Profiles (perfis) so especificaes de um servio especfico ou aplicao, definidos de forma a garantir a interoperabilidade entre dispositivos Bluetooth.

Android Bluetooth API

Funcionalidades:

Procurar outros dispositivos

Fazer requisies a dispositivos pareados

Estabelecimento de conexes RFCOMM

Conectar-se a dispositivo desconhecido

Transferir Dados

Gerenciar mltiplas conexes

TECDM 36

Obrigatrio desde a verso 2.0 do Android Funcionalidades:

Procurar outros dispositivos Fazer requisies a dispositivos pareados Estabelecimento de conexes RFCOMM Conectar-se a dispositivo desconhecido Transferir Dados Gerenciar mltiplas conexes


Como toda comunicao Assncrona:

Use Threads!

TECDM 37

Caso contrrio, sua aplicao vai ficar travada, ou seja, sem responder ao usurio at que o processamento da comunicao Bluetooth termine


Principais Classes:

Bluetooth Adapter

Bluetooth Device

TECDM 38

Bluetooth Adapter: a classe pela qual voc ter acesso inicial aos servios da API Descobre dispositivos e instancia Bluetooh Devices Bluetooth Device: Atravs do endereo MAC podemos instanci-lo e comunicar atravs de um BluetoothSocket ou BluetoothServerSocket


Primeiro passo:

Manifest.xml:

TECDM 39

Modelo de segurana do Android exige a verificao dos usurios de Apps no momento da instalao do aplicativo. Caso o usurio no deseje permitir que uma aplicao acesse a funcionalidade de Bluetooth, sua nica opo recusar a instalao. Caso o usurio aceite, todas as permisses requisitadas pela App no Manifest.xml sero concedidas. Caso o desenvolvedor esquea de requisitar uma permisso vai ocorrer um erro ao tentar acessar uma API que exija permisso para ser executada

Ativando Bluetooth - Passo a Passo

1. Requisitar um BluetoothAdapter

2. Ativar o Bluetooth:

TECDM 40

if (!mBluetoothAdapter.isEnabled()) {

Intent enableBtIntent =

new Intent(BluetoothAdapter.ACTION_REQUEST_ENABLE);

startActivityForResult(enableBtIntent, REQUEST_ENABLE_BT);

}

Get the BluetoothAdapterThe BluetoothAdapter is required for any and all Bluetooth activity. To get the BluetoothAdapter, call the static getDefaultAdapter()method. This returns a BluetoothAdapter that represents the device's own Bluetooth adapter (the Bluetooth radio). There's one Bluetooth adapter for the entire system, and your application can interact with it using this object. If getDefaultAdapter() returns null, then the device does not support Bluetooth and your story ends here. For example: BluetoothAdapter mBluetoothAdapter = BluetoothAdapter.getDefaultAdapter(); if (mBluetoothAdapter == null) { // Device does not support Bluetooth } Enable BluetoothNext, you need to ensure that Bluetooth is enabled. Call isEnabled() to check whether Bluetooth is currently enable. If this method returns false, then Bluetooth is disabled. To request that Bluetooth be enabled, call startActivityForResult() with the ACTION_REQUEST_ENABLE action Intent. This will issue a request to enable Bluetooth through the system settings (without stopping your application). For example: if (!mBluetoothAdapter.isEnabled()) { Intent enableBtIntent = new Intent(BluetoothAdapter.ACTION_REQUEST_ENABLE); startActivityForResult(enableBtIntent, REQUEST_ENABLE_BT); }A dialog will appear requesting user permission to enable Bluetooth, as shown in Figure 1. If the user responds "Yes," the system will begin to enable Bluetooth and focus will return to your application once the process completes (or fails). The REQUEST_ENABLE_BT constant passed to startActivityForResult() is a locally defined integer (which must be greater than 0), that the system passes back to you in your onActivityResult()implementation as the requestCode parameter.

If enabling Bluetooth succeeds, your activity receives the RESULT_OK result code in theonActivityResult() callback. If Bluetooth was not enabled due to an error (or the user responded "No") then the result code is RESULT_CANCELED. Optionally, your application can also listen for the ACTION_STATE_CHANGED broadcast Intent, which the system will broadcast whenever the Bluetooth state has changed. This broadcast contains the extra fieldsEXTRA_STATE and EXTRA_PREVIOUS_STATE, containing the new and old Bluetooth states, respectively. Possible values for these extra fields are STATE_TURNING_ON, STATE_ON, STATE_TURNING_OFF, andSTATE_OFF. Listening for this broadcast can be useful to detect changes made to the Bluetooth state while your app is running

Procurando dispositivos

Primeiro procure os que j foram pareados

Inicie o processo de descoberta de dispositivos

Registre os dispositivos encontrados

Permita-se ser descoberto

TECDM 41

Finding Devices Using the BluetoothAdapter, you can find remote Bluetooth devices either through device discovery or by querying the list of paired (bonded) devices. Device discovery is a scanning procedure that searches the local area for Bluetooth enabled devices and then requesting some information about each one (this is sometimes referred to as "discovering," "inquiring" or "scanning"). However, a Bluetooth device within the local area will respond to a discovery request only if it is currently enabled to be discoverable. If a device is discoverable, it will respond to the discovery request by sharing some information, such as the device name, class, and its unique MAC address. Using this information, the device performing discovery can then choose to initiate a connection to the discovered device. Once a connection is made with a remote device for the first time, a pairing request is automatically presented to the user. When a device is paired, the basic information about that device (such as the device name, class, and MAC address) is saved and can be read using the Bluetooth APIs. Using the known MAC address for a remote device, a connection can be initiated with it at any time without performing discovery (assuming the device is within range). Remember there is a difference between being paired and being connected. To be paired means that two devices are aware of each other's existence, have a shared link-key that can be used for authentication, and are capable of establishing an encrypted connection with each other. To be connected means that the devices currently share an RFCOMM channel and are able to transmit data with each other. The current Android Bluetooth API's require devices to be paired before an RFCOMM connection can be established. (Pairing is automatically performed when you initiate an encrypted connection with the Bluetooth APIs.)

The following sections describe how to find devices that have been paired, or discover new devices using device discovery. Note: Android-powered devices are not discoverable by default. A user can make the device discoverable for a limited time through the system settings, or an application can request that the user enable discoverability without leaving the application. How to enable discoverability is discussed below. Querying paired devices Before performing device discovery, its worth querying the set of paired devices to see if the desired device is already known. To do so, call getBondedDevices(). This will return a Set of BluetoothDevices representing paired devices. For example, you can query all paired devices and then show the name of each device to the user, using an ArrayAdapter: Set pairedDevices = mBluetoothAdapter.getBondedDevices(); // If there are paired devices if (pairedDevices.size() > 0) { // Loop through paired devices for (BluetoothDevice device : pairedDevices) { // Add the name and address to an array adapter to show in a ListView mArrayAdapter.add(device.getName() + "\n" + device.getAddress()); } }All that's needed from the BluetoothDevice object in order to initiate a connection is the MAC address. In this example, it's saved as a part of an ArrayAdapter that's shown to the user. The MAC address can later be extracted in order to initiate the connection. You can learn more about creating a connection in the section about Connecting Devices. Discovering devices To start discovering devices, simply call startDiscovery(). The process is asynchronous and the method will immediately return with a boolean indicating whether discovery has successfully started. The discovery process usually involves an inquiry scan of about 12 seconds, followed by a page scan of each found device to retrieve its Bluetooth name. Your application must register a BroadcastReceiver for the ACTION_FOUND Intent in order to receive information about each device discovered. For each device, the system will broadcast the ACTION_FOUNDIntent. This Intent carries the extra fields EXTRA_DEVICE and EXTRA_CLASS, containing a BluetoothDeviceand a BluetoothClass, respectively. For example, here's how you can register to handle the broadcast when devices are discovered: // Create a BroadcastReceiver for ACTION_FOUND private final BroadcastReceiver mReceiver = new BroadcastReceiver() { public void onReceive(Context context, Intent intent) { String action = intent.getAction(); // When discovery finds a device if (BluetoothDevice.ACTION_FOUND.equals(action)) { // Get the BluetoothDevice object from the Intent BluetoothDevice device = intent.getParcelableExtra(BluetoothDevice.EXTRA_DEVICE); // Add the name and address to an array adapter to show in a ListView mArrayAdapter.add(device.getName() + "\n" + device.getAddress()); }

} }; // Register the BroadcastReceiver IntentFilter filter = new IntentFilter(BluetoothDevice.ACTION_FOUND); registerReceiver(mReceiver, filter); // Don't forget to unregister during onDestroyAll that's needed from the BluetoothDevice object in order to initiate a connection is the MAC address. In this example, it's saved as a part of an ArrayAdapter that's shown to the user. The MAC address can later be extracted in order to initiate the connection. You can learn more about creating a connection in the section about Connecting Devices. Caution: Performing device discovery is a heavy procedure for the Bluetooth adapter and will consume a lot of its resources. Once you have found a device to connect, be certain that you always stop discovery withcancelDiscovery() before attempting a connection. Also, if you already hold a connection with a device, then performing discovery can significantly reduce the bandwidth available for the connection, so you should not perform discovery while connected. Enabling discoverability If you would like to make the local device discoverable to other devices, callstartActivityForResult(Intent, int) with the ACTION_REQUEST_DISCOVERABLE action Intent. This will issue a request to enable discoverable mode through the system settings (without stopping your application). By default, the device will become discoverable for 120 seconds. You can define a different duration by adding the EXTRA_DISCOVERABLE_DURATION Intent extra. The maximum duration an app can set is 3600 seconds, and a value of 0 means the device is always discoverable. Any value below 0 or above 3600 is automatically set to 120 secs). For example, this snippet sets the duration to 300: Intent discoverableIntent = new Intent(BluetoothAdapter.ACTION_REQUEST_DISCOVERABLE); discoverableIntent.putExtra(BluetoothAdapter.EXTRA_DISCOVERABLE_DURATION, 300); startActivity(discoverableIntent);Figure 2: The enabling discoverability dialog. A dialog will be displayed, requesting user permission to make the device discoverable, as shown in Figure 2. If the user responds "Yes," then the device will become discoverable for the specified amount of time. Your activity will then receive a call to the onActivityResult()) callback, with the result code equal to the duration that the device is discoverable. If the user responded "No" or if an error occurred, the result code will beRESULT_CANCELED. Note: If Bluetooth has not been enabled on the device, then enabling device discoverability will automatically enable Bluetooth. The device will silently remain in discoverable mode for the allotted time. If you would like to be notified when the discoverable mode has changed, you can register a BroadcastReceiver for the ACTION_SCAN_MODE_CHANGEDIntent. This will contain the extra fields EXTRA_SCAN_MODE and EXTRA_PREVIOUS_SCAN_MODE, which tell you the new and old scan mode, respectively. Possible values for each areSCAN_MODE_CONNECTABLE_DISCOVERABLE, SCAN_MODE_CONNECTABLE, or SCAN_MODE_NONE, which indicate that the device is either in discoverable mode, not in discoverable mode but still able to receive connections, or not in discoverable mode and unable to receive connections, respectively.

You do not need to enable device discoverability if you will be initiating the connection to a remote device. Enabling discoverability is only necessary when you want your application to host a server socket that will accept incoming connections, because the remote devices must be able to discover the device before it can initiate the connection.

Conectando dispositivos

Dispositivos precisam pareados (caso j no tenham sido)

Pelo padro da Piconet um deve atuar como servidor e outro comocliente

TECDM 42

Connecting Devices In order to create a connection between your application on two devices, you must implement both the server-side and client-side mechanisms, because one device must open a server socket and the other one must initiate the connection (using the server device's MAC address to initiate a connection). The server and client are considered connected to each other when they each have a connected BluetoothSocket on the same RFCOMM channel. At this point, each device can obtain input and output streams and data transfer can begin, which is discussed in the section about Managing a Connection. This section describes how to initiate the connection between two devices. The server device and the client device each obtain the required BluetoothSocket in different ways. The server will receive it when an incoming connection is accepted. The client will receive it when it opens an RFCOMM channel to the server. Figure 3: The Bluetooth pairing dialog. One implementation technique is to automatically prepare each device as a server, so that each one has a server socket open and listening for connections. Then either device can initiate a connection with the other and become the client. Alternatively, one device can explicitly "host" the connection and open a server socket on demand and the other device can simply initiate the connection. Note: If the two devices have not been previously paired, then the Android framework will automatically show a pairing request notification or dialog to the user during the connection procedure, as shown in Figure 3. So when attempting to connect devices, your application does not need to be concerned about whether or not the devices are paired. Your RFCOMM connection attempt will block until the user has successfully paired, or will fail if the user rejects pairing, or if pairing fails or times out. Connecting as a server

When you want to connect two devices, one must act as a server by holding an openBluetoothServerSocket. The purpose of the server socket is to listen for incoming connection requests and when one is accepted, provide a connected BluetoothSocket. When the BluetoothSocket is acquired from the BluetoothServerSocket, the BluetoothServerSocket can (and should) be discarded, unless you want to accept more connections. About UUID A Universally Unique Identifier (UUID) is a standardized 128-bit format for a string ID used to uniquely identify information. The point of a UUID is that it's big enough that you can select any random and it won't clash. In this case, it's used to uniquely identify your application's Bluetooth service. To get a UUID to use with your application, you can use one of the many random UUID generators on the web, then initialize a UUID withfromString(String). Here's the basic procedure to set up a server socket and accept a connection: Get a BluetoothServerSocket by calling thelistenUsingRfcommWithServiceRecord(String, UUID).The string is an identifiable name of your service, which the system will automatically write to a new Service Discovery Protocol (SDP) database entry on the device (the name is arbitrary and can simply be your application name). The UUID is also included in the SDP entry and will be the basis for the connection agreement with the client device. That is, when the client attempts to connect with this device, it will carry a UUID that uniquely identifies the service with which it wants to connect. These UUIDs must match in order for the connection to be accepted (in the next step). Start listening for connection requests by calling accept().This is a blocking call. It will return when either a connection has been accepted or an exception has occurred. A connection is accepted only when a remote device has sent a connection request with a UUID matching the one registered with this listening server socket. When successful, accept() will return a connected BluetoothSocket. Unless you want to accept additional connections, call close().This releases the server socket and all its resources, but does not close the connected BluetoothSocketthat's been returned by accept(). Unlike TCP/IP, RFCOMM only allows one connected client per channel at a time, so in most cases it makes sense to call close() on the BluetoothServerSocket immediately after accepting a connected socket. The accept() call should not be executed in the main activity UI thread because it is a blocking call and will prevent any other interaction with the application. It usually makes sense to do all work with aBluetoothServerSocket or BluetoothSocket in a new thread managed by your application. To abort a blocked call such as accept(), call close() on the BluetoothServerSocket (or BluetoothSocket) from another thread and the blocked call will immediately return. Note that all methods on aBluetoothServerSocket or BluetoothSocket are thread-safe. Example Here's a simplified thread for the server component that accepts incoming connections: private class AcceptThread extends Thread { private final BluetoothServerSocket mmServerSocket; public AcceptThread() { // Use a temporary object that is later assigned to mmServerSocket, // because mmServerSocket is final

BluetoothServerSocket tmp = null; try { // MY_UUID is the app's UUID string, also used by the client code tmp = mBluetoothAdapter.listenUsingRfcommWithServiceRecord(NAME, MY_UUID); } catch (IOException e) { } mmServerSocket = tmp; } public void run() { BluetoothSocket socket = null; // Keep listening until exception occurs or a socket is returned while (true) { try { socket = mmServerSocket.accept(); } catch (IOException e) { break; } // If a connection was accepted if (socket != null) { // Do work to manage the connection (in a separate thread) manageConnectedSocket(socket); mmServerSocket.close(); break; } } } /** Will cancel the listening socket, and cause the thread to finish */ public void cancel() { try { mmServerSocket.close(); } catch (IOException e) { } } }In this example, only one incoming connection is desired, so as soon as a connection is accepted and theBluetoothSocket is acquired, the application sends the acquired BluetoothSocket to a separate thread, closes the BluetoothServerSocket and breaks the loop. Note that when accept() returns the BluetoothSocket, the socket is already connected, so you should notcall connect() (as you do from the client-side). manageConnectedSocket() is a fictional method in the application that will initiate the thread for transferring data, which is discussed in the section about Managing a Connection. You should usually close your BluetoothServerSocket as soon as you are done listening for incoming connections. In this example, close() is called as soon as the BluetoothSocket is acquired. You may also want to provide a public method in your thread that can close the private BluetoothSocket in the event that you need to stop listening on the server socket. Connecting as a client

In order to initiate a connection with a remote device (a device holding an open server socket), you must first obtain a BluetoothDevice object that represents the remote device. (Getting a BluetoothDevice is covered in the above section about Finding Devices.) You must then use the BluetoothDevice to acquire aBluetoothSocket and initiate the connection. Here's the basic procedure: Using the BluetoothDevice, get a BluetoothSocket by callingcreateRfcommSocketToServiceRecord(UUID).This initializes a BluetoothSocket that will connect to the BluetoothDevice. The UUID passed here must match the UUID used by the server device when it opened its BluetoothServerSocket (withlistenUsingRfcommWithServiceRecord(String, UUID)). Using the same UUID is simply a matter of hard-coding the UUID string into your application and then referencing it from both the server and client code. Initiate the connection by calling connect().Upon this call, the system will perform an SDP lookup on the remote device in order to match the UUID. If the lookup is successful and the remote device accepts the connection, it will share the RFCOMM channel to use during the connection and connect() will return. This method is a blocking call. If, for any reason, the connection fails or the connect() method times out (after about 12 seconds), then it will throw an exception. Because connect() is a blocking call, this connection procedure should always be performed in a thread separate from the main activity thread. Note: You should always ensure that the device is not performing device discovery when you callconnect(). If discovery is in progress, then the connection attempt will be significantly slowed and is more likely to fail. Example Here is a basic example of a thread that initiates a Bluetooth connection: private class ConnectThread extends Thread { private final BluetoothSocket mmSocket; private final BluetoothDevice mmDevice; public ConnectThread(BluetoothDevice device) { // Use a temporary object that is later assigned to mmSocket, // because mmSocket is final BluetoothSocket tmp = null; mmDevice = device; // Get a BluetoothSocket to connect with the given BluetoothDevice try { // MY_UUID is the app's UUID string, also used by the server code tmp = device.createRfcommSocketToServiceRecord(MY_UUID); } catch (IOException e) { } mmSocket = tmp; } public void run() { // Cancel discovery because it will slow down the connection mBluetoothAdapter.cancelDiscovery();

try { // Connect the device through the socket. This will block // until it succeeds or throws an exception mmSocket.connect(); } catch (IOException connectException) { // Unable to connect; close the socket and get out try { mmSocket.close(); } catch (IOException closeException) { } return; } // Do work to manage the connection (in a separate thread) manageConnectedSocket(mmSocket); } /** Will cancel an in-progress connection, and close the socket */ public void cancel() { try { mmSocket.close(); } catch (IOException e) { } } }Notice that cancelDiscovery() is called before the connection is made. You should always do this before connecting and it is safe to call without actually checking whether it is running or not (but if you do want to check, call isDiscovering()). manageConnectedSocket() is a fictional method in the application that will initiate the thread for transferring data, which is discussed in the section about Managing a Connection. When you're done with your BluetoothSocket, always call close() to clean up. Doing so will immediately close the connected socket and clean up all internal resources.

Gerenciando a conexo

necessrio apenas acessar o stream de entrada ou sada para trocar informao entre os dispositivos

TECDM 43

Managing a Connection When you have successfully connected two (or more) devices, each one will have a connectedBluetoothSocket. This is where the fun begins because you can share data between devices. Using theBluetoothSocket, the general procedure to transfer arbitrary data is simple: Get the InputStream and OutputStream that handle transmissions through the socket, viagetInputStream() and getOutputStream(), respectively. Read and write data to the streams with read(byte[]) and write(byte[]). That's it. There are, of course, implementation details to consider. First and foremost, you should use a dedicated thread for all stream reading and writing. This is important because both read(byte[]) and write(byte[])methods are blocking calls. read(byte[]) will block until there is something to read from the stream.write(byte[]) does not usually block, but can block for flow control if the remote device is not callingread(byte[]) quickly enough and the intermediate buffers are full. So, your main loop in the thread should be dedicated to reading from the InputStream. A separate public method in the thread can be used to initiate writes to the OutputStream. Example Here's an example of how this might look: private class ConnectedThread extends Thread { private final BluetoothSocket mmSocket; private final InputStream mmInStream; private final OutputStream mmOutStream; public ConnectedThread(BluetoothSocket socket) {

mmSocket = socket; InputStream tmpIn = null; OutputStream tmpOut = null; // Get the input and output streams, using temp objects because // member streams are final try { tmpIn = socket.getInputStream(); tmpOut = socket.getOutputStream(); } catch (IOException e) { } mmInStream = tmpIn; mmOutStream = tmpOut; } public void run() { byte[] buffer = new byte[1024]; // buffer store for the stream int bytes; // bytes returned from read() // Keep listening to the InputStream until an exception occurs while (true) { try { // Read from the InputStream bytes = mmInStream.read(buffer); // Send the obtained bytes to the UI activity mHandler.obtainMessage(MESSAGE_READ, bytes, -1, buffer) .sendToTarget(); } catch (IOException e) { break; } } } /* Call this from the main activity to send data to the remote device */ public void write(byte[] bytes) { try { mmOutStream.write(bytes); } catch (IOException e) { } } /* Call this from the main activity to shutdown the connection */ public void cancel() { try { mmSocket.close(); } catch (IOException e) { } } }The constructor acquires the necessary streams and once executed, the thread will wait for

data to come through the InputStream. When read(byte[]) returns with bytes from the stream, the data is sent to the main activity using a member Handler from the parent class. Then it goes back and waits for more bytes from the stream. Sending outgoing data is as simple as calling the thread's write() method from the main activity and passing in the bytes to be sent. This method then simply calls write(byte[]) to send the data to the remote device. The thread's cancel() method is important so that the connection can be terminated at any time by closing the BluetoothSocket. This should always be called when you're done using the Bluetooth connection. For a demonstration of using the Bluetooth APIs, see the Bluetooth Chat sample app.

Trabalhando com perfis

A partir do Android 3.0 foi adicionado o suporte a perfis Bluetooh

TECDM 44

Working with Profiles Starting in Android 3.0, the Bluetooth API includes support for working with Bluetooth profiles. A Bluetooth profile is a wireless interface specification for Bluetooth-based communication between devices. An example is the Hands-Free profile. For a mobile phone to connect to a wireless headset, both devices must support the Hands-Free profile. You can implement the interface BluetoothProfile to write your own classes to support a particular Bluetooth profile. The Android Bluetooth API provides implementations for the following Bluetooth profiles: Headset. The Headset profile provides support for Bluetooth headsets to be used with mobile phones. Android provides the BluetoothHeadset class, which is a proxy for controlling the Bluetooth Headset Service via interprocess communication (IPC). This includes both Bluetooth Headset and Hands-Free (v1.5) profiles. The BluetoothHeadset class includes support for AT commands. For more discussion of this topic, see Vendor-specific AT commands A2DP. The Advanced Audio Distribution Profile (A2DP) profile defines how high quality audio can be streamed from one device to another over a Bluetooth connection. Android provides the BluetoothA2dpclass, which is a proxy for controlling the Bluetooth A2DP Service via IPC. Health Device. Android 4.0 (API level 14) introduces support for the Bluetooth Health Device Profile (HDP). This lets you create applications that use Bluetooth to communicate with health devices that support Bluetooth, such as heart-rate monitors, blood meters, thermometers, scales, and so on. For a list of supported devices and their corresponding device data specialization codes, refer to Bluetooth Assigned Numbers at www.bluetooth.org. Note that these values are also referenced in the ISO/IEEE 11073-20601 [7] specification as MDC_DEV_SPEC_PROFILE_* in the Nomenclature Codes Annex. For more discussion of HDP, see Health Device Profile. Here are the basic steps for working with a profile:

Get the default adapter, as described in Setting Up Bluetooth. Use getProfileProxy() to establish a connection to the profile proxy object associated with the profile. In the example below, the profile proxy object is an instance of BluetoothHeadset. Set up a BluetoothProfile.ServiceListener. This listener notifies BluetoothProfile IPC clients when they have been connected to or disconnected from the service. In onServiceConnected(), get a handle to the profile proxy object. Once you have the profile proxy object, you can use it to monitor the state of the connection and perform other operations that are relevant to that profile. For example, this code snippet shows how to connect to a BluetoothHeadset proxy object so that you can control the Headset profile: BluetoothHeadset mBluetoothHeadset; // Get the default adapter BluetoothAdapter mBluetoothAdapter = BluetoothAdapter.getDefaultAdapter(); // Establish connection to the proxy. mBluetoothAdapter.getProfileProxy(context, mProfileListener, BluetoothProfile.HEADSET); private BluetoothProfile.ServiceListener mProfileListener = new BluetoothProfile.ServiceListener() { public void onServiceConnected(int profile, BluetoothProfile proxy) { if (profile == BluetoothProfile.HEADSET) { mBluetoothHeadset = (BluetoothHeadset) proxy; } } public void onServiceDisconnected(int profile) { if (profile == BluetoothProfile.HEADSET) { mBluetoothHeadset = null; } } }; // ... call functions on mBluetoothHeadset // Close proxy connection after use. mBluetoothAdapter.closeProfileProxy(mBluetoothHeadset);Vendor-specific AT commands Starting in Android 3.0, applications can register to receive system broadcasts of pre-defined vendor-specific AT commands sent by headsets (such as a Plantronics +XEVENT command). For example, an application could receive broadcasts that indicate a connected device's battery level and could notify the user or take other action as needed. Create a broadcast receiver for the ACTION_VENDOR_SPECIFIC_HEADSET_EVENTintent to handle vendor-specific AT commands for the headset. Health Device Profile Android 4.0 (API level 14) introduces support for the Bluetooth Health Device Profile (HDP). This lets you create applications that use Bluetooth to communicate with health devices that support Bluetooth, such as heart-rate monitors, blood meters, thermometers, and scales.

The Bluetooth Health API includes the classesBluetoothHealth, BluetoothHealthCallback, and BluetoothHealthAppConfiguration, which are described in The Basics. In using the Bluetooth Health API, it's helpful to understand these key HDP concepts: ConceptDescriptionSourceA role defined in HDP. A source is a health device that transmits medical data (weight scale, glucose meter, thermometer, etc.) to a smart device such as an Android phone or tablet.SinkA role defined in HDP. In HDP, a sink is the smart device that receives the medical data. In an Android HDP application, the sink is represented by aBluetoothHealthAppConfiguration object.RegistrationRefers to registering a sink for a particular health device.ConnectionRefers to opening a channel between a health device and a smart device such as an Android phone or tablet.Creating an HDP Application Here are the basic steps involved in creating an Android HDP application: Get a reference to the BluetoothHealth proxy object.Similar to regular headset and A2DP profile devices, you must call getProfileProxy() with aBluetoothProfile.ServiceListener and the HEALTH profile type to establish a connection with the profile proxy object. Create a BluetoothHealthCallback and register an application configuration (BluetoothHealthAppConfiguration) that acts as a health sink. Establish a connection to a health device. Some devices will initiate the connection. It is unnecessary to carry out this step for those devices. When connected successfully to a health device, read/write to the health device using the file descriptor.The received data needs to be interpreted using a health manager which implements the IEEE 11073-xxxxx specifications. When done, close the health channel and unregister the application. The channel also closes when there is extended inactivity. For a complete code sample that illustrates these steps, see Bluetooth HDP (Health Device Profile).

NFC Near Field Communication

TECDM 45

NFC Technology Architecture NFC is based on RFID technology at 13.56 MHz, with a typical operating distance up to 10 cm. The data exchange rate is up to 424 kilobits/s. Compared to other communication technology, the biggest advantage of NFC is it is quick and easy to use. The following graph compares NFC to other communication technologies. http://software.intel.com/en-us/android/articles/nfc-application-development-on-android

NFC modos de operao

TECDM 46

NFC technology has three modes: NFC card emulation mode, peer-to-peer mode, and reader/writer mode, shown in the following graph. card emulation mode, NFC simulates an RFID integrated circuit (IC) card, with a security module, which allows users to make purchases safely. In peerto-peer mode, you can share information, such as business cards, between different NFC devices via an NFC connection. You can also set up a WiFi* or Bluetooth* connection quickly through the NFC connection and transfer big files through the WiFi or Bluetooth connection. In reader/writer mode, you can use NFC-enabled devices to read NFC tags and launch smart tasks. Each mode is discussed in more detail below. NFC Card Emulation Mode An NFC module usually consists of two parts: an NFC controller and a secure element (SE). The NFC controller is responsible for communication. The SE is responsible for encrypting and decrypting sensitive data. Figure 3: NFC Hardware Components The SE connects to the NFC controller via SWP (Single Wire Protocol) or DCLB (Digital Contactless Bridge) bus. NFC standards define a logical interface between the host and the controller allowing them to communicate via the RF-field. A built-in app or a small OS implements the SE, which is responsible for the encrypting and decrypting the sensitive data. The three solutions to implement the SE are: Embedded in SIM card Embedded in SD card Embedded in NFC Chip Figure 4: Three NFC SE Solutions

The telecom operators, such as CMCC (China Mobile Communication Corporation), Vodafone and AT&T, usually prefer the SIM card-based solution, who are encouraging their users to replace old SIM cards with new NFC-enabled ones for free. NFC Peer-to peer Mode Two devices with NFC can communicate directly and easily to share small files such as business cards. Two NFC-enabled devices can also share configured .xml files with each other and establish Bluetooth/WiFi connection to share big files. In this mode, no SE module is needed. NFC Reader /Writer Mode In this mode, the NFC host can read/write NFC tags. A good example is to read useful information from smart posters. Users can access links to view the advertisements and download discount coupons.

Dvidas?

TECDM 47

Obrigado

TECDM 48

tecnologias de comunicacao sem fio

Documents