JP7632466B2 - 通信システムにおける制御装置、および、その制御方法 - Google Patents

Description

本技術は、通信システムにおける制御装置に関する。詳しくは、通信システムにおいて使用可能なリソースを管理する制御装置、および、その制御方法に関する。

セルラーネットワークは、ＲＡＮ（Radio Access Network）とコアネットワーク（ＣＮ：Core Network）から構成されている。ＲＡＮは、基地局（ＢＳ：Base Station）と端末（ＵＥ：User Equipment）の間の無線システムである。コアネットワークは、端末がネットワークへ接続する際の許可やセッション管理を主に行っている。４Ｇおよび５Ｇにおいて、コアネットワークは、コントロールプレーンファンクション（ＣＰＦ：Control Plane Function）、および、ユーザプレーンファンクション（ＵＰＦ：User Plane Function）により構成される。端末がネットワークに接続してデータの送受信を行う場合には、コアネットワークのユーザプレーンの機能が必要となる。４Ｇの場合には、ＳＧＷやＰＧＷがこの役割を果たす。５Ｇの場合には、ユーザプレーンファンクションがこの役割を果たす。

端末にユーザプレーンを割り当てるために、４Ｇでは、セレクションファンクション（Selection Function）が、ネットワークにアタッチしてきた端末に対して、どのＳＧＷおよびＰＧＷを割り当てるかを、その時のネットワークの状況に応じて決定する。そして、その情報に基づいて、ＭＭＥからの要請として、基地局とＳＧＷおよびＰＧＷとの間にＧＴＰトンネルという土管を設ける。ここで、ＰＧＷは、端末が設定したＡＰＮに基づいて選択される。また、ＳＧＷは、端末の地理的な場所により選択される（例えば、非特許文献１参照。）。

また、５Ｇでは、ＮＳＳＡＩ（Network Slice Selection Assistance Information）という情報を端末に提供して、どのネットワークスライスの選択が可能であるかを端末に提供する。ＮＳＳＦ（Network Slice Selection Function）は、端末が選択したネットワークスライスに対応するユーザプレーンファンクションを、その端末に割り当てる（例えば、非特許文献２参照。）。

３ＧＰＰ ＴＳ２３．４０１、セクション４．３．８ ３ＧＰＰ ＴＳ２３．５０１、セクション５．１５

上述の従来技術において、端末の数に応じてスループットを確保するためには、端末の数の変動に応じてユーザプレーンの数を増減させることが有用である。しかしながら、上述の従来技術では、ユーザプレーンの数を柔軟に増減させることは難しい。特に、近年の局所的なセルラシステムのためのコアネットワークでは低コストによる実現が必要であり、複雑な仕組みを設けることは好ましくない。

本技術はこのような状況に鑑みて生み出されたものであり、通信システムにおけるユーザプレーンの数を柔軟に制御することを目的とする。

本技術は、上述の問題点を解消するためになされたものであり、その第１の側面は、ローカルエリアネットワークに配置された基地局とクラウドに配置された少なくとも１つのユーザプレーンファンクションとが接続される通信システムにおいて、上記ローカルエリアネットワークによる最大トラフィック量のうち、上記少なくとも１つのユーザプレーンファンクションが上記ローカルエリアネットワークを利用して転送するユーザデータのトラフィック量と、新たなユーザプレーンファンクションの想定トラフィック量とを考慮して、上記新たなユーザプレーンファンクションを追加すべきか否かを判断する制御装置およびその制御方法である。これにより、ローカルエリアネットワークによる最大トラフィック量において新たなユーザプレーンファンクションに利用可能なトラフィック量を考慮して、新たなユーザプレーンファンクションを追加すべきか否かを判断するという作用をもたらす。

また、この第１の側面において、上記少なくとも１つのユーザプレーンファンクションのうちの対象ユーザプレーンファンクションの処理使用率が所定の閾値を超えた場合に、上記新たなユーザプレーンファンクションを追加すべきか否かの判断を行うようにしてもよい。これにより、動作中のユーザプレーンファンクションの処理使用率が高くなった際に新たなユーザプレーンファンクションを追加すべきか否かを判断するという作用をもたらす。

また、この第１の側面において、上記対象ユーザプレーンファンクションの処理使用率は、上記対象ユーザプレーンファンクションの現在の処理容量を上記対象ユーザプレーンファンクションの想定トラフィック量で除算することにより得られる値を想定する。

また、この第１の側面において、上記対象ユーザプレーンファンクションの処理使用率は、上記対象ユーザプレーンファンクションにおける処理遅延が大きいほど上記対象ユーザプレーンファンクションの処理使用率が高いものとして計算される値を想定する。

また、この第１の側面において、上記ローカルエリアネットワークによる最大トラフィック量は、上記少なくとも１つのユーザプレーンファンクション毎に測定された、上記ローカルエリアネットワークに配置されたエンティティとのトラフィック量の最大値を想定する。

また、この第１の側面において、上記ユーザデータのトラフィック量は、上記少なくとも１つのユーザプレーンファンクション毎に測定された、上記基地局を介した端末によるトラフィック量の総計を想定する。

また、この第１の側面において、上記ローカルエリアネットワークによる最大トラフィック量からトラフィック増加余地容量を算出して、上記トラフィック増加余地容量を上記新たなユーザプレーンファンクションの想定トラフィック量で除算した値が所定の値を超える場合に、上記新たなユーザプレーンファンクションを追加すべきと判断してもよい。ここで、上記トラフィック増加余地容量は、上記ローカルエリアネットワークによる最大トラフィック量から上記ユーザデータのトラフィック量を減算した値であってもよい。また、上記トラフィック増加余地容量は、上記ローカルエリアネットワークによる最大トラフィック量から上記少なくとも１つのユーザプレーンファンクションの台数に応じたトラフィック量を減算した値であってもよい。なお、上記所定の値は、１以上であることが想定される。

また、この第１の側面において、上記ローカルエリアネットワークに配置されたエンティティから上記新たなユーザプレーンファンクションに属するサブネットにおける仮想マシンに対して測定されたトラフィック量が、上記新たなユーザプレーンファンクションの想定トラフィック量より多い場合に、上記新たなユーザプレーンファンクションを追加すべきと判断するようにしてもよい。これにより、新たなユーザプレーンファンクションを追加したと想定した際のトラフィック量を実測により確認するという作用をもたらす。

また、この第１の側面において、上記ローカルエリアネットワークに配置されたエンティティから上記新たなユーザプレーンファンクションに属するサブネットにおける仮想マシンに対して測定された遅延時間が所定の遅延閾値より小さい場合に、上記新たなユーザプレーンファンクションを追加すべきと判断するようにしてもよい。これにより、新たなユーザプレーンファンクションを追加したと想定した際の遅延時間を実測により確認するという作用をもたらす。

また、この第１の側面において、上記少なくとも１つのユーザプレーンファンクションのうちの対象ユーザプレーンファンクションの処理使用率および上記対象ユーザプレーンファンクションとは異なる他のユーザプレーンファンクションの処理使用率を考慮して、上記対象ユーザプレーンファンクションを削除すべきか否かを判断するようにしてもよい。これにより、ユーザプレーンファンクションの処理使用率を利用してユーザプレーンファンクションを削除すべきか否かを判断するという作用をもたらす。

また、この第１の側面において、上記少なくとも１つのユーザプレーンファンクションのうちの対象ユーザプレーンファンクションの処理使用率が第１の閾値を下回った場合に、上記対象ユーザプレーンファンクションとは異なる他のユーザプレーンファンクションにおいてその処理使用率が上記第１の閾値よりも高い第２の閾値を下回るユーザプレーンファンクションが少なくとも１つ存在する場合に、上記対象ユーザプレーンファンクションを削除すべきと判断するようにしてもよい。これにより、処理使用率の低い対象ユーザプレーンファンクションによって処理されていた分を他のユーザプレーンファンクションにおいて収容できる場合に、対象ユーザプレーンファンクションを削除すべきと判断するという作用をもたらす。

また、この第１の側面において、上記ローカルエリアネットワークに配置されたエンティティから上記他のユーザプレーンファンクションに属するサブネットにおける仮想マシンに対して測定されたトラフィック量が、上記対象ユーザプレーンファンクションの想定トラフィック量より多い場合に、上記対象ユーザプレーンファンクションを削除すべきと判断するようにしてもよい。これにより、対象ユーザプレーンファンクションを削除したと想定した際のトラフィック量を実測により確認するという作用をもたらす。

本技術の実施の形態において想定する無線通信システムの第１の例を示す図である。 本技術の実施の形態において想定する無線通信システムの第２の例を示す図である。 本技術の実施の形態におけるコアネットワークの配置例を示す図である。 コアネットワークがボトルネックになっている場合の例を示す図である。 本技術の実施の形態における無線通信システムの一例を示す図である。 本技術の実施の形態における無線通信システムの通信経路の例を示す図である。 本技術の第１の実施の形態における無線通信システムの全体の処理手順例を示すシーケンス図である。 本技術の実施の形態におけるＬＡＮの最大トラフィック量取得の態様例を示す図である。 本技術の実施の形態におけるＬＡＮの最大トラフィック量取得の際のＵＰＦの動作例を示す図である。 本技術の実施の形態におけるＵＰＦ１２０毎の通信路の最大のトラフィック量の測定例を示す図である。 本技術の実施の形態におけるＵＰＦ１２０毎のユーザデータのトラフィック量取得の態様例を示す図である。 本技術の実施の形態におけるＵＰＦ１２０毎のユーザデータのトラフィック量取得の際のパケットカウンタ１８０の適用例を示す図である。 本技術の実施の形態におけるＵＰＦ１２０毎の運用中のユーザデータのトラフィック量の測定例を示す図である。 本技術の第２の実施の形態におけるトラフィック量測定の態様例を示す図である。 本技術の第２の実施の形態におけるトラフィック量測定の際のＵＰＦの動作例を示す図である。 本技術の第２の実施の形態における無線通信システムの全体の処理手順例を示すシーケンス図である。

以下、本技術を実施するための形態（以下、実施の形態と称する）について説明する。説明は以下の順序により行う。
１．第１の実施の形態（ＬＡＮのトラフィック量に着目した制御の例）
２．第２の実施の形態（他の通信路のトラフィック量を併せて考慮した制御の例）

＜１．第１の実施の形態＞
［無線通信システム］
図１は、本技術の実施の形態において想定する無線通信システムの第１の例を示す図である。

この第１の例は、第４世代移動通信システム（４Ｇ）に本技術の実施の形態を適用した場合の例である。端末３００は、基地局２００を介してコアネットワークに接続する。端末３００と基地局２００との間は、無線システムであるＲＡＮにより接続される。

コアネットワークは端末３００がネットワークに接続する際の許可やセッション管理を主に行うものであり、４ＧではＥＰＣ（Evolved Packet Core）と呼称される。この４Ｇのコアネットワークは、コントロールプレーンファンクション１１０とユーザプレーンファンクション１２０とに分かれおり、前者がネットワークの制御を行い、後者がパケット転送を行う。なお、コントロールプレーンファンクション１１０は、特許請求の範囲に記載の制御部の一例である。また、以下では、コントロールプレーンファンクション１１０を、単にコントロールプレーンと略すことがある。同様に、ユーザプレーンファンクション１２０を、単にユーザプレーンと略すことがある。

４Ｇのコントロールプレーンファンクション１１０は、ＨＳＳ１１１およびＭＭＥ１１２などを備える。ＨＳＳ（Home Subscriber Server）１１１は、ユーザ情報を管理するデータベースサーバである。ＭＭＥ（Mobility Management Entity）１１２は、端末３００の制御のための制御信号のゲートウェイである。

４Ｇのユーザプレーンファンクション１２０は、ＳＧＷ１２１およびＰＧＷ１２２などを備える。ＳＧＷ（Serving Gateway）１２１は、ユーザデータのゲートウェイである。ＰＧＷ（Packet data network Gateway）１２２は、外部ネットワークに接続するためのゲートウェイである。

４Ｇにおいて、端末３００の加入者情報が格納されているＨＳＳ１１１からその端末３００の契約情報や暗号のための鍵を受けて、その端末３００がネットワークに接続してもよいか否かを判断し、暗号化のための鍵の生成などを行う。つまり、端末３００の中にあるＳＩＭ（Subscriber Identity Module）カードの中にあるＩＭＳＩ（International Mobile Subscriber Identity）という加入者番号に紐づいた端末３００の情報がＨＳＳ１１１に格納されていることが、その端末３００にとって、ネットワークに接続するために必要となる。また、端末３００がセルラシステムにアタッチするために、ＭＭＥ１１２がその役割を果たす。

図２は、本技術の実施の形態において想定する無線通信システムの第２の例を示す図である。

この第２の例は、第５世代移動通信システム（５Ｇ）に本技術の実施の形態を適用した場合の例である。端末３００が基地局２００を介してコアネットワークに接続し、端末３００と基地局２００との間がＲＡＮにより接続される点は、上述の４Ｇの場合と同様である。

５Ｇのコントロールプレーンファンクション１１０は、ＵＤＭ１１３、ＳＭＦ１１４およびＡＭＦ１１５などを備える。ＵＤＭ（Unified Data Management）１１３は、加入者情報を管理するものである。ＳＭＦ（Session Management Function）１１４は、セッション管理を行うものである。ＡＭＦ（Access and Mobility Management Function）１１５は、端末の認証や位置管理などを行うものである。

５Ｇのユーザプレーンファンクション１２０は、４ＧのＳＧＷ１２１およびＰＧＷ１２２のように分離されておらず、ここではＵＰＦ（User Plane Function）１２３と表記する。

５Ｇにおいては、上述のＨＳＳ１１１と同様の機能をＵＤＭ１１３が備える。以降、ＨＳＳ１１１という表記を用いるが、これは、ＵＤＭ１１３にも適用できる。また、端末３００がセルラシステムにアタッチするために、ＡＭＦ１１５やＳＭＦ１１４がその役割を果たす。

図３は、本技術の実施の形態におけるコアネットワークの配置例を示す図である。

４ＧのＰＧＷ１２２や５ＧのＵＰＦ１２３は、コアネットワークと一般のインターネットとの境界となるゲートウェイの役割を果たしている。この実施の形態では、コアネットワークも一般のインターネットにも配置することを考えているためＰＧＷ１２２やＵＰＦ１２３に相当するＣＮ－Ｕ１２９というコアネットワークのユーザプレーンファンクションが、コアネットワークと一般のアプリケーションとの境界に配置されるゲートウェイであると捉えて構わない。同様に、ここでは、ＭＭＥ１１２やＳＭＦ１１４およびＡＭＦ１１５に相当するものをＣＮ－Ｃ１１９として示している。

端末３００と基地局２００が配置されている近くにコアネットワークが配置されると、セルラ部分で要する遅延が少なくなることが知られている。そのため、インターネットのエッジ（Edge）に配置されるコアネットワークが増加することが予想される。ただし、この場合においても、エッジに配置されていないコアネットワークを、センターコアネットワークとして配置しておくことは有用である。エッジにコアネットワークが配置されていない時には、このセンターコアネットワークを使えばよいからである。なお、「エッジに配置されるコアネットワーク」という表現は、「コアネットワーク内のエッジに配置される１または複数のコアネットワークノード」という表現に代替されてもよい。また、「エッジ」は端末３００または基地局２００（例えば、端末３００のアクセスポイント）の近くに配置されることを意味していてもよい。

今後は、センターコアネットワークが存在している状況で、世界中の様々な場所のインターネットのエッジに多数のコアネットワークが配置されることが予想される。中には、工場や病院、オフィスの中のＬＡＮにコアネットワークを配置するケースも出てくると考えられる。少なくとも、基地局２００は、工場や病院、オフィスのようなローカルエリアに配置され、コアネットワークは、そのようなローカルに置く場合とそのローカルエリアの近くのインターネット上に置かれる場合とが出てくると考えられる。いずれにしても、そのようなローカルなセルラシステムでは、低コストなシステムが要求される。これらは、プライベート４Ｇ（ローカル４Ｇ）またはプライベートＬＴＥ（ローカルＬＴＥ）や、プライベート５Ｇ（ローカル５Ｇ）などと呼ばれることもある。

［スループット］
ＳＧＷ１２１およびＰＧＷ１２２またはＵＰＦ１２３によって実現されるユーザプレーンファンクションは、その能力の一つの指標として、処理できる最大のスループットというものがある。例えば、１００Ｍｂｐｓのユーザデータ（ユーザプレーンのデータ）を処理できる等の指標である。１００Ｍｂｐｓを処理するコアネットワークのユーザプレーンファンクションがあり、１台の基地局２００が処理できる能力が１００Ｍｂｐｓであったとする。その場合には、１台の端末がネットワークを使うと、その１台の端末は１００Ｍｂｐｓのスピードを享受することができる。一方、そのような基地局２００と端末が１０セットあった場合には、コアネットワークのユーザプレーンの能力がボトルネックになって、各端末は１０Ｍｂｐｓのスループットしか得られない。

図４は、コアネットワークがボトルネックになっている場合の例を示す図である。１００Ｍｂｐｓを処理するコアネットワークのユーザプレーンファンクションに対して、端末３００や基地局２００が増えるとユーザプレーンの能力がボトルネックになるおそれがある。このように基地局２００の数や端末３００の数が増えた時に、コアネットワークのユーザプレーンの能力を向上させる必要がある。

コアネットワークのユーザプレーンの能力向上、すなわちスケーリング（Scaling）を行う際、静的（static）なスケーリングと動的（dynamic）なスケーリングとが考えられる。静的スケーリングとは、一度、ユーザプレーンの台数を決めて、コアネットワークを起動し、基地局２００と接続し、運用を開始した後は、そのユーザプレーンの台数は、基本的に変えないという方法である。一方、動的スケーリングとは、端末３００の数の変動に対応して、ユーザプレーンの台数を柔軟に増やし、または、減らす方法である。

ユーザプレーンの台数を動的に増減させる方法は、非常に難易度が高い。なぜなら、基地局２００の設定を変える必要が出てくる場合もあれば、新しいＰＤＵセッションをユーザプレーンファンクションに割り振る機能が、変化したユーザプレーンの存在に気づき、内部のテーブルを更新するなどの手間がかかる場合もあるからである。上述のプライベートＬＴＥやプライベート５Ｇなどと呼ばれる局所的なセルラシステムのためのコアネットワークは低コストで作る必要があるため、このような手間をかけることが困難であった。このスケーリングの際には、動的または静的のどちらの方法であっても、ユーザプレーンファンクションの数を増やすべきか、または、減らすべきかを、どこかの機能で判断する必要がある。

この実施の形態において、端末３００と基地局２００は、ＬＡＮ（Local Area Network）に配置される。また、この実施の形態において、コアネットワークのコントロールプレーンは、インターネット上のクラウドに配置される。一方、コアネットワークのユーザプレーンファンクションは、オンプレミス（on-premise）のＬＡＮに配置してもよく、また、オンクラウド（on-cloud）に配置してもよい。

ＬＡＮに配置したユーザプレーンファンクションは、ＰＣ（Personal Computer）などの設備を増強しない限り、ユーザプレーンファンクションを増加することができない。一方、クラウドに配置したユーザプレーンファンクションは、クラウド上の仮想マシン（Virtual Machine）を追加して、その仮想マシンの中でユーザプレーンファンクションのプログラムを起動すれば、容易にユーザプレーンファンクションを追加することができる。ユーザプレーンファンクションの削除は、ユーザプレーンファンクションのプログラムを停止した上で、仮想マシンを削除すればよい。したがって、ユーザプレーンファンクションの追加または削除は、主にクラウド上に配置したユーザプレーンファンクションの追加または削除である。

ユーザプレーンファンクションの追加または削除は、クラウド上であれば比較的容易である。ＬＡＮにもユーザプレーンファンクションを配置することが可能であり、追加または削除ができないわけではないが、仮想マシンを自由に追加または削除できるわけではないため、ユーザプレーンファンクションの追加または削除は、ＬＡＮ上ではやり難い。なお、端末３００から見た場合に、ＬＡＮのユーザプレーンファンクションとクラウドのユーザプレーンファンクションは、同じように並列に見えるため、違いが分かるわけではない。

そこで、以下ではクラウド上でユーザプレーンファンクションの追加または削除を行う手法について検討する。

図５は、本技術の実施の形態における無線通信システムの一例を示す図である。

この例では、上述のように、オンプレミスとオンクラウドにまたがって無線通信システムが形成される。オンプレミスとは、工場や病院、オフィスなどのＬＡＮ上にＵＰＦを配置することをいう。オンクラウドとは、インターネット上のクラウドのデータセンターにＵＰＦを配置することをいう。基地局２００と端末３００は、もともとローカルなエリアに設置されている。

コアネットワークのコントロールプレーンは、オンプレミスでもオンクラウドでもよい。ここでは、コントロールプレーンはオンクラウドに設置した例を示している。

この例では、オンプレミスには、２つのユーザプレーンファンクションがコントロールプレーンの立上げ時、または、運用開始時に実在しているものとする。また、オンクラウドには、コントロールプレーンの立上げ時、または、運用開始時には、ユーザプレーンファンクションが不在であり、その後から立ち上げることを想定している。

ＬＡＮとクラウドのデータセンター内は、広域レイヤ２接続で、同じサブネット（Subnet）としてネットワークを形成しておくのがよい。これにより、ＬＡＮなのかクラウドなのかを意識することなく、ユーザプレーンファンクションを増減させることが可能となる。オンプレミスのユーザプレーンファンクションで足りなくなってきた時に、オンクラウドのユーザプレーンファンクションを実際に起動して、ユーザプレーンファンクション全体の容量を増やすことができる。なお、広域レイヤ２接続をする技術については、仮想ＶＰＮ（Virtual Private Network）等の既存の技術を適用することができる。

ここで、サブネットとは、ＩＰパケットを転送する際にＭＡＣアドレスに基づいてルーティングできる範囲のことをいう。具体的には、同じスイッチに接続するエンティティ（entity）は、同じサブネットに属しているという。基本的に、１つのＵＰＦは、１つのサブネットに属する。したがって、ＵＰＦが３２個ある場合、３２個の別のサブネットがクラウド上に存在することになる。

クラウド上のリソースマネージメントファンクション１９０は、ネットワーク上のリソースを管理するものである。ここでは、特に、リソースマネージメントファンクション１９０は、ネットワークの状況に基づいて、クラウド上のユーザプレーンファンクションを追加または削除する機能を有する。

測定対象となる使用中のユーザプレーンファンクションに対して、ネットワークトラフィック量測定ツール、例えば、ｉｐｅｒｆ３やｐｉｎｇといったツールを用いて、何Ｍｂｐｓの速度が得られるかを測定する方法が従来から知られている。この方法では、ｉｐｅｒｆ３サーバをユーザプレーンファンクションの内部、または、その近傍の仮想マシンに配置し、ｉｐｅｒｆ３クライアントをＬＡＮ側に配置して、測定を行う。これにより、ユーザプレーンファンクションまでの通信経路の通信路のトラフィックの混雑度を測定することができる。なお、スループットとトラフィック量は同義であるが、トラフィックとスループットは同義ではない。スループットと一つの機能を通り抜けるトラフィック量は同義である。以下の実施の形態では、スループットとトラフィック量は同じ意味として使用する。

この情報を取得しても、どの通信経路でトラフィックが混雑しているのか分からないため、ユーザプレーンファンクションを追加すべきか、または、削除すべきかの判断の情報としては十分ではない。また、ネットワーク測定ツールでは、実際にトラフィックを発生させて、どれくらいトラフィック量を向上させることができる余地があるかを測定する。しかし、このネットワークトラフィック量測定ツールによって生じたトラフィックが重要なユーザデータの通信に影響を与え、ユーザデータのトラフィック量の低下や遅延特性の悪化を招くことがある。特に、プライベート５Ｇ／４Ｇでは、ＬＡＮ部分は脆弱なネットワークであることが少なくないため、そのようなネットワークでは、実際にテスト用のデータをネットワークトラフィック量測定ツールが送信するのは望ましくない。

そこで、この実施の形態において、リソースマネージメントファンクション１９０は、大きく分けて以下の２つの情報に着目する。１つ目は、ユーザプレーンファンクションの処理能力である。また、２つ目は、ネットワークに流れるトラフィックの状況である。ネットワークに流れるトラフィックは、各ユーザプレーンファンクションで共通の通信路と、各ユーザプレーンファンクション固有の通信路の２種類ある。前者は、主にＬＡＮの通信経路であり、後者は、主にクラウドのユーザプレーンファンクション毎に異なる通信経路である。

まず、１つ目のユーザプレーンファンクションの処理能力について検討する。ユーザプレーンファンクションは、ソフトウェアとして設計されている。そのソフトウェアの処理能力が例えば１００Ｍｂｐｓである場合には、１秒間に１００Ｍビットのユーザデータを処理可能であるということになる。このとき、ユーザデータの使用状況が１００Ｍｂｐｓに迫る勢いの８０Ｍｂｐｓの場合には、もう１つユーザプレーンファンクションを追加して、追加したユーザプレーンファンクションと合わせて処理した方が、処理能力は増大するため、望ましい。もちろん、ユーザプレーンファンクションを増やす場合には、クラウドの仮想マシンを追加することになるため、プライベート５Ｇ／４Ｇのネットワーク運用者にとっては、コストが増大するという負の側面もある。

次に、２つ目のネットワークに流れるトラフィックの状況について検討する。１つ目のユーザプレーンファンクションの処理能力の観点からユーザプレーンファンクションを追加した方がよいと判断しても、ネットワークのトラフィックが混雑している状況では、ユーザプレーンファンクションを増やしたとしてもスループットのパフォーマンスは向上しないと考えられる。したがって、ネットワークのトラフィックの状況を把握することが重要となる。ここで、ネットワークのトラフィックの状況とは、大きく分けて２つある。一つは、ＬＡＮ側のネットワークのトラフィックの混雑状況、もう一つは、クラウド側のネットワークのトラフィックの混雑状況である。

クラウド側に配置されたユーザプレーンファンクションは、共通のＬＡＮを使用し、その後段のインターネットでも同じ経路を通り、最後に各ユーザプレーンファンクションに分配されるときに、異なる通信路を通る。すなわち、通信経路は、共通の通信経路と、各ユーザプレーンファンクション独自の通信経路に分かれている。そして、共通の通信経路はＬＡＮの影響が大きいといえる。

図６は、本技術の実施の形態における無線通信システムの通信経路の例を示す図である。

この例では、ＬＡＮから共通の通信経路を通って、ルータ４１０をゲートウェイとして、インターネットに接続される場合を想定している。

ここで、共通の通信経路について検討する。ＬＡＮにインターネットを提供するＩＳＰ（Internet Services Provider）とＬＡＮとの境界に配置されるルータ４１０内で分岐している場合もあり得る。また、ＬＡＮの後のＩＳＰの通信経路の中で、個別の通信経路に分岐している場合もあり得る。また、その後段のクラウドのデータセンターで個別の通信経路に分岐している場合もあり得る。何れにしても、クラウド側の各ユーザプレーンファンクションまで到達したトラフィックは、全て共通の通信経路を通っているということになる。

特定のユーザプレーンファンクションのトラフィックが混雑しているが、共通の通信経路であるＬＡＮが混雑していない場合には、ユーザプレーンファンクションを別の場所に追加して、そちらで使用した方がスループットのパフォーマンスが向上するといった使い方ができる。また、ユーザプレーンファンクションを１台追加したい場合に、その追加した分のトラフィックを吸収できるかは、少なくとも共通部分のＬＡＮでその追加した分のトラフィックを吸収できるかを判断する必要がある。その上で個別の通信経路でもトラフィックを吸収できるかについても判断した方がよい。このように、プライベート５Ｇ／４Ｇのトラフィックを観測する際には、共通の通信経路で混雑しているのか、個別の通信経路で混雑しているかを区別することが重要である。

プライベート５Ｇ／４ＧではＬＡＮを使用するため、そのＬＡＮが脆弱なネットワークの場合、ＬＡＮからインターネットに出ていく時のゲートウェイとなるルータ４１０の処理能力が限られている場合、または、ＩＳＰの通信路の能力が限られる場合があり得る。そのため、ｉｐｅｒｆ３などのネットワークツールを使って、テスト用のトラフィックを発生してネットワークの速度向上余地を知る手法は、重要な既存のユーザデータのスループットを低下させ、または、遅延特性を劣化させるおそれがあるため、望ましくない。さらに、ＬＡＮに配置したネットワークツールのクライアントから、クラウドに配置したユーザプレーンファンクション、または、その近傍の仮想マシンに配置したネットワークツールのサーバとの間のスループットを測定した場合に、共通の通信経路が混雑しているのか、個別の通信経路が混雑しているのかを判別することが困難であった。この実施の形態では、このような環境下で、ユーザプレーンファンクションの追加または削除を判断して、ユーザプレーンファンクションの数を柔軟に制御する。

［処理概要］
図７は、本技術の第１の実施の形態における無線通信システムの全体の処理手順例を示すシーケンス図である。

まず、ＬＡＮの最大トラフィック量を取得する。そのために、後述するように、ＬＡＮにコンピュータ（ＰＣ）４２０を配置して、ネットワークトラフィック量測定ツールを使用して、各ＵＰＦ１２０に対して通信路の最大のトラフィック量を測定する（８１０）。ただし、これは、プライベート５Ｇ／４Ｇの運用を行っていない夜中などに行う。

コンピュータ４２０は、測定したＵＰＦ１２０毎の最大トラフィック量をリソースマネージメントファンクション１９０に報告する（８１１）。リソースマネージメントファンクション１９０は、そのＵＰＦ１２０毎の最大トラフィック量に基づいて、ＬＡＮの最大能力を集計する（８１２）。このＬＡＮの最大能力は、後述するように、クラウドに配置されているＵＰＦ１２０のプログラムを実行する仮想マシンに対するトラフィック量のうち、最大のものを選択することにより得られる。

次に、基地局２００を介して端末３００とＵＰＦ１２０との間で実運用（８１３）が行われている際の、ＵＰＦ１２０毎のユーザデータのトラフィック量を取得する。そのために、後述するように、ＵＰＦ１２０毎にパケットカウンタ１８０を想定し、このパケットカウンタ１８０により実運用中のユーザデータのトラフィック量を測定する（８１４）。このパケットカウンタ１８０による測定値は、リソースマネージメントファンクション１９０に報告される（８１５）。

リソースマネージメントファンクション１９０は、測定された実運用中のユーザデータのトラフィック量を総計して、ＬＡＮにおけるユーザデータのトラフィック量を算出する。そして、上述のＬＡＮの最大能力から、このＬＡＮにおけるユーザデータのトラフィック量を減算することにより、ＵＰＦ１２０のトラフィック増加余地容量を取得する（８１６）。このトラフィック増加余地容量とは、後述するように、ＵＰＦ１２０を増加した際に利用可能なトラフィック量である。

次に、ＵＰＦ１２０は、それぞれの処理使用率を算出し、リソースマネージメントファンクション１９０に報告する（８１７）。この処理使用率は、後述するように、ＵＰＦ１２０を構成するプログラムの処理が能力的にどれくらい残っているかということを意味する。

このようにして取得した各種の情報を参照して、リソースマネージメントファンクション１９０は、新たにＵＰＦ１２０を追加すべきか否か、および、既存のＵＰＦ１２０を削除すべきか否かを判断する（８１８）。この判断の詳細については後述する。そして、その判断に基づいて、リソースマネージメントファンクション１９０は、ＵＰＦ１２０の追加または削除を実行する（８１９）。

［ＬＡＮの最大トラフィック量の取得］
図８は、本技術の実施の形態におけるＬＡＮの最大トラフィック量取得の態様例を示す図である。このＬＡＮの最大トラフィック量の取得は、上述の８１０乃至８１２に相当する。

プライベート５Ｇ／４Ｇの運用を行っていない夜中などに、ｉｐｅｒｆ３等のネットワークトラフィック量測定ツールを使用して、ＬＡＮに配置したコンピュータ４２０から各ＵＰＦ１２０に対して、通信路の最大のトラフィック量を測定しておく。ここでのトラフィック量測定は、コアネットワークの能力を使ったトラフィック量測定ではなく、ＬＡＮとイーサネットケーブルで接続したコンピュータ４２０から、クラウドに配置したＵＰＦ１２０に対する、固定ケーブルの通信経路のトラフィック量測定である。これは、ネットワークが混雑していないと想定する時間を使って測定し、それを複数回行うことにより、最大のトラフィック量を見積もることができる。なお、コンピュータ４２０は、ＬＡＮに配置されたエンティティの一例である。

図９は、本技術の実施の形態におけるＬＡＮの最大トラフィック量取得の際のＵＰＦの動作例を示す図である。

各ＵＰＦ１２０は、ＵＰＦ１２０毎に異なるサブネットに配置されている。その場合に、ＬＡＮ側に配置したコンピュータ４２０からネットワークトラッフィク量測定ツールで測定する場合には、各サブネットに配置された仮想マシンに対してトラフィック量を測定してもよく、また、ＵＰＦ１２０が配置された仮想マシンに対してトラフィック量を測定してもよい。すなわち、同じサブネット内であれば何れの仮想マシンでもよく、そのサブネット内に配置された仮想マシンに対して測定を行えばよいことになる。

図１０は、本技術の実施の形態におけるＵＰＦ１２０毎の通信路の最大のトラフィック量の測定例を示す図である。

ここでは、各ＵＰＦ１２０が属するサブネットまでのトラフィック量が示されている。すなわち、無線区間を除く、有線通信区間のみのトラフィック量である。この場合のトラフィック量は、アップリンクとダウンリンクとで、基本的には同じトラフィック量になることが想定されるため、アップリンクかダウンリンクの何れかを測定すればよいと考えられる。

ここでは、ＵＰＦ１２０毎の３２個の最大トラフィック量の中での最大値が、ＬＡＮからクラウドへ出ていく通信経路の最大能力としている。この最大能力とは、固定通信としての最大トラフィック量である。この例では、１．５ＧｂｐｓがＬＡＮからインターネットへの通信の最大速度であると推定している。

すなわち、ＬＡＮの最大能力は次式により得られる。ただし、関数Ｍａｘは最大値を示す関数である。
ＬＡＮの最大能力 ＝ Ｍａｘ（ＵＰＦ＃１の最大トラフィック量，
ＵＰＦ＃２の最大トラフィック量，...，
ＵＰＦ＃３２の最大トラフィック量）

上述の無線通信システムの構成例では、ＵＰＦ＃１および＃２はＬＡＮに配置され、ＵＰＦ＃３乃至３２はクラウドに配置されることを想定していた。したがって、この場合、クラウドに新たにＵＰＦ２０を追加することが可能か否かを判断するために、次式のように、クラウドに配置されたＵＰＦ１２０を実行する仮想マシンに対する最大トラフィック量をＬＡＮの最大能力とする。
ＬＡＮの最大能力 ＝ Ｍａｘ（ＵＰＦ＃３の最大トラフィック量，
ＵＰＦ＃４の最大トラフィック量，...，
ＵＰＦ＃３２の最大トラフィック量）

なお、上式におけるＵＰＦの最大トラフィック量とは、上述のように、通常のＵＰＦの処理を行った上で測定したトラフィック量ではなく、ＵＰＦ１２０のプログラムを配置した仮想マシンに対してネットワーク測定ツールで測定したトラフィック量である。

［ＵＰＦ毎のユーザデータのトラフィック量の取得］
図１１は、本技術の実施の形態におけるＵＰＦ１２０毎のユーザデータのトラフィック量取得の態様例を示す図である。このユーザデータのトラフィック量取得は、上述の８１３乃至８１５に相当する。

オンクラウドに設置したＵＰＦ１２０では、ＵＰＦ１２０毎に異なるサブネットを構築することが可能であり、そのサブネットに流入したトラフィックは、全て、このＵＰＦ１２０のトラフィックであるといえる。したがって、オンクラウドに設置したＵＰＦ１２０の中の対象のＵＰＦに流れる５Ｇ／４Ｇのトラフィック量を測定することにより、容易に得ることができる。特に、ＵＰＦ１２０毎にサブネットを分けることにより、そのサブネットに流入したパケット数でトラフィック量を測定することにより、実際にＵＰＦ１２０の内部で受信したトラフィック量や、送信したトラフィック量を測定しなくてもよいというメリットがある。したがって、サブネット毎に配置したＵＰＦへのトラフィック量の測定を、そのサブネットに流入したトラフィックおよびそのサブネットから流出したトラフィックを監視することで実現することができる。

一方、オンプレミス（ＬＡＮ）上に構築したＵＰＦ１２０が属するサブネットには、他の様々なトラフィックが流れているため、プライベート５Ｇ／４Ｇで使用しているトラフィックと他のトラフィックとを分離することは困難である。したがって、この実施の形態における無線通信システムでは、敢えてオンクラウドのＵＰＦ１２０が属するサブネットに流入するトラフィックだけを監視する。オンクラウドのＵＰＦ１２０のトラフィックだけを監視することでできることは、オンクラウドの特定のＵＰＦ１２０で使用しているトラフィック量を明確にすることができるということである。

図１２は、本技術の実施の形態におけるＵＰＦ１２０毎のユーザデータのトラフィック量取得の際のパケットカウンタ１８０の適用例を示す図である。

ＵＰＦ１２０毎のトラフィック量の測定は、各ＵＰＦ１２０が実装されている仮想マシンにおいて、パケットカウンタ１８０を実装することにより実現することができる。このパケットカウンタ１８０は、入力のパケット数およびそのパケットのビット数と、出力のパケット数およびそのパケットのビット数とを測定する。このパケットカウンタ１８０は、ＵＰＦ１２０毎に用意する。アップリンクとダウンリンクの区別は、パケットのソースＩＰアドレスおよびデスティネーションＩＰアドレスを参照することにより、その宛先および送信元から判断することができる。

図１３は、本技術の実施の形態におけるＵＰＦ１２０毎の運用中のユーザデータのトラフィック量の測定例を示す図である。

ここでは、上述の通信路の最大のトラフィック量の測定例と異なり、無線区間を含むトラフィック量が示されている。また、アップリンクとダウンリンクとが異なるため、別々に測定されている。

クラウドのＵＰＦ１２０が使用しているユーザデータのトラフィック量は、全てＬＡＮに配置されている基地局２００と端末３００から発生しているものであり、通信路の共通部分の大部分はＬＡＮであるため、このトラフィック量はＬＡＮのトラフィックの混雑度として使用可能である。

ＬＡＮでは、各ＵＰＦ１２０のアップリンクとダウンリンクのトラフィックを全て合計したものがトラフィックとして流れている。したがって、ＬＡＮにおけるユーザデータのトラフィック量は、次式により表される。ただし、関数ＳＵＭは、総和を表す関数である。
ＬＡＮにおけるユーザデータのトラフィック量 ＝
ＳＵＭ（ＵＰＦ＃ｉのトラフィック量） （ｉ＝１～３２）

そこで、次式のように、上述のＬＡＮの最大能力（８１２）からこのＬＡＮにおけるユーザデータのトラフィック量を減算した値が、ＵＰＦ１２０のトラフィック増加余地容量となる。
ＵＰＦのトラフィック増加余地容量 ＝ ＬＡＮの最大能力
－ ＬＡＮにおけるユーザデータのトラフィック量

このトラフィック増加余地容量は、ＵＰＦ１２０を増加した際に利用可能なトラフィック量である。したがって、このトラフィック増加余地容量を指標にして、新たにＵＰＦ１２０を増加するか否かを判断することができる。

上式によるトラフィック増加余地容量は、実際のユーザデータのトラフィック量を考慮しているため、そのトラフィック量が変動した場合には当初の想定と異なるという事態が起こり得る。そこで、簡易な手法として、ＵＰＦのプログラム処理能力を、例えば「１００Ｍｂｐｓ」の固定値として想定して、次式のようにＵＰＦのトラフィック増加余地容量を求めるようにしてもよい。
ＵＰＦのトラフィック増加余地容量 ＝ ＬＡＮの最大能力
－ ＵＰＦのプログラム処理能力 × ＵＰＦの稼働台数

また、上式の場合、ＵＰＦのトラフィック増加余地容量が少なく見積もられることになるため、次式のように調整係数をかけて調整してもよい。
ＵＰＦのトラフィック増加余地容量 ＝ ＬＡＮの最大能力
－ ＵＰＦのプログラム処理能力 × ＵＰＦの稼働台数 × 調整係数
ここで、調整係数は、例えば１．０から０．７程度が想定される。

トラフィック増加余地容量と同様の指標として、ＬＡＮの混雑度について説明する。ＬＡＮの混雑度は、次式により表される。
ＬＡＮの混雑度 ＝ ＬＡＮにおけるユーザデータのトラフィック量
／ＬＡＮの最大能力

なお、上式では、ＬＡＮの混雑度の中に他の無線ＬＡＮやイーサネットに接続されているコンピュータのトラフィックは含まれていない。これは、プライベート５Ｇ／４ＧはＬＡＮを使用するが、そのＬＡＮに従来の無線ＬＡＮやイーサネット経由に直接接続したコンピュータは接続されないものと想定したものである。無線ＬＡＮ等も同時に収容する場合には、それを考慮する必要があるが、プライベート５Ｇ／４Ｇ用のＬＡＮは、プライベート５Ｇ／４Ｇ用の専用のＬＡＮにする可能性が高いため、ここではそれは考慮しないで議論を続ける。

これにより、ここでは、従来のネットワーク測定ツールを使用せず、既存のユーザデータに影響を与えることなく、ＬＡＮ部分の混雑度を推定することが可能になった。なお、このＬＡＮの混雑度とＵＰＦのトラフィック増加余地容量は、実用上は同様に使用可能なため、以下ではＵＰＦのトラフィック増加余地容量を使用する。

［ＵＰＦの処理使用率の取得］
このＵＰＦの処理使用率の取得は、上述の８１７に相当する。

ＵＰＦの処理使用率とは、対象のＵＰＦを構成するプログラムの処理がどれくらい使用されているかを示す指標である。このＵＰＦの処理使用率は次式により表される。
ＵＰＦの処理使用率 ＝
現在の処理容量 ／ ＵＰＦのプログラム処理能力

例えば、ＵＰＦの本来のプログラム処理能力が１００Ｍｂｐｓで、現在の処理容量が８０Ｍｂｐｓである場合には、ＵＰＦの処理使用率は「０．８」になる。また、ＵＰＦの処理使用率が「０．０」であれば、そのＵＰＦは使用されていなくて、完全に処理の容量があることを意味する。また、ＵＰＦの処理使用率が「１．０」であれば、完全にビジーで、処理能力が残っていないことを意味する。

また、このＵＰＦの処理使用率を取得するための変形例として、対象となるＵＰＦにおいて入力したパケットにタイムスタンプを付与し、出力時にそのタイムスタンプを参照する手法を用いてもよい。この場合、タイムスタンプを参照することにより、そのＵＰＦの処理遅延を観測し、一定時間以上の処理遅延を観測した時にはそのＵＰＦの処理使用率が高いと考える。この場合のＵＰＦの処理使用率は、次式により得られる。
ＵＰＦの処理使用率 ＝ （現在の遅延－最低遅延）／ 現在の遅延

この場合の遅延は、ＵＰＦの入力から、ＵＰＦ内部で処理されて、ＵＰＦから出力されるまでの遅延時間をいう。上式は、現在の遅延が最低遅延に近いと「０」に近づき、現在の遅延が大きくなるにしたがって「１」に近づく。

［ＵＰＦの追加判断］
このＵＰＦの追加判断は、上述の８１８に相当する。

リソースマネージメントファンクション１９０は、全てのＵＰＦを対象ＵＰＦとして、以下の条件を調べていく。そして、以下の２つの条件を満たした場合には、新たなＵＰＦを１台追加すべきと判断する。
追加条件＃１： 対象ＵＰＦの処理使用率 ＞ ０．８
追加条件＃２： ＵＰＦのトラフィック増加余地容量 ／
ＵＰＦのプログラム処理能力 ＞ １．２

追加条件＃１は、対象ＵＰＦの処理のビジー率を示すものである。追加条件＃１において、対象ＵＰＦの処理使用率が０．８より大きいということは、処理能力が限界に近付いているということを意味する。したがって、可能であればＵＰＦを新たに追加して、その新たなＵＰＦにトラフィックを移したいという状況である。

一方で、新たにＵＰＦを追加するということは、そのＵＰＦの追加によって生じる新たなトラフィックを収容できるだけの通信路の容量が必要になる。その指標となるのが追加条件＃２である。

追加条件＃２は、ＵＰＦを増加した際にＬＡＮにおいて必要なトラフィック量を利用可能であるかを示すものである。追加条件＃２におけるＵＰＦのトラフィック増加余地容量は、上述の８１６において取得されたものである。また、追加条件＃２におけるＵＰＦのプログラム処理能力は、ＵＰＦにおける固定値であり、例えば「１００Ｍｂｐｓ」を想定する。なお、ここでは、マージンを見越してＵＰＦの「１．２」台分のトラフィック量が利用できることを条件としているが、例えばマージンを設けずに「１．０」台分を条件としてもよい。

なお、ＵＰＦのトラフィック増加余地容量は、ＬＡＮの混雑度だけを考慮したものであるため、実際にはクラウドの通信路が混雑していた場合には、見積もりに誤差を生じ得る。しかし、この追加条件＃２によって、ＵＰＦの追加が必要ないということについては判断することができる。

［ＵＰＦの削除判断］
このＵＰＦの削除判断は、上述の８１８に相当する。

リソースマネージメントファンクション１９０は、全てのＵＰＦを対象ＵＰＦとして、以下の条件を調べていく。そして、以下の２つの条件を満たした場合には、その対象ＵＰＦを削除すべきと判断する。
削除条件＃１： 対象ＵＰＦの処理使用率 ＜ ０．１
削除条件＃２： 対象ＵＰＦ以外のＵＰＦについて、
ＵＰＦの処理使用率＜０．５ を示すＵＰＦが少なくとも１台ある

削除条件＃１は、使用率の低いＵＰＦを示すものである。すなわち、処理使用率が小さいということは、対象ＵＰＦがほとんど使用されていないことを意味している。ほとんど使用されていないＵＰＦは、削除できる可能性がある。

一方で、ＵＰＦを削除した場合には、そのＵＰＦで使われていたトラフィックを別のＵＰＦが収容する必要がある。その指標となるのが削除条件＃２である。

削除条件＃２は、対象ＵＰＦのトラフィックを収容できる可能性のあるＵＰＦが存在することを示している。つまり、トラフィックの収容に余裕がある、ＵＰＦ処理使用率が少ないＵＰＦが、存在していることを判断するものである。

２つの削除条件から明らかなように、ＵＰＦを削除するかどうかの判断には、トラフィックの状況が考慮されていない。これは、削除されるＵＰＦのトラフィックが別のＵＰＦに収容されるだけであるため、少なくともＬＡＮにおけるトラフィックが増加するわけではないからである。

なお、上述の各手順において、トラフィックの状況や処理使用率を調べる回数は、数回実施した結果の平均等を取った上で慎重に判断してもよく、また、１回の調査の結果をもって判断してもよい。

このように、本技術の第１の実施の形態では、ＬＡＮのトラフィックの状況と、ＵＰＦの処理使用率とを考慮して、新たにＵＰＦを追加すべきか否かが判断される。また、対象ＵＰＦの処理使用率と、他のＵＰＦの処理使用率とを考慮して、対象ＵＰＦを削除すべきか否かが判断される。これにより、リソースマネージメントファンクション１９０は、無線通信システムの状況に応じて、ＵＰＦの数を柔軟に制御することができる。すなわち、ＵＰＦの追加および削除を効果的に判断することが可能になり、必要な数のＵＰＦを配置することが可能になるため、必要最小限のコストでスループット（トラフィック量）を増大させることができる。

＜２．第２の実施の形態＞
上述の第１の実施の形態では、ＵＰＦのトラフィック増加余地容量は、ＬＡＮの混雑度だけを考慮したものである。実際には、通信路の混雑は、ＬＡＮだけではなく、インターネットやインターネット上に配置されるクラウドの通信路で混雑する場合がある。したがって、ＬＡＮが混んでいない状態でクラウドが混んでいる場合には、ＵＰＦを追加するという判断において誤差を生じ得る。

例えば、ＵＰＦのトラフィック増加余地容量が十分あるためＵＰＦを増やしたところ、実際には、クラウド側の通信路が混雑していたため、ＵＰＦを増やしても、そこで使用する通信路の容量がなかったということが起きる場合がある。これは、クラウドだけではなく、ＩＳＰの経路が混んでいる場合にも同じことがいえる。ＩＳＰの途中から各ＵＰＦに向けて通信路が分岐する場合もあるからである。

そこで、この第２の実施の形態では、ＵＰＦの追加判断および削除判断において、以下に示すように条件を追加する。

［ＵＰＦの追加判断］
この第２の実施の形態では、リソースマネージメントファンクション１９０は、上述の追加条件＃１および＃２を満たした場合には、新たなＵＰＦを追加するための仮想マシンを立ち上げる。そして、ＬＡＮのイーサネットケーブルに接続したコンピュータ４２０から、クラウドの新たに作成したサブネットの中に新たに立ち上げた仮想マシンに対して、ネットワークトラフィック量測定ツールによって固定通信のスループットの測定を行う。測定されたスループットが以下の追加条件＃３を満たした時には、その新たに追加した仮想マシンの上でＵＰＦのプログラムを起動する。
追加条件＃３： ＵＰＦを追加するために新たに立ち上げた
仮想マシンに対する固定通信のスループットが
ＵＰＦのプログラム処理能力よりも大きい場合

すなわち、ＵＰＦを追加するためには、そのＵＰＦのプログラムを搭載する仮想マシンを新たに立ち上げる必要がある。その上で、その仮想マシンまで実際にスループットを測定することにより、トラフィックの状況が実際に、追加されるＵＰＦの処理能力以上のトラフィック増加余地があるかを検証している。これにより、ＩＳＰやクラウドの通信路が混雑していて、ＵＰＦを追加した分のトラフィックを運ぶ余裕があるか否かを検査することができる。

図１４は、本技術の第２の実施の形態におけるトラフィック量測定の態様例を示す図である。

ここで、ｉｐｅｒｆ３のようなネットワークトラフィック量測定ツールによって実際のトラフィックを流しているが、これはＵＰＦを追加するか否かを判断する時のみ実施すればよい。つまり、追加条件＃１および２を満たした場合のみ、追加条件＃３によりトラフィック測定を行うため、トラフィック測定用のトラフィックが運用中のユーザデータに与える影響は少ないと考えられる。

図１５は、本技術の第２の実施の形態におけるトラフィック量測定の際のＵＰＦの動作例を示す図である。

新たなＵＰＦを収容するために、運用中のＵＰＦのサブネットに加えて、新たにサブネットを追加し、その追加したサブネットの中の仮想マシンに対してトラフィック量を測定する。ここでは、新たに追加したサブネットの中に、ネットワークトラフィック量測定ツールによる測定用の仮想マシンを立ち上げた状態を示している。

このように、追加条件＃３を設けて、ネットワークトラフィック量測定ツールによって実際にＬＡＮからクラウドのＵＰＦまでのトラフィック量を測定することにより、追加条件＃１および２だけでは見えなかったＩＳＰとクラウドの混雑度を考慮することができる。ただし、この場合、テスト用のトラフィックがユーザデータのトラフィックに影響を及ぼすおそれがある。

そこで、第２の実施の形態におけるＵＰＦの追加判断の変形例として、ＬＡＮで発生したパケットにタイムスタンプを付与し、追加しようとしているＵＰＦのために新たに立ち上げた仮想マシンに対して送信する手法を用いてもよい。この場合、その仮想マシンに到着したパケットのタイムスタンプと現時刻とを比較することにより、ＬＡＮからクラウドに追加した仮想マシンまでのパケットが到達する時の遅延時間を測定することができる。

すなわち、ＬＡＮのイーサネットケーブルに接続したコンピュータ４２０から、クラウドの新たに作成したサブネットの中に新たに立ち上げた仮想マシンに対して、タイムスタンプを付与したパケットを送信し、その仮想マシンに到着した時刻との差分から遅延時間を取得する。そして、その遅延時間に関する追加条件＃３－２を、上述の追加条件＃３に代えて適用する。
追加条件＃３－２： 遅延時間 ＜ 遅延時間の閾値

この追加条件＃３－２において、遅延時間が大き過ぎる場合には、ＩＳＰまたはクラウドにおいて混雑していることを検出することができる。遅延時間の閾値は、トラフィックが混んでいない夜中の遅延時間等を測定しておき、その値に基づいて一定の値をマージンとして足した値を用いることが想定される。

この変形例における追加条件＃３－２は、上述の第２の実施の形態における追加条件＃３と異なり、大量のパケットをトラフィック量測定のために送信する必要がないため、既存のユーザデータに与える影響が少ないという利点がある。

［ＵＰＦの削除判断］
この第２の実施の形態では、リソースマネージメントファンクション１９０は、上述の追加条件＃１および＃２に加えて、以下の追加条件＃３を満たした場合には、その対象ＵＰＦを削除すべきと判断する。その際、ＬＡＮのイーサネットケーブルに接続したコンピュータ４２０から、削除予定の対象ＵＰＦのトラフィックを収容する、対象ＵＰＦ以外のＵＰＦまたは、そのＵＰＦと同じサブネット内の仮想マシンに対して、ネットワークトラフィック量測定ツールによってトラフィック量を測定する。その測定されたトラフィック量について、以下の削除条件＃３を判断する。
削除条件＃３： 対象ＵＰＦ以外のＵＰＦについて測定された
トラフィック量が、ＵＰＦのプログラム処理能力よりも大きい場合

この削除条件＃３において、ＵＰＦのプログラム処理能力は、削除される予定のＵＰＦにおける固定値であり、例えば「１００Ｍｂｐｓ」を想定する。

上述の第１の実施の形態では、削除条件＃１および２に従ってＵＰＦを削除する際、その削除したＵＰＦのトラフィックを他のＵＰＦに収容できるか否かはＬＡＮの混雑度により判断していた。これに対し、この第２の実施の形態では、削除条件＃３において、削除したＵＰＦのトラフィックを代わりに収容するＵＰＦにおいて、実際に通信速度が得られるか否かを確かめることによって、クラウド側が混雑していないことを確認することができる。

この第２の実施の形態では、ネットワークトラフィック量測定ツールを使って、実際に通信路にテストのためのトラフィックを流すため、既存の重要なユーザデータへの影響が起こり得る。しかし、削除条件＃１および２によって、ＬＡＮの混雑度が少なく、少なくともＵＰＦのプログラム処理能力分の通信路の空き容量があることを確認した後にのみ、削除条件＃３において実際にトラフィックを発生する。したがって、最初から全てネットワークトラフィック量測定ツールを使う手法に比べると、ユーザデータへの影響は比較的少ないと考えられる。

図１６は、本技術の第２の実施の形態における無線通信システムの全体の処理手順例を示すシーケンス図である。

この例では、追加条件＃３について説明したように、追加ＵＰＦを実行する仮想マシンを立ち上げて、トラフィック量を測定する点（８２０）が新たに記載されている。これ以外の点は、上述の第１の実施の形態と同様である。

なお、この例では、ＵＰＦを追加する際のトラフィック量測定について示しているが、ＵＰＦを削除する際にも削除条件＃３を判断するためにトラフィック量の測定が必要となる。

このように、本技術の第２の実施の形態では、ＵＰＦを追加または削除する際に実際のトラフィック量を測定することにより、ＵＰＦを追加または削除した後のトラフィック量による影響を考慮する。すなわち、これにより、ＬＡＮ以外の通信路において混雑が生じていることにより、ＵＰＦの追加または削除の後に想定していた性能が得られない、という事態を回避することができる。

上述したいくつかの実施の形態において、リソースマネージメントファンクション１９０が行う動作は、コアネットワーク（例えば、５ＧＣやＥＰＣ）内の他のノードが行ってもよい。例えば、リソースマネージメントファンクション１９０の代わりに、５ＧＣのＡＭＦ１１５、ＳＭＦ１１４、ＮＳＳＦ（Network Slice Selection Function）もしくはＡＦ（Application Function）またはこれらの組合せが、上述したリソースマネージメントファンクション１９０の動作を行ってもよい。さらに、または、これに代えて、ＥＰＣのＡＭＦ１１５、ＳＧＷ１２１もしくはＰＧＷ１２２またはこれらの組合せが、上述したリソースマネージメントファンクション１９０の動作を行ってもよい。

なお、上述の実施の形態は本技術を具現化するための一例を示したものであり、実施の形態における事項と、特許請求の範囲における発明特定事項とはそれぞれ対応関係を有する。同様に、特許請求の範囲における発明特定事項と、これと同一名称を付した本技術の実施の形態における事項とはそれぞれ対応関係を有する。ただし、本技術は実施の形態に限定されるものではなく、その要旨を逸脱しない範囲において実施の形態に種々の変形を施すことにより具現化することができる。

また、上述の実施の形態において説明した処理手順は、これら一連の手順を有する方法として捉えてもよく、また、これら一連の手順をコンピュータに実行させるためのプログラム乃至そのプログラムを記憶する記録媒体として捉えてもよい。この記録媒体として、例えば、ＣＤ（Compact Disc）、ＭＤ（MiniDisc）、ＤＶＤ（Digital Versatile Disc）、メモリカード、ブルーレイディスク（Blu-ray（登録商標）Disc）等を用いることができる。

なお、本明細書に記載された効果はあくまで例示であって、限定されるものではなく、また、他の効果があってもよい。

なお、本技術は以下のような構成もとることができる。
（１）ローカルエリアネットワークに配置された基地局とクラウドに配置された少なくとも１つのユーザプレーンファンクションとが接続される通信システムにおいて、
前記ローカルエリアネットワークによる最大トラフィック量のうち、前記少なくとも１つのユーザプレーンファンクションが前記ローカルエリアネットワークを利用して転送するユーザデータのトラフィック量と、新たなユーザプレーンファンクションの想定トラフィック量とを考慮して、前記新たなユーザプレーンファンクションを追加すべきか否かを判断する制御装置。
（２）前記少なくとも１つのユーザプレーンファンクションのうちの対象ユーザプレーンファンクションの処理使用率が所定の閾値を超えた場合に、前記新たなユーザプレーンファンクションを追加すべきか否かの判断を行う
前記（１）に記載の制御装置。
（３）前記対象ユーザプレーンファンクションの処理使用率は、前記対象ユーザプレーンファンクションの現在の処理容量を前記対象ユーザプレーンファンクションの想定トラフィック量で除算することにより得られる値である
前記（２）に記載の制御装置。
（４）前記対象ユーザプレーンファンクションの処理使用率は、前記対象ユーザプレーンファンクションにおける処理遅延が大きいほど前記対象ユーザプレーンファンクションの処理使用率が高いものとして計算される値である
前記（２）に記載の制御装置。
（５）前記ローカルエリアネットワークによる最大トラフィック量は、前記少なくとも１つのユーザプレーンファンクション毎に測定された、前記ローカルエリアネットワークに配置されたエンティティとのトラフィック量の最大値である
前記（１）から（４）のいずれかに記載の制御装置。
（６）前記ユーザデータのトラフィック量は、前記少なくとも１つのユーザプレーンファンクション毎に測定された、前記基地局を介した端末によるトラフィック量の総計である
前記（１）から（５）のいずれかに記載の制御装置。
（７）前記ローカルエリアネットワークによる最大トラフィック量からトラフィック増加余地容量を算出して、前記トラフィック増加余地容量を前記新たなユーザプレーンファンクションの想定トラフィック量で除算した値が所定の値を超える場合に、前記新たなユーザプレーンファンクションを追加すべきと判断する
前記（１）から（６）のいずれかに記載の制御装置。
（８）前記トラフィック増加余地容量は、前記ローカルエリアネットワークによる最大トラフィック量から前記ユーザデータのトラフィック量を減算した値である
前記（７）に記載の制御装置。
（９）前記トラフィック増加余地容量は、前記ローカルエリアネットワークによる最大トラフィック量から前記少なくとも１つのユーザプレーンファンクションの台数に応じたトラフィック量を減算した値である
前記（７）に記載の制御装置。
（１０）前記ローカルエリアネットワークに配置されたエンティティから前記新たなユーザプレーンファンクションに属するサブネットにおける仮想マシンに対して測定されたトラフィック量が、前記新たなユーザプレーンファンクションの想定トラフィック量より多い場合に、前記新たなユーザプレーンファンクションを追加すべきと判断する
前記（１）から（９）のいずれかに記載の制御装置。
（１１）前記ローカルエリアネットワークに配置されたエンティティから前記新たなユーザプレーンファンクションに属するサブネットにおける仮想マシンに対して測定された遅延時間が所定の遅延閾値より小さい場合に、前記新たなユーザプレーンファンクションを追加すべきと判断する
前記（１）から（９）のいずれかに記載の制御装置。
（１２）前記少なくとも１つのユーザプレーンファンクションのうちの対象ユーザプレーンファンクションの処理使用率および前記対象ユーザプレーンファンクションとは異なる他のユーザプレーンファンクションの処理使用率を考慮して、前記対象ユーザプレーンファンクションを削除すべきか否かを判断する
前記（１）から（１１）のいずれかに記載の制御装置。
（１３）前記少なくとも１つのユーザプレーンファンクションのうちの対象ユーザプレーンファンクションの処理使用率が第１の閾値を下回った場合に、前記対象ユーザプレーンファンクションとは異なる他のユーザプレーンファンクションにおいてその処理使用率が前記第１の閾値よりも高い第２の閾値を下回るユーザプレーンファンクションが少なくとも１つ存在する場合に、前記対象ユーザプレーンファンクションを削除すべきと判断する
前記（１２）に記載の制御装置。
（１４）前記ローカルエリアネットワークに配置されたエンティティから前記他のユーザプレーンファンクションに属するサブネットにおける仮想マシンに対して測定されたトラフィック量が、前記対象ユーザプレーンファンクションの想定トラフィック量より多い場合に、前記対象ユーザプレーンファンクションを削除すべきと判断する
前記（１３）に記載の制御装置。
（１５）ローカルエリアネットワークに配置された基地局とクラウドに配置された少なくとも１つのユーザプレーンファンクションとが接続される通信システムにおける制御方法であって、
制御装置が、前記ローカルエリアネットワークによる最大トラフィック量を取得する手順と、
前記制御装置が、前記少なくとも１つのユーザプレーンファンクションが前記ローカルエリアネットワークを利用して転送するユーザデータのトラフィック量を取得する手順と、
前記制御装置が、前記ローカルエリアネットワークによる最大トラフィック量、前記ユーザデータのトラフィック量および新たなユーザプレーンファンクションの想定トラフィック量を考慮して前記新たなユーザプレーンファンクションを追加すべきか否かを判断する手順と
を具備する制御方法。

１１０ コントロールプレーンファンクション（ＣＰＦ）
１２０ ユーザプレーンファンクション（ＵＰＦ）
１８０ パケットカウンタ
１９０ リソースマネージメントファンクション
２００ 基地局
３００ 端末
４１０ ルータ
４２０ コンピュータ

Claims (15)

1. ローカルエリアネットワークに配置された基地局とクラウドに配置された少なくとも１つのユーザプレーンファンクションとが接続される通信システムにおいて、
   前記ローカルエリアネットワークによる最大トラフィック量のうち、前記少なくとも１つのユーザプレーンファンクションが前記ローカルエリアネットワークを利用して転送するユーザデータのトラフィック量と、新たなユーザプレーンファンクションの想定トラフィック量とを考慮して、前記新たなユーザプレーンファンクションを追加すべきか否かを判断する制御装置。
2. 前記少なくとも１つのユーザプレーンファンクションのうちの対象ユーザプレーンファンクションの処理使用率が所定の閾値を超えた場合に、前記新たなユーザプレーンファンクションを追加すべきか否かの判断を行う
   請求項１記載の制御装置。
3. 前記対象ユーザプレーンファンクションの処理使用率は、前記対象ユーザプレーンファンクションの現在の処理容量を前記対象ユーザプレーンファンクションの想定トラフィック量で除算することにより得られる値である
   請求項２記載の制御装置。
4. 前記対象ユーザプレーンファンクションの処理使用率は、前記対象ユーザプレーンファンクションにおける処理遅延が大きいほど前記対象ユーザプレーンファンクションの処理使用率が高いものとして計算される値である
   請求項２記載の制御装置。
5. 前記ローカルエリアネットワークによる最大トラフィック量は、前記少なくとも１つのユーザプレーンファンクション毎に測定された、前記ローカルエリアネットワークに配置されたエンティティとのトラフィック量の最大値である
   請求項１記載の制御装置。
6. 前記ユーザデータのトラフィック量は、前記少なくとも１つのユーザプレーンファンクション毎に測定された、前記基地局を介した端末によるトラフィック量の総計である
   請求項１記載の制御装置。
7. 前記ローカルエリアネットワークによる最大トラフィック量からトラフィック増加余地容量を算出して、前記トラフィック増加余地容量を前記新たなユーザプレーンファンクションの想定トラフィック量で除算した値が所定の値を超える場合に、前記新たなユーザプレーンファンクションを追加すべきと判断する
   請求項１記載の制御装置。
8. 前記トラフィック増加余地容量は、前記ローカルエリアネットワークによる最大トラフィック量から前記ユーザデータのトラフィック量を減算した値である
   請求項７記載の制御装置。
9. 前記トラフィック増加余地容量は、前記ローカルエリアネットワークによる最大トラフィック量から前記少なくとも１つのユーザプレーンファンクションの台数に応じたトラフィック量を減算した値である
   請求項７記載の制御装置。
10. 前記ローカルエリアネットワークに配置されたエンティティから前記新たなユーザプレーンファンクションに属するサブネットにおける仮想マシンに対して測定されたトラフィック量が、前記新たなユーザプレーンファンクションの想定トラフィック量より多い場合に、前記新たなユーザプレーンファンクションを追加すべきと判断する
    請求項１記載の制御装置。
11. 前記ローカルエリアネットワークに配置されたエンティティから前記新たなユーザプレーンファンクションに属するサブネットにおける仮想マシンに対して測定された遅延時間が所定の遅延閾値より小さい場合に、前記新たなユーザプレーンファンクションを追加すべきと判断する
    請求項１記載の制御装置。
12. 前記少なくとも１つのユーザプレーンファンクションのうちの対象ユーザプレーンファンクションの処理使用率および前記対象ユーザプレーンファンクションとは異なる他のユーザプレーンファンクションの処理使用率を考慮して、前記対象ユーザプレーンファンクションを削除すべきか否かを判断する
    請求項１記載の制御装置。
13. 前記少なくとも１つのユーザプレーンファンクションのうちの対象ユーザプレーンファンクションの処理使用率が第１の閾値を下回った場合に、前記対象ユーザプレーンファンクションとは異なる他のユーザプレーンファンクションにおいてその処理使用率が前記第１の閾値よりも高い第２の閾値を下回るユーザプレーンファンクションが少なくとも１つ存在する場合に、前記対象ユーザプレーンファンクションを削除すべきと判断する
    請求項１２記載の制御装置。
14. 前記ローカルエリアネットワークに配置されたエンティティから前記他のユーザプレーンファンクションに属するサブネットにおける仮想マシンに対して測定されたトラフィック量が、前記対象ユーザプレーンファンクションの想定トラフィック量より多い場合に、前記対象ユーザプレーンファンクションを削除すべきと判断する
    請求項１３記載の制御装置。
15. ローカルエリアネットワークに配置された基地局とクラウドに配置された少なくとも１つのユーザプレーンファンクションとが接続される通信システムにおける制御方法であって、
    制御装置が、前記ローカルエリアネットワークによる最大トラフィック量を取得する手順と、
    前記制御装置が、前記少なくとも１つのユーザプレーンファンクションが前記ローカルエリアネットワークを利用して転送するユーザデータのトラフィック量を取得する手順と、
    前記制御装置が、前記ローカルエリアネットワークによる最大トラフィック量、前記ユーザデータのトラフィック量および新たなユーザプレーンファンクションの想定トラフィック量を考慮して前記新たなユーザプレーンファンクションを追加すべきか否かを判断する手順と
    を具備する制御方法。

Images