(57)【要約】転送ネットワーク局から候補ネットワーク局への移動局のソフト・ハンドオフの間にチャネル化コードの使用を管理する一実施形態では、候補ネットワーク局により使用される既存のチャネル化コードに関連付けられるフィールドが未使用であるかどうか、および転送ネットワーク局から移動局によって受信される対応フィールドに関連付けられるタイミング基準を満たすかどうかに関しての決定がなされる。この決定に基づいて、候補ネットワーク局が移動局との通信に使用するチャネル化コードが割り当てられる。
2009524996.tif 000002
【特許請求の範囲】
【請求項１】
転送ネットワーク局から候補ネットワーク局への移動局のソフト・ハンドオフの間にチャネル化コードの使用を管理する方法であって、
前記候補ネットワーク局によって使用される既存のチャネル化コードに関連付けられるフィールドが未使用であるかどうか、および前記転送ネットワーク局から前記移動局によって受信される対応フィールドに関連付けられるタイミング基準を満たすかどうかを決定するステップと、
前記決定するステップに基づいて、候補ネットワーク局が移動局との通信に使用するチャネル化コードを割り当てるステップと、
を含む、方法。
【請求項２】
前記決定するステップが、前記候補ネットワーク局によって使用される前記既存のチャネル化コードに関連付けられるフィールドが未使用であり、前記転送ネットワーク局から前記移動局によって受信される前記対応フィールドに関連付けられるタイミング基準を満たすことを決定する場合、前記割り当てるステップが前記既存のチャネル化コードを割り当てる、請求項１に記載の方法。
【請求項３】
前記既存のチャネル化コードの未使用フィールドが、前記転送ネットワーク局からの前記対応フィールドの受信に対して確立されるタイミング窓内で前記移動局によって受信される場合、前記タイミング基準が満たされる、請求項２に記載の方法。
【請求項４】
前記決定するステップが、前記候補ネットワーク局によって使用される前記既存のチャネル化コードに関連付けられるフィールドが未使用であり、前記転送ネットワーク局から前記移動局によって受信される前記対応フィールドに関連付けられるタイミング基準を満たすことを決定しない場合だけに、前記割り当てるステップが前記候補ネットワーク局による使用のために未使用チャネル化コードを割り当てる、請求項２に記載の方法。
【請求項５】
前記決定するステップが、前記候補ネットワーク局によって使用される前記既存のチャネル化コードに関連付けられるフィールドが未使用であり、前記転送ネットワーク局から前記移動局によって受信される前記対応フィールドに関連付けられるタイミング基準を満たすことを決定しない場合だけに、前記割り当てるステップが前記候補ネットワーク局による使用のために未使用チャネル化コードを割り当てる、請求項１に記載の方法。
【請求項６】
前記既存のチャネル化コードの未使用フィールドが、前記転送ネットワーク局からの前記対応フィールドの受信に対して確立されるタイミング窓内で前記移動局によって受信される場合、前記タイミング基準が満たされる、請求項１に記載の方法。
【請求項７】
前記割り当てるステップの後に、
前記転送ネットワーク局から前記移動局によって受信される前記対応フィールドに対応する前記割り当てられたチャネル化コードのフィールドの間のタイミングが、前記対応フィールドに対する許容可能なタイミング窓を超えてドリフトされているかどうかを検出するステップと、
前記検出するステップが、前記転送ネットワーク局から前記移動局によって受信される前記対応フィールドに対応する前記割り当てられたチャネル化コードの前記フィールドの間の前記タイミングが、前記対応フィールドに対する許容可能なタイミング窓を超えてドリフトされていることを検出する場合、前記決定するステップおよび前記割り当てるステップを繰り返すステップとをさらに含む、請求項１に記載の方法。
【請求項８】
前記検出するステップが、
前記割り当てられたチャネル化コードの前記フィールドと前記転送ネットワーク局から前記移動局によって受信される前記対応フィールドとの間のタイミング差異を決定するステップと、
前記タイミング差異の絶対値が閾値を超過する場合、許容可能なタイミング窓を超えるドリフトを検出するステップと、を含む、請求項７に記載の方法。
【請求項９】
前記割り当てるステップの後に、
（ｉ）前記転送ネットワーク局から前記移動局によって受信される前記対応フィールドに対応する前記割り当てられたチャネル化コードのフィールドと（ｉｉ）前記転送ネットワーク局から前記移動局によって受信される前記対応フィールドとの間の許容可能な同期化の欠如を検出するステップと、
前記検出するステップが許容可能な同期化の欠如を検出する場合、前記決定するステップおよび前記割り当てるステップを繰り返すステップとをさらに含む、請求項１に記載の方法。
【請求項１０】
前記候補ネットワーク局によって使用される１つのチャネル化コードが、前記候補ネットワーク局によって使用される別の使用済チャネル化コードの対応使用済フィールドに関連付けられるタイミング基準を満たす未使用フィールドを有するかどうかを判別するステップと、
前記判別するステップが、前記１つのチャネル化コードの対応使用済フィールドに関連付けられるタイミング基準を満たす未使用フィールドを前記別の使用済チャネル化コードが有することを判別する場合、前記１つのチャネル化コードの前記使用済フィールドが未使用になるように、前記別の使用済チャネル化コードの前記使用済フィールドの代わりに前記１つのチャネル化コードの前記未使用フィールドを使用するステップとをさらに含む、請求項１に記載の方法。
【発明の詳細な説明】
【背景技術】
【０００１】
図１は、ＵＭＴＳ無線通信ネットワークの一部を示す。示されるように、ユーザ装置ＵＥは、地理的領域（しばしば、セルまたはセルの集合と呼ばれる）の通信ニーズにサービスを提供するノードＢと無線通信する。ＵＥは、携帯電話、無線装備ＰＤＡ、無線装備ノート型パソコン、その他であってよい。ＵＥは、一般に、移動局または移動ユニットとも呼ばれる。ノードＢは、ネットワーク局であり、一般に、基地局とも呼ばれる。ノードＢは、種々のチャネル上でＵＥおよびノードＢを通信に関して構成し得る無線ネットワークコントローラ（ＲＮＣ）と通信する。
【０００２】
３ＧＰＰ仕様のリリース６バージョンの一部として、Ｆ−ＤＰＣＨ（断片的専用物理チャネル（Ｆｒａｃｔｉｏｎａｌ  Ｄｅｄｉｃａｔｅｄ  Ｐｈｙｓｉｃａｌ  ＣＨａｎｎｅｌ））の特性が組み込まれている。現在、３ＧＰＰ標準は、図２Ａに示されるようにＦ−ＤＰＣＨの使用を定義する。図２Ｂに示される通常のＤＰＣＣＨ（専用物理制御チャネル（Ｄｅｄｉｃａｔｅｄ  Ｐｈｙｓｉｃａｌ  Ｃｏｎｔｒｏｌ  ＣＨａｎｎｅｌ））スロット形式と対照的に、図２ＡはＦ−ＤＰＣＨスロット形式を示す。図２Ｂに示されるように、図２Ａに示されるＤＴＸ（不連続送信）周期の間、ＤＰＣＣＨスロット形式は、ＴＦＣＩ（転送形式組み合わせインジケータ（Ｔｒａｎｓｐｏｒｔ  Ｆｏｒｍａｔ  Ｃｏｍｂｉｎａｔｉｏｎ  Ｉｎｄｉｃａｔｏｒ））および専用パイロット・ビットを含む。一方、Ｆ−ＤＰＣＨは、制御情報、即ち、例えば、ノードＢからＵＥへの転送電力制御ビット（ＴＰＣ）を搬送する。即ち、全てのより高い層のデータ、制御およびユーザ・プレーンが、３ＧＰＰ仕様のリリース５バージョンの一部として規定されたＨＳ−ＤＳＣＨ転送チャネル上にマッピングされるときに、Ｆ−ＤＰＣＨが使用され得る。現在、Ｆ−ＤＰＣＨ上に保持される唯一の情報は、各ユーザに特化され、スロット毎に１度送信されるＴＰＣビットである。
【０００３】
図２Ａに示されるように、Ｆ−ＤＰＣＨのスロットは、各々が２５６チップの１０個のフィールドに分割され得る２５６０チップの長さを有する。（２５６チップの刻み幅で）異なるユーザの異なるＦ−ＤＰＣＨを時間的整合することによって、図３に示されるように、異なるＵＥのＴＰＣ情報を多重化するためにＤＴＸ周期が使用され得る。従って、Ｆ−ＤＰＣＨの動作は、単一のチャネル化コード上の最高１０人のユーザまたはＵＥを時間的に多重化することを可能にし、ユーザ毎に１つのチャネル化コードが利用される必要のある、前のリリースのＤＰＣＨ（専用物理チャネル（Ｄｅｄｉｃａｔｅｄ  Ｐｈｙｓｉｃａｌ  ＣＨａｎｎｅｌ））上の動作と比較してコード・リソースの使用をより効率的にする。別の言い方をすれば、単一のチャネル化コードは、各々が異なるユーザのＦ−ＤＰＣＨをサポートする１０個のフィールドを有し得る。従って、１０個のＵＥは、全てのＵＥのＦ−ＤＰＣＨに対する１０個の異なるチャネル化コードの代わりに、１０個のＦ−ＤＰＣＨに対する単一のチャネル化コードを利用して、サービスが提供され得る。
【０００４】
しかしながら、ＵＥまたは移動局のソフト・ハンドオフまたはハンドオーバー動作に関しては、Ｆ−ＤＰＣＨに対してチャネル化コードがこのやり方で使用されない。知られているように、ソフト・ハンドオフの間、ソフト・ハンドオフに関与する２つ以上のノードＢは、ＵＥに関するタイミング整合を保持することを試みる。この同期化を達成するためのプロセスはよく知られており、例えば、３ＧＰＰ  ＴＲ２５．８７８に記載されている。しかしながら、タイミング調整によって同期化が達成されたとしても、ドリフトが生じ、２つの異なるノードＢから受信されるＴＰＣビットをＵＥの所定の受信窓（ｒｅｃｅｐｔｉｏｎ  ｗｉｎｄｏｗ）（例えば、＋／−１４８チップ）に分ける要件を満たさない可能性がある。従って、１つの提案は、ソフト・ハンドオフの間に生じる各追加のノードＢとＵＥとの間の接続に対して追加のチャネル化コードを使用することを提言する。即ち、ソフト・ハンドオフが元のサービス提供ノードＢと２つの候補ノードＢに関与する場合、ＲＮＣは２つの新規のチャネル化コードを割り当て、１つを候補ノードＢの各々がＵＥへのＦ−ＤＰＣＨ送信に関しての使用に対して割り当てる。
【非特許文献１】３ＧＰＰ  ＴＲ２５．８７８
【非特許文献２】３ＧＰＰ  ＴＳ２５．３３１
【発明の開示】
【発明が解決しようとする課題】
【０００５】
本発明は、ソフト・ハンドオフの間に、チャネル化コードの使用を管理する方法を提供する。
【課題を解決するための手段】
【０００６】
転送ネットワーク局から候補ネットワーク局への移動局のソフト・ハンドオフの間にチャネル化コードの使用を管理する一実施形態では、候補ネットワーク局により使用される既存のチャネル化コードに関連付けられるフィールドが未使用であるかどうか、および転送ネットワーク局から移動局によって受信される対応フィールドに関連付けられるタイミング基準を満たすかどうかに関しての決定がなされる。この決定に基づいて、候補ネットワーク局が移動局との通信に使用するチャネル化コードが割り当てられる。
【０００７】
例えば、候補ネットワーク局により使用される既存のチャネル化コードに関連付けられるフィールドが未使用であり、転送ネットワーク局から移動局によって受信される対応フィールドに関連付けられるタイミング基準を満たすことが決定される場合、既存のチャネル化コードが割り当てられる。別の例では、候補ネットワーク局により使用される既存のチャネル化コードに関連付けられるフィールドが未使用であり、転送ネットワークから移動局によって受信される対応フィールドに関連付けられるタイミング基準を満たすことが決定されない場合にだけ、候補ネットワーク局による使用に関して未使用チャネル化コードが割り当てられる。
【０００８】
一実施形態では、転送ネットワーク局からの対応フィールドの受信に対して確立されるタイミング窓（ｔｉｍｉｎｇ  ｗｉｎｄｏｗ）内で移動局によって既存のチャネル化コードの未使用フィールドが受信される場合、タイミング基準が満たされる。例えば、タイミング窓は、転送ネットワーク局からの対応フィールドの受信に対して＋１４８チップから−１４８チップであってよい。
【０００９】
一実施形態では、割り当てるステップが、既存のチャネル化コードを割り当てる場合、既存のチャネル化コードのフィールドの間、候補ネットワーク局が順方向リンク通信チャネルデータを送信する。順方向リンク通信チャネルは、断片的専用物理チャネルであってよい。
【００１０】
別の実施形態では、転送ネットワーク局から移動局によって受信される対応フィールドに対応する割り当てられたチャネル化コードのフィールドのタイミングが、対応フィールドに関して許容可能なタイミング窓を超えるドリフトを検出するために監視される。許容可能なタイミング窓を超えるドリフトが検出される場合、次に、本発明の一実施形態に従ったチャネル化コード割り当てプロセスが繰り返される。さらに別の実施形態では、候補ネットワーク局によって使用される１つのチャネル化コードが、候補ネットワークによって使用される別の使用済チャネル化コードの対応使用済フィールドに関連付けられるタイミング基準を満たす未使用フィールドを有するかどうかが判別される。判別するステップが、この１つのチャネル化コードの対応使用済フィールドに関連付けられるタイミング基準を満たす未使用フィールドを別の使用済チャネル化コードが有すると判別する場合、この１つのチャネル化コードの使用済フィールドが未使用になるように、次に、別の使用済チャネル化コードの使用済フィールドの代わりに、この１つのチャネル化コードの未使用フィールドが使用される。
【００１１】
例示のみを目的として与えられ、従って、本発明を制限しない、本明細書の以下で与えられる詳細な説明と、同様の要素が同様の参照番号によって示される添付の図面とから、本発明がより完全に理解されるようになるであろう。
【発明を実施するための最良の形態】
【００１２】
図４は、本発明の一実施形態に従った、ソフト・ハンドオフまたはソフト・ハンドオーバーでのＵＥまたは移動局の一例を示す。この例では、第１のノードＢ１がＵＥの通信ニーズに最初にサービスを提供する。その後に、ＵＥは、ＵＥの通信ニーズの処理に関する責任が第１のノードＢ１から第２のノードＢ２に転送されるソフト・ハンドオフ動作を開始する。第１のノードＢ１は、しばしば転送ネットワーク局と呼ばれる。第２のノードＢ２は移動局の受信をする候補であるため、しばしば候補ネットワーク局と呼ばれる。知られているように、ソフト・ハンドオフの間、１つ以上の候補ネットワーク局が存在し得る。ソフト・ハンドオフ・プロセスはよく知られており、簡潔さの目的から詳細は説明されない。代わりに、本発明の実施形態に従った、ソフト・ハンドオフの際のチャネル化コードの管理でのＲＮＣの役割が詳しく説明される。
【００１３】
図４に示されるように、第１のノードＢ１からＵＥへの接続は第１の無線リンクＲＬ１と呼ばれ、第２のノードＢ２からＵＥへの接続は第２の無線リンクＲＬ２と呼ばれる。
【００１４】
本発明の一実施形態によれば、図４に示されるようにＵＥがソフト・ハンドオフの状態である場合、第１の無線リンクＲＬ１に関するチャネル化コードは、図３に示されるように多重化されたＦ−ＤＰＣＨを有するように構成される。即ち、ソフト・ハンドオフの前に第１のノードＢ１は、図３の多重化形式に従って動作している。そして、第１のノードＢ１によってサービスが提供される移動局がソフト・ハンドオフを開始してもこの形式が維持される。別の言い方をすれば、転送ノードＢのチャネル化コードの使用およびＦ−ＤＰＣＨの時間オフセットは変化しないままである。
【００１５】
しかしながら、ＲＮＣは、チャネル化コードの使用が最小化されるように、第２のノードＢ２−受信ノードＢ２−の多重化形式を管理する。
【００１６】
上述されたように、ソフト・ハンドオフの間、ＲＮＣは、ＵＥに対して第１の無線リンクＲＬ１と第２の無線リンクＲＬ２との間のタイミング整合を維持することを試みる。例えば、第１の無線リンクＲＬ１および第２の無線リンクＲＬ２上のＵＥへのＦ−ＤＰＣＨ送信が同期化される。さらに上述されたように、この同期化を達成するプロセスはよく知られており、例えば、３ＧＰＰ  ＴＲ２５．８７８に記載されている。しかしながら、タイミング調整によって同期化が達成されても、ドリフトが生じ、２つの異なるノードＢから受信されるＴＰＣビットをＵＥの所定の受信窓（例えば、＋／−１４８チップ）に分ける要件を満たさない可能性がある。
【００１７】
従って、ＲＮＣは、このタイミング基準が満たされるかどうかを監視し、この監視に基づいて第２のノードＢ２でのＦ−ＤＰＣＨに対するチャネル化コードの使用が管理される。この管理プロセスは、次に、図５〜８に関して以下で詳細が説明される。図５は、ソフト・ハンドオフ動作が開始される場合、ＲＮＣによって実行されるチャネル化コード管理プロセスのフローチャートを示す。示されるように、ステップＳ１０で、ＲＮＣは、ＲＬ１上の移動局に対するＦ−ＤＰＣＨのＴＰＣフィールドのタイミングを決定する。即ち、ＲＮＣは、例えば、３ＧＰＰ  ＴＳ２５．３３１に記載されているように、よく知られているようにタイミング報告を受信してよい。
【００１８】
このタイミング情報に基づいて、ステップＳ１２で、ＲＮＣは、第１の無線リンクＲＬ１上のＵＥに対するＴＰＣのタイミングに合致する未使用ＴＰＣフィールドを有するＦ−ＤＰＣＨに対して第２のノードＢ２が何らかの既存のチャネルコードを使用するかどうかを決定する。第１の無線リンクＲＬ１上の移動局によるＴＰＣフィールドの受信に関してタイミング窓（例えば、＋／−１４８チップ）内で移動局によって既存のチャネル化コードの未使用ＴＰＣフィールドが受信される場合、タイミング合致が生じる。そうである場合、次に、第２無線リンクＲＬ２上のＴＰＣフィールドが第１の無線リンクＲＬ１上の対応するＴＰＣフィールドのタイミングと合致するように、ＲＮＣは、ＵＥに対するＴＰＣフィールドまたはＦ−ＤＰＣＨの送信で既存のチャネル化コードを使用するように第２のノードＢ２に指示する。しかしながら、合致がみつからない場合、次にステップＳ１６で、ＲＮＣは、未使用チャネル化コードのプールから新規のチャネル化コードを第２のノードＢに割り当て、第２の無線リンクＲＬ２のＴＰＣフィールドのタイミングが第１の無線リンクＲＬ１上のＴＰＣフィールドのタイミングと合致するように、第２の無線リンクＲＬ２上のＴＰＣフィールドの送信で新規のチャネル化コードを使用するように第２のノードＢ２に指示する。
【００１９】
理解されるように、ステップＳ１２で合致がみつかる場合、次に、ソフト・ハンドオフの間、Ｆ−ＤＰＣＨ送信に関して使用されるチャネル化コードの数が最小に維持され得る。図８は、第２の無線リンクＲＬ２上で同じチャネル化コードを有する異なるＵＥに関するＴＰＣフィールドの一例を示す。示されているように、この例では、いくつかのＵＥのＴＰＣフィールドの間のいくつかの２５６チップの間隙と共に５人のユーザが１つのチャネル化コード上に多重化される。各第１の無線リンクのタイミングによって決定されるＵＥの受信窓がこのチャネル化コードに関するＴＰＣフィールドの利用を可能にしない場合、これらの間隙が生じる。
【００２０】
さらに、理解されるように、かつ上述されたように、ハンドオフが開始された後、ＵＥに対する第１の無線リンクＲＬ１上のＴＰＣフィールドと第２の無線リンクＲＬ２上のＴＰＣフィールドとの間の同期化のドリフトが生じ得る。その結果、ＲＮＣは、ＵＥに対して第２無線リンクＲＬ２上で使用されるチャネル化コードおよび／またはＴＰＣフィールドを変更する必要があり得る。この更新プロセスは、図６のフローチャートに示されている。ソフト・ハンドオフの間、ＲＮＣは、例えば、ＴＳ２５．３３１に記載されるような、任意の公知のやり方で、第１および第２の無線リンクＲＬ１およびＲＬ２のタイミングの最新情報をステップＳ２０で受信する。このタイミング情報に基づいて、ＲＮＣは、ステップＳ２２で、第２の無線リンクＲＬ２上でのＵＥに対するＦ−ＤＰＣＨのタイミングが変更されるべきであるかどうかを決定する。例えば、ＲＮＣは、第１および第２の無線リンクＲＬ１およびＲＬ２上のＴＰＣフィールドの間のタイミング差異を決定（例えば、ドリフトを決定）してよく、このタイミング差異が閾値を超過する場合、ＲＮＣは、第２の無線リンクＲＬ２上のＵＥに対するＦ−ＤＰＣＨのタイミングを変更することを決定する。即ち、変更が決定される場合、プロセスは、図５のステップＳ１２に進み、そこでＲＮＣが、既存のチャネル化コードの新規の未使用ＴＰＣフィールドを割り当てるか、第２の無線リンクＲＬ２上のＦ−ＤＰＣＨに対する新規のチャネル化コードを割り当てる。理解されるように、これは、第２の無線リンクＬＲ２上で現在使用されているのと同じチャネル化コードと共に異なるＴＰＣフィールドを使用することを生じ得るか、または異なる既存のチャネル化コードの使用を生じ得る。さらに、これは、チャネル化コードが未使用になることを生じ得る。そうである場合、次に、将来の割り当てのために、チャネル化コードが未使用のチャネル化コードのプールに戻される。ステップＳ２２に戻って、タイミング変更がなされない場合、次に、ＲＮＣは、ＵＥに対するチャネル化コードの使用を保持する。
【００２１】
さらに、許容可能なタイミング窓（例えば、＋／−上記の例の閾値）は、ステップＳ１２で使用されるのと同一のタイミング窓である必要はないが、同じであってもよいことを理解されるであろう。さらに、ステップＳ１２のタイミング窓とステップＳ２２のタイミング窓との両方が第１の無線リンクＲＬ１上の移動局によって受信されるＴＰＣフィールドに対して対称的であるように説明されたが、これらのタイミング窓の一方または両方が非対称的であってよい。
【００２２】
ドリフトの結果としてチャネル化コードの管理を継続することに加えて、ＲＮＣは、使用されるチャネル化コードの数を最小化するためにチャネル化コードの管理を継続する。この管理プロセスの一例が図７に示されている。図７に示される管理プロセスは、例えば、最少使用チャネル化コード上に現在スケジュールされている各ＵＥに対して実行され、ステップＳ２０で上述されたように、ＵＥから取得されるタイミング情報に基づいて実行される。以下のプロセスは、最少使用チャネル化コードに対して実行されるものとして説明されるが、ＵＥによって使用される別のチャネル化コードに対して適用されてもよいし、ＵＥによって使用される別のチャネル化コードと同等の適用がみつけられてもよい。最少使用チャネル化コード上の各ＵＥに対して、ステップＳ３０で、ＲＮＣは、別の既存のチャネル化コードが、最少使用チャネル化コード上のＵＥに対するＴＰＣフィールドのタイミングと合致する未使用のＴＰＣフィールドを有するかどうかを決定する。そうである場合、次に、ステップＳ３４で、ＲＮＣは、ＴＰＣフィールドに対するチャネル化コード（例えば、Ｆ−ＤＰＣＨ）を別の既存のチャネル化コードに変更する。次に、ステップＳ３６で、ＲＮＣは、ステップＳ３４の結果として、最少使用チャネル化コードが未使用になったかどうかを決定する。そうである場合、ＲＮＣは、ステップＳ３８で、最少使用チャネル化コードを未使用チャネル化コードのプールに戻す。最少使用チャネル化コードがなお使用されている場合、次に、ＲＮＣはステップＳ３０に戻って、最少使用チャネル化コードを使用して次のＵＥに対するプロセスを開始する。ステップＳ１２と同様に、使用済ＴＰＣフィールドの受信に関してタイミング窓（例えば、＋／−１４８チップ）内で未使用ＴＰＣフィールドが移動局によって受信される場合、タイミング合致が生じる。
【００２３】
上述したように、ステップＳ３０で、ＲＮＣは、最少使用チャネル化コード上のＵＥに対するＴＰＣフィールドのタイミングと合致する未使用ＴＰＣフィールドを別の既存のチャネル化コードが有するかどうかを決定する。合致がみつからない場合、次に、ステップＳ３２で、ＲＮＣは、ＵＥによる最少使用チャネル化コードの現在の使用を維持し、最少使用チャネル化コードを使用する次のＵＥに対するプロセスを開始する。
【００２４】
上述されたように、このプロセスは、次に、ノードＢによって使用中の別のチャネル化コードに対して繰り返され得る。
【００２５】
理解されるように、本発明の実施形態は、ソフト・ハンドオフの間にＦ−ＤＰＣＨを使用してＵＥに対するコード・リソースを節約することを実現する。それゆえに、ソフト・ハンドオフでのＦ−ＤＰＣＨ動作がより効率的である。さらに、本発明の実施形態は、ＲＮＣによって実行される、より改良された無線リソース管理を可能にする。そして、これらの方法の実装から高いシステム能力がもたらされる。
【００２６】
本発明は上述したように説明されたが、それらが多数のやり方で変更され得ることは自明であろう。例えば、Ｆ−ＤＰＣＨの時間的多重化に適用されているが、本発明は、別のチャネルに対するチャネル化コードを管理すること、または別の種類のコードを管理することと同等の適用をみつけ得る。そのような変更は、本発明からの逸脱とみなされず、そのような修正の全ては、本発明の範疇の範囲内に含まれることが意図されている。
【図面の簡単な説明】
【００２７】
【図１】ＵＭＴＳ無線通信ネットワークの一部の説明図である。
【図２Ａ】Ｆ−ＤＰＣＨチャネルの従来技術のスロット形式の説明図である。
【図２Ｂ】ＤＰＣＨチャネルの従来技術のスロット形式の説明図である。
【図３】単一のチャネル化コードを使用する複数のＵＥに対するＦ−ＤＰＣＨチャネルの従来技術の時間的多重化の説明図である。
【図４】本発明の一実施形態に従った、ソフト・ハンドオフまたはソフト・ハンドオーバーでのＵＥの一例の説明図である。
【図５】本発明の一実施形態に従った、ソフト・ハンドオフが開始する場合に実行されるチャネル化コード管理プロセスのフローチャートの説明図である。
【図６】本発明の一実施形態に従った、ソフト・ハンドオフの間に実行されるチャネル化コード管理プロセスのフローチャートの説明図である。
【図７】本発明の一実施形態に従った、ソフト・ハンドオフの間に実行されるチャネル化コード管理プロセスのフローチャートの説明図である。
【図８】本発明の一実施形態に従った、ＲＮＣによるソフト・ハンドオーバーに関与するノードＢでのＦ−ＤＰＣＨチャネルの時間的多重化の説明図である。
【図１】
2009524996.tif 000003
【図２Ａ】
2009524996.tif 000004
【図２Ｂ】
2009524996.tif 000005
【図３】
2009524996.tif 000006
【図４】
2009524996.tif 000007
【図５】
2009524996.tif 000008
【図６】
2009524996.tif 000009
【図７】
2009524996.tif 000010
【図８】
2009524996.tif 000011
【国際調査報告】
2009524996.tif 000012
2009524996.tif 000013
2009524996.tif 000014