WO2019157898A1 - 一种规则管理方法及设备 - Google Patents

一种规则管理方法及设备 Download PDF

Info

Publication number
WO2019157898A1
WO2019157898A1 PCT/CN2019/072032 CN2019072032W WO2019157898A1 WO 2019157898 A1 WO2019157898 A1 WO 2019157898A1 CN 2019072032 W CN2019072032 W CN 2019072032W WO 2019157898 A1 WO2019157898 A1 WO 2019157898A1
Authority
WO
WIPO (PCT)
Prior art keywords
network device
terminal
indication information
request
rule
Prior art date
Application number
PCT/CN2019/072032
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 EP19755077.5A priority Critical patent/EP3755022B1/en
Publication of WO2019157898A1 publication Critical patent/WO2019157898A1/zh
Priority to US16/994,044 priority patent/US20200374671A1/en

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/02Details
    • H04L12/14Charging, metering or billing arrangements for data wireline or wireless communications
    • H04L12/1403Architecture for metering, charging or billing
    • H04L12/1407Policy-and-charging control [PCC] architecture
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M15/00Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M15/00Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/66Policy and charging system
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M15/00Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/80Rating or billing plans; Tariff determination aspects
    • H04M15/8016Rating or billing plans; Tariff determination aspects based on quality of service [QoS]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • H04W28/06Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/24Accounting or billing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W8/00Network data management
    • H04W8/02Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/08Mobility data transfer
    • H04W8/12Mobility data transfer between location registers or mobility servers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W8/00Network data management
    • H04W8/22Processing or transfer of terminal data, e.g. status or physical capabilities
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M2215/00Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/32Involving wireless systems
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W76/00Connection management
    • H04W76/20Manipulation of established connections
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W92/00Interfaces specially adapted for wireless communication networks
    • H04W92/16Interfaces between hierarchically similar devices
    • H04W92/24Interfaces between hierarchically similar devices between backbone network devices

Definitions

  • the present application relates to the field of communications technologies, and in particular, to a rule management method and device.
  • the PCRF sends the QoS rule to the bearer binding and event report function (BBERF) through the Gxx interface, and the BBERF controls the QoS of the user; the PCRF will be the PCC.
  • the rule is sent to the policy and charging enforcement function (PCEF) through the Gx interface, and the PCEF controls the charging policy of the user service.
  • PCEF exists in a packet data network gateway (P-GW), and the BBERF exists in a serving gateway (S-GW), between the PCEF and the BBERF (that is, the P-GW and the S-GW). Between) via a PMIP-based S5/S8 interface.
  • the bearer binding function can also be performed by the PCEF, that is, the BBERF is not included in the S-GW.
  • the PCEF and the S-GW (ie, between the P-GW and the S-GW) are connected through an S5/S8 interface based on a General Packet Radio Service Tunneling Protocol (GTP).
  • GTP General Packet Radio Service Tunneling Protocol
  • the PCRF sends a PCC rule to the PCEF through the Gx interface.
  • the request sent by the PCRF to the PCEF is a policy and charging control rule installation and/or deletion request, that is, requesting to install or update the PCC rule.
  • the terminal is suspended.
  • the PCEF fails to update the terminal bearer, so the update fails to the PCRF, and the PCRF will re-issue the updated PCC rule. And/or QoS rule requests until the update is successful. Therefore, the signaling interaction on the Gx interface is very frequent and wastes a lot of resources.
  • the present application provides a method and a device for managing a rule, so as to avoid a waste of resources when network terminals continuously perform signaling interaction when the terminal cannot receive downlink data and needs to update the PCC rules and/or QoS rules of the terminal.
  • the application provides a rule management method, including:
  • the first network device receives the first indication information, where the first indication information is used to indicate that the terminal is currently in a suspended state; the first network device sends the second indication information to the second network device, where the second indication information is used to indicate the current terminal In the suspended state, the second network device determines, according to the second indication information, that the request for updating the policy and the charging control rule and/or the quality of service rule for the terminal is not sent.
  • the first network device may be a PCEF, or the first network device is a BBERF; and the second network device is a PCRF.
  • the update PCC rule and/or the QoS rule request is not sent temporarily, and therefore, the method existing in the prior art can be solved.
  • the network device continuously sends out a request for updating the PCC rules and/or QoS rules of the terminal, and the first network device continuously responds to the problem of the update failure, reduces signaling interaction, and helps improve resource utilization efficiency.
  • the network device sends the fourth indication information, where the fourth indication information is used to indicate the terminal state recovery, so that the second network device sends the first policy to the first when the policy and the charging control rule and/or the quality of service rule of the terminal need to be updated.
  • the network device sends a request to update the policy and charging control rules or quality of service rules of the terminal.
  • the first network device may further receive the first request sent by the second network device before sending the second indication information to the second network device, where the first request is used to request installation or update.
  • the policy and charging control rules or quality of service rules of the terminal may further receive the first request sent by the second network device before sending the second indication information to the second network device, where the first request is used to request installation or update.
  • the first network device receives the request for the update rule sent by the second network device when the terminal is suspended, the status information of the terminal is reported to the second network device, and the second network device is prevented from being repeatedly sent. Requests to update rules can reduce signaling interactions.
  • the first request is further used to request to subscribe to the information that the terminal returns from the suspended state to the normal state, so that the first network device returns from the suspended state to the normal state in the terminal.
  • Sending the status information of the terminal to the second network device; or the first request is further used to request to subscribe to status information of the terminal, so that the first network device occurs in the terminal status
  • the status information of the terminal is sent to the second network device when the change occurs.
  • the second network device may send the request for updating the rule and the request for subscribing the terminal status to the first network device by using the same signaling, thereby avoiding frequent signaling interaction, ensuring policy charging and service demand control for the terminal. Timeliness.
  • the first network device may further receive a second request sent by the second network device, where the second request is used to subscribe to the terminal, before sending the second indication information to the second network device.
  • Status information so that the first network device sends the status information of the terminal to the second network device when the status of the terminal changes; or the second request is used to subscribe to the terminal to return from the suspended state to the normal state.
  • the information is sent to the first network device to send the status information of the terminal to the second network device when the terminal returns from the suspended state to the normal state.
  • the foregoing embodiment helps the second network device to immediately obtain the terminal state restored information, thereby facilitating the second network device to immediately send a request for updating the terminal PCC rule or QoS rule after the terminal returns to the normal state, thereby ensuring The timeliness of policy charging and service demand control of the terminal.
  • the application provides a rule management method, including:
  • the first network device receives the first indication information, where the first indication information is used to indicate that the terminal is currently in a suspended state;
  • the first network device stores the policy and charging control rule or the quality of service rule requesting the update
  • the first network device When the first network device receives the second indication information, the first network device performs, on the terminal, the policy and charging control rule or the quality of service rule of the terminal that requests the update, the second The indication information is used to indicate the terminal status recovery.
  • the first network device if the first network device does not receive the second indication information within a preset time, the first network device sends the third indication information to the second network device,
  • the third indication information is used to indicate that the terminal is currently in a suspended state, so that the second network device does not send a request to update the policy and the charging control rule or the quality of service rule of the terminal.
  • the BBERF or the PCEF After receiving the request for updating the PCC rule or the QoS rule, the BBERF or the PCEF performs a new charging rule on the terminal according to the updated rule and provides a new quality of service. If the execution fails, the PCRF is sent to the PCRF. The escalation update failed, but the updated rules are not stored.
  • the BBERF or the PCEF after receiving the request for updating the PCC rule or the QoS rule, if the terminal is in the suspended state and cannot immediately execute the updated rule, the BBERF or the PCEF stores the updated rule first, and then stores the updated rule. Wait for the terminal to return to normal status before executing the new rule. This method can reduce signaling interaction and avoid resource waste.
  • the application provides a first network device, where the first network device includes a receiving unit and a sending unit.
  • the receiving unit and the sending unit are configured to perform the functions performed by the first network device in the foregoing first aspect or any possible implementation manner of the first aspect.
  • the application provides a second network device, where the second network device includes a receiving unit and a determining unit. Further, the second network device may further include a sending unit. The receiving unit, the determining unit, and the sending unit are configured to perform the functions performed by the second network device in the foregoing first aspect or any possible implementation manner of the first aspect.
  • the application provides a first network device, where the first network device includes a receiving unit, a storage unit, and an execution unit. Further, the first network device may further include a sending unit. The receiving unit, the storage unit, the executing unit, and the sending unit are configured to perform the functions performed by the first network device in any of the possible implementation manners of the second aspect or the second aspect.
  • the application provides a first network device, the first network device including a processor, and a memory and a transceiver respectively connected to the processor.
  • the processor is configured to read a function performed by the first network device in any possible implementation manner of the first aspect or the first aspect, where the computer program is pre-stored in the memory. For details, refer to the detailed description in the method embodiment. I will not repeat them here.
  • the present application provides a second network device, including a processor, and a memory and a transceiver respectively connected to the processor.
  • the processor is configured to read a function of the second network device in any one of the possible implementation manners of the first aspect or the first aspect, and the detailed description in the method embodiment. I will not repeat them here.
  • the application provides a first network device, the first network device including a processor, and a memory and a transceiver respectively connected to the processor.
  • the processor is configured to read a function performed by the first network device in any possible implementation manner of the second aspect or the second aspect, where the computer program is pre-stored in the memory. For details, refer to the detailed description in the method embodiment. I will not repeat them here.
  • the present application provides a computer readable storage medium having stored therein computer instructions that, when executed on a computer, cause the computer to perform as in the first aspect or the second aspect The function performed by the first network device.
  • the present application provides a computer readable storage medium having stored therein computer instructions that, when executed on a computer, cause the computer to perform any of the first aspect or the first aspect A function performed by a second network device in a possible implementation.
  • FIG. 1 is a schematic diagram of a PCC architecture provided by an embodiment of the present application.
  • FIG. 2 is a schematic flowchart of a rule management method according to an embodiment of the present disclosure
  • FIG. 3 is a PCC architecture including a BBERF according to an embodiment of the present application.
  • FIG. 5 is a second schematic diagram of a rule management method according to an embodiment of the present application.
  • FIG. 6 is a third schematic diagram of a rule management method according to an embodiment of the present disclosure.
  • FIG. 7 is a fourth schematic diagram of a rule management method according to an embodiment of the present application.
  • FIG. 8 is a fifth schematic diagram of a rule management method according to an embodiment of the present disclosure.
  • FIG. 9 is a sixth schematic diagram of a rule management method according to an embodiment of the present disclosure.
  • FIG. 10 is a schematic diagram of a rule management method according to an embodiment of the present application.
  • FIG. 11 is a schematic diagram VIII of a rule management method according to an embodiment of the present disclosure.
  • FIG. 12 is a schematic diagram of a rule management method according to an embodiment of the present application.
  • FIG. 13 is a schematic diagram 10 of a rule management method according to an embodiment of the present disclosure.
  • FIG. 14 is a schematic diagram of a rule management method according to an embodiment of the present application.
  • FIG. 15 is a schematic flowchart of another rule management method according to an embodiment of the present disclosure.
  • FIG. 16 is a second schematic flowchart of another rule management method according to an embodiment of the present disclosure.
  • FIG. 17 is a third schematic flowchart of another rule management method according to an embodiment of the present disclosure.
  • FIG. 18 is a schematic structural diagram of a first network device according to an embodiment of the present application.
  • FIG. 19 is a schematic structural diagram of a second network device according to an embodiment of the present disclosure.
  • FIG. 20 is a second schematic structural diagram of a first network device according to an embodiment of the present disclosure.
  • FIG. 21 is a second schematic structural diagram of a second network device according to an embodiment of the present disclosure.
  • FIG. 22 is a schematic structural diagram of another first network device according to an embodiment of the present disclosure.
  • FIG. 23 is a second schematic structural diagram of another first network device according to an embodiment of the present disclosure.
  • PCC rules and QoS rules can be executed for different terminals.
  • the PCRF sends the QoS rules formulated for the terminal to the BBERF.
  • the BBERF controls the QoS of the user, and sends the PCC rules formulated for the terminal to the PCEF, and the PCEF performs the PCC function.
  • the PCRF sends the PCC rules to the PCEF through policy and charging control rule installation and/or deletion requests.
  • the terminal cannot receive the downlink data at this time, and thus the service data flow (SDF) between the network device and the terminal cannot be updated. ) or QoS flow. Therefore, if the PCRF sends a request to the PCEF and/or BBERF to update the PCC rules and/or QoS rules when the terminal is in the suspended state, the PCEF and/or BBERF will not be able to perform the update operation and will return an update failure response to the PCRF. After receiving the update failure response, the PCRF will re-issue the update request until the update is successful, resulting in frequent signaling interactions and wasting signaling resources.
  • SDF service data flow
  • the embodiment of the present application provides a rule management method for solving the problem that signaling interaction is frequent and resources are wasted when the terminal hangs and requests to update PCC rules and/or QoS rules.
  • the rule management method provided by the embodiment of the present application can be applied to long term evolution (LTE), 5G, or other communication systems in the future, which is not limited in this application.
  • LTE long term evolution
  • the embodiment of the present application may be performed by a BBERF (S-GW), a PCEF (P-GW), or a PCRF.
  • S-GW BBERF
  • P-GW PCEF
  • PCRF PCRF
  • the policy may be performed by a policy control function (PCF) and a session management function (SMF).
  • PCF policy control function
  • SMF session management function
  • the first network device in the embodiment of the present application may be an SMF.
  • the second network device can be a PCF.
  • FIG. 2 is a schematic flowchart of a rule management method according to an embodiment of the present application. As shown in the figure, the method may include the following steps:
  • Step 201 The first network device receives the first indication information, where the first indication information is used to indicate that the terminal is currently in a suspended state.
  • Step 202 The first network device sends second indication information to the second network device, where the second indication information is used to indicate that the terminal is currently in a suspended state.
  • the first network device may report the status of the terminal to the second network device immediately after receiving the first indication information according to the indication of the second network device, or may receive the updated PCC rule sent by the second network device. And after the request of the QoS rule, the second indication information is sent to the second network device. Will be described in detail later.
  • Step 203 The second network device determines, according to the second indication information, that the PCC rule and/or the QoS rule for updating the terminal is not sent.
  • the MME when the BBERF is included in the PCC architecture, as shown in FIG. 3, when the terminal is suspended, the MME sends an indication to the S-GW (the BBERF is set in the S-GW and the BBERF is the first network device). Information indicating that the terminal is currently in a suspended state.
  • the BBERF may send an indication message to the PCRF (second network device) indicating that the terminal is currently in a suspended state.
  • the PCRF After receiving the indication information sent by the BBERF, the PCRF does not send a request to update the terminal QoS rule to the BBERF temporarily, even if it needs to update the PCC rule and/or QoS rule of the terminal, and does not send the PCCE rule to the PCEF to update the terminal. Request.
  • the MME sends an indication message to the S-GW, and the S-GW further goes to the P-GW (the PCEF is set in the P-GW, and the PCEF is the first A network device sends an indication message indicating that the terminal is currently in a suspended state.
  • the PCEF may send an indication message to the PCRF (second network device) indicating that the terminal is currently in a suspended state.
  • the PCRF does not temporarily send a request to update the PCC rule to the PCEF even if the PCC rule of the terminal needs to be updated.
  • the second network device determines that the request for updating the PCC rule and/or the QoS rule of the terminal is not temporarily sent to avoid
  • the second network device continuously sends an update request, and the first network device continuously responds to the update failure response, and reduces signaling interaction between the first network device and the second network device, which helps improve resource utilization efficiency.
  • the first network device if receiving the third indication information, indicating that the terminal status is restored, the first network device may send the fourth indication information to the second network device, indicating that the terminal has returned to the normal state. .
  • the second network device may send a request for updating the PCC rule and/or the QoS rule of the terminal when determining that the PCC rule and/or the QoS rule of the terminal needs to be updated.
  • the PCRF second network device
  • the PCRF sends a request to update the terminal QoS rule to the BBERF when determining that the PCC rule and the QoS rule of the terminal need to be updated, and sends an update to the PCEF to the PCEF.
  • the request of the rule if the first network device is a PCEF, the PCRF (second network device) sends a request to update the terminal PCC rule to the PCEF when determining that the PCC rule of the terminal needs to be updated.
  • the first network device determines, according to the first indication information, the current terminal.
  • the second indication information is sent to the first network device to notify the second network device that the current terminal is in the suspended state.
  • the PCRF sends a request for updating the QoS rule to the BBERF. Because the BBERF determines that the terminal is currently in the suspended state according to the indication information sent by the MME, the response to the update failure is returned to the PCRF, and the response includes the reason that the update fails because the terminal is currently in the The suspended state, that is, the second indication information.
  • the PCRF sends a request for updating the PCC rule to the PCEF. Because the PCRF determines that the terminal is currently in the suspended state according to the indication information sent by the S-GW, the PCRF returns a response to the update failure, and the response includes the reason for the update failure. The terminal is currently in a suspended state, that is, the second indication information. The reason why the PCRF fails to obtain the PCC rule or QoS rule update is because the terminal is currently in the suspended state, and it is determined that the request for updating the QoS and/or PCC rules is not temporarily sent to the BBERF and/or the PCEF to avoid useless signaling interaction. Wasting signaling resources.
  • the foregoing first request may also be used to request to subscribe to information that the terminal returns from the suspended state to the normal state.
  • the first network device receives the first request, if it is determined that the terminal is currently in a normal state, the first network device updates the PCC rule and/or the QoS rule of the terminal according to the first request. If the first network device determines that the terminal is currently in the suspended state, the first network device returns a response message to the second network device, where the response message indicates that the second network device fails to update and the reason for the failure is that the terminal is in the suspended state.
  • the first network device receives the third indication information for indicating that the terminal is restored to the normal state, the first network device will be the event that the terminal requesting the subscription in the first request returns from the suspended state to the normal state.
  • the information that the terminal returns from the suspended state to the normal state is reported to the second network device, that is, the first network device sends the fourth indication information to the second network device, where the fourth indication information is used to indicate that the terminal has returned to the normal state.
  • the second network device may resend the request for updating the terminal PCC rule or the QoS rule to the first network device.
  • the foregoing embodiment helps the second network device to immediately obtain the information that the terminal state has returned to the normal state, thereby facilitating the second network device to immediately send a request for updating the terminal PCC rule or the QoS rule after the terminal returns to the normal state. Thereby ensuring the timeliness of policy charging and service demand control of the terminal.
  • the foregoing first request may also be used to request to subscribe to status information of the terminal.
  • the first network device updates the PCC rule and/or the QoS rule of the terminal according to the first request; if the first network device determines the terminal Currently in the suspended state, the first network device returns a response message to the second network device, the response message indicating that the update failed, and indicating that the terminal is currently in a suspended state.
  • the first network device subsequently receives the indication information of the terminal status, the status information of the terminal is reported to the second network device.
  • the second network device may request to subscribe to the status information that the terminal is currently in the suspended state or the suspended state; or may request the subscription terminal to change the state of the terminal, specifically, the first After receiving the indication that the status of the terminal changes, the network device reports the status of the terminal to the second network device, and further reports the changed status information to the second network device.
  • the first network device reports the status information that the terminal is suspended or resumes normal to the second network device, thereby avoiding the request for the second network device to send the update rule when the terminal is suspended, due to the update rule.
  • the request usually occupies more resources than the signaling of reporting the status information of the terminal, so this embodiment helps to improve resource utilization.
  • the QoS rule of the terminal does not know the current state information of the terminal, and the PCEF does not need to interact with the terminal when updating the PCC rule of the terminal, so the PCEF will update the PCC rule of the terminal, thereby causing the PCC rule and QoS rule of the terminal.
  • the update is inconsistent, that is, the quality of service provided for the terminal is inconsistent with the charging rule for the terminal.
  • the PCRF when creating or modifying an IP-CAN session, the PCRF sends a request to install or update a PCC rule to the PCEF through CCA or RAR signaling.
  • Step 503 The PCRF is triggered to update the PCC rule of the terminal, and sends RAR signaling to the PCEF, where the signaling includes a policy and charging control rule installation and/or deletion request (Charging-Rule-Install AVP and/or Charging-Rule- Remove AVP), request to update the PCC rules.
  • the signaling includes a policy and charging control rule installation and/or deletion request (Charging-Rule-Install AVP and/or Charging-Rule- Remove AVP), request to update the PCC rules.
  • Step 505 After the terminal state is restored, the S-GW sends a modify bearer request or a resume notification message to the P-GW.
  • step 609 the PCEF returns response information to the PCRF.
  • the value of the Event-Trigger AVP field in the CCA or RAR signaling indicates the change information of the status of the requesting subscription terminal, so that the PCEF sends the status information of the terminal to the PCRF when the terminal status changes.
  • Step 703 The PCEF sends CCR or RAA signaling to the PCRF.
  • the Event-Trigger AVP field in the signaling indicates that the status of the terminal changes, and the USER_STATUS AVP field is included, and the value of the field indicates that the terminal is in a suspended state. .
  • the signaling sent by the PCRF to the BBERF may further carry an Event-Trigger AVP, and the value of the field indicates the change information of the status of the requesting subscription terminal, so that the BBERF sends the status information of the terminal to the PCRF when the terminal status changes;
  • the PCRF may also send a request to subscribe to the terminal status information through other signaling.
  • Step 802 The terminal is suspended, and the MME sends a suspend notification message to the S-GW.
  • Step 804 The PCRF stores the status information of the terminal, determines that the request for updating the QoS rule is not sent to the BBERF, and does not send a request for updating the PCC rule to the PCEF, and returns a response message to the BBERF.
  • Step 809 The PCRF sends a quality of service rule installation and/or deletion request (QoS-Rule-Install AVP and/or QoS-Rule-Remove AVP) to the BBERF.
  • QoS-Rule-Install AVP and/or QoS-Rule-Remove AVP a quality of service rule installation and/or deletion request
  • Step 811 The PCEF determines that the downlink data of the terminal can be sent to the BBERF, and returns response information to the PCRF.
  • Step 905 After the terminal returns to the normal state, the S-GW sends a modify bearer request or a resume notification message to the P-GW.
  • Step 906 The PCEF sends CCR signaling to the PCRF, where the signaling carries an Event-Trigger AVP field.
  • the value of the field indicates that the state of the terminal changes, and the USER_STATUS AVP field is included.
  • the value of the field indicates that the terminal returns to the normal state.
  • Step 907 The PCRF is triggered to update the PCC rule of the terminal, and sends a policy and charging control rule installation and/or deletion request to the PCEF, requesting to update the PCC rule.
  • step 902 and step 903 may be interchanged.
  • Step 1004 The BBERF sends the RAA signaling to the PCRF, where the information carries the indication information of the update failure, the Event-Trigger AVP field in the signaling, the value of the field indicates that the status of the terminal changes, and the USER_STATUS AVP field is also included. The value of the field indicates that the terminal is in a suspended state.
  • Step 1005 The PCRF sends RAR signaling to the PCEF.
  • the Event-Trigger AVP field in the signaling indicates that the status of the terminal changes, and the USER_STATUS AVP field is included.
  • the value of the field indicates that the terminal is in a suspended state.
  • Step 1006 After receiving the foregoing signaling, the PCEF does not send the downlink data of the terminal to the BBERF, and returns a response message to the PCRF.
  • Step 1008 The BBERF sends CCR signaling to the PCRF, where the signaling carries an Event-Trigger AVP field, where the value of the field indicates that the state of the terminal changes, and the USER_STATUS AVP field is included, and the value of the field indicates that the terminal returns to the normal state.
  • Event-Trigger AVP field where the value of the field indicates that the state of the terminal changes, and the USER_STATUS AVP field is included, and the value of the field indicates that the terminal returns to the normal state.
  • Step 1009 The PCRF sends CCR signaling to the BBERF, where the signaling includes a quality of service rule installation and/or deletion request (QoS-Rule-Install AVP and/or QoS-Rule-Remove AVP).
  • the signaling includes a quality of service rule installation and/or deletion request (QoS-Rule-Install AVP and/or QoS-Rule-Remove AVP).
  • step 1002 and step 1003 may be interchanged
  • order of step 1004 and step 1005 may be interchanged
  • order of step 1006 and step 1007 may be interchanged
  • order of step 1009 and step 1010 may be interchanged.
  • FIG. 11 it is a schematic flowchart of a rule management method when the BBERF is not included in the PCC architecture. among them:
  • the CCA or RAR signaling includes two Event-Trigger AVP fields, where the value of one Event-Trigger AVP field indicates that the subscription subscription terminal status is suspended, and the value of another Event-Trigger AVP field indicates the subscription terminal status.
  • the recovered information is such that the PCEF sends the status information of the terminal to the PCRF when the terminal status changes.
  • FIG. 12 it is a schematic flowchart of a rule management method when a BBERF is included in a PCC architecture. among them:
  • Step 1201 S-GW, P-GW, and PCRF are triggered to create or modify an IP-CAN session of the terminal.
  • the PCEF may send CCR or RAA signaling to the PCRF, where the signaling carries an Event-Trigger AVP field, and the value of the field indicates the change information of the status of the requesting subscription terminal, so that
  • the PCRF sends the status information of the terminal to the PCEF when the status of the terminal changes;
  • the PCRF sends a request for installing or updating the QoS rule to the BBERF through CCA or RAR signaling;
  • the PCRF will install or update the request for the PCC rule through CCA or RAR signaling.
  • Step 1203 The BBERF sends CCR signaling to the PCRF, where the Event-Trigger AVP field in the signaling indicates that the terminal is in a suspended state.
  • Step 1205 The PCRF sends RAR signaling to the PCEF, where the Event-Trigger AVP field is in the signaling, and the value of the field indicates that the terminal is in a suspended state.
  • Step 1206 After receiving the foregoing signaling, the PCEF does not send the downlink data of the terminal to the BBERF, and returns a response message to the PCRF.
  • Step 1207 After the terminal returns to the normal state, the MME sends a modify bearer request or a resume notification message to the S-GW.
  • Step 1208 The BBERF sends CCR signaling to the PCRF, where the signaling carries an Event-Trigger AVP field, and the value of the field indicates that the terminal status has been restored.
  • Step 1209 The PCRF sends a Quality of Service Rule installation and/or deletion request (QoS-Rule-Install AVP and/or QoS-Rule-Remove AVP) to the BBERF.
  • QoS-Rule-Install AVP and/or QoS-Rule-Remove AVP QoS-Rule-Install AVP and/or QoS-Rule-Remove AVP
  • Step 1210 The PCRF sends RAR signaling to the PCEF, where the signaling includes an Event-Trigger AVP field, and the value of the field indicates that the terminal returns to a normal state, and further includes a policy and charging control rule installation and/or deletion request, requesting the PCEF. Update PCC rules.
  • Step 1211 The PCEF determines that the downlink data of the terminal can be sent to the BBERF, and returns response information to the PCRF.
  • step 1204 and step 1205 may be interchanged, and the order of step 1209 and step 1210 may be interchanged.
  • FIG. 13 it is a schematic flowchart of a rule management method when the BBERF is not included in the PCC architecture. among them:
  • Step 1301 S-GW, P-GW, and PCRF are triggered to create or modify an IP-CAN session of the terminal.
  • the PCRF when creating or modifying an IP-CAN session, the PCRF sends a request to install or update the PCC rule to the PCEF through CCA or RAR signaling.
  • the CCA or RAR signaling includes two Event-Trigger AVP field fields, where the value of one Event-Trigger AVP field indicates an event requesting that the subscription terminal state is suspended, and the value of another Event-Trigger AVP field indicates the subscription terminal. State recovery event.
  • Step 1302 The PCRF is triggered to update the PCC rule of the terminal, and sends RAR signaling to the PCEF, where the signaling includes a policy and charging control rule installation and/or deletion request, and requests to update the PCC rule.
  • the foregoing signaling may further include two Event-Trigger AVP fields, where the value of one Event-Trigger AVP field indicates an event requesting that the subscription terminal state is suspended, and the value of another Event-Trigger AVP field indicates the subscription terminal. State recovery event.
  • Step 1303 The terminal is suspended, and the S-GW sends a suspend notification message to the P-GW.
  • Step 1304 The PCEF sends RAA signaling to the PCRF, indicating that the update rule fails, and the Event-Trigger AVP field in the signaling indicates that the terminal is in a suspended state.
  • the PCRF stores the status information of the terminal, and determines that the request for updating the PCC rule is not sent to the PCEF.
  • Steps 1305 to 1307 are similar to the above steps 1105 to 1107, and are not described herein again.
  • step 1202 and step 1303 may be interchanged.
  • FIG. 14 is a schematic flowchart of a rule management method when a BBERF is included in a PCC architecture. among them:
  • Step 1401 S-GW, P-GW, and PCRF are triggered to create or modify an IP-CAN session of the terminal.
  • the PCEF may send CCR or RAA signaling to the PCRF, where the signaling carries an Event-Trigger AVP field, and the value of the field indicates the change information of the status of the requesting subscription terminal, so that
  • the PCRF sends the status information of the terminal to the PCEF when the status of the terminal changes;
  • the PCRF sends a request for installing or updating the QoS rule to the BBERF through CCA or RAR signaling;
  • the PCRF will install or update the request for the PCC rule through CCA or RAR signaling.
  • the signaling sent by the PCRF to the BBERF may also carry two Event-Trigger AVP fields, where the value of one Event-Trigger AVP field indicates an event requesting the subscription terminal to be suspended, and the value of another Event-Trigger AVP field. An event indicating that the status of the terminal is restored.
  • the PCRF may also send the event reporting request for subscribing to the terminal status through other signaling.
  • Step 1402 The PCRF is triggered to update the PCC rule and the QoS rule of the terminal, and send RAR signaling to the BBERF, where the signaling carries a QoS-Rule-Install AVP and/or a QoS-Rule. -Remove AVP).
  • the foregoing signaling may further include an Event-Trigger AVP field, where the value of the field indicates information that requests the subscribing terminal to recover from the suspended state to the state.
  • Step 1403 The terminal is suspended, and the MME sends a suspend notification message to the S-GW.
  • Step 1404 The BBERF sends the RAA signaling to the PCRF, indicating that the update fails.
  • the signaling further includes an Event-Trigger AVP field, and the value of the field indicates that the terminal is in a suspended state.
  • the PCRF stores the status information of the terminal, determines that the request for updating the QoS rule is not sent to the BBERF, and does not send a request for updating the PCC rule to the PCEF.
  • Steps 1405 to 1411 are similar to the above steps 1205 to 1211, and are not described herein again.
  • step 1402 and step 1403 may be interchanged
  • order of step 1404 and step 1405 may be interchanged
  • order of step 1407 and step 1408 may be interchanged
  • order of step 1409 and step 1410 may be interchanged.
  • the embodiment of the present application further provides a rule management method, which is used to solve the problem that the signaling interaction is frequent and resources are wasted when the terminal hangs and requests to update the PCC rule and/or the QoS rule.
  • the method can be applied to LTE, 5G or other communication systems in the future, which is not limited in this application.
  • FIG. 15 is a schematic flowchart of a rule management method according to an embodiment of the present application. As shown in the figure, the method may include the following steps:
  • Step 1501 The first network device receives indication information indicating that the terminal is currently in a suspended state.
  • Step 1502 The first network device receives a request sent by the second network device to request to update the terminal PCC rule or QoS rule.
  • Step 1503 The first network device stores a PCC rule or a QoS rule requesting the update.
  • Step 1504 After the first network device receives the indication information for indicating that the terminal returns to the normal state, the first network device performs a PCC rule or a QoS rule requesting the update for the terminal.
  • the MME sends indication information to the S-GW (the BBERF is placed in the S-GW, and the BBERF is the first network device), indicating the terminal.
  • the S-GW the BBERF is placed in the S-GW, and the BBERF is the first network device
  • the PCRF second network device
  • the PCRF sends a request to the BBERF to update the QoS rule of the terminal. Since the BBERF cannot establish or modify the corresponding SDF according to the updated QoS rule, The BBERF replies to the PCRF with an update failure response.
  • the BBERF if the PCRF sends a request to update the terminal QoS rule to the BBERF when the terminal is suspended, the BBERF first stores the updated QoS rule, but does not execute. After receiving the indication information sent by the MME indicating that the terminal returns to the normal state, the BBERF performs the updated QoS rule on the terminal, that is, establishes or modifies the corresponding SDF according to the updated QoS rule.
  • the PCEF does not need to interact with the terminal when updating the PCC rules of the terminal. Therefore, even if the terminal is in the suspended state, the PCEF can still update after receiving the request for updating the PCC rule sent by the PCRF. success.
  • the MME sends an indication message to the S-GW, and the S-GW sends the P-GW to the P-GW (the PCEF is set to the P-GW, and the PCEF is the first.
  • the network device sends an indication message indicating that the terminal is currently in a suspended state.
  • the PCRF second network device
  • the PCEF cannot perform an updated PCC rule on the terminal, so the PCEF replies with an update failure response to the PCRF.
  • the PCEF if the PCRF sends a request to update the PCC rule of the terminal to the PCEF when the terminal is suspended, the PCEF first stores the PCC rule requesting the update, but does not execute. After the PCEF receives the indication information sent by the S-GW indicating that the terminal returns to the normal state, the PCCE rules are executed on the terminal.
  • the timer is started according to the preset time. If the timer does not receive the indication information for instructing the terminal to return to the normal state, the first network device sends the indication information to the second network device (PCRF), indicating that the terminal is currently in the suspended state, and the rule update fails.
  • the second network device After receiving the indication information indicating that the terminal is currently in the suspended state and the rule update fails, the second network device determines that the first network device fails to update, and needs to resend the request for updating the rule, but the terminal is temporarily suspended, so the suspension is suspended. send.
  • the first network device After receiving the indication information that the terminal returns to the normal state, the first network device sends the status information of the terminal to the second network device, and the second network device resends the request for updating the rule.
  • the BBERF or the PCEF After receiving the request for updating the PCC rule or the QoS rule, the BBERF or the PCEF performs a new charging rule on the terminal according to the updated rule and provides a new quality of service. If the execution fails, the PCRF is sent to the PCRF. The escalation update failed, but the updated rules are not stored.
  • the BBERF or the PCEF after receiving the request for updating the PCC rule or the QoS rule, if the terminal is in the suspended state and cannot immediately execute the updated rule, the BBERF or the PCEF stores the updated rule first, and then stores the updated rule. Wait for the terminal to return to normal status before executing the new rule. This method can reduce signaling interaction and avoid resource waste.
  • FIG. 16 it is a schematic flowchart of a rule management method when the BBERF is not included in the PCC architecture. among them:
  • Step 1601 S-GW, P-GW, and PCRF are triggered to create or modify an IP-CAN session of the terminal.
  • the PCRF when creating or modifying an IP-CAN session, the PCRF sends a request to install or update the PCC rule to the PCEF through CCA or RAR signaling.
  • Step 1602 the terminal is suspended, and the S-GW sends a suspend notification message to the P-GW (the PCEF is set in the P-GW).
  • Step 1603 The PCRF is triggered to update the PCC rule of the terminal, and send RAR signaling to the PCEF, where the signaling includes a policy charging control rule installation request (Charging-Rule-Install AVP and/or Charging-Rule-Remove AVP), requesting Update PCC rules.
  • a policy charging control rule installation request Charging-Rule-Install AVP and/or Charging-Rule-Remove AVP
  • Step 1604 After receiving the update request, the PCEF stores the PCC rule included in the request, and starts a timer.
  • Step 1605 The PCEF replies with the response information to the PCRF, indicating that the update rule is successful.
  • Step 1606 After the terminal returns to the normal state, the S-GW sends a modify bearer request or a resume notification message to the P-GW. If the timer does not expire at this time, step 1507 is performed; otherwise, step 1510 is performed.
  • Step 1607 The PCEF executes the updated PCC rule on the terminal according to the stored rule.
  • Step 1608 If the PCEF update fails, send CCR signaling to the PCRF to notify the PCRF rule that the update fails.
  • step 1609 the PCRF replies to the PCEF with response information.
  • the response information may carry a request for updating the PCC rule.
  • Step 1610 If the timer expires and the indication information that the terminal returns to the normal state is not received, the PCEF determines that the terminal is still in the suspended state.
  • Step 1611 The PCEF sends CCR signaling to the PCRF, where the signaling indicates that the update fails, and the failure reason is that the terminal is in a suspended state.
  • Step 1612 The PCRF stores the status information of the terminal, determines that the update rule request is not sent to the PCEF, and returns the response information to the PCEF.
  • Step 1613 After the terminal returns to the normal state, the S-GW sends a modify bearer request or a resume notification message to the P-GW.
  • Step 1614 The PCEF sends CCR signaling to the PCRF, where the signaling carries an Event-Trigger AVP field, and the value of the field indicates that the terminal returns to a normal state.
  • FIG. 17 is a schematic flowchart of a rule management method when a BBERF is included in a PCC architecture. among them:
  • Step 1701 S-GW, P-GW, and PCRF are triggered to create or modify an IP-CAN session of the terminal.
  • the PCRF when creating or modifying an IP-CAN session, the PCRF sends a request to install or update a QoS rule to the BBERF through CCA or RAR signaling.
  • the PCRF sends a request to install or update the PCC rule to the PCEF through CCA or RAR signaling.
  • Step 1702 The terminal is suspended, and the MME sends a suspend notification message to the S-GW (the BBERF is set in the P-GW).
  • Step 1703 The PCRF is triggered to update the PCC rule and the QoS rule of the terminal, and the PCRF sends RAR signaling to the BBERF, where the signaling carries a QoS-Rule-Install AVP and/or QoS- Rule-Remove AVP), ie, requesting BBERF to update QoS rules.
  • the foregoing signaling may further include an Event-Trigger AVP field, where the value of the field indicates information that requests the subscribing terminal to resume from the suspended state to the normal state.
  • Step 1704 After receiving the update request, the BBERF stores the QoS rule included in the request, and starts a timer.
  • Step 1705 The BBERF replies with a response message to the PCRF, indicating that the update rule is successful.
  • Step 1706 The PCRF sends a policy and charging control rule installation and/or deletion request to the PCEF.
  • Step 1707 The PCEF updates the PCC rule of the terminal according to the request, and sends a response to the PCRF, indicating that the update is successful.
  • the steps 1603 to 1605 are interchangeable with the steps 1606 to 1607.
  • Step 1708 The BBERF receives the terminal recovery notification information sent by the MME, and the timer does not time out.
  • Step 1709 The BBERF installs and/or deletes the QoS rule of the terminal according to the QoS rule.
  • Step 1710 If the BBERF update fails, send signaling to the PCRF to notify the rule update failure.
  • Step 1711 The PCRF replies to the BBERF with response information.
  • Step 1712 If the timer expires and the indication information that the terminal returns to the normal state is not received, the BBERF determines that the terminal is still in the suspended state.
  • Step 1713 The BBERF sends CCR signaling to the PCRF, where the signaling indicates that the update fails, and the failure reason is that the terminal is in a suspended state.
  • Step 1714 The PCRF stores the status information of the terminal, determines that the update rule request is not sent to the BBERF, and returns the response information to the BBERF.
  • FIG. 18 is a schematic structural diagram of a first network device according to an embodiment of the present disclosure.
  • the first network device includes: a receiving unit 1801 and a sending unit 1802.
  • the receiving unit 1801 is configured to receive first indication information, where the first indication information is used to indicate that the terminal is currently in a suspended state.
  • the sending unit 1802 is configured to send the second indication information to the second network device, where the second indication information is used to indicate that the terminal is currently in a suspended state, so that the second network device does not send the update of the terminal. Policy and charging control rules and/or requests for quality of service rules.
  • the receiving unit 1801 is further configured to: receive the third indication information, where the third indication information is used to indicate the terminal State recovery
  • the sending unit 1802 is further configured to send fourth indication information to the second network device, where the fourth indication information is used to indicate that the terminal status is restored, so that the second network device needs to update the terminal.
  • the first network device sends a request to update the policy of the terminal with a charging control rule or a quality of service rule.
  • the receiving unit 1801 is further configured to: receive, by the first network device, the second request sent by the second network device
  • the second request is used to subscribe to the status information of the terminal, so that the first network device sends the status information of the terminal to the second network device when the status of the terminal changes; or
  • the second request is used to subscribe to the information that the terminal returns from the suspended state to the normal state, so that the first network device restores the state of the terminal when the terminal returns from the suspended state to the normal state.
  • Information is sent to the second network device.
  • FIG. 19 is a schematic structural diagram of a second network device according to an embodiment of the present disclosure.
  • the second network device includes: a receiving unit 1901 and a determining unit 1902. Further, the second network device may further A transmitting unit 1903 is included.
  • the determining unit 1902 is configured to determine, according to the first indication information, that the policy for updating the terminal and the charging control rule and/or the quality of service rule are not sent.
  • the receiving unit 1901 further uses Receiving: the second indication information sent by the first network device, where the second indication information is used to indicate that the terminal status is restored;
  • the sending unit 1903 before the receiving unit 1901 receives the first indication information sent by the first network device, the sending unit 1903 is further configured to send, to the first network device, a first request, where the A request for requesting to install or update the policy and charging control rules or quality of service rules of the terminal.
  • the sending unit 1903 is further configured to send a second request to the first network device, where the The second request is used to request to subscribe to the status information of the terminal, so that the first network device sends the status information of the terminal to the second network device when the status of the terminal changes; or The second request is used to subscribe to the information that the terminal returns from the suspended state to the normal state, so that the first network device sends the status information of the terminal to the terminal when the terminal returns from the suspended state to the normal state.
  • the second network device is used to subscribe to the information that the terminal returns from the suspended state to the normal state, so that the first network device sends the status information of the terminal to the terminal when the terminal returns from the suspended state to the normal state.
  • the receiving unit 1901 before receiving the first indication information sent by the first network device, the receiving unit 1901 is further configured to:
  • the sending unit 1903 after the receiving unit 1901 receives the first indication information sent by the first network device, is further used to:
  • the receiving unit 1901 is further configured to: Receiving, by the first network device, second indication information, where the second indication information is used to indicate that the terminal status is restored;
  • FIG. 20 is a schematic structural diagram of a first network device according to an embodiment of the present disclosure.
  • the first network device includes: a processor 2001, and a memory 2002 connected to the processor 2001. 2003;
  • the processor 2001 is configured to read a computer program pre-stored in the memory 2002 to execute:
  • the processor 2001 is further configured to: after sending the second indication information to the second network device by using the transceiver 2003,
  • the processor 2001 is further configured to: before sending the second indication information to the second network device by using the transceiver 2003,
  • the first request is further used to subscribe to information that the terminal returns from a suspended state to a normal state, so that the first network device is restored from the suspended state to the terminal Sending the status information of the terminal to the second network device in a normal state; or the first request is further used to subscribe to status information of the terminal, so that the first network device is in the terminal status
  • the status information of the terminal is sent to the second network device when a change occurs.
  • the processor 2001 is further configured to: before sending the second indication information to the second network device by using the transceiver 2003,
  • the terminal Receiving, by the transceiver 2003, a second request sent by the second network device, where the second request is used to subscribe to status information of the terminal, so that the first network device changes when the terminal status changes.
  • FIG. 21 is a schematic structural diagram of a second network device according to an embodiment of the present disclosure.
  • the second network device includes: a processor 2101, and a memory 2102 connected to the processor 2101. 2103;
  • the processor 2101 is configured to read a computer program pre-stored in the memory 2102 to execute:
  • the processor 2101 is further configured to: after determining, according to the first indication information, that a policy for updating the terminal and a charging control rule and/or a quality of service rule are not sent, :
  • the transceiver 2103 sends a policy and charging control rule or a quality of service rule to the second network device to update the terminal. Request.
  • the processor 2101 is further configured to: before receiving the first indication information sent by the second network device by using the transceiver 2103,
  • the first request is further used to subscribe to information that the terminal returns from a suspended state to a normal state, so that the second network device is restored from the suspended state to the terminal Sending status information of the terminal to the first network device in a normal state;
  • the first request is further used to request to subscribe to the status information of the terminal, so that the second network device sends the status information of the terminal to the first network device when the status of the terminal changes.
  • the transceiver 2103 Sending, by the transceiver 2103, a second request to the second network device, where the second request is used to request to subscribe to status information of the terminal, so that the second network device changes when the terminal status changes. Transmitting the status information of the terminal to the first network device; or the second request is used to subscribe to information that the terminal returns from a suspended state to a normal state, so that the first network device is in the When the terminal returns from the suspended state to the normal state, the terminal sends the status information of the terminal to the second network device.
  • the processor 2101 is specifically configured to: when determining, according to the first indication information, that a policy for updating the terminal and a charging control rule and/or a QoS rule are not sent, :
  • the processor 2101 is further configured to: before receiving the first indication information sent by the second network device by using the transceiver 2103,
  • the processor 2101 is further configured to: after receiving the first indication information sent by the second network device by using the transceiver 2103,
  • the processor 2101 is further configured to: after determining, according to the first indication information, that the policy of the terminal and the charging control rule and the QoS rule are not sent,
  • FIG. 22 is a schematic structural diagram of a first network device according to an embodiment of the present disclosure.
  • the first network device includes: a receiving unit 2201, a storage unit 2202, and an executing unit 2203.
  • the second network device may further include a sending unit 2204.
  • the receiving unit 2201 is configured to receive first indication information, where the first indication information is used to indicate that the terminal is currently in a suspended state, and receive a policy and charging control that is sent by the second network device to request to update the terminal. a request for a rule or a quality of service rule; and receiving second indication information, the second indication information being used to indicate terminal state recovery.
  • the storage unit 2202 is configured to store the policy for requesting update and a charging control rule or a quality of service rule;
  • the executing unit 2203 is configured to, when the receiving unit 2201 receives the second indication information, perform the policy and charging control rule or the quality of service rule of the terminal that is requested to be updated.
  • the sending unit 2204 is configured to send third indication information to the second network device, where the The three indication information is used to indicate that the terminal is currently in a suspended state, so that the second network device does not send a request to update the policy and the charging control rule or the quality of service rule of the terminal.
  • the third indication information is sent to the second network device by using the transceiver 2302, where the third indication information is used to indicate The terminal is currently in a suspended state, so that the second network device does not send a request to update the policy and charging control rules or quality of service rules of the terminal.
  • embodiments of the present application can be provided as a method, system, or computer program product.
  • the present application can take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment in combination of software and hardware.
  • the application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) including computer usable program code.
  • the computer program instructions can also be stored in a computer readable memory that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer readable memory produce an article of manufacture comprising the instruction device.
  • the apparatus implements the functions specified in one or more blocks of a flow or a flow and/or block diagram of the flowchart.
  • These computer program instructions can also be loaded onto a computer or other programmable data processing device such that a series of operational steps are performed on a computer or other programmable device to produce computer-implemented processing for execution on a computer or other programmable device.
  • the instructions provide steps for implementing the functions specified in one or more of the flow or in a block or blocks of a flow diagram.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Databases & Information Systems (AREA)
  • Quality & Reliability (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)

Abstract

本申请公开了一种规则管理方法及设备。该方法中,第一网络设备接收第一指示信息,该第一指示信息用于指示终端当前处于挂起状态;第一网络设备向第二网络设备发送第二指示信息,该第二指示信息用于指示终端当前处于挂起状态;第二网络设备根据该第二指示信息确定不发送更新有关该终端的策略与计费控制规则和/或服务质量规则的请求。在上述方法中,当第二网络设备接收到用于指示终端处于挂起状态的指示信息后,则暂时不发送更新规则的请求,因此,能够解决现有技术中存在的第二网络设备不断下发更新有关终端的规则的请求,而第一网络设备不断回复更新失败的问题,减少了信令交互,有助于提高资源利用效率。

Description

一种规则管理方法及设备
本申请要求于2018年2月14日提交中国国家知识产权局、申请号为201810151832.1、发明名称为“一种规则管理方法及设备”的中国专利申请的优先权,其全部内容通过引用结合在本申请中。
技术领域
本申请涉及通信技术领域,尤其涉及一种规则管理方法及设备。
背景技术
第三代合作伙伴项目(3rd generation partnership project,3GPP)定义的策略与计费控制(policy and charging control,PCC)架构,可对用户使用网络资源进行业务的服务质量(quality of service,QoS)以及策略与计费的控制。其中,策略与计费控制功能(policy and charging control function,PCRF)根据应用功能(application function,AF),用户签约数据库(subscription profile repository,SPR),在线计费***(online charging system,OCS)和/或无线网络拥塞觉察功能(RAN congestion awareness function,RCAF)提供的信息制定用户业务的PCC规则以及QoS规则。
在如图1所示的PCC架构中,PCRF将QoS规则通过Gxx接口发送给承载绑定与事件上报功能(bearer binding and event report function,BBERF),由BBERF对用户的QoS进行控制;PCRF将PCC规则通过Gx接口发送给策略与计费执行功能(policy and charging enforcement function,PCEF),PCEF对用户业务的计费策略进行控制。其中,PCEF存在于数据网络网关(packet data network gateway,P-GW)中,BBERF存在于服务网关(serving gateway,S-GW)中,PCEF与BBERF之间(即P-GW与S-GW之间)通过基于PMIP的S5/S8接口连接。
或者,承载绑定这一功能也可以由PCEF执行,即S-GW中不包含BBERF。PCEF与S-GW之间(即P-GW与S-GW之间)通过基于通用分组无线服务隧道协议(GPRS tunnelling protocol,GTP)的S5/S8接口连接。PCRF通过Gx接口向PCEF发送PCC规则,其中,根据协议规定,PCRF向PCEF发送的请求为策略与计费控制规则安装和/或删除请求,即请求安装或更新PCC规则。
当触发更改PCC规则和QoS规则的事件发生时,例如用户流量超过预设值时需要对用户进行流量限速,PCEF或BBERF将触发事件上报给PCRF;PCRF更新PCC规则和QoS规则并请求PCEF和/或BBERF执行新的规则。
对于不支持双传输模式(dual transfer mode,DTM)的终端,当终端由于通话而从3/4G网络回落到2G网络时,终端的4G网络会话及相关承载将被挂起,此时该终端当前不能接收下行数据。
若PCC架构中包含BBERF,且PCRF下发新的PCC规则和QoS规则时终端已被挂起,BBERF由于无法进行终端承载的更新,因此向PCRF回复更新失败,而PCRF不知道是由于终端挂起导致更新失败,将会重新下发更新QoS规则请求,直到更新成功为止,使得Gxx 接口上的信令交互十分频繁,浪费大量资源。
若PCC架构中不包含BBERF,且PCRF向PCEF发送更新PCC规则请求时终端已被挂起,PCEF由于无法进行终端承载的更新,因此向PCRF回复更新失败,而PCRF将会重新下发更新PCC规则和/或QoS规则的请求,直到更新成功为止。因此,Gx接口上的信令交互十分频繁,浪费大量资源。
发明内容
本申请提供一种规则管理方法及设备,用以避免在终端不能接收下行数据且需要更新该终端的PCC规则和/或QoS规则时,网络设备之间不断进行信令交互而导致资源浪费。
第一方面,本申请提供了一种规则管理方法,包括:
第一网络设备接收第一指示信息,该第一指示信息用于指示终端当前处于挂起状态;第一网络设备向第二网络设备发送第二指示信息,该第二指示信息用于指示终端当前处于挂起状态;第二网络设备根据该第二指示信息确定不发送更新有关该终端的策略与计费控制规则和/或服务质量规则的请求。
可选的,第一网络设备可以为PCEF,或者第一网络设备为BBERF;第二网络设备为PCRF。
在上述方法中,当第二网络设备接收到用于指示终端处于挂起状态的指示信息后,则暂时不发送更新PCC规则和/或QoS规则请求,因此,能够解决现有技术中存在的第二网络设备不断下发更新有关终端的PCC规则和/或QoS规则的请求,而第一网络设备不断回复更新失败的问题,减少了信令交互,有助于提高资源利用效率。
在一种可能的实现方式中,第一网络设备在向第二网络设备发送第二指示信息之后,若接收到第三指示信息,该第三指示信息用于指示终端状态恢复;可以向第二网络设备发送第四指示信息,该第四指示信息用于指示终端状态恢复,以使第二网络设备在需要更新终端的策略与计费控制规则和/或服务质量规则时,向所述第一网络设备发送更新所述终端的策略与计费控制规则或服务质量规则的请求。
在一种可能的实现方式中,第一网络设备在向第二网络设备发送第二指示信息之前,还可以接收第二网络设备发送的第一请求,其中,第一请求用于请求安装或更新所述终端的策略与计费控制规则或服务质量规则。
在上述实施例中,若在终端挂起时,第一网络设备接收到第二网络设备发送的更新规则的请求,则将终端的状态信息上报给第二网络设备,避免第二网络设备重复发送更新规则的请求,能够减少信令交互。
在一种可能的实现方式中,第一请求还用于请求订阅所述终端从挂起状态恢复为正常状态的信息,以使所述第一网络设备在所述终端从挂起状态恢复为正常状态时,将所述终端的状态信息发送给所述第二网络设备;或者,第一请求还用于请求订阅所述终端的状态信息,以使所述第一网络设备在所述终端状态发生变化时将所述终端的状态信息发送给所述第二网络设备。
在上述实施例,第二网络设备可以将更新规则的请求和订阅终端状态的请求通过同一信令发送给第一网络设备,从而避免信令交互频繁,保证对终端的策略计费、服务需求控制的 时效性。
在一种可能的实现方式中,第一网络设备在向第二网络设备发送第二指示信息之前,还可以接收第二网络设备发送的第二请求,该第二请求用于订阅所述终端的状态信息,以使第一网络设备在所述终端状态发生变化时将所述终端的状态信息发送给第二网络设备;或者,第二请求用于订阅所述终端从挂起状态恢复为正常状态的信息,以使第一网络设备在所述终端从挂起状态恢复为正常状态时,将所述终端的状态信息发送给第二网络设备。
上述实施例有助于第二网络设备立即获取到终端状态已恢复信息,进而有助于实现在终端恢复正常状态后第二网络设备立即发送更新该终端PCC规则或QoS规则的请求,从而保证对终端的策略计费、服务需求控制的时效性。
第二方面,本申请提供了一种规则管理方法,包括:
第一网络设备接收第一指示信息,第一指示信息用于指示终端当前处于挂起状态;
第一网络设备接收第二网络设备发送的用于请求更新终端的策略与计费控制规则或服务质量规则的请求;
第一网络设备存储所述请求更新的策略与计费控制规则或服务质量规则;
当所述第一网络设备接收到第二指示信息时,所述第一网络设备对所述终端执行所述请求更新的所述终端的策略与计费控制规则或服务质量规则,所述第二指示信息用于指示终端状态恢复。
在一种可能的实现方式中,若所述第一网络设备在预设时间内未接收到所述第二指示信息,所述第一网络设备向所述第二网络设备发送第三指示信息,所述第三指示信息用于指示终端当前处于挂起状态,以使所述第二网络设备不发送更新所述终端的策略与计费控制规则或服务质量规则的请求。
在传统的PCC架构中,BBERF或PCEF在接收到更新PCC规则或QoS规则的请求后,根据更新后的规则对终端执行新的计费规则并提供新的服务质量,若执行失败,则向PCRF上报更新失败,但并不存储更新后的规则。而本申请上述实施例中,BBERF或PCEF在接收到更新PCC规则或QoS规则的请求后,若终端处于挂起状态而无法立即执行更新后的规则,则先对更新后的规则进行存储,然后等待终端恢复正常状态时,再执行新的规则。该方法能够减少信令交互,避免资源浪费。
第三方面,本申请提供一种第一网络设备,该第一网络设备包括接收单元和发送单元。上述接收单元和发送单元用于执行上述第一方面或第一方面的任一可能实现方式中第一网络设备所执行的功能。
第四方面,本申请提供一种第二网络设备,该第二网络设备包括接收单元和确定单元。进一步地,第二网络设备还可以包括发送单元。上述接收单元、确定单元和发送单元用于执行上述第一方面或第一方面的任一可能实现方式中第二网络设备所执行的功能。
第五方面,本申请提供一种第一网络设备,该第一网络设备包括接收单元、存储单元和执行单元,进一步地,第一网络设备还可以包括发送单元。上述接收单元、存储单元、执行单元以及发送单元用于执行上述第二方面或第二方面的任一可能实现方式中第一网络设备所执行的功能。
第六方面,本申请提供一种第一网络设备,该第一网络设备包括处理器,以及与所述处理器分别连接的存储器和收发器。所述处理器用于读取所述存储器中预先存储的计算机程序 执行如第一方面或第一方面的任一可能实现方式中第一网络设备所执行的功能,具体参见方法实施例中的详细描述,此处不做赘述。
第七方面,本申请提供一种第二网络设备,该第二网络设备包括处理器,以及与所述处理器分别连接的存储器和收发器。所述处理器用于读取所述存储器中预先存储的计算机程序执行如第一方面或第一方面的任一可能实现方式中第二网络设备所执行的功能,具体参见方法实施例中的详细描述,此处不做赘述。
第八方面,本申请提供一种第一网络设备,该第一网络设备包括处理器,以及与所述处理器分别连接的存储器和收发器。所述处理器用于读取所述存储器中预先存储的计算机程序执行如第二方面或第二方面的任一可能实现方式中第一网络设备所执行的功能,具体参见方法实施例中的详细描述,此处不做赘述。
第九方面,本申请提供一种计算机可读存储介质,所述计算机可读存储介质中存储有计算机指令,当所述指令在计算机上运行时,使得计算机执行如第一方面或第二方面中第一网络设备所执行的功能。
第十方面,本申请提供一种计算机可读存储介质,所述计算机可读存储介质中存储有计算机指令,当所述指令在计算机上运行时,使得计算机执行如第一方面或第一方面任一可能实现方式中第二网络设备所执行的功能。
附图说明
图1为本申请实施例提供的PCC架构示意图;
图2为本申请实施例提供的一种规则管理方法的流程示意图之一;
图3为本申请实施例提供的包含BBERF的PCC架构;
图4为本申请实施例提供的不包含BBERF的PCC架构;
图5为本申请实施例提供的一种规则管理方法的示意图之二;
图6为本申请实施例提供的一种规则管理方法的示意图之三;
图7为本申请实施例提供的一种规则管理方法的示意图之四;
图8为本申请实施例提供的一种规则管理方法的示意图之五;
图9为本申请实施例提供的一种规则管理方法的示意图之六;
图10为本申请实施例提供的一种规则管理方法的示意图之七;
图11为本申请实施例提供的一种规则管理方法的示意图之八;
图12为本申请实施例提供的一种规则管理方法的示意图之九;
图13为本申请实施例提供的一种规则管理方法的示意图之十;
图14为本申请实施例提供的一种规则管理方法的示意图之十一;
图15为本申请实施例提供的另一种规则管理方法的流程示意图之一;
图16为本申请实施例提供的另一种规则管理方法的流程示意图之二;
图17为本申请实施例提供的另一种规则管理方法的流程示意图之三;
图18为本申请实施例提供的第一网络设备的结构示意图之一;
图19为本申请实施例提供的第二网络设备的结构示意图之一;
图20为本申请实施例提供的第一网络设备的结构示意图之二;
图21为本申请实施例提供的第二网络设备的结构示意图之二;
图22为本申请实施例提供的另一种第一网络设备的结构示意图之一;
图23为本申请实施例提供的另一种第一网络设备的结构示意图之二。
具体实施方式
为了使本申请的目的、技术方案和优点更加清楚,下面将结合附图对本申请作进一步地详细描述。
随着无线通信技术的发展,用户的业务类型、服务需求越来越多种多样。为了保证不同用户对于不同业务类型的不同服务需求,可以为不同的终端执行不同的PCC规则和QoS规则。若PCC架构中包含BBERF,PCRF将为终端制定的QoS规则发送给BBERF,由BBERF对用户的QoS进行控制,将为终端制定的PCC规则发送给PCEF,由PCEF执行PCC功能。若PCC架构中不包含BBERF,PCRF将PCC规则通过策略与计费控制规则安装和/或删除请求发送给PCEF。
然而,若终端由于通话而回落到2G网络或者由于其他原因使得终端处于挂起状态时,此时终端无法接收下行数据,因此无法更新网络设备与终端之间的服务数据流(service data flow,SDF)或者服务质量流(QoS flow)。因此,若终端处于挂起状态时,PCRF向PCEF和/或BBERF发送更新PCC规则和/或QoS规则的请求时,PCEF和/或BBERF将无法执行更新操作,将向PCRF返回更新失败响应。PCRF在接收到更新失败响应后,将重新下发更新请求,直到更新成功为止,导致信令交互频繁,浪费信令资源。
为了解决上述问题,本申请实施例提供了一种规则管理方法,用于解决当终端挂起且请求更新PCC规则和/或QoS规则时,信令交互频繁、浪费资源的问题。
本申请实施例提供的规则管理方法可以应用于长期演进(long term evolution,LTE)、5G或未来的其他通信***中,本申请对此不做限制。例如,在LTE中,本申请实施例可以由BBERF(S-GW)、PCEF(P-GW)、PCRF执行,若PCC架构中不包含BBERF,则本申请实施例主要由PCEF(P-GW)和PCRF执行。又例如,在5G中,可以由策略控制功能(policy control function,PCF)和会话管理功能(session management function,SMF)执行,具体地,本申请实施例中的第一网络设备可以是SMF,第二网络设备可以是PCF。
参见图2,为本申请实施例提供的规则管理方法的流程示意图,如图所示,该方法可以包括以下步骤:
步骤201、第一网络设备接收第一指示信息,其中,第一指示信息用于指示终端当前处于挂起状态。
步骤202、第一网络设备向第二网络设备发送第二指示信息,第二指示信息用于指示终端当前处于挂起状态。
具体地,第一网络设备可以根据第二网络设备的指示,在接收到第一指示信息后,立即向第二网络设备上报终端的状态,也可以在接收到第二网络设备发送的更新PCC规则和/或QoS规则的请求后,再向第二网络设备发送第二指示信息。后面将详细介绍。
步骤203、第二网络设备根据第二指示信息确定不发送更新该终端的PCC规则和/或QoS规则。
以LTE通信***为例,当PCC架构中包含BBERF时,如图3所示,当终端挂起时,MME向S-GW(BBERF设置于S-GW中,BBERF为第一网络设备)发送指示信息,指示终端当前处于挂起状态。BBERF可以向PCRF(第二网络设备)发送指示信息,指示终端当前处于挂起状态。PCRF在接收到BBERF发送的指示信息后,即使当前需要更新该终端的PCC规则和/或QoS规则,也暂时不向BBERF发送更新该终端QoS规则的请求,也不向PCEF发送更新该终端PCC规则的请求。
当PCC架构中不包含BBERF时,如图4所示,当终端挂起时,MME向S-GW发送指示信息,S-GW进而向P-GW(PCEF设置于P-GW中,PCEF为第一网络设备)发送指示信息,指示终端当前处于挂起状态。PCEF可以向PCRF(第二网络设备)发送指示信息,指示终端当前处于挂起状态。PCRF在接收到PCEF发送的指示信息后,即使当前需要更新该终端的PCC规则,也暂时不向PCEF发送更新PCC规则的请求。
在上述方法中,由于第一网络设备将终端处于挂起状态的信息发送给第二网络设备,使得第二网络设备确定暂时不发送更新该终端的PCC规则和/或QoS规则的请求,以避免第二网络设备不断发送更新请求、第一网络设备不断回复更新失败响应的情况发生,减少第一网络设备和第二网络设备的信令交互,有助于提高资源利用效率。
进一步地,在上述步骤203之后,第一网络设备若接收到第三指示信息,指示终端状态恢复,则第一网络设备可以向第二网络设备发送第四指示信息,指示终端已恢复为正常状态。第二网络设备在接收到第四指示信息后,在确定需要更新该终端的PCC规则和/或QoS规则时,可以发送更新该终端的PCC规则和/或QoS规则的请求。例如,若第一网络设备为BBERF,PCRF(第二网络设备)在确定需要更新该终端的PCC规则和QoS规则时,向BBERF发送更新该终端QoS规则的请求,并向PCEF发送更新该终端PCC规则的请求;若第一网络设备为PCEF,PCRF(第二网络设备)在确定需要更新该终端的PCC规则时,向PCEF发送更新该终端PCC规则的请求。
在一种可能的实现方式中,第一网络设备可以在接收到第二网络设备发送的第一请求(即更新终端的PCC规则或QoS规则的请求)后,根据上述第一指示信息确定终端当前处于挂起状态,因而向第一网络设备发送第二指示信息,以通知第二网络设备当前终端处于挂起状态。例如,PCRF向BBERF发送更新QoS规则的请求,由于BBERF根据MME发送的指示信息确定终端当前处于挂起状态,则向PCRF返回更新失败的响应,同时该响应中包含更新失败的原因是终端当前处于挂起状态,即第二指示信息。又例如,PCRF向PCEF发送更新PCC规则的请求,由于PCRF根据S-GW发送的指示信息确定终端当前处于挂起状态,则向PCRF返回更新失败的响应,同时该响应中包含更新失败的原因是终端当前处于挂起状态,即第二指示信息。PCRF在获取到PCC规则或QoS规则更新失败的原因是由于终端当前处于挂起状态,则确定暂时不向BBERF和/或PCEF发送更新QoS和/或PCC规则的请求,以避免无用的信令交互浪费信令资源。
在一些实施例中,上述第一请求,还可以用于请求订阅该终端从挂起状态恢复为正常状态的信息。相应地,第一网络设备在接收到第一请求后,若确定终端当前处于正常状态,则第一网络设备根据第一请求更新终端的PCC规则和/或QoS规则。若第一网络设备确定终端当前处于挂起状态,则第一网络设备向第二网络设备返回响应消息,该响应消息指示第二网络设备更新失败且失败原因为终端处于挂起状态。此外,若第一网络设备接收到用于指示终 端恢复为正常状态的第三指示信息,由于上述第一请求中请求订阅的终端从挂起状态恢复为正常状态的事件,因此第一网络设备将终端从挂起状态恢复为正常状态的信息上报给第二网络设备,即,第一网络设备向第二网络设备发送第四指示信息,该第四指示信息用于指示终端已恢复为正常状态。第二网络设备在接收到第四指示信息后,可以重新向第一网络设备发送更新该终端PCC规则或QoS规则的请求。
上述实施例有助于第二网络设备立即获取到终端状态已恢复正常状态的信息,进而有助于实现在终端恢复正常状态后第二网络设备立即发送更新该终端PCC规则或QoS规则的请求,从而保证对终端的策略计费、服务需求控制的时效性。
在另外一些实施例中,上述第一请求,还可以用于请求订阅该终端的状态信息。相应地,第一网络设备在接收到第一请求后,若确定终端当前处于正常状态,则第一网络设备根据第一请求更新终端的PCC规则和/或QoS规则;若第一网络设备确定终端当前处于挂起状态,则第一网络设备向第二网络设备返回响应消息,该响应消息指示更新失败,并且指示终端当前处于挂起状态。此外,若第一网络设备后续接收到该终端状态的指示信息,则将终端的状态信息上报给第二网络设备。例如,第一网络设备之后接收到终端恢复到正常状态的指示信息,则将终端恢复到正常状态的信息上报给第二网络设备;第一网络设备之后又接收到终端被挂起的指示信息,则将终端处于挂起状态的信息主动上报给第二网络设备。
可选地,第二网络设备请求订阅终端的状态信息时,可以请求订阅终端当前处于挂起状态还是从挂起状态恢复的状态信息;也可以请求订阅终端状态的变化信息,具体地,第一网络设备在接收到指示终端状态发生变化后,向第二网络设备上报终端的状态发生变化,进一步地,将变化后的状态信息也上报给第二网络设备。
在上述实施例中,由于第一网络设备将终端挂起或恢复正常的状态信息均上报给第二网络设备,从而避免了第二网络设备在终端挂起时发送更新规则的请求,由于更新规则的请求通常情况下比上报终端状态信息的信令占用更多的资源,因此该实施例有助于提高资源利用率。
此外,第二网络设备还可以在终端与网络设备建立或修改会话时,请求订阅终端的状态信息。例如,在终端接入网络设备后与网络设备建立IP-CAN会话时,PCRF向BBERF发送安装QoS规则的请求,该请求中同时携带请求订阅终端状态变化事件。若PCC架构中不包含BBERF,在终端接入网络设备后与网络设备建立IP-CAN会话时,PCRF向PCEF发送安装PCC规则时,可以进一步请求PCEF在终端被挂起时,以及终端回复正常状态时,将终端状态变化事件上报给PCRF;也可以仅请求在终端从挂起状态恢复为正常状态时,上报终端的状态信息。
在另外一种可能的实现方式中,第二网络设备还可以向第一网络设备发送第二请求,该请求用于请求订阅终端的状态信息。相应地,第一网络设备在接收到第二请求后,若接收到用于指示终端当前处于挂起状态的第一指示信息,或者接收到用于终端恢复为正常状态的第三指示信息,则立即将终端的状态信息上报给第二网络设备。上述实施例能够避免第二网络设备在终端挂起时发送更新规则的请求,有助于避免信令资源的浪费。具体地,第二请求可以用于请求订阅所述终端的状态信息,或者,第二请求也可以用于订阅终端从挂起状态恢复的信息。
当PCC架构如图3所示时,即S-GW中设置有BBERF时,S-GW在接收到MME发送 的用于指示终端的状态信息后,不会将终端的状态信息发送给P-GW,因而PCEF不能获取到终端当前的状态信息。因此,若终端当前处于挂起状态,且PCRF向BBERF发送了更新该终端QoS规则的请求、向PCEF发送了更新该终端PCC规则的请求,由于BBERF无法更新与终端之间的SDF,BBERF无法更新该终端的QoS规则;而PCEF并不知道终端当前的状态信息,且PCEF更新终端的PCC规则时无需与终端进行交互,因而PCEF将更新终端的PCC规则,从而导致该终端的PCC规则和QoS规则更新不一致,即为终端的提供的服务质量与对该终端的计费规则不一致。
为了避免上述情况的发生,第二网络设备(PCRF)可以在接收到第一网络设备(BBERF)发送的用于指示终端处于挂起状态的第一指示信息后,向PCEF发送指示信息,以使PCEF能够获取终端当前处于挂起状态的信息,在PCEF产生该终端的下行数据时,暂缓向S-GW发送产生的下行数据。
进一步地,第二网络设备(PCRF)还可以在接收到第一网络设备(BBERF)发送的用于指示终端恢复为正常状态的第三指示信息后,向PCEF发送指示信息,以使PCEF能够获取终端当前已恢复正常状态的信息,PCEF可以向S-GW发送该终端的下行数据。
可选地,第二网络设备(PCRF)可以根据PCEF的要求,确定是否将终端的状态信息发送给PCEF。例如,PCEF可以向PCRF发送第三请求,该第三请求用于请求订阅终端的状态的信息;PCRF在接收到第三请求后,若接收到BBERF发送的用于指示终端处于挂起状态的第一指示信息后,或者接收到BBERF发送的用于指示终端恢复为正常状态的第三指示信息后,则将终端的状态信息发送给PCEF。进一步地,第三请求可以请求在终端被挂起时,以及终端回复正常状态时,PCRF均将终端的状态信息发送给PCEF;也可以仅请求在终端从挂起状态恢复为正常状态时,PCRF将终端恢复为正常状态的信息发送给PCEF。
为了清楚理解本申请上述实施例提供的规则管理方法,下面结合图5~图14的例子来进一步说明。
信用控制(credit control,CC)或重授权(Re-Auth,RA)信令中包括事件触发(Event-Trigger AVP)字段,该字段中存在预留的值(value),在本申请实施例中,可以利用保留值表示PCRF请求订阅终端的状态信息,或者请求订阅终端从挂起状态恢复到正常状态的信息等。例如,若PCRF发送的CCA或RAR信令中Event-Trigger AVP字段的值为56时,表示PCRF请求订阅终端的状态信息,则BBERF或PCEF在终端状态发生变化时向PCRF上报终端当前状态;若Event-Trigger AVP字段的值为57时,表示PCRF请求订阅终端从挂起状态恢复到正常状态的信息。应当理解,上述字段的取值仅用于举例,并不对本申请构成限定。
参见图5,为PCC架构中不包括BBERF时,规则管理方法的流程示意图。其中:
步骤501、S-GW、P-GW以及PCRF被触发创建或修改终端的IP-CAN会话。
具体地,在创建或修改IP-CAN会话时,PCRF将安装或更新PCC规则的请求通过CCA或RAR信令发送给PCEF。
进一步的,PCRF向PCEF发送的信令中还可以携带Event-Trigger AVP字段,该字段的值表示请求订阅终端从挂起状态恢复到正常状态的信息。
步骤502、终端被挂起,S-GW向P-GW(PCEF置于P-GW中)发送挂起通知信息(suspend notification message)。
由于PCRF仅订阅终端从挂起状态恢复到正常状态的信息,因此,PCEF并不上报终端 被挂起的信息。
步骤503、PCRF被触发更新终端的PCC规则,向PCEF发送RAR信令,该信令中包括策略与计费控制规则安装和/或删除请求(Charging-Rule-Install AVP和/或Charging-Rule-Remove AVP),请求更新PCC规则。
可选的,上述信令中还可以包括Event-Trigger AVP字段,该字段的值表示请求订阅终端从挂起状态恢复到正常状态的信息。
步骤504、PCEF确定终端仍处于挂起状态,向PCRF回复RAA信令,该信令中携带指示规则更新失败且失败原因为终端处于挂起状态的指示信息。
PCRF在接收到信令后,确定PCEF更新规则失败,但暂不发送更新规则请求。
步骤505、当终端状态恢复后,S-GW向P-GW发送修改承载请求(modify bearer request)或恢复通知信息(resume notification message)。
步骤506、PCEF向PCRF发送CCR信令,该信令中携带Event-Trigger AVP字段,该字段的值表示终端状态已恢复。
步骤507、PCRF向PCEF发送CCA信令,该信令中包括规则安装和/或删除命令请求,请求更新PCC规则。
参见图6,为PCC架构中包括BBERF时,规则管理方法的流程示意图。其中:
步骤601、S-GW、P-GW以及PCRF被触发创建或修改终端的IP-CAN会话。
具体地,在创建或修改IP-CAN会话时,PCRF通过CCA或RAR信令将安装或更新QoS规则的请求发送给BBERF;PCRF通过CCA或RAR信令将安装或更新PCC规则的请求发送给PCEF。进一步的,PCRF向BBERF发送的信令中还可以携带Event-Trigger AVP,该字段的值表示请求订阅终端从挂起状态到状态恢复的信息,以使BBERF在终端从挂起状态恢复时将终端状态恢复的信息发送给PCRF;或者,PCRF也可以通过其它信令发送订阅终端从挂起状态恢复信息的请求。
步骤602、终端被挂起,MME向S-GW(BBERF置于S-GW中)发送挂起通知信息(suspend notification message)。
步骤603、PCRF被触发更新终端的PCC规则和QoS规则,PCRF向BBERF发送RAR信令,该信令中携带有服务质量规则安装和/或删除请求(QoS-Rule-Install AVP和/或QoS-Rule-Remove AVP),即,请求BBERF更新QoS规则。
可选的,上述信令中还可以包括Event-Trigger AVP字段,该字段的值表示请求订阅终端的状态信息。
步骤604、BBERF向PCRF发送RAA信令,该信令中携带指示规则更新失败且失败原因为终端处于挂起状态的指示信息。
PCRF在接收到信令后,确定PCEF更新规则失败,但暂不发送更新规则请求(包括更新QoS规则和更新PCC规则的请求),并存储终端的状态信息。
步骤605、当终端恢复为正常状态后,MME向S-GW发送修改承载请求(modify bearer request)或恢复通知信息(resume notification message)。
步骤606、BBERF向PCRF发送CCR信令,该信令中携带Event-Trigger AVP字段,该字段的值表示终端状态已恢复。
步骤607、PCRF向BBERF发送CCA信令,该信令中携带有服务质量规则安装和/或删 除请求(QoS-Rule-Install AVP和/或QoS-Rule-Remove AVP)。
步骤608、PCRF向PCEF发送RAR信令,该信令中包括Event-Trigger AVP字段,该字段的值表示终端状态已恢复,该信令还包括策略与计费控制规则安装和/或删除请求,请求PCEF更新PCC规则。
步骤609、PCEF向PCRF返回响应信息。
在上述实施例中,步骤607和步骤608的顺序可以互换。
参见图7,为PCC架构中不包括BBERF时,规则管理方法的流程示意图。其中:
步骤701、S-GW、P-GW以及PCRF被触发创建或修改终端的IP-CAN会话。
具体地,在创建或修改IP-CAN会话时,PCRF通过CCA或RAR信令将安装或更新PCC规则的请求发送给PCEF。
其中,该CCA或RAR信令中Event-Trigger AVP字段的值表示请求订阅终端状态的变化信息,以使PCEF在终端状态发生变化时将终端的状态信息发送给PCRF。
步骤702、终端被挂起,S-GW向P-GW发送挂起通知信息(suspend notification message)。
步骤703、PCEF向PCRF发送CCR或RAA信令,该信令中Event-Trigger AVP字段,该字段的值表示终端的状态发生变化,还包括USER_STATUS AVP字段,该字段的值表示终端处于挂起状态。
步骤704、PCRF存储终端的状态信息,确定暂不向PCEF发送更新PCC规则的请求,并向PCEF回复响应信息。
步骤705、当终端状态恢复后,S-GW向P-GW发送修改承载请求(modify bearer request)或恢复通知信息(resume notification message)。
步骤706、PCEF向PCRF发送CCR或RAA信令,该信令中携带Event-Trigger AVP字段,该字段的值表示终端的状态发生变化,还包括USER_STATUS AVP字段,该字段的值表示终端恢复为正常状态。
步骤707、PCRF被触发更新终端的PCC规则,向PCEF发送策略与计费控制规则安装和/或删除请求,请求更新PCC规则。
参见图8,为PCC架构中包括BBERF时,规则管理方法的流程示意图。其中:
步骤801、S-GW、P-GW以及PCRF被触发创建或修改终端的IP-CAN会话。
具体地,在创建或修改IP-CAN会话时,PCEF可以向PCRF发送CCR或RAA信令,该信令中携带Event-Trigger AVP字段,该字段的值表示请求订阅终端状态的变化信息,以使PCRF在终端状态发生变化时将终端的状态信息发送给PCEF;PCRF通过CCA或RAR信令将安装或更新QoS规则的请求发送给BBERF;PCRF通过CCA或RAR信令将安装或更新PCC规则的请求发送给PCEF。进一步的,PCRF向BBERF发送的信令中还可以携带Event-Trigger AVP,该字段的值表示请求订阅终端状态的变化信息,以使BBERF在终端状态发生变化时将终端的状态信息发送给PCRF;或者,PCRF也可以通过其它信令发送订阅终端状态信息的请求。
步骤802、终端被挂起,MME向S-GW发送挂起通知信息(suspend notification message)。
步骤803、BBERF向PCRF发送CCR信令,该信令中Event-Trigger AVP字段,该字段的值表示终端的状态发生变化,还包括USER_STATUS AVP字段,该字段的值表示终端处于挂起状态。
步骤804、PCRF存储终端的状态信息,确定暂不向BBERF发送更新QoS规则的请求,也不向PCEF发送更新PCC规则的请求,并向BBERF回复响应信息。
步骤805、PCRF向PCEF发送RAR信令,该信令中Event-Trigger AVP字段,该字段的值表示终端的状态发生变化,还包括USER_STATUS AVP字段,该字段的值表示终端处于挂起状态。
步骤806、PCEF在接收到上述信令后,不再向BBERF发送该终端的下行数据,并向PCRF回复响应信息。
步骤807、当终端恢复为正常状态后,MME向S-GW发送修改承载请求(modify bearer request)或恢复通知信息(resume notification message)。
步骤808、BBERF向PCRF发送CCR信令,该信令中携带Event-Trigger AVP字段,该字段的值表示终端的状态发生变化,还包括USER_STATUS AVP字段,该字段的值表示终端恢复为正常状态。
步骤809、PCRF向BBERF发送服务质量规则安装和/或删除请求(QoS-Rule-Install AVP和/或QoS-Rule-Remove AVP)。
步骤810、PCRF向PCEF发送RAR信令,该信令中包括Event-Trigger AVP字段,该字段的值表示终端状态发生变化,还包括USER_STATUS AVP字段,该字段的值表示终端恢复为正常状态,还包括策略与计费控制规则安装和/或删除请求,请求PCEF更新PCC规则。
步骤811、PCEF确定可以向BBERF发送终端的下行数据,并向PCRF返回响应信息。
在上述实施例中,步骤804和步骤805的顺序可以互换。
参见图9,为PCC架构中不包括BBERF时,规则管理方法的流程示意图。其中:
步骤901、S-GW、P-GW以及PCRF被触发创建或修改终端的IP-CAN会话。
具体地,在创建或修改IP-CAN会话时,PCRF通过CCA或RAR信令将安装或更新PCC规则的请求发送给PCEF。
其中,该CCA或RAR信令中Event-Trigger AVP字段的值表示请求订阅终端的状态信息,以使PCEF在终端状态发生变化时将终端的状态信息发送给PCRF。
步骤902、PCRF被触发更新终端的PCC规则,向PCEF发送RAR信令,该信令中包括策略与计费控制规则安装和/或删除请求,请求更新PCC规则。
可选的,上述信令中还可以包括Event-Trigger AVP字段,该字段的值表示请求订阅终端的状态信息,以使PCEF在终端状态发生变化时将终端的状态信息发送给PCRF。
步骤903、终端被挂起,S-GW向P-GW发送挂起通知信息(suspend notification message)。
步骤904、PCEF向PCRF发送RAA信令,该信令中Event-Trigger AVP字段,该字段的值表示终端的状态发生变化,还包括USER_STATUS AVP字段,该字段的值表示终端处于挂起状态。
PCRF存储终端的状态信息,确定暂不向PCEF发送更新PCC规则的请求。
步骤905、当终端恢复为正常状态后,S-GW向P-GW发送修改承载请求(modify bearer request)或恢复通知信息(resume notification message)。
步骤906、PCEF向PCRF发送CCR信令,该信令中携带Event-Trigger AVP字段,该字段的值表示终端的状态发生变化,还包括USER_STATUS AVP字段,该字段的值表示终端恢复为正常状态。
步骤907、PCRF被触发更新终端的PCC规则,向PCEF发送策略与计费控制规则安装和/或删除请求,请求更新PCC规则。
在上述实施例中,步骤902和步骤903的顺序可以互换。
参见图10,为PCC架构中包括BBERF时,规则管理方法的流程示意图。其中:
步骤1001、S-GW、P-GW以及PCRF被触发创建或修改终端的IP-CAN会话。
具体地,在创建或修改IP-CAN会话时,PCEF可以向PCRF发送CCR或RAA信令,该信令中携带Event-Trigger AVP字段,该字段的值表示请求订阅终端状态的变化信息,以使PCRF在终端状态发生变化时将终端的状态信息发送给PCEF;PCRF通过CCA或RAR信令将安装或更新QoS规则的请求发送给BBERF;PCRF通过CCA或RAR信令将安装或更新PCC规则的请求发送给PCEF。进一步的,PCRF向BBERF发送的信令中还可以携带Event-Trigger AVP,该字段的值表示请求订阅终端状态的变化信息,以使BBERF在终端状态发生变化时将终端的状态信息发送给PCRF;或者,PCRF也可以通过其它信令发送订阅终端状态信息的请求。
步骤1002、PCRF被触发更新终端的PCC规则和QoS规则,向BBERF发送RAR信令,该信令中携带有服务质量规则安装和/或删除请求(QoS-Rule-Install AVP和/或QoS-Rule-Remove AVP)。
步骤1003、终端被挂起,MME向S-GW发送挂起通知信息(suspend notification message)。
步骤1004、BBERF向PCRF发送RAA信令,该信息中携带更新失败的指示信息,该信令中的Event-Trigger AVP字段,该字段的值表示终端的状态发生变化,还包括USER_STATUS AVP字段,该字段的值表示终端处于挂起状态。
PCRF存储终端的状态信息,确定暂不向BBERF发送更新QoS规则的请求,也不向PCEF发送更新PCC规则的请求。
步骤1005、PCRF向PCEF发送RAR信令,该信令中Event-Trigger AVP字段,该字段的值表示终端的状态发生变化,还包括USER_STATUS AVP字段,该字段的值表示终端处于挂起状态。
步骤1006、PCEF在接收到上述信令后,不再向BBERF发送该终端的下行数据,并向PCRF回复响应信息。
步骤1007、当终端恢复为正常状态后,MME向S-GW发送修改承载请求(modify bearer request)或恢复通知信息(resume notification message)。
步骤1008、BBERF向PCRF发送CCR信令,该信令中携带Event-Trigger AVP字段,该字段的值表示终端的状态发生变化,还包括USER_STATUS AVP字段,该字段的值表示终端恢复为正常状态。
步骤1009、PCRF向BBERF发送CCR信令,该信令中包括服务质量规则安装和/或删除请求(QoS-Rule-Install AVP和/或QoS-Rule-Remove AVP)。
步骤1010、PCRF向PCEF发送RAR信令,该信令中包括Event-Trigger AVP字段,该字段的值表示终端状态发生变化,还包括USER_STATUS AVP字段,该字段的值表示终端恢复为正常状态,还包括策略与计费控制规则安装请求,请求PCEF更新PCC规则。
步骤1011、PCEF确定可以向BBERF发送终端的下行数据,并向PCRF返回响应信息。
在上述实施例中,步骤1002和步骤1003的顺序可以互换,步骤1004和步骤1005的顺 序可以互换,步骤1006和步骤1007的顺序可以互换,步骤1009和步骤1010的顺序可以互换。
参见图11,为PCC架构中不包括BBERF时,规则管理方法的流程示意图。其中:
步骤1101、S-GW、P-GW以及PCRF被触发创建或修改终端的IP-CAN会话。
具体地,在创建或修改IP-CAN会话时,PCRF通过CCA或RAR信令将安装或更新PCC规则的请求发送给PCEF。
其中,该CCA或RAR信令中包含两个Event-Trigger AVP字段,其中一个Event-Trigger AVP字段的值表示请求订阅终端状态挂起的信息,另一个Event-Trigger AVP字段的值表示订阅终端状态恢复的信息,以使PCEF在终端状态发生变化时将终端的状态信息发送给PCRF。
步骤1102、终端被挂起,S-GW向P-GW发送挂起通知信息(suspend notification message)。
步骤1103、PCEF向PCRF发送CCR信令,该信令中Event-Trigger AVP字段,该字段的值表示终端处于挂起状态。
步骤1104、PCRF存储终端的状态信息,确定暂不向PCEF发送更新PCC规则的请求,并向PCEF回复响应信息。
步骤1105、当终端恢复为正常状态后,S-GW向P-GW发送修改承载请求(modify bearer request)或恢复通知信息(resume notification message)。
步骤1106、PCEF向PCRF发送CCR信令,该信令中携带Event-Trigger AVP字段,该字段的值表示终端恢复为正常状态。
步骤1107、PCRF被触发更新终端的PCC规则,向PCEF发送策略与计费控制规则安装和/或删除请求,请求更新PCC规则。
参见图12,为PCC架构中包括BBERF时,规则管理方法的流程示意图。其中:
步骤1201、S-GW、P-GW以及PCRF被触发创建或修改终端的IP-CAN会话。
具体地,在创建或修改IP-CAN会话时,PCEF可以向PCRF发送CCR或RAA信令,该信令中携带Event-Trigger AVP字段,该字段的值表示请求订阅终端状态的变化信息,以使PCRF在终端状态发生变化时将终端的状态信息发送给PCEF;PCRF通过CCA或RAR信令将安装或更新QoS规则的请求发送给BBERF;PCRF通过CCA或RAR信令将安装或更新PCC规则的请求发送给PCEF。进一步的,PCRF向BBERF发送的信令中还可以携带两个Event-Trigger AVP字段,其中一个Event-Trigger AVP字段的值表示请求订阅终端状态挂起的事件,另一个Event-Trigger AVP字段的值表示订阅终端状态恢复的事件,以使BBERF在终端状态发生变化时将终端的状态信息发送给PCRF;或者,PCRF也可以通过其它信令发送上述订阅请求。
步骤1202、终端被挂起,MME向S-GW发送挂起通知信息(suspend notification message)。
步骤1203、BBERF向PCRF发送CCR信令,该信令中Event-Trigger AVP字段,该字段的值表示终端处于挂起状态。
步骤1204、PCRF存储终端的状态信息,确定暂不向BBERF发送更新QoS规则的请求,也不向PCEF发送更新PCC规则的请求,并向BBERF回复响应信息。
步骤1205、PCRF向PCEF发送RAR信令,该信令中Event-Trigger AVP字段,该字段的值表示终端处于挂起状态。
步骤1206、PCEF在接收到上述信令后,不再向BBERF发送该终端的下行数据,并向 PCRF回复响应信息。
步骤1207、当终端恢复为正常状态后,MME向S-GW发送修改承载请求(modify bearer request)或恢复通知信息(resume notification message)。
步骤1208、BBERF向PCRF发送CCR信令,该信令中携带Event-Trigger AVP字段,该字段的值表示终端状态已恢复。
步骤1209、PCRF向BBERF发送服务质量规则安装和/或删除请求(QoS-Rule-Install AVP和/或QoS-Rule-Remove AVP)。
步骤1210、PCRF向PCEF发送RAR信令,该信令中包括Event-Trigger AVP字段,该字段的值表示终端恢复为正常状态,还包括策略与计费控制规则安装和/或删除请求,请求PCEF更新PCC规则。
步骤1211、PCEF确定可以向BBERF发送终端的下行数据,并向PCRF返回响应信息。
在上述实施例中,步骤1204和步骤1205的顺序可以互换,步骤1209和步骤1210的顺序可以互换。
参见图13,为PCC架构中不包括BBERF时,规则管理方法的流程示意图。其中:
步骤1301、S-GW、P-GW以及PCRF被触发创建或修改终端的IP-CAN会话。
具体地,在创建或修改IP-CAN会话时,PCRF通过CCA或RAR信令将安装或更新PCC规则的请求发送给PCEF。
其中,该CCA或RAR信令中包含两个Event-Trigger AVP字段字段,其中一个Event-Trigger AVP字段的值表示请求订阅终端状态挂起的事件,另一个Event-Trigger AVP字段的值表示订阅终端状态恢复的事件。
步骤1302、PCRF被触发更新终端的PCC规则,向PCEF发送RAR信令,该信令中包括策略与计费控制规则安装和/或删除请求,请求更新PCC规则。
可选的,上述信令中还可以包含两个Event-Trigger AVP字段,其中一个Event-Trigger AVP字段的值表示请求订阅终端状态挂起的事件,另一个Event-Trigger AVP字段的值表示订阅终端状态恢复的事件。
步骤1303、终端被挂起,S-GW向P-GW发送挂起通知信息(suspend notification message)。
步骤1304、PCEF向PCRF发送RAA信令,表示更新规则失败,该信令中Event-Trigger AVP字段,该字段的值表示终端处于挂起状态。
PCRF存储终端的状态信息,确定暂不向PCEF发送更新PCC规则的请求。
步骤1305至步骤1307与上述步骤1105至步骤1107类似,此处不再赘述。
在上述实施例中,步骤1202和步骤1303的顺序可以互换。
参见图14,为PCC架构中包括BBERF时,规则管理方法的流程示意图。其中:
步骤1401、S-GW、P-GW以及PCRF被触发创建或修改终端的IP-CAN会话。
具体地,在创建或修改IP-CAN会话时,PCEF可以向PCRF发送CCR或RAA信令,该信令中携带Event-Trigger AVP字段,该字段的值表示请求订阅终端状态的变化信息,以使PCRF在终端状态发生变化时将终端的状态信息发送给PCEF;PCRF通过CCA或RAR信令将安装或更新QoS规则的请求发送给BBERF;PCRF通过CCA或RAR信令将安装或更新PCC规则的请求发送给PCEF。进一步的,PCRF向BBERF发送的信令中还可以携带两个Event-Trigger AVP字段,其中一个Event-Trigger AVP字段的值表示请求订阅终端状态挂起的 事件,另一个Event-Trigger AVP字段的值表示订阅终端状态恢复的事件;或者,PCRF也可以通过其它信令发送上述用于订阅终端状态的事件上报请求。
步骤1402、PCRF被触发更新终端的PCC规则和QoS规则,向BBERF发送RAR信令,该信令中携带有服务质量规则安装和/或删除请求(QoS-Rule-Install AVP和/或QoS-Rule-Remove AVP)。
可选的,上述信令中还可以包括Event-Trigger AVP字段,该字段的值表示请求订阅终端从挂起状态到状态恢复的信息。
步骤1403、终端被挂起,MME向S-GW发送挂起通知信息(suspend notification message)。
步骤1404、BBERF向PCRF发送RAA信令,表示更新失败,该信令中还包括Event-Trigger AVP字段,该字段的值表示终端处于挂起状态。
PCRF存储终端的状态信息,确定暂不向BBERF发送更新QoS规则的请求,也不向PCEF发送更新PCC规则的请求。
步骤1405至步骤1411与上述步骤1205至步骤1211类似,此处不再赘述。
在上述实施例中,步骤1402和步骤1403的顺序可以互换,步骤1404和步骤1405的顺序可以互换,步骤1407和步骤1408的顺序可以互换,步骤1409和步骤1410的顺序可以互换。
此外,为了解决上述问题,本申请实施例还提供了一种规则管理方法,用于解决当终端挂起且请求更新PCC规则和/或QoS规则时,信令交互频繁、浪费资源的问题。
该方法可以应用于LTE、5G或未来的其他通信***中,本申请对此不做限制。
参见图15,为本申请实施例提供的规则管理方法的流程示意图,如图所示,该方法可以包括以下步骤:
步骤1501、第一网络设备接收用于指示终端当前处于挂起状态的指示信息。
步骤1502、第一网络设备接收第二网络设备发送的用于请求更新该终端PCC规则或QoS规则的请求。
步骤1503、第一网络设备存储请求更新的PCC规则或QoS规则。
步骤1504、在第一网络设备接收到用于指示终端恢复为正常状态的指示信息后,第一网络设备对该终端执行请求更新的PCC规则或QoS规则。
具体地,当PCC架构中包含BBERF时,如图3所示,当终端挂起时,MME向S-GW(BBERF置于S-GW中,BBERF为第一网络设备)发送指示信息,指示终端当前处于挂起状态。
在传统的PCC架构中,若终端挂起时,PCRF(第二网络设备)向BBERF发送更新该终端QoS规则的请求,由于BBERF无法根据更新后的QoS规则与终端建立或修改相应的SDF,因此BBERF向PCRF回复更新失败响应。
在本申请上述实施例中,若终端挂起时PCRF向BBERF发送更新该终端QoS规则的请求,BBERF先将更新后的QoS规则存储下来,但并不执行。待BBERF接收到MME发送的指示终端恢复到正常状态的指示信息后,再对终端执行更新后的QoS规则,即,根据更新后的QoS规则与终端建立或修改相应的SDF。
当PCC架构中包含BBERF时,PCEF在更新终端的PCC规则时,由于不需要与终端进行交互,因此即使终端处于挂起状态,PCEF在接收到PCRF发送的更新PCC规则的请求后, 仍然能够更新成功。
当PCC架构中不包含BBERF时,如图4所示,当终端挂起时,MME向S-GW发送指示信息,S-GW向P-GW(PCEF设置于P-GW中,PCEF为第一网络设备)发送指示信息,指示终端当前处于挂起状态。
在传统的PCC架构中,若终端挂起时PCRF(第二网络设备)向PCEF发送更新该终端PCC规则的请求,PCEF由于无法对终端执行更新后的PCC规则,因此PCEF向PCRF回复更新失败响应。
在本申请上述实施例中,若终端挂起时PCRF向PCEF发送更新该终端PCC规则的请求,PCEF先将请求更新的PCC规则存储下来,但并不执行。待PCEF接收到S-GW发送的指示终端恢复到正常状态的指示信息后,再对终端执行更新后的PCC规则。
可选地,在上述步骤1502后,即第一网络设备(BBERF或PCEF)接收到用于请求更新该终端PCC规则或QoS规则的请求后,则根据预设时间开启定时器。若定时器超时仍未接收到用于指示终端恢复为正常状态的指示信息,则第一网络设备向第二网络设备(PCRF)发送指示信息,指示终端当前处于挂起状态、规则更新失败。
第二网络设备在接收到指示终端当前处于挂起状态、规则更新失败的指示信息后,确定第一网络设备更新失败,需要重新发送更新规则的请求,但由于终端当前处于挂起状态,因此暂缓发送。
进一步地,当第一网络设备接收到终端恢复为正常状态的指示信息后,将终端的状态信息发送给第二网络设备,第二网络设备则重新发送更新规则的请求。
在传统的PCC架构中,BBERF或PCEF在接收到更新PCC规则或QoS规则的请求后,根据更新后的规则对终端执行新的计费规则并提供新的服务质量,若执行失败,则向PCRF上报更新失败,但并不存储更新后的规则。
而本申请上述实施例中,BBERF或PCEF在接收到更新PCC规则或QoS规则的请求后,若终端处于挂起状态而无法立即执行更新后的规则,则先对更新后的规则进行存储,然后等待终端恢复正常状态时,再执行新的规则。该方法能够减少信令交互,避免资源浪费。
为了清楚理解本申请上述实施例提供的规则管理方法,下面结合图16和图17的例子来进一步说明。
参见图16,为PCC架构中不包括BBERF时,规则管理方法的流程示意图。其中:
步骤1601、S-GW、P-GW以及PCRF被触发创建或修改终端的IP-CAN会话。
具体地,在创建或修改IP-CAN会话时,PCRF通过CCA或RAR信令将安装或更新PCC规则的请求发送给PCEF。
步骤1602、终端被挂起,S-GW向P-GW(PCEF设置于P-GW中)发送挂起通知信息(suspend notification message)。
步骤1603、PCRF被触发更新终端的PCC规则,向PCEF发送RAR信令,该信令中包括策略计费控制规则安装请求(Charging-Rule-Install AVP和/或Charging-Rule-Remove AVP),请求更新PCC规则。
步骤1604、PCEF在接收到更新请求后,存储请求中包含的PCC规则,并启动定时器。
步骤1605、PCEF向PCRF回复响应信息,表示更新规则成功。
步骤1606、当终端恢复为正常状态后,S-GW向P-GW发送修改承载请求(modify bearer  request)或恢复通知信息(resume notification message)。若此时定时器未超时,则执行步骤1507,否则,执行步骤1510。
步骤1607、PCEF根据存储的规则对终端执行更新后的PCC规则。
步骤1608、若PCEF更新失败,则向PCRF发送CCR信令,以通知PCRF规则更新失败。
步骤1609、PCRF向PCEF回复响应信息。
可选的,该响应信息中可以携带有更新PCC规则的请求。
步骤1610、若定时器超时且未收到终端恢复为正常状态的指示信息,则PCEF确定终端仍处于挂起状态。
步骤1611、PCEF向PCRF发送CCR信令,该信令中指示更新失败,失败原因为终端处于挂起状态。
步骤1612、PCRF存储终端的状态信息,确定暂不向PCEF发送更新规则请求,并向PCEF回复响应信息。
步骤1613、当终端恢复为正常状态后,S-GW向P-GW发送修改承载请求(modify bearer request)或恢复通知信息(resume notification message)。
步骤1614、PCEF向PCRF发送CCR信令,该信令中携带Event-Trigger AVP字段,该字段的值表示终端恢复为正常状态。
参见图17,为PCC架构中包括BBERF时,规则管理方法的流程示意图。其中:
步骤1701、S-GW、P-GW以及PCRF被触发创建或修改终端的IP-CAN会话。
具体地,在创建或修改IP-CAN会话时,PCRF通过CCA或RAR信令将安装或更新QoS规则的请求发送给BBERF。PCRF通过CCA或RAR信令将安装或更新PCC规则的请求发送给PCEF。
步骤1702、终端被挂起,MME向S-GW(BBERF设置于P-GW中)发送挂起通知信息(suspend notification message)。
步骤1703、PCRF被触发更新终端的PCC规则和QoS规则,PCRF向BBERF发送RAR信令,该信令中携带有服务质量规则安装和/或删除请求(QoS-Rule-Install AVP和/或QoS-Rule-Remove AVP),即,请求BBERF更新QoS规则。
可选的,上述信令中还可以包括Event-Trigger AVP字段,该字段的值表示请求订阅终端从挂起状态恢复到正常状态的信息。
步骤1704、BBERF在接收到更新请求后,存储请求中包含的QoS规则,并启动定时器。
步骤1705、BBERF向PCRF回复响应信息,表示更新规则成功。
步骤1706、PCRF向PCEF发送策略与计费控制规则安装和/或删除请求。
步骤1707、PCEF根据请求更新终端的PCC规则,并向PCRF发送响应,表示更新成功。
其中,上述步骤1603至步骤1605,与步骤1606至步骤1607的顺序可以互换。
步骤1708、BBERF接收到MME发送的终端恢复通知信息,且定时器未超时。
步骤1709、BBERF根据服务质量规则安装和/或删除请求更新终端的QoS规则。
步骤1710、若BBERF更新失败,则向PCRF发送信令,以通知规则更新失败。
步骤1711、PCRF向BBERF回复响应信息。
步骤1712、若定时器超时且未收到终端恢复为正常状态的指示信息,则BBERF确定终 端仍处于挂起状态。
步骤1713、BBERF向PCRF发送CCR信令,该信令中指示更新失败,失败原因为终端处于挂起状态。
步骤1714、PCRF存储终端的状态信息,确定暂不向BBERF发送更新规则请求,并向BBERF回复响应信息。
基于相同的技术构思,本申请实施例还提供了一种第一网络设备,用以实现上述方法实施例中第一网络设备所执行的方法流程。参见图18,为本申请实施例提供的一种第一网络设备的结构示意图,如图所示,该第一网络设备包括:接收单元1801和发送单元1802。
具体地,接收单元1801,用于接收第一指示信息,所述第一指示信息用于指示终端当前处于挂起状态。
发送单元1802,用于向第二网络设备发送第二指示信息,所述第二指示信息用于指示所述终端当前处于挂起状态,以使所述第二网络设备不发送更新所述终端的策略与计费控制规则和/或服务质量规则的请求。
在一种可能的实现方式中,在发送单元1802向第二网络设备发送第二指示信息之后,接收单元1801还用于:接收第三指示信息,所述第三指示信息用于指示所述终端状态恢复;
发送单元1802,还用于向所述第二网络设备发送第四指示信息,所述第四指示信息用于指示所述终端状态恢复,以使第二网络设备在需要更新所述终端的策略与计费控制规则和/或服务质量规则时,向所述第一网络设备发送更新所述终端的策略与计费控制规则或服务质量规则的请求。
在一种可能的实现方式中,在发送单元1802向第二网络设备发送第二指示信息之前,接收单元1801还用于:接收所述第二网络设备发送的第一请求,所述第一请求用于请求安装或更新所述终端的策略与计费控制规则或服务质量规则。
在一种可能的实现方式中,所述第一请求还用于请求订阅所述终端从挂起状态恢复为正常状态的信息,以使所述第一网络设备在所述终端从挂起状态恢复为正常状态时,将所述终端的状态信息发送给所述第二网络设备;或者,所述第一请求还用于请求订阅所述终端的状态信息,以使所述第一网络设备在所述终端状态发生变化时将所述终端的状态信息发送给所述第二网络设备。
在一种可能的实现方式中,在发送单元1802向第二网络设备发送第二指示信息之前,接收单元1801还用于:所述第一网络设备接收所述第二网络设备发送的第二请求,所述第二请求用于订阅所述终端的状态信息,以使所述第一网络设备在所述终端状态发生变化时将所述终端的状态信息发送给所述第二网络设备;或者,所述第二请求用于订阅所述终端从挂起状态恢复为正常状态的信息,以使所述第一网络设备在所述终端从挂起状态恢复为正常状态时,将所述终端的状态信息发送给所述第二网络设备。
基于相同的技术构思,本申请实施例还提供了一种第二网络设备,用以实现上述方法实施例中第二网络设备所执行的方法流程。参见图19,为本申请实施例提供的一种第二网络设备的结构示意图,如图所示,该第二网络设备包括:接收单元1901和确定单元1902,进一步地,第二网络设备还可以包括发送单元1903。
具体地,接收单元1901,用于接收第一网络设备发送的第一指示信息,所述第一指示信息用于指示终端当前处于挂起状态;
确定单元1902,用于根据所述第一指示信息确定不发送更新所述终端的策略与计费控制规则和/或服务质量规则的请求。
在一种可能的实现方式中,在确定单元1902根据所述第一指示信息确定不发送更新所述终端的策略与计费控制规则和/或服务质量规则的请求之后,接收单元1901,还用于:接收所述第一网络设备发送的第二指示信息,所述第二指示信息用于指示所述终端状态恢复;
发送单元1903,用于在确定单元1902确定需要更新所述终端的策略与计费控制规则和/或服务质量规则时,向所述第一网络设备发送更新所述终端的策略与计费控制规则或服务质量规则的请求。
在一种可能的实现方式中,在接收单元1901接收所述第一网络设备发送的第一指示信息之前,发送单元1903还用于,向所述第一网络设备发送第一请求,所述第一请求用于请求安装或更新所述终端的策略与计费控制规则或服务质量规则。
在一种可能的实现方式中,所述第一请求还用于订阅所述终端从挂起状态恢复为正常状态的信息,以使所述第一网络设备在所述终端从挂起状态恢复为正常状态时,将所述终端的状态信息发送给所述第二网络设备;或者,所述第一请求还用于请求订阅所述终端的状态信息,以使所述第一网络设备在所述终端状态发生变化时将所述终端的状态信息发送给所述第二网络设备。
在一种可能的实现方式中,在接收单元1901接收所述第一网络设备发送的第一指示信息之前,发送单元1903还用于,向所述第一网络设备发送第二请求,所述第二请求用于请求订阅所述终端的状态信息,以使所述第一网络设备在所述终端状态发生变化时将所述终端的状态信息发送给所述第二网络设备;或者,所述第二请求用于订阅所述终端从挂起状态恢复为正常状态的信息,以使所述第一网络设备在所述终端从挂起状态恢复为正常状态时,将所述终端的状态信息发送给所述第二网络设备。
在一种可能的实现方式中,确定单元1902具体用于:根据所述第一指示信息确定不向所述第一网络设备发送更新所述终端的服务质量规则的请求;根据所述第一指示信息确定不向第三网络设备发送更新所述终端的策略与计费控制规则的请求。
在一种可能的实现方式中,接收单元1901在接收第一网络设备发送的第一指示信息之前,还用于:
接收第三网络设备发送的第三请求,所述第三请求用于订阅所述终端的状态信息,以使所述第二网络设备在所述终端状态发生变化时将所述终端的状态信息发送给所述第三网络设备;
发送单元1903,在接收单元1901接收所述第一网络设备发送的第一指示信息之后,还用于:
向所述第三网络设备发送第三指示信息,所述第三指示信息用于指示终端当前处于挂起状态,以使所述第三网络设备不向所述第一网络设备发送所述终端的下行数据。
在一种可能的实现方式中,在确定单元1902根据所述第一指示信息确定不发送更新所述终端的策略与计费控制规则和服务质量规则的请求之后,接收单元1901,还用于:接收所述第一网络设备发送的第二指示信息,所述第二指示信息用于指示所述终端状态恢复;
发送单元1903,还用于向第三网络设备发送第四指示信息,所述第二指示信息用于指示所述终端状态恢复,以使所述第三网络设备将所述终端的下行数据发送给所述第一网络设备。
基于相同的技术构思,本申请实施例还提供了一种第一网络设备,用以实现上述方法实施例中第一网络设备所执行的方法流程。参见图20,为本申请实施例提供的一种第一网络设备的结构示意图,如图所示,该第一网络设备包括:处理器2001,以及与所述处理器2001连接的存储器2002和收发器2003;
所述处理器2001,用于读取所述存储器2002中预先存储的计算机程序执行:
通过所述收发器2003接收第一指示信息,所述第一指示信息用于指示终端当前处于挂起状态;
通过所述收发器2003向所述第二网络设备发送第二指示信息,所述第二指示信息用于指示所述终端当前处于挂起状态,以使所述第二网络设备不发送更新所述终端的策略与计费控制规则和/或服务质量规则的请求。
在一种可能的实现方式中,所述处理器2001,在通过所述收发器2003向所述第二网络设备发送第二指示信息之后,还用于:
通过所述收发器2003接收第三指示信息,所述第三指示信息用于指示所述终端状态恢复;
通过所述收发器2003向所述第二网络设备发送第四指示信息,所述第四指示信息用于指示所述终端状态恢复,以使第二网络设备在需要更新所述终端的策略与计费控制规则和/或服务质量规则时,向所述第一网络设备发送更新所述终端的策略与计费控制规则或服务质量规则的请求。
在一种可能的实现方式中,所述处理器2001,在通过所述收发器2003向所述第二网络设备发送第二指示信息之前,还用于:
通过所述收发器2003接收所述第二网络设备发送的第一请求,所述第一请求用于请求安装或更新所述终端的策略与计费控制规则或服务质量规则。
在一种可能的实现方式中,所述第一请求还用于订阅所述终端从挂起状态恢复为正常状态的信息,以使所述第一网络设备在所述终端从挂起状态恢复为正常状态时,将所述终端的状态信息发送给所述第二网络设备;或者所述第一请求还用于订阅所述终端的状态信息,以使所述第一网络设备在所述终端状态发生变化时将所述终端的状态信息发送给所述第二网络设备。
在一种可能的实现方式中,所述处理器2001,在通过所述收发器2003向第二网络设备发送第二指示信息之前,还用于:
通过所述收发器2003接收所述第二网络设备发送的第二请求,所述第二请求用于订阅所述终端的状态信息,以使所述第一网络设备在所述终端状态发生变化时将所述终端的状态信息发送给所述第二网络设备;或者,所述第二请求用于订阅所述终端从挂起状态恢复为正常状态的信息,以使所述第一网络设备在所述终端从挂起状态恢复为正常状态时,将所述终端的状态信息发送给所述第二网络设备。
基于相同的技术构思,本申请实施例还提供了一种第二网络设备,用以实现上述方法实施例中第二网络设备所执行的方法流程。参见图21,为本申请实施例提供的一种第二网络设备的结构示意图,如图所示,该第二网络设备包括:处理器2101,以及与所述处理器2101连接的存储器2102和收发器2103;
所述处理器2101,用于读取所述存储器2102中预先存储的计算机程序执行:
通过所述收发器2103接收第二网络设备发送的第一指示信息,所述第一指示信息用于指示终端当前处于挂起状态;
根据所述第一指示信息确定不发送更新所述终端的策略与计费控制规则和/或服务质量规则的请求。
在一种可能的实现方式中,所述处理器2101,在根据所述第一指示信息确定不发送更新所述终端的策略与计费控制规则和/或服务质量规则的请求之后,还用于:
通过所述收发器2103接收所述第二网络设备发送的第二指示信息,所述第二指示信息用于指示所述终端状态恢复;
在需要更新所述终端的策略与计费控制规则和/或服务质量规则时,通过所述收发器2103向所述第二网络设备发送更新所述终端的策略与计费控制规则或服务质量规则的请求。
在一种可能的实现方式中,所述处理器2101,在通过所述收发器2103接收所述第二网络设备发送的第一指示信息之前,还用于:
通过所述收发器2103向所述第二网络设备发送第一请求,所述第一请求用于请求安装或更新所述终端的策略与计费控制规则或服务质量规则。
在一种可能的实现方式中,所述第一请求还用于订阅所述终端从挂起状态恢复为正常状态的信息,以使所述第二网络设备在所述终端从挂起状态恢复为正常状态时,将所述终端的状态信息发送给所述第一网络设备;或者
所述第一请求还用于请求订阅所述终端的状态信息,以使所述第二网络设备在所述终端状态发生变化时将所述终端的状态信息发送给所述第一网络设备。
在一种可能的实现方式中,所述处理器2101,在通过所述收发器2103接收所述第二网络设备发送的第一指示信息之前,还用于:
通过所述收发器2103向所述第二网络设备发送第二请求,所述第二请求用于请求订阅所述终端的状态信息,以使所述第二网络设备在所述终端状态发生变化时将所述终端的状态信息发送给所述第一网络设备;或者,所述第二请求用于订阅所述终端从挂起状态恢复为正常状态的信息,以使所述第一网络设备在所述终端从挂起状态恢复为正常状态时,将所述终端的状态信息发送给所述第二网络设备。
在一种可能的实现方式中,所述处理器2101,在根据所述第一指示信息确定不发送更新所述终端的策略与计费控制规则和/或服务质量规则的请求时,具体用于:
根据所述第一指示信息确定不向所述第二网络设备发送更新所述终端的服务质量规则的请求;
根据所述第一指示信息确定不向第三网络设备发送更新所述终端的策略与计费控制规则的请求。
在一种可能的实现方式中,所述处理器2101,在通过所述收发器2103接收第二网络设备发送的第一指示信息之前,还用于:
通过所述收发器2103接收第三网络设备发送的第三请求,所述第三请求用于订阅所述终端的状态信息,以使所述第一网络设备在所述终端状态发生变化时将所述终端的状态信息发送给所述第三网络设备;
所述处理器2101,在通过所述收发器2103接收所述第二网络设备发送的第一指示信息之后,还用于:
通过所述收发器2103向所述第三网络设备发送第三指示信息,所述第三指示信息用于指示终端当前处于挂起状态,以使所述第三网络设备不向所述第二网络设备发送所述终端的下行数据。
在一种可能的实现方式中,所述处理器2101,在根据所述第一指示信息确定不发送更新所述终端的策略与计费控制规则和服务质量规则的请求之后,还用于:
通过所述收发器2103接收所述第二网络设备发送的第二指示信息,所述第二指示信息用于指示所述终端状态恢复;
通过所述收发器2103向第三网络设备发送第四指示信息,所述第二指示信息用于指示所述终端状态恢复,以使所述第三网络设备将所述终端的下行数据发送给所述第二网络设备。
基于相同的技术构思,本申请实施例还提供了一种第一网络设备,用以实现上述方法实施例中第一网络设备所执行的方法流程。参见图22,为本申请实施例提供的一种第一网络设备的结构示意图,如图所示,该第一网络设备包括:接收单元2201、存储单元2202和执行单元2203。进一步地,第二网络设备还可以包括发送单元2204。
具体地,接收单元2201,用于接收第一指示信息,所述第一指示信息用于指示终端当前处于挂起状态;以及接收第二网络设备发送的用于请求更新终端的策略与计费控制规则或服务质量规则的请求;以及接收第二指示信息,所述第二指示信息用于指示终端状态恢复。
存储单元2202,用于存储所述请求更新的策略与计费控制规则或服务质量规则;
执行单元2203,用于在接收单元2201接收到第二指示信息时,对所述终端执行所述请求更新的所述终端的策略与计费控制规则或服务质量规则。
在一种可能的实现方式中,若接收单元2201在预设时间内未接收到所述第二指示信息,发送单元2204,用于向所述第二网络设备发送第三指示信息,所述第三指示信息用于指示终端当前处于挂起状态,以使所述第二网络设备不发送更新所述终端的策略与计费控制规则或服务质量规则的请求。
基于相同的技术构思,本申请实施例还提供了一种第一网络设备,用以实现上述方法实施例中第一网络设备所执行的方法流程。参见图23,为本申请实施例提供的一种第一网络设备的结构示意图,如图所示,该第一网络设备包括:处理器2301,以及与所述处理器2301连接的存储器2302和收发器2302;
所述处理器2301,用于读取所述存储器2302中预先存储的计算机程序执行:
通过所述收发器2302接收第一指示信息,所述第一指示信息用于指示终端当前处于挂起状态;
通过所述收发器2302接收第二网络设备发送的用于请求更新终端的策略与计费控制规则或服务质量规则的请求;
将所述请求更新的策略与计费控制规则或服务质量规则存储到所述存储器中;
当通过所述收发器2302接收到第二指示信息时,对所述终端执行所述请求更新的所述终端的策略与计费控制规则或服务质量规则,所述第二指示信息用于指示终端状态恢复。
在一种可能的实现方式中,所述处理器2301,还用于:
若在预设时间内未通过所述收发器2302接收到所述第二指示信息,通过所述收发器2302向所述第二网络设备发送第三指示信息,所述第三指示信息用于指示终端当前处于挂起状态,以使所述第二网络设备不发送更新所述终端的策略与计费控制规则或服务质量规则的请求。
本领域内的技术人员应明白,本申请的实施例可提供为方法、***、或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本申请是参照根据本申请的方法、设备(***)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
显然,本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样,倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内,则本申请也意图包含这些改动和变型在内。

Claims (30)

  1. 一种规则管理方法,其特征在于,包括:
    第一网络设备接收第一指示信息,所述第一指示信息用于指示终端当前处于挂起状态;
    所述第一网络设备向第二网络设备发送第二指示信息,所述第二指示信息用于指示所述终端当前处于挂起状态,以使所述第二网络设备不发送更新所述终端的策略与计费控制规则和/或服务质量规则的请求。
  2. 如权利要求1所述的方法,其特征在于,在所述第一网络设备向第二网络设备发送第二指示信息之后,还包括:
    所述第一网络设备接收第三指示信息,所述第三指示信息用于指示所述终端状态恢复;
    所述第一网络设备向所述第二网络设备发送第四指示信息,所述第四指示信息用于指示所述终端状态恢复,以使第二网络设备在需要更新所述终端的策略与计费控制规则和/或服务质量规则时,向所述第一网络设备发送更新所述终端的策略与计费控制规则或服务质量规则的请求。
  3. 如权利要求1或2所述的方法,其特征在于,在所述第一网络设备向第二网络设备发送第二指示信息之前,还包括:
    所述第一网络设备接收所述第二网络设备发送的第一请求,所述第一请求用于请求安装或更新所述终端的策略与计费控制规则或服务质量规则。
  4. 如权利要求3所述的方法,其特征在于,所述第一请求还用于请求订阅所述终端从挂起状态恢复为正常状态的信息,以使所述第一网络设备在所述终端从挂起状态恢复为正常状态时,将所述终端的状态信息发送给所述第二网络设备;或者
    所述第一请求还用于请求订阅所述终端的状态信息,以使所述第一网络设备在所述终端状态发生变化时将所述终端的状态信息发送给所述第二网络设备。
  5. 如权利要求1或2所述的方法,其特征在于,在所述第一网络设备向第二网络设备发送第二指示信息之前,还包括:
    所述第一网络设备接收所述第二网络设备发送的第二请求,所述第二请求用于订阅所述终端的状态信息,以使所述第一网络设备在所述终端状态发生变化时将所述终端的状态信息发送给所述第二网络设备;或者,所述第二请求用于订阅所述终端从挂起状态恢复为正常状态的信息,以使所述第一网络设备在所述终端从挂起状态恢复为正常状态时,将所述终端的状态信息发送给所述第二网络设备。
  6. 一种规则管理方法,其特征在于,包括:
    第一网络设备接收第二网络设备发送的第一指示信息,所述第一指示信息用于指示终端当前处于挂起状态;
    所述第一网络设备根据所述第一指示信息确定不发送更新所述终端的策略与计费控制规则和/或服务质量规则的请求。
  7. 如权利要求6所述的方法,其特征在于,在所述第一网络设备根据所述第一指示信息确定不发送更新所述终端的策略与计费控制规则和/或服务质量规则的请求之后,还包括:
    所述第一网络设备接收所述第二网络设备发送的第二指示信息,所述第二指示信息用于指示所述终端状态恢复;
    所述第一网络设备在需要更新所述终端的策略与计费控制规则和/或服务质量规则时,向所述第二网络设备发送更新所述终端的策略与计费控制规则或服务质量规则的请求。
  8. 如权利要求6或7所述的方法,其特征在于,在所述第一网络设备接收所述第二网络设备发送的第一指示信息之前,还包括:
    所述第一网络设备向所述第二网络设备发送第一请求,所述第一请求用于请求安装或更新所述终端的策略与计费控制规则或服务质量规则。
  9. 如权利要求8所述的方法,其特征在于,所述第一请求还用于订阅所述终端从挂起状态恢复为正常状态的信息,以使所述第二网络设备在所述终端从挂起状态恢复为正常状态时,将所述终端的状态信息发送给所述第一网络设备;或者
    所述第一请求还用于请求订阅所述终端的状态信息,以使所述第二网络设备在所述终端状态发生变化时将所述终端的状态信息发送给所述第一网络设备。
  10. 如权利要求6或7所述的方法,其特征在于,在所述第一网络设备接收所述第二网络设备发送的第一指示信息之前,还包括:
    所述第一网络设备向所述第二网络设备发送第二请求,所述第二请求用于请求订阅所述终端的状态信息,以使所述第二网络设备在所述终端状态发生变化时将所述终端的状态信息发送给所述第一网络设备;或者,所述第二请求用于订阅所述终端从挂起状态恢复为正常状态的信息,以使所述第一网络设备在所述终端从挂起状态恢复为正常状态时,将所述终端的状态信息发送给所述第二网络设备。
  11. 如权利要求6所述的方法,其特征在于,所述第一网络设备根据所述第一指示信息确定不发送更新所述终端的策略与计费控制规则和/或服务质量规则的请求,包括:
    所述第一网络设备根据所述第一指示信息确定不向所述第二网络设备发送更新所述终端的服务质量规则的请求;
    所述第一网络设备根据所述第一指示信息确定不向第三网络设备发送更新所述终端的策略与计费控制规则的请求。
  12. 如权利要求6或7所述的方法,其特征在于,在所述第一网络设备接收第二网络设备发送的第一指示信息之前,还包括:
    所述第一网络设备接收第三网络设备发送的第三请求,所述第三请求用于订阅所述终端的状态信息,以使所述第一网络设备在所述终端状态发生变化时将所述终端的状态信息发送给所述第三网络设备;
    在所述第一网络设备接收所述第二网络设备发送的第一指示信息之后,还包括:
    所述第一网络设备向所述第三网络设备发送第三指示信息,所述第三指示信息用于指示终端当前处于挂起状态,以使所述第三网络设备不向所述第二网络设备发送所述终端的下行数据。
  13. 如权利要求11所述的方法,其特征在于,在所述第一网络设备根据所述第一指示信息确定不发送更新所述终端的策略与计费控制规则和服务质量规则的请求之后,还包括:
    所述第一网络设备接收所述第二网络设备发送的第二指示信息,所述第二指示信息用于指示所述终端状态恢复;
    所述第一网络设备向第三网络设备发送第四指示信息,所述第二指示信息用于指示所述终端状态恢复,以使所述第三网络设备将所述终端的下行数据发送给所述第二网络设备。
  14. 一种规则管理方法,其特征在于,包括:
    第一网络设备接收第一指示信息,所述第一指示信息用于指示终端当前处于挂起状态;
    所述第一网络设备接收第二网络设备发送的用于请求更新终端的策略与计费控制规则 或服务质量规则的请求;
    所述第一网络设备存储所述请求更新的策略与计费控制规则或服务质量规则;
    当所述第一网络设备接收到第二指示信息时,所述第一网络设备对所述终端执行所述请求更新的所述终端的策略与计费控制规则或服务质量规则,所述第二指示信息用于指示终端状态恢复。
  15. 如权利要求14所述的方法,其特征在于,还包括:
    若所述第一网络设备在预设时间内未接收到所述第二指示信息,所述第一网络设备向所述第二网络设备发送第三指示信息,所述第三指示信息用于指示终端当前处于挂起状态,以使所述第二网络设备不发送更新所述终端的策略与计费控制规则或服务质量规则的请求。
  16. 一种网络设备,其特征在于,所述网络设备作为第一网络设备与第二网络设备进行通信;
    所述第一网络设备包括:处理器,以及与所述处理器连接的存储器和收发器;
    所述处理器,用于读取所述存储器中预先存储的计算机程序执行:
    通过所述收发器接收第一指示信息,所述第一指示信息用于指示终端当前处于挂起状态;
    通过所述收发器向所述第二网络设备发送第二指示信息,所述第二指示信息用于指示所述终端当前处于挂起状态,以使所述第二网络设备不发送更新所述终端的策略与计费控制规则和/或服务质量规则的请求。
  17. 如权利要求16所述的网络设备,其特征在于,所述处理器,在通过所述收发器向所述第二网络设备发送第二指示信息之后,还用于:
    通过所述收发器接收第三指示信息,所述第三指示信息用于指示所述终端状态恢复;
    通过所述收发器向所述第二网络设备发送第四指示信息,所述第四指示信息用于指示所述终端状态恢复,以使第二网络设备在需要更新所述终端的策略与计费控制规则和/或服务质量规则时,向所述第一网络设备发送更新所述终端的策略与计费控制规则或服务质量规则的请求。
  18. 如权利要求16或17所述的网络设备,其特征在于,所述处理器,在通过所述收发器向所述第二网络设备发送第二指示信息之前,还用于:
    通过所述收发器接收所述第二网络设备发送的第一请求,所述第一请求用于请求安装或更新所述终端的策略与计费控制规则或服务质量规则。
  19. 如权利要求18所述的网络设备,其特征在于,所述第一请求还用于订阅所述终端从挂起状态恢复为正常状态的信息,以使所述第一网络设备在所述终端从挂起状态恢复为正常状态时,将所述终端的状态信息发送给所述第二网络设备;或者
    所述第一请求还用于订阅所述终端的状态信息,以使所述第一网络设备在所述终端状态发生变化时将所述终端的状态信息发送给所述第二网络设备。
  20. 如权利要求16或17所述的网络设备,其特征在于,所述处理器,在通过所述收发器向第二网络设备发送第二指示信息之前,还用于:
    通过所述收发器接收所述第二网络设备发送的第二请求,所述第二请求用于订阅所述终端的状态信息,以使所述第一网络设备在所述终端状态发生变化时将所述终端的状态信息发送给所述第二网络设备;或者,所述第二请求用于订阅所述终端从挂起状态恢复为正常状态的信息,以使所述第一网络设备在所述终端从挂起状态恢复为正常状态时,将所述终端的状态信息发送给所述第二网络设备。
  21. 一种网络设备,其特征在于,所述网络设备作为第一网络设备与第二网络设备进行通信;
    所述第一网络设备包括:处理器,以及与所述处理器连接的存储器和收发器;
    所述处理器,用于读取所述存储器中预先存储的计算机程序执行:
    通过所述收发器接收第二网络设备发送的第一指示信息,所述第一指示信息用于指示终端当前处于挂起状态;
    根据所述第一指示信息确定不发送更新所述终端的策略与计费控制规则和/或服务质量规则的请求。
  22. 如权利要求21所述的网络设备,其特征在于,所述处理器,在根据所述第一指示信息确定不发送更新所述终端的策略与计费控制规则和/或服务质量规则的请求之后,还用于:
    通过所述收发器接收所述第二网络设备发送的第二指示信息,所述第二指示信息用于指示所述终端状态恢复;
    在需要更新所述终端的策略与计费控制规则和/或服务质量规则时,通过所述收发器向所述第二网络设备发送更新所述终端的策略与计费控制规则或服务质量规则的请求。
  23. 如权利要求21或22所述的网络设备,其特征在于,所述处理器,在通过所述收发器接收所述第二网络设备发送的第一指示信息之前,还用于:
    通过所述收发器向所述第二网络设备发送第一请求,所述第一请求用于请求安装或更新所述终端的策略与计费控制规则或服务质量规则。
  24. 如权利要求23所述的网络设备,其特征在于,所述第一请求还用于订阅所述终端从挂起状态恢复为正常状态的信息,以使所述第二网络设备在所述终端从挂起状态恢复为正常状态时,将所述终端的状态信息发送给所述第一网络设备;或者
    所述第一请求还用于请求订阅所述终端的状态信息,以使所述第二网络设备在所述终端状态发生变化时将所述终端的状态信息发送给所述第一网络设备。
  25. 如权利要求21或22所述的网络设备,其特征在于,所述处理器,在通过所述收发器接收所述第二网络设备发送的第一指示信息之前,还用于:
    通过所述收发器向所述第二网络设备发送第二请求,所述第二请求用于请求订阅所述终端的状态信息,以使所述第二网络设备在所述终端状态发生变化时将所述终端的状态信息发送给所述第一网络设备;或者,所述第二请求用于订阅所述终端从挂起状态恢复为正常状态的信息,以使所述第一网络设备在所述终端从挂起状态恢复为正常状态时,将所述终端的状态信息发送给所述第二网络设备。
  26. 如权利要求21所述的网络设备,其特征在于,所述处理器,在根据所述第一指示信息确定不发送更新所述终端的策略与计费控制规则和/或服务质量规则的请求时,具体用于:
    根据所述第一指示信息确定不向所述第二网络设备发送更新所述终端的服务质量规则的请求;
    根据所述第一指示信息确定不向第三网络设备发送更新所述终端的策略与计费控制规则的请求。
  27. 如权利要求21或22所述的网络设备,其特征在于,所述处理器,在通过所述收发器接收第二网络设备发送的第一指示信息之前,还用于:
    通过所述收发器接收第三网络设备发送的第三请求,所述第三请求用于订阅所述终端的状态信息,以使所述第一网络设备在所述终端状态发生变化时将所述终端的状态信息发送给 所述第三网络设备;
    所述处理器,在通过所述收发器接收所述第二网络设备发送的第一指示信息之后,还用于:
    通过所述收发器向所述第三网络设备发送第三指示信息,所述第三指示信息用于指示终端当前处于挂起状态,以使所述第三网络设备不向所述第二网络设备发送所述终端的下行数据。
  28. 如权利要求27所述的网络设备,其特征在于,所述处理器,在根据所述第一指示信息确定不发送更新所述终端的策略与计费控制规则和服务质量规则的请求之后,还用于:
    通过所述收发器接收所述第二网络设备发送的第二指示信息,所述第二指示信息用于指示所述终端状态恢复;
    通过所述收发器向第三网络设备发送第四指示信息,所述第二指示信息用于指示所述终端状态恢复,以使所述第三网络设备将所述终端的下行数据发送给所述第二网络设备。
  29. 一种网络设备,其特征在于,所述网络设备作为第一网络设备与第二网络设备进行通信;
    所述第一网络设备包括:处理器,以及与所述处理器连接的存储器和收发器;
    所述处理器,用于读取所述存储器中预先存储的计算机程序执行:
    通过所述收发器接收第一指示信息,所述第一指示信息用于指示终端当前处于挂起状态;
    通过所述收发器接收第二网络设备发送的用于请求更新终端的策略与计费控制规则或服务质量规则的请求;
    将所述请求更新的策略与计费控制规则或服务质量规则存储到所述存储器中;
    当通过所述收发器接收到第二指示信息时,对所述终端执行所述请求更新的所述终端的策略与计费控制规则或服务质量规则,所述第二指示信息用于指示终端状态恢复。
  30. 如权利要求29所述的网络设备,其特征在于,所述处理器,还用于:
    若在预设时间内未通过所述收发器接收到所述第二指示信息,通过所述收发器向所述第二网络设备发送第三指示信息,所述第三指示信息用于指示终端当前处于挂起状态,以使所述第二网络设备不发送更新所述终端的策略与计费控制规则或服务质量规则的请求。
PCT/CN2019/072032 2018-02-14 2019-01-16 一种规则管理方法及设备 WO2019157898A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP19755077.5A EP3755022B1 (en) 2018-02-14 2019-01-16 Rule management method and apparatus
US16/994,044 US20200374671A1 (en) 2018-02-14 2020-08-14 Rule Management Method And Device

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201810151832.1 2018-02-14
CN201810151832.1A CN110166962B (zh) 2018-02-14 2018-02-14 一种规则管理方法及设备

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/994,044 Continuation US20200374671A1 (en) 2018-02-14 2020-08-14 Rule Management Method And Device

Publications (1)

Publication Number Publication Date
WO2019157898A1 true WO2019157898A1 (zh) 2019-08-22

Family

ID=67619115

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2019/072032 WO2019157898A1 (zh) 2018-02-14 2019-01-16 一种规则管理方法及设备

Country Status (4)

Country Link
US (1) US20200374671A1 (zh)
EP (1) EP3755022B1 (zh)
CN (1) CN110166962B (zh)
WO (1) WO2019157898A1 (zh)

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101494848A (zh) * 2008-01-25 2009-07-29 华为技术有限公司 业务挂起的方法、业务恢复的方法、***及设备
CN103636163A (zh) * 2011-06-22 2014-03-12 瑞典爱立信有限公司 用于策略控制的方法和用于承载控制的方法以及对应的服务器、***和计算机程序
CN103781041A (zh) * 2012-10-18 2014-05-07 中兴通讯股份有限公司 计费同步方法、装置及***
CN105101139A (zh) * 2014-05-09 2015-11-25 中兴通讯股份有限公司 策略控制处理方法、装置及***
WO2016070579A1 (zh) * 2014-11-07 2016-05-12 中兴通讯股份有限公司 确定挂起业务的方法及装置、指示信息处理方法及装置
CN105900391A (zh) * 2013-02-28 2016-08-24 微软技术许可有限责任公司 使用restlike api进行实时通信
CN106656661A (zh) * 2016-11-30 2017-05-10 瑞斯康达科技发展股份有限公司 一种实现设备间线性保护机制互通的方法、装置及***
CN107079281A (zh) * 2014-09-26 2017-08-18 瑞典爱立信有限公司 用于处理更新的订户数据的方法和节点

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100414932B1 (ko) * 1998-01-24 2004-04-03 삼성전자주식회사 이동통신시스템의데이타통신방법
FI116187B (fi) * 2003-12-19 2005-09-30 Nokia Corp Keskeytystilan hallinta
US7924811B2 (en) * 2004-03-30 2011-04-12 Sony Ericsson Mobile Communications Ab Methods, systems and computer program products for suspending packet-switched sessions to a wireless terminal
WO2009136776A2 (ko) * 2008-05-09 2009-11-12 주식회사 포스데이타 광대역 무선 통신 시스템에서 정책 및 과금 제어 에러 핸들링 방법 및 이를 지원하는 장치
WO2010136070A1 (en) * 2009-05-29 2010-12-02 Telefonaktiebolaget Lm Ericsson (Publ) Policy and charging control method, network entities, communication system and computer program therefor
US8675487B2 (en) * 2010-06-28 2014-03-18 Alcatel Lucent System and method for generating and updating PCC rules based on service requests
WO2012131962A1 (ja) * 2011-03-30 2012-10-04 富士通株式会社 タスク実行制御装置、タスク実行制御システムおよびタスク実行制御方法
CN103686657B (zh) * 2012-09-11 2017-05-24 电信科学技术研究院 业务质量控制规则传递及更新方法和设备
KR102205907B1 (ko) * 2014-02-07 2021-01-21 삼성전자주식회사 이동 통신 시스템에서 서비스 제공 장치 및 방법
KR101539981B1 (ko) * 2014-02-11 2015-07-29 에스케이텔레콤 주식회사 이동 통신 시스템에서 단말의 위치 정보 보고 방법 및 이를 위한 장치
FR3022426A1 (fr) * 2014-06-16 2015-12-18 Orange Gestion par un equipement intermediaire de la qualite de transmission d'un flux de donnees vers un terminal mobile
US10004035B2 (en) * 2014-10-13 2018-06-19 Mediatek Inc. Method of managing data transmission for wireless system
WO2017078491A1 (ko) * 2015-11-06 2017-05-11 삼성전자 주식회사 Ciot 시스템에서 데이터 전송 방법 및 그 장치
US10321305B2 (en) * 2015-11-13 2019-06-11 Telefonaktiebolaget Lm Ericsson (Publ) Node and method for managing a packet data network connection and/or an internet protocol-connectivity access network session
CN108307443B (zh) * 2016-08-12 2022-12-06 北京三星通信技术研究有限公司 一种轻连接用户设备的业务控制的方法

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101494848A (zh) * 2008-01-25 2009-07-29 华为技术有限公司 业务挂起的方法、业务恢复的方法、***及设备
CN103636163A (zh) * 2011-06-22 2014-03-12 瑞典爱立信有限公司 用于策略控制的方法和用于承载控制的方法以及对应的服务器、***和计算机程序
CN103781041A (zh) * 2012-10-18 2014-05-07 中兴通讯股份有限公司 计费同步方法、装置及***
CN105900391A (zh) * 2013-02-28 2016-08-24 微软技术许可有限责任公司 使用restlike api进行实时通信
CN105101139A (zh) * 2014-05-09 2015-11-25 中兴通讯股份有限公司 策略控制处理方法、装置及***
CN107079281A (zh) * 2014-09-26 2017-08-18 瑞典爱立信有限公司 用于处理更新的订户数据的方法和节点
WO2016070579A1 (zh) * 2014-11-07 2016-05-12 中兴通讯股份有限公司 确定挂起业务的方法及装置、指示信息处理方法及装置
CN105635985A (zh) * 2014-11-07 2016-06-01 中兴通讯股份有限公司 确定挂起业务的方法及装置、指示信息处理方法及装置
CN106656661A (zh) * 2016-11-30 2017-05-10 瑞斯康达科技发展股份有限公司 一种实现设备间线性保护机制互通的方法、装置及***

Also Published As

Publication number Publication date
EP3755022A4 (en) 2021-04-07
CN110166962A (zh) 2019-08-23
EP3755022A1 (en) 2020-12-23
EP3755022B1 (en) 2023-08-23
US20200374671A1 (en) 2020-11-26
CN110166962B (zh) 2021-01-05

Similar Documents

Publication Publication Date Title
CN101583112B (zh) 会话信息的标识方法及装置
EP2493222B1 (en) Method and system for implementing usage monitoring control
EP2874347B1 (en) Charging control method and charging trigger function
US8799440B2 (en) Policy and charging control method and system for multi-PDN connections of single APN
CN102547640B (zh) 一种消费限制业务的签约和执行方法及***
JP6009076B2 (ja) 課金セッションを終了すべきことを判定するデバイスおよびそのシステム
EP2566197A1 (en) Policy application method for machine type communication and policy and charging enforcement function
CN102065402B (zh) 基于时段的策略和计费控制方法及***
WO2017219905A1 (zh) 一种计费方法、装置、***和存储介质
EP3364599B1 (en) Application charging method and system
EP2239884A1 (en) Pcc rules updating method, device and system
WO2010069170A1 (zh) 一种实现策略和计费控制的方法
EP2521305A1 (en) Method, device and system for controlling user session policy
CN102625272A (zh) 一种支持流检测功能的用量监控方法及***
CN106304195B (zh) 第三方应用的策略控制方法、scef和pcrf
WO2010148598A1 (zh) 一种基于用户当前所在时区的策略和计费控制方法及***
JP2017514338A (ja) 課金セッション管理方法および装置
CN103957542A (zh) 一种业务承载建立的方法及装置
WO2009138016A1 (zh) 信息传递方法、装置和***
WO2009056046A1 (fr) Procédé de fin de session
CN110650475B (zh) 一种会话绑定处理方法及网络设备
CN101742471B (zh) 一种数据流与接入网连接绑定的方法
WO2020048532A1 (zh) Gx会话异常的处理方法及装置
WO2019157898A1 (zh) 一种规则管理方法及设备
WO2010094188A1 (zh) 业务策略控制方法及***

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: 19755077

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: 2019755077

Country of ref document: EP

Effective date: 20200914