(57)【要約】  本発明は、複数のネットワークプロトコルスタックを有するネットワークを介しアプリケーションデータユニットをターゲットアプリケーションに送信する送信システムに関する。このような送信システムは、通常ストリームの処理に影響を与えることなく、第１ネットワークプロトコルスタックのレイヤから第２ネットワークプロトコルスタックのレイヤに付加情報を送信するための解法を提供する。このため、本送信装置はさらに、少なくとも第１及び第２ネットワークプロトコルスタックを介し前記第２ネットワークプロトコルスタックのレイヤに送信される付加情報を前記第１ネットワークプロトコルスタックのレイヤで生成する生成手段と、前記付加情報をネットワークプロトコル規則に従う少なくとも１つの付加データユニットに変換する調整手段と、前記付加データユニットをマーク処理するマーク手段と、前記付加データユニットが前記第２ネットワークプロトコルスタックのレイヤに到達すると、前記付加データユニット内の前記付加情報を抽出する抽出手段とを有する。より一般には、本発明は、送信システム内のネットワークプロトコルスタックのレイヤ間での付加情報のすべての可能な交換を扱う。本送信システムはまた、いくつかのルータを含んでもよい。
2005512462.tif 000002
【特許請求の範囲】
【請求項１】
複数のネットワークプロトコルスタックを有するネットワークを介しターゲットアプリケーションにソースアプリケーションデータユニットを送信する送信システムであって、
少なくとも第１及び第２ネットワークプロトコルスタックを介し前記第２ネットワークプロトコルスタックのレイヤに送信される付加情報を前記第１ネットワークプロトコルスタックのレイヤに生成する生成手段と、
前記付加情報をネットワークプロトコル規則に従う少なくとも１つの付加データユニットに変換する調整手段と、
前記付加データユニットをマーク処理するマーク手段と、
前記付加データユニットが前記第２ネットワークプロトコルスタックの前記レイヤに到達すると、前記付加データユニット内の前記付加情報を抽出する抽出手段とを有することを特徴とする送信システム。
【請求項２】
請求項１記載の送信システムであって、さらに、
ソースアプリケーションデータユニットに関する特定化情報を収集する収集手段を有し、前記特定化情報は、前記ソースアプリケーションデータユニットに関する付加情報の少なくとも１つの付加データユニットへの変換時に、前記調整手段により利用されることを特徴とする送信システム。
【請求項３】
請求項１記載の送信システムであって、前記第２ネットワークプロトコルスタックのレイヤは、ソースアプリケーションデータユニットに関する確認メッセージを他のネットワークプロトコルスタックに送り返す確認手段を有し、
該送信システムは、さらに、
前記付加データユニットに対して前記確認手段のアクティブ状態を解除するアクティブ解除手段を有する。
【請求項４】
請求項２記載の送信システムであって、前記付加情報はソースアプリケーションデータユニットになされたハード決定に関するソフト情報であり、
該送信システムは、さらに、
前記付加情報を供給するチャンネルデコーダを有し、
前記調整手段は、さらに、
前記付加情報からより短い付加情報を供給する数量化サブ手段と、
前記より短い付加情報において有用情報と制御情報を識別する識別サブ手段と、
前記有用情報を有用フィールドに構成する構成サブ手段と、
前記制御情報を利用することにより、前記有用フィールドをネットワークプロトコル規則に従う少なくとも１つの付加データユニットにカプセル化するカプセル化サブ手段とを有し、
前記抽出手段は、さらに、
前記有用フィールドから前記付加情報を復元する逆数量化サブ手段を有することを特徴とする送信システム。
【請求項５】
複数のネットワークプロトコルスタックを有するネットワークを介しターゲットアプリケーションにソースアプリケーションデータユニットを送信する方法であって、
少なくとも第１及び第２ネットワークプロトコルスタックを介し前記第２ネットワークプロトコルスタックのレイヤに送信される付加情報を前記第１ネットワークプロトコルスタックのレイヤに生成するステップと、
前記付加情報をネットワークプロトコル規則に従う少なくとも１つの付加データユニットに変換するステップと、
前記付加データユニットをマーク処理するステップと、
前記付加データユニットが前記第２ネットワークプロトコルスタックの前記レイヤに到達すると、前記付加データユニット内の前記付加情報を抽出するステップとを有することを特徴とする方法。
【請求項６】
請求項５記載の方法であって、さらに、
ソースアプリケーションデータユニットに関する特定化情報を収集するステップを有し、前記特定化情報は、前記ソースアプリケーションデータユニットに関する付加情報の少なくとも１つの付加データユニットへの変換時に、前記調整ステップにおいて利用されることを特徴とする方法。
【請求項７】
ターゲットネットワークプロトコルスタックとターゲットアプリケーションとを有し、他のネットワークプロトコルスタックを有するネットワークを介し前記ターゲットアプリケーションに送信されるソースアプリケーションデータユニットを処理する受信機であって、該受信機は、さらに、
前記他のネットワークプロトコルスタックのレイヤにより生成され、少なくとも前記他のネットワークプロトコルスタックと前記ターゲットネットワークプロトコルスタックを介し前記ターゲットネットワークプロトコルスタックのレイヤに送信される付加情報を抽出する抽出手段を有することを特徴とする受信機。
【請求項８】
ターゲットネットワークプロトコルスタックとターゲットアプリケーションとを有し、ネットワークを介し前記ターゲットアプリケーションに送信されるソースアプリケーションデータユニットを処理する受信機であって、該受信機は、さらに、
前記ターゲットネットワークプロトコルスタックを介し前記ターゲットネットワークプロトコルスタックのレイヤに送信される付加情報を前記ターゲットネットワークプロトコルスタックのレイヤに生成する生成手段と、
前記付加情報をネットワークプロトコル規則に従う少なくとも１つの付加データユニットに変換する調整手段と、
前記付加データユニットをマーク処理するマーク手段と、
前記付加データユニットが前記ターゲットネットワークプロトコルスタックの前記レイヤに到達すると、前記付加データユニット内の前記付加情報を抽出する抽出手段とを有することを特徴とする受信機。
【請求項９】
請求項８記載の受信機であって、さらに、
ソースアプリケーションデータユニットに関する特定化情報を収集する収集手段を有し、前記特定化情報は、前記ソースアプリケーションデータユニットに関する付加情報の少なくとも１つの付加データユニットへの変換時に、前記調整手段により利用されることを特徴とする受信機。
【請求項１０】
請求項９記載の受信機であって、前記付加情報はソースアプリケーションデータユニットになされたハード決定に関するソフト情報を有し、
該受信機は、さらに、
前記付加情報を供給するチャンネルデコーダを有し、
前記調整手段は、さらに、
前記付加情報からより短い付加情報を供給する数量化サブ手段と、
前記より短い付加情報において有用情報と制御情報を識別する識別サブ手段と、
前記有用情報を有用フィールドに構成する構成サブ手段と、
前記制御情報を利用することにより、前記有用フィールドをネットワークプロトコル規則に従う少なくとも１つの付加データユニットにカプセル化するカプセル化サブ手段とを有し、
前記抽出手段は、さらに、
前記有用フィールドから前記付加情報を復元する逆数量化サブ手段を有することを特徴とする受信機。
【請求項１１】
ソースネットワークプロトコルスタックとソースアプリケーションとを有し、ネットワークを介しターゲットアプリケーションにソースアプリケーションデータユニットを送信する送信機であって、該送信機は、さらに、
前記ソースネットワークプロトコルスタックと他のネットワークプロトコルスタックを介し、前記他のネットワークプロトコルスタックのレイヤに前記ネットワークを介し送信される付加情報を前記ソースネットワークプロトコルスタックのレイヤに生成する生成手段と、
前記付加情報をネットワークプロトコル規則に従う少なくとも１つの付加データユニットに変換する調整手段と、
前記付加データユニットをマーク処理するマーク手段とを有することを特徴とする送信機。
【請求項１２】
ソースネットワークプロトコルスタックとソースアプリケーションとを有し、ネットワークを介しソースアプリケーションデータユニットを送信する送信機であって、該送信機は、さらに、
前記ソースネットワークプロトコルのレイヤに送信される付加情報を前記ソースネットワークプロトコルスタックの他のレイヤに生成する生成手段と、
前記付加情報をネットワークプロトコル規則に従う少なくとも１つの付加データユニットに変換する調整手段と、
前記付加データユニットをマーク処理するマーク手段と、
前記付加データユニットが前記他のレイヤに到達すると、前記付加データユニット内の前記付加情報を抽出する抽出手段とを有することを特徴とする送信機。
【請求項１３】
請求項５または６記載の方法を実現するインストラクションセットを有するプログラムであって、該プログラムはプロセッサにより実行されることを特徴とするプログラム。
【発明の詳細な説明】
【発明の詳細な説明】
【０００１】
[発明の技術分野]
本発明は、複数のネットワークプロトコルスタックから構成されるネットワークを介しソースアプリケーションデータユニットをターゲットアプリケーションに送信するための送信システムに関する。
【０００２】
本発明はまた、そのような送信システムでの利用のためのデータユニット送信方法に関する。
【０００３】
本発明はまた、ターゲットネットワークプロトコルスタックと、ネットワークを介し送信されたソースアプリケーションデータユニットを処理するターゲットアプリケーションとを有する受信機に関する。
【０００４】
本発明はまた、ソースアプリケーションと、ネットワークを介し送信されるソースアプリケーションデータユニットを処理するソースネットワークプロトコルスタックとを有する送信機に関する。
【０００５】
本発明はさらに、そのような方法を実現するためのプログラムに関する。
【０００６】
本発明は、無線ネットワークのような帯域が制限され、エラーが発生しやすいネットワークを介したマルチメディアコンテンツの送信に関するアプリケーションに特に有益である。
[発明の背景]
デジタル通信の領域では、アプリケーションはネットワークにより接続される。通常利用されるネットワークアーキテクチャは、Ｄｕｎｏｄにより編集された「Ｐｒｅｎｔｉｃｅ  Ｈａｌｌ」コレクションにおけるＡｎｄｒｅｗ  Ｔａｎｅｎｂａｕｍにより書かれた「コンピュータネットワーク」という本の１４〜２１ページに説明される７階層のISO参照モデルである。このモデルによると、ネットワークはプロトコルにより規定されるレイヤにより構成される。ネットワーク管理のすべての処理は、アプリケーションと送信チャンネルとの間のインタフェースの役割を担うネットワークプロトコルスタックにより実行される。ネットワークプロトコルスタックは、送信チャンネルの両側に配備される。
【０００７】
物理層と呼ばれる第１レイヤは、データの物理的送信を扱う送信チャンネルを有する。上位のレイヤは、ルーティング、アドレッシング、誤りチェックなどのデータ送信に関する処理を扱うためのネットワークプロトコルの適用を行っている。アプリケーションレイヤと呼ばれる最後のレイヤは、ネットワークへのユーザインタフェースを管理し、ターゲットアプリケーションの要求に関与する。
【０００８】
図１に示される送信システムの従来スキームでは、ソースアプリケーションＳＡＰＰはソースネットワークプロトコルスタックＳＳＴＫを有する送信機ＴＲＡＮＳに含まれ、ターゲットアプリケーションＤＡＰＰはターゲットネットワークプロトコルスタックＤＳＴＫを有する受信機ＲＥＣに属する。ＯＳＩ参照モデルにより定義されるように、ソースネットワークプロトコルスタックＳＳＴＫとターゲットネットワークプロトコルスタックＤＳＴＫはそれぞれ７つのレイヤＬｉ（１≦ｉ≦７）から構成される。
Ｌ１：物理層
Ｌ２：データリンク層
Ｌ３：ネットワーク層
Ｌ４：トランスポート層
Ｌ５：セッション層
Ｌ６：プレゼンテーション層
Ｌ７：アプリケーション層
入力データはまず、ソースアプリケーション情報ＳＡＩを供給するソースアプリケーションＳＡＰＰにより処理される。その後、このソースアプリケーション情報はソースネットワークプロトコルスタックＳＳＴＫにより送信されるソースアプリケーションデータユニットＴＳＡＤＵに変換され、ネットワークを介し受信機ＲＥＣに送信される。受信されたソースアプリケーションデータユニットＲＳＡＤＵは、ターゲットネットワークプロトコルスタックＤＳＴＫにより受信され、受信されたソースアプリケーション情報ＲＳＡＩが受信されたソースアプリケーションデータユニットＲＳＡＤＵから抽出される。この受信されたソースアプリケーション情報ＲＳＡＩは、最終的にはターゲットアプリケーションＤＡＰＰにより処理され、出力データＯＤが出力される。
【０００９】
結果として、ネットワークを介し送信するためには、情報はネットワークプロトコルに準拠していなければならない。
[発明の概要]
本発明の課題は、送信システムの第１ネットワークプロトコルスタックのレイヤから第２ネットワークプロトコルスタックのレイヤに付加情報を通常のストリームの処理を妨害することなく送信するための解決法を提供することにある。
【００１０】
本発明による導入部で説明されたような送信システムは、さらに、少なくとも第１及び第２ネットワークプロトコルスタックを介し第２ネットワークプロトコルスタックのレイヤに送信される付加情報を第１ネットワークプロトコルスタックのレイヤにおいて生成する生成手段と、この付加情報をネットワークプロトコルルールに従う少なくとも１つの付加データユニットに変換する調整手段と、この付加データユニットをマークするマーク手段と、付加データユニットが第２ネットワークプロトコルスタックのレイヤに到達すると、付加データユニット内の付加情報を抽出する抽出手段とを有することを特徴とする。
【００１１】
本発明は、送信システム内のネットワークプロトコルスタックのレイヤ間におけるすべての可能な情報交換を処理する。この情報は、ソースアプリケーションからターゲットアプリケーションに送信される通常のデータストリームに追加して送信される。それは、第１ネットワークプロトコルスタックの第１レイヤにより生成され、この第１ネットワークプロトコルスタックと同一のものであってよいだい２ネットワークプロトコルスタックの第２レイヤにアドレス指定される。このため、この情報は付加情報と呼ばれる。付加情報は、例えば、物理層により受信機側で出力されるチャンネル状態情報であり、ターゲットアプリケーションに有益なものである。ある付加情報は、例えば、それが通常のストリームのデータセットの重要性のレベルに関するものである場合、アプリケーションから物理層に送信機内において交換されてもよい。この種の情報は、チャンネルエンコーダがどの保護レベルがデータセットに適用されるべきかを決定するのに役に立つかもしれない。
【００１２】
付加情報はまた受信機から送信機に、その反対に送信機から受信機に送られてもよい。例えば、受信機の物理層において利用可能なチャンネル状態情報はまた、特にソース情報がスケーラブルなデータストリームを出力する場合、ソースアプリケーションにとって有益であるかもしれない。実際、チャンネル状態が高いエラーレートにより不調である場合、ソースアプリケーションは基本データストリームのみを受信機に送信することを決めるかもしれない。逆に、チャンネル状態が流動性の高いトラフィックにより良好である場合、ソースアプリケーションは基本及び拡張両方のデータストリームを供給するかもしれない。
【００１３】
ここで、ネットワークはルータにより分離された複数の送信チャンネルから構成されてもよい。ルータは送信チャンネルを開始新しい送信チャンネルに送信されるデータユニットをリダイレクトするためのネットワークプロトコルスタックである。ルータは受信側のターゲットアプリケーションに送信される付加情報を提供するレイヤから構成される。
【００１４】
本発明の一実施例では、付加情報がソースアプリケーションデータユニットと関連付けされている場合、送信システムはさらに、このソースアプリケーションデータユニットに関連付けされている付加情報を付加データユニットに変換するときに調整手段により利用されるソースアプリケーションデータユニットに関する情報を収集する収集手段を有する。これは、付加データユニット内でコピーされるとき、それらがソースアプリケーションデータユニットに関するものであるということを示す当該ソースアプリケーションデータユニット内の情報を収集するためである。例えば、これは、ソースアプリケーションデータユニットがターゲットアプリケーションにより受信された時点におけるエラーレートを示すチャンネル状態情報に関する場合である。チャンネル状態情報はソースアプリケーションデータユニットと関連付けされる必要がある。収集手段はこの付加データユニットにソースアプリケーションデータユニットと等しいシーケンス番号を与えることが効果的である。
【００１５】
本発明の他の実施例では、ターゲットネットワークプロトコルスタックのレイヤが、例えば、送信機側の他のネットワークプロトコルスタックの対応するレイヤにソースアプリケーションデータユニットについての確認メッセージを送信する確認手段を有する場合、送信システムはまた当該付加データユニットに対する確認手段のアクティブ状態を解除するアクティブ状態解除手段を提供する。本発明の１つの効果は、通常のストリームに対するターゲットネットワークプロトコルスタックの動作方法が、特にＱｏＳ（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ）に関して付加データユニットの送信により影響を受けないということである。基本的に、これは、送信機により無視されるデータユニットについて受信した確認メッセージによるネットワークエラーを回避するためである。
【００１６】
マーク手段は付加データユニットに特定のターゲットポート番号を与えることが効果的である。
【００１７】
本発明の好適な実施例では、付加情報は、受信機のターゲットネットワークプロトコルスタックの物理層において受信されたソースアプリケーションデータユニットに対するハード決定に関するソフト情報である。このソフト情報は、例えば、ソースデコーダのようなターゲットアプリケーションにアドレス指定される。このため、送信システムはさらに、付加情報を供給するチャンネルデコーダを有し、調整手段はさらに、当該付加情報からより短い付加情報を供給する数量化サブ手段と、当該より短い付加情報の有用情報と制御情報を識別する識別サブ手段と、この有用情報を有用フィールドに構成する構成サブ手段と、この制御情報を利用することによりネットワークプロトコルスタックに従う付加データユニットへの有用フィールドのカプセル化を行うカプセル化サブ手段とを有する。
【００１８】
抽出手段はさらに、有用フィールドから付加情報を復元するターゲット逆数量化サブ手段を有する。
【００１９】
もちろん送信手段は、この付加情報が受信したソースアプリケーションデータユニットから直接導き出されるため、収集手段を有する。
【００２０】
本発明のこの好適な実施例では、パフォーマンス向上を可能にするということが証明されているため、ソフト情報をターゲットアプリケーションに送信することに大きな関心がある。
【００２１】
本発明の追加的な課題、特徴及び効果は、以下の詳細な説明を読み、図面を参照することにより明らかとなるであろう。
[発明の詳細な説明]
本発明は、複数のネットワークプロトコルスタックを有するネットワークを介しターゲットアプリケーションにソースアプリケーションデータユニットを送信する送信システムに関する。
【００２２】
そのような送信システムは、第１ネットワークプロトコルスタックの任意のレイヤから第２ターゲットネットワークプロトコルスタックの他の任意のレイヤへの付加情報の送信を可能にする。図２において、送信機ＴＲＡＮＳ、ネットワークＮＥＴ及び受信機ＲＥＣから構成される従来の送信システムが示される。送信機ＴＲＡＮＳは、ソースアプリケーションＳＡＰＰとソースネットワークプロトコルスタックＳＳＴＫを有し、受信機ＲＥＣは、ターゲットネットワークプロトコルスタックＤＳＴＫとターゲットアプリケーションＤＡＰＰを有する。送信機と受信機はネットワークＮＥＴにより接続される。５つの付加情報の例（Ｉｉ）が与えられる。
【００２３】
付加情報Ｉ１は、ターゲットネットワークプロトコルスタックの物理層からアプリケーション層に送信される。それは、ターゲットアプリケーションがソースアプリケーションデータユニットの処理により適切な決定を行うためのソースアプリケーションデータユニットに関するチャンネル状態情報でありうる。
【００２４】
付加情報Ｉ２は、ターゲットネットワークプロトコルスタックのアプリケーション層により物理層に送信される。それは、物理層のチャンネルデコーダがソフト復号化の開始または中止することを要求する制御指示でありうる。
【００２５】
付加情報Ｉ３は、ソースネットワークプロトコルスタックの物理層からアプリケーション層に送信される。それは、例えば、ソースアプリケーションが入力データに要される符号化方法についての決定に利用されるかもしれないチャンネル状態情報であるかもしれない。
【００２６】
付加情報Ｉ４は、ターゲットネットワークプロトコルスタックの物理層によりソースネットワークプロトコルスタックのアプリケーション層に送信される。それは、スケーラブル符号化アプローチの場合において、ソースアプリケーションが基本データストリームのみ、あるいは基本及び拡張の両方のストリームを送信するか決定するのに利用されるかもしれないある時点において測定されたチャンネル状態情報であるかもしれない。
【００２７】
付加情報Ｉ５は、ターゲットネットワークプロトコルスタックのアプリケーション層により物理層に送信される。それは、物理層がソースアプリケーションデータユニットのデータ保護調整レベルを選択するのに利用するソースアプリケーションデータユニットに関する重要レベルであるかもしれない。
【００２８】
図３において、本発明の第１実施例が説明される。それは付加情報Ｉ１を扱っている。送信システムの受信機ＲＥＣは、ターゲットネットワークプロトコルスタックＤＳＴＫと、例えば、ソースデコーダであるターゲットアプリケーションＤＡＰＰを有する。図４ｂに示されるように、ターゲットネットワークプロトコルスタックＤＳＴＫは、当業者には周知のＯＳＩ参照モデルに従って、階層構成される。
【００２９】
ここで、このモデルは唯一のものではないということに注意すべきである。図４ｂに示されるＴＣＰ／ＩＰ参照モデルは、広く利用されるものであるが、４つのレイヤから構成されている。その第１レイヤＬ’１はＬ１とＬ２をグループ化したものであり、Ｌ’２はネットワーク層Ｌ３に対応し、Ｌ’３はトランスポート層Ｌ４に対応し、Ｌ’４はＬ５、Ｌ６及びＬ７をグループ化したものである。
【００３０】
ソースアプリケーションデータユニットＲＳＡＤＵは、ネットワークプロトコルスタックＤＳＴＫの物理層Ｌ１によりネットワークＮＥＴを介し受信される。物理層は、受信したデータソースアプリケーションデータユニットＲＳＡＤＵに対する復調、等化、チャンネル復号化などのいくつかの処理を実現する。それはまた、チャンネルに関する測定ＣＭからチャンネル状態情報ＣＳＩを供給する測定手段ＭＥＡＳのような生成手段を有するかもしれない。
【００３１】
チャンネル状態情報ＣＳＩは、ターゲットネットワークプロトコルスタックの上位レイヤが受信されたソースアプリケーションデータユニットをより良好に処理するための適切な戦略を選択できるよう利用される。このため、このような情報を上位に伝えることに大きな関心がある。チャンネル状態情報ＣＳＩは、ターゲットネットワークプロトコルスタックの物理層により生成される付加情報の一種である。これにより、受信機は、付加情報ＣＳＩをネットワークプロトコルルールに従う付加データユニットに変換する調整手段ＡＤＡＰを有する。図３の例では、調整手段ＡＤＡＰは物理層Ｌ１に属している。これは、付加情報がこの段階で与えられるためである。付加情報が他のレイヤにより与えられたとすると、調整手段はその他のレイヤに属することになるであろう。
【００３２】
調整手段ＡＤＡＰの目的は、チャンネル状態情報ＣＳＩを含み、ターゲットネットワークプロトコルスタックＤＳＴＫに従う付加データユニットＡＤＵを供給することにある。
【００３３】
図４ａに示されるように、ターゲットネットワークプロトコルスタックＤＳＴＫに従ったデータユニットはある構成を有する。この構成は、ペイロード（ｐａｙｌｏａｄ）と呼ばれる有用情報と制御情報である２つのタイプの情報に分割される。有用情報は、この場合、チャンネル状態情報ＣＳＩを送信するための情報である。制御情報は、例えば、ネットワークプロトコルスタックＤＳＴＫにより、データユニットの有効性をチェックするなどのデータユニットの処理に利用されるすべてのデータを集めたものである。実際、制御情報にはヘッダ（ｈｅａｄｅｒ）Ｈｄｉとトレーラ（ｔｒａｉｌｅｒ）Ｔｒｉ（２≦ｉ≦７）という２つのタイプのものがあり、それらは送信機内の対応するレイヤＬｉにより有用情報の始めと終わりにそれぞれ添付される。データユニットがネットワークプロトコルスタックＤＳＴＫを上方にパスすると、これらヘッダ及びトレーラは送信機内で除去される。ここで、物理層Ｌ１以外のすべてのレイヤは関連付けされたヘッダと恐らくトレーラを有する。物理層では、データはビット系列として単にみなされるため、フレームとも呼ばれるデータユニットの記法は意味がない。
【００３４】
従って、調整手段ＡＤＡＰは、次のレイヤにより解釈可能なデータリンクレイヤＬ２である付加データユニットＡＤＵを生成する必要がある。
【００３５】
ここで、図４ａに示されるように、いわゆるペイロードの内容はレイヤにより変化する。すなわち、ターゲットアプリケーションＤＡＰＰに送信される有用情報をＰａとすると、ＰａはレイヤＬ７のペイロードであるが、レイヤＬ６のペイロードＰａ６はさらに、上位レイヤＬ７のヘッダＨｄ７とトレーラＴｒ７を有するなどである。
【００３６】
チャンネル状態情報ＣＳＩに対して準拠した付加データユニットＡＤＵを構築する方法は、以前に受信したソースアプリケーションデータユニットの制御情報、すなわち、それのヘッダとトレーラを有用情報ＣＳＩの始めと終わりにコピーするというものである（例えば、制御情報はメモリに格納される）。ヘッダとトレーラの中で、制御情報は複数のフィールドを含み、その中には、
ネットワーク層Ｌ３に属し、現在データユニットの受信機（例えば、コンピュータ）ターゲットアドレスを定義するＩＰアドレス、
トランスポート層Ｌ４に属し、ＵＤＰペイロードに連結されたＵＤＰヘッダの全長を定義するＵＤＰ長、
トランスポート層Ｌ４に属し、ＵＤＰペイロードに連結されたＵＤＰヘッダのビットの和であるＵＤＰチェック合計、
トランスポート層Ｌ４に属し、ターゲットアプリケーションまたはプロセスを特定するターゲットポート番号、
トランスポート層Ｌ４に属し、データストリーム内のデータユニットの特定及び番号付けを行うＲＴＰシーケンス番号がある。
【００３７】
これらのフィールドのいくつかはペイロードに格納された有用情報の特性に強く依存しているため、付加データユニットＡＤＵに対する再計算の必要がある。例えば、有用情報はもともと受信したデータユニットにおいて同一のものではないため、ＵＤＰ長は再計算される必要がある。これにより、ＵＤＰチェック合計もまた更新される必要がある。
【００３８】
さらに、送信状態はしばしば変動するものであるため、チャンネル状態情報ＣＳＩはある期間においてのみ成り立つ可変な測定値となる。このため、それは時点またはソースアプリケーションデータユニットに関連付けされ、この時点において物理層に到達される。時点の場合、「タイムスタンプ」と呼ばれる追加的フィールドがチャンネル状態情報の有効性を制限するのに利用されてもよい。そのようなフィールドは、所与の正の値から始まり、ゼロとなるまでディクリメントされる。ソースアプリケーションデータユニットの場合、ターゲットレイヤにおいてチャンネル状態情報がソースアプリケーションデータユニットに対して有効であるということを示すためのソースアプリケーションデータユニット内の特定化情報を抽出する必要がある。
【００３９】
このため、本発明による送信システムはさらに、受信したソースアプリケーションデータユニットＲＳＡＤＵについての特定化情報IIを収集する収集手段ＣＯＬＬを有する。この特定化情報は、ソースアプリケーションデータユニットに関する付加情報の付加データユニットＡＤＵへの変換時に、調整手段により利用される。
【００４０】
従って、収集手段は、ソースアプリケーションデータユニットを物理層からアプリケーション層に上方への送信を行うためのネットワークプロトコルスタックＤＳＴＫにより実行されるカプセル解除処理を、特定化情報IIが届けられた時点でそれらが中止されるという事実を別にして、並列に再生する。特定化情報は、例えば、受信したソースアプリケーションデータユニットＲＳＡＤＵのＲＴＰヘッダに格納されているＲＴＰシーケンス番号であってもよい。その後、ＲＴＰシーケンス番号は、付加データユニットＡＤＵにさらに含まれるように、調整手段ＡＤＡＰに供給される。
【００４１】
ここで、第１ネットワークプロトコルスタックのレイヤから第２ネットワークプロトコルスタックのレイヤに送信される付加情報が特定のソースアプリケーションデータユニットに関するものでない場合、収集手段は役に立たず、調整手段が０のようなＲＴＰシーケンス番号に意味のない値を与える。
【００４２】
ヘッダとトレーラの関係するすべてのフィールドが再計算されると、付加データユニットＡＤＵがマーク手段ＭＡＲＫに供給される。マーク手段ＭＡＲＫは、マークされた付加データユニットＭＡＤＵ１を供給することにより、付加データユニットＡＤＵと受信したソースアプリケーションデータユニットＲＳＡＤＵとを区別するためのものである。そのような区別は、例えば、第２レイヤではきわめて有用である。なぜなら、大部分の時間、マークされた付加データユニットＭＡＤＵは、自身されたソースアプリケーションデータユニットＲＳＡＤＵと同様には処理されないためである。
【００４３】
このようなマーク処理は、受信されたソースアプリケーションデータユニットＲＳＡＤＵ（例えば、ターゲットポート番号Ｐ１を有する）のものとは異なるターゲットポート番号Ｐ２を付加データユニットＡＤＵに作用させることにより効果的に実現される。ターゲットポート番号は、ＵＤＰヘッダに属し、トランスポートレイヤＬ４より下位のレイヤによっては考慮されないフィールドである。
【００４４】
ここで、ＦＴＰ（Ｆｉｌｅ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）のような特定の標準的アプリケーションは他のアプリケーションが利用することができない予約されたターゲットポート番号を有する。例えば、ソースデコーダのような他のアプリケーションに対して、すべてのフリーなポート番号が可能であり、同一のアプリケーションに対して複数のターゲットポート番号が可能でさえある。
【００４５】
ターゲットポート番号という解決法はもちろん限定的なものではない。他の選択肢では、付加データユニットＡＤＵに受信したソースアプリケーションデータユニットＲＳＡＤＵと同一のＲＴＰシーケンス番号が与えられるかもしれない。
【００４６】
マークされた付加データユニットＭＡＤＵ１がその後データリンクレイヤＬ２まで送信される。このマークされた付加データユニットＭＡＤＵ１を受信すると、データリンクレイヤＬ２はそれのヘッダＨｄ２とトレーラＴｒ２をチェックして、削除し、マークされた付加データユニットの新たなものＭＡＤＵ２をネットワーク層Ｌ３に送信する。ネットワーク層Ｌ３は、同様のプロセスを実現し、マークされた付加データユニットの対応するものＭＡＤＵ３をトランスポート層Ｌ４に供給する。
【００４７】
マークされた付加データユニットＭＡＤＵ３がトランスポート層Ｌ４のチェックをパスしたと仮定すると、新たなＭＡＤＵ４が上位レイヤに送信される。マークされた付加データユニットのＭＡＤＵ６が付加データユニット内のチャンネル状態情報ＣＳＩのような付加情報を抽出する抽出手段ＲＥＴＲＩＥＶに与えられるまで、上記プロセスは継続される。この抽出手段ＲＥＴＲＩＥＶの他の目的は、この付加情報を正しいターゲットポート番号に導き、必要なら、これに関する受信したソースアプリケーションデータユニットＲＳＡＤＵ６に含まれるソースアプリケーション情報ＳＡＩと一緒にする。その後、付加情報はそれのターゲットアプリケーションＤＡＰＰに到達する。
【００４８】
さらにわかるように、付加情報がアドレス指定されるレイヤに応じて、抽出手段はより複雑な処理を実行するようにしてもよい。
【００４９】
アプリケーションレベルにおいて利用可能なチャンネル状態情報ＣＳＩを有することの効果は価値あるものである。実際、そのような関連情報は戦略的な選択を行うのに利用されるかもしれない。例えば、チャンネル状態に応じて、スケーラブルなデータストリームを受信するソースデコーダは、チャンネルのエラーレートが高い場合には基本ストリームのみを送信するよう送信機に要求するかもしれないし、あるいは送信状態が良好な場合には基本及び拡張ストリームの両方を送信するよう送信機に要求するかもしれない。
【００５０】
先に進む前に、トランスポート層Ｌ４の動作方法がより詳細に検討されねばならない。トランスポート層Ｌ４は、ＴＣＰと呼ばれる１つの信頼性の高いプロトコルにより、あるいは、図４ｂに示されるように、例えばＲＴＰ／ＲＴＣＰのような信頼性の高いプロトコルと接続されたベストエフォートサービスを提供するＵＤＰという２つのプロトコルにより制御される。信頼性の高いプロトコルのすべてに共通な特徴は、受信機側にＱｏＳを提供する確認手段ＡＣＫＮを備えているということである。この確認手段は、いくつの有効なデータユニットを受信したか通知するために、確認メッセージを送信機に送り返すためのものである。使われるプロトコルに応じて、確認メッセージの頻度は可変とされてもよい。例えば、プロトコルＴＣＰは受信した有効データユニットのそれぞれに対して確認メッセージを送信する。これは送信チャンネルに大きな負荷をかけることになる。また、遅延を生じさせることにさえなり、リアルタイムのアプリケーションとは相容れない。ＲＴＰ／ＲＴＣＰプロトコルは、同一のターゲットポート番号で受信された複数のデータユニットに対しては１つの確認メッセージを送信するだけであるため、信頼性とコスト効率性との良好なバランスをとることができる。従って、ＴＣＰプロトコルとＵＤＰ／ＲＴＰ／ＲＴＣＰプロトコルとの選択はアプリケーションに依存することになる。
【００５１】
この確認メッセージにより、送信機はどのデータユニットが受信機により受信されていないか推論でき、データユニットの再送を決定するかもしれない。
【００５２】
受信機側では、確認手段ＡＣＫＮはまた、再送を待機するか、あるいは迅速な再送を直接要求することを決定してもよい。
【００５３】
トランスポート層Ｌ４はまた、マークされた付加データユニットがアドレス指定されているターゲットアプリケーションＤＡＰＰの特定を受け持つ。
【００５４】
受信されたソースアプリケーションデータユニットＳＡＤＵ４に対して、確認手段ＡＣＫＮは送信機に送信される確認メッセージＲＡＭ４を出力する。確認メッセージＲＡＭ４は、確認メッセージＲＡＭ３としてネットワークからデータリンク層に、確認メッセージＲＡＭ２としてデータリンクから物理層に、確認メッセージＲＡＭとして物理層から送信チャンネルに、というように下位のレイヤを介し下方にパスしなければならない。その後、ネットワークＮＥＴの送信チャンネルを介し送信され、送信機ＴＲＡＮＳにより受信される。ここで、ＴＣＰやＲＴＰ／ＲＴＣＰプロトコルによるそのような確認プロセスはシステマティックなものであり、すなわち、トランスポート層を介し上方にパスされるすべてのデータに適用される。
【００５５】
しかしながら、送信機は付加データユニットの存在を偶然無視するかもしれない。例えば、送信機はチャンネル状態情報ＣＳＩを含む付加データユニットＡＤＵの存在を無視する。このため、そのような付加データユニットＡＤＵに対する確認メッセージの受信は、送信機側でのプロトコルエラーを招くかもしれない。
【００５６】
これを回避するため、単純な解決法として、トランスポート層においてＴＣＰやＲＴＰ／ＲＴＣＰプロトコルの代わりにＵＤＰプロトコルを単に利用することにより、受信機側でのすべてのソースアプリケーションデータユニットのＱｏＳを抑制するというものがある。この場合、マーク手段ＭＡＲＫによる第２ポート番号の使用は、すべてのデータユニットがトランスポート層により同様に処理されるため、このレベルにおいては有益ではない。しかしながら、この解決法は全く十分なものではない。なぜなら、第１レイヤから第２レイヤへの付加情報の送信の可能性は、受信されるソースアプリケーションデータユニット全体のＱｏＳを犠牲にして得られるためである。
【００５７】
この問題を解決するため、本発明による送信システムは、さらに、付加データユニットＡＤＵに対して確認手段ＡＣＫＮを抑制するアクティブ解除手段ＤＥＡＣＴを有する。図３において、このアクティブ解除手段は示される。
【００５８】
本発明の第１実施例では、ＵＤＰ／ＲＴＰ／ＲＴＣＰプロトコルが利用されるケースが考えられている。アクティブ解除手段ＤＥＡＣＴは物理層Ｌ１に配備される。それはマーク手段ＭＡＲＫが付加データユニットをマークした方法を利用して、これら付加データユニットを認識し、ＲＴＰ／ＲＴＣＰプロトコルをスキップさせる。これは、単にＲＴＰ／ＲＴＣＰヘッダとトレーラを除去することによりなされる。これにより、受信したソースアプリケーションデータユニットＲＳＡＤＵはＲＴＰ／ＲＴＣＰプロトコルに続くＵＤＰプロトコルにより処理されるのに対し、送信機のトランスポート層から未知のものと考えられている付加データユニットＡＤＵはＵＤＰプロトコルによって処理されるだけである。言い換えると、付加データユニットＡＤＵに対してＱｏＳは破棄されるが、受信したソースアプリケーションデータユニットＲＳＡＤＵに対しては維持される。
【００５９】
他の解決法では、すべてのデータユニットをトランスポート層と同様に処理するというものである。すなわち、ＴＣＰまたはＵＤＰ／ＲＴＰ／ＲＴＣＰプロトコルにすべてのデータユニットに対する確認メッセージを送信させ、特定のターゲットポート番号Ｐ２を有するデータユニットに対応するメッセージを停止するための物理層Ｌ１におけるアクティブ解除手段ＤＥＡＣＴを設定するというものである。これによる効果は、プロトコルにより制御を受けない唯一のレイヤである物理層が修正されるだけで済むということである。
【００６０】
本発明の１つの効果として、選択的なＱｏＳが可能になるというものがある。本発明では、物理層からアプリケーション層への付加情報の送信は、信頼性を犠牲にして得られるものでなく、真の追加的価値をもたらす。
【００６１】
ＲＴＰ／ＲＴＣＰプロトコルが利用される場合、同一のターゲットポート番号、すなわち、Ｐ１またはＰ２を有する複数の有効なデータユニットに対し、確認メッセージが送信機に送り返されるということに注意すべきである。これにより、受信したソースアプリケーションと付加データユニットを併せたものについて、確認メッセージは送信されない。
【００６２】
また、確認手段を有するのはトランスポート層Ｌ４だけではない。例えば、データリンク層Ｌ２のような下位レイヤもまた確認手段を有する。本発明の好適な実施例では、確認手段が毀損したデータユニットの再送を送信機に要求しなうように、確認手段は部分的に抑制される。実際、データユニットのターゲットポート番号はこの段階では確認できず、付加データユニットの特定は不可能である。このため、確認手段は、それが受信したデータユニットをチェックし、恐らく拒絶する。しかしながら、下位レイヤの制御情報を利用して付加データユニットをマークすることにより、これら下位レイヤの選択的なＱｏＳを設定することが可能であるべきである。
【００６３】
最後に、第１レイヤ情報はまた、トランスポート層Ｌ４と同様に物理層Ｌ１より上位のレイヤにとって有益なものであるかもしれない。例えば、チャンネル状態情報ＣＳＩは、ＴＣＰまたはＲＴＰ／ＲＴＣＰプロトコルが毀損したデータユニットに対し採用されるベストな戦略、すなわち、エラーレートが低く、トラフィックの流動性が高い場合、送信機に再送を要求するか、あるいはエラーレートが高いか、あるいはネットワークが混雑している場合、毀損したデータユニットを訂正しようとするか、を選ぶのに利用可能である。
【００６４】
先に進む前に、本発明の確認に関する部分は選択的なものであり、この部分が破棄されても本発明は依然として存在するということを強調したい。
【００６５】
図５において、本発明の第２実施例が説明される。そこでは、チャンネルデコーダＣＤＥＣにより受信したソースアプリケーションデータユニットＲＳＡＤＵについて与えられるハード情報ＨＩ及びソフト情報ＳＩの送信が扱われる。チャンネルデコーダＣＤＥＣは、送信システムの受信機側のターゲットネットワークプロトコルスタックの物理層Ｌ１に属する。ハード情報ＨＩ及びソフト情報ＳＩは、ターゲットネットワークプロトコルスタックＤＳＴＫのアプリケーション層Ｌ７にアドレス指定される。
【００６６】
ここで、前述のように、図５に示されたものとは異なるが、物理層はチャンネルデコーダＣＤＥＣ（または、送信機側におけるチャンネルエンコーダＣＥＮＣ）に制限されるのではなく、ネットワークＮの送信チャンネルとの機械的、機能的及び電気的インタフェースを実現するものであるということに注意すべきである。例えば、物理層は変調（復調）または等化に関する手段を有する。
【００６７】
ネットワークＮＥＴを介し送信される受信したソースアプリケーションデータユニットＲＳＡＤＵの各実数値に対し、チャンネルデコーダＣＤＥＣは、この実数値に関してとられたハード決定である１ハードビットと、このハード決定に関する信頼性尺度を表す複数のソフトビットを生成する。この信頼性尺度は、ターゲットアプリケーションＤＡＰＰが受信したソースアプリケーションデータユニットに関して自ら選択をするのに非常に有益である。チャンネルデコーダは、受信したソースアプリケーションデータユニットＲＳＡＤＵに対しハード及びソフトビットを出力する。ソフトビットは付加情報の形態をとり、ターゲットネットワークプロトコルスタックＤＳＴＫの第１レイヤ（物理レイヤ）から第２レイヤ（アプリケーションレイヤ）に送信されるハードデータユニットに関連付けされている。
【００６８】
本発明の第２実施例では、生成手段はチャンネルデコーダＣＤＥＣにより与えられる。
【００６９】
ソフトビットの送信が可能となるため、本発明による送信システムはさらに、図６ａで説明される調整手段ＡＤＡＰ内に、付加情報ＨＩとＳＩからより短い付加情報Ｂ０を供給する数量化サブ手段ＱＵＡＮＴと、より短い付加情報Ｂ０の有用情報ＵＩと制御情報ＣｏＩを区別する識別サブ手段ＤＩＳＣＲと、有用情報ＵＩを有用フィールドＵＦ（ｊ）（２≦ｊ≦７）に構成する構成サブ手段ＳＴＲＵＣＴと、制御情報ＣｏＩを利用することにより、有用フィールドＵＦ（ｊ）を付加データユニットＡＤＵ（ｊ）にカプセル化するカプセル化サブ手段ＥＮＣＡＰＳとを有し、抽出手段ＲＥＴＲＩＥＶ内に、有用フィールドＵＦ（ｊ）から付加情報ＨＩとＳＩを復元するターゲット逆数量化サブ手段ＤＥＱＵＡＮＴとを有する。
【００７０】
数量化サブ手段ＱＵＡＮＴは、付加情報ＨＩとＳＩからより短い付加情報Ｂ０を供給するためのものである。この処理はいくつかの理由から必要とされる。
【００７１】
第１に、ネットワークＮＥＴを介した送信前、データユニットは、例えば、当業者には周知なＢＰＳＫ変調を利用するチャンネルエンコーダＣＥＮＣにより変調される。取得されるデータユニットは物理的信号によりネットワークＮＥＴを介し送信されるため、この変調処理が必要とされる。
【００７２】
第２に、送信により、受信したソースアプリケーションデータユニットＲＳＡＤＵの各データは、ＢＰＳＫ変調に従うように、正確に−１または１でなくともよい実数値を有する。
【００７３】
第３に、送信チャンネルの出力において、受信したソースアプリケーションデータユニットＲＳＡＤＵの各データは、ほとんど切り捨てることなく当該データのバイナリデータシーケンスを提供するため、多数のビットに数量化される。数量化された受信ソースアプリケーションデータユニットが取得される。この数量化された受信ソースアプリケーションデータユニットの各数量化データは、チャンネルデコーダＣＤＥＣにより数量化確率に変換される。例えば、ＢＰＳＫ変調の場合では、この数量化確率の符号は受信ソースアプリケーションデータユニットＲＳＡＤＵに含まれる数量化データの可能性の高い最終的な値（−１または１）を示し、モジュールは訂正されるべきこの最終的な値の確率を表す。そのようなチャンネルデコーダＣＤＥＣはソフト出力チャンネルデコーダと呼ばれる。ハード出力チャンネルデコーダは、受信したデータユニットの各実数値を最も確率の高い最終的な値により直接取り替える。そのようなハード出力チャンネルデコーダは、送信されたソースアプリケーションデータユニットＴＳＡＤＵと見込みとしては一致するハードチャンネル復号化情報を生成する。このため、送信エラーがないとすると、ハードチャンネル復号化情報は、送信されたソースアプリケーションデータユニットＴＳＡＤＵと一致することになり、これによりネットワークプロトコルスタックＤＳＴＫにより許容される。しかしながら、ソフト出力チャンネルデコーダの場合には、送信された１ビットが１ハードビットと取り替えられるのではなく、例えば、１ハードビットと（Ｎ−１）補完的ソフトビットから構成されるＮソフトビットと置き換えられる。これにより、得られる付加情報は、送信されたソースアプリケーションデータユニットＴＳＡＤＵよりはるかに長いものとなり、ネットワークプロトコルスタックＤＳＴＫにより確実に拒絶される。
【００７４】
従って、図６ａに示すように、付加情報ＨＩとＳＩはチャンネル数量化サブ手段ＱＵＡＮＴにより処理される。例えば、図７に示されるように、Ｎ＝３ビット上の一様な数量化が実行される。数量化のレベル０は、軸ＡＸのセグメント[−１，１]の中間にあるデリミッタ（ｄｅｌｉｍｉｔｅｒ）ｑ０＝０により定義される。その後、ｑ０上の対称性により、他の６つの数量化デリミッタｑ１，ｑ２，…，ｑ６が、軸ＡＸを以下の区間に完全に分割するよう定義される。
【００７５】
【数１】
2005512462.tif 000003
ここで、第１レイヤ情報の受信された実数値に対する可能なビットシーケンスは、それぞれ０１０，０１１，００１，０００，１００，１０１，１１１及び１１０である。数量化デリミッタは、例えば、ｑ１＝０．６６６＝−ｑ４，ｑ２＝１．３３４＝−ｑ５，ｑ３＝２．０＝−ｑ６となりうる。最も重要な数量化ビットは、受信されたソースアプリケーションデータユニットＲＳＡＤＵのデータについてのハードビットまたはチャンネルデコーダＣＤＥＣの決定である。ここで、結合ソースチャンネル復号化が実行されない従来のデコーダでは、閾値検出器は、チャンネルデコーダＣＤＥＣの後ろに置かれ、ハードビットの出力を行っている。数量化サブ手段ＱＵＡＮＴは上記ハードビットを出力するのみであるとき、当該手段がシンプルな閾値検出器の役割を担っている。
【００７６】
その他の（Ｎ−１）の数量化ビットは、ハードビットまたは決定に関する確率を表すソフトビットである。Ｎ数量化ビットは、いわゆるより短い第１レイヤ情報である。
【００７７】
最後に、数量化サブ手段ＱＵＡＮＴは、制御及び有用情報である、第１レイヤ情報のすべての受信データのＮ数量化ビットを含むバッファＢ０に構成されるより短い付加情報を出力する。
【００７８】
図６ａ及び図８に示される識別サブ手段ＤＩＳＣＲは、より短い付加情報Ｂ０の有用情報ＵＩと制御情報ＣｏＩを識別するためのものである。このため、識別サブ手段ＤＩＳＣＲはまず、次の方法によりハードデータユニットＤＵ０を生成する。すなわち、ＤＵ０はより短い第１レイヤ情報Ｂ０のハードビットを含む。ハードデータユニットＤＵ０は、ハード制御情報ＨＣＩ（ヘッダＨｄｉｔｏトレーラＴｒｉ）とハード有用情報ＨＵＩを有する。
【００７９】
その後、識別サブ手段ＤＩＳＣＲは、ネットワークプロトコルスタックと同様にハードデータユニットＤＵ０をカプセル解除する。すなわち、ネットワークプロトコルスタックＤＳＴＫの各レイヤＬｉ（２≦ｉ≦７）に対して、適用可能である場合、以下のアクションが連続的に実行される。すなわち、
ハードデータユニットＤＵ０内の現在レイヤＬｉのヘッダＨｄｉを読み出し、このヘッダＨｄｉとヘッダ長ＨｄＬｉをヘッダ長メモリＨｄＬＢｏｘに格納し、
適用可能である場合、下位レイヤのチェック合計のさらなる再計算を考慮して、ヘッダＨｄｉをチェック合計メモリＣｋｓＢｏｘに格納し（例えば、下位レイヤＬｉ−１に対して、Ｈｄｉは有用情報またはペイロードに属する）、
適用可能である場合、有用情報パディングバイトに関する情報ＰＡＤを抽出し、パディングメモリＰａｄＢｏｘにコピーし、（情報ＰＡＤは、パディングバイトがハードデータユニットＤＵ０の有用情報ＨＵＩの終わりに添付されているか示すものである。）
ハードデータユニットＤＵ０内の現在レイヤＬｉのトレーラＴｒｉを読み出し、トレーラＴｒｉとトレーラ長ＴｒＬｉをトレーラ長メモリＴｒＬＢｏｘに格納し、
適用可能である場合、レイヤＬｉのプロトコルに特有な他の情報を抽出する。
【００８０】
上記アクションａ，ｂ，ｃ，ｄ及びｅの中のいくつかは利用されるプロトコルに依存する。ＵＤＰプロトコルでは、チェック合計ＣｋｓＵＤＰは有用情報またはペイロードＨＵＩと上位レイヤのヘッダに依存する。従って、アクションｂが実行される必要がある。ＲＴＰヘッダの場合、シーケンス番号が抽出される必要がある。ソフト情報がハードデータユニットＤＵ０に関連付けされているため、生成される付加データユニットに同じＲＴＰシーケンス番号が与えられる。従って、アクションｅはレイヤＬ４に対し必須となる。
【００８１】
すべてのヘッダ及びトレーラシーケンスが取り除かれると、識別サブ手段ＤＩＳＣＲは、ヘッダ長メモリＨｄＬＢｏｘに格納されるヘッダ長ＨｄＬｉ（２≦ｉ≦７）とトレーラ長メモリＴｒＬＢｏｘに格納されるトレーラ長ＴｒＬｉ（２≦ｉ≦７）を利用して、トータルヘッダ長ＴＬの計算ができる。より短い付加情報Ｂ０のトータルヘッダ長はハードデータユニットＤＵ０のトータルヘッダ長ＴＨＬのＮ倍であるため、ハードデータユニットＤＵ０のトータルヘッダ長ＴＨＬを知ることにより、より短い付加情報Ｂ０に含まれるより短い有用情報ＵＩの終わりへの配置を可能にする。有用情報ＵＩは識別サブ手段により出力される。ハードデータユニットＤＵ０から抽出されるヘッダＨｄｉとトレーラＴｒｉは、識別サブ手段ＤＩＳＣＲにより出力される制御情報ＨＣＬを構成する。
【００８２】
従って、制御情報のため、ハードビットのみが保持され、（Ｎ−１）補完的ソフトビットは維持されない。
【００８３】
識別サブ手段ＤＩＳＣＲは、ハードデータユニットＤＵ０から抽出される制御情報ＣｏＩと、より短い付加情報Ｂ０に含まれるハード及びソフト有用情報ＵＩを出力する。
【００８４】
その後、有用情報はそれを有用フィールドに構成するための構成サブ手段ＳＴＲＵＣＴにより受信される。
【００８５】
調整手段ＡＤＡＰでは、図６ａ及び図９に示される構成サブ手段ＳＴＲＵＣＴは、有用情報ＵＩを有用フィールドＵＦ（ｊ）（０≦ｊ≦Ｎ−１）に構成するためのものである。Ｎ個のバッファ群ＡＤＵ（ｊ）（０≦ｊ≦Ｎ−１）が生成され、それの各サイズはハードデータユニットＤＵ０のものに等しい。本発明の実施例では、有用情報ＵＩはＮ個の有用フィールドＵＦ（ｊ）（０≦ｊ≦Ｎ−１）に以下の方法により分割される。すなわち、有用情報ＵＩからのビットｊ（ｍｏｄ）Ｎが有用フィールドＵＦ（ｊ）（０≦ｊ≦Ｎ−１）に分類される。
【００８６】
ここで、有用情報は、有用フィールドＵＦ（ｊ）の他の番号Ｌ（０≦ｊ≦Ｌ−１，Ｌ＞ＮまたはＬ＜Ｎ）に分割することもできる。
【００８７】
生成される有用フィールドＵＦｊは、チェック合計メモリＣｋｓＢｏｘにコピーされる。ここで、例えば、ＵＤＰプロトコルの場合、それらは特定レイヤのチェック合計の再計算に有益であるかもしれない。
【００８８】
調整手段ＡＤＡＰにおいて、図６ａ及び図９に示されるカプセル化サブ手段ＥＮＣＡＰＳは、制御情報ＣｏＩを利用することによって、有用フィールドＵＦ（ｊ）（０≦ｊ≦Ｎ−１）をターゲットネットワークプロトコルスタックＤＳＴＫに従う付加データユニットにカプセル化するためのものである。バッファＡＤＵ（ｊ）（０≦ｊ≦Ｎ−１）は、付加データユニットへの変換の必要があり、このため、カプセル化サブ手段ＥＮＣＡＰＳは以下のアクションを連続的に実行する。すなわち、
ヘッダＨｄｉ（２≦ｉ≦７）を各バッファＡＤＵ（ｊ）（０≦ｊ≦Ｎ−１）の始めにコピーし、
Ｎ個の有用フィールドを各自のバッファＡＤＵ（ｊ）（０≦ｊ≦Ｎ−１）にコピーし、同数の付加データユニットＡＤＵ（ｊ）を生成するため、ネットワークプロトコルルールに従う最終的に更新されたチェック合計によりバッファＡＤＵ（ｊ）を完成させ、（ＡＤＵ（０）はより短い有用情報ＵＩのハードビットを有するのに対して、ＡＤＵ（ｊ）（０≦ｊ≦Ｎ−１）はこのより短い有用情報ＵＩのｊ番目のソフトビットを有する。）
トレーラＴｒｉ（２≦ｉ≦７）を有用フィールドＵＦｊの終わりにコピーし、
当該レイヤのチェック合計を再計算し、バッファＡＤＵ（ｊ）（０≦ｊ≦Ｎ−１）にコピーし、
レイヤＬｉ（２≦ｉ≦７）のプロトコルに特有な他の情報を計算し、バッファＡＤＵ（ｊ）（０≦ｊ≦Ｎ−１）内の適切な位置に配置する。
【００８９】
この点から、バッファＡＤＵ（ｊ）（０≦ｊ≦Ｎ−１）は付加データユニットになった。ここで、ハード付加データユニットＡＤＵ０は、単にもとのハードデータユニットＨＤＵ０の更新されたものであり、その制御情報は、ハードデータユニットＡＤＵ（０）が受信機及び可能なルータのターゲットネットワークプロトコルスタックＤＳＴＫによるさらなる拒絶を回避できるよう再計算された。エラーがハードデータユニットＤＵ０において検出される場合に、これは起こりうる。
【００９０】
本発明の好適な実施例では、収集手段ＣＯＬＬは、付加データユニットＡＤＵ（ｊ）を第２レイヤのハードデータユニットＡＤＵ（０）と関連付ける特定化情報として供する識別サブ手段ＤＩＳＣＲにより供給されるハード制御情報ＣｏＩ内のフィールドを抽出するためのものである。本発明の第１実施例において、関連付けされた受信ソースアプリケーションデータユニットＲＡＳＤＵのＲＴＰシーケンス番号を付加データユニットの特定化情報として利用するシンプルな解法を説明した。ここでの状況は、複数の付加データユニットＡＤＵ（ｊ）が１つのハードデータユニットＡＤＵ（０）と関連付けされているため、より複雑である。従って、アプリケーション層が正しい順序で付加データユニットＡＤＵ（ｊ）を処理することを保証するため、シーケンス番号の並び替えが必要となる。ハードデータユニットＡＤＵ（０）のＲＴＰシーケンス番号ｓ０を考える場合、本実施例の解法では、ハード及びソフト情報を有する付加データユニットＡＤＵ（ｊ）のＲＴＰシーケンス番号として、ＲＴＰシーケンス番号ｓ０＋ｊ（０≦ｊ≦Ｎ−１）が選ばれる。
【００９１】
付加データユニットＡＤＵ（ｊ）はさらに、マーク手段ＭＡＲＫに送信される。例えば、マーク手段は、これらデータユニットに前述したような特定のターゲットポート番号Ｐ２をマークし、Ｎ個のマークされたソフトデータユニットＭＡＤＵ（ｊ）（１≦ｊ≦Ｎ−１）を出力する。
【００９２】
付加データユニットＡＤＵ（ｊ）に特定のターゲットポート番号を利用することによる１つの効果は、アプリケーション層Ｌ７における混乱を引き起こすとこなく、付加データユニットと受信されたソースアプリケーションデータユニットに対して、同一のＲＴＰシーケンス番号の利用が可能になるということである。実際、例えば、各自がＲＴＰシーケンス番号ｓ０及びｓ０＋１を有する２つの連続したハードデータユニットＡＤＵ（０）及びＡＤＵ’（０）を考える場合、ＡＤＵ（０）に関連付けされた第１追加的ソフトデータユニットＡＤＵ（１）にはまたＲＴＰシーケンス番号ｓ０＋１が与えられる。しかしながら、ＡＤＵ（１）はＡＤＵ’（０）と同じターゲットポート番号では送信されないため、問題は生じない。アプリケーション層Ｌ７は、共に同一のＲＴＰシーケンス番号ｓ０＋１を有するが、ＡＤＵ（１）とＡＤＵ’（０）は異なるタイプのデータであるという事実を認識する。
【００９３】
付加情報ＡＤＵ（ｊ）は、受信機のターゲットネットワークプロトコルスタックＤＳＴＫを介し上方にパスされる。それがアプリケーション層Ｌ７に到達すると、有用フィールドＵＦ（ｊ）であるマークされた付加データユニットＭＡＤＵ（ｊ）から付加情報を抽出するための抽出手段ＲＥＴＲＩＥＶにより受信される。
【００９４】
抽出手段はさらに、有用フィールドＵＦｊからハード情報ＨＩとソフト情報ＳＩを復元する逆数量化サブ手段ＤＥＱＵＡＮＴを有する。
【００９５】
逆数量化サブ手段は、有用フィールドＵＦｊ（０≦ｊ≦Ｎ−１）からハード情報ＨＩとソフト情報ＳＩを生成するためのものである。当業者に周知な逆数量化プロセスが利用される。数量化サブ手段ＱＵＡＮＴにより利用されるタイプの数量化について通知されているとすると、逆数量化サブ手段ＤＥＱＵＡＮＴはいくつの連続した有用フィールドＵＦｊが一緒に処理されねばならないか知る。さらに、それらは同一のＲＴＰシーケンス番号を有する。逆数量化の実行時、有用フィールドはハード情報ＨＩとソフト情報ＳＩを形成し、その後、本実施例ではソースデコーダであるターゲットアプリケーションに供給される。
【００９６】
ここで、前述の例にあるように、第１レイヤ（物理層）と第２レイヤ（アプリケーション層）は共に、受信機のターゲットネットワークプロトコルスタックＤＳＴＫに属してもよいが、それに限定されるものではない。例えば、図１０は、ネットワークが正しい方向にデータユニットを到達させるルーティングを担う複数のルータＲ１〜Ｒ４を備えるケースを示す。ルータはネットワークプロトコルスタックの一種であり、一般に下位３つのレイヤのみを利用する。実際、最終的なターゲットにデータユニットを導くために、ネットワーク層Ｌ３から知らされるＩＰアドレスのみが必要となる。
【００９７】
図１０の例では、２つのタイプの送信チャンネルが考えられている。すなわち、送信機ＴＲＡＮＳとルータＲ１との間、ルータＲ１とＲ２との間、ルータＲ４とＲ３との間、及びルータＲ３と受信機ＲＥＣとの間のインターネットリンクと、ルータＲ２とＲ４との間の無線リンクである。
【００９８】
無線リンクは有線リンクよりデータにより多くのノイズを発生させる。従って、送信ノイズによるエラーが最も起こりやすい無線リンクの終わりでソフト復号化処理を利用し、インターネット上の出力ソフトデータを、この場合ソースデコーダであるターゲットアプリケーションに送信することは興味深い。ネットワークプロトコルスタックを介したパス処理に加えて、マークされた付加データユニットＭＡＤＵ（ｊ）（０≦ｊ≦Ｎ−１）は、１以上のルータを介しパスされねばならない。これらはネットワークプロトコルルールに従っているため、特に問題は生じない。
【００９９】
ここで、第２実施例で説明されたものと同様のソフト入力−ソフト出力チャンネルデコーダＣＤＥＣは、ハードのみ、あるいはハードとソフト両方を出力することができる。
【０１００】
図１１において、本発明の第３実施例が説明される。そこでは、受信機側のターゲットネットワークプロトコルスタックＤＳＴＫのアプリケーション層Ｌ７により物理層Ｌ１に送信される付加情報Ｉ３が扱われる。
【０１０１】
ターゲットアプリケーションＤＡＰＰは、ソフト復号化の実行を要求するため、チャンネルデコーダＣＤＥＣにアドレス指定される制御指示ＣＯを生成する生成手段ＧＥＮＥＲを有する。そのような受信機は、アプリケーション層Ｌ７に調整手段ＡＤＡＰとマーク手段ＭＡＲＫと、物理層Ｌ１に抽出手段ＲＥＴＲＩＥＶを有する。収集及び調整手段は前述のケースよりはるかにシンプルなものである。下方に進むとき、これは付加データユニット内の制御指示のカプセル化を扱うネットワークプロトコルスタックであるためである。
【０１０２】
物理層Ｌ１のレベルでは、逆に抽出手段は前述の実施例より複雑になっている。実際、そのような付加データユニットは、それのターゲットである第１レイヤに到達するとき、カプセル解除される必要がある。
【０１０３】
抽出手段ＲＥＴＲＩＥＶは、さらに、付加データユニットから制御指示を抽出するカプセル解除サブ手段ＤＥＣＡＰＳを有する。その処理は、ネットワークプロトコルスタックと同様に実行される。
【０１０４】
本発明の第３実施例では、ハードチャンネル復号化情報が最終的なソース復号化情報の効率的な質を提供しないとソースデコーダが判断すると、ソースデコーダは物理層Ｌ１に追加的なソフト情報を要求するようにしてもよい。このため、ソースデコーダとチャンネルデコーダとの間の後方への通信が確立される。この通信は、「ハード復号化処理の実行」や「ソフト復号化処理の実行」のような単純な指示に限定される。言い換えると、本実施例は「オンデマンド」ソフト復号化モードを実現する。
【０１０５】
この「オンデマンド」ソフト複合化モードの効果は、チャンネルデコーダとソースデコーダとの間の不要な複雑さの導入を回避できるということである。ソースデコーダによる必要時に、付加情報は送信されるにすぎない。
【０１０６】
本発明の第４実施例では、ターゲットアプリケーションＤＡＰＰは、第２実施例のチャンネルデコーダＣＤＥＣと同様にソフト出力を提供するソースデコーダＳＤＥＣである。この場合、ソースデコーダＳＤＥＣは、チャンネルデコーダにアドレス指定されるハードソース情報ＨＳＩとソフトソース情報ＳＳＩを生成する生成手段を有する。ハードソース情報ＨＳＩとソフトソース情報ＳＳＩは、図１１に示されるように、前述の制御指示ＣＯと同様に従う。さらに、ハードソース情報ＨＳＩとソフトソース情報ＳＳＩは、以前に受信したソースアプリケーションデータユニットＲＳＡＤＵに関するものである。このため、本発明の第４実施例では、アプリケーション層Ｌ７は、この以前に受信したソースアプリケーションデータユニットＲＳＡＤＵについてのアプリケーション層Ｌ７の特定化情報IIの収集を行う収集手段ＣＯＬＬを有する。以前のように、ＲＴＰシーケンス番号ＲＴＰ＿ＮＢは、ハードソース情報ＨＳＩとソフトソース情報ＳＳＩをこの以前に受信したソースアプリケーションデータユニットＲＳＡＤＵを関連付けるための関連する特定化情報IIとしてとることができる。
【０１０７】
例えば、ソフト復号化モードがアクティブ状態とされるとする。ソースデコーダＳＤＥＣは、ソース復号化情報ＳＤＩの生成に利用される受信したソースアプリケーションデータユニットＲＳＡＤＵについて、チャンネルデコーダＣＤＥＣからハード情報ＨＩとソフト情報ＳＩを受信した。チャンネルデコーダＣＤＥＣと同様に、ソースデコーダＳＤＥＣはまた、ソフト出力の供給、すなわち、受信したハード情報ＨＩとソフト情報ＳＩの各データに実数値を割り当てる。この実数値は、ソースデコーダＳＤＥＣの決定と当該決定の正確さの確率を示すものである。チャンネルデコーダＣＤＥＣと同様に、ソースデコーダＳＤＥＣはその後、正確さを維持し、ソース復号化情報ＳＤＩを供給するため、多数のビット上でこの実数値を数量化する。
【０１０８】
この場合、収集、調整及びマーク手段はアプリケーション層Ｌ７内に配置される一方、抽出手段ＲＥＴＲＩＥＶは物理層Ｌ１に配置される。
【０１０９】
図１２において、調整手段ＡＤＡＰが示され、それは、ソース付加情報ＨＳＩとＳＳＩからより短いソース付加情報ＳＢ０を供給する数量化サブ手段ＱＵＡＮＴと（この数量化処理は、例えば、Ｎビットで行われる。）、より短いソース付加情報ＳＢ０を有用ソースフィールドＵＳＦ（ｊ）に構成する構成手段ＳＴＲＵＣＴを有する。
【０１１０】
このとき、マーク手段ＭＡＲＫは、トランスポート層Ｌ４が追加的ソースデータユニット内のターゲットポート番号を正確に書き入れることができるように、付加情報に特定のターゲットポート番号Ｐ２が与えられる必要があるということをネットワークプロトコルスタックＤＳＴＫに示すためのものである。
【０１１１】
物理層では、抽出手段ＲＥＴＲＩＥＶは、それのターゲットポート番号を利用して、追加的ソースデータユニットＡＳＤＵ（ｊ）（０≦ｊ≦Ｎ−１）を傍受するためのものである。図１２ｂにおいて、抽出手段ＲＥＴＲＩＥＶが説明され、それは、追加的ソース復号化データユニットＡＳＤＵ（ｊ）から有用ソースフィールドＵＳＦ（ｊ）を抽出するカプセル解除手段ＤＥＣＡＰＳと（この処理はネットワークプロトコルスタックと同様に実行される）、有用ソースフィールドＵＳＦ（ｊ）からハードソース情報ＨＳＩとソフトソース情報ＳＳＩを復元する逆数量化手段ＤＥＱＵＡＮＴを有する。
【０１１２】
本発明の第４実施例では、ソースデコーダＳＤＥＣが、チャンネルデコーダＣＤＥＣにハードソース情報ＨＳＩとソフトソース情報ＳＳＩを送り返す。
【０１１３】
ソースデコーダＳＤＥＣとチャンネルデコーダＣＤＥＣとの間の後方への通信の１つの効果は、ソースデコーダが受信したソースアプリケーションデータユニットＲＳＡＤＵを処理した方法についてチャンネルデコーダにフィードバックを与えることである。ソースデコーダにより送信されるハードソース情報ＨＳＩとソフトソース情報ＳＳＩを利用することにより、チャンネルデコーダＣＤＥＣは、効果的に、自らの決定と受信したソースアプリケーションデータユニットＲＳＡＤＵの確率を再計算し、更新されたハード及びソフト情報を出力する。このようにして、結合したソースチャンネル復号化処理が実行され、連続するパスにおいて繰り返される。この繰り返しの復号化モードの目的は、結合したソースチャンネルデコーダを、再構成の質に関して、与えられた受信したソースアプリケーションデータユニットＲＳＡＤＵに対する最良のソース復号化情報ＳＤＩに収束させるためである。
【０１１４】
上記送信方法は、送信機及び受信機に配備されたコンピュータまたはデジタルプロセッサの制御のもと実行可能なインストラクション群により好適に実現される。
【０１１５】
ここで、上記方法、受信機、送信機、送信システム及びネットワークに関して、本発明の範囲を逸脱することなく変更または改良が提起されてもよい。本発明は、与えられた例に限定されるものではない。
【０１１６】
動詞「有する」及びその活用形の利用は、クレームに述べられたもの以外の要素あるいはステップの存在を排除するものではない。要素の前の冠詞「１つの」の利用は、そのような要素が複数存在することを排除するものではない。
【図面の簡単な説明】
【０１１７】
【図１】図１は、従来技術によるネットワーク通信システムの概略図である。
【図２】図２は、送信システム内の付加データの交換に関するいくつかの例を与える概略図である。
【図３】図３は、本発明による受信機の概略図である。
【図４ａ】図４ａは、ネットワークプロトコル規則に従うデータユニットの構成を示す。
【図４ｂ】図４ｂは、ＯＳＩモデルによるネットワークプロトコルスタックの階層構造を示す。
【図４ｃ】図４ｃは、ＴＣＰ／ＩＰモデルによるネットワークプロトコルスタックの階層構造を示す。
【図５】図５は、本発明による送信システム内の追加的ソフトデータユニットの送信を示す概略図である。
【図６ａ】図６ａは、本発明による送信システムの調整手段を示す。
【図６ｂ】図６ｂは、本発明による送信システムの抽出手段を示す。
【図７】図７は、本発明による数量化サブ手段内のソフト復号化処理に利用される一様な数量化処理の概略図である。
【図８】図８は、本発明による識別サブ手段を示す。
【図９】図９は、本発明による構成及びカプセル化サブ手段を示す。
【図１０】図１０は、複数のルータを有する送信システム内の追加的ソフトデータユニットの送信を示す概略図である。
【図１１】図１１は、本発明による「繰り返しの」ソフト復号化モードの制御指示または付加情報の受信機のアプリケーション層から物理層への送信のための概略図である。
【図１２ａ】図１２ａは、本発明による「繰り返しの」ソフト復号化モードのための調整手段を示す。
【図１２ｂ】図１２ｂは、本発明による「繰り返しの」ソフト復号化モードのための抽出手段を示す。
【図１】
2005512462.tif 000004
【図２】
2005512462.tif 000005
【図３】
2005512462.tif 000006
【図４ａ】
2005512462.tif 000007
【図４ｂ】
2005512462.tif 000008
【図４ｃ】
2005512462.tif 000009
【図５】
2005512462.tif 000010
【図６ａ】
2005512462.tif 000011
【図６ｂ】
2005512462.tif 000012
【図７】
2005512462.tif 000013
【図８】
2005512462.tif 000014
【図９】
2005512462.tif 000015
【図１０】
2005512462.tif 000016
【図１１】
2005512462.tif 000017
【図１２ａ】
2005512462.tif 000018
【図１２ｂ】
2005512462.tif 000019
【国際調査報告】
2005512462.tif 000020
2005512462.tif 000021
2005512462.tif 000022