(57)【要約】ＷＣＤＭＡ高速パケット・アップリンク・アクセス（High Speed Packet Uplink Access（ＨＳＵＰＡ））エアインターフェースのアップリンク送信時間間隔（transmission time interval（ＴＴＩ））長の再設定の間に、データの喪失を最小限にし、確実に大きな遅延が起こらないようにする方法であって、アップリンクＴＴＩ長の再設定がすべての保留中の再送が正常に送信されるまで、または最大送信数に達するまでアップリンクＴＴＩ長の再設定を遅延させる方法。この期間の新しいパケットの送信は止められる。しかし、保留中の再送は行なうことができる。ＵＥが各ＨＡＲＱプロセスのＡＣＫ／ＮＡＣＫを受信した後、または特定の最大再送信数に達してから、ＵＥが新しいアップリンクＴＴＩ長で送信を開始する。【選択図】図1
2008510331.tif 000002
【特許請求の範囲】
【請求項１】
アップリンクＴＴＩ長を再設定する方法であって、
第１のアップリンクＴＴＩ長でユーザ装置から基地局へデータ・パケットを送信するステップと、
該基地局から該ユーザ装置にＡＣＫ／ＮＡＣＫを送ることで、該データ・パケットの受信応答をするステップと、
サービング無線ネットワーク制御装置からの再設定コマンドの発行によって、該ユーザ装置からの新しいデータ・パケットを該第１のアップリンクＴＴＩ長で送信することを終了させるステップと、
所定の期間、該ユーザ装置からの新しいデータ・パケットの送信を遅延させるステップと、
次の終了サブルーチンの完了後、第２のアップリンクＴＴＩ長で該ユーザ装置から該基地局へ新しいデータ・パケットを送信するステップと、
を含む方法。
【請求項２】
前記次の終了サブルーチンが、
正常に受信されなかったデータ・パケットについて、保留中の再送があるかどうかを判断するステップと、
前記第１のアップリンクＴＴＩ長で全てのデータ・パケットが正常に受信されるまで、少なくとも１つの正常に受信されなかったデータ・パケットのすべての保留中の再送のため、該第１のアップリンクＴＴＩ長で再送を受信し続けるステップと、
を含む、請求項１に記載の方法。
【請求項３】
前記次の終了サブルーチンが、現在実行中のハイブリッド自動再送要求（Hybrid Automatic Repeat requests（ＨＡＲＱ））プロセスの数に基づいた期間、前記ユーザ装置からのデータ・パケットの送信を一時停止するステップを含む、請求項１に記載の方法。
【請求項４】
前記第１のアップリンクＴＴＩ長が２ｍｓであり、前記第２のアップリンクＴＴＩ長が１０ｍｓである、請求項１に記載の方法。
【請求項５】
前記再設定コマンドがサービング無線ネットワーク制御装置により発行される、請求項１に記載の方法。
【請求項６】
前記再設定コマンドが、前記ユーザ装置の前記アップリンクＴＴＩ長の同期再設定を該再設定が発生する接続フレーム番号で開始するステップを含む、請求項５に記載の方法。
【請求項７】
前記再設定コマンドが発行されると、前記第２のアップリンクＴＴＩ長でデータ・パケットを直ちに送信するステップをさらに含む、請求項１に記載の方法。
【請求項８】
データ・パケットのＡＣＫ／ＮＡＣＫに基づいて前記第１のアップリンクＴＴＩ長で誤って受信されたデータ・パケットを判断するステップと、
該誤って受信されたデータ・パケットを、前記ユーザ装置から前記基地局へ、前記第２のアップリンクＴＴＩ長で再送するステップと、
をさらに含む、請求項１に記載の方法。
【請求項９】
前記第１のアップリンクＴＴＩ長で送られた保留中の再送データ・パケットを有するハイブリッド自動再送要求（ＨＡＲＱ）プロセス用のＨＡＲＱバッファをクリアするステップをさらに含む、請求項８に記載の方法。
【請求項１０】
前記基地局が最後のＡＣＫ／ＮＡＣＫを前記第１のアップリンクＴＴＩ長で前記ユーザ装置に送ることに続いて、前記クリアするステップが行なわれる、請求項９に記載の方法。
【請求項１１】
前記第１のアップリンクＴＴＩ長が２ｍｓである、請求項９に記載の方法。
【請求項１２】
前記第１のアップリンクＴＴＩ長が２ｍｓである、請求項１０に記載の方法。
【請求項１３】
前記第１のアップリンクＴＴＩ長で送信された最初のデータ・パケットのＡＣＫ／ＮＡＣＫが、前記第２のアップリンクＴＴＩ長で送られた最後のデータ・パケットに続いて前記ユーザ装置に初めて到達する、請求項３に記載の方法。
【請求項１４】
前記第１のアップリンクＴＴＩ長が１０ｍｓで、前記第２のアップリンクＴＴＩ長が２ｍｓである、請求項１３に記載の方法。
【請求項１５】
前記所定の期間は、予め定められた最大送信数が前記第１のアップリンクＴＴＩ長で発生する期間である、請求項１に記載の方法。
【請求項１６】
前記所定の期間は、前記第１のアップリンクＴＴＩ長で再送されたすべてのパケットが肯定的に応答された期間、または該第１のアップリンクＴＴＩ長で予め定められた最大送信数に到達する期間の少なくとも１つである、請求項１に記載の方法。
【請求項１７】
前記新しいパケットが前記所定の期間には送られない、請求項１６に記載の方法。
【請求項１８】
前記第１のアップリンクＴＴＩ長で送信されたデータ・パケットのＡＣＫ／ＮＡＣＫを受信するステップと、
前記第２のアップリンクＴＴＩ長で正常に受信されなかったデータ・パケットを新しいデータ・パケット送信として再送するステップと、
をさらに含む、請求項１に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概ね、ユニバーサル移動電話システム（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（ＳＨＯ））ブランチを扱うために関与している場合、本実施形態の方法は不適切であることに注意されたい。これは、別のノードＢが古いアップリンクＴＴＩ長で正しく送られた最終パケットを受信することがある一方、別のノードＢがそのパケットを逃しており、よって古いアップリンクＴＴＩ長でそのパケットの再送をさらに要求するからである。ここで、ＵＥがアップリンクＴＴＩ長を変更する。しかし、パケットの再送をまだ要求している他のノードＢは、ＵＥからの次の送信をデコードし損なう。
【００１９】
本発明の別の実施形態において、アップリンクＴＴＩ長は、受信された再設定メッセージに配置される接続フレーム番号（ＣＦＮ）の示されたアクティブ化時間で直ちに変更される。ここで、ノードＢは自身のＨＡＲＱバッファをクリアし、ＵＥは示されたアクティブ化時間に新しいアップリンクＴＴＩ長で新しいパケットの送信を開始する。その結果、再送を待機しているすべてのパケットが喪失されるが、上位層再送プロトコルによって回復されることもでき得る。
【００２０】
図２を参照すると、本発明の実施形態によるアップリンクＴＴＩ長を再設定する方法が示されている。ここで、再設定コマンドが受信されるとアップリンクＴＴＩ長が直ちに変更される。つまり、ノードＢが自身のＨＡＲＱバッファをクリアする。しかし、各送信のＡＣＫ／ＮＡＣＫは、続いて最初のアップリンクＴＴＩ長の送信に対して送られる。その結果、どのパケットが正しくおよび／または誤って受信されたかをＵＥは知ることができる。この情報に基づいて、ＵＥは、新しい最初の送信（および可能な次の再送信）を用い、新しいアップリンクＴＴＩ長で、ノードＢで正常に受信できなかったデータを送る。その結果、物理層でパケットが喪失されなくなる。しかし、古いアップリンクＴＴＩ長での最初の送信のエネルギーは失われる。
【００２１】
本発明の実施形態によれば、１０ｍｓアップリンクＴＴＩ長から２ｍｓアップリンクＴＴＩ長へ変更する際に、おおよそ（Ｎ−１）＊１０ｍｓの間、ＵＥは新しいアップリンクＴＴＩ長でいかなるパケットも送信しないことが必要とされる。これは、より短いアップリンクＴＴＩ長のより速いＡＣＫ／ＮＡＣＫ送信がより長いアップリンクＴＴＩ長の保留中のＡＣＫ／ＮＡＣＫとオーバーラップすることを防ぐためである。この場合、Ｎは１０ｍｓアップリンクＴＴＩ長のＨＡＲＱプロセスの数である。一般的に、２ｍｓアップリンクＴＴＩ長から１０ｍｓアップリンクＴＴＩ長へ変更する際、ＡＣＫ／ＮＡＣＫオーバーラップは発生しない。これは、２ｍｓアップリンクＴＴＩ長のＮは十分に小さい（例えば、７）ので、最初の１０ｍｓＴＴＩデータ・パケットの最初のＡＣＫ／ＮＡＣＫを受信する前にすべてのＡＣＫ／ＮＡＣＫが受信できるためである。したがって、再設定が発生した後、ＵＥは直ちに１０ｍｓアップリンクＴＴＩ長で送信を開始し、最初の１０ｍｓＡＣＫ／ＮＡＣＫがＵＥに到達する前にキューに残っている２ｍｓのＡＣＫ／ＮＡＣＫを受信することができる。その結果、異なるＴＴＩ長のＡＣＫ／ＮＡＣＫ間でのオーバーラップの発生が回避される。
【００２２】
さらに図２を参照すると、再設定を行なう接続フレーム番号（ＣＦＮ）が示しながら、ユーザ装置（ＵＥ）およびノードＢ用のアップリンクＴＴＩ長の同期式再設定を指示するサービング無線ネットワーク装置（ＳＲＮＣ）を用いて、本実施形態の方法が実施されている。別の実施形態では、ＵＥおよびノードＢが、３ＧＰＰによって確立された別の方法によってアップリンクＴＴＩ長の再設定の正確なタイミングを得る。
【００２３】
本実施形態の方法によれば、アップリンクＴＴＩ長を２ｍｓから１０ｍｓへ再設定するために、ＵＥは再設定が発生した際に直ちに１０ｍｓアップリンクＴＴＩ長でパケットの送信を開始する。しかし、２ｍｓアップリンクＴＴＩ長で以前に送られたパケットのＡＣＫ／ＮＡＣＫは、再設定が行なわれなかったかのように今までと同じ方法で受信される。ここで、ＡＣＫ／ＮＡＣＫ送信がオーバーラップしないように、２ｍｓおよび１０ｍｓアップリンクＴＴＩ長のＨＡＲＱプロセスの数が確定されることとするのが合理的である。
【００２４】
ＵＥは、２ｍｓＴＴＩパケットの受信したＡＣＫ／ＮＡＣＫから、どのデータが誤って受信されたかを確かめる。その結果、ＵＥはそのデータを再送するが、これは新しいデータであるかのように１０ｍｓアップリンクＴＴＩで再送する。
【００２５】
次に、ノードＢが直ちに１０ｍｓアップリンクＴＴＩ長でデータの受信を開始する一方、以前に２ｍｓアップリンクＴＴＩ長で受信したパケットのＡＣＫ／ＮＡＣＫをやはり通常のように送信している。
【００２６】
ノードＢは、最後の２ｍｓアップリンクＴＴＩ長ＡＣＫ／ＮＡＣＫを送信した後、２ｍｓＴＴＩ長で送信され、まだ保留中の再送があるＨＡＲＱプロセス用のＨＡＲＱバッファをクリアする。あるいは、ノードＢは、蓄積された２ｍｓＴＴＩ長で送信されたパケットのエネルギー（すなわち、ソフト・シンボル）を１０ｍｓアップリンクＴＴＩ長の同一のデータの再送とともに使用する。
【００２７】
本発明の本実施形態によれば、アップリンクＴＴＩ長を１０ｍｓから２ｍｓへ変更するため、２つのアップリンクＴＴＩ長のＨＡＲＱプロセスの数から導かれる期間の間、ＵＥはパケットの送信を止められる。よって、２ｍｓアップリンクＴＴＩ長で送られた最初のパケットのＡＣＫ／ＮＡＣＫが、１０ｍｓアップリンクＴＴＩ長で送られた最後のパケットのＡＣＫ／ＮＡＣＫの後に初めてＵＥに到着する。他のすべての態様において、この熟考された実施形態は、アップリンクＴＴＩ長の２ｍｓから１０ｍｓへの再設定に関しても上記の実施形態と同じである。
【００２８】
アップリンクＴＴＩ長の変更が行なわれる典型的な場合のシグナリングの流れの例は、図３に示されている。ここで示されているのは、セル内での通信である。図示されたシグナリングの流れは、完全なものではなく、例えば図４に示されるＢＴＳ内無線リンクの追加、図５に示される相互ＢＴＳ無線リンクの追加、またはブランチの削除およびブランチの置き換えなど、シグナルの流れの他のケースも定義できる。
【００２９】
図６は、本発明の方法による、アップリンクＴＴＩ長を２ｍｓから１０ｍｓへ変更する方法のステップを示すフローチャートである。図６を参照すると、ステップ６００で示されるように、本発明の方法はパケットをＵＥからノードＢへ送信することにより実施される。ステップ６１０で示されるように、送信された各パケットのＡＣＫ／ＮＡＣＫがＵＥに送られる。ステップ６２０で示されるように、アップリンクＴＴＩ長再設定コマンドが発行されたかをどうかを判定するためにチェックが行なわれる。ステップ６３０で示されるように、ＴＴＩ長コマンドが発行されていると、パケットが誤って受信されたかどうかを判定するためにチェックが行なわれる。すべてのパケットが正しく受信された場合、パケットの送信を続けるためにステップ６００へ戻る。しかし、パケットが正しく受信されなかった場合、すなわちＵＥによってＮＡＣＫが受信された場合、再設定を行なう接続フレーム番号（ＣＦＮ）を示しながら、サービング無線リンク制御装置（ＳＲＮＣ）からユーザ装置（ＵＥ）およびノードＢのアップリンクＴＴＩ長の同期再設定を行なうためのコマンドが発行され、ステップ６４０で示されるようにその指示された接続フレーム番号（ＣＦＮ）で、２ｍｓアップリンクＴＴＩ長での新しいデータの送信は終了される。別の実施形態では、ＵＥおよびノードＢは３ＧＰＰによって確立された別の方法によって、アップリンクＴＴＩ長の再設定の正確なタイミングを得る。
【００３０】
次に、ステップ６５０で示されるように、２ｍｓアップリンクＴＴＩ長で送信されたパケットのＡＣＫ／ＮＡＣＫを用いて、すべての送信データが正しく受信されたかどうかを判断するチェックを行なう。ステップ６６０で示されるように、２ｍｓアップリンクＴＴＩ長での保留中の再送がある場合、再設定がまだ行なわれていないかのように、２ｍｓアップリンクＴＴＩ長で以前に送られたパケットのＡＣＫ／ＮＡＣＫが同じ方法でまだ受信される。ここで、ＡＣＫ／ＮＡＣＫ送信がオーバーラップすることを防ぐため、２ｍｓおよび１０ｍｓアップリンクＴＴＩ長のＨＡＲＱプロセスの数が確定されているとするのが合理的である。その結果、ステップ６７０で示されるように、ノードＢは、１０ｍｓアップリンクＴＴＩ長でデータの受信を開始する前に、以前に２ｍｓアップリンクＴＴＩ長で受信されたパケットのすべてのＡＣＫ／ＮＡＣＫが送信されるまで待機する。
【００３１】
ノードＢは、最後の２ｍｓアップリンクＴＴＩ長ＡＣＫ／ＮＡＣＫを送信した後、再送がまだ保留中になっている２ｍｓＴＴＩ長で送信されたＨＡＲＱプロセス用のＨＡＲＱバッファをクリアする。あるいは、ノードＢは、蓄積された２ｍｓＴＴＩ長で送られたパケットのエネルギー（すなわち、ソフト・シンボル）を１０ｍｓアップリンクＴＴＩ長の同一のデータの再送信とともに使用する。
【００３２】
本発明の本実施形態によれば、アップリンクＴＴＩ長を１０ｍｓから２ｍｓへ変更するため、両方のアップリンクＴＴＩ長用のＨＡＲＱプロセスの数から得られる期間、ＵＥはパケットの送信を止められる。よって、１０ｍｓアップリンクＴＴＩ長で送られた最後のパケットのＡＣＫ／ＮＡＣＫの後に２ｍｓアップリンクＴＴＩ長で送られた最初のパケットのＡＣＫ／ＮＡＣＫがＵＥに初めて到達する。
【００３３】
図７は、本発明の本実施形態によるアップリンクＴＴＩ長を１０ｍｓから２ｍｓへ変更する方法のステップを示すフローチャートである。図７を参照すると、ステップ７００で示されるように、本発明の方法はＵＥからノードＢにパケットを送信することによって実施される。ステップ７１０で示されるように、各パケットのＡＣＫ／ＮＡＣＫがＵＥに送られる。ステップ７２０で示されるように、アップリンクＴＴＩ長の再設定コマンドが発行されたかどうかを判断するためにチェックが行なわれる。ＴＴＩ長コマンドが発行されている場合、ステップ７３０で示されるように、パケットが誤って受信されたかどうかを判断するチェックが行なわれる。すべてのパケットが正しく受信された場合、パケットの送信を継続するためステップ７００へ戻る。しかし、パケットが正しく受信されなかった場合、すなわちＵＥによってＮＡＣＫが受信された場合、再設定を行なう接続フレーム番号（ＣＦＮ）を示しながら、サービング無線リンク制御装置（ＳＲＮＣ）からユーザ装置（ＵＥ）およびノードＢのアップリンクＴＴＩ長の同期再設定を行なうためのコマンドが発行され、ステップ７４０で示されるようにその指示された接続フレーム番号（ＣＦＮ）で、２ｍｓアップリンクＴＴＩ長での新しいデータの送信は終了される。別の実施形態では、ＵＥおよびノードＢは、３ＧＰＰによって確立された別の方法によって、アップリンクＴＴＩ長の再設定の正確なタイミングを得る。
【００３４】
次に、ステップ７５０で示されるように、両方のアップリンクＴＴＩ長用のＨＡＲＱプロセスの数から得られる期間、ＵＥからのパケットの送信が中断される。ノードＢは、最後の１０ｍｓアップリンクＴＴＩ長ＡＣＫ／ＮＡＣＫを送信した後、１０ｍｓＴＴＩ長で送られた、まだ保留中の再送のあるＨＡＲＱプロセスのためのＨＡＲＱバッファをクリアする。その結果、ステップ７６０に示されるように、ノードＢは、直ちに２ｍｓアップリンクＴＴＩ長でデータの受信を開始する一方、２ｍｓアップリンクＴＴＩ長で以前に受信されたパケットのＡＣＫ／ＮＡＣＫを通常のようにまだ送信している。
【００３５】
図８は、単一のＨＡＲＱプロセスに関連するステップを示すフローチャートである。特に図８は、他のＨＡＲＱプロセスがＡＣＫ／ＮＡＣＫの送信を待機しているとき、単一のプロセスでデータを送信するために複数のＨＡＲＱプロセス（例えば、ＵＥチャネル）がどのように動作するかを示している。この場合、ＴＴＩ長の変更はすべてのＨＡＲＱプロセスに対して同時に発生する。好適な実施形態において、ＴＴＩ長を変更するかどうかの判断は、データ・パケットを送信するかどうかの判定を行なう直前、またはパケットを送信するためのデータ判定が行なわれる直後に判断される。
【００３６】
図８を参照すると、ステップ８００に示されるように、新しいデータ・パケットが送信される。次に、ステップ８１０に示されるように、アップリンクＴＴＩ長の変更コマンドが発行されたかどうかを判断するチェックが行なわれる。アップリンクＴＴＩ長の変更コマンドが発行されている場合、ステップ８２０で示されるように、次に送信されるパケットのアップリンクＴＴＩ長を変更させるため、アップリンクＴＴＩ長変更プロシージャが開始される。その後、ステップ８００へ戻り、次のデータ・パケットが新しいアップリンクＴＴＩ長で送信される。
【００３７】
アップリンクＴＴＩ長変更コマンドが発行されていない場合、ステップ８３０に示されるように、ＡＣＫ／ＮＡＣＫが受信されたかどうかを判断するチェックが行なわれる。ＮＡＣＫが受信されている場合、ステップ８４０に示されるように、データ・パケットは再送される。ＡＣＫが受信されている場合、ステップ６００へ戻り、さらなるデータ・パケットが送信される。
【００３８】
図９は、図８のアップリンクＴＴＩ長変更プロシージャと関連するステップを示すフローチャートである。図９を参照すると、ステップ９００に示されるように、アップリンクＴＴＩ長変更プロシージャは、ＡＣＫ／ＮＡＣＫが受信されたかどうかを判断するチェックをすることによってインプリメントされる。ＮＡＣＫが受信されている場合、ステップ９１０に示されるように、データ・パケットが再送される。ＡＣＫが受信される場合、ステップ９２０で示されるように、アップリンクＴＴＩ長変更コマンドが発行される。
【００３９】
次に、ステップ９３０で示されるように、すべてのＨＡＲＱプロセス用のアップリンクＴＴＩ長の変更が発生したかどうかを判断するチェックが行なわれる。すべてのＨＡＲＱプロセス用のアップリンクＴＴＩ長が変更されていない場合、すべてのプロセス用のアップリンクＴＴＩ長が変更されるまで、すべてのＨＡＲＱプロセスが続けてチェックされる。この「連続ループ」では、別のＨＡＲＱプロセスが古いアップリンクＴＴＩ長で送信している間は、一方のＨＡＲＱプロセスが新しいアップリンクＴＴＩ長で送信しないようにすることが確実に必要となる。
【００４０】
図１０は、別のアップリンクＴＴＩ長変更プロシージャに関連するステップを示すフローチャートである。特に図１０を参照すると、ステップ１０００で示されるように、アップリンクＴＴＩ長変更プロシージャは、変更カウンタをゼロに設定することでインプリメントされる。その後、ステップ１０１０で示されるように、データ・パケットの再送カウントが所定の最大送信数未満であるかどうかを判断するチェックが行なわれる。アップリンクＴＴＩ変更長コマンドの前に発生するデータ・パケット再送も再送カウントの一部としてカウントされることも注意されたい。
【００４１】
再送カウントが所定の最大送信数未満である場合、ステップ１０２０に示されるように、ＮＡＣＫが受信されたかどうかを判断するチェックが行なわれる。当然、ステップ１０２５で示されるように、データ・パケットの再送カウントが所定の最大送信数以上の場合、ＮＡＣＫは送信されないことは理解されよう。
【００４２】
ＮＡＣＫを受信すると、ステップ１０３０で示されるように、データ・パケットが再送される。その後、ステップ１０４０に示されるように、変更カウンタがインクリメントされる。ここで、データ・パケットの再送カウントもインクリメントされ、データ・パケットの再送カウントが所定の最大送信数未満であるかどうかを判断するチェックを行なうため、ステップ１０１０へリターンする。
【００４３】
その一方、ＡＣＫがステップ１０２０で受信される場合、ステップ１０５０で示されるように、アップリンクＴＴＩ長変更コマンドが発行される。ステップ１０６０で示されるように、その後すべてのＨＡＲＱプロセスに対するアップリンクＴＴＩ長の変更が発生したかどうかを判断するチェックが行なわれる。すべてのＨＡＲＱプロセスに対するアップリンクＴＴＩ長が変更されていない場合、すべてのプロセスに対するアップリンクＴＴＩ長が変更されるまで、すべてのＨＡＲＱプロセスが続けてチェックされる。
【００４４】
この単純な「データ・ロス」アプローチ（すなわち、ノードＢのＨＡＲＱバッファをクリアし、保留中の送信がないかのようにＵＥから送信を続ける）は、アップリンクＴＴＩ長を再設定する最も簡単な方法である。しかし、この技術はデータの喪失を引き起こし、ＲＬＣ／ＴＣＰ層の再送に依存し、これが上位の遅延に繋がることがある。本発明のプロシージャの方法を用いると、関連するデータの喪失がなく、シームレスな結果をもたらす。しかし、処理の複雑度およびコストが高くなる。
【００４５】
したがって、好適な実施形態に適用された本発明の基本的で新規な特徴を示し、記載し、指摘したが、記述したデバイスおよび方法の形態および詳細、ならびにその動作において、様々な省略、代替および変更が、本発明の本旨を逸脱することなく当業者により行なわれ得ることは、理解されよう。例えば、実質的に同一の方法で実質的に同一の機能を実行して同一の結果を実現させるこれらの構成要素および／または方法工程のすべての組み合わせは、本発明の範囲内であると明確に意図している。さらに、本発明のいかなる開示された形態または実施形態に関連して示されたおよび／または記載された、構造および／または構成要素および／または方法工程は、一般的な設計事項として、他のいかなる開示、記載、または示唆されるところによる態様、もしくは実施形態に組み込まれても良いということも理解されよう。したがって、本願明細書に添付の特許請求の範囲に示された範囲にのみ限定されることを意図する。
【図面の簡単な説明】
【００４６】
【図１】プロセス数（Ｎ）が３に等しく、アップリンク送信時間間隔（ＴＴＩ）が１０ｍｓに等しい、ハイブリッド自動再送要求（ＨＡＲＱ）タイミングを例で示す図である。
【図２】本発明の実施形態による、アップリンクＴＴＩ長の再設定を行なう方法を示す図である。
【図３】アップリンクＴＴＩ長の変更が行なわれるときの典型的な場合のシグナリング・フローの例を示す図である。
【図４】アップリンクＴＴＩ長の変更が行なわれるときの典型的な場合のシグナリング・フローの別の例を示す図である。
【図５】アップリンクＴＴＩ長の変更が行なわれるときの典型的な場合のシグナリング・フローのさらに別の例を示す図である。
【図６】本発明による、アップリンクＴＴＩ長を２ｍｓから１０ｍｓへ変更する方法のステップを示すフローチャートである。
【図７】本発明による、アップリンクＴＴＩ長を１０ｍｓから２ｍｓへ変更する方法のステップを示すフローチャートである。
【図８】単一のＨＡＲＱプロセスに関連するステップを示すフローチャートである。
【図９】図８のアップリンクＴＴＩ長変更プロシージャに関連するステップを示すフローチャートである。
【図１０】別のアップリンクＴＴＩ長変更プロシージャに関連するステップを示すフローチャートである。
【図１】
2008510331.tif 000003
【図２】
2008510331.tif 000004
【図３】
2008510331.tif 000005
【図４】
2008510331.tif 000006
【図５】
2008510331.tif 000007
【図６】
2008510331.tif 000008
【図７】
2008510331.tif 000009
【図８】
2008510331.tif 000010
【図９】
2008510331.tif 000011
【図１０】
2008510331.tif 000012