技术领域
[0001] 本
发明涉及通信技术领域，尤其涉及基于城市轨道乘客信息系统的音视频数据包包长调整方法。
背景技术
[0002] 在城市轨道交通系统工程中，乘客信息系统(Passenger Information System，以下简称PIS)的一个重要功能是地
铁列车上的音视频直播。要实现该功能，首先需要在PIS控制中心的
编码器将直播
信号进行音
视频编码。
[0003] 编码器在对直播信号编码后，按照DVB标准将直播数据打包成UDP包，并以组播的方式输入到PIS网络。音视频直播数据包通过LTE车地无线网络传输到列车，并由车载播放
控制器解码播放。
[0004] 该线路建设的1.8GHz频段LTE车地无线网络能够提供的总数据带宽大约为8Mbps，包括上下行，但是需要同时承载信号系统、视频
监控系统、PIS三个业务。
[0005] 音视频编码数据的特点是数据量很大，按照PIS的功能要求，列车音视频直播的编码码率一般要求达到2～6Mbps，而LTE车地无线网络承载的三个业务中，除了信号系统的数据码率较低外(Kbps量级)，其他两个业务都是音视频业务，都要求较高的带宽来传输。信号系统是列车行进控制的安全保障系统，在三个业务中优先级是最高的，视频监控系统则是安防反恐的重要辅助手段，优先级次之，PIS业务是三个业务中优先级最低的。
[0006] 由于无线网络无法做到有线网络那么稳定可靠，在传输数据的过程中会由于信号干扰导致数据丢失，因此为了能够有效的在LTE车地无线网络上传输UDP形式的直播音视频数据包，应该避免一个音视频编码UDP数据包被网络拆分成两个包传输，否则一旦其中的一个拆分包丢失，就会导致整个音视频编码UDP数据包丢失。
[0007] 车载上进行音视频解码播放时，如果发生数据包丢失的情况，会导致卡顿和
马赛克现象，影响到乘客的观感体验，数据丢的越多，卡顿和马赛克现象就越严重。因此在遇到数据包丢失时，需要将丢失的数据包补充回来。如果补充的数据包也被拆分传输的话，势必会占用更多的带宽。
发明内容
[0008] 本发明旨在解决在LTE车地无线网络上传输UDP形式的直播音视频数据包时受到信号干扰出现音视频编码UDP数据包被网络拆分成两个包传输而导致数据丢失的问题。
[0009] 为了实现上述目标，本发明采用以下的技术方案：本发明提供了基于城市轨道乘客信息系统的音视频数据包包长调整方法，其特征在于包括以下步骤：
[0010] (1)在
操作系统中设定不拆分
定位标记位；
[0011] (2)将一个
指定大小的数据包不经过拆分发往目的端，判断是否能够
送达：
[0012] 若未能送达则获得最大传输单元大小；
[0013] 若能够送达则发送的数据包加一个字节，重复该步骤直至数据包不能送达至目的端，获得最大传输单元大小；
[0014] (3)计算最大传输单元能够容纳TS包个数；
[0015] (4)用TS流的数据包包长乘以最大传输单元能够容纳的TS包个数即得到音视频编码UDP数据包大小。
[0016] 本发明所达到的有益效果：本发明基于城市轨道乘客信息系统的音视频数据包包长调整方法，使得数据包在网络层传输时不需要拆分，对于提高整个LTE网络利用效率是非常重要的，避免重新传输丢失的数据包，可以确保音视频解码的流畅性。
附图说明
[0018] 图2是UDP/IP包结构示意图；
[0019] 图3是UDP包结构示意图。
具体实施方式
[0020] 为了使本发明的目的、技术方案及优点更加清楚，下面对本发明作进一步描述。应当理解，以下
实施例仅用于更加清楚地说明本发明的技术方案，而不能以此来限制本发明的保护范围。
[0021] UDP是User Datagram Protocol的简称，中文名是用户数据报协议，是OSI(Open System Interconnection，开放式系统互联)参考模型中一种无连接的传输层协议，提供面向事务的简单不可靠信息传送服务，IETF RFC 768是UDP的正式规范。UDP在IP报文的协议号是17。
[0022] UDP协议与TCP协议一样用于处理数据包，但是不一样的是，UDP是一种无连接的协议。UDP协议直接位于IP(网际协议)协议的顶层。根据OSI(开放系统互连)参考模型，UDP和TCP都属于传输层协议。UDP协议的主要作用是将网络数据流量压缩成数据包的形式。一个典型的数据包就是一个二进制数据的传输单位。每一个数据包的前8个字节用来包含报头信息，剩余字节则用来包含具体的传输数据。
[0023] UDP报文没有可靠性保证、顺序保证和流量控制字段等，可靠性较差。但是正因为UDP协议的控制选项较少，在数据传输过程中延迟小、数据传输效率高，适合于传输音视频数据。UDP包在IP包中的
位置图2所示。
[0024] UDP报头由4个域组成，其中每个域各占用2个字节，具体如图3所示。
[0025] 端口号分为源端口号和目的端口号，用于描述发送端和接收端应用的数据通道。UDP长度是指包括报头和数据部分在内的总字节数。由于包头长度是固定的，所以该域主要被用来计算数据部分的长度。从理论上说，UDP长度域占用16比特位，因此包含报头在内的数据报的最大长度为2^16＝65535字节。
[0026] 图1是本发明方法的流程图；在图1中示出了本发明方法的流程：具体包括：
[0027] (1)在操作系统中设定不拆分定位标记位；
[0028] MTU(Maximum Transmission Unit，最大传输单元)是指一种通信协议的某一层上面所能通过的最
大数据包大小，对于TCP/IP来说，就是TCP包和UDP包的最大大小(以字节为单位)，虽然上面提到UDP包的最大长度为65535字节，但那是面向应用层，对于网络层，如果一个数据包超过了MTU，虽然该数据包也能继续传输，但是会被网络层驱动拆分成一个个不超过MTU的数据包再传输，然后在接收端在重新组合成完成的数据包。在传输的过程中，即使仅仅一个拆分的小包丢失，也会导致整个数据包被丢弃。
[0029] 因此，在PIS中实现车载音视频直播时，打包形成的UDP包不应该超过MTU大小，以提高传输的效率。
[0030] 进一步地，在windows和linux两大主流操作系统中，socket是网络数据通信的具体实现，通过设定DF标记位(don't fragment flag，意思是不拆分)可以将一个指定大小的数据包不经过拆分发往目的端，如果该数据包能够送达，说明网络MTU比该数据包大小大，可以再尝试发送更大的数据包。
[0031] Windows系统：
[0032] int val＝1；
[0033] setsockopt(sd,IPPROTO_IP,IP_DONTFRAG,&val,sizeof(val))；
[0034] linux系统：
[0035] int val＝IP_PMTUDISC_DO；
[0036] setsockopt(sd,IPPROTO_IP,IP_MTU_DISCOVER,&val,sizeof(val))；
[0037] (2)将一个指定大小的数据包不经过拆分发往目的端，判断是否能够送达：
[0038] 若未能送达则获得最大传输单元大小；
[0039] 若能够送达则发送的数据包加一个字节，重复该步骤直至数据包不能送达至目的端，获得最大传输单元大小；
[0040] (3)计算最大传输单元能够容纳TS包个数；
[0041] 为了进一步说明计算最大传输单元能够容纳TS包个数；以下为本发明的一个实施例。
[0042] 编码器通过上述方法探测到MTU大小后，首先需要计算出留给负载的数据长度，
算法如下：
[0043] length＝MTU–IP包长–UDP包长，
[0044] 其中IP包长为20字节，UDP包长为8字节。
[0045] 对于普通以太网来说，MTU一般为1500字节，那么留给负载的数据长度为：
[0046] length＝1500–20–8＝1472，
[0047] 按照DVB标准，TS流由一个个数据包构成，TS包包长有188、204个字节，一般188包长的应用较多。因此，一个MTU包能够容纳的TS包个数如下：
[0048] 需要说明的是这里length/TS包长采用向下取整。
[0049] 在普通以太网中，计算如下：
[0050]
[0051] (4)用TS流的数据包包长乘以最大传输单元能够容纳的TS包个数即得到音视频编码UDP数据包大小。
[0052] 因此，普通以太网中，实际的音视频编码UDP数据包大小为：
[0053] size＝7*188＝1316
[0054] 本发明方法在南京宁高线的LTE车地无线网络在实际实现时，经探测，其MTU为1500。为了比较音视频编码的UDP数据包在拆分和不拆分情况下的数据传输效率，专
门对编码器的输出设置了两种UDP包长，并测试两种情况下的数据传输情况，结果表1。
[0055] 表1
[0056]序号 包长 拆分 传输量 总数据包数 丢失包数 丢失比率
1 1316 否 100MB 79679 75 0.094％
2 1504 是 100MB 69719 111 0.16％
[0057] 不管传输任何数据，在LTE网络中，对于1316包长，总数据包个数为79679，由于不需要拆分，对于LTE网络来说，数据包个数也是79679；然而对于1504包长来，总数据包个数为69719，虽然少了，但是对于LTE网络来说，由于需要拆分，实际的数据包个数变成了69719*2＝139438。拆分的数据包，一旦其中一个丢失，整个数据包就会丢弃，因此在LTE网络层丢包率基本一致的情况下，1504包长的数据丢失率更高是正常的。
[0058] 本发明调整音视频数据包包长，使得数据包在网络层传输时不需要拆分，对于提高整个LTE网络利用效率是非常重要的，避免重新传输丢失的数据包，可以确保音视频解码的流畅性。
[0059] 以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明技术原理的前提下，还可以做出若干改进和
变形，这些改进和变形也应视为本发明的保护范围。
