CN1311590A - 压缩报头传输数据包的方法和装置 - Google Patents

压缩报头传输数据包的方法和装置 Download PDF

Info

Publication number
CN1311590A
CN1311590A CN01108948.2A CN01108948A CN1311590A CN 1311590 A CN1311590 A CN 1311590A CN 01108948 A CN01108948 A CN 01108948A CN 1311590 A CN1311590 A CN 1311590A
Authority
CN
China
Prior art keywords
header
packet
data
compressed packet
compressed
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN01108948.2A
Other languages
English (en)
Other versions
CN1165138C (zh
Inventor
吉村健
河原敏朗
铃木敬
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NTT Docomo Inc
Original Assignee
NTT Docomo Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by NTT Docomo Inc filed Critical NTT Docomo Inc
Publication of CN1311590A publication Critical patent/CN1311590A/zh
Application granted granted Critical
Publication of CN1165138C publication Critical patent/CN1165138C/zh
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/04—Protocols for data compression, e.g. ROHC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/167—Adaptation for transition between two IP versions, e.g. between IPv4 and IPv6
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

在包括发送器和接收器的网络这种情况下,其中的发送器将要发送的非压缩数据包转换成包括一个完整报头的完整报头数据包或者包括压缩报头的压缩报头数据包,并将转换过的数据包发送给接收器,在这种情况下,发送器将要发送的非压缩数据包里的至少重要数据包作为完整报头数据包发送。重要数据包指的是例如,包括在最终收到数据包的数据终端按照数据包里的数据再现声音和/或图像的时候,扮演重要角色的数据的数据包。

Description

压缩报头传输数据包的方法和装置
本发明涉及一种数据包传输方法，用于在多个数据终端之间发送和接收数据包，还涉及用于这一数据包传输的一种中继装置和一种数据终端。
最近，通过因特网传输需要实时传输的视频数据或者音频数据这一类数据的需要非常紧迫。
作为满足这一需要的协议，RFC(请求说明)1889制订了一个RTP(实时传输协议)，由因特网标准化组IETF(因特网工程特别任务)发布。这个RTP的功能有：1)有效负荷类型的规范，2)序列号的指定，和3)时标的指定。这些规则使得音频和视频数据这样的信息能够在因特网上实时传输。通常，RTP被用作网络层上IP(因特网协议)的上层和传输层上的UDP(用户数据报协议)。
图13A说明要按照RTP、UDP和IP传输的音频和视频数据这种数据的RTP报头、UDP报头和IP报头(以后叫做“RTP/UDP/IP报头”)。以后，将包括RTP/UDP/IP报头的数据包叫做IP数据包。
如图所示，IP报头需要20个字节，UDP报头需要8个字节，RTP报头需要12个字节，因此，RTP/UDP/IP报头总的字节数达到40个字节。而IP数据包里的视频数据则包括，例如，大约50个字节。为了以数据包的形式传输这种图像数据，系统开销达到44％以上。类似地，为了在一个数据包里传输包括20个字节的音频数据，系统开销达到了66％。由于实际传输中需要增加其它层的报头，因此，整个报头将占用数据包很大的一个百分比，会因此降低通信效率。
作为克服这一缺点的一种技术，IETF发布的RFC 2508给出了一个RTP压缩协议，用于压缩RTP/UDP/IP报头。RTP压缩协议使得图13A所示的RTP/UDP/IP报头能够被压缩成图13B所示的报头(以后叫做“压缩报头”)。下面详细介绍这一压缩方法。
这一压缩方法被用于网络内两个节点之间，这些数据包在例如多个数据终端之间传输。更具体地说，在这两个节点中，一个节点(以后叫做“发送器节点”)将数据终端之间传输的一部分IP数据包的RTP/UDP/IP报头转换成压缩报头，并将它作为压缩了报头的数据包传输给另一个节点(以后叫做“接收器节点”)。与此同时，发送器节点将另一部分IP数据包的RTP/UDP/IP报头作为完整报头而没有任何压缩传输给接收器节点。接收器节点将来自发送器节点的压缩报头数据包或者完整报头数据包解压缩(也就是恢复)，得到IP数据包，并将它发送给下一个节点或者接收器数据终端。完整报头是这样的报头，包括在图13A所示的RTP/UDP/IP报头里的长度被包括一个CONTEXT_ID的信息替换掉，用于识别RTP连接和按照发送器传输顺序给出的连接序列号link_seq。
下面介绍图13B所示压缩报头的内容。在图13A所示RTP/UDP/IP报头的阴影区部分里的数据，包括IP报头里的版本号(V)和RTP报头里的有效负荷类型，是要从发送器节点发送的数据包的恒定数据(以后叫做“静态字段”)。因此，如图13B所示，这一压缩报头不包括静态字段的数据。当发送器节点将数据包流里的第一个IP数据包发送给接收器节点的时候，它发送一个完整报头数据包，它具有完整的报头，包括那些静态字段。在这以后，发送器节点将后面的IP数据包的RTP/UDP/IP报头转换成不包括任何静态字段的压缩报头。这些转换过的压缩报头被作为压缩报头数据包，发送给接收器节点。当接收器节点收到第一个IP数据包的完整报头数据包时，接收器节点将收到的RTP/UDP/IP报头恢复成第一个收到的完整报头数据包里的完整报头，并将这样得到的解压缩报头写入内部存储器。在这以后，接收器节点利用RTP/UDP/IP报头的静态字段，恢复在第一个数据包后面收到的压缩报头数据包里压缩报头的静态字段。
在所有IP数据包里，静态字段里的数据并不总是常数，而是可能在某个IP数据包里发生改变。如果在某个IP数据包里发生了这样的改变，发送器节点将发送一个完整的报头数据包给接收器节点，包括IP数据包RTP/UDP/IP报头的完整报头，而不进行压缩。
图13A中RTP/UDP/IP报头里非阴影区部分的数据包括序列号和RTP报头的时标以及IP报头的ID。这个时标给出发送或者产生数据包的时刻。在接连发送的两个IP数据包中，这些数据应当具有恒定的差值(改变量)。以后，提供这些数据的字段叫做“德尔塔字段”。如图13B所示，基本压缩报头不包括德尔塔字段里的数据。如上所述，在其存储器里保存着RTP/UDP/IP报头的接收器节点将差值加到储存的RTP/UDP/IP报头的德尔塔字段里的值上去，从而能够对压缩报头的德尔塔字端解压缩，随后被收到。
然而，并不是所有IP数据包之间德尔塔字段里的这些差值都是恒定的。在某些情况下它们取不同的值。在这些情况下，必须将改变的值告诉接收器节点。利用存储器中RTP/UDP/IP报头的内容和新获得的差值，接收字节能够将随后收到的每一个压缩报头数据包的RTP/UDP/IP报头里包括的德尔塔字段里的内容恢复出来。为此，图13A所示的压缩报头里有几个标志S、T和I，它们说明德尔塔字段里的差值是否发生了改变。如果有差值发生了改变，新的差值被增加到压缩报头里，如图13B里的虚线所示。实际上，如果RTP报头序列号的差值发生了改变，就将S标志设置成“1”，并将说明序列号新差值的一个序列号差值(德尔塔RTP序列)增加到压缩报头里去，如图13B的虚线所示。类似地，如果RTP报头时标的差值发生了改变，就将标志T设置成“1，说明时标信差值的时标差值(德尔塔RTP时标)包括在压缩报头里，如图13B里的虚线所示。如果IP报头的ID的差值发生了改变，就将标志I设置成“1”，说明ID新差值的ID差值(德尔塔IP ID)被附加到压缩报头里。
如图13B所示，跟完整报头一样，压缩报头还包括CONTEXT_ID和link_seq。接收器节点按照CONTEXT_ID指定的RTP/UDP/IP报头里的内容对压缩报头解压缩。接收接点参考从发送器节点按顺序发送的每一个数据包(压缩报头数据包或者完整报头数据包)的连接序列号link_seq。发现一些连接序列号丢失了以后，接收器就认定在发送器节点和接收器节点之间丢失了数据包。
参考图14，现在描述在发送器节点和接收器节点之间进行数据包传输的过程。在图14里，字段A说明RTP/UDP/IP报头的一个静态字段(也就是图13A中阴影区里的任意数据)，字段B说明了一个德尔塔字段(也就是图13A中非阴影区里的任意数据)。此外，在图14里，“F”表示完整报头数据包，“C”表示压缩报头数据包。
收到从发送器数据终端发送给接收器数据终端的IP数据包a的时候，发送器节点将IP数据包的RTP/UDP/IP报头存入它的内部存储器。与此同时，发送器节点通过用报头长度替换CONTEXT_ID来产生一个完整报头和连接序列号link_seq，并将包括产生的完整报头和数据的完整报头数据包(以后叫做“RTP有效负荷”)发送给接收器节点，它们是IP数据包中除了RTP/UDP/IP报头以外的部分(在图14里叫做“OP1”)。收到这一完整报头数据包的接收器节点将来自这一数据包的完整报头的RPT/UDP/IP报头储存起来(也就是从完整报头里提取出CONTEXT_ID和link_seq)，并将这一IP数据包跟这一报头一起发送给下一个节点或者接收器数据终端。在这一过程中，解压缩以后的RTP/UDP/IP报头被存入它的内部存储器。
然后，发送器节点将在IP数据包以后收到的IP数据包b里的RTP/UDP/IP报头转换成压缩报头，并将数据包b跟压缩报头一起发送给接收器节点(在图14里叫做“OP2”)。在压缩报头数据包的压缩报头里，增加数据包b的德尔塔字段B里的一个值[1]跟最后一个数据包a的德尔塔字段B里的一个值[0]之间的差值ΔB(=1)，同时将标志(图13B里的标志S、T和I)设置成“1”，表示差值发生了变化。
通过将这一数据包里给出的差值ΔB加到储存在内部存储器里最后一个IP数据包a里的RTP/UDP/IP报头的德尔塔字段B的值上去，接收压缩报头数据包b的接收器节点获得压缩报头数据包b的压缩报头里的德尔塔字段B。然后，接收器节点将具有这两个RTP/UDP/IP报头的IP数据包b发送出去，其中包括IP数据包a的RTP/UDP/IP报头的德尔塔字段B和静态字段A，以及RTP有效负荷。对IP数据包b解压缩的过程中提到的RTP/UDP/IP报头9(在这种情况下是从最后一个IP数据包a提取出来的RTP/UDP/IP报头)被压缩报头数据包b的CONTEXT_ID指定。这个数据包里给出的IP数据包b的RTP/UDP/IP报头和差值ΔB也储存在内部存储器里。
下一步接收IP数据包c的时候，发送器节点计算IP数据包c和最后一个IP数据包b的德尔塔字段B之间的差值。在这种情况下，ΔB为[1](=3-2)，这跟上次告诉接收器节点的前一个一样。于是，没有任何必要通知没有改变的差值。因此，发送器发送有一个没有差值的压缩报头的一个压缩报头数据包c给接收器节点(也就是图13B所示的虚线，在图14里叫做“OP3”)。接收这一压缩报头c的接收器节点将储存起来的差值ΔB存入前一个数据包b的德尔塔字段B，从而对压缩报头数据包里压缩报头的德尔塔字段B解压缩。然后，接收器节点发送包括两个RTP/UDP/IP报头的一个IP数据包c，包括解压缩值，从完整报头数据包a的完整报头里提取出来的静态字段A，以及RTP有效负荷。下一个数据包d被按照同样的方式加以处理。
下一步发送器节点收到的IP数据包e的德尔塔字段B的值是[5]，最后一个IP数据包d的德尔塔字段B的差值是[2]。当差值ΔB按照这种方式改变的时候，发送器节点发送有一个压缩报头的一个压缩报头数据包e，其中增加了改变的新的差值，而且相应的标志被设置为[1]。接收器节点将新差值加到IP数据包d的德尔塔字段B的值上去，从而对数据包e的德尔塔字段B解压缩，然后发送包括解压缩德尔塔字段B的一个IP数据包。
然后发送器节点接收IP数据包g，它不同于最后一个IP数据包e的静态字段A。这样，在这种情况下，发送器节点不压缩这一IP数据包的RTP/UDP/IP报头，并发送具有完整报头的一个完整报头数据包g，其中数据包g的RTP/UDP/IP报头的长度被CONTEXT_ID和link_seq替换。接收这一完整报头数据包g的接收器节点将完整报头转换成RTP/UDP/IP报头，并将它们存入内部存储器里。
上面已经描述了RFC 2508给出的报头压缩方法(以后叫做“方法A”)。然而，这一压缩方法有一些缺点，下面将进行描述。
例如，如图15所示，由于某种原因在发送和接收器节点之间丢失了压缩报头数据包c。如上所述，对数据包d解压缩的时候，接收器节点将差值ΔB加到IP数据包c的德尔塔字段B上去，对IP数据包d的德尔塔字段B解压缩。结果，丢失压缩报头数据包c的时候，无法对压缩报头数据包d的德尔塔字段B解压缩。于是，接收器节点被迫丢弃图15中的数据包d、e和f，直到收到下一个完整报头数据包g。换句话说，数据包的丢失导致一些其它数据包接连丢失，跟不进行报头压缩的方法相比，它会导致吞吐量下降。特别是在发送和接收器节点是用有线链路连接的情况下，很可能会在有线链路上丢失数据包。如果丢失了这样的数据包，接收器节点常常会丢弃其它一些数据包。作为解决这种问题的一种技术，IETF和因特网草案发布的RFC 2507和2508提供了以下方法。
方法1：反复发送完整报头数据包(RFC 2507)
在上述传统方法A的情况里，发送器节点只在报头的静态字段改变值的情况下发送完整报头数据包。而如图16所示，这一方法1每隔预定个数数据包选择要发送的几个IP数据包，不管静态字段的值是否改变。选择的IP数据包被转换成具有完整报头的完整报头数据包，而且这些完整报头数据包被发送给接收器节点，剩下的IP数据包被转换成具有压缩报头的压缩报头数据包，将这些压缩报头数据包发送给接收器节点。在方法A里，因为只要静态字段不改变值，就不将完整报头的数据包发送给接收器节点，所以，在丢失数据包以后发送的所有数据包都被丢弃。而这一方法1则是间歇性地发送完整报头数据包，这样，它的优点是由于数据包丢失而丢弃的数据包的个数会减少。但是，这一方法1中，发送完整报头数据包较长的周期会导致丢弃数据包增加，而较短的周期又会导致发送大量的完整报头数据包，从而增大系统开销，降低通信效率。
方法2：通过反向信道请求发送完整报头(RFC 2507和2508)
如图17所示，检测数据包是否丢失的时候，这一方法2使接收器节点能够发送一个CONTEXT_STATE消息，向发送器节点请求获得一个完整报头数据包。收到这个CONTEXT_STATE时，发送器节点以完整报头数据包的形式发送下一个IP数据包给接收器节点。结果，由于丢失某个数据包而丢弃一些数据包的时间段可以被限制在数据包丢失到相应CONTEXT_STATE发送的完整报头数据包之间。然而，这一方法有一个缺点，当发送CONTEXT_STATE和接收器节点收到完整报头数据包之间的时间，也就是一个RTT(往返时间)增大时，丢弃的数据包也会增加。如果通过无线链路传递数据包，这一缺点就非常明显，因为无线链路的RTT很长。
方法3：两倍算法(RFC 2507)
第三个方法利用在丢失数据包之前刚刚解开压缩的RTP/UDP/IP报头对丢失了某个数据包以后收到的压缩报头数据包的压缩报头解压缩。例如，如图18所示，假设按顺序收到数据包b以后，丢失了数据包c，然后按顺序收到数据包d。在这种情况下，如果在数据包b到d之间差值ΔB没有改变，数据包d的德尔塔字段B就可以通过在数据包b的德尔塔字段B上加ΔB的两倍计算出来。此外，这一方法需要压缩报头中的UDP校验和(参考图13B)，从而将UDP校验和用于判断数据包的解压缩是否正确。然而，如图18所示，如果丢失了数据包k，而且数据包j和k之间德尔塔字段的差值ΔB发生了改变，就会发生紧接丢失的数据包后面收到的数据包1无法正确解压缩这样的问题。特别是如果数据包是用无线链路传递的，就有可能丢失一大串数据包(也就是很长一段时间)。在这种情况下可以认为在丢失的大量数据包中，差值ΔB很可能会发生改变。因此，前面的问题更加严重。
方法4：ROCCO(因特网草案)
根据本发明的第4个方法，可以根据传送数据包的媒体的特性来估计差值ΔB。例如，在图19那种情况中，假设丢失了数据包g和h，而且g和h之间的差值ΔB发生了改变。在这一情形里，根据传递数据包的媒介的特性来估计差值ΔB的改变，数据包可以通过将估计的差值ΔB加到数据包f上来解压缩。另外，这一方法还利用差错检测码(CRC)来判断解压缩是否正确。这样，即使差值ΔB发生了改变，这一方法仍然能够对丢失某个数据包以后收到的数据包解压缩。但是，这一方法中估计差值ΔB很困难。
如上所述，虽然提出了多种技术来有效地进行数据通信，甚至IP数据包的RTP/UDP/IP报头被压缩了，但是，所有这些技术都有某些缺点。这样，目前在有效地减少发送和接收器节点之间丢失某个数据包以后而丢弃的数据包的个数方面存在着局限性。也就是说，在接收器节点和发送器节点之间传递数据包的过程中，部分数据包的丢失会导致接收器节点丢失其它数据包。这就导致了处理接收器数据终端接收数据包(例如，用收到的数据包显示图像或者播放音乐)的过程中出现很大的损失。
本发明是在上述情形下出现的。本发明的一个目的是提供一种数据包传输方法、一个中继装置和一个数据终端，它们能够有效地减少由于丢失某个数据包而丢弃的数据包的个数，即使要发送和接收的数据包的报头都是压缩过了的。
一方面，为了本发明目的，提供了一种数据包传输方法，用于从发送器节点到接收器节点通过网络传输数据包，包括发送器节点里的通信装置进行转换，将要发送的非压缩数据包转换成具有一个更新报头的一个更新报头数据包，其中包括在接收器节点足以正确地解压缩和恢复同步的信息；或者转换成具有压缩报头的压缩报头数据包的步骤，其中包括的信息比更新报头包括的信息少，这样，一些非压缩数据包被转换成更新报头数据包，只要这些数据包是重要数据包；还包括发送数据包流给接收器节点的步骤，这个数据包流中包括更新报头数据包和压缩报头数据包。
在这一方法中，将包括数据包流中起重要作用的数据的重要数据包作为更新报头数据包发送，它们总是能够被正确地解压缩并恢复同步。因此，由于这个重要数据包不会因为丢失其它数据包而被丢弃，所以，可以降低数据包的丢失对媒介质量，也就是显示的图像和播放的音频信号的质量的影响。
这一更新报头可以是一个完整报头，包括非压缩数据包中原来的报头。这个更新报头还可以是另一种格式。例如，如果发送给接收器节点的第一个数据包已经启动了压缩状态，发送器节点就能够发送更新报头，它能够根据前面的初始化结果更新压缩状态。
可以这样来实现本发明，生产或者销售中继装置或者数据终端，用于按照本发明的数据包传输方法传输数据包。此外，本发明还能够这样来实现，将执行本发明的数据包传输方法的程序记录在计算机能够读出来的存储媒介里，或者通过电子通信电路将这一程序提供给用户。
图1说明采用本发明第一个实施方案的数据包传输方法的通信系统的结构框图；
图2是数据包传输方法中使用的接收器节点的结构框图；
图3是本发明第一个实施方案中数据包中继装置的工作流程图；
图4A和4B是改进了的第一个实施方案的数据包传输时序图；
图5是本发明第二个实施方案中传输的压缩了的非TCP数据包的报头格式；
图6A是传输非TCP数据包的时候，完整报头数据包传输方法的时序图；图6B是本发明中完整报头数据包传输方法的时序图；图6C是本发明完整报头数据包传输方法的另一个时序图；
图7说明利用ROHC的报头压缩过程和重构过程中的状态过渡；
图8A说明ROHC中IR报头的格式；图8B说明ROHC中IR-DYN报头的格式；
图9A说明ROHC中的O型报头；图9B说明ROHC中的1型报头；图9C说明ROHC中的2型报头；
图10说明ROHC中使用的LSB编码；
图11说明这一实施方案中的数据包传输方法；
图12说明用于每一个实施方案的变种里IPv6报头的格式；
图13A说明RTP/UDP/IP报头的内容；图13B说明压缩报头的内容；
图14说明跟本发明有关的技术中数据包传输方法所经历的步骤的时序图(方法A)；
图15是说明有关技术中数据包传输方法存在的问题的时序图；
图16是说明有关技术中另一个数据包传输方法的步骤的时序图(方法1)；
图17是说明有关技术中另一个数据包传输方法的步骤的时序图(方法2)；
图18是说明有关技术中另一个数据包传输方法的步骤的时序图(方法3)；
图19是说明有关技术中另一个数据包传输方法的步骤的时序图(方法4)。
下面将参考附图来介绍本发明的实施方案。代表本发明各种模式的这些实施方案不是要限制本发明的范围，而是可以进行修改而不会偏离本发明的范围。
A．第一个实施方案
A-1：第一个实施方案的结构
图1说明可以采用本发明的数据包传输方法的通信系统的结构。在这个通信系统里，提供了发送器数据终端1和接收器数据终端2，通过网络3交换数据包。后面介绍的本发明中，由发送终端1发送数据包给接收终端2。
网络3包括一个发送器节点3a和一个接收器节点3b。在发送器节点3a和接收器节点3b上有中继装置。中继装置能够在发送器数据终端和接收器数据终端1和2之间中继数据包。虽然图1所示网络3说明的结构中包括发送器节点和接收器节点3a和3b，但是本发明并不限于这一结构。网络中可以包括三个或者更多的节点和中继装置。
在这一结构中，发送器数据终端1通过网络3按顺序发送要给接收器数据终端2的数据包。要从发送器数据终端1发送的数据包是包括图13A所示RTP/UDP/IP报头的IP数据包。发送器节点3a里的中继装置按顺序接收从发送数据节点1发送过来的IP数据包，将收到的IP数据包转换成包括完整报头的完整报头数据包或者包括压缩报头的压缩报头数据包，将它们发送给接收器节点3b。如前所述，完整报头是这样的报头，其中IP数据包中RTP/UDP/IP报头的IP报头或者UDP报头中包括的长度只用包括CONTEXT_ID或者link_seq的数据替代。另一方面，从发送器节点3a接收压缩报头数据包或者完整报头数据包的时候，接收器节点3b里的中继装置将压缩报头数据包的压缩报头或者完整报头数据包的完整报头里的RTP/UDP/IP报头储存起来，并将包括RTP/UDP/IP报头的IP数据包发送给接收器数据终端2。接收器数据终端2接收从接收器节点3b发送的IP数据包，并根据收到的IP数据包完成预定的处理(例如，根据RTP有效负荷显示图像、播放声音等等)。
跟前面描述的传统技术一样，完整报头数据包指的是这种数据包，它能够只根据完整报头数据包中的完整报头的内容，将包括RTP/UDP/IP报头的IP数据包储存起来。RTP/UDP/IP报头中的长度只用CONTEXT_STATE和link_seq替换，但是，这些长度值也可以利用较低层的信息恢复出来。相反，压缩报头数据包指的是这样的数据包，可以根据其它数据包(比方说完整报头数据包)将它解压缩成IP数据包，而不能只根据压缩报头数据包中包括的压缩报头将它解压缩成包括RTP/UDP/IP报头的IP数据包。
参考图2，现在介绍发送器节点3a中的中继装置。如图所示，发送器节点3a里的中继装置包括一个接收部分31a、发送部分32a、控制部分33a、存储部分34a和将这些单元连接在一起的总线35a。
接收部分31a被用作接收通过通信线路从发送器数据终端1发送的IP数据包，并将这些数据包输出给控制部分33a的装置或者单元。发送部分32a被用作通过通信线路发送来自控制部分33a的数据的装置或者单元。
控制部分33a是一种装置或者单元，用于控制接收部分31a、发送部分32a和存储部分34a中的每一个。实际上，控制部分33a实现a和b描述的过程。
a．判断收到的IP数据包的重要性
前面描述的有关技术中发送器节点里的中继装置的结构使得中继装置将具有改变的报头中的静态字段的数据包、每固定个数选择出来的数据包或者从接收器节点收到CONTEXT_STATE以后要立即发送的数据包转换成完整报头数据包，而不压缩数据包的报头，并将这个完整报头数据包发送给接收器节点。相反，这一实施方案中发送器节点3a里的中继装置的结构使得这一中继装置能够从发送器数据终端1接收IP数据包，并将其数据是重要数据的IP数据包(以后叫做“重要数据包”)转换成完整报头数据包，而不压缩报头，并将这一完整报头数据包发送给接收器节点3b。这里，重要数据包指的是包括接收器数据终端2播放声音或者显示图像的时候起重要作用的数据的数据包。具体而言，重要数据包指的是如果这一数据包被丢失，就会严重地影响声音或者图像传输质量(例如，使显示的图像或者播放的音乐变坏)的数据包。如果发送器节点3a里的控制部分33a符合以下条件，就认为收到的IP数据包是重要数据包。
①．RTP报头里的标志位M被置位的数据包，或者标志位M被置位的IP数据包的下一个数据包
标志位M包括在发送器数据终端1发送的IP数据包的RTP报头里。发送器节点3a里的控制部分33a通过检查这个标志位来判断它是否重要的IP数据包。下面对此进行详细介绍。
如果发送器数据终端1发送的数据是包括几个帧的视频数据，那么每一帧的第一个数据常常包括对于显示图像非常有用的信息。另一方面，RTP报头里的标志位M一般被设置成包括视频帧的最后数据。RTP报头中标志位M被置位的数据包的下一个数据包常常是视频帧的第一个数据。因此，发送器节点3a里的控制部分33a被这样配置，它使得RTP报头中标志位M被置位的数据包的下一个数据包被判断为重要数据包。
另外，有可能出现这样的情况，当有效负荷包括某些结构信息，例如数据结构之类，的时候，RTP报头里标志位M可以被置位。另一方面，当接收器数据终端用这些数据来显示图像或者播放音乐的时候，包括这些结构信息的数据包是重要数据包。因此，发送器节点3a里的控制部分33a可以被这样配置，使得RTP报头中标志位M被置位的数据包被判断为重要数据包。
②．RTP报头里的时标发生改变的情形
如果从发送器数据终端1发送的IP数据包里的数据是包括几个视频帧的视频数据，那么，包括相同视频帧的数据包里每一个数据包的时标值都相同。另一方面，如果这两个数据包包括属于不同视频帧的数据，时标值就不同。因此，当时标发生改变的时候，可以认为帧发生了改变。如上所述，紧跟发生改变的这一帧以后的数据包括在接收器数据终端2显示图像需要的重要信息。因此，当收到的IP数据包里的时标值不同于前一个数据包的时标值的时候，发送器节点3a的控制部分33a就认为收到的这个数据包是重要数据包(也就是说，包括帧初始信息的数据包)。
③．数据包的大小大于某一值的情形
当发送器数据终端1发送的IP数据包的有效负荷是包括话音突峰和无声部分的音频数据时，包括数据话音突峰的数据包的长度通常都比包括无声部分的数据包长。在接收器数据终端2里没能正确地收到包括话音突峰数据的数据包时，跟没能正确地收到包括无声部分的数据的数据包的时候相比，音频质量会显著地变坏。因此，从发送器数据终端1发送的IP数据包里的数据是音频数据的时候，发送器节点3a那里的控制部分33a根据IP数据包的大小检查每一个数据包的有效负荷是话音突峰数据还是无声部分的数据，并认为包括话音突峰数据的数据包，也就是大小超过预定大小的数据包，都是重要数据包。
④．数据包大小发生改变的情况
从发送器数据终端1发送的IP数据包的有效负荷是包括话音突峰和无声的音频数据的时候，接收器数据终端2需要识别从话音突峰到无声的切换，以及从无声到话音突峰的切换。因此，发送器节点3a处的控制部分33a将从无声切换到话音突峰或者从话音突峰切换到无声后面的数据包转换成完整报头数据包而不压缩报头，并将完整报头数据包发送给接收器节点3b。实际上，无论什么时候收到IP数据包的时候，发送器节点3a处的控制部分33a都要检查IP数据包的大小是不是大于预定大小(常数值)，并且当前一次收到的数据包的大小比预定大小小，而且这次收到的数据包的大小大于预定大小的时候，就认定这次收到的IP数据包是重要数据包。同样，如果前一次收到的数据包大于预定大小，而这次收到的数据包的大小小于预定大小，就认定这次收到的数据包是重要数据包。
⑤．包括要发送的媒体专用结构信息的情况
发送器节点3a里的控制部分33a检查收到的IP数据包是不是包括H.263的图形报头或者对应于MPEG 4之类的VOP报头的信息，并认定包括上述信息的数据包是重要数据包。
b．产生和发送报头压缩数据包和完整报头数据包
发送器节点3a的控制部分33a将认定为重要数据包的第一个数据包和IP数据包作为完整报头数据包输出给发送部分32a，而将其余数据包作为压缩报头数据包输出给发送部分32a。
具体而言，对于要作为完整报头数据包发送的IP数据包，控制部分33a给内部RTP/UDP/IP报头增加一个上下文ID和一个连接序列号(link_seq)，形成一个完整报头，并将包括完整报头的完整报头数据包发送给接收器节点3b。在这种情况下，IP数据包的内容被存入存储部分34a。
另一方面，对于要作为压缩报头数据包发送的IP数据包，控制部分按照传统技术中相同的方法，根据储存在存储部分34a里的IP数据包的内容产生压缩报头，并将包括压缩报头的压缩报头数据包发送给发送部分32a。
上面是发送器节点3a中的控制部分33a完成的过程。
接收器节点3b上的中继装置跟发送器节点3a具有相同的结构。具体而言，接收器节点3b里的中继装置包括用于从发送器节点3a接收数据包的接收部分31b、用于控制接收器节点3b里每一部分的控制部分33b、存储部分34b和用于将控制部分33b输出的数据包发送给接收器数据终端2的发送部分32b。但是，接收器节点3b里的控制部分33b将发送器节点3a发送的完整报头数据包或者压缩报头数据包转换成IP数据包，并将它输出给发送部分32b，跟上述发送部分3a里的控制部分相反。
A-2：第一个实施方案里的操作
下面参考图3介绍在发送器节点3a和接收器节点3b里中继装置之间进行的实际操作。在图3里，假设包括几帧的视频数据从发送器数据终端1发送出来。实际上，数据包a1～a5都是包括A帧的数据的IP数据包。数据包b1～b5都是包括B帧的数据的IP数据包。数据包c1～c5都是包括C帧的数据的IP数据包。另外，如上所述，为了方便，假设只有包括每一帧第一个数据的IP数据包被认定为重要数据包。
首先，收到要通过接收部分31a从发送器数据终端1发送的第一个IP数据包的时候，发送器节点3a里的控制部分33a将IP数据包a1的RTP/UDP/IP报头转换成完整报头，并将完整报头的内容储存在存储部分34a。然后，控制部分33a将包括完整报头的完整报头数据包a1通过发送部分32a发送给接收器节点3b。
然后，接收来自发送器数据终端1的IP数据包a2的时候，发送器节点3a里的控制部分33a检查RTP报头里的标志位M是不是被置位。在这种情况下，由于IP数据包a2不是A帧的最后一个数据包，因此，标志位M没有置位。接下来，控制部分33a根据存储部分34a中储存的数据包a1的完整报头的内容，将IP数据包a2里的RTP/UDP/IP报头转换成压缩报头，并将压缩报头数据包a2发送给接收器节点3b。以后，发送器节点3a里的控制部分33a完成针对数据包a3和a4所完成的过程。
于是，从发送器数据终端1接收数据包a5的时候，控制部分判断RTP报头里的标志位M是否被置位。在这种情况下，由于IP数据包a5是A帧的最后一个数据包，因此，标志位M被置位。所以，控制部分33a认为在数据包a5后面收到的那一个IP数据包是重要数据包。而对于IP数据包a5，控制部分将IP数据包里的RTP/UDP/IP报头转换成压缩报头，并用发送IP数据包a2～a4的方式将它们发送给接收器节点3b。
接下来，控制部分33a接收IP数据包b1。在这种情况下，由于已经很清楚这个IP数据包b1是重要数据包(也就是说IP数据包b1是新帧B的第一个数据包)，因为IP数据包a5里的标志位M被置位，所以控制部分33a将数据包b1的RTP/UDP/IP报头转换成完整报头，并将这个完整报头的内容写入存储部分34a，然后，将包括完整报头的完整报头数据包b1发送给接收器节点3b。而对于以后收到的IP数据包b2～b5，控制部分按照前面针对IP数据包a2～a5所做的一样，将它们作为压缩报头数据包发送给接收器节点3b。
另一方面，从发送器节点接收完整报头数据包a1的时候，接收器节点3b将其中包括的完整报头转换成RTP/UDP/IP报头，并将这样获得的IP数据包a1存入存储部分34b，同时将它发送给接收器数据终端2。
然后，接收器节点3b里的控制部分33b根据保存在存储部分34b里的IP数据包a1里RTP/UDP/IP报头的内容，将通过接收部分31b收到的压缩报头数据包a2里的压缩报头恢复出来，并将它作为包括RTP/UDP/IP报头的IP数据包发送给接收器数据终端2。至于随后收到的数据包a3，接收器节点3b里的控制部分33b恢复IP数据包，然后按照前面介绍过的方式将它发送给接收器数据终端2。
另一方面，如图3所示的实例说明了从发送器节点3a发送的压缩报头数据包a4在到达接收器节点之前，因为某种原因而丢失。此时，接收器节点3b根据下一步应该收到的压缩数据包a5里的连接序列号，检测到数据包a4已经丢失。由于压缩报头数据包a5无法正确地恢复，除非利用压缩报头数据包a4的内容，因此接收器节点3b里的控制部分33b丢弃收到的数据包，直到收到下一个完整报头数据包，也就是数据包a5。相反，包括B帧第一个数据的数据包b1不象数据包a5一样因为丢失了数据包a4而被丢弃，因为数据包b1是作为完整报头数据包发送的。
如上所述，在这一实施方案的数据包发送方法里，发送器节点3a将重要数据包作为完整报头数据包发送给接收器节点3b。因此，即使在发送器节点发送的数据包因为某种原因被丢失，而且随后的压缩报头数据包因此被丢弃，重要数据包仍然被发送给接收器数据终端2，直到重要数据包自己在发送器节点3a和接收器节点3b之间被丢失。具体地说，在接收器节点3b里，不会因为丢失了其它数据包而丢弃显示图像(或者播放声音)的重要数据包。因此，跟传统技术里完整报头数据包被发送给接收接点而不考虑数据包是否重要数据包这种情况相比，可以降低数据包丢失对接收器数据终端里图像质量的影响(例如，播放的图像或者声音的质量的变坏)。
在前面，虽然将IP报头里的标志位被置位的IP数据包的下一个数据包，也就是包括这一帧里第一数据的IP数据包，认定为重要数据包，但是这一操作同样能够用于其它IP数据包，也就是②～⑤介绍的IP数据包，被当作重要数据包的情形。
A-3：第一个实施方案的变型
虽然第一个实施方案里的发送器节点3a只将重要数据包作为完整报头数据包发送，但其结构并不限于此，下面的结构也包括在内。
<变型实例1>
在要发送的数据包的RTP/UDP/IP报头里的静态字段的值没有改变的情况下，可以采用这一方法只为重要数据包制作完整报头数据包，并将它按照上述方式发送。但是在静态字段的值发生了改变的情况下，发送器节点3a必须将重要数据包和静态字段发生了改变的数据包转换成完整报头数据包，如同传统技术A所示。具体而言，可以让发送器节点3a里的控制部分33a为重要数据包和静态字段发生了改变的数据包发送完整报头数据包给接收器节点3b。
<变型实例2>
在只有完整报头数据包被作为重要数据包发送的情况下，跟其它数据包比较，要发送的重要数据包的个数较少时，发送完整报头数据包的时间间隔会变长。此时，可以想到，收到的许多压缩报头数据包会因为丢失了压缩报头数据包而被丢弃，直到收到下一个完整报头数据包。为了避免这种情况，可以在发送完整报头数据包F以后，经过了预定时间T以后还没有收到重要数据包(换句话说，没有发送完整报头数据包)的时候，下一个要发送的数据包就作为完整报头数据包F发送，即使这个数据包不是重要数据包，如图4A所示。或者，发送了完整报头数据包F以后，发送了某个数目N的压缩报头数据包而没有收到重要数据包的时候，就将数据包作为完整数据包F发送，而不管下一个要发送的数据包是不是重要数据包。
此外，发送了N个数据包或者发送了T时间的数据包的时候，让发送器节点里的中继装置将非压缩数据包转换成完整报头数据包F，并将这个完整报头数据包发送给接收器节点，即使这个非压缩数据包不是重要数据包。
利用以上方法，可以避免发送完整报头数据包的时间间隔过长，即使要发送的数据包里获得的重要数据包的个数很少。这样，由于数据包丢失而丢弃的数据包的个数被减少。
在静态字段的内容可能会发生改变的情况下，即使跟变型实例1里一样采用了上述结构，也有必要考虑除了重要数据包以外静态字段的内容发生了改变的数据包，以及每隔固定个数选择的数据包，作为增加完整报头的数据包。
<变型实例3>
如上所述，在方法2那样的传统技术里，当接收器节点3b检测到在发送器节点3a和接收器节点3b之间丢失了数据包的时候，接收器节点发送CONTEXT_STATE给发送器节点3a，请求发送完整报头数据包。具体地说，可以让发送器节点3a里的控制部分33a将重要数据包作为完整报头数据包，与此同时，控制部分在收到接收器节点3b发送的CONTEXT_STATE以后将要发送的数据包作为完整报头数据包发送。在这一变型实例中也要考虑将静态字段以后的数据包作为完整报头数据包发送，如同上述变型实例2那种情形一样。
<变型实例4>
除了前面的实施方案列出的那些以外，还有以下IP数据包要作为重要数据包考虑。
a．如果要传输的数据包里是用包括帧内编码过程和帧间预测编码过程的动画图像压缩编码算法(例如，对应于MPEG(运动图形专家组)的动画图像编码算法)获得的视频数据，就将包括用帧内编码过程获得的数据的IP数据包(也就是I帧的编码数据)作为重要数据包，其原因是，除非接收器正确地恢复了I帧，否则，后面的帧间预测编码的I帧无法正确地恢复出来。
b．如果要发送的是包括底层数据和增强层数据的分层编码数据，就将包括底层数据的IP数据包作为重要数据包。底层数据指的是接收器对分层编码数据译码的时候，对于恢复原始信息非常重要的数据。另外，增强层数据指的是不象底层数据那么重要，但正确地译码以后能够提高原始信息再生质量的数据。例如，在跟MPEG-2兼容的动画图像压缩编码算法里，要发送的一系列帧被划分成I帧、P帧和B帧。对I帧进行帧内编码。参考前一个I帧或者P帧对P帧采用单向帧间预测编码。参考前后的I帧或者P帧对B帧进行双向帧间预测编码。此时，I帧和P帧的编码数据是底层的数据，B帧的编码数据是增强层的数据。译码器可以再生动画图像，尽管它的时间分辨力很低，直到至少底层的数据被正确地收到。这样，底层的数据非常重要，从而将底层的数据作为重要数据包发送。在译码器里对增强层里的数据进行译码的时候，将B帧用于补偿I帧和P帧之间的时间间隙，从而提高动画图像的时间分辨力。
B．第二个实施方案
在上面第一个实施方案里，发送器节点3a里的中继装置能够将IP数据包转换成压缩报头数据包或者完整报头数据包(以后叫做“压缩功能”)，而接收器节点3b里的中继装置能够将压缩报头数据包或者完整报头数据包转换成IP数据包(以后叫做“解压缩功能”)。相反，在这个实施方案里，图1所描述的发送器数据终端和接收数据节点3具有压缩功能，而发送器节点3a和接收器数据终端2具有解压缩功能。
实际上，接收器数据终端1按顺序产生要发送的IP数据包，然后，按照第一个实施方案里的方式判断这些IP数据包是不是重要数据包。发送器数据终端1将认定为重要数据包的IP数据包作为完整报头数据包发送给发送器节点3a，而将其余数据包作为压缩报头数据包发送给发送器节点3a。
另一方面，发送器节点3a里的中继装置将收到的压缩报头数据包或者完整报头数据包转换成IP数据包并将它发送给接收器节点3b。此外，接收器节点3b上的中继装置判断来自发送器节点3a的每一个IP数据包是不是重要数据包，并将认定是重要数据包的IP数据包作为完整报头数据包发送给接收器数据终端2，而将其余IP数据包作为压缩报头数据包发送给接收器数据终端2。接收器数据终端2在从接收器节点3b收到的完整报头数据包或者压缩报头数据包的基础之上恢复IP数据包，然后按照从每一个数据包获得的数据显示图像或者播放声音等等。按照这种结构能够获得跟第一个实施方案的效果相同的效果。
如上所述，可以让发送器数据终端能够将要在IP数据包里发送的重要数据包作为完整报头数据包发送。具体地说，本发明的这一数据包传输方法可以用于任意装置在网络中实现数据包传输和接收。换句话说，权利要求中定义的“发送器”和“接收器”并不限于在数据终端之间交换数据包的数据包中继装置，而是包括作为数据包发送器的数据终端和作为数据包目的地的数据终端。
在这一实施方案里，还可以将发送器配制成将重要数据包和具有改变了的静态字段的IP数据包，就象第一个实施方案里的变型实例(变型实例1)所介绍的一样，在没有发送IP数据包要发送的完整报头数据包一定时间过去了以后发送的IP数据包，或者在发送完固定个数压缩报头数据包而没有发送完整报头数据包以后发送的IP数据包(变型实例2)，以及从发送器节点3a收到CONTEXT_STATE以后要发送的IP数据包，作为当作完整报头数据包发送的数据包。
C．第三个实施方案
跟上面的实施方案一样，这个实施方案假设数据包是通过UDP这样的非TCP协议传输的。RFC 2507将具有图5所示格式的压缩过的非TCP报头定义成能够用于非TCP数据包的压缩报头。有可能每个数据包里，非TCP数据包的报头里IP和RTP的ID的字段都发生改变。压缩过的非TCP报头包括由那些字段组成的字段，每个数据包里它们的数据都不相同。为了方便，将这样获得的压缩过的非TCP报头中的字段叫做“替换字段”。图5所示的IP和RTP的ID是这些替换字段。每个压缩过的非TCP报头都参考它前面的完整报头来产生。图5里的CID是用来识别为了产生压缩过的非TCP报头而引用的完整报头的信息。“产生”是完整报头的恒定字段发生改变的时候更新的字段。
从发送器节点收到压缩过的非TCP报头的时候，接收器节点里的通信装置参考压缩过的非TCP报头和用压缩过的非TCP报头中包括的CID识别的完整报头，并产生有压缩过的非TCP报头的替换字段的报头和完整报头的其它字段。然后，通信装置利用产生的报头来处理非TCP数据包。
从发送器节点向接收器节点传递非TCP数据包的时候，会出现所谓的同步丢失。在RFC 2507里建议了一种方法，用于从同步丢失快速恢复过来。根据这一建议，以指数方式增长的间隔重复地发送完整报头，如图6A所示。
前面是RFC 2507里介绍的非TCP数据包的报头压缩方法的概况。
在这一实施方案里，将本发明的方法应用到上述对非TCP数据包的报头压缩方法里去。图6B和6C分别给出了这一实施方案的数据包传输方法。
在图6B所示的传输方法里，传输重要数据包的时候，发送包括压缩非TCP报头的更新报头数据包RHP而不是完整报头数据包。压缩过的非TCP报头包括从同步丢失恢复过来所需要的所有信息。因此，获得了跟第一个实施方案相同的效果，即使发送的是压缩过的非TCP报头而不是完整报头。
在图6C所示的传输方法里，当同步丢失的时候，将重要数据包作为更新报头数据包RHP发送，而更新报头数据包则以间歇方式发送，直到对应于重要数据包的更新报头数据包RHP出现。此时，连续两个更新报头数据包RHP之间的时间间隔或者数据包个数按指数方式增加的时候，重复发送更新报头数据包RHP。
在这一实施方案里，可以获得第一个实施方案那样的效果。
D．第四个实施方案
IP数据包有另一个报头压缩方法：ROHC(坚固的报头压缩)，它被作为一个因特网草案发布。这个实施方案涉及这一数据包压缩方法和利用这个ROHC方法的传输方法。
第一个到第三个实施方案已经描述了在开始发送数据包的时候以及在数据包的传递过程中传输包括原始报头内容的完整报头，作为一个更新报头在接收器里恢复同步。在利用这一ROHC的数据包压缩和传输方法里，不是完整报头格式的更新报头从发送器发送出来，在接收器里恢复同步。然后，将描述ROHC的要点以帮助理解本发明的技术含义。
图7说明用于ROHC的压缩状态的过渡。如图所示，ROHC有三种压缩状态。
在发送器节点和接收器节点之间传递压缩报头数据包的时候，从一开始，就分别在发送器节点和接收器节点启动压缩过程和重构过程。此外，在数据包的发送和接收过程中同步丢失时，压缩过程和重构过程不得不回到初始状态，以便在发送器节点和接收器节点之间恢复同步。在压缩过程和重构过程初始化以后，满足某种条件时，发送器节点里压缩过程的状态和接收器节点里重构过程的状态过度到差值改变状态，这个状态是更上一层的状态。在这一状态中满足某一条件时，压缩和重构的处理状态转换成差值恒定状态，这个状态是更上一层的状态。当压缩和重构处理状态过渡到更上层状态的时候，要发送的压缩报头的大小变得更小。
在初始状态，发送图8A描述的IR报头或者图8B描述的IR-DYN报头。
当利用报头压缩的数据包传递开始的时候，IR报头是从第一个数据包的IP/UDP/RTP报头产生的，以便初始化压缩过程和重构过程。在图8A里，静态链包括静态字段的信息，在IP/UDP/RTP报头里它不是在每个数据包里都会改变。动态链包括动态字段的信息，在IP/UDP/RTP报头里不同数据包里它都会不同。
在报头压缩已经开始，并且已经发送给接收器以后，在数据包传输过程中同步丢失时，以及接收器里需要报头重构过程的初始化的时候，产生IR-DYN报头。IR-DYN报头只包括动态链，如图8B所示。由于动态链包括动态字段的所有信息，通过在接收器节点接收它们而恢复同步。
IR报头和IR-DYN报头都包括利用原始IP/UDP/RTP报头计算出来的CRC。接收IR报头和IR-DYN报头的节点可以通过利用CRC来检查每一个报头是不是已经正确地恢复。
发送器节点里的通信装置在数据包之间监视按顺序发送的数据包的IP/UDP/RTP报头的动态字段的差。这个差没有任何改变的时候(也就是差值恒定状态)，产生包括图9A描述的O型的压缩报头数据包，并发送给接收器节点。在图9A里，SN代表RTP的序列号。接收O型报头的时候，接收器节点发现在数据包之间动态字段的差没有任何改变。但只将这个时刻动态字段的差加到当前值上去，以便重构动态字段。
当发送器节点里的通信装置发现差发生了改变的时候(也就是说差值改变状态)，发送器节点里的通信装置产生包括1型报头或者2型报头，将新的差发送给接收器节点的压缩报头数据包，并将它发送给接收器节点。1型报头的格式在图9B里描述，2型报头的格式在图9C里描述。在这些附图中，SN表示涉及RTP序列号的差的信息，TS代表跟RTP时标中的差有关的信息。发送1型报头还是发送2型报头是任选的。
上面提到的跟差有关的信息是通过对应字段的LSB(最低有效位)编码来获得的。图10说明了LSB编码的步骤。
在这一方法中，当数据包之间报头的某些字段的差发生改变的时候，将要压缩的数据包前面的一个或者多个数据包选出来作为参考数据包。选择哪些数据包作为参考数据包是任意的。将要压缩的数据包的报头的字段和这样选出来的参考数据包的报头的对应字段进行比较，然后发送不同的低位。在图10所描述的实例里，由于低四位不同，用1型报头或者2型报头将低四位发送给接收器节点。在接收器节点里，参考数据包报头对应字段里的低四位用1型报头或者2型报头里的低四位来替换，这样就能重构原来的字段。
上面是因特网草案里建议的ROHC的概况。
图11描述的是这一实施方案的数据包传输方法。
在这一实施方案里，发送重要数据包的时候，重要数据包的IP/UDP/RTP报头被转换成IR报头、IR-DYN报头、1型报头或者2型报头中的一种，包括这样转换过来的这一报头的更新报头数据包被发送给接收器节点。下面将给出更加具体的描述。
在ROHC的压缩包头数据包传输中，会发生接收器节点里的通信装置收到报头，并且报头的内容被正确地恢复这样的情况，从接收器节点发送ACK，将这一情况告诉发送器节点。在这一实施方案里，从接收器节点收到这个ACK以后产生要发送的重要数据包的时候，参考前面已经发送和确认的报头，从重要数据包的IP/UDP/RTP报头产生1型报头或者2型报头。然后将包括这样产生的1型和2型报头的更新报头数据包发送给接收器节点。这样发送的1型或者2型报头包括数据，说明重要数据包IP/UDP/RTP报头里动态字段之间的差，以及发送器节点已经收到了ACK的确认数据包的那些。
由于1型报头和2型报头包括的信息足以恢复同步，即使在发送重要数据包以前就丢失了数据包，重要数据包里的报头都被正确地重构而没有任何问题。这样，重要数据包得到保护，不会出现导致同步丢失的数据包丢失。
会出现这样的情况，重要数据包已经被发送，但是还没有任何报头已经被发送和确认。在这种情况下，从重要数据包的IP/UDP/RTP报头产生IR报头或者IR-DYN报头，包括它的更新报头数据包被发送给接收器节点。
在这一实施方案里，重要数据包可以得到保护，不会出现导致同步丢失的数据包丢失。
E．上述实施方案中每一个的变型实例
上面描述的所有实施方案都公开了用于IRv4数据包传输的数据包传输方法。然而，本发明的应用范围不限于此。本发明可以用于传输IPv6数据包。图12给出了IPv6报头的格式。如图所示，IPv6具有静态字段，在数据包之间它不会改变，还具有动态字段，在数据包之间会改变，以及删除的字段，它具有已知的值，或者可以从其它字段重构。因此，在每一个实施方案里或者它们的变种里描述的这一数据包传输方法，可以被用于具有IP/UDP/RTP报头的非压缩数据包，其中的IP部分包括IPv6报头。
可以这样来应用本发明，将用于执行本发明的数据包传输方法的程序存入计算机能够读出来的存储媒介里交给用户，或者通过电子通信电路将这样的程序提供给用户。

Claims (25)

1．一种数据包传输方法，用于通过网络从发送器节点向接收器节点传输数据包，包括以下步骤：
发送器节点里的通信装置进行转换，用于将要发送的非压缩数据包转换成具有更新报头的更新报头数据包，这个更新报头包括足以在接收器节点里恢复同步的信息；或者转换成具有压缩报头的压缩报头数据包，这个压缩报头包括的信息比更新报头的少，这样，只要这个数据包是重要数据包，非压缩数据包里的所有数据包都被转换成更新报头数据包；和
将包括更新报头数据包和压缩报头数据包的数据包流发送给接收器节点。
2．权利要求1的数据包传输方法，其中的更新报头包括一个完整报头，其中包括非压缩数据包包括的原始报头里的内容。
3．权利要求1的数据包传输方法，其中更新报头的格式包括第一个格式，这个格式能够用于接收器节点开始接收这一数据包流的通信装置里重构过程的第一次初始化，还包括第二个格式，这第二个格式能够用于第二次初始化和以后的初始化，和
发送器节点里的通信装置将数据包流中第二个和后面的数据包流中的重要数据包转换成包括更新报头的更新报头数据包，并发送给接收器节点，这个更新报头包括第二个格式。
4．权利要求1的数据包传输方法，其中的更新报头包括一个报头，这个报头是通过参考接收器节点里通信装置中的重构得到了确认的一个报头产生的。
5．权利要求1的数据包传输方法，还包括一项操作，用于在非压缩数据包中包括的实时传输协议报头的标志位的情形基础之上，通过发送器节点里的通信装置确定要发送的非压缩数据包中的每一个是否重要数据包。
6．权利要求5的数据包传输方法，当非压缩数据包前面的一个非压缩数据包的标志位已经被置位的时候，其中的非压缩数据包被确定为重要数据包。
7．权利要求5的数据包传输方法，当非压缩数据包里的标志位被置位的时候，其中的非压缩数据包被确定为重要数据包。
8．权利要求1的数据包传输方法，还包括一项操作，用于在非压缩数据包的大小的基础之上，通过发送器节点里的通信装置确定要发送的每一个非压缩数据包是否重要数据包。
9．权利要求8的数据包传输方法，当非压缩数据包的大小超过预定大小的时候，其中的非压缩数据包被确定为重要数据包。
10．权利要求8的数据包传输方法，当非压缩数据包的大小大于预定大小，而且下一个非压缩数据包报头的大小小于预定大小时，或者当非压缩数据包的大小小于预定大小，而且下一个非压缩报头比预定大小大的时候，其中的非压缩数据包被确定为重要数据包。
11．权利要求1的数据包传输方法，其中的重要数据包包括一个非压缩数据包，其中包括结构信息，以便在接收器节点里参考这样的信息来解释数据包里的数据。
12．权利要求1的数据包传输方法，其中每个数据包里的数据都包括代表几帧图像的至少部分图像数据，和
重要数据包包括一个数据包，这个数据包里包括每个所述帧的第一个信息。
13．权利要求12的数据包传输方法，当非压缩数据包包括不同于前面的非压缩数据包里包括的时标的一个时标时，其中的非压缩数据包被确定为这一帧的第一个数据包。
14．权利要求1的数据包传输方法，其中每个数据包里的数据都代表话音，和
重要数据包包括非压缩数据包，非压缩数据包包括代表话音部分的数据。
15．权利要求14的数据包传输方法，其中包括代表话音部分的数据的非压缩数据包是在要发送的一组非压缩数据包的数据包大小的的改变的基础之上获得的。
16．权利要求1的数据包传输方法，其中每一个数据包里的数据都包括代表几帧图像的至少一部分编码数据，这几帧是利用包括帧内编码过程和帧间预测编码过程的一个算法来获得的，和
重要数据包包括一个数据包，这个数据包包括帧内编码过程获得的编码数据。
17．权利要求1的数据包传输方法，其中每个数据包里的数据都包括至少部分分层编码数据，这个分层编码数据包括底层数据和增强层里的数据，和
重要数据包包括一个数据包，其中包括底层的数据。
18．权利要求1的数据包传输方法，其中发送完最后一个完整报头数据包以后经过了预定长度的时间或者发送了预定个数的压缩报头数据包，发送器节点里的通信装置就将非压缩数据包转换成完整报头数据包，即使这一非压缩数据包不是重要数据包。
19．权利要求1的数据包传输方法，其中已经发送了某个数目的数据包的时候，或者发送了某个时间长度的数据包的时候，发送器节点里的通信装置发送更新报头数据包。
20．权利要求1的数据包传输方法，其中在数据包通信中同步丢失的时候，发送器节点里的通信装置发送更新报头数据包，同时按指数规律增加它们的传输时间间隔。
21．权利要求1的数据包传输方法，其中发送器节点里的通信装置响应接收器节点的请求，将非压缩数据包作为更新报头数据包发送出去。
22．一种程序，用于让计算机执行一个数据包传输方法，通过网络从发送器节点向接收器节点传输数据包，这个方法包括以下步骤：
发送器节点里的通信装置进行转换，用于将要发送的非压缩数据包转换成具有更新报头的更新报头数据包，这个更新报头包括足以在接收器节点里恢复同步的信息；或者转换成具有压缩报头的压缩报头数据包，这个压缩报头包括的信息比更新报头的少，这样，非压缩数据包里的所有数据包都被转换成更新报头数据包，只要这个数据包是重要数据包；和
将包括更新报头数据包和压缩报头数据包的数据包流发送给接收器节点。
23．一种计算机能够读取的存储媒介，用于储存程序，这个程序是计算机执行一个数据包传输方法，通过网络从发送器节点向接收器节点传输数据包，这个方法包括以下步骤：
发送器节点里的通信装置进行转换，用于将要发送的非压缩数据包转换成具有更新报头的更新报头数据包，这个更新报头包括足以在接收器节点里恢复同步的信息；或者转换成具有压缩报头的压缩报头数据包，这个压缩报头包括的信息比更新报头的少，这样，非压缩数据包里的所有数据包都被转换成更新报头数据包，只要这个数据包是重要数据包；和
将包括更新报头数据包和压缩报头数据包的数据包流发送给接收器节点。
24．网络里用于从网络的发送器节点接收数据包并发送数据包给网络的接收器节点的一种中继装置，这种中继装置包括：
一个压缩器，用于将要发送的非压缩数据包转换成具有更新报头的更新报头数据包，这个更新报头包括足以在接收器节点里恢复同步的信息；或者转换成具有压缩报头的压缩报头数据包，这个压缩报头包括的信息比更新报头的少，这样，非压缩数据包里的所有数据包都被转换成更新报头数据包，只要这个数据包是重要数据包；和
数据包流的一个发送器，用于将包括更新报头数据包和压缩报头数据包的数据包流发送给接收器节点。
25．一种数据终端，包括：
一个压缩器，用于将要发送的非压缩数据包转换成具有更新报头的更新报头数据包，这个更新报头包括足以在接收器节点里恢复同步的信息；或者转换成具有压缩报头的压缩报头数据包，这个压缩报头包括的信息比更新报头的少，这样，非压缩数据包里的所有数据包都被转换成更新报头数据包，只要这个数据包是重要数据包；和
数据包流的一个发送器，用于将包括更新报头数据包和压缩报头数据包的数据包流发送给接收器节点。
CNB011089482A 2000-03-03 2001-03-02 压缩报头传输数据包的方法和装置 Expired - Fee Related CN1165138C (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP59367/2000 2000-03-03
JP2000059367 2000-03-03

Publications (2)

Publication Number Publication Date
CN1311590A true CN1311590A (zh) 2001-09-05
CN1165138C CN1165138C (zh) 2004-09-01

Family

ID=18579829

Family Applications (1)

Application Number Title Priority Date Filing Date
CNB011089482A Expired - Fee Related CN1165138C (zh) 2000-03-03 2001-03-02 压缩报头传输数据包的方法和装置

Country Status (4)

Country Link
US (1) US7061936B2 (zh)
EP (1) EP1146713B1 (zh)
CN (1) CN1165138C (zh)
DE (1) DE60110303T2 (zh)

Cited By (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100337455C (zh) * 2003-09-04 2007-09-12 国际商业机器公司 用于压缩消息头部的方法
CN100459710C (zh) * 2005-03-17 2009-02-04 华为技术有限公司 一种数据流头压缩中的全头包发送方法
CN100463445C (zh) * 2005-08-09 2009-02-18 大唐移动通信设备有限公司 数据包序列号计算方法及数据包传输方法
WO2009086690A1 (en) * 2008-01-04 2009-07-16 Lucent Technologies Inc. Transmission methods, network equipment, user equipment and telecommunication system
CN101102263B (zh) * 2006-07-07 2010-05-12 华为技术有限公司 压缩报文恢复方法及装置
CN101159667B (zh) * 2007-10-16 2010-09-01 中兴通讯股份有限公司 用于移动多媒体广播系统对分组数据进行报头压缩的方法
CN1977516B (zh) * 2004-05-13 2010-12-01 高通股份有限公司 无线通信系统上传输数据的方法和无线通信设备
CN101146025B (zh) * 2006-09-13 2010-12-08 华为技术有限公司 压缩实时传输协议的报文传输方法和系统以及压缩端单元
CN1706137B (zh) * 2002-01-16 2011-02-02 雷西昂公司 用于压缩数据通信用的信元标头的方法和系统
CN102347771A (zh) * 2010-07-30 2012-02-08 Arm有限公司 递增计数值的分布
CN1650584B (zh) * 2002-03-20 2012-11-28 英特尔公司 无线局域网中报头压缩的方法和装置
CN101453298B (zh) * 2007-12-07 2013-06-05 华为技术有限公司 一种无线网络中头压缩的处理方法及系统、装置
CN101754275B (zh) * 2002-08-14 2013-07-17 Lg电子株式会社 双向分组数据传输系统和方法
CN101981894B (zh) * 2008-01-30 2014-11-26 高通股份有限公司 基于中继的报头压缩
CN109104435A (zh) * 2018-10-12 2018-12-28 中国科学院上海高等研究院 一种实现数据按序传送的方法
CN109672929A (zh) * 2018-12-14 2019-04-23 中国联合网络通信集团有限公司 一种视频业务报文的检测方法和设备
CN112769705A (zh) * 2020-12-01 2021-05-07 北京电子工程总体研究所 一种适用于小型局域网的VoIP报头压缩方法

Families Citing this family (62)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7788211B2 (en) * 2000-06-16 2010-08-31 Nokia Networks Oy Robust and efficient compression of list of items
US20040136380A1 (en) * 2000-09-12 2004-07-15 Daiji Ido Packet transmitter, packet receiver and packet transmission method
US6766376B2 (en) 2000-09-12 2004-07-20 Sn Acquisition, L.L.C Streaming media buffering system
US7386000B2 (en) * 2001-04-17 2008-06-10 Nokia Corporation Packet mode speech communication
FI118244B (fi) 2001-06-27 2007-08-31 Nokia Corp Otsikkokenttien kompressiotunnisteen välittäminen datapakettiyhteydellä
JP3617967B2 (ja) 2001-09-28 2005-02-09 松下電器産業株式会社 ヘッダ圧縮パケット受信装置及び方法
SE523862C2 (sv) * 2001-10-19 2004-05-25 Operax Ab Ett förfarande och en apparat för att överföra datapaket i IP-routrar
KR100431003B1 (ko) * 2001-10-31 2004-05-12 삼성전자주식회사 데이터 송수신 시스템 및 방법
US7836124B2 (en) * 2001-11-16 2010-11-16 Clearwire Legacy Llc RTP, UDP, IP header compression on the circuit switched type airlink access
EP1968277B1 (en) 2001-11-24 2011-03-16 LG Electronics, Inc. Method for transmitting packet data in compressed form in a communication system
SE521600C2 (sv) 2001-12-04 2003-11-18 Global Ip Sound Ab Lågbittaktskodek
JP3844686B2 (ja) * 2001-12-13 2006-11-15 株式会社エヌ・ティ・ティ・ドコモ ルータ装置、端末装置、通信システム及びルーティング方法
US7519455B2 (en) * 2002-06-10 2009-04-14 Robert Bosch Gmbh Method and device for a vehicle-related telematics service
US8619592B2 (en) * 2002-06-12 2013-12-31 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for increased internet protocol (IP) headers compression performance by reporting cause of missing packets
KR100497357B1 (ko) * 2002-06-26 2005-06-23 삼성전자주식회사 인터넷 프로토콜 기반 네트워크 환경에 있어서 헤더 압축및 패킷 다중화 장치와 그 방법
JP3745709B2 (ja) * 2002-06-28 2006-02-15 インターナショナル・ビジネス・マシーンズ・コーポレーション 符号化装置、復号化装置、符号化方法、復号化方法、プログラム、プログラム記録媒体、及びデータ記録媒体
JP4317403B2 (ja) * 2002-08-09 2009-08-19 パナソニック株式会社 ヘッダ圧縮装置及びヘッダ圧縮方法
US7324516B2 (en) * 2002-08-14 2008-01-29 Intel Corporation Data packet header conversion
KR100663586B1 (ko) * 2002-08-28 2007-01-02 삼성전자주식회사 헤더 압축에 의한 패킷 데이터의 송신 방법 및 장치
US7738552B2 (en) * 2002-12-06 2010-06-15 Broadcom Company Processing data streams
US7386013B1 (en) * 2003-01-03 2008-06-10 Juniper Networks, Inc. Systems and methods for compressing packet headers
US7272658B1 (en) 2003-02-13 2007-09-18 Adobe Systems Incorporated Real-time priority-based media communication
US7450586B2 (en) * 2003-07-22 2008-11-11 Motorola, Inc. Network header compression arrangement
JP4185426B2 (ja) * 2003-09-16 2008-11-26 株式会社リコー 端末
TWI225343B (en) * 2003-10-24 2004-12-11 Benq Corp Method for video data transmission in a wireless network
US20100316116A1 (en) * 2003-12-08 2010-12-16 John Iler Processing data streams
US7430617B2 (en) * 2003-12-19 2008-09-30 Nokia Corporation Method and system for header compression
DE102004003551A1 (de) * 2004-01-23 2005-08-18 Siemens Ag Kompressionsverfahren für einen Bytestrom in Netzwerkprotokollen
KR100678055B1 (ko) * 2004-02-12 2007-02-01 삼성전자주식회사 멀티미디어 방송/멀티캐스트 서비스 시스템에서 헤더 복원 동작을 재개하는 방법
US20050238008A1 (en) * 2004-04-23 2005-10-27 Fraser Alexander G Method and apparatus for the encapsulation of control information in a real-time data stream
CN101902433B (zh) * 2004-04-30 2013-04-10 夏普株式会社 无线通信系统
SE0401346D0 (sv) * 2004-05-24 2004-05-24 Ericsson Telefon Ab L M Methods for Increased Tolerance Against Packet Reordering for the Secure Reference Principle in Robust Header Compression
EP1751981B1 (en) 2004-05-31 2016-08-31 Panasonic Intellectual Property Management Co., Ltd. Digital broadcasting system and digital broadcast transmission and reception method
IL162305A (en) * 2004-06-02 2010-06-16 Eci Telecom Ltd Method, device and system for transmitting ethernet packets
KR100651715B1 (ko) * 2004-10-07 2006-12-01 한국전자통신연구원 차세대 인터넷에서 자동으로 주소를 생성하고 수락하는방법 및 이를 위한 데이터 구조
US7817628B2 (en) * 2004-11-15 2010-10-19 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for header compression with transmission of context information dependent upon media characteristic
US8184561B2 (en) * 2004-12-22 2012-05-22 Nokia Corporation Terminal based packet loss due to mobility detection
JP4725262B2 (ja) * 2005-09-14 2011-07-13 富士フイルム株式会社 画像形成装置
KR100748342B1 (ko) 2005-09-14 2007-08-09 매그나칩 반도체 유한회사 씨모스 이미지 센서의 제조방법
US7907609B2 (en) * 2006-01-06 2011-03-15 Qualcomm, Incorporated Method and apparatus for enhancing RoHC performance when encountering silence suppression
US20070237144A1 (en) * 2006-03-30 2007-10-11 Avaya Technology Llc Transporting authentication information in RTP
US8306063B2 (en) 2006-08-29 2012-11-06 EXFO Services Assurance, Inc. Real-time transport protocol stream detection system and method
US8045589B2 (en) * 2007-04-26 2011-10-25 Kyocera Corporation Radio communication system with data structure change
US20090080422A1 (en) * 2007-09-21 2009-03-26 Posdata Co., Ltd. Header-compression packet processing method, mobile station, base station, and control station in wireless communication system
US7961878B2 (en) 2007-10-15 2011-06-14 Adobe Systems Incorporated Imparting cryptographic information in network communications
US8306015B2 (en) * 2007-11-22 2012-11-06 Hewlett-Packard Development Company, L.P. Technique for identifying RTP based traffic in core routing switches
WO2009104284A1 (ja) * 2008-02-19 2009-08-27 富士通株式会社 ストリームデータ管理プログラム、方法、及びシステム
CA2722857A1 (en) * 2008-04-28 2010-07-22 Xg Technology, Inc. Header compression mechanism for transmitting rtp packets over wireless links
US8483129B2 (en) * 2008-11-17 2013-07-09 Xg Technology, Inc. RTP voice packets for base station hand-off in mobile IP telephony
EP2452480B1 (en) 2009-07-08 2018-03-21 Thomson Licensing DTV Backward looking robust header compression receiver
US20110016313A1 (en) * 2009-07-15 2011-01-20 Qualcomm Incorporated HEADER COMPRESSION FOR TUNNELED IPsec PACKET
US20110149848A1 (en) * 2009-08-17 2011-06-23 Qualcomm Incorporated Header compression for relay nodes
EP3010161A1 (en) 2010-04-01 2016-04-20 LG Electronics Inc. Multiple physical layer pipes (plb) with mutual information
GB2483282B (en) * 2010-09-03 2017-09-13 Advanced Risc Mach Ltd Data compression and decompression using relative and absolute delta values
US20130128809A1 (en) * 2011-05-19 2013-05-23 Qualcomm Incorporated Apparatus and methods for media access control header compression
US20130155929A1 (en) * 2011-12-15 2013-06-20 Futurewei Technologies, Inc. System and Method for Communicating Using Short-Header Frames
AU2013387114B2 (en) * 2013-04-17 2018-02-22 Interdigital Vc Holdings, Inc. Method and apparatus for packet header compression
WO2016093586A1 (ko) 2014-12-10 2016-06-16 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
EP3304970B1 (en) * 2015-05-29 2019-04-17 Telefonaktiebolaget LM Ericsson (PUBL) Methods for compression and decompression of headers of internet protocol packets, devices, computer programs and computer program products
RU2687217C1 (ru) * 2018-06-20 2019-05-07 Открытое Акционерное Общество "Информационные Технологии И Коммуникационные Системы" Способ предотвращения фрагментации TCP/IP-пакетов при использовании VPLS в сети с коммутацией пакетов
FR3090936B1 (fr) * 2018-12-21 2021-12-10 Thales Sa Procédé d’authentification d’un équipement, dispositif d’émission, dispositif de réception, système de communication et aéronef associés
CN113709510A (zh) * 2021-08-06 2021-11-26 联想(北京)有限公司 高速率数据实时传输方法及装置、设备、存储介质

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6032197A (en) * 1997-09-25 2000-02-29 Microsoft Corporation Data packet header compression for unidirectional transmission
FI107000B (fi) * 1999-02-17 2001-05-15 Nokia Mobile Phones Ltd Otsikon pakkaaminen reaaliaikaisissa palveluissa
US6754231B1 (en) * 1999-06-18 2004-06-22 Telefonaktiebolaget Lm Ericsson (Publ) Robust header compression in packet communications
US6680955B1 (en) * 1999-08-20 2004-01-20 Nokia Networks Oy Technique for compressing a header field in a data packet
US6882637B1 (en) * 1999-10-14 2005-04-19 Nokia Networks Oy Method and system for transmitting and receiving packets
US6608841B1 (en) 1999-12-30 2003-08-19 Nokia Networks Oy System and method for achieving robust IP/UDP/RTP header compression in the presence of unreliable networks
US6650623B1 (en) 1999-12-30 2003-11-18 Aperto Networks, Inc. Adaptive link layer for point to multipoint communication system
JP3730835B2 (ja) * 2000-03-03 2006-01-05 株式会社エヌ・ティ・ティ・ドコモ パケット伝送方法、中継装置およびデータ端末

Cited By (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1706137B (zh) * 2002-01-16 2011-02-02 雷西昂公司 用于压缩数据通信用的信元标头的方法和系统
CN1650584B (zh) * 2002-03-20 2012-11-28 英特尔公司 无线局域网中报头压缩的方法和装置
US9635142B2 (en) 2002-08-14 2017-04-25 Lg Electronics Inc. Bi-directional packet data transmission system and method
US8848684B2 (en) 2002-08-14 2014-09-30 Lg Electronics Inc. Bi-directional packet data transmission system and method
US9635140B2 (en) 2002-08-14 2017-04-25 Lg Electronics Inc. Bi-directional packet data transmission system and method
US9635141B2 (en) 2002-08-14 2017-04-25 Lg Electronics Inc. Bi-directional packet data transmission system and method
CN101754275B (zh) * 2002-08-14 2013-07-17 Lg电子株式会社 双向分组数据传输系统和方法
CN100337455C (zh) * 2003-09-04 2007-09-12 国际商业机器公司 用于压缩消息头部的方法
CN1977516B (zh) * 2004-05-13 2010-12-01 高通股份有限公司 无线通信系统上传输数据的方法和无线通信设备
CN100459710C (zh) * 2005-03-17 2009-02-04 华为技术有限公司 一种数据流头压缩中的全头包发送方法
CN100463445C (zh) * 2005-08-09 2009-02-18 大唐移动通信设备有限公司 数据包序列号计算方法及数据包传输方法
CN101102263B (zh) * 2006-07-07 2010-05-12 华为技术有限公司 压缩报文恢复方法及装置
CN101146025B (zh) * 2006-09-13 2010-12-08 华为技术有限公司 压缩实时传输协议的报文传输方法和系统以及压缩端单元
CN101159667B (zh) * 2007-10-16 2010-09-01 中兴通讯股份有限公司 用于移动多媒体广播系统对分组数据进行报头压缩的方法
CN101453298B (zh) * 2007-12-07 2013-06-05 华为技术有限公司 一种无线网络中头压缩的处理方法及系统、装置
CN101911643B (zh) * 2008-01-04 2013-08-14 朗讯科技公司 传输方法、网络设备、用户设备和电信系统
CN101911643A (zh) * 2008-01-04 2010-12-08 朗讯科技公司 传输方法、网络设备、用户设备和电信系统
WO2009086690A1 (en) * 2008-01-04 2009-07-16 Lucent Technologies Inc. Transmission methods, network equipment, user equipment and telecommunication system
CN101981894B (zh) * 2008-01-30 2014-11-26 高通股份有限公司 基于中继的报头压缩
US8995469B2 (en) 2008-01-30 2015-03-31 Qualcomm Incorporated Relay based header compression
CN102347771B (zh) * 2010-07-30 2016-08-03 Arm有限公司 递增计数值的分布
CN102347771A (zh) * 2010-07-30 2012-02-08 Arm有限公司 递增计数值的分布
CN109104435A (zh) * 2018-10-12 2018-12-28 中国科学院上海高等研究院 一种实现数据按序传送的方法
CN109104435B (zh) * 2018-10-12 2021-04-06 中国科学院上海高等研究院 一种实现数据按序传送的方法
CN109672929A (zh) * 2018-12-14 2019-04-23 中国联合网络通信集团有限公司 一种视频业务报文的检测方法和设备
CN112769705A (zh) * 2020-12-01 2021-05-07 北京电子工程总体研究所 一种适用于小型局域网的VoIP报头压缩方法

Also Published As

Publication number Publication date
EP1146713B1 (en) 2005-04-27
EP1146713A3 (en) 2003-10-15
DE60110303T2 (de) 2006-03-09
DE60110303D1 (de) 2005-06-02
EP1146713A2 (en) 2001-10-17
CN1165138C (zh) 2004-09-01
US20010048680A1 (en) 2001-12-06
US7061936B2 (en) 2006-06-13

Similar Documents

Publication Publication Date Title
CN1165138C (zh) 压缩报头传输数据包的方法和装置
JP4433287B2 (ja) 受信装置および方法、並びにプログラム
US20200029130A1 (en) Method and apparatus for configuring content in a broadcast system
JP3931595B2 (ja) データ修正装置及びデータ修正方法
RU2601442C2 (ru) Способ и устройство передачи/приема мультимедиа-содержимого в системе мультимедиа
CN1217530C (zh) 传输具有数据单元序列的数据信号的服务器、系统和方法
JP2005176352A (ja) 移動通信端末機の動画像ストリーミングサービスのための無線動画像ストリーミングファイル、サービス方法及びシステム
KR101722719B1 (ko) 역방향의 강력한 헤더 압축 수신기
JP6523249B2 (ja) パケットヘッダを圧縮する方法及び装置
US8094548B2 (en) Transmission format, communication control apparatus and method, recording medium, and program
CN1643875A (zh) 数据流式传输系统和方法
CN1852429A (zh) 视频码流分组传输方法及系统
CN101300781A (zh) 控制运动图像数据在网络上的传输的系统和方法
CN1655536A (zh) 在多媒体广播/多播业务系统中恢复报头解压缩的方法
CN1976448A (zh) 用于音频和视频传输的方法和系统
CN1674676A (zh) 用于经由无线网络进行通信的服务器系统及其操作方法
KR20080045276A (ko) Ｒｔｐ 패킷에 ｖｃ―１ 정보를 캡슐화하는 방법, 이를구현하기 위한 컴퓨터 판독가능 매체, ｒｔｐ 데이터구조체, 액세스 유닛 데이터 구조체, 소스 모듈, 디코더모듈, 소스 모듈 및 디코더 모듈을 포함하는 시스템, 및타겟 모듈
CN1812587A (zh) 视频编码
CN1977516A (zh) 无线通信系统上传输的多媒体数据的报头压缩
CN1868213A (zh) 内容接收设备、视频/音频输出定时控制方法及内容提供系统
JP2006319992A (ja) マルチメディアストリーミングサービスのためのパケット転送装置及びその方法
CN1643932A (zh) 用于数据流式传输系统的数据结构
CN101926173A (zh) 运动图像收发系统
US7346054B2 (en) Method and system for co-relating transport packets on different channels using a cyclic redundancy check (CRC)
CN101296166A (zh) 基于索引的多媒体数据的测量方法

Legal Events

Date Code Title Description
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C06 Publication
PB01 Publication
C14 Grant of patent or utility model
GR01 Patent grant
C19 Lapse of patent right due to non-payment of the annual fee
CF01 Termination of patent right due to non-payment of annual fee