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

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

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

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

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

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

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

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

Ｍｕｌｔｉｐｌｅｘｅｒ?yàn)椋裕藕停停釉谝粋€(gè)起始／停止模式的、具有分幀功能的串行鏈路上傳輸數(shù)據(jù)流提供了一套機(jī)制。圖１給出了不同的協(xié)議層及其功能示意。Ｍｕｌｔｉｐｌｅｘｅｒ?qū)迂?fù)責(zé)將數(shù)據(jù)按字節(jié)流的方式傳輸，不再進(jìn)行進(jìn)一步的組幀；如果數(shù)據(jù)需要按一定結(jié)構(gòu)傳輸，就需要增加一個(gè)會(huì)聚層來完成這些功能。

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

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

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

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

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

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

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

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

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

２．１ ＡＴ命令包格式

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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