0NC0NN_IND信令，并聲明自己處于不可連接模式。廣播方不監(jiān)聽掃描 方發(fā)來的信令； 4) 可掃描非定向廣播事件(Scannableundirectedevent):廣播方向周圍所有的掃描 方廣播ADV_SCAN_IND信令。廣播方只監(jiān)聽掃描方發(fā)來的SCAN_REQ信令，然后向掃描方發(fā)送 SCAN_RSP信令。
[0033]掃描狀態(tài)（ScanningState)可分為： 1)被動(dòng)掃描(Passivescanning):處于被動(dòng)掃描模式的掃描方只能監(jiān)聽廣播方廣播的 信令，不能對(duì)外發(fā)送數(shù)據(jù)； 2)主動(dòng)掃描(Activescanning):處于主動(dòng)掃描模式的掃描方監(jiān)聽廣播方廣播的信令， 只對(duì)廣播ADV_IND信令和ADV_SCAN_IND信令的廣播方發(fā)送SCAN_REQ信令，發(fā)送完畢后繼續(xù) 監(jiān)聽廣播方發(fā)來的SCAN_RSP信令。
[0034]在發(fā)起狀態(tài)（InitiatingState)中： 處于發(fā)起狀態(tài)的發(fā)起方可以對(duì)廣播ADV_IND信令和ADV_DIRECT_IND信令的廣播方發(fā)送 CONNECT_REQ信令。
[0035] 廣播信道的廣播狀態(tài)(AdvertisingState)，掃描狀態(tài)（ScanningState)和發(fā)起 狀態(tài)（InitiatingState)三種狀態(tài)對(duì)應(yīng)的信令關(guān)系如表7所示。
[0036] 表7 在GAP層中，定義了4種角色：廣播角色（BroadcasterRole)、觀察角色（Observer Role)、外圍角色（PeripheralRole)和中心角色（CentralRole)。
[0037] 1)廣播角色:處于廣播角色的設(shè)備以低功耗模式向周圍廣播，但不會(huì)響應(yīng)其他設(shè) 備發(fā)來的連接請(qǐng)求，即處于廣播角色的設(shè)備處于不可連接模式； 2) 觀察角色:處于觀察角色的設(shè)備可以掃描處于廣播角色的設(shè)備，但不能發(fā)起連接請(qǐng) 求，即處于觀察角色的設(shè)備處于不可連接模式； 3) 外圍角色:處于外圍角色的設(shè)備以低功耗模式向周圍廣播，響應(yīng)其他設(shè)備發(fā)來的連 接請(qǐng)求，即處于外圍角色的設(shè)備處于可連接模式； 4) 中心角色:處于中心角色的設(shè)備可以掃描處于外圍角色的設(shè)備，可以發(fā)起連接請(qǐng)求， 即處于中心角色的設(shè)備處于可連接模式。
[0038]LL層與GAP層的對(duì)應(yīng)關(guān)系如表8所示，其中，"E"表示不支持，"M"表示必須支持，"0" 表示選擇支持，"0/E"表示如果中心角色支持被動(dòng)掃描，那么中心角色選擇支持主動(dòng)掃描， 否者中心角色必須支持主動(dòng)掃描。
[0039] 表 8 然后對(duì)傳統(tǒng)藍(lán)牙協(xié)議進(jìn)行詳細(xì)說明如下。
[0040]傳統(tǒng)藍(lán)牙的優(yōu)點(diǎn)是傳輸數(shù)據(jù)量較大，數(shù)據(jù)傳輸速率也較快，適用于各種不同的實(shí) 際應(yīng)用。傳統(tǒng)藍(lán)牙協(xié)議的開發(fā)主要在邏輯鏈路控制與適配協(xié)議（LogicalLinkControl andAdaptationProtocol,L2CAP)，通用訪問協(xié)議層（GenericAccessProfile，GAP)和 應(yīng)用層(ApplicationProfile)，下面將分別作介紹。
[0041]根據(jù)藍(lán)牙聯(lián)盟發(fā)布的傳統(tǒng)藍(lán)牙協(xié)議，邏輯鏈路控制與適配協(xié)議(LogicalLink ControlandAdaptationProtocol,L2CAP)定義了命令格式和數(shù)據(jù)格式。
[0042]兩個(gè)藍(lán)牙設(shè)備在通信過程中需要交互一系列的命令，命令信道的通用信令格式如 表9所示。
[0043]
表9 其中，Length表不Commands的字節(jié)長度;ChannelID固定為0x0001 ;Commands中的Code表示命令的類型，如連接請(qǐng)求（Connectionrequest)，連接回復(fù)（Connectionresponse)， 如表10所示；Commands中的Identifier用來匹配請(qǐng)求和回復(fù)；Commands中的Length表示 Commands中的Data的字節(jié)長度;Commands中的Data表示命令可攜帶的信息。
[0044] 表1〇 連接請(qǐng)求的Commands格式如表11所示。其中，PSM表示協(xié)議/服務(wù)復(fù)用，分為兩部分，第 一部分固定由藍(lán)牙聯(lián)盟分配用作協(xié)議，第二部分由系統(tǒng)動(dòng)態(tài)分配用作服務(wù)，最少占2個(gè)字節(jié) 長度;SourceCID(源信道ID)表示發(fā)送連接請(qǐng)求的藍(lán)牙設(shè)備的信道ID。
[0045] 表11 連接回復(fù)的Commands格式如表12所示。
[0046] 表12 其中，DestinationCID(目的信道ID)表示發(fā)送連接回復(fù)的藍(lán)牙設(shè)備的信道ID;Source CID(源信道ID)表示接收連接回復(fù)的藍(lán)牙設(shè)備的信道ID，直接從連接請(qǐng)求命令的Source CID復(fù)制;Result表示連接請(qǐng)求信令的結(jié)果，例如連接成功(Connectionsuccessful)、待定 (Connectionpending)和拒絕（Connectionrefused)，如表 13所不；
表13 對(duì)于連接請(qǐng)求信令的結(jié)果為待定的情況，用Status來進(jìn)一步闡述結(jié)果為待定的原因， 如表14所示。
[0047]表14
通用訪問協(xié)議(GenericAccessProfile,GAP)定義了查詢、可被發(fā)現(xiàn)、連接、可被連 接和已連接等狀態(tài)和流程。
[0048]藍(lán)牙設(shè)備通過時(shí)分復(fù)用方式可以同時(shí)查詢附近的藍(lán)牙設(shè)備和被附近的藍(lán)牙設(shè)備 發(fā)現(xiàn)，即傳統(tǒng)藍(lán)牙設(shè)備可以同時(shí)擔(dān)任查詢?cè)O(shè)備（Inquiringdevice)和可被發(fā)現(xiàn)設(shè)備 (Discoverabledevice)。查詢?cè)O(shè)備通過查詢獲得可被發(fā)現(xiàn)設(shè)備的藍(lán)牙地址。
[0049]查詢?cè)O(shè)備和可被發(fā)現(xiàn)設(shè)備可能已經(jīng)與另外一個(gè)藍(lán)牙設(shè)備處于連接狀態(tài)，但仍保持 查詢和可被發(fā)現(xiàn)功能。
[0050]藍(lán)牙設(shè)備通過時(shí)分復(fù)用方式可以同時(shí)連接附近的藍(lán)牙設(shè)備和被附近的藍(lán)牙設(shè)備 連接，即藍(lán)牙設(shè)備可以同時(shí)擔(dān)任連接設(shè)備（Connectingdevice)和可被連接設(shè)備 (Connectabledevice)。連接設(shè)備向可被連接設(shè)備發(fā)送連接請(qǐng)求(ConnectionRequest); 可被連接設(shè)備向連接設(shè)備發(fā)送連接回復(fù)(ConnectionResponse)。連接成功后，發(fā)起連接的 藍(lán)牙設(shè)備在網(wǎng)絡(luò)中成為主機(jī)(Master)，被連接的藍(lán)牙設(shè)備在網(wǎng)絡(luò)中成為從機(jī)(Slave)。
[0051] 本發(fā)明結(jié)合低功耗藍(lán)牙和傳統(tǒng)藍(lán)牙的特點(diǎn)，提供了一種基于藍(lán)牙的可穿戴設(shè)備與 移動(dòng)終端自動(dòng)連接的方法。請(qǐng)參見圖1，圖1是本發(fā)明所述基于藍(lán)牙的可穿戴設(shè)備與移動(dòng)終 端自動(dòng)連接的方法較佳實(shí)施例的流程圖。如圖1所示，所述基于藍(lán)牙的可穿戴設(shè)備與移動(dòng)終 端自動(dòng)連接的方法，包括步驟： 步驟S100、可穿戴設(shè)備通過藍(lán)牙廣播藍(lán)牙名稱； 步驟S200、智能終端掃描獲取可穿戴設(shè)備的藍(lán)牙名稱，當(dāng)該藍(lán)牙名稱存在于智能終端 中預(yù)先寫入的藍(lán)牙名稱列表時(shí)，則將可穿戴設(shè)備的藍(lán)牙名稱寫入掃描列表。
[0052] 本發(fā)明的實(shí)施例中，所述步驟S100中可穿戴設(shè)備通過藍(lán)牙方式(也即傳統(tǒng)藍(lán)牙方 式)或低功耗藍(lán)牙方式廣播藍(lán)牙名稱，并發(fā)射藍(lán)牙信號(hào)；其中，藍(lán)牙方式為支持藍(lán)牙2.0、藍(lán) 牙2.1或藍(lán)牙3.0的方式;低功耗藍(lán)牙方式為支持BluetoothSmart的方式。具體實(shí)施時(shí)，所 述可穿戴設(shè)備為智能手表、智能手環(huán)、智能眼鏡、智能跑鞋或智能戒指等。所述智能終端為 智能手機(jī)、平板電腦、筆記本電腦或臺(tái)式電腦等搭載操作系統(tǒng)的終端。
[0053]步驟S100及步驟S200在具體實(shí)施時(shí)，以智能終端為智能手機(jī)來具體說明。可穿戴 設(shè)備通過藍(lán)牙廣播預(yù)定義的藍(lán)牙名稱，同時(shí)發(fā)射藍(lán)牙信號(hào)；智能手機(jī)通過藍(lán)牙掃描(查詢） 周邊的藍(lán)牙設(shè)備并過濾出具有和智能終端中預(yù)先寫入的藍(lán)牙名稱列表里藍(lán)牙名稱相同的 可穿戴設(shè)備，同時(shí)檢測(cè)對(duì)應(yīng)的可穿戴設(shè)備的藍(lán)牙信號(hào)獲取RSSI(ReceivedSignal StrengthIndication，接收信號(hào)強(qiáng)度指示）。這里定義的藍(lán)牙功能和流程適用于低功耗藍(lán) 牙方式和藍(lán)牙方式，以下將分別作描述。
[0054] 若可穿戴設(shè)備與智能手機(jī)都支持低功耗藍(lán)牙?？纱┐髟O(shè)備以低功耗模式廣播，31 字節(jié)的廣播數(shù)據(jù)包中帶有ADType為0x09的藍(lán)牙名稱消息段。安裝在智能手機(jī)端的APP應(yīng)用 預(yù)先寫入該藍(lán)牙名稱，因此智能手機(jī)在被動(dòng)掃描周邊的低功耗藍(lán)牙設(shè)備時(shí)，會(huì)從得到的掃 描結(jié)果中，根據(jù)預(yù)先寫入的藍(lán)牙名稱，過濾出和預(yù)先寫入的藍(lán)牙名稱相同的可穿戴設(shè)備，獲 得掃描列表。
[0055]若可穿戴設(shè)備與智能手機(jī)都支持傳統(tǒng)藍(lán)牙?？纱┐髟O(shè)備處于可被發(fā)現(xiàn)模式，廣播 藍(lán)牙名稱。安裝在智能手機(jī)端的APP應(yīng)用預(yù)先寫入該藍(lán)牙名稱，因此智能手機(jī)在查詢周邊的 傳統(tǒng)藍(lán)牙設(shè)備時(shí)，會(huì)從得到的查詢結(jié)果中，根據(jù)預(yù)先寫入的藍(lán)牙名稱，過濾出和預(yù)先寫入的 藍(lán)牙名稱相同的可穿戴設(shè)備，形成查詢列表(為了和低功耗藍(lán)牙保持統(tǒng)一，這里的"查詢列 表"也稱為"掃描列表"）。
[0056] 進(jìn)一步的，如圖1所示，所述步驟S200之后還包括： 步驟S300、智能終端獲取與掃描列表中每一可穿戴設(shè)備對(duì)應(yīng)的當(dāng)前藍(lán)牙接收信號(hào)強(qiáng)度 指示值，若可穿戴設(shè)備的當(dāng)前藍(lán)牙接收信號(hào)強(qiáng)度指示值高于預(yù)設(shè)的藍(lán)牙接收信號(hào)強(qiáng)度指示 閾值時(shí)，則與對(duì)應(yīng)的可穿戴設(shè)備建立藍(lán)牙連接。具體實(shí)施時(shí)，所述藍(lán)牙接收信號(hào)強(qiáng)度指示閾 值為 _30dBm。
[0057] 進(jìn)一步的，所述步驟S200中，還包括智能終端檢測(cè)已寫入掃描列表的可穿戴設(shè)備 發(fā)射藍(lán)牙信號(hào)的當(dāng)前藍(lán)牙接收信號(hào)強(qiáng)度指示值。
[0058]可穿戴設(shè)備廣播特定的藍(lán)牙名稱，并且發(fā)射藍(lán)牙信號(hào)；智