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

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

Info

Publication number
WO2020093878A1
WO2020093878A1 PCT/CN2019/113083 CN2019113083W WO2020093878A1 WO 2020093878 A1 WO2020093878 A1 WO 2020093878A1 CN 2019113083 W CN2019113083 W CN 2019113083W WO 2020093878 A1 WO2020093878 A1 WO 2020093878A1
Authority
WO
WIPO (PCT)
Prior art keywords
functional entity
new service
plane functional
service
rules
Prior art date
Application number
PCT/CN2019/113083
Other languages
English (en)
French (fr)
Inventor
夏勇
顾晓蕴
黄正刚
侯利昌
林凯
Original Assignee
中兴通讯股份有限公司
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 中兴通讯股份有限公司 filed Critical 中兴通讯股份有限公司
Priority to EP19882750.3A priority Critical patent/EP4033699A4/en
Publication of WO2020093878A1 publication Critical patent/WO2020093878A1/zh

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

Definitions

  • Embodiments of the present disclosure relate to, but are not limited to, a method for issuing rules, a method for receiving rules, a control plane functional entity, a user plane functional entity, and a computer-readable storage medium.
  • PCRF Policy and Charging Functions
  • PCF Policy Control Function
  • SMF SMF
  • Control and User Plane Separation control plane and user plane are separated
  • U plane User Plane, user plane
  • media side how can a large number of rules for a certain access user of the C plane (Control Plane, control plane) be delivered to the U plane (User Plane, user plane) , Also known as the media side)?
  • PFCP Packet Forwarding Control Plane, Packet Forwarding Control Plane
  • Session “Establishment” Request session establishment request
  • PDR Packet Detection Rules
  • FAR Forwarding Action Rule
  • URR User Reporting Rule
  • QER QoS Enforcement Rule, quality of service enforcement rule
  • An embodiment of the present disclosure provides a method for issuing rules, including: the control plane functional entity determines that the terminal initiates a new service to the user plane functional entity, where the new service is a service where the user plane functional entity has no rules installed; The control plane functional entity sends the rules of the new service to the user plane functional entity.
  • An embodiment of the present disclosure also provides a method for receiving rules, including: the user plane functional entity determines that the terminal initiates a new service, wherein the new service is a service where the user plane functional entity does not install rules; Obtain and install the rules of the new service from the control plane functional entity.
  • An embodiment of the present disclosure also provides a control plane functional entity, including: a first determining module, configured to determine that the terminal initiates a new service to the user plane functional entity, where the new service is a rule that the user plane functional entity does not install rules Business; delivery module, used to send the rules of the new business to the user plane functional entity.
  • a control plane functional entity including: a first determining module, configured to determine that the terminal initiates a new service to the user plane functional entity, where the new service is a rule that the user plane functional entity does not install rules Business; delivery module, used to send the rules of the new business to the user plane functional entity.
  • An embodiment of the present disclosure also provides a user plane functional entity, including: a second determining module, configured to determine that the terminal initiates a new service, wherein the new service is a business where the user plane functional entity does not install rules; an obtaining module, It is used to obtain and install the rules of the new service from the control plane functional entity.
  • An embodiment of the present disclosure also provides a control plane functional entity, including: a memory, a processor, and a computer program stored on the memory and executable on the processor.
  • the processor implements the computer program under the rule Hair method.
  • An embodiment of the present disclosure also provides a user plane functional entity, including: a memory, a processor, and a computer program stored on the memory and executable on the processor, and the processor realizes the rule reception when the processor executes the computer program Methods.
  • Embodiments of the present disclosure also provide a computer-readable storage medium that stores computer-executable instructions, and the computer-executable instructions are used to execute the method for issuing the rule.
  • An embodiment of the present disclosure also provides a computer-readable storage medium that stores computer-executable instructions, and the computer-executable instructions are used to execute the method for receiving the rule.
  • FIG. 1 is a flowchart of a method for issuing rules according to an embodiment of the present disclosure
  • FIG. 2 is a flowchart of a method for issuing rules according to another embodiment of the present disclosure
  • FIG. 3 is a flowchart of a method for issuing rules according to yet another embodiment of the present disclosure.
  • FIG. 5 is a flowchart of step 402 in FIG. 4;
  • FIG. 6 is a flowchart of a method for receiving rules according to another embodiment of the present disclosure.
  • FIG. 7 is a flowchart of a method for receiving rules according to yet another embodiment of the present disclosure.
  • PCF PCF issues a predefined rule group to specify user rules
  • FIG. 11 is a flowchart of Application Example 4 of the present disclosure (the network side initiates the establishment of a proprietary bearer (QFI));
  • PCF PCF dynamic rule for sending flow information
  • Example 13 is a flowchart of Application Example 6 of the present disclosure (manual configuration as a common service identification of a user group);
  • Example 14 is a flowchart of Application Example 7 of the present disclosure (the system automatically generates a business ranking as a common service identification of a user group);
  • 15 is a flowchart of an application example 8 of the present disclosure (using peripherals to save user preference data as user common service identification);
  • 16 is a schematic diagram of the composition of the control plane functional entity of the embodiment of the present disclosure.
  • 17 is a schematic diagram of the composition of the user plane functional entity of the embodiment of the present disclosure.
  • FIG. 19 is a schematic diagram of the composition of a user plane functional entity according to another embodiment of the present disclosure.
  • the C surface may only issue the rules of commonly used services to the U surface, and for the business (new business) where the C surface is not issued to the U surface to create rules, a strategy of "assignment" installation rules is adopted , That is, users use this service, and then install the relevant rules (may include business-related PDR, FAR, URR, QER).
  • the C side may not issue rules for common services, that is, do not specify common services.
  • controller functional entity including:
  • Step 101 The control plane functional entity determines that the terminal initiates a new service to the user plane functional entity, where the new service is a service where the user plane functional entity has no rules installed.
  • control plane functional entity may be PCRF or PCF
  • user plane functional entity may be PGW or SMF
  • control plane functional entity receives the new service identification report notification sent by the user plane functional entity, and determines that the terminal initiates a new service to the user plane functional entity according to the new service identification report notification.
  • the new service identification report notification may be, but not limited to, a PFCP Session Report (session report) message.
  • Step 102 The control plane functional entity sends the rules of the new service to the user plane functional entity.
  • control plane functional entity may directly determine the rules of the new service, or may interact with other network elements such as OCS (Online Charging System) and other network elements (or NF (Network Function) to determine the location State the rules of the new business.
  • OCS Online Charging System
  • NF Network Function
  • control plane functional entity sends the rules of the new service to the user plane functional entity through a session modification request.
  • the session modification request may be, but not limited to, a PFCP Modify Request message.
  • step 101 it may further include:
  • Step 201 The control plane functional entity sends rules of common services to the user plane functional entity in advance.
  • a large number of rules planned by operators for users are for various specific services, that is, different AppIDs (application identification). Users generally do not use all of these services (at least not all at once), and there are several common services. Based on this actual situation, when the C plane does not know which services the user will use, there is no need to issue all the business rules to the U plane, only need to distribute the common business, so as to ensure that a large number of users commonly used business The rule hit rate, while avoiding the situation that the signaling length is too long due to too many rules issued. In special cases, the C-plane may not be issued to the U-plane for installation with a specific business rule, that is, no common service is specified.
  • control plane functional entity pre-delivers the rules of common services to the user plane functional entity through the Sx (N4) port.
  • the method further includes: the control plane function entity determines common services, which may include but not limited to the following ways and combinations thereof:
  • the global statistics related to specific services are statistically ranked and applied to all individual users, so that common services of access users can be automatically determined.
  • This method uses external devices to store data such as user online behaviors and Get data interactively.
  • step 101 it may further include:
  • control plane functional entity instructs the user plane functional entity to create one or more new service detectors, and the new service probe is used to detect that the user plane functional entity does not install regular services.
  • step 201 and step 301 can be executed at the same time, that is, the control plane functional entity instructs the user plane functional entity to create a new service detector while issuing rules of common services.
  • the new service detector can notify the control plane functional entity of the specific detection information after detecting the new service.
  • the new business detector can be used repeatedly. After completing the installation of a new business rule, the detection function can be resumed to continue to detect new business without a new installed rule.
  • the packet matching rule includes a PDR (application upstream and downstream) that does not specify an application ID (Application ID), and the PDR that does not specify an application ID has a lower priority than the PDR that specifies an application ID.
  • the PDR that does not specify an application identifier is associated with a URR that is provided with a start trigger, and the start trigger is used to trigger a new service identification report.
  • control plane functional entity instructs to update the URR provided with a start trigger through the session modification request to reset the start trigger.
  • the PDR that does not specify an application identifier is associated with a FAR that is provided with a cache operation.
  • the new service detector is used to detect at least one of the following services:
  • the new service detector includes a message matching rule with preset matching parameters.
  • the new service detector can simultaneously set different SDF (Service Data) (Service Data Flow) in the PDI (Packet Detection Information) according to different application scenarios (can be wildcarded, or no SDF) as the default Bearer, proprietary bearer, PCC (Policy Control and Charging, policy control and charging) dynamic rules, etc. to detect new services.
  • SDF Service Data
  • PDI Packet Detection Information
  • PCC Policy Control and Charging, policy control and charging
  • the control plane functional entity can issue multiple new business detectors to be responsible for their detection.
  • the user rules for issuing U planes can be reasonably handled, which can not only prevent excessive long signaling, but also avoid the use of a large number of inter-CU signaling, while saving C and U planes.
  • the operation uses resources to improve U-plane forwarding performance. It avoids the situation that the system cannot be used when there are many business divisions in actual commercial use, guarantees the normal use of user services, and ensures the correct charging and control of user services by the core network.
  • the method for receiving rules according to an embodiment of the present disclosure which is applied to a user plane functional entity, includes:
  • step 401 the user plane functional entity determines that the terminal initiates a new service, where the new service is a service for which the user plane functional entity has no rules installed.
  • the user plane functional entity determines that the terminal initiates a new service according to the service message of the new service initiated by the terminal.
  • Step 402 The user plane functional entity obtains and installs the rules of the new service from the control plane functional entity.
  • the step 402 may include:
  • Step 501 The user plane functional entity sends a new service identification report notification to the control plane functional entity.
  • the new service identification report notification may be, but not limited to, a PFCP Session Report message.
  • Step 502 the user plane functional entity receives a session modification request sent by the control plane functional entity, and the session modification request carries the rules of the new service.
  • the session modification request may be, but not limited to, a PFCP Modify Request message.
  • the method further includes:
  • Step 601 The user plane functional entity receives and installs rules of common services sent by the control plane functional entity.
  • the rules of common services sent by the control plane functional entity can be received through the Sx (N4) port.
  • the rule hit rate of the common services of a large number of users can be ensured, and at the same time, the situation that the signaling length is excessively long due to too many issued rules is avoided.
  • the method further includes:
  • Step 701 the user plane functional entity creates one or more new service detectors, and the new service probe is used to detect that the user plane functional entity does not install a regular service.
  • the user plane functional entity may create one or more new business detectors according to the instructions of the control plane functional entity, or may automatically create one or more new business detectors according to preset rules.
  • steps 601 and 701 can be executed simultaneously, that is, the control plane functional entity instructs the user plane functional entity to create a new service while issuing rules of common services detector.
  • the new service detector can notify the control plane functional entity of the specific detection information after detecting the new service.
  • the user plane functional entity determining that the terminal initiates a new service includes:
  • the user plane functional entity receives a service message of a new service initiated by the terminal, detects the service message through the new service detector, and determines that the terminal initiates a new service.
  • the new service detector includes a message matching rule with preset matching parameters.
  • the detecting of the service message by the new service detector to determine that the terminal initiates a new service includes:
  • the service message is matched by the message matching rule, and when the match is passed, it is determined that the terminal initiates a new service.
  • the packet matching rule includes a PDR (application upstream and downstream) that does not specify an application ID (Application ID), and the PDR that does not specify an application ID has a lower priority than the PDR that specifies an application ID.
  • the PDR that does not specify an application identifier is associated with a URR provided with a start trigger, and the start trigger is used to trigger a new service identification report.
  • the user plane functional entity receives a service message of a new service initiated by the terminal, and determines that when the terminal initiates a new service, a trigger is triggered to trigger new service identification and reporting, and the user plane functional entity reports to the control plane
  • the functional entity sends a new service identification report notification.
  • the PDR that does not specify an application identifier is associated with a FAR set with a cache operation.
  • the user plane functional entity caches the service message of the new service.
  • the method further includes:
  • the user plane functional entity releases the cached service message of the new service, rematches the rules, and executes according to the rules of the new service.
  • the session modification request also instructs to update the URR provided with the activation trigger, and the user plane function entity updates the URR according to the instruction of the session modification request to reset the activation trigger Device. Therefore, the new service detector can be used repeatedly. After completing the installation of a new service rule, the detection function can be resumed to continue to detect new services with new rules not installed.
  • the new service detector is used to detect at least one of the following services:
  • the new service detector can simultaneously set different SDFs in the PDI (can be wildcarded, or no SDF) according to different application scenarios to detect new services for default bearers, proprietary bearers, PCC dynamic rules, and so on.
  • the user rules for issuing U planes can be reasonably handled, which can not only prevent excessive long signaling, but also avoid the use of a large number of inter-CU signaling, while saving C and U planes.
  • the operation uses resources to improve U-plane forwarding performance. It avoids the situation that the system cannot be used when there are many business divisions in actual commercial use, guarantees the normal use of user services, and ensures the correct charging and control of user services by the core network.
  • Application Example 1 includes the following steps:
  • Step 801 a user session is created, and C initiates a request to establish an Sx (N4) session to the U plane.
  • the user has a high degree of business refinement and many rules. If all are installed on the U plane at one time, hundreds of PDR rules may be required. For the sake of simplicity, it is assumed that there is only one service commonly used by users, that is, the service represented by AppID1. For this service, uplink and downlink PDR1 and PDR2 are created.
  • the PDI of PDR1 includes Local F-TEID (Full Qualified Tunnel Endpoint Identifier. Tunnel information such as tunnel endpoint ID), Application ID (application ID, AppID1 here), PDI of PDR2 includes UE IP address, Application ID (here AppID1).
  • PDRi PDI includes tunnel information such as Local F-TEID, no Application ID (that is, wildcard all Application IDs), PDRj PDI includes UE IP address, no Application ID (that is, wildcard all Application IDs).
  • the priority of PDRi and PDRj is lower than that of PDR1 and PDR2 of a specific AppID1 service.
  • PDRi and PDRj are associated with URRn, and URRn installs a Start trigger.
  • PDRi and PDRj are associated with FAR rules for caching operations, and BAR rules indicate specific cache parameters. These protocols have been specifically described and will not be described anymore. Of the new business detectors are similarly related to cache related FAR and BAR.
  • Step 802 a session establishment response. At this time, the session establishment is successful.
  • the relationship between the session and each PDR, FAR, and URR is shown in FIG. 8.
  • QER is simplified, and the principle is the same.
  • Step 803 the service flow initiating AppID1 passes through the U plane, matches PDR1 and PDR2, and is executed according to the corresponding FAR1, FAR2, and URR1 rules.
  • Step 804 the terminal initiates the service flow of AppID2 to reach the U plane, and the U plane has an application identification function, which can identify this service flow as AppID2.
  • Matching PDRi or PDRj triggers the start report of URRn in step 805, and the service flow message is cached in the U plane.
  • step 805 when the U-Rem initiates the start report, the U-face fills in the Application detection information with the Application ID of AppID2, and reports the service flow information.
  • step 806 the C-plane responds to the U-plane's session report request.
  • step 807 when receiving the Start report of URRn in step 805, the C plane has sensed the arrival of the new service AppID2, and knows that the business rules of AppID2 have not yet been issued to the U plane. After that, immediately initiate a session modification request to the U-plane.
  • the session modification request includes the creation of upstream and downstream PDR3 and PDR4 for the AppID2 service.
  • the PDI of PDR3 includes tunnel information such as Local F-TEID, Application ID (here is AppID2), and the PDI of PDR4 includes UE IP address and Application ID (here is AppID2) .
  • PDR3 and PDR4 have higher priority than PDRi and PDRj.
  • step 808 the U-plane responds to the session modification request initiated by the C-plane.
  • the relationship between the rules in this session is shown in FIG. 8.
  • PDR3 and PDR4 have been successfully installed and have higher priority than PDRi and PDRj.
  • URR2 is also successfully installed and associated with the PDR of the AppID2 service.
  • PDRi, PDRj, and URRn like the flow after step 802, continue to detect services that are not used or have no rules installed.
  • step 809 the U-plane releases the packets buffered in step 804 and executes them again according to the rules under the session.
  • These AppID2 packets will match PDR3 and PDR4, and the usage statistics will be collected by URR2. Subsequent AppID2 business will have rules to follow, no longer need to request C-side installation rules.
  • Application Example 2 includes the following steps:
  • step 901 plane C receives a session creation request.
  • Step 902 C initiates CCR (I) (Credit Control Request) (type of initial request) for PCRF (PCF).
  • Step 903 PCRF (PCF) responds to CCA (I) and issues a predefined rule group name in CCA (I).
  • This predefined rule group name corresponds to 99 predefined rules configured on the C-plane.
  • Each predefined rule Billing control strategy for a specific service (specified AppID).
  • Step 904 the C side receives the CCA (I), finds 99 predefined rules of the user according to the predefined rule group name, and selects the predefined rules of the two common services from the configuration designation (the common services here are AppID1 and AppID2) , Convert it to N4 (Sx) port rules and send it to U plane through Session Establishment Request.
  • PDR1, PDR2, PDR3, PDR4 represent the upstream and downstream PDR of AppID1 and AppID2 services respectively, and specify their forwarding rules FAR1 FAR2, specify their usage statistics URR1.
  • PDRi and PDRj are issued as new service detectors, and URRn is its Start trigger.
  • Step 905 the U-plane responds to the Session-Establishment request of the C-plane.
  • Step 906 the C-plane responds to the session creation request successfully.
  • step 907 the terminal initiates a common service AppID1, matches PDR1 and PDR2 in uplink and downlink, and is forwarded by FAR1 and FAR2.
  • the usage statistics are included in URR1, and the service is normal.
  • step 908 the terminal initiates a common service AppID2, matches PDR3 and PDR4 in uplink and downlink, and is forwarded by FAR1 and FAR2.
  • the usage statistics are included in URR1, and the service is normal.
  • step 909 the terminal initiates the unused service AppID3, and the upstream and downstream match PDRi and PDRj, triggering step 910, and the message is cached.
  • the new service detector finds that the new service AppID3 arrives, and the U initiates a Session report request to the C plane, and reports the Start trigger of URRn, including the detection information Application ID is AppID3 and flow information.
  • Step 911 the C plane responds to the Session Report request of the U plane.
  • step 912 when receiving the Start report of URRn in step 910, the C plane has sensed the arrival of the new service AppID3 and knows that the business rules of AppID3 have not been issued to the U plane, so it responds to the U plane session in step 911 After reporting the request, immediately initiate a session modification request to the U-plane.
  • the session modification request includes the creation of upstream and downstream PDR5 and PDR6 for the AppID3 service. PDR5 and PDR6 have higher priority than PDRi and PDRj. And create an independent usage statistics rule URR2 for the AppID3 service.
  • the forwarding rule FAR about AppID3 can be specified according to specific service characteristics, and no further explanation is given here.
  • URRn is also updated, and its Start trigger is restored to ensure that the next time a new service (appID1, AppID2, AppID3, or other services) arrives, it can also trigger URRn's Start report.
  • step 913 the U-plane responds to the session modification request initiated by the C-plane.
  • step 914 the U-plane releases the packets buffered in step 909 and executes them again according to the rules under the session.
  • These AppID3 packets will match PDR5 and PDR6, and the usage statistics will be collected by URR2.
  • Step 915 the service flow of the subsequent AppID3 will have rules to follow, and it is no longer necessary to request the C-plane to install the rules, and smoothly pass the U-plane.
  • step 916 the terminal initiates the unused service AppID4, and the upstream and downstream match PDRi and PDRj, triggering step 917, and the message is cached.
  • Step 917 the new service detector finds that the new service AppID4 arrives, and the U initiates a Session report request to the C plane, and reports the Start trigger of URRn, including the detection information Application ID is AppID4 and flow information.
  • Step 918 the C-plane responds to the U-plane Session Report request.
  • step 919 when receiving the Start report of URRn in step 917, the C plane has sensed the arrival of the new service AppID4, and knows that the business rules of AppID4 have not been issued to the U plane, so it responds to the U plane session in step 918 After reporting the request, immediately initiate a session modification request to the U-plane.
  • the session modification request includes the creation of upstream and downstream PDR7 and PDR8 for the AppID4 service. PDR7 and PDR8 have higher priority than PDRi and PDRj. And create independent usage statistics rule URR3 for AppID4 business.
  • URRn is also updated, and its Start trigger is restored to ensure that the next new service (services other than AppID1, AppID2, AppID3, and AppID4) will also trigger URRn's Start report.
  • Step 920 the U-plane responds to the session modification request initiated by the C-plane.
  • step 921 the U-plane releases the packets cached in step 916 and executes them again according to the rules under the session.
  • These AppID4 packets will match PDR7 and PDR8, and the usage statistics will be collected by URR3.
  • Step 922 the subsequent AppID4 business flow will have rules to follow, no longer need to request the C-plane to install the rules, and smoothly pass the U-plane.
  • Application Example 3 includes the following steps:
  • step 1001 plane C receives a session creation request.
  • Step 1002 C initiates a CCR (I) authentication request towards the OCS.
  • step 1003 the OCS responds to CCA (I), indicating successful authentication and allowing access.
  • Step 1004 C initiates a Session Request for the U-plane.
  • the rule of not sending common services that is, there are no common services, only new service detectors PDRi, PDRj, and Start trigger URRn are issued.
  • Step 1005 the U-plane responds to the Session-Establishment request of the C-plane.
  • Step 1006 the C-plane responds to the session creation request successfully.
  • step 1007 the terminal initiates the AppID1 service, and the upstream and downstream match PDRi and PDRj, triggering step 1008, and the packet is cached.
  • Step 1008 the new service detector finds that the new service AppID1 arrives, and U initiates a Session report request to the C plane, and reports the URRn Start trigger, including the detection information Application ID is AppID1 and flow information.
  • Step 1009 the C-plane responds to the U-plane Session Report request.
  • step 1010 when receiving the Start report of URRn in step 1008, plane C has sensed the arrival of the new service AppID1 and knows that the business rules of AppID1 have not been issued to the plane U. At the same time, according to the rules configured on the C plane, the service belongs to the RatingGroup1 rate group in the charging strategy, and RatingGroup1 has not been authorized by the OCS quota. So C initiates CCR (U) (type update request) for OCS to request quota authorization for RatingGroup1.
  • U type update request
  • step 1011 the OCS responds to the C-plane quota request and grants the quota in the CCA (U) to allow the user to use the RatingGroup1 service.
  • step 1012 according to the local policy of AppID1 available in plane C in step 1010, plus the RatingGroup1 quota authorization obtained from OCS in plane 1011, plane C can issue all the rules corresponding to AppID1. Therefore, C initiates a session modification request to the U-plane, creates uplink and downlink PDR1 and PDR2 for the AppID1 service, and creates URR1 for the RatingGroup1 service for usage statistics and quota control of the RatingGroup1 service including the AppID1 service. PDR1 and PDR2 are associated with URR1. Finally, in this session modification request, URRn is also updated, and its Start trigger is restored to ensure that the next time a new service (a service other than AppID1) arrives, it can also trigger URRn's Start report.
  • Step 1013 the U-plane responds to the session modification request initiated by the C-plane.
  • step 1014 the U-plane releases the buffered message in step 1007 and executes it again according to the rules under the session.
  • These AppID1 messages will match PDR1 and PDR2, and the usage statistics will be collected by URR1.
  • step 1015 the service flow of the subsequent AppID1 will have rules to follow, and it is no longer necessary to request the C-plane to install the rules, and smoothly pass the U-plane.
  • step 1016 the terminal initiates the AppID2 service, and the uplink and downlink match PDRi and PDRj, triggering step 1017, and the packet is cached.
  • Step 1017 the new service detector finds that the new service AppID2 arrives, and U initiates a Session report request to the C plane, and reports the URRn Start trigger, including the detection information Application ID is AppID2 and flow information.
  • Step 1018 the C-plane responds to the U-plane Session Report request.
  • step 1019 when receiving the Start report of URRn in step 1017, the C plane has sensed the arrival of the new service AppID2 and knows that the business rules of AppID2 have not been issued to the U plane. At the same time, according to the rules configured on the C side, the service belongs to the RatingGroup2 rate group in the charging strategy, and RatingGroup2 has not been authorized by the OCS quota. So C initiates CCR (U) for OCS to request quota authorization for RatingGroup2.
  • step 1020 the OCS responds to the C-plane quota request and grants the quota in the CCA (U) to allow the user to use the RatingGroup2 service.
  • step 1021 according to the local policy of AppID2 available in plane C in step 1019, plus the RatingGroup2 quota authorization obtained from OCS in plane 1020, plane C can issue all the rules corresponding to AppID2. Therefore, C initiates a session modification request to the U plane, creates upstream and downstream PDR3 and PDR4 for the AppID2 service, and creates URR2 for the RatingGroup2 for usage statistics and quota control of the RatingGroup2 service including the AppID2 service, and PDR3 and PDR4 are associated with URR2. Finally, in this session modification request, URRn is also updated, and its Start trigger is restored to ensure that when the next new service (services other than AppID1 and AppID2) arrives, URRn's Start report can also be triggered.
  • Step 1022 the U-plane responds to the session modification request initiated by the C-plane.
  • step 1023 the U-plane releases the packets buffered in step 1016 and executes them again according to the rules under the session.
  • These AppID2 packets will match PDR3 and PDR4, and the usage statistics will be collected by URR2.
  • Step 1024 the subsequent AppID2 business flow will have rules to follow, no longer need to request the C-side to install the rules, and smoothly pass through the U-side.
  • step 1025 the terminal initiates the AppID3 service, and the upstream and downstream match PDRi and PDRj, triggering step 1026, the packet is cached.
  • Step 1026 the new service detector finds that the new service AppID3 arrives, and the U initiates a Session report request to the C plane, and reports the Start trigger of URRn, including the detection information Application ID is AppID3 and flow information.
  • Step 1027 the C-plane responds to the U-plane Session Report request.
  • step 1028 when receiving the Start report of URRn in step 1026, plane C has sensed the arrival of the new service AppID3, and knows that the business rules of AppID3 have not been issued to plane U. At the same time, according to the rules configured on the C side, the service belongs to the RatingGroup1 rate group in the charging strategy, and RatingGroup1 has been authorized by the OCS quota, so the C side can already issue all the rules corresponding to AppID3. So C initiates a session modification request to the U plane, creates upstream and downstream PDR5 and PDR6 for the AppID3 service, and associates URR1. Finally, in this session modification request, URRn is also updated, and its Start trigger is restored to ensure that the next new service (services other than AppID1, AppID2, and AppID3) can also trigger Start reporting of URRn.
  • Step 1029 the U-plane responds to the session modification request initiated by the C-plane.
  • step 1030 the U-plane releases the packets buffered in step 1025 and executes them again according to the rules under the session. These AppID3 packets will match PDR5 and PDR6, and the usage statistics will be collected by URR1.
  • step 1031 the service flow of the subsequent AppID3 will have rules to follow, and it is no longer necessary to request the C plane to install the rule, and smoothly pass the U plane.
  • Application Example 4 includes the following steps:
  • step 1101 the C plane receives a session creation request.
  • Step 1102 C initiates a CCR (I) request to the PCRF (PCF).
  • Step 1103 PCRF (PCF) responds to CCA (I) successfully.
  • the C plane receives the CCA (I), initiates a SessionEstablishment request to the U plane according to the PCRF delivery parameters and local configuration, and installs the relevant rules (including new service detectors).
  • the rules installed here belong to the default bearer .
  • the installation content is similar to step 904 in Application Example 2.
  • Step 1105 the U-plane responds to the Session-Establishment request of the C-plane.
  • Step 1106 the C-plane responds to the session creation request successfully.
  • step 1107 the terminal uses the default bearer to initiate related services, which may be services with rules installed or services without rules.
  • step 1108 if the service initiated by the default bearer is a service with no rule installed, similar to step 910 to step 913 in application example 2, new business rules are installed, and the installed rules all belong to the default bearer.
  • the PCRF (PCF) specifies the flow information description of the dedicated bearer through a RAR request, and initiates the establishment of a dedicated bearer on the network side.
  • step 1110 the C-plane responds to the RAR request and returns a RAA response.
  • Step 1111 C sends a create bearer request to the front-end network element.
  • step 1112 plane C receives a bearer creation response from the front-end network element.
  • Step 1113 C initiates a session modification request to the U plane, where the C plane can optionally specify a common service for the dedicated bearer, that is, the service represented by AppID1, and create upstream and downstream PDR21 and PDR22 for this service, of which the PDI of PDR21 includes Tunnel information such as Local F-TEID, SDF (that is, dedicated flow message description), Application ID (here is AppID1), PDR22 PDI includes UE IP, SDF (that is, dedicated flow information description), Application ID (here It is AppID1).
  • the business dedicated to AppID uses URR21 as the usage statistics rule.
  • PDR2i's PDI includes tunnel information such as Local F-TEID, SDF (that is, dedicated flow information description), and no Application ID (ie Wildcard all Application IDs), PDR2j's PDI includes UE IP address, SDF (that is, dedicated stream message description), no Application ID (that is, all Application IDs).
  • the priority of PDR2i and PDR2j is lower than that of PDR21 and PDR22 dedicated to AppID1 services, but higher than the PDR priority of all default bearers.
  • step 1114 the U-plane responds to the C-plane session modification request.
  • Step 1115 the terminal initiates the service of AppID1 through the dedicated bearer, matches PDR21 and PDR22, and the usage statistics are included in URR21. Business is normally used.
  • step 1116 the terminal initiates the AppID2 service through the dedicated bearer, matching PDR2i and PDR2j, triggering step 1117, and the packet is cached.
  • Step 1117 the dedicated new service detector finds that the new service AppID2 arrives, and U initiates a Session report request to the C plane, and reports the Start trigger of URR2n, including the detection information Application ID is AppID2 and flow information.
  • Step 1118 the C-plane responds to the U-plane Session Report request.
  • step 1119 when receiving the Start report from URR2n in step 1117, plane C has sensed the arrival of the new service AppID2, and knows that the business rules of AppID2 have not been issued to the U plane, so it responds to the U plane session in step 1118 After reporting the request, immediately initiate a session modification request to the U-plane.
  • the session modification request includes the creation of upstream and downstream PDR23 and PDR24 for the AppID2 service. PDR23 and PDR24 have higher priority than PDR2i and PDR2j. And create independent usage statistics rule URR22 for AppID2 business.
  • URR2n is also updated, and its Start trigger is restored to ensure that when the new service (services other than AppID1 and AppID2) arrives next time, the start report of URR2n can also be triggered.
  • Step 1120 the U-plane responds to the session modification request initiated by the C-plane.
  • step 1121 the U-plane releases the packets cached in step 1116 and executes them again according to the rules under the session.
  • These dedicated AppID2 packets will match PDR23 and PDR24, and the usage statistics will be collected by URR22.
  • step 1122 the service flow of the AppID2 that will be subsequently uploaded will have rules to follow, and it is no longer necessary to request the C plane to install the rule, and smoothly pass the U plane.
  • Application Example 5 includes the following steps:
  • Step 1201 when the user session is created, the C plane instructs the U plane to create corresponding upstream and downstream PDR1, PDR2, associated URR1 for the AppID1 service on the default bearer; and creates corresponding upstream and downstream PDR3, PDR4, associated URR2 for the AppID2 service.
  • Step 1202 C faces a certain CCR (U) request initiated by PCRF (PCF).
  • Step 1203 The PCRF (PCF) responds to the CCR (U) request on the C plane, and issues a dynamic rule in the CCA (U) of the response.
  • This dynamic rule uses flow description information to specify certain services on the default bearer and requires compliance This flow describes the business of the information for special processing. However, this dynamic rule only specifies some rules, and does not specify, for example, the charging method.
  • Step 1204 after receiving the CCA (U), the C plane installs the dynamic rule according to the instructions of the PCRF (PCF), but finds that the specific service indicated by the flow description information specified by the dynamic rule cannot be determined (that is, the unique AppID cannot be determined), In this way, information such as the charging method configured on the C plane cannot be obtained according to the AppID, and part of the rule information not indicated in the dynamic rule cannot be supplemented, and the complete rule cannot be issued to the U plane. Therefore, the U-plane is instructed to create a new business detector for this dynamic rule, first detect the specific business, and then install the complete rule.
  • PCRF PCRF
  • PDR2i's PDI includes local F-TEID and other tunnel information
  • SDF that is, dynamic rule flow information description
  • no Application ID that is, all Application IDs
  • PDR2j's PDI includes UE IP address
  • SDF that is, dynamic rule flow information description
  • no Application ID that is, wildcard all Application IDs
  • the priority of PDR2i and PDR2j is higher than the PDR priority of wildcard SDF (or no SDF) on all default bearers.
  • PDR2i and PDR2j also belong to the default bearer PDR, but the priority is relatively high. Create URR2n as the Start trigger for the new business detector.
  • step 1205 the U-plane responds to the C-plane session modification request.
  • step 1206 the terminal initiates an AppID1 service that conforms to the description information of the dynamic rule flow, and matches PDR2i and PDR2j.
  • Step 1207 is triggered, and the packet is cached.
  • Step 1207 the dynamic ruled new service detector finds that the new service AppID1 arrives, and U initiates a Session report request to the C plane, and reports the Start trigger of URR2n, including the detection information Application ID is AppID1 and flow information.
  • Step 1208 the C-plane responds to the U-plane Session Report request.
  • step 1209 when receiving the Start report of URR2n in step 1207, the C-plane has sensed the arrival of the new service AppID1 in the dynamic rule, and knows that the business rule of the AppID1 in the dynamic rule has not been issued to the U-plane.
  • Step 1208 responds to the U-plane session reporting request, and immediately initiates a session modification request to the U-plane.
  • the session modification request includes the creation of upstream and downstream PDR21 and PDR22 for the AppID1 service in the dynamic rule. PDR21 and PDR22 have higher priority than PDR2i and PDR2j.
  • step 1210 the U-plane responds to the session modification request initiated by the C-plane.
  • step 1211 the U-plane releases the packets cached in step 1206 and executes them again according to the rules under the session.
  • These packets that meet the dynamic rules of AppID1 will match PDR21 and PDR22, and will be used by URR1 for usage statistics.
  • Step 1212 the subsequent AppID1 business flow that conforms to the description information of the dynamic rule flow will have rules to follow, and no longer needs to request the C-plane installation rule to smoothly pass the U-plane.
  • step 1213 the terminal initiates an AppID2 service that conforms to the description information of the dynamic rule flow, matching PDR2i and PDR2j, and triggering step 1214, the packet is cached.
  • the dynamic rule new service detector finds that the new service AppID2 arrives, and U initiates a Session report request to the C plane, and reports the Start trigger of URR2n, including the detection information Application ID is AppID2 and flow information.
  • Step 1215 the C-plane responds to the U-plane Session Report request.
  • Step 1216 when receiving the Start report of URR2n in step 1214, the C plane has sensed the arrival of the new service AppID2 in the dynamic rule and knows that the business rule of the AppID2 in the dynamic rule has not been issued to the U plane, Step 1215 responds to the U-plane session reporting request, and immediately initiates a session modification request to the U-plane.
  • the session modification request includes the creation of upstream and downstream PDR23 and PDR24 for the AppID2 service in the dynamic rule. PDR23 and PDR24 have higher priority than PDR2i and PDR2j. Because the usage statistics belong to the same bearer as the default service, PDR23 and PDR24 are associated with URR2, which is incorporated into the usage statistics of the same bearer AppID2.
  • URR2n is also updated, and its Start trigger is restored to ensure that this dynamic rule can also trigger URR2n's Start report when the new service (services other than AppID1 and AppID2) arrives next time.
  • step 1217 the U-plane responds to the session modification request initiated by the C-plane.
  • step 1218 the U-plane releases the packets cached in step 1213 and executes them again according to the rules under the session. These packets that meet the dynamic rules of AppID2 will match PDR23 and PDR24, and the usage statistics will be counted by URR2.
  • Step 1219 the subsequent AppID2 business flow that conforms to the description information of the dynamic rule flow will have rules to follow, and no longer needs to request the C-plane installation rule to smoothly pass the U-plane.
  • Application Example 6 includes the following steps:
  • Step 1301 Perform data configuration on the C-plane device and configure two common services, AppID1 and AppID2, respectively.
  • the number of common services depends on the situation. Here are two common services.
  • Step 1302 a user initiates a session creation request to plane C, requesting access to the device.
  • Step 1303, C initiates a PFCP session establishment request to the U plane, the request indicates the relevant rules of the installation services AppID1, AppID2, where AppID1, AppID2 are the two common services configured in step 1301.
  • the request also includes new business detectors.
  • Step 1304 the U-plane responds to the C-plane PFCP session establishment request.
  • Step 1305 the C-plane responds to the user-created session creation request.
  • Application Example 7 includes the following steps:
  • Step 1401 the system runs, performs statistical analysis on the data such as the types and frequencies of services used by the user group, and generates a ranking of the user group about the different services they use.
  • This ranking can be used as an identification of common services.
  • the ranking is AppID1, AppID2, AppID3, AppID4 ... in order.
  • This ranking can be automatically generated internally by the C surface.
  • step 1402 a user initiates a session creation request to plane C, requesting access to the device.
  • step 1403 C initiates a PFCP session establishment request to the U-plane.
  • the request indicates the relevant rules of the installation services AppID1 and AppID2.
  • AppID1 and AppID2 are the top two services in step 1401 as common services.
  • the request also includes new business detectors.
  • Step 1404 the U-plane responds to the C-plane PFCP session establishment request.
  • Step 1405 the C-plane responds to the user-created session creation request.
  • Application Example 8 includes the following steps:
  • Step 1501 a user accesses the mobile network and uses the mobile network to perform various services.
  • the core network devices mainly the C and U planes
  • step 1502 the user subsequently initiates a session creation request to plane C again to request access to the device, and plane C obtains the user's business preference data from an external device.
  • Step 1503, C initiates a PFCP session establishment request to the U plane, the request indicates the relevant rules of the installation service AppID1, AppID2, where AppID1, AppID2 is the user preference data obtained by the C plane from the external device in step 1502, that is, this user preference Common business.
  • the request also includes new business detectors.
  • Step 1504 the U-plane responds to the C-plane PFCP session establishment request.
  • Step 1505 the C-plane responds to the user-created session creation request.
  • an embodiment of the present disclosure also provides a control plane functional entity, including:
  • the first determination module 1601 is configured to determine that the terminal initiates a new service to the user plane functional entity, where the new service is a service where the user plane functional entity has no rules installed;
  • the issuing module 1602 is configured to send the rule of the new service to the user plane functional entity.
  • an embodiment of the present disclosure also provides a user plane functional entity, including:
  • the second determination module 1701 is configured to determine that the terminal initiates a new service, where the new service is a service where the user plane functional entity has no rules installed;
  • the obtaining module 1702 is used to obtain and install the rules of the new service from the control plane functional entity.
  • an embodiment of the present disclosure also provides a control plane functional entity, including: a memory 1801, a processor 1802, and a computer program 1803 stored on the memory 1801 and executable on the processor 1802, the processor 1802 implements the method for issuing the rule when the computer program is executed.
  • an embodiment of the present disclosure further provides a user plane functional entity, including: a memory 1901, a processor 1902, and a computer program 1903 stored on the memory 1901 and executable on the processor 1902, the processor In 1902, when the computer program 1903 is executed, the rule receiving method is implemented.
  • a user plane functional entity including: a memory 1901, a processor 1902, and a computer program 1903 stored on the memory 1901 and executable on the processor 1902, the processor In 1902, when the computer program 1903 is executed, the rule receiving method is implemented.
  • Embodiments of the present disclosure also provide a computer-readable storage medium that stores computer-executable instructions, and the computer-executable instructions are used to execute the method for issuing the rule.
  • An embodiment of the present disclosure also provides a computer-readable storage medium that stores computer-executable instructions, and the computer-executable instructions are used to execute the method for receiving the rule.
  • the above storage medium may include, but is not limited to: U disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), mobile hard disk, magnetic disk or optical disk, etc.
  • ROM read-only memory
  • RAM random access memory
  • mobile hard disk magnetic disk or optical disk, etc.
  • the user rules for issuing U planes can be reasonably handled, which can not only prevent excessive long signaling, but also avoid the use of a large number of inter-CU signaling, while saving C and U planes.
  • the operation uses resources to improve U-plane forwarding performance. It avoids the situation that the system cannot be used when there are many business divisions in actual commercial use, guarantees the normal use of user services, and ensures the correct charging and control of user services by the core network.
  • computer storage media includes both volatile and nonvolatile implemented in any method or technology for storing information such as computer readable instructions, data structures, program modules, or other data Sex, removable and non-removable media.
  • Computer storage media include but are not limited to RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage, magnetic cartridge, magnetic tape, magnetic disk storage or other magnetic storage devices Any other medium for storing desired information and accessible by a computer.
  • the communication medium generally contains computer readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transmission mechanism, and may include any information delivery medium .

Landscapes

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

Abstract

本公开实施例公开了一种规则下发、接收的方法及功能实体，其中，所述规则下发的方法，包括：控制面功能实体确定终端向用户面功能实体发起新业务，其中，所述新业务为所述用户面功能实体未安装规则的业务；所述控制面功能实体将所述新业务的规则发送至所述用户面功能实体。

Description

规则下发、接收的方法及功能实体
本公开要求享有2018年11月09日提交的名称为“规则下发、接收的方法及功能实体”的中国专利申请CN201811328913.0的优先权，其全部内容通过引用并入本文中。
技术领域
本公开实施例涉及但不限于一种规则下发的方法、规则接收的方法、控制面功能实体、用户面功能实体和计算机可读存储介质。
背景技术
目前一些商用局点对业务的细分化程度已经非常高，达到了数百，甚至达到上千种。这就决定了用于计费与控制的规则数量相当庞大。在商用场景中，如果不启用PCRF(Policy and Charging Rules Function，策略与计费规则功能)或PCF(Policy Control function，策略控制功能)，那么在PGW(PDN GateWay，公用数据网网关)或SMF(Session Management 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 Modification Request(会话修改请求)分批下发规则，也将导致在CU之间造成大量信令报文的情况，也是无法接受的。
发明内容
以下是对本文详细描述的主题的概述。本概述并非是为了限制权利要求的保护范围。
本公开实施例提供了一种规则下发的方法，包括：控制面功能实体确定终端向用户面功能实体发起新业务，其中，所述新业务为所述用户面功能实体未安装规则的业务；所述控制面功能实体将所述新业务的规则发送至所述用户面功能实体。
本公开实施例还提供一种规则接收的方法，包括：用户面功能实体确定终端发起新业务，其中，所述新业务为所述用户面功能实体未安装规则的业务；所述用户面功能实体从控制面功能实体获取所述新业务的规则并安装。
本公开实施例还提供一种控制面功能实体，包括：第一确定模块，用于确定终端向用户面功能实体发起新业务，其中，所述新业务为所述用户面功能实体未安装规则的业务；下发模块，用于将所述新业务的规则发送至所述用户面功能实体。
本公开实施例还提供一种用户面功能实体，包括：第二确定模块，用于确定终端发起新业务，其中，所述新业务为所述用户面功能实体未安装规则的业务；获取模块，用于从控制面功能实体获取所述新业务的规则并安装。
本公开实施例还提供一种控制面功能实体，包括：存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现所述规则下发的方法。
本公开实施例还提供一种用户面功能实体，包括：存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现所述规则接收的方法。
本公开实施例还提供一种计算机可读存储介质，存储有计算机可执行指令，所述计算机可执行指令用于执行所述规则下发的方法。
本公开实施例还提供一种计算机可读存储介质，存储有计算机可执行指令，所述计算机可执行指令用于执行所述规则接收的方法。
附图说明
图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 Detection Information，报文探测信息)中不同的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 IP address、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面发起Session Report请求，上报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)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。
通过本公开实施例，使得在CU分离的情况下，合理处理下发U面的用户规则，既可防止超长信令，又可避免使用大量CU之间信令，同时节省了C、U面的运行使用资源，提升了U面转发性能。避免了实际商用中业务划分较多情况下系统无法使用的情况，保证了用户业务的正常使用，保证了核心网对用户业务的正确计费与控制。
本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤、系统、装置中的功能模块/单元可以被实施为软件、固件、硬件及其适当的组合。在硬件实施方式中，在以上描述中提及的功能模块/单元之间的划分不一定对应于物理组件的划分；例如，一个物理组件可以具有多个功能，或者一个功能或步骤可以由若干物理组件合作执行。某些组件或所有组件可以被实施为由处理器，如数字信号处理器或微处理器执行的软件，或者被实施为硬件，或者被实施为集成电路，如专用集成电路。这样的软件可以分布在计算机可读介质上，计算机可读介质可以包括计算机存储介质(或非暂时性介质)和通信介质(或暂时性介质)。如本领域普通技术人员公知的，术语计算机存储介质包括在用于存储信息(诸如计算机可读指令、数据结构、程序模块或其他数据)的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于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中任意一项所述规则接收的方法。
PCT/CN2019/113083 2018-11-09 2019-10-24 规则下发、接收的方法及功能实体 WO2020093878A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP19882750.3A EP4033699A4 (en) 2018-11-09 2019-10-24 PROCESS FOR SENDING AND RECEIVING RULE AND ASSOCIATED FUNCTION ENTITIES

Applications Claiming Priority (2)

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

Publications (1)

Publication Number Publication Date
WO2020093878A1 true WO2020093878A1 (zh) 2020-05-14

Family

ID=70610812

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2019/113083 WO2020093878A1 (zh) 2018-11-09 2019-10-24 规则下发、接收的方法及功能实体

Country Status (3)

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

Cited By (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

Families Citing this family (2)

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

Citations (4)

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

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101222413B (zh) * 2007-01-09 2012-05-23 华为技术有限公司 业务流程中的处理方法及系统
CN100544266C (zh) * 2007-09-18 2009-09-23 中兴通讯股份有限公司 一种公平用户策略的业务实现方法
CN102075900B (zh) * 2009-11-23 2014-03-12 中兴通讯股份有限公司 一种实现用量监测控制的方法及系统
CN103491517B (zh) * 2012-06-13 2017-05-10 电信科学技术研究院 一种pcc规则获取方法及设备
CN105828310B (zh) * 2015-01-04 2020-02-04 中国移动通信集团公司 一种数据业务的计费方法及设备、系统
EP3278495B1 (en) * 2015-03-31 2020-06-03 Telefonaktiebolaget LM Ericsson (publ) Selective inactivation of control rules parameters

Patent Citations (4)

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

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
5G: "Technical Specification Group Core Network and Terminals;. '' Policy and Charging Control Signalling Flows and Quality of Service (QoS) Parameter Mapping", 3GPP TS 29.213 VI5.4.0, 30 September 2018 (2018-09-30), XP051573139 *
LTE: "Technical Specification Group Core Network and Terminals ;. '' Interface between the Control Plane and the User Plane Nodes; Stage 3 (Release 15", 3GPP TS 29.244 V15.3.0, 30 September 2018 (2018-09-30), XP051487290 *
See also references of EP4033699A4

Cited By (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

Also Published As

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

Similar Documents

Publication Publication Date Title
US9769326B2 (en) Charging method and device
WO2020093878A1 (zh) 规则下发、接收的方法及功能实体
US9647848B2 (en) Application charging method, device, and system
US10609225B2 (en) Charging method, apparatus, and system
US20220264358A1 (en) Bearer Processing Method and System, and Related Apparatus
WO2017092442A1 (zh) 策略和计费控制快速调整方法、装置及系统
EP2950581B1 (en) Policy server, policy enforcement device, and various methods for dynamically excluding active service add-ons from bearer throttling for user terminals
CN107396333B (zh) 策略和计费控制方法、系统及用量监测装置
US10257879B2 (en) Method for simplifying the control session of a user session
JP6933883B2 (ja) 情報処理装置、情報処理方法、およびプログラム
WO2016206071A1 (zh) 承载绑定的方法和相关设备
KR20100043571A (ko) 이동통신 시스템에서의 패킷 서비스 제공 방법

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19882750

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2019882750

Country of ref document: EP

Effective date: 20210609