1 引言

藍(lán)牙（Bluetooth ）是一種低成本、短距離的無(wú)線連接技術(shù)標(biāo)準(zhǔn)。它是由愛立信（Ericsson ） ，國(guó)際商用機(jī)器（IBM ） ，英特爾（ Intel ） ，諾基亞（Nokia ）和東芝（Toshiba ） 5 家公司共同倡導(dǎo)的一種全球無(wú)線技術(shù)標(biāo)準(zhǔn)。其目的就是將智能移動(dòng)電話與筆記本電腦、掌上電腦以及各種數(shù)字信息的外部設(shè)備用無(wú)線方式連接起來。目前，無(wú)線連接飛速普及、大受歡迎，藍(lán)牙技術(shù)的廣泛應(yīng)用對(duì)無(wú)線移動(dòng)數(shù)據(jù)通信將起到巨大的促進(jìn)作用。

2 藍(lán)牙無(wú)線頻段的選擇和抗干擾

藍(lán)牙技術(shù)采用2400～2483.5MHz 的ISM （工業(yè)、科學(xué)和醫(yī)學(xué)）頻段，這是因?yàn)椋?/p>

（ l ）該頻段內(nèi)沒有其它系統(tǒng)的信號(hào)干擾，同時(shí)頻段向公眾開放，無(wú)須特許；

（ 2 ）該頻段在全球范圍內(nèi)有效。

此時(shí)，抗干擾問題便變得非常重要。因?yàn)?400～2483.5MHz ISM 頻段為開放頻段，使用其中的任何頻段都會(huì)遇到不可預(yù)測(cè)的干擾源（如某些家用電器、無(wú)繩電話和汽車開門器等），此外，對(duì)外部干擾源和其它藍(lán)牙設(shè)備的干擾也應(yīng)作充分估計(jì)。

抗干擾方法分為避免干擾和抑制干擾。避免干擾可通過降低各通信單元的信號(hào)發(fā)射電平來達(dá)到；抑制干擾則通過編碼或直接序列擴(kuò)頻來實(shí)現(xiàn)。然而，在不同的無(wú)線環(huán)境下，專用系統(tǒng)的干擾和有用信號(hào)的動(dòng)態(tài)范圍變化極大。在超過50dB 的遠(yuǎn)近比和不同環(huán)境功率差異的情況下，要達(dá)到1Mb/s 以上速率，僅靠編碼和處理增益是不夠的。相反，由于信號(hào)可在沒有干擾時(shí)（或干擾低時(shí)）發(fā)送，故避免干擾更容易一些。若采用時(shí)間避免干擾法，當(dāng)遇到時(shí)域脈沖干擾時(shí)，發(fā)送的信號(hào)將會(huì)中止。另一方面，大部分無(wú)線系統(tǒng)是帶寬受限的，而在2.45 GHZ 頻段上，系統(tǒng)帶寬為80MHz，可找到一段無(wú)明顯干擾的頻譜，同時(shí)利用頻域濾波器對(duì)無(wú)線頻帶其余頻譜進(jìn)行抑制，以達(dá)到理想效果。因此，以頻域避免干擾法更為可行。

3 藍(lán)牙基帶協(xié)議中的可靠性措施

藍(lán)牙基帶協(xié)議把保證藍(lán)牙無(wú)線連接的可靠性放在了至關(guān)重要的位置上，確保匹克網(wǎng)內(nèi)各藍(lán)牙設(shè)備之間由射頻構(gòu)成可靠的物理連接。實(shí)際上，為了提高藍(lán)牙無(wú)線連接的可靠性，以較小的開銷有效地降低誤碼率、切實(shí)提高藍(lán)牙無(wú)線連接的可靠性，藍(lán)牙基帶協(xié)議中定義了一系列提高藍(lán)牙無(wú)線連接可靠性的措施，主要包括：差錯(cuò)檢測(cè)和校正、進(jìn)行數(shù)據(jù)編解碼、差錯(cuò)控制、數(shù)據(jù)加噪等。下面，我們對(duì)這些可靠性措施一一進(jìn)行闡述：

3.1 藍(lán)牙基帶協(xié)議中的差錯(cuò)控制方案

在藍(lán)牙基帶協(xié)議中采用的差錯(cuò)控制方案有：1/3 比例前向糾錯(cuò)碼（FEC）；2/3比例前向糾錯(cuò)碼（FEC）；數(shù)據(jù)的自動(dòng)重傳請(qǐng)求（ARQ， Automatic Repeat Request）方案。

其中，F(xiàn)EC（前向糾錯(cuò)）的目的是為了減少數(shù)據(jù)載荷重發(fā)的次數(shù)，使用FEC碼，檢錯(cuò)、糾錯(cuò)以及編解碼的過程變得簡(jiǎn)單迅速，這對(duì)RX 和TX 間的有限處理時(shí)間非常重要。但是，采用FEC的缺點(diǎn)是還是會(huì)降低實(shí)際數(shù)據(jù)傳輸速率。所以，在糾錯(cuò)要求不高的環(huán)境中，可以不采用FEC。藍(lán)牙規(guī)范基帶協(xié)議中的分組的定義對(duì)于在有效載荷中是否采用FEC 給出了相當(dāng)?shù)撵`活度，由此而定義了ACL鏈接中使用的DM 和DH分組以及SCO鏈接中使用的HV分組。分組頭通常采用1/3比例前向糾錯(cuò)碼保護(hù)，它含有很重要的鏈接信息，能夠容忍多位錯(cuò)誤。

3.1.1 1/3 比例前向糾錯(cuò)碼（FEC）

在這種3位重復(fù)方案中，分組頭中的每一位都重復(fù)三次。主要用來屏蔽頭中的錯(cuò)誤，因?yàn)榉纸M頭中包含有重要的連接信息。實(shí)際上在整個(gè)分組頭里都采用了三位重復(fù)碼。在這種3 位重復(fù)方案中，重復(fù)碼大部分在接收端判決，既可用于數(shù)據(jù)包頭，也可用于SCO鏈接的分組。例如，在SCO鏈接中使用的HV1分組里的話音段中也采用了這種編碼格式。

3.1.2 2/3比例前向糾錯(cuò)碼（FEC）

在這一方案中，采用了一種（15， 10）精簡(jiǎn)的（縮短的）漢明碼表示方式。每10個(gè)信息位被編碼為15位的碼字，生成多項(xiàng)式為：g（D）= （D+1） （D4+D+1）。此類錯(cuò)誤校正方法主要用來以最可靠的方式來發(fā)送數(shù)據(jù)分組。該方案能夠在各代碼字中糾正所有奇數(shù)位錯(cuò)和檢測(cè)所有偶數(shù)位錯(cuò)，誤碼檢測(cè)用于數(shù)據(jù)糾錯(cuò)。它既可用于SCO鏈接的同步分組，也可用于ACL 鏈接的異步分組。具體而言，2/3比例前向糾錯(cuò)碼可用于DM分組、DV分組中的數(shù)據(jù)段、FHS 分組以及SCO鏈接中使用的HV2分組中。由于編碼器采用長(zhǎng)度為10 的信息段，所以值為O的尾位可附加在CRC位之后。而所有需要編碼的位數(shù)（即：有效載荷頭、用戶數(shù)據(jù)、CRC和尾部數(shù)位）必須是10 的整倍數(shù)。通常是用線性反饋移位寄存器LFSR來生成2/3比例前向糾錯(cuò)碼。

3.1.3 自動(dòng)重傳請(qǐng)求（ARQ）

在藍(lán)牙無(wú)線連接中，為了保證可靠傳送，常用做法是采用自動(dòng)重傳請(qǐng)求（ARQ）方案，由接收方發(fā)回特殊的控制幀，作為對(duì)輸人肯定或否定性的確認(rèn)（ACK/NACK）。如果出現(xiàn)丟幀或丟掉確認(rèn)消息的情況，則計(jì)時(shí)器在超時(shí)后會(huì)發(fā)出超時(shí)信號(hào)，提醒發(fā)送方可能出現(xiàn)了問題，必須重傳此幀。而且收方必須能夠辨別收到的是重復(fù)幀還是新幀。

在藍(lán)牙采用的ARQ方案中，藍(lán)牙的DM、DH和DV分組的數(shù)據(jù)段可以進(jìn)行傳輸或重發(fā)，直到收端返回成功接收確認(rèn)信息（或超時(shí)）為止。該確認(rèn)信息包含在返回分組頭里，即捎帶（ Piggy backing） 。為了確定有效載荷正確與否，循環(huán)冗余校驗(yàn)碼應(yīng)該加載于有效載荷中。ARQ方案只工作在分組的有效載荷上（僅針對(duì)具有CRC的有效載荷）。分組頭和話音有效載荷不受ARQ 保護(hù)。

藍(lán)牙使用快速、無(wú)編號(hào)確認(rèn)方案。為了應(yīng)答前次接收分組，應(yīng)返回ACK （ARQN=1）或NAK （ARQN=0）。在返回分組的分組頭里，生成ACK / NACK 域，同時(shí)，接收分組的分組頭中的ACK / NACK域可表明前面的負(fù)載是否正確接收，決定是否需要重發(fā)或發(fā)送下一個(gè)分組。從單元將在主-從時(shí)隙后緊跟在從-主時(shí)隙中進(jìn)行應(yīng)答。主單元?jiǎng)t將在下一個(gè)事件中應(yīng)答，該事件將給出同一從單元地址。由于處理時(shí)間短，當(dāng)分組接收時(shí)，解碼選擇在空閑時(shí)間進(jìn)行，并要簡(jiǎn)化FEC編碼結(jié)構(gòu)，以加快處理速度。快速ARQ方案與停止等待ARQ方案相似，但時(shí)延最小，實(shí)際上沒有由ARQ方案引起的附加時(shí)延。該結(jié)構(gòu)比退后n幀ARQ更有效，并與選擇重傳ARQ 效率相同，但由于只有失效的分組被重發(fā)，可減少開銷。

在快速ARQ方案中，收方為了辨別是重復(fù)幀還是新幀（即過濾重傳數(shù)據(jù)），頭部將附加SEQN位。通常，每次新的CRC數(shù)據(jù)有效載荷傳輸，SEQN位將交替變化。而在重傳中，SEQN位不發(fā)生變化。這樣，通過辨認(rèn)SEQN位是否發(fā)生變化，收方即可辨別出是重復(fù)幀還是新幀。

3.2 藍(lán)牙基帶協(xié)議中的錯(cuò)誤校驗(yàn)

在藍(lán)牙無(wú)線連接中，至少應(yīng)該對(duì)HEC進(jìn)行分組頭校驗(yàn)。另外，必要時(shí)其有效載荷也必須進(jìn)行CRC校驗(yàn)。使用分組頭HEC信息和有效載荷中的CRC信息，可以檢測(cè)分組錯(cuò)誤和傳輸錯(cuò)誤。

3.2.1 分組頭HEC檢測(cè)

為了檢測(cè)藍(lán)牙分組頭，每個(gè)分組頭的最高8位定義為HEC （ Header-Error-Check，頭部錯(cuò)誤檢測(cè)）信息。HEC由多項(xiàng)式647（八進(jìn)制數(shù)）生成，在生成HEC之前，HEC生成器用一個(gè)8 位值來初始化。在初始化后，對(duì)分組頭的其它10位進(jìn)行計(jì)算，得到8位的HEC值。另外，在接收方校驗(yàn)HEC之前，也必須先進(jìn)行適當(dāng)?shù)某跏蓟Ｔ诮邮辗纸M時(shí)，首先校驗(yàn)的是訪問碼，由于在信道訪問碼中的64位同步字來源于24位主單元的低地址部分（LAP），這樣就可以校驗(yàn)LAP是否正確，并可以防止接收方接收來自其它匹克網(wǎng)的分組。

3.2.2 有效載荷的CRC校驗(yàn)

CRC校驗(yàn)即循環(huán)冗余碼校驗(yàn)，是一種常用的檢錯(cuò)編碼，而且已經(jīng)有相應(yīng)的國(guó)際標(biāo)準(zhǔn)，如CRC-CCITT。在藍(lán)牙無(wú)線連接中，發(fā)送方按照國(guó)際標(biāo)準(zhǔn)CRC-CCITT ，即g （D） = （ D + 1 ） （ D7 +D4+D3+D2+D+1），并用線性反饋移位寄存器LFSR硬件電路生成有效載荷（數(shù)據(jù)信息）的CRC校驗(yàn)碼，附加在數(shù)據(jù)信息后面構(gòu)成完整的數(shù)據(jù)幀，由接收方在接收時(shí)檢查。若出錯(cuò)，返回NAK，發(fā)送方收到NAK 后重發(fā)該數(shù)據(jù)幀。

3.3 藍(lán)牙基帶協(xié)議中的其它可靠性措施

3.3.1 教據(jù)加噪

所有的分組頭和載荷信息在發(fā)送前都要利用數(shù)據(jù)加噪字進(jìn)行加噪處理。這主要是為了避免在傳輸過程中出現(xiàn)過長(zhǎng)的連續(xù)0或1的位流模式。基帶處理器需要從接收到的模擬數(shù)據(jù)信號(hào)中判斷數(shù)據(jù)是0還是1，但過長(zhǎng)的連續(xù)0或1位流會(huì)造成問題。因?yàn)樵诮邮盏降哪M數(shù)據(jù)信號(hào)中并不存在象直流信號(hào)中那樣的參考點(diǎn)，因此必須依靠接收到的最后幾個(gè)傳輸信號(hào)進(jìn)行校正。任何連續(xù)的0或1的長(zhǎng)序列位流串都可能導(dǎo)致校正失敗。因此需要采用數(shù)據(jù)加噪技術(shù)對(duì)信號(hào)進(jìn)行擾碼處理，以大大降低出現(xiàn)長(zhǎng)序列0或1位流串的可能性。

在藍(lán)牙無(wú)線連接的發(fā)送方，這種加噪過程先于FEC編碼完成。在接收端，接收數(shù)據(jù)使用相同的數(shù)據(jù)加噪字進(jìn)行還原處理，該還原處理在FEC解碼后完成。

3.3.2 鏈路監(jiān)測(cè)

在無(wú)線連接中，有很多原因能夠引起連接中斷，比如，設(shè)備關(guān)閉、設(shè)備移出了藍(lán)牙通信范圍。而且在連接中斷發(fā)生時(shí)，通常不會(huì)有任何提前報(bào)警，所以，在藍(lán)牙主、從單元兩端對(duì)鏈路進(jìn)行監(jiān)測(cè)是非常必要的。

為此，在藍(lán)牙主、從單元均使用鏈路監(jiān)測(cè)定時(shí)器。一旦收到經(jīng)過HEC校驗(yàn)的分組和正確的藍(lán)牙活動(dòng)成員地址（AMADDR），定時(shí)器就復(fù)位。如果在連接狀態(tài)的任何時(shí)刻，定時(shí)器達(dá)到閾值（該閾值可協(xié)商），則連接復(fù)位。SCO和ACL 連接使用同一閾值。這樣，就能夠在藍(lán)牙主、從單元兩端對(duì)鏈路進(jìn)行監(jiān)測(cè)了。

4 藍(lán)牙鏈路管理層（LM）中的可靠性措施

類似地，在藍(lán)牙鏈路管理層（LM ）中，也定義有保證可靠的無(wú)線連接的措施。

在藍(lán)牙接收和發(fā)送設(shè)備的鏈路管理層之間是通過協(xié)議數(shù)據(jù)單元（PDU）來相互通信的。PDU 由操作碼、事件ID和內(nèi)容參數(shù)組成，其中，7 位操作碼用來標(biāo)識(shí)不同類型的PDU。

如果鏈路管理器收到不能識(shí)別操作碼的PDU，就用LMP no accepted協(xié)議數(shù)據(jù)單元（PDU）應(yīng)答，并且LMP no accepted PDU中含有原因碼unknown LMP PDU。而且返回的操作碼參數(shù)同樣也是不能夠識(shí)別的操作碼。如果鏈路管理器收到含有無(wú)效參數(shù)的PDU，就用LMP no accepted PDU應(yīng)答，并且LMP no accepted PDU中含有原因碼invalid LMP PDU（無(wú)效LMP 參數(shù)）。

某一方在等待對(duì)方響應(yīng)時(shí)，如果發(fā)現(xiàn)超過了最大響應(yīng)時(shí)間或者檢測(cè)到鏈路丟失，等待應(yīng)答的一方就可以認(rèn)為該過程已經(jīng)終止。

信道出錯(cuò)或發(fā)送方系統(tǒng)出錯(cuò)都會(huì)引起發(fā)送錯(cuò)誤的消息。為了檢測(cè)后一種情況，LM應(yīng)監(jiān)測(cè)錯(cuò)誤消息數(shù)量，一旦超過閾值就將其斷開，該閾值可根據(jù)實(shí)際情況進(jìn)行設(shè)置。

由于無(wú)法實(shí)時(shí)地截獲PDU，在鏈路兩端的LM都對(duì)同一過程進(jìn)行初始化而且都沒有成功時(shí)，很可能會(huì)發(fā)生沖突。這時(shí)，主單元將通過發(fā)送含有原因碼“LMP Error Transaction Collision ”的LMP no accepted PDU，中止從單元的初始化過程，從而保證主單元的初始化過程能夠順利進(jìn)行。

5 藍(lán)牙應(yīng)用層中可采用的可靠性措施

5.1 穩(wěn)定、可靠的藍(lán)牙文件傳輸協(xié)議：RBTFT

藍(lán)牙的文件傳輸是通過RFCOMM協(xié)議建立一條端到端的連接。所以在藍(lán)牙RFCOMM協(xié)議的基礎(chǔ)之上建立了本文所描述的藍(lán)牙的文件傳輸協(xié)議，稱之為RBTFT（表示為Reliable Bluetooth File Transfer），其主要目標(biāo)是在藍(lán)牙設(shè)備之間建立一條可靠的無(wú)線連接通道，進(jìn)行可靠的文件傳輸。該協(xié)議目前的開發(fā)是采用VC+ +，應(yīng)用平臺(tái)為WIN98/2000/NT，但作為RBTFT 協(xié)議的本身不受具體編程語(yǔ)言及操作系統(tǒng)所限制。

RBTFT 協(xié)議支持一次傳輸多個(gè)文件、斷點(diǎn)續(xù)傳和CRC校驗(yàn)。其設(shè)計(jì)思想是基于幀傳輸方式，即在發(fā)送數(shù)據(jù)時(shí)是一幀一幀地發(fā)送，為保證可靠的傳輸，RBTFT協(xié)議對(duì)RBTFT幀進(jìn)行了精心的定義，RBTFT 幀由報(bào)頭、數(shù)據(jù)子包組成，報(bào)頭指明幀類型（有些幀是不帶數(shù)據(jù)的命令幀、信息幀，如BTFNAK ） ，還攜帶CRC校驗(yàn)信息。而數(shù)據(jù)子包還有不同的子包結(jié)束符，指明后面是否有后續(xù)包等。在進(jìn)行數(shù)據(jù)傳輸時(shí)，采用發(fā)送/應(yīng)答／握手／失敗方式，即發(fā)送一幀數(shù)據(jù)，一個(gè)應(yīng)答，若應(yīng)答沒收到，重新進(jìn)行協(xié)商握手，握手失敗則向應(yīng)用程序報(bào)告錯(cuò)誤。

在利用RBTFT 協(xié)議進(jìn)行實(shí)際的文件傳輸時(shí)，首先第一步是進(jìn)行串口初始化操作，在串口初始化成功時(shí)，通過異步消息RBTFT C0NNECT向應(yīng)用程序報(bào)告，表示一條通信鏈路建立完畢。開始發(fā)送數(shù)據(jù)時(shí)，應(yīng)用程序根據(jù)內(nèi)部緩沖區(qū)的大小決定每次真正可發(fā)送的數(shù)據(jù)量，數(shù)據(jù)將被存儲(chǔ)在內(nèi)部緩沖區(qū)內(nèi)，按照RBTFT協(xié)議，內(nèi)部緩沖區(qū)的數(shù)據(jù)分割成一幀一幀并加人幀信息和CRC校驗(yàn)信息，每一幀將調(diào)用內(nèi)部線程發(fā)送數(shù)據(jù)，當(dāng)內(nèi)部緩沖區(qū)的數(shù)據(jù)全部發(fā)送完畢（即內(nèi)部緩沖區(qū)為空）時(shí)，則向應(yīng)用程序發(fā)送消息表示內(nèi)部緩沖區(qū)的數(shù)據(jù)全部發(fā)送完畢，應(yīng)用程序?qū)⒖衫^續(xù)發(fā)送其余的數(shù)據(jù)。在接收方，每到達(dá)一幀時(shí)，接收方就判讀幀信息、對(duì)到達(dá)的數(shù)據(jù)進(jìn)行接收并進(jìn)行CRC校驗(yàn)，若發(fā)生錯(cuò)誤則通過RBTFT協(xié)議所定義的方式進(jìn)行重發(fā)或協(xié)商，當(dāng)通信能繼續(xù)則不向應(yīng)用程序發(fā)送任何消息，繼續(xù)保持鏈路，若通信不能繼續(xù)，則放棄此鏈路，并且向應(yīng)用程序發(fā)送RBTFT ERROR的消息，應(yīng)用程序?qū)⒅匦聫?fù)位此鏈路或進(jìn)行其它相應(yīng)的處理。另外，當(dāng)有任何一方斷開鏈接，應(yīng)用程序?qū)⒔邮盏絉BTFT CLOSE消息，表示此鏈路已經(jīng)斷開。在接收端，所接收到的分幀的數(shù)據(jù)被去掉幀頭重新歸到接收緩沖區(qū)流，重新拼裝為所傳輸?shù)奈募?。然后，再進(jìn)行下一個(gè)文件的傳輸，直至傳輸完所有的文件。

對(duì)于在應(yīng)用層提高藍(lán)牙無(wú)線連接的可靠性而言，最為可貴的是RBTFT協(xié)議支持?jǐn)帱c(diǎn)續(xù)傳。我們目前所實(shí)現(xiàn)的也就是將RBTFT文件傳輸協(xié)議嵌人到藍(lán)牙無(wú)線文件傳輸?shù)膽?yīng)用中，這樣，即便出現(xiàn)文件傳輸中斷的情況，也可以進(jìn)行斷點(diǎn)續(xù)傳。這對(duì)于大文件無(wú)線傳輸尤為有意義。

RBTFT協(xié)議支持?jǐn)帱c(diǎn)續(xù)傳的原理在于RBTFT數(shù)據(jù)幀在報(bào)頭中攜帶有指明文件數(shù)據(jù)在文件具體某個(gè)位置開始的偏移量。當(dāng)發(fā)生錯(cuò)誤或連接中斷時(shí)，接收方發(fā)送一個(gè)帶有偏移量的信息幀，說明它希望發(fā)送方從該位置重新開始傳輸。這樣就無(wú)需重傳整個(gè)文件，從而實(shí)現(xiàn)了斷點(diǎn)續(xù)傳。

5.2 藍(lán)牙文件傳翰RBTFT協(xié)議發(fā)送文件的詳細(xì)過程

以下是藍(lán)牙文件傳輸RBTFT 協(xié)議發(fā)送單個(gè)文件的詳細(xì)過程：

n =0； //初始化重試次數(shù)計(jì)數(shù)器，收發(fā)雙方建立連接；

file = fopen （filename，“rb ”）； 設(shè)置并發(fā)送包含文件名、文件長(zhǎng)度的報(bào)頭；

for （ ； ；） {

message =所讀取接收方發(fā)來的響應(yīng)報(bào)頭信息；

switch （message） {

case 接收方返回“已經(jīng)準(zhǔn)備接收”：

發(fā)送第一個(gè)數(shù)據(jù)子包，并以子包結(jié)束符指明后面有后續(xù)包；

Continue ；

case 接收方拒絕接收：

fclose （file）；

return OK；

case 接收方返回確認(rèn)信息：

發(fā)下一個(gè)包；

Continue；

case 超時(shí)：n=n+l；

if （n》20）//重試20 次，若還不能恢復(fù)連接，則放棄

{return ERROR;}

else if

｛重新建立連接；

請(qǐng)求接收方發(fā)送帶有偏移量的信息幀；

接收該信息幀；

從指定偏移量處開始繼續(xù)傳送；

Continue;}

case 接收方放棄傳輸：

return ERROR;

case 文件傳輸完畢：

輸出“文件傳輸完畢”的屏幕提示信息；

return OK；

}

6 結(jié)論

本文敘述了藍(lán)牙無(wú)線連接在射頻、基帶協(xié)議、鏈路管理協(xié)議（LMP）中采用的可靠性措施，包括：差錯(cuò)檢測(cè)和校正、進(jìn)行數(shù)據(jù)編解碼、差錯(cuò)控制、數(shù)據(jù)加噪等。為了進(jìn)一步在無(wú)線連接中提高藍(lán)牙文件傳輸?shù)目煽啃裕谒{(lán)牙RFCOMM協(xié)議的基礎(chǔ)之上建立了本文所描述的藍(lán)牙的文件傳輸協(xié)議，稱之為RBTFT，其中，創(chuàng)造性地提出了支持文件斷點(diǎn)續(xù)傳的辦法，并得到了實(shí)現(xiàn)，從而在應(yīng)用層有效地提高了藍(lán)牙無(wú)線連接的可靠性。我們相信，在切實(shí)提高了藍(lán)牙無(wú)線連接的可靠性之后，藍(lán)牙技術(shù)將會(huì)得到更加廣泛的應(yīng)用。