JP2015524186A - フレキシブルなネットワーク共有 - Google Patents

Abstract

共通の無線アクセスネットワーク（ＲＡＮ）リソースのフレキシブルな共有は、割り当てられていないリソースをプールすることができる。たとえば、ネットワークリソースの共有は、静的であることが可能であり、たとえば、共有契約は、ネットワークリソースのうちで、契約における変更を伴わずに修正されることが不可能である一定割合の割り当てを定義することができる。ネットワークリソースの共有は、動的であることも可能であり、リアルタイムベースで被ホスト側オペレータのキャパシティーニーズに対応することができる。

Description

本発明は、フレキシブルなネットワーク共有に関する。

関連出願の相互参照
本出願は、２０１２年７月１９日に出願された米国特許仮出願第６１／６７３，５２９号明細書、および２０１２年５月９日に出願された米国特許仮出願第６１／６４４，９８６号明細書の利益を主張するものである。これらの仮出願の内容は、それらの全体が参照によって本明細書に組み込まれている。

モバイルネットワークオペレータは、モバイルブロードバンドトラフィックにおける増大に起因する自分たちのネットワーク上での需要の高まりに対処するためのコスト効率のよい方法を探している。いくつかのソリューションは、屋内カバレッジの増大、スモールセル、ＬＴＥ、ＩＰイーサネットバックホール、および／またはより多くのスペクトルを伴う。しかしながら、これらのソリューションは、さらなる資本支出（Ｃａｐｅｘ）を伴う。

ネットワークおよびネットワークインフラストラクチャーを共有することは、オペレータが、モバイルネットワークに関する高い展開コストを、特にロールアウトフェーズにおいて共有することを可能にすることができる。既存の無線アクセスネットワーク（ＲＡＮ）に対する強化を共有するというソリューションは、かなりの節減をもたらそうと試みているように思われる。しかしながら、割り当てられていないリソースをプールすることによって共通のＲＡＮリソースを効率よく共有することに対する必要性が引き続き存在している。

フレキシブルなネットワーク共有のためのシステム、方法、および手段が開示される。割り当てられていないリソースをプールすることによって、共通の無線アクセスネットワーク（ＲＡＮ）リソースが共有されることが可能である。

ネットワークリソースの共有は、静的であることが可能であり、たとえば、共有契約は、ネットワークリソースのうちで、その契約における変更を伴わずに修正されることが不可能である一定割合の割り当てを定義することができる。別の例においては、ネットワークリソースの共有は、動的であることが可能である。ネットワーク共有スキームは、リアルタイムベースで被ホスト側オペレータのキャパシティーニーズに対応するのに十分なだけフレキシブルであることが可能である。ネットワーク、たとえばＲＡＮオペレータは、最も高い入札額を提示している被ホスト側オペレータにネットワークキャパシティーを売り渡すことができる。

本明細書において開示されている例は、共有ネットワーク要素が、割り当てられるＲＡＮリソースを共有取り決めまたはポリシーに従って提供していることを確認するための手段を提供することができる。本明細書において開示されている例は、共有取り決めまたはポリシーを考慮した場合のオーバーロード状況の表示、およびそれらのオーバーロード状況に際しての潜在的なアクションを提供することができる。

ＲＡＮ共有アーキテクチャーに対する強化が定義されることが可能である。キャパシティーブローカリングアーキテクチャーに関しては、ネットワーク要素が提供されることが可能であり、１または複数のノードに１または複数の機能が付加されることが可能であり、１または複数のインターフェースが提供されることが可能である。ネットワークキャパシティーは、何が共有されることが可能であるか、または、所与の被ホスト側オペレータに割り当てられているネットワークのスライスを表すためにどんなメトリックが使用されることが可能であるかに関して定義されることが可能である。共有ネットワークリソースの使用を判定するための測定が提供されることが可能である。加えて、ネットワーク共有の利得が、関与している関係者、たとえば、ネットワークオペレータ、被ホスト側オペレータ、および／またはＭＶＮＯの観点から定量化されることが可能である。

別々のオペレータを伴う無線アクセスネットワーク（ＲＡＮ）キャパシティーを管理するための方法が提供されることが可能である。共有ＲＡＮリソースを要求するキャパシティークエリー要求が、ブローカレッジコントロールユニット（ＢＣＵ）を介して受信されることが可能である。利用可能な共有ＲＡＮリソースが判定されることが可能である。利用可能な共有ＲＡＮリソースから、要求されている共有ＲＡＮリソースを許可するためのキャパシティークエリー結果が送信されることが可能である。

別々のオペレータを伴う無線アクセスネットワーク（ＲＡＮ）キャパシティーを管理するための方法が提供されることが可能である。共有ＲＡＮリソースを求める要求をキャンセルするためのキャパシティー割り当てキャンセレーション要求が、ブローカレッジコントロールユニット（ＢＣＵ）を介して受信されることが可能である。共有ＲＡＮリソースを求める要求がキャンセルされることが可能であるかどうかが判定されることが可能である。共有ＲＡＮリソースを求める要求がキャンセルされたかどうかを示すためのキャパシティー割り当てキャンセレーション結果が送信されることが可能である。

無線アクセスネットワーク（ＲＡＮ）内のリソース充当をコントロールするための方法が提供されることが可能である。クエリーメッセージが、ＲＡＮノードを介してブローカレッジコントロールユニット（ＢＣＵ）へ送信されることが可能である。応答メッセージが、ＢＣＵから受信されることが可能である。その応答メッセージは、１または複数のオペレータによって共有されることが可能であるＲＡＮリソースのリソース割り当てを含むことができる。１または複数のオペレータからのオペレータが、そのオペレータに関するリソースしきい値よりも多くを使用している可能性があるということがリソース割り当てから判定されることが可能である。たとえば、オペレータは、共有リソースのうちの自分の持ち分よりも多くを使用している可能性がある。

無線アクセスネットワーク（ＲＡＮ）内のリソース充当をコントロールするための方法が提供されることが可能である。割り当て行動レポート（allocation behavior report）が、ネットワークノードからブローカレッジコントロールユニット（ＢＣＵ）を介して受信されることが可能である。割り当て行動ユニットは、オペレータのためのものであることが可能である。リソース割り当てポリシーに準拠していない可能性がある、オペレータに割り当てられたリソースの使用が、割り当て行動レポートから判定されることが可能である。オペレータに割り当てられたリソースの使用を調整するためのメッセージが、オペレータへ送信されることが可能である。

この「発明の概要」は、コンセプトのうちの抜粋したものを、簡略化された形式で紹介するために提供されており、それらのコンセプトは、以降の「発明を実施するための形態」においてさらに開示されている。この「発明の概要」は、特許請求される主題の鍵となる特徴または必要不可欠な特徴を特定することを意図されておらず、特許請求される主題の範囲を限定するために使用されることも意図されていない。さらに、特許請求される主題は、本開示の任意の部分に記載されているあらゆるまたはすべての不利な点を解決するいかなる制限にも限定されるものではない。

例として添付の図面とともに与えられる以降の説明から、より詳細な理解が得られることが可能である。
１または複数の開示されている実施形態が実施されることが可能である例示的な通信システムのシステム図である。 図１Ａにおいて示されている通信システム内で使用されることが可能である例示的なワイヤレス送信／受信ユニット（ＷＴＲＵ）のシステム図である。 図１Ａにおいて示されている通信システム内で使用されることが可能である例示的な無線アクセスネットワークおよび例示的なコアネットワークのシステム図である。 図１Ａにおいて示されている通信システム内で使用されることが可能である別の例示的な無線アクセスネットワークおよび別の例示的なコアネットワークのシステム図である。 図１Ａにおいて示されている通信システム内で使用されることが可能である別の例示的な無線アクセスネットワークおよび別の例示的なコアネットワークのシステム図である。 ユニバーサルテレストリアルラジオアクセスネットワーク（ＵＴＲＡＮ）を共有している２つのモバイルネットワークオペレータを示す図である。 ネットワーク共有のための例示的なゲートウェイコアネットワーク（ＧＣＮ）構成を示す図である。 複数のコアネットワーク（ＣＮ）ノードが単一の無線ネットワークコントローラ（ＲＮＣ）に接続されている例示的なマルチオペレータコアネットワーク（ＭＯＣＮ）を示す図である。 例示的な仮想ネットワークを示す図である。 例示的な仮想ネットワークを示す図である。 例示的な仮想ネットワークを示す図である。 例示的な仮想ネットワークを示す図である。 ロードバランシングのための例示的な方法を示す図である。 ロードバランシングのための別の例示的な方法を示す図である。 例示的なグローバルｅＮＢ ＩＤ／Ｅ−ＵＴＲＡＮセルグローバルＩＤ（ＥＣＧＩ）混乱シナリオを示す図である。 キャパシティーブローカレッジのための例示的なアーキテクチャーを示す図である。 キャパシティーブローカレッジのための別の例示的なアーキテクチャーを示す図である。 キャパシティーブローカレッジのための別の例示的なアーキテクチャーを示す図である。 キャパシティーブローカレッジのための別の例示的なアーキテクチャーを示す図である。 キャパシティーブローカレッジのための別の例示的なアーキテクチャーを示す図である。 キャパシティーブローカレッジのための別の例示的なアーキテクチャーを示す図である。 被ホスト側オペレータとＲＡＮオペレータとの間における例示的なキャパシティークエリー手順メッセージ交換を示す図である。 例示的なキャパシティー割り当て要求および応答手順を示す図である。 被ホスト側オペレータによって開始される例示的なリソースキャンセレーションプロセスを示す図である。 ＲＡＮオペレータによって開始される例示的なリソースキャンセレーションプロセスを示す図である。 例示的な論理課金アーキテクチャーを示す図である。 例示的なオフライン課金システムを示す図である。 例示的なオンライン課金システムを示す図である。 課金情報を送信するための例示的な手順を示す図である。

次いで、説明例についての詳細な説明が、さまざまな図を参照しながら行われる。この説明は、可能な実施態様の詳細な例を提供するが、それらの詳細は、例示的なものであり、けっして本出願の範囲を限定するものではないということを意図されているという点に留意されたい。

図１Ａは、１または複数の開示されている実施形態が実施されることが可能である例示的な通信システム１００の図である。通信システム１００は、コンテンツ、たとえば音声、データ、ビデオ、メッセージング、放送などを複数のワイヤレスユーザに提供するマルチプルアクセスシステムであることが可能である。通信システム１００は、複数のワイヤレスユーザが、ワイヤレス帯域幅を含むシステムリソースの共有を通じてそのようなコンテンツにアクセスすることを可能にすることができる。たとえば、通信システム１００は、１または複数のチャネルアクセス方法、たとえば符号分割多元接続（ＣＤＭＡ）、時分割多元接続（ＴＤＭＡ）、周波数分割多元接続（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、シングルキャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）などを採用することができる。

図１Ａにおいて示されているように、通信システム１００は、ワイヤレス送信／受信ユニット（ＷＴＲＵ）１０２ａ、１０２ｂ、１０２ｃ、および／または１０２ｄ（全体として、または総称して、ＷＴＲＵ１０２と呼ばれる場合がある）、無線アクセスネットワーク（ＲＡＮ）１０３／１０４／１０５、コアネットワーク１０６／１０７／１０９、公衆交換電話網（ＰＳＴＮ）１０８、インターネット１１０、ならびにその他のネットワーク１１２を含むことができるが、開示されている実施形態は、任意の数のＷＴＲＵ、基地局、ネットワーク、および／またはネットワーク要素を想定しているということが理解されるであろう。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのそれぞれは、ワイヤレス環境において動作および／または通信を行うように構成されている任意のタイプのデバイスであることが可能である。例として、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、ワイヤレス信号を送信および／または受信するように構成されることが可能であり、ユーザ機器（ＵＥ）、移動局、固定式または移動式のサブスクライバーユニット、ページャー、セルラー電話、携帯情報端末（ＰＤＡ）、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、ワイヤレスセンサ、家庭用電化製品などを含むことができる。

通信システム１００は、基地局１１４ａおよび基地局１１４ｂを含むこともできる。基地局１１４ａ、１１４ｂのそれぞれは、コアネットワーク１０６／１０７／１０９、インターネット１１０、および／またはネットワーク１１２などの１または複数の通信ネットワークへのアクセスを容易にするために、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの少なくとも１つとワイヤレスにインターフェースを取るように構成されている任意のタイプのデバイスであることが可能である。例として、基地局１１４ａ、１１４ｂは、ベーストランシーバステーション（ＢＴＳ）、Ｎｏｄｅ−Ｂ、ｅＮｏｄｅ Ｂ、ホームＮｏｄｅ Ｂ、ホームｅＮｏｄｅ Ｂ、サイトコントローラ、アクセスポイント（ＡＰ）、ワイヤレスルータなどであることが可能である。基地局１１４ａ、１１４ｂは、それぞれ単一の要素として示されているが、基地局１１４ａ、１１４ｂは、任意の数の相互接続された基地局および／またはネットワーク要素を含むことができるということが理解されるであろう。

基地局１１４ａは、ＲＡＮ１０３／１０４／１０５の一部であることが可能であり、ＲＡＮ１０３／１０４／１０５は、その他の基地局および／またはネットワーク要素（図示せず）、たとえば基地局コントローラ（ＢＳＣ）、無線ネットワークコントローラ（ＲＮＣ）、中継ノードなどを含むこともできる。基地局１１４ａおよび／または基地局１１４ｂは、特定の地理的領域内でワイヤレス信号を送信および／または受信するように構成されることが可能であり、その地理的領域は、セル（図示せず）と呼ばれることがある。セルは、セルセクタへとさらに分割されることが可能である。たとえば、基地局１１４ａに関連付けられているセルは、３つのセクタへと分割されることが可能である。したがって一実施形態においては、基地局１１４ａは、３つのトランシーバ、すなわち、セルのそれぞれのセクタごとに１つのトランシーバを含むことができる。別の実施形態においては、基地局１１４ａは、多入力多出力（ＭＩＭＯ）テクノロジーを採用することができ、したがって、セルのそれぞれのセクタごとに複数のトランシーバを利用することができる。

基地局１１４ａ、１１４ｂは、エアインターフェース１１５／１１６／１１７を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの１または複数と通信することができ、エアインターフェース１１５／１１６／１１７は、任意の適切なワイヤレス通信リンク（たとえば、無線周波数（ＲＦ）、マイクロ波、赤外線（ＩＲ）、紫外線（ＵＶ）、可視光など）であることが可能である。エアインターフェース１１５／１１６／１１７は、任意の適切な無線アクセステクノロジー（ＲＡＴ）を使用して確立されることが可能である。

より具体的には、上述したように、通信システム１００は、マルチプルアクセスシステムであることが可能であり、１または複数のチャネルアクセススキーム、たとえばＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡ、ＳＣ−ＦＤＭＡなどを採用することができる。たとえば、ＲＡＮ１０３／１０４／１０５内の基地局１１４ａ、およびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ユニバーサルモバイルテレコミュニケーションズシステム（ＵＭＴＳ）テレストリアルラジオアクセス（ＵＴＲＡ）などの無線テクノロジーを実施することができ、この無線テクノロジーは、ワイドバンドＣＤＭＡ（ＷＣＤＭＡ）を使用してエアインターフェース１１５／１１６／１１７を確立することができる。ＷＣＤＭＡは、ハイスピードパケットアクセス（ＨＳＰＡ）および／またはエボルブドＨＳＰＡ（ＨＳＰＡ＋）などの通信プロトコルを含むことができる。ＨＳＰＡは、ハイスピードダウンリンクパケットアクセス（ＨＳＤＰＡ）および／またはハイスピードアップリンクパケットアクセス（ＨＳＵＰＡ）を含むことができる。

別の実施形態においては、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、エボルブドＵＭＴＳテレストリアルラジオアクセス（Ｅ−ＵＴＲＡ）などの無線テクノロジーを実施することができ、この無線テクノロジーは、ロングタームエボリューション（ＬＴＥ）および／またはＬＴＥアドバンスト（ＬＴＥ−Ａ）を使用してエアインターフェース１１５／１１６／１１７を確立することができる。

その他の実施形態においては、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、無線テクノロジー、たとえばＩＥＥＥ ８０２．１６（すなわちワールドワイドインターオペラビリティーフォーマイクロウェーブアクセス（ＷｉＭＡＸ））、ＣＤＭＡ２０００、ＣＤＭＡ２０００ １Ｘ、ＣＤＭＡ２０００ ＥＶ−ＤＯ、暫定標準２０００（ＩＳ−２０００）、暫定標準９５（ＩＳ−９５）、暫定標準８５６（ＩＳ−８５６）、グローバルシステムフォーモバイルコミュニケーションズ（ＧＳＭ）、エンハンストデータレートフォーＧＳＭエボリューション（ＥＤＧＥ）、ＧＳＭ ＥＤＧＥ（ＧＥＲＡＮ）などを実施することができる。

図１Ａにおける基地局１１４ｂは、たとえばワイヤレスルータ、ホームＮｏｄｅ Ｂ、ホームｅＮｏｄｅ Ｂ、またはアクセスポイントであることが可能であり、局所的なエリア、たとえば事業所、家庭、乗り物、キャンパスなどにおけるワイヤレス接続を容易にするために、任意の適切なＲＡＴを利用することができる。一実施形態においては、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、ワイヤレスローカルエリアネットワーク（ＷＬＡＮ）を確立するために、ＩＥＥＥ ８０２．１１などの無線テクノロジーを実施することができる。別の実施形態においては、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、ワイヤレスパーソナルエリアネットワーク（ＷＰＡＮ）を確立するために、ＩＥＥＥ ８０２．１５などの無線テクノロジーを実施することができる。さらに別の実施形態においては、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、ピコセルまたはフェムトセルを確立するために、セルラーベースのＲＡＴ（たとえば、ＷＣＤＭＡ、ＣＤＭＡ２０００、ＧＳＭ、ＬＴＥ、ＬＴＥ−Ａなど）を利用することができる。図１Ａにおいて示されているように、基地局１１４ｂは、インターネット１１０への直接接続を有することができる。したがって、基地局１１４ｂは、コアネットワーク１０６／１０７／１０９を介してインターネット１１０にアクセスすることを求められないことが可能である。

ＲＡＮ１０３／１０４／１０５は、コアネットワーク１０６／１０７／１０９と通信状態にあることが可能であり、コアネットワーク１０６／１０７／１０９は、音声、データ、アプリケーション、および／またはボイスオーバーインターネットプロトコル（ＶｏＩＰ）サービスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの１または複数に提供するように構成されている任意のタイプのネットワークであることが可能である。たとえば、コアネットワーク１０６／１０７／１０９は、コール制御、料金請求サービス、モバイルロケーションベースサービス、プリペイドコーリング、インターネット接続、ビデオ配信などを提供すること、および／またはユーザ認証などのハイレベルセキュリティー機能を実行することが可能である。図１Ａにおいては示されていないが、ＲＡＮ１０３／１０４／１０５および／またはコアネットワーク１０６／１０７／１０９は、ＲＡＮ１０３／１０４／１０５と同じＲＡＴまたは異なるＲＡＴを採用しているその他のＲＡＮと直接または間接の通信状態にあることが可能であるということが理解されるであろう。たとえば、コアネットワーク１０６／１０７／１０９は、Ｅ−ＵＴＲＡ無線テクノロジーを利用している可能性があるＲＡＮ１０３／１０４／１０５に接続されていることに加えて、ＧＳＭ無線テクノロジーを採用している別のＲＡＮ（図示せず）と通信状態にあることも可能である。

コアネットワーク１０６／１０７／１０９は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄがＰＳＴＮ１０８、インターネット１１０、および／またはその他のネットワーク１１２にアクセスするためのゲートウェイとして機能することもできる。ＰＳＴＮ１０８は、単純旧式電話サービス（ＰＯＴＳ）を提供する回線交換電話ネットワークを含むことができる。インターネット１１０は、ＴＣＰ／ＩＰインターネットプロトコルスイートにおけるトランスミッションコントロールプロトコル（ＴＣＰ）、ユーザデータグラムプロトコル（ＵＤＰ）、およびインターネットプロトコル（ＩＰ）など、共通の通信プロトコルを使用する相互接続されたコンピュータネットワークおよびデバイスからなるグローバルシステムを含むことができる。ネットワーク１１２は、その他のサービスプロバイダによって所有および／または運営されている有線またはワイヤレスの通信ネットワークを含むことができる。たとえば、ネットワーク１１２は、ＲＡＮ１０３／１０４／１０５と同じＲＡＴまたは異なるＲＡＴを採用している可能性がある１または複数のＲＡＮに接続されている別のコアネットワークを含むことができる。

通信システム１００内のＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちのいくつかまたはすべては、マルチモード機能を含むことができ、すなわち、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、別々のワイヤレスリンクを介して別々のワイヤレスネットワークと通信するために複数のトランシーバを含むことができる。たとえば、図１Ａにおいて示されているＷＴＲＵ１０２ｃは、セルラーベースの無線テクノロジーを採用している可能性がある基地局１１４ａ、およびＩＥＥＥ ８０２無線テクノロジーを採用している可能性がある基地局１１４ｂと通信するように構成されることが可能である。

図１Ｂは、例示的なＷＴＲＵ１０２のシステム図である。図１Ｂにおいて示されているように、ＷＴＲＵ１０２は、プロセッサ１１８、トランシーバ１２０、送信／受信要素１２２、スピーカー／マイクロフォン１２４、キーパッド１２６、ディスプレイ／タッチパッド１２８、取り外し不能メモリ１３０、取り外し可能メモリ１３２、電源１３４、グローバルポジショニングシステム（ＧＰＳ）チップセット１３６、およびその他の周辺機器１３８を含むことができる。ＷＴＲＵ１０２は、一実施形態との整合性を保持しながら、上述の要素どうしの任意の下位組合せを含むことができるということが理解されるであろう。また実施形態は、基地局１１４ａおよび１１４ｂ、ならびに／または、基地局１１４ａおよび１１４ｂが相当することが可能であるノード（数ある中でも、トランシーバステーション（ＢＴＳ）、Ｎｏｄｅ−Ｂ、サイトコントローラ、アクセスポイント（ＡＰ）、ホームｎｏｄｅ−Ｂ、エボルブドホームｎｏｄｅ−Ｂ（ｅＮｏｄｅＢ）、ホームエボルブドｎｏｄｅ−Ｂ（ＨｅＮＢ）、ホームエボルブドｎｏｄｅ−Ｂゲートウェイ、およびプロキシノードなどであるが、それらには限定されない）は、図１Ｂにおいて示され本明細書において説明されている要素のうちのいくつかまたはすべてを含むことができるということを想定している。

プロセッサ１１８は、汎用プロセッサ、専用プロセッサ、従来型プロセッサ、デジタルシグナルプロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと関連付けられている１もしくは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、その他の任意のタイプの集積回路（ＩＣ）、状態マシンなどであることが可能である。プロセッサ１１８は、信号コーディング、データ処理、パワー制御、入力／出力処理、および／または、ＷＴＲＵ１０２がワイヤレス環境において機能することを可能にするその他の任意の機能を実行することができる。プロセッサ１１８は、トランシーバ１２０に結合されることが可能であり、トランシーバ１２０は、送信／受信要素１２２に結合されることが可能である。図１Ｂは、プロセッサ１１８とトランシーバ１２０を別々のコンポーネントとして示しているが、プロセッサ１１８とトランシーバ１２０は、電子パッケージまたはチップ内にともに統合されることが可能であることが理解されるであろう。

送信／受信要素１２２は、エアインターフェース１１５／１１６／１１７を介して、基地局（たとえば、基地局１１４ａ）に信号を送信するように、または基地局（たとえば、基地局１１４ａ）から信号を受信するように構成されることが可能である。たとえば、一実施形態においては、送信／受信要素１２２は、ＲＦ信号を送信および／または受信するように構成されているアンテナであることが可能である。別の実施形態においては、送信／受信要素１２２は、たとえば、ＩＲ信号、ＵＶ信号、または可視光信号を送信および／または受信するように構成されているエミッタ／検知器であることが可能である。さらに別の実施形態においては、送信／受信要素１２２は、ＲＦ信号および光信号の両方を送信および受信するように構成されることが可能である。送信／受信要素１２２は、ワイヤレス信号の任意の組合せを送信および／または受信するように構成されることが可能であることが理解されるであろう。

加えて、送信／受信要素１２２は、図１Ｂにおいては単一の要素として示されているが、ＷＴＲＵ１０２は、任意の数の送信／受信要素１２２を含むことができる。より具体的には、ＷＴＲＵ１０２は、ＭＩＭＯテクノロジーを採用することができる。したがって、一実施形態においては、ＷＴＲＵ１０２は、エアインターフェース１１５／１１６／１１７を介してワイヤレス信号を送信および受信するために、複数の送信／受信要素１２２（たとえば、複数のアンテナ）を含むことができる。

トランシーバ１２０は、送信／受信要素１２２によって送信されることになる信号を変調するように、また、送信／受信要素１２２によって受信される信号を復調するように構成されることが可能である。上述したように、ＷＴＲＵ１０２は、マルチモード機能を有することができる。したがってトランシーバ１２０は、ＷＴＲＵ１０２が、たとえばＵＴＲＡおよびＩＥＥＥ ８０２．１１など、複数のＲＡＴを介して通信することを可能にするために複数のトランシーバを含むことができる。

ＷＴＲＵ１０２のプロセッサ１１８は、スピーカー／マイクロフォン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８（たとえば、液晶ディスプレイ（ＬＣＤ）ディスプレイユニットもしくは有機発光ダイオード（ＯＬＥＤ）ディスプレイユニット）に結合されることが可能であり、そこからユーザ入力データを受け取ることができる。プロセッサ１１８は、ユーザデータをスピーカー／マイクロフォン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８へ出力することもできる。加えて、プロセッサ１１８は、取り外し不能メモリ１３０および／または取り外し可能メモリ１３２など、任意のタイプの適切なメモリからの情報にアクセスすること、およびそれらのメモリにデータを格納することが可能である。取り外し不能メモリ１３０は、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、ハードディスク、またはその他の任意のタイプのメモリストレージデバイスを含むことができる。取り外し可能メモリ１３２は、サブスクライバーアイデンティティーモジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカードなどを含むことができる。その他の実施形態においては、プロセッサ１１８は、サーバまたはホームコンピュータ（図示せず）上など、ＷＴＲＵ１０２上に物理的に配置されていないと言えるメモリからの情報にアクセスすること、およびそのメモリにデータを格納することが可能である。

プロセッサ１１８は、電源１３４から電力を受け取ることができ、また、ＷＴＲＵ１０２内のその他のコンポーネントへの電力を分配および／または制御するように構成されることが可能である。電源１３４は、ＷＴＲＵ１０２に電力供給するための任意の適切なデバイスであることが可能である。たとえば、電源１３４は、１または複数の乾電池（たとえば、ニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉ−ｉｏｎ）など）、太陽電池、燃料電池などを含むことができる。

プロセッサ１１８は、ＧＰＳチップセット１３６に結合されることも可能であり、ＧＰＳチップセット１３６は、ＷＴＲＵ１０２の現在位置に関する位置情報（たとえば、経度および緯度）を提供するように構成されることが可能である。ＷＴＲＵ１０２は、ＧＰＳチップセット１３６からの情報に加えて、またはその情報の代わりに、基地局（たとえば、基地局１１４ａ、１１４ｂ）からエアインターフェース１１５／１１６／１１７を介して位置情報を受信すること、および／または複数の近隣の基地局から受信されている信号のタイミングに基づいて自分の位置を判定することが可能である。ＷＴＲＵ１０２は、一実施形態との整合性を保持しながら、任意の適切な位置判定方法を通じて位置情報を得ることができるということが理解されるであろう。

プロセッサ１１８は、その他の周辺機器１３８にさらに結合されることが可能であり、その他の周辺機器１３８は、さらなる特徴、機能、および／または有線接続もしくはワイヤレス接続を提供する１または複数のソフトウェアモジュールおよび／またはハードウェアモジュールを含むことができる。たとえば、周辺機器１３８は、加速度計、ｅコンパス、衛星トランシーバ、デジタルカメラ（写真またはビデオ用）、ユニバーサルシリアルバス（ＵＳＢ）ポート、振動デバイス、テレビジョントランシーバ、ハンドフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）ラジオユニット、デジタルミュージックプレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザなどを含むことができる。

図１Ｃは、一実施形態によるＲＡＮ１０３およびコアネットワーク１０６のシステム図である。上述したように、ＲＡＮ１０３は、エアインターフェース１１５を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するためにＵＴＲＡ無線テクノロジーを採用することができる。ＲＡＮ１０３は、コアネットワーク１０６と通信状態にあることも可能である。図１Ｃにおいて示されているように、ＲＡＮ１０３は、Ｎｏｄｅ−Ｂ１４０ａ、１４０ｂ、１４０ｃを含むことができ、これらのＮｏｄｅ−Ｂはそれぞれ、エアインターフェース１１５を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するために１または複数のトランシーバを含むことができる。Ｎｏｄｅ−Ｂ１４０ａ、１４０ｂ、１４０ｃはそれぞれ、ＲＡＮ１０３内の特定のセル（図示せず）に関連付けられることが可能である。ＲＡＮ１０３は、ＲＮＣ１４２ａ、１４２ｂを含むこともできる。ＲＡＮ１０３は、一実施形態との整合性を保持しながら、任意の数のＮｏｄｅ−ＢおよびＲＮＣを含むことができるということが理解されるであろう。

図１Ｃにおいて示されているように、Ｎｏｄｅ−Ｂ１４０ａ、１４０ｂは、ＲＮＣ１４２ａと通信状態にあることが可能である。加えて、Ｎｏｄｅ−Ｂ１４０ｃは、ＲＮＣ１４２ｂと通信状態にあることが可能である。Ｎｏｄｅ−Ｂ１４０ａ、１４０ｂ、１４０ｃは、Ｉｕｂインターフェースを介してそれぞれのＲＮＣ１４２ａ、１４２ｂと通信することができる。ＲＮＣ１４２ａ、１４２ｂは、Ｉｕｒインターフェースを介して互いに通信状態にあることが可能である。ＲＮＣ１４２ａ、１４２ｂのそれぞれは、自分が接続されているそれぞれのＮｏｄｅ−Ｂ１４０ａ、１４０ｂ、１４０ｃを制御するように構成されることが可能である。加えて、ＲＮＣ１４２ａ、１４２ｂのそれぞれは、その他の機能、たとえば、アウターループパワー制御、負荷制御、アドミッション制御、パケットスケジューリング、ハンドオーバー制御、マクロダイバーシティー、セキュリティー機能、データ暗号化などを実行またはサポートするように構成されることが可能である。

図１Ｃにおいて示されているコアネットワーク１０６は、メディアゲートウェイ（ＭＧＷ）１４４、モバイルスイッチングセンター（ＭＳＣ）１４６、サービングＧＰＲＳサポートノード（ＳＧＳＮ）１４８、および／またはゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）１５０を含むことができる。上述の要素のうちのそれぞれは、コアネットワーク１０６の一部として示されているが、これらの要素のうちのいずれかの要素が、コアネットワークオペレータ以外のエンティティーによって所有および／または運営されることも可能であるということが理解されるであろう。

ＲＡＮ１０３内のＲＮＣ１４２ａは、ＩｕＣＳインターフェースを介してコアネットワーク１０６内のＭＳＣ１４６に接続されることが可能である。ＭＳＣ１４６は、ＭＧＷ１４４に接続されることが可能である。ＭＳＣ１４６およびＭＧＷ１４４は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと、従来の地上通信線通信デバイスとの間における通信を容易にするために、ＰＳＴＮ１０８などの回線交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供することができる。

ＲＡＮ１０３内のＲＮＣ１４２ａは、ＩｕＰＳインターフェースを介してコアネットワーク１０６内のＳＧＳＮ１４８に接続されることも可能である。ＳＧＳＮ１４８は、ＧＧＳＮ１５０に接続されることが可能である。ＳＧＳＮ１４８およびＧＧＳＮ１５０は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと、ＩＰ対応デバイスとの間における通信を容易にするために、インターネット１１０などのパケット交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供することができる。

上述したように、コアネットワーク１０６は、ネットワーク１１２に接続されることも可能であり、ネットワーク１１２は、その他のサービスプロバイダによって所有および／または運営されているその他の有線またはワイヤレスのネットワークを含むことができる。

図１Ｄは、一実施形態によるＲＡＮ１０４およびコアネットワーク１０７のシステム図である。上述したように、ＲＡＮ１０４は、エアインターフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するためにＥ−ＵＴＲＡ無線テクノロジーを採用することができる。ＲＡＮ１０４は、コアネットワーク１０７と通信状態にあることも可能である。

ＲＡＮ１０４は、ｅＮｏｄｅ−Ｂ１６０ａ、１６０ｂ、１６０ｃを含むことができるが、ＲＡＮ１０４は、一実施形態との整合性を保持しながら、任意の数のｅＮｏｄｅ−Ｂを含むことができるということが理解されるであろう。ｅＮｏｄｅ−Ｂ１６０ａ、１６０ｂ、１６０ｃはそれぞれ、エアインターフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するために１または複数のトランシーバを含むことができる。一実施形態においては、ｅＮｏｄｅ−Ｂ１６０ａ、１６０ｂ、１６０ｃは、ＭＩＭＯテクノロジーを実施することができる。したがってｅＮｏｄｅ−Ｂ１６０ａは、たとえば、ＷＴＲＵ１０２ａにワイヤレス信号を送信するために、およびＷＴＲＵ１０２ａからワイヤレス信号を受信するために、複数のアンテナを使用することができる。

ｅＮｏｄｅ−Ｂ１６０ａ、１６０ｂ、１６０ｃのそれぞれは、特定のセル（図示せず）に関連付けられることが可能であり、無線リソース管理決定、ハンドオーバー決定、アップリンクおよび／またはダウンリンクにおけるユーザのスケジューリングなどを取り扱うように構成されることが可能である。図１Ｄにおいて示されているように、ｅＮｏｄｅ−Ｂ１６０ａ、１６０ｂ、１６０ｃは、Ｘ２インターフェースを介して互いに通信することができる。

図１Ｄにおいて示されているコアネットワーク１０７は、モビリティー管理ゲートウェイ（ＭＭＥ）１６２、サービングゲートウェイ１６４、およびパケットデータネットワーク（ＰＤＮ）ゲートウェイ１６６を含むことができる。上述の要素のうちのそれぞれは、コアネットワーク１０７の一部として示されているが、これらの要素のうちのいずれかの要素が、コアネットワークオペレータ以外のエンティティーによって所有および／または運営されることも可能であるということが理解されるであろう。

ＭＭＥ１６２は、Ｓ１インターフェースを介してＲＡＮ１０４内のｅＮｏｄｅ−Ｂ１６０ａ、１６０ｂ、１６０ｃのそれぞれに接続されることが可能であり、コントロールノードとして機能することができる。たとえば、ＭＭＥ１６２は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのユーザを認証すること、ベアラアクティブ化／非アクティブ化、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃの最初の接続中に特定のサービングゲートウェイを選択することなどを担当することができる。ＭＭＥ１６２は、ＲＡＮ１０４と、ＧＳＭまたはＷＣＤＭＡなどのその他の無線テクノロジーを採用しているその他のＲＡＮ（図示せず）との間における切り替えを行うためのコントロールプレーン機能を提供することもできる。

サービングゲートウェイ１６４は、Ｓ１インターフェースを介してＲＡＮ１０４内のｅＮｏｄｅ−Ｂ１６０ａ、１６０ｂ、１６０ｃのそれぞれに接続されることが可能である。サービングゲートウェイ１６４は一般に、ユーザデータパケットをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃへ／ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃから回送および転送することができる。サービングゲートウェイ１６４は、その他の機能、たとえば、ｅＮｏｄｅ Ｂ間でのハンドオーバー中にユーザプレーンを固定すること、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃにとってダウンリンクデータが利用可能である場合にページングをトリガーすること、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのコンテキストを管理および記憶することなどを実行することもできる。

サービングゲートウェイ１６４は、ＰＤＮゲートウェイ１６６に接続されることも可能であり、ＰＤＮゲートウェイ１６６は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと、ＩＰ対応デバイスとの間における通信を容易にするために、インターネット１１０などのパケット交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供することができる。

コアネットワーク１０７は、その他のネットワークとの通信を容易にすることができる。たとえば、コアネットワーク１０７は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと、従来の地上通信線通信デバイスとの間における通信を容易にするために、ＰＳＴＮ１０８などの回線交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供することができる。たとえば、コアネットワーク１０７は、コアネットワーク１０７とＰＳＴＮ１０８との間におけるインターフェースとして機能するＩＰゲートウェイ（たとえば、ＩＰマルチメディアサブシステム（ＩＭＳ）サーバ）を含むことができ、またはそうしたＩＰゲートウェイと通信することができる。加えて、コアネットワーク１０７は、ネットワーク１１２へのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供することができ、ネットワーク１１２は、その他のサービスプロバイダによって所有および／または運営されているその他の有線またはワイヤレスのネットワークを含むことができる。

図１Ｅは、一実施形態によるＲＡＮ１０５およびコアネットワーク１０９のシステム図である。ＲＡＮ１０５は、エアインターフェース１１７を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するためにＩＥＥＥ８０２．１６無線テクノロジーを採用しているアクセスサービスネットワーク（ＡＳＮ）であることが可能である。以降でさらに論じられるように、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、ＲＡＮ１０５、およびコアネットワーク１０９という別々の機能エンティティーの間における通信リンクは、リファレンスポイントとして定義されることが可能である。

図１Ｅにおいて示されているように、ＲＡＮ１０５は、基地局１８０ａ、１８０ｂ、１８０ｃ、およびＡＳＮゲートウェイ１８２を含むことができるが、ＲＡＮ１０５は、一実施形態との整合性を保持しながら、任意の数の基地局およびＡＳＮゲートウェイを含むことができるということが理解されるであろう。基地局１８０ａ、１８０ｂ、１８０ｃはそれぞれ、ＲＡＮ１０５内の特定のセル（図示せず）に関連付けられることが可能であり、エアインターフェース１１７を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するために１または複数のトランシーバをそれぞれ含むことができる。一実施形態においては、基地局１８０ａ、１８０ｂ、１８０ｃは、ＭＩＭＯテクノロジーを実施することができる。したがって基地局１８０ａは、たとえば、ＷＴＲＵ１０２ａにワイヤレス信号を送信するために、およびＷＴＲＵ１０２ａからワイヤレス信号を受信するために、複数のアンテナを使用することができる。基地局１８０ａ、１８０ｂ、１８０ｃは、モビリティー管理機能、たとえば、ハンドオフトリガリング、トンネル確立、無線リソース管理、トラフィック分類、サービス品質（ＱｏＳ）ポリシー実施などを提供することもできる。ＡＳＮゲートウェイ１８２は、トラフィックアグリゲーションポイントとして機能することができ、ページング、サブスクライバープロファイルのキャッシング、コアネットワーク１０９へのルーティングなどを担当することができる。

ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと、ＲＡＮ１０５との間におけるエアインターフェース１１７は、ＩＥＥＥ８０２．１６仕様を実施するＲ１リファレンスポイントとして定義されることが可能である。加えて、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのそれぞれは、コアネットワーク１０９との論理インターフェース（図示せず）を確立することができる。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと、コアネットワーク１０９との間における論理インターフェースは、Ｒ２リファレンスポイントとして定義されることが可能であり、このＲ２リファレンスポイントは、認証、許可、ＩＰホスト構成管理、および／またはモビリティー管理のために使用されることが可能である。

基地局１８０ａ、１８０ｂ、１８０ｃのそれぞれの間における通信リンクは、ＷＴＲＵハンドオーバー、および基地局どうしの間におけるデータの転送を容易にするためのプロトコルを含むＲ８リファレンスポイントとして定義されることが可能である。基地局１８０ａ、１８０ｂ、１８０ｃと、ＡＳＮゲートウェイ１８２との間における通信リンクは、Ｒ６リファレンスポイントとして定義されることが可能である。このＲ６リファレンスポイントは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのそれぞれに関連付けられているモビリティーイベントに基づいてモビリティー管理を容易にするためのプロトコルを含むことができる。

図１Ｅにおいて示されているように、ＲＡＮ１０５は、コアネットワーク１０９に接続されることが可能である。ＲＡＮ１０５と、コアネットワーク１０９との間における通信リンクは、たとえば、データ転送およびモビリティー管理機能を容易にするためのプロトコルを含むＲ３リファレンスポイントとして定義されることが可能である。コアネットワーク１０９は、モバイルＩＰホームエージェント（ＭＩＰ−ＨＡ）１８４、認証／許可／アカウンティング（ＡＡＡ）サーバ１８６、およびゲートウェイ１８８を含むことができる。上述の要素のうちのそれぞれは、コアネットワーク１０９の一部として示されているが、これらの要素のうちのいずれかの要素が、コアネットワークオペレータ以外のエンティティーによって所有および／または運営されることも可能であるということが理解されるであろう。

ＭＩＰ−ＨＡは、ＩＰアドレス管理を担当することができ、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃが、別々のＡＳＮおよび／または別々のコアネットワークの間においてローミングすることを可能にすることができる。ＭＩＰ−ＨＡ１８４は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと、ＩＰ対応デバイスとの間における通信を容易にするために、インターネット１１０などのパケット交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供することができる。ＡＡＡサーバ１８６は、ユーザ認証と、ユーザサービスをサポートすることとを担当することができる。ゲートウェイ１８８は、その他のネットワークと相互作用することを容易にすることができる。たとえば、ゲートウェイ１８８は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと、従来の地上通信線通信デバイスとの間における通信を容易にするために、ＰＳＴＮ１０８などの回線交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供することができる。加えて、ゲートウェイ１８８は、ネットワーク１１２へのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供することができ、ネットワーク１１２は、その他のサービスプロバイダによって所有および／または運営されているその他の有線またはワイヤレスのネットワークを含むことができる。

図１Ｅにおいては示されていないが、ＲＡＮ１０５は、その他のＡＳＮに接続されることが可能であり、コアネットワーク１０９は、その他のコアネットワークに接続されることが可能であるということが理解されるであろう。ＲＡＮ１０５と、その他のＡＳＮとの間における通信リンクは、Ｒ４リファレンスポイントとして定義されることが可能であり、このＲ４リファレンスポイントは、ＲＡＮ１０５と、その他のＡＳＮとの間においてＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのモビリティーをコーディネートするためのプロトコルを含むことができる。コアネットワーク１０９と、その他のコアネットワークとの間における通信リンクは、Ｒ５リファレンスとして定義されることが可能であり、このＲ５リファレンスは、ホームコアネットワークと、訪問先コアネットワークとの間における相互作用を容易にするためのプロトコルを含むことができる。

別々のオペレータの間においてキャパシティーを管理することを担当することができる論理エンティティーが提供されることが可能である。この論理エンティティーは、ブローカレッジコントロールユニット（ＢＣＵ）と呼ばれる場合がある。被ホスト側オペレータに対するネットワークキャパシティーおよび／またはネットワークスライス割り当てを表すためのメトリックが提供されることが可能である。これらのメトリックは、個々に、または互いにもしくはその他のメトリックと組み合わせて使用されることが可能である。

被ホスト側オペレータは、さらなるリソースが必要とされていると言えるかどうかを識別するために自分のネットワーク内のさまざまなパラメータをモニタすることができる。それらのパラメータは、ｅＮＢベースごとであることが可能である。それらのパラメータは、領域内のＷＴＲＵにサービス提供することができるｅＮＢのグループに基づくことが可能である。ｅＮＢは、それらのパラメータをネットワーク内の論理エンティティーへ定期的に送信することができ、またはそうするようネットワークノードによって要求されたときにそれらのパラメータを送信することができる。

被ホスト側オペレータは、リソースを提供することができる可能性がある利用可能なＲＡＮオペレータを発見することができる。この発見は、たとえば、運用／管理／メンテナンス（ＯＡＭ）手順、ホームサブスクライバーサービス（ＨＳＳ）によってサポートされる発見などを含むことができる１または複数の方法を使用して実行されることが可能である。ＲＡＮオペレータを発見すると、被ホスト側オペレータは、利用可能なリソースを探してそのＲＡＮオペレータにクエリーを行うことができる。これは、たとえば、キャパシティークエリーメッセージなどのクエリーメッセージを送信することによって行われることが可能である。このメッセージは、ＲＡＮオペレータまたはＲＡＮオペレータのＢＣＵへ送信されることが可能である。リソースがＲＡＮオペレータから要求されることを可能にするために、キャパシティー割り当て要求または応答メッセージのやり取りがもたらされることが可能である。

使用されていない割り当てられたリソースは、被ホスト側オペレータまたはＲＡＮオペレータによってキャンセルまたは撤去されることが可能である。割り当てられたリソースをキャンセルしたいと望むオペレータは、リソースを撤去するためのキャンセレーション要求を他方のオペレータへ送信することができる。リソースをキャンセルするという決定は、ＲＡＮオペレータによって行われることが可能である。

ＰＬＭＮごとのオフローディングルールをサポートする目的で、別々のＰＬＭＮに属しているＷＴＲＵどうしに関してハンドオーバーをトリガーする条件を修正するための１または複数の方法が使用されることが可能である。たとえば、それぞれのＰＬＭＮのためのモビリティー変更要求メッセージ内のハンドオーバートリガー変更ＩＥが複製されることが可能である。別々の被ホスト側オペレータによってピアｅＮＢが共有されることが可能になる条件をサポートするために、オペレータ情報（ＰＬＭＮ）がハンドオーバートリガー変更ＩＥ内に含まれることが可能である。

ＢＣＵまたはその他のＯＡＭノードは、被ホスト側オペレータが、割り当てられたリソースのうちの自分の持ち分を点検することができる場合に適用されることが可能である特定のポリシーを共有ノードに強制することができる。ＲＡＮリソースのうちの一定割合は、ＲＡＮノードによって予備リソースとして保持されることが可能であり、いかなるオペレータにも割り当てられないことが可能である。

ネットワークおよびネットワークインフラストラクチャーを共有することは、３ＧＰＰシステムの重要な部分になっている。ネットワークおよびネットワークインフラストラクチャーを共有することによって、モバイルネットワークオペレータは、モバイルネットワークに関する重い展開コストを、特にロールアウトフェーズにおいて共有することができる。複数のネットワーク共有シナリオが考えられる場合があり、それらのシナリオは、さまざまなオペレータ戦略およびさまざまな国々における法規に依存する場合がある。３ＧＰＰシステムは、もともとは別々のオペレータの間におけるネットワーク共有のために設計されたわけではない。しかしながら、３ＧＰＰリリース９９は、ネットワーク共有のためのいくらかの限られたサポートを提供している。リリース９９におけるＰＬＭＮ機能は、オペレータが共通のＵＴＲＡＮを共有することを可能にし、コアネットワークの特定の部分２０２も、オペレータどうしの間において共有される。図２は、共通のＵＴＲＡＮ２００を共有している２つのオペレータを示す図である。

現在のモバイル電話市場においては、さまざまな形態のネットワーク共有を可能にする機能が、ますます重要になっている。これらの機能的な側面は、３ＧＰＰ ＵＴＲＡＮベースのアクセスネットワークにおけるリリース６の前には、３ＧＰＰ Ｅ−ＵＴＲＡＮベースのアクセスネットワークにおけるリリース８の前には、および３ＧＰＰ ＧＥＲＡＮベースのアクセスネットワークにおけるリリース１０の前には、対処されていなかった。

３ＧＰＰリリース６より前のＵＴＲＡＮワイヤレス送信／受信ユニット（ＷＴＲＵ）に、およびサポートしていない３ＧＰＰ ＧＥＲＡＮ ＷＴＲＵに対応するために、ＭＳＣ、ＳＧＳＮ、ＢＳＣ、およびＲＮＣのための特別な機能が、サポートしていないＷＴＲＵにネットワーク共有機能を提供することができる。

ＵＭＴＳリリース８およびＬＴＥリリース８においては、ＵＴＲＡＮおよびＥ−ＵＴＲＡＮ対応ＷＴＲＵは、ネットワーク共有要件をサポートすることを必要とされていた。

いくつかのネットワーク共有シナリオは、共通の無線アクセスネットワーク（ＲＡＮ）を共有する複数のコアネットワーク（ＣＮ）、地理的に分割されたネットワーク共有、共通の地理的エリアにわたるネットワーク共有、共通スペクトルネットワーク共有、および／または、共通のコアネットワークを共有する複数の無線アクセスネットワークを含むことができる。

図３は、ネットワーク共有のための例示的なゲートウェイコアネットワーク（ＧＷＣＮ）構成３００を示している。図４は、例示的なマルチオペレータコアネットワーク（ＭＯＣＮ）を示しており、このＭＯＣＮにおいては、複数のＣＮノード４０２が、同じＲＮＣ４０４に接続されており、それらのＣＮノード４０２は、別々のオペレータによって操作されることが可能である。図３および図４は、２つの異なる種類のネットワーク共有構成を示している。このネットワーク共有アーキテクチャーは、ＧＷＣＮであるかＭＯＣＮであるかを問わず、別々のコアネットワークオペレータが無線アクセスネットワークを共有することを可能にすることができる。オペレータどうしは、無線ネットワーク要素を共有することができ、無線リソースそのものを共有することができる。ｅＮＢ内のキャリアリソースは、コアネットワークオペレータによって共有されることが可能である。

ネットワーク共有においては、キャリアリソースは、共有キャリアまたは専用キャリアであることが可能である。共有キャリアは、複数のコアネットワークオペレータによって共有されることが可能であるｅＮＢ内のキャリアであると言える。専用キャリアは、特定のオペレータのために排他的に使用されることが可能であるｅＮＢ内のキャリアであると言える。

ネットワーク共有は、さまざまなシナリオにおいて使用されることが可能である。たとえば、ＰＬＭＮ ＩＤ１を有するオペレータ１というオペレータが、ｅＮＢを購入する場合があり、次いでそのｅＮＢを、ＰＬＭＮ ＩＤ２を有するオペレータ２という別のオペレータ、およびＰＬＭＮ ＩＤ３を有するオペレータ３というさらに別のオペレータに貸す場合がある。そのｅＮＢは、オペレータ１、オペレータ２、およびオペレータ３によって共有されることが可能である。キャリアは、セルと同等または類似の概念とみなされることが可能である。

エボルブドパケットシステムに関しては、ＰＳドメインが関連する場合がある。Ｅ−ＵＴＲＡＮアクセスに関しては、図３および／または図４が当てはまることが可能である。しかしながら、ＭＭＥがＳＧＳＮに取って代わる場合があり、ｅＮｏｄｅＢがＲＮＣに取って代わる場合があり、Ｓ１リファレンスポイントがＩｕインターフェースに取って代わる場合がある。

モバイルネットワークオペレータは、モバイルブロードバンドトラフィックにおける増大に起因する自分たちのネットワーク上での需要の高まりに対処するためのコスト効率のよい方法を探している。いくつかのソリューションは、屋内カバレッジの増大、スモールセル、ＬＴＥ、ＩＰイーサネットバックホール、および／またはより多くのスペクトルを伴う。しかしながら、これらのソリューションは、さらなる資本支出（Ｃａｐｅｘ）を伴う。

先行投資コストの大部分が、カバレッジを確立することに関連している場合がある。資本支出の約７０％が、敷地を取得すること、アクセス機器、土木工事（たとえば、敷地での建設作業、機器の据え付け）、ならびに電気およびバックホールのためのケーブルを敷設することを伴う場合がある。

かなりの運用経費および資本支出の節減をもたらすことを確約することができる強化が、既存のＲＡＮ共有ソリューションに対して行われることが可能である。これらの強化は、ネットワークロールアウト戦略において新たなパラダイムを導入することができる。たとえば、ＲＡＮ共有に対するこれらの強化が非常に有益である場合がある少なくとも３つのソリューションが存在していると言える。新規展開において、２つのオペレータが、新たなテクノロジー、たとえば４Ｇを構築することに同意する場合がある。はじめに、新たな共有されるネットワークインフラストラクチャーおよびオペレーションは、両方のオペレータのキャパシティーおよびカバレッジ要件に基づくことが可能である。オペレータは、５０：５０で、または自分たちの予想される必要性に従って、構築に出資することができる。バイインソリューションにおいては、共有オペレータのうちの１つが、たとえば４Ｇネットワークを既に構築している場合があり、ネットワークを共有するための別のオペレータを探している場合がある。このケースにおいては、第２のオペレータは、そのネットワークを確保するためのキャパシティー使用手数料または前払い手数料を支払う場合がある。統合状況においては、共有オペレータによって既に構築されている場合がある２Ｇ、３Ｇ、および／または４Ｇネットワークどうしは、１つの共同のネットワークへと統合される必要が生じる場合がある。このタイプのネットワーク共有は、著しいコスト上の利点を有する場合があるが、かなりの設計上の難題を提示する場合もある。

資本支出（Ｃａｐｅｘ）および運用経費（Ｏｐｅｘ）の節減に加えて、さらに良好な屋内カバレッジを提供することができる、かつさらに高いセルキャパシティーにつながることができるさらに高密度なネットワークなど、間接的な効率上の利得が存在する場合もある。

図５は、ＷＴＲＵアーキテクチャーおよびネットワークアーキテクチャーを含むことができる仮想化されたネットワーク５００の例示的なエンドツーエンドのアーキテクチャーを示している。このアーキテクチャーは、例として、無線アクセスネットワーク（ＲＡＮ）、コアネットワーク（ＣＮ）、サービスネットワーク、および／またはクラウドネットワークを含むことができる１または複数のネットワークのアーキテクチャーとして特徴付けられることが可能である多次元の仮想化アーキテクチャーであることが可能である。それらの次元の１つにおいては、オペレータが仮想化されることが可能である。別の次元においては、サービスプロバイダが仮想化されることが可能である。別の次元においては、潜在的に複数の異なるエアインターフェース（たとえば、ＧＳＭ、ＣＤＭＡ、ＷＣＤＭＡ／ＨＳＤＰＡ／ＨＳＵＰＡ、ＴＳ−ＳＣＤＭＡ、ＬＴＥ、ＷｉＦｉ、ＷｉＭＡＸなど）を伴うＲＡＮリソースを含むネットワークリソース（たとえば、計算リソース、ストレージリソース、ネットワーキングロジック、プロトコルおよびアルゴリズムロジック）がクラウド内で仮想化されることが可能である。無線アクセスネットワークのコンテキストにおけるネットワークリソース仮想化が、たとえば、再構成可能な無線システムにおいて採用されることが可能である。３つの次元の仮想化、たとえば、オペレータ、サービスプロバイダ、およびネットワークリソースを採用するアーキテクチャーは、オペレータに依存しない、および／またはテクノロジーアクセスに依存しない、および／またはサービスプロバイダに依存しないネットワークおよびサービスアクセスを提供することができる。

別の次元においては、ネットワークリソースが、複数のネットワークにわたる動的なリソースプーリングという意味で仮想化されることが可能である。動的なリソースプーリングは、たとえば、無線アクセスネットワークリソース（たとえば、スペクトル、無線リソースブロック、セルなど）の共有のために使用されることが可能である。別の次元においては、ＷＴＲＵリソース（たとえば、計算リソース、ストレージリソース、ネットワーキングロジック、プロトコルおよびアルゴリズムロジック）がクラウド内で仮想化されることが可能である。ネットワークリソース仮想化は、再構成可能な無線システムのための無線アクセスネットワークのコンテキストにおいて使用されることが可能である。

さらに別の次元においては、ユーザに提供されるサービス（たとえば、ビジネスロジック）、またはその他のビジネスサポートサービス（たとえば、課金および料金請求サポートシステム、オペレータサポートシステムなど）がクラウド内で仮想化されることが可能である。これらの次元は、図５において示されているように統合されることおよび／またはともにアクティブ化されることが可能であり、または個別にアクティブ化されることが可能であり、または任意の組合せでアクティブ化されることが可能である。

仮想化されたネットワーク５００は、複数のネットワークノードを含むことができる。仮想化レイヤネットワークマネージャー機能（ＶＮＭＦ）５０２は、仮想化されたネットワークリソースを管理することができ、いくつかのステークホルダ、たとえばオペレータにわたってオペレータのネットワークリソースをコントロールすることができる。ＶＮＭＦ５０２は、仮想化されたベアラをそれぞれのステークホルダネットワークへとセットアップして管理することを担当することができる。ＶＮＭＦ５０２は、クラウドベアラの管理を担当することもできる。

ＶＮＭＦ５０２は、直接インターフェースを取ることができ、または複数のタスクの１もしくは複数に関してアプリケーションインターフェース（ＡＰＩ）プリミティブを採用することができる。ＶＮＭＦ５０２は、より広いネットワーキングおよびユビキタスサービスプロビジョニングのためにネットワークどうしのネットワークを形成するためにモバイルサービスクラウドネットワークおよび／またはピアサービスネットワークと対話することができる。ＶＮＭＦ５０２は、サービスおよびアプリケーションへのエンドユーザ／ＷＴＲＵの接続を提供するために、さまざまなオペレータのネットワーク、たとえばコアネットワーク、およびそれらの関連した無線アクセスネットワークと対話することができ、その対話は、接続およびネットワークリソース管理のためのオペレータネットワークコントローリングノード（ＭＭＥ／ＳＧＳＮ）とのコマンドおよびコントロール対話を含むことができる。これらのコアネットワークおよび／または無線アクセスネットワークは、オペレータネットワークのゲートウェイノード（たとえば、Ｓ−ＧＷ、Ｐ−ＧＷ、ＧＧＳＮ）を介した、本明細書において開示されているＶＳＡＣＥノードへのサービスまたはアプリケーショントラフィックパスをエンドユーザのために確立することに関与することができる。ＶＮＭＦ５０２は、モバイルデバイスエンドユーザがエンドユーザもしくはＷＴＲＵのロケーションまたはネットワークとの接続ポイントに基づいて選択したサービスまたはアプリケーションに関するコントロールまたはデータ目的でＷＴＲＵが適切な無線アクセスネットワークおよびオペレータのコアネットワークパスを選ぶのを支援するために、エンドユーザまたはＷＴＲＵと直接対話することができる。ＶＮＭＦ５０２は、さまざまなネットワークオペレータからのユーザプロファイルを保持することができ、たとえば、別々のネットワークオペレータからのさまざまなＭＭＥに接続されることが可能である。ＶＮＭＦ５０２は、ＷＴＲＵが別々のオペレータネットワークの間において移動する場合に、モビリティー管理情報を保持することができる。ＶＮＭＦ５０２は、仮想ネットワークシステムにアクセスするための必要とされている金融または課金クレデンシャルをユーザが有していることを確かめるために、金融機関、または金融機関に接続されている課金エンティティーと対話することができる。ＶＮＭＦ５０２は、ユーザにとっての利用可能なサービスおよび／またはアプリケーションのリスト、ならびにそれらのサービスおよび／またはアプリケーションに関連した課金情報を提供することができる。

仮想化レイヤポリシーおよびルール調整機能（ＶＰＲＣＦ）５０４は、マルチステークホルダサービス環境におけるサービス配信に関与することができる。ＶＰＲＣＦ５０４は、さまざまなステークホルダ、たとえば、ネットワークオペレータ、仮想ネットワークオペレータ、サービスプロバイダ（たとえば、Ａｍａｚｏｎ（登録商標）、Ｇｏｏｇｌｅ（登録商標）、Ｙａｈｏｏ（登録商標）、Ａｐｐｌｅ（登録商標）、Ｆａｃｅｂｏｏｋ（登録商標）、Ｔｗｉｔｔｅｒ（登録商標）など）、アプリケーションプロバイダまたは開発者、コンテンツプロバイダ、金融機関（たとえば、銀行、ＰａｙＰａｌなど）、アイデンティティープロバイダ（たとえば、Ｇｏｏｇｌｅ（登録商標）、Ｙａｈｏｏ（登録商標）、ＭｙＳｐａｃｅ（登録商標）等などのＯｐｅｎＩＤプロバイダ）、デバイス製造業者、その他の信頼されているエンティティーなどにわたってポリシーおよびルールを統合および調整することができる。ステークホルダは、ユーザおよび／またはサブスクライバーを含むこともできる。

ＶＰＲＣＦ５０４は、複数のステークホルダにわたるコンフリクトを解消するためのロジックを実装することができる。そのようなコンフリクト解消ロジックは、入力として、たとえば、ユーザもしくはサブスクライバーの好み、ルール、および／もしくはポリシー、サービスレベルアグリーメント、所望のＱｏＳ／ＱｏＥ、価格、コンテキスト、ならびに／またはその他の関連する入力を使用することができる。

ＶＰＲＣＦ５０４は、自分の機能のうちのいずれも、ＷＴＲＵ内の仮想化機能、たとえば、ＷＴＲＵ内のクロスステークホルダポリシーマネージャー機能と連携させて実行することができる。別の例においては、ＶＰＲＣＦ５０４は、自分の機能のうちのいずれも、単独で実行することができる。

ネットワークオペレータは、ネットワーク、たとえば、ＲＡＮまたはコアネットワークを所有することができるエンティティー、関係者、またはオペレータなどであることが可能である。本開示において使用される際には、ネットワークオペレータは、ＲＡＮオペレータ、ホスト側オペレータ、またはホスト側ＲＡＮオペレータと呼ばれる場合もある。ネットワークオペレータは、自分のリソースがその他のオペレータおよび／またはモバイル仮想ネットワークオペレータ（ＭＶＮＯ）によって使用されることを可能にすることができる。これらのリソースは、キャリアレベル、セルレベル、ｅＮＢレベル、および／またはコアネットワークレベルであることが可能であり、本明細書においてさらに説明される。

被ホスト側オペレータまたは参加オペレータは、ホスト側オペレータにリソースを要求することができるエンティティー、関係者、またはオペレータなどであることが可能である。被ホスト側オペレータは、ホスト側オペレータに関して本明細書において説明されているようなさまざまなタイプのリソースを要求することができる。被ホスト側オペレータは、物理的なエンティティーではないことが可能であり、ネットワークをさまざまなホスト側オペレータと共有することができる仮想オペレータであることが可能である。

静的な共有は、リソース割り当てが合意されることが可能である、ホスト側オペレータと被ホスト側オペレータとの間において生じることができるネットワーク共有取り決めのタイプであると言える。ホスト側オペレータは、合意されたリソースを被ホスト側オペレータに提供することができる。被ホスト側オペレータがリソース割り当てを変更したいと望む可能性がある場合には、新たな取り決めが必要とされることがある。

動的な共有は、ホスト側オペレータと被ホスト側オペレータとの間における手動または自動のＯＡＭ手順を使用してネットワークリソースの割り当てが変更されることまたは切り替えられることが可能であるネットワーク共有取り決めのタイプであると言える。被ホスト側オペレータは、さらなるリソースをホスト側オペレータに動的に要求することができ、それらのリソースを、ホスト側オペレータは、可用性およびその他の要因に基づいて割り当てることまたは割り当てないことが可能である。このタイプのリソース割り当ては、たとえば、数分間から数時間のタイムフレームで生じることが可能である。

リアルタイムの共有は、リソース割り当てが被ホスト側オペレータからの要求に基づいて迅速に、たとえばすぐに変わることが可能であるネットワーク共有取り決めのタイプであると言える。このタイプの共有においては、ＯＡＭ手順が関与することも、または関与しないことも可能である。ネットワークノードどうしは、別々の共有オペレータに属している場合があり、それらの共有オペレータは、リソースの新たなキャパシティーまたは割り当てについて交渉するためにメッセージを直接やり取りすることができる。このタイプのリソース共有割り当ては、数マイクロ秒間から数秒間のピリオド内で生じることが可能である。

本開示において使用される際には、アクセスポイント名（ＡＰＮ）という用語は、ネットワーク（たとえば、インターネット、パケットデータネットワークなど）へのポータルを指すことができる。ＡＰＮは、供給されているデータレートプラン内で定義されているＡＰＮの定義に基づいて特定のデータサービスを提供するために使用されることが可能である。それぞれのＡＰＮは、インターネットなどのネットワークへのアクセスを可能にすることができるが、そのアクセスおよび関連付けられている料金請求は、ＡＰＮごとに異なる場合がある。

本開示において使用される際には、デフォルトアクセスポイント名（ＡＰＮ）という用語は、サブスクリプションデータにおけるデフォルトとしてマークされることが可能な、および接続手順中に使用されることが可能なＡＰＮを指すことができる。ＷＴＲＵによってＡＰＮが提供されていない場合には、そのＷＴＲＵは、ＰＤＮ接続手順を要求した可能性がある。

本開示において使用される際には、パックドデータネットワーク（ＰＤＮ）接続という用語は、ＩＰｖ４アドレスおよび／またはＩＰｖ６プレフィックスによって表されるＷＴＲＵと、アクセスポイント名（ＡＰＮ）によって表されるＰＤＮとの間における関連付けを指すことができる。

本開示において使用される際には、デフォルトベアラという用語は、新たなＰＤＮ接続のために確立されることが可能な、およびそのＰＤＮ接続の存続期間にわたって確立されたままであることが可能なエボルブドパケットシステム（ＥＰＳ）ベアラを指すことができる。端末ＩＰアドレスごとに１つのデフォルトベアラが存在することが可能である。同じＰＤＮ接続に関して確立されることが可能である任意のさらなる１または複数のＥＰＳベアラは、専用ベアラと呼ばれる場合がある。デフォルトベアラのＱｏＳレベルは、サブスクリプションデータに基づいて割り振られることが可能である。

本明細書において開示されている例は、共通のＲＡＮリソースを共有すること、たとえば、割り当てられていない無線リソースをプールすることを効率よく行うための手段を提供することができる。ネットワークリソースの共有は、静的であることが可能である。共有契約は、ネットワークリソースのうちで、その契約における変更を伴わずに修正されることが不可能である一定割合の割り当てを定義することができる。ネットワークリソースの共有は、動的であることが可能である。ネットワーク共有スキームは、リアルタイムベースで被ホスト側オペレータのキャパシティーニーズに対応するのに十分なだけフレキシブルであることが可能である。ネットワーク、たとえばＲＡＮオペレータは、最も高い入札額を提示している被ホスト側オペレータにネットワークキャパシティーを売り渡すことができる。

本明細書において開示されている例は、共有ネットワーク要素が、割り当てられるＲＡＮリソースを共有取り決めまたはポリシーに従って提供していることを確認するための手段を提供することができる。開示されている例は、共有取り決めまたはポリシーを考慮した場合のオーバーロード状況の表示、およびそれらのオーバーロード状況に際して取られることが可能である潜在的なアクションを提供することができる。

既存のＲＡＮ共有アーキテクチャーに対する強化が定義されることが可能である。キャパシティーブローカリングのアーキテクチャーに関しては、新たなネットワーク要素が関与することが可能であり、既存のノードに新たな機能が付加されることが可能であり、および／または新たなインターフェースが提供されることが可能である。ネットワークキャパシティーは、何が共有されることが可能であるか、または、所与の被ホスト側オペレータに割り当てられているネットワークのスライスを表すためにどんなメトリックが使用されることが可能であるかに関して定義されることが可能である。共有ネットワークリソースの消費を判定するための新たな測定が提供されることが可能である。加えて、ネットワーク共有の利得が、たとえば、ホスト側オペレータ、被ホスト側オペレータ、および／またはＭＶＮＯを含む関与している関係者の観点から定量化されることが可能である。加えて、別々のオペレータが、ＲＡＮ共有のためにリソースをプールしている場合には、ＷＴＲＵの課金は、そのＷＴＲＵがサブスクライブされているホスト側オペレータの課金ルールに従って実行されることが可能である。ネットワーク内の別々のＷＴＲＵごとに、別々の課金レコードが生成されることが可能である。加えて、ＲＡＮ共有は、オペレータ仮想化のケースにおいて、たとえば、仮想ネットワークアーキテクチャーにおいて実行されることが可能である。

動的な共有が提供されることが可能である。ＲＡＮリソースが別々のオペレータまたはＭＶＮＯによって共有されることが可能である場合には、これらのリソースは、被ホスト側オペレータによってオンデマンドベースで要求されることが可能である。これらのリソースのうちで別々のオペレータによって使用される割合は、時間とともに変わることが可能である。被ホスト側オペレータからのさらなるリソースを求める必要性または要求は、一貫している場合があり、たとえば、被ホスト側オペレータは、毎回同じ要求を送信する場合がある。被ホスト側オペレータからのさらなるリソースを求める必要性または要求は、被ホスト側オペレータが、自分のネットワーク混雑状況に基づいて、ＲＡＮリソースを所有しているオペレータにその要求を送信する場合があるという点で、動的である場合がある。その要求をＲＡＮオペレータが受信した場合には、ＲＡＮオペレータは、その着信要求を確認するためにいくつかのアクションを取ることができ、リソースが割り当てられることが可能であるかどうかを判定することができる。その要求をＲＡＮオペレータが受け入れた場合には、ＲＡＮオペレータは、リソースを被ホスト側オペレータに割り振ることができる。

被ホスト側オペレータは、自分が共有ネットワークにおいてさらなるリソースを必要とする可能性があるということを識別することができる。それは、リソースが必要とされる可能性があるピリオド、リソースの量、および／または、特定のＱｏＳ等などのその他のパラメータを指定することもできる。さらなるリソースが必要とされているということを、被ホスト側オペレータが、たとえば、自分がモニタするパラメータ、およびそのプロセスに関与しているさまざまなノードを介して識別することができる複数の方法が存在することが可能である。ＲＡＮインフラストラクチャーおよびスペクトルが両方とも共有されることが可能であるネットワーク共有スキームにおいては、共有されるネットワークのキャパシティーは、さまざまなリソースタイプおよび／もしくはリソースユニット、またはさまざまなタイプのリソースの組合せの点から表されることが可能である。共有されることが可能であるさまざまなＲＡＮリソース、たとえば、アクセスプリアンブル、コントロールチャネルＣＣＥ、共有ＰＤＳＣＨ／ＰＵＳＣＨ／ＰＵＣＣＨが存在することが可能である。共有されるキャパシティーを有することができる１または複数のリソースが判定されることが可能である。加えて、共有されるキャパシティーのユニットが判定されることが可能である。

被ホスト側オペレータは、自分がさらなるリソースを必要とする可能性があると判定した場合には、リソースを求める要求をＲＡＮオペレータへ送信することができる。その要求は、複数の方法で送信されることが可能である。加えて、要求メッセージは、複数のパラメータを含むことができる。被ホスト側オペレータは、さまざまなＲＡＮネットワークからのリソースを使用している場合があり、したがって、どのＲＡＮオペレータに自分が要求を送信する可能性があるかを判定することができ、または自分が要求を１つのＲＡＮオペレータに送信する可能性があるか、もしくは複数のＲＡＮオペレータに送信する可能性があるかを判定することができる。

ＲＡＮオペレータは、要求を受信した場合には、その要求を受け入れることも、または受け入れないことも可能である。ＲＡＮオペレータが、被ホスト側オペレータからのリソースを求める要求を査定しながら考慮に入れることができる複数のルールおよび／またはポリシーが、ＲＡＮオペレータにおいて定義されることが可能である。ＲＡＮリソースを被ホスト側オペレータに割り当てるためのＲＡＮレベルにおけるいくつかの手順および方法が実行されることが可能である。加えて、割り当てが利用可能であるという旨を応答するための方法が使用されることが可能である。

割り当てられたリソースは、被ホスト側オペレータによって、またはＲＡＮオペレータによって撤去またはキャンセルされることが可能である。これらのリソースは、被ホスト側オペレータがそれらを使用し始める前にキャンセルされることが可能である。被ホスト側オペレータがそれらのリソースを使用し始めた場合には、それらのリソースの残りがキャンセルされることが可能である。被ホスト側オペレータの側で、およびＲＡＮオペレータの側で、２つの異なる手順が使用されることが可能である。複数の要因および／またはポリシーが、リソースのキャンセレーションにつながる場合がある。キャンセレーション手順は、キャパシティー割り当ての要求手順および／もしくはメッセージ、最初の要求のキャンセレーション手順および／もしくはメッセージ、ならびに／または利用可能なキャパシティーのクエリー手順および／もしくはメッセージを含むことができる。

いくつかの状況においては、複数の被ホスト側オペレータが、同時にＲＡＮオペレータにリソースを要求し、潜在的に競合状況をもたらす場合がある。ホスト側オペレータは、限られたリソースを有している場合には、この競合状況においてどのようにリソースを割り当てるかを決めることができる。そのようなケースを取り扱うための特定のルールおよび／または手順が使用されることが可能である。

本明細書において開示されているいくつかの例は、ＲＡＮ共有シナリオのコンテキストにおいて説明されているが、コアネットワーク（ＣＮ）リソースの共有に適用されることも可能である。

ＷＴＲＵは、接続モードにあって移動しているときには、１つのセルから別のセルへ移動する場合がある。ＷＴＲＵは、自分自身のネットワークセル（たとえば、そのＷＴＲＵがサブスクライブされているネットワーク）から、ＲＡＮオペレータ（たとえば、さらなるキャパシティーを提供しているオペレータ）に属しているセルへのシームレスなハンドオーバーを実行することができる。ＲＡＮオペレータは、共有ＲＡＮの使用について記述する課金またはアカウンティングレコードを生成することができる。課金レコードは、被ホスト側オペレータへ送信されることが可能であり、ＷＴＲＵに提供されるサービスの始まりおよび終わりについて記述することができる。さらに、いくつかのハンドオーバー、たとえば、ＲＡＮオペレータのセルどうしの間におけるハンドオーバーは、課金イベントを生み出さない場合がある。ネットワークは、共有ＲＡＮへのおよび共有ＲＡＮからのＷＴＲＵの移動によってもたらされるイベントどうしの間において区別を行うことができ、それらのイベントは、アカウンティングまたは課金メッセージの生成、およびアカウンティング目的でのメッセージの生成を含まない場合があるモビリティーイベントを含むことができる。

いくつかのロード測定は、複数のコアネットワークによってＲＡＮが共有されている場合に別々のオペレータのネットワークからのロードを区別しない。加えて、Ｘ２ロード交換方法は、別々のオペレータからのトラフィックの間における区別を行わない。

図６は、ロードバランシングのための例示的な方法を示している。いくつかのロードバランシング手順においては、セル６０２は、オーバーロードされている場合には、自分の近隣のセルとの間で自分のロード情報をやり取りすることができる。ロードバランシングアルゴリズムが、オーバーロード状況を有していないセルを選ぶことができ、オーバーロードされているセルから１または複数のオーバーロードされていないセル６０４へ、それらのハンドオーバーパラメータを調整することによって、トラフィックをオフロードすることができる。いくつかのロードバランシング手順は、オーバーロードされているセルからオーバーロードされていないセルへトラフィックをオフロードする際にトラフィックのネットワークを区別することができない。

ＲＡＮ共有の容易さの点で、被ホスト側オペレータどうしは、ＲＡＮリソース上に別々の持ち分を有することができる。オフロードされるように選ばれたロードは、別々のオペレータに対しては、それぞれのＲＡＮノード上のそれらの使用および割り当てられた持ち分に基づいて異なることがある。

図７は、別のロードバランシング方法を示している。図７において示されているように、ＲＡＮは、それぞれＰＬＭＮ ＡおよびＰＬＭＮ Ｂを伴う２つの被ホスト側オペレータ７０２、７０４によって共有されることが可能である。ｅＮＢ １は、オペレータＡに関して設定されている最大の持ち分を超過しているＰＬＭＮ Ａからのトラフィックでオーバーロードされている状況にある可能性がある。ｅＮＢ １におけるオペレータＢからのトラフィックは、オペレータＢに関する割り当てられている持ち分を下回っている可能性がある。オペレータＡからのトラフィックは、ｅＮＢ ２における自分の割り当てられている持ち分を下回っている可能性があり、オペレータＢからのトラフィックは、ちょうど自分の割り当てられている持ち分である可能性がある。オペレータＡからのトラフィックは、ｅＮＢ １からｅＮＢ ２へオフロードされることが可能である。

オペレータ固有のロードバランシングをサポートするために、ＰＬＭＮベースでＲＡＮトラフィックを測定するための方法が使用されることが可能である。このＰＬＭＮ固有のロード測定は、それぞれのＰＬＭＮからのトラフィック上のロード状況を判定するために使用されることが可能であり、どの１または複数のＰＬＭＮがシステムをオーバーロードさせる可能性があるかを判定する上で役立つことができる。

加えて、ＰＬＭＮ固有のトラフィックをＸ２ロード更新メッセージ内に含めるためにロード情報交換手順が使用されることが可能である。ＰＬＭＮのトラフィックがオフロードされる必要が生じる可能性があるかどうか、およびそれぞれのＰＬＭＮからのどれぐらい多くのトラフィックが、オーバーロードされているセルからオフロードされる可能性があるかを判定するために、ロード交換メッセージが使用されることが可能である。加えて、ロード交換メッセージは、それぞれのＰＬＭＮからのどれぐらい多くのトラフィックを、オーバーロードされていないセルが、オーバーロードされているセルから取ることができる可能性があるかを判定するために使用されることが可能である。

近隣のセルをコントロールしているピアｅＮＢとの間でハンドオーバートリガー設定について交渉するために、セルモビリティーパラメータが使用されることが可能である。ハンドオーバートリガー設定上の変更は、接続モードのＷＴＲＵに関するセルカバレッジを変更する場合があり、セルのロードを変更する場合がある。ＰＬＭＮ固有のオフローディングをサポートするために、ハンドオーバートリガー設定について交渉するためのＸ２メッセージが、ＰＬＭＮ固有のハンドオーバー設定をサポートするように強化されることが可能である。たとえば、ＰＬＭＮ固有のハンドオーバー設定に伴って、セルは、それぞれのＰＬＭＮごとに異なるカバレッジを有することができ、特定のＰＬＭＮ上で自分のロードを具体的に調整することができる。

セルが、接続モードのＷＴＲＵに関してＰＬＭＮ固有のカバレッジを、その一方でアイドルモードＷＴＲＵに関して同じカバレッジを有している場合には、ＷＴＲＵは、アイドルモードと比較して接続モードにおいてさらに小さなカバレッジを有しているＰＬＭＮに属することができ、接続モードに遷移した場合には、すぐにハンドオーバーまたは別のラウンドのロードバランシングをトリガーすることができる。これは、セルにおけるリソースの浪費をもたらす場合があり、短時間の滞在の問題をもたらすことによってＳＯＮアルゴリズムを混乱させる場合がある。本明細書において開示されているように、アイドルモードＷＴＲＵに関してＰＬＭＮ固有のカバレッジを定義するための方法が使用されることが可能である。

リソースモニタリングが提供されることが可能である。ＲＡＮ共有リソースモニタリングの使用事例は、自分のＲＡＮキャパシティーのうちの何らかの部分をその他の被ホスト側オペレータ（たとえば、ＭＶＮＯ）との間で共有することができるＲＡＮオペレータの状況に関連する場合があり、その場合、共有構成は、それぞれの被ホスト側オペレータごとに異なることがある。そのようなシナリオにおいては、ＲＡＮオペレータは、要求を行っている被ホスト側オペレータに、その被ホスト側オペレータに割り当てられている共有ＲＡＮリソース、ならびに予備のために利用可能な割り当てられていないオンデマンドリソースのステータスについて知らされるための手段を提供することができる。ＲＡＮオペレータは、ＲＡＮ共有ステータスに関して定期的におよび／または要求に応じて被ホスト側オペレータに報告することができる。

ＲＡＮオペレータは、レポートを通じてＲＡＮ共有の進展に関する定期的な更新を被ホスト側オペレータに提供することができる場合がある。ＲＡＮオペレータは、レポートを通じてＲＡＮ共有の進展に関するオンデマンドの更新に応答することができる場合がある。被ホスト側オペレータは、レポートを通じてＲＡＮ共有取り決めの履行を確認することができる場合がある。被ホスト側オペレータは、モニタリング情報に応答してアクション（たとえば、ロードバランシング、さらなるキャパシティー交渉など）を開始することができる場合がある。

リソース管理がＲＡＮノードにおいて提供されることが可能である。リソース共有が供され割り当てられている場合には、別々のネットワークノード、たとえばＲＡＮノードは、別々のオペレータの間におけるリソース共有割合または割り当てについて知らされることが必要となる場合があり、それによってＲＡＮリソースは、同じ割り当てに従って共有されることが可能になる。したがって、別々のオペレータの間におけるリソース割り当てについてＲＡＮノードに知らせるための手順または方法が定義されることが可能である。

複数のオペレータの間におけるリソース分割に関する情報をＲＡＮノードが有すると、ＲＡＮノードは、ＲＡＮにおいて使用されているリソースの平均量が、オペレータどうしの間において決められている割り当てを超過してはならないということを確実にすることができる。これを確実にするために、共有ＲＡＮ要素は、ネットワークリソース使用のアカウンティングを、たとえば常に、それぞれのＲＡＮ共有パートナーごとに別々に実行することができる。アカウンティング手順は、リソース割り当て取り決めが違反されないようにＲＡＮノードにおいて定義されることが可能である。

ＲＡＮノードが自分のキャパシティーの付近で、たとえば自分の割り当てられたリソース付近（close to its allocated resources）で機能している場合には、新たなベアラの許可は、複数のオペレータの間における共有取り決めに違反する可能性がある。そのようなシナリオを回避するためのポリシーおよび／または手順がＲＡＮノードにおいて使用されることが可能である。したがってＲＡＮノードは、そのようなポリシーおよび／または手順に基づいてベアラを受け入れることができ、特定のベアラを受け入れることがＲＡＮオペレータどうしの間における共有取り決めに違反する可能性がある場合には、それらを拒否することができる。そのようなポリシーおよび／または手順は、違反シナリオが発生しないように記述されることが可能である。

図５において示されている例示的なオペレータ仮想化アーキテクチャーは、別々のＲＡＮオペレータおよびサービスプロバイダが仮想化されることが可能である仮想ネットワークアーキテクチャーの例示的な実施態様であると言うことができ、ＷＴＲＵは、本明細書において開示されているような仮想クラウドの一部である任意のオペレータネットワークにアクセスすること、またはそうした任意のオペレータネットワーク上で機能することが可能であると言える。

図５は、別々のネットワークに属しているが仮想ネットワークの一部としてともに機能するグループＮＢおよびｅＮＢのＲＡＮレイヤを示している。これらのｅＮＢは、仮想ネットワークオペレーションのために確保されることが可能である特定の割り当てを有することができる。いくつかのケースにおいては、特定のネットワークからの全ｅＮＢが仮想ネットワークオペレーションのために使用されることが可能である。いかに仮想ネットワークｅＮＢまたはＲＡＮノードが、動的なキャパシティー割り当て、キャパシティーブローカレッジ、リソースモニタリング、および／またはロードバランシングを実行することができるかは明らかでない場合がある。これらのノードは、共通の仮想ネットワークリソースコントローラによってコントロールされることが可能であり、その共通の仮想ネットワークリソースコントローラは、仮想ネットワーク内のＲＡＮリソースのうちのいくつかまたはすべてを割り当てることまたは充当することが可能である。

クラウドの１または複数のレベルにおいて、たとえば、ＲＡＮレベルにおいて、ＣＮレベル、および／またはハイレイヤサービスレベルにおいてＡＰＩを公開することができるクラウドアーキテクチャーが、図５において示されている。ＲＡＮプロバイダクラウド５０６は、クラウドコントローラ５０８およびデータセンター５１０を含むことができ、それは、仮想ネットワークのＲＡＮレイヤ５１２と対話することができる。これらのノードは、処理のうちのいくらかをＲＡＮノード、たとえばｅＮＢ、ＨｅＮＢ、ＮＢなどから引き継ぐことができ、データの処理を中央で実行することができる。ＲＡＮプロバイダクラウド５０６は、仮想化されたＲＡＮを実施するためにＲＡＮレイヤ５１２と対話することができ、特定のＲＡＮ機能は、ＲＡＮプロバイダクラウド５０６へアウトソースされることが可能である。

どのＰＬＭＮ ＩＤがグローバルｅＮＢ ＩＤおよびＥ−ＵＴＲＡＮセルグローバル識別子（ＥＣＧＩ）内に含まれることが可能であるかについて混乱をもたらす可能性があるような方法で、同じｅＮＢに属している複数のセルが共有されることがあるＲＡＮ共有シナリオが存在する場合がある。これは、グローバルｅＮＢ ＩＤ／ＥＣＧＩの混乱をもたらす可能性がある。図８は、例示的なグローバルｅＮＢ／ＥＣＧＩ混乱シナリオを示している。

同じＰＬＭＮ ＩＤ、たとえば、ブロードキャストされているＰＬＭＮ ＩＤリスト内の最初のＰＬＭＮ ＩＤ（プライマリーＰＬＭＮ ＩＤ）が、グローバルｅＮＢ ＩＤおよびＥＣＧＩ内に含まれる場合がある。しかしながら、図８において示されている例示的なシナリオにおいては、グローバルｅＮＢ ＩＤ内でどのＰＬＭＮ ＩＤが選択されることが可能であるかはわからない場合がある。なぜなら、それぞれのセル８０２、８０４、８０６、または８０８、８１０、８１２は、別々のＰＬＭＮ ＩＤをブロードキャストしている可能性があるためである。別々のＰＬＭＮ ＩＤがグローバルｅＮＢ ＩＤおよびＥＣＧＩ内に入れられる可能性がある場合には、ネットワーク要素は、どのｅＮＢにセルが属しているかがわからない可能性がある。

この状況は、ハンドオーバー手順に影響を与える場合がある。ｅＮＢは、Ｓ１−ＡＰハンドオーバーメッセージをＭＭＥへ送信する場合には、ＬＴＥからＬＴＥへのハンドオーバーのケースにおいてはターゲットｅＮＢのグローバルｅＮＢ ＩＤをターゲットＩＤ ＩＥ内に含めることができる。ＭＭＥは、このグローバルｅＮＢ ＩＤを使用して、そのハンドオーバーメッセージをターゲットｅＮＢへ回送することができる。このメッセージ内に別々のＰＬＭＮ ＩＤが含まれる可能性がある場合には、ＭＭＥは、どのターゲットｅＮＢへこのハンドオーバーメッセージを転送すべきかがわからない可能性がある。本明細書において開示されている方法は、同じｅＮＢに属しているセルどうしが別々のＰＬＭＮ ＩＤをブロードキャストする場合にそのような混乱を回避するために使用されることが可能である。

ネットワーク共有キャパシティーブローカレッジアーキテクチャーが提供されることが可能である。本明細書において開示されているように、ＲＡＮオペレータにリソースを要求するためのさまざまな可能なアーキテクチャーが存在することが可能である。

図９は、キャパシティーブローカレッジのための例示的なアーキテクチャー９００を示している。図１０は、キャパシティーブローカレッジのための別の例示的なアーキテクチャー１０００を示している。図１１は、キャパシティーブローカレッジのためのさらに別の例示的なアーキテクチャー１１００を示している。

図９の例示的なアーキテクチャー９００においては、ブローカレッジコントロールユニット（ＢＣＵ）９０２は、さまざまなオペレータの間においてキャパシティーを管理することを担当することができる論理ノードであることが可能である。ＲＡＮオペレータ９０４は、図９において示されているように、ＢＣＵ９０２を実装することができる。

図１０の例示的なアーキテクチャー１０００においては、ＲＡＮを共有しているオペレータ１００４、１００６にサービス提供するためにマスターＢＣＵ１００２が使用されることが可能である。

図１１の例示的なアーキテクチャー１１００においては、それぞれのオペレータ１１０２、１１０４は、自分自身のＢＣＵ１１０６、１１０８を有することができる。ＢＣＵ１１０６、１１０８は、ＲＡＮリソースを共有していることが可能であるオペレータ１１０２、１１０４の間においてＲＡＮキャパシティーを管理するために互いに交渉することができる。ＢＣＵ１１０６、１１０８の機能は、被ホスト側オペレータから割り当て要求などのクエリーを受信することを含むことができる。ＢＣＵ１１０６、１１０８は、割り当て結果などのクエリーを被ホスト側オペレータへ送信することができることが可能である。ＢＣＵ１１０６、１１０８は、リソースが必要とされる可能性がある期間、リソースの量、および／またはＱｏＳ等などのその他のサービス属性など、オペレータどうしの間においてさまざまなリソースパラメータについて交渉することができることが可能である。ＢＣＵ１１０６、１１０８の機能は、限られたリソースを複数のオペレータが要求しているケースにおけるアービトレータ機能を含むことができる。たとえば、ＢＣＵ１１０６、１１０８は、限られたリソースのシェアをどのオペレータが得るか、ならびにそのシェアのサイズを決めることができる。ＢＣＵ１１０６、１１０８は、共有ＲＡＮから利用可能リソース情報を収集するように構成されることが可能である。ＢＣＵ１１０６、１１０８は、リソース確保を実施することができる共有ＲＡＮを示すことができる。ＢＣＵ１１０６、１１０８は、課金に関する使用統計を提供することができる。ＢＣＵ１１０６、１１０８は、使用されることが可能であるＲＡＮリソースの料金を被ホスト側オペレータに課金することができることが可能である。ＢＣＵ１１０６、１１０８は、利用可能なリソースをさまざまなオペレータへ定期的にブロードキャストすることができる。ＢＣＵ１１０６、１１０８は、承認されたオペレータにリソースが割り当てられることが可能であることを確実にするためにセキュリティーおよび／またはインテグリティーパラメータを提供することができる。

図１２、図１３、および図１４は、それぞれのＢＣＵ、およびさまざまなネットワークノードとの間でのそれらのインターフェースを伴うその他の例示的なアーキテクチャー１２００、１３００、および１４００を示している。これらのネットワークノードは、ＨＳＳ、ＰＣＲＦ、ＭＭＥ、ＲＡＮ、および／またはＯＡＭノード、ならびにその他のノードの組合せを含むことができる。たとえば、図１２において示されているように、ＢＣＵ１２０２は、被ホスト側オペレータ１２０８のＯＡＭノード１２０４およびＨＳＳノード１２０６とのインターフェースを取る。図１３において示されているように、ＲＡＮオペレータ１３０２は、ＲＡＮオペレータ１３０２のＯＡＭノード１３０６と、および被ホスト側オペレータ１３１０のＢＣＵ１３０８とインターフェースを取るＢＣＵ１３０４を含む。ＢＣＵ１３０８は、被ホスト側オペレータ１３１０のＯＡＭノード１３１２およびＨＳＳノード１３１４とインターフェースを取る。図１４は、ＲＡＮオペレータ１４０２および被ホスト側オペレータ１４０４が、課金システムとともに使用するためのそれぞれのＰＣＲＦノード１４０６、１４０８を有しているアーキテクチャー１４００を示している。ＢＣＵ１４１０、１４１２は、これらのＰＣＲＦノード１４０６、１４０８と、ならびにＯＡＭノード１４１４、１４１６、およびＨＳＳノード１４１８とインターフェースを取る。

本明細書において開示されているように、ＢＣＵは、論理ノードであることが可能である。この機能は、別々の物理的なネットワークノード内に存在することが可能である。ＢＣＵ機能は、１もしくは複数のネットワークノードの一部、またはネットワークノードの組合せであることが可能である。たとえば、ＢＣＵ機能は、ＭＭＥの一部であることが可能であり、別々のＢＣＵの間における通信は、ＭＭＥどうしの間におけるＳ１０インターフェースを使用することができる。ＢＣＵは、ｅＮＢの一部であることが可能であり、別々のＢＣＵの間における通信のためにＸ２インターフェースが使用されることが可能である。ＢＣＵは、ＨＳＳの一部であることが可能であり、ＢＣＵ通信のために２つのＨＳＳの間におけるインターフェースが使用されることが可能である。

ＢＣＵは、オペレータネットワーク内の物理的なスタンドアロンのノードであることが可能である。それは、ネットワークノードと通信することができ、ノードとのＢＣＵ通信を支援するためのインターフェースが提供されることが可能である。これらのインターフェースの例が、図９および図１０において示されている。

ＢＣＵ９０２と、要求側オペレータのＯＡＭノードとの間には、インターフェースＧｘａ９０６が存在することが可能である。ＯＡＭノードは、このインターフェースを介してクエリーおよび／または割り当て要求を送信することができ、半静的にまたは動的に結果を受信することができる。

要求側オペレータのＭＭＥと、ＢＣＵ９０２との間には、インターフェースＧｘｃ９０８が存在することが可能である。ＭＭＥは、登録されているＷＴＲＵの数およびそれらのトラフィックの情報を有することができる。この情報に基づいて、ＭＭＥは、このインターフェースを通じてキャパシティーを動的に要求することができる。このインターフェースは、図１１において示されているような、それぞれのネットワークがＢＣＵノードを採用しているケースにおけるＢＣＵからＢＣＵへの通信のために使用されることが可能である。

ＢＣＵと共有ＲＡＮとの間におけるインターフェースＧｘｂ９１０は、独自仕様のインターフェースであることが可能である。ＢＣＵは、ＲＡＮからリソース情報を収集することができ、このインターフェースを介して割り当てを実施するようＲＡＮに要求することができる。

ネットワークキャパシティー割り当てのためにユニットが提供されることが可能である。チャネルは、送信機と受信機との間における一方向接続の手段として定義されることが可能である。チャネルは、ダウンリンクチャネルまたはアップリンクチャネルであることが可能である。ベアラは、定義されたサービス品質（ＱｏＳ）要件を伴うＩＰパケットフローとして定義されることが可能である。本明細書において使用される際には、ベアラ、チャネル、およびベアラチャネルという用語は、交換可能に使用されることが可能である。

ユーザプレーン上では、ベアラチャネルは、たとえば、リソースタイプ（たとえば、保証ビットレート（ＧＢＲ）ベアラ対非ＧＢＲベアラ）、優先度、パケット遅延バジェット、および／またはパケットエラー損失率を含む複数のＱｏＳ特性によって記述されることが可能である。

たとえばＬＴＥにおいては、ＱｏＳコンセプトは、クラスベースであることが可能であり、それぞれのベアラは、４項目（リソースタイプ、優先度、パケット遅延バジェット、およびパケットエラー損失率）によって特徴付けられることが可能であるＱｏＳクラス識別子（ＱＣＩ）を割り振られることが可能である。

ＱＣＩは、ベアラのユーザプレーン処理を指定することができる。割り当ておよび保持優先度（ＡＲＰ）は、ベアラが受けるコントロールプレーン処理を指定することができる。たとえば、ＡＲＰは、ベアラ確立または修正要求が受け入れられることが可能であるか、またはリソース制限に起因して拒否されることが可能であるかを決めるためにコントロールプレーンにおいて使用されることが可能である。さらに、ＡＲＰは、リソース制限中にどのベアラをリリースすべきかを決めるために使用されることが可能である。

加えて、非ＧＢＲベアラは、サブスクライバーによって消費されるビットレートの総量をオペレータが制限することを可能にするために総合最大ビットレート（ＡＭＢＲ）によってコントロールされることが可能である。ＡＭＢＲは、非ＧＢＲベアラベースのグループごとに定義されることが可能である。たとえば、ＡＰＮ−ＡＭＢＲは、サブスクライバーごとに、およびＡＰＮごとに定義されることが可能であり、端末ＡＭＢＲは、サブスクライバーごとに定義されることが可能である。

無線インターフェース上で、ベアラチャネルは、周波数、時間、空間、および／またはコードというドメインのうちの１または複数においてネットワークリソースにマップされることが可能である。さらに、さまざまな変調およびコーディングスキーム（ＭＣＳ）ならびに複数の伝送レイヤが使用されることが可能である。たとえばＬＴＥにおいては、物理リソース要素（ＰＲＥ）は、ＯＦＤＭシンボル持続時間にわたってサブキャリアとして定義されることが可能である。周波数ドメインは、サブキャリアへと分割されることが可能であり、その一方で時間ドメインは、フレーム（１０ｍｓ）、スロット（０．５ｍｓ）、およびシンボルへと分割されることが可能である。物理リソースブロック（ＰＲＢ）は、０．５ｍｓのタイムスロット（ハーフサブフレーム）中に１２個のサブキャリア、たとえば、８４個のリソース要素（ノーマルサイクリックプレフィックス）または７２個のリソース要素（拡張サイクリックプレフィックス）から構成されることが可能である。リソースブロックはスロットにわたって定義されることが可能であるが、動的なスケジューリングのための基本的な時間ドメインユニットは、２つの連続したスロットから構成されているサブフレームであることが可能である。

被ホスト側オペレータに対するネットワークキャパシティーおよびネットワークスライス割り当てを表すために、複数のメトリックが個々にまたは任意の組合せで使用されることが可能である。１つのメトリックは、それぞれの定義されたＧＢＲデータレート、ＱＣＩ、およびＡＲＰ（ダウンリンク、アップリンク）に関する、利用できることが可能であるＧＢＲベアラの数、またはＧＢＲベアラ全体のうちで利用できることが可能である割合であることが可能である。別のメトリックは、それぞれの定義された非ＧＢＲデータレート、ＱＣＩ、およびＡＲＰ（ダウンリンク、アップリンク）に関する、利用できることが可能である非ＧＢＲベアラの数、または非ＧＢＲベアラ全体のうちで利用できることが可能である割合であることが可能である。別のメトリックは、それぞれのＡＰＮもしくはＡＰＮタイプに関するＡＰＮ−ＡＭＢＲ（もしくはＡＰＮ−ＡＭＢＲ−サブスクライバー）（ダウンリンク、アップリンク）の数、またはそれぞれのＡＰＮもしくはＡＰＮタイプに関する、ＡＰＮ−ＡＭＢＲの総数のうちで利用できることが可能である割合であることが可能である。ＡＰＮ−ＡＭＢＲは、サブスクライバーごとであること、したがってＡＰＮ−ＡＭＢＲ−サブスクライバーという表記であることが可能である。たとえば、被ホスト側オペレータが、オンデマンドの映画サービスに相当すると言えるＡＰＮに関する５４Ｍｂｐｓの非ＧＢＲの２００万のＡＰＮ−ＡＭＢＲを割り当てられる場合がある。次いで被ホスト側オペレータは、それぞれのサブスクライバーがそのサイトに対して一度に１つのＰＤＮ接続を有することができると想定すると、２００万人のサブスクライバーにサービス提供することができる。あるいは、共有されているネットワークがそのＡＭＢＲデータレートで１，０００万人のサブスクライバーをサポートすることができるならば、割合として表される同じ割り当ては２０％であると言える。別のメトリックは、端末−ＡＭＢＲ（ダウンリンク、アップリンク）の数、または端末−ＡＭＢＲ全体のうちで利用できることが可能である割合であることが可能である。別のメトリックは、ＰＤＮ接続の数、またはＰＤＮ接続全体のうちで利用できることが可能である割合であることが可能である。別のメトリックは、利用可能なＧＢＲ ＰＲＢの数、またはＧＲＢ ＰＲＢ（ダウンリンク、アップリンク）全体のうちの割合であることが可能である。別のメトリックは、利用可能なＧＢＲ ＰＲＥの数、またはＧＲＢ ＰＲＥ（ダウンリンク、アップリンク）全体のうちの割合であることが可能である。別のメトリックは、利用可能な非ＧＢＲ ＰＲＢの数、または非ＧＲＢ ＰＲＢ（ダウンリンク、アップリンク）全体のうちの割合であることが可能である。別のメトリックは、利用可能な非ＧＢＲ ＰＲＥの数、または非ＧＲＢ ＰＲＥ（ダウンリンク、アップリンク）全体のうちの割合であることが可能である。別のメトリックは、ＰＲＢの総数、またはＰＲＢの総数のうちの割合であることが可能である。別のメトリックは、ＰＲＥの総数、またはＰＲＥの総数のうちの割合であることが可能である。別のメトリックは、周波数帯域（もしくは所与の周波数帯域内の帯域幅、もしくはサブキャリアの数）、または利用可能な周波数帯域のうちの割合であることが可能である。別のメトリックは、期間、たとえばスロット、サブフレーム、もしくはフレーム、１日のうちの秒、分、もしくは時間での期間であること、または始点および終点によって定義されることが可能である。別のメトリックは、コード、たとえば利用可能なコードの割合、またはコードの数であることが可能である。別のメトリックは、伝送レイヤ、たとえば、セルあたりの伝送レイヤの数であることが可能である。別のメトリックは、アクセスプリアンブルの数、または利用可能なアクセスプリアンブルの割合であることが可能である。別のメトリックは、コントロールチャネル要素の数、または利用可能なコントロールチャネル要素の割合であることが可能である。別のメトリックは、任意の所与の時点で接続モードにあると言えるＷＴＲＵの平均数、およびそれらのＷＴＲＵによって転送されることが可能であるデータの平均量、またはＷＴＲＵの総数のうちで所与の時点で接続モードにあると言える割合であることが可能である。別のメトリックは、セル内にいると言えるＷＴＲＵの総数もしくは割合、およびＷＴＲＵあたりのＥＰＳベアラの数もしくは割合、またはセル内のベアラの総数であることが可能である。この情報は、ベアラのＱＣＩを含むこともできる。別のメトリックは、ＩＰアドレスまたはＭＳＩＳＤＮまたはＵＲＩまたはその他の任意の端末もしくはアプリケーションアドレスの数または割合であることが可能である。

約束されたキャパシティーからの逸脱を測定することの一環としてコール／セッション脱落率が使用されることが可能である。コール／セッション脱落率は、ＧＢＲベアラあたりのかつＱＣＩあたりの、非ＧＢＲベアラあたりのかつＱＣＩあたりの、ＡＰＮあたりの、端末あたりの（もしくはユーザあたりの）など、またはそれらの任意の組合せでの総脱落率を含むことができる。コール／セッション試行失敗率は、ＧＢＲベアラあたりのかつＱＣＩあたりの、非ＧＢＲベアラあたりのかつＱＣＩあたりの、ＡＰＮあたりの、端末（もしくはユーザ）あたりのなど、またはそれらの任意の組合せでの総失敗率を含むことができる。約束されたキャパシティーからの逸脱を測定することの一環としてハンドオーバー試行失敗率が使用されることが可能である。ハンドオーバー試行失敗率は、ＧＢＲベアラあたりのかつＱＣＩあたりの、非ＧＢＲベアラあたりのかつＱＣＩあたりの、ＡＰＮあたりの、端末（もしくはユーザ）あたりのなど、またはそれらの任意の組合せでの総失敗率を含むことができる。

使用されるメトリックまたはメトリックの組合せは、ネットワーク共有展開シナリオおよび取り決めに依存する場合がある。たとえば、ネットワーク所有者がネットワークオペレーションを管理することができるネットワーク共有シナリオに関しては、ネットワークキャパシティー割り当ては、利用できることが可能であるＧＢＲベアラの数、利用できることが可能である非ＧＢＲベアラの数、ＡＰＮ−ＡＭＢＲの数、および／または端末−ＡＭＢＲの数などの４つのメトリックに基づくことが可能である。同様に、被ホスト側オペレータがネットワークの行動を管理およびコントロールするネットワーク共有シナリオに関しては、ネットワークキャパシティー割り当ては、ＰＲＢメトリック、または、上述のメトリック、たとえば、ＰＲＢメトリック、ＰＲＥメトリック、周波数帯域、期間、コード、および／もしくは伝送レイヤの数というメトリックのうちのすべてもしくはいくつかの組合せの点から表されることが可能である。これは、共有フレームワークが、被ホスト側オペレータの構成の好みに従ったネットワークの構成および／または管理を可能にすることができる場合に実行されることも可能である。

動的なリソース共有が実行されることが可能である。必要とされる可能性があるリソースを被ホスト側オペレータが識別することを可能にするための１または複数の方法が提供されることが可能である。被ホスト側オペレータは、さらなるリソースが必要とされる可能性があるかどうかを識別するために自分のネットワークにおいてさまざまなパラメータをモニタすることができる。これらのパラメータは、領域内のＷＴＲＵにサービス提供することができるｅＮＢベースまたはｅＮＢのグループごとであることが可能である。これらのｅＮＢは、これらのパラメータをネットワーク内の論理エンティティーへ定期的に送信することができ、またはネットワークノードによって要求された場合にこれらのパラメータを送信することができる。ｅＮＢどうしは、これらのパラメータを自分たちの間において、たとえばＸ２インターフェースを介して、やり取りすることができる。

被ホスト側オペレータＲＡＮは、物理的な無線リソース、データレート、ビットレート、接続モードにあると言えるＷＴＲＵの平均数、セル内にいると言えるＷＴＲＵの総数、着信および発信ハンドオーバー要求の平均数、ＷＴＲＵ上で実行されているアプリケーションのタイプ、ネットワーク内にいると言えるローミングしているＷＴＲＵの数など、またはそれらの任意の組合せなど、１または複数のパラメータを分析することによって、さらなるリソースが必要とされる可能性があるかどうかを識別することができる。

被ホスト側オペレータＲＡＮは、ｅＮＢまたはｅＮＢのグループにおいてさまざまなＷＴＲＵによって使用されることが可能である物理的な無線リソースを分析することによって、さらなるリソースが必要とされる可能性があるかどうかを識別することができる。これらのリソースは、アクセスプリアンブル、コントロールチャネル要素、ＰＤＳＣＨ／ＰＵＳＣＨの１または複数のＰＲＢ、ＰＵＣＣＨリソースなどを含むことができる。

被ホスト側オペレータＲＡＮは、データレートまたはビットレート（ＰＤＣＰ／ＲＬＣ、メイクレベルにおける総ビットレート、および／またはそのｅＮＢのカバレッジのもとでそれぞれのＷＴＲＵに提供されるビットレートであることが可能である）を分析することによって、さらなるリソースが必要とされる可能性があるかどうかを識別することができる。

被ホスト側オペレータＲＡＮは、所与の時点で接続モードにあると言えるＷＴＲＵの平均数、およびそれらのＷＴＲＵによって転送されるデータの平均量を分析することによって、さらなるリソースが必要とされる可能性があるかどうかを識別することができる。

被ホスト側オペレータＲＡＮは、セル内のＷＴＲＵの総数、およびＷＴＲＵあたりのＥＰＳベアラの数、またはセル内のベアラの総数を分析することによって、さらなるリソースが必要とされる可能性があるかどうかを識別することができる。この情報は、ベアラのＱＣＩを含むこともできる。

被ホスト側オペレータＲＡＮは、所与の量の時間にわたる着信および発信ハンドオーバー要求の平均数を分析することによって、さらなるリソースが必要とされる可能性があるかどうかを識別することができる。着信ハンドオーバー要求の量が、発信ハンドオーバー要求の量よりも多い場合には、被ホスト側ネットワークは、さらなるリソースを求める要求をトリガーすることができる。

被ホスト側オペレータＲＡＮは、所与のセル内のＷＴＲＵ上で実行されているアプリケーションのタイプを分析することによって、さらなるリソースが必要とされる可能性があるかどうかを識別することができる。アプリケーションのタイプの細かさは、音声アプリケーションまたは非音声アプリケーションであることが可能であり、または、よりいっそう高度な細かさ、たとえば、ビデオ、インタラクティブ、ソーシャルネットワーキング、ゲーミングなどであることが可能である。

被ホスト側オペレータＲＡＮは、ネットワーク内のローミングしているＷＴＲＵの数を分析することによって、さらなるリソースが必要とされる可能性があるかどうかを識別することができる。

リソースを要求するための方法が、被ホスト側オペレータによって使用されることが可能である。被ホスト側オペレータは、たとえば手動モデルおよび／または自動モデルを使用して、ＲＡＮオペレータにリソースを要求することができる。手動モデルにおいては、要求側オペレータは、いつどれぐらい多くのリソースを自分が必要とする可能性があるかを事前に知ることができ、ＯＡＭ手順を介してキャパシティー割り当てを要求することができる。これは、半静的なモデルであるとも言える。このモデルにおいては、さらなるキャパシティーが、別々のオペレータの間において、別々のオペレータの間における取り決めに基づいて交渉されることが可能である。オペレータは、さらなるキャパシティーを要求するか、または被ホスト側オペレータに割り振られているキャパシティーをキャンセルするためのアーキテクチャーを使用することができる。自動モデルにおいては、被ホスト側オペレータネットワークは、たとえば、本明細書において開示されている方法を使用して、ＲＡＮリソースが十分ではない可能性があると自動的に判定することができ、さらなるリソースを割り当ててほしいという要求をホスト側オペレータに送信することができる。これは、完全に動的なモデルであると言える。

被ホスト側オペレータは、ＲＡＮオペレータにリソースを要求するために、本明細書において開示されているアーキテクチャーを使用することができる。被ホスト側オペレータは、リソースを提供することができる可能性がある利用可能なＲＡＮオペレータを発見することができる。この発見は、本明細書において開示されている方法のうちの１または複数を使用して実行されることが可能である。

発見は、ＯＡＭ手順を使用して実行されることが可能である。被ホスト側オペレータは、ＲＡＮオペレータとの取り決めを有することができる。被ホスト側オペレータは、自分の取り決めを通じてＢＣＵの宛先アドレス（たとえば、トランスポートレイヤまたはＩＰアドレスなど）を受信することができ、それによって、さらなるリソースを必要とする可能性がある場合には、ＲＡＮオペレータのＢＣＵに連絡を取ることができる。

発見は、ＨＳＳによってサポートされることが可能である。被ホスト側オペレータは、ＲＡＮオペレータのアドレスを含むことができる情報を見つけ出すために自分のＨＳＳにクエリーを行うことができる。ＨＳＳは、１または複数の利用可能なＲＡＮオペレータを伴って応答することができる。次いでＢＣＵは、リソースを要求するためにこれらのオペレータに連絡を取ることを決めることができる。

発見は、発見サーバによって実行されることが可能である。発見サーバは、ＭＶＮＯまたは被ホスト側オペレータにＲＡＮリソースを提供することを厭わない利用可能なＲＡＮオペレータのデータベースを有することができる。被ホスト側オペレータは、アドレス情報など、ＲＡＮオペレータに関する情報を受信するために発見サーバに連絡を取ることができる。

ＲＡＮオペレータを発見した後に、被ホスト側オペレータは、利用可能なリソースを求めてＲＡＮオペレータにクエリーを行うことができる。これは、クエリーメッセージ、たとえば「キャパシティークエリー要求」または類似のメッセージをＲＡＮオペレータまたはＲＡＮオペレータのＢＣＵに送信することによって実行されることが可能である。そのクエリーメッセージを送信するために、図９〜図１４において示されているアーキテクチャーが使用されることが可能である。

図１５は、被ホスト側オペレータとＲＡＮオペレータとの間における例示的なメッセージ交換１５００を示している。図１５において示されているように、ＯＡＭ／ＭＭＥノード１５０２は、別のＢＣＵノード、たとえば被ホスト側オペレータＢＣＵであることも可能である。図１５において示されているように、被ホスト側オペレータは、キャパシティークエリー要求１５０４をＲＡＮオペレータに、たとえばＲＡＮオペレータのＢＣＵ１５０６に送信することができる。このメッセージは、被ホスト側オペレータの識別情報（ＰＬＭＮ＿ＩＤ）、ロケーション（ｃｅｌｌ＿ｉｄ＿ｌｉｓｔなど）、要求のタイプ（定期的なもしくは１回限りの要求）、利用可能なリソースタイプ（たとえば、本明細書において開示されているリソースタイプ）、リソースが必要とされる可能性がある期間、現在の使用、必要とされるリソースのＱｏＳなど、またはそれらの任意の組合せを含むことができる。

要求を受信すると、ＢＣＵ１５０６は、要求メッセージ内に含まれているパラメータを検討することができ、キャパシティークエリー結果１５０８または利用可能リソースステータスを伴って応答することができる。キャパシティークエリー結果は、トランザクションＩＤ、利用可能なリソースのタイプの応答（要求に対する定期的な回答など）、要求側オペレータの識別情報（ＰＬＭＮ＿ＩＤ）、ロケーション（ｃｅｌｌ＿ｉｄ＿ｌｉｓｔなど）、利用可能なリソースタイプのリスト、利用可能なリソースの量、利用可能なリソースのＱｏＳ属性、利用可能なリソースのうちのそれぞれの期間、利用可能なリソースのうちのそれぞれを被ホスト側オペレータが使用することができるか否かを識別するためのパラメータ、被ホスト側オペレータが使用することを許可されることが可能であるセルもしくはリソースの最大割合、利用可能なリソースの課金パラメータおよびレートなど、またはそれらの任意の組合せを含むことができる。

キャパシティークエリー要求１５０４を受信すると、ＢＣＵ１５０６は、最新の割り当てられたネットワークキャパシティーと整合するように選択されたネットワークノードの構成または再構成をトリガーすることができる。ＢＣＵ１５０６は、影響されるノードの構成の後にキャパシティークエリー結果１５０８を送信することができる。

いくつかのケースにおいては、ＢＣＵ１５０６は、選択されたネットワークノードの構成または再構成をトリガーしないことが可能である。次いで被ホスト側オペレータ内のＢＣＵノードのＯＡＭ／ＭＭＥ１５０２は、キャパシティークエリー結果１５０８メッセージを受信すると、関連するネットワークノード内の割り当てられたリソースを構成することができる。キャパシティークエリー結果１５０８は、被ホスト側オペレータに割り当てられたネットワークノードのアイデンティティーを含むことができる。

リソースを許可するための１または複数の方法がＲＡＮオペレータにおいて使用されることが可能である。被ホスト側オペレータが、利用可能なリソースに関する情報を定期的に、またはＢＣＵによって送信された要求に対する応答として受信した場合には、ネットワーク要素は、利用可能なリソースに関するその情報を使用して、ＲＡＮオペレータに対するリソースを求める要求のメッセージを作成することができる。ネットワーク構成、オペレータ間の取り決め、および／またはその他の要因に応じて、リソースを求める要求のメッセージは、リソースが必要とされる可能性があるときに送信されることが可能である。被ホスト側オペレータは、要求をいくらか前の時点で送信することもできる。被ホスト側オペレータから要求を受信すると、ＲＡＮオペレータは、被ホスト側オペレータに対してリソースを許可することも、または許可しないことも可能である。ＲＡＮオペレータは、被ホスト側オペレータに対してリソースを許可する場合には、要求されているリソースの一部を許可することができる。利用可能なリソースのステータスは、被ホスト側オペレータがキャパシティークエリー結果１５０８または類似のメッセージを最後に受信したときから変わっている場合がある。このケースにおいては、被ホスト側オペレータがリソース割り当て要求を受信して、その割り当て要求が、利用可能なリソースのステータスと整合していない場合には、それは、その割り当て要求を拒否することができ、利用可能リソースステータスまたは図１５のキャパシティークエリー結果１５０８メッセージを被ホスト側オペレータへ送信することができる。拒否は、被ホスト側オペレータに対して、新たな割り当てステータスに基づいて要求を再び試みることができるということを示すこともできる。

図１６は、例示的なキャパシティー割り当て要求／応答手順を示している。図１６は、さらなるリソースをＲＡＮオペレータに要求するために使用されることが可能であるキャパシティー割り当て要求／応答メッセージ交換１６００を示している。示されているＯＡＭ／ＭＭＥノードは、別のＢＣＵノード、たとえば被ホスト側オペレータＢＣＵであることも可能である。キャパシティー割り当て要求１６０２は、トランザクションＩＤ、要求側オペレータの識別情報（ＰＬＭＮ＿ＩＤ）、１または複数のロケーション（ｃｅｌｌ＿ｉｄ＿ｌｉｓｔなど）、割り当て要求のタイプ（緊急要求、非緊急要求、キャリアアグリゲーションなど）、リソースが必要とされる可能性がある時刻、リソースが必要とされる可能性がある時間の量、要求されているリソースタイプ、リソースの要求されている量、ＱｏＳ属性等など、１または複数のパラメータまたはＩＥを含むことができる。キャパシティー割り当て結果または受け入れメッセージ１６０４は、トランザクションＩＤ、結果（割り当てられた、割り当てられなかった、部分的に割り当てられたなど）、割り当てられたリソースのセルＩＤ、割り当てられたリソースタイプ、割り当てられたリソース量、ＱｏＳ属性、割り当てられた期間、被ホスト側オペレータがそれらのリソースを使い始めることができる時刻、被ホスト側オペレータがそのリソースを撤去することができるかどうか、ＲＡＮオペレータがそのリソースを撤去することができるかどうか、その同じリソースまたはその同じリソースのプールを共有している可能性があるその他のオペレータまたはＰＬＭＮに関する情報等など、１または複数のパラメータを含むことができる。

ＲＡＮオペレータが同時に別々の被ホスト側オペレータから同時要求を受信する可能性がある状況が存在する場合がある。この競合状況においては、複数のオペレータが、時間のピリオドにおいて利用可能なキャパシティーよりも多くを要求する可能性がある場合に、ＢＣＵは、要求側オペレータどうしの間においてリソースをどのように割り当てるべきかを決めることが必要となる可能性がある。要求側オペレータどうしは、別々の優先度を与えられることが可能であり、それらの優先度に従ってキャパシティーを配分するための別々のオペレーションが存在することが可能である。たとえば、１位の優先度の関係者は、自分が要求したものを得ることができる。残りが、２位の優先度の関係者が要求しているものよりも多いと言える場合には、２位の優先度の関係者は、自分が要求したものを得ることができる。そうでない場合には、２位の優先度の関係者は、残りを得ることしかできない。別の例として、それぞれの優先度の関係者が、等しいまたは公平な量のリソースをはじめに得ることができ、残りが優先順に配分されることが可能である。別の例として、それぞれの優先度が重み付けを与えられることが可能であり、リソースが十分であると言える場合には、「要求されている優先度^*重み付け」が割り当てられることが可能である。別の例として、優先度は、リソースが割り当てられることが可能であるアプリケーションのタイプに基づくことが可能である。

リソースは、早いもの順に割り当てられることも可能であり、それによって、より早い要求が最初に満たされることが可能になる。オペレータがこのタイプのポリシーに準拠する場合には、それに対していくつかの例外が存在することが可能である。たとえば、緊急リソース割り当てを求める着信要求が存在する可能性がある場合の例外が存在することが可能である。

再び図１５を参照すると、ＢＣＵは、キャパシティークエリー要求１５０４を受信すると、最新の割り当てられたネットワークキャパシティーと整合するように選択されたネットワークノードの構成または再構成をトリガーすることができる。ＢＣＵは、影響されるノードの構成の後にキャパシティークエリー結果１５０８を送信することができる。

あるいは、ＢＣＵは、選択されたネットワークノードの構成または再構成をトリガーしないことが可能である。次いで被ホスト側オペレータドメイン内のＢＣＵノードのＯＡＭ／ＭＭＥは、キャパシティークエリー結果１５０８メッセージを受信すると、関連するネットワークノード内の割り当てられたリソースを構成することができる。キャパシティークエリー結果１５０８メッセージは、被ホスト側オペレータに割り当てられたネットワークノードのアイデンティティーを含むこともできる。

ホスト側オペレータが、静的な構成または動的なオンデマンド要求の結果として、特定の被ホスト側オペレータに関してリソース共有を許可することに合意した場合には、ホスト側オペレータは、その参加オペレータのＰＬＭＮアイデンティティーを、ブロードキャストされるＰＬＭＮアイデンティティーリスト内に加えて、そのＰＬＭＮをＷＴＲＵにとって選択可能にすることができる。同様に、ホスト側オペレータは、特定のオペレータに関して共有をやめる必要がある場合、たとえば、その参加オペレータが共有リソース持ち分を使い果たした場合には、そのオペレータのＰＬＭＮアイデンティティーを、ブロードキャストされるＰＬＭＮアイデンティティーリストから除去することができる。

リソースを撤去またはキャンセルするための１または複数の方法が使用されることが可能である。使用されていない割り当てられたリソースは、被ホスト側オペレータまたはＲＡＮオペレータによってキャンセルまたは撤去されることが可能である。割り当てられたリソースをキャンセルしたいと望むオペレータは、リソースを撤去するためのキャンセレーション要求を他方のオペレータへ送信することができる。リソースをキャンセルするという最終的な決定は、いずれのケースにおいてもＲＡＮオペレータによって行われることが可能である。図１７は、被ホスト側オペレータによって開始されることが可能である例示的なリソースキャンセレーションプロセス１７００を示している。図１７に示されているプロセスにおいては、示されているＯＡＭ／ＭＭＥノード１７０２は、別のＢＣＵノード、たとえば、被ホスト側オペレータＢＣＵであることも可能である。キャパシティー割り当てキャンセレーション要求１７０４において搬送される情報は、トランザクションＩＤ、要求側オペレータの識別情報（ＰＬＭＮ＿ＩＤ）、ロケーション（ｃｅｌｌ＿ｉｄ＿ｌｉｓｔなど）、キャンセルされるリソースタイプ、キャンセレーションに関する理由、キャンセルされるリソースの量、キャンセルされる期間、リソースがキャンセルされることが必要となる時刻、いくつのリソースがキャンセルされることが必要となる可能性があるかを示すことができるパラメータなど、またはそれらの任意の組合せを含むことができる。このメッセージは、リソースパラメータ、たとえば、ＱｏＳなどを修正するために使用されることも可能である。

ＲＡＮオペレータ、たとえば、ＲＡＮオペレータのＢＣＵ１７０６は、このメッセージを受信した場合には、キャパシティーキャンセレーション結果メッセージ１７０８を伴って応答することができる。キャパシティーキャンセレーション結果メッセージ１７０８は、トランザクションＩＤ、要求側オペレータの識別情報（ＰＬＭＮ＿ＩＤ）、ロケーション（ｃｅｌｌ＿ｉｄ＿ｌｉｓｔなど）、キャンセレーション結果（たとえば、受け入れた、受け入れなかった、部分的に受け入れたなど）、もしあればキャンセレーション料金もしくは手数料など、またはそれらの任意の組合せを含むことができる。

図１８は、ＲＡＮオペレータによって開始されることが可能である例示的なリソースキャンセレーションプロセス１８００を示している。本明細書において開示されているように、リソースは、ＲＡＮオペレータによってキャンセルされることも可能である。図１８において示されているように、ＲＡＮオペレータ内のＢＣＵ１８０２は、使用されていない割り当てられたリソースをキャンセルするためのキャパシティー割り当てキャンセレーション通知１８０４を被ホスト側オペレータ、たとえば、被ホスト側オペレータ内のＯＡＭ／ＭＭＥノード１８０６へ送信することができる。キャパシティー割り当てキャンセレーション通知１８０４は、トランザクションＩＤ、要求側オペレータの識別情報（ＰＬＭＮ＿ＩＤ）、ロケーション（ｃｅｌｌ＿ｉｄ＿ｌｉｓｔなど）、キャンセレーションに関する理由、キャンセルされるリソースの量、キャンセルされる期間、リソースがキャンセルされることが必要となる時刻、いくつのリソースがキャンセルされることが必要となる可能性があるかを示すことができるパラメータ、次のリソース要求が被ホスト側オペレータによっていつ送信されるべきかを示すことができるパラメータなど、またはそれらの任意の組合せを含むことができる。キャパシティー割り当てキャンセレーション通知１８０４は、リソースパラメータ、たとえば、ＱＣＩ、ＱｏＳなどを修正するために使用されることも可能である。このメッセージを受信すると、被ホスト側オペレータは、それに応じて肯定応答（ＡＣＫ）１８０８を送信することも、または送信しないことも可能である。

キャパシティークエリー要求を受信すると、ＢＣＵは、最新の割り当てられたネットワークキャパシティーと整合するように選択されたネットワークノードの構成または再構成をトリガーすることができる。ＢＣＵは、影響されるノードの構成の後にキャパシティークエリー結果を送信することができる。

別の例においては、ＢＣＵは、選択されたネットワークノードの構成または再構成をトリガーしないことが可能である。被ホスト側オペレータドメイン内のＢＣＵノードのＯＡＭ／ＭＭＥは、選択されたノードを最新のリソース割り当てステータスと整合するように構成または再構成することができる。

一例においては、ホスト側ＲＡＮオペレータ、たとえば、ＵＴＲＡＮホスト側オペレータは、ドメイン固有のネットワーク共有を被ホスト側オペレータまたは参加オペレータに提供することができる。ドメイン固有のネットワーク共有は、共有されているリソースの使用を、特定のドメイン、たとえば、ＣＳドメインのみ、またはＰＳドメインのみに制限することができる。

ドメイン固有のネットワーク共有は、ＰＬＭＮ固有の設定であることが可能であり、たとえば、別々の参加オペレータごとに、別々の設定（たとえば、ＣＳドメイン共有のみ、ＰＳドメイン共有のみ、ＣＳおよびＰＳドメイン両方の共有など）を有することができ、またはホスト側ＲＡＮは、すべての参加オペレータに関して共通の設定を使用することができる。

ホスト側ＲＡＮは、自分のドメイン固有の共有設定を自分のシステム情報内に含めてブロードキャストすることができる。このブロードキャストされる設定は、たとえば、すべての参加オペレータに関する、もしくは、このシステム情報内のＰＬＭＮ固有の設定を有していない参加オペレータに関する共通のドメイン固有の設定、および／または、参加オペレータのうちのいくつかもしくはすべてに関するＰＬＭＮ固有の設定のリストなどの情報を含むことができる。共通の設定またはＰＬＭＮ固有の設定は、ＣＳドメインのみの共有、ＰＳドメインのみの共有、ならびに／またはＣＳおよびＰＳドメイン両方のみの共有などのオプションを有することができる。

ドメイン固有の共有設定は、ＰＬＭＮアイデンティティーリストとともに、ＳＩＢ１内に含めてブロードキャストされることが可能であり、それによってＷＴＲＵは、ＰＬＭＮを選ぶ前にその設定を取得することができる。あるいは、ドメイン固有の共有設定は、ＳＩＢ１以外のその他のＳＩＢ内に含めてブロードキャストされることが可能である。ＷＴＲＵは、自分のドメイン固有のアクセス制限を知らずにＰＬＭＮを選ぶことができる。

ドメイン固有の共有設定がＳＩＢ１内に含めてブロードキャストされる場合には、ＷＴＲＵは、これらの設定をＰＬＭＮ選択手順の中で考えることができる。たとえば、音声またはＳＭＳに関してＣＳドメインを使用するように構成されているＷＴＲＵは、ＰＳドメインのみとして指定されているＰＬＭＮを選択しないことが可能である。

ドメイン固有の共有設定がＳＩＢ１以外のＳＩＢ内に含めてブロードキャストされる場合には、ＷＴＲＵは、自分のドメイン固有の共有設定を問わずにＰＬＭＮを選ぶことができる。セルにキャンプインした後に、ＷＴＲＵは、ドメイン固有の共有設定を有するＳＩＢを取得することができ、それらの設定が適切でないことがわかった場合には、別のＰＬＭＮ、もしくはその同じＰＬＭＮの別の適切なセルを再選択すること、そのセルを禁止とラベル付けすること、選択されたＰＬＭＮの優先度を時間の特定のピリオドにわたって下げること（たとえば、タイマーが始動されることが可能であり、そのタイマーが切れた時点でＰＬＭＮ優先度が元に戻されることが可能である）、および／または、ＰＬＭＮを時間の特定のピリオドにわたって利用不能もしくは不許可とラベル付けすること（たとえば、タイマーが始動されることが可能であり、そのタイマーが切れた時点でＰＬＭＮ可用性が元に戻されることが可能である）が可能である。

ドメイン固有の共有設定は、動的に変わることも可能である。ＷＴＲＵは、通常のシステム情報更新手順に準拠して、新たな設定を取得することができる。新たな設定が、アクティブな接続を既に有しているＷＴＲＵにとって不利に、たとえば、そのＷＴＲＵがＰＳモードＷＴＲＵである場合にＰＳドメインのみの共有からＣＳドメインのみの共有へ変わったならば、ホスト側オペレータは、そのＷＴＲＵに引き続きサービス提供すべきか、またはそのＷＴＲＵとの接続を切るべきかを判定することができる。

参加オペレータは、ホスト側オペレータの共有設定を、ＯＡＭ構成によって、またはシステム間のシグナリング交換によって認識することができる。参加オペレータは、ＷＴＲＵを、たとえばロードバランシングのために、またはＣＳコールフォールバックのためにホスト側ＲＡＮへリダイレクトしようと試みるときに共有設定について考える場合がある。

図１９は、例示的な論理課金アーキテクチャー１９００ならびにオフライン課金およびオンライン課金に関する情報フローを示している。例示的な課金機能が、オンライン課金システム１９０２へのインターフェース、およびオフライン課金システム１９０４へのインターフェースを伴って図１９において示されている。ｅＮＢまたはＲＡＮサブシステム１９０６が、仮想化またはＲＡＮ共有ケースにおいて採用されることが可能である。ＲＡＮノードまたはｅＮＢは、オンラインケースまたはオフラインケースにおいて課金イベントをトリガーすることができる。

図２０および図２１は、オフライン課金システム２０００およびオンライン課金システム２１００を、それぞれＲＡＮサブシステムとともに示している。両方のシステムにおいて、ＲＡＮノードは、課金トリガー機能（ＣＴＦ）２００２、２１０２を有することができ、ＲＡＮリソースおよびその他のネットワークリソースの観察に基づいて課金イベントを生成することができる。これらの課金イベントは、ＲＡＮ／ｅＮＢによって課金データ機能（ＣＤＦ）２００４へ直接送信されることが可能であり、ＣＤＦ２００４は、課金レコード（ＣＲＤ）を作成することができ、そのＣＲＤは、課金ゲートウェイ機能（ＣＧＦ）２００６、２１０６へ送信されることが可能である。ＣＧＦ２００６、２１０６は、オフライン課金システム２０００のための料金請求ドメイン２００８への直接のインターフェースを有することができる。

被ホスト側オペレータＷＴＲＵがＲＡＮオペレータへハンドオーバーされる場合には、ＲＡＮオペレータは、そのＷＴＲＵが被ホスト側オペレータセルからハンドオーバーされているかどうかのチェックを実行することができ、またはＲＡＮオペレータは、課金イベントがトリガーされることが必要であるかどうかを判定するためにチェックを行うことができる。課金イベントは、たとえば、そのハンドオーバーがＲＡＮオペレータ内のシームレスなハンドオーバーである場合には、トリガーされないことが可能である。

このチェックは、ハンドオーバーの前に実行されることが可能である。ソースｅＮＢは、ターゲットｅＮＢのＥＣＧＩを含むことができる測定を受信することができる。ソースセルは、ターゲットセルが同じオペレータに属しているか否かを、ＥＣＧＩ内に含まれているＰＬＭＮ ＩＤから知ることができる。ターゲットセルがＲＡＮオペレータに属しているということをソースセルが判定した場合には、ソースセルは、課金イベントがトリガーされることが必要であるという旨をターゲットセルへのハンドオーバー要求メッセージ内に含めることができる。あるいは、ソースセルは、課金イベントが生じることが可能であるということをソースＭＭＥまたはターゲットＭＭＥに通知することができ、次いでそのＭＭＥは、ターゲットｅＮＢへのパス切り替え要求メッセージまたはその他の任意のＳ１−ＡＰにおいて課金イベントをトリガーするようソースセルに知らせることができる。あるいは、それは、イベントそのものをトリガーすることができる。なぜなら、ターゲットセルは、その後のハンドオーバーに関する課金イベントを認識することができるためである。

別の例として、ターゲットｅＮＢは、特定の近隣セルまたはｅＮＢからのハンドオーバーが特定のオペレータに属しているかどうかをＯＡＭ構成またはその他のネットワーク構成から判定することができる。この情報は、特定のハンドオーバーがＲＡＮオペレータ間のハンドオーバーであるか、または被ホスト側オペレータセルとＲＡＮオペレータセルとの間におけるハンドオーバーであるかをｅＮＢが判定する上で役立つことができる。この情報は、課金イベントをトリガーすべきかどうかを判定するためにターゲットｅＮＢによって使用されることが可能である。

ＭＭＥ間のハンドオーバー、たとえば、被ホスト側オペレータＭＭＥからＲＡＮオペレータへのハンドオーバーのケースにおいては、ターゲットＭＭＥは、ソースＭＭＥからのＷＴＲＵコンテキストから、そのＷＴＲＵが被ホスト側オペレータに属しているということを判定することができる。次いでＭＭＥは、課金イベントをトリガーするよう、課金システムに関与しているＲＡＮ、Ｐ−ＧＷ、ＰＣＥＦ、ＰＣＲＦ、またはその他の任意のノードに知らせることができる。

ＢＣＵは、ＲＡＮオペレータｅＮＢのリストを伴って構成されることも可能である。ＢＣＵは、ＷＴＲＵが特定のｅＮＢのカバレッジのもとにあるということを判定した場合には、その特定のｅＮＢに関する課金イベントを開始するよう、対応するＭＭＥおよび／またはｅＮＢに知らせることができる。

アイドルモードモビリティーのケースにおいては、課金イベントは、ＷＴＲＵが新たなセルにおいてトラッキングエリア更新またはロケーションエリア更新を実行した場合にトリガーされることが可能である。ＴＡＵメッセージを受信すると、ターゲットシステム内のＭＭＥ（新たなＭＭＥ）は、ソースＭＭＥ（古いＭＭＥ）にＷＴＲＵコンテキストを要求することができる。ＷＴＲＵが被ホスト側オペレータに属しているということを知らせる新たな表示が、古いＭＭＥからのコンテキスト応答メッセージ内に付加されることが可能である。この表示は、ターゲットＭＭＥにおいて課金イベントをトリガーすることができる。ターゲットＭＭＥは、対応する課金プロセスを開始するための表示を、課金システムに関与しているＰ−ＧＷ、ＰＣＥＦ、ＰＣＲＦ、またはその他の任意のノードへ送信することができる。

別の例として、ＷＴＲＵは、自分が被ホスト側オペレータに属しているということをＭＭＥに示す表示をＴＡＵ要求メッセージ内に含めて送信することができる。次いでＭＭＥは、本明細書において開示されている課金ノードを用いて課金イベントをトリガーするために、この表示を使用することができる。

課金イベントがトリガーされた後に、ＲＡＮオペレータにおける課金ノードは、課金またはアカウンティングレコードまたは情報を被ホスト側オペレータのＢＣＵまたはその他の任意の課金コントロールまたはＯＡＭノードへ送信することができる。図２２は、課金情報２２０２を送信するための例示的な手順２２００を示している。課金情報２２０２は、たとえば、トランザクションＩＤ、要求側オペレータの識別情報（ＰＬＭＮ＿ＩＤ）、ロケーション（ｃｅｌｌ＿ｉｄ＿ｌｉｓｔなど）、情報タイプ（たとえば、課金イベントの開始、サービスの終了など）、課金理由（たとえば、被ホスト側オペレータからのハンドオーバー、リソース修正など）、使用されているリソースのタイプ（たとえば、ＱＣＩ、ＱｏＳ、コールエアタイムなど）、レコードが生成されているＷＴＲＵのアイデンティティー、および／またはキャンセルされるリソースの量を含むことができる。

課金情報２２０２を受信すると、被ホスト側オペレータは、それに応じて肯定応答（ＡＣＫ）２２０４を送信することも、または送信しないことも可能である。次いでＢＣＵは、その情報を格納すること、またはそれを被ホスト側オペレータ内の課金システムへ転送することが可能である。次いでその情報は、ＲＡＮオペレータに対するアカウンティングおよび料金請求のために使用されることが可能である。

課金システムは、ＷＴＲＵが参加オペレータへ移動し、したがって課金イベントが生成されることが可能であるケースを取り扱うこともできる。ハンドオーバーが生じた場合には、ＭＭＥは、セルまたはサービングノードにおける変化について、セッション要求作成メッセージ内のユーザロケーション情報ＩＥおよび／またはサービングノードＩＥおよび／または表示フラグＩＥを介して、セッション要求作成メッセージ内のＳ−ＧＷに知らせることができる。次いでＳ−ＧＷは、このメッセージをＰ−ＧＷへ転送することができる。一例においては、セッション要求作成メッセージは、ＩＥ、たとえば、ＲＡＮ情報ＩＥを含むことができる。このＩＥは、Ｅ−ＵＴＲＡＮ初期接続およびＷＴＲＵによって要求されるＰＤＮ接続手順のためにＳ１１インターフェース上に含まれることが可能である。それは、ＥＣＧＩおよびＴＡＩを含むことができる。ＭＭＥ／ＳＧＳＮは、Ｐ−ＧＷがロケーション情報変化報告を要求しており、ＭＭＥ／ＳＧＳＮがＲＡＮ情報変化報告をサポートしている場合には、ＴＡＵ／ＲＡＵ／Ｘ２ハンドオーバー／拡張ＳＲＮＳリロケーション手順のためにＳ１１／Ｓ４インターフェース上にそれを含むことができる。Ｓ−ＧＷは、ＲＩをＭＭＥ／ＳＧＳＮから受信する場合には、このＩＥをＳ５／Ｓ８インターフェース上に含むことができる。このＩＥは、ＰＤＰコンテキストアクティブ化手順のためにＳ４およびＳ５／Ｓ８インターフェース上に含まれることも可能である。それは、ＣＧＩ、ＳＡＩ、および／またはＲＡＩを含むことができる。このＩＥは、ＷＴＲＵが参加オペレータのセルへ移動した場合には、課金トリガーについて課金システムに知らせることができる。

一例においては、変化報告サポート表示が、ＲＡＮ情報変化報告を含めるようにセッション要求作成メッセージの表示フラグＩＥにおいて更新されることが可能である。このフラグは、ＳＧＳＮ／ＭＭＥがＲＡＮ情報変化報告をサポートしている場合には、Ｅ−ＵＴＲＡＮ初期接続またはＷＴＲＵによって要求されるＰＤＮ接続またはＰＤＰコンテキストアクティブ化手順中にＳ１１／Ｓ４およびＳ５／Ｓ８インターフェース上で１に設定されることが可能である。

ロードバランシングが実行されることが可能である。本明細書において開示されている測定は、ＲＡＮ共有環境におけるロードバランスのためにＰＬＭＮ固有のロード測定をサポートするために使用されることが可能である。

合計の被ホスト側オペレータＰＲＢ使用が測定されることが可能である。これは、たとえば、測定期間Ｔ中に特定の被ホスト側オペレータに関する周波数リソースの使用（ＰＲＢ使用）を測定するために行われることが可能である。この測定は、測定期間Ｔ中に被ホスト側オペレータごとの周波数リソースの使用（ＰＲＢ使用）を測定することによって実行されることも可能である。測定結果は、特定の被ホスト側オペレータに関する、またはそれぞれの被ホスト側オペレータに関するＰＲＢ使用の割合（パーセンテージ）の形式であることが可能である。

トラフィッククラス（ＱＣＩ）ごとの合計の被ホスト側オペレータＰＲＢ使用が測定されることが可能である。これは、たとえば、測定期間Ｔ中に特定の被ホスト側オペレータに関するトラフィッククラス（ＱＣＩ）ごとの周波数リソースの使用（ＰＲＢ使用）を測定するために行われることが可能である。この測定は、測定期間Ｔ中に被ホスト側オペレータごとの周波数リソースの使用（ＰＲＢ使用）をトラフィッククラス（ＱＣＩ）ごとに測定することによって行われることも可能である。測定結果は、特定の被ホスト側オペレータに関する、またはそれぞれの被ホスト側オペレータに関するＰＲＢ使用の割合（パーセンテージ）の形式であることが可能である。

アクティブな被ホスト側オペレータＷＴＲＵのダウンリンク（ＤＬ）またはアップリンク（ＵＬ）の数が測定されることが可能である。これは、たとえば、被ホスト側オペレータに関するアクティブなダウンリンクＷＴＲＵまたはアップリンクＷＴＲＵの数を測定するために行われることが可能である。アクティブなＷＴＲＵは、ＭＡＣ、ＲＬＣ、またはＰＤＣＰプロトコルレイヤ内にダウンリンクまたはアップリンクのためのバッファされたデータが存在することが可能であるＷＴＲＵとして定義されることが可能である。これは、それぞれの被ホスト側オペレータに関するアクティブなダウンリンクＷＴＲＵまたはアップリンクＷＴＲＵの数を測定することによって測定されることも可能である。トラフィッククラスベースごとのアクティブなＷＴＲＵの数に関する測定をサポートするために、この測定は、特定の被ホスト側オペレータに関するトラフィッククラスごとのアクティブなダウンリンクＷＴＲＵまたはアップリンクＷＴＲＵの数を測定することができる。所与のＱＣＩ上のアクティブなダウンリンクＷＴＲＵまたはアップリンクＷＴＲＵは、その所与のＱＣＩに等しいトラフィッククラス（ＱＣＩ）のデータ無線ベアラに関して、ＭＡＣ、ＲＬＣ、および／またはＰＤＣＰプロトコルレイヤ内にダウンリンクまたはアップリンクのためのバッファされたデータが存在することが可能であるＷＴＲＵとして定義されることが可能である。別の例においては、測定は、それぞれの被ホスト側オペレータに関してトラフィッククラスごとのアクティブなダウンリンクＷＴＲＵまたはアップリンクＷＴＲＵの数を測定することができる測定として定義されることが可能である。

ＰＬＭＮごとのサポートリソースステータスが測定されることが可能である。ＰＬＭＮ固有のロードバランシングをサポートするために、ＰＬＭＮロード報告が関与することが可能である。ＰＬＭＮベースごとにセルロードが報告されることが可能である。それぞれのＰＬＭＮに関してＳ１ロードが報告されることが可能である。Ｓ１ロードは、バックホールリンクの混雑レベルを推定するために使用されることが可能である。Ｓ１リンクがオーバーロードされている可能性がある場合には、ＲＡＮは、さらなるコールを認めないことが可能である。ＲＡＮを共有しているそれぞれの被ホスト側オペレータ（ＰＬＭＮ）に関してＰＲＢ使用情報が報告されることが可能である。これは、たとえば、リソースステータス更新メッセージにおいてそれぞれのＰＬＭＮに関して現在の無線リソースステータスＩＥを繰り返すことによって行われることが可能である。ＰＬＭＮベースごとに複合利用可能キャパシティーグループが報告されることも可能である。

リソースステータス更新メッセージの一例が、下に示されていると言える。

ピアｅＮＢが別々の被ホスト側オペレータによって共有されることが可能であるケースにおいては、測定結果が属しているオペレータを示すために、ＰＬＭＮ ＩＤが、無線リソースステータスＩＥ、Ｓ１ ＴＮＬロードインジケータ、および複合利用可能キャパシティーグループ内に含まれることが可能である。

別の例として、ＰＬＭＮ ＩＤは、直接セル測定結果アイテム内に（たとえば、セルＩＤの後に）含まれることが可能である。次いで階層は、リソースステータスレポートを提供するために、それぞれのセルＩＤに関して、およびそれぞれのＰＬＭＮ ＩＤに関して、そのセルによってサービス提供されることが可能である。リソースステータス要求メッセージおよびリソースステータス更新メッセージの一例が、下に示されていると言える。

それぞれのリソースタイプに関して、リソース使用情報は、被ホスト側オペレータに割り当てられている総ネットワークリソースに対する相対的な量として解釈されることが可能である。

ＰＬＭＮベースごとにハンドオーバー（ＨＯ）しきい値を調整するためのサポートが提供されることが可能である。ＰＬＭＮごとのオフローディングルールをサポートする目的で、異なるＰＬＭＮに属している可能性があるＷＴＲＵに関してハンドオーバーをトリガーする条件を修正するための１または複数の方法が使用されることが可能である。たとえば、モビリティー変更要求メッセージ内のハンドオーバートリガー変更ＩＥが、それぞれのＰＬＭＮのために複製されることが可能である。別々の被ホスト側オペレータによってピアｅＮＢが共有されることが可能になる条件をサポートするために、オペレータ情報（ＰＬＭＮ）がハンドオーバートリガー変更ＩＥ内に含まれることが可能である。

次の表は、モビリティー変更要求メッセージの一例を示している。

別の例は、被ホスト側オペレータおよびハンドオーバートリガー変更の両方をモビリティーパラメータ情報ＩＥ内に含めることが可能であると言える。

ｅＮＢ２は、ｅＮＢ１によって提案された提案モビリティーパラメータを拒否することができるケースにおいては、モビリティー変更失敗メッセージを返信することができる。この失敗メッセージにおいては、それぞれの被ホスト側オペレータに関するｅＮＢ２モビリティーパラメータの範囲をｅＮＢ１に示すことができる。下に示されているように、このメッセージにおいては、ｅＮＢは、ＲＡＮリソースを共有することができる被ホスト側オペレータのリストを提供することもできる。

アイドルモードＷＴＲＵを分散させることに対するｅＮＢが、ＰＬＭＮベースごとにサポートされることが可能である。ｅＮＢがアイドルモードＷＴＲＵモビリティーをＰＬＭＮベースごとに構成するのをサポートするために、セルは、ホスト固有のセル再選択パラメータ、たとえば、それぞれのサポートされるＰＬＭＮに関するｑ−Ｈｙｓｔ、またはそれぞれのサポートされるＰＬＭＮに関するｑ−ＯｆｆｓｅｔＣｅｌｌをブロードキャストすることができる。一例が下に示されている。

リソースモニタリングが提供されることが可能である。本明細書において開示されているメトリックの点からのネットワークリソースの使用がＰＬＭＮベースごとにモニタされることが可能である。モニタリングフォーマットは、本明細書において開示されているように定義されることが可能である。

リソース使用モニタリングは、ｅＮＢ、ＨｅＮＢ、ＢＣＵによって（たとえば、そのコントロールのもとでさまざまなノードからリソース使用を収集した後に）、ならびに／またはｅＮＢ／ＨｅＮＢおよびＢＣＵによって互いに連携して、もしくはＭＭＥ、Ｓ−ＧＷ／Ｐ−ＧＷなどのコアネットワークノードと連携して行われることが可能である。

モニタリングは、オンデマンドでの被ホスト側オペレータからの要求、リソース使用報告ピリオドに関連付けられているタイマーが切れたこと、ホスト側オペレータ構成など、またはそれらの任意の組合せによってトリガーされることが可能である。

ホスト側オペレータと被ホスト側オペレータとの間においてレポートがやり取りされることが可能である。たとえば、レポートは、本明細書において開示されているスキームを使用してホスト側オペレータと被ホスト側オペレータとの間においてやり取りされることが可能である。被ホスト側オペレータは、リソースステータス要求メッセージをホスト側オペレータへ送信することができる。このメッセージを受信すると、ホスト側オペレータは、どのレポートが成功裏に開始されたかを応答するためのリソースステータス応答メッセージを送信することができる。ホスト側オペレータは、被ホスト側オペレータによって要求された際に使用ステータスを報告するためのリソースステータス更新メッセージを用いて進むことができる。

ネットワーク共有のためのリソースモニタリングが提供されることが可能である。ホスト側オペレータは、Ｓ−ＧＷ、Ｐ−ＧＷ等など、ネットワークの一部を共有することができる。これは、たとえば、同じリソースを共有していることが可能であるそれぞれのオペレータに関するネットワーク使用をモニタするために行われることが可能である。測定は、複数のメトリックのうちの任意のものまたはすべてを単独で、または任意の組合せで含むことができる。１つのメトリックは、オペレータごとにＳ−ＧＷからＰ−ＧＷへ送信されることが可能であるＧＴＰ−Ｕ ＰＤＵボリュームであることが可能である。別のメトリックは、オペレータごとにＰ−ＧＷからＳ−ＧＷへ送信されることが可能であるＧＴＰ−Ｕ ＰＤＵボリュームであることが可能である。別のメトリックは、オペレータごとにＳ−ＧＷからＰ−ＧＷへ送信されることが可能であるＧＴＰ−Ｕパケットの数であることが可能である。別のメトリックは、オペレータごとにＰ−ＧＷからＳ−ＧＷへ送信されることが可能であるＧＴＰ−Ｕパケットの数であることが可能である。別のメトリックは、オペレータごとにＳ−ＧＷからＰ−ＧＷへ送信されることが可能であるＧＴＰ−Ｃパケットの数であることが可能である。別のメトリックは、オペレータごとにＰ−ＧＷからＳ−ＧＷへ送信されることが可能であるＧＴＰ−Ｃパケットの数であることが可能である。別のメトリックは、オペレータごとにＳ−ＧＷからＰ−ＧＷへ送信されることが可能であるＧＴＰ−Ｃパケットの数であることが可能である。別のメトリックは、オペレータごとにＳ−ＧＷからＳＧＳＮへ送信されることが可能であるＧＴＰ−Ｕ ＰＤＵボリュームであることが可能である。別のメトリックは、オペレータごとにＳＧＳＮからＳ−ＧＷへ送信されることが可能であるＧＴＰ−Ｕ ＰＤＵボリュームであることが可能である。別のメトリックは、オペレータごとにＳ−ＧＷからｅＮＢ（Ｓ１Ｕ）へ送信されることが可能であるＧＴＰ−Ｕ ＰＤＵボリュームであることが可能である。別のメトリックは、オペレータごとにＳ−ＧＷからｅＮＢ（Ｓ１Ｕ）へ受信されることが可能であるＧＴＰ−Ｕ ＰＤＵボリュームであることが可能である。別のメトリックは、オペレータごとにＳ−ＧＷからｅＮＢへ送信されることが可能であるＧＴＰ−Ｕパケットの数であることが可能である。別のメトリックは、オペレータごとにｅＮＢからＳ−ＧＷ（Ｓ１Ｕ）へ送信されることが可能であるＧＴＰ−Ｕパケットの数であることが可能である。

リソース管理がＲＡＮノードにおいて提供されることが可能である。被ホスト側オペレータまたはホストＲＡＮは、リソースが複数のオペレータによって共有されることが可能である場合にリソース割り当てが違反されることが絶対にあり得ないようにすることができる。ＲＡＮまたはＣＮは、リソースの公平な配分を確実にするために複数のアクションを取ることができる。たとえば、ＲＡＮノードまたはその他の任意のノードは、ＢＣＵにクエリーを行うことができる。これは、スケジュールされたベースに従って、または要求に応じて実行されることが可能である。これは、たとえば、リソース割り当てが変わる場合があるのに伴って共有ネットワークが割り当てを認識することを確実にするために行われることが可能である。割り当て変更が生じた際にＢＣＵまたはその他の任意の制御エンティティーがこの情報を共有ノードに渡すことができるということが可能である場合もある。

ＢＣＵまたはその他のＯＡＭノードは、リソースの公平な配分を確実にするためのポリシーを共有ノードに強制することができる。それらのポリシーは、たとえば被ホスト側オペレータが、割り当てられたリソースのうちの自分の持ち分を超過した場合に、適用されることが可能である。それらのポリシーは、リソース割り当てを確実にする上で役立つことができる。たとえば、共有ノードまたはＭＭＥは、それ以上のＰＤＮ接続、専用ベアラ要求、ベアラ修正手順などを受け入れないことが可能である。別の例として、共有ノードは、いくつかのＷＴＲＵを近隣セルへオフロードするために、本明細書において開示されているようなハンドオーバー手順をトリガーすることができる。

別の例として、ＢＣＵまたはその他のＯＡＭノードは、共有ノードが、割り当てられたリソース割り当てを超過することをＢＣＵまたはその他の任意の制御エンティティーに要求することを可能にすることができるポリシーを強制することができる。この情報は、共有ノードにおいて利用できることが可能である。たとえば、ＢＣＵは、共有ノードがＢＣＵに接続しているときに、またはリソース割り当てがＢＣＵによって許可されることが可能であるときに、この情報をその共有ノードへ送信しておくことができる。ＢＣＵは、トレランスレベルについて共有ノードに知らせることができる。次いで共有ノードは、割り当てられた持ち分が完全に利用されていて、かつネットワークを共有しているその他のオペレータからの利用可能なリソースが存在する可能性があるケースにおいては、許容されたトレランスを超過することができる。

別の例として、ＢＣＵまたはその他のＯＡＭノードは、ＢＣＵが、はじめに割り当てられたよりも多くのリソースなど、特別なリソースを使用することに関して被ホスト側オペレータとの間で別の課金レートを交渉することを可能にすることができるポリシーを強制することができる。被ホスト側オペレータが、特別なリソースを使用することに関する課金ポリシーに合意した場合には、ＲＡＮオペレータは、被ホスト側オペレータが自分の割り当てられた限度を超過することを可能にすることができる。

別の例として、ＢＣＵまたは類似のエンティティーは、割り当てられたリソースが限度に達した場合にその限度を超過することなく現在のリソースをどのように取り扱うかに関するポリシーを強制することもできる。これらのポリシーは、たとえば、現在のベアラのＱｏＳを低減させること、その他のＲＡＴ（たとえば、Ｗｉ−Ｆｉ、３ＧＰＰなど）へオフロードすること、不連続受信（ＤＲＸ）パラメータを構成すること、アイドルモードスリープタイマーを構成すること、セルベアリングおよび／またはバックオフタイマーを構成することなどを含むことができる。

ｅＮＢまたはその他の任意の共有ＲＡＮは、時間のピリオドにわたって割り当て行動を観察することができる。これらのノードは、キャパシティーぎりぎり（close to capacity）で頻繁に機能している場合がある、および自分の割り当てられたキャパシティーをしばしば超過する場合があるオペレータに気づくことができる。次いでそのような行動は、対応するＢＣＵに報告されることが可能である。次いでＢＣＵは、割り当てを変更することができ、また被ホスト側オペレータに知らせることができ、または割り当てが変更されることを望むかどうかを被ホスト側オペレータにたずねることができる。ＢＣＵまたはＲＡＮオペレータは、その情報を被ホスト側オペレータに渡すことができ、次いで被ホスト側オペレータは、自分自身のポリシーおよびＯＡＭ手順に基づいて決定を行うことができる。被ホスト側オペレータは、その情報に基づいてさらなるリソースを要求することを決定した場合には、本明細書において開示されているリソース要求手順を使用して、それを行うことができる。ＲＡＮオペレータは、被ホスト側オペレータリソースのうちの１つが時間のほとんどにわたって十分に利用されていない場合があるということを見て取ったならば、これらのリソースをキャンセルすることを決定することができ、それらを、さらなるリソースを必要としている可能性があるオペレータに割り当てることができる。

ＲＡＮリソースのうちの一部は、いかなるオペレータにも割り当てられないことが可能であり、予備リソースとしてＲＡＮノードによって保持されることが可能である。これらのリソースは、オンデマンドで被ホスト側オペレータに割り当てられることが可能であり、または被ホスト側オペレータのうちの１つが、割り当てられたリソースを超過した場合に割り当てられることが可能である。ＲＡＮオペレータは、これらの予備リソースの料金を別々に課金することができる。これらの予備リソースは、いつでもＲＡＮオペレータによって取り戻されることが可能である。

図５において示されている仮想ネットワークアーキテクチャー内のそれぞれのＲＡＮオペレータは、自分のＲＡＮリソースのうちのいくつかまたはすべてを仮想ネットワークに割り当てることができる。リソースが仮想ネットワークに部分的に割り当てられる場合には、リソースは、その仮想ネットワークに属していないＷＴＲＵに関してはＲＡＮオペレータによって使用されないことが可能である。いくつかのケースにおいては、リソースが時間のいくらかの指定されたピリオドにわたってアイドルであって、ＲＡＮオペレータが自分のＷＴＲＵのためのリソースを必要としている場合には、仮想ネットワークリソースは、ＲＡＮオペレータに戻されることが可能である。ＲＡＮオペレータは、仮想ネットワークとの間でさまざまなタイプのリソース割り当てを有することができる。これらのタイプのリソース割り当ては、さまざまな価格設定モデルを伴うことができる。

一例として、ＲＡＮオペレータによって仮想ネットワークに割り当てられるリソースのパーセンテージまたは割合は、動的であることが可能である。仮想オペレータは、リソースを必要に応じてＲＡＮオペレータに要求することができる。ＲＡＮオペレータは、利用可能なリソースを有している場合には、リソースを動的に仮想ネットワークに割り当てることができる。

別の例として、ＲＡＮオペレータによって割り当てられるリソースは、動的に割り当てられないことが可能である。リソースが仮想オペレータに割り振られている場合に、仮想オペレータは、たとえそれらのリソースが仮想ネットワークにおいてアイドルであっても、それらのリソースを保持する場合がある。ＲＡＮオペレータは、リソースを必要とする場合には、別のＲＡＮオペレータへのハンドオーバーを行うこと、およびロードバランシング技術を実施することを試みることが可能である。

別の例として、ＲＡＮオペレータによって割り当てられるリソースは、仮想ネットワークの観点からのみ動的であることが可能である。たとえば、仮想ネットワークは、さらなるリソースを必要とする場合には、それらをＲＡＮオペレータに動的に要求することができ、これらのリソースは、動的に仮想ネットワークに割り当てられることが可能である。しかしながら、ＲＡＮオペレータは、たとえば、自分のＷＴＲＵのためにリソースを必要としている場合には、それらのリソースを要求することができない場合がある。仮想ネットワークがリソースをもはや必要としない場合には、それらのリソースは、ＲＡＮオペレータに戻されることが可能である。

これらのシナリオは、本明細書において開示されているＲＡＮ共有アーキテクチャーを使用して仮想ネットワークにおいて実施されることが可能である。これらのアーキテクチャーにおいては、ＢＣＵの機能のうちのいくつかまたはすべては、図５の仮想ネットワークの仮想化レイヤネットワークマネージャー機能（ＶＮＭＦ）内に存在することが可能である。このノードは、このタイプの仮想ネットワークに関する動的なＲＡＮ共有を可能にするための複数の機能を提供することができる。

たとえば、ＶＮＭＦは、その他のオペレータ、たとえば、ＲＡＮオペレータおよび／または被ホスト側オペレータから仮想ネットワークの代わりにクエリーおよび／または割り当て要求を受信することができる。別の例として、ＶＮＭＦは、仮想ネットワークＲＡＮがさらなるリソースを必要としている場合には、クエリーおよび／または割り当て結果をＲＡＮオペレータへ送信することができる。ＶＮＭＦは、ロードバランシングが必要とされている可能性があるということを仮想ネットワーク内のＲＡＮノードに示すことができる。別の例として、ＶＮＭＦは、オペレータどうしの間においてさまざまなリソースパラメータ、たとえば、リソースが必要とされる期間、リソースの量、およびＱｏＳなどのその他のサービス属性を仮想オペレータの代わりに交渉することができる。別の例として、ＶＮＭＦは、仮想ネットワーク内の複数のオペレータが、限られたリソースを要求しているケースにおいては、限られたリソースの分け前のうちのどれぐらい多くをどのオペレータが受け取るかを決定することによってなど、アービトレータとして機能することができる。別の例として、ＶＮＭＦは、利用可能なリソースに関する情報を、仮想ネットワーク内の共有ＲＡＮから、および仮想ネットワーク外のその他のＲＡＮオペレータから収集することができる。リソース割り当てまたは充当における修正のケースにおいては、ＶＮＭＦは、そのような修正について共有ＲＡＮノードに示すことができ、それらは、それに従って自分たちの割り当てを変更することができる。

さらに、仮想ネットワークＲＡＮノードに関する課金は、ＶＰＣＲＦノードによってまとめて取り扱われることが可能である。課金イベントがトリガーされた場合には、課金またはアカウンティングレコードを作成するための表示がＶＰＣＲＦへ送信されることが可能である。ＶＰＣＲＦは、料金請求の目的でこの課金またはアカウンティングレコードをそれぞれの１または複数のオペレータへ送信することができる。ＶＰＣＲＦは、複数の機能を実施することができる。たとえば、ＶＰＣＲＦは、課金のために仮想ネットワーク内の参加ＲＡＮノードからの使用統計を報告することができる。ＶＰＣＲＦは、使用されているＲＡＮリソースに関する課金メッセージを被ホスト側オペレータへ送信することができる。ＶＰＣＲＦは、共有ＲＡＮノードにおいて、本明細書において開示されているように課金イベントに関するトリガーを実施することができる。ＶＰＣＲＦは、リソースの使用に関する統計および情報を収集するためにＶＮＭＦと連携することができ、特定のサービスまたはアプリケーションが特定のＲＡＮノードによってしか提供され得ないことを確実にするために、この情報を仮想化レイヤサービスおよびアプリケーションコントロール機能（ＶＳＡＣＦ）に提供することができる。

承認されたオペレータに、または承認されたオペレータからリソースが割り当てられていることを確実にするために、セキュリティーおよびインテグリティーパラメータが提供されることが可能である。この機能は、仮想ネットワーク内の仮想化レイヤサービスおよびアプリケーションコントロール機能（ＶＳＡＣＦ）ノードによって提供されることが可能である。

ＥＣＧＩ／グローバルｅＮＢ ＩＤの混乱は、ＰＬＭＮベースで対処されることが可能である。本明細書に記載されているＥＣＧＩ／グローバルｅＮＢ ＩＤの混乱の説明に関連して、それぞれのセルは、別々のＰＬＭＮ ＩＤ、またはＰＬＭＮ ＩＤの別々のリストをブロードキャストしている場合がある。ＰＬＭＮ ＩＤのうちの１つが、グローバルｅＮＢ ＩＤ内に含まれる場合があり、グローバルｅＮＢ ＩＤは、ＰＬＭＮ ＩＤおよびｅＮＢ ＩＤから構成される場合がある。それらはともに、一意のグローバルｅＮＢ ＩＤとみなされる場合がある。この問題を解決するために、いくつかの例示的な実施態様が採用されることが可能である。

ｅＮＢは、複数の一意のｅＮＢ ＩＤを有することができる。これは、それぞれのセルが、自分がブロードキャストしていることが可能であるＰＬＭＮのうちの１つとともにセルＩＤ（ｅＮＢ ＩＤを含むことができる）をブロードキャストすることができるということを意味することが可能である。たとえば、ｅＮＢが、それぞれが別々のＰＬＭＮ ＩＤをブロードキャストする３つのセルを有している場合には、セルによってブロードキャストされることが可能であるＥＣＧＩ内に含まれている別々のＰＬＭＮ ＩＤが存在することが可能である。グローバルｅＮＢ ＩＤは、ＥＣＧＩ内のＰＬＭＮ ＩＤ、およびＥＣＧＩ内のｅＮＢ ＩＤから得られることが可能である。したがって、それぞれのセルは、別々の一意のグローバルｅＮＢ ＩＤを有することができる。

このグローバルｅＮＢ ＩＤは、ｅＮＢとＭＭＥとの間におけるＳ１接続をセットアップする際に含まれることが可能である。グローバルｅＮＢ ＩＤは、Ｓ１−ＡＰ接続セットアップ要求メッセージ内にＩＥとして含まれることが可能である。このケースにおいては、ｅＮＢは、Ｓ１−ＡＰセットアップ要求メッセージ内にグローバルｅＮＢ ＩＤを含めることができ、またはｅＮＢは、複数のＳ１−ＡＰセットアップ要求メッセージをＭＭＥへ送信することができ、それぞれのメッセージは、別々の一意のグローバルｅＮＢ ＩＤを有している。これは、たとえば、ハンドオーバーのケースにおいては、ＭＭＥがハンドオーバーメッセージを正しいｅＮＢへ送信するのを支援するために行われることが可能である。ネットワークを共有しているＲＡＮオペレータは、ＭＭＥにおけるルーティング混乱を防止するために、別々のＰＬＭＮ内のｅＮＢどうしに割り振られるｅＮＢ ＩＤが一意であることが可能であるように調整を行うことができる。

ｅＮＢは、そのｅＮＢによってブロードキャストされているＰＬＭＮ ＩＤにマップすることができる共通のまたはフェイクのＰＬＭＮ ＩＤを割り振ることができる。そのマッピングは、ＭＭＥまたはその他のｅＮＢに示されることが可能であり、それによって、ハンドオーバーおよびその他の手順中にメッセージが正しいｅＮＢへ回送されることが可能になる。また、Ｓ１セットアップ手順中に、このフェイクのＩＤは、Ｓ１−ＡＰセットアップ要求メッセージ内に含めて送信されることが可能である。マッピングがブロードキャストされるＰＬＭＮ ＩＤは、同じＳ１−ＡＰセットアップ要求またはその他のＳ１−ＡＰメッセージ内に含めて送信されることが可能である。

ハンドオーバー中に、ソースｅＮＢは、測定要求においてターゲットｅＮＢに関するＥＣＧＩセルＩＤを受信することができる。ＥＣＧＩは、フェイクのＰＬＭＮ ＩＤを含むことができる。ソースｅＮＢは、フェイクのＰＬＭＮ ＩＤを本物のＰＬＭＮ ＩＤに変換するためにマッピングテーブルを使用することができ、メッセージをＭＭＥへ送信することができる。別の例として、ソースｅＮＢは、ハンドオーバーメッセージをＭＭＥへ送信することができ、ＭＭＥは、変換を行うことができ、メッセージを正しいターゲットｅＮＢへ回送することができる。このソリューションは、ローカルｅＮＢ ＩＤにおいてコンフリクトがないこと、たとえば、ローカルｅＮＢ ＩＤが共有ＰＬＭＮに対して一意であることが可能であることを確実にするために、ＲＡＮを共有しているオペレータどうしの間における何らかの形式の調整を伴うことができる。

ｅＮＢは、グローバルｅＮＢ ＩＤ内で使用されることになるブロードキャストされるＰＬＭＮ ＩＤのうちの１つをランダムに、またはいくつかの事前に定義されたルールを用いて選ぶことができる。ローカルｅＮＢ ＩＤは、ＲＡＮを共有しているＰＬＭＮどうしの間においてコンフリクトをもたらさないことが可能である。

上記では特徴および要素が特定の組合せで説明されているが、それぞれの特徴または要素は、単独で、またはその他の特徴および要素との任意の組合せで使用されることが可能であるということを当技術分野における標準的な技術者なら理解するであろう。加えて、本明細書において説明されている方法は、コンピュータまたはプロセッサによって実行するためにコンピュータ可読メディア内に組み込まれているコンピュータプログラム、ソフトウェア、またはファームウェアで実装されることが可能である。コンピュータ可読メディアの例は、（有線接続またはワイヤレス接続を介して伝送される）電子信号、およびコンピュータ可読ストレージメディアを含む。コンピュータ可読ストレージメディアの例は、読み取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、レジスタ、キャッシュメモリ、半導体メモリデバイス、内蔵ハードディスクおよび取り外し可能ディスクなどの磁気メディア、光磁気メディア、ならびに、ＣＤ−ＲＯＭディスクおよびデジタル多用途ディスク（ＤＶＤ）などの光メディアを含むが、それらには限定されない。ＷＴＲＵ、ＵＥ、端末、基地局、ＲＮＣ、または任意のホストコンピュータにおいて使用するための無線周波数トランシーバを実装するために、ソフトウェアと関連付けられているプロセッサが使用されることが可能である。

Claims (20)

1. 複数のオペレータを伴う無線アクセスネットワーク（ＲＡＮ）キャパシティーを管理するための方法であって、
   共有ＲＡＮリソースを要求する前記複数のオペレータのうちの参加オペレータからのキャパシティークエリー要求を、第１のブローカレッジコントロールユニットを介して受信することと、
   利用可能な共有ＲＡＮリソースを判定することと、
   前記利用可能な共有ＲＡＮリソースからの前記要求されている共有ＲＡＮリソースを許可するキャパシティークエリー結果を前記参加オペレータへ送信することと、
   前記参加オペレータによる共有ＲＡＮリソースの使用のアカウンティングを行うことと
   を含むことを特徴とする方法。
2. 共有ＲＡＮからの前記利用可能な共有ＲＡＮリソースに関連する情報を受信することをさらに含むことを特徴とする請求項１に記載の方法。
3. 前記参加オペレータによる共有ＲＡＮリソースの使用の前記アカウンティングに関連する情報を課金システムに提供することをさらに含むことを特徴とする請求項１に記載の方法。
4. 前記課金システムに共有ＲＡＮリソースの使用について前記参加オペレータに課金させることをさらに含むことを特徴とする請求項３に記載の方法。
5. 前記キャパシティークエリー要求は、Ｘ２インターフェースを介して第２のブローカレッジコントロールユニットから受信されることを特徴とする請求項１に記載の方法。
6. ハンドオーバーイベントに関連付けられている課金イベントをトリガーすべきかどうかを判定することをさらに含むことを特徴とする請求項１に記載の方法。
7. 前記ハンドオーバーイベントのタイプに応じて前記課金イベントをトリガーすべきかどうかを判定することをさらに含むことを特徴とする請求項６に記載の方法。
8. 前記キャパシティークエリー結果は、利用可能な共有ＲＡＮリソースに関連付けられているロケーションを含むことを特徴とする請求項１に記載の方法。
9. 前記キャパシティークエリー結果は、利用可能な共有ＲＡＮリソースのサービス品質（ＱｏＳ）属性を含むことを特徴とする請求項１に記載の方法。
10. 前記キャパシティークエリー結果は、利用可能な共有ＲＡＮリソースの期間を含むことを特徴とする請求項１に記載の方法。
11. 前記共有ＲＡＮリソースは、仮想化されたＲＡＮオペレータに関連付けられていることを特徴とする請求項１に記載の方法。
12. 複数のオペレータを伴う無線アクセスネットワーク（ＲＡＮ）キャパシティーを管理するためのシステムであって、
    共有ＲＡＮリソースを要求する前記複数のオペレータのうちの参加オペレータからのキャパシティークエリー要求を受信するように構成されている第１のブローカレッジコントロールユニットと、
    前記第１のブローカレッジコントロールユニットと通信状態にあり、前記キャパシティークエリー要求を前記第１のブローカレッジコントロールユニットへ送信するように構成されている第２のブローカレッジコントロールユニットと、
    前記第１のブローカレッジコントロールユニットと通信状態にある第１の課金システムと、
    前記第２のブローカレッジコントロールユニットと通信状態にある第２の課金システムとを含み、
    前記第１のブローカレッジコントロールユニットは、利用可能な共有ＲＡＮリソースを判定し、前記利用可能な共有ＲＡＮリソースからの前記要求されている共有ＲＡＮリソースを許可するキャパシティークエリー結果を前記参加オペレータへ送信し、および前記参加オペレータによる共有ＲＡＮリソースの使用のアカウンティングを行うように構成されており、
    前記第１の課金システムは、前記参加オペレータによる前記共有ＲＡＮリソースの前記使用の前記アカウンティングに応じて課金情報を生成し、および前記課金情報を前記第２の課金システムへ送信するように構成されていることを特徴とするシステム。
13. 前記第１のブローカレッジコントロールユニットおよび前記第２のブローカレッジコントロールユニットは、Ｘ２インターフェースを介して通信状態にあることを特徴とする請求項１２に記載のシステム。
14. 前記第１のブローカレッジコントロールユニットは、ハンドオーバーイベントに関連付けられている課金イベントをトリガーすべきかどうかを判定するように構成されていることを特徴とする請求項１２に記載のシステム。
15. 前記第１のブローカレッジコントロールユニットは、前記ハンドオーバーイベントのタイプに応じて前記課金イベントをトリガーすべきかどうかを判定するように構成されていることを特徴とする請求項１４に記載のシステム。
16. 前記キャパシティークエリー結果は、利用可能な共有ＲＡＮリソースに関連付けられているロケーションを含むことを特徴とする請求項１２に記載のシステム。
17. 前記キャパシティークエリー結果は、利用可能な共有ＲＡＮリソースのサービス品質（ＱｏＳ）属性を含むことを特徴とする請求項１２に記載のシステム。
18. 前記キャパシティークエリー結果は、利用可能な共有ＲＡＮリソースの期間を含むことを特徴とする請求項１２に記載のシステム。
19. 無線アクセスネットワーク（ＲＡＮ）内のリソース充当をコントロールするための方法であって、
    ネットワークノードから参加オペレータに関する割り当て行動レポートを、ブローカレッジコントロールユニット（ＢＣＵ）を介して受信することと、
    前記参加オペレータに割り当てられたリソースの使用がリソース割り当てポリシーに準拠しているかどうかを、前記割り当て行動レポートから判定することと、
    前記参加オペレータに割り当てられた前記リソースの前記使用が前記リソース割り当てポリシーに準拠していない場合に、前記参加オペレータに割り当てられた前記リソースの前記使用を調整するためのメッセージを前記参加オペレータへ送信することと
    を含むことを特徴とする方法。
20. 前記割り当て行動レポートは、前記参加オペレータが期間にわたってキャパシティーの付近で機能しているということを示すことを特徴とする請求項１９に記載の方法。