Traitement en cours

Veuillez attendre...

Paramétrages

Paramétrages

Aller à Demande

1. WO2020166617 - APPAREIL D'ARBITRAGE DE CONTENTION DE RESSOURCES, PROCÉDÉ D'ARBITRAGE DE CONTENTION DE RESSOURCES, ET PROGRAMME

Document

明 細 書

発明の名称 リソース競合調停装置、リソース競合調停方法、及びプログラム

技術分野

0001  

背景技術

0002   0003   0004   0005  

先行技術文献

特許文献

0006  

発明の概要

発明が解決しようとする課題

0007   0008   0009  

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

0010  

発明の効果

0011  

図面の簡単な説明

0012  

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

0013   0014   0015   0016   0017   0018   0019   0020   0021   0022   0023   0024   0025   0026   0027   0028   0029   0030   0031   0032   0033   0034   0035   0036   0037   0038   0039   0040   0041   0042   0043   0044   0045   0046   0047   0048   0049   0050   0051   0052   0053   0054   0055   0056   0057   0058   0059   0060   0061   0062   0063   0064   0065   0066   0067   0068   0069   0070   0071   0072   0073  

符号の説明

0074  

請求の範囲

1   2   3   4   5  

図面

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19  

明 細 書

発明の名称 : リソース競合調停装置、リソース競合調停方法、及びプログラム

技術分野

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

背景技術

[0002]
 これまで固定網/移動体網単独で提供していたサービスについて、他事業者やエンドユーザへAPIを開放し、API経由で更に柔軟かつリアルタイムにサービスを提供・変更することに対する需要が高まっている。
[0003]
 従来、固定網BPCF/移動体網PCRF単独で適用ポリシーを判定することができていたが、今後は、上記の需要に応えるために、API経由で他事業者から指定されるポリシーとの競合を考慮する必要がある。他事業者網とのS9a連携(3GPP規定)についても、同様の考慮が必要である。
[0004]
 図1(a)~(d)は、ポリシー連携モデルの例を示している。図1(a)は、他の事業者と固定網のAPI経由のポリシー連携モデルの例を示し、図1(b)は、エンドユーザと固定網のAPI経由のポリシー連携モデルの例を示し、図1(c)は、他の事業者と移動体網のAPI経由のポリシー連携モデルの例を示し、図1(d)は、固定網と移動体網のポリシー連携モデルの例を示している。
[0005]
 さて、近年、ネットワークカメラやテレビ等、ネットワークに接続されるIoTデバイスが多様化している。特に、5G/IoT時代には、NWにつながるIoTデバイスが多様化(カメラ、センサ、等)し、デバイス毎に求められるポリシーも多様化すると想定される(例:監視カメラの映像を優先制御)。

先行技術文献

特許文献

[0006]
特許文献1 : 特開2003-264586号公報

発明の概要

発明が解決しようとする課題

[0007]
 5G/IoT時代を見据えたキャリアネットワークでは、これらのIoTデバイスに対し、(1)自NWからのポリシー適用、(2)ユーザからのAPI経由のポリシー適用、(3)他事業者からのAPI経由のポリシー適用、が競合するおそれがある。図2は、このような競合の例を示している。図2の例では、自NWは、PCRF10等を備える移動体網である。図2に示すように、IoT-GW#1において、ユーザ30から指示されるポリシー(Rule#2)と、自NWより指示されるポリシー(Rule#1)と、他事業者から指示されるポリシー(Rule#3)が競合する。競合とは、より具体的には通信のリソースである帯域が競合することである。
[0008]
 しかし、上記のようなリソースの競合を調停するための技術はこれまでに提案されていない。
[0009]
 本発明は上記の点に鑑みてなされたものであり、通信サービスを利用するデバイスに対するリソースの競合を調停することを可能とする技術を提供することを目的とする。

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

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

発明の効果

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

図面の簡単な説明

[0012]
[図1] ポリシー連携モデルの例を示す図である。
[図2] IoTデバイス毎のポリシー連携を示す図である。
[図3] ポリシー管理・制御方式の例を示す図である。
[図4] 課題を説明するための図である。
[図5] 課題を説明するための図である。
[図6] 本発明の実施の形態の概要を説明するための図である。
[図7] 本発明の実施の形態の概要を説明するための図である。
[図8] 本発明の実施の形態の概要を説明するための図である。
[図9] 本発明の実施の形態の形態におけるシステム構成図である。
[図10] デバイス毎の割当帯域の最適化問題を示す図である。
[図11] 本発明の実施の形態の形態におけるシステム構成図である。
[図12] PCRFの構成図である。
[図13] 装置のハードウェア構成例を示す図である。
[図14] システムの動作例を説明するためのシーケンス図である。
[図15] システムの動作例を説明するためのシーケンス図である。
[図16] 具体例を説明するための図である。
[図17] 具体例を説明するための図である。
[図18] 具体例を説明するための図である。
[図19] 具体例を説明するための図である。

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

[0013]
 以下、図面を参照して本発明の実施の形態(本実施の形態)を説明する。以下で説明する実施の形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施の形態に限られるわけではない。
[0014]
 例えば、以下の例では、本発明の動作をPCRFが実行するが、本発明はPCRF以外の装置にも適用可能である。また、以下の例では、調停するリソースが通信の帯域であるが、本発明は帯域に限らないリソースの調停に適用できる。以下ではまず、課題に関する動作等を説明し、その後に本発明に係る技術を説明する。
[0015]
 (課題について)
 図3を参照して、一般的なポリシー管理・制御方式を説明する。図3に示すシステム構成は、図2と同様であり、自NW(自事業者)はPCRF10、PCEF20を含む移動体網である。なお、PCRF(Policy and Charging Rule Function)は、ポリシー情報を管理するノードであり、PCEF(Policy and Charging Enforcement Function)は、ポリシー制御を実行するノードである。PCEFはP-GWに含まれる場合が多い。
[0016]
 当該自NWに、種々のデバイスを収容するIoT-GW50(ユーザの装置)が接続されている。また、当該自NWに、ユーザ30(具体的にはユーザ端末等)と他事業者40(他事業者のネットワークに接続された装置等)がそれぞれAPIを介して接続されている。図3に示す例では、IoT-GW50と自NWとの間の回線(具体的にはVLAN等)の契約帯域は100Mbpsである。つまり、使用可能な帯域の上限値が100Mbpsである。
[0017]
 また、PCRF10からPCEF20に対し、Dynamicにポリシー適用を指示することができるとともに、API経由でユーザ30及び他事業者40からPCEF20に対してポリシー適用を指示することができる。
[0018]
 図3に示す例では、ユーザ30から、デバイス#2に対する50Mbps保証(優先度高)のポリシー適用が指示され、他事業者40から、デバイス#3に対する50Mbps保証(優先度高)のポリシー適用が指示され、自NW(PCRF10)から、デバイス#1に対する50Mbps保証(優先度高)のポリシー適用が指示されている。なお、ポリシーの内容を「ルール」と呼ぶ。この「ルール」を「ポリシールール」と呼んでもよい。
[0019]
 上記のポリシーで指示された優先度高の帯域を合計すると150Mbpsになる、すなわち、自PCRFとAPI経由の優先度高のルールを適用すると、保証帯域の合計が契約帯域を超過してしまう。つまり、リソース競合が発生する。
[0020]
 このリソース競合をPCRF10で適切に調停する必要があるが、従来技術では、APIからのポリシー適用指示がされた場合の競合を調停する仕組みがなく、調停を行うことができない。
[0021]
 課題が生じる他の例を図4、図5に示す。図4は、図5との比較のために示したものであり、自NWのPCRF10からポリシー制御を行う場合を示したものである。図4に示すように、自NWのPCRF10から、IoT-GW#1配下のデバイス#1~デバイス#3、及びIoT-GW#2配下のデバイス#4~デバイス#6へのポリシー適用の指示が行われている。図4に示すように、IoT-GW#1、IoT-GW#2のいずれについても、優先転送の割当帯域は、契約帯域以下になっている。
[0022]
 図5は、API経由で他事業者(ここではIoT事業者60)からポリシー制御を行う場合の例を示している。図5に示すように、IoT事業者60から、IoT-GW#1配下のデバイス#1~デバイス#3、及びIoT-GW#2配下のデバイス#4~デバイス#6へのポリシー適用の指示が行われている。図5に示すように、IoT-GW#1における優先転送の割当帯域は計110Mbpsとなり契約帯域を超過している。
[0023]
 このように、従来技術では、API経由で他事業者(ここではIoT事業者60)からポリシー制御を行う場合において、(1VLAN配下のデバイスに対する要求帯域の合計帯域)>(1VLANの割当帯域)となる場合を検出することができない。
[0024]
 以下、上記の課題を解決して、リソース競合をPCRFで適切に調停し、デバイスに対するルールの適用を最適化することを可能とする技術を、本発明の実施の形態として説明する。
[0025]
 (実施の形態の概要)
 本実施の形態におけるシステム構成は、例えば図2に示したシステム構成である。ただし、PCRFは本発明に係る機能を含む。以降、従来の「PCRF10」と本発明の機能を含むPCRFとを区別するために、本発明の機能を含むPCRFを「PCRF100」と記載する。なお、PCRF100は、リソースの競合を調停する機能を持つので、PCRF100をリソース競合調停装置と呼んでもよい。
[0026]
 本実施の形態では、PCRF100から各デバイスに対し、割当帯域に関するポリシー適用を指示する過程をオンライン0-1ナップサック問題と捉え、PCRF100において、分枝限定法によりポリシールール適用の調停を実施する。
[0027]
 ここで、一例として、1デバイスに1ルールを適用する場合を考え、契約帯域をb、ルール適用を指示する対象となるデバイス数をnとし、デバイスiに対するルールの適用指示は優先度p (優先度の基準は統一されている前提)で帯域幅c を使用することを指示するものであるとする。このような前提の下、PCRF100は、契約帯域内で各デバイス毎の適用ルールの優先度の和を最大化するルールの選び方に関する問題を解く。
[0028]
 ここで、オンラインナップサック問題について説明する。図6に示すように、オンラインナップサック問題とは、容量bのナップサックが1つと、n種類の品物(各々価値p 、容積c )が与えられたとき、ナップサックの容量を超えない範囲で入れた品物の価値の和を最大化する品物の選び方に関する問題である。
[0029]
 オンラインナップサック問題を、本実施の形態におけるデバイス毎の割当帯域のオンライン最適化問題に適用したものを図7に示す。本実施の形態におけるデバイス毎の割当帯域のオンライン最適化問題は、契約帯域幅bの契約回線が1つと、n個のデバイス(各々適用ルールの優先度p 、割当帯域幅c )が与えられたとき、契約回線の契約帯域幅を超えない範囲で適用したデバイス毎の適用ルールの優先度の和を最大化するデバイス毎のルールの選び方に関する問題になる。
[0030]
 特に、本実施の形態では、図8に示すように、n個のデバイスに対してルールが適用されていて、更に、API経由でルールの適用指示があり、そこで競合が発生するような場合の問題を想定している。
[0031]
 (システム構成)
 図9は、本実施の形態におけるシステム構成の例を示している。図9に示すように、移動体網(自NW)には、PCEF20、及び本発明に係る機能を持つPCRF100が備えられている。また、自NWには、IoT-GW50が接続され、IoT-GW50の配下にはデバイス#1~#iが接続されている。自NWのPCRF100からポリシールールの適用を各デバイスに指示することができるとともに、ユーザ30及び他事業者40のそれぞれは、APIを介して、ポリシールール適用をPCRF100を経由して各デバイスに指示することができる。
[0032]
 (基本動作)
 PCRF100は、上述した最適化問題を解くことで、デバイス毎に最適なポリシールールの適用を決定する。
[0033]
 具体的には、1デバイスに1ルールを適用する場合において、デバイスiに対し、ルールを適用する時はx =1、ルールを適用しない時はx =0とし、契約帯域をb、ルール適用を指示する対象となるデバイス数をnとし、デバイスiについての各ルールの適用に関して、その優先度をp とし、当該ルールで指示される割当帯域幅をc とし、アプリケーション等の用途に応じた定数をy とする。図10に、これらのパラメータが示されている。y はアプリケーション毎に予め定めておく定数である。なお、y を使用しないこととしてもよい。
[0034]
 PCRF100は、契約帯域内で各デバイスの適用ルールの優先度の和を最大化するために、目的関数z=Σ i=1(p +y )(制約条件Σ i=1<b、x ∈{0,1}、-1≦y ≦1(i=1,2,・・・,n)、p ≧0、c ≧0、∀i∈n))を最大化するx の値を決定する。
[0035]
 図11に示すように、1デバイスに複数ルールを適用する場合にも同様である。この場合、1デバイスとしてデバイス#1に着目する。デバイス#1に対し、ルールiを適用する時はx =1、ルールiを適用しない時はx =0とし、契約帯域をb、ルール数をnとし、各ルールiに関して、その優先度をp とし、当該ルールiで指示される割当帯域幅をc とし、アプリケーション等の用途に応じた定数をy とする。
[0036]
 PCRF100は、契約帯域内でルールの優先度の和を最大化するために、目的関数z=Σ i=1(p +y )(制約条件Σ i=1<b、x ∈{0,1}、-1≦y ≦1(i=1,2,・・・,n)、p ≧0、c ≧0、∀i∈n))を最大化するx の値を決定する。
[0037]
 なお、PCRF100は、上記の0-1ナップサック問題を分枝限定法を用いて解くことができる。また、PCRF100は、緩和問題の利用等により、効率的に上記の0-1ナップサック問題を解くことができる。なお、上記最適化問題を解くこと自体については、種々の既存技術を使用することができる。
[0038]
 (装置構成例)
 図12に、PCRF100の機能構成例を示す。図12に示すように、PCRF100は、入力部110、判定部120、最適ルール適用計算部130、出力部140、及び記憶部150を有する。
[0039]
 入力部110は、外部(自NWのオペレーションシステム、API経由での他事業者/ユーザ等)からルールの適用指示を受信し、PCRF100の内部に入力する。判定部120は、入力されたルールを適用した場合に、デバイスへの割当帯域の合計が回線の契約帯域を超えるかどうかの判定を行う。
[0040]
 最適ルール適用計算部130は、判定部120により、デバイスへの割当帯域の合計が回線の契約帯域を超えると判断された場合、つまり、リソース競合が発生すると判断された場合に、前述した最適化問題を解くことで、各デバイスへの最適なルールの適用を計算する。
[0041]
 出力部140は、最適なルールの適用指示をPCEF20に対して行う。また、出力部140は、API経由で受けたルール適用指示について、その適用可否(適用したか否か)を指示元に通知する。
[0042]
 記憶部150は、各デバイスに対して指示されたルール、及びそのルールの適用有無等を管理するテーブルを格納している。
[0043]
 PCRF100は、例えば、コンピュータに、本実施の形態で説明する処理内容を記述したプログラムを実行させることにより実現可能である。
[0044]
 PCRF100は、コンピュータに内蔵されるCPUやメモリ等のハードウェア資源を用いて、当該PCRF100で実施される処理に対応するプログラムを実行することによって実現することが可能である。上記プログラムは、コンピュータが読み取り可能な記録媒体(可搬メモリ等)に記録して、保存したり、配布したりすることが可能である。また、上記プログラムをインターネットや電子メール等、ネットワークを通して提供することも可能である。
[0045]
 図13は、本実施の形態における上記コンピュータのハードウェア構成例を示す図である。図13のコンピュータは、それぞれバスBで相互に接続されているドライブ装置1000、補助記憶装置1002、メモリ装置1003、CPU1004、インタフェース装置1005、表示装置1006、及び入力装置1007等を有する。
[0046]
 当該コンピュータでの処理を実現するプログラムは、例えば、CD-ROM又はメモリカード等の記録媒体1001によって提供される。プログラムを記憶した記録媒体1001がドライブ装置1000にセットされると、プログラムが記録媒体1001からドライブ装置1000を介して補助記憶装置1002にインストールされる。但し、プログラムのインストールは必ずしも記録媒体1001より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置1002は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。
[0047]
 メモリ装置1003は、プログラムの起動指示があった場合に、補助記憶装置1002からプログラムを読み出して格納する。CPU1004は、メモリ装置1003に格納されたプログラムに従って、当該PCRF100に係る機能を実現する。インタフェース装置1005は、ネットワークに接続するためのインタフェースとして用いられる。表示装置1006はプログラムによるGUI(Graphical User Interface)等を表示する。入力装置1007はキーボード及びマウス、ボタン、又はタッチパネル等で構成され、様々な操作指示を入力させるために用いられる。
[0048]
 (システムの動作例)
 次に、図14、図15を参照してシステムの動作例を説明する。図14、図15いずれも、1デバイスに複数ルールが適用される場合を示しているが、1デバイスに1ルールが適用される場合も同様のシーケンスである。
[0049]
 図14のS101、S102において、自NW管理のポリシールールがデバイス60に適用される。このルールは、X[Mbps]の帯域を割り当てるものである。
[0050]
 S103において、他事業者40からPCRF100に対して、API経由で、Y[Mbps]の帯域を割り当てるポリシールール適用指示が送られる。なお、契約帯域はZ[Mbps]であり、X+Y>Zとなる。
[0051]
 S104において、PCRF100の判定部120は、X+Y>Zであることを検知し、競合の調停を行うことを決定する。S105において、最適ルール適用計算部130が、既に説明した最適化問題(0-1ナップサック問題)を解くことで、各ルールの適用可否を計算する。
[0052]
 S106において、出力部140は、最適ルール適用計算部130による計算結果である最適なルール適用の指示をPCEF20に通知する。S107において、PCEF20は、指示されたルールをデバイス60に適用する。また、S108において、出力部140は、API経由でのルール適用指示に関して、そのルールを適用したか否かを指示元の他事業者40に通知する。
[0053]
 図15は、図14における他事業者40に代えて、ユーザ30がAPI経由でポリシー適用指示を実行するものである。他事業者40がユーザ30に変わったこと以外は図14での処理と同じである。
[0054]
 (具体例)
 次に、最適ルール適用計算部130によるルールの調停の計算の具体例を説明する。以下の説明において、優先度はその数値が大きいほど高いものとする。また、帯域の単位はMbpsとし、契約帯域bは100であるとする。また、便宜上、y は全て0として考える。
[0055]
 <例1>
 図16を参照して例1を説明する。例1では、1デバイス1ルールが適用される場合を想定している。
[0056]
 例1において、デバイス#1、デバイス#2、デバイス#3が、回線#1(契約帯域:100)に収容される。ここで、デバイス#1、デバイス#2には、自NWにより、それぞれ割当帯域として60、40が既に割り当てられている。これらの優先度は1、1である。このとき、PCRF100の記憶部150には、図16のデバイス#1とデバイス#2のデータを持つテーブルが格納されている。
[0057]
 ここで、API経由で、デバイス#3に対して、優先度:2、割当帯域:50のルール適用指示を受けるものとする。この場合、割当帯域の合計が150となり、100を超える。図16は、この指示を受信したときのテーブルを示している。
[0058]
 そこで、最適ルール適用計算部130が、調停を実施する。具体的には、目的関数z=Σ i=1(p +y )(制約条件Σ i=1<b、x ∈{0,1}、-1≦y ≦1(i=1,2,・・・,n)、p ≧0、c ≧0、∀i∈n))を最大化するx の値を決定する。
[0059]
 この場合、x =0、x =1、x =1が解として得られ、図16のテーブルのx の欄が上から0、1、1に書き換えられる。この結果より、出力部140は、デバイス#1に対してルール不適用、デバイス#2に対してルール適用、デバイス#3に対してルール適用、を示すルール適用指示をPCEF20に対して送信し、PCEF20はその指示に従ってルール適用を実行する。
[0060]
 <例2>
 図17を参照して例2を説明する。例2では、1デバイス(デバイス#1)に複数ルールが適用される場合を想定している。
[0061]
 例2において、デバイス#1が、回線#1(契約帯域:100)に収容される。ここで、デバイス#1には、自NWにより、ルール#1、ルール#2として60、40が既に割り当てられている。これらの優先度は1、1である。このとき、PCRF100の記憶部150には、図17のルール#1とルール#2のデータを持つテーブルが格納されている。
[0062]
 ここで、API経由で、デバイス#1に対して、優先度:2、割当帯域:50からなるルール#3の適用指示を受けるものとする。この場合、割当帯域の合計が150となり、100を超える。図17は、この指示を受信したときのテーブルを示している。
[0063]
 そこで、最適ルール適用計算部130が、調停を実施する。具体的には、目的関数z=Σ i=1(p +y )(制約条件Σ i=1<b、x ∈{0,1}、-1≦y ≦1(i=1,2,・・・,n)、p ≧0、c ≧0、∀i∈n))を最大化するx の値を決定する。
[0064]
 この場合、x =0、x =1、x =1が解として得られ、図17のテーブルのx の欄が上から0、1、1に書き換えられる。この結果より、出力部140は、デバイス#1に対してルール#1不適用、ルール#2適用、ルール#3適用、を示すルール適用指示をPCEF20に対して送信し、PCEF20はその指示に従ってルール適用を実行する。
[0065]
 <例3>
 次に、例3を説明する。例3では、図18に示すように、1デバイス1ルール、1デバイス複数ルールが組み合わせられる場合を想定している。
[0066]
 例3において、デバイス#1、デバイス#2、デバイス#3が、回線#1(契約帯域:100)に収容される。ここで、自NWにより、デバイス#1には、デバイス#1に対するルール#1、#2として、割当帯域20、30が既に割り当てられている。これらの優先度は1、2である。また、デバイス#3には、デバイス#3に対するルール#1として、割当帯域40が既に割り当てられている。優先度は1である。
[0067]
 このとき、PCRFの記憶部150には、図19のデバイス#1とデバイス#3のデータを持つテーブルが格納されている。
[0068]
 ここで、API経由で、デバイス#2に対するルール#1として、優先度:2、割当帯域:40のルール適用指示を受けるものとする。この場合、割当帯域の合計が130となり、100を超える。図19は、この指示を受信したときのテーブルを示している。
[0069]
 そこで、最適ルール適用計算部130が、調停を実施する。具体的には、目的関数z=Σ Σ (p ijij+y ij)(制約条件Σ Σ ijij<b、x ij∈{0,1}、-1≦y ij≦1(i=1,2,・・・,n、j=1,2,・・・,k)、p ij≧0、c ij≧0、∀i∈n、∀j∈k))を最大化するx ijの値を決定する。なお、kは、i毎のルールの数である。
[0070]
 この場合、z=(p 1111+y 11)+(p 1212+y 12)+(p 2121+y 21)+(p 3131+y 31)であり、制約条件の下、x 11=1、x 12=1、x 21=1、x 31=0が解として得られる。図19のテーブルのx ijの欄が上から1、1、1、0に書き換えられる。この結果より、出力部140は、デバイス#1に対してルール#1、#2適用、デバイス#2に対してルール#1適用、デバイス#3に対してルール#1不適用、を示すルール適用指示をPCEF20に対して送信し、PCEF20はその指示に従ってルール適用を実行する。
[0071]
 (実施の形態の効果、まとめ)
 以上、説明したように、本実施の形態に係る技術により、デバイスに対して複数のポリシールールに基づくリソース競合が発生した場合、PCRF100にて、帯域の制約条件を満たしながら、優先度の和を最大化した最適なポリシーを判断できる。また、PCRF100からAPI経由で、ポリシー適用指示元に対し、ポリシー適用の可否を通知することができる。
[0072]
 本明細書には少なくとも下記の各項に記載された装置、方法、プログラムが記載されている。
(第1項)
 リソースの競合を調停するリソース競合調停装置であって、
 1つ又は複数のデバイスのうちのあるデバイスに対するリソース割当要求を受信する受信手段と、
 前記リソース割当要求で要求されたリソースを前記デバイスに割り当てるとした場合に、前記1つ又は複数のデバイスに割り当てられるリソースの合計値が、使用可能なリソースの上限値を超えるか否かを判定する判定手段と、
 前記判定手段により、前記合計値が前記上限値を超えると判定された場合に、前記1つ又は複数のデバイスに割り当てられるリソースの合計値が前記上限値を超えないという制約条件の下で、各デバイスに対するリソース割当の優先度の和が最大になるように各デバイスに対するリソース割当可否を決定する計算手段と
 を備えるリソース競合調停装置。
(第2項)
 前記計算手段による計算結果に基づき、前記リソース割当要求の適用可否を当該リソース割当要求の要求元に通知する出力手段
 を更に備える第1項に記載のリソース競合調停装置。
(第3項)
 前記リソースは通信帯域であり、前記リソース割当要求は、API経由で適用を指示されたポリシールールである
 第1項又は第2項に記載のリソース競合調停装置。
(第4項)
 リソースの競合を調停するリソース競合調停装置が実行するリソース競合調停方法であって、
 1つ又は複数のデバイスのうちのあるデバイスに対するリソース割当要求を受信する受信ステップと、
 前記リソース割当要求で要求されたリソースを前記デバイスに割り当てるとした場合に、前記1つ又は複数のデバイスに割り当てられるリソースの合計値が、使用可能なリソースの上限値を超えるか否かを判定する判定ステップと、
 前記判定ステップにより、前記合計値が前記上限値を超えると判定された場合に、前記1つ又は複数のデバイスに割り当てられるリソースの合計値が前記上限値を超えないという制約条件の下で、各デバイスに対するリソース割当の優先度の和が最大になるように各デバイスに対するリソース割当可否を決定する計算ステップと
 を備えるリソース競合調停方法。
(第5項)
 コンピュータを、第1項ないし第3項のうちいずれか1項に記載のリソース競合調停装置の各手段として機能させるためのプログラム。
[0073]
 以上、本実施の形態について説明したが、本発明はかかる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

符号の説明

[0074]
10、100 PCRF
20 PCEF
30 ユーザ
40 他事業者
50 IoT-GW
110 入力部
120 判定部
130 最適ルール適用計算部
140 出力部
150 記憶部
1000 ドライブ装置
1002 補助記憶装置
1003 メモリ装置
1004 CPU
1005 インタフェース装置
1006 表示装置
1007 入力装置

請求の範囲

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

図面

[ 図 1]

[ 図 2]

[ 図 3]

[ 図 4]

[ 図 5]

[ 図 6]

[ 図 7]

[ 図 8]

[ 図 9]

[ 図 10]

[ 図 11]

[ 図 12]

[ 図 13]

[ 図 14]

[ 図 15]

[ 図 16]

[ 図 17]

[ 図 18]

[ 図 19]