關鍵詞：TS27.010 串行鏈路復用 GPRS移動終端 嵌入式Linux

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

圖1 TS27.010協議棧組成與示意圖

１ ＴＳ２７．０１０協議介紹

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

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

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

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

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

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

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

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

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

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

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

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

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

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

２．１ ＡＴ命令包格式

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

圖4 Linux下串行通信數據流和函數調用示意圖

    ２．２ 數據包格式

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

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

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

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

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

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

３ Ｌｉｎｕｘ下串口通信系統的組成

要在Ｌｉｎｕｘ系統上實現ＴＳ２７．０１０協議，就必須了解Ｌｉｎｕｘ下串口驅動軟件模塊的結構。

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

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

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

圖5 MUX系統組成

４ Ｍｕｌｔｉｐｌｅｘｉｎｇ協議的實現

４．１ 協議實現時的考慮

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

４．２ ｍｕｘ ｄｒｉｖｅｒ的實現方案

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

圖５給出了ＭＵＸ模塊的函數調用和數據流程。ＴＴＹ Ｌａｙｅｒ、ｌｉｎｅ ｄｉｓｃｉｐｌｉｎｅ和ｓｅｒｉａｌ ｄｒｉｖｅｒ是Ｌｉｎｕｘ ｔｔｙ設備文件系統在內核中已有的三層，在前一節已經介紹。

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

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

４．３ Ｗａｖｅｃｏｍ復用協議特殊情況的處理

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

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