(57)【要約】【課題】クラウドに基づいた無線アクセスネットワークのリソース管理方法を提供する。【解決手段】クラウドには、仮想サービスアンカー又はｖＳＡがあり、それぞれの仮想サービスアンカーは、その仮想ネットワークによって提供される個々のサービスに対して提供される。そして、一のｖＳＡは、一の仮想ネットワーク内の一のサービスの全てのユーザに対してリソース割り当てを取り扱う。ｖＳＡは、コンテンツアクセス要求に応答して、示されたコンテンツ及びユーザ装置に対して近隣の基地局に基づいて、少なくとも１つの適切なコンテンツデリバリノードを識別して、サービス要求を送信する。複数のｖＳＡから受け取られたサービス要求に応答して、それぞれの基地局は、第２のリソース割り当てを実行して、その基地局に無線接続しているそれぞれのユーザ装置にサービスを提供する。【選択図】図５
2016082569.tif 000002
【特許請求の範囲】
【請求項１】
クラウドにおいて利用可能な共通のリソースから、複数の仮想ネットワークを決定することであって、それぞれの前記仮想ネットワークは１つ又は複数のサービスを提供し且つ複数のサービング基地の内の何れかを使用しており、ユーザ装置は、前記サービング基地に無線接続されて一の前記仮想ネットワークにアクセスすることと、
前記ユーザ装置が、一の前記仮想ネットワークに加入している前記ユーザ装置のユーザによって、特定のサービスを受け取ることができることを許容することと、
それぞれの前記仮想ネットワークでは、前記仮想ネットワークの全てのユーザに対してサービスをプロビジョニングするために前記共通のリソースを用いて、前記仮想ネットワークによって提供されるそれぞれの特定のサービスに対して第１リソース割り当てを実行し、前記第１リソース割り当てに基づいてサービス要求を送信することと、
それぞれの前記サービング基地では、それぞれの前記仮想ネットワークから前記サービス要求を受信し、応答して、前記サービング基地に無線接続しているそれぞれの前記ユーザ装置に対してサービスを提供するために第２リソース割り当てを実行することと、
を備えるクラウドに基づいた無線通信システムにおけるリソースを管理するための方法。
【請求項２】
更に、
前記仮想ネットワークによって提供されるそれぞれの特定のサービスに対して、個々の仮想サービスアンカーを提供することであって、前記仮想サービスアンカーはその特定のサービスに対して前記第１のリソース割り当てを実行し且つその特定のサービスに対して前記サービス要求を送信することを備える請求項１に記載の方法。
【請求項３】
更に、
それぞれの前記仮想サービスアンカーが、前記ユーザ装置の特定のサービスにおいてアクセスされるコンテンツを示す、前記ユーザ装置からのコンテンツアクセス要求を受け取ることと、
それぞれの前記仮想サービスアンカーが、前記コンテンツアクセス要求、及び所定の仮想オペレータポリシー及び記憶されたユーザプロファイルの内の少なくとも１つに基づいて、前記仮想サービスアンカーの特定のサービスに対する前記第１リソース割り当てを実行することと、
を備える請求項２に記載の方法。
【請求項４】
それぞれの前記コンテンツアクセス要求は、更に、前記サービング基地、及び／又は、前記ユーザ装置の位置情報に関する、前記ユーザ装置の測定レポートを有する請求項３に記載の方法。
【請求項５】
それぞれの前記仮想サービスアンカーから送信された前記サービス要求は、前記コンテンツアクセス要求に示されるコンテンツを保持する少なくとも１つのコンテンツデリバリノードへのサービスの要求を含む請求項３又は４に記載の方法。
【請求項６】
更に、
少なくとも１つの前記コンテンツデリバリノードが、前記サービス要求に示されるコンテンツのデータサイズを前記仮想サービスアンカーに通知することによって、前記サービス要求に応答することを備える請求項５に記載の方法。
【請求項７】
更に、
前記仮想サービスアンカーが、
一の前記コンテンツデリバリノード又はそれぞれの前記コンテンツデリバリノードによって通知される前記データサイズと、
一の前記コンテンツデリバリノードから一の前記サービング基地への１つ又は複数の接続のプロパティと、
前記ユーザ装置の測定レポート及び／又は位置情報と、
に基づいて、前記ユーザ装置に対するコンテンツの推定される配信時間を計算することを備え、
前記仮想サービスアンカーは、コンテンツの配信中に前記推定される配信時間を更新する請求項４〜６の何れか一項に記載の方法。
【請求項８】
それぞれの前記仮想ネットワークから送信される前記サービス要求は、特定のサービスを要求する一の前記ユーザ装置に対して近隣として識別される１つ又は複数の前記サービング基地のそれぞれへのサービスの要求を含む請求項１〜７の何れか一項に記載の方法。
【請求項９】
一の前記ユーザ装置に対して近隣として識別される１つ又は複数の前記サービング基地のそれぞれへの前記サービス要求は、少なくとも１つの前記コンテンツデリバリノード及び前記推定される配信時間を識別する請求項７又は８に記載の方法。
【請求項１０】
少なくとも１つの前記コンテンツデリバリノードに対するそれぞれの前記サービス要求は、特定のサービスを要求する一の前記ユーザ装置に対して近隣として識別される１つ又は複数の前記サービング基地に関する情報を含む請求項５又は８に記載の方法。
【請求項１１】
更に、
特定のサービスを要求する一の前記ユーザ装置に対して近隣として識別される１つ又は複数の前記サービング基地のそれぞれが、コンテンツを受信し且つ前記ユーザ装置に対してコンテンツを送信するために一の前記コンテンツデリバリノード又はそれぞれの前記コンテンツデリバリノードとの接続を確立することを備える請求項９又は１０に記載の方法。
【請求項１２】
更に、
それぞれの前記仮想サービスアンカーが、前記ユーザ装置、前記サービング基地、及び、一の前記コンテンツデリバリノード又はそれぞれの前記コンテンツデリバリノードからフィードバックを受け取ることを備え、前記フィードバックは、
一の前記ユーザ装置からの、近隣の前記サービング基地との前記ユーザ装置の無線接続の状態と、
一の前記サービング基地からの、前記サービング基地の負荷状態及び／又は前記サービング基地によって経験される干渉状態と、
一の前記コンテンツデリバリノードからの、負荷状態及び／又は前記仮想ネットワークとの接続の状態と、
の内の少なくとも１つを含む請求項５に記載の方法。
【請求項１３】
更に、
前記第１リソース割り当てでは、前記仮想サービスアンカーが、前記ユーザ装置の近隣の複数の前記サービング基地のそれぞれに対して、好ましいリソーススケジューリングの決定を決定して、該決定を関係するそれぞれの前記サービング基地へ送信することと、
前記第２リソース割り当てでは、前記決定を考慮するそれぞれの前記サービング基地が、達成可能なリソーススケジューリングの決定を決定することであって、前記サービング基地が該決定を前記仮想サービスアンカーへその後通知することと、
１つ又は複数の前記コンテンツデリバリノードから少なくとも１つの前記サービング基地を介して前記ユーザ装置へコンテンツを配信することによって、前記ユーザ装置のサービスセッションを開始することと、
前記サービスセッションの間に間隔をあけて、前記第１リソース割り当て及び前記第２リソース割り当てを繰り返すことと、
を備える請求項１２に記載の方法。
【請求項１４】
更に、
前記仮想サービスアンカーが、前記コンテンツデリバリノードに対して、その前記コンテンツデリバリノードに関係するそれぞれのリソーススケジューリングの前記決定を通知することを備える請求項１３に記載の方法。
【請求項１５】
更に、
前記仮想サービスアンカーが、前記サービング基地からの達成可能なリソーススケジューリングの前記決定に基づいて、その好ましいリソーススケジューリングの前記決定を修正して、修正された該決定を関係するそれぞれの前記サービング基地へ送信することを備え、
それぞれの前記サービング基地は、修正された前記決定を考慮して前記第２リソース割り当てを繰り返して、前記仮想サービスアンカーに対して結果を通知する請求項１３又は１４に記載の方法。
【請求項１６】
クラウドにおいて利用可能な共通のリソースを用いて決定された複数の仮想ネットワークの内の何れかを用いてサービスを受け取るように配置された複数のユーザ装置と、
複数のサービング基地であって、一の前記ユーザ装置が、複数の前記仮想ネットワークの内の何れかと少なくとも１つの前記サービング基地を介して無線接続するように配置されて、前記仮想ネットワークに加入している前記ユーザ装置のユーザに対する特定のサービスを一の前記仮想ネットワークから受け取る、複数のサービング基地と、
複数の前記仮想ネットワーク内の複数の仮想サービスアンカーであって、それぞれの前記仮想サービスアンカーは、前記仮想ネットワークによって提供される個々のサービスに対して提供され、前記共通のリソースを用いて第１リソース割り当てを実行するように配置され、前記第１リソース割り当てに基づいてサービス要求を送信するように配置される、複数の仮想サービスアンカーと、
を備え、
それぞれの前記サービング基地は、複数の前記仮想サービスアンカーから受け取った前記サービス要求に応答して、第２リソース割り当てを実行し、前記サービング基地に無線接続しているそれぞれの前記ユーザ装置に対してサービスを提供するように配置されるクラウドに基づいた無線通信システム。
【請求項１７】
それぞれの前記仮想サービスアンカーは、更に、個々のサービスにおいてアクセスされるコンテンツを示す、前記ユーザ装置からのコンテンツアクセス要求を受け取るように配置され、
前記システムは、更に、少なくとも１つのコンテンツデリバリノードを備え、それぞれの前記仮想サービスアンカーから送信された前記サービス要求は、示されたコンテンツに基づいた少なくとも１つの前記コンテンツデリバリノードに対するサービスの要求を含む請求項１６に記載の無線通信システム。
【請求項１８】
少なくとも１つのネットワークに接続されたコンピュータのプロセッサ及びサービング基地によって実行される時に、請求項１〜１５の何れか一項に記載の方法を実行するコンピュータ可読コードを有するソフトウェア。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線ネットワーク内のリソース管理に関し、特に、無線アクセスネットワーク（ｒａｄｉｏ  ａｃｃｅｓｓ  ｎｅｔｗｏｒｋ：ＲＡＮ）の少なくとも一部がクラウドコンピューティング又は言い換えると「クラウド内」を介して実装される無線ネットワークに関する。
【背景技術】
【０００２】
今日のデータ速度の要求の指数関数的な増加は、利用可能な記憶容量及び処理力の指数関数的な増加と密接に結合しており、処理力が大きい程、処理データを記憶するためにより多くの記憶を要求する。この要求を満たすために、クラウドコンピューティングは、ＩＴプラットホームの発展を著しく変えた破壊的な技術である。
【０００３】
ＮＩＳＴ（米国標準技術局）は、クラウドコンピューティングを、「最小の管理努力又はサービスプロバイダの相互作用で速やかに提供され且つ開放され得る可変なコンピュータリソース（例えば、ネットワーク、サーバ、ストレージ、アプリケーション及びサービス）の共有プールに対して、偏在し、便利で、オンデマンドなネットワークアクセスを可能にするためのモデル」と定義する。クラウドコンピューティングモデルの本質的な特徴は、以下の通りである。
（ｉ）オンデマンドのセルフサービス
任意のクラウドユーザが、その時に且つその特定の必要に最も適合した量で、クラウドプラットホーム中の直接のサービスエントリポイントを介して、必要なコンピュータリソースを自己で供給でき、人的な支援がなく且つプロビジョニングが自動的である。
（ｉｉ）ブロードネットワークアクセス
コンピュータリソースは、標準的なネットワーク接続を用いて、一意的にアクセスされ且つ使用される（他のタイプの接続は存立できない）。
（ｉｉｉ）リソースプール
コンピュータリソースのプールは、マルチテナントモデルに従って、一意的であり全てのユーザ間で共有される。ユーザは、割り当てられるリソースの位置がクラウドプラットホームによって選択されるメカニズムに影響を与える方法を有さない。
（ｉｖ）高速伸縮性（ｒａｐｉｄ  ｅｌａｓｔｉｃｉｔｙ）
リソースは、ユーザに対してシームレスにスケーラブルであると思われて、いかなる方法でも、リアルタイムの要求に動的に適合することができなくてはならない。
（ｖ）メジャードサービス（ｍｅａｓｕｒｅｄ  ｓｅｒｖｉｃｅ）
クラウドプラットホームは、全ての関係する消費者からのリソース要求及び使用を監視し且つアカウントすることをサポートしながら、それぞれの提供されるサービスに特有の抽象的レベルを用いて、計測能力を備えていなくてはならない。
【０００４】
従来の移動ネットワークは、専用のネットワーク基盤（ｉｎｆｒａｓｔｒｕｃｔｕｒｅ：インフラストラクチャ）を使用して、ある特定の無線アクセス技術（ｒａｄｉｏ  ａｃｃｅｓｓ  ｔｅｃｈｎｏｌｏｇｙ：ＲＡＴ）に基づいたＲＡＮを提供する。同じ地理的領域内では、しばしば標準のＷｉＦｉ（登録商標）グループに基づいた無線ＬＡＮと一緒に、通常、ＧＳＭ（登録商標）、ＵＭＴＳ及びＬＴＥのような無線アクセス技術に基づいた複数の共存するＲＡＮがある。一のネットワークの基地局又はアクセスポイントは、普通、独自の性質を有し、任意の一の基地局の使用率は全く低いものの、他のシステムに対して互換性を有さない。無線データに対する絶えずに増大する要求に応ずるための試みに失敗して、全体的な容量は、ＲＡＮ間の干渉によって制限され得る。共存するＲＡＮ間でハードウェアを共有するための試みがなされているけれども、全体的な案は、基本的に非協働的で、柔軟性がなく且つハードウェアリソースの浪費である。
【０００５】
従って、クラウド技術を活用して電気通信ネットワークを改善し且つトラフィック要求を変えることによってユーザの要求に対処することの可能性が調査されている。
【０００６】
その一方で、ネットワーク機能及びそのハードウェア間の依存性を取り除くために、仮想化技術が提案されており、仮想マシンの形で複数の仮想ネットワーク機能によって、物理的ハードウェアの共有をもたらす。ハードウェアの更なる貯蔵は、クラウドコンピューティング基盤においてすでに見られる現象である、大きく且つ機敏なリソースの共有を促進し得る。
【０００７】
ＮＧＭＮ（Ｎｅｘｔ  Ｇｅｎｅｒａｔｉｏｎ  Ｍｏｂｉｌｅ  Ｎｅｔｗｏｒｋｓ）プロジェクトの一部として、いわゆるクラウドＲＡＮ（Ｃｌｏｕｄ−ＲＡＮ：Ｃ−ＲＡＮ）は、中央的処理、共同の無線、リアルタイムのクラウドコンピューティング及び「クリーンな」（単純な建築の意味において）ＲＡＮシステムとして提案されている。中央的処理は、オペレータがクラウドコンピューティングパラダイムを使用して、共同の方法で入ってくる無線トラフィックを取り扱うことを許容して、エンドユーザに対してより高いスループットを可能にする。
【０００８】
図１は、Ｃ−ＲＡＮに適用可能なシステムアーキテクチャを示す（ここで、本明細書では、「システム」及び「ネットワーク」という用語は、文脈によって他のことが要求されない限りは交換可能である）。このＣ−ＲＡＮ１では、無線通信ネットワークの従来の基地局（ＢＳ）は、遠隔無線ヘッド（Ｒｅｍｏｔｅ  Ｒａｄｉｏ  Ｈｅａｄ：ＲＲＨ）１０及びベースバンドユニット（Ｂａｓｅ  Ｂａｎｄ  Ｕｎｉｔ：ＢＢＵ）２０に分けられる。
【０００９】
ＲＲＨ１０は、デジタルベースバンド及び伝達ネットワークに適合し、ＲＦ送信からの無線機能及びユーザ装置（図示せず）による受信を担当しており、遠隔に位置する無線ユニット及びアンテナである。図１に示すように、ＲＲＨ１０のクラスタがあり得る。それぞれのＲＲＨは、無線通信ネットワーク及びクラスタにおいて、少なくとも１つのセルを提供し、従って、所定の地理的領域においてセルが重なるネットワークを形成し得る。
【００１０】
ＢＢＵ２０は、高性能でプログラム可能なプロセッサ及びリアルタイムの仮想化技術からなる、ベースバンドデジタル処理装置である。ＢＢＵ２０は、物理層レベル（Ｌ１）機能において要求される任意の行動を実行し、ＢＳの層２及び３の機能（制御及び管理）を集める。ＢＢＵ２０及びＲＲＨ１０は、高いバンド幅及び低い待機時間の光学的な「フロントホール（ｆｒｏｎｔｈａｕｌ）」ネットワーク（１つ又は複数の光学スイッチ／ルータ３を有する）を介して、結合される。
【００１１】
それぞれのＢＢＵは、スタンドアロン（独立型）ユニットではなく、むしろ、図１に示すように、仮想マシンとして提供され、「ＢＢＵプール」の一部が、中央局又はデータセンタ２内に実装される。中央局２は、複数の無線アクセス技術（無線アクセス技術）のそれぞれのための一つである、一のＢＢＵプールよりも多くのＢＢＵプールを含み得る。それぞれの中央局内では、個々のＢＢＵ（仮想マシン）は、堅く相互接続され、高速のデータ交換を許容し得る。一のＲＡＴプール内のＢＢＵの結合は、通常、異なるプール間よりも密接であろう。
【００１２】
ここで、ＢＢＵは、図１では、原則ＲＡＴ毎に異なるプールで示されているが、これは、１つのあり得る配置だけである。
【００１３】
図２を参照して、中央局の仮想マシンの他の概念が示される。
【００１４】
この例では、リソースプール２４が、ＰＨＹ（物理）層、ＭＡＣ／Ｔｒａｎｓ（メディアアクセス制御／トランスポート）層、アクセレータ層、及び制御及び管理（動作及び保守又はＯ＆Ｍ）層という様々な階層レベルで定義される。図２に示されるように、リソースプール２４は、中央局の複数のプロセッサ２３のハードウェアリソースから形成される。それぞれのプロトコル層におけるリソースプールは、協働して、図の右側の部分に示されるように、図１のＢＢＵに対応する、複数の（仮想）基地局（ＢＳ）２５を決定する。示されるように、複数の基地局は、異なる標準１，２及び３に、言い換えると、異なる無線アクセス技術に、対応し得る。ところで、本明細書では、基地局は、それぞれが一のＲＡＴに付属しているように示されるが、マルチＲＡＴの基地局も可能である。基地局は、また、無線セルラ機能を、ＷＬＡＮ機能（ＷｉＦｉ（登録商標））又はＬＴＥに基づく無線通信に対して使用される非認可のスペクトル（いわゆるＬＴＥ−Ｕと呼ばれる）と結合して、アクセスポイントと共に無線セルラ基地局として動作し得る。更なる可能性は、基地局によってサポートされる、ユーザ装置間の無線通信のためのＬＴＥスペクトルを用いるいわゆる装置トゥ装置（ｄｅｖｉｃｅ−ｔｏ−ｄｅｖｉｃｅ：Ｄ２Ｄ）通信を使用することである。
【００１５】
再度図１を参照して、光学スイッチ／ルータ３は、ＢＢＵへの経路を提供すると共に、スイッチ／ルータ３’を介して、中央局２’へ結合するＲＲＨ１０を有する他の領域のネットワークへの接続を許容する。中央局２’は、中央局２’によってカバーされる異なる地理的領域にサービスし得る。
【００１６】
クラウドにおける他のノードへのＢＢＵ２０の接続は、いわゆる「バックホール（ｂａｃｋｈａｕｌ）」ネットワーク上で実行される。これは、従来のインターネットプロトコルを用いた、ブロードバンドインターネット接続である（又は少なくとも思われ得る）。それぞれの中央局２は、バックホールネットワークを介して、コンテンツデリバリノード３０に接続される。図では、コンテンツデリバリノードのうちの１つが示されており、実際には他のネットワーク基盤（ルータ５によって例示される）が存在するだろう。
【００１７】
そのようなアーキテクチャにおける無線リソース管理は、簡単ではない仕事であることが知られており、複数の仮想ネットワークオペレータ（Ｖｉｒｔｕａｌ  Ｎｅｔｗｏｒｋ  Ｏｐｅｒａｔｏｒｓ’：ＶＮＯｓ）が複数の仮想ネットワークを定義する同じ物理基盤上に存在する、仮想無線アクセスネットワーク（Ｖｉｒｔｕａｌ  Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ：Ｖ−ＲＡＮ）との関連において、より挑戦的にさえなる。
【００１８】
図３は、Ｖ−ＲＡＮにおける無線リソースの管理を示しており、階層的に示されており、共通無線リソース管理（Ｃｏｍｍｏｎ  Ｒａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｍａｎａｇｅｍｅｎｔ：ＣＲＲＭ）及びローカルＲＲＭ上で、仮想無線リソース管理（Ｖｉｒｔｕａｌ  Ｒａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｍａｎａｇｅｍｅｎｔ：ＶＲＲＭ）を構成する。階層は、上から下まで示され、上において最も高いレベル（最も抽象的）の機能を備える。図３の下におけるアンテナの記号は、図１のＲＲＨに対応する。ＲＲＭは、図１におけるＲＡＴ  ＢＢＵプール毎に、おおまかに等しい。
【００１９】
この階層の最も高いレベルにおけるＶＮＯは、無線アクセス基盤を所有しないネットワークオペレータであるが、ネットワークリソースを共有して、インフラストラクチャ提供者との取り決めによって、ＶＮＯの加入者（ｓｕｂｓｃｒｉｂｅｒ）への無線接続を提供する。このスキームでは、ＶＮＯは、物理基盤を取り扱う仮想リソースマネージャからの所定のレベルのサービス品質（ｑｕａｌｉｔｙ  ｏｆ  ｓｅｒｖｉｃｅ：ＱｏＳ）を要求する。これは、それぞれのサービスセッションのサービス条件の品質の追加である。そのような要求は、仮想オペレータとインフラストラクチャ提供者との間のサービスレベル契約（Ｓｅｒｖｉｃｅ  Ｌｅｖｅｌ  Ａｇｒｅｅｍｅｎｔ：ＳＬＡ）によってカバーされ得るか、及び／又は、現在の要求に基づいて動的に出される要求であり得る。
【００２０】
最も高いレベルのマネージャであるＶＲＲＭは、ＶＮＯの要求及びＳＬＡを、低いレベルに対するポリシーのセットに翻訳することを担当する。ＶＲＲＭは、仮想無線リソースの使用を最適化して、物理リソースは扱わない。とはいえ、ＣＲＲＭから受け取るレポート及び監視情報（例えば、推定された残りの容量）は、ポリシーを改善することを可能にする。
【００２１】
また、ジョイントＲＲＭ（ＪＲＲＭ）と呼ばれるＣＲＲＭは、ＶＲＲＭとローカルなＲＲＭとの間で中間の管理レベルである。ＣＲＲＭは、異種のアクセス環境（マルチＲＡＴの意味の異種）において、ポリシーを出して無線リソースを管理することに加えて、仮想リソースから物理リソースまでのＶＲＲＭのポリシーを計画する。また、ＣＲＲＭは、ローカルなＲＲＭからの情報に基づいて、ポリシーを最適化して、ＶＲＲＭに対してレポートを送る。
【００２２】
ローカルなＲＲＭは、最も低いリソース管理レベルにおいて、単一の無線アクセス技術（ＲＡＴ）における無線リソースの使用を最適化することに対して責任がある。それらは、要求を受け取ることに際して、エンドユーザに対して、物理無線リソースパラメータ（例えば、電力、周波数幅、タイムスロット等）を割り当てることを担当する。それぞれのローカルなＲＲＭに対するＣＲＲＭによって出されるポリシーは、そのＲＲＭに対する決定ガイドラインとして用いられる。ＣＲＲＭによって設定されるポリシーに加えて、それぞれのローカルなＲＲＭにおけるリソースの割り当ては、それぞれのサービスのＱｏＳ要求を満たさなければならない。ここで、「サービス」は一のエンドユーザに提供されている特定のアプリケーションと称される。
【００２３】
現在まで、仮想ネットワーク及びＶ−ＲＡＮの概念は、クラウドコンピューティングの原則を用いることなく、従来のネットワーク基盤を共有していた。他方、Ｃ−ＲＡＮによって提供される仮想化は、リソースが要求に応じて仮想オペレータ間で柔軟に割り当てられることを許容して、Ｖ−ＲＡＮの概念に自然に合うものである。図３中の鎖線が示すように、それぞれのＲＡＴに対する少なくともＲＲＭ機能及びＣＲＲＭは、Ｃ−ＲＡＮ１によって実行され得る。
【００２４】
ここで、クラウドに基づいたネットワークを考えると、基本の基盤は、一人又は複数のオペレータによって提供され、幾人かの仮想オペレータによって共有される。そのようなネットワークの基本的特徴は、下記を含み得る。
トラフィックの密集領域
無線アクセス技術の多様性
マクロセルのカバー領域上のマルチモードのスモールセル（ＬＴＥ階層及びＬＴＥ−Ｕ／ＷｉＦｉ（登録商標）階層）
【００２５】
そのようなクラウドに基づいたネットワークでは、リソースは、複数のオペレータ（仮想オペレータを含む）によって共有され、彼らは、異なる経営戦略／焦点を有し、従って、異なる顧客／加入者に基づいた異なるポリシーを有し得る。リソースの管理は、個々の仮想オペレータに対して、サービスポリシーが実施されることを保証し、且つ個々の仮想オペレータの顧客／加入者に対して提供されるサービスの特徴を考慮してＱｏＳを保証するために必須である。一方、物理ネットワークの能力の観点から、最小のコストで高いリソースの利用を維持することが重要である。
【００２６】
要するに、解決を要求している問題は、クラウドに基づいたネットワークにおけるリソースの管理をどのように効率的にサポートするかということである。
【先行技術文献】
【特許文献】
【００２７】
【特許文献１】欧州特許出願公開第１５６０１４号明細書
【特許文献２】国際公開第２０１２／１４５５３３号
【発明の概要】
【００２８】
本発明の第１態様によれば、クラウドにおいて利用可能な共通のリソースから、複数の仮想ネットワークを決定することであって、それぞれの上記仮想ネットワークは１つ又は複数のサービスを提供し且つ複数のサービング基地の内の何れかを使用しており、ユーザ装置は、上記サービング基地に無線接続されて一の上記仮想ネットワークにアクセスすることと、上記ユーザ装置が、一の上記仮想ネットワークに加入している上記ユーザ装置のユーザによって、特定のサービスを受け取ることができることを許容することと、それぞれの上記仮想ネットワークでは、上記仮想ネットワークの全てのユーザに対してサービスをプロビジョニングするために上記共通のリソースを用いて、上記仮想ネットワークによって提供されるそれぞれの特定のサービスに対して第１リソース割り当てを実行し、上記第１リソース割り当てに基づいてサービス要求を送信することと、それぞれの上記サービング基地では、それぞれの上記仮想ネットワークから上記サービス要求を受信し、応答して、上記サービング基地に無線接続しているそれぞれの上記ユーザ装置に対してサービスを提供するために第２リソース割り当てを実行することと、を備えるクラウドに基づいた無線通信システムにおけるリソースを管理するための方法が提供される。
【００２９】
ここで、「クラウド」は、インターネットを介してアクセス可能なハードウェアリソースと称され、その物理的位置は重要ではない（そして、実際、サービング基地又はユーザ装置に対して明らかではないだろう）サービング基地は、仮想ネットワークに対して共通であるが、「クラウド」内にある必要はない（又は全体がある必要はない）。しかしながら、サービング基地の少なくとも複数の機能が、クラウド内に実装され得る。例えば、図１に示すように分離したＲＲＨ及びＢＢＵを有する基地局の形のサービング基地が、クラウド内に位置するＢＢＵ機能を有し得る。
【００３０】
それぞれの「サービング基地」は、基地局又はアクセスポイントであり得る。代わりに又は追加して、１つ又は複数のサービング基地が、装置トゥ装置（Ｄ２Ｄ）通信のために構成される他のユーザ装置を有し得る。上述したように、そのようなユーザ装置は、基地局によってサポートされる。従って、この場合には、「サービング基地」という用語は、そのサポートする基地局と組み合わされるユーザ装置をカバーすることとして考えると適切であり得る。
【００３１】
ユーザ装置がサービスを受け取ることができることを許容することは、具体的には、ユーザに対して仮想ネットワーク（及びおそらくその仮想ネットワーク内の１つ又は複数のサービスタイプに対して）に加入することを要求して、利用可能なサービスを提供するための前提条件を設定することと称される。実際のサービスの配信は、第１及び第２リソース割り当ての後まで、起こらない。そして、これらは、通常、順番にユーザ装置（下記参照）からの特定の要求に依存する。
【００３２】
方法は、上記仮想ネットワークによって提供されるそれぞれの特定のサービスに対して、個々の仮想サービスアンカーを提供することであって、上記仮想サービスアンカーはその特定のサービスに対して上記第１のリソース割り当てを実行し且つその特定のサービスに対して上記サービス要求を送信することを、好ましくは提供する。
【００３３】
通常、方法は、ユーザ装置からのサービスに対する特定の要求（コンテンツアクセス要求）によって、始動する。このように、本発明の一実施形態であるサービス要求手順では、方法は、好ましくは、更に、それぞれの上記仮想サービスアンカーが、上記ユーザ装置の特定のサービスにおいてアクセスされるコンテンツを示す、上記ユーザ装置からのコンテンツアクセス要求を受け取ることと、それぞれの上記仮想サービスアンカーが、上記コンテンツアクセス要求、及び所定の仮想オペレータポリシー及び好ましくはまた記憶されたユーザプロファイルの内の少なくとも１つ、に基づいて、上記仮想サービスアンカーの特定のサービスに対する上記第１リソース割り当てを実行することと、を備える。
【００３４】
この場合、好ましくは、それぞれの上記コンテンツアクセス要求は、更に、上記サービング基地、及び／又は、上記ユーザ装置の位置情報に関する、上記ユーザ装置の測定レポートを有する。それと同時に、それぞれの上記仮想サービスアンカーから送信された上記サービス要求は、上記コンテンツアクセス要求に示されるコンテンツを保持する少なくとも１つのコンテンツデリバリノードへのサービスの要求を含み得る。
【００３５】
次に、好ましくは、少なくとも１つの上記コンテンツデリバリノードが、上記サービス要求に示されるコンテンツのデータサイズを上記仮想サービスアンカーに通知することによって、上記サービス要求に応答する。このデータサイズは、もしそれが関係する上記コンテンツデリバリノードにおいて利用可能である全てであるならば、要求されたコンテンツの部分のみを有しうる。
【００３６】
その後、上記仮想サービスアンカーが、一の上記コンテンツデリバリノード又はそれぞれの上記コンテンツデリバリノードによって通知される上記データサイズと、一の上記コンテンツデリバリノードから一の上記サービング基地への１つ又は複数の接続のプロパティと、上記ユーザ装置の測定レポート及び／又は位置情報と、に基づいて、上記ユーザ装置に対するコンテンツの推定される配信時間を計算し得る。
【００３７】
また、上記仮想サービスアンカーは、コンテンツの配信中に上記推定される配信時間を更新し得る。
【００３８】
ここで、「１つ又は複数の接続のプロパティ」は、例えば、関係するサービング基地に対するコンテンツデリバリノード間の通信接続上の容量又は待機時間といえる。
【００３９】
上述した何れかの方法では、好ましくは、それぞれの前記仮想ネットワークから送信される上記サービス要求は、特定のサービスを要求する一の上記ユーザ装置に対して近隣として識別される１つ又は複数の上記サービング基地のそれぞれへのサービスの要求を含む。このように、ユーザ装置に対してサービスを提供することは、同時に２つ以上のサービング基地を有するユーザ装置の無線通信を含み得る。
【００４０】
好ましくは、一の上記ユーザ装置に対して近隣として識別される１つ又は複数の上記サービング基地のそれぞれへの上記サービス要求は、少なくとも１つの上記コンテンツデリバリノード及び上記推定される配信時間を識別する。このようにして、サービング基地は、ネットワーク内のどのノードに対して、データの要求を送るのかを知り、期待される遅れ及び／又はコンテンツのスループットの指示が、ユーザ装置へ与えられ得る。
【００４１】
また、好ましくは、少なくとも１つの上記コンテンツデリバリノードに対するそれぞれの上記サービス要求は、特定のサービスを要求する一の上記ユーザ装置に対して近隣として識別される１つ又は複数の上記サービング基地に関する情報を含む。コンテンツデリバリノードは、コンテンツの配信の期待される時間（又は期間）も同様に通知されて、コンテンツデリバリノードにおける負荷管理を促進し得る。
【００４２】
次に、特定のサービスを要求する一の上記ユーザ装置に対して近隣として識別される１つ又は複数の上記サービング基地のそれぞれが、コンテンツを受信し且つ上記ユーザ装置に対してコンテンツを送信するために一の上記コンテンツデリバリノード又はそれぞれの上記コンテンツデリバリノードとの接続を確立し得る。このようにして、サービスは、実際にユーザ装置に対して提供される。
【００４３】
本発明の他の実施形態が、複数のサービング基地に対する統合されたデータ配信手順を提供する。この場合、好ましくは、それぞれの前記仮想サービスアンカーが、前記ユーザ装置、前記サービング基地、及び、一の上記コンテンツデリバリノード又はそれぞれの上記コンテンツデリバリノードからフィードバックを受け取り、上記フィードバックは、一の上記ユーザ装置からの、近隣の上記サービング基地との上記ユーザ装置の無線接続の状態と、一の上記サービング基地からの、上記サービング基地の負荷状態及び／又は上記サービング基地によって経験される干渉状態と、一の上記コンテンツデリバリノードからの、負荷状態及び／又は上記仮想ネットワークとの接続の状態と、の内の少なくとも１つを含む。
【００４４】
次に、上記第１リソース割り当てでは、上記仮想サービスアンカーが、好ましくは、上記ユーザ装置の近隣の複数の上記サービング基地のそれぞれに対して、好ましいリソーススケジューリング（ｒｅｓｏｕｒｃｅ  ｓｃｈｅｄｕｌｉｎｇ）の決定を決定して、該決定を関係するそれぞれの上記サービング基地へ送信する。上記第２リソース割り当てでは、それぞれの上記サービング基地が、上記決定を考慮して、達成可能なリソーススケジューリングの決定（又は提案）を決定し、上記サービング基地が該決定を上記仮想サービスアンカーへその後通知する。
【００４５】
１つ又は複数の上記コンテンツデリバリノードから少なくとも１つの上記サービング基地を介して上記ユーザ装置へコンテンツを配信することによって、上記ユーザ装置と共に、サービスセッションが開始する。好ましくは、上記サービスセッションの間に間隔をあけて、上記第１リソース割り当て及び上記第２リソース割り当てが繰り返される。これは、データ配信のために使用されるサービング基地を変更することを含み得る。
【００４６】
ここで、好ましくは、上記仮想サービスアンカーが、上記コンテンツデリバリノードに対して、その上記コンテンツデリバリノードに関係するそれぞれのリソーススケジューリングの上記決定を通知する。
【００４７】
この実施形態は、好ましくは、更に、上記仮想サービスアンカーが、上記サービング基地からの達成可能なリソーススケジューリングの上記決定に基づいて、その好ましいリソーススケジューリングの上記決定を修正して、修正された該決定を関係するそれぞれの上記サービング基地へ送信することを備え、それぞれの上記サービング基地は、修正された上記決定を考慮して上記第２リソース割り当てを繰り返して、上記仮想サービスアンカーに対して結果を通知する。
【００４８】
本発明の第２態様によれば、クラウドにおいて利用可能な共通のリソースを用いて決定された複数の仮想ネットワークの内の何れかを用いてサービスを受け取るように配置された複数のユーザ装置と、複数のサービング基地であって、一の上記ユーザ装置が、複数の上記仮想ネットワークの内の何れかと少なくとも１つの上記サービング基地を介して無線接続するように配置されて、上記仮想ネットワークに加入している上記ユーザ装置のユーザに対する特定のサービスを一の上記仮想ネットワークから受け取る、複数のサービング基地と、複数の上記仮想ネットワーク内の複数の仮想サービスアンカーであって、それぞれの上記仮想サービスアンカーは、上記仮想ネットワークによって提供される個々のサービスに対して提供され、上記共通のリソースを用いて第１リソース割り当てを実行するように配置され、上記第１リソース割り当てに基づいてサービス要求を送信するように配置される、複数の仮想サービスアンカーと、を備え、それぞれの上記サービング基地は、複数の上記仮想サービスアンカーから受け取った上記サービス要求に応答して、第２リソース割り当てを実行し、上記サービング基地に無線接続しているそれぞれの上記ユーザ装置に対してサービスを提供するように配置される、クラウドに基づいた無線通信システムが提供される。
【００４９】
ここで、仮想サービスアンカーは、クラウド内にある。サービング基地が「クラウド内」にあるといえるか否か及びどのような範囲でサービング基地が「クラウド内」にあるといえるかは、実装に依存する。例えば、Ｄ２Ｄに対して構成されるユーザ装置の形におけるサービング基地は、それ自体はクラウド内にはないが、すでに上述したように、ＢＢＵ及びＲＲＨを有する基地局であるサービング基地、又はＢＢＵ及びＲＲＨを有する基地局を有するサービング基地は、クラウド内にＢＢＵの一部を有し得る。本明細書の他の場所で、「物理基地局」という用語は、ユーザ装置と物理無線インターフェース上で通信する基地局（ＲＲＨのような）の少なくとも一部があることを示すために使用される。
【００５０】
好ましくは、それぞれの上記仮想サービスアンカーは、更に、個々のサービスにおいてアクセスされるコンテンツを示す、上記ユーザ装置からのコンテンツアクセス要求を受け取るように配置され、上記システムは、更に、少なくとも１つのコンテンツデリバリノードを備え、それぞれの上記仮想サービスアンカーから送信された上記サービス要求は、示されたコンテンツに基づいた少なくとも１つの上記コンテンツデリバリノードに対するサービスの要求を含む。
【００５１】
本発明の第３態様によれば、上述されたシステム内で少なくとも１つの仮想サービスアンカーを提供するように構成されたコンピュータネットワーク内のサーバが提供される。
【００５２】
本発明の第４態様によれば、少なくとも１つのネットワークに接続されたコンピュータ及びサービング基地のプロセッサによって実行される時に、上述された方法の何れかを実行する、コンピュータ可読コードを備えるソフトウェアが提供される。
【００５３】
このように、本発明の実施形態は、ユーザ装置が、「クラウド内」の共通のリソースを用いて決定される複数の仮想ネットワークの内の何れかを介してサービスを受け取るように配置される、クラウドに基づく無線通信システムを提供し得る。システムは、複数の基地局（物理基地局又はアクセスポイント）と、少なくとも１つの基地局を介して仮想ネットワークの何れかと無線接続して、ユーザ装置のユーザが加入している仮想ネットワークから特定のサービスを受け取るように配置されるユーザ装置と、を有する。クラウド内には、複数の仮想サービスアンカー又はｖＳＡがあり、それぞれの仮想サービスアンカーは、その仮想ネットワークによって提供される個々のサービスに対して提供される。言い換えると、それぞれの仮想ネットワークでは、複数の仮想サービスアンカーがあり、サービス（又はサービスタイプ）毎に１つの仮想サービスアンカーであり、仮想ネットワーク内のサービスの全てのユーザを覆っている。
【００５４】
導入において説明されたＶＲＲＭと同様に、ｖＳＡは、従来のＲＲＭの上に無線リソース管理の追加の層を提供する。相違点は、ｖＳＡがサービス毎に且つＶＮＯ毎に基づいて決定されることである。また、ｖＳＡは、コンテンツデリバリノードに対して直接の論理インターフェースを提供して、スケジュールを作成する要求を行う時に、ｖＳＡがコンテンツデリバリノードからのフィードバックを考慮することを許容する。
【００５５】
本発明の実施形態は、ユーザ装置に対するコンテンツ（オーディオ、ビデオ、ファイル）の送信を含むサービスを主に目的とする。そのようなサービスの例は、ビデオ及びオーディオのストリーミング、ダウンロード等を含み得る。それぞれのｖＳＡは、物理基地局又はアクセスポイント（以下、ｐＢＳと示す）を介して、そのｖＳＡのサービス内でアクセスされるコンテンツを示す、ユーザ装置からのコンテンツアクセス要求又はサービス要求を受け取る。関係するコンテンツはクラウド内の少なくとも１つのコンテンツデリバリノードによって格納される。ｖＳＡは、コンテンツアクセス要求に応答して、それぞれの要求するユーザ装置に近隣の基地局と共に、少なくとも１つの関係するコンテンツデリバリノードを識別する。次に、ｖＳＡは、近隣の基地局に対するサービス要求と共に、指示されたコンテンツに基づいて少なくとも１つのコンテンツデリバリノードに対するサービスの要求を含む、サービス要求を送信する。複数のｖＳＡから受信したサービス要求に応答して、それぞれの基地局は、ローカル（セル）レベルにおけるリソース割り当てを実行して、その基地局と無線接続されたそれぞれのユーザ装置に対してサービスを提供する。
【００５６】
このように、本発明の実施形態は、仮想オペレータ（ＶＮＯ）を含む複数のオペレータによって共有される、クラウドに基づく仮想化されたネットワークにおいて、複数レベルの中央サービス的なリソース管理のメカニズムを提供し得る。提案される案では、サービスアンカー（ｖＳＡ）におけるレベル１のリソース管理、及び、物理基地局又はアクセスポイント（ｐＢＳ）におけるレベル２のリソース管理という、２つのレベルのリソース管理がある。
【００５７】
サービス要求の手順が提案されて、ｖＳＡが、仮想オペレータのユーザ装置によって提起される要求に対する適切なｐＢＳ及びコンテンツデリバリノードを識別することを許容する。また、ｖＳＡが関係するノード間のユーザ装置のデータの配信セッションを調整することを可能にする調整計画が提案される。
【００５８】
本発明の実施形態は、アプリケーション層（即ち、コンテンツデリバリノード）からアクセスネットワーク層（即ち、物理基地局又はアクセスポイント）へのノードの動作を調整することによって、リソース管理を最適化することができる。
【００５９】
提案されるリソース管理は、仮想オペレータの関係するユーザ装置だけでなく、全体的なネットワークの性能の利益となる、自動化された調整を許容する。
【図面の簡単な説明】
【００６０】
【図１】図１は、クラウドに基づいた無線アクセスネットワーク（Ｃ−ＲＡＮ）に対して提案されるネットワークアーキテクチャを示す。
【図２】図２は、図１のものと似たＣ−ＲＡＮを含み得る仮想化されたＲＡＮにおけるリソース管理のレベルを示す。
【図３】図３は、Ｃ−ＲＡＮの機能を実装するためのリソースプールを提供する中央局のプロセッサを示す。
【図４Ａ】図４Ａは、簡略化された従来のネットワークアーキテクチャ（図４Ａ）を、本発明で提案されるアーキテクチャ（図４Ｂ）と比較する。
【図４Ｂ】図４Ｂは、簡略化された従来のネットワークアーキテクチャ（図４Ａ）を、本発明で提案されるアーキテクチャ（図４Ｂ）と比較する。
【図５】図５は、本発明の実施形態におけるサービス要求手順に対する伝達ダイアグラムである。
【図６】図６は、本発明の実施形態におけるデータ配信セッションに対する伝達ダイアグラムである。
【発明を実施するための形態】
【００６１】
本発明の実施形態は、仮想オペレータ（ＶＮＯ）を含む複数のオペレータによって共有されるクラウドに基づく仮想化されたネットワークにおいて、複数レベルの中央サービス的なリソース管理メカニズムを提供する。仮想ネットワークが特定の仮想オペレータに対して生成されることが仮定される。一の仮想ネットワークは、１つ又は複数の仮想サービスアンカー（ｖＳＡ）を備えており、仮想ネットワークのカバレッジフットプリント及び能力は、この仮想オペレータの加入者の要求に対応して変化する。原則として、一の仮想ネットワークのカバレッジフットプリントは、一国全体に及ぶことができ、この場合には対応するｖＳＡは、国の異なる地理的領域にわたっては分配されるだろう。
【００６２】
本発明における新規な概念であるｖＳＡは、サービスに特有であり、オペレータに特有である。言い換えると、一の仮想オペレータは、複数のｖＳＡを有することができ、一のｖＳＡは、唯一の仮想オペレータ（ＶＮＯ）に属する。通常、所与のＶＮＯの一のサービスに対して、ただ１つのｖＳＡがある。「サービス」の例は、ビデオオンデマンド、音楽ストリーミング、マルチメディア放送（ｍｕｌｔｉｍｅｄｉａ  ｂｒｏａｄｃａｓｔ：ＭＢＭＳ）、ＷＷＷアクセス等を含み得る、この文脈において、「サービス」は「サービスタイプ」と同じである。ユーザは、彼らがＶＮＯとの契約に入る（加入する）と、１つ又は複数の異なる種類のサービスに対して加入し得る。どの位のｖＳＡが提供されるのかは、部分的には、定義の問題である。しかし、クラウドコンピューティングを使用することは、カバーされる地理的面積に関わらず、一の論理的ｖＳＡが一のＶＮＯの一の特定サービスに対して十分であるといえるだろう。
【００６３】
図４Ａ及び４Ｂは、本発明のアーキテクチャを、ＬＴＥに基づくネットワークのような従来の無線ネットワークのものと比較する。
【００６４】
図４Ａにおける従来の無線ネットワークは、独立型で一の特定の無線ネットワークの専用の基地局である基地局１４０と無線接続するユーザ装置１２を有する。基地局１４０は、専用でネットワークに特有のバックホール上で、コンテンツデリバリノード３０からコンテンツを読み出すことを許容しながら、インターネットに対するゲートウェイとして働くＰＤＮ−ＧＷ２６０と通信する。ＰＤＮ−ＧＷとコンテンツデリバリノード３０との間の接続は、そのように、ブロードバンドのインターネット接続であり得る。もしＣＤＮ３０がネットワークオペレータによって管理される場合、代わりに、専用のバックホールが使用され得る。ＰＤＮ−ＧＷ２６０は、また、ユーザ装置に対するサービスアンカーとして働き得る。一方、ＰＤＮ−ＧＷは、リソース管理機能を有さないことに留意されたい。
【００６５】
図４Ｂに示すように、本発明で使用するために提案されるアーキテクチャは、表面的には似ており、ユーザ装置及びコンテンツデリバリノードは不変である。しかし、この場合には、物理基地局又はｐＢＳ１４は、（例えば）部分的にクラウド内に、例えば図１のＢＢＵプールによって実装される仮想ネットワークの基地局であり、サービスアンカーは上述したｖＳＡ２６である。仮想ネットワークの基地局１４と、そのネットワークのｖＳＡ２６との間の接続は、ブロードバンドインターネットを介してか又は専用のバックホールを介しての何れかであり得る。一方、ｖＳＡ２６からコンテンツデリバリノード３０への接続は、ブロードバンドインターネット上（コンテンツデリバリノード３０がインターネット上に配置される場合）又は専用のリンク（もしコンテンツデリバリノード３０がオペレータの所有である場合）を介しての何れかで行われ得る。従って、高価な専用のバックホールに対する要求は、低下し得る。
【００６６】
ｖＳＡは、全てのＶＮＯによって提供される全てのタイプのサービスに対する一般的なレベルの無線リソース管理を提供するＶＲＲＭが（物理）ネットワーク内の全てのＶＮＯに対してサービスする、図３に示されるＶＲＲＭのような従来の提案とは異なる。対照的に、本明細書で提案するｖＳＡは、サービスに特有であり且つＶＮＯに特有である。そして、ネットワーク内に第１ＶＮＯ及び第２ＶＮＯがある場合、両者は似た種類のサービスを提供し、それぞれは、それらの自分の（１つ又は複数の）ｖＳＡを有するだろう。これらの２つのＶＮＯのポリシー間の相違のために、第１ＶＮＯに対するｖＳＡは、第２ＶＮＯに対するｖＳＡと比較して、異なるリソース管理の決定をとるだろう。
【００６７】
それぞれのユーザが、何らかの方法で、例えばＶＮＯによって提供されるアプリケーションプログラム（「ａｐｐ」）をダウンロードすることによって、サービスを申し込むことを仮定し得る。ユーザ（加入者）は、彼又は彼女のユーザ装置からサービス要求を送信することによって、サービスセッションを開始する。仮想サービスアンカーは、この仮想オペレータの加入者からの少なくとも１つのサービス要求がある時だけ、供給される。一の仮想サービスアンカーは、異なる無線アクセス技術における複数の物理基地局又はアクセスポイントと関係（又は接続）し得る。一の物理基地局又はアクセスポイントは、複数の仮想サービスアンカーによって共有され得る。仮想サービスアンカーと物理基地局との間の固定されたマッピングは、不要である。
【００６８】
上述した導入において説明されたＢＢＵプール２１又は２２に関して、ＢＢＵプールは、主に物理無線リソース管理を担当する一方で、ｖＳＡ２６は、特定のＶＮＯの特定のサービスに対する仮想リソース管理を取り扱う。この意味で、ｖＳＡは、ＢＢＵプールにおいて提供されるか又は他の方法で提供されるＲＲＭ機能と相互作用する「より高い」層のエンティティとして考えられる。ｖＳＡは、ＢＢＵプール２１，２２と同じ中央局２と物理的に同じ場所に位置し得る場合でも、ｖＳＡは、（あるとしても）ＢＢＵプールとは独立する論理エンティティである。例えば、両者は、クラウド内の、即ちサーバ上又はサーバファーム内の、プロセッサ上で走るソフトウェアによって提供され得る。ｖＳＡ２６はサービスに特有であり且つＶＮＯに特有なので、ｖＳＡとＢＢＵプールとの間に固定されたマッピングはない。
【００６９】
しかし、上述したようにｐＢＳが部分的にクラウド内に実装され得るけれども、本発明は、また、従来の「独立型」基地局及び／又はＤ２Ｄに対して構成されるユーザ装置と共に使用され得ることに留意されたい。
【００７０】
仮想サービスアンカーは、仮想オペレータの加入者を「追いかけ」得る。例えば、加入者が移動する時（例えば、仮想サービスアンカーと関係する現在の物理基地局のカバレッジから出る）、仮想サービスアンカーは、異なる物理基地局又はアクセスポイントと結びついて、加入者に対して十分なカバレッジ及び能力を提供し得る。
【００７１】
提案される案では、２つのレベルのリソース管理がある。
【００７２】
（ａ）レベル１  サービスアンカー（ｖＳＡ２６）において
【００７３】
このリソース管理レベルは、仮想オペレータの加入者のためのみであり、ここで、リソース管理が、例えばセッション及びサービスクラス（仮想オペレータのポリシーに基づく）の推定される完了時間というアプリケーション層の特徴を考慮しながら、これらの加入者は、ユーザ装置上でアプリケーションを動作させてサービスを得る。このレベルの鍵となる機能は、関連する物理基地局を調整することである。
【００７４】
（ｂ）レベル２  物理基地局又はアクセスポイント（ｐＢＳ１４）において
【００７５】
このレベルは、ｐＢＳとユーザ装置との間の無線接続の物理接続状態を考慮して、ｐＢＳ／アクセスポイントのカバー領域（セル又は範囲）内の全てのユーザに対して適用される。ここで、リソーススケジューリングの決定は、レベル１のリソース管理コンポーネントからの要求を満たすように行われる。
【００７６】
より具体的には、リソース管理のこれらのレベルは、図５に示されるサービス要求手順及び図６に示されるデータ配信セッションを届けるための手順を提供する。
【００７７】
サービス要求手順
【００７８】
この手順では、仮想オペレータのユーザ装置１２は、仮想オペレータのｖＳＡ２６に対してサービス要求を開始する。ユーザ装置１２は、人間であるユーザのユーザ機器であり、例えば、携帯電話又はタブレット又はコンピュータであり得る。それは、また、マシンタイプ装置であり得る。ユーザ装置を操作することにより、ユーザは、サービス要求が生成される結果をもたらす。要求されるサービスは、例えば仮想オペレータの店で入手可能な特定のビデオストリームのためという、仮想オペレータによって提供されるサービスの一部である特定の内容の配信であり得る。
【００７９】
ユーザ装置からの及びユーザ装置に対する全ての通信は、基地局（物理基地局又はｐＢＳ１４、又はそれは代わりにアクセスポイントであり得る）を介して無線で行われる。普通、一のユーザ装置からのサービス要求は、一の特定の基地局（通常最近接）に向けられるだろうが、ユーザ装置が複数のｐＢＳと通信することが可能である。
【００８０】
図５は、下記のステップを含むサービス要求手順の例を示す。
【００８１】
開始のステップＳ１０において、その所有者が仮想オペレータのサービスの加入者であるユーザ装置１２は、ｐＢＳ１４を介して、仮想オペレータのｖＳＡ２６に対してサービス要求を送信して、仮想オペレータによって提供されるサービスの一部としての特定のコンテンツにアクセスする。このサービス要求（コンテンツアクセス要求とも称される）は、暗に又は明示的に、要求の対象であるサービスを提供する仮想ネットワークを識別する。暗に指示する例は、要求に含まれており、特定の仮想ネットワークの加入者として送信者を識別する加入者ＩＤであろう。明示的に指示する例は、サービス要求が、仮想オペレータによって提供され且つ特有であるアプリケーションプログラム（「ａｐｐ」）を用いて生成されるかどうかであろう。結果として、ｐＢＳは、要求をどこに進めるべきかを知る。ｖＳＡはネットワークにおいてｐＢＳよりも高いレベルにあるので、ｐＢＳはバックホールネットワークを介して、適切なｖＳＡに対してサービス要求を進める。
【００８２】
ユーザ装置１２の測定レポートは、要求に含まれて、近隣の基地局及びアクセスポイントで受信される信号の品質を示し得る。ユーザ装置の位置情報も、例えばユーザ装置のＧＰＳ機能から分かれば、含まれ得る。
【００８３】
ステップＳ１２において、要求を受信して、ｖＳＡ２６は、要求されたコンテンツを検査して、最も適切なコンテンツデリバリノード又はノード（例えば、送信時間の意味で最近接の利用可能なノード）を見つける。その後、ステップＳ１４において、ｖＳＡ２６は、コンテンツの配信セッションに対して、適切なｐＢＳを識別する。適切なｐＢＳの決定は、測定及びユーザ装置の位置情報及び加入者のプロファイル及び／又は仮想オペレータのポリシー等に基づき得る。通常、ユーザ装置に対して近隣の一又は複数のｐＢＳが選択され得る。ｐＢＳは、複数の仮想ネットワークの内の何れかの使用に対して、利用可能な共通のリソースとしてみなされ得る。
【００８４】
ステップＳ１６において、次に、ｖＳＡ２６は、要求（又はｖＳＡにおいて要求から生成された対応するメッセージ）を、バックホールネットワーク上で、識別されたコンテンツデリバリノード又はノード３０に対して進める。識別されたｐＢＳのＩＤ及びアドレス情報は、メッセージに含まれる。
【００８５】
次のステップＳ１８において、コンテンツデリバリノード３９は、要求されたコンテンツのファイルサイズと共に、承認メッセージで応答する。
【００８６】
ある代わりのケースでは、それぞれの選択されたノードが要求されたコンテンツの一部を格納する複数のコンテンツデリバリノードが、このコンテンツ配信セッションに対して識別され得る。それらの内のそれぞれは、このノード内に格納される要求されたコンテンツの一部のファイルサイズと共に、要求に対して応答し得る。
【００８７】
後続のステップは、簡単のために、単一のｐＢＳに関して説明される。しかし、ｖＳＡが複数の基地局を使用して、要求されたコンテンツをユーザ装置に対して配信することが可能であることに留意されたい。そのように、下記の「識別されたｐＢＳ」は、複数の基地局と称されることが可能であるとして理解されたい。
【００８８】
ステップＳ２０において、コンテンツデリバリノードからの応答を受信して、ｖＳＡ２６は、ファイルサイズ及び識別されたｐＢＳの接続品質に基づいて、推定される配信時間を計算する。複数のコンテンツデリバリノードの場合、ｖＳＡ２６は、それぞれのコンテンツデリバリノードにおいて利用可能なコンテンツに対する推定される配信時間を計算し得る。
【００８９】
次に、ステップＳ２２において、ｖＳＡ２６は、識別されたｐＢＳに対して要求を進める。識別されたコンテンツデリバリノードのＩＤ及びアドレス情報は、コンテンツデリバリノードにおいて利用可能なコンテンツに対する推定される配信時間と共に、メッセージに含まれている。
【００９０】
Ｓ２４において、ｐＢＳ１４は、要求を承認する。次に、ステップＳ２６において、データの配信経路が、コンテンツデリバリノードからｐＢＳまで、更にユーザ装置１２まで設定され得る。
【００９１】
複数のコンテンツデリバリノードの場合、複数の経路が、ｐＢＳとコンテンツデリバリノードとの間に設定され得る。どのようにデータをユーザ装置１２に配信するかは、ｐＢＳ次第であり得る。コンテンツの配信は、コンテンツデリバリノード（又はそれぞれのコンテンツデリバリノード）からｐＢＳへ直接であり、データは仮想サービスアンカーを介して送られない。
【００９２】
ｖＳＡ２６は、残りのファイルサイズ及び接続品質に基づいて、推定される配信時間と共に、ｐＢＳ１４を更新し得る。
【００９３】
調整されたデータの配信
【００９４】
この手順は、ｖＳＡ２６と、ユーザ装置１２のデータ配信セッションのための他の関係するノードとの間の調整計画（ｓｃｈｅｍｅ）である。一例の手順が、図６に示される。ここで、図の上端における鎖線によって示されるように、ユーザ装置１２は、コンテンツに対するデータ配信セッションに携わり、２つのｐＢＳ１４及び１４’からデータを受け取りながら、仮想オペレータによって提供されるサービスの一部として要求する。
【００９５】
一のｖＳＡ２６は、ｐＢＳ１４，１４’（ｐＢＳ１及びｐＢＳ２ともラベル付けされる）及び複数のコンテンツデリバリノード３０（この例では１つだけ示される）と関係するデータ配信を調整している。データ配信セッションの間、ネットワークノードは、ステップＳ３０及びＳ３２によって示されるように、ｖＳＡに対してフィードバックを提供する。ｖＳＡ２６は、ユーザ装置１２、ｐＢＳ１４，１４’及びコンテンツデリバリノード３０によって、頻繁に更新されると考えられる。
【００９６】
フィードバックのいくつか例は下記を含む：
【００９７】
−ユーザ装置１２から：１つ又は複数のｐＢＳに関する接続状態（検出された干渉を含む）、パケット損失及び待ち時間のようなデータ配信のＱｏＳ
【００９８】
−ｐＢＳ１４及び１４’から：負荷状態（又は利用可能な能力）、リソースの使用効率、検出された干渉
【００９９】
−コンテンツデリバリノード３０から：負荷状態、パケット損失及び待ち時間のようなデータ配信のＱｏＳ
【０１００】
ユーザ装置１２からのフィードバックは、図６のｐＢＳ１４を介して送信される。ことに留意されたい。一方、コンテンツデリバリノード３０からのフィードバックは、バックホールネットワーク上で、ｖＳＡ２６に直接送信される。
【０１０１】
リソーススケジューリング（リソースの割り当て）の実行において、仮想サービスアンカーは、仮想オペレータによって設定されるポリシーに従う。そのようなポリシーの一例は、「最も経済的な方法で配信すること（即ち、最も安い）」であり得る。このポリシーに基づいて、ｖＳＡは、コンテンツ配信に関係するｐＢＳとして、基本的なＱｏＳ要求を満たす限り、ＬＴＥ基地局の代わりにＷｉ−Ｆｉ（登録商標）アクセスポイントを選択し得る。又は、ｖＳＡは、ｐＢＳに指示して、サービスに対して最も経済的な技術を使用し得る（例えば、Ｄ２Ｄ通信、又はＬＴＥ−Ｕのような許可されていないスペクトル）。
【０１０２】
Ｓ３０及びＳ３２におけるフィードバック情報と、仮想オペレータのポリシーとに基づいて、ステップＳ３４において、ｖＳＡ２６は、それぞれの関係するｐＢＳに対する好ましいリソーススケジューリングの決定を成し遂げて、ユーザ装置に対して最高の性能（例えば、スループット、データ速度）を達成する。次に、ステップＳ３６において、ｖＳＡは、関係するｐＢＳ１４及び１４’に対して、関係するユーザ装置の推定される性能及びセッションに対する推定されるセッション完了時間と一緒に、提案を送信する。
【０１０３】
ステップＳ３８において、そのような提案を受け取ると、それぞれのｐＢＳ１４、１４’は、利用可能なリソースを考慮しながら（可能であれば、どのＲＡＴを用いてユーザ装置と通信するかのＲＡＴの選択を含む）、好ましいスケジューリングに従うことが可能であるか否かを査定するだろう。ここで、ｐＢＳは、また、仮想オペレータに加入しているこれらとは別に、他のユーザ機器を考慮して、それに従って、スケジューリングの決定を行い得る（例えば、最高の全てのリソース使用効率を目的として）。ステップＳ４０において、次に、フィードバック手順の一部として、それぞれのｐＢＳは、ｐＢＳが他のｖＳＡ２６からの要求を含めて自身に対して利用可能な情報に基づいて配信できると考えるリソースの割り当てである「達成可能なスケジューリングの決定」を、ｖＳＡ２６に通知する。次に、複数のｖＳＡからの、ことによると矛盾する要求に基づいてスケジューリングの決定（又は勧告）を行うことは、ｐＢＳ次第である。Ｓ４２において、次に、ｖＳＡは、推定される性能及びセッション完了時間を用いて、コンテンツデリバリノード３０を更新する。そのようなフィードバックは、コンテンツデリバリノード３０が、リソース管理及び可能であれば負荷平衡に対して適切な行動／決定を行うことを支援する。
【０１０４】
ｐＢＳからのフィードバックされた情報に基づいて、Ｓ４４において、ｖＳＡ２６は、その自身が提案したスケジューリングの決定及びそれぞれのｐＢＳの達成可能な決定との間で、少しでもあるとしたら差／相違を検査し、異なるスケジューリングの決定から生ずる性能の相違を識別する。次に、必要であれば、ｖＳＡは、妥協したゴールと共に、ユーザ毎に基づいて、又は、同じオペレータの複数のユーザに対してまとめての何れかで、好ましいスケジューリングを調整する（例えば、ユーザ装置が達成する２番目に最高の性能）。この提案は、ｐＢＳによって受け入れられるより良い機会を有するだろう。ＶＮＯのポリシーが可能な限り最高のユーザの経験として設定されているならば、個々のユーザに対する一例は、ｖＳＡがユーザのサービスに対して最高のサービスを得る試みを行うことであろう。しかし、一のｐＢＳにおける利用可能なリソースの制限によって（例えば、一のｐＢＳは高いＱｏＳ要求を有するいくつかのＵＥにサービスしなくてはならない）、このユーザは、ｐＢＳにおける制限されたリソースでスケジューリングされ得る。このフィードバックに基づいて、ｖＳＡは、例えば低減した解像度でビデオをストリーミングする結果をもたらし得る低いデータ速度に設定して、妥協として、そのスケジューリング要求を下げるだろう。このように、ｖＳＡ及びｐＢＳは調整して、そのｐＢＳによってサービスされる現在の全てのユーザに対してｐＢＳにおける受け入れ可能なスケジューリングに到達する。
【０１０５】
ステップＳ４６において、ｖＳＡ２６は、関係するｐＢＳ１４，１４’に対して、提案（修正されたスケジューリングの決定）を送信する。Ｓ５０において、更に、ｖＳＡ２６は、コンテンツデリバリノード３０に対して、推定される性能及びセッション完了時間を通知する。
【０１０６】
それぞれのｐＢＳは、ｖＳＡからの修正されたリソースの割り当て（スケジューリングの決定）を受け入れるか又は少なくとも考慮する。一度受け入れると、コンテンツデリバリノードからのｐＢＳに対するコンテンツの配信が、開始し得る。図６には示されていないけれども、上述した調整手順は繰り返されて、スケジューリングの調整を改善して、仮想オペレータの関係するユーザ装置だけでなく全てのネットワーク性能に利益を与えて、最適化されたリソース管理をもたらし得る。
【０１０７】
これは、コンテンツの配信中に、間隔をあけてスケジューリングを繰り返すことを含む。そのような繰り返しに対する時間スケールは、一般に、物理層のスケジューリング間隔（例えば数ミリ秒）よりも大きくあるべきであり、数秒であって、フィードバックに依存して変化し得る。（例えば、ｖＳＡの提案するスケジューリングの決定とｐＢＳにおける利用可能なスケジューリングとの間の差／相違が十分に小さい時にはより頻繁でなくなる）このようにスケジューリングの再訪問の結果は、個々のｐＢＳの負荷又は無線接続の条件変化として、データ配信において、更に（又は異なる）ｐＢＳを関係させることを含み得る。
【０１０８】
特に、複数の仮想オペレータが同じリソースを共有する場合には、そのような調整／交渉は、自動的にリソースの割り当てを最適化し且つ最適で調和した動作環境を達成するために特に重要である。
【０１０９】
要約すると、本発明の実施形態は、「クラウド内」に少なくとも部分的に存在し且つシステムに対して利用可能である共通のリソースを用いて定義された複数の仮想ネットワークの内の何れかを介してサービスを受け取るように配置されるユーザ装置１２を備えるクラウドに基づく無線通信システム１を提供できる。共通のリソースは、複数の基地局（物理基地局又はアクセスポイント）１４と、少なくとも１つの基地局１４を介して仮想ネットワークの内の何れかと無線接続して、仮想ネットワークからユーザ装置のユーザが加入している特定のサービスを受け取るように配置されるユーザ装置１２とを含む。仮想ネットワークには仮想サービスアンカー又はｖＳＡ２６があり、それぞれの仮想サービスアンカーは、その仮想ネットワークによって提供されるそれぞれのサービスに対して提供される。それぞれのｖＳＡ２６は、そのｖＳＡのサービスにおいてアクセスされるコンテンツを指示する、ユーザ装置１２からのコンテンツアクセス要求を受け取り、コンテンツはクラウド内の少なくとも１つのコンテンツデリバリノードによって格納される。ｖＳＡ２６は、コンテンツアクセス要求に応答して、共通のリソースを用いて、第１リソース割り当てを実行し、これは、指示されたコンテンツに基づいて、基地局１４に対するサービス要求と共に、少なくとも１つのコンテンツデリバリノードに対してサービス要求を送信することを含む。複数のｖＳＡ２６からのサービス要求に応答して、それぞれの基地局１４は、第２リソース割り当てを実行して、その基地局１４と無線接続しているそれぞれのユーザ装置１２に対してサービスを提供する。
【０１１０】
このようにして、本発明の実施形態は、複数レベルの中央サービス的な管理方法を、特に、対応する仮想オペレータのみの加入者を表し、アプリケーション層の特徴を考慮しながら、関係する物理基地局を調整するサービスアンカーレベルにおいて、提供し得る。本発明のより具体的な実施形態は、仮想オペレータを含む複数のオペレータによって共有される仮想化されたネットワークに基づいたクラウド内の複数レベルの中央サービス的な管理メカニズムを提供する。
【０１１１】
サービス要求手順が提案されて、仮想オペレータのユーザ装置によって立ち上げられた要求に対して、ｖＳＡが適切なｐＢＳ及びコンテンツデリバリノードを識別することを許容する。また、ｖＳＡが関係するノード間でユーザ装置のデータ配信セッションを調整することを可能する調整方法が、提案される。
【０１１２】
本発明の範囲内で様々な変形が可能である。
【０１１３】
上述したアーキテクチャは仮想ネットワークだけを含むけれども、本発明は、ＶＮＯ及び非ＶＮＯの両方を含む複数のオペレータによって共有される効率的なネットワークを許容して、専用（非仮想）ネットワークと共存可能である。専用ネットワークのユーザはｖＳＡを提供される必要はないが、少なくとも仮想ネットワークのユーザに対してｖＳＡを提供することは、ＶＮＯのポリシーに基づいて個々のユーザに対するＱｏＳを保証しながら、ネットワークの使用効率を改善するだろう。
【０１１４】
上述されたサービス要求手順及び調整方法は、組み合わされるか、又は、それらは個々に使用され得る。
【０１１５】
産業上の利用可能性
【０１１６】
本発明の長所は、第１に、アプリケーション層（即ち、コンテンツデリバリノード）からアクセスネットワーク層（即ち、物理基地局又はアクセスポイント）へのノードの操作を調整することによって、リソース管理を最適化することを含む。第２に、提案されるリソース管理は、仮想オペレータの関係するユーザ装置だけでなく全てのネットワーク性能に利益をもたらす自動調整を許容する。
【図１】
2016082569.tif 000003
【図２】
2016082569.tif 000004
【図３】
2016082569.tif 000005
【図４Ａ】
2016082569.tif 000006
【図４Ｂ】
2016082569.tif 000007
【図５】
2016082569.tif 000008
【図６】
2016082569.tif 000009