以下、図面と共に本発明の一側面に係るスライス割当方法の実施形態について詳細に説明する。なお、図面の説明においては同一要素には同一符号を付し、重複する説明を省略する。
図1に本実施形態に係るサービスマッピング装置10を含むシステム1の構成を示す。システム1は、仮想ネットワークであるスライスに対してサービスを割り当てるシステムである。スライスとは、ネットワーク装置のリンクとノードの資源を仮想的に切り分けて、切り分けた資源を結合し、ネットワークインフラ上に論理的に生成される仮想ネットワーク又はサービス網であり、スライス同士は資源を分離しており、互いに干渉しない。サービスとは、通信サービス(専用線サービス等)やアプリケーションサービス(動画配信、エンベデッド装置等のセンサ装置を利用したサービス)等のネットワーク資源を用いたサービスをいう。
図1に示すようにシステム1は、サービスマッピング装置10(第1装置)と、SO(Service Operator)20と、OSS/BSS(Operations Support System/Business Support System)30と、NFVO40と、VNFM50と、VIM(Virtualized Infrastructure Management:仮想化基盤管理)60と、HSS(Home Subscriber Server)70(第2装置)と、DNS(Domain Name System)サーバ80(第2装置)と、MME(Mobility Management Entity)90と、eNB100と、SGW(Serving Gateway)110と、PGW(Packet data network gateway)120と、UE(User Equipment)130とを含んで構成されている。このうち、NFVO40とVNFM50とVIM60とは、MANO(Management & Orchestration)architectureである。
これらの構成要素は、システム1のコアネットワークを構成するものである。なお、互いに情報の送受信が必要な構成要素間は、有線等で接続されており情報の送受信が可能となっている。
本実施形態に係るシステム1は、物理サーバ上に実現される仮想マシンにおいて動作する仮想サーバによって移動通信端末に対して通信機能を提供する。即ち、システム1は、仮想化された移動体通信ネットワークである。通信機能は、仮想マシンによって当該通信機能に応じた通信処理を実行することで移動通信端末に対して提供される。
サービスマッピング装置10は、システム1におけるサービス管理を行い、システム1での通信機能に係る指示を行うノードである。また、サービスマッピング装置10は、システム1に係る通信事業者によって操作され得る。
SO(Service Operator)20は、サービス要求する装置であり、例えば、仮想ネットワークを用いて各種ユーザへサービス提供をする事業者の端末装置(例えば、パーソナルコンピュータ等)である。
OSS/BSS30は、SO20からのサービス要求を受け付けて、サービスマッピング装置10へその要求を通知する装置である。
NFVO40は、物理資源であるNFVI160上に構築された仮想ネットワーク(スライス)全体の管理を行う全体管理ノード(機能エンティティ)である。NFVO40は、サービスマッピング装置10からの指示を受信し、当該指示に応じた処理を行う。NFVO40は、インフラと通信サービスの移動体通信網の物理資源において構築された仮想化ネットワーク全体にわたる管理を行う。NFVO40は、仮想ネットワークにより提供される通信サービスをVNFM50及びVIM60を経由して適切な場所に実現する。例えば、サービスのライフサイクル管理(具体的には例えば、生成、更新、スケール制御、イベント収集)、移動体通信網内全体にわたる資源の分散・予約・割当管理、サービス・インスタンス管理、及びポリシー管理(具体的には例えば、リソースの予約・割当、地理・法令等に基づく最適配置)を行う。
VNFM50は、物理資源(ノード)となるNFVI160に対して、サービスに係る機能を追加する仮想通信機能管理ノード(機能エンティティ)である。VNFM50は、システム1に複数、設けられていてもよい。
VIM60は、物理資源(ノード)各々を管理する物理資源管理ノード(機能エンティティ)である。具体的には、資源の割当・更新・回収の管理、物理資源と仮想化ネットワークとの関連付け、ハードウェア資源とSW資源(ハイパーバイザー)一覧の管理を行う。通常、VIM60は、データセンタ(局舎)毎に管理を行う。物理資源の管理は、データセンタに応じた方式で行われる。データセンタの管理方式(管理資源の実装方式)は、OPENSTACKやvCenter等の種類がある。通常、VIM60は、データセンタの管理方式毎に設けられる。即ち、互いに異なる方式で、NFVI160における物理資源各々を管理する複数のVIM60が含まれる。なお、異なる管理方式で管理される物理資源の単位は、必ずしもデータセンタ単位でなくてもよい。
なお、NFVO40、VNFM50及びVIM60は、物理的なサーバ装置上でプログラムが実行されることにより実現される(但し仮想化上で実現されることを制限するものでは無く、管理系統を分離した上で、仮想化上で実現してもよい)。NFVO40、VNFM50及びVIM60は、それぞれ別々の物理的なサーバ装置で実現されていてもよいし、同じサーバ装置で実現されていてもよい。NFVO40、VNFM50及びVIM60(を実現するためのプログラム)は、別々のベンダから提供されていてもよい。
NFVO40は、スライス生成要求を受信すると、VIM60に対してスライス(スライスSL1、SL2等)のためのリソース確保要求を行う。VIM60が、物理資源を構成するサーバ装置やスイッチにおけるリソースを確保すると、NFVO40は、当該これら物理資源に対してスライスを定義する。
また、NFVO40は、VIM60に、物理資源においてリソース確保させると、当該物理資源に対してスライスを定義した情報をNFVO40が記憶しているテーブルに記憶する。そして、NFVO40は、当該サービスに必要となる機能を実現するためのソフトウェアのインストール要求をVNFM50に対して行う。VNFM50は、当該インストール要求に応じて、VIM60によって確保された物理資源(サーバ装置、スイッチ装置またはルータ装置などのノード)に対して上記ソフトウェアをインストールする。
NFVO40は、VNFM50によりソフトウェアがインストールされると、NFVO40が記憶しているテーブルへスライスとサービスとの対応付けをする。スライスSL1〜スライスSL3は、サービスを割り当てる単位となるスライスである。
例えば図2に示すように、NFVO40がスライス(Slice1及びSlice2)のためのリソース確保要求をVIM60へ行うと、VIM60は、その旨の指示をスイッチSW1、スイッチSW2、サーバSV1、及びスイッチSW3に対して行う。そして、これらスイッチSW1、スイッチSW2、サーバSV1、及びスイッチSW3はSlice1用にリソースを確保する。同様に、VIM60からの指示に従って、スイッチSW1、スイッチSW2、サーバSV1、及びスイッチSW4は、Slice2用にリソースを確保する。
上述の物理資源であるNFVI160は、仮想化環境を構成する物理資源(ノード群)から形成されたネットワークを示す。この物理資源は、概念的には計算資源、記憶資源、伝送資源を含む。具体的には、この物理資源は、システム1において通信処理を行う物理的なサーバ装置である物理サーバ、スイッチ等のノードを含んで構成されている。物理サーバは、CPU(コア、プロセッサ)、メモリ、及びハードディスク等の記憶手段を備えて構成される。通常、NFVI160を構成する物理サーバ等のノードは、複数まとめてデータセンタ(DC)等の拠点に配置される。データセンタでは、配置された物理サーバがデータセンタ内部のネットワークによって接続されており、互いに情報の送受信を行うことができるようになっている。また、システム1には、複数のデータセンタが設けられている。データセンタ間はネットワークで接続されており、異なるデータセンタに設けられた物理サーバはそのネットワークを介して互いに情報の送受信を行うことができる。
上述のように、VNFM50が、物理資源(ノード)となるNFVI160に対して、各種機能を追加することにより、NFVI160は、HSS70、DNSサーバ80、MME90、SGW110、及びPGW120の機能を実現する。
HSS70は、UE130等の通信端末の契約情報、認証情報、通信サービス情報、端末タイプ情報及び在圏情報を含む加入者情報をデータベースで管理する機能である。ここで、通信サービス情報とは、各UE130が利用する通信サービスのタイプを定義した情報である。通信サービス情報には、UE130を識別する情報(例えば、IMSI(International Mobile Subscriber Identity))と、当該UE130が利用する通信サービスの要件を示すサービスタイプとが含まれる。
DNSサーバ80は、ネットワーク上でドメイン名やホスト名とIPアドレスの対応関係を管理する機能である。さらにDNSサーバ80は、サービスパラメータとSGW110のアドレスとを対応付けた情報を記憶している。DNSサーバ80は、MME90からアドレスの送信要求を受け付けると、要求に応じたSGW110のアドレスをMME90へ送信する。
MME90は、LTE(Long Term Evolution)ネットワークに在圏するユーザ端末(UE130)の位置管理、認証制御、及びSGW110とUE130との間のユーザデータの通信経路の設定処理を行う機能である。すなわち、MME90は、UE130と通信接続する通信装置である。
eNB100は、MME90に接続された無線基地局であるとともに、無線アクセス制御機能を有した装置である。
SGW110は、LTEを収容する在圏パケット交換機の機能で、PGW(Packet data network Gateway)120との間で通信サービス提供に利用されるユーザデータの送受信を行う。SGW110は、複数の通信サービスの要件に対応して複数設けられている。
PGW120は、PDN(Packet data network)との接合点であり、IPアドレスの割当てや、SGW110へのパケット転送などを行うゲートウェイである。
引き続いて、サービスマッピング装置10について、本実施形態に係る機能について図3を用いて説明する。
図3に戻り、サービスマッピング装置10の機能を説明する。図3に示すようにサービスマッピング装置10は、依頼受付部11と、保持部12と、スライス要件取得部13と、リソース取得部14と、決定部15と、割当部16と、登録要求部17とを有する。
依頼受付部11は、OSS/BSS30からのサービスにおける機能の要件であるサービス要件を含むサービス依頼を受け付ける部分である。ここで、サービス要件の内、機能要件とはサービスを実行するための機能に関する要件である。具体的には、機能要件としてモビリティ制御の要否、可能アクセスエリア範囲、サービス利用時間が含まれる。モビリティ制御の要否とは、ハンドオーバ制御を必要とするか否かを意味する。アクセスエリア範囲は、サービスを提供する範囲(エリア)を意味する。サービス利用時間は、サービスを利用する時間帯を意味する。
また、依頼受付部11は、サービス依頼を受け付ける際に、サービスを実現するための機能の要件を示す情報を受信する。ここでいうサービスを実現するための機能の要件を示す情報としては、SLA−SLである。
依頼受付部11は、上記のサービスを実現するための機能の要件を示す情報を受信すると、サービス要件を決定部15へ送出する。また、依頼受付部11は、スライス要件取得部13に対して、スライス要件を取得する旨の通知をする。
また、依頼受付部11は、予め定められているリソース状況チェックタイミングであることを検知すると、リソース取得部14へリソース取得する旨の通知をすると共に、上記チェックタイミングである旨を決定部15へ通知する。また、依頼受付部11は、リソース状況チェックタイミングである場合も、スライス要件取得部13に対して、スライス要件を取得する旨の通知をする。
保持部12は、各種テーブルを記憶する部分である。保持部12は、割当サービステーブル(対応情報)及びスライステーブルを記憶する。図4に、割当サービステーブルを示す。図4に示すように、割当サービステーブルは、「Service parameter」欄と「SLA−SL」欄と「NW sliceID」欄とを対応付けた情報を記憶する。ここで、「Service parameter」欄及び「SLA−SL」欄の情報は、OSS/BSS30からサービス要求を受け付けたサービスを特定する情報であり、OSS/BSS30から受信する情報である。「NW sliceID」欄の情報は、NFVO40から受信する情報である。図4の例では、「Service parameter」欄に入力されている「Smart meter」であるサービスパラメータに「NW sliceID」(スライスを識別するスライスID)が「2」であるスライスが割り当てられていることを示す。
図5に、スライステーブルを示す。図5に示すように、スライステーブルは、「NW sliceID」欄と「Function」欄と「Usage」欄と「IP adress」欄と「SLA−SL」欄とを対応付けた情報を記憶する。「NW sliceID」欄、「Funciotn」欄、「Usage」欄、「IP adress」欄、及び「SLA−SL」欄の情報は、NFVO40から受信する情報である。図5の例では、「NW sliceID」が「1」であるスライスは、Usageが60%であり、SLA−SLが「3,3,3,1」であることを示す。MANOでスライスが新規に生成されると、サービスマッピング装置10は、新規に生成されたスライスについての「NW sliceID」欄の情報と「Function」欄の情報と「Usage」欄の情報と「IP adress」欄の情報と「SLA−SL」欄の情報とを取得し、保持部12のスライステーブルに記憶する。また、保持部12は、要求サービス管理テーブルも記憶する。この要求サービス管理テーブルは、「Service parameter」欄と「SLA−SL」欄とが対応付けられたテーブルである。「Service parameter」欄には、依頼受付部11がOSS/BSS30から受信したサービスパラメータが入力されている。「SLA−SL」欄には、依頼受付部11がOSS/BSS30から受信したSLA−SLが入力されている。また、上記要求サービス管理テーブルには、上記2つの欄以外に「端末情報」欄も対応付けられている。この「端末情報」欄には、依頼受付部11がOSS/BSS30から受信した端末情報が入力されている。
スライス要件取得部13は、保持部12で記憶している、図5に示したスライステーブルを参照して、各スライスの要件(SLA−SL)を取得する部分である。スライス要件取得部13は、当該スライスの要件を取得すると、決定部15へ送出する。
リソース取得部14は、依頼受付部11からリソース取得要求を受け付けると、NFVO40へリソース取得要求をする。リソース取得部14は、当該リソース取得要求に応じて、NFVO40からリソース情報を受信する。リソース取得部14は、当該リソース情報をスライステーブルへ更新する。また、リソース取得部14は、依頼受付部11の要求に応じてスライステーブルを参照し、スライス毎の利用率を決定部15へ送出する。
決定部15は、依頼受付部11によって受け付けられたサービスのサービス要件に対応するスライスを決定する部分である。例えば、決定部15は、依頼受付部11がOSS/BSS30からサービス割当要求を受け付けた場合、依頼受付部11から受信したSLA―SLと、スライス要件取得部13から取得した図5に示したスライステーブルの情報のSLA―SLとを比較して、依頼受付部11から受信したSLA―SLの値を全て包含する(受信したSLA―SLの値以上である)スライステーブルの情報の「NW sliceID」欄に設定されているIDをスライスIDとして決定する。決定部15は、割当サービステーブルを参照し、割当対象のサービスパラメータと同一のサービスパラメータが既に割り当てられている場合であり、上記決定したスライスIDと、上記サービスパラメータに既に割り当てられているスライスIDとが異なる場合、割当部16へ割り当て要求をする。また、決定部15は、割当サービステーブルを参照し、既に同一のサービスパラメータが割り当てられていない場合は、割当部16へ割り当て要求する。
また、決定部15は、リソース取得部14からリソース情報を取得した場合、割当サービステーブルの各サービスパラメータに対応するSLA―SLと、スライステーブルのSLA―SLと、リソース取得部14によって取得されたスライス毎のリソース使用状況とに基づいて、割当対象のサービスパラメータに割り当てるスライスを決定する。具体的には、決定部15は、スライステーブルのSLA―SLを参照し、割当サービステーブルの各サービスパラメータに対応するSLA―SLを満たすスライスの内、リソース使用状況に余裕のある(リソースに空きがある)スライスにサービスパラメータを割り当てることを決定する。ここでリソース使用状況に余裕があるとは、スライス毎のリソース(当該スライスを構成するVM又は、当該VMを実現するハードウェア)の使用率の平均値が最も低いことをいう。この場合に、今回決定したスライスと、前回割り当てていたスライスが異なる場合、割当部16へ割り当て要求をする。決定部15は、割当部16へ割当要求する場合、端末情報、サービスパラメータ、及び割り当てるスライスを通知する。
割当部16は、割当サービステーブルにより割当対象のサービスに対応付けられているスライスから、決定部15により決定されたスライスへ割当て変更する部分である。割当部16は、割当対象のサービスパラメータと、割当先のスライスを対応付けるように割当サービステーブルを更新する。また、割当部16は、新規にサービスパラメータにスライスを割り当てる場合、サービスパラメータ、SLA−SL、及び端末情報を要求サービス管理テーブルへ登録する。また、割当部16は、サービスパラメータと当該サービスパラメータに対応するIPアドレスを登録要求部17へ通知する。
登録要求部17は、ユーザからのサービスの利用要求に応じて当該サービスの接続先を当該ユーザへ通知するDNSサーバ80に対して、割当部16により変更されたスライスに対応する接続先への接続先の変更を要求する部分である。登録要求部17は、サービスの接続先(IPアドレス)とサービスパラメータをDNSサーバ80又はHSS70へ送信する。また、登録要求部17は、新たにサービスを登録する場合、端末情報(ユーザID)及びサービスパラメータをHSS70へ送信する。
登録要求部17は、HSS70及びDNSサーバ80へ登録要求をする部分である。登録要求部17は、NFVO40から機能セット(機能のリスト)、端末情報、スライスID及びサービスパラメータを受信すると共に、上記登録要求を受け付ける。登録要求部17は、上記端末情報、スライスID、及びサービスパラメータを送信し、HSS70へ編集要求をする。ここで、HSS70が記憶している情報の例を図6に示す。HSS70は、図6に示すように、「User ID」欄と「Service Parameter」欄とを対応付けた情報を上記変更要求に応じて記憶する。「User ID」欄には、ユーザを識別する情報であり、例えば、IMSI等の情報が入力される。「Service Parameter」欄には、サービスパラメータが入力される。
また、登録要求部17は、設定対象のスライスIDを検索キーとして、スライステーブルからIPアドレスを取得する。そして、登録要求部17は、当該IPアドレスとサービスパラメータとをDNSサーバ80へ送信すると共に編集要求する。ここで、DNSサーバ80が記憶している情報の例を図7に示す。DNSサーバ80は、図7に示すように、「Service Parameter」欄と「IP Address」欄とを対応付けた情報を上記編集要求に応じて記憶する。「Service Parameter」欄には、サービスパラメータが入力される。「IP Address」欄には、アクセス先を示すアドレス情報が入力される。DNSサーバ80は、上記編集要求を受信すると、要求対象のサービスパラメータの情報が入力されていない場合には、新たにサービスパラメータと、上記アドレス情報を登録する。既にサービスパラメータが登録されている場合には、当該サービスパラメータに対応するアドレス情報を、要求対象のアドレス情報に変更する。
続いて、NFVO40の機能の説明をする。NFVO40は、保持部41と、リソース要求受付部42と、リソース通知部43とを備える。
保持部41は、各種テーブルを記憶する部分である。保持部41は、ファンクションセットテーブル及びファンクション要件テーブルを記憶する。図8にファンクションセットテーブルを示す。このファンクションセットテーブルは、「Slice ID」欄と「Funciton Set」欄とを対応付けた情報を記憶するテーブルである。「Slice ID」欄には、スライスを識別するスライスIDが入力されている。「Funciton Set」欄には、ファンクションセットを示す情報が入力されている。図9にファンクション要件テーブル示す。ファンクション要件テーブルは、「Function」欄と「SLA−SL」欄とを対応付けた情報を記憶するテーブルである。図9に示す「Funciton」欄には、ファンクションを示す情報が入力されている。また、「SLA−SL」欄には、当該ファンクションに対応するSLA−SLを示す情報が入力されている。
リソース要求受付部42は、サービスマッピング装置10からリソース要求を受け付けると、保持部41のファンクションセットテーブルからファンクションセットを取得する。リソース要求受付部42は、当該ファンクションセットのそれぞれの機能をVNFM50へ送信し、VM取得要求をする。リソース要求受付部42は、VNFM50からVMを取得する。続いて、リソース要求受付部42は、それぞれのVMのリソース利用状況の送信要求をVIM60へ行う。リソース要求受付部42は、VIM60からリソース利用状況を受信すると、当該リソース利用状況をスライス毎にリソース通知部43へ通知する。
リソース通知部43は、リソース要求受付部42から受信したリソース利用状況をスライス毎にサービスマッピング装置10へ送信する。
続いて、VNFM50の説明をする。VNFM50は、構成要求受付部51と、保持部52と、検索部53とを有する。構成要求受付部51は、NFVO40からのVM取得要求を受け付ける部分である。構成要求受付部51は、NFVO40から対象機能と共にVM取得要求を受け付けると、当該対象機能を検索部53へ通知する。構成要求受付部51は、検索部53に当該通知をした後に、検索部53による検索結果を検索部53から取得する。構成要求受付部51は、検索結果を検索部53から取得すると、検索結果をNFVO40へ送信する。
保持部52は、各種情報を保持する部分である。保持部52は、ソフトウェア(例えば、リポジトリ)を保持する。また、保持部52は、上記ソフトウェア以外に、VMと機能とを対応付けた情報有するVM機能テーブルを記憶する。図10にVM機能テーブルの例を示す。図10に示すように、「Function」欄と「VM」欄と、図示していないが、当該「VM」のアドレスを示す「アドレス」欄とを対応付けて記憶している。「Function」欄には、ファンクションを示す情報が入力されている。「VM」欄には、当該ファンクションを実行するVMを示す情報(例えば、VMの識別子等)が入力される。
検索部53は、構成要求受付部51からの要求に応じて、保持部52のVM機能テーブルを検索して、その検索結果を構成要求受付部51へ通知する部分である。検索部53は、構成要求受付部51から対象機能を受信すると、VM機能テーブルを検索して、当該対象機能に合致する「Function」欄の情報を有する「VM」を検索結果として、構成要求受付部51へ送信する。
VIM60は、リソース要求受付部61と、保持部62と、リソース通知部63とを備える。リソース要求受付部61は、NFVO40から、対象VMと共にリソース状況の要求を受け付ける部分である。リソース要求受付部61は、リソース状況要求受け付けると、対象VMを検索キーとして、保持部62の情報を検索する。リソース要求受付部61は、検索結果をリソース通知部63へ通知する。
保持部62は、リソース情報を記憶する部分である。リソース情報として、VMの使用率情報及び当該VMを実現するハードウェアの使用率情報を記憶する。図11にVMの使用率情報例を示す。図11に示すように、「VM」欄と、「所属HW」欄と、「Usage」欄とを対応付けた情報を記憶している。「VM」欄には、VMを示す情報(例えば、VMの識別子)が入力されている。「所属HW」欄には、VMを実現するハードウェア(例えば、サーバ)を示す情報(例えば、サーバの識別子)が入力されている。「Usage」欄には、VMの使用率を示す情報が入力されている。続いて、図12にハードウェアの使用率情報の例を示す。図12に示すように、「HW」欄と、「Usage」欄とを対応付けた情報を記憶している。「HW」欄には、ハードウェアを識別する情報が入力されている。「Usage」欄には、ハードウェアの使用率を示す情報が入力されている。
リソース通知部63は、構成要求受付部51から検索結果を受信し、当該検索結果をNFVO40へ送信する部分である。
物理的には、サービスマッピング装置10、NFVO40、VNFM50及びVIM60は、それぞれ図13に示すように、一又は複数のCPU101、主記憶装置であるRAM102及びROM103、データ送受信デバイスである通信モジュール104(Transmitter or Receiver)、ハードディスク、フラッシュメモリ等に例示される補助記憶装置105(Memory)などを含むコンピュータシステムとして構成されている。サービスマッピング装置10では、図4に示すCPU101、RAM102等のハードウェア上に所定のコンピュータソフトウェアを読み込ませることにより、CPU101の制御のもとで通信モジュール104を動作させるとともに、RAM102や補助記憶装置105におけるデータの読み出し及び書き込みを行うことで、サービスマッピング装置10における一連の機能が実現される。
なお、CPU101などのプロセッサ(Processor)が図3における各機能を実行することに代えて、その機能全部または一部を専用の集積回路(IC:integrated circuit)を構築することにより各機能を実行するように構成してもよい。例えば、画像処理や通信制御を行なうための専用の集積回路を構築することにより上記機能を実行するようにしてもよい。
ソフトウェアは、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語と呼ばれるか、他の名称で呼ばれるかを問わず、命令、命令セット、コード、コードセグメント、プログラムコード、プログラム、サブプログラム、ソフトウェアモジュール、アプリケーション、ソフトウェアアプリケーション、ソフトウェアパッケージ、ルーチン、サブルーチン、オブジェクト、実行可能ファイル、実行スレッド、手順、機能などを意味するよう広く解釈されるべきである。
また、ソフトウェア、命令などは、伝送媒体を介して送受信されてもよい。例えば、ソフトウェアが、同軸ケーブル、光ファイバケーブル、ツイストペア及びデジタル加入者回線(DSL)などの有線技術及び/又は赤外線、無線及びマイクロ波などの無線技術を使用してウェブサイト、サーバ、又は他のリモートソースから送信される場合、これらの有線技術及び/又は無線技術は、伝送媒体の定義内に含まれる。
なお、サービスマッピング装置10、NFVO40、VNFM50及びVIM60は複数のサーバ装置からなるコンピュータシステムによって構成されていてもよい。また、システム1に含まれる上記以外のノードも上記のハードウェア構成を有するサーバ装置によって実現されてもよい。また、eNB100やUE130(移動通信端末)の各機能の一部又は全ては、ASIC(Application Specific Integrated Circuit)、PLD(Programmable Logic Device)、FPGA(Field Programmable Gate Array)などのハードウェアを用いて実現されても良い。また、eNB100やUE130は、プロセッサ(CPU)と、ネットワーク接続用の通信インターフェースと、メモリと、プログラムを保持したコンピュータ読み取り可能な記憶媒体と、を含むコンピュータ装置によって実現されてもよい。つまり、本発明の一実施形態に係るeNB100やUE130などは、本発明の一側面に係る処理を行うコンピュータとして機能してもよい。
ここで、プロセッサやメモリなどは情報を通信するためのバスで接続される。また、コンピュータ読み取り可能な記録媒体は、例えば、フレキシブルディスク、光磁気ディスク(例えば、コンパクトディスク、デジタル多用途ディスク、Blu−ray(登録商標)ディスク)、スマートカード、フラッシュメモリデバイス(例えば、カード、スティック、キードライブ)、ROM、EPROM(Erasable Programmable ROM)、EEPROM(Electrically Erasable Programmable ROM)、CD−ROM(Compact Disc−ROM)、RAM、レジスタ、リムーバブルディスク、ハードディスク、フロッピー(登録商標)ディスク、磁気ストリップ、データベース、サーバその他の適切な記憶媒体である。また、プログラムは、電気通信回線を介してネットワークから送信されても良い。また、eNB100やUE130は、入力キーなどの入力装置や、ディスプレイなどの出力装置を含んでいてもよい。
eNB100及びUE130の機能構成は、上述のハードウェアによって実現されてもよいし、プロセッサによって実行されるソフトウェアモジュールによって実現されてもよいし、両者の組み合わせによって実現されてもよい。プロセッサは、オペレーティングシステムを動作させてユーザ端末の全体を制御する。また、プロセッサは、記憶媒体からプログラム、ソフトウェアモジュールやデータをメモリに読み出し、これらに従って各種の処理を実行する。
ここで、当該プログラムは、発明の実施形態で説明する各動作を、コンピュータに実行させるプログラムであれば良い。例えば、移動通信端末の制御部は、メモリに格納され、プロセッサで動作する制御プログラムによって実現されてもよく、他の機能ブロックについても同様に実現されてもよい。
引き続いて、図14のシーケンス図を用いて、本実施形態に係るシステム1で実行される処理を説明する。ここでは、SO20からサービス割当要求がある場合の例とする。
SO20は、上記サービスを示すサービスパラメータ、SLA―SL及び当該サービスを利用するUE130の端末情報をOSS/BSS30へ送信すると共に、サービス割当要求をする(ステップS1)。また、OSS/BSS30は、サービスマッピング装置10に対してサービスパラメータ、SLA―SL及び当該サービスを利用するUE130の端末情報を送信すると共に、サービス割当要求をする(ステップS2)。サービスマッピング装置10の依頼受付部11は、当該サービスパラメータ、SLA―SL及び端末情報を受信すると共にサービス割当要求を受け付ける。スライス要件取得部13は、依頼受付部11がサービス割当要求を受け付けると、保持部12で記憶しているスライステーブルから情報を取得する。そして、決定部15は、スライス要件取得部13が取得したスライステーブルのSLA―SLを参照し、受信したSLA―SLを満たすスライスIDを決定する。また、割当部16は、受信したサービスパラメータと、SLA―SLと、決定したスライスIDとを対応付けた情報を割当サービステーブルへ登録する(ステップS3)。続いて、登録要求部17は、DNSサーバ80に対して、当該サービスパラメータと、決定したスライスIDに対応するIPアドレスとをDNSサーバ80へ送信すると共にDNSサーバ80へ登録要求をする(ステップS4)。また、登録要求部17は、サービスパラメータと、端末情報(UserID)とをHSS70へ送信すると共に、登録要求をする(ステップS5)。
また、登録要求部17は、上記登録の完了通知をHSS70及びDNSサーバ80から受け取ると、OSS/BSS30を介してサービスパラメータの登録完了通知をSO20へ送信する(ステップS6、ステップS7)。SO20は、当該登録完了通知を受信すると、UE130へサービスパラメータを通知する(ステップS8)。UE130は、サービス利用時には、予め定められているMME90へAttach要求をする(ステップS9)。MME90は、HSS70へAttach要求をする(ステップS10)。HSS70は、当該Attach要求を受け付けると共にAttach要求しているUE130に対応するサービスパラメータを検索する。HSS70は、検索したサービスパラメータをMME90へ返却する(ステップS11)。MME90は、当該サービスパラメータをDNSサーバ80へ送信すると共に、当該サービスパラメータに対応するアドレスの検索要求をする(ステップS12)。DNSサーバ80は、検索したアドレス(SGW110及びPGW120のIPアドレス)をMME90へ送信する(ステップS13)。MME90は、当該アドレスを受信し、受信したアドレスのSGW110へ接続し、ベアラ確立する(ステップS14)。また、受信したアドレスのPGW120へ接続し、ベアラ確立する(ステップS15)。MME90は、UE130へベアラ接続先を通知する(ステップS16)。UE130は、MME90から受信した接続先へアクセスして、サービスデータの通信を開始する(ステップS17)。
上述のシーケンス図では、MME90がHSS70からサービスパラメータを受信する場合について述べたが、ステップS11においてUE130からサービスパラメータを受信するようにしてもよい。
続いて、図15のシーケンス図と、図16の変更前後の情報とを用いて、本実施形態に係るシステム1で実行される処理を説明する。ここでは、サービスマッピング装置10へCar videoのSLA―SLが「2,2,2,1」から「2,2,2,2」に変更した場合の例とする。
SO20は、サービスパラメータ及びSLA―SLをOSS/BSS30へ送信すると共に、サービス割当要求をする(ステップS21)。また、OSS/BSS30は、サービスマッピング装置10に対してサービスパラメータ、SLA―SL及び当該サービスを利用するUE130の端末情報を送信すると共に、サービス割当要求をする(ステップS22)。サービスマッピング装置10の依頼受付部11は、当該サービスパラメータ及びSLA―SLを受信すると共にサービス割当要求を受け付ける。スライス要件取得部13は、依頼受付部11がサービス割当要求を受け付けると、保持部12で記憶している図6に示したスライステーブルから情報を取得する。そして、決定部15は、スライス要件取得部13が取得したスライステーブルのSLA―SLを参照し、受信したSLA―SLを満たすスライスIDを決定する(ステップS23)。また、決定部15は、割当対象のサービスパラメータと同一のサービスパラメータが割当サービステーブルに記憶されているか否かを確認する(割当対象のサービスパラメータが割当サービステーブルに記憶されているか否かを確認する)。既に当該サービスパラメータを含む情報が記憶されており、別のスライスIDに対応付けられている場合、割当部16は、割当対象のサービスパラメータと、割当先のスライスを対応付けるように割当サービステーブルを更新する。
登録要求部17は、DNSサーバ80へサービスパラメータに対応するアドレスの更新要求をする(ステップS24)。DNSサーバ80は、この更新要求に応じてサービスパラメータに対応するアドレスを更新して、MME90へ変更通知する(ステップS25)。MME90は、UE130へリリース通知をする(ステップS26)。UE130は、上記リリース通知に応じて、予め定められているMME90へAttach要求をする(ステップS27)。MME90は、HSS70へAttach要求をする(ステップS28)。HSS70は、当該Attach要求を受け付けると共にAttach要求しているUE130に対応するサービスパラメータを検索する。HSS70は、検索したサービスパラメータをMME90へ返却する(ステップS29)。MME90は、当該サービスパラメータをDNSサーバ80へ送信すると共に、当該サービスパラメータに対応するアドレスの検索要求をする(ステップS30)。DNSサーバ80は、検索したアドレス(SGW110及びPGW120のIPアドレス)をMME90へ送信する(ステップS31)。MME90は、当該アドレスを受信し、受信したアドレスのSGW110へ接続要求する(ステップS32)。また、SGW110は、PGW120へベアラ確立依頼をして(ステップS33)、PGW120からSGW110へベアラ確立通知をする(ステップS34)。また、SGW110からMME90へベアラ確立通知をする(ステップS35)。そして、MME90からUE130へベアラ確立通知をする(ステップS36)。UE130は、MME90から通知に応じて、サービスデータの通信を開始する(ステップS37)。
例えば、図16(A)に示す割当サービステーブルの変化を示す。例えば、当初、サービスパラメータ「Car Video」で、SLA−SLが「2,2,2,1」で登録要求がある場合、スライスID「1」が適切なので、割当部16は、サービスパラメータ「Car Video」に対応するスライスIDを「1」に設定する。
この後で、サービスパラメータ「Car Video」で、SLA−SLが「2,2,2,2」で登録要求を受け付けると、スライスIDが「3」になる。そこで、割当部16は、サービスパラメータ「Car Video」のスライスIDを「3」に設定する。
また、登録要求部17は、DNSサーバ80へサービスパラメータ「Car Video」のIPアドレスの更新要求をする。これに伴い、図16(B)に示すように、サービスパラメータ「Car Video」のIPアドレスが更新される。
続いて、図17のシーケンス図及び図18の変更前後の情報とを用いて、本実施形態に係るシステム1で実行される処理を説明する。ここでは、所定のタイミングでリソースの状況に基づいて、スライスの割当をする処理方法について説明する。
所定のタイミングで、サービスマッピング装置10のリソース取得部14は、NFVO40へスライスIDと当該スライスのファンクションセットを送信すると共にリソースの利用状況を取得して、取得した結果をスライステーブルに更新している。所定のタイミングでリソース取得部14は、スライステーブルを参照し、各スライスのリソース利用状況を決定部15へ送出する。決定部15は、利用率が逼迫しているスライスがあるか否かを判断する(ステップS41)。例えば、図18(A)に示すようにスライステーブルにおけるスライスIDのUsageが60%であったが、図18(B)に示すように、Usageが90%に変更していた場合、スライスID「1」が利用率が逼迫していると判断する。
続いて、決定部15は、各スライスのSLA―SLと、スライス毎のファンクションセットのVMの使用状況に基づいて、割り当てるスライスを決定する(ステップS42)。具体的には、決定部15は、割当サービステーブルで記憶されているサービスパラメータのSLA―SLを満たすSLA―SLを有するスライステーブルのレコードを特定し、当該レコードが示すスライスの内、リソースに最も空きがあるスライスに割り当てると決定する。割当部16は、割当対象のサービスパラメータと、割当先のスライスを対応付けるように割当サービステーブルを更新する(ステップS43)。ステップS44〜ステップS45は、ステップS24〜ステップS25とそれぞれ同様であるため、説明を省略する。また、登録要求部17は、MME90へリリース指示をする(ステップS46)。ステップS47〜ステップS58は、ステップS26〜ステップS37とそれぞれ同様であるため、説明を省略する。
上述に示した例では、DNSサーバ80へ変更要求する場合について述べたが、代わりにHSS70が記憶するデータを更新するようにしてもよい。SLA−SLが変更された場合と、リソース変更により処理変更する場合の処理手順を説明する。
最初に、SLA−SLが変更された場合について図19及び図20を用いて説明する。図19は、あるサービスパラメータのSLA−SLが変更された場合に、HSS70へ変更要求する処理を示すシーケンス図である。
ステップS61〜ステップS63は、ステップS21〜ステップS23とそれぞれ同様であるため、説明を省略する。登録要求部17は、割当対象のスライスを変更する時に、当該変更後のスライスが割り当てられている他のサービスパラメータを特定し、SLA−SLが変更されたサービスパラメータと他のサービスパラメータとをHSS70へ通知する共に、HSS70に更新要求する(ステップS64)。HSS70は、SLA−SLが変更されたサービスパラメータが対応付けられているユーザを他のサービスパラメータに変更する。例えば、HSS70が、当初「Car Video」であったサービスパラメータを「Streaming」へ変更要求を受け付けた場合、図20に示すように、「Car Video」であるユーザに対応するサービスパラメータを「Streaming」に変更する。
HSS70は、MME90へ変更した旨を通知する(ステップS65)。ステップS66〜S77は、ステップS26〜S37とそれぞれ同様であるので、説明を省略する。
続いて、リソース変更により処理変更する場合の処理手順を図21を用いて説明する。ステップS81〜ステップS83は、ステップS41〜ステップS43とそれぞれ同様であるため、説明を省略する。登録要求部17は、割当対象のスライスを変更する時に、当該変更後のスライスが割り当てられている他のサービスパラメータを特定し、SLA−SLが変更されたサービスパラメータと他のサービスパラメータとをHSS70へ通知する共に、HSS70に更新要求する(ステップS84)。HSS70は、SLA−SLが変更されたサービスパラメータが対応付けられているユーザを他のサービスパラメータに変更する。
HSS70は、MME90へ変更した旨を通知する(ステップS85)。ステップS86〜S98は、ステップS46〜S58とそれぞれ同様であるので、説明を省略する。
なお、HSS70は、「User ID」欄と「Service Parameter」欄とを対応付けた情報を記憶している場合について述べたが、図22に示すように、さらに「UE Usage type」欄をさらに対応付けてもよい。
つぎに、本実施形態のシステム1の作用効果について説明する。サービスマッピング装置10では、既にスライスが割り当てられているサービスと、当該スライスと、当該サービスを実行する装置を示すアドレスとを対応付けた割当サービステーブルを記憶している。また、サービスマッピング装置10の依頼受付部11は、機能の要件であるSLA―SLを受信する。決定部15は、受け付けられたサービスのサービス要件(SLA―SL)に対応する(サービス要件を満たす)SLA―SLを有するスライスを決定する。割当部16は、割当対象のサービスが、予めスライスに対応付けられている場合、決定されたスライスにサービスを割り当て変更する。
この場合、システム1は、割当要求を受けた際に、サービス要件を満たすスライスへ割り当て直すので、仮にサービス要件が変更されても、変更されたサービス要件を満たすスライスへ割り当て直すことができる。このように、動的に変更されるサービス要件に対応して割り当てるスライスを動的に変更することができ、適切なサービスを提供することができる。
また、サービスマッピング装置10の登録要求部17は、UE130からのサービスの利用要求に応じて、当該サービスの接続先を当該UE130と接続するMME90へ通知するDNSサーバ80に対して、変更後のスライスに対応するアドレスへアドレスの変更要求をする。この場合、スライスの割当変更した後に、DNSサーバ80へ接続先の変更要求をするので、ユーザからのサービス利用要求に応じて、適切にユーザへ変更後の接続先を通知することができる。
また、依頼受付部11は、割当対象のサービス及びSLA―SLを取得し、決定部15は、取得したSLA―SLを満たすスライスを決定する。この場合、サービス要件に応じて、当該サービスのデータを送受信する通信制御装置を切り替えるのでサービスを利用するユーザに対して好適なサービスを提供することができる。
また、リソース取得部14は、所定のタイミングで、スライス毎のリソース状況を取得する。スライス要件取得部13は、既にスライスが割り当てられているサービスのサービス要件と共に、各スライスのSLA―SLを特定する。決定部15は、サービスのサービス要件と、各スライスのSLA―SLと、リソース状況とに基づいて割り当てるスライスを決定する。
この場合、リソースの状況情報を考慮して、サービスに割り当てるスライスを決定するので、リソース状況が変動した場合でも適切なスライスを動的に割り当てることができる。
決定部15は、サービス要件を満たすスライスの内、空リソースが最も多いスライスに決定する。この場合、空リソースが最も多いリソースのスライスにサービスを割り当てるので、リソースの有効活用することができる。
なお、本明細書で説明した「情報」は、様々な異なる技術のいずれかを使用して表されてもよい。例えば、上記の説明全体に渡って言及され得るデータ、命令、コマンド、情報、信号、ビット、シンボル、チップなどは、電圧、電流、電磁波、磁界若しくは磁性粒子、光場若しくは光子、又はこれらの任意の組み合わせによって表されてもよい。
本明細書で使用する「判断」という用語は、多種多様な動作を包含する。「判断」は、例えば、計算(calculating)、算出(computing)、処理(processing)、導出(deriving)、調査(investigating)、探索(looking up)(例えば、テーブル、データベースまたは別のデータ構造での探索)、確認(ascertaining)などを含み得る。また、「判断」は、受信(receiving)(例えば、情報を受信すること)、アクセス(accessing)(例えば、メモリ中のデータにアクセスすること)などを含み得る。また、「判断」は、解決(resolving)、選択(selecting)、選定(choosing)、確立(establishing)、比較(comparing)などを含み得る。
本明細書で使用する「に基づいて」という記載は、別段に明記されていない限り、「のみに基づいて」を意味しない。言い換えれば、「に基づいて」という記載は、「のみに基づいて」と「に少なくとも基づいて」の両方を意味する。
本明細書で説明した各態様/実施形態の処理手順、シーケンス、フローチャートなどは、矛盾の無い限り、順序を入れ替えてもよい。例えば、本明細書で説明した方法については、例示的な順序で様々なステップの要素を提示しており、提示した特定の順序に限定されない。
本明細書で説明した各態様/実施形態は単独で用いてもよいし、組み合わせて用いてもよいし、実行に伴って切り替えて用いてもよい。また、所定の情報の通知(例えば、「Xであること」の通知)は、明示的に行うものに限られず、暗黙的(例えば、当該所定の情報の通知を行わない)ことによって行われてもよい。
以上、本発明について詳細に説明したが、当業者にとっては、本発明が本明細書中に説明した実施形態に限定されるものではないということは明らかである。本発明は、特許請求の範囲の記載により定まる本発明の趣旨及び範囲を逸脱することなく修正及び変更態様として実施することができる。したがって、本明細書の記載は、例示説明を目的とするものであり、本発明に対して何ら制限的な意味を有するものではない。