JP6867371B2 - スライス管理システム及びスライス管理方法 - Google Patents

Description

本発明は、スライス管理システム及びスライス管理方法に関する。

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

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

端末が上述のネットワークシステムのスライスからサービス提供を受けようとする場合、端末はサービス種類を指定した上でスライスへの接続を要求する。それにより、指定されたサービス種類から一意に特定されるスライスに端末は接続される。ここで、ネットワークシステムにおいて端末が指定したサービス種類から一意に特定されるスライスが提供されていない場合、例え端末が要求するサービスの提供が十分に受けられる別のスライスが存在しているとしても、スライスへの接続が拒絶され、端末はサービス提供を受けることができない。

そこで、本発明は、かかる課題に鑑みて為されたものであり、端末が接続するスライスをより柔軟に決定することができるスライス管理システム及びスライス管理方法を提供することを目的とする。

上記課題を解決するため、本発明の一側面のスライス管理システムは、ネットワークインフラ上に生成される仮想ネットワークであるスライスを管理するスライス管理システムであって、端末の接続先候補のスライスが優先度順に並んだ優先度リストを格納するメモリを備え、当該スライス管理システムは、端末によるスライスへの接続要求を取得した場合に、メモリに格納された優先度リストに基づいて端末が接続するスライスを決定する。かかる構成を採れば、端末が接続するスライスが、端末の接続先候補のスライスが優先度順に並んだ優先度リストに基づいて決定される。例えば、２以上の接続先候補のスライスから接続するスライスを決定することで、端末が接続することができるスライスをより確実に決定することができる。すなわち、端末が接続するスライスをより柔軟に決定することができる。それにより、端末のスライスへの接続が拒絶されることなく、端末はサービス提供を受けることができる可能性が高くなる。

また、本発明の一側面のスライス管理システムにおいて、優先度リストに含まれる接続先候補のスライスは、端末のユーザ毎に対応付けられており、当該スライス管理システムは、端末によるスライスへの接続要求を取得した場合に、優先度リストのうち、当該端末のユーザに対応付けられた接続先候補のスライスに基づいて当該端末が接続するスライスを決定することとしてもよい。かかる構成を採れば、端末が接続するスライスが、当該端末のユーザに対応付けられた接続先候補のスライスに基づいて決定されるため、例えば、端末のユーザ毎の要求に沿ったスライスに端末を接続することができる。それにより、より適切なスライスに端末を接続することができる。

また、本発明の一側面のスライス管理システムにおいて、優先度リストに含まれる接続先候補のスライスは、端末が要求するサービス毎に対応付けられており、当該スライス管理システムは、端末によるスライスへの接続要求を取得した場合に、優先度リストのうち、当該端末が要求するサービスに対応付けられた接続先候補のスライスに基づいて当該端末が接続するスライスを決定することとしてもよい。かかる構成を採れば、端末が接続するスライスが、当該端末が要求するサービスに対応付けられた接続先候補のスライスに基づいて決定されるため、例えば、端末が要求するサービスに沿ったスライスに端末を接続することができる。それにより、より適切なスライスに端末を接続することができる。

また、本発明の一側面のスライス管理システムにおいて、優先度リストに含まれる接続先候補のスライスは、ローミング先のスライスを含むこととしてもよい。かかる構成を採れば、ローミング先のスライスも接続候補として決定することができるため、端末の接続候補であるスライスの選択肢が増える。それにより、端末のスライスへの接続が拒絶されることなく、端末はサービス提供を受けることができる可能性が高くなる。

また、本発明の一側面のスライス管理システムにおいて、管理するスライスの運用状況、端末が要求するサービスのサービス要求条件、管理するスライスのサービス要求条件、端末のユーザの契約情報のうち少なくとも一つに基づいて優先度リストを更新することとしてもよい。かかる構成を採れば、管理するスライスの運用状況、端末が要求するサービスのサービス要求条件、管理するスライスのサービス要求条件、端末のユーザの契約情報のうち少なくとも一つに基づいて、動的かつ柔軟に優先度リストを更新することができる。それにより、より適切なスライスに端末を接続することができる。

また、本発明の一側面のスライス管理システムにおいて、端末によるスライスへの接続要求を取得した場合に、端末が移動する先である移動先エリアにて、移動元エリアで接続していたスライスに接続できるか否かを判定し、接続できないと判定された場合に、優先度リストに基づいて１以上の接続先候補のスライスを選択し、選択したスライスの中から優先度順に基づいて端末が接続するスライスを決定することとしてもよい。かかる構成を採れば、端末が、移動先エリアにて、移動元エリアで接続していたスライスに接続できない場合でも、端末が接続するスライスがより確実に決定されるため、端末をより確実にスライスに接続することができる。

ところで、本発明の一側面は、上記のようにスライス管理システムの発明として記述できる他に、以下のようにスライス管理方法の発明としても記述することができる。これはカテゴリが異なるだけで、実質的に同一の発明であり、同様の作用及び効果を奏する。

すなわち、本発明の一側面に係るスライス管理方法は、ネットワークインフラ上に生成される仮想ネットワークであるスライスを管理するスライス管理システムにより実行されるスライス管理方法であって、端末によるスライスへの接続要求を取得した場合に、メモリに格納された、端末の接続先候補のスライスが優先度順に並んだ優先度リストに基づいて、端末が接続するスライスを決定する決定ステップ、を含む。

また、本発明の一側面に係るスライス管理方法において、優先度リストに含まれる接続先候補のスライスは、端末が要求するサービス毎に対応付けられており、決定ステップは、端末によるスライスへの接続要求を取得した場合に、優先度リストのうち、当該端末が要求するサービスに対応付けられた接続先候補のスライスに基づいて当該端末が接続するスライスを決定することとしてもよい。

また、本発明の一側面に係るスライス管理方法は、端末によるスライスへの接続要求を取得した場合に、端末が移動する先である移動先エリアにて、移動元エリアで接続していたスライスに接続できるか否かを判定する判定ステップをさらに含み、決定ステップは、判定ステップにおいて接続できないと判定された場合に、優先度リストに基づいて１以上の接続先候補のスライスを選択し、選択したスライスの中から優先度順に基づいて端末が接続するスライスを決定することとしてもよい。

端末が接続するスライスをより柔軟に決定することができる。

従来技術における端末のエリア間移動時のスライス接続について説明する図である。 本発明の実施形態に係るスライス管理システムにおける端末のエリア間移動時のスライス接続について説明する図である。 本発明の実施形態に係るスライス管理システムのシステム構成図である。 メモリ（ＤＮＳ）に格納されたスライス情報のテーブル例を示す図である。 メモリ（ＮＦＶＯ、ＶＮＦＭ、ＶＩＭ）に格納されたリソース量のテーブル例を示す図である。 メモリ（ＳＳＦ）に格納された優先度リストのテーブル例を示す図である。 管理するスライスのサービス要求条件、及び、端末のユーザの契約情報のテーブル例を示す図である。 管理するスライスの運用状況、及び、端末が要求するサービスのサービス要求条件のテーブル例を示す図（その１）である。 管理するスライスの運用状況、及び、端末が要求するサービスのサービス要求条件のテーブル例を示す図（その２）である。 ＳＬＡ−ＳＬについて説明する図である。 本発明の実施形態に係るスライス管理システムに含まれる一部装置（ＳＳＦ）のハードウェア構成を示す図である。 本発明の実施形態に係るスライス管理システムに含まれる一部装置（ＳＭＦ）のハードウェア構成を示す図である。 本発明の実施形態に係るスライス管理システムで実行される処理（スライス管理方法）を示すフローチャート（ＳＳＦによる優先度リスト格納版）である。 本発明の実施形態に係るスライス管理システムで実行される処理（スライス管理方法）を示すフローチャート（ＵＥによる優先度リスト格納版）である。 本発明の実施形態に係るスライス管理システムで実行される処理（スライス管理方法）を示すフローチャート（ＢＳによる優先度リスト格納版）である。 本発明の実施形態に係るスライス管理システムで実行される処理（スライス管理方法）を示すフローチャート（ＤＮＳによる優先度リスト格納版）である。 本発明の実施形態に係るスライス管理システムで実行される処理（スライス管理方法）を示すフローチャート（独立リポジトリによる優先度リスト格納版）である。

以下、図面とともにスライス管理システム及びスライス管理方法の実施形態について詳細に説明する。なお、図面の説明においては同一要素には同一符号を付し、重複する説明を省略する。

まず、図１及び２を用いて、従来技術と本発明の実施形態に係るスライス管理システム１との主な違いについて説明する。

図１は、従来技術における端末のエリア間移動時のスライス接続について説明する図である。図１において、地理的に互いに異なる場所に３つのＤＣ（Data Center）であるＤＣ＃１、ＤＣ＃２及びＤＣ＃３が拠点を設けている。各ＤＣは、当該ＤＣに含まれるネットワークインフラを用いてＤＣ間を跨がるスライスを形成している。スライス（あるいはネットワークスライス）とは、ネットワーク装置のリンクとノードの資源を仮想的に切り分けて、切り分けた資源を結合し、ネットワークインフラ上に論理的に生成される仮想ネットワーク又はサービス網であり、スライス同士は資源を分離しており、互いに干渉しない。サービスとは、通信サービス（専用線サービス等）やアプリケーションサービス（動画配信、エンベデッド装置等のセンサ装置を利用したサービス）等のネットワーク資源を用いたサービスをいう。

図１に示す通り、ＤＣ＃１及びＤＣ＃２は、ＤＣ＃１及びＤＣ＃２を跨がるスライスであるＮＳ（Network Slice）−Ｃａｒを形成している。なお、ＮＳ−Ｃａｒは、各ＤＣに生成された、スライスの機能エンティティであるＮＦＥ（Network Function Entity）−Ｃａｒを構成要素として含んでいる。ＮＳ−Ｃａｒは、端末（車）に対して車車間の移動体通信サービスを提供する。ＮＳ−Ｃａｒでのサービス要求条件としては、低遅延及び局所内通信が求められる。

さらに、ＤＣ＃１、ＤＣ＃２及びＤＣ＃３は、ＤＣ＃１、ＤＣ＃２及びＤＣ＃３を跨がるスライスであるＮＳ−ｅＭＢＢ（evolved Mobile Broad Band）を形成している。なお、ＮＳ−ｅＭＢＢは、各ＤＣに生成された、スライスの機能エンティティであるＮＦＥ−ｅＭＢＢを構成要素として含んでいる。ＮＳ−ｅＭＢＢは、既存の携帯電話通信網と同じ役割を持つものであり、端末に対してインターネット接続を可能とする移動体通信サービスを提供する。ＮＳ−ｅＭＢＢでのサービス要求条件としては、既存の携帯電話通信網レベルの遅延及び帯域が求められる。

なお、本実施形態全体において、各ＤＣに含まれるネットワークインフラが形成するスライスが提供する移動体通信サービスの提供範囲（端末が無線通信が可能な範囲）をエリアと呼ぶ。また、便宜上、ＤＣをエリアと呼ぶこともある。図１において、ＤＣ＃１及びＤＣ＃２は都市エリアであり、ＤＣ＃３は地方エリアである。ＮＳ−ＣａｒはＤＣ＃１及びＤＣ＃２の都市エリアにおいては形成されている（カバーしている）が、ＤＣ＃３の地方エリアにおいては形成されていない（カバーしていない）。一方、ＮＳ−ｅＭＢＢはＤＣ＃１及びＤＣ＃２の都市エリア、並びにＤＣ＃３の地方エリアにおいてあまねく形成されている。

図１では、ＮＳ−Ｃａｒが提供する移動体通信サービスにアクセス可能な端末である車２ａが、順に、ＤＣ＃１の都市エリア、ＤＣ＃２の都市エリア、及びＤＣ＃３の地方エリアへとエリア間を移動する場面を示している。まず、車２ａは、ＤＣ＃１の都市エリアにてＮＳ−Ｃａｒに接続し、そのままＤＣ＃２の都市エリアに移動した後も、引き続き（ＤＣ＃２の都市エリアの）ＮＳ−Ｃａｒに接続することができる。しかしながら、車２ａは、その後にＤＣ＃３の地方エリアに移動すると、ＤＣ＃３の地方エリアではＮＳ−Ｃａｒは形成されていないため、ＮＳ−Ｃａｒに接続することができない。すなわち、従来技術においては、このようにＤＣ＃３の地方エリアに移動した車２ａは、ＤＣ＃１及びＤＣ＃２の都市エリアにて接続していたＮＳ−Ｃａｒに引き続き接続することができない。

図２は、スライス管理システム１における端末のエリア間移動時のスライス接続について説明する図である。図１と同じ内容については説明を省略する。スライス管理システム１は、車２ａがＤＣ＃３の地方エリアに移動した際に、車２ａがＤＣ＃２の都市エリアにて接続していたＮＳ−Ｃａｒに引き続き接続できるか否かを判定し、接続できないと判定した場合、車２ａが引き続きＮＳ−Ｃａｒ相当のサービスを提供可能なスライスに接続できるように、車２ａからの接続を、ＮＳ−Ｃａｒ相当のサービスを提供可能なスライスであって、ＤＣ＃３においても形成されているスライスであるＮＳ−ｅＭＢＢに切り替える。以上のようにスライス管理システム１においては、ＮＳ−Ｃａｒへの接続をＮＳ−ｅＭＢＢに切り替えることで、ＤＣ＃３の地方エリアに移動した車２ａは、ＤＣ＃１及びＤＣ＃２の都市エリアにて接続していたＮＳ−Ｃａｒ相当のサービスを提供可能なＮＳ−ｅＭＢＢに引き続き接続することができる。

続いて、スライス管理システム１の詳細について説明する。図３は、スライス管理システム１のシステム構成図である。図３に示す通り、スライス管理システム１（スライス管理システム）は、ＵＥ（User Equipment）２（端末）、ＢＳ（Base Station）３、ＳＳＦ（Slice Selection Function）４、ＤＮＳ（Domain Name System）５（メモリ）、ＳＭＦ（Service-slice Mapping Function）６及びＭＡＮＯ（Management And Orchestration）７を含んで構成される。なお、スライス管理システム１は、これら構成要素のうち一部を含まなくてもよいし、その他の構成要素を含んでもよい。

本実施形態において、スライス管理システム１は、物理サーバ上に実現される仮想マシンにおいて動作する仮想サーバによって移動通信端末であるＵＥ２に対して通信機能を提供する。即ち、スライス管理システム１は、仮想化された移動体通信ネットワークである。通信機能は、仮想マシンによって当該通信機能に応じた通信処理を実行することで移動通信端末に対して提供される。スライス管理システム１は、４Ｇ（第４世代移動通信規格）、５Ｇ（第５世代移動通信規格）及びＮＦＶ（Network Functions Virtualisation）アーキテクチャなどで定義されている構成要素を含んでおり、また含んでもよく、それら構成要素の詳細については説明を適宜省略する。

ＵＥ２は、スライス管理システム１によって提供される移動体通信ネットワークに接続することで、移動体通信を行うことが可能な移動通信端末である。本実施形態において、ＵＥ２は、移動体通信機能を備えた車である。ＵＥ２は、スライスへの接続を依頼する旨の情報であるスライス接続依頼をＢＳ３に送信することで、スライス管理システム１が管理（形成）する当該スライスに接続し、当該スライスが提供するサービスを受けることができる。ＵＥ２は、スライス接続依頼を送信する際に、スライス管理システム１に対して、どのサービスを受けることを要求するか、すなわちどのスライスに接続することを要求するかを指定するパラメータとして“UE Usage Type”及び“Service Type”をスライス接続依頼に含めて送信する。

“UE Usage Type”は、ＵＥ２毎、若しくはＵＥ２のユーザ毎に定められた「どのサービスを実行するための端末か」を示す情報である。“UE Usage Type”の具体例としては、携帯電話を示す“mobile phone”及び（ネットワークに接続された）車“car”等が挙げられる。

“Service Type”は、“UE Usage Type”とは独立に定められた情報であり、「どのサービスを実行するか」を記した情報である。“Service Type”の具体例としては、音声通信サービスを示す“voice call”、映像ストリーミングサービスを示す“movie streaming”、ｅＭＢＢサービスを示す“eMBB”及び車車間通信サービスを示す“intra car communication”等が挙げられる。

ＵＥ２は、スライス接続依頼に、“UE Usage Type”及び“Service Type”以外に、ＵＥ２を識別する端末識別情報、ＵＥ２のユーザを識別するユーザ識別情報、及びＵＥ２が在圏するＢＳ３のセルを識別するセル識別情報などを含めてもよい。なお、ＵＥ２は、エリアを跨いで移動したとき（エリア間を移動したとき）、移動先エリアにてスライス接続依頼を（移動先エリアのＢＳ３に）送信する。

ＢＳ３は、一般的な基地局である。ＢＳ３は、ＵＥ２からスライス接続依頼を受信すると、受信したスライス接続依頼をＳＳＦ４に送信する。ＢＳ３は、受信したスライス接続依頼をＳＳＦ４に送信する際に、スライス接続依頼を送信したＵＥ２が在圏する当該ＢＳ３におけるセルを識別するセル識別情報などを含めて送信してもよい。

ＢＳ３は、ＳＳＦ４にスライス接続依頼を送信した応答として、ＵＥ２の接続先となるスライスに関するスライス接続先情報、または接続先のスライスが決定できなかった旨を示す接続先エラー情報を受信する。ＢＳ３は、ＳＳＦ４からスライス接続先情報を受信した場合、受信したスライス接続先情報が示すスライスに、スライス接続依頼を送信してきたＵＥ２を接続する。また、ＢＳ３は、ＳＳＦ４から接続先エラー情報を受信した場合、受信した接続先エラー情報をＵＥ２に送信する。なお、ＵＥ２は、接続先エラー情報を受信することで、スライスに接続できないことを判定する。

ＳＳＦ４は、独立したノード（サーバ装置など）である。ＳＳＦ４は、ＢＳ３からスライス接続依頼を受信すると、受信したスライス接続依頼に基づいて、当該スライス接続依頼を送信したＵＥ２をどのスライスに接続するかを決定し、接続先のスライスが決定した場合は、当該接続先のスライスに関するスライス接続先情報をＢＳ３に送信する。接続先のスライスが決定できなかった場合は、その旨を示す接続先エラー情報をＢＳ３に送信する。ＳＳＦ４の詳細（図３に示す機能ブロック）については後述する。

ＤＮＳ５は、一般的なＤＮＳのサービスを提供するノードである。ＤＮＳ５は、スライス管理システム１にて管理されているスライスであって、エリア毎にＵＥ２が接続可能なスライスに関するスライス情報を格納する。スライス情報は、スライスが提供されているＤＣを識別するＤＣ識別情報、スライスが提供されている当該ＤＣにおけるセルを識別するセル識別情報、スライスを識別するスライス識別情報、及びスライスのＩＰアドレスを含む。また、スライス情報は、“UE Usage Type”及び“Service Type”毎に対応付けられていてもよい。

図４は、ＤＮＳ５にて格納されているスライス情報のテーブル例を示す図である。図４（ａ）に示すスライス情報は、“UE Usage Type”が“car”であり、かつ“Service Type”が“eMBB”に対応付けられており、当該スライス情報が示すスライスは、車がｅＭＢＢサービスを実行するためのスライスであることを示している。また、図４（ａ）に示すテーブル例の１レコード目は、ＤＣ＃１のセル＃１〜１０においてスライス識別情報が“eMBB”であるスライスが形成されており、そのＩＰアドレスが“aa.aa.aa.aa”であることを示している。同様に、図４（ｂ）に示すスライス情報は、“UE Usage Type”が“car”であり、かつ“Service Type”が“intra car communication”に対応付けられており、当該スライス情報が示すスライスは、車がｅ車車間通信サービスを実行するためのスライスであることを示している。なお、図４（ｂ）に示すテーブル例の３レコード目は、ＤＣ＃３のセル＃１１〜３０では車が車車間通信サービスを実行するためのスライスが形成（提供）されていないことを示している。

図３に戻り、ＳＭＦ６は、スライスの管理を行ったり、後述の優先度リストの更新を行ったりするノードである。ＳＭＦ６の詳細（図３に示す機能ブロック）については後述する。

ＭＡＮＯ７は、スライスに関する資源を管理するためのアーキテクチャである。図３に示す通り、ＭＡＮＯ７は、ＮＦＶＯ７０、ＶＮＦＭ７１及びＶＩＭ７２を含んで構成される。

ＮＦＶＯ７０は、ＶＮＦＭ７１及びＶＩＭ７２を管理し、ＳＭＦ６からの指示に応じて、スライスの作成・削除やリソース運用状況取得を行うノードである。ＶＮＦＭ７１は、ＤＣにおけるスライスのソフトウェアリソースのリソース管理を行うノードである。ＶＩＭ７２は、ＤＣにおけるスライスの物理・論理ハードウェアリソースのリソース管理を行うノードである。

例えば、ＮＦＶＯ７０は、ＳＭＦ６からスライスの作成を指示する旨の情報であるスライス作成指示を受信すると、ＶＮＦＭ７１及びＶＩＭ７２に対して、対応するＤＣ上のリソースを取得させ、ＤＣ上にてスライス用のＮＦＥを構成し、スライスを作成する。また例えば、ＮＦＶＯ７０は、ＳＭＦ６からスライスの削除を指示する旨の情報であるスライス削除指示を受信すると、ＶＮＦＭ７１及びＶＩＭ７２に対して、対応するＤＣ上のスライス用のＮＦＥを削除し、ＤＣ上のリソースを解放させ、スライスを削除する。なお、ＤＣ上に構成されるＮＦＥは、Ｕ−ｐｌａｎｅ用及びＣ−ｐｌａｎｅ用に分かれて構成されてもよい。

図５は、ＮＦＶＯ７０、ＶＮＦＭ７１及びＶＩＭ７２のそれぞれに格納されたリソース量のテーブル例を示す図である。図５（ａ）は、ＮＦＶＯ７０に格納されたリソース量のテーブル例である。図５（ａ）に示すテーブル例では、スライス識別情報と当該スライス識別情報が示すスライスの構成要素の識別情報（ＮＦＥの識別情報）とが対応付けられている。図５（ｂ）は、ＶＮＦＭ７１に格納されたリソース量のテーブル例である。図５（ｂ）に示すテーブル例では、スライスの構成要素であるＮＦＥの識別情報と当該ＮＦＥのＣＰＵ使用率とが対応付けられている。図５（ｃ）は、ＶＩＭ７２に格納されたリソース量のテーブル例である。図５（ｃ）に示すテーブル例では、ＤＣを識別するＤＣ識別情報と当該ＤＣに存在するハードウェアの識別情報と当該ハードウェアのＣＰＵ使用率とが対応付けられている。

なお、ＳＭＦ６は、ＮＦＶＯ７０、ＶＮＦＭ７１及びＶＩＭ７２それぞれに対してリソース運用状況取得を指示する旨の情報であるリソース運用状況取得指示を送信することで、その応答として、上述のＮＦＶＯ７０、ＶＮＦＭ７１及びＶＩＭ７２それぞれに格納されたリソース量のテーブルを取得し、ＳＭＦ６内に格納する。ＳＭＦ６は、定期的にリソース運用状況取得指示を送信することで、ＮＦＶＯ７０、ＶＮＦＭ７１及びＶＩＭ７２の最新のリソース量をＳＭＦ６内に格納し、格納された最新のリソース量に基づいて、スライスを特定のＤＣ上で構築可能か否か等を判定する。

以上説明したスライス管理システム１に含まれるＢＳ３、ＳＳＦ４、ＤＮＳ５、ＳＭＦ６、ＮＦＶＯ７０、ＶＮＦＭ７１及びＶＩＭ７２のうち何れか一つ以上は、上述の通り物理的なサーバ装置などによって実現されてもよいし、物理的なサーバ装置上のプログラムが実行されることにより実現されてもよい。また、ＢＳ３、ＳＳＦ４、ＤＮＳ５、ＳＭＦ６、ＮＦＶＯ７０、ＶＮＦＭ７１及びＶＩＭ７２のうち何れか二つ以上は、一つの物理的なサーバ装置などによって実現されてもよいし、一つの物理的なサーバ装置上のプログラムが実行されることにより実現されてもよい。また、ＳＳＦ４は、３ＧＰＰ（Third Generation Partnership Project）アーキテクチャにおけるＭＭＥ（Mobility Management Entity）、ＨＳＳ（Home Subscriber Server）及びＤＮＳから構成されてもよい。

続いて、図３に示すＳＳＦ４の各機能ブロックについて説明する。

スライス接続依頼取得部４０は、ＢＳ３経由でＵＥ２からスライス接続依頼を受信（取得）し、受信したスライス接続依頼をスライス接続判定部４１に送信する。

スライス接続判定部４１は、スライス接続依頼取得部４０からスライス接続依頼を受信すると、ＵＥ２がエリア間を移動するときにＵＥ２が移動元エリアにて接続していたスライスに移動先エリアにて接続できるか否かを、ＤＮＳ５に格納されたスライス情報に基づいて判定する。具体的に、スライス接続判定部４１は、スライス接続依頼取得部４０からスライス接続依頼を受信すると、受信したスライス接続依頼に含まれる端末識別情報が示すＵＥ２から前回受信したスライス接続依頼に含まれる“UE Usage Type”、“Service Type”及びセル識別情報と、今回受信したスライス接続依頼に含まれる同内容を比較することで、ＵＥ２がエリア間を移動しているか否か、及び、前回と同じスライスに接続しようとしているか否かを判定する。なお、前回受信したスライス接続依頼と比較を行うため、ＳＳＦ４は、過去のスライス接続依頼の履歴を格納する。スライス接続判定部４１は、ＵＥ２がエリア間を移動しており、移動元エリアにて接続していたスライスに移動先エリアでも接続しようとしている場合、今回受信したスライス接続依頼に含まれる“UE Usage Type”、“Service Type”及びセル識別情報を引数としてＤＮＳ５にＤＮＳ問い合わせを行うことで、ＵＥ２が接続を依頼しているスライスのＩＰアドレスの問い合わせを行う。

例えば、ＤＮＳ５にて格納されているスライス情報のテーブルが図４に示すテーブルであって、スライス接続依頼に含まれる“UE Usage Type”が“car”であり、“Service Type”が“eMBB”であり、セル識別情報が“＃２２”である場合、図４（ａ）に示すテーブルの３レコード目に該当するため、スライス接続判定部４１は、ＤＮＳ５からのＤＮＳ返答としてＩＰアドレス“cc.cc.cc.cc”を受信する。このようにＵＥ２が接続を依頼しているスライスのＩＰアドレスを取得できた場合、スライス接続判定部４１は、ＵＥ２がエリア間を移動するときにＵＥ２が移動元エリアにて接続していたスライスに移動先エリアにて接続できると判定する。続いて、スライス接続判定部４１は、取得できたＩＰアドレスをＢＳ３に返信し、当該ＩＰアドレスが示すスライスにＵＥ２を接続させる。

また、例えば、スライス接続依頼に含まれる“UE Usage Type”が“car”であり、“Service Type”が“intra car communication”であり、セル識別情報が“＃２８”である場合、図４（ｂ）に示すテーブルの３レコード目に該当するが、当該ＤＣ＃３には対応するスライスは存在しない（スライス識別情報及びＩＰアドレスが空欄の場合はスライスが存在しないことを示す）。その場合、スライス接続判定部４１は、ＤＮＳ５からのＤＮＳ返答として、接続できるスライスが無い旨の情報を受信する。このようにＵＥ２が接続を依頼しているスライスが存在しない場合、スライス接続判定部４１は、ＵＥ２がエリア間を移動するときにＵＥ２が移動元エリアにて接続していたスライスに移動先エリアにて接続できないと判定する。接続できないと判定した場合、スライス接続判定部４１は、受信したスライス接続依頼に含まれる情報をスライス切替部４３に送信する。

スライス接続判定部４１は、スライス接続依頼取得部４０からスライス接続依頼を受信すると、受信したスライス接続依頼にて要求されているスライスに接続できるか否かを、ＤＮＳ５に格納されたスライス情報に基づいて判定してもよい。当該判定は、上述の判定と同様である。

優先度リスト格納部４２は、ＵＥ２の接続先候補のスライスが優先度順に並んだ優先度リストを格納する。図６は、優先度リスト格納部４２によって格納された優先度リストのテーブル例を示す図である。図６に示すテーブル例では、優先度リストの対象であるＵＥ２のユーザ識別情報（“User ID”列）、上述の“Service Type”であり、ＵＥ２が要求するサービスの種類（“Service Type”列）、及びＵＥ２の接続先候補のスライスが優先度順に並んだ優先度リスト（“precedence list”列）が含まれる。例えば、図６に示すテーブル例のうち１レコード目は、“Service Type”として“intra car communication”を要求している、ユーザ識別情報が“００１”のユーザに対して、優先順位としてまずは“NS-Car”スライス、次に“NS-eMBB”スライス、次に“NS-XX”スライスを接続先候補として挙げている優先度リストを示す。なお、優先度リストは、ユーザ識別情報及び“Service Type”の少なくとも一方が上述のように対応付けられてなくてもよい。

優先度リスト格納部４２によって格納された優先度リストは、ローミング先のスライスを含んでもよい。ローミング先のスライスとは、例えば、スライス管理システム１を管理する移動体通信事業者とは異なる移動体通信事業者が管理するスライスである。優先度リストに含まれるスライスのうち、ローミング先のスライスについては当該スライスを特定可能なスライス特定情報、例えばＩＰアドレスが対応付いている。なお、優先度リストに含まれる各スライスについて、当該スライスがローミング先か否かを示すフラグ値が対応付いていてもよい。

スライス切替部４３は、スライス接続判定部４１から受信したスライス接続依頼に含まれる情報を受信し、受信した情報及び優先度リスト格納部４２によって格納された優先度リストに基づいて、ＵＥ２が接続するスライスを決定する。例えば、スライス切替部４３は、スライス接続依頼に含まれるユーザ識別情報及び“Service Type”を抽出し、優先度リスト格納部４２によって格納された優先度リストのうち、抽出したユーザ識別情報及び“Service Type”に対応する優先度リストを取得する。そして、スライス切替部４３は、取得した優先度リストに含まれる接続先候補のスライスについて、優先度順にそれぞれ接続可能かＤＮＳ５に対してＤＮＳ問い合わせを行い、接続可能なスライスを、最終的にＵＥ２が接続するスライスとして決定する。

スライス切替部４３は、スライス接続依頼にユーザ識別情報及び“Service Type”の一方しか含まれない場合は、当該一方に対応する優先度リストを取得してもよいし、両方が含まれない場合は、優先度リスト格納部４２によって格納された優先度リスト全体を取得してもよい。例えば、スライス切替部４３は、スライス接続依頼にユーザ識別情報が含まれ、“Service Type”が含まれない場合は、優先度リスト格納部４２によって格納された優先度リストのうち、当該ユーザ識別情報が識別するユーザに対応付けられた接続先候補のスライスに基づいてＵＥ２が接続するスライスを決定する。また例えば、スライス切替部４３は、スライス接続依頼に“Service Type”が含まれ、ユーザ識別情報が含まれない場合は、優先度リスト格納部４２によって格納された優先度リストのうち、（ＵＥ２が要求する）“Service Type”が示すサービスに対応付けられた接続先候補のスライスに基づいてＵＥ２が接続するスライスを決定する。

スライス切替部４３は、ＵＥ２が接続するスライスを決定すると、決定したスライスに関する情報を含むノード切替返答をＢＳ３に送信する。スライス切替部４３は、ローミング先のスライスを決定した場合は、優先度リストにおいて当該スライスに対応付いたスライス特定情報も含めたノード切替返答をＢＳ３に送信する。なお、ＢＳ３は、受信したノード切替返答に含まれるスライスに関する情報やスライス特定情報に基づいて、対応するスライスとの接続（ベアラ確立）を行う。

なお、優先度リスト格納部４２は、ＳＳＦ４が備えることに限定されず、ＵＥ２、ＢＳ３及びＤＮＳ５の何れかが備えてもよく、また、スライス管理システム１に含まれる不図示の独立リポジトリ（サーバ装置などにより構成）が備えてもよい。すなわち、優先度リスト格納部４２は、スライス管理システム１に含まれる何れかのノード（のメモリ）が備えてもよい。その場合、上述で説明したスライス切替部４３が行う優先度リスト格納部４２との間のデータ処理は、優先度リスト格納部４２を備えるノードとのデータ通信処理を行うことによって実現される。

続いて、図３に示すＳＭＦ６の各機能ブロックについて説明する。

優先度リスト更新部６０は、優先度リスト格納部４２によって格納された優先度リストを、管理するスライスの運用状況、ＵＥ２が要求するサービスのサービス要求条件、管理するスライスのサービス要求条件、ＵＥ２のユーザの契約情報のうち少なくとも一つに基づいて更新する。以下では図７〜１０を用いて、優先度リスト更新部６０による優先度リストの更新について説明する。

なお、以下で説明するＳＬＡ−ＳＬ（Service Level Agreement Sufficient Level）の一例として、図１０にＳＬＡ−ＳＬのテーブル例を示す。ＳＬＡ−ＳＬは、サービス毎に定められ、このサービス要求条件を満たすためにはどの程度の機能が必要かを示すものである。図１０（ａ）に示すテーブル例は、ＳＬＡ−ＳＬの各パラメータの値が示す基準を示している。図１０（ｂ）に示すテーブル例は、５つのサービスのＳＬＡ−ＳＬの例を示している。例えば、図１０（ｂ）に示すテーブル例の１レコード目は、“pervasive video”サービスに関するＳＬＡ−ＳＬが（２，２，３，２）であることを示している。すなわち、“latency”に対して要求されるサービス要求条件が“10ms”のため１つ目のパラメータ値は（図１０（ａ）のテーブル例より）“２”、“mobility”に対して要求されるサービス要求条件が“100km/h”のため２つ目のパラメータ値は“２”、“throughput”に対して要求されるサービス要求条件が“300Mbps”のため３つ目のパラメータ値は“３”、“UE density”に対して要求されるサービス要求条件が“2500km²”のため４つ目のパラメータ値は“２”である。

図７は、ＳＭＦ６によって格納された、管理するスライスのサービス要求条件のテーブル例（図７（ａ））及びＵＥ２のユーザの契約情報のテーブル例（図７（ｂ））を示す図である。優先度リスト更新部６０は、図７（ａ）及び（ｂ）に示すテーブル例に基づいて、図６に示す優先度リストを作成（更新）してもよい。例えば、“Service Type”が“intra car communication”に対応するスライスのＳＬＡ−ＳＬが（２，２，２，２）である場合において、図７（ｂ）に示すテーブル例によれば、ユーザ識別情報が“001”のユーザは、「ＳＬＡ−ＳＬを満たす別のスライスに接続し、高品質なサービスを継続すること」を望んでいるため、図７（ａ）に示すテーブル例に基づき、優先度リスト更新部６０は、優先順位の順に“NS-car”、“NS-eMBB”及び“NS-XX”を選択し、優先度リストとする。同様に、ユーザ識別情報が“002”のユーザは、「接続できないのであれば接続せず、代わりに利用料を安くすること」を望んでいるため、図７（ａ）に示すテーブル例に基づき、優先度リスト更新部６０は、“NS-car”のみを選択し、優先度リストとする。同様に、ユーザ識別情報が“003”のユーザは、「品質が下がってもいいのでサービスが継続されること」を望んでいるため、図７（ａ）に示すテーブル例に基づき、優先度リスト更新部６０は、優先順位の順に“NS-car”、“NS-YY”及び“NS-ZZ”を選択し、優先度リストとする。なお、説明の便宜上、図７（ｂ）に示すテーブル例の「契約情報」は、文章にて示されているが、実際はコンピュータが容易に処理可能な形式で格納されるものとする。また、優先度リスト更新部６０は、管理するスライスのサービス要求条件及びＵＥ２のユーザの契約情報の何れか一方に基づいて優先度リストを作成（更新）してもよい。

図８は、ＳＭＦ６によって格納された、管理するスライスの運用状況のテーブル例（図８（ａ））及びＵＥ２が要求するサービスのサービス要求条件のテーブル例（図８（ｂ））を示す図である。優先度リスト更新部６０は、図８（ａ）及び（ｂ）に示すテーブル例に基づいて、図６に示す優先度リストを作成（更新）してもよい。例えば、図８（ｂ）に示すテーブル例において、“サービス１”のＳＬＡ−ＳＬが（１，１，１，１）であるため、図８（ａ）に示すテーブル例のスライス毎のＳＬＡ−ＳＬ及びリソース利用状況に基づき、優先度リスト更新部６０は、優先順位の順に“スライス２”、“スライス１”及び“スライス３”を選択し、優先度リストとする。

また、スライスの運用状況に変化があり、図８（ａ）に示すテーブル例が、図９（ａ）に示すテーブル例に変化した場合（“スライス２”の利用状況が“４０％”から“８０％”に変化）、優先度リスト更新部６０は当該変化に基づき、図９（ｂ）の「優先度」列に示す通り、優先順位の順に“スライス１”及び“スライス３”とした優先度リストに更新する。

以上、図３に示すＳＳＦ４及びＳＭＦ６の各機能ブロックについて説明した。

ここで、ＳＳＦ４は、ＣＰＵ等のハードウェアから構成されているものである。図１１は、ＳＳＦ４のハードウェア構成の一例を示す図である。図３に示されるＳＳＦ４は、物理的には、図１１に示すように、一又は複数のＣＰＵ４００、主記憶装置であるＲＡＭ４０１及びＲＯＭ４０２、ディスプレイ等の入出力装置４０３、通信モジュール４０４及び補助記憶装置４０５などを含むコンピュータシステムとして構成されている。

図３に示すＳＳＦ４の各機能ブロックの機能は、図１１に示すＣＰＵ４００、ＲＡＭ４０１等のハードウェア上に所定のコンピュータソフトウェアを読み込ませることにより、ＣＰＵ４００の制御のもとで入出力装置４０３、通信モジュール４０４、及び補助記憶装置４０５を動作させるとともに、ＲＡＭ４０１におけるデータの読み出し及び書き込みを行うことで実現される。

同様に、ＳＭＦ６は、ＣＰＵ等のハードウェアから構成されているものである。図１２は、ＳＭＦ６のハードウェア構成の一例を示す図である。図３に示されるＳＭＦ６は、物理的には、図１２に示すように、一又は複数のＣＰＵ６００、主記憶装置であるＲＡＭ６０１及びＲＯＭ６０２、ディスプレイ等の入出力装置６０３、通信モジュール６０４及び補助記憶装置６０５などを含むコンピュータシステムとして構成されている。

図３に示すＳＭＦ６の各機能ブロックの機能は、図１２に示すＣＰＵ６００、ＲＡＭ６０１等のハードウェア上に所定のコンピュータソフトウェアを読み込ませることにより、ＣＰＵ６００の制御のもとで入出力装置６０３、通信モジュール６０４、及び補助記憶装置６０５を動作させるとともに、ＲＡＭ６０１におけるデータの読み出し及び書き込みを行うことで実現される。

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

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

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

続いて、図１３〜１７に示すフローチャート図を用いて、スライス管理システム１におけるスライス管理方法の主な処理について説明する。各フローチャート図の違いは、主に優先度リストを格納するノードである。図１３に示すフローチャート図は、独立リポジトリが優先度リストを格納する場合のフローチャート図である。図１４に示すフローチャート図は、ＵＥ２が優先度リストを格納し、図１５に示すフローチャート図は、ＢＳ３が優先度リストを格納し、図１６に示すフローチャート図は、ＳＳＦ４が優先度リストを格納し、図１７に示すフローチャート図は、ＤＮＳ５が優先度リストを格納する場合のフローチャート図である。

まず、図１３に示すフローチャート図について説明する。ＵＥ２がＤＣ＃２からＤＣ＃３へ移動すると、ＤＣ＃２及びＤＣ＃３のＢＳ３間でハンドオーバの準備処理が実行され、ＤＣ＃３のＢＳ３により、（ＵＥ２から受信した）スライス接続依頼（ノード切替依頼）がＳＳＦ４に送信される（ステップＳ１）。次に、スライス接続判定部４１により、ＤＮＳ５に対してＤＮＳ問い合わせが行われ（ステップＳ２）、その応答としてＤＮＳ返答が取得される（ステップＳ３）。次に、スライス接続判定部４１により、Ｓ３にて取得されたＤＮＳ返答に基づいて、ＵＥ２が移動元エリアにて接続していたスライスに移動先エリアにて接続できるか否かが判定され、ここではスライスに接続できないと判定されたものとする（ステップＳ４）。次に、スライス接続判定部４１により、独立リポジトリに対して優先度リストの問い合わせが行われ（ステップＳ５）、その応答として優先度返答が取得される（ステップＳ６）。ここでは、優先度返答として、接続候補である複数のスライスに関する情報が返答されるものとする。なお、優先度返答として接続候補である１つのスライスに関する情報が返答されてもよい。

次に、スライス切替部４３により、ＤＮＳ５に対してＤＮＳ問い合わせが行われ（ステップＳ７）、その応答としてＤＮＳ返答が取得される（ステップＳ８）。ここでは、Ｓ６にて取得された接続候補である複数のスライスそれぞれに対してＤＮＳ問い合わせが行われ、対応するＩＰアドレスが取得されるものとする。次に、スライス切替部４３は、取得したＤＮＳ返答に基づいて、ＵＥ２が接続する１つのスライスを決定する。例えば、スライス切替部４３は、ＤＮＳ５からＩＰアドレスが取得されたスライスのうち優先順位が一番高いスライスを、ＵＥ２が接続するスライスとして決定する。次に、スライス切替部４３により、決定したスライスに関する情報を含むノード切替返答がＢＳ３に送信される（ステップＳ９）。次に、ＢＳ３により、受信したノード切替に含まれるスライスに関する情報が示すスライスに対して接続要求を送信し（ステップＳ１０）、ベアラが確立される（ステップＳ１１）。

以下では、図１４〜１７に示すフローチャート図のうち、図１３との差分について説明する。図１４〜１７に示すフローチャート図に含まれるステップ番号のうち、図１３に示すフローチャート図と共通のものは、上述の対応するステップ番号の説明を参照されたい。

図１４に示すフローチャート図について説明する。Ｓ３の後、ＳＳＦ４により、Ｓ３で受信したＤＮＳ返答（接続するスライスが無い旨を示す）がＵＥ２に送信される（ステップＳ２０）。次に、ＵＥ２により、スライスに接続できないと判定され（Ｓ４と同様）、続いて、ＵＥ２に格納された優先度リストが参照され、接続候補であるスライスに関する情報が取得される（Ｓ５及びＳ６と同様）（ステップＳ２１）。次に、ＵＥ２により、接続候補であるスライスに関する情報を含むノード切替依頼がＳＳＦ４に送信される（ステップＳ２２）。Ｓ２２に続き、Ｓ７が実行される。

図１５に示すフローチャート図について説明する。Ｓ３の後、ＳＳＦ４により、Ｓ３で受信したＤＮＳ返答（接続するスライスが無い旨を示す）がＢＳ３に送信される（ステップＳ３０）。次に、ＢＳ３により、スライスに接続できないと判定され（Ｓ４と同様）、続いて、ＢＳ３に格納された優先度リストが参照され、接続候補であるスライスに関する情報が取得される（Ｓ５及びＳ６と同様）（ステップＳ３１）。次に、ＢＳ３により、接続候補であるスライスに関する情報を含むノード切替依頼がＳＳＦ４に送信される（ステップＳ３２）。Ｓ３２に続き、Ｓ７が実行される。

図１６に示すフローチャート図について説明する。Ｓ３の後、ＳＳＦ４により、スライスに接続できないと判定され（Ｓ４と同様）、続いて、ＳＳＦ４に格納された優先度リストが参照され、接続候補であるスライスに関する情報が取得される（Ｓ５及びＳ６と同様）（ステップＳ４０）。Ｓ４０に続き、Ｓ７が実行される。

図１７に示すフローチャート図について説明する。Ｓ２の後、ＤＮＳ５により、Ｓ２で受信したＤＮＳ問い合わせに基づいて、スライスに接続できないと判定され（Ｓ４と同様）、続いて、ＤＮＳ５に格納された優先度リストが参照され、接続候補であるスライスに関する情報が取得される（Ｓ５及びＳ６と同様）（ステップＳ５０）。Ｓ５０に続き、Ｓ８が実行される。

次に、本実施形態のように構成されたスライス管理システム１の作用効果について説明する。

本実施形態のスライス管理システム１によれば、ＵＥ２が接続するスライスが、ＵＥ２の接続先候補のスライスが優先度順に並んだ優先度リストに基づいて決定される。例えば、２以上の接続先候補のスライスから接続するスライスを決定することで、ＵＥ２が接続することができるスライスをより確実に決定することができる。すなわち、ＵＥ２が接続するスライスをより柔軟に決定することができる。それにより、ＵＥ２のスライスへの接続が拒絶されることなく、ＵＥ２はサービス提供を受けることができる可能性が高くなる。

また、本実施形態のスライス管理システム１によれば、ＵＥ２が接続するスライスが、当該ＵＥ２のユーザに対応付けられた接続先候補のスライスに基づいて決定されるため、例えば、ＵＥ２のユーザ毎の要求に沿ったスライスにＵＥ２を接続することができる。それにより、より適切なスライスにＵＥ２を接続することができる。

また、本実施形態のスライス管理システム１によれば、ＵＥ２が接続するスライスが、当該ＵＥ２が要求するサービスに対応付けられた接続先候補のスライスに基づいて決定されるため、例えば、ＵＥ２が要求するサービスに沿ったスライスにＵＥ２を接続することができる。それにより、より適切なスライスにＵＥ２を接続することができる。

また、本実施形態のスライス管理システム１によれば、優先度リストに含まれる接続先候補のスライスにおいてローミング先のスライスが含まれることで、ローミング先のスライスも接続候補として決定することができるため、ＵＥ２の接続候補であるスライスの選択肢が増える。それにより、ＵＥ２のスライスへの接続が拒絶されることなく、ＵＥ２はサービス提供を受けることができる可能性が高くなる。

また、本実施形態のスライス管理システム１によれば、管理するスライスの運用状況、ＵＥ２が要求するサービスのサービス要求条件、管理するスライスのサービス要求条件、ＵＥ２のユーザの契約情報のうち少なくとも一つに基づいて、動的かつ柔軟に優先度リストを更新することができる。それにより、より適切なスライスにＵＥ２を接続することができる。

また、本実施形態のスライス管理システム１によれば、ＵＥ２によるスライスへの接続要求を取得した場合に、ＵＥ２が移動する先である移動先エリアにて、移動元エリアで接続していたスライスに接続できるか否かが判定され、接続できないと判定された場合に、優先度リストに基づいて１以上の接続先候補のスライスが選択され、選択されたスライスの中から優先度順に基づいてＵＥ２が接続するスライスが決定される。これにより、ＵＥ２が、移動先エリアにて、移動元エリアで接続していたスライスに接続できない場合でも、ＵＥ２が接続するスライスがより確実に決定されるため、ＵＥ２をより確実にスライスに接続することができる。

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

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

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

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

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

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

本開示の全体において、単数形は、文脈から明らかにそうでないことが示されていなければ、複数のものを含むものとする。従って、例えば、「装置」について述べる場合は、単数の装置と共に複数のそのような装置であるケースをも包含する。

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

１…スライス管理システム、２…ＵＥ、３…ＢＳ、４…ＳＳＦ、５…ＤＮＳ、６…ＳＭＦ、７…ＭＡＮＯ、４０…スライス接続依頼取得部、４１…スライス接続判定部、４２…優先度リスト格納部、４３…スライス切替部、６０…優先度リスト更新部、７０…ＮＦＶＯ、７１…ＶＮＦＭ、７２…ＶＩＭ。

Claims (7)

1. ネットワークインフラ上に生成される仮想ネットワークであるスライスを管理するスライス管理システムであって、
   端末の接続先候補のスライスが優先度順に並んだ優先度リストを格納するメモリを備え、
   当該スライス管理システムは、
   前記端末によるスライスへの接続要求を取得した場合に、前記端末が移動する先である移動先エリアにて、移動元エリアで接続していたスライスに接続できるか否かを判定し、
   接続できないと判定された場合に、前記メモリに格納された前記優先度リストに基づいて１以上の接続先候補のスライスを選択し、選択したスライスの中から前記優先度順に基づいて前記端末が接続するスライスを決定する、
   スライス管理システム。
2. 前記優先度リストに含まれる接続先候補のスライスは、前記端末のユーザ毎に対応付けられており、
   当該スライス管理システムは、
   前記優先度リストのうち、当該端末のユーザに対応付けられた接続先候補のスライスに基づいて当該端末が接続するスライスを決定する、
   請求項１に記載のスライス管理システム。
3. 前記優先度リストに含まれる接続先候補のスライスは、前記端末が要求するサービス毎に対応付けられており、
   当該スライス管理システムは、
   前記優先度リストのうち、当該端末が要求するサービスに対応付けられた接続先候補のスライスに基づいて当該端末が接続するスライスを決定する、
   請求項１又は２に記載のスライス管理システム。
4. 前記優先度リストに含まれる接続先候補のスライスは、ローミング先のスライスを含む、
   請求項１〜３の何れか一項に記載のスライス管理システム。
5. 管理するスライスの運用状況、前記端末が要求するサービスのサービス要求条件、管理するスライスのサービス要求条件、前記端末のユーザの契約情報のうち少なくとも一つに基づいて前記優先度リストを更新する、
   請求項１〜４の何れか一項に記載のスライス管理システム。
6. ネットワークインフラ上に生成される仮想ネットワークであるスライスを管理するスライス管理システムにより実行されるスライス管理方法であって、
   端末によるスライスへの接続要求を取得した場合に、前記端末が移動する先である移動先エリアにて、移動元エリアで接続していたスライスに接続できるか否かを判定する判定ステップと、
   前記判定ステップにおいて接続できないと判定された場合に、メモリに格納された、前記端末の接続先候補のスライスが優先度順に並んだ優先度リストに基づいて１以上の接続先候補のスライスを選択し、選択したスライスの中から前記優先度順に基づいて前記端末が接続するスライスを決定する決定ステップと、
   を含むスライス管理方法。
7. 前記優先度リストに含まれる接続先候補のスライスは、前記端末が要求するサービス毎に対応付けられており、
   前記決定ステップは、前記優先度リストのうち、当該端末が要求するサービスに対応付けられた接続先候補のスライスに基づいて当該端末が接続するスライスを決定する、
   請求項７に記載のスライス管理方法。

Images