1. 程式人生 > >藍芽協議-----之pan profile on bluedroid

藍芽協議-----之pan profile on bluedroid

1 藍芽pan profile協議的概述

1.1 協議層次結構

藍芽pan就是我們熟知的藍芽網路,他在藍芽協議體系中的層次結構見如下圖:

BNEP相當於網路協議棧中的鏈路層,由該層虛擬出一個網路介面,而BNEP層以下就是藍芽核心協議之一的L2CAP。這個是在藍芽協議中的層次結構,具體在bluedroid中的層次結構,跟這個有點出入。但基本都差不多的。

1.2 BNEP包的型別和格式

上圖中的BNEP層收到的資料包是乙太網格式的,需要將他重現拆分打包成適合BNEP over L2CAP來傳輸,所以在BNEP層需要將ip層下來的乙太網頭去掉,再加上BNEP的頭,當這個BNEP包傳輸到l2cap層時,又會被加上L2cap的頭,他們的包頭格式的變換如下圖所示:

1.3 BNEP包的型別

上圖中的BNEP Header的格式基本是遵循如下圖所示的格式,但具體的格式是依賴於BNEP TYPE的,不同的type他們的BNEP header是有所不同的。

0                  8      12     16     20    24     28     31

BNEP TYPE E BNEP Packet based on BNEP Type ...

以上各欄位的解析如下:

BNEP Type:取值範圍:0x00 –0x7F,Seven bit Bluetooth Network Encapsulation Protocol Type value identifies the type of BNEP header contained in this packet.Values are defined in the following Table 1

Extension Flag (E):One bit extension flag that indicates if one or more extension headers follow the BNEP Header before the data payload. If the extension flag is equal to 0x1 then one or more extension headers follows the BNEP header.  If the extension flag is equal to 0x0 then the
BNEP payload follows the BNEP header

 以上各種BNEP包型別,重點描述0x01和0x2型別,其他的請詳見BNEP的協議描述。

1.4 BNEP control packet type

BNEP_ CONTROL Packet Type Header Format:The BNEP_ CONTROL packet type header format is shown in the following Figure。

This packet type is mandatory to recognize and respond to accordingly.  The BNEP_CONTROL packet type is used to exchange control information

 

上圖中的BNEP control type有如下種類,他們主要用於BNEP連線的建立和斷開,及設定網路濾包。但需要注意的是,由於BNEP連線是建立在l2cap連線之上的,所以需要先建立l2cap連線。

1.4.1 BNEP_CONTROL_COMMAND_NOT_UNDERSTOOD

BNEP_CONTROL_COMMAND_NOT_UNDERSTOOD Control Command Packet:

This packet shall be used to reply to any control message received, which contains an unknown BNEP control type value.  This allows devices to response to control message that may be used in the future

1.4.2 BNEP_SETUP_CONTROL Packets

This packet type shall contain control messages used to setup the initial connection information about the BNEP connection.  All devices that support BNEP shall be able to recognize and respond to accordingly to all BNEP_SETUP_CONTROL packets BNEP_SETUP_CONTROL packet types must be processed in order that they are received.  For each connection, only one outstanding BNEP_SETUP_CONTROL message is allowed.   A response message must be used to respond to each control message received.  If a response message is not received, after Tcrt time has elapsed, then the outstanding BNEP_SETUP_CONTROL message can be assumed to be lost and the same BNEP_SETUP_CONTROL message can be retransmitted.  The range for Tcrt is from 1 second to 30 seconds, with a suggested timeout value to be 10 seconds. BNEP packets of type BNEP_SETUP_CONTROL are for the device with direct connection communication only, and must never be forwarded.

1.4.2.1 BNEP_SETUP_CONNECTION_REQUEST_MSG

BNEP_SETUP_CONNECTION_REQUEST_MSG setup control message format:

The BNEP_SETUP_CONNECTION_REQUEST_MSG setup control message format is shown in the following Figure:

The purpose of this control message is to inform the peer entity the destination and source SDP service UUIDs [8] whichare being used for this BNEP connection.  The device, which is establishing the L2CAP connection for BNEP, is required to send this packet and receive a successful response before sending any additional packets with other BNEP packet types.  This setup packet SHALL be successfully transmitted to the other device and successfully responded to by that device before sending any other BNEP packets.  In addition, the BNEP setup message can be used to switch the current roles for the BNEP connection

1.4.2.2 BNEP_SETUP_ CONNECTION_RESPONSE_MSG

BNEP_SETUP_ CONNECTION_RESPONSE_MSG response message format:

The BNEP_SETUP_ CONNECTION_RESPONSE_MSG response message format is shown in the following Figure,The response message shall be used to respond to each BNEP_SETUP_CONNECTION_REQUEST_MSG control message.  Each of the received setup control messages must be responded to by one response message.

控制型別的包的解析就到此為止,因為其他的控制包型別都是可選的,就不再累述了。下面描述第二種包。

1.5 BNEP_COMPRESSED_ETHERNET Packet Type

BNEP_COMPRESSED_ETHERNET Packet Type Header Format:

The BNEP_COMPRESSED_ETHERNET packet type header format is shown in the following Figure

his packet type shall be used to carry Ethernet packets to and from devices that are directly connected at
L2CAP level (have a valid L2CAP connection handle) using BNEP.  This compressed header may be used when two Bluetooth devices are exchanging packets, in which the source address is set to the local device’s address which is the source device sending the packet and destination addresses is set to the other device’s address which is the final destination for the packet.   Devices do not need to include the source or destination addresses in the packet because the destination address is always the device’s address that received the packet and the source address is always the device’s address that sent the packet

1.6 BNEP_COMPRESSED_ETHERNET_SOURCE_ONLY

BNEP_COMPRESSED_ETHERNET_SOURCE_ONLY Packet Type Header:

The header format is based on one of the compressed versions of the Ethernet header supported by BNEP.  This
packet type will be used to carry Ethernet packets to a device using BNEP, which is the final destination for that packet.  Devices do not need to include the destination address in the packet, because the destination address of the BNEP packet is the same as the address corresponding to the L2CAP channel over which the packet is sent.

1.7 BNEP_COMPRESSED_ETHERNET_DEST_ONLY

BNEP_COMPRESSED_ETHERNET_DEST_ONLY Packet Type Header:

This packet type shall be used to carry Ethernet packets from a device using BNEP, which is the originator of that packet.  Devices do not need to include the source address in the packet, because the source address can be determined from the L2CAP connection and which device sent the packet.The destination may be an IEEE Ethernet address, if the actual destination is an
IEEE device and not a Bluetooth device.  

至此我們在bluedroid BNEP協議的實現中要用到的主要包型別已經描述完畢。下面開始具體的實現環節。

2藍芽pan在bluedroid中的層次結構

藍芽pan profile在android bluedroid程式碼結構中的層次關係如下:

 從上到下:hal層提供給上層的呼叫介面為(callin):btpan_interface_t pan_if,同時上層提供給pan profile的回撥介面(callback)為:btpan_callbacks_t。

callin介面用來接收上層的命令,而callback介面用來給上層返回狀態等事件。PAN HAL層以下就是PAN BTA層,也就是pan的應用層,而BTA層以下就是pan 的核心stack層,包含兩部分,一個部分是stack pan,一個部分是stack bnep,前者基於後者,最後bnep是基於l2cap層。

而層與層之間,都是通過callin 和callback來進行互動,最終達到資訊在各層次間的交流。

具體到每層的實現,基本都是分為三個子模組:api submod,main submod,utils submod。其中api submod提供給上層呼叫該層的介面,而main submod會提供給上層一個註冊函式,用於註冊上層的回撥函式,另外一個主要功能就是狀態機的維護和遷移;在有狀態機的模組通常還包含一個action submod,該模組就是在狀態遷移時,需要執行的動作都定義在該模組中;而utils subsys就是工具和輔助函式。

3藍芽pan的連結過程

下圖再結合上圖,你就可以清楚的看到,一個命令是如何在上層傳遞到下層,並且命令的事件是如何通過各層的callback從下層傳遞迴上層的。

前面我們知道,BNEP的連線是建立在l2cap連線之上的,從上面的連線時序圖中,我們可以清楚的看到,BNEP的連線過程的半段就是l2cap的連線(連線情況的發起,鏈路的配置等),然後才是BNEP鏈路的連線。上圖中,箭頭從左到右的是上層命令傳遞到下層的一個流程;而箭頭從右到左就是命令的事件從下層通過回撥傳遞到上層的流程。

4藍芽pan的資料收發過程

4.1 pan的資料傳送過程

上述的過程,需要注意乙太網的頭是如何在這個過程被去掉的,並且BNEP的頭是如何被新增進來的,最後傳遞到l2cap層,並由l2cap層新增l2cap的頭。

4.2 pan資料的接

資料接收的過程,就是進來的資料一路從下層回撥到上層的過程。

5 從sniffer log看bnep的連線過程(role:panu)

下圖就是bnep連線過程,對應的l2cap連線的過程,對應下圖包序號的348到355.簡單的描述就是鏈路連線的發起和配置過程。

 下面就是在l2cap連線建立的基礎上,發起Bnep層的連線的過程,很簡單就兩個包,然後資料在通訊過程中,基本都是使用的compressed ethernet package,因為傳送和接受放都是l2cap的兩端,所以src和dest地址都可以省略掉。 

 在上圖中,我們可以看到還有好幾個compressed ethernet dest only 包,這些包其實就是對應的arp request包,因為這些包的dest 地址都是廣播地址,並不是l2cap接收端的藍芽mac地址,所以需要使用這個只包含dest only的compressed ethernet包。

6 參考資料

1:Core_V4.0.pdf

2:BNEP.pdf

3:android的原始碼分支:external\bluetooth\bluedroid