特許 6843833 ＳＦＮ間ノードメッセージング

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6843833

(24)【登録日】2021年2月26日

(45)【発行日】2021年3月17日

(54)【発明の名称】ＳＦＮ間ノードメッセージング

(51)【国際特許分類】

   H04W 28/16 20090101AFI20210308BHJP

   H04W 88/12 20090101ALI20210308BHJP

   H04W 72/12 20090101ALI20210308BHJP

   H04W 92/20 20090101ALI20210308BHJP

   H04W 88/08 20090101ALI20210308BHJP

【ＦＩ】

   H04W28/16

   H04W88/12

   H04W72/12 130

   H04W92/20

   H04W88/08

【請求項の数】8

【全頁数】17

(21)【出願番号】特願2018-505668(P2018-505668)

(86)(22)【出願日】2016年8月4日

(65)【公表番号】特表2018-528669(P2018-528669A)

(43)【公表日】2018年9月27日

(86)【国際出願番号】EP2016068675

(87)【国際公開番号】WO2017021502

(87)【国際公開日】20170209

【審査請求日】2019年7月18日

(31)【優先権主張番号】15179851.9

(32)【優先日】2015年8月5日

(33)【優先権主張国】EP

(73)【特許権者】

【識別番号】508012091

【氏名又は名称】アイピーコム ゲゼルシャフト ミット ベシュレンクテル ハフツング ウント コンパニー コマンディートゲゼルシャフト

【氏名又は名称原語表記】ＩＰＣｏｍ ＧｍｂＨ ＆ Ｃｏ． ＫＧ

(74)【代理人】

【識別番号】100114890

【弁理士】

【氏名又は名称】アインゼル・フェリックス＝ラインハルト

(74)【代理人】

【識別番号】100098501

【弁理士】

【氏名又は名称】森田 拓

(74)【代理人】

【識別番号】100116403

【弁理士】

【氏名又は名称】前川 純一

(74)【代理人】

【識別番号】100135633

【弁理士】

【氏名又は名称】二宮 浩康

(74)【代理人】

【識別番号】100162880

【弁理士】

【氏名又は名称】上島 類

(72)【発明者】

【氏名】アンドレアス シュミット

(72)【発明者】

【氏名】アヒム ルフト

(72)【発明者】

【氏名】マーティン ハンス

(72)【発明者】

【氏名】マイク ビーナス

【審査官】 町田 舞

(56)【参考文献】

【文献】 国際公開第２０１０／０５０３０２（ＷＯ，Ａ１）

【文献】 国際公開第２０１０／０５０３０３（ＷＯ，Ａ１）

【文献】 中国特許出願公開第１０４２７０７２５（ＣＮ，Ａ）

【文献】 RAN WG3，LS on MBMS Improvement for HSPA Evolution，3GPP TSG-RAN WG3#62 R3-083468，２００８年１１月１７日

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｂ ７／２４− ７／２６

Ｈ０４Ｗ ４／００−９９／００

３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１−４

ＳＡ ＷＧ１−４

ＣＴ ＷＧ１、４

(57)【特許請求の範囲】

【請求項1】

資源制御装置の機能を第１のノードから第２のノードに転送する方法であって、前記資源制御装置の機能は、ダウンリンク・データパケットを複数の送信点に同期転送のために分散する機能を含み、前記第１のノードと第２のノードは、単一周波数ネットワーク（２２、２４）内で、複数の送信点（２０）を形成し、
前記方法は、前記第１のノードに割り当てられた資源制御装置または前記複数の送信点（２０）を管理する中央管理装置によって実行され、
前記第１のノードに割り当てられた資源制御装置で一組の資源制御情報を少なくとも１つの候補ノードから受信するステップと、
前記資源制御情報を用いて、前記少なくとも１つの候補ノードが前記第２のノードである適合性を決定するステップと、
前記資源制御装置の機能を、前記第１のノードから前記第２のノードに転送するのを開始するステップと、
前記資源制御装置の機能を、前記第１のノードから前記第２のノードに転送するのを開始する前記ステップの後に、前記第１のノードを停止する、
を含む方法。

【請求項2】

前記資源制御情報を前記少なくとも１つの候補ノードから受信する前記ステップの前に、
前記少なくとも１つの候補ノードを選択するステップと、
前記少なくとも１つの候補ノードを起動するステップと、
前記少なくとも１つの候補ノードに前記資源制御情報を要求するステップと、
のうちの少なくとも１つを実行する、
請求項１に記載の方法。

【請求項3】

前記第２のノードとしての候補ノードの前記適合性を決定する前記ステップは、リストの組からの少なくとも一組の資源制御情報を分析するステップを含み、前記リストの組は、
前記第１のノードによって推定される一組の情報と、
少なくとも１つの候補ノードによって提供される一組の情報と、
を備える、
請求項１または２に記載の方法。

【請求項4】

前記資源制御情報は、リストから選択される情報の少なくとも１つの項目を備える一組の情報であり、前記リストは、
アップリンク測定と、
ノード能力と、
ノード構成の詳細と、
活動状態と、
無線資源利用と、
処理負荷と、
を備える、
請求項１に記載の方法。

【請求項5】

前記資源制御装置の機能の一部のみが、前記第１のノードから前記第２のノードに転送される、
請求項１から４のいずれかに記載の方法。

【請求項6】

前記第１のノードは、送信点の第１のクラスタに関連付けられ、前記第２のノードは、送信点の第２のクラスタに関連付けられている、
請求項１から５のいずれかに記載の方法。

【請求項7】

エアインタフェース上の前記データパケットの送信時間は、前記資源制御装置からの前記データパケットの分散に結び付けられ、前記第１のノードは、データパケットの分散を停止し、前記第２のノードは、選択された時点でデータパケットの分散を開始するような同期方法で、前記データパケットは、資源制御装置から送信点に分散される、
請求項１から６のいずれかに記載の方法。

【請求項8】

前記データパケットは、資源制御装置から送信点に非同期方法で分散され、
切り替え時点は、前記第１のノードと前記第２のノードとの間で一致し、
前記第２のノードは、前記切り替え時点後にのみデータパケットを分散し、前記第１のノードは、前記切り替え時点後にはデータパケットを分散しない、
請求項１から６のいずれかに記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、２０１５年２月１日に出願された「Ｍｅｔｈｏｄ ａｎｄ Ｄｅｖｉｃｅ ｆｏｒ Ｃｏｎｆｉｇｕｒｉｎｇ ａ Ｓｉｎｇｌｅ Ｆｒｅｑｕｅｎｃｙ Ｎｅｔｗｏｒｋ」という名称の欧州特許出願第１５１５４７０５．６号（ＥＰ１５１５４７０５．６）に記載されている構成のさらなる発展であり、前記出願内容は、本願明細書に参照によってすべての目的のために組み込まれる。

【0002】

本発明は、単一周波数ネットワークまたはネットワーク・クラスタの動作に関するものであり、単一周波数ネットワークまたはネットワーク・クラスタでは、各々が１つまたは複数の無線セルを提供する複数の基地局は、協調して動作するので、ユーザ機器が複数のセルを横断するとき、ハンドオーバは必要とされない。

【背景技術】

【0003】

欧州特許出願第１５１５４７０５．６号（ＥＰ１５１５４７０５．６）には、移動端末の位置および／または軌跡についての知識に基づいて、単一周波数ネットワーク（ＳＦＮ）を動作するための方法が記載されている。簡潔には、中央に位置してもよいし、または、通信システムの全体にわたるさまざまな実体内に割り振られてもよい資源制御装置（ＲＣＵ）の機能が定義される。代替例のローカル・スケジューリングを有する資源プールでは、（ＳＦＮクラスタ間の干渉の軽減のための）第１の干渉軽減機能を中央ＲＣＵ実体に割り当てるとともに、（ＳＦＮクラスタ内の干渉の軽減のための）第２の干渉軽減機能をローカル（またはクラスタに特定の）ＲＣＵ実体に割り当てることが提案された。さらに、ローカルＲＣＵは、無線通信システムのエアインタフェース技術のＭＡＣ層のスケジューリング機能を備えてもよい、または、制御してもよいことが記載されていた。この概念において、ローカルＲＣＵは、そのそれぞれのＳＦＮクラスタ内のすべての含まれる送信点（ｅＮＢまたはＲＲＨ）に、いつデータのどの部分を同期方法で送信すべきかを「伝え」なければならない。

【0004】

米国特許出願公開第２００９／０２６４１２５号明細書（ＵＳ２００９／０２６４１２５Ａ１）には、フェムトセル動作を提供するためのハンドヘルド装置を組み込む通信システムが記載されている。ハンドヘルド装置は、複数の無線インタフェースをユーザ機器に提供する。フェムトセルは、通常のセルラー基地局と同様に動作する。複数のハンドヘルド装置が所定のエリア内で動作する場合、フェムトセル・アクセス・ポイント機能は、複数のハンドヘルド装置の間で再分散されてもよい。

【0005】

３ＧＰＰ ＴＳ ３６．３２１によれば、ＬＴＥ用のＭＡＣ（媒体アクセス制御）プロトコル層の主要なサービスおよび機能は、以下を含む。
ａ）論理チャネルと転送チャネルとの間のマッピング
ｂ）転送チャネル上の物理層へ送出される／物理層から送出される、転送ブロック（ＴＢ）につながる１つまたは複数の論理チャネルに帰属するＭＡＣ ＳＤＵの多重化／非多重化
ｃ）スケジューリング情報の報告
ｄ）１つのＵＥの論理チャネル間の優先処理
ｅ）ダイナミックスケジューリングを用いた、複数のＵＥ間の優先処理
ｆ）転送形式選択
ｇ）パディング（ｐａｄｄｉｎｇ）および他の機能

【0006】

本発明では、ＭＡＣ機能のスケジューリングの態様ｃ）およびｅ）がＳＦＮクラスタ内の干渉を効率的に軽減するために不可欠であるので、特に重要である。

【0007】

図１、図２、図３Ａおよび図３Ｂには、従来技術によるセルラー通信ネットワークの一般的アーキテクチャが表される。図１は、ＬＴＥ通信システム１０の一例のネットワーク・アーキテクチャを示し、ＬＴＥ通信システム１０では、送信点２０は、複数のクラスタに分割され、図示例では２つのクラスタ、すなわちクラスタＭ（２２）およびクラスタＮ（２４）に分割される。各クラスタは、それぞれの資源制御装置ＲＣＵ_Ｍ（２６）およびＲＣＵ_Ｎ（２８）によって制御される。次に、ＲＣＵは、クラスタ管理装置３０によって制御される。図１は、クラスタ管理装置３０と、コアネットワークの一部の移動管理実体ＭＭＥ（３４）と、の間の基盤インタフェース３２（ＬＴＥの場合には、これはＳ１インタフェースである）を示す。

【0008】

図２では、ネットワーク側の実際の送信点２０（アンテナまたはアンテナアレイ）は、基地局４０に位置する。図２は、基盤インタフェース３２およびエアインタフェース３６（ＬＴＥの場合には、これはＵｕ基準点である）を示す。基地局４０および移動端末４２の各々のためのエアインタフェースのためのプロトコル・スタック３８もまた示される。さまざまなＬＴＥプロトコル層の終端点は、基地局（ｅＮＢ）および移動端末（ＵＥ）内に存在する。

【0009】

図３Ａは、ＬＴＥ通信システムの一例のネットワーク・アーキテクチャを示し、ＬＴＥ通信システムは、送信点として機能するリモートラジオヘッド（ＲＲＨ）４４を有する。このＲＲＨ４４は、例えば方向性の無線技術またはファイバ・オプティクスを用いて基地局４６（ｅＮＢ）に接続され、一方、図３Ｂは、ＬＴＥ通信システムの一例のネットワーク・アーキテクチャを示し、ＬＴＥ通信システムは、仮想基地局（ｅＮＢ）のプール５０に接続されているリモートラジオヘッド（ＲＲＨ）４８を有する。図３Ａおよび図３Ｂでは、ネットワーク側の実際の送信点（アンテナまたはアンテナアレイ）は、リモートラジオヘッド（ＲＲＨ）によって表され、リモートラジオヘッド（ＲＲＨ）は、インタフェース１を用いて基地局（または基地局計算資源のプール）に接続され、インタフェース１は、無線、有線または光インタフェースでもよい。例えば、ＣＰＲＩ（Ｃｏｍｍｏｎ Ｐｕｂｌｉｃ Ｒａｄｉｏ Ｉｎｔｅｒｆａｃｅ）プロトコルが、インタフェース１に用いられてもよい。ＲＲＨは、現在の新しい分散基地局の最重要なサブシステムの１つになってきた。リモートラジオヘッドは、基地局のＲＦ回路、アナログデジタル・コンバータ、デジタルアナログ・コンバータ、アップ・コンバータ、ダウン・コンバータおよびアンテナを含む。ＲＲＨはまた、動作および管理処理能力および基地局の「残り」に接続する標準化されたインタフェースを有する。ＲＲＨは、基地局と比較して、ＭＩＭＯ動作を非常に容易に行い、基地局は、ＲＦ回路、Ａ／Ｄコンバータなどを含み、アナログインタフェースを介してアンテナに接続されている。ＲＲＨはまた、基地局の効率を増加し、ギャップカバレッジ問題のためのより容易な物理的な位置を容易にする。

【0010】

図３Ａおよび図３Ｂでは、エアインタフェースのためのプロトコル・スタックは、プロトコル・スタック６０、６２および６４として示される。ＬＴＥ物理層（ＰＨＹ）以外のさまざまなＬＴＥプロトコル層の終端点は、基地局（ｅＮＢ）および移動端末（ＵＥ）内に存在する。図２とは対照的に、ＬＴＥ ＰＨＹ層の少なくとも一部は、ＲＲＨ内で終端する。ＵＥの視点から見ると、ＰＨＹ層に対応するものは、ＲＲＨ内に位置するが、ＰＨＹより上の層に対応するものは、ｅＮＢ内に位置する。インタフェース１はベースバンド信号の交換のためにあり、一方、インタフェース２は、実際のエアインタフェース（アンテナ対アンテナ）であり、実際のエアインタフェースは、（以前の発明にて説明したような）資源網、変調およびＬＴＥ物理層の符号化方式を用いる。

【0011】

図３Ａでは、ＲＲＨは、現実の物理的な基地局に接続されているが、図３Ｂでは、ＲＲＨは、基地局計算資源のプール（「クラウドＲＡＮ」としても知られている）に接続されている。

【0012】

無線通信システム内の「ローカルＲＣＵ」の実体の意味がある位置決めが実際の配備シナリオに大きく依存する点に留意されたい。より詳しくは、それは、トポロジーのネットワーク構造およびＲＲＨまたはｅＮＢが送信点（ＴＰ）として用いられるか否かという問題に対する回答に依存する。さらに、それは、（図３Ａに示すように）現実の物理的なｅＮＢが配備されるのか、または、（図３Ｂに示すように、例えば、ｅＮＢ計算資源のプールによって提供される）仮想ｅＮＢが用いられるのか、に依存する。

【0013】

本発明の文脈では、ｅＮＢが現実（すなわち物理的なｅＮＢ）でもよいし、または、仮想ｅＮＢ（すなわち計算能力のプールによって提供されるｅＮＢ計算資源のインスタンス）でもよい点にさらに留意されたい。送信点（ＴＰ）は、リモートラジオヘッド（ＲＲＨ）でもよいし、「完全な」基地局でもよい。

【0014】

図４Ａ〜図４Ｃは、本発明のさらなる理解のために、本発明の実施に適している異なる周知のネットワーク・トポロジーの例を表す。送信点（ＴＰ）という用語は、ＲＲＨまたは現実の物理的なｅＮＢ（のアンテナまたはアンテナアレイ）を表してもよい。図４Ａは、「バス型」トポロジー・ネットワーク構造の一例を示し、図４Ｂは、「スター型」トポロジー・ネットワーク構造の一例を示し、図４Ｃは、「バス型」および「スター型」が混在したトポロジー・ネットワーク構造の一例を示す。

【発明の概要】

【課題を解決するための手段】

【0015】

本発明は、請求項１に従って、単一周波数ネットワーク内で制御機能を動作する資源制御装置を、第１のノードから第２のノードに転送する方法を提供する。

【0016】

本発明の方法の目的は、ＲＣＵ機能／ＲＣＵコンテクスト情報（ＳＦＮクラスタ内の干渉軽減のためのＭＡＣスケジューリング態様を含む）を、１つの実体から他の実体にシームレスに交換することを提供することである（対応するＳＦＮクラスタが移動、拡大または縮小するように）。

【0017】

ＲＣＵ機能を交換するプロセスは、少なくとも１つの候補ノードを選択するステップと、少なくとも１つの候補ノードを起動するステップと、情報を少なくとも１つの候補ノードから要求するステップと、一組の情報を少なくとも１つの候補ノードから受信するステップと、少なくとも１つの候補ノードから受信された一組の情報を評価するステップと、第１のノードによって推定される他の組の情報を評価するステップと、１つの候補ノードを第２のノードとして決定するステップと、ＲＣＵコンテクスト情報を、第１のノードから第２のノード（ターゲットノード）に転送するのを開始するステップと、ＲＣＵコンテクスト情報を、全体的または部分的に、第１のノードから第２のノード（ターゲットノード）に転送するステップと、第１のノードを停止するステップと、のうちの１つまたは複数を含んでもよい。ここでリストされるステップの順序は、任意に選択されており、すなわち、実生活配備では、ここで記載されているさまざまなステップは、それぞれのシナリオに従って、異なる順序で実行されてもよい。また、ここでリストされるすべてのプロセスステップが、実体間でのＲＣＵ機能の交換のために必要なわけではない。

【0018】

一実施形態では、ＲＣＵ機能の交換は、ＲＣＵコンテクスト情報の交換を備えてもよく、他の実施形態では、ＲＣＵコンテクスト情報の交換は、ＲＣＵ機能の交換を備えてもよい。

【0019】

本発明のさらなる態様は、従属請求項に従って提供される。

【0020】

以下、本発明の実施形態が、単に例として、添付の図面を参照して記載されている。

【図面の簡単な説明】

【0021】

【図1】クラスタに分割される単一周波数ネットワークの概略図である。

【図2】ＬＴＥ通信システムの一例のネットワーク・アーキテクチャを示す。

【図3A】リモートラジオヘッドを有するＬＴＥ通信システムの一例のネットワーク・アーキテクチャを示す。

【図3B】リモートラジオヘッドを有するＬＴＥ通信システムのさらなる例のネットワーク・アーキテクチャを示す。

【図4】図４Ａは、バス型ネットワーク構造を示し、図４Ｂは、スター型ネットワーク構造を示し、図４Ｃは、バス型およびスター型が複合したネットワーク構造を示す。

【図5】図５Ａは、バス型トポロジー・クラスタ内で実施される本発明の一実施形態を示し、図５Ｂは、スター型トポロジー・クラスタ内で実施される本発明の一実施形態を示す。

【図6】図６Ａは、バス型トポロジー内のローカルＲＣＵ間でのＲＣＵ機能の転送を示し、図６Ｂは、スター型トポロジー内のローカルＲＣＵ間でのＲＣＵ機能の転送を示す。

【図7】図７Ａは、バス型トポロジーを有するＳＦＮクラスタを示し、図７Ｂは、スター型トポロジーを有するＳＦＮクラスタを示す。

【図8】第１のｅＮＢから第２のｅＮＢへの転送を示す。

【図9】第１のメッセージ・シーケンス図を示す。

【図10】第２のメッセージ・シーケンス図を示す。

【発明を実施するための形態】

【0022】

図５Ａは、バス型トポロジーを有するＳＦＮクラスタＭ内でのＲＣＵ機能の転送を示し、ＲＣＵ機能は、１つのｅＮＢ（ｅＮＢ_ｍ）から第２のｅＮＢ（ｅＮＢ_ｍ＋２）に転送される。１つのｅＮＢから他のｅＮＢへの転送では、ローカル資源制御装置ＲＣＵの機能もまた転送される。

【0023】

ローカルＲＣＵ_Ｍは、転送前の資源制御装置を意味し、ローカルＲＣＵ_Ｍ＊は、転送後の資源制御装置を意味する。同様に、転送前の無線アクセスネットワーク（ＲＡＮ）とコアネットワーク（ＣＮ）との間の基盤インタフェースＳ１、および、転送後の無線アクセスネットワーク（ＲＡＮ）とコアネットワーク（ＣＮ）との間の基盤インタフェースＳ１^＊は、変化する。

【0024】

図５Ａから、ＲＣＵ機能が、２つのＳ１基準点を介して、または、ＳＦＮクラスタＭ内のｅＮＢを接続するバスを介して転送されてもよいことが分かる。

【0025】

図５Ｂから、ＲＣＵ機能が、２つのＳ１基準点を介して、または、ＳＦＮクラスタＮ内のｅＮＢ_ｎとｅＮＢ_ｎ＋２との間の直接接続を介して転送されてもよいことが分かる。図５Ｂに示すスター型トポロジーの場合には、スター型トポロジーは、ＲＣＵ機能の転送が成功した後、新たに形成される必要がある（すなわちｅＮＢ_ｎ＋２がＳＦＮクラスタＮのためのＲＣＵ機能を保つとき、ｅＮＢ_ｎとｅＮＢ_ｎ＋１との間の直接接続は中断され、ｅＮＢ_ｎ＋２とｅＮＢ_ｎ＋１との間の直接接続が確立される必要がありうる）。これは、実際の配備シナリオに依存し、すべての場合において可能なわけではない。

【0026】

本発明はまた、ローカルＲＣＵ機能の転送を、第１のＳＦＮクラスタの第１のｅＮＢから第２のＳＦＮクラスタの第２のｅＮＢに提供する（例えば、図６Ａに示すようにｅＮＢ_ｌからｅＮＢ_ｍに、または、図６Ｂに示すようにｅＮＢ_ｎからｅＮＢ_ｏに）。ローカルＲＣＵ_Ｌ／ＲＣＵ_Ｎは、転送前の資源制御装置を意味し、ローカルＲＣＵ_Ｍ／ＲＣＵ_Ｏは、転送後の資源制御装置を意味する。同様に、Ｓ１_Ｌ／Ｓ１_Ｎは、転送前の無線アクセスネットワーク（ＲＡＮ）とコアネットワーク（ＣＮ）との間の基盤インタフェースを意味し、Ｓ１_Ｍ／Ｓ１_Ｏは、転送後の無線アクセスネットワーク（ＲＡＮ）とコアネットワーク（ＣＮ）との間の基盤インタフェースを意味する。

【0027】

上述した例のように、図６Ａから、ＲＣＵ機能が、２つのＳ１基準点を介して、または、ＳＦＮクラスタＬとＳＦＮクラスタＭとを接続するバスを介して転送されてもよいことが分かる。

【0028】

図６Ｂから、ＲＣＵ機能が、２つのＳ１基準点を介してのみ転送されてもよいことが分かる。上述した例とは異なり、所定のスター型トポロジーのため、異なるＳＦＮクラスタ間に直接接続は存在しない。

【0029】

図７Ａおよび図７Ｂから、同じＳＦＮクラスタの第１のｅＮＢから第２のｅＮＢへの転送が、ＲＲＨ配備の性質のため必要ではないということが容易に分かる。

【0030】

任意の所定のＳＦＮクラスタ内のローカルＲＣＵ機能をホスト／提供するｅＮＢの能力および／または適合性は、ＲＣＵ機能の転送が開始される前に知られている必要がある。追加的または代替的に、（例えば、ｅＮＢによって提供されるエアインタフェース上の）資源割り当てについての情報、および／または、（例えば、ｅＮＢのハードウェア内の）処理負荷、および／または、現在の構成の詳細（例えば、ｅＮＢの帯域幅構成）、および／または、（例えば、ｅＮＢ内の電力節約モードに関連する）ローカル活動状態は、いくつかの配備シナリオでは知られている必要がある。

【0031】

それゆえ、ｅＮＢの能力および／または適合性を記載する情報のさまざまな部分は、集合的に資源制御情報と称され、第１の転送前に、ＲＣＵ機能をトリガする実体に提供される。このデータの提供は、例えば第１のノードによって（すなわち、ローカルＲＣＵ機能を特定のクラスタに現在提供しているｅＮＢによって）、または、中央に位置する管理装置（例えばＳＦＮクラスタ管理装置）によって要求または推定されてもよい。

【0032】

本発明のさらに他の態様は、ローカルＲＣＵ機能を、第１のＳＦＮクラスタを制御する第１の仮想ｅＮＢから、第２のＳＦＮクラスタを制御する第２の仮想ｅＮＢに伝播することである（例えば、図８に示すように、ｅＮＢ_ＭからｅＮＢ_Ｎに）。ローカルＲＣＵ_Ｍは、転送前にｅＮＢ_Ｍに割り当てられる資源制御装置を意味し、ローカルＲＣＵ_Ｎは、転送後にｅＮＢ_Ｎに割り当てられる資源制御装置を意味する。このシナリオでは、１つの仮想ｅＮＢから他の仮想ｅＮＢへのローカルＲＣＵ機能のハンドオーバは、「ｅＮＢプールの内部動作」であるので、コンテクスト情報の交換のための任意の外部インタフェースを必要としない。

【0033】

図８は、「バス」型トポロジーを有するＳＦＮクラスタＭおよび「スター」型トポロジーを有するＳＦＮクラスタＮを有する単に一例の配備トポロジーを示す。これは、いずれにせよ制限するものとして理解されるべきではない。他のシナリオでは、両方のＳＦＮクラスタが「バス型」トポロジーを有してもよいし、または、「スター型」トポロジーを有してもよい。また、多数の仮想ｅＮＢからなるｅＮＢプールと、多数の物理的なｅＮＢからなるサブシステムと、の間のＲＣＵコンテクスト情報の転送は、明確に本発明の範囲内に存在する。後者は、簡潔さのために本願明細書には示されない。

【0034】

図１に示すように、特定のクラスタに供する（サーブする）任意のローカルＲＣＵは、ＳＦＮクラスタ管理装置によって管理される。この管理装置は、（少なくとも１つの）ＳＦＮクラスタを定め、このＳＦＮクラスタは、ネットワークに広がり、特定のＳＦＮクラスタに接続されているローカルＲＣＵならびにユーザ／デバイスによって供される。

【0035】

ＳＦＮクラスタおよびＳＦＮクラスタによって供されるデバイスの概念は、地理的な位置、実際のＵＥの移動および／またはＵＥの予想される軌道ならびに他の態様を考慮し、他の態様は、
○ローカルＲＣＵ内の資源の利用可能性および需要
○必要な同期オーバーヘッド、すなわちＳＦＮ使用による資源の損失
○クラスタの予想される有効な時間、すなわち予想される保守オーバーヘッド
を含む。

【0036】

いったん確立されたＳＦＮクラスタは、（ローカルおよびグローバルな）ニーズに従って変化する、以下のパラメータを有するダイナミックな構造である。
○ＳＦＮクラスタによって供されるＵＥの数
○ＳＦＮクラスタを形成するＴＰ（ＲＲＨまたはｅＮＢ）
○ＳＦＮクラスタに供するように（中央）ＲＣＵによって管理される資源
○ローカルＲＣＵの機能を特定のＳＦＮクラスタのために実行する実体

【0037】

このリストとは対照的に、いくつかのパラメータは、中央管理機能と相互作用することなく、ローカルＲＣＵによってローカルに管理される。例は、中央に割り当てられた資源を用いるローカル資源管理およびクラスタのエネルギー効率を増加するための、ＴＰ（ＲＲＨ、ｅＮＢ）用のローカルパワーアップ／ダウンである。

【0038】

どの実体がローカルＲＣＵ機能を実行するのかという決定は、ＳＦＮクラスタ管理装置内の中央ＲＣＵにおいて行われる。第１に、決定は、利用できる実体の能力に基づき、すなわち、すべての実体が、必要な機能を実行し、良好な性能を確保できる、または、それに適しているというわけではない。第２に、ローカルＲＣＵは、クラスタ内のすべてのＴＰに対する良好な接続を有するように選択されなければならない、すなわち、転送遅延は、ＳＦＮクラスタの同期動作を確実にするのに十分に短く、帯域幅は、すべての関連するＵＥの需要をサポートするのに十分でなければならない。第３に、問題の配備シナリオに依存して、他の基準、例えば資源割り当て、処理負荷、帯域幅構成の詳細および／または特定ノードの活動状態も同様に考慮されうる。

【0039】

論理的であるが、必須ではない決定は、ローカルＲＣＵ機能をＳＦＮクラスタ内の（能力がある）ｅＮＢの１つに与えることである。しかしながら、定められるクラスタのダイナミクスのため、ローカルＲＣＵ機能を実行する実体は、期間後の最適以下の選択になりえ、最終的に、接続損失または接続品質の減少のため、機能を実行することができない、または、機能を実行するのに適さなくなりうる。また、実体は、不十分な計算資源を被りうるし、または、実体は、他のクラスタに供するのに最適な選択になりうるため、その現在のクラスタに供するのをやめなければならなくなりうる。

【0040】

他の実施形態では、特定ノードは、ソーラパネルによって電力供給されてもよい。この場合、ノードは、例えば、夜間に非活動状態に入ることを強制されると、ローカルＲＣＵ機能を実行するのに適さなくなりうる。

【0041】

さらに他の実施形態では、ローカルＲＣＵ機能の一部（またはサブセット）のみが、１つの実体（第１のノード）から他の実体（第２のノード）に、第２の（候補）ノードから受信される情報に基づいておよび／または第１のノード自体により推定される情報に基づいて転送される。

【0042】

記載されている理由は、現在の実体と新しく定義される（ターゲット）実体との間の機能転送の必要を示す。転送の最終的な決定は、ＳＦＮクラスタ管理装置によって行われるが、転送のためのトリガは、ローカルＲＣＵまたは中央ＲＣＵのいずれかから生じてもよい。

【0043】

デバイス内で実行される周知の測定、例えば、レガシーのセルラーネットワークから知られているようなセル間測定（この文脈では、「ＳＦＮ外の測定」と呼ばれる方が良い）は、ＲＣＵが、ＳＦＮクラスタに追加されるおよび／またはローカルＲＣＵ機能が与えられるＴＰの利用可能性を引き出すのを助けてもよい。

【0044】

図９は、例示的なメッセージ・シーケンス図を示し、上部において、転送前手順は、ローカルＲＣＵが機能を転送するためのオプションの要求によって示される（破線）。このメッセージは、特定の実体への転送を要求してもよく、特定の実体は、例えば、十分な数のＵＥにより、非常に良好に受信されると測定されたｅＮＢである。転送は、要求されたターゲット実体なしで要求されてもよく、例えば、ＲＣＵと１つまたは複数のＴＰとの間の接続品質の減少を示す。

【0045】

要求は、クラスタ内のＵＥから受信される測定またはローカルＲＣＵ自体によって行われる測定を含んでもよい。要求は、単一の測定または連続測定および観察から引き出される統合情報を含んでもよい。

【0046】

代替例は、図９に点線で示される。現在のローカルＲＣＵは、１つまたは複数の候補実体、例えば、現在所定のクラスタの一部である近くのｅＮＢ（図９に示すように）ならびに現在クラスタの一部でない近くのｅＮＢを直接要求し、クラスタ内のＵＥによって送信されるＵＬ信号を測定してもよい。この要求に対する他の実体からの回答は、測定結果および現在の能力情報を含むことができ、能力情報とは、その実体がクラスタのＲＣＵ機能を引き受けることができるか否かについての情報であり、オプションで、特定の数のＵＥ、最大帯域幅などに限定される。さらなる情報、例えば、現在の資源割り当ておよび／または負荷表示は、さまざまな近くのｅＮＢから受信される応答の一部であり、これらの近くのｅＮＢがＲＣＵ機能を実行するのに適しているか否かを決定してもよい。

【0047】

例えば、ＲＣＵ機能を１つのノードから他のノードに転送すべきか否かの決定は、以下のような特徴に基づいてもよい。
−アップリンク測定（例えば、基地局によってアップリンク・チャネル上で実行される）−ダウンリンク測定（例えば、移動端末によってダウンリンク・チャネル上で実行され、その後報告される）
−ノード能力
−ノード構成の詳細
−活動状態
−無線資源利用
−処理負荷

【0048】

代替的に、ＲＣＵ機能を転送するための要求が、現在のローカルＲＣＵから受信された後、非常に類似の要求は、ＳＦＮクラスタ管理装置（中央管理装置）から行われてもよい。図９のこの代替例では、ＳＦＮクラスタ管理装置がさまざまな近くのｅＮＢの能力についての知識を有すると仮定されるので、能力関連部分の情報を、さまざまな近くの候補ノードからＳＦＮクラスタ管理装置（中央管理装置）に交換することを示す必要はない。

【0049】

要求、応答および受信されたフィードバック（例えば、測定および／または位置情報など）に基づいて、ＳＦＮクラスタ管理装置（中央管理装置）は、ソースおよびターゲット実体にそれぞれのローカルＲＣＵ機能を転送するように命じることによって、機能の転送を開始する。

【0050】

この機能転送によって、クラスタの一部であるＴＰは、必ずしも変化するわけではない、すなわち、ソースＲＣＵが、例えば、ＴＰとしても実行していたｅＮＢである場合、ＴＰ機能は、完全なままであることができ、ＵＥと送受信されたいかなる情報も失わない。これは、図９において「（ＴＰ）」と記載されている。

【0051】

クラスタのローカルＲＣＵは、例えば以下のようないくつかの機能を有する。

【0052】

機能Ａ：ＤＬデータをＴＰに同期転送のために分散すること、すなわち、同期転送を介した分散、または、同期情報、例えば正確な送信タイミングを併用した分散
機能Ｂ：異なるＴＰによって受信されるＵＬデータの結合および／または選択、すなわち、（クラスタのすべてのＴＰからの）それぞれの受信ノードを選択すること、および、複数のＴＰによって冗長に受信され、ＮＷに転送される単一のＵＥからのデータを結合すること
機能Ｃ：資源管理、すなわち、ＳＦＮクラスタ管理装置（中央管理装置）によってクラスタに割り当てられた利用できる資源を、クラスタ内で供される異なるＵＥに割り当てること（ＵＥに特定の需要に依存して）
機能Ｄ：ローカルＴＰ管理、すなわち、より良好な電力効率およびＴＰの送信電力の制御のためのＴＰの起動／停止であり、ＵＬ内で受信される電力制御情報を結合し、ＤＬのためのさまざまなＴＰの電力需要を引き出す

【0053】

ローカルＲＣＵ機能の転送は、ソースノードとターゲットノードとの間の上述した機能のシームレスまたはほぼシームレスの転送を意味する。

【0054】

機能Ａ
転送の間および転送後にＤＬデータ分散を確実に成功させるために、ネットワークは、トラフィックのルーティングについて、新しいローカルＲＣＵを介して知らされることが好ましい。古いルートを介して（ソースのローカルＲＣＵを介して）まだ受信されるすべてのトラフィックは、転送前のようにＴＰに分散可能である、または、ターゲットのローカルＲＣＵに転送可能である。すべての残りのトラフィックがソースのローカルＲＣＵによって送信された後、ターゲットのローカルＲＣＵを介したトラフィックは、ＴＰに分散されるのみであることが好ましい。従来技術の解決法では（例えば、ＬＴＥにおけるｅＮＢ間のハンドオーバまたは単一のＵＥデータルートのためのネットワークノードの類似の変化のために）、ソースノードは、トラフィックをターゲットノードに、ＵＥへの送信のために転送する。最後に転送されたパケットは、終了マーカーを含んでもよく、終了マーカーは、転送された（古い）データの終了を示し、それゆえターゲットノードによる新しいデータ分散を開始する。

【0055】

現在のＳＦＮクラスタ解決法の特別な要求は、データパケットの同期分散である。
○ＲＣＵからＴＰへの分散の性質が同期方法である場合、すなわち、データパケットの分散が、エアインタフェース上のＴＰによるデータの送信に時間的に結び付けられている場合、分散機能の切り替えは、正確に同期しなければならない。これは、ソースＲＣＵおよびターゲットＲＣＵの両方が、ソースが分散を停止し、ターゲットが分散を開始する時点（共通の時間に基づく）を定めることを必要とし、準備段階は、ターゲットがその時に開始できることを確実にしなければならない。
○ＲＣＵからＴＰへの分散が非同期で行われる場合、すなわち、データパケットの分散が、ＴＰによって送信される各パケットのための正確なタイミング情報を含む場合、切り替え時点は、ソースＲＣＵとターゲットＲＣＵとの間で一致してもよく、両方は、非同期に実行を開始することができ、ターゲットは、切り替え時点後にのみ転送のためのパケットを分散し、ソースＲＣＵは、その時点前にのみ分散する。
○これらの機能の両方は、データ転送が用いられるか否かに関係なく、すなわち、ソースＲＣＵからターゲットＲＣＵに転送する分散機能データの切り替え後にも発生することができる。

【0056】

機能Ｂ
ＵＬデータの結合およびＴＰ選択の転送を確実に成功させるために、クラスタのＴＰは、ローカルＲＣＵ変化について知らされなければならない。分散されるデータが存在する限り、ソースが、そのＵＬ機能を継続できるので、ＴＰ内のルートをソースＲＣＵからターゲットＲＣＵに切り替えるための要求は、比較的緩和される。防止されなければならない唯一の状況は、１つのＴＰがそのＵＬデータをソースに送信し、１つのＴＰが同じデータをターゲットＲＣＵに送信することであり、そのことは、ＮＷへのＵＬデータストリーム内のデータの重複になりうる。ここでの解決法は、ＤＬに類似しており、同期した切り替えまたは（ＴＰ内のタイミング問題を緩和するための）例えばソースＲＣＵからターゲットＲＣＵへのデータ転送、および、ＲＣＵの１つのみにおける結合である。

【0057】

機能Ｃ
資源割り当て機能の転送の成功のために、ターゲットＲＣＵは、ＳＦＮクラスタに割り当てられる資源プールを提供されなければならない。これのための最も可能性のある解決法は、中央ＳＦＮクラスタ管理装置からの資源の提供である。なぜなら、中央ＳＦＮクラスタ管理装置は、全体の資源プール割り当て（ＳＦＮ間クラスタ干渉態様を含む）の責任を有するからである。代替例は、ソースのローカルＲＣＵからの現在の割り当ての転送である。関連する任意のコンテクスト情報、すなわち、資源需要についてのＵＥに特定のコンテクスト、申し込みサービス、能力、リンク品質などもまた同様に転送され、ターゲットのローカルＲＣＵがローカル資源割り当てを最適に実行することを可能にしなければならない。

【0058】

実際のデータが関連した資源を介してターゲットのローカルＲＣＵによって分散されるより十分に前もって、現在のＤＬ資源割り当ては、転送されなければならず、ターゲットのローカルＲＣＵが適切な資源をそのＤＬ分散の開始から選択できるのを確実にしなければならない。ＵＬ資源割り当ては、ターゲットのローカルＲＣＵによってもまた知られていなければならず、受信データを正しいソースＵＥにマップしなければならない。ターゲットのローカルＲＣＵは、その後毎回、自身の割り当て戦略に従って、資源プールからのＵＬ資源を割り当てることができる。

【0059】

機能Ｄ
ローカルＴＰ管理（および上述したいくつかの機能）の転送は、第１に、クラスタに帰属するＴＰについての知識を必要とする。知識とは、ターゲットＲＣＵによって必要とされる情報であり、ＴＰの現状、すなわちオンまたはオフであるか、潜在的にＵＥに特定のＴＰの関係、すなわち一般的に「オンである」ＴＰが、特定のＵＥと送受信することを必要とされるかという情報である。クラスタのいくつかのＴＰは、十分な品質で他のＴＰから受信するＵＥへの分散およびそれぞれＵＥからのＵＬ送信のために「無言（ｑｕｉｅｔ）」にされてもよい。この情報は、ソースのローカルＲＣＵから、または、中央ＲＣＵからのいずれかから交換されなければならない（または、ターゲットのローカルＲＣＵへの情報転送が２つの間で分割されるときには両方）。一般的にＴＰ管理は、機能Ａ〜Ｃの転送需要と比較して、時間および同期要求を緩和している。

【0060】

図１０は、メッセージ・シーケンス図において上述した情報の交換を示し、メッセージ・シーケンス図は、情報の交換のための複数の実体間の例のメッセージを用いる。しかしながら、メッセージは、異なる順序で交換されてもよい。また、より多いメッセージが用いられてもよいし、または、より少ないメッセージが用いられてもよい。

【0061】

図１０では、ターゲットのローカルＲＣＵ（ＲＣＵ_ｙ）は、ソースのローカルＲＣＵによって機能転送について知らされる。代替例は、図９に示されており、図９では、ソースおよびターゲットのローカルＲＣＵの両方が、ＳＦＮクラスタ管理装置（中央管理装置）によって知らされていた。図１０に示された例では、ルーティング情報は、ＴＰ（１つのみが示される）およびネットワーク内で基本的に同時に中央管理装置によって更新される。ＵＥとＴＰとの間のエアインタフェースは、転送によって全く影響されないが、ルーティングが更新される前、ソースのローカルＲＣＵに到着しているＵＬトラフィックは、ターゲットのローカルＲＣＵに転送され、データ重複を防止する。終了マーカーは、データ転送の終了をマークするので、ターゲットのローカルＲＣＵは、ＤＬデータをＴＰの方に送信開始することができる。メッセージの他のタイミング関係を有する他の例を示すことができ、それゆえ、図１０は多数の可能性がある例のうちの単なる１つである。

【0062】

表１は、（図１０の上部に示される）「転送コンテクスト」メッセージの内容に含まれてもよい情報要素を示し、情報要素が「必須」Ｍとみなされるか、または、「オプション」ＯＰとみなされるかを示す。

【0063】

【表1】

【0064】

当業者は、さらなる情報要素が可能であると理解するものである。

【0065】

機能の転送が完了した後、ソースのローカルＲＣＵは、それぞれのＳＦＮクラスタについてすべてのコンテクストを削除することができる。ターゲットのローカルＲＣＵは、ＳＦＮクラスタの管理を、資源を割り当てることなどによって開始することができる。

【0066】

ターゲットのローカルＲＣＵは、ソースのローカルＲＣＵを、そのＳＦＮクラスタのための最近のローカルＲＣＵのリスト内に記憶し、ＵＥからの測定がそのように指示する場合、同じローカルＲＣＵに戻って切り替わることを防止することができる。ローカルＲＣＵ機能の転送のためのいわゆる「ピンポン効果」の防止は、システムの効率を保証するために重要である。

【図1】

【図2】

【図3A】

【図3B】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】