一种面向4G和5G融合核心网的信令代理架构及统一信令处理方法与流程

本发明属于通信，具体涉及一种面向4g和5g融合核心网的信令代理架构及统一信令处理方法。

背景技术：

1、随着第五代移动通信技术5g的商用部署，全球运营商面临4g网络与5g网络长期共存的现实局面。在融合过渡阶段，4g epc与5gc需要实现互通，以支持用户在4g和5g网络之间的无缝移动性管理和会话连续性。在上述演进过程中，为保障存量4g用户的业务连续性，同时充分利用5gc的云原生架构优势，业界提出了4g和5g融合核心网的概念，即在同一个核心网平台上同时处理4g和5g业务。

2、现有的融合核心网方案主要采用"网元内嵌式融合"策略，参照图1，即在5g网元内部同时集成4g和5g协议栈。典型的融合网元包括：smf/pgw-c融合网元：会话管理功能smf内部集成pgw控制面pgw-c功能，需同时支持5g的n4接口（pfcp协议）、n7接口（http/sbi协议）以及4g的s5/s8接口（gtpv2-c协议）、gx接口（diameter协议）；udm/hss融合网元：统一数据管理udm内部集成归属用户服务器hss功能，需同时支持5g的nudm系列sbi接口（http协议）以及4g的s6a接口（diameter协议）；upf/pgw-u融合网元：用户面功能upf内部集成pgw用户面pgw-u，需同时支持5g的n3/n9接口和4g的s1-u/s5-u接口（均基于gtp-u协议）。上述“网元内嵌式融合”方案虽然功能上能够满足4g和5g互通需求，但存在以下显著缺陷：

3、架构不纯粹，服务化设计被破坏：内嵌式融合方案强制要求5g网元内部同时集成厚重的传统协议栈diameter协议栈和gtpv2-c协议栈，这些传统协议与http微服务的设计理念存在根本性冲突，破坏了基于服务的体系架构sba的纯洁性和简洁性。

4、开发与维护成本高昂：内嵌式融合方案要求研发人员同时掌握传统通信协议的底层实现细节，包括但不限于：（1）diameter协议的属性值对avp编解码、命令码处理、结果码映射；（2）gtpv2-c协议的信息元素ie编解码、类型-‌长度-‌值tlv格式处理、bearercontext的复合ie嵌套解析。上述跨协议栈的研发需求显著增加了开发周期和测试工作量，延缓了融合核心网的商用进度。

5、云原生弹性扩缩容受阻：在云原生部署环境（如kubernetes）中，容器实例pod的ip地址是由平台动态分配的，pod销毁重建后ip随之改变。然而，diameter协议和gtpv2-c协议均基于固定ip的对等通信模型：mme必须预先配置hss的固定ip地址以建立s6a diameter对等连接，同时配置sgw的固定ip地址以发送s11 gtpv2-c信令。当承载这些协议的融合网元部署在云原生平台时，pod ip的动态变化与协议要求的固定ip地址之间存在根本冲突，导致融合网元无法像5g http微服务那样自由地进行弹性伸缩。此外，融合网元内部通常在进程本地内存中维护大量有状态的用户会话上下文，实例的增减直接导致会话状态丢失或不一致，进一步加剧了云原生扩缩容的困难。

技术实现思路

1、本发明针对上述背景技术中存在的问题，提出一种面向4g和5g融合核心网的信令代理架构及统一信令处理方法，基于纯粹的5g服务架构实现了4g和5g融合核心网，大幅降低开发与维护成本，统一弹性扩缩容机制，并且实现了弹性扩缩容零中断，全面具备云原生热迁移能力。

2、一种面向4g和5g融合核心网的信令代理架构，包括4g移动管理实体mme、融合代理网元proxy和5g核心网网元群5gc nfs；其中，

3、4g移动管理实体mme，负责4g终端的接入管理、移动性管理和承载管理，与归属用户服务器hss交互获取签约数据和鉴权向量，与sgw交互管理演进分组系统eps承载；

4、融合代理网元proxy，独立部署在mme与5gc之间，包括南向协议适配模块、协议转换引擎、上下文管理模块和北向sbi客户端模块；

5、其中，南向协议适配模块包括diameter协议终结点和gtpv2-c协议终结点，以实现diameter基础协议栈和gtpv2-c协议栈；协议转换引擎实现4g→5g正向转换和5g→4g反向转换，并保存4g参数与5g参数之间的参数映射规则表；上下文管理模块包括eps会话上下文缓存和映射关系表，并对4g侧和5g侧的用户会话进行状态管理；北向sbi客户端模块为http协议客户端，实现网元服务发现与选择；

6、5g核心网网元群5gc nfs包括实现各项具体功能的5g网元，包括统一数据管理udm、认证服务器功能ausf、会话管理功能smf、策略控制功能pcf、用户面功能upf。

7、基于上述面向4g和5g融合核心网的信令代理架构的统一信令处理方法，包括用户鉴权与签约数据获取、用户位置更新、pdn连接/会话建立和会话释放的四部分流程；其中，

8、用户鉴权与签约数据获取流程中，proxy接收mme的认证信息请求，进行协议转换并向5gc nfs的认证服务器功能ausf发起请求，ausf进行鉴权并返回结果，proxy再次进行协议转换，将认证信息应答返回给mme；

9、用户位置更新流程中，proxy接收mme的更新位置请求，进行协议转换并向5gc nfs的统一数据管理udm发起请求，udm进行注册和代理，获取用户的签约数据，proxy再次进行协议转换，将更新位置应答返回给mme；

10、pdn连接/会话建立流程中，proxy接收mme的创建会话请求，创建会话上下文并分配id，进行协议转换并向5gc nfs的会话管理功能smf发起请求，smf进行处理并返回创建响应，proxy再次进行协议转换，将创建会话响应返回给mme；

11、会话释放流程中，proxy接收mme的释放会话请求，查询对应的内容id和对话id，向5gc nfs的会话管理功能smf发起释放会话请求，smf执行会话释放流程并返回结果，proxy清理本地上下文，将释放会话响应返回给mme。

12、与现有技术相比，本发明的有益效果包括：

13、（1）架构纯粹性保持：

14、本发明通过独立部署的融合代理网元proxy，将4g传统信令协议栈（diameter、gtpv2-c/udp）完全终结在proxy上。5gc内部的业务处理网元（smf、udm、ausf、pcf等）无需引入任何4g协议栈代码，完全保持5g 基于服务的体系架构sba（service basedarchitecture）架构的纯粹性和简洁性。各5gc网元仅通过标准http/2协议的sbi接口进行交互，符合3gpp 5g核心网的云原生设计理念。

15、（2）开发与维护成本大幅降低：

16、4g传统协议栈的实现复杂度被集中封装在proxy内部，5gc网元的研发团队无需掌握diameter协议的avp编解码、gtpv2-c的teid管理和ie嵌套解析等底层通信协议细节。5gc网元侧仅需处理标准的或少量扩展的http json字段，可复用成熟的web微服务开发框架和工具链，显著降低研发人员的技能门槛和学习成本。同时，4g协议栈的bug修复和版本升级仅影响proxy网元，无需对5gc网元进行联动修改，维护效率大幅提升。

17、（3）云原生弹性扩缩容与零中断迁移：

18、本发明通过稳定虚拟ip接入与无状态架构设计，解决了diameter和gtpv2-c协议基于固定ip通信而无法在云原生环境中弹性伸缩的核心矛盾。proxy通过kubernetesservice对外暴露稳定的虚拟ip，mme将此虚拟ip配置为hss和sgw地址，无论后端proxy pod如何增减，该虚拟ip始终不变，对mme完全透明。同时，proxy采用计算与存储分离的无状态化架构，将全部用户会话上下文外置至分布式内存数据库集群，任意proxy实例均可处理任意用户的信令请求。在扩容场景下，新实例启动后即可承接新请求，无需预热；在缩容场景下，通过排水机制与diameter协议的对等断连过程实现优雅关闭，mme自动向虚拟ip重新建立连接并被路由至健康实例，会话状态从分布式数据库按需加载，实现零中断迁移。5gc内部网元的弹性扩缩容则完全基于标准的kubernetespod水平自动扩缩hpa，不受传统电信协议约束。