資料終端裝置與無線通信子產品之間串行通信鍊路複用協定（TS27.010）在嵌入式系統上的開發【轉】1. ＴＳ２７．０１０協定介紹 2. Ｗａｖｅｃｏｍ ＧＳＭ／ＧＰＲＳ子產品Ｍｕｌｔｉｐｌｅｘｉｎｇ協定介紹 3. Ｌｉｎｕｘ下序列槽通信系統的組成 4. Ｍｕｌｔｉｐｌｅｘｉｎｇ協定的實作

<a href="http://blog.csdn.net/hellolwl/article/details/6164449#t0">協定介紹</a>

<a href="http://blog.csdn.net/hellolwl/article/details/6164449#t1">子產品協定介紹</a>

<a href="http://blog.csdn.net/hellolwl/article/details/6164449#t2">1            指令包格式</a>

<a href="http://blog.csdn.net/hellolwl/article/details/6164449#t3">2            資料包格式</a>

<a href="http://blog.csdn.net/hellolwl/article/details/6164449#t4">下序列槽通信系統的組成</a>

<a href="http://blog.csdn.net/hellolwl/article/details/6164449#t5">協定的實作</a>

<a href="http://blog.csdn.net/hellolwl/article/details/6164449#t6">1            協定實作時的考慮</a>

<a href="http://blog.csdn.net/hellolwl/article/details/6164449#t7">2            的實作方案</a>

<a href="http://blog.csdn.net/hellolwl/article/details/6164449#t8">3            複用協定特殊情況的處理</a>

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

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

在常用的ＧＳＭ／ＧＰＲＳ通信子產品中（如Ｓｉｅｍｅｎｓ的ＭＣ３５、ＷａｖｅＣｏｍ的 Ｑ２４００等），隻能通過一個普通９針的異步序列槽

與終端裝置ＴＥ（Ｔｅｒｍｉｎａｌ Ｅｑｕｉｐｍｅｎｔ）進行通信。ＴＥ和ＭＳ

?穴Ｍｏｂｉｌｅ Ｓｔａｔｉｏｎ

?雪需要通過這個序列槽交換各種類型的資料

，例如：語音、傳真、資料、ＳＭＳ、ＣＢＳ、電話号碼本的維護、電池狀态、ＧＰＲＳ、ＵＳＳＤ等。 如何在一個序列槽上同時支援這麼多的業務？例如，在資料通信過程中，怎樣發送或接收ＳＭＳ？為了解決這些問題，３ＧＰＰ提出了一個協定

——ＴＳ２７．０１０

協定（Ｔｅｒｍｉｎａｌ Ｅｑｕｉｐｍｅｎｔ ｔｏ Ｍｏｂｉｌｅ Ｓｔａｔｉｏｎ Ｍｕｌｔｉｐｌｅｘｅｒ

Ｐｒｏｔｏｃｏｌ）。有了Ｍｕｌｔｉｐｌｅｘｅｒ，即使在資料連接配接過程中，也可以發送ＳＭＳ。其它業務組合也可以同時進行。例如，數字語音和ＳＭＳ同時發

送。Ｍｕｌｔｉｐｌｅｘｅｒ的存在使得一個完整的系統能夠根據需要進行劃分。

３ＧＰＰ

的Ｍｕｌｔｉｐｌｅｘｅｒ設計非常靈活，并且獨立于ＭＳ／ＴＥ平台，已有的應用程式不需要改動即可工作。在設計Ｍｕｌｔｉｐｌｅｘｅｒ時，特别考慮到采用

電池供電的裝置的需求，是以包含了省電模式控制等很重要的功能，并且Ｍｕｌｔｉｐｌｅｘｅｒ本身在運作時也盡量使用最小的功耗和記憶體。

Ｍｕｌｔｉｐｌｅｘｅｒ 基于ＩＳＯ的ＨＤＬＣ标準設計

，

工作于有多種選項的單模式下。但是Ｂａｓｉｃ

Ｏｐｔｉｏｎ并不遵從ＨＤＬＣ。在基本選項模式下，Ｍｕｌｔｉｐｌｅｘｅｒ沒有透明機制，也沒有錯誤恢複功能。但是在進階選項（Ａｄｖａｎｃｅｄ

Ｏｐｔｉｏｎ）模式下，使用ＨＤＬＣ的透明機制，且Ｍｕｌｔｉｐｌｅｘｅｒ有一個友善的再同步機制，能夠在ＤＣ１／ＤＣ３（ＸＯＮ／ＸＯＦＦ）流控打開的

鍊路上工作，且包含了錯誤恢複功能。

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

Ｍｕｌｔｉｐｌｅｘｅｒ為ＴＥ和ＭＳ在一個起始／停止模式的、具有分幀功能的串行鍊路上傳 輸資料流提供了一套機制。圖１給出了不同的協定層及其功能示意。Ｍｕｌｔｉｐｌｅｘｅｒ層負責将資料按位元組流的方式傳輸

，不再進行進一步的組幀；如果資料 需要按一定結構傳輸，就需要增加一個會聚層來完成這些功能。

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

ＴＳ２７．０１０規範使用８ｂｉｔ字元的ｓｔａｒｔ－ｓｔｏｐ傳輸模式，兩個 Ｍｕｌｉｔｐｌｅｘｅｒ實體間的通信使用了規定的幀格式。ＴＥ和ＭＳ之間的每個信道稱為一條資料鍊路連接配接ＤＬＣ（Ｄａｔａ Ｌｉｎｋ Ｃｏｎｎｅｃｔｉｏｎ）

，這些ＤＬＣ被依次獨立地建立起來。每個ＤＬＣ都可以有自己的流控機制。

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

。這三種模式特點如下：

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

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

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

筆者選用了Ｗａｖｅｃｏｍ的Ｑ２４０３Ａ，這是一款Ｅ－ＧＳＭ／ＧＰＲＳ ９００／１８００的雙頻子產品。這個子產品支援大部分常用的ＡＴ指令，但不支援标準的ＴＳ２７．０１０協定。為了能夠資料／指令複用，Ｗａｖｅｃｏｍ定義了自己的ｍｕｌｔｉｐｌｅｘ協定。

Ｗａｖｅｃｏｍ的複用協定允許一條串行鍊路上同時進行兩個會話（即虛連接配接）：一個ＡＴ指令的會話和一個資料通信的會話。ＡＴ＋ＷＭＵＸ＝１将激活子產品的複用模式。在這種模式下，ＡＴ指令和資料都被封裝成資料包。通過標頭，可以區分是資料包還是ＡＴ指令包。

ＡＴ指令包幀格式如圖２所示。第一個位元組（０ｘＡＡ）用于辨別這是一個指令包，第二個位元組 是ＡＴ指令長度的低八位。第三個位元組由兩部分組成：低３位是ＡＴ指令長度的高３位；高３位用于辨別一個ＡＴ指令。ＡＴ指令的最大長度可以為２０４７位元組。 校驗和

?穴ｃｈｅｃｋｓｕｍ

?雪是包中所有位元組（包括頭和ＡＴ指令）之和對２５６取模。

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

·Ｔｙｐｅ＝０

——ＤＡＴＡ 包：這個包是發送到無線鍊路上或者從無線鍊路上接收到的資料

·Ｔｙｐｅ＝１

——ＳＴＡＴＵＳ包：這個包給出了ＳＡ、ＳＢ、Ｘ和中斷條件編碼的資訊。

狀态包的長度總為１位元組。任何一個狀态（除了ｂｒｅａｋ）改變時，所有的狀态位都要發送出去。預設情況下，所有的狀态位都是關閉的（是以ＤＴＲ、ＲＴＳ都是關閉的），是以在打開複用開關準備傳送資料之前，一定要發送一個狀态包。

·Ｔｙｐｅ＝２

——ＲＥＡＤＹ包：這個包表示發送ＲＥＡＤＹ包的一方可以接收資料了。包中沒有資料，是以長度字段為０。

·Ｔｙｐｅ＝３

——ＢＵＳＹ 包：這個包表示發送ＲＥＡＤＹ包的一方忙，無法接收資料。包中沒有資料。

要在Ｌｉｎｕｘ系統上實作ＴＳ２７．０１０協定，就必須了解Ｌｉｎｕｘ下序列槽驅動軟體子產品的結構。

圖４不但給出了

Ｌｉｎｕｘ ｋｅｒｎｅｌ中序列槽通信子產品的組成結構，還形象地表示出了資料是如何在使用者和硬體接口之間流動的（筆者使用Ｌｉｎｕｘ

２．４．１９的核心）。從圖４可以看到序列槽通信子產品可在邏輯上分為三層：ＴＴＹ層、ｌｉｎｅ

ｄｉｓｃｉｐｌｉｎｅ層和底層驅動層。ＴＴＹ層是使用者空間和核心空間的橋梁，使用者程式和核心需要通過ｔｔｙ層交換資料；Ｌｏｗ－ｌｅｖｅｌ

ｄｒｉｖｅｒ則負責硬體的互動，它對硬體進行控制和讀寫操作；ｌｉｎｅ

ｄｉｓｃｉｐｌｉｎｅ層是整個串行通信子產品中最靈活、設計最巧妙的一層，它要為一個串行口的使用定下資料互動的

“規程

”，

在Ｌｉｎｕｘ核心中已經存在了許 多ｌｉｎｅ ｄｉｓｃｉｐｌｉｎｅ，例如ＰＰＰ、ＳＬＩＰ、ＴＴＹ等。預設使用ＴＴＹ ｌｉｎｅ

ｄｉｓｃｉｐｌｉｎｅ。可以根據需要将ｌｉｎｅ ｄｉｓｃｉｐｌｉｎｅ替換成Ｌｉｎｕｘ已經定義的ｌｉｎｅ

ｄｉｓｃｉｐｌｉｎｅ結構，甚至替換為自己的ｌｉｎｅ ｄｉｓｃｉｐｌｉｎｅ結構。

在圖４中，向硬

件接口寫資料的過程是顯而易見的。但是，使用者程式從硬體讀取資料的過程卻要

複雜一些，這是因為硬體與使用者空間之間沒有直接的聯系。解決的辦法就是使用緩沖技術，硬體接收資料存儲于ｋｅｒｎｅｌ

ｂｕｆｆｅｒ中，等待使用者程式請求這些資料；如果使用者程式請求資料時，這個ｂｕｆｆｅｒ是空的，那麼使用者程式就會被挂起，直到ｂｕｆｆｅｒ中有資料時，它

才被喚醒。實際上，ＴＴＹ相關的緩沖是由兩級構成的：一個

“正常

”ｂｕｆｆｅｒ（資料等待着ｌｉｎｅ ｄｉｓｃｐｌｉｎｅ取走，預設情況下傳到使用者空間）和一個

“ｆｌｉｐ

”ｂｕｆｆｅｒ（硬體驅動函數将底層進來的資料盡可能快地存入這個緩沖，而不必考慮并 發存取問題，因為這個ｂｕｆｆｅｒ是每個硬體驅動專有的）。ｆｌｉｐ ｂｕｆｆｅｒ由兩個實體的緩沖實作，并被交替地寫入，這樣中斷處理函數就會總有一個緩沖可用。

Ｌｉｎｕｘ下串

口軟體的這種分層結構雖然增加了複雜性，但是它帶來的好處是多方面的。第

一，序列槽子產品更加靈活，在為新的序列槽硬體編寫驅動程式時，隻需修改和增加最底層的軟體即可；第二，上層應用程式可以根據需要改變ｌｉｎｅ

ｄｉｓｃｉｐｌｉｎｅ的處理軟體，在使用ＰＰＰ、ＳＬＩＰ等協定進行撥接上網時，都需要将原有的ｌｉｎｅ

ｄｉｓｃｉｐｌｉｎｅ替換為ＰＰＰ或者ＳＬＩＰ協定本身的ｌｉｎｅ ｄｉｓｃｉｐｌｉｎｅ

?鴉第三，可以根據需要，在層與層之間加入一層自己的處理軟體。事實上，筆者在實作Ｍｕｌｔｉｐｌｅｘ協定時正是這樣做的。

在實作

ＴＳ２７．０１０協定時，基于以下考慮：第一，使用序列槽的上層應用程式不需要改動。

這一點很重要，因為系統中有許多使用者程式使用序列槽進行通信。如果需要對它們進行改動，那麼由此付出的代價顯然是不值得的。在這一點上，尤其需要特别考慮

ＰＰＰ軟體，因為在Ｌｉｎｕｘ下通過ＧＰＲＳ上網必須使用ＰＰＰ協定進行撥号。ＰＰＰ存在于使用者空間和核心空間兩個地方，使用者空間的ｐｐｐｄ應用程式完成

撥接上網的管理功能；核心空間的ｐｐｐ協定軟體實作ＰＰＰ包的組幀／分幀等核心功能。ＰＰＰ定義了自己的ｌｉｎｅ

ｄｉｓｃｉｐｌｉｎｅ子產品，且到此為止，往下就不再有ＰＰＰ相關的軟體子產品（參看圖４的分層結構）。第二，盡可能多地實作ＴＳ２７．０１０協定。雖然這個

協定的内容很豐富，但是由于Ｗａｖｅｃｏｍ通信子產品隻支援有限的幾種格式，并且幀頭部分還略有不同。這樣實作起來就存在許多困難，隻能在保證實作

Ｗａｖｅｃｏｍ複用協定并可靠工作的前提下，盡量實作ＴＳ２７．０１０協定，以便于以後硬體和軟體的更新。

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

圖５給出了ＭＵＸ子產品的函數調用和資料流程。ＴＴＹ Ｌａｙｅｒ、ｌｉｎｅ ｄｉｓｃｉｐｌｉｎｅ和ｓｅｒｉａｌ ｄｒｉｖｅｒ是Ｌｉｎｕｘ ｔｔｙ裝置檔案系統在核心中已有的三層，在前一節已經介紹。

正如筆者在實作

ＴＳ２７．０１０協定時所考慮的，為了不影響上層應用程式，ＭＵＸ必須支援

标準的Ｌｉｎｕｘ系統調用，如ｗｒｉｔｅ（）、ｒｅａｄ（）、ｉｏｃｔｌ（）等。ｗｒｉｔｅ（）如果成功，則傳回發送的位元組數；如果失敗則傳回－１，并将

ｅｒｒｎｏ（Ｌｉｎｕｘ系統下一個全局變量，使用者接口可以根據這個值判斷錯誤類型）置為合适的值。正如圖５所示，ｗｒｉｔｅ

?穴

?雪并不是将資料直接發送 出去，要發送的資料首先按照ＴＳ２７．０１０協定的要求（筆者使用Ｗａｖｅｃｏｍ子產品，它有自己的協定要求）組成ＭＵＸ幀

?熏然後根據資料的優先級排隊， 優先級高的資料首先被發送。

同樣，對裝置

／ｄｅｖ／ｍｕｘＮ（０＜Ｎ＜Ｍ）的标準的Ｌｉｎｕｘ調用ｒｅａｄ（）也不是

由ＭＵＸ直接支援的。ＭＵＸ不會知道一個使用者應用程式何時讀裝置／ｄｅｖ／ｍｕｘＮ（０＜Ｎ＜Ｍ）。ｒｅａｄ（）功能由ＭＵＸ的上層（主要是ＴＴＹ層）支

持。ＭＵＸ根據ＴＳ２７．０１０協定（或者Ｗａｖｅｃｏｍ協定）将實體鍊路上接收到的ＭＵＸ包解封裝，然後将純資料發送到裝置／ｄｅｖ／ｍｕｘＮ（０＜Ｎ

＜Ｍ）的讀緩沖區中。如果裝置／ｄｅｖ／ｍｕｘＮ（０＜Ｎ＜Ｍ）沒有足夠的讀緩沖空間，ＭＵＸ就會将資料放到自己的接收緩沖區中。

ＴＳ２７．０１０協定時，考慮到Ｗａｖｅｃｏｍ協定的特殊情況，在完全實作

Ｗａｖｅｃｏｍ複用功能的同時，盡可能多地實作ＴＳ２７．０１０協定。由于Ｗａｖｅｃｏｍ隻能同時支援兩個虛連接配接，是以這裡的Ｍ＝２。其中，

／ｄｅｖ／ｍｕｘ０用于ＡＴ指令，作為控制資訊通道；／ｄｅｖ／ｍｕｘ１用于ＰＰＰ連接配接，作為資料通道。作為Ｗａｖｅｃｏｍ複用協定的一個嚴重缺陷，從圖

２、圖３的幀結構可以看到，從串行鍊路送出來的資料隻能區分出是ＡＴ

ｃｏｍｍａｎｄ資料還是ＤＡＴＡ資料，而無法确定鍊路的資訊，即無法确定資料是ｍｕｘ０接收，還是ｍｕｘ１接收。為了解決這個問題，筆者在實作時，将底層

送出的資料同時送給ｍｕｘ０和ｍｕｘ１（如果這兩個裝置都已經打開）。但是考慮到軟體的效率和資料的可靠性，在向上層送出資料時，有以下兩點例外：第一，

ｍｕｘ１是ＰＰＰ專用的，在ＰＰＰ沒起來之前，ｍｕｘ１可以作為ＡＴ指令通道，但是ＰＰＰ連接配接成功後（ＰＰＰ的ｌｉｎｅ

ｄｉｓｃｉｐｌｉｎｅ已經替換掉了預設的ＴＴＹ ｌｉｎｅ

ｄｉｓｃｉｐｌｉｎｅ），它将不再接收ＡＴ指令，是以此時底層送出的ＡＴ指令幀不會送給ｍｕｘ１

?鴉第二，ｍｕｘ０作為ＡＴ指令通道，将不接收ＰＰＰ數 據，是以在ＰＰＰ連接配接成功後，不會把０ｘ７Ｅ開始和０ｘ７Ｅ結束（ＰＰＰ的幀同步标志位元組）的ＤＡＴＡ幀發送到ｍｕｘ１。

ＧＰＲＳ網絡作

為一種過渡性質的２．５Ｇ網絡，覆寫日益廣泛。由于它的速率高、實時性好、

費用低廉等諸多優勢，日益被手持／車載等移動終端裝置采用。在使用ＧＰＲＳ網絡傳輸資料的同時，這些裝置也必須能支援普通的無線業務，如語音、短消息等。

ＴＳ

２７．０１０協定很好地解決了這些業務的複用問題。筆者開發的這套Ｌｉｎｕｘ上的ｍｕｌｔｉｐｌｅｘｉｎｇ軟體實作了這些功能，使得移動終端能夠在ＰＰＰ

連接配接不斷開的情況下，可以打出／接聽電話、發送／接收短消息。

【新浪微網誌】 張昺華--sky

【twitter】 @sky2030_

【facebook】 張昺華 zhangbinghua

本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接配接，否則保留追究法律責任的權利.