JP7030055B2 - 通信制御装置及び通信制御方法 - Google Patents

Description

本発明は、通信制御装置及び通信制御方法に関する。

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

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

ところで、ユーザ端末によって各々のスライスに割り当てられたサービスを利用しながら、何らかの事情により当該ユーザ端末に係る通信路を変更する必要が生じる場合がある。特に、複数のスライスに対してこのユーザ端末がアクセスしてユーザデータを送受信している場合に、サービスを利用しながら通信路を変更することについては、従来は検討されていなかった。

本発明は上記を鑑みてなされたものであり、複数のスライスに割り当てられているサービスを利用しながら、複数のスライスとの間に設けられる通信路を変更することが可能な通信制御装置及び通信制御方法を提供することを目的とする。

上記目的を達成するため、本発明の一形態に係る通信制御装置は、ネットワークインフラ上に生成される仮想化ネットワークである一又は複数のスライスにおける制御ノードに対してそれぞれ通信路を設け、前記通信路を介してユーザデータを送受信するユーザ端末に係る通信制御を行う通信制御装置であって、前記ユーザ端末に係る前記通信路の変更に係る変更要求を取得する変更要求取得部と、前記変更要求取得部が取得した前記変更要求に含まれる情報により、当該変更要求に係る前記ユーザ端末が、複数の前記スライスにおける前記制御ノードに対してそれぞれ前記通信路を設けているか否かを判定する判定部と、前記判定部により、前記変更要求に係る前記ユーザ端末が複数の前記スライスに対してそれぞれ前記通信路を設けていると判定された場合に、複数の前記スライスにおける前記制御ノードに対して設けられた複数の前記通信路それぞれについて、変更前の前記通信路と変更後の前記通信路とが両立した状態を設けながら、前記通信路の変更に係る処理を行う通信処理部と、を有する。

また、本発明の一形態に係る通信制御方法は、ネットワークインフラ上に生成される仮想化ネットワークである一又は複数のスライスにおける制御ノードに対してそれぞれ通信路を設け、前記通信路を介してユーザデータを送受信するユーザ端末に係る通信制御を行う通信制御装置による通信制御方法であって、前記ユーザ端末に係る前記通信路の変更に係る変更要求を取得する変更要求取得ステップと、前記変更要求取得ステップにおいて取得された前記変更要求に含まれる情報から、当該変更要求に係る前記ユーザ端末が複数の前記スライスに対してそれぞれ前記通信路を設けていると判定される場合に、複数の前記スライスにおける前記制御ノードに対して設けられた複数の前記通信路それぞれについて、変更前の前記通信路と変更後の前記通信路とが両立した状態を設けながら、前記通信路の変更に係る処理を行う通信処理ステップと、を有する。

上記の通信制御装置及び通信制御方法によれば、通信制御装置に対して送信された変更要求に係るユーザ端末が複数のスライスにおける制御ノードに対してそれぞれ通信路を設けている場合に、複数の通信路それぞれについて、変更前の通信路と変更後の通信路とが両立した状態を設けながら、通信路の変更に係る処理が行われる。このため、ユーザ端末は、変更前の通信路もしくは変更後の通信路を利用してユーザデータを送受信可能な状態を保つことができることから、複数のスライスに割り当てられているサービスを利用しながら、複数のスライスとの間に設けられる通信路を変更することが実現される。

本発明によれば、複数のスライスに割り当てられているサービスを利用しながら、複数のスライスとの間に設けられる通信路を変更することが可能な通信制御装置及び通信制御方法が提供される。

本発明の実施形態に係るシステムの構成を示す図である。 スライスとコアネットワークとの関係を示す図である。 スライスとハードとの関係を示す図である。 本発明の実施形態での技術課題を説明する図である。 通信制御装置に係る機能ブロックを示す図である。 通信制御装置に係るハードウェア構成を示す図である。 第１のケースに係る状況を説明する図である。 第１のケースに係る処理を説明するシーケンス図である。 第２のケースに係る状況を説明する図である。 第２のケースに係る処理を説明するシーケンス図である。 第３のケースに係る状況を説明する図である。 第３のケースに係る処理を説明するシーケンス図である。 ＤＮＳサーバ及びＳＳＦが保持する情報の例を示す図である。 第４のケースに係る状況を説明する図である。 第４のケースに係る処理を説明するシーケンス図である。 第２実施形態に係るスライスとコアネットワークとの関係を説明する図である。 第１のケースに係る状況を説明する図である。 第１のケースに係る処理を説明するシーケンス図である。 第２のケースに係る状況を説明する図である。 第２のケースに係る処理を説明するシーケンス図である。 第３のケースに係る状況を説明する図である。 第３のケースに係る処理を説明するシーケンス図である。 第４のケースに係る状況を説明する図である。 第４のケースに係る処理を説明するシーケンス図である。

以下、添付図面を参照して、本発明を実施するための形態を詳細に説明する。なお、図面の説明においては同一要素には同一符号を付し、重複する説明を省略する。

（第１実施形態：共通Ｃ－Ｐｌａｎｅ制御ノードを有するシステム）
図１では、仮想化されたネットワークを構成するシステム（通信システム）１の構成を示している。図１のシステム１は、仮想化ネットワークであるスライスに対してサービスを割り当てることで、サービスユーザ（Service User）の使用する端末（ユーザ端末）であるＵＥ（User Equipment）９０に対してネットワークサービスを提供する。スライスとは、ネットワーク装置のリンクとノードの資源を仮想的に切り分けて、切り分けた資源を結合し、ネットワークインフラ上に論理的に生成される仮想化ネットワーク又はサービス網であり、スライス同士は資源を分離しており、互いに干渉しない。ネットワークサービスとは、通信サービス（専用線サービス等）やアプリケーションサービス（動画配信、エンベデッド装置等のセンサ装置を利用したサービス）等のネットワーク資源を用いたサービスをいう。また、ＵＥ９０は、例えば、スマートフォン等の通信機能を有する端末装置である。

図１に示すようにシステム１は、ＢＳＳ／ＯＳＳ（Business Support System / Operations Support System）１０と、ＳＯ（Service Operator）２０と、ＮＦＶＯ３０と、ＶＮＦＭ４０と、ＶＩＭ（Virtualized Infrastructure Management：仮想化基盤管理）５０とを含んで構成されている。また、システム１には、ＮＦＶＩ（ＮＦＶ（Network Functions Virtualisation） Infrastructure）６０と、ＳＳＦ（Slice Selection Function）７０とｅＮＢ（eNodeB）８０とＵＥ９０とを含んで構成されている。このうち、ＮＦＶＯ３０とＶＮＦＭ４０とＶＩＭ５０は、ＥＴＳＩ ＮＦＶ－ＩＳＧで仕様化されているＭＡＮＯ（Management & Orchestration）architectureの機能である。

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

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

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

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

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

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

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

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

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

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

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

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

具体的にＮＦＶＯ３０では、図２に示すように、第１のサービス（サービスＳ１）用のスライスであるスライスＳＬ１（第１のスライス）、第２のサービス（サービスＳ２）用のスライスであるスライスＳＬ２（第２のスライス）、及び、スライスＳＬ１又はスライスＳＬ２の制御に係る制御装置としての機能を有するスライスであるスライスＳＬ３（第３のスライス）を生成する。ＮＦＶＯ３０は、スライスＳＬ１に対してサービスＳ１を割り当て、スライスＳＬ２に対してサービスＳ２を割り当てる。サービスＳ１及びサービスＳ２を実行する機能は、スライスＳＬ３から送られる信号等に基づいて処理を行ったり、必要に応じて後述の通信制御装置としての機能を有するノードが設けられるスライスＳＬ３に対して情報の提供を要求する処理を行ったりする。

このように、システム１では、スライスＳＬ１、スライスＳＬ２およびスライスＳＬ３が、互いに論理的に通信可能に構築される。

なお、本実施形態では、サービスＳ１を提供するスライスＳＬ１には、第１Ｃ－Ｐｌａｎｅ制御ノード（ＣＰ１）２１１及び第１Ｕ－Ｐｌａｎｅ制御ノード（ＵＰ１）２１２が含まれる。第１Ｃ－Ｐｌａｎｅ制御ノード２１１は、ユーザに対してサービスＳ１を提供する際の通信路の開設及び切断に係る制御信号等の送受信を行う。また、第１Ｕ－Ｐｌａｎｅ制御ノード２１２は、ユーザに対してサービスＳ１を提供する際に通信路を設けると共に、サービスを提供するサービスサーバ１０１とも通信路を設けて、ユーザデータの送受信を実行する。また、サービスＳ２を提供するスライスＳＬ２には、第２Ｃ－Ｐｌａｎｅ制御ノード（ＣＰＸ１）２２１及び第２Ｕ－Ｐｌａｎｅ制御ノード（ＵＰＸ１）２２２が含まれる。第２Ｃ－Ｐｌａｎｅ制御ノード２２１は、ユーザに対してサービスＳ２を提供する際の通信路の開設及び切断に係る制御信号等の送受信を行う。また、第２Ｕ－Ｐｌａｎｅ制御ノード２２２は、ユーザに対してサービスＳ２を提供する際に通信路を設けると共に、サービスを提供するサービスサーバ１０２とも通信路を設けて、ユーザデータの送受信を実行する。上記のスライスとサービスとの対応関係は、一例であり、適宜変更することができる。すなわち、複数のサービスを提供するためのノードが１つのスライスに割り当てられていてもよい。

なお、図面等においては、「ＣＰ１、ＵＰ１」と「ＣＰＸ１、ＵＰＸ１」とを区別して示している場合がある。この「ＣＰ」と「ＣＰＸ」との表記の違いは、これらのノードがどのサービスに適用されるノードであるかを示しているものである。すなわち、ＣＰ１等はサービスＳ１に適用されるノードであり、ＣＰＸ１等はサービスＳ２に適用されるノードであることを模式的に示している。また、「ＣＰＹ、ＵＰＹ」と記載されるノードも存在する。このノードは、元来サービスＳ１又はサービスＳ２に対して適用することを想定していなかったノードを模式的に示したものである。

図２のスライスＳＬ３には共通Ｃ－Ｐｌａｎｅ制御ノード（Ｃｏｍｍｏｎ ＣＰ）３０１が含まれる。共通Ｃ－Ｐｌａｎｅ制御ノード３０１は、サービスＳ１の第１Ｃ－Ｐｌａｎｅ制御ノード２１１、及び、サービスＳ２の第２Ｃ－Ｐｌａｎｅ制御ノード２２１等を管轄する機能を有し、ユーザ側からの指示に基づいて、ユーザと各スライスとの通信路の開設及び切断に係る処理を実行する。

なお、共通Ｃ－Ｐｌａｎｅ制御ノード３０１は、スライスＳＬ３に機能を割り当てて実現することに代えて、ハードウェアを有する装置によって実現されていてもよい。この場合、ＮＦＶＯ３０により生成されるスライスは、スライスＳＬ１，ＳＬ２となる。

図３に、各スライスとサーバとの対応関係の例を示す。図３に示すように、ノードはサーバの一部であり、スライス１（スライスＳＬ１）の第１Ｃ－Ｐｌａｎｅ制御ノード２１１の機能及びスライス２（スライスＳＬ２）の第２Ｃ－Ｐｌａｎｅ制御ノード２２１の機能は、サーバ１（１１０Ａ）及びスイッチ、ルータ等により実現される。また、スライス１（スライスＳＬ１）の第１Ｕ－Ｐｌａｎｅ制御ノード２１２の機能及びスライス２（スライスＳＬ２）の第２Ｕ－Ｐｌａｎｅ制御ノード２２２の機能は、サーバ２（１１０Ｂ）及びスイッチ、ルータ等により実現される。なお、図３では、スライス３の共通Ｃ－Ｐｌａｎｅ制御ノード３０１に関しては記載を省略するが、上記の各ノードと同様に、サーバ、スイッチ及びルータ等により実現される。

ＮＦＶＯ３０がスライスへネットワークサービスを割り当てた後、ＮＦＶＯ３０は、当該ネットワークサービスのＩＤと、当該ネットワークサービスの最初の機能を提供する論理ノードの宛先（例えば、ＩＰアドレス）とを含むアクセス情報をＢＳＳ／ＯＳＳ１０へ送信する。

ＢＳＳ／ＯＳＳ１０は、当該アドレス情報を受信すると、各ＳＳＦ７０へ当該アドレス情報を通知する。ＳＳＦ７０は、基地局装置であるｅＮｏｄｅＢ（ｅＮＢ）８０と互いに通信可能なサーバ装置であり、サービスユーザであるＵＥ９０からネットワークサービスＩＤと共に、サービス要求がｅＮＢ８０へなされると、当該ｅＮＢ８０からＳＳＦ７０に対してＵＥ９０から受信したネットワークサービスＩＤを通知する。なお、ＳＳＦ７０は、ｅＮＢ８０と一体として実現されていてもよいし、ＭＭＥ（Mobility Management Entity）等の他の装置と一体として実現されていてもよい。

ＳＳＦ７０は、ｅＮＢ８０からネットワークサービスＩＤを受信すると、ＳＳＦ７０が記憶するアドレス情報のうち、ｅＮＢ８０から受信したネットワークサービスＩＤに対応するアドレス情報のネットワークサービスの最初の機能を提供する論理ノードの宛先情報をｅＮＢ８０へ送信する。ｅＮＢ８０は、当該宛先情報をＵＥ９０へ通知する。これにより、ＵＥ９０は、ネットワークサービスを利用するために最初にアクセスする宛先を特定することができる。

上記のように、ＳＳＦ７０は、ネットワークサービスの機能を提供する論理ノードの情報を保持している。換言すると、ＳＳＦ７０は、論理ノード毎に対応可能なサービスを特定する情報を保持している。詳細は後述するが、他の論理ノードからの問い合わせに基づいて、ＳＳＦ７０は、この情報を提供する機能を有する。

ここで、図２及び図４を参照しながら、本実施形態に係るシステム１により生成されるスライスの各ノード及びその他の装置により構成されるコアネットワークＮ１における技術課題を説明する。このコアネットワークＮ１とは、ＵＥ９０が通信を行ってサービスを利用する際のコアネットワークを指している。

図２に示すように、システム１において構築されるスライスを含むコアネットワークＮ１においては、ＵＥ９０は、ｅＮＢ８０、及び、スライスＳＬ１に設けられたサービスＳ１に係る第１Ｕ－Ｐｌａｎｅ制御ノード２１２を経由して、サービスサーバ１０１との間で通信を行うことで、サービスサーバ１０１の提供するサービスＳ１を利用することができる。この際、ｅＮＢ８０と第１Ｕ－Ｐｌａｎｅ制御ノード２１２との間には、ＵＥ９０に係るユーザデータを送受信するための通信路が設けられる。すなわち、第１Ｕ－Ｐｌａｎｅ制御ノード２１２がスライスＳＬ１における制御ノードとして機能する。また、ｅＮＢ８０と第１Ｕ－Ｐｌａｎｅ制御ノード２１２との間の通信路の開設及び切断に係る処理を行うための制御信号は、共通Ｃ－Ｐｌａｎｅ制御ノード３０１及び第１Ｃ－Ｐｌａｎｅ制御ノード２１１を経由して送受信が行われる。

また、ＵＥ９０は、ｅＮＢ８０、及び、スライスＳＬ２に設けられたサービスＳ２に係る第２Ｕ－Ｐｌａｎｅ制御ノード２２２を経由して、サービスサーバ１０２との間で通信を行うことで、サービスサーバ１０２の提供するサービスＳ２を利用することができる。この際、ｅＮＢ８０と第２Ｕ－Ｐｌａｎｅ制御ノード２２２との間には、ＵＥ９０に係るユーザデータを送受信するための通信路が設けられる。すなわち、第２Ｕ－Ｐｌａｎｅ制御ノード２２２がスライスＳＬ２における制御ノードとして機能する。また、このｅＮＢ８０と第２Ｕ－Ｐｌａｎｅ制御ノード２２２との間の通信路の開設及び切断に係る処理を行うための制御信号は、共通Ｃ－Ｐｌａｎｅ制御ノード３０１及び第２Ｃ－Ｐｌａｎｅ制御ノード２２１を経由して送受信が行われる。

このように、本実施形態においては、ＵＥ９０が在圏するエリアのｅＮＢ８０と２つのスライスＳＬ１，ＳＬ２との間で通信路を設けることで、ＵＥ９０はスライスＳＬ１，ＳＬ２を利用した通信が可能な状態となっている。

ここで、図４に示すように、ＵＥ９０が何らかの事情により、サービスを利用するために通信を行っているスライスの変更、もしくは、スライスとＵＥ９０との間の通信路の変更を行う必要が生じたとする。ＵＥ９０が上記の変更を行う可能性はいくつか考えられるが、ＵＥ９０に係るコンテキスト情報の変更（例えば、所属する基地局やセクタの変化、乗り物への乗車等による移動速度の変化、建造物への侵入、周囲の混雑情報等）に伴って通信路もしくは通信路を設ける相手方のスライスを変更することが必要となる可能性がある。例えば、ＵＥ９０が通信エリアを跨ぐ移動を行う、すなわち、位置情報を変更することにより、ＵＥ９０がアクセスするｅＮＢを変更すると、移動前のｅＮＢとスライスとの間に設けていた通信路を変更する必要が生じる。また、ＵＥ９０が複数のサービスを利用している場合には、ＵＥ９０はｅＮＢを介して複数のスライスにおける制御ノードとの間で通信路を設けることがあるが、ＵＥ９０に係るコンテキスト情報の変更に伴って、これを１つのスライスにまとめることも考えられる。この場合にも、通信路を改めて設けることが必要となる場合がある。

図４では、ＵＥ９０がサービス提供エリアを跨ぐ移動をした場合の例を示している。図４に示す例では、２つのエリアが示されている。エリア（ＳＡ：Service Area）＃１は、ｅＮＢ８１が管轄するエリアであり、エリア（ＳＡ）＃２は、ｅＮＢ８２が管轄するエリアである。ＳＡ＃１において、ＵＥ９０は、スライスＳＬ１，ＳＬ２との間に通信路を設けてサービスＳ１，Ｓ２を利用することができる。また、ＳＡ＃２において、ＵＥ９０は、スライスＳＬ４，ＳＬ５との間に通信路を設けてサービスＳ１，Ｓ２を利用することができる。図４では、上記のＳＡ＃１からＳＡ＃２へＵＥ９０が移動する場合を示している。

スライスＳＬ４には、第４Ｃ－Ｐｌａｎｅ制御ノード３４１（ＣＰ２）及び第４Ｕ－Ｐｌａｎｅ制御ノード３４２（ＵＰ２）に係る機能が設けられる。第４Ｕ－Ｐｌａｎｅ制御ノード３４２は、サービスＳ１を提供するサービスサーバ１０１との間で通信路を設けることができるとする。また、スライスＳＬ５には、第５Ｃ－Ｐｌａｎｅ制御ノード３５１（ＣＰＸ２）及び第５Ｕ－Ｐｌａｎｅ制御ノード３５２（ＵＰＸ２）に係る機能が設けられる。第５Ｕ－Ｐｌａｎｅ制御ノード３５２は、サービスＳ２を提供するサービスサーバ１０２との間で通信路を設けることができるとする。

ＵＥ９０がＳＡ＃１に在圏している際は、ＵＥ９０がサービスＳ１の提供を受けるため、ｅＮＢ８１とスライスＳＬ１の第１Ｕ－Ｐｌａｎｅ制御ノード２１２との間でＵＥ９０に係る通信路が設けられる。また、ＵＥ９０がサービスＳ２の提供を受けるため、ｅＮＢ８１とスライスＳＬ２の第１Ｕ－Ｐｌａｎｅ制御ノード２２２との間でＵＥ９０に係る通信路が設けられる。

ここで、ＵＥ９０がＳＡ＃１からＳＡ＃２に移動すると、ＵＥ９０がアクセスする基地局装置はｅＮＢ８２となる。そして、図４に示す例では、ＵＥ９０がサービスＳ１の提供を受けるためには、ｅＮＢ８２とスライスＳＬ４の第４Ｕ－Ｐｌａｎｅ制御ノード２４２との間で通信路を設ける必要がある。また、ＵＥ９０がサービスＳ２の提供を受けるためには、ｅＮＢ８２とスライスＳＬ５の第５Ｕ－Ｐｌａｎｅ制御ノード２５２との間で通信路を設ける必要がある。なお、共通Ｃ－Ｐｌａｎｅ制御ノード３０１は、両方のエリア（ＳＡ＃１，ＳＡ＃２）のＣ－Ｐｌａｎｅ制御ノード２１１，２２１，２４１，２５１を管轄する機能を有し、ユーザ側からの指示に基づいて、ユーザと各スライスとの通信路の開設及び切断に係る処理を実行するとする。

図４に示すように、ＵＥ９０がエリアを移動した後も移動前と同一のサービスを受けるためには、ユーザデータを送受信するための通信路を設ける対象のスライスを変更する必要がある場合がある。また、スライスＳＬ１，ＳＬ２にアクセスすることでサービスを利用することができる場合であっても、ＵＥ９０のエリア内の移動に伴ってＵＥ９０に係る通信の制御を行うｅＮＢが変更となるため、通信路を改めて設ける必要がある。

本実施形態では、このように、ＵＥ９０が複数のスライスとの間で通信を行っている際に、何らかの事情により、ＵＥ９０がサービスを利用するために通信を行っているスライスの変更、もしくは、複数のスライスとＵＥ９０との間にそれぞれ設けられる通信路の変更を行う必要が生じた場合の処理を説明する。以下の実施形態で説明する処理は、ＵＥ９０がサービスを利用する状態を継続しながら、通信路を変更することを特徴とする。ＵＥ９０がサービスを利用する状態を継続しながら、とは、通信路がConnected Modeであることを継続しながら、という意味である。これを実現するためには、複数のスライスの制御ノードに対して設けられる通信路それぞれについて、変更前の通信路と、変更後の通信路とが両立した状態を設けながら、通信路の変更に係る処理を行う。

上記の処理は、共通Ｃ－Ｐｌａｎｅ制御ノード３０１が主体的に実行する。すなわち、共通Ｃ－Ｐｌａｎｅ制御ノード３０１が、複数のスライスの制御ノードに対して設けられるＵＥ９０に係る通信路の制御を行う通信制御装置として機能する。そのため、共通Ｃ－Ｐｌａｎｅ制御ノード３０１は、図５に示すように、変更要求取得部３１０と、判定部３２０と、通信処理部３３０と、を有する。

変更要求取得部３１０は、スライスＳＬ１等との通信路の変更に係る要求を取得する機能を有する。ＵＥ９０の移動に伴いＵＥ９０に係る通信路を変更する場合には、この通信路の変更に係る要求は、ＵＥ９０がアクセスするｅＮＢから送信される。また、他のコンテキスト情報の変更に伴って通信路を変更する場合には、通信路の変更に係る要求はｅＮＢとは異なる装置から送信される場合がある。通信路の変更に係る要求を送信するｅＮＢとは異なる装置としては、例えば、ＵＥ９０、又は、ＵＥ９０に係るコンテキスト情報を収集する機能を有するＳＳＦ７０等が考えられる。変更要求取得部３１０が通信路の変更に係る要求を取得すると、当該要求に含まれる情報は、判定部３２０へ送られる。

判定部３２０は、通信路の変更に係る要求の対象のＵＥ９０に係る通信路が、複数のスライスに対して設けられているかを判定する機能を有する。判定部３２０では、通信路の変更に係る要求に含まれる情報に基づいて、上記の判定を行う。また、判定部３２０における判定結果に基づいて、通信処理部３３０による処理が行われる。

通信処理部３３０は、通信路の変更に係る要求に基づいて、ＵＥ９０がサービスを利用しながら通信路の変更が行えるように、通信路の変更に係る処理を行う。通信処理部３３０による処理の詳細については後述する。

図６は、本実施形態に係る処理を実行する各ノードの機能を実現するサーバ（例えば、共通Ｃ－Ｐｌａｎｅ制御ノード３０１を構成するサーバ等）のハードウェア構成の一例を示す図である。上述のサーバは、物理的には、プロセッサ１００１、メモリ１００２、ストレージ１００３、通信装置１００４、入力装置１００５、出力装置１００６、バス１００７などを含むコンピュータ装置として構成されてもよい。

なお、以下の説明では、「装置」という文言は、回路、デバイス、ユニットなどに読み替えることができる。上記のサーバのハードウェア構成は、図に示した各装置を１つ又は複数含むように構成されてもよいし、一部の装置を含まずに構成されてもよい。

サーバにおける各機能は、プロセッサ１００１、メモリ１００２などのハードウェア上に所定のソフトウェア（プログラム）を読み込ませることで、プロセッサ１００１が演算を行い、通信装置１００４による通信や、メモリ１００２及びストレージ１００３におけるデータの読み出し及び／又は書き込みを制御することで実現される。

プロセッサ１００１は、例えば、オペレーティングシステムを動作させてコンピュータ全体を制御する。プロセッサ１００１は、周辺装置とのインターフェース、制御装置、演算装置、レジスタなどを含む中央処理装置（ＣＰＵ：Central Processing Unit）で構成されてもよい。例えば、上述の共通Ｃ－Ｐｌａｎｅ制御ノード３０１における通信処理部３３０などは、プロセッサ１００１で実現されてもよい。

また、プロセッサ１００１は、プログラム（プログラムコード）、ソフトウェアモジュールやデータを、ストレージ１００３及び／又は通信装置１００４からメモリ１００２に読み出し、これらに従って各種の処理を実行する。プログラムとしては、上述の実施の形態で説明した動作の少なくとも一部をコンピュータに実行させるプログラムが用いられる。例えば、上述の通信処理部３３０は、メモリ１００２に格納され、プロセッサ１００１で動作する制御プログラムによって実現されてもよく、他の機能ブロックについても同様に実現されてもよい。上述の各種処理は、１つのプロセッサ１００１で実行される旨を説明してきたが、２以上のプロセッサ１００１により同時又は逐次に実行されてもよい。プロセッサ１００１は、１以上のチップで実装されてもよい。なお、プログラムは、電気通信回線を介してネットワークから送信されても良い。

メモリ１００２は、コンピュータ読み取り可能な記録媒体であり、例えば、ＲＯＭ（Read Only Memory）、ＥＰＲＯＭ（Erasable Programmable ＲＯＭ）、ＥＥＰＲＯＭ（Electrically Erasable Programmable ＲＯＭ）、ＲＡＭ（Random Access Memory）などの少なくとも１つで構成されてもよい。メモリ１００２は、レジスタ、キャッシュ、メインメモリ（主記憶装置）などと呼ばれてもよい。メモリ１００２は、本発明の一実施の形態に係る無線通信方法を実施するために実行可能なプログラム（プログラムコード）、ソフトウェアモジュールなどを保存することができる。

ストレージ１００３は、コンピュータ読み取り可能な記録媒体であり、例えば、ＣＤ－ＲＯＭ（Compact Disc ＲＯＭ）などの光ディスク、ハードディスクドライブ、フレキシブルディスク、光磁気ディスク(例えば、コンパクトディスク、デジタル多用途ディスク、Ｂｌｕ－ｒａｙ（登録商標）ディスク)、スマートカード、フラッシュメモリ(例えば、カード、スティック、キードライブ)、フロッピー（登録商標）ディスク、磁気ストリップなどの少なくとも１つで構成されてもよい。ストレージ１００３は、補助記憶装置と呼ばれてもよい。上述の記憶媒体は、例えば、メモリ１００２及び／又はストレージ１００３を含むデータベース、サーバその他の適切な媒体であってもよい。

通信装置１００４は、有線及び／又は無線ネットワークを介してコンピュータ間の通信を行うためのハードウェア（送受信デバイス）であり、例えばネットワークデバイス、ネットワークコントローラ、ネットワークカード、通信モジュールなどともいう。例えば、上述の変更要求取得部３１０，通信処理部３３０などは、通信装置１００４で実現されてもよい。

入力装置１００５は、外部からの入力を受け付ける入力デバイス（例えば、キーボード、マウス、マイクロフォン、スイッチ、ボタン、センサなど）である。出力装置１００６は、外部への出力を実施する出力デバイス（例えば、ディスプレイ、スピーカー、ＬＥＤランプなど）である。なお、入力装置１００５及び出力装置１００６は、一体となった構成（例えば、タッチパネル）であってもよい。

また、プロセッサ１００１やメモリ１００２などの各装置は、情報を通信するためのバス１００７で接続される。バス１００７は、単一のバスで構成されてもよいし、装置間で異なるバスで構成されてもよい。

また、共通Ｃ－Ｐｌａｎｅ制御ノード３０１は、マイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ：Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＰＬＤ（Programmable Logic Device）、ＦＰＧＡ（Field Programmable Gate Array）などのハードウェアを含んで構成されてもよく、当該ハードウェアにより、各機能ブロックの一部又は全てが実現されてもよい。例えば、プロセッサ１００１は、これらのハードウェアの少なくとも１つで実装されてもよい。

次に、共通Ｃ－Ｐｌａｎｅ制御ノード３０１を含むシステム１におけるＵＥ９０に係る通信路の変更の具体的な処理（通信制御方法）について説明する。ＵＥ９０が複数のサービスを利用しながらその通信路を変更する場合、上述したように、変更前の通信路と変更後の通信路とが両立する状態を設けながら、通信路の変更に係る処理を行う。

前提として、２つのスライスに対してＵＥ９０に係る通信路が設けられているとする。この場合、変更前の通信路と変更後の通信路をどのように設けるかについては、具体的には、４つのケースが考えられる。第１に、通信路を設けるスライスは変更せずに通信路のみを変更するケース、第２に、変更前とは異なるスライスであって、２つのサービスをそれぞれ個別に提供可能な２つのスライスに対してそれぞれ通信路を設けるケース、第３に、変更前とは異なる１つのスライスに対して通信路を設けるケースであってＤＮＳサーバが対応可能なスライスの情報を保持している場合、第４に、変更前とは異なる１つのスライスに対して通信路を設けるケースであってＤＮＳサーバが対応可能なスライスの情報を保持していない場合、である。以下、この４つのケースについて、それぞれ状況を説明すると共に、具体的な処理についてシーケンス図を参照しながら説明する。

（第１：通信路のみを変更するケース）
図７は、第１のケースの状況を説明する図である。図７に示すケースは、例えば、ＵＥ９０がスライスＳＬ１，ＳＬ２との間で通信を行うことでＵＥ９０がサービスＳ１，Ｓ２を利用することができるエリアＳＡ＃１内で移動をする場合である。この場合、ＵＥ９０が通信をする際の基地局装置は、ハンドオーバによりｅＮＢ８１からｅＮＢ８２へ変更されるが、引き続きスライスＳＬ１，ＳＬ２との通信を行ってサービスＳ１，Ｓ２を利用することができる。したがって、移動前のｅＮＢ８１と第１Ｕ－Ｐｌａｎｅ制御ノード２１２との通信路をｅＮＢ８２と第１Ｕ－Ｐｌａｎｅ制御ノード２１２との通信路に切り替えると共に、移動前のｅＮＢ８１と第２Ｕ－Ｐｌａｎｅ制御ノード２２２との通信路をｅＮＢ８２と第２Ｕ－Ｐｌａｎｅ制御ノード２２２との通信路に切り替えることで、サービスＳ１，Ｓ２を継続して利用することができる。

このようなケースにおける具体的な処理の手順について、図８を参照しながら説明する。

まず、ＵＥ９０の移動前のｅＮＢ８１と移動先のｅＮＢ８２との間でハンドオーバに係る信号の送受信が行われる（HO Request, HO Request ACK：Ｓ１０１）。この信号を契機として、ＵＥ９０，ｅＮＢ８１，ｅＮＢ８２の間でハンドオーバに係る処理が行われる（Handover Execution：Ｓ１０２）。

この後、移動先のｅＮＢ８２から、共通Ｃ－Ｐｌａｎｅ制御ノード３０１に対して、通信路の変更に係る要求を行う信号が送信される（Path Switch Request：Ｓ１０３：変更要求取得ステップ）。なお、ここでは、ＵＥ９０がハンドオーバを行う場合について説明しているので、通信路の変更に係る要求を行う信号は”Path Switch Request”であるが、通信路の変更に係る要求を行う信号は、通信路を変更する事情に応じて適宜変更される。これは、他のケースでも同様である。

通信路の変更に係る要求には、ＵＥ９０を特定する情報と、通信路を特定する情報（TU-1,TU-2）及びセッションを特定する情報（S-ID1, S-ID2）が含まれる。なお、セッションを特定する情報（S-ID：Session ID）に代えて、無線アクセスベアラのＩＤ（E-RAB ID：E-UTRAN Radio Access Bearer ID）を用いてもよい。この点は後述の他の実施形態及び他のケースでも同様である。共通Ｃ－Ｐｌａｎｅ制御ノード３０１の変更要求取得部３１０において、ｅＮＢ８２からの要求を受信すると、判定部３２０では、通信路の変更に係る要求に基づいて、ＵＥ９０が２つのスライスとの間で通信路を設けているか否かを判定する（Ｓ１０４：判定ステップ）。本実施形態では、通信路の変更に係る要求に、通信路を特定する情報が複数含まれていて、セッションを特定する情報が複数含まれていると、判定部３２０では、ＵＥ９０に関して２つの通信路が個別に設けられていることを判断することができる。このように、通信路の変更に係る要求に含まれる情報により、判定部３２０では、複数の通信路が設けられているか否かの判定を行う。そして、判定部３２０において、ＵＥ９０に関して複数の通信路が設けられていると判定された場合には、図８に示す以下の処理を行う。なお、判定部３２０において、ＵＥ９０に関して複数の通信路が設けられていない、すなわち、ＵＥ９０に関して、１つのスライスとの間にのみ通信路が設けられている、もしくは、通信路が設けられていないと判定された場合には、公知のハンドオーバに係る処理が行われる。

判定部３２０において、ＵＥ９０に関して複数の通信路が設けられていると判定した場合、共通Ｃ－Ｐｌａｎｅ制御ノード３０１の通信処理部３３０は、セッションを特定する情報等に基づいて、第１Ｃ－Ｐｌａｎｅ制御ノード２１１及び第２Ｃ－Ｐｌａｎｅ制御ノード２２１に対して通信路の変更に関する指示を送信する（Path Switch Request：Ｓ１０５、Ｓ１０６：通信処理ステップ）通信路の変更に関する指示には、変更先のｅＮＢ８２を特定する情報(eNB ID)と、変更の対象となる通信路を特定する情報（TU-1もしくはTU-2）と、が含まれる。なお、２つのノードへの通信路の変更に関する指示の送信順序（Ｓ１０５，Ｓ１０６）は、変更することができる。

第１Ｃ－Ｐｌａｎｅ制御ノード２１１では、通信路の変更に関する指示を受信すると、当該指示に基づいて、公知の手順により、通信路の変更に係る処理を行う。具体的には、同一のスライスＳＬ１の第１Ｕ－Ｐｌａｎｅ制御ノード２１２に対して、変更の対象となる通信路を特定する情報（TU-1）と共に、変更先のｅＮＢ８２を特定する情報（eNB ID）を送信することで、通信路の作成を指示する（Modify Bearer Request：Ｓ１０７）。これに対して、第１Ｕ－Ｐｌａｎｅ制御ノード２１２は、通信路の作成に係る処理を行った後、自ノードを特定する情報（UP1 ID）と共に、通信路を作成する処理を行ったことを第１Ｃ－Ｐｌａｎｅ制御ノード２１１に対して返信する（Modify Bearer Response：Ｓ１０９）。第１Ｕ－Ｐｌａｎｅ制御ノード２１２からの返信を受信した第１Ｃ－Ｐｌａｎｅ制御ノード２１１は、通信路の変更に係る処理が終わったことを、通信路の変更に関する指示（Ｓ１０５）に対する応答として、共通Ｃ－Ｐｌａｎｅ制御ノード３０１に対して通知する（Path Switch Request ack：Ｓ１１１：通信処理ステップ）。

第２Ｃ－Ｐｌａｎｅ制御ノード２２１においても同様の処理が行われる。すなわち、第２Ｃ－Ｐｌａｎｅ制御ノード２２１では、通信路の変更に関する指示を受信すると、当該指示に基づいて、公知の手順により、通信路の変更に係る処理を行う。具体的には、同一のスライスＳＬ２の第２Ｕ－Ｐｌａｎｅ制御ノード２２２に対して、変更の対象となる通信路を特定する情報（TU-2）と共に、変更先のｅＮＢ８２を特定する情報（eNB ID）を送信することで、通信路の作成を指示する（Modify Bearer Request：Ｓ１０８）。これに対して、第２Ｕ－Ｐｌａｎｅ制御ノード２２２は、通信路の作成に係る処理を行った後、自ノードを特定する情報（UPX1 ID）と共に、通信路を作成する処理を行ったことを第２Ｃ－Ｐｌａｎｅ制御ノード２２１に対して返信する（Modify Bearer Response：Ｓ１０９）。第１Ｕ－Ｐｌａｎｅ制御ノード２２２からの返信を受信した第２Ｃ－Ｐｌａｎｅ制御ノード２２１は、通信路の変更に係る処理が終わったことを、通信路の変更に関する指示（Ｓ１０６）に対する応答として、共通Ｃ－Ｐｌａｎｅ制御ノード３０１に対して通知する（Path Switch Request ack：Ｓ１１２：通信処理ステップ）。

図８では、スライスＳＬ１での処理と、スライスＳＬ２での処理と、が交互に行われるように示している。しかしながら、スライスＳＬ１での処理と、スライスＳＬ２での処理は個別に行われるため、処理の順序は、図８に示す順序とは異なる可能性がある。

共通Ｃ－Ｐｌａｎｅ制御ノード３０１では、第１Ｃ－Ｐｌａｎｅ制御ノード２１１からの応答（Ｓ１１１）と、第２Ｃ－Ｐｌａｎｅ制御ノード２２１からの応答（Ｓ１１２）と、を受信すると、ｅＮＢ８２に対して、通信路の変更に係る処理が終了したことを通知する（Path Switch Request ack：Ｓ１１３：通信処理ステップ）。この信号には、第１Ｕ－Ｐｌａｎｅ制御ノード２１２を特定する情報（UP1 ID）と、第２Ｕ－Ｐｌａｎｅ制御ノード２２２を特定する情報（UPX1 ID）とが含まれる。この情報に基づいて、ｅＮＢ８２は、通信路の相手方となるノードを特定することができる。

その後、ｅＮＢ８２からｅＮＢ８１に対して、通信路に係るリソースの開放を指示する（Release Resource：Ｓ１１４）。これにより、ＵＥ９０は、ｅＮＢ８２を経由して第１Ｕ－Ｐｌａｎｅ制御ノード２１２との間でユーザデータの送受信が可能となる（Ｓ１１５）と共に、ｅＮＢ８２を経由して第２Ｕ－Ｐｌａｎｅ制御ノード２２２との間でユーザデータの送受信が可能となる（Ｓ１１６）。これにより、ＵＥ９０は、ｅＮＢ８２を経由してサービスＳ１，Ｓ２を利用することが可能となる。

上記の処理において、ｅＮＢ８２と、第１Ｕ－Ｐｌａｎｅ制御ノード２１２及び第２Ｕ－Ｐｌａｎｅ制御ノード２２２との間の通信路が設けられた時点（Ｓ１１３）では、ｅＮＢ８１側での通信路に係るリソースが開放されていない。したがって、変更前の通信路と変更後の通信路とが両立する状態が設けられた上で、通信路の変更に係る処理が行われる。

すなわち、変更後の通信路を設ける処理を行った後、変更前の通信路の開放に係る処理が行われる。このようにして、変更前の通信路と変更後の通信路とが両立する状態が設けられる。

（第２：新たに２つのスライスに対して通信路を設けるケース）
図９は、第２のケースの状況を説明する図である。図９に示すケースは、例えば、ＵＥ９０がスライスＳＬ１，ＳＬ２との間で通信を行うことでＵＥ９０がサービスＳ１，Ｓ２を利用することができるエリアＳＡ＃１から、異なるエリアＳＡ＃２へ移動をする場合である。この場合、ＵＥ９０が通信をする際の基地局装置は、ハンドオーバによりｅＮＢ８１からｅＮＢ８２へ変更されるだけでなく、ＵＥ９０がサービスＳ１，Ｓ２を利用するために通信を行うスライスを、スライスＳＬ１，ＳＬ２からスライスＳＬ４，ＳＬ５に変更する必要がある。移動前のｅＮＢ８１と第１Ｕ－Ｐｌａｎｅ制御ノード２１２との通信路は、ｅＮＢ８２と第４Ｕ－Ｐｌａｎｅ制御ノード２４２との通信路に切り替える。また、移動前のｅＮＢ８１と第２Ｕ－Ｐｌａｎｅ制御ノード２２２との通信路は、ｅＮＢ８２と第５Ｕ－Ｐｌａｎｅ制御ノード２５２との通信路に切り替える。これにより、ＵＥ９０はサービスＳ１，Ｓ２を継続して利用することができる。なお、ＵＥ９０の移動先のエリアＳＡ＃２において、ｅＮＢ８２がどのスライスとの間に通信路を設けることで、ＵＥ９０がサービスＳ１，Ｓ２を利用できるかについては、ｅＮＢ８２、共通Ｃ－Ｐｌａｎｅ制御ノード３０１、及びＵＥ９０等は把握をしていない。この情報については、共通Ｃ－Ｐｌａｎｅ制御ノード３０１がＤＮＳ（Domain Name System）サーバ３５０に対して問い合わせをすることで、情報を取得する。ＤＮＳサーバ３５０は、ドメイン名とＩＰアドレスとの対応付けに係る情報を保持していて、スライスに係る情報も保持している。

このようなケースにおける具体的な処理の手順について、図１０を参照しながら説明する。

まず、ＵＥ９０の移動前のｅＮＢ８１と移動先のｅＮＢ８２との間でハンドオーバに係る信号の送受信が行われる（HO Request, HO Request ACK：Ｓ２０１）。この信号を契機として、ＵＥ９０，ｅＮＢ８１，ｅＮＢ８２の間でハンドオーバに係る処理が行われる（Handover Execution：Ｓ２０２）。

この後、移動先のｅＮＢ８２から、共通Ｃ－Ｐｌａｎｅ制御ノード３０１に対して、通信路の変更に係る要求を行う信号が送信される（Path Switch Request：Ｓ２０３：変更要求取得ステップ）。

通信路の変更に係る要求には、ＵＥ９０を特定する情報と、通信路を特定する情報（TU-1, TU-2）及びセッションを特定する（S-ID1, S-ID2）が含まれる。共通Ｃ－Ｐｌａｎｅ制御ノード３０１の変更要求取得部３１０において、ｅＮＢ８２からの要求を受信すると、判定部３２０では、通信路の変更に係る要求に含まれる情報により、ＵＥ９０が２つのスライスとの間で通信路を設けているか否かを判定する（Ｓ２０４：判定ステップ）。本実施形態では、通信路の変更に係る要求に、通信路を特定する情報が複数含まれていて、セッションを特定する情報が複数含まれていると、判定部３２０では、ＵＥ９０に関して２つの通信路が個別に設けられていることを判断することができる。このように、通信路の変更に係る要求に含まれる情報により、判定部３２０では、複数の通信路が設けられているか否かの判定を行う。そして、判定部３２０において、ＵＥ９０に関して複数の通信路が設けられていると判定された場合には、図１０に示す以下の処理を行う。なお、判定部３２０において、ＵＥ９０に関して複数の通信路が設けられていない、すなわち、ＵＥ９０に関して、１つのスライスとの間にのみ通信路が設けられている、もしくは、通信路が設けられていないと判定された場合には、公知のハンドオーバに係る処理が行われる。

さらに、判定部３２０では、２つのスライスＳＬ１，ＳＬ２がｅＮＢ８２の管轄するエリアをカバーしていないことを確認する（Ｓ２０４）。共通Ｃ－Ｐｌａｎｅ制御ノード３０１では、第１Ｃ－Ｐｌａｎｅ制御ノード２１１が含まれるスライスＳＬ１及び第２Ｃ－Ｐｌａｎｅ制御ノード２２１が含まれるスライスＳＬ２に係る情報を、ｅＮＢ８１とスライスＳＬ１，ＳＬ２間の通信路の開設時に取得している。したがって、２つのスライスＳＬ１，ＳＬ２がｅＮＢ８２の管轄するエリアをカバーしていないことは、共通Ｃ－Ｐｌａｎｅ制御ノード３０１において把握することができる。

判定部３２０において、ＵＥ９０に関して複数の通信路が設けられていて、且つ、スライスＳＬ１，ＳＬ２がｅＮＢ８２の管轄するエリアをカバーしていないことが確認された場合、共通Ｃ－Ｐｌａｎｅ制御ノード３０１の通信処理部３３０は、ＤＮＳサーバ３５０に対して、ｅＮＢ８２を介して通信路を設ける際のスライスに係る情報を問い合わせる（DNS Query Request / Response：Ｓ２０５：通信処理ステップ）。より具体的には、ｅＮＢ８２を介してサービスＳ１，Ｓ２を利用する際に通信を行うことができるＣ－Ｐｌａｎｅ制御ノードを特定する情報を取得する。この結果、通信処理部３３０では、ＤＮＳサーバ３５０から取得されるＣ－Ｐｌａｎｅ制御ノードに係る情報から、ｅＮＢ８２間でユーザデータを送受信しようしているサービスサーバのＡＰＮ（Access Point Name）と、ＵＥ９０の位置（すなわちアクセスするｅＮＢ８２の情報）とに基づいて、サービスＳ１を利用するためにアクセスすべきスライス（ここでは、スライスＳＬ４）のＣ－Ｐｌａｎｅ制御ノード２４１と、サービスＳ２を利用するためにアクセスすべきスライス（ここでは、スライスＳＬ５）のＣ－Ｐｌａｎｅ制御ノード２５１と、が特定される（Ｓ２０６：通信処理ステップ）。

通信処理部３３０では、特定された２つのＣ－Ｐｌａｎｅ制御ノード、すなわち、第４Ｃ－Ｐｌａｎｅ制御ノード２４１及び第５Ｃ－Ｐｌａｎｅ制御ノード２５１に対して、ＵＥ９０に係る新たなセッションを設けるための要求を送信する（Create Session Request：Ｓ２０７、Ｓ２０８：通信処理ステップ）。セッションの作成要求には、アクセス先のｅＮＢ８２を特定する情報（eNB ID）と、セッションの作成により設けられる通信路を特定する情報（TU-1もしくはTU-2）と、が含まれる。なお、２つのノードへのセッションの作成要求の送信順序（Ｓ２０７，Ｓ２０８）は、変更することができる。

第４Ｃ－Ｐｌａｎｅ制御ノード２４１では、セッションの作成要求を受信すると、当該要求に基づいて、公知の手順により、通信路の作成に係る処理を行う。具体的には、通信路を作成するＵ－Ｐｌａｎｅ制御ノードとして、同一のスライスＳＬ４の第４Ｕ－Ｐｌａｎｅ制御ノード２４２を選択する（UP Selection：Ｓ２０９）。その後、第４Ｕ－Ｐｌａｎｅ制御ノード２４２に対して、通信路を特定する情報（TU-1）と共に、ｅＮＢ８２を特定する情報（eNB ID）を送信することで、通信路の作成を指示する（Create Session Request：Ｓ２１１）。第４Ｕ－Ｐｌａｎｅ制御ノード２４２は、通信路の作成に係る処理を行った後、自ノードを特定する情報（UP2 ID）と共に、通信路を作成する処理を行ったことを第４Ｃ－Ｐｌａｎｅ制御ノード２４１に対して返信する（Create Session Response：Ｓ２１３）。第４Ｕ－Ｐｌａｎｅ制御ノード２４２からの返信を受信した第４Ｃ－Ｐｌａｎｅ制御ノード２４１は、通信路の作成に係る処理が終わったことを、セッションの作成要求（Ｓ２０７）に対する応答として、共通Ｃ－Ｐｌａｎｅ制御ノード３０１に対して通知する（Create Session Response：Ｓ２１５：通信処理ステップ）。

第５Ｃ－Ｐｌａｎｅ制御ノード２５１においても同様の処理が行われる。すなわち、第５Ｃ－Ｐｌａｎｅ制御ノード２５１では、セッションの作成要求を受信すると、当該要求に基づいて、公知の手順により、通信路の作成に係る処理を行う。具体的には、通信路を作成するＵ－Ｐｌａｎｅ制御ノードとして、同一のスライスＳＬ５の第５Ｕ－Ｐｌａｎｅ制御ノード２５２を選択する（UP Selection：Ｓ２１０）。その後、第５Ｕ－Ｐｌａｎｅ制御ノード２５２に対して、通信路を特定する情報（TU-2）と共に、ｅＮＢ８２を特定する情報（eNB ID）を送信することで、通信路の作成を指示する（Create Session Request：Ｓ２１２）。第５Ｕ－Ｐｌａｎｅ制御ノード２５２は、通信路の作成に係る処理を行った後、自ノードを特定する情報（UP2 ID）と共に、通信路を作成する処理を行ったことを第５Ｃ－Ｐｌａｎｅ制御ノード２５１に対して返信する（Create Session Response：Ｓ２１４）。第５Ｕ－Ｐｌａｎｅ制御ノード２５２からの返信を受信した第５Ｃ－Ｐｌａｎｅ制御ノード２５１は、通信路の作成に係る処理が終わったことを、セッションの作成要求（Ｓ２０８）に対する応答として、共通Ｃ－Ｐｌａｎｅ制御ノード３０１に対して通知する（Create Session Response：Ｓ２１６：通信処理ステップ）。

図１０では、スライスＳＬ４での処理と、スライスＳＬ５での処理と、が交互に行われるように示している。しかしながら、スライスＳＬ４での処理と、スライスＳＬ５での処理は個別に行われるため、処理の順序は、図１０に示す順序とは異なる可能性がある。

共通Ｃ－Ｐｌａｎｅ制御ノード３０１では、第４Ｃ－Ｐｌａｎｅ制御ノード２４１からの応答（Ｓ２１５）と、第５Ｃ－Ｐｌａｎｅ制御ノード２５１からの応答（Ｓ２１６）と、を受信すると、ｅＮＢ８２に対して、通信路の変更に係る処理が終了したことを通知する（Path Switch Request ack：Ｓ２１７：通信処理ステップ）。この信号には、第４Ｕ－Ｐｌａｎｅ制御ノード２４２を特定する情報（UP2 ID）と、第５Ｕ－Ｐｌａｎｅ制御ノード２５２を特定する情報（UPX2 ID）とが含まれる。この情報に基づいて、ｅＮＢ８２は、通信路の相手方となるノードを特定することができる。

その後、ｅＮＢ８２からｅＮＢ８１に対して、通信路に係るリソースの開放を指示する（Release Resource：Ｓ２１８）。また、共通Ｃ－Ｐｌａｎｅ制御ノード３０１は、ｅＮＢ８１との間で通信路を設けていたスライスＳＬ１の第１Ｃ－Ｐｌａｎｅ制御ノード２１１と、スライスＳＬ２の第２Ｃ－Ｐｌａｎｅ制御ノード２２１に対して、セッションの開放を指示して、セッションの開放処理を行う（Delete Session Request / Response：Ｓ２１９，Ｓ２２０：通信処理ステップ）。ｅＮＢ８２からｅＮＢ８１へのリソースの開放指示（Ｓ２１８）と、共通Ｃ－Ｐｌａｎｅ制御ノード３０１からのセッション開放指示（Ｓ２１９，Ｓ２２０）とは、順序が入れ替わっていても良い。

以上の処理により、ＵＥ９０は、ｅＮＢ８２を経由して第４Ｕ－Ｐｌａｎｅ制御ノード２４２との間でユーザデータの送受信が可能となると共に、ｅＮＢ８２を経由して第５Ｕ－Ｐｌａｎｅ制御ノード２５２との間でユーザデータの送受信が可能となる。これにより、ＵＥ９０は、ｅＮＢ８２を経由してサービスＳ１，Ｓ２を利用することが可能となる。

上記の処理では、ｅＮＢ８２と、第４Ｕ－Ｐｌａｎｅ制御ノード２４２及び第５Ｕ－Ｐｌａｎｅ制御ノード２５２との間の通信路が設けられた時点（Ｓ２１７）では、ｅＮＢ８１側での２つの通信路に係るリソースが開放されていない。したがって、変更前の通信路と変更後の通信路とが両立する状態が設けられた上で、通信路の変更に係る処理が行われる。

すなわち、変更後の通信路を設ける処理を行った後、変更前の通信路の開放に係る処理が行われる。このようにして、変更前の通信路と変更後の通信路とが両立する状態が設けられる。

（第３：１つのスライスとの間で通信路を設けるケースであって、ＤＮＳサーバから情報を取得することができる場合）
図１１は、第３のケースの状況を説明する図である。図１１に示すケースは、例えば、ＵＥ９０がスライスＳＬ１，ＳＬ２との間で通信を行うことでＵＥ９０がサービスＳ１，Ｓ２を利用することができるエリアＳＡ＃１から、異なるエリアＳＡ＃２へ移動をする場合である。この場合、ＵＥ９０が通信をする際の基地局装置をハンドオーバによりｅＮＢ８１からｅＮＢ８２へ変更するだけでなく、サービスＳ１，Ｓ２を利用するために通信を行うスライスを変更する必要がある。ただし、移動先のエリアＳＡ＃２では、スライスＳＬ１に対応するスライスＳＬ４は存在するが、スライスＳＬ２に対応するスライスが存在しない場合がある。このような場合に２つのサービスを継続して利用する方法として、第３のケースでは、移動前のｅＮＢ８１と第１Ｕ－Ｐｌａｎｅ制御ノード２１２との通信路と、移動前のｅＮＢ８１と第２Ｕ－Ｐｌａｎｅ制御ノード２２２との通信路と、の両方の機能を、ｅＮＢ８２と第４Ｕ－Ｐｌａｎｅ制御ノード２４２との通信路に切り替える。すなわち、１つのスライスＳＬ４に対して設けられる１本の通信路により、２つのサービスのユーザデータの送受信を行う。これにより、ＵＥ９０では、サービスＳ１，Ｓ２を継続して利用することができる。

なお、ＵＥ９０の移動先のエリアＳＡ＃２において、ｅＮＢ８２がどのスライスとの間に通信路を設けることで、ＵＥ９０がサービスＳ１，Ｓ２を利用できるかについては、ｅＮＢ８２、共通Ｃ－Ｐｌａｎｅ制御ノード３０１、及びＵＥ９０等は把握をしていない。この情報については、共通Ｃ－Ｐｌａｎｅ制御ノード３０１がＤＮＳ（Domain Name System）サーバ３５０に対して問い合わせをすることで、情報を取得する。また、共通Ｃ－Ｐｌａｎｅ制御ノード３０１がＤＮＳサーバ３５０及びＳＳＦ７０に問い合わせることで、これらの情報を取得する場合もある。これらの手法については後述する。

上記のような第３のケースにおける具体的な処理の手順について、図１２を参照しながら説明する。

まず、ＵＥ９０の移動前のｅＮＢ８１と移動先のｅＮＢ８２との間でハンドオーバに係る信号の送受信が行われる（HO Request, HO Request ACK：Ｓ３０１）。この信号を契機として、ＵＥ９０，ｅＮＢ８１，ｅＮＢ８２の間でハンドオーバに係る処理が行われる（Handover Execution：Ｓ３０２）。

この後、移動先のｅＮＢ８２から、共通Ｃ－Ｐｌａｎｅ制御ノード３０１に対して、通信路の変更に係る要求を行う信号が送信される（Path Switch Request：Ｓ３０３：変更要求取得ステップ）。

通信路の変更に係る要求には、ＵＥ９０を特定する情報と、通信路を特定する情報（TU-1, TU-2）及びセッションを特定する（S-ID1, S-ID2）が含まれる。共通Ｃ－Ｐｌａｎｅ制御ノード３０１の変更要求取得部３１０において、ｅＮＢ８２からの要求を受信すると、判定部３２０では、通信路の変更に係る要求に含まれる情報により、ＵＥ９０が２つのスライスとの間で通信路を設けているか否かを判定する（Ｓ３０４：判定ステップ）。本実施形態では、通信路の変更に係る要求に、通信路を特定する情報が複数含まれていて、セッションを特定する情報が複数含まれていると、判定部３２０では、ＵＥ９０に関して２つの通信路が個別に設けられていることを判断することができる。このように、通信路の変更に係る要求に含まれる情報により、判定部３２０では、複数の通信路が設けられているか否かの判定を行う。そして、判定部３２０において、ＵＥ９０に関して複数の通信路が設けられていると判定された場合には、図１２に示す以下の処理を行う。なお、判定部３２０において、ＵＥ９０に関して複数の通信路が設けられていない、すなわち、ＵＥ９０に関して、１つのスライスとの間にのみ通信路が設けられている、もしくは、通信路が設けられていないと判定された場合には、公知のハンドオーバに係る処理が行われる。

さらに、判定部３２０では、２つのスライスＳＬ１，ＳＬ２がｅＮＢ８２の管轄するエリアをカバーしていないことを確認する（Ｓ３０４）。この点は第２のケースと同様である。

判定部３２０において、ＵＥ９０に関して複数の通信路が設けられていて、且つ、スライスＳＬ１，ＳＬ２がエリアＳＡ＃２をカバーしていないことが確認された場合、共通Ｃ－Ｐｌａｎｅ制御ノード３０１の通信処理部３３０は、ＤＮＳサーバ３５０に対して、ｅＮＢ８２を介して通信路を設ける際のスライスに係る情報を問い合わせる（DNS Query Request：Ｓ３０５：通信処理ステップ）。より具体的には、通信処理部３３０は、ＤＮＳサーバ３５０に対して、ＥＣＧＩ（E-UTRAN Cell Global ID）もしくはサービスＳ１，Ｓ２を提供するサービスサーバのＡＰＮ（APN1&2）を送信することで、サービスＳ１，Ｓ２を利用する際に通信を行うべきスライスのＣ－Ｐｌａｎｅ制御ノードを特定する情報を取得する。ＥＣＧＩは、ＵＥ９０が在圏するセルを特定する情報であり、すなわち、ＵＥ９０の位置を示す情報である。

ここで、ＤＮＳサーバ３５０が図１３（Ａ）に示す情報を保持している場合、ＤＮＳサーバ３５０は、ＵＥ９０の位置に応じて、各種サービスに対応したスライスに係る情報を提供することができる。図１３（Ａ）では、エリア（location）毎に、サービスの種類（Service Type）と、当該サービスを利用する際に利用されるスライス及びそのスライスを構成するノードが示されている。例えば、Location#1で特定されるエリアでは、ＭＢＢというサービスを利用する際にはスライス１との間で通信路を設け、Ｖ２Ｘというサービスを利用する際にはスライス２との間で通信路を設けることが示されている。一方、Location#2で特定されるエリアでは、ＭＢＢ及びＶ２Ｘの両方のサービスに対してスライス３が対応付けられている。また、Location#3で特定されるエリアでは、ＭＢＢ及びＶ２Ｘの両方のサービスに対してスライス４が対応付けられている。

第２のケースは、Location#1のように、サービス毎に異なるスライスが対応付けられているようなケースであった。これに対して、第３のケースは、Location#2又はLocation#3のように、一つのスライスのノードが２つのサービスＳ１，Ｓ２に適用されるようなケースである。ｅＮＢ８２が管轄するエリア（ＵＥ９０が在圏するエリア）がこのような状況である場合、ＤＮＳサーバ３５０から送信される結果には、１つのＣ－Ｐｌａｎｅ制御ノードを特定する情報のみが返送される（DNS Query Response：Ｓ３０６：通信処理ステップ）。ここでは、第４Ｃ－Ｐｌａｎｅ制御ノード２４１を特定する情報がＤＮＳサーバ３５０から共通Ｃ－Ｐｌａｎｅ制御ノード３０１に対して送られる。これにより、共通Ｃ－Ｐｌａｎｅ制御ノード３０１では、第４Ｃ－Ｐｌａｎｅ制御ノード２４１が含まれるスライスＳＬ４との間で２つのサービスに係るセッションを設けることを決定する（Selects CP2 for both APN1&2 Sessions：Ｓ３０９：通信処理ステップ）。

なお、ＤＮＳサーバ３５０が保持している情報では、ＵＥ９０の在圏するエリアにおいてサービスＳ１，Ｓ２に対応することができるスライスを特定することができない場合がある。それは、ＤＮＳサーバ３５０において、例えば図１３（Ｂ）に対応する情報のみを保持している場合である。図１３（Ｂ）に示す例では、エリア（location）毎に、利用することができるスライス及びそのスライスを構成するノードのみが示されている。すなわち、どのスライスとの間で通信を行うとどのサービスを利用することができるかが不明である場合である。この場合、ＵＥ９０が例えばLocation#2に在圏している場合には、ＤＮＳサーバ３５０からは、スライスＳＬ４の第４Ｃ－Ｐｌａｎｅ制御ノード２４１を特定する情報が共通Ｃ－Ｐｌａｎｅ制御ノード３０１に対して送られる。ただし、この場合には、ＤＮＳサーバ３５０からの情報のみでは第４Ｃ－Ｐｌａｎｅ制御ノード２４１が含まれるスライスＳＬ４に対して通信を行うことで、２つのサービスを利用できるかどうかが不明である。したがって、共通Ｃ－Ｐｌａｎｅ制御ノード３０１の通信処理部３３０では、ＳＳＦ７０に対してＵＥ９０を特定する情報と、利用したいサービスを特定する情報（APN1&APN2）と、ＥＣＧＩとを送信して、問い合わせを行う（Policy Request：Ｓ３０７：通信処理ステップ）。

ＤＮＳサーバ３５０が図１３（Ｂ）に示すような情報のみを保持している場合、ＳＳＦ７０では、図１３（Ｃ）に示すような情報、すなわち、サービス毎に優先して通信を行うべきスライスを特定する情報を保持することができる。図１３（Ｃ）に示す例では、２つのサービスのそれぞれについて、対応可能なスライスが優先される順に記載される。ＳＳＦ７０では、共通Ｃ－Ｐｌａｎｅ制御ノード３０１から送信されるサービスを特定する情報に応じて、対応するスライスの情報を提供する（Policy Response：Ｓ３０８：通信処理ステップ）。ここでは、スライスＳＬ４を特定する情報として、第４Ｃ－Ｐｌａｎｅ制御ノード２４１を特定する情報が提供される。

そして、共通Ｃ－Ｐｌａｎｅ制御ノード３０１では、ＤＮＳサーバ３５０からの情報と、ＳＳＦ７０からの情報とに基づいて、第４Ｃ－Ｐｌａｎｅ制御ノード２４１が含まれるスライスＳＬ４との間で２つのサービスに係るセッションを設けることを決定する（Selects CP2 for both APN1&2 Sessions：Ｓ３０９：通信処理ステップ）。

このように、ＤＮＳサーバ３５０が保持する情報だけでは、適切なスライス（Ｃ－Ｐｌａｎｅ制御ノード）を選択することができない場合には、ＳＳＦ７０がサービスに対応したスライスを特定する情報を保持する構成として、共通Ｃ－Ｐｌａｎｅ制御ノード３０１がＳＳＦ７０にも問い合わせを行うことで、２つのサービスを利用するための適切なスライス（Ｃ－Ｐｌａｎｅ制御ノード）を特定する構成としてもよい。

なお、上記では、ＤＮＳサーバ３５０が図１３（Ｂ）に示すような情報のみを保持している場合について説明したが、他にもＤＮＳサーバ３５０が保持している情報では、ＵＥ９０の在圏するエリアにおいてサービスＳ１，Ｓ２に対応することができるスライスを特定することができない場合がある。それは、例えば、ＤＮＳサーバ３５０がサービスの種類（Service Type）と、当該サービスを利用する際に利用されるスライス及びそのスライスを構成するノードとの対応のみを保持している場合である。このようなケースでは、ＤＮＳサーバ３５０ではＵＥ９０の在圏するエリアに係る情報を考慮して適切なスライスを選択することができないことが考えられるため、ＳＳＦ７０に対して問い合わせを行う必要が生じる。

また、上記のように、ＤＮＳサーバ３５０がサービスの種類（Service Type）と、当該サービスを利用する際に利用されるスライス及びそのスライスを構成するノードとの対応を保持している場合に、ＤＮＳサーバ３５０が保持している情報だけは、特定のサービスに関して対応することができるスライスを特定できない場合がある。例えば、図１３（Ａ）に示す例では、Location#2において、サービスＭＢＢ及びサービスＶ２Ｘについてスライス３が対応可能であることが示されているが、サービスＶ２Ｘに対応可能なスライスが特定されていない場合がある。このような場合についても、ＤＮＳサーバ３５０は、１つのＣ－Ｐｌａｎｅ制御ノードを特定する情報のみを結果として共通Ｃ－Ｐｌａｎｅ制御ノード３０１に対して返送する（DNS Query Response：Ｓ３０６：通信処理ステップ）。このように、１つのＣ－Ｐｌａｎｅ制御ノードを特定する情報が返送された場合には、そのＣ－Ｐｌａｎｅ制御ノードは、ＤＮＳサーバ３５０において複数のサービス全てに対応可能であると判断されたスライスに係るノードの情報である場合と、特定のサービスにのみ対応可能なスライスに係るノードの情報である場合と、がある。前者の場合は、ＳＳＦ７０に問い合わせなくてもよいが、後者の場合は、複数のサービスの利用を継続するためには、ＳＳＦ７０に対しても問い合わせを行う必要が生じる。

ＤＮＳサーバ３５０及びＳＳＦ７０がどのような情報を保持していて、共通Ｃ－Ｐｌａｎｅ制御ノード３０１からの要求に基づいてどのような情報を返すかは予め定められる。例えば、ＤＮＳサーバ３５０において、ＵＥ９０の位置、ＵＥ９０が利用するサービス、及び、スライスのポリシー等の情報に基づいた判断がなされていれば、ＤＮＳサーバ３５０から１つのＣ－Ｐｌａｎｅ制御ノードに係る情報（スライスに係る情報）が提供された場合にもＳＳＦ７０に対する問い合わせは不要であると考えられる。一方、ＤＮＳサーバ３５０が保持する情報が少ない場合には、ＤＮＳサーバ３５０から１つのＣ－Ｐｌａｎｅ制御ノードに係る情報（スライスに係る情報）が提供された場合にはＳＳＦ７０に対して問い合わせることが好ましいと考えられる。このように、ＤＮＳサーバ３５０が保持する情報の量や精度等によっても、ＳＳＦ７０に対して問い合わせることが好ましいかは変化すると考えられる。したがって、共通Ｃ－Ｐｌａｎｅ制御ノード３０１がＤＮＳサーバ３５０から１つのＣ－Ｐｌａｎｅ制御ノードに係る情報を取得した場合に、ＳＳＦ７０に対しても問い合わせを行うかどうかは、ＤＮＳサーバ３５０が保持する情報の種類等に基づいて、予め決めてもよいし、ＤＮＳサーバ３５０からの応答内容に応じて変更するような構成としてもよい。

なお、ＤＮＳサーバ３５０及びＳＳＦ７０が、利用したいサービスを特定する情報（APN1&APN2）に対して適切なスライスを特定する情報を提供できない場合には、サービスの提供ができないため、サービスの提供自体が中断される。

通信処理部３３０では、ここまでの処理により特定されたＣ－Ｐｌａｎｅ制御ノード、すなわち、第４Ｃ－Ｐｌａｎｅ制御ノード２４１に対して、ＵＥ９０に係る新たなセッションを設けるための要求を送信する（Create Session Request：Ｓ３１０：通信処理ステップ）。セッションの作成要求には、アクセス先のｅＮＢ８２を特定する情報（eNB ID）と、セッションの作成により設けられる通信路を特定する情報（TU-1及びTU-2）と、サービスを特定する情報（APN1及びAPN2）が含まれる。これにより、第４Ｃ－Ｐｌａｎｅ制御ノード２４１においても、２つのサービスに係るセッションを開設することが認識される。

第４Ｃ－Ｐｌａｎｅ制御ノード２４１では、セッションの作成要求を受信すると、当該要求に基づいて、公知の手順により、通信路の作成に係る処理を行う。具体的には、通信路を作成するＵ－Ｐｌａｎｅ制御ノードとして、同一のスライスＳＬ４の第４Ｕ－Ｐｌａｎｅ制御ノード２４２を選択する（UP Selection：Ｓ３１１）。その後、第４Ｕ－Ｐｌａｎｅ制御ノード２４２に対して、通信路を特定する情報（TU-1及びTU-2）と共に、ｅＮＢ８２を特定する情報（eNB ID）を送信することで、通信路の作成を指示する（Create Session Request：Ｓ３１２）。第４Ｕ－Ｐｌａｎｅ制御ノード２４２は、通信路の作成に係る処理を行った後、通信路を特定する情報（TU-1及びTU-2）及び自ノードを特定する情報（UP2 ID）と共に、通信路を作成する処理を行ったことを第４Ｃ－Ｐｌａｎｅ制御ノード２４１に対して返信する（Create Session Response：Ｓ３１３）。第４Ｕ－Ｐｌａｎｅ制御ノード２４２からの返信を受信した第４Ｃ－Ｐｌａｎｅ制御ノード２４１は、通信路の作成に係る処理が終わったことを、セッションの作成要求（Ｓ３１０）に対する応答として、共通Ｃ－Ｐｌａｎｅ制御ノード３０１に対して通知する（Create Session Response：Ｓ３１４：通信処理ステップ）。

共通Ｃ－Ｐｌａｎｅ制御ノード３０１では、第４Ｃ－Ｐｌａｎｅ制御ノード２４１からの応答（Ｓ３１４）を受信すると、ｅＮＢ８２に対して、通信路の変更に係る処理が終了したことを通知する（Path Switch Request ack：Ｓ３１５：通信処理ステップ）。この信号には、第４Ｕ－Ｐｌａｎｅ制御ノード２４２を特定する情報（UP2 ID）に対応付けて、２つの通信路を特定する情報（TU-1, TU-2）と、２つのセッションを特定する情報（S-ID1, S-ID2）が含まれる。この情報に基づいて、ｅＮＢ８２は、通信路の相手方となるノードを特定することができる。

その後、ｅＮＢ８２からｅＮＢ８１に対して、通信路に係るリソースの開放を指示する（Release Resource：Ｓ３１６）。また、共通Ｃ－Ｐｌａｎｅ制御ノード３０１は、ｅＮＢ８１との間で通信路を設けていたスライスＳＬ１の第１Ｃ－Ｐｌａｎｅ制御ノード２１１と、スライスＳＬ２の第２Ｃ－Ｐｌａｎｅ制御ノード２２１に対して、セッションの開放を指示して、セッションの開放処理を行う（Delete Session Request / Response：Ｓ３１７，Ｓ３１８：通信処理ステップ）。ｅＮＢ８２からｅＮＢ８１へのリソースの開放指示（Ｓ３１６）と、共通Ｃ－Ｐｌａｎｅ制御ノード３０１からのセッション開放指示（Ｓ３１７，Ｓ３１８）は、順序が入れ替わっていても良い。

以上の処理により、ＵＥ９０は、ｅＮＢ８２を経由して第４Ｕ－Ｐｌａｎｅ制御ノード２４２との間でユーザデータの送受信が可能となることで、ｅＮＢ８２を経由してサービスＳ１，Ｓ２を利用することが可能となる。

なお、上記の第３のケースでは、移動先のエリアＳＡ＃２では、スライスＳＬ１に対応するスライスＳＬ４は存在するが、スライスＳＬ２に対応するスライスが存在しない場合、として説明したが、逆の場合であってもよい。すなわち、スライスＳＬ１に対応するスライスは存在しないが、スライスＳＬ２に対応するスライスＳＬ５が存在する場合も、上記で説明した処理と同様の方法で処理を行うことができる。

上記の処理では、ｅＮＢ８２と、第４Ｕ－Ｐｌａｎｅ制御ノード２４２との間の通信路が設けられた時点（Ｓ３１５）では、ｅＮＢ８１側での通信路に係るリソースが開放されていない。したがって、変更前の通信路と変更後の通信路とが両立する状態が設けられた上で、通信路の変更に係る処理が行われる。

すなわち、変更後の通信路を設ける処理を行った後、変更前の通信路の開放に係る処理が行われる。このようにして、変更前の通信路と変更後の通信路とが両立する状態が設けられる。

（第４：１つのスライスとの間で通信路を設けるケースであって、ＳＳＦから情報を取得することができる場合）
図１４は、第４のケースの状況を説明する図である。図１４に示すケースは、第３のケースと同様に、ＵＥ９０がスライスＳＬ１，ＳＬ２との間で通信を行うことでＵＥ９０がサービスＳ１，Ｓ２を利用することができるエリアＳＡ＃１から、異なるエリアＳＡ＃２へ移動をする場合である。この場合、ＵＥ９０が通信をする際の基地局装置は、ハンドオーバによりｅＮＢ８１からｅＮＢ８２へ変更されるだけでなく、サービスＳ１，Ｓ２を利用するために通信を行うスライスを変更する必要がある。ただし、移動先のエリアＳＡ＃２では、スライスＳＬ１，ＳＬ２に対応するスライスが存在しない場合がある。つまり、第３のケースと同様に、ＤＮＳサーバ３５０に対して問い合わせを行った場合に、ＤＮＳサーバ３５０からＣ－Ｐｌａｎｅ制御サーバに係る情報を取得できない場合である。

このような場合に２つのサービスを継続して利用する方法としては、第４のケースでは、移動前のｅＮＢ８１と第１Ｕ－Ｐｌａｎｅ制御ノード２１２との通信路と、移動前のｅＮＢ８１と第２Ｕ－Ｐｌａｎｅ制御ノード２２２との通信路と、の両方の機能を、２つのサービスとは関連性がないスライスＳＬ６に設けられた第６Ｕ－Ｐｌａｎｅ制御ノード（ＵＰＹ）２６２との通信路に切り替える。スライスＳＬ６には、第６Ｃ－Ｐｌａｎｅ制御ノード（ＣＰＹ）２６１と、第６Ｕ－Ｐｌａｎｅ制御ノード２６２と、が含まれる。

なお、ＵＥ９０の移動先のエリアＳＡ＃２において、ｅＮＢ８２がどのスライスとの間に通信路を設けることで、ＵＥ９０がサービスＳ１，Ｓ２を利用できるかについては、ｅＮＢ８２、共通Ｃ－Ｐｌａｎｅ制御ノード３０１、及びＵＥ９０等は把握をしていない。また、スライスＳＬ６がサービスＳ１，Ｓ２に対応可能であることをＤＮＳサーバ３５０が把握していない場合には、ＤＮＳサーバ３５０もこの情報を共通Ｃ－Ｐｌａｎｅ制御ノード３０１に対して提供することができない。そのため、共通Ｃ－Ｐｌａｎｅ制御ノード３０１は、ＳＳＦ７０に問い合わせることで情報を取得する。

上記のような第４のケースにおける具体的な処理の手順について、図１５を参照しながら説明する。

まず、ＵＥ９０の移動前のｅＮＢ８１と移動先のｅＮＢ８２との間でハンドオーバに係る信号の送受信が行われる（HO Request, HO Request ACK：Ｓ４０１）。この信号を契機として、ＵＥ９０，ｅＮＢ８１，ｅＮＢ８２の間でハンドオーバに係る処理が行われる（Handover Execution：Ｓ４０２）。

この後、移動先のｅＮＢ８２から、共通Ｃ－Ｐｌａｎｅ制御ノード３０１に対して、通信路の変更に係る要求を行う信号が送信される（Path Switch Request：Ｓ４０３：変更要求取得ステップ）。

通信路の変更に係る要求には、ＵＥ９０を特定する情報と、通信路を特定する情報（TU-1, TU-2）及びセッションを特定する（S-ID1, S-ID2）が含まれる。共通Ｃ－Ｐｌａｎｅ制御ノード３０１の変更要求取得部３１０において、ｅＮＢ８２からの要求を受信すると、判定部３２０では、通信路の変更に係る要求に含まれる情報により、ＵＥ９０が２つのスライスとの間で通信路を設けているか否かを判定する（Ｓ４０４：判定ステップ）。本実施形態では、通信路の変更に係る要求に、通信路を特定する情報が複数含まれていて、セッションを特定する情報が複数含まれていると、判定部３２０では、ＵＥ９０に関して２つの通信路が個別に設けられていることを判断することができる。このように、通信路の変更に係る要求に含まれる情報に基づいて、判定部３２０では、複数の通信路が設けられているか否かの判定を行う。そして、判定部３２０において、ＵＥ９０に関して複数の通信路が設けられていると判定された場合には、図１５に示す以下の処理を行う。なお、判定部３２０において、ＵＥ９０に関して複数の通信路が設けられていない、すなわち、ＵＥ９０に関して、１つのスライスとの間にのみ通信路が設けられている、もしくは、通信路が設けられていないと判定された場合には、公知のハンドオーバに係る処理が行われる。

さらに、判定部３２０では、２つのスライスＳＬ１，ＳＬ２がｅＮＢ８２の管轄するエリアをカバーしていないことを確認する（Ｓ４０４）。この点は第２のケースと同様である。

判定部３２０において、ＵＥ９０に関して複数の通信路が設けられていて、且つ、スライスＳＬ１，ＳＬ２がエリアＳＡ#２をカバーしていないことが確認された場合、共通Ｃ－Ｐｌａｎｅ制御ノード３０１の通信処理部３３０は、ＤＮＳサーバ３５０に対して、ｅＮＢ８２を介して通信路を設ける際のスライスに係る情報を問い合わせる（DNS Query Request：Ｓ４０５：通信処理ステップ）。より具体的には、通信処理部３３０は、ＤＮＳサーバ３５０に対して、ＥＣＧＩ（E-UTRAN Cell Global ID）もしくはサービスＳ１，Ｓ２を提供するサービスサーバのＡＰＮ（APN1&2）を送信することで、サービスＳ１，Ｓ２を利用する際に通信を行うべきスライスのＣ－Ｐｌａｎｅ制御ノードを特定する情報を取得する。ＥＣＧＩは、ＵＥ９０が在圏するセルを特定する情報であり、すなわち、ＵＥ９０の位置を示す情報である。

第４のケースでは、ｅＮＢ８２の管轄するエリアＳＡ＃２は、図１３（Ａ）に示す表には含まれない状態となっている。すなわち、location及びサービスの種類に対して、アクセス先（通信路を設ける先）のスライスを特定する情報が対応付けられていない状態である。したがって、ＤＮＳサーバ３５０は、共通Ｃ－Ｐｌａｎｅ制御ノード３０１に対して、サービスに対応するスライスが存在しないことを示す情報、すなわち、Ｃ－Ｐｌａｎｅ制御ノードの情報がないことを通知する（DNS Query Response：Ｓ４０６：通信処理ステップ）。

このように、ＤＮＳサーバ３５０からＣ－Ｐｌａｎｅ制御ノードを特定する情報が提供されない場合、共通Ｃ－Ｐｌａｎｅ制御ノード３０１側では、ＵＥ９０がサービスＳ１，Ｓ２を利用するためにｅＮＢ８２との間で通信路を設ける相手方のスライスを特定することができないことになる。そこで、共通Ｃ－Ｐｌａｎｅ制御ノード３０１の通信処理部３３０では、ＳＳＦ７０に対してＵＥ９０を特定する情報と、利用したいサービスを特定する情報（APN1&APN2）と、ＥＣＧＩとを送信して、問い合わせを行う（Policy Request：Ｓ４０７：通信処理ステップ）。

これに対して、ＳＳＦ７０は、利用したいサービスを特定する情報と、ＥＧＣＩと、自装置で保持している情報と、に基づいて、ＵＥ９０の在圏するエリアにおいて、当該サービスを利用するための通信路を設けることができるスライスを特定する。図１３（Ｃ）に示すように、ＳＳＦ７０では、サービス毎に対応可能なスライスを特定する情報を保持していることから、この情報を利用して、対応するスライスの情報を提供する（Policy Response：Ｓ４０８：通信処理ステップ）。

共通Ｃ－Ｐｌａｎｅ制御ノード３０１では、ＳＳＦ７０からの情報に基づいて、第６Ｃ－Ｐｌａｎｅ制御ノード２６１が含まれるスライスＳＬ６との間で２つのサービスに係るセッションを設けることを決定する（Selects CPY for both APN1&2 Sessions：Ｓ４０９：通信処理ステップ）。

このように、ＤＮＳサーバ３５０から提供される情報では、適切なスライス（Ｃ－Ｐｌａｎｅ制御ノード）を選択することができない場合には、サービスに対応したスライスを特定する情報を保持するＳＳＦ７０に対して問い合わせる構成とする。これにより、２つのサービスを利用するための適切なスライス（Ｃ－Ｐｌａｎｅ制御ノード）に係る情報を取得することが可能となる。

なお、ＤＮＳサーバ３５０及びＳＳＦ７０が、利用したいサービスを特定する情報（APN1&APN2）に対して適切なスライスを特定する情報を提供できない場合には、サービスの提供ができないため、サービスの提供自体が中断される。

通信処理部３３０では、ここまでの処理により特定されたＣ－Ｐｌａｎｅ制御ノード、すなわち、第６Ｃ－Ｐｌａｎｅ制御ノード２６１に対して、ＵＥ９０に係る新たなセッションを設けるための要求を送信する（Create Session Request：Ｓ４１０：通信処理ステップ）。セッションの作成要求には、アクセス先のｅＮＢ８２を特定する情報（eNB ID）と、セッションの作成により設けられる通信路を特定する情報（TU-1及びTU-2）と、サービスを特定する情報（APN1及びAPN2）が含まれる。これにより、第６Ｃ－Ｐｌａｎｅ制御ノード２６１においても、２つのサービスに係るセッションを開設することが認識される。

第６Ｃ－Ｐｌａｎｅ制御ノード２６１では、セッションの作成要求を受信すると、当該要求に基づいて、公知の手順により、通信路の作成に係る処理を行う。具体的には、通信路を作成するＵ－Ｐｌａｎｅ制御ノードとして、同一のスライスＳＬ６の第６Ｕ－Ｐｌａｎｅ制御ノード２６２を選択する（UP Selection：Ｓ４１１）。その後、第６Ｕ－Ｐｌａｎｅ制御ノード２６２に対して、通信路を特定する情報（TU-1及びTU-2）と共に、ｅＮＢ８２を特定する情報（eNB ID）を送信することで、通信路の作成を指示する（Create Session Request：Ｓ４１２）。第６Ｕ－Ｐｌａｎｅ制御ノード２６２は、通信路の作成に係る処理を行った後、通信路を特定する情報（TU-1及びTU-2）及び自ノードを特定する情報（UP2 ID）と共に、通信路を作成する処理を行ったことを第６Ｃ－Ｐｌａｎｅ制御ノード２６１に対して返信する（Create Session Response：Ｓ４１３）。第６Ｕ－Ｐｌａｎｅ制御ノード２６２からの返信を受信した第６Ｃ－Ｐｌａｎｅ制御ノード２６１は、通信路の作成に係る処理が終わったことを、セッションの作成要求（Ｓ４１０）に対する応答として、共通Ｃ－Ｐｌａｎｅ制御ノード３０１に対して通知する（Create Session Response：Ｓ４１４：通信処理ステップ）。

共通Ｃ－Ｐｌａｎｅ制御ノード３０１では、第４Ｃ－Ｐｌａｎｅ制御ノード２４１からの応答（Ｓ４１４）を受信すると、ｅＮＢ８２に対して、通信路の変更に係る処理が終了したことを通知する（Path Switch Request ack：Ｓ４１５：通信処理ステップ）。この信号には、第６Ｕ－Ｐｌａｎｅ制御ノード２６２を特定する情報（UPY ID）に対応付けて、２つの通信路を特定する情報（TU-1, TU-2）と、２つのセッションを特定する情報（S-ID1, S-ID2）が含まれる。この情報に基づいて、ｅＮＢ８２は、通信路の相手方となるノードを特定することができる。

その後、ｅＮＢ８２からｅＮＢ８１に対して、通信路に係るリソースの開放を指示する（Release Resource：Ｓ４１６）。また、共通Ｃ－Ｐｌａｎｅ制御ノード３０１は、ｅＮＢ８１との間で通信路を設けていたスライスＳＬ１の第１Ｃ－Ｐｌａｎｅ制御ノード２１１と、スライスＳＬ２の第２Ｃ－Ｐｌａｎｅ制御ノード２２１に対して、セッションの開放を指示して、セッションの開放処理を行う（Delete Session Request/Response：Ｓ４１７，Ｓ４１８：通信処理ステップ）。ｅＮＢ８２からｅＮＢ８１へのリソースの開放指示（Ｓ４１６）と、共通Ｃ－Ｐｌａｎｅ制御ノード３０１からのセッション開放指示（Ｓ４１７，Ｓ４１８）は、順序が入れ替わっていても良い。

以上の処理により、ＵＥ９０は、ｅＮＢ８２を経由して第６Ｕ－Ｐｌａｎｅ制御ノード２６２との間でユーザデータの送受信が可能となることで、ｅＮＢ８２を経由してサービスＳ１，Ｓ２を利用することが可能となる。

上記の処理では、ｅＮＢ８２と、第６Ｕ－Ｐｌａｎｅ制御ノード２６２との間の通信路が設けられた時点（Ｓ４１５）では、ｅＮＢ８１側での通信路に係るリソースが開放されていない。したがって、変更前の通信路と変更後の通信路とが両立する状態が設けられた上で、通信路の変更に係る処理が行われる。

すなわち、変更後の通信路を設ける処理を行った後、変更前の通信路の開放に係る処理が行われる。このようにして、変更前の通信路と変更後の通信路とが両立する状態が設けられる。

以上のように、第１実施形態に係る通信制御装置である共通Ｃ－Ｐｌａｎｅ制御ノード３０１及びこの共通Ｃ－Ｐｌａｎｅ制御ノード３０１による通信制御方法によれば、上記の４つのケースに共通するが、変更前の通信路と変更後の通信路とが両立した状態を設けながら、通信路の変更に係る処理が行われる。このため、ＵＥ９０は、変更前の通信路もしくは変更後の通信路を利用してユーザデータを送受信可能な状態を保つことができること。したがって、複数のスライスに割り当てられているサービスを利用しながら、複数のスライスとの間に設けられる通信路を変更することが実現される。

また、上記の４つのケースに共通して、変更後の通信路を設ける処理を行った後、変更前の通信路の開放に係る処理が行われる。このようにすることで、ＵＥ９０が複数のスライスに対して接続している状態であっても、変更前の通信路と変更後の通信路とが両立する状態が設けられる。

また、第２のケースでは、変更前の複数の通信路について、それぞれ、変更前の通信路が設けられたスライスＳＬ１，ＳＬ２とは異なり、且つ、互いに異なるスライスＳＬ４，ＳＬ５におけるＵ－Ｐｌａｎｅ制御ノードに対して設けられる通信路へ変更する。このような構成であると、変更前の通信路毎に変更後も個別に通信路が設けられるため、通信路を変更した後についても、ユーザデータを好適に送受信することができる。

一方、第３のケース及び第４のケースでは、変更前の複数の通信路に対して、変更前の通信路が設けられたスライスＳＬ１，ＳＬ２とは異なるスライス（第３のケースの場合には、スライスＳＬ４であり、第４のケースの場合にはスライスＳＬ６である）におけるＵ－Ｐｌａｎｅ制御ノードに対して設けられる一つの通信路へ変更される。上記実施形態でも説明したが、変更前の複数のスライスにおける制御ノードそれぞれに対して個別に通信路に対応した通信路を設けることができないようなケースが存在する。この場合には、上記のように、変更前の複数の通信路を、１つのスライスの制御ノードに対して設けられる１つの通信路にまとめる構成とすることで、通信路を変更した後についても、複数のサービスに係るユーザデータを好適に送受信することができる。

なお、第３のケース及び第４のケースでは、複数の通信路（上記実施形態では２つの通信路）を１つの通信路にまとめる構成について説明したが、このように１つの通信路にまとめる複数の通信路は、ＵＥ９０に関して設けられている通信路全てでなくてもよい。例えば、変更前にはＵＥ９０が通信路を３つ設けている場合に、３つの通信路のうちの２つの通信路について変更後は１つの通信路にまとめ、残りの１つの通信路は変更後も１つの通信路として別途設けていてもよい。この場合、ＵＥ９０に係る変更後の通信路の数は２つとなる。このように、ＵＥ９０に係る全ての通信路を１つの通信路にまとめなくてもよい。この点は、後述の第２実施形態についても同様である。

（第２実施形態：Ｃ－Ｐｌａｎｅ制御ノードにより通信路の管理を一括して行うシステム）
次に、本発明に係る通信制御装置を共通Ｃ－Ｐｌａｎｅ制御ノードを有しないネットワーク構成に適用した場合について説明する。

図１６は、第２実施形態に係るシステムにより構築されたスライス構成を含むコアネットワークＮ２を説明する図であり、第１実施形態の図２に対応する。

図１６に示すように、第２実施形態においても、第１のサービス（サービスＳ１）用のスライスであるスライスＳＬ１（第１のスライス）、第２のサービス（サービスＳ２）用のスライスであるスライスＳＬ２（第２のスライス）、及び、スライスＳＬ１又はスライスＳＬ２の制御に係る制御装置としての機能を有するスライスであるスライスＳＬ３（第３のスライス）を生成する。ＮＦＶＯ３０は、スライスＳＬ１に対してサービスＳ１を割り当て、スライスＳＬ２に対してサービスＳ２を割り当てる。サービスＳ１及びサービスＳ２を実行する機能は、スライスＳＬ３から送られる信号等に基づいて処理を行ったり、通信制御装置としての機能を有するノードを含むスライスＳＬ３に対して情報の提供を要求する処理を行ったりする。

第２実施形態においては、サービスＳ１，Ｓ２に対応するスライスＳＬ１，ＳＬ２には、Ｃ－Ｐｌａｎｅ制御ノードが設けられていない。すなわち、サービスＳ１に係るノードとしては、スライスＳＬ１の第１Ｕ－Ｐｌａｎｅ制御ノード（ＵＰ１）２１２のみが存在する。また、サービスＳ２に係るノードとしては、スライスＳＬ２の第２Ｕ－Ｐｌａｎｅ制御ノード（ＵＰＸ１）２２２のみが存在する。

また、スライスＳＬ３にはＣ－Ｐｌａｎｅ制御ノード３０５が含まれる。Ｃ－Ｐｌａｎｅ制御ノード３０５は、ユーザ側からの指示に基づいて、ユーザと各スライスとの通信路の開設及び切断に係る処理を実行する。すなわち、第２実施形態では、サービスを提供するスライスにはノードとしてＣ－Ｐｌａｎｅ制御ノードが設けられず、スライスＳＬ３に設けられるＣ－Ｐｌａｎｅ制御ノード３０５がサービスを利用する際に経由する各スライスに対する通信路の開設及び切断に係る処理を行う。この点が第１実施形態との相違点である。

第２実施形態のシステムにおいては、スライスＳＬ３に設けられるＣ－Ｐｌａｎｅ制御ノード３０５が第１実施形態での共有Ｃ－Ｐｌａｎｅ制御ノード３０１の機能と、各スライスに設けられたＣ－Ｐｌａｎｅ制御ノードの機能と、を有している。すなわち、Ｃ－Ｐｌａｎｅ制御ノード３０５が、複数のスライスの制御ノードに対して設けられるＵＥ９０に係る通信路の制御を行う通信制御装置として機能する。

なお、ＬＴＥネットワークにおけるＥＰＣ（Evolved Packet Core）においては、例えば、ＭＭＥ（Mobility Management Entity）が、第２実施形態におけるＣ－Ｐｌａｎｅ制御ノード３０５に係る機能を有する構成とすることができる。また、例えば、ＳＧＷ（Serving Gateway）及びＰＧＷ（Packet Data Network Gateway）が、第２実施形態におけるＵ－Ｐｌａｎｅ制御ノードに係る機能を有する構成とすることができる。

このような第２実施形態のシステムにおいて、ＵＥ９０が複数のスライスとの間で通信を行っている際に、何らかの事情により、ＵＥ９０がサービスを利用するために通信を行っているスライスの変更、もしくは、スライスとＵＥ９０との間の通信路の変更を行う必要が生じた場合の処理について説明する。第２実施形態のシステムでは、上記の処理をＣ－Ｐｌａｎｅ制御ノード３０５が主体的に実行する。そのため、Ｃ－Ｐｌａｎｅ制御ノード３０５は、共通Ｃ－Ｐｌａｎｅ制御ノード３０１と同様に、図５に示す変更要求取得部３１０と、判定部３２０と、通信処理部３３０と、を有する。

各部の機能は共通Ｃ－Ｐｌａｎｅ制御ノード３０１と同様である。変更要求取得部３１０は、スライスＳＬ１等との通信路の変更に係る要求を取得する機能を有する。また、判定部３２０は、通信路の変更に係る要求の対象のＵＥ９０が複数のスライスとの間で通信路を設けているかを判定する機能を有する。さらに、通信処理部３３０は、通信路の変更に係る要求に基づいて、ＵＥ９０がサービスを利用しながら通信路の変更が行えるように、処理を行う。

次に、Ｃ－Ｐｌａｎｅ制御ノード３０５を含むコアネットワークＮ２におけるＵＥ９０に係る通信路の変更の具体的な処理について説明する。ＵＥ９０が複数のサービスを利用しながらその通信路を変更する場合には、第１実施形態と同様に、４つのケースが考えられる。以下、４つのケースについて、それぞれ状況を説明すると共に、具体的な処理についてシーケンス図を参照しながら説明する。なお、４つのケースにおける処理の内容については第１実施形態と共通している部分が多いため、説明を簡略化する場合がある。

（第１：通信路のみを変更するケース）
図１７は、第１のケースの状況を説明する図である。図１７に示すケースは、例えば、ＵＥ９０がスライスＳＬ１，ＳＬ２との間で通信を行うことでＵＥ９０がサービスＳ１，Ｓ２を利用することができるエリアＳＡ＃１内で移動をする場合である。この場合、ＵＥ９０が通信をする際の基地局装置は、ハンドオーバによりｅＮＢ８１からｅＮＢ８２へ変更されるが、引き続きスライスＳＬ１，ＳＬ２との通信を行ってサービスＳ１，Ｓ２を利用することができる。したがって、移動前のｅＮＢ８１と第１Ｕ－Ｐｌａｎｅ制御ノード２１２との通信路をｅＮＢ８２と第１Ｕ－Ｐｌａｎｅ制御ノード２１２との通信路に切り替えると共に、移動前のｅＮＢ８１と第２Ｕ－Ｐｌａｎｅ制御ノード２２２との通信路をｅＮＢ８２と第２Ｕ－Ｐｌａｎｅ制御ノード２２２との通信路に切り替えることで、サービスＳ１，Ｓ２を継続して利用することができる。

このようなケースにおける具体的な処理の手順について、図１８を参照しながら説明する。

まず、ＵＥ９０の移動前のｅＮＢ８１と移動先のｅＮＢ８２との間でハンドオーバに係る信号の送受信が行われる（HO Request, HO Request ACK：Ｓ５０１）。この信号を契機として、ＵＥ９０，ｅＮＢ８１，ｅＮＢ８２の間でハンドオーバに係る処理が行われる（Handover Execution：Ｓ５０２）。

この後、移動先のｅＮＢ８２から、Ｃ－Ｐｌａｎｅ制御ノード３０５に対して、通信路の変更に係る要求を行う信号が送信される（Path Switch Request：Ｓ５０３：変更要求取得ステップ）。なお、ここでは、ＵＥ９０がハンドオーバを行う場合について説明しているので、通信路の変更に係る要求を行う信号は”Path Switch Request”であるが、通信路の変更に係る要求を行う信号は、通信路を変更する事情に応じて適宜変更される。これは、他のケースでも同様である。

通信路の変更に係る要求には、ＵＥ９０を特定する情報と、通信路を特定する情報（TU-1, TU-2）及びセッションを特定する（S-ID1, S-ID2）が含まれる。Ｃ－Ｐｌａｎｅ制御ノード３０５の変更要求取得部３１０において、ｅＮＢ８２からの要求を受信すると、判定部３２０では、通信路の変更に係る要求に含まれる情報により、ＵＥ９０が２つのスライスとの間で通信路を設けているか否かを判定する（Ｓ５０４：判定ステップ）。判定部３２０において、ＵＥ９０に関して複数の通信路が設けられていると判定された場合には、図１８に示す以下の処理を行う。なお、判定部３２０において、ＵＥ９０に関して複数の通信路が設けられていない、すなわち、ＵＥ９０に関して、１つのスライスとの間にのみ通信路が設けられている、もしくは、通信路が設けられていないと判定された場合には、公知のハンドオーバに係る処理が行われる。

判定部３２０において、ＵＥ９０に関して複数の通信路が設けられていると判定した場合、Ｃ－Ｐｌａｎｅ制御ノード３０５の通信処理部３３０は、セッションを特定する情報等に基づいて、第１Ｕ－Ｐｌａｎｅ制御ノード２１２及び第２Ｕ－Ｐｌａｎｅ制御ノード２２２に対して通信路の変更に関する指示を送信する（Path Switch Request：Ｓ５０５，Ｓ５０６：通信処理ステップ）。通信路の変更に関する指示には、変更先のｅＮＢ８２を特定する情報（eNB ID）と、変更の対象となる通信路を特定する情報（TU-1もしくはTU-2）と、が含まれる。なお、２つのノードへの通信路の変更に関する指示の送信順序（Ｓ５０５，Ｓ５０６：通信処理ステップ）は、変更することができる。

第１Ｕ－Ｐｌａｎｅ制御ノード２１２では、通信路の変更に関する指示を受信すると、通信路の作成に係る処理を行った後、自ノードを特定する情報（UP1 ID）と共に、通信路を作成する処理を行ったことをＣ－Ｐｌａｎｅ制御ノード３０１に対して返信する（Modify Bearer Response：Ｓ５０７：通信処理ステップ）。第２Ｕ－Ｐｌａｎｅ制御ノード２２２においても、同様に、通信路の作成に係る処理を行った後、自ノードを特定する情報（UPX1 ID）と共に、通信路を作成する処理を行ったことをＣ－Ｐｌａｎｅ制御ノード３０５に対して返信する（Modify Bearer Response：Ｓ５０８：通信処理ステップ）。

なお、スライスＳＬ１での処理と、スライスＳＬ２での処理は個別に行われるため、上記の処理（Ｓ５０５～Ｓ５０８）の順序は、図１８に示す順序とは異なる可能性がある。

Ｃ－Ｐｌａｎｅ制御ノード３０５では、第１Ｕ－Ｐｌａｎｅ制御ノード２１２からの応答（Ｓ５０７）と、第２Ｕ－Ｐｌａｎｅ制御ノード２２２からの応答（Ｓ５０８）と、を受信すると、ｅＮＢ８２に対して、通信路の変更に係る処理が終了したことを通知する（Path Switch Request ack：Ｓ５０９：通信処理ステップ）。この信号には、第１Ｕ－Ｐｌａｎｅ制御ノード２１２を特定する情報（UP1 ID）と、第２Ｕ－Ｐｌａｎｅ制御ノード２２２を特定する情報（UPX1 ID）とが含まれる。この情報に基づいて、ｅＮＢ８２は、通信路の相手方となるノードを特定することができる。

その後、ｅＮＢ８２からｅＮＢ８１に対して、通信路に係るリソースの開放を指示する（Release Resource：Ｓ５１０）。これにより、ＵＥ９０は、ｅＮＢ８２を経由して第１Ｕ－Ｐｌａｎｅ制御ノード２１２との間でユーザデータの送受信が可能となる（Ｓ５１１）と共に、ｅＮＢ８２を経由して第２Ｕ－Ｐｌａｎｅ制御ノード２２２との間でユーザデータの送受信が可能となる（Ｓ５１２）。これにより、ＵＥ９０は、ｅＮＢ８２を経由してサービスＳ１，Ｓ２を利用することが可能となる。

上記の処理では、ｅＮＢ８２と、第１Ｕ－Ｐｌａｎｅ制御ノード２１２及び第２Ｕ－Ｐｌａｎｅ制御ノード２２２との間の通信路が設けられた時点（Ｓ５０９）では、ｅＮＢ８１側での通信路に係るリソースが開放されていない。したがって、変更前の通信路と変更後の通信路とが両立する状態が設けられた上で、通信路の変更に係る処理が行われる。

上記の処理では、ｅＮＢ８２と、第１Ｕ－Ｐｌａｎｅ制御ノード２１２及び第２Ｕ－Ｐｌａｎｅ制御ノード２２２との間の通信路が設けられた時点（Ｓ５０９）では、ｅＮＢ８１側での通信路に係るリソースが開放されていない。したがって、変更前の通信路と変更後の通信路とが両立する状態が設けられた上で、通信路の変更に係る処理が行われる。

すなわち、変更後の通信路を設ける処理を行った後、変更前の通信路の開放に係る処理が行われる。このようにして、変更前の通信路と変更後の通信路とが両立する状態が設けられる。

（第２：新たに２つのスライスに対して通信路を設けるケース）
図１９は、第２のケースの状況を説明する図である。図１９に示すケースは、例えば、ＵＥ９０がエリアＳＡ＃１からエリアＳＡ＃２へ移動をする場合である。この場合、ＵＥ９０が通信をする際の基地局装置は、ハンドオーバによりｅＮＢ８１からｅＮＢ８２へ変更されるだけでなく、サービスＳ１，Ｓ２を利用するために通信を行うスライスを、スライスＳＬ１，ＳＬ２からスライスＳＬ４，ＳＬ５に変更する。すなわち、移動前のｅＮＢ８１と第１Ｕ－Ｐｌａｎｅ制御ノード２１２との通信路は、ｅＮＢ８２と第４Ｕ－Ｐｌａｎｅ制御ノード２４２との通信路に切り替える。また、移動前のｅＮＢ８１と第２Ｕ－Ｐｌａｎｅ制御ノード２２２との通信路は、ｅＮＢ８２と第５Ｕ－Ｐｌａｎｅ制御ノード２５２との通信路に切り替える。なお、スライスＳＬ４，ＳＬ５に係る情報は、Ｃ－Ｐｌａｎｅ制御ノード３０５がＤＮＳ（Domain Name System）サーバ３５０に対して問い合わせをすることで取得する点は、第１実施形態と同様である。

このようなケースにおける具体的な処理の手順について、図２０を参照しながら説明する。

まず、ＵＥ９０の移動前のｅＮＢ８１と移動先のｅＮＢ８２との間でハンドオーバに係る信号の送受信が行われる（HO Request, HO Request ACK：Ｓ６０１）。この信号を契機として、ＵＥ９０，ｅＮＢ８１，ｅＮＢ８２の間でハンドオーバに係る処理が行われる（Handover Execution：Ｓ６０２）。

この後、移動先のｅＮＢ８２から、Ｃ－Ｐｌａｎｅ制御ノード３０５に対して、通信路の変更に係る要求を行う信号が送信される（Path Switch Request：Ｓ６０３：変更要求取得ステップ）。

通信路の変更に係る要求には、ＵＥ９０を特定する情報と、通信路を特定する情報（TU-1, TU-2）及びセッションを特定する（S-ID1, S-ID2）が含まれる。Ｃ－Ｐｌａｎｅ制御ノード３０５の変更要求取得部３１０において、ｅＮＢ８２からの要求を受信すると、判定部３２０では、通信路の変更に係る要求に含まれる情報により、ＵＥ９０が２つのスライスとの間で通信路を設けているか否かを判定する（Ｓ６０４：判定ステップ）。判定部３２０において、ＵＥ９０に関して複数の通信路が設けられていると判定された場合には、図１９に示す以下の処理を行う。なお、判定部３２０において、ＵＥ９０に関して複数の通信路が設けられていない、すなわち、ＵＥ９０に関して、１つのスライスとの間にのみ通信路が設けられている、もしくは、通信路が設けられていないと判定された場合には、公知のハンドオーバに係る処理が行われる。

さらに、判定部３２０では、２つのスライスＳＬ１，ＳＬ２がｅＮＢ８２の管轄するエリアをカバーしていないことを確認する（Ｓ６０４）。

判定部３２０において、ＵＥ９０に関して複数の通信路が設けられていて、且つ、スライスＳＬ１，ＳＬ２がｅＮＢ８２の管轄するエリアをカバーしていないことが確認された場合、Ｃ－Ｐｌａｎｅ制御ノード３０５の通信処理部３３０は、ＤＮＳサーバ３５０に対して、ｅＮＢ８２を介して通信路を設ける際のスライスに係る情報を問い合わせる（DNS Query Request/Response：Ｓ６０５：通信処理ステップ）。より具体的には、ｅＮＢ８２を介してサービスＳ１，Ｓ２を利用する際に通信を行うことができるＣ－Ｐｌａｎｅ制御ノードを特定する情報を取得する。この結果、通信処理部３３０では、ＤＮＳサーバ３５０から取得されるＣ－Ｐｌａｎｅ制御ノードに係る情報から、ｅＮＢ８２間でユーザデータを送受信しようしているサービスサーバのＡＰＮ（Access Point Name）と、ＵＥ９０の位置（すなわちアクセスするｅＮＢ８２の情報）とに基づいて、サービスＳ１を利用するために通信路を設けるべきスライス（ここでは、スライスＳＬ４）のＵ－Ｐｌａｎｅ制御ノード２４２と、サービスＳ２を利用するために通信路を設けるべきスライス（ここでは、スライスＳＬ５）のＵ－Ｐｌａｎｅ制御ノード２５２と、が特定される（Ｓ６０６：通信処理ステップ）。

通信処理部３３０では、特定された２つのＵ－Ｐｌａｎｅ制御ノード、すなわち、第４Ｕ－Ｐｌａｎｅ制御ノード２４２及び第５Ｕ－Ｐｌａｎｅ制御ノード２５２に対して、ＵＥ９０に係る新たなセッションを設けるための要求を送信する（Create Session Request：Ｓ６０７、Ｓ２０８：通信処理ステップ）。セッションの作成要求には、アクセス先のｅＮＢ８２を特定する情報（eNB ID）と、セッションの作成により設けられる通信路を特定する情報（TU-1もしくはTU-2）と、が含まれる。なお、２つのノードへのセッションの作成要求の送信順序（Ｓ６０７，Ｓ６０８）は、変更することができる。

第４Ｕ－Ｐｌａｎｅ制御ノード２４２では、セッションの作成要求を受信すると、当該要求に基づいて、通信路の作成に係る処理を行った後、自ノードを特定する情報（UP2 ID）と共に、通信路を作成する処理を行ったことをＣ－Ｐｌａｎｅ制御ノード３０５に対して通知する（Create Session Response：Ｓ６０９：通信処理ステップ）。第５Ｕ－Ｐｌａｎｅ制御ノード２５２においても、セッションの作成要求を受信すると、通信路の作成に係る処理を行った後、自ノードを特定する情報（UP2 ID）と共に、通信路を作成する処理を行ったことをＣ－Ｐｌａｎｅ制御ノード３０５に対して通知する（Create Session Response：Ｓ６１０：通信処理ステップ）。

なお、スライスＳＬ４での処理と、スライスＳＬ５での処理は個別に行われるため、上記の処理（Ｓ６０７～Ｓ６１０）の順序は、図２０に示す順序とは異なる可能性がある。

Ｃ－Ｐｌａｎｅ制御ノード３０５では、第４Ｕ－Ｐｌａｎｅ制御ノード２４２からの応答（Ｓ６０９）と、第５Ｕ－Ｐｌａｎｅ制御ノード２５２からの応答（Ｓ６１０）と、を受信すると、ｅＮＢ８２に対して、通信路の変更に係る処理が終了したことを通知する（Path Switch Request ack：Ｓ６１１：通信処理ステップ）。この信号には、第４Ｕ－Ｐｌａｎｅ制御ノード２４２を特定する情報（UP2 ID）と、第５Ｕ－Ｐｌａｎｅ制御ノード２５２を特定する情報（UPX2 ID）とが含まれる。この情報に基づいて、ｅＮＢ８２は、通信路の相手方となるノードを特定することができる。

その後、ｅＮＢ８２からｅＮＢ８１に対して、通信路に係るリソースの開放を指示する（Release Resource：Ｓ６１２）。また、Ｃ－Ｐｌａｎｅ制御ノード３０５は、ｅＮＢ８１との間で通信路を設けていたスライスＳＬ１の第１Ｕ－Ｐｌａｎｅ制御ノード２１２と、スライスＳＬ２の第２Ｕ－Ｐｌａｎｅ制御ノード２２２に対して、セッションの開放を指示して、セッションの開放処理を行う（Delete Session Request/Response：Ｓ６１３，Ｓ６１４：通信処理ステップ）。ｅＮＢ８２からｅＮＢ８１へのリソースの開放指示（Ｓ６１２）と、Ｃ－Ｐｌａｎｅ制御ノード３０５からのセッション開放指示（Ｓ６１３，Ｓ６１４）とは、順序が入れ替わっていても良い。

以上の処理により、ＵＥ９０は、ｅＮＢ８２を経由して第４Ｕ－Ｐｌａｎｅ制御ノード２４２との間でユーザデータの送受信が可能となる（Ｓ６１５）と共に、ｅＮＢ８２を経由して第５Ｕ－Ｐｌａｎｅ制御ノード２５２との間でユーザデータの送受信が可能となる（Ｓ６１６）。これにより、ＵＥ９０は、ｅＮＢ８２を経由してサービスＳ１，Ｓ２を利用することが可能となる。

上記の処理では、ｅＮＢ８２と、第４Ｕ－Ｐｌａｎｅ制御ノード２４２及び第５Ｕ－Ｐｌａｎｅ制御ノード２５２との間の通信路が設けられた時点（Ｓ６１１）では、ｅＮＢ８１側での通信路に係るリソースが開放されていない。したがって、変更前の通信路と変更後の通信路とが両立する状態が設けられた上で、通信路の変更に係る処理が行われる。

すなわち、変更後の通信路を設ける処理を行った後、変更前の通信路の開放に係る処理が行われる。このようにして、変更前の通信路と変更後の通信路とが両立する状態が設けられる。

（第３：１つのスライスとの間で通信路を設けるケースであって、ＤＮＳサーバから情報を取得することができる場合）
図２１は、第３のケースの状況を説明する図である。図２１に示すケースは、例えば、ＵＥ９０がエリアＳＡ＃１からエリアＳＡ＃２へ移動をする場合である。この場合、ＵＥ９０が通信をする際の基地局装置は、ハンドオーバによりｅＮＢ８１からｅＮＢ８２へ変更される。また、サービスＳ１，Ｓ２を利用するために通信を行うスライスを変更する必要がある。ただし、移動先のエリアＳＡ＃２では、スライスＳＬ１に対応するスライスＳＬ４は存在するが、スライスＳＬ２に対応するスライスが存在しない場合である。第３のケースでは、移動前のｅＮＢ８１と第１Ｕ－Ｐｌａｎｅ制御ノード２１２との通信路と、移動前のｅＮＢ８１と第２Ｕ－Ｐｌａｎｅ制御ノード２２２との通信路と、の両方の機能を、ｅＮＢ８２と第４Ｕ－Ｐｌａｎｅ制御ノード２４２との通信路に切り替える。

なお、Ｃ－Ｐｌａｎｅ制御ノード３０５がＤＮＳサーバ３５０及びＳＳＦ７０に対して問い合わせをすることで、サービスＳ１，Ｓ２を利用するための通信路を設けるスライスと特定する情報を取得する点は、第１実施形態と同様である。

上記のような第３のケースにおける具体的な処理の手順について、図２２を参照しながら説明する。

まず、ＵＥ９０の移動前のｅＮＢ８１と移動先のｅＮＢ８２との間でハンドオーバに係る信号の送受信が行われる（HO Request, HO Request ACK：Ｓ７０１）。この信号を契機として、ＵＥ９０，ｅＮＢ８１，ｅＮＢ８２の間でハンドオーバに係る処理が行われる（Handover Execution：Ｓ７０２）。

この後、移動先のｅＮＢ８２から、Ｃ－Ｐｌａｎｅ制御ノード３０５に対して、通信路の変更に係る要求を行う信号が送信される（Path Switch Request：Ｓ７０３：変更要求取得ステップ）。

通信路の変更に係る要求には、ＵＥ９０を特定する情報と、通信路を特定する情報（TU-1, TU-2）及びセッションを特定する（S-ID1, S-ID2）が含まれる。Ｃ－Ｐｌａｎｅ制御ノード３０５の変更要求取得部３１０において、ｅＮＢ８２からの要求を受信すると、判定部３２０では、通信路の変更に係る要求に含まれる情報により、ＵＥ９０が２つのスライスとの間で通信路を設けているか否かを判定する（Ｓ７０４：判定ステップ）。判定部３２０において、ＵＥ９０に関して複数の通信路が設けられていると判定された場合には、図２２に示す以下の処理を行う。なお、判定部３２０において、ＵＥ９０に関して複数の通信路が設けられていない、すなわち、ＵＥ９０に関して、１つのスライスとの間にのみ通信路が設けられている、もしくは、通信路が設けられていないと判定された場合には、公知のハンドオーバに係る処理が行われる。

さらに、判定部３２０では、２つのスライスＳＬ１，ＳＬ２がｅＮＢ８２の管轄するエリアをカバーしていないことを確認する（Ｓ７０４）。この点は第２のケースと同様である。

判定部３２０において、ＵＥ９０に関して複数の通信路が設けられていて、且つ、スライスＳＬ１，ＳＬ２がエリアＳＡ＃２をカバーしていないことが確認された場合、Ｃ－Ｐｌａｎｅ制御ノード３０５の通信処理部３３０は、ＤＮＳサーバ３５０に対して、ｅＮＢ８２を介して通信路を設ける際のスライスに係る情報を問い合わせる（DNS Query Request：Ｓ７０５：通信処理ステップ）。より具体的には、通信処理部３３０は、ＤＮＳサーバ３５０に対して、ＥＣＧＩ（E-UTRAN Cell Global ID）もしくはサービスＳ１，Ｓ２を提供するサービスサーバのＡＰＮ（APN1&2）を送信することで、サービスＳ１，Ｓ２を利用する際に通信を行うべきスライスのＵ－Ｐｌａｎｅ制御ノードを特定する情報を取得する。

第３のケースの場合には、ＤＮＳサーバ３５０から送信される結果には、１つのＵ－Ｐｌａｎｅ制御ノードを特定する情報のみが返送される（DNS Query Response：Ｓ７０６：通信処理ステップ）。ここでは、第４Ｕ－Ｐｌａｎｅ制御ノード２４２を特定する情報がＤＮＳサーバ３５０からＣ－Ｐｌａｎｅ制御ノード３０５に対して送られる。これにより、Ｃ－Ｐｌａｎｅ制御ノード３０５では、第４Ｕ－Ｐｌａｎｅ制御ノード２４２が含まれるスライスＳＬ４との間で２つのサービスに係るセッションを設けることを決定する（Selects UP2 for both APN1&2 Sessions：Ｓ７０９：通信処理ステップ）。

なお、ＤＮＳサーバ３５０が保持している情報では、ＵＥ９０の在圏するエリアにおいてサービスＳ１，Ｓ２に対応することができるスライスを特定することができない場合がある。この場合には、第１実施形態と同様に、Ｃ－Ｐｌａｎｅ制御ノード３０５の通信処理部３３０は、ＳＳＦ７０に対してＵＥ９０を特定する情報と、利用したいサービスを特定する情報（APN1&APN2）と、ＥＣＧＩとを送信して、問い合わせを行う（Policy Request：Ｓ７０７：通信処理ステップ）。これにより、ＳＳＦ７０では、Ｃ－Ｐｌａｎｅ制御ノード３０５から送信されるサービスを特定する情報に応じて、対応するスライスの情報を提供する（Policy Response：Ｓ７０８：通信処理ステップ）。ここでは、スライスＳＬ４を特定する情報として、第４Ｕ－Ｐｌａｎｅ制御ノード２４２を特定する情報が提供される。

そして、Ｃ－Ｐｌａｎｅ制御ノード３０５では、ＤＮＳサーバ３５０からの情報と、ＳＳＦ７０からの情報とに基づいて、第４Ｕ－Ｐｌａｎｅ制御ノード２４１が含まれるスライスＳＬ４との間で２つのサービスに係るセッションを設けることを決定する（Selects UP2 for both APN1&2 Sessions：Ｓ７０９：通信処理ステップ）。

このように、ＤＮＳサーバ３５０が保持する情報だけでは、適切なスライス（Ｕ－Ｐｌａｎｅ制御ノード）を選択することができない場合には、ＳＳＦ７０がサービスに対応したスライスを特定する情報を保持する構成として、Ｃ－Ｐｌａｎｅ制御ノード３０５がＳＳＦ７０にも問い合わせを行うことで、２つのサービスを利用するための適切なスライス（Ｕ－Ｐｌａｎｅ制御ノード）を特定する構成としてもよい。この点も第１の実施形態と同様である。

なお、ＤＮＳサーバ３５０及びＳＳＦ７０が、利用したいサービスを特定する情報（APN1&APN2）に対して適切なスライスを特定する情報を提供できない場合には、サービスの提供ができないため、サービスの提供自体が中断される。

通信処理部３３０では、ここまでの処理により特定されたＵ－Ｐｌａｎｅ制御ノード、すなわち、第４Ｕ－Ｐｌａｎｅ制御ノード２４２に対して、ＵＥ９０に係る新たなセッションを設けるための要求を送信する（Create Session Request：Ｓ７１０：通信処理ステップ）。セッションの作成要求には、アクセス先のｅＮＢ８２を特定する情報（eNB ID）と、セッションの作成により設けられる通信路を特定する情報（TU-1及びTU-2）と、サービスを特定する情報（APN1及びAPN2）が含まれる。これにより、第４Ｕ－Ｐｌａｎｅ制御ノード２４２においても、２つのサービスに係るセッションを開設することが認識される。

第４Ｕ－Ｐｌａｎｅ制御ノード２４２では、通信路の作成に係る処理を行った後、通信路を特定する情報（TU-1及びTU-2）及び自ノードを特定する情報（UP2 ID）と共に、通信路を作成する処理を行ったことをＣ－Ｐｌａｎｅ制御ノード３０５に対して通知する（Create Session Response：Ｓ７１１：通信処理ステップ）。

Ｃ－Ｐｌａｎｅ制御ノード３０５では、第４Ｕ－Ｐｌａｎｅ制御ノード２４２からの応答（Ｓ７１１）を受信すると、ｅＮＢ８２に対して、通信路の変更に係る処理が終了したことを通知する（Path Switch Request ack：Ｓ７１２：通信処理ステップ）。この信号には、第４Ｕ－Ｐｌａｎｅ制御ノード２４２を特定する情報（UP2 ID）に対応付けて、２つの通信路を特定する情報（TU-1, TU-2）と、２つのセッションを特定する情報（S-ID1, S-ID2）が含まれる。この情報に基づいて、ｅＮＢ８２は、通信路の相手方となるノードを特定することができる。

その後、ｅＮＢ８２からｅＮＢ８１に対して、通信路に係るリソースの開放を指示する（Release Resource：Ｓ７１３）。また、Ｃ－Ｐｌａｎｅ制御ノード３０５は、ｅＮＢ８１との間で通信路を設けていたスライスＳＬ１の第１Ｕ－Ｐｌａｎｅ制御ノード２１２と、スライスＳＬ２の第２Ｕ－Ｐｌａｎｅ制御ノード２２２に対して、セッションの開放を指示して、セッションの開放処理を行う（Delete Session Request/Response：Ｓ７１４，Ｓ７１５：通信処理ステップ）。ｅＮＢ８２からｅＮＢ８１へのリソースの開放指示（Ｓ７１３）と、Ｃ－Ｐｌａｎｅ制御ノード３０５からのセッション開放指示（Ｓ７１４，Ｓ７１５）は、順序が入れ替わっていても良い。

以上の処理により、ＵＥ９０は、ｅＮＢ８２を経由して第４Ｕ－Ｐｌａｎｅ制御ノード２４２との間でユーザデータの送受信が可能となることで、ｅＮＢ８２を経由してサービスＳ１，Ｓ２を利用することが可能となる（Ｓ７１６）。

なお、上記の第３のケースでは、移動先のエリアＳＡ＃２では、スライスＳＬ１に対応するスライスＳＬ４は存在するが、スライスＳＬ２に対応するスライスが存在しない場合、として説明したが、逆の場合であってもよい。すなわち、スライスＳＬ１に対応するスライスは存在しないが、スライスＳＬ２に対応するスライスＳＬ５が存在する場合も、上記で説明した処理と同様の方法で処理を行うことができる。

上記の処理では、ｅＮＢ８２と、第４Ｕ－Ｐｌａｎｅ制御ノード２４２との間の通信路が設けられた時点（Ｓ７１２）では、ｅＮＢ８１側での通信路に係るリソースが開放されていない。したがって、変更前の通信路と変更後の通信路とが両立する状態が設けられた上で、通信路の変更に係る処理が行われる。

すなわち、変更後の通信路を設ける処理を行った後、変更前の通信路の開放に係る処理が行われる。このようにして、変更前の通信路と変更後の通信路とが両立する状態が設けられる。

（第４：１つのスライスとの間で通信路を設けるケースであって、ＳＳＦから情報を取得することができる場合）
図２３は、第４のケースの状況を説明する図である。図２３に示すケースは、第３のケースと同様に、ＵＥ９０がエリアＳＡ＃１からエリアＳＡ＃２へ移動をする場合である。ただし、移動先のエリアＳＡ＃２では、スライスＳＬ１，ＳＬ２に対応するスライスが特定されておらず、第３のケースと同様にＤＮＳサーバ３５０に対して問い合わせを行った場合に、ＤＮＳサーバ３５０からＣ－Ｐｌａｎｅ制御サーバに係る情報を取得できない場合である。第４のケースでは、２つのサービスとは関連性がないスライスＳＬ６に設けられた第６Ｕ－Ｐｌａｎｅ制御ノード（ＵＰＹ）２６２との通信路に切り替える。

なお、Ｃ－Ｐｌａｎｅ制御ノード３０５がＤＮＳサーバ３５０及びＳＳＦ７０に対して問い合わせをすることで、サービスＳ１，Ｓ２を利用するための通信路を設けるスライスと特定する情報を取得する点は、第１実施形態と同様である。

上記のような第４のケースにおける具体的な処理の手順について、図２４を参照しながら説明する。

まず、ＵＥ９０の移動前のｅＮＢ８１と移動先のｅＮＢ８２との間でハンドオーバに係る信号の送受信が行われる（HO Request, HO Request ACK：Ｓ８０１）。この信号を契機として、ＵＥ９０，ｅＮＢ８１，ｅＮＢ８２の間でハンドオーバに係る処理が行われる（Handover Execution：Ｓ８０２）。

この後、移動先のｅＮＢ８２から、Ｃ－Ｐｌａｎｅ制御ノード３０５に対して、通信路の変更に係る要求を行う信号が送信される（Path Switch Request：Ｓ８０３：変更要求取得ステップ）。

通信路の変更に係る要求には、ＵＥ９０を特定する情報と、通信路を特定する情報（TU-1, TU-2）及びセッションを特定する（S-ID1, S-ID2）が含まれる。Ｃ－Ｐｌａｎｅ制御ノード３０５の変更要求取得部３１０において、ｅＮＢ８２からの要求を受信すると、判定部３２０では、通信路の変更に係る要求に含まれる情報により、ＵＥ９０が２つのスライスとの間で通信路を設けているか否かを判定する（Ｓ８０４：判定ステップ）。判定部３２０において、ＵＥ９０に関して複数の通信路が設けられていると判定された場合には、図２４に示す以下の処理を行う。なお、判定部３２０において、ＵＥ９０に関して複数の通信路が設けられていない、すなわち、ＵＥ９０に関して、１つのスライスとの間にのみ通信路が設けられている、もしくは、通信路が設けられていないと判定された場合には、公知のハンドオーバに係る処理が行われる。

さらに、判定部３２０では、２つのスライスＳＬ１，ＳＬ２がｅＮＢ８２の管轄するエリアをカバーしていないことを確認する（Ｓ８０４）。この点は第２のケースと同様である。

判定部３２０において、ＵＥ９０に関して複数の通信路が設けられていて、且つ、スライスＳＬ１，ＳＬ２がエリアSA#２をカバーしていないことが確認された場合、Ｃ－Ｐｌａｎｅ制御ノード３０５の通信処理部３３０は、ＤＮＳサーバ３５０に対して、ｅＮＢ８２を介して通信路を設ける際のスライスに係る情報を問い合わせる（DNS Query Request：Ｓ８０５：通信処理ステップ）。より具体的には、通信処理部３３０は、ＤＮＳサーバ３５０に対して、ＥＣＧＩ（E-UTRAN Cell Global ID）もしくはサービスＳ１，Ｓ２を提供するサービスサーバのＡＰＮ（APN1&2）を送信することで、サービスＳ１，Ｓ２を利用する際に通信を行うべきスライスのＵ－Ｐｌａｎｅ制御ノードを特定する情報を取得する。

第４のケースでは、ｅＮＢ８２の管轄するエリアＳＡ＃２は、図１３（Ａ）に示す表には含まれない状態となっている。すなわち、location及びサービスの種類に対して、アクセス先（通信路を設ける先）のスライスを特定する情報が対応付けられていない状態である。したがって、ＤＮＳサーバ３５０は、Ｃ－Ｐｌａｎｅ制御ノード３０５に対して、サービスに対応するスライスが存在しないことを示す情報、すなわち、Ｃ－Ｐｌａｎｅ制御ノードの情報がないことを通知する（DNS Query Response：Ｓ８０６：通信処理ステップ）。

このように、ＤＮＳサーバ３５０からＣ－Ｐｌａｎｅ制御ノードを特定する情報が提供されない場合、Ｃ－Ｐｌａｎｅ制御ノード３０５側では、ＵＥ９０がサービスＳ１，Ｓ２を利用するためにｅＮＢ８２との間で通信路を設ける相手方のスライスを特定することができないことになる。そこで、Ｃ－Ｐｌａｎｅ制御ノード３０５の通信処理部３３０では、ＳＳＦ７０に対してＵＥ９０を特定する情報と、利用したいサービスを特定する情報（APN1&APN2）と、ＥＣＧＩとを送信して、問い合わせを行う（Policy Request：Ｓ８０７：通信処理ステップ）。

これに対して、ＳＳＦ７０は、利用したいサービスを特定する情報と、ＥＧＣＩとに基づいて、自装置で保持している情報に基づいて、ＵＥ９０の在圏するエリアにおいて、当該サービスを利用するための通信路を設けることができるスライスを特定し、対応するスライスの情報を提供する（Policy Response：Ｓ８０８：通信処理ステップ）。

Ｃ－Ｐｌａｎｅ制御ノード３０５では、ＳＳＦ７０からの情報に基づいて、第６Ｕ－Ｐｌａｎｅ制御ノード２６２が含まれるスライスＳＬ６との間で２つのサービスに係るセッションを設けることを決定する（Selects UPY for both APN1&2 Sessions：Ｓ８０９：通信処理ステップ）。

なお、ＤＮＳサーバ３５０及びＳＳＦ７０が、利用したいサービスを特定する情報（APN1&APN2）に対して適切なスライスを特定する情報を提供できない場合には、サービスの提供ができないため、サービスの提供自体が中断される。

通信処理部３３０では、ここまでの処理により特定されたＣ－Ｐｌａｎｅ制御ノード、すなわち、第６Ｕ－Ｐｌａｎｅ制御ノード２６２に対して、ＵＥ９０に係る新たなセッションを設けるための要求を送信する（Create Session Request：Ｓ８１０）。セッションの作成要求には、アクセス先のｅＮＢ８２を特定する情報（eNB ID）と、セッションの作成により設けられる通信路を特定する情報（TU-1及びTU-2）と、サービスを特定する情報（APN1及びAPN2）が含まれる。これにより、第６Ｕ－Ｐｌａｎｅ制御ノード２６２においても、２つのサービスに係るセッションを開設することが認識される。

第６Ｕ－Ｐｌａｎｅ制御ノード２６２では、セッションの作成要求を受信すると、通信路の作成に係る処理を行った後、通信路を特定する情報（TU-1及びTU-2）及び自ノードを特定する情報（UP2 ID）と共に、通信路を作成する処理を行ったことをＣ－Ｐｌａｎｅ制御ノード３０５に対して通知する（Create Session Response：Ｓ８１１：通信処理ステップ）。

Ｃ－Ｐｌａｎｅ制御ノード３０５では、第６Ｕ－Ｐｌａｎｅ制御ノード２６２からの応答（Ｓ８１１）を受信すると、ｅＮＢ８２に対して、通信路の変更に係る処理が終了したことを通知する（Path Switch Request ack：Ｓ８１２：通信処理ステップ）。この信号には、第６Ｕ－Ｐｌａｎｅ制御ノード２６２を特定する情報（UPY ID）に対応付けて、２つの通信路を特定する情報（TU-1, TU-2）と、２つのセッションを特定する情報（S-ID1, S-ID2）が含まれる。この情報に基づいて、ｅＮＢ８２は、通信路の相手方となるノードを特定することができる。

その後、ｅＮＢ８２からｅＮＢ８１に対して、通信路に係るリソースの開放を指示する（Release Resource：Ｓ８１３）。また、Ｃ－Ｐｌａｎｅ制御ノード３０５は、ｅＮＢ８１との間で通信路を設けていたスライスＳＬ１の第１Ｕ－Ｐｌａｎｅ制御ノード２１２と、スライスＳＬ２の第２Ｕ－Ｐｌａｎｅ制御ノード２２２に対して、セッションの開放を指示して、セッションの開放処理を行う（Delete Session Request/Response：Ｓ８１４，Ｓ８１５：通信処理ステップ）。ｅＮＢ８２からｅＮＢ８１へのリソースの開放指示（Ｓ８１３）と、Ｃ－Ｐｌａｎｅ制御ノード３０５からのセッション開放指示（Ｓ８１４，Ｓ８１５）は、順序が入れ替わっていても良い。

以上の処理により、ＵＥ９０は、ｅＮＢ８２を経由して第６Ｕ－Ｐｌａｎｅ制御ノード２６２との間でユーザデータの送受信が可能となることで、ｅＮＢ８２を経由してサービスＳ１，Ｓ２を利用することが可能となる（Ｓ８１６）。

上記の処理では、ｅＮＢ８２と、第６Ｕ－Ｐｌａｎｅ制御ノード２６２との間の通信路が設けられた時点（Ｓ８１２）では、ｅＮＢ８１側での通信路に係るリソースが開放されていない。したがって、変更前の通信路と変更後の通信路とが両立する状態が設けられた上で、通信路の変更に係る処理が行われる。

すなわち、変更後の通信路を設ける処理を行った後、変更前の通信路の開放に係る処理が行われる。このようにして、変更前の通信路と変更後の通信路とが両立する状態が設けられる。

以上のように、第２実施形態に係る通信制御装置であるＣ－Ｐｌａｎｅ制御ノード３０５及びこのＣ－Ｐｌａｎｅ制御ノード３０５による通信制御方法においても、上記の４つのケースに共通するが、変更前の通信路と変更後の通信路とが両立した状態を設けながら、通信路の変更に係る処理が行われる。このため、ＵＥ９０は、変更前の通信路もしくは変更後の通信路を利用してユーザデータを送受信可能な状態を保つことができる。したがって、複数のスライスに割り当てられているサービスを利用しながら、複数のスライスとの間に設けられる通信路を変更することが実現される。

また、上記の４つのケースに共通して、変更後の通信路を設ける処理を行った後、変更前の通信路の開放に係る処理が行われる。このようにすることで、ＵＥ９０が複数のスライスに対して接続している状態であっても、変更前の通信路と変更後の通信路とが両立する状態が設けられる。

また、第２のケースでは、変更前の複数の通信路について、それぞれ、変更前の通信路が設けられたスライスＳＬ１，ＳＬ２とは異なり、且つ、互いに異なるスライスＳＬ４，ＳＬ５におけるＵ－Ｐｌａｎｅ制御ノードに対して設けられる通信路へ変更する。このような構成であると、変更前の通信路毎に変更後も個別に通信路が設けられるため、通信路を変更した後についても、ユーザデータを好適に送受信することができる。

一方、第３のケース及び第４のケースでは、変更前の複数の通信路に対して、変更前の通信路が設けられたスライスＳＬ１，ＳＬ２とは異なるスライス（第３のケースの場合には、スライスＳＬ４であり、第４のケースの場合にはスライスＳＬ６である）におけるＵ－Ｐｌａｎｅ制御ノードに対して設けられる一つの通信路へ変更される。上記実施形態でも説明したが、変更前の複数のスライスにおける制御ノードそれぞれに対して個別に通信路に対応した通信路を設けることができないようなケースが存在する。この場合には、上記のように、変更前の複数の通信路を、１つのスライスの制御ノードに対して設けられる１つの通信路にまとめる構成とすることで、通信路を変更した後についても、複数のサービスに係るユーザデータを好適に送受信することができる。

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

情報の通知は、本明細書で説明した態様／実施形態に限られず、他の方法で行われてもよい。例えば、情報の通知は、物理レイヤシグナリング（例えば、ＤＣＩ（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）からなるネットワークにおいて、端末との通信のために行われる様々な動作は、基地局および／または基地局以外の他のネットワークノードによって行われ得ることは明らかである。上記において基地局以外の他のネットワークノードが１つである場合を例示したが、複数の他のネットワークノードの組み合わせであってもよい。

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

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

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

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

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

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

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

なお、本明細書で説明した用語及び／又は本明細書の理解に必要な用語については、同一の又は類似する意味を有する用語と置き換えてもよい。例えば、信号はメッセージであってもよい。

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

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

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

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

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

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

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

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

本明細書で「第１の」、「第２の」などの呼称を使用した場合においては、その要素へのいかなる参照も、それらの要素の量または順序を全般的に限定するものではない。これらの呼称は、２つ以上の要素間を区別する便利な方法として本明細書で使用され得る。したがって、第１および第２の要素への参照は、２つの要素のみがそこで採用され得ること、または何らかの形で第１の要素が第２の要素に先行しなければならないことを意味しない。

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

本明細書において、文脈または技術的に明らかに1つのみしか存在しない装置である場合以外は、複数の装置をも含むものとする。

本開示の全体において、文脈から明らかに単数を示したものではなければ、複数のものを含むものとする。

８０，８１，８２…ｅＮＢ、９０…ＵＥ、２１１，２２１，２４１，２５１，２６１，３０５…Ｃ－Ｐｌａｎｅ制御ノード、２１２，２２２，２４２，２５２，２６２…Ｕ－Ｐｌａｎｅ制御ノード、３０１…共通Ｃ－Ｐｌａｎｅ制御ノード、ＳＬ１～ＳＬ６…スライス。

Claims (2)

1. ネットワークインフラ上に生成される仮想化ネットワークである一又は複数のスライスに設けられた第１制御ノードに対して第１通信路を設けると共に、第１制御ノードとは異なる第２制御ノードに対して第２通信路を設け、前記第１通信路及び前記第２通信路を介してユーザデータを送受信するユーザ端末に係る通信制御を行う通信制御装置であって、
   前記ユーザ端末に係る前記第１通信路及び前記第２通信路の変更に係る変更要求を取得する変更要求取得部と、
   変更前の前記第１通信路及び前記第２通信路と変更後の通信路とが両立した状態を設けながら、前記第１通信路及び前記第２通信路の変更に係る処理を行う通信処理部と、
   を有し、
   前記通信処理部は、前記変更後の通信路を開設する処理を行って開設が完了した後に、変更前の前記第１通信路及び前記第２通信路の開放に係る処理を行うことで、変更前の前記第１通信路及び前記第２通信路と前記変更後の通信路とが両立した状態を設け、
   前記通信処理部は、変更前の前記第１制御ノード及び前記第２制御ノードとは異なる第３制御ノードに対して設けられる前記変更後の通信路へ変更し、
   変更前の前記第１通信路及び前記第２通信路の両方の機能を前記変更後の通信路に切り替え、且つ、前記変更後の通信路の数は、前記第１通信路及び前記第２通信路の数の合計よりも少ない、通信制御装置。
2. ネットワークインフラ上に生成される仮想化ネットワークである一又は複数のスライスに設けられた第１制御ノードに対して第１通信路を設けると共に、第１制御ノードとは異なる第２制御ノードに対して第２通信路を設け、前記第１通信路及び前記第２通信路を介してユーザデータを送受信するユーザ端末に係る通信制御を行う通信制御装置による通信制御方法であって、
   前記ユーザ端末に係る前記第１通信路及び前記第２通信路の変更に係る変更要求を取得する変更要求取得ステップと、
   変更前の前記第１通信路及び前記第２通信路と変更後の通信路とが両立した状態を設けながら、前記第１通信路及び前記第２通信路の変更に係る処理を行う通信処理ステップと、
   を有し、
   前記通信処理ステップにおいて、前記変更後の通信路を開設する処理を行って開設が完了した後に、変更前の前記第１通信路及び前記第２通信路の開放に係る処理を行うことで、変更前の前記第１通信路及び前記第２通信路と前記変更後の通信路とが両立した状態を設け、
   前記通信処理ステップにおいて、変更前の前記第１制御ノード及び前記第２制御ノードとは異なる第３制御ノードに対して設けられる前記変更後の通信路へ変更し、
   変更前の前記第１通信路及び前記第２通信路の両方の機能を前記変更後の通信路に切り替え、且つ、前記変更後の通信路の数は、前記第１通信路及び前記第２通信路の数の合計よりも少ない、通信制御方法。

Images