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

2007-03-09 19:03:27来源: 互联网
摘要:介绍3GPP提出的一种终端设备和移动台串行通信的复用协议及嵌入式Linux系统下串行通信模块的结构和功能划分,在此基础上,提出一种实现这一复用协议的方案。目前,这一设计方案已经开发成功并广泛应用于所开发的车载移动终端产品中。 关键词:TS27.010 串行链路复用 GPRS移动终端 嵌入式Linux 随着移动通信技术的迅速发展,具备无线通信功能的移动终端也迅速发展起来。这些移动终端支持普通的话音、短消息等业务,随着GPRS网络覆盖的迅速扩大,越来越多的手持/车载移动终端也开始支持GPRS上网业务。如何在一个终端设备上整合这些业务,这是许多移动终端设备开发者面对的问题。笔者在开发一款车载移动终端过程中,采用了3GPP的TS 27.010协议,成功地整合了这些业务。 图1 TS27.010协议栈组成与示意图 1 TS27.010协议介绍 在常用的GSM/GPRS通信模块中(如Siemens的MC35、WaveCom的Q2400等),只能通过一个普通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。这三种模式特点如下: %26;#183;Basic:长度标识代替HDLC的透明机制;使用与HDLC不同的标志字;不能用于具有XON/XOFF流控的链路;从同步丢失状态中恢复需要更长的时间。 %26;#183;Advanced without error recovery:遵从ISO/IEC13239的异步HDLC过程;可以用于具备XON/XOFF流控的链路上;可以更快地从失同步状态恢复。 %26;#183;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取模。 图4 Linux下串行通信数据流和函数调用示意图 2.2 数据包格式 数据包各个字段(除packet type外)意义与AT命令包相同,其帧格式如图3所示。数据包有以下几种类型: %26;#183;Type=0——DATA 包:这个包是发送到无线链路上或者从无线链路上接收到的数据 %26;#183;Type=1——STATUS包:这个包给出了SA、SB、X和中断条件编码的信息。 状态包的长度总为1字节。任何一个状态(除了break)改变时,所有的状态位都要发送出去。缺省情况下,所有的状态位都是关闭的(因此DTR、RTS都是关闭的),所以在打开复用开关准备传送数据之前,一定要发送一个状态包。 %26;#183;Type=2——READY包:这个包表示发送READY包的一方可以接收数据了。包中没有数据,所以长度字段为0。 %26;#183;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协议时正是这样做的。 图5 MUX系统组成 4 Multiplexing协议的实现 4.1 协议实现时的考虑 在实现TS27.010协议时,基于以下考虑:第一,使用串口的上层应用程序不需要改动。这一点很重要,因为系统中有许多用户程序使用串口进行通信。如果需要对它们进行改动,那么由此付出的代价显然是不值得的。在这一点上,尤其需要特别考虑PPP软件,因为在Linux下通过GPRS上网必须使用PPP协议进行拨号。PPP存在于用户空间和内核空间两个地方,用户空间的pppd应用程序完成拨号连接的管理功能;内核空间的ppp协议软件实现PPP包的组帧/分帧等核心功能。PPP定义了自己的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连接不断开的情况下,可以打出/接听电话、发送/接收短消息。
编辑: 引用地址:http://www.eeworld.com.cn/designarticles/embed/200703/11777.html
本网站转载的所有的文章、图片、音频视频文件等资料的版权归版权所有人所有,本站采用的非本站原创文章及图片等内容无法一一联系确认版权者。如果本网所选内容的文章作者及编辑认为其作品不宜公开自由传播,或不应无偿使用,请及时通过电子邮件或电话通知我们,以迅速采取适当措施,避免给双方造成不必要的经济损失。
论坛活动 E手掌握
微信扫一扫加关注
论坛活动 E手掌握
芯片资讯 锐利解读
微信扫一扫加关注
芯片资讯 锐利解读
推荐阅读
全部

小广播

About Us 关于我们 客户服务 联系方式 器件索引 网站地图 最新更新 手机版

站点相关: 安防电子 医疗电子 工业控制

北京市海淀区知春路23号集成电路设计园量子银座1305 电话:(010)82350740 邮编:100191

电子工程世界版权所有 京ICP证060456号 京ICP备10001474号 电信业务审批[2006]字第258号函 京公海网安备110108001534 Copyright © 2005-2016 EEWORLD.com.cn, Inc. All rights reserved