特許 6523249 パケットヘッダを圧縮する方法及び装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6523249

(24)【登録日】2019年5月10日

(45)【発行日】2019年5月29日

(54)【発明の名称】パケットヘッダを圧縮する方法及び装置

(51)【国際特許分類】

   H04L 29/06 20060101AFI20190520BHJP

   H03M 7/30 20060101ALI20190520BHJP

【ＦＩ】

   H04L13/00 305C

   H03M7/30 Z

【請求項の数】16

【全頁数】20

(21)【出願番号】特願2016-508247(P2016-508247)

(86)(22)【出願日】2013年11月22日

(65)【公表番号】特表2016-519527(P2016-519527A)

(43)【公表日】2016年6月30日

(86)【国際出願番号】IB2013002615

(87)【国際公開番号】WO2014170715

(87)【国際公開日】20141023

【審査請求日】2016年11月17日

(31)【優先権主張番号】13305502

(32)【優先日】2013年4月17日

(33)【優先権主張国】EP

(73)【特許権者】

【識別番号】501263810

【氏名又は名称】トムソン ライセンシング

【氏名又は名称原語表記】Ｔｈｏｍｓｏｎ Ｌｉｃｅｎｓｉｎｇ

(74)【代理人】

【識別番号】100079108

【弁理士】

【氏名又は名称】稲葉 良幸

(74)【代理人】

【識別番号】100109346

【弁理士】

【氏名又は名称】大貫 敏史

(74)【代理人】

【識別番号】100117189

【弁理士】

【氏名又は名称】江口 昭彦

(74)【代理人】

【識別番号】100134120

【弁理士】

【氏名又は名称】内藤 和彦

(74)【代理人】

【識別番号】100108213

【弁理士】

【氏名又は名称】阿部 豊隆

(72)【発明者】

【氏名】シャンペル，マリー−リュック

【審査官】 松崎 孝大

(56)【参考文献】

【文献】 特開２００３−００８６４４（ＪＰ，Ａ）

【文献】 特開２００１−３２０４１９（ＪＰ，Ａ）

【文献】 米国特許出願公開第２００３／０１９３９５０（ＵＳ，Ａ１）

【文献】 特開２００３−３０４２９９（ＪＰ，Ａ）

【文献】 吉村 健 Takeshi Yoshimura，移動通信におけるパケットロスを考慮したＲＴＰヘッダ圧縮・復元方法 Packet Loss Resilient RTP Header Compression over Wireless Links，マルチメディア，分散，協調とモバイル（ＤＩＣＯＭＯ）シンポジウム論文集 １９９７年〜２００６年版 Ｖｅｒ．１．１ ［ＤＶＤ−ＲＯＭ］ Multimedia,Distributed,Cooperative and Mobile Symposium，日本，社団法人情報処理学会，２０００年 ６月２８日，第2000巻，pp.295-300

(57)【特許請求の範囲】

【請求項1】

データを送信する方法であって、
複数のトランスポートパケットを含むデータストリームに、ビデオデータとオーディオデータのうち少なくとも一方をカプセル化するステップであって、各トランスポートパケットはヘッダ部とペイロード部とを含むステップと、
フルサイズパケットヘッダフォーマットと縮小サイズパケットヘッダフォーマットのうち一方を用いて、あるトランスポートパケットを送信できるか判断するステップと、
判断されたフォーマットに応じて前記データストリームのトランスポートパケットを構成するステップであって、構成されるトランスポートパケットは、少なくとも、第１のヘッダを含む第１のパケットと、第２のヘッダを含む第２のパケットとを含み、前記第１のヘッダは前記フルサイズパケットヘッダフォーマットに対応し、前記第２のヘッダは前記縮小サイズパケットヘッダフォーマットに対応するステップとを含み、
前記第１のパケットのシーケンス番号は前記第１のヘッダ中の複数のビットで表され、
前記第２のパケットのシーケンス番号は、前記第２のパケットのシーケンス番号に対応する他の複数のビットの最下位の所定数のビットを用いて前記第２のヘッダ内に示され、
前記第２のヘッダ中の参照シーケンス番号は、前記複数のビットの一部で表され、前記第２のヘッダが前記第１のヘッダを参照として用いることを示すために用いられ、
前記方法は、
構成した前記トランスポートパケットを送信するステップとを含む、
方法。

【請求項2】

前記構成するステップは、
前記第１のヘッダを有する前記第１のパケットを構成するステップと、
前記第２のヘッダを生成するステップであって、前記第２のヘッダは、送信を意図された値と、前記第１のヘッダ中の対応するフィールド中に表された値との間の差を表すフィールドを含む、ステップとを含む、
請求項１に記載の方法。

【請求項3】

データを受信する方法であって、
複数のトランスポートパケットを含み、ビデオデータとオーディオデータのうち少なくとも一方を含むデータストリームを受け取るステップであって、各トランスポートパケットはヘッダ部とペイロード部とを含み、前記複数のトランスポートパケットは少なくとも、第１のヘッダを有する第１のパケットと、第２のヘッダを有する第２のパケットとを含み、前記第１のヘッダはフルサイズパケットヘッダフォーマットに対応し、前記第２のヘッダは縮小サイズパケットヘッダフォーマットに対応する、ステップと、
前記第１のパケットのシーケンス番号は前記第１のヘッダ中の複数のビットで表され、
前記第２のパケットのシーケンス番号は、前記第２のパケットのシーケンス番号に対応する他の複数のビットの最下位の所定数のビットを用いて前記第２のヘッダ内に示され、
前記第２のヘッダ中の参照シーケンス番号は、前記複数のビットの一部で表され、
前記第１のヘッダのシーケンス番号と、前記第２のヘッダの参照シーケンス番号とに基づいて、前記第１のヘッダが前記第２のヘッダの参照として用いられるべきことを判断するステップと、
前記第１のヘッダを参照として用いて前記第２のヘッダを復号するステップとを含む、
方法。

【請求項4】

前記受信するステップは、
前記第１のヘッダを含む前記第１のパケットを受信するステップと、
前記第２のヘッダを含む前記第２のパケットを受信するステップとを含み、
前記復号するステップは、
前記第２のヘッダ中のフィールドを、前記第１のヘッダ中の対応するフィールドに応じて復号するステップを含む、
請求項３に記載の方法。

【請求項5】

データを送信する装置であって、
複数のトランスポートパケットを含むデータストリームに、ビデオデータとオーディオデータのうち少なくとも一方をカプセル化するように構成され、各トランスポートパケットはヘッダ部とペイロード部とを含む送信器と、
フルサイズパケットヘッダフォーマットと縮小サイズパケットヘッダフォーマットのうち一方を用いてトランスポートパケットを送信できるか決定し、前記決定されたフォーマットに応じて前記データストリームのトランスポートパケットを構成するように構成されたヘッダ圧縮器とを有し、
構成されるトランスポートパケットは、少なくとも、第１のヘッダを有する第１のパケットと、第２のヘッダを有する第２のパケットとを含み、前記第１のヘッダは前記フルサイズパケットヘッダフォーマットに対応し、前記第２のヘッダは前記縮小サイズパケットヘッダフォーマットに対応し、
前記第１のパケットのシーケンス番号は前記第１のヘッダ中の複数のビットで表され、
前記第２のパケットのシーケンス番号は、前記第２のパケットのシーケンス番号に対応する他の複数のビットの最下位の所定数のビットを用いて前記第２のヘッダ内に示され、
前記第２のヘッダ中の参照シーケンス番号は前記複数のビットの一部により表され、前記第２のヘッダが前記第１のヘッダを参照として用いることを示すために用いられ、前記送信器は構成された前記トランスポートパケットを送信するように構成される、
装置。

【請求項6】

前記送信器は、前記第１のヘッダを有する前記第１のパケットを送信するように構成され、
前記ヘッダ圧縮器は前記第２のヘッダを生成するように構成され、前記第２のヘッダは、送信すべく意図された値と、前記第１のヘッダ中の対応するフィールドに表された値との差を表すフィールドを含み、前記送信器は前記第２のヘッダを含む前記第２のパケットを送信する、
請求項５に記載の装置。

【請求項7】

前記第２のヘッダ中の参照シーケンス番号は前記複数のビットの最下位の所定数のビットで表される、請求項１または３に記載の方法。

【請求項8】

前記第１のヘッダは、前記第２のヘッダ中のフィールドに表されるデータが、前記第２のヘッダ中のフィールドに含まれるビット数の最大表現能力を超えたときに構成される、
請求項１に記載の方法。

【請求項9】

データを受信する装置であって、
複数のトランスポートパケットを含み、ビデオデータとオーディオデータのうち少なくとも一方を含むデータストリームを受け取るように構成された受信器であって、各トランスポートパケットはヘッダ部とペイロード部とを含み、前記複数のトランスポートパケットは少なくとも、第１のヘッダを有する第１のパケットと、第２のヘッダを有する第２のパケットとを含み、前記第１のヘッダはフルサイズパケットヘッダフォーマットに対応し、前記第２のヘッダは縮小サイズパケットヘッダフォーマットに対応する受信器と、
前記第１のパケットのシーケンス番号は前記第１のヘッダ中の複数のビットで表され、
前記第２のパケットのシーケンス番号は、前記第２のパケットのシーケンス番号に対応する他の複数のビットの最下位の所定数のビットを用いて前記第２のヘッダ内に示され、
前記第２のヘッダ中の参照シーケンス番号は、前記複数のビットの一部で表され、
前記第１のヘッダのシーケンス番号と、前記第２のヘッダの参照シーケンス番号とに基づいて、前記第１のヘッダが前記第２のヘッダの参照として用いられるべきことを判断するヘッダ復元器と、
前記第１のヘッダを参照として用いて前記第２のヘッダを復号するように構成される復号器とを有する、
装置。

【請求項10】

前記受信器は、前記第１のヘッダを含む前記第１のパケットを受信し、前記第２のヘッダを含む前記第２のパケットを受信し、前記ヘッダ復元器は、前記第２のヘッダ中のフィールドを前記第１のヘッダ中の対応するフィールドに応じて復号するように構成される、
請求項９に記載の装置。

【請求項11】

前記第２のヘッダは、他の複数のビットの最下位の所定数のビットを用いて前記第２のパケットのシーケンス番号を示す第２のフィールドを含み、前記他の複数のビットは前記第２のパケットのシーケンス番号に対応する、
請求項１または３に記載の方法。

【請求項12】

前記第１のヘッダ中の対応するフィールドは一組のビットにより表され、前記第２のヘッダ中のフィールドは、前記一組のビットと、受信したフィールドとに応じて復号され、前記第２のヘッダ中の復号されたフィールドは、前記第１のヘッダ中の対応するフィールドを表すのに使われるのと同じビット数を有する、請求項２または４に記載の方法。

【請求項13】

前記第２のヘッダは前記第２のヘッダが前記第１のヘッダを参照として用いることを示す前記複数のビットの最下位の所定数のビットを含む、
請求項５または９に記載の装置。

【請求項14】

前記第２のヘッダは前記第１のパケット中の第１のヘッダより少ないフィールドを含む、
請求項５または９に記載の装置。

【請求項15】

前記第２のパケット中の第２のヘッダは前記第１のパケット中の第１のヘッダより少ないフィールドを含む、請求項１または３に記載の方法。

【請求項16】

コンピュータに、請求項１−４、７、８、１１、１２及び１５いずれか一項に記載の方法のステップを実行させるコンピュータプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

［関連出願との相互参照］
本出願は、２０１３年５月１３日出願、発明の名称「Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｐａｃｋｅｔ Ｈｅａｄｅｒ Ｃｏｍｐｒｅｓｓｉｏｎ」の欧州特許出願第ＥＰ１３３０５５０２．０号の出願日の利益を主張するものである。この出願はその全体をここに参照援用する。

【0002】

本発明は、圧縮トランスポートパケットヘッダを生成する方法及び装置と、圧縮トランスポートパケットヘッダを処理する方法及び装置とに関する。

【背景技術】

【0003】

通信ネットワークにおいて、最も費用のかかるリソースのひとつは回線容量である。通信ネットワークを通じて伝送されるデータ量を効果的に削減するオーディオ及びビデオの圧縮方法が開発されている。また、トランスポートプロトコルの利用により生じるオーバーヘッドを削減することが重要である。より具体的に、トランスポートパケットヘッダのサイズを縮小することが重要である。

【発明の概要】

【0004】

本原理は、データを送信する方法を提供する。該方法は、複数のトランスポートパケットを含むデータストリームに、ビデオデータとオーディオデータのうち少なくとも一方をカプセル化するステップであって、各トランスポートパケットはヘッダ部とペイロード部とを含むステップと、フルサイズパケットヘッダフォーマットと縮小サイズパケットヘッダフォーマットのうち一方を用いて、あるトランスポートパケットを送信できるか判断するステップと、前記判断するステップに応じて前記データストリームのトランスポートパケットを構成するステップと、上記の通り構成された前記トランスポートパケットを送信するステップとを含む。本原理は、これらのステップを実行する装置も提供する。

【0005】

本原理は、データを受信する方法も提供する。該方法は、複数のトランスポートパケットを含み、ビデオデータとオーディオデータのうち少なくとも一方を含むデータストリームを受け取るステップであって、各トランスポートパケットはヘッダ部とペイロード部とを含むステップと、トランスポートパケットがフルサイズパケットヘッダフォーマットと縮小サイズパケットヘッダフォーマットのうち一方を用いているか判断するステップと、上記の通り判断された前記フォーマットに応じて前記データストリームのトランスポートパケットを復号するステップと、を含む。本原理は、これらのステップを実行する装置も提供する。

【0006】

本原理は、上記の方法によりデータを送信または受信する命令を記憶したコンピュータ読み取り可能媒体も提供する。

【図面の簡単な説明】

【0007】

【図1A】ペイロードデータに先行するＭＭＴ（ＭＰＥＧ Ｍｕｌｔｉｍｅｄｉａ Ｔｒａｎｓｐｏｒｔ）ペイロードヘッダの構造を示す図である。

【図1B】ＭＭＴペイロードヘッダエクステンションの構造を示す図である。

【図2】ＭＭＴパケットヘッダの構造を示す図である。

【図3】本原理の一実施形態による、縮小ヘッダ生成方法の一例を示すフロー図である。

【図4】本原理の一実施形態による、フルサイズヘッダのシーケンス番号中のビットを用いて縮小ヘッダのｒｅｄｕｃｅｄ＿ＳｅｑＮｕｍを生成すること、及びｒｅｄｕｃｅｄ＿ＳｅｑＮｕｍを用いて縮小ヘッダのシーケンス番号を復号することを示す図である。

【図5A】フルヘッダを有する修正ＭＭＴパケットの構造を示す図である。

【図5B】本原理の一実施形態による縮小ヘッダを有する修正ＭＭＴパケットの構造を示す図である。

【図6A】ペイロードデータに先行する修正ＭＭＴペイロードヘッダの構造を示す図である。

【図6B】本原理の一実施形態によるペイロードデータに先行する縮小ＭＭＴペイロードヘッダの構造を示す図である。

【図7】本原理の一実施形態による、フルヘッダを用いるか縮小ヘッダを用いるか判断する方法の一例を示すフロー図である。

【図8】本原理の一実施形態による、縮小ヘッダ復元方法の一例を示すフロー図である。

【図9】本原理の一実施形態による送信システムの一例を示すブロック図である。

【図10】本原理の一実施形態による受信システムの一例を示すブロック図である。

【図11】本原理の一実施形態による受信システムの他の一例を示すブロック図である。

【発明を実施するための形態】

【0008】

ＭＰＥＧ−Ｈパート１標準（ＭＰＥＧ Ｍｕｌｔｉｍｅｄｉａ ＴｒａｎｓｐｏｒｔすなわちＭＭＴとしても知られている）は、タイムド・メディア・コンテンツ及びノンタイムド・メディア・コンテンツのパッケージング、伝送及び構成に対する完全なソリューションを規定している。ＭＭＴは目下開発中であり、標準案は「Ｔｅｘｔ ｏｆ ＩＳＯ／ＩＥＣ ２ｎｄ ＣＤ ２３００８−１ ＭＰＥＧ Ｍｅｄｉａ Ｔｒａｎｓｐｏｒｔ， ＭＰＥＧ／Ｎ１３２９３」（Ｇｅｎｅｖａ， Ｓｗｉｔｚｅｒｌａｎｄ， Ｊａｎｕａｒｙ ２０１３（以下、「ＭＭＴ＿ＣＤ」と呼ぶ））に記載されている。

【0009】

ＭＭＴは主にＩＰネットワークに関するものであるが、任意のタイプのパケットベースネットワークによるコンテンツ配信もサポートしている。具体的に、ＭＭＴは、地上波、ケーブル又は衛星ネットワークなどのブロードキャストネットワークによるオーディオビジュアルサービスの配信に用いられ得る。

【0010】

ＭＭＴでは、「アセット（Ａｓｓｅｔ）」との用語は、同じトランスポート特性を有するデータを含み、同じアセットＩＤ（Ａｓｓｅｔ ＩＤ）を有する一以上のＭＰＵ（メディア処理ユニット）により構成されたデータエンティティを指す。「パッケージ（Ｐａｃｋａｇｅ）」との用語はデータの論理的コレクションを指し、一以上のアセット及びそれに関係するアセット配信特性（Ａｓｓｅｔ Ｄｅｌｉｖｅｒｙ Ｃｈａｒａｃｔｅｒｉｓｔｉｃｓ）（すなわち、アセットの配信に必要なサービス品質（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）に関する記述）及び構成情報（Ｃｏｍｐｏｓｉｔｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎ）（すなわち、アセット間の空間的及び時間的関係に関する記述）により構成されている。

【0011】

ＭＭＴパッケージング及びトランスポート機能は、２つのプロトコルで、すなわちＭＭＴ−Ｐａｙｌｏａｄ Ｆｏｒｍａｔ（ＭＭＴ−ＰＦ）とＭＭＴ−Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ（ＭＭＴ−ＴＰ）とで規定されている。具体的に、ＭＭＴ−ＰＦはマルチメディアパッケージのコンテンツ成分（例えば、オーディオ、ビデオ及びファイル）をパケット化する一般的ペイロードフォーマットを規定している。ＭＭＴ−ＰＦはメディアデータを符号化するのに用いる具体的なメディアコードにはとらわれず、シグナリングメッセージと順方向誤り訂正（Ｆｏｒｗａｒｄ Ｅｒｒｏｒ Ｃｏｒｒｅｃｔｉｏｎ（ＦＥＣ））情報とをパケット化するのにも使われる。ＭＭＴペイロードフォーマットは、ＲＴＰまたはＭＭＴトランスポートプロトコルなどの任意のパケットベースのトランスポートプロトコルに対して利用できる。ＭＭＴ−ＴＰは、ＩＰネットワーク環境を含むパケットベースの異種配信ネットワークによるパッケージのストリーミング配信をサポートするトランスポートプロトコルを確定する。ＭＭＴプロトコルは、パッケージ（Ｐａｃｋａｇｅ）の配信のための基本的機能を提供する。例えば、さまざまなアセットが単一のＭＭＴパケットフローにより配信できるようにするプロトコルレベル多重化、広い範囲のネットワークジッターに適合するプレゼンテーション時間に依存しない配信タイミングモデル、及びサービス品質（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）をサポートする情報などを提供する。

【0012】

図１Ａと図１Ｂはそれぞれ、ＭＭＴ−ＰＦプロトコルによるペイロードデータに先行するＭＭＴペイロードヘッダの構造と、ＭＭＴペイロードヘッダエクステンションの構造とを示している。このアプリケーションでは、ペイロードヘッダはＭＭＴ−ＰＦヘッダとも呼ばれる。セマンティックスの完全な説明はＭＭＴ＿ＣＤに記載されている。図１Ａと図１Ｂに示した幾つかのフィールドのセマンティックスを以下に再掲するが、これらは本原理により削除しても修正してもよい。
ｌｅｎｇｔｈ（１６ｂｉｔｓ）−このフィールドは、ヘッダを除くペイロードの長さをバイト単位で示している。これはパディングデータ（ｐａｄｄｉｎｇ ｄａｔａ）のサイズを含む。
ｆ＿ｉ（２ｂｉｔｓ）−このフィールドは、フラグメンテーションインジケータがペイロード中のデータユニットのフラグメンテーション（ｆｒａｇｍｅｎｔａｔｉｏｎ）に関する情報を含むことを示している。
ｆｒａｇｍｅｎｔａｔｉｏｎ＿ｆｌａｇ（Ｆ：１ｂｉｔ）−ｆｒａｇｍｅｎｔ＿ｃｏｕｎｔｅｒがあれば「１」に設定される。
ａｇｇｒｅｇａｔｉｏｎ＿ｆｌａｇ（Ａ：１ｂｉｔ）−ａｇｇｒｅｇａｔｉｏｎ＿ｉｎｆｏがあれば「１」に設定される。
ＲＡＰ＿ｆｌａｇ（Ｒ：１ｂｉｔ）−ペイロードがランダムアクセスポイント（又はその一部）を含めば「１」に設定される。
ｐａｙｌｏａｄ＿ｓｅｑｕｅｎｃｅ＿ｆｌａｇ（Ｐ：１ｂｉｔ）−ｐａｙｌｏａｄ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒがあれば「１」に設定される。
ｎｕｍｂｅｒ＿ｄａｔａ＿ｕｎｉｔ（ｎｕｍＤＵ：４ｂｉｔｓ）−このフィールドはこのＭＭＴペイロード中のデータユニット数を示す。ｆｒａｇｍｅｎｔａｔｉｏｎ＿ｆｌａｇが「１」に設定されたとき、このフィールドは「０」である。
ＤＵ＿ｏｆｆｓｅｔ（１６ｂｉｔｓ）−このフィールドはｄａｔａ＿ｏｆｆｓｅｔにより示される、バイトの各データユニットの位置を示す。ａｇｇｒｅｇａｔｉｏｎ＿ｆｌａｇが「１」に設定されたとき、このフィールドが使われる。
ｐａｙｌｏａｄ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒ（３２ｂｉｔｓ）−このフィールドは同じアセットに関連するペイロードのシーケンス番号を示す。

【0013】

図２は、ＭＭＴ−ＴＰプロトコルによるＭＭＴパケットヘッダの構成を示している。セマンティックスの完全な説明はＭＭＴ＿ＣＤに記載されている。本願では、ＭＭＴパケットヘッダはＭＭＴ−ＴＰヘッダとも呼ぶ。図２に示した幾つかのフィールドのセマンティックスを以下に再掲するが、これらは本原理により削除しても修正してもよい。
ｐａｃｋｅｔ＿ｉｄ（１６ｂｉｔｓ）−このフィールドは、あるアセットを他のアセットから区別するために各アセットに割り当てられた整数値である。
ｐａｃｋｅｔ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒ（３２ｂｉｔｓ）−このフィールドは、ｐａｃｋｅｔ＿ｉｄによりスコープされ、任意の値で始まりＭＭＴパケットごとに１ずつインクリメントされる整数値である。最大値に達した後、「０」に戻る。
ｔｉｍｅｓｔａｍｐ（３２ｂｉｔｓ）−このフィールドはＭＭＴパケット配信の時間インスタンスを指定する。ＮＴＰ（Ｎｅｔｗｏｒｋ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）時間は、ＩＥＴＦ ＲＦＣ５９０５， ＮＴＰ ｖｅｒｓｉｏｎ ４のクローズ６の「ショートフォーマット（ｓｈｏｒｔ−ｆｏｒｍａｔ）」に記載されているように、タイムスタンプで使われる。このタイムスタンプはＭＭＴパケットの第１ビットで測定される。

【0014】

ＭＭＴ−ＰＦとＭＭＴ−ＴＰは両方とも、可変サイズヘッダを含み、（普通にシーケンス番号を有する）ＭＭＴ−ＰＦの場合に最小サイズの９バイトであり、ＭＭＴ−ＴＰの場合に１２バイト（及び３ビット）である。ＭＭＴ−ＰＦとＭＭＴ−ＴＰを用いて非常に小さいパケットペイロードを伝送してもよいので、ヘッダに費やされるこれらの余分な２１バイトは非常に高いオーバーヘッドを表しているかも知れない。

【0015】

ヘッダのサイズを縮小するため、Ｒｏｂｕｓｔ Ｈｅａｄｅｒ Ｃｏｍｐｒｅｓｓｉｏｎ（ＲＦＣ３０９５で定義されたＲｏＨＣ）を用いても良い。ＲｏＨＣは、ヘッダのサイズを効果的に縮小できるが、受信側で大量の計算を要する可能性がある複雑なコーディング手法に依存し、受信器がパケットフィルタリングを目的としてヘッダの一部を調べればよい場合でも、受信器にすべてのヘッダを復号することを強制する。

【0016】

本原理は、上記の問題を解決し、少ない計算の複雑性でヘッダサイズを大幅に縮小できる方法と装置を提供する。

【0017】

一実施形態では、ヘッダは圧縮して送信しても、圧縮せずに送信してもよい。本願では、圧縮していないヘッダは「フルサイズヘッダ」または「フルヘッダ」と呼び、圧縮されたヘッダは「縮小サイズヘッダ」または「縮小ヘッダ」と呼ぶ。ヘッダ圧縮が使われているか区別するため、フィールド（本実施形態ではＣフィールドとする）を、例えばヘッダの始めに付け加えることができる。一例では、Ｃが０に設定されている場合、ヘッダは「フルサイズ（ｆｕｌｌ ｓｉｚｅ）」ヘッダを含み、Ｃが１に設定されている場合、ヘッダは「縮小サイズ（ｒｅｄｕｃｅｄ ｓｉｚｅ）」ヘッダを含む。

【0018】

縮小サイズヘッダを構成するため、フルサイズヘッダの幾つかのフィールドを削除してもよく、幾つかのフィールドをフルヘッダより少ないビットで表してもよく、新しいフィールドを追加してもよい。ヘッダ中のフィールドの順序を変更してもよい。以下、ＭＭＴ−ＴＰとＭＭＰ−ＰＦの場合のヘッダ圧縮の実施形態をさらに詳しく説明する。

ＭＭＴ−ＴＰヘッダ
図３は、縮小ＭＭＴ−ＴＰヘッダを生成する方法例３００を示す。方法３００はステップ３０５から始まる。ステップ３１０において、ｄｅｌｔａ＿ｔｉｍｅｓｔａｍｐフィールドを用いてタイムスタンプを表す。多くのビットを要するが、パケットに関連するタイムスタンプ情報は保存する必要がある。

【0019】

ｄｅｌｔａ＿ｔｉｍｅｓｔａｍｐフィールドは、参照フルサイズヘッダのタイムスタンプフィールドと、フルヘッダを使った場合に現在のタイムスタンプフィールドに入るだろう値との間の差を含む。一実施形態では、フルサイズヘッダは、受信器と送信器の両方が知っている規則に基づく参照ヘッダであることを暗示してもよく、例えば最後に受信したフルサイズヘッダを参照ヘッダとして用いてもよい。他の一実施形態では、フルサイズヘッダが参照ヘッダであると明示的に示されてもよい。タイムスタンプ間の差は、ＮＴＰタイムスタンプの最下位から１９個のビットと同様の方法で符号化される。これは、８秒の長さのタイムスタンプ精度を保つ。これらの２つのタイムスタンプの間の差が８秒より長い場合（それため１９ビットで符号化できる最長時間を超える場合）、縮小サイズヘッダを有する別のパケットに新しいタイムスタンプ参照値を提供するために、フルヘッダを有するパケットが送信される。

【0020】

フルヘッダのｐａｃｋｅｔ＿ｉｄフィールドは、ｒｅｄｕｃｅｄ＿ｐｃｋｔ＿ｉｄフィールドで置き換えられる。ｒｅｄｕｃｅｄ＿ｐｃｋｔ＿ｉｄはフルヘッダにおける１６ビットではなく８ビットを用いる。それゆえ、この１６ビットパケットＩＤから８ビットＩＤへの縮小は、ｐａｃｋｅｔ＿ｉｄが０ないし２５５であるストリームに対する縮小ヘッダの使用を制限する。それゆえ、ステップ３２０において、ｐａｃｋｅｔ＿ｉｄが０と２５５との間にあるかチェックする。ＹＥＳであれば、方法３００はｒｅｄｕｃｅｄ＿ｐｃｋｔ＿ｉｄの値を設定し、続けて縮小ヘッダを生成する。ＮＯであれば、提案のヘッダ縮小メカニズムは使用できず、フルヘッダを生成しなければならない。

【0021】

ステップ３３０において、ｒｅｄｕｃｅｄ＿ＳｅｑＮｕｍフィールドを用いてパケットのシーケンス番号を表す。ｒｅｄｕｃｅｄ＿ＳｅｑＮｕｍフィールドは、フルサイズヘッダが使われたとしたらヘッダの中にあるｐａｃｋｅｔ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒフィールドの最下位から８つのビットを含む。この新しいフィールドは８ビットで符号化されているので、本原理は、（同じｐａｃｋｅｔ＿ｉｄで特定される）各ストリームに対して、フルサイズヘッダを有するパケットが少なくとも２５６パケットごとに送信させる。

【0022】

ステップ３４０において、新しいフィールドＲｅｆＳｅｑＮｕｍを生成する。ＲｅｆＳｅｑＮｕｍは、フルヘッダが参照として用いられるパケットのシーケンス番号の少なくとも５ビットを含む。この新しいフィールドにより、受信器が、最後に受信したフルヘッダが現在の縮小サイズヘッダの参照として使われるものかチェックできるので、さらにロバストになる。パケットは失われることもあるので、フィールドＲｅｆＳｅｑＮｕｍは、フルヘッダ参照が受信されていない場合に受信器が縮小ヘッダを不適切に復号することを試みないようにするメカニズムを提供する。

【0023】

ステップ３５０において、「ｄｅｌｔａ＿ｔｉｍｅｓｔａｍｐ」、「ｒｅｄｕｃｅｄ＿ｐｃｋｔ＿ｉｄ」、「ｒｅｄｕｃｅｄ＿ＳｅｑＮｕｍ」、「ＲｅｆＳｅｑＮｕｍ」その他のフィールドが、例えば図５Ｂに示したフォーマットにより、縮小サイズヘッダ（ｒｅｄｕｃｅｄ ｓｉｚｅ ｈｅａｄｅｒ）に書き込まれる。方法３００はステップ３９９で終わる。
方法３００のステップは、図３に示した順序とは異なる順序で進行してもよく、例えばステップ３１０−３４０はどんな順序で行ってもよい。

【0024】

図４は、フィールド「ｒｅｄｕｃｅｄ＿ＳｅｑＮｕｍ」を生成するためシーケンス番号中のビットが用いられること、及び縮小ヘッダ中のシーケンス番号を復号するためにフィールド「ｒｅｄｕｃｅｄ＿ＳｅｑＮｕｍ」を用いられることを、例を用いて示している。この例では、現在のパケットＮ＋ｉが送信され、パケットＮで最後のフルサイズヘッダが受信される。送信側では、シーケンス番号（４１５）の最下位から８つのビット（４３０）のみを保存して、フィールド「ｒｅｄｕｃｅｄ＿ＳｅｑＮｕｍ」を生成する。これにより必要な処理が削減される。

【0025】

受信側における復号は送信側における符号化よりも複雑である。まず、逆圧縮器（ｄｅ−ｃｏｍｐｒｅｓｓｏｒ）が、参照として用いられるパケットの、シーケンス番号（４０５）、またはシーケンス番号の最上位から２４個のビット（４１０）を記憶する必要がある。逆圧縮器は、ｒｅｄｕｃｅｄ＿ＳｅｑＮｕｍの初期値として、シーケンス番号の最下位から８つのビット（４３０）を記憶することとしてもよい。次に、受信した各縮小ヘッダについて、復号器は、ｒｅｄｕｃｅｄ＿ＳｅｑＮｕｍが０を通ってループしたか追跡する必要がある。縮小ヘッダパケットの完全なシーケンス番号は、ｒｅｄｕｃｅｄ＿ＳｅｑＮｕｍ（４３０）を、参照シーケンス番号の最上位から２４ビット（４４０）（ｒｅｄｕｃｅｄ＿ＳｅｑＮｕｍが０を通ってループしたとき１だけインクリメントされる）に付加することにより得られる。すなわち、４４０に示されたビットは、ｒｅｄｕｃｅｄ＿ＳｅｑＮｕｍが０を通ってループしていなければ、４１０に示されたビットに等しく、そうでなければ、４１０に示されたビットより１だけ大きい。

【0026】

図５Ａは提案のフルＭＭＴ−ＴＰヘッダを示し、図５Ｂは、本原理による提案の縮小ＭＭＴ−ＴＰヘッダを示す。図２に示したＭＭＴ−ＴＰヘッダと比較して、フィールド「Ｑ」、「Ｆ」、「Ｐ」、「ＦＥＣ」、「ＲＥＳ」、「ＴＢ」、「ＤＳ」及び「Ｒ」が提案のフルＭＭＴ−ＴＰヘッダの始めに移動され、そのサイズとセマンティックス（ｓｅｍａｎｔｉｃｓ）は変更されておらず、フィールド「Ｓ」が削除され、フィールド「Ｃ」と「Ｉ」が追加されている。現在のヘッダ情報が後で参照として使われるのでそれを記憶すべきか示すために「Ｉ」フラグが用いられ、ＩフラグはフルＭＭＴ−ＰＦ及びＭＭＴ−ＴＰヘッダに追加されている。

【0027】

フィールドの順序も調整されている。フラグ「Ｃ］は、用いられるヘッダの種類を示すので、復号器により決定される最初の情報であることを要する。復号器が最初のビットから決定すると過程すると、フラグ「Ｃ」に最初のビットを用いることにより、復号器は続くヘッダの種類を最初に決定できる。

【0028】

図５Ｂに示した提案の縮小ＭＭＴ−ＴＰヘッダを図５Ａに示したフルＭＭＴ−ＴＰヘッダと比較すると、「ｐａｃｋｅｔ＿ｉｄ、「ｐａｃｋｅｔ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒ」及び「ｔｉｍｅｓｔａｍｐ」がそれぞれ「ｒｅｄｕｃｅｄ＿ｐｃｋｔ＿ｉｄ」、「ｒｅｄｕｃｅｄ＿ＳｅｑＮｕｍ」及び「ｄｅｌｔａ＿ｔｉｍｅｓｔａｍｐ」と置き換えられており、フィールド「ＲｅｆＳｅｑＮｕｍ」が追加されており、フィールド「Ｉ」、「ＲＥＳ」及び「ｒｅｓｅｒｖｅｄ」が削除されている。その結果、最小のＭＭＴ−ＴＰヘッダのサイズは９９ビットから５６ビットに減少し、これはビットの４３％節約である。

【0029】

ＭＭＴ−ＴＰストリームは、そのｐａｃｋｅｔ＿ｉｄにより特定され、各ストリームはそれ自体のｐａｃｋｅｔ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒシーケンスを有する。それゆえ、（ｐａｃｋｅｔ＿ｉｄが０ないし２５５の）限定された数のストリームにヘッダ縮小メカニズム（ｈｅａｄｅｒ ｒｅｄｕｃｔｉｏｎ ｍｅｃｈａｎｉｓｍ）を適用することにより、ＲｅｆＳｅｑＮｕｍとｒｅｄｕｃｅｄ＿ｐｃｋｔ＿ｉｄフィールドの組み合わせにより、縮小サイズヘッダの復号に用いる参照パケットを独特な方法で特定する。

【0030】

さらに、ｒｅｄｕｃｅｄ＿ｐｃｋｔ＿ｉｄはｐａｃｋｅｔ＿ｉｄフィールドの可能な値の範囲がより小さいコピーでしかないので、ｐａｃｋｅｔ＿ｉｄのフィルタリングによりなされる従来のパケットフィルタリングは、ｒｅｄｕｃｅｄ＿ｐｃｋｔ＿ｉｄに同様に使える。一例では、フィルタリングは、パケットを送信または受信すべきか決定するために、幾つかのフィールドを調べることである。ヘッダの一フィールドを読むためにＲｏＨＣなどの手法を用いる場合、ヘッダ全体を復元する必要がある。対照的に、提案の手法を使えば、所望のフィールドのみを復元すればよい。すなわち、フィルタリングは、元のｐａｃｋｅｔ＿ｉｄを再構成せずに、ｒｅｄｕｃｅｄ＿ｐａｃｋｅｔ＿ｉｄに直接的に行える。それゆえ、本原理によるヘッダ圧縮手法はパケットフィルタリングに対して完全にトランスパレント（ｔｒａｎｓｐａｒｅｎｔ）である。

ＭＭＴ−ＰＦヘッダ
通常、ヘッダ圧縮は、大きくかつ繰り返されるヘッダに対して関心を寄せる。ＭＭＴの場合、ＦＥＣリペアシンボルの場合に、または単一のＭＰＵが複数のセグメントで伝送されたときに、ヘッダ圧縮により大幅なビット節約が提供される。このように、ヘッダ圧縮により利益を受ける幾つかの具体的な使用シナリオに対して、縮小ヘッダを設計する。使用シナリオを検討して、下記の縮小サイズＭＭＴ−ＰＦヘッダを提案する。

【0031】

（１）アグリゲーション（ａｇｇｒｅｇａｔｉｏｎ）は縮小サイズヘッダによりサポートされていないので、Ａとｎｕｍｂｅｒ＿ｄａｔａ＿ｕｎｉｔとＤＵ＿ｏｆｆｓｅｔフィールドを削除した。その結果、アグリゲーションを使うとき、フルヘッダを使用する。

【0032】

（２）ペイロード中にＲａｎｄｏｍ Ａｃｃｅｓｓ Ｐｏｉｎｔ（ＲＡＰ）がある場合、常にフルヘッダが使われるので、Ｒフラグは削除した。これにより、ＲＡＰを有するパケットはそれ自体で（他の「参照」パケットの符号化に依存せずに）復号できるようにする。

【0033】

（３）縮小ヘッダを有するすべてのパケットはその「参照」パケットと同じｐａｙｌｏａｄ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒを有するので、Ｐ及びｐａｙｌｏａｄ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒフィールドは削除した。

【0034】

（４）ヘッダ圧縮は同サイズのフラグメントにのみ使われるので、ｌｅｎｇｔｈフィールドを削除した。その結果、最初のフラグメントはフルヘッダを用い、「参照」フラグメント（通常は最初のフラグメントであるが、必ずしもそうではないこともある）とは異なるサイズを有するフラグメントもフルヘッダを用いる。

【0035】

（５）ＲｅｆＳＮｕｍフィールドは、フルヘッダが参照として用いられるパケットのペイロードシーケンス番号の少なくとも４ビットを含む。これにより、受信器が、最後に受信したフルヘッダが現在の縮小サイズヘッダの参照として使われるものかチェックできるので、さらにロバストになる。パケットは失われることもあるので、これは、フルヘッダ参照が受信されていない場合に受信器が縮小ヘッダを不適切にデコードすることを試みないようにするメカニズムを提供する。

【0036】

図６Ａは提案のフルＭＭＴ−ＰＦヘッダを示し、図６Ｂは提案の縮小ＭＭＴ−ＰＦヘッダを示す。図１Ａに示したＭＭＴ−ＰＦヘッダと比較して、フィールド「ｆ＿ｉ」、「Ａ」、「Ｒ」、「Ｐ」及び「Ｅ」が、提案のフルＭＭＴ−ＰＦヘッダの始めに移動され、そのサイズとセマンティックスは変更していない。フラグ「Ｆ」と「Ｓ」が削除され、フィールド「Ｃ」と「Ｉ」が追加されている。フィールドの順序も調整されている。図６Ｂに示した提案の縮小ＭＭＴ−ＰＦヘッダを図６Ａに示したフルＭＭＴ−ＰＦヘッダと比較すると、フィールド「Ｉ」、「Ａ」、「Ｒ」、「Ｐ」、「ｌｅｎｇｔｈ」、「ｎｕｍＤＵ」、「ＤＵ＿ｏｆｆｓｅｔ」及び「ｐａｙｌｏａｄ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒ」が削除され、フィールド「ＲｅｆＳＮｕｍ」が追加されている。その結果、最小のＭＭＴ−ＰＦヘッダのサイズは１２８ビットから３２ビットに減少し、これはビットの７５％節約である。

【0037】

多くのアプリケーションにおいて、同じアセットの最後のフラグメント以外のすべてのフラグメントは、同じサイズを有し、それゆえ最初と最後のフラグメントのみでフルサイズヘッダを使え、他のすべてのフラグメントは、最初のフラグメントを参照として使いつつ、縮小ヘッダを使ってもよい。

【0038】

上記の通り、ＭＭＴ−ＰＦとＭＭＴ−ＴＰに対して、異なる方法を用いて、効率的かつロバストなヘッダ圧縮を提供した。一実施形態では、現在のフィールドと参照フィールドとの間の差、例えばｄｅｌｔａ＿ｔｉｍｅｓｔａｍｐを縮小ヘッダで用いる。フィールド自体ではなく差を用いることにより、より少ないビットを用いてフィールドを表せる。他の一実施形態では、現在のフィールドの下位ビット、例えばｒｅｄｕｃｅｄ＿ＳｅｑＮｕｍを用いて現在のフィールドを表す。かかるフィールドを受信したとき、そのフィールドを復元するため参照フィールドの上位ビットが必要である。これらの２つの実施形態は、すなわち、差を用いるものと上位ビットを用いるものは、現在のフィールドの異なる表現を用いてヘッダ圧縮を効率化する。他の一実施形態では、本原理による構成は、ヘッダ圧縮の利益がある典型的な使用シナリオを判断し、さらに縮小ヘッダにおいて幾つかのフィールドを削除できると判断する。また、より少ないビットを用いて縮小ヘッダ中の現在のフィールドを表す（例えば、ｒｅｄｕｃｅｄ＿ｐｃｋｔ＿ｉｄ）。これにより、現在のフィールドにより表され得る値に制約がかかることがある。本原理は、縮小ヘッダ使用の制約を認め、フィールドの値を設定するときのルールとガイドラインとを提供する。

【0039】

上記の通り、縮小ヘッダの使用にはルールと制約とがある。図７は、ルールと制約とを検討して縮小ヘッダまたはフルサイズヘッダを用いるか判断する方法例７００を示す。この方法は、例えば、ＭＭＴ−ＴＰによるトランスポートストリームに関連するヘッダを符号化する符号化器で実行される。方法７００はステップ７１０で始まり、初期化を行う。

【0040】

ステップ７２０において、現在のパケットのタイムスタンプと、参照パケットのタイムスタンプとの間の差が８秒より大きいか（、及びそれゆえ１９ビットのｄｅｌｔａ＿ｔｉｍｅｓｔａｍｐフィールドで符号化できないか）チェックする。ＹＥＳであれば、方法７００はステップ７７０においてフルサイズヘッダを生成する。

【0041】

ステップ７３０において、ｐａｃｋｅｔ＿ｉｄが０ないし２５５の範囲にあるかチェックする。ＮＯであれば、ｐａｃｋｅｔ＿ｉｄはｒｅｄｕｃｅｄ＿ｐｃｋｔ＿ｉｄにより正しく表せる範囲を超えており、ステップ７７０においてフルサイズヘッダが生成される。

【0042】

ステップ７４０において、（ｐａｃｋｅｔ＿ｉｄにより特定される）各ストリームに対して、ｒｅｄｕｃｅｄ＿ＳｅｑＮｕｍがその初期値で終わるか、チェックする。ＹＥＳであれば、方法７００はステップ７７０においてフルサイズヘッダを生成して、生成したヘッダを用いるさらに別のパケットに対して、参照シーケンス番号を提供する。

【0043】

ステップ７５０において、パケットが、Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｐｏｉｎｔ（ＲＡＰ）を含むアクセスユニットの最初のパケットであるかチェックする。ＹＥＳであれば、方法７００はステップ７７０においてフルサイズヘッダを生成する。そうでなければ、ステップ７６０において、縮小ヘッダを生成する。

【0044】

方法７００のステップは、図７に示した順序とは異なる順序で進行してもよく、例えばステップ７２０−７５０はどんな順序で行ってもよい。方法７００では、その他の条件の下で、例えばユーザ要求に基づき、フルサイズヘッダを生成することを選択してもよい。
ＭＭＴ−ＰＦに対してフルサイズヘッダまたは縮小ヘッダを使えるか判断するため、次の条件を検討し得る：
（１）アグリゲーションメカニズム（ａｇｇｒｅｇａｔｉｏｎ ｍｅｃｈａｎｉｓｍ）が使われている；
（２）Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｐｏｉｎｔ（ＲＡＰ）がある；
（３）新しいペイロードシーケンス番号が使われている；
（４）現在のパケットのｌｅｎｇｔｈ値が参照パケットのｌｅｎｇｔｈ値と異なる。

【0045】

上記の条件のうち少なくとも一つが満たされた場合、フルＭＭＴ−ＰＦヘッダを送信すべきである。他の条件の下で、例えばユーザ要求に基づき、フルＭＭＴ−ＰＦヘッダを送信することもできる。
受信側において、本原理による方法を実施する受信器は、例えば「Ｃ」フラグを用いて、フルサイズヘッダが用いられているかまたは縮小ヘッダが用いられているか判断する。受信器は、フルヘッダが参照としてマークされているとき、フルヘッダから得た重要な情報を、例えばヘッダの復元に必要なものを記憶する。

【0046】

図８は、縮小サイズＭＭＴ−ＰＴヘッダを復元する方法例８００を示す。方法８００はステップ８０５から始まる。ステップ８１０において、縮小ヘッダを受信し、縮小サイズヘッダから得たフィールド、例えば限定ではないが「ｄｅｌｔａ＿ｔｉｍｅｓｔａｍｐ」、「ｒｅｄｕｃｅｄ＿ＳｅｑＮｕｍ」及び「ＲｅｆＳｅｑＮｕｍ」などのフィールドを解析する。ステップ８２０において、参照として使われるフルサイズヘッダのｐａｃｋｅｔ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒの少なくとも５ビットがＲｅｆＳｅｑＮｕｍと同じであるかチェックする。それらが同じでなければ、縮小サイズヘッダは正しく復号できず、方法８００はステップ８９９で終了する。そうでなければ、ステップ８３０において、現在の縮小サイズヘッダの参照として用いられているフルサイズヘッダのタイムスタンプとｐａｃｋｅｔ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒを決定する。ステップ８４０において、参照フルヘッダのタイムスタンプと、ｄｅｌｔａ＿ｔｉｍｅｓｔａｍｐの和として、現在のパケットのタイムスタンプを決定する。ステップ８５０において、例えば図４に示したように、フルサイズヘッダのｐａｃｋｅｔ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒとｒｅｄｕｃｅｄ＿ＳｅｑＮｕｍとに基づいて、現在のパケットのパケットシーケンス番号を決定する。方法８００はステップ８９９で終わる。

【0047】

ＭＭＴ−ＰＦとＭＭＴ−ＴＰヘッダを例として用いて、さまざまな実施形態をどのように用いて効率的にヘッダを圧縮するか説明する。ヘッダ圧縮なので、現在のフィールドを正しく復号するために正しい参照フィールドを用いることが重要である。復号をロバストにするため、参照フィールド（例えば、ＲｅｆＳｅｑＮｕｍ）へのリンクを用いて、縮小サイズヘッダの間違った復号を防止できる。本原理は、他のアプリケーションやプロトコルにおいてヘッダ圧縮に用いることもできる。

【0048】

上記のさまざまな例では、フィールドの具体的な値（例えばフィールドやフラグのビット数など）や具体的な順序を説明した。これらの値や順序は、本原理が異なるアプリケーションやトランスポートプロトコルに適用される時に適宜調整する必要があるかも知れない。

【0049】

本原理による縮小ヘッダにおいて符号化されたパケットは、すべてのパケットの複雑なヘッダ復号をしなくても容易にフィルタできる。このように、本原理はネットワークの透明性という利点を提供する。また、単純なヘッダ圧縮メカニズムを用いることにより、本原理は、低い計算複雑性で実装でき、受信器において大がかりな処理を必要としない。

【0050】

図９は、送信システム例９００を示す。入力データは、例えばオーディオデータとビデオデータであるが、メディア符号化器９１０において符号化される。符号化されたデータは多重化器９２０で多重化され、送信器９３０で送信される。例えば方法３００と７００である本原理によるヘッダ圧縮メカニズムは、多重化器９２０または送信器９３０に配置されたヘッダ圧縮器（９４０、９５０）で用いることができる。送信システムは、帯域幅が高価な資源である一般的な放送テレビジョン環境において用いてもよいし、またはオーディオビジュアルサービスを提供するモバイルデバイスで用いてもよい。メディア符号化プロセスに続いて、多重化器９２０においてヘッダ圧縮を用いることにより、予めヘッダ圧縮を準備することができる。ＭＭＴ−ＰＦフローは実際に送信される前にファイルフォーマットで記憶されてもよいからである。送信器９３０において、本システムは、ＭＭＴ−ＰＦヘッダ圧縮を（場合によっては更新して）再利用してもよく、実際のＭＭＴ−ＴＰパケットを送信する前にＭＭＴ−ＴＰヘッダ圧縮を利用してもよい。

【0051】

図１０は、受信システム例１０００を示す。システム１０００の入力データは、トランスポートビットストリームであってもよく、例えばシステム９００の出力であってもよい。データは、受信器１０１０で受信され、逆多重化器１０２０で逆多重化され、メディア復号器１０３０で復号される。ＭＭＴ−ＴＰパケットを受信したとき、ヘッダ復元器（１０４０、１０５０）が、参照パケットから得たヘッダ情報を記憶して、縮小ヘッダを復号することにより、ＭＭＴ−ＴＰヘッダ復元を行う。復号されたパケットは逆多重化器１０２０のバッファに入れておける。ＭＭＴ−ＰＦペイロードを処理するとき、逆多重化器１０２０は、ＭＭＴ−ＰＦヘッダ復元を用いてもよい。

【0052】

図１１は、他の受信システム例１１００を示す。概して、図１１のビデオ受信システムにおいて、放送番組コンテンツを表すオーディオ、ビデオ及び関連データを担う信号で変調された放送キャリアが、アンテナ１０で受信され、ユニット１３で処理される。得られたデジタル出力信号は復調器１５により復調される。ユニット１５からの復調出力は、復号器１７により、トレリス復号され、バイト長データセグメントにマッピングされ、逆インターリーブされ、リードソロモンエラー訂正される。ユニット１７の出力データは、ＭＰＥＧ互換トランスポート・データストリームの形式であり、例えば番組を代表する多重化されたオーディオ、ビデオ及びデータコンポーネントを含むＭＭＴトランスポートストリームの形式である。ユニット１７から出力されるトランスポートストリームは、ユニット２２によりオーディオ、ビデオ及びデータコンポーネントに逆多重（ｄｅｍｕｌｔｉｐｌｅｘ）され、これらは復号器１００の他の要素によりさらに処理される。

【0053】

例えばＭＭＴ−ＰＦ及びＭＭＴ−ＴＰヘッダ圧縮などのヘッダ圧縮手法が使われる場合、ユニット２２は、ストリームを逆多重し、エレメンタリストリームをユニット２５、３５または９５に送信する前に、ヘッダ復元を行う。一モードでは、復号器１００は、ユニット５０と５５でそれぞれ表示及びオーディオ再生する復号されたＭＰＥＧデータを提供する。他の一モードでは、ユニット１７から出力されるトランスポートストリームは、復号器１００により処理され、記憶デバイス９０を介して記憶媒体１０５に記憶されるＭＰＥＧ互換データストリームを提供する。

【0054】

ユーザは、リモートコントロールユニット７０を用いて、テレビチャンネルまたは番組ガイドなどのオンスクリーンメニューを見る選択をする。プロセッサ６０は、視聴する所望の番組チャンネルを受信するように図１１の要素を適切に設定する、インタフェース６５を介してリモートコントロールユニット７０から提供される選択情報を用いる。プロセッサ６０は、プロセッサ６２とコントローラ６４とを有する。ユニット６２は、番組ガイドとシステム情報を含む特定番組情報を処理（すなわち、解析、照合及び組み立て）し、コントローラ６４は、復号器１００の動作に必要な残りの制御機能を実行する。ユニット６０の機能は図１１に示したように別々の要素６２と６４として実装されてもよいが、代替的に単一のプロセッサ内に実装されてもよい。例えば、ユニット６２と６４の機能はマイクロプロセッサのプログラム命令に組み込まれてもよい。プロセッサ６０は、入力信号のフォーマットと符号化タイプを復調し、復号するよう、プロセッサ１３、復調器１５、復号器１７及び復号システム１００を設定する。

【0055】

図１１を詳細に検討してオーディオ、ビデオ及び関連データを表す番組を担う信号で変調され、アンテナ１０により受信されたキャリアは、デジタル形式に変換され、入力プロセッサ１３により処理される。プロセッサ１３は、無線周波数（ＲＦ）チューナと、中間周波数（ＩＦ）ミキサと、入力信号を後段の処理に適した低周波数帯にダウンコンバートする増幅段とを含む。

【0056】

例えば、ビデオ受信器ユーザがリモートコントロールユニット７０を用いて視聴するサブチャンネル（ＳＣ）を選択すると仮定する。プロセッサ６０は、インタフェース６５を介してリモートコントロールユニット７０から提供される選択情報を用いて、選択されたサブチャンネルＳＣに対応する物理的チャンネルを受信するように、復号器１００要素を適切に設定する。

【0057】

プロセッサ２２に提供される出力データは、番組チャンネルコンテンツと、複数のサブチャンネルを通して配信される多くの番組の特定番組情報とを含むトランスポート・データストリームの形式である。

【0058】

プロセッサ２２は、復号器１７により提供される入来パケットのＰａｃｋｅｔ Ｉｄｅｎｔｉｆｉｅｒｓ（ＰＩＤｓ）を、サブチャンネルＳＣで送信されているビデオ、オーディオ及びサブピクチャストリームのＰＩＤ値と一致するか調べる。これらのＰＩＤ値は、プロセッサ６０によりユニット２２内の制御レジスタにプリロードされる。プロセッサ２２は、サブチャンネルＳＣで送信される番組を構成するパケットをキャプチャし、それらから、ビデオ復号器２５及びオーディオ復号器３５にそれぞれ出力するＭＰＥＧ互換のビデオ及びオーディオストリームを構成する。ビデオ及びオーディオストリームは、選択されたサブチャンネルＳＣ番組コンテンツを表す圧縮されたビデオ及びオーディオデータを含む。
プロセッサ２２は、ＭＭＴ−ＰＦ及びＭＭＴ−ＴＰヘッダ圧縮などの本原理によるヘッダ圧縮が使われているか検出し、パケットがヘッダ圧縮のための参照ヘッダを提供するか検出する。プロセッサ２２は、参照ヘッダを記憶し、それを用いて縮小サイズヘッダを復号する。

【0059】

復号器２５は、ユニット２２から出力されたパケット化されたＭＰＥＧ互換ビデオデータを復号及び復元し、復元された番組表現画素データをデバイス５０に表示のため提供する。同様に、オーディオプロセッサ３５は、ユニット２２からのパケット化されたオーディオデータを復号し、復号されたオーディオデータであって関連する復元されたビデオデータと同期したものをデバイス５５にオーディオ再生のために提供する。

【0060】

図１１のシステムの記憶モードでは、ユニット１７からの出力データは復号器１００により処理され、ＭＰＥＧ互換データストリームを記憶のため提供する。このモードでは、番組は、ユーザによりリモートコントロールユニット７０とインタフェース６５とを介して、記憶のため選択される。

【0061】

プロセッサ６０は、プロセッサ２２と共に、選択された番組のパケット化されたコンテンツデータと、関連する特定番組情報とを含むコンポジットＭＰＥＧ互換データストリームを構成する。コンポジットデータストリームはストレージインタフェース９５に出力される。ストレージインタフェース９５は、コンポジットデータストリームをバッファし、データのギャップとビットレート変動を低減する。バッファされたデータは、媒体１０５への記憶に適したように、ストレージデバイス９０により処理される。ストレージデバイス９０は、チャンネル符号化、インターリーブ及びリードソロモン符号化などの既知のエラー符号化手法を用いて、インタフェース９５からのバッファされたデータストリームを符号化し、符号化され記憶に適したデータストリームを生成する。ユニット９０は、縮約された特定番組情報（ｃｏｎｄｅｎｓｅｄ ｐｒｏｇｒａｍ ｓｐｅｃｉｆｉｃ ｉｎｆｏｒｍａｔｉｏｎ）を組み込んだ、符号化されたデータストリームを、媒体１０５に記憶する。

【0062】

ここで説明した実施形態は、方法またはプロセス、装置、またはソフトウェアプログラム、データストリーム、又は信号として実施できる。１つの形式の実施形態の場合で説明した（例えば、方法としてのみ説明した）場合であっても、説明した機能の実施形態は他の形式（例えば、装置やプログラム）でも実施できる。装置は例えば適切なハードウェア、ソフトウェア、及びファームウェアで実施可能である。上記の方法は、例えばプロセッサ等の装置で実施可能である。プロセッサとは、処理装置一般を指し、例えばコンピュータ、マイクロプロセッサ、集積回路、プログラマブル論理デバイスなどを指す。プロセッサは、エンドユーザ間での情報通信を行う、コンピュータ、セルラー電話、ポータブル／パーソナル・デジタル・アシスタント（ＰＤＡ）などのデバイス、及びその他の通信デバイスも含む。

【0063】

本原理の「一実施形態」等と言う場合、本発明の少なくとも１つの実施形態に含まれるその実施形態に関して説明する具体的な特徴、構造、特性などを意味する。それゆえ、本明細書を通していろいろなところに記載した「一実施形態において」等と言った場合、必ずしもすべてが同じ実施形態を参照するものではない。

【0064】

また、本願とその特許請求の範囲において、様々な情報を「判断（ｄｅｔｅｒｍｉｎｉｎｇ）」する旨を記載した。情報の判断には、例えば、その情報の推定、その情報の計算、その情報の予測、またはその情報のメモリからの読み出しのうちの一以上が含まれ得る。

【0065】

さらに、本願とその特許請求の範囲において、様々な情報を「アクセス（ａｃｃｅｓｓｉｎｇ）」する旨を記載した。情報へのアクセスは、例えば、情報の受け取り、（例えば、メモリからの）情報の読み出し、情報の記憶、情報の処理、情報の送信、情報の移動、情報のコピー、情報の削除、情報の計算、情報の決定、情報の予測、又は情報の推定などの一以上を含み得る。

【0066】

また、本願とその特許請求の範囲において、様々な情報を「受け取る」旨を記載した。受け取りは、「アクセス」と同様に、広い意味で用いている。情報の受け取りは、例えば、情報へのアクセス、または（例えば、メモリからの）情報の読み出しのうちの一または複数を含み得る。さらに、「受け取り（ｒｅｃｅｉｖｉｎｇ）」は、一般的に、例えば、情報の記憶、情報の処理、情報の送信、情報の移動、情報のコピー、情報の削除、情報の計算、情報の決定、情報の予測または情報の推定などの動作中にいろいろな点で関係してくる。

【0067】

当業者には言うまでもないが、実施形態は、例えば記憶または送信され得る情報を担うようフォーマットされた種々の信号を生成することもできる。情報には、例えば、方法を実行する命令や、説明した実施形態により生成されるデータが含まれ得る。例えば、信号は説明した実施形態のビットストリームを担うようにフォーマットされてもよい。かかる信号は、（例えば、無線周波数のスペクトルを用いた）電磁波やベースバンド信号などとしてフォーマットし得る。フォーマット化には、例えば、データストリームの符号化、符号化したデータストリームによるキャリアの変調が含まれる。信号が担う情報は例えばアナログ情報やデジタル情報であってもよい。知られているように、信号は様々な異なる有線リンクまたは無線リンクで送信できる。信号はプロセッサ読み取り可能媒体に記憶してもよい。
次の付記を記す。
（付記１） データを送信する方法であって、
複数のトランスポートパケットを含むデータストリームに、ビデオデータとオーディオデータのうち少なくとも一方をカプセル化するステップであって、各トランスポートパケットはヘッダ部とペイロード部とを含むステップと、
フルサイズパケットヘッダフォーマットと縮小サイズパケットヘッダフォーマットのうち一方を用いて、あるトランスポートパケットを送信できるか判断するステップと、
前記判断するステップに応じて前記データストリームのトランスポートパケットを構成するステップと、
構成した前記トランスポートパケットを送信するステップとを含む、方法。
（付記２） 前記構成するステップは、
第１のヘッダを有する第１のパケットを構成するステップであって、前記第１のヘッダは第２のパケットの第２のヘッダに対する参照として提供され、前記第１のヘッダは前記フルサイズパケットヘッダフォーマットに対応し、前記第２のヘッダは前記縮小サイズパケットヘッダフォーマットに対応するステップと、
前記第２のヘッダを生成するステップであって、前記第２のヘッダ中の一フィールドが前記第１のヘッダ中の対応するフィールドに対して表し方が異なるステップとを含む、
付記１に記載の方法。
（付記３） データを受信する方法であって、
複数のトランスポートパケットを含み、ビデオデータとオーディオデータのうち少なくとも一方を含むデータストリームを受け取るステップであって、各トランスポートパケットはヘッダ部とペイロード部とを含むステップと、
トランスポートパケットがフルサイズパケットヘッダフォーマットと縮小サイズパケットヘッダフォーマットのうち一方を用いているか判断するステップと、
判断された前記フォーマットに応じて前記データストリームのトランスポートパケットを復号するステップとを含む、方法。
（付記４） 前記受信するステップは、
第１のヘッダを含む第１のパケットを受信するステップと、
第２のヘッダを含む第２のパケットを受信するステップであって、前記第１のヘッダは前記フルサイズパケットヘッダフォーマットに対応し、前記第２のヘッダは前記縮小サイズパケットヘッダフォーマットに対応し、前記第２のヘッダはフィールドを含む、ステップとを含み、
前記復号するステップは、
前記第１のヘッダを前記第２のヘッダの参照として用いることを決定するステップと、
前記第２のヘッダ中のフィールドを、前記第１のヘッダ中の対応するフィールドに応じて復号するステップとを含む、
付記３に記載の方法。
（付記５） データを送信する装置であって、
複数のトランスポートパケットを含むデータストリームに、ビデオデータとオーディオデータのうち少なくとも一方をカプセル化するように構成され、各トランスポートパケットはヘッダ部とペイロード部とを含む送信器と、
フルサイズパケットヘッダフォーマットと縮小サイズパケットヘッダフォーマットのうち一方を用いてトランスポートパケットを送信できるか決定し、前記決定に応じて前記データストリームのトランスポートパケットを構成するように構成されたヘッダ圧縮器とを有し、前記送信器は構成された前記トランスポートパケットを送信するように構成される、装置。
（付記６） 前記送信器は、第１のヘッダを有する第１のパケットを送信するように構成され、前記第１のヘッダは第２のパケットの第２のヘッダに対する参照として提供され、前記第１のヘッダは前記フルサイズパケットヘッダフォーマットに対応し、前記第２のヘッダは前記縮小サイズパケットヘッダフォーマットに対応し、
前記ヘッダ圧縮器は前記第２のヘッダを生成するように構成され、前記第２のヘッダ中のフィールドは前記第１のヘッダ中の対応するフィールドに対する差として表され、前記送信器は前記第２のヘッダを含む前記第２のパケットを送信する、
付記５に記載の装置。
（付記７） 前記第２のヘッダ中のフィールドは複数のビットで表すことができ、前記ヘッダ圧縮器は、前記第２のヘッダ中のフィールドを前記複数のビットの下位ビットで表すことにより前記第２のヘッダを生成する、
付記２または５に記載の方法または装置。
（付記８） 前記第１のヘッダは、前記フィールドに表されるデータが前記フィールドに含まれるビット数の最大表現能力を超えたときに構成される、
付記２または５に記載の方法または装置。
（付記９） データを受信する装置であって、
複数のトランスポートパケットを含み、ビデオデータとオーディオデータのうち少なくとも一方を含むデータストリームを受け取るように構成され、各トランスポートパケットはヘッダ部とペイロード部とを含む受信器と、
トランスポートパケットがフルサイズパケットヘッダフォーマットと縮小サイズパケットヘッダフォーマットのうち一方を用いているか決定し、決定されたフォーマットに応じて前記データストリームのトランスポートパケットを復号するように構成されたヘッダ復元器とを有する、装置。
（付記１０） 前記受信器は第１のヘッダを含む第１のパケットを受信し、第２のヘッダを含む第２のパケットを受信し、前記第１のヘッダは前記フルサイズパケットヘッダフォーマットに対応し、前記第２のヘッダは前記縮小サイズパケットヘッダフォーマットに対応し、前記第２のヘッダはフィールドを含み、前記ヘッダ復元器は、前記第１のヘッダを前記第２のヘッダの参照として用いることを決定し、前記第２のヘッダ中のフィールドを前記第１のヘッダ中の対応するフィールドに応じて復号するように構成される、
付記９に記載の装置。
（付記１１） 前記第１のヘッダは前記第１のヘッダが前記参照として用いられることを示す第２のフィールドを含む、
付記２、４、６または１０に記載の方法または装置。
（付記１２） 前記第１のヘッダ中の対応するフィールドは複数のビットにより表すことができ、前記第２のヘッダ中のフィールドは、前記複数のビットの上位ビットと受信したフィールドとに応じて復号され、前記第２のヘッダ中の復号されたフィールドは、前記第１のヘッダ中の対応するフィールドを表すのに使われるのと同じビット数を有する、
付記４または１０に記載の方法または装置。
（付記１３） 前記第２のヘッダは前記第１のパケットへのリンクを含む、
付記２、４、６または１０に記載の方法または装置。
（付記１４） 前記第１のヘッダ中のシーケンス番号は複数のビットにより表すことができ、前記第２のヘッダは前記複数のビットの、前記第１のパケットへのリンクを提供する部分を含む、
付記１３に記載の方法または装置。
（付記１５） 前記第２のパケット中の第２のヘッダは前記第１のパケット中の第１のヘッダより少ないフィールドを含む、
付記２、４、６または１０に記載の方法または装置。
（付記１６） 付記１−４、７、８、及び１１−１５に記載の、データを送信または受信する命令を記憶したコンピュータ読み取り可能記憶媒体。

【図1A】

【図1B】

【図2】

【図3】

【図4】

【図5A】

【図5B】

【図6A】

【図6B】

【図7】

【図8】

【図9】

【図10】

【図11】