CN109565734B - 通信控制装置及通信控制方法 - Google Patents

Abstract

作为通信控制装置的公共C‑Plane控制节点(301)具有：变更请求取得部(310)，其取得与作为用户终端的UE90的通信路径的变更相关的变更请求；判定部(320)，其根据变更请求取得部(310)取得的变更请求中所包含的信息，判定与该变更请求相关的UE90是否对多个切片中的控制节点分别设置了所述通信路径；以及通信处理部(330)，其在由判定部(320)判定为与变更请求相关的UE90对多个所述切片分别设置了通信路径的情况下，针对对多个切片中的所述控制节点设置的多个通信路径中的各个通信路径，一边设置变更前的通信路径与变更后的通信路径并存的状态，一边进行与通信路径的变更相关的处理。

Description

通信控制装置及通信控制方法

技术领域

本发明涉及一种通信控制装置及通信控制方法。

背景技术

在使用以往的虚拟化技术的网络***中，使用非专利文献1中公开的虚拟化技术，虚拟地划分硬件资源，生成作为在网络基础设施上逻辑地生成的虚拟网络的切片(slice)。并且，通过向该切片分配服务，从而能够使用分别独立的切片的网络对用户所使用的用户终端提供服务。由此，在对具有多种多样的要求条件的各服务分别分配切片的情况下，能够容易地满足各服务的要求条件，减轻其信令处理等。此外，在利用由用户终端对各切片分配的服务的情况下，通过对设置于切片的控制节点设置与该用户终端相关的通信路径，从而经由通信路径来进行用户数据的收发。

现有技术文献

非专利文献

非专利文献1：中尾彰宏、″仮想化ノード·プロジェクト新世代のネットワークをめざす仮想化技術″、[online]、2010年6月、独立行政法人情報通信研究機構、[2016年8月10日检索]、internet<http://www.nict.go.jp/publication/NICT-News/1006/01.html>

发明内容

发明要解决的问题

然而，有时会需要一边利用由用户终端对各切片分配的服务，一边由于某些情况而变更与该用户终端相关的通信路径。特别是，以往还没有研究过在该用户终端接入多个切片而收发用户数据的情况下，一边利用服务、一边变更通信路径。

本发明是鉴于上述情况而完成的，其目的在于提供一种通信控制装置及通信控制方法，能够一边利用分配给多个切片的服务，一边变更在与多个切片之间设置的通信路径。

用于解决问题的手段

为了达到上述目的，本发明的一个方式的通信控制装置，其进行与用户终端相关的通信控制，所述用户终端对作为在网络基础设施上生成的虚拟化网络的一个或者多个切片中的控制节点分别设置通信路径，经由所述通信路径收发用户数据，所述通信控制装置具有：变更请求取得部，其取得与所述用户终端的所述通信路径的变更相关的变更请求；判定部，其根据所述变更请求取得部取得的所述变更请求中所包含的信息，判定与该变更请求相关的所述用户终端是否对多个所述切片中的所述控制节点分别设置了所述通信路径；以及通信处理部，其在由所述判定部判定为与所述变更请求相关的所述用户终端对多个所述切片分别设置了所述通信路径的情况下，针对对多个所述切片中的所述控制节点设置的多个所述通信路径中的各个所述通信路径，一边设置变更前的所述通信路径与变更后的所述通信路径并存的状态，一边进行与所述通信路径的变更相关的处理。

此外，本发明的一个方式的一种由通信控制装置执行的通信控制方法，所述通信控制方法进行与用户终端相关的通信控制，所述用户终端对作为在网络基础设施上生成的虚拟化网络的一个或者多个切片中的控制节点分别设置通信路径，经由所述通信路径收发用户数据，其中，所述通信控制方法具有如下步骤：变更请求取得步骤，取得与所述用户终端的所述通信路径的变更相关的变更请求；以及通信处理步骤，在根据在所述变更请求取得步骤中取得的所述变更请求中所包含的信息，判定为与所述变更请求相关的所述用户终端对多个所述切片分别设置了所述通信路径的情况下，针对对多个所述切片中的所述控制节点设置的多个所述通信路径中的各个所述通信路径，一边设置变更前的所述通信路径与变更后的所述通信路径并存的状态，一边进行与所述通信路径的变更相关的处理。

根据上述的通信控制装置及通信控制方法，在与对通信控制装置发送的变更请求相关的用户终端对多个切片中的控制节点分别设置了通信路径的情况下，针对各多个通信路径，一边设置变更前的通信路径与变更后的通信路径并存的状态，一边进行与通信路径的变更相关的处理。因此，由于用户终端能够保持利用变更前的通信路径或者变更后通信路径而能够收发用户数据的状态，因此实现了一边利用分配给多个切片的服务，一边变更设置在与多个切片之间的通信路径。

发明效果

根据本发明，提供一种通信控制装置及通信控制方法，能够一边利用分配给多个切片的服务，一边变更设置与多个切片之间的通信路径。

附图说明

图1是示出本发明的实施方式的***的结构的图。

图2是示出切片与核心网络之间的关系的图。

图3是示出切片与硬件(hard)之间的关系的图。

图4是用于说明本发明的实施方式中的技术问题的图。

图5是示出通信控制装置的功能块的图。

图6是示出通信控制装置的硬件结构的图。

图7是用于说明第1示例的状況的图。

图8是用于说明第1示例的处理的时序图。

图9是用于说明第2示例的状況的图。

图10是用于说明第2示例的处理的时序图。

图11是用于说明第3示例的状況的图。

图12是用于说明第3示例的处理的时序图。

图13是示出DNS服务器和SSF所保持的信息的示例的图。

图14是用于说明第4示例的状況的图。

图15是用于说明第4示例的处理的时序图。

图16是用于说明第2实施方式的切片与核心网络之间的关系的图。

图17是用于说明第1示例的状況的图。

图18是用于说明第1示例的处理的时序图。

图19是用于说明第2示例的状況的图。

图20是用于说明第2示例的处理的时序图。

图21是用于说明第3示例的状況的图。

图22是用于说明第3示例的处理的时序图。

图23是用于说明第4示例的状況的图。

图24是用于说明第4示例的处理的时序图。。

具体实施方式

下面参照附图对用于实施本发明的方式进行详细说明。另外，在附图说明中，对相同的要素赋予相同的标号，省略重复的说明。

(第1实施方式：具有公共C-Plane控制节点的***)

在图1中，示出了构成虚拟化的网络的***(通信***)1的结构。图1的***1通过对作为虚拟化网络的切片分配服务，从而对服务用户(Service User)所使用的终端(用户终端)即UE(User Equipment：用户装置)90提供网络服务。切片是指虚拟地划分网络装置的链路和节点的资源，联合所划分的资源，在网络基础设施上逻辑地生成的虚拟化网络或者服务网络，切片彼此之间分离资源，相互不会产生干扰。网络服务是指使用了通信服务(专线服务等)、应用服务(利用了动态图像发布、嵌入式装置等传感器装置的服务)等的网络资源的服务。此外，UE90例如是智能手机等具有通信功能的终端装置。

如图1所示，***1构成为包含BSS/OSS(Business Support System/OperationsSupport System：业务支持***/操作支持***)10、SO(Service Operator：服务运营商)2、NFVO30、VNFM40以及VIM(Virtualized Infrastructure Management：虚拟化基础管理)50。此外，构成为***1中包含NFVI(NFV(Network Functions Virtualisation:网络功能虚拟化)Infrastructure:基础设施)60、SSF(Slice Selection Function:切片选择功能)70、eNB(eNodeB)80以及UE90。其中，NFVO30、VNFM40以及VIM50为通过ETSI NFV-ISG标准化的MANO(Management&Orchestration：管理&编制)架构(architecture)的功能。

这些结构要素构成作为***1中的核心的网络。另外，相互进行信息的收发所需的结构要素之间通过有线的方式连接，能够进行信息的收发。

本实施方式的***1由在物理服务器上实现的虚拟机中进行动作的虚拟服务器对移动通信终端提供通信功能。即，***1是虚拟化的移动通信网络。由虚拟机执行与该通信功能相应的通信处理，从而对移动通信终端提供通信功能。

NFVI60表示由构成虚拟化环境的物理资源(节点群)形成的网络。该物理资源在概念上包含计算资源、存储资源、传输资源。具体来说，该物理资源构成为包含在***1中进行通信处理的物理***器装置即物理服务器、交换机等节点。物理服务器构成为具有CPU(核心、处理器)、内存以及硬盘等存储单元。通常来说，汇总多个构成NFVI60的物理服务器等节点而配置在数据中心(DC)等据点。在数据中心中，所配置的物理服务器通过数据中心内部的网络而能够进行通信，能够相互进行信息的收发。此外，***1中设置有多个数据中心。数据中心之间能够通过网络进行通信，设置于不同的数据中心的物理服务器能够经由该网络相互进行信息的收发。

SO(Service Operator，服务运营商)20是请求创建用于提供网络服务的网络的装置，例如，是使用虚拟网络对各种用户提供服务的运营商的终端装置(例如，个人计算机等)。

BSS/OSS10是进行***1中的服务管理，并进行与***1中的通信功能相关的指示的节点。例如，BSS/OSS10指示NFVO30增加新的网络服务。此外，可以由与***1相关的通信运营商操作BSS/OSS10。

NFVO30是进行在作为物理资源的NFVI60上构建的虚拟网络(切片)整体的管理的整体管理节点(功能实体)。NFVO30接收来自BSS/OSS10的指示，进行与该指示相应的处理。NFVO30对在基础设施与网络服务的移动通信网络的物理资源中构建的虚拟化网络整体进行管理。NFVO30与VNFM40及VIM50协作而在适当的场所实现由虚拟网络提供的网络服务。例如，进行网络服务的生存周期管理(具体来说，例如，网络服务的生成、更新、比例(scale)控制、事件收集)、移动通信网络内整体的资源管理，即，与资源的分布·预约·分配管理、服务·实例管理以及资源配置相关的策略管理(具体来说，例如，资源的预约·分配、基于地理·法令等的最佳配置)。

VNFM40是对作为物理资源(节点)的NFVI60追加构成网络服务的功能的虚拟通信功能管理节点(功能实体)。在***1中可以设置多个VNFM40。

VIM50是对NFVI60中的物理资源(节点)分别进行管理的物理资源管理节点(功能实体)。具体来说，进行资源的分配·更新·回收的管理、物理资源与虚拟化网络之间的关联、硬件资源与SW资源(管理程序(Hypervisor))一览的管理。通常来说，VIM50按照每个数据中心(局端)来进行管理。按照与数据中心相应的方式来进行物理资源的管理。数据中心的管理方式(管理资源的安装方式)有OPENSTACK、vCenter等种类。通常来说，按照数据中心的每种管理方式来设置VIM50。即，包含多个按照相互不同的方式对NFVI60中的物理资源分别进行管理的VIM50。另外，按照不同的管理方式进行管理的物理资源的单位不一定以数据中心为单位。

另外，通过在物理***器装置上执行程序从而实现NFVO30、VNFM40以及VIM50(但是，不限于通过虚拟化实现，可以在将管理***分离了的基础上，通过虚拟化实现)。对于NFVO30、VNFM40以及VIM50，可以分别通过不同的物理***器装置来实现，也可以通过相同的服务器装置来实现。可以分别从不同的供应商提供NFVO30、VNFM40以及VIM50(用于实现NFVO30、VNFM40以及VIM50的程序)。

当接收到来自BSS/OSS10的网络服务创建请求时，NFVO30对VIM50进行用于切片(切片SL1、SL2等)的资源确保请求。当VIM50确保了构成NFVI60的服务器装置、交换机(switch)中的资源时，NFVO30对该这些NFVI60定义切片。

此外，当使VIM50在NFVI60中进行了资源确保时，NFVO30将对该NFVI60定义了切片的信息存储于NFVO30所存储的表中。并且，NFVO30对VNFM40进行软件的安装请求，该软件用于实现该网络服务所需的功能。VNFM40根据该安装请求，对由VIM50确保的NFVI60(服务器装置、交换装置或者路由器装置等节点)安装上述软件。

当通过VNFM40安装了软件时，NFVO30对NFVO30所存储的表进行切片与网络服务之间的关联。

具体来说，在NFVO30中，如图2所示，生成作为第1服务(服务S1)用的切片的切片SL1(第1切片)、作为第2服务(服务S2)用的切片的切片SL2(第2切片)、以及具有作为与切片SL1或切片SL2的控制相关的控制装置的功能的切片即切片SL3(第3切片)。NFVO30对切片SL1分配服务S1，对切片SL2分配服务S2。执行服务S1和服务S2的功能根据从切片SL3发送的信号等进行处理，或者根据需要进行对设置有具有作为后述的通信控制装置的功能的节点的切片SL3请求信息的提供的处理。

由此，在***1中，切片SL1、切片SL2以及切片SL3构建为能够在逻辑上相互进行通信。

另外，在本实施方式中，提供服务S1的切片SL1包含第1C-Plane(控制平面)控制节点(CP1)211和第1U-Plane(用户平面)控制节点(UP1)212。第1C-Plane控制节点211进行与对用户提供服务S1时的通信路径的开设及断开相关的控制信号等的收发。此外，第1U-Plane控制节点212在对用户提供服务S1时设置通信路径，并且也与提供服务的服务服务器101设置通信路径，而执行用户数据的收发。此外，提供服务S2的切片SL2包含第2C-Plane控制节点(CPX1)221和第2U-Plane控制节点(UPX1)222。第2C-Plane控制节点221进行与对用户提供服务S2时的通信路径的开设及断开相关的控制信号等的收发。此外，第2U-Plane控制节点222在对用户提供服务S2时设置通信路径，并且也与提供服务的服务服务器102设置通信路径，而执行用户数据的收发。上述切片与服务之间的对应关系仅为一例，可以适当地进行变更。即，可以对1个切片分配用于提供多个服务的节点。

另外，在附图等中，有时区别地示出“CP1、UP1”和“CPX1、UPX1”。该“CP”与“CPX”的表述的区别在于表示这些节点是应用于哪种服务。即，示意性地示出CP1等是应用于服务S1的节点，CPX1等是应用于服务S2的节点。此外，也存在记载为“CPY、UPY”的节点。该节点示意性地示出本来未设想应用于服务S1或服务S2的节点。

图2的切片SL3包含公共C-Plane控制节点(Common CP(公共CP))301。公共C-Plane控制节点301具有管辖服务S1的第1C-Plane控制节点211和服务S2的第2C-Plane控制节点221等的功能，根据来自用户侧的指示，执行与用户和各切片之间的通信路径的开设及断开相关的处理。

另外，代替对切片SL3分配功能来实现公共C-Plane控制节点301的方式，可以由具有硬件的装置来实现公共C-Plane控制节点301。在该情况下，由NFVO30生成的切片成为切片SL1、SL2。

图3示出各切片与服务器之间的对应关系的示例。如图3所示，节点是服务器的一部分，由服务器1(110A)以及交换机、路由器等实现切片1(切片SL1)的第1C-Plane控制节点211的功能和切片2(切片SL2)的第2C-Plane控制节点221的功能。此外，由服务器2(110B)以及交换机、路由器等实现切片1(切片SL1)的第1U-Plane控制节点212的功能和切片2(切片SL2)的第2U-Plane控制节点222的功能。另外，在图3中，关于切片3的公共C-Plane控制节点301省略了记载，但与上述各节点同样地，由服务器、交换机以及路由器等实现切片3的公共C-Plane控制节点301。

在NFVO30对切片分配了网络服务之后，NFVO30向BSS/OSS10发送接入信息，其中，该接入信息包含该网络服务的ID、和提供该网络服务的最初功能的逻辑节点的目的地(例如，IP地址)。

当接收到该地址信息时，BSS/OSS10向各SSF70通知该地址信息。SSF70是能够与作为基站装置的eNodeB(eNB)80相互进行通信的服务器装置，当与网络服务ID一起从作为服务用户的UE90向eNB80发送了服务请求时，从该eNB80对SSF70通知从UE90接收到的网络服务ID。另外，可以与eNB80一体地实现SSF70，也可以与MME(Mobility Management Entity)等其它装置一体地实现SSF70。

当从eNB80接收到网络服务ID时，SSF70向eNB80发送逻辑节点的目的地信息，其中，该逻辑节点提供SSF70所存储的地址信息中的与从eNB80接收到的网络服务ID对应的地址信息的网络服务的最初功能。eNB80向UE90通知该目的地信息。由此，UE90能够确定为了利用网络服务而最初接入的目的地。

如上所述，SSF70保持提供网络服务的功能的逻辑节点的信息。换而言之，SSF70按照每个逻辑节点保持确定能够对应的服务的信息。对详细内容进行后述，但SSF70具有根据来自其它逻辑节点的查询而提供该信息的功能。

在此，参照图2和图4，对由本实施方式的***1生成的切片的各节点以及由其它装置构成的核心网络N1中的技术课题进行说明。该核心网络N1是指UE90进行通信而利用服务时的核心网络。

如图2所示，在包含在***1中构建的切片的核心网络N1中，UE90经由eNB80、和与设置于切片SL1的服务S1相关的第1U-Plane控制节点212，在与服务服务器101之间进行通信，从而能够利用服务服务器101所提供的服务S1。此时，在eNB80与第1U-Plane控制节点212之间，设置用于收发与UE90相关的用户数据的通信路径。即，第1U-Plane控制节点212作为切片SL1中的控制节点发挥功能。此外，经由公共C-Plane控制节点301和第1C-Plane控制节点211来进行用于进行eNB80与第1U-Plane控制节点212之间的通信路径的开设及断开的处理的控制信号的收发。

此外，UE90经由eNB80、与设置于切片SL2的服务S2相关的第2U-Plane控制节点222，与服务服务器102之间进行通信，从而能够利用服务服务器102所提供的服务S2。此时，在eNB80与第2U-Plane控制节点222之间，设置用于收发与UE90相关的用户数据的通信路径。即，第2U-Plane控制节点222作为切片SL2中的控制节点发挥功能。此外，经由公共C-Plane控制节点301、第2C-Plane控制节点221来进行用于进行该eNB80与第2U-Plane控制节点222之间的通信路径的开设及断开的处理的控制信号的收发。

由此，在本实施方式中，通过在UE90所属的区域的eNB80与2个切片SL1、SL2之间设置通信路径，从而UE90成为能够进行利用了切片SL1、SL2的通信的状态。

在此，如图4所示，UE90由于某些情况，为了利用服务而需要进行正在进行通信的切片的变更、或者需要进行切片与UE90之间的通信路径的变更。虽然考虑了UE90进行上述变更的几个可能性，但伴随与UE90相关的上下文(context)信息的变更(例如，所属的基站、扇区的变化、由于乘坐到交通工具等而引起的移动速度的变化、进入建筑物、周围的混杂信息等)，可能需要变更通信路径或者设置通信路径的对手方的切片。例如，UE90进行跨越通信区域的移动，即，通过变更位置信息，从而当变更了UE90所接入的eNB时，需要变更设置在移动前的eNB与切片之间的通信路径。此外，在UE90在利用多个服务的情况下，有时UE90经由eNB与多个切片中的控制节点之间设置通信路径，但伴随与UE90相关的上下文信息的变更，也考虑将其汇总为1个切片。在该情况下，有时需要重新设置通信路径。

在图4中，示出了UE90进行跨越服务提供区域的移动的情况下的示例。在图4所示的示例中，示出了2个区域。区域(SA：Service Area)#1是eNB81所管辖的区域，区域(SA)#2是eNB82所管辖的区域。在SA#1中，UE90能够在切片SL1、SL2之间设置通信路径而利用服务S1、S2。此外，在SA#2中，UE90能够在切片SL4、SL5之间设置通信路径而利用服务S1、S2。在图4中，示出了UE90从上述SA#1向SA#2移动的情况。

切片SL4中设置有与第4C-Plane控制节点341(CP2)及第4U-Plane控制节点342(UP2)相关的功能。第4U-Plane控制节点342能够与提供服务S1的服务服务器101之间设置通信路径。此外，切片SL5中设置有与第5C-Plane控制节点351(CPX2)和第5U-Plane控制节点352(UPX2)相关的功能。第5U-Plane控制节点352能够与提供服务S2的服务服务器102之间设置通信路径。

在UE90属于SA#1时，UE90接受服务S1的提供，因此在eNB81与切片SL1的第1U-Plane控制节点212之间设置与UE90相关的通信路径。此外，由于UE90接受服务S2的提供，因此在eNB81与切片SL2的第1U-Plane控制节点222之间设置与UE90相关的通信路径。

在此，当UE90从SA#1移动到SA#2时，UE90所接入的基站装置成为eNB82。并且，在图4所示的示例中，UE90为了接受服务S1的提供，需要在eNB82与切片SL4的第4U-Plane控制节点242之间设置通信路径。此外，UE90为了接受服务S2的提供，需要在eNB82与切片SL5的第5U-Plane控制节点252之间设置通信路径。另外，公共C-Plane控制节点301具有管辖双方的区域(SA#1，SA#2)的C-Plane控制节点211、221、241、251的功能，根据来自用户侧的指示，执行与用户和各切片之间的通信路径的开设及断开相关的处理。

如图4所示，UE90在移动了区域之后，也接受与移动前相同的服务，有时需要变更设置用于收发用户数据的通信路径的对象切片。此外，即使在通过接入到切片SL1、SL2从而能够利用服务的情况下，由于伴随UE90在区域内的移动进行与UE90相关的通信的控制的eNB产生变更，需要重新设置通信路径。

说明在本实施方式中，这样在对UE90与多个切片之间进行通信时，由于某些情况，UE90需要进行为了利用服务而在进行通信的切片的变更、或者需要进行在多个切片与UE90之间分别设置的通信路径的变更的情况下的处理。以下的实施方式中所说明的处理的特征在于UE90一边持续利用服务的状态，一边变更通信路径。UE90一边持续利用服务的状态是指一边持续通信路径为连接模式(Connected Mode)的情况。为了实现该处理，对于对多个切片的控制节点设置的通信路径，分别一边设置变更前的通信路径与变更后的通信路径并存的状态，一边进行与通信路径的变更相关的处理。

上述处理由公共C-Plane控制节点301作为主体来执行。即，公共C-Plane控制节点301作为进行与对多个切片的控制节点设置的UE90相关的通信路径的控制的通信控制装置发挥功能。因此，如图5所示，公共C-Plane控制节点301具有变更请求取得部310、判定部320以及通信处理部330。

变更请求取得部310具有取得与和切片SL1等的通信路径的变更相关的请求的功能。在伴随UE90的移动而变更与UE90相关的通信路径的情况下，从UE90接入的eNB发送与该通信路径的变更相关的请求。此外，在伴随其它上下文信息的变更而变更通信路径的情况下，有时从与eNB不同的装置发送与通信路径的变更相关的请求。作为发送与通信路径的变更相关的请求的eNB不同的装置，例如，可以考虑UE90、或者具有收集与UE90相关的上下文信息的功能的SSF70等。当变更请求取得部310取得与通信路径的变更相关的请求时，向该判定部320发送该请求中所包含的信息。

判定部320具有判定是否对多个切片设置了与通信路径的变更的请求的对象UE90相关的通信路径的功能。在判定部320中，根据与通信路径的变更的请求中所包含的信息，进行上述判定。此外，根据判定部320的判定结果，来进行通信处理部330的处理。

通信处理部330根据通信路径的变更的请求进行与通信路径的变更相关的处理，以使UE90一边利用服务，一边进行通信路径的变更。对通信处理部330的处理详细内容进行后述。

图6是示出实现执行本实施方式的处理的各节点的功能的服务器(例如，构成公共C-Plane控制节点301的服务器等)的硬件结构的一例的图。上述服务器可以构成为在物理上包含处理器1001、内存(memory)1002、存储器(storage)1003、通信装置1004、输入装置1005、输出装置1006、以及总线1007等的计算机装置

另外，在下面的说明中，“装置”这一措辞可以替换为“电路”、“设备(device)”、“单元(unit)”等。上述服务器的硬件结构可以构成为包含1个或多个图示的各装置，也可以构成为不包含其中的一部分装置。

服务器中的各功能通过如下方法实现：在处理器1001、内存1002等硬件上读入规定的软件(程序)，从而处理器1001进行运算，并控制通信装置1004的通信、内存1002及存储器1003中的数据的读出和/或写入。

处理器1001例如使操作***动作并对计算机整体进行控制。处理器1001可以由包含与周边装置之间的接口、控制装置、运算装置、寄存器等的中央处理装置(CPU：CentralProcessing Unit)构成。例如，可以通过处理器1001实现上述公共C-Plane控制节点301中的通信处理部330等。

此外，处理器1001从存储器1003和/或通信装置1004向内存1002读出程序(程序代码)、软件模块或数据，据此执行各种处理。作为程序，使用了使计算机执行在上述的实施方式中说明的动作中的至少一部分程序。例如，可以通过存储在内存1002中并通过处理器1001进行动作的控制程序来实现上述通信处理部330，也可以同样地实现其它的功能块。虽然说明了通过1个处理器1001执行上述各种处理，但也可以通过2个以上的处理器1001同时或依次执行上述各种处理。处理器1001可以通过1个以上的芯片来安装。另外，程序也可以经由电信线路从网络发送。

内存1002是计算机可读的记录介质，例如可以由ROM(Read Only Memory：只读存储器)、EPROM(Erasable Programmable ROM：可擦可编程只读存储器)、EEPROM(Electrically Erasable Programmable ROM：可电擦除可编程只读存储器)、RAM(RandomAccess Memory：随机存取存储器)等的至少一方构成。内存1002可以称为寄存器、高速缓冲存储器、主存储器(主存储装置)等。内存1002可以保存能够执行本发明的一个实施方式的无线通信方法的程序(程序代码)、软件模块等。

存储器1003是计算机可读的记录介质，例如可以由CD-ROM(Compact Disc ROM)等光盘、硬盘驱动器、软盘、磁光盘(例如高密度磁盘、数字多功能磁盘、Blu-ray(注册商标)盘、智能卡、闪存(例如卡、棒、键驱动(Key drive))、Floppy(注册商标)盘、磁条等中的至少一方构成。存储器1003也可以称为辅助存储装置。上述存储介质可以是例如包含内存1002和/或存储器1003的数据库、服务器等其它适当的介质。

通信装置1004是用于经由有线和/或无线网络进行计算机之间的通信的硬件(收发设备)，例如，也可以称为网络设备、网络控制器、网卡、通信模块等。例如，可以通过通信装置1004实现上述变更请求取得部310、通信处理部330等。

输入装置1005是受理来自外部的输入的输入设备(例如，键盘、鼠标、麦克风、开关、按钮、传感器等)。输出装置1006是实施向外部输出的输出设备(例如，显示器、扬声器、LED灯等)。另外，输入装置1005和输出装置1006也可以是一体的结构(例如，触摸面板)。

此外，处理器1001和内存1002等各装置通过用于对信息进行通信的总线1007来连接。总线1007可以通过单一的总线构成，也可以在装置间由不同的总线构成。

此外，公共C-Plane控制节点301可以构成为包含微处理器、数字信号处理器(DSP：Digital Signal Processor)、ASIC(Application Specific Integrated Circuit：专用集成电路)、PLD(Programmable Logic Device：可编程逻辑器件)、FPGA(Field ProgrammableGate Array：现场可编程门阵列)等硬件，可以通过该硬件来实现各功能块的一部分或全部。例如，可以通过这些硬件中的至少1个硬件来安装处理器1001。

接着，对包含公共C-Plane控制节点301的***1中的UE90的通信路径的变更的具体处理(通信控制方法)进行说明。在UE90一边利用多个服务一边变更其通信路径的情况下，如上所述，一边设置变更前的通信路径与变更后的通信路径共存的状态，一边进行与通信路径的变更相关的处理。

作为前提，设为对2个切片设置与UE90相关的通信路径。在该情况下，关于如何设置变更前的通信路径与变更后的通信路径，具体来说，可以考虑4个案例(case)。即，第1案例为不变更设置通信路径的切片而仅变更通信路径，第2案例为对与变更前不同、并且能够分别单独提供2个服务的2个切片分别设置通信路径，第3案例为对与变更前不同的1个切片设置通信路径、并且保持DNS服务器能够对应的切片的信息的情况，第4案例为对与变更前不同的1个切片设置通信路径、并且未保持DNS服务器能够对应的切片的信息的情况。下面，对该4个示例分别进行说明，并且参照时序图对具体的处理进行说明。

(第1：仅变更通信路径的案例)

图7是用于说明第1示例的状況的图。图7所示的示例例如是UE90与切片SL1、SL2之间进行通信，从而UE90在能够利用服务S1、S2的区域SA#1内进行移动的情况。在该情况下，UE90进行通信时的基站装置通过切换(handover)从eNB81向eNB82变更，但能够继续进行与切片SL1、SL2进行通信而利用服务S1、S2。因此，将移动前的eNB81与第1U-Plane控制节点212之间的通信路径切换为eNB82与第1U-Plane控制节点212之间的通信路径，并且将移动前的eNB81与第2U-Plane控制节点222之间的通信路径切换为eNB82与第2U-Plane控制节点222之间的通信路径，从而能够持续利用服务S1、S2。

参照图8对这样的案例中的具体的处理过程进行说明。

首先，在UE90的移动前的eNB81与移动目的地的eNB82之间进行与切换相关的信号的收发(HO Request(HO请求)，HO Request ACK(HO请求确认)：S101)。以该信号为契机，在UE90、eNB81、eNB82之间进行与切换相关的处理(Handover Execution(切换执行)：S102)。

之后，从移动目的地的eNB82对公共C-Plane控制节点301发送进行与通信路径的变更相关的请求的信号(Path Switch Request(路径切换请求)：S103：变更请求取得步骤)。另外，在此，对UE90进行切换的情况进行了说明，因此进行与通信路径的变更相关的请求的信号为“路径切换请求”，但可以根据变更通信路径的情况而适当地变更进行与通信路径的变更相关的请求的信号。这在其它案例中也是同样的。

与通信路径的变更相关的请求包含用于确定UE90的信息、用于确定通信路径的信息(TU-1、TU-2)以及用于确定会话的信息(S-ID1、S-ID2)。另外，代替用于确定会话的信息(S-ID：Session ID(会话ID))，可以使用无线接入承载的ID(E-RAB ID：E-UTRAN RadioAccess Bearer ID(E-UTRAN无线接入承载ID))。对于该点，在后述的其它实施方式以及其它案例中也是同样的。在公共C-Plane控制节点301的变更请求取得部310中，当接收到来自eNB82的请求时，在判定部320中，根据与通信路径的变更相关的请求，判定UE90是否在与2个切片之间设置了通信路径(S104：判定步骤)。在本实施方式中，当与通信路径的变更相关的请求包含多个用于确定通信路径的信息，并且包含多个用于确定会话的信息时，在判定部320中，能够判断对UE90单独设置2个通信路径的情况。由此，利用与通信路径的变更相关的请求中所包含的信息，在判定部320中，进行是否设置了多个通信路径的判定。并且，在判定部320中，在判定为对UE90设置了多个通信路径的情况下，进行图8所示的以下的处理。另外，在判定部320中，在判定为未对UE90设置多个通信路径，即，对于UE90，仅在与1个切片之间设置了通信路径、或者未设置通信路径的情况下，进行与公知的切换相关的处理。

在判定部320中，在判定为对UE90设置了多个通信路径的情况下，公共C-Plane控制节点301的通信处理部330根据用于确定会话的信息等，对第1C-Plane控制节点211和第2C-Plane控制节点221发送与通信路径的变更相关的指示(Path Switch Request(路径切换请求)：S105、S106：通信处理步骤)。与通信路径的变更相关的指示包含用于确定变更目的地的eNB82的信息(eNB ID)、以及用于确定作为变更对象的通信路径的信息(TU-1或TU-2)。另外，可以变更向2个节点发送与通信路径的变更相关的指示的顺序(S105，S106)。

在第1C-Plane控制节点211中，当接收到与通信路径的变更相关的指示时，根据该指示，通过公知的过程来进行与通信路径的变更相关的处理。具体来说，将用于确定变更目的地的eNB82的信息(eNB ID)与用于确定作为变更对象的通信路径的信息(TU-1)一起发送给同一切片SL1的第1U-Plane控制节点212，从而指示通信路径的创建(Modify BearerRequest(变更承载请求)：S107)。与此相对，第1U-Plane控制节点212在进行了与通信路径的创建相关的处理之后，将表示进行了创建通信路径的处理的信息与用于确定自身节点的信息(UP1ID)一起回复给第1C-Plane控制节点211(Modify Bearer Response(变更承载应答)：S109)。接收到来自第1U-Plane控制节点212的回复的第1C-Plane控制节点211对公共C-Plane控制节点301通知与通信路径的变更相关的处理已完成，作为针对与通信路径的变更相关的指示(S105)的应答(Path Switch Request ack：S111：通信处理步骤)。

在第2C-Plane控制节点221中也进行同样的处理。即，在第2C-Plane控制节点221中，当接收到与通信路径的变更相关的指示时，根据该指示，通过公知的过程来进行与通信路径的变更相关的处理。具体来说，将用于确定变更目的地的eNB82的信息(eNB ID)与用于确定作为变更对象的通信路径的信息(TU-2)一起发送给同一切片SL2的第2U-Plane控制节点222，从而指示通信路径的创建(Modify Bearer Request(承载修改请求)：S108)。与此相对，第2U-Plane控制节点222在进行了与通信路径的创建有关的处理之后，与用于确定自身节点的信息(UPX1ID)一起，将表示已进行了创建通信路径的处理的信息回复给第2C-Plane控制节点221(Modify Bearer Response(承载修改应答)：S109)。接收到来自第1U-Plane控制节点222的回复的第2C-Plane控制节点221对公共C-Plane控制节点301通知与通信路径的变更相关的处理已完成，作为针对与通信路径的变更相关的指示(S106)的应答(PathSwitch Request ack：S112(路径切换请求确认)：通信处理步骤)。

在图8中示出了交替地进行切片SL1中的处理和切片SL2中的处理。然而，由于切片SL1中的处理和切片SL2中的处理单独地进行，因此处理的顺序可能与图8所示的顺序不同。

在公共C-Plane控制节点301中，当接收到来自第1C-Plane控制节点211的应答(S111)和来自第2C-Plane控制节点221的应答(S112)时，对eNB82通知与通信路径的变更相关的处理已结束(Path Switch Request ack(路径切换请求确认)：S113：通信处理步骤)。该信号包含用于确定第1U-Plane控制节点212的信息(UP1ID)、以及用于确定第2U-Plane控制节点222的信息(UPX1ID)。根据该信息，eNB82能够确定作为通信路径的对手方的节点。

之后，从eNB82对eNB81指示与通信路径相关的资源的释放(Release Resource(资源释放)：S114)。由此，UE90能够经由eNB82与第1U-Plane控制节点212之间进行用户数据的收发(S115)，并且能够经由eNB82与第2U-Plane控制节点222之间进行用户数据的收发(S116)。由此，UE90能够经由eNB82利用服务S1、S2。

在上述处理中，在设置了eNB82与第1U-Plane控制节点212及第2U-Plane控制节点222之间的通信路径的时刻(S113)，eNB81侧中的与通信路径相关的资源未被释放。因此，在设置了变更前的通信路径与变更后的通信路径共存的状态之后，进行与通信路径的变更相关的处理。

即，在进行了设置变更后的通信路径的处理之后，进行与变更前的通信路径的释放相关的处理。由此，设置变更前的通信路径与变更后的通信路径共存的状态。

(第2：对2个切片新设置通信路径的案例)

图9是用于说明第2示例的状況的图。在图9所示的案例例如是UE90与切片SL1、SL2之间进行通信，从而UE90从能够利用服务S1、S2的区域SA#1向不同的区域SA#2移动的情况。在该情况下，UE90进行通信时的基站装置不仅通过切换从eNB81变更至eNB82，还需要将UE90为了利用服务S1、S2而进行通信的切片从切片SL1、SL2变更为切片SL4、SL5。移动前的eNB81与第1U-Plane控制节点212之间的通信路径切换为eNB82与第4U-Plane控制节点242之间的通信路径。此外，移动前的eNB81与第2U-Plane控制节点222之间的通信路径切换为eNB82与第5U-Plane控制节点252之间的通信路径。由此，UE90能够持续利用服务S1、S2。另外，eNB82、公共C-Plane控制节点301以及UE90等未掌握在UE90的移动目的地的区域SA#2中通过使eNB82与哪个切片之间设置通信路径，从而能够使UE90利用服务S1、S2。关于该信息，公共C-Plane控制节点301向DNS(Domain Name System：域名***)服务器350进行查询，从而取得信息。DNS服务器350保持域名与IP地址之间的关联的信息，也保持与切片相关的信息。

参照图10对这样的案例中的具体的处理过程进行说明。

首先，在UE90的移动前的eNB81与移动目的地的eNB82之间进行与切换相关的信号的收发(HO Request(HO请求)，HO Request ACK(HO请求确认)：S201)。以该信号为契机，在UE90、eNB81、eNB82之间进行与切换相关的处理(Handover Execution(切换执行)：S202)。

之后，从移动目的地的eNB82对公共C-Plane控制节点301发送进行与通信路径的变更相关的请求的信号(Path Switch Request(路径切换请求)：S203：变更请求取得步骤)。

与通信路径的变更相关的请求包含用于确定UE90的信息、用于确定通信路径的信息(TU-1、TU-2)以及用于确定会话的信息(S-ID1、S-ID2)。在公共C-Plane控制节点301的变更请求取得部310中，当接收到来自eNB82的请求时，在判定部320中，利用与通信路径的变更相关的请求中所包含的信息，判定UE90是否与2个切片之间设置了通信路径(S204：判定步骤)。在本实施方式中，当与通信路径的变更相关的请求包含多个用于确定通信路径的信息，并且包含多个用于确定会话的信息时，在判定部320中，能够判断对UE90单独设置2个通信路径的情况。由此，利用与通信路径的变更相关的请求中所包含的信息，在判定部320中，进行是否设置了多个通信路径的判定。并且，在判定部320中，在判定为对UE90设置了多个通信路径的情况下，进行图10所示的以下的处理。另外，在判定部320中，在判定为未对UE90设置多个通信路径，即，对于UE90仅与1个切片之间设置通信路径、或者未设置通信路径的情况下，进行与公知的切换相关的处理。

进而，在判定部320中，确认2个切片SL1、SL2未覆盖eNB82所管辖的区域的情况(S204)。在公共C-Plane控制节点301中，在eNB81与切片SL1、SL2之间的通信路径的开设时取得与包含第1C-Plane控制节点211的切片SL1和包含第2C-Plane控制节点221的切片SL2相关的信息。因此，能够在公共C-Plane控制节点301中掌握2个切片SL1、SL2未覆盖eNB82所管辖的区域的情况。

在判定部320中，在确认了对UE90设置了多个通信路径，并且切片SL1、SL2未覆盖eNB82所管辖的区域的情况下，公共C-Plane控制节点301的通信处理部330向DNS服务器350查询与经由eNB82设置通信路径时的切片相关的信息(DNS Query Request/Response(DNS查询请求/应答)：S205：通信处理步骤)。更具体来说，取得用于确定能够在经由eNB82利用服务S1、S2时进行通信的C-Plane控制节点的信息。其结果，在通信处理部330中，根据与从DNS服务器350取得的C-Plane控制节点相关的信息，基于在eNB82之间要收发用户数据的服务服务器的APN(Access Point Name：接入点名称)和UE90的位置(即，接入的eNB82的信息)，确定为了利用服务S1而应接入的切片(在此，为切片SL4)的C-Plane控制节点241、和为了利用服务S2而应接入的切片(在此，为切片SL5)的C-Plane控制节点251(S206：通信处理步骤)。

在通信处理部330中，对所确定的2个C-Plane控制节点，即第4C-Plane控制节点241和第5C-Plane控制节点251发送用于设置与UE90相关的新的会话的请求(CreateSession Request(会话创建请求)：S207、S208：通信处理步骤)。会话的创建请求包含用于确定接入目的地的eNB82的信息(eNB ID)、以及用于确定通过会话的创建而设置的通信路径的信息(TU-1或TU-2)。另外，能够变更向2个节点发送会话创建请求的顺序(S207、S208)。

在第4C-Plane控制节点241中，当接收到会话创建请求时，根据该请求，通过公知的过程来进行与通信路径的创建相关的处理。具体来说，作为创建通信路径的U-Plane控制节点，选择同一切片SL4的第4U-Plane控制节点242(UP Selection(UP选择)：S209)。之后，将用于确定eNB82的信息(eNB ID)与用于确定通信路径的信息(TU-1)一起发送给第4U-Plane控制节点242，从而指示通信路径的创建(Create Session Request(会话创建请求)：S211)。第4U-Plane控制节点242在进行了与通信路径的创建相关的处理之后，与用于确定自身节点的信息(UP2ID)，对第4C-Plane控制节点241回复已进行了创建通信路径的处理(Create Session Response(会话创建应答)：S213)。接收到来自第4U-Plane控制节点242的回复的第4C-Plane控制节点241对公共C-Plane控制节点301通知与通信路径的创建相关的处理已完成，作为针对会话的创建请求(S207)的应答(Create Session Response(会话创建应答)：S215：通信处理步骤)。

在第5C-Plane控制节点251中也进行同样的处理。即，在第5C-Plane控制节点251中，当接收到会话的创建请求时，根据该请求，通过公知的过程来进行与通信路径的创建相关的处理。具体来说，作为创建通信路径的U-Plane控制节点，选择同一切片SL5的第5U-Plane控制节点252(UP Selection(UP选择)：S210)。之后，将用于确定eNB82的信息(eNBID)与用于确定通信路径的信息(TU-2)一起发送给第5U-Plane控制节点252，从而指示通信路径的创建(Create Session Request(会话创建请求)：S212)。第5U-Plane控制节点252在进行了与通信路径的创建相关的处理之后，与用于确定自身节点的信息(UP2ID)一起，将表示已进行了创建通信路径的处理的信息回复给第5C-Plane控制节点251(Create SessionResponse(会话创建应答)：S214)。接收到来自第5U-Plane控制节点252的回复的第5C-Plane控制节点251对公共C-Plane控制节点301通知与通信路径的创建相关的处理已完成，作为针对会话创建请求(S208)的应答(Create Session Response(会话创建应答)：S216：通信处理步骤)。

图10示出了交替地进行切片SL4中的处理与切片SL5中的处理。然而，由于切片SL4中的处理与切片SL5中的处理单独地进行，因此处理的顺序可能与图10所示的顺序不同。

在公共C-Plane控制节点301中，当接收到来自第4C-Plane控制节点241的应答(S215)、和来自第5C-Plane控制节点251的应答(S216)时，对eNB82通知与通信路径的变更相关的处理已结束(Path Switch Request ack(路径切换请求确认)：S217：通信处理步骤)。该信号包含用于确定第4U-Plane控制节点242的信息(UP2ID)、以及用于确定第5U-Plane控制节点252的信息(UPX2ID)。根据该信息，eNB82能够确定作为通信路径的对手方的节点。

之后，从eNB82对eNB81指示与通信路径相关的资源的释放(Release Resource(资源释放)：S218)。此外，公共C-Plane控制节点301对与eNB81之间设置了通信路径的切片SL1的第1C-Plane控制节点211和切片SL2的第2C-Plane控制节点221指示会话的释放，进行会话的释放处理(Delete Session Request/Response(会话删除请求/应答)：S219，S220：通信处理步骤)。对于从eNB82向eNB81的资源释放指示(S218)与来自公共C-Plane控制节点301的会话释放指示(S219，S220)，可以交换顺序。

通过以上的处理，UE90能够经由eNB82与第4U-Plane控制节点242之间进行用户数据的收发，并且能够经由eNB82与第5U-Plane控制节点252之间进行用户数据的收发。由此，UE90能够经由eNB82利用服务S1、S2。

在上述处理中，在设置了eNB82与第4U-Plane控制节点242及第5U-Plane控制节点252之间的通信路径的时刻(S217)，eNB81侧的与2个通信路径相关的资源未被释放。因此，在设置了变更前的通信路径与变更后的通信路径共存的状态之后，进行与通信路径的变更相关的处理。

即，在进行了设置变更后的通信路径的处理之后，进行与变更前的通信路径的释放相关的处理。由此，设置变更前的通信路径与变更后的通信路径共存的状态。

(第3：与1个切片之间设置通信路径的案例，并且能够从DNS服务器取得信息的情况)

图11是用于说明第3案例的状況的图。图11所示的案例例如是UE90与切片SL1、SL2之间进行通信，从而UE90从能够利用服务S1、S2的区域SA#1移动至不同的区域SA#2的情况。在该情况下，不仅通过切换使UE90进行通信时的基站装置从eNB81变更至eNB82，而且需要变更为了利用服务S1、S2而进行通信的切片。但是，在移动目的地的区域SA#2中，存在与切片SL1对应的切片SL4，但有时不存在与切片SL2对应的切片。在该情况下，作为持续利用2个服务的方法，在第3案例中，将移动前的eNB81与第1U-Plane控制节点212之间的通信路径、以及移动前的eNB81与第2U-Plane控制节点222之间的通信路径双方的功能切换为eNB82与第4U-Plane控制节点242之间的通信路径。即，通过对1个切片SL4设置的1条通信路径进行2个服务的用户数据的收发。由此，在UE90中，能够持续利用服务S1、S2。

另外，eNB82、公共C-Plane控制节点301以及UE90等未掌握在UE90的移动目的地的区域SA#2中通过使eNB82与哪个切片之间设置通信路径，从而使UE90能够利用服务S1、S2的情况。关于该信息，公共C-Plane控制节点301对DNS(Domain Name System)服务器350进行查询，从而取得信息。此外，公共C-Plane控制节点301有时也对DNS服务器350及SSF70进行查询，从而取得这些信息。关于这些方法进行后述。

参照图12对上述那样的第3案例中的具体的处理过程进行说明。

首先，在UE90的移动前的eNB81与移动目的地的eNB82之间进行与切换相关的信号的收发(HO Request(HO请求),HO Request ACK(HO请求确认)：S301)。以该信号为契机，在UE90、eNB81，eNB82之间进行与切换相关的处理(Handover Execution(切换执行)：S302)。

之后，从移动目的地的eNB82对公共C-Plane控制节点301发送进行与通信路径的变更相关的请求的信号(Path Switch Request(路径切换请求)：S303：变更请求取得步骤)。

与通信路径的变更相关的请求中包含用于确定UE90的信息、用于确定通信路径的信息(TU-1、TU-2)以及用于确定会话的信息(S-ID1、S-ID2)。在公共C-Plane控制节点301的变更请求取得部310中，当接收到来自eNB82的请求时，在判定部320中，利用与通信路径的变更相关的请求中所包含的信息，判定UE90是否与2个切片之间设置了通信路径(S304：判定步骤)。在本实施方式中，当与通信路径的变更相关的请求中包含多个用于确定通信路径的信息，并且包含多个用于确定会话的信息时，在判定部320中，能够判断出对UE90单独地设置2个通信路径的情况。由此，利用与通信路径的变更相关的请求中所包含的信息，在判定部320中进行是否设置了多个通信路径的判定。并且，在判定部320中判定为对UE90设置了多个通信路径的情况下，进行图12所示的以下的处理。另外，在判定部320中判定为未对UE90设置多个通信路径，即，对于UE90仅与1个切片之间设置了通信路径、或者未设置通信路径的情况下，进行与公知的切换相关的处理。

进而，在判定部320中，确认2个切片SL1、SL2未覆盖eNB82所管辖的区域的情况(S304)。对于该点，与第2案例同样。

在判定部320中确定了对UE90设置了多个通信路径，并且切片SL1、SL2未覆盖区域SA#2的情况下，公共C-Plane控制节点301的通信处理部330对DNS服务器350查询与经由eNB82设置通信路径时的切片相关的信息(DNS Query Request(DNS查询请求)：S305：通信处理步骤)。更具体来说，通信处理部330对DNS服务器350发送ECGI(E-UTRAN Cell GlobalID(小区全局ID))或者提供服务S1、S2的服务服务器的APN(APN1&2)，从而取得用于确认利用服务S1、S2时应进行通信的切片的C-Plane控制节点的信息。ECGI是用于确定UE90所属的小区的信息，即，表示UE90的位置信息。

在此，在DNS服务器350保持图13的(A)所示的信息的情况下，DNS服务器350能够根据UE90的位置提供与各种服务对应的切片相关的信息。在图13的(A)中，按照每个区域(位置(Location))示出服务的种类(Service Type)、利用该服务时所利用的切片以及构成该切片的节点。例如，示出了在由位置(Location)#1确定的区域中，在利用MBB这样的服务时，与切片1之间设置通信路径，在利用V2X这样的服务时，与切片2之间设置通信路径。另一方面，示出了在由位置#2确定的区域中，对MBB和V2X这双方的服务关联切片3。此外，在由位置#3确定的区域中，对MBB和V2X这双方的服务关联切片4。

第2案例是如位置#1那样按照每个服务关联不同的切片的案例。与此相对，第3案例是如位置#2和位置#3那样一个切片的节点应用于2个服务S1、S2的案例。当eNB82所管辖的区域(UE90所属的区域)为这种状况时，对从DNS服务器350发送的结果仅返回用于确定1个C-Plane控制节点的信息(DNS Query Response(DNS查询应答)：S306：通信处理步骤)。在此，从DNS服务器350对公共C-Plane控制节点301发送用于确定第4C-Plane控制节点241的信息。由此，在公共C-Plane控制节点301中，决定与包含第4C-Plane控制节点241的切片SL4之间设置与2个服务相关的会话(Selects CP2for both APN1&2Sessions(为APN1&2会话选择CP2)：S309：通信处理步骤)。

另外，根据DNS服务器350所保持的信息，有时不能在UE90所属的区域中确定能够与服务S1、S2对应的切片。这是如下的情况：即，在DNS服务器350中，例如仅保持由与图13的(B)对应的信息。在图13的(B)所示的示例中，按照每个区域(位置)仅示出能够利用的切片以及构成该切片的节点。即，是不清楚与哪个切片之间进行通信以及能够利用哪个服务的情况。在该情况下，在UE90例如属于位置#2的情况下，从DNS服务器350对公共C-Plane控制节点301发送用于确定切片SL4的第4C-Plane控制节点241的信息。但是，在该情况下，仅根据来自DNS服务器350的信息，不清楚能否通过对包含第4C-Plane控制节点241的切片SL4进行通信从而利用2个服务。因此，在公共C-Plane控制节点301的通信处理部330中，对SSF70发送用于确定UE90的信息、用于确定想要利用的服务的信息(APN1&APN2)以及ECGI，并进行查询(Policy Request(策略请求)：S307：通信处理步骤)。

在DNS服务器350仅保持图13的(B)所示的信息的情况下，在SSF70中，能够保持图13的(C)所示的那样的信息，即，能够保持按照每个服务用于确定应优先地进行通信的切片的信息。在图13的(C)所示的示例中，对于2个服务，分别按优先的顺序记载能够对应的切片。在SSF70中，根据用于确定从公共C-Plane控制节点301发送的服务的信息，提供对应的切片的信息(Policy Response(策略应答)：S308：通信处理步骤)。在此，作为用于确定切片SL4的信息，提供用于确定第4C-Plane控制节点241的信息。

并且，在公共C-Plane控制节点301中，根据来自DNS服务器350的信息和来自SSF70的信息，决定与包含第4C-Plane控制节点241的切片SL4之间设置与2个服务相关的会话(Selects CP2for both APN1&2Sessions(为APN1&2会话选择CP2)：S309：通信处理步骤)。

由此，在仅根据DNS服务器350所保持的信息不能选择适当的切片(C-Plane控制节点)的情况下，作为SSF70保持用于确定与服务对应的切片的信息的结构，可以是公共C-Plane控制节点301也对SSF70进行查询，从而确定用于利用2个服务的适当的切片(C-Plane控制节点)的结构。

另外，在上述内容中，对DNS服务器350仅保持图13的(B)所示那样的信息的情况进行了说明，但除此之外，有时根据DNS服务器350所保持的信息，不能确定UE90所属的区域中能够与服务S1、S2对应的切片。这是如下的情况：即，例如DNS服务器350仅保持服务的种类(Service Type)与利用该服务时所利用的切片及构成该切片的节点之间的对应。在该案例中，考虑到不能考虑DNS服务器350中与UE90所属的区域相关的信息来选择适当的切片，因此需要对SSF70进行查询。

此外，如上所述，在DNS服务器350保持服务的种类(Service Type)与利用该服务时所利用的切片及构成该切片节点之间的对应的情况下，有时仅根据DNS服务器350所保持的信息，不能对特定的服务确定能够对应的切片。例如，在图13的(A)所示的示例中，在位置#2处示出了切片3能够对应服务MBB和服务V2X的情况，但有时未确定能够对应服务V2X的切片。关于这种情况，DNS服务器350也仅对公共C-Plane控制节点301返回用于确定1个C-Plane控制节点的信息(DNS Query Response(DNS查询应答)：S306：通信处理步骤)作为结果。由此，在返回了用于确定1个C-Plane控制节点的信息的情况下，存在如下的两种情况：该C-Plane控制节点为判断为在DNS服务器350中能够对应所有的多个服务的切片相关的节点的信息，以及为仅能够对应特定的服务的切片相关的节点的信息。在前者的情况下，可以不查询SSF70，但在后者的情况下，为了持续利用多个服务，需要也对SSF70进行查询。

预先确定DNS服务器350和SSF70保持什么样的信息，根据来自公共C-Plane控制节点301的请求返回什么样的信息。例如，在DNS服务器350中，如果进行了基于UE90的位置、UE90所利用的服务以及切片的策略等信息的判断，则可以考虑在从DNS服务器350提供了与1个C-Plane控制节点相关的信息(与切片相关的信息)的情况下不需要进行针对SSF70的查询。另一方面，在DNS服务器350所保持的信息较少的情况下，可以考虑优选在从DNS服务器350提供了与1个C-Plane控制节点相关的信息(与切片相关的信息)的情况下，对SSF70进行查询。由此，考虑根据DNS服务器350所保持的信息的量、精度等，是否优选对SSF70进行查询的情况会产生变化。因此，在公共C-Plane控制节点301从DNS服务器350取得与1个C-Plane控制节点相关的信息的情况下，可以根据DNS服务器350所保持的信息的种类等预先决定是否也对SSF70进行查询，也可以构成为根据来自DNS服务器350的应答内容而进行变更。

另外，在DNS服务器350及SSF70不能对确定想利用的服务的信息(APN1&APN2)提供用于确定适当的切片的信息的情况下，由于不能进行服务的提供，因此服务的提供本身被中断。

在通信处理部330中，对通过到目前为止的处理确定的C-Plane控制节点，即，第4C-Plane控制节点241发送用于设置与UE90相关的新的会话的请求(Create SessionRequest(会话创建请求)：S310：通信处理步骤)。会话的创建请求中包含用于确定接入目的地的eNB82的信息(eNB ID)、用于确定通过会话的创建而设置的通信路径的信息(TU-1及TU-2)以及用于确定服务的信息(APN1及APN2)。由此，在第4C-Plane控制节点241中，识别出开设与2个服务相关的会话的情况。

在第4C-Plane控制节点241中，当接收到会话的创建请求时，根据该请求，通过公知的过程进行与通信路径的创建相关的处理。具体来说，作为创建通信路径的U-Plane控制节点，选择同一切片SL4的第4U-Plane控制节点242(UP Selection(UP选择)：S311)。之后，将用于确定eNB82的信息(eNB ID)与用于确定通信路径的信息(TU-1及TU-2)一起发送供给第4U-Plane控制节点242，从而指示通信路径的创建(Create Session Request(会话创建请求)：S312)。第4U-Plane控制节点242在进行了与通信路径的创建相关的处理之后，与用于确定通信路径的信息(TU-1及TU-2)以及用于确定自身节点的信息(UP2ID)一起，将表示已进行了创建通信路径的处理的信息回复给第4C-Plane控制节点241(Create SessionResponse(会话创建应答)：S313)。接收到来自第4U-Plane控制节点242的回复的第4C-Plane控制节点241对公共C-Plane控制节点301通知与通信路径的创建相关的处理已完成，作为针对会话创建请求(S310)的应答(Create Session Response(会话创建应答)：S314：通信处理步骤)。

在公共C-Plane控制节点301中，当接收到来自第4C-Plane控制节点241的应答(S314)时，对eNB82通知与通信路径的变更相关的处理已结束(Path Switch Request ack(路径切换请求确认)：S315：通信处理步骤)。对该信号关联用于确定第4U-Plane控制节点242的信息(UP2ID)，包含2个用于确定通信路径的信息(TU-1、TU-2)和2个用于确定会话的信息(S-ID1、S-ID2)。根据该信息，eNB82能够确定作为通信路径的对手方的节点。

之后，从eNB82对eNB81指示与通信路径相关的资源的释放(Release Resource(资源释放)：S316)。此外，公共C-Plane控制节点301对与eNB81之间设置通信路径的切片SL1的第1C-Plane控制节点211和切片SL2的第2C-Plane控制节点221指示会话的释放，进行会话的释放处理(Delete Session Request/Response(会话删除请求/应答)：S317，S318：通信处理步骤)。对于从eNB82向eNB81的资源释放指示(S316)和来自公共C-Plane控制节点301的会话释放指示(S317，S318)，可以交换顺序。

通过以上的处理，UE90能够经由eNB82与第4U-Plane控制节点242之间进行用户数据的收发，从而能够经由eNB82利用服务S1、S2。

另外，在上述第3案例中，对在移动目的地的区域SA#2中存在与切片SL1对应的切片SL4，但不存在与切片SL2对应的切片的情况进行了说明，但也可以是相反的情况。即，在不存在与切片SL1对应的切片，但存在与切片SL2对应的切片SL5的情况下，也能够按照与上述说明的处理同样的方法来进行处理。

在上述处理中，在设置了eNB82与第4U-Plane控制节点242之间的通信路径的时刻(S315)，eNB81侧中的与通信路径相关的资源未被释放。因此，在设置变更前的通信路径与变更后的通信路径共存的状态之后，进行与通信路径的变更相关的处理。

即，在进行了设置变更后的通信路径的处理之后，进行与变更前的通信路径的释放相关的处理。由此，设置变更前的通信路径与变更后的通信路径共存的状态。

(第4：是与1个切片之间设置通信路径的案例，并且能够从SSF取得信息的情况)

图14是用于说明第4案例的状況的图。图14所示的案例与第3案例同样地，是UE90与切片SL1、SL2之间进行通信从而UE90从能够利用服务S1、S2的区域SA#1向不同的区域SA#2进行移动的情况。在该情况下，不仅UE90进行通信时的基站装置通过切换从eNB81变更至eNB82，而且需要变更为了利用服务S1、S2而进行通信的切片。但是，在移动目的地的区域SA#2中，有时不存在与切片SL1、SL2对应的切片。即，与第3案例同样地，在对DNS服务器350进行了查询的情况下，有时也不能从DNS服务器350取得与C-Plane控制服务器相关的信息。

在这种情况下，作为持续地利用2个服务的方法，在第4案例中，将移动前的eNB81与第1U-Plane控制节点212之间的通信路径以及移动前的eNB81与第2U-Plane控制节点222之间的通信路径这双方的功能切换为与设置于和2个服务没有关联性的切片SL6中的第6U-Plane控制节点(UPY)262之间的通信路径。切片SL6包含第6C-Plane控制节点(CPY)261和第6U-Plane控制节点262。

另外，eNB82、公共C-Plane控制节点301及UE90等未掌握在UE90的移动目的地的区域SA#2中通过使eNB82与哪个切片之间设置通信路径，从而使UE90能够利用服务S1、S2的情况。此外，当DNS服务器350未掌握切片SL6能够对应服务S1、S2的情况时，DNS服务器350也不能对公共C-Plane控制节点301提供该信息。因此，公共C-Plane控制节点301对SSF70进行查询，从而取得信息。

参照图15对上述那样的第4案例中的具体的处理过程进行说明。

首先，在UE90的移动前的eNB81与移动目的地的eNB82之间进行与切换相关的信号的收发(HO Request,HO Request ACK：S401)。以该信号为契机，在UE90、eNB81、eNB82之间进行与切换相关的处理(Handover Execution(切换执行)：S402)。

之后，从移动目的地的eNB82对公共C-Plane控制节点301发送进行与通信路径的变更相关的请求的信号(Path Switch Request(路径切换请求)：S403：变更请求取得步骤)。

与通信路径的变更相关的请求中包含用于确定UE90的信息、用于确定通信路径的信息(TU-1、TU-2)以及用于确定会话的信息(S-ID1、S-ID2)。在公共C-Plane控制节点301的变更请求取得部310中，当接收到来自eNB82的请求时，在判定部320中，通过与通信路径的变更相关的请求中所包含的信息，判定UE90是否与2个切片之间设置了通信路径(S404：判定步骤)。在本实施方式中，当与通信路径的变更相关的请求中包含多个用于确定通信路径的信息，并且包含多个用于确定会话的信息时，在判定部320中，能够判断出对UE90单独设置2个通信路径。由此，根据与通信路径的变更相关的请求中所包含的信息，在判定部320中，进行是否设置了多个通信路径的判定。并且，在判定部320中判定为对UE90设置了多个通信路径的情况下，进行图15所示的以下的处理。另外，在判定部320中判定为未对UE90设置多个通信路径，即，对于UE90仅与1个切片之间设置了通信路径、或者未设置通信路径的情况下，进行与公知的切换相关的处理。

进而，在判定部320中，确认2个切片SL1、SL2未覆盖eNB82所管辖的区域的情况(S404)。对于该点，与第2案例同样。

在判定部320中确认了对UE90设置有多个通信路径，并且切片SL1、SL2未覆盖区域SA#2的情况下，公共C-Plane控制节点301的通信处理部330对DNS服务器350查询与经由eNB82设置通信路径时的切片相关的信息(DNS Query Request(DNS查询请求)：S405：通信处理步骤)。更具体来说，通信处理部330对DNS服务器350发送ECGI(E-UTRAN Cell GlobalID(E-UTRAN小区全局ID))或者提供服务S1、S2的服务服务器的APN(APN1&2)，从而取得用于确定利用服务S1、S2时应进行通信的切片的C-Plane控制节点的信息。ECGI是用于确定UE90所属的小区的信息，即，是表示UE90的位置的信息。

在第4案例中，成为eNB82所管辖的区域SA#2未包含于图13的(A)所示的表中的状态。即，为针对位置及服务的种类未关联有用于确定接入目的地(设置通信路径的目的地)的切片的信息的状态。因此，DNS服务器350对公共C-Plane控制节点301通知表示不存在与服务对应的切片的信息，即，通知不存在C-Plane控制节点的信息(DNS Query Response(DNS查询应答)：S406：通信处理步骤)。

由此，在未从DNS服务器350提供用于确定C-Plane控制节点的信息的情况下，在公共C-Plane控制节点301侧，不能确定UE90为了利用服务S1、S2而与eNB82之间设置通信路径的对手方的切片。由此，在公共C-Plane控制节点301的通信处理部330中，对SSF70发送用于确定UE90的信息、用于确定想利用的服务的信息(APN1&APN2)以及ECGI，并进行查询(Policy Request：S407：通信处理步骤)。

与此相对，SSF70根据用于确定想利用的服务的信息、ECGI以及自身装置中保持的信息，确定UE90所属的区域中能够设置用于利用该服务的通信路径的切片。如图13的(C)所示，在SSF70中，由于按照每个服务保持了用于确定能够对应的切片的信息，因此利用该信息，提供对应的切片的信息(Policy Response(策略应答)：S408：通信处理步骤)。

在公共C-Plane控制节点301中，根据来自SSF70的信息，决定与包含第6C-Plane控制节点261的切片SL6之间设置与2个服务相关的会话(Selects CPY for both APN1&2Sessions：S409：通信处理步骤)。

由此，为如下的结构：即，在根据从DNS服务器350提供的信息，不能选择适当的切片(C-Plane控制节点)的情况下，对保持用于确定与服务对应的切片的信息的SSF70进行查询。由此，能够取得与用于利用2个服务的适当的切片(C-Plane控制节点)相关的信息。

另外，在DNS服务器350及SSF70不能对用于确定想利用的服务的信息(APN1&APN2)提供用于确定适当的切片的信息的情况下，由于不能进行服务的提供，因此服务的提供本身被中断。

在通信处理部330中，对通过到目前为止的处理所确定的C-Plane控制节点，即，第6C-Plane控制节点261发送用于设置与UE90相关的新的会话的请求(Create SessionRequest(会话创建请求)：S410：通信处理步骤)。会话的创建请求中包含用于确定接入目的地的eNB82的信息(eNB ID)、用于确定通过会话的创建而设置的通信路径的信息(TU-1及TU-2)以及用于确定服务的信息(APN1及APN2)。由此，在第6C-Plane控制节点261中，也识别出开设与2个服务相关的会话的情况。

在第6C-Plane控制节点261中，当接收到会话的创建请求时，根据该请求，通过公知的过程进行与通信路径的创建相关的处理。具体来说，作为创建通信路径的U-Plane控制节点，选择同一切片SL6的第6U-Plane控制节点262(UP Selection(UP选择)：S411)。之后，将用于确定eNB82的信息(eNB ID)与用于确定通信路径的信息(TU-1及TU-2)一起发送给第6U-Plane控制节点262，从而指示通信路径的创建(Create Session Request(会话创建请求)：S412)。第6U-Plane控制节点262在进行了与通信路径的创建相关的处理之后，与用于确定通信路径的信息(TU-1及TU-2)以及用于确定自身节点的信息(UP2ID)一起，将表示已进行了创建通信路径的处理的信息回复给第6C-Plane控制节点261(Create SessionResponse(会话创建应答)：S413)。接收到来自第6U-Plane控制节点262的回复的第6C-Plane控制节点261对公共C-Plane控制节点301通知与通信路径的创建相关的处理已完成，作为针对会话的创建请求(S410)的应答(Create Session Response(会话创建应答)：S414：通信处理步骤)。

在公共C-Plane控制节点301中，当接收到来自第4C-Plane控制节点241的应答(S414)时，对eNB82通知与通信路径的变更相关的处理已结束(Path Switch Request ack(路径切换请求确认)：S415：通信处理步骤)。对该信号关联用于确定第6U-Plane控制节点262的信息(UPY ID)，包含2个用于确定通信路径的信息(TU-1、TU-2)和2个用于确定会话的信息(S-ID1、S-ID2)。根据该信息，eNB82能够确定作为通信路径的对手方的节点。

之后，从eNB82对eNB81指示与通信路径相关的资源的释放(Release Resource(资源释放)：S416)。此外，公共C-Plane控制节点301对与eNB81之间设置了通信路径的切片SL1的第1C-Plane控制节点211和切片SL2的第2C-Plane控制节点221指示会话的释放，进行会话的释放处理(Delete Session Request/Response(会话删除请求/应答)：S417，S418：通信处理步骤)。对于从eNB82向eNB81的资源释放指示(S416)和来自公共C-Plane控制节点301的会话释放指示(S417、S418)，可以交换顺序。

通过以上的处理，UE90能够经由eNB82与第6U-Plane控制节点262之间进行用户数据的收发，从而能够经由eNB82利用服务S1、S2。

在上述处理中，在设置了eNB82与第6U-Plane控制节点262之间的通信路径的时刻(S415)，eNB81侧中的与通信路径相关的资源未被释放。因此，在设置变更前的通信路径与变更后的通信路径共存的状态之后，进行与通信路径的变更相关的处理。

即，在进行了设置变更后的通信路径处理之后，进行与变更前的通信路径的释放相关的处理。由此，设置变更前的通信路径与变更后的通信路径共存的状态。

如上所述，根据作为第1实施方式的通信控制装置的公共C-Plane控制节点301以及基于该公共C-Plane控制节点301的通信控制方法，通用于上述4个案例，一边设置变更前的通信路径与变更后的通信路径并存的状态，一边进行与通信路径的变更相关的处理。因此，UE90能够保持利用变更前的通信路径或者变更后的通信路径而能够收发用户数据的状态。因此，实现了一边利用分配给多个切片的服务，一边变更设置与多个切片之间的通信路径。

此外，通用于上述4个案例，在进行了设置变更后的通信路径处理之后，进行与变更前的通信路径的释放相关的处理。由此，即使在UE90与多个切片连接的状态下，也能够设置变更前的通信路径与变更后的通信路径共存的状态。

此外，在第2案例中，关于变更前的多个通信路径，分别变更为对与设置有变更前的通信路径的切片SL1、SL2不同、并且彼此不同的切片SL4、SL5中的U-Plane控制节点所设置的通信路径。作为这种结构，由于按照每个变更前的通信路径，在变更后也单独地设置通信路径，因此即使在变更了通信路径之后，也能够适当地收发用户数据。

另一方面，在第3案例和第4案例中，对于变更前的多个通信路径，变更为对与设置有变更前的通信路径的切片SL1、SL2不同的切片(在第3案例的情况下为切片SL4，在第4案例的情况下为切片SL6)中的U-Plane控制节点所设置的一个通信路径。在上述实施方式也进行了说明，但也存在不能对变更前的多个切片中的控制节点分别单独地设置与通信路径对应的通信路径那样的案例。在该情况下，如上所述，设为将变更前的多个通信路径汇总为针对1个切片的控制节点所设置的1个通信路径的结构，从而即使在变更了通信路径之后，也能够适当地收发与多个服务相关的用户数据。

另外，在第3案例和第4案例中，对将多个通信路径(在上述实施方式中为2个通信路径)汇总为1个通信路径的结构进行了说明，但这样汇总为1个通信路径的多个通信路径可以不是对UE90设置的所有的通信路径。例如，当在变更前对UE90设置了3个通信路径时，可以在变更后将3个通信路径中的2个通信路径汇总为1个通信路径，对于剩余的1个通信路径，在变更后也作为1个通信路径单独设置。在该情况下，与UE90相关的变更后的通信路径的数量为2个。这样，可以不是将与UE90相关的所有的通信路径汇总为1个通信路径。对于该点，在后述的第2实施方式中也是同样的。

(第2实施方式：通过C-Plane控制节点一并进行通信路径的管理的***)

接着，对将本发明的通信控制装置应用于不具有公共C-Plane控制节点的网络结构的情况进行说明。

图16是用于说明包含由第2实施方式的***构建的切片结构的核心网络N2的图，与第1实施方式的图2对应。

如图16所示，在第2实施方式中，也生成作为第1服务(服务S1)用的切片的切片SL1(第1切片)、作为第2服务(服务S2)用的切片的切片SL2(第2切片)、以及具有作为与切片SL1或切片SL2的控制相关的控制装置的功能的切片即切片SL3(第3切片)。NFVO30对切片SL1分配服务S1，对切片SL2分配服务S2。对于执行服务S1及服务S2的功能，根据从切片SL3发送的信号等进行处理，或者进行对包含具有作为通信控制装置的功能的节点的切片SL3请求提供信息的处理。

在第2实施方式中，在与服务S1、S2对应的切片SL1、SL2中未设置C-Plane控制节点。即，作为与服务S1相关的节点，仅存在切片SL1的第1U-Plane控制节点(UP1)212。此外，作为与服务S2相关的节点，仅存在切片SL2的第2U-Plane控制节点(UPX1)222。

此外，切片SL3中包含C-Plane控制节点305。C-Plane控制节点305根据来自用户侧的指示，执行用户与各切片之间的通信路径的开设及断开的处理。即，在第2实施方式中，在提供服务的切片中未设置C-Plane控制节点作为节点，由设置于切片SL3中的C-Plane控制节点305进行针对利用服务时所经由的各切片的通信路径的开设及断开的处理。该点是与第1实施方式的区别点。

在第2实施方式的***中，设置于切片SL3中的C-Plane控制节点305具有第1实施方式中的公共C-Plane控制节点301的功能以及设置于各切片中的C-Plane控制节点的功能。即，C-Plane控制节点305作为进行对多个切片的控制节点所设置的与UE90相关的通信路径的控制的通信控制装置发挥功能。

另外，在LTE网络中的EPC(Evolved Packet Core：演进型分组核心)中，例如，MME(Mobility Management Entity：移动管理实体)能够采用具有与第2实施方式的C-Plane控制节点305相关的功能的结构。此外，例如，SGW(Serving Gateway：服务网关)及PGW(PacketData Network Gateway:分组数据网络网关)能够采用具有与第2实施方式的U-Plane控制节点相关的功能的结构。

说明在这样的第2实施方式的***中，当UE90与多个切片之间进行通信时，由于某些情况，需要进行UE90为了利用服务而进行通信的切片的变更、或者需要进行切片与UE90之间的通信路径的变更的情况下的处理。在第2实施方式的***中，由C-Plane控制节点305作为主体执行上述处理。因此，C-Plane控制节点305与公共C-Plane控制节点301同样地，具有图5所示的变更请求取得部310、判定部320以及通信处理部330。

各部的的功能与公共C-Plane控制节点301是同样的。变更请求取得部310具有取得与和切片SL1等之间的通信路径的变更相关的请求的功能。此外，判定部320具有判定与通信路径的变更相关的请求的对象UE90是否与多个切片之间设置了通信路径的功能。进而，通信处理部330根据与通信路径的变更相关的请求进行处理，以使UE90一边利用服务，一边进行通信路径的变更。

接着，对包含C-Plane控制节点305的核心网络N2中的与UE90相关的通信路径的变更的具体处理进行说明。在UE90一边利用多个服务一边变更其通信路径的情况下，与第1实施方式同样地，考虑了4个案例。下面，对于4个案例，对各自的状况进行说明，并且参照时序图对具体的处理进行说明。另外，关于4个案例中的处理的内容，由于与第1实施方式通用的部分较多，有时简化说明。

(第1：仅变更通信路径的案例)

图17是用于说明第1案例的状況的图。图17所示的案例例如是UE90与切片SL1、SL2之间进行通信从而UE90在能够利用服务S1、S2的区域SA#1内进行移动的情况。在该情况下，UE90进行通信时的基站装置通过切换从eNB81变更至eNB82，但能够继续进行与切片SL1、SL2之间的通信而利用服务S1、S2。因此，将移动前的eNB81与第1U-Plane控制节点212之间的通信路径切换为eNB82与第1U-Plane控制节点212之间的通信路径，并且将移动前的eNB81与第2U-Plane控制节点222之间的通信路径切换为eNB82与第2U-Plane控制节点222之间的通信路径，从而能够持续利用服务S1、S2。

参照图18对这样的案例中的具体的处理过程进行说明。

首先，在UE90的移动前的eNB81与移动目的地的eNB82之间进行与切换相关的信号的收发(HO Request(HO请求),HO Request ACK(HO请求确认)：S501)。以该信号为契机，在UE90、eNB81、eNB82之间进行与切换相关的处理(Handover Execution(切换执行)：S502)。

之后，从移动目的地的eNB82对C-Plane控制节点305发送进行与通信路径的变更相关的请求的信号(Path Switch Request(路径切换请求)：S503：变更请求取得步骤)。另外，在此，对UE90进行切换的情况进行了说明，进行与通信路径的变更相关的请求的信号为“Path Switch Request(路径切换请求)”，但进行与通信路径的变更相关的请求的信号可以根据变更通信路径的情况而适当地变更。这在其它案例中也是同样的。

与通信路径的变更相关的请求中包含用于确定UE90的信息、用于确定通信路径的信息(TU-1、TU-2)以及用于确定会话的信息(S-ID1、S-ID2)。在C-Plane控制节点305的变更请求取得部310中，当接收到来自eNB82的请求时，在判定部320中，根据与通信路径的变更相关的请求中所包含的信息，判定UE90是否与2个切片之间设置了通信路径(S504：判定步骤)。在判定部320中判定为对UE90设置了多个通信路径的情况下，进行图18所示的以下的处理。另外，在判定部320中判定为未对UE90设置多个通信路径，即，对于UE90仅与1个切片之间设置了通信路径、或者未设置通信路径的情况下，进行与公知的切换相关的处理。

在判定部320中判定为对UE90设置了多个通信路径的情况下，C-Plane控制节点305的通信处理部330根据用于确定会话的信息等，对第1U-Plane控制节点212及第2U-Plane控制节点222发送与通信路径的变更相关的指示(Path Switch Request(承载修改请求)：S505，S506：通信处理步骤)。与通信路径的变更相关的指示中包含用于确定变更目的地的eNB82的信息(eNB ID)以及用于确定作为变更对象的通信路径的信息(TU-1或TU-2)。另外，可以变更向2个节点发送与通信路径的变更相关的指示的顺序(S505，S506：通信处理步骤)。

在第1U-Plane控制节点212中，当接收到与通信路径的变更相关的指示时，在进行了与通信路径的创建相关的处理之后，与用于确定自身节点的信息(UP1ID)一起，将表示已进行了创建通信路径的处理的信息回复给C-Plane控制节点301(Modify Bearer Response(承载修改应答)：S507：通信处理步骤)。在第2U-Plane控制节点222中也同样，在进行了与通信路径的创建相关的处理之后，与用于确定自身节点的信息(UPX1ID)一起，将表示已进行了创建通信路径的处理的信息回复给C-Plane控制节点305(Modify Bearer Response(承载修改应答)：S508：通信处理步骤)。

另外，由于单独地进行切片SL1中的处理和切片SL2中的处理，因此上述处理(S505～S508)的顺序可能与图18所示的顺序不同。

在C-Plane控制节点305中，当接收到来自第1U-Plane控制节点212的应答(S507)、和来自第2U-Plane控制节点222的应答(S508)时，对eNB82通知与通信路径的变更相关的处理已结束(Path Switch Request ack(路径切换请求确认)：S509：通信处理步骤)。该信号中包含用于确定第1U-Plane控制节点212的信息(UP1ID)以及用于确定第2U-Plane控制节点222的信息(UPX1ID)。根据该信息，eNB82能够确定作为通信路径的对手方的节点。

之后，从eNB82对eNB81指示与通信路径相关的资源的释放(Release Resource(资源释放)：S510)。由此，UE90能够经由eNB82与第1U-Plane控制节点212之间进行用户数据的收发(S511)，并且能够经由eNB82与第2U-Plane控制节点222之间进行用户数据的收发(S512)。由此，UE90能够经由eNB82利用服务S1、S2。

在上述处理中，在设置了eNB82与第1U-Plane控制节点212及第2U-Plane控制节点222之间的通信路径的时刻(S509)，eNB81侧中的与通信路径相关的资源未被释放。因此，在设置了变更前的通信路径与变更后的通信路径共存的状态之后，进行与通信路径的变更相关的处理。

在上述处理中，在设置了eNB82与第1U-Plane控制节点212及第2U-Plane控制节点222之间的通信路径的时刻(S509)，eNB81侧中的与通信路径相关的资源未被释放。因此，在设置了变更前的通信路径与变更后的通信路径共存的状态之后，进行与通信路径的变更相关的处理。

即，在进行了设置变更后的通信路径的处理之后，进行与变更前的通信路径的释放相关的处理。由此，设置变更前的通信路径与变更后的通信路径共存的状态。

(第2：对2个切片新设置通信路径的案例)

图19是用于说明第2案例的状況的图。图19所示的案例例如是UE90从区域SA#1向区域SA#2进行移动的情况。在该情况下，UE90进行通信时的基站装置不仅通过切换从eNB81变更至eNB82，而且将为了利用服务S1、S2而进行通信的切片从切片SL1、SL2变更为切片SL4、SL5。即，移动前的eNB81与第1U-Plane控制节点212之间的通信路径切换为eNB82与第4U-Plane控制节点242之间的通信路径。此外，移动前的eNB81与第2U-Plane控制节点222之间的通信路径切换为eNB82与第5U-Plane控制节点252之间的通信路径。另外，C-Plane控制节点305对DNS(Domain Name System，域名服务器)服务器350进行查询从而取得与切片SL4、SL5相关的信息这一点与第1实施方式同样。

参照图20对这样的案例中的具体的处理过程进行说明。

首先，在UE90的移动前的eNB81与移动目的地的eNB82之间进行与切换相关的信号的收发(HO Request,HO Request ACK：S601)。以该信号为契机，在UE90、eNB81、eNB82之间进行与切换相关的处理(Handover Execution(切换执行)：S602)。

之后，从移动目的地的eNB82对C-Plane控制节点305发送进行与通信路径的变更相关的请求的信号(Path Switch Request(路径切换请求)：S603：变更请求取得步骤)。

与通信路径的变更相关的请求中包含用于确定UE90的信息、用于确定通信路径的信息(TU-1、TU-2)以及用于确定会话的信息(S-ID1、S-ID2)。在C-Plane控制节点305的变更请求取得部310中，当接收到来自eNB82的请求时，在判定部320中根据与通信路径的变更相关的请求中所包含的信息，判定UE90是否与2个切片之间设置了通信路径(S604：判定步骤)。在判定部320中判定为对UE90设置了多个通信路径的情况下，进行图19所示的以下的处理。另外，在判定部320中判定为未对UE90设置多个通信路径，即，对于UE90仅与1个切片之间设置了通信路径、或者未设置通信路径的情况下，进行与公知的切换相关的处理。

进而，在判定部320中，确认2个切片SL1、SL2未覆盖eNB82所管辖的区域的情况(S604)。

在判定部320中确认了对UE90设置了多个通信路径、并且切片SL1、SL2未覆盖eNB82所管辖的区域的情况下，C-Plane控制节点305的通信处理部330对DNS服务器350查询与经由eNB82设置通信路径时的切片相关的信息(DNS Query Request/Response(DNS查询请求/应答)：S605：通信处理步骤)。更具体来说，取得用于确定在经由eNB82利用服务S1、S2时能够进行通信的C-Plane控制节点的信息。其结果，在通信处理部330中，根据从DNS服务器350取得的与C-Plane控制节点相关的信息，基于在eNB82之间想要收发用户数据的服务服务器的APN(Access Point Name)和UE90的位置(即，接入的eNB82的信息)，确定为了利用服务S1而应设置通信路径的切片(在此，为切片SL4)的U-Plane控制节点242和为了利用服务S2而应设置通信路径的切片(在此，为切片SL5)的U-Plane控制节点252(S606：通信处理步骤)。

在通信处理部330中，对所确定的2个U-Plane控制节点，即第4U-Plane控制节点242和第5U-Plane控制节点252发送用于设置与UE90相关的新的会话的请求(CreateSession Request(会话创建请求)：S607、S608：通信处理步骤)。会话的创建请求中包含用于确定接入目的地的eNB82的信息(eNB ID)以及用于确定通过会话的创建而设置的通信路径的信息(TU-1或TU-2)。另外，能够变更向2个节点发送会话创建请求的顺序(S607、S608)

在第4U-Plane控制节点242中，当接收到会话的创建请求时，在根据该请求进行了与通信路径的创建相关的处理之后，与用于确定自身节点的信息(UP2ID)一起，将表示已进行了创建通信路径的处理的信息通知给C-Plane控制节点305(Create Session Response(会话创建应答)：S609：通信处理步骤)。在第5U-Plane控制节点252中，当接收到会话的创建请求时，在进行了与通信路径的创建相关的处理之后，与用于确定自身节点的信息(UP2ID)一起，将表示已进行了创建通信路径的处理的信息通知给C-Plane控制节点305(Create Session Response(会话创建应答)：S610：通信处理步骤)。

另外，由于单独地进行切片SL4中的处理和切片SL5中的处理，上述处理(S607～S610)的顺序可能与图20所示的顺序不同。

在C-Plane控制节点305中，当接收到来自第4U-Plane控制节点242的应答(S609)和来自第5U-Plane控制节点252的应答(S610)时，对eNB82通知与通信路径的变更相关的处理已结束(Path Switch Request ack(路径切换请求确认)：S611：通信处理步骤)。该信号中包含用于确定第4U-Plane控制节点242的信息(UP2ID)以及用于确定第5U-Plane控制节点252的信息(UPX2ID)。根据该信息，eNB82能够确定作为通信路径的对手方的节点。

之后，从eNB82对eNB81指示与通信路径相关的资源的释放(Release Resource(资源释放)：S612)。此外，C-Plane控制节点305对与eNB81之间设置了通信路径的切片SL1的第1U-Plane控制节点212和切片SL2的第2U-Plane控制节点222指示会话的释放，进行会话的释放处理(Delete Session Request/Response(会话删除请求/应答)：S613，S614：通信处理步骤)。对于从eNB82向eNB81的资源释放指示(S612)和来自C-Plane控制节点305的会话释放指示(S613，S614)，可以交换顺序。

通过以上的处理，UE90能够经由eNB82与第4U-Plane控制节点242之间进行用户数据的收发(S615)，并且能够经由eNB82与第5U-Plane控制节点252之间进行用户数据的收发(S616)。由此，UE90能够经由eNB82利用服务S1、S2。

在上述处理中，在设置了eNB82与第4U-Plane控制节点242及第5U-Plane控制节点252之间的通信路径的时刻(S611)，eNB81侧中的与通信路径相关的资源未被释放。因此，在设置了变更前的通信路径与变更后的通信路径共存的状态之后，进行与通信路径的变更相关的处理。

即，在进行了设置变更后的通信路径的处理之后，进行与变更前的通信路径的释放相关的处理。由此，设置变更前的通信路径与变更后的通信路径共存的状态。

(第3：与1个切片之间设置通信路径的案例，并且能够从DNS服务器取得信息的情况)

图21是用于说明第3案例的状況的图。图21所示的案例例如是UE90从区域SA#1向区域SA#2进行移动的情况。在该情况下，UE90进行通信时的基站装置通过切换从eNB81变更至eNB82。此外，需要变更为了利用服务S1、S2而进行通信的切片。但是，在移动目的地的区域SA#2中，存在与切片SL1对应的切片SL4，但有时不存在与切片SL2对应的切片。在第3案例中，将移动前的eNB81与第1U-Plane控制节点212之间的通信路径以及移动前的eNB81与第2U-Plane控制节点222之间的通信路径双方的功能切换为eNB82与第4U-Plane控制节点242之间的通信路径。

另外，C-Plane控制节点305对DNS服务器350及SSF70进行查询从而取得确定为设置用于利用服务S1、S2的通信路径的切片的信息这一点与第1实施方式同样。

参照图22对上述那样的第3案例中的具体的处理过程进行说明。

首先，在UE90的移动前的eNB81与移动目的地的eNB82之间进行与切换相关的信号的收发(HO Request(HO请求),HO Request ACK(HO请求确认)：S701)。以该信号为契机，在UE90、eNB81、eNB82之间进行与切换相关的处理(Handover Execution(切换执行)：S702)。

之后，从移动目的地的eNB82对C-Plane控制节点305发送进行与通信路径的变更相关的请求的信号(Path Switch Request(路径切换请求)：S703：变更请求取得步骤)。

与通信路径的变更相关的请求中包含用于确定UE90的信息、用于确定通信路径的信息(TU-1、TU-2)以及用于确定会话的信息(S-ID1、S-ID2)。在C-Plane控制节点305的变更请求取得部310中当接收到来自eNB82的请求时，在判定部320中，根据与通信路径的变更相关的请求中所包含的信息，判定UE90是否与2个切片之间设置了通信路径(S704：判定步骤)。在判定部320中判定为对UE90设置了多个通信路径的情况下，进行图22所示的以下的处理。另外，在判定部320中判定为未对UE90设置多个通信路径，即，对于UE90仅与1个切片之间设置了通信路径、或者未设置通信路径的情况下，进行与公知的切换相关的处理。

进而，在判定部320中，确认2个切片SL1、SL2未覆盖eNB82所管辖的区域的情况(S704)。该点与第2案例是同样的。

在判定部320中确认了对UE90设置了多个通信路径，并且切片SL1、SL2未覆盖区域SA#2的情况下，C-Plane控制节点305的通信处理部330对DNS服务器350查询与经由eNB82设置通信路径时的切片相关的信息(DNS Query Request(DNS查询请求)：S705：通信处理步骤)。更具体来说，通信处理部330对DNS服务器350发送ECGI(E-UTRAN Cell Global ID(E-UTRAN小区全局ID))或者提供服务S1、S2的服务服务器的APN(APN1&2)，从而取得用于确定利用服务S1、S2时应进行通信的切片的U-Plane控制节点的信息。

在第3案例的情况下，仅对从DNS服务器350发送的结果返回用于确定1个U-Plane控制节点的信息(DNS Query Response(DNS查询应答)：S706：通信处理步骤)。在此，从DNS服务器350对C-Plane控制节点305发送用于确定第4U-Plane控制节点242的信息。由此，在C-Plane控制节点305中，决定与包含第4U-Plane控制节点242的切片SL4之间设置2个与服务相关的会话(Selects UP2for both APN1&2Sessions(为APN1&2会话选择UP2)：S709：通信处理步骤)。

另外，根据DNS服务器350所保持的信息，有时不能在UE90所属的区域中确定能够与服务S1、S2对应的切片。在该情况下，与第1实施方式同样地，C-Plane控制节点305的通信处理部330对SSF70发送用于确定UE90的信息、用于确定想利用的服务的信息(APN1&APN2)以及ECGI，并进行查询(Policy Request(策略请求)：S707：通信处理步骤)。由此，在SSF70中，根据从C-Plane控制节点305发送的用于确定服务的信息，提供对应的切片信息(PolicyResponse(策略应答)：S708：通信处理步骤)。在此，作为用于确定切片SL4的信息，提供了用于确定第4U-Plane控制节点242的信息。

并且，在C-Plane控制节点305中，根据来自DNS服务器350的信息和来自SSF70的信息，决定与包含第4U-Plane控制节点241的切片SL4之间设置2个与服务相关的会话(Selects UP2for both APN1&2Sessions(为APN1&2会话选择UP2)：S709：通信处理步骤)。

这样，在仅根据DNS服务器350所保持的信息，不能选择适当的切片(U-Plane控制节点)的情况下，SSF70作为保持用于确定与服务对应的切片的信息的结构，可以是C-Plane控制节点305也对SSF70进行查询，从而确定用于利用2个服务的适当的切片(U-Plane控制节点)的结构。该点也与第1实施方式同样。

另外，在DNS服务器350及SSF70不能对用于确定想利用的服务的信息(APN1&APN2)提供用于确定适当的切片的信息的情况下，由于不能进行服务的提供，因此服务的提供本身被中断。

在通信处理部330中，对通过到目前为止的处理所确定的U-Plane控制节点，即第4U-Plane控制节点242发送用于设置与UE90相关的新的会话的请求(Create SessionRequest(会话创建请求)：S710：通信处理步骤)。会话的创建请求中包含用于确定接入目的地的eNB82的信息(eNB ID)、和用于确定通过会话的创建而设置的通信路径的信息(TU-1及TU-2)以及用于确定服务的信息(APN1及APN2)。由此，在第4U-Plane控制节点242中，也识别出开设与2个服务相关的会话。

在第4U-Plane控制节点242中，在进行了与通信路径的创建相关的处理之后，与用于确定通信路径的信息(TU-1及TU-2)以及用于确定自身节点的信息(UP2ID)一起，将表示已进行了创建通信路径的处理的信息通知给C-Plane控制节点305(Create SessionResponse(会话创建应答)：S711：通信处理步骤)。

在C-Plane控制节点305中，当接收到来自第4U-Plane控制节点242的应答(S711)时，对eNB82通知与通信路径的变更相关的处理已结束(Path Switch Request ack：S712：通信处理步骤)。对该信号关联用于确定第4U-Plane控制节点242的信息(UP2ID)，包含用于确定2个通信路径的信息(TU-1、TU-2)和用于确定2个会话的信息(S-ID1、S-ID2)。根据该信息，eNB82能够确定作为通信路径的对手方的节点。

之后，从eNB82对eNB81指示与通信路径相关的资源的释放(Release Resource(释放资源)：S713)。此外，C-Plane控制节点305对与eNB81之间设置了通信路径的切片SL1的第1U-Plane控制节点212和切片SL2的第2U-Plane控制节点222指示会话的释放，进行会话的释放处理(Delete Session Request/Response(会话删除请求/应答)：S714、S715：通信处理步骤)。对于从eNB82向eNB81的资源释放指示(S713)和来自C-Plane控制节点305的会话释放指示(S714，S715)，可以交换顺序。

通过以上的处理，UE90能够经由eNB82与第4U-Plane控制节点242之间进行用户数据的收发，从而能够经由eNB82利用服务S1、S2(S716)。

另外，在上述第3示例中，说明了在移动目的地的区域SA#2中，存在与切片SL1对应的切片SL4，但有时不存在与切片SL2对应的切片的情况，但也可以是相反的情况。即，在存在与切片SL1对应的切片，但不存在与切片SL2对应的切片SL5的情况下，也能够按照与上述说明的处理同样的方法进行处理。

在上述处理中，在设置了eNB82与第4U-Plane控制节点242之间的通信路径的时刻(S712)，eNB81侧中的与通信路径相关的资源未被释放。因此，在设置了变更前的通信路径与变更后的通信路径共存的状态之后，进行与通信路径的变更相关的处理。

即，在进行了设置变更后的通信路径的处理之后，进行与变更前的通信路径的释放相关的处理。由此，设置变更前的通信路径与变更后的通信路径共存的状态。

(第4：与1个切片之间设置通信路径的案例，并且能够从SSF取得信息的情况)图23是用于说明第4案例的状況的图。图23所示的案例与第3案例同样地，是UE90从区域SA#1向区域SA#2进行移动的情况。但是，是如下情况：在移动目的地的区域SA#2中，未确定与切片SL1、SL2对应的切片，与第3案例同样地，在对DNS服务器350进行了查询的情况下，不能从DNS服务器350取得与C-Plane控制服务器相关的信息。在第4案例中，切换为与设置于和2个服务没有关联性的切片SL6中的第6U-Plane控制节点(UPY)262之间的通信路径。

另外，C-Plane控制节点305对DNS服务器350及SSF70进行查询，从而取得确定为设置用于利用服务S1、S2的通信路径的切片的信息这一点与第1实施方式是同样的。

参照图24对上述那样的第4案例中的具体的处理过程进行说明。

首先，在UE90的移动前的eNB81与移动目的地的eNB82之间进行与切换相关的信号的收发(HO Request,HO Request ACK(HO请求，HO请求确认)：S801)。以该信号为契机，在UE90、eNB81、eNB82之间进行与切换相关的处理(Handover Execution(切换执行)：S802)。

之后，从移动目的地的eNB82对C-Plane控制节点305发送进行与通信路径的变更相关的请求的信号(Path Switch Request(路径切换请求)：S803：变更请求取得步骤)。

与通信路径的变更相关的请求中包含用于确定UE90的信息、用于确定通信路径的信息(TU-1、TU-2)以及确定会话的信息(S-ID1、S-ID2)。在C-Plane控制节点305的变更请求取得部310中当接收到来自eNB82的请求时，在判定部320中，根据与通信路径的变更相关的请求中所包含的信息，判定UE90是否与2个切片之间设置了通信路径(S804：判定步骤)。在判定部320中判定为对UE90设置了多个通信路径的情况下，进行图24所示的以下的处理。另外，在判定部320中判定为未对UE90设置多个通信路径，即，对于UE90仅与1个切片之间设置了通信路径、或者未设置通信路径的情况下，进行与公知的切换相关的处理。

进而，在判定部320中，确认2个切片SL1、SL2未覆盖eNB82所管辖的区域(S804)。该点与第2案例同样。

在判定部320中确认了对UE90设置了多个通信路径，并且切片SL1、SL2未覆盖区域SA#2的情况下，C-Plane控制节点305的通信处理部330对DNS服务器350查询与经由eNB82设置通信路径时的切片相关的信息(DNS Query Request(DNS查询请求)：S805：通信处理步骤)。更具体来说，通信处理部330对DNS服务器350发送ECGI(E-UTRAN Cell Global ID(E-UTRAN小区全局ID))或者提供服务S1、S2的服务服务器的APN(APN1&2)，从而取得用于确定利用服务S1、S2时应进行通信的切片的U-Plane控制节点的信息。

在第4案例中，eNB82所管辖的区域SA#2成为未包含于图13的(A)所示的表中的状态。即，为针对位置和服务的种类未关联用于确定接入目的地(设置通信路径的目的地)的切片的信息的状态。因此，DNS服务器350对C-Plane控制节点305通知表示不存在与服务对应的切片的信息，即，通知不存在C-Plane控制节点的信息(DNS Query Response(DNS查询应答)：S806：通信处理步骤)。

如此，在从DNS服务器350未提供用于确定C-Plane控制节点的信息的情况下，在C-Plane控制节点305侧，不能确定UE90为了利用服务S1、S2而与eNB82之间设置通信路径的对手方的切片。由此，在C-Plane控制节点305的通信处理部330中，对SSF70发送用于确定UE90的信息、用于确定想利用的服务的信息(APN1&APN2)、以及ECGI，并进行查询(PolicyRequest(策略请求)：S807：通信处理步骤)。

与此相对，SSF70根据用于确定想利用的服务的信息和EGCI，基于自身装置中所保持的信息，确定UE90所属的区域中能够设置用于利用该服务的通信路径的切片，提供对应的切片的信息(Policy Response(策略应答)：S808：通信处理步骤)。

在C-Plane控制节点305中，根据来自SSF70的信息，决定与包含第6U-Plane控制节点262的切片SL6之间设置与2个服务相关的会话(Selects UPY for both APN1&2Sessions(为APN1&2会话选择UPY)：S809：通信处理步骤)。

另外，在DNS服务器350及SSF70不能对用于确定想利用的服务的信息(APN1&APN2)提供用于确定适当的切片的信息的情况下，由于不能进行服务的提供，因此服务的提供本身被中断。

在通信处理部330中，对通过到目前为止的处理所确定的C-Plane控制节点，即第6U-Plane控制节点262发送用于设置与UE90相关的新的会话的请求(Create SessionRequest(会话创建请求)：S810)。会话的创建请求中包含用于确定接入目的地的eNB82的信息(eNB ID)、和用于确定通过会话的创建而设置的通信路径的信息(TU-1及TU-2)以及用于确定服务的信息(APN1及APN2)。由此，在第6U-Plane控制节点262中，也识别出开设与2个服务相关的会话。

在第6U-Plane控制节点262中，当接收到会话的创建请求时，在进行了与通信路径的创建相关的处理之后，与用于确定通信路径的信息(TU-1及TU-2)以及用于确定自身节点的信息(UP2ID)一起，将表示已进行了创建通信路径的处理的信息通知给C-Plane控制节点305(Create Session Response(会话创建应答)：S811：通信处理步骤)。

在C-Plane控制节点305中，当接收到来自第6U-Plane控制节点262的应答(S811)时，对eNB82通知与通信路径的变更相关的处理已结束(Path Switch Request ack(路径切换请求确认)：S812：通信处理步骤)。对该信号关联用于确定第6U-Plane控制节点262的信息(UPY ID)，包含用于确定2个通信路径的信息(TU-1、TU-2)和用于确定2个会话的信息(S-ID1、S-ID2)。根据该信息，eNB82能够确定作为通信路径的对手方的节点。

之后，从eNB82对eNB81指示与通信路径相关的资源的释放(Release Resource：S813)。此外，C-Plane控制节点305对与eNB81之间设置了通信路径的切片SL1的第1U-Plane控制节点212和切片SL2的第2U-Plane控制节点222指示会话的释放，进行会话的释放处理(Delete Session Request/Response(会话删除请求/应答)：S814，S815：通信处理步骤)。对于从eNB82向eNB81的资源释放指示(S813)和来自C-Plane控制节点305的会话释放指示(S814，S815)，可以交换顺序。

通过以上的处理，UE90能够经由eNB82与第6U-Plane控制节点262之间进行用户数据的收发，从而能够经由eNB82利用服务S1、S2(S816)。

在上述处理中，在设置了eNB82与第6U-Plane控制节点262之间的通信路径的时刻(S812)，eNB81侧中的与通信路径相关的资源未被释放。因此，在设置变更前的通信路径与变更后的通信路径共存的状态之后，进行与通信路径的变更相关的处理。

即，在进行了设置变更后的通信路径的处理之后，进行与变更前的通信路径的释放相关的处理。由此，设置变更前的通信路径与变更后的通信路径共存的状态。

如上所述，作为第2实施方式的通信控制装置的C-Plane控制节点305及基于该C-Plane控制节点305的通信控制方法通用于上述4个案例，一边设置变更前的通信路径与变更后的通信路径并存的状态，一边进行与通信路径的变更相关的处理。因此，UE90能够保持利用变更前的通信路径或者变更后的通信路径而能够收发用户数据的状态。因此，实现一边利用分配给多个切片的服务，一边变更与多个切片之间设置的通信路径。

此外，通用于上述4个案例，在进行了设置变更后的通信路径的处理之后，进行与变更前的通信路径的释放相关的处理。由此，即使在UE90与多个切片连接的状态下，也能够设置变更前的通信路径与变更后的通信路径共存的状态。

此外，在第2案例中，将变更前的多个通信路径分别变更为对与设置有变更前的通信路径的切片SL1、SL2不同、并且彼此不同的切片SL4、SL5中的U-Plane控制节点所设置的通信路径。作为这种结构，由于按照每个变更前的通信路径，在变更后也单独地设置通信路径，因此即使在变更了通信路径之后，也能够适当地收发用户数据。

另一方面，在第3案例和第4案例中，将变更前的多个通信路径变更为对与设置有变更前的通信路径的切片SL1、SL2不同的切片(在第3案例的情况下为切片SL4，在第4案例的情况下为切片SL6)中的U-Plane控制节点所设置的一个通信路径。在上述实施方式也进行了说明，但也存在不能对变更前的多个切片中的控制节点分别单独地设置与通信路径对应的通信路径那样的案例。在该情况下，如上所述，采用将变更前的多个通信路径汇总为针对1个切片的控制节点所设置的1个通信路径的结构，从而即使在变更了通信路径之后，也能够适当地收发与多个服务相关的用户数据。

以上对本实施方式进行了详细说明，但对本领域技术人员来说，显而易见的是本发明不限于本说明书中说明的实施方式。本发明能够在不脱离通过权利要求书的记载所确定的本发明的主旨和范围内实施为修正和变更形态。因此，本说明书的记载的目的在于例示说明，对本发明不具有任何限制性的意思。

信息的通知不限于本说明书中说明的形态/实施方式，也可以通过其它方法进行。例如，信息的通知可以通过物理层信令(例如，DCI(Downlink Control Information：下行链路控制信息)、UCI(Uplink Control Information：上行链路控制信息))、高层信令(例如，RRC(Radio Resource Control：无线资源控制)信令、MAC(Medium Access Control：介质访问控制)信令、广播信息(MIB(Master Information Block：主信息块)、SIB(SystemInformation Block：***信息块))、其它信号或这些的组合来实施。此外，RRC信令也可以称为RRC消息，例如可以是RRC连接创建(RRC Connection Setup)消息、RRC连接重新设定(RRC Connection Reconfiguration)消息等。

本说明书中说明的各形态/实施方式也可以应用于LTE(Long Term Evolution：长期演进)、LTE-A(LTE-Advanced)、SUPER 3G、IMT-Advanced、4G、5G、FRA(Future RadioAccess，未来的无线接入)、W-CDMA(注册商标)、GSM(注册商标)、CDMA2000、UMB(UltraMobile Broadband，超移动宽带)、IEEE 802.11(Wi-Fi)、IEEE 802.16(WiMAX)、IEEE802.20、UWB(Ultra-WideBand，超宽带)、Bluetooth(注册商标)、使用其它适当***的***和/或据此扩展的下一代***。

对于本说明书中说明的各形态/实施方式的处理过程、时序、流程等，在不矛盾的情况下，可以交换顺序。例如，对于本说明书中说明的方法，通过例示的顺序提示各种各样的步骤的要素，但不限于所提示的特定的顺序。

对于在本说明书中由特定的装置执行的特定动作，也存在根据情况而由其上位节点(upper node)执行的情况。例如，在特定的装置是基站的情况下，在由具有基站的1个或多个网络节点(network nodes)构成的网络中，对于为了进行与终端的通信而进行的各种各样的动作，可以由基站和/或基站以外的其它网络节点来进行，这是显而易见的。上述例示了基站以外的其它网络节点为1个的情况，但也可以是多个其它网络节点的组合。

可以从高层(或低层)向低层(或高层)输出信息等。也可以经由多个网络节点输入或输出。

输入输出的信息等可以保存在特定的位置(例如，内存)，也可以在管理表中进行管理。可以重写、更新或追记输入输出的信息等。也可以删除所输出的信息等。还可以向其它装置发送所输入的信息等。

可以通过1比特所表示的值(0或1)进行判定，也可以通过布尔值(Boolean：true或false)进行判定，还可以通过数值的比较(例如，与规定值的比较)进行判定。

本说明书中说明的各形态/实施方式可以单独使用，也可以组合使用，还可以根据执行情况切换使用。此外，规定信息的通知不限于显式地(例如，“是X”的通知)进行，也可以隐式地(例如，不进行该规定信息的通知)进行。

对于软件，无论被称为软件、固件、中间件、微码、硬件描述语言，还是以其它名称来称呼，均应当广泛地解释为是指命令、命令集、代码、代码段、程序代码、程序(program)、子程序、软件模块、应用、软件应用、软件包、例行程序(routine)、子程序(subroutine)、对象、可执行文件、执行线程、过程、功能等。

此外，可以经由传输介质收发软件、命令等。例如，在使用同轴电缆、光纤电缆、双绞线及数字用户线(DSL)等有线技术和/或红外线、无线及微波等无线技术从网站、服务器或其它远程源发送软件的情况下，这些有线技术和/或无线技术包含在传输介质的定义内。

可以使用各种各样不同的技术中的任意一种来表示本说明书中说明的信息、信号等。例如，可以通过电压、电流、电磁波、磁场或磁性颗粒、光场或光子、或者这些的任意组合来表示上述说明整体所涉及的数据、命令、指令(command)、信息、信号、比特、码元(symbol)、码片(chip)等。

此外，对于本说明书中说明的用语和/或理解本说明书所需的用语，可以与具有相同或类似的意思的用语进行置换。例如，信号可以是消息。

本说明书中使用的“***”和“网络”等用语可以互换地使用。

此外，对于本说明书中说明的信息、参数等，可以通过绝对值表示，也可以通过相对于规定值的相对值来表示，还可以通过对应的其它信息来表示。例如，无线资源可以由索引来指示。

上述参数所使用的名称在任意一点上都是非限制性的。进而，使用这些参数的数式等有时也与本说明书明示的内容不同。可以通过适当的名称来识别各种各样的信道(例如，PUCCH、PDCCH等)及信息要素(例如，TPC等)，因此分配给这些各种各样的信道及信息要素的各种各样的名称在任意一点上都是非限制性的。

基站能够收纳1个或者多个(例如，3个)小区(也称为扇区)。在基站收纳多个小区的情况下，基站的覆盖区域整体能够划分为多个更小的区域，各多个更小的区域也能够通过基站子***(例如，室内用的小型基站RRH：Remote Radio Head(远程无线头))提供通信服务。“小区”或者“扇区”这样的用语是指在该覆盖范围内进行通信服务的基站、和/或基站子***的覆盖区域的一部分或者整体。进而，“基站”“eNB”“小区”以及“扇区”这样的用语在本说明书中可以互换地使用。对于基站，也用下述用语来称呼：固定站(fixed station)、NodeB、eNodeB(eNB)、接入点(accesspoint)、毫微微小区、小型小区等。

对于用户终端，本领域技术人员有时也用下述用语来称呼：用户站、移动单元(mobile unit)、用户单元、无线单元、远程单元、移动设备、无线设备、无线通信设备、远程设备、移动用户站、接入终端、移动终端、无线终端、远程终端、手持机、用户代理(useragent)、移动客户端、客户端、或一些其它适当的用语。

本说明书中使用的“判断(determining)”、“决定(determining)”这样的用语有时也包含多种多样的动作的情况。“判断”、“决定”例如可以包括将进行了计算(calculating)、算出(computing)、处理(processing)、导出(deriving)、调查(investigating)、搜索(looking up)(例如，在表格、数据库或其它数据结构中的搜索)、确认(ascertaining)的事项视为“判断”、“决定”的事项等。此外，“判断”、“决定”可以包括将进行了接收(receiving)(例如，接收信息)、发送(transmitting)(例如，发送信息)、输入(input)、输出(output)、接入(accessing)(例如，访问存储器中的数据)的事项视为“判断”、“决定”的事项。此外，“判断”、“决定”可以包括将进行了解决(resolving)、选择(selecting)、选定(choosing)、建立(establishing)、比较(comparing)等的事项视为“判断”、“决定”的事项。即，“判断”、“决定”可以包含“判断”、“决定”了任意动作的事项。

“连接(connected)”、“耦合(coupled)”这样的用语或者这些用语的一切变形意在表示2个或者2个以上的要素之间的一切直接或间接的连接或耦合，可以包括在相互“连接”或“耦合”的2个要素之间存在1个或者1个以上的中间要素的情况。要素间的耦合或连接可以是物理上的耦合或连接，也可以是逻辑上的耦合或连接，或者也可以是这些的组合。在本说明书中使用的情况下，对于2个要素，可以考虑通过使用1个或者1个以上的电线、电缆和/或印刷电连接，以及作为一些非限制性且非包括性的示例通过使用具有无线频域、微波区域以及光(包括可视及不可视双方)区域的波长的电磁能量等的电磁能量，来进行相互“连接”或“耦合”。

本说明书中使用的“根据”这样的记载，除非另有说明，否则不是“仅根据”的意思。换而言之，“根据”这样的记载的意思是“仅根据”和“至少根据”双方。

针对使用了本说明书中使用的“第一”、“第二”等称呼的要素的任何参考，也并非全部限定这些要素的量和顺序。这些呼称作为区分2个以上的要素之间简便的方法而在本说明书中被使用。因此，针对第一和第二要素的参照不表示在此仅能采取2个要素或者在任何形态下第一要素必须先于第二要素。

另外，当在本说明书或者权利要求书中使用“包括(include)”、“包含(comprising)”、及其变形的用语时，这些用语与“具有(comprising)”同样地意在表示“包括性的”。另外，在本说明书或者权利要求书中使用的用语“或者(or)”意为不是异或。

在本说明书中，除了根据上下文或者技术能够明确得知仅存在一个装置的情况以外，也包含多个装置。

在本公开的整体中，除非根据上下文能够明确得知表示单个，否则也包含多个的情况。

标号说明

80、81、82…eNB，90…UE，211、221、241、251、261、305…C-Plane控制节点，212、222、242、252、262…U-Plane控制节点，301…公共C-Plane控制节点，SL1～SL6…切片

Claims (2)

1.一种通信控制装置，其进行与用户终端相关的通信控制，所述用户终端经由第一通信路径以及第二通信路径收发用户数据，所述第一通信路径是针对作为在网络基础设施上生成的虚拟化网络的一个或多个切片中的第一控制节点而设置的，所述第二通信路径是针对作为在网络基础设施上生成的虚拟化网络的一个或多个切片中的、与所述第一控制节点不同的第二控制节点而设置的，

所述通信控制装置具有：

变更请求取得部，其取得与所述用户终端的所述第一通信路径以及所述第二通信路径的变更相关的变更请求；

通信处理部，其一边形成变更前的所述第一通信路径以及所述第二通信路径与变更后的通信路径彼此并存的状态，一边进行与所述第一通信路径以及所述第二通信路径的变更相关的处理，

所述通信处理部进行建立所述变更后的通信路径的处理并且完成所述建立，然后执行释放所述变更前的所述第一通信路径以及所述第二通信路径的处理，由此建立变更前的所述第一通信路径以及所述第二通信路径与所述变更后的通信路径并存的状态，

所述通信处理部将通信路径变更为针对与所述第一控制节点以及所述第二控制节点不同的第三控制节点而设置的所述变更后的通信路径，并且所述通信处理部将变更前的所述第一通信路径和所述第二通信路径双方的功能切换到所述变更后的通信路径，所述变更后的通信路径的数量小于所述第一通信路径和所述第二通信路径的总数。

2.一种由通信控制装置执行的通信控制方法，所述通信控制方法进行与用户终端相关的通信控制，所述用户终端经由第一通信路径以及第二通信路径收发用户数据，所述第一通信路径是针对作为在网络基础设施上生成的虚拟化网络的一个或多个切片中的第一控制节点而设置的，所述第二通信路径是针对作为在网络基础设施上生成的虚拟化网络的一个或多个切片中的、与所述第一控制节点不同的第二控制节点而设置的，其中，所述通信控制方法具有如下步骤：

变更请求取得步骤，取得与所述用户终端的所述第一通信路径以及所述第二通信路径的变更相关的变更请求；以及

通信处理步骤，一边形成变更前的所述第一通信路径以及所述第二通信路径与变更后的通信路径彼此并存的状态，一边进行与所述第一通信路径以及所述第二通信路径的变更相关的处理，

在所述通信处理步骤中，进行建立所述变更后的通信路径的处理并且完成所述建立，然后执行释放所述变更前的所述第一通信路径以及所述第二通信路径的处理，由此建立变更前的所述第一通信路径以及所述第二通信路径与所述变更后的通信路径并存的状态，

在所述通信处理步骤中，将通信路径变更为针对与所述第一控制节点以及所述第二控制节点不同的第三控制节点而设置的所述变更后的通信路径，并且将变更前的所述第一通信路径和所述第二通信路径双方的功能切换到所述变更后的通信路径，所述变更后的通信路径的数量小于所述第一通信路径和所述第二通信路径的总数。

Images