用户面重路由方法及装置

摘要

本申请实施例提供一种用户面重路由方法及装置，该方法包括：第一网元接收第二网元发送的用户面重路由触发信息；其中，该用户面重路由触发信息为该第二网元监测到与报文检测规则PDR匹配的预设业务报文时发送的；该PDR用于指示触发用户面重路由的预设业务报文对应的匹配信息以及执行规则；进一步地，该第一网元根据该用户面重路由触发信息，执行用户面重路由。可见，本申请实施例可以实现运营商控制范围内的网元基于业务感知的用户面路径调整，无需第三方APP规划的功能实体触发用户面路径改变，从而提高了运营商网络的安全性。

权利要求

1.一种用户面重路由方法，其特征在于，包括：第一网元接收第二网元发送的用户面重路由触发信息；其中，所述用户面重路由触发信息为所述第二网元监测到与报文检测规则PDR匹配的预设业务报文时发送的；所述PDR用于指示触发用户面重路由的预设业务报文对应的匹配信息以及执行规则；

所述第一网元根据所述用户面重路由触发信息，执行用户面重路由。

2.根据权利要求1所述的方法，其特征在于，所述PDR中包括：报文检测信息PDI、使用量上报规则URR；其中，所述PDI用于指示所述预设业务报文对应的匹配信息，所述URR用于指示所述预设业务报文对应的执行规则。

3.根据权利要求1或2所述的方法，其特征在于，所述方法还包括：所述第一网元根据预置的用于触发用户面重路由的策略生成所述PDR，并将所述PDR发送给所述第二网元。

4.根据权利要求1或2所述的方法，其特征在于，所述方法还包括：所述第一网元从第三网元获取所述第三网元中预置的用于触发用户面重路由的策略；

所述第一网元根据所述策略生成所述PDR，并将所述PDR发送给所述第二网元。

5.根据权利要求1或2所述的方法，其特征在于，所述方法还包括：所述第一网元向所述第二网元发送激活消息，所述激活消息用于指示激活所述第二网元中预置的所述PDR。

6.根据权利要求3所述的方法，其特征在于，所述PDR携带于所述第一网元向所述第二网元发送的第一会话创建请求消息，所述第一会话创建请求消息用于指示创建所述第一网元与所述第二网元之间的会话。

7.根据权利要求4所述的方法，其特征在于，所述PDR携带于所述第一网元向所述第二网元发送的第一会话创建请求消息，所述第一会话创建请求消息用于指示创建所述第一网元与所述第二网元之间的会话。

8.根据权利要求5所述的方法，其特征在于，所述激活消息携带于所述第一网元向所述第二网元发送的第二会话创建请求消息，所述第二会话创建请求消息用于指示创建所述第一网元与所述第二网元之间的会话。

9.根据权利要求1‑2和6‑8中任一项所述的方法，其特征在于，所述第一网元根据所述用户面重路由触发信息，执行用户面重路由，包括：所述第一网元向第四网元发送第一会话请求消息，以及向第五网元发送第二会话请求消息；其中，所述第一会话请求消息用于指示创建或更新所述第一网元与所述第四网元之间的会话，所述第二会话请求消息用于指示创建或更新所述第一网元与所述第五网元之间的会话，所述第二会话请求消息中携带为所述第五网元分配的业务报文分流规则；和/或，所述第一网元向所述第二网元发送会话更新请求消息，所述会话更新请求消息用于指示更新所述第二网元中的PDR。

10.根据权利要求1‑2和6‑8中任一项所述的方法，其特征在于，所述第一网元根据所述用户面重路由触发信息，执行用户面重路由，包括：所述第一网元创建与第四网元之间的会话；

所述第一网元删除与所述第二网元之间的会话。

11.根据权利要求10所述的方法，其特征在于，所述第一网元创建与第四网元之间的会话，包括：

所述第一网元向所述第四网元发送第三会话创建请求消息，所述第三会话创建请求消息用于指示创建所述第一网元与所述第四网元之间的会话。

12.根据权利要求11所述的方法，其特征在于，所述第一网元删除与所述第二网元之间的会话，包括：

所述第一网元向所述第二网元发送会话删除请求消息，所述会话删除请求消息用于指示删除所述第一网元与所述第二网元之间的会话。

13.根据权利要求4所述的方法，其特征在于，所述第一网元根据所述用户面重路由触发信息，执行用户面重路由之前，所述方法还包括：所述第一网元将所述用户面重路由触发信息发送给所述第三网元；

所述第一网元接收所述第三网元发送的指示信息，其中，所述指示信息用于指示所述第一网元执行用户面重路由。

14.一种用户面重路由方法，其特征在于，包括：第一网元根据报文检测规则PDR对业务报文进行监测；其中，所述PDR用于指示触发用户面重路由的预设业务报文对应的匹配信息以及执行规则；

若所述第一网元监测到与所述PDR匹配的预设业务报文时，所述第一网元根据所述执行规则向第二网元发送用户面重路由触发信息。

15.根据权利要求14所述的方法，其特征在于，所述PDR中包括：报文检测信息PDI、使用量上报规则URR；其中，所述PDI用于指示所述预设业务报文对应的匹配信息，所述URR用于指示所述预设业务报文对应的执行规则。

16.根据权利要求15所述的方法，其特征在于，所述第一网元根据报文检测规则PDR对业务报文进行监测，包括：

所述第一网元确定所述业务报文的属性信息；

所述第一网元将所述属性信息与所述PDI进行匹配；

若所述属性信息与所述PDI匹配，则所述第一网元监测到所述业务报文是与所述PDR匹配的预设业务报文；和/或，

若所述属性信息与所述PDI不匹配，则所述第一网元监测到所述业务报文不是与所述PDR匹配的预设业务报文。

17.根据权利要求14‑16中任一项所述的方法，其特征在于，所述方法还包括：所述第一网元接收所述第二网元发送的所述PDR，其中，所述PDR为所述第二网元根据预置的用于触发用户面重路由的策略生成的，或者所述PDR为所述第二网元在从第三网元获取到用于触发用户面重路由的策略后所生成的。

18.根据权利要求14‑16中任一项所述的方法，其特征在于，所述方法还包括：所述第一网元接收所述第二网元发送的激活消息，所述激活消息用于指示激活所述第一网元中预置的所述PDR。

19.根据权利要求17所述的方法，其特征在于，所述PDR携带于所述第一网元接收到的所述第二网元发送的第一会话创建请求消息，所述第一会话创建请求消息用于指示创建所述第二网元与所述第一网元之间的会话。

20.根据权利要求18所述的方法，其特征在于，所述激活消息携带于所述第一网元接收到的所述第二网元发送的第二会话创建请求消息，所述第二会话创建请求消息用于指示创建所述第二网元与所述第一网元之间的会话。

21.根据权利要求14‑16和19‑20中任一项所述的方法，其特征在于，所述方法还包括：所述第一网元接收所述第二网元发送的会话更新请求消息，所述会话更新请求消息用于指示更新所述第一网元中的所述PDR。

22.根据权利要求14‑16和19‑20中任一项所述的方法，其特征在于，所述方法还包括：所述第一网元接收所述第二网元发送的会话删除请求消息，所述会话删除请求消息用于指示删除所述第二网元与所述第一网元之间的会话。

23.一种网元，其特征在于，所述网元为第一网元，所述第一网元包括：第一接收模块，用于接收第二网元发送的用户面重路由触发信息；其中，所述用户面重路由触发信息为所述第二网元监测到与报文检测规则PDR匹配的预设业务报文时发送的；

所述PDR用于指示触发用户面重路由的预设业务报文对应的匹配信息以及执行规则；

重路由模块，用于根据所述用户面重路由触发信息，执行用户面重路由。

24.根据权利要求23所述的第一网元，其特征在于，所述PDR中包括：报文检测信息PDI、使用量上报规则URR；其中，所述PDI用于指示所述预设业务报文对应的匹配信息，所述URR用于指示所述预设业务报文对应的执行规则。

25.根据权利要求23或24所述的第一网元，其特征在于，所述第一网元还包括：第一生成模块，用于根据预置的用于触发用户面重路由的策略生成所述PDR；

第一发送模块，用于将所述PDR发送给所述第二网元。

26.根据权利要求23或24所述的第一网元，其特征在于，所述第一网元还包括：获取模块，用于从第三网元获取所述第三网元中预置的用于触发用户面重路由的策略；

第二生成模块，用于根据所述策略生成所述PDR；

第二发送模块，用于将所述PDR发送给所述第二网元。

27.根据权利要求23或24所述的第一网元，其特征在于，所述第一网元还包括：第三发送模块，用于向所述第二网元发送激活消息，所述激活消息用于指示激活所述第二网元中预置的所述PDR。

28.一种网元，其特征在于，所述网元为第一网元，所述第一网元包括：监测模块，用于根据报文检测规则PDR对业务报文进行监测；其中，所述PDR用于指示触发用户面重路由的预设业务报文对应的匹配信息以及执行规则；

发送模块，用于若所述监测模块监测到与所述PDR匹配的预设业务报文时，根据所述执行规则向第二网元发送用户面重路由触发信息。

29.根据权利要求28所述的第一网元，其特征在于，所述PDR中包括：报文检测信息PDI、使用量上报规则URR；其中，所述PDI用于指示所述预设业务报文对应的匹配信息，所述URR用于指示所述预设业务报文对应的执行规则。

30.一种网元，其特征在于，包括：处理器和存储器；

其中，所述存储器，用于存储程序指令；

所述处理器，用于调用并执行所述存储器中存储的程序指令，当所述处理器执行所述存储器存储的程序指令时，所述网元用于执行如权利要求1至22中任一项所述的方法。

31.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有指令，当所述指令在计算机上运行时，使得计算机执行如权利要求1至22中任一项所述的方法。

说明书

用户面重路由方法及装置

技术领域

[0001] 本申请涉及网络技术领域，尤其涉及一种用户面重路由方法及装置。

背景技术

[0002] 第五代移动通信5G(5th‑generation，5G)网络架构中，5G核心网控制面与5G核心网用户面之间通过相应的接口进行消息交互，以实现控制面到用户面的用户策略下发以及
用户面到控制面的事件上报等处理。在实际运用过程中，可能需要更改用户面路径。

[0003] 相关技术中，由应用功能实体(Application Function，AF)发起用户面路径改变请求，通过网络能力开放功能实体(Network Exposure Function，NEF)和统一数据缓存功
能实体(Unified Data Repository，UDR)来触发策略控制功能实体(Policy Control 
Function，PCF)通知会话管理功能实体(Session Management Function，SMF)重配置用户
面功能实体(User Plane Function，UPF)的用户面路径。

[0004] 但相关技术中，通过AF‑>NEF‑>UDR‑>PCF‑>SMF的业务触发路径实现的，其中涉及的服务较多，且AF属于第三方应用程序(Application，APP)规划的功能实体，不在运营商控
制范围内。为了实现合理的路径规划，运营商需要通过NEF将运营商网络内部的业务规划开
放给第三方APP，导致存在安全方面的问题。

发明内容

[0005] 本申请实施例提供一种用户面重路由方法及装置，提高了运营商网络的安全性。

[0006] 第一方面，本申请实施例提供一种用户面重路由方法，包括：

[0007] 第一网元接收第二网元发送的用户面重路由触发信息；其中，该用户面重路由触发信息为该第二网元监测到与报文检测规则PDR匹配的预设业务报文时发送的；该PDR用于
指示触发用户面重路由的预设业务报文对应的匹配信息以及执行规则；

[0008] 该第一网元根据该用户面重路由触发信息，执行用户面重路由。

[0009] 第一方面提供的用户面重路由触发信息方法中，通过第一网元接收第二网元发送的用户面重路由触发信息；其中，该用户面重路由触发信息为该第二网元监测到与报文检
测规则PDR匹配的预设业务报文时发送的；该PDR用于指示触发用户面重路由的预设业务报
文对应的匹配信息以及执行规则；进一步地，该第一网元根据该用户面重路由触发信息，执
行用户面重路由。可见，相对于相关技术中通过非运营商的第三方APP规划的功能实体触发
用户面路径改变的方式，本申请实施例可以实现运营商控制范围内的网元基于业务感知的
用户面路径调整，无需第三方APP规划的功能实体触发用户面路径改变，从而提高了运营商
网络的安全性。

[0010] 在一种可能的实现方式中，该PDR中包括：报文检测信息PDI、使用量上报规则URR；其中，该PDI用于指示该预设业务报文对应的匹配信息，该URR用于指示该预设业务报文对
应的执行规则。

[0011] 在一种可能的实现方式中，该方法还包括：

[0012] 该第一网元根据预置的用于触发用户面重路由的策略生成该PDR，并将该PDR发送给该第二网元。

[0013] 在一种可能的实现方式中，该方法还包括：

[0014] 该第一网元从第三网元获取该第三网元中预置的用于触发用户面重路由的策略；

[0015] 该第一网元根据该策略生成该PDR，并将该PDR发送给该第二网元。

[0016] 在一种可能的实现方式中，该方法还包括：

[0017] 该第一网元向该第二网元发送激活消息，该激活消息用于指示激活该第二网元中预置的该PDR。

[0018] 在一种可能的实现方式中，该PDR携带于该第一网元向该第二网元发送的第一会话创建请求消息，该第一会话创建请求消息用于指示创建该第一网元与该第二网元之间的
会话。

[0019] 在一种可能的实现方式中，该激活消息携带于该第一网元向该第二网元发送的第二会话创建请求消息，该第二会话创建请求消息用于指示创建该第一网元与该第二网元之
间的会话。

[0020] 在一种可能的实现方式中，该第一网元根据该用户面重路由触发信息，执行用户面重路由，包括：

[0021] 该第一网元向第四网元发送第一会话请求消息，以及向第五网元发送第二会话请求消息；其中，该第一会话请求消息用于指示创建或更新该第一网元与该第四网元之间的
会话，该第二会话请求消息用于指示创建或更新该第一网元与该第五网元之间的会话，该
第二会话请求消息中携带为该第五网元分配的业务报文分流规则；和/或，

[0022] 该第一网元向该第二网元发送会话更新请求消息，该会话更新请求消息用于指示更新该第二网元中的PDR。

[0023] 在一种可能的实现方式中，该第一网元根据该用户面重路由触发信息，执行用户面重路由，包括：

[0024] 该第一网元创建与第四网元之间的会话；

[0025] 该第一网元删除与该第二网元之间的会话。

[0026] 在一种可能的实现方式中，该第一网元创建与第四网元之间的会话，包括：

[0027] 该第一网元向该第四网元发送第三会话创建请求消息，该第三会话创建请求消息用于指示创建该第一网元与该第四网元之间的会话。

[0028] 在一种可能的实现方式中，该第一网元删除与该第二网元之间的会话，包括：

[0029] 该第一网元向该第二网元发送会话删除请求消息，该会话删除请求消息用于指示删除该第一网元与该第二网元之间的会话。

[0030] 在一种可能的实现方式中，该第一网元根据该用户面重路由触发信息，执行用户面重路由之前，该方法还包括：

[0031] 该第一网元将该用户面重路由触发信息发送给该第三网元；

[0032] 该第一网元接收该第三网元发送的指示信息，其中，该指示信息用于指示该第一网元执行用户面重路由。

[0033] 第二方面，本申请实施例提供一种用户面重路由方法，包括：

[0034] 第一网元根据报文检测规则PDR对业务报文进行监测；其中，该PDR用于指示触发用户面重路由的预设业务报文对应的匹配信息以及执行规则；

[0035] 若该第一网元监测到与该PDR匹配的预设业务报文时，该第一网元根据该执行规则向第二网元发送用户面重路由触发信息。

[0036] 第二方面提供的用户面重路由触发信息方法中，通过第一网元根据报文检测规则PDR对业务报文进行监测；若该第一网元监测到与该PDR匹配的预设业务报文时，该第一网
元根据该执行规则向第二网元发送用户面重路由触发信息，以使第二网元根据用户面重路
由触发信息执行用户面重路由。可见，相对于相关技术中通过非运营商的第三方APP规划的
功能实体触发用户面路径改变的方式，本申请实施例可以实现运营商控制范围内的网元基
于业务感知的用户面路径调整，无需第三方APP规划的功能实体触发用户面路径改变，从而
提高了运营商网络的安全性。

[0037] 在一种可能的实现方式中，该PDR中包括：报文检测信息PDI、使用量上报规则URR；其中，该PDI用于指示该预设业务报文对应的匹配信息，该URR用于指示该预设业务报文对
应的执行规则。

[0038] 在一种可能的实现方式中，该第一网元根据报文检测规则PDR对业务报文进行监测，包括：

[0039] 该第一网元确定该业务报文的属性信息；

[0040] 该第一网元将该属性信息与该PDI进行匹配；

[0041] 若该属性信息与该PDI匹配，则该第一网元监测到该业务报文是与该PDR匹配的预设业务报文；和/或，

[0042] 若该属性信息与该PDI不匹配，则该第一网元监测到该业务报文不是与该PDR匹配的预设业务报文。

[0043] 在一种可能的实现方式中，该方法还包括：

[0044] 该第一网元接收该第二网元发送的该PDR，其中，该PDR为该第二网元根据预置的用于触发用户面重路由的策略生成的，或者该PDR为该第二网元在从第三网元获取到用于
触发用户面重路由的策略后所生成的。

[0045] 在一种可能的实现方式中，该方法还包括：

[0046] 该第一网元接收该第二网元发送的激活消息，该激活消息用于指示激活该第一网元中预置的该PDR。

[0047] 在一种可能的实现方式中，该PDR携带于该第一网元接收到的该第二网元发送的第一会话创建请求消息，该第一会话创建请求消息用于指示创建该第二网元与该第一网元
之间的会话。

[0048] 在一种可能的实现方式中，该激活消息携带于该第一网元接收到的该第二网元发送的第二会话创建请求消息，该第二会话创建请求消息用于指示创建该第二网元与该第一
网元之间的会话。

[0049] 在一种可能的实现方式中，该方法还包括：

[0050] 该第一网元接收该第二网元发送的会话更新请求消息，该会话更新请求消息用于指示更新该第一网元中的该PDR。

[0051] 在一种可能的实现方式中，该方法还包括：

[0052] 该第一网元接收该第二网元发送的会话删除请求消息，该会话删除请求消息用于指示删除该第二网元与该第一网元之间的会话。

[0053] 第三方面，本申请实施例提供一种网元，该网元为第一网元，该第一网元包括：

[0054] 第一接收模块，用于接收第二网元发送的用户面重路由触发信息；其中，该用户面重路由触发信息为该第二网元监测到与报文检测规则PDR匹配的预设业务报文时发送的；
该PDR用于指示触发用户面重路由的预设业务报文对应的匹配信息以及执行规则；

[0055] 重路由模块，用于根据该用户面重路由触发信息，执行用户面重路由。

[0056] 在一种可能的实现方式中，该PDR中包括：报文检测信息PDI、使用量上报规则URR；其中，该PDI用于指示该预设业务报文对应的匹配信息，该URR用于指示该预设业务报文对
应的执行规则。

[0057] 在一种可能的实现方式中，该第一网元还包括：

[0058] 第一生成模块，用于根据预置的用于触发用户面重路由的策略生成该PDR；

[0059] 第一发送模块，用于将该PDR发送给该第二网元。

[0060] 在一种可能的实现方式中，该第一网元还包括：

[0061] 获取模块，用于从第三网元获取该第三网元中预置的用于触发用户面重路由的策略；

[0062] 第二生成模块，用于根据该策略生成该PDR；

[0063] 第二发送模块，用于将该PDR发送给该第二网元。

[0064] 在一种可能的实现方式中，该第一网元还包括：

[0065] 第三发送模块，用于向该第二网元发送激活消息，该激活消息用于指示激活该第二网元中预置的该PDR。

[0066] 在一种可能的实现方式中，该PDR携带于该第一网元向该第二网元发送的第一会话创建请求消息，该第一会话创建请求消息用于指示创建该第一网元与该第二网元之间的
会话。

[0067] 在一种可能的实现方式中，该激活消息携带于该第一网元向该第二网元发送的第二会话创建请求消息，该第二会话创建请求消息用于指示创建该第一网元与该第二网元之
间的会话。

[0068] 在一种可能的实现方式中，该重路由模块具体用于：

[0069] 向第四网元发送第一会话请求消息，以及向第五网元发送第二会话请求消息；其中，该第一会话请求消息用于指示创建或更新该第一网元与该第四网元之间的会话，该第
二会话请求消息用于指示创建或更新该第一网元与该第五网元之间的会话，该第二会话请
求消息中携带为该第五网元分配的业务报文分流规则；和/或，

[0070] 向该第二网元发送会话更新请求消息，该会话更新请求消息用于指示更新该第二网元中的PDR。

[0071] 在一种可能的实现方式中，该重路由模块包括：

[0072] 创建单元，用于创建与第四网元之间的会话；

[0073] 删除单元，用于删除与该第二网元之间的会话。

[0074] 在一种可能的实现方式中，该创建单元具体用于：

[0075] 向该第四网元发送第三会话创建请求消息，该第三会话创建请求消息用于指示创建该第一网元与该第四网元之间的会话。

[0076] 在一种可能的实现方式中，该删除单元具体用于：

[0077] 向该第二网元发送会话删除请求消息，该会话删除请求消息用于指示删除该第一网元与该第二网元之间的会话。

[0078] 在一种可能的实现方式中，该第一网元还包括：

[0079] 第四发送模块，用于将该用户面重路由触发信息发送给该第三网元；

[0080] 第二接收模块，用于接收该第三网元发送的指示信息，其中，该指示信息用于指示该第一网元执行用户面重路由。

[0081] 第四方面，本申请实施例提供一种网元，该网元为第一网元，该第一网元包括：

[0082] 监测模块，用于根据报文检测规则PDR对业务报文进行监测；其中，该PDR用于指示触发用户面重路由的预设业务报文对应的匹配信息以及执行规则；

[0083] 发送模块，用于若该监测模块监测到与该PDR匹配的预设业务报文时，根据该执行规则向第二网元发送用户面重路由触发信息。

[0084] 在一种可能的实现方式中，该PDR中包括：报文检测信息PDI、使用量上报规则URR；其中，该PDI用于指示该预设业务报文对应的匹配信息，该URR用于指示该预设业务报文对
应的执行规则。

[0085] 在一种可能的实现方式中，该监测模块具体用于：

[0086] 确定该业务报文的属性信息；

[0087] 将该属性信息与该PDI进行匹配；

[0088] 若该属性信息与该PDI匹配，则监测到该业务报文是与该PDR匹配的预设业务报文；和/或，

[0089] 若该属性信息与该PDI不匹配，则监测到该业务报文不是与该PDR匹配的预设业务报文。

[0090] 在一种可能的实现方式中，该第一网元还包括：

[0091] 第一接收模块，用于接收该第二网元发送的该PDR，其中，该PDR为该第二网元根据预置的用于触发用户面重路由的策略生成的，或者该PDR为该第二网元在从第三网元获取
到用于触发用户面重路由的策略后所生成的。

[0092] 在一种可能的实现方式中，该第一网元还包括：

[0093] 第二接收模块，用于接收该第二网元发送的激活消息，该激活消息用于指示激活该第一网元中预置的该PDR。

[0094] 在一种可能的实现方式中，该PDR携带于该第一网元接收到的该第二网元发送的第一会话创建请求消息，该第一会话创建请求消息用于指示创建该第二网元与该第一网元
之间的会话。

[0095] 在一种可能的实现方式中，该激活消息携带于该第一网元接收到的该第二网元发送的第二会话创建请求消息，该第二会话创建请求消息用于指示创建该第二网元与该第一
网元之间的会话。

[0096] 在一种可能的实现方式中，该第一网元还包括：

[0097] 第三接收模块，用于接收该第二网元发送的会话更新请求消息，该会话更新请求消息用于指示更新该第一网元中的该PDR。

[0098] 在一种可能的实现方式中，该第一网元还包括：

[0099] 第四接收模块，用于接收该第二网元发送的会话删除请求消息，该会话删除请求消息用于指示删除该第二网元与该第一网元之间的会话。

[0100] 第五方面，本申请实施例提供一种网元，其特征在于，包括：处理器和存储器；

[0101] 其中，该存储器，用于存储程序指令；

[0102] 该处理器，用于调用并执行该存储器中存储的程序指令，当该处理器执行该存储器存储的程序指令时，该网元用于执行上述第一方面或第二方面的任一实现方式所述的方
法。

[0103] 第六方面，本申请实施例提供一种计算机可读存储介质，该计算机可读存储介质中存储有指令，当该指令在计算机上运行时，使得计算机执行上述第一方面或第二方面的
任一实现方式所述的方法。

[0104] 第七方面，本申请实施例提供一种芯片系统，该芯片系统包括处理器，还可以包括存储器，用于实现上述第一方面或第二方面的任一实现方式所述的方法。该芯片系统可以
由芯片构成，也可以包含芯片和其他分立器件。

[0105] 第八方面，本申请实施例提供一种程序，该程序在被处理器执行时用于执行上述第一方面或第二方面的任一实现方式所述的方法。

[0106] 第九方面，本申请实施例提供一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述第一方面或第二方面的任一实现方式所述的方法。

附图说明

[0107] 图1为本申请实施例提供的5G网络架构的示意图一；

[0108] 图2为本申请实施例提供的5G网络架构的示意图二；

[0109] 图3为相关技术提供的上行报文分流的用户面架构示意图；

[0110] 图4为相关技术提供的多宿主PDU会话的用户面架构示意图；

[0111] 图5为相关技术提供的由AF触发用户面重路由的流程示意图；

[0112] 图6为本申请一实施例提供的用户面重路由方法的流程示意图；

[0113] 图7为本申请另一实施例提供的用户面重路由方法的流程示意图；

[0114] 图8为本申请另一实施例提供的用户面重路由方法的流程示意图；

[0115] 图9为本申请另一实施例提供的用户面重路由方法的流程示意图；

[0116] 图10为本申请一实施例提供的网元的结构示意图；

[0117] 图11为本申请另一实施例提供的网元的结构示意图；

[0118] 图12为本申请另一实施例提供的网元的结构示意图。

具体实施方式

[0119] 首先，对本申请实施例所涉及的网络架构和部分词汇进行解释说明。

[0120] 图1为本申请实施例提供的5G网络架构的示意图一。如图1所示，5G网络架构中的控制面网元对外提供服务化接口，5G核心网控制面与5G核心网用户面之间通过相应的服务
化接口进行消息交互，以实现控制面到用户面的用户策略下发以及用户面到控制面的事件
上报等处理。

[0121] 例如，网络切片选择功能实体(Network Slice Selection Function，NSSF)对外提供服务化接口Nnssf、NEF对外提供服务化接口Nnef、网络存储功能实体(Network 
Repository Function，NRF)对外提供服务化接口Nnrf、PCF对外提供服务化接口Npcf、统一
数据管理(Unified Data Management，UDM)对外提供服务化接口Nudm、AF对外提供服务化
接口Naf、认证服务功能实体(Authentication Server Function，AUSF)对外提供服务化接
口Nausf、接入和移动性管理功能实体(Access and Mobility Management Function，AMF)
对外提供服务化接口Namf、SMF对外提供服务化接口Nsmf。另外，终端与AMF之间通过N1接口
连接，AMF与接入网(Access Network，AN)之间通过N2接口连接，AN与UPF之间通过N3接口连
接，UPF与SMF之间通过N4接口连接，UPF与数据网络(Data Network，DN)之间通过N6接口连
接。

[0122] 图2为本申请实施例提供的5G网络架构的示意图二。如图2所示，5G网络架构中需要互联的两个网元之间具有一对一定义的网元间接口，5G核心网控制面与5G核心网用户面
之间通过相应的网元间接口进行消息交互，以实现控制面到用户面的用户策略下发以及用
户面到控制面板的事件上报等处理。

[0123] 例如，N1为终端与AMF之间的网元间接口、N2为AN与AMF之间的网元间接口、N3为AN与UPF之间的网元间接口、N4为UPF与SMF之间的网元间接口、N5为PCF与AF之间的网元间接
口、N6为UPF与DN之间的网元间接口、N7为SMF与PCF之间的网元间接口、N8为AMF与UDM之间
的网元间接口、N9为UPF之间的网元间接口、N10为UDM与SMF之间的网元间接口、N11为AMF与
SMF之间的网元间接口、N12为AMF与AUSF之间的网元间接口、N13为AUSF与UDM之间的网元间
接口、N14为AMF之间的网元间接口、N15为AMF与PCF之间的网元间接口、N22为NSSF与AMF之
间的网元间接口。

[0124] 相关技术中定义了一个协议数据单元(Protocol Data Unit，PDU)会话(Session)可以支持多个PDU会话锚点(PDU Session Anchor，PSA)的场景。图3为相关技术提供的上行
报文分流的用户面架构示意图，如图3所示，通过增加针对网际协议版本4(Internet 
Protocol version 4，IPv4)会话和非多宿主(Multi‑home)的互联网协议第6版(Internet 
Protocol Version6，IPv6)会话的上行报文分流(Uplink Classifier，ULCL)‑UPF来实现单
一会话多业务路径的分流处理，例如可以通过PSA‑UPF1和PSA‑UPF2进行分流处理。

[0125] 图4为相关技术提供的多宿主PDU会话的用户面架构示意图，如图4所示，通过增加针对Multi‑home的IPv6会话的分支节点(Branch Point，BP)‑UPF来实现单一会话多业务路
径的分流处理，例如，可以通过PSA‑UPF1和PSA‑UPF2进行分流处理。

[0126] 图5为相关技术提供的由AF触发用户面重路由的流程示意图。如图5所示，相关技术中的AF可以感知到访问其业务的终端以及终端的位置信息，由AF发起用户面路径改变请
求，通过NEF和UDR来触发PCF通知SMF重配置UPF的用户面路径。例如，AF创建AF请求，并向
NEF发送AF请求，以便NEF将AF请求保存到UDR中，其中，AF请求中可以包括但不限于：创建消
息、更新消息或删除消息；进一步地，由于PCF已经向UDR订阅了AF请求变更时的通知服务，
因此，UDR会向PCF发送通知消息，以便于PCF向SMF发送策略控制更新通知消息，以使SMF重
配置UPF的用户面路径，从而使得将用户面路径切换到与终端最近的服务器。

[0127] 但相关技术中，通过AF‑>NEF‑>UDR‑>PCF‑>SMF的业务触发路径实现的，其中涉及的服务较多，且AF属于第三方APP规划的功能实体，不在运营商控制范围内。为了实现合理
的路径规划，运营商需要通过NEF将运营商网络内部的业务规划开放给第三方APP，导致存
在安全方面的问题。

[0128] 本申请实施例提供的用户面重路由方法及装置，通过运营商控制范围内的第二网元根据PDR对业务报文进行监测，在监测到与PDR匹配的预设业务报文时向第一网元发送用
户面重路由触发信息，使得第一网元根据接收到的用户面重路由触发信息可以获知终端正
在访问会触发用户面重路由的预设业务报文，进而执行用户面重路由。可见，相对于相关技
术中通过非运营商的第三方APP规划的功能实体触发用户面路径改变的方式，本申请实施
例可以实现运营商控制范围内的网元基于业务感知的用户面路径调整，无需第三方APP规
划的功能实体触发用户面路径改变，从而提高了运营商网络的安全性。

[0129] 本申请中，“至少一个”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，
同时存在A和B，单独存在B的情况，其中A,B可以是单数或者复数。字符“/”一般表示前后关
联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指的这些项中的任意组
合，包括单项(个)或复数项(个)的任意组合。例如，a,b,或c中的至少一项(个)，可以表示：
a,b,c,a‑b,a‑c,b‑c,或a‑b‑c，其中a,b,c可以是单个，也可以是多个。

[0130] 下面以具体地实施例对本申请的技术方案进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。

[0131] 图6为本申请一实施例提供的用户面重路由方法的流程示意图。如图6所示，本申请实施例的方法可以包括：

[0132] 步骤S601、第二网元根据报文检测规则PDR对业务报文进行监测；其中，PDR用于指示触发用户面重路由的预设业务报文对应的匹配信息以及执行规则。

[0133] 示例性地，本申请实施例中涉及的第二网元可以是指终端的初始会话对应的源锚点PSA‑UPF1。

[0134] 本申请实施例中涉及的预设业务报文是指会触发用户面重路由的预设业务对应的报文。示例性地，预设业务可以包括但不限于：预设的服务器互联网协议(Internet 
Protocol，IP)地址段发生的访问业务，或者，预设应用或APP发生的访问业务。

[0135] 本申请实施例中涉及的PDR中可以包括但不限于：报文检测信息(Packet Detection Information，PDI)、使用量上报规则(Usage Reporting Rule，URR)；PDR中还可
以包括QoS执行规则(QoS Enforcement Rule，QER)和/或转发动作规则(Forwarding 
Action Rule，FAR)。

[0136] 示例性地，PDI用于指示预设业务报文对应的匹配信息，例如PDI可以包括但不限于：预设报文的全量隧道端点标识(Full Qualified Tunnel Endpoint Identifier，F‑
TEID)、源目的端口、源目的IP地址、IP协议类型、应用身份标识号(Identity document，
ID)。

[0137] 示例性地，URR、QoS执行规则和/或FAR均用于指示预设业务报文对应的执行规则。

[0138] 可选地，本步骤中第二网元在接收到任意业务报文时，首先确定业务报文的属性信息，例如，业务报文的属性信息可以包括但不限于：业务报文的F‑TEID、源目的端口、源目
的IP地址、IP协议类型、应用ID。其次，第二网元将属性信息与PDI进行对比匹配。若业务报
文的属性信息与PDI匹配，则第二网元监测到业务报文是与PDR匹配的预设业务报文；若业
务报文的属性信息与PDI不匹配，则第二网元监测到业务报文不是与PDR匹配的预设业务报
文。

[0139] 例如，假设PDI包括：预设报文的F‑TEID、源目的端口、源目的IP地址、IP协议类型，业务报文的属性信息包括：业务报文的F‑TEID、源目的端口、源目的IP地址、IP协议类型，若
业务报文的F‑TEID与预设报文的F‑TEID相同、业务报文的源目的端口与预设报文的源目的
端口相同、业务报文的源目的IP地址与预设报文的源目的IP地址相同，以及业务报文的IP
协议类型与预设报文的IP协议类型相同，则第二网元确定业务报文的属性信息与PDI匹配，
从而监测到业务报文是与PDR匹配的预设业务报文；否则(例如，业务报文的F‑TEID与预设
报文的F‑TEID、业务报文的源目的端口与预设报文的源目的端口、业务报文的源目的IP地
址与预设报文的源目的IP地址、业务报文的IP协议类型与预设报文的IP协议类型中的任意
不相同)，第二网元确定业务报文的属性信息与PDI不匹配，从而监测到业务报文不是与PDR
匹配的预设业务报文。

[0140] 本申请下述实施例对第二网元中的PDR的获取方式进行介绍。

[0141] 一种可能的实现方式，第一网元根据预置的用于触发用户面重路由的策略生成PDR，并将PDR发送给第二网元；对应地，第二网元接收第一网元发送的PDR。

[0142] 示例性地，本申请实施例中涉及的第一网元可以是SMF。

[0143] 本申请实施例中涉及的预置的用于触发用户面重路由的策略可以包括但不限于以下任一项：

[0144] 终端访问预设业务时需要选择一个特定的UPF作为分流UPF插入会话信息、选择另一个特定的UPF作为新的本地锚点建立新的会话信息，以及向分流UPF下发用于指示将业务
流(包括多个业务报文)分别通过源锚点和新的本地锚点进行分发的策略；

[0145] 终端访问预设业务时需要选择一个特定的UPF作为新的本地锚点建立新的会话信息，以及删除源锚点上的会话信息；

[0146] 若新的本地锚点的第一预设距离范围内部署了内容分发网络(Content Delivery Network，CDN)服务器，则可以将预设业务的业务流通过新的本地锚点进行分发，从而可以
直接访问CDN服务器以提高服务质量以及业务访问效率的策略；

[0147] 若车辆服务器部署在自动驾驶车辆的第二预设距离范围内的新的本地锚点所对应的DN网络内，则在自动驾驶车辆中的终端访问预设业务时，可以通过新的本地锚点进行
业务访问。

[0148] 本实现方式中，第一网元中预置有用于触发用户面重路由的策略，第一网元可以根据预置的策略生成PDR，然后将生成的PDR发送给第二网元。示例性地，PDR可以携带于第
一网元向第二网元发送的第一会话创建请求消息，第一会话创建请求消息用于指示创建第
一网元与第二网元之间的会话；当然，PDR还可以携带于第一网元向第二网元发送的其它消
息中(例如，会话更新请求消息等)。

[0149] 另一种可能的实现方式，第一网元从第三网元获取第三网元中预置的用于触发用户面重路由的策略；第一网元根据策略生成PDR，并将PDR发送给第二网元；对应地，第二网
元接收第一网元发送的PDR。

[0150] 示例性地，本申请实施例中涉及的第三网元可以是PCF。

[0151] 本实现方式中，第三网元中预置有用于触发用户面重路由的策略，第一网元可以从第三网元中获取第三网元中预置的策略，然后根据获取的策略生成PDR，并将生成的PDR
发送给第二网元。示例性地，PDR可以携带于第一网元向第二网元发送的第一会话创建请求
消息；当然，PDR还可以携带于第一网元向第二网元发送的其它消息中(例如，会话更新请求
消息等)。

[0152] 另一种可能的实现方式，第一网元向第二网元发送激活消息，激活消息用于指示激活第二网元中预置的PDR；对应地，第二网元接收第一网元发送的激活消息。

[0153] 本实现方式中，第二网元中预先设置有PDR，第一网元通过向第二网元发送激活消息，以激活第二网元中预置的PDR。示例性地，激活消息可以携带于第一网元向第二网元发
送的第二会话创建请求消息，第二会话创建请求消息用于指示创建第二网元与第一网元之
间的会话；当然，激活消息还可以携带于第一网元向第二网元发送的其它消息中(例如，会
话更新请求消息等)。

[0154] 步骤S602、若第二网元监测到与PDR匹配的预设业务报文时，第二网元根据执行规则向第一网元发送用户面重路由触发信息。

[0155] 本步骤中，若第二网元监测到与PDR匹配的预设业务报文时，第二网元根据PDR中的执行规则向第一网元发送用户面重路由触发信息，以使第一网元根据用户面重路由触发
信息可以获知终端正在访问会触发用户面重路由的预设业务报文，从而执行用户面重路
由。

[0156] 步骤S603、第一网元接收第二网元发送的用户面重路由触发信息。

[0157] 本步骤中，第一网元接收第二网元发送的用户面重路由触发信息，从而获知终端正在访问会触发用户面重路由的预设业务报文；其中，用户面重路由触发信息为第二网元
监测到与报文检测规则PDR匹配的预设业务报文时发送的。

[0158] 步骤S604、第一网元根据用户面重路由触发信息，执行用户面重路由。

[0159] 本步骤中，第一网元根据用户面重路由触发信息，执行用户面重路由的操作。具体的，执行用户面重路由的操作可以包括但不限于以下几种可实现方式。

[0160] 一种可能的实现方式，第一网元向第四网元发送第一会话请求消息，以及向第五网元发送第二会话请求消息；其中，第一会话请求消息用于指示创建或更新第一网元与第
四网元之间的会话，第二会话请求消息用于指示创建或更新第一网元与第五网元之间的会
话，第二会话请求消息中携带为第五网元分配的业务报文分流规则；和/或，

[0161] 第一网元向第二网元发送会话更新请求消息，会话更新请求消息用于指示更新第二网元中的PDR；对应地，第二网元接收第一网元发送的会话更新请求消息。

[0162] 示例性地，本申请实施例中涉及的第四网元可以是指终端的新建会话对应的新的本地锚点PSA‑UPF2。

[0163] 示例性地，针对IPv4会话和/或非Multi‑home的IPv6会话，本申请实施例中涉及的第五网元可以是指ULCL‑UPF；针对Multi‑home的IPv6会话，本申请实施例中涉及的第五网
元可以是指BP‑UPF。

[0164] 本实现方式中，第一网元可以向第四网元发送用于指示创建或更新第一网元与第四网元之间的会话的第一会话请求消息，以及向第五网元发送用于指示创建或更新第一网
元与第五网元之间的会话的第二会话请求消息；其中，第二会话请求消息中还可以携带为
第五网元分配的业务报文分流规则，以使第五网元根据业务报文分流规则对业务报文进行
分发。

[0165] 需要说明的是，若第一网元已创建了第一网元与第四网元之间的会话，则第一会话请求消息用于指示更新第一网元与第四网元之间的会话；若第一网元未创建第一网元与
第四网元之间的会话，则第一会话请求消息用于指示创建第一网元与第四网元之间的会
话。和/或，若第一网元已创建了第一网元与第五网元之间的会话，则第二会话请求消息用
于指示更新第一网元与第五网元之间的会话；若第一网元未创建第一网元与第五网元之间
的会话，则第二会话请求消息用于指示创建第一网元与第五网元之间的会话。

[0166] 本实现方式中，第一网元还可以向第二网元发送会话更新请求消息，对应地，第二网元接收第一网元发送的会话更新请求消息，其中，会话更新请求消息用于指示更新第二
网元中的PDR。

[0167] 示例性地，会话更新请求消息可以用于指示将原有PDR的FAR动作中携带的接口隧道信息更新为第二网元与第五网元之间的接口隧道信息(例如，接口地址和/或F‑TEID)。

[0168] 可选地，若第二网元中的PDR为第一网元在从第三网元获取到用于触发用户面重路由的策略后所生成的，并发送给第二网元的，则第一网元在根据用户面重路由触发信息，
执行用户面重路由之前，首先将用户面重路由触发信息发送给第三网元，以使第三网元根
据预置的用于触发用户面重路由的策略向第一网元发送用于指示第一网元执行用户面重
路由的指示信息，其次接收第三网元发送的指示信息。

[0169] 另一种可能的实现方式，第一网元创建与第四网元之间的会话，并删除与第二网元之间的会话。

[0170] 示例性地，第一网元可以通过向第四网元发送用于指示创建第一网元与第四网元之间的会话的第三会话创建请求消息，对应地，第四网元在接收到第一网元发送的第三会
话创建请求消息后，还可以向第一网元发送第三会话创建请求消息对应的会话创建响应消
息，以实现创建第一网元与第四网元之间的会话。

[0171] 示例性地，第一网元可以通过向第二网元发送用于指示删除第一网元与第二网元之间的会话的会话删除请求消息，对应地，第二网元在接收到第一网元发送的会话删除请
求消息后，还可以向第一网元发送会话删除请求消息对应的会话删除响应消息，以实现删
除第一网元与第二网元之间的会话。

[0172] 本申请实施例中，第二网元根据报文检测规则PDR对业务报文进行监测；若第二网元监测到与PDR匹配的预设业务报文时，第二网元根据执行规则向第一网元发送用户面重
路由触发信息；进一步地，第一网元根据接收到的用户面重路由触发信息执行用户面重路
由。相对于相关技术中通过非运营商的第三方APP规划的功能实体触发用户面路径改变的
方式，本申请实施例中通过运营商控制范围内的第二网元根据PDR对业务报文进行监测，在
监测到与PDR匹配的预设业务报文时向第一网元发送用户面重路由触发信息，使得第一网
元根据接收到的用户面重路由触发信息可以获知终端正在访问会触发用户面重路由的预
设业务报文，进而执行用户面重路由。可见，本申请实施例可以实现运营商控制范围内的网
元基于业务感知的用户面路径调整，无需第三方APP规划的功能实体触发用户面路径改变，
从而提高了运营商网络的安全性。

[0173] 图7为本申请另一实施例提供的用户面重路由方法的流程示意图。在上述实施例的基础上，本申请实施例中以PSA‑UPF1根据SMF下发的PDR监测业务报文，并在监测到与PDR
匹配的预设业务报文时向SMF发送用户面重路由触发信息，以使得SMF执行分流UPF和PSA‑
UPF2的会话新建以及业务报文分流规则下发等用户面重路由操作为例，对用户面重路由方
法进行介绍。

[0174] 本申请实施例中，SMF中预置有用于触发用户面重路由的策略，例如，终端访问预设业务时需要选择一个特定的UPF作为分流UPF插入会话信息、选择另一个特定的UPF作为
新的本地锚点PSA‑UPF2建立新的会话信息，以及向分流UPF下发用于指示将业务流(包括多
个业务报文)分别通过源锚点PSA‑UPF1和新的本地锚点PSA‑UPF2进行分发的策略等。

[0175] 本实施例中，SMF可以根据预置的策略生成对应的PDR，其中，PDR中可以包括但不限于：PDI和URR。

[0176] 示例性地，针对IPv4会话和/或非Multi‑home的IPv6会话，本申请实施例中涉及的分流UPF可以是指ULCL‑UPF；针对Multi‑home的IPv6会话，本申请实施例中涉及的分流UPF
可以是指BP‑UPF。

[0177] 如图7所示，本申请实施例的方法可以包括：

[0178] 步骤S701、终端向SMF发送会话建立请求消息。

[0179] 步骤S702、SMF向PSA‑UPF1发送会话创建请求消息1，其中，会话创建请求消息1用于指示创建SMF与PSA‑UPF1之间的会话。

[0180] 示例性地，会话创建请求消息1中携带有SMF根据预置的策略所生成的PDR，其中，PDR中可以包括但不限于：PDI和URR。

[0181] 表1为会话创建请求消息1中URR信息元素(Information Elements，IE)的结构示意表

[0182]

[0183] 如表1所示，URR信息元素中增加了上报的触发点(Reporting Triggers)，用于指示向控制面(Control Plane，CP)功能实体报告网络资源使用量的触发点。其中，上报的触
发点的具体格式可以如表2所示，当八位组(Octet)6的位(Bit)7‑RERT(重路由业务)设置为
1时，表示在检测到存在重路由业务流时发送报告请求。

[0184] 表2为上报的触发点的结构示意表

[0185]

[0186] Octet 5的编码可以如下：

[0187] 位1‑周期上报(Periodic Reporting，PERIO)：当设置为1时，表示请求定期报告；

[0188] 位2‑流量阈值(Volume Threshold，VOLTH)：当设置为1时，表示数据使用量达到使用量阈值时请求报告；

[0189] 位3‑时长阈值(Time Threshold，TIMTH)：当设置为1时，表示当时间使用达到时间阈值时请求报告；

[0190] 位4‑配额保持时长(Quota Holding Time，QUHTI)：当设置为1时，表示在超过配额保持时长的时间段内没有接收到数据包时请求报告；

[0191] 位5‑业务开始(Start of Traffic，START)：当设置为1时，表示在检测到业务数据流(Service Data Flow，SDF)或应用业务开始时请求报告；

[0192] 位6‑业务停止(Stop of Traffic，STOPT)：当设置为1时，表示在检测到SDF或应用业务停止时请求报告；

[0193] 位7‑丢弃下行业务的阈值(Dropped DL Traffic Threshold，DROTH)：当设置为1时，表示当丢弃的下行业务达到阈值时请求报告；

[0194] 位8‑关联的使用量上报事件(Linked Usage Reporting，LIUSA)：当设置为1时，表示关联的使用量上报请求，例如，当关联的使用量上报规则发起使用量上报时，需要同时触
发该使用量上报规则的使用量上报请求；

[0195] Octet 6的编码可以如下：

[0196] 位1‑流量配额(Volume Quota，VOLQU)：当设置为1时，表示在流量配额耗尽时请求报告；

[0197] 位2‑时长配额(Time Quota，TIMQU)：当设置为1时，表示在时长配额用尽时请求报告；

[0198] 位3‑信封关闭(Envelope Closure，ENVCL)：当设置为1时，表示满足信封关闭条件时请求报告；

[0199] 位4‑MAC地址上报(MAC Addresses Reporting，MACAR)：当设置为1时，指示MAC(以太网)地址用作UE发送的上行(Uplink，UL)数据帧的源地址时请求报告；

[0200] 位5‑事件阈值(Event Threshold，EVETH)：当设置为1时，表示达到事件阈值时请求报告；

[0201] 位6‑事件配额(Event Quota，EVEQU)：当设置为1时，表示在达到事件配额时请求报告；

[0202] 位7‑重路由业务(Rerouting of Traffic，RERT)：当设置为1时，表示在检测到存在重路由的SDF或应用业务时请求报告；

[0203] 位8：备用，供将来使用并设置为0。

[0204] 步骤S703、PSA‑UPF1向SMF发送会话创建响应消息1。

[0205] 步骤S704、SMF向终端发送会话建立响应消息。

[0206] 步骤S705、终端发起业务访问。

[0207] 步骤S706、PSA‑UPF1根据PDR对业务报文进行监测。

[0208] 示例性地，若PSA‑UPF1监测到与PDR中的PDI匹配的预设业务报文时，则执行步骤S707。

[0209] 步骤S707、PSA‑UPF1向SMF发送会话报告请求消息。

[0210] 示例性地，PSA‑UPF1在监测到与PDR中的PDI匹配的预设业务报文时，根据PDR中的URR(包含用于指示业务重路由的Reporting Triggers)向SMF发送会话报告请求消息，其
中，会话报告请求消息中携带用户面重路由触发信息。

[0211] 表3为会话报告请求消息中使用量上报(Usage Report)IE的结构示意表

[0212]

[0213] 如表3所示，使用量上报的触发原因(Usage Report Trigger)用于指示使用量上报的触发原因，本申请实施例中增加了重路由业务触发原因(Traffic Rerouting 
Trigger)，或者称之为用户面重路由触发信息。其中，使用量上报的触发原因的具体格式可
以如表4所示，当八位组7的位2‑RERT设置为1时，表示检测到存在重路由业务流(即重路由
业务触发原因，或者用户面重路由触发信息)。

[0214] 表4为使用量上报的触发原因的结构示意表

[0215]

[0216] Octet 5的编码可以如下：

[0217] 位1‑PERIO：当设置为1时，表示定期报告；

[0218] 位2‑VOLTH：设置为1时，表示数据使用量达到使用量阈值；

[0219] 位3‑TIMTH)：设置为1时，表示时间使用达到时间阈值；

[0220] 位4‑QUHTI：当设置为1时，表示在超过配额保持时长的时间段内没有收到任何数据包；

[0221] 位5‑START：当设置为1时，表示检测到业务开始；

[0222] 位6‑STOPT：当设置为1时，表示检测到业务停止；

[0223] 位7‑DROTH：当设置为1时，表示丢弃的下行业务达到阈值；

[0224] 位8‑立即上报(Immediate Report，IMMER)(指收到CP的消息后，立即触发的URR上报)：当设置为1时，表示基于CP功能实体的要求触发一个即时的使用量上报请求；

[0225] Octet 6的编码可以如下：

[0226] 位1‑VOLQU：设置为1时，表示流量配额已用尽；

[0227] 位2‑TIMQU：设置为1时，表示时长配额已用尽；

[0228] 位3‑LIUSA：当设置为1时，表示关联的使用量上报，例如，由于关联的使用量上报规则的使用量上报，因此，该使用量上报规则的使用量上报；

[0229] 位4‑终止报告(Termination Report，TERMR)：当设置为1时，表示由于PFCP会话终止而导致使用量上报(在PFCP会话删除响应中)，或者由于移除了URR而导致使用量上报(在
PFCP会话修改响应中)；

[0230] 位5‑监视时间(Monitoring Time，MONIT)：当设置为1时，表示由于达到监视时间而报告URR的使用量上报；

[0231] 位6‑ENVCL：当设置为1时，表示信封关闭时生成使用量上报；

[0232] 位7‑MACAR：当设置为1时，指示MAC(以太网)地址用作UE发送的UL数据帧的源地址的使用量上报；

[0233] 位8‑EVETH：当设置为1时，表示达到事件阈值时生成使用量上报；

[0234] Octet 7的编码可以如下：

[0235] 位1‑EVEQU：当设置为1时，表示事件配额已用尽；

[0236] 位2‑RERT：当设置为1时，表示在检测到存在重路由的SDF或应用业务；

[0237] 位3到8：备用，以备将来使用并设置为0。

[0238] 步骤S708、SMF向PSA‑UPF1发送会话报告响应消息。

[0239] 步骤S709、SMF根据会话报告请求消息中的用户面重路由触发信息，确定需要执行用户面重路由。

[0240] 示例性地，SMF根据会话报告请求消息中的用户面重路由触发信息确定需要执行分流UPF和PSA‑UPF2的会话新建以及业务报文分流规则下发的预设业务已经触发，从而需
要执行用户面重路由。

[0241] 步骤S710、SMF向PSA‑UPF2发送会话创建请求消息2，其中，会话创建请求消息2用于指示创建SMF与PSA‑UPF2之间的会话。

[0242] 步骤S711、PSA‑UPF2向SMF发送会话创建响应消息2。

[0243] 步骤S712、SMF向分流UPF发送会话创建请求消息3，其中，会话创建请求消息3用于指示创建SMF与分流UPF之间的会话。

[0244] 示例性地，会话创建请求消息3中携带有为分流UPF分配的业务报文分流规则，以使分流UPF根据业务报文分流规则将业务报文通过源锚点PSA‑UPF1和新的本地锚点PSA‑
UPF2进行分发。

[0245] 步骤S713、分流UPF向SMF发送会话创建响应消息3。

[0246] 步骤S714、SMF向PSA‑UPF1发送会话更新请求消息，会话更新请求消息用于指示更新PSA‑UPF1中的PDR。

[0247] 示例性地，会话更新请求消息用于指示将PSA‑UPF1原有PDR的FAR动作中携带的接口隧道信息更新为PSA‑UPF1与分流UPF之间的接口隧道信息(例如，接口地址和/或F‑
TEID)。

[0248] 步骤S715、PSA‑UPF1向SMF发送会话更新响应消息。

[0249] 步骤S716、分流UPF根据业务报文分流规则将终端发送的业务报文通过PSA‑UPF1和PSA‑UPF2转发到DN。

[0250] 示例性地，分流UPF根据业务报文分流规则可以将预设业务报文分流到PSA‑UPF2进行数据网络访问，其他业务报文仍然转发至PSA‑UPF1继续进行访问。

[0251] 本申请实施例中，PSA‑UPF1可以根据PDR对业务报文进行监测，在监测到与PDR匹配的预设业务报文时向SMF发送用户面重路由触发信息；SMF根据用户面重路由触发信息可
以获知需要执行分流UPF和PSA‑UPF2的会话新建以及业务报文分流规则下发的预设业务已
经触发，进而执行分流UPF和PSA‑UPF2的会话建立流程，以便于将特定业务流分流到相应的
锚点UPF进行数据网络访问。可见，本申请实施例可以实现基于业务感知的用户面路径调
整，无需第三方APP规划的功能实体感知和触发用户面重路由，从而提高了运营商网络的安
全性。

[0252] 图8为本申请另一实施例提供的用户面重路由方法的流程示意图。在上述实施例的基础上，本申请实施例以PSA‑UPF1根据SMF下发的PDR监测业务报文，并在监测到与PDR匹
配的预设业务报文时向SMF发送用户面重路由触发信息，以使得SMF执行PSA‑UPF2的会话新
建和PSA‑UPF1的会话删除等用户面重路由操作为例，对用户面重路由方法进行介绍。

[0253] 本申请实施例中，SMF中预置有用于触发用户面重路由的策略，例如，终端访问预设业务时需要选择一个特定的UPF作为新的本地锚点PSA‑UPF2建立新的会话信息，以及删
除源锚点PSA‑UPF1上的会话信息等。

[0254] 本实施例中，SMF可以根据预置的策略生成对应的PDR，其中，PDR中可以包括但不限于：PDI和URR。

[0255] 如图8所示，本申请实施例的方法可以包括：

[0256] 步骤S801、终端向SMF发送会话建立请求消息。

[0257] 步骤S802、SMF向PSA‑UPF1发送会话创建请求消息1，其中，会话创建请求消息1用于指示创建SMF与PSA‑UPF1之间的会话。

[0258] 示例性地，会话创建请求消息1中携带有SMF根据预置的策略所生成的PDR，其中，PDR中可以包括但不限于：PDI和URR。

[0259] 其中，会话创建请求消息1中URR信息元素的结构如表1和表2所示，此处不再赘述。

[0260] 步骤S803、PSA‑UPF1向SMF发送会话创建响应消息1。

[0261] 步骤S804、SMF向终端发送会话建立响应消息。

[0262] 步骤S805、终端发起业务访问。

[0263] 步骤S806、PSA‑UPF1根据PDR对业务报文进行监测。

[0264] 示例性地，若PSA‑UPF1监测到与PDR中的PDI匹配的预设业务报文时，则执行步骤S807。

[0265] 步骤S807、PSA‑UPF1向SMF发送会话报告请求消息。

[0266] 示例性地，PSA‑UPF1在监测到与PDR中的PDI匹配的预设业务报文时，根据PDR中的URR(包含用于指示业务重路由的Reporting Triggers)向SMF发送会话报告请求消息，其
中，会话报告请求消息中携带用户面重路由触发信息。

[0267] 其中，会话报告请求消息中使用量上报(Usage Report)IE的结构如表3和表4所示，此处不再赘述。

[0268] 步骤S808、SMF向PSA‑UPF1发送会话报告响应消息。

[0269] 步骤S809、SMF根据会话报告请求消息中的用户面重路由触发信息，确定需要执行用户面重路由。

[0270] 示例性地，SMF根据会话报告请求消息中的用户面重路由触发信息确定需要执行PSA‑UPF2的会话新建和PSA‑UPF1的会话删除的预设业务已经触发，从而需要执行用户面重
路由。

[0271] 步骤S810、SMF向PSA‑UPF2发送会话创建请求消息2，其中，会话创建请求消息2用于指示创建SMF与PSA‑UPF2之间的会话。

[0272] 步骤S811、PSA‑UPF2向SMF发送会话创建响应消息2。

[0273] 步骤S812、SMF向PSA‑UPF1发送会话删除请求消息，会话删除请求消息用于指示删除SMF与PSA‑UPF1之间的会话。

[0274] 步骤S813、PSA‑UPF1向SMF发送会话删除响应消息。

[0275] 步骤S814、PSA‑UPF2对终端发送的业务报文进行转发处理。

[0276] 本申请实施例中，PSA‑UPF1可以根据PDR对业务报文进行监测，在监测到与PDR匹配的预设业务报文时向SMF发送用户面重路由触发信息；SMF根据用户面重路由触发信息可
以获知需要执行PSA‑UPF2的会话新建和PSA‑UPF1的会话删除的预设业务已经触发，进而执
行PSA‑UPF2的会话建立和PSA‑UPF1的会话删除流程，使得终端发送的所有业务报文通过
PSA‑UPF2进行数据网络访问。可见，本申请实施例可以实现基于业务感知的用户面路径调
整，无需第三方APP规划的功能实体感知和触发用户面重路由，从而提高了运营商网络的安
全性。

[0277] 图9为本申请另一实施例提供的用户面重路由方法的流程示意图。在上述实施例的基础上，本申请实施例以PSA‑UPF1根据SMF下发的PDR监测业务报文(为SMF从PCF获取到
用于触发用户面重路由的策略后所生成的)，并在监测到与PDR匹配的预设业务报文时向
SMF发送用户面重路由触发信息，以使得SMF将用户面重路由触发信息上报给PCF，并在接收
到PCF发送的用于指示SMF执行用户面重路由的指示信息后，执行分流UPF和PSA‑UPF2的会
话新建以及业务报文分流规则下发等用户面重路由操作为例，对用户面重路由方法进行介
绍。

[0278] 本申请实施例中，PCF中预置有用于触发用户面重路由的策略，例如，终端访问预设业务时需要选择一个特定的UPF作为分流UPF插入会话信息、选择另一个特定的UPF作为
新的本地锚点PSA‑UPF2建立新的会话信息，以及向分流UPF下发用于指示将业务流(包括多
个业务报文)分别通过源锚点PSA‑UPF1和新的本地锚点PSA‑UPF2进行分发的策略等。

[0279] 示例性地，针对IPv4会话和/或非Multi‑home的IPv6会话，本申请实施例中涉及的分流UPF可以是指ULCL‑UPF；针对Multi‑home的IPv6会话，本申请实施例中涉及的分流UPF
可以是指BP‑UPF。

[0280] 如图9所示，本申请实施例的方法可以包括：

[0281] 步骤S901、终端向SMF发送会话建立请求消息。

[0282] 步骤S902、SMF向PCF发送策略控制创建请求消息，其中，策略控制创建请求消息用于指示获取用于触发用户面重路由的策略。

[0283] 步骤S903、PCF向SMF发送策略控制创建响应消息，其中，策略控制创建响应消息中携带用于触发用户面重路由的策略；当然，策略控制创建响应消息中还可以携带计费与控
制策略等其它策略。

[0284] 示例性地，策略控制创建响应消息中可以包括策略控制请求触发原因(Policy Control Request Triggers)指示信息。如表5所示，策略控制请求触发原因指示信息中可
以包括但不限于重路由策略(或者称之为用于触发用户面重路由的策略)，用于指示当SMF
监测到终端访问了需要执行用户面重路由的预设业务时上报策略控制更新请求。

[0285] 表5为策略控制请求触发原因指示信息的示意表

[0286]

[0287] 步骤S904、SMF根据从PCF获取的用于触发用户面重路由的策略生成对应的PDR，其中，PDR中可以包括但不限于：PDI和URR。

[0288] 步骤S905、SMF向PSA‑UPF1发送会话创建请求消息1，其中，会话创建请求消息1用于指示创建SMF与PSA‑UPF1之间的会话。

[0289] 示例性地，会话创建请求消息1中携带有PDR，其中，PDR中可以包括但不限于：PDI和URR。

[0290] 其中，会话创建请求消息1中URR信息元素的结构如表1和表2所示，此处不再赘述。

[0291] 步骤S906、PSA‑UPF1向SMF发送会话创建响应消息1。

[0292] 步骤S907、SMF向终端发送会话建立响应消息。

[0293] 步骤S908、终端发起业务访问。

[0294] 步骤S909、PSA‑UPF1根据PDR对业务报文进行监测。

[0295] 示例性地，若PSA‑UPF1监测到与PDR中的PDI匹配的预设业务报文时，则执行步骤S910。

[0296] 步骤S910、PSA‑UPF1向SMF发送会话报告请求消息。

[0297] 示例性地，PSA‑UPF1在监测到与PDR中的PDI匹配的预设业务报文时，根据PDR中的URR(包含用于指示业务重路由的Reporting Triggers)向SMF发送会话报告请求消息，其
中，会话报告请求消息中携带用户面重路由触发信息。

[0298] 其中，会话报告请求消息中使用量上报(Usage Report)IE的结构如表3和表4所示，此处不再赘述。

[0299] 步骤S911、SMF向PSA‑UPF1发送会话报告响应消息。

[0300] 步骤S912、SMF向PCF发送策略控制更新请求消息。

[0301] 示例性地，SMF根据会话报告请求消息中的用户面重路由触发信息确定需要执行分流UPF和PSA‑UPF2的会话新建以及业务报文分流规则下发的预设业务已经触发，从而向
PCF发送策略控制更新请求消息，其中，策略控制更新请求消息中可以携带用户面重路由触
发信息。

[0302] 步骤S913、PCF向SMF发送策略控制更新响应消息，其中，策略控制更新响应消息中可以携带用于指示SMF执行用户面重路由的指示信息。

[0303] 步骤S914、SMF根据收到的用于指示SMF执行用户面重路由的指示信息，确定执行用户面重路由。

[0304] 步骤S915、SMF向PSA‑UPF2发送会话创建请求消息2，其中，会话创建请求消息2用于指示创建SMF与PSA‑UPF2之间的会话。

[0305] 步骤S916、PSA‑UPF2向SMF发送会话创建响应消息2。

[0306] 步骤S917、SMF向分流UPF发送会话创建请求消息3，其中，会话创建请求消息3用于指示创建SMF与分流UPF之间的会话。

[0307] 示例性地，会话创建请求消息3中携带有为分流UPF分配的业务报文分流规则，以使分流UPF根据业务报文分流规则将业务报文通过源锚点PSA‑UPF1和新的本地锚点PSA‑
UPF2进行分发。

[0308] 步骤S918、分流UPF向SMF发送会话创建响应消息3。

[0309] 步骤S919、SMF向PSA‑UPF1发送会话更新请求消息，会话更新请求消息用于指示更新PSA‑UPF1中的PDR。

[0310] 示例性地，会话更新请求消息用于指示将PSA‑UPF1原有PDR的FAR动作中携带的接口隧道信息更新为PSA‑UPF1与分流UPF之间的接口隧道信息(例如，接口地址和/或F‑
TEID)。

[0311] 步骤S920、PSA‑UPF1向SMF发送会话更新响应消息。

[0312] 步骤S921、分流UPF根据业务报文分流规则将终端发送的业务报文通过PSA‑UPF1和PSA‑UPF2转发到DN。

[0313] 示例性地，分流UPF根据业务报文分流规则可以将预设业务报文分流到PSA‑UPF2进行数据网络访问，其他业务报文仍然转发至PSA‑UPF1继续进行访问。

[0314] 本申请实施例中，PSA‑UPF1可以根据PDR对业务报文进行监测，在监测到与PDR匹配的预设业务报文时向SMF发送用户面重路由触发信息；SMF根据用户面重路由触发信息可
以获知需要执行分流UPF和PSA‑UPF2的会话新建以及业务报文分流规则下发的预设业务已
经触发，并上报给PCF，进而在接收到PCF发送的用于指示SMF执行用户面重路由的指示信息
后，执行分流UPF和PSA‑UPF2的会话建立流程，以便于将特定业务流分流到相应的锚点UPF
进行数据网络访问。可见，本申请实施例可以实现基于业务感知的用户面路径调整，无需第
三方APP规划的功能实体感知和触发用户面重路由，从而提高了运营商网络的安全性。

[0315] 图10为本申请一实施例提供的网元的结构示意图。可选地，本申请实施例提供的网元可以为第一网元。如图10所示，本申请实施例的网元100可以包括：第一接收模块1001
以及重路由模块1002。

[0316] 其中，第一接收模块1001，用于接收第二网元发送的用户面重路由触发信息；其中，该用户面重路由触发信息为该第二网元监测到与报文检测规则PDR匹配的预设业务报
文时发送的；该PDR用于指示触发用户面重路由的预设业务报文对应的匹配信息以及执行
规则；

[0317] 重路由模块1002，用于根据该用户面重路由触发信息，执行用户面重路由。

[0318] 在一种可能的实现方式中，该PDR中包括：报文检测信息PDI、使用量上报规则URR；其中，该PDI用于指示该预设业务报文对应的匹配信息，该URR用于指示该预设业务报文对
应的执行规则。

[0319] 在一种可能的实现方式中，该第一网元还包括：

[0320] 第一生成模块，用于根据预置的用于触发用户面重路由的策略生成该PDR；

[0321] 第一发送模块，用于将该PDR发送给该第二网元。

[0322] 在一种可能的实现方式中，该第一网元还包括：

[0323] 获取模块，用于从第三网元获取该第三网元中预置的用于触发用户面重路由的策略；

[0324] 第二生成模块，用于根据该策略生成该PDR；

[0325] 第二发送模块，用于将该PDR发送给该第二网元。

[0326] 在一种可能的实现方式中，该第一网元还包括：

[0327] 第三发送模块，用于向该第二网元发送激活消息，该激活消息用于指示激活该第二网元中预置的该PDR。

[0328] 在一种可能的实现方式中，该PDR携带于该第一网元向该第二网元发送的第一会话创建请求消息，该第一会话创建请求消息用于指示创建该第一网元与该第二网元之间的
会话。

[0329] 在一种可能的实现方式中，该激活消息携带于该第一网元向该第二网元发送的第二会话创建请求消息，该第二会话创建请求消息用于指示创建该第一网元与该第二网元之
间的会话。

[0330] 在一种可能的实现方式中，该重路由模块1002具体用于：

[0331] 向第四网元发送第一会话请求消息，以及向第五网元发送第二会话请求消息；其中，该第一会话请求消息用于指示创建或更新该第一网元与该第四网元之间的会话，该第
二会话请求消息用于指示创建或更新该第一网元与该第五网元之间的会话，该第二会话请
求消息中携带为该第五网元分配的业务报文分流规则；和/或，

[0332] 向该第二网元发送会话更新请求消息，该会话更新请求消息用于指示更新该第二网元中的PDR。

[0333] 在一种可能的实现方式中，该重路由模块1002包括：

[0334] 创建单元，用于创建与第四网元之间的会话；

[0335] 删除单元，用于删除与该第二网元之间的会话。

[0336] 在一种可能的实现方式中，该创建单元具体用于：

[0337] 向该第四网元发送第三会话创建请求消息，该第三会话创建请求消息用于指示创建该第一网元与该第四网元之间的会话。

[0338] 在一种可能的实现方式中，该删除单元具体用于：

[0339] 向该第二网元发送会话删除请求消息，该会话删除请求消息用于指示删除该第一网元与该第二网元之间的会话。

[0340] 在一种可能的实现方式中，该第一网元还包括：

[0341] 第四发送模块，用于将该用户面重路由触发信息发送给该第三网元；

[0342] 第二接收模块，用于接收该第三网元发送的指示信息，其中，该指示信息用于指示该第一网元执行用户面重路由。

[0343] 本申请实施例提供的网元100，可以用于执行本申请上述用户面重路由方法实施例中关于第一网元的技术方案，其实现原理和技术效果类似，此处不再赘述。

[0344] 图11为本申请另一实施例提供的网元的结构示意图。可选地，本申请实施例提供的网元可以为第一网元。如图11所示，本申请实施例的网元110可以包括：监测模块1101以
及发送模块1102。

[0345] 监测模块1101，用于根据报文检测规则PDR对业务报文进行监测；其中，该PDR用于指示触发用户面重路由的预设业务报文对应的匹配信息以及执行规则；

[0346] 发送模块1102，用于若该监测模块监测到与该PDR匹配的预设业务报文时，根据该执行规则向第二网元发送用户面重路由触发信息。

[0347] 在一种可能的实现方式中，该PDR中包括：报文检测信息PDI、使用量上报规则URR；其中，该PDI用于指示该预设业务报文对应的匹配信息，该URR用于指示该预设业务报文对
应的执行规则。

[0348] 在一种可能的实现方式中，该监测模块1101具体用于：

[0349] 确定该业务报文的属性信息；

[0350] 将该属性信息与该PDI进行匹配；

[0351] 若该属性信息与该PDI匹配，则监测到该业务报文是与该PDR匹配的预设业务报文；和/或，

[0352] 若该属性信息与该PDI不匹配，则监测到该业务报文不是与该PDR匹配的预设业务报文。

[0353] 在一种可能的实现方式中，该第一网元还包括：

[0354] 第一接收模块，用于接收该第二网元发送的该PDR，其中，该PDR为该第二网元根据预置的用于触发用户面重路由的策略生成的，或者该PDR为该第二网元在从第三网元获取
到用于触发用户面重路由的策略后所生成的。

[0355] 在一种可能的实现方式中，该第一网元还包括：

[0356] 第二接收模块，用于接收该第二网元发送的激活消息，该激活消息用于指示激活该第一网元中预置的该PDR。

[0357] 在一种可能的实现方式中，该PDR携带于该第一网元接收到的该第二网元发送的第一会话创建请求消息，该第一会话创建请求消息用于指示创建该第二网元与该第一网元
之间的会话。

[0358] 在一种可能的实现方式中，该激活消息携带于该第一网元接收到的该第二网元发送的第二会话创建请求消息，该第二会话创建请求消息用于指示创建该第二网元与该第一
网元之间的会话。

[0359] 在一种可能的实现方式中，该第一网元还包括：

[0360] 第三接收模块，用于接收该第二网元发送的会话更新请求消息，该会话更新请求消息用于指示更新该第一网元中的该PDR。

[0361] 在一种可能的实现方式中，该第一网元还包括：

[0362] 第四接收模块，用于接收该第二网元发送的会话删除请求消息，该会话删除请求消息用于指示删除该第二网元与该第一网元之间的会话。

[0363] 本申请实施例提供的网元100，可以用于执行本申请上述用户面重路由方法实施例中关于第二网元的技术方案，其实现原理和技术效果类似，此处不再赘述。

[0364] 图12为本申请另一实施例提供的网元的结构示意图。如图12所示，本实施例的网元120可以包括：处理器1201和存储器1202。可选地，该网元120还可以包括用于收发信息
和/或消息的收发器1203。其中，该存储器1202用于存储程序指令，该处理器1201用于调用
并执行该存储器1202中存储的程序指令，当该处理器1201执行该存储器1202存储的程序指
令时，该网元120用于执行本申请上述用户面重路由方法实施例中关于第一网元或第二网
元的技术方案，其实现原理和技术效果类似，此处不再赘述。

[0365] 本申请实施例还提供一种计算机可读存储介质，该计算机可读存储介质中存储有指令，当该指令在计算机上运行时，使得计算机执行本申请上述用户面重路由方法实施例
中关于第一网元或第二网元的技术方案，其实现原理和技术效果类似，此处不再赘述。

[0366] 本申请实施例还提供一种芯片系统，该芯片系统包括处理器，还可以包括存储器，用于实现本申请上述用户面重路由方法实施例中关于第一网元或第二网元的技术方案，其
实现原理和技术效果类似，此处不再赘述。该芯片系统可以由芯片构成，也可以包含芯片和
其他分立器件。

[0367] 本申请实施例还提供一种程序，该程序在被处理器执行时用于执行本申请上述用户面重路由方法实施例中关于第一网元或第二网元的技术方案，其实现原理和技术效果类
似，此处不再赘述。

[0368] 本申请实施例还提供一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行本申请上述用户面重路由方法实施例中关于第一网元或第二网元的技术
方案，其实现原理和技术效果类似，此处不再赘述。

[0369] 本申请实施例中涉及的处理器可以是通用处理器、数字信号处理器、专用集成电路、现场可编程门阵列或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组
件，可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以
是微处理器或者任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体
现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

[0370] 本申请实施例中涉及的存储器可以是非易失性存储器，比如硬盘(hard disk drive，HDD)或固态硬盘(solid‑state drive，SSD)等，还可以是易失性存储器(volatile 
memory)，例如随机存取存储器(random‑access memory，RAM)。存储器是能够用于携带或存
储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不
限于此。

[0371] 在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅
仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结
合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的
相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通
信连接，可以是电性，机械或其它的形式。

[0372] 所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个
网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目
的。

[0373] 另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单
元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

[0374] 本领域普通技术人员可以理解，在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应
对本申请实施例的实施过程构成任何限定。

[0375] 在上述各实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序
产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或
部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计
算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质
中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机
指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字
用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或
数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者
是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以
是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘
Solid State Disk(SSD))等。