串行通信链路复用协议在嵌入系统上开发

随着移动通信技术的迅速发展，具备无线通信功能的移动终端也迅速发展起来。这些移动终端支持普通的话音、短消息等业务，随着ｇｐｒｓ网络覆盖的迅速扩大， 越来越多的手持／车载移动终端也开始支持ｇｐｒｓ上网业务。如何在一个终端设备上整合这些业务，这是许多移动终端设备开发者面对的问题。笔者在开发一款车 载移动终端过程中，采用了３ｇｐｐ的ｔｓ ２７．０１０协议，成功地整合了这些业务。

１ ｔｓ２７．０１０协议介绍

在常用的ｇｓｍ／ｇｐｒｓ通信模块中（如ｓｉｅｍｅｎｓ的ｍｃ３５mc35、ｗａｖｅｃｏｍ的ｑ２４００q2400等），只能通过一个普通９针的异 步串口与终端设备ｔｅ（ｔｅｒｍｉｎａｌ ｅｑｕｉｐｍｅｎｔ）进行通信。ｔｅ和ｍｓ?ｍｏｂｉｌｅ ｓｔａｔｉｏｎ　需要通过这个串口交换各种类型的数据，例如：语音、传真、数据、ｓｍｓ、ｃｂｓ、电话号码本的维护、电池状态、ｇｐｒｓ、ｕｓｓｄ等。如 何在一个串口上同时支持这么多的业务？例如，在数据通信过程中，怎样发送或接收ｓｍｓ？为了解决这些问题，３ｇｐｐ提出了一个协议--ｔｓ２７．０１０协 议（ｔｅｒｍｉｎａｌ ｅｑｕｉｐｍｅｎｔ ｔｏ ｍｏｂｉｌｅ ｓｔａｔｉｏｎ ｍｕｌｔｉｐｌｅｘｅｒ ｐｒｏｔｏｃｏｌ）。有了ｍｕｌｔｉｐｌｅｘｅｒ，即使在数据连接过程中，也可以发送ｓｍｓ。其它业务组合也可以同时进行。例如，数字语音和ｓｍｓ同时发 送。ｍｕｌｔｉｐｌｅｘｅｒ的存在使得一个完整的系统能够根据需要进行划分。

３ｇｐｐ 的ｍｕｌｔｉｐｌｅｘｅｒ设计非常灵活，并且独立于ｍｓ／ｔｅ平台，已有的应用程序不需要改动即可工作。在设计ｍｕｌｔｉｐｌｅｘｅｒ时，特别考虑到采用 电池供电的设备的需求，所以包含了省电模式控制等很重要的功能，并且ｍｕｌｔｉｐｌｅｘｅｒ本身在运行时也尽量使用最小的功耗和内存。

ｍｕｌｔｉｐｌｅｘｅｒ基于ｉｓｏ的ｈｄｌｃ标准设计，工作于有多种选项的单模式下。但是ｂａｓｉｃ ｏｐｔｉｏｎ并不遵从ｈｄｌｃ。在基本选项模式下，ｍｕｌｔｉｐｌｅｘｅｒ没有透明机制，也没有错误恢复功能。但是在高级选项（ａｄｖａｎｃｅｄ ｏｐｔｉｏｎ）模式下，使用ｈｄｌｃ的透明机制，且ｍｕｌｔｉｐｌｅｘｅｒ有一个方便的再同步机制，能够在ｄｃ１／ｄｃ３（ｘｏｎ／ｘｏｆｆ）流控打开的 链路上工作，且包含了错误恢复功能。

３ｇｐｐ的ｍｕｌｔｉｐｌｅｘｅｒ依赖于一个控制信道。在这个控制信道上，ｔｅ和ｍｓ交换控制信息，例如参数协商、节电控制信息、流控信息等。 ｍｕｌｔｉｐｌｅｘｅｒ是一个可选项，如果支持这个功能，就应使用ａｔ＋ｃｍｕｘ命令激活它。 ｍｕｌｔｉｐｌｅｘｅｒ为ｔｅ和ｍｓ在一个起始／停止模式的、具有分帧功能的串行链路上传输数据流提供了一套机制。图１给出了不同的协议层及其功能示意。 ｍｕｌｔｉｐｌｅｘｅｒ层负责将数据按字节流的方式传输，不再进行进一步的组帧；如果数据需要按一定结构传输，就需要增加一个会聚层来完成这些功能。

ｍｕｌｔｉｐｌｅｘｅｒ为ｔｅ上的进程和ｍｓ上相对应的进程提供了一条虚连接，这样ｔｅ和ｍｓ上的进程就可以通过这条虚连接通信。例如，ｔｅ上的 ｓｍｓ应用程序可以通过一条ｍｕｌｔｉｐｌｅｘｅｒ通道与ｍｓ上的ｓｍｓ处理程序连接起来。 ｔｓ２７．０１０规范使用８ｂｉｔ字符的ｓｔａｒｔ－ｓｔｏｐ传输模式，两个ｍｕｌｉｔｐｌｅｘｅｒ实体间的通信使用了规定的帧格式。ｔｅ和ｍｓ之间的每 个信道称为一条数据链路连接ｄｌｃ（ｄａｔａ ｌｉｎｋ ｃｏｎｎｅｃｔｉｏｎ），这些ｄｌｃ被依次独立地建立起来。每个ｄｌｃ都可以有自己的流控机制。

ｍｕｌｔｉｐｌｅｘｅｒ有三种工作模式：ｂａｓｉｃ、ａｄｖａｎｃｅｄ ｗｉｔｈｏｕｔ ｅｒｒｏｒ ｒｅｃｏｖｅｒｙ和ａｄｖａｎｃｅｄ ｗｉｔｈ ｅｒｒｏｒ ｒｅｃｏｖｅｒｙ。这三种模式特点如下：

·ｂａｓｉｃ：长度标识代替ｈｄｌｃ的透明机制；使用与ｈｄｌｃ不同的标志字；不能用于具有ｘｏｎ／ｘｏｆｆ流控的链路；从同步丢失状态中恢复需要更长的时间。

·ａｄｖａｎｃｅｄ ｗｉｔｈｏｕｔ ｅｒｒｏｒ ｒｅｃｏｖｅｒｙ：遵从ｉｓｏ／ｉｅｃ１３２３９的异步ｈｄｌｃ过程；可以用于具备ｘｏｎ／ｘｏｆｆ流控的链路上；可以更快地从失同步状态恢复。

·ａｄｖａｎｃｅｄ ｗｉｔｈ ｅｒｒｏｒ ｒｅｃｏｖｅｒｙ：使用了ｈｄｌｃ的错误恢复过程。

２ ｗａｖｅｃｏｍ ｇｓｍ／ｇｐｒｓ模块ｍｕｌｔｉｐｌｅｘｉｎｇ协议介绍 笔者选用了ｗａｖｅｃｏｍ的ｑ２４０３ａ，这是一款ｅ－ｇｓｍ／ｇｐｒｓ ９００／１８００的双频模块。这个模块支持大部分常用的ａｔ命令，但不支持标准的ｔｓ２７．０１０协议。为了能够数据／命令复用，ｗａｖｅｃｏｍ定义了自 己的ｍｕｌｔｉｐｌｅｘ协议。

ｗａｖｅｃｏｍ的复用协议允许一条串行链路上同时进行两个会话（即虚连接）：一个ａｔ命令的会话和一个数据通信的会话。ａｔ＋ｗｍｕｘ＝１将激活模块的复用模式。在这种模式下，ａｔ命令和数据都被封装成数据包。通过包头，可以区分是数据包还是ａｔ命令包。

２．１ ａｔ命令包格式

ａｔ命令包帧格式如图２所示。第一个字节?０ｘａａ　用于标识这是一个命令包，第二个字节是ａｔ命令长度的低八位。第三个字节由两部分组成：低３位 是ａｔ命令长度的高３位；高３位用于标识一个ａｔ命令。ａｔ命令的最大长度可以为２０４７字节。校验和（ｃｈｅｃｋｓｕｍ）是包中所有字节（包括头和ａｔ 命令）之和对２５６取模。

２．２ 数据包格式

数据包各个字段（除ｐａｃｋｅｔ ｔｙｐｅ外）意义与ａｔ命令包相同，其帧格式如图３所示。数据包有以下几种类型：

·ｔｙｐｅ＝０--ｄａｔａ 包：这个包是发送到无线链路上或者从无线链路上接收到的数据

·ｔｙｐｅ＝１--ｓｔａｔｕｓ包：这个包给出了ｓａ、ｓｂ、ｘ和中断条件编码的信息。

状态包的长度总为１字节。任何一个状态（除了ｂｒｅａｋ）改变时，所有的状态位都要发送出去。缺省情况下，所有的状态位都是关闭的（因此ｄｔｒ、ｒｔｓ都是关闭的），所以在打开复用开关准备传送数据之前，一定要发送一个状态包。

·ｔｙｐｅ＝２--ｒｅａｄｙ包：这个包表示发送ｒｅａｄｙ包的一方可以接收数据了。包中没有数据，所以长度字段为０。

·ｔｙｐｅ＝３--ｂｕｓｙ 包：这个包表示发送ｒｅａｄｙ包的一方忙，无法接收数据。包中没有数据。

３ ｌｉｎｕｘ下串口通信系统的组成

要在ｌｉｎｕｘ系统上实现ｔｓ２７．０１０协议，就必须了解ｌｉｎｕｘ下串口驱动软件模块的结构。

图４不但给出了ｌｉｎｕｘ ｋｅｒｎｅｌ中串口通信模块的组成结构，还形象地表示出了数据是如何在用户和硬件接口之间流动的（笔者使用ｌｉｎｕｘ ２．４．１９的内核）。从图４可以看到串口通信模块可在逻辑上分为三层：ｔｔｙ层、ｌｉｎｅ ｄｉｓｃｉｐｌｉｎｅ层和底层驱动层。ｔｔｙ层是用户空间和内核空间的桥梁，用户程序和内核需要通过ｔｔｙ层交换数据；ｌｏｗ－ｌｅｖｅｌ ｄｒｉｖｅｒ则负责硬件的交互，它对硬件进行控制和读写操作；ｌｉｎｅ ｄｉｓｃｉｐｌｉｎｅ层是整个串行通信模块中最灵活、设计最巧妙的一层，它要为一个串行口的使用定下数据交互的"规程"，在ｌｉｎｕｘ内核中已经存在了许 多ｌｉｎｅ ｄｉｓｃｉｐｌｉｎｅ，例如ｐｐｐ、ｓｌｉｐ、ｔｔｙ等。缺省使用ｔｔｙ ｌｉｎｅ ｄｉｓｃｉｐｌｉｎｅ。可以根据需要将ｌｉｎｅ ｄｉｓｃｉｐｌｉｎｅ替换成ｌｉｎｕｘ已经定义的ｌｉｎｅ ｄｉｓｃｉｐｌｉｎｅ结构，甚至替换为自己的ｌｉｎｅ ｄｉｓｃｉｐｌｉｎｅ结构。 在图４中，向硬件接口写数据的过程是显而易见的。但是，用户程序从硬件读取数据的过程却要复杂一些，这是因为硬件与用户空间之间没有直接的联系。解决的办 法就是使用缓冲技术，硬件接收数据存储于ｋｅｒｎｅｌ ｂｕｆｆｅｒ中，等待用户程序请求这些数据；如果用户程序请求数据时，这个ｂｕｆｆｅｒ是空的，那么用户程序就会被挂起，直到ｂｕｆｆｅｒ中有数据时，它 才被唤醒。实际上，ｔｔｙ相关的缓冲是由两级构成的：一个"常规"ｂｕｆｆｅｒ（数据等待着ｌｉｎｅ ｄｉｓｃｐｌｉｎｅ取走，缺省情况下传到用户空间）和一个"ｆｌｉｐ"ｂｕｆｆｅｒ（硬件驱动函数将底层进来的数据尽可能快地存入这个缓冲，而不必考虑并 发存取问题，因为这个ｂｕｆｆｅｒ是每个硬件驱动专有的）。ｆｌｉｐ ｂｕｆｆｅｒ由两个物理的缓冲实现，并被交替地写入，这样中断处理函数就会总有一个缓冲可用。

ｌｉｎｕｘ下串口软件的这种分层结构虽然增加了复杂性，但是它带来的好处是多方面的。第一，串口模块更加灵活，在为新的串口硬件编写驱动程序时，只 需修改和增加最底层的软件即可；第二，上层应用程序可以根据需要改变ｌｉｎｅ ｄｉｓｃｉｐｌｉｎｅ的处理软件，在使用ｐｐｐ、ｓｌｉｐ等协议进行拨号连接时，都需要将原有的ｌｉｎｅ ｄｉｓｃｉｐｌｉｎｅ替换为ｐｐｐ或者ｓｌｉｐ协议本身的ｌｉｎｅ ｄｉｓｃｉｐｌｉｎｅ?第三，可以根据需要，在层与层之间加入一层自己的处理软件。事实上，笔者在实现ｍｕｌｔｉｐｌｅｘ协议时正是这样做的。

４ ｍｕｌｔｉｐｌｅｘｉｎｇ协议的实现

４．１ 协议实现时的考虑

在实现ｔｓ２７．０１０协议时，基于以下考虑：第一，使用串口的上层应用程序不需要改动。这一点很重要，因为系统中有许多用户程序使用串口进行通 信。如果需要对它们进行改动，那么由此付出的代价显然是不值得的。在这一点上，尤其需要特别考虑ｐｐｐ软件，因为在ｌｉｎｕｘ下通过ｇｐｒｓ上网必须使用 ｐｐｐ协议进行拨号。ｐｐｐ存在于用户空间和内核空间两个地方，用户空间的ｐｐｐｄ应用程序完成拨号连接的管理功能；内核空间的ｐｐｐ协议软件实现ｐｐｐ 包的组帧／分帧等核心功能。ｐｐｐ定义了自己的ｌｉｎｅ ｄｉｓｃｉｐｌｉｎｅ模块，且到此为止，往下就不再有ｐｐｐ相关的软件模块（参看图４的分层结构）。第二，尽可能多地实现ｔｓ２７．０１０协议。虽然这个 协议的内容很丰富，但是由于ｗａｖｅｃｏｍ通信模块只支持有限的几种格式，并且帧头部分还略有不同。这样实现起来就存在许多困难，只能在保证实现 ｗａｖｅｃｏｍ复用协议并可靠工作的前提下，尽量实现ｔｓ２７．０１０协议，以便于以后硬件和软件的升级。

４．２ ｍｕｘ ｄｒｉｖｅｒ的实现方案

正是基于以上两点考虑，决定将这个协议的实现放在ｌｉｎｅ ｄｉｓｃｉｐｌｉｎｅ和ｌｏｗ－ｌｅｖｅｌ ｄｒｉｖｅｒ两层之间，参看图５。这样，不需要对ｌｉｎｕｘ的ｔｃｐ／ｉｐ协议栈软件和ｐｐｐ软件作任何修改，就可以在复用模式下实现原有的无线上网功能。

图５给出了ｍｕｘ模块的函数调用和数据流程。ｔｔｙ ｌａｙｅｒ、ｌｉｎｅ ｄｉｓｃｉｐｌｉｎｅ和ｓｅｒｉａｌ ｄｒｉｖｅｒ是ｌｉｎｕｘ ｔｔｙ设备文件系统在内核中已有的三层，在前一节已经介绍。

正如笔者在实现ｔｓ２７．０１０协议时所考虑的，为了不影响上层应用程序，ｍｕｘ必须支持标准的ｌｉｎｕｘ系统调用，如ｗｒｉｔｅ（）、 ｒｅａｄ（）、ｉｏｃｔｌ（）等。ｗｒｉｔｅ（）如果成功，则返回发送的字节数；如果失败则返回－１，并将ｅｒｒｎｏ（ｌｉｎｕｘ系统下一个全局变量，用 户接口可以根据这个值判断错误类型）置为合适的值。正如图５所示，ｗｒｉｔｅ（）并不是将数据直接发送出去，要发送的数据首先按照ｔｓ２７．０１０协议的 要求（笔者使用ｗａｖｅｃｏｍ模块，它有自己的协议要求）组成ｍｕｘ帧?然后根据数据的优先级排队，优先级高的数据首先被发送。 同样，对设备／ｄｅｖ／ｍｕｘｎ（０＜ｎ＜ｍ＝的标准的ｌｉｎｕｘ调用ｒｅａｄ（）也不是由ｍｕｘ直接支持的。ｍｕｘ不会知道一个用户应用程序何时读设备 ／ｄｅｖ／ｍｕｘｎ（０＜ｎ＜ｍ＝。ｒｅａｄ（）功能由ｍｕｘ的上层（主要是ｔｔｙ层）支持。ｍｕｘ根据ｔｓ２７．０１０协议（或者ｗａｖｅｃｏｍ协议） 将物理链路上接收到的ｍｕｘ包解封装，然后将纯数据发送到设备／ｄｅｖ／ｍｕｘｎ（０＜ｎ＜ｍ＝的读缓冲区中。如果设备／ｄｅｖ／ｍｕｘｎ（０＜ｎ＜ｍ） 没有足够的读缓冲空间，ｍｕｘ就会将数据放到自己的接收缓冲区中。 ４．３ ｗａｖｅｃｏｍ复用协议特殊情况的处理

在实现ｔｓ２７．０１０协议时，考虑到ｗａｖｅｃｏｍ协议的特殊情况，在完全实现ｗａｖｅｃｏｍ复用功能的同时，尽可能多地实现ｔｓ２７．０１０协 议。由于ｗａｖｅｃｏｍ只能同时支持两个虚连接，所以这里的ｍ＝２。其中，／ｄｅｖ／ｍｕｘ０用于ａｔ命令，作为控制信息通道；／ｄｅｖ／ｍｕｘ１用于 ｐｐｐ连接，作为数据通道。作为ｗａｖｅｃｏｍ复用协议的一个严重缺陷，从图２、图３的帧结构可以看到，从串行链路提交来的数据只能区分出是ａｔ ｃｏｍｍａｎｄ数据还是ｄａｔａ数据，而无法确定链路的信息，即无法确定数据是ｍｕｘ０接收，还是ｍｕｘ１接收。为了解决这个问题，笔者在实现时，将底层 提交的数据同时送给ｍｕｘ０和ｍｕｘ１?如果这两个设备都已经打开　。但是考虑到软件的效率和数据的可靠性，在向上层提交数据时，有以下两点例外：第 一，ｍｕｘ１是ｐｐｐ专用的，在ｐｐｐ没起来之前，ｍｕｘ１可以作为ａｔ命令通道，但是ｐｐｐ连接成功后（ｐｐｐ的ｌｉｎｅ ｄｉｓｃｉｐｌｉｎｅ已经替换掉了缺省的ｔｔｙ ｌｉｎｅ ｄｉｓｃｉｐｌｉｎｅ），它将不再接收ａｔ命令，所以此时底层提交的ａｔ命令帧不会送给ｍｕｘ１?第二，ｍｕｘ０作为ａｔ命令通道，将不接收ｐｐｐ数据， 所以在ｐｐｐ连接成功后，不会把０ｘ７ｅ开始和０ｘ７ｅ结束?ｐｐｐ的帧同步标志字节　的ｄａｔａ帧发送到ｍｕｘ１。

ｇｐｒｓ网络作为一种过渡性质的２．５ｇ网络，覆盖日益广泛。由于它的速率高、实时性好、费用低廉等诸多优势，日益被手持／车载等移动终端设备采 用。在使用ｇｐｒｓ网络传输数据的同时，这些设备也必须能支持普通的无线业务，如语音、短消息等。ｔｓ ２７．０１０协议很好地解决了这些业务的复用问题。笔者开发的这套ｌｉｎｕｘ上的ｍｕｌｔｉｐｌｅｘｉｎｇ软件实现了这些功能，使得移动终端能够在ｐｐｐ 连接不断开的情况下，可以打出／接听电话、发送／接收短消息。