(57)【要約】  本明細書及び図面は，ハイブリッド自動再送要求プロトコル（ＨＡＲＱ）を用いるアップリンク通信の性能を，移動体通信ネットワークにおけるＩｕｂインタフェース（例えばノードＢから無線ネットワークコントローラＲＮＣまで）を介したＨＡＲＱ障害表示によって改善させる新たな方法と，システムと，装置と，ソフトウェア製品と，を提示する。ＨＡＲＱ障害表示は，その障害が起きるまでに何回かのＨＡＲＱ再送信を含む。
2008529437.tif 000002
【特許請求の範囲】
【請求項１】
ハイブリッド自動再送要求（ＨＡＲＱ）プロトコルを用いるアップリンク通信の方法であって，
ネットワーク要素（１２）が，前記ＨＡＲＱプロトコルを用いてアップリンクデータのデコードに失敗するように試行するステップと，
前記の試行におけるＨＡＲＱ障害の表示を更なるネットワーク要素（２４）に選択的に報告する報告ステップであって，前記表示はＨＡＲＱ障害が起きるまでに何回かのＨＡＲＱ再送信試行を含むステップと，
を有する方法。
【請求項２】
前記ハイブリッド自動再送要求（ＨＡＲＱ）プロトコルは，前記ＨＡＲＱ障害が起きるまでにＮ回再送信を用い，Ｎは最大許容再送信数を超えない少なくとも０である整数とする請求項１に記載の方法。
【請求項３】
前記ネットワーク要素（１２）は，所定の基準を用いて前記の試行をＨＡＲＱ障害と解釈する請求項１に記載の方法。
【請求項４】
前記ＨＡＲＱ障害が起きた時刻，又は前記ネットワーク要素（１２）が検出した時刻を更に報告するステップを更に有する請求項１に記載の方法。
【請求項５】
前記ネットワーク要素（１２）がＨＡＲＱ障害を検出したときはいつでも，前記ＨＡＲＱ障害を報告する請求項１に記載の方法。
【請求項６】
前記ネットワーク要素（１２）は移動体通信システムのノードＢとする請求項１に記載の方法。
【請求項７】
ＨＡＲＱ障害の前記表示を報告する前記報告ステップを，フレームプロトコルヘッダを用いて行う請求項１に記載の方法。
【請求項８】
ＨＡＲＱ障害の前記表示を報告する前記報告ステップを，制御フレームを用いて行う請求項１に記載の方法。
【請求項９】
ＨＡＲＱ障害の前記表示を報告する前記報告ステップを，独立フレームを用いて行う請求項１に記載の方法。
【請求項１０】
前記ＨＡＲＱ障害を，所定の値の１ビットフラグを用いて示す請求項１に記載の方法。
【請求項１１】
前記ＨＡＲＱ障害を，所定の値のＭＡＣ−ｅｓ  ＰＤＵ数フィールドを用いて示す請求項１に記載の方法。
【請求項１２】
前記ＭＡＣ−ｅｓ  ＰＤＵ数フィールドに０を用いる請求項１１に記載の方法。
【請求項１３】
前記ＨＡＲＱ障害を，所定の値のデータ記述指示子（ＤＤＩ）を用いて示す請求項１に記載の方法。
【請求項１４】
前記データ記述指示子（ＤＤＩ）に２進値１１１１１１を用いる請求項１３に記載の方法。
【請求項１５】
ＨＡＲＱ障害の前記表示を報告する前記報告ステップを，デコードしたデータを含むデータフレームに前記報告を組み込むステップを用いて行う請求項１に記載の方法。
【請求項１６】
前記データフレーム内の前記ＨＡＲＱ障害表示ごとに，サブフレーム番号フィールドを１だけ増加させる請求項１５に記載の方法。
【請求項１７】
前記更なるネットワーク要素（２４）は，無線ネットワークコントローラ（ＲＮＣ）とする請求項１に記載の方法。
【請求項１８】
計算機プロセッサが実行する計算機プログラムコードを組み込んだ計算機可読記憶構造を含む計算機プログラム製品であって，前記計算機プログラムコードは，前記ネットワーク要素（１２）又は前記更なるネットワーク要素（２４）の任意のコンポーネントによって実行するように指示された請求項１に記載の方法の各ステップを実行する命令を含むことを特徴とする計算機プログラム製品。
【請求項１９】
移動体通信システム（１５）のネットワーク要素（１２）であって，
ハイブリッド自動再送要求（ＨＡＲＱ）プロトコルを用いて，アップリンクデータをデコードするよう試行するＨＡＲＱデコーダモジュール（１４）と，
更なるネットワーク要素（２４）に，前記の試行におけるＨＡＲＱ障害表示を選択的に報告する障害報告発生器（１６）であって，前記表示は，ＨＡＲＱ障害が起きるまでに何回かのＨＡＲＱ再送信試行を含む発生器と，
を備えるネットワーク要素。
【請求項２０】
前記ハイブリッド自動再送要求（ＨＡＲＱ）プロトコルは，前記ＨＡＲＱ障害が起きるまでにＮ回再送信を用い，Ｎは最大許容再送信数を超えない少なくとも０である整数とする請求項１９に記載のネットワーク要素。
【請求項２１】
前記障害報告発生器（１６）は，所定の基準を用いて前記の試行をＨＡＲＱ障害と解釈する請求項１９に記載のネットワーク要素。
【請求項２２】
前記ネットワーク要素（１２）は移動体通信システム（１５）のノードＢとする請求項１９に記載のネットワーク要素。
【請求項２３】
前記ＨＡＲＱデコーダモジュール（１４）と前記障害報告発生器（１６）とを１つのブロックに結合した請求項１９に記載のネットワーク要素。
【請求項２４】
前記ネットワーク要素（１２）がＨＡＲＱ障害を検出したときはいつでも，前記ＨＡＲＱ障害を報告する請求項１９に記載のネットワーク要素。
【請求項２５】
ＨＡＲＱ障害の前記表示を報告する前記報告ステップを，制御フレームを用いて行う請求項１９に記載のネットワーク要素。
【請求項２６】
ＨＡＲＱ障害の前記表示を報告する前記報告ステップを，独立フレームを用いて行う請求項１９に記載のネットワーク要素。
【請求項２７】
ＨＡＲＱ障害の前記表示を報告する前記報告ステップを，デコードしたデータを含むデータフレームに前記報告を組み込むステップを用いて行う請求項１９に記載のネットワーク要素。
【請求項２８】
前記データフレーム内の前記ＨＡＲＱ障害表示ごとに，サブフレーム番号フィールドを１だけ増加させる請求項２７に記載のネットワーク要素。
【請求項２９】
前記ＨＡＲＱ障害を，所定の値の１ビットフラグを用いて示す請求項１９に記載のネットワーク要素。
【請求項３０】
前記ＨＡＲＱ障害を，所定の値のＭＡＣ−ｅｓ  ＰＤＵ数フィールドを用いて示す請求項１９に記載のネットワーク要素。
【請求項３１】
前記ＭＡＣ−ｅｓ  ＰＤＵ数フィールドに０を用いる請求項３０に記載のネットワーク要素。
【請求項３２】
前記ＨＡＲＱ障害を，所定の値のデータ記述指示子（ＤＤＩ）を用いて示す請求項１９に記載のネットワーク要素。
【請求項３３】
前記データ記述指示子（ＤＤＩ）に２進値１１１１１１を用いる請求項３２に記載のネットワーク要素。
【請求項３４】
ＨＡＲＱ障害の前記表示を報告する前記報告ステップを，フレームプロトコルヘッダを用いて行う請求項１９に記載のネットワーク要素。
【請求項３５】
アップリンク通信にハイブリッド自動再送要求（ＨＡＲＱ）プロトコルを用いる移動体通信システム（１５）であって，
アップリンクデータを送信及び再送信するユーザ装置（１０）と，
前記アップリンクデータ信号に反応して，前記ハイブリッド自動再送要求（ＨＡＲＱ）プロトコルを用いて前記アップリンクデータ信号に含まれるアップリンクデータをデコードし，前記の試行におけるＨＡＲＱ障害表示を含むＨＡＲＱ障害表示信号（２０）を提供するネットワーク要素（１２）であって，前記表示はＨＡＲＱ障害が起きるまでに何回かのＨＡＲＱ再送信試行を含むネットワーク要素と，
前記ＨＡＲＱ障害表示信号（２０）に反応する更なるネットワーク要素（２４）と，
を備えるシステム。
【請求項３６】
前記ネットワーク要素（１２）は，所定の基準を用いて前記の試行をＨＡＲＱ障害と解釈する請求項３５に記載の移動体通信システム。
【請求項３７】
前記ネットワーク要素（１２）がＨＡＲＱ障害を検出したときはいつでも，前記ＨＡＲＱ障害を報告する請求項３５に記載の移動体通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は概略移動体通信ネットワークに関し，より詳細に言えばＩｕｂインタフェースを介したＨＡＲＱ障害表示に関する。
【背景技術】
【０００２】
図１ａに示すように，３Ｇ  ＷＣＤＭＡ（第３世代広帯域符号分割多元接続）によれば，無線通信を介して通信しているとき，移動体ユーザ装置（ＵＥ）１８は，いわゆるＵｕインタフェースを介してＵＴＲＡＮ（はん用移動体通信システム（ＵＭＴＳ）地上無線接続ネットワーク）のノードＢ１７（時には基地局とも呼ばれる）に接続する。次にＵＴＲＡＮノードＢは，いわゆるＩｕｂインタフェースを介してＵＴＲＡＮ無線ネットワークコントローラ（ＲＮＣ）１１と通信し，そしてＲＮＣはいわゆるＩｕインタフェースを介して，コアネットワーク（ＣＮ），すなわち移動体通信交換センタ（ＭＳＣ）又はサービス提供ＧＰＲＳ（はん用パケット無線システム）サポートノード（ＳＧＳＮ）のいずれかと通信し，またいわゆるＩｕｒインタフェースを介してほかのＲＮＣとも通信する。より詳細に言えば，Ｉｕインタフェースは，ＵＴＲＡＮ  ＲＮＣとＭＳＣとの間の回線交換インタフェースＩｕＣＳ，又はＵＴＲＡＮ  ＲＮＣとＳＧＳＮとの間のパケット交換インタフェースＩｕＰＳ，のいずれかである。
【０００３】
３ＧＰＰのＥ−ＤＣＨ（強化個別チャネル）に関する技術資料文書，3GPP TR R3.015 v0.2.1，FDD Enhanced Uplink: UTRAN Iub/Iur Protocol Aspects (Release 6, Section 6.3.2)，２００４年１２月，に本発明に関連する課題及び未解決の項目が適切に述べられている。上述の文書の６．３．２章は，まとめると次のとおりである。
【０００４】
遅延に鋭敏な会話クラスのフローについては，最大再送信試行数を２〜３回に限ることが望ましい。特にＴＴＩ（送信タイミング間隔）が１０ｍｓのときにそうであり，ペイロードが１又は２回のＨＡＲＱ（ハイブリッド自動再送要求）再送信よりも長く遅延した場合には，そのアプリケーションとの関連性を失うかもしれない。
【０００５】
ノードＢは，再送信事象が継続しないことによって障害を検出してもよい。
【０００６】
本発明の時点で，次の項目が課題であった。
・ＨＡＲＱデコード障害表示を通知する方法の詳細。例えばこの表示は，ＴＢブロックサイズが０に設定されているＵＬ（アップリンク）データフレームに挿入された特定の値（例えば１５）を有するＨＡＲＱ再送信数フィールドであってもよい。ＨＡＲＱデコード障害表示がＵプレーン（ユーザプレーン）で送信されるときは，最後にデコード試行が失敗したときに，ＣＦＮ（コネクションフレーム番号）及びサブフレーム番号でタイムスタンプが付けられる。
・障害表示を送信するトランスポートベアラ（すなわちＭＡＣ−ｄフロー，ＭＡＣは媒体接続制御の略）を選択する規則。これは，ＭＡＣ−ｄ分離情報が帯域内（すなわちＭＡＣ−ｅ  ＰＤＵ（プロトコルデータユニット）内）に含まれており，デコードが成功するまではノードＢに未知であるからである。
・種々の再送信限度を有するＭＡＣ−ｄフローが，同一のＭＡＣ−ｅ  ＰＤＵ内に多重化されている場合。
・ＳＨＯ（軟ハンドオーバ）の場合の最適化（例えばＭＡＣ−ｅ  ＰＤＵが別のノードＢを介してうまく受信できた場合に，ノードＢにおける再送信カウンタをリセットする手段）。
【発明の開示】
【課題を解決するための手段】
【０００７】
本発明の第１態様によれば，ハイブリッド自動再送要求（ＨＡＲＱ）プロトコルを用いるアップリンク通信の方法は，ネットワーク要素（１２）が，前記ＨＡＲＱプロトコルを用いてアップリンクデータのデコードに失敗するように試行するステップと，前記の試行におけるＨＡＲＱ障害表示を更なるネットワーク要素（２４）に選択的に報告する報告ステップであって，前記表示はＨＡＲＱ障害が起きるまでに何回かのＨＡＲＱ再送信試行を含むステップと，を有する。
【０００８】
本発明の第１態様によれば更に，前記ハイブリッド自動再送要求（ＨＡＲＱ）プロトコルは，前記ＨＡＲＱ障害が起きるまでにＮ回再送信を行ってもよく，Ｎは最大許容再送信数を超えない少なくとも０である整数である。
【０００９】
更に本発明の第１態様によれば，前記ネットワーク要素は，所定の基準を用いて前記の試行をＨＡＲＱ障害と解釈してもよい。
【００１０】
また更に本発明の第１態様によれば，第１態様は更に，前記ＨＡＲＱ障害が起きた時刻又は前記ネットワーク要素が検出した時刻を更に報告するステップを更に有してもよい。
【００１１】
本発明の第１態様によれば更に，前記ネットワーク要素がＨＡＲＱ障害を検出したときはいつでも，前記ＨＡＲＱ障害を報告してもよい。
【００１２】
本発明の第１態様によれば更に，前記ネットワーク要素は移動体通信システムのノードＢであってもよい。
【００１３】
本発明の第１態様によれば更に，ＨＡＲＱ障害の前記表示を報告する前記報告ステップを，フレームプロトコルヘッダを用いて行ってもよい。
【００１４】
本発明の第１態様によれば更に，ＨＡＲＱ障害の前記表示を報告する前記報告ステップを，制御フレームを用いて行ってもよい。
【００１５】
本発明の第１態様によれば更に，ＨＡＲＱ障害の前記表示を報告する前記報告ステップを，独立フレームを用いて行ってもよい。
【００１６】
本発明の第１態様によれば更に，前記ＨＡＲＱ障害を，所定の値の１ビットフラグを用いて示してもよい。
【００１７】
本発明の第１態様によれば更に，前記ＨＡＲＱ障害を，所定の値のＭＡＣ−ｅｓ  ＰＤＵ数フィールドを用いて示してもよい。更に前記のＭＡＣ−ｅｓ  ＰＤＵ数フィールドに０を用いてもよい。
【００１８】
また更に本発明の第１態様によれば，前記ＨＡＲＱ障害を，所定の値のデータ記述指示子（ＤＤＩ）を用いて示してもよい。更に前記データ記述指示子（ＤＤＩ）に２進値１１１１１１を用いてもよい。
【００１９】
更に本発明の第１態様によれば，ＨＡＲＱ障害の前記表示を報告する前記報告ステップを，デコードしたデータを含むデータフレームに前記報告を組み込むステップを用いて行ってもよい。更に前記データフレーム内の前記ＨＡＲＱ障害表示ごとに，サブフレーム番号フィールドを１だけ増加させてもよい。
【００２０】
更に本発明の第１態様によれば，前記更なるネットワーク要素は，無線ネットワークコントローラ（ＲＮＣ）であってもよい。
【００２１】
本発明の第２態様によれば，計算機プログラム製品が計算機プロセッサの実行する計算機プログラムコードを組み込んだ計算機可読記憶構造を含み，前記計算機プログラムコードは，前記ネットワーク要素又は前記更なるネットワーク要素の任意のコンポーネントによって実行するように指示された，請求項１に記載の方法の各ステップを実行する命令を含むことを特徴とする。
【００２２】
本発明の第３態様によれば，移動体通信システムのネットワーク要素は，ハイブリッド自動再送要求（ＨＡＲＱ）プロトコルを用いて，アップリンクデータをデコードするよう試行するＨＡＲＱデコーダモジュールと，更なるネットワーク要素に，前記の試行におけるＨＡＲＱ障害表示を選択的に報告する障害報告発生器であって，前記表示は，ＨＡＲＱ障害が起きるまでに何回かのＨＡＲＱ再送信試行を含む発生器と，を備える。
【００２３】
本発明の第３態様によれば更に，前記ハイブリッド自動再送要求（ＨＡＲＱ）プロトコルは，前記ＨＡＲＱ障害が起きるまでにＮ回再送信を行ってもよく，Ｎは最大許容再送信数を超えない少なくとも０である整数である。
【００２４】
更に本発明の第３態様によれば，前記障害報告発生器は，所定の基準を用いて前記の試行をＨＡＲＱ障害と解釈してもよい。
【００２５】
更に本発明の第３態様によれば，前記ネットワーク要素は移動体通信システムのノードＢであってもよい。
【００２６】
更に本発明の第３態様によれば，前記ＨＡＲＱデコーダモジュールと前記障害報告発生器とを１つのブロックに結合してもよい。
【００２７】
更に本発明の第３態様によれば，前記ネットワーク要素がＨＡＲＱ障害を検出したときはいつでも，前記ＨＡＲＱ障害を報告してもよい。
【００２８】
更に本発明の第３態様によれば，ＨＡＲＱ障害の前記表示を報告する前記報告ステップを，制御フレームを用いて行ってもよい。
【００２９】
更に本発明の第３態様によれば，ＨＡＲＱ障害の前記表示を報告する前記報告ステップを，独立フレームを用いて行ってもよい。
【００３０】
また更に本発明の第３態様によれば，ＨＡＲＱ障害の前記表示を報告する前記報告ステップを，デコードしたデータを含むデータフレームに前記報告を組み込むステップを用いて行ってもよい。更に前記データフレーム内の前記ＨＡＲＱ障害表示ごとに，サブフレーム番号フィールドを１だけ増加させてもよい。
【００３１】
また更に本発明の第３態様によれば，前記ＨＡＲＱ障害を，所定の値の１ビットフラグを用いて示してもよい。
【００３２】
また更に本発明の第３態様によれば，前記ＨＡＲＱ障害を，所定の値のＭＡＣ−ｅｓ  ＰＤＵ数フィールドを用いて示してもよい。更に前記ＭＡＣ−ｅｓ  ＰＤＵ数フィールドに０を用いてもよい。
【００３３】
また更に本発明の第３態様によれば，前記ＨＡＲＱ障害を，所定の値のデータ記述指示子（ＤＤＩ）を用いて示してもよい。更に前記データ記述指示子（ＤＤＩ）に２進値１１１１１１を用いてもよい。
【００３４】
また更に本発明の第３態様によれば，ＨＡＲＱ障害の前記表示を報告する前記報告ステップを，フレームプロトコルヘッダを用いて行ってもよい。
【００３５】
本発明の第４態様によれば，アップリンク通信にハイブリッド自動再送要求（ＨＡＲＱ）プロトコルを用いる移動体通信システムは，アップリンクデータを送信及び再送信するユーザ装置と，前記アップリンクデータ信号に反応して，前記ハイブリッド自動再送要求（ＨＡＲＱ）プロトコルを用いて前記アップリンクデータ信号に含まれるアップリンクデータをデコードし，前記の試行におけるＨＡＲＱ障害表示を含むＨＡＲＱ障害表示信号を提供するネットワーク要素であって，前記表示はＨＡＲＱ障害が起きるまでに何回かのＨＡＲＱ再送信試行を含むネットワーク要素と，前記ＨＡＲＱ障害表示信号に反応する更なるネットワーク要素と，を備える。
【００３６】
更に本発明の第４態様によれば，前記ネットワーク要素は，所定の基準を用いて前記の試行をＨＡＲＱ障害と解釈してもよい。
【００３７】
更に本発明の第４態様によれば，前記ネットワーク要素がＨＡＲＱ障害を検出したときはいつでも，前記ＨＡＲＱ障害を報告してもよい。
【発明を実施するための最良の形態】
【００３８】
本発明の性質及び目的をより良く理解するために，図面と共に以降の詳細な説明を参照されたい。
【００３９】
ハイブリッド自動再送要求プロトコル（ＨＡＲＱ）を用いるアップリンク通信の性能を改善させるために，移動体通信ネットワーク内のＩｕｂインタフェース（例えばノードＢから無線ネットワークコントローラＲＮＣまで）を介したＨＡＲＱ障害表示による，前述の障害が起きるまでに何回かのＨＡＲＱ再送信することを含む新規な方法と，システムと，装置と，ソフトウェア製品と，を提示する。ネットワーク要素（例えばノードＢ）は，所定の基準を用いて，再送信事象が継続しないことによってＨＡＲＱの障害を検出してもよい。更に，ＨＡＲＱ障害表示及び前述のＨＡＲＱ再送信数は，フレームプロトコルヘッダを用いてノードＢから例えばＳＲＮＣ（サービス提供ＲＮＣ）へ送信してもよい。更に，ＨＡＲＱ障害は，ネットワーク要素がＨＡＲＱ障害を検出するたびに報告してもよいし，予め選択した規則を用いて選択的に報告してもよい。
【００４０】
ＨＡＲＱを最大再送信限界近くで運用すると，無線状態の変化によって，許容ＨＡＲＱ再送信数以内で受信機がペイロードをデコードできない状況が生じることがある。しかし，ＳＲＮＣ（サービス提供ＲＮＣ）内にある外ループ電力制御（ＯＬＰＣ）は，デコード障害を知ることがなければＳＩＲ（信号対干渉比）目標を増加させないであろう。通常は正しくデコードされたフレームだけがＳＲＮＣに送信される。したがってＨＡＲＱ障害がＳＲＮＣに報告されないときは，引き続いてＨＡＲＱ障害が生じ，ＳＩＲ目標が低すぎるレベルに留まるおそれがある。このため，ノードＢからＲＮＣへ，ＨＡＲＱデコード障害表示を行わなければならない。
【００４１】
先行技術では障害を示すために，上述のように特別な値（例えば１１１１，１０進表記の１５）を設定した「ＨＡＲＱ再送信数」フィールドと，同時に０（又はＮ＝０，ここでＮは時々，「ＭＡＣ−ｄ  ＰＤＵ数」の代わりに用いる）を設定した「ＭＡＣ−ｄ  ＰＤＵ数」フィールドと，をＵＬ（アップリンク）データフレームに挿入することを提案している。しかしこれらの方法は，障害が生じるまでに何回送信が試みられるのかＲＮＣ（無線ネットワークコントローラ）が知らないという欠点がある。試行数は少なくても（ただ１回ですらも）よいので，障害がＮＡＫからＡＣＫへのフィードバック誤りに起因するときは特に有害であり，ＲＮＣはこの情報を取得するのが望ましい。ＨＡＲＱプロトコルの一部としてノードＢは，ブロックが正常にデコードされたときはＡＣＫ（肯定応答）を，又はブロックが正常にデコードされなかったときはＮＡＫ（否定応答）を，フィードバックとしてＵＥに送信する。ＮＡＫは再送信要求である。ＮＡＫは時々ＵＥにおいてＡＣＫとして解釈されることがあり，ブロックは再送信されない（ＮＡＫからＡＣＫへの誤り）。これはＨＡＲＱ障害を起こすであろう。またＳＨＯ（軟ハンドオーバ）において，そこでは数個のノードＢ（例えばノードＢ１及びノードＢ２）がＵＥの信号を受信し，それぞれがＵＥにＡＣＫ又はＮＡＫを送信するが，１つのノードＢ（例えばノードＢ２）がブロックを正常にデコードしＡＣＫを送信すると，（たとえ残りのノードＢ１がＮＡＫを送信しても）ＵＥは当然ブロックを再送信しないであろう。この場合ノードＢ１はそのブロックを正常に受信できず，ＲＮＣにＨＡＲＱ障害を示すであろう。（これは，ＲＮＣの関連からすればノードＢ２からブロックを受信しているので障害ではないが，ノードＢ１はそれを知らないので，前述の場合と区別することができない。）これらの場合すべてにおいて，ノードＢはＥ−ＤＰＣＣＨ（強化個別物理制御チャネル）を受信し，Ｅ−ＤＰＤＣＨをデコードしようとし，何回かの再送信の後ＵＥは送信を停止し，新規の送信を開始したと想定する。Ｅ−ＤＰＣＣＨが失われたときは，ノードＢは送信信号が何もないと想定するので，障害は起きない。普通ノードＢはＨＡＲＱ往復時間後，すなわち予想される再送信が送信されなかったとき，障害に気付く。これは遅延を生じるがＩｕｂのトラヒックを減少させる。すべてのＭＡＣ−ｅ  ＰＤＵ障害を通知するとＩｕｂトラヒックを増加させ，適切なパケットだけをＩｕｂを介して送信するという採用原則に反する。（障害になったブロックは，どのＭＡＣ−ｄフローに属しているのか分からない。）このように再送信数を用いて，多くの場合ＲＮＣは障害が例えばＮＡＫからＡＣＫへの誤りのためなのか，最大送信数のためなのか，などを推定することができる。
【００４２】
本発明によれば，「ＨＡＲＱ再送信数」フィールドを用い，ＨＡＲＱ障害を２進値ＤＤＩ＝１１１１１１及びＮ＝０（ＤＤＩはデータ記述指示子の略）で示して，（再）送信試行数をＲＮＣに通知することができる。
【００４３】
更に，障害を示すためにＮ＝０とした「ＨＡＲＱ再送信数」フィールドを用いる代わりに，本発明は障害を示すために特定の値を持つＤＤＩフィールドを用いることを提案する。これには，「ＨＡＲＱ再送信数」フィールドを通常の目的のため，すなわちＨＡＲＱ再送信数を伝えるために使うことができるという利点がある。通常「ＨＡＲＱ再送信数」フィールドは，正常にトランスポートブロックを完了するために何回の再送信が必要だったかを伝える。ここで本発明においては，「ＨＡＲＱ再送信数」フィールドは，障害までのＨＡＲＱ再送信試行数を伝える。このようにしてＲＮＣは，この重要な付加情報を障害の場合においても得ることができる。
【００４４】
更に本発明によれば，ＭＡＣ−ｅヘッダ内で送信されるＤＤＩ（６ビット）が，論理チャネルｉｄと，ＭＡＣ−ｄフローｉｄと，ＭＡＣ−ｄ  ＰＤＵサイズと，に対応付けられた６４の別々の値を有する。ＭＡＣ−ｅヘッダはＮも含み，それは対応するＭＡＣ−ｅｓ  ＰＤＵ内のＭＡＣ−ｄ  ＰＤＵ数である。ＤＤＩ値をＮ値（ＭＡＣ−ｄ  ＰＤＵ数に等しい）と共に，フレームプロトコル（ＦＰ）のデータフレームヘッダ（図２及び３を参照）の一部としてＲＮＣに送信することが提案されている。
【００４５】
無線インタフェースにおいては，１つのＤＤＩ値（例えば１１１１１１に等しい）がＭＡＣ−ｅ  ＰＤＵの終わりにある可能性があるパッドを示すために予約されている。この値はＩｕｂインタフェースを介して送信されない（ＭＡＣ−ｅｓ  ＰＤＵだけが送信される）。このようにＤＤＩ＝１１１１１１の値はＦＰヘッダ内おいてＨＡＲＱ障害を示すために再利用することができる。また，あるほかの値を予約することもでき，それはその値が無線インタフェースすなわちＩｕｂにおけるどの論理チャネルを示すのにも使うことができないことを意味する。
【００４６】
図１ｂに，本発明による移動体通信システム１５内のＩｕｂインタフェースを介するＨＡＲＱ障害表示を示すブロック図の１例を示す。通常のアップリンク（ＵＬ）データ信号は，ユーザ装置１０によってネットワーク要素（ノードＢ）１２のＨＡＲＱデコーダモジュール１４へ（再）送信される。障害報告発生器１６は，報告された障害に基づいてＨＡＲＱ障害表示信号２０を発生し，それはＩｕｂインタフェース２２を介し独立フレームとして，又は通常のデータフレームヘッダ部に付加されて，無線ネットワークコントローラ（ＲＮＣ）２４へ送信することができる。本発明によれば，ブロック１４と１６とを結合することができる。
【００４７】
図２及び３に，２つの可能なＦＰ（フレームプロトコル）データフレーム構造を示す。双方の構造とも，複数の無線インタフェースＴＴＩ（送信時間間隔）のデータを１つのＦＰデータフレームに結合することに対応できる。図３において，１つのＭＡＣ−ｅｓ  ＰＤＵに関連するヘッダ部はオクテット単位で並んでおり，そのために各ＭＡＣ−ｅｓ  ＰＤＵに対して同じヘッダ構成を与えている（偶数ＰＤＵと基数ＰＤＵとの間に差がない）。またペイロード部も，ＭＡＣ−ｅｓ  ＰＤＵ長が常にｎオクテット＋６ビット（ＴＳＮ，送信シーケンス番号）であること利用して最適化されている。これは，ＲＬＣ（無線リンク制御）ＰＤＵ長が常にオクテットの倍数であり，Ｅ−ＤＣＨのＭＡＣ−ｄはＣ／Ｔフィールド（Ｃ／Ｔフィールドは論理チャネル番号を示す）を追加しないことによる。ペイロードオクテット（バイト）が，ＲＬＣだけでなく，ＦＰデータフレームと，ＭＡＣ−ｅｓと，ＭＡＣ−ｄと，で同一であると，ＲＮＣ内部のデータ処理は簡略化され，そのためビットシフトは不要である。最後にヘッダの符号化は，3GPP TS 25.427 v6.1.0，２００４年１２月，の６．１．１章に示されている一般原理に従う。（読み書きは，左から右，上から下，へ行う）。
【００４８】
図２（図３に対応する先行技術のみを示す）は，Ｅ−ＤＣＨ（強化個別チャネル）ＦＰデータフレームの一例をとりわけ示す図であり，それはいくつかの無線インタフェースＴＴＩのデータを１つのＦＰデータフレームへ結合させることに対応している。ＭＡＣ−ｅｓ  ＰＤＵフィールド（８ビット）は，ＭＡＣ−ｅｓ  ＰＤＵ数だけでなくヘッダ部の数も通知する。サブフレーム番号（３ビット）及びＨＡＲＱ再送信数（４ビット）は，ＭＡＣ−ｅｓ  ＰＤＵごとに，ＤＤＩフィールド（６ビット）及びＭＡＣ−ｄ  ＰＤＵ数フィールド（６ビット）と共に繰り返される。たとえ単一のサブフレームからなっているＭＡＣ−ｅｓ  ＰＤＵであっても同一の構造を用いることができる。図２の方法の欠点は，たとえ各ＭＡＣ−ｅｓ  ＰＤＵが同一のサブフレーム内で送信されるときであっても，サブフレーム番号フィールド及びＨＡＲＱ再送信数フィールドがＭＡＣ−ｅｓ  ＰＤＵごとに繰り返されることである。
【００４９】
図３は代替フレーム構造であって，サブフレーム番号フィールド及びＨＡＲＱ再送信数フィールドはサブフレーム当たり１回だけ与えられ，一方，ＤＤＩフィールド及びＭＡＣ−ｄ  ＰＤＵ数フィールドはＭＡＣ−ｅｓ  ＰＤＵごとに繰り返される。ＭＡＣ−ｅｓ  ＰＤＵ数フィールドは除去され，２レベルの拡張フラグ（Ｆ）で置き換えられた。サブフレーム番号と同一の行のフラグは，もう１つのサブフレームが続く（Ｆ＝１）か，否か（Ｆ＝０）を示す。１つのヘッダ部の終わり（ＭＡＣ−ｄ  ＰＤＵ数フィールドの後）にある別のフラグは，同一のサブフレームのもう１つのヘッダ部が続く（Ｆ＝１）か，否か（Ｆ＝０）を示す。ＭＡＣ−ｅｓ  ＰＤＵごとに１つのヘッダ部（ＤＤＩ及びＭＡＣ−ｄ  ＰＤＵ数）がある。またこの構造は，１つのデータフレーム内の単一又は多数の無線インタフェースＴＴＩに対応する。この構造の利点は，サブフレーム番号フィールド及びＨＡＲＱ再送信数フィールドが不必要に繰り返されないことである。すなわち，１つのサブフレーム（例えば２ｍｓＴＴＩ）内で送信されるＭＡＣ−ｅｓ  ＰＤＵは，同一のサブフレーム値及びＨＡＲＱ再送信数値を有する。あるいは，拡張フラグの意味を反転させてもよい（Ｆ＝０はもう１つのサブフレーム又はヘッダ部が続くことを示し，Ｆ＝１はこれが最後のサブフレーム又はヘッダ部であることをそれぞれ示す）。
【００５０】
次に，本発明の種々の実施例を，例えば図２及び３に示すフレーム構造を用いてどのように実現できるかを示す。これらは単に例であって，３ＧＰＰが規定した実際のＦＲデータフレームはこれらの例と異なることがあることに留意されたい。またＨＡＲＱ障害表示もそれによって変更される（特に，本発明の一部ではないフィールド）。
【００５１】
始めに独立の「ＨＡＲＱ障害表示フレーム」，すなわちＨＡＲＱ障害を示すためだけに用いられる別個のフレーム，を説明する。
【００５２】
図４に，図３のＦＰデータフレームを踏襲し，本発明の実施例による独立ＨＡＲＱ障害表示フレームのダイヤグラムの例をとりわけ示す。別個のＨＡＲＱ障害表示フレームを生成し，Ｉｕｂを介して送信するときは，フレームは図４に示すもののように見えるであろう。ＤＤＩフィールドは１１１１１１に設定されてＨＡＲＱ障害を示す。ＭＡＣ−ｄ  ＰＤＵ数フィールドは０に設定するのが好ましく，ＭＡＣ−ｅｓ  ＰＤＵが何も追加されていないことを示す。また拡張フラグ（Ｆ）も０に設定されて，後続のヘッダがないことを示す（第１フラグは後続のサブフレームがないことを示し，第２フラグは後続のヘッダ部（ＤＤＩフィールド及びＭＡＣ−ｄ  ＰＤＵ数フィールド）がないことを示す）。「ＨＡＲＱ再送信数」フィールドは，本発明による実際の再送信試行数に設定される。ＣＦＮ及びサブフレーム番号は，いつこのブロックの最後の（再）送信試行が受信されたか，又はいつＨＡＲＱ障害をネットワーク要素（例えばノードＢ）が検出したか，を通知できる。またＣＦＮ及びサブフレームは，タイムスタンプとも呼ばれる。ヘッダＣＲＣは全フレーム（この場合はヘッダ）に渡って計算され，ここでＦＴ＝０（ＦＴはフレーム種別の略）であり，すなわちデータフレームを表している。
【００５３】
図５は，本発明の別の実施例による独立ＨＡＲＱ障害表示フレームの代替ダイヤグラムである。これは上述の別の代替データフレームによるものである（図２参照）。唯一の違いは，ＭＡＣ−ｅｓ  ＰＤＵ数を示す方法である。ここでは拡張フラグが「ＭＡＣ−ｅｓ  ＰＤＵ数」フィールドで置き換えられて，いくつのＭＡＣ−ｅｓ  ＰＤＵ（及び対応するヘッダ部）が続くかを通知する。このフィールドは，０に設定して引き続くＭＡＣ−ｅｓ  ＰＤＵがないことを示す（しかし１つのヘッダ部は読むことが望ましい）か，又は１に設定して１つのヘッダ部が続く（そしてＤＤＩ＝１１１１１１及びＮ＝０によってデータが何もないことを示す）ことを示すか，のいずれかであることが望ましい。ほかのフィールドは図４と同一である。
【００５４】
独立ＨＡＲＱ障害表示の第３代替案は，図６に示す制御フレームを用いることである（ＦＴ＝１が制御フレームであることを示す）。ここでは新たな制御フレーム種別によってＨＡＲＱ障害を示す（次の空き符号語，例えば００００１０１１を用いる）。次に必要なフィールド，すなわちＣＦＮと，サブフレーム番号（タイムスタンプである）と，ＨＡＲＱ再送信数と，だけを送信する（すなわち，ＤＤＩフィールド及びＭＡＣ−ｄ  ＰＤＵ数フィールドは不要である）。
【００５５】
本発明によれば，同時に送信すべき適切なデータがあるときは，ほかのデータと共にＨＡＲＱ障害表示を送信するという別の代替案がある。この場合，図４及び５に示した上述のヘッダ部が，通常のデータヘッダ部と同時に送信される（図７から１０に示すとおり）。普通ＤＤＩフィールドは，論理チャネルｉｄ及び通常データのＭＡＣ−ｄ  ＰＤＵサイズを通知する。特別な値のＤＤＩ（１１１１１１が好ましい）は，このヘッダ部がＨＡＲＱ障害表示であって，このヘッダ部に関連するデータはない（ＭＡＣ−ｅｓ  ＰＤＵがない）ことを通知する。
【００５６】
この種の相乗りＨＡＲＱ障害表示に関する課題は，現在のデータフレームのＣＦＮが，失敗した送信のＣＦＮと同一であるかもしれないことである。これは，ＵＥが再送信ではなく新たな送信を開始したときに障害に気付いたときによくある事例である。その場合，ＨＡＲＱプロトコルの往復時間後に障害に気付く。この課題を解決するには，少なくとも２つの解決策がある。１）追加のＣＦＮをデータフレームに追加する（ヘッダに追加する（可変長ヘッダ部を意味する。図７参照。）か，又は１オクテットペイロードとして（図８参照）），それによってＣＦＮが失敗した送信が起きたフレームを通知する（障害表示は，対応するサブフレーム番号及びＨＡＲＱ再送信数と共に送信される）。２）ＨＡＲＱ障害表示ヘッダ部に負のＣＦＮオフセットを加える。例えば，ＭＡＣ−ｄ  ＰＤＵフィールドの後の予備ビットをＣＦＮ＿ｏｆｆｓｅｔで置き換える（図９参照）。３ビットで０〜７フレームのオフセットが表示でき（符号なし整数表示を想定），それで十分である。このＣＦＮ＿ｏｆｆｓｅｔをデータフレームのＣＦＮから減算する。（別の代替案は，符号付き整数を用いることであるが，更にもう１ビットが必要になる。）本発明によれば，「ＨＡＲＱ再送信数」フィールドがＨＡＲＱ障害表示のために必要なため，これらすべての例においてＨＡＲＱ障害表示は独自のサブフレーム番号を有する。フラグだけでなく，サブフレーム番号と，ＨＡＲＱ再送信数と，ＤＤＩと，ＭＡＣ−ｄ  ＰＤＵ数と，の各フィールドはヘッダ内の通常の位置にある。ＨＡＲＱ障害表示のＣＦＮだけが，これらの特別な配置を必要とする。ＨＡＲＱ障害表示のＣＦＮ及びサブフレーム番号は，ＨＡＲＱ障害表示のタイムスタンプの働きをする。
【００５７】
図２に示すデータフレーム形式を選択したとき，どのようにしてＨＡＲＱ障害表示をデータと共に相乗りさせることができるかを図１０に示す。
【００５８】
ＨＡＲＱ障害表示だけを含む独立データフレーム（図４及び５参照）については，（それを解決策として選択したときは）ＣＦＮ＿ｏｆｆｓｅｔフィールドも追加して，それを０とする（通常のＣＦＮが有効であることを示す）のが好ましい。類似して追加のＣＦＮを解決策として選択したときは，同一のヘッダ構造を有するように，それもまた独立ＨＡＲＱ障害表示フレーム内に置くのが好ましい。
【００５９】
図１１，１２，１３に本発明の更なる実施例を更に示す。
【００６０】
図１１は，本発明の実施例によるＨＡＲＱ障害表示を含むＥ−ＤＣＨ  ＵＬデータフレームを示すダイヤグラムである。図１１のａはＨＡＲＱ障害表示を相乗りさせたものであり，ｂは独立のＨＡＲＱ障害表示である。
【００６１】
図１１において，ＨＡＲＱ障害表示のパラメータ設定は次のとおりである。
・「ＳＦＮ数」を１だけ増加させる（すなわち，１つのＳＦＮがＨＡＲＱ障害表示に用いられる）。例えば「第１ＳＦＮ」をＨＡＲＱ障害表示のＳＦＮに設定する。（ＳＦＮはサブフレーム番号であり，「ＳＦＮ数」は，サブフレーム番号の数である。すなわち，ＦＰヘッダ内にいくつのサブフレーム番号（ＳＦＮ）フィールドがあるかを通知する。）
・「ＭＡＣ−ｅｓ  ＰＤＵ数」を１に設定する（１組のＤＤＩ及びＮが続くことを示す）。
・「ＨＡＲＱ再送信数」を障害までのＨＡＲＱ再送信試行数に設定する。
・「ＤＤＩ」を１１１１１１に設定する。
・「Ｎ」を００００００に設定して，この「ＭＡＣ−ｅｓ  ＰＤＵ」にペイロードがないことを示す。
【００６２】
ＨＡＲＱ障害表示にペイロード部がないとき（例えば本発明の実施例において上述したように，ＨＡＲＱ障害のＣＦＮがペイロード内で送信されないとき）は，「ＭＡＣ−ｅｓ  ＰＤＵ数」フィールドを０に設定してＨＡＲＱ障害を示す。すなわち本発明の実施例によれば，ＨＡＲＱ障害をＤＤＩ＝１１１１１１で示す代わりに，「ＭＡＣ−ｅｓ  ＰＤＵ数」フィールドを０（又は一般に所定の値），又は１５（４ビットで表現できる最高値）に設定することによっても，同様にＨＡＲＱ障害を示すことができる。これはＦＰデータフレームにおいて最大２オクテット節約できるという利点がある。ＤＤＩ及びＮフィールドは省略できる。図１２に本発明のこの実施例を示す。
【００６３】
図１２は，本発明の実施例による，特定のＳＦＮに対してＭＡＣ−ｅｓ  ＰＤＵ数＝０（又は一般に所定の値）によって，ＨＡＲＱ障害表示を示したＥ−ＤＣＨ  ＵＬデータフレーム構造をとりわけ示すダイヤグラムの例である。図１２のａは，ＨＡＲＱ障害表示を相乗りさせたもの（明灰色部分が障害表示である），そしてｂは独立ＨＡＲＱ障害表示である。ＨＡＲＱ障害は，特定のＳＦＮに対してＭＡＣ−ｅｓ  ＰＤＵ数＝０で示され，ＨＡＲＱ障害表示のための別個のＣＦＮはない。
【００６４】
図１２において，ＨＡＲＱ障害表示のパラメータ設定は次のとおりであってよい。
・「ＳＦＮ数」を１だけ増加させる（すなわち，１つのＳＦＮがＨＡＲＱ障害表示に用いられる）。
・「第１ＳＦＮ」をＨＡＲＱ障害表示のＳＦＮに設定する。
・「ＭＡＣ−ｅｓ  ＰＤＵ数」を０に設定する（これは，ここではＨＡＲＱ障害表示であることを示す）。
・「ＨＡＲＱ再送信数」を障害までのＨＡＲＱ再送信試行数に設定する。
・「ＤＤＩ」及び「Ｎ」は置かない。
【００６５】
この場合，ＨＡＲＱ障害表示に関連するＭＡＣ−ｅｓ  ＰＤＵはない。またＨＡＲＱ障害表示が単独であるときは（図１２のｂ参照），この代替案によってより短い構造が得られる。
【００６６】
本発明の更なる実施例によれば，構造を更に最適化できる可能性がまだある。ＨＡＲＱ障害表示は次の情報を有することが望ましい。すなわち，ＨＡＲＱ再送信数と，ＣＦＮ／ＳＦＮと，これがＨＡＲＱ障害表示である（そして通常のヘッダ部ではない）ことを示すいくつかの手段と，である。ＨＡＲＱ障害表示を示す最も単純な方法は，１ビットフラグ（Ｆ）を用いることである。図１３にこの概念を示す。
【００６７】
図１３は，本発明の実施例による，特定のＳＦＮに対してＦ＝１によって，ＨＡＲＱ障害表示を示したＥ−ＤＣＨ  ＵＬデータフレーム構造をとりわけ示すダイヤグラムの例である。図１３のａは，ＨＡＲＱ障害表示を相乗りさせたもの（明灰色部分が障害表示である），そしてｂは独立ＨＡＲＱ障害表示である。
【００６８】
図１３に示すように，新たなフラグ（Ｆ）がヘッダに追加されている。このフラグは，ヘッダの当該部分がＨＡＲＱ障害表示用である（Ｆ＝１）か，又はＭＡＣ−ｅｓ  ＰＤＵの通常のヘッダである（Ｆ＝０）か，を通知する。Ｆ＝１（ＨＡＲＱ障害表示）であるときは，ＨＡＲＱ再送信数フィールド及びＳＦＮフィールドが続く。これは，ＨＡＲＱ障害表示のために追加オクテットが１だけ必要であることを意味する。フラグが０（Ｆ＝０）に設定されているときは，通常のヘッダ部の後に，ＳＦＮと，ＭＡＣ−ｅｓ  ＰＤＵ数と，ＨＡＲＱ再送信数と，ＤＤＩと，Ｎと，の各フィールドが続く。
【００６９】
図１３において，ＨＡＲＱ障害表示のパラメータ設定は次のとおりであってよい。
・ＨＡＲＱ障害表示ごとに「ＳＦＮ数」を１だけ増加させる（すなわち，ＨＡＲＱ障害表示ごとに１つのＳＦＮが用いられる）。
・「ＳＦＮ」をＨＡＲＱ障害表示のＳＦＮに設定する。
・「ＨＡＲＱ再送信数」を障害までのＨＡＲＱ再送信試行数に設定する。
・「ＭＡＣ−ｅｓ  ＰＤＵ数」と，「ＤＤＩ」と，「Ｎ」と，は置かない。
【００７０】
この場合，ＨＡＲＱ障害表示に関連するＭＡＣ−ｅｓ  ＰＤＵはない。またＨＡＲＱ障害表示が単独であるときは（図１３のｂ参照），この代替案によってより短い構造が得られる。ＳＦＮ数＝１は，ただ１つのＳＦＮがあることを通知し，Ｆ＝１はこれがＨＡＲＱ障害表示であることを通知する。
【００７１】
図１３に示したシナリオは多くの変形物が可能である。例えばＨＡＲＱ障害表示に別個のＣＦＮが必要なときは，ヘッダ内のＳＦＮの直後に完全なＣＦＮか，又はＣＦＮオフセットのいずれかとして追加してもよい。また，通常のヘッダ部だけでなく，ＨＡＲＱ障害表示についても，フィールドの位置を変更できることに気付くであろう。例えばＨＡＲＱ再送信数フィールドは，常に通常のヘッダ部内のＦフラグの後に置く方がよいであろう。更に，Ｆフラグの対応付けも当然入れ替えてよい。すなわち，Ｆ＝０はＨＡＲＱ障害を示すために用い，そしてＦ＝１は通常のヘッダ部を示すために用いてもよい。
【００７２】
上述のとおり本発明は，方法と，該方法の各ステップを実行する機能を提供する種々のモジュールからなる対応する装置と，の双方を提供する。各モジュールは，ハードウェアとして実現してもよいし，若しくは計算機プロセッサが実行するソフトウェア又はファームウェアとして実現してもよい。特にファームウェア又はソフトウェアの場合は，本発明は，計算機プロセッサが実行するための計算機プログラムコード（すなわちソフトウェア又はファームウェア）を組み込んだ計算機可読記憶構造を含む計算機プログラム製品として提供してもよい。
【００７３】
上述の構成は，本発明の原理の応用を例示するものに過ぎないことを理解されたい。本技術の当業者であれば，本発明の範囲を逸脱することなく，数々の修正物及び代替構成を考案できるであろう。添付の各請求項は，そのような修正物及び構成を包含することを意図したものである。
【図面の簡単な説明】
【００７４】
【図１ａ】ＵＴＲＡＮと通信するユーザ装置（ＵＥ）を示すブロック図である。
【図１ｂ】本発明によるＩｕｂインタフェースを介するＨＡＲＱ障害表示を示すブロック図である。
【図２】本発明の実施例を実現するＦＰ（フレームプロトコル）データフレーム構造のダイヤグラムである。
【図３】本発明の実施例を実現するＦＰ（フレームプロトコル）データフレーム構造の代替ダイヤグラムである。
【図４】本発明の実施例による独立ＨＡＲＱ障害表示フレームのダイヤグラムである。
【図５】本発明の実施例による独立ＨＡＲＱ障害表示フレームの代替ダイヤグラムである。
【図６】本発明の実施例によるＨＡＲＱ障害表示制御フレームのダイヤグラムである。
【図７】本発明の実施例によるＨＡＲＱ障害表示を有するヘッダ部と通常のデータヘッダ部とを結合する種々の代替案を示すダイヤグラムである。
【図８】本発明の実施例によるＨＡＲＱ障害表示を有するヘッダ部と通常のデータヘッダ部とを結合する種々の代替案を示すダイヤグラムである。
【図９】本発明の実施例によるＨＡＲＱ障害表示を有するヘッダ部と通常のデータヘッダ部とを結合する種々の代替案を示すダイヤグラムである。
【図１０】本発明の実施例によるＨＡＲＱ障害表示を有するヘッダ部と通常のデータヘッダ部とを結合する種々の代替案を示すダイヤグラムである。
【図１１】本発明の実施例によるＨＡＲＱ障害表示を有するＥ−ＤＣＨ  ＵＬデータフレーム構造であって，ａはＨＡＲＱ障害表示を相乗りさせたもの，ｂは独立ＨＡＲＱ障害表示，を示すダイヤグラムである。
【図１２】本発明の実施例による特定のＳＦＮに対してＭＡＣ−ｅｓ  ＰＤＵ数＝０によって示したＨＡＲＱ障害表示を有するＥ−ＤＣＨ  ＵＬデータフレーム構造であって，ａはＨＡＲＱ障害表示を相乗りさせたもの，ｂは独立ＨＡＲＱ障害表示，を示すダイヤグラムである。
【図１３】本発明の実施例による特定のＳＦＮに対してＦ＝１によって示したＨＡＲＱ障害表示を有するＥ−ＤＣＨ  ＵＬデータフレーム構造であって，ａはＨＡＲＱ障害表示を相乗りさせたもの，ｂは独立ＨＡＲＱ障害表示，を示すダイヤグラムである。
【図１ａ】
2008529437.tif 000003
【図１ｂ】
2008529437.tif 000004
【図２】
2008529437.tif 000005
【図３】
2008529437.tif 000006
【図４】
2008529437.tif 000007
【図５】
2008529437.tif 000008
【図６】
2008529437.tif 000009
【図７】
2008529437.tif 000010
【図８】
2008529437.tif 000011
【図９】
2008529437.tif 000012
【図１０】
2008529437.tif 000013
【図１１】
2008529437.tif 000014
【図１２】
2008529437.tif 000015
【図１３】
2008529437.tif 000016
【手続補正書】
【提出日】平成18年12月6日(2006.12.6)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ネットワーク要素が，ハイブリッド自動再送要求プロトコルを用いてアップリンクデータのデコードに失敗するように試行するステップと，
前記の試行におけるＨＡＲＱ障害の表示を更なるネットワーク要素に選択的に報告する報告ステップであって，前記表示はＨＡＲＱ障害が起きるまでに何回かのＨＡＲＱ再送信試行を含むステップと，
を有する方法。
【請求項２】
前記ハイブリッド自動再送要求プロトコルは，前記ＨＡＲＱ障害が起きるまでにＮ回再送信を用いるように構成し，Ｎは最大許容再送信数を超えない少なくとも０である整数とする請求項１に記載の方法。
【請求項３】
前記ネットワーク要素は，所定の基準を用いて前記の試行をＨＡＲＱ障害と解釈する請求項１に記載の方法。
【請求項４】
前記ＨＡＲＱ障害が起きた時刻，又は前記ネットワーク要素が検出した時刻を更に報告するステップを更に有する請求項１に記載の方法。
【請求項５】
前記ネットワーク要素がＨＡＲＱ障害を検出したときはいつでも，前記ＨＡＲＱ障害を報告する請求項１に記載の方法。
【請求項６】
前記ネットワーク要素は移動体通信システムのノードＢとする請求項１に記載の方法。
【請求項７】
ＨＡＲＱ障害の前記表示を報告する前記報告ステップを，フレームプロトコルヘッダを用いて行う請求項１に記載の方法。
【請求項８】
ＨＡＲＱ障害の前記表示を報告する前記報告ステップを，制御フレームを用いて行う請求項１に記載の方法。
【請求項９】
ＨＡＲＱ障害の前記表示を報告する前記報告ステップを，独立フレームを用いて行う請求項１に記載の方法。
【請求項１０】
前記ＨＡＲＱ障害を，所定の値の１ビットフラグを用いて示す請求項１に記載の方法。
【請求項１１】
前記ＨＡＲＱ障害を，所定の値のＭＡＣ−ｅｓプロトコルデータユニット数フィールドを用いて示す請求項１に記載の方法。
【請求項１２】
前記ＭＡＣ−ｅｓプロトコルデータユニット数フィールドに０を用いる請求項１１に記載の方法。
【請求項１３】
前記ＨＡＲＱ障害を，所定の値のデータ記述指示子を用いて示す請求項１に記載の方法。
【請求項１４】
前記データ記述指示子は，２進値１１１１１１を有する請求項１３に記載の方法。
【請求項１５】
ＨＡＲＱ障害の前記表示を報告する前記報告ステップを，デコードしたデータを含むデータフレームに前記報告を組み込むステップを用いて行う請求項１に記載の方法。
【請求項１６】
前記データフレーム内の前記ＨＡＲＱ障害表示ごとに，サブフレーム番号フィールドを１だけ増加させる請求項１５に記載の方法。
【請求項１７】
前記更なるネットワーク要素は，無線ネットワークコントローラとする請求項１に記載の方法。
【請求項１８】
計算機プロセッサが実行する計算機プログラムコードを組み込んだ計算機可読記憶構造を含む計算機プログラム製品であって，前記計算機プログラムコードは，前記ネットワーク要素又は前記更なるネットワーク要素の任意のコンポーネントによって実行するように指示された請求項１に記載の方法を実行する命令を含む計算機プログラム製品。
【請求項１９】
ハイブリッド自動再送要求プロトコルを用いて，アップリンクデータをデコードするよう試行するＨＡＲＱデコーダモジュールと，
更なるネットワーク要素に，前記の試行におけるＨＡＲＱ障害表示を選択的に報告する障害報告発生器であって，前記表示は，ＨＡＲＱ障害が起きるまでに何回かのＨＡＲＱ再送信試行を含む発生器と，
を備えるネットワーク要素。
【請求項２０】
前記ハイブリッド自動再送要求プロトコルは，前記ＨＡＲＱ障害が起きるまでにＮ回再送信を用いるように構成し，Ｎは最大許容再送信数を超えない少なくとも０である整数とする請求項１９に記載のネットワーク要素。
【請求項２１】
前記障害報告発生器は，所定の基準を用いて前記の試行をＨＡＲＱ障害と解釈するように構成する請求項１９に記載のネットワーク要素。
【請求項２２】
前記ネットワーク要素は，移動体無線通信用とする請求項１９に記載のネットワーク要素。
【請求項２３】
前記ＨＡＲＱデコーダモジュールと前記障害報告発生器とを１つのブロックに結合した請求項１９に記載のネットワーク要素。
【請求項２４】
前記ネットワーク要素がＨＡＲＱ障害を検出したときはいつでも，前記障害報告発生器が前記ＨＡＲＱ障害を報告するように構成した請求項１９に記載のネットワーク要素。
【請求項２５】
前記障害報告発生器が，ＨＡＲＱ障害の前記表示を，制御フレームを用いて報告するように構成した請求項１９に記載のネットワーク要素。
【請求項２６】
前記障害報告発生器が，ＨＡＲＱ障害の前記表示を，独立フレームを用いて報告するように構成した請求項１９に記載のネットワーク要素。
【請求項２７】
前記障害報告発生器が，ＨＡＲＱ障害の前記表示を，デコードしたデータを含むデータフレームに前記報告を組み込むステップを用いて報告するように構成した請求項１９に記載のネットワーク要素。
【請求項２８】
前記データフレーム内の前記ＨＡＲＱ障害表示ごとに，サブフレーム番号フィールドを１だけ増加させる請求項２７に記載のネットワーク要素。
【請求項２９】
前記ＨＡＲＱ障害を，所定の値の１ビットフラグを用いて示す請求項１９に記載のネットワーク要素。
【請求項３０】
前記ＨＡＲＱ障害を，所定の値のＭＡＣ−ｅｓプロトコルデータユニット数フィールドを用いて示す請求項１９に記載のネットワーク要素。
【請求項３１】
前記ＭＡＣ−ｅｓプロトコルデータユニット数フィールドに０を用いる請求項３０に記載のネットワーク要素。
【請求項３２】
前記ＨＡＲＱ障害を，所定の値のデータ記述指示子を用いて示す請求項１９に記載のネットワーク要素。
【請求項３３】
前記データ記述指示子に２進値１１１１１１を用いる請求項３２に記載のネットワーク要素。
【請求項３４】
前記障害報告発生器が，ＨＡＲＱ障害の前記表示をフレームプロトコルヘッダを用いて報告するように構成した請求項１９に記載のネットワーク要素。
【請求項３５】
アップリンクデータを送信及び再送信するユーザ装置と，
前記アップリンクデータ信号に反応して，ハイブリッド自動再送要求プロトコルを用いて前記アップリンクデータ信号に含まれるアップリンクデータをデコードし，前記の試行におけるＨＡＲＱ障害表示を含むＨＡＲＱ障害表示信号を提供するネットワーク要素であって，前記表示はＨＡＲＱ障害が起きるまでに何回かのＨＡＲＱ再送信試行を含むネットワーク要素と，
前記ＨＡＲＱ障害表示信号に反応する更なるネットワーク要素と，
を備える移動体通信システム。
【請求項３６】
前記ネットワーク要素は，所定の基準を用いて前記の試行をＨＡＲＱ障害と解釈するように構成した請求項３５に記載の移動体通信システム。
【請求項３７】
前記ネットワーク要素がＨＡＲＱ障害を検出したときはいつでも，前記障害報告発生器が，前記ＨＡＲＱ障害を報告するように構成した請求項３５に記載の移動体通信システム。
【請求項３８】
ハイブリッド自動再送要求プロトコルを用いてアップリンクデータをデコードするように試行するためのデコード手段と，
前記の試行におけるＨＡＲＱ障害表示を更なるネットワーク要素に選択的に報告するための報告手段であって，前記表示はＨＡＲＱ障害が起きるまでに何回かのＨＡＲＱ再送信試行を含む手段と，
を備えるネットワーク要素。
【請求項３９】
前記報告手段は，所定の基準を用いて前記の試行をＨＡＲＱ障害として解釈するように構成した障害報告発生器である請求項３８に記載のネットワーク要素。
【国際調査報告】
2008529437.tif 000017
2008529437.tif 000018
2008529437.tif 000019
2008529437.tif 000020