WO2017154728A1 - スライス割当方法 - Google Patents

Abstract

サービスマッピング装置１０では、既にスライスが割り当てられているサービスと、当該スライスと、当該サービスを実行する装置を示すアドレスとを対応付けた割当サービステーブルを記憶している。また、サービスマッピング装置１０の依頼受付部１１は、機能の要件であるＳＬＡ―ＳＬを受信する。決定部１５は、受け付けられたサービスのサービス要件（ＳＬＡ―ＳＬ）に対応する（サービス要件を満たす）ＳＬＡ―ＳＬを有するスライスを決定する。割当部１６は、割当対象のサービスが、予めスライスに対応付けられている場合、決定されたスライスにサービスを割り当て変更する。

Description

スライス割当方法

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

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

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

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

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

　上記目的を達成するために、本発明の一側面に係るスライス割当方法は、ネットワークインフラ上に生成される仮想ネットワークであるスライスに対して、当該仮想ネットワークを用いるサービスを割り当てる第１装置で実行されるスライス割当方法であって、第１装置では、既にスライスが割り当てられているサービスと、当該スライスと、当該サービスを実行する装置を示す接続先とを対応付けた情報である対応情報を予め記憶しており、割当対象のサービスにおける機能の要件であるサービス要件を満たすスライスを決定する決定ステップと、対応情報により割当対象のサービスに対応付けられているスライスから、決定ステップにより決定されたスライスへ割当て変更する割当ステップと、を含む。

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

　上記のスライス割当方法は、ユーザからのサービスの利用要求に応じて、当該サービスの接続先を当該ユーザと通信接続する通信装置へ通知する第２装置に対して、割当ステップにより変更されたスライスに対応する接続先への接続先の変更を要求する変更要求ステップをさらに含んでもよい。この場合、スライスの割当変更した後に、第２装置へ接続先の変更要求をするので、ユーザからのサービス利用要求に応じて、適切にユーザへ変更後の接続先を通知することができる。

　上記のスライス割当決定方法は、割当対象のサービス及びサービス要件を新規に取得する要件取得ステップをさらに含み、決定ステップは、要件取得ステップにより取得されたサービス要件を満たすスライスを決定してもよい。この場合、サービス要件に応じて、当該サービスのデータを送受信する通信制御装置を切り替えるのでサービスを利用するユーザに対して好適なサービスを提供することができる。

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

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

　サービスと当該サービスに割り当てるスライスを動的に変えることができる。

本発明の実施形態に係るシステムの構成を示す図である。 スライスとリソースとの対応関係を示す図である。 本発明の実施形態に係るシステムに含まれる装置のブロック図である。 割当サービステーブルを示す図である。 スライステーブルを示す図である。 ユーザ利用サービステーブルを示す図である。 サービスパラメータアドレステーブルである。 ファンクションセットテーブルを示す図である。 ファンクション要件テーブルを示す図である。 ＶＭ機能テーブルを示す図である。 ＶＭ使用率テーブルを示す図である。 ハードウェア使用率テーブルを示す図である。 サービスマッピング装置等のハードウェア構成図である。 新規サービス処理を示すシーケンス図である。 サービス再割り当て処理を示すシーケンス図である。 再割り当てによるデータの変化を示す図である。 リソースに基づくサービス再割り当て処理を示すシーケンス図である。 リソースの変化例を示す図である。 ＨＳＳ７０へ編集要求する場合のサービス再割り当て処理を示すシーケンス図である。 再割り当てにより、ＨＳＳ７０で記憶しているデータの変化を示す図である。 ＨＳＳ７０へ編集要求する場合のリソースに基づくサービス再割り当て処理を示すシーケンス図である。 ＨＳＳ７０で記憶するデータの変形例である。

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

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

　図１に示すようにシステム１は、サービスマッピング装置１０（第１装置）と、ＳＯ（Service　Operator）２０と、ＯＳＳ／ＢＳＳ（Operations　Support　System／Business　Support　System）３０と、ＮＦＶＯ４０と、ＶＮＦＭ５０と、ＶＩＭ(Virtualized　Infrastructure　Management:仮想化基盤管理)６０と、ＨＳＳ（Home Subscriber Server）７０（第２装置）と、ＤＮＳ（Domain　Name　System）サーバ８０（第２装置）と、ＭＭＥ（Mobility　Management　Entity）９０と、ｅＮＢ１００と、ＳＧＷ（Serving　Gateway）１１０と、ＰＧＷ（Packet　data　network　gateway）１２０と、ＵＥ（User　Equipment）１３０とを含んで構成されている。このうち、ＮＦＶＯ４０とＶＮＦＭ５０とＶＩＭ６０とは、ＭＡＮＯ（Management　&　Orchestration）architectureである。

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

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

　サービスマッピング装置１０は、システム１におけるサービス管理を行い、システム１での通信機能に係る指示を行うノードである。また、サービスマッピング装置１０は、システム１に係る通信事業者によって操作され得る。

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

　ＯＳＳ／ＢＳＳ３０は、ＳＯ２０からのサービス要求を受け付けて、サービスマッピング装置１０へその要求を通知する装置である。

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

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

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

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

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

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

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

　例えば図２に示すように、ＮＦＶＯ４０がスライス（Ｓｌｉｃｅ１及びＳｌｉｃｅ２）のためのリソース確保要求をＶＩＭ６０へ行うと、ＶＩＭ６０は、その旨の指示をスイッチＳＷ１、スイッチＳＷ２、サーバＳＶ１、及びスイッチＳＷ３に対して行う。そして、これらスイッチＳＷ１、スイッチＳＷ２、サーバＳＶ１、及びスイッチＳＷ３はＳｌｉｃｅ１用にリソースを確保する。同様に、ＶＩＭ６０からの指示に従って、スイッチＳＷ１、スイッチＳＷ２、サーバＳＶ１、及びスイッチＳＷ４は、Ｓｌｉｃｅ２用にリソースを確保する。

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

　上述のように、ＶＮＦＭ５０が、物理資源（ノード）となるＮＦＶＩ１６０に対して、各種機能を追加することにより、ＮＦＶＩ１６０は、ＨＳＳ７０、ＤＮＳサーバ８０、ＭＭＥ９０、ＳＧＷ１１０、及びＰＧＷ１２０の機能を実現する。

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

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

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

　ｅＮＢ１００は、ＭＭＥ９０に接続された無線基地局であるとともに、無線アクセス制御機能を有した装置である。

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

　ＰＧＷ１２０は、ＰＤＮ（Packet　data　network）との接合点であり、ＩＰアドレスの割当てや、ＳＧＷ１１０へのパケット転送などを行うゲートウェイである。

　引き続いて、サービスマッピング装置１０について、本実施形態に係る機能について図３を用いて説明する。

　図３に戻り、サービスマッピング装置１０の機能を説明する。図３に示すようにサービスマッピング装置１０は、依頼受付部１１と、保持部１２と、スライス要件取得部１３と、リソース取得部１４と、決定部１５と、割当部１６と、登録要求部１７とを有する。

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

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

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

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

　保持部１２は、各種テーブルを記憶する部分である。保持部１２は、割当サービステーブル（対応情報）及びスライステーブルを記憶する。図４に、割当サービステーブルを示す。図４に示すように、割当サービステーブルは、「Ｓｅｒｖｉｃｅ　ｐａｒａｍｅｔｅｒ」欄と「ＳＬＡ－ＳＬ」欄と「ＮＷ　ｓｌｉｃｅＩＤ」欄とを対応付けた情報を記憶する。ここで、「Ｓｅｒｖｉｃｅ　ｐａｒａｍｅｔｅｒ」欄及び「ＳＬＡ－ＳＬ」欄の情報は、ＯＳＳ／ＢＳＳ３０からサービス要求を受け付けたサービスを特定する情報であり、ＯＳＳ／ＢＳＳ３０から受信する情報である。「ＮＷ　ｓｌｉｃｅＩＤ」欄の情報は、ＮＦＶＯ４０から受信する情報である。図４の例では、「Ｓｅｒｖｉｃｅ　ｐａｒａｍｅｔｅｒ」欄に入力されている「Ｓｍａｒｔ　ｍｅｔｅｒ」であるサービスパラメータに「ＮＷ　ｓｌｉｃｅＩＤ」（スライスを識別するスライスＩＤ）が「２」であるスライスが割り当てられていることを示す。

　図５に、スライステーブルを示す。図５に示すように、スライステーブルは、「ＮＷ　ｓｌｉｃｅＩＤ」欄と「Ｆｕｎｃｔｉｏｎ」欄と「Ｕｓａｇｅ」欄と「ＩＰ　ａｄｒｅｓｓ」欄と「ＳＬＡ－ＳＬ」欄とを対応付けた情報を記憶する。「ＮＷ　ｓｌｉｃｅＩＤ」欄、「Ｆｕｎｃｉｏｔｎ」欄、「Ｕｓａｇｅ」欄、「ＩＰ　ａｄｒｅｓｓ」欄、及び「ＳＬＡ－ＳＬ」欄の情報は、ＮＦＶＯ４０から受信する情報である。図５の例では、「ＮＷ　ｓｌｉｃｅＩＤ」が「１」であるスライスは、Ｕｓａｇｅが６０％であり、ＳＬＡ－ＳＬが「３，３，３，１」であることを示す。ＭＡＮＯでスライスが新規に生成されると、サービスマッピング装置１０は、新規に生成されたスライスについての「ＮＷ　ｓｌｉｃｅＩＤ」欄の情報と「Ｆｕｎｃｔｉｏｎ」欄の情報と「Ｕｓａｇｅ」欄の情報と「ＩＰ　ａｄｒｅｓｓ」欄の情報と「ＳＬＡ－ＳＬ」欄の情報とを取得し、保持部１２のスライステーブルに記憶する。また、保持部１２は、要求サービス管理テーブルも記憶する。この要求サービス管理テーブルは、「Ｓｅｒｖｉｃｅ　ｐａｒａｍｅｔｅｒ」欄と「ＳＬＡ－ＳＬ」欄とが対応付けられたテーブルである。「Ｓｅｒｖｉｃｅ　ｐａｒａｍｅｔｅｒ」欄には、依頼受付部１１がＯＳＳ／ＢＳＳ３０から受信したサービスパラメータが入力されている。「ＳＬＡ－ＳＬ」欄には、依頼受付部１１がＯＳＳ／ＢＳＳ３０から受信したＳＬＡ－ＳＬが入力されている。また、上記要求サービス管理テーブルには、上記２つの欄以外に「端末情報」欄も対応付けられている。この「端末情報」欄には、依頼受付部１１がＯＳＳ／ＢＳＳ３０から受信した端末情報が入力されている。

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

　リソース取得部１４は、依頼受付部１１からリソース取得要求を受け付けると、ＮＦＶＯ４０へリソース取得要求をする。リソース取得部１４は、当該リソース取得要求に応じて、ＮＦＶＯ４０からリソース情報を受信する。リソース取得部１４は、当該リソース情報をスライステーブルへ更新する。また、リソース取得部１４は、依頼受付部１１の要求に応じてスライステーブルを参照し、スライス毎の利用率を決定部１５へ送出する。

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

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

　割当部１６は、割当サービステーブルにより割当対象のサービスに対応付けられているスライスから、決定部１５により決定されたスライスへ割当て変更する部分である。割当部１６は、割当対象のサービスパラメータと、割当先のスライスを対応付けるように割当サービステーブルを更新する。また、割当部１６は、新規にサービスパラメータにスライスを割り当てる場合、サービスパラメータ、ＳＬＡ－ＳＬ、及び端末情報を要求サービス管理テーブルへ登録する。また、割当部１６は、サービスパラメータと当該サービスパラメータに対応するＩＰアドレスを登録要求部１７へ通知する。

　登録要求部１７は、ユーザからのサービスの利用要求に応じて当該サービスの接続先を当該ユーザへ通知するＤＮＳサーバ８０に対して、割当部１６により変更されたスライスに対応する接続先への接続先の変更を要求する部分である。登録要求部１７は、サービスの接続先（ＩＰアドレス）とサービスパラメータをＤＮＳサーバ８０又はＨＳＳ７０へ送信する。また、登録要求部１７は、新たにサービスを登録する場合、端末情報（ユーザＩＤ）及びサービスパラメータをＨＳＳ７０へ送信する。

　登録要求部１７は、ＨＳＳ７０及びＤＮＳサーバ８０へ登録要求をする部分である。登録要求部１７は、ＮＦＶＯ４０から機能セット（機能のリスト）、端末情報、スライスＩＤ及びサービスパラメータを受信すると共に、上記登録要求を受け付ける。登録要求部１７は、上記端末情報、スライスＩＤ、及びサービスパラメータを送信し、ＨＳＳ７０へ編集要求をする。ここで、ＨＳＳ７０が記憶している情報の例を図６に示す。ＨＳＳ７０は、図６に示すように、「Ｕｓｅｒ　ＩＤ」欄と「Ｓｅｒｖｉｃｅ　Ｐａｒａｍｅｔｅｒ」欄とを対応付けた情報を上記変更要求に応じて記憶する。「Ｕｓｅｒ　ＩＤ」欄には、ユーザを識別する情報であり、例えば、ＩＭＳＩ等の情報が入力される。「Ｓｅｒｖｉｃｅ　Ｐａｒａｍｅｔｅｒ」欄には、サービスパラメータが入力される。

　また、登録要求部１７は、設定対象のスライスＩＤを検索キーとして、スライステーブルからＩＰアドレスを取得する。そして、登録要求部１７は、当該ＩＰアドレスとサービスパラメータとをＤＮＳサーバ８０へ送信すると共に編集要求する。ここで、ＤＮＳサーバ８０が記憶している情報の例を図７に示す。ＤＮＳサーバ８０は、図７に示すように、「Ｓｅｒｖｉｃｅ　Ｐａｒａｍｅｔｅｒ」欄と「ＩＰ　Ａｄｄｒｅｓｓ」欄とを対応付けた情報を上記編集要求に応じて記憶する。「Ｓｅｒｖｉｃｅ　Ｐａｒａｍｅｔｅｒ」欄には、サービスパラメータが入力される。「ＩＰ　Ａｄｄｒｅｓｓ」欄には、アクセス先を示すアドレス情報が入力される。ＤＮＳサーバ８０は、上記編集要求を受信すると、要求対象のサービスパラメータの情報が入力されていない場合には、新たにサービスパラメータと、上記アドレス情報を登録する。既にサービスパラメータが登録されている場合には、当該サービスパラメータに対応するアドレス情報を、要求対象のアドレス情報に変更する。

　続いて、ＮＦＶＯ４０の機能の説明をする。ＮＦＶＯ４０は、保持部４１と、リソース要求受付部４２と、リソース通知部４３とを備える。

　保持部４１は、各種テーブルを記憶する部分である。保持部４１は、ファンクションセットテーブル及びファンクション要件テーブルを記憶する。図８にファンクションセットテーブルを示す。このファンクションセットテーブルは、「Ｓｌｉｃｅ　ＩＤ」欄と「Ｆｕｎｃｉｔｏｎ　Ｓｅｔ」欄とを対応付けた情報を記憶するテーブルである。「Ｓｌｉｃｅ　ＩＤ」欄には、スライスを識別するスライスＩＤが入力されている。「Ｆｕｎｃｉｔｏｎ　Ｓｅｔ」欄には、ファンクションセットを示す情報が入力されている。図９にファンクション要件テーブル示す。ファンクション要件テーブルは、「Ｆｕｎｃｔｉｏｎ」欄と「ＳＬＡ－ＳＬ」欄とを対応付けた情報を記憶するテーブルである。図９に示す「Ｆｕｎｃｉｔｏｎ」欄には、ファンクションを示す情報が入力されている。また、「ＳＬＡ－ＳＬ」欄には、当該ファンクションに対応するＳＬＡ－ＳＬを示す情報が入力されている。

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

　リソース通知部４３は、リソース要求受付部４２から受信したリソース利用状況をスライス毎にサービスマッピング装置１０へ送信する。

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

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

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

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

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

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

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

　なお、ＣＰＵ１０１などのプロセッサ（Processor）が図３における各機能を実行することに代えて、その機能全部または一部を専用の集積回路（ＩＣ：integrated　circuit）を構築することにより各機能を実行するように構成してもよい。例えば、画像処理や通信制御を行なうための専用の集積回路を構築することにより上記機能を実行するようにしてもよい。

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

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

　なお、サービスマッピング装置１０、ＮＦＶＯ４０、ＶＮＦＭ５０及びＶＩＭ６０は複数のサーバ装置からなるコンピュータシステムによって構成されていてもよい。また、システム１に含まれる上記以外のノードも上記のハードウェア構成を有するサーバ装置によって実現されてもよい。また、ｅＮＢ１００やＵＥ１３０（移動通信端末）の各機能の一部又は全ては、ＡＳＩＣ（Application　Specific　Integrated　Circuit）、ＰＬＤ（Programmable　Logic　Device）、ＦＰＧＡ（Field　Programmable　Gate　Array）などのハードウェアを用いて実現されても良い。また、ｅＮＢ１００やＵＥ１３０は、プロセッサ（ＣＰＵ）と、ネットワーク接続用の通信インターフェースと、メモリと、プログラムを保持したコンピュータ読み取り可能な記憶媒体と、を含むコンピュータ装置によって実現されてもよい。つまり、本発明の一実施形態に係るｅＮＢ１００やＵＥ１３０などは、本発明の一側面に係る処理を行うコンピュータとして機能してもよい。

　ここで、プロセッサやメモリなどは情報を通信するためのバスで接続される。また、コンピュータ読み取り可能な記録媒体は、例えば、フレキシブルディスク、光磁気ディスク(例えば、コンパクトディスク、デジタル多用途ディスク、Ｂｌｕ－ｒａｙ（登録商標）ディスク)、スマートカード、フラッシュメモリデバイス(例えば、カード、スティック、キードライブ)、ＲＯＭ、ＥＰＲＯＭ（Erasable　Programmable　ＲＯＭ）、ＥＥＰＲＯＭ（Electrically Erasable Programmable ＲＯＭ）、ＣＤ－ＲＯＭ（Compact　Disc－ＲＯＭ）、ＲＡＭ、レジスタ、リムーバブルディスク、ハードディスク、フロッピー（登録商標）ディスク、磁気ストリップ、データベース、サーバその他の適切な記憶媒体である。また、プログラムは、電気通信回線を介してネットワークから送信されても良い。また、ｅＮＢ１００やＵＥ１３０は、入力キーなどの入力装置や、ディスプレイなどの出力装置を含んでいてもよい。

　ｅＮＢ１００及びＵＥ１３０の機能構成は、上述のハードウェアによって実現されてもよいし、プロセッサによって実行されるソフトウェアモジュールによって実現されてもよいし、両者の組み合わせによって実現されてもよい。プロセッサは、オペレーティングシステムを動作させてユーザ端末の全体を制御する。また、プロセッサは、記憶媒体からプログラム、ソフトウェアモジュールやデータをメモリに読み出し、これらに従って各種の処理を実行する。

　ここで、当該プログラムは、発明の実施形態で説明する各動作を、コンピュータに実行させるプログラムであれば良い。例えば、移動通信端末の制御部は、メモリに格納され、プロセッサで動作する制御プログラムによって実現されてもよく、他の機能ブロックについても同様に実現されてもよい。

　引き続いて、図１４のシーケンス図を用いて、本実施形態に係るシステム１で実行される処理を説明する。ここでは、ＳＯ２０からサービス割当要求がある場合の例とする。

　ＳＯ２０は、上記サービスを示すサービスパラメータ、ＳＬＡ―ＳＬ及び当該サービスを利用するＵＥ１３０の端末情報をＯＳＳ／ＢＳＳ３０へ送信すると共に、サービス割当要求をする（ステップＳ１）。また、ＯＳＳ／ＢＳＳ３０は、サービスマッピング装置１０に対してサービスパラメータ、ＳＬＡ―ＳＬ及び当該サービスを利用するＵＥ１３０の端末情報を送信すると共に、サービス割当要求をする（ステップＳ２）。サービスマッピング装置１０の依頼受付部１１は、当該サービスパラメータ、ＳＬＡ―ＳＬ及び端末情報を受信すると共にサービス割当要求を受け付ける。スライス要件取得部１３は、依頼受付部１１がサービス割当要求を受け付けると、保持部１２で記憶しているスライステーブルから情報を取得する。そして、決定部１５は、スライス要件取得部１３が取得したスライステーブルのＳＬＡ―ＳＬを参照し、受信したＳＬＡ―ＳＬを満たすスライスＩＤを決定する。また、割当部１６は、受信したサービスパラメータと、ＳＬＡ―ＳＬと、決定したスライスＩＤとを対応付けた情報を割当サービステーブルへ登録する（ステップＳ３）。続いて、登録要求部１７は、ＤＮＳサーバ８０に対して、当該サービスパラメータと、決定したスライスＩＤに対応するＩＰアドレスとをＤＮＳサーバ８０へ送信すると共にＤＮＳサーバ８０へ登録要求をする（ステップＳ４）。また、登録要求部１７は、サービスパラメータと、端末情報（ＵｓｅｒＩＤ）とをＨＳＳ７０へ送信すると共に、登録要求をする（ステップＳ５）。

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

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

　続いて、図１５のシーケンス図と、図１６の変更前後の情報とを用いて、本実施形態に係るシステム１で実行される処理を説明する。ここでは、サービスマッピング装置１０へＣａｒ　ｖｉｄｅｏのＳＬＡ―ＳＬが「２，２，２，１」から「２，２，２，２」に変更した場合の例とする。

　ＳＯ２０は、サービスパラメータ及びＳＬＡ―ＳＬをＯＳＳ／ＢＳＳ３０へ送信すると共に、サービス割当要求をする（ステップＳ２１）。また、ＯＳＳ／ＢＳＳ３０は、サービスマッピング装置１０に対してサービスパラメータ、ＳＬＡ―ＳＬ及び当該サービスを利用するＵＥ１３０の端末情報を送信すると共に、サービス割当要求をする（ステップＳ２２）。サービスマッピング装置１０の依頼受付部１１は、当該サービスパラメータ及びＳＬＡ―ＳＬを受信すると共にサービス割当要求を受け付ける。スライス要件取得部１３は、依頼受付部１１がサービス割当要求を受け付けると、保持部１２で記憶している図６に示したスライステーブルから情報を取得する。そして、決定部１５は、スライス要件取得部１３が取得したスライステーブルのＳＬＡ―ＳＬを参照し、受信したＳＬＡ―ＳＬを満たすスライスＩＤを決定する（ステップＳ２３）。また、決定部１５は、割当対象のサービスパラメータと同一のサービスパラメータが割当サービステーブルに記憶されているか否かを確認する（割当対象のサービスパラメータが割当サービステーブルに記憶されているか否かを確認する）。既に当該サービスパラメータを含む情報が記憶されており、別のスライスＩＤに対応付けられている場合、割当部１６は、割当対象のサービスパラメータと、割当先のスライスを対応付けるように割当サービステーブルを更新する。

　登録要求部１７は、ＤＮＳサーバ８０へサービスパラメータに対応するアドレスの更新要求をする（ステップＳ２４）。ＤＮＳサーバ８０は、この更新要求に応じてサービスパラメータに対応するアドレスを更新して、ＭＭＥ９０へ変更通知する（ステップＳ２５）。ＭＭＥ９０は、ＵＥ１３０へリリース通知をする（ステップＳ２６）。ＵＥ１３０は、上記リリース通知に応じて、予め定められているＭＭＥ９０へＡｔｔａｃｈ要求をする（ステップＳ２７）。ＭＭＥ９０は、ＨＳＳ７０へＡｔｔａｃｈ要求をする（ステップＳ２８）。ＨＳＳ７０は、当該Ａｔｔａｃｈ要求を受け付けると共にＡｔｔａｃｈ要求しているＵＥ１３０に対応するサービスパラメータを検索する。ＨＳＳ７０は、検索したサービスパラメータをＭＭＥ９０へ返却する（ステップＳ２９）。ＭＭＥ９０は、当該サービスパラメータをＤＮＳサーバ８０へ送信すると共に、当該サービスパラメータに対応するアドレスの検索要求をする（ステップＳ３０）。ＤＮＳサーバ８０は、検索したアドレス（ＳＧＷ１１０及びＰＧＷ１２０のＩＰアドレス）をＭＭＥ９０へ送信する（ステップＳ３１）。ＭＭＥ９０は、当該アドレスを受信し、受信したアドレスのＳＧＷ１１０へ接続要求する（ステップＳ３２）。また、ＳＧＷ１１０は、ＰＧＷ１２０へベアラ確立依頼をして（ステップＳ３３）、ＰＧＷ１２０からＳＧＷ１１０へベアラ確立通知をする（ステップＳ３４）。また、ＳＧＷ１１０からＭＭＥ９０へベアラ確立通知をする（ステップＳ３５）。そして、ＭＭＥ９０からＵＥ１３０へベアラ確立通知をする（ステップＳ３６）。ＵＥ１３０は、ＭＭＥ９０から通知に応じて、サービスデータの通信を開始する（ステップＳ３７）。

　例えば、図１６（Ａ）に示す割当サービステーブルの変化を示す。例えば、当初、サービスパラメータ「Ｃａｒ　Ｖｉｄｅｏ」で、ＳＬＡ－ＳＬが「２，２，２，１」で登録要求がある場合、スライスＩＤ「１」が適切なので、割当部１６は、サービスパラメータ「Ｃａｒ　Ｖｉｄｅｏ」に対応するスライスＩＤを「１」に設定する。

　この後で、サービスパラメータ「Ｃａｒ　Ｖｉｄｅｏ」で、ＳＬＡ－ＳＬが「２，２，２，２」で登録要求を受け付けると、スライスＩＤが「３」になる。そこで、割当部１６は、サービスパラメータ「Ｃａｒ　Ｖｉｄｅｏ」のスライスＩＤを「３」に設定する。

　また、登録要求部１７は、ＤＮＳサーバ８０へサービスパラメータ「Ｃａｒ　Ｖｉｄｅｏ」のＩＰアドレスの更新要求をする。これに伴い、図１６（Ｂ）に示すように、サービスパラメータ「Ｃａｒ　Ｖｉｄｅｏ」のＩＰアドレスが更新される。

　続いて、図１７のシーケンス図及び図１８の変更前後の情報とを用いて、本実施形態に係るシステム１で実行される処理を説明する。ここでは、所定のタイミングでリソースの状況に基づいて、スライスの割当をする処理方法について説明する。

　所定のタイミングで、サービスマッピング装置１０のリソース取得部１４は、ＮＦＶＯ４０へスライスＩＤと当該スライスのファンクションセットを送信すると共にリソースの利用状況を取得して、取得した結果をスライステーブルに更新している。所定のタイミングでリソース取得部１４は、スライステーブルを参照し、各スライスのリソース利用状況を決定部１５へ送出する。決定部１５は、利用率が逼迫しているスライスがあるか否かを判断する（ステップＳ４１）。例えば、図１８（Ａ）に示すようにスライステーブルにおけるスライスＩＤのＵｓａｇｅが６０％であったが、図１８（Ｂ）に示すように、Ｕｓａｇｅが９０％に変更していた場合、スライスＩＤ「１」が利用率が逼迫していると判断する。

　続いて、決定部１５は、各スライスのＳＬＡ―ＳＬと、スライス毎のファンクションセットのＶＭの使用状況に基づいて、割り当てるスライスを決定する（ステップＳ４２）。具体的には、決定部１５は、割当サービステーブルで記憶されているサービスパラメータのＳＬＡ―ＳＬを満たすＳＬＡ―ＳＬを有するスライステーブルのレコードを特定し、当該レコードが示すスライスの内、リソースに最も空きがあるスライスに割り当てると決定する。割当部１６は、割当対象のサービスパラメータと、割当先のスライスを対応付けるように割当サービステーブルを更新する（ステップＳ４３）。ステップＳ４４～ステップＳ４５は、ステップＳ２４～ステップＳ２５とそれぞれ同様であるため、説明を省略する。また、登録要求部１７は、ＭＭＥ９０へリリース指示をする（ステップＳ４６）。ステップＳ４７～ステップＳ５８は、ステップＳ２６～ステップＳ３７とそれぞれ同様であるため、説明を省略する。

　上述に示した例では、ＤＮＳサーバ８０へ変更要求する場合について述べたが、代わりにＨＳＳ７０が記憶するデータを更新するようにしてもよい。SLA－SLが変更された場合と、リソース変更により処理変更する場合の処理手順を説明する。

　最初に、ＳＬＡ－ＳＬが変更された場合について図１９及び図２０を用いて説明する。図１９は、あるサービスパラメータのＳＬＡ－ＳＬが変更された場合に、ＨＳＳ７０へ変更要求する処理を示すシーケンス図である。

　ステップＳ６１～ステップＳ６３は、ステップＳ２１～ステップＳ２３とそれぞれ同様であるため、説明を省略する。登録要求部１７は、割当対象のスライスを変更する時に、当該変更後のスライスが割り当てられている他のサービスパラメータを特定し、ＳＬＡ－ＳＬが変更されたサービスパラメータと他のサービスパラメータとをＨＳＳ７０へ通知する共に、ＨＳＳ７０に更新要求する（ステップＳ６４）。ＨＳＳ７０は、ＳＬＡ－ＳＬが変更されたサービスパラメータが対応付けられているユーザを他のサービスパラメータに変更する。例えば、ＨＳＳ７０が、当初「Ｃａｒ Ｖｉｄｅｏ」であったサービスパラメータを「Ｓｔｒｅａｍｉｎｇ」へ変更要求を受け付けた場合、図２０に示すように、「Ｃａｒ Ｖｉｄｅｏ」であるユーザに対応するサービスパラメータを「Ｓｔｒｅａｍｉｎｇ」に変更する。

　ＨＳＳ７０は、ＭＭＥ９０へ変更した旨を通知する（ステップＳ６５）。ステップＳ６６～Ｓ７７は、ステップＳ２６～Ｓ３７とそれぞれ同様であるので、説明を省略する。

　続いて、リソース変更により処理変更する場合の処理手順を図２１を用いて説明する。ステップＳ８１～ステップＳ８３は、ステップＳ４１～ステップＳ４３とそれぞれ同様であるため、説明を省略する。登録要求部１７は、割当対象のスライスを変更する時に、当該変更後のスライスが割り当てられている他のサービスパラメータを特定し、ＳＬＡ－ＳＬが変更されたサービスパラメータと他のサービスパラメータとをＨＳＳ７０へ通知する共に、ＨＳＳ７０に更新要求する（ステップＳ８４）。ＨＳＳ７０は、ＳＬＡ－ＳＬが変更されたサービスパラメータが対応付けられているユーザを他のサービスパラメータに変更する。

　ＨＳＳ７０は、ＭＭＥ９０へ変更した旨を通知する（ステップＳ８５）。ステップＳ８６～Ｓ９８は、ステップＳ４６～Ｓ５８とそれぞれ同様であるので、説明を省略する。

　なお、ＨＳＳ７０は、「Ｕｓｅｒ　ＩＤ」欄と「Ｓｅｒｖｉｃｅ　Ｐａｒａｍｅｔｅｒ」欄とを対応付けた情報を記憶している場合について述べたが、図２２に示すように、さらに「ＵＥ　Ｕｓａｇｅ　ｔｙｐｅ」欄をさらに対応付けてもよい。

　つぎに、本実施形態のシステム１の作用効果について説明する。サービスマッピング装置１０では、既にスライスが割り当てられているサービスと、当該スライスと、当該サービスを実行する装置を示すアドレスとを対応付けた割当サービステーブルを記憶している。また、サービスマッピング装置１０の依頼受付部１１は、機能の要件であるＳＬＡ―ＳＬを受信する。決定部１５は、受け付けられたサービスのサービス要件（ＳＬＡ―ＳＬ）に対応する（サービス要件を満たす）ＳＬＡ―ＳＬを有するスライスを決定する。割当部１６は、割当対象のサービスが、予めスライスに対応付けられている場合、決定されたスライスにサービスを割り当て変更する。

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

　また、サービスマッピング装置１０の登録要求部１７は、ＵＥ１３０からのサービスの利用要求に応じて、当該サービスの接続先を当該ＵＥ１３０と接続するＭＭＥ９０へ通知するＤＮＳサーバ８０に対して、変更後のスライスに対応するアドレスへアドレスの変更要求をする。この場合、スライスの割当変更した後に、ＤＮＳサーバ８０へ接続先の変更要求をするので、ユーザからのサービス利用要求に応じて、適切にユーザへ変更後の接続先を通知することができる。

　また、依頼受付部１１は、割当対象のサービス及びＳＬＡ―ＳＬを取得し、決定部１５は、取得したＳＬＡ―ＳＬを満たすスライスを決定する。この場合、サービス要件に応じて、当該サービスのデータを送受信する通信制御装置を切り替えるのでサービスを利用するユーザに対して好適なサービスを提供することができる。

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

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

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

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

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

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

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

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

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

　１…システム、１０…サービスマッピング装置、１１…依頼受付部、１２…保持部、１３…スライス要件取得部、１４…リソース取得部、１５…決定部、１６…割当部、１７…登録要求部、２０…ＳＯ、３０…ＯＳＳ／ＢＳＳ、４０…ＮＦＶＯ、４１…保持部、４２…リソース要求受付部、４３…リソース通知部、５０…ＶＮＦＭ、５１…構成要求受付部、５２…保持部、５３…検索部、６０…ＶＩＭ、６１…リソース要求受付部、６２…保持部、６３…リソース通知部、７０…ＨＳＳ、８０…ＤＮＳサーバ、９０…ＭＭＥ、１００…ｅＮＢ、１０１…ＣＰＵ、１０２…ＲＡＭ、１０３…ＲＯＭ、１０４…通信モジュール、１０５…補助記憶装置、１１０…ＳＧＷ、１２０…ＰＧＷ、１３０…ＵＥ、１６０…ＮＦＶＩ。

Claims (5)

1. 　ネットワークインフラ上に生成される仮想ネットワークであるスライスに対して、当該仮想ネットワークを用いるサービスを割り当てる第１装置で実行されるスライス割当方法であって、
   　前記第１装置では、既にスライスが割り当てられているサービスと、当該スライスと、当該サービスを実行する装置を示す接続先とを対応付けた情報である対応情報を予め記憶しており、
   　割当対象のサービスにおける機能の要件であるサービス要件を満たすスライスを決定する決定ステップと、
   　前記対応情報により前記割当対象のサービスに対応付けられているスライスから、前記決定ステップにより決定されたスライスへ割当て変更する割当ステップと、を含むスライス割当方法。
2. 　ユーザからのサービスの利用要求に応じて、当該サービスの接続先を当該ユーザと通信接続する通信装置へ通知する第２装置に対して、前記割当ステップにより変更されたスライスに対応する接続先への接続先の変更を要求する変更要求ステップをさらに含む、請求項１に記載のスライス割当方法。
3. 　割当対象のサービス及びサービス要件を新規に取得する要件取得ステップをさらに含み、
   　前記決定ステップは、前記要件取得ステップにより取得されたサービス要件を満たすスライスを決定する、請求項１又は２に記載のスライス割当方法。
4. 　スライス毎のリソース使用状況と、既にスライスが割り当てられているサービスのサービス要件を取得する使用状況取得ステップ、をさらに含み、
   　前記決定ステップは、前記使用状況取得ステップにより取得されたサービス要件及びリソース使用状況に基づいて割り当てるスライスを決定する、請求項１から３の何れか一項に記載のスライス割当方法。
5. 　前記決定ステップは、前記サービス要件を満たすスライスの内、空リソースが最も多いスライスに決定する、請求項４に記載のスライス割当方法。

Images