CN116456292B - 一种用于用户面和控制面分离架构的信令交互方法及装置 - Google Patents

Abstract

本发明公开了一种用于用户面和控制面分离架构的信令交互方法及装置，在创建及更新用量上报规则信元中加入新的内容锚定用量上报规则ID，使除锚定用量上报规则ID所在创建及更新用量上报规则携带完整内容外，其余创建及更新用量上报规则信元携带的内容不需要携带完整内容，而只需要通过索引锚定用量上报规则ID对应的创建及更新用量上报规则内容，同时通过原有信元携带对索引用量上报规则ID的创建及更新用量上报规则内容的改变项目，从而在不减少创建及更新用量上报规则总数目情况下有效降低对应总体创建及更新用量上报规则所需携带内容所需比特数。

Description

一种用于用户面和控制面分离架构的信令交互方法及装置

技术领域

本发明涉及计算机网络和通信技术领域，特别涉及一种用于用户面和控制面分离架构的信令交互方法及装置。

背景技术

目前第四代通信（4G）以及第五代通信系统（5G）的核心网采用控制面（CP）和用户面（UP）分离的架构。在大量用户接入场景，比如窄带物联网（NB-IoT Narrow-BandInternet of Things）或海量设备间通信（mMTC massive Machine Type Communication）场景中，存在着大量的分组数据单元会话（PDU session）的建立及修改，这使得控制面的会话管理网元（SMF session management function）需要针对每一个会话通过数据转发控制协议PFCP（Packet Forwarding Control Protocol）会话建立请求（PFCP SessionEstablishment Request）以及PFCP会话修改请求（PFCP Session Modification Request）来提供或修改作为用户面功能（UPF User Plane Function）网元的用户流量数据包检测规则（PDR Packet Detection Rule）以及用量上报规则（URR Usage Reporting Rules），这使得控制面和用户面网元负载过高，从而整体业务系统的稳定性和可靠性无法保证。

发明内容

本发明的目的在于提供一种用于用户面和控制面分离架构的信令交互方法及装置，以克服现有技术中的不足。

为实现上述目的，本发明提供如下技术方案：

本发明公开了一种用于用户面和控制面分离架构的信令交互方法，包括如下步骤：

步骤1：控制面对业务会话进行建立或修改；

步骤2：控制面检查当前创建或者修改会话选择的计费配置，确定对用户面装载流处理规则内容的重复部分；

步骤3：通过在创建及更新用量上报规则信元中加入新的锚定用量上报规则标识（ID， Identity），控制面检查重复内容并合并用量上报规则内容，只保留一份完整内容，其余用量上报规则均采用参考内容引用的方式；

步骤4：控制面下发经过重复用量上报规则内容索引处理的PFCP会话建立或修改请求到用户面；

步骤5：用户面收到PFCP会话建立或修改请求并成功重组各个创建及更新用量上报规则内容以及成功装载对应流处理规则后，回复PFCP会话建立或修改请求并把原因属性对设为成功；

步骤6：用户面根据收到的URR流上报处理规则，对上下行流量进行对应流量控制和流量整形操作。

所述步骤1中，控制面对会话的建立及修改通过PFCP协议在用户面进行对应流规则创建或修改。

所述步骤3的具体子步骤如下：

步骤3.1：在创建及更新用量上报规则信元中加入新的内容锚定用量上报规则ID，并使锚定用量上报规则ID所在创建及更新用量上报规则携带完整内容；

步骤3.2：除锚定用量上报规则ID所在创建及更新用量上报规则外，其余创建及更新用量上报规则信元通过索引锚定用量上报规则ID对应的创建及更新用量上报规则内容，同时仅携带对索引用量上报规则ID的创建及更新用量上报规则内容的改变项目。

所述步骤3中新加的锚定用量上报规则ID内容位于TS 29.244 标准规范的创建用量上报规则及更新用量上报规则信元中，为可选新加信元。

每一个创建及更新用量上报规则内容必须包含唯一内容识别用量上报规则ID，所述锚定用量上报规则ID用于指示被引用的用量上报规则ID对应的创建及更新用量上报规则内容，对被引用创建及更新用量上报规则内容中需要改变的部分，依据每个创建及更新用量上报规则包含信元项目为标准定义结构，重用当前用量上报规则 ID对应创建及更新用量上报规则的相应信元内容进行补充。

所述步骤3.2中，除锚定用量上报规则ID所在创建及更新用量上报规则携带完整内容外，其余创建及更新用量上报规则信元不需要携带完整内容。

所述步骤3.2中，所述其余创建及更新用量上报规则信元通过原有信元携带对索引用量上报规则ID的创建及更新用量上报规则内容的改变项目。

本发明公开了一种用于用户面和控制面分离架构的信令交互装置，所述装置包括存储器和一个或多个处理器，所述存储器中存储有可执行代码，所述一个或多个处理器执行所述可执行代码时，用于上述用于用户面和控制面分离架构的信令交互方法。

本发明的有益效果：在创建及更新用量上报规则信元中加入新的内容锚定用量上报规则ID，使得 PFCP会话建立或修改请求中用于传输相同数据面流处理规则所需的创建及更新用量上报规则信元数量在不变的情况下，除锚定用量上报规则ID所在创建及更新用量上报规则携带完整内容外，其余创建及更新用量上报规则信元携带的内容不需要携带完整内容，而只需要通过索引锚定用量上报规则ID对应的创建及更新用量上报规则内容，同时通过原有信元携带对索引用量上报规则ID的创建及更新用量上报规则内容的改变项目，从而在不减少创建及更新用量上报规则总数目情况下有效降低对应总体创建及更新用量上报规则所需携带内容所需比特数。对比传统方案和标准定义的改进方案，本发明有效减少因使用业务开始触发条件造成的外PFCP 会话上报流程（PFCP Session ReportProcedure）以及PFCP 会话建立/修改流程（PFCP Session Establishment/ModificationProcedure），这进一步减少了控制面和用户面间的信令交互，降低了该部分负载对控制面和用户面硬件上的处理能力、存储能力的需求。在高负载，大量用户接入场景中，（例如物联网NB-IoT, 5G海量物联网mMTC等）本发明可以低硬件成本以及高效的提升整体业务系统的稳定性和可靠性。

附图说明

图1是URR规则颗粒度以及URR规则非共享原则示意图；

图2是现有URR创建、修改及上报流程示意图；

图3是现存基于预定义规则的方法示意图；

图4是用于用户面和控制面分离架构的信令交互方法流程图；

图5是本发明实施例对图2所述方法的具体改进示意图；

图6是本发明实施例Anchor URR ID 为 “URR_1”的示意图；

图7是本发明实施例测量周期改为5s (Measurement Period = 5s)示例图；

图8是本发明实施例的装置示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明了，下面通过附图及实施例，对本发明进行进一步详细说明。但是应该理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限制本发明的范围。此外，在以下说明中，省略了对公知结构和技术的描述，以避免不必要地混淆本发明的概念。

为了便于对本发明实施例的理解，对现有技术中用户面和控制面信令交互方法传统方案和标准定义的改进方案做出如下描述：

用户面通过使用PFCP Session Report Procedure的PFCP 会话上报请求（PFCPSession Report Request）把PFCP 会话相关的信息上报给控制面。如图1所示，用量上报规则（URR）可以提供会话（Session）层面、承载（Bearer）层面、计费组（Rating Group）层面以及业务（Service）层面。大量的不同层级的创建及更新用量上报规则（Create/Update URR）信元（IE Information Element）内容需要在控制面和用户面间传递。如图1所示，不同用户选择相同会话层级、承载层级、计费组层级、业务层级的计费配置文件（charging profile）执行相同的对应层级URR策略。针对不同的层级，或者同层级不同的会话（通过会话ID区分）、承载（通过承载ID区分）、计费组（通过计费组ID区分）及业务（通过业务ID区分），也需要通过各自的Create/Update URRs消息传递全新的完整URR信元内容，即使这些信息内容是完全一致的。

图2给出了典型的URR规则交互流程。假设有已经建立好的4个会话并需要提供URR上报规则。URR上报规则信息通过PFCP Session Establishment/Modification Request在控制面（SMF）和用户面（UPF）间交互 （图2 Create/Update URR中 周期PERIO = 10秒，掉包率门限DROPTH = 10%，使用时间门限TIMTH = 10s）。此时即使各个会话选择了相同的计费配置文件，并传递相同的URR信息，控制面（SMF）仍然需要使用独立URR ID对每个会话发送完整的 “Create/Update URRs”信息，用户面需要根据控制面传递的信息加载4个独立的URR规则（图2 URR_ 1, URR_2, URR_3 以及URR_4），即使该Create/Update URR中包含的信息完全一致。

此外，在接收到用户面UPF发来的 “PFCP Session Report Request”后，控制面会话管理网元SMF常常需要额外发送 “PFCP Session Modification Request” 给用户面来更新对应URR内容，比如用户流量额度（quota），流量上报门限值（VOLTH）,时间检测门限值（TIMTH）等等。这导致了控制面和用户面间产生更多的 “Create/Update URR” 信令，尤其当各个Create/Update URR包含相同内容的时候。如图2所示，在接收到 “URR_1”和 “URR_2” 的会话报告后， 控制面需要分别为“URR_1”和 “URR_2” 发送 “PFCP SessionModification Request” 来更新对应的新使用时间门限（TIMTH = 20s）。

为解决该问题，目前3GPP TS29.244 标准化了预定义规则的方法 （pre-definedRule）。如图3所示，该方法仅使用URR ID及业务开始（service start trigger）作为触发条件来代替“PFCP Session Establishment / Modification Request”中的完整的URR内容。只有在对应业务流开始后并被用户面检测到，用户面上报该URR对应业务已经开始，并通过“PFCP Session Reporting Request” 申请控制面对用户面下发此上报的URR全部内容。

如图3所示，给出TS29.244中预定义规则方法详细流程如下：

1.SMF对UPF发送 “PFCP Session Establishment/Modification Request”，该请求中包含对应 “Create/Update URRs” 并设置上报触发条件为开始”(Usage ReportTrigger = START”)。

2.UPF收到 “PFCP Session Establishment/Modification Request” 后保存该信息并在所有对应的规则都成功保存和装载后，回复 “PFCP 会话建立/修改响应（ PFCPSession Establishment/Modification Response）” 并设置原因值为“成功”(cause=“success")。

3.UPF在检测到对应业务开始后发送 “PFCP Session Report Request” 上报给SMF。

4.SMF接收到 “PFCP Session Report Request” 信息并在成功处理后回复 “会话上报响应（PFCP Session Report Response）” 及设置原因为“成功”(cause =“success”)。

5.UPF接收到 设置原因为“成功”(cause = “success”) 的“PFCP SessionReport Respons” 消息。

6.SMF发起 “PFCP Session Modification Request”来发送对应开始业务所需的全部URR内容到UPF。

7.UPF装载收到的URR检测规则并回复 “PFCP Session Modification Response”来确认对应的更新URR内容已成功安装到UPF (对应被检测已开始业务所需的完整 URR 内容)。

8.当对应更新的URR内容再次被触发后，UPF发起 “PFCP Session ReportProcedure”来对触发条件内容进行上报。

如图3所示，此技术存在以下几点问题

1.控制面和用户面需要实时同步URR规则的模板来更新业务开始触发条件，对比无预制规则的方法，这会造成额外的信令交互。

2.对比没有采用预定义URR规则的方法，每个会话层级、承载层级、计费组层级、业务层级的业务开始触发额外会增加一次PFCP 会话上报流程。

3.加剧对控制面和用户面的处理能力的需求，例如存储空间大小，并发处理能力等。取决于触发的业务数量。在最坏情况下，比传统无预定义URR策略的方法多2*N（N为触发上报次数）次 PFCP 会话上报流程。

如上所述，显然该方法没有起到有效降低控制面和用户面负载的作用。

因此，参考图4，本发明实施例提供了一种用于用户面和控制面分离架构的信令交互方法，基于控制面和用户面间交互内容重复部分参考索引的方法，包括以下步骤：

步骤一：控制面对业务会话进行建立或修改，控制面对会话的建立及修改需要通过PFCP协议在用户面进行对应流规则创建或修改。

步骤二：控制面检查当前创建或者修改会话选择的计费配置，确定对用户面装载流处理规则内容的重复部分。

步骤三：控制面检查重复内容并合并URR规则内容，只保留一份完整内容，其余URR均采用参考内容引用的方式。

该步骤是本发明的核心，具体步骤如下。

在Create/Update URR信元中加入新的内容锚定URR ID，使得PFCP 会话建立/修改请求中总体用于传输相同数据面流处理规则所需的创建/更新用户上报规则信元数量在不变的情况下，除锚定URR ID所在创建/更新用量上报规则需要携带完整内容外，其余创建/更新用量上报规则信元携带的内容不需携带完整内容，而只需要通过索引锚定URR ID对应的创建/更新用量上报规则内容，同时仅携带对索引URR ID的创建/更新用量上报规则内容的改变项目（通过原有信元携带），从而在不减少创建/更新用量上报规则总数目情况下有效降低对应总体创建/更新用量上报规则所需携带内容所需比特数。

如表格1所示，本发明提出了一种新的Create/Update URR 内容索引方法。该方法新加的锚定URR ID（Anchor URR ID）内容位于TS 29.244 标准规范的Create URR及UpdateURR 信元中，为可选新加信元（表格1中 “O”：Optional）。 因每一个Create/Update URR内容必须（表格1中 “M”：Mandatory）包含唯一内容识别URR ID，该锚定URR ID用于指示被引用的URR ID对应的Create/Update URR内容，因此每个Create/Update URR必须携带一个“URR ID”，可选携带一个 “Anchor URR ID”，共两个URR ID。而对被引用Create/UpdateURR内容中需要改变的部分，即当前所需Create/Update URR的内容与引用的锚定URR ID的Create/Update URR内容的不同部分，因每个Create/Update URR包含信元项目为标准定义结构，则重用当前URR ID对应Create/Update URR 的相应信元内容进行补充。

步骤四：控制面下发经过重复URR规则内容索引处理的PFCP SessionEstablishment/Modification Request 到用户面。

步骤五：用户面收到PFCP Session Establishment/Modification Request并成功重组各个Create/Update URR内容以及成功装载对应流处理规则后，回复PFCP SessionEstablishment/Modification Response并把原因设置为 “成功” （cause= “success”）。

步骤六：用户面根据收到的URR流处理规则，对上下行流量进行对应流量控制和流量整形操作。

图5给出了本发明对图2方法步骤一的具体改进:

URR上报规则信息通过PFCP Session Establishment/Modification Request在控制面（SMF）和用户面（UPF）间交互 （图2 Create/Update URR中 上报周期PERIO = 10秒，掉包率门限DROPTH = 10%，使用时间门限TIMTH = 10s），此时4个承载（Bearer）除URR_2需要对测量周期信息修改为5s（上报周期PERIO = 5s）外，其余均为相同的URR信息。控制面（SMF）使用独立URR ID（URR_1, URR_2, URR_3和URR_4）对每个承载分别发送独立“Create/Update URR”信息并分别携带锚点URR ID (“Anchor URR ID = URR_1”)来引用对 URR_1的对应“Create/Update URR” 内容（ URR_3和URR_4对应为 “触发条件Triggers(PERIO=10s,DROPTH= 10%, TIMETH=10s)”, URR_2 对应为“触发条件Triggers(PERIO=5s, DROPTH=10%, TIMETH=10s)”）。

收到控制面信息后，用户面对每个承载（图5 共4个承载层面URR）加载独立的URR规则（图5中 URR_ 1, URR_2, URR_3 和URR_4），其中只有URR_1的内容是完整内容，其他URR内容（URR_2, URR_3 和URR_4）内容采用引用URR_1的方式，注意此时URR_2中的测量周期（Measurement Period修改为5s: PERIO = 5s）。

表格2给出了 “URR ID = URR_2” 的“Create/Update URR”内容 ，图6给出了锚定URR ID （Anchor URR ID）为URR_1的ID格式示例。URR_3和URR_4对应“Create/Update URR”内容携带相同锚定 URR ID结构。其中URR_2由于对测量周期进行修改（MeasurementPeriod修改为5s: PERIO = 5s），额外携带了测量周期信元（表格2 中 “MeasurementPeriod”），并将测量周期信元设定为5s（图7中 “Measurement Period = 5s”）。因URR3及URR_4对应“Create/Update URR”内容对引用 “URR ID = URR_1” 的“Create/Update URR”内容无修改，对应“Create/Update URR”内容（表格3和表格4）仅需携带锚定 URR ID(“Anchor URR ID = URR_1”）即可。

参见图8，本发明实施例还提供了一种用于用户面和控制面分离架构的信令交互装置，还包括存储器和一个或多个处理器，存储器中存储有可执行代码，所述一个或多个处理器执行所述可执行代码时，用于实现上述实施例中的用于用户面和控制面分离架构的信令交互方法。

本发明一种用于用户面和控制面分离架构的信令交互装置的实施例可以应用在任意具备数据处理能力的设备上，该任意具备数据处理能力的设备可以为诸如计算机等设备或装置。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在任意具备数据处理能力的设备的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图8所示，为本发明一种用于用户面和控制面分离架构的信令交互的装置所在任意具备数据处理能力的设备的一种硬件结构图，除了图8所示的处理器、内存、网络接口、以及非易失性存储器之外，实施例中装置所在的任意具备数据处理能力的设备通常根据该任意具备数据处理能力的设备的实际功能，还可以包括其他硬件，对此不再赘述。上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本发明方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

本发明实施例还提供一种计算机可读存储介质，其上存储有程序，该程序被处理器执行时，实现上述实施例中的用于用户面和控制面分离架构的信令交互方法。

所述计算机可读存储介质可以是前述任一实施例所述的任意具备数据处理能力的设备的内部存储单元，例如硬盘或内存。所述计算机可读存储介质也可以是任意具备数据处理能力的设备的外部存储设备，例如所述设备上配备的插接式硬盘、智能存储卡(Smart Media Card，SMC)、SD卡、闪存卡(Flash Card)等。进一步的，所述计算机可读存储介质还可以既包括任意具备数据处理能力的设备的内部存储单元也包括外部存储设备。所述计算机可读存储介质用于存储所述计算机程序以及所述任意具备数据处理能力的设备所需的其他程序和数据，还可以用于暂时地存储已经输出或者将要输出的数据。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换或改进等，均应包含在本发明的保护范围之内。

Claims (8)

1.一种用于用户面和控制面分离架构的信令交互方法，其特征在于：包括如下步骤：

步骤1：控制面对业务会话进行建立或修改；

步骤2：控制面检查当前创建或者修改会话选择的计费配置，确定对用户面装载流处理规则内容的重复部分；

步骤3：通过在创建及更新用量上报规则信元中加入新的锚定用量上报规则ID，控制面检查重复内容并合并用量上报规则内容，只保留一份完整内容，其余用量上报规则均采用参考内容引用的方式；

步骤4：控制面下发经过重复用量上报规则内容索引处理的PFCP会话建立或修改请求到用户面；

步骤5：用户面收到PFCP会话建立或修改请求并成功重组各个创建及更新用量上报规则内容以及成功装载对应流处理规则后，回复PFCP会话建立或修改请求并把原因属性对设为成功；

步骤6：用户面根据收到的URR流处理规则，对上下行流量进行对应流量控制和流量整形操作。

2.如权利要求1所述的一种用于用户面和控制面分离架构的信令交互方法，其特征在于：所述步骤1中，控制面对会话的建立及修改通过PFCP协议在用户面进行对应流规则创建或修改。

3.如权利要求1所述的一种用于用户面和控制面分离架构的信令交互方法，其特征在于：所述步骤3的具体子步骤如下：

步骤3.1：在创建及更新用量上报规则信元中加入新的内容锚定用量上报规则ID，并使锚定用量上报规则ID所在创建及更新用量上报规则携带完整内容；

步骤3.2：除锚定用量上报规则ID所在创建及更新用量上报规则外，其余创建及更新用量上报规则信元通过索引锚定用量上报规则ID对应的创建及更新用户上报规则内容，同时仅携带对索引用量上报规则ID的创建及更新用量上报规则内容的改变项目。

4.如权利要求1所述的一种用于用户面和控制面分离架构的信令交互方法，其特征在于：所述步骤3中新加的锚定用量上报规则ID内容位于TS29.244标准规范的创建用量上报规则及更新用量上报规则信元中，为可选新加信元。

5.如权利要求1所述的一种用于用户面和控制面分离架构的信令交互方法，其特征在于：每一个创建及更新用量上报规则内容必须包含唯一内容识别用户上报规则ID，所述锚定用量上报规则ID用于指示被引用的用量上报规则ID对应的创建及更新用量上报规则内容，对被引用创建及更新用量上报规则内容中需要改变的部分，依据每个创建及更新用量上报规则包含信元项目为标准定义结构，重用当前用量上报规则ID对应创建及更新用量上报规则的相应信元内容进行补充。

6.如权利要求3所述的一种用于用户面和控制面分离架构的信令交互方法，其特征在于：所述步骤3.2中，除锚定用量上报规则ID所在创建及更新用量上报规则携带完整内容外，其余创建及更新用量上报规则信元携不需要携带完整内容。

7.如权利要求3所述的一种用于用户面和控制面分离架构的信令交互方法，其特征在于：所述步骤3.2中，所述其余创建及更新用量上报规则信元通过原有信元携带对索引用量上报规则ID的创建及更新用量上报规则内容的改变项目。

8.一种用于用户面和控制面分离架构的信令交互装置，其特征在于：所述装置包括存储器和一个或多个处理器，所述存储器中存储有可执行代码，所述一个或多个处理器执行所述可执行代码时，用于实现权利要求1-7任一项所述用于用户面和控制面分离架构的信令交互方法。