CN110719303B - 一种容器化nrf的方法及系统 - Google Patents

Abstract

本发明涉及通信领域，特别涉及一种容器化NRF的方法及系统，用以提升NRF系统的运行效率。该方法为：在NRF系统原有架构的基础上，在应用容器引擎层之上的应用层中，设置有多个容器，各个容器之间采用标准的服务化接口进行通信。这样，相较于已有的虚拟机NRF方案，由于不再设置GUESTOS，因此有效实现了NRF系统的轻量化，也减少了NRF系统运行过程中所需要的资源消耗，从而显著提升了NRF系统的运行效率，容器化后的NRF系统具有很强的扩展性，在动态扩缩容过程中只需要对相应容器进行增减即可完成相关操作，有力的支持了运营商的灵活部署。

Description

一种容器化NRF的方法及系统

技术领域

本发明涉及通信领域，特别涉及一种容器化NRF的方法及系统。

背景技术

网络注册功能实体(Network Register Function，NRF)是5G核心网引入服务化架构后的重要网络功能节点，是5G核心网中负责服务注册、服务管理的软件实体，负责在控制面实现网络功能(Network Function，NF)的服务注册、去注册、发现、授权等管理功能。5G核心网是承载于电信云平台之上的，业界通行采用基于内核的虚拟机(Kernel-basedVirtual Machine，KVM)做为其虚拟化技术。KVM属于第一代云计算技术，采用了硬件、宿主机操作系统(Host Operating System，Host OS)、虚拟化层、客户机操作系统(GuestOperating System，Guest OS)、虚拟网络功能(Virtual Network Functions，VNF)的五层系统架构。因此，NRF也是部署于KVM之上。

在5G核心网控制面，全部NF都需要与NRF进行连接，并在上线之后向NRF进行注册。各NF之间消息交互之前都需要到NRF处进行服务器发现，以查看对应的NF的IP地址并建设超文本传输协议(HyperText Transfer Protocol，HTTP)连接，然后进行信令面的通信。

参阅图1所示，已有技术下，NRF采用KVM虚拟机的方案实现，具体包括：

硬件层，用于提供底层硬件设备支持。

HOST OS层，位于硬件层之上，用于负责对底层硬件设备的管理，对上提供操作接口。

虚拟化层中间件(Hypervisor)，位于HOST OS层之上，用于负责将多个操作系统和应用共享一套基础物理硬件。

Hypervisor层之上是KVM的虚拟机部分，包括虚拟机操作系统(GUEST OS)和NRF应用(APP)。

参阅图2所示，通常情况下，NRF采用的Guest OS为Centos 6.5，而NRF APP的软件在逻辑上分为共享基础设施(Shared Base Infrastructure，SBI)模块、数据库(DataBase，DB)模块、注册(Register，REG)模块、补丁(PATCH)模块和同步(Synchronize，SYN)模块；而操作系统应用编程接口(OS Application Programming Interface，OS API)是Guest OS提供给NRF APP的软件编程接口；其中，

SBI模块，用于负责HTTP、TCP、IP等通信协议的处理。

DB模块，是NRF APP的本地数据库管理系统，用于负责对NRF自身及各NF的相关信息的存储。

PATCH模块，用于负责对外提供订阅服务的发布以及外部访问NRF的公共接口。

REG模块，用于负责对各NF的注册、去注册、发现、授权等服务化过程及生命周期的管理。

SYN模块，用于负责与其它NRF或融合域名系统(Domain Name System，DNS的信息同步。

如图2所示，在基于KVM虚拟机的NRF中，NRF的运行环境中有一个独立于Host OS的Guest OS。即在一台服务器节点上除了在硬件层之上的一个“实”操作系统，在NRF运行的虚拟机里还有一个“虚”的操作系统。

因此，一个NRF的系统镜像所占用的存储空间都在15GB左右，从而造成NRF在系统备份、动态迁移等方面处理时间均无法满足未来5G智能敏捷网络的需要，有必要进行相关软件重构和新的虚拟化技术的适配来提升NRF的系统效率。

发明内容

本发明实施例提供一种容器化NRF的方法及系统，用以提升NRF系统的运行效率。

本发明实施例提供的具体技术方案如下：

一种容器化网络注册功能实体NRF的系统，包括：

硬件层，用于提供底层硬件设备支持；

宿主机操作系统HOST OS层，位于所述硬件层之上，用于对底层硬件设备进行管理，以及对上层提供操作接口；

应用容器引擎层，位于所述HOST OS层之上，用于实现虚拟化层中间件功能；

应用层，位于所述应用容器引擎层之上，设置有多个容器，各个容器之间采用标准的服务化接口进行通信，其中，所述多个容器至少包括：

SBI容器，用于针对各个容器提供外部的通信协议的处理；

业务容器，用于执行各类的业务处理；

DB容器，用于针对各个容器负责本地数据的存储和读写。

可选的，所述标准的服务化接口，采用的协议栈包括有：

应用层、超文本传输协议层、网络协议层、层2和层1。

可选的，各个容器之间采用的统一资源标识URI规范包括：

五元组、服务名、服务版本号和资源名，其中，五元组至少包括源IP、目的IP、源端口、目的端口和协议类型。

可选的，所述资源名至少包括以下信息：

接收消息的容器ID、连接容器的网络的标识、SBI容器数据、DB容器数据、数据库健值和数据库维护信息。

可选的，所述各个容器之间采用标准的服务化接口进行通信时，采用的服务化消息中至少包含消息头标识和内容类型；其中，

所述消息头标识用于指示所述服务化消息是超文本传输协议HTTP消息部分或数据部分；

所述内容类型用于指示所述服务化消息是容器之间交互的消息或容器内部交互的消息。

可选的，所述各个容器之间采用标准的服务化接口进行通信时，基于服务化消息发送的请求消息中至少携带以下数据项：

用户标识、目标地址、目标端口、统一资源位置标识、方法名称、源地址、消息长度、期望获得的反馈和内容类型；

各个容器之间采用服务化消息进行交互时，基于服务化消息发送的响应消息时，至少携带以下数据项：

用户标识、流标识、连接标识、消息长度、内容类型，响应代码和发送响应消息的网元位置信息。

可选的，所述SBI容器进一步用于：

接收的网络功能实体NF发送的外部的请求消息，对所述外部的请求消息进行解析，获得相关的对象表示法JSON结构体内容，并通过服务化接口将获得的JSON结构体内容发送给所述业务容器进行处理，再通过服务化接口通知所述DB容器进行本地数据更新；

所述业务容器进一步用于：

对接收的JSON结构体内容进行处理，并构建相应的响应消息，以及将所述响应消息采用新的JSON结构体内容的形式，通过服务化接口发送给所述SBI容器，触发所述SBI容器对所述响应消息进行解析，并在进行HTTP封装后发送至所述NF。

可选的，SBI容器进一步用于：

与外部的NF进行交互时，接收NF基于标准的服务化消息的信令消息体结构生成相应的请求消息，所述请求消息中携带相应的网元位置信息；或/和，

与外部的NF进行交互时，基于标准的服务化消息的信令消息体结构生成相应的响应消息，所述响应消息中携带有相应的响应码。

一种容器化网络注册功能实体NRF的方法，包括：

设置用于提供底层的硬件设备支持的硬件层；

在所述硬件层之上，设置用于负责对底层的硬件设备的管理的宿主机操作系统HOST OS层；

在所述HOST OS层之上，设置用于实现虚拟化层中间件功能的应用容器引擎层；

在位于所述应用容器引擎层之上，设置包含有多个容器的应用层，各个容器之间采用标准的服务化接口进行通信，其中，所述多个容器至少包括：

SBI容器，用于针对各个容器提供外部的通信协议的处理；

业务容器，用于处理接收到的各类业务请求；

DB容器，用于针对各个容器负责本地数据的存储和读写。

可选的，所述标准的服务化接口，采用的协议栈包括有：

应用层、超文本传输协议层、网络协议层、层2和层1。

可选的，各个容器之间采用的统一资源标识URI规范包括：

五元组、服务名、服务版本号和资源名，其中，五元组至少包括源IP、目的IP、源端口、目的端口和协议类型。

可选的，所述资源名至少包括以下信息：

接收消息的容器ID、连接容器的网络的标识、SBI容器数据、DB容器数据、数据库健值和数据库维护信息。

可选的，所述各个容器之间采用标准的服务化接口进行通信时，采用的服务化消息中至少包含消息头标识和内容类型；其中，

所述消息头类型用于指示所述服务化消息是超文本传输协议HTTP消息部分或数据部分；

所述内容类型用于指示所述服务化消息是容器之间交互的消息或容器内部交互的消息。

可选的，所述各个容器之间采用标准的服务化接口进行通信时，基于服务化消息发送的请求消息中至少携带以下数据项：

用户标识、目标地址、目标端口、统一资源位置标识、方法名称、源地址、消息长度、期望获得的反馈和内容类型；

各个容器之间采用服务化消息进行交互时，在发送响应消息时，至少携带以下数据项：

用户标识、流标识、连接标识、消息长度、内容类型，响应代码和发送响应消息的网元位置信息。

可选的，进一步包括：

通过所述SBI容器执行以下操作：

接收网络功能实体NF发送的外部的请求消息，对所述外部的请求消息进行解析，获得相关的对象表示法JSON结构体内容，并通过服务化接口将获得的JSON结构体内容发送给所述业务容器进行处理，再通过服务化接口通知所述DB容器进行本地数据更新；

通过所述业务容器执行以下操作：

对接收的JSON结构体内容进行处理，并构建相应的响应消息，以及将所述响应消息采用新的JSON结构体内容的形式，通过服务化接口发送给所述SBI容器，触发所述SBI容器对所述响应消息进行解析，并在进行HTTP封装后发送至所述NF。

可选的，进一步用于包括：

通过所述SBI容器与外部的NF进行交互时，接收NF基于标准的服务化消息的信令消息体结构生成相应的请求消息，所述请求消息中携带相应的网元位置信息；或/和，

通过所述SBI容器与外部的NF进行交互时，基于标准的服务化消息的信令消息体结构生成相应的响应消息，所述响应消息中携带有相应的响应码。

综上所述，本发明实施例中，在NRF系统原有架构的基础上，在应用容器引擎层之上的应用层中，设置有多个容器，各个容器之间采用标准的服务化接口进行通信，其中，所述多个容器至少包括：SBI容器，用于针对各个容器提供外部的通信协议的处理；业务容器，用于执行各类的业务处理；DB容器，用于针对各个容器负责本地数据的存储和读写。这样，相较于已有的虚拟机NRF方案，由于不再设置GUEST OS，因此有效实现了NRF系统的轻量化，也减少了NRF系统运行过程中所需要的资源消耗，从而显著提升了NRF系统的运行效率，容器化后的NRF系统具有很强的扩展性，在动态扩缩容过程中只需要对相应容器进行增减即可完成相关操作，有力的支持了运营商的灵活部署。

附图说明

图1为已有技术下KVM虚拟机NRF系统结构图；

图2为已有技术下NRF APP软件逻辑结构图；

图3为本发明实施例中容器化NRF第一系统架构图；

图4为本发明实施例中容器化NRF第二系统第二架构图；

图5为本发明实施例中标准的服务肥接口协议栈示意图；

图6为本发明实施例中URI结构示意图。

具体实施方式

为了提升NRF系统的运行效率，本发明实施例中，将NRF中的各个功能模块进行合理的服务化拆分，然后通过容器技术实现NRF的网络功能。

下面结合附图对本发明优选的实施方式进行详细说明。

本发明实施例中，可选的，选用业界通行的Docker技术作为容器技术。Docker是一个开源的应用容器引擎，让开发者可以打包应用以及依赖包到一个可移植的容器中，然后发布到任何流行的Linux主机(实体机或虚拟机)上。

采用Docker后的NRF方案系统的架构如图3所示，与已有的如图1所示的虚拟机NRF方案相对应，本发明实施例中，容器化后的NRF包括：

硬件层，用于提供底层硬件设备支持。

HOST OS层，位于硬件层之上，用于对底层硬件设备进行管理，以及对上层提供操作接口。

应用容器引擎(Docker Engine)层，位于HOST OS层之上，替代了Hypervisor作为虚拟化层中间件。

由于容器化的NRF方案采用的是共享操作系统内核(Kernel)的方案，因此，容器内部不需要额外的一个Guest OS来提供NRF APP所需的OS API支持。

应用层(即NRF APP)，位于Docker Engine之上。

在容器化的NRF方案中，需要参照服务化的架构对NRF APP中的原有的功能模块进行适当的拆分，将原有的内部消息接口或函数调用接口转换为标准的服务化接口。

由于采用了标准的服务化接口，在执行系统备份、动态迁移等操作时，容器化的NRF可以迅速实现与新环境的融合、对接，从而法满足未来5G智能敏捷网络的需要。

具体的，按照虚拟机NRF方案中的原有的功能模块的划分，需要将SBI模块、DB模块、REG模块、PATCH模块和SYN模块按照服务化的架构要求重新按容器的粒度进行重构。

参阅图4所示，较佳的，应用层中包括：

DB容器，用于在整体NRF容器集群中负责本地数据的存储和读写。

DB容器是将DB模块单独转换后形成的一个服务化的容器。

SBI容器，用于给NRF容器集群提供外部的通信协议(如，HTTP、TCP、IP等)的处理。

SBI容器是将SBI模块单独转换后形成的一个服务化的容器。

业务容器，用于处理NRF中的各类业务。

业务容器，是将REG模块、PATCH模块和SYN模块合并转换后形成的一个服务化的容器。

DB容器、SBI容器和业务容器之间通过标准的服务化接口进行通信。

参阅图5所示，所谓标准的服务化接口，其协议栈具体的包括有：应用层(Application)、超文本传输协议层(HTTP/2)、网络协议层(IP)、层2(L2)和层1(L1)。

基于上述服务化接口的协议栈，SBI容器、DB容器和业务容器之间的、DB、业务容器间统一资源标识(URI)规范约定如下：

URI中需要包括五元组{apiRoot}/服务名{apiName}/服务版本号{apiVersion}/资源名{apiSpecificResourceUriPart}，其中，五元组至少包括源IP、目的IP、源端口、目的端口和协议类型。

URI的具体结构如图6所示，进一步地，URL结构中，除了五元组、服务名、版本号之外，资源名部分需要记录以下信息：

接收消息的容器ID、连接容器的网络的标识、SBI容器数据(可以为空)、DB容器数据(可以为空)、数据库健值、数据库维护信息等等。

当外部的NF发送请求消息(即外部的请求消息)至NRF时，SBI容器会将接收到的请求消息进行拆包，解析出报文中相关的对象表示法(JavaScript Object Notation，JSON)结构体内容。然后通过服务化接口将获得的JSON结构体内容发送给业务容器进行处理，并通过服务化接口通知DB容器进行本地数据更新。

业务容器对接收的JSON结构体内容进行处理，并构建相应的响应消息，以及将所述响应消息采用新的JSON结构体内容的形式，通过服务化接口发送给所述SBI容器，触发所述SBI容器对所述响应消息进行解析，并在进行HTTP封装后发送至相应的NF。

在业务容器处理完成后会构建相应的响应消息并以JSON结构体内容的形式通过服务接口发送给SBI容器，SBI容器负责进行将响应消息进行拆包，并在进行HTTP封装后对外部相应的NF发送。

进一步地，由于容器化NRF中，DB容器、SBI容器和业务容器之间通过标准的服务化接口进行通信，因而可以按照HTTP协议，定义DB容器、SBI容器和业务容器之间交互时能够使用的方法(Method)，具体的，可以包括以下五种：获取(get)、放入(put)、传输(post)、补丁(patch)、删除(delete)。

同时，定义了容器之间交互的服务化消息的消息头标识(ulMsgID)，具体结果为：

针对HTTP消息部分(即HTTP_MSG)，可以将消息头标识定义为：80000001。

针对数据部分(即SUPI_AID_DEL_MSG)，可以将消息头标识定义为：1。

另一方面，还需要定义服务化消息的内容类型(ulContentType)，每个容器内部也会存在多个功能子模块，各个功能子模块之间可以自定义的内部消息进行交互，具体结果为：

针对容器之间的消息，可以将内容类型定义为：

CONTENT_TYPE_APPLICATION_JSON 0；

针对容器内部的消息，可以将内容类型定义为：

CONTENT_TYPE_MULTIPART_RELATED 1。

进一步地，本发明实施例中，在容器化的NRF内，各个容器之间采用标准的服务化接口进行通信时，基于服务化消息发送的发送请求消息中至少携带以下数据项：

用户标识(stSupi)、目标地址(stDestIpAddr)、目标端口(usDstPort)、统一资源位置标识(aucURI)、方法名称(usMethod)、源地址(stSrcIpAddr)、消息长度(ulJsonLength)、期望获得的反馈(aucRsv)和内容类型(ulContent Type)。

相应的，各个容器之间采用标准的服务化接口进行通信时，基于服务化消息发送的响应消息中至少携带以下数据项：

用户标识(stSupi)、流标识(ulStreamId)、连接标识(usConnectID)、消息长度(ulJsonLength)、内容类型(ulContentType)，响应代码(ulResponseCode)(对应于上述aucRsv)和发送响应消息的网元位置信息(aucLocation)。

其中，各个容器首次发送响应消息时，需要携带用于表征建立HTTP长连接的长连接标识(usAID)，并置长连接标志位ulFlag的第0bit为1，之后再发送的响应消息中不再携带usAID，直到拆除长连接时，再返回响应消息中需要将ulFlag的第0bit置为0，后续发送的响应消息中不再携带usAID。

可选的，各个容器之间交互请求消息和响应消息时，都需要根据实际发送的消息类型携带相应的ulContentType。

可选的，本发明实施例中，各个容器之间采用的标准的服务化接口进行通信时，是指业务容器、SBI容器和DB容器之间使用标准的“HTTP+JSON接口进行通信，业务容器可以通过资源表找到SBI容器所在的架框槽信息。

例如，D B容器上报的服务类型为296，业务容器通过查询R_lte DevResourceEntry表中的lteDevResourceServiceType字段为296的记录，获取SBI容器的通讯四字节，字段为lteDevResourceInetAddr；同时，假设SBI容器与业务容器之间通讯的纤程ID为：0xFC0000；同时，SBI容器也通过感知R_lteDevResourceEntry表中的服务类型，确定业务容器的通讯四字节和纤程ID。

另一方面，SBI容器与外部的各个NF进行通信时，也需要采用指定的信令消息体结构：

下边以释放会话管理上下文服务消息(Release SM Context service Message)作为示例对上述信令消息体结构进行说明。

参阅表1所示，SBI容器从NF接收的外部的请求消息，至少携带以下数据项：

表1

[Release SM Context service Message(Request)]

通过表1可以看出，SBI容器从NF接收的外部的请求消息是基于标准的服务化消息的信令消息体结构设计的，不同之处在于，需要在上述外部的请求消息中携带网元位置信息。

相应的，参阅表2所示，SBI容器向NF返回的响应消息，至少携带以下数据项：

表2

[Release SM Context service Message(Response)]

通过表2可以看出，SBI容器向NF返回的响应消息也是基于标准的服务化消息的信令消息体结构设计的，不同之处在于，需要在上述响应消息中携带相应的响应码。

即Release SM Context service Message(Response)需要将Response Code信息携带在服务化消息体中，以及在服务化消息体中根据响应码携带相应的内容。

基于上述架构的NRC系统，本发明实施例中，基于同一种发明构思，还一种容器化网络注册功能实体NRF的方法，包括：

设置用于提供底层的硬件设备支持的硬件层；

在所述硬件层之上，设置用于负责对底层的硬件设备的管理的宿主机操作系统HOST OS层；

在所述HOST OS层之上，设置用于实现虚拟化层中间件功能的应用容器引擎层；

在位于所述应用容器引擎层之上，设置包含有多个容器的应用层，各个容器之间采用标准的服务化接口进行通信，其中，所述多个容器至少包括：

SBI容器，用于针对各个容器提供外部的通信协议的处理；

业务容器，用于处理接收到的各类业务请求；

DB容器，用于针对各个容器负责本地数据的存储和读写。

可选的，所述标准的服务化接口，采用的协议栈包括有：

应用层、超文本传输协议层、网络协议层、层2和层1。

可选的，各个容器之间采用的统一资源标识URI规范包括：

五元组、服务名、服务版本号和资源名，其中，五元组至少包括源IP、目的IP、源端口、目的端口和协议类型。

可选的，所述资源名至少包括以下信息：

接收消息的容器ID、连接容器的网络的标识、SBI容器数据、DB容器数据、数据库健值和数据库维护信息。

可选的，所述各个容器之间采用标准的服务化接口进行通信时，采用的服务化消息中至少包含消息头标识和内容类型；其中，

所述消息头类型用于指示所述服务化消息是超文本传输协议HTTP消息部分或数据部分；

所述内容类型用于指示所述服务化消息是容器之间交互的消息或容器内部交互的消息。

可选的，所述各个容器之间采用标准的服务化接口进行通信时，基于服务化消息发送的请求消息中至少携带以下数据项：

用户标识、目标地址、目标端口、统一资源位置标识、方法名称、源地址、消息长度、期望获得的反馈和内容类型；

各个容器之间采用服务化消息进行交互时，在发送响应消息时，至少携带以下数据项：

用户标识、流标识、连接标识、消息长度、内容类型，响应代码和发送响应消息的网元位置信息。

可选的，进一步包括：

通过所述SBI容器执行以下操作：

接收网络功能实体NF发送的外部的请求消息，对所述外部的请求消息进行解析，获得相关的对象表示法JSON结构体内容，并通过服务化接口将获得的JSON结构体内容发送给所述业务容器进行处理，再通过服务化接口通知所述DB容器进行本地数据更新；

通过所述业务容器执行以下操作：

对接收的JSON结构体内容进行处理，并构建相应的响应消息，以及将所述响应消息采用新的JSON结构体内容的形式，通过服务化接口发送给所述SBI容器，触发所述SBI容器对所述响应消息进行解析，并在进行HTTP封装后发送至所述NF。

可选的，进一步用于包括：

通过所述SBI容器与外部的NF进行交互时，接收NF基于标准的服务化消息的信令消息体结构生成相应的请求消息，所述请求消息中携带相应的网元位置信息；或/和，

通过所述SBI容器与外部的NF进行交互时，基于标准的服务化消息的信令消息体结构生成相应的响应消息，所述响应消息中携带有相应的响应码。

综上所述，本发明实施例中，将NRF系统原有架构的基础上，在HOST OS层之上设置了用于实现虚拟化层中间件的应用容器引擎层，而在应用容器引擎层之上的应用层中，设置有多个容器，各个容器之间采用标准的服务化接口进行通信，其中，所述多个容器至少包括：SBI容器，用于针对各个容器提供外部的通信协议的处理；业务容器，用于执行各类的业务处理；DB容器，用于针对各个容器负责本地数据的存储和读写。

这样，相较于已有的虚拟机NRF方案，由于不再设置GUEST OS，因此有效实现了NRF系统的轻量化，也减少了NRF系统运行过程中所需要的资源消耗，从而显著提升了NRF系统的运行效率。另一方面，采用本发明技术方案，令容器化后的NRF系统具有很强的扩展性，在动态扩缩容过程中只需要对相应容器进行增减即可完成相关操作，有力的支持了运营商的灵活部署。

因此，本发明技术方案中设计的容器化后的NRF系统在5G核心网的实际部署方面有较为广阔的应用前景。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。

显然，本领域的技术人员可以对本发明实施例进行各种改动和变型而不脱离本发明实施例的精神和范围。这样，倘若本发明实施例的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (16)

1.一种容器化网络注册功能实体NRF的系统，其特征在于，包括：

硬件层，用于提供底层硬件设备支持；

宿主机操作系统HOST OS层，位于所述硬件层之上，用于对底层硬件设备进行管理，以及对上层提供操作接口；

应用容器引擎层，位于所述HOST OS层之上，用于实现虚拟化层中间件功能；

应用层，位于所述应用容器引擎层之上，设置有多个容器，各个容器之间采用标准的服务化接口进行通信，其中，所述多个容器至少包括：

SBI容器，用于针对各个容器提供外部的通信协议的处理；

业务容器，用于执行各类的业务处理；

DB容器，用于针对各个容器负责本地数据的存储和读写。

2.如权利要求1所述的系统，其特征在于，所述标准的服务化接口，采用的协议栈包括有：

应用层、超文本传输协议层、网络协议层、层2和层1。

3.如权利要求2所述的系统，其特征在于，各个容器之间采用的统一资源标识URI规范包括：

五元组、服务名、服务版本号和资源名，其中，五元组至少包括源IP、目的IP、源端口、目的端口和协议类型。

4.如权利要求3所述的系统，其特征在于，所述资源名至少包括以下信息：

接收消息的容器ID、连接容器的网络的标识、SBI容器数据、DB容器数据、数据库健值和数据库维护信息。

5.如权利要求1所述的系统，其特征在于，所述各个容器之间采用标准的服务化接口进行通信时，采用的服务化消息中至少包含消息头标识和内容类型；其中，

所述消息头标识用于指示所述服务化消息是超文本传输协议HTTP消息部分或数据部分；

所述内容类型用于指示所述服务化消息是容器之间交互的消息或容器内部交互的消息。

6.如权利要求1所述的系统，其特征在于，所述各个容器之间采用标准的服务化接口进行通信时，基于服务化消息发送的请求消息中至少携带以下数据项：

用户标识、目标地址、目标端口、统一资源位置标识、方法名称、源地址、消息长度、期望获得的反馈和内容类型；

各个容器之间采用服务化消息进行交互时，基于服务化消息发送的响应消息时，至少携带以下数据项：

用户标识、流标识、连接标识、消息长度、内容类型，响应代码和发送响应消息的网元位置信息。

7.如权利要求1－6任一项所述的系统，其特征在于，所述SBI容器进一步用于：

接收的网络功能实体NF发送的外部的请求消息，对所述外部的请求消息进行解析，获得相关的对象表示法JSON结构体内容，并通过服务化接口将获得的JSON结构体内容发送给所述业务容器进行处理，再通过服务化接口通知所述DB容器进行本地数据更新；

所述业务容器进一步用于：

对接收的JSON结构体内容进行处理，并构建相应的响应消息，以及将所述响应消息采用新的JSON结构体内容的形式，通过服务化接口发送给所述SBI容器，触发所述SBI容器对所述响应消息进行解析，并在进行HTTP封装后发送至所述NF。

8.如权利要求1－6任一项所述的系统，其特征在于，SBI容器进一步用于：

与外部的NF进行交互时，接收NF基于标准的服务化消息的信令消息体结构生成相应的请求消息，所述请求消息中携带相应的网元位置信息；或/和

与外部的NF进行交互时，基于标准的服务化消息的信令消息体结构生成相应的响应消息，所述响应消息中携带有相应的响应码。

9.一种容器化网络注册功能实体NRF的方法，其特征在于，包括：

设置用于提供底层的硬件设备支持的硬件层；

在所述硬件层之上，设置用于负责对底层的硬件设备的管理的宿主机操作系统HOSTOS层；

在所述HOST OS层之上，设置用于实现虚拟化层中间件功能的应用容器引擎层；

在位于所述应用容器引擎层之上，设置包含有多个容器的应用层，各个容器之间采用标准的服务化接口进行通信，其中，所述多个容器至少包括：

SBI容器，用于针对各个容器提供外部的通信协议的处理；

业务容器，用于处理接收到的各类业务请求；

DB容器，用于针对各个容器负责本地数据的存储和读写。

10.如权利要求9所述的方法，其特征在于，所述标准的服务化接口，采用的协议栈包括有：

应用层、超文本传输协议层、网络协议层、层2和层1。

11.如权利要求10所述的方法，其特征在于，各个容器之间采用的统一资源标识URI规范包括：

五元组、服务名、服务版本号和资源名，其中，五元组至少包括源IP、目的IP、源端口、目的端口和协议类型。

12.如权利要求11所述的方法，其特征在于，所述资源名至少包括以下信息：

接收消息的容器ID、连接容器的网络的标识、SBI容器数据、DB容器数据、数据库健值和数据库维护信息。

13.如权利要求9所述的方法，其特征在于，所述各个容器之间采用标准的服务化接口进行通信时，采用的服务化消息中至少包含消息头标识和内容类型；其中，

所述消息头类型用于指示所述服务化消息是超文本传输协议HTTP消息部分或数据部分；

所述内容类型用于指示所述服务化消息是容器之间交互的消息或容器内部交互的消息。

14.如权利要求9所述的方法，其特征在于，所述各个容器之间采用标准的服务化接口进行通信时，基于服务化消息发送的请求消息中至少携带以下数据项：

用户标识、目标地址、目标端口、统一资源位置标识、方法名称、源地址、消息长度、期望获得的反馈和内容类型；

各个容器之间采用服务化消息进行交互时，在发送响应消息时，至少携带以下数据项：

用户标识、流标识、连接标识、消息长度、内容类型，响应代码和发送响应消息的网元位置信息。

15.如权利要求9－14任一项所述的方法，其特征在于，进一步包括：

通过所述SBI容器执行以下操作：

接收网络功能实体NF发送的外部的请求消息，对所述外部的请求消息进行解析，获得相关的对象表示法JSON结构体内容，并通过服务化接口将获得的JSON结构体内容发送给所述业务容器进行处理，再通过服务化接口通知所述DB容器进行本地数据更新；

通过所述业务容器执行以下操作：

对接收的JSON结构体内容进行处理，并构建相应的响应消息，以及将所述响应消息采用新的JSON结构体内容的形式，通过服务化接口发送给所述SBI容器，触发所述SBI容器对所述响应消息进行解析，并在进行HTTP封装后发送至所述NF。

16.如权利要求9－14任一项所述的方法，其特征在于，进一步用于包括：

通过所述SBI容器与外部的NF进行交互时，接收NF基于标准的服务化消息的信令消息体结构生成相应的请求消息，所述请求消息中携带相应的网元位置信息；或/和

通过所述SBI容器与外部的NF进行交互时，基于标准的服务化消息的信令消息体结构生成相应的响应消息，所述响应消息中携带有相应的响应码。

Images