JP2020506625A - 持続可能なサービスの選択 - Google Patents

Abstract

【課題】持続可能なサービスの選択。【解決手段】ネットワークからサービスのリソースを要求することを含む方法が提供され、この要求は、リソースがサービスに対して満たされるべき要件を示す要件指標を含む。【選択図】図１

Description

本発明は、サービス選択に関する装置、方法およびコンピュータプログラム製品に関する。より詳細には、本発明は、要件に基づくサービス選択の装置、方法、およびコンピュータプログラム製品に関する。

略語
３ＧＰＰ：第三世代パートナーシッププロジェクト
４Ｇ：第４世代
５Ｇ：第５世代
ＡＦ：アプリケーション機能
ＡＮ：アクセスノード
ＡＰＮ：アクセスポイント名
ＢＧＷ：ボーダーゲートウェイ
ＢＳ：基地局
ＣＤＭＡ：符号分割多重アクセス（Ｃｏｄｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）
ＣＰ：コントロールプレーン
ＣｒｉＣ：クリティカル通信
ＣＳＣＦ：コールセッション制御機能（ＩＭＳ）
ＣＵＰＳ：コントロールおよびユーザープレーンの分離
ＤＧＱ：ダイナミックジェネリックＱｏＳ／ＳＬＡ
ＤＬ：ダウンリンク
ＤＮ：データネットワーク
ｅ２ｅ：エンドツーエンド
ＥＤＧＥ：ＧＳＭ進化型拡張データレート
ｅＭＢＢ：拡張モバイルブロードバンド
ｅＮＢ：進化型ＮｏｄｅＢ
ＥＳ：ＥＴＳＩ仕様
ＥＴＳＩ：欧州電気通信標準協会
ＦＭＣ：固定モバイルコンバージェンス
ＦＴＥＩＤ：完全条件ＴＥＩＤ
ＧＢＲ：保証ビットレート
ＧＧＳＮ：ゲートウェイＧＰＲＳサポートノード
ＧＰＲＳ：一般的パケット無線システム
ＧＴＰ：ＧＰＲＳトンネルプロトコル
ＨＰＬＭＮ：ホームＰＬＭＮ
ＩＢＣＦ：相互接続境界制御機能
ＩＤ：識別子
ＩＭＳ：ＩＰマルチメディアサブシステム
ＫＰＩ：重要業績評価インジケータ
ＬＴＥ：長期的進化
ＬＴＥ−Ａ：ＬＴＥ−アドバンスト
ＭＭＥ：モビリティ管理エンティティ
ｍＭＴＣ：大規模ＭＴＣ
ＭＴＣ：マシン型通信
ＮＦＶ：ネットワーク機能仮想化
ＰＧＷ：パケットゲートウェイ
ＰＬＭＮ：公衆携帯電話ネットワーク（Ｐｕｂｌｉｃ Ｌａｎｄ Ｍｏｂｉｌｅ Ｎｅｔｗｏｒｋ）
ＰｒｏｃＤ：処理遅延
ＰｒｏｐＤ：伝播遅延
ＱｏＳ：サービス品質
ＲＡＮ：無線アクセスネットワーク
ＲＴＴ：往復時間
ＳＧＳＮ：サービングＧＰＲＳサポートノード
ＳＧＷ：サービングゲートウェイ
ＳＬＡ：サービスレベル契約
ＴＥＩＤ：トンネルエンドポイント識別子
ＴｒａｎＤ：伝送遅延
ＴｒＧＷ：移行ゲートウェイ
ＴＲ：テクニカルレポート
ＴＴＩ：送信時間間隔
ＵＥ：ユーザー機器
ＵＰ：ユーザープレーン
ＵＴＲＡＮ：ＵＭＴＳ地上無線アクセスネットワーク
ＶＰＬＭＮ：訪問ＰＬＭＮ
ＷｉＦｉ：ワイファイ

従来技術によれば、スライス選択（すなわち、どのスライスがどのサービスまたはサービスの一部を実行するか）は、アプリケーションＩＤおよびサービス記述子に基づいて実行される。

以下は、３ＧＰＰ ＴＲ ２３．７９９の抜粋である。

抽出開始――――――――――

ネットワーク選択を実行するためには、特定のユースケース用に設計された機能のクラス内であっても、選択原理が、特定のサービスを提供する適切な機能を選択できるようにする必要がある。

要約すると、選択基準は、特定のアプリケーションに対して、適切なネットワークスライスの選択を可能にし、また、いつでもＵＥが要求する特定のサービスに対するネットワークスライス内の適切な機能コンポーネントを選択できるようにする必要がある。次の図は、ＵＥで実行されているアプリケーションが多次元記述子を提供できることを示す。多次元記述子には、少なくとも、
− アプリケーションＩＤ、
− サービス記述子（ｅＭＢＢサービス、ＣｒｉＣ、ｍｍＴＣなど）、
が含まれる。ネットワークは、ネットワークで利用可能な他の情報（サブスクリプションなど）とともに多次元記述子を使用して、適切なネットワークスライスとネットワーク機能を選択できる。これは、多次元選択メカニズムと呼ばれる。

以下は、ネットワークスライスおよび機能選択の可能なオプションである。
１． ２段階選択メカニズム：ネットワークで利用可能な情報（サブスクリプションなど）とともに、ＲＡＮの選択機能はアプリケーションＩＤ（多次元記述子の一部）を使用して、適切なコアネットワークスライスを選択し、コアネットワーク内の選択機能は、サービス記述子（部分多次元記述子の）を使用し、ネットワークスライス内の適切なネットワーク機能を選択する。
２． ワンステップ選択メカニズム：ネットワークで利用可能な情報（サブスクリプションなど）とともに、ＲＡＮ内の選択機能またはコアネットワーク内の選択機能は、アプリケーションＩＤとサービス記述子（多次元記述子）を使用して、適切なネットワークスライス、ネットワーク機能を選択し、それに応じてＵＥに（再）指示する。
――――――――――抽出終了

この抽出によると、３ＧＰＰは、アプリケーションＩＤ、および、ｍｍＴＣやＣｒＩＣなどのサービス記述子と呼ばれる２つのパラメーターに基づいてスライスを選択することを意図している。

これは、ＵＥは、これらのアプリケーションＩＤとサービス記述子を明示的にセットアップすることが期待され、ネットワークはそれらを評価することが期待されていることを意味する。

これは、ネットワーク（ＲＡＮまたはコア）が、アプリケーションＩＤとサービス記述子との各組み合わせに対応するスライスを計算／選択／決定できるように、すべての新しいアプリケーションＩＤと新しいサービス記述子を評価および認識する必要があるという問題につながる。したがって、新しいアプリケーションＩＤやサービス記述子はそれぞれ認識される必要があるため、新しいアプリケーションＩＤやサービス記述子はすべてネットワーク（ＲＡＮやＣＯＲＥ）に影響を与える。ローミングの場合、ＨＰＬＭＮだけでなくＶＰＬＭＮも、アプリケーションＩＤとサービス記述子の各組み合わせを理解して、要求されたサービスをサポートする適切なタイプのスライスを選択する必要がある。この問題を解決するために、標準化された専用のアプリケーションＩＤと専用のサービス記述子のセットを合意して、スライスのタイプに任意の組み合わせを関連付け／マッピングすることができる。

本発明の目的は、従来技術を改善することである。

本発明の第１の態様によれば、少なくとも１つのプロセッサと、コンピュータプログラムコードを含む少なくとも１つのメモリと、少なくとも１つのプロセッサとを備えた装置が提供される。少なくとも１つのメモリとコンピュータプログラムコードとは、少なくともネットワークに対してサービスのリソースを要求することを装置に少なくとも実行させるように構成され、その要求は、サービスに対して満たされるべきリソースに対する要件を示す要件指標を含む。

本発明の第２の態様によれば、少なくとも１つのプロセッサと、コンピュータプログラムコードを含む少なくとも１つのメモリと、を備えた装置であって、該少なくとも１つのプロセッサは、該少なくとも１つのメモリと該コンピュータプログラムコードとを用いて、該装置に、サービスのための第１のリソースに対する受信された要求から要求を抽出させるステップであって、要求は要求指標を含み、要求指標はサービスのために満たされるべき要件を示す、ステップと、サービスの第１の部分が第１のリソースで実行される場合の要件に対する第１のリソースの寄与を決定するステップと、サービスの第２の部分を実行するための第２のリソースを請求するステップであって、ここで、この請求は寄与指標を含み、寄与指標は要件に対する許容可能な寄与を示し、許容可能な寄与は要件および第１のリソースの寄与に基づく、ステップと、を少なくとも行わせるように構成される、装置が提供される。

少なくとも１つのメモリとコンピュータープログラムコードは、装置に、さらに、サービスの複数の第１リソースのそれぞれについて、サービスの第１の部分がそれぞれの第１のリソースで実行される場合、要件へのそれぞれの第１のリソースのそれぞれの寄与を決定するステップであって、ここで、第２のリソースの請求には、１つ以上の寄与インジケーターのペアが含まれ、それぞれが複数の第１のリソースのそれぞれの第１のリソースの識別情報を含み、それぞれの寄与指標、および、各寄与指標は、それぞれの第１のリソースの要件と寄与に基づくものである、ステップを実行させるように構成することができる。

少なくとも１つのメモリおよびコンピュータプログラムコードは、装置に、さらに、複数の第１のリソースのそれぞれについて、それぞれの寄与に基づいて、サービスの要件がそれぞれの第１のリソースによって満たされることができるかどうかをチェックするステップと、複数の第１のリソースのそれぞれについて、サービスの要件が各第１のリソースによって満たされない場合、第２のリソースの請求が各第１のリソースの識別を含む寄与インジケータペアを含むことを禁止するステップとを実行させるように構成することができる。

少なくとも１つのメモリとコンピュータープログラムコードは、装置に、さらに、第２のリソースの請求に対する受信応答が第１のリソースの選択されたものの識別であるかどうかを監視するステップと、前記応答が、第１のリソースのうちの選択されたものの識別を含む場合、第１のリソースの選択された１つをサービスに割り当てるステップとを実行させるように構成することができる。

この装置において、許容可能な寄与のうちの少なくとも１つは、第１のリソースの要件および寄与によって、寄与指標に示され得る。少なくとも１つのメモリおよびコンピュータプログラムコードは、装置に、第１のリソースの要件および寄与に基づいて許容寄与の計算をさらに実行させるように構成され得、寄与指標は、計算された許容寄与を含み得る。

少なくとも１つのメモリおよびコンピュータプログラムコードは、装置に、第１のリソースの寄与が要件を満たすことを許可するかどうかをチェックするステップと、第１のリソースの寄与により要件を満たすことができる場合、第１のリソースをサービスに割り当てるステップと、をさらに実行させるように構成され得る。

少なくとも１つのメモリおよびコンピュータプログラムコードは、装置に、第１のリソースの寄与が要件を満たすことを許可しない場合、第１のリソースの要求に応じて発信不可能性指標を提供するステップをさらに実行させるように構成され得る。

少なくとも１つのメモリおよびコンピュータプログラムコードは、装置に、第２のリソースの請求に応じて、着信不可能性指標が受信されたか否かを監視することであって、着信不可能指標は、第２のリソースが許容可能な寄与を超えていることを示すものである、監視することと、サービスの第２の部分が、第３のリソースで実行される場合の要件に対する第３のリソースの寄与を決定することと、第３のリソースの寄与が許容可能な寄与を超えているかどうかをチェックすることと、第３のリソースの寄与が許容可能な寄与を超えておらず、着信不可能性指標を受信した場合、第３のリソースをサービスに割り当てることと、をさらに実行させるように構成され得る。

本発明の第３の態様によれば、少なくとも１つのプロセッサと、コンピュータプログラムコードを含む少なくとも１つのメモリとを備えた装置が提供される。ここで、この少なくとも１つのプロセッサは、該少なくとも１つのメモリと該コンピュータプログラムコードを用いて、該装置に、少なくとも、少なくともサービスのための第１のリソースに対する受信された要求から要求を少なくとも抽出するステップであって、要求は要件指標を含み、要件指標はサービスのために満たされる要求を示す、ステップと、複数の第１のリソースのそれぞれについて、サービスの少なくとも第１の部分がそれぞれの第１のリソースで実行される場合の要件に対するそれぞれの第１の寄与を決定するステップと、要件とそれぞれの第１の寄与との間の不一致が所定の制限内にあるように、複数の第１のリソースの１つを選択するステップと、選択した第１のリソースをサービスに割り当てるステップと、を実行させるように構成されている。

要件指標は、全体的な要件指標と寄与指標を含むことができ、全体的な要件指標は、サービスに対する全体的な要件を示すことができ、寄与指標は、第２のリソースが、サービスの第２の部分を実行される場合、第２のリソースによって引き起こされる全体的な要件に対する第２の寄与を示すことができ、そして、少なくとも１つのメモリおよびコンピュータプログラムコードは、装置に、さらに、要件指標から全体的な要件を抽出するステップと、要件指標から第２の寄与するステップと、を実行させるように構成することができる。ここで、複数の第１のリソースのうちの１つは、全体の要件と、第２の寄与と、それぞれの第１の寄与の合計との間の不一致が、所定の制限内にあるように選択される。

要件には、サービスの全体的な要件と複数の第２寄与インジケータを含めることができる。第２寄与インジケータのそれぞれは、それぞれの第２リソースの識別と、第２のリソースがサービスの第２の部分を実行する場合、それぞれの第２のリソースによって引き起こされる全体要件へのそれぞれの第２寄与を示すそれぞれの第２寄与指標とを含むことができ、少なくとも１つのメモリおよびコンピュータプログラムコードは、装置に、寄与インジケータペアのそれぞれについて、それぞれの識別およびそれぞれの第２の寄与を抽出するステップと、第１の寄与のそれぞれ１つと、第２の寄与のそれぞれ１つとの１つ以上の寄与ペアのそれぞれの合計寄与を決定するステップと、全体の寄与とそれぞれの合計の寄与との間の不一致が所定の制限内にあるように、寄与するペアの１つを選択するステップと、第１のリソースの選択された第１のリソースを決定するステップであって、選択された第１のリソースは、選択された寄与ペアのそれぞれの第１の寄与に寄与する、ステップと、選択された第２のリソースの識別を決定するステップであって、それぞれの第２の寄与インジケータにしたがって、選択された第２のリソースは、選択された寄与ペアのそれぞれの第２の寄与に寄与する、ステップと、選択した第１のリソースをサービスに割り当てるステップと、選択された第１のリソースおよび選択された第２のリソースの識別についてデバイスに通知するステップであって、要求はデバイスから受信される、ステップと、をさらに実行させるように構成され得る。

本発明の第４の態様によれば、少なくとも１つのプロセッサと、コンピュータプログラムコードを含む少なくとも１つのメモリとを備えた装置であって、該少なくとも１つのプロセッサは、少なくとも１つのメモリとコンピュータプログラムコードとを用いて、装置に、少なくとも、少なくとも、サービスのための第１のリソースに対する受信された要求から、要件を抽出するステップであって、要求は要件指標を含み、要件指標はサービスに対して満たされる要件を示す、ステップと、サービスの第２の部分を実行するためにサービスに第２のリソースを割り当てるように選択装置を招待するステップであって、該招待は該要件指標を含む、ステップと、前記招待に対する応答から第２の寄与指標を抽出するステップであって、前記サービスの前記第２の部分が前記第２のリソースの上で実行される場合、該第２の寄与指標は、前記第２のリソースの寄与を示す、ステップと、第１のリソースの各々について、前記サービスの少なくとも第１の部分が前記それぞれの第１のリソースの上で実行される場合の要件に対するそれぞれの第１の寄与を決定するステップと、前記要件と、前記それぞれの第１の寄与および前記第２の寄与の合計との間の不一致が、所定の制限内にあるように、前記複数の第１のリソースのうちの１つを選択するステップと、前記選択した第１のリソースを前記サービスに割り当てるステップと、を行わせるように構成される、装置が提供される。

第３および第４の態様のいずれかにしたがう装置のそれぞれにおいて、少なくとも１つのメモリおよびコンピュータプログラムコードは、装置がさらに、前記受信された要求に応答して、前記選択された第１のリソースの識別および前記選択された第１のリソースの第１の寄与を提供するステップを実行するように構成することができる。

第３および第４の態様のいずれかにしたがう装置のそれぞれにおいて、少なくとも１つのメモリおよびコンピュータプログラムコードは、装置に、前記選択された第１のリソースの前記第１の寄与に関する情報を、前記サービスの処理に関連する課金記録に追加するステップをさらに実行させるように構成され得る。

第１から第４の態様のいずれかによる装置のそれぞれにおいて、要件は、レイテンシ、ジッタ、帯域幅、パケット損失率、エラー率、リソースタイプ、優先度、信頼性、および、該レイテンシ、該ジッタ、該帯域幅、該パケット損失率、該エラー率、該リソースタイプ、該優先度、該信頼性の少なくとも２つに基づくパラメータのうちの少なくとも１つであることができる。

本発明の第５の態様によれば、ネットワークからサービスのリソースを要求するステップを含む方法が提供され、この要求は、サービスに対するリソースの要件を示す要件指標を含む。

本発明の第６の態様によれば、サービスのための第１のリソースに対する受信された要求から、要件を抽出するステップであって、該要求は要件指標を含み、該要件指標はサービスのために満たされるべき要件を示す、ステップと、前記サービスの第１の部分が前記第１のリソースの上で実行される場合の前記要件に対する第１のリソースの寄与を決定するステップと、前記サービスの第２の部分を実行するための第２のリソースを請求するステップであって、この請求は寄与指標を含み、該寄与指標は要件に対する許容可能な寄与を示し、許容可能な寄与は要件および第１のリソースの寄与に基づく、ステップと、を含む方法が提供される。

この方法は、更に、前記サービスの複数の第１のリソースのそれぞれについて、前記サービスの前記第１の部分が前記それぞれの第１のリソースの上で実行される場合の、要件へのそれぞれの第１のリソースのそれぞれの寄与を決定するステップを含む。ここで、第２のリソースを請求するステップは、各々が、複数の第１のリソースのそれぞれの第１のリソースの識別、および、それぞれの寄与指標を含む１つ以上の寄与インジケータのペアを含めることができ、そして、寄与指標の各々は、それぞれの第１のリソースの要件と寄与に基づくことができる。

この方法は、更に、それぞれの寄与に基づいて、前記サービスの前記要件が、前記それぞれの第１のリソースによって満たされることができるかどうか前記複数の第１のリソースの各々についてチェックするステップと、前記第１のリソースの各々に対して、前記サービスの前記要件をそれぞれの前記第１のリソースにより満たすことができない場合、前記第２のリソースの請求が、それぞれの前記第１のリソースの識別を含む寄与インジケータペアを含むことを禁止するステップとを含むことができる。

この方法は、更に、前記第２のリソースを請求する受信応答が前記リソースのうちの選択された１つの前記識別を含むかどうかを監視するステップと、前記応答が、第１のリソースのうちの選択されたものの識別を含む場合、前記第１のリソースのうちの前記選択された１つを前記サービスに割り当てるステップとを含むことができる。

許容可能な寄与は、第１のリソースの要件と寄与によって、寄与指標において示されることができる。 そして、この方法は、さらに、要件に基づいて許容される寄与および、第１のリソースの寄与を計算するステップを含むことができ、寄与指標は、計算された許容可能な寄与を含み得る。

この方法は、さらに、前記第１のリソースの前記寄与により前記要件を満たすことができるか否かをチェックするステップと、第１のリソースの寄与により要件を満たすことができる場合、第１のリソースをサービスに割り当てるステップと、含むことができる。

この方法は、第１のリソースの寄与が要件を満たすことを許可しない場合、第１のリソースの要求に応じて発信不可能性指標を提供することをさらに含むことができる。

この方法は、第２のリソースの請求に応じて、着信不可能性指標が受信されるかどうかを監視するステップであって、着信不可能性指標は、第２のリソースが許容寄与を超えることを示す、ステップと、サービスの第２の部分が第３のリソースの上で実行される場合、要件に対する第３のリソースの寄与を決定するステップと、第３のリソースの寄与が許容可能な寄与を超えているかどうかをチェックするステップと、第３のリソースの寄与が許容可能な寄与を超えておらず、前記着信不可能性指標が受信された場合、第３のリソースをサービスに割り当てるステップと、をさらに含むことができる。

本願発明の第７の態様によれば、サービスのための第１のリソースに対する受信された要求から、要件を抽出するステップであって、前記要求は要件指標を含み、該要件指標はサービスのために満たされるべき要件を示す、ステップと、第１のリソースの各々について、前記サービスの少なくとも第１の部分が前記それぞれの第１のリソースの上で実行される場合の前記要件に対するそれぞれの第１の寄与を決定するステップと、前記要求と前記それぞれの第１の寄与との間の不一致が、所定の制限内にあるように複数の第１のリソースの１つを選択するステップと、選択した第１のリソースをサービスに割り当てるステップと、を含む方法が提供される。

要件指標は、全体的な要件指標と寄与指標を含むことができ、全体的な要件指標は、サービスに対する全体的な要件を示すことができ、第２のリソースが、サービスの第２の部分を実行する場合、寄与指標は、第２のリソースによって引き起こされる全体的な要件に対する第２の寄与を示すことができる。そして、この方法は、要件指標から全体的な要件を抽出するステップと、前記要件指標から前記第２の寄与を抽出するステップとをさらに含むことができる。そして、複数の第１のリソースのうちの１つを、全体の要件と第２の寄与およびそれぞれの第１の寄与の合計との間の不一致が、所定の制限内にあるように選択することができる。

この要件には、サービスの全体的な要件と複数の第２の寄与インジケータを含めることができる。第２の寄与インジケータの各々は、それぞれの第２リソースの識別と、第２のリソースがサービスの第２の部分を実行する場合、それぞれの第２のリソースによって引き起こされる全体要件へのそれぞれの第２の寄与を示すそれぞれの第２の寄与指標とを含むことができる。そして、この方法は、さらに、寄与インジケータペアのそれぞれについて、それぞれの識別およびそれぞれの第２の寄与を抽出するステップと、第１の寄与のそれぞれ１つと、第２の寄与のそれぞれ１つとの１つ以上の寄与ペアのそれぞれの合計寄与を決定するステップと、全体の寄与とそれぞれの合計の寄与の間の不一致が所定の制限内にあるように、寄与するペアの１つを選択するステップと、第１のリソースの選択された第１のリソースを決定するステップであって、選択された第１のリソースは、選択された寄与ペアのそれぞれの第１の寄与に寄与する、ステップと、選択された第２のリソースの識別を決定するステップであって、それぞれの第２の寄与インジケータにしたがって、該選択された第２のリソースは、前記選択された寄与ペアの前記それぞれの第２の寄与に寄与する、ステップと、選択した第１のリソースをサービスに割り当てるステップと、選択された第１のリソースおよび選択された第２のリソースの識別についてデバイスに通知するステップであって、前記要求は前記デバイスから受信される、ステップと、を含む。

本発明の第８の態様によれば、サービスのための第１のリソースに対する受信された要求から、要件を抽出するステップであって、該要求は要件指標を含み、該要件指標はサービスのために満たされるべき要件を示す、ステップと、サービスの第２の部分を実行するためにサービスに第２のリソースを割り当てるように選択装置を招待するステップであって、該招待は該要件指標を含む、ステップと、前記招待に対する応答から第２の寄与指標を抽出するステップであって、前記サービスの前記第２の部分が前記第２のリソースの上で実行される場合、該第２の寄与指標は、前記第２のリソースの寄与を示す、ステップと、第１のリソースの各々について、前記サービスの少なくとも第１の部分が前記それぞれの第１のリソースの上で実行される場合の要件に対するそれぞれの第１の寄与を決定するステップと、前記要件と、前記それぞれの第１の寄与および前記第２の寄与の合計との間の不一致が、所定の制限内にあるように、複数の第１のリソースの１つを選択するステップと、選択した第１のリソースをサービスに割り当てるステップと、を含む方法が提供される。

第７および第８の態様のいずれかによる方法の各々は、さらに、前記受信された要求に応答して、前記選択された第１のリソースの識別および前記選択された第１のリソースの第１の寄与を提供するステップを含むことができる。

第７および第８の態様のいずれかによる方法の各々は、さらに、前記選択された第１のリソースの前記第１の寄与に関する情報を、前記サービスの処理に関連する課金記録に追加するステップを含むことができる。

第５ないし第８の態様のいずれかによる方法の各々において、要件は、レイテンシ、ジッタ、帯域幅、パケット損失率、エラー率、リソースタイプ、優先度、信頼性、該レイテンシ、該ジッタ、該帯域幅、該パケット損失率、該エラー率、該リソースタイプ、該優先度、該信頼性の少なくとも２つに基づくパラメータのうちの少なくとも１つであることができる。

第５ないし第８の態様のいずれかによる方法の各々は、サービス選択の方法であり得る。

本発明の第９の態様によれば、装置で実行されると、装置に、第５ないし第８の態様のいずれかによる方法を実行させるように構成される命令セットを含むコンピュータプログラム製品が提供される。コンピュータプログラム製品は、コンピュータ可読媒体として具現化されるか、またはコンピュータに直接ロード可能である。

本発明のいくつかの実施形態によれば、以下の利点のうちの少なくとも１つが達成され得る。
● サービスへのリソースの割り当てに関する非常に静的な現在のアプローチが、克服される。
● ローミングの場合でも、リソース使用率を最適化できる。

上記の修正のいずれも、代替を除外するものとして明示的に述べられていない限り、それらが言及するそれぞれの態様に単独でまたは組み合わせて適用できることを理解すべきである。

さらなる詳細、特徴、目的、および、利点は、添付の図面と併せて解釈される本発明の好ましい実施形態の以下の詳細な説明から明らかである。
本発明のいくつかの実施形態による非ローミングの場合のメッセージフローを示す図である。 本発明のいくつかの実施形態によるローミングの場合のメッセージフローを示す図である。 本発明の一実施形態による装置を示す図である。 本発明の一実施形態による方法を示す図である。 本発明の一実施形態による装置を示す図である。 本発明の一実施形態による方法を示す図である。 本発明の一実施形態による装置を示す図である。 本発明の一実施形態による方法を示す図である。 本発明の一実施形態による装置を示す図である。 本発明の一実施形態による方法を示す図である。 本発明の一実施形態による装置を示す図である。

以下、本発明の特定の実施形態を添付図面を参照して詳細に説明するが、これらの実施形態の特徴は、特に記載がない限り、互いに自由に組み合わせることができる。しかしながら、特定の実施形態の説明は例としてのみ与えられるものであり、本発明を開示された詳細な説明に限定するものとして考えられることを決して意図するものではないことは明確に理解されるべきである。

さらに、場合によって、装置のみまたは方法のみが説明されているけれども、装置は、対応する方法を実行するように構成されていることが理解されるべきである。

ネットワーク選択のための従来技術のアプローチは、一般的ではなく、ひどく特異的であり、持続可能ではない。ＵＥによって設定されるべきアプリケーションＩＤを指定する必要があることには疑問がある。

さらに、特に、遅延とジッタは、これまで、３ＧＰＰ内の対応するネットワーク機能の選択プロセスにおいて適切に考慮されていないことは認識されていた。たとえば、［１］：ｈｔｔｐｓ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｄｒａｆｔ−ｎａｔａｒａｊａｎ−ｎｆｖｒｇ−ｃｏｎｔａｉｎｅｒｓ−ｆｏｒ−ｎｆｖ−０３によると、異なる種類の仮想化の遅延により、まったく異なる遅延が発生する（たとえば、表１において、遅延は４ミリ秒から３４ミリ秒まで変化する）。

低遅延および超低遅延のユースケースでは、最適なノードを見つけて選択するために、各ノードの寄与を無視することはできない。したがって、好適には、ローミングパートナーは、レイテンシとジッターの要件をすべてにおいて満たすことができるように、レイテンシとジッターに関する知識を少なくとも共有する必要がある。

従来技術では、選択手順が遅延に３４ｍｓを寄与するノードを選択した場合、選択プロセスは５ｍｓの遅延要件を満たすことができない。従来の選択プロセスでは、単に、各候補ノードの個々の遅延寄与について知らないために、そのようなノードが選択されることがあり得る。

ＵＥまたはＵＥ内のアプリケーション（スマートフォンなど）が、何らかのアプリケーションＩＤを知っている場合、そのアプリケーションのＱｏＳ／ＳＬＡパラメーターも知っている可能性がある。したがって、本発明のいくつかの実施形態によれば、ＵＥは、（ミニ）アプリケーションごとに新しいアプリケーションＩＤを作成する代わりに、最初に、ＱｏＳ／ＳＬＡパラメータの情報をネットワークに提供する。

次に、ローミングの場合においても、ＱｏＳ／ＳＬＡ要件に最適な「スライス」を割り当て／選択するのはネットワーク次第である。つまり、ネットワークはサービス要件（ＱｏＳ／ＳＬＡ）を、「スライス」の独自の展開に、マップしなければならない。したがって、各ネットワークは、異なるオペレータのスライス間の相互運用性を確保するために、ある種の「標準化されたスライス／ネットワーク」に制限されることなく、独自のニーズに応じてスライスを設定することができる。

より一般的には、スライスはサービスを実行するために割り当てられるリソースである。本発明は、仮想化（すなわち、スライス上で機能を実装すること）に依存せず、サービスを実行するための任意のリソースが上記の原理に基づいて選択され得る。リソースの別の例は、ネットワークノードまたはネットワーク機能である。

最後に、エンドユーザーはサービスの相互運用性を求めている。彼らは、実際に、１人のオペレーターがそのスライスをどのように配置するかを気にしておらず、エンドユーザーは、どのように、異なるオペレーターが異なるタイプ（フレーバー）のスライスの相互運用性を確保するかを知ることには興味がない。そこには、エンドユーザー、オペレーター、ベンダーにとっても付加価値はない。

３ＧＰＰ ＴＲ ２３．７９９に記載されているアプローチの代わりに、本発明のいくつかの実施形態によれば、ＵＥがサービスのためのリソースを要求する場合、ＵＥは、対応する要件を記述するＱｏＳ／ＳＬＡパラメータを提供する。ＱｏＳ ／ ＳＬＡパラメーターは、３ＧＰＰ ＴＲ ２３．７９９によるアプリケーションＩＤよりも動的で汎用的であると考えられるため、以降、「動的汎用ＱｏＳ／ＳＬＡパラメーター」（ＤＧＱ）と名付ける。これは一種の要件指標である。

例えば、ＵＥは、接続を希望する／必要とする各アプリケーションに対して、ＲＡＮおよびコアへのアタッチメントにおけるＤＧＱを送信することができる。特に、アプリケーション開発者は、要件を最もよく知っているため、アプリケーションに必要なコンテンツを配置／設定する必要がある。つまり、ＤＧＱはアプリケーションごとに事前定義されている。いくつかの実施形態では、いくつかの条件に応じてアプリケーションによって選択され得る１つのアプリケーションに対して複数のＤＧＱが事前定義され得る。

たとえば、アプリケーションは、
− 最小レイテンシ／最大レイテンシ
− 最大ジッター／最小ジッター
− 帯域幅−パケットエラー率
− パケット損失率−リソースタイプ（ＧＢＲまたは非ＧＢＲ）
− 優先度
− 信頼性
− ベンダー固有の拡張
のうち少なくとも１つに関する要件を提出するものとする。このリストは完全ではない。たとえば、他の要件は、これらのパラメーターの２つ以上の組み合わせに基づくことができる。

たとえば、ＵＥ内のアプリケーションが２０Ｍｂｐｓの帯域幅を必要とする場合、この番号はアタッチ要求（Ａｔｔａｃｈ ｒｅｑｕｅｓｔ）で信号伝達される（アタッチは単なる例であり、ＬＴＥ環境で現在使用されている名前と同じであるが、５Ｇなどの他のテクノロジーでは異なることがあり得る）。加えて、ＵＥは、例えば、６ｍｓのサービスの遅延要件を示すことができる。両方の要件は、新しいパラメータＵＥ ＤＧＱのそれぞれの情報要素において信号伝達される。

ＵＥによって特定のパラメーターが設定されていない場合（つまり、特定のＱｏＳ／ＳＬＡ要件が示されていない場合）、ＵＥとネットワークは、ＵＥ仕様の以前のバージョンのように動作し、動作することができる。

本発明のいくつかの実施形態によれば、ネットワークは、サービス要求の要件を満たすリソースを選択および割り当てるために、この新しい情報要素を評価する。

すなわち、ＵＥは、この新しいパラメータを、アタッチ要求において、ＲＡＮ（例えば、ｅＮＢまたはＷｉＦｉ ＡＮ）に送信する。本発明のいくつかの実施形態では、ＲＡＮは、アタッチ要求／セッション作成要求（ここでも、アタッチ要求とセッション作成要求は、ＬＴＥ環境で既に知られているリソースを要求するための単なる例である）をコアネットワークの転送するときと同様の方法で、非ローミングの場合およびローミングの場合も潜在的に、その利用可能なリソースおよび能力（すなわち、ＵＥから受信したＱｏＳ／ＳＬＡ要件への寄与）を示す別の新しいパラメータを設定する。ＲＡＮの能力（寄与）を有するこの新しいパラメータは、本発明のいくつかの実施形態による手順がサポートされることを示すために、リソースの要求に、常に含まれることができる。

すなわち、本発明のいくつかの実施形態によれば、ＲＡＮは、サービスのためのリソースを要求するとき、ＵＥから受信し、サービスの全体的な要件を示すＵＥ ＤＱＧ、および、全体的な要件に対するＲＡＮの寄与を示す別のパラメーター（例えば、ＲＡＮ ＤＧＱ）の２つのＤＧＱパラメータを転送する。いくつかの実施形態では、２つのＤＧＱパラメータの代わりに、またはそれに加えて、ＲＡＮは、コアが追加することを許可される寄与を示す別のＤＱＧパラメータを転送する。たとえば、ＵＥによって示される許容可能な全体の遅延が１００ミリ秒であり、ＲＡＮが３０ミリ秒の遅延に寄与する場合、コアは７０ミリ秒の遅延を追加することができる。これは、リソースの要求の対応するパラメーターで示されることがあり得る。

ＤＧＱパラメータを信号伝達することにより、リソースは、先行技術と比較して、より最適な方法で割り当てられ、リソース選択のために最良の推測のみが実行され得る。

新しいＤＧＱパラメータが信号伝達された場合、どのように進めるかには、一般に少なくとも、
● 要求の発信元、および、さらにリソースが要求されるネットワークの部分が、互いに独立してリソースを割り当てる、または、代替的に、
● それらが、リソースを共同で、および協働して（／ネゴシエートして）割り当てる、
の２つの可能性がある。

独立した選択は次善の割り当てにつながる可能性があるが、協働的な選択は、リソースの利用率とユーザーへのサービス提供を改善し、オペレーターのコストを削減する。一方、協働的選択には、独立した選択には必要ではないネゴシエーションが必要であり、ローミングパートナーオペレーターへの潜在的に重要な情報の開示が必要である。

例として、１つのネットワーク内で、異なるＲＡＮスライスと異なるコアネットワークスライスの選択は、独立してまたは協働して実行される。同様に、ローミングの場合、サービスに割り当てられたＶＰＬＭＮおよびＨＰＬＭＮのリソースは、ネットワークごとに独立して、または、ネットワーク間で協調して選択できる。

以下では、本発明のいくつかの実施形態によるローミングの場合の協調的選択がより詳細に概説される。

このシナリオでは、ＶＰＬＭＮ（ＲＡＮの直接またはコアの潜在的に分離されたＣＰのいずれか）は、セッション作成要求（Ｃｒｅａｔｅ Ｓｅｓｓｉｏｎ ｒｅｑｕｅｓｔ）の信号伝達を介して、候補ＣＰおよび／またはＵＰアドレスをＨＰＬＭＮと共有する。好ましくは、さらなる相乗効果を得るために、ＲＡＮとコアのＣＰの間、および、ＶＰＬＭＮのＣＰとＨＰＬＭＮのＣＰの間の上位層プロトコルは、同じでなければならない。これにより、たとえば、ＶＰＬＭＮのＲＡＮが、ＨＰＬＭＮのＣＰに直接接続されることが許容される。ただし、上記の要件は必須ではない。例えば、ＶＰＬＭＮのＲＡＮは、ＶＰＬＭＮのＣＰを介して、ＨＰＬＭＮのＣＰと通信することができる。

ＵＥのＤＧＱを分析した後、例えば、ＶＰＬＭＮは、ＤＧＱ内のＶＰＬＭＮの候補リソースのＣＰおよびＵＰのうちの少なくとも１つに対するアドレスおよび／または位置のリストを、ＨＰＬＭＮに、提供／信号伝達することができる。これらのアドレスのリソースは一致し、および／または、少なくともＵＥの要件に違反しない。ＶＰＬＭＮが要件を満たせない場合、ＶＰＬＭＮはＵＥの要求を拒否するか、または、ＶＰＬＭＮが、要件を緩和するように請求することができないことを、ＵＥに通知する。

ＵＥ ＤＧＱとＶＰＬＭＮのＤＧＱの両方を受信すると、ＨＰＬＭＮはＶＰＬＭＮのＵＥ ＤＧＱとＤＧＱを評価し、ＵＥ要件が満たされるようにＨＰＬＭＮ内でリソースを選択するために、ＵＥの要件をＶＰＬＭＮの「消費された」および／または提案された寄与と比較する。さらに、ＨＰＬＭＮは、ビジネスニーズまたは選択におけるその他の制約を考慮することができる。

例の要件は、ＵＥの（ユーザープレーン）レイテンシ要件である。たとえば、ＵＥが、ａ）１１ｍｓ、または、ｂ）４ｍｓの最大レイテンシを必要とすると仮定すると、ａ）すでに６ミリ秒、ｂ）すでに２ミリ秒が消費された場合のＶＰＬＭＮの指標に応じて、ＨＰＬＭＮは、ａ）の場合、例えば５ｍｓが使用され、ｂ）の場合、２ｍｓのみが使用されるようなそのリソースを選択する。

これは、ａ）の場合、リソースは、ＵＥから最大２．５＊６６ｋｍ＝１６５ｋｍ離れている可能性がある（この計算では、ファイバーが使用され、平均して「視界」距離の３倍の光学距離と、２０００００ｋｍ／ｓの速度を持つと想定している）ことを意味する。ただし、ケースｂ）では、ＨＰＬＭＮは、ＵＥから約６６ｋｍ離れた最大物理距離のリソースと、ＶＰＬＭＮの割り当てられたリソースを選択する必要がある。ＨＰＬＭＮがそのような場所に対応するリソースを持っている場合、ＨＰＬＭＮは、生成セッション（Ｃｒｅａｔｅ Ｓｅｓｓｉｏｎ）応答において対応する自身のリソースのアドレスを返し、ＶＰＬＭＮによって以前に提供されたリソースの１つをコミットすることを提案される。ＶＰＬＭＮで応答を受信すると、ネゴシエーションが完了する。

ただし、ＨＰＬＭＮの周辺にリソースがない場合もある（例えば、ｂ）のケースで要求されるような場合）。本発明のいくつかの実施形態では、何らかの最後の手段として、ＨＰＬＭＮは、この場合でもＵＥのサービス要求を満たすことができるように、リソースの選択をＶＰＬＭＮに委任する。したがって、ＶＰＬＭＮは、ＨＰＬＭＮの周辺でも再利用できるように独自のリソースを提供する。委任できるようにするには、どのリソースがＨＰＬＭＮに割り当てられていないか、しかし、どのリソースが代わりにＶＰＬＭＮに割り当てられるべきか、に応じて、ＨＰＬＭＮが、生成セッション（Ｃｒｅａｔｅ Ｓｅｓｓｉｏｎ）応答における新しい情報要素（たとえば、名前付き不可能指標（ｎａｍｅｄ ｉｍｐｏｓｓｉｂｉｌｉｔｙ ｉｎｄｉｃａｔｉｏｎ））でその不可能性を示すことが提案される。

一般に、どのようにレイテンシを推定および計算するか、どのように対応するリソースの選択を実行するか、について、
１． ネットワークノードは、推定レイテンシを収集または計算し、対応する累積レイテンシ値をピアに信号伝達する／または、
２． ピアは、対応するノードの関連する場所を交換し、地理的距離および／またはネットワークトポロジに基づいてピア間の遅延を計算することができる、
の少なくとも２つのやり方がある。この位置情報の交換を可能にするために、ネットワークスライスを実行している各クラウドセンターに、それぞれのグローバルクラウドＩＤを割り当てることができる。この２つのアプローチを組み合わせることができる。

遅延と同様にジッタを推定または計算できる。ただし、帯域幅やパケット損失などの他のＫＰＩのリソースは、要件に違反するリソースを単に選択しないことで、選択することができる。たとえば、１０−５以上のパケット損失率が必要な場合、たとえば、１０−４のレートのリソースは、リソースを選択するときに考慮されない。

図１および図２は、本発明のいくつかの実施形態による、非ローミング（図１）およびローミングの場合（図２）における持続可能なサービス選択の例を示している。ＩＰアドレスを含むＧＴＰトンネルＩＤを典型的に示すＦＴＥＩＤは、コントロールプレーンとユーザープレーンの終端ポイントを説明するための単なる例である。コントロールプレーンとユーザープレーンのトラフィックを交換するための、ピア間の他のエンドポイントもカバーするプレースホルダーとして理解されるべきである。

図１に示すように、ＵＥはアタッチ要求とともに、ＵＥ ＤＧＱなどの要件指標をＲＡＮに提供する。受信したアタッチ要求により、ＲＡＮはＵＥ ＤＧＱ、ＡＮ ｃａｐ ＤＱＧ（つまり、アクセスネットワーク機能ＤＧＱ）を含むコアのＣＰにセッション作成要求を発行する。これは、ＵＥ ＤＧＱによって示される要件に対するＲＡＮの機能／寄与、および、潜在的な候補リソースのＩＤ（ＩＰまたはイーサネット（登録商標）アドレスなど）を保持するＡＮ ＣＰ／ＵＰ ＦＴＥＩＤ（アクセスネットワークコントロールプレーン／ユーザープランＦＴＥＩＤ）を示す。セッション作成要求を受信すると、ＣＰは、・・ことを指示する。例えば、ＯｐｅｎＦＬｏｗで定義されているＦｌｏｗＭｏｄ（フロー修正）により、ＵＰ ＦＴＥＩＤ（ユーザープレーンの完全修飾トンネルエンドポイントＩＤ）およびＨＰＬＭＮ ＤＧＱ を備えるＵＰに、対応するＯｐｅｎＦｌｏｗルールをユーザープレーンにインストールすることができる、加えて、ＡＮ（例えば、ＲＡＮ）に、ＨＰＬＭＮおよびＲＡＮ／ＡＮにおける選択したリソースのＣＰ（コントロールプレーン）とＵＰ ＦＴＥＩＤについて通知し、そしてＡＮ ｓｅｌ ＤＧＱ（ＡＮで選択されたＤＧＱ）を提供する。たとえば、協働モードでは、オリジンは候補リソースを提供し、終端ＨＰＬＭＮ側は、候補リストから、ＵＥによって信号伝達／要求される要件を満たす特定の（セットの）リソースを選択する。そのために、ＨＰＬＭＮは、ＡＮ ｓｅｌ ＤＧＱを介して、ＡＮで選択されたリソースについてＡＮに通知する。

図２のローミングの場合、ＶＰＬＭＮのＣＰは、非ローミングの場合について説明したのと同様に、ＶＰＬＭＮのＵＰと相互作用する。そこでは、ＨＰＬＭＮ ＤＧＱがＶＰＬＭＮ ＤＧＱに置き換えられているさらに、ＶＰＬＭＮのＣＰは、ＨＰＬＭＮのＣＰに初期要求を送信し、ここで、初期アタッチ要求は、ＵＥ ＤＧＱ、ＣＰおよびＵＰ ＦＴＥＩＤ、およびＶＰＬＭＮキャップＤＧＱを含み、それは、ＵＥ ＤＧＱによって示される要件へのＶＰＬＭＮの寄与を示す。ＨＰＬＭＮのＣＰは、非ローミングの場合と同様に、ＨＰＬＭＮのＵＰと相互作用する。ＶＰＬＭＮからの初期要求に応じて、ＨＰＬＭＮ ＣＰはＣＰおよびＵＰ ＦＴＥＩＤとＨＰＬＭＮ ｓｅｌ ＤＧＱ（すなわち、ＨＰＬＭＮで選択されたＤＧＱ）を提供する。

リソースの選択は、協働的であっても、非協働的であってもよい。非協働的なシナリオでは、２つのＰＬＭＮの各々が、互いに独立して、それぞれのリソースを選択する。特に、ＶＰＬＭＮはそのリソースを選択し、ＨＰＬＭＮに向けてリソースのアドレス（ＣＰプレーンやＵＰプレーンなど）を信号伝達する。したがって、このソリューションでは、ＨＰＬＭＮは、ＵＥの全体的な要件を満たすために、ＶＰＬＭＮが共有する入力に、リソースの選択を適応させる必要がある。これは、対応するリソースの選択／配置の最適な解決策にはならないかもしれないが、オペレーターがリソースのリストを共有しており、外部オペレーターによる自身のリソースの選択を許可する必要はない。一般に、ポリシーとビジネスニーズに応じて、両方のオプション（協働的、非協働的）を適用できるため、これら２つのオプションは２つのオペレータ間で動的にネゴシエートされるか、事前に構成することができる。

非ローミングケースは、１つのオペレータのみが関与するために、ローミングケースを多少簡略化されるが、このオペレータにはＵＥの要求に応じて全体の要件を満たす自由と義務がある。ただし、オペレーターがＲＡＮとコアリソースを同時に所有しているため、たとえば、ＲＡＮとコア全体で遅延を分割する方法を決定しなければならない。たとえば、オペレーターはＲＡＮにより多くの遅延を割り当て、それによりコアにより少ない遅延を割り当てることができる。これは、ＲＡＮの近くにあるクラウドからコアリソースが選択されることを意味する。ＲＡＮで許容される遅延が少ない反対のケースでは、ＲＡＮから離れた場所にあるクラウド／データセンターから、コアリソースを選択できる。一般に、ローミングの場合と同じ手順とパラメータを利用できる（たとえば、図１と図２を比較）。ＲＡＮでＵＥ ＤＧＱパラメータを受信すると、ＲＡＮは、利用可能なリソースおよび利用についてデータベースに問い合わせることにより、動的なジェネリックＱｏＳ／ＳＬＡパラメータ（ＤＧＱ）を評価することができる。たとえば、１つのオプションでは、ＲＡＮは外部または内部データベースを参照して、ＵＥ ＤＧＱのコンテンツに基づいて内部リソースを計算および選択する。

ＲＡＮ内部のリソースを選択した後、または同時に、ＲＡＮは外部または内部データベースを参照して、コアネットワークのホーム／ローカル／訪問済み部分を選択する。これらのネットワークパーツは、ＵＥ ＤＧＱとＲＡＮからの寄与を含む信号伝達された情報に基づいて、リソースを選択できる。

あるいは、本発明のいくつかの実施形態によれば、コア（／ＨＰＬＭＮ）は、全体の予算を選択／決定し、ネットワークのその部分のリソースを選択し、要件に関する残りの予算（寄与）を計算し、それを、ＲＡＮ［／ＶＰＬＭＮ］に返して信号伝達し、それに応じてリソースを構成する。第１のケースは、例えば、非ローミングケース、および、ローミングケースのＶＰＬＭＮの場合に適用可能である。第２のケースはローミングケースに適用することができる。

上記の（ＫＰＩ／ＱｏＳ／ＳＬＡ）属性は、他の属性に大きな影響を与えることなく、ある範囲内で互いに独立して制御できることに留意する。これは、帯域幅は、ＲＡＮスライシングを使用したｅＮＢ／ｎｅｗＲＡＮ内であっても、レイテンシとは無関係に構成できることを意味する。したがって、スライスタイプを事前に事前定義／事前構成する必要はない。これにより、柔軟性が生まれ、オペレーターに付加価値が提供される。

したがって、本発明のいくつかの実施形態によれば、ｅＮＢ／ｎｅｗＲＡＮは、上記の属性自体を評価するか、ＵＥの要件が満たされるようにリソースを構成するためにコアネットワーク（例えば、ＬＴＥアーキテクチャのＭＭＥなど）によって制御されるかのいずれかにより、各属性に応じて内部的に構成される。ＲＡＮは、０から最高値までのわずかな短いステップの構成を回避するために、１から６までの数で識別される特定の範囲内の各属性に対して構成可能であることが好ましい。ただし、属性のフローティング表示は除外されない。

表２に、ｎｅｗＲＡＮの機能とその分類の例を示す。同様のパラメータを、順方向および逆方向のローミングパートナー間のインターフェイスに導入することができる。

上記の表にリストされているＫＰＩ／属性および値は単なる例であり、完全ではない。他の属性は、それに応じて分類できる。この表は、属性に柔軟かつ独立して対処する方法を示している。さらに、ＭＭＥ（または、より一般的なコアのＣＰ）は、各属性／リソースの予算の残りの部分について同様のテーブルと構成パターンを維持することができる。

選択を支援するために、ｎｅｗＲＡＮ／ＬＴＥ（一般的に、アクセスネットワーク、または、サービスの実行に関与する他のノード）は、必要なリソースに関する独自の機能を信号伝達できる。たとえば、問題のＲＡＮが１０−６のパケット損失を提供できる場合、ＲＡＮはパケット損失率の数値１を送信する。

これにより、ＲＡＮがコア構成から切り離され、コアは、コアにおいて利用可能なカテゴリから任意の値を選択するようにＲＡＮに指示し、必要に応じて経済的に実行可能な、サービスを動的に組み合わせて構成する。事前にオペレータ全体の定義済みおよび標準化されたスライスを作成する必要はない。あるいは、任意のＲＡＮにおいて、ネットワーク内に新しいスライスを必要とする新しいサービスタイプを必要とする新しいアプリケーションが出現した場合、ＲＡＮとＣｏｒｅ間のインターフェイスに影響を与えない。また、たとえば、ＭＭＥ（コントロールプレーン）（またはＨＰＬＭＮまたはＶＰＬＭＮのその他のインスタンス）が、ＵＥが遅延ｘ、帯域幅ｙを要求していることを認識した場合、ＭＭＥはｅＮＢとコアネットワーク全体で予算を分割できる。ローミングの場合でも、ＵＥから送信されたサービス要件は、ホームＰＬＭＮに信号伝達され、ホームＰＬＭＮは各属性の全体予算の一部を自身に割り当て、残りの一部をＶＰＬＭＮに、割り当てることができる。また、ＶＰＬＭＮは、ＵＥの需要を満たすためのリソースの最適な分割として決定されたとおり、その割合をＲＡＮおよびコアネットワーク全体に動的に割り当てることができる。

あるいは、本発明のいくつかの実施形態では、ローミングする場合、ＭＭＥ（または一般にＶＰＬＭＮの制御プレーン）は、問題のリソースのそれぞれの能力を信号伝達することもでき、したがって、２つの演算子間で分割されるように、関連ＫＰＩに対してフラクションの一部を選択するために、ＨＰＬＭＮに提供することができる。

最適な方法でリソースを割り当てるためには、ＨＰＬＭＮが、ＵＥの位置、ＵＥのＱｏＳ要件、および、自身の候補リソースを知っていることが有益であり、そして、自身の能力と位置を備えたＶＰＬＭＮの能力を備えた候補リソースは、ＵＥの要件を満たすために、自身の候補リソースとＶＰＬＭＮの候補リソースの最適な組み合わせを決定／計算する。

たとえば、ＨＰＬＭＮが、要求されたサービスのためにＵＥの領域で利用可能なネットワークリソースを持たない場合、ＨＰＬＭＮは、ＶＰＬＭＮがアプリケーションに対して何らかの種類のショートカットを実行することをＶＰＬＭＮに信号伝達できる（これは、ローカルブレイクアウトのケース（ホームルーティングではない））。このようにして、オペレータは非常に動的な環境の状況に応じて柔軟な決定／選択を利用する。本発明のいくつかの実施形態では、ＨＰＬＭＮはそれ自身のリソースを選択することができ、ＶＰＬＭＮも、それ自身のポリシーおよびビジネスニーズに基づいて、それ自身のリソースを選択することができる。協力的な選択の場合でも、ＨＰＬＭＮおよびＶＰＬＭＮは、独自のポリシーおよびビジネスニーズに基づいて、それぞれの候補リソースを選択できる。

したがって、ＨＰＬＭＮは、ＶＰＬＭＮが、自身のニーズにしたがって、リソースを選択するのに十分な自由があり得ることをＶＰＬＭＮに示すことができる。つまり、これらの実施形態のいくつかでは、ＨＰＬＭＮはＵＥの要件を満たすために、残りの予算についてＶＰＬＭＮに通知することができ、ＶＰＬＭＮは残りの予算について、受信した指標に基づいてそのリソースを選択し、それにしたがってＨＰＬＭＮとＵＥに通知する。この手順には、ＶＰＬＭＮが一部の候補リソースの機能についてＨＰＬＭＮに通知する必要がないという利点があるが、選択された候補リソースについて通知するためには、ＶＰＬＭＮからＨＰＬＭＮへの追加の信号伝達が必要である。本発明のいくつかの実施形態によれば、ＶＰＬＭＮが、ＨＰＬＭＮからリソースを要求する場合に、この追加の信号伝達を回避することができ、ＨＰＬＭＮが選択できる能力を備えた候補リソースのリストを提供することができる。次に、ＨＰＬＭＮは、ＨＰＬＭＮからＨＰＬＭＮへの追加の信号伝達が不要になるように、ＨＰＬＭＮの選択されたリソースおよびＶＰＬＭＮの選択された候補リソースでＶＰＬＭＮに通知する。本発明のいくつかの実施形態では、ネットワークごとに、または、ＨＰＬＭＮとＶＰＬＭＮの各ペアに対して、協働選択のオプションのいずれが適用されるかが事前に構成されている。本発明のいくつかの実施形態では、ＨＰＬＭＮおよびＶＰＬＭＮは、適用するオプションを動的にネゴシエートすることができる。

ＶＰＬＭＮが候補リソースのリストを提供し、ＨＰＬＭＮがＶＰＬＭＮ候補リソースからリソースを選択する場合、これにより高速セットアップが可能になるが、ＨＰＬＭＮがＶＰＬＭＮリソースを知らずに独自のリソースを選択する場合、ＶＰＬＭＮは、その後、選択されたリソースについて通知する必要があり、これにより、サービスのセットアップが遅れる。したがって、本発明のいくつかの実施形態によれば、ネゴシエーションの結果は、ＵＥによって要求されたサービスの必要性に依存し得る。

状況によっては、ＲＡＮのユーザープレーン（ｅＮＢまたはｅＮＢ＋など）が、コントロールプレーンとユーザープレーンに分割され、同じオペレーターからのコアが、コロケートされている、または、同じエンティティであり得ることが有益な場合がある（ユーザープレーンホップが少ないため、これにより遅延がさらに減少する）。その場合、コアの制御プレーンとＲＡＮの制御プレーンとは、コロケートされている場合とない場合がある。しかし、いずれにせよ、上記のように、相互運用性を改善するために、ＲＡＮとコア間のインターフェースが、２つの異なるオペレーターのコアネットワーク内のインターフェースと同じであることが望ましい場合がある。さらに、モビリティのないサービスなどの場合、コアの（モビリティ）コントロールプレーンは実際には必要なく、ＶＰＬＭＮのコアの専用コントロールプレーンがなくても、ＲＡＮのコントロールプレーンをローミングパートナーに直接接続できる。したがって、本発明のいくつかの実施形態では、モビリティの必要がないことを示す情報要素が使用される。この情報要素が検出された場合、（または、この情報要素に事前定義された値がある場合）、ユーザープレーントラフィックとコントロールプレーントラフィックは、ＭＭＥをさらに関与させることなく、ｅＮＢとＳＧＷの間で直接交換される。たとえば、ＬＴＥに関しては、情報要素（または、情報要素が事前定義された値を持っていること）を検出したＭＭＥは、ＭＭＥが、以降の通信で、コントロールプレーンに対してバイパスされるように、ｅＮＢの制御プレーンアドレスをＳＧＷに転送し、ＳＧＷの制御プレーンアドレスをｅｎＢに転送することができる。既存のＡＰＮ（アクセスポイント名）を再利用して、ＵＥによってアドレス指定されるアプリケーションを識別およびアドレス指定できる。

アプリケーションに必要な属性の明示的な値を保持する汎用パラメーターＤＧＱの導入では、新しいアプリケーションごとに新しいアプリケーションＩＤやサービス記述子を登録することが必要であることを要求しない。ネットワークは、時々の新しいＩＤや記述子を導入による影響を受けない。したがって、新しいアプリケーションを非常に迅速に展開できる。新しいアプリケーションを展開でき、経済が繁栄するために、障壁がなくなり、経済の進歩が促進される。本発明の実施形態のオペレータは、新しい用途および収益を引き付けることができる。

オペレータは、加入者のニーズ、および／またはオペレータのビジネスニーズ、および／またはオペレータのポリシー、および／またはコストおよび／または利用レベル、および／または可用性に応じて、オペレータのリソースを自由に割り当てることができる。以下では、サービスの潜在的な要件の１つとしての遅延について詳しく説明する。

一般に、遅延は、少なくとも、伝送遅延（ＴｒａｎＤ）、処理遅延（ＰｒｏｃＤ）、および伝搬遅延（ＰｒｏｐＤ）を含む。

伝播遅延（ＰｒｏｐＤ）：これは、信号（たとえばレーザー信号）が伝送媒体（たとえば、ファイバー）の光の速度によって制限されるという事実から生じる遅延である。

伝送遅延（ＴｒａｎＤ）：この遅延は、リソースに割り当てられた送信／受信の有限帯域幅によって引き起こされる。たとえば、ネットワークがリソースの潜在的に利用可能な帯域幅を知っており、候補リソースに高い帯域幅を割り当てることを決定した場合、伝送遅延を減らすことができる。したがって、関連するコストを推定および最適化できる。

処理遅延（ＰｒｏｃＤ）：これは、先行技術で述べたように行われた観察に関連しており、異なる仮想化技術は異なる処理遅延につながる可能性があり、仮想化が最も低いレイテンシを提供しないとは限らない。

（少なくとも）これらの３つの遅延の合計がｅ２ｅ遅延を決定するので、本発明のいくつかの実施形態によれば、選択プロセスは、これまでに蓄積された遅延、関連するコストで選択される候補リソースの潜在的な遅延、および、満たす必要がある遅延要件を知っていることができる。その場合、選択プロセスは、最適なコストでリソースを選択できる。

これを確実にするために、本発明のいくつかの実施形態によれば、ＵＥは、ＲＡＮ（またはＦＭＣ環境の任意の固定アクセスノード）に送信されるＵＥＤＧＱを介して、特定の最大遅延および／または最大ジッタを要求することができる。サービスの実行に参加する各ノード（例えば、ＲＡＮ、ＡＮ、ＭＭＥ、ＳＧＷ、ＰＧＷ、ＰＧＷ−Ｃ、ＳＧＷ−Ｃ、ＰＧＷ−Ｕ、ＳＧＷ−Ｕ、ＣＳＣＦ（プロキシＣＳＣＦ、ＣＳＣＦの問い合わせ、ＣＳＣＦの提供）、ＩＢＣＦ、ＳＧＳＮ／ＧＧＳＮおよびＢＧＷまたはＴｒＧＷ）は、選択された場合、遅延またはジッターへの自身の寄与を、（コントロールプレーン）信号伝達に追加することができる、あるいは、選択ノードが、データベースから問題のノードに関連する処理遅延またはジッターを取得することができる。

たとえば、ＲＡＮ（通常は、ＵＥによって選択される）は、適切なＭＭＥを選択する。いくつかの実施形態では、ＲＡＮは、すでに蓄積された遅延について、ＭＭＥに通知する。この情報は、ＵＥからＲＡＮへの累積遅延（つまり、ＰｒｏｃＤ、ＰｒｏｐＤ、および、ＴｒａｎＤの合計）を含むことができる。いくつかの実施形態では、ＲＡＮは、ＰｒｏｐＤ（ＵＥとｅＮＢとの間で実質的に固定されていると考えられる）でＭＭＥに通知し、サービス実行に寄与し得るＰｒｏｃＤおよびＴｒａｎＤの範囲について通知する。つまり、ＲＡＮのＰｒｏｃＤとＴｒａｎＤは、選択したＲＡＮに対して必ずしも固定されているわけではない。たとえば、ＴｒａｎＤは、異なる帯域幅をＵＥ−ｅＮＢ接続に割り当てることによって適応でき、ＰｒｏｃＤは、適切なプロセッサを選択することによって、および／またはＴＴＩを適応することによって適応できる。

あるいは、ＲＡＮが、ＰｒｏｃＤ、ＰｒｏｐＤ、ＴｒａｎＤ（またはその合計）に対する独自の潜在的な寄与を、信号伝達に追加しなかった／できなかった場合、ＭＭＥは、個々のＲＡＮの識別に基づいて、潜在的なＰｒｏｃＤ、データベースからのＴｒａｎＤ（内部または外部の）を取り出すことができる。ＵＥとｅＮＢ間のＰｒｏｐＤは、ほとんどの場合、ごくわずか（または、たとえばセル半径に基づく定数）と考えられる。さらに、このようなデータベースでは、また、２つのネットワークノード間の伝播遅延（ＰｒｏｐＤ）も保持されることができる、あるいは、おそらくは、それぞれのクラウドセンターの識別に基づいて動的に取得される。

ＭＭＥ（または、５Ｇまたは３Ｇなどの同様の／対応する機能）は、ＵＥが要求する遅延、ＲＡＮの遅延指標、および、おそらく割り当てられる候補リソースの候補遅延を受信する。

このアプローチにより、ＭＭＥは、ＵＥからの詳細な遅延要件、すでに蓄積された遅延、および、ＭＭＥによる選択のための候補リソースの潜在的に利用可能な追加的なさらなる遅延を知ることができる位置にいる。たとえば、選択ノードであるＭＭＥは、潜在的なＰｒｏｃＤ値、ＴｒａｎＤ値、および、関連するコストとともに、ＳＧＷ／ＰＧＷ−Ｕ（または、３Ｇおよび／または５Ｇ内の同様の機能）の候補のＩＤを保持するデータベースにアクセスできる。ＳＧＷ／ＰＧＷ−Ｕは、制御プレーンから分離されたＳＧＷ／ＰＧＥのユーザープレーン部分であるか、または、従来のＳＧＷ／ＰＧＷ内に統合され得る。ネットワーク機能の仮想化は、将来のアーキテクチャのために明示的に除外されないため（ＣＵＰＳ、５Ｇ、ＥＴＳＩ ＮＦＶなど）、ＲＡＮと候補ＳＧＷ−Ｕ／ＰＧＷ−Ｕの間の伝播遅延（ＰｒｏｐＤ）は、常に同じ値に固定されるとは限らない。固定されていない場合、ＭＭＥの選択プロセスは、例えば、それぞれのクラウドセンターの識別に基づいて、候補ピア間の実際の伝播遅延（この場合は、発信ＲＡＮと候補Ｓ／ＰＧＷ−Ｕ間の）を認識させる必要がある。ただし、ＰｒｏｃＤ、ＰｒｏｐＤ、ＴｒａｎＤ、および関連するすべての候補ＳＧＷ−Ｕ／ＰＧＷ−Ｕのコストを同時に考慮すると、ＭＭＥでの選択プロセスは、ＵＥから信号伝達された要件を引き続き満たすため、最終的に候補の（たとえばビジネスニーズに基づいて）最適なものを選択できる。この計算に基づいて、対応するＳＧＷ−Ｕ／ＰＧＷ−Ｕインスタンスは、対応するコントロールプレーン信号伝達を介して、そのＳＧＷ−Ｕ／ＰＧＷ−Ｕに、割り当てられるように要求される。

いくつかの実施形態では、ＭＭＥは、適切なＳＧＷ−Ｕ／ＰＧＷ−Ｕを割り当てるだけでなく、ＴｒａｎＤおよびＰｒｏｃＤの利用可能な範囲がＲＡＮによって提供されるならば、それらの範囲の指標に基づいて、ＲＡＮ内のＴｒａｎＤおよびＰｒｏｃＤを決定することができる。つまり、ＭＭＥは、ＲＡＮとＳＧＷ−Ｕ／ＰＧＷ−Ｕの組み合わせによって、サービスの全体的な要件が実質的に満たされるように、特定のＴｒａｎＤとＰｒｏｃＤを提供するようにＲＡＮに指示できる。ＭＭＭＥは、ＳＧＷ−Ｕ／ＰＧＷ−Ｕを割り当てるとき、または、その割り当ての成功の確認時に、ＲＡＮに指示できる。

コアのｅＮＢとＵＰとの間の遅延は、遅延（およびジッタ）のユーザー要件を満たすために、同様の方法で再配置できる。つまり、ＭＭＥは、参加ノードの潜在的な遅延能力と、候補ノード間の潜在的な伝播遅延とを評価し、最小限のコストで要件を満たすために、関連する／選択されたノードおよびＲＡＮ／ｅＮＢのリソース全体に全体の遅延制限の個々の割合／部分を割り当てる。たとえば、偶然、ＵＥが現在、仮想化されたユーザープレーンインスタンスの候補の近くにある、例えば、クラウドに配置されている場合、このため、比較的高い処理遅延で、（一般的に、ユーザープレーンの仮想化は、仮想化されていないユーザープレーンに比べて遅延を増加させるため）、この例では、伝播遅延が低いため、選択プロセスは仮想化されたユーザープレーンを優先する。

一方、ＲＡＮと候補ユーザープレーン間の対応する伝搬遅延が比較的大きい場合、選択プロセスでは、上記の例と比較して処理遅延が低い仮想化ユーザープレーン、または、ユーザープレーンのいずれかを選択する必要がある。後者は、仮想化されていないため、処理の遅延が最小限に抑えられる。オペレーターにとって合理的なコストで、このアプローチによってＵＥが要求するニーズを満たすことができる場合、Ｓ／ＰＧＷ−Ｕとの間で（ＵＥが最初に要求した）より高い帯域幅を割り当てることにより、伝送遅延を削減できることに留意すべきである。

遅延と同様に、ジッタ要件も、ＵＥからネットワークに信号伝達される。それに応じて、各ノード（たとえば、ＲＡＮまたはコア）は、選択プロセス（たとえば、ＭＭＥ）が、連結される候補リソースの個々のジッタ寄与の合計を推定できるように、現在のリソースまたは候補リソースに関連するジッタの部分を追加する。あるいは、候補リソースのジッターは、ＭＭＥによって、データベースクエリによって取得できる。したがって、ＭＭＥは、最適なコストでＵＥの要件を満たすリソースを選択できる。上記の説明は、非ローミングユースケースに基づいている。以下に、ローミングの使用例の手順を示す。

また、ローミングの場合、ＵＥはネットワークに向けて実際の要件（遅延やジッタなど）を明示的に信号伝達する。

本発明のいくつかの実施形態では、ＶＰＬＭＮは、ＵＥ要件およびビジネスニーズに基づいて、そのリソース（例えば、ＳＧＷ−Ｕ）のみを選択し、選択されたインスタンスと、現在蓄積されている遅延および／またはジッタを、ＵＥ要件とともに、ＨＰＬＭＮに信号伝達する。これに基づいて、すでに選択されているインスタンスとＨＰＬＭＮの候補との間のＰｒｏｐＤを考慮して、ＨＰＬＭＮは、独自のリソースを割り当てようとする。これは、独自のネットワーク内の候補、累積された遅延および、独自のネットワーク内の候補リソース（ＰＧＷ−Ｕなど）のジッターと特性およびコストを考慮して評価することにより、行われる。これは、ＵＥの要件が、ビジネスニーズに応じて、妥当な／許容できる／最適なＨＰＬＭＮコストで満たされているように行われる。これが、最適ではないソリューションにつながること、または、ソリューションが全く可能ではないことを除外することはできない。

いくつかの実施形態では、ＶＰＬＭＮは、ＨＰＬＭＮに、ＳＧＷ−Ｕの候補インスタンスのリストと、遅延に対するＴｒａｎＤおよびＰｒｏｃＤの関連する蓄積および／または潜在的な寄与とを提供する（ｅＮＢが非ローミングの場合にＭＭＥに提供したように）。ＨＰＬＭＮがＰＧＷ−Ｕ候補の独自のリストから選択する場合、これらの候補はＨＰＬＭＮで検討できる。一般に、この手順は、上記の非ローミングの場合で説明した手順と非常に似ている。つまり、ＨＰＬＭＮは、ＶＰＬＭＮとＨＰＬＭＮの両方のリソースの候補と、ＴｒａｎｓＤとＰｒｏｃＤへの個々の寄与の概要を有している。候補ＳＧＷ−ＵピアとＰＧＷ−Ｕピア間の実際の伝搬遅延（上記の非ローミングのケースを参照）を計算する手段と併せて、ＨＰＬＭＮは、候補のリストからＳＧＷ−ＵとＰＧＷ−Ｕのペアを選択できる。これは、ビジネスニーズに応じて、最適／合理的／許容可能なコストでＵＥ要件を満たす。次のステップにおいて、ＨＰＬＭＮは、ＶＰＬＭＮで選択されたインスタンス（これは、もちろん、最初に提供されたリストの一部であった）と同様に、ＨＰＬＭＮで選択されたインスタンスをＶＰＬＭＮに信号伝達する。ＶＰＬＭＮでＨＰＬＭＮ応答を受信すると、選択されたインスタンスはＨＰＬＭＮとインターフェイスするように構成される。この場合、最終決定はＨＰＬＭＮで行われるため、選択プロセスは可能な限り幅広いソリューションからリソースを選択でき、最適／合理的／許容可能なコストで全体的なソリューションが向上する。

［チャージング／アカウンティング］
協働選択の場合、潜在的に機密情報が（潜在的に競合する）オペレーター間で交換されるため、この情報の共有は報われる可能性がある。たとえば、ローミングパートナーは、全体の遅延に寄与する部分および／またはＵＥによって信号伝達された全体のジッタ要件に反比例する（または同様の）収益を共有する場合がある。それ以外の場合、ＨＰＬＭＮは、ＶＰＬＭＮを犠牲にして、ＶＰＬＭＮで高性能で潜在的にコストのかかるリソースを選択できる、または、選択できた。ただし、ＶＰＬＭＮはこの機密情報を共有したくない場合があり、その努力に対して報われない場合、高価なリソースを提供したくないことがあり得る。

したがって、本発明のいくつかの実施形態によれば、対応するオペレータによって寄与される実際の遅延およびジッタ等は、チャージング／アカウンティング記録に追加される。Ｇｘ、Ｇｘｘ、Ｇｙ、Ｇｚなどの、対応する３ＧＰＰ充電プロトコルは、それに応じて拡張できる。また、ＶＰＬＭＮは、情報を共有するための何らかの基本給でも報いられることができる。

本発明のいくつかの実施形態では、ＨＰＬＭＮは、その候補ＰＧＷ−Ｕの同じ情報を（上記のオプションでＶＰＬＭＮが行うように）市場のＶＰＬＭＮと共有することができ、そこからＶＰＬＭＮは同時に最良のＳＧＷ−ＵおよびＰＧＷ−Ｕペアを選択することができる。ただし、これにより、ＨＰＬＭＮから複数のＶＰＬＭＮへの機密情報の何らかのブロードキャストが発生するため、ブロードキャストを実行するそのＨＰＬＭＮとの接続のセットアップに対する実際のＵＥ要求なしでブロードキャストされた情報は事前に必要なので、好適なソリューションとは見なされない。したがって、これは不均衡であるように思われる。

ＨＰＬＭＮが実行するＶＰＬＭＮリソースの選択は、ＶＰＬＭＮがＨＰＬＭＮ（４Ｇ）のリソースを選択する現在の既存の手順と一致しないことが知られている。

例えば、ＩＭＳのＢＧＷ機能を、ＥＰＣのＰＧＷ−Ｕ機能（またはＳＧＳＮ／ＧＧＳＮ−Ｕまたは５Ｇ対応ユニット）と１つの単一ノードに統合する場合、さらに最適化の可能性がある。現在、ＰＧＷ−ＵとＢＧＷは、明確に分離されたノード機能であり、それらは、２つの異なる機能としてカウントされ、個別に、さらには、例えば遅延に寄与する。低遅延および超低遅延の要件まで遅延を減らすと、これらの２つの機能を１つの結合された機能に集約することがますます魅力的になる。これは、２つではなく、１つのホップと１つのノードのみであるためである（遅延とジッターには、１回のみで、約半分しか寄与しない）。

上記の説明では、ユーザープレーンの遅延は通常ユーザーエクスペリエンスにとって最も重要であるため、ユーザープレーンの遅延とジッターが主に対処されている。ただし、対応する選択メカニズムをコントロールプレーンの遅延とコントロールプレーンのジッタに適用できる。図３は、本発明の実施形態による装置を示す。この装置は、ＵＥなどの端末、またはその要素であり得る。図４は、本発明の実施形態による方法を示す。図３による装置は、図４の方法を実行することができるが、この方法に限定されるものではない。図４の方法は、図３の装置によって実行され得るが、この装置によって実行されることに限定されるものではない。

この装置は、要求手段１０を含む。要求手段１０は、要求プロセッサであることができる。

要求プロセッサ１０は、ネットワークにサービスのリソースを要求する（Ｓ１０）。この要求には、サービスに対して満たされるリソースに対する要件を示す要件指標が含まれる。例えば、要件指標はＤＧＱであり得る。要件は、ＱｏＳ要件またはＳＬＡ要件、あるいはその両方であり得る。

図５は、本発明の一実施形態による装置を示す。この装置は、ＲＡＮ（ｅＮＢによって表される）またはその要素などのサービスのためのリソースを選択しないネットワーク機能であることができる。図６は、本発明の一実施形態による方法を示す。図５による装置は、図６の方法を実行しることができるが、この方法に限定されるものではない。図６の方法は、図５の装置によって実行され得るが、この装置によって実行されることに限定されるものではない。

この装置は、抽出手段１１０、決定手段１２０、および、請求手段１３０を含む。抽出手段１１０、決定手段１２０、および、請求手段１３０は、それぞれ抽出プロセッサ、決定プロセッサ、および、請求プロセッサであることができる。

抽出手段１１０は、受信したサービスの第１のリソースの要求から要件を抽出する（Ｓ１１０）。おの要求には要件指標が含まれ、要件指標はサービスに対して満たされる要件を示す。

決定手段１２０は、サービスの第１の部分が第１のリソースによって実行される場合の、要件に対する第１のリソースの寄与を決定する（Ｓ１２０）。請求手段１３０は、サービスの第２の部分を実行するための第２のリソースを請求（すなわち「要求」）する（Ｓ１３０）。請求（つまり、第２のリソースの要求）には、寄与指標が含まれる。寄与指標は、要件への許容可能な寄与、つまり、第２のリソースが要件に寄与できる度合いを示す。許容可能な寄与は、要件と第１のリソースの寄与とに基づいている。例えば、許容可能な寄与は、第１のリソースの要件と寄与のペアとして示されてもよいし、または、許容可能な寄与は、第１のリソースの要件と寄与に基づいて計算された計算許容可能寄与として示されてもよい。

加えて、装置（例えば、割り当て手段またはその割り当てプロセッサ）は、第１のリソースをサービスに割り当てることができる。

図７は、本発明の実施形態による装置を示す。この装置は、制御プレーン（例えば、ＭＭＥ）のノードまたはその要素などのサービスのためのリソースを選択するネットワーク機能であることができる。図８は、本発明の一実施形態による方法を示す。図７による装置は、図８の方法を実行することができるが、この方法に限定されるものではない。図８の方法は、図７の装置によって実行されることができるが、この装置によって実行されることに限定されるものではない。

この装置は、抽出手段２１０、決定手段２２０、選択手段２３０、および、割り当て手段２４０を含む。抽出手段２１０、決定手段２２０、選択手段２３０、および、割り当て手段２４０は、それぞれ、抽出プロセッサ、決定プロセッサ、選択プロセッサ、および、割り当てプロセッサであり得る。

抽出手段２１０は、受信したサービスのリソースの要求から要件を抽出する（Ｓ２１０）。この要求には要件指標が含まれ、要件指標はサービスに対して満たされる要件を示す。複数のリソースのそれぞれについて、決定手段２２０は、サービスの少なくとも第１の部分が、それぞれのリソースで実行される場合の要件に対するそれぞれの寄与を決定する（Ｓ２２０）。すなわち、サービスの少なくとも第１の部分がそれぞれのリソースで実行されるという仮定の下で、決定手段２２０は、それぞれのリソースによって引き起こされた要件への寄与を決定する。

選択手段２３０は、要件とそれぞれの寄与との間の不一致が所定の制限内になるように、すなわち、寄与が要件に適合するように、複数のリソースのうちの１つを選択する（Ｓ２３０）。そして、割り当て手段２４０は、選択されたリソースをサービスに割り当てる（Ｓ２４０）。

図９は、本発明の一実施形態による装置を示す。この装置は、制御プレーン（例えば、ＭＭＥ）のノードまたはその要素などのサービスのためのリソースを選択するネットワーク機能であり得る。図１０は、本発明の実施形態による方法を示す。図９による装置は、図１０の方法を実行することができる。しかし、この方法に限定されるものでない。図１０の方法は、図９の装置によって実行されることができる、しかし、この装置によって実行されることに限定されるものではない。

この装置は、第１の抽出手段３１０、招待手段３２０、第２の抽出手段３３０、決定手段３４０、選択手段３５０、および、割り当て手段３６０を備える。第１抽出手段３１０、招待手段３２０、第２抽出手段３３０、決定手段３４０、選択手段３５０、および、割り当て手段３６０は、それぞれ、第１抽出プロセッサ、招待プロセッサ、第２抽出プロセッサ、決定プロセッサ、選択プロセッサ、および割り当てプロセッサであり得る。

第１の抽出手段３１０は、受信したサービスの第１のリソースの要求から要件を抽出する（Ｓ３１０）。要求には要件指標が含まれ、要件指標はサービスに対して満たされる要件を示す。

招待手段３２０は、サービスの第２の部分を実行するために、サービスに第２のリソースを割り当てるように、選択デバイスを招待（すなわち、「要求」）する（Ｓ３２０）。この招待は、要件指標が含まれる。選択装置は、例えば、ＭＭＥまたは別の制御デバイスであり得る。

第２抽出手段３３０は、その招待に対する応答から第２寄与指標を抽出する（Ｓ３３０）。サービスの第２の部分が第２のリソースで実行される場合、第２の寄与指標は、第２のリソースの寄与を示す。決定手段３４０は、複数の第１のリソースのそれぞれについて、サービスの少なくとも第１の部分がそれぞれの第１のリソースで実行される場合の要件に対するそれぞれの第１の寄与を決定する（Ｓ３４０）。第１のリソースのそれぞれは、第２のリソースと異なっていてもよい。すなわち、第２のリソースは選択装置の制御下にあり、一方、第１のリソースは装置の制御下にあり得る。

選択手段３５０は、要件と、それぞれの第１の寄与および第２の寄与の合計との間の不一致が、所定の限度内になるように、複数の第１のリソースの１つを選択する（Ｓ３５０）。寄付の合計は、寄付の種類に応じて計算される。例えば。遅延が追加される場合があるが、一方、確率または確率の逆数（パケット損失など）が乗算される場合がある。合計２つの帯域幅が、２つの帯域幅の最小値になることがあり得る。

割り当て手段３６０は、選択された第１のリソースをサービスに割り当てる（Ｓ３６０）。典型的には、第１のリソースの選択機能（選択手段３５０）は、選択された第１のリソースに関する情報を第２のリソースの選択機能に送信して、割り当てられた第１および第２のリソースが互いに知り合い、ペイロードを交換できる（その他の各々と通信できる）ようにすることができる。

図１１は、本発明の実施形態による装置を示す。この装置は、少なくとも１つのプロセッサ６１０、コンピュータプログラムコードを含む少なくとも１つのメモリ６２０を備え、および、少なくとも１つのメモリ６２０およびコンピュータプログラムコードを備えた少なくとも１つのプロセッサ６１０は、この装置に、少なくとも。図４、６、８、および１０による方法の少なくとも１つを実行させるように構成される。

本発明の実施形態は、ＬＴＥまたはＬＴＥ−Ａなどの３ＧＰＰネットワーク、または５Ｇネットワークで採用されることができる。また、ＣＤＭＡ、ＥＤＧＥ、ＵＴＲＡＮネットワーク、ＷｉＦｉネットワークなど、他の無線または有線の通信ネットワークでも使用できる。

端末は、それぞれのネットワークにアクセスできる任意の装置であり得る。例えば、３ＧＰＰネットワークでは、端末は、ＵＥ、Ｍ２Ｍデバイス、コンピュータ／ノートブック、固定電話などであり得る。端末は、スマートフォン、ラップトップ、携帯電話などであり得る。

本発明のいくつかの実施形態を、ＵＥが全体的な要件を定義し、次に、例えば、ＲＡＮおよびコア（またはＶＰＬＭＮおよびＨＰＬＭＮなど）上での部分的な要件に分割されるところを説明する。ただし、そのコンセプトは、カスケード接続できる。例えば、ＶＰＬＭＮはＨＰＬＭＮに要件を提供することができ、この要件はＵＥからの全体的な要件とＶＰＬＭＮからの寄与の結果である。次に、ＨＰＬＭＮは、ＶＰＬＭＮから受信した要件を、ＨＰＬＭＮに接続されたＵＥから受信した全体的な要件と同じように、全体的な要件と見なす。

１つの情報が１つのエンティティから別のエンティティに１つ以上のメッセージで送信されることがあり得る。これらの各メッセージは、さらに（異なる）情報を含む場合がある。

ネットワーク要素、プロトコル、およびメソッドの名前は、現在の標準に基づいている。他のバージョンまたは他の技術では、対応する機能を提供する限り、これらのネットワーク要素および／またはプロトコルおよび／またはメソッドの名前は異なることがあり得る。

特に明記されていないか、文脈から明らかにされていない場合、２つのエンティティが異なるというステートメントは、それらが異なる機能を実行することを意味する。必ずしも、異なるハードウェアに基づいているという意味ではない。すなわち、本明細書で説明される各エンティティは、異なるハードウェアに基づいていることができ、または、エンティティの一部またはすべてが同じハードウェアに基づいていることもできる。必ずしも異なるソフトウェアに基づいているわけではない。すなわち、本明細書で説明される各エンティティは、異なるソフトウェアに基づいていることができ、または、エンティティの一部またはすべてが同じソフトウェアに基づいていることもできる。説明したエンティティの１つ以上をクラウドに実装できる。特に、記述されたエンティティのそれぞれは、ネットワークスライスとして実装されることができる。

上記の説明によれば、本発明の例示的な実施形態は、例えば、ユーザ機器またはそのコンポーネントなどの端末、それを具現化する装置、制御および／または操作方法、および、それを制御および／または操作するコンピュータープログラム、ならびにそのようなコンピュータープログラムを保持し、コンピュータープログラム製品を形成する媒体を提供することは明らかであるはずである。したがって、上記の説明によれば、本発明の例示的な実施形態は、例えば、基地局（例えば、ＮｏｄｅＢまたはｅＮｏｄｅＢ）などのアクセスノード、またはその構成要素、それを実施する装置、方法、および、それらを制御および／または操作するコンピュータープログラム、ならびに、そのようなコンピュータープログラムを運び、コンピュータープログラム製品を形成する媒体を提供することは明らかであるはずである。したがって、上記の説明によれば、本発明の例示的な実施形態が、例えば、ＭＭＥなどの制御装置／または動作方法またはその構成要素、それを具現化する装置、それを制御および／または操作する方法、および同じものを制御および／または操作するコンピュータープログラム、ならびにそのようなコンピュータープログラムを保持し、コンピュータープログラム製品を形成する媒体提供することは明らかであるはずである。

上記のブロック、装置、システム、技術または方法のいずれかの実装には、非限定的な例として、ハードウェア、ソフトウェア、ファームウェア、専用回路またはロジック、汎用ハードウェアまたはコントローラーまたは他のコンピューティングデバイス、または、それらの組み合わせを含む。それらは、完全にまたは部分的にクラウドに実装することができる。

上述したことは、現在本発明の好ましい実施形態と考えられているものであることが理解されるべきである。しかしながら、好適な実施形態の説明は、例としてのみ与えられ、添付の特許請求の範囲によって定義される本発明の範囲から逸脱することなく様々な修正を行うことができることに留意する。

Claims (34)

1. 少なくとも１つのプロセッサと、コンピュータプログラムコードを含む少なくとも１つのメモリと、を備える装置であって、該少なくとも１つのプロセッサは、該少なくとも１つのメモリおよび該コンピュータプログラムコードを用いて、該装置に、ネットワークからのサービスのためのリソースを要求するステップであって、該要求は、該サービスのために満たされるべきリソースへの要件を示す要件指標を含む、ステップを少なくとも実行させるように構成させる、装置。
2. 少なくとも１つのプロセッサと、コンピュータプログラムコードを含む少なくとも１つのメモリと、少なくとも１つのメモリとコンピュータプログラムコードを備えた少なくとも１つのプロセッサとを備える装置であって、該コンピュータプログラムコードは、該装置に、少なくとも、サービスの第１のリソースに対する受信された要求から要件を抽出するステップであって、該要求は要件指標を含み、該要件指標はサービスのために満たされるべき要件を示す、ステップと、前記サービスの第１の部分が第１のリソースで実行される場合の前記要件に対する第１のリソースの寄与を決定するステップと、前記サービスの第２の部分を実行するための第２のリソースを請求するステップであって、該請求することは、寄与指標を含み、該寄与指標は要件に対する許容可能な寄与を示し、該許容可能な寄与は、前記要件および前記第１のリソースの前記寄与に基づく、ステップと、を実行させるように構成される、装置。
3. 前記少なくとも１つのメモリおよび前記コンピュータプログラムコードは、前記装置に、前記サービスのための複数の第１のリソースのそれぞれについて、前記サービスの前記第１の部分がそれぞれの前記第１のリソースの上で実行される場合の要件に対する、それぞれの前記第１のリソースの前記第１のリソースのそれぞれの寄与を決定するステップをさらに実行させるように構成され、ここで、前記第２のリソースを請求するステップは、前記複数の第１のリソースのそれぞれの第１のリソースの識別、および、それぞれの寄与指標をそれぞれが含む１つ以上の寄与インジケータペアを含み、前記寄与指標の各々は、前記要件およびそれぞれの前記第１のリソースの前記寄与に基づく、請求項２に記載の装置。
4. 前記少なくとも１つのメモリおよび前記コンピュータプログラムコードは、前記サービスの前記要件をそれぞれの前記第１のリソースにより満たすことができるか否かを、それぞれの前記寄与に基づいて、前記複数の第１のリソースの各々についてチェックするステップと、前記第１のリソースの各々に対して、前記サービスの前記要件をそれぞれの前記第１のリソースにより満たすことができない場合、前記第２のリソースの請求が、それぞれの前記第１のリソースの識別を含む寄与インジケータペアを含むことを禁止するステップとをさらに実行させるように構成される、請求項３に記載の装置。
5. 前記少なくとも１つのメモリおよび前記コンピュータプログラムコードは、さらに、前記装置に、前記第２のリソースを請求する受信応答が前記リソースのうちの選択された１つの前記識別を含むかどうかを監視するステップと、前記応答が前記第１のリソースのうちの前記選択された１つの前記識別を含む場合、前記第１のリソースのうちの前記選択された１つを前記サービスに割り当てるステップとを実行させるように構成される、請求項３または４に記載の装置。
6. 前記許容寄与のうちの少なくとも１つは、前記第１のリソースの前記要件および前記寄与によって前記寄与指標において示され、前記少なくとも１つのメモリおよび前記コンピュータプログラムコードは、前記装置に、前記第１のリソースの前記要件および前記寄与に基づいて前記許容寄与を計算するステップをさらに実行させるように構成され、前記寄与指標は、前記計算された許容寄与を含む、請求項２から５のいずれか１項に記載の装置。
7. 前記少なくとも１つのメモリおよび前記コンピュータプログラムコードは、前記装置に、前記第１のリソースの前記寄与が前記要件を満たすことを可能にするかどうかのチェックするステップと、前記第１のリソースの前記寄与により前記要件を満たすことができる場合、前記第１のリソースを前記サービスに割り当てるステップとをさらに実行させる、請求項２ないし６のいずれか１項に記載の装置。
8. 前記少なくとも１つのメモリおよび前記コンピュータプログラムコードは、前記第１のリソースの寄与が前記要件を満たすことを可能にしない場合、前記第１のリソースの前記要求に応じて、発信不可能性指標を提供するステップをさらに実行させるように構成される、請求項７に記載の装置。
9. 前記少なくとも１つのメモリおよび前記コンピュータプログラムコードは、前記装置に、前記第２のリソースを請求することに応答して、到着する不可能指標が受信されたかどうかを監視するステップであって、前記到着不可能指標は、前記第２のリソースが許容可能な寄与を超えていることを示す、ステップと、前記サービスの第２の部分が前記第３のリソースの上で実行される場合の前記要件に対する第３のリソースの寄与を決定するステップと、前記第３のリソースの寄与が許容可能な前記寄与を超えているかどうかをチェックするステップと、第３のリソースの寄与が許容可能な寄与を超えておらず、着信不可能性指標を受信した場合、前記第３のリソースを前記サービスに割り当てるステップと、を更に実行させるように構成される、請求項２ないし８のいずれか１項に記載の装置。
10. 少なくとも１つのプロセッサと、コンピュータプログラムコードを含む少なくとも１つのメモリとを備える装置であって、該少なくとも１つのプロセッサは、該少なくとも１つのメモリと該コンピュータプログラムコードを用いて、該装置に、少なくとも、サービスの第１のリソースに対する受信された要求からの要求を抽出するステップであって、前記要求は要件指標を含み、該要件指標は、前記サービスのために満たされるべき要件を示す、ステップと、複数の第１のリソースのそれぞれについて、前記サービスの少なくとも第１の部分が、前記それぞれの第１のリソース上で実行される場合の前記要件に対するそれぞれの第１の寄与を決定するステップと、前記要件と前記それぞれの第１の寄与との間の不一致が、所定の制限内にあるように、前記複数の第１のリソースのうちの１つを選択するステップと、前記選択した第１のリソースをサービスに割り当てるステップと、を実行させるように構成されている、装置。
11. 前記要件指標は、全体要件指標および寄与指標を含み、前記全体要件指標は、前記サービスの全体要件を示し、前記寄与指標は、第２のリソースがサービスの第２の部分を実行する場合、該第２のリソースによって引き起こされる前記全体要件に対する第２の寄与を示し、前記少なくとも１つのメモリおよび前記コンピュータプログラムコードは、前記装置に、前記要求指標から前記全体的な要求の抽出することと、前記要件指標から前記第２の寄与を抽出することとをさらに実行させるように構成され、前記複数の第１のリソースのうちの前記１つは、全体の要件と、前記第２の寄与および前記それぞれの第１の寄与の合計との間の不一致が、前記所定の制限内にあるように選択される、請求項１０に記載の装置。
12. 前記要件は、前記サービスの前記全体要件および複数の第２の寄与インジケータを含み、前記第２の寄与インジケータのそれぞれは、それぞれの第２のリソースの識別、および、前記第２のリソースが前記サービスの前記第２の部分を実行する場合、前記それぞれの第２のリソースによって引き起こされる前記全体的な要件へのそれぞれの第２の寄与を示すそれぞれの第２の寄与指標を含み、前記少なくとも１つのメモリおよび前記コンピュータプログラムコードは、前記装置に、前記寄与インジケータペアのそれぞれについて、前記それぞれの識別および前記それぞれの第２の寄与を抽出するステップと、第１の寄与のそれぞれ１つと第２の寄与のそれぞれ１つとの１つ以上の寄与ペアのそれぞれの合計寄与を決定するステップと、全体の寄与とそれぞれの合計の寄与の間の不一致が所定の制限内にあるように前記寄与するペアの１つを選択するステップと、第１のリソースの選択された第１のリソースを決定するステップであって、該選択された第１のリソースは、前記選択された寄与ペアの前記それぞれの第１の寄与に寄与する、ステップと、選択された第２のリソースの識別を決定するステップであって、前記それぞれの第２の寄与インジケータにしたがって、該選択された第２のリソースは、前記選択された寄与ペアの前記それぞれの第２の寄与に寄与する、ステップと、前記選択した第１のリソースを前記サービスに割り当てるステップと、選択された第１のリソースおよび選択された第２のリソースの識別についてデバイスに通知するステップであって、前記要求は前記デバイスから受信される、ステップと、を更に実行させるように構成される、請求項１１に記載の装置。
13. 少なくとも１つのプロセッサと、コンピュータプログラムコードを含む少なくとも１つのメモリと、を備えた装置であって、該少なくとも１つのプロセッサは、該少なくとも１つのメモリと該コンピュータプログラムコードとを用いて、該装置に、少なくとも、サービスの第１のリソースに対する受信した要求から要件を抽出するステップであって、該要求には要件指標が含まれ、該要件指標は、該サービスに対して満たされるべき要件を示す、ステップと、サービスの第２の部分を実行するためにサービスに第２のリソースを割り当てるように選択装置を招待するステップであって、該招待は該要件指標を含む、ステップと、前記招待に対する応答から第２の寄与指標を抽出するステップであって、前記サービスの前記第２の部分が前記第２のリソースの上で実行される場合、該第２の寄与指標は、前記第２のリソースの寄与を示す、ステップと、複数の第１のリソースのそれぞれについて、前記サービスの少なくとも第１の部分が、前記それぞれの第１のリソースで実行される場合の要件に対するそれぞれの第１の寄与を決定するステップと、前記要件と、前記それぞれの第１の寄与および前記第２の寄与の合計との間の不一致が、所定の制限内にあるように、複数の第１のリソースの１つを選択するステップと、前記選択した第１のリソースを前記サービスに割り当るステップと、を実行させるように構成されている、装置。
14. 前記少なくとも１つのメモリおよび前記コンピュータプログラムコードは、前記装置に、受信した要求に応答して、前記選択された第１のリソースの識別および前記選択された第１のリソースの前記第１の寄与を提供するステップをさらに実行させるように構成される、請求項１０に記載の装置。
15. 前記少なくとも１つのメモリおよび前記コンピュータプログラムコードは、前記装置に、更に、前記選択された第１のリソースの前記第１の寄与に関する情報を、サービスの処理に関連する課金記録に追加するステップを実行させるように構成される、請求項１０ないし１４のいずれか１項に記載の装置。
16. 前記要件は、レイテンシ、ジッタ、帯域幅、パケット損失率、エラー率、リソースタイプ、優先度、信頼性、および、前記レイテンシ、前記ジッタ、前記帯域幅、前記パケット損失率、前記エラー率、前記リソースタイプ、前記優先度、前記信頼性のうちの少なくとも２つに基づく組み合わせパラメータの少なくとも１つである、請求項１ないし１５のいずれか１項に記載の装置。
17. ネットワークからサービスのためのリソースを要求するステップであって、該要求は、該サービスのために満たされるリソースに対する要件を示す要件指標を含む、ステップを含む方法。
18. サービスの第１のリソースに対する受信された要求から要件を抽出するステップであって、該要求は要件指標を含み、該要件指標は、サービスのために満たされるべき要件を示す、ステップと、前記サービスの第１の部分が前記第１のリソースの上で実行される場合の前記要件に対する前記第１のリソースの寄与を決定するステップと、前記サービスの第２の部分を実行するための第２のリソースを請求するステップであって、該請求することは、寄与指標を含み、該寄与指標は前記要件に対する許容可能な寄与を示し、該許容可能な寄与は、前記要件および前記第１のリソースの前記寄与に基づく、ステップと、を含む方法。
19. 前記サービスの複数の第１のリソースのそれぞれについて、前記サービスの前記第１の部分が前記それぞれの第１のリソースの上で実行される場合の、前記要件に対する前記それぞれの第１のリソースのそれぞれの寄与を決定するステップをさらに含み、前記第２のリソースを請求する前記ステップは、前記複数の第１のリソースのそれぞれの第１のリソースの識別、および、それぞれの寄与指標をそれぞれが含む１つ以上の寄与インジケータペアを含み、前記寄与指標の各々は、前記それぞれの第１のリソースの前記要件および前記寄与に基づく、請求項１８に記載の方法。
20. 複数の第１のリソースの各々について、前記それぞれの寄与に基づいて、前記サービスの前記要件が、前記それぞれの第１のリソースによって満たされることができるかどうかをチェックするステップと、前記複数の第１のリソースの各々について、前記サービスの前記要件が前記それぞれの第１のリソースによって満たされることができない場合、前記第２のリソースを請求することが、前記それぞれの第１のリソースの識別を含む前記寄与インジケータペアを含むことを禁止するステップと、をさらに含む、請求項１９に記載の方法。
21. 前記第２のリソースを請求する受信応答が前記リソースのうちの選択された１つの前記識別を含むかどうかを監視するステップと、前記応答が前記第１のリソースのうちの前記選択された１つの前記識別を含む場合、前記第１のリソースのうちの前記選択された１つを前記サービスに割り当てるステップとをさらに含む、請求項１９または２０に記載の方法。
22. 前記許容寄与のうちの少なくとも１つは、前記第１のリソースの前記要求および前記寄与によって前記寄与指標において示され、前記方法は、前記第１のリソースの前記要件および前記寄与に基づいて前記許容寄与を計算するステップを更に含み、前記寄与指標は、前記計算された許容寄与を含む、請求項１８ないし２１のいずれか１項に記載の方法。
23. 前記第１のリソースの前記寄与により前記要件を満たすことができるか否かをチェックするステップと、前記第１のリソースの前記寄与により前記要件を満たすことができる場合、前記第１のリソースを前記サービスに割り当てるステップとをさらに含む、請求項１８ないし２２のいずれか１項に記載の方法。
24. 第１のリソースの寄与が要件を満たすことを許可しない場合、第１のリソースの要求に応じて発信不可能性指標を提供するステップをさらに含む、請求項２３に記載の方法。
25. 前記第２のリソースの請求に応じて、着信不可能性指標が受信されたか否かを監視するステップであって、前記到着不可能指標は、前記第２のリソースが前記許容可能な寄与を超えていることを示す、ステップと、前記サービスの前記第２の部分が、前記第３のリソースの上で実行される場合の前記要件に対する第３のリソースの寄与を決定するステップと、前記第３のリソースの前記寄与が前記許容可能な寄与を超えているかどうかをチェックするステップと、前記第３のリソースの前記寄与が前記許容可能な寄与を超えておらず、前記着信不可能性指標が受信された場合、前記第３のリソースを前記サービスに割り当てるステップと、をさらに含む、請求項１８ないし２４のいずれか１項に記載の方法。
26. サービスのための第１のリソースに対する受信された要求から要件を抽出するステップであって、前記要求は要件指標を含み、該要件指標は前記サービスに対して満たされるべき要件を示す、ステップと、第１のリソースの各々について、前記サービスの少なくとも第１の部分が前記それぞれの第１のリソースの上で実行される場合の前記要件に対するそれぞれの第１の寄与を決定するステップと、前記要件と、前記それぞれの第１の寄与との間の不一致が、所定の制限内にあるように、前記複数の第１のリソースのうちの１つを選択するステップと、前記選択した第１のリソースを前記サービスに割り当てるステップと、を含む方法。
27. 前記要件指標は、全体要件指標および寄与指標を含み、前記全体要件指標は、前記サービスの全体要件を示し、前記寄与指標は、前記第２のリソースが前記サービスの前記第２の部分を実行する場合、第２のリソースによって引き起こされる前記全体要件に対する第２の寄与を示し、前記方法は、前記要件指標から前記全体的な要件を抽出するステップと、前記要件指標から前記第２の寄与を抽出するステップとを更に含み、前記複数の第１のリソースのうちの１つは、前記全体的な要件と、前記第２の寄与および前記それぞれの第１の寄与の合計との間の不一致が、所定の制限内にあるように選択される、請求項２６に記載の方法。
28. 前記要件は、前記サービスの前記全体的要件および複数の第２の寄与インジケータを含み、前記第２の寄与インジケータの各々は、それぞれの第２のリソースの識別と、前記第２のリソースが前記サービスの前記第２の部分を実行する場合、それぞれの第２のリソースによって引き起こされる前記全体的な要件に対するそれぞれの第２の寄与を示すそれぞれの第２の寄与指標とを含み、前記方法は、寄与インジケータペアのそれぞれについて、それぞれの識別およびそれぞれの第２の寄与を抽出するステップと、第１の寄与のそれぞれ１つと、第２の寄与のそれぞれ１つとの１つ以上の寄与ペアのそれぞれの合計寄与を決定するステップと、全体の寄与とそれぞれの合計の寄与との間の不一致が所定の制限内にあるように、寄与するペアの１つを選択するステップと、第１のリソースの選択された第１のリソースを決定するステップであって、選択された第１のリソースは、選択された寄与ペアのそれぞれの第１の寄与に寄与する、ステップと、選択された第２のリソースの識別を決定するステップであって、それぞれの第２の寄与インジケータにしたがって、該選択された第２のリソースは、前記選択された寄与ペアの前記それぞれの第２の寄与に寄与する、ステップと、選択した第１のリソースをサービスに割り当てるステップと、選択された第１のリソースおよび選択された第２のリソースの識別についてデバイスに通知するステップであって、前記要求は前記デバイスから受信される、ステップと、を更に含む、請求項２７に記載の方法。
29. サービスのための第１のリソースに対する受信された要求から要求を少なくとも抽出するステップであって、前記要求は要件指標を含み、該要件指標は前記サービスに対して満たされるべき要件を示す、ステップと、サービスの第２の部分を実行するためにサービスに第２のリソースを割り当てるように選択装置を招待するステップであって、該招待は該要件指標を含む、ステップと、前記招待に対する応答から第２の寄与指標を抽出するステップであって、前記サービスの前記第２の部分が前記第２のリソースの上で実行される場合、該第２の寄与指標は、前記第２のリソースの寄与を示す、ステップと、第１のリソースの各々について、前記サービスの少なくとも第１の部分が前記それぞれの第１のリソースの上で実行される場合の前記要件に対するそれぞれの第１の寄与を決定するステップを含む方法。前記要件と、前記それぞれの第１の寄与および前記第２の寄与の合計との間の不一致が、所定の制限内にあるように、複数の第１のリソースの１つを選択するステップと、前記選択した第１のリソースを前記サービスに割り当てるステップと、請求項２７に記載の方法。
30. 前記受信された要求に応答して、前記選択された第１のリソースの識別および前記選択された第１のリソースの第１の寄与を提供するステップをさらに含む請求項２６ないし２９のいずれか１項に記載の方法。
31. 前記選択された第１のリソースの前記第１の寄与に関する情報を、前記サービスの処理に関連する課金記録に追加するステップをさらに含む、請求項２６から３０のいずれかに記載の方法。
32. 前記要件は、レイテンシ、ジッタ、帯域幅、パケット損失率、エラー率、リソースタイプ、優先度、信頼性、および、該レイテンシ、該ジッタ、該帯域幅、該パケット損失率、該エラー率、該リソースタイプ、該優先度、該信頼性の少なくとも２つに基づくパラメータのうちの少なくとも１つである、請求項１７ないし３１のいずれか１項に記載の方法。
33. 装置上で実行されると、該装置に、請求項１７ないし３２のいずれか１項に記載の方法を実行させるように構成される命令のセットを備えるコンピュータプログラム製品。
34. コンピュータ可読媒体として具現化されるか、またはコンピュータに直接ロード可能な、請求項３３に記載のコンピュータプログラム製品。