WO2012142953A1 - 一种永远在线能力的提供方法、系统和设备 - Google Patents

一种永远在线能力的提供方法、系统和设备 Download PDF

Info

Publication number
WO2012142953A1
WO2012142953A1 PCT/CN2012/074346 CN2012074346W WO2012142953A1 WO 2012142953 A1 WO2012142953 A1 WO 2012142953A1 CN 2012074346 W CN2012074346 W CN 2012074346W WO 2012142953 A1 WO2012142953 A1 WO 2012142953A1
Authority
WO
WIPO (PCT)
Prior art keywords
always
service
session
capability
information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/CN2012/074346
Other languages
English (en)
French (fr)
Inventor
朱琳
苑红
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
China Mobile Communications Group Co Ltd
Original Assignee
China Mobile Communications Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by China Mobile Communications Corp filed Critical China Mobile Communications Corp
Publication of WO2012142953A1 publication Critical patent/WO2012142953A1/zh
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/20—Manipulation of established connections
    • H04W76/25—Maintenance of established connections

Definitions

  • the invention provides a method, system and device for providing an always-on capability.
  • the application is submitted to the Chinese Patent Office on April 19, 2011, and the application number is 201110097754.X.
  • the invention is entitled "A method, system and device for providing an always-on capability.
  • the priority of the Chinese Patent Application the entire contents of which is incorporated herein by reference.
  • TECHNICAL FIELD The present invention relates to the field of communications technologies, and in particular, to a method, system, and device for providing an always-on capability. BACKGROUND With the rapid development of communication technologies, the network is increasingly open.
  • always-on business such as instant chat service, social network service, mail push service, etc.
  • the above-mentioned always-on business reflects the operability between the user and the server.
  • the impact of the network on the user when the user uses the service needs to know whether the user is still connected to the server.
  • users use the always-on service, they do not want to feel the delay caused by the network condition or the server status, and when the high-burst data occurs, the always-online service can be quickly responded.
  • the method for the server of the always-on-line service to know the connection state between the user and the server is: the server receives the online presence information (ie, a keep alive message) from the user, and when the server receives the heartbeat of the user In the case of the package, it proves that the user is still connected to the server, and determines the state of the user online, thereby realizing the feature of always-on.
  • the online presence information ie, a keep alive message
  • the existing wireless network mechanism is designed according to the application of the user using intermittent and large data volume, and after the user is silent for a period of time, the network The side will release resources and no longer provide the always-on capability.
  • the heartbeat packet mechanism is needed to maintain the online capability.
  • the heartbeat packet is often short, the data volume is small, and only the user part information is included.
  • the transmission interval is longer; therefore, a large amount of signaling is consumed, and network resources are occupied.
  • an embodiment of the present invention provides a method for providing an always-online capability, including the following steps: receiving an always-on service request information from a service server, where the request information carries user information corresponding to an always-on service;
  • the network device maintains the always-on capability for the IP-CAN session corresponding to the user information.
  • An embodiment of the present invention provides a method for providing an always-online capability, including the following steps: receiving a request notification of an always-on service from a PCRF, where the request notification carries an always-online service information, and the request is an always-online service IP-CAN session. Maintaining information for always-on capabilities; maintaining an always-on capability for the IP-CAN session of the always-on service.
  • the embodiment of the present invention provides a policy and charging rule function entity PCRF, which includes: a receiving module, configured to receive always-on service request information from a service server, where the request information carries user information corresponding to an always-on service; And for informing the core network device to maintain the always-online capability for the IP-CAN session corresponding to the user information.
  • PCRF policy and charging rule function entity
  • An embodiment of the present invention provides a core network device, including: a receiving module, configured to receive a request notification of an always-on service from a PCRF, where the request notification carries an always-online service information, and the request is an always-online service IP-CAN session. Information for maintaining the always-on capability; a capability retention module for maintaining an always-on capability for the IP-CAN session of the always-on service.
  • the embodiment of the invention provides a system for providing always-on capabilities, including the above-mentioned policy and charging rule function entity PCRF, and the above-mentioned core network device.
  • FIG. 1 is a schematic diagram of a PCC architecture in the prior art
  • FIG. 2 is a schematic diagram of a prior art center packet
  • FIG. 3 is a schematic diagram of an application scenario according to various embodiments of the present invention
  • FIG. 4 is a schematic diagram of an online process for always-online service according to Embodiment 1 of the present invention.
  • FIG. 5 is a schematic diagram of an IP-CAN session release process for an always-on service according to Embodiment 2 of the present invention.
  • FIG. 6 is a schematic flowchart of the offline operation of the always-online service according to Embodiment 3 of the present invention.
  • FIG. 7 is a schematic structural diagram of a PCRF according to Embodiment 4 of the present invention.
  • FIG. 8 is a schematic structural diagram of a core network device according to Embodiment 5 of the present invention.
  • a schematic diagram of a PCC (Policy and Charging Control) architecture shown in FIG. 1 is defined to support QoS (Quality of Service) control, charging control, and threshold control of a service flow.
  • the PCC architecture can support the provision of a service-based PCC policy for each service flow, including the flow rules, authorized QoS, etc. to the PCEF, and the PCEF (Policy and Charging Enforcement Function) QoS guarantee for traffic flow.
  • Policy and Charging Control Policy and Charging Control
  • the QoS authorization of the service flow can be generated based on factors such as the service type, the user subscription data, and the preset policy on the Policy and Charging Rules Function (PCRF), and can support the event reporting based on the service flow.
  • PCRF Policy and Charging Rules Function
  • the main network elements include: PCRF, PCEF, SPR (Subscription Profile Repository), AF (Application Function, Application Function), etc., where:
  • PCRF which is the core of PCC, is responsible for policy decision making and billing rules.
  • the PCRF acquires the policy and charging control subscription information of the user from the SPR according to the information related to the service obtained from the AF, and acquires the bearer related information from the PCEF/BBERF (Bearing Binding and Event Report Function).
  • Network information such as IP-CAN (IP-Connectivity Access Network) type, user's location information
  • the foregoing policy and charging control mainly include detection of service data flow, gating, QoS control, and charging rules based on data flows.
  • PCEF a functional logic entity for policy and accounting, located within the gateway.
  • the PCEF detects the service data flow according to the service data flow filter in the PCC rule delivered by the PCRF, and executes the policy and the gate control to predict the flow-based charging.
  • SPR is a logical node that stores all user subscription information.
  • the subscription information can be used by the PCRF to perform contract-based policy control and PCC policy control of the IP CAN bearer layer.
  • the SPR can provide the following subscription information for each PDN (Public Data Network): user-signed service, preemption priority of each contracted service, user-signed QoS (such as guaranteed bandwidth QoS), User's billing related information (such as location information related to billing), user category.
  • PDN Public Data Network
  • AF such as P-CSCF (Proxy Call Session Control Function) of IMS (IP Multimedia Subsystem, IP Multimedia System) network
  • P-CSCF Proxy Call Session Control Function
  • IMS IP Multimedia Subsystem, IP Multimedia System
  • the AF communicates with the PCRF to send dynamic session information to the PCRF for policy control decisions.
  • the AF also receives information about IP CAN reported by the PCRF and event notification.
  • the existing network resource management mechanism is: Only when the user has business requirements, The bearer is established (for example, the PDP is activated), and the corresponding radio resource bearer is established. When the user is silent for a certain period of time, that is, when the user does not have a service within a certain period of time, the network side actively deletes the bearer (such as deactivating the PDP). To save network resources.
  • the PCC related technology has completed the basic service flow resource guarantee and the flow charging policy, and can provide differentiated services to users to a certain extent. It mainly includes: policy negotiation, decision and execution when the bearer is established, policy modification, and policy cancellation when the bearer is released.
  • the above process can handle the policy management of the bearer-related and session-independent types of services, which can be triggered by a bearer setup request trigger, or a PCEF trigger, or a change of the subscription information of the user, or a service request sent by the AF.
  • the PCRF it only passively accepts the request to establish, modify, and terminate, and then formulates or terminates the corresponding policy based on the business information.
  • For the bearer maintenance of specific services (such as the service with always-on features), there is no relevant solution so far.
  • the existing network does not maintain the state of always-online services.
  • the packet domain network does not provide the status management of the corresponding bearer for the service, and does not have the capability of providing the service always online.
  • a packet domain network architecture it is capable of supporting a service-based provision for each service flow.
  • the PCC policy but the PCC policy only includes the flow rule, the authorized QoS, etc., and the PCEF that accepts the PCC policy performs the QoS guarantee for the service flow; when the user has the service request, the IP-CAN is activated, and the user is in the IP-CAN After the user is silent for a period of time, the network side releases IP-CAN (IP unreachable in the core network); due to NAT (Network Address Translation) penetration mechanism, the PDN side network Resources (such as public network addresses) are also released.
  • IP-CAN IP unreachable in the core network
  • NAT Network Address Translation
  • the network cannot sense the existence of the always-on service. Therefore, the online service feature cannot be maintained. As a result, the always-online service needs to rely on the heartbeat packet to maintain the connection state, occupy a large amount of network resources, and affect the normal operation of other services. And reduce the operator network service quality and customer experience.
  • the existing network does not maintain the state of the always-on service.
  • the always-on service message depends on the heartbeat packet mechanism.
  • the time interval of the heartbeat packet exceeds the duration of the IP-CAN release or the re-allocation of the radio side resources, so that the always-on service is sent.
  • reallocating the wireless side resources causes the terminal to exchange signaling with the core network element, and the state of the terminal changes rapidly due to the characteristics of the heartbeat packet.
  • the schematic diagram of the packet hopping in the prior art center when the terminal sends the heartbeat packet, because the granularity of the control of the system is small, the resource is quickly released in the interval of the heartbeat packet similar to the impact, and when When the heartbeat packet is sent, the resources are re-allocated, and a large amount of signaling is generated during the heartbeat packet, which may affect the functions such as RRC (Radio Resource Control) control.
  • RRC Radio Resource Control
  • an increase in the PS (Packet Domain) RAB (Radio Access Bear) setup request causes a significant increase in the load of the RNC (Radio Network Controller) signaling processing module, while the overall user
  • the packet service data and signaling traffic increase significantly, and even the overload of the load may even affect the normal use of the user circuit domain service.
  • the embodiments of the present invention provide a method, system, and device for providing an always-online capability, and an always-online service policy and network providing capability are introduced in the PCC architecture.
  • the always-online service server can be used.
  • the always-online application status is reported to the PCRF through the always-on service AF.
  • the PCRF makes flexible and accurate decisions based on the reported always-on service status and other services and session information, and enables the user to open the always-online capability on the network side and cancel the heartbeat of the service side.
  • the first embodiment of the present invention provides a method for providing an always-online capability, which is applied to a 2G/3G system or an LTE system based on a PCC architecture.
  • the core network device in this embodiment includes a GGSN (Gateway).
  • GPRS Support Node GPRS Support Node
  • the core network device in this embodiment includes a PDN GW (Public Data Network Gateway), and the LTE system is used as an example.
  • PDN GW Public Data Network Gateway
  • the AF entities in the PCC architecture can be deployed separately, integrated on the business server, integrated on the PCRF, or integrated on other devices.
  • the online process of the always-on service includes the following steps:
  • Step 401 When the user equipment activates the always-on service through the existing bearer, the service server provides the always-on service for the user equipment.
  • the service server is an application server for always-on services, such as an application server for always-on services such as QQ and MSN.
  • Step 402 The service server sends the always-online service request information to the PCRF through the AF corresponding to the always-on service.
  • the service server directly sends the always-on service request information to the PCRF.
  • the service server may send the always-on service request information to the PCRF through the AF to notify the PCRF to activate the corresponding always-on service.
  • the request information carries at least the always-on service identifier and user information (such as the user equipment IP address) corresponding to the always-on service.
  • Step 403 After receiving the always-on service request information from the service server, the PCRF passes the It is known that the core network device maintains the always-online capability for the IP-CAN session corresponding to the user information.
  • Manner 1 Determine whether the IP-CAN session bearer always-online capability corresponding to the user information is activated by querying the pre-maintained service tag information. If the IP-CAN session bearer always-online capability corresponding to the user information is activated (IP- corresponding to the user information)
  • IP- corresponding to the user information IP- corresponding to the user information
  • the CAN session can always be online to correspond to multiple types of always-on services of the user equipment, and the IP-CAN session carrying the always-on capability activation state can be set to an active state during the request process of other always-on services.
  • the core network device adopts the first type of mode (the core network device notifies the NAT function entity not to release the always-online service corresponding public network address) to maintain the always-online capability of the IP-CAN session corresponding to the user information (based on the first type of request notification) A message carrying the always-on online service information and processing in the first type of manner); if the IP-CAN bearer always-on capability corresponding to the user information is not activated, the core network device is notified to adopt the second type of mode (the NAT is notified by the core network device) The functional entity does not release the always-online service corresponding to the public network address, and keeps the right The IP-CAN session should not be released.
  • the IP-CAN session for the user information is always online.
  • the second type of request notification carries the always-on service information, IP-CAN session information, and the second type. Mark for processing).
  • the PCRF is stored (eg, stored in a table manner) and the service tag information is maintained, and the service tag information records user information corresponding to the always-on service (ie, user attribute information, such as an IP address, etc.), IP-CAN. Session information, IP-CAN session bearer activation or non-alive status information of the always-on capability, always-on service bearer activation status (ie bearer is active or bearer is inactive), and service server attribution (determinable by always-on service identifier) Correspondence of ).
  • user attribute information such as an IP address, etc.
  • IP-CAN IP-CAN. Session information, IP-CAN session bearer activation or non-alive status information of the always-on capability, always-on service bearer activation status (ie bearer is active or bearer is inactive), and service server attribution (determinable by always-on service identifier) Correspondence of ).
  • the IP-CAN session bearer always-on capability corresponding to the user information is activated in the service tag information, such as The IP-CAN session corresponding to the user information in the service tag information is not activated when the always-online capability is carried.
  • Manner 2 By querying the pre-maintained service tag information to determine whether the IP-CAN session bearer always-online capability corresponding to the user information is activated, the IP-CAN session bearer always-online capability corresponding to the user information is activated or not activated, and the PCRF notifies
  • the core network device maintains the always-online capability for the IP-CAN session corresponding to the user information (the notification carries the always-online service information, IP-CAN
  • the session information is determined by the core network device to determine the always-online capability of the IP-CAN session corresponding to the user information in the first type or the second type.
  • the PCRF when the IP-CAN session bearer always-online capability corresponding to the user information is not activated, the PCRF needs to be in the process of notifying the core network device that the IP-CAN session corresponding to the user information maintains the always-online capability.
  • the IP-CAN session bearer always-on capability corresponding to the user information is modified to the IP-CAN session bearer always-on capability activation state; and the always-on service bearer is modified to the always-on service bearer activation state.
  • the PCRF also needs to modify the always-on service bearer to the always-on service bearer activation state.
  • Step 404 The core network device receives the request notification of the always-on service from the PCRF, and maintains the always-on capability for the IP-CAN session corresponding to the always-on service.
  • the core network device can receive the request notification of the always-on service, where the request notification carries the IP that is requested to be an always-on service.
  • the CAN session maintains the information of the always-on capability (ie, the always-on service bearer capability request).
  • the core network device learns that it needs to maintain the always-on capability for the IP-CAN session.
  • other information can be carried in the request notification for different processing methods.
  • the core network device for the first mode, if the IP-CAN session corresponding to the user information is activated, the core network device has previously maintained the other types of always-on services corresponding to the IP-CAN session. Always-online capability, and because the public network address corresponding to different services is different, the core network device only needs to notify the NAT function entity not to release the public network address corresponding to the always-on service, and can maintain the IP-CAN session for the current permanent online service forever. ability.
  • the request notification based on the first type of notification mode carries the always-on service information and the token processed by the first type of manner.
  • the core network device receives the notification of the request, it can directly notify the NAT function entity not to release the always-online.
  • the public network address corresponding to the service (according to the information of the always-on business).
  • the IP-CAN session bearer always-on capability corresponding to the user information is not activated, it indicates that the core network device has not been permanently maintained for other types of always-on services corresponding to the IP-CAN session.
  • the remote network capability the core network device needs to notify the NAT function entity not to release the public network address corresponding to the always-on service, and keep the corresponding IP-CAN session not released (if not actively initiate the PDP deactivation process), thereby being the current always online.
  • the IP-CAN session of the service remains always online.
  • the request notification based on the second type of notification method carries the always-on service information, the IP-CAN session information, and the token processed by the second type.
  • the NAT can directly notify the NAT.
  • the functional entity does not release the public network address corresponding to the always-on service (known from the always-on service information), and keeps the IP-CAN session (known according to the IP-CAN session information) from being released.
  • the core network device itself determines that the IP-CAN session of the current always-on service maintains the always-online capability, and the request notification carries the always-online service information and the IP-CAN session information; and the request notification is not carried.
  • the mark processed in the first and second modes therefore, when receiving the request notification for maintaining the always-on capability for the IP-CAN session, the core network device determines that the bearer corresponding to the IP-CAN session is always online according to the IP-CAN session information.
  • the capability is activated or not activated (it can be judged by judging whether the IP-CAN session has been maintained forever online). If the bearer always-on capability of the IP-CAN session is activated, the core network device notifies the NAT function entity not to release.
  • the always-on service corresponds to the public network address. If the bearer-on-line capability of the IP-CAN session is not activated, the core network device notifies the NAT function entity that the public network address of the always-on service is not released, and the corresponding IP-CAN session is not released.
  • the core network device changes the corresponding IP-CAN session to the always-online service bearer, and maintains the always-online capability for the IP-CAN session (including notifying the NAT function entity not to release the public network address, and / or, keep the corresponding IP-CAN session not released, etc.).
  • Step 405 The core network device returns information to the PCRF to confirm that the current always-online service bearer has the capability of always-online service.
  • Step 406 The PCRF notifies the AF that the always-online capability has been activated for the current always-on service (that is, the permanent online service processed as described above).
  • the PCRF after receiving the acknowledgment that the current permanent online service bearer has the always-on service bearer capability returned by the core network device, the PCRF also needs to maintain the service tag information. If the IP-CAN session bearer always-on capability corresponding to the user information is activated, the service tag information is already recorded.
  • the information about the always-online capability of the IP-CAN session is recorded, and the PCRF maintains the current information about the always-on service in the service tag information; if the IP-CAN session bearer always-online capability of the user information is not activated, the service
  • the PCRF records the activated always-on service tag corresponding to the IP-CAN session in the service tag information, and the tag includes the user information corresponding to the always-on service
  • the always-on service carries the activation status, the IP-CAN session information, the service server attribution, and the like, and indicates the activation on the always-on service bearer activation state, thereby implementing the process of always-online online.
  • an always-on-line service notification function is added to the service server (AF)
  • a service tag function is added to the PCRF
  • a state management function of the bearer is added to the core network device, and the core network side provides
  • the always-online service bears the NAT public network address and does not release the IP-CAN session.
  • the embodiment of the present invention improves the processing of the always-on-line service of the core network, and effectively solves the problem that the service can be always provided online in the existing solution, and the service side needs to maintain the always-on state through the "heartbeat packet", causing Excessive signaling load problems.
  • the IP-CAN session release process of the always-on service includes the following steps:
  • Step 501 The user equipment initiates a release of the IP-CAN session flow to the core network device (eg, the PDP context is deactivated).
  • Step 502 After receiving the IP-CAN request, the core network device determines whether the IP-CAN session bearer is an always-on service bearer.
  • the reason is non-resistance (such as the user equipment is powered off, shut down, etc.) (ie, the release process caused by the user equipment being offline) , go to step 503; otherwise, go to step 504.
  • Step 503 The core network device caches a message sent by the service server to the user equipment. After that, the core network device waits for the keep-alive of the always-on service bearer, and re-sends the cached content to the user equipment after the bearer keep-alive of the always-on service is successful; or if the always-on online service fails or does not perform forever
  • the far-end service carries the keep-alive, and the core network device can delete the corresponding cached content.
  • Step 504 The core network device notifies the PCRF to release the IP-CAN session.
  • Step 505 After receiving the request for releasing the IP-CAN session, the PCRF determines, from the service tag information, whether the bearer of the IP-CAN session already has an always-on service, and if yes, performs step 506; otherwise, performs an existing release IP. -CAN process.
  • the existing process for releasing the IP-CAN includes: the PCRF identifies the affected PCC policy, and the core network device deletes all the corresponding policies and charging rules, and the PCRF notifies the AF of the transmission loss and confirms the release of the IP to the core network device.
  • the core network device responds to the IP-CAN session release request initiated by the UE, and the process of releasing the IP-CAN ends. This process is not described in detail in the embodiment of the present invention.
  • Step 506 The PCRF selects a policy that does not perform an always-on service bearer keep-alive policy or selects a policy for performing an always-on service bearer.
  • Step 507 The PCRF notifies the core network device to confirm that the user equipment releases the IP-CAN message, where the message includes the confirmation that the core network device in step 504 notifies the PCRF to release the IP-CAN session, and whether to perform or not perform the always-on service bearer keep-alive Strategy.
  • the PCRF may select any one of the foregoing two policies according to the actual needs.
  • the core network device When the PCRF chooses not to perform the policy of the always-on service bearer, the core network device only performs the release of the IP-CAN process after receiving the policy information. And performing step 509; when the PCRF selects to execute the policy of the always-on service bearer, the core network device performs the release of the IP-CAN process after receiving the policy information, and performs a reactivation of the always-on service IP-CAN session flow.
  • the process of releasing the IP-CAN is not described in the embodiment of the present invention.
  • IP-CAN session the following includes: After the PDP context deactivation process ends, the core network device initiates the IP of the always-on service.
  • the CAN session reactivation process, the core network device, the PCRF, and the like perform an IP-CAN session reactivation process for the always-on service.
  • the core network device needs to notify the NAT function entity that the public network address corresponding to the always-on service is not released (that is, the public network address used for the always-on service is not released), and the IP-CAN session is not released (if the PDP is not actively initiated).
  • the deactivation process); the PCRF needs to record the information about the IP-CAN session in the service tag information, so as to maintain the always-online capability for the IP-CAN session information of the always-on service on the PCRF and the core network device, the process and the embodiment The process of one is similar, in This is not detailed here.
  • Step 508 The core network device returns an acknowledgement message to the PCRF, where the acknowledgement message includes an execution result of the IP-CAN session reactivation of the always-on service, such as an IP-CAN session reactivation success or failure.
  • Step 509 after receiving the confirmation message, if the IP-CAN session reactivation is successful, the process ends. If the IP-CAN session reactivation fails, the PCRF notifies the AF that the always-online service corresponding to the IP-CAN session is offline, by the AF. Notify the corresponding service server that the always-online service is offline, and confirm to the PCRF that the always-online service is offline.
  • the PCRF may also verify that the service tag information corresponding to the always-online service is updated, that is, if the policy is not performing the always-on service bearer, the service tag information of the service corresponding to the IP-CAN session is always online.
  • the service bearer activation state is to deactivate or delete the corresponding service tag information.
  • the service tag information of the service corresponding to the IP-CAN session is updated according to the confirmation message in step 508, that is, if the IP-CAN session reactivation is successful in the confirmation message, the process ends; If the IP-CAN session reactivation fails in the confirmation message, the corresponding service tag information is deleted.
  • a new caching mechanism is added to the core network device, and a decision mechanism for always-on-line service bearer is established on the PCRF, and two IP-CAN session release processing methods for the always-on-line service are newly established on the PCRF.
  • Adding the always-on service notification function to the AF so that the IP-CAN session release mode can be provided for the always-on service in the scenario of the hybrid network in the packet domain, so that the service server does not sense the abnormal disconnection state of the user. , saving the resource of the service server re-finding the user equipment and re-logging the user equipment.
  • the always-online service offline process includes the following steps:
  • Step 601 The user equipment deactivates the always-on service, and the corresponding service server stops providing the always-on service for the user equipment.
  • Step 602 The online service is always offline, and the service server passes the AF corresponding to the always-on service.
  • the always-on service deactivation information is sent to the PCRF.
  • the service server directly sends the always-on service deactivation information to the PCRF.
  • the deactivation information carries at least the always-on service identifier and user information (such as the user equipment IP address) corresponding to the always-on service.
  • Step 603 After receiving the always-on service deactivation information from the service server, the PCRF notifies the core network device that the IP-CAN session corresponding to the user information is always online.
  • Manner 1 Determine whether there are other permanent online services in the IP-CAN session corresponding to the user information by querying the pre-maintained service tag information (each IP-CAN session can correspond to multiple always-on services, for example, the IP of the user device 1)
  • the CAN session can correspond to the always-online service 1 and the always-online service 2.
  • the IP-CAN session After receiving the deactivation information of the always-on service 1, if the IP-CAN session for querying the service tag information also corresponds to the always-on service 2, then the IP- There are other always-on services in the CAN session. If there is no other always-online service in the IP-CAN session that queries the service tag information, there is no other always-on service in the IP-CAN session. If there is no other always-on online.
  • the PCRF notifies the core network device to adopt the third type of mode (the core network device notifies the NAT function entity to enable the public network address management mode for the always-on service, and modifies the IP-CAN session to the IP-CAN session of the data service) IP-
  • the always-on capability of CAN sessions (based on the third type of deactivation notifications that are always online
  • the PCRF notifies the core network device to adopt the fourth type of mode (the core network device notifies the NAT function entity)
  • the public network address management mode is enabled for the always-on service.
  • the always-online capability of the IP-CAN session is revoked (the flag of the fourth type of deactivation notification carries the always-on service information and is processed in the fourth type).
  • Manner 2 When querying the pre-maintained service tag information to determine whether the IP-CAN session corresponding to the user information exists or does not exist other permanent online services, the PCRF notifies the core network device core network device to revoke the always-on capability of the IP-CAN session (the The notification carries the always-online service information, the IP-CAN session corresponding to the always-on service, and the core network device determines the permanent-online capability of the third-class or fourth-class way to sell the IP-CAN session.
  • Step 604 The core network device receives a deactivation notification of the always-on service from the PCRF, and The always-on capability of the IP-CAN session corresponding to the always-on business.
  • the core network device may receive a deactivation notification, where the deactivation notification message carries the request for the always-online service.
  • the IP-CAN session 4 transmits the information of the always-on capability (ie, the always-on service bearer deactivation request), and according to the always-on service bearer capability deactivation request, the core network device learns that the always-online capability needs to be revoked for the IP-CAN session.
  • the deactivation notification may carry other information for different processing methods.
  • the third-type deactivation notification carries the always-on service information, the IP-CAN session corresponding to the always-on service, and the mark processed by the third-type manner, when receiving the
  • the core network device notifies the NAT function entity to enable the public network address management mode for the always-on service, and modifies the IP-CAN session to The IP-CAN session of the data service (that is, the corresponding IP-CAN session is changed to the existing data service bearer mode. For example, when the user is idle for a period of time, the PDP context can be actively initiated from the core network side to be activated).
  • a tag based on the fourth type of deactivation notification that carries the always-on service information message and processes in the fourth type, and receives the always-online capability of the IP-CAN session in the fourth type from the PCRF.
  • the core network device When the notification is deactivated, the core network device notifies the NAT function entity to enable the public network address management mode for the always-on service.
  • the core network device itself determines the way to revoke the always-online capability of the IP-CAN session, and the deactivation notification carries the always-online service information, the IP-CAN session corresponding to the always-on service, and receives the deactivation from the PCRF. After the notification, the core network device determines whether there are other always-on services in the IP-CAN session; if there are no other always-on services, the core network device notifies
  • the NAT function entity enables the public network address management mode for the always-on service and modifies the IP-CAN session to the IP-CAN session of the data service. If there are other always-on services, the core network device notifies the NAT function entity to enable the always-on service. Network address management method.
  • Step 605 The core network device returns information to the PCRF to confirm that the current always-on service bearer capability is deactivated, and the existing data service policy is executed.
  • Step 606 the PCRF notifies that the AF has been the current always-on service (that is, the above-mentioned processing is forever Far online business) to activate the always-on ability.
  • the PCRF also needs to modify the service tag information of the always-on service corresponding to the IP-CAN session, and indicate the deactivation on the corresponding permanent-online service bearer activation state, when all the service tag information corresponding to an IP-CAN session
  • the active online bearer activation status is deactivated, the corresponding service tag can be deleted, thereby implementing the process of always online service offline.
  • an offline processing mode is provided for the always-online service in a scenario of a packet-domain hybrid networking, and can be restored when the always-online capability is not required for the always-online service.
  • IP-CAN sessions for common services save network resources.
  • a policy and charging rule function entity PCRF is also proposed in the embodiment of the present invention, including:
  • the receiving module 11 is configured to receive the always-on service request information from the service server, where the request information carries the user information corresponding to the always-on service;
  • the notification module 12 is configured to notify the core network device to maintain the always-on capability for the IP-CAN session corresponding to the user information.
  • the notification module 12 is specifically configured to notify the core network device to use the first type of manner to maintain the IP-CAN session corresponding to the user information if the IP-CAN session bearer always-on capability corresponding to the user information is activated. For example, if the IP-CAN session bearer always-on capability corresponding to the user information is not activated, the core network device is notified to use the second type to maintain the always-online capability for the IP-CAN session corresponding to the user information. Or,
  • the method further includes: an obtaining module 13, configured to learn, corresponding to the user information
  • the pre-maintained service tag information is queried according to the user information, and the service tag information records user information, IP-CAN session information, IP-CAN session bearer activation or not Activate status information for always-on capabilities, always online business Corresponding relationship of the live state information; and learning, according to the query result, that the IP-CAN session carrying the always-online capability corresponding to the user information is an activated state or an inactive state.
  • the method further includes: a first processing module, configured to: when it is learned from the request information for releasing the IP-CAN session from the core network device, that the bearer of the IP-CAN session already exists for the always-on service, Not executing the policy of the always-on service bearer, notifying the selected network policy to the core network device, performing a process of releasing the IP-CAN session with the core network device, and notifying the service server of the IP-CAN session Always online business offline.
  • a first processing module configured to: when it is learned from the request information for releasing the IP-CAN session from the core network device, that the bearer of the IP-CAN session already exists for the always-on service, Not executing the policy of the always-on service bearer, notifying the selected network policy to the core network device, performing a process of releasing the IP-CAN session with the core network device, and notifying the service server of the IP-CAN session Always online business offline.
  • the second processing module 15 is configured to select a policy for performing an always-on service bearer keep-alive when it is learned from the request information for releasing the IP-CAN session from the core network device that the bearer of the IP-CAN session already exists for the always-on service. Notifying the selected network policy to the core network device, and performing a process of releasing the IP-CAN session with the core network device, and re-activating the IP-CAN session of the always-on service; if the IP-CAN is always online service The session reactivation fails, and the service server is notified that the 7 j far online service corresponding to the IP-CAN session is offline.
  • the receiving module 11 is further configured to receive the always-on service deactivation information from the service server, where the deactivation information carries the user information corresponding to the always-on service;
  • the notification module 12 is further configured to notify the core network device to cancel the always-on capability of the IP-CAN session by using a third type when the IP-CAN session corresponding to the user information does not have other permanent online services; or When the IP-CAN session corresponding to the user information has other permanent online services, notify the core network device to cancel the always-once capability of the IP-CAN session by using the fourth type manner, or
  • the embodiment of the present invention further provides a core network device.
  • the core network device includes:
  • the receiving module 21 is configured to receive a request notification of an always-on service from the PCRF, where the IP-CAN session that carries the always-on service information and requests the always-on service is kept forever Information about far-line capabilities;
  • the capability retention module 22 is configured to maintain an always-on capability for the IP-CAN session of the always-on service.
  • the capability maintaining module 22 is configured to notify the NAT function entity not to release the public network address corresponding to the always-on service when receiving the request notification that the IP-CAN session is maintained in the first-class manner. Receiving the request notification carrying the IP-CAN session information for the IP-CAN session to maintain the always-online capability in the second type, notifying the NAT function entity not to release the public network address corresponding to the always-on service, and maintaining the IP- CAN session is not released; or,
  • the NAT function entity When receiving the request notification carrying the IP-CAN session information for the IP-CAN session to maintain the always-on capability, determining, according to the IP-CAN session information, that the bearer always-on capability corresponding to the IP-CAN session is activated or not activated, the NAT function entity is notified not to release the public network address corresponding to the always-on service; when the bearer always-online capability corresponding to the IP-CAN session is not activated, the notification is The NAT function entity does not release the public network address corresponding to the always-on service, and keeps the IP-CAN session not released.
  • the method further includes: a first processing module 23, configured to: when it is learned from the request information for releasing the IP-CAN session from the user equipment, that the bearer of the IP-CAN session is an always-on service bearer, the cache service The content sent by the server to the user equipment; after the bearer of the always-on service is successfully saved, the cached content is sent to the user equipment; or, when the bearer of the always-on service fails, or the bearer of the always-on service is not performed When you keep alive, delete the cached content.
  • a first processing module 23 configured to: when it is learned from the request information for releasing the IP-CAN session from the user equipment, that the bearer of the IP-CAN session is an always-on service bearer, the cache service The content sent by the server to the user equipment; after the bearer of the always-on service is successfully saved, the cached content is sent to the user equipment; or, when the bearer of the always-on service fails, or the bearer of the always-on service is not performed When you keep alive, delete
  • the embodiment of the present invention further includes: a second processing module 24, configured to send, when the bearer of the IP-CAN session is an always-on service bearer, from the request information for releasing the IP-CAN session from the user equipment, send the signal to the PCRF Releasing the request information of the IP-CAN session; receiving a policy from the PCRF that does not perform the always-on service bearer keep-alive, and performing a process of releasing the IP-CAN session with the PCRF; or receiving the execution from the PCRF forever
  • the online service carries a keep-alive policy, and performs a process of releasing the IP-CAN session with the PCRF, and re-activating the IP-CAN session of the always-on service.
  • the device further includes: a capability revocation module 25, configured to notify the NAT function when receiving the deactivation notification of the always-on capability from the PCRF using the third-class mode 4, the IP-CAN session
  • the public network address management mode is enabled for the always-online service, and the IP-CAN session is modified to the IP-CAN session of the data service;
  • the third-type deactivation notification carries the always-on service information and the IP corresponding to the always-on service.
  • -CAN session or, when receiving a deactivation notification from the PCRF that cancels the always-on capability of the IP-CAN session by the fourth type, notifying the NAT function entity to enable the public network address management mode for the always-on service, based on the fourth Class-based deactivation notifications carry always-on business information; or,
  • the embodiment of the present invention further provides a system for providing an always-on capability, including the policy and charging rule function entity PCRF of the fourth embodiment and the core network device of the fifth embodiment;
  • the system also includes:
  • the service server is configured to send the always-on service request information that carries the user information corresponding to the always-on service to the PCRF when the online service is online; when the online service is offline, send the user information corresponding to the always-on service to the PCRF.
  • Always online to deactivate information.
  • the application function entity AF is configured to receive the always-on service request information from the service server when the service server sends the always-on service request information that carries the user information corresponding to the always-on service to the PCRF, and send the always-on service request information. Giving the PCRF; when the service server sends the always-on service deactivation information carrying the user information corresponding to the always-on service to the PCRF, receiving the always-on service deactivation information from the service server, and deactivating the information for the always-on service Send to the PCRF.
  • the embodiments of the present invention may be implemented by hardware, or may be implemented by means of software plus a necessary general hardware platform.
  • the technical solution of the embodiment of the present invention can be embodied in the form of a software product.
  • the software product can be stored in a non-volatile storage medium (which can be a CD-ROM, a USB flash drive, a mobile hard disk, etc.), and includes a plurality of instructions for causing a computer device (which can be a personal computer, a server, or The network device or the like performs the method described in each implementation scenario of the embodiment of the present invention.
  • modules in the device in the implementation scenario may be distributed in the device for implementing the scenario according to the implementation scenario description, or may be correspondingly changed in one or more devices different from the implementation scenario.
  • the modules of the above implementation scenarios can be combined into one module, or can be further split into multiple sub-modules.
  • serial numbers of the foregoing embodiments of the present invention are merely for description, and do not represent the advantages and disadvantages of the implementation scenarios.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

一种永远在线能力的提供方法、系统和设备，该方法包括：接收来自业务服务器的永远在线业务请求信息，所述请求信息中携带永远在线业务对应的用户信息；通知核心网设备为所述用户信息对应的IP-CAN会话保持永远在线能力。所述永远在线能力的提供方法、系统和设备针对PCC架构实现永远在线业务，无需使用心跳包机制来维护永远在线状态，降低了网络信令负荷，减少了网络在用户使用业务时对用户的影响，提高了用户体验。

Description

一种永远在线能力的提供方法、 系统和设备 本申请要求于 2011 年 4 月 19 日提交中国专利局、 申请号为 201110097754.X, 发明名称为"一种永远在线能力的提供方法、 系统和设备"的 中国专利申请的优先权， 其全部内容通过引用结合在本申请中。 技术领域 本发明涉及通信技术领域，特别是涉及一种永远在线能力的提供方法、 系 统和设备。 背景技术 随着通信技术的快速发展， 网络日趋开放， 在竟争日趋激烈的情况下， 网 络是否安全可靠直接关系到企业的产品竟争力，从而决定了企业的市场地位和 竟争力， 只有网络安全可靠， 才能保障企业客户的业务永远在线， 继而保证企 业持续长远发展。
当智能手机和移动电脑被广泛应用后， 出现了永远在线业务的需求，如即 时聊天业务、 社交网络业务、 邮件推送业务等， 上述永远在线业务为了体现出 用户与服务器之间的操作性， 减少网络在用户使用业务时对用户的影响，提高 用户体验， 需要获知用户是否还连接在服务器上。 进一步的， 用户在使用永远 在线业务时不希望感受到由于网络状况或服务器状况而产生的延迟，在高突发 性数据发生时， 要求永远在线业务可以做出快速响应。
现有技术中，永远在线类业务的服务器获知用户与服务器间的连接状态的 方法为： 服务器接收来自用户的保持在线状态信息（即心跳包（ keep alive )消 息）， 当服务器接收到用户的心跳包时， 证明用户依然连接在服务器上， 确定 用户在线的状态， 从而实现了永远在线的特征。
在实现本发明的过程中， 发明人发现现有技术中至少存在以下问题： 现有的无线网络机制是按照用户使用间断、 大数据量的应用来设计架构 的， 当用户静默一段时间后， 网络侧会释放资源， 不再提供永远在线能力， 当 永远在线业务承载在无线网络时， 需要通过心跳包机制来维护在线能力， 而心 跳包往往比较筒短， 数据量小， 只包含用户部分信息， 且发送间隔时间较长； 因此会导致大量的信令消耗， 占用网络资源。 发明内容 本发明实施例提供一种永远在线能力的提供方法、 系统和设备， 以实现永 远在线业务， 充分利用网络资源。
为了达到上述目的， 本发明实施例提供一种永远在线能力的提供方法， 包 括以下步骤： 接收来自业务服务器的永远在线业务请求信息， 所述请求信息中 携带永远在线业务对应的用户信息； 通知核心网设备为所述用户信息对应的 IP-CAN会话保持永远在线能力。
本发明实施例提供一种永远在线能力的提供方法， 包括以下步骤： 接收来 自 PCRF 的永远在线业务的请求通知， 所述请求通知中携带永远在线业务信 息、 请求为永远在线业务的 IP-CAN会话保持永远在线能力的信息； 为所述永 远在线业务的 IP-CAN会话保持永远在线能力。
本发明实施例提供一种策略与计费规则功能实体 PCRF, 包括：接收模块， 用于接收来自业务服务器的永远在线业务请求信息，所述请求信息中携带永远 在线业务对应的用户信息； 通知模块， 用于通知核心网设备为所述用户信息对 应的 IP-CAN会话保持永远在线能力。
本发明实施例提供一种核心网设备，包括：接收模块，用于接收来自 PCRF 的永远在线业务的请求通知， 所述请求通知中携带永远在线业务信息、请求为 永远在线业务的 IP-CAN会话保持永远在线能力的信息； 能力保持模块， 用于 为所述永远在线业务的 IP-CAN会话保持永远在线能力。
本发明实施例提供一种永远在线能力的提供系统，包括上述的策略与计费 规则功能实体 PCRF、 以及上述的核心网设备。
与现有技术相比， 本发明实施例所提出的技术方案具有以下优点： 针对 PCC架构实现永远在线业务， 无需使用心跳包机制来维护永远在线 状态， 降低了网络信令负荷， 减少了网络在用户使用业务时对用户的影响， 提 高了用户体验。 附图说明 图 1为现有技术中 PCC架构示意图；
图 2为现有技术中心跳包示意图； 图 3为本发明各实施例的应用场景示意图；
图 4为本发明实施例一提供的永远在线业务的上线流程示意图；
图 5为本发明实施例二提供的永远在线业务的 IP-CAN会话释放流程示意 图；
图 6为本发明实施例三提供的永远在线业务下线流程示意图；
图 7为本发明实施例四提供的 PCRF的结构示意图；
图 8为本发明实施例五提供的核心网设备的结构示意图。 具体实施方式 如图 1所示的 PCC ( Policy and Charging Control, 策略和计费控制 ) 架构 示意图， 为了支持对业务流的 QoS ( Quality of Service, 服务质量）控制、 计 费控制和门限控制， 定义了 PCC架构， PCC架构能够支持为每个业务流提供 基于业务的 PCC策略，包括将流规则、授权的 QoS等给 PCEF,由 PCEF( Policy and Charging Enforcement Function,策略及计费执行功能）执行对业务流的 QoS 保证。其中，业务流的 QoS授权可以基于业务类型、用户签约数据、 PCRF( Policy and Charging Rules Function,策略与计费规则功能）上预设的策略等因素生成， 能够支持基于业务流的事件上报的能力。在 PCC架构中，主要网元包括: PCRF、 PCEF, SPR( Subscription Profile Repository,用户签约数据库 ), AF( Application Function, 应用功能）等， 其中：
( 1 ) PCRF, 为 PCC 的核心， 负责策略决策和计费规则的制定。 PCRF 根据从 AF获取与业务相关的信息，从 SPR获取用户的策略和计费控制签约信 息、 , 从 PCEF/BBERF ( Bearing Binding and Event Report Function, 载邦定及 事件报告功能）获取与承载相关的网络信息（如 IP-CAN( IP-Connectivity Access Network, IP连接访问网络）类型、 用户的位置信息）， 以及 PCRF自身预配置 的信息制定策略和计费规则。 其中， 上述策略和计费控制主要包括业务数据流 的检测， 门控， QoS控制， 基于数据流的计费规则等。
( 2 ) PCEF, 为策略和计费执行功能逻辑实体， 位于网关内。 PCEF按照 PCRF下发的 PCC规则中的业务数据流过滤器对业务数据流进行检测，执行策 略、 门控预计基于流的计费。 ( 3 ) SPR, 是存放所有用户签约信息的逻辑节点， 签约信息可以被 PCRF 用来进行基于签约的策略控制和 IP CAN承载层的 PCC策略控制。 其中， SPR 中可以为每个 PDN ( Public Data Network,公用数据网络）提供如下签约信息： 用户签约的服务、每种签约的服务的抢占优先级、 用户签约的 QoS (如保证的 带宽 QoS )、 用户的计费相关信息 （如和计费相关的位置信息）、 用户类别。
( 4 )AF,如 IMS( IP Multimedia Subsystem, IP多媒体系统）网络的 P-CSCF ( Proxy Call Session Control Function, 代理呼叫会话控制功能）， 是提供业务 并要求 IP CAN为该业务提供动态的策略控制节点。 AF通过和 PCRF通信下 发动态的会话信息给 PCRF进行策略控制决策， AF也接受 PCRF上报的 IP CAN的相关信息和事件通知。
另外，对于分组网络承载管理机制，在无线网络中， 网络的资源相对有限， 因此为节省网络资源， 提高网络资源利用率， 现有网络资源管理机制是： 仅当 用户有业务需求时， 才会进行承载建立 (如 PDP激活）， 以及相应的无线资源承 载建立，同时当用户静默一定时间段后，即当用户一段时间内没有业务发生时， 网络侧会主动删除承载（如去激活 PDP ) , 以节省网络资源。
基于上述 PCC架构， PCC相关技术目前已完成基本的业务流资源保障以 及流计费策略， 可在一定程度上为用户提供差异化的服务。 主要包括： 承载建 立时的策略协商、 决定和执行， 策略的修改， 以及承载释放时的策略取消等。 上述流程能够处理会话相关和会话无关两种类型业务的承载的策略管理，可以 由承载建立请求触发、 或 PCEF触发、 或对用户的签约信息的改变触发、 或 AF发来的业务请求触发。 对 PCRF来说， 只是被动的接受建立、 修改、 终止 的请求， 之后根据业务信息制定或终止相应的策略。 而针对具体业务（如永远 在线特性的业务） 的承载维护， 目前为止没有相关解决方案。
基于现有永远在线业务的需求， 现有的无线网络机制所采用的 PCC架构 中至少存在以下问题：
( 1 )现有网络不维护永远在线业务的状态。 其中， 分组域网络不会针对 业务去提供对应承载的状况管理， 不具有对业务提供永远在线的能力。
具体的， 在分组域网络架构中， 能够支持为每个业务流提供基于业务的 PCC策略， 但 PCC策略仅包括流规则、 授权的 QoS等， 由接受此 PCC策略 的 PCEF执行对业务流的 QoS保证； 当用户有业务请求时才激活 IP-CAN, 用 户在此 IP-CAN所包含的承载中实现业务； 在用户静默期一段时间后， 网络侧 会释放 IP-CAN(核心网内 IP不可达）；由于 NAT( Network Address Translation, 网络地址转换） 穿透机制， 在 PDN侧网络资源 （如公网地址）也会释放。
基于上述情况， 网络不能感知永远在线业务的存在， 因此不能针对永远在 线业务特性进行维护， 导致永远在线业务上线后需要靠心跳包来维持连接状 态， 占用大量网络资源， 影响其他业务的正常运作， 并降低运营商网络服务质 量和客户体验度。
( 2 )业务的大量信令。 其中， 由于现有网络不维护永远在线业务的状态， 永远在线业务消息依赖于心跳包机制， 心跳包的时间间隔会超出 IP-CAN释放 或无线侧资源重分配的时长， 从而使得永远在线业务发送心跳包时重新激活 PDP或重分配无线侧资源。进一步的，重新分配无线侧资源会造成终端与核心 网网元交换信令， 并且由于心跳包的特性， 终端的状态会快速改变。
如图 2所示， 为现有技术中心跳包示意图， 当终端发送心跳包时， 由于系 统对资源的控制粒度较小， 在类似于沖击的心跳包间隔时间内快速的释放资 源， 而当心跳包发送时又会重新分配资源，期间会产生大量信令，从而对 RRC ( Radio Resource Control, 无线资源控制协议）控制等功能造成沖击。
另夕卜， PS (分组域） RAB ( Radio Access Bear, 无线接入承载）建立请求 的增加会造成 RNC ( Radio Network Controller, 无线网络控制器）信令处理模 块负荷的显著增加， 同时整体的用户分组业务数据及信令流量显著增加， 进一 步负荷超载时甚至会影响到用户电路域业务的正常使用。
针对上述问题， 本发明实施例提供一种永远在线能力的提供方法、 系统和 设备， 在 PCC架构中引入了永远在线业务策略和网络提供能力， 当永远在线 类应用上线后， 可由永远在线业务服务器通过永远在线业务 AF向 PCRF上报 永远在线类应用状态， PCRF根据上报的永远在线业务状态及其他业务、 会话 信息进行灵活准确的决策， 并在网络侧为用户开通永远在线能力，取消业务侧 的心跳包，从而降低永远在线业务的心跳包对网络的沖击（如延长永远在线业 务的 PDP上下文释放时间、 延长永远在线业务的公网地址释放时间、 在永远 在线业务所在承载意外去激活时保活承载 ), 从而使得业务无需使用心跳包确 认即可感受到用户的在线状态。
下面将结合本发明中的附图，对本发明中的技术方案进行清楚、 完整的描 述， 显然， 所描述的实施例是本发明的一部分实施例， 而不是全部的实施例。 基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下 所获得的所有其他实施例， 都属于本发明保护的范围。
实施例一
本发明实施例一提供一种永远在线能力的提供方法， 该方法应用于基于 PCC架构的 2G/3G系统或者 LTE系统， 在 2G/3G系统中， 本实施例中的核心 网设备包括 GGSN ( Gateway GPRS Support Node, 网关 GPRS支持节点）， 在 LTE系统中， 本实施例中的核心网设备包括 PDN GW ( Public Data Network Gateway, 公共数据网网关）， 以 LTE 系统为例， 本实施例的应用场景为图 3 所示的具有永远在线业务能力的网络架构示意图。 PCC架构中的 AF实体可单 独部署、可集成在业务服务器上，可集成在 PCRF上、也可集成在其他设备上。
如图 4所示，基于上述应用场景示意图，永远在线业务的上线流程包括以 下步骤：
步骤 401 , 当用户设备通过已有承载激活永远在线业务时， 业务服务器为 该用户设备提供永远在线业务。其中， 该业务服务器为永远在线业务的应用服 务器， 如 QQ、 MSN等永远在线业务的应用服务器。
步骤 402, 业务服务器通过永远在线业务对应的 AF向 PCRF发送永远在 线业务请求信息。 其中， 当永远在线业务对应的 AF部署在业务服务器上时， 则由业务服务器直接向 PCRF发送永远在线业务请求信息。
具体的， 当永远在线业务上线时， 该业务服务器可通过 AF向 PCRF发送 永远在线业务请求信息， 以通知 PCRF激活对应的永远在线业务。 其中， 该请 求信息中至少携带永远在线业务对应的永远在线业务标识和用户信息（如用户 设备 IP地址）。
步骤 403, PCRF接收到来自业务服务器的永远在线业务请求信息后， 通 知核心网设备为用户信息对应的 IP-CAN会话保持永远在线能力。 方式一： 通过查询预先维护的业务标记信息确定用户信息对应的 IP-CAN 会话承载永远在线能力是否已激活，如果用户信息对应的 IP-CAN会话承载永 远在线能力已激活（用户信息对应的 IP-CAN会话^载永远在线能力可对应用 户设备的多种类型的永远在线业务，该 IP-CAN会话承载永远在线能力激活状 态可为其他永远在线业务的请求过程中被设置为激活状态 ), 则通知核心网设 备采用第一类方式（由核心网设备通知 NAT功能实体不释放永远在线业务对 应公网地址）为用户信息对应的 IP-CAN会话保持永远在线能力（基于第一类 方式的请求通知中携带永远在线业务信息、以及采用第一类方式进行处理的标 记）； 如果用户信息对应的 IP-CAN 载永远在线能力没有激活， 则通知核心 网设备采用第二类方式（由核心网设备通知 NAT功能实体不释放永远在线业 务对应公网地址、 且保持对应的 IP-CAN 会话不释放） 为用户信息对应的 IP-CAN会话保持永远在线能力 （基于第二类方式的请求通知中携带永远在线 业务信息、 IP-CAN会话信息、 以及采用第二类方式进行处理的标记）。
具体的， 在 PCRF上存储（如以表格方式存储）并维护了业务标记信息， 该业务标记信息中记录了永远在线业务对应的用户信息（即用户属性信息， 如 IP地址等）、 IP-CAN会话信息、 IP-CAN会话承载激活或者未激活永远在线能 力的状态信息、永远在线业务承载激活状态（即承载处于激活状态或者承载处 于未激活状态）、 以及业务服务器归属 （可由永远在线业务标识确定） 的对应 关系。
基于该业务标记信息中记录的对应关系，则根据永远在线业务请求信息中 携带的用户信息，可在业务标记信息中查询到该用户信息对应的 IP-CAN会话 承载永远在线能力是否已激活， 如业务标记信息中没有用户信息对应的 IP-CAN会话承载永远在线能力时为未激活。
方式二： 通过查询预先维护的业务标记信息确定用户信息对应的 IP-CAN 会话承载永远在线能力是否已激活时，用户信息对应的 IP-CAN会话承载永远 在线能力已激活或者没有激活， PCRF 均通知核心网设备为用户信息对应的 IP-CAN会话保持永远在线能力 （该通知中携带永远在线业务信息、 IP-CAN 会话信息）， 由核心网设备来确定采用第一类方式或者第二类方式为用户信息 对应的 IP-CAN会话保持永远在线能力。
本发明实施例中， 当用户信息对应的 IP-CAN会话承载永远在线能力没有 激活时，在通知核心网设备为用户信息对应的 IP-CAN会话保持永远在线能力 的过程中， PCRF还需在业务标记信息中将用户信息对应的 IP-CAN会话承载 永远在线能力修改为 IP-CAN会话承载永远在线能力激活状态； 并将永远在线 业务承载修改为永远在线业务承载激活状态。 当用户信息对应的 IP-CAN会话 承载永远在线能力已激活时， PCRF还需将永远在线业务承载修改为永远在线 业务承载激活状态。
步骤 404, 核心网设备接收来自 PCRF的永远在线业务的请求通知， 并为 永远在线业务对应的 IP-CAN会话保持永远在线能力。
具体的， 在 PCRF通知核心网设备为用户信息对应的 IP-CAN会话保持永 远在线能力时，核心网设备可接收到永远在线业务的请求通知， 该请求通知中 携带请求为永远在线业务的 IP-CAN会话保持永远在线能力的信息（即永远在 线业务承载能力请求）， 根据该永远在线业务承载能力请求， 核心网设备获知 需要为 IP-CAN会话保持永远在线能力。 另外， 针对不同的处理方式， 该请求 通知中还可以携带其他信息。
本发明实施例中， 针对方式一， 如果用户信息对应的 IP-CAN会话^载永 远在线能力已激活， 则说明核心网设备之前已经为对应该 IP-CAN会话的其他 类型的永远在线业务保持了永远在线能力，而由于不同业务对应的公网地址不 同，核心网设备只要通知 NAT功能实体不释放永远在线业务对应的公网地址， 即可为当前的永远在线业务的 IP-CAN会话保持永远在线能力。
因此，基于第一类通知方式的请求通知中携带永远在线业务信息和采用第 一类方式进行处理的标记， 当核心网设备接收到该请求通知后， 即可直接通知 NAT 功能实体不释放永远在线业务（根据永远在线业务信息获知）对应的公 网地址。
如果用户信息对应的 IP-CAN会话承载永远在线能力没有激活， 则说明核 心网设备之前并没有为对应该 IP-CAN会话的其他类型的永远在线业务保持永 远在线能力， 核心网设备需要通知 NAT功能实体不释放永远在线业务对应的 公网地址，且保持对应的 IP-CAN会话不释放（如不主动发起 PDP去活流程）， 从而为当前的永远在线业务的 IP-CAN会话保持永远在线能力。
因此，基于第二类通知方式的请求通知中携带永远在线业务信息、 IP-CAN 会话信息和采用第二类方式进行处理的标记，当核心网设备接收到该请求通知 后， 即可直接通知 NAT功能实体不释放永远在线业务（根据永远在线业务信 息获知 )对应的公网地址， 且保持 IP-CAN会话（根据 IP-CAN会话信息获知 ) 不释放。
针对方式二， 由核心网设备自身确定为当前的永远在线业务的 IP-CAN会 话保持永远在线能力的方式， 请求通知中携带永远在线业务信息、 IP-CAN会 话信息；而由于请求通知中未携带采用第一、二类方式进行处理的标记， 因此， 当接收到为 IP-CAN会话保持永远在线能力的请求通知时， 核心网设备根据 IP-CAN会话信息确定 IP-CAN会话对应的承载永远在线能力已激活或者没有 激活 （可通过判断是否已经为 IP-CAN会话保持永远在线能力的方式进行判 断 ),如果 IP-CAN会话对应的承载永远在线能力已激活，核心网设备通知 NAT 功能实体不释放永远在线业务对应公网地址，如果 IP—CAN会话对应的承载永 远在线能力没有激活， 核心网设备通知 NAT功能实体不释放永远在线业务对 应公网地址， 且保持对应的 IP-CAN会话不释放。
综上所述， 本步骤中， 核心网设备将对应 IP-CAN会话为变更为永远在线 业务承载， 并为该 IP-CAN会话保持永远在线能力 （包括通知 NAT功能实体 不释放公网地址、 和 /或， 保持对应的 IP-CAN会话不释放等）。
步骤 405 , 核心网设备向 PCRF返回信息确认当前永远在线业务承载已具 有永远在线业务^载能力。
步骤 406, PCRF通知 AF已为当前永远在线业务（即上述进行处理的永 远在线业务）开通永远在线能力。
本发明实施例中，当接收到核心网设备返回的确认当前永远在线业务承载 已具有永远在线业务承载能力后， PCRF还需要维护业务标记信息。 如果用户 信息对应的 IP-CAN会话承载永远在线能力已激活，则业务标记信息中已经记 录了该 IP-CAN会话承载永远在线能力的相关信息， PCRF在业务标记信息中 维护当前的永远在线业务的相关信息即可；如果用户信息对应的 IP-CAN会话 承载永远在线能力没有激活， 业务标记信息中没有记录该 IP-CAN会话承载永 远在线能力的相关信息时， PCRF在业务标记信息中记录 IP-CAN会话对应的 已激活永远在线业务标记， 该标记包括永远在线业务对应的用户信息、永远在 线业务承载激活状态、 IP-CAN会话信息、 业务服务器归属等信息， 并在永远 在线业务承载激活状态上标明激活， 从而实现永远在线业务上线的过程。
综上所述， 本发明实施例中， 在业务服务器（AF )上新增永远在线业务 通知功能， 在 PCRF上增加业务标记功能， 在核心网设备上增加承载的状态管 理功能， 核心网侧提供永远在线业务承载 NAT公网地址不释放、 不主动去激 活 IP-CAN会话， 从而可有效实现分组域混合组网场景下， 为永远在线业务提 供永远在线能力的方法，使得业务无需依赖心跳包来维护用户在线状态， 节约 信令开销。 因此， 本发明实施例对核心网处理永远在线业务方案进行改进， 有 效的解决了现有方案中存在的无法提供业务永远在线能力，导致业务侧需要通 过 "心跳包" 来维护永远在线状态， 引起过多信令负荷的问题。
实施例二
如图 5所示， 基于图 3所示的应用场景示意图， 永远在线业务的 IP-CAN 会话释放流程包括以下步骤：
步骤 501 , 用户设备向核心网设备发起释放 IP-CAN会话流程 (如 PDP上 下文去激活）。
步骤 502, 核心网设备收到释放 IP-CAN请求后， 判断该 IP-CAN会话承 载是否为永远在线业务承载。
如果该 IP-CAN会话承载是永远在线业务承载且用户设备释放 IP-CAN请 求的原因为非不可抗拒（如用户设备没电、 关机等）原因 （即不是用户设备主 动下线导致的释放过程）， 执行步骤 503; 否则， 执行步骤 504。
步骤 503, 核心网设备緩存业务服务器发向用户设备的消息。 之后， 核心 网设备等待永远在线业务承载的保活，并在永远在线业务的承载保活成功后向 用户设备重发緩存的内容； 或者，如果永远在线业务^载保活失败或不进行永 远在线业务承载保活， 核心网设备可删除对应緩存的内容。
步骤 504 , 核心网设备通知 PCRF释放 IP-CAN会话。
步骤 505, PCRF收到释放 IP-CAN会话的请求后， 从业务标记信息中判 断该 IP-CAN会话的承载是否已经存在永远在线业务，如果是，执行步骤 506, 否则， 执行现有的释放 IP-CAN的流程。
具体的，现有的释放 IP-CAN的流程包括： PCRF标识受影响的 PCC策略， 核心网设备删除对应的所有策略和计费规则， PCRF向 AF告知传输丟失并向 核心网设备确认释放 IP-CAN会话， 核心网设备响应 UE发起的 IP-CAN会话 释放请求， 释放 IP-CAN的流程结束， 该过程本发明实施例中不再详加赘述。
步骤 506, PCRF选择不执行永远在线业务承载保活的策略或者选择执行 永远在线业务 载保活的策略。
步骤 507 , PCRF通知核心网设备确认用户设备释放 IP-CAN消息， 该消 息中包含对步骤 504中核心网设备通知 PCRF释放 IP-CAN会话的确认、 以及 选择执行或不执行永远在线业务承载保活的策略。
具体的， PCRF可根据实际需要选择上述两种策略的任意一种， 当 PCRF 选择不执行永远在线业务承载保活的策略时， 核心网设备收到该策略信息后， 只执行释放 IP-CAN流程， 并执行步骤 509; 当 PCRF选择执行永远在线业务 承载保活的策略时， 核心网设备收到该策略信息后， 执行释放 IP-CAN流程， 并执行重激活永远在线业务 IP-CAN会话流程。
其中， 释放 IP-CAN的流程本发明实施例中不再赘述， 对于重激活永远在 线业务 IP-CAN会话流程， 包括： 当 PDP上下文去激活流程结束后， 核心网 设备发起永远在线业务的 IP-CAN会话重激活流程， 核心网设备、 PCRF等设 备执行永远在线业务的 IP-CAN会话重激活流程。
具体的， 核心网设备需要通知 NAT功能实体不释放永远在线业务对应公 网地址（即不释放永远在线业务所使用的公网地址 ), 且保持该 IP-CAN会话 不释放 (如不主动发起 PDP去活流程）； PCRF需要在业务标记信息中记录该 IP-CAN会话的相关信息， 从而在 PCRF和核心网设备上为永远在线业务的 IP-CAN会话信息保持永远在线能力， 该过程与实施例一的处理过程类似， 在 此不再详加赘述。
步骤 508, 核心网设备向 PCRF返回对策略的确认消息， 该确认消息中包 括永远在线业务的 IP-CAN会话重激活的执行结果， 如 IP-CAN会话重激活成 功或失败。
步骤 509, 当接收到确认消息后， 如果 IP-CAN会话重激活成功， 则结束 流程， 如果 IP-CAN会话重激活失败， PCRF通知 AF该 IP-CAN会话对应的 永远在线业务下线， 由 AF通知对应的业务服务器该永远在线业务下线， 并向 PCRF确认永远在线业务下线。
本发明实施例中， PCRF还可以校验更新对应永远在线业务的业务标记信 息， 即如果策略为不执行永远在线业务承载保活， 则更新对应 IP-CAN会话上 业务的业务标记信息中永远在线业务承载激活状态为去激活或者删除对应业 务标记信息。
如果策略为执行永远在线业务承载保活，则根据步骤 508中的确认消息更 新对应 IP-CAN会话上业务的业务标记信息， 即确认消息中携带 IP-CAN会话 重激活成功， 则流程结束； 如果确认消息中携带 IP-CAN会话重激活失败， 则 删除对应业务标记信息。
综上所述， 本发明实施例中， 在核心网设备上新增緩存机制， 在 PCRF上 新建永远在线业务承载的判决机制， 在 PCRF 上新建两种永远在线业务 IP-CAN会话释放处理方法， 在 AF上新增永远在线业务通知功能， 从而可有 效实现分组域混合组网场景下， 为永远在线业务提供一种 IP-CAN会话释放方 式，使得业务服务器不会感知到用户的异常断线状态， 节约了业务服务器重新 查找用户设备以及用户设备重登录的资源浪费。
实施例三
如图 6所示，基于图 3所示的应用场景示意图，永远在线业务下线流程包 括以下步骤：
步骤 601 , 用户设备去激活永远在线业务， 相应业务服务器停止为该用户 设备提供永远在线业务。
步骤 602, 永远在线业务下线， 业务服务器通过永远在线业务对应的 AF 向 PCRF发送永远在线业务去激活信息。 其中， 当永远在线业务对应的 AF部 署在业务服务器上时，则由业务服务器直接向 PCRF发送永远在线业务去激活 信息。该去激活信息中至少携带永远在线业务对应的永远在线业务标识和用户 信息 （如用户设备 IP地址）。
步骤 603, PCRF接收到来自业务服务器的永远在线业务去激活信息后， 通知核心网设备为用户信息对应的 IP-CAN会话4款销永远在线能力。
方式一： 通过查询预先维护的业务标记信息确定用户信息对应的 IP-CAN 会话是否还存在其他永远在线业务（每个 IP-CAN会话可对应多个永远在线业 务， 例如， 用户设备 1的 IP-CAN会话可对应永远在线业务 1和永远在线业务 2, 当接收到永远在线业务 1 的去激活信息后， 如果查询到业务标记信息的 IP-CAN会话还对应了永远在线业务 2, 则说明 IP-CAN会话中还存在其他永 远在线业务； 如果查询到业务标记信息的 IP-CAN会话中没有对应其他永远在 线业务， 则说明 IP-CAN会话中不存在其他永远在线业务）， 如果不存在其他 永远在线业务， PCRF通知核心网设备采用第三类方式 （由核心网设备通知 NAT功能实体对永远在线业务启用公网地址管理方式，并将 IP-CAN会话修改 为数据业务的 IP-CAN会话 ) IP-CAN会话的永远在线能力 （基于第三类 方式的去激活通知中携带永远在线业务信息、永远在线业务对应的 IP-CAN会 话、 采用第三类方式进行处理的标记）； 如果存在其他永远在线业务， PCRF 通知核心网设备采用第四类方式（由核心网设备通知 NAT功能实体对永远在 线业务启用公网地址管理方式）撤销 IP-CAN会话的永远在线能力（基于第四 类方式的去激活通知中携带永远在线业务信息、采用第四类方式进行处理的标 记）。
方式二： 通过查询预先维护的业务标记信息确定用户信息对应的 IP-CAN 会话存在或不存在其他永远在线业务时， PCRF均通知核心网设备核心网设备 撤销 IP-CAN会话的永远在线能力（该通知中携带永远在线业务信息、 永远在 线业务对应的 IP-CAN会话）， 由核心网设备确定采用第三类方式或者第四类 方式 4敦销 IP-CAN会话的永远在线能力。
步骤 604, 核心网设备接收来自 PCRF的永远在线业务的去激活通知， 并 ϋ销永远在线业务对应的 IP-CAN会话的永远在线能力。
具体的， 在 PCRF通知核心网设备 4敦销永远在线业务对应的 IP-CAN会话 的永远在线能力时，核心网设备可接收到去激活通知， 该去激活通知消息中携 带请求为永远在线业务的 IP-CAN会话 4敦销永远在线能力的信息（即永远在线 业务承载能力去激活请求）， 根据该永远在线业务承载能力去激活请求， 核心 网设备获知需要为 IP-CAN会话撤销永远在线能力。 另外， 针对不同的处理方 式， 该去激活通知还可以携带其他信息。
本发明实施例中，针对方式一，基于第三类方式的去激活通知中携带永远 在线业务信息、 永远在线业务对应的 IP-CAN会话、 采用第三类方式进行处理 的标记， 当接收到来自 PCRF的采用第三类方式4款销 IP-CAN会话的永远在线 能力的去激活通知时， 核心网设备通知 NAT功能实体对永远在线业务启用公 网地址管理方式， 并将 IP-CAN会话修改为数据业务的 IP-CAN会话（即将对 应的 IP-CAN会话变更为现有数据业务承载方式， 如当用户空闲一段时间后， 可以从核心网侧主动发起 PDP上下文去激活）。
基于第四类方式的去激活通知中携带永远在线业务信息话、采用第四类方 式进行处理的标记， 当接收到来自 PCRF的采用第四类方式4款销 IP-CAN会话 的永远在线能力的去激活通知时， 核心网设备通知 NAT功能实体对永远在线 业务启用公网地址管理方式。
针对方式二， 由核心网设备自身确定撤销 IP-CAN会话的永远在线能力的 方式， 去激活通知中携带永远在线业务信息、 永远在线业务对应的 IP-CAN会 话， 当接收到来自 PCRF的去激活通知后， 核心网设备确定 IP-CAN会话是否 还存在其他永远在线业务； 如果不存在其他永远在线业务， 核心网设备通知
NAT功能实体对永远在线业务启用公网地址管理方式，并将 IP-CAN会话修改 为数据业务的 IP-CAN会话； 如果存在其他永远在线业务， 核心网设备通知 NAT功能实体对永远在线业务启用公网地址管理方式。
步骤 605, 核心网设备向 PCRF返回信息确认当前永远在线业务承载能力 去激活， 执行现有数据业务策略。
步骤 606, PCRF通知 AF已为当前永远在线业务（即上述进行处理的永 远在线业务）去激活永远在线能力。
本发明实施例中， PCRF还需要修改 IP-CAN会话对应的永远在线业务的 业务标记信息， 在对应的永远在线业务承载激活状态上标明去激活， 当一个 IP-CAN会话对应的所有业务标记信息中永远在线业务承载激活状态都为去激 活时， 可以删除对应业务标记， 从而实现永远在线业务下线的过程。
综上所述， 本发明实施例中， 可有效实现分组域混合组网场景下， 为永远 在线业务提供一种下线的处理方式，当不需要为永远在线业务提供永远在线能 力时， 可恢复普通业务的 IP-CAN会话， 节约了网络资源。
实施例四
如图 7所示，基于上述方法同样的发明构思， 本发明实施例中还提出了一 种策略与计费规则功能实体 PCRF, 包括：
接收模块 11 , 用于接收来自业务服务器的永远在线业务请求信息， 所述 请求信息中携带永远在线业务对应的用户信息；
通知模块 12,用于通知核心网设备为所述用户信息对应的 IP-CAN会话保 持永远在线能力。
所述通知模块 12,具体用于如果所述用户信息对应的 IP-CAN会话承载永 远在线能力已激活，通知所述核心网设备采用第一类方式为所述用户信息对应 的 IP-CAN会话保持永远在线能力； 或者， 如果所述用户信息对应的 IP-CAN 会话承载永远在线能力没有激活，通知所述核心网设备采用第二类方式为所述 用户信息对应的 IP-CAN会话保持永远在线能力； 或者，
当所述用户信息对应的 IP-CAN会话承载永远在线能力已激活或者没有激 活时，通知所述核心网设备为所述用户信息对应的 IP-CAN会话保持永远在线 能力，由所述核心网设备确定采用第一类方式或者第二类方式为所述用户信息 对应的 IP-CAN会话保持永远在线能力。
本发明实施例中， 还包括： 获取模块 13, 用于获知所述用户信息对应的
IP-CAN会话承载永远在线能力是否激活； 其中， 根据所述用户信息查询预先 维护的业务标记信息，所述业务标记信息中记录用户信息、 IP-CAN会话信息、 IP-CAN会话承载激活或者未激活永远在线能力的状态信息、 永远在线业务激 活状态信息的对应关系； 并根据查询结果获知所述用户信息对应的 IP-CAN会 话承载永远在线能力为激活状态或者未激活状态。
本发明实施例中， 还包括： 第一处理模块 14, 用于当从来自核心网设备 的释放 IP-CAN会话的请求信息中获知所述 IP-CAN会话的承载已经存在永远 在线业务时，选择不执行永远在线业务承载保活的策略，将选择的策略通知给 所述核心网设备， 并和所述核心网设备执行释放 IP-CAN会话的流程， 以及通 知业务服务器所述 IP-CAN会话对应的永远在线业务下线。
第二处理模块 15,用于当从来自核心网设备的释放 IP-CAN会话的请求信 息中获知所述 IP-CAN会话的承载已经存在永远在线业务时，选择执行永远在 线业务承载保活的策略，将选择的策略通知给所述核心网设备， 并和所述核心 网设备执行释放 IP-CAN会话的流程、 重激活永远在线业务的 IP-CAN会话的 流程； 如果永远在线业务的 IP-CAN会话重激活失败， 通知业务服务器所述 IP-CAN会话对应的 7j远在线业务下线。
所述接收模块 11 , 还用于接收来自业务服务器的永远在线业务去激活信 息， 所述去激活信息中携带永远在线业务对应的用户信息；
所述通知模块 12,还用于当所述用户信息对应的 IP-CAN会话不存在其他 永远在线业务时，通知核心网设备采用第三类方式撤销所述 IP-CAN会话的永 远在线能力； 或者， 当所述用户信息对应的 IP-CAN会话存在其他永远在线业 务时，通知核心网设备采用第四类方式撤销所述 IP-CAN会话的永远在线能力 或者，
通知核心网设备4款销所述用户信息对应的 IP-CAN会话的永远在线能力； 由所述核心网设备确定采用第三类方式或者第四类方式撤销所述 IP-CAN会话 的永远在线能力。
实施例五
基于上述方法同样的发明构思， 本发明实施例还提供了一种核心网设备， 如图 8所示， 该核心网设备包括：
接收模块 21 , 用于接收来自 PCRF的永远在线业务的请求通知， 所述请 求通知中携带永远在线业务信息、请求为永远在线业务的 IP-CAN会话保持永 远在线能力的信息；
能力保持模块 22,用于为所述永远在线业务的 IP-CAN会话保持永远在线 能力。
所述能力保持模块 22,具体用于当接收到采用第一类方式为所述 IP-CAN 会话保持永远在线能力的请求通知时， 通知 NAT功能实体不释放永远在线业 务对应的公网地址； 当接收到采用第二类方式为所述 IP-CAN会话保持永远在 线能力的携带 IP-CAN会话信息的请求通知时， 通知 NAT功能实体不释放永 远在线业务对应公网地址， 且保持所述 IP-CAN会话不释放； 或者，
当接收到为所述 IP-CAN会话保持永远在线能力的携带 IP-CAN会话信息 的请求通知时， 根据所述 IP-CAN会话信息确定 IP-CAN会话对应的承载永远 在线能力已激活或者没有激活； 当所述 IP-CAN会话对应的承载永远在线能力 已激活时， 通知 NAT 功能实体不释放永远在线业务对应公网地址； 当所述 IP-CAN会话对应的承载永远在线能力没有激活时，通知 NAT功能实体不释放 永远在线业务对应公网地址， 且保持所述 IP-CAN会话不释放。
本发明实施例中， 还包括： 第一处理模块 23, 用于当从来自用户设备的 释放 IP-CAN会话的请求信息中获知所述 IP-CAN会话的承载为永远在线业务 承载时，緩存业务服务器向所述用户设备发送的内容； 当永远在线业务的承载 保活成功后， 向所述用户设备发送緩存的内容； 或者， 当永远在线业务的承载 保活失败或不进行永远在线业务的承载保活时， 删除緩存的内容。
本发明实施例， 还包括： 第二处理模块 24, 用于当从来自用户设备的释 放 IP-CAN会话的请求信息中获知所述 IP-CAN会话的承载为永远在线业务承 载时， 向 PCRF发送释放 IP-CAN会话的请求信息； 接收来自所述 PCRF的不 执行永远在线业务承载保活的策略， 并和所述 PCRF执行释放 IP-CAN会话的 流程； 或者， 接收来自所述 PCRF的执行永远在线业务承载保活的策略， 并和 所述 PCRF执行释放 IP-CAN会话的流程、 重激活永远在线业务的 IP-CAN会 话的流程。
该设备还包括： 能力撤销模块 25 , 用于当接收到来自 PCRF的采用第三 类方式 4敦销 IP-CAN会话的永远在线能力的去激活通知时， 通知 NAT功能实 体对永远在线业务启用公网地址管理方式， 并将 IP-CAN会话修改为数据业务 的 IP-CAN会话； 基于第三类方式的去激活通知中携带永远在线业务信息、 永 远在线业务对应的 IP-CAN会话； 或者， 当接收到来自 PCRF的采用第四类方 式撤销 IP-CAN会话的永远在线能力的去激活通知时， 通知 NAT功能实体对 永远在线业务启用公网地址管理方式，基于第四类方式的去激活通知中携带永 远在线业务信息； 或者，
当接收到来自 PCRF 的携带永远在线业务信息、 永远在线业务对应的 IP-CAN会话的去激活通知时， 确定所述 IP-CAN会话是否还存在其他永远在 线业务； 如果不存在其他永远在线业务， 通知 NAT功能实体对永远在线业务 启用公网地址管理方式， 并将 IP-CAN会话修改为数据业务的 IP-CAN会话； 如果存在其他永远在线业务， 通知 NAT功能实体对永远在线业务启用公网地 址管理方式。
实施例六
基于上述方法和设备同样的发明构思，本发明实施例中还提供了一种永远 在线能力的提供系统，包括上述实施例四的策略与计费规则功能实体 PCRF和 实施例五的核心网设备； 此外， 该系统还包括：
业务服务器， 用于在永远在线业务上线时， 向 PCRF发送携带永远在线业 务对应的用户信息的永远在线业务请求信息；在永远在线业务下线时，向 PCRF 发送携带永远在线业务对应的用户信息的永远在线业务去激活信息。
应用功能实体 AF, 用于在业务服务器向 PCRF发送携带永远在线业务对 应的用户信息的永远在线业务请求信息时，接收来自所述业务服务器的永远在 线业务请求信息， 并将永远在线业务请求信息发送给所述 PCRF; 在业务服务 器向 PCRF发送携带永远在线业务对应的用户信息的永远在线业务去激活信 息时，接收来自所述业务服务器的永远在线业务去激活信息， 并将永远在线业 务去激活信息发送给所述 PCRF。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本发明 实施例可以通过硬件实现，也可以借助软件加必要的通用硬件平台的方式来实 现。基于这样的理解， 本发明实施例的技术方案可以以软件产品的形式体现出 来， 该软件产品可以存储在一个非易失性存储介质 （可以是 CD-ROM, U盘， 移动硬盘等）中， 包括若干指令用以使得一台计算机设备（可以是个人计算机， 服务器， 或网络设备等）执行本发明实施例各个实施场景所述的方法。
本领域技术人员可以理解附图只是一个优选实施场景的示意图，附图中的 模块或流程并不一定是实施本发明实施例所必须的。
本领域技术人员可以理解实施场景中的装置中的模块可以按照实施场景 描述进行分布于实施场景的装置中，也可以进行相应变化位于不同于本实施场 景的一个或多个装置中。上述实施场景的模块可以合并为一个模块，也可以进 一步拆分成多个子模块。
上述本发明实施例序号仅仅为了描述， 不代表实施场景的优劣。
以上公开的仅为本发明实施例的几个具体实施场景，但是， 本发明实施例 并非局限于此，任何本领域的技术人员能思之的变化都应落入本发明实施例的 业务限制范围。

Claims

权 利 要 求
1、 一种永远在线能力的提供方法， 其特征在于， 包括以下步骤： 接收来自业务服务器的永远在线业务请求信息，所述请求信息中携带永远 在线业务对应的用户信息；
通知核心网设备为所述用户信息对应的 IP-CAN会话保持永远在线能力。
2、 如权利要求 1所述的方法， 其特征在于， 所述通知核心网设备为所述 用户信息对应的 IP-CAN会话保持永远在线能力， 包括：
如果所述用户信息对应的 IP-CAN会话^载永远在线能力已激活，通知所 述核心网设备采用第一类方式为所述用户信息对应的 IP-CAN会话保持永远在 线能力； 如果所述用户信息对应的 IP-CAN会话承载永远在线能力没有激活， 通知所述核心网设备采用第二类方式为所述用户信息对应的 IP-CAN会话保持 永远在线能力； 或者，
当所述用户信息对应的 IP-CAN会话承载永远在线能力已激活或者没有激 活时，通知所述核心网设备为所述用户信息对应的 IP-CAN会话保持永远在线 能力，由所述核心网设备确定采用第一类方式或者第二类方式为所述用户信息 对应的 IP-CAN会话保持永远在线能力。
3、 如权利要求 1所述的方法， 其特征在于， 所述方法还包括：
当从来自核心网设备的释放 IP-CAN会话的请求信息中获知所述 IP-CAN 会话的承载已经存在永远在线业务时，选择不执行永远在线业务承载保活的策 略， 将选择的策略通知给所述核心网设备， 并和所述核心网设备执行释放 IP-CAN会话的流程， 以及通知业务服务器所述 IP-CAN会话对应的永远在线 业务下线。
4、 如权利要求 1所述的方法， 其特征在于， 所述方法还包括：
当从来自核心网设备的释放 IP-CAN会话的请求信息中获知所述 IP-CAN 会话的承载已经存在永远在线业务时， 选择执行永远在线业务承载保活的策 略， 将选择的策略通知给所述核心网设备， 并和所述核心网设备执行释放 IP-CAN会话的流程、 重激活永远在线业务的 IP-CAN会话的流程； 如果永远在线业务的 IP-CAN 会话重激活失败， 通知业务服务器所述 IP-CAN会话对应的 7j远在线业务下线。
5、 如权利要求 1所述的方法， 其特征在于， 所述方法还包括：
接收来自业务服务器的永远在线业务去激活信息，所述去激活信息中携带 永远在线业务对应的用户信息；
当所述用户信息对应的 IP-CAN会话不存在其他永远在线业务时，通知核 心网设备采用第三类方式撤销所述 IP-CAN会话的永远在线能力； 当所述用户 信息对应的 IP-CAN会话存在其他永远在线业务时，通知核心网设备采用第四 类方式撤销所述 IP-CAN会话的永远在线能力； 或者，
通知核心网设备4款销所述用户信息对应的 IP-CAN会话的永远在线能力； 由所述核心网设备确定采用第三类方式或者第四类方式撤销所述 IP-CAN会话 的永远在线能力。
6、 一种永远在线能力的提供方法， 其特征在于， 包括以下步骤： 接收来自 PCRF的永远在线业务的请求通知，所述请求通知中携带永远在 线业务信息、 请求为永远在线业务的 IP-CAN会话保持永远在线能力的信息； 为所述永远在线业务的 IP-CAN会话保持永远在线能力。
7、如权利要求 6所述的方法，其特征在于，为所述永远在线业务的 IP-CAN 会话保持永远在线能力， 包括：
当接收到采用第一类方式为所述 IP-CAN会话保持永远在线能力的请求通 知时， 通知 NAT功能实体不释放永远在线业务对应的公网地址； 当接收到采 用第二类方式为所述 IP-CAN会话保持永远在线能力的携带 IP-CAN会话信息 的请求通知时， 通知 NAT功能实体不释放永远在线业务对应公网地址， 且保 持所述 IP-CAN会话不释放； 或者，
当接收到为所述 IP-CAN会话保持永远在线能力的携带 IP-CAN会话信息 的请求通知时， 根据所述 IP-CAN会话信息确定 IP-CAN会话对应的承载永远 在线能力已激活或者没有激活； 当所述 IP-CAN会话对应的承载永远在线能力 已激活时， 通知 NAT 功能实体不释放永远在线业务对应公网地址； 当所述 IP-CAN会话对应的承载永远在线能力没有激活时，通知 NAT功能实体不释放 永远在线业务对应公网地址， 且保持所述 IP-CAN会话不释放。
8、 如权利要求 6所述的方法， 其特征在于， 所述方法还包括：
当从来自用户设备的释放 IP-CAN会话的请求信息中获知所述 IP-CAN会 话的承载为永远在线业务承载时， 緩存业务服务器向所述用户设备发送的内 容； 当永远在线业务的承载保活成功后， 向所述用户设备发送緩存的内容； 或 者， 当永远在线业务的承载保活失败或不进行永远在线业务的承载保活时， 删 除緩存的内容。
9、 如权利要求 6所述的方法， 其特征在于， 所述方法还包括：
当从来自用户设备的释放 IP-CAN会话的请求信息中获知所述 IP-CAN会 话的承载为永远在线业务承载时，向 PCRF发送释放 IP-CAN会话的请求信息； 接收来自所述 PCRF 的不执行永远在线业务承载保活的策略， 并和所述 PCRF执行释放 IP-CAN会话的流程； 或者， 接收来自所述 PCRF的执行永远 在线业务承载保活的策略， 并和所述 PCRF执行释放 IP-CAN会话的流程、 重 激活永远在线业务的 IP-CAN会话的流程。
10、 如权利要求 6所述的方法， 其特征在于， 所述方法还包括：
当接收到来自 PCRF的采用第三类方式撤销 IP-CAN会话的永远在线能力 的去激活通知时，通知 NAT功能实体对永远在线业务启用公网地址管理方式， 并将 IP-CAN会话修改为数据业务的 IP-CAN会话， 基于第三类方式的去激活 通知中携带永远在线业务信息、 永远在线业务对应的 IP-CAN会话； 当接收到 来自 PCRF的采用第四类方式 4敦销 IP-CAN会话的永远在线能力的去激活通知 时， 通知 NAT功能实体对永远在线业务启用公网地址管理方式， 基于第四类 方式的去激活通知中携带永远在线业务信息； 或者，
当接收到来自 PCRF 的携带永远在线业务信息、 永远在线业务对应的
IP-CAN会话的去激活通知时， 确定所述 IP-CAN会话是否还存在其他永远在 线业务； 如果不存在其他永远在线业务， 通知 NAT功能实体对永远在线业务 启用公网地址管理方式， 并将 IP-CAN会话修改为数据业务的 IP-CAN会话； 如果存在其他永远在线业务， 通知 NAT功能实体对永远在线业务启用公网地 址管理方式。
11、 一种策略与计费规则功能实体 PCRF, 其特征在于， 包括： 接收模块， 用于接收来自业务服务器的永远在线业务请求信息， 所述请求 信息中携带永远在线业务对应的用户信息；
通知模块，用于通知核心网设备为所述用户信息对应的 IP-CAN会话保持 永远在线能力。
12、 如权利要求 11所述的 PCRF, 其特征在于，
所述通知模块，具体用于如果所述用户信息对应的 IP-CAN会话承载永远 在线能力已激活，通知所述核心网设备采用第一类方式为所述用户信息对应的 IP-CAN会话保持永远在线能力； 如果所述用户信息对应的 IP-CAN会话承载 永远在线能力没有激活，通知所述核心网设备采用第二类方式为所述用户信息 对应的 IP-CAN会话保持永远在线能力； 或者，
所述通知模块，具体用于当所述用户信息对应的 IP-CAN会话承载永远在 线能力已激活或者没有激活时， 通知所述核心网设备为所述用户信息对应的 IP-CAN会话保持永远在线能力， 由所述核心网设备确定采用第一类方式或者 第二类方式为所述用户信息对应的 IP-CAN会话保持永远在线能力。
13、 如权利要求 11所述的 PCRF, 其特征在于， 还包括：
第一处理模块，用于当从来自核心网设备的释放 IP-CAN会话的请求信息 中获知所述 IP-CAN会话的承载已经存在永远在线业务时，选择不执行永远在 线业务承载保活的策略，将选择的策略通知给所述核心网设备， 并和所述核心 网设备执行释放 IP-CAN会话的流程， 以及通知业务服务器所述 IP-CAN会话 对应的 7j远在线业务下线。
14、 如权利要求 11所述的 PCRF, 其特征在于， 还包括：
第二处理模块，用于当从来自核心网设备的释放 IP-CAN会话的请求信息 中获知所述 IP-CAN会话的承载已经存在永远在线业务时，选择执行永远在线 业务承载保活的策略，将选择的策略通知给所述核心网设备， 并和所述核心网 设备执行释放 IP-CAN会话的流程、 重激活永远在线业务的 IP-CAN会话的流 程； 如果永远在线业务的 IP-CAN 会话重激活失败， 通知业务服务器所述 IP-CAN会话对应的 7j远在线业务下线。
15、 如权利要求 11所述的 PCRF, 其特征在于，
所述接收模块， 还用于接收来自业务服务器的永远在线业务去激活信息， 所述去激活信息中携带永远在线业务对应的用户信息；
所述通知模块，还用于当所述用户信息对应的 IP-CAN会话不存在其他永 远在线业务时，通知核心网设备采用第三类方式撤销所述 IP-CAN会话的永远 在线能力； 当所述用户信息对应的 IP-CAN会话存在其他永远在线业务时， 通 知核心网设备采用第四类方式4款销所述 IP-CAN会话的永远在线能力； 或者， 所述通知模块， 还用于通知核心网设备4款销所述用户信息对应的 IP-CAN 会话的永远在线能力；由所述核心网设备确定采用第三类方式或者第四类方式 撤销所述 IP-CAN会话的永远在线能力。
16、 一种核心网设备， 其特征在于， 包括：
接收模块， 用于接收来自 PCRF的永远在线业务的请求通知， 所述请求通 知中携带永远在线业务信息、请求为永远在线业务的 IP-CAN会话保持永远在 线能力的信息；
能力保持模块，用于为所述永远在线业务的 IP-CAN会话保持永远在线能 力。
17、 如权利要求 16所述的核心网设备， 其特征在于，
所述能力保持模块，具体用于当接收到采用第一类方式为所述 IP-CAN会 话保持永远在线能力的请求通知时， 通知 NAT功能实体不释放永远在线业务 对应的公网地址； 当接收到采用第二类方式为所述 IP-CAN会话保持永远在线 能力的携带 IP-CAN会话信息的请求通知时， 通知 NAT功能实体不释放永远 在线业务对应公网地址， 且保持所述 IP-CAN会话不释放； 或者，
所述能力保持模块，具体用于当接收到为所述 IP-CAN会话保持永远在线 能力的携带 IP-CAN会话信息的请求通知时， 根据所述 IP-CAN会话信息确定 IP-CAN会话对应的承载永远在线能力已激活或者没有激活； 当所述 IP-CAN 会话对应的承载永远在线能力已激活时， 通知 NAT功能实体不释放永远在线 业务对应公网地址；当所述 IP-CAN会话对应的承载永远在线能力没有激活时， 通知 NAT功能实体不释放永远在线业务对应公网地址， 且保持所述 IP-CAN 会话不释放。
18、 如权利要求 16所述的核心网设备， 其特征在于， 还包括：
第一处理模块，用于当从来自用户设备的释放 IP-CAN会话的请求信息中 获知所述 IP-CAN会话的承载为永远在线业务承载时，緩存业务服务器向所述 用户设备发送的内容； 当永远在线业务的承载保活成功后， 向所述用户设备发 送緩存的内容； 或者， 当永远在线业务的承载保活失败或不进行永远在线业务 的承载保活时， 删除緩存的内容。
19、 如权利要求 16所述的核心网设备， 其特征在于， 还包括：
第二处理模块，用于当从来自用户设备的释放 IP-CAN会话的请求信息中 获知所述 IP-CAN会话的承载为永远在线业务承载时， 向 PCRF发送释放 IP-CAN会话的请求信息； 接收来自所述 PCRF的不执行永远在线业务承载保 活的策略， 并和所述 PCRF执行释放 IP-CAN会话的流程； 或者， 接收来自所 述 PCRF 的执行永远在线业务承载保活的策略， 并和所述 PCRF执行释放 IP-CAN会话的流程、 重激活永远在线业务的 IP-CAN会话的流程。
20、 如权利要求 16所述的核心网设备， 其特征在于， 还包括：
能力撤销模块， 用于当接收到来自 PCRF的采用第三类方式撤销 IP-CAN 会话的永远在线能力的去激活通知时， 通知 NAT功能实体对永远在线业务启 用公网地址管理方式， 并将 IP-CAN会话修改为数据业务的 IP-CAN会话， 基 于第三类方式的去激活通知中携带永远在线业务信息、 永远在线业务对应的 IP-CAN会话； 当接收到来自 PCRF的采用第四类方式4款销 IP-CAN会话的永 远在线能力的去激活通知时， 通知 NAT功能实体对永远在线业务启用公网地 址管理方式， 基于第四类方式的去激活通知中携带永远在线业务信息； 或者， 能力撤销模块， 用于当接收到来自 PCRF的携带永远在线业务信息、永远 在线业务对应的 IP-CAN会话的去激活通知时， 确定所述 IP-CAN会话是否还 存在其他永远在线业务； 如果不存在其他永远在线业务， 通知 NAT功能实体 对永远在线业务启用公网地址管理方式， 并将 IP-CAN会话修改为数据业务的 IP-CAN会话； 如果存在其他永远在线业务，通知 NAT功能实体对永远在线业 务启用公网地址管理方式。
21、 一种永远在线能力的提供系统， 其特征在于， 包括如权利要求 11-15 之一所述的策略与计费规则功能实体 PCRF, 以及如权利要求 16-20之一所述 的核心网设备。
22、 如权利要求 21所述的系统， 其特征在于， 还包括：
业务服务器， 用于在永远在线业务上线时， 向 PCRF发送携带永远在线业 务对应的用户信息的永远在线业务请求信息；在永远在线业务下线时，向 PCRF 发送携带永远在线业务对应的用户信息的永远在线业务去激活信息；
应用功能实体 AF, 用于在业务服务器向 PCRF发送携带永远在线业务对 应的用户信息的永远在线业务请求信息时，接收来自所述业务服务器的永远在 线业务请求信息， 并将永远在线业务请求信息发送给所述 PCRF; 在业务服务 器向 PCRF发送携带永远在线业务对应的用户信息的永远在线业务去激活信 息时，接收来自所述业务服务器的永远在线业务去激活信息， 并将永远在线业 务去激活信息发送给所述 PCRF。
PCT/CN2012/074346 2011-04-19 2012-04-19 一种永远在线能力的提供方法、系统和设备 Ceased WO2012142953A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201110097754.X 2011-04-19
CN201110097754.XA CN102752722B (zh) 2011-04-19 2011-04-19 一种永远在线能力的提供方法、系统和设备

Publications (1)

Publication Number Publication Date
WO2012142953A1 true WO2012142953A1 (zh) 2012-10-26

Family

ID=47032578

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2012/074346 Ceased WO2012142953A1 (zh) 2011-04-19 2012-04-19 一种永远在线能力的提供方法、系统和设备

Country Status (2)

Country Link
CN (1) CN102752722B (zh)
WO (1) WO2012142953A1 (zh)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104137641A (zh) * 2013-01-31 2014-11-05 华为技术有限公司 保持应用在线的方法、永久在线控制器和设备
CN104253739B (zh) * 2013-06-28 2018-08-10 中国移动通信集团公司 一种永远在线业务的实现方法、系统和设备
CN104427598B (zh) * 2013-09-09 2018-02-23 中国移动通信集团公司 长时间在线业务免心跳的方法和装置
CN104703146B (zh) 2013-12-09 2019-03-08 腾讯科技（深圳）有限公司 信息推送方法、客户端及系统
CN104065661B (zh) * 2014-06-27 2017-07-28 北京思特奇信息技术股份有限公司 一种降低移动互联网ott业务网络资源消耗的方法及系统
US10321395B2 (en) 2015-04-10 2019-06-11 Huawei Technologies Co., Ltd. Data packet processing method and related device
CN108540428B (zh) * 2017-03-02 2021-10-01 华为技术有限公司 业务处理方法、设备及系统

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101051968A (zh) * 2006-04-04 2007-10-10 华为技术有限公司 保持终端永远在线的方法及装置
CN101227740A (zh) * 2008-02-01 2008-07-23 华为技术有限公司 一种接入sae核心网的方法、系统及装置
WO2010073263A2 (en) * 2008-12-23 2010-07-01 Spice Digital Limited Instant messaging over unstructured supplementary service data (ussd)

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2529313C (en) * 2004-02-09 2008-07-15 Research In Motion Limited Methods and apparatus for controlling wireless network operations associated with a flow control process
WO2008084306A2 (en) * 2006-12-28 2008-07-17 Nokia Corporation Interworking of policy and charging control and network address translator
CN101860556A (zh) * 2009-04-08 2010-10-13 北京闻言科技有限公司 一种保持用户在线安全稳定的心跳技术

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101051968A (zh) * 2006-04-04 2007-10-10 华为技术有限公司 保持终端永远在线的方法及装置
CN101227740A (zh) * 2008-02-01 2008-07-23 华为技术有限公司 一种接入sae核心网的方法、系统及装置
WO2010073263A2 (en) * 2008-12-23 2010-07-01 Spice Digital Limited Instant messaging over unstructured supplementary service data (ussd)

Also Published As

Publication number Publication date
CN102752722B (zh) 2016-10-12
CN102752722A (zh) 2012-10-24

Similar Documents

Publication Publication Date Title
CN103535080B (zh) 用于在接入网络之间转换用户的方法、系统和计算机可读媒体
CN103828476B (zh) 控制服务会话的资源的方法和网络节点以及对应的系统和计算机程序
WO2012142953A1 (zh) 一种永远在线能力的提供方法、系统和设备
US9949191B2 (en) Methods, devices and computer programs for providing a service or service component requiring a specific packet-forwarding treatment
CN104247331B (zh) 用于管理网络资源的方法和节点以及相应的系统和计算机程序
CN103636163A (zh) 用于策略控制的方法和用于承载控制的方法以及对应的服务器、系统和计算机程序
CN101540980A (zh) 业务优先级更新指示方法、业务优先级更新方法及装置
WO2008116406A1 (fr) Procédé de commande, système et entité de fonction pour notifier un événement de flux d'internet de signalisation
WO2014101228A1 (zh) 无线网络的能力开放系统、网关、代理和方法
CN104782168A (zh) Pcrf装置和用于pcrf的业务处理方法
WO2021063129A1 (zh) 核心网能力调用方法及系统
WO2010015171A1 (zh) 一种处理状态信息的方法及其装置、系统及客户端
JP7066734B2 (ja) 制御プレーン接続管理方法および装置
US9716629B2 (en) Capability negotiation and control
WO2011110021A1 (zh) 一种策略控制方法、系统及策略控制器
CN102577449B (zh) 优先级业务激活、去激活方法、装置和系统
WO2010108367A1 (zh) 业务切换方法、业务信息控制方法、相关设备及系统
WO2009089776A1 (en) Method and apparatus for the policy and charging rule function information maintenance
JP4406204B2 (ja) ２層通信ネットワークにおける接続解除
CN101572950A (zh) Ip多媒体子系统会话建立的方法及装置
WO2014176987A1 (zh) 策略控制方法及网元
CN103139849B (zh) 一种多网协同下的QoS业务执行方法和AF、PCRF
CN105451253A (zh) 一种策略控制方法及装置、dra、p-cscf
CN101835211B (zh) 回退媒体状态的方法
CN102075908A (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: 12774569

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12774569

Country of ref document: EP

Kind code of ref document: A1