蓝芽无线电话系统与服务搜寻协定实作.docx

《蓝芽无线电话系统与服务搜寻协定实作.docx》由会员分享，可在线阅读，更多相关《蓝芽无线电话系统与服务搜寻协定实作.docx（16页珍藏版）》请在三一办公上搜索。

1、教育部八十九學年度通訊科技專題製作競賽入選論文集藍芽無線電話系統與服務搜尋協定實作指導老師：侯廷昭參賽隊員：許宏凱 張逸豪 施富仁 賴振德國立中正大學電機工程研究所1教育部八十九學年度通訊科技專題製作競賽入選論文集摘要：Bluetooth 的發展解決許多短距離無線連結的需求。但在 Bluetooth 相關產品陸續推出時卻有一技術最為複雜、相關技術背景知識要求最多，且目前尚無產品問世的領域 Bluetooth Telephony。在本專題中我們開發出先進的 “藍芽無線電話系統”，完全實現 Bluetooth Telephony 功能。在專題中軟體部份我們同時發展Bluetooth 協定堆疊中，幾

2、個最主要的核心技術： TCS (Telephony Control Protocol Specification) 協定、 SDP (Service Discovery Protocol) 協定、 SDAP (Service Discovery Application Profile)、以及 L2CAP (Logic Link Control and Adaptation Protocol) 協定。另外，為了彌補 Bluetooth 規格未定義詳盡的地方，我們在系統及程式發展中創造了新的輔助函式，使系統程式能完整正常的運作。在專題中的硬體部份我們採取自行製作之數位語音電路，作為日後繼續發展各項

3、應用之基礎。這個電路，我們稱之為 Bluetooth Phone Emulation Board，我們運用 PCM Codec 晶片、SLIC (Subscriber Line Interface Circuit) 晶片來完成此一電路，並整合 Bluetooth Module 於其上。我們將此電路與一般市售有線電話搭配，實現藍芽無線電話系統之功能。關鍵詞：藍芽無線電話系統、Bluetooth、TCS、SDP、L2CAP、PCM、SLIC。一、前言Bluetooth 的發展解決了許多短距離無線連結的需求，目前 Bluetooth Special Interest Group (SIG) 廠商也陸

4、續推出各式 Bluetooth 產品。在 Bluetooth 的各種應用技術中，Bluetooth Telephony 技術最為複雜、相關技術背景知識要求最多、目前也尚無產品問世。我們的主題 “藍芽無線電話系統” 完全實現 Bluetooth Telephony 功能，此項應用需結合 Telecommunication、 Data communication、Embedded System、及語音與數據整合等多項技術。由於在 Bluetooth network 中每一台 Bluetooth 設備皆可自由移動，因此在 piconet 中可提供的服務隨時都不同，這部分和傳統的網路環境具有很明顯的差

5、異。為了能夠解決這一部份的問題，Bluetooth 制定一個很獨特的協定 服務搜尋協定（SDP）。 SDP 可讓每一個應用程式隨時、即時的找到目前 piconet 中所有提供服務的設備以及其服務的特性。由於 SDP 在Bluetooth協定中極為重要，因此 “服務搜尋協定 (Service Discovery Protocol) 實作”，也是我們在此次競賽中的主題。我們的專題在技術創新部分，以更簡潔且更為快速的程式碼實現了複雜的 Telecommuni cation Signaling 功能；在程式語法上，我們比傳統實現 Q.931 Finite State Machine 的方法更為精簡，並

6、達成相同的目的；我們創造新的輔助函式，使 Bluetooth protocol 不足之處更為完備；SDP 部分，我們自建符合 SDP 環境的資料庫與搜尋方式，讓 SDP 讀寫、搜尋資料庫能夠更為快速；我們將 Bluetooth protocol stack 實現成 Embedded system module，可以隨時依需要抽換；我們在資源有限的情形下，使用一般的市售電話來實現無線手機雛型，這種方式同時也讓一般市售電話機只要接上了我們的藍芽無線通訊裝置，就能馬上具有無線電話與對講機之功能；我們在 Ericsson Bluetooth Module功能不全，不能建立Piconet 的情形下，設計

7、新的方法完成 WUG Group 建立與 Fast Inter-Member Access；在應用創新部分，透過 Bluetooth Gateway 先進的 Signaling 程序，我們可以建立起多對通話連線，可以選擇同時獨立通話而沒有數量的限制，這是目前家用無線電話無法做到的。藍芽無線電話系統與搜尋服務協定的實作成果在第五節將會做更詳細的說明。二、研究目的由於 Bluetooth 技術具有不受方向限制、可穿透障礙物、具有比傳統電話更大傳輸量、更多方面應用、以及更快傳輸速率等優點，同時 Bluetooth 也是第一個可將通訊、資訊、消費性電子產品這三類廠商結合在一起的技術；再者，Blueto

8、oth 提出後，世界各大廠一致看好並相繼加入聯盟；更何況臺灣廠商一向在消費性產品有著強大的競爭力，所以我們認為 Bluetooth是一個非常適合台灣的研究領域，我們希望能協助廠商進行先期的研究開發，並作為他們的助力。在專題題目選取方面，我們發現在一般辦公室的環境中，通常以有線電話作為電話分機，因而需要大量的佈線工程和許多昂貴的交換機設備，而有線電話由於必須固接於一處，不具可攜性，因此常會發生打電話到某分機卻找不到人，或是常需轉接數次才能找到通話對象的情形。目前市面上販售的家庭用無線電話，容易受到雜訊干擾，而且並無加密的機制，有被竊聽的危險。一般的無線電話子機有數目的限制，而且只能使用於同一廠牌

9、的母機，無法任使用者將其帶到其他場所與不同廠牌之無線母機通話。由發展 Bluetooth 技術的構想與解決上述問題的想法，我們研發出了這套系統 - ”藍芽無線電話系統”以及“藍芽服務搜尋協定”（SDP）。我們根據 Bluetooth 規格書中的Cordless Telephony Profile、 Intercom Profile、及 Service Discovery Application Profile來規劃我們的系統。我們將 Bluetooth 規格書中的 TCS Profile 加以延伸，加強了 TCS 的功能，開發以藍芽為無線傳輸媒介的無線電話系統。這樣的無線電話系統可以裝設於辦公

10、環境中，取代行之有年的有線電話分機系統，節省佈線經費及維護複雜度。同時由於 Bluetooth 技術的公開性，不同廠牌的無線子機和無線母機間的互通將成為可能。藉由 TCS 中 Group Management 的功能，藍芽無線電話系統使辦公室分機可以隨身攜帶，而隨著使用者的移動加入不同 Bluetooth Gateway 的群組中，因此可達成分機的可攜性。除了一般無線電話的應用之外，藍芽無線電話系統也支援無線子機之間互相通話的對講機功能，透過 Bluetooth Gateway 先進的 Signaling 程序，我們可以建立起無限多對通話連線，沒有數量的限制。本專題所發展之藍芽無線電話系統與服

11、務搜尋協定將來可與 PDA 或其他小型無線裝置整合，發展出能整合語音通訊、資料傳遞、資訊家電控制的多功能無線視訊電話系統。若將我們所開發的藍芽無線電話系統與行動電話系統整合在一起，更可發展出結合行動電話、室內無線電話、對講機功能於一身的三用電話。三、原理與分析1 TCS結構圖在 Bluetooth 的協定架構中，Bluetooth 無線電話系統使用到的核心，也是最主要的部分叫做 TCS Binary （Bluetooth Telephony Control protocol Specification Binary），它是根據 ITU-T Q.931 所制定出來的，與 Q.931 不同的是，T

12、CS 並沒有利用使用者和網路端來作區別，只以發話端 （Outgoing side） 與受話端 （Incoming side） 表示。如圖3.1所示，TCS 位於 L2CAP 上層，利用 L2CAP 傳送訊息及建立連結。圖3.1 TCS within the Bluetooth stackTCS功能如下：Call Control （CC）：利用 signaling 的方式建立和釋放 Bluetooth 機器之間的語音和數據通道。Group Management （GM）：利用 signaling 方式減輕管理 Bluetooth 機器所需的負擔。1.1 CALL CONTROL （CC）Call

13、 Control 主要目的是利用訊息傳遞以建立和釋放兩個藍芽裝置間的語音及資料通道其包含了兩種程序，通話建立程序 （CALL ESTABLISHMENT）及通話清除程序 （CALL CLEARING）。1.1.1 CALL ESTABLISHMENT1.1.1.1 通話的要求由發話端（Outgoing side）傳送SETUP訊號給受話端（Incoming side）來啟動整個通話建立（call establishment）的程序。發話端在傳送 SETUP MESSAGE 後，發話端的CC 狀態機進入 Call initiated 狀態，而受話端接收到SETUP MESSAGE，受話端的CC狀

14、態機會進入Call Present 的狀態。受話端傳送 CONNECT 訊息來告訴發話端它所呼叫的電話已被接通，並且停止鈴聲，開始計時 （T313計時器）。發話端收到受話端所傳來的 CONNECT 訊息後，會停止所有的計時，並且完成 SCO 或 ACL Link 兩端的連接，之後再傳送 CONNECT ACKNOWLEDGE 表示已建立起資料傳送的連結，而且進入Active狀態。而受話端在收到這個訊息後立即停止 T313 計時器，並進入Active狀態，之後兩端即可傳送資料。假使T313 計時器逾時，則發話端會啟動啟動 Call Clearing 程序。圖3.2 整個通話建立訊息傳遞的流程1.

15、1.2 CALL CLEARING發話端結束通話時，會傳送 DISCONNECT 訊息，結束與受話端之間的語音或資料通道，進入 Disconnect Request 狀態，而受話端進入Disconnect Indication 狀態。DISCONNECT 訊息告訴受話端要結束彼此之間的通訊，若彼此通訊已經結束，則受話端傳送 RELEASE 訊息給發話端會進入 Release Request 狀態。發話端收到 RELEASE 訊息後，釋放通道並傳送 RELEASE COMPLETE訊息，回到 Null 狀態。受話端收到 RELEASE COMPLETE 訊息後，回到 Null狀態。圖3.3通話清

16、除程序訊息傳遞流程1.2 GROUP MANAGEMENT （GM）1.2.1 Wireless User Group在 GM 的協定中，多台支援 TCS 的 Bluetooth 裝置可以組成一個WUG。其中有一台裝置作為 WUG master，其它裝置則為 WUG member。每個 WUG 中的成員都擁有所有 WUG member 或是 WUG master 裝置的資訊。WUG master 會藉由Configuration Distribution 將這些資訊送給所有 WUG member。1.2.2 概觀Group Management 的功能分成三個不同的程序，分別為 Obtain

17、access rights、Configuration distribution 和 Fast inter-member access，主要功能是在建立並維護Wireless User Group (WUG) 的成員資訊。1.2.2.1 Obtain Access Rights經由使用 Obtain Access Rights 的程序之後，此台裝置就具有使用位於同一個WUG 中其它裝置所提供的電話服務的權利。圖3.4 Obtain Access Rights Message Flow1.2.2.2 Configuration Distribution當 WUG 中的狀況有了改變 （例如，有裝置

18、加入或退出、WUG 結構改變） 而且有必要通知在 WUG 中的 member 時就會進行 Configuration Distribution 程序。圖3.5 Configuration Distribution Message Flow1.1.2.3 Fast Inter-Member Access當兩台 WUG member 在 WUG 中都處於可使用的狀況下，其中一台 WUG member 可利用 Fast Inter-Member Access 的程序取得和另一台之間的連接。在 Fast Inter-Member Access 的程序中，發話端會取得受話端的 clock 資訊，同時強迫

19、受話端進入 Page Scan 模式並持續一段特定的時間。圖3.6 Fast Inter-Member Access Message Flow2 Service Discovery Protocol（SDP）SDP 的架構及流程是運用 ClientServer 的模式在運作，如果 Bluetooth 設備欲在 piconet 中提供服務的話就必須具備 SDP Server 機制，必須注意的是每一台 Bluetooth 設備上無論有多少種服務項目，最多只能有一個 SDP Server。 所有由 SDP Server 提供的服務項目資訊都儲存在 SDP Server 的 Service Recor

20、d 中，每個服務項目都會儲存在個別的 Service Record 中並且有一個唯一的 Service Record handle對應，在圖3.7中每個 Service Record均包含由 SDP Server 所提供的其中一種 Service 之全部 attribute，經由此 Service Record 可將一個服務項目的所有特性描述清楚。在 Service Record 中每個 Service Attribute 均分為兩個部份， Attribute ID是用來區分此 Service Attribute 的功用，經過比對便可得知 Attribute Value存放的內容形式。圖3.7

21、 Service Record and Service Attribute每個服務項目均由許多 Service Class 組成，在 Service Class 中有分為 superclass 和 subclass 兩部份，subclass 會保留 superclass 的全部attribute 並會另外定義新的 attribute。在 SDP 中每個 Service Class 都由一個 UUID （Universally Unique Identifier） 代表不同的 Service Class，而這些 UUID 是在 attribute ID 為0x0001的 Service Attr

22、ibute 中。在 SDP 中 UUID 是由128 bit 所組成的數值，為了增進程式效能，UUID 也可以由 16-bit 或 32-bit 的數值代表。而 16-bit 或 32-bit UUID 的組成方法是由一個Bluetooth Base UUID再加上 32-bit 或 16-bit 數值所組成。其組成方式為：128_bit_value=16_bit_value * 296 + BT_Base_UUID128_bit_value=32_bit_value * 296 + BT_Base_UUIDBase UUID = 00000000-0000-1000-7007-00805F9

23、B34FB當 SDP Client 上層之 Application 要求尋找某一 Service 時會發出SDP_ServiceSearch Request PDU 向 SDP Server尋找，其中有一個參數是由特別的 UUID 所組成的 Service search pattern，當 SDP Server 收到此 PDU 後會和每個 Service Record 中 attribute 裡面的 UUID 進行比對。如果 Service search pattern 中的 UUID 完全符合 Service Record ，此時 SDP Server 會將符合條件的 Service Rec

24、ord 中的 ServiceRecordHandle 放入 SDP_Service SearchResponse PDU 內傳回給 SDP Client。接著SDP Client 端會針對其中一個 Service Record 發出 SDP_ServiceAttributeRequest PDU，進一步向 SDP Server 端查詢所需之 attribute。此外，SDP 可將 ServiceSearch Pattern 和要找的 Attribute ID 直接放入 SDP_ServiceSearchAttributeRequest PDU 送往SDP Server。利用這種做法可節省一次封

25、包所需的傳送時間，只需經過一次查詢後 SDP Server 就會將前面所提的兩步驟做完才傳回一個 SDP_ServiceAttributeResponse PDU。除了直接向 SDP Server 要求符合的 Service Record 之方法外，SDP Client 也可藉由 Browsing 的方式向 SDP Server 查詢在 SDP Server 上有提供的服務項目。而 SDP Client 經由 Browsing 後可得到表3.1的資料，經由表3.1便可由 SDP Client 組成圖3.8的架構。表3.1 Browse Table圖3.8、 Browse Hierarchy3

26、Logical Link Control and Adaptation Protocol（L2CAP）3.1 L2CAP簡介The Logical Link Control and Adaptation Layer Protocol 簡稱 L2CAP，歸屬於Bluetooth Protocol Stack中之資料鍊結層 (Data Link Layer)，主要功能在提供上層的Protocols兩種 Data Services “Connection-Oriented” 及“Connectionless“，除此之外L2CAP亦具有 Protocols Multiplexing、Segmentat

27、ion and Reassembly、Quality of Service及Group Management的功能。3.2 L2CAP層功能介紹3.2.1 Protocol MultiplexingBluetooth 的規範中允許多個上層Protocol同時運作但兩個藍芽裝置之間最多只能有一條 ACL Link，因此L2CAP必須具有 Protocols Multiplexing 的能力，並能辨別出上層不同的資料封包。L2CAP層於規範中定義了三種類型的Logical channel，分別為 Connection-Oriented、Connectionless以及Signaling，其中前兩種

28、Channel 的建立，都必須先經過Signaling的動作來完成。Connectionless Channel是提供Point to Multi-Point之連結，而Connection-Oriented Channel 則提供 Point to Point 之連結。3.2.2 Segmentation and Reassembly在規範中規定L2CAP層所能接收上層之封包最大為64K Bytes，但是Baseband接收來自L2CAP層之封包最大只有341Bytes，因此L2CAP層必須對上層較大的封包做切割的動作，使其符合Baseband所能傳送之封包大小。同樣地， L2CAP 層也必須

29、具備將多個 Baseband 封包重組還原的能力，圖3.9為L2CAP 層進行封包的切割與重組的示意圖。如果 L2CAP 層與 Baseband 之間有Host Controller Interface （HCI） Protocol 存在時，封包之切割與重組工作將由 HCI 來執行。圖3.9 Segmentation and Reassemblyservice的示意圖3.3 State Machine如圖3.10所示為 L2CAP 層與上下層 Event 與 Action 關係的示意圖。圖中的符號 L2CA_ 表示上層Protocol與 L2CAP 層間訊息的互動，符號 LP_ 表示L2CAP

30、 層與下層 Protocol 間訊息的互動，符號 L2CAP_ 表示Peer to Peer間訊息的互動。且從上層 Protocol 收到的訊息稱作Request ，相對應的回應叫 Confirm ，而從下層 Protocol 得到的訊息稱作 Indication ，相對應的回應則稱為 Response。L2CAP與上下層彼此間訊息的溝通，即經由一序列的Request，Indication、Response 及 Confirm 的動作來完成。圖3.10 L2CAP Layer Interactions以下為一簡單的 State Machine 例子，說明L2CAP層是如何根據 Event 以及

31、Channel 的 State 來觸發相關的 Action ，並最後進行 State 的轉換。圖3.11 Message Sequence Chart Of Basic Operation四、軟硬體系統1 軟體架構圖4.1所示為本專題中Bluetooth軟體部分的架構。其中 TCS、 SDP、 L2CAP 之功能已於第三章中描述。(LMP 及 Baseband 是由 Bluetooth module 的硬體及韌體來實現。)圖4.1 Bluetooth protocol stack以下我們就圖4.1中，各部份間之介面分別說明：介面 (A)： 在 TCS Profile 中，電話應用層 (Tele

32、phony Application) 與底層 (Baseband) 間存在著提供數位語音傳送的路徑 (speech path) 。TCS 中的 CC透過此介面控制該語音路徑的連接與中斷。介面 (B)： 此介面使TCS 能夠利用L2CAP所提供的非連結導向通道，點對多點 (point-to-multipoint)地傳送 signaling 訊息。Gateway (GW) 透過此介面傳送TCS 的 廣播訊息，而各 Terminal (TL) 透過此介面接收該訊息。介面 (C)： 此介面使TCS能夠透過L2CAP的連結導向通道，點對點 (point-to-point) 地傳送signaling訊息。

33、介面 (D)： 此介面使 TCS 中的 CC 能夠直接控制 LMP 以建立或釋放 SCO link。介面 (E)： 此介面使TCS中的GM在啟始和key-handling時能夠使用LMP的功能。介面 (F)： L2CAP與LMP間的介面。介面 (G)： 此介面使GM能夠直接控制LC/Baseband，並使用Baseband中的 inquiry、 paging 和 pairing 等動作。在本專題中，我們透過了 HCI 與Bluetooth Module溝通，因此 (D)、(E)、(F)、(G) 等介面的實現我們是以透過HCI間接對 LMP、Baseband下控制指令的方式來達成。在程式的實作上

34、， Bluetooth 協定堆疊中各層協定間我們以函式的呼叫與傳回值作為其介面，並完整地定義了上下層間所需提供的服務、回應、及所需傳遞的變數。這種作法不但使我們能夠在開發軟體時能夠讓各層專注於其功能的實現及正確性，同時並帶來了模組化的便利性，讓我們能在相同介面上開發新的程式碼而免去牽一髮而動全身的危險，加快了測試、整合的進度。在軟體的開發過程中為了讓上層的 TCS 及SDP可以和下層 L2CAP 分開且各自獨立發展。我們規劃了兩個方案，一是直接使用 Bluetooth module 配合軟體的開發；或是利用軟體模擬資料傳送動作，利用 Socket 作為傳送資料的通道進行開發。這兩種方式的優缺點

35、如下：在軟體方面若以 Socket 方式模擬下層傳送資料的動作，可避免每一部份的開發都需要 Bluetooth Module 而造成硬體不足的困擾，也可讓各層協定獨力發展，在發生問題或流程驗證時可減少變數，但在將來整合時必須將軟體模擬的部分改為可用於真正硬體上的架構，但這不需要花太多時間。若直接使用 Bluetooth module 發展，則未來不需面對更改架構的問題，但相對的，就沒有使用軟體模擬方法的優點，而且在我們的操作經驗中，每次測試時 Bluetooth module 要進行硬體初始的動作，而這個動作將會比用軟體模擬多花費將近十秒的時間，這一點也將造成開發人員之困擾。因此，在比較這兩種

36、方式的優缺點後，我們決定選擇以軟體模擬方式先進行開發，等開發完成後時再與硬體整合，進行完整的測試動作。而這也如我們預期的一樣，減少了很多的困擾，同時讓開發速度加快。我們將 Bluetooth 協定堆疊以 Linux Kernel Module 的方式實現在 Linux OS 上，並整合進 Embedded Linux Kernel 中。由於在 Linux Kernel Mode 中，除錯相當困難，稍有不慎即會造成系統當機，所以我們將發展過程分為兩個階段，初期在 Linux User Mode 下發展系統，成熟後再將所有 Protocol 改寫為 Kernel Module。另外，整合到 Emb

37、edded Linux System 的原因是藍芽無線電話系統為一嵌入式系統，我們必須將 Linux 作業系統的核心做大量的修改與微小化，以便在嵌入式系統中與硬體整合。另外，由於 Bluetooth Core Specification 並沒有針對介面詳加定義，所以第四章中描述的程式架構除了標準流程外，大部分都是我們自行發展的輔助函式，與實作的技巧和方法。1.1 Group Management （GM）我們在程式實作上將 WUG master 與 WUG member 分別撰寫，其流程圖分別如圖4.2、圖4.3所示。至於其動作可以分為加入 WUG 及進行 Fast Inter-Member

38、Access 流程兩部份。加入 WUG 部份可分為處理 Bluetooth裝置加入 WUG 之動作及進行 WUG member資料更新兩步驟。首先，若WUG master 收到 ACCESS_RIGHTS_REQUEST 訊息後，會呼叫 access_rights_request_server() 判斷是否要讓提出要求之 Bluetooth 裝置加入 WUG。若允許則送出 ACCESS_RIGHTS_ACCEPT 訊息，否則送出 ACCESS_RIGHTS_REJECT 訊息。當Bluetooth 裝置成功加入 WUG之後，代表 WUG 之資料已經有所更動，因此 WUG master 會進行

39、Configuration Distribution 之動作，對每台 WUG member 送出INFO_SUGGEST 訊息，藉此將目前 WUG member 之資料進行更新。在執行 Fast Inter-Member Access 動作時，若 WUG master 收到 LISTEN_REQUEST 訊息會先判斷Incoming 端是否為 WUG member，若是則將 LISTEN_SUGGEST 訊息送給Incoming 端，代表有 WUG member 要和它通話，否則送出 LISTEN REJECT 給 Outgoing 端同時將拒絕原因一併送出。當Incoming 端收到LIST

40、EN_SUGGEST 訊息後若有能力和 Outgoing 端通話便送出LISTEN ACCEPT 訊息；否則送出 LISTEN REJECT 訊息。WUG master 收到由 Outgoing 端送出之訊息後會將訊息再轉送給 Incoming 端。圖4.2 TCS WUG Master 流程圖圖4.3 TCS WUG Member 流程圖1.2 Call Control （CC）Call Control entity 是一種 Finite State Machine 的機制。而 Finite State Machine 在有事件發生時，會依本身的狀態 （CC State） 和發生的事件 (E

41、vent)，來決定該做的動作。假使在寫 C code 時單純使用switch來判斷，會需要兩層swtich，第一層判斷是哪種message，而第二層判斷state。此種方法造成debug困難，而且最主要的，就是程式碼會變的非常複雜。因此我們將 CC 所有的狀態和所有會發生的事件互相配對，而以一個二維陣列來記載不同狀態與事件的組合下所應有的動作，我們稱此二維陣列為狀態表。使用狀態表的好處有： 1. 可以清楚了解整個 Finite State Machine 的動作流程。 2. 除錯容易。 3. 可依據實際需求，輕易增加或修改程式碼。藉由圖4.4，程式可以查出應該呼叫的函式以處理發生的事件。圖4.

42、4、 State Table動作代碼與函式間的對應，我們以一 Action Vector 來完成。 Action Vector 是一個一維陣列，其中各元素皆為指向不同函式的指標 (pointer)，存放著各函式的位址。以動作代碼為此陣列之 index，即可查出動作代碼所對應的函式位址，並呼叫動作代碼所對應的函式。這種實作方式是 Specification 上面沒有提到，卻又必須要有的，我們稱之為輔助函式。圖4.5、 Action Vector以下之流程圖說明在不同狀態及事件的組合下 CC 的動作，圖4.6為通話建立程序所經過之流程，圖4.7為中斷通話所經過之流程，而圖4.8則是 timeout

43、 發生時應作之處理。圖4.6 通話建立程序所經過之流程圖4.7 中斷通話所經過之流程圖4.8 timeout 發生時應作之處理1.3 L2CAP 1.3.1 CLOSED State如圖4.9所示，當上層要與L2CAP層溝通時必需借由 L2CA_init事件把參數 (Protocol Service Multiplexer-PSM與 Return_ADDR) 告知 L2CAP 層，以作為往後區別及回傳到上層之依據。如果L2CAP層收到上層 L2CA_ ConnectReq 事件時，會先判斷參數 PSM與 Bluetooth Device Address (BD_ADDR) 是否正確，接著確認

44、Baseband ACL Link 是否存在；如果ACL Link已存在，則L2CAP層建立Logical Channel，同時儲存相關參數，接著進行 L2CAP_ConnectReq 的動作且始動RTX計數器，以確認傳送狀況，進入W4_L2CAP_ CONNECT_RSP State。這種實作方式為新增的輔助函式。圖4.9 CLOSED State流程圖如圖4.10所示，如果收到下層的LP_ConnectInd事件，L2CAP層會判斷BD_ADDR是否正確，如果正確則回應LP_ConnectRsp動作至下層，回到CLOSED State。若L2CAP層收到下層LP_Connect_Cfm 事

45、件，首先會先判斷Status參數是否成功，接著進行L2CAP_ConnectReq的動作且起始RTX計數器，進入W4_L2CAP_CONNECT_RSP State；否則以L2CA_ConnectCfm告知上層無法建立Channel，並回到CLOSED State。若收到Peer端的L2CAP_ConnectReq事件，L2CAP層會儲存相關參數且產生對應於Peer端之CID值，接著會進行 L2CA_ConnectInd動作告知上層連線狀態及CID值，且進入W4_L2CA_ CONNECT_RSP State。圖4.10 CLOSED State流程圖 (續圖 4.9)1.3.2 W4_L2C

46、A_CONNECT_RSP如圖4.11所示，L2CAP 收到上層的L2CA_ConnectRsp 事件並藉由判斷 Response參數來進行L2CAP_ConnectRsp的動作，進入CONFIG State；或傳送L2CAP_ConnectRsp，告知Peer端失敗的原因，且清除CID，進入CLOSED State。圖4.11 W4_L2CA_CONNECT_RSP State流程圖1.3.3 W4_L2CAP_CONNECT_RSP State如圖4.12所示，若收到 Peer 端所送之L2CAP_ConnectRsp 事件，L2CAP 層會先終止RTX 計數器，然後判斷 Result 參

47、數之結果，如果為Pending則傳送 L2CA_ConnectPnd 通知上層，並啟動 ERTX 計數器，回到W4_L2CAP_CONNECT_RSP State；如果成功則傳送L2CA_ConnectCfm至上層，告知建立連線的狀態及CID值，進入CONFIG State；如果失敗則傳送L2CA_ConnectCfm至上層，告知上層失敗的原因，進入CLOSED State。圖4.12 W4_L2CAP_CONNECT_RSP State流程圖1.3.5 OPEN State如圖4.15所示，若收到上層L2CA_DataWrite事件時進行L2CAP_Data的動作，將資料傳送到Peer端；若

48、收到Peer端所送的L2CAP_Data事件時，會將所收到資料利用L2CA_DataRead傳送到上層。若收到上層L2CA_DisconnectReq 事件要求中止通道會進行 L2CAP_DisconnectReq 動作，將訊息傳遞至 Peer 端，同時起動 RTX Timer 並進入 W4_L2CAP_DISCONNECT_RSP Sate。若收到Peer端送L2CAP_DisconnectReq事件則利用L2CAP_DisconnectInd通知上層，告知Peer端要求中斷通道，進入W4_L2CA_DISCONNECT_RSP State。圖4.15 OPEN State流程圖1.3.6 W4_L2CA_DIS