CN102684833B

CN102684833B - 分组传输装置、通信系统

Info

Publication number: CN102684833B
Application number: CN201210120701.XA
Authority: CN
Inventors: 久礼嘉伸; 川田雅人
Original assignee: Sony Corp
Current assignee: Sony Corp
Priority date: 2005-11-09
Filing date: 2006-11-09
Publication date: 2015-07-22
Anticipated expiration: 2026-11-09
Also published as: TW200737845A; US8516346B2; KR101242663B1; US7958435B2; CN101026553A; EP1786136B1; JP4513725B2; KR20070049976A; CN102684833A; US20120278677A1; US20070079222A1; DE602006015141D1; CN101026553B; US20110231727A1; TWI337026B; JP2007134836A; EP1786136A1; US8234548B2

Abstract

用以通过尽力型网络传输限制了达到期限的分组的分组传输设备包括：分组自动重传部分，用于控制未交付分组的重传；前向纠错编码部分，用于添加冗余分组到数据分组块；以及冗余度确定部分，用于基于观察到的网络状态信息动态确定该冗余分组的冗余度，使得仅通过未交付分组的重传实现的接收机端的纠错后丢失率满足纠错后允许丢失率。

Description

分组传输装置、通信系统

本申请是申请日为2006年11月9日，申请号为200610130952.0，发明名称为“分组传输装置、通信系统和程序”的发明专利申请的分案申请。

相关申请的交叉引用

本申请包含2005年11月9日在日本专利局提交的日本专利申请JP2005-324224涉及的主题，在此全文引用作为参考。

技术领域

本申请涉及适合于通过尽力型网络传输限制了达到期限的分组的情况的技术。

由本申请的发明人提出的发明涉及分组传输装置、通信系统和程序等方面。

背景技术

最近，通过尽力型通信网络传输多媒体数据的机会不断增加。在这种类型的数据传输中，使用下载传输系统或流传输系统。

作为尽力型通信网络，例如，最常见的有因特网。另外，多媒体数据包括，例如，视频文件、音频文件、两种文件的组合数据，以及部分包括这些数据的数据。在本说明书中，多媒体数据用于表示包括时间信息或涉及播放顺序的信息的数据。

在下载传输系统中，数据文件从交付服务器（deliver server）下载到接收机的记录区，并且在传输完全结束的时间点，开始其播放。因此，下载传输系统不适于播放需要长时间播放的多媒体数据，也不适于播放需要实时播放的多媒体数据。

另一方面，在流传输系统中，数据文件的播放只要部分数据从发送机（sender）传输到接收机时就开始了。因此，这种技术被用于因特网电话、远程视频会议、视频点播、网络摄像机、因特网电视以及其它业务。

作为适用于流传输系统的因特网技术，有由IETF RFC3550定义的RTP（实时传输协议）系统。在借助RTP系统的数据传输中，时间戳作为时间信息被插入到分组当中。这样，发送机和接收机之间的时间关系的控制成为可能，而且同步播放成为可能，而不会受到分组传输时的延迟波动（抖动）等的影响。

在此，在RTP系统中，实时数据传输是没有保证的。事实上，分组传输的优先权的设置、管理等不在RTP提供的传输业务的范围之内。因此，在RTP分组的情况下，类似于其它分组，还是有可能发生传输延时或分组丢失。

即使发生这样的情况，接收机只要利用在期望时间内已经到达的分组，就能再现该数据。

这是因为即使在视频数据或音频数据中存在少量的数据丢失，在一定程度上播放还是可以执行。

另外，在接收机中，延迟交付的分组或出错的分组被丢弃。也就是说，存在这样的问题，即使传输装置交付了高质量的数据，但当分组丢失或错误出现时，在接收机也无法执行播放。

尤其是，在现有的通信环境中，据说即使在有线部分内也存在10^-5的误差，而在无线部分存在10^-3或更多的误差。因此，考虑到品质维持，即使RTP系统单独用于多媒体数据的交付，也不能期待足够的可靠性。

于是，有可能应用高可靠性的TCP（传输控制协议）系统。

然而，虽然TCP能够防止出错，但是其吞吐量很低，延迟很大，不适用于流传输。

于是，通过利用RTP系统作为改进数据传输的可靠性的方法，研究将自动重传系统（这里也称为“ARQ（自动重复请求）系统”）和前向纠错编码系统（这里也称为“FEC（前向纠错）系统”）组合到一起。

在ARQ系统中，丢失的分组通过RTP分组的序列号被检测到，而接收机向发送机请求重传丢失的分组。

在FEC系统中，多个分组被做成FEC块而且利用Reed-Solomon（RS：Reed-Solomon编码）或其他纠错编码进行冗余编码。例如，在使用（n，k）RS编码的情况下，在冗余编码之前，可以从k个原始分组中产生n-k个冗余分组。而且，n＞k成立。在这种情况下，从传输装置中发送总共n个分组。另一方面，在接收装置中，当可以接收n个分组中的k个分组时，可以通过 RS解码处理恢复k个原始分组。

[专利文献1]JP-A-2000-188609

发明内容

然而，ARQ系统和FEC系统都分别存在下述的问题。

在ARQ系统中，在允许播放延时（分组传输时间和分组播放时间之间的间隔）相对于往返时间（RTT）不够大的情况下，由于在这期间重传请求处理和分组重传请求无法完成，原始影响就无法体现了。

在FEC系统中，由于在FEC块中即使只丢失了一个分组也无法执行解码处理，为了使分组恢复速率与ARQ系统相等，需要比ARQ重传分组传输更多的冗余分组，就出现了增加网络的拥塞这样的问题。而且，还有一个问题就是，原始数据的传输速率不必要地减少了。

那么，本发明人提出使得未交付分组的重传系统（ARQ系统）和前向纠错系统（FEC）有效地共同操作的传输技术。

也就是说，提出了在通过尽力型网络传输限制了到达期限的分组的分组传输设备中提供以下处理功能的传输技术：

（a）分组自动重传功能，控制未交付分组的重传。

（b）前向纠错编码功能，添加冗余分组到数据分组块。

（c）冗余度确定功能，基于观察到的网络状态信息动态确定添加到数据分组块中的冗余分组的冗余度，使得仅通过未交付分组的重传实现的接收机端的纠错后丢失率满足纠错后允许丢失率。

根据发明人提出的本发明的实施例，冗余分组的冗余度可以根据网络状态来优化。这样，无须不必要地提高网络拥塞或者不必要地降低数据分组块的传输总量，接收机端的纠错后丢失率也可以保持在允许范围之内。

附图说明

图1是示出了构成通信系统的传输设备的结构示例的视图。

图2是示出了构成通信系统的接收设备的结构示例的视图。

图3是示出了在传输设备中执行的FEC处理的示例的视图。

图4是示出了在接收设备中执行的FEC处理的示例的视图。

图5是示出了ARQ处理的时序示例的视图。

图6是示出了在传输设备中执行的ARQ处理的示例的视图。

图7是示出了在接收设备中执行的ARQ处理的示例的视图。

图8是示出了冗余表的示例的视图。

图9是示出了冗余度确定处理的示例的视图。

图10是示出了实施例1中执行的冗余度控制映像的视图。

图11是示出了构成通信系统的传输设备的结构示例的视图。

图12是示出了冗余表的示例的视图。

图13是示出了冗余度确定处理的示例的视图。

图14是示出了实施例2中执行的冗余度控制映像的视图。

具体实施方式

下面将描述提供本发明的传输技术的通信系统的实施例。

附带地，在这个技术领域内的公共或公知技术被应用到本发明的一部分中，而在本发明的说明书中没有特别地说明或描述。

而且，下面描述的实施例只是本发明的实施例而已，而本发明并不受限于这些实施例。

（A）实施例1

在这个实施例中，将描述通过因特网执行视频数据的流传输的通信系统。

而且，在这个实施例中，假设对分组的总传输速率没有限制。在本说明书中，总传输速率就是视频数据分组块的传输速率、纠错分组的传输速率和重传分组的传输速率的总和。

附带地，视频数据分组块、纠错数据、重传数据分别对应于权利要求的“数据分组块”、“冗余分组”和“未交付分组”。

（A-1）系统结构示例

图1和图2示出了构成通信系统的传输设备和接收设备的结构示例。图1和图2示出了通信系统100包括传输设备200和接收设备300的情况。

传输设备200（图1）包括编码部分201、分组部分203、FEC编码部分205、RTP传输部分207、ARQ部分209、RTCP（RTP控制协议）部分211和冗余度确定部分213。

ARQ部分209对应于分组自动重传功能，用以控制重传分组的重传。FEC编码部分205对应于前向纠错编码功能，用以将纠错数据添加到视频数据分组块中。

冗余度确定部分213对应于冗余度确定功能，用以基于观测到的网络状态信息，动态确定添加到视频数据分组块的冗余分组的冗余度，使得仅通过未交付分组的重传实现的接收机端的纠错后丢失率满足纠错后允许丢失率。

在本实施例的情况下，网络信息作为往返时间RTT和分组丢失率给出。虽然网络信息可以只给出往返时间RTT，但是这样描述的网络状态的精确性不如增加了分组丢失率的情况。

所有其它通信处理功能应用的是已知技术。

接收设备300（图2）包括RTP接收部分301、拆包部分303、解码部分305、丢失检测部分307、FEC解码部分309、ARQ部分311和RTCP部分313。

已知技术被应用到所有这些通信处理功能中。RTCP部分313是用以周期性地发送RTCP分组的处理功能部分，用于传输设备200的传输速率等的调整。作为RTCP分组，例如，分组丢失率或NACK分组被发送。

（A-2）处理算法

下面，将在通信系统100中执行的处理算法分成正常传输处理和纠错处理，并进行描述。

（a）正常传输处理

传输设备200通过输入界面V_IN连接到图像输出设备，例如视频摄像机。通过V_IN输入的视频数据在编码部分201经过压缩处理，然后传递到分组部分203并经过RTP分组。

然后，在FEC编码部分205，纠错数据被添加到视频数据中。

也就是说，视频数据被FEC冗余编码。FEC冗余编码数据被传递给传输部分207，并作为RTP分组发送到因特网中。

接收设备300通过RTP接收部分301接收RTP分组，并且在拆包部分303将其重新构造成压缩的视频数据。然后，解码部分305解除重新构造的压缩视频数据的压缩处理。解码视频数据通过视频输出接口V_OUT输出到视频播放设备，例如显示器。

（b）纠错处理

纠错处理将分成三个部分进行描述，即“FEC处理”、“ARQ处理”和“冗余度确定处理”。

在FEC处理中，FEC系统的冗余编码、以及解码处理被执行。而且，在 “ARQ处理中”，ARQ系统的重传控制被执行。而“冗余度确定处理”中，从网络状态信息确定FEC的冗余度、ARQ重传分组的总量、诸如视频数据的数据分组块的数据速率。“冗余度确定处理”是本说明书中提出的传输技术的主要部分。

（b1）FEC处理

在“FEC处理”中，传输设备200中，基于“冗余度确定处理”确定的冗余度的原始数据的冗余编码处理被执行。另一方面，在接收设备300中，解码处理被执行。对于FEC冗余编码，丢失的纠错码，例如，Reed-Solomon编码被使用并且冗余度编码处理被执行。

从“冗余度确定处理”得到的冗余度用（原始数据分组的数量，冗余分组的数量）的格式描述。

在本说明书中，一对（原始数据分组的数量，冗余分组的数量）作为一个冗余编码单元，即所谓的FEC块。例如，当给出（原始数据分组的数量，冗余分组的数量）=（10，5），在传输设备200中FEC处理为10个原始数据分组创建5个冗余分组，而总共15个分组在FEC块中传输。在接收设备300中，当在FEC块中接收到10个分组，原始数据就可以被FEC解码处理解码了。

图3和图4示出了“FEC处理”中执行的处理过程。图3示出了传输设备200中的处理过程，图4示出了接收设备300中的处理过程。

在传输设备200中的FEC编码部分205首先判断是否要结束FEC处理（S1）。

在处理S1中得到否定结果的情况下，FEC编码部分205判断是否获得了从分组部分203输入的视频数据分组块的传输分组（S2）。

在处理S2中得到否定结果期间，FEC编码部分205重复处理S1和处理S2的判断处理。

另一方面，在处理S2得到肯定结果的情况下，FEC编码单元205从冗余度确定部分213获取用于FEC处理的冗余分组的数量（S3）。

然后，FEC编码部分205基于获取的冗余分组数量，对传输分组进行冗余编码，并交付该编码结果到RTP传输部分207（S4）。

另一方面，在接收设备300中的FEC解码部分309首先判断是否要结束FEC处理（S11）。

在处理S11获得否定结果的情况下，FEC解码部分309接收在接收缓冲器中的分组，并更新FEC数据库（S12）。

然后，FEC解码部分309判断是否可以由所接收到的分组执行FEC解码（S13）。

在处理S13得到否定结果期间，也就是说，直到FEC解码变成可能，FEC解码部分309将重复处理S11和处理S12的判断处理。

另一方面，在处理S13得到肯定结果的情况下，FEC解码部分309执行解码处理，并返回解码分组到接收缓冲器（S14）。

然后，FEC解码部分309提供FEC恢复信息到ARQ部分311，并从NACK列表中删除该经解码分组（S15）。这些处理重复地执行，直到确认FEC处理结束。

（b2）ARQ处理

在“ARQ”处理中，将用以请求重传丢失分组（未交付分组）的重传请求分组（即，NACK分组）从接收设备300发送到传输设备200。在传输设备200中，执行由NACK指定的序列号的未交付分组的重传处理。

丢失分组的检测由接收设备300的丢失检测部分307执行。丢失检测部分307检测，例如，在RTP分组报头列举的序列号，而且在接收到的RTP的序列号不连续的情况下，认定分组丢失了。

在ARQ部分311中，丢失的分组被添加到重传请求列表（即，NACK列表）。ARQ部分311在特定的时间从“NACK列表”中读取NACK分组信息，并传给RTCP部分313。RTCP部分313基于该“NACK列表”发送NACK分组到传输设备200。

在“NACK列表”中，“NACK超时（timeout）”信息和“NACK期限（deadline）”信息这两个时间信息片段设置用于单个NACK分组信息。

在此，接收设备300的ARQ部分311在分组丢失第一次被检测到的时间点命令NACK分组的传输。另一方面，即使在从NACK分组开始传输起已经过去特定时间时的时间点（即，在“NACK超时”的流逝时间点）没有收到重传的分组的情况下，该ARQ部分311也重复输出该NACK分组的传输命令，直到“NACK期限”。

“NACK期限”通常设置成从NACK分组开始传输起已经过去RTT时间时的时间。“NACK超时”设置成分组到达期限之前RTT时间的时间，诸如分组数据播放调度时间。

图5示出了“ARQ处理”的时序示例。图5示出了在序列号“102”的分组已经成为未交付分组的情况下，虽然两个重传分组也被判断为丢失分组，但NACK分组的重传因“NACK期限”到达而被停止的示例。

例如，使用在IETF因特网草案“Extended RTP Profile for PTCP-based Feedback”中描述的RTCP NACK分组格式作为NACK分组的格式。

图6和图7示出了在“ARQ处理”中执行的处理过程的示例。图6示出了在传输设备200中的处理过程，而图7示出了在接收设备300中的处理过程。

传输设备200中的ARQ部分209首先判断是否ARQ处理要结束（S21）。

在处理S21得到否定结果的情况下，ARQ部分209判断是否收到NACK分组（S22）。

在处理S22得到否定结果期间，ARQ部分209重复处理S21和处理S22的判断处理。

另一方面，在处理S22得到肯定结果的情况下，ARQ部分209通知RTP传输部分207由NACK分组的序列号指定的分组的重传（S23）。这些处理重复地执行，直到确认ARQ处理结束。

另一方面，接收设备300中的ARQ部分311还首先判断ARQ处理是否要结束（S31）。

在处理S31得到否定结果的情况下，ARQ部分311从数据列表中删除NACK列表中超出“NACK期限”的分组（S32）。

然后，ARQ部分311判断是否通知了分组丢失信息（S33）。

在处理S33得到肯定结果的情况下，ARQ部分311添加丢失分组的序列号、“NACK超时”和“NACK期限”到NACK列表中（S34）。

在处理S33得到否定结果的情况下（在NACK分组相对于相同的分组已经被传输的情况下），ARQ部分311判断“NACK超时”是否已经过去了（S35）。

处理S34执行之后或者在处理S35得到肯定结果的情况下，ARQ部分311判断是否当前时间超过了“NACK期限”，在没有超过的情况下，ARQ部分311请求RTCP部分313发送NACK分组（S36）。

另一方面，在处理S35得到否定结果的情况下，ARQ部分311返回到处理S31并执行这一系列的处理。

（b3）冗余度确定处理

在“冗余度确定处理”中，用于FEC编码部分205的纠错数据的冗余度是基于网络状态信息、ARQ重传分组总量和诸如视频数据的数据分组块的数据速率来确定的。

网络状态信息是从，例如，IETF RFC3550中描述的RTCP发送机报告（SR）分组和RTCP接收机报告（RR）分组获取的，这些分组在传输设备200中的RTCP部分211和接收设备300中的RTCP部分313之间传输/接收。

诸如往返时间（RTT）和分组丢失率的各种参数被使用作为网络状态信息。

在本实施例中，RTCP部分211从这些网络参数中获得纠错后丢失率，该纠错仅通过未交付的分组的重传来实现，并确定对于实现纠错后的目标丢失率所需要的FEC冗余度。

在没有分组到达期限的情况下，由于ARQ功能的重传请求可以被无限执行，所以纠错后的目标丢失率只能由ARQ实现。

然而，在分组到达期限是有限的情况下，ARQ系统重传的可能次数是由RTT和分组到达期限来确定的，而且一旦RTT增大，ARQ纠错后丢失率也变高。也就是说，在FEC编码部分205中，需要更高冗余度的冗余编码。

作为示例，假设视频帧数据是FEC块单元，纠错后的视频帧丢失率是纠错后目标丢失率的索引。

例如，在纠错后目标丢失率少于10^-4的情况下，确定冗余度以使得使用ARQ系统和FEC系统纠错后的视频帧中只丢失了一个分组的可能性是10^-4或更低。

纠错后的分组丢失率而不是视频帧丢失率也可以被使用作为目标索引。

在冗余度确定部分213中，例如，基于来自RTCP部分211的RTT信息和来自分组部分203的每视频帧的分组数量信息，每FEC块的冗余分组数量被确定。

作为对冗余分组数量的指定，有可能应用参考前面计算的“冗余表”的系统或每次执行计算的系统。

图8示出了用于参考“冗余表”的方法中的冗余表的示例。图8示出了当网络的分组丢失率没有作为参数使用的同时，在随机分组丢失率的环境下使纠错后的视频帧丢失率保持特定值或更低所必须的冗余表的示例。也就是说，在冗余表的示例中，只有RTT是参数。

附带地，除了RTT信息之外，分组丢失率也被添加作为参数。在这种情况下，需要三维冗余表。

在这个例子中，在视频帧是FEC块单元的情况下，为了使纠错后的视频帧丢失率保持特定值或更高，根据每个FEC块的数据分组的数量，改变需要的FEC分组的数量与该数据分组的数量的比率。

图9示出了执行“冗余度确定处理”的处理过程。

在传输设备200中的冗余度确定部分213首先判断是否要结束冗余度确定处理（S41）。

在处理S41得到否定结果的情况下，冗余度确定部分213判断是否从RTCP部分211得到了网络状态信息（S42）。

在处理S42得到否定结果期间，冗余度确定部分213重复处理S41和处理S42的判断处理。

另一方面，在处理S42得到肯定结果的情况下，冗余度确定部分213参考“冗余表”，确定数据分组的数量和FEC冗余分组的数量，并把这些传给FEC编码部分205。这些处理重复执行，直到确认冗余度确定处理结束。

如上所述，在视频帧被组装成FEC块单元的情况下，仅借助于ARQ的纠错后分组丢失率和借助于ARQ和FEC的纠错后视频帧丢失率可以由下面的表达式来计算（数学表达式1）。

通过这个表达式，达到纠错后理想的视频帧丢失率所必须的冗余分组的数量可以计算出来。

[数学表达式1]

P_{arq} = p_{l}^{(N_{net} + 1)} {(2 - p_{l})}^{N_{net}}

P_{fec_arq} = 1 - ({Σ_{k = 0}^{N_{F}}}_{(N_{D} + N_{F})} C_{k} P_{arq} {(1 - P_{arq})}^{(N_{D} + N_{F} - k)})

P_l：分组丢失率（随机分组丢失率）

P_arq：仅借助于ARQ的纠错后分组丢失率

P_{fec_arq}：借助于ARQ和FEC的纠错后视频帧丢失率

N_D：每视频帧的原始数据分组数量

N_F：每视频帧的冗余分组数量

N_net：ARQ重传的可能次数

（A-3）实施例的效果

如上所述，当传输设备200中提供了冗余度确定部分213，而且冗余分组的冗余度根据网络状态得到优化时，接收机端纠错后丢失率可以保持在允许的范围之内而不会增加网络的拥塞。

例如，在往返时间（RTT）很小的情况下，指定的纠错后丢失率可以通过对未交付分组的重传来实现。从而，冗余分组的冗余度达到最小化，而且有可能避免网络不必要的拥塞。

另外，例如，在往返时间（RTT）很大的情况下，需要的纠错后丢失率不能仅通过未交付分组的重传来实现，然而，该需要的纠错后丢失率可以通过增加冗余分组的冗余度来实现。

图10示出了该处理的映像。根据图10，可以理解，虽然数据分组块的传输速率是常量，但冗余分组的冗余度还是根据网络的往返时间增加/减少。

另外，通过使用冗余度确定部分213，可以消除使用传输设备200的用户手动改变纠错系统的设置的必要性。因此，用户的便利性得到了提高。

而且，纠错所必需的数据传输总数也可以最小化。因此，大量的传输总量可以分配到数据分组块的传输中。通过这种方式，在视频传输的情况下，相比现有的技术，可以实现更高质量的视频传输。

（B）实施例2

在本实施例中，还将描述通过因特网执行视频数据的流传输的通信系统。

然而，在本实施例中，假设可用总传输速率被共享介质中的传输速率控制、或带宽预留的限制、或物理网络的限制而限制。

（B-1）系统结构示例

图11示出了构成通信系统的传输设备和接收设备的结构示例。图11示出了通信系统400包括传输设备500和接收设备300（图2）的情况。也就是说，接收设备300的结构与实施例1是相同的。

传输设备500（图11）包括编码部分201、分组部分203、FEC编码部分205、RTP传输部分207、ARQ部分209、RTCP部分211、速率控制部分501和冗余度确定部分503。

与实施例1不同之处在于速率控制部分501和冗余度确定部分503这两部分。

（B-2）处理算法

下面将描述通信系统400中执行的处理算法。附带地，实施例2的处理算法与实施例1的处理算法的不同之处只有两点，即，添加了“速率控制处理”和“冗余度确定处理”的内容。相应地，下面只介绍这两个处理功能。

（a）速率控制处理

速率控制处理是根据，例如，IETF RFC3448“TCP Friendly Rate Control (TFRC):Protocol Specification”来执行的。传输设备500中的速率控制部分501基于来自RTCP部分211的网络信息，例如分组丢失率和RTT，确定数据分组块、FEC的冗余分组数据和ARQ的重传数据的总传输速率。在已知的处理系统中，虽然总传输速率信息只通知给编码部分201和RTP传输部分207，但是在本实施例中，总传输速率信息通知给冗余度确定部分503。

（b）冗余度确定部分

传输设备500中的冗余度确定部分503中，“冗余度确定处理”基于速率控制部分501通知的总传输速率、RTCP部分211通知的分组丢失率和RTT、ARQ部分209通知的重传数据大小，确定通知给编码部分201的视频帧数据大小和通知给FEC编码部分205的冗余度。

附带地，在实施例1中，虽然原始数据分组的数量由分组部分203通知给冗余度确定部分213，但是在本实施例中，数据大小和冗余度是在冗余度确定部分503中调整的，重传数据的传输速率、FEC冗余分组的传输速率和数据分组块的传输速率的总和成为总传输速率，从速率控制部分501通知给编码部分201和FEC编码部分205。

在本实施例中，图12还示出了冗余表的示例，其中视频帧数据构成FEC块单元，纠错后视频帧丢失率是特定值或更低的值。

在该冗余表中，通过从总传输速率减去重传分组的传输所必需的传输速率（重传数据速率）得到的传输速率构成当前值，每个FEC块的FEC冗余分组的数量根据该当前值与RTT值的关系来确定。

图13示出了在“冗余度确定处理”中执行的处理过程。

在此，冗余度确定单元503首先判断冗余度确定处理是否要结束（S51）。

在处理S51得到否定结果的情况下，冗余度确定单元503判断是否从RTCP部分211获取了网络状态信息（S52）。

在处理S52得到否定结果期间（直到确认了网络状态信息的获取），冗余度确定部分503重复处理S51和处理S52的判断处理。

另一方面，在处理S52得到肯定结果的情况下，冗余度确定部分503判断是否从速率控制部分501获取了传输速率信息（S53）。

在处理S53得到否定结果期间（直到确认了传输速率信息的获取），冗余度确定部分503重复处理S51到处理S53的判断处理。

另一方面，在处理S53得到肯定结果的情况下，冗余度确定部分503判断是否从ARQ部分209获取了重传数据大小（S54）。

在处理S54得到否定结果期间（直到确认了重传数据大小的获取），冗余度确定部分503重复处理S51到处理S54的判断处理。

另一方面，在处理S54得到肯定结果的情况下，冗余度确定部分503从总传输速率中减去重传数据速率，得到数据分组块和FEC冗余分组可以使用的传输速率。

当获取了传输速率时，冗余度确定部分503参考“冗余表”，确定数据分组的数量和FEC冗余分组的数量，以满足约束条件下的传输速率，并将它们传送给编码部分201和FEC编码部分205（S55）。这些处理重复地执行，直到确认冗余度确定处理结束。

附带地，还是在本实施例中，数据控制所必须的数据分组的数量和FEC冗余分组的数量可以通过计算获得。

（B-3）实施例的效果

如上所述，当传输设备500中提供了冗余度确定部分503，而且冗余分组的冗余度根据网络状态得到优化时，在有限的传输速率范围内而且不需要不必要的冗余度增加，在接收机端纠错后丢失率可以保持在允许范围之内。

例如，在往返时间（RTT）短的情况下，指定的纠错后丢失率可以通过对未交付分组的重传来实现。从而，冗余分组的冗余度达到最小化，而且被传输的数据分组块的比率可以增加。

另外，例如，在往返时间（RTT）大的情况下，需要的纠错后丢失率不能仅通过未交付分组的重传来实现，然而，分配给数据分组块的数据总量可以在需要的纠错后丢失率可以实现的范围内最大化。

图14示出了该处理的映像。如图14所示，虽然总传输速率是常量，但数据分组块和纠错数据（FEC）的比值还是根据网络状态增加/减少。

另外，还是在本实施例中，通过使用冗余度确定部分503，可以排除使用传输/接收设备的用户手动改变纠错系统的设置的必要性。因此，用户的便利性得到了提高。

而且，由于纠错所必需的数据传输总数也最小化，大量的传输总量可以分配到数据分组块的传输中。例如，在视频传输的情况下，相比现有的技术，可以实现更高质量的视频传输。

（C）其它实施例

（a）在前面的实施例中的传输设备的处理功能可以通过硬件或软件来实现。

另外，不仅所有这些处理通过硬件或软件来实现，其中一部分可以通过硬件和软件来实现。也就是说，可以应用硬件和软件的组合。

（b）参考前面的实施例，各种在本发明主旨的范围之内的改进的例子都是可能的。另外，基于本说明书的材料制造或组合的各种改进的例子和应用的例子也是可能的。

本领域内技术人员应该理解取决于本发明的设计需求和其它因素的各种改进、组合、替代组合和替换都在本附加权利要求及其等价物范围之内。

Claims

1.一种传输具有有限到达时间的数据分组的分组传输装置，包括：

分组重传部分，配置为控制未交付数据分组的重传；

前向纠错编码部分，配置为基于冗余度产生用于具有有限到达时间的数据分组的前向纠错(FEC)分组；

传输部分，配置为传输数据分组、FEC分组和重传分组；和

冗余度确定部分，配置为接收至少包括往返时间信息的网络状态信息并基于网络状态信息动态地确定添加到数据分组块的冗余分组的冗余度。

2.根据权利要求1所述的分组传输装置，其中，所述网络状态信息包括往返时间信息和分组丢失率。

3.一种传输具有有限到达时间的数据分组的分组传输方法，包括：

控制未交付数据分组的重传；

基于冗余度产生用于具有有限到达时间的数据分组的前向纠错(FEC)分组；

传输数据分组、FEC分组和重传分组；

接收网络状态信息；和

基于至少包括往返时间信息的网络状态信息动态地确定添加到数据分组块的冗余分组的冗余度。

4.根据权利要求3所述的分组传输方法，其中，所述网络状态信息包括往返时间信息和分组丢失率。