转自：http://blog.csdn.net/hellolwl/article/details/6164449
摘要： 介绍 3GPP提出的一种终端设备和移动台串行通信的复用协议及嵌入式 Linux系统下串行通信模块的结构和功能划分，在此基础上，提出一种实现这一复用协议的方案。目前，这一设计方案已经开发成功并广泛应用于所开发的车载移动终端产品中。
关键词： TS27.010 串行链路复用 GPRS移动终端 嵌入式 Linux
随 着移动通信技术的迅速发展，具备无线通信功能的移动终端也迅速发展起来。这些移动终端支 持普通的话音、短消息等业务，随着ＧＰＲＳ网络覆盖的迅速扩大，越来越多的手持／车载移动终端也开始支持ＧＰＲＳ上网业务。如何在一个终端设备上整合这些 业务，这是许多移动终端设备开发者面对的问题。笔者在开发一款车载移动终端过程中，采用了３ＧＰＰ的ＴＳ ２７．０１０协议，成功地整合了这些业务。
1. ＴＳ２７．０１０协议介绍
在常用的ＧＳＭ／ＧＰＲＳ通信模块中（如Ｓｉｅｍｅｎｓ的ＭＣ３５、ＷａｖｅＣｏｍ的 Ｑ２４００等），只能通过一个普通９针的异步串口 与终端设备ＴＥ（Ｔｅｒｍｉｎａｌ Ｅｑｕｉｐｍｅｎｔ）进行通信。ＴＥ和ＭＳ ?穴Ｍｏｂｉｌｅ Ｓｔａｔｉｏｎ ?雪需要通过这个串口交换各种类型的数据 ，例如：语音、传真、数据、ＳＭＳ、ＣＢＳ、电话号码本的维护、电池状态、ＧＰＲＳ、ＵＳＳＤ等。 如何在一个串口上同时支持这么多的业务？例如，在数据通信过程中，怎样发送或接收ＳＭＳ？为了解决这些问题，３ＧＰＰ提出了一个协议 ——ＴＳ２７．０１０ 协议（Ｔｅｒｍｉｎａｌ Ｅｑｕｉｐｍｅｎｔ ｔｏ Ｍｏｂｉｌｅ Ｓｔａｔｉｏｎ Ｍｕｌｔｉｐｌｅｘｅｒ Ｐｒｏｔｏｃｏｌ）。有了Ｍｕｌｔｉｐｌｅｘｅｒ，即使在数据连接过程中，也可以发送ＳＭＳ。其它业务组合也可以同时进行。例如，数字语音和ＳＭＳ同时发 送。Ｍｕｌｔｉｐｌｅｘｅｒ的存在使得一个完整的系统能够根据需要进行划分。
３ＧＰＰ 的Ｍｕｌｔｉｐｌｅｘｅｒ设计非常灵活，并且独立于ＭＳ／ＴＥ平台，已有的应用程序不需要改动即可工作。在设计Ｍｕｌｔｉｐｌｅｘｅｒ时，特别考虑到采用 电池供电的设备的需求，所以包含了省电模式控制等很重要的功能，并且Ｍｕｌｔｉｐｌｅｘｅｒ本身在运行时也尽量使用最小的功耗和内存。
Ｍｕｌｔｉｐｌｅｘｅｒ 基于ＩＳＯ的ＨＤＬＣ标准设计 ， 工作于有多种选项的单模式下。但是Ｂａｓｉｃ Ｏｐｔｉｏｎ并不遵从ＨＤＬＣ。在基本选项模式下，Ｍｕｌｔｉｐｌｅｘｅｒ没有透明机制，也没有错误恢复功能。但是在高级选项（Ａｄｖａｎｃｅｄ Ｏｐｔｉｏｎ）模式下，使用ＨＤＬＣ的透明机制，且Ｍｕｌｔｉｐｌｅｘｅｒ有一个方便的再同步机制，能够在ＤＣ１／ＤＣ３（ＸＯＮ／ＸＯＦＦ）流控打开的 链路上工作，且包含了错误恢复功能。
３ＧＰＰ的Ｍｕｌｔｉｐｌｅｘｅｒ依赖于一个控制信道。在这个控制信道上，ＴＥ和ＭＳ交换控制信息，例如参数协商、节电控制信息、流控信息等。Ｍｕｌｔｉｐｌｅｘｅｒ是一个可选项，如果支持这个功能，就应使用ＡＴ＋ＣＭＵＸ命令激活它。
Ｍｕｌｔｉｐｌｅｘｅｒ为ＴＥ和ＭＳ在一个起始／停止模式的、具有分帧功能的串行链路上传 输数据流提供了一套机制。图１给出了不同的协议层及其功能示意。Ｍｕｌｔｉｐｌｅｘｅｒ层负责将数据按字节流的方式传输 ，不再进行进一步的组帧；如果数据 需要按一定结构传输，就需要增加一个会聚层来完成这些功能。
Ｍｕｌｔｉｐｌｅｘｅｒ为ＴＥ上的进程和ＭＳ上相对应的进程提供了一条虚连接，这样ＴＥ和ＭＳ上的进程就可以通过这条虚连接通信。例如，ＴＥ上的ＳＭＳ应用程序可以通过一条Ｍｕｌｔｉｐｌｅｘｅｒ通道与ＭＳ上的ＳＭＳ处理程序连接起来。
ＴＳ２７．０１０规范使用８ｂｉｔ字符的ｓｔａｒｔ－ｓｔｏｐ传输模式，两个 Ｍｕｌｉｔｐｌｅｘｅｒ实体间的通信使用了规定的帧格式。ＴＥ和ＭＳ之间的每个信道称为一条数据链路连接ＤＬＣ（Ｄａｔａ Ｌｉｎｋ Ｃｏｎｎｅｃｔｉｏｎ） ，这些ＤＬＣ被依次独立地建立起来。每个ＤＬＣ都可以有自己的流控机制。
Ｍｕｌｔｉｐｌｅｘｅｒ有三种工作模式：Ｂａｓｉｃ、Ａｄｖａｎｃｅｄ ｗｉｔｈｏｕｔ ｅｒｒｏｒ ｒｅｃｏｖｅｒｙ和Ａｄｖａｎｃｅｄ ｗｉｔｈ ｅｒｒｏｒ ｒｅｃｏｖｅｒｙ 。这三种模式特点如下：
·Ｂａｓｉｃ：长度标识代替ＨＤＬＣ的透明机制；使用与ＨＤＬＣ不同的标志字；不能用于具有ＸＯＮ／ＸＯＦＦ流控的链路；从同步丢失状态中恢复需要更长的时间。
·Ａｄｖａｎｃｅｄ ｗｉｔｈｏｕｔ ｅｒｒｏｒ ｒｅｃｏｖｅｒｙ：遵从ＩＳＯ／ＩＥＣ１３２３９的异步ＨＤＬＣ过程；可以用于具备ＸＯＮ／ＸＯＦＦ流控的链路上；可以更快地从失同步状态恢复。
·Ａｄｖａｎｃｅｄ ｗｉｔｈ ｅｒｒｏｒ ｒｅｃｏｖｅｒｙ：使用了ＨＤＬＣ的错误恢复过程。
2. Ｗａｖｅｃｏｍ ＧＳＭ／ＧＰＲＳ模块Ｍｕｌｔｉｐｌｅｘｉｎｇ协议介绍
笔者选用了Ｗａｖｅｃｏｍ的Ｑ２４０３Ａ，这是一款Ｅ－ＧＳＭ／ＧＰＲＳ ９００／１８００的双频模块。这个模块支持大部分常用的ＡＴ命令，但不支持标准的ＴＳ２７．０１０协议。为了能够数据／命令复用，Ｗａｖｅｃｏｍ定义了自己的ｍｕｌｔｉｐｌｅｘ协议。
Ｗａｖｅｃｏｍ的复用协议允许一条串行链路上同时进行两个会话（即虚连接）：一个ＡＴ命令的会话和一个数据通信的会话。ＡＴ＋ＷＭＵＸ＝１将激活模块的复用模式。在这种模式下，ＡＴ命令和数据都被封装成数据包。通过包头，可以区分是数据包还是ＡＴ命令包。
2.1. ＡＴ命令包格式
ＡＴ命令包帧格式如图２所示。第一个字节（０ｘＡＡ）用于标识这是一个命令包，第二个字节 是ＡＴ命令长度的低八位。第三个字节由两部分组成：低３位是ＡＴ命令长度的高３位；高３位用于标识一个ＡＴ命令。ＡＴ命令的最大长度可以为２０４７字节。 校验和 ?穴ｃｈｅｃｋｓｕｍ ?雪是包中所有字节（包括头和ＡＴ命令）之和对２５６取模。
2.2. 数据包格式
数据包各个字段（除ｐａｃｋｅｔ ｔｙｐｅ外）意义与ＡＴ命令包相同，其帧格式如图３所示。数据包有以下几种类型：
·Ｔｙｐｅ＝０ ——ＤＡＴＡ 包：这个包是发送到无线链路上或者从无线链路上接收到的数据
·Ｔｙｐｅ＝１ ——ＳＴＡＴＵＳ包：这个包给出了ＳＡ、ＳＢ、Ｘ和中断条件编码的信息。
状态包的长度总为１字节。任何一个状态（除了ｂｒｅａｋ）改变时，所有的状态位都要发送出去。缺省情况下，所有的状态位都是关闭的（因此ＤＴＲ、ＲＴＳ都是关闭的），所以在打开复用开关准备传送数据之前，一定要发送一个状态包。
·Ｔｙｐｅ＝２ ——ＲＥＡＤＹ包：这个包表示发送ＲＥＡＤＹ包的一方可以接收数据了。包中没有数据，所以长度字段为０。
·Ｔｙｐｅ＝３ ——ＢＵＳＹ 包：这个包表示发送ＲＥＡＤＹ包的一方忙，无法接收数据。包中没有数据。
3. Ｌｉｎｕｘ下串口通信系统的组成
要在Ｌｉｎｕｘ系统上实现ＴＳ２７．０１０协议，就必须了解Ｌｉｎｕｘ下串口驱动软件模块的结构。
图４不但给出了 Ｌｉｎｕｘ ｋｅｒｎｅｌ中串口通信模块的组成结构，还形象地表示出了数据是如何在用户和硬件接口之间流动的（笔者使用Ｌｉｎｕｘ ２．４．１９的内核）。从图４可以看到串口通信模块可在逻辑上分为三层：ＴＴＹ层、ｌｉｎｅ ｄｉｓｃｉｐｌｉｎｅ层和底层驱动层。ＴＴＹ层是用户空间和内核空间的桥梁，用户程序和内核需要通过ｔｔｙ层交换数据；Ｌｏｗ－ｌｅｖｅｌ ｄｒｉｖｅｒ则负责硬件的交互，它对硬件进行控制和读写操作；ｌｉｎｅ ｄｉｓｃｉｐｌｉｎｅ层是整个串行通信模块中最灵活、设计最巧妙的一层，它要为一个串行口的使用定下数据交互的 “规程 ”， 在Ｌｉｎｕｘ内核中已经存在了许 多ｌｉｎｅ ｄｉｓｃｉｐｌｉｎｅ，例如ＰＰＰ、ＳＬＩＰ、ＴＴＹ等。缺省使用ＴＴＹ ｌｉｎｅ ｄｉｓｃｉｐｌｉｎｅ。可以根据需要将ｌｉｎｅ ｄｉｓｃｉｐｌｉｎｅ替换成Ｌｉｎｕｘ已经定义的ｌｉｎｅ ｄｉｓｃｉｐｌｉｎｅ结构，甚至替换为自己的ｌｉｎｅ ｄｉｓｃｉｐｌｉｎｅ结构。
在图４中，向硬 件接口写数据的过程是显而易见的。但是，用户程序从硬件读取数据的过程却要 复杂一些，这是因为硬件与用户空间之间没有直接的联系。解决的办法就是使用缓冲技术，硬件接收数据存储于ｋｅｒｎｅｌ ｂｕｆｆｅｒ中，等待用户程序请求这些数据；如果用户程序请求数据时，这个ｂｕｆｆｅｒ是空的，那么用户程序就会被挂起，直到ｂｕｆｆｅｒ中有数据时，它 才被唤醒。实际上，ＴＴＹ相关的缓冲是由两级构成的：一个 “常规 ”ｂｕｆｆｅｒ（数据等待着ｌｉｎｅ ｄｉｓｃｐｌｉｎｅ取走，缺省情况下传到用户空间）和一个 “ｆｌｉｐ ”ｂｕｆｆｅｒ（硬件驱动函数将底层进来的数据尽可能快地存入这个缓冲，而不必考虑并 发存取问题，因为这个ｂｕｆｆｅｒ是每个硬件驱动专有的）。ｆｌｉｐ ｂｕｆｆｅｒ由两个物理的缓冲实现，并被交替地写入，这样中断处理函数就会总有一个缓冲可用。
Ｌｉｎｕｘ下串 口软件的这种分层结构虽然增加了复杂性，但是它带来的好处是多方面的。第 一，串口模块更加灵活，在为新的串口硬件编写驱动程序时，只需修改和增加最底层的软件即可；第二，上层应用程序可以根据需要改变ｌｉｎｅ ｄｉｓｃｉｐｌｉｎｅ的处理软件，在使用ＰＰＰ、ＳＬＩＰ等协议进行拨号连接时，都需要将原有的ｌｉｎｅ ｄｉｓｃｉｐｌｉｎｅ替换为ＰＰＰ或者ＳＬＩＰ协议本身的ｌｉｎｅ ｄｉｓｃｉｐｌｉｎｅ ?鸦第三，可以根据需要，在层与层之间加入一层自己的处理软件。事实上，笔者在实现Ｍｕｌｔｉｐｌｅｘ协议时正是这样做的。
4. Ｍｕｌｔｉｐｌｅｘｉｎｇ协议的实现
4.1. 协议实现时的考虑
在实现 ＴＳ２７．０１０协议时，基于以下考虑：第一，使用串口的上层应用程序不需要改动。 这一点很重要，因为系统中有许多用户程序使用串口进行通信。如果需要对它们进行改动，那么由此付出的代价显然是不值得的。在这一点上，尤其需要特别考虑 ＰＰＰ软件，因为在Ｌｉｎｕｘ下通过ＧＰＲＳ上网必须使用ＰＰＰ协议进行拨号。ＰＰＰ存在于用户空间和内核空间两个地方，用户空间的ｐｐｐｄ应用程序完成 拨号连接的管理功能；内核空间的ｐｐｐ协议软件实现ＰＰＰ包的组帧／分帧等核心功能。ＰＰＰ定义了自己的ｌｉｎｅ ｄｉｓｃｉｐｌｉｎｅ模块，且到此为止，往下就不再有ＰＰＰ相关的软件模块（参看图４的分层结构）。第二，尽可能多地实现ＴＳ２７．０１０协议。虽然这个 协议的内容很丰富，但是由于Ｗａｖｅｃｏｍ通信模块只支持有限的几种格式，并且帧头部分还略有不同。这样实现起来就存在许多困难，只能在保证实现 Ｗａｖｅｃｏｍ复用协议并可靠工作的前提下，尽量实现ＴＳ２７．０１０协议，以便于以后硬件和软件的升级。
4.2. ｍｕｘ ｄｒｉｖｅｒ的实现方案
正是基于以上两点考虑，决定将这个协议的实现放在Ｌｉｎｅ ｄｉｓｃｉｐｌｉｎｅ和Ｌｏｗ－ｌｅｖｅｌ ｄｒｉｖｅｒ两层之间，参看图５。这样，不需要对Ｌｉｎｕｘ的ＴＣＰ／ＩＰ协议栈软件和ＰＰＰ软件作任何修改，就可以在复用模式下实现原有的无线上网功能。
图５给出了ＭＵＸ模块的函数调用和数据流程。ＴＴＹ Ｌａｙｅｒ、ｌｉｎｅ ｄｉｓｃｉｐｌｉｎｅ和ｓｅｒｉａｌ ｄｒｉｖｅｒ是Ｌｉｎｕｘ ｔｔｙ设备文件系统在内核中已有的三层，在前一节已经介绍。
正如笔者在实现 ＴＳ２７．０１０协议时所考虑的，为了不影响上层应用程序，ＭＵＸ必须支持 标准的Ｌｉｎｕｘ系统调用，如ｗｒｉｔｅ（）、ｒｅａｄ（）、ｉｏｃｔｌ（）等。ｗｒｉｔｅ（）如果成功，则返回发送的字节数；如果失败则返回－１，并将 ｅｒｒｎｏ（Ｌｉｎｕｘ系统下一个全局变量，用户接口可以根据这个值判断错误类型）置为合适的值。正如图５所示，ｗｒｉｔｅ ?穴 ?雪并不是将数据直接发送 出去，要发送的数据首先按照ＴＳ２７．０１０协议的要求（笔者使用Ｗａｖｅｃｏｍ模块，它有自己的协议要求）组成ＭＵＸ帧 ?熏然后根据数据的优先级排队， 优先级高的数据首先被发送。
同样，对设备 ／ｄｅｖ／ｍｕｘＮ（０＜Ｎ＜Ｍ）的标准的Ｌｉｎｕｘ调用ｒｅａｄ（）也不是 由ＭＵＸ直接支持的。ＭＵＸ不会知道一个用户应用程序何时读设备／ｄｅｖ／ｍｕｘＮ（０＜Ｎ＜Ｍ）。ｒｅａｄ（）功能由ＭＵＸ的上层（主要是ＴＴＹ层）支 持。ＭＵＸ根据ＴＳ２７．０１０协议（或者Ｗａｖｅｃｏｍ协议）将物理链路上接收到的ＭＵＸ包解封装，然后将纯数据发送到设备／ｄｅｖ／ｍｕｘＮ（０＜Ｎ ＜Ｍ）的读缓冲区中。如果设备／ｄｅｖ／ｍｕｘＮ（０＜Ｎ＜Ｍ）没有足够的读缓冲空间，ＭＵＸ就会将数据放到自己的接收缓冲区中。
4.3. Ｗａｖｅｃｏｍ复用协议特殊情况的处理
在实现 ＴＳ２７．０１０协议时，考虑到Ｗａｖｅｃｏｍ协议的特殊情况，在完全实现 Ｗａｖｅｃｏｍ复用功能的同时，尽可能多地实现ＴＳ２７．０１０协议。由于Ｗａｖｅｃｏｍ只能同时支持两个虚连接，所以这里的Ｍ＝２。其中， ／ｄｅｖ／ｍｕｘ０用于ＡＴ命令，作为控制信息通道；／ｄｅｖ／ｍｕｘ１用于ＰＰＰ连接，作为数据通道。作为Ｗａｖｅｃｏｍ复用协议的一个严重缺陷，从图 ２、图３的帧结构可以看到，从串行链路提交来的数据只能区分出是ＡＴ ｃｏｍｍａｎｄ数据还是ＤＡＴＡ数据，而无法确定链路的信息，即无法确定数据是ｍｕｘ０接收，还是ｍｕｘ１接收。为了解决这个问题，笔者在实现时，将底层 提交的数据同时送给ｍｕｘ０和ｍｕｘ１（如果这两个设备都已经打开）。但是考虑到软件的效率和数据的可靠性，在向上层提交数据时，有以下两点例外：第一， ｍｕｘ１是ＰＰＰ专用的，在ＰＰＰ没起来之前，ｍｕｘ１可以作为ＡＴ命令通道，但是ＰＰＰ连接成功后（ＰＰＰ的ｌｉｎｅ ｄｉｓｃｉｐｌｉｎｅ已经替换掉了缺省的ＴＴＹ ｌｉｎｅ ｄｉｓｃｉｐｌｉｎｅ），它将不再接收ＡＴ命令，所以此时底层提交的ＡＴ命令帧不会送给ｍｕｘ１ ?鸦第二，ｍｕｘ０作为ＡＴ命令通道，将不接收ＰＰＰ数 据，所以在ＰＰＰ连接成功后，不会把０ｘ７Ｅ开始和０ｘ７Ｅ结束（ＰＰＰ的帧同步标志字节）的ＤＡＴＡ帧发送到ｍｕｘ１。
ＧＰＲＳ网络作 为一种过渡性质的２．５Ｇ网络，覆盖日益广泛。由于它的速率高、实时性好、 费用低廉等诸多优势，日益被手持／车载等移动终端设备采用。在使用ＧＰＲＳ网络传输数据的同时，这些设备也必须能支持普通的无线业务，如语音、短消息等。 ＴＳ ２７．０１０协议很好地解决了这些业务的复用问题。笔者开发的这套Ｌｉｎｕｘ上的ｍｕｌｔｉｐｌｅｘｉｎｇ软件实现了这些功能，使得移动终端能够在ＰＰＰ 连接不断开的情况下，可以打出／接听电话、发送／接收短消息。
本文转自张昺华-sky博客园博客，原文链接：http://www.cnblogs.com/sky-heaven/p/6093849.html，如需转载请自行联系原作者