数据终端设备与无线通信模块之间串行通信链路复用协议TS27010在嵌入式系统上的开发.docx

数据终端设备与无线通信模块之间串行通信链路复用协议TS27010在嵌入式系统上的开发.docx

《数据终端设备与无线通信模块之间串行通信链路复用协议TS27010在嵌入式系统上的开发.docx》由会员分享，可在线阅读，更多相关《数据终端设备与无线通信模块之间串行通信链路复用协议TS27010在嵌入式系统上的开发.docx（5页珍藏版）》请在冰豆网上搜索。

数据终端设备与无线通信模块之间串行通信链路复用协议TS27010在嵌入式系统上的开发

数据终端设备与无线通信模块之间串行通信链路复用协议（TS27.010）在嵌入式系统上的开发

　　摘要：

介绍3GPP提出的一种终端设备和移动台串行通信的复用协议及嵌入式Linux系统下串行通信模块的结构和功能划分，在此基础上，提出一种实现这一复用协议的方案。

目前，这一设计方案已经开发成功并广泛应用于所开发的车载移动终端产品中。

关键词：

串行链路复用GPRS移动终端嵌入式Linux

随着移动通信技术的迅速发展，具备无线通信功能的移动终端也迅速发展起来。

这些移动终端支持普通的话音、短消息等业务，随着ＧＰＲＳ网络覆盖的迅速扩大，越来越多的手持／车载移动终端也开始支持ＧＰＲＳ上网业务。

如何在一个终端设备上整合这些业务，这是许多移动终端设备开发者面对的问题。

笔者在开发一款车载移动终端过程中，采用了３ＧＰＰ的ＴＳ２７．０１０协议，成功地整合了这些业务。

１ＴＳ２７．０１０协议介绍

在常用的ＧＳＭ／ＧＰＲＳ通信模块中，只能通过一个普通９针的异步串口与终端设备ＴＥ进行通信。

ＴＥ和ＭＳ?

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

雪需要通过这个串口交换各种类型的数据，例如：

语音、传真、数据、ＳＭＳ、ＣＢＳ、电话号码本的维护、电池状态、ＧＰＲＳ、ＵＳＳＤ等。

如何在一个串口上同时支持这么多的业务？

例如，在数据通信过程中，怎样发送或接收ＳＭＳ？

为了解决这些问题，３ＧＰＰ提出了一个协议——ＴＳ２７．０１０协议。

有了Ｍｕｌｔｉｐｌｅｘｅｒ，即使在数据连接过程中，也可以发送ＳＭＳ。

其它业务组合也可以同时进行。

例如，数字语音和ＳＭＳ同时发送。

Ｍｕｌｔｉｐｌｅｘｅｒ的存在使得一个完整的系统能够根据需要进行划分。

３ＧＰＰ的Ｍｕｌｔｉｐｌｅｘｅｒ设计非常灵活，并且独立于ＭＳ／ＴＥ平台，已有的应用程序不需要改动即可工作。

在设计Ｍｕｌｔｉｐｌｅｘｅｒ时，特别考虑到采用电池供电的设备的需求，所以包含了省电模式控制等很重要的功能，并且Ｍｕｌｔｉｐｌｅｘｅｒ本身在运行时也尽量使用最小的功耗和内存。

Ｍｕｌｔｉｐｌｅｘｅｒ基于ＩＳＯ的ＨＤＬＣ标准设计，工作于有多种选项的单模式下。

但是ＢａｓｉｃＯｐｔｉｏｎ并不遵从ＨＤＬＣ。

在基本选项模式下，Ｍｕｌｔｉｐｌｅｘｅｒ没有透明机制，也没有错误恢复功能。

但是在高级选项模式下，使用ＨＤＬＣ的透明机制，且Ｍｕｌｔｉｐｌｅｘｅｒ有一个方便的再同步机制，能够在ＤＣ１／ＤＣ３流控打开的链路上工作，且包含了错误恢复功能。

３ＧＰＰ的Ｍｕｌｔｉｐｌｅｘｅｒ依赖于一个控制信道。

在这个控制信道上，ＴＥ和ＭＳ交换控制信息，例如参数协商、节电控制信息、流控信息等。

Ｍｕｌｔｉｐｌｅｘｅｒ是一个可选项，如果支持这个功能，就应使用ＡＴ＋ＣＭＵＸ命令激活它。

Ｍｕｌｔｉｐｌｅｘｅｒ为ＴＥ和ＭＳ在一个起始／停止模式的、具有分帧功能的串行链路上传输数据流提供了一套机制。

图１给出了不同的协议层及其功能示意。

Ｍｕｌｔｉｐｌｅｘｅｒ层负责将数据按字节流的方式传输，不再进行进一步的组帧；如果数据需要按一定结构传输，就需要增加一个会聚层来完成这些功能。

Ｍｕｌｔｉｐｌｅｘｅｒ为ＴＥ上的进程和ＭＳ上相对应的进程提供了一条虚连接，这样ＴＥ和ＭＳ上的进程就可以通过这条虚连接通信。

例如，ＴＥ上的ＳＭＳ应用程序可以通过一条Ｍｕｌｔｉｐｌｅｘｅｒ通道与ＭＳ上的ＳＭＳ处理程序连接起来。

ＴＳ２７．０１０规范使用８ｂｉｔ字符的ｓｔａｒｔ－ｓｔｏｐ传输模式，两个Ｍｕｌｉｔｐｌｅｘｅｒ实体间的通信使用了规定的帧格式。

ＴＥ和ＭＳ之间的每个信道称为一条数据链路连接ＤＬＣ，这些ＤＬＣ被依次独立地建立起来。

每个ＤＬＣ都可以有自己的流控机制。

Ｍｕｌｔｉｐｌｅｘｅｒ有三种工作模式：

Ｂａｓｉｃ、Ａｄｖａｎｃｅｄｗｉｔｈｏｕｔｅｒｒｏｒｒｅｃｏｖｅｒｙ和Ａｄｖａｎｃｅｄｗｉｔｈｅｒｒｏｒｒｅｃｏｖｅｒｙ。

这三种模式特点

·Ｂａｓｉｃ：

长度标识代替ＨＤＬＣ的透明机制；使用与ＨＤＬＣ不同的标志字；不能用于具有ＸＯＮ／ＸＯＦＦ流控的链路；从同步丢失状态中恢复需要更长的时间。

·Ａｄｖａｎｃｅｄｗｉｔｈｏｕｔｅｒｒｏｒｒｅｃｏｖｅｒｙ：

遵从ＩＳＯ／ＩＥＣ１３２３９的异步ＨＤＬＣ过程；可以用于具备ＸＯＮ／ＸＯＦＦ流控的链路上；可以更快地从失同步状态恢复。

·Ａｄｖａｎｃｅｄｗｉｔｈｅｒｒｏｒｒｅｃｏｖｅｒｙ：

使用了ＨＤＬＣ的错误恢复过程。

２ＷａｖｅｃｏｍＧＳＭ／ＧＰＲＳ模块Ｍｕｌｔｉｐｌｅｘｉｎｇ协议介绍

笔者选用了Ｗａｖｅｃｏｍ的Ｑ２４０３Ａ，这是一款Ｅ－ＧＳＭ／ＧＰＲＳ９００／１８００的双频模块。

这个模块支持大部分常用的ＡＴ命令，但不支持标准的ＴＳ２７．０１０协议。

为了能够数据／命令复用，Ｗａｖｅｃｏｍ定义了自己的ｍｕｌｔｉｐｌｅｘ协议。

Ｗａｖｅｃｏｍ的复用协议允许一条串行链路上同时进行两个会话：

一个ＡＴ命令的会话和一个数据通信的会话。

ＡＴ＋ＷＭＵＸ＝１将激活模块的复用模式。

在这种模式下，ＡＴ命令和数据都被封装成数据包。

通过包头，可以区分是数据包还是ＡＴ命令包。

２．１ＡＴ命令包格式

ＡＴ命令包帧格式如图２所示。

第一个字节用于标识这是一个命令包，第二个字节是ＡＴ命令长度的低八位。

第三个字节由两部分组成：

低３位是ＡＴ命令长度的高３位；高３位用于标识

　　一个ＡＴ命令。

ＡＴ命令的最大长度可以为２０４７字节。

校验和?

穴ｃｈｅｃｋｓｕｍ?

雪是包中所有字节之和对２５６取模。

２．２数据包格式

数据包各个字段意义与ＡＴ命令包相同，其帧格式如图３所示。

数据包有以下几种类型

·Ｔｙｐｅ＝０——ＤＡＴＡ包：

这个包是发送到无线链路上或者从无线链路上接收到的数据

·Ｔｙｐｅ＝１——ＳＴＡＴＵＳ包：

这个包给出了ＳＡ、ＳＢ、Ｘ和中断条件编码的信息。

状态包的长度总为１字节。

任何一个状态改变时，所有的状态位都要发送出去。

缺省情况下，所有的状态位都是关闭的，所以在打开复用开关准备传送数据之前，一定要发送一个状态包。

·Ｔｙｐｅ＝２——ＲＥＡＤＹ包：

这个包表示发送ＲＥＡＤＹ包的一方可以接收数据了。

包中没有数据，所以长度字段为０。

·Ｔｙｐｅ＝３——ＢＵＳＹ包：

这个包表示发送ＲＥＡＤＹ包的一方忙，无法接收数据。

包中没有数据。

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

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

图４不但给出了Ｌｉｎｕｘｋｅｒｎｅｌ中串口通信模块的组成结构，还形象地表示出了数据是如何在用户和硬件接口之间流动的。

从图４可以看到串口通信模块可在逻辑上分为三层：

ＴＴＹ层、ｌｉｎｅｄｉｓｃｉｐｌｉｎｅ层和底层驱动层。

ＴＴＹ层是用户空间和内核空间的桥梁，用户程序和内核需要通过ｔｔｙ层交换数据；Ｌｏｗ－ｌｅｖｅｌｄｒｉｖｅｒ则负责硬件的交互，它对硬件进行控制和读写操作；ｌｉｎｅｄｉｓｃｉｐｌｉｎｅ层是整个串行通信模块中最灵活、设计最巧妙的一层，它要为一个串行口的使用定下数据交互的“规程”，在Ｌｉｎｕｘ内核中已经存在了许多ｌｉｎｅｄｉｓｃｉｐｌｉｎｅ，例如ＰＰＰ、ＳＬＩＰ、ＴＴＹ等。

缺省使用ＴＴＹｌｉｎｅｄｉｓｃｉｐｌｉｎｅ。

可以根据需要将ｌｉｎｅｄｉｓｃｉｐｌｉｎｅ替换成Ｌｉｎｕｘ已经定义的ｌｉｎｅｄｉｓｃｉｐｌｉｎｅ结构，甚至替换为自己的ｌｉｎｅｄｉｓｃｉｐｌｉｎｅ结构。

在图４中，向硬件接口写数据的过程是显而易见的。

但是，用户程序从硬件读取数据的过程却要复杂一些，这是因为硬件与用户空间之间没有直接的联系。

解决的办法就是使用缓冲技术，硬件接收数据存储于ｋｅｒｎｅｌｂｕｆｆｅｒ中，等待用户程序请求这些数据；如果用户程序请求数据时，这个ｂｕｆｆｅｒ是空的，那么用户程序就会被挂起，直到ｂｕｆｆｅｒ中有数据时，它才被唤醒。

实际上，ＴＴＹ相关的缓冲是由两级构成的：

一个“常规”ｂｕｆｆｅｒ和一个“ｆｌｉｐ”ｂｕｆｆｅｒ。

ｆｌｉｐｂｕｆｆｅｒ由两个物理的缓冲实现，并被交替地写入，这样中断处理函数就会总有一个缓冲可用。

Ｌｉｎｕｘ下串口软件的这种分层结构虽然增加了复杂性，但是它带来的好处是多方面的。

第一，串口模块更加灵活，在为新的串口硬件编写驱动程序时，只需修改和增加最底层的软件即可；第二，上层应用程序可以根据需要改变ｌｉｎｅｄｉｓｃｉｐｌｉｎｅ的处理软件，在使用ＰＰＰ、ＳＬＩＰ等协议进行拨号连接时，都需要将原有的ｌｉｎｅｄｉｓｃｉｐｌｉｎｅ替换为ＰＰＰ或者ＳＬＩＰ协议本身的ｌｉｎｅｄｉｓｃｉｐｌｉｎｅ?

鸦第三，可以根据需要，在层与层之间加入一层自己的处理软件。

事实上，笔者在实现Ｍｕｌｔｉｐｌｅｘ协议时正是这样做的。

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

４．１协议实现时的考虑

在实现ＴＳ２７．０１０协议时，基于以下考虑：

第一，使用串口的上层应用程序不需要改动。

这一点很重要，因为系统中有许多用户程序使用串口进行通信。

如果需要对它们进行改动，那么由此付出的代价显然是不值得的。

在这一点上，尤其需要特别考虑ＰＰＰ软件，因为在Ｌｉｎｕｘ下通过ＧＰＲＳ上网必须使用ＰＰＰ协议进行拨号。

ＰＰＰ存在于用户空间和内核空间两个地方，用户空间的ｐｐｐｄ应用程序完成拨号连接的管理功能；内核空间的ｐｐｐ协议软件实现ＰＰＰ包的组帧／分帧等核心功能。

ＰＰＰ定义了自己的ｌｉｎｅｄｉｓｃｉｐｌｉｎｅ模块，且到此为止，往下就不再有ＰＰＰ相关的软件模块。

第二，尽可能多地实现ＴＳ２７．０１０协议。

虽然这个协议的内容很丰富，但是由于Ｗａｖｅｃｏｍ通信模块只支持有限的几种格式，并且帧头部分还略有不同。

这样实现起来就存在许多困难，只能在保证实现Ｗａｖｅｃｏｍ复用协议并可靠工作的前提下，尽量实现ＴＳ２７．０１０协议，以便于以后硬件和软件的升级。

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

正是基于以上两点考虑，决定将这个协议的实现放在Ｌｉｎｅｄｉｓｃｉｐｌｉｎｅ和Ｌｏｗ－ｌｅｖｅｌｄｒｉｖｅｒ两层之间，参看图５。

这样，不需要对Ｌｉｎｕｘ的ＴＣＰ／ＩＰ协议栈软件和ＰＰＰ软件作任何修改，就可以在复用模式下实现原有的无线上网功能。

图５给出了ＭＵＸ模块的函数调用和数据流程。

ＴＴＹＬａｙｅｒ、ｌｉｎｅｄｉｓｃｉｐｌｉｎｅ和ｓｅｒｉａｌｄｒｉｖｅｒ是Ｌｉｎｕｘｔｔｙ设备文件系统在内核中已有的三层，在前一节已经介绍。

正如笔者在实现ＴＳ２７．０１０协议时所考虑的，为了不影响上层应用程序，ＭＵＸ必须支持标准的Ｌｉｎｕｘ系统调用，如ｗｒｉｔｅ、ｒｅａｄ、ｉｏｃｔｌ等。

ｗｒｉｔｅ如果成功，则返回发送的字节数；如果失败则返回－１，并将ｅｒｒｎｏ置为合适的值。

正如图５所示，ｗｒｉｔｅ?

穴?

雪并不是将数据直接发送出去，要发送的数据首先按照ＴＳ２７．０１０协议的要求组成ＭＵＸ帧?

熏然后根据数据的优先级排队，优先级高的数据首先被发送。

同样，对设备／ｄｅｖ／ｍｕｘＮ的标准的Ｌｉｎｕｘ调用ｒｅａｄ也不是由ＭＵＸ直接支持的。

ＭＵＸ不会知道一个用户应用程序何时读设备／ｄｅｖ／ｍｕｘＮ。

ｒｅａｄ功能由ＭＵＸ的上层支持。

ＭＵＸ根据ＴＳ２７．０１０协议（或者Ｗａｖｅｃ

　　ｏｍ协议）将物理链路上接收到的ＭＵＸ包解封装，然后将纯数据发送到设备／ｄｅｖ／ｍｕｘＮ的读缓冲区中。

如果设备／ｄｅｖ／ｍｕｘＮ没有足够的读缓冲空间，ＭＵＸ就会将数据放到自己的接收缓冲区中。

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

在实现ＴＳ２７．０１０协议时，考虑到Ｗａｖｅｃｏｍ协议的特殊情况，在完全实现Ｗａｖｅｃｏｍ复用功能的同时，尽可能多地实现ＴＳ２７．０１０协议。

由于Ｗａｖｅｃｏｍ只能同时支持两个虚连接，所以这里的Ｍ＝２。

其中，／ｄｅｖ／ｍｕｘ０用于ＡＴ命令，作为控制信息通道；／ｄｅｖ／ｍｕｘ１用于ＰＰＰ连接，作为数据通道。

作为Ｗａｖｅｃｏｍ复用协议的一个严重缺陷，从图２、图３的帧结构可以看到，从串行链路提交来的数据只能