(57)【要約】本発明は、無線アクセス・ネットワーク中の制御エンティティを含む無線通信システムにおいて、送信エンティティから受信エンティティへ提供されるサービスのデータ・パケットの配信に応答するために使用されるＨＡＲＱ再送プロトコルの応答モードを設定するための方法に関係する。送信信号の強固さを提供すると共に全体の送信効率を向上させるために、上記制御エンティティは、ＱｏＳ属性または物理層のパラメータの少なくとも一つに基づいて第１及び第２の応答モードの一つを設定する。設定された応答モードによる応答メッセージが送信され、データ・パケットが受信エンティティによってうまく復号されなかった場合、第１の応答モードでの応答メッセージは、受信エンティティでデータ・パケットを復号する際に得られたデータ・パケットの複数の復号品質レベルの一つを示し、第２の応答モードでの応答メッセージはデータ・パケットの復号失敗を示す。
2009517935.tif 000002
【特許請求の範囲】
【請求項１】
無線アクセス・ネットワーク中の制御エンティティをさらに含む無線通信システムにおいて、送信エンティティから受信エンティティへ提供されるサービスのデータを含むデータ・パケットの配信に応答するために使用されるＨＡＲＱ再送プロトコルの応答モードを設定するための方法であり、当該方法は、
サービス品質の属性または物理層のパラメータの少なくとも一つに基づいて、上記制御エンティティがそれによればＨＡＲＱ再送プロトコルが動作可能である第１及び第２の応答モードの一つを設定するステップであって、ここで設定された応答モードはデータ・パケットの配信に応答するために上記受信エンティティによって使用されることになる、前記ステップと、
上記送信エンティティから上記受信エンティティへデータ・パケットを送信するステップと、
上記受信エンティティがデータ・パケットを受信して復号するステップと、
前記データ・パケットの受信に応えて、設定された応答モードによる応答メッセージを上記受信エンティティが送信するステップと
を含み、
データ・パケットが上記受信エンティティによってうまく復号されなかった場合、第１の応答モードでの応答メッセージは、上記受信エンティティでデータ・パケットを復号する際に得られたデータ・パケットの複数の復号品質レベルの一つを示し、
データ・パケットが上記受信エンティティによってうまく復号されなかった場合、第２の応答モードでの応答メッセージはデータ・パケットの復号失敗を示す、
ＨＡＲＱ再送プロトコルの応答モードを設定するための方法。
【請求項２】
上記制御エンティティが、設定された応答モードを上記送信エンティティと上記受信エンティティにシグナリングにより通知することをさらに含む、請求項１に記載の方法。
【請求項３】
上記制御エンティティは上記送信エンティティに含まれ、上記設定ステップは上記送信エンティティによって実行され、当該方法は上記送信エンティティから上記受信エンティティへ設定された応答モードをシグナリングにより通知することをさらに含む、請求項１に記載の方法。
【請求項４】
上記制御エンティティは上記受信エンティティに含まれ、上記設定ステップは上記受信エンティティによって実行され、当該方法は上記受信エンティティから上記送信エンティティへ設定された応答モードをシグナリングにより通知することをさらに含む、請求項１に記載の方法。
【請求項５】
設定された応答モードは、無線ベアラ確立手順及び／または無線ベアラ再設定手順中で交換される無線ベアラ設定メッセージにて通知される、請求項１から請求項４のいずれかに記載の方法。
【請求項６】
第１の応答モードを第１のＨＡＲＱプロセスに属させ及び／または第２の応答モードを第２のＨＡＲＱプロセスに属させることと、サービスを送信するために第１及び第２のＨＡＲＱプロセスの一つを設定された応答モードに基づいて選択することをさらに含む、請求項１から請求項５のいずれかに記載の方法。
【請求項７】
上記物理層のパラメータは、サービスを送信するために使用される標準的なデータ・パケットのサイズを含んでなり、標準的なデータ・パケットのサイズが第１の所定値よりも大きいときには第１の応答モードが設定され、標準的なデータ・パケットのサイズが前記第１の所定値よりも小さいときには第２の応答モードが設定される、請求項１から請求項６のいずれかに記載の方法。
【請求項８】
上記サービス品質のパラメータが上記送信エンティティから上記受信エンティティへ提供されるサービスのビット・レートであり、ビット・レートが第２の所定値よりも大きいときには第１の応答モードが設定され、ビット・レートが前記第２の所定値よりも小さいときには第２の応答モードが設定される、請求項１から請求項７のいずれかに記載の方法。
【請求項９】
第１の応答モードが設定され、前記方法は、
上記受信エンティティの送信電力レベルが第３の所定値より高いときには、上記受信エンティティが設定された第１の応答モードから第２の応答モードへ切り替えることと、
上記受信エンティティの送信電力レベルが第３の所定値より小さいときには、上記受信エンティティが第２の応答モードから第１の応答モードへ切り替えて元に戻すことと
をさらに含む、請求項１から請求項８のいずれかに記載の方法。
【請求項１０】
第１の応答モードから第２の応答モードへ切り替えた後及び／または第２の応答モードから第１の応答モードへ戻すように切り替えた後、上記受信エンティティがそのときの応答モードを上記送信エンティティにシグナリングにより通知することをさらに含む、請求項９に記載の方法。
【請求項１１】
第１の応答モードが設定され、前記方法は、
応答メッセージを運ぶチャネル上の干渉レベルの情報を上記送信エンティティが取得することと、
上記送信エンティティで取得された干渉レベルが第４の所定値より大きいときには、上記送信エンティティが設定された第１の応答モードから第２の応答モードへ切り替えることと、
上記送信エンティティで取得された干渉レベルが第４の所定値より小さいときには、上記送信エンティティが第２の応答モードから第１の応答モードへ切り替えて戻すことと
をさらに含む、請求項１から請求項１０のいずれかに記載の方法。
【請求項１２】
第１の応答モードが設定され、前記方法は、
上記受信エンティティによって送信された応答メッセージを上記送信エンティティが復号すること、
応答メッセージの復号品質が第５の所定値より小さいときには、上記送信エンティティが設定された第１の応答モードから第２の応答モードへ切り替えることと、
応答メッセージの復号品質が第５の所定値より大きいときには、上記送信エンティティが第２の応答モードから第１の応答モードへ切り替えて戻すことと              
をさらに含む、請求項１から請求項１１のいずれかに記載の方法。
【請求項１３】
第１の応答モードから第２の応答モードへの切り替えた後及び／または第２の応答モードから第１の応答モードへ戻すように切り替えた後、上記送信エンティティはそのときの応答モードを上記受信エンティティにシグナリングにより通知することをさらに含んでなる、請求項１１または請求項１２のいずれかに記載の方法。
【請求項１４】
上記送信エンティティは無線アクセス・ネットワーク内の基地局であり、上記受信エンティティは移動端末である、請求項１から請求項１３のいずれかに記載の方法。
【請求項１５】
上記送信エンティティは移動端末であり、上記受信エンティティは無線アクセス・ネットワーク内の基地局である、請求項１から請求項１３のいずれかに記載の方法。
【請求項１６】
上記物理層のパラメータは、移動端末のソフト・ハンドオーバ状態をさらに含んでなり、移動端末がソフト・ハンドオーバ中で第１の基地局から第２の基地局へハンドオーバされているときには、第２の応答モードが設定される、請求項１４または請求項１５のいずれかに記載の方法。
【請求項１７】
無線アクセス・ネットワーク中の制御エンティティをさらに含む無線通信システムにおいて、送信エンティティから受信エンティティへ提供されるサービスのデータを含むデータ・パケットの配信に応答するために使用されるＨＡＲＱ再送プロトコルの応答モードを設定するための方法であり、当該方法は、
上記送信エンティティから上記受信エンティティへのデータ・パケットの送信に使用される無線リソース割り当てタイプに基づいて、上記制御エンティティがそれによればＨＡＲＱ再送プロトコルが動作可能である第１及び第２の応答モードの一つを設定するステップと、ここで設定された応答モードはデータ・パケットの配信に応答するために上記受信エンティティによって使用されることになる、
上記送信エンティティから上記受信エンティティへデータ・パケットを送信するステップと、
上記受信エンティティがデータ・パケットを受信して復号するステップと、
前記データ・パケットの受信に応えて、設定された応答モードによる応答メッセージを上記受信エンティティが送信するステップと
を含んでなり、
データ・パケットが上記受信エンティティによってうまく復号されなかった場合、第１の応答モードでの応答メッセージは、上記受信エンティティでデータ・パケットを復号する際に得られたデータ・パケットの複数の復号品質レベルの一つを示し、
データ・パケットが上記受信エンティティによってうまく復号されなかった場合、第２の応答モードでの応答メッセージはデータ・パケットの復号失敗を示す、
ＨＡＲＱ再送プロトコルの応答モードを設定するための方法。
【請求項１８】
局所化無線リソース割り当てタイプが使用されるときには第１の応答モードが設定され、分散化無線リソース割り当てタイプが使用されるときには第２の応答モードが設定される、請求項１７に記載の方法。
【請求項１９】
送信エンティティと、受信エンティティと、無線アクセス・ネットワーク中の制御エンティティとを具備する無線通信システムであり、前記無線通信システムは、上記送信エンティティから上記受信エンティティへ提供されるサービスのデータを含むデータ・パケットの配信に応答するために使用されるＨＡＲＱ再送プロトコルの応答モードを設定するようになされ、
上記制御エンティティは、サービス品質の属性または物理層のパラメータの少なくとも一つに基づいて、それによればＨＡＲＱ再送プロトコルが動作可能である第１及び第２の応答モードの一つを設定するための設定手段を具備し、ここで設定された応答モードはデータ・パケットの配信に応答するために上記受信エンティティによって使用されることになる、
上記送信エンティティは、データパケットを上記受信エンティティへ送信するための送信手段を具備し、
上記受信エンティティは、送信されたデータ・パケットを受信して復号するための受信及び復号手段と、前記データ・パケットの受信に応えて、設定された応答モードによる応答メッセージを上記受信エンティティが送信するための送信手段とを具備し、
データ・パケットが上記受信エンティティによってうまく復号されなかった場合、第１の応答モードでの応答メッセージは、上記受信エンティティでデータ・パケットを復号する際に得られたデータ・パケットの複数の復号品質レベルの一つを示し、
データ・パケットが上記受信エンティティによってうまく復号されなかった場合、第２の応答モードでの応答メッセージはデータ・パケットの復号失敗を示す、
無線通信システム。
【請求項２０】
上記制御エンティティは設定された応答モードを上記送信エンティティと上記受信エンティティにシグナリングにより通知するようになされる、請求項１９に記載の無線通信システム。
【請求項２１】
上記制御エンティティは上記送信エンティティに含まれ、上記送信エンティティは応答モードを設定し、設定された応答モードを上記受信エンティティにシグナリングにより通知するようになされる、請求項１９に記載の無線通信システム。
【請求項２２】
上記制御エンティティは上記受信エンティティに含まれ、上記受信エンティティは応答モードを設定し、設定された応答モードを上記送信エンティティにシグナリングにより通知するようになされる、請求項１９に記載の無線通信システム。
【請求項２３】
上記制御エンティティは、設定された応答モードを無線ベアラ確立手順及び／または無線ベアラ再設定手順中で交換される無線ベアラ設定メッセージにて通知するようになされる、請求項１９から請求項２２のいずれかに記載の無線通信システム。
【請求項２４】
上記制御エンティティは、第１の応答モードを第１のＨＡＲＱプロセスに属させ及び／または第２の応答モードを第２のＨＡＲＱプロセスに属させ、サービスを送信するために第１及び第２のＨＡＲＱプロセスの一つを設定された応答モードに基づいて選択するようにさらになされる、請求項１９から請求項２３のいずれかに記載の無線通信システム。
【請求項２５】
上記物理層のパラメータは、サービスを送信するために使用される標準的なデータ・パケットのサイズであり、上記制御エンティティは、標準的なデータ・パケットのサイズが第１の所定値よりも大きいときには第１の応答モードを設定し、標準的なデータ・パケットのサイズが前記第１の所定値よりも小さいときには第２の応答モードを設定するようになされる、請求項１９から請求項２４のいずれかに記載の無線通信システム。
【請求項２６】
上記サービス品質のパラメータが上記送信エンティティから上記受信エンティティへ提供されるサービスのビット・レートであり、上記制御エンティティは、ビット・レートが第２の所定値よりも大きいときには第１の応答モードを設定し、ビット・レートが前記第２の所定値よりも小さいときには第２の応答モードを設定するようにさらになされる、請求項１９から請求項２５のいずれかに記載の無線通信システム。
【請求項２７】
第１の応答モードが設定され、上記受信エンティティは、移動端末の送信電力レベルが第３の所定値より高いときには、設定された第１の応答モードから第２の応答モードへ切り替え、移動端末の送信電力レベルが第３の所定値より小さいときには、第２の応答モードから第１の応答モードへ切り替えて元に戻すようになされる、請求項１９から請求項２６のいずれかに記載の無線通信システム。
【請求項２８】
上記受信エンティティは、第１の応答モードから第２の応答モードへ切り替えた後及び／または第２の応答モードから第１の応答モードへ戻すように切り替えた後、そのときの応答モードを上記送信エンティティにシグナリングにより通知するようになされる、請求項２７に記載の無線通信システム。
【請求項２９】
第１の応答モードが設定され、上記送信エンティティは、応答メッセージを運ぶチャネル上の干渉レベルの情報を取得し、当該干渉レベルが第４の所定値より大きいときには設定された第１の応答モードから第２の応答モードへ切り替え、当該干渉レベルが第４の所定値より小さいときには、第２の応答モードから第１の応答モードへ切り替えて戻すようになされる、請求項１９から請求項２８のいずれかに記載の無線通信システム。
【請求項３０】
第１の応答モードが設定され、上記送信エンティティは、上記受信エンティティによって送信された応答メッセージを復号し、当該応答メッセージの復号品質が第５の所定値より小さいときには、設定された第１の応答モードから第２の応答モードへ切り替え、当該応答メッセージの復号品質が第５の所定値より大きいときには、第２の応答モードから第１の応答モードへ切り替えて戻すようになされる、請求項１９から請求項２９のいずれかに記載の無線通信システム。
【請求項３１】
上記送信エンティティは、第１の応答モードから第２の応答モードへ切り替えた後及び／または第２の応答モードから第１の応答モードへ戻すように切り替えた後、そのときの応答モードを上記受信エンティティにシグナリングにより通知するようになされる、請求項２９または請求項３０に記載の無線通信システム。
【請求項３２】
上記送信エンティティは無線アクセス・ネットワーク内の基地局であり、上記受信エンティティは移動端末である、請求項１９から請求項３１のうちの一つに記載の無線通信システム。
【請求項３３】
上記送信エンティティは移動端末であり、上記受信エンティティは無線アクセス・ネットワーク内の基地局である、請求項１９から請求項３２のいずれかに記載の無線通信システム。
【請求項３４】
上記物理層のパラメータは、移動端末のソフト・ハンドオーバ状態をさらに含んでなり、上記制御エンティティは、移動端末がソフト・ハンドオーバ中で第１の基地局から第２の基地局へハンドオーバされているときには第２の応答モードを設定するようになされる、請求項３２または請求項３３に記載の無線通信システム。
【請求項３５】
送信エンティティと、受信エンティティと、無線アクセス・ネットワーク中の制御エンティティとを具備する無線通信システムであり、前記無線通信システムは、上記送信エンティティから上記受信エンティティへ提供されるサービスのデータを含むデータ・パケットの配信に応答するために使用されるＨＡＲＱ再送プロトコルの応答モードを設定するようになされ、
上記制御エンティティは、上記送信エンティティから上記受信エンティティへのデータ・パケットの送信に使用される無線リソース割り当てタイプに基づいて、それによればＨＡＲＱ再送プロトコルが動作可能である第１及び第２の応答モードの一つを設定するための設定手段を具備し、ここで設定された応答モードはデータ・パケットの配信に応答するために上記受信エンティティによって使用されることになる、
上記送信エンティティは、データパケットを上記受信エンティティへ送信するための送信手段を具備し、
上記受信エンティティは、送信されたデータ・パケットを受信して復号するための受信及び復号手段と、前記データ・パケットの受信に応えて、設定された応答モードによる応答メッセージを上記受信エンティティが送信するための送信手段とを具備し、
データ・パケットが上記受信エンティティによってうまく復号されなかった場合、第１の応答モードでの応答メッセージは、上記受信エンティティでデータ・パケットを復号する際に得られたデータ・パケットの複数の復号品質レベルの一つを示し、
データ・パケットが上記受信エンティティによってうまく復号されなかった場合、第２の応答モードでの応答メッセージはデータ・パケットの復号失敗を示す、
無線通信システム。
【請求項３６】
上記制御エンティティは、局所化無線リソース割り当てタイプが使用されるときには第１の応答モードを設定し、分散化無線リソース割り当てタイプが使用されるときには第２の応答モードを設定するようになされる、請求項３５に記載の無線通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ハイブリッド自動再送要求（ＨＡＲＱ）再送プロトコルの応答モードを設定するための方法、並びにＨＡＲＱ再送プロトコルの応答モードを設定するように適合された無線通信システムに関係する。本発明による方法は、ダウンリンクまたはアップリンク方向のいずれでも複数のレベルの否定応答（ＮＡＣＫ）シグナリングを使用するＨＡＲＱプロトコルを採用している移動通信ネットワーク中のいかなるシステムにも広く適用可能である。
【背景技術】
【０００２】
Ｗ−ＣＤＭＡ（Wideband Code Division Multiple Access;広帯域符号分割多元接続）は、第三世代無線移動通信システムとしての利用に向けて標準化されたＩＭＴ−２０００システム（International Mobile Telecommunicationシステム)のための無線インタフェースである。Ｗ−ＣＤＭＡは、音声サービスやマルチメディア移動通信サービスなど多様なサービスを柔軟で効率的な方法で提供する。日本、欧州、米国、その他の国々の標準化機関は、Ｗ−ＣＤＭＡについての共通無線インタフェース仕様を作成するために、合同でthe 3rd Generation Partnership Project (３ＧＰＰ)というプロジェクトを組織した。
【０００３】
ＩＭＴ−２０００の標準化された欧州バージョンは、一般に、ＵＭＴＳ（Universal Mobile Telecommunication System）と呼ばれる。ＵＭＴＳの仕様の最初のリリースは、１９９９年に公表された（リリース９９）。その後、リリース４、リリース５、リリース６において標準の改良が幾度か３ＧＰＰにより標準化された。さらなる改良についての検討が、リリース７の範疇で、Ｅｖｏｌｖｅｄ  ＵＭＴＳ地上無線アクセス （Ｅｖｏｌｖｅｄ  ＵＴＲＡ：Evolved UMTS Terrestrial Radio Access）及びＵＭＴＳ地上無線アクセス・ネットワーク （ＵＴＲＡＮ：UMTS Terrestrial Radio Access Network）に関する研究項目の範囲で現在行われている。
【０００４】
以下に、従来技術のＵＴＲＡＮリリース５のアーキテクチャと無線インタフェース・プロトコル・アーキテクチャを詳しく説明する。
【０００５】
ＵＭＴＳアーキテクチャ
Universal Mobile Telecommunication System（ＵＭＴＳ）のハイレベル・リリース９９／４／５のアーキテクチャを図１に示す（http://www.3gpp.orgから得られる非特許文献１を参照）。このＵＭＴＳシステムは、各々が定義された機能を有する、いくつかのネットワーク要素により構成される。各ネットワーク要素はそれぞれ各自の機能によって定義されるが、各ネットワーク要素の同様な物理的実現は、必ずしも必須ではないが一般的である。
【０００６】
ネットワーク要素は、機能的に、コア・ネットワーク（ＣＮ）１０１、ＵＭＴＳ地上無線アクセス・ネットワーク（ＵＴＲＡＮ）１０２及びユーザ装置（ＵＥ）１０３にグループ分けされる。ＵＴＲＡＮ １０２は無線通信に関係したすべての機能を処理することを担い、ＣＮ １０１は外部ネットワークへのデータ接続および呼のルーティングを担当する。これらのネットワーク要素間の相互接続は、オープン・インタフェース（Ｉｕ、Ｕｕ）により形成される。ＵＭＴＳシステムはモデュール形式であり、したがって同一タイプのネットワーク要素をいくつも持つことが可能であることに留意すべきである。
【０００７】
図２は、ＵＴＲＡＮの現行のアーキテクチャを示す。複数の無線ネットワーク・コントローラ（ＲＮＣ）２０１、２０２がＣＮ １０１に接続される。機能的には、ＲＮＣ２０１、２０２はそのドメイン内の無線リソースを所有、制御し、通常、アクセス・ネットワーク側での無線リソース制御プロトコルを終端させる。各ＲＮＣ ２０１、２０２は、ユーザ装置と通信する１個または数個の基地局（ノードＢ）２０３、２０４、２０５、２０６を制御する。数個の基地局を制御するＲＮＣは、これらの基地局にとっての支配ＲＮＣ（Ｃ−ＲＮＣ）と呼ばれる。支配下の基地局とそれらを制御するＣ−ＲＮＣを加えたセットは、無線ネットワーク・サブシステム（ＲＮＳ）２０７、２０８と呼ばれる。ユーザ装置とＵＴＲＡＮ間の各接続につき一つのＲＮＳがサービングＲＮＳ（Ｓ−ＲＮＳ）である。Ｓ−ＲＮＳは、コア・ネットワーク（ＣＮ）１０１とのいわゆるＩｕ接続を維持する。必要な場合には、ドリフトＲＮＳ ３０２（Ｄ−ＲＮＳ３０２）が、図３に示すように、無線リソースを提供することによってサービングＲＮＳ（Ｓ−ＲＮＳ）３０１をサポートする。各々のＲＮＣは、サービングＲＮＣ（Ｓ−ＲＮＣ）とドリフトＲＮＣ（Ｄ−ＲＮＣ）と呼ばれる。Ｃ−ＲＮＣとＤ−ＲＮＣは同じものであるので、Ｓ−ＲＮＣまたはＲＮＣという略語が使用されることもあり、多くの場合そうである。一般に、ドリフトＲＮＳ３０２は、異なるＲＮＳ間でのＵＥのソフト・ハンドオーバに使用される。
【０００８】
以下では、Ｃ−ＲＮＣとＤ−ＲＮＣが一致するものとしばしばみなされるが、この場合には、Ｓ−ＲＮＣまたはＲＮＣという略語のみを使用する。
【０００９】
ＵＴＲＡＮ地上インタフェースのプロトコル・モデルの概要説明
図４は、ＵＭＴＳネットワークにおけるＵＴＲＡＮのプロトコル・モデルの概要を示す。よりよく理解するために、ここでは簡単な説明だけを述べるが、非特許文献２を参照すればさらに詳細を知ることができる。
【００１０】
横方向の面で、プロトコル・モデルは、無線ネットワーク層とトランスポート・ネットワーク層に分けることができる。すべてのＵＴＲＡＮに関係した問題は無線ネットワーク層に現れて対処されるのに対して、トランスポート・ネットワーク層はＵＴＲＡＮ固有の変更なしにＵＴＲＡＮに対応したデータ伝送に使用されるように選ばれる、標準的なトランスポート技術に通常相当する。
【００１１】
縦方向の面で、プロトコル・モデルは、制御プレーンとユーザ・プレーンに分けることができる。制御プレーンは、ＵＭＴＳ固有のシグナリング（すなわち、無線ネットワーク層に関する制御シグナリング）に使用され、例えば、Ｉｕインタフェース上のＲＡＮＡＰ、Ｉｕｒインタフェース上のＲＮＳＡＰ、Ｉｕｂインタフェース上のＮＢＡＰ及びＵｕインタフェース上のＲＲＣといったアプリケーション・プロトコル（ＡＰ）を含む。制御プレーンの機能及びアプリケーション・プロトコルは、いわゆるシグナリング無線ベアラを介したユーザ装置へのトラヒック無線ベアラの設定を可能にする。
【００１２】
制御プレーンのプロトコルはＵＭＴＳ固有の制御シグナリングを担う一方、ユーザ・プレーンは、音声呼、ストリームーミング・データ・パケット交換方式のサービスのパケットなどといった、ユーザによって送信され、ユーザへ送信されるデータ・ストリームを伝送する。伝送のために、ユーザ・プレーンは、いわゆるトラヒック無線ベアラ（時にはデータ・ベアラということもある）を含む。
【００１３】
トランスポート・ネットワーク制御プレーンが、トランスポート・ネットワーク層内のシグナリングを制御するために使用されるが、これは無線ネットワーク層に関する情報を全く含まない。トランスポート・ネットワーク制御プレーンは、ユーザ・プレーンの情報を交換するためのトラヒック無線ベアラとＡＬＣＡＰプロトコル・メッセージを通信するために必要なシグナリング無線ベアラを設定するために使用されるＡＬＣＡＰプロトコルを含む。トランスポート・ネットワーク制御プレーンの存在により、制御プレーン内のアプリケーション・プロトコルは、ユーザ・プレーンにおけるトラヒック無線ベアラ上でのデータ伝送のために選択された技術から完全に独立して動作することができる。トランスポート・ネットワーク制御プレーンは、トランスポート・ネットワーク・ユーザ・プレーンの動作を制御する。
【００１４】
ＵＴＲＡ無線インタフェース・プロトコル・アーキテクチャ
ＵＴＲＡＮの無線インタフェース・プロトコル・アーキテクチャの概要を図５に示す。一般に、ＵＴＲＡＮの無線インタフェース・プロトコル・アーキテクチャは、ＯＳＩプロトコル・スタックの第１〜第３層を実装する。ＵＴＲＡＮ内で終端するプロトコルは、アクセス層（プロトコル）とも呼ばれる。アクセス層と対比的に、ＵＴＲＡＮ内で終端しないすべてのプロトコルは、通常、非アクセス層プロトコルと呼ばれる。
【００１５】
図４に関して述べたように、ユーザ・プレーンと制御プレーンへのプロトコルの縦の分割が示される。無線リソース制御（ＲＲＣ）プロトコルは、ＵＴＲＡ無線インタフェース（Ｕｕ）の下位層のプロトコルを制御する、制御プレーンの第３層のプロトコルである。
【００１６】
ＲＲＣプロトコルは、通常、ＵＴＲＡＮのＲＮＣで終端されるが、その他のネットワーク要素、例えばノードＢも、ＵＴＲＡＮ内でＲＲＣプロトコルを終端させることが考えられた。ＲＲＣプロトコルは、無線インタフェースの無線リソースへのアクセスを制御するための制御情報をＵＥへシグナリングするために使用される。さらに、ＲＲＣプロトコルが、非アクセス層プロトコル内の制御に通常関係付けられる非アクセス層プロトコル・メッセージをカプセル化して含み、伝送する可能性もある。
【００１７】
制御プレーン中で、ＲＲＣプロトコルは、サービス・アクセス・ポイント（ＳＡＰ）を通るシグナリング無線ベアラを介して、制御情報を第２層、すなわち無線リンク制御プロトコル（ＲＬＣ）へ中継する。ユーザ・プレーンにおいて、非アクセス層プロトコル・エンティティは、ＳＡＰを介して第２層へ直接アクセスするためにトラヒック無線ベアラを使用することができる。このアクセスは、ＲＬＣへ直接行われるか、または次にＰＤＵをＲＬＣプロトコル・エンティティに提供するパックド・データ・コンバージェンス・プロトコルに対して行われることもある。
【００１８】
ＲＬＣは、より上位の層に対してＳＡＰを提供する。ＳＡＰは、ＲＬＣがどのようにパケットを処理するか、例えば、ＲＬＣがトランスペアレントモード(transparent mode)、応答モード（acknowledged mode）、非応答モード（unacknowledged mode）のいずれで動作するかを定義する。ＲＲＣまたはＰＤＣＰによって制御プレーン及びユーザ・プレーン中のより上位の層に提供されるサービスは、それぞれ、シグナリング無線ベアラとトラヒック無線ベアラとも呼ばれる。
【００１９】
ＭＡＣ／ＲＬＣ層は、次に、そのサービスをいわゆる論理チャネルによってＲＬＣ層へ提供する。論理チャネルは、基本的にどのような種類のデータが伝送されるかを定義する。物理層は、ＭＡＣ／ＲＬＣ層へそのサービスを、いわゆるトランスポート・チャネルによって提供する。トランスポート・チャネルは、ＭＡＣ層から受け取ったデータを物理チャネルを介してどのように、どのような特性で送信するかを定義する。
【００２０】
機能の割り振り及びプロトコル・アーキテクチャ
上述したネットワーク要素のユーザ・プレーンと制御プレーンに置かれる本発明に関連する機能を以下に紹介する。
【００２１】
ＲＮＣ：制御プレーンの機能
ネットワーク側の無線リソース制御（ＲＲＣ）プロトコルは、ＲＮＣにおいて終端される。これは、とりわけ、本発明に関連する次の機能を含む。
・無線ベアラ、トランスポート・チャネル及び物理チャネルの制御、
・測定制御及び測定リポートの処理、 
・ＲＲＣ接続モビリティ機能
【００２２】
ノードＢアプリケーション・パート（ＮＢＡＰ）プロトコル、無線ネットワーク・サブシステム・アプリケーション・プロトコル（ＲＮＳＡＰ）及び無線アクセス・ネットワーク・アプリケーション・パート（ＲＡＮＡＰ）プロトコルは、それぞれ、Ｉｕｂ、Ｉｕｒ、Ｉｕインタフェースを通じてＲＮＣで終端される。
【００２３】
上述のＲＲＣ機能をサポートするために、次のＮＢＡＰの手順が使用される。
・無線リンク設定共通ＮＢＡＰ手順（ＮＢＡＰ）
・無線リンク追加／削除専用ＮＢＡＰ手順（ＮＢＡＰ）
・無線リンク再設定手順（ＮＢＡＰ）
【００２４】
ＲＮＣ：ユーザ・プレーンの機能
ＲＮＣは、リリース９９／４のプロトコル・アーキテクチャに準拠したネットワーク側のＭＡＣ及びＲＬＣプロトコルを終端させる。リリース５の高速ダウンリンク・パケット・アクセス（ＨＳＤＰＡ)及び高速アップリンク・パケット・アクセス（ＨＳＵＰＡ）に関連したユーザ・プレーンのプロトコル・スタック・アーキテクチャを以下に紹介する。これらのプロトコルの設定はＲＲＣによって制御される。
【００２５】
ノードＢ：ユーザ・プレーン／制御プレーンの機能
物理層だけが、ネットワーク側でリリース９９／４のノードＢで終端される。リリース５のノードＢは、後で解説するように、高速個別共有チャネル（ＨＳ−ＤＳＣＨ）トランスポート・チャネル向けのＭＡＣ層（ＭＡＣ−ｈｓ）を終端させる。Ｉｕｂインタフェースを通じてＮＢＡＰプロトコルを終端させるほかには、ノードＢにおける制御機能はない。
【００２６】
ＨＳＤＰＡの場合のユーザ・プレーンのプロトコル・スタック・アーキテクチャ
ＨＳＤＰＡのユーザ・プレーンの無線インタフェース・プロトコル・アーキテクチャを図６に示す。ＨＡＲＱプロトコル及びスケジューリング機能は、ノードＢとＵＥに割り振られているＭＡＣ−ｈｓサブ層に属する。応答モードにおいてＲＬＣサブ層のレベルでＲＮＣとＵＥ間にスライディング・ウィンドウ・メカニズムに基づく選択的再送（ＳＲ）自動再送要求（ＡＲＱ）プロトコルを確立することも可能であることに留意すべきである。ＲＮＣとＵＥ間のポイント・ツー・ポイント接続のためにＲＬＣサブ層から提供されるサービスは、無線ベアラと呼ばれる。
【００２７】
プロトコルのパラメータは、制御プレーン内のシグナリングによって設定される。このシグナリングは、無線ネットワーク（Ｓ−ＲＮＣとＵＥ）間のシグナリング用の無線リソース制御（ＲＲＣ）プロトコルによって、及び、Ｉｕｂインタフェースを通じたＮＢＡＰ及びＩｕｒインタフェースを通じたＲＮＳＡＰのアプリケーション・プロトコルによって制御される。
【００２８】
ＨＳＵＰＡの場合のユーザ・プレーンのプロトコル・スタック・アーキテクチャ
ＨＳＵＰＡのユーザ・プレーンの無線インタフェース・プロトコル・アーキテクチャを図７に示す。ＨＡＲＱプロトコル及びスケジューリング機能は、ノードＢとＵＥに割り振られているＭＡＣ−ｅサブ層に属する。再順序付け機能が、異なるセルから到着したデータ・パケットを再順序付けするために、フトハンドオーバでは必要である。これらの機能は、Ｓ−ＲＮＣ上のＭＡＣ−ｅｓに置かれる。ＨＳＤＰＡの場合と同様に、プロトコルのパラメータは制御プレーン内のシグナリングによって設定される。このシグナリングは、無線ネットワーク（Ｓ−ＲＮＣとＵＥ）間のシグナリング用の無線リソース制御（ＲＲＣ）プロトコルによって、及び、Ｉｕｂインタフェースを通じたＮＢＡＰ及びＩｕｒインタフェースを通じたＲＮＳＡＰのアプリケーション・プロトコルによって制御される。
【００２９】
無線ベアラの確立
データの送信前に、その送信に合った無線ベアラが確立され、それに応じてすべての層が設定される。無線ベアラを確立するための手順は、無線ベアラと個別トランスポートチャネルとの関係により変わり得る。サービス品質（ＱｏＳ）のパラメータに応じて、個別チャネルを無線ベアラに関連付けて不変に割り当てる場合とそうでない場合とがある。
【００３０】
以下では、従来技術のＵＭＴＳシステムにおいて個別物理チャネルの起動を伴う無線ベアラ確立手順の一例を図８に基づいて説明する。
【００３１】
図８に示した手順は、無線ベアラに対応する新しい物理チャネルを設ける必要がある場合に適用される。無線ベアラ確立は、ＲＲＣ層のネットワーク側で上位層のサービス・アクセス・ポイントからＲＢ確立要求プリミティブを受信する時に開始される。このプリミティブは、ベアラ基準とサービス品質のパラメータを含む。サービス品質のパラメータに基づいて、ネットワーク側のＲＲＣエンティティによってＬ１（第１層）及びＬ２（第２層）のパラメータが選定される。ＲＲＣは、アプリケーション／サービスのサービス品質のパラメータに基づいて、アプリケーション／サービスのデータを運ぶために最も適する無線ベアラ・パラメータを決定する。
【００３２】
すべての該当するノードＢに対して発行されたＣＰＨＹ−ＲＬ設定要求プリミティブによって、ネットワーク側の物理層処理が開始される。対象とされた受信ノードのいずれかがサービスを提供できない場合には、確認プリミティブでそのことが通知される。ノードＢでの送信／受信の開始を含むＬ１の設定が済んだ後、ＮＷ−ＲＲＣは無線ベアラ設定メッセージをその通信相手のエンティティへ送信する（応答送信または非応答送信は選択的である）。このメッセージは、Ｌ１、ＭＡＣ及びＲＬＣパラメータを含む。例えば、無線ベアラ設定時に、それに関与する各論理チャネルが１〜８の範囲のＭＡＣ論理チャネル優先度を持つように設定される。ＭＡＣ論理チャネル優先度は、ＲＢマッピング情報の情報要素に含まれる。このメッセージを受信後、ＵＥ−ＲＲＣは、メッセージで伝達されたパラメータに従ってＬ１、ＭＡＣ及びＲＬＣを設定する。
【００３３】
Ｌ１同期化が指示されるときは、ＵＥは応答モードで無線ベアラ設定完了メッセージをネットワークへ返送する。ＮＷ−ＲＲＣは、ネットワーク側のＭＡＣ及びＲＬＣを設定する。無線ベアラ設定完了に対する確認を受信後、ＵＥ−ＲＲＣは、新しい無線ベアラに関連付けた新しいＲＬＣエンティティを設置する。ＲＬＣ確立の適切な方法は、ＲＬＣ転送モードに依存して変わり得る。ＲＬＣ接続は暗示的に確立されてもよいし、または明示的なシグナリングを適用してもよい。最後に、ＲＢ確立通知プリミティブがＵＥ−ＲＲＣによって送信され、ＲＢ確立が確認される。
【００３４】
アクティブ接続の最中に無線ベアラ特性を変更することも可能である。すでに確立された無線ベアラに対してパラメータを再設定するために、無線ベアラ再設定手順が使用される。
【００３５】
Ｅｖｏｌｖｅｄ  ＵＴＲＡ無線インタフェース・プロトコル・アーキテクチャ
現在、無線インタフェース及び無線ネットワーク・アーキテクチャの進展が、３ＧＰＰにおいて最近取り上げられた「Ｅｖｏｌｖｅｄ  ＵＴＲＡ及びＵＴＲＡＮ」という研究項目において研究されている。この研究項目の狙いは、３ＧＰＰ無線アクセス技術の競争力を長期間をかけて確実なものにしようということである。狙いとする目標は、遅延時間の減少、より高いユーザ・データ伝送速度、パケット・サービスの最適化したサポート、システム容量及びカバレッジの向上、及び通信事業者にとってのコスト削減、並びにシステムの複雑性を低減することを含む。
【００３６】
現在のアーキテクチャを図９に示すが、ここでは、ＲＲＣは完全にＲＮＣに置かれ、第２層（ＭＡＣサブ層及びＲＬＣ）はノードＢとＲＮＣに割り振られている。このアーキテクチャに関するいくつかの異なる提案が、現在検討されている。提案の一つを図１０に示す。この提案は、遅延時間を少なくするために、従来のＵＭＴＳのリリース６のシステムではＲＮＣに存在している第２層全部（ＭＡＣ及びＲＬＣ）とおそらくはＲＲＣ機能の一部を無線インタフェースの方向へ、すなわちノードＢへ移動したことにある。検討中の別の提案を図１１に示すが、ここでは、従来のＲＮＣはＥｖｏｌｖｅｄ  ＵＴＲＡＮアーキテクチャでは除外されており、ＲＮＣに従来置かれていた機能はノードＢとコア・ネットワークの一部分であるＳＧＳＮ（サービングＧＰＲＳサポート・ノード）に割り振られている。
【００３７】
直交周波数分割多重アクセス（Orthogonal Frequency Division Multiplexing Access）におけるリソース割り当て技術
マルチユーザＯＦＤＭとも呼ばれるＯＦＤＭＡは、将来の世代の無線ネットワーク向けの変調及び多重アクセス方法として検討されている。ＯＦＤＭＡは、IEEE 802.11無線ＬＡＮ（ＷｉＦｉ）やIEEE 802.16無線広帯域アクセス・システム（ＷｉＭＡＸ）などのデータ・アクセス・システムで既に採用されている、直交周波数分割多重（ＯＦＤＭ）の拡張である。
【００３８】
直交周波数分割多重（ＯＦＤＭ）の基本原理は、周波数帯域をいくつかの狭帯域チャネルに分割することである。したがって、全体の周波数帯域のチャネルがマルチパス環境に起因して周波数選択的であっても、ＯＦＤＭは、比較的均一な並列チャネル（サブキャリア）でのデータの送信を可能にする。各サブキャリアは異なるチャネル状態になるので、各サブキャリアの容量はばらつき、違ったデータ伝送速度での各サブキャリア上の送信が可能になる。したがって、適応変調符号化によるサブキャリアを対象にした（周波数領域）リンク適応が、各サブキャリア上で異なるデータ伝送速度の送信を行うことによって無線効率を増加させる。ＯＦＤＭＡは、複数のユーザがＯＦＤＭシンボル当たり異なるサブキャリア上で同時に送信することを可能にする。すべてのユーザが特定のサブキャリア中の深いフェーディングを経験する可能性は非常に低いので、サブキャリアを当該サブキャリア上でよいチャネル・ゲインを見込むユーザに割り当てることを確実にすることができる。ダウンリンクのリソースをセル内の異なるユーザに割り当てる際に、各サブキャリアの各ユーザが経験したチャネル状態の情報をスケジューラは考慮に入れる。ユーザによるシグナリングで通知された制御情報、すなわちＣＱＩにより、スケジューラは複数のユーザ間のダイバーシチを利用することによりスペクトル効率の増加を図れる。
【００３９】
ＯＦＤＭＡにおいて利用可能な周波数スペクトルを異なるユーザ間に割り振る無線アクセス方式に基づいて、二つの異なるリソース割り当て方法を区別することができる。第一の割り当てモードは、局所化モードと呼ばれ、特定のＵＥが最良の無線チャネル状態を経験するようにサブキャリアを割り当てることによって、周波数スケジューリング・ゲインの利点を完全に得ようとするものである。このスケジューリング・モードは、関連するシグナリング（リソース割り当てシグナリング、アップリンクでのＣＱＩ）を必要とするので、このモードは非リアルタイムの、高データ伝送速度向けのサービスに最も適するであろう。局所化リソース割り当てモードでは、ユーザはサブキャリアの連続するブロックを割り当てられる。
【００４０】
第二のリソース割り当てモードは、分散化モードと呼ばれ、時間と周波数の格子上に散在するリソースを割り当てることによって送信信号の強固性を得るために周波数ダイバーシチ効果を頼りにする。局所化モードとの基本的な違いは、リソース割り当てアルゴリズムが受信機での受信品質に関する知識に基づいて物理的リソースを割り当てようとはせずに、ある特定のＵＥに割り当てるリソースをほぼランダムに選択することである。この分散化リソース割り当て方法は、局所化モードに比べて関連するシグナリングが少なくて済む（迅速なＣＱＩや迅速な割り当てシグナリングは必要としない）ので、リアルタイムのサービスに最も適するとみられる。
【００４１】
ＯＦＤＭＡベースの無線アクセス方式についての上記の二つの異なるリソース割り当て方法を図１２に示す。局所化リソース割り当てモードを図示する、図の左側の部分から見てとれるように、局所化モードは、送信された信号が利用可能な全スペクトルの一部分を占める連続的なスペクトルを持つことによって特徴づけられる。送信された信号の異なるシンボル伝送速度（異なるデータ伝送速度に対応する）は、局所化信号の異なる帯域幅（時間／周波数分割区画（bins））を意味する。
【００４２】
一方、図の右側の部分から見てとれるように、分散化リソース割り当てモードは、送信された信号がほぼ全システム帯域幅（時間／周波数分割区画（bins））にわたり分散される非連続的スペクトルを持つことよって特徴づけられる。
【００４３】
リンク適応方法
固定ネットワーク・システムとは異なり、無線システムは本質的に急速時変システムである。これは、物理チャネル状態が顕著に経時変化することを意味し、そのため、データ転送が非常に不確かになる。例えば、同軸ケーブルまたは光ファイバでは、干渉のレベルはよく知られており、ただゆっくりと変化する。無線システムでは、無線インタフェースの特性は、移動局の速度と伝播モデルに依存して、ずっと急速な（例えば、数ns)間隔で変化する。これに対抗するために、強度のフェーディングによる損失から回復させるために符号化技術が採用される。強力な符号は存在するが、高いデータ伝送速度はさらなる保護メカニズムを要求する。
【００４４】
ＧＳＭで採用されたが、特にＵＭＴＳで実現されたこのような電力制御技術は、送信電力を受信機の電力に適合させることを頼みにする。この手順を用いて、送信装置は受信機が受けた強度のフェーディングを補正しようとする。電力制御技術の主な欠点は、非常に高速な確実なフィードバック信号を必要とし、送信装置と受信装置の複雑性を増加させる傾向があることである。さらに、電力制御アルゴリズムのまずい実現は、不必要な干渉を発生させる点で、全体のシステム性能に大きな影響を与える可能性がある。
【００４５】
ＵＭＴＳ標準のリリース５仕様に追加された機能として、ＨＳＤＰＡ（高速ダウンリンク・パケット・アクセス）向けのいくつかのリンク適応技術が存在する。ＨＳＤＰＡの目的は、ダウンリンクにおいて高データ伝送速度のサービスをサポートするための手段を提供することである。ＨＳＤＰＡの要件を満たすために、いくつかの新しい技術が導入された。
【００４６】
さらなる適応技術は、リリース５においてＨＳＤＰＡに対して導入された適応変調符号化（ＡＭＣ）である。送信電力を変えることによって強度のフェーディングを補正しようとすることに代えて、受信装置から送信装置へ送られるチャネル品質フィードバック・メッセージに応じて、符号率と使用する変調（例えば、ＱＰＳＫまたは１６ＱＡ）が選択される。このようなチャネル品質指標メッセージ（ＣＱＩ）は、同じ無線状態下で受信装置が一定の確率で受信可能な符号率を指示する。無線状態が悪い場合には、受信機は小さい符号率、すなわち符号化の度合いを多くすることを提示する。他方、無線状態がよいときは、受信機は小さい符号率、すなわち、同一時間内により多くのデータの送信を可能にする、符号化の度合いを少なくすることを提示する。利用可能な複数の異なるレベルが、変調及び符号化セットと呼ばれるセットを形成する。さらに、ＣＱＩメッセージは、受信機側で経験した復号品質に関するものではなく、測定された無線状態に関する情報を与えるだけであることをよく理解されたい。
【００４７】
別の適応技術は、ノードＢ制御によるスケジューリングであり、これではＣＱＩメッセージがＨＳＤＰＡシステムによってセル内のユーザのスケジューリングのために使用される。ＵＥの集団から受信したＣＱＩとノードＢ（ＭＡＣ−ｈｓ）で使用されるスケジューリング・アルゴリズムに応じて、利用可能な物理的リソースが異なるユーザ間に割り振られる。例えば、一組のリソース全部を最良のＣＱＩを持つＵＥに割り当てることができる。この方法は、ノードＢに近いＵＥ群のみスケジューリングしがちになり、セルのはずれにあるＵＥ群にはサービスを提供しない不公平さがあるという犠牲を払って、セル内の最高の全システム・スループット（回線容量）を提供する。
【００４８】
ＨＳＤＰＡで使用される信頼性の低いチャネル上でパケットを送信するシステムにおけるエラー検出及び訂正のためのさらなる一般的な技術は、ハイブリッド自動再送要求（ＨＡＲＱ）と呼ばれる。ハイブリッドＡＲＱは、順方向誤り訂正（ＦＥＣ）とＡＲＱを組み合わせたものである。
【００４９】
ＦＥＣ符号化されたパケットが送信され、受信機がこのパケットを正しく復号できない場合（エラーは通常、巡回冗長検査ビットによってチェックされる）、受信機は当該パケットの再送を要求する。送信信号を構成する情報（一般に、符号ビット／シンボル）により、及び受信機がこの情報をどのように処理するかにより、以下のＨＡＲＱ方式が定義される。
【００５０】
タイプＩ
受信機がパケットを正しく復号できない場合、符号化パケットの情報は廃棄されて、再送が要求される。これは、すべての送信信号が別々に復号されることを暗に示す。一般に、再送信号は初期送信信号と同一の情報（符号ビット／シンボル）を含む。
【００５１】
タイプＩＩ
受信機がパケットを正しく復号できない場合、再送が要求されるが、ここでは受信機は受信エラーとなった符号化パケットの情報をソフト情報（ソフト・ビット／シンボル）として記憶する。これは、受信機上にソフト・バッファが必要であることを暗に示す。再送信号は、前の送信と同じパケットによる情報（符号ビット／シンボル）と同一の情報、部分的に同一の情報、または同一ではない情報から構成され得る。再送信号を受信時、受信機はソフト・バッファから取り出した記憶された情報と今受信した情報とを合成し、合成した情報に基づいてパケットを復号しようとする。パケットを正しく受信する確率は再送信号を受信するたびに増加することから、タイプＩＩの方式はタイプＩの方式よりも洗練されている。この増加は、受信機上にハイブリッドＡＲＱソフト・バッファが必要であるという犠牲を払って生まれる。
【００５２】
ＨＡＲＱタイプＩＩは、チェイス合成法または増加的冗長性の二つの異なる方法で実行され得る。チェイス合成法では、各再送信号は、最初の送信信号またはその一部を繰り返す。増加的冗長性では、各再送信号は、より低い率の符号を作るために母符号から新しい符号ビットを提供する。チェイス合成法は適応変調符号化を強固にするのに十分である一方、増加的冗長性は、追加のメモリーと復号の複雑性という犠牲を払ってではあるが、より高い信号対雑音比の推定エラーとＦＥＲ動作ポイント（すなわち、２回目以後の送信信号に必要とされるより高い確率）において高い初期及びその後の符号率を持つ性能向上の可能性を提供する。増加的冗長性の別の欠点は、ある送信バージョンは、単独であるとみなされる場合、受信機によって復号可能でなくなる可能性がある（自己復号可能でない再送信号）ことである。実際、システマチック・ターボ符号化データ・パケットは、元の情報ビット（システマチック・ビット）と追加のパリティ・ビット（冗長性）を含む。
【００５３】
タイプＩＩＩ
これは、各送信信号は自己復号可能でなければならないという制約を付けた、タイプＩＩのサブセットである。
【００５４】
本発明は、受信した送信信号がソフト合成される、タイプＩＩとタイプＩＩＩに特に関係付けられる。
【００５５】
上に示した従来のＨＡＲＱ方式では、ＡＣＫ（肯定応答）と通常呼ばれる復号成功またはＮＡＣＫ（否定応答）と通常呼ばれる復号失敗を示す送信機への単一ビットのフィードバックだけが送信ごとに必要とされる。ＨＡＲＱシステムの性能をさらに向上させるために集中的な研究が行われてきた。研究されてきた一つの研究分野は、受信パケットの信頼性に基づくＨＡＲＱタイプＩＩの方式であり、この方式では受信機によって算定された受信パケットの信頼性情報が不成功パケットの再送信号を形成するために考慮される。この信頼性情報を生成する一つの可能な方法は、デコーダの出力における各情報ビットの対数尤度比の平均の大きさを計算することである。この情報は、ＮＡＣＫ信号と共に、再送すべきビットの量とひいては位置を送信装置に指示するために使用することができる。
【００５６】
このアプローチの主要な問題は、この方法により必要になるシグナリングの量が法外であるということである。この方法を簡易にするために、再送すべき明確なビット数を指示する代わりに、復号のレベルを送信機にシグナリングにより通知するために複数のＮＡＣＫレベルを使用することができる（例えば、１、２、３）。複数レベルのＮＡＣＫメッセージは送信機側で解釈される必要があるので、複数レベルのＮＡＣＫメッセージのレベルの数とそれらの厳密な定義が受信機側と送信機側の双方で知られていなければならない。複数レベルのＮＡＣＫメッセージは、マルチレベル変調技術（例えば、ＱＰＳＫ、１６ＱＡＭ）での異なるコンステレーション点に異なるレベルをマッピングすることによってＬ１メッセージとすることもできるし、あるいはＬ２メッセージとすることもできる。第二のオプションでは、異なるレベルを異なるコードワードで表現される（例えば、第１レベル：00001、第２レベル：00010、第３レベル：00100、など）。さらに、信頼性情報を、例えば、ＣＱＩといった他の情報と合同で符号化することができ、その結果生じる符号化データはＣＲＣ（巡回冗長検査）で保護され得る。Ｌ２メッセージの利点は、メッセージの信頼性の増加である。しかし、符号化／復号化処理とＣＲＣチェックは、多少の処理遅延を伴う演算処理コストが高くつく。
【００５７】
さらなる簡易化が、受信機は原則的にパケットが復号されていないことを示す２つのレベル（ＮＡＣＫ及びＬＯＳＴ）―ここで、ＬＯＳＴは次の再送信号との合成は受信機側では考えられないほどの受信パケットのひどい破損を示す―を持つという形で提案された。この場合、送信機はパケットの自己復号可能なバージョンを送信することになる。この技法の利点はその簡易さとその強固さであるが、送信機は、ＮＡＣＫが受信機から送信される場合に再送信号をどのように形成するかについての情報を全く与えられない。
【００５８】
前述したように、複数レベルのＮＡＣＫのフィードバックは有益である、というのはこれはＨＡＲＱプロトコルを送信するエンティティ（実体）が、データ・パケットのすでに受信した送信信号の復号品質に基づいて、パケット再送信号を調整できるようにするからである。これは次には、送信効率と全体のデータ・スループット（回線容量）を向上させる。
【００５９】
しかし、正確な複数レベルのＮＡＣＫ信号の生成は、受信側で大量な演算を必要とする。これは受信エンティティ（実体）での電力消費を増加させがちであり、そのことが、受信エンティティが移動端末である場合には、重大な問題になる可能性がある。演算要求量の増加はさらに、受信側での処理遅延を増加させがちであり、そのことが、リアルタイムのサービスなどの遅延の要求条件が非常に厳しいサービスにとって負担になる可能性があり、さらに達成可能なデータ伝送速度に上限を課す可能性がある。実際、非常に高速な応答メカニズムは、送信機が一定の時間内により多くのパケットを処理することを可能にする。
【００６０】
さらに、複数レベルのＮＡＣＫフィードバック再送プロトコルは、同じ送信電力を仮定した場合、単純なＡＣＫ／ＮＡＣＫフィードバック・プロトコルよりも本質的に信頼性が低い。実際、２つの値（ＡＣＫまたはＮＡＣＫ）を識別しなければならないことに代えて、送信機側は数個の値（例えば、ＡＣＫ、ＮＡＣＫ＿１、ＮＡＣＫ＿２、ＮＡＣＫ＿３）を分けなければならない。フィードバック・メッセージの送信電力が同じである場合、フィードバック・レベルを誤って解釈する可能性は、従来のＡＣＫ／ＮＡＣＫフィードバック方式よりも高くなる。フィードバック・メッセージの誤った解釈は性能損失に直接つながるので、信頼性の問題は重大である。特に、ＮＡＣＫをＡＣＫにＡＣＫをＮＡＣＫに誤って解釈することは、特別な機能（例えば、ＨＳＤＰＡにおけるＲＬＣ）によって検出され修正される必要があるプロトコル・エラーを引き起こすという点で深刻である。正常な環境下では、送信装置は十分によい信頼度でＮＡＣＫ信号を復号できるであろう。しかし、例えば、セル干渉が急に増加した場合に、複数レベルのＮＡＣＫの復号エラーの可能性も増加する。
【００６１】
同様に、セルのはずれにいるＵＥまたは他の同時に発生するアップリンク・データ・トラヒックにより電力が制限されているＵＥは、複数レベルのＮＡＣＫメッセージを所要の電力で送信するために利用可能な十分な電力を持てない可能性がある。減少した電力レベルでのフィードバック・メッセージ送信によって、ノードＢにおいてＨＡＲＱフィードバックを誤って復号する可能性が高くなる。この影響は、ＨＡＲＱフィードバック・メッセージを送信する両方の手段に、すなわちＬ１信号またはＬ２信号に当てはまる―Ｌ１信号のほうがこの問題により影響を受けやすいが―ことに留意すべきである。
【００６２】
したがって、複数レベルのＮＡＣＫシグナリングはシステム・スループット（回線容量）の達成という面では利をもたらすが、それに付随した欠点により、リアルタイムのサービスまたは小さいパケットを使用するサービスなどのある種のサービスでは、または、例えば、送信電力が制限されているといったある状況下では、潜在的な利点が相殺される。
【非特許文献１】3GPP TR 25.401: "UTRAN Overall Description"
【非特許文献２】Holma et al. "WCDMA for UTMS", Third Edition, Wiley & Sons, Inc., October 2004, Chapter 5
【発明の開示】
【００６３】
本発明の目的は、送信信号の強固さを提供すると共に全体の送信効率を向上させるために、ハイブリッド自動再送要求（ＨＡＲＱ）再送プロトコルの応答モードを設定するための方法を提案することである。
【００６４】
上記の目的は、独立請求項の主題によって達成される。本発明の有利な実施形態は、従属請求項の主題である。
【００６５】
本発明の一つの態様は、ＨＡＲＱ再送プロトコルの応答モードを設定可能にすることである。複数レベルのＮＡＣＫ応答モードまたは従来のＡＣＫ／ＮＡＣＫ応答モードが、サービス品質のパラメータまたは物理層のパラメータに応じて選択可能である。
【００６６】
本発明の一つの実施形態は、無線アクセス・ネットワーク中の制御エンティティをさらに含む無線通信システムにおいて、送信エンティティから受信エンティティへ提供されるサービスのデータを含むデータ・パケットの配信に応答するために使用されるＨＡＲＱ再送プロトコルの応答モードを設定するための方法を提供する。当該方法は、サービス品質の属性または物理層のパラメータの少なくとも一つに基づいて、制御エンティティがそれによればＨＡＲＱ再送プロトコルが動作可能である第１及び第２の応答モードの一つを設定すること含んでなり、ここで設定された応答モードはデータ・パケットの配信に応答するために受信エンティティによって使用されることになる。当該方法は、送信エンティティから受信エンティティへデータ・パケットを送信すること、受信エンティティがデータ・パケットを受信して復号すること、及び前記データ・パケットの受信に応えて、設定された応答モードによる応答メッセージを受信エンティティが送信することをさらに含んでなる。データ・パケットが受信エンティティによってうまく復号されなかった場合の第１の応答モードでの応答メッセージは、受信エンティティでデータ・パケットを復号する際に得られたデータ・パケットの複数の復号品質レベルの一つを示し、データ・パケットが受信エンティティによってうまく復号されなかった場合の第２の応答モードでの応答メッセージはデータ・パケットの復号失敗を示す。
【００６７】
本発明のさらに別の実施形態では、制御エンティティは設定された応答モードを送信エンティティと受信エンティティにシグナリングにより通知する。
【００６８】
この実施形態の変形においては、制御エンティティは送信エンティティに含まれ、設定ステップは送信エンティティによって実行され、上記方法は送信エンティティから受信エンティティへ設定された応答モードをシグナリングにより通知することをさらに含んでなる。
【００６９】
この実施形態のさらに別の変形においては、制御エンティティは受信エンティティに含まれ、設定ステップは受信エンティティによって実行され、上記方法は受信エンティティから送信エンティティへ設定された応答モードをシグナリングにより通知することをさらに含んでなる。
【００７０】
本発明のある実施形態によれば、設定された応答モードは、無線ベアラ確立手順及び／または無線ベアラ再設定手順中で交換される無線ベアラ設定メッセージにて通知される。
【００７１】
本発明のさらに別の実施形態によれば、第１の応答モードは第１のＨＡＲＱプロセスに属させ及び／または第２の応答モードは第２のＨＡＲＱプロセスに属させ、サービスを送信するために第１及び第２のＨＡＲＱプロセスの一つが設定された応答モードに基づいて選択される。
【００７２】
さらに、上記の物理層のパラメータは、サービスを送信するために使用される標準的なデータ・パケットのサイズを含んでなり、標準的なデータ・パケットのサイズが第１の所定値よりも大きいときには第１の応答モードが設定され、標準的なデータ・パケットのサイズが前記第１の所定値よりも小さいときには第２の応答モードが設定される。
【００７３】
本発明の特に有利な実施形態においては、上記のサービス品質のパラメータが送信エンティティから受信エンティティへ提供されるサービスのビット・レートであり、ビット・レートが第２の所定値よりも大きいときには第１の応答モードが設定され、ビット・レートが前記第２の所定値よりも小さいときには第２の応答モードが設定される。
【００７４】
本発明による方法のさらに別の実施形態によれば、第１の応答モードが設定され、当該方法は、受信エンティティの送信電力レベルが第３の所定値より高いときには、受信エンティティが設定された第１の応答モードから第２の応答モードへ切り替えることと、受信エンティティの送信電力レベルが第３の所定値より小さいときには、受信エンティティが第２の応答モードから第１の応答モードへ切り替えて元に戻すことをさらに含んでなる。
【００７５】
さらに、当該方法は、第１の応答モードから第２の応答モードへの切り替え及び／または第２の応答モードから第１の応答モードへ戻す切り替えの後、受信エンティティが応答モードを送信エンティティにシグナリングにより通知することを含む。
【００７６】
本発明による方法の別の実施形態によれば、第１の応答モードが設定され、当該方法は、応答メッセージを運ぶチャネル上の干渉レベルの情報を送信エンティティが取得することをさらに含んでなる。送信エンティティは、送信エンティティで取得された干渉レベルが第４の所定値より大きいときには、設定された第１の応答モードから第２の応答モードへ切り替えることができ、送信エンティティで取得された干渉レベルが第４の所定値より小さいときには、第２の応答モードから第１の応答モードへ切り替えて戻すことができる。
【００７７】
本発明による方法のさらに別の実施形態によれば、第１の応答モードが設定され、当該方法は、受信エンティティによって送信された応答メッセージを送信エンティティが復号することをさらに含んでなる。送信エンティティは、応答メッセージの復号品質が第５の所定値より小さいときには、設定された第１の応答モードから第２の応答モードへ切り替えることができ、応答メッセージの復号品質が第５の所定値より大きいときには、第２の応答モードから第１の応答モードへ切り替えて戻すことができる。
【００７８】
さらに、第１の応答モードから第２の応答モードへの切り替え及び／または第２の応答モードから第１の応答モードへ戻す切り替えの後、送信エンティティは応答モードを受信エンティティにシグナリングにより通知する。
【００７９】
本発明の一つの実施形態によれば、送信エンティティは無線アクセス・ネットワーク内の基地局であってもよく、受信エンティティは移動端末であってもよい。本発明の代替的な実施形態によれば、送信エンティティが移動端末であってもよく、受信エンティティが無線アクセス・ネットワーク内の基地局であってもよい。したがって、本発明による方法は、アップリンクまたはダウンリンクのデータ・パケット送信の両方に適用可能である利点を提供する。
【００８０】
本発明のさらに別の実施形態では、物理層のパラメータは、移動端末のソフト・ハンドオーバ状態をさらに含んでなり、移動端末がソフト・ハンドオーバ中で第１の基地局から第２の基地局へハンドオーバされているときには、第２の応答モードが設定される。
【００８１】
本発明の別の態様によれば、無線アクセス・ネットワーク中の制御エンティティをさらに含む無線通信システムにおいて、送信エンティティから受信エンティティへ提供されるサービスのデータを含むデータ・パケットの配信に応答するために使用されるＨＡＲＱ再送プロトコルの応答モードを設定するための方法が提供される。当該方法は、送信エンティティから受信エンティティへのデータ・パケットの送信に使用される無線リソース割り当てタイプに基づいて、制御エンティティがそれによればＨＡＲＱ再送プロトコルが動作可能である第１及び第２の応答モードの一つを設定することを含んでなり、ここで設定された応答モードはデータ・パケットの配信に応答するために受信エンティティによって使用されることになる。さらに、当該方法は、送信エンティティから受信エンティティへデータ・パケットを送信すること、受信エンティティがデータ・パケットを受信して復号すること、及び前記データ・パケットの受信に応えて、設定された応答モードによる応答メッセージを受信エンティティが送信することをさらに含んでなる。データ・パケットが受信エンティティによってうまく復号されなかった場合の第１の応答モードでの応答メッセージは、受信エンティティでデータ・パケットを復号する際に得られたデータ・パケットの複数の復号品質レベルの一つを示し、データ・パケットが受信エンティティによってうまく復号されなかった場合の第２の応答モードでの応答メッセージはデータ・パケットの復号失敗を示す。
【００８２】
本発明のさらに別の実施形態によれば、局所化無線リソース割り当てタイプが使用されるときには第１の応答モードが設定され、分散化無線リソース割り当てタイプが使用されるときには第２の応答モードが設定される。
【００８３】
本発明のさらに別の実施形態は、送信エンティティ、受信エンティティ及び無線アクセス・ネットワーク中の制御エンティティを具備する無線通信システムを提供し、前記無線通信システムは、送信エンティティから受信エンティティへ提供されるサービスのデータを含むデータ・パケットの配信に応答するために使用されるＨＡＲＱ再送プロトコルの応答モードを設定するようになされる。制御エンティティは、サービス品質の属性または物理層のパラメータの少なくとも一つに基づいて、それによればＨＡＲＱ再送プロトコルが動作可能である第１及び第２の応答モードの一つを設定するための設定手段を具備し、ここで設定された応答モードはデータ・パケットの配信に応答するために受信エンティティによって使用されることになる。送信エンティティは、データ・パケットを受信エンティティへ送信するための送信手段を具備し、受信エンティティは、送信されたデータ・パケットを受信して復号するための受信及び復号手段と、前記データ・パケットの受信に応えて、設定された応答モードによる応答メッセージを受信エンティティが送信するための送信手段を具備する。データ・パケットが受信エンティティによってうまく復号されなかった場合の第１の応答モードでの応答メッセージは、受信エンティティでデータ・パケットを復号する際に得られたデータ・パケットの複数の復号品質レベルの一つを示し、データ・パケットが受信エンティティによってうまく復号されなかった場合の第２の応答モードでの応答メッセージはデータ・パケットの復号失敗を示す。
【００８４】
本発明の別の実施形態は、送信エンティティ、受信エンティティ及び無線アクセス・ネットワーク中の制御エンティティを具備する代替的な無線通信システムを提供し、前記無線通信システムは、送信エンティティから受信エンティティへ提供されるサービスのデータを含むデータ・パケットの配信に応答するために使用されるＨＡＲＱ再送プロトコルの応答モードを設定するようになされる。制御エンティティは、送信エンティティから受信エンティティへのデータ・パケットの送信に使用される無線リソース割りタイプに基づいて、それによればＨＡＲＱ再送プロトコルが動作可能である第１及び第２の応答モードの一つを設定するための設定手段を具備し、ここで設定された応答モードはデータ・パケットの配信に応答するために受信エンティティによって使用されることになる。送信エンティティは、データ・パケットを受信エンティティへ送信するための送信手段を具備し、受信エンティティは、送信されたデータ・パケットを受信して復号するための受信及び復号手段と、前記データ・パケットの受信に応えて、設定された応答モードによる応答メッセージを受信エンティティが送信するための送信手段を具備する。データ・パケットが受信エンティティによってうまく復号されなかった場合の第１の応答モードでの応答メッセージは、受信エンティティでデータ・パケットを復号する際に得られたデータ・パケットの複数の復号品質レベルの一つを示し、データ・パケットが受信エンティティによってうまく復号されなかった場合の第２の応答モードでの応答メッセージはデータ・パケットの復号失敗を示す。
【００８５】
上記の無線通信システムの両方とも、上述した本発明の様々な実施形態及び変形のうちの一つによるＨＡＲＱ再送プロトコルの応答モードを設定するための方法を実行するようになされたさらに追加される手段を含み得る。
【発明を実施するための最良の形態】
【００８６】
以下のパラグラフでは、本発明の様々な実施形態を説明する。典型的な例を示すという目的でのみ、実施形態の大部分は、ＵＭＴＳ通信システムに関連して概説される。また、以下の節で使用される専門用語は、主にＵＭＴＳの用語に関係する。これは、本発明はこの種の通信ネットワークで有利に適用することができるからである。しかし、ＵＭＴＳアーキテクチャに関連して使用する用語と実施形態の説明は、本発明の原理と概念を上記システムに限定するという意味合いはない。
【００８７】
また、前述の背景技術の節で述べた詳細な説明は、以下に説明する主にＵＭＴＳに特有の典型的な実施例をよりよく理解してもらうためのものにすぎず、移動通信ネットワークにおけるプロセス及び機能のここで述べた特定の実現に本発明の基礎をなす広範な概念を限定するものと理解すべきではない。
【００８８】
特に、従来技術のＵＴＲＡＮリリース５／６のアーキテクチャを詳細に説明したが、本発明はこの従来技術のアーキテクチャに限定されず、以下に説明するＵＴＲＡＮの将来の進化にも適用可能であることに留意すべきである。
【００８９】
本発明の一つの態様は、無線ベアラごとにＨＡＲＱ再送プロトコルの応答モードを設定することである。代替的に、この応答モードの設定はＨＡＲＱプロセスごとに行うこともできる、すなわち、フィードバック・モードを対応するＨＡＲＱプロセスに関連付ける。これらの設定モードを両立させることも可能である。したがって、設定は物理層のパラメータまたはＱｏＳ属性に基づく。
【００９０】
本発明の別の態様によれば、ＨＡＲＱ再送プロトコルの応答モードは設定可能である、すなわち、複数レベルのＮＡＣＫフィードバックまたは従来のＡＣＫ／ＮＡＣＫフィードバック・モードが、例えば、データ・パケット・サイズ、データのビットレートなどのサービス品質のパラメータ、移動端末のソフト・ハンドオーバ状態、または無線アクセス・ネットワークでの通信に使用されるリソース割り当てモードに基づいて選択される。
【００９１】
本発明のさらに別の態様によれば、送信エンティティ及び／または受信エンティティは、例えば、受信エンティティの送信電力レベル、応答メッセージを運ぶチャネル上の干渉レベル、または送信エンティティでの応答メッセージの復号品質に応じて、設定されたフィードバック・モードから別のフィードバック・モードへの切り替えを行なえる。
【００９２】
無線通信システムの送信エンティティと受信エンティティが考案される。送信エンティティは、サービスのデータ・パケットを受信エンティティへ送信する。受信エンティティは、サービスのデータ・パケットを受信して復号する。データ・パケットの受信に応えて、受信したデータ・パケットを復号した後、受信エンティティは送信エンティティに応答メッセージを送信することによって、データ・パケットの受信に対して応答する。受信エンティティは、送信エンティティから受信エンティティへ提供されるサービスのデータ・パケットの配信に応答するためにＨＡＲＱ再送プロトコルを使用する。無線通信システムは、無線アクセス・ネットワーク中の制御エンティティをさらに含んでなる。
【００９３】
本発明のある実施形態によれば、送信エンティティから受信エンティティへ提供されるサービスのデータ・パケットの配信に応答するために使用されるＨＡＲＱ再送プロトコルの応答モードを設定可能にすることができる。制御エンティティは、サービス品質の属性または物理層のパラメータの少なくとも一つに基づいて、それによればＨＡＲＱ再送プロトコルが動作可能である第１及び第２の応答モードの一つを設定する、ここで設定された応答モードはデータ・パケットの配信に応答するために受信エンティティによって使用されることになる。
【００９４】
受信エンティティによって送信エンティティへ送信される応答メッセージは、設定された応答モードに従って生成される。具体的には、データ・パケットが受信エンティティによって首尾よく符号化されるとき、肯定応答メッセージＡＣＫが受信エンティティによって送信エンティティへ送信され、これにより送信されたデータ・パケットの受信と受信エンティティによるデータ・パケットの復号処理の成功を確認する。
【００９５】
しかし、データ・パケットが受信エンティティによってうまく復号されなかった場合、応答メッセージが受信エンティティによって送信エンティティへ送信されるが、この応答メッセージは設定された応答モードに従って生成される。第１の応答モードでは、受信エンティティでデータ・パケットを復号する際に得られたデータ・パケットの複数の復号品質レベルの一つを示す応答メッセージが、受信エンティティによって送信エンティティへ送信される。第２の応答モードでは、データ・パケットが受信エンティティによってうまく復号されなかったとき、データ・パケットの復号失敗を示す応答メッセージ、例えば、否定応答ＮＡＣＫが受信エンティティによって送信エンティティへ送信される。
【００９６】
制御エンティティは、無線通信システムの無線アクセス・ネットワーク内に含まれるネットワーク要素のどれかに存在できる。通常、制御エンティティは、無線アクセス・ネットワークにおける無線リソース制御（ＲＲＣ）を終端するエンティティ、例えば、現在のＵＭＴＳシステムにおけるＲＮＣである。制御エンティティが、サービス品質の属性または物理層のパラメータに基づいて、第１及び第２の応答モードの一つを設定したとき、制御エンティティは設定された応答モードを送信エンティティへシグナリングにより通知する。これにより、送信エンティティは、受信エンティティにおいてデータ・パケットの配信に応答するために使用される設定された応答モードを承知する。送信エンティティが基地局、すなわちＵＭＴＳでのノードＢであり、受信エンティティが移動端末、すなわち、ＵＭＴＳでのＵＥである場合、制御エンティティはＲＮＣに存在することができ、設定された応答モードをノードＢへＮＢＡＰシグナリングを用いて通知する。さらに、制御エンティティは、応答モードをＵＥへＲＲＣシグナリングを用いて通知する。したがって、送信エンティティと受信エンティティの双方とも、送信エンティティから受信エンティティへ提供されるサービスのデータを含むデータ・パケットの配信に応答するために使用されるべく設定された応答モードを承知する。
【００９７】
上述した例は、送信エンティティが移動端末であり、受信エンティティが基地局である場合にも適用することができる。
【００９８】
本発明の別の実施形態では、制御エンティティは送信エンティティに搭載されると予見され、これによりＨＡＲＱ再送プロトコルの応答モードの設定は送信エンティティによって実行される。さらに送信エンティティは、設定された応答モードを受信エンティティへシグナリングにより通知し、これにより、受信エンティティは送信エンティティによって送信されたデータ・パケットの配信に応答するために第１または第２の応答モードのどちらが使用されることになるのかを知る。
【００９９】
本発明の代替的な実施形態では、制御エンティティは受信エンティティに置かれ、これによりＨＡＲＱ再送プロトコルの応答モードの設定は、したがって受信エンティティによって実行される。応答モードを設定後、受信エンティティは設定された応答モードを送信エンティティへシグナリングにより通知し、これにより送信エンティティは設定された応答モードを承知する。
【０１００】
それによればＨＡＲＱ再送プロトコルが動作可能である第１及び第２の応答モードの一つを設定することは、サービス品質の属性または物理層のパラメータの少なくとも一つに基づいて行われる。
【０１０１】
ここで使用されるサービス品質の属性は、例えば、送信エンティティから受信エンティティへ提供されるサービスのビットレートである。さらに広くは、この用語はサービスを特徴づけるいずれかのパラメータ、例えば、遅延が重大な問題になるサービスにおける最大許容遅延、または対象のサービスのデータ伝送速度、個々には、ビットレートなどであり得る。
【０１０２】
物理層のパラメータという用語は、物理層に知られているパラメータを定義する。物理層のパラメータは、例えば、トランスポートブロック（transport block）中に使用されるデータ・パケットのサイズである。データ・パケットのサイズは、ＭＡＣ層によって決定され、物理層に通知されるので、物理層に知られている。このデータ・パケットのサイズは、本出願では標準的なデータ・パケットのサイズとして定義されるが、これはＭＡＣ層は、チャネル品質に応じてトランスポートブロック中に使用されるデータ・パケットのサイズを変えるように適合されるからである。高い品質のチャネルでは大きなデータパケットを送信できるが、チャネル品質が低いときにはより小さいパケット・サイズのデータ・パケットを送信することがより望ましい。物理層のパラメータの別の例は、ＵＥのソフト・ハンドオーバ状態、すなわち、ＵＥがソフト・ハンドオーバ中である否かであってもよい。
【０１０３】
送信エンティティが前に受信したデータ・パケットの送信信号の復号品質に基づいてデータ・パケットの再送信号を調整可能にするように、受信エンティティは、従来のＡＣＫ／ＮＡＣＫフィードバックまたは複数レベルのＡＣＫ／ＮＡＣＫフィードバックのいずれかをシグナリングにより通知するように構成され得る。
【０１０４】
サービス特性によるフィードバック・モードの設定は、以下に説明するように、異なる抽象概念レベルで行うことができる。
【０１０５】
本発明の一つの実施形態によれば、ＨＡＲＱフィードバック・モードは無線ベアラごとに設定される。
【０１０６】
データ送信を開始する前に無線ベアラを確立し、すべての層をそれに応じて設定する。通常、無線ベアラ確立手順が新しい無線ベアラを確立するために使用される。アプリケーション／サービスのサービス品質（ＱｏＳ）の属性に基づいて、ＲＲＣエンティティがそのアプリケーション／サービスのデータを運ぶために最も適切な無線ベアラ・パラメータを決定する。
【０１０７】
サービスのタイプにより、複数レベルのフィードバック・モードを有する信頼性に基づくＨＡＲＱ再送プロトコルを使用することがより有益である場合、またはそれほど有益ではない場合がある。高いデータ伝送速度を使用し、大きなパケット・サイズを持つデータパケットを使用するサービスでは、複数レベルの応答モードを使用してデータ・パケットの再送を実行することは有利である。したがって、この場合、複数レベルのフィードバックは送信効率を大幅に向上させ得る。
【０１０８】
しかし、遅延が重大な問題になるサービスまたは低いデータ伝送速度のサービス、例えば、ＶｏＩＰというような他のサービスでは、データ・パケットの配信に応答するための複数レベルのフィードバック・モードの使用がスループット（回線容量）を向上させるために有効に利用されない可能性がある。その場合には、普通のＡＣＫ／ＮＡＣＫフィードバック・モードを使用することがより有益である可能性がある。さらに、追加のシグナリング・オーバヘッドが複数レベルのＡＣＫ／ＮＡＣＫ 応答モードに伴うし、またフィードバック・シグナリングの信頼性が低下するので、複数レベルのＮＡＣＫフィードバック・モードは、従来のＡＣＫ／ＮＡＣＫフィードバック・モードよりも適応性は下がると思われる。
【０１０９】
考慮されたサービスとそれに対応するＱｏＳ属性に応じて、制御エンティティはＨＡＲＱフィードバック・モードを設定することができる。このフィードバック・モードは、例えば、無線ベアラ確立手順中に送信され得る、無線ベアラ設定メッセージでシグナリングにより通知することができる。制御エンティティ、例えば、ＲＲＣエンティティは、設定されたＨＡＲＱ応答モードを、例えば、無線ベアラ設定メッセージ内でＵＥに通知できる。送信及び受信エンティティの両方が無線ベアラに関連付けられたフィードバック・モードを知る必要があるので、ＲＲＣエンティティは、フィードバック・モードをＮＢＡＰシグナリングを介して、すなわち、無線リンク設定メッセージを使用してノードＢにも通知する。
【０１１０】
無線ベアラの特性はアクティブ接続の最中に変化することがあるので、無線ベアラのパラメータを再設定するために無線ベアラ再設定手順が使用できる。したがって、設定されたフィードバック・モードは、本発明のある実施形態によれば再設定可能である。例えば、ＲＲＣエンティティは、再設定されたフィードバック・モードをＵＥとノードＢに無線ベアラ再設定手順（ＲＲＣメッセージ)または無線リンク再設定手順（ＮＢＡＰメッセージ）内で通知できる。
【０１１１】
それぞれに対して設定された異なるフィードバック・モードを持つ二つの無線ベアラのデータが同じＨＡＲＱプロセス中に送信される場合、異なるＨＡＲＱ応答モードを持つ無線ベアラが同じＨＡＲＱプロセスに多重化するのを防ぐことが考えられ得る。一つの実施例では、ＲＲＣエンティティは、対応するＨＡＲＱプロセスに関連付けられる同一トランスポートブロック中に多重化できるデータ・パケットを持ち得る無線ベアラはどれであるかを示す多重化リストを定義する。
【０１１２】
無線ベアラごとに応答モードを設定する方式を図１３に示す。送信エンティティはノードＢに存在するように選択され、受信エンティティはユーザ装置ＵＥに含まれる。制御エンティティは、無線ベアラへの応答モードの割り当てを示す設定メッセージを送信エンティティへ送信する。制御エンティティは、この割り当て情報を設定メッセージにて受信エンティティにも通知する。図１３に示した例では、複数レベルのＮＡＣＫフィードバック・モードが、例えば、無線ベアラＢに割り当てられる。一方、従来のＡＣＫ／ＮＡＣＫ応答モードが無線ベアラＡとＣに割り当てられる。
【０１１３】
本例ではノードＢに存在する送信エンティティは受信エンティティへデータを送信し、本例ではＵＥに存在する受信エンティティは、無線ベアラに割り当てられた設定された応答モードによりフィードバック・メッセージをノードＢへ送信する。例えば、無線ベアラＡまたはＣによって送信されたデータは、従来のＡＣＫ／ＮＡＣＫフィードバック・モードを使用して応答される一方、無線ベアラＢによって送信されたデータは、複数レベルのＮＡＣＫフィードバック・モードを使用して応答される。
【０１１４】
制御エンティティは送信エンティティ及び受信エンティティとは異なる独立の機能エンティティとして表現されているが、本発明の別の実施形態によれば、制御エンティティが送信エンティティ内または受信エンティティ内のどちらかに含まれてもよい。制御エンティティが送信エンティティに含まれる場合、送信エンティティは、無線ベアラに対する応答モードの割り当てを受信エンティティにシグナリングにより通知する。代替的に、制御エンティティは、無線アクセス・ネットワークの別のネットワーク要素、例えばＲＮＣに含まれてもよい。
【０１１５】
本発明のさらに別の実施形態によれば、ＨＡＲＱフィードバック・モードはＨＡＲＱプロセスごとに設定することができる。
【０１１６】
図１４は、制御エンティティがＲＲＣを終端し、ノードＢとＵＥとは異なるネットワーク要素に存在する場合の例を示す。送信エンティティはノードＢに含まれ、受信エンティティはＵＥに置かれる。制御エンティティは、応答モードをＨＡＲＱプロセスに属させて、ＨＡＲＱプロセスへの応答モードの割り当てを設定メッセージにて送信エンティティに通知する。さらに、制御エンティティは、この割り当て情報を設定メッセージを用いて受信エンティティにも通知する。
【０１１７】
第１の応答モード、例えば、複数レベルのＮＡＣＫフィードバック・モードが第１のＨＡＲＱプロセスに割り当てられ、第２の応答モード、例えば、従来のＡＣＫ／ＮＡＣＫ応答モードが第２のＨＡＲＱプロセスに割り当てられる。代替的に、一つの応答モード をすべてのＨＡＲＱプロセスに属させることもできる。
【０１１８】
図１４に示した例では、従来のＡＣＫ／ＮＡＣＫ応答モードがＨＡＲＱプロセス＃１と＃２に割り当てられる一方、複数レベルのＮＡＣＫ応答モードがＨＡＲＱプロセス＃３に割り当てられる。送信エンティティから受信エンティティへ送信されたデータに対して、その受信がＨＡＲＱプロセス＃１と＃２により応答されるとき、受信エンティティによって送信される応答メッセージは、従来のＡＣＫ／ＮＡＣＫフィードバック・モードを使用して生成される。他方、送信エンティティから受信エンティティへ送信されたデータに対して、その受信がＨＡＲＱプロセス＃３により応答されるとき、受信エンティティによって送信される応答メッセージは、複数レベルの ＮＡＣＫフィードバック・モードを使用して生成される。
【０１１９】
この実施形態では、ＲＲＣエンティティは送信エンティティ及び受信エンティティとは異なるネットワーク要素に存在する別個のエンティティとして表現されているが、本発明の別の実施形態によれば、制御エンティティが送信エンティティまたは受信エンティティに含まれてもよい。制御エンティティが送信エンティティ、例えば、ノードＢに含まれる場合、ノードＢは割り当て情報を受信エンティティ、すなわち、本例ではＵＥにシグナリングにより通知し、これによりＵＥは各ＨＡＲＱプロセスに関連付けられた応答モードを承知する。
【０１２０】
ＨＡＲＱ応答モードをＨＡＲＱプロセスごとに設定することは、応答モードを無線ベアラごとに設定することよりもさらに有利になり得る。実際、特定のＨＡＲＱプロセスが複数レベルのフィードバックを利用できる一方、その他のＨＡＲＱプロセスでの送信については、従来のＡＣＫ／ＮＡＣＫフィードバックが設定される。データ送信に使用されたＨＡＲＱプロセスは、例えば、ＨＳＤＰＡでのようにＨＡＲＱプロセスＩＤの明確なシグナリングによって、またはＨＳＵＰＡでのように送信タイミングによって受信エンティティに知られるので、フィードバック・モードも知られ、受信エンティティはしたがって正しいタイプのフィードバックを生成できる。サービスのＱｏＳ属性に応じて、ＲＲＣエンティティは各ＨＡＲＱプロセスのＨＡＲＱフィードバック・モードを個々に設定し、図１４に示すように、あるＨＡＲＱプロセスは複数レベルの ＮＡＣＫフィードバック・モードに設定することができる。
【０１２１】
さらに、ＲＲＣエンティティは、ＨＡＲＱプロセスに対する無線ベアラのマッピングを明示的に設定することができる。このマッピングは送信及び受信エンティティの両方によって知られなければならないので、ＲＲＣエンティティはこのマッピングをＵＥとノードＢに、例えば、ＲＲＣ及びＮＢＡＰシグナリングを介してそれぞれ通知する。制御エンティティが、送信及び受信エンティティを含む各ネットワーク要素とは異なるネットワーク要素に存在する場合、該当のＲＲＣ及びＮＢＡＰメッセージに新たな情報要素の追加が必要となる可能性がある。
【０１２２】
本発明の別の実施形態によれば、ＨＡＲＱフィードバック・モードはユーザ装置のソフト・ハンドオーバ状態に基づいて設定される。
【０１２３】
移動端末が、ソフトハンドオーバ中で第１の基地局から第２の基地局へハンドオーバされているときには、第２の応答モード、すなわち、従来のＡＣＫ／ＮＡＣＫ応答モードが設定される。
【０１２４】
複数レベルのＨＡＲＱフィードバックによって与えられた情報は、高データ伝送速度の送信では最も有効に利用することができるので、複数レベルのフィードバック・モードを使用する信頼性に基づくＨＡＲＱ再送プロトコルは、ＵＥがソフト・ハンドオーバ中でない状況に最も適する。ソフト・ハンドオーバ中のユーザ・データ伝送速度はセル境界にあるときよりも低いと予想されるので、本発明のある実施形態によるフィードバック・モードはユーザのソフト・ハンドオーバ状態に基づいて設定される。ユーザ装置のソフト・ハンドオーバ状態を送信及び受信エンティティの両方が認識するので、両方のエンティティはしたがって再送に使用されるべきフィードバック・モードを知る。
【０１２５】
本発明の別の態様によれば、ＨＡＲＱフィードバック・モードは、無線アクセス・ネットワークで使用されるリソース割り当て方法に基づいて設定することができる。
【０１２６】
制御エンティティは、送信エンティティから受信エンティティへのデータ・パケットの送信に使用される無線リソース割り当てタイプに基づいて、それによればＨＡＲＱ再送プロトコルが動作可能である第１及び第２の応答モードの一つを設定する。
【０１２７】
データ・パケットがうまく復号されなかった場合、第１の応答モードにより受信エンティティによって送信された応答メッセージは、受信エンティティでデータ・パケットを復号する際に得られたデータ・パケットの複数の復号品質レベルの一つを示す。第２の応答モードによれば、受信エンティティによってデータ・パケットがうまく復号されなかった場合、第２の応答モードでの応答メッセージはデータ・パケットの復号失敗を示す。
【０１２８】
本発明のある実施形態では、発明の背景の節でＯＦＤＭ無線アクセス・ネットワークに関して定義した、局所化無線リソース割り当てタイプが、送信エンティティから受信エンティティへのデータ・パケットの送信に使用されるときには、第１の応答モード、複数レベルのＮＡＣＫ応答モードが設定される。他方、発明の背景の節でＯＦＤＭ無線アクセス・ネットワークに関して定義した、分散化無線リソース割り当てタイプがデータ・パケットの送信に使用されるときには、第２の応答モード、従来のＡＣＫ／ＮＡＣＫフィードバック・モードが設定される。
【０１２９】
局所化リソース割り当て方法は、ＣＱＩリポーティングなどの非常に正確なリンク適応を用いることにより周波数スケジューリング・ゲインから利点を得ようとするから、複数レベルのＮＡＣＫフィードバック・モードに最もよく適合する、というのはこのフィードバック・モードも受信したＨＡＲＱフィードバックに基づいて再送を調整することによって送信効率を向上させようとするからである。
【０１３０】
他方、分散化リソース割り当てタイプは、周波数ダイバーシチ効果を頼りにして送信信号の強固さを得る。局所化リソース割り当てタイプとは異なり、分散化リソース割り当てモードは、受信エンティティからの、例えば、ＣＱＩリポーティングのような品質のフィードバックに基づいて物理的リソースを割り当てようとはしない。送信エンティティは複数レベルのフィードバック・モードによって提供され得る情報を有効に利用しないので、分散化リソース割り当てモードには従来のＡＣＫ／ＮＡＣＫフィードバック・モードが設定される。
【０１３１】
上述した両方のリソース割り当て方法、局所化及び分散化リソース割り当て方法は、スケジューリング・モードとも言うことができる。局所化及び分散化スケジューリング・モードは、発明の背景の節で述べた、例えばＯＦＤＭなどのマルチキャリアに基づく無線アクセス方式に、並びに単一キャリア周波数分割多元接続（ＳＣ−ＦＤＭＡ）などの単一キャリアに基づく無線アクセス方式にも使用することができる。したがって、本発明のこの態様による、リソース割り当て方法、例えばスケジューリング・モードに基づくＨＡＲＱフィードバック・モードの設定は、特定の無線アクセス技術に限定されない。
【０１３２】
上記の実施形態で説明したメカニズムのように、ＨＡＲＱ再送プロトコルの設定された応答モードは 、無線ベアラ・メッセージを使用してシグナリングにより通知することができ、及び／または特定のＨＡＲＱプロセスに属させることができる。
【０１３３】
本発明の別の実施形態によれば、送信または受信エンティティは設定された応答モードを自律的に切り替えることができる。第１の応答モードが設定されているとき、ある状況において、送信エンティティまたは受信エンティティは設定された第１の応答モードから第２の応答モードへ自律的に切り替えを行なえる。
【０１３４】
例えば、受信エンティティの送信電力レベルが所定値よりも高いとき、すなわち、受信エンティティが送信電力を制限されるとき、受信エンティティは、設定された第１の応答モード、すなわち、複数レベルのフィードバック・モードから第２の応答モード、すなわち、従来のＡＣＫ／ＮＡＣＫフィードバック・モードへ切り替わる。状況に応じて、受信エンティティの送信電力レベルが所定値よりも低いときには、受信エンティティは第２の応答モードから設定された第１の応答モードへ戻るように切り替わる。
【０１３５】
受信エンティティはまた、第１の応答モードから第２の応答モードへの切り替え後、及び第２の応答モードから第１の応答モードへ戻る切り替え後、一つの応答モードから他の応答モードへ切り替わったことまたは戻ったことを送信エンティティに通知する。
【０１３６】
シグナリング信頼性が同じであると仮定すれば、複数レベルのフィードバック・モードによるフィードバック・シグナリングは、従来のＡＣＫ／ＮＡＣＫフィードバック・シグナリングに比べて送信電力をより多く必要とする。言い換えれば、送信電力が同じであると仮定すれば、複数レベルのフィードバック・シグナリングのシグナリング信頼性は、従来のＡＣＫ／ＮＡＣＫフィードバック・シグナリングに比べて劣る。したがって、たとえ複数レベルのフィードバック・モードがＲＲＣエンティティによって既に設定されていたとしても、上記のように送信電力が制限される状況では、複数レベルのフィードバック・モードから従来のＡＣＫ／ＮＡＣＫフィードバック・モードへ切り替えることはより有益である。
【０１３７】
したがって、本発明のある実施形態によれば、ＵＥが電力を制限されているとき、ＵＥは設定された複数レベルのフィードバック・モードから従来のＡＣＫ／ＮＡＣＫフィードバック・モードへ自律的に切り替わる。電力制限がもはやなくなれば、ＵＥは設定されたフィードバック・モードへ戻ることができる。電力制限の場合を詳細に述べているが、ＵＥが設定されたフィードバック・モードを自律的に切り替えるその他の状況もあり得る。
【０１３８】
ＵＥが設定されたフィードバック・モードを変更可能であるのと同様に、ノードＢも必要な場合に応答モードを切り替える。例えば、応答メッセージを運ぶチャネル上に増加した干渉レベルがあるとき、送信エンティティ、すなわち、本例ではノードＢは設定されたフィードバック・モードを切り替えることができる。
【０１３９】
したがって、本発明のこの有利な実施形態によれば、送信エンティティは、応答メッセージを運ぶチャネル上の干渉レベルの情報を取得する。この取得した干渉レベルに基づいて、送信エンティティで取得した干渉レベルが所定値よりも大きいときには、送信エンティティは設定された第１の応答モード、すなわち、複数レベルの応答モードから第２の応答モード、すなわち、従来のＡＣＫ／ＮＡＣＫフィードバック・モードへ切り替り、送信エンティティで取得した干渉レベルが所定値より小さいときには、従来のＡＣＫ／ＮＡＣＫ応答モードから複数レベルの応答モードへ戻るように切り替わる。
【０１４０】
ノードＢはまた、本発明の別の実施形態では、ノードＢで受信した応答メッセージの復号品質が所定値より小さいときには、複数レベルの応答モードから従来のＡＣＫ／ＮＡＣＫ応答モードへ切り替わることができる。ノードＢで受信した応答メッセージの復号品質が所定値より大きいときには、ノードＢは従来のＡＣＫ／ＮＡＣＫフィードバック・モードから設定された複数レベルのフィードバック・モードへ戻るように切り替わる。
【０１４１】
設定された第１の応答モードから第２の応答モードへの切り替え後、及び／または第２の応答モードから第１の設定応答モードへ戻る切り替え後、送信エンティティは応答モードを受信エンティティにシグナリングにより通知する。
【０１４２】
前に説明したように、性能損失を避けるために、受信及び送信エンティティの両方はＨＡＲＱフィードバック・モードに関して同期される。実際、送信エンティティが、例えば、従来のＡＣＫ／ＮＡＣＫフィードバック・モードをとるのに対し、受信エンティティが複数レベルのフィードバック・モードをとる場合、複数レベルのフィールドによって提供された追加情報は、再送の調整のために送信エンティティによって利用されず、したがって性能が低下する。
【０１４３】
送信と受信エンティティが同期されない場合のこの性能損失の別の例を、ＨＡＲＱフィードバックがＭＡＣシグナリングにより送信される場合を例にとり以下に説明する。可能な各フィードバック・メッセージはコードワードに対応する。複数レベルのＡＣＫ／ＮＡＣＫに対応したコードワードを使用する簡単な実現を下表に示す。
【０１４４】
【表１】
2009517935.tif 000003
【０１４５】
「Lost」はフィードバックの第３のレベルを示し、これは、例えば、送信エンティティがデータ・パケットの自己復号可能なバージョンを再送すべきであることを示す。送信エンティティがＨＡＲＱフィードバック・シグナリングに使用されるコードワードの数を認識していない場合、性能の低下が起こる。
【０１４６】
切り替え後に送信及び受信エンティティの両方が同じＨＡＲＱフィードバック・モードを使用することを保証するために、フィードバック・モードの確認メッセージが送信エンティティ及び受信エンティティ間で交換される。
【０１４７】
送信または受信エンティティによって自律的に起こされた迅速なＨＡＲＱフィードバック・モードの切り替えのためのシグナリングは、物理層のシグナリングまたはＬ２のシグナリング、すなわち、ＭＡＣシグナリングを介して行なえる。一例として、ＵＥが、送信電力制限に伴い、設定された複数レベルのフィードバック・モードから従来のＡＣＫ／ＮＡＣＫフィードバック・モードへ切り替えたい場合、ＨＡＲＱフィードバック・モードの切り替えを示すＭＡＣ制御ＰＤＵをＵＥはノードＢへ送信する。このＭＡＣ制御ＰＤＵを受信すると、ＭＡＣ制御ＰＤＵの受信を確認する応答をノードＢはＵＥへ送信する。この応答メッセージは、例えば、ＡＣＫメッセージまたは他のＭＡＣ制御ＰＤＵであってもよい。
【０１４８】
さらに別の実施形態では、ＲＲＣシグナリングを介した無線ベアラまたはＨＡＲＱプロトコルの設定時または再設定時に、ノードＢ及び／またはＵＥがある種の危険な状態により複数レベルのＮＡＣＫシグナリングの使用と停止の切り替えを自律的に行なえるか否かを無線アクセス・ネットワークが明確に指示する。
【０１４９】
本発明の別の実施形態は、ハードウェア及びソフトウェアを使用した、上述した様々な実施形態の実現に関係する。本発明の多様な実施形態は、例えば汎用プロセッサとしてのコンピューティング・デバイス（プロセッサ）、デジタル・シグナル・プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）またはその他のプログラム可能な論理回路などを使用して実現可能または実施可能であることが認識される。本発明の多様な実施形態は、上記のデバイスの組合せによっても実施または実現し得る。
【０１５０】
さらに、本発明の多様な実施形態は、プロセッサで実行され、または直接ハードウェアに組み込むソフトウェア・モジュールを用いても実現可能である。また、ソフトウェア・モジュールとハードウェア実現の組合せも可能である。ソフトウェア・モジュールは、コンピュータで読取り可能などんな種類の記憶媒体3/4例えば、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュ・メモリ、レジスタ、ハード・ディスク、ＣＤ−ＲＯＭ、ＤＶＤなど3/4に記憶されてもよい。
【図面の簡単な説明】
【０１５１】
【図１】ハイレベルＵＭＴＳアーキテクチャを示す。
【図２】ＵＭＴＳリリース９９／４／５によるＵＴＲＡＮの現行のアーキテクチャを示す。
【図３】ＵＭＴＳネットワークにおけるドリフト及びサービング無線ネットワーク・サブシステムを示す。
【図４】ＵＭＴＳネットワークにおけるＵＴＲＡＮのプロトコルの概要を示す。
【図５】ＵＴＲＡＮの無線インタフェース・プロトコル・アーキテクチャの概要を示す。
【図６】リリース９９／４／５のＵＴＲＡＮアーキテクチャを前提にしたＨＳＤＰＡ向けのユーザ・プレーンのプロトコル・スタック・アーキテクチャを示す。
【図７】リリース９９／４／５のＵＴＲＡＮアーキテクチャを前提にしたＨＳＵＰＡ向けのユーザ・プレーンのプロトコル・スタック・アーキテクチャを示す。
【図８ａ】ＵＭＴＳシステムにおいて個別物理チャネルの起動を伴う無線ベアラ確立手順を示す。
【図８ｂ】ＵＭＴＳシステムにおいて個別物理チャネルの起動を伴う無線ベアラ確立手順を示す。
【図９】リリース６のＵＭＴＳアーキテクチャを前提にしたＲＮＣ要素を含む制御プレーンのプロトコル・スタックの例を示す。
【図１０】ＲＮＣ要素を含む、進化した制御プレーンのプロトコル・スタックの例を示す。
【図１１】ＲＮＣ要素を含まない、進化した制御プレーンのプロトコル・スタックの例を示す。
【図１２】ＯＦＤＭにおける局所化及び分散化リソース割り当て方法を示す。
【図１３】本発明の実施形態による無線ベアラごとにＨＡＲＱ応答モードを設定する方式を示す。
【図１４】本発明の実施形態によるＨＡＲＱプロセスごとにＨＡＲＱ応答モードを設定する方式を示す。
【図１】
2009517935.tif 000004
【図２】
2009517935.tif 000005
【図３】
2009517935.tif 000006
【図４】
2009517935.tif 000007
【図５】
2009517935.tif 000008
【図６】
2009517935.tif 000009
【図７】
2009517935.tif 000010
【図８ａ】
2009517935.tif 000011
【図８ｂ】
2009517935.tif 000012
【図９】
2009517935.tif 000013
【図１０】
2009517935.tif 000014
【図１１】
2009517935.tif 000015
【図１２】
2009517935.tif 000016
【図１３】
2009517935.tif 000017
【図１４】
2009517935.tif 000018
【国際調査報告】
2009517935.tif 000019
2009517935.tif 000020
2009517935.tif 000021