(57)【要約】  本発明は、無線通信システムにおいて時分割複信（ＴＤＤ）とＦＤＤ（ＦＤＤ）との間でリソース配分を統合する。無線ネットワーク制御装置（ＲＮＣ）は、コアネットワークまたは無線送受信ユニット（ＷＴＲＵ）から無線アクセスベアラ（ＲＡＢ）リクエストを受信する。リクエストに応答して無線リソースを割り当てるため、ＲＮＣはＴＤＤ−ＦＤＤセレクタを利用する。ＴＤＤ−ＦＤＤセレクタは、受信ＲＡＢリクエストに関する様々なパラメータを評価し、ＴＤＤリソースまたはＦＤＤリソースのどちらを割り当てるのが好ましいか、またそのようなリソースが現在利用可能かどうかを決定する。リソースが割り当てられると、現在のリソース配分に最適化を施し得るかどうかを決定するため、システム状態が評価される。
2007507180.tif 000002
【特許請求の範囲】
【請求項１】
無線送受信ユニット（ＷＴＲＵ）を含む無線通信システムにおいて時分割複信（ＴＤＤ）モードと周波数分割複信（ＦＤＤ）モードの間のハンドオーバのための装置であって、
サービスリクエストについて複数のポリシー関連入力に基づいて適切な通信モードを決定するためのポリシーサーバと、
前記ポリシーサーバの出力に従ってＴＤＤモードとＦＤＤモードの間で通信モードを変更するためのハンドオーバユニットと
を具えたことを特徴とする装置。
【請求項２】
前記ポリシー関連入力は、前記サービスリクエストにとって必要なサービス品質に関する入力と、前記サービスリクエストに固有の条件に関する入力と、前記無線通信システムの管理に関する入力と、前記ＷＴＲＵの挙動に関する入力とを含むことを特徴とする請求項１記載の装置。
【請求項３】
１つまたは複数のポリシー関連入力が、その他のポリシー関連入力よりも高い優先度を有することを特徴とする請求項２記載の装置。
【請求項４】
前記ポリシー関連入力は、汎用無線ネットワーク制御装置（ＲＮＣ）制御ロジック、無線リソース管理機能、または外部エンティティによって提供されることを特徴とする請求項１記載の装置。
【請求項５】
独立型ＲＮＣに含まれることを特徴とする請求項１記載の装置。
【請求項６】
ＦＤＤモードおよびＴＤＤモード通信の両方のために構成される無線リソースマネージャをさらに備えることを特徴とする請求項１記載の装置。
【請求項７】
無線送受信ユニット（ＷＴＲＵ）を含む無線通信システムにおいて時分割複信（ＴＤＤ）モードと周波数分割複信（ＦＤＤ）モードの間のハンドオーバのための方法であって、
ＴＤＤモードまたはＦＤＤモードのどちらかでコネクションを確立するステップと、
サービスリクエストを受信するステップと、
通信モードを遷移させるように、前記サービスリクエストについて１つまたは複数のポリシーが満たされているかどうかを決定するステップと、
前記決定に従って現在のモードから別のモードへの遷移を実行するステップと
を具えたことを特徴とする方法。
【請求項８】
ポリシー関連入力が、前記サービスリクエストにとって必要なサービス品質に関する入力と、前記サービスリクエストに固有の条件に関する入力と、前記無線通信システムの管理に関する入力と、前記ＷＴＲＵの挙動に関する入力とを含むことを特徴とする請求項７記載の方法。
【請求項９】
前記ポリシー関連入力は、汎用無線ネットワーク制御装置（ＲＮＣ）制御ロジック、無線リソース管理機能、または外部エンティティによって提供されることを特徴とする請求項７記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線通信システムに関する。より詳細には、本発明は、無線通信システムにおいて時分割複信（ＴＤＤ：ｔｉｍｅ  ｄｉｖｉｓｉｏｎ  ｄｕｐｌｅｘ）と周波数分割複信（ＦＤＤ：ｆｒｅｑｕｅｎｃｙ  ｄｉｖｉｓｉｏｎ  ｄｕｐｌｅｘ）との間でリソース配分を統合することに関する。
【背景技術】
【０００２】
当技術分野において無線通信システムが良く知られている。無線システムに大域的な接続性を提供するため、規格が開発され、実施されている。広く使用されている現行規格の１つは、移動体通信用グローバルシステム（ＧＳＭ：Global System for Mobile Telecommunications）として知られている。これはいわゆる第２世代移動体無線システム規格（２Ｇ）と見なされており、その改訂版（２．５Ｇ）が後に続いた。ＧＰＲＳおよびＥＤＧＥは、２．５Ｇ技術の例であり、（２Ｇ）ＧＭＳネットワーク上で相対的に高速なデータサービスを提供する。これらの規格は各々、付加的特徴および機能強化を加えて従来技術を改良しようと試みた。１９９８年１月、欧州電気通信標準化機構の移動体特別部会（ＥＴＳＩ  ＳＭＧ：European Telecommunications Standard Institute-Special Mobile Group）が、ユニバーサル移動体通信システム（ＵＭＴＳ：Universal Mobile Telecommunications Systems）と呼ばれる第３世代無線システム用の無線アクセス方式に合意した。さらにＵＭＴＳ規格を実施するため、１９９８年１２月、第３世代パートナーシッププロジェクト（３ＧＰＰ：Third Generation Partnership Project）が結成された。３ＧＰＰは、共通第３世代移動体無線規格（common third generational mobile radio standard）に関する作業を続けている。
【０００３】
現在の３ＧＰＰ仕様による典型的なＵＭＴＳシステム構成が、図１に示されている。ＵＭＴＳシステム構成は、現在公に利用可能な３ＧＰＰ仕様文書で詳細に定義されているＩｕとして知られるインターフェースを介して、ＵＭＴＳ地上無線アクセスネットワーク（ＵＴＲＡＮ：Ｔｅｒｒｅｓｔｒｉａｌ  Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ）に相互接続されたコアネットワーク（ＣＮ）を含む。ＵＴＲＡＮは、Ｕｕとして知られる無線インターフェースを介し、３ＧＰＰではユーザ機器（ＵＥ）として知られる無線送受信ユニット（ＷＴＲＵ：ｗｉｒｅｌｅｓｓ  ｔｒａｎｓｍｉｔ  ｒｅｃｅｉｖｅ  ｕｎｉｔ）を通して、ユーザに無線通信サービスを提供するように構成される。ＵＴＲＡＮは、１つまたは複数の無線ネットワーク制御装置（ＲＮＣ：Ｒａｄｉｏ  Ｎｅｔｗｏｒｋ  Ｃｏｎｔｒｏｌｌｅｒ）と、３ＧＰＰではノードＢとして知られる基地局とを有し、これらは共同して、ＵＥとの無線通信のための地理的カバレージを提供する。１つまたは複数のノードＢが、３ＧＰＰではＩｕｂとして知られるインターフェースを介して、各ＲＮＣに接続される。ＵＴＲＡＮは、異なるＲＮＣに接続された複数のノードＢのグループを有することができ、図１に示された例には２つのグループが示されている。ＵＴＲＡＮに２以上のＲＮＣが提供される場合、Ｉｕｒインターフェースを介してＲＮＣ間通信が実行される。
【０００４】
ネットワーク構成要素の外部の通信は、ユーザレベルではＵｕインターフェースを介してノードＢによって、またネットワークレベルでは外部システムへの様々なＣＮ接続を介してＣＮによって実行される。
【０００５】
一般に、ノードＢおよびアクセスポイントなどの基地局の主要機能は、基地局のネットワークとＷＴＲＵの間で無線接続を提供することである。通常、基地局は、非接続ＷＴＲＵが基地局のタイミングと同期できるように、共通チャネル信号を発信する。３ＧＰＰでは、ノードＢはＵＥとの物理無線接続を実行する。ノードＢによってＵｕインターフェースを介して送信される信号を制御するＲＮＣから、ノードＢはＩｕｂインターフェースを介して信号を受信する。
【０００６】
ＣＮは、情報を正しい宛先にルーティングする責任を負う。例えば、ＣＮは、ノードＢの１つを介してＵＭＴＳによって受信されたＵＥからの音声トラフィックを公衆交換電話網（ＰＳＴＮ）に、またはインターネット行きのパケットデータをルーティングすることができる。３ＧＰＰでは、ＣＮは６つの主要構成要素、すなわち、１）サービス提供汎用パケット無線サービス（ＧＰＲＳ：Ｇｅｎｅｒａｌ  Ｐａｃｋｅｔ  Ｒａｄｉｏ  Ｓｅｒｖｉｃｅ）支援ノード、２）ゲートウェイＧＰＲＳ支援ノード、３）境界ゲートウェイ、４）在圏ロケーションレジスタ（ｖｉｓｉｔｏｒ  ｌｏｃａｔｉｏｎ  ｒｅｇｉｓｔｅｒ）、５）移動サービス交換センタ、および６）ゲートウェイ移動サービス交換センタを有する。サービス提供ＧＰＲＳ支援ノードは、インターネットなどのパケット交換ドメインへのアクセスを提供する。ゲートウェイＧＰＲＳ支援ノードは、その他のネットワークに接続するためのゲートウェイノードである。他の通信事業者ネットワークまたはインターネットに向うすべてのデータトラフィックは、ゲートウェイＧＰＲＳ支援ノードを通過する。境界ゲートウェイは、ネットワークの外部の侵入者によるネットワーク領域内の加入者への攻撃を防ぐためのファイアウォールとして機能する。在圏ロケーションレジスタは、現在のサービス提供ネットワークがもつ、サービスを提供するのに必要な加入者データのコピーである。この情報は最初、移動加入者を管理するデータベースから来る。移動サービス交換センタは、ＵＭＴＳ端末からネットワークへの回路交換接続を担当する。ゲートウェイ移動サービス交換センタは、加入者の現在地に基づいて必要とされるルーティング機能を実施する。ゲートウェイ移動サービス交換センタはまた、加入者から外部ネットワークへの接続リクエストを受信し、管理する。
【０００７】
ＲＮＣは一般に、ＵＴＲＡＮの内部機能を制御する。ＲＮＣは、例えば国内ＵＭＴＳ内のセル電話からかけられた海外通話など、Ｕｕインターフェースを介してノードＢと接続されるローカル構成要素と、ＣＮと外部システムの間のコネクションを介した外部サービス構成要素とを有する通信のための仲介サービスも提供する。
【０００８】
一般に、ＲＮＣは、複数の基地局を監視し、ノードＢによってサービスを受ける無線サービスカバレージ（ｗｉｒｅｌｅｓｓ  ｒａｄｉｏ  ｓｅｒｖｉｃｅ  ｃｏｖｅｒａｇｅ）の地理的エリア内のリソースを管理し、Ｕｕインターフェースのための物理無線リソースを制御する。３ＧＰＰでは、ＲＮＣのＩｕインターフェースは、ＣＮへの２つのコネクションを提供し、一方はパケット交換ドメインへのコネクション、他方は回路交換ドメインへのコネクションである。ＲＮＣのその他の重要な機能には、機密性および完全性保護が含まれる。
【０００９】
第３世代パートナーシッププロジェクト（３ＧＰＰ）の時分割複信（ＴＤＤ）および周波数分割複信（ＦＤＤ）システムなどの通信システムでは、可変速度データの複数の共用および専用チャネルが、送信のために合成される。そのようなシステムのためのバックグラウンド仕様データ（ｂａｃｋｇｒｏｕｎｄ  ｓｐｅｃｉｆｉｃａｔｉｏｎ  ｄａｔａ）は、公に利用可能であり、開発され続けている。
【００１０】
ほぼすべての無線通信システムは、ＵＬおよびＤＬトラフィック用に２つの異なるチャネルを使用する。ＴＤＤタイプのシステムでは、ＵＬおよびＤＬチャネルは、同じ周波数帯域に存在する。ＵＬおよびＤＬチャネルの間の分割は、時間領域で行われる。したがって、ある特定の周波数搬送波に関して、その周波数搬送波の具体的なリンク方向は、その単一の周波数搬送波上で現在処理されているのはＵＬトラフィックか、それともＤＬトラフィックかに応じて、ＵＬとＤＬの間で交替する。対照的に、ＦＤＤタイプのシステムでは、ＵＬおよびＤＬコネクション用に２つの周波数帯域が使用される。従来のコードレス電話、北米セルラ無線（Ｎｏｒｔｈ  Ａｍｅｒｉｃａｎ  ｃｅｌｌｕｌａｒ  ｒａｄｉｏ）、マイクロ波ポイントツーポイント無線（ｍｉｃｒｏｗａｖｅ  ｐｏｉｎｔ−ｔｏ−ｐｏｉｎｔ  ｒａｄｉｏ）、および衛星システムを含む大部分のシステムは、ＦＤＤタイプの技術を実施する。
【００１１】
無線通信システムの発展に伴い、そのようなシステムを介して搬送されるトラフィックのタイプは、音声通信ばかりでなく、様々なタイプのデータ送信も含むように発展した。例えば、無線通信システムを介したマルチメディアデータ送信は、ＵＬおよびＤＬの間でしばしば非対称トラフィック負荷を生じさせる。さらに、ＴＤＤタイプのシステムとＦＤＤタイプのシステムの両方が無線ユーザから利用可能なカバレージエリアのオーバラップが増加している。
【００１２】
当業者に知られているように、ＴＤＤタイプのシステムでは、ＵＬチャネルとＤＬチャネルの数は、特定の時間および場所におけるトラフィック条件に従って、動的に調整することができる。したがって、ＴＤＤタイプのシステムは、高いデータ速度を有する非対称（またはそれ以外の不平衡）トラフィックを処理するのにより適している。しかし、ＦＤＤシステムは、ＵＬおよびＤＬリソースの所定配分のため、音声トラフィックなど低速から中速の一定のデータ速度をもつサービスを処理するのにより適しているという点で、ＴＤＤタイプのシステムにまさる利点を有する。
【発明の開示】
【発明が解決しようとする課題】
【００１３】
ＴＤＤタイプのシステムとＦＤＤタイプのシステムの間の無線リソース管理は、各システムタイプで別個に独自の配分方法に従って実行される。この構成は、無線通信システムにおける時分割複信（ＴＤＤ）と周波数分割複信（ＦＤＤ）の間の統合的なリソース配分によって達成されるかもしれない潜在的な最適化を阻害する。
【００１４】
したがって、無線通信システムにおいてＴＤＤとＦＤＤの間の無線リソース管理を統合する必要がある。
【課題を解決するための手段】
【００１５】
本発明は、無線通信システムにおいて時分割複信（ＴＤＤ）とＦＤＤ（ＦＤＤ）との間でリソース配分を統合する。無線ネットワーク制御装置（ＲＮＣ）は、コアネットワークまたは無線送受信ユニット（ＷＴＲＵ）から無線アクセスベアラ（ＲＡＢ：ｒａｄｉｏ  ａｃｃｅｓｓ  ｂｅａｒｅｒ）リクエストを受信する。リクエストに応答して無線リソースを割り当てるため、ＲＮＣはＴＤＤ−ＦＤＤセレクタを利用する。ＴＤＤ−ＦＤＤセレクタは、受信ＲＡＢリクエストに関する様々なパラメータを評価し、ＴＤＤリソースまたはＦＤＤリソースのどちらを割り当てるのが好ましいか、またそのようなリソースが現在利用可能かどうかを決定する。リソースが割り当てられると、現在のリソース配分に最適化を施し得るかどうかを決定するため、システム状態が評価される。
【発明を実施するための最良の形態】
【００１６】
本発明は、図面を参照して説明されるが、すべての図面にわたって同じ番号は同じ要素を表す。
【００１７】
以降、「ＷＴＲＵ」という用語は、ユーザ機器、移動局、固定もしくは移動加入者ユニット、ページャ、または無線環境で動作可能なその他のタイプの任意の装置を含むが、これらに限定されない。以降で言及される場合、「基地局」という用語は、ノードＢ、サイトコントローラ、アクセスポイント、または無線環境におけるその他の任意のインターフェース装置を含むが、これらに限定されない。
【００１８】
今度は図２を参照すると、本発明による無線通信システム２００が示されている。システム２００は、コアネットワーク２０２に接続された、ＴＤＤ無線ネットワーク制御装置（ＲＮＣ）２０４と、ＦＤＤ  ＲＮＣ２０８とを含む。ＲＮＣ２０４、２０８は各々、少なくとも１つの基地局を制御する。例えば、ＴＤＤ  ＲＮＣ２０４は、基地局２１２を制御する。その基地局２１２は、カバレージエリア２１０を提供し、カバレージエリア２１０内で動作するＷＴＲＵ２２８、２３０は、ＴＤＤ  ＲＮＣ２０４からリソースを割り当てられることができる。同様に、ＦＤＤ  ＲＮＣ２０８は、基地局２１６を制御し、その基地局２１６は、カバレージエリア２１４を提供する。ＷＴＲＵ２２０、２２２は、ＦＤＤ  ＲＮＣ２０８からリソースを割り当てられることができる。エリア２１８では、ＴＤＤおよびＦＤＤサービスの両方が、ＷＴＲＵ２２４、２２６から利用可能である。エリア２１８のような重なり合うカバレージエリアは、任意の大きさをとることができ、図２に示された特定の構成は、まったくの例であるに過ぎない。
【００１９】
無線アクセスベアラ（ＲＡＢ）リクエスト（すなわち呼確立リクエスト）が、コアネットワークまたはＷＴＲＵからＲＮＣに送信される場合、リクエストは通常、要求されたコネクションがどのように利用されるかに関する情報を提供する複数のパラメータと一緒に送信される。そのようなパラメータの例として、アップリンクとダウンリンクの間の対称度（すなわち要求されたコネクションの対称性または対称ステータス）、データ転送速度、フレームサイズ、アプリケーションタイプ、および要求されたコネクションがポイントツーポイントか、ポイントツーマルチポイントか、それともブロードキャストかなどを挙げることができるが、これらに限定されない。上記のパラメータは、まったくの例であるに過ぎず、要求されたコネクションに関する情報を提供する任意のタイプのパラメータを利用することができる。
【００２０】
本発明のＲＮＣ２０４、２０８は、それぞれＴＤＤ−ＦＤＤセレクタ２０６、２１０を備えて構成される。ＴＤＤ−ＦＤＤセレクタ２０６、２１０は、受信ＲＡＢリクエストにとって最適の技術タイプを決定するための、所望の１つまたは複数のプロセッサとすることができる。すなわち、例えば、ＲＡＢリクエスト、リソース利用可能性、および／またはその他の関連する考慮事項に関して提供されたパラメータに基づいて、ＴＤＤ−ＦＤＤセレクタ２０６、２１０は、個々のタイプのコネクションリクエストを処理するのに最も効率的なシステム技術タイプに基づいてコネクションリクエストがリソースの割り当てを受けるように、無線リソースマネージャ（ＲＲＭ：ｒａｄｉｏ  ｒｅｓｏｕｒｃｅ  ｍａｎａｇｅｒ）を始めとするＲＮＣの既存機能と連携して、リソースを割り当てるために動作する。例えば、対称性が最優先の考慮事項だと仮定すると、対称トラフィック（すなわちアップリンクとダウンリンクのトラフィック量が同程度）を有するコネクションリクエストは、ＦＤＤ技術をもちろん実施する、そのようなトラフィックを処理する際により効率的な、ＦＤＤ  ＲＮＣ２０８によって好ましくは処理される。同様に、非対称トラフィック（すなわち一方の方向のトラフィック量が他方よりも多い）を有するコネクションリクエストは、ＴＤＤ技術をもちろん実施する、そのようなトラフィックを処理する際により効率的な、ＴＤＤ  ＲＮＣ２０４によって好ましくは処理される。
【００２１】
例えば、やはり対称性が最優先の考慮事項である場合、個々の受信ＲＡＢリクエストにとって好ましい技術タイプを決定するため、ＴＤＤ−ＦＤＤセレクタ２０６、２１０は、その受信ＲＡＢリクエストについてアップリンクおよびダウンリンクのデータ速度を推定することができる。アップリンクおよびダウンリンクの推定データ速度は、例えば、要求データ速度、現在のトラフィック状態、現在の干渉レベル、またはその他の任意の関連パラメータに基づいて推定することができる。ＴＤＤ−ＦＤＤセレクタ２０６、２１０は、その後、アップリンクおよびダウンリンクの推定データ速度の差と所定の閾値とを比較することができる。アップリンクおよびダウンリンクの推定データ速度の差が閾値と等しいか、または閾値より大きい場合、ＲＡＢリクエストは非対称であると（すなわち非対称の対称ステータスを有すると）見なすことができ、ＴＤＤ  ＲＮＣ２０４からのリソースを割り当てることができる。推定データ速度の差が閾値より小さい場合、ＲＡＢリクエストは対称であると（すなわち対称の対称ステータスを有すると）見なすことができ、ＦＤＤ  ＲＮＣ２０８からのリソースを割り当てることができる。
【００２２】
上述したように、受信ＲＡＢリクエストに基づいてリソースを割り当てるため、最適な技術タイプを決定するとき、アプリケーションタイプおよびデータ速度を含むその他のパラメータを単独でまたは対称性と組み合わせて評価することもできる。例えば、要求されたコネクションが、リアルタイム送信を必要とする音声アプリケーション用のものである場合、コネクションはＦＤＤ  ＲＮＣ２０８を使用して提供される方が好ましい。同様に、リアルタイム送信を必要としないデータアプリケーション用のものである場合、コネクションはＴＤＤ  ＲＮＣ２０４を使用して提供される方が好ましい。一般に、トラフィックが非常に非対称的であり、高いデータ速度を有するならば、ＴＤＤの方が好ましい。トラフィックが非常に対称的であり、かなり低いデータ速度を有するならば、ＦＤＤの方が好ましい。その中間のものは、状況に応じて、ＴＤＤまたはＦＤＤのどちらかで送信されることができる。例えば、ＴＤＤセルが密集している場合、その他のパラメータに関わらず、ＲＡＢリクエストをＦＤＤに割り当てる方が望ましい。
【００２３】
この実施形態では、ＲＡＢリクエストは、ＴＤＤ  ＲＮＣ２０４またはＦＤＤ  ＲＮＣ２０８のどちらかを介して発行されることができることに留意されたい。どちらの場合でも、リクエストを受信したＲＮＣは、リソース割り当てに関する決定を下し、必要な場合は、リソースが適切なタイプのＲＮＣによって配分されるように、適切に別のＲＮＣタイプにＲＡＢリクエストを転送する。例えば、ＴＤＤ  ＲＮＣ２０４がＲＡＢリクエストを受信し、リクエストはＦＤＤタイプの技術を使用して処理されるべきであると決定した場合、ＴＤＤ  ＲＮＣ２０４は、そのリクエストをＩｕｒインターフェースを介してＦＤＤ  ＲＮＣ２０８に転送する。その後、ＦＤＤ  ＲＮＣ２０８は、そのリクエストを通常の方式で処理する。
【００２４】
今度は図３を参照すると、本発明の別の実施形態における、統合ＴＤＤ−ＦＤＤ  ＲＮＣ３０４が提供されている。統合ＴＤＤ−ＦＤＤ  ＲＮＣ３０４は、ＴＤＤ  ＲＮＣとＦＤＤ  ＲＮＣの従来の機能を統合する。したがって、この実施形態では、ＴＤＤ−ＦＤＤセレクタが１つだけ提供される。ＴＤＤ−ＦＤＤセレクタ８０６は、上で説明したように動作し、受信ＲＡＢリクエストはＴＤＤモードで処理されるべきか、それともＦＤＤモードで処理されるべきかを決定する。上で説明したように、ＴＤＤ−ＦＤＤセレクタは、個々のＲＡＢリクエストにとってどのモードが適切かを決定するとき、対称性、データ速度、アプリケーションタイプ、リソース利用可能性、およびその他の任意の関連パラメータを評価することができる。例えば、ＷＴＲＵ３２０および３２２は交わったカバレージエリア３２４に存在するので、ＷＴＲＵ３２０および３２２には、必要に応じてＴＤＤモードまたはＦＤＤモードのどちらかでリソースを割り当てることができる。
【００２５】
今度は図４を参照すると、本発明による、システムリソースを割り当てるための方法４００が示されている。方法４００は、無線アクセスベアラ（ＲＡＢ）リクエストが受信されるステップ４０２において開始する。リクエストは、ＴＤＤ  ＲＮＣまたはＦＤＤ  ＲＮＣのどちらかによって受信されることができ、統合ＴＤＤ−ＦＤＤ  ＲＮＣが提供される場合は、リクエストは、ＴＤＤモードまたはＦＤＤモードのどちらかで受信されることができる。次にステップ４０４において、受信リクエストに関するパラメータが評価される。上で説明したように、パラメータは、受信ＲＡＢに関する情報を提供する任意のパラメータとすることができる。一般に、評価されると好ましいパラメータとして、対称性、データ速度、およびアプリケーションタイプを挙げることができる。
【００２６】
ステップ４０６において、ステップ４０４で評価されたパラメータに基づいて、ＴＤＤタイプのセル内とＦＤＤタイプのセル内（すなわちＴＤＤモードとＦＤＤモード）のどちらで要求されたサービスを処理した方が好ましいかが決定される。先に説明したように、高いデータ速度の非対称コネクションはＴＤＤ（すなわちＴＤＤセル内）で処理した方が好ましく、低いデータ速度の対称コネクションはＦＤＤ（すなわちＦＤＤセル内）で処理した方が好ましい。
【００２７】
要求されたサービスはＴＤＤセル内で処理された方が好ましいと決定された場合、方法４００はステップ４０６からステップ４０８に進む。ステップ４０８において、ＲＡＢを必要とするＷＴＲＵがＴＤＤセル内に存在するかどうかが決定される。すなわち、ステップ４０６でＴＤＤの方が好ましいと決定されたが、ステップ４０８ではＴＤＤサービスが実際に現在利用可能であるかどうかを確認する。例えば、ＴＤＤセル内で動作するＷＴＲＵによって受信ＲＡＢリクエストが発行され、かつリクエストはＴＤＤセル内で処理されるべきであると決定された場合、ＴＤＤサービスは明らかに利用可能である。しかし、ＦＤＤセル内で動作するＷＴＲＵによって受信ＲＡＢリクエストが発行され、かつリクエストはＴＤＤセル内で処理されるべきであると決定された場合、本発明は、ＷＴＲＵをＦＤＤからＴＤＤに受け渡す前に、ＴＤＤサービスも利用可能であることを確認する。したがって、ステップ４０８でＷＴＲＵがＴＤＤセル内に存在すると決定された場合、ステップ４１０において、要求されたサービスがＴＤＤセル内で提供される。しかし、ＷＴＲＵがＴＤＤセル内に存在しない（すなわちＴＤＤサービスは利用可能でない）と決定された場合、要求されたサービスは、ＦＤＤセル内でＷＴＲＵに提供される（ステップ４１４）。この状況では、ＷＴＲＵは好ましいセル内で（すなわちＴＤＤセル内で）サービスを受けられないが、ＲＡＢが要求されたときにＷＴＲＵが動作していたシステムであるＦＤＤで、要求したサービスを提供されることに留意されたい。
【００２８】
上と同様に、ステップ４０６において、要求されたサービスはＦＤＤセル内で処理された方が好ましいと決定された場合、方法４００はステップ４０６からステップ４１２に進む。ステップ４１２において、ＲＡＢを必要とするＷＴＲＵがＦＤＤセル内に存在するかどうかが決定される。すなわち、ステップ４０８でＦＤＤの方が好ましいと決定されたが、ステップ４１２ではＦＤＤサービスが実際に現在利用可能であるかどうかを確認する。例えば、ＦＤＤセル内で動作するＷＴＲＵによって受信ＲＡＢリクエストが発行され、かつリクエストはＦＤＤセル内で処理されるべきであると決定された場合、ＦＤＤサービスは明らかに利用可能である。しかし、ＴＤＤセル内で動作するＷＴＲＵによって受信ＲＡＢリクエストが発行され、かつリクエストはＦＤＤセル内で処理されるべきであると決定された場合、本発明は、ＷＴＲＵをＴＤＤからＦＤＤに受け渡す前に、ＦＤＤサービスも利用可能であることを確認する。したがって、ステップ４１２でＷＴＲＵがＦＤＤセル内に存在すると決定された場合、ステップ４１４において、要求されたサービスがＦＤＤセル内で提供される。しかし、ＷＴＲＵがＦＤＤセル内に存在しない（すなわちＴＤＤサービスは利用可能でない）と決定された場合、要求されたサービスは、ＴＤＤセル内でＷＴＲＵに提供される（ステップ４１０）。この状況では、ＷＴＲＵは好ましいセル内で（すなわちＦＤＤセル内で）サービスを受けられないが、ＲＡＢが要求されたときにＷＴＲＵが動作していたシステムであるＴＤＤで、要求したサービスを提供されることに留意されたい。
【００２９】
上で述べたように、サービスが特定のタイプのセル内でＷＴＲＵに提供されると、そのセルは、そのＷＴＲＵに関して好ましいセルかまたは好ましくないセルかのどちらかである。したがって、要求されたサービスが提供されると、方法４００はステップ４１０または４１４からステップ４１６に進む。ステップ４１６において、何か最適化を実行できるかどうかを決定するため、確立されたコネクションに関するパラメータが評価される。例えば、ＷＴＲＵはＴＤＤセルに割り当てられたが、ＦＤＤセルの方が好ましいと決定されたサービスをそれ以前に要求していた場合、ＷＴＲＵがＦＤＤセルに移動したかどうか、または別の理由でＦＤＤサービスが利用可能になったかどうかを決定するため、ＷＴＲＵの位置を監視することができる。ステップ４１６では、ＷＴＲＵが現在動作しているセルのタイプがまだＷＴＲＵの好ましいセルかどうかを決定するため、対称性（すなわちコネクションの対称ステータス）、データ速度、アプリケーションタイプ、および／またはその他の任意の関連パラメータに関して、既存のコネクションを評価することもできる。すなわち、最初の評価ではＴＤＤセルの方が好ましいという決定に達したが、状況または使用法が変化した結果、ＦＤＤセルの方が好ましくなることもある。ステップ４１６で行われた評価に基づいて、何らかのタイプの最適化を実行する（すなわち例えばＷＴＲＵを一方のタイプのセルから別のタイプに移す）ことが可能ならば、方法４００はステップ４１８からステップ４２０に進み、現在のセル配分を必要に応じて再配分する。再配分が完了すると、さらなる最適化を探すため、方法４００はステップ４１６に戻ることができる。ステップ４１６における評価の結果、現在は最適化が可能でないならば、方法４００はステップ４１６に直接戻り、何か可能な最適化を見つけるため、既存のコネクションの監視および評価を続行することができる。
【００３０】
今度は図５を参照すると、本発明の別の実施形態が示されている。この実施形態では、ＴＤＤ  ＲＮＣとＦＤＤ  ＲＮＣが提供されることができるが、コアネットワークへのＩｕコネクションは１つしか必要でない。Ｉｕコネクションは、コアネットワークと、システム内で優勢な技術タイプであるＲＮＣタイプ（すなわちＴＤＤまたはＦＤＤのどちらか）に属するＲＮＣとの間に提供される。すなわち、システムによって提供されるカバレージの大部分をＴＤＤとすることができ、その場合、ＴＤＤが優勢なシステムタイプであり、ＩｕコネクションはコアネットワークとＴＤＤ  ＲＮＣとの間に提供される。本発明を説明する目的で、図６に示されたシステム５００は、ＦＤＤが優勢な技術タイプである広域のカバレージ５５０を有するＦＤＤシステムとする。ＦＤＤカバレージエリア５５０内には、より高いデータ速度が利用可能な複数のＴＤＤホットスポット５５２、５５４、５５６、５５８が存在する。
【００３１】
システム５００内では、すべてのコネクションは、ＦＤＤ  ＲＮＣ５０８によって確立され、終了されるので、コアネットワーク５０２にはＩｕコネクションが１つ提供されるだけでよい。したがって、すべてのＲＡＢリクエストは、ＦＤＤ  ＲＮＣ５０８によって受信され、上で説明したように、ＴＤＤ−ＦＤＤセレクタ５１０によって評価される。ある特定のリクエストをＴＤＤで処理すべきであるとセレクタ５１０が決定し、かつＴＤＤサービスが利用可能である（例えばＷＴＲＵ５２４）場合、コネクションはＴＤＤ  ＲＮＣ５０４に転送され、システム５００のＴＤＤ部分内（例えばＲＮＣ５０４、基地局５７０、５７２）で処理される。すなわち、ＷＴＲＵ５２４がシステム５００のＴＤＤ部分内で動作している間は、通常のＴＤＤ無線リソース管理を使用することができる。同様に、ＦＤＤサービスの方が好ましい場合、またはＦＤＤサービスが利用可能な唯一のサービスである場合、通常のＦＤＤ無線リソース管理を使用することができる。
【００３２】
上述したように、すべてのトラフィック（ＴＤＤおよびＦＤＤ）を、ＦＤＤ  ＲＮＣ５０８を介して開始し、また終了するため、好ましくは追加機能がＦＤＤ  ＲＮＣ５０８に提供される。好ましい一実施形態では、ＦＤＤ  ＲＮＣ５０８は、図６に示されるように構成される。ＦＤＤ  ＲＮＣ５０８は、ＦＤＤ  ＲＲＭ６０４を含み、通常通りＩｕプロトコル６０２、ＦＤＤ  Ｉｕｂプロトコル６０６、およびＦＤＤ  Ｉｕｒプロトコル６１０を実行するように構成される。さらに、ＦＤＤ  ＲＮＣ５０８は、ＴＤＤサービス無線ネットワーク制御装置（Ｓ−ＲＮＣ）無線リソースマネージャ（ＲＲＭ）６０８を含み、ＴＤＤ  Ｉｕｒプロトコル６１０を実行するように構成される。ＦＤＤ  ＲＮＣ５０８に追加される追加機能（すなわちＴＤＤ  ＳＲＮＣ  ＲＲＭ６０８およびＴＤＤ  Ｉｕｒプロトコル６１０）は、典型的なＦＤＤ  ＲＮＣですでに実行されている機能と類似しており、例えばソフトウェアアップグレードとして追加することができる。ＴＤＤ  ＲＮＣ５０４は好ましくは、制御ＲＮＣ（Ｃ−ＲＮＣ）  ＴＤＤ  ＲＲＭ６１２を含むように構成され、さらに通常通りＴＤＤ  Ｉｕｂプロトコル６１４、およびＴＤＤ  Ｉｕｒプロトコル６１３をサポートするように構成される。
【００３３】
ＦＤＤ  ＲＮＣ５０８に示されるようにＲＮＣを構成することで、ＴＤＤ  ＲＮＣ５０４の構成をあまり複雑でなくすることができ、したがってより容易かつより安価に配備することができる。すなわち、コアネットワーク５０２とＦＤＤ  ＲＮＣ５０８の間にＩｕコネクションを１つだけ有し、それによってＴＤＤ  ＲＮＣ５０４がＩｕプロトコルをサポートする必要をなくすことで、ＴＤＤネットワークをより広域なＦＤＤネットワーク内に速やかに配備できるようになる。この実施形態では、ＴＤＤ  ＲＮＣ５０４がＳ−ＲＮＣモードになることは決してなく、したがってＳ−ＲＮＣの標準機能をサポートする必要もない。これは、上で述べたように、システム５００内で動作するＷＴＲＵは、呼の接続および切断時には常にＦＤＤ  ＲＮＣ５０８にアクセスするよう強制されるからである。すなわち、ブロードキャストおよびアクセス制御チャネルは、ＦＤＤ  ＲＮＣ５０８においてのみ確立され、したがって、ＲＡＢがＴＤＤ−ＦＤＤセレクタによってＴＤＤに割り当てられた場合のみ、ＷＴＲＵ５２４などのＷＴＲＵは、システム５００のＴＤＤ部分に入ることができる。システム５００のＴＤＤ部分に割り当てられると、ＷＴＲＵ５２４は、通常通りＴＤＤカバレージエリア内で動作し、ＴＤＤセル間でハンドオーバされ、必要に応じてＦＤＤ  ＲＮＣ５０８に戻される。ＴＤＤセル間でのハンドオーバの決定は、標準的なＴＤＤ機能に従って処理されるが、ＷＴＲＵをＦＤＤ  ＲＮＣエリアに戻すべきかどうかの決定は、好ましくはＴＤＤ−ＦＤＤセレクタ５１０によって決定される。
【００３４】
図７は、本発明の代替実施形態による、ＴＤＤ−ＦＤＤセレクタ７０２を含むＲＮＣ７００のブロック図である。ＲＮＣ７００は、ＴＤＤモードとＦＤＤモードの間の切り替えを可能にする。ＲＮＣ７００は好ましくは、ＴＤＤおよびＦＤＤモード両方の通信のための無線リソース管理を実行できるように、ＦＤＤ  ＲＲＭ７０８とＴＤＤ  ＲＲＭ７１０の両方を含む。
【００３５】
ＴＤＤ−ＦＤＤセレクタ７０２は、ノードＢまたはその他の任意のＲＮＣ機能エンティティなどの別のエンティティに含まれることができる。ＲＮＣ７００は、単独型のＲＮＣエンティティであることも、または汎用パケット無線サービス提供ノード（ＧＳＮ：Ｇｅｎｅｒａｌ  Ｐａｃｋｅｔ  Ｒａｄｉｏ  Ｓｅｒｖｉｃｅ  Ｓｅｒｖｉｎｇ  Ｎｏｄｅ）／ＲＮＣまたはＲＮＣ／ノードＢなど、実装機能中にＲＮＣ機能を含む組合せ装置であることもできる。
【００３６】
ＴＤＤ／ＦＤＤセレクタ７０２は、ハンドオーバユニット７０４と、ポリシーサーバ７０６とを含む。ハンドオーバユニット７０４は、ポリシーサーバ７０６の出力に従って、ＴＤＤ−ＦＤＤハンドオーバおよびＦＤＤ−ＴＤＤハンドオーバを実行する。
【００３７】
ポリシーサーバ７０６は、１つまたは複数のポリシーに関する入力を受信し、適切な通信モードに関する決定を下す。１つまたは複数のポリシーが、ＦＤＤ／ＴＤＤハンドオーバを開始するために定義される。典型的なポリシーカテゴリとして、１）サービス品質（ＱｏＳ）、２）サービス、３）管理、および４）挙動を挙げることができるが、必要に応じて任意の追加のカテゴリを含むこともできる。ＱｏＳポリシーは、電力または品質閾値などのＱｏＳ条件を定義する。サービスポリシーは、データ速度非対称性、またはリアルタイム（ＲＴ）サービス（例えば音声通話）対非リアルタイム（ＮＲＴ）サービス（例えばウェブブラウジング）など、サービス特性条件を定義する。管理ポリシーは、運用、管理、および保守（ＯＡ＆Ｍ）条件を定義する。これは、負荷平衡目的に利用されるＲＴポリシー、または保守に関係するＮＲＴ面を含む。挙動ポリシーは、ユーザ位置または速度などの１つまたは複数のユーザ挙動条件を定義する。
【００３８】
ポリシーは、システム構成の一部として定義され、独立であっても、相互依存していてもよい。例えば、管理ポリシーは、ＱｏＳまたはサービスポリシーより高い優先度をもつことができる。各ポリシーに関する関連入力は、ポリシーサーバに入力される。ポリシーサーバへの入力は、汎用ＲＮＣ制御ロジック、ＲＲＭ機能によって、またはＯＡＭ機能などの外部エンティティによって提供される。ポリシーは、必要に応じて定義され、またはその他の方法で構成されることができ、それによって、必要に応じてＦＤＤモードまたはＴＤＤモードのどちらかでサービスリクエストが処理されることを可能にする。
【００３９】
新しい呼またはハンドオーバのリクエストの受信時、ＴＤＤ−ＦＤＤセレクタ７０２は、適切な通信モードに関する決定を下すようポリシーサーバに要求する。ＴＤＤ−ＦＤＤセレクタ７０２は、ポリシーサーバによって下された決定に従って、適切な通信モードの選択、またはＦＤＤモードとＴＤＤモードの間の遷移を実行する。
【００４０】
図８は、本発明による、ＴＤＤモードとＦＤＤモードの間のハンドオーバのためのプロセス８００のフローチャートである。最初に、ＷＴＲＵが、ある特定の通信モードで通信を確立する（ステップ８０２）。次にＷＴＲＵは、ウェブブランジングなどある特定のサービスを要求する（ステップ８０４）。次にＲＮＣ７００が、通信モードの遷移が行われるべきであるように、複数の所定のポリシーのうち１つまたは複数がサービスリクエストについて満たされているかどうかを決定する（ステップ８０６）。１つまたは複数のポリシー（ＱｏＳ、位置、速度など）が満たされている場合、ポリシーサーバ７０６は、サービスが認められるべき通信モードを指示し、ＲＮＣ７００は、その指示に従って通信モードの遷移を実行する（ステップ８０８）。ポリシーが満たされていない場合、ＲＮＣ７００は、現在の通信モードを維持する（８１０）。
【００４１】
例えば、ＷＴＲＵがＴＤＤモードにある時に音声呼が到着した場合、各ポリシーの関連入力がポリシーサーバに入力される。ＴＤＤからＦＤＤへのハンドオーバについて１つまたは複数のポリシー条件が満たされている場合、ポリシーサーバ７０６は、ＦＤＤモードへの遷移が行われるべきであることを指示し、ＲＮＣ７００は、ＦＤＤモードへの遷移を実行する。
【００４２】
本発明の説明では各ＲＮＣタイプ（すなわちＦＤＤおよびＴＤＤ）につき１つのＲＮＣしか示されていないが、任意の数のＴＤＤ  ＲＮＣおよびＦＤＤ  ＲＮＣを設けることができることに留意されたい。そのような構成では、同じタイプのＲＮＣは、それぞれのＩｕｒプロトコルを使用して通常通り通信する。本明細書で説明された様々な機能およびプロトコルは、必要に応じて任意の数のプロセッサを使用して、個別にまたは集団で実行することができることも留意されたい。
【００４３】
本発明は、必要に応じて、任意のタイプの時分割複信（ＴＤＤ）技術または任意のタイプの周波数分割複信（ＦＤＤ）技術を利用する任意のタイプの無線通信システムにおいて実施することができる点に留意することが重要である。例えば、本発明は、ＵＭＴＳ−ＴＤＤ、ＵＭＴＳ−ＦＤＤ、ＴＤＭＡ、ＴＤＳＣＤＭＡ、またはその他の任意の類似のタイプの無線通信システムにおいて実施することができる。さらに、様々な実施形態に関して本発明が説明されたが、添付の特許請求の範囲で概要が示される本発明の範囲内にあるその他の変形が当業者には明らかであろう。
【図面の簡単な説明】
【００４４】
【図１】典型的な無線通信システムの図である。
【図２】ＴＤＤおよびＦＤＤタイプの無線ネットワーク制御装置（ＲＮＣ）にＴＤＤ−ＦＤＤセレクタが備えられた本発明の一実施形態を示す図である。
【図３】統合ＴＤＤ／ＦＤＤ  ＲＮＣにＴＤＤ−ＦＤＤセレクタが備えられた本発明の一実施形態を示す図である。
【図４】本発明による、無線リソースを割り当てる方法の図である。
【図５】ＴＤＤおよびＦＤＤタイプサービスがコアネットワークとＦＤＤ  ＲＮＣの間の単一のＩｕコネクションによって提供されることができる本発明の一実施形態を示す図である。
【図６】図５に示されたＲＮＣの構成を示す図である。
【図７】ポリシーサーバを有するＴＤＤ−ＦＤＤセレクタを含むＲＮＣのブロック図である。
【図８】ＲＮＣがポリシーサーバを有するＴＤＤ−ＦＤＤセレクタを備えて構成されている、通信モードの間のハンドオーバのためのプロセスのフローチャートである。
【図１】
2007507180.tif 000003
【図２】
2007507180.tif 000004
【図３】
2007507180.tif 000005
【図４】
2007507180.tif 000006
【図５】
2007507180.tif 000007
【図６】
2007507180.tif 000008
【図７】
2007507180.tif 000009
【図８】
2007507180.tif 000010
【手続補正書】
【提出日】平成17年3月15日(2005.3.15)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
無線送受信ユニット（ＷＴＲＵ）を含む無線通信システムにおいて時分割複信（ＴＤＤ）モードと周波数分割複信（ＦＤＤ）モードの間のハンドオーバのための装置であって、
サービスリクエストについて複数のポリシー関連入力に基づいて適切な通信モードを決定するためのポリシーサーバと、
ここで、前記ポリシー関連入力は、汎用無線ネットワーク制御装置（ＲＮＣ）制御ロジック、無線リソース管理機能、および外部エンティティの少なくとも１つによって提供され、
前記ポリシーサーバの出力に従ってＴＤＤモードとＦＤＤモードの間で通信モードを変更するためのハンドオーバユニットと
を具えたことを特徴とする装置。
【請求項２】
前記ポリシー関連入力は、前記サービスリクエストにとって必要なサービス品質に関する入力と、前記サービスリクエストに固有の条件に関する入力と、前記無線通信システムの管理に関する入力と、前記ＷＴＲＵの挙動に関する入力とを含むことを特徴とする請求項１記載の装置。
【請求項３】
１つまたは複数のポリシー関連入力が、その他のポリシー関連入力よりも高い優先度を有することを特徴とする請求項２記載の装置。
【請求項４】
独立型ＲＮＣに含まれることを特徴とする請求項１記載の装置。
【請求項５】
ＦＤＤモードおよびＴＤＤモード通信の両方のために構成される無線リソースマネージャをさらに備えることを特徴とする請求項１記載の装置。
【請求項６】
無線送受信ユニット（ＷＴＲＵ）を含む無線通信システムにおいて時分割複信（ＴＤＤ）モードと周波数分割複信（ＦＤＤ）モードの間のハンドオーバのための方法であって、
ＴＤＤモードまたはＦＤＤモードのどちらかでコネクションを確立するステップと、
サービスリクエストを受信するステップと、
通信モードを遷移させるように、前記サービスリクエストについて１つまたは複数のポリシーが満たされているかどうかを決定するステップと、
ここで、前記１つまたは複数のポリシーは、汎用無線ネットワーク制御装置（ＲＮＣ）制御ロジック、無線リソース管理機能、および外部エンティティの少なくとも１つによって提供され、
前記決定に従って現在のモードから別のモードへの遷移を実行するステップと
を具えたことを特徴とする方法。
【請求項７】
ポリシー関連入力が、前記サービスリクエストにとって必要なサービス品質に関する入力と、前記サービスリクエストに固有の条件に関する入力と、前記無線通信システムの管理に関する入力と、前記ＷＴＲＵの挙動に関する入力とを含むことを特徴とする請求項６記載の方法。
【国際調査報告】
2007507180.tif 000011