|
|
|
16-7 邏輯鏈路控制與調適協定
16-7-1 LACAP 協定堆疊 『邏輯鏈路控制與調適協定』（Logical Link Control and Adaptation Protocol, 簡稱為 L2CAP）的功能如同 IEEE 802.2 LLC（Logical Link Control）協定一樣，都是處理上層通訊協定連結到共享網路媒介的鏈路控制，包含有網路媒介的多工處理、協定單元的分段與組合、錯誤檢出與重送、以及通訊連線的建立與終止等等。圖 16-19 為 L2CAP 層與其它高層通訊協定的關係，L2CAP 協定為了能連結各種高層協定，制定了一系列的標準介面，其它通訊軟體只要能合乎標準介面規格，便能順利連結到 L2CAP 層次，再由 L2CAP 層來呼叫以及連結到基頻（Baseband）層。也就是說，通訊協定只要能符合 L2CAP 的介面標準，便能將它的應用軟體安裝在 Bluetooth 裝置上。
圖 16-19 L2CAP 層與高層協定的關係 目前 Bluetooth 規格中已有許多上層協定的標準，相信近來會有更多的通訊協定加入標準之中。我們用圖 16-19 為範例，來介紹一些上層通訊協定的運用，這對我們認識 Bluetooth 網路非常有幫助，敘述如下： ● RFCOMM（Radio Frequency Communication）：『射頻通訊』（RFCOMM）協定是 Bluetooth SIG 協會利用現有的 GSM TS07.10 標準制定而成，主要功能是模擬 RS-232 串列埠口內的控制與資料訊號，也就是模擬 RS-232 串列的通訊協定。因此 RFCOMM 上層可以連接 PPP（Point-to-Point Protocol）（類似 Modem 功能），並可透過 PPP 協定連結到其它通訊軟體，譬如 IP 或 IPX 協定。由此可見，L2CAP 只要透過 RECOMM 層的連結功能，便能銜接到 Internet 網路，而目前透過 PPP 協定的應用軟體已經非常普遍。 ● TCS（Telephone Control Specification）：『電話控制規格』（TCS）包括 TCS Binary 與 AT-Command 兩部份，TCS Binary 是 Bluetooth SIG 協會基於 ITU-T Recommendation Q.931 標準所制定的協定，定義在 Bluetooth 裝置之間建立語音（Speech）與資料（Data）通訊所需的呼叫控制命令（Call Control Signalling），使 Bluetooth 裝置能與傳統的電話設備相結合。另外，AT-Command 命令是根據 ITU-T V.250 與 ETSI 300 916（GSM 07.07）標準，定義控制行動電話與數據機之間的指令集。因此，透過 TCS 協定便可連結一般有線電話或行動電話。 ● SDP（Service Discovery Protocol）：『服務發現協定』（SDP）是使用於發現網路中有哪些可用的服務、以及這些服務特性的通訊協定。由於 Bluetooth 裝置（無線網路）攜帶方便，移動中的網路環境必定隨時變化：當裝置進入新的網路範圍時，必須搜尋新的環境是否能給予服務。它的運作方式是當某一裝置（Client）進入新的網路服務範圍時，即由 SDP 協定尋找該網路（或稱 Server）所能提供的服務類型；而當裝置（Client）離開網路範圍時，SDP 協定也能偵測出該網路（或 Server）所提供的服務已經不存在。 ● Voice：一般語音（Voice）傳輸都是利用同步傳輸（SCO 連線），如果針對封包式（經過壓縮處理）的語音，也可透過 L2CAP 來利用非同步傳輸（ACL 連線）。 16-7-2 多工與邏輯通道 基本上，L2CAP 僅提供非同步的 ACL 連線，並不提供同步通訊的 SCO 連線。另外，在 ACL 連線中的 AUX1 封包也被禁止使用，因為 AUX1 封包並不提供 CRC 錯誤檢出的功能。傳送資料若無法被檢測出是否有錯誤發生，也就無法執行重送的功能，而 L2CAP 大多連結應用系統，因此不適合使用 AUX1 封包。 圖 16-20 為 L2CAP 多工處理的功能圖，在 L2CAP 層提供多個『邏輯通道』（Logical Channel）存取點，每一通道給予一個『邏輯通道識別碼』（logical Channel IDentifier, CID）。上層的通訊軟體只要銜接到一個邏輯通道，便能夠連結到 L2CAP 層的通訊軟體。裝置內系統大多是使用分時多工的方法，來輪流服務已銜接上的邏輯通道；但對於任何通訊軟體而言，卻好像獨享 L2CAP 協定的通訊軟體（如同一般分時多工系統的功能）。依照邏輯通道的傳輸型態可區分為： (1) 資料通道（Data Channel）：只供傳輸資料使用，又可區分為連接導向（Connection-oriented）與非連接（Connectionless）資料連線，其中連接導向為雙向傳輸的『全雙工』（Duplex）模式，而非連接方式為單工模式（Simplex）。 (2) 訊號通道（Signaling Channel）：只供傳遞控制訊號使用，有關建立或終止連線、以及相關控制訊號皆由此通道傳遞。
圖 16-20 L2CAP 層的邏輯通道 CID 在 L2CAP 協定中是非常重要的識別碼，每一裝置內的每一個 CID 識別碼分別代表一條與遠端裝置（L2CAP 協定）的連接，而遠端裝置也以一個 CID 碼來對應。CID 碼共有 16 個位元，可表示範圍是 0 ~ 65535，通常是在建立邏輯通道時，再動態分配（Dynamically Allocate）給上層通訊軟體；但 0x0000 未指定使用、0x0001 保留給『訊號通道』（Signaling Channel）使用、0x0002 保留給『非連接接收通道』（Connectionless Reception Channel）使用、另 0x0003 ~ 0x003F 保留未來發展使用，其餘識別碼則可以任意指定使用（連接導向的識別碼）。由於每一裝置的非連線接收通道只有一個，並且固定在 0x0002 的 CID 識別碼上，因此每一裝置只能接受一條非連接連線，但可針對多個裝置發送多條非連接連線。CID 識別碼與通道型態之關係如表 16-6 所示。 表 16-6 CID 識別碼分類
圖 16-21 為 L2CAP 的連結範例，其中裝置 #2（Master 裝置）分別與裝置 #1、裝置 #3 建立連接導向連線，其中和裝置 #1 更建立起兩條連線。另一方面，裝置 #2 也分別和裝置 #4 與 #5 各建立一條非連接方式的連線。為了能保持及控制這些資料連線，裝置 #2 分別與各個裝置之間建立一條控制連線，由之間的控制連線來管理這些資料連線的起始或終止。
圖 16-21 邏輯通道連接範例 其實 L2CAP 的資料通道與訊號通道對下層通訊協定的連接並不相同，訊號通道是傳輸有關 ACL 連線的建立與終止控制訊息，譬如所建立的資料通道是單一時槽或多時槽、以及希望基頻層所傳送的封包格式等等，因此訊號通道是連結到 LMP（Link Manager Protocol）層次上。L2CAP 接受上層通訊協定的要求，透過訊號通道將所期望的通訊方式傳輸給 LMP 層，再由 LMP 層下達控制命令給基頻（Baseband）層，由基頻層建立相關傳輸時槽以及封包格式。然而資料連線只負責傳遞資料，其中並不包含相關的控制訊息，因此只要連結到基頻層即可，如圖 16-22 所示。
圖 16-22 訊號通道與資料通道 16-7-3 L2CAP 封包格式 圖 16-23 為 L2CAP 封包格式，其中包含非連接（Connectionless）、連接導向（Connection-oriented）與訊號命令（Signaling Command）等三種格式，在訊號命令格式中，每個封包也許會包含若干個命令，每一個命令格式如圖 16-23 (d) 所示。L2CAP 封包內各欄位功能如下：
圖 16-23 L2CAP 封包格式 ● Length：表示此封包所承載訊息的長度，其中也包含 PSM 欄位（如非連接方式的封包）的長度，單位為位元組。 ● Channel ID（CID）：通道識別碼，表示該封包目的地的 CID 識別碼，如非連接封包則固定為 0x0002，而訊號命令封包則固定為 0x0001。 ● PSM（Protocol Service Multiplex）：『協定服務多工』。在非連接封包上多出來一個 PSM 欄位，此欄位用來標明本封包所承載的訊息是屬於哪一個通訊協定的。PSM 內容的規範是由 ISO 3309 規格擴充而來，該值必須為奇數（ODD），且最高位元必須為 0；目前 Bluetooth 所規範的通訊協定與 PSM 值的分配如表 16-7 所示。 ● Information：訊息。此欄位承載上層通訊協定的封包。 由上面的敘述可以發現，各種封包內並沒有來源 CID（Source CID）欄位，表示對連接導向封包而言，在同一個裝置上的上層應用軟體（L2CAP 的上一層）只能給予一條連線，否則便無法分辨。譬如，上層通訊協定為 RFCOMM，則通訊雙方僅能針對 RFCOMM 建立一條連線。至於非連接封包，因為它是動態的連線，傳遞完資料後該連線就消失，因此利用 PSM 欄位來分辨即可。另一者，訊號命令封包本來就固定在 0x0001 位址上，也不需要分辨，而且它也是非連接方式，訊號傳遞完成後該連線便自然消失。 表 16-7 PSM 數值規範
訊號命令封包與連接導向封包有相同的封包標頭，但它的 CID 數值固定為 0x0001，且其承載訊息部份也許會包含若干個命令，每一個命令的格式如圖 16-23 (d) 所示，各欄位功能如下： (1) Code：表示此命令型態，表 16-8 為目前 Bluetooth 所制定的命令彙集。 (2) Identifier：回應命令（Response）時，用來標示對應到哪一個要求命令（Request）。每一個要求命令都會設定一個識別值，而對方回應時便依照該識別值來標示自己是針對哪一個命令所做的回覆。 (3) Length：表示該命令所承載資料（或命令參數）的長度，單位為位元組。 (4) Data：該命令所需的資料或參數。 表 16-8 為 L2CAP 訊號命令的彙集，各種命令會依實際需要承載一些資料或參數，而這些資料參數都有一定的格式。也就是說，Data 欄位會依照各種命令再劃分為若干個子欄位。有關這些子欄位如何定義，請參考『Bluetooth Core Specification Part D』，本書限於篇幅不再一一介紹。 表 16-8 L2CAP 訊號命令彙集
16-7-4 封包分段與重組 L2CAP 協定建立邏輯通道之前，雙方必須利用訊號通道協議出『最大傳輸量』（Maximum Transmission Unit, MTU）、以及所欲建立連線的『服務品質』（Quality of Service, QoS）。由於基頻傳輸是利用無線電波，每次所能傳送的封包比較小，因此，一般 L2CAP 協定封包傳送到基頻層時，大多已經過分段處理（segment）；接收端收到一連串的封包後，再將其重組（Reassembly）還原成 L2CAP 封包格式。MTU 就是表示每個傳送封包的大小，也就是說，如果 L2CAP 封包超過雙方協議的 MTU 大小，L2CAP 層傳送封包給基頻層時，該封包便必須經過分段處理。（如圖 16-24 所示）
圖 16-24 L2CAP 協定的封包分段 圖 16-24 為 L2CAP 與基頻層之間的封包分段情形，分段後的第一個封包（或未經分段處理的封包）將其 Payload Header 內的 L_CH 欄位設定為 10，而緊跟其後的分段封包則將自己的 L_CH 設定為 01（請參考圖 16-11）。分段後的封包便依照傳輸格式（DM1、DH1、DM3、DH3、DM5 或 DM6），決定是否將資料經過 1/3 FEC 或 2/3 FEC 編碼，並計算 CRC 檢查值且填入 CRC 欄位上。 接收端收到資料後，依照 CRC 檢查碼診斷該封包是否發生錯誤，如發生錯誤便可以要求對方重送。這裡最重要的一點是，L2CAP 所建立的邏輯鏈路是使用『停止與等待』（Stop-and-Wait）的流量控制法，傳送端每傳送一個封包，便須等待對方回應是否正常接收；而接收端每收到一個封包後，亦須經過 CRC 檢查再決定是否要求對方重送或繼續傳送下一個封包，因此不會涉及緩衝器不足的問題（有關流量控制請參考本書第三章說明）。 16-7-5 層次介面 L2CAP 的層次介面（Layer Interface）如同 IEEE 802.2 LLC 一樣，具有四個基礎呼叫（Primitive）：Request、Indication、Confirm 與 Response。無論 L2CAP 的命令呼叫或資料傳遞呼叫，其運作方式都如同圖 16-25 所示，上層協定可能是 RFCOMM、TCS 或 SDP，而下層協定也許是 LMP 或 Baseband。
圖 16-25 L2CAP 層次介面的交談 L2CAP 傳遞到上下層的命令是由許多不同的事件（Event）與命令（Command）所組成。事件（Event）包括上層發出的連線要求（Connection Request）、資料寫入要求（Data Write Request）、或是中斷連線要求（Diconnection Request），下層可能是發出連線要求或中斷連線等事件。每一事件會延伸若干個命令出來，譬如圖 16-25 中，客戶端（Client） 的上層協定發出 L2CA_Request 命令（要求事件）給 L2CAP 協定，由 L2CAP 協定產生 L2CAP_Request 命令（要求事件），該要求事件是由 LP_Request 命令來達成。而伺服端（Server）下層的 LP_Response 命令，則用來回應連線要求事件（L2CAP_Response）。 各種資料及訊號通道的建立方式，大多如同圖 16-25 所示，至於各種命令的運作方式，請參考『Bluetooth Core Specification Park D』。
|
翻轉工作室：粘添壽
電腦網路與連結技術：
翻轉電子書系列：
|
