CN111752717A

CN111752717A - Smf智能扩展方法和装置、smf会话建立的通信方法

Info

Publication number: CN111752717A
Application number: CN202010649414.2A
Authority: CN
Inventors: 王飚; 周远长
Original assignee: Guangzhou Aipu Road Network Technology Co Ltd
Current assignee: Guangzhou Aipu Road Network Technology Co Ltd
Priority date: 2020-07-08
Filing date: 2020-07-08
Publication date: 2020-10-09
Anticipated expiration: 2040-07-08
Also published as: CN111752717B

Abstract

本发明公开SMF智能扩展方法和装置、SMF会话建立的通信方法，将SMF拆分为中央控制单元、数据中心和若干个服务进程类型。通过中央控制单元动态地控制各服务进程类型中运行的服务进程数量。从而实现SMF的动态扩展，缓解SMF网元压力的同时，减少运维人员部署、配置虚拟机的工作量。

Description

SMF智能扩展方法和装置、SMF会话建立的通信方法

技术领域

本发明涉及通信技术领域，特别涉及SMF智能扩展方法和装置、SMF会话建立的通信方法。

背景技术

随着5G网络技术带来的新一轮网络容量提升，人们对于物联网时代的畅想也得以付诸到实际。越来越多的设备都可以连接到移动网络中来为人们提供不同的服务。然而不同的终端设备(以下简称UE)，在移动性、策略规则等方面需要的支持程度不同。因此对各个网元，对网元内的服务访问的次数、频率也不相同。会话管理功能实体(以下简称SMF)作为5G核心网(以下简称5GC)中会话管理服务，与多个网元如AMF(接入和移动性管理功能)、PCF(分组控制功能)、UDM(统一数据管理功能)、UPF(用户面管理功能)等都有接口。所以SMF处理会话的效率很重要。

目前的核心网可以部署在虚拟平台如VmWare、KVM平台上，当虚拟机的资源不足或者接近满负载的情况下，目前现有的做法是由运维人员通过克隆虚拟机进行扩容。这种做法将会消耗大量时间对系统进行配置和调优，无法做到自动扩展，也无法实时的根据现有的用户模型对服务进行最优化配置。为了提高SMF处理会话的效率，有必要对目前的扩容方式进行优化和改善。

发明内容

本发明的目的是提供SMF智能扩展方法和装置、SMF会话建立的通信方法，解决了现有技术无法自动扩展虚拟网元资源的问题。

本发明的目的是通过以下技术方案实现的：

第一方面，本发明提供一种SMF智能扩展方法，包括被动适应性扩展方法，所述的被动适应性扩展方法包括以下步骤：

步骤S1、将SMF拆分为中央控制单元、数据中心和若干个服务进程类型；所述的每个服务进程类型包括至少一个服务进程，配置每个服务进程类型的初始数据；

步骤S2、中央控制单元收到第一服务进程的服务选择请求时，查询服务进程状态表，在被选择的服务进程类型中选择当前负载数量最少的两个非空闲状态的服务进程fc1和服务进程fc2，且服务进程fc1的负载数量小于fc2的负载数量；

步骤S3、如果服务进程fc1的负载数量大于或等于其会话处理数最大阈值，转至步骤S4；如果服务进程fc2的负载数量小于或等于其会话处理数最小阈值，转至步骤S5；否则，直接返回服务进程fc1的ip地址和端口给第一服务进程；

步骤S4、中央控制单元在被选择的服务进程类型中，恢复一个空闲状态的负载数量最多的服务进程，返回服务进程fc1的ip地址和端口给第一服务进程；如果没有空闲状态的服务进程，则启动一个新的服务进程，再返回服务进程fc1的ip地址和端口给第一服务进程；如果没有新的服务进程可以启动，则返回错误码给第一服务进程；

步骤S5、中央控制单元返回服务进程fc2的ip地址和端口，同时修改服务进程fc1为空闲状态。

进一步的，所述的步骤S2中，如果当前非空闲状态服务进程的只有服务进程fc1，则取服务进程fc1的当前负载数量和其会话处理数最大阈值两者中较大的那个值加一，作为服务进程fc2的当前负载数量。

进一步的，所述的服务进程在被启动后，周期性地向中央控制单元发送状态心跳消息；如果在规定的周期内，中央控制单元没有收到服务进程的心跳消息，则将该服务进程的状态数据从服务进程状态表中删除。

进一步的，所述的被动适应性扩展方法还包括关闭服务进程的步骤：

中央控制单元查询服务进程状态表中处于空闲状态并且负载数量为0的服务进程，向其发送服务关闭请求消息；

服务进程接收到服务关闭请求消息后，判断自身是否存在处理中的会话，如果不存在，则向中央控制单元回复请求成功消息，关闭自身心跳后自行退出；如果存在，则向中央控制单元回复错误码；

中央控制单元收到请求成功消息后，清除服务进程状态表中该服务进程的状态数据。

进一步的，所述的SMF智能扩展方法还包括根据运行状态主动扩展方法；所述的根据运行状态主动扩展方法包括以下步骤：

步骤A、中央控制单元获取session状态表中所有会话中使用的每个类型的服务进程数量，记为Sum1、Sum2、Sum3；计算出最简整数比Sum1：Sum2：Sum3＝x：y：z；

步骤B、中央控制单元获取服务进程状态表中每个类型的服务进程的运行数量i，j，k；计算出S1＝i/x、S2＝j/y、S3＝z/k；S1、S2和S3的结果取整数；

步骤C、如果S1＝S2＝S3，则不做处理；否则取S1、S2和S3中最大的一个值记为Smax，为小于Smax的数值所对应服务进程类型启动一个新的服务进程；

步骤D、将x、y、z的数值写入配置文件，作为下次SMF重启时各服务进程的初始启动数量；间隔设定时间后，重复步骤A至步骤D。

第二方面，本发明提供一种SMF会话建立的通信方法，包括以下步骤：

步骤一、当中央控制单元接收到其他网元的服务请求时，选择与服务请求相对应的第一服务进程，将服务请求指令发送给第一服务进程；

步骤二、第一服务进程从session数据表中获得该服务请求对应的session数据并处理该服务请求，判断该服务请求是否需要其他类型的第二服务进程继续处理，如需要，第一服务进程向中央控制单元发送服务选择请求，转至步骤四；否则转至步骤三；

步骤三、第一服务进程进行数据处理，并发送服务请求回复消息给中央控制单元，中央控制单元将处理结果回复给提出服务请求的网元，该服务请求处理完成；

步骤四、中央控制单元采用被动适应性扩展方法选择第二服务进程，并返回第二服务进程的ip地址和端口给第一服务进程；

步骤五、第一服务进程向数据中心存储session数据，并向第二服务进程发送服务请求指令；

步骤六、第二服务进程从数据中心获取session数据，处理该服务请求后进行数据处理；如果该服务请求需要其他类型的第三服务进程继续处理，第二服务进程向中央控制单元发送服务选择请求，返回步骤四；否则中央控制单元将处理结果回复给提出服务需求的网元，该服务请求处理完成。

进一步的，所述的步骤一中中央控制单元选择第一服务进程的步骤包括：

步骤S101、当中央控制单元接收到服务请求时，判断该服务请求是否是新建会话，如果是则转至步骤S102；如果不是，则转至步骤S103；

步骤S102、中央控制单元新建一条会话编号，将与该新建会话相关的session数据记录入session数据表中，再选择一个Sm类型的服务进程，向被选择的Sm服务进程发起服务请求指令；

步骤S103、中央控制单元从session数据表中获取该服务请求的session数据，再将session数据更新后记录入session数据表，然后与该服务请求对应的一个服务进程向其发起服务请求指令。

第三方面，本发明提供一种SMF智能扩展装置，包括中央控制单元、数据中心和若干个服务进程类型；每个服务进程类型包括至少一个服务进程；所述的中央控制单元动态地控制各服务进程类型中运行的服务进程数量；中央控制单元、服务进程和数据中心两两之间通过HTTP2协议通信。

进一步的，所述的中央控制单元中存有服务进程状态表和session状态表；所述的数据中心存有session数据表。

本发明的SMF智能扩展的方法和装置，通过将SMF拆分为一个中央控制单元、若干个服务进程类型和数据中心。通过中央控制单元动态地控制各服务进程类型中运行的服务进程数量，实现动态扩展。并能自动完成数据迁移以及配置，实现SMF的智能动态扩展，缓解SMF网元压力的同时，减少运维人员部署、配置虚拟机的工作量。

附图说明

图1为本发明的SMF智能扩展装置的内部结构示意图；

图2为服务进程向Controller发送状态心跳消息的通信流程图；

图3为Controller向服务进程发送服务请求指令的通信流程图；

图4为向数据中心写入数据的通信流程图；

图5为向数据中心读取数据的通信流程图；

图6为服务进程向Controller发送服务请求回复指令的通信流程图；

图7为服务进程向Controller发送发现请求的通信流程图；

图8为Controller关闭服务进程的通信流程图；

图9为本发明的被动适应性扩展方法的流程示意图；

图10为本发明的服务进程之间的通信流程图；

图11为本发明的根据运行状态主动扩展方法的流程示意图；

图12为本发明的SMF会话建立的通信方法的流程示意图。

具体实施例

下面结合附图对本公开实施例进行详细描述。

以下通过特定的具体实例说明本公开的实施方式，本领域技术人员可由本说明书所揭露的内容轻易地了解本公开的其他优点与功效。显然，所描述的实施例仅仅是本公开一部分实施例，而不是全部的实施例。本公开还可以通过另外不同的具体实施方式加以实施或应用，本说明书中的各项细节也可以基于不同观点与应用，在没有背离本公开的精神下进行各种修饰或改变。需说明的是，在不冲突的情况下，以下实施例及实施例中的特征可以相互组合。基于本公开中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本公开保护的范围。

本发明的SMF智能扩展方法，包括被动适应性扩展方法。

进一步的，在本申请提供的一种优选的实施例中，被动适应性扩展方法包括以下步骤：

步骤S1、将SMF拆分为中央控制单元Controller、数据中心datacenter和若干个服务进程类型fcType。每个服务进程类型包括至少一个服务进程。配置每个服务进程类型的初始数据。

服务进程类型包括但不限于：

会话管理单元(以下简称Sm)，用于维护和管理用户的会话信息，负责处理AMF发来的会话请求，以及向UDM请求用户鉴权信息。

服务提供单元(以下简称Sc)，用于维护和管理用户的策略以及计费信息，负责处理Sm发来的业务请求，与CHF(计费功能)、PCF(策略控制功能)交互，以及向UPF(用户平面功能)下发消息。

第三方服务单元(以下简称App)，用于维护SMF和第三方服务之间的数据连接。

本发明的中央控制单元，用于动态地控制各服务进程类型中运行的服务进程数量，实现动态扩展，提高选择服务进程的命中效率。

配置每个服务进程类型的初始数据包括但不限于：配置每个服务进程类型包含的服务进程数量和单个服务进程的会话(以下简称session)处理数最大阈值和会话处理数最小阈值。当SMF启动时，由配置文件配置每个服务进程类型所包含的服务进程数量，比如配置会话管理单元的数量C_Sm、服务提供单元的数量C_Sc、第三方服务单元的数量C_App。具体的数量根据实际需要进行设定。由用户通过配置文件配置单个服务进程的会话处理数最大阈值和会话处理数最小阈值。比如配置单个Sm服务进程的会话处理数最大阈值Nsm_max的值、会话处理数最小阈值Nsm_min的值。具体的数值根据实际需要进行设定。在SMF启动时自动完成数据配置，减少运维人员部署、配置虚拟机的工作量。

每个服务进程由Controller配置唯一服务进程编号。比如Sm类型的服务进程分别记为Sm1、Sm2、Sm3......Smn。Sc类型的服务进程分别记为Sc1、Sc2、Sc3......Scn。App类型的服务进程分别记为App1、App2、App3......Appn。如图1所示。

服务进程之间、服务进程与Controller之间、Controller与外部其他网元之间都采用标准的HTTP2协议进行通信。HTTP2协议相比HTTP/1而言，提供了更加高效的传输方式，其可加密的特性也保证了数据传输的与安全。

优选的，每个服务进程启动后，需要周期性地向Controller发送状态心跳消息。Controller通过状态心跳消息判断该服务进程是否存在，以及判断该服务进程的运行情况。服务进程向Controller发送状态心跳消息的通信流程如图2所示。

状态心跳消息的路由(path)为：POST/heartbeat/{fcType}/{fcID}/，其中：POST为HTTP2消息的方法。heartbeat表示该消息为状态心跳消息。fcType为发送该状态心跳消息的服务进程类型，如Sm、Sc、App等。fcID为发送该状态心跳消息的服务进程编号，如Sm1、Sc2、App4等。服务进程的编号的取值范围为0至用户配置的该服务类型最大服务进程数量。状态心跳消息的正文部分为服务进程状态fcStatus，用于判断该服务进程的运行情况。fcStatus采用json格式传输。fcStatus的属性如表1所示：

表1

表1中的条件包括M、O和C，其中M代表必选项，O代表可选项，C代表有条件可选项。服务进程向Controller发送状态心跳消息后，Controller在服务进程状态表中查找该服务进程的状态数据。如果该服务进程的状态数据不存在，则创建一条该服务进程的状态数据；如果存在，就更新服务进程的状态数据，用于后续的服务选择。Controller完成状态数据创建或更新后，返回204 No Content消息给服务进程，表示已经收到状态心跳消息，并完成了状态数据的创建或更新。间隔一段设定的下次心跳时间后，该服务进程又会发送状态心跳消息，如此循环。每当完成一次心跳检测后(Controller每返回204 No Content消息给服务进程，视为完成一次心跳检测)，Controller中有线程定时每秒将设定的下次心跳时间减一，当下次心跳时间为0时，还未收到该服务进程发送的状态心跳消息，则认为该服务进程异常，将该服务进程的状态数据从服务进程状态表中删除，该服务进程不再参与服务选择。

上述服务进程状态表保存在Controller中，按照不同的服务进程类型分为不同的服务进程状态表，每个类型的服务进程状态表中记录该类型的所有服务进程的状态数据。服务进程的状态数据结构如下所示。

fcID：{“sessionCount”：xxx，“nextHeartBeat”：xxx，“ipAndPort”：“a.b.c.d:e”，“idle”：True/False}

fcID表示服务进程的编号。sessionCount表示该服务进程正在处理的会话数量(也称负载数量)。nextHeartBeat表示下次心跳时间。ipAndPort表示该服务进程的IP地址和端口。idle表示空闲状态，当idle值为True时，表示该服务进程处于空闲状态(也称为idle态)；当idle值为False时，表示该服务进程处于非空闲状态(也称为非idle态)。被启动的服务进程是非idle态的，暂且称之为正常状态。服务进程没有会话需要处理时，会被Controller关闭，暂且称之为关闭状态。idle态是服务进程从正常状态到关闭状态的过渡状态，由Controller根据服务进程的负载数量进行设置。进入idle态的服务进程表示它即将要被关闭，不接受新的session。如果下次服务选择时需要扩展新的服务进程，就将被扩展的服务进程从idle态设置为非idle态；否则就一直处于idle态，直到所有的session都处理完后就会被关闭。

服务进程状态表为Controller记录每一个服务进程的负载数量、发送心跳消息的时间间隔、通信ip地址和端口以及是否处于idle状态，为Controller管理每个服务进程状态、进行服务选择提供依据。

Controller中还保存有session状态表。按照不同的服务进程类型分为不同的session状态表，每个类型的session状态表中记录不同的服务进程类型被选择的次数，反应该session对各种不同类型的服务进程的占用情况。session状态表的结构如下所示。

sessionID：{“SmCount”：xxx，“ScCount”：xxx，“AppCount”：xxx}

sessionID表示该会话的编号，每个会话有一个唯一的编号，在该会话被触发时由Controller为其配置。SmCount、ScCount、AppCount为服务进程类型的名称。xxx为该服务进程类型下的服务进程被使用的次数，服务进程每被选择一次，被使用的次数加一。实际使用时，xxx是具体的数字。

session状态表为Controller记录每一个会话对每一类型的服务进程的使用数量，为生成该会话的服务使用模型提供依据。

datacenter用于存储session数据表。session数据表会在各服务进程中传递，因此保存在SMF的数据中心当中，记录该session的处理流程，以及其全局数据。session数据表中的session数据的结构如下所示。

sessionID：{“nowState”：“xxx”，“nextState”：“xxx”，“data”：{…}}

sessionID表示该会话的编号，每个会话有一个唯一的编号，在该会话被触发时由Controller为其配置。nowState表示该会话目前的处理流程。nextState表示该会话的下一个处理流程。xxx为当前处理或下一个处理该会话的服务进程编号，可以是Sm1、Sc2等等。data是以Key：Value格式存储的会话相关数据。

session数据表在服务进程之间充当上下文作用，记录每一个session当前完成的处理流程，以及准备进行的下一个处理流程，为跨进程处理session提供基础，也将数据与服务进程解耦，各服务进程可以根据处理该会话任务的需求任意加减数量，实现动态扩容。

步骤S2、Controller收到第一服务进程的服务选择请求时，根据服务选择请求中携带的被选择的服务进程类型，查询被选择的服务进程类型对应的服务进程状态表，选择当前负载数量最少的两个非空闲状态(也称非idle态)的服务进程fc1和服务进程fc2，且服务进程fc1的负载数量小于fc2的负载数量。

服务进程向Controller发送服务选择请求的通信流程如图7所示。服务选择请求的路由为：POST/serviceDiscover。其中POST为HTTP2消息的方法，serviceDiscover表示该消息为服务选择请求。服务选择请求的内容为discoverReq，其属性如表2所示：

表2

优选的，如果服务进程fc2为空，即当前非空闲状态的服务进程只有一个——服务进程fc1，则取服务进程fc1的当前负载数量和服务进程fc1的会话处理数最大阈值两者中较大的那个值加一作为服务进程fc2的当前负载数量。公式为：

fc2.sessionCount＝fc1.sessionCount>Nfc_max？fc1.sessionCount+1：Nfc_max+1

其中：fc2.sessionCount表示服务进程fc2的当前负载数量；

fc1.sessionCount表示服务进程fc1的当前负载数量；

Nfc_max表示服务进程fc1的会话处理数最大阈值。

步骤S3、如果服务进程fc1的负载数量大于或等于其会话处理数最大阈值，转至步骤S4；如果服务进程fc2的负载数量小于或等于其会话处理数最小阈值，转至步骤S5；否则，直接返回服务进程fc1的ip地址和端口给第一服务进程。

步骤S4、Controller在被选择的服务进程类型中，尝试恢复一个空闲状态的负载数量最多的服务进程，再返回服务进程fc1的ip地址和端口给第一服务进程。如果没有空闲状态的服务进程，则启动一个新的服务进程，再返回服务进程fc1的ip地址和端口给第一服务进程。如果没有新的服务进程可以启动时，则返回错误码给第一服务进程。错误码如表3所示。

表3

恢复或者启动新的服务进程是留给下次服务选择时用的，因为恢复或者启动完成一个新的服务进程所需的时间无法控制。一个空闲状态的服务进程被恢复后，它的状态就自动变为非空闲状态。

步骤S5、Controller返回服务进程fc2的ip地址和端口，同时Controller修改服务进程fc1为空闲状态。

每当成功返回一个服务进程ip地址和端口时，session状态表中该sessionID下对应的服务进程类型的被使用次数加一。

进一步的，在本申请提供的一种优选的实施例中，被动适应性扩展方法还包括关闭服务进程的步骤，具体为：

Controller查询服务进程状态表中处于空闲状态并且负载数量为0的服务进程，向其发送服务关闭请求消息。服务进程接收到服务关闭请求消息后，判断自身是否存在处理中的会话，如果不存在，则向Controller回复请求成功消息(200OK消息，200OK消息是HTTP协议常用的请求成功消息，在此不详细描述)，关闭自身心跳后自行退出；如果存在，则向Controller回复错误码。Controller收到请求成功消息后，清除服务进程状态表中该服务进程的状态数据。

Controller关闭服务进程的通信流程如图8所示。服务关闭请求消息的路由为：POST/svcClose。其中svcClose表示该消息为服务关闭请求消息。

上述被动适应性扩展的方法，SMF根据服务进程的负载数量，扩展或服务进程的数量。当负载数量超过设定的会话数量最大阈值时扩展服务进程的数量，当负载数量小时，关闭服务进程。实现了SMF的智能动态扩展，减少人工维护，缓解SMF网元压力。

进一步的，在本申请提供的一种优选的实施例中，SMF智能扩展方法还包括根据运行状态主动扩展方法。

SMF定时启动一次主动拓展。根据运行状态主动扩展方法包括以下步骤：

步骤A、Controller获取session状态表中所有会话中使用的每个类型的服务进程数量，记为Sum1、Sum2、Sum3，计算出其最简整数比Sum1：Sum2：Sum3＝x：y：z。

步骤B、Controller获取服务进程状态表中每个类型的服务进程的运行数量i，j，k。计算S1＝i/x、S2＝j/y、S3＝z/k。S1、S2和S3的结果取整数。

步骤C、如果S1＝S2＝S3，则认为目前各类型的服务进程比例与用户理想服务使用比例相符，不做处理。否则取S1、S2和S3中最大的一个值记为Smax，为小于Smax的数值所对应服务进程类型启动一个新的服务进程。

步骤D、将x、y、z的数值写入配置文件，作为下次SMF重启时各服务进程的初始启动数量。间隔设定时间后，重复步骤A至步骤D。

进一步的，在本申请提供的一种优选的实施例中，SMF智能扩展方法还包括根据现有建议表模型主动扩展调整的方法，包括以下步骤：

SMF在运行时对各模型量进行统计，根据统计数据，SMF根据当前运行的业务量(对业务进程的请求数量)，主动的去调整服务进程数。同时，统计运行稳定时相应进程数与业务量的比例，为之后的调整作为依据。

本发明的SMF会话建立的通信方法，包括以下步骤：

步骤一、当Controller接收到其他网元的服务请求时，选择与服务请求相对应的一个服务进程(以下简称第一服务进程)，将服务请求指令发送给第一服务进程。

举例来说，如果服务请求的内容为新建会话，则Controller会选择一个Sm服务进程。如果服务请求的内容为计费信息，则Controller会选择一个Sc服务进程。选择哪个类型的服务进程，是根据服务请求的内容来决定的。

进一步的，在本申请提供的一种优选的实施例中，Controller选择第一服务进程的步骤包括：

步骤S101、当Controller接收到服务请求时，判断该服务请求是否是新建会话，如果是则转至步骤S102；如果不是，则转至步骤S103。

步骤S102、Controller新建一条会话编号(sessionID)记录，该sessionID唯一。将与该会话相关的session数据记录入数据中心的session数据表中，再选择一个Sm服务进程，向被选择的Sm服务进程发起服务请求指令。

步骤S103、Controller根据该服务请求的sessionID从session数据表中获取该服务请求的session数据，再将session数据更新后录入session数据表，然后选择与该服务请求对应的服务进程向其发起服务请求指令。更新操作为：有相同key的做替换操作，之前没有的就新增进去。

非新建会话的服务请求自身会携带之前已配置好的sessionID。

Controller与服务进程之间的通信流程如图3所示。服务请求指令是通过服务请求消息传输的，服务请求消息的路由为：POST/SessionReq/{sessionID}。POST为HTTP2消息的方法，SessionReq表示该消息为服务请求消息。服务请求消息中携带sessionID，为该服务请求消息对应的会话编号。SessionReq的内容包括但不限于CreateSmContext(新建会话)、UpdateSmContext(更新会话)。

将session数据写入session数据表的流程如图4所示。Controller或服务进程将处理好的session数据发送给DataCenter，DataCenter接收到session数据后，会根据session数据携带的sessionID去新建或是更新数据记录，写入session数据表中，供需要的其它服务进程获取。返回处理成功消息(200OK消息)或错误码给Controller或服务进程。

从session数据表中获取session数据的通信流程如图5所示。具体包括：

Controller或服务进程发送数据获取消息给消息中心。消息中心接收到数据获取消息后，会根据数据获取消息中携带的sessionID，在session数据表中查找该sessionID对应的session数据。如果可以查找到，则返回处理成功消息(200OK消息)并携带对应的session数据，否则返回错误码。

错误码的格式如上述的表2所示。

步骤二、第一服务进程接收到服务请求指令后，根据服务请求指令中携带的sessionID，从数据中心的session数据表中获得对应的session数据并处理该服务请求。如果该服务请求需要其他类型的第二服务进程继续处理，第一服务进程向Controller发送服务选择请求，转至步骤四；否则转至步骤三。

从session数据表中获得session数据的过程在上文已经描述，在此不再赘述。

判断该服务请求是否需要第二服务进程继续处理时，依据session数据中的nextState数据，如果nextState为空，则无需第二服务进程继续处理。否则判断为需要第二服务进程继续处理。

第一服务进程向Controller发送服务选择请求的通信流程为：

第一服务进程处理完服务请求后，发送服务请求回复消息给Controller。

Controller将服务请求回复消息中的处理数据(http2data)回复给提出服务需求的网元，并回复处理成功消息(200OK消息)给第一服务进程。

第一服务进程更新session数据并将session数据写入数据中心的session数据表中，向Controller发送服务选择请求。

服务进程向Controller发送服务请求回复消息的通信流程如图6所示。服务请求回复消息的路由为：POST/http2Resp/{sessionID}。其中POST为HTTP2消息的方法，http2Resp表示该消息为服务请求回复消息。服务请求回复消息中携带sessionID，为该服务请求回复消息对应的会话编号。服务请求回复消息的内容为http2data。Controller收到服务请求回复消息后，根据服务请求回复消息中携带的sessionID找到需要对应的服务请求(同一个session同一时间只处理一条服务请求)，将服务进程发送的http2data回复给提出该服务请求的网元。

步骤三、第一服务进程进行数据处理，并发送服务请求回复消息给Controller，Controller将处理结果回复给提出服务请求的网元，该服务请求处理完成。

第一服务进程进行数据处理的过程为：第一服务进程更新session数据，将session数据写入数据中心的session数据表中。

步骤四、Controller收到服务选择请求时，采用上述被动适应性扩展方法选择第二服务进程，并返回第二服务进程的ip地址和端口给第一服务进程。

步骤五、第一服务进程向数据中心存储session数据，并向第二服务进程发送服务请求指令。

两个服务进程之间的通信流程如图10所示。第二服务进程收到服务请求指令后，会回复200OK消息给第一服务进程，表示收到服务请求指令。

步骤六、第二服务进程从数据中心获取session数据，处理该服务请求后，更新session数据，再写入数据中心。如果该服务请求需要其他类型的第三服务进程继续处理，第二服务进程向Controller发送服务选择请求，返回步骤四；否则Controller将处理结果回复给提出服务需求的网元，该服务请求处理完成。

图12为SMF会话建立的通信方法的通信流程图。该流程图是以PDU会话建立的过程为例的。从图12可以看出，服务进程是和session完全解耦的，服务进程不存有session数据，也和session没有对应关系。服务进程的选择由Controller完成。参与正常服务的服务进程的数量可以根据负载数量由Controller进行增减。

本发明的SMF智能扩展装置，包括中央控制单元、数据中心和若干个服务进程类型。每个服务进程类型包括至少一个服务进程。中央控制单元、服务进程和数据中心两两之间通过HTTP2协议通信。

中央控制单元用于动态地控制各服务进程类型中运行的服务进程数量。中央控制单元中存有服务进程状态表和session状态表。数据中心存有session数据表。

本发明的SMF智能扩展装置用于执行上述SMF智能扩展方法、SMF会话建立的通信方法。

以上仅为说明本发明的实施方式，并不用于限制本发明，对于本领域的技术人员来说，凡在本发明的精神和原则之内，不经过创造性劳动所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims

1.SMF智能扩展方法，其特征在于，包括被动适应性扩展方法，所述的被动适应性扩展方法包括以下步骤：

2.根据权利要求1所述的SMF智能扩展方法，其特征在于，所述的步骤S2中，如果当前非空闲状态服务进程的只有服务进程fc1，则取服务进程fc1的当前负载数量和其会话处理数最大阈值两者中较大的那个值加一，作为服务进程fc2的当前负载数量。

3.根据权利要求1所述的SMF智能扩展方法，其特征在于，所述的服务进程在被启动后，周期性地向中央控制单元发送状态心跳消息；如果在规定的周期内，中央控制单元没有收到服务进程的心跳消息，则将该服务进程的状态数据从服务进程状态表中删除。

4.根据权利要求1所述的SMF智能扩展方法，其特征在于，所述的被动适应性扩展方法还包括关闭服务进程的步骤：

5.根据权利要求1所述的SMF智能扩展方法，其特征在于，所述的SMF智能扩展方法还包括根据运行状态主动扩展方法；所述的根据运行状态主动扩展方法包括以下步骤：

6.SMF会话建立的通信方法，其特征在于，包括以下步骤：

7.根据权利要求6所述的SMF会话建立的通信方法，其特征在于，所述的步骤一中中央控制单元选择第一服务进程的步骤包括：

8.SMF智能扩展装置，其特征在于，包括中央控制单元、数据中心和若干个服务进程类型；每个服务进程类型包括至少一个服务进程；所述的中央控制单元动态地控制各服务进程类型中运行的服务进程数量；中央控制单元、服务进程和数据中心两两之间通过HTTP2协议通信。

9.根据权利要求8所述的SMF智能扩展装置，其特征在于，所述的中央控制单元中存有服务进程状态表和session状态表；所述的数据中心存有session数据表。