JP2011507321A - 圧縮されたネットワークヘッダの確実な送信のための方法と装置 - Google Patents

Abstract

データが少なくとも１つの圧縮ヘッダフィールドと１つのデータフィールドを含むパケットの形式でかつ伝送システムに適した形式に従って送信される、伝送システムにおいてデータを送信するための方法であって、少なくとも、
−圧縮ヘッダと有用データを含む送信対象のデータパケットを再生し、有用データ部からヘッダ部を特定する工程と、
−使用する保護モードで通信中にも、ヘッダレベルで選択された訂正符号を適用し、その結果の新しいパケットをリンク層に提供する工程と、
−使用する保護モードを組み込んだ当該伝送システムの伝送形式とリンク層のＣＲＣチェックサムの適合度とに従ってリンクヘッダを生成する工程と、
−受信すると、エラー訂正復号化を２つの工程で実行する工程と、を含むことを特徴とする方法。
【選択図】 図１

Description

本発明は、伝送システムにおける、エラーに対しデータを保護することを可能にする方法と装置に関する。本発明は特にマルチメディアデータの送信に使用される。本発明はまた、圧縮ヘッダ（ｃｏｍｐｒｅｓｓｅｄ ｈｅａｄｅｒ）を有するパケットによるデータの送信に適用される。

データ伝送の分野では、データは伝送チャネル自体によるエラーにより損なわれることがある。無線チャネルにおける送信（例えば、ＵＭＴＳ（汎用移動通信システム：Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｙｓｔｅｍ）、ＷｉＦｉ技術あるいはＷｉＭＡＸ、または高周波（ＨＦ）チャネル上で採用される解決策等の使用など）は、受信時のデータの復号化を妨害し得るエラーを引き起こす。

これらのエラーが送信を妨害し得るという危険に対処するために、データ再送信タイプの解決策（例えば、略称ＡＲＱ（自動再送要求：Ａｕｔｏｍａｔｉｃ Ｒｅｐｅａｔ）によりよく知られたデータの自動再送信あるいはその分派のハイブリッドＡＲＱの技術）を使用することは当業者に知られている。

これらの解決策は一般的にはネットワークレベルで適用される。無線アクセスレベルすなわち伝送システムの物理層のレベルでの冗長性（ＦＥＣ：順方向誤り訂正）の導入に直接依存する解決策もまた存在する。物理層のレベルでの重大誤り訂正符号（ｍｏｒｅ ｓｉｇｎｉｆｉｃａｎｔ ｅｒｒｏｒ ｃｏｒｒｅｃｔｏｒ ｃｏｄｉｎｇ）を有するあるいは再送信を活用する標準的な圧縮ヘッダを採用することも知られている。

従来技術の解決策の主要な欠点は、一般的には、実際にそのヘッダが依然として正しければ部分的に破損したペイロードを受信することを願う人もいるかもしれないにもかかわらず、破損した場合のパケットを区別せずに除去することで保護がヘッダプラスデータレベル全体として与えられるということである。

再送信技術のさらなる欠点は、これらの技術が、特に一斉通報アプリケーションの場合に双方向リンクの存在（これは常に可能だとは限らない）を前提するということである。

従来技術の別の欠点は、ネットワーク層下の物理レベルにおいて高度の冗長性を生じさせるということである。これは、一方では、（このような保護レベルの、または使用したい符号の利用のための措置がなされていない場合に）使用する標準規格との非互換性を引き起こす可能性があり、他方では、一般的に、無差別的方法でパケット全体として保護レベルの増加をもたらし、したがって帯域幅の点で高価となってしまう。

本発明の考えは、特に、データ送信が正常に動作している場合に有用データを保護することもなく送信対象のパケットのヘッダを保護するということがその本質にある新規な手法に依存する。

主題は、データが少なくとも１つの圧縮ヘッダフィールドと１つのデータフィールドを含むパケットの形式でかつ伝送システムに適した形式に従って送信される、伝送システムにおいてデータを送信するための方法であって、少なくとも、
−ヘッダと有用データを含む送信対象のデータパケットを再生し、有用データ部からヘッダ部を特定する工程と、
−使用する保護モードで通信中にも、ヘッダレベルで選択された訂正符号を適用し、その結果の新しいパケットをリンク層に提供する工程と、
−使用する保護モードを組み込んだ当該伝送システムの伝送形式とリンク層のＣＲＣチェックサムの適合度とに従ってリンクヘッダを生成する工程と、
−受信すると、次の２つの工程、すなわち
・ＲＣＨ圧縮ヘッダの最初の部分を復号化して初期の圧縮ヘッダのサイズに関する情報を推定できるようにする第１の工程と、
・先に判断されたサイズ情報に基づいてヘッダの残り部分を復号化する第２の工程と、でエラー訂正復号化を実行する工程と、を含むことを特徴とする方法である。

他の特徴と利点は、添付図面に関連する以下の限定しない例として与えられる詳細説明を読むことで明らかになるであろう。

ＲＣＨ（ロバストな圧縮ヘッダ：ｒｏｂｕｓｔ ｃｏｍｐｒｅｓｓｅｄ ｈｅａｄｅｒ）パケット保護の図である。 本発明によるＲＣＨモジュールを実装した例示的な通信チェーンの図である。 使用スループットとアプリケーションレベルにおける最終収率とに関する利得曲線である。 使用スループットとアプリケーションレベルにおける最終収率とに関する利得曲線である。 アプリケーション、セッション、トランスポート、ネットワーク、リンク、および物理層を介した無線ネットワーク上のマルチメディアデータの送信の典型的な工程を表す。

本発明による方法をよりうまく解明するために、以下の説明は、特にＩＰヘッダが例えばＲＦＣ３０９５およびその関係するＲＦＣにおけるＩＥＴＦ委員会により標準化されたＲＯＨＣ（ロバストなヘッダ圧縮：Ｒｏｂｕｓｔ Ｈｅａｄｅｒ Ｃｏｍｐｒｅｓｓｉｏｎ）規格により圧縮されたときのＩＰヘッダを保護するためのアプリケーションの枠組み内で与えられる。

この考えは、特に、パケットヘッダを保護するためにエラー訂正符号を適用することにより当該圧縮ヘッダに保護メカニズムを適用することにその本質がある。実際、ヘッダの損失は一般的にはパケットの損失を引き起こす。ここで、所与の例では、トランスポートまたはアプリケーションレベルでたとえ部分的に破損したとしてもソースデータ（すなわちアプリケーションレベルで有用なデータ）の受信は、対応するパケットを損失することよりも好ましい。これは、通常、アプリケーションまたはトランスポートレベルでの保護、訂正、またはマスキングためのメカニズムを実装することが可能となった送信（例えば、音声または映像送信など）を伴う。この場合、そのヘッダの破損の理由でプロトコルスタックからパケットを（例えば、リンクまたはネットワークレベルで）削除することは有害である。

図１には、本発明による方法を適用することにより送信対象のデータパケットのコンテンツまたは形式の変化を許容する工程を図式的に示す。

本方法は例えば以下の工程を実施する。
−工程１：ＩＰ層１からネットワークパケットを再生し、ソースデータ部から圧縮ヘッダ部２を特定する。ネットワークの観点からは、ペイロード＝当該層の観点からの送信対象データ（従って、特にはソースデータであるが上記層のヘッダでもある）。
−工程２：デフォルト符号または当該伝送リンクの状態に関し利用可能な情報に応じて選択された符号を含む選択された訂正符号を適用し、結果の新しいネットワークパケット４を、ＲＣＨ（ロバストな圧縮ヘッダ）エラー符号化情報（使用される保護のモード、および必要に応じて保護された圧縮ヘッダの長さ）の識別子により、リンク層へ提供する。
−工程３：ＲＣＨ情報（使用される保護のモード、および必要に応じて保護された圧縮ヘッダの長さ）を取り込む当該送信規格とリンク層のチェックサム（ＣＲＣ）の適合度とに従ってリンクヘッダを生成する。

ＲＣＨ（ロバストな圧縮ヘッダ）のメカニズムは、保護対象のデータパケットの部分はより必然であるので実現することは高価となるものの、ヘッダが実際には圧縮されていない場合（例えば、ＲＯＨＣプロトコルの非圧縮モード"ＵＮＣＯＭＰＲＥＳＳＥＤ"を採用する場合）にも当然適用される。

ＲＣＨのメカニズムは、従来のヘッダ圧縮メカニズムのアプリケーションに直接組み込まれてよく、これにより第１の工程における有用データ部からＲＣＨモジュールへの圧縮ヘッダ部の識別子の送信を簡単にすることができる。

ＲＣＨのメカニズムはまた、有用データのすべてまたは一部に関係させるように誤り訂正符号化メカニズムを適合させることにより有用データのすべてまたは一部の保護まで拡張してよい。これは、対応するＲＣＨ情報をリンクヘッダに追加する必要性も伴う。実際、ＲＣＨのメカニズムは、ヘッダが有用データ部よりうまく保護される場合のみ有益であろう。

送信対象のデータは例えばマルチメディア型である。

図２には、ＲＣＨモジュールを実装する例示的な通信チェーンを示す。ＲＣＨモジュールは実際上、従来のＲＯＨＣ型のヘッダ圧縮モジュールの場所（またはその内部）のネットワーク層（ＩＰ）下に位置する。送信者１側では、ＲＣＨデータは知られているか、あるいは以下説明されるモードに従ってＲＣＨモジュール２により導入される。受信者３側では、受信者は、エラー（仮にあれば）の訂正に使用されるパラメータを知っているか、あるいはこれらのパラメータ（使用される保護のモード、および必要に応じて保護された圧縮ヘッダの長さ）を見つけ出すのに好適なＲＣＨモジュール４を含む。データは無線リンク５を介し送信される。

先に記載された３つの工程に依存するＲＣＨの実施については、以下では、８０２．１１型の無線アクセスへのアプリケーションの場合が例示される。

実際、８０２．１１規格［１］は、以下のように交換されるフレームの形式を定義する。

ここで、各フレームは、ヘッダ（メディアアクセスヘッダ用ＭＡＣヘッダと呼ばれる）、フレーム本体（より高度なプロトコル層のヘッダとパケットの有用データとを伝達する可変長の）、エラー検出を可能にするチェックフィールド（フレームシーケンスチェック用ＦＣＳと呼ばれる）を有する。

より正確には、ヘッダは特に以下のフィールドに従って分割される。
・以下のように分割される２バイトのフレーム制御フィールド（フレーム制御用ＦＣと呼ばれる）。

ここでは、特に、そのフィールドが管理タイプ（関連付け要求とアクセス点通知メッセージに対応する）と、コントロールタイプ（トラフィックを送信するためにメディアに対するアクセス許可の要求を特定する）と、データタイプ（データフレームに対応する）とを分離できるようにする対象フレームの「タイプ」と「サブタイプ」を示す。サブタイプは様々なタイプの中から対象フレームの正確な性質、すなわち
・リンク層のペイロードを含むフレーム本体、すなわち完全なＩＰパケット（圧縮または非圧縮ヘッダ、ソースデータ）と、
・関係するデータブロックの完全性のチェックによりエラーを検知できるようにするチェックサム（巡回冗長検査ＣＲＣとも呼ばれる）フィールドと、
を識別できるようにする。

本発明によるＲＣＨ解決策は、誤り訂正符号を圧縮ＩＰヘッダに導入することと、その有用データが破損しているかもしれないパケットをパスさせることに対応する。したがって、チェックサムフィールドの範囲を減らすことと、ヘッダだけに関係付けて従来行われているようにヘッダとフレームの本体にもはや関係させないこととが必要である。

ＲＣＨストリーム（そして任意選択的にＲＯＨＣストリーム）を予約値の中から特定するための新しいサブタイプの例示的な定義は次の表３に与えられる。

本発明によるＲＣＨ保護の例で使用する値は、モード１に対しては１００１、モード２に対しては１０１０、モード３に対しては１０１１である。

例示として、ＲＣＨデータフレームを伝達するための以下の３つの場合を提案することができる。
・最も単純な「モード１」は、ＲＣＨパラメータは送信者と受信者に知られていると想定されるので、例えばＲＣＨパラメータがフレームにより提供されないアプリケーションの機能として完全に事前定義されるタイプに対応する。この場合、フレームチェックフィールドは規格に対して不変である。チェックサムフィールドの範囲だけはヘッダだけ（対象とする例では３０バイト）に関係するように修正されなければならない。
・「モード２」は、ＲＣＨ情報を、データストリームを特定するために使用される値に導入できるようにする。したがって、この情報は、もはや事前定義されず、例えばリンクの状態に応じて時間とともに変化するか、あるいは新しい送信毎に送信者により単純に再定義されてよい。したがって、このモードでは、ＲＣＨ保護のための対象符号の識別子と圧縮された初期ヘッダのサイズに関する情報とに専用に１バイトまたは２バイトだけフィールドＦＣを拡張することを提案する。実際上、対象の符号指標は、送信者と受信者に知られた所定の表を参照しかつ誤り訂正符号化および復号化操作に必要な情報（符号タイプ、生成多項式、速度など）を含む２〜８ビットで与えられる。圧縮された初期ヘッダのサイズｌに関する情報は６〜８ビットで符号化され、実際上送信される値は、そのサイズ自身か、あるいは単純な規則によりそのサイズから推測される。したがって、ＲＴＰ／ＵＤＰ（−Ｌｉｔｅ）／ＩＰｖ６ヘッダ圧縮の場合には、ＲＯＨＣ圧縮ヘッダのサイズは長さｌ＝６５バイトを達成することができ、これにより６ビットだけでｌ−１を符号化できるようにする。その結果の新しいフィールドＦＣを以下に例示する。この場合、チェックサムフィールドの範囲は新しいヘッダ（考察例のこの場合は、サイズ３１または３２バイト）においてだけ再度修正される。

・「モード３」もまたＲＣＨ情報の導入を可能にするという意味でモード２に似ているが、この場合、ＲＣＨ情報は対象符号に限定され、保護が適用された圧縮ヘッダの長さに関する情報アイテムが圧縮ヘッダ自体から推定される。実際上、これはＲＣＨヘッダの復号化を以下の２つの工程、すなわち
・ＲＣＨヘッダの最初の部分を復号化することにより、初期の圧縮ヘッダのサイズに関する情報を抽出し、したがって適用された符号に応じてヘッダのサイズを推定できるようにする第１の工程と、
・先に判断されたヘッダのサイズに関する情報に基づいてＲＣＨヘッダの残り部分を復号化する第２の工程と、で行うことを想定する。誤った情報（第１の復号化工程で失敗した場合の）を考慮しないようにするために、復号化により推定されたヘッダのサイズに関する情報を制限するための最大値を定義することができる。

本提案の拡張は一例として与えられたが、本メカニズムは、対象符号とヘッダ長とで異なる配分の拡張ビットを選んだ場合でも変わらない。

図３と図４には、本発明による方法を適用することで得られた利得を例示する。本試験はＨ．２６４／ＡＶＣ映像送信の枠組み内で実行され、同規格のＪＭ１０．１基準ソフトウェア［３］のクラッシュに対してロバストにされた符号器のバージョンを使用した。実際上、採用されたのは、マルチスライスモード（すなわち、各画像を１９２バイトのＮＡＬ（ネットワーク抽象化層：Ｎｅｔｗｏｒｋ Ａｂｓｔｒａｃｔｉｏｎ Ｌａｙｅｒ）パケット最大サイズと１５の画像（Ｉ_１Ｐ_１４）のグループでいくつかのスライスすなわちサブイメージにチョッピングし得るモード）のＱｃｉｆ（１５Ｈｚ形式）で使用されるＩＴＵ−Ｔの「Ｆｏｒｅｍａｎ」基準系列である。送信元符号器のエラーに対する感度の高さを緩和するために、これらのソースデータは、［２］で定義されたレート１／３の母符号とメモリ６とにより畳み込みエラー訂正符号（レート互換パンクチャード畳み込み符号：ＲＣＰＣ（ｃｏｍｐａｔｉｂｌｅ−ｒａｔｅ ｐｕｎｃｔｕｒｅｄ ｃｏｎｖｏｌｕｔｉｏｎａｌ ｃｏｄｅ））を適用することによりアプリケーションレベルで保護された。第１の場合において３２８ｋｂｐそして第２の場合において２１０ｋｂｐの同一チャネル上で送信されるスループットを得るために、ＲＯＨＣモードにおける１６４ｋｂｐとＲＣＨモードにおける１５５ｋｂｐの訂正符号のないスループットに対応する２つの場合を提示する。符号化された各ＮＡＬはその後、ＩＥＴＦ ＲＦＣ ３９８４勧告によるＲＴＰ（リアルタイムトランスポートプロトコル：Ｒｅａｌ Ｔｉｍｅ ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）フレーム内で別々にカプセル化され、次に、従来のＲＯＨＣ圧縮モジュールかまたは本発明による圧縮と保護のためのＲＣＨモジュールのいずれかへ送る前に、ＵＤＰ−Ｌｉｔｅ／ＩＰｖ６標準プロトコルスタックへ送信される。これら両方の場合、採用したＲＯＨＣ圧縮パラメータは、Ｌ＝２，ＦＯ＿ＴＩＭＥＯＵＴ＝５０，ＩＲ＿ＴＩＭＥＯＵＴ＝１０００である。上記符号器ＲＣＰＣを採用する一方で、１／３の母レートで使用される「モード１」ではＲＣＨモードを採用した。データはその後、ガウス性白色雑音（その信号対雑音比Ｅ_ｂ／Ｎ_０は提示された曲線の横座標である）の追加により模擬された擬無線リンク上で送信された。

図５には、アプリケーション、セッション、トランスポート、ネットワーク、リンク、および物理層を介した無線ネットワーク上のマルチメディアデータの送信の典型的な工程を表す。

図５の左側部分では、ソース符号化を含むアプリケーション１０がカプセル化工程１１にデータを送信する。カプセル化されたデータはその後、トランスポート層１２によりネットワーク層１３へ送信される。ネットワーク層は、前の図に関連して説明した方法に従ってデータをＲＣＨ圧縮工程１４へ送信する。圧縮ヘッダを有するデータはリンク層と物理層を含む無線アクセス層１５へ送信される。後者の無線アクセス層は圧縮ヘッダを有するデータを受信者（図の右側部分）へ送信する。この受信者はその無線アクセス層１６のレベルでデータを受信し、次に本発明によるヘッダ復元工程１７へこれらデータを送信する。復元されたヘッダデータはその後、ＩＰネットワーク層１８へ、そして次にトランスポート層１９へ送信される。データはその後、アプリケーション層２１へ送信される前に非カプセル化される（工程２０）。

本発明は、特に、無線ネットワーク上での送信の前のヘッダタイプのパケットの送信を改善できるようにする。

本発明は、ヘッダのレベル、ＲＣＨ情報の挿入、チェックサムの修正以外に、採用される無線アクセス解決策の修正を必要としない。このことは規格の点では認可され得るものであり、使用されるスループットの点では再送信より安上がりである。

リンクヘッダ内に挿入されることにより本解決策は明確に特定される。これは、本発明を実装しない受信者が、誤ったデータを上位レイヤへアップロードすることなく本解決策を採用するフレームを検知できるようにし、それを重要でないものとして拒絶できるようにする。

チェックサムをもっぱらリンクヘッダに関係付けるためにチェックサムの範囲を修正することにより、誤ったペイロードのフレームの損失が回避されるとともに、リンクヘッダが正しいこと（そのチェックサムにより検証される）とネットワークパケットのヘッダが保護される（エラー訂正符号と任意選択的にヘッダ圧縮メカニズムのチェックサムとにより）こととを確実にする。

したがって、これはパケット全体のＡＲＱまたはＦＥＣに対する系統的な依存を回避してスループットを高める。本解決策は一方向と双方向リンクに適用することができる。

参考文献
［１］ Ｍ． Ｇａｓｔ， ８０２．１１ ｗｉｒｅｌｅｓｓ ｎｅｔｗｏｒｋｓ， ｔｈｅ ｄｅｆｉｎｉｔｉｖｅ ｇｕｉｄｅ． Ｅｄ． Ｏ’Ｒｅｉｌｌｙ．
［２］ Ｊ． Ｈａｇｅｎａｕｅｒ， "Ｒａｔｅ−ｃｏｍｐａｔｉｂｌｅ ｐｕｎｃｔｕｒｅｄ ｃｏｎｖｏｌｕｔｉｏｎａｌ ｃｏｄｅｓ ａｎｄ ｔｈｅｉｒ ａｐｐｌｉｃａｔｉｏｎ，" ｉｎ ＩＥＥＥ Ｔｒａｎｓ． Ｏｎ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ， ｖｏｌ． ３６， ｎ．４， ｐｐ． ３８９−４００， Ａｐｒｉｌ １９８８．
［３］ Ｊｏｉｎｔ ｖｅｒｉｆｉｃａｔｉｏｎ ｍｏｄｅｌ ｆｏｒ Ｈ．２６４ （ＪＭ １０．１）， ｔｔｐ：／／ｉｐｈｏｍｅ．ｈｈｉ．ｄｅ／ｓｕｅｈｒｉｎｇ／ｔｍｌ， Ｊｕｌｙ ２００６．

Claims (7)

1. データが少なくとも１つの圧縮ヘッダフィールドと１つのデータフィールドを含むパケットの形式でかつ伝送システムに適した形式に従って送信される、伝送システムにおいてデータを送信するための方法であって、少なくとも、
   −圧縮ヘッダと有用データを含む送信対象のデータパケットを再生し、有用データ部からヘッダ部を特定する工程と、
   −使用する保護モードで通信中にも、ヘッダレベルで選択された訂正符号を適用し、その結果の新しいパケットをリンク層に提供する工程と、
   −使用する保護モードを組み込んだ当該伝送システムの伝送形式とリンク層のＣＲＣチェックサムの適合度とに従ってリンクヘッダを生成する工程と、
   −受信すると、次の２つの工程、すなわち、
   ・ＲＣＨ圧縮ヘッダの最初の部分を復号化して初期の圧縮ヘッダのサイズに関する情報を推定できるようにする第１の工程と、
   ・先に判断されたサイズ情報に基づいてヘッダの残り部分を復号化する第２の工程と、でエラー訂正符号化を実行する工程と、
   を含むことを特徴とする方法。
2. データが少なくとも１つの圧縮ヘッダフィールドと１つのデータフィールドを含むパケットの形式でかつ伝送システムに適した形式に従って送信される、伝送システムにおいてデータを送信するための方法であって、少なくとも、
   −圧縮ヘッダと有用データを含む送信対象のデータパケットを再生し、有用データ部からヘッダ部を特定する工程と、
   −使用する保護モードで通信中にも、ヘッダレベルで選択された訂正符号を適用し、その結果の新しいパケットをリンク層に提供する工程と、
   −そのバイト数がＲＣＨ保護の対象の符号の識別子と圧縮された初期ヘッダのサイズに関する情報とに専用に１または複数バイトだけ拡張されるフレームチェックフィールドのレベルで、エラー訂正符号のパラメータをフレームに導入する工程と、
   −使用する保護モードを組み込んだ当該伝送システムの伝送形式とリンク層のＣＲＣチェックサムの適合度とに従ってリンクヘッダを生成する工程と、を含むことを特徴とする方法。
3. データの送信はＩＥＥＥ８０２．１１規格を使用し、誤り訂正符号は圧縮したＩＰヘッダに導入されることを特徴とする請求項１に記載の方法。
4. 誤り訂正符号のパラメータは送信者と受信者に知られていると想定され、パラメータはデータフレームの外にある処理により提供されることを特徴とする請求項１、２または３のいずれか一項に記載の方法。
5. 送信対象のデータはマルチメディアデータであることを特徴とする請求項１〜４のいずれか一項に記載の方法。
6. システムはＨ．２６４映像伝送システムであることを特徴とする請求項１〜５のいずれか一項に記載の方法。
7. 送信機と復号器受信機を含むデータ送信システムであって、前記送信機は、少なくとも請求項１〜６のいずれか一項に記載の方法の工程を実行するための手段を含むことを特徴とするシステム。

Images