數(shù)據(jù)終端設(shè)備與無線通信模塊之間串行通信鏈路復(fù)用協(xié)議（TS27

    關(guān)鍵詞：TS27.010 串行鏈路復(fù)用 GPRS移動終端 嵌入式Linux

隨著移動通信技術(shù)的迅速發(fā)展，具備無線通信功能的移動終端也迅速發(fā)展起來。這些移動終端支持普通的話音、短消息等業(yè)務(wù)，隨著ＧＰＲＳ網(wǎng)絡(luò)覆蓋的迅速擴大，越來越多的手持／車載移動終端也開始支持ＧＰＲＳ上網(wǎng)業(yè)務(wù)。如何在一個終端設(shè)備上整合這些業(yè)務(wù)，這是許多移動終端設(shè)備開發(fā)者面對的問題。筆者在開發(fā)一款車載移動終端過程中，采用了３ＧＰＰ的ＴＳ ２７．０１０協(xié)議，成功地整合了這些業(yè)務(wù)。

圖1 TS27.010協(xié)議棧組成與示意圖

１ ＴＳ２７．０１０協(xié)議介紹

在常用的ＧＳＭ／ＧＰＲＳ通信模塊中（如Ｓｉｅｍｅｎｓ的ＭＣ３５、ＷａｖｅＣｏｍ的Ｑ２４００等），只能通過一個普通９針的異步串口與終端設(shè)備ＴＥ（Ｔｅｒｍｉｎａｌ Ｅｑｕｉｐｍｅｎｔ）進行通信。ＴＥ和ＭＳ?穴Ｍｏｂｉｌｅ Ｓｔａｔｉｏｎ?雪需要通過這個串口交換各種類型的數(shù)據(jù)，例如：語音、傳真、數(shù)據(jù)、ＳＭＳ、ＣＢＳ、電話號碼本的維護、電池狀態(tài)、ＧＰＲＳ、ＵＳＳＤ等。如何在一個串口上同時支持這么多的業(yè)務(wù)？例如，在數(shù)據(jù)通信過程中，怎樣發(fā)送或接收ＳＭＳ？為了解決這些問題，３ＧＰＰ提出了一個協(xié)議——ＴＳ２７．０１０協(xié)議（Ｔｅｒｍｉｎａｌ Ｅｑｕｉｐｍｅｎｔ ｔｏ Ｍｏｂｉｌｅ Ｓｔａｔｉｏｎ Ｍｕｌｔｉｐｌｅｘｅｒ Ｐｒｏｔｏｃｏｌ）。有了Ｍｕｌｔｉｐｌｅｘｅｒ，即使在數(shù)據(jù)連接過程中，也可以發(fā)送ＳＭＳ。其它業(yè)務(wù)組合也可以同時進行。例如，數(shù)字語音和ＳＭＳ同時發(fā)送。Ｍｕｌｔｉｐｌｅｘｅｒ的存在使得一個完整的系統(tǒng)能夠根據(jù)需要進行劃分。

３ＧＰＰ 的Ｍｕｌｔｉｐｌｅｘｅｒ設(shè)計非常靈活，并且獨立于ＭＳ／ＴＥ平臺，已有的應(yīng)用程序不需要改動即可工作。在設(shè)計Ｍｕｌｔｉｐｌｅｘｅｒ時，特別考慮到采用電池供電的設(shè)備的需求，所以包含了省電模式控制等很重要的功能，并且Ｍｕｌｔｉｐｌｅｘｅｒ本身在運行時也盡量使用最小的功耗和內(nèi)存。

    Ｍｕｌｔｉｐｌｅｘｅｒ基于ＩＳＯ的ＨＤＬＣ標準設(shè)計，工作于有多種選項的單模式下。但是Ｂａｓｉｃ Ｏｐｔｉｏｎ并不遵從ＨＤＬＣ。在基本選項模式下，Ｍｕｌｔｉｐｌｅｘｅｒ沒有透明機制，也沒有錯誤恢復(fù)功能。但是在高級選項（Ａｄｖａｎｃｅｄ Ｏｐｔｉｏｎ）模式下，使用ＨＤＬＣ的透明機制，且Ｍｕｌｔｉｐｌｅｘｅｒ有一個方便的再同步機制，能夠在ＤＣ１／ＤＣ３（ＸＯＮ／ＸＯＦＦ）流控打開的鏈路上工作，且包含了錯誤恢復(fù)功能。

３ＧＰＰ的Ｍｕｌｔｉｐｌｅｘｅｒ依賴于一個控制信道。在這個控制信道上，ＴＥ和ＭＳ交換控制信息，例如參數(shù)協(xié)商、節(jié)電控制信息、流控信息等。Ｍｕｌｔｉｐｌｅｘｅｒ是一個可選項，如果支持這個功能，就應(yīng)使用ＡＴ＋ＣＭＵＸ命令激活它。

Ｍｕｌｔｉｐｌｅｘｅｒ為ＴＥ和ＭＳ在一個起始／停止模式的、具有分幀功能的串行鏈路上傳輸數(shù)據(jù)流提供了一套機制。圖１給出了不同的協(xié)議層及其功能示意。Ｍｕｌｔｉｐｌｅｘｅｒ?qū)迂撠煂?shù)據(jù)按字節(jié)流的方式傳輸，不再進行進一步的組幀；如果數(shù)據(jù)需要按一定結(jié)構(gòu)傳輸，就需要增加一個會聚層來完成這些功能。

Ｍｕｌｔｉｐｌｅｘｅｒ為ＴＥ上的進程和ＭＳ上相對應(yīng)的進程提供了一條虛連接，這樣ＴＥ和ＭＳ上的進程就可以通過這條虛連接通信。例如，ＴＥ上的ＳＭＳ應(yīng)用程序可以通過一條Ｍｕｌｔｉｐｌｅｘｅｒ通道與ＭＳ上的ＳＭＳ處理程序連接起來。

ＴＳ２７．０１０規(guī)范使用８ｂｉｔ字符的ｓｔａｒｔ－ｓｔｏｐ傳輸模式，兩個Ｍｕｌｉｔｐｌｅｘｅｒ?qū)嶓w間的通信使用了規(guī)定的幀格式。ＴＥ和ＭＳ之間的每個信道稱為一條數(shù)據(jù)鏈路連接ＤＬＣ（Ｄａｔａ Ｌｉｎｋ Ｃｏｎｎｅｃｔｉｏｎ），這些ＤＬＣ被依次獨立地建立起來。每個ＤＬＣ都可以有自己的流控機制。

    Ｍｕｌｔｉｐｌｅｘｅｒ有三種工作模式：Ｂａｓｉｃ、Ａｄｖａｎｃｅｄ ｗｉｔｈｏｕｔ ｅｒｒｏｒ ｒｅｃｏｖｅｒｙ和Ａｄｖａｎｃｅｄ ｗｉｔｈ ｅｒｒｏｒ ｒｅｃｏｖｅｒｙ。這三種模式特點如下：

·Ｂａｓｉｃ：長度標識代替ＨＤＬＣ的透明機制；使用與ＨＤＬＣ不同的標志字；不能用于具有ＸＯＮ／ＸＯＦＦ流控的鏈路；從同步丟失狀態(tài)中恢復(fù)需要更長的時間。

·Ａｄｖａｎｃｅｄ ｗｉｔｈｏｕｔ ｅｒｒｏｒ ｒｅｃｏｖｅｒｙ：遵從ＩＳＯ／ＩＥＣ１３２３９的異步ＨＤＬＣ過程；可以用于具備ＸＯＮ／ＸＯＦＦ流控的鏈路上；可以更快地從失同步狀態(tài)恢復(fù)。

·Ａｄｖａｎｃｅｄ ｗｉｔｈ ｅｒｒｏｒ ｒｅｃｏｖｅｒｙ：使用了ＨＤＬＣ的錯誤恢復(fù)過程。

２ Ｗａｖｅｃｏｍ ＧＳＭ／ＧＰＲＳ模塊Ｍｕｌｔｉｐｌｅｘｉｎｇ協(xié)議介紹

筆者選用了Ｗａｖｅｃｏｍ的Ｑ２４０３Ａ，這是一款Ｅ－ＧＳＭ／ＧＰＲＳ ９００／１８００的雙頻模塊。這個模塊支持大部分常用的ＡＴ命令，但不支持標準的ＴＳ２７．０１０協(xié)議。為了能夠數(shù)據(jù)／命令復(fù)用，Ｗａｖｅｃｏｍ定義了自己的ｍｕｌｔｉｐｌｅｘ協(xié)議。

Ｗａｖｅｃｏｍ的復(fù)用協(xié)議允許一條串行鏈路上同時進行兩個會話（即虛連接）：一個ＡＴ命令的會話和一個數(shù)據(jù)通信的會話。ＡＴ＋ＷＭＵＸ＝１將激活模塊的復(fù)用模式。在這種模式下，ＡＴ命令和數(shù)據(jù)都被封裝成數(shù)據(jù)包。通過包頭，可以區(qū)分是數(shù)據(jù)包還是ＡＴ命令包。

２．１ ＡＴ命令包格式

ＡＴ命令包幀格式如圖２所示。第一個字節(jié)（０ｘＡＡ）用于標識這是一個命令包，第二個字節(jié)是ＡＴ命令長度的低八位。第三個字節(jié)由兩部分組成：低３位是ＡＴ命令長度的高３位；高３位用于標識一個ＡＴ命令。ＡＴ命令的最大長度可以為２０４７字節(jié)。校驗和?穴ｃｈｅｃｋｓｕｍ?雪是包中所有字節(jié)（包括頭和ＡＴ命令）之和對２５６取模。

圖4 Linux下串行通信數(shù)據(jù)流和函數(shù)調(diào)用示意圖

    ２．２ 數(shù)據(jù)包格式

數(shù)據(jù)包各個字段（除ｐａｃｋｅｔ ｔｙｐｅ外）意義與ＡＴ命令包相同，其幀格式如圖３所示。數(shù)據(jù)包有以下幾種類型：

·Ｔｙｐｅ＝０——ＤＡＴＡ 包：這個包是發(fā)送到無線鏈路上或者從無線鏈路上接收到的數(shù)據(jù)

·Ｔｙｐｅ＝１——ＳＴＡＴＵＳ包：這個包給出了ＳＡ、ＳＢ、Ｘ和中斷條件編碼的信息。

狀態(tài)包的長度總為１字節(jié)。任何一個狀態(tài)（除了ｂｒｅａｋ）改變時，所有的狀態(tài)位都要發(fā)送出去。缺省情況下，所有的狀態(tài)位都是關(guān)閉的（因此ＤＴＲ、ＲＴＳ都是關(guān)閉的），所以在打開復(fù)用開關(guān)準備傳送數(shù)據(jù)之前，一定要發(fā)送一個狀態(tài)包。

·Ｔｙｐｅ＝２——ＲＥＡＤＹ包：這個包表示發(fā)送ＲＥＡＤＹ包的一方可以接收數(shù)據(jù)了。包中沒有數(shù)據(jù)，所以長度字段為０。

·Ｔｙｐｅ＝３——ＢＵＳＹ 包：這個包表示發(fā)送ＲＥＡＤＹ包的一方忙，無法接收數(shù)據(jù)。包中沒有數(shù)據(jù)。

３ Ｌｉｎｕｘ下串口通信系統(tǒng)的組成

要在Ｌｉｎｕｘ系統(tǒng)上實現(xiàn)ＴＳ２７．０１０協(xié)議，就必須了解Ｌｉｎｕｘ下串口驅(qū)動軟件模塊的結(jié)構(gòu)。

圖４不但給出了Ｌｉｎｕｘ ｋｅｒｎｅｌ中串口通信模塊的組成結(jié)構(gòu)，還形象地表示出了數(shù)據(jù)是如何在用戶和硬件接口之間流動的（筆者使用Ｌｉｎｕｘ ２．４．１９的內(nèi)核）。從圖４可以看到串口通信模塊可在邏輯上分為三層：ＴＴＹ層、ｌｉｎｅ ｄｉｓｃｉｐｌｉｎｅ層和底層驅(qū)動層。ＴＴＹ層是用戶空間和內(nèi)核空間的橋梁，用戶程序和內(nèi)核需要通過ｔｔｙ層交換數(shù)據(jù)；Ｌｏｗ－ｌｅｖｅｌ ｄｒｉｖｅｒ則負責硬件的交互，它對硬件進行控制和讀寫操作；ｌｉｎｅ ｄｉｓｃｉｐｌｉｎｅ層是整個串行通信模塊中最靈活、設(shè)計最巧妙的一層，它要為一個串行口的使用定下數(shù)據(jù)交互的“規(guī)程”，在Ｌｉｎｕｘ內(nèi)核中已經(jīng)存在了許多ｌｉｎｅ ｄｉｓｃｉｐｌｉｎｅ，例如ＰＰＰ、ＳＬＩＰ、ＴＴＹ等。缺省使用ＴＴＹ ｌｉｎｅ ｄｉｓｃｉｐｌｉｎｅ?？梢愿鶕?jù)需要將ｌｉｎｅ ｄｉｓｃｉｐｌｉｎｅ替換成Ｌｉｎｕｘ已經(jīng)定義的ｌｉｎｅ ｄｉｓｃｉｐｌｉｎｅ結(jié)構(gòu)，甚至替換為自己的ｌｉｎｅ ｄｉｓｃｉｐｌｉｎｅ結(jié)構(gòu)。

在圖４中，向硬件接口寫數(shù)據(jù)的過程是顯而易見的。但是，用戶程序從硬件讀取數(shù)據(jù)的過程卻要復(fù)雜一些，這是因為硬件與用戶空間之間沒有直接的聯(lián)系。解決的辦法就是使用緩沖技術(shù)，硬件接收數(shù)據(jù)存儲于ｋｅｒｎｅｌ ｂｕｆｆｅｒ中，等待用戶程序請求這些數(shù)據(jù)；如果用戶程序請求數(shù)據(jù)時，這個ｂｕｆｆｅｒ是空的，那么用戶程序就會被掛起，直到ｂｕｆｆｅｒ中有數(shù)據(jù)時，它才被喚醒。實際上，ＴＴＹ相關(guān)的緩沖是由兩級構(gòu)成的：一個“常規(guī)”ｂｕｆｆｅｒ（數(shù)據(jù)等待著ｌｉｎｅ ｄｉｓｃｐｌｉｎｅ取走，缺省情況下傳到用戶空間）和一個“ｆｌｉｐ”ｂｕｆｆｅｒ（硬件驅(qū)動函數(shù)將底層進來的數(shù)據(jù)盡可能快地存入這個緩沖，而不必考慮并發(fā)存取問題，因為這個ｂｕｆｆｅｒ是每個硬件驅(qū)動專有的）。ｆｌｉｐ ｂｕｆｆｅｒ由兩個物理的緩沖實現(xiàn)，并被交替地寫入，這樣中斷處理函數(shù)就會總有一個緩沖可用。

Ｌｉｎｕｘ下串口軟件的這種分層結(jié)構(gòu)雖然增加了復(fù)雜性，但是它帶來的好處是多方面的。第一，串口模塊更加靈活，在為新的串口硬件編寫驅(qū)動程序時，只需修改和增加最底層的軟件即可；第二，上層應(yīng)用程序可以根據(jù)需要改變ｌｉｎｅ ｄｉｓｃｉｐｌｉｎｅ的處理軟件，在使用ＰＰＰ、ＳＬＩＰ等協(xié)議進行撥號連接時，都需要將原有的ｌｉｎｅ ｄｉｓｃｉｐｌｉｎｅ替換為ＰＰＰ或者ＳＬＩＰ協(xié)議本身的ｌｉｎｅ ｄｉｓｃｉｐｌｉｎｅ?鴉第三，可以根據(jù)需要，在層與層之間加入一層自己的處理軟件。事實上，筆者在實現(xiàn)Ｍｕｌｔｉｐｌｅｘ協(xié)議時正是這樣做的。

圖5 MUX系統(tǒng)組成

４ Ｍｕｌｔｉｐｌｅｘｉｎｇ協(xié)議的實現(xiàn)

４．１ 協(xié)議實現(xiàn)時的考慮

在實現(xiàn)ＴＳ２７．０１０協(xié)議時，基于以下考慮：第一，使用串口的上層應(yīng)用程序不需要改動。這一點很重要，因為系統(tǒng)中有許多用戶程序使用串口進行通信。如果需要對它們進行改動，那么由此付出的代價顯然是不值得的。在這一點上，尤其需要特別考慮ＰＰＰ軟件，因為在Ｌｉｎｕｘ下通過ＧＰＲＳ上網(wǎng)必須使用ＰＰＰ協(xié)議進行撥號。ＰＰＰ存在于用戶空間和內(nèi)核空間兩個地方，用戶空間的ｐｐｐｄ應(yīng)用程序完成撥號連接的管理功能；內(nèi)核空間的ｐｐｐ協(xié)議軟件實現(xiàn)ＰＰＰ包的組幀／分幀等核心功能。ＰＰＰ定義了自己的ｌｉｎｅ ｄｉｓｃｉｐｌｉｎｅ模塊，且到此為止，往下就不再有ＰＰＰ相關(guān)的軟件模塊（參看圖４的分層結(jié)構(gòu)）。第二，盡可能多地實現(xiàn)ＴＳ２７．０１０協(xié)議。雖然這個協(xié)議的內(nèi)容很豐富，但是由于Ｗａｖｅｃｏｍ通信模塊只支持有限的幾種格式，并且?guī)^部分還略有不同。這樣實現(xiàn)起來就存在許多困難，只能在保證實現(xiàn)Ｗａｖｅｃｏｍ復(fù)用協(xié)議并可靠工作的前提下，盡量實現(xiàn)ＴＳ２７．０１０協(xié)議，以便于以后硬件和軟件的升級。

４．２ ｍｕｘ ｄｒｉｖｅｒ的實現(xiàn)方案

正是基于以上兩點考慮，決定將這個協(xié)議的實現(xiàn)放在Ｌｉｎｅ ｄｉｓｃｉｐｌｉｎｅ和Ｌｏｗ－ｌｅｖｅｌ ｄｒｉｖｅｒ兩層之間，參看圖５。這樣，不需要對Ｌｉｎｕｘ的ＴＣＰ／ＩＰ協(xié)議棧軟件和ＰＰＰ軟件作任何修改，就可以在復(fù)用模式下實現(xiàn)原有的無線上網(wǎng)功能。

圖５給出了ＭＵＸ模塊的函數(shù)調(diào)用和數(shù)據(jù)流程。ＴＴＹ Ｌａｙｅｒ、ｌｉｎｅ ｄｉｓｃｉｐｌｉｎｅ和ｓｅｒｉａｌ ｄｒｉｖｅｒ是Ｌｉｎｕｘ ｔｔｙ設(shè)備文件系統(tǒng)在內(nèi)核中已有的三層，在前一節(jié)已經(jīng)介紹。

正如筆者在實現(xiàn)ＴＳ２７．０１０協(xié)議時所考慮的，為了不影響上層應(yīng)用程序，ＭＵＸ必須支持標準的Ｌｉｎｕｘ系統(tǒng)調(diào)用，如ｗｒｉｔｅ（）、ｒｅａｄ（）、ｉｏｃｔｌ（）等。ｗｒｉｔｅ（）如果成功，則返回發(fā)送的字節(jié)數(shù)；如果失敗則返回－１，并將ｅｒｒｎｏ（Ｌｉｎｕｘ系統(tǒng)下一個全局變量，用戶接口可以根據(jù)這個值判斷錯誤類型）置為合適的值。正如圖５所示，ｗｒｉｔｅ?穴?雪并不是將數(shù)據(jù)直接發(fā)送出去，要發(fā)送的數(shù)據(jù)首先按照ＴＳ２７．０１０協(xié)議的要求（筆者使用Ｗａｖｅｃｏｍ模塊，它有自己的協(xié)議要求）組成ＭＵＸ幀?熏然后根據(jù)數(shù)據(jù)的優(yōu)先級排隊，優(yōu)先級高的數(shù)據(jù)首先被發(fā)送。

同樣，對設(shè)備／ｄｅｖ／ｍｕｘＮ（０＜Ｎ＜Ｍ）的標準的Ｌｉｎｕｘ調(diào)用ｒｅａｄ（）也不是由ＭＵＸ直接支持的。ＭＵＸ不會知道一個用戶應(yīng)用程序何時讀設(shè)備／ｄｅｖ／ｍｕｘＮ（０＜Ｎ＜Ｍ）。ｒｅａｄ（）功能由ＭＵＸ的上層（主要是ＴＴＹ層）支持。ＭＵＸ根據(jù)ＴＳ２７．０１０協(xié)議（或者Ｗａｖｅｃｏｍ協(xié)議）將物理鏈路上接收到的ＭＵＸ包解封裝，然后將純數(shù)據(jù)發(fā)送到設(shè)備／ｄｅｖ／ｍｕｘＮ（０＜Ｎ＜Ｍ）的讀緩沖區(qū)中。如果設(shè)備／ｄｅｖ／ｍｕｘＮ（０＜Ｎ＜Ｍ）沒有足夠的讀緩沖空間，ＭＵＸ就會將數(shù)據(jù)放到自己的接收緩沖區(qū)中。

４．３ Ｗａｖｅｃｏｍ復(fù)用協(xié)議特殊情況的處理

在實現(xiàn)ＴＳ２７．０１０協(xié)議時，考慮到Ｗａｖｅｃｏｍ協(xié)議的特殊情況，在完全實現(xiàn)Ｗａｖｅｃｏｍ復(fù)用功能的同時，盡可能多地實現(xiàn)ＴＳ２７．０１０協(xié)議。由于Ｗａｖｅｃｏｍ只能同時支持兩個虛連接，所以這里的Ｍ＝２。其中，／ｄｅｖ／ｍｕｘ０用于ＡＴ命令，作為控制信息通道；／ｄｅｖ／ｍｕｘ１用于ＰＰＰ連接，作為數(shù)據(jù)通道。作為Ｗａｖｅｃｏｍ復(fù)用協(xié)議的一個嚴重缺陷，從圖２、圖３的幀結(jié)構(gòu)可以看到，從串行鏈路提交來的數(shù)據(jù)只能區(qū)分出是ＡＴ ｃｏｍｍａｎｄ數(shù)據(jù)還是ＤＡＴＡ數(shù)據(jù)，而無法確定鏈路的信息，即無法確定數(shù)據(jù)是ｍｕｘ０接收，還是ｍｕｘ１接收。為了解決這個問題，筆者在實現(xiàn)時，將底層提交的數(shù)據(jù)同時送給ｍｕｘ０和ｍｕｘ１（如果這兩個設(shè)備都已經(jīng)打開）。但是考慮到軟件的效率和數(shù)據(jù)的可靠性，在向上層提交數(shù)據(jù)時，有以下兩點例外：第一，ｍｕｘ１是ＰＰＰ專用的，在ＰＰＰ沒起來之前，ｍｕｘ１可以作為ＡＴ命令通道，但是ＰＰＰ連接成功后（ＰＰＰ的ｌｉｎｅ ｄｉｓｃｉｐｌｉｎｅ已經(jīng)替換掉了缺省的ＴＴＹ ｌｉｎｅ ｄｉｓｃｉｐｌｉｎｅ），它將不再接收ＡＴ命令，所以此時底層提交的ＡＴ命令幀不會送給ｍｕｘ１?鴉第二，ｍｕｘ０作為ＡＴ命令通道，將不接收ＰＰＰ數(shù)據(jù)，所以在ＰＰＰ連接成功后，不會把０ｘ７Ｅ開始和０ｘ７Ｅ結(jié)束（ＰＰＰ的幀同步標志字節(jié)）的ＤＡＴＡ幀發(fā)送到ｍｕｘ１。

ＧＰＲＳ網(wǎng)絡(luò)作為一種過渡性質(zhì)的２．５Ｇ網(wǎng)絡(luò)，覆蓋日益廣泛。由于它的速率高、實時性好、費用低廉等諸多優(yōu)勢，日益被手持／車載等移動終端設(shè)備采用。在使用ＧＰＲＳ網(wǎng)絡(luò)傳輸數(shù)據(jù)的同時，這些設(shè)備也必須能支持普通的無線業(yè)務(wù)，如語音、短消息等。ＴＳ ２７．０１０協(xié)議很好地解決了這些業(yè)務(wù)的復(fù)用問題。筆者開發(fā)的這套Ｌｉｎｕｘ上的ｍｕｌｔｉｐｌｅｘｉｎｇ軟件實現(xiàn)了這些功能，使得移動終端能夠在ＰＰＰ連接不斷開的情況下，可以打出／接聽電話、發(fā)送／接收短消息。