GPRS行业应用
- 发布时间:2009-10-29
- 浏览次数:1965
资料类型 | 文件 | ||
下载次数 | 0 | ||
上 传 人 | 默认 | ||
关 键 词 | |||
资料大小 | 0 | ||
需要积分 | 0 |
1、GPRS行业应用
GPRS当前应用广泛的行业有电力、油田、工业控制、运输、金融、证券、商业、公共安全业、天气预报、交通信息实时发布等,应用特点是数据量小,发送时间间隔大,或不定时发送。通过GPRS网络进行数据传输,具有成本低、组网迅速灵活、范围广、专业队伍维护的优势。
应用中,用户在GPRS网络上可选择UDP与TCP传输协议,由于没有明确的标准,选用何种协议让业主单位、设备供应商、系统集成商常常为在选用何种传输协议进行长时间讨论,并且进行了大量测试,几乎每个项目都要进行小规模试验,影响了GPRS在行业应用的进程。系统运行效果除受协议选择影响外,还受到网络质量、使用方式、外围设备的影响。很多试验的结果不尽一致,不能准确反映TCP/UDP协议选择带来的效果。让TCP/UDP选择再次陷入新一轮讨论与测试过程。
2、两种传输协议的定义与主要特征的比较
关于UDP、TCP两种协议的详细讲解请参阅相关资料,这里针对行业应用的特点进行说明。
UDP是一个简单的面向数据报的运输层协议:进程的每个输出操作都正好产生一个UDP数据报,并组装成一份待发送的IP数据报。UDP数据报封装成一份IP数据报的格式如图所示:
UDP不提供可靠性连接:它把应用程序传给IP层的数据发送出去,但是并不保证它们能到达目的地。
TCP和UDP都使用相同的网络层(IP)。TCP提供了一种可靠的面向连接的字节流运输层服务。如图所示:
TCP向应用层提供与UDP*不同的服务。TCP提供一种面向连接的、可靠的字节流服务。TCP将用户数据打包构成报文段;它发送数据后启动一个定时器,等待对端数据确认;另一端对收到的数据进行确认,对失序的数据重新排序,丢弃重复数据;TCP提供端到端的流量控制,并计算和验证一个强制性的端到端检验和。
面向连接意味着两个使用TCP的应用(通常是一个客户和一个服务器)在彼此交换数据之前必须先建立一个TCP连接。这一过程与打很相似,先拨号振铃,等待对方摘机说“喂”,然后才说明是谁。
TCP传输协议连接过程:
首先建立连接,TCP用三个报文段完成连接的建立。这个过程也称为三次握手(three-way handshake)。如图所示:
终止一个连接要经过4次握手。如图所示:
数据发送必须经过接收方确认,并且有超时重传等保障机制,这是TCP传输有一定保障的根本原因。
可以看到,完成一次数据传送,除了完成连接、终止连接外,至少还需要一个数据分组与一个ACK分组。
UDP与TCP提供不同的传输方式与不同的传输质量,TCP以增加网络开销的方式提供传输保障。在GPRS网络实际测试,当网络正常情况下,从GPRS DTU->GPRS网络->互联网->用户数据中心这个通路上,UDP传输有效性>99%,TCP传输有效性≈*
3、传输效率
在只考虑UDP/TCP分组情况下,发送应用数据,数据包为IP头+UDP/TCP头+应用数据。GPRS网络计费按照流量计费,数据传送效率就显得十分重要。由于目前分组数据机费按照网络协议二层以上数据计算(即IP包数据),传输效率计算按照以下公式计算:
包传输效率= 数据长度/(数据长度+UDP/TCP头长度)
数据长度
| UDP效率
| TCP效率
|
8
| 50.00%
| 28.57%
|
16
| 66.67%
| 44.44%
|
32
| 80.00%
| 61.54%
|
64
| 88.89%
| 76.19%
|
128
| 94.12%
| 86.49%
|
256
| 96.97%
| 92.75%
|
512
| 98.46%
| 96.24%
|
1024
| 99.22%
| 98.08%
|
通过协议内容分析,可以看到单包传送的用户数据量比较小时,UDP协议传输效率明显高于TCP协议。行业应用数据量比较小,不同行业应用选择协议时,需要仔细分析应用层数据单帧字节数。
以上只是数据分组的传输效率,TCP协议还需要连接、终止连接、ACK包等额外开销,UDP与TCP实际传送效率差别将远大于上表中的计算效率差别。
4、网络承载能力
GPRS分组业务信道可采用CS-1~CS-4不同的编码方式(其数据速率分别为9.05kbit/s、13.4kbit/s、15.6kbit/s、21.4kbit/s)。采用编码方式为CS-4时,且无线环境良好,信道充足的情况下,可以实现GPRS网络支持的理论zui高速率171.2kbps,这种速率*可以支持一些多媒体图像传输业务等对带宽要求较高的应用业务。但实际数据传输速率受网络编码方式和终端支持的因素影响,CS-3、CS-4的接收参考灵敏度较低,这两种编码方式只有在距离基站较近且信号较好的地区才能够真正使用。
目前,GPRS采用CS-2信道编码方案。保证实现小区的90%以上覆盖,满足C/I不低于9dB的要求。在小区内,提供上下行分别为1~4 GPRS信道(PDCH)。GPRS无线信道的分配初期至少设置一个静态的分组数据业务信道,以后根据GPRS的流量调整PDCH分配。按照话音优先的原则,动态信道将优先分配给话音信道,保证GSM质量。所以GPRS带宽为13.4Kbps~54.4Kbps。
在中国移动GPRS网络上,采用上下行不对称方法分配信道,上行小,下行大,通常为1+2、1+3、2+4等。这主要是为客户访问互联网设置的,而在行业应用中,出现的情况正相反,上行数据大于下行数据。因此,在考虑GPRS网络带宽问题时,应该考虑带宽较窄的上行带宽。
GPRS业务的特点是数据通道共享,这带来了按流量计费的便利,但小区内,终端数量多,数据量大等情况下,终端必须在有限的带宽中竞争,导致掉线率高,上网困难等现象。这也就是GPRS开通一年之久后体现出的新应用特点:GPRS在个人用户市场上竞争力不强,但是在大量的行业数据传输上具有非常强的优势。
有限的带宽资源对应用提出了要求:数据量小、传输效率高。
5、行业应用的需求
GPRS行业应用,无论是电力抄表、管网监测、气象采集、金融业务等,都是终端设备与数据服务器之间的通讯,在提供GPRS传输方式之前,有电台、MODEM(线)、专线、直接电缆连接等方式。这些方式提供的通讯质量差异较大。不同的应用,对传输可靠性的要求是不同的,有的可以接受少量数据丢失,有的必须确保任何数据的不丢失,有的不接受超时效数据。不同的应用中,相同的特点是不依赖传输手段提供的数据保障,终端与数据中心之间有各自的通讯协议,通过误码/超时重传等方法,确保数据的安全准确。
采用UDP协议传送,UDP包等同应用数据包,基本没有额外开销。
TCP协议按照协议窗口进行多包统一确认的方式,可以减少ACK报文的数量,但是在行业应用中,应用的特点是数据量小,发送间隔通常从几秒到几小时之间不等,数据报文之间发送间隔通常超过TCP协议需要的zui大确认间隔,导致几乎每个数据报文都需要在TCP协议中的ACK报文。
在整个应用系统中,传输保障是由应用协议与网络协议共同完成的,要充份选择发挥应用协议与网络协议的优势,达到总的效率zui高、效果的目的。在应用协议中,大多具有基本的传输保障功能,通过应用层协议中超时重传等功能*可以满足对UDP协议中少量丢包情况的处理,按照UDP丢包的概率,重传概率也在1%左右。如果选用TCP协议,将导致数据量大大增加。两种协议传输过程如图所示。
6、其它需要考虑的问题
TCP连接保证数据传输的可靠性,每个具体TCP实现必须选择一个报文段zui大生存时间MSL (Maximum Segment Lifetime)。它是任何报文段被丢弃前在网络内的zui长时间。我们知道这个时间是有限的。RFC 793 [Pos 1981c] 指出MSL为2分钟。然而,实现中的常用值是30秒,1分钟,或2分钟。对于部分实时监控系统,超过时效的数据是没有任何用途。使用UDP连接,当网络拥塞时,部分数据包被丢弃,但可以改善接收数据严重滞后的情况。
GPRS在电力系统中的应用,刚刚起步,处于小规模试用阶段,无论选用UDP还是TCP协议,都对网络及服务器系统不会产生明显压力,使用TCP协议时,可靠的传输显得更为便利。但TCP协议却不适合大规模使用。城市电力配网自动化、抄表等应用,一个系统可能有成千上万台终端,如果选用TCP连接,服务器除了完成大量数据处理功能,还需要完成对大量GPRS终端的TCP连接保持。这对服务器的承载能力提出了严格的要求。
如果终端连接数量大,使用TCP连接协议可能带来更严重的问题。GPRS终端与服务器建立了TCP连接后发送数据后,或者服务器向正在请求连接的终端发出SYN+ACK应答报文后可能无法收到对端的ACK报文,这种情况下发送端一般会重试并等待一段时间后终止这个的连接,一般来说这个时间大约为30秒~2分钟;一个终端出现异常导致服务器的一个线程等待1分钟不是大问题,但如果网络拥塞导致大量这种情况,服务器端将为了维护一个非常大的半连接列表而消耗非常多的资源,即使是简单的保存并遍历也会消耗非常多的CPU时间和内存,何况还要不断对这个列表中的IP进行重试。如果服务器的TCP/IP栈不够强大,zui后的结果往往是堆栈溢出崩溃。即使服务器系统足够强大,也忙于处理TCP连接请求以及重传数据导致系统性能严重下降。大量重传数据进一步加剧GPRS网络的拥塞情况,严重时可以让GPRS网络及服务器系统崩溃。
7、结论
在行业应用中,需要仔细分析行业应用特点,根据需要选择UDP或TCP协议。多点分散、数据量小、实时性要求高、终端数量多的应用,可以考虑UDP的协议。对于一些数据量大、数据可靠性要求十分严格、终端数量较少,以及部分特殊应用,TCP会好一点。