JP7112322B2 - 通信要件を提示する制御装置、制御方法、及びプログラム - Google Patents

Description

本発明は、サービスを提供する際の通信要件の設定支援技術に関する。

第３世代パートナーシッププロジェクト（３ＧＰＰ）において、第５世代の無線通信システムが検討されている。第５世代システムでは、無線ドメインやコアネットワークドメイン等の様々なドメインを含んだネットワークを、サービスごとに論理的に分離する、Ｅｎｄ－ｔｏ－Ｅｎｄ（Ｅ２Ｅ）でのネットワークスライシングが検討されている。このようなＥ２Ｅネットワークスライシングにより、要件が異なる様々なサービスに対応する通信を、互いに独立した状態でまとめて収容することが可能となる。Ｅ２Ｅネットワークスライシングでは、オーケストレータと呼ばれる制御機能がネットワークに含まれる様々なドメインの状況の管理や制御を行う。

オーケストレータは、通信サービスを提供するプロバイダやサービスを享受するエンドユーザ等のユーザから実行すべきサービス要件を受け付け、そのサービス要件に対応する通信要件（例えば、許容遅延、許容エラー率、所要無線品質等）を特定しうる。オーケストレータは、その通信要件を満たすことができるか否かを、例えば各ドメインのコントローラに問い合わせ、それらの情報を総合して、ユーザに対して、要求されたサービス要件での通信が可能であるか否かを通知することができる。

３ＧＰＰ ＴＳ３６．３００ Ｖ１３．４．０、２０１６年６月

無線環境等を含むユーザの状況によっては通信要件を満たすのに必要な無線リソースが異なり、また、そのユーザへサービスを提供するために使用可能なシステム内の機器の演算リソースの量が異なりうる。このため、例えば、ユーザが通信に必要な無線リソースの量を認識せずにサービスの提供を受けることにより高額な通信料金を請求されたり、使用可能な演算リソースが少ないことに起因して十分なサービスを受けることができなかったりし、利便性に欠けるという課題があった。

本発明は上記課題に鑑みてなされたものであり、通信を伴うサービスの実行の際のユーザ利便性を向上させるための技術を提供する。

本発明の一態様による制御装置は、ユーザから受け付けたサービス要件に基づいて前記ユーザに関連付けられた通信装置とネットワークとの間の通信に関する第１の通信要件を特定すると共に、前記第１の通信要件の代替候補の前記通信装置と前記ネットワークとの間の通信に関する第２の通信要件を特定する第１の特定手段と、前記第１の通信要件および前記第２の通信要件のそれぞれが満たされるように前記通信装置と前記ネットワークとの間の通信が行われる場合に要求される、無線リソースと演算リソースとを含んだリソースの量を、通信要件と要求されるリソースの量とを関連付けた情報を参照することにより特定する第２の特定手段と、前記第２の通信要件を示す情報と、前記第１の通信要件および前記第２の通信要件のそれぞれについて特定された前記リソースの量に関連する情報とを前記ユーザへ通知する通知手段と、前記第１の通信要件または前記第２の通信要件の前記ユーザによる選択を受け付ける受付手段と、前記ユーザによって選択された通信要件について特定された前記リソースの量を、当該リソースを用いた前記通信装置と前記ネットワークとの間の通信処理を制御する装置に確保させるための制御を実行する制御手段と、を有する。

本発明によれば、通信を伴うサービスの実行の際のユーザ利便性を向上させることができる。

システム構成の例を示す図である。 通信要件と消費リソース量とを含むリストの構成例を示す図である。 オーケストレータのハードウェア構成例を示す図である。 オーケストレータの機能構成例を示す図である。 処理の流れの例を示す図である。

以下、本発明の実施の形態について、図面を参照しながら説明する。

（システム構成）
図１に、本実施形態に係るシステムの構成例を示す。本システムは、一例において、第５世代（５Ｇ）の無線通信システムであり、ネットワークをサービスごとに論理的に分離して、Ｅ２Ｅネットワークスライシングを実現可能に構成される。また、本システムは、一例において、ＲＡＮドメイン（Radio Access Network）を管理するＲＡＮコントローラ、トランスポートドメインを管理するトランスポートコントローラ、モバイルコアドメインを管理するモバイルコアコントローラ等のドメインコントローラと、それらのドメインコントローラの制御を行うオーケストレータを含んで構成される。各ドメインコントローラは、そのドメインでの通信処理を実行するための装置を制御するように構成される。例えば、ＲＡＮコントローラは、ＲＡＮの各処理を実行するＲＡＮ装置（例えば基地局装置や、基地局を制御する制御局等）を制御して、無線端末との通信を行わせることができる。また、本実施形態では、ユーザ装置が少なくともオーケストレータと通信可能に構成される。なお、ここでの「ユーザ」は、通信を使用した通信サービスの提供を受けるエンドユーザのみならず、そのような通信サービスを提供するサービスプロバイダや、その他の通信サービスに関与する主体を含みうる。また、ここでの「ユーザ」は、必ずしも人間である必要はなく、例えばサービスプロバイダによって利用されている情報処理システム等や、無線端末等に含まれるアプリケーションをも含む。すなわち、必ずしも人間が介在する必要はなく、本実施形態に係るシステムに対して指示等の情報を提供し、また、本実施形態に係るシステムから情報を取得する、任意の主体を指して「ユーザ」と呼ぶ。ユーザ装置は、例えば上述のような無線端末であってもよいし、有線通信を実行するネットワーク装置であってもよい。なお、上述のシステムの構成は一例に過ぎず、他の構成が用いられてもよいし、また、他の用途で使用されてもよい。例えば、上述のシステムが５Ｇ以外の無線通信システムや有線通信システムに適用されてもよいし、また、図１と異なる構成によって、後述するような機能を実現するようにしてもよい。

図１のシステムにおいて、ユーザ装置は、オーケストレータに対して、サービス要件を示す情報を送信する。ここでのサービス要件は、そのサービス要件に対応するサービスが提供されるために必要となる通信要件をシステムにおいて特定することができる任意の情報である。オーケストレータは、サービス要件を示す情報を取得すると、通信に関する要件を示す通信要件を特定する。

ここで、同じ通信要件を満たす場合であっても、その通信要件を満たす環境によって、要求される無線リソース（周波数リソース、時間リソース、空間リソース等）の量や、演算リソースの量など、通信に関する各種リソースの消費量を確保することの容易性が異なりうる。例えば、要求されているサービス要件に対応するサービススライスのための無線リソースの多くが既に利用されている状態において新規のサービスのための通信を可能とするには、例えば実行中のサービスのための通信を一時的に停止させて、その新規のサービスのための無線リソースの確保を行う必要がありうる。一方、同じ量の無線リソースを使用するとしても、そのサービス要件に対応するサービススライスのための無線リソースの利用率が低い場合には、既存の通信を一時停止させる等の労力が不要であるため、無線リソースの確保が容易である。また、無線リソースの確保が容易であったとしても、他の通信サービスのための演算が大量に発生している場合等には、新規サービスに関する演算処理を実行するための演算リソースの確保が容易でなくなる。一方、演算リソースの使用率が低い場合には、新規サービスのための演算リソースの確保は容易である。このような、状況に応じてリソースの確保の容易性が変動しうる場合に、そのリソース確保の容易性を高めることができることは、通信事業者にとって有益である。また、リソース確保を容易とすることにより例えば通信料金を下げることができる場合などでは、ユーザにとっても有益となりうる。また、ユーザ装置から通知されたサービス要件に対応する通信要件を満たすことができる場合であっても、ユーザは、どの程度のリソースが使用されるかを知ることはできない。このため、例えばそのサービスを実行するために必要な無線リソースを確保するために必要な料金をユーザが事前に把握することができず、利便性が良くないことが予想される。また、例えば、サービス要件の少なくとも一部を変更することによって使用される無線リソース等のリソースの量が減り、それによって料金が安価になる可能性があるとしても、その可能性をユーザが認識することもできない。

本実施形態の制御装置（オーケストレータ）は、このような事情に鑑み、通知されたサービス要件に対応する通信要件を特定して、その通信要件において要求されるリソースの量と、そのリソースの量に対応して定まる料金とを特定し、その料金の情報をユーザに通知する。これにより、ユーザは、サービスを実行する際に必要な料金を事前に把握することができ、サービスを実行可能であるものの料金が高額に過ぎるために採用できない等の判断を行うことができる。また、オーケストレータは、このときに、通知されたサービス要件に基づく第１の通信要件と共に、その第１の通信要件の代替候補の第２の通信要件を特定し、第１の通信要件のみならず、第２の通信要件についても、料金の情報をユーザに通知する。なお、第１の通信要件に対応する料金が事前にユーザに知られている場合には、第１の通信要件についての料金の通知は行われなくてもよい。また、第２の通信要件についての情報を提供することにより、第２の通信要件に対応する料金が安価である場合、ユーザは、例えば第１の通信要件による通信サービスを実行可能であっても料金が高額に過ぎると判断した場合に、代替案として第２の通信要件によるサービスの実行を決定することができる。オーケストレータは、通知された料金に基づいて第１の通信要件又は第２の通信要件のユーザによる選択を受け付け、選択された通信要件について上述のように特定された要求量のリソースを確保するように、ドメインコントローラを制御する。

このように、サービスの実行の前に、通知されたサービス要件に対応する第１の通信要件と、第１の通信要件と異なる第２の通信要件とについての料金をユーザに通知することで、ユーザ利便性を向上させることができる。また、第２の通信要件を、第１の通信要件の少なくとも一部の要素を緩和したものとすることで、その第２の通信要件が選択された場合にリソース確保の容易性が高まり、通信事業者にも有利となる。さらに、このように事前に料金を通知する仕組みを作ることにより、通信事業者が柔軟に料金を設定することが容易になる。例えば、有限のリソースを運用して各サービスのためのリソースを確保するという観点によれば、リソース確保の容易性に応じて、ユーザに対して請求する料金を変動させる仕組みを有することが通信事業者に有益でありうる。すなわち、例えば、通信事業者は、同じ通信要件での通信を行う条件においても、リソース確保が容易な状態（例えば無線リソースや演算リソースに余裕がある状態）での料金を、リソース確保が容易でない状態での料金より安価に設定する等を決定しうる。この場合、同じ量のリソースを確保するとしても、時間によって料金に変動があるが、通信事業者は、上述のようにして事前にユーザに料金を通知することで、ユーザの承認の下でサービスに関する通信を提供することが可能となる。また、通信事業者は、例えば、通信が継続している時間が長いほど、料金を引き上げるなどの料金設定を行うこともできる。

なお、通信要件は、例えば、許容遅延、許容エラー率、所要無線品質、送信周期、所定期間（例えば月間、週間、一日等）あたりに通信されるデータ量等の、１つ以上の要素を含む。そして、オーケストレータは、通知されたサービス要件に対応してこれらの要素の値をそれぞれ定めた１つの通信要件（第１の通信要件）を定めると共に、これらの要素の少なくとも１つを変更した１つ以上の代替候補の通信要件（第２の通信要件）を特定する。第２の通信要件は、一例において、上述の要素の少なくともいずれかを緩和する要件でありうる。例えば、第２の通信要件は、第１の通信要件と比して、許容遅延が大きいもの、許容エラー率が高いもの、所要無線品質が低いもの、の少なくともいずれかを満たすような要件でありうる。また、第２の通信要件は、第１の通信要件と比して送信周期が長いものや、所定期間あたりに通信されるデータ量の少ないものを含みうる。なお、オーケストレータは、候補となる通信要件をリストとして事前に保持し、サービス要件を受け付けたことに応じて、対応する通信要件と代替候補の通信要件とを特定してもよい。

通信要件のリストの一例を図２に示す。図２のリストでは、複数のＳＬＡ（Service Level Agreement）番号と、それに対する通信要件の各要素の値とが対応付けられる。ＳＬＡ番号は、サービス要件に対応し、オーケストレータは、サービス要件が通知されたことに応じて、そのサービス要件に対応するＳＬＡ番号を検索し、それに対応する通信要件として、第１の通信要件を特定する。例えば、オーケストレータは、通知されたサービス要件がＳＬＡ番号「１００」に対応する場合、許容遅延が１時間、許容エラー率が０．１％、送信周期が４時間、月間データ量が６００ｋＢ、所要無線品質が１０ｄＢという通信要件を、第１の通信要件として特定する。また、オーケストレータは、例えば許容エラー率を緩和したＳＬＡ番号「１０２」に対応する通信要件を、第２の通信要件として特定しうる。また、オーケストレータは、例えば送信周期を緩和したＳＬＡ番号「１０１」に対応する通信要件を、第２の通信要件として特定してもよい。なお、オーケストレータは、例えばＳＬＡ番号「１０１」及び「１０２」の両方についての２つの通信要件を、第２の通信要件として特定してもよい。なお、オーケストレータは、ＳＬＡ番号「２００」～「２０２」等の大幅に異なる通信要件は、第２の通信要件として特定しないように、所定のフィルタリングが用いられてもよい。一例において、各通信要件を類似度に応じてグループ分けしておき、通知されたサービス要件に対応する通信要件を含んだグループに属する他の通信要件の中から、代替候補が選択されるようにしてもよい。この場合、１つの通信要件は、１つのグループのみに属してもよいし、複数のグループに属してもよい。

通信要件のリストは、さらに、各通信要件と、その通信要件が用いられた場合に消費されるリソースの量を特定する情報とを関連付けて保持してもよい。なお、図２のように、１つのリストの中に通信要件と消費リソース量とが保持されてもよいし、通信要件と消費リソース量とは別個のリストに保持されてもよい。なお図２において、消費リソースは、リソースの種別ごとに特定される。例えば、無線リソースと、演算リソースとのそれぞれについての量が、このリストに登録されうる。また、図２では、２つのリソースについてのリソース消費量が登録されている例を示しているが、１つのみ又は３つ以上のリソースについてのリソース消費量が登録されてもよい。例えば、無線リソース及び演算リソースに加えて又はこれらに代えて、トランスポートドメインやモバイルコアドメインのそれぞれについてのリソースについての消費量の情報が登録されてもよい。消費リソース量の値は、例えば事前に実験的に算出された値であってもよいし、オーケストレータが、実際の通信環境において使用されたリソース量を各ドメインコントローラから取得して、逐次更新した値であってもよい。また、図２の例では、消費リソースの量が、使用可能なリソースの量に対する比率で表現される場合の例を示しているが、このような相対的な値ではなく、絶対的な値が用いられてもよい。さらに、図２の例では、複数のタイプのリソースのそれぞれについて消費リソースの量が１つ示されているが、サービスの実行に関与する装置ごと（例えばＲＡＮ装置ごと）に、それぞれ消費するリソース量が定められうる。例えば、装置ごとに利用可能なリソースの量が異なりうるため、同じ通信要件であっても、その比率が異なる場合がありうる。また、第１のＲＡＮ装置と第２のＲＡＮ装置とで、サポートする周波数帯や通信方式が異なりうるため、装置ごとの特性を考慮して、各通信要件を満たすために必要なリソース量が特定されうる。これによれば、オーケストレータは、例えばサービスの提供を受ける端末装置が接続中の基地局装置に基づいて、第１の通信要件を特定しながら、別の基地局装置に端末装置をハンドオーバさせることによって、同じ通信要件をより少ないリソース量で提供可能であるか否かを判断することができる。

オーケストレータは、一例において、通知されたサービス要件に対応する通信要件よりも消費リソース量が減る通信要件を、第２の通信要件として特定しうる。また、オーケストレータは、このときに、複数のタイプのリソースのそれぞれが、既存の他の通信によって既に確保されている量の程度に基づいて、複数の通信要件のうちのいずれを第２の通信要件とするかを決定してもよい。例えば、オーケストレータは、ＳＬＡ番号「１００」の通信要件が第１の通信要件である場合に、リソースＡの余剰リソース量（利用可能なリソースの総量のうちの使用されていないリソース量）が少なく、リソースＢの余剰リソース量が十分に残っている場合、リソースＢの消費量は減らないがリソースＡの消費量が減る、ＳＬＡ番号「１０２」の通信要件を第２の通信要件として決定しうる。同様に、オーケストレータは、リソースＡの余剰リソース量が十分に残っており、リソースＢの余剰リソース量が少ない場合、リソースＡの消費量は減らないがリソースＢの消費量が減る、ＳＬＡ番号「１０１」の通信要件を第２の通信要件として決定しうる。例えば、あるリソースについて、既存の通信のために確保済みのリソース量と、第１の通信要件での通信を実行するとした場合にそのリソースがどの程度使用されるかを示す量との和が所定値を超える場合に、そのリソースの使用量を低減することが可能な通信要件が第２の通信要件として決定されうる。また、リソースＡ及びリソースＢのそれぞれが同程度使用されている場合、リソースの総使用量の低減量が多い通信要件を第２の通信要件として決定してもよい。すなわち、第１の通信要件で通信する場合にどの程度の量のリソースが使用されるかに基づいて、その第１の通信要件よりリソースの消費量が少ない通信要件が、第２の通信要件として決定されうる。なお、リソースＡの余剰リソースが十分に残っており、リソースＢの余剰リソースが相対的に少ない場合には、リソースＡの消費量が増える通信要件が第２の通信要件として選択されてもよい。また、リソースＡ及びリソースＢの余剰リソースが十分に残っている場合には、第１の通信要件より多くのリソースを要求する通信要件を、第２の通信要件として特定してもよい。例えば、オーケストレータは、第１の通信要件の要素の少なくとも一部をさらに厳しくした代替要件を第２の通信要件として決定してもよい。このように、より通信に関する要求を厳格にした要件を通知することで、品質を向上させたサービスの可能性をユーザに提示することができる。例えば、動画提供サービスについて、サービス要件がＨＤ動画相当である場合に、４Ｋ動画の提供を可能とする要件が提示されうる。なお、このような提示を行う場合には、料金は第１の通信要件の料金と同程度に設定されてもよい。なお、オーケストレータは、例えばＳＬＡ番号「１０１」及び「１０２」の両方等の複数の第２の通信要件を決定してもよいが、例えばいずれかのタイプのリソースの余剰量が少ない場合には、そのリソースの使用量が減らない通信要件については、第２の通信要件から除くようにしてもよい。また、オーケストレータは、リソースが既存の通信により大量に確保されている場合には、そのリソースについて確保済みの量が少ない時間帯（例えば深夜から早朝）で通信を行う通信要件を、第２の通信要件として決定してもよい。すなわち、通信要件には、通信を行う時間帯が含まれてもよい。また、オーケストレータは、リソースが既存の通信によって大量に確保されていない場合であっても、第１の通信要件で通信するよりも料金が安くなる時間帯で通信を行う代替要件を、第２の通信要件として特定してもよい。また、オーケストレータは、通知されたサービス要件による通信のために所定の期間にわたって連続してリソースを確保することができない場合には、第１の通信要件に含まれる要素のうち遅延に関する要素が緩和された通信要件を、第２の通信要件としてもよい。

また、オーケストレータは、通信要件に含まれる複数の要素のそれぞれについて優先度を付し、その優先度に基づいて、第１の通信要件のうちのどの要素を緩和するかを決定してもよい。例えば、オーケストレータは、優先度の低い要素を緩和した通信要件を第２の通信要件として特定しうる。なお、オーケストレータは、例えば、最も優先度の低い要素を緩和したとしてもリソース消費量の減少量が不十分である（例えば所定量以下である）場合、２番目に優先度の低い要素を緩和した通信要件についてリソース消費量を特定する。そして、オーケストレータは、そのリソース消費量の減少量が十分である（例えば所定量を超える）場合には、その通信要件を第２の通信要件として特定しうる。また、オーケストレータは、２番目に優先度の低い要素を緩和してもリソース消費量の減少量が不十分である場合には、３番目に優先度の低い要素の緩和や、優先度が１番目及び２番目に低い２つの要素の緩和により、リソース消費量が十分に低減するか否かを判定してもよい。このように、オーケストレータは、優先度の低い要素から順に緩和してリソース消費量が低減するか否かを判断してもよい。なお、優先度の情報は、ユーザ（サービスプロバイダ又はエンドユーザ）によって指定されてもよいし、システム内で事前に定められていてもよい。また、通信要件の候補に優先順位が付され、その優先順位に従って、第２の通信要件が特定されてもよい。例えば、第１の通信要件としていずれの通信要件が特定されるかに応じて他の通信要件の（代替候補としての）優先順位が定まる、条件付き優先順位が事前に設定されうる。この場合、オーケストレータは、第１の通信要件を特定した後に、その第１の通信要件に応じて事前設定された優先順位を参照し、優先順位の高い方から所定数の通信要件を第２の通信要件として特定してもよい。なお、この場合に、リソースの消費量が所定量以上減少しない通信要件については、優先順位が高いものであっても、第２の通信要件として特定されなくてもよい。

なお、オーケストレータは、第１の通信要件及び第２の通信要件のそれぞれについて必要なリソース量を、上述のように事前にリストとして保持してもよいし、各ドメインコントローラに対して問い合わせることにより取得してもよい。また、既に使用されているリソースの量の情報は、オーケストレータが各ドメインコントローラに問い合わせることによって取得されてもよいし、各ドメインコントローラが周期的にオーケストレータに通知するようにしてもよい。オーケストレータは、ユーザからユーザ装置を介して受け付けたサービス要件を取得し、そのサービス要件に基づいて第１の通信要件と少なくとも１つの第２の通信要件とを特定し、それらの通信要件のそれぞれについて要求されるリソースの量と、そのリソースの量に対応して定まる料金とを特定し、それらの通信要件と対応する料金とをユーザに通知して、どの通信要件を使用するかの選択を受け付けることができるように構成される。このような動作が可能である限りにおいて、他の装置との関係はどのように構築されてもよい。また、オーケストレータの機能は１つの制御装置によって実現されてもよいし、上述の各処理を分担する複数の装置によって実現されてもよい。

なお、上述の第２の通信要件は、例えば、第１の通信要件から処理を実行する主体を変更するものであってもよい。例えば、第２の通信要件においては、第１の通信要件と異なる周波数帯／時間／空間等の無線リソースや、異なる演算装置を用いられうる。一例において、サービスの提供を受ける端末装置が、周波数帯や接続先のセルを変更することにより、相対的に余剰リソースに余裕のある無線リソースを利用可能である場合、オーケストレータは、そのような周波数帯や接続先のセルを変更する通信要件を第２の通信要件として特定しうる。オーケストレータは、この通信要件によって、無線リソースの使用量を削減することができないとしても、相対的に余剰リソースに余裕のある無線リソースを使用することで、システムの安定化やシステム全体の無線リソースの利用効率を向上させることができる。このため、オーケストレータは、この通信要件については、無線リソースの使用量を削減することができなくても、第２の通信要件として特定しうる。また、オーケストレータは、その際に通知する料金を、第１の通信要件より安価に設定してもよい。また、サービスを実行するための演算処理の少なくとも一部を実行可能であって低負荷状態の、第１の通信要件では用いられることが想定されていない演算装置が存在する場合に、オーケストレータは、その演算装置を用いる通信要件を第２の通信要件として特定しうる。この場合も、相対的に余剰リソースに余裕のある演算リソースを使用することで、システムの安定化やシステム全体の無線リソースの利用効率を向上させることができる。このため、オーケストレータは、この通信要件については、演算リソースの使用量を削減することができなくても、第２の通信要件として特定してもよく、また、その際に通知する料金を、第１の通信要件より安価に設定してもよい。なお、第１の通信要件の少なくとも一部の要件を緩和することにより、他の無線リソースや他の演算装置を使用する代替候補を多く特定することが可能となり、システムにおけるリソースの有効活用を図ることが可能となる。

オーケストレータは、所定の条件が満たされない場合には、上述の第２の通信要件をユーザに通知しないようにしてもよい。所定の条件は、例えば、サービス要件が新規に受け付けられたものであることを含みうる。すなわち、サービス要件が新規に受け付けられたものでない場合には、第２の通信要件がユーザに通知されなくてもよい。また、所定の条件は、例えば、利用可能なリソースのうち使用されていない量のリソースにより第１の通信要件での通信を実行可能でないことを含みうる。すなわち、利用可能なリソースのうち使用されていない量のリソースにより第１の通信要件による通信を実行可能である場合には第２の通信要件がユーザに通知されなくてもよい。また、所定の条件は、例えば、利用可能なリソースのうち使用されていない量が所定量以下であることを含んでもよい。すなわち、利用可能なリソースのうち使用されていない量が所定量を超える場合には、第２の通信要件がユーザに通知されなくてもよい。また、所定の条件は、第２の通信要件に関する情報の通知をユーザが要求したことを含みうる。すなわち、第２の通信要件に関する情報の通知をユーザが要求していない場合には、第２の通信要件がユーザに通知されなくてもよい。例えば、ユーザが第１の通信要件に対応して通知された料金を承認せず、他の通信要件及び料金の通知を求めた場合にのみ、第２の通信要件が通知されてもよい。また、例えば、ユーザが、リソースの消費量が過剰であると判断し、リソースの消費量を削減するために第２の通信要件を要求した場合等に、第２の通信要件が通知されるようにしてもよい。なお、この場合、オーケストレータは、ユーザに対して、リソースの使用状況や予約状況をユーザに通知するように動作しうる。また、所定の条件は、利用可能なリソースのうち使用されていないリソースの量が変化したことを含みうる。すなわち、利用可能なリソースのうちの使用されていないリソースの量が変化していない間は第２の通信要件がユーザに通知されなくてもよい。なお、このときに、利用可能なリソースのうちの使用されていないリソースの量が変化していても、その変化によって所定値を上回った又は下回った場合以外は、第２の通信要件がユーザに通知されないようにしうる。

上述の所定の条件は一例に過ぎず、上述の条件の一部が所定の条件に含まれなくてもよいし、他の条件が所定の条件に含まれてもよい。オーケストレータは、設定された所定の条件のいずれか又はその組み合わせが満たされる場合には、第２の通信要件をユーザに通知するようにしうる。例えば、通信を実行中の端末装置が移動したこと等によって利用可能なリソースのうちで使用されていないリソースの量が変化した場合には、他の所定の条件が満たされていない場合であっても第２の通信要件をユーザに通知するようにしうる。なお、オーケストレータは、利用可能なリソースのうちで使用されていないリソースの量が変化した場合であっても、他の所定の条件の一部または全部が満たされていない限りは第２の通信要件をユーザに通知しなくてもよい。また、上述のような所定の条件を用いなくてもよい。例えば、空きリソースの量によらずに第２の通信要件をユーザに通知してもよい。また、オーケストレータは、所定の条件を満たす場合であっても、適切な第２の通信要件がない場合（例えば使用リソース量が削減される代替候補がない場合）には、第２の通信要件をユーザに通知しなくてもよい。

オーケストレータは、上述のように、新規にサービスを実行するためにサービス要件を提示したユーザに対して、そのサービス要件に対応する第１の通信要件と代替候補である第２の通信要件とを通知することができるが、既存の通信を行っている他のユーザに対して代替候補の通信要件を通知してもよい。すなわち、新規にサービスを実行するユーザに対してのみならず、既にサービスを実行中のユーザに対して、現在使用されている第３の通信要件の代替候補の第４の通信要件を通知しうる。例えば、リソースの使用量が最も多い端末装置やリソースの予約期間が（例えば所定長より）長い端末装置のユーザに対して、使用リソースを低減するための第４の通信要件を通知しうる。これによれば、リソースを多量に使用する又は予約している通信について、使用リソースを低減し、ユーザ間で公平にリソースを利用することができるようになる。なお、リソースの使用量が多く又はリソースの予約期間が長い端末装置のユーザであっても、実行中のサービスの種類によっては、第４の通信要件の通知対象から除かれてもよい。例えば、優先度の高いサービスが実行中である場合、そのサービスのユーザについては、第４の通信要件を通知せずに第３の通信要件を継続して使用するようにしてもよい。なお、既存の通信に関して第４の通信要件が通知される場合、上述の新規の通信に関する第２の通信要件は通知されなくてもよいし、通知されてもよい。すなわち、新規の通信についてはサービス要件を充足可能な通信要件を用いると共に既存の通信についてはその一部の要素を緩和した通信要件を用いるようにしてもよいし、既存の通信と新規の通信との双方で通信要件を緩和することにより、それぞれの通信要件の緩和の程度を小さく抑えるようにしてもよい。

上述のようにして、オーケストレータは、通知されたサービス要件に対応する第１の通信要件に加えて、第２の通信要件を、料金と共にユーザに通知する。これにより、ユーザに対してサービスの質と料金とのトレードオフの関係を認識させ、よりユーザの意図に沿った通信サービスを提供することが可能となる。例えば、動画視聴サービスについてのサービス要件がユーザによって提示された場合に、オーケストレータは、ユーザの要求に沿った画質でのサービスと、相対的に低画質とするサービスとのそれぞれについて、料金をユーザに通知しうる。また、トラッキングサービスについて、ユーザの要求に沿った通信頻度でのサービスと、通信頻度を下げて提供されるサービスとのそれぞれについて、料金をユーザに通知しうる。また、ナビゲーションサービスにおいて、ユーザの要求に沿った高精度な移動ルートの選択サービスを行う場合と、それより精度が低い又は候補の数が少ない、すなわち、演算リソースの少ないサービスを行う場合とのそれぞれについて、料金をユーザに通知しうる。これ以外にも、様々な用途において、ユーザが提示したサービス要件に対応する通信要件と、緩和された通信要件とに基づいて、ユーザに選択肢を与え、ユーザが適切な通信要件を選択することにより、ユーザ利便性が向上し、ユーザの満足度を向上させることができる。

なお、上述の実施形態では、新規のサービスを開始する際の処理について説明したが、これに限られない。例えば、実行中のサービスについて、追加のサービス要件が指定される場合にも、上述の処理を適用することができる。この場合、その追加のサービス要件に対応する通信要件と、その通信要件で要求されるリソースの量とが特定され、そのリソースの量に応じた料金も特定される。なお、オーケストレータは、例えば追加されたサービス要件に対応する通信要件での通信をリソース不足等の要因によって実現できないと判定した場合、ユーザに対してサービス要件を満たすことができないことと、代替の通信要件（第２の通信要件）を通知することができる。

また、オーケストレータは、１つのドメイン（例えばＲＡＮドメイン）で通信要件を満たせない場合に、他のドメイン（トランスポートドメイン、モバイルコアドメイン）における通信要件を厳しくすることにより、ネットワーク全体で通信要件を満たすことができるか否かを判定しうる。例えば、オーケストレータは、サービス要件を受け付けた場合に、それに対応する通信要件を満たすことができるかを各ドメインコントローラに対して問い合わせ、一部のドメインコントローラから通信要件の一部の要素を満たすことができないことの通知を受信したとする。この場合、オーケストレータは、他のドメインコントローラに対して、少なくともその一部の要素を厳しく設定することが可能であるかをさらに問い合わせる。そして、オーケストレータは、そのような設定が可能であるとの応答を受信した場合に、ユーザから通知されたサービス要件を充足する通信を行うことが可能であると判定してもよい。なお、オーケストレータは、このようなドメイン間の調停を行ってもよいし、そのような調停を行わなくてもよい。

（装置構成）
続いて、オーケストレータ（制御装置）の構成について説明する。図３は、オーケストレータのハードウェア構成例を示す図である。オーケストレータは、一例において、プロセッサ３０１、ＲＯＭ３０２、ＲＡＭ３０３、記憶装置３０４、及び通信回路３０５を含んで構成される。プロセッサ３０１は、汎用のＣＰＵ（中央演算装置）や、ＡＳＩＣ（特定用途向け集積回路）等の、１つ以上の処理回路を含んで構成されるコンピュータであり、ＲＯＭ３０２や記憶装置３０４に記憶されているプログラムを読み出して実行することにより、装置全体の処理や、上述の各処理を実行する。ＲＯＭ３０２は、オーケストレータが実行する処理に関するプログラムや各種パラメータ等の情報を記憶する読み出し専用メモリである。ＲＡＭ３０３は、プロセッサ３０１がプログラムを実行する際のワークスペースとして機能し、また、一時的な情報を記憶するランダムアクセスメモリである。記憶装置３０４は、例えば着脱可能な外部記憶装置等によって構成される。通信回路３０５は、例えば、有線通信又は無線通信用の回路によって構成される。オーケストレータは、各ドメインコントローラやユーザ装置との（有線または無線）通信を実行するためのネットワーク接続用の回路を含みうる。なお、図３では、１つの通信回路３０５が図示されているが、各装置は、複数の通信回路を有しうる。

図４に、オーケストレータの機能構成例を示す。オーケストレータは、その機能として、例えば、サービス要件受付部４０１、通信要件特定部４０２、料金特定部４０３、情報通知部４０４、選択受付部４０５、及び通信制御部４０６を有する。

サービス要件受付部４０１は、ユーザ装置から、実行するサービスについてのサービス要件の情報を受け付ける。サービス要件受付部４０１は、例えば、エンドユーザの端末装置またはサービスプロバイダが利用する情報処理装置等から、サービス要件の情報を受け付ける。一例において、エンドユーザの端末装置が、サービスプロバイダに対して通信を伴うサービスの実行を要求し、サービスプロバイダがそのサービスについてのサービス要件をオーケストレータへ通知しうる。なお、エンドユーザの端末装置は、サービスの実行要求の際に、サービスプロバイダが提供するサービスのうちのいずれの提供を要求するかを特定する情報を通知し、サービスプロバイダは、その情報に基づいてサービス要件を特定して、オーケストレータへ通知しうる。また、エンドユーザの端末装置は、サービス要件が事前に定まっている所定の通信サービスを実行することをオーケストレータに通知してもよい。なお、サービス要件受付部４０１は、新規のサービスについてのサービス要件のみならず、既存のサービスについての追加のサービス要件を受け付けてもよい。

通信要件特定部４０２は、サービス要件受付部４０１によって受け付けられたサービス要件に対応する第１の通信要件と、第１の通信要件の代替候補となる少なくとも１つの第２の通信要件とを特定する。料金特定部４０３は、通信要件特定部４０２で特定された第１の通信要件及び第２の通信要件のそれぞれについて、必要となるリソースの量を特定し、そのリソースの量に対応して定まる料金とを特定する。なお、これらの特定の方法については、上述の通りであるため、ここではその説明については省略する。情報通知部４０４は、通信要件特定部４０２で特定された通信要件を示す情報と、その通信要件について料金特定部４０３で特定された料金の情報とを、サービス要件受付部４０１を介してサービス要件を提示したユーザへ通知する。

なお、通信要件特定部４０２は、サービス要件受付部４０１によって受け付けられたサービス要件に対応する第１の通信要件を特定した後に、実行中（既存）のサービスについての第３の通信要件に対する代替候補である少なくとも１つの第４の通信要件を特定しうる。この場合、料金特定部４０３も、その第４の通信要件についての料金を特定し、情報通知部４０４は、その実行中のサービスのユーザ（エンドユーザ又はサービスプロバイダ）に対して、第４の通信要件と対応する料金との情報を通知してもよい。すなわち、情報通知部４０４は、サービス要件受付部４０１を介してサービス要件を提示したユーザと異なるユーザに対して、情報を通知してもよい。なお、第４の通信要件が通知される場合には第２の通信要件は特定／通知されなくてもよいし、第２の通信要件と第４の通信要件とが共に特定／通知されてもよい。

選択受付部４０５は、情報通知部４０４によってユーザに通知された通信要件のうち、どの通信要件がユーザに選択されたかを示す情報を、上述の通信要件を通知した先のユーザ装置（または、そのユーザ装置と事前にユーザアカウント等で関連付けられた他の装置）から取得する。通信制御部４０６は、選択受付部４０５によって受け付けられた選択に応じて、選択された通信要件での通信を行うように各ドメインコントローラを制御する。各ドメインコントローラは、この制御の下で、配下の装置を制御して、サービス提供先の端末装置に対する通信を実行させる。

（処理の流れ）
続いて、本実施形態に係る処理の流れについて、図５を用いて概説する。なお、図５は、ユーザ装置が新規にサービスを開始する場合に、そのユーザ装置に第１の通信要件と代替候補の第２の通信要件とを通知する場合の例を示している。ただし、上述のように、本実施形態はそれに限定されず、実行中の通信についての代替候補の通信要件を特定してその通信に係るユーザ装置に対して、その代替候補の通信要件を通知してもよい。

本処理では、まず、ユーザ装置（例えばエンドユーザの端末装置やネットワークオペレータの情報処理装置）が、オーケストレータに対してサービス要件（要求するサービスレベル）を通知する。そして、オーケストレータは、通知されたサービス要件に対応する通信要件として第１の通信要件を特定し、さらに、その第１の通信要件の代替候補である少なくとも１つの第２の通信要件を特定する。例えば、第１の通信要件に含まれる要素の少なくとも一部を緩和して、要求されるリソース量が所定量以上減る通信要件が、第２の通信要件として特定される。なお、上述のように、これ以外の様々な観点で第２の通信要件が特定される。なお、新規のサービスに対する通信要件についての代替要件に代えて又はこれに加えて、実行中の通信において用いられている通信要件についての代替要件が特定されてもよい。

そして、オーケストレータは、特定した代替要件について、要求されるリソース（例えば無線リソースや演算リソース）の量を特定する。このとき、オーケストレータは、図２のようなリストにおいて事前に特定されたリソース使用量を要求されるリソースの量として用いてもよいし、図５に示すように、ドメインコントローラに問い合わせることによって要求されるリソースの量を特定してもよい。図５では、オーケストレータは、特定した第１の通信要件と第２の通信要件とをドメインコントローラへ送信し、ドメインコントローラに使用リソース量の推定を依頼する。そして、ドメインコントローラは、そのドメインにおける通信処理を実行する装置（ＲＡＮドメインにおけるＲＡＮ装置、トランスポートドメインにおけるトランスポート装置、モバイルコアドメインにおけるモバイルコア装置等）と協働して、使用されるリソースの量を特定する。そして、ドメインコントローラは、その特定したリソース使用量をオーケストレータに通知する。なお、ドメインコントローラは、配下に複数の装置が存在する場合等、複数の方法で通信要件を充足することができる場合には、１つの通信要件について、使用リソース量の複数のパターンを特定して、オーケストレータに通知してもよい。例えば、第１のパターンにおいては、無線リソースの消費が大きいが演算リソースの消費が少なく、第２のパターンにおいては、演算リソースの消費が大きいが無線リソースの消費が小さい、等のパターンがオーケストレータに通知されうる。なお、ここで特定されるリソース使用量は、サービスが実行される期間が長いほど当然に多くなりうる。すなわち、リソース使用量は、一連のサービスの終了までのリソース量として特定されうる。ただし、これに限られず、例えば、所定期間あたりのリソース使用量が特定されてもよい。

その後、オーケストレータは、特定したリソース量に対応する料金を特定する。このとき、例えば、既存の通信による使用率の高いタイプのリソースについては使用量当たりの料金を高く設定し、使用率の低いタイプのリソースについては使用量当たりの料金を低く設定するなど、柔軟な料金設定がなされうる。また、長期間にわたってリソースを確保する必要があるほど料金が高くするなどの料金設定が行われてもよい。オーケストレータは、料金設定に従って、第１の通信要件と第２の通信要件とのそれぞれについての料金を特定する。なお、上述のように、１つの通信要件についてリソース使用量の複数のパターンが特定された場合は、それぞれのパターンについての料金が特定されうる。そして、オーケストレータは、例えば、それらのパターンの中で料金が最低となるパターンを、その通信要件に対するリソース使用量として特定しうる。なお、オーケストレータは、複数のパターンのうち、通信サービスの安定化に最も資するパターンを、その通信要件に対するリソース使用量として特定してもよい。すなわち、オーケストレータは、１つの通信要件に対してリソース使用量の複数のパターンが存在する場合に、通信事業者にとって都合のよいパターンを選択するようにしてもよい。なお、この場合、オーケストレータは、通信事業者にとって都合のよいパターンを選択しながら、複数のパターンに対応する料金のうち、最も安い料金を、その通信要件に対応する料金として特定してもよい。これによれば、通信事業者にとって都合のよいパターンでの通信が行われることに対してインセンティブを付すことができる。

オーケストレータは、料金を特定すると、第１の通信要件及び第２の通信要件と、それらの対応する料金とをユーザ装置に通知する。なお、実行中の通信に関する第４の通信要件が特定された場合には、その実行中の通信に係るユーザ装置に対して、第４の通信要件と料金とを通知しうる。なお、オーケストレータは、例えば、第１の通信要件及び第２の通信要件を通知せず、第２の通信要件に関する情報のみを通知してもよい。このとき、第１の通信要件と異なる部分のみが第２の通信要件として通知されてもよい。例えば、オーケストレータは、第２の通信要件が第１の通信要件と比して、遅延要件を緩和したものである、等の情報をユーザ装置に通知する。ユーザ装置は、この情報を受信した場合、サービス要件に対応する通信要件を用いる場合の料金と、遅延要件が緩和された場合に料金がどの程度まで下がるか等を示す情報を、例えば画面表示等を通じてユーザに通知しうる。そして、ユーザは、通知された情報に基づいて、どの通信要件を選択するかを決定する。なお、ユーザは、通知された要件の全てを拒否してもよく、この場合、処理は、通信要件の特定まで戻る。なお、オーケストレータは、実現可能な全ての通信要件についてユーザによって拒否された場合は、ユーザから通知されたサービス要件を充足することはできないことをユーザ装置に通知して処理を終了しうる。

オーケストレータは、使用する通信要件のユーザ選択を受け付けると、その選択された通信要件での通信のためにリソースを確保するように、ドメインコントローラを制御する制御信号を送信する。ドメインコントローラは、この信号に従って、配下の装置を制御して、リソースを確保し、要求されたサービスに関する通信を開始する。

なお、上述の説明では、サービス要件に基づいて特定された複数の通信要件のそれぞれについて、要求されるリソースの量に対して定まる料金の情報をユーザへ通知するとしたがこれに限られない。例えば、事前に定額を支払うという契約をユーザとの間で締結していた場合は、どの程度のリソースの量が使用されるかのカウンタ値が特定されてそのユーザに通知されてもよい。また、使用可能なリソースの量に応じたポイントをユーザが購入する形式の契約が行われる場合、リソースの使用量に応じたポイント消費量等の情報をユーザに通知するようにしてもよい。すなわち、料金の情報は、使用されるリソースの量に関連する情報の一態様に過ぎず、それ以外の形式で、各通信要件について要求されるリソースの量に関連する情報がユーザに通知されうる。このとき、各通信要件について要求されるリソースの量に関連する情報は、料金やポイント等のユーザに対して要求される対価に関連する情報であってもよいし、定額制契約時に利用されるリソースの量のカウンタなど、対価とは無関係な情報であってもよい。

以上のようにして、本実施形態によれば、サービス要件を提示したユーザに対して、そのサービス要件での通信の可否のみならず、その通信に要するリソースの量に関連する情報や、代替の通信要件とそれが用いられた場合のリソースの量に関連する情報を提示する。これにより、ユーザに対して様々な選択肢を与えることができ、ユーザ利便性の向上を図ることが可能となる。

Claims (19)

1. ユーザから受け付けたサービス要件に基づいて前記ユーザに関連付けられた通信装置とネットワークとの間の通信に関する第１の通信要件を特定すると共に、前記第１の通信要件の代替候補の前記通信装置と前記ネットワークとの間の通信に関する第２の通信要件を特定する第１の特定手段と、
   前記第１の通信要件および前記第２の通信要件のそれぞれが満たされるように前記通信装置と前記ネットワークとの間の通信が行われる場合に要求される、無線リソースと演算リソースとを含んだリソースの量を、通信要件と要求されるリソースの量とを関連付けた情報を参照することにより特定する第２の特定手段と、
   前記第２の通信要件を示す情報と、前記第１の通信要件および前記第２の通信要件のそれぞれについて特定された前記リソースの量に関連する情報とを前記ユーザへ通知する通知手段と、
   前記第１の通信要件または前記第２の通信要件の前記ユーザによる選択を受け付ける受付手段と、
   前記ユーザによって選択された通信要件について特定された前記リソースの量を、当該リソースを用いた前記通信装置と前記ネットワークとの間の通信処理を制御する装置に確保させるための制御を実行する制御手段と、
   を有することを特徴とする制御装置。
2. 前記第１の通信要件および前記第２の通信要件は、それぞれ優先度が付された複数の要素を含み、
   前記第１の特定手段は、前記優先度に基づいて、前記第１の通信要件の前記複数の要素の少なくともいずれかが緩和された通信要件として、前記第２の通信要件を特定する、
   ことを特徴とする請求項１に記載の制御装置。
3. 前記複数の要素についての前記優先度はユーザによって指定される、
   ことを特徴とする請求項２に記載の制御装置。
4. 前記リソースは第１のタイプのリソースおよび第２のタイプのリソースを含み、
   前記第１の特定手段は、前記第１のタイプのリソースおよび前記第２のタイプのリソースのそれぞれが前記第２の通信要件によってどの程度の量だけ使用されるかに基づいて、前記第２の通信要件を特定する、
   ことを特徴とする請求項１から３のいずれか１項に記載の制御装置。
5. 前記第１の特定手段は、前記第１のタイプのリソースおよび前記第２のタイプのリソースのそれぞれが前記第１の通信要件によってどの程度の量だけ使用されるかにさらに基づいて、前記第２の通信要件を特定する、
   ことを特徴とする請求項４に記載の制御装置。
6. 前記第１の特定手段は、前記第１のタイプのリソースおよび前記第２のタイプのリソースのそれぞれが既に確保されている量の程度にさらに基づいて、前記第２の通信要件を特定する、
   ことを特徴とする請求項４に記載の制御装置。
7. 前記第１の特定手段は、前記第１のタイプのリソースと前記第２のタイプのリソースとの少なくともいずれかが既に確保されている量の程度が低い時間帯で通信を行う要件を、前記第２の通信要件として特定する、
   ことを特徴とする請求項６に記載の制御装置。
8. 前記第１の特定手段は、所定の期間にわたって連続してリソースを確保することができない場合、前記第１の通信要件の遅延に関する要素が緩和された通信要件として、前記第２の通信要件を特定する、
   ことを特徴とする請求項１から７のいずれか１項に記載の制御装置。
9. 複数の通信要件に対して優先順位が事前に定められ、
   前記第１の特定手段は、前記優先順位に従って、前記複数の通信要件の中から前記第２の通信要件を特定する、
   ことを特徴とする請求項１から８のいずれか１項に記載の制御装置。
10. 前記第１の特定手段は、前記第１の通信要件において要求されるリソースの量より少ない量のリソースを要求する通信要件を、前記第２の通信要件として特定する、
    ことを特徴とする請求項１から９のいずれか１項に記載の制御装置。
11. 前記第１の特定手段は、前記第１の通信要件で通信が行われる時間帯と異なる時間帯であると共に当該第１の通信要件で通信が行われるより料金が安くなる時間帯で通信を行う通信要件を、前記第２の通信要件として特定する、
    ことを特徴とする請求項１から１０のいずれか１項に記載の制御装置。
12. 前記第１の特定手段は、利用可能なリソースのうち使用されていない量が第１の所定量以上である場合、前記第１の通信要件より多くのリソースを要求する通信要件を、前記第２の通信要件として特定する、
    ことを特徴とする請求項１から１１のいずれか１項に記載の制御装置。
13. 前記通知手段は、所定の条件を満たさない場合に、前記第２の通信要件の情報を前記ユーザへ通知しないように構成され、
    前記所定の条件は、前記サービス要件が新規に受け付けられたものであること、利用可能なリソースのうち使用されていない量のリソースにより前記第１の通信要件による通信を実行可能でないこと、利用可能なリソースのうち使用されていない量が第２の所定量以下であること、前記第２の通信要件に関する情報の通知を前記ユーザが要求したこと、利用可能なリソースのうち使用されていないリソースの量が変化したこと、の少なくともいずれかを含む、
    ことを特徴とする請求項１から１２のいずれか１項に記載の制御装置。
14. 前記第１の特定手段は、他のユーザのサービスのための通信における第３の通信要件に対する代替要件である第４の通信要件を特定し、
    前記通知手段は、前記他のユーザに対して、前記第４の通信要件に関する情報を通知する、
    ことを特徴とする請求項１から１０のいずれか１項に記載の制御装置。
15. 前記通知手段は、前記他のユーザに対して前記第４の通信要件に関する情報を通知する場合、前記ユーザに対して前記第２の通信要件に関する情報を通知しない、
    ことを特徴とする請求項１４に記載の制御装置。
16. 前記他のユーザは、リソースの使用量とリソースの予約期間と当該他のユーザのサービス要件との少なくともいずれかに基づいて決定される、
    ことを特徴とする請求項１４又は１５に記載の制御装置。
17. 前記通知手段は、利用可能なリソースのうち使用されていないリソースの量が変化した場合に、前記第２の通信要件に関する情報を前記ユーザへ通知する、
    ことを特徴とする請求項１から１６のいずれか１項に記載の制御装置。
18. 制御装置によって実行される制御方法であって、
    ユーザから受け付けたサービス要件に基づいて前記ユーザに関連付けられた通信装置とネットワークとの間の通信に関する第１の通信要件を特定すると共に、前記第１の通信要件の代替候補の前記通信装置と前記ネットワークとの間の通信に関する第２の通信要件を特定する第１の特定工程と、
    前記第１の通信要件および前記第２の通信要件のそれぞれが満たされるように前記通信装置と前記ネットワークとの間の通信が行われる場合に要求される、無線リソースと演算リソースとを含んだリソースの量を、通信要件と要求されるリソースの量とを関連付けた情報を参照することにより特定する第２の特定工程と、
    前記第２の通信要件を示す情報と、前記第１の通信要件および前記第２の通信要件のそれぞれについて特定された前記リソースの量に関連する情報とを前記ユーザへ通知する通知工程と、
    前記第１の通信要件または前記第２の通信要件の前記ユーザによる選択を受け付ける受付工程と、
    前記ユーザによって選択された通信要件について特定された前記リソースの量を、当該リソースを用いた前記通信装置と前記ネットワークとの間の通信処理を制御する装置に確保させるための制御を実行する制御工程と、
    を有することを特徴とする制御方法。
19. 制御装置に備えられたコンピュータに、
    ユーザから受け付けたサービス要件に基づいて前記ユーザに関連付けられた通信装置とネットワークとの間の通信に関する第１の通信要件を特定させると共に、前記第１の通信要件の代替候補の前記通信装置と前記ネットワークとの間の通信に関する第２の通信要件を特定させ、
    前記第１の通信要件および前記第２の通信要件のそれぞれが満たされるように前記通信装置と前記ネットワークとの間の通信が行われる場合に要求される、無線リソースと演算リソースとを含んだリソースの量を、通信要件と要求されるリソースの量とを関連付けた情報を参照することにより特定させ、
    前記第２の通信要件を示す情報と、前記第１の通信要件および前記第２の通信要件のそれぞれについて特定された前記リソースの量に関連する情報とを前記ユーザへ通知させ、
    前記第１の通信要件または前記第２の通信要件の前記ユーザによる選択を受け付けさせ、
    前記ユーザによって選択された通信要件について特定された前記リソースの量を、当該リソースを用いた前記通信装置と前記ネットワークとの間の通信処理を制御する装置に確保させるための制御を実行させる、
    ためのプログラム。

Images