JP5778672B2 - バックワードルッキングロバストヘッダ圧縮レシーバ - Google Patents

バックワードルッキングロバストヘッダ圧縮レシーバ Download PDF

Info

Publication number
JP5778672B2
JP5778672B2 JP2012519532A JP2012519532A JP5778672B2 JP 5778672 B2 JP5778672 B2 JP 5778672B2 JP 2012519532 A JP2012519532 A JP 2012519532A JP 2012519532 A JP2012519532 A JP 2012519532A JP 5778672 B2 JP5778672 B2 JP 5778672B2
Authority
JP
Japan
Prior art keywords
packet
compressed data
context information
initialization
data packet
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.)
Active
Application number
JP2012519532A
Other languages
English (en)
Other versions
JP2012533213A (ja
JP2012533213A5 (ja
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.)
Thomson Licensing SAS
Original Assignee
Thomson Licensing SAS
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 Thomson Licensing SAS filed Critical Thomson Licensing SAS
Publication of JP2012533213A publication Critical patent/JP2012533213A/ja
Publication of JP2012533213A5 publication Critical patent/JP2012533213A5/ja
Application granted granted Critical
Publication of JP5778672B2 publication Critical patent/JP5778672B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22Parsing or analysis of headers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/04Protocols for data compression, e.g. ROHC
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/54Store-and-forward switching systems 
    • H04L12/56Packet switching systems
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/65Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/70Media network packetisation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/75Media network packet handling
    • H04L65/764Media network packet handling at the destination 
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/28Timers or timing mechanisms used in protocols

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Communication Control (AREA)
  • Mobile Radio Communication Systems (AREA)

Description

[関連特許出願]
本出願は米国特許仮出願第61/270,466号(2009年7月8日出願)の米国特許法第119条(e)項に規定する優先権の利益を主張し、この仮出願の全開示内容は全ての目的において本願明細書に組み込まれたものとする。
本発明はデジタル通信システム及び方法に関し、特に、パケット通信システム及びパケット通信方法に関する。
ワイヤレスリンクを使用するインターネットプロトコル(IP)が双方向音声会話または画像等の機能のために用いられる場合の問題点は、例えば、ヘッダのオーバーヘッドが大きいことである。IP電話の音声データ及び画像データは通常、リアルタイムトランスポートプロトコル(RTP)を利用して移送される。パケットは、リンク層フレーミング(link layer framing)に加え、IPヘッダ(IPv4の場合、20オクテット)、ユーザデータグラムプロトコル(UDP)ヘッダ(8オクテット)及びRTPヘッダ(12オクテット)を有する(合計で40オクテット)。IPv6の場合、IPヘッダは40オクテットであるので、合計で60オクテットとなる。パケットのペイロードのサイズは使用されるフレーム及びスピーチ符号化方法に依存し、15−20オクテット程度である。
ロバストヘッダ圧縮(ROHC:Robust Header Compression)はデータをより効率的に伝送するためにヘッダ情報を圧縮する手法を提供する(ネットワークワーキンググループ、リクエストフォーコメント3095(Network Working Group, Request for Comments 3095)を参照されたい)。圧縮は例えば、幾つかのヘッダフィールドは先験的に良く知られた値を有し、全てを送信する必要がないことを認識し、且つ、幾つかのヘッダフィールドはパケットストリームの寿命が尽きるまでの間一定でありパケットストリームの最初に一度送信するだけで良いことを認識することによって、達成される。ROHCにおいて、過去のパケットからの関連情報はコンテキストに維持される。コンテキスト情報は、その後のパケットを圧縮及び復元(解凍)する際に用いられる。イニシャライゼーションアンドリフレッシュ(IR)パケットは、伝送されているデータの完全な非圧縮コンテキストを提供する。
コンプレッサ及びデコンプレッサは、所定の事象が生じた場合に、コンテキストを更新する。欠陥(impariment)事象が生ずると、コンプレッサのコンテキストとデコンプレッサのコンテキストとの間に不一致が生ずることがあり、当該不一致により不正確な復元をしてしまう場合がある。典型的なストリーミング環境において、パケットは連続的に受信される。どのようなパケット損失であっても、コンテキストリッチな新しいパケット(例えば、IRパケット)がデコンプレッサによって受信されるまで、サービスの質を低下させるおそれがある。
バースト(burst)モデルの動作では、同じ原理が働く。しかしバースト動作においては、データがバースト形式で送出されるので、レシーバは所定時間のデータにアクセスすることができる。バースト動作は帯域幅使用効率が良いが、エラーが無いわけではない。もしバースト伝送の間に損失があれば、レシーバは複数のパケットを含む全バーストデータを捨ててしまうおそれがあり、その結果、サービスの質が低下する。これはストリーミング動作モードの場合よりも顕著であることが多い。
バースト動作は種々のシステムにおいて使用されており、その一例はデジタル放送システム(例えば、ATSC−M/H(Advanced Television Systems Committee Mobile/Handheld)規格に基づいたシステム)である。このようなシステムにおいて、複数のサービスのデータは所定の物理チャネルを介してバーストデータとして多重送信される。よって、レシーバは選択されたサービスのデータを周期的なバーストとして(安定的なストリームとしてではなく)受信する。従って、レシーバは獲得可能なバーストデータを突然得ることになり、その後、次のバーストデータを待たなければならない。各バーストデータは例えば、1秒間相当のストリーミング音声コンテンツ及び/もしくは画像コンテンツである。
しかしながら、レシーバに提供されるサービス(例えば、RTPを介した画像及び音声)は、安定的なデータストリームの概念においてモデル化されたメカニズムを介して提供される。ストリーミングモデルを使用すると、パケットは時間的に連続して受信される。後のパケットを受信する前に、レシーバは現在のパケットと当該後のパケットとの間の全てのパケットを受信する。これは概念的にバーストモデルと異なる。バーストモデルでは、レシーバは1回の受信によって所定時間長のパケットのフルセットを受信する。
例示的な実施形態において本発明の方法は、ロバストヘッダ圧縮(ROHC)デコンプレッサが後に受信されるコンテキスト・リッチなパケットを使用して、前に受信したパケットを復元する。当該前に受信したパケットについてはコンテキスト情報が受信されていない。例示的なROHCデコンプレッサは、コンテキスト情報を欠くパケットを捨てるのではなく、後に受信するコンテキストリッチなパケット(例えば、IRパケット)を用いて、当該前に受信したパケットに関連するコンテキスト情報を再形成する。このように再形成されたコンテキスト情報を使用して、当該前に受信したパケットを復元する。
上記記載に鑑みると共に下記の詳細な説明から明らかになるように、他の実施形態及び構成を採用することも可能であり、それらは本発明の原理の範囲内にある。
本発明の装置及び/または方法の幾つかの実施形態が、例示として、図面を参照しつつ以下に記載される。
典型的なROHCシステムの概略図である。 ROHCシステムにおけるパケット送信(IRパケットの周期的な送信を含む)を示す図である。 図2の送信における第1のIRパケットが消失した場合を示す図である。 IRパケットのフォーマットを示す図である。 IR−DYNパケットのフォーマットを示す図である。 インターネットプロトコルバージョン4(IPv4)のROHCのIRパケットヘッダのスタティック部分およびダイナミック部分を示す図である。 UDP(User Datagram Protocol)のROHCのIRパケットヘッダのスタティック部分およびダイナミック部分を示す図である。 RTP(Real−time Transport Protocol)サブヘッダのスタティック部分およびダイナミック部分を示す図である。 本発明に基づく、後に受信したIRパケットのコンテンツを使用して前に受信したパケットを復元する方法の例示な実施形態のフローチャートである。
本発明の技術思想を除き、図面に示された要素は周知であり、詳細には説明しない。例えば、本発明の技術的思想を除き、パケットデータ通信(例えば、IP(インターネットプロトコル)、UDP(User Datagram Protocol)、RTP(Real−Time Transport Protocol)及びROHC(Robust Header Compression))並びに、例えば、ATSC−M/HもしくはDVB−H等の通信システムについては良く知られていると仮定し、これらを本明細書において説明することはしない。尚、本発明概念の態様は従来のプログラミング技術を用いて実装することができ、当該プログラミング技術そのものを本明細書において説明することはしない。また、異なる図面における同様の参照番号は同様の要素を示している。
本発明の発明者は、バーストモードが通信における特有の課題を与えることを見出した。特に、本発明者はROHCを例えばRTPの基本プロトコルとともに使用すると、特定の現象が得られることを見出した。知られているように、ROHCは所与の(基本の)プロトコルに対しては拡張ヘッダを使用するし、基本プロトコル(例えば、RTP)に基づいてフォーマット化されたデータも含む。上記したように、ROHCはIRパケットを使用して、所定の制御情報を送信する。バーストモードにおいて、本発明者は、もしIRパケットが消失したり、エラーを含んでいたり、あるいはレシーバ側で利用不能であるならば、レシーバは通常、当該消失IRパケットに依存するデータパケットを捨ててしまうことに気付いた。
例示的な実施形態において、後に受信されるIRパケットを使用して、消失したIRパケットの中の色々な情報片についての値を決定または推定することができる。例示的な実施形態において、データパケットを復号化するのに使用される情報だけが、決定または推定される。他の実施形態においては、IRパケット全体が決定または推定される。
図1はROHCを採用する典型的なシステムの概略図である。RFC3095はROHCを記述すると共に種々の基本プロトコル(RTPその他を含む)への適用を記述する。図1に示されているように、典型的なROHC方式は、ROHC適応のコンプレッサもしくはトランスミッタ110とROHC適応のデコンプレッサもしくはレシーバ120とを介して、クライアント102に接続されたデータパケットのソース101を含む。ソース101及びコンプレッサ110は通常、同じ位置に配置され、クライアント102及びデコンプレッサ120も同じ位置に配置されるが、そのような配置は必須ではない。コンプレッサ110及びデコンプレッサ120は任意の適切な有線リンク(単数または複数)もしくは無線リンク(単数または複数)によって繋がれる。
送信されているデータに応じて、ROHCは3つのうちの1つのモードで動作することができる。すなわち、Uモード(Unidirectional Mode:ユニディレクショナルモード)、Oモード(Optimistic mode:オプティミスティックモード)またはRモード(Reliable Mode:リライアブルモード)である。Uモードの場合、フィードバックチャネルは無いと考える。Oモード及びRモードはフィードバックメカニズムを有し、よって、コンプレッサ110はデコンプレッサ120からのフィードバックに基づいて使用される圧縮レベルを変えることができる。
ROHC動作は通常、IR(Initialization and Refresh)パケットの送信で開始する。IRパケットは圧縮されていないパケットであり、送信されるデータのプロファイルに関する完全なコンテキスト情報を含んでいる。Uモードの場合、パケットはコンプレッサ110からデコンプレッサ120へフィードバック無しで送信される。コンプレッサ110は、デコンプレッサ120がどの情報を受信しなかったのかを示すフィードバックを受け取らないので、ROHCのUモードはタイムアウトメカニズム(所定時間が経過すると圧縮モードを切り替えるメカニズム)を有し、コンプレッサ110が異なる(複数の)圧縮モードの間で切り替えられるようになっている。
Uモード動作の場合(これは例えばATSC−M/H送信において使用することができるものである)、完全なコンテキストを含むIRパケットを周期的に送信することができる。このような動作が図2に示されている。IRパケットはコンテキスト情報のスタティック部分及びダイナミック部分を非圧縮形式で含むか、またはスタティック部分のみを含む。関連するパケットタイプ(IR−DYNパケット)は、コンテキスト情報のダイナミック部分のみを含む。コンプレッサ110はこれら2つのタイプのIRパケットを一定間隔で交互に送信することができる。これは、Uモードにはフィードバックが無いので、特に有効である。IRパケット及びIR−DYNパケットのフォーマットは下記において詳述する。
図2に示されているように、IRパケットIR1はパケットA、B及びCを復元するためのコンテキスト情報を含み、IRパケットIR2はパケットP、Q及びRを復元するためのコンテキスト情報を含む。図2に示されている例示的な状況において、パケットIR1、A、B及びCは1つのタイムスライスとして一緒に送信され、パケットIR2、P、Q及びRは後のタイムスライスとして一緒に送信される。タイムスライス化処理は送信方法の1つであり、各送信が所定時間の間、データのバーストとして伝送されるものであり、ATSC−M/HまたはDVB−H等の一方向放送システムに広く採用されている。例示的な実施形態において、各タイムスライスは、1つのIRパケットと、当該IRパケットに含まれているコンテキスト情報が関連している複数のパケットとを含む。各タイムスライスはIRパケットでスタートする。タイムスライスは、本実施形態で説明されたパケット及びIRパケットとは異なる数のパケット及びIRパケットを有することもできる。
デコンプレッサ120がタイムスライスのデータの送信の間にONになると、デコンプレッサ120は当該タイムスライスの幾つかのパケットを受信するが、当該パケットより前のIRパケットは受信しない。よって、デコンプレッサ120はそれらのパケットを復元するのに必要な関連IRパケット無しで当該パケットを受信することになる。そのような場面が図3に示されている。図3において、パケットA、B及びCは受信されるが、IRパケットIR1は受信されない。パケットA、B及びCに関連するIRパケットがデコンプレッサ120によって受信されなかったので、IRパケットに含まれているパケットA、B及びC復元用コンテキスト情報をデコンプレッサ120が使用することはできない。しかしながら、1つもしくは複数の後続のIRパケットを後続のスライスにおいて、後に受信することは出来る。図3に示された状況では、パケットP、Q及びRの前のIRパケットIR2がデコンプレッサ120によって受信される。しかし上述したように、IRパケットは当該IRパケットの後に続くパケットのためのコンテキスト情報を含む。
本発明の例示的な実施形態によれば、ROHCデコンプレッサはIRパケットに含まれているコンテキスト情報を使用して、当該IRパケットの前のパケットを復元する。図3に示された場面では、デコンプレッサ120はIRパケットIR2に含まれているコンテキスト情報を使用してパケットA、B及びCを復元する(こうする以外に、これらパケットについてはコンテキスト情報が無い)。これは、連続するIRパケット(例えば、IR2及びIR1)が共通の情報を含むので、可能となる。さらに、前の消失IRパケットの情報の一部もしくは全部は、後続のIRパケットから再形成することができる。例えば、IRパケットIR2の中のRTPタイムスタンプ(TS:Timestamp)、タイムスタンプストライド(TS_Stirde)及びRTPシーケンスナンバ(SN:Sequence Number)を用いて、IRパケットIR1の中の対応する情報を再構成することができる。
図4AはRTPのIRパケットのフォーマットを示し、図4BはRTPのIR−DYNパケットのフォーマットを示している(図4A及び図4BはRFC3095から導出したものである)。IRパケットタイプはコンテキストのスタティック部分(つまり、一定SN関数の値)を送信する。また、必要であれば、コンテキストのダイナミック部分(つまり、一定でないSN関数のパラメータ)を送信することも可能である。さらに、必要であれば、元のパケットのペイロード(もし存在するならば)を送信することも可能である。IR−DYNパケットタイプはコンテキストのダイナミック部分(つまり、一定でないSN関数のパラメータ)を送信する。パケットの各フィールドには、各フィールドのオクテット数が括弧書きで示されている。
図4A及び図4Bに示されているように、各IRパケット及びIR−DYNパケットはコンテキスト識別子情報(Add−CID、CID)を含み、この情報により、異なるコンテキストを有する複数のパケットストリームが1つのチャネルを共有することができる。各パケットの第2のオクテットはパケットタイプ(IRまたはIR−DYN)を特定し、IRパケットの場合、bit Dであり、これはダイナミックチェーンフィールドが存在するかどうかを表す。
図4A及び図4Bに示されているように、各IRパケット及びIR−DYNパケットはヘッダ圧縮プロファイルオクテットを含む。このオクテットは、ある種類のパケットストリームのヘッダをある種類のリンクを介してどのように圧縮するのかを示す。圧縮プロファイルはROHCヘッダ圧縮フレームワークの詳細を示す。
図4A及び図4Bに示されているように、各IRパケットヘッダ及びIR−DYNパケットヘッダは、ヘッダの完全性をチェックするためのCRC(Cyclic Redundancy Check:巡回冗長検査)オクテットを含んでいる。
例示的な実施形態において、図4A及び図4BのIRヘッダ情報はAdd−CID、パケットヘッダ、プロファイル及びCRCのフィールドを含んでいるが、消失したIRパケットのために再形成されることはない。なぜならこれらはデータパケットを復号化する際に使用されないからである。
IRパケットヘッダにおいては、CRCオクテットの後にスタティックチェーンフィールドが存在しており、その後にダイナミックチェーンフィールドが存在することもある。IR−DYNパケットヘッダにおいては、CRCオクテットの後にダイナミックチェーンフィールドが存在する。IRパケットもしくはIR−DYNパケットのヘッダの後には、対応する元のパケットのペイロードが位置する(もし当該ペイロードがあれば)。
スタティックチェーンフィールドはスタティックサブヘッダ情報のチェーン(一連のスタティックサブヘッダ情報)を含み、ダイナミックチェーンフィールドはダイナミックサブヘッダ情報のチェーン(一連のダイナミックサブヘッダ情報)を含む。どのようなダイナミック情報が存在するかは、スタティックチェーンフィールドから推測する。圧縮可能なサブヘッダはスタティック部分とダイナミック部分に分けられる。
図5A〜図5Cはインターネットプロトコルバージョン4(IPv4)、UDP(User Datagram Protocol)及びRTP(Real−time Transport Protocol)サブヘッダ用のROHCのIRパケットヘッダのスタティック部分とダイナミック部分をそれぞれ示している。(図5A〜図5CはRFC3095から導取したものである。)しかし後述するように、UDPヘッダ及びIPヘッダの内容は通常、RTPヘッダのコンテンツよりも頻繁に変化しない。
図3に示されているようにパケットIR1が消失した場合、パケットA、B及びCに関連するスタティック情報及びダイナミック情報は消失する。しかしながら、後続のIRパケットIR2は受信され、当該パケットIR2は通常、消失したパケットIR1に含まれていたのと同じスタティック情報を含むと共に消失したパケットIR1に含まれていたダイナミック情報に幾らかの変更がなされたものを含む。よって、パケットIR2に含まれているスタティック情報及びダイナミック情報を再利用することにより、消失したパケットIR1に含まれていたスタティック情報及びダイナミック情報を再形成することができる。例示的な実施形態において、パケットIR2のスタティック情報はパケットIR1のスタティック情報として再利用され、パケットIR2のダイナミック情報及び/もしくはスタティック情報はパケットIR1のダイナミック情報を導出するために使用される。
IPパケットヘッダ及びUDPパケットヘッダについては、再利用することができるスタティック情報は、ソースアドレス、ソースポート、行先アドレス及び行先ポートを含む。放送に適用した場合(これは例示的な実施形態に包含される)、ソースネットワークアドレス、ソースネットワークポート、行先ネットワークアドレス及び行先ネットワークポートは通常、頻繁に変わらない。
同じことがIPv4ヘッダ(図5A)のダイナミック部分についても言える。IPv4ヘッダは幾つかのネットワークパラメータ、例えば、有効期間(Time to Live(TTL))及びサービスのタイプ(Type of Service(TOS))等を含む。この情報は頻繁に変わらず、対応するIRパケットがないパケットに対して再利用することができる。
例えば、図5Cに示したようなIRパケットのRTPヘッダの場合、再形成されるべき別の情報がある。図5Cに示されているように、RTPヘッダのスタティック部分はストリームのSSRC(Synchronization source identifier:同期ソース識別子)を含む。SSRCはストリームを識別し、1つのIRパケットと次のIRパケットとの間で変わらないと考えられる。よって、次に受信されるIRパケットからのSSRCは、消失したIRパケットからのSSRCと同じであると考えられる。このような情報は時間経過と共に大きく変わらないので、再利用することができる。
RTPヘッダ(図5C)のダイナミック部分においては、最初の2バイト(バージョン数V、RX、CC、M及びペイロードタイプPTを含む)は通常、1つのIRパケットと次のIRパケットとの間で変わらないと考えられる。よって、例示的な実施形態にあっては、前記次に受信されたIRパケットからのこれら2つのバイトは、消失したIRパケットからの対応する2つのバイトと同じであると考えられ、再利用することができる。
IRパケットIR2のシーケンス番号(SN)を使用して、前のパケットのシーケンス番号を導出することができる。RTPの一部として、シーケンス番号は1つのパケットから次のパケットへ増加する(パケット毎に増加する)。消失したIRパケットのシーケンス番号は受信したIRパケットのシーケンス番号から判断することができる。例えば、「x」個のRTPデータパケットが消失したIRパケットと受信したIRパケットとの間にある場合、消失したIRパケットのシーケンス番号は受信したIRパケットのシーケンス番号から「x」+1を引くことによって得られる。従って、一例として、もし図3に示されているパケットIR2が4というシーケンス番号を有しているなら、前のパケットA、B及びCのシーケンス番号はそれぞれ1、2及び3であるという演算をすることができる。
図5Cに示されているように、RTPヘッダのダイナミック部分はタイムスタンプ(TS:Timestamp)フィールド、TS_Strideフィールド及びTime_Strideフィールドも含む。TS_Stride及びTime_Strideは、連続するRTPタイムスタンプと連続する絶対タイムスタンプ(ウォールクロック)との間の変化を提供する。より詳しくは、TS_Strideはレシーバに、前のIRパケットからみた場合のRTPタイムスタンプの予想変化を提示する。従って、消失IRパケットのRTPタイムスタンプは、受信したIRパケットのTS_Stride及びRTPタイムスタンプから決定することができる。さらに、TS_Stride及びTime_Strideは通常、1つのIRパケットと次のIRパケットとの間で変わっていないと考えられる。例えば、「x」個のデータRTPパケットが消失IRパケットと受信IRパケットの間にある場合、当該消失IRパケットのTimestampは受信IRパケットのRTPのTimestampから(x+1)×TS_Strideを引くことによって得られる。よって、一例として、もしIRパケットIR2のTimestamp値が100でありTS_Stride値が10の場合、前のパケットA、B及びCのTimestamp値はそれぞれ70、80及び90であると推論される。
図5Cに示されているように、RTPヘッダのダイナミック部分はCRLリストフィールドも含んでいる。CRLリストは通常、1つのIRパケットと次のIRパケットの間で変わらないと考えられる。従って、消失IRパケットからのCRLリストは、次に受信したIRパケットからのCRLと同じであると考えられる。
よって、後のIRパケットを使用することにより、必要な情報のほとんど(例えば、RTPパケットのペイロードタイプ(PT)、RTPバージョン(V)及びTimestamp(TS))を再形成することができ、それをコンテキスト情報を持っていないパケットに利用することができる。これにより、よりロバスト性の高いサービスを提供することができる。また、これにより、レシーバにとってはチューニングをより速く行うことができるようになる。なぜなら、パケットに関連するIRパケットの受信ができなくても、当該パケットからの情報を復号化することができるからである。
例示的な実施形態においては、ROHCヘッダの特定のフィールドに関する信号送信要件があるために、リバースシーケンスでパケットA、B及びCを再構築する必要があり得る。例えば、RTPの場合、パケットCがまず再構築され、その後パケットB、そしてパケットAが再構築される。このようにするのは、SN(Sequence Number:シーケンス番号)情報及びTS(Timestamp:タイムスタンプ)情報をROHCヘッダで信号送信する方法に合わせるためである。増加するデータしか利用できないので、パケットはIRから逆方向(バックワード)に処理を行うことによって再構築される。
例示的な実施形態では、ROHCパケットヘッダのCRC情報は、上述したように再形成されたヘッダ情報の妥当性をチェックするために使用することができる。UモードROHCの場合、例えば、各パケットのROHCヘッダはCRCを含む。別のIRパケット(例えばパケットIR2)に含まれている情報から再形成された情報を使って復元されたパケットA、B及びCのようなパケットについては、デコンプレッサは、パケットを復元して、復元パケットを受信されたパケットヘッダに含まれているCRCと比較した後、各パケットについてCRCを計算することによって前記再形成された情報の妥当性をテストすることができる。一致すれば、前記再形成されたデータが有効と判断され、当該パケットをクライアントに転送することができる。一致しなければ、そのパケットは廃棄される。
RTP/UDP/IPパケットがROHCを用いて圧縮されている場合、レシーバはRTP/UDP/IPヘッダを復元し、CRCを適用して当該得られたヘッダを確認することができる。しかし、もしパケットが消失しているなら、再構成されたパケットに不確定な部分が含まれていることもある。従って、パケット消失の無い通常動作においては、パケットP0、P1、P2、P3、…がコンプレッサ110によってそれぞれROHCパケットR(P0)、R(P1)、R(P2)、R(P3)、…に圧縮され、デコンプレッサ120に送信され、デコンプレッサ120によって当該パケットがパケットP0、P1、P2、P3、…に復元される。しかし、例えば、R(P2)が消失している場合、P2を再構成することができず、R(P2)が異なる情報を含んでいたので、P3を不正確に再構成する可能性がある。
簡単な構成の実施形態においてレシーバは、次のIRパケットが受信されるまで、単にパケットR(P3)、R(P4)、…を無視する。より複雑な実施形態においてレシーバはP3を再構成して、そのCRCを行う。もしCRCをパスすれば、レシーバは後続のパケットP4、P5、…を復号化し続け、そうでなければ、復号化を停止して次のIRパケットを待つ。さらに別の実施形態においてレシーバは、もしCRCをパスできなければ、パケットP3のコンテンツは変更され(例えば、消失パケットに基づいて推定される量だけSN及びTSを増加することによって)、CRCは変更されたコンテンツに基づいて再計算され、CRCが再び試みられる。パケットコンテンツを変更してCRCを再度行うという上記処理は、CRCをパスするまで繰り返されるか、または何らかの事象が起きるまで(例えば、所定時間が経過するまで)繰り返される。
上記したようにパケットが逆の順序で再構築される場合、たとえ消失パケットがなくても、当該パケットが曖昧部分無しに生成できるかは保証されない。従って、好ましくは、CRCによるチェックを実施する。さらに、上述のパケットコンテンツの変更及びCRCの再チェックという処理を繰り返して行う場合もある。
図6は上記した記載に基づく方法の例示的な実施形態のフローチャートを示している。図6に示されているように、ステップ202において複数のパケットを含む1つのタイムスライス(例えば図2及び図3に示されているようなもの)がデコンプレッサによって受信される。デコンプレッサはタイムスライスを検査して、もしステップ204において当該タイムスライスにIRパケットが無いことが判明したならば(図3の場合)、動作はステップ206へ進む。ステップ206において、現在のタイムスライスで受信されている圧縮パケットが、後に実行される復元のために保存される。この保存は、後続のタイムスライスが、パケットを復元するために使用できるコンテキスト情報を含むIRパケットと共に受信されているという予想のもとに行われる。その後、ステップ202に戻り、別のタイムスライスの受信を待つ。
ステップ204において現在のタイムスライスがIRパケットと共に受信されたと判断されると(図2に示された場合のように)、動作はステップ207へ進み、デコンプレッサは、復元を待っているステップ206で保存された以前のタイムスライスからの圧縮パケットがないかをチェックする。もしなければ、動作はステップ212に進み、現在のタイムスライスにおいて受信されたパケットヘッダが、現在のタイムスライスにおいて受信されたIRパケットに存在するコンテキスト情報に基づいて復元される。
ステップ207において、復元を待っている古いタイムスライスからの圧縮パケットが保存されていると判断されたならば、動作はステップ208へ進み、現在のIRパケットの情報が抽出される。抽出された情報はステップ210において、関連IRパケットを持っていない保存パケットのためのスタティック情報及びダイナミック情報を再形成するために使用される。上記したように、コンテキスト情報を再形成するステップは、抽出したスタティック情報及び/もしくはダイナミック情報の一部もしくは全てを再利用し、且つ/または抽出したスタティック情報及び/もしくはダイナミック情報の一部もしくは全てからコンテキスト情報を導出することを含む場合がある。その後、動作はステップ212に進み、記憶されたパケットは上記した再形成されたコンテキスト情報に基づいて復元される。さらに、現在のタイムスライスにおいて受信されたパケットも、上記抽出された情報に基づいて復元される。その後、動作はステップ202に戻り、別のタイムスライスの受信を待つ。
上記において、パケットがバースト形式またはタイムスライス形式で送信されるバーストモードの動作の例示的実施形態を説明してきたが、本発明の原理はパケットが連続するストリームで送信されるストリーミングモードの動作にも適用可能である。
他の例示的な実施形態において、ROHCデコンプレッサは前に受信したコンテキストリッチなパケットを使用して、後に受信するパケット(このパケットについては、コンテキスト情報が受信されない)を復元する。例示的なROHCデコンプレッサは、コンテキスト情報を欠いているパケットを捨てる代わりに、前に受信したコンテキストリッチなパケット(例えばIRパケット)を使用して、後に受信したパケットに関するコンテキスト情報を再形成する。このように再形成されたコンテキスト情報は、受信したパケットを復元するために使用される。例示的な実施形態において、データパケットを復号化する際に使用される情報だけが、決定されまたは推定される。他の実施形態においては、IRパケット全体が決定されまたは推定される。
さらに別の例示的な実施形態においては、ROHCデコンプレッサは前に受信したコンテキストリッチなパケットと後に受信したコンテキストリッチなパケットとを使用して、コンテキスト情報を受信していないパケットを復元する。例示的なROHCデコンプレッサは、コンテキスト情報を欠いているパケットを捨てる代わりに、IRパケット等のコンテキストリッチな複数のパケット(コンテキスト情報を受信していないパケットの前のパケットと後のパケット)の組み合わせを使用して、当該パケットに関連するコンテキスト情報を再形成する。例えば、RTPを適用している場合、消失IRパケットのSN及びTS等の情報は、前に受信したIRパケット(正しく受信されたIRパケット)及び後に受信したIRパケット(正しく受信されたIRパケット)の対応する値を補間することにより決定することができる。このように再形成されたコンテキスト情報が当該パケットを復元するために使用される。例示的な実施形態において、データパケットを復号化する際に使用される情報だけが決定されまたは推定される。別の実施形態においては、IRパケット全体が決定されまたは推定される。
直近のIRパケット(例えば消失IRパケットのすぐ前のIRパケットまたはすぐ後のIRパケット)が当該消失IRパケットのコンテンツを再形成するための最も正確な情報を含んでいる可能性が最も高いと思われるが、離れたIRパケットからの情報を使用してもよい場合もある(特に、近くのIRパケットの情報の妥当性に疑問がある場合)。
本発明に基づく種々の例示的な実施形態が可能である。例えば、例示的な実施形態において、ROHCシステム内において消失IRパケットの全てもしくは一部を、異なるIRパケットを使用して再形成する方法が提供される。他の例示的な実施形態において、消失IRパケットに基づくデータを処理する(例えば復号化する)方法が提供される。この処理は、再形成されたIRパケットを使用して行われる。他の例示的な実施形態においては、前記再形成を実行する処理装置及び/もしくは前記処理方法を実行する処理装置が提供される。他の例示的な実施形態においては、プリプロセッサ、エンコーダ、トランスミッタ、レシーバ、デコーダ、ポストプロセッサ、セットトップボックス、携帯電話、ラップトップコンピュータその他のパーソナルコンピュータ、PDAその他の家庭用(個人用)通信機器(上記した処理装置を含む)等の装置やデバイスが提供される。
本発明による実施形態は色々な用途に適用できる。例えば、実施形態は、ビデオデータの符号化及び/もしくは他のタイプのデータの符号化に利用することができる。さらに、実施形態は規格として利用できるし、または、規格に用いられるものとして利用できる。そのような規格の1つはATSC−M/H規格であるが、他の規格(既存の規格または将来作られる規格)にも適用できる。もちろん、実施形態は規格に利用される必要はない。
本明細書に記載された実施形態は例えば、方法、プロセス、装置、ソフトウエアプログラム、データストリームまたは信号において実装することができる。たとえ1つの実施形態でのみ説明されたとしても(例えば方法として説明されたとしても)、上記した特徴の実施は他の形態(例えば装置またはプログラム)においても実施することができる。装置は、適切なハードウエア、ソフトウエア及びファームウエアにおいて実施することができる。方法は例えば装置(例えば、コンピュータ、マイクロコンピュータ、集積回路またはプログラム可能論理デバイスを含めて一般的に処理装置と称されるプロセッサ)において実施することができる。プロセッサは、通信装置(例えば、コンピュータ、携帯電話、携帯用情報端末(portable digital assistant)/個人用情報端末(personal digital assistant)(PDA)及びエンドユーザ間の情報通信のための他の装置)を含む。
本明細書に記載された種々のプロセス及び特徴は種々の異なる機器またはアプリケーション(たとえばデータ符号化及びデータ復号化に関連づけられた機器またはアプリケーション)において具体的に実施することができる。そのような機器の例は、エンコーダ、デコーダ、デコーダからの出力を処理するポストプロセッサ、エンコーダへの入力を提供するプリプロセッサ、ビデオコーダ、ビデオデコーダ、ビデオコーデック、ウエブサーバ、セットトップボックス、ラップトップコンピュータ、パーソナルコンピュータ、携帯電話、PDA及びその他の通信装置である。明確にする必要があるならば、上記機器は移動できるものでもよく、さらに移動車両に設けられるものでもよい。
さらに、本発明の方法はコンピュータによって実行される命令として実装されてもよく、そのような命令(及び/または実行によって生成されるデータ値)は、例えば、集積回路、ソフトウエアキャリア、または、ハードディスク、コンパクトディスク、ランダムアクセスメモリ(RAM)もしくはリードオンリーメモリ(ROM)といった他の記憶装置等の、コンピュータ読取可能媒体に記憶されることもある。前記命令はコンピュータ読取可能媒体に実装されたアプリケーションプログラムとして実装されてもよい。命令は例えば、ハードウエア、ファームウエア、ソフトウエア、もしくはこれらの組み合わせにおいて実装される。命令は例えば、オペレーティングシステム、別個のアプリケーションもしくはこれらの組み合わせの中に見つけられるものであってもよい。従って、プロセッサは、例えば、方法を実施する装置と、方法を実施するための命令を保持するコンピュータ読取可能媒体(例えば記憶装置)を含む装置として特徴付けられる。さらに、コンピュータ読取可能媒体は命令に加えまたは命令の代わりに、実行によって生成されたデータ値を記憶することもできる。
上記において複数の実施形態が説明された。しかしながら、種々の変形が可能である。例えば、異なる実施形態の要素を組み合わせたり、追加したり、変形したり、除去したりすることによって、別の実施形態を作ることもできる。また、当業者であれば、異なる構造及び異なる手順を上記した内容の代わりに採用できることが理解できるであろうし、その結果として得られる実施形態が少なくとも上記実施形態と実質上同じ機能(単数または複数)を実質上同じ方法(単数または複数)で発揮して実質上同じ結果(単数または複数)を得ることができることも理解できるであろう。よって、上記した実施形態及び上記されなかった実施形態は本開示に包含され、本開示の範囲に含まれる。
上記の記載に鑑みれば、これまでの説明は単に本発明の原理を例示したにすぎず、当業者であれば多くの代替実施形態を考えることができるであろう。そのような代替実施形態は本明細書に明記されていないが、本発明の原理を具現化するものであって、本発明の範囲内のものである。例えば、別個の機能的要素として説明されていないが、当該機能的要素は1つもしくは複数の集積回路(IC)に実装することができる。同様に、別個の要素として図示されているが、当該要素の幾つかもしくは全ては、記憶されたプログラムにより制御されるプロセッサ(例えばデジタル信号プロセッサまたは汎用プロセッサ)に実装されてもよい。当該プロセッサは例えば1つもしくは複数のステップに対応する関連ソフトウエアを実行するプロセッサであり、当該ソフトウエアは種々の適切な記憶媒体のいずれかに実装されたものでよい。さらに、本発明の原理は種々のタイプのワイヤレス通信システム、例えば、地上放送、衛星放送、Wi−Fi通信、携帯通信その他に適用することができる。つまり、本発明の技術思想は固定式のトランスミッタ及びレシーバ、または移動式のトランスミッタ及びレシーバにも適用可能である。従って、多くの変形を上記実施形態になすことができ、その他の構成も本発明の精神及び範囲から離れることなく実施することができる。
本発明は以下の態様を含む。
(付記1)
レシーバにおいてデータパケットを復元する方法であって、
第1の圧縮データパケットを受信するステップ(202)と、
前記第1の圧縮データパケットの後に、コンテキスト情報を含む初期化パケットを受信するステップ(204)と、
前記初期化パケットに含まれている前記コンテキスト情報から前記第1の圧縮データパケットを復元するためのコンテキスト情報を再形成するステップ(210)と、
前記再形成されたコンテキスト情報を使用して前記第1の圧縮データパケットを復元するステップ(212)と、
を含む、前記方法。
(付記2)
前記初期化パケットの後に、第2の圧縮データパケットを受信するステップ(202)と、
前記初期化パケットに含まれている前記コンテキスト情報を使用して、前記第2の圧縮データパケットを復元するステップ(212)と、
をさらに含む、付記1記載の方法。
(付記3)
前記第1の圧縮データパケットはロバストヘッダ圧縮(ROHC)パケットである、付記1記載の方法。
(付記4)
前記初期化パケットはイニシャライゼーションアンドリフレッシュ(IR)パケットである、付記3記載の方法。
(付記5)
前記第1の圧縮データパケットはリアルタイムトランスポートプロトコル(RTP)パケットである、付記1記載の方法。
(付記6)
前記再形成されたコンテキスト情報は、タイムスタンプ、タイムスタンプストライド及びシーケンス番号の少なくとも1つを含む、付記5記載の方法。
(付記7)
前記第1の圧縮データパケットは第1のデータバーストで受信され、前記初期化パケットは第2のデータバーストで受信される、付記1記載の方法。
(付記8)
前記コンテキスト情報を再形成するステップは、前記初期化パケットに含まれているコンテキスト情報を再利用すること、および前記初期化パケットに含まれている前記コンテキスト情報からコンテキスト情報を導出すること、の少なくとも一方を含む、付記1記載の方法。
(付記9)
前記復元された第1の圧縮データパケットのための巡回冗長コード(CRC)を決定するステップと、
前記決定された巡回冗長コードを、前記第1の圧縮データパケットに含まれている巡回冗長コードと比較するステップと、
を含む、付記1記載の方法。
(付記10)
前記第1の圧縮データパケットの前に、それ以前の初期化パケットを受信するステップを含み、当該それ以前の初期化パケットはコンテキスト情報を含み、前記第1の圧縮データパケットを復元するための前記コンテキスト情報は、前記初期化パケットに含まれているコンテキスト情報と前記それ以前の初期化パケットに含まれているコンテキスト情報とから再形成される、付記1記載の方法。
(付記11)
コンピュータプログラムを記憶したコンピュータ読取可能媒体であって、前記コンピュータプログラムは、コンピュータに、
第1の圧縮データパケットを受信するステップ(202)と、
前記第1の圧縮データパケットの後に、コンテキスト情報を含む初期化パケットを受信するステップ(204)と、
前記初期化パケットに含まれている前記コンテキスト情報から前記第1の圧縮データパケットを復元するためのコンテキスト情報を再形成するステップ(210)と、
前記再形成されたコンテキスト情報を使用して前記第1の圧縮データパケットを復元するステップ(212)と、
を実行することによりデータパケットを復元させる、前記コンピュータ読取可能媒体。
(付記12)
前記コンピュータが、
前記初期化パケットの後に、第2の圧縮データパケットを受信するステップ(202)と、
前記初期化パケットに含まれている前記コンテキスト情報を使用して、前記第2の圧縮データパケットを復元するステップ(212)と、
を実行する、付記11記載のコンピュータ読取可能媒体。
(付記13)
前記第1の圧縮データパケットはロバストヘッダ圧縮(ROHC)パケットである、付記11記載のコンピュータ読取可能媒体。
(付記14)
前記初期化パケットはイニシャライゼーションアンドリフレッシュ(IR)パケットである、付記13記載のコンピュータ読取可能媒体。
(付記15)
前記第1の圧縮データパケットはリアルタイムトランスポートプロトコル(RTP)パケットである、付記11記載のコンピュータ読取可能媒体。
(付記16)
前記再形成されたコンテキスト情報は、タイムスタンプ、タイムスタンプストライド及びシーケンス番号の少なくとも1つを含む、付記15記載のコンピュータ読取可能媒体。
(付記17)
前記第1の圧縮データパケットは第1のデータバーストで受信され、前記初期化パケットは第2のデータバーストで受信される、付記11記載のコンピュータ読取可能媒体。
(付記18)
前記コンテキスト情報を再形成するステップは、前記初期化パケットに含まれているコンテキスト情報を再利用すること、および前記初期化パケットに含まれている前記コンテキスト情報からコンテキスト情報を導出すること、の少なくとも一方を含む、付記11記載のコンピュータ読取可能媒体。
(付記19)
前記コンピュータが、
前記復元された第1の圧縮データパケットのための巡回冗長コード(CRC)を決定するステップと、
前記決定された巡回冗長コードを、前記第1の圧縮データパケットに含まれている巡回冗長コードと比較するステップと、
を実行する、付記11記載のコンピュータ読取可能媒体。
(付記20)
前記コンピュータは前記第1の圧縮データパケットの前に、それ以前の初期化パケットを受信するステップを実行し、当該それ以前の初期化パケットはコンテキスト情報を含み、前記第1の圧縮データパケットを復元するための前記コンテキスト情報は、前記初期化パケットに含まれているコンテキスト情報と前記それ以前の初期化パケットに含まれているコンテキスト情報とから再形成される、付記11記載のコンピュータ読取可能媒体。
(付記21)
圧縮データパケットを復元する装置であって、
第1の圧縮データパケット(A、B、C)を受信し、当該第1の圧縮データパケットの後に、コンテキスト情報を含む初期化パケット(IR2)を受信する手段(120)と、
前記初期化パケットに含まれている前記コンテキスト情報から前記第1の圧縮データパケットを復元するためのコンテキスト情報を再形成する手段と、
前記再形成されたコンテキスト情報を使用して前記第1の圧縮データパケットを復元する手段と、
を含む、前記装置。
(付記22)
前記受信する手段(120)は、前記初期化パケット(IR2)の後に、第2の圧縮データパケット(P、Q、R)を受信し、
前記復元する手段は、前記初期化パケットに含まれている前記コンテキスト情報を使用して、前記第2の圧縮データパケットを復元する、付記21記載の装置。
(付記23)
前記第1の圧縮データパケットはロバストヘッダ圧縮(ROHC)パケットである、付記21記載の装置。
(付記24)
前記初期化パケットはイニシャライゼーションアンドリフレッシュ(IR)パケットである、付記23記載の装置。
(付記25)
前記第1の圧縮データパケットはリアルタイムトランスポートプロトコル(RTP)パケットである、付記21記載の装置。
(付記26)
前記再形成されたコンテキスト情報は、タイムスタンプ、タイムスタンプストライド及びシーケンス番号の少なくとも1つを含む、付記25記載の装置。
(付記27)
前記第1の圧縮データパケットは第1のデータバーストで受信され、前記初期化パケットは第2のデータバーストで受信される、付記21記載の装置。
(付記28)
前記コンテキスト情報を再形成することは、前記初期化パケットに含まれているコンテキスト情報を再利用すること、および前記初期化パケットに含まれている前記コンテキスト情報からコンテキスト情報を導出すること、の少なくとも一方を含む、付記21記載の装置。
(付記29)
前記復元された第1の圧縮データパケットのための巡回冗長コード(CRC)を決定する手段と、
前記決定された巡回冗長コードを、前記第1の圧縮データパケットに含まれている巡回冗長コードと比較する手段と、
を含む、付記21記載の装置。
(付記30)
前記受信する手段は、前記第1の圧縮データパケットの前に、それ以前の初期化パケットを受信し、当該それ以前の初期化パケットはコンテキスト情報を含み、前記第1の圧縮データパケットを復元するための前記コンテキスト情報は、前記初期化パケットに含まれているコンテキスト情報と前記それ以前の初期化パケットに含まれているコンテキスト情報とから再形成される、付記21記載の装置。
101 ソース
110 コンプレッサ
120 デコンプレッサ
102 クライアント

Claims (17)

  1. レシーバにおいてデータパケットをバックワードルッキングな方法を用いて復元する方法であって、各圧縮データパケットは同一のタイムスライスにおける前の初期化パケットに関連し、
    第1のタイムスライスにおいて送信された、前記前の初期化パケットが欠落した第1の圧縮データパケットを受信するステップと、
    前記第1の圧縮データパケットの後に、初期化パケットを受信するステップであって、前記第1のタイムスライスに続く第2のタイムスライスにおいて送信された前記初期化パケットはコンテキスト情報を含み、前記初期化パケットは、前記第1の圧縮データパケットより遅く受信された第2の圧縮データパケットに関連する、前記ステップと、
    前記第1の圧縮データパケットを復元するためのコンテキスト情報を、前記初期化パケットに含まれている前記コンテキスト情報から再形成するステップと、
    前記再形成されたコンテキスト情報を使用して前記第1の圧縮データパケットを復元するステップと、
    を含む、前記方法。
  2. 前記初期化パケットの後に、前記第2の圧縮データパケットを受信するステップと、
    前記初期化パケットに含まれている前記コンテキスト情報を使用して、前記第2の圧縮データパケットを復元するステップと、
    をさらに含む、請求項1記載の方法。
  3. 前記第1の圧縮データパケットはロバストヘッダ圧縮(ROHC)パケットであり、前記初期化パケットはイニシャライゼーションアンドリフレッシュ(IR)パケットである、請求項1記載の方法。
  4. 前記第1の圧縮データパケットはリアルタイムトランスポートプロトコル(RTP)パケットであり、前記再形成されたコンテキスト情報は、タイムスタンプ、タイムスタンプストライド及びシーケンス番号の少なくとも1つを含む、請求項1記載の方法。
  5. 前記第1の圧縮データパケットは第1のデータバーストで受信され、および前記初期化パケットは第2のデータバーストで受信される、請求項1記載の方法。
  6. 前記コンテキスト情報を再形成するステップは、前記初期化パケットに含まれているコンテキスト情報を再利用すること、およびコンテキスト情報を前記初期化パケットに含まれている前記コンテキスト情報から導出すること、の少なくとも一方を含む、請求項1記載の方法。
  7. 前記復元された第1の圧縮データパケットのための巡回冗長コード(CRC)を決定するステップと、
    前記決定された巡回冗長コードを、前記第1の圧縮データパケットに含まれている巡回冗長コードと比較するステップと、
    を含む、請求項1記載の方法。
  8. 前記第1の圧縮データパケットの前に、それ以前の初期化パケットを受信するステップを含み、当該それ以前の初期化パケットはコンテキスト情報を含み、前記第1の圧縮データパケットを復元するための前記コンテキスト情報は、前記初期化パケットに含まれている前記コンテキスト情報と前記それ以前の初期化パケットに含まれている前記コンテキスト情報とから再形成される、請求項1記載の方法。
  9. コンピュータプログラムを記憶したコンピュータ読取可能媒体であって、前記コンピュータプログラムは、コンピュータに、請求項1ないし8記載の方法のうちの1つを実行することによりデータパケットを復元させる、前記コンピュータ読取可能媒体。
  10. 圧縮データパケットをバックワードルッキングな方法を用いて復元する装置であって、各圧縮データパケットは同一のタイムスライスにおける前の初期化パケットに関連し、
    第1のタイムスライスにおいて送信された、前記前の初期化パケットが欠落した第1の圧縮データパケットを受信し、当該第1の圧縮データパケットの後に、初期化パケットを受信する手段であって、前記第1のタイムスライスに続く第2のタイムスライスにおいて送信された前記初期化パケットはコンテキスト情報を含み、前記初期化パケットは、前記第1の圧縮データパケットより遅く受信された第2の圧縮データパケットに関連する、前記手段と、
    前記第1の圧縮データパケットを復元するためのコンテキスト情報を、前記初期化パケットに含まれている前記コンテキスト情報から再形成する手段と、
    前記再形成されたコンテキスト情報を使用して前記第1の圧縮データパケットを復元する手段と、
    を含む、前記装置。
  11. 前記受信する手段は、前記初期化パケットの後に、前記第2の圧縮データパケットを受信し、
    前記復元する手段は、前記初期化パケットに含まれている前記コンテキスト情報を使用して、前記第2の圧縮データパケットを復元する、請求項10記載の装置。
  12. 前記第1の圧縮データパケットはロバストヘッダ圧縮(ROHC)パケットであり、前記初期化パケットはイニシャライゼーションアンドリフレッシュ(IR)パケットである、請求項10記載の装置。
  13. 前記第1の圧縮データパケットはリアルタイムトランスポートプロトコル(RTP)パケットであり、前記再形成されたコンテキスト情報は、タイムスタンプ、タイムスタンプストライド及びシーケンス番号の少なくとも1つを含む、請求項10記載の装置。
  14. 前記第1の圧縮データパケットは第1のデータバーストで受信され、および前記初期化パケットは第2のデータバーストで受信される、請求項10記載の装置。
  15. 前記コンテキスト情報を再形成することは、前記初期化パケットに含まれているコンテキスト情報を再利用すること、および前記初期化パケットに含まれている前記コンテキスト情報からコンテキスト情報を導出すること、の少なくとも一方を含む、請求項10記載の装置。
  16. 前記復元された第1の圧縮データパケットのための巡回冗長コード(CRC)を決定する手段と、
    前記決定された巡回冗長コードを、前記第1の圧縮データパケットに含まれている巡回冗長コードと比較する手段と、
    を含む、請求項10記載の装置。
  17. 前記受信する手段は、前記第1の圧縮データパケットの前に、それ以前の初期化パケットを受信し、当該それ以前の初期化パケットはコンテキスト情報を含み、前記第1の圧縮データパケットを復元するための前記コンテキスト情報は、前記初期化パケットに含まれている前記コンテキスト情報と前記それ以前の初期化パケットに含まれている前記コンテキスト情報とから再形成される、請求項10記載の装置。
JP2012519532A 2009-07-08 2010-06-18 バックワードルッキングロバストヘッダ圧縮レシーバ Active JP5778672B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US27046609P 2009-07-08 2009-07-08
US61/270,466 2009-07-08
PCT/US2010/001773 WO2011005288A1 (en) 2009-07-08 2010-06-18 Backward looking robust header compression receiver

Publications (3)

Publication Number Publication Date
JP2012533213A JP2012533213A (ja) 2012-12-20
JP2012533213A5 JP2012533213A5 (ja) 2013-08-01
JP5778672B2 true JP5778672B2 (ja) 2015-09-16

Family

ID=42830792

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2012519532A Active JP5778672B2 (ja) 2009-07-08 2010-06-18 バックワードルッキングロバストヘッダ圧縮レシーバ

Country Status (6)

Country Link
US (2) US9055034B2 (ja)
EP (1) EP2452480B1 (ja)
JP (1) JP5778672B2 (ja)
KR (1) KR101722719B1 (ja)
CN (1) CN102484643B (ja)
WO (1) WO2011005288A1 (ja)

Families Citing this family (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110016313A1 (en) * 2009-07-15 2011-01-20 Qualcomm Incorporated HEADER COMPRESSION FOR TUNNELED IPsec PACKET
CN102036307B (zh) * 2010-12-17 2016-04-13 中兴通讯股份有限公司 鲁棒性头压缩中提高上下文更新报文健壮性的方法和装置
CN103051434A (zh) * 2012-12-20 2013-04-17 中兴通讯股份有限公司 数据的解压缩、解压缩处理方法及装置
EP3090518B1 (en) * 2014-01-03 2020-02-12 LG Electronics Inc. Method and apparatus for transmitting/receiving broadcast signal including robust header compression packet stream
KR101861695B1 (ko) 2014-01-14 2018-05-28 엘지전자 주식회사 RoHC 패킷 스트림 및 고속 정보를 포함하는 방송 신호의 송수신 방법 및 장치
JP2015170912A (ja) 2014-03-05 2015-09-28 ソニー株式会社 データ処理装置、及び、データ処理方法
CN104394117A (zh) * 2014-03-10 2015-03-04 贵阳朗玛信息技术股份有限公司 Rtp包的传输方法及装置
US10135886B2 (en) * 2014-03-10 2018-11-20 Samsung Electronics Co., Ltd. Method and device for retaining robust header compression (ROHC) compressor state
KR102273873B1 (ko) * 2014-09-24 2021-07-06 삼성전자 주식회사 Lte 시스템을 이용한 호 수행 방법 및 장치
CN105765943B (zh) 2014-10-20 2019-08-23 Lg 电子株式会社 发送广播信号的装置、接收广播信号的装置、发送广播信号的方法和接收广播信号的方法
KR101764635B1 (ko) * 2014-12-10 2017-08-03 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2016144031A1 (ko) 2015-03-11 2016-09-15 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2017007281A1 (ko) * 2015-07-08 2017-01-12 엘지전자(주) 방송 신호 송수신 장치 및 방법
US10638286B2 (en) 2015-08-13 2020-04-28 Spreadtrum Hong Kong Limited Apparatus and method for scheduling order of downlink control information in a wireless network
US10194348B2 (en) * 2016-05-27 2019-01-29 Qualcomm Incorporated Techniques and apparatuses for improved robust header compression (ROHC) decompression
US10623989B2 (en) 2016-10-27 2020-04-14 Qualcomm Incorporated Techniques and apparatuses for unidirectional robust header compression
GB2575246A (en) * 2018-06-25 2020-01-08 British Telecomm Processing local area network diagnostic data
US11196649B2 (en) 2018-06-25 2021-12-07 British Telecommunications Public Limited Company Processing local area network diagnostic data
CN112335203B (zh) 2018-06-25 2023-12-05 英国电讯有限公司 处理局域网诊断数据
CN111092844B (zh) * 2018-10-23 2023-12-01 瑞昱半导体股份有限公司 进行压缩操作的模式转换的方法、及传输装置
CN111866969B (zh) * 2019-04-30 2021-10-26 华为技术有限公司 一种数据处理方法、通信装置和系统
TWI734195B (zh) * 2019-09-17 2021-07-21 圓展科技股份有限公司 具有控制回饋功能的影像傳輸裝置及控制回饋方法
EP4038840B1 (en) 2019-09-30 2024-10-09 British Telecommunications public limited company Processing local area network diagnostic data
WO2023195986A1 (en) * 2022-04-07 2023-10-12 Zeku, Inc. Hybrid rohc-rtp stack for small packet applications

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6850740B1 (en) * 1999-05-17 2005-02-01 Telefonaktiebolaget Lm Ericsson Time and frequency diversity in FH/TDD systems
JP3730835B2 (ja) 2000-03-03 2006-01-05 株式会社エヌ・ティ・ティ・ドコモ パケット伝送方法、中継装置およびデータ端末
DE60110303T2 (de) * 2000-03-03 2006-03-09 Ntt Docomo, Inc. Verfahren und Vorrichtung zur Paketübertragung mit Paketenkopfkompression
JP2001320422A (ja) * 2000-03-03 2001-11-16 Ntt Docomo Inc ヘッダ圧縮を伴うパケット伝送のための方法および装置
US7675895B2 (en) * 2004-09-14 2010-03-09 Alcatel-Lucent Usa Inc. Method and apparatus for wireless communication using voice over internet protocol
US7924731B2 (en) 2004-11-15 2011-04-12 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for handling out-of-sequence packets in header decompression
US7907609B2 (en) 2006-01-06 2011-03-15 Qualcomm, Incorporated Method and apparatus for enhancing RoHC performance when encountering silence suppression
US7948989B2 (en) 2006-05-04 2011-05-24 Qualcomm, Incorporated Methods and systems for enhancing local repair in robust header compression
KR20080012441A (ko) 2006-08-03 2008-02-12 삼성전자주식회사 패킷 데이터 통신망에서 헤더 정보 압축 장치 및 방법
US8175075B2 (en) 2006-12-26 2012-05-08 Alcatel Lucent Adaptive header compression in a wireless communication network
US8819110B2 (en) * 2007-04-16 2014-08-26 Blackberry Limited System and method for real-time data transmission using adaptive time compression

Also Published As

Publication number Publication date
KR101722719B1 (ko) 2017-04-11
US20120113993A1 (en) 2012-05-10
WO2011005288A1 (en) 2011-01-13
US9055034B2 (en) 2015-06-09
EP2452480B1 (en) 2018-03-21
JP2012533213A (ja) 2012-12-20
EP2452480A1 (en) 2012-05-16
CN102484643A (zh) 2012-05-30
CN102484643B (zh) 2015-11-25
US20150237179A1 (en) 2015-08-20
US9154588B2 (en) 2015-10-06
KR20120042833A (ko) 2012-05-03

Similar Documents

Publication Publication Date Title
JP5778672B2 (ja) バックワードルッキングロバストヘッダ圧縮レシーバ
US7907609B2 (en) Method and apparatus for enhancing RoHC performance when encountering silence suppression
US8351363B2 (en) Method and apparatus for enhanced file distribution in multicast or broadcast
JP5084842B2 (ja) 無線通信ネットワークにおける改良されたヘッダ圧縮
KR101449710B1 (ko) 데이터 통신시스템, 데이터 송신장치, 데이터 송신방법 및패킷 사이즈 및 용장도 결정방법
US9392082B2 (en) Communication interface and method for robust header compression of data flows
EP1882343A2 (en) Improving error resilience using out of band directory information
JP2005515651A (ja) 既知のパターンで変化するフィールドの削除を含むペイロードヘッダ抑制
CN113364508B (zh) 一种语音数据的传输控制方法、系统及设备
KR101953580B1 (ko) 영상회의 시스템에서 데이터 송수신 장치 및 방법
CN108737349B (zh) 一种语音数据包的处理方法及装置
CN108574684B (zh) 一种解压缩的方法和装置
US20150063103A1 (en) Bandwidth-dependent compressor for robust header compression and method of use thereof
KR101999105B1 (ko) 실시간 비디오 스트리밍에서 비디오 지연시간을 최소로 하면서 안정적으로 비디오 데이터를 송수신하는 방법
Rawat et al. Robust header compression over long delay links
Madsen et al. IP header compression for media streaming in wireless networks
Dawood et al. Error resilient packet-switched video telephony with adaptive rateless coding and reference picture selection.

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20130617

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20130617

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20140225

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20140526

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20140602

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20140825

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20141202

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20150402

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20150518

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20150609

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20150709

R150 Certificate of patent or registration of utility model

Ref document number: 5778672

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313113

S531 Written request for registration of change of domicile

Free format text: JAPANESE INTERMEDIATE CODE: R313531

R360 Written notification for declining of transfer of rights

Free format text: JAPANESE INTERMEDIATE CODE: R360

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R360 Written notification for declining of transfer of rights

Free format text: JAPANESE INTERMEDIATE CODE: R360

R371 Transfer withdrawn

Free format text: JAPANESE INTERMEDIATE CODE: R371

S531 Written request for registration of change of domicile

Free format text: JAPANESE INTERMEDIATE CODE: R313531

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313113

R360 Written notification for declining of transfer of rights

Free format text: JAPANESE INTERMEDIATE CODE: R360

R360 Written notification for declining of transfer of rights

Free format text: JAPANESE INTERMEDIATE CODE: R360

R371 Transfer withdrawn

Free format text: JAPANESE INTERMEDIATE CODE: R371

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313113

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250