CN111181739A - 规则下发、接收的方法及功能实体 - Google Patents

规则下发、接收的方法及功能实体 Download PDF

Info

Publication number
CN111181739A
CN111181739A CN201811328913.0A CN201811328913A CN111181739A CN 111181739 A CN111181739 A CN 111181739A CN 201811328913 A CN201811328913 A CN 201811328913A CN 111181739 A CN111181739 A CN 111181739A
Authority
CN
China
Prior art keywords
functional entity
service
plane functional
new service
rule
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN201811328913.0A
Other languages
English (en)
Other versions
CN111181739B (zh
Inventor
夏勇
顾晓蕴
黄正刚
侯利昌
林凯
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
ZTE Corp
Original Assignee
ZTE Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ZTE Corp filed Critical ZTE Corp
Priority to CN201811328913.0A priority Critical patent/CN111181739B/zh
Priority to EP19882750.3A priority patent/EP4033699A4/en
Priority to PCT/CN2019/113083 priority patent/WO2020093878A1/zh
Publication of CN111181739A publication Critical patent/CN111181739A/zh
Application granted granted Critical
Publication of CN111181739B publication Critical patent/CN111181739B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
    • H04L12/1403—Architecture for metering, charging or billing
    • H04L12/1407—Policy-and-charging control [PCC] architecture
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/58—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP based on statistics of usage or network monitoring
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/62—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP based on trigger specification
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/64—On-line charging system [OCS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/66—Policy and charging system
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/80—Rating or billing plans; Tariff determination aspects
    • H04M15/8016—Rating or billing plans; Tariff determination aspects based on quality of service [QoS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/82—Criteria or parameters used for performing billing operations
    • H04M15/8228—Session based
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/24—Accounting or billing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/80—Rating or billing plans; Tariff determination aspects
    • H04M15/8022—Determining tariff or charge band
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/20—Services signaling; Auxiliary data signalling, i.e. transmitting data via a non-traffic channel

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • Probability & Statistics with Applications (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Quality & Reliability (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

本发明实施例公开了一种规则下发、接收的方法及功能实体，其中，所述规则下发的方法，包括：控制面功能实体确定终端向用户面功能实体发起新业务，其中，所述新业务为所述用户面功能实体未安装规则的业务；所述控制面功能实体将所述新业务的规则发送至所述用户面功能实体。通过本发明实施例，使得在CU分离的情况下，合理处理下发U面的用户规则，既可防止超长信令，又可避免使用大量CU之间信令，同时节省了C、U面的运行使用资源，提升了U面转发性能。避免了实际商用中业务划分较多情况下系统无法使用的情况，保证了用户业务的正常使用，保证了核心网对用户业务的正确计费与控制。

Description

规则下发、接收的方法及功能实体
技术领域
本发明实施例涉及但不限于一种规则下发的方法、规则接收的方法、控制面功能实体、用户面功能实体和计算机可读存储介质。
背景技术
目前一些商用局点对业务的细分化程度已经非常高，达到了数百，甚至达到上千种。这就决定了用于计费与控制的规则数量相当庞大。在商用场景中，如果不启用PCRF(Policy and Charging Rules Function，策略与计费规则功能)或PCF(Policy Controlfunction，策略控制功能)，那么在PGW(PDN GateWay，公用数据网网关)或SMF(SessionManagement Function，会话管理功能)上就必须配置数量众多的本地规则。即使PCRF(PCF)使用预定义规则名、预定义规则组名涵盖所有规则，那其规则(组)名所指向的大量具体规则仍然需要在PGW(SMF)上配置，这是目前PGW(SMF)支持业务精细化的实际情况。PCRF(PCF)无法通过Sx(N7)口支持对这么多具体业务下发动态规则。
CU分离(Control and User Plane Separation，控制面、用户面分离)后，C面(Control Plane，控制面)的某个接入用户的大量规则如何通过Sx下发到U面(User Plane，用户面，也可称为媒体面)呢？如果通过PFCP(Packet Forwarding Control Plane，数据包转发控制平面)Session Establishment Request(会话建立请求)在用户接入时下发所有业务的规则，则大量的PDR(Packet Detection Rule，报文检测规则)(可能还包括大量的FAR(Forwarding Action Rule，转发行为规则)、URR(Usage Reporting Rule，用量上报规则)、QER(QoS Enforcement Rule，服务质量执行规则))将导致此信令编码长度巨大，对CU双方来说都是承重的负担，无法达到商用要求。而通过PFCP Session ModificationRequest(会话修改请求)分批下发规则，也将导致在CU之间造成大量信令报文的情况，也是无法接受的。
发明内容
以下是对本文详细描述的主题的概述。本概述并非是为了限制权利要求的保护范围。
本发明实施例提供了一种规则下发的方法、规则接收的方法、控制面功能实体、用户面功能实体和计算机可读存储介质，以实现CU分离的情况下，合理传递用户规则。
本发明实施例提供了一种规则下发的方法，包括：
控制面功能实体确定终端向用户面功能实体发起新业务，其中，所述新业务为所述用户面功能实体未安装规则的业务；
所述控制面功能实体将所述新业务的规则发送至所述用户面功能实体。
本发明实施例还提供一种规则接收的方法，包括：
用户面功能实体确定终端发起新业务，其中，所述新业务为所述用户面功能实体未安装规则的业务；
所述用户面功能实体从控制面功能实体获取所述新业务的规则并安装。
本发明实施例还提供一种控制面功能实体，包括：
第一确定模块，用于确定终端向用户面功能实体发起新业务，其中，所述新业务为所述用户面功能实体未安装规则的业务；
下发模块，用于将所述新业务的规则发送至所述用户面功能实体。
本发明实施例还提供一种用户面功能实体，包括：
第二确定模块，用于确定终端发起新业务，其中，所述新业务为所述用户面功能实体未安装规则的业务；
获取模块，用于从控制面功能实体获取所述新业务的规则并安装。
本发明实施例还提供一种控制面功能实体，包括：存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现所述规则下发的方法。
本发明实施例还提供一种用户面功能实体，包括：存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现所述规则接收的方法。
本发明实施例还提供一种计算机可读存储介质，存储有计算机可执行指令，所述计算机可执行指令用于执行所述规则下发的方法。
本发明实施例还提供一种计算机可读存储介质，存储有计算机可执行指令，所述计算机可执行指令用于执行所述规则接收的方法。
本发明实施例包括：控制面功能实体确定终端向用户面功能实体发起新业务，其中，所述新业务为所述用户面功能实体未安装规则的业务；所述控制面功能实体将所述新业务的规则发送至所述用户面功能实体。通过本发明实施例，使得在CU分离的情况下，合理处理下发U面的用户规则，既可防止超长信令，又可避免使用大量CU之间信令，同时节省了C、U面的运行使用资源，提升了U面转发性能。避免了实际商用中业务划分较多情况下系统无法使用的情况，保证了用户业务的正常使用，保证了核心网对用户业务的正确计费与控制。
在阅读并理解了附图和详细描述后，可以明白其他方面。
附图说明
图1是本发明实施例的规则下发的方法的流程图；
图2是本发明另一实施例的规则下发的方法的流程图；
图3是本发明再一实施例的规则下发的方法的流程图；
图4是本发明实施例的规则接收的方法的流程图；
图5是图4中步骤402的流程图；
图6是本发明另一实施例的规则接收的方法的流程图；
图7是本发明再一实施例的规则接收的方法的流程图；
图8是本发明应用实例1(纯C面本地规则)流程图；
图9是本发明应用实例2(PCRF(PCF)下发预定义规则组指定用户规则)的流程图；
图10是本发明应用实例3(开启在线计费业务)的流程图；
图11是本发明应用实例4(网络侧发起专有承载(QFI)建立)的流程图；
图12是本发明应用实例5(PCRF(PCF)下发流信息动态规则)的流程图；
图13是本发明应用实例6(手动配置作为用户群常用业务识别)的流程图；
图14是本发明应用实例7(系统自动生成业务排名作为用户群常用业务识别)的流程图；
图15是本发明应用实例8(利用外设保存用户偏好数据作为用户常用业务识别)的流程图；
图16是本发明实施例的控制面功能实体的组成示意图；
图17是本发明实施例的用户面功能实体的组成示意图；
图18是本发明另一实施例的控制面功能实体的组成示意图；
图19是本发明另一实施例的用户面功能实体的组成示意图。
具体实施方式
下文中将结合附图对本发明的实施例进行详细说明。
在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行。并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。
经过分析，可以发现C面在准备给U面下发业务规则的时候，C面其实并不知道用户即将和最终使用哪些业务，所以C面只能把尽量多的、或者所有业务的规则下发到U面，使得需要下发大量的规则。
在本发明实施例中，C面可以仅将常用业务的规则下发至U面，对于C面未下发给U面创建规则的业务(新业务)，采取“按需分配”安装规则的策略，即用户使用这种业务了，再安装相关的规则(可以包括业务相关的PDR、FAR、URR、QER)。在一些情况下，C面也可以不下发常用业务的规则，即不指定常用业务。
如图1所示，本发明实施例的规则下发的方法，应用于控制器功能实体，包括：
步骤101，控制面功能实体确定终端向用户面功能实体发起新业务，其中，所述新业务为所述用户面功能实体未安装规则的业务。
其中，所述控制面功能实体可以是PCRF或PCF，用户面功能实体可以是PGW或SMF。
在一实施例中，所述控制面功能实体接收所述用户面功能实体发送的新业务识别上报通知，根据所述新业务识别上报通知确定终端向所述用户面功能实体发起新业务。
其中，所述新业务识别上报通知可以但不限于是PFCP Session Report(会话上报)消息。
步骤102，所述控制面功能实体将所述新业务的规则发送至所述用户面功能实体。
其中，所述控制面功能实体可以直接确定所述新业务的规则，也可能与OCS(Online Charging System，在线计费系统)等其他网元(或NF(Network Function，网络功能)交互后确定所述新业务的规则。
在一实施例中，所述控制面功能实体通过会话修改请求向所述用户面功能实体发送所述新业务的规则。
其中，所述会话修改请求可以但不限于是PFCP Modify Request消息。
如图2所示，在一实施例中，步骤101之前，还可以包括：
步骤201，所述控制面功能实体预先将常用业务的规则发送至所述用户面功能实体。
运营商给用户规划的大量规则是针对各种具体业务的，即不同的AppID(应用标识)。用户一般不会全部使用这些业务(至少不会马上全部使用)，且常用业务集中在若干个。基于这样的实际情况，C面在不知道用户会使用哪些业务的时候，无需把所有业务的规则都下发给U面，只需下发常用业务的即可，这样可以保证大批用户常用业务的规则命中率，同时避免了因下发规则数量太多，导致信令长度超长的情况。特殊的情况C面可以一个具体业务规则都不发给U面安装，即不指定常用业务。
在一实施例中，所述控制面功能实体预先将常用业务的规则通过Sx(N4)口下发给所述用户面功能实体。
在一实施例中，步骤201之前，还包括：所述控制面功能实体确定常用业务，可以包括但不限于如下方式及其组合：
1、根据接收到的配置信息确定所述常用业务。
其中，可以依赖人为经验、或相关数据手动指定，并在控制面功能实体上配置。
2、根据业务相关的全局统计数据进行统计排名，确定所述常用业务。
其中，对具体业务相关的全局统计数据进行统计排名后，应用于所有个体用户，从而可以自动确定接入用户的常用业务。
3、根据用户上网行为记录确定所述常用业务。
其中，可以基于运营商对个体用户上网行为的记录，分析出属于特定用户的常用业务，从而可以自动确定接入用户的常用业务，这种方式借助外部设备存储用户上网行为等数据，并与之交互获取数据。
如图3所示，在一实施例中，步骤101之前，还可以包括：
步骤301，所述控制面功能实体指示所述用户面功能实体创建一个或多个新业务探测器，所述新业务探测器用于检测所述用户面功能实体未安装规则的业务。
其中，步骤201和步骤301可以同时执行，即所述控制面功能实体在下发常用业务的规则的同时，指示所述用户面功能实体创建新业务探测器。
新业务探测器可以探测到新业务后将具体探测信息通知控制面功能实体。
所述新业务探测器可以反复使用，在完成一次新业务规则安装后，可重新恢复探测作用，继续探测新的未安装规则的新业务。
在一实施例中，所述报文匹配规则包括不指定应用标识(Application ID)的PDR(分上下行)，所述不指定应用标识的PDR比指定应用标识的PDR的优先级低。
在一实施例中，所述不指定应用标识的PDR与设置有启动触发器的URR相关联，所述启动触发器用于触发新业务识别上报。
在一实施例中，所述控制面功能实体通过所述会话修改请求指示更新设置有启动触发器的URR，以重置所述启动触发器。
在一实施例中，所述不指定应用标识的PDR与设置有缓存操作的FAR相关联。
在一实施例中，所述新业务探测器用于探测如下业务中的至少之一：
默认承载业务、专有承载业务、动态规则业务。
所述新业务探测器包含预设匹配参数的报文匹配规则。
所述新业务探测器可以根据不同的应用场景同时设置PDI(Packet DetectionInformation，报文探测信息)中不同的SDF(Service Data Flow，业务数据流)(可以通配，或者没有SDF)来为默认承载、专有承载、PCC(Policy Control and Charging，策略控制和计费)动态规则等探测新业务。控制面功能实体可以下发多个新业务探测器分别负责他们的探测。
通过本发明实施例，使得在CU分离的情况下，合理处理下发U面的用户规则，既可防止超长信令，又可避免使用大量CU之间信令，同时节省了C、U面的运行使用资源，提升了U面转发性能。避免了实际商用中业务划分较多情况下系统无法使用的情况，保证了用户业务的正常使用，保证了核心网对用户业务的正确计费与控制。
如图4所示，本发明实施例的规则接收的方法，应用于用户面功能实体，包括：
步骤401，用户面功能实体确定终端发起新业务，其中，所述新业务为所述用户面功能实体未安装规则的业务。
其中，所述用户面功能实体根据所述终端发起的新业务的业务报文，确定终端发起新业务。
步骤402，所述用户面功能实体从控制面功能实体获取所述新业务的规则并安装。
如图5所示，在一实施例中，所述步骤402可以包括：
步骤501，所述用户面功能实体向所述控制面功能实体发送新业务识别上报通知。
其中，所述新业务识别上报通知可以但不限于是PFCP Session Report消息。
步骤502，所述用户面功能实体接收所述控制面功能实体发送的会话修改请求，所述会话修改请求携带所述新业务的规则。
其中，所述会话修改请求可以但不限于是PFCP Modify Request消息。
如图6所示，在一实施例中，步骤401之前，还包括：
步骤601，所述用户面功能实体接收所述控制面功能实体发送的常用业务的规则并安装。
其中，可以通过Sx(N4)口接收所述控制面功能实体发送的常用业务的规则。
通过从所述控制面功能实体接收常用业务的规则并安装，可以保证大批用户常用业务的规则命中率，同时避免了因下发规则数量太多，导致信令长度超长的情况。
如图7所示，在一实施例中，步骤401之前，还包括：
步骤701，所述用户面功能实体创建一个或多个新业务探测器，所述新业务探测器用于检测所述用户面功能实体未安装规则的业务。
其中，所述用户面功能实体可以根据所述控制面功能实体的指示创建一个或多个新业务探测器，也可以根据预设的规则自动创建一个或多个新业务探测器。
在新业务探测器由控制面功能实体的指示创建时，步骤601和步骤701可以同时执行，即所述控制面功能实体在下发常用业务的规则的同时，指示所述用户面功能实体创建新业务探测器。
新业务探测器可以探测到新业务后将具体探测信息通知控制面功能实体。
在一实施例中，所述用户面功能实体确定终端发起新业务，包括：
所述用户面功能实体接收所述终端发起的新业务的业务报文，通过所述新业务探测器检测所述业务报文，确定终端发起新业务。
在一实施例中，所述新业务探测器包含预设匹配参数的报文匹配规则，所述通过所述新业务探测器检测所述业务报文，确定终端发起新业务，包括：
通过所述报文匹配规则对所述业务报文进行匹配，在匹配通过时，确定终端发起新业务。
在一实施例中，所述报文匹配规则包括不指定应用标识(Application ID)的PDR(分上下行)，所述不指定应用标识的PDR比指定应用标识的PDR的优先级低。
在一实施例中，所述不指定应用标识的PDR与设置有启动(Start)触发器的URR相关联，所述启动触发器用于触发新业务识别上报。
其中，所述用户面功能实体接收所述终端发起的新业务的业务报文，确定所述终端发起新业务时，启动触发器触发新业务识别上报，所述用户面功能实体向所述控制面功能实体发送新业务识别上报通知。
在一实施例中，所述不指定应用标识的PDR与设置有缓存操作的FAR相关联，所述用户面功能实体确定终端发起新业务之后，还包括：
所述用户面功能实体缓存所述新业务的业务报文。
在一实施例中，所述用户面功能实体从控制面功能实体获取所述新业务的规则并安装之后，还包括：
所述用户面功能实体释放缓存的所述新业务的业务报文，重新匹配规则，按照所述新业务的规则执行。
在一实施例中，步骤502中，会话修改请求还指示更新设置有启动触发器的URR，所述用户面功能实体根据所述会话修改请求的指示更新所述URR，以重置所述启动触发器。从而使得所述新业务探测器可以反复使用，在完成一次新业务规则安装后，可重新恢复探测作用，继续探测新的未安装规则的新业务。
在一实施例中，所述新业务探测器用于探测如下业务中的至少之一：
默认承载业务、专有承载业务、动态规则业务。
所述新业务探测器可以根据不同的应用场景同时设置PDI中不同的SDF(可以通配，或者没有SDF)来为默认承载、专有承载、PCC动态规则等探测新业务。
通过本发明实施例，使得在CU分离的情况下，合理处理下发U面的用户规则，既可防止超长信令，又可避免使用大量CU之间信令，同时节省了C、U面的运行使用资源，提升了U面转发性能。避免了实际商用中业务划分较多情况下系统无法使用的情况，保证了用户业务的正常使用，保证了核心网对用户业务的正确计费与控制。
下面以一些应用实例进行说明。
应用实例1
如图8所示，应用实例1包括如下步骤：
步骤801，用户会话创建，C面向U面发起建立Sx(N4)会话请求。该用户业务细化程度高，规则多，如果全部一次安装到U面可能需要上百PDR规则。这里为了说明简便，假设用户常用的业务只有1个，即AppID1代表的业务，为此业务创建上下行PDR1、PDR2，其中PDR1的PDI包括Local(本地)F-TEID(Full Qualified Tunnel Endpoint Identifier，全量隧道端点标识)等隧道信息、Application ID(应用标识，这里就是AppID1)，PDR2的PDI包括UE IPaddress、Application ID(这里就是AppID1)。上行转发使用FAR1，下行转发使用FAR2。AppID的业务使用URR1作为用量统计规则。为了探测其他非特定业务(即其他AppID)，为此创建上下行PDRi、PDRj，其中PDRi的PDI包括Local F-TEID等隧道信息、无Application ID(即通配所有Application ID)，PDRj的PDI包括UE IP address、无Application ID(即通配所有Application ID)。PDRi、PDRj的优先级低于特定AppID1业务的PDR1、PDR2。PDRi、PDRj关联URRn，URRn安装Start触发器，一旦报文匹配PDRi、PDRj即可触发探测到其他业务的Start上报，这里只要是AppID1以外的业务都可触发URRn的Start上报。为了在探测到新业务时候能将报文缓存，PDRi、PDRj关联有缓存操作的FAR规则，并有BAR规则指示具体的缓存参数，这些协议已有专门的说明，不再加以说明，后续实例中的新业务探测器同理关联缓存相关的FAR与BAR。
步骤802，会话建立响应，此时会话建立成功，会话与各PDR、FAR、URR关系如图8，这里简略了QER，原理相同。
步骤803，发起AppID1的业务流经过U面，匹配PDR1、PDR2并按相应的FAR1、FAR2、URR1规则执行。
步骤804，终端发起AppID2的业务流达到U面，U面具备应用识别功能，可识别此业务流为AppID2。匹配PDRi或PDRj，触发步骤805中URRn的Start上报，业务流报文被U面缓存。
步骤805，U面在发起URRn的Start上报时，在应用探测信息中填写Application ID为AppID2，并上报业务流信息。
步骤806，C面响应U面的会话上报请求。
步骤807，C面在步骤805收到URRn的Start上报时，已经感知到新业务AppID2的来到，并知道AppID2的业务规则还没有下发给U面，于是在步骤806响应U面会话上报请求后，马上对U面发起会话修改请求。会话修改请求包括为AppID2业务创建上下行PDR3、PDR4，其中PDR3的PDI包括Local F-TEID等隧道信息、Application ID(这里就是AppID2)，PDR4的PDI包括UE IP address、Application ID(这里就是AppID2)。PDR3、PDR4的优先级高于PDRi、PDRj。并为AppID2业务创建独立的用量统计规则URR2(也可以指向之前的URR1，这里只是为了说明方便，突出AppID2的特别之处)，并为AppID2的业务的上下行转发指向原先的FAR1、FAR2，以表示AppID2的业务的上下行转发规则与AppID1相同。最后在这个会话修改请求中，还对URRn进行更新，恢复其Start触发器，以保证下次新的业务(AppID1、AppID2以外的业务)到来时，同样可以触发URRn的Start上报。
步骤808，U面响应C面发起的会话修改请求，此时这个会话中各规则的关系如图8。PDR3、PDR4已经成功安装，优先级高于PDRi、PDRj。URR2也安装成功并被关联到AppID2业务的PDR下。PDRi、PDRj以及URRn像步骤802后的流程那样，继续探测着那些未使用、未安装规则的业务。
步骤809，U面释放步骤804中缓存的报文，重新按会话下的规则执行，这些AppID2的报文将匹配PDR3、PDR4，并被URR2进行用量统计。后续AppID2业务将有规则可依，不再需要请求C面安装规则。
应用实例9
如图9所示，应用实例2包括如下步骤：
步骤901，C面收到会话创建请求。
步骤902，C面向PCRF(PCF)发起CCR(I)(Credit Control Request，信用控制请求)(类型为初始请求)。
步骤903，PCRF(PCF)响应CCA(I)，并在CCA(I)中下发预定义规则组名，这个预定义规则组名对应C面配置的99条预定义规则，每条预定义规则为特定业务(指定AppID)的计费控制策略。
步骤904，C面收到CCA(I)，根据预定义规则组名找到用户的99条预定义规则，从配置指定中选择其中常用两种业务的预定义规则(这里常用业务为AppID1、AppID2)，将其转化为N4(Sx)口规则通过Session Establishment(会话建立)请求下发给U面，PDR1、PDR2、PDR3、PDR4分别代表AppID1、AppID2业务的上下行PDR，指定他们的转发规则FAR1、FAR2，指定他们的用量统计URR1。同时下发PDRi、PDRj作为新业务探测器，URRn为其Start触发器。
步骤905，U面响应C面的Session Establishment请求。
步骤906，C面响应会话创建请求成功。
步骤907，终端发起常用业务AppID1，上下行匹配PDR1、PDR2，并由FAR1、FAR2转发，用量统计入URR1，业务正常。
步骤908，终端发起常用业务AppID2，上下行匹配PDR3、PDR4，并由FAR1、FAR2转发，用量统计入URR1，业务正常。
步骤909，终端发起非常用业务AppID3，上下行匹配PDRi、PDRj，触发步骤910，报文被缓存。
步骤910，新业务探测器发现新业务AppID3到达，U面向C面发起Session Report请求，上报URRn的Start触发，包括探测信息Application ID为AppID3和流信息。
步骤911，C面响应U面的Session Report请求。
步骤912，C面在第910步收到URRn的Start上报时，已经感知到新业务AppID3的来到，并知道AppID3的业务规则还没有下发给U面，于是在第911步响应U面会话上报请求后，马上对U面发起会话修改请求。会话修改请求包括为AppID3业务创建上下行PDR5、PDR6。PDR5、PDR6的优先级高于PDRi、PDRj。并为AppID3业务创建独立的用量统计规则URR2，有关AppID3的转发规则FAR可依具体业务特性指定，这里不再特别说明。最后在这个会话修改请求中，还对URRn进行更新，恢复其Start触发器，以保证下次新的业务(AppID1、AppID2、AppID3以外的业务)到来时，同样可以触发URRn的Start上报。
步骤913，U面响应C面发起的会话修改请求。
步骤914，U面释放步骤909中缓存的报文，重新按会话下的规则执行，这些AppID3的报文将匹配PDR5、PDR6，并被URR2进行用量统计。
步骤915，后续AppID3的业务流将有规则可依，不再需要请求C面安装规则，顺利通过U面。
步骤916，终端发起非常用业务AppID4，上下行匹配PDRi、PDRj，触发步骤917，报文被缓存。
步骤917，新业务探测器发现新业务AppID4到达，U面向C面发起Session Report请求，上报URRn的Start触发，包括探测信息Application ID为AppID4和流信息。
步骤918，C面响应U面的Session Report请求。
步骤919，C面在第917步收到URRn的Start上报时，已经感知到新业务AppID4的来到，并知道AppID4的业务规则还没有下发给U面，于是在第918步响应U面会话上报请求后，马上对U面发起会话修改请求。会话修改请求包括为AppID4业务创建上下行PDR7、PDR8。PDR7、PDR8的优先级高于PDRi、PDRj。并为AppID4业务创建独立的用量统计规则URR3。最后在这个会话修改请求中，还对URRn进行更新，恢复其Start触发器，以保证下次新的业务(AppID1、AppID2、AppID3、AppID4以外的业务)到来时，同样可以触发URRn的Start上报。
步骤920，U面响应C面发起的会话修改请求。
步骤921，U面释放步骤916中缓存的报文，重新按会话下的规则执行，这些AppID4的报文将匹配PDR7、PDR8，并被URR3进行用量统计。
步骤922，后续AppID4的业务流将有规则可依，不再需要请求C面安装规则，顺利通过U面。
应用实例3
如图10所示，应用实例3包括如下步骤：
步骤1001，C面收到会话创建请求。
步骤1002，C面向OCS发起CCR(I)鉴权请求。
步骤1003，OCS响应CCA(I)，指示鉴权成功，允许接入。
步骤1004，C面向U面发起Session Establishment请求。这里为了说明简单，不下发常用业务的规则，即没有常用业务，只下发新业务探测器PDRi、PDRj和Start触发器URRn。
步骤1005，U面响应C面的Session Establishment请求。
步骤1006，C面响应会话创建请求成功。
步骤1007，终端发起AppID1业务，上下行匹配PDRi、PDRj，触发步骤1008，报文被缓存。
步骤1008，新业务探测器发现新业务AppID1到达，U面向C面发起Session Report请求，上报URRn的Start触发，包括探测信息Application ID为AppID1和流信息。
步骤1009，C面响应U面的Session Report请求。
步骤1010，C面在第1008步收到URRn的Start上报时，已经感知到新业务AppID1的来到，并知道AppID1的业务规则还没有下发给U面。同时根据C面配置的规则，该业务在计费策略上归属RatingGroup1费率组，而RatingGroup1还没有经过OCS配额授权。于是C面向OCS发起CCR(U)(类型为更新请求)为RatingGroup1请求配额授权。
步骤1011，OCS响应C面的配额请求，在CCA(U)中授予配额，允许用户使用RatingGroup1业务。
步骤1012，根据步骤1010中C面可获取的AppID1的本地策略，加上步骤1011中C面从OCS获取的RatingGroup1配额授权，C面可以下发AppID1对应的全部规则了。于是C面向U面发起会话修改请求，为AppID1业务创建上下行PDR1、PDR2，并为RatingGroup1创建URR1用于包括AppID1业务在内的RatingGroup1业务进行用量统计、配额控制，PDR1、PDR2关联URR1。最后在这个会话修改请求中，还对URRn进行更新，恢复其Start触发器，以保证下次新的业务(AppID1以外的业务)到来时，同样可以触发URRn的Start上报。
步骤1013，U面响应C面发起的会话修改请求。
步骤1014，U面释放步骤1007中缓存的报文，重新按会话下的规则执行，这些AppID1的报文将匹配PDR1、PDR2，并被URR1进行用量统计。
步骤1015，后续AppID1的业务流将有规则可依，不再需要请求C面安装规则，顺利通过U面。
步骤1016，终端发起AppID2业务，上下行匹配PDRi、PDRj，触发步骤1017，报文被缓存。
步骤1017，新业务探测器发现新业务AppID2到达，U面向C面发起Session Report请求，上报URRn的Start触发，包括探测信息Application ID为AppID2和流信息。
步骤1018，C面响应U面的Session Report请求。
步骤1019，C面在第1017步收到URRn的Start上报时，已经感知到新业务AppID2的来到，并知道AppID2的业务规则还没有下发给U面。同时根据C面配置的规则，该业务在计费策略上归属RatingGroup2费率组，而RatingGroup2还没有经过OCS配额授权。于是C面向OCS发起CCR(U)为RatingGroup2请求配额授权。
步骤1020，OCS响应C面的配额请求，在CCA(U)中授予配额，允许用户使用RatingGroup2业务。
步骤1021，根据步骤1019中C面可获取的AppID2的本地策略，加上步骤1020中C面从OCS获取的RatingGroup2配额授权，C面可以下发AppID2对应的全部规则了。于是C面向U面发起会话修改请求，为AppID2业务创建上下行PDR3、PDR4，并为RatingGroup2创建URR2用于包括AppID2业务在内的RatingGroup2业务进行用量统计、配额控制，PDR3、PDR4关联URR2。最后在这个会话修改请求中，还对URRn进行更新，恢复其Start触发器，以保证下次新的业务(AppID1、AppID2以外的业务)到来时，同样可以触发URRn的Start上报。
步骤1022，U面响应C面发起的会话修改请求。
步骤1023，U面释放步骤1016中缓存的报文，重新按会话下的规则执行，这些AppID2的报文将匹配PDR3、PDR4，并被URR2进行用量统计。
步骤1024，后续AppID2的业务流将有规则可依，不再需要请求C面安装规则，顺利通过U面。
步骤1025，终端发起AppID3业务，上下行匹配PDRi、PDRj，触发步骤1026，报文被缓存。
步骤1026，新业务探测器发现新业务AppID3到达，U面向C面发起Session Report请求，上报URRn的Start触发，包括探测信息Application ID为AppID3和流信息。
步骤1027，C面响应U面的Session Report请求。
步骤1028，C面在第1026步收到URRn的Start上报时，已经感知到新业务AppID3的来到，并知道AppID3的业务规则还没有下发给U面。同时根据C面配置的规则，该业务在计费策略上归属RatingGroup1费率组，而RatingGroup1已经经过OCS配额授权，因此C面已经可以下发AppID3对应的全部规则了。于是C面向U面发起会话修改请求，为AppID3业务创建上下行PDR5、PDR6，并关联URR1。最后在这个会话修改请求中，还对URRn进行更新，恢复其Start触发器，以保证下次新的业务(AppID1、AppID2、AppID3以外的业务)到来时，同样可以触发URRn的Start上报。
步骤1029，U面响应C面发起的会话修改请求。
步骤1030，U面释放步骤1025中缓存的报文，重新按会话下的规则执行，这些AppID3的报文将匹配PDR5、PDR6，并被URR1进行用量统计。
步骤1031，后续AppID3的业务流将有规则可依，不再需要请求C面安装规则，顺利通过U面。
应用实例4
如图11所示，应用实例4包括如下步骤：
步骤1101，C面收到会话创建请求。
步骤1102，C面向PCRF(PCF)发起CCR(I)请求。
步骤1103，PCRF(PCF)响应CCA(I)成功。
步骤1104，C面收到CCA(I)，根据PCRF的下发参数与本地配置情况，给U面发起Session Establishment请求，安装相关规则(包括新业务探测器)，这里安装的规则都归属默认承载。安装内容类似应用实例2中步骤904。
步骤1105，U面响应C面的Session Establishment请求。
步骤1106，C面响应会话创建请求成功。
步骤1107，终端使用默认承载发起相关业务，可以是已经安装规则的业务，也可以是没有安装规则的业务。
步骤1108，如果默认承载发起的业务是未安装规则的业务，类似应用实例2中步骤910至步骤913，进行新业务规则的安装，安装的规则都归属默认承载。
步骤1109，PCRF(PCF)通过RAR请求，指定专有承载的流信息描述，发起网络侧专有承载建立。
步骤1110，C面响应RAR请求，回送RAA响应。
步骤1111，C面向前端网元发送创建承载请求。
步骤1112，C面收到前端网元的创建承载响应。
步骤1113，C面向U面发起会话修改请求，这里C面根据指定可选得为专有承载指定一个常用业务，即AppID1代表的业务，为此业务创建上下行PDR21、PDR22，其中PDR21的PDI包括Local F-TEID等隧道信息、SDF(即专载的流消息描述)、Application ID(这里就是AppID1)，PDR22的PDI包括UE IP address、SDF(即专载的流信息描述)、Application ID(这里就是AppID1)。专载AppID的业务使用URR21作为用量统计规则。为了探测专载其他业务(即其他AppID)，为此创建上下行PDR2i、PDR2j，其中PDR2i的PDI包括Local F-TEID等隧道信息、SDF(即专载的流信息描述)、无Application ID(即通配所有Application ID)，PDR2j的PDI包括UE IP address、SDF(即专载的流消息描述)、无Application ID(即通配所有Application ID)。PDR2i、PDR2j的优先级低于专载AppID1业务的PDR21、PDR22，但高于所有默认承载的PDR优先级。创建URR2n作为新业务探测器的Start触发器
步骤1114，U面响应C面的会话修改请求。
步骤1115，终端通过专有承载发起AppID1的业务，匹配PDR21、PDR22,用量统计入URR21。业务正常使用。
步骤1116，终端通过专有承载发起AppID2的业务，匹配PDR2i、PDR2j，触发步骤1117，报文被缓存。
步骤1117，专载的新业务探测器发现新业务AppID2到达，U面向C面发起SessionReport请求，上报URR2n的Start触发，包括探测信息Application ID为AppID2和流信息。
步骤1118，C面响应U面的Session Report请求。
步骤1119，C面在第1117步收到URR2n的Start上报时，已经感知到新业务AppID2的来到，并知道AppID2的业务规则还没有下发给U面，于是在第1118步响应U面会话上报请求后，马上对U面发起会话修改请求。会话修改请求包括为AppID2业务创建上下行PDR23、PDR24。PDR23、PDR24的优先级高于PDR2i、PDR2j。并为AppID2业务创建独立的用量统计规则URR22。最后在这个会话修改请求中，还对URR2n进行更新，恢复其Start触发器，以保证专载下次新的业务(AppID1、AppID2以外的业务)到来时，同样可以触发URR2n的Start上报。
步骤1120，U面响应C面发起的会话修改请求。
步骤1121，U面释放步骤1116中缓存的报文，重新按会话下的规则执行，这些专载的AppID2的报文将匹配PDR23、PDR24，并被URR22进行用量统计。
步骤1122，后续专载的AppID2的业务流将有规则可依，不再需要请求C面安装规则，顺利通过U面。
应用实例5
如图12所示，应用实例5包括如下步骤：
步骤1201，在用户会话创建时，C面指示U面为默认承载上AppID1业务创建了对应的上下行PDR1、PDR2，关联URR1；为AppID2业务创建了对应的上下行PDR3、PDR4，关联URR2。
步骤1202，C面向PCRF(PCF)发起的某次CCR(U)请求。
步骤1203，PCRF(PCF)响应C面的CCR(U)请求，在响应的CCA(U)中下发一个动态规则，此动态规则使用流描述信息指定默认承载上的某些业务，并要求符合此流描述信息的业务做特殊处理。但此动态规则只指定了部分规则，对例如计费方式等没有指定。
步骤1204，C面收到CCA(U)后，按PCRF(PCF)的指示安装动态规则，但发现这个动态规则指定的流描述信息所指的具体业务无法确定(即无法确定唯一的AppID)，这样就无法根据AppID获得C面配置的计费方式等信息，也就无法补充动态规则中未指示的部分规则信息，也就无法下发完整规则给U面。所以指示U面为此动态规则创建新业务探测器，先探测具体业务，后安装完整规则。于是向U面发起修改会话请求，创建上下行PDR2i、PDR2j，其中PDR2i的PDI包括Local F-TEID等隧道信息、SDF(即动态规则的流信息描述)、无Application ID(即通配所有Application ID)，PDR2j的PDI包括UE IP address、SDF(即动态规则的流信息描述)、无Application ID(即通配所有Application ID)。PDR2i、PDR2j的优先级高于所有默认承载上通配SDF(或者没有SDF)的PDR优先级。PDR2i、PDR2j也属于默认承载的PDR，只是优先级相对较高。创建URR2n作为新业务探测器的Start触发器。
步骤1205，U面响应C面的会话修改请求。
步骤1206，终端发起符合动态规则流描述信息的AppID1业务，匹配PDR2i、PDR2j，触发步骤1207，报文被缓存。
步骤1207，动态规则的新业务探测器发现新业务AppID1到达，U面向C面发起Session Report请求，上报URR2n的Start触发，包括探测信息Application ID为AppID1和流信息。
步骤1208，C面响应U面的Session Report请求。
步骤1209，C面在第1207步收到URR2n的Start上报时，已经感知到动态规则中新业务AppID1的来到，并知道动态规则中AppID1的业务规则还没有下发给U面，于是在第1208步响应U面会话上报请求后，马上对U面发起会话修改请求。会话修改请求包括为动态规则中AppID1业务创建上下行PDR21、PDR22。PDR21、PDR22的优先级高于PDR2i、PDR2j。因用量统计归属默认承载同业务，所以PDR21、PDR22关联URR1，即并入同承载AppID1的用量统计。最后在这个会话修改请求中，还对URR2n进行更新，恢复其Start触发器，以保证这个动态规则下次新的业务(AppID1以外的业务)到来时，同样可以触发URR2n的Start上报。
步骤1210，U面响应C面发起的会话修改请求。
步骤1211，U面释放步骤1206中缓存的报文，重新按会话下的规则执行，这些符合动态规则的AppID1的报文将匹配PDR21、PDR22，并被URR1进行用量统计。
步骤1212，后续符合动态规则流描述信息的AppID1业务流将有规则可依，不再需要请求C面安装规则，顺利通过U面。
步骤1213，终端发起符合动态规则流描述信息的AppID2业务，匹配PDR2i、PDR2j，触发步骤1214，报文被缓存。
步骤1214，动态规则的新业务探测器发现新业务AppID2到达，U面向C面发起Session Report请求，上报URR2n的Start触发，包括探测信息Application ID为AppID2和流信息。
步骤1215，C面响应U面的Session Report请求。
步骤1216，C面在第1214步收到URR2n的Start上报时，已经感知到动态规则中新业务AppID2的来到，并知道动态规则中AppID2的业务规则还没有下发给U面，于是在第1215步响应U面会话上报请求后，马上对U面发起会话修改请求。会话修改请求包括为动态规则中AppID2业务创建上下行PDR23、PDR24。PDR23、PDR24的优先级高于PDR2i、PDR2j。因用量统计归属默认承载同业务，所以PDR23、PDR24关联URR2，即并入同承载AppID2的用量统计。最后在这个会话修改请求中，还对URR2n进行更新，恢复其Start触发器，以保证这个动态规则下次新的业务(AppID1、AppID2以外的业务)到来时，同样可以触发URR2n的Start上报。
步骤1217，U面响应C面发起的会话修改请求。
步骤1218，U面释放步骤1213中缓存的报文，重新按会话下的规则执行，这些符合动态规则的AppID2的报文将匹配PDR23、PDR24，并被URR2进行用量统计。
步骤1219，后续符合动态规则流描述信息的AppID2业务流将有规则可依，不再需要请求C面安装规则，顺利通过U面。
应用实例6
如图13所示，应用实例6包括如下步骤：
步骤1301，在C面设备上进行数据配置，配置两个常用业务，分别为AppID1、AppID2。常用业务个数可视情况而定，这里举例为2个常用业务。
步骤1302，某用户发起创建会话请求至C面，请求接入设备。
步骤1303，C面向U面发起PFCP会话建立请求，该请求指示安装业务AppID1、AppID2的相关规则，这里的AppID1、AppID2即为步骤1301中配置的两个常用业务。请求还包括新业务探测器。
步骤1304，U面响应C面的PFCP会话建立请求。
步骤1305，C面响应用户发起的创建会话请求。
应用实例7
如图14所示，应用实例7包括如下步骤：
步骤1401，系统运行，对用户群使用业务的种类、频度等数据进行统计分析，生成用户群关于他们使用的不同业务的排名，这个排名可以作为常用业务的识别。这里举例说明中，排名依次为AppID1、AppID2、AppID3、AppID4......。这个排名可通过C面内部自动生成。
步骤1402，某用户发起创建会话请求至C面，请求接入设备。
步骤1403，C面向U面发起PFCP会话建立请求，该请求指示安装业务AppID1、AppID2的相关规则，这里的AppID1、AppID2即为步骤1401中业务排名取前两位作为常用业务。请求还包括新业务探测器。
步骤1404，U面响应C面的PFCP会话建立请求。
步骤1405，C面响应用户发起的创建会话请求。
应用实例8
如图15所示，应用实例8包括如下步骤：
步骤1501，某用户接入移动网络，使用移动网络进行各种业务。在用户使用过程中，核心网设备(这里主要是C面与U面)对其使用移动网络的业务偏好数据存入外部设备。
步骤1502，这个用户后续再次发起创建会话请求至C面，请求接入设备，C面从外部设备获取该用户的业务偏好数据。
步骤1503，C面向U面发起PFCP会话建立请求，该请求指示安装业务AppID1、AppID2的相关规则，这里的AppID1、AppID2即为步骤1502中C面从外部设备获取的用户偏好数据，即这个用户偏好的常用业务。请求还包括新业务探测器。
步骤1504，U面响应C面的PFCP会话建立请求。
步骤1505，C面响应用户发起的创建会话请求。
如图16所示，本发明实施例还提供一种控制面功能实体，包括：
第一确定模块1601，用于确定终端向用户面功能实体发起新业务，其中，所述新业务为所述用户面功能实体未安装规则的业务；
下发模块1602，用于将所述新业务的规则发送至所述用户面功能实体。
如图17所示，本发明实施例还提供一种用户面功能实体，包括：
第二确定模块1701，用于确定终端发起新业务，其中，所述新业务为所述用户面功能实体未安装规则的业务；
获取模块1702，用于从控制面功能实体获取所述新业务的规则并安装。
如图18所示，本发明实施例还提供一种控制面功能实体，包括：存储器1801、处理器1802及存储在存储器1801上并可在处理器1802上运行的计算机程序1803，所述处理器1802执行所述计算机程序时实现所述规则下发的方法。
如图19所示，本发明实施例还提供一种用户面功能实体，包括：存储器1901、处理器1902及存储在存储器1901上并可在处理器1902上运行的计算机程序1903，所述处理器1902执行所述计算机程序1903时实现所述规则接收的方法。
本发明实施例还提供一种计算机可读存储介质，存储有计算机可执行指令，所述计算机可执行指令用于执行所述规则下发的方法。
本发明实施例还提供一种计算机可读存储介质，存储有计算机可执行指令，所述计算机可执行指令用于执行所述规则接收的方法。
在本实施例中，上述存储介质可以包括但不限于：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。
本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤、系统、装置中的功能模块/单元可以被实施为软件、固件、硬件及其适当的组合。在硬件实施方式中，在以上描述中提及的功能模块/单元之间的划分不一定对应于物理组件的划分；例如，一个物理组件可以具有多个功能，或者一个功能或步骤可以由若干物理组件合作执行。某些组件或所有组件可以被实施为由处理器，如数字信号处理器或微处理器执行的软件，或者被实施为硬件，或者被实施为集成电路，如专用集成电路。这样的软件可以分布在计算机可读介质上，计算机可读介质可以包括计算机存储介质(或非暂时性介质)和通信介质(或暂时性介质)。如本领域普通技术人员公知的，术语计算机存储介质包括在用于存储信息(诸如计算机可读指令、数据结构、程序模块或其他数据)的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于RAM、ROM、EEPROM、闪存或其他存储器技术、CD-ROM、数字多功能盘(DVD)或其他光盘存储、磁盒、磁带、磁盘存储或其他磁存储装置、或者可以用于存储期望的信息并且可以被计算机访问的任何其他的介质。此外，本领域普通技术人员公知的是，通信介质通常包含计算机可读指令、数据结构、程序模块或者诸如载波或其他传输机制之类的调制数据信号中的其他数据，并且可包括任何信息递送介质。

Claims (30)

1.一种规则下发的方法，包括：
控制面功能实体确定终端向用户面功能实体发起新业务，其中，所述新业务为所述用户面功能实体未安装规则的业务；
所述控制面功能实体将所述新业务的规则发送至所述用户面功能实体。
2.如权利要求1所述的方法，其特征在于，所述控制面功能实体确定终端向用户面功能实体发起新业务之前，所述方法还包括：
所述控制面功能实体预先将常用业务的规则发送至所述用户面功能实体。
3.如权利要求2所述的方法，其特征在于，所述控制面功能实体预先将所述常用业务的规则发送至所述用户面功能实体之前，所述方法还包括：所述控制面功能实体采用如下方式中的至少之一确定常用业务：
根据接收到的配置信息确定所述常用业务；
根据业务相关的全局统计数据进行统计排名，确定所述常用业务；
根据用户上网行为记录确定所述常用业务。
4.如权利要求1所述的方法，其特征在于，所述控制面功能实体确定终端向用户面功能实体发起新业务之前，所述方法还包括：
所述控制面功能实体指示所述用户面功能实体创建一个或多个新业务探测器，所述新业务探测器用于检测所述用户面功能实体未安装规则的业务。
5.如权利要求4所述的方法，其特征在于，所述新业务探测器用于探测如下业务中的至少之一：
默认承载业务、专有承载业务、动态规则业务。
6.如权利要求4所述的方法，其特征在于，所述新业务探测器包含预设匹配参数的报文匹配规则。
7.如权利要求6所述的方法，其特征在于，所述报文匹配规则包括不指定应用标识的报文检测规则PDR，所述不指定应用标识的PDR比指定应用标识的PDR的优先级低。
8.如权利要求7所述的方法，其特征在于，
所述不指定应用标识的PDR与设置有启动触发器的用量上报规则URR相关联，所述启动触发器用于触发新业务识别上报。
9.如权利要求7所述的方法，其特征在于，
所述不指定应用标识的PDR与设置有缓存操作的转发行为规则FAR相关联。
10.如权利要求1～9中任意一项所述的方法，其特征在于，所述控制面功能实体确定终端向用户面功能实体发起新业务，包括：
所述控制面功能实体接收所述用户面功能实体发送的新业务识别上报通知，根据所述新业务识别上报通知确定终端向所述用户面功能实体发起新业务。
11.如权利要求1～9中任意一项所述的方法，所述控制面功能实体将所述新业务的规则发送至所述用户面功能实体，包括：
所述控制面功能实体通过会话修改请求向所述用户面功能实体发送所述新业务的规则。
12.如权利要求11所述的方法，其特征在于，所述方法还包括：
所述控制面功能实体通过所述会话修改请求指示更新设置有启动触发器的URR，以重置所述启动触发器。
13.一种规则接收的方法，包括：
用户面功能实体确定终端发起新业务，其中，所述新业务为所述用户面功能实体未安装规则的业务；
所述用户面功能实体从控制面功能实体获取所述新业务的规则并安装。
14.如权利要求13所述的方法，其特征在于，所述用户面功能实体确定终端发起新业务之前，还包括：
所述用户面功能实体接收所述控制面功能实体发送的常用业务的规则并安装。
15.如权利要求13所述的方法，其特征在于，所述用户面功能实体确定终端发起新业务之前，还包括：
所述用户面功能实体创建一个或多个新业务探测器，所述新业务探测器用于检测所述用户面功能实体未安装规则的业务。
16.如权利要求15所述的方法，其特征在于，所述新业务探测器用于探测如下业务中的至少之一：
默认承载业务、专有承载业务、动态规则业务。
17.如权利要求15所述的方法，其特征在于，所述用户面功能实体确定终端发起新业务，包括：
所述用户面功能实体接收所述终端发起的新业务的业务报文，通过所述新业务探测器检测所述业务报文，确定终端发起新业务。
18.如权利要求17所述的方法，其特征在于，所述新业务探测器包含预设匹配参数的报文匹配规则，所述通过所述新业务探测器检测所述业务报文，确定终端发起新业务，包括：
通过所述报文匹配规则对所述业务报文进行匹配，在匹配通过时，确定终端发起新业务。
19.如权利要求18所述的方法，其特征在于，所述报文匹配规则包括不指定应用标识的报文检测规则PDR，所述不指定应用标识的PDR比指定应用标识的PDR的优先级低。
20.如权利要求19所述的方法，其特征在于，
所述不指定应用标识的PDR与设置有启动触发器的用量上报规则URR相关联，所述启动触发器用于触发新业务识别上报。
21.如权利要求19所述的方法，其特征在于，所述不指定应用标识的PDR与设置有缓存操作的转发行为规则FAR相关联，所述用户面功能实体确定终端发起新业务之后，还包括：
所述用户面功能实体缓存所述新业务的业务报文。
22.如权利要求21所述的方法，其特征在于，所述用户面功能实体从控制面功能实体获取所述新业务的规则并安装之后，还包括：
所述用户面功能实体释放缓存的所述新业务的业务报文，重新匹配规则，按照所述新业务的规则执行。
23.如权利要求13～22中任意一项所述的方法，其特征在于，所述用户面功能实体从控制面功能实体获取所述新业务的规则并安装，包括：
所述用户面功能实体向所述控制面功能实体发送新业务识别上报通知；
所述用户面功能实体接收所述控制面功能实体发送的会话修改请求，所述会话修改请求携带所述新业务的规则。
24.如权利要求23所述的方法，其特征在于，所述方法还包括：
所述用户面功能实体根据所述会话修改请求的指示更新设置有启动触发器的URR，以重置所述启动触发器。
25.一种控制面功能实体，其特征在于，包括：
第一确定模块，用于确定终端向用户面功能实体发起新业务，其中，所述新业务为所述用户面功能实体未安装规则的业务；
下发模块，用于将所述新业务的规则发送至所述用户面功能实体。
26.一种用户面功能实体，其特征在于，包括：
第二确定模块，用于确定终端发起新业务，其中，所述新业务为所述用户面功能实体未安装规则的业务；
获取模块，用于从控制面功能实体获取所述新业务的规则并安装。
27.一种控制面功能实体，包括：存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如权利要求1～12中任意一项所述规则下发的方法。
28.一种用户面功能实体，包括：存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如权利要求13～24中任意一项所述规则接收的方法。
29.一种计算机可读存储介质，存储有计算机可执行指令，所述计算机可执行指令用于执行权利要求1～12中任意一项所述规则下发的方法。
30.一种计算机可读存储介质，存储有计算机可执行指令，所述计算机可执行指令用于执行权利要求13～24中任意一项所述规则接收的方法。
CN201811328913.0A 2018-11-09 2018-11-09 规则下发、接收的方法及功能实体 Active CN111181739B (zh)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CN201811328913.0A CN111181739B (zh) 2018-11-09 2018-11-09 规则下发、接收的方法及功能实体
EP19882750.3A EP4033699A4 (en) 2018-11-09 2019-10-24 PROCESS FOR SENDING AND RECEIVING RULE AND ASSOCIATED FUNCTION ENTITIES
PCT/CN2019/113083 WO2020093878A1 (zh) 2018-11-09 2019-10-24 规则下发、接收的方法及功能实体

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201811328913.0A CN111181739B (zh) 2018-11-09 2018-11-09 规则下发、接收的方法及功能实体

Publications (2)

Publication Number Publication Date
CN111181739A true CN111181739A (zh) 2020-05-19
CN111181739B CN111181739B (zh) 2023-02-28

Family

ID=70610812

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201811328913.0A Active CN111181739B (zh) 2018-11-09 2018-11-09 规则下发、接收的方法及功能实体

Country Status (3)

Country Link
EP (1) EP4033699A4 (zh)
CN (1) CN111181739B (zh)
WO (1) WO2020093878A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115915045A (zh) * 2022-11-08 2023-04-04 之江实验室 一种用于降低用户面和控制面信令交互负载的方法及装置
WO2024098597A1 (zh) * 2022-11-08 2024-05-16 之江实验室 一种用于用户面和控制面分离架构的信令交互方法及装置

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210250839A1 (en) * 2020-02-07 2021-08-12 Parallel Wireless, Inc. FAR ID Provisioning During Dedicated Bearer Creation

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101119211A (zh) * 2007-09-18 2008-02-06 中兴通讯股份有限公司 一种公平用户策略的业务实现方法
CN101222413A (zh) * 2007-01-09 2008-07-16 华为技术有限公司 业务流程中的处理方法及系统
CN102075900A (zh) * 2009-11-23 2011-05-25 中兴通讯股份有限公司 一种实现用量监测控制的方法及系统
CN103491517A (zh) * 2012-06-13 2014-01-01 电信科学技术研究院 一种pcc规则获取方法及设备
CN105828310A (zh) * 2015-01-04 2016-08-03 中国移动通信集团公司 一种数据业务的计费方法及设备、系统
US20180097700A1 (en) * 2015-03-31 2018-04-05 Telefonaktiebolaget Lm Ericsson (Publ) Selective Inactivation of Control Rules Parameters

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015096005A1 (zh) * 2013-12-23 2015-07-02 华为技术有限公司 消息处理方法和网关
CN107302441B (zh) * 2016-04-14 2020-06-30 中国移动通信有限公司研究院 信息处理方法、装置及服务器
CN107547212A (zh) * 2016-06-24 2018-01-05 中兴通讯股份有限公司 一种基于分离架构的计费方法、装置和系统
WO2018195803A1 (zh) * 2017-04-26 2018-11-01 华为技术有限公司 一种报文处理方法及相关设备

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101222413A (zh) * 2007-01-09 2008-07-16 华为技术有限公司 业务流程中的处理方法及系统
CN101119211A (zh) * 2007-09-18 2008-02-06 中兴通讯股份有限公司 一种公平用户策略的业务实现方法
CN102075900A (zh) * 2009-11-23 2011-05-25 中兴通讯股份有限公司 一种实现用量监测控制的方法及系统
CN103491517A (zh) * 2012-06-13 2014-01-01 电信科学技术研究院 一种pcc规则获取方法及设备
CN105828310A (zh) * 2015-01-04 2016-08-03 中国移动通信集团公司 一种数据业务的计费方法及设备、系统
US20180097700A1 (en) * 2015-03-31 2018-04-05 Telefonaktiebolaget Lm Ericsson (Publ) Selective Inactivation of Control Rules Parameters

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115915045A (zh) * 2022-11-08 2023-04-04 之江实验室 一种用于降低用户面和控制面信令交互负载的方法及装置
CN115915045B (zh) * 2022-11-08 2023-09-22 之江实验室 一种用于降低用户面和控制面信令交互负载的方法及装置
WO2024098598A1 (zh) * 2022-11-08 2024-05-16 之江实验室 一种用于降低用户面和控制面信令交互负载的方法及装置
WO2024098597A1 (zh) * 2022-11-08 2024-05-16 之江实验室 一种用于用户面和控制面分离架构的信令交互方法及装置

Also Published As

Publication number Publication date
CN111181739B (zh) 2023-02-28
EP4033699A4 (en) 2022-12-28
WO2020093878A1 (zh) 2020-05-14
EP4033699A1 (en) 2022-07-27

Similar Documents

Publication Publication Date Title
US11265226B2 (en) Service management method and apparatus thereof
US20180262625A1 (en) System and method for account level maximum bit rate enforcement
US9769326B2 (en) Charging method and device
US9998343B2 (en) Selective event reporting in a mobile telecommunications network
US11032433B2 (en) Charging method, apparatus, and system
US8917600B2 (en) Technique for introducing a real-time congestion status in a policy decision for a cellular network
CN111181739B (zh) 规则下发、接收的方法及功能实体
CN104507126B (zh) 一种实现无线网络QoS管理的方法及装置
CN109996216B (zh) 订阅请求处理方法、网络实体及能力开放平台
WO2012083789A1 (zh) 资源分配处理方法、装置和网络服务系统
US10448224B1 (en) Proactive overload handling on real-time systems
US20220264358A1 (en) Bearer Processing Method and System, and Related Apparatus
CN108011725B (zh) 一种策略控制方法、装置及系统
WO2016061788A1 (en) Telecommunications system and method
EP3618468B1 (en) Wireless communication method and device
JP6271719B2 (ja) データ接続のためのオンデマンドＱｏＳ
CN108270808B (zh) 一种实现应用检测与控制的方法、装置和系统
US20170026524A1 (en) Charging method and apparatus
US11601867B2 (en) Method and device for managing an overload of a network core controlling a mobile access network
CN115299097A (zh) 用于qos通知的方法和网络节点
US11252568B1 (en) Method and apparatus for rearranging traffic data
US10257879B2 (en) Method for simplifying the control session of a user session
WO2024026877A1 (en) Policy enhancement for quick user datagram protocol international connection application
US20240015250A1 (en) Method and apparatus for providing a pre-paid service in a cellular communication network
JP6933883B2 (ja) 情報処理装置、情報処理方法、およびプログラム

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant