DIY编程器网

标题: 手机电视(DVB-H)软件接收器 [打印本页]

作者: admin 时间: 2014-10-12 22:50
标题: 手机电视(DVB-H)软件接收器
1、简介

手持式数字电视DVB-H（DigitalVideoBroadcasting-Handheld）系统标准规范[1]主要以地面广播系统DVB-T（DigitalVideoBroadcasting-Terrestrial）的架构为核心，再附加新的技术标准以进行规格制定。由于DVB-T系统系利用编码正交分频多任务（CodedOrthogonalFrequencyDivisionMultiplexing，COFDM）之多载波调变技术，对于多重路径（Multi-path）反射效应所衍生出的干扰及衰减问题，能提供有效的处理与抑制能力，因此非常适合使用于行动应用。此外，DVB-H系统标准另外新增的功能与改进的技术有：DVB-H传输参数信号（TransmissionParameterSignaling，TPS）、分时切片（TimeSlicing）、软式交递（SoftHandover）算法、4K模式、深度符号内间插（In-depthsymbolinterleaver）与多协定封装前向纠错机制（Multi-ProtocolEncapsulationForwardErrorCorrection，MPE-FEC）等技术，用来提升手持装置之移动接收性能并克服耗电问题，更透过行动电视条件接收（ConditionAccess，CA）之应用与电子服务指南（ElectricServiceGuide，ESG）等功能来使得所提供的服务内容更为完备并更具保障。

2、相关技术研究

最近对于DVB-H之MPE-FEC机制的研究文章，主要着重于接收端于解封装时，如何对传输串流中的数据进行错误侦测判断、如何提供纠错译码运算时所需的错误信息与如何改善增强MPE-FEC机制对错误的检测修复能力。

目前对于接收端接收数据进行错误侦测与判断的方式，主要能够分为两类，这两类的主要差异点是在于不同层次的封装格式上进行错误侦测与判断，其中一种判断方式是在解传输串流封包时进行，另一种则是在进一步解多协议封装（Multi-ProtocolEncapsulation，MPE）格式时进行，而在DVB-H规范中的建议方式是采用后者，主要是利用循环冗赘核对（CyclicRedundancyCheck，CRC）来对数据进行错误侦测与判断。

另外，对于提供纠错译码运算时所需的错误信息方面，则会根据所提供的错误信息形式上的不同而有不同的纠错译码方式。以上两种方面的各种规划设计概念大多已被整合介绍于一篇研究文章内[2]并主要被分成五种架构，而本研究考虑设计与实作上的便利，故采用所谓的TSE（TransportStreamErasure）的错误侦测方式（即根据TS封包标头内的错误指标字段来进行正确性判断），而于RS译码部分则是采用欧几里得（Euclid）方式来进行RS纠错译码。

3、数字电视广播系统核心技术简介

3.1DVB-H传输系统结构与封装格式

DVB-H传输IP服务的传输系统如图1所示。DVB-H的服务数据封装成IP封包之后，再透过MPE机制封装于传输串流之中，并同时加入Time-Slicing信息后与其它DVB-T的电视节目（MPEG-2TVService）经由多任务器多任务成一个更大的传输串流（又称复合节目串流，MultipleProgramTransportStream），再调变成无线信号送出，其中在发送端的MPE、MPE-FEC与Time-Slicing机制合称为DVB-HIP封装器（IP-Encapsulator），而在接收端的反向解回部份则称为DVB-HIP解封装器（IP-Decapsulator），而整个DVB-H的封装格式则如同图2所示。

图1 DVB-H传输IP服务的传输系统[3]

当影音压缩与其它服务数据经过一连串的封装之后，最后将被封装成传输串流（TransportStream）的封包格式，而在接收端将再其递送给底层硬件进一次所罗门编码后，才将封包调变成无线讯号送出。相对地在接端接收到封包时，将先进行一次所罗门译码，而将译码的结果记录在封包标头中。

图2DVB-H数据封装格式

3.2Time-Slicing传输机制与时间参数

Time-Slicing传输机制的目的在于降低手持式终端设备的平均能源消耗与实现SoftHandover机制在基地台间平滑交接。Time-Slicing传输机制如图3所示，系以瞬间高流量脉波传输（Burst）的方式传输数据。

图3Time-Slicing传输机制的Burst传输方式

另外，为了让接收端设备能正确地接收每一个Burst数据，故在Burst中夹带时间卷标（Delta-T）信息来指出下一个Burst到达的时间（如图4），而接收端则预先提早Delta-TJitter的时间来打开接收器，以便能正确地接收数据，介于两个Burst中间的OffTime时间则不传输任何数据，藉由此种频宽分享方式来传递其它不同服务的数据。整个Burst在传输数据时有个最大持续时间（MaxBurstDuration）而这个信息也一并被夹带于整个传输流中传送。

图4时间参数Delta-T示意图

3.3MPE-FEC机制原理与运作

MPE-FEC机制在DVB-H系统中负责进行错误数据修复动作，整体技术是建构于一个名为MPE-FEC框架的方形内存装置之中。如图5，此框架又被定义成两部份称为：ApplicationDataTable与RSDataTable，其分别用来存放DVB-H系统中传送的服务数据与纠错冗余编码数据。

图5MPE-FEC框架

如图6，在发送端透过纵向填入数据与横向纠错编码来完成交织编码的编码方式再进行封装传送。而在接收端接收后则进行反向的纠错译码动作，藉此来修复因传输所发生的数据错误。

图6 MPE-FEC框架交织编码方式

4、 DVB-H软件接收器系统设计

DVB-H接收器的详细软件架构如图7所呈现，主要由传输串流分派器（TransportStreamDispatcher）、子译码器（SubDecoder）组件、控制器（Controller）对象与MPE-FEC运算单元（MPE-FECOperationUnit）所组成。

图7DVB-H接收器软件架构

4.1传输串流分派器

传输串流分派器主要负责将DVB-H传输串流中各种类型的封包转递给不同的子译码器进行处理并从封包中过滤使用者所欲观看的节目传递给DVB-H终端装置。若在Burst传输期间，封包数据因噪声干扰而损毁，或者传送端于传送时为符合服务的传输位率而添加一些填塞封包，因此为减少封包的处理时间，故在传输串流分派器取得封包之后，便先检查此流封包是否发生错误与是否为填塞封包，若发生错误，则将封包丢弃，而整个执行程序将进入到错误分类机制（ErrorCategorizationmechanism）中，若为填塞封包则即早丢弃，避免填塞封包送入子译码器中花费不必要的处理时间。为简化子译码器的复杂度，传输串流分派器系使用分派表方式来注册欲译码的封包子译码器类型，并藉此分离各个子译码器之间的相依关系。分派表系采用杂凑表（Hashtable）的一种应用，使用杂凑表的优点在于不论注册数量的多寡，查询时间花费永远固定为常数值，因此将可广泛支持未来规范中新增的窗体或电视台所自订的私有窗体。而整个传输串流分派器的分派处理动作则如表1的虚拟程序代码（Pseudocode）所示。

表1 传输串流分派器之虚拟程序代码

If System Start then

Set Buffer to receive TS packet

If ErrorIndicator is equal to 1

Drop this TS packet

Start Error Categorization mechanism

else if PID is equal to 8191

Drop this TS packet

else if PayloadUnitStartIndicator is equal to 1

If ContinueSection is not equal to Null

Call the sub-decoder to continue decode

else

If sub-decoder is not found

Drop this unknown TS packet

else

Call the sub-decoder to decode

else

If ContinueSection is not equal to Null

Call the sub-decoder to continue decode

else

Drop this TS packet

4.2子译码器组件

于初始化时期，子译码器必须向传输串流分派器注册封包类型，以便从传输串流分派器中得到相对应的封包。

表2子译码器共通虚拟程序代码

Function：DecodeFunction

从传输串流分派器中取得section中的第一个封包并译码。

Set PayloadBuffer to receive the section data

Set PaylaodLength equal to PacketPayloadLength

If SectionHeaderLength is equal to 12

Decode the section header

If section payload is not equal to Null

Output section payload to

SectionPayloadCottectionUnit

else

Set ReceiveLength equal to PayloadLength

Set ContinueSection to this sub-decoder

Function：ContinueFunction

从传输串流分派器中取得接续的section封包资料。

Set PayloadBuffer to receive the section data

Set PayloadLength equal to PayloadLength add

ReceiveSectionPayloadLength

If SectionHeaderLength is equal to 12

Decode the section header

If section payload is not equal to Null

Output section payload to

SectionPayloadCottectionUnit

If PayloadLength is equal to SectionLength

Set ContinueSection to Null

else

Set ContinueSection to this sub-decoder

子译码器共通的虚拟程序代码如表2所示，传输串流分派器则根据分派表中已经注册的子译码器信息来递送封包给特定子译码器，子译码器则根据封包中所传达的数据将讯息或组态释出，并传递给控制器对象。当子译码器藉由解读section的长度字段得知该section数据长度超过一个封包所能承载的数量时，会将接续片段指针对象设定指向自己。此后，当传输串流分派器接收到封包后，将会检视接续片段指针对象是否为空对象，若为空对象则从分派表中寻找负责解碼此封包的子译码器。若非空对象，则将封包传送给欲接续接收的子译码器，直到整个section数据接收完成之后，子译码器才会将接续片段指针对象重设为空对象，而从下一个封包开始，将以正常程序寻找封包子译码器。

4.3控制器对象

控制器对象为DVB-H软件接收器与使用者互动的接口。控制器的主要功能除了撷取使用者的输入讯息之外，也实作讯息输出接口。在控制行为部分，控制器仅与子译码器互动，在讯息输出方面，则是与整个DVB-H软件接收器中的所有组件连结在一起。另外，在实作设计上则不同于传统将控制接口嵌入于播放器的作法，藉由此方式达到DVB-H软件接收器与播放装置各别独立的能力。

4.4MPE-FEC运算单元

MPE-FEC运算单元主要负责进行整个MPE-FEC机制的运作，如图8而其又可分为三个运作单元，分别为：MPEsection数据收集单元、FECsection数据收集单元与所罗门译码单元（RSDecodingUnit）。

其中MPE与FECsection数据收集单元主要负责收集从子译码器解读取出的section数据，当完成section数据收集后即填入位于所罗门译码单元中的MPE-FEC框架中，直到整个框架的所有section数据均已收集完成，则立即进行每列的所罗门纠错译码，藉此来修复于传输时因噪声干扰所造成的数据错误。

4.5错误产生、侦测与分类机制

当接收端硬件接收到由传送端所传送的传输串流封包时，硬件会先对封包进行一次所罗门译码，若是超出其纠错解碼能力时，将会把封包标头内的错误指标字段（ErrorIndicator）设定为1，藉此来标示发生错误的封包，而本研究于错误侦测判断时，即是根据此标头字段值，并透过设定此字段值来产生显著的错误数据，以突显MPE-FEC机制的运作。当发现错误封包之后，将立即执行错误分类机制来找出错误发生在整个section的哪个区段并在一个与MPE-FEC框架相同大小的ErrorBit-mapBuffer（EBB）中的相对应位置设成1来表示其在框架中的错误位置，以便提供往后所罗门译码所需的错误位置数据，而整个错误分类机制的虚拟程序代码如表3所示。

表3 错误分类机制虚拟程序代码

If ErrorIndicator is equal to 1

If HeaderDecoded is true

If error at middle of section

Set 1 in EBB according to the TS payload

region of this section in MPE-FEC frame

Drop this TS packet

else

If packet carry part of next section header

Set 1 in EBB according to the TS payload

region of this section and whole the next

section payload region in MPE-FEC

frame

Drop this TS packet and drop all TS

packets of next section

else

Set 1 in EBB according to the TS

payload region of this section in

MPE-FEC frame

Drop this packet

else

Set 1 in EBB at whole section payload

　　 region in MPE-FEC frame

Drop all TS packets of this section

当传输串流分派器收到封包并立即侦测与判断封包标头中的错误指标字段是否为1，若为1则表示发生错误而进一步开始找出此错误封包所载送的数据是位于整个section的哪个区段位置，若是发生在section标头部位，由于标头是载送整个section最重要的信息来源位置，因此为了能正确地接收往后的section，故当发生错误的封包包含任一字节的标头信息时，将会将整个section数据完全丢弃而等待下一个正确载送section标头的封包进来。如果发生错误的封包是载送标头信息之外的部份时，则再进一步判断封包中载送的数据范围是位于整个section数据的哪个区段，若仅是中间部位，则只丢弃该封包而等待下一个正确封包即可，但若是section末端数据的话，则需再进一步的判断是否包含到下一个section标头信息，如果有的话，则一并把载送下一个section数据的所有封包丢弃而等待下一个正确载送section标头的封包进来，反之则一样仅丢弃该封包即可。

4.6Time-Slicing传输机制设计

DVB-H传送数据的方式是采用Burst传输方式，采用此种方式时，则必须精确地得知下一个Burst的抵达时间与传输该Burst数据的最大传输时间，才能让硬件能于正确时间点开关接收器来接收数据，而接收端在接收数据时，必须满足两个时间要求：

（1）当Burst到来，并接收到第一个MPEsection进行解读时，section标头必须在Delta-TJitter时间内解碼并将Delta-T值回传到实体层。

（2） IP解封装器必须于Delta-T时间内完成所有section的译码与MPE-FEC机制的运作，并将数据输出到终端。

由于未必能在Burst的最大维持时间内将所有section数据解读完成，故接收端必须以缓冲器暂存整个Burst时间内的所有section封包，而封包的译码工作在剩余的Delta-T时间内完成即可。

除此之外，由于在处理的过程中使用缓冲器来暂存section封包数据，而再取出解读时，其标头中所挟带的实时性Delta-T信息已失效，仅有解读第一个MPEsection所造成的延迟时间最为短暂。

因此，在实作上即采用第一个MPEsection标头所挟带的Delta-T信息来告知实体层下一个Burst的到来时间，而其余section标头内的Delta-T信息将不被读取采用。整个section封包处理延迟时间示意图即以图9呈现。

图9 section封包处理延迟时间示意图

5、实验模拟结果

本研究整个实验模拟结果均是利用个人计算机（PC）进行测试，个人计算机的配备如表4所呈现，并以公视试播计划所提供的传输串流当作是播放测试档案，而表5则是从公视所提的串流档案撷取出来的信息。

5.1正确性验证

本研究纠错后的数据验证是利用文字处理软件Ultra-Edit所提供的二进制档案比对来完成，分别将添加错误的每个Burst数据与修正后的数据存成档案后再与验证档案进行比对。

5.2效能评估

本文的MPE架构与Time-Slicing传输机制设计主要采用[4]的观实作观念与架构，[4]中对每个Burst数据（仅有针对MPEsection）的处理时间已有相当完整的分析信息，故本论文即针对主要设计的MPE-FEC纠错机制做实作上的效能分析与探讨。

表4个人计算机基本配备表

处理器厂牌规格
Intel Pentium 4

处理器处理速度
3.0 GHz

硬盘大小
80 GBytes

内存容量
512 MBytes

表5公视影像来源参数数据

参数
数值

档案大小
755,605,652（bytes）

封包总数
4,019,179（封包以188个bytes为单位）

MPE-FEC框架总列数
512列

Delta-T
1250 ms

Delta-T Jitter
7.5 ms

最大Burst持续时间
200 ms

省电效率
79.7%

每秒画面更新速率
15 （frame per second,

整个传输流档案中，每个Burst所挟带的框架大小为255×512，而框架资料量大小为1Mbits（128kBytes），每个MPE-FEC框架执行的RS纠错运算次数为512次（即每一列执行一次RS纠错运算），编码率（coderate）为2/3的情况条件下，10个Burst、50个Burst与100个Burst单纯使用Java以及RS译码采用Euclid算法在Windows上的完整MPE-FEC纠错机制与单纯RS译码的平均执行时间如图13所示。

图13完整MPE-FEC机制运作与单纯RS解码的平均执行时间

由图13可知整个MPE-FEC机制的运作时间大多花费在RS译码上，因此本研究进一步将RS译码使用C/C++并且使用RS内部不同的译码算法透过Java的JNI（JavaNativeInterface）呼叫在Windows上执行完整的MPE-FEC机制，其执行解果如图14所呈现。

图14Java与C/C++以及不同算法在Windows上的平均执行时间

虽然就执行时间上来看，使用C/C++并采用BM算法的译码时间较短，但对于表5所撷取到的Delta-T时间（1250毫秒）而言，仍无法达到DVB-H接收端的实时播放。因此，再进一步测试在Linux系统上不同算法的C/C++语言执行时间并与Windows的执行时间汇整而得到图15。

图15不同操作系统下，C/C++使用不同算法的执行时间

在Linux操作系统上执行完整的MPE-FEC机制运作后所得到的平均执行时间均小于在Windows上的执行时间。此外，使用BM算法在Linux与Windows上的执行时间更相差约略2.5秒，并且已能符合DVB-H接收端实时播放的时间要求。

最后在Windows将测试档案加入错误后，再透过本研究所设计的软件系统进行纠错之后所得的数据存成档案再进行播放。

6、结论

本研究利用纯软件的方式来仿真实作DVB-HMPE-FEC纠错机制，并确实能修复还原添加于测试档案中的错误，虽然于Windows操作系统上的数据处理时间已超过实时播放的时间要求，但在Linux上采用BM算法的RS译码测试实验结果，却已符合实时播放的限制条件。因此，以系统的执行时间及实时播放的角度来看，对于往后的软件设计实作，在Linux上实现，或许会比在Windows上更为理想。

欢迎光临 DIY编程器网 (http://diybcq.com/)