JP4558794B2 - Ｔｔｉ長再設定の間のｗｃｄｍａアップリンクｈａｒｑオペレーション - Google Patents

Description

本発明は、概ね、ユニバーサル移動電話システム（Universal Mobile Telecommunications System（ＵＭＴＳ））地上無線接続方式（Terrestrial Radio Access（ＵＴＲＡ））の第３世代移動体通信システム標準化プロジェクト（Third Generation Partnership Project（３ＧＰＰ））仕様に関し、特にＷＣＤＭＡ高速パケット・アップリンク・アクセス（High Speed Packet Uplink Access（ＨＳＵＰＡ））エアインターフェースのアップリンク送信時間間隔（transmission time interval（ＴＴＩ））長の再設定（リコンフィギュレーション）の間に、データの喪失を最小限にし、確実に大きな遅延が起こらないようにする方法に関する。

関連出願

本願は２００４年８月１３日に出願された米国仮特許出願第６０／６０１，４６２号の優先権を主張するものである。

ＨＳＵＰＡ機能の重要な要素は、高速なＷＣＤＭＡ基地局（すなわち、ノードＢ）レベルのハイブリッド自動再送要求（Hybrid Automatic Repeat requests（ＨＡＲＱ））である。これは、ノードＢが、図1に示されるＴ_ｐｒｏｐのような任意の伝搬遅延の後に各アップリンク送信時間間隔（ＴＴＩ）で送信されたパケットの受信に直ちに応答することである。この場合、応答は肯定または否定のいずれかである。アップリンクＴＴＩで送信されたパケットが誤って受信された場合、同じ情報が送信されるように、ユーザ装置（ｕser equipment（ＵＥ））はパケット中のビットと全く同じ数のビットか、正確な増加的冗長（incremental redundancy）ビットを再送する。

３ＧＰＰ規格の開発者らは、ＨＳＵＰＡエアインターフェースに対し２つの異なるアップリンクＴＴＩ長（すなわち、２ｍｓおよび１０ｍｓ）を確立し、アップリンクＴＴＩ長を半固定とするよう同意した。すなわちＨＳＵＰＡ無線リンク（またはエアインターフェース）ＴＴＩ長の変更は、無線ネットワーク制御装置（radio network controller（ＲＮＣ））によって制御される同期無線リンク再設定手続を必要とする。

一般に、アップリンクＴＴＩ長の変更が起こるとき、保留中の送信が存在する。すなわちノードＢがパケットを誤って受信し、パケットの再送を要求している。この場合、パケットの再送が発生する前に、アップリンクＴＴＩ長が変更される。その結果、保留中の再送でのパケットは物理層で喪失するため、上位のプロトコル層による再送によるアップリンクＴＴＩ長の再設定の際にデータの喪失および／または大きな遅延が発生する。現在、３ＧＰＰ規格は、アップリンクＴＴＩ長の再設定の間のシステムの動作については対応していない。よって、ＨＳＵＰＡエアインターフェースのアップリンクＴＴＩ長が再設定されるとき、データの喪失および／または大きな遅延が確実に起こらないようにする必要がある。

発明のまとめ

本発明は、ＷＣＤＭＡ高速パケット・アップリンク・アクセス（ＨＳＵＰＡ）エアインターフェースのアップリンク送信時間間隔（ＴＴＩ）長の再設定の間に、データの喪失を最小限にし、確実に大きな遅延が起こらないようにする方法である。本発明によれば、アップリンクＴＴＩ長の変更の場合にシステムが確実に合理的に応答する複数の技術がある。例えば、ハイブリッド自動再送要求（ＨＡＲＱ）の重要な要素は、正常に受信されなかったパケットの送信エネルギーが受信装置にソフト・シンボルとして格納され、再送要求がフィードバック情報として受信装置から送信装置に送られるということである。同一のパケットを送ろうとする異なる試行によって得られるこれらのソフト・シンボルは、結合させてデータ・パケットの単一のインスタンスをつくることができる。その結果、特定のパケットが２回送信され、いずれも誤って受信された場合、誤って受信されたパケットは１つの正しいパケットに結合できる可能性がある。本発明の一つの態様によれば、誤って受信されたパケットの送信されたエネルギーは使用しない。すなわち、ソフト・シンボルは結合されない。本発明の別の態様によれば、アップリンクＴＴＩ長の変更の前に送信された、誤って受信されたパケットのエネルギーが用いられる。すなわち、各送信の試行のソフト・シンボルが結合される。

ソフト・シンボルの作成には増加的冗長法（incremental redundancy scheme）が用いられる。例えば、送信側はハード・ビット（０および１、これらは一般的に無線機によって−１および＋１にマッピングされる）のみ送信しても、受信側は−１を受信したか＋１を受信したがどうかの「硬」判定を行なわない。代わりに、受信されたビットが−１または＋１にどの位近いかについての判定を行なう。本発明によれば、複数の送信のソフト・シンボルを合計することができる。その結果、受信側は、複数の送信からの送信エネルギーを蓄積することができる。ここで、送信側は送信中および受信側にある誤り訂正符号および巡回冗長検査（ＣＲＣ）の検査部分を使用する。各送信の試行後、デコーダが各ソフト・シンボルに対して「硬」判定を行なう。さらに、受信された送信をデコードした後、ＣＲＣ検査でデータが正しいことが示される場合、ソフト・シンボルをクリアすることができ、受信されたデコード済みのパケットをＲＮＣへ中継することができる。増加的冗長法では、送信側が各送信の中で異なるビットを部分的に送信することもできる。さらに、受信側は、各試行される送信の中でどのビットが送信されるべきかを事前に知っている。

本発明のさらなる態様によれば、すべての保留中の再送が正常に送信されるまで、または最大送信数に達するまで、アップリンクＴＴＩ長の再設定は遅延される。ここで、この遅延期間には新しいデータは送られない。その結果、アップリンクＴＴＩ長の再設定に遅延が付与される。

本発明の別の態様によれば、アップリンクＴＴＩ長が変更される前に、ハイブリッド自動再送要求（ＨＡＲＱ）再送の最大数で表わされる期間が経過することが許される。さらに、この期間の新しいパケットの送信は止められるが、どんな保留中の送信も行なわれるようにする。

本発明のその他の目的および機能は、以下の詳細な説明を添付の図面とともに読むことで明らかになるであろう。しかし、図面は例示的な説明のためのものであって、本発明を制限するものではないということは理解されたい。本発明の範囲については、添付の特許請求の範囲が専ら参照されるべきである。さらに、図面は必ずしもスケールに応じて描かれておらず、特に断りのない限り、本発明の構造および手順を単に概念的に示すに留まるものであることを理解すべきである。

本発明の上記ならびにその他の利点および機能は、以下の発明を実施するための最良の形態を添付の図面とともに読むことで明らかになるであろう。

現在好適である実施形態の詳細な説明

本発明は、ＷＣＤＭＡ高速パケット・アップリンク・アクセス（ＨＳＵＰＡ）エアインターフェースのアップリンクＴＴＩ長が再設定されるときに、データの喪失を最小限にし、且つ／または大きな遅延が確実に起こらないようにする方法に関する。本発明によれば、アップリンクＴＴＩ長の変更があった場合に、確実にシステムが合理的に応答する複数の技術がある。例えば、ハイブリッド自動再送要求（ＨＡＲＱ）の重要な要素として、正常に受信されなかったパケットの送信エネルギーが受信装置にソフト・シンボルとして格納され、送信要求がフィードバック情報として受信装置から送信装置へ送られるとういことである。同一のパケットを送信するための異なる試行によって得られるこれらのソフト・シンボルは、結合させてデータ・パケットの単一のインスタンスをつくることができる。その結果、特定のパケットが二回送信され、いずれも誤って受信される場合、誤って受信されたパケットを１つの正しいパケットに結合することができる可能性がある。本発明の一実施形態においては、誤って受信されたパケットの送信エネルギーは使用しない。すなわち、ソフト・シンボルを結合しない。別の実施形態においては、アップリンクＴＴＩ長の変更の前に送信された誤って受信されたパケットのエネルギーを使用する。すなわち、各送信のソフト・シンボルを結合する。

ソフト・シンボルの作成には、増加的冗長法を使用する。例えば、送信側がハード・ビット（０および１、これらは通常−１および＋１にマッピングされる）のみを送信しても、受信側は−１を受信したか＋１を受信したかについての「硬」判定を行なわない。代わりに、受信したビットが−１または＋１にどの位近いかについての判定を行なう。本発明によれば、複数の送信のソフト・シンボルを合計することができる。その結果、受信側は複数の送信からの送信エネルギーを蓄積することができる。ここで、送信側は送信中および受信側の中の誤り訂正符号および巡回冗長検査（ＣＲＣ）の検査部分を使用する。各送信の試行の後、デコーダが各ソフト・シンボルに対しての「硬」判定を行なう。さらに、受信した送信をデコードした後、ＣＲＣ検査でデータが正しいことが示された場合、ソフト・シンボルはクリアすることができ、受信されたデコード済みパケットをＲＮＣへ中継することができる。増加的冗長法では、送信側は各送信において異なるビットを部分的に送信することもできる。さらに、受信側は、各試行される送信でどのビットが送信されるべきかを事前に知ることになる。

本発明の実施形態において、すべての保留中の再送が正常に送信されるまで、または最大送信数に達するまで、アップリンクＴＴＩ長の再設定は遅延される。ここで、この遅延期間には新しいデータは送られない。その結果、アップリンクＴＴＩ長の再設定に遅延が付与される。予想されるとおり、再設定が比較的まれに発生し、再設定を直ちに行なう必要がない場合、システム全体のパフォーマンスにおける遅延の悪影響は最小限となるため、遅延は許容できる。しかし、弱い信号範囲によってアップリンクＴＴＩ長が２ｍｓから１０ｍｓに変わると、「ドロップコール（drop call）」イベントが遅延時間の間に発生することがあるため、アップリンクＴＴＩ長の再設定を遅らせることを実行できなくなる。しかし、アップリンクＴＴＩ長が１０ｍｓから２ｍｓに変わる場合、これは弱い信号範囲に関連する問題が存在しないイベントであるため、アップリンクＴＴＩ長の再設定を遅延させることができる。別の実施形態では、アップリンクＴＴＩ長が変更される前に、ハイブリッド自動再送要求（ＨＡＲＱ）の最大再送数を示す期間を経過することができる。さらに、その期間、いかなる新しいパケットの送信も止められるが、いかなる保留中の送信も発生することが許可される。

本実施形態の方法は、サービング無線ネットワーク制御装置（serving radio network controller（ＳＲＮＣ））によって実装される。サービング無線ネットワーク制御装置は、ユーザ装置（ＵＥ）およびノードＢのために、アップリンクＴＴＩ長の同期再設定を指示する。この指示には、再設定を行なう接続フレーム番号（connection frame number（ＣＦＮ））が示されている。別の実施形態では、３ＧＰＰによって確立された別の方法によって、ＵＥおよびノードＢがアップリンクＴＴＩ長を再設定する正確なタイミングを得る。

設定接続フレーム番号（ＣＦＮ）コマンドの発行で、ＵＥは古いアップリンクＴＴＩ長で新しいデータ・パケットを送信することを止めるが、すべてのパケットが正常に送信されるまで、すなわちＵＥが各ＨＡＲＱプロセスに対し肯定応答（ＡＣＫ）を受信するまで、または特定の最大再送数に達するまで、古いアップリンクＴＴＩ長でどんな保留中の再送も送信し続ける。このイベントが発生した後、ＵＥは新しいアップリンクＴＴＩ長で送信を開始することができる。

設定されたＣＦＮで、ノードＢは、各ＨＡＲＱプロセスが再送後パケットを正常に受信する、または最大再送数に達することのいずれかによって保留中の再送を終了するまで、古いアップリンクＴＴＩ長で通常の方法によって動作を続ける。ＨＡＲＱプロセスが終了した後、ノードＢは、新しいアップリンクＴＴＩ長で受信を開始する。ＨＡＲＱプロセスのいずれに対しても保留中の再送が無い場合、ノードＢは、直ちに新しいアップリンクＴＴＩ長での送信を待機し始める。

複数のノードＢがＵＥのソフト・ハンドオーバー（soft handover（ＳＨＯ））ブランチを扱うために関与している場合、本実施形態の方法は不適切であることに注意されたい。これは、別のノードＢが古いアップリンクＴＴＩ長で正しく送られた最終パケットを受信することがある一方、別のノードＢがそのパケットを逃しており、よって古いアップリンクＴＴＩ長でそのパケットの再送をさらに要求するからである。ここで、ＵＥがアップリンクＴＴＩ長を変更する。しかし、パケットの再送をまだ要求している他のノードＢは、ＵＥからの次の送信をデコードし損なう。

本発明の別の実施形態において、アップリンクＴＴＩ長は、受信された再設定メッセージに配置される接続フレーム番号（ＣＦＮ）の示されたアクティブ化時間で直ちに変更される。ここで、ノードＢは自身のＨＡＲＱバッファをクリアし、ＵＥは示されたアクティブ化時間に新しいアップリンクＴＴＩ長で新しいパケットの送信を開始する。その結果、再送を待機しているすべてのパケットが喪失されるが、上位層再送プロトコルによって回復されることもでき得る。

図２を参照すると、本発明の実施形態によるアップリンクＴＴＩ長を再設定する方法が示されている。ここで、再設定コマンドが受信されるとアップリンクＴＴＩ長が直ちに変更される。つまり、ノードＢが自身のＨＡＲＱバッファをクリアする。しかし、各送信のＡＣＫ／ＮＡＣＫは、続いて最初のアップリンクＴＴＩ長の送信に対して送られる。その結果、どのパケットが正しくおよび／または誤って受信されたかをＵＥは知ることができる。この情報に基づいて、ＵＥは、新しい最初の送信（および可能な次の再送信）を用い、新しいアップリンクＴＴＩ長で、ノードＢで正常に受信できなかったデータを送る。その結果、物理層でパケットが喪失されなくなる。しかし、古いアップリンクＴＴＩ長での最初の送信のエネルギーは失われる。

本発明の実施形態によれば、１０ｍｓアップリンクＴＴＩ長から２ｍｓアップリンクＴＴＩ長へ変更する際に、おおよそ（Ｎ−１）＊１０ｍｓの間、ＵＥは新しいアップリンクＴＴＩ長でいかなるパケットも送信しないことが必要とされる。これは、より短いアップリンクＴＴＩ長のより速いＡＣＫ／ＮＡＣＫ送信がより長いアップリンクＴＴＩ長の保留中のＡＣＫ／ＮＡＣＫとオーバーラップすることを防ぐためである。この場合、Ｎは１０ｍｓアップリンクＴＴＩ長のＨＡＲＱプロセスの数である。一般的に、２ｍｓアップリンクＴＴＩ長から１０ｍｓアップリンクＴＴＩ長へ変更する際、ＡＣＫ／ＮＡＣＫオーバーラップは発生しない。これは、２ｍｓアップリンクＴＴＩ長のＮは十分に小さい（例えば、７）ので、最初の１０ｍｓＴＴＩデータ・パケットの最初のＡＣＫ／ＮＡＣＫを受信する前にすべてのＡＣＫ／ＮＡＣＫが受信できるためである。したがって、再設定が発生した後、ＵＥは直ちに１０ｍｓアップリンクＴＴＩ長で送信を開始し、最初の１０ｍｓＡＣＫ／ＮＡＣＫがＵＥに到達する前にキューに残っている２ｍｓのＡＣＫ／ＮＡＣＫを受信することができる。その結果、異なるＴＴＩ長のＡＣＫ／ＮＡＣＫ間でのオーバーラップの発生が回避される。

さらに図２を参照すると、再設定を行なう接続フレーム番号（ＣＦＮ）が示しながら、ユーザ装置（ＵＥ）およびノードＢ用のアップリンクＴＴＩ長の同期式再設定を指示するサービング無線ネットワーク装置（ＳＲＮＣ）を用いて、本実施形態の方法が実施されている。別の実施形態では、ＵＥおよびノードＢが、３ＧＰＰによって確立された別の方法によってアップリンクＴＴＩ長の再設定の正確なタイミングを得る。

本実施形態の方法によれば、アップリンクＴＴＩ長を２ｍｓから１０ｍｓへ再設定するために、ＵＥは再設定が発生した際に直ちに１０ｍｓアップリンクＴＴＩ長でパケットの送信を開始する。しかし、２ｍｓアップリンクＴＴＩ長で以前に送られたパケットのＡＣＫ／ＮＡＣＫは、再設定が行なわれなかったかのように今までと同じ方法で受信される。ここで、ＡＣＫ／ＮＡＣＫ送信がオーバーラップしないように、２ｍｓおよび１０ｍｓアップリンクＴＴＩ長のＨＡＲＱプロセスの数が確定されることとするのが合理的である。

ＵＥは、２ｍｓＴＴＩパケットの受信したＡＣＫ／ＮＡＣＫから、どのデータが誤って受信されたかを確かめる。その結果、ＵＥはそのデータを再送するが、これは新しいデータであるかのように１０ｍｓアップリンクＴＴＩで再送する。

次に、ノードＢが直ちに１０ｍｓアップリンクＴＴＩ長でデータの受信を開始する一方、以前に２ｍｓアップリンクＴＴＩ長で受信したパケットのＡＣＫ／ＮＡＣＫをやはり通常のように送信している。

ノードＢは、最後の２ｍｓアップリンクＴＴＩ長ＡＣＫ／ＮＡＣＫを送信した後、２ｍｓＴＴＩ長で送信され、まだ保留中の再送があるＨＡＲＱプロセス用のＨＡＲＱバッファをクリアする。あるいは、ノードＢは、蓄積された２ｍｓＴＴＩ長で送信されたパケットのエネルギー（すなわち、ソフト・シンボル）を１０ｍｓアップリンクＴＴＩ長の同一のデータの再送とともに使用する。

本発明の本実施形態によれば、アップリンクＴＴＩ長を１０ｍｓから２ｍｓへ変更するため、２つのアップリンクＴＴＩ長のＨＡＲＱプロセスの数から導かれる期間の間、ＵＥはパケットの送信を止められる。よって、２ｍｓアップリンクＴＴＩ長で送られた最初のパケットのＡＣＫ／ＮＡＣＫが、１０ｍｓアップリンクＴＴＩ長で送られた最後のパケットのＡＣＫ／ＮＡＣＫの後に初めてＵＥに到着する。他のすべての態様において、この熟考された実施形態は、アップリンクＴＴＩ長の２ｍｓから１０ｍｓへの再設定に関しても上記の実施形態と同じである。

アップリンクＴＴＩ長の変更が行なわれる典型的な場合のシグナリングの流れの例は、図３に示されている。ここで示されているのは、セル内での通信である。図示されたシグナリングの流れは、完全なものではなく、例えば図４に示されるＢＴＳ内無線リンクの追加、図５に示される相互ＢＴＳ無線リンクの追加、またはブランチの削除およびブランチの置き換えなど、シグナルの流れの他のケースも定義できる。

図６は、本発明の方法による、アップリンクＴＴＩ長を２ｍｓから１０ｍｓへ変更する方法のステップを示すフローチャートである。図６を参照すると、ステップ６００で示されるように、本発明の方法はパケットをＵＥからノードＢへ送信することにより実施される。ステップ６１０で示されるように、送信された各パケットのＡＣＫ／ＮＡＣＫがＵＥに送られる。ステップ６２０で示されるように、アップリンクＴＴＩ長再設定コマンドが発行されたかをどうかを判定するためにチェックが行なわれる。ステップ６３０で示されるように、ＴＴＩ長コマンドが発行されていると、パケットが誤って受信されたかどうかを判定するためにチェックが行なわれる。すべてのパケットが正しく受信された場合、パケットの送信を続けるためにステップ６００へ戻る。しかし、パケットが正しく受信されなかった場合、すなわちＵＥによってＮＡＣＫが受信された場合、再設定を行なう接続フレーム番号（ＣＦＮ）を示しながら、サービング無線リンク制御装置（ＳＲＮＣ）からユーザ装置（ＵＥ）およびノードＢのアップリンクＴＴＩ長の同期再設定を行なうためのコマンドが発行され、ステップ６４０で示されるようにその指示された接続フレーム番号（ＣＦＮ）で、２ｍｓアップリンクＴＴＩ長での新しいデータの送信は終了される。別の実施形態では、ＵＥおよびノードＢは３ＧＰＰによって確立された別の方法によって、アップリンクＴＴＩ長の再設定の正確なタイミングを得る。

次に、ステップ６５０で示されるように、２ｍｓアップリンクＴＴＩ長で送信されたパケットのＡＣＫ／ＮＡＣＫを用いて、すべての送信データが正しく受信されたかどうかを判断するチェックを行なう。ステップ６６０で示されるように、２ｍｓアップリンクＴＴＩ長での保留中の再送がある場合、再設定がまだ行なわれていないかのように、２ｍｓアップリンクＴＴＩ長で以前に送られたパケットのＡＣＫ／ＮＡＣＫが同じ方法でまだ受信される。ここで、ＡＣＫ／ＮＡＣＫ送信がオーバーラップすることを防ぐため、２ｍｓおよび１０ｍｓアップリンクＴＴＩ長のＨＡＲＱプロセスの数が確定されているとするのが合理的である。その結果、ステップ６７０で示されるように、ノードＢは、１０ｍｓアップリンクＴＴＩ長でデータの受信を開始する前に、以前に２ｍｓアップリンクＴＴＩ長で受信されたパケットのすべてのＡＣＫ／ＮＡＣＫが送信されるまで待機する。

ノードＢは、最後の２ｍｓアップリンクＴＴＩ長ＡＣＫ／ＮＡＣＫを送信した後、再送がまだ保留中になっている２ｍｓＴＴＩ長で送信されたＨＡＲＱプロセス用のＨＡＲＱバッファをクリアする。あるいは、ノードＢは、蓄積された２ｍｓＴＴＩ長で送られたパケットのエネルギー（すなわち、ソフト・シンボル）を１０ｍｓアップリンクＴＴＩ長の同一のデータの再送信とともに使用する。

本発明の本実施形態によれば、アップリンクＴＴＩ長を１０ｍｓから２ｍｓへ変更するため、両方のアップリンクＴＴＩ長用のＨＡＲＱプロセスの数から得られる期間、ＵＥはパケットの送信を止められる。よって、１０ｍｓアップリンクＴＴＩ長で送られた最後のパケットのＡＣＫ／ＮＡＣＫの後に２ｍｓアップリンクＴＴＩ長で送られた最初のパケットのＡＣＫ／ＮＡＣＫがＵＥに初めて到達する。

図７は、本発明の本実施形態によるアップリンクＴＴＩ長を１０ｍｓから２ｍｓへ変更する方法のステップを示すフローチャートである。図７を参照すると、ステップ７００で示されるように、本発明の方法はＵＥからノードＢにパケットを送信することによって実施される。ステップ７１０で示されるように、各パケットのＡＣＫ／ＮＡＣＫがＵＥに送られる。ステップ７２０で示されるように、アップリンクＴＴＩ長の再設定コマンドが発行されたかどうかを判断するためにチェックが行なわれる。ＴＴＩ長コマンドが発行されている場合、ステップ７３０で示されるように、パケットが誤って受信されたかどうかを判断するチェックが行なわれる。すべてのパケットが正しく受信された場合、パケットの送信を継続するためステップ７００へ戻る。しかし、パケットが正しく受信されなかった場合、すなわちＵＥによってＮＡＣＫが受信された場合、再設定を行なう接続フレーム番号（ＣＦＮ）を示しながら、サービング無線リンク制御装置（ＳＲＮＣ）からユーザ装置（ＵＥ）およびノードＢのアップリンクＴＴＩ長の同期再設定を行なうためのコマンドが発行され、ステップ７４０で示されるようにその指示された接続フレーム番号（ＣＦＮ）で、２ｍｓアップリンクＴＴＩ長での新しいデータの送信は終了される。別の実施形態では、ＵＥおよびノードＢは、３ＧＰＰによって確立された別の方法によって、アップリンクＴＴＩ長の再設定の正確なタイミングを得る。

次に、ステップ７５０で示されるように、両方のアップリンクＴＴＩ長用のＨＡＲＱプロセスの数から得られる期間、ＵＥからのパケットの送信が中断される。ノードＢは、最後の１０ｍｓアップリンクＴＴＩ長ＡＣＫ／ＮＡＣＫを送信した後、１０ｍｓＴＴＩ長で送られた、まだ保留中の再送のあるＨＡＲＱプロセスのためのＨＡＲＱバッファをクリアする。その結果、ステップ７６０に示されるように、ノードＢは、直ちに２ｍｓアップリンクＴＴＩ長でデータの受信を開始する一方、２ｍｓアップリンクＴＴＩ長で以前に受信されたパケットのＡＣＫ／ＮＡＣＫを通常のようにまだ送信している。

図８は、単一のＨＡＲＱプロセスに関連するステップを示すフローチャートである。特に図８は、他のＨＡＲＱプロセスがＡＣＫ／ＮＡＣＫの送信を待機しているとき、単一のプロセスでデータを送信するために複数のＨＡＲＱプロセス（例えば、ＵＥチャネル）がどのように動作するかを示している。この場合、ＴＴＩ長の変更はすべてのＨＡＲＱプロセスに対して同時に発生する。好適な実施形態において、ＴＴＩ長を変更するかどうかの判断は、データ・パケットを送信するかどうかの判定を行なう直前、またはパケットを送信するためのデータ判定が行なわれる直後に判断される。

図８を参照すると、ステップ８００に示されるように、新しいデータ・パケットが送信される。次に、ステップ８１０に示されるように、アップリンクＴＴＩ長の変更コマンドが発行されたかどうかを判断するチェックが行なわれる。アップリンクＴＴＩ長の変更コマンドが発行されている場合、ステップ８２０で示されるように、次に送信されるパケットのアップリンクＴＴＩ長を変更させるため、アップリンクＴＴＩ長変更プロシージャが開始される。その後、ステップ８００へ戻り、次のデータ・パケットが新しいアップリンクＴＴＩ長で送信される。

アップリンクＴＴＩ長変更コマンドが発行されていない場合、ステップ８３０に示されるように、ＡＣＫ／ＮＡＣＫが受信されたかどうかを判断するチェックが行なわれる。ＮＡＣＫが受信されている場合、ステップ８４０に示されるように、データ・パケットは再送される。ＡＣＫが受信されている場合、ステップ６００へ戻り、さらなるデータ・パケットが送信される。

図９は、図８のアップリンクＴＴＩ長変更プロシージャと関連するステップを示すフローチャートである。図９を参照すると、ステップ９００に示されるように、アップリンクＴＴＩ長変更プロシージャは、ＡＣＫ／ＮＡＣＫが受信されたかどうかを判断するチェックをすることによってインプリメントされる。ＮＡＣＫが受信されている場合、ステップ９１０に示されるように、データ・パケットが再送される。ＡＣＫが受信される場合、ステップ９２０で示されるように、アップリンクＴＴＩ長変更コマンドが発行される。

次に、ステップ９３０で示されるように、すべてのＨＡＲＱプロセス用のアップリンクＴＴＩ長の変更が発生したかどうかを判断するチェックが行なわれる。すべてのＨＡＲＱプロセス用のアップリンクＴＴＩ長が変更されていない場合、すべてのプロセス用のアップリンクＴＴＩ長が変更されるまで、すべてのＨＡＲＱプロセスが続けてチェックされる。この「連続ループ」では、別のＨＡＲＱプロセスが古いアップリンクＴＴＩ長で送信している間は、一方のＨＡＲＱプロセスが新しいアップリンクＴＴＩ長で送信しないようにすることが確実に必要となる。

図１０は、別のアップリンクＴＴＩ長変更プロシージャに関連するステップを示すフローチャートである。特に図１０を参照すると、ステップ１０００で示されるように、アップリンクＴＴＩ長変更プロシージャは、変更カウンタをゼロに設定することでインプリメントされる。その後、ステップ１０１０で示されるように、データ・パケットの再送カウントが所定の最大送信数未満であるかどうかを判断するチェックが行なわれる。アップリンクＴＴＩ変更長コマンドの前に発生するデータ・パケット再送も再送カウントの一部としてカウントされることも注意されたい。

再送カウントが所定の最大送信数未満である場合、ステップ１０２０に示されるように、ＮＡＣＫが受信されたかどうかを判断するチェックが行なわれる。当然、ステップ１０２５で示されるように、データ・パケットの再送カウントが所定の最大送信数以上の場合、ＮＡＣＫは送信されないことは理解されよう。

ＮＡＣＫを受信すると、ステップ１０３０で示されるように、データ・パケットが再送される。その後、ステップ１０４０に示されるように、変更カウンタがインクリメントされる。ここで、データ・パケットの再送カウントもインクリメントされ、データ・パケットの再送カウントが所定の最大送信数未満であるかどうかを判断するチェックを行なうため、ステップ１０１０へリターンする。

その一方、ＡＣＫがステップ１０２０で受信される場合、ステップ１０５０で示されるように、アップリンクＴＴＩ長変更コマンドが発行される。ステップ１０６０で示されるように、その後すべてのＨＡＲＱプロセスに対するアップリンクＴＴＩ長の変更が発生したかどうかを判断するチェックが行なわれる。すべてのＨＡＲＱプロセスに対するアップリンクＴＴＩ長が変更されていない場合、すべてのプロセスに対するアップリンクＴＴＩ長が変更されるまで、すべてのＨＡＲＱプロセスが続けてチェックされる。

この単純な「データ・ロス」アプローチ（すなわち、ノードＢのＨＡＲＱバッファをクリアし、保留中の送信がないかのようにＵＥから送信を続ける）は、アップリンクＴＴＩ長を再設定する最も簡単な方法である。しかし、この技術はデータの喪失を引き起こし、ＲＬＣ／ＴＣＰ層の再送に依存し、これが上位の遅延に繋がることがある。本発明のプロシージャの方法を用いると、関連するデータの喪失がなく、シームレスな結果をもたらす。しかし、処理の複雑度およびコストが高くなる。

したがって、好適な実施形態に適用された本発明の基本的で新規な特徴を示し、記載し、指摘したが、記述したデバイスおよび方法の形態および詳細、ならびにその動作において、様々な省略、代替および変更が、本発明の本旨を逸脱することなく当業者により行なわれ得ることは、理解されよう。例えば、実質的に同一の方法で実質的に同一の機能を実行して同一の結果を実現させるこれらの構成要素および／または方法工程のすべての組み合わせは、本発明の範囲内であると明確に意図している。さらに、本発明のいかなる開示された形態または実施形態に関連して示されたおよび／または記載された、構造および／または構成要素および／または方法工程は、一般的な設計事項として、他のいかなる開示、記載、または示唆されるところによる態様、もしくは実施形態に組み込まれても良いということも理解されよう。したがって、本願明細書に添付の特許請求の範囲に示された範囲にのみ限定されることを意図する。

プロセス数（Ｎ）が３に等しく、アップリンク送信時間間隔（ＴＴＩ）が１０ｍｓに等しい、ハイブリッド自動再送要求（ＨＡＲＱ）タイミングを例で示す図である。 本発明の実施形態による、アップリンクＴＴＩ長の再設定を行なう方法を示す図である。 アップリンクＴＴＩ長の変更が行なわれるときの典型的な場合のシグナリング・フローの例を示す図である。 アップリンクＴＴＩ長の変更が行なわれるときの典型的な場合のシグナリング・フローの別の例を示す図である。 アップリンクＴＴＩ長の変更が行なわれるときの典型的な場合のシグナリング・フローのさらに別の例を示す図である。 本発明による、アップリンクＴＴＩ長を２ｍｓから１０ｍｓへ変更する方法のステップを示すフローチャートである。 本発明による、アップリンクＴＴＩ長を１０ｍｓから２ｍｓへ変更する方法のステップを示すフローチャートである。 単一のＨＡＲＱプロセスに関連するステップを示すフローチャートである。 図８のアップリンクＴＴＩ長変更プロシージャに関連するステップを示すフローチャートである。 別のアップリンクＴＴＩ長変更プロシージャに関連するステップを示すフローチャートである。

Claims (22)

1. アップリンク送信時間間隔（ＴＴＩ）長を再設定する方法であって、
   第１のアップリンクＴＴＩ長でユーザ装置から基地局へ第１のデータ・パケットを送信すること、
   サービング無線ネットワーク制御装置からの再設定コマンドを前記ユーザ装置が受信することによって、該ユーザ装置から前記第１のデータ・パケットを前記第１のアップリンクＴＴＩ長で送信することを終了させること、
   所定の時点まで、前記ユーザ装置からの第２のデータ・パケットの送信を遅延させること、および、
   前記第１のアップリンクＴＴＩ長と異なる第２のアップリンクＴＴＩ長で前記ユーザ装置から前記基地局へ前記第２のデータ・パケットを送信すること、
   を含む方法。
2. 全ての第１のデータ・パケットが前記基地局に正常に受信されるまで、少なくとも１つの正常に受信されなかった前記第１のデータ・パケットのすべての保留中の再送のため、前記第１のアップリンクＴＴＩ長で再送すること
   を含む、請求項１に記載の方法。
3. 前記第１のアップリンクＴＴＩ長が２ｍｓであり、前記第２のアップリンクＴＴＩ長が１０ｍｓである、請求項１又は２に記載の方法。
4. 前記再設定コマンドの受信に応じて、前記再設定が行われるべき接続フレーム番号において、前記ユーザ装置の前記アップリンクＴＴＩ長の同期再設定を開始する、請求項１乃至３のいずれかに記載の方法。
5. 前記所定の時点は、予め定められた最大送信数が前記第１のアップリンクＴＴＩ長で発生する時点である、請求項１乃至４のいずれかに記載の方法。
6. 前記所定の時点は、再送されたすべての第１のデータ・パケットが肯定的に応答された時点、または予め定められた第１のデータ・パケットの最大送信数に到達する時点の少なくとも１つである、請求項１乃至５のいずれかに記載の方法。
7. 正常に受信されなかった第１のデータ・パケットを第２のデータ・パケットとして再送すること、
   をさらに含む、請求項１乃至６のいずれかに記載の方法。
8. 第１のデータ・パケットについて保留中の再送を有するハイブリッド自動再送要求（ＨＡＲＱ）プロセス用の、前記基地局のＨＡＲＱバッファをクリアする、請求項７に記載の方法。
9. 前記第１のデータ・パケットに関して最後の受信表示を送信した後に、前記クリアが行なわれる、請求項８に記載の方法。
10. 前記第１のデータ・パケットの受信または未受信を示す応答を、前記基地局から前記ユーザ装置に受信することをさらに含む、請求項１乃至９のいずれかに記載の方法。
11. 第２のデータ・パケットの受信表示が、最後の第１のデータ・パケットの応答の受信の後に、前記ユーザ装置に受信される、請求項１０に記載の方法。
12. 基地局に対し、第１のデータ・パケットを第１のアップリンク送信時間間隔（ＴＴＩ）長で送信するように設定可能な送信機と、
    無線ネットワーク装置から再設定コマンドを受信するように設定可能な受信機と、
    前記再設定コマンドの受信に応じて前記第１のデータ・パケットの送信を終了するように設定可能な制御器とを備え、当該制御器はさらに、所定の時点まで、第２のデータ・パケットの送信を遅らせるように設定可能であり、その後当該第２のデータ・パケットの送信が可能になると、当該第２のデータ・パケットを前記第１のアップリンクＴＴＩ長とは異なる第２のアップリンクＴＴＩ長で前記基地局に送信する通信送受信装置。
13. 前記制御器は、さらに、全ての第１のデータ・パケットが前記基地局に正常に受信されるまで、少なくとも１つの正常に受信されなかった前記第１のデータ・パケットのすべての保留中の再送のため、前記第１のアップリンクＴＴＩ長で再送するように設定可能である、請求項１２に記載の装置。
14. 前記所定の時点は、現在実行中のハイブリッド自動再送要求（Hybrid Automatic Repeat requests（ＨＡＲＱ））プロセスの数に基づいた時点である、請求項１２又は１３に記載の装置。
15. 前記第１のアップリンクＴＴＩ長が２ｍｓであり、前記第２のアップリンクＴＴＩ長が１０ｍｓである、請求項１２乃至１４のいずれかに記載の装置。
16. 前記無線ネットワーク装置は、サービング無線ネットワーク制御装置である、請求項１２乃至１５のいずれかに記載の装置。
17. 前記制御器は、さらに、前記再設定コマンドの受信に応じて、前記再設定が行われるべき接続フレーム番号において、前記ユーザ装置の前記アップリンクＴＴＩ長の同期再設定を開始するように設定可能である、請求項１２乃至１６のいずれかに記載の装置。
18. 前記受信機は、さらに、前記基地局から少なくとも第１のデータ・パケットの受信または未受信を示す確認応答を受信するように設定可能であり、第２のデータ・パケットの受信表示は、最後の第１のデータ・パケットについての確認応答を受信した後に受信される、請求項１２乃至１７のいずれかに記載の装置。
19. 前記所定の時点は、予め定められた最大送信数が前記第１のアップリンクＴＴＩ長で発生する時点である、請求項１２乃至１８のいずれかに記載の装置。
20. 前記所定の時点は、再送されたすべての第１のデータ・パケットが肯定的に応答された時点、または予め定められた第１のデータ・パケットの最大送信数に到達する時点の少なくとも１つである、請求項１２乃至１９のいずれかに記載の装置。
21. 前記制御器は、さらに、正常に受信されなかった第１のデータ・パケットを第２のデータ・パケットとして再送するように設定可能である請求項１２乃至２０のいずれかに記載の装置。
22. 前記通信送受信装置は、ＨＳＵＰＡのエアインターフェースとともに使用可能なユーザ装置である請求項１２乃至２１のいずれかに記載の装置。

Images