串行通信链路复用协议在嵌入系统上开发 - 通信/网络 - 电

2dmin

随着移动通信技术的迅速发展,具备无线通信功能的移动终端也迅速发展起来｡这些移动终端支持普通的话音､短消息等业务,随着GPRS网络覆盖的迅速扩大,越来越多的手持/车载移动终端也开始支持GPRS上网业务｡如何在一个终端设备上整合这些业务,这是许多移动终端设备开发者面对的问题｡笔者在开发一款车载移动终端过程中,采用了3GPP的TS 27.010协议,成功地整合了这些业务｡

1 TS27.010协议介绍

在常用的GSM/GPRS通信模块中(如Siemens的MC35MC35､WaveCom的Q2400Q2400等),只能通过一个普通9针的异步串口与终端设备TE(Terminal Equipment)进行通信｡TE和MS?Mobile Station 需要通过这个串口交换各种类型的数据,例如:语音､传真､数据､SMS､CBS､电话号码本的维护､电池状态､GPRS､USSD等｡如何在一个串口上同时支持这么多的业务?例如,在数据通信过程中,怎样发送或接收SMS?为了解决这些问题,3GPP提出了一个协议--TS27.010协议(Terminal Equipment to Mobile Station Multiplexer Protocol)｡有了Multiplexer,即使在数据连接过程中,也可以发送SMS｡其它业务组合也可以同时进行｡例如,数字语音和SMS同时发送｡Multiplexer的存在使得一个完整的系统能够根据需要进行划分｡

3GPP 的Multiplexer设计非常灵活,并且独立于MS/TE平台,已有的应用程序不需要改动即可工作｡在设计Multiplexer时,特别考虑到采用电池供电的设备的需求,所以包含了省电模式控制等很重要的功能,并且Multiplexer本身在运行时也尽量使用最小的功耗和内存｡

Multiplexer基于ISO的HDLC标准设计,工作于有多种选项的单模式下｡但是Basic Option并不遵从HDLC｡在基本选项模式下,Multiplexer没有透明机制,也没有错误恢复功能｡但是在高级选项(Advanced Option)模式下,使用HDLC的透明机制,且Multiplexer有一个方便的再同步机制,能够在DC1/DC3(XON/XOFF)流控打开的链路上工作,且包含了错误恢复功能｡

3GPP的Multiplexer依赖于一个控制信道｡在这个控制信道上,TE和MS交换控制信息,例如参数协商､节电控制信息､流控信息等｡Multiplexer是一个可选项,如果支持这个功能,就应使用AT+CMUX命令激活它｡ Multiplexer为TE和MS在一个起始/停止模式的､具有分帧功能的串行链路上传输数据流提供了一套机制｡图1给出了不同的协议层及其功能示意｡Multiplexer层负责将数据按字节流的方式传输,不再进行进一步的组帧;如果数据需要按一定结构传输,就需要增加一个会聚层来完成这些功能｡

Multiplexer为TE上的进程和MS上相对应的进程提供了一条虚连接,这样TE和MS上的进程就可以通过这条虚连接通信｡例如,TE上的SMS应用程序可以通过一条Multiplexer通道与MS上的SMS处理程序连接起来｡ TS27.010规范使用8bit字符的start-stop传输模式,两个Mulitplexer实体间的通信使用了规定的帧格式｡TE和MS之间的每个信道称为一条数据链路连接DLC(Data Link Connection),这些DLC被依次独立地建立起来｡每个DLC都可以有自己的流控机制｡

Multiplexer有三种工作模式:Basic､Advanced without error recovery和Advanced with error recovery｡这三种模式特点如下:

•Basic:长度标识代替HDLC的透明机制;使用与HDLC不同的标志字;不能用于具有XON/XOFF流控的链路;从同步丢失状态中恢复需要更长的时间｡
•Advanced without error recovery:遵从ISO/IEC13239的异步HDLC过程;可以用于具备XON/XOFF流控的链路上;可以更快地从失同步状态恢复｡
•Advanced with error recovery:使用了HDLC的错误恢复过程｡


2 Wavecom GSM/GPRS模块Multiplexing协议介绍

笔者选用了Wavecom的Q2403A,这是一款E-GSM/GPRS 900/1800的双频模块｡这个模块支持大部分常用的AT命令,但不支持标准的TS27.010协议｡为了能够数据/命令复用,Wavecom定义了自己的multiplex协议｡

Wavecom的复用协议允许一条串行链路上同时进行两个会话(即虚连接):一个AT命令的会话和一个数据通信的会话｡AT+WMUX=1将激活模块的复用模式｡在这种模式下,AT命令和数据都被封装成数据包｡通过包头,可以区分是数据包还是AT命令包｡

2.1 AT命令包格式

AT命令包帧格式如图2所示｡第一个字节?0xAA 用于标识这是一个命令包,第二个字节是AT命令长度的低八位｡第三个字节由两部分组成:低3位是AT命令长度的高3位;高3位用于标识一个AT命令｡AT命令的最大长度可以为2047字节｡校验和(checksum)是包中所有字节(包括头和AT命令)之和对256取模｡


2.2 数据包格式

数据包各个字段(除packet type外)意义与AT命令包相同,其帧格式如图3所示｡数据包有以下几种类型:


•Type=0--DATA 包:这个包是发送到无线链路上或者从无线链路上接收到的数据
•Type=1--STATUS包:这个包给出了SA､SB､X和中断条件编码的信息｡

状态包的长度总为1字节｡任何一个状态(除了break)改变时,所有的状态位都要发送出去｡缺省情况下,所有的状态位都是关闭的(因此DTR､RTS都是关闭的),所以在打开复用开关准备传送数据之前,一定要发送一个状态包｡

•Type=2--READY包:这个包表示发送READY包的一方可以接收数据了｡包中没有数据,所以长度字段为0｡
•Type=3--BUSY 包:这个包表示发送READY包的一方忙,无法接收数据｡包中没有数据｡

3 Linux下串口通信系统的组成

要在Linux系统上实现TS27.010协议,就必须了解Linux下串口驱动软件模块的结构｡

图4不但给出了Linux kernel中串口通信模块的组成结构,还形象地表示出了数据是如何在用户和硬件接口之间流动的(笔者使用Linux 2.4.19的内核)｡从图4可以看到串口通信模块可在逻辑上分为三层:TTY层､line discipline层和底层驱动层｡TTY层是用户空间和内核空间的桥梁,用户程序和内核需要通过tty层交换数据;Low-level driver则负责硬件的交互,它对硬件进行控制和读写操作;line discipline层是整个串行通信模块中最灵活､设计最巧妙的一层,它要为一个串行口的使用定下数据交互的"规程",在Linux内核中已经存在了许多line discipline,例如PPP､SLIP､TTY等｡缺省使用TTY line discipline｡可以根据需要将line discipline替换成Linux已经定义的line discipline结构,甚至替换为自己的line discipline结构｡ 在图4中,向硬件接口写数据的过程是显而易见的｡但是,用户程序从硬件读取数据的过程却要复杂一些,这是因为硬件与用户空间之间没有直接的联系｡解决的办法就是使用缓冲技术,硬件接收数据存储于kernel buffer中,等待用户程序请求这些数据;如果用户程序请求数据时,这个buffer是空的,那么用户程序就会被挂起,直到buffer中有数据时,它才被唤醒｡实际上,TTY相关的缓冲是由两级构成的:一个"常规"buffer(数据等待着line discpline取走,缺省情况下传到用户空间)和一个"flip"buffer(硬件驱动函数将底层进来的数据尽可能快地存入这个缓冲,而不必考虑并发存取问题,因为这个buffer是每个硬件驱动专有的)｡flip buffer由两个物理的缓冲实现,并被交替地写入,这样中断处理函数就会总有一个缓冲可用｡


Linux下串口软件的这种分层结构虽然增加了复杂性,但是它带来的好处是多方面的｡第一,串口模块更加灵活,在为新的串口硬件编写驱动程序时,只需修改和增加最底层的软件即可;第二,上层应用程序可以根据需要改变line discipline的处理软件,在使用PPP､SLIP等协议进行拨号连接时,都需要将原有的line discipline替换为PPP或者SLIP协议本身的line discipline?第三,可以根据需要,在层与层之间加入一层自己的处理软件｡事实上,笔者在实现Multiplex协议时正是这样做的｡

4 Multiplexing协议的实现

4.1 协议实现时的考虑

在实现TS27.010协议时,基于以下考虑:第一,使用串口的上层应用程序不需要改动｡这一点很重要,因为系统中有许多用户程序使用串口进行通信｡如果需要对它们进行改动,那么由此付出的代价显然是不值得的｡在这一点上,尤其需要特别考虑PPP软件,因为在Linux下通过GPRS上网必须使用PPP协议进行拨号&#65377PP存在于用户空间和内核空间两个地方,用户空间的pppd应用程序完成拨号连接的管理功能;内核空间的ppp协议软件实现PPP包的组帧/分帧等核心功能&#65377PP定义了自己的line discipline模块,且到此为止,往下就不再有PPP相关的软件模块(参看图4的分层结构)｡第二,尽可能多地实现TS27.010协议｡虽然这个协议的内容很丰富,但是由于Wavecom通信模块只支持有限的几种格式,并且帧头部分还略有不同｡这样实现起来就存在许多困难,只能在保证实现Wavecom复用协议并可靠工作的前提下,尽量实现TS27.010协议,以便于以后硬件和软件的升级｡

4.2 mux driver的实现方案

正是基于以上两点考虑,决定将这个协议的实现放在Line discipline和Low-level driver两层之间,参看图5｡这样,不需要对Linux的TCP/IP协议栈软件和PPP软件作任何修改,就可以在复用模式下实现原有的无线上网功能｡

图5给出了MUX模块的函数调用和数据流程｡TTY Layer､line discipline和serial driver是Linux tty设备文件系统在内核中已有的三层,在前一节已经介绍｡


正如笔者在实现TS27.010协议时所考虑的,为了不影响上层应用程序,MUX必须支持标准的Linux系统调用,如write()､read()､ioctl()等｡write()如果成功,则返回发送的字节数;如果失败则返回-1,并将errno(Linux系统下一个全局变量,用户接口可以根据这个值判断错误类型)置为合适的值｡正如图5所示,write()并不是将数据直接发送出去,要发送的数据首先按照TS27.010协议的要求(笔者使用Wavecom模块,它有自己的协议要求)组成MUX帧?然后根据数据的优先级排队,优先级高的数据首先被发送｡ 同样,对设备/dev/muxN(0<N<M=的标准的Linux调用read()也不是由MUX直接支持的｡MUX不会知道一个用户应用程序何时读设备/dev/muxN(0<N<M=｡read()功能由MUX的上层(主要是TTY层)支持｡MUX根据TS27.010协议(或者Wavecom协议)将物理链路上接收到的MUX包解封装,然后将纯数据发送到设备/dev/muxN(0<N<M=的读缓冲区中｡如果设备/dev/muxN(0<N<M)没有足够的读缓冲空间,MUX就会将数据放到自己的接收缓冲区中｡

4.3 Wavecom复用协议特殊情况的处理

在实现TS27.010协议时,考虑到Wavecom协议的特殊情况,在完全实现Wavecom复用功能的同时,尽可能多地实现TS27.010协议｡由于Wavecom只能同时支持两个虚连接,所以这里的M=2｡其中,/dev/mux0用于AT命令,作为控制信息通道;/dev/mux1用于PPP连接,作为数据通道｡作为Wavecom复用协议的一个严重缺陷,从图2､图3的帧结构可以看到,从串行链路提交来的数据只能区分出是AT command数据还是DATA数据,而无法确定链路的信息,即无法确定数据是mux0接收,还是mux1接收｡为了解决这个问题,笔者在实现时,将底层提交的数据同时送给mux0和mux1?如果这两个设备都已经打开 ｡但是考虑到软件的效率和数据的可靠性,在向上层提交数据时,有以下两点例外:第一,mux1是PPP专用的,在PPP没起来之前,mux1可以作为AT命令通道,但是PPP连接成功后(PPP的line discipline已经替换掉了缺省的TTY line discipline),它将不再接收AT命令,所以此时底层提交的AT命令帧不会送给mux1?第二,mux0作为AT命令通道,将不接收PPP数据,所以在PPP连接成功后,不会把0x7E开始和0x7E结束?PPP的帧同步标志字节 的DATA帧发送到mux1｡

GPRS网络作为一种过渡性质的2.5G网络,覆盖日益广泛｡由于它的速率高､实时性好､费用低廉等诸多优势,日益被手持/车载等移动终端设备采用｡在使用GPRS网络传输数据的同时,这些设备也必须能支持普通的无线业务,如语音､短消息等｡TS 27.010协议很好地解决了这些业务的复用问题｡笔者开发的这套Linux上的multiplexing软件实现了这些功能,使得移动终端能够在PPP连接不断开的情况下,可以打出/接听电话､发送/接收短消息｡