JP2009504007A

JP2009504007A - 無線通信システム内のアップリンク上の拡張データチャネルの容量を増大する方法

Info

Publication number: JP2009504007A
Application number: JP2008523931A
Authority: JP
Inventors: バクル，ライナー，ワルター; ラオ，アニル，エム．; シャハト，ミルコ; イ，ヘンリー，ヒュイ
Original assignee: ルーセントテクノロジーズインコーポレーテッド
Priority date: 2005-07-27
Filing date: 2006-07-14
Publication date: 2009-01-29
Also published as: KR20080035527A; WO2007015769A3; WO2007015769A2; EP1908231A2; CN101292470A; US20070025345A1

Abstract

ＵＭＴＳ無線通信システムで、ＵＥからノードＢへのアップリンク上の拡張専用物理データチャネル（Ｅ−ＤＰＤＣＨ）上のパケットサイズが収束デフォルトパケットサイズに達したときに、対応する専用物理制御チャネル（Ｅ−ＤＰＣＣＨ）の電源が切られる。ノードＢは、各可能な冗長バージョンを使用してＥ−ＤＰＤＣＨ上で受信されたフレームをデコードするためにデフォルトパケットサイズを使用する。代替として、ＵＥによって新規フレームが送信されたときにだけ、Ｅ−ＤＰＣＣＨの電源が切られ、ＵＥによって新規送信フラッグが送信される。次いで、ノードＢは、Ｅ−ＤＰＤＣＨ上で受信されたフレームをデコードする際にどの冗長バージョンが推定されるべきか判定するために、Ｅ−ＤＰＣＣＨの不在と併せて、そのフラッグの存在又は不在を使用する。

Description

本発明は、無線通信に関する。

無線通信ネットワークは、通常、無線接続又は有線接続によって結合され、様々なタイプの通信チャネルを通してアクセスされる様々な通信ノードを含む。各通信ノードは、通信チャネルを介して送受信されたデータを処理するプロトコルスタックを含む。通信システムのタイプに応じて、様々な通信ノードの動作及び構成は異なる可能性があり、異なる名称で呼ばれることも多い。そのような通信システムには、たとえば、符号分割多元接続２０００（ＣＤＭＡ２０００）システム及びユニバーサル移動体通信システム（ＵＭＴＳ）がある。

第３世代無線通信プロトコル規格（たとえば、３ＧＰＰ−ＵＭＴＳ、３ＧＰＰ２−ＣＤＭＡ２０００など）は、アップリンク（たとえば、移動局（ＭＳ）又はユーザ機器（ＵＥ）と、基地局（ＢＳ）又はノードＢとの間の通信の流れ）で専用トラフィックチャネルを利用してもよい。専用物理チャネルは、データ部分（たとえば、ＵＭＴＳリリース４／５プロトコルに準拠した専用物理データチャネル（ＤＰＤＣＨ）、ＣＤＭＡ２０００プロトコルに準拠した基本チャネル又は補足チャネルなど）、及び制御部分（たとえば、ＵＭＴＳリリース４／５プロトコルに準拠した専用物理制御チャネル（ＤＰＣＣＨ）、ＣＤＭＡ２０００プロトコルに準拠したパイロット／電力制御サブチャネルなど）を含んでもよい。

これらの規格のより新しいバージョン、たとえば、ＵＭＴＳのリリース６は、拡張専用物理チャネルと呼ばれる高データ速度アップリンクチャネルを規定する。これらの拡張専用物理チャネルは、拡張データ部分（たとえば、ＵＭＴＳプロトコルに準拠した拡張専用物理データチャネル［Ｅ−ＤＰＤＣＨ］）及び拡張制御部分（たとえば、ＵＭＴＳプロトコルに準拠した拡張専用物理制御チャネル［Ｅ−ＤＰＣＣＨ］）を含んでもよい。拡張アップリンク・データ・チャネルの仕様で定義されているように、ＵＥは、Ｅ−ＤＰＣＣＨチャネル内の制御情報のフレームと同時にＥ−ＤＰＤＣＨ内のパケットデータのフレームを送信する。ＵＥからノードＢに伝達されたこの制御情報は、ノードＢがＥ−ＤＰＤＣＨフレームをデコードするために一般に必要なパラメータを含む。Ｅ−ＤＰＣＣＨワードは、ノードＢがＥ−ＤＰＤＣＨデータパケットのサイズを判定することができる情報をノードＢに提供する７つのＴＦＩ（トランスポート・フォーマット・インジケータ）ビットを含む。このサイズ情報は、パケットサイズがアプリケーションのタイプ及びパケットデータ通信の動的な性質に基づいて変わる可能性があるので、必要である。一般に、２つのフレームサイズ（ＴＴＩの長さ）、すなわち、１０ｍｓ及び２ｍｓがＥ−ＤＰＤＣＨで使用するために利用可能である。さらに、Ｅ−ＤＰＤＣＨワードは、データパケットの冗長バージョンを示す２つのＲＳＮ（再送信シーケンス番号）ビットを含む。冗長バージョンは、ノードＢが、パケットがパケットの最初の送信か、又はパケットのＨＡＲＱ（ハイブリッド自動再送要求）再送信か、及び詳細には、パケットがデータパケットの第２の送信か、第３の送信か、又は第４の送信か知る必要があるので、必要である。前の送信が、ＵＥと通信している可能性があるいずれのノードＢによっても肯定応答されなかった場合、通信しているすべてのノードＢから否定応答（ＮＡＣＫ）を受信するか、又は同じパケットの再送信の最大許容数に達した場合、肯定応答（ＡＣＫ）が少なくとも１つのノードＢから受信されない限り、ＵＥは同じパケットを再送信することになる。したがって、ノードＢが前にパケット送信をデコードすることができなかったとしても、ＵＥが通信していた別のノードＢによって前のデータパケットが肯定応答された可能性があるので、ＵＥが別のデータパケットの新規の送信又は前のデータパケットの再送信を送信するかどうかノードＢは予測することができない。Ｅ−ＤＰＣＣＨワードはまた、ＵＥがより高い又はより低い速度で送信することを望むことをノードＢに示す単一のハッピービット（Ｈビット）を含む。Ｅ−ＤＰＣＣＨワードは１０ビットを含む。

Ｅ−ＤＰＣＣＨは、通常、ノードＢがこのチャネルを正しくデコードすることができることを保証するのに十分な電力で送信される。大きなデータパケットを有するＥ−ＤＰＤＣＨを送信するＵＥでは、Ｅ−ＤＰＣＣＨチャネルに与えられた総電力は、すべてのＥ−ＤＰＤＣＨチャネルに与えられた電力の小さな部分に過ぎない。しかし、ＶｏＩＰ（ボイスオーバＩＰ）などのアプリケーションでは、ＵＥは小さなデータパケットだけを有するＥ−ＤＰＤＣＨを送信する。この後者の場合には、Ｅ−ＤＰＣＣＨに与えられた電力は、同じＵＥの対応するＥ−ＤＰＤＣＨパケットに与えられた電力に比べてかなり大きい。また、ＵＥがＥ−ＤＰＤＣＨ上で低データ速度で送信しているときはいつでもそうであるが、Ｅ−ＤＰＣＣＨ電力がＥ−ＤＰＤＣＨ電力に比べてかなり大きい別の状態もある。特に、非常に低いデータ速度が、重く負荷されたセル内で不利なパス損失状態にあるＵＥに割当てられることが多い。

不利なことには、Ｅ−ＤＰＣＣＨを送信するために必要とされる追加の電力は、逆のチャネル上の全体の容量をかなり大きく低減する可能性がある。前述のように、２つの異なるフレームサイズ（１０ｍｓ及び２ｍｓのＴＴＩ長）がある。ＶｏＩＰアプリケーションでは、特に改善された時間ダイバーシティにつながるより大きな数のＨＡＲＱ再送信を使用する場合、１０ｍｓのＴＴＩ長に比べてより小さい遅延を導入するので、２ｍｓのＴＴＩ長のほうが好まれることもある。しかし、２ｍｓのＴＴＩでは、１０ｍｓのＴＴＩ長の場合に比べてより高い有効Ｅ−ＤＰＣＣＨデータ速度及びより小さいダイバーシティ利得があるので、Ｅ−ＤＰＣＣＨによるオーバーヘッドはずっと大きい。

本発明の一実施形態によれば、必要とされるＥ−ＤＰＣＣＨ電力がかなり大きく低減され、したがって、予め決められた条件がＥ−ＤＰＤＣＨ上にあると判定された場合、Ｅ−ＤＰＣＣＨ上で送信されるデータの量を低減することによって、拡張アップリンク・データ・チャネルを使用するアプリケーションのための容量が大きく増大される。

例示的諸実施形態では、データ速度が通常変化せず一定のままであるＶｏＩＰなどのアプリケーションでは、Ｅ−ＤＰＣＣＨ上で搬送される情報が冗長になるので、ＵＥはＥ−ＤＰＤＣＨフレーム送信ごとにＥ−ＤＰＤＣＨパケットサイズをノードＢに通知する必要がない。しかし、ノードＢとＵＥとの間の通信の初期段階では、Ｅ−ＤＰＤＣＨパケットサイズはそれでもなお送信のいわゆる「強靭性」の欠如のために様々である可能性がある。強靭性が達成された後は、パケットサイズは稼動している特定のアプリケーション（特定のデータ速度のＶｏＩＰなど）に対応する値に収束する。以下では「デフォルトパケットサイズ」と呼ばれるＥ−ＤＰＤＣＨ上の収束パケットサイズに達した後は、Ｅ−ＤＰＣＣＨ上で送信されるデータの量が低減される。

第一実施形態では、強靭性が達成された場合にそうであるが、対応するＥ−ＤＰＤＣＨパケットサイズがデフォルトパケットサイズに一致した場合、Ｅ−ＤＰＣＣＨの電源が完全に切られる。Ｅ−ＤＰＣＣＨの電源が切られたときに、ノードＢはデフォルトパケットサイズを使用することを知る。しかし、ノードＢは、ＵＥが新規のデータパケットを送信しているのか、又は前に送信されたデータパケットを再送信しているのかに関しては分からない。したがって、ノードＢは、現在受信されたＴＴＩのためのすべての可能な冗長バージョンに基づいて、複数回、各データパケットをデコードする必要がある。データパケットの最大送信数がＮであれば、ノードＢは各Ｅ−ＤＰＤＣＨデータパケットを推定された送信又は再送信ごとにＮ回までデコードし、デコーディングが良好なＣＲＣチェックで成功したとき、又はＮ回の試行がすべて失敗したときに、停止する。

本発明の第２の例示的実施形態では、対応するＥ−ＤＰＤＣＨパケットサイズがデフォルトパケットサイズに一致した場合、Ｅ−ＤＰＣＣＨの電源が再び切られるが、新規のＥ−ＤＰＤＣＨフレームが送信されたときだけ、ＵＥによって単一ビットフラッグなどの最小ビット長の新規の送信フラッグがノードＢに送信される。したがって、ノードＢがＥ−ＤＰＣＣＨ送信を検出しないが、新規送信フラッグを検出した場合、ノードＢは、デフォルトパケットサイズを使用し、Ｅ−ＤＰＤＣＨ上の送信を新規送信（０に等しい冗長バージョン）であると推定する。ノードＢがＥ−ＤＰＣＣＨ送信も新規送信フラッグも検出しなかった場合、前の冗長バージョンに１つ追加し、Ｅ−ＤＰＤＣＨをデコードしようと試みる。新規送信フラッグは、現在のＥ−ＤＰＣＣＨ上に特定のコードワードを追加することによって、又は個別の物理コードチャネルによって、ＵＥからノードＢに送信されることができる。

図１を参照すると、拡張データチャネル上で、ソフト・ハンドオフ状態で、ノードＢ１０２とノードＢ１０３の両方と通信しているＵＥ１０１が示されている。同じマルチノードＢ（又はマルチ基地局）コントローラ１０４に接続され、本明細書及びＵＭＴＳ専門用語ではＲＮＣ（無線ネットワーク・コントローラ）と呼ばれるノードＢ１０２及びノードＢ１０３が例示的に示されている。明瞭のために、ＲＮＣ１０４のコアネットワークへの接続は示されていないが、当業者によって存在すると理解される。１０５で示された送信は、ＵＥ１０１がアップリンク上でパケットをＥ−ＤＰＤＣＨ及びＥ−ＤＰＣＣＨを通してノードＢ１０２及び１０３に送信していることを示す。ノードＢ１０２及び１０３は両方とも、Ｅ−ＤＰＤＣＨ及びＥ−ＤＰＣＣＨ送信を独自にデコードしようと試みる。Ｅ−ＤＰＤＣＨパケットがノードＢ１０２又はノードＢ１０３のいずれかによって首尾よくデコードされた場合は、パケットをデコードしたノードＢがノードＢ１０２からの送信１０６、又はノードＢ１０３からの送信１０７のいずれかによって肯定応答（ＡＣＫ）をＵＥ１０１に送信する。ＵＥ１０１は、ノードＢ１０２又はノードＢ１０３のいずれかからＡＣＫを受信した場合は、その後で新規データパケットを送信する。ＵＥ１０１は、ノードＢ１０２及び１０３の両方から否定応答（ＮＡＣＫ）を受信した場合は、同じデータパケットを再送信する。そのパケットの再送信手順は、ＡＣＫがノードＢの１つから受信されるか、又は再送信の最大許容数に達したときに終了する。

図２は、Ｅ−ＤＰＤＣＨ及びＥ−ＤＰＣＣＨ送信に関する例示的タイミング図、並びに現在の技術（３ＧＰＰリリース６規格）に定義されている再送信手順を示す。このタイミング図は１０ｍｓのＴＴＩ用であるが、記載されているものは、ＶｏＩＰで使用される可能性が最も大きいであろう２ｍｓのＴＴＩにも同様に適用可能である。図から分かるように、Ｅ−ＤＰＤＣＨ送信は、常に、対応するＥ−ＤＰＣＣＨ送信を伴う。前述のように、各Ｅ−ＤＰＣＣＨワードは、合計１０ビットごとに３つの情報、すなわち、ＲＳＮ（再送信シーケンス番号）、ＴＦＩ（トランスポート・フォーマット・インジケータ）、及びＨビット（ハッピービット）を含む。ＵＥが「第１ＴＸ」によって示されたフレーム０でＥ−ＤＰＤＣＨ上の新規パケット送信２０１を開始したときに、アップリンク上で対応するＥ−ＤＰＣＣＨ送信２０２が行われる。例示のために、ＵＥがフレーム２ですべてのノードＢからＮＡＣＫ２０３を受信したと仮定すると、その同じパケットのＥ−ＤＰＤＣＨ再送信２０４（第２ＴＸ）が、やはり対応するＥ−ＤＰＣＣＨ送信２０５を伴うフレーム４で行われる。この実施例では、ＵＥはそれでもなお、フレーム４での送信が失敗したことを示すＮＡＣＫ２０６をフレーム６で受信する。したがって、フレーム８で別のＥ−ＤＰＤＣＨ再送信２０７（第３ＴＸ）及び付随するＥ−ＤＰＣＣＨ送信２０８が行われる。この実施例では、Ｅ−ＤＰＤＣＨ送信２０７が首尾よく受信され、フレーム１０で、ＡＣＫ２０９がノードＢによってＵＥに送り返される。ＡＣＫ応答を受信すると、ＵＥがフレーム１２で新規データパケットＥ−ＤＰＤＣＨ送信２１０及び付随するＥ−ＤＰＣＣＨ送信２１１を行う。

アップリンク上で拡張データチャネルを使用するそれらのアプリケーションのための容量は、データ速度が通常変化せず一定のままであるＶｏＩＰなどのアプリケーションのために必要とされるＥ−ＤＰＣＣＨ電力を低減することによって増大される。たとえば、ＶｏＩＰユーザのデータ速度が、そのユーザの特定のボコーダによって判定されることができる。その結果として、Ｅ−ＤＰＤＣＨパケットサイズも一般に一定であり、その具体的なサイズはボコーダ依存である。この場合、Ｅ−ＤＰＣＣＨ上で搬送された情報が冗長になるので、ＵＥがノードＢにＥ−ＤＰＤＣＨフレーム送信ごとにＥ−ＤＰＤＣＨパケットサイズを通知する必要はない。

ノードＢとＵＥとの間の通信の初期段階では、Ｅ−ＤＰＤＣＨパケットサイズはそれでもなお、送信のいわゆる「強靭性」の欠如のために変わる可能性がある。強靭性が達成された後は、パケットサイズは、特定のデータ速度のＶｏＩＰなどの特定のアプリケーションに対応する値に収束する。３ＧＰＰリリース５及びリリース６規格によれば、強靭なヘッダ圧縮（ＲｏＨＣ、ＲＦＣ３０９５）の使用が詳述されている。ここでは、初期パケットのヘッダサイズは大きい、すなわち圧縮されていない。圧縮コンテキストが受信側で確立された後では、一定のサイズ、通常３バイトの最小ヘッダだけが送信される。ヘッダ更新の手順が詳述されているが、ＶｏＩＰアプリケーションでは、最高の圧縮状態に達した後は、ヘッダサイズが変化しないことが予測されることができる。前述のように、収束パケットサイズは、以下の記述及び特許請求の範囲では、「デフォルトパケットサイズ」と呼ばれる。本明細書に記載の本発明の諸実施形態は、Ｅ−ＤＰＤＣＨデフォルトパケットサイズが知られているＶｏＩＰなどの、しかしＶｏＩＰに限定されない、アプリケーションに適用可能である。デコンプレッサがコンプレッサに状態情報を示すことができるように、Ｏモード及びＲモードなど、いくつかのＲｏＨＣのモードがヘッダでフィードバックを利用することが留意される。これらの場合、ヘッダサイズが追加の２つのバイトによって最小サイズから変わる。ここでは、ＲｏＨＣヘッダにフィードバックがある場合、総ＶｏＩＰパケットサイズの間に違いがないように最小パケットサイズにパッディングビットが追加されるという推定が行われることができ、したがって、フィードバックの使用が「デフォルトパケットサイズ」と呼ばれるものを変更しない。

第１の例示的実施形態によれば、強靭性が達成された後での場合であるが、対応するＥ−ＤＰＤＣＨパケットサイズがデフォルトパケットサイズに一致するときはいつでも、Ｅ−ＤＰＣＣＨの電源が完全に切られる。有利なことには、Ｅ−ＤＰＣＣＨの電源を切ることは、エアーインターフェース容量をかなり大きく改善する。Ｅ−ＤＰＣＣＨの電源が切られている間、ＵＥは第１ノードＢから第２ノードＢへのハンドオフ状態にあってもよい。第２ノードＢは、特定のアプリケーションに基づいてデフォルトＥ−ＤＰＤＣＨパケットサイズを判定することができ、したがって、Ｅ−ＤＰＣＣＨチャネルをデコードすることができないときはいつでも、Ｅ−ＤＰＤＣＨのためのデフォルト・サイズを推定することができる。代替として、特定のノードＢが特定のＵＥのためのアクティブセットに追加されるときはいつでも、ノードＢにそのＵＥ及びＨＡＲＱプロセスのためのデフォルトパケットサイズを通知する手順がＲＮＣに導入されることもできる。これは、デフォルトパケットサイズのシグナル通知が現在の標準仕様では現在サポートされていないので、規格の変更を必要とする。ＶｏＩＰのようなアプリケーションのための増大された容量の利点があれば、そのような規格の変更は受け容れられる可能性があるであろう。

図３は、Ｅ−ＤＰＤＣＨパケットサイズがＶｏＩＰのようなアプリケーションのためのデフォルトパケットサイズに達したときにＥ−ＤＰＣＣＨの電源が完全に切られるこの第１実施形態による図２のタイミング図の変更形態を示す。前述のように、このタイミング図は、図２の場合と同様に、１０ｍｓのＴＴＩのためのものであるが、ＴＴＩが２ｍｓに等しい場合にも同様に適用可能である。

Ｅ−ＤＰＣＣＨの電源がこの第１実施形態のように完全に切られた場合、処理するノードＢが、必然的に、より複雑になる。前述のように、Ｅ−ＤＰＣＣＨがノードＢに運搬する２つの最も重要なパラメータ値はパケットサイズ及び冗長バージョンである。Ｅ−ＤＰＣＣＨの電源が切られた場合、ノードＢはＶｏＩＰのようなアプリケーションのためにデフォルトパケットサイズを使用することを知っているが、ノードＢは、ＵＥが新規データパケットを送信しているのか、又は前に送信されたデータパケットを再送信しているのかについては分からないままである。したがって、ノードＢは、Ｅ−ＤＰＤＣＨ上で受信された各データパケットを現在受信されたＴＴＩのためのすべての可能な冗長バージョンに基づいて複数回デコードする必要がある。たとえば、ＶｏＩＰユーザのデータパケットのための送信（オリジナル送信及び再送信）の最大許容数がＮである（すなわち、Ｎ−１までの再送信が許容される）と仮定すると、ノードＢは、各Ｅ−ＤＰＤＣＨデータパケットをＮ回までデコードする必要があり、最初に新規送信であると推定してデータパケットをデコードし、失敗した場合は、最初の再送信であると推定してデータパケットをデコードし、その後同様にデコードし、最後に、すべての先行する努力が失敗した場合は、第（Ｎ−１）の再送信であると推定してデータパケットをデコードする。この手順は、デコーディングが「良好な」ＣＲＣチェックで成功した場合か、又はＮ回の試行がすべて失敗した場合か、いずれかの場合に停止する。

ノードＢの中でこの複数デコーディング方式を実施することは、Ｎ回までのデコーディングによってデコーディングの複雑さを増大する。実際には、Ｎは２〜４又は２〜６の範囲の値を有する。一般にデータパケットサイズが小さいＵＥでＥ−ＤＰＣＣＨのスイッチが切られた場合、それらのＵＥにさらにＮ回のデコーディング容量を求めることは、いくらか低い割合のデコーディングのために全体のノードＢの実施の複雑さを増大するだけである可能性がある。

本実施形態の要約は次のとおりである。
Ｅ−ＤＰＤＣＨデータ速度が一定であり、デフォルトＥ−ＤＰＤＣＨパケットサイズが知られているアプリケーションを有するＵＥでは、ＵＥは、対応するＥ−ＤＰＤＣＨパケットサイズがデフォルトパケットサイズに等しいときはいつでも、Ｅ−ＤＰＣＣＨ送信のスイッチを切る。初期期間の後ではＥ−ＤＰＤＣＨパケットサイズがデフォルトパケットサイズに収束するので、その場合、Ｅ−ＤＰＣＣＨのスイッチはほとんどの時間切られていて、したがって、Ｅ−ＤＰＣＣＨによって消費されるエアーインターフェース・リソースがかなり大きく低減される。

ノードＢは、従来技術の場合と同様に、ずっとＥ−ＤＰＣＣＨを検出しデコードしようとする。ノードＢがＥ−ＤＰＣＣＨ送信を検出し、デコードすることができた場合は、ノードＢは、対応する同時に送信されたＥ−ＤＰＤＣＨフレームをデコードするために、デコードされたＥ−ＤＰＣＣＨからのパケットサイズ及び冗長情報を使用する。しかし、Ｅ−ＤＰＣＣＨが検出されることができなかった場合、ノードＢは、デフォルトパケットサイズがＵＥによって使用されたと推定し、直近に受信されたＥ−ＤＰＤＣＨフレームのためのすべての可能な冗長バージョン数に基づいて、複数回、受信されたＥ−ＤＰＤＣＨフレームをデコードしようと試みる。

（１）特定のＵＥのアクティブセットに追加されたノードＢにデフォルトデータパケットサイズをシグナル通知するように、及び（２）対応するＥ−ＤＰＤＣＨパケットサイズがデフォルトパケットサイズに等しいときはいつでもＥ−ＤＰＣＣＨのスイッチを切るように、規格が変更される必要がある。

第２の例示的実施形態は、ノードＢで複数回Ｅ−ＤＰＤＣＨをデコードする必要性を回避する。この実施形態によれば、対応するＥ−ＤＰＤＣＨパケットサイズがデフォルトパケットサイズに等しいときはいつでもＥ−ＤＰＣＣＨの電源が切られ、さらに、Ｅ−ＤＰＣＣＨのスイッチが切られている間に新規Ｅ−ＤＰＤＣＨフレームが送信されたときはいつでも１ビット「新規送信」フラッグ（新規ｔｘフラッグ）が送信される。

したがって、ノードＢは次のとおりに機能する。ノードＢがＥ−ＤＰＣＣＨ送信を検出したが、新規ｔｘフラッグを検出しなかった場合は、デコードされたＥ−ＤＰＣＣＨフレームからの冗長バージョン及びパケットサイズ情報がＥ−ＤＰＤＣＨをデコードするために使用される。ノードＢがＥ−ＤＰＣＣＨ送信を検出しなかったが、新規ｔｘフラッグを検出した場合は、ノードＢはＥ−ＤＰＤＣＨフレームをデコードするためにデフォルトパケットサイズ及び０に等しい冗長バージョンを使用する。ノードＢがＥ−ＤＰＣＣＨも新規ｔｘフラッグも検出しなかった場合は、ノードＢはＥ−ＤＰＤＣＨフレームをデコードするためにデフォルトパケットサイズ及び前の冗長バージョン＋１に等しい冗長バーションを使用する。これは、ＵＥによって使用された冗長バージョンと同期するために、ノードＢが、常に、最後に検出された新規ｔｘフラッグを使用することを意味する。

図４は、Ｅ−ＤＰＣＣＨと、１ビット新規ｔｘフラッグと、Ｅ−ＤＰＤＣＨと、第２実施形態に従ってＵＥによって受信されたＡＣＫ／ＮＡＣＫとの間のタイミング関係を示す。図から分かるように、Ｅ−ＤＰＣＣＨの電源が切られる。単一ビットの新規ｔｘフラッグは、Ｅ−ＤＰＤＣＨが同時に新規送信を行っているときは、フレーム０と１２の間でだけ送信される。Ｅ−ＤＰＤＣＨフレームの第２及び第３送信がそれぞれフレーム２及び６でのＮＡＣＫの受信に応答して行われるときは、フラッグ及びＥ−ＤＰＣＣＨはフレーム４と８の間では１つも送信されない。

第１実施形態と比べて、第２実施形態は、新規ｔｘフラッグを送信するために最小のエアーインターフェース・リソースを消費することを犠牲にして、同じＥ−ＤＰＤＣＨフレームを複数回デコードする必要性を排除することによって、ノードＢの実装を簡略化する。新規ｔｘフラッグは、現在のＥ−ＤＰＣＣＨ上に特定のコードワードを追加することによって、又は個別の物理コードチャネルによって、ＵＥからノードＢに送信されることもできる。新規送信のためだけに単一ビットを送信するための電力消費は、従来技術のように各Ｅ−ＤＰＤＣＨに対して１０ビットＥ−ＤＰＣＣＨフレームを送信するための電力消費よりかなり少ない。したがって、新規ｔｘフラッグ送信は、Ｅ−ＤＰＣＣＨ送信のために必要とされるよりもずっと少ないリソースを使用する。

第２実施形態の要約は次のとおりである。
ＵＥの振る舞いは、Ｅ−ＤＰＣＣＨのスイッチが切られ、Ｅ−ＤＰＤＣＨデータパケットが初めて送信されるときはいつでも、１ビット新規ｔｘフラッグがノードＢに送信されることを除いては、上記で第１実施形態に関連して説明したものと同じである。

ノードＢは、ノードＢが新規ｔｘフラッグを受信するかどうか、及び通常のＥ−ＤＰＣＣＨがＵＥによって送信されたかどうか、検出する。Ｅ−ＤＰＣＣＨが検出された場合は、ノードＢはデコードされたＥ−ＤＰＣＣＨ送信からのパケットサイズ及び冗長バージョン情報を使用する。新規ｔｘフラッグが検出された場合は、ノードＢはそれを使用して冗長バージョンをＵＥと同期させ、Ｅ−ＤＰＤＣＨのデフォルトパケットサイズを推定する。新規ｔｘフラッグもＥ−ＤＰＣＣＨも検出されなかった場合は、ノードＢは、Ｅ−ＤＰＤＣＨのためのデフォルトパケットサイズを推定し、前に検出されたＥ−ＤＰＣＣＨ又は新規ｔｘフラッグから冗長バージョンを推論する。

（１）デフォルトデータパケットサイズをシグナル通知するように、（２）対応するＥ−ＤＰＤＣＨパケットサイズがデフォルトパケットサイズに等しいときはいつでもＥ−ＤＰＣＣＨのスイッチを切るように、及び（３）新規ｔｘフラッグを導入するように、規格が変更される必要がある。

ハッピー（Ｈ）ビットは、通常、遅延に敏感なＶｏＩＰなどのアプリケーションのためには使用されない。したがって、デフォルトパケットサイズがＥ−ＤＰＤＣＨ上で送信されているときにＥ−ＤＰＣＣＨの電源を切り、その情報を提供しないことは、有害な結果を生じないであろう。

上記ではＵＭＴＳ規格に準拠している諸実施形態に関連して説明されたが、本発明は、高速データパケットチャネル及び付随する制御チャネルが、たとえば、ＥＶＤＯ規格、ＷｉＭＡＸ規格、又はすでに採用されている若しくは提案されているその他の規格、あるいはまだ採用されていない、又は提案されていない規格に準拠する無線システムなどの移動端末及び基地局又は同様の装置の間のアップリンク若しくはダウンリンク上で送信される他の無線規格にも適用可能である。

従来技術による、ソフト・ハンドオフ状態で、Ｅ−ＤＰＤＣＨ及びＥ−ＤＰＣＣＨ上のアップリンク上で、２つのノードＢと通信しているＵＥを示すブロック図である。Ｅ−ＤＰＣＣＨと、Ｅ−ＤＰＤＣＨと、Ｅ−ＤＰＤＣＨ送信に応答してノードＢによって受信されたＡＣＫ／ＮＡＣＫとの間の従来技術のタイミング関係を示す図である。本発明の第１実施形態による、Ｅ−ＤＰＣＣＨと、Ｅ−ＤＰＤＣＨと、Ｅ−ＤＰＤＣＨ送信に応答してノードＢによって受信されたＡＣＫ／ＮＡＣＫとの間のタイミング関係を示す図である。本発明の第２実施形態による、新規送信フラッグと、Ｅ−ＤＰＣＣＨと、Ｅ−ＤＰＤＣＨと、Ｅ−ＤＰＤＣＨ送信に応答してノードＢによって受信されたＡＣＫ／ＮＡＣＫとの間のタイミング関係を示す図である。

Claims

無線通信システムにおける方法であって、
専用物理データチャネル上で送信されるデータパケットのサイズがデフォルトデータパケットサイズに一致した場合に、前記専用物理データチャネルに関連する専用物理制御チャネル上で送信される制御情報を低減するステップであって、該制御情報が前記専用物理データチャネル上で受信された前記データパケットをデコードするために使用される、ステップからなる方法。
前記専用物理データチャネル上で送信される前記パケットのサイズが前記デフォルトデータパケットサイズに一致した場合、前記関連する専用物理制御チャネル上で制御情報を送信しない請求項１記載の方法。
前記専用物理データチャネル上で送信される前記パケットのサイズが前記デフォルトデータパケットサイズに一致した場合、そのパケットが新規のパケットである場合にだけ前記専用データパケットチャネル上で送信されたパケットに関連するフラッグを送信し、前記パケットが前に送信されたパケットの再送信である場合にはそうしない請求項１記載の方法。
前記専用物理データチャネルが拡張専用物理データチャネル（Ｅ−ＤＰＤＣＨ）であり、前記専用物理制御チャネルが関連する拡張専用物理制御チャネル（Ｅ−ＤＰＣＣＨ）であり、両方ともユニバーサル移動体通信システム（ＵＭＴＳ）内のアップリンク上で送信される請求項１記載の方法。
無線通信システムにおける方法であって、
パケットが専用物理データチャネル上で受信され、対応する制御情報が前記専用物理データチャネルに関連する専用物理制御チャネル上で受信されず、該制御情報が存在する場合に前記専用物理データチャネル上で前記データをデコードするために使用される場合は、前記受信されたパケットをデコードするためにデフォルトデータパケットサイズを使用するステップからなる方法。
請求項５記載の方法であって、さらに、
前記受信されたパケットの可能な冗長バージョンごとに前記受信されたパケットをデコードしようと試みるステップからなる方法。
請求項５記載の方法であって、さらに、
前記受信されたパケットをデコードする前に前記デフォルトデータパケットサイズを受信するステップからなる方法。
請求項５記載の方法であって、さらに、
パケットが前記専用物理データチャネル上で受信され、対応する制御情報が前記関連する専用物理制御チャネル上で受信されず、新規パケット送信を表すフラッグが前記受信されたパケットに関連して受信された場合は、ゼロに等しい推定冗長バージョンで前記パケットをデコードするために前記デフォルトデータパケットサイズを使用するステップからなる方法。
請求項５記載の方法であって、さらに、
パケットが前記専用物理データチャネル上で受信され、対応する制御情報が前記関連する専用物理制御チャネル上で受信されず、新規パケット送信を表すフラッグが前記受信されたパケットに関連して受信されなかった場合は、前に検出されたフラッグから前記受信されたパケットの冗長バージョンを推論し、前記パケットをデコードするために前記推論された冗長バージョンと併せて前記デフォルトデータパケットサイズを使用するステップからなる方法。
請求項５記載の方法において、前記専用物理データチャネルが前記拡張専用物理データチャネル（Ｅ−ＤＰＤＣＨ）であり、前記専用物理制御チャネルが前記関連する拡張専用物理制御チャネル（Ｅ−ＤＰＣＣＨ）であり、両方ともユニバーサル移動体通信システム（ＵＭＴＳ）内の前記アップリンク上で送信される方法。