(57)【要約】      （修正有）【課題】サービス側ＨＳ−ＤＳＣＨセル変更手順の間に、待ち時間を低減し、潜在的にはパケットデータユニット伝送の喪失を防止する。【解決手段】ソースノードＢによってバッファされたデータをより効率的に回復するために、ＲＲＣ手順によって示されたセル変更の通知に引き続いて、可能な限り早急にＰＤＵの状況レポートを生成するＵＥ向けに、新しい基準が導入される。ＰＤＵ状況は、ＨＳ−ＤＳＣＨ移送チャネルに関連付けられた各無線リンクコントローラについて示される可能性がある。さらに、インターノードＢサービス側ＨＳ−ＤＳＣＨセル変更に応じて、ＳＲＮＣは、ターゲットセル内で新しいデータの伝送を開始する前に、ＰＤＵ状況レポートを待つことができる。【選択図】図１
2006025437.tif 000002
【特許請求の範囲】
【請求項１】
高速ダウンリンク共用チャネル（ＨＳ−ＤＳＣＨ）のセル変更を容易にするシステムにおいて、少なくとも１つのノードＢに結合された遠隔ネットワークコントローラ（ＲＮＣ）を含み、前記少なくとも１つのノードＢは、少なくとも１つのユーザ機器（ＵＥ）にさらに結合されるシステムであって、
前記ＲＮＣ部に位置し、いつＨＳ−ＤＳＣＨセル変更が必要であるか判定するための、また、前記セル変更の通知を生成するための無線リソース制御（ＲＲＣ）ユニットと、
前記通知を受信し、各ＰＤＵの状況を示す状況メッセージを生成するための、また、前記状況メッセージを前記ＲＮＣに送信するための、前記ＵＥ内に位置する制御ユニットと、
前記状況メッセージを読み取り、そのような状況メッセージに基づいてＰＤＵを前記ＵＥに再伝送するための、前記ＲＮＣ部の制御ユニットとを備えることを特徴とするシステム。
【請求項２】
少なくとも１つのユーザ機器にさらに結合される少なくとも１つのノードＢに結合された遠隔ネットワークコントローラ（ＲＮＣ）を有するシステムにおける、高速ダウンリンク共用チャネル（ＨＳ−ＤＳＣＨ）セル変更のための方法であって、
前記ＲＮＣ部で、ＨＳ−ＤＳＣＨセル変更について必要性を検出すること、
前記セル変更について前記ＵＥに通知すること、
前記ＵＥ部で受信されたデータの状況を決定すること、
前記ＵＥ部でのデータの受信の前記状況に基づいて、状況レポートを生成すること、
前記ＵＥから前記ＲＮＣに前記状況レポートを伝送すること、
前記ＲＮＣ部で、前記状況レポートに基づいて、前記ＵＥに伝送すべきデータを決定することを含むことを特徴とする方法。
【請求項３】
ソースセルからターゲットセルへの高速ダウンリンク共用チャネル（ＨＳ−ＤＳＣＨ）セル変更を容易にするＵＥであって、
前記ＵＥ部で、いつセル変更が必要であるか判定するための手段と、
前記セル変更の前に、前記ＵＥに伝送されたデータの状況を決定するための手段と、
前記決定に基づいて、状況レポートを生成するための手段と、
前記データ状況レポートを伝送するための手段とを備えることを特徴とするＵＥ。
【請求項４】
前記データは、パケットデータユニット（ＰＤＵ）を含むことを特徴とする請求項３に記載のＵＥ。
【請求項５】
前記状況レポートは、状況ＰＤＵを含むことを特徴とする請求項４に記載のシステム。
【請求項６】
前記第１の決定手段は、ＨＳ−ＤＳＣＨセル変更を示す要求メッセージを受信するための手段を含むことを特徴とする請求項３に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ワイヤレス通信の分野に関する。より詳細には、本発明は、中間点からデータを配信するワイヤレスシステムにおいて、バッファされたデータをハンドオーバの後に効率的に回復することに関する。１つまたは複数のノードＢに結合された遠隔ネットワークコントローラ（ＲＮＣ）を有し、ノードＢは、複数のユーザ機器（ＵＥ）にワイヤレスで結合される第３世代（３Ｇ）システムであって、適応変調および符号化（ＡＭＣ）技法と、ハイブリッド自動再送要求（Ｈ−ＡＲＱ）技法とを使用する第３世代システムは、この種のシステムの一例にすぎない。
【背景技術】
【０００２】
３Ｇ地上無線接続網（Ｕｎｉｖｅｒｓａｌ  Ｔｅｒｒｅｓｔｒｉａｌ  Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ：ＵＴＲＡＮ）は、いくつかのＲＮＣを備え、各ＲＮＣはいくつかのノードＢに結合することができる。ノードＢは、各々が１つまたは複数のセルについてトラフィックを管理する１つまたは複数の基地局を備えるエンティティである。
【０００３】
一般に、３ＧのＦＤＤシステムとＴＤＤシステムは、ＲＮＣを使用し、ＵＥに対するデータ伝送をバッファしてスケジューリングを行う。しかし、３Ｇセルラシステムの高速チャネルの場合、データは、ノードＢにより伝送するためバッファおよびスケジューリングが行われる。たとえば、これらの高速チャネルの１つは、高速ダウンリンクの共用チャネル（ＨＳ−ＤＳＣＨ）である。データはノードＢによって配信されるため、ノードＢ内で伝送用にデータをバッファすることが必要である。このアーキテクチャを採用する結果、ＲＮＣは、パケットデータユニット（ＰＤＵ）の、ノードＢによって制御された最新の伝送状況を有していない。したがって、セル間でハンドオーバする際、データ伝送のスケジューリングをセル変更にあわせることが必要となる。そうでないと、セル変更の後に伝送されたデータの喪失または重複を回避するため、データ伝送を再同期することが必要になってします。３Ｇネットワークでは、セル間のハンドオーバは、ＲＮＣによって制御される。そのＵＥが存在するセルを制御するＲＮＣが変わる可能性があるため、ハンドオーバの結果としてデータの損失、または重複のおそれがある。この問題は、各ＲＮＣに関連付けられたノードＢのアーキテクチャによっては悪化することがある。ＵＥのセルハンドオーバの結果ＲＮＣが変更されるより、移動ＵＥがノードＢの変更を必要とする可能性の方がはるかに高い。
【０００４】
ＨＳ−ＤＳＣＨは、データの高速伝送を可能にするためにＡＭＣを、またデータの送達に成功する可能性を高めるためにＨ−ＡＲＱを使用する。サービス側ＨＳ−ＤＳＣＨセルは、サービス側ＨＳ−ＤＳＣＨ無線リンクの送受信を実行しているＵＴＲＡＮアクセスポイントに関連付けられたセルをＵＥが変更しなければならないとき変更される。サービス側ＨＳ−ＤＳＣＨセルの変更は、物理チャネル条件の改善、および／または物理的容量の改善が、代替のセル内で実現されたとき呼び出される。ＵＴＲＡＮ内のＲＮＣ部で終端する３Ｇネットワーク内の他のチャネルと異なり、ＨＳ−ＤＳＣＨはノードＢ部で終端する。
【０００５】
ＨＳ−ＤＳＣＨセル変更には、２つのタイプがある。イントラノードＢ（Ｉｎｔｒａ−Ｎｏｄｅ  Ｂ）サービス側ＨＳ−ＤＳＣＨセル変更は、ＵＥが、同じノードＢに関連付けられた２つのセル間で変わるときである。インターノードＢ（Ｉｎｔｅｒ−Ｎｏｄｅ  Ｂ）サービス側ＨＳ−ＤＳＣＨセル変更は、ＵＥが、異なるノードＢに関連付けられた２つのセル間で変わるときである。インターノードＢセル変更では、サービス側ＨＳ−ＤＳＣＨセル変更の前のノードＢがソースノードＢと呼ばれ、サービス側ＨＳ−ＤＳＣＨセル変更の後のノードＢがターゲットノードＢと呼ばれる。
【０００６】
ＲＮＣにもＵＥにもピア無線リンク制御（ＲＬＣ）エンティティがあり、データの伝送用に自動再送要求（ＡＲＱ）機能を提供する。送信側ＲＬＣエンティティは、ＰＤＵヘッダ内でシーケンス番号（ＳＮ）を示し、シーケンス番号は、伝送時にＰＤＵを逸しないように受信側ＲＬＣエンティティによって使用される。ＰＤＵが乱れた順序で送達されたことによって伝送中に逸したＰＤＵがあると認識された場合、受信側ＲＬＣエンティティは、状況レポートＰＤＵを送信し、送信側ＲＬＣエンティティに逸したＰＤＵを通知する。状況レポートＰＤＵは、データ伝送の状況を述べるために使用される。状況レポートＰＤＵは、逸した、または受信されたＰＤＵのＳＮを識別する。ＰＤＵを逸した場合、送信側ＲＬＣエンティティは、逸したＰＤＵの複製を再伝送することになる。
【０００７】
送信側ＲＬＣエンティティが、受信側ＲＬＣエンティティに状況レポートＰＤＵを求めてポーリングし、あるいは受信側ＲＬＣエンティティが状況レポートを定期的に生成することも可能である。ポーリング機能は、送信側ＲＬＣエンティティがＰＤＵ伝送の状況を要求するための機構を提供する。
【０００８】
ノードＢのＨ−ＡＲＱ機能もまた、失敗した伝送の再伝送を可能にする。Ｈ−ＡＲＱは、いくつかの失敗した伝送を取り除き、およびデータの送達に成功する確率を高めるように機能するが、最終的に送達の成功を確保するのは、ＲＬＣプロトコル層である。
【０００９】
伝播条件の動的な変化により、ＨＳ−ＤＳＣＨセル変更は、サービス品質を維持するため迅速に実行しなければならない。サービス側ＨＳ−ＤＳＣＨセル変更中、ソースノードＢ内に現在格納されているＰＤＵのすべてが成功裏に伝送される前に、ＵＥがソースセル内で送受信を停止する可能性がある。ソースノードＢがデータのスケジューリングおよびバッファを行うため、およびデータ転送速度が非常に速いため（たとえば、１０Ｍｂ／秒以上）、ＵＥが（特にインターノードＢハンドオーバのために）サービス側ＨＳ−ＤＳＣＨセル変更を実行するとき、ソースノードＢ内にバッファされているかなりの量のデータが失われる可能性がある。このようにデータが喪失する理由の１つは、ソースノードＢ部でバッファされたデータをターゲットノードＢに転送するための機構が、ＵＴＲＡＮアーキテクチャ内に存在しないことである。ＨＳ−ＤＳＣＨセル変更を行う際、ＲＮＣは、ノードＢデータ伝送スケジューリングについて、およびその伝送がＵＥによって肯定確認されるのに成功したかどうか通知されないため、ＲＮＣは、あったとしてもどれだけのデータが失われたかについて情報を有していない。したがって、データを喪失することなしに伝送を維持するため、サービス側ＨＳ−ＤＳＣＨセル変更の際、データがソースノードＢ内にバッファされていると、ＲＮＣ  ＲＬＣは、このデータを回復しなければならない。
【００１０】
現在、従来技術のシステムがソースノードＢ部でバッファされたデータの回復を処理する２つの望ましい方法がある。ＨＳ−ＤＳＣＨセル変更の後に、１）ＲＮＣは、ＵＥに状況ＰＤＵを明示的に要求することができ、あるいは２）ＲＮＣは、ソースセル内で停止したところで単に伝送を開始することができ、ＵＥが認識している順序の乱れた送達によって状況ＰＤＵが生成されることになる。
【００１１】
ＲＮＣがＵＥをポーリングすることによって、状況ＰＤＵを明示的に要求する第１の場合には、ＲＮＣはまず、新しいセル内で物理チャネルが確立されるまで待たなければならない。次いで、状況ＰＤＵ要求が送信され、ＵＥによって受信され、処理される。ＵＥは、状況ＰＤＵを生成し、それをＲＮＣに返し、ＲＮＣは、状況ＰＤＵを処理し、どのＰＤＵが再伝送を必要としているかを判定する。
【００１２】
ＲＮＣが、ソースセル内で停止したところから単にＰＤＵを伝送するのを開始する第２の場合、ＵＥは、データが乱れた順序で送達されたことを認識し、ＲＮＣに返す状況ＰＤＵを生成する。ＲＮＣは、状況ＰＤＵを処理し、どのＰＤＵが再伝送を必要としているか学習する。
【発明の開示】
【発明が解決しようとする課題】
【００１３】
これら２つの場合のどちらにおいても、ソースノードＢ内にバッファされているデータを回復することが必要とされる場合は状況ＰＤＵが処理されるが、ＵＥによって再伝送データが適切に受信されるのは、かなり遅れることになる。これは、ＵＥによって状況ＰＤＵが生成されるのが、また、ＲＮＣ内で状況ＰＤＵが受信されるのが遅れるためである。
【００１４】
伝送がＲＬＣ肯定確認モードで実行されている場合、データの逐次送達が行われるまで、データは、より高い層に渡されない。したがって、ＵＥは、逸したＰＤＵを再伝送することができるまで、順序の乱れたデータをバッファすることを求められることになる。これは、伝送の遅延を引き起こすだけでなく、ソースノードＢ内に格納されたデータの送達に成功するまでデータをバッファするのに十分なメモリをＵＥが有していることが必要である。そうでない場合、有効なデータ伝送速度が低下し、それによりサービス品質に影響を及ぼすこととなる。メモリは非常にコストがかかるため、これは望ましくない設計制約である。
【００１５】
したがって、ターゲットノードＢに転送する前に、ソースノードＢ内にバッファされているデータを回復する従来技術の方法は、非常に望ましくない結果をもたらす。ユーザのサービス品質要件を適切に維持するために、より少ない遅延で、より効率的にソースノードＢ内にバッファされているデータを回復することができるシステムおよび方法を有することが望ましい。
【課題を解決するための手段】
【００１６】
本発明は、サービス側ＨＳ−ＤＳＣＨセル変更手順の間に待ち時間を低減し、潜在的にはＰＤＵ伝送の喪失を防止するため、一連の動作を実施する方法およびシステムである。ＲＬＣ  ＰＤＵの状況レポートをＵＥで生成するため、新しい基準が導入される。ソースノードＢによってバッファされたデータをより効率的に回復するために、ＵＥは、ＲＲＣハンドオーバ手順によって示されたＨＳ−ＤＳＣＨセル変更の通知に引き続いて、可能な限り早急にＰＤＵの状況レポートを独自に生成する。ＨＳ−ＤＳＣＨ移送チャネルに関連付けられた各肯定確認モード（ＡＭ）ＲＬＣインスタンスについてＰＤＵ状況を示すこともできる。
【発明を実施するための最良の形態】
【００１７】
本発明の好ましい実施形態について図面を参照して説明するが、全体を通して同じ数字は同じ要素を表すものとする。
【００１８】
ＲＮＣがＰＤＵの状況を取得して、ソースノードＢ内にバッファされているデータを回復するための待ち時間を低減するため、サービス側ＨＳ−ＤＳＣＨセル変更の後に、ＵＥは、ＲＲＣ手順によって示されたＨＳ−ＤＳＣＨセル変更の通知に引き続いて、ＰＤＵの状況をＲＮＣに自動的に送信する。ＨＳ−ＤＳＣＨ移送チャネルに関連付けられた各ＡＭ  ＲＬＣインスタンスにＰＤＵ状況の生成を適用することができる。
【００１９】
図１のフローチャートを参照すると、本発明のノードＢによってバッファされたデータを効率的に回復する方法１０が示されている。ＲＮＣは、サービス側ＨＳ−ＤＳＣＨセル変更の必要性を認識する（ステップ１２）。次いで、サービス側ＨＳ−ＤＳＣＨセル変更についてノードＢに通知する（ステップ１４）。ＲＲＣ要求メッセージを介して示されるサービス側ＨＳ−ＤＳＣＨセル変更についてＵＥに通知する（ステップ１６）。ステップ１４の前にステップ１６を呼び出すことも可能である。
【００２０】
ステップ１８でＲＲＣ要求メッセージがＵＥによって受信された後に、ソースノードＢ内にバッファされているデータを回復する際の遅延を低減するため、ＵＥは、ＲＲＣ手順によって示されたＨＳ−ＤＳＣＨセル変更の通知に引き続いて、可能な限り早急にＲＬＣ  ＰＤＵ状況を示す状況レポートを独自に生成する（ステップ２０）。ＵＥは、状況ＰＤＵを生成するためのいずれの従来技術のトリガ（たとえば、状況ＰＤＵを生成するためのＲＮＣによる要求、または、順序の乱れたデータの送達のＵＥによる検出）も待たない。
【００２１】
ＵＥにおいては、サービス側ＨＳ−ＤＳＣＨセル変更の後にＰＤＵ状況レポートの生成のトリガを引くためにＵＥが実装することができる多数の様々な代替方法がある。しかし、本明細書では、そのうちいくつかの例を提示する。第１の選択肢として、ＭＡＣ−ｈｓが、その再順序付けバッファがフラッシュされた後にＲＬＣに通知するのが望ましい。第２の選択肢は、ＲＲＣが、サービス側ＨＳ−ＤＳＣＨセル変更を示すレベル３（Ｌ３）ＲＲＣ手順についてＲＬＣに通知することである。第３に、物理層が、ターゲットセル内でのＨＳ−ＤＳＣＨ制御チャネルの受信についてＲＬＣに通知することができ、あるいは物理層が、ＨＳ−ＤＳＣＨ制御のターゲットセルへの切換えの際にＲＬＣに通知することができる。ＵＥからＲＮＣに送信すべきＲＬＣ  ＰＤＵ状況メッセージのトリガを引くための他の方法があり得ることを、当業者なら確実に理解できるであろう。こ手続きの結果として、ＰＤＵ状況は、あまり遅延せずに生成され、またＲＮＣに送信され（ステップ２２）、これにより、ソースノードＢによってバッファされたデータがより効率的に回復される。
【００２２】
ステップ２２においては、ＵＥがＲＮＣにＰＤＵの状況レポートを送信するためのいくつかの代替の形態がある。状況ＰＤＵを送信するこれらの方法は、どのように状況ＰＤＵをＵＥからＲＮＣに示すことができるかという例であり、新しい基準に応じて状況ＰＤＵを生成することに関する本発明の最重要事項ではない。ＵＥは、ＨＳ−ＤＳＣＨ移送チャネルにマッピングされた各ＡＭ  ＲＬＣインスタンスについてＲＬＣ状況レポートを生成するのが望ましい。
【００２３】
第２の代替の形態において、ＵＥは、状況レポートが得られたら直ちに、ＵＥからＲＮＣへの第１の既存のアップリンクメッセージを介してＰＤＵ状況レポートを送信する。イントラノードＢサービス側セル変更の場合（また、ＨＳ−ＤＳＣＨ移送チャネルおよび無線ベアラパラメータが変更されていないと仮定して）、メッセージは、ＤＣＣＨ上で「ＰＨＹＳＩＣＡＬ  ＣＨＡＮＮＥＬ  ＲＥＣＯＮＦＩＧＵＲＡＴＩＯＮ  ＣＯＭＰＬＥＴＥ（物理チャネル再構成完了）」である。ＨＳ−ＤＳＣＨ移送チャネルおよび無線ベアラパラメータが変更された場合、および／またはインターノードＢサービス側セル変更の場合、メッセージは、ＤＣＣＨ上で「ＴＲＡＮＰＳＯＲＴ  ＣＨＡＮＮＥＬ  ＲＥＣＯＮＦＩＧＵＲＡＴＩＯＮ  ＣＯＭＰＬＥＴＥ（移送チャネル再構成完了）」である。ＰＤＵ状況は、任意のＲＲＣシグナリングメッセージ内で識別することができる。次いで、ＲＮＣ  ＲＲＣエンティティは、ターゲットノードＢに対して伝送を再開するために、ＲＬＣにＰＤＵの状況を通知する。
【００２４】
第３の代替形態において、ＵＥは、ＵＥからＲＮＣへのＤＣＣＨ上の新しいＬ３シグナリングメッセージ上で状況レポートを送信する。この新しいメッセージは、ＵＥの無線リソース制御（ＲＲＣ）層からＲＮＣのＲＲＣ層に送信される。次いで、ＲＮＣは、ターゲットノードＢに対して伝送を再開するために、ＲＬＣ層にＰＤＵの状況を通知する。この場合、図１に示されているＰＤＵ状況メッセージは、「ＲＲＣ完了（ＲＲＣ  Ｃｏｍｐｌｅｔｅ）」と「ＲＬＣ状況（ＲＬＣ  Ｓｔａｔｕｓ）」という２つの別個のメッセージを含むことができる。
【００２５】
ＰＤＵの状況レポートの特定のフォーマットは変わる可能性があることに留意されたい。たとえば、ＰＤＵの状況レポートのフォーマットには、１）最後の成功裏に逐次送達されたＰＤＵのシーケンス番号（ＳＮ）、２）成功裏に受信されたＰＤＵの最大ＳＮ、３）成功裏に受信されたＰＤＵの最大ＳＮまで、受信するのに成功しなかったＰＤＵ（すなわち、逸したＰＤＵ）のＳＮ、または４）受信するのに成功したＰＤＵのＳＮのリストが含まれる。
【００２６】
ＲＮＣがＰＤＵ状況を送信するメッセージを受信した後に、ＰＤＵ状況メッセージは、逸したＰＤＵを決定するため、ＲＮＣ  ＲＬＣによって処理される（ステップ２４）。セル変更の結果、失われたデータは、今現在、ＲＮＣによって認識され、ＵＥに再伝送することができる（ステップ２６）。メッセージは、多数の代替の形態のものとすることができ、必ずしもＰＤＵ状況レポートを送信する形態だけに限定されないことに留意されたい。
【００２７】
また、本発明のこの実施形態において、ＲＮＣは、ステップ１６と２４の間で、ターゲットセル内でＵＥに伝送するために引き続きデータを転送することができることに留意されたい。ソースノードＢによってバッファされたデータすべてが成功裏に送信された場合、データは順序が乱れることになるため、ＵＥは、より高い層に対する逐次送達を維持するために、データをバッファせざるを得なくなる。これは、ＵＥが、順序の乱れたＰＤＵを格納するために十分なメモリを有することを必要とする。連続データの喪失の後に、失われた連続データが成功裏に伝送されるまで、伝送がＵＥメモリ容量に制限される。
【００２８】
図２のフローチャートを参照すると、本発明の一代替実施形態のノードＢによってバッファされたデータを効率的に回復する方法４０が示されている。この方法４０は、図１に示されている方法１０と同様であり、図１の場合と同じ符号が付けられている図２の諸ステップは、同一である。しかし、本発明の  本実施形態によれば、方法４０は、ステップ２４でＰＵＤ状況メッセージが処理されるまで、ＵＥに対するダウンリンクＨＳ−ＤＳＣＨ伝送すべてを中止する新しいステップ１７を含む。本実施形態は、ソースノードＢによってバッファされたデータを再伝送するための遅延を最小限に抑え、ＵＥ部でバッファしなければならないデータ量を制限する。
【００２９】
遅延を最小限に抑えることに関連して、ノードＢはＲＬＣ伝送シーケンス番号を知らず、ノードＢ内の伝送スケジューリングは、ＦＩＦＯベースである。したがって、ＰＤＵ状況が処理される前に、データがターゲットセル内でＲＮＣによって転送される場合、データが先に送信されることになる。ノードＢにおけるこのデータキューイングは、ソースノードＢによってバッファされたデータの再伝送をさらに遅らせる可能性がある。
【００３０】
本発明は、インターノードＢセル変更とイントラノードＢセル変更のＨＳ−ＤＳＣＨセル変更に共に適用することができる。イントラノードＢセル変更の場合には、内部設計問題により、ノードＢが、バッファされているＨＳ−ＤＳＣＨデータをターゲットセルに再指定することができない場合があり得るため、ＲＮＣは、どちらの場合についても、ＰＤＵ状況の生成の必要性を示すことができる。また、ＵＥは、インターノードＢセル変更とイントラノードＢセル変更を区別することができない可能性もあり、これもまた、インターとイントラのどちらの場合についても、ＰＤＵ状況を生成することになるであろう。そのような形で送信される状況ＰＤＵは、インターノードＢセル変更、またはバッファされているデータをターゲットセルに切り換えることができないイントラノードＢの場合において有用となる。
【００３１】
以上、本発明について詳しく述べたが、本発明はそれに限定されないこと、また、特許請求の範囲によって規定される本発明の精神および範囲から逸脱することなしに、様々な変更を加えることができることを理解されたい。
【図面の簡単な説明】
【００３２】
【図１】ＨＳ−ＤＳＣＨセル変更の後に、ノードＢによってバッファされたデータを効率的に回復するための、本発明による効率的な手順のフローチャートである。
【図２】ターゲットセル内で新しいデータの伝送を開始する前に、ＲＮＣが状況ＰＤＵを待つ代替方法のフローチャートである。
【図１】
2006025437.tif 000003
【図２】
2006025437.tif 000004