数据终端设备与无线通信模块之间串行通信链路复用协议（TS27.010

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

·Ｔｙｐｅ＝０——ＤＡＴＡ 包：这个包是发送到无线链路上或者从无线链路上接收到的数据

·Ｔｙｐｅ＝１——ＳＴＡＴＵＳ包：这个包给出了ＳＡ、ＳＢ、Ｘ和中断条件编码的信息。

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

·Ｔｙｐｅ＝２——ＲＥＡＤＹ包：这个包表示发送ＲＥＡＤＹ包的一方可以接收数据了。包中没有数据，所以长度字段为０。

·Ｔｙｐｅ＝３——ＢＵＳＹ 包：这个包表示发送ＲＥＡＤＹ包的一方忙，无法接收数据。包中没有数据。

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

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

图４不但给出了Ｌｉｎｕｘ ｋｅｒｎｅｌ中串口通信模块的组成结构，还形象地表示出了数据是如何在用户和硬件接口之间流动的（笔者使用Ｌｉｎｕｘ ２．４．１９的内核）。从图４可以看到串口通信模块可在逻辑上分为三层：ＴＴＹ层、ｌｉｎｅ ｄｉｓｃｉｐｌｉｎｅ层和底层驱动层。ＴＴＹ层是用户空间和内核空间的桥梁，用户程序和内核需要通过ｔｔｙ层交换数据；Ｌｏｗ－ｌｅｖｅｌ ｄｒｉｖｅｒ则负责硬件的交互，它对硬件进行控制和读写操作；ｌｉｎｅ ｄｉｓｃｉｐｌｉｎｅ层是整个串行通信模块中最灵活、设计最巧妙的一层，它要为一个串行口的使用定下数据交互的“规程”，在Ｌｉｎｕｘ内核中已经存在了许多ｌｉｎｅ ｄｉｓｃｉｐｌｉｎｅ，例如ＰＰＰ、ＳＬＩＰ、ＴＴＹ等。缺省使用ＴＴＹ ｌｉｎｅ ｄｉｓｃｉｐｌｉｎｅ。可以根据需要将ｌｉｎｅ ｄｉｓｃｉｐｌｉｎｅ替换成Ｌｉｎｕｘ已经定义的ｌｉｎｅ ｄｉｓｃｉｐｌｉｎｅ结构，甚至替换为自己的ｌｉｎｅ ｄｉｓｃｉｐｌｉｎｅ结构。

在图４中，向硬件接口写数据的过程是显而易见的。但是，用户程序从硬件读取数据的过程却要复杂一些，这是因为硬件与用户空间之间没有直接的联系。解决的办法就是使用缓冲技术，硬件接收数据存储于ｋｅｒｎｅｌ ｂｕｆｆｅｒ中，等待用户程序请求这些数据；如果用户程序请求数据时，这个ｂｕｆｆｅｒ是空的，那么用户程序就会被挂起，直到ｂｕｆｆｅｒ中有数据时，它才被唤醒。实际上，ＴＴＹ相关的缓冲是由两级构成的：一个“常规”ｂｕｆｆｅｒ（数据等待着ｌｉｎｅ ｄｉｓｃｐｌｉｎｅ取走，缺省情况下传到用户空间）和一个“ｆｌｉｐ”ｂｕｆｆｅｒ（硬件驱动函数将底层进来的数据尽可能快地存入这个缓冲，而不必考虑并发存取问题，因为这个ｂｕｆｆｅｒ是每个硬件驱动专有的）。ｆｌｉｐ ｂｕｆｆｅｒ由两个物理的缓冲实现，并被交替地写入，这样中断处理函数就会总有一个缓冲可用。

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

图5 MUX系统组成

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

４．１ 协议实现时的考虑

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

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

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

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

正如笔者在实现ＴＳ２７．０１０协议时所考虑的，为了不影响上层应用程序，ＭＵＸ必须支持标准的Ｌｉｎｕｘ系统调用，如ｗｒｉｔｅ（）、ｒｅａｄ（）、ｉｏｃｔｌ（）等。ｗｒｉｔｅ（）如果成功，则返回发送的字节数；如果失败则返回－１，并将ｅｒｒｎｏ（Ｌｉｎｕｘ系统下一个全局变量，用户接口可以根据这个值判断错误类型）置为合适的值。正如图５所示，ｗｒｉｔｅ?穴?雪并不是将数据直接发送出去，要发送的数据首先按照ＴＳ２７．０１０协议的要求（笔者使用Ｗａｖｅｃｏｍ模块，它有自己的协议要求）组成ＭＵＸ帧?熏然后根据数据的优先级排队，优先级高的数据首先被发送。

同样，对设备／ｄｅｖ／ｍｕｘＮ（０＜Ｎ＜Ｍ）的标准的Ｌｉｎｕｘ调用ｒｅａｄ（）也不是由ＭＵＸ直接支持的。ＭＵＸ不会知道一个用户应用程序何时读设备／ｄｅｖ／ｍｕｘＮ（０＜Ｎ＜Ｍ）。ｒｅａｄ（）功能由ＭＵＸ的上层（主要是ＴＴＹ层）支持。ＭＵＸ根据ＴＳ２７．０１０协议（或者Ｗａｖｅｃｏｍ协议）将物理链路上接收到的ＭＵＸ包解封装，然后将纯数据发送到设备／ｄｅｖ／ｍｕｘＮ（０＜Ｎ＜Ｍ）的读缓冲区中。如果设备／ｄｅｖ／ｍｕｘＮ（０＜Ｎ＜Ｍ）没有足够的读缓冲空间，ＭＵＸ就会将数据放到自己的接收缓冲区中。

４．３ Ｗａｖｅｃｏｍ复用协议特殊情况的处理

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

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