JP7077985B2 - リソース競合調停装置、リソース競合調停方法、及びプログラム - Google Patents

Description

本発明は、通信サービスを利用するデバイスに対してポリシールールを適用するための技術に関連するものである。

これまで固定網／移動体網単独で提供していたサービスについて、他事業者やエンドユーザへＡＰＩを開放し、ＡＰＩ経由で更に柔軟かつリアルタイムにサービスを提供・変更することに対する需要が高まっている。

従来、固定網ＢＰＣＦ／移動体網ＰＣＲＦ単独で適用ポリシーを判定することができていたが、今後は、上記の需要に応えるために、ＡＰＩ経由で他事業者から指定されるポリシーとの競合を考慮する必要がある。他事業者網とのＳ９ａ連携（３ＧＰＰ規定）についても、同様の考慮が必要である。

図１（ａ）～（ｄ）は、ポリシー連携モデルの例を示している。図１（ａ）は、他の事業者と固定網のＡＰＩ経由のポリシー連携モデルの例を示し、図１（ｂ）は、エンドユーザと固定網のＡＰＩ経由のポリシー連携モデルの例を示し、図１（ｃ）は、他の事業者と移動体網のＡＰＩ経由のポリシー連携モデルの例を示し、図１（ｄ）は、固定網と移動体網のポリシー連携モデルの例を示している。

さて、近年、ネットワークカメラやテレビ等、ネットワークに接続されるＩｏＴデバイスが多様化している。特に、５Ｇ／ＩｏＴ時代には、ＮＷにつながるＩｏＴデバイスが多様化（カメラ、センサ、等）し、デバイス毎に求められるポリシーも多様化すると想定される（例：監視カメラの映像を優先制御）。

特開２００３－２６４５８６号公報

５Ｇ／ＩｏＴ時代を見据えたキャリアネットワークでは、これらのＩｏＴデバイスに対し、（１）自ＮＷからのポリシー適用、（２）ユーザからのＡＰＩ経由のポリシー適用、（３）他事業者からのＡＰＩ経由のポリシー適用、が競合するおそれがある。図２は、このような競合の例を示している。図２の例では、自ＮＷは、ＰＣＲＦ１０等を備える移動体網である。図２に示すように、ＩｏＴ－ＧＷ＃１において、ユーザ３０から指示されるポリシー（Ｒｕｌｅ＃２）と、自ＮＷより指示されるポリシー（Ｒｕｌｅ＃１）と、他事業者から指示されるポリシー（Ｒｕｌｅ＃３）が競合する。競合とは、より具体的には通信のリソースである帯域が競合することである。

しかし、上記のようなリソースの競合を調停するための技術はこれまでに提案されていない。

本発明は上記の点に鑑みてなされたものであり、通信サービスを利用するデバイスに対するリソースの競合を調停することを可能とする技術を提供することを目的とする。

開示の技術によれば、リソースの競合を調停するリソース競合調停装置であって、
１つ又は複数のデバイスのうちのあるデバイスに対するリソース割当要求を受信する受信手段と、
前記リソース割当要求で要求されたリソースを前記デバイスに割り当てるとした場合に、前記１つ又は複数のデバイスに割り当てられるリソースの合計値が、使用可能なリソースの上限値を超えるか否かを判定する判定手段と、
前記判定手段により、前記合計値が前記上限値を超えると判定された場合に、前記１つ又は複数のデバイスに割り当てられるリソースの合計値が前記上限値を超えないという制約条件の下で、各デバイスに対するリソース割当の優先度の和が最大になるように各デバイスに対するリソース割当可否を決定する計算手段とを備え、
前記リソースは通信帯域であり、前記リソース割当要求は、ＡＰＩ経由で適用を指示されたポリシールールである
リソース競合調停装置が提供される。

開示の技術によれば、通信サービスを利用するデバイスに対するリソースの競合を調停することができる。

ポリシー連携モデルの例を示す図である。 ＩｏＴデバイス毎のポリシー連携を示す図である。 ポリシー管理・制御方式の例を示す図である。 課題を説明するための図である。 課題を説明するための図である。 本発明の実施の形態の概要を説明するための図である。 本発明の実施の形態の概要を説明するための図である。 本発明の実施の形態の概要を説明するための図である。 本発明の実施の形態の形態におけるシステム構成図である。 デバイス毎の割当帯域の最適化問題を示す図である。 本発明の実施の形態の形態におけるシステム構成図である。 ＰＣＲＦの構成図である。 装置のハードウェア構成例を示す図である。 システムの動作例を説明するためのシーケンス図である。 システムの動作例を説明するためのシーケンス図である。 具体例を説明するための図である。 具体例を説明するための図である。 具体例を説明するための図である。 具体例を説明するための図である。

以下、図面を参照して本発明の実施の形態（本実施の形態）を説明する。以下で説明する実施の形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施の形態に限られるわけではない。

例えば、以下の例では、本発明の動作をＰＣＲＦが実行するが、本発明はＰＣＲＦ以外の装置にも適用可能である。また、以下の例では、調停するリソースが通信の帯域であるが、本発明は帯域に限らないリソースの調停に適用できる。以下ではまず、課題に関する動作等を説明し、その後に本発明に係る技術を説明する。

（課題について）
図３を参照して、一般的なポリシー管理・制御方式を説明する。図３に示すシステム構成は、図２と同様であり、自ＮＷ（自事業者）はＰＣＲＦ１０、ＰＣＥＦ２０を含む移動体網である。なお、ＰＣＲＦ（Policy and Charging Rule Function）は、ポリシー情報を管理するノードであり、ＰＣＥＦ（Policy and Charging Enforcement Function）は、ポリシー制御を実行するノードである。ＰＣＥＦはＰ－ＧＷに含まれる場合が多い。

当該自ＮＷに、種々のデバイスを収容するＩｏＴ－ＧＷ５０（ユーザの装置）が接続されている。また、当該自ＮＷに、ユーザ３０（具体的にはユーザ端末等）と他事業者４０（他事業者のネットワークに接続された装置等）がそれぞれＡＰＩを介して接続されている。図３に示す例では、ＩｏＴ－ＧＷ５０と自ＮＷとの間の回線（具体的にはＶＬＡＮ等）の契約帯域は１００Ｍｂｐｓである。つまり、使用可能な帯域の上限値が１００Ｍｂｐｓである。

また、ＰＣＲＦ１０からＰＣＥＦ２０に対し、Ｄｙｎａｍｉｃにポリシー適用を指示することができるとともに、ＡＰＩ経由でユーザ３０及び他事業者４０からＰＣＥＦ２０に対してポリシー適用を指示することができる。

図３に示す例では、ユーザ３０から、デバイス＃２に対する５０Ｍｂｐｓ保証（優先度高）のポリシー適用が指示され、他事業者４０から、デバイス＃３に対する５０Ｍｂｐｓ保証（優先度高）のポリシー適用が指示され、自ＮＷ（ＰＣＲＦ１０）から、デバイス＃１に対する５０Ｍｂｐｓ保証（優先度高）のポリシー適用が指示されている。なお、ポリシーの内容を「ルール」と呼ぶ。この「ルール」を「ポリシールール」と呼んでもよい。

上記のポリシーで指示された優先度高の帯域を合計すると１５０Ｍｂｐｓになる、すなわち、自ＰＣＲＦとＡＰＩ経由の優先度高のルールを適用すると、保証帯域の合計が契約帯域を超過してしまう。つまり、リソース競合が発生する。

このリソース競合をＰＣＲＦ１０で適切に調停する必要があるが、従来技術では、ＡＰＩからのポリシー適用指示がされた場合の競合を調停する仕組みがなく、調停を行うことができない。

課題が生じる他の例を図４、図５に示す。図４は、図５との比較のために示したものであり、自ＮＷのＰＣＲＦ１０からポリシー制御を行う場合を示したものである。図４に示すように、自ＮＷのＰＣＲＦ１０から、ＩｏＴ－ＧＷ＃１配下のデバイス＃１～デバイス＃３、及びＩｏＴ－ＧＷ＃２配下のデバイス＃４～デバイス＃６へのポリシー適用の指示が行われている。図４に示すように、ＩｏＴ－ＧＷ＃１、ＩｏＴ－ＧＷ＃２のいずれについても、優先転送の割当帯域は、契約帯域以下になっている。

図５は、ＡＰＩ経由で他事業者（ここではＩｏＴ事業者６０）からポリシー制御を行う場合の例を示している。図５に示すように、ＩｏＴ事業者６０から、ＩｏＴ－ＧＷ＃１配下のデバイス＃１～デバイス＃３、及びＩｏＴ－ＧＷ＃２配下のデバイス＃４～デバイス＃６へのポリシー適用の指示が行われている。図５に示すように、ＩｏＴ－ＧＷ＃１における優先転送の割当帯域は計１１０Ｍｂｐｓとなり契約帯域を超過している。

このように、従来技術では、ＡＰＩ経由で他事業者（ここではＩｏＴ事業者６０）からポリシー制御を行う場合において、（１ＶＬＡＮ配下のデバイスに対する要求帯域の合計帯域）＞（１ＶＬＡＮの割当帯域）となる場合を検出することができない。

以下、上記の課題を解決して、リソース競合をＰＣＲＦで適切に調停し、デバイスに対するルールの適用を最適化することを可能とする技術を、本発明の実施の形態として説明する。

（実施の形態の概要）
本実施の形態におけるシステム構成は、例えば図２に示したシステム構成である。ただし、ＰＣＲＦは本発明に係る機能を含む。以降、従来の「ＰＣＲＦ１０」と本発明の機能を含むＰＣＲＦとを区別するために、本発明の機能を含むＰＣＲＦを「ＰＣＲＦ１００」と記載する。なお、ＰＣＲＦ１００は、リソースの競合を調停する機能を持つので、ＰＣＲＦ１００をリソース競合調停装置と呼んでもよい。

本実施の形態では、ＰＣＲＦ１００から各デバイスに対し、割当帯域に関するポリシー適用を指示する過程をオンライン０－１ナップサック問題と捉え、ＰＣＲＦ１００において、分枝限定法によりポリシールール適用の調停を実施する。

ここで、一例として、１デバイスに１ルールを適用する場合を考え、契約帯域をｂ、ルール適用を指示する対象となるデバイス数をｎとし、デバイスｉに対するルールの適用指示は優先度ｐ_ｉ（優先度の基準は統一されている前提）で帯域幅ｃ_ｉを使用することを指示するものであるとする。このような前提の下、ＰＣＲＦ１００は、契約帯域内で各デバイス毎の適用ルールの優先度の和を最大化するルールの選び方に関する問題を解く。

ここで、オンラインナップサック問題について説明する。図６に示すように、オンラインナップサック問題とは、容量ｂのナップサックが１つと、ｎ種類の品物（各々価値ｐ_ｉ、容積ｃ_ｉ）が与えられたとき、ナップサックの容量を超えない範囲で入れた品物の価値の和を最大化する品物の選び方に関する問題である。

オンラインナップサック問題を、本実施の形態におけるデバイス毎の割当帯域のオンライン最適化問題に適用したものを図７に示す。本実施の形態におけるデバイス毎の割当帯域のオンライン最適化問題は、契約帯域幅ｂの契約回線が１つと、ｎ個のデバイス（各々適用ルールの優先度ｐ_ｉ、割当帯域幅ｃ_ｉ）が与えられたとき、契約回線の契約帯域幅を超えない範囲で適用したデバイス毎の適用ルールの優先度の和を最大化するデバイス毎のルールの選び方に関する問題になる。

特に、本実施の形態では、図８に示すように、ｎ個のデバイスに対してルールが適用されていて、更に、ＡＰＩ経由でルールの適用指示があり、そこで競合が発生するような場合の問題を想定している。

（システム構成）
図９は、本実施の形態におけるシステム構成の例を示している。図９に示すように、移動体網（自ＮＷ）には、ＰＣＥＦ２０、及び本発明に係る機能を持つＰＣＲＦ１００が備えられている。また、自ＮＷには、ＩｏＴ－ＧＷ５０が接続され、ＩｏＴ－ＧＷ５０の配下にはデバイス＃１～＃ｉが接続されている。自ＮＷのＰＣＲＦ１００からポリシールールの適用を各デバイスに指示することができるとともに、ユーザ３０及び他事業者４０のそれぞれは、ＡＰＩを介して、ポリシールール適用をＰＣＲＦ１００を経由して各デバイスに指示することができる。

（基本動作）
ＰＣＲＦ１００は、上述した最適化問題を解くことで、デバイス毎に最適なポリシールールの適用を決定する。

具体的には、１デバイスに１ルールを適用する場合において、デバイスｉに対し、ルールを適用する時はｘ_ｉ＝１、ルールを適用しない時はｘ_ｉ＝０とし、契約帯域をｂ、ルール適用を指示する対象となるデバイス数をｎとし、デバイスｉについての各ルールの適用に関して、その優先度をｐ_ｉとし、当該ルールで指示される割当帯域幅をｃ_ｉとし、アプリケーション等の用途に応じた定数をｙ_ｉとする。図１０に、これらのパラメータが示されている。ｙ_ｉはアプリケーション毎に予め定めておく定数である。なお、ｙ_ｉを使用しないこととしてもよい。

ＰＣＲＦ１００は、契約帯域内で各デバイスの適用ルールの優先度の和を最大化するために、目的関数ｚ＝Σ^ｎ _ｉ＝１（ｐ_ｉｘ_ｉ＋ｙ_ｉ）（制約条件Σ^ｎ _ｉ＝１ｃ_ｉｘ_ｉ＜ｂ、ｘ_ｉ∈｛０，１｝、－１≦ｙ_ｉ≦１（ｉ＝１，２，・・・，ｎ）、ｐ_ｉ≧０、ｃ_ｉ≧０、∀ｉ∈ｎ））を最大化するｘ_ｉの値を決定する。

図１１に示すように、１デバイスに複数ルールを適用する場合にも同様である。この場合、１デバイスとしてデバイス＃１に着目する。デバイス＃１に対し、ルールｉを適用する時はｘ_ｉ＝１、ルールｉを適用しない時はｘ_ｉ＝０とし、契約帯域をｂ、ルール数をｎとし、各ルールｉに関して、その優先度をｐ_ｉとし、当該ルールｉで指示される割当帯域幅をｃ_ｉとし、アプリケーション等の用途に応じた定数をｙ_ｉとする。

ＰＣＲＦ１００は、契約帯域内でルールの優先度の和を最大化するために、目的関数ｚ＝Σ^ｎ _ｉ＝１（ｐ_ｉｘ_ｉ＋ｙ_ｉ）（制約条件Σ^ｎ _ｉ＝１ｃ_ｉｘ_ｉ＜ｂ、ｘ_ｉ∈｛０，１｝、－１≦ｙ_ｉ≦１（ｉ＝１，２，・・・，ｎ）、ｐ_ｉ≧０、ｃ_ｉ≧０、∀ｉ∈ｎ））を最大化するｘ_ｉの値を決定する。

なお、ＰＣＲＦ１００は、上記の０－１ナップサック問題を分枝限定法を用いて解くことができる。また、ＰＣＲＦ１００は、緩和問題の利用等により、効率的に上記の０－１ナップサック問題を解くことができる。なお、上記最適化問題を解くこと自体については、種々の既存技術を使用することができる。

（装置構成例）
図１２に、ＰＣＲＦ１００の機能構成例を示す。図１２に示すように、ＰＣＲＦ１００は、入力部１１０、判定部１２０、最適ルール適用計算部１３０、出力部１４０、及び記憶部１５０を有する。

入力部１１０は、外部（自ＮＷのオペレーションシステム、ＡＰＩ経由での他事業者／ユーザ等）からルールの適用指示を受信し、ＰＣＲＦ１００の内部に入力する。判定部１２０は、入力されたルールを適用した場合に、デバイスへの割当帯域の合計が回線の契約帯域を超えるかどうかの判定を行う。

最適ルール適用計算部１３０は、判定部１２０により、デバイスへの割当帯域の合計が回線の契約帯域を超えると判断された場合、つまり、リソース競合が発生すると判断された場合に、前述した最適化問題を解くことで、各デバイスへの最適なルールの適用を計算する。

出力部１４０は、最適なルールの適用指示をＰＣＥＦ２０に対して行う。また、出力部１４０は、ＡＰＩ経由で受けたルール適用指示について、その適用可否（適用したか否か）を指示元に通知する。

記憶部１５０は、各デバイスに対して指示されたルール、及びそのルールの適用有無等を管理するテーブルを格納している。

ＰＣＲＦ１００は、例えば、コンピュータに、本実施の形態で説明する処理内容を記述したプログラムを実行させることにより実現可能である。

ＰＣＲＦ１００は、コンピュータに内蔵されるＣＰＵやメモリ等のハードウェア資源を用いて、当該ＰＣＲＦ１００で実施される処理に対応するプログラムを実行することによって実現することが可能である。上記プログラムは、コンピュータが読み取り可能な記録媒体（可搬メモリ等）に記録して、保存したり、配布したりすることが可能である。また、上記プログラムをインターネットや電子メール等、ネットワークを通して提供することも可能である。

図１３は、本実施の形態における上記コンピュータのハードウェア構成例を示す図である。図１３のコンピュータは、それぞれバスＢで相互に接続されているドライブ装置１０００、補助記憶装置１００２、メモリ装置１００３、ＣＰＵ１００４、インタフェース装置１００５、表示装置１００６、及び入力装置１００７等を有する。

当該コンピュータでの処理を実現するプログラムは、例えば、ＣＤ－ＲＯＭ又はメモリカード等の記録媒体１００１によって提供される。プログラムを記憶した記録媒体１００１がドライブ装置１０００にセットされると、プログラムが記録媒体１００１からドライブ装置１０００を介して補助記憶装置１００２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１００１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１００２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。

メモリ装置１００３は、プログラムの起動指示があった場合に、補助記憶装置１００２からプログラムを読み出して格納する。ＣＰＵ１００４は、メモリ装置１００３に格納されたプログラムに従って、当該ＰＣＲＦ１００に係る機能を実現する。インタフェース装置１００５は、ネットワークに接続するためのインタフェースとして用いられる。表示装置１００６はプログラムによるＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）等を表示する。入力装置１００７はキーボード及びマウス、ボタン、又はタッチパネル等で構成され、様々な操作指示を入力させるために用いられる。

（システムの動作例）
次に、図１４、図１５を参照してシステムの動作例を説明する。図１４、図１５いずれも、１デバイスに複数ルールが適用される場合を示しているが、１デバイスに１ルールが適用される場合も同様のシーケンスである。

図１４のＳ１０１、Ｓ１０２において、自ＮＷ管理のポリシールールがデバイス６０に適用される。このルールは、Ｘ［Ｍｂｐｓ］の帯域を割り当てるものである。

Ｓ１０３において、他事業者４０からＰＣＲＦ１００に対して、ＡＰＩ経由で、Ｙ［Ｍｂｐｓ］の帯域を割り当てるポリシールール適用指示が送られる。なお、契約帯域はＺ［Ｍｂｐｓ］であり、Ｘ＋Ｙ＞Ｚとなる。

Ｓ１０４において、ＰＣＲＦ１００の判定部１２０は、Ｘ＋Ｙ＞Ｚであることを検知し、競合の調停を行うことを決定する。Ｓ１０５において、最適ルール適用計算部１３０が、既に説明した最適化問題（０－１ナップサック問題）を解くことで、各ルールの適用可否を計算する。

Ｓ１０６において、出力部１４０は、最適ルール適用計算部１３０による計算結果である最適なルール適用の指示をＰＣＥＦ２０に通知する。Ｓ１０７において、ＰＣＥＦ２０は、指示されたルールをデバイス６０に適用する。また、Ｓ１０８において、出力部１４０は、ＡＰＩ経由でのルール適用指示に関して、そのルールを適用したか否かを指示元の他事業者４０に通知する。

図１５は、図１４における他事業者４０に代えて、ユーザ３０がＡＰＩ経由でポリシー適用指示を実行するものである。他事業者４０がユーザ３０に変わったこと以外は図１４での処理と同じである。

（具体例）
次に、最適ルール適用計算部１３０によるルールの調停の計算の具体例を説明する。以下の説明において、優先度はその数値が大きいほど高いものとする。また、帯域の単位はＭｂｐｓとし、契約帯域ｂは１００であるとする。また、便宜上、ｙ_ｉは全て０として考える。

＜例１＞
図１６を参照して例１を説明する。例１では、１デバイス１ルールが適用される場合を想定している。

例１において、デバイス＃１、デバイス＃２、デバイス＃３が、回線＃１（契約帯域：１００）に収容される。ここで、デバイス＃１、デバイス＃２には、自ＮＷにより、それぞれ割当帯域として６０、４０が既に割り当てられている。これらの優先度は１、１である。このとき、ＰＣＲＦ１００の記憶部１５０には、図１６のデバイス＃１とデバイス＃２のデータを持つテーブルが格納されている。

ここで、ＡＰＩ経由で、デバイス＃３に対して、優先度：２、割当帯域：５０のルール適用指示を受けるものとする。この場合、割当帯域の合計が１５０となり、１００を超える。図１６は、この指示を受信したときのテーブルを示している。

そこで、最適ルール適用計算部１３０が、調停を実施する。具体的には、目的関数ｚ＝Σ^ｎ _ｉ＝１（ｐ_ｉｘ_ｉ＋ｙ_ｉ）（制約条件Σ^ｎ _ｉ＝１ｃ_ｉｘ_ｉ＜ｂ、ｘ_ｉ∈｛０，１｝、－１≦ｙ_ｉ≦１（ｉ＝１，２，・・・，ｎ）、ｐ_ｉ≧０、ｃ_ｉ≧０、∀ｉ∈ｎ））を最大化するｘ_ｉの値を決定する。

この場合、ｘ_１＝０、ｘ_２＝１、ｘ_３＝１が解として得られ、図１６のテーブルのｘ_ｉの欄が上から０、１、１に書き換えられる。この結果より、出力部１４０は、デバイス＃１に対してルール不適用、デバイス＃２に対してルール適用、デバイス＃３に対してルール適用、を示すルール適用指示をＰＣＥＦ２０に対して送信し、ＰＣＥＦ２０はその指示に従ってルール適用を実行する。

＜例２＞
図１７を参照して例２を説明する。例２では、１デバイス（デバイス＃１）に複数ルールが適用される場合を想定している。

例２において、デバイス＃１が、回線＃１（契約帯域：１００）に収容される。ここで、デバイス＃１には、自ＮＷにより、ルール＃１、ルール＃２として６０、４０が既に割り当てられている。これらの優先度は１、１である。このとき、ＰＣＲＦ１００の記憶部１５０には、図１７のルール＃１とルール＃２のデータを持つテーブルが格納されている。

ここで、ＡＰＩ経由で、デバイス＃１に対して、優先度：２、割当帯域：５０からなるルール＃３の適用指示を受けるものとする。この場合、割当帯域の合計が１５０となり、１００を超える。図１７は、この指示を受信したときのテーブルを示している。

そこで、最適ルール適用計算部１３０が、調停を実施する。具体的には、目的関数ｚ＝Σ^ｎ _ｉ＝１（ｐ_ｉｘ_ｉ＋ｙ_ｉ）（制約条件Σ^ｎ _ｉ＝１ｃ_ｉｘ_ｉ＜ｂ、ｘ_ｉ∈｛０，１｝、－１≦ｙ_ｉ≦１（ｉ＝１，２，・・・，ｎ）、ｐ_ｉ≧０、ｃ_ｉ≧０、∀ｉ∈ｎ））を最大化するｘ_ｉの値を決定する。

この場合、ｘ_１＝０、ｘ_２＝１、ｘ_３＝１が解として得られ、図１７のテーブルのｘ_ｉの欄が上から０、１、１に書き換えられる。この結果より、出力部１４０は、デバイス＃１に対してルール＃１不適用、ルール＃２適用、ルール＃３適用、を示すルール適用指示をＰＣＥＦ２０に対して送信し、ＰＣＥＦ２０はその指示に従ってルール適用を実行する。

＜例３＞
次に、例３を説明する。例３では、図１８に示すように、１デバイス１ルール、１デバイス複数ルールが組み合わせられる場合を想定している。

例３において、デバイス＃１、デバイス＃２、デバイス＃３が、回線＃１（契約帯域：１００）に収容される。ここで、自ＮＷにより、デバイス＃１には、デバイス＃１に対するルール＃１、＃２として、割当帯域２０、３０が既に割り当てられている。これらの優先度は１、２である。また、デバイス＃３には、デバイス＃３に対するルール＃１として、割当帯域４０が既に割り当てられている。優先度は１である。

このとき、ＰＣＲＦの記憶部１５０には、図１９のデバイス＃１とデバイス＃３のデータを持つテーブルが格納されている。

ここで、ＡＰＩ経由で、デバイス＃２に対するルール＃１として、優先度：２、割当帯域：４０のルール適用指示を受けるものとする。この場合、割当帯域の合計が１３０となり、１００を超える。図１９は、この指示を受信したときのテーブルを示している。

そこで、最適ルール適用計算部１３０が、調停を実施する。具体的には、目的関数ｚ＝Σ_ｉΣ_ｊ（ｐ_ｉｊｘ_ｉｊ＋ｙ_ｉｊ）（制約条件Σ_ｉΣ_ｊｃ_ｉｊｘ_ｉｊ＜ｂ、ｘ_ｉｊ∈｛０，１｝、－１≦ｙ_ｉｊ≦１（ｉ＝１，２，・・・，ｎ、ｊ＝１，２，・・・，ｋ）、ｐ_ｉｊ≧０、ｃ_ｉｊ≧０、∀ｉ∈ｎ、∀ｊ∈ｋ））を最大化するｘ_ｉｊの値を決定する。なお、ｋは、ｉ毎のルールの数である。

この場合、ｚ＝（ｐ_１１ｘ_１１＋ｙ_１１）＋（ｐ_１２ｘ_１２＋ｙ_１２）＋（ｐ_２１ｘ_２１＋ｙ_２１）＋（ｐ_３１ｘ_３１＋ｙ_３１）であり、制約条件の下、ｘ_１１＝１、ｘ_１２＝１、ｘ_２１＝１、ｘ_３１＝０が解として得られる。図１９のテーブルのｘ_ｉｊの欄が上から１、１、１、０に書き換えられる。この結果より、出力部１４０は、デバイス＃１に対してルール＃１、＃２適用、デバイス＃２に対してルール＃１適用、デバイス＃３に対してルール＃１不適用、を示すルール適用指示をＰＣＥＦ２０に対して送信し、ＰＣＥＦ２０はその指示に従ってルール適用を実行する。

（実施の形態の効果、まとめ）
以上、説明したように、本実施の形態に係る技術により、デバイスに対して複数のポリシールールに基づくリソース競合が発生した場合、ＰＣＲＦ１００にて、帯域の制約条件を満たしながら、優先度の和を最大化した最適なポリシーを判断できる。また、ＰＣＲＦ１００からＡＰＩ経由で、ポリシー適用指示元に対し、ポリシー適用の可否を通知することができる。

本明細書には少なくとも下記の各項に記載された装置、方法、プログラムが記載されている。
（第１項）
リソースの競合を調停するリソース競合調停装置であって、
１つ又は複数のデバイスのうちのあるデバイスに対するリソース割当要求を受信する受信手段と、
前記リソース割当要求で要求されたリソースを前記デバイスに割り当てるとした場合に、前記１つ又は複数のデバイスに割り当てられるリソースの合計値が、使用可能なリソースの上限値を超えるか否かを判定する判定手段と、
前記判定手段により、前記合計値が前記上限値を超えると判定された場合に、前記１つ又は複数のデバイスに割り当てられるリソースの合計値が前記上限値を超えないという制約条件の下で、各デバイスに対するリソース割当の優先度の和が最大になるように各デバイスに対するリソース割当可否を決定する計算手段と
を備えるリソース競合調停装置。
（第２項）
前記計算手段による計算結果に基づき、前記リソース割当要求の適用可否を当該リソース割当要求の要求元に通知する出力手段
を更に備える第１項に記載のリソース競合調停装置。
（第３項）
前記リソースは通信帯域であり、前記リソース割当要求は、ＡＰＩ経由で適用を指示されたポリシールールである
第１項又は第２項に記載のリソース競合調停装置。
（第４項）
リソースの競合を調停するリソース競合調停装置が実行するリソース競合調停方法であって、
１つ又は複数のデバイスのうちのあるデバイスに対するリソース割当要求を受信する受信ステップと、
前記リソース割当要求で要求されたリソースを前記デバイスに割り当てるとした場合に、前記１つ又は複数のデバイスに割り当てられるリソースの合計値が、使用可能なリソースの上限値を超えるか否かを判定する判定ステップと、
前記判定ステップにより、前記合計値が前記上限値を超えると判定された場合に、前記１つ又は複数のデバイスに割り当てられるリソースの合計値が前記上限値を超えないという制約条件の下で、各デバイスに対するリソース割当の優先度の和が最大になるように各デバイスに対するリソース割当可否を決定する計算ステップと
を備えるリソース競合調停方法。
（第５項）
コンピュータを、第１項ないし第３項のうちいずれか１項に記載のリソース競合調停装置の各手段として機能させるためのプログラム。

以上、本実施の形態について説明したが、本発明はかかる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

１０、１００ ＰＣＲＦ
２０ ＰＣＥＦ
３０ ユーザ
４０ 他事業者
５０ ＩｏＴ－ＧＷ
１１０ 入力部
１２０ 判定部
１３０ 最適ルール適用計算部
１４０ 出力部
１５０ 記憶部
１０００ ドライブ装置
１００２ 補助記憶装置
１００３ メモリ装置
１００４ ＣＰＵ
１００５ インタフェース装置
１００６ 表示装置
１００７ 入力装置

Claims (4)

1. リソースの競合を調停するリソース競合調停装置であって、
   １つ又は複数のデバイスのうちのあるデバイスに対するリソース割当要求を受信する受信手段と、
   前記リソース割当要求で要求されたリソースを前記デバイスに割り当てるとした場合に、前記１つ又は複数のデバイスに割り当てられるリソースの合計値が、使用可能なリソースの上限値を超えるか否かを判定する判定手段と、
   前記判定手段により、前記合計値が前記上限値を超えると判定された場合に、前記１つ又は複数のデバイスに割り当てられるリソースの合計値が前記上限値を超えないという制約条件の下で、各デバイスに対するリソース割当の優先度の和が最大になるように各デバイスに対するリソース割当可否を決定する計算手段とを備え、
   前記リソースは通信帯域であり、前記リソース割当要求は、ＡＰＩ経由で適用を指示されたポリシールールである
   リソース競合調停装置。
2. 前記計算手段による計算結果に基づき、前記リソース割当要求の適用可否を当該リソース割当要求の要求元に通知する出力手段
   を更に備える請求項１に記載のリソース競合調停装置。
3. リソースの競合を調停するリソース競合調停装置が実行するリソース競合調停方法であって、
   １つ又は複数のデバイスのうちのあるデバイスに対するリソース割当要求を受信する受信ステップと、
   前記リソース割当要求で要求されたリソースを前記デバイスに割り当てるとした場合に、前記１つ又は複数のデバイスに割り当てられるリソースの合計値が、使用可能なリソースの上限値を超えるか否かを判定する判定ステップと、
   前記判定ステップにより、前記合計値が前記上限値を超えると判定された場合に、前記１つ又は複数のデバイスに割り当てられるリソースの合計値が前記上限値を超えないという制約条件の下で、各デバイスに対するリソース割当の優先度の和が最大になるように各デバイスに対するリソース割当可否を決定する計算ステップとを備え、
   前記リソースは通信帯域であり、前記リソース割当要求は、ＡＰＩ経由で適用を指示されたポリシールールである
   リソース競合調停方法。
4. コンピュータを、請求項１又は２に記載のリソース競合調停装置の各手段として機能させるためのプログラム。

Images