JP4819831B2 - Ｉｕｂインタフェースを介したＨＡＲＱ障害表示 - Google Patents

Description

本発明は概略移動体通信ネットワークに関し，より詳細に言えばＩｕｂインタフェースを介したＨＡＲＱ障害表示に関する。

図１ａに示すように，３Ｇ ＷＣＤＭＡ（第３世代広帯域符号分割多元接続）によれば，無線通信を介して通信しているとき，移動体ユーザ装置（ＵＥ）１８は，いわゆるＵｕインタフェースを介してＵＴＲＡＮ（はん用移動体通信システム（ＵＭＴＳ）地上無線接続ネットワーク）のノードＢ１７（時には基地局とも呼ばれる）に接続する。次にＵＴＲＡＮノードＢは，いわゆるＩｕｂインタフェースを介してＵＴＲＡＮ無線ネットワークコントローラ（ＲＮＣ）１１と通信し，そしてＲＮＣはいわゆるＩｕインタフェースを介して，コアネットワーク（ＣＮ），すなわち移動体通信交換センタ（ＭＳＣ）又はサービス提供ＧＰＲＳ（はん用パケット無線システム）サポートノード（ＳＧＳＮ）のいずれかと通信し，またいわゆるＩｕｒインタフェースを介してほかのＲＮＣとも通信する。より詳細に言えば，Ｉｕインタフェースは，ＵＴＲＡＮ ＲＮＣとＭＳＣとの間の回線交換インタフェースＩｕＣＳ，又はＵＴＲＡＮ ＲＮＣとＳＧＳＮとの間のパケット交換インタフェースＩｕＰＳ，のいずれかである。

３ＧＰＰのＥ−ＤＣＨ（強化個別チャネル）に関する技術資料文書，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，２００４年１２月，の６．１．１章に示されている一般原理に従う。（読み書きは，左から右，上から下，へ行う）。

図２（図３に対応する先行技術のみを示す）は，Ｅ−ＤＣＨ（強化個別チャネル）ＦＰデータフレームの一例をとりわけ示す図であり，それはいくつかの無線インタフェースＴＴＩのデータを１つのＦＰデータフレームへ結合させることに対応している。ＭＡＣ−ｅｓ ＰＤＵフィールド（８ビット）は，ＭＡＣ−ｅｓ ＰＤＵ数だけでなくヘッダ部の数も通知する。サブフレーム番号（３ビット）及びＨＡＲＱ再送信数（４ビット）は，ＭＡＣ−ｅｓ ＰＤＵごとに，ＤＤＩフィールド（６ビット）及びＭＡＣ−ｄ ＰＤＵ数フィールド（６ビット）と共に繰り返される。たとえ単一のサブフレームからなっているＭＡＣ−ｅｓ ＰＤＵであっても同一の構造を用いることができる。図２の方法の欠点は，たとえ各ＭＡＣ−ｅｓ ＰＤＵが同一のサブフレーム内で送信されるときであっても，サブフレーム番号フィールド及びＨＡＲＱ再送信数フィールドがＭＡＣ−ｅｓ ＰＤＵごとに繰り返されることである。

図３は代替フレーム構造であって，サブフレーム番号フィールド及びＨＡＲＱ再送信数フィールドはサブフレーム当たり１回だけ与えられ，一方，ＤＤＩフィールド及びＭＡＣ−ｄ ＰＤＵ数フィールドはＭＡＣ−ｅｓ ＰＤＵごとに繰り返される。ＭＡＣ−ｅｓ ＰＤＵ数フィールドは除去され，２レベルの拡張フラグ（Ｆ）で置き換えられた。サブフレーム番号と同一の行のフラグは，もう１つのサブフレームが続く（Ｆ＝１）か，否か（Ｆ＝０）を示す。１つのヘッダ部の終わり（ＭＡＣ−ｄ ＰＤＵ数フィールドの後）にある別のフラグは，同一のサブフレームのもう１つのヘッダ部が続く（Ｆ＝１）か，否か（Ｆ＝０）を示す。ＭＡＣ−ｅｓ ＰＤＵごとに１つのヘッダ部（ＤＤＩ及びＭＡＣ−ｄ ＰＤＵ数）がある。またこの構造は，１つのデータフレーム内の単一又は多数の無線インタフェースＴＴＩに対応する。この構造の利点は，サブフレーム番号フィールド及びＨＡＲＱ再送信数フィールドが不必要に繰り返されないことである。すなわち，１つのサブフレーム（例えば２ｍｓＴＴＩ）内で送信されるＭＡＣ−ｅｓ ＰＤＵは，同一のサブフレーム値及びＨＡＲＱ再送信数値を有する。あるいは，拡張フラグの意味を反転させてもよい（Ｆ＝０はもう１つのサブフレーム又はヘッダ部が続くことを示し，Ｆ＝１はこれが最後のサブフレーム又はヘッダ部であることをそれぞれ示す）。

次に，本発明の種々の実施例を，例えば図２及び３に示すフレーム構造を用いてどのように実現できるかを示す。これらは単に例であって，３ＧＰＰが規定した実際のＦＲデータフレームはこれらの例と異なることがあることに留意されたい。またＨＡＲＱ障害表示もそれによって変更される（特に，本発明の一部ではないフィールド）。

始めに独立の「ＨＡＲＱ障害表示フレーム」，すなわちＨＡＲＱ障害を示すためだけに用いられる別個のフレーム，を説明する。

図４に，図３のＦＰデータフレームを踏襲し，本発明の実施例による独立ＨＡＲＱ障害表示フレームのダイヤグラムの例をとりわけ示す。別個のＨＡＲＱ障害表示フレームを生成し，Ｉｕｂを介して送信するときは，フレームは図４に示すもののように見えるであろう。ＤＤＩフィールドは１１１１１１に設定されてＨＡＲＱ障害を示す。ＭＡＣ−ｄ ＰＤＵ数フィールドは０に設定するのが好ましく，ＭＡＣ−ｅｓ ＰＤＵが何も追加されていないことを示す。また拡張フラグ（Ｆ）も０に設定されて，後続のヘッダがないことを示す（第１フラグは後続のサブフレームがないことを示し，第２フラグは後続のヘッダ部（ＤＤＩフィールド及びＭＡＣ−ｄ ＰＤＵ数フィールド）がないことを示す）。「ＨＡＲＱ再送信数」フィールドは，本発明による実際の再送信試行数に設定される。ＣＦＮ及びサブフレーム番号は，いつこのブロックの最後の（再）送信試行が受信されたか，又はいつＨＡＲＱ障害をネットワーク要素（例えばノードＢ）が検出したか，を通知できる。またＣＦＮ及びサブフレームは，タイムスタンプとも呼ばれる。ヘッダＣＲＣは全フレーム（この場合はヘッダ）に渡って計算され，ここでＦＴ＝０（ＦＴはフレーム種別の略）であり，すなわちデータフレームを表している。

図５は，本発明の別の実施例による独立ＨＡＲＱ障害表示フレームの代替ダイヤグラムである。これは上述の別の代替データフレームによるものである（図２参照）。唯一の違いは，ＭＡＣ−ｅｓ ＰＤＵ数を示す方法である。ここでは拡張フラグが「ＭＡＣ−ｅｓ ＰＤＵ数」フィールドで置き換えられて，いくつのＭＡＣ−ｅｓ ＰＤＵ（及び対応するヘッダ部）が続くかを通知する。このフィールドは，０に設定して引き続くＭＡＣ−ｅｓ ＰＤＵがないことを示す（しかし１つのヘッダ部は読むことが望ましい）か，又は１に設定して１つのヘッダ部が続く（そしてＤＤＩ＝１１１１１１及びＮ＝０によってデータが何もないことを示す）ことを示すか，のいずれかであることが望ましい。ほかのフィールドは図４と同一である。

独立ＨＡＲＱ障害表示の第３代替案は，図６に示す制御フレームを用いることである（ＦＴ＝１が制御フレームであることを示す）。ここでは新たな制御フレーム種別によってＨＡＲＱ障害を示す（次の空き符号語，例えば００００１０１１を用いる）。次に必要なフィールド，すなわちＣＦＮと，サブフレーム番号（タイムスタンプである）と，ＨＡＲＱ再送信数と，だけを送信する（すなわち，ＤＤＩフィールド及びＭＡＣ−ｄ ＰＤＵ数フィールドは不要である）。

本発明によれば，同時に送信すべき適切なデータがあるときは，ほかのデータと共にＨＡＲＱ障害表示を送信するという別の代替案がある。この場合，図４及び５に示した上述のヘッダ部が，通常のデータヘッダ部と同時に送信される（図７から１０に示すとおり）。普通ＤＤＩフィールドは，論理チャネルｉｄ及び通常データのＭＡＣ−ｄ ＰＤＵサイズを通知する。特別な値のＤＤＩ（１１１１１１が好ましい）は，このヘッダ部がＨＡＲＱ障害表示であって，このヘッダ部に関連するデータはない（ＭＡＣ−ｅｓ ＰＤＵがない）ことを通知する。

この種の相乗りＨＡＲＱ障害表示に関する課題は，現在のデータフレームのＣＦＮが，失敗した送信のＣＦＮと同一であるかもしれないことである。これは，ＵＥが再送信ではなく新たな送信を開始したときに障害に気付いたときによくある事例である。その場合，ＨＡＲＱプロトコルの往復時間後に障害に気付く。この課題を解決するには，少なくとも２つの解決策がある。１）追加のＣＦＮをデータフレームに追加する（ヘッダに追加する（可変長ヘッダ部を意味する。図７参照。）か，又は１オクテットペイロードとして（図８参照）），それによってＣＦＮが失敗した送信が起きたフレームを通知する（障害表示は，対応するサブフレーム番号及びＨＡＲＱ再送信数と共に送信される）。２）ＨＡＲＱ障害表示ヘッダ部に負のＣＦＮオフセットを加える。例えば，ＭＡＣ−ｄ ＰＤＵフィールドの後の予備ビットをＣＦＮ＿ｏｆｆｓｅｔで置き換える（図９参照）。３ビットで０〜７フレームのオフセットが表示でき（符号なし整数表示を想定），それで十分である。このＣＦＮ＿ｏｆｆｓｅｔをデータフレームのＣＦＮから減算する。（別の代替案は，符号付き整数を用いることであるが，更にもう１ビットが必要になる。）本発明によれば，「ＨＡＲＱ再送信数」フィールドがＨＡＲＱ障害表示のために必要なため，これらすべての例においてＨＡＲＱ障害表示は独自のサブフレーム番号を有する。フラグだけでなく，サブフレーム番号と，ＨＡＲＱ再送信数と，ＤＤＩと，ＭＡＣ−ｄ ＰＤＵ数と，の各フィールドはヘッダ内の通常の位置にある。ＨＡＲＱ障害表示のＣＦＮだけが，これらの特別な配置を必要とする。ＨＡＲＱ障害表示のＣＦＮ及びサブフレーム番号は，ＨＡＲＱ障害表示のタイムスタンプの働きをする。

図２に示すデータフレーム形式を選択したとき，どのようにしてＨＡＲＱ障害表示をデータと共に相乗りさせることができるかを図１０に示す。

ＨＡＲＱ障害表示だけを含む独立データフレーム（図４及び５参照）については，（それを解決策として選択したときは）ＣＦＮ＿ｏｆｆｓｅｔフィールドも追加して，それを０とする（通常のＣＦＮが有効であることを示す）のが好ましい。類似して追加のＣＦＮを解決策として選択したときは，同一のヘッダ構造を有するように，それもまた独立ＨＡＲＱ障害表示フレーム内に置くのが好ましい。

図１１，１２，１３に本発明の更なる実施例を更に示す。

図１１は，本発明の実施例によるＨＡＲＱ障害表示を含むＥ−ＤＣＨ ＵＬデータフレームを示すダイヤグラムである。図１１のａはＨＡＲＱ障害表示を相乗りさせたものであり，ｂは独立のＨＡＲＱ障害表示である。

図１１において，ＨＡＲＱ障害表示のパラメータ設定は次のとおりである。
・「ＳＦＮ数」を１だけ増加させる（すなわち，１つのＳＦＮがＨＡＲＱ障害表示に用いられる）。例えば「第１ＳＦＮ」をＨＡＲＱ障害表示のＳＦＮに設定する。（ＳＦＮはサブフレーム番号であり，「ＳＦＮ数」は，サブフレーム番号の数である。すなわち，ＦＰヘッダ内にいくつのサブフレーム番号（ＳＦＮ）フィールドがあるかを通知する。）
・「ＭＡＣ−ｅｓ ＰＤＵ数」を１に設定する（１組のＤＤＩ及びＮが続くことを示す）。
・「ＨＡＲＱ再送信数」を障害までのＨＡＲＱ再送信試行数に設定する。
・「ＤＤＩ」を１１１１１１に設定する。
・「Ｎ」を００００００に設定して，この「ＭＡＣ−ｅｓ ＰＤＵ」にペイロードがないことを示す。

ＨＡＲＱ障害表示にペイロード部がないとき（例えば本発明の実施例において上述したように，ＨＡＲＱ障害のＣＦＮがペイロード内で送信されないとき）は，「ＭＡＣ−ｅｓ ＰＤＵ数」フィールドを０に設定してＨＡＲＱ障害を示す。すなわち本発明の実施例によれば，ＨＡＲＱ障害をＤＤＩ＝１１１１１１で示す代わりに，「ＭＡＣ−ｅｓ ＰＤＵ数」フィールドを０（又は一般に所定の値），又は１５（４ビットで表現できる最高値）に設定することによっても，同様にＨＡＲＱ障害を示すことができる。これはＦＰデータフレームにおいて最大２オクテット節約できるという利点がある。ＤＤＩ及びＮフィールドは省略できる。図１２に本発明のこの実施例を示す。

図１２は，本発明の実施例による，特定のＳＦＮに対してＭＡＣ−ｅｓ ＰＤＵ数＝０（又は一般に所定の値）によって，ＨＡＲＱ障害表示を示したＥ−ＤＣＨ ＵＬデータフレーム構造をとりわけ示すダイヤグラムの例である。図１２のａは，ＨＡＲＱ障害表示を相乗りさせたもの（明灰色部分が障害表示である），そしてｂは独立ＨＡＲＱ障害表示である。ＨＡＲＱ障害は，特定のＳＦＮに対してＭＡＣ−ｅｓ ＰＤＵ数＝０で示され，ＨＡＲＱ障害表示のための別個のＣＦＮはない。

図１２において，ＨＡＲＱ障害表示のパラメータ設定は次のとおりであってよい。
・「ＳＦＮ数」を１だけ増加させる（すなわち，１つのＳＦＮがＨＡＲＱ障害表示に用いられる）。
・「第１ＳＦＮ」をＨＡＲＱ障害表示のＳＦＮに設定する。
・「ＭＡＣ−ｅｓ ＰＤＵ数」を０に設定する（これは，ここではＨＡＲＱ障害表示であることを示す）。
・「ＨＡＲＱ再送信数」を障害までのＨＡＲＱ再送信試行数に設定する。
・「ＤＤＩ」及び「Ｎ」は置かない。

この場合，ＨＡＲＱ障害表示に関連するＭＡＣ−ｅｓ ＰＤＵはない。またＨＡＲＱ障害表示が単独であるときは（図１２のｂ参照），この代替案によってより短い構造が得られる。

本発明の更なる実施例によれば，構造を更に最適化できる可能性がまだある。ＨＡＲＱ障害表示は次の情報を有することが望ましい。すなわち，ＨＡＲＱ再送信数と，ＣＦＮ／ＳＦＮと，これがＨＡＲＱ障害表示である（そして通常のヘッダ部ではない）ことを示すいくつかの手段と，である。ＨＡＲＱ障害表示を示す最も単純な方法は，１ビットフラグ（Ｆ）を用いることである。図１３にこの概念を示す。

図１３は，本発明の実施例による，特定のＳＦＮに対してＦ＝１によって，ＨＡＲＱ障害表示を示したＥ−ＤＣＨ ＵＬデータフレーム構造をとりわけ示すダイヤグラムの例である。図１３のａは，ＨＡＲＱ障害表示を相乗りさせたもの（明灰色部分が障害表示である），そしてｂは独立ＨＡＲＱ障害表示である。

図１３に示すように，新たなフラグ（Ｆ）がヘッダに追加されている。このフラグは，ヘッダの当該部分がＨＡＲＱ障害表示用である（Ｆ＝１）か，又はＭＡＣ−ｅｓ ＰＤＵの通常のヘッダである（Ｆ＝０）か，を通知する。Ｆ＝１（ＨＡＲＱ障害表示）であるときは，ＨＡＲＱ再送信数フィールド及びＳＦＮフィールドが続く。これは，ＨＡＲＱ障害表示のために追加オクテットが１だけ必要であることを意味する。フラグが０（Ｆ＝０）に設定されているときは，通常のヘッダ部の後に，ＳＦＮと，ＭＡＣ−ｅｓ ＰＤＵ数と，ＨＡＲＱ再送信数と，ＤＤＩと，Ｎと，の各フィールドが続く。

図１３において，ＨＡＲＱ障害表示のパラメータ設定は次のとおりであってよい。
・ＨＡＲＱ障害表示ごとに「ＳＦＮ数」を１だけ増加させる（すなわち，ＨＡＲＱ障害表示ごとに１つのＳＦＮが用いられる）。
・「ＳＦＮ」をＨＡＲＱ障害表示のＳＦＮに設定する。
・「ＨＡＲＱ再送信数」を障害までのＨＡＲＱ再送信試行数に設定する。
・「ＭＡＣ−ｅｓ ＰＤＵ数」と，「ＤＤＩ」と，「Ｎ」と，は置かない。

この場合，ＨＡＲＱ障害表示に関連するＭＡＣ−ｅｓ ＰＤＵはない。またＨＡＲＱ障害表示が単独であるときは（図１３のｂ参照），この代替案によってより短い構造が得られる。ＳＦＮ数＝１は，ただ１つのＳＦＮがあることを通知し，Ｆ＝１はこれがＨＡＲＱ障害表示であることを通知する。

図１３に示したシナリオは多くの変形物が可能である。例えばＨＡＲＱ障害表示に別個のＣＦＮが必要なときは，ヘッダ内のＳＦＮの直後に完全なＣＦＮか，又はＣＦＮオフセットのいずれかとして追加してもよい。また，通常のヘッダ部だけでなく，ＨＡＲＱ障害表示についても，フィールドの位置を変更できることに気付くであろう。例えばＨＡＲＱ再送信数フィールドは，常に通常のヘッダ部内のＦフラグの後に置く方がよいであろう。更に，Ｆフラグの対応付けも当然入れ替えてよい。すなわち，Ｆ＝０はＨＡＲＱ障害を示すために用い，そしてＦ＝１は通常のヘッダ部を示すために用いてもよい。

上述のとおり本発明は，方法と，該方法の各ステップを実行する機能を提供する種々のモジュールからなる対応する装置と，の双方を提供する。各モジュールは，ハードウェアとして実現してもよいし，若しくは計算機プロセッサが実行するソフトウェア又はファームウェアとして実現してもよい。特にファームウェア又はソフトウェアの場合は，本発明は，計算機プロセッサが実行するための計算機プログラムコード（すなわちソフトウェア又はファームウェア）を組み込んだ計算機可読記憶構造を含む計算機プログラム製品として提供してもよい。

上述の構成は，本発明の原理の応用を例示するものに過ぎないことを理解されたい。本技術の当業者であれば，本発明の範囲を逸脱することなく，数々の修正物及び代替構成を考案できるであろう。添付の各請求項は，そのような修正物及び構成を包含することを意図したものである。

ＵＴＲＡＮと通信するユーザ装置（ＵＥ）を示すブロック図である。 本発明によるＩｕｂインタフェースを介するＨＡＲＱ障害表示を示すブロック図である。 本発明の実施例を実現するＦＰ（フレームプロトコル）データフレーム構造のダイヤグラムである。 本発明の実施例を実現するＦＰ（フレームプロトコル）データフレーム構造の代替ダイヤグラムである。 本発明の実施例による独立ＨＡＲＱ障害表示フレームのダイヤグラムである。 本発明の実施例による独立ＨＡＲＱ障害表示フレームの代替ダイヤグラムである。 本発明の実施例によるＨＡＲＱ障害表示制御フレームのダイヤグラムである。 本発明の実施例によるＨＡＲＱ障害表示を有するヘッダ部と通常のデータヘッダ部とを結合する種々の代替案を示すダイヤグラムである。 本発明の実施例によるＨＡＲＱ障害表示を有するヘッダ部と通常のデータヘッダ部とを結合する種々の代替案を示すダイヤグラムである。 本発明の実施例によるＨＡＲＱ障害表示を有するヘッダ部と通常のデータヘッダ部とを結合する種々の代替案を示すダイヤグラムである。 本発明の実施例によるＨＡＲＱ障害表示を有するヘッダ部と通常のデータヘッダ部とを結合する種々の代替案を示すダイヤグラムである。 本発明の実施例によるＨＡＲＱ障害表示を有するＥ−ＤＣＨ ＵＬデータフレーム構造であって，ａはＨＡＲＱ障害表示を相乗りさせたもの，ｂは独立ＨＡＲＱ障害表示，を示すダイヤグラムである。 本発明の実施例による特定のＳＦＮに対してＭＡＣ−ｅｓ ＰＤＵ数＝０によって示したＨＡＲＱ障害表示を有するＥ−ＤＣＨ ＵＬデータフレーム構造であって，ａはＨＡＲＱ障害表示を相乗りさせたもの，ｂは独立ＨＡＲＱ障害表示，を示すダイヤグラムである。 本発明の実施例による特定のＳＦＮに対してＦ＝１によって示したＨＡＲＱ障害表示を有するＥ−ＤＣＨ ＵＬデータフレーム構造であって，ａはＨＡＲＱ障害表示を相乗りさせたもの，ｂは独立ＨＡＲＱ障害表示，を示すダイヤグラムである。

Claims (32)

1. ノードＢが，ハイブリッド自動再送要求プロトコルを用いてアップリンクデータをデコードするように試行するステップと，
   前記の試行におけるハイブリッド自動再送要求障害の表示を無線ネットワークコントローラに選択的に報告する報告ステップと，
   を有し，
   前記表示はハイブリッド自動再送要求障害が起きるまでに実行されたハイブリッド自動再送要求再送信試行数の表示を含み，前記ハイブリッド自動再送要求障害は，ＭＡＣ−ｅｓプロトコルデータユニット数フィールドの所定の値を用いて表示される方法。
2. 前記ハイブリッド自動再送要求プロトコルは，前記ハイブリッド自動再送要求障害が起きるまでにＮ回までの再送信を用い，Ｎは最大許容再送信数を超えない少なくとも０である整数とする請求項１に記載の方法。
3. 前記ノードＢは，所定の基準を用いて前記ハイブリッド自動再送要求障害を判定する請求項１に記載の方法。
4. 前記ハイブリッド自動再送要求障害が起きた時刻，又は前記ノードＢが検出した時刻を更に報告するステップを更に有する請求項１に記載の方法。
5. 前記ノードＢがハイブリッド自動再送要求障害を検出したときはいつでも，前記ハイブリッド自動再送要求障害を報告する請求項１に記載の方法。
6. 前記ハイブリッド自動再送要求障害の表示を報告する前記報告ステップを，フレームプロトコルヘッダを用いて行う請求項１に記載の方法。
7. 前記ハイブリッド自動再送要求障害の表示を報告する前記報告ステップを，制御フレームを用いて行う請求項１に記載の方法。
8. 前記ハイブリッド自動再送要求障害の表示を報告する前記報告ステップを，独立フレームを用いて行う請求項１に記載の方法。
9. 前記ハイブリッド自動再送要求障害を，所定の値の１ビットフラグを用いて示す請求項１に記載の方法。
10. 前記ＭＡＣ−ｅｓプロトコルデータユニット数フィールドに０を用いる請求項１に記載の方法。
11. 前記ハイブリッド自動再送要求障害を，所定の値のデータ記述指示子を用いて示す請求項１に記載の方法。
12. 前記データ記述指示子は，２進値１１１１１１を有する請求項１１に記載の方法。
13. 前記ハイブリッド自動再送要求障害の表示を報告する前記報告ステップを，デコードしたデータを含むデータフレームに前記報告を組み込むステップを用いて行う請求項１に記載の方法。
14. 前記データフレーム内の前記ハイブリッド自動再送要求障害の表示ごとに，サブフレーム数フィールドを１だけ増加させる請求項１３に記載の方法。
15. 計算機プロセッサが実行する計算機プログラムコードを組み込んだ計算機可読記憶媒体であって，前記計算機プログラムコードは，前記ノードＢ又は前記無線ネットワークコントローラの任意のコンポーネントによって実行するように指示された請求項１に記載の方法を実行する命令を含む計算機可読記憶媒体。
16. プロセッサと，
    計算機プログラムコードを記憶させた記憶装置と，
    を備えたノードＢであって，
    前記計算機プログラムコードは前記プロセッサによって前記ノードＢが少なくとも，
    ハイブリッド自動再送要求プロトコルを用いて，アップリンクデータをデコードするよう試行し，
    無線ネットワークコントローラに，前記の試行におけるハイブリッド自動再送要求障害表示を選択的に報告する，
    ように構成され，
    前記表示は，ハイブリッド自動再送要求障害が起きるまでに実行されたハイブリッド自動再送要求再送信の数を含み，前記ハイブリッド自動再送要求障害は，ＭＡＣ−ｅｓプロトコルデータユニット数フィールドの所定の値を用いて表示される
    ノードＢ。
17. 前記ハイブリッド自動再送要求プロトコルは，前記ハイブリッド自動再送要求障害が起きるまでにＮ回までの再送信を用い，Ｎは最大許容再送信数を超えない少なくとも０である整数とする請求項１６に記載のノードＢ。
18. 前記記憶装置は，前記プロセッサによって前記ノードＢが所定の基準を用いて前記の試行をハイブリッド自動再送要求障害と判定するように構成された計算機プログラムコードを記憶する請求項１６に記載のノードＢ。
19. 前記ノードＢは，端末との移動体無線通信用とする請求項１６に記載のノードＢ。
20. 前記プロセッサ及び前記計算機プログラムコードを記憶させた記憶装置は，１つのブロックに結合されたハイブリッド自動再送要求デコーダモジュール及び障害報告発生器をなす請求項１６に記載のノードＢ。
21. 前記記憶装置は，前記プロセッサによって，前記ノードＢがハイブリッド自動再送要求障害を検出したときはいつでも，前記ノードＢが前記ハイブリッド自動再送要求障害を報告するように構成した計算機プログラムコードを記憶する請求項１６に記載のノードＢ。
22. 前記記憶装置は，前記プロセッサによって，ハイブリッド自動再送要求障害の前記表示を，前記ノードＢが制御フレームを用いて報告するように構成した計算機プログラムコードを記憶する請求項１６に記載のノードＢ。
23. 前記記憶装置は，前記プロセッサによって，ハイブリッド自動再送要求障害の前記表示を，前記ノードＢが独立フレームを用いて報告するように構成した計算機プログラムコードを記憶する請求項１６に記載のノードＢ。
24. 前記記憶装置は，前記プロセッサによって，ハイブリッド自動再送要求障害の前記表示を，前記ノードＢがデコードしたデータを含むデータフレームに前記報告を組み込むステップを用いて報告するように構成した計算機プログラムコードを記憶する請求項１６に記載のノードＢ。
25. 前記データフレーム内の前記ハイブリッド自動再送要求障害表示ごとに，サブフレーム数フィールドを１だけ増加させる請求項２４に記載のノードＢ。
26. 前記ハイブリッド自動再送要求障害を，所定の値の１ビットフラグを用いて示す請求項１６に記載のノードＢ。
27. 前記ＭＡＣ−ｅｓプロトコルデータユニット数フィールドに０を用いる請求項１６に記載のノードＢ。
28. 前記ハイブリッド自動再送要求障害を，所定の値のデータ記述指示子を用いて示す請求項１６に記載のノードＢ。
29. 前記データ記述指示子に２進値１１１１１１を用いる請求項２８に記載のノードＢ。
30. 前記記憶装置は，前記プロセッサによって，ハイブリッド自動再送要求障害の前記表示を，前記ノードＢがフレームプロトコルヘッダを用いて報告するように構成した計算機プログラムコードを記憶する請求項１６に記載のノードＢ。
31. ハイブリッド自動再送要求プロトコルを用いてアップリンクデータをデコードするように試行するためのデコード手段と，
    前記の試行におけるハイブリッド自動再送要求障害表示を無線ネットワークコントローラに選択的に報告するための報告手段と，
    を備え，
    前記表示はハイブリッド自動再送要求障害が起きるまでに実行されたハイブリッド自動再送要求再送信試行数を含み，前記ハイブリッド自動再送要求障害は，ＭＡＣ−ｅｓプロトコルデータユニット数フィールドの所定の値を用いて表示される
    ノードＢ。
32. 前記報告手段は，所定の基準を用いて前記の試行をハイブリッド自動再送要求障害として判定するように構成した障害報告発生器である請求項３１に記載のノードＢ。

Images