JPWO2017057025A1 - サービス割当決定方法 - Google Patents

Abstract

サービスと当該サービスに割り当てるスライスを動的に変えることができるスライス割当方法を提供する。ＯＳＳ／ＢＳＳ１０では、スライスが割当てられているサービスと当該スライスとの対応付けをした割当サービス情報を保持する。また、ＯＳＳ／ＢＳＳ１０の依頼受付部１１は、機能の要件であるＳＬＡ—ＳＬを受信する。割当決定部１５は、受け付けられたサービスのサービス要件（ＳＬＡ—ＳＬ）に対応するＳＬＡ—ＳＬを有するスライスを決定する。割当要求部１６は、割当決定部１５により決定されたスライスのサービスと、予めスライスに対応付けられているサービスと同一である場合、決定されたスライスへサービスを割当て直す。

Description

本発明は、サービスを割り当てるスライスを決定する方法に関する。

従来の仮想化技術を用いたネットワークシステムは、非特許文献１に開示された仮想化技術を用いて、ハードウェア資源を仮想的に切り分けて、ネットワークインフラ上に論理的に生成される仮想ネットワークであるスライスを生成する。そして、当該スライスへサービスを割当てることにより、それぞれ独立したスライスのネットワークを用いてサービス提供することができる。これにより、多様な要求条件を持つサービス各々にスライスを割り当てた場合、サービス個々の要求条件を満たすことを容易にし、そのシグナリング処理などを軽減させることが可能となる。

中尾彰宏、″仮想化ノード・プロジェクト新世代のネットワークをめざす仮想化技術″、［online］、2010年6月、独立行政法人情報通信研究機構、［2015年3月16日検索］、インターネット<http://www.nict.go.jp/publication/NICT-News/1006/01.html>

しかし、一意にサービスをスライスに割り当ててしまうと、当該サービスの要件が動的に変わる場合や当該スライスを提供するリソースの状況が変化した場合に、常時当該サービスに対して適切なスライスに割り当てているとは限らない。また、リソース利用効率化の観点からもスライスを固定することが適切でない場合もある。

本発明は、上記に鑑みてなされたものであり、サービスと当該サービスに割り当てるスライスを動的に変えるスライス割当方法を提供することを目的とする。

上記目的を達成するために、本発明の一実施形態に係るサービス割当決定方法は、ネットワークインフラ上に生成される仮想ネットワークであるスライスに対して、当該仮想ネットワークを用いるサービスを割当てる装置で実行されるサービス割当決定方法であって、装置では、スライスが割当てられているサービスと当該スライスとの対応付けがなされており、割当対象のサービスにおける機能の要件であるサービス要件を満たすスライスを決定する決定ステップと、割当対象となるサービスが、装置により予めスライスに対応付けられている場合、決定ステップにより決定されたスライスへ割当対象のサービスを割当てし直す割当ステップとを含む。

上記のサービス割当決定方法によれば、サービス要件を満たすスライスへ割り当てし直すので、仮にサービス要件が変更されても、変更されたサービス要件を満たすスライスへ割り当てし直すことができる。このように、動的に変更されるサービス要件に対応して割り当てるスライスを動的に変更することができ、適切なサービスを提供することができる。

上記のサービス割当決定方法は、サービスを利用するためのデータを送受信する通信制御装置を変更することにより、割当対象のサービスを割当てし直してもよい。この場合、サービス要件に応じて、当該サービスのデータを送受信する通信制御装置を切り替えるのでサービスを利用するユーザに対して好適なサービスを提供することができる。

上記のサービス割当決定方法は、スライス毎のリソース状況と、既にスライスが割り当てられているサービスのサービス要件を取得する取得ステップ、をさらに含み、決定ステップは、取得ステップにより取得されたサービス要件及びリソース状況に基づいて割り当てるスライスを決定してもよい。この場合、既にスライスが割り当てられているサービスのサービス要件及びリソース状況情報に基づいてサービスに割り当てるスライスを決定するので、リソース状況が変動した場合でも適切なスライスを動的に割当てることができる。

また、上記のサービス割当決定方法は、決定ステップは、サービス要件を満たすスライスの内、空リソースが最も多いスライスに決定してもよい。この場合、空リソースが最も多いリソースのスライスにサービスを割当てるので、リソースの有効活用することができる。

本発明によれば、動的に変更されるサービス要件に対応して割り当てるスライスを動的に変更することができ、適切なサービスを提供することができる。

本発明の実施形態に係るシステムの構成を示す図である。 スライスとリソースとの対応関係を示す図である。 サービス要件に基づいて割り当てる方法の概要を説明する図である。 本発明の実施形態に係るシステムに含まれる装置のブロック図である。 ＯＳＳ／ＢＳＳ等のハードウェア構成図である。 要求サービステーブルを示す図である。 ファンクションセットテーブルを示す図である。 ファンクション要件テーブルを示す図である。 ユーザ利用サービステーブルを示す図である。 サービスパラメータドレステーブルを示す図である。 ＶＭ機能テーブルを示す図である。 ＶＭ使用率テーブルを示す図である。 ハードウェア使用率テーブルを示す図である。 新規サービス処理を示すシーケンス図である。 サービス再割り当て処理を示すシーケンス図である。 リソースに基づくサービス再割り当て処理を示すシーケンス図である。

以下、図面と共に本発明の一実施形態に係るスライス割当方法の実施形態について詳細に説明する。なお、図面の説明においては同一要素には同一符号を付し、重複する説明を省略する。

図１に本実施形態に係るＯＳＳ／ＢＳＳ１０及びＮＦＶＯ３０を含むシステム１の構成を示す。システム１は、仮想ネットワークであるスライスに対してサービスを割り当てるシステムである。スライスとは、ネットワーク装置のリンクとノードの資源を仮想的に切り分けて、切り分けた資源を結合し、ネットワークインフラ上に論理的に生成される仮想ネットワーク又はサービス網であり、スライス同士は資源を分離しており、互いに干渉しない。サービスとは、通信サービス（専用線サービス等）やアプリケーションサービス（動画配信、エンベデッド装置等のセンサ装置を利用したサービス）等のネットワーク資源を用いたサービスをいう。

図１に示すようにシステム１は、ＯＳＳ／ＢＳＳ（Operations Support System／Business Support System）１０と、ＳＯ（Service Operator）２０と、ＮＦＶＯ３０と、ＶＮＦＭ４０と、ＶＩＭ(Virtualized Infrastructure Management: 仮想化基盤管理)５０とを含んで構成されている。また、システム１には、物理資源であるＮＦＶＩ（ＮＦＶ(Network Functions Virtualisation) Infrastructure）６０と、ＳＢＳＡ（Service-Based Slice Allocator）７０と基地局８０とＵＥ９０と、ＨＳＳ（Home Subscriber Server）１１０と、ＤＮＳ（Domain Name System）１２０と、ＭＭＥ（Mobility Management Entity）１３０と、ＳＧＷ（Serving Gateway）１４０と、を含んで構成されている。このうち、ＮＦＶＯ３０とＶＮＦＭ４０とＶＩＭ５０とは、ＭＡＮＯ（Management & Orchestration）architectureである。

これらの構成要素は、システム１のコアネットワークを構成するものである。なお、互いに情報の送受信が必要な構成要素間は、有線等で接続されており情報の送受信が可能となっている。

本実施形態に係るシステム１は、物理サーバ上に実現される仮想マシンにおいて動作する仮想サーバによって移動通信端末に対して通信機能を提供する。即ち、システム１は、仮想化された移動体通信ネットワークである。通信機能は、仮想マシンによって当該通信機能に応じた通信処理を実行することで移動通信端末に対して提供される。

ＯＳＳ／ＢＳＳ１０は、システム１におけるサービス管理を行い、システム１での通信機能に係る指示を行うノードである。例えば、ＯＳＳ／ＢＳＳ１０は、ＮＦＶＯ３０に対して、新たな通信機能（通信サービス）を追加するように指示を行う。また、ＯＳＳ／ＢＳＳ１０は、システム１に係る通信事業者によって操作され得る。

ＳＯ（Service Operator）２０は、サービス要求する装置であり、例えば、仮想ネットワークを用いて各種ユーザへサービス提供をする事業者の端末装置（例えば、パーソナルコンピュータ等）である。

ＮＦＶＯ３０は、物理資源であるＮＦＶＩ６０上に構築された仮想ネットワーク（スライス）全体の管理を行う全体管理ノード（機能エンティティ）である。ＮＦＶＯ３０は、ＯＳＳ／ＢＳＳ１０からの指示を受信し、当該指示に応じた処理を行う。ＮＦＶＯ３０は、インフラと通信サービスの移動体通信網の物理資源において構築された仮想化ネットワーク全体にわたる管理を行う。ＮＦＶＯ３０は、仮想ネットワークにより提供される通信サービスをＶＮＦＭ４０及びＶＩＭ５０を経由して適切な場所に実現する。例えば、サービスのライフサイクル管理（具体的には例えば、生成、更新、スケール制御、イベント収集）、移動体通信網内全体にわたる資源の分散・予約・割当管理、サービス・インスタンス管理、及びポリシー管理（具体的には例えば、リソースの予約・割当、地理・法令等に基づく最適配置）を行う。

ＶＮＦＭ４０は、物理資源（ノード）となるＮＦＶＩ６０に対して、サービスに係る機能を追加する仮想通信機能管理ノード（機能エンティティ）である。ＶＮＦＭ４０は、システム１に複数、設けられていてもよい。

ＶＩＭ５０は、後述するＮＦＶＩ６０における物理資源（ノード）各々を管理する物理資源管理ノード（機能エンティティ）である。具体的には、資源の割当・更新・回収の管理、物理資源と仮想化ネットワークとの関連付け、ハードウェア資源とＳＷ資源（ハイパーバイザー）一覧の管理を行う。通常、ＶＩＭ５０は、データセンタ（局舎）毎に管理を行う。物理資源の管理は、データセンタに応じた方式で行われる。データセンタの管理方式（管理資源の実装方式）は、ＯＰＥＮＳＴＡＣＫやｖＣｅｎｔｅｒ等の種類がある。通常、ＶＩＭ５０は、データセンタの管理方式毎に設けられる。即ち、互いに異なる方式で、ＮＦＶＩ６０における物理資源各々を管理する複数のＶＩＭ５０が含まれる。なお、異なる管理方式で管理される物理資源の単位は、必ずしもデータセンタ単位でなくてもよい。

なお、ＮＦＶＯ３０、ＶＮＦＭ４０及びＶＩＭ５０は、物理的なサーバ装置上でプログラムが実行されることにより実現される（但し仮想化上で実現されることを制限するものでは無く、管理系統を分離した上で、仮想化上で実現してもよい）。ＮＦＶＯ３０、ＶＮＦＭ４０及びＶＩＭ５０は、それぞれ別々の物理的なサーバ装置で実現されていてもよいし、同じサーバ装置で実現されていてもよい。ＮＦＶＯ３０、ＶＮＦＭ４０及びＶＩＭ５０（を実現するためのプログラム）は、別々のベンダから提供されていてもよい。

ＮＦＶＯ３０は、ＯＳＳ／ＢＳＳ１０からのサービス割当要求を受信すると、ＶＩＭ５０に対してスライス（スライスＳＬ１、ＳＬ２等）のためのリソース確保要求を行う。ＶＩＭ５０が、ＮＦＶＩ６０を構成するサーバ装置やスイッチにおけるリソースを確保すると、ＮＦＶＯ３０は、当該これらＮＦＶＩ６０に対してスライスを定義する。

また、ＮＦＶＯ３０は、ＶＩＭ５０に、ＮＦＶＩ６０においてリソース確保させると、当該ＮＦＶＩ６０に対してスライスを定義した情報をＮＦＶＯ３０が記憶しているテーブルに記憶する。そして、ＮＦＶＯ３０は、当該サービスに必要となる機能を実現するためのソフトウェアのインストール要求をＶＮＦＭ４０に対して行う。ＶＮＦＭ４０は、当該インストール要求に応じて、ＶＩＭ５０によって確保されたＮＦＶＩ６０（サーバ装置、スイッチ装置またはルータ装置などのノード）に対して上記ソフトウェアをインストールする。

ＮＦＶＯ３０は、ＶＮＦＭ４０によりソフトウェアがインストールされると、ＮＦＶＯ３０が記憶しているテーブルへスライスとサービスとの対応付けをする。

スライスＳＬ１〜スライスＳＬ３は、サービスを割当てる単位となるサービススライス（以下、サービススライスを単に「スライス」ともいう）である。また、上記サービススライスを構成するリソースを定義するリソーススライスがある。リソーススライスとサービススライスとを対応付けることにより、サービススライスを構成するリソースが定まる。例えば、図２に示すように、ＮＦＶＯ３０がリソーススライス（リソーススライスＲ−ｓｌｉｃｅ１〜Ｒ−ｓｌｉｃｅ３）のためのリソース確保要求をＶＩＭ５０へ行うと、ＶＩＭ５０は、その旨の指示をサーバＳＶ１、スイッチＳＷ１、サーバＳＶ２及びスイッチＳＷ２に対して行う。そして、ＮＦＶＯ３０は、サーバＳＶ１、スイッチＳＷ１、サーバＳＶ２及びサーバＳＶ３のリソースをリソーススライスＲ−ｓｌｉｃｅ１のために確保する。また、ＮＦＶＯ３０は、サーバＳＶ１及びスイッチＳＷ１のリソースをリソーススライスＲ−ｓｌｉｃｅ２のために確保する。また、ＮＦＶＯ３０は、サーバＳＶ２及びサーバＳＶ３のリソースをリソーススライスＲ−ｓｌｉｃｅ３のために確保する。

ＮＦＶＯ３０は、リソーススライスを作成し、当該リソーススライスを構成するリソースに機能を設定すると、当該リソーススライスを利用するサービススライスを決定する。

ＮＦＶＯ３０は、上記のように、リソーススライスとサービススライスとを対応付けると、ＮＦＶＯ３０が記憶する複数のテーブル情報を用いて、図３（Ａ）に示すようにスライスと当該スライスの機能とを対応付けた情報を記憶する。例えば、ＮＦＶＯ３０は、リソーススライスＲ−ｓｌｉｃｅ１にサービススライスＳ−ｓｌｉｃｅ１を対応付け、リソーススライスＲ−ｓｌｉｃｅ２及びＲ−ｓｌｉｃｅ３にサービススライスＳ−ｓｌｉｃｅ２を対応付ける。このように、ＮＦＶＯ３０は、当該ＮＦＶＯ３０の利用者（管理者）からの入力操作に応じて、サービススライスとリソーススライスとを対応付ける。

図３（Ａ）は、ＮＦＶＯ３０が記憶するテーブルに基づいたリストである。図３（Ａ）に示すように、「Service slice」欄と、「Resource slice」欄と、「Function set」欄と、「ＳＬＡ（Service Level Agreement）−ＳＬ（Sufficiency Level）」欄とを対応付けたリストである。「Service slice」欄に入力されている情報（例えば、S-slice1）は、サービススライスを示す識別子である。「Resource slice」欄に入力されている情報は、リソーススライスを識別子である。「Function set」欄には、ファンクションセットを示す情報が入力される。ここでファンクションセットとは、リソーススライスのリソースが有する機能の集合である。「ＳＬＡ−ＳＬ」欄に入力される情報は、当該ファンクションセットに含まれるファンクションのそれぞれの機能を指標化した値である。ＮＦＶＯ３０が予め記憶している機能と当該機能の指標値とを対応した情報を参照して定めたものである。

ＮＦＶＯ３０は、図３（Ａ）に示した情報の内、「Service Slice」欄の情報と「SLA-SL」欄の情報とを定期的にＯＳＳ／ＢＳＳ１０に送信する。ＯＳＳ／ＢＳＳ１０は、当該「Service Slice」欄と「SLA-SL」欄とを対応付けた情報を記憶する。ＯＳＳ／ＢＳＳ１０は、ＳＯ２０からサービスパラメータとサービス要件を受信すると共にサービス要求を受け付けた場合、当該サービス要件と、記憶している「SLA-SL」欄の情報とを参照して、サービスの要件を満たす「SLA-SL」欄の情報を有するサービススライスに要求されたサービスを割当てて、当該割当てた結果を記憶する。サービスパラメータとは、サービスを一意に識別することができる情報である。図３（Ｂ）にＯＳＳ／ＢＳＳ１０が、割当てた結果として記憶する情報を示す。図３（Ｂ）に示すように、「Service parameter」欄と「Service slice」欄と「SLA-SL」欄とを対応付けた情報を記憶する。ここで、「Service parameter」欄は、ＳＯ２０からサービス要求を受け付けたサービスを特定する情報であり、ＳＯ２０から受信する情報である。「Service slice」欄の情報及び「SLA-SL」欄の情報は、ＮＦＶＯ３０から受信する情報である。図３（Ｂ）の例では、「Service parameter」欄に入力されている「Smart meter」及び「Road sensor」であるサービスパラメータにサービススライス「S-slice1」が割り当てられていることを示す。ＯＳＳ／ＢＳＳ１０は、割り当てることが決定されたサービススライス及びサービスパラメータをＮＦＶＯ３０へ通知する。ＮＦＶＯ３０は、当該サービススライス及びサービスパラメータをＶＮＦＭ４０へ通知する。ＶＮＦＭ４０は、上記割当てに関係する装置へ情報書換要求（編集要求）をする。ＶＮＦＭ４０は、編集が完了すると、サービスパラメータをＳＯ２０へ送信する。

ＮＦＶＩ６０は、仮想化環境を構成する物理資源（ノード群）から形成されたネットワークを示す。この物理資源は、概念的には計算資源、記憶資源、伝送資源を含む。具体的には、この物理資源は、システム１において通信処理を行う物理的なサーバ装置である物理サーバ、スイッチ等のノードを含んで構成されている。物理サーバは、ＣＰＵ（コア、プロセッサ）、メモリ、及びハードディスク等の記憶手段を備えて構成される。通常、ＮＦＶＩ６０を構成する物理サーバ等のノードは、複数まとめてデータセンタ（ＤＣ）等の拠点に配置される。データセンタでは、配置された物理サーバがデータセンタ内部のネットワークによって接続されており、互いに情報の送受信を行うことができるようになっている。また、システム１には、複数のデータセンタが設けられている。データセンタ間はネットワークで接続されており、異なるデータセンタに設けられた物理サーバはそのネットワークを介して互いに情報の送受信を行うことができる。

上述のように、ＶＮＦＭ４０が、物理資源（ノード）となるＮＦＶＩ６０に対して、各種機能を追加することにより、ＮＦＶＩ６０は、ＨＳＳ１１０、ＤＮＳ１２０、ＭＭＥ１３０、及びＳＧＷ１４０（通信制御装置）の機能を実現する。

ＳＢＳＡ７０は、基地局８０と互いに通信可能なサーバ装置であり、ＵＥ（User Equipment）９０からサービスＩＤと共に、サービス要求が基地局８０へなされると、当該基地局８０がＳＢＳＡ７０へＵＥ９０から受信したサービスＩＤをＳＢＳＡ７０へ通知する。

ＳＢＳＡ７０は、基地局８０からサービスＩＤを受信すると、ＳＢＳＡ７０が記憶するアクセス情報の内、基地局８０から受信したサービスＩＤに対応するアクセス情報のサービスの最初の機能を提供するハードウェアの宛先情報を基地局８０へ送信する。基地局８０は、当該宛先情報をＵＥ９０へ通知する。これにより、ＵＥ９０は、サービスを利用するために最初にアクセスする宛先を特定することができる。なお、ＳＯ２０からＵＥ９０へアクセスするための情報として、サービスパラメタを送信するようにしてもよい。

ＨＳＳ１１０は、ＵＥ９０等の通信端末の契約情報、認証情報、通信サービス情報、端末タイプ情報及び在圏情報を含む加入者情報をデータベースで管理する機能である。ここで、通信サービス情報とは、各ＵＥ９０が利用する通信サービスのタイプを定義した情報である。通信サービス情報には、ＵＥ９０を識別する情報（例えば、ＩＭＳＩ）と、当該ＵＥ９０が利用する通信サービスの要件を示すサービスタイプとが含まれる。

ＤＮＳ１２０は、ネットワーク上でドメイン名やホスト名とＩＰアドレスの対応関係を管理する機能である。さらにＤＮＳ１２０は、サービスパラメータとＳＧＷ１４０のアドレスとを対応付けた情報を記憶している。ＤＮＳ１２０は、ＭＭＥ１３０からアドレスの送信要求を受け付けると、要求に応じたＳＧＷ１４０のアドレスをＭＭＥ１３０へ送信する。

ＭＭＥ１３０は、ＬＴＥ（Long Term Evolution）ネットワークに在圏するユーザ端末（ＵＥ９０）の位置管理、認証制御、及びＳＧＷ１４０とＵＥ９０との間のユーザデータの通信経路の設定処理を行う機能である。

ＳＧＷ１４０は、ＬＴＥを収容する在圏パケット交換機の機能で、ＰＧＷ（Packet data network Gate Way）との間で通信サービス提供に利用されるユーザデータの送受信を行う。ＳＧＷ１４０は、複数の通信サービスの要件に対応して複数設けられている。

引き続いて、ＯＳＳ／ＢＳＳ１０と、ＮＦＶＯ３０と、ＶＮＦＭ４０と、ＶＩＭ５０とについて、本実施形態に係る機能について図４を用いて説明する。

また、物理的には、ＯＳＳ／ＢＳＳ１０と、ＮＦＶＯ３０と、ＶＮＦＭ４０と、ＶＩＭ５０は、それぞれ図５に示すように、ＣＰＵ１０１、主記憶装置であるＲＡＭ１０２及びＲＯＭ１０３、データ送受信デバイスである通信モジュール１０４、ハードディスク、フラッシュメモリ等に例示される補助記憶装置１０５などを含むコンピュータシステムとして構成されている。ＯＳＳ／ＢＳＳ１０と、ＮＦＶＯ３０と、ＶＮＦＭ４０と、ＶＩＭ５０とでは、図５に示すＣＰＵ１０１、ＲＡＭ１０２等のハードウェア上に所定のコンピュータソフトウェアを読み込ませることにより、ＣＰＵ１０１の制御のもとで通信モジュール１０４、を動作させるとともに、ＲＡＭ１０２や補助記憶装置１０５におけるデータの読み出し及び書き込みを行うことで、各装置における一連の機能が実現される。図４に戻り、ＯＳＳ／ＢＳＳ１０と、ＮＦＶＯ３０と、ＶＮＦＭ４０と、ＶＩＭ５０との機能を説明する。

図４に示すようにＯＳＳ／ＢＳＳ１０は、依頼受付部１１と、スライス要件取得部１２と、保持部１３と、リソース取得部１４と、割当決定部１５と、割当要求部１６とを有する。

依頼受付部１１は、ＳＯ２０からのサービスにおける機能の要件であるサービス要件を含むサービス依頼を受け付ける部分である。ここで、サービス要件の内、機能要件とはサービスを実行するための機能に関する要件である。具体的には、機能要件としてモビリティ制御の要否、可能アクセスエリア範囲、サービス利用時間が含まれる。モビリティ制御の要否とは、ハンドオーバ制御を必要とするか否かを意味する。アクセスエリア範囲は、サービスを提供する範囲（エリア）を意味する。サービス利用時間は、サービスを利用する時間帯を意味する。

また、依頼受付部１１は、サービス依頼を受け付ける際に、サービスを実現するための機能の要件を示す情報を受信する。ここでいうサービスを実現するための機能の要件を示す情報としては、ＳＬＡ−ＳＬである。

依頼受付部１１は、上記のサービスを実現するための機能の要件を示す情報を受信すると、サービス要件を割当決定部１５へ送出する。また、依頼受付部１１は、スライス要件取得部１２に対して、スライス要件を取得する旨の通知をする。

また、依頼受付部１１は、予め定められているリソース状況チェックタイミングであることを検知すると、リソース取得部１４へリソース取得する旨の通知をすると共に、上記チェックタイミングである旨を割当決定部１５へ通知する。また、依頼受付部１１は、リソース状況チェックタイミングである場合も、スライス要件取得部１２に対して、スライス要件を取得する旨の通知をする。

スライス要件取得部１２は、保持部１３で記憶している、図３（Ｂ）に示したスライスサービス情報を参照して、各スライスの要件（ＳＬＡ−ＳＬ）を取得する部分である。スライス要件取得部１２は、当該スライスの要件を取得すると、割当決定部１５へ送出する。

保持部１３は、各種テーブルを記憶する部分である。保持部１３は、要求サービス管理テーブル及び割当サービステーブル（図３（Ｂ））を記憶する。図６に要求サービス管理テーブルを示す。この要求サービス管理テーブルは、「Service Parameter」欄と「SLA-SL」欄とが対応付けられたテーブルである。「Service Parameter」欄には、依頼受付部１１がＯＳＳ／ＢＳＳ１０から受信したサービスパラメータが入力されている。「SLA-SL」欄には、依頼受付部１１がＯＳＳ／ＢＳＳ１０から受信したＳＬＡ−ＳＬが入力されている。また、上記要求サービス管理テーブルには、上記２つの欄以外に「端末情報」欄も対応付けられている。この「端末情報」欄には、依頼受付部１１がＯＳＳ／ＢＳＳ１０から受信した端末情報が入力されている。

リソース取得部１４は、依頼受付部１１からリソース取得要求を受け付けると、ＮＦＶＯ３０へリソース取得要求をする。リソース取得部１４は、当該リソース取得要求に応じて、ＮＦＶＯ３０からリソース情報を受信する。リソース取得部１４は、当該リソース情報を割当決定部１５へ通知する。

割当決定部１５は、依頼受付部１１によって受け付けられたサービスのサービス要件に対応するスライスを決定する部分である。例えば、割当決定部１５は、依頼受付部１１がＳＯ２０からサービス割当要求を受け付けた場合、依頼受付部１１から受信したＳＬＡ―ＳＬと、スライス要件取得部１２から取得した図３（Ｂ）に示した割当サービステーブルの情報のＳＬＡ―ＳＬとを比較して、依頼受付部１１から受信したＳＬＡ―ＳＬの値を全て包含する（受信したＳＬＡ―ＳＬの値以上である）割当サービステーブルの情報のサービススライスＩＤを決定する。割当決定部１５は、割当サービステーブルを参照し、割当対象のサービスパラメータと同一のサービスパラメータが既に割り当てられている場合であり、上記決定したサービススライスＩＤと、上記サービスパラメータに既に割り当てられているサービススライスＩＤとが異なる場合、割当要求部１６へ割り当て要求をする。また、割当決定部１５は、割当サービステーブルを参照し、既に同一のサービスパラメータが割り当てられていない場合は、割当要求部１６へ割り当て要求する。

また、割当決定部１５は、リソース取得部１４からリソース情報を取得した場合、要求サービス管理テーブルの各サービスパラメータに対応するＳＬＡ―ＳＬと、割当サービステーブルのＳＬＡ―ＳＬと、リソース取得部１４によって取得されたサービススライス毎のリソース使用状況とに基づいて、割当対象のサービスパラメータに割り当てるサービススライスを決定する。具体的には、割当決定部１５は、割当サービステーブルのＳＬＡ―ＳＬを参照し、要求サービス管理テーブルの各サービスパラメータに対応するＳＬＡ―ＳＬを満たすサービススライスの内、リソース使用状況に余裕のある（リソースに空きがある）サービススライスにサービスパラメータを割当てることを決定する。ここでリソース使用状況に余裕があるとは、スライス毎のリソース（当該スライスを構成するＶＭ又は、当該ＶＭを実現するハードウェア）の使用率の平均値が最も低いことをいう。この場合に、今回決定したサービススライスと、前回割り当てていたサービススライスが異なる場合、割当要求部１６へ割り当て要求をする。割当決定部１５は、割当要求部１６へ割当要求する場合、端末情報、サービスパラメータ、及び割り当てるサービススライスを通知する。

割当要求部１６は、割当対象のサービスが、予めスライスに対応付けられている場合、決定されたスライスへサービスを割当てし直す部分である。割当要求部１６は、割当決定部１５から受信した端末情報、サービスパラメータ、及び割り当てるサービススライスをＮＦＶＯ３０へ送信すると共に、割当要求をする。また、割当要求部１６は、割当対象のサービスパラメータと、割当先のサービススライスを対応付けるように割当サービステーブルを更新する。また、割当要求部１６は、新規にサービスパラメータにサービススライスを割当てる場合、サービスパラメータ、ＳＬＡ−ＳＬ、及び端末情報を要求サービス管理テーブルへ登録する。

続いて、ＮＦＶＯ３０の機能の説明をする。ＮＦＶＯ３０は、サービス割当要求部３１と、保持部３２と、ファンクション検索部３３と、リソース要求受付部３４と、リソース通知部３５とを備える。

サービス割当要求部３１は、ＯＳＳ／ＢＳＳ１０からの割当要求を受け付けて、これに応じてＶＮＦＭ４０へ割り当て要求する部分である。具体的には、サービス割当要求部３１は、ＯＳＳ／ＢＳＳ１０から、端末情報と、サービスパラメータと、サービススライスＩＤとを受信すると共に割当要求を受け付ける。また、サービス割当要求部３１は、当該サービススライスＩＤをファンクション検索部３３へ送信する。また、サービス割当要求部３１は、当該ファンクション検索部３３からファンクション検索結果を受信する。そして、サービス割当要求部３１は、サービスパラメータと、端末情報と、サービススライスＩＤと、ファンクション検索結果とをＶＮＦＭ４０へ送信し、サービス割当要求をする。

保持部３２は、各種テーブルを記憶する部分である。保持部３２は、ファンクションセットテーブル及びファンクション要件テーブルを記憶する。図７にファンクションセットテーブルを示す。このファンクションセットテーブルは、「S-Slice ID」欄と「R-Slice ID」欄と「Function Set」欄とを対応付けた情報を記憶するテーブルである。「S-Slice ID」欄には、サービススライスを識別するサービススライスＩＤが入力されている。「R-Slice ID」欄には、リソーススライスを識別するリソーススライスＩＤが入力されている。「Function Set」欄には、ファンクションセットを示す情報が入力されている。図８にファンクション要件テーブル示す。ファンクション要件テーブルは、「Function」欄と「SLA-SL」欄とを対応付けた情報を記憶するテーブルである。図８に示す「Function」欄には、ファンクションを示す情報が入力されている。また、「SLA-SL」欄には、当該ファンクションに対応するＳＬＡ−ＳＬを示す情報が入力されている。

ファンクション検索部３３は、サービススライスＩＤに対応するファンクションセットを検索する部分である。ファンクション検索部３３は、サービス割当要求部３１からサービススライスＩＤを受信すると、当該サービススライスＩＤを検索キーとしてファンクションセットテーブルを検索する。ファンクション検索部３３は、当該検索結果（ファンクションセット）をサービス割当要求部３１へ通知する。

リソース要求受付部３４は、ＯＳＳ／ＢＳＳ１０からリソース要求を受け付けると、保持部３２のファンクションセットテーブルからファンクションセットを取得する。リソース要求受付部３４は、当該ファンクションセットのそれぞれの機能をＶＮＦＭ４０へ送信し、ＶＭ取得要求をする。リソース要求受付部３４は、ＶＮＦＭ４０からＶＭを取得する。続いて、リソース要求受付部３４は、それぞれのＶＭのリソース利用状況の送信要求をＶＩＭ５０へ行う。リソース要求受付部３４は、ＶＩＭ５０からリソース利用状況を受信すると、当該リソース利用状況をサービススライス毎にリソース通知部３５へ通知する。

リソース通知部３５は、リソース要求受付部３４から受信したリソース利用状況をサービススライス毎にＯＳＳ／ＢＳＳ１０へ送信する。

続いて、ＶＮＦＭ４０の説明をする。ＶＮＦＭ４０は、構成要求受付部４１と、保持部４２と、検索部４３と、編集要求部４４とを有する。構成要求受付部４１は、ＮＦＶＯ３０からのＶＭ取得要求を受け付ける部分である。構成要求受付部４１は、ＮＦＶＯ３０から対象機能と共にＶＭ取得要求を受け付けると、当該対象機能を検索部４３へ通知する。構成要求受付部４１は、検索部４３に当該通知をした後に、検索部４３による検索結果を検索部４３から取得する。構成要求受付部４１は、検索結果を検索部４３から取得すると、検索結果をＮＦＶＯ３０へ送信する。

保持部４２は、各種情報を保持する部分である。保持部４２は、ソフトウェア（例えば、リポジトリ）を保持する。また、保持部４２は、上記ソフトウェア以外に、ＶＭと機能とを対応付けた情報有するＶＭ機能テーブルを記憶する。図１１にＶＭ機能テーブルの例を示す。図１１に示すように、「Function」欄と「VM」欄と、図示していないが、当該「VM」のアドレスを示す「アドレス」欄とを対応付けて記憶している。「Function」欄には、ファンクションを示す情報が入力されている。「VM」欄には、当該ファンクションを実行するＶＭを示す情報（例えば、ＶＭの識別子等）が入力される。

検索部４３は、構成要求受付部４１からの要求に応じて、保持部４２のＶＭ機能テーブルを検索して、その検索結果を構成要求受付部４１へ通知する部分である。検索部４３は、構成要求受付部４１から対象機能を受信すると、ＶＭ機能テーブルを検索して、当該対象機能に合致する「Function」欄の情報を有する「VM」を検索結果として、構成要求受付部４１へ送信する。

編集要求部４４は、ＮＦＶＯ３０からの編集要求を受け付け、これに応じて、ＨＳＳ１１０及びＤＮＳ１２０へ編集要求をする部分である。編集要求部４４は、ＮＦＶＯ３０から機能セット（機能のリスト）、端末情報、サービススライスＩＤ及びサービスパラメータを受信すると共に、上記編集要求を受け付ける。編集要求部４４は、上記端末情報、サービススライスＩＤ、及びサービスパラメータを送信し、ＨＳＳ１１０へ編集要求をする。ここで、ＨＳＳ１１０が記憶している情報の例を図９に示す。ＨＳＳ１１０は、図９に示すように、「User ID」欄と「Service Parameter」欄とを対応付けた情報を上記編集要求に応じて記憶する。「User ID」欄には、ユーザを識別する情報であり、例えば、ＩＭＳＩ等の情報が入力される。「Service Parameter」欄には、サービスパラメータが入力される。

また、編集要求部４４は、ＮＦＶＯ３０から受信した機能セットの内、ＳＧＷを示す情報を検索キーとして、ＶＭ機能テーブルを検索して、当該ＳＧＷのアドレスを取得する。そして、編集要求部４４は、当該アドレスとサービスパラメータとをＤＮＳ１２０へ送信すると共に編集要求する。ここで、ＤＮＳ１２０が記憶している情報の例を図１０に示す。ＤＮＳ１２０は、図１０に示すように、「Service Parameter」欄と「IP Address」欄とを対応付けた情報を上記編集要求に応じて記憶する。「Service Parameter」欄には、サービスパラメータが入力される。「IP Address」欄には、アクセス先を示すアドレス情報が入力される。ＤＮＳ１２０は、上記編集要求を受信すると、要求対象のサービスパラメータの情報が入力されていない場合には、新たにサービスパラメータと、上記アドレス情報を登録する。既にサービスパラメータが登録されている場合には、当該サービスパラメータに対応するアドレス情報を、要求対象のアドレス情報に変更する。

ＶＩＭ５０は、リソース要求受付部５１と、保持部５２と、リソース通知部５３とを備える。リソース要求受付部５１は、ＮＦＶＯ３０から、対象ＶＭと共にリソース状況の要求を受け付ける部分である。リソース要求受付部５１は、リソース状況要求受け付けると、対象ＶＭを検索キーとして、保持部５２の情報を検索する。リソース要求受付部５１は、検索結果をリソース通知部５３へ通知する。

保持部５２は、リソース情報を記憶する部分である。リソース情報として、ＶＭの使用率情報及び当該ＶＭを実現するハードウェアの使用率情報を記憶する。図１２にＶＭの使用率情報例を示す。図１２に示すように、「VM」欄と、「所属HW」欄と、「Usage」欄とを対応付けた情報を記憶している。「VM」欄には、VMを示す情報（例えば、VMの識別子）が入力されている。「所属HW」欄には、VMを実現するハードウェア（例えば、サーバ）を示す情報（例えば、サーバの識別子）が入力されている。「Usage」欄には、VMの使用率を示す情報が入力されている。続いて、図１３にハードウェアの使用率情報の例を示す。図１３に示すように、「HW」欄と、「Usage」欄とを対応付けた情報を記憶している。「HW」欄には、ハードウェアを識別する情報が入力されている。「Usage」欄には、ハードウェアの使用率を示す情報が入力されている。

リソース通知部５３は、リソース要求受付部５１から検索結果を受信し、当該検索結果をＮＦＶＯ３０へ送信する部分である。

引き続いて、図１４のシーケンス図を用いて、本実施形態に係るシステム１で実行される処理を説明する。ここでは、ＳＯ２０からＯＳＳ／ＢＳＳ１０へスクリーン搭載車における動作配信サービスにおいて固定モード（ＳＬＡ―ＳＬのmobilityが「１」）のサービス割当要求がある場合の例とする。

ＳＯ２０は、上記動作配信サービスを示すサービスパラメータ、ＳＬＡ―ＳＬ及び当該サービスを利用するＵＥ９０の端末情報をＯＳＳ／ＢＳＳ１０へ送信すると共に、サービス割当要求をする（ステップＳ１）。ＯＳＳ／ＢＳＳ１０の依頼受付部１１は、当該サービスパラメータ、ＳＬＡ―ＳＬ及び端末情報を受信すると共にサービス割当要求を受け付ける。スライス要件取得部１２は、依頼受付部１１がサービス割当要求を受け付けると、保持部１３で記憶している図３（Ｂ）に示した割当サービステーブルから情報を取得する。そして、割当決定部１５は、スライス要件取得部１２が取得した割当サービステーブルのＳＬＡ―ＳＬを参照し、受信したＳＬＡ―ＳＬを満たすスライスＩＤを決定する。ここでは、ＳＬＡ―ＳＬのmobilityが「１」であるので、他の要件も満たしている場合には、スライスＩＤが「１」のスライスにサービスを割当てることを決定する（ステップＳ２）。続いて、割当要求部１６は、当該サービススライスＩＤと、サービスパラメータと、端末情報とをＮＦＶＯ３０へ送信する（ステップＳ３）。ＮＦＶＯ３０のサービス割当要求部３１は、サービススライスＩＤと、サービスパラメータと、端末情報とを受信すると共にサービス割当要求を受信する。ＮＦＶＯ３０のファンクション検索部３３は、受信したサービススライスＩＤを検索キーとして、ファンクションセットテーブルを検索して、当該サービススライスＩＤに対応するファンクションセットを検索する（ステップＳ４）。ＮＦＶＯ３０のサービス割当要求部３１は、サービススライスＩＤと、サービスパラメータと、端末情報と、ファンクションセットとをＶＮＦＭ４０へ送信する（ステップＳ５）。編集要求部４４は、ＮＦＶＯ３０から受信した機能セットの内、ＳＧＷを示す情報を検索キーとして、ＶＭ機能テーブルを検索して、当該ＳＧＷのアドレスを取得する（ステップＳ６）。ＶＮＦＭ４０の編集要求部４４は、ＮＦＶＯ３０からの編集要求を受け付け、上記端末情報、サービススライスＩＤ、及びサービスパラメータを送信し、ＨＳＳ１１０へ編集要求をする（ステップＳ７）。そして、編集要求部４４は、当該アドレスとサービスパラメータとをＤＮＳ１２０へ送信すると共に編集要求する（ステップＳ８）。

また、ＶＮＦＭ４０の編集要求部４４は、上記編集の完了通知をＨＳＳ１１０及びＤＮＳ１２０から受け取ると、サービスパラメータの登録完了通知をＳＯ２０へ送信する（ステップＳ９）。ＳＯ２０は、当該登録完了通知を受信すると、ＵＥ９０へサービスパラメータを通知する（ステップＳ１０）。ＵＥ９０は、サービス利用時には、予め定められているＭＭＥ１３０へＡｔｔａｃｈ要求をする（ステップＳ１１）。ＭＭＥ１３０は、ＨＳＳ１１０へＡｔｔａｃｈ要求をする（ステップＳ１２）。ＨＳＳ１１０は、当該Ａｔｔａｃｈ要求を受け付けると共にＡｔｔａｃｈ要求しているＵＥ９０に対応するサービスパラメータを検索する（ステップＳ１３）。ＨＳＳ１１０は、検索したサービスパラメータをＭＭＥ１３０へ返却する（ステップＳ１４）。ＭＭＥ１３０は、当該サービスパラメータをＤＮＳ１２０へ送信すると共に、当該サービスパラメータに対応するアドレスを検索する（ステップＳ１６）。ＤＮＳ１２０は、検索したアドレスをＭＭＥ１３０へ送信する（ステップＳ１７）。ＭＭＥ１３０は、当該アドレスを受信し、受信したアドレスのＳＧＷ１４０へ接続し、ベアラ確立する（ステップＳ１８）。ＭＭＥ１３０は、ＵＥ９０へベアラ接続先を通知する（ステップＳ１９）。ＵＥ９０は、ＭＭＥ１３０から受信した接続先へアクセスして、サービスデータの通信を開始する（ステップＳ２０）。

上述のシーケンス図では、ＭＭＥ１３０がＨＳＳ１１０からサービスパラメータを受信する場合について述べたが、ステップＳ１１においてＵＥ９０からサービスパラメータを受信するようにしてもよい。

続いて、図１５のシーケンス図を用いて、本実施形態に係るシステム１で実行される処理を説明する。ここでは、ＳＯ２０からＯＳＳ／ＢＳＳ１０へスクリーン搭載車における移動モード（ＳＬＡ―ＳＬのmobilityが「３」）のサービス割当要求がある場合の例とする。

ＳＯ２０は、サービスパラメータ及びＳＬＡ―ＳＬをＯＳＳ／ＢＳＳ１０へ送信すると共に、サービス割当要求をする（ステップＳ３１）。ＯＳＳ／ＢＳＳ１０の依頼受付部１１は、当該サービスパラメータ及びＳＬＡ―ＳＬを受信すると共にサービス割当要求を受け付ける。スライス要件取得部１２は、依頼受付部１１がサービス割当要求を受け付けると、保持部１３で記憶している図３（Ｂ）に示した割当サービステーブルから情報を取得する。そして、割当決定部１５は、スライス要件取得部１２が取得した割当サービステーブルのＳＬＡ―ＳＬを参照し、受信したＳＬＡ―ＳＬを満たすスライスＩＤを決定する。ここでは、ＳＬＡ―ＳＬのmobilityが「３」であるので、他の要件も満たしている場合には、「S-slice ID」欄に入力されているサービススライスＩＤが「２」のスライスにサービスを割当てることを決定する（ステップＳ３２）。また、割当決定部１５は、割当対象のサービスパラメータと同一のサービスパラメータが割当サービステーブルに記憶されているか否かを確認する（割当対象のサービスパラメータが割当サービステーブルに記憶されているか否かを確認する）。既に当該サービスパラメータを含む情報が記憶されており、別のサービススライスＩＤに対応付けられているので、割当決定部１５は、割当対象のサービスパラメータと、割当先のサービススライスを対応付けるように割当サービステーブルを更新する。このように、ＳＬＡ―ＳＬのmobilityが上がると、以前割り当てたスライスとは別のスライスへ割り当てる。

ステップＳ３３〜ステップＳ３８の処理は、ステップＳ３〜ステップＳ８の処理とそれぞれ同じであるので、説明を省略する。なお、既にＵＥ９０には、サービスパラメータを通知済みであるので、ステップＳ９及びステップＳ１０に対応する処理を行わない。ステップＳ３９〜ステップＳ４８の処理は、ステップＳ１１〜ステップＳ２０の処理とそれぞれ同じであるので、説明を省略する。上述のように、以前割り当てたスライスとは別のスライスへ割り当てることにより、サービスを利用するためのデータを送受信するＳＧＷ１４０を変更する（ステップＳ３３〜ステップＳ３８）。

続いて、図１６のシーケンス図を用いて、本実施形態に係るシステム１で実行される処理を説明する。ここでは、所定のタイミングでリソースの状況に基づいて、サービススライスの割当をする処理方法について説明する。

所定のタイミングで、ＯＳＳ／ＢＳＳ１０のリソース取得部１４は、ＮＦＶＯ３０へスライスＩＤと当該スライスのファンクションセットを送信すると共にリソースの利用状況の要求をする（ステップＳ５１）。ＮＦＶＯ３０のリソース要求受付部３４は、ＶＮＦＭ４０へ当該ファンクションセットに対応するＶＭを要求して、ＶＮＦＭ４０の構成要求受付部４１は、当該要求を受け付け、上記ファンクションセットのそれぞれのＶＭをＮＦＶＯ３０へ通知する（ステップＳ５２）。ＮＦＶＯ３０のリソース要求受付部３４は、ＶＩＭ５０へリソース利用状況の取得要求をする（ステップＳ５３）。ＶＩＭ５０のリソース要求受付部５１は、当該リソース要求を受け付けると、保持部５２で記憶している情報を検索して、リソース通知部５３は、それぞれのＶＭの使用率をＮＦＶＯ３０へ通知する。ＮＦＶＯ３０のリソース通知部３５は、スライス毎にファンクションセットを構成するＶＭの使用状況をＯＳＳ／ＢＳＳ１０へ送信する（ステップＳ５４）。ＯＳＳ／ＢＳＳ１０の割当決定部１５は、各スライスのＳＬＡ―ＳＬと、スライス毎のファンクションセットのＶＭの使用状況に基づいて、割り当てるスライスを決定する（ステップＳ５５）。具体的には、割当決定部１５は、要求サービス管理テーブルで記憶されているサービスパラメータのＳＬＡ―ＳＬを満たすＳＬＡ―ＳＬを有する割当サービステーブルのレコードを特定し、当該レコードが示すサービススライスの内、リソースに最も空きがあるサービススライスに割り当てると決定する。割当要求部１６は、割当後のサービススライスＩＤと、サービスパラメータと、端末情報とを、ＮＦＶＯ３０へ通知する（ステップＳ５６）。ステップＳ５７〜ステップＳ５９、ステップＳ６１、ステップＳ６２は、ステップＳ４〜ステップＳ６、ステップＳ７、ステップＳ８とそれぞれ同様であるため、説明を省略する。ＶＮＦＭ４０は、端末情報をＭＭＥ１３０へ送信する（ステップＳ６０）。また、ＭＭＥ１３０は、それぞれのＵＥ９０へアクセス先のＭＭＥ１３０を通知する（ステップＳ６３）。ステップＳ６３〜ステップＳ７２の処理は、ステップＳ１１〜ステップＳ２０の処理とそれぞれ同じであるので、説明を省略する。なお、上記ステップＳ５５及びステップＳ５６の処理は、サービススライスＩＤを変更することにより、接続先のＭＭＥが変わる場合のみ実行する。

図１６のシーケンスでは、ＯＳＳ／ＢＳＳ１０が定期的にリソース使用状況の情報を取得要求をする場合について述べたが、ＮＦＶＯ３０が、ハードウェアのリソース使用状況（ＶＭの使用率、ハードウェアの使用率）を監視して、上記リソース使用状況が一定値（例えば、９０％）を超えたタイミングで、ＮＦＶＯ３０が上述のシーケンスと同様にリソースの使用状況の情報をスライス毎に取得し、当該情報をＯＳＳ／ＢＳＳ１０へ送信する共に、サービス割当変更要求をするようにしてもよい。

つぎに、本実施形態のシステム１の作用効果について説明する。ＯＳＳ／ＢＳＳ１０では、スライスが割当てられているサービスと当該スライスとの対応付けをした割当サービステーブルの情報を保持する。また、ＯＳＳ／ＢＳＳ１０の依頼受付部１１は、機能の要件であるＳＬＡ―ＳＬを受信する。割当決定部１５は、受け付けられたサービスのサービス要件（ＳＬＡ―ＳＬ）に対応する（サービス要件を満たす）ＳＬＡ―ＳＬを有するスライスを決定する。割当要求部１６は、割当対象のサービスが、予めスライスに対応付けられている場合、決定されたスライスへサービスを割当てし直す。

この場合、システム１は、割当要求を受けた際に、サービス要件を満たすスライスへ割り当て直すので、仮にサービス要件が変更されても、変更されたサービス要件を満たすスライスへ割り当てし直すことができる。このように、動的に変更されるサービス要件に対応して割り当てるスライスを動的に変更することができ、適切なサービスを提供することができる。

また、システム１は、割当要求部１６は、ＮＦＶＯ３０に対して、割当決定部１５から受信した端末情報、サービスパラメータ、及び割り当てるサービススライスをＮＦＶＯ３０へ送信すると共に、割当要求をする。ＮＦＶＯ３０は、当該割当要求に応じて、ＶＮＦＭ４０に当該サービスパラメータに対応するＳＧＷのアドレスを変更させる。このように、割当要求部１６が割当要求することにより、サービスを利用するためのデータを送受信する通信制御装置を変更する。従って、サービス要件に応じて、当該サービスのデータを送受信する通信制御装置を切り替えるのでサービスを利用するユーザに対して好適なサービスを提供することができる。

また、リソース取得部１４は、所定のタイミングで、スライス毎のリソース状況を取得する。スライス要件取得部１２は、既にスライスが割り当てられているサービスのサービス要件と共に、各スライスのＳＬＡ―ＳＬを特定する。割当決定部１５は、サービスのサービス要件と、各スライスのＳＬＡ―ＳＬと、リソース状況とに基づいて割り当てるスライスを決定する。

この場合、リソースの状況情報を考慮して、サービスに割り当てるスライスを決定するので、リソース状況が変動した場合でも適切なスライスを動的に割当てることができる。

割当決定部１５は、サービス要件を満たすスライスの内、空リソースが最も多いスライスに決定する。この場合、空リソースが最も多いリソースのスライスにサービスを割当てるので、リソースの有効活用することができる。

ソフトウェアは、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語と呼ばれるか、他の名称で呼ばれるかを問わず、命令、命令セット、コード、コードセグメント、プログラムコード、プログラム、サブプログラム、ソフトウェアモジュール、アプリケーション、ソフトウェアアプリケーション、ソフトウェアパッケージ、ルーチン、サブルーチン、オブジェクト、実行可能ファイル、実行スレッド、手順、機能などを意味するよう広く解釈されるべきである。

また、ソフトウェア、命令などは、伝送媒体を介して送受信されてもよい。例えば、ソフトウェアが、同軸ケーブル、光ファイバケーブル、ツイストペア及びデジタル加入者回線（ＤＳＬ）などの有線技術及び／又は赤外線、無線及びマイクロ波などの無線技術を使用してウェブサイト、サーバ、又は他のリモートソースから送信される場合、これらの有線技術及び／又は無線技術は、伝送媒体の定義内に含まれる。

本明細書で説明した情報、信号などは、様々な異なる技術のいずれかを使用して表されてもよい。例えば、上記の説明全体に渡って言及され得るデータ、命令、コマンド、情報、信号、ビット、シンボル、チップなどは、電圧、電流、電磁波、磁界若しくは磁性粒子、光場若しくは光子、又はこれらの任意の組み合わせによって表されてもよい。

なお、本明細書で説明した用語及び／又は本明細書の理解に必要な用語については、同一の又は類似する意味を有する用語と置き換えてもよい。例えば、チャネル及び／又はシンボルは信号（シグナル）であってもよい。また、信号はメッセージであってもよい。また、コンポーネントキャリア（ＣＣ）は、キャリア周波数、セルなどと呼ばれてもよい。

本明細書で使用する「システム」および「ネットワーク」という用語は、互換的に使用される。

また、本明細書で説明した情報、パラメータなどは、絶対値で表されてもよいし、所定の値からの相対値で表されてもよいし、対応する別の情報で表されてもよい。例えば、無線リソースはインデックスで指示されるものであってもよい。

上述したパラメータに使用する名称はいかなる点においても限定的なものではない。さらに、これらのパラメータを使用する数式等は、本明細書で明示的に開示したものと異なる場合もある。様々なチャネル（例えば、ＰＵＣＣＨ、ＰＤＣＣＨなど）及び情報要素（例えば、ＴＰＣなど）は、あらゆる好適な名称によって識別できるので、これらの様々なチャネル及び情報要素に割り当てている様々な名称は、いかなる点においても限定的なものではない。

基地局は、１つまたは複数（例えば、３つ）の（セクタとも呼ばれる）セルを収容することができる。基地局が複数のセルを収容する場合、基地局のカバレッジエリア全体は複数のより小さいエリアに区分でき、各々のより小さいエリアは、基地局サブシステム（例えば、屋内用の小型基地局ＲＲＨ：Ｒｅｍｏｔｅ Ｒａｄｉｏ Ｈｅａｄ）によって通信サービスを提供することもできる。「セル」または「セクタ」という用語は、このカバレッジにおいて通信サービスを行う基地局、および／または基地局サブシステムのカバレッジエリアの一部または全体を指す。さらに、「基地局」「ｅＮＢ」、「セル」、および「セクタ」という用語は、本明細書では互換的に使用され得る。基地局は、固定局（fixed station）、ＮｏｄｅＢ、ｅＮｏｄｅＢ（ｅＮＢ）、アクセスポイント（access point）、フェムトセル、スモールセルなどの用語で呼ばれる場合もある。

移動局は、当業者によって、加入者局、モバイルユニット、加入者ユニット、ワイヤレスユニット、リモートユニット、モバイルデバイス、ワイヤレスデバイス、ワイヤレス通信デバイス、リモートデバイス、モバイル加入者局、アクセス端末、モバイル端末、ワイヤレス端末、リモート端末、ハンドセット、ユーザエージェント、モバイルクライアント、クライアント、またはいくつかの他の適切な用語で呼ばれる場合もある。

また、本明細書で使用する「決定(determining)」という用語は、多種多様な動作を包含する。「決定」は、例えば、判定(judging)、計算(calculating)、算出(computing)、処理(processing)、導出(deriving)、調査(investigating)、探索(looking up)（例えば、テーブル、データベースまたは別のデータ構造での探索）、確認(ascertaining)した事を「決定」したとみなす事などを含み得る。また、「決定」は、受信(receiving)（例えば、情報を受信すること）、送信(transmitting)（例えば、情報を送信すること）、入力(input)、出力(output)、アクセス(accessing)（例えば、メモリ中のデータにアクセスすること）した事を「決定」したとみなす事などを含み得る。また、「決定」は、解決(resolving)、選択(selecting)、選定(choosing)、確立(establishing)、比較(comparing)などした事を「決定」したとみなす事を含み得る。つまり、「決定」は、何らかの動作を「決定」したとみなす事を含み得る。

「接続された(connected)」、「結合された(coupled)」という用語、又はこれらのあらゆる変形は、２又はそれ以上の要素間の直接的又は間接的なあらゆる接続又は結合を意味し、互いに「接続」又は「結合」された２つの要素間に１又はそれ以上の中間要素が存在することを含むことができる。要素間の結合又は接続は、物理的なものであっても、論理的なものであっても、或いはこれらの組み合わせであってもよい。本明細書で使用する場合、２つの要素は、１又はそれ以上の電線、ケーブル及び／又はプリント電気接続を使用することにより、並びにいくつかの非限定的かつ非包括的な例として、無線周波数領域、マイクロ波領域及び光（可視及び不可視の両方）領域の波長を有する電磁エネルギーなどの電磁エネルギーを使用することにより、互いに「接続」又は「結合」されると考えることができる。

本明細書で使用する「に基づいて」という記載は、別段に明記されていない限り、「のみに基づいて」を意味しない。言い換えれば、「に基づいて」という記載は、「のみに基づいて」と「に少なくとも基づいて」の両方を意味する。

また、上記の各装置の構成における「手段」を、「部」、「回路」、「デバイス」等に置き換えてもよい。

「含む(ｉｎｃｌｕｄｉｎｇ)」、「含んでいる（ｃｏｍｐｒｉｓｉｎｇ）」、およびそれらの変形が、本明細書あるいは特許請求の範囲で使用されている限り、これら用語は、用語「備える」と同様に、包括的であることが意図される。さらに、本明細書あるいは特許請求の範囲において使用されている用語「または（or）」は、排他的論理和ではないことが意図される。

なお、情報の通知は、本明細書で説明した態様／実施形態に限られず、他の方法で行われてもよい。例えば、情報の通知は、物理レイヤシグナリング（例えば、ＤＣＩ（Downlink Control Information）、ＵＣＩ（Uplink Control Information））、上位レイヤシグナリング（例えば、ＲＲＣ（Radio Resource Control）シグナリング、ＭＡＣ（Medium Access Control）シグナリング、報知情報（ＭＩＢ（Master Information Block）、ＳＩＢ（System Information Block）））、その他の信号又はこれらの組み合わせによって実施されてもよい。また、ＲＲＣシグナリングは、ＲＲＣメッセージと呼ばれてもよく、例えば、ＲＲＣ接続セットアップ（RRC Connection Setup）メッセージ、ＲＲＣ接続再構成（RRC Connection Reconfiguration）メッセージなどであってもよい。

また、本明細書で説明した各態様／実施形態は、ＬＴＥ（Long Term Evolution）、ＬＴＥ−Ａ（LTE-Advanced）、ＳＵＰＥＲ ３Ｇ、ＩＭＴ−Ａｄｖａｎｃｅｄ、４Ｇ、５Ｇ、ＦＲＡ（Future Radio Access）、Ｗ−ＣＤＭＡ（登録商標）、ＧＳＭ（登録商標）、ＣＤＭＡ２０００、ＵＭＢ（Ultra Mobile Broadband）、ＩＥＥＥ ８０２．１１（Ｗｉ−Ｆｉ）、ＩＥＥＥ ８０２．１６（ＷｉＭＡＸ）、ＩＥＥＥ ８０２．２０、ＵＷＢ（Ultra-WideBand）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、その他の適切なシステムを利用するシステム及び／又はこれらに基づいて拡張された次世代システムに適用されてもよい。

また、本明細書で説明した各態様／実施形態の処理手順、シーケンス、フローチャートなどは、矛盾の無い限り、順序を入れ替えてもよい。例えば、本明細書で説明した方法については、例示的な順序で様々なステップの要素を提示しており、提示した特定の順序に限定されない。

また、本明細書において基地局によって行われるとした特定動作は、場合によってはその上位ノード（upper node）によって行われることもある。基地局を有する１つまたは複数のネットワークノード（network nodes）からなるネットワークにおいて、端末との通信のために行われる様々な動作は、基地局および／または基地局以外の他のネットワークノード(例えば、MMEまたはS-GWなどが考えられるが、これらに限られない)によって行われ得ることは明らかである。上記において基地局以外の他のネットワークノードが１つである場合を例示したが、複数の他のネットワークノードの組み合わせ(例えば、MMEおよびS-GW)であってもよい。

上記の情報等は、上位レイヤ（または下位レイヤ）から下位レイヤ（または上位レイヤ）へ出力され得る。複数のネットワークノードを介して入出力されてもよい。

入出力された情報等は特定の場所（例えば、メモリ）に保存されてもよいし、管理テーブルで管理してもよい。入出力される情報等は、上書き、更新、または追記され得る。出力された情報等は削除されてもよい。入力された情報等は削除されてもよい。入力された情報等は他の装置へ送信されてもよい。

判定は、１ビットで表される値（０か１か）によって行われてもよいし、真偽値(Boolean：trueまたはfalse)によって行われてもよいし、数値の比較（例えば、所定の値との比較）によって行われてもよい。

本明細書で説明した各態様／実施形態は単独で用いてもよいし、組み合わせて用いてもよいし、実行に伴って切り替えて用いてもよい。また、所定の情報の通知（例えば、「Ｘであること」の通知）は、明示的に行うものに限られず、暗黙的（例えば、当該所定の情報の通知を行わない）ことによって行われてもよい。

本開示の全体において、明らかに単数であることを示しているものではない限り、単数および複数の両方のものを含むものとする。

以上、本発明について詳細に説明したが、当業者にとっては、本発明が本明細書中に説明した実施形態に限定されるものではないということは明らかである。本発明は、特許請求の範囲の記載により定まる本発明の趣旨及び範囲を逸脱することなく修正及び変更態様として実施することができる。したがって、本明細書の記載は、例示説明を目的とするものであり、本発明に対して何ら制限的な意味を有するものではない。

１…システム、１０…ＯＳＳ／ＢＳＳ、１１…依頼受付部、１２…スライス要件取得部、１３…保持部、１４…リソース取得部、１５…割当決定部、１６…割当要求部、２０…ＳＯ、３０…ＮＦＶＯ、３１…サービス割当要求部、３２…保持部、３３…ファンクション検索部、３４…リソース要求受付部、３５…リソース通知部、４０…ＶＮＦＭ、４１…構成要求受付部、４２…保持部、４３…検索部、４４…編集要求部、５０…ＶＩＭ、５１…リソース要求受付部、５２…保持部、５３…リソース通知部、６０…ＮＦＶＩ、７０…ＳＢＳＡ、８０…基地局、９０…ＵＥ、１０１…ＣＰＵ、１０２…ＲＡＭ、１０３…ＲＯＭ、１０４…通信モジュール、１０５…補助記憶装置。

Claims (4)

1. ネットワークインフラ上に生成される仮想ネットワークであるスライスに対して、当該仮想ネットワークを用いるサービスを割当てる装置で実行されるサービス割当決定方法であって、
   前記装置では、スライスが割当てられているサービスと当該スライスとの対応付けがなされており、
   割当対象のサービスにおける機能の要件であるサービス要件を満たすスライスを決定する決定ステップと、
   前記割当対象となるサービスが、前記装置により予めスライスに対応付けられている場合、前記決定ステップにより決定されたスライスへ前記割当対象のサービスを割当てし直す割当ステップとを含むサービス割当決定方法。
2. 前記サービスを利用するためのデータを送受信する通信制御装置を変更することにより、前記割当対象のサービスを割当てし直す、請求項１に記載のサービス割当決定方法。
3. スライス毎のリソース状況と、既にスライスが割り当てられているサービスのサービス要件を取得する取得ステップ、をさらに含み、
   前記決定ステップは、前記取得ステップにより取得されたサービス要件及びリソース状況に基づいて割り当てるスライスを決定する、請求項１又は２に記載のサービス割当決定方法。
4. 前記決定ステップは、前記サービス要件を満たすスライスの内、空リソースが最も多いスライスに決定する、請求項３に記載のサービス割当決定方法。

Images