WO2008131674A1 - Procédé, système et dispositif servant à examiner un événement de transport - Google Patents

Procédé, système et dispositif servant à examiner un événement de transport Download PDF

Info

Publication number
WO2008131674A1
WO2008131674A1 PCT/CN2008/070762 CN2008070762W WO2008131674A1 WO 2008131674 A1 WO2008131674 A1 WO 2008131674A1 CN 2008070762 W CN2008070762 W CN 2008070762W WO 2008131674 A1 WO2008131674 A1 WO 2008131674A1
Authority
WO
WIPO (PCT)
Prior art keywords
event
type
range
detection
bearer
Prior art date
Application number
PCT/CN2008/070762
Other languages
English (en)
Chinese (zh)
Inventor
Shiyong Tan
Yan Li
Weihua Wei
Shibi Huang
Peng Zhao
Yuxin Mao
Original Assignee
Huawei Technologies Co., Ltd.
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 Huawei Technologies Co., Ltd. filed Critical Huawei Technologies Co., Ltd.
Publication of WO2008131674A1 publication Critical patent/WO2008131674A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0894—Policy-based network configuration management

Definitions

  • This invention relates to the field of communications technology and, more particularly, to a method, system and apparatus for detecting bearer events.
  • IP networks can provide a variety of services, such as multimedia calls, file downloads, web browsing, etc., where different services have different requirements for QoS (including bandwidth, delay, packet loss rate, etc.), and billing The requirements are also different. For example: Online billing or offline billing can be used, and it can be charged according to the flow rate or according to the time.
  • QoS Quality of Service
  • the Third Generation Partnership Project (3GPP) defines a Policy and Charging Control (PCC) architecture, through which different schemes can be satisfied. QoS control and billing requirements.
  • PCRF Policy Control and Charging Rules Function
  • the PCRF entity determines the corresponding policy according to the operator policy, the user subscription data, and the service information currently being performed by the user, and provides the policy to the Policy and Charging Enforcement Function (PCEF), which is executed by the PCEF.
  • PCEF Policy and Charging Enforcement Function
  • User subscription data can be obtained from the User Profile Data Repository (SPR) function entity.
  • SPR User Profile Data Repository
  • Policies include detection rules for service data flows (collections of IP flows that complete a service such as voice communication), whether to gate, QoS, flow-based charging rules, and so on.
  • PCEF is mainly used to complete the detection of service data flows, the execution of policies, flow-based charging, etc.
  • the entity performs the policy that is sent or specified by the PCRF, specifically, performs detection and measurement of the service data flow, guarantees QoS of the service data flow, user plane traffic processing, and session management of the trigger control plane.
  • the functional entity is used to provide user subscription data to the PCRF.
  • the application layer function entity (Appl ica t ion Funct ion, AF), the function entity is used to dynamically provide session information of the application layer service to the PCRF, and the PCRF formulates a corresponding policy, and the AF can obtain the IP connectivity access network from the PCRF ( IP-Connect iv i ty Acces s Network , IP-CAN ) related information and IP-CAN bearer related events.
  • PCRF IP-Connect iv i ty Acces s Network , IP-CAN
  • the interface between AF and PCRF is the Rx reference point.
  • the reference point is used by the AF to deliver application layer related information, including an IP filter (such as a source IP address, a destination IP address, a protocol type, a source port number, a destination port number, etc.) for identifying a service data flow, an application, or a media. Required bandwidth information.
  • the PCRF can also provide IP-CAN related information, report bearer events, etc. to the AF through the reference point. This reference point uses the Diameter ten defined by the Internet Eng ineering Task Force (IETF).
  • IP-CAN When the user roams within the access network (when the location changes), the IP service continuity can be preserved (ie, the service is not interrupted).
  • the access network with such a nature is called IP-CAN, such as (Genera l Packet Radio Service, GPRS). Network, interworking-WLAN (I-WLAN) network, etc.
  • IP-CAN session refers to the association between the UE and the PDN, and is identified by the IP address of the User Equipment (UE) and the identity of the UE (such as IMSI).
  • UE User Equipment
  • IMSI Interworking-WLAN
  • the IP-CAN exists as long as the UE is assigned an IP address and can be identified by the IP network.
  • An IP-CAN session can contain one or more IP-CAN bearers.
  • the strategy formulated by the PCRF and the specific IP-CAN bearer binding can be implemented by PCRF or PCEF, respectively.
  • IP-CAN bearer 1 in Figure 2 has higher QoS than IP-CAN bearer 2, thus for QoS.
  • High-demand services such as VOIP, multimedia calls, etc.
  • IP-CAN bearer 1 for lower QoS requirements (such as file downloading, web browsing) Etc.)
  • IP-CAN bearer 2 can be used.
  • the PCEF identifies the IP flow according to the flow description information (such as source IP address, destination IP address, protocol type, source port number, destination port number, etc.) in the PCC rule.
  • the IP flow is composed of the same source IP address, destination IP address, transport layer protocol, source port number, and destination port number (collectively IP quintuple, if the corresponding transport layer protocol does not have a port number concept, source port number and destination A one-way flow consisting of IP packets whose port number can be omitted.
  • each IP Flow is described by an F low-Descr ipt ion AVP.
  • multiple IP-CAN bearers can be established in one IP-CAN session, and one IP-CAN bearer can be used to transmit one or more IP flows (requires that these IP flows have the same QoS requirements)
  • a PCC rule can only be used for one IP-CAN bearer, and one IP-CAN bearer can have one or more PCC rules.
  • the AF request event escalation can only be directed to the entire D i ame t e r session between AF and PCRF.
  • AF needs to pay attention not to all IP flows in the entire session, and may only be some IP flows, but the prior art PCEF may detect IP-CAN bearers or IP flows that are not concerned, and will appear. The detection status is reported, and the PCRF also needs to report to the AF.
  • AF does not need this information, which leads to redundant message interaction between PCEF and PCRF, between PCRF and AF, adding unnecessary load between the three devices.
  • AF only pays attention to the interruption of IP flow 1 as shown in Figure 1 (this will cause the service to abort), and does not pay attention to other IP flows as shown in Figure 2.
  • the PCRF must instruct the PCEF to report all IP-CAN bearer interruptions in the session. Summary of the invention
  • the main purpose of the embodiments of the present invention is to provide a method for detecting bearer events to reduce redundant message interaction.
  • Another object of embodiments of the present invention is to provide a system for detecting bearer events to reduce redundant message interaction.
  • a further object of embodiments of the present invention is to propose an AF to reduce redundant message interaction.
  • Another object of embodiments of the present invention is to propose a PCRF to reduce redundant message interaction.
  • the technical solution of the embodiment of the present invention is implemented as follows: A method for detecting a bearer event, the method includes:
  • the application layer function entity AF sends a bearer event detection request to the policy control and charging rule function entity PCRF, where the bearer event detection request includes an event detection type range and event detection corresponding to each event type in the event detection type range. Scope
  • the PCRF detects this type of event within the event detection range of each event type, and returns the type of event of the detected event to the AF and the range of influence of the detected event.
  • a system for detecting bearer events comprising AF and PCRF, wherein:
  • An AF configured to send a bearer event detection request to the PCRF, where the bearer event detection request includes an event detection type range and an event detection range corresponding to each event type in the event detection type range;
  • the PCRF is configured to detect the type of event within the event detection range of each event type, and return the type of the event of the detected event to the AF and the range of influence of the detected event.
  • An AF includes a bearer event detection request sending unit and an event processing unit, where: a bearer event detecting request sending unit is configured to send a bearer event detecting request to the PCRF, where the bearer event detecting request includes an event detecting type range and Corresponding to an event detection range of each event type in the event detection type range;
  • the event processing unit is configured to process the event according to an application layer policy after receiving the event type of the event detected by the PCRF and the scope of the detected event.
  • the PCRF includes an event detecting unit and a detection result returning unit, where: an event detecting unit is configured to receive a bearer event detecting request sent by the AF, and detect the type in the event detecting range of each event type.
  • An event where the bearer event detection request includes an event detection type range and an event detection range corresponding to each event type in the event detection type range;
  • the detection result returning unit is configured to return the type of the event of the detected event to the AF and the influence range of the detected event.
  • the AF request PCRF detects the reported event, it indicates the range of the detected event type and the detection range, and the detection range may be the entire D i ame ter session or the media stream or the media sub- Any combination of stream and IP flow, the detection range of different events can be different.
  • the PCRF detects the event specified by the AF in the range specified by the AF according to the request of the AF. After detecting the corresponding event, the PCRF reports the type of the event and the scope of the event to the AF, where the impact range may be the entire Diameter session or media.
  • FIG. 1 is a schematic diagram of a PCC structure in the prior art
  • FIG. 2 is a schematic diagram of correspondence between IP flows, PCC rules, IP-CAN bearers, and IP-CAN sessions in the prior art
  • FIG. 3 is a schematic flowchart of a method for detecting a bearer event according to an embodiment of the present invention
  • FIG. 4 is a schematic flowchart of a method for detecting a bearer event according to a first embodiment of the present invention
  • FIG. 5 is a schematic flowchart of a method for detecting a bearer event according to a second embodiment of the present invention
  • FIG. 6 is a diagram for detecting a bearer event according to an embodiment of the present invention. Schematic diagram of the system structure
  • Figure ⁇ is a schematic diagram of an AF structure according to an embodiment of the present invention.
  • FIG. 8 is a schematic diagram showing the structure of a PCRF according to an embodiment of the present invention.
  • the Diameter series protocol used in the embodiments of the present invention is a new generation of Authentication Authorization Answer (AAA) technology, and the purpose is to create an IP network (including NGN) that can fully satisfy the current and future. And 3G, etc.) AAA protocol for user access control requirements.
  • the Diame ter protocol is a remote authentication dial-up user service ( Remote Authent ica t ion Upgrade of the Dia L-In User Service (RADIUS) protocol, including the basic protocol, the transport protocol, and the extended protocol for different application scenarios.
  • the extension for different application scenarios in Diameter is called an application, such as the Rx and Gx reference in the PCC architecture. Points are two different Diameter applications).
  • the basic functions shared by various applications are implemented in the base protocol, and the functions specific to different application scenarios are defined in each application.
  • both the Diameter client and the Diameter server can actively send request messages to the peer.
  • the Diameter client performs a series of information exchange with the Diameter server, and such a series of information interactions from initiation to suspension is called a Diameter session.
  • the establishment of a Diameter session is generally initiated by the client.
  • the end of the Diameter session is completely determined by the client, but the server can also issue an abort session request first. If the client agrees to abort the request, it will respond to the abort session response, and then the client will issue a session end request to notify the server to end the user. Session, otherwise the session is still maintained.
  • the Diameter message consists of a message header and a message body.
  • the message header includes the protocol version number, the application identifier (identifying different Diameter applications), the command code (Command Code, indicating the message type), the message length, etc., and the message body is composed of attribute values. (At tr ibute-Va lue-Pa ir , AVP ) composition.
  • Different types of Diameter messages can contain different AVPs. Each application can define an AVP specific to the application. It is an extension mechanism of Diameter to define a new AVP to implement new functions.
  • FIG. 3 is a schematic flowchart of a method for detecting a bearer event according to an embodiment of the present invention. As shown in Figure 3, the method includes:
  • Step 301 The AF sends a bearer event detection request to the PCRF, where the bearer event detection request includes an event detection type range and an event detection range corresponding to each event type in the event detection type range.
  • the event detection range may be an entire Diameter session, or any combination of a media stream, a media substream, and an IP stream. Also, the event detection type range can include all event types. Or include at least one specific event type.
  • each media stream is described by a Media-Component-Descr i pt ion AVP. Multiple media streams in the same session are identified by ber AVP via Media-Component-N. If AF uses the Session Description Protocol (SDP) to describe the media, then a media stream corresponds to the m line (media description line) in the SDP. The Media-Component-Number corresponding to the media stream is that the m line appears in the SDP. The sequence number.
  • SDP Session Description Protocol
  • the media substream is further subdivided into the media stream.
  • RTP Real Time Transport Protocol
  • the corresponding RTP stream and the RTCP stream respectively correspond to one media substream.
  • each media substream is described by a Media-Sub-Component AVP.
  • the multiple media substreams in the same media stream are identified by the Flow-Number AVP, and the Flow-Number can be sorted according to the port number corresponding to each media substream.
  • the media substream can correspond to a bidirectional flow (containing two Flow-Descr IVPs, describing two IP flows), or a unidirectional flow (containing only one Flow-Descr iption AVP, describing an IP flow).
  • the AF request PCRF detects the reported event, it indicates the type of the event to be detected and the detection range, and the detection range of the different types of events may be different.
  • Step 302 The PCRF detects the type of event in the event detection range of each event type, and returns the type of the event of the detected event to the AF and the influence range of the detected event.
  • the PCRF detects the event specified by the AF in the range specified by the AF according to the request of the AF. After detecting the corresponding event, the PCRF reports the type of the event and the scope of the event to the AF, and the impact range may be the entire Diameter session. Or any combination of media streams, media substreams, and IP streams.
  • the event detection range of each event detection type in the event detection type range is not the same, and the range of influence of each detected event is not the same; or the event detection range of each event detection type in the event detection type range is the same, And the range of the impact of each detected event is the same; or the event detection range of each event detection type in the range of the event detection type is not the same, and the range of influence of each detected event is the same; or each of the types of event detection types
  • the event detection type has the same range of event detection, and the range of influence of each detected event is not the same.
  • the AF may request the PCRF to detect the reported event, and may request to add, delete, and modify the reported event, and may send a request message (such as AAR) to the PCRF in the AF.
  • AAR request message
  • the indication in can also be indicated in the response message (such as RAA) of the AF response PCRF.
  • the AF may further send a cancel bearer event detection request to the PCRF, where the cancel bearer event detection request includes a cancel detection event type range and corresponding to the cancel detection event, when the event type of the cancellation detection report needs to be increased.
  • the AF may further send an increase bearer event detection request to the PCRF, where the increased bearer event detection request includes an increase detection event type range and corresponding to the increased detection event type.
  • the AF may send a modify bearer event detection request to the PCRF, where the modified bearer event detection request includes the detection event type range to be modified and the type of the detection event to be modified.
  • the invention can also be used for signaling path state detection.
  • the Media-Component-Number of the signaling stream can be 0 or a special number (3x4 OxFFFFFF).
  • the flow-number AVP is specified by the AF, and the signaling flow is described by the Flow-Description AVP, so that the event detection report of the signaling flow is consistent with the event detection report of the media stream, and there is no need to establish a new Diameter session for the signaling path state detection.
  • the AF may request the PCRF to detect the reported event in the request message.
  • Figure 4 is the first in accordance with the present invention A schematic diagram of a method for detecting a bearer event of an embodiment.
  • the method includes:
  • Step 401 The AF sends a request message (for example, may be an AAR message to the PCRF), and requests the PCRF to detect the reported event, where the detected event type range and the detection range are specified, and the detection range may be the entire Diameter session or the media stream, Any combination of media sub-flow and IP flow, the detection range of different events may be the same or different.
  • the event type can use the wildcard method to request to detect and report all event types at one time, or request to detect and report one or some events.
  • Step 402 The PCRF returns a response message to the AF (for example, an AAA message;).
  • Step 403 The PCRF detects the AF-specified event within the range specified by the AF according to the AF indication and the PCEF.
  • Step 404 After the PCRF detects the corresponding event, the PCRF sends a request message (such as a RAR message) to the AF, and reports the event type and the scope of the event.
  • the impact range may be the entire Diameter session or the media stream, the media substream, and the IP stream. combination.
  • the event impact range indicated when the PCRF is reported must be within the detection range specified by the AF request. Events that occur outside the detection range specified by the AF are not reported, and the event types that the AF does not specify are not reported.
  • the PCRF can report multiple events at once, and the impact range of these events can be the same or different.
  • Step 405 The AF sends a response message to the PCRF (such as a RAA message;);
  • Step 406 The AF extracts corresponding measures according to the policy of the application layer and the reported event (such as tearing down the service, modifying the service by signaling, etc.).
  • FIG. 5 is a flow chart showing a method for detecting a bearer event according to a second embodiment of the present invention.
  • the method includes:
  • Step 501 The PCRF sends a request message (such as a RAR message;) to the AF.
  • a request message such as a RAR message
  • Step 502 The AF returns a response message (such as a RAA message) to the PCRF, and requests the PCRF to detect the reported event.
  • the message indicates the range of the detected event type and the detection range.
  • the detection range may be the entire Diameter session or the media stream, the media substream, and the IP stream. Any combination of different events
  • the measurement range can be different.
  • the event type may request to detect and report all event types in a wildcard manner, or may request to detect and report one or some events.
  • Step 503 The PCRF cooperates with the PCEF according to the AF indication to detect the AF-specified event within the range specified by the AF.
  • Step 504 After the PCRF detects the corresponding event, the PCRF sends a request message (such as a RAR message) to the AF, and reports the event type and the scope of the event.
  • the impact range may be the entire Diameter session or the media stream, the media substream, and the IP stream. combination.
  • the event impact range indicated when the PCRF is reported must be within the detection range specified by the AF request. Events that occur outside the detection range specified by AF are not reported, and AF does not report the type of event that is not specified.
  • the PCRF can report multiple events at a time, and the impact range of these events can be the same or different;
  • Step 505 The AF sends a response message to the PCRF (such as an RAA message;);
  • Step 506 The AF extracts corresponding measures according to the policy of the application layer and the reported event (such as tearing down the service, modifying the service by signaling, etc.).
  • Diameter protocol the protocol between AF and PCRF.
  • the present invention will be described in detail below by taking the Diameter protocol as an example. However, those skilled in the art will appreciate that the present invention is not limited to the Diameter protocol.
  • IP-Flows AVP is a newly defined AVP. This AVP is used to locate one or more IP flows.
  • the Direction is an enumerated type. The value can be UPLINK (0, Up), DOWNLINK. (1, down), BOTH (2, two-way). ⁇ ... ⁇ indicates comparison parameters, tincter indicates optional parameters, and * indicates that there can be multiple (subsequent use of the same rules).
  • Flow-Number does not appear to represent all media substreams in the media stream corresponding to Media-Component-Number, and Direction does not appear to indicate that upstream and downstream are included.
  • the specific-action AVP is an existing AVP. However, it is not used directly for the AF request to detect the reported event. It is not directly used by the PCRF to report events to the AF. It is only used to define various event types and is defined on the basis of the original value. A new enumeration value: ALL, which means that all event types are wildcarded, and ALL can only be used in messages sent by the AF to the PCRF.
  • IP-Flows-Specific-Action AVP is a newly defined AVP that binds events and IP flows together. IP-Flows does not appear to indicate that the event is for the entire Diameter.
  • IP-Flows-Specific-Action AVP is a newly defined AVP, enumerated type, with values of ADD (0, increase;), REMOVE (1, delete;), UPDATE (2, update;), for AF indication PCRF How to operate IP-Flows-Specific-Action.
  • ADD can be used to add a new event type or increase the detection range of the event that has been requested to be reported.
  • REMOVE is used to delete the event type that has been requested to be reported or to reduce the detection range of the event that has been requested to be reported.
  • UPDATE is used to delete all the original requests. The escalated event is replaced with the event in the new message.
  • IP-Flows-Specific- Action-Operation: : ⁇ AVP Header: x >
  • IP-Flows-Specific-Action-Operation AVP is a newly defined AVP for AF direction
  • the PCRF adds, deletes, and updates the reported detection event.
  • IP-Flows-Specific-Action-Operation AVPs are included in the request message (such as AAR) or response message (such as RAA) sent to the PCRF, and multiple detection ranges are included.
  • the same event can be included in the same IP-Flows-Specific-Action-Operation AVP. If the detection range of one or some events is the entire Diameter session, the corresponding IP-Flows-Specific-Action AVP does not include the IP-Flows AVP, otherwise the corresponding IP-Flows-Specific-Action AVP may contain one or more.
  • IP-Flows AVP to indicate the event detection range (any combination of media stream, media substream, and IP stream). AF uses different Operation-Types to flexibly add, delete, modify, and update reported events.
  • the PCRF When the PCRF reports an event to the AF, it can flexibly report the event to the AF by including one or more IP-Flows-Specific-Action AVPs in the request message (such as RAR) or the response message (such as AAA) sent to the AF. Multiple events with the same range of influences can be included in the same IP-Flows-Specific-Action-Operation AVP. If the impact scope of one or some events is the entire Diameter session, the corresponding IP-Flows-Specific-Action AVP does not include the IP-Flows AVP, otherwise the corresponding IP-Flows-Specific-Action AVP may contain one or more. IP-Flows AVP to indicate the scope of impact of the event (any combination of media stream, media substream, and IP stream).
  • This kind of scheme has a large change to the existing mechanism, and the advantage is that it is very flexible and convenient.
  • Flows AVP is an existing AVP that adds Direction AVP to the original so that it can locate an IP stream.
  • Direction is an enumerated type, which can be UPLINK (0, Up), DOWNLINK (1, Down), BOTH (2, Bidirectional).
  • Flow-Number does not appear to indicate all media substreams in the media stream corresponding to Media-Component-Number, and Direction does not appear to indicate that upstream and downstream are included.
  • the Specific-Action AVP is an existing AVP. It can still be used by the AF to report events to the PCRF and the PCRF to report events to the AF.
  • Two new enumeration values are defined: DETECT—ALL and REMOVE—ALL, where DETECT—ALL indicates the AF request.
  • the PCRF detects all events, and REMOVE_ALL indicates that the AF request PCRF cancels the detection and reports all events.
  • the two newly defined values can only be used in the message sent by the AF to the PCRF.
  • the AF request is reported to the PCRF to detect the reported event
  • only one or more Specific-Action AVPs are included in the request message (such as AAR) or response message (such as RAA) sent to the PCRF, and the event detection range is the Diameter message in the entire Diameter session.
  • the Flow AVP is not carried in the flow, otherwise one or more Flows AVPs may be carried to indicate the scope of influence (any combination of media stream, media substream and IP stream).
  • the newly issued Specific-Action AVP is superimposed on the original basis.
  • you need to delete one or some events you can include multiple Specific-Action AVPs in the message.
  • the first value is REMOVE-ALL.
  • the event that is requested to be reported, and the subsequent Specific-Action indicates the reported event that needs to be retained.
  • the PCRF When the PCRF reports an event to the AF, it only needs to include one or more Specific-Action AVPs in the request message (such as RAR) or response message (such as AAA) sent to the AF.
  • the event impact range is not carried in the message when the entire Diameter session is used.
  • Flows AVP otherwise one or more Flows AVPs can be carried to indicate the scope of influence (any combination of media stream, media substream and IP stream).
  • Flows AVP is an existing AVP that adds Direction AVP to the original so that it can locate an IP stream.
  • Direction is an enumerated type, which can be UPLINK (0, Up), DOWNLINK (1, Down), BOTH (2, Bidirectional).
  • Flow-Number does not appear to indicate all media substreams in the media stream corresponding to Media-Component-Number, and Direction does not appear to indicate that upstream and downstream are included.
  • the Specific-Action AVP is an existing AVP. It can still be used by the AF to report events to the PCRF and the PCRF to report events to the AF.
  • Two new enumeration values are defined: DETECT—ALL and REMOVE—ALL, where DETECT—ALL indicates the AF request.
  • the PCRF detects all events, and REMOVE_ALL indicates that the AF request PCRF cancels the detection and reports all events.
  • the two newly defined values can only be used in the message sent by the AF to the PCRF.
  • the Media-Component-Description AVP is an existing AVP, and the Specific-Action AVP is used to indicate that the detection range is the media stream when the AF requests the PCRF to report the reported event.
  • the Media-Sub-Component AVP is an existing AVP, and the parameter Specific-Action AVP is used to indicate that the detection range is a media sub-flow when the AF requests the PCRF to detect the reported event.
  • the AF when the AF requests the PCRF to detect the reported event, it can be in the same Diameter.
  • the PCRF is used to report different events with different detection scopes by including different Specific-Action AVPs in the Media-Component-Description AVP and/or the Media-Sub-Component AVP, and the other aspects are the same as the second method.
  • Flows AVP is an existing AVP that adds Direction AVP to the original so that it can locate an IP stream.
  • Direction is an enumerated type, which can be UPLINK (0, Up), DOWNLINK (1, Down), BOTH (2, Bidirectional).
  • Flow-Number does not appear to indicate all media substreams in the media stream corresponding to Media-Component-Number, and Direction does not appear to indicate that upstream and downstream are included.
  • the Specific-Action AVP is an existing AVP. However, it is not used directly for the AF request PCRF report event. It is not directly used by the PCRF to report events to the AF. It is only used to define various event types. Define two new enumeration values: DETECT—ALL and REMOVE—ALL, where DETECT—ALL indicates that the AF request PCRF detection reports all events, and REMOVE—ALL indicates that the AF request PCRF cancels detection and reports all events, these two newly defined values. Both can only be used in messages sent by the AF to the PCRF.
  • IP-Flows-Specific-Action AVP is a newly defined AVP that binds events and IP flows together. IP-Flows does not appear to indicate that the event is for the entire Diameter.
  • IP-Flows-Specific-Action AVPs are included in the request message (such as AAR) or response message (such as RAA) sent to the PCRF, if one of the events
  • the detection range is the entire Diameter session, and the corresponding IP-Flows-Specific-Action AVP does not include the Flows AVP. Otherwise, the corresponding IP-Flows-Specific-Action AVP may include one or more Flows AVPs to indicate the event detection range (media stream). , any combination of media substream and IP stream).
  • the newly-issued Specific-Action AVP is superimposed on the original basis.
  • IP-Flows-Specific-Action AVPs When you need to delete one or some events, you can include multiple IP-Flows-Specific-Action AVPs in the message, the first IP-Flows-Specific The value of the Specific-Action in the -Action is REMOVE_ALL, the event that was requested to be reported is canceled, and the subsequent IP-Flows-Specific-Action indicates that the event needs to be reported. To cancel all the packets, you need to carry an IP-Flows-Specific-Action AVP in the Diameter message with the value of Specific-Action being REMOVE-ALL.
  • the PCRF When the PCRF reports an event to the AF, it can flexibly report the event to the AF by including one or more IP-Flows-Specific-Action AVPs in the request message (such as RAA) or the response message (such as AAA) sent to the AF. If the impact range of one of the events is the entire Diameter session, the corresponding IP-Flows-Specific-Action AVP does not include the Flows AVP, otherwise the corresponding IP-Flows-Specific-Action AVP may include one or more Flows AVPs to indicate The scope of the event (any combination of media stream, media substream, and IP stream).
  • FIG. 6 is a schematic structural diagram of a system for detecting a bearer event according to an embodiment of the present invention. As shown in Figure 6, the system includes AF 601 and PCRF 602, where:
  • the AF 601 is configured to send a bearer event detection request to the PCRF 602, where the bearer event detection request includes an event detection type range and an event detection range corresponding to each event type in the event detection type range;
  • PCRF 602 which is used to detect this type of event within the event detection range of each event type. And returning to AF 601 the type of event of the detected event and the range of influence of the detected event.
  • the AF 601 may be further configured to send a cancel bearer event detection request to the PCRF 602, where the cancel bearer event detection request includes a cancel detection event type range and a cancellation corresponding to each event type in the cancel detection event type range. Range of event detection;
  • the PCRF 602 is further configured to cancel the detection of the event of the type within the cancellation event detection range of each cancellation detection event type.
  • the AF 601 may be further configured to send an increase bearer event detection request to the PCRF 602, where the increase bearer event detection request includes an increase detection event type range and an event detection range corresponding to each event type in the increase detection event type range. ;
  • the PCRF 602 can be further configured to detect the event of the type within the event detection range of each of the increased detection event types, and return the type of the event of the detected event to the AF 601 and the range of influence of the detected event.
  • the AF 601 may be further configured to send a modified bearer event detection request to the PCRF 602.
  • the modified bearer event detection request includes a detection event type range to be modified and an event detection range to be modified corresponding to each event type in the range of the detection event type to be modified;
  • the PCRF 602 is further configured to detect the event of the type to be modified within the range of the event to be modified for each type of the detected event to be modified, and return the type of the event of the detected event to the AF 601 and the range of influence of the detected event.
  • the AF 601 can send a bearer event detection request to the PCRF 602 through an AAR message or a RAA message.
  • the PCRF 602 can return the type of the event of the detected event and the range of influence of the detected event to the AF 601 through the RAR message or the AAA message.
  • the AF 601 may be further configured to process the event according to an application layer policy after receiving the type of the event in which the event is detected and the scope of the detected event.
  • the AF may request the PCRF to detect the reported event, and may request to add, delete, and modify the reported event, and may send the request to the PCRF in the AF.
  • Message such as an authentication authorization request message
  • the indication in (Auth-Author iza t ion-Reques t , AAR ) can also be indicated in the response message of the AF response PCRF, such as Re-Auth-Answer (RAA), so the actual operation More flexible.
  • Figure ⁇ is a schematic diagram of an AF structure in accordance with an embodiment of the present invention.
  • the AF includes a bearer event detection request transmitting unit 701 and an event processing unit 702, where:
  • the bearer event detection request sending unit 701 is configured to send a bearer event detection request to the PCRF, where the bearer event detection request includes an event detection type range and an event detection range corresponding to each event type in the event detection type range.
  • the event processing unit 702 is configured to process the event according to an application layer policy after receiving the event type of the event detected by the PCRF and the affected range of the detected event.
  • FIG. 8 is a schematic diagram showing the structure of a PCRF according to an embodiment of the present invention.
  • the PCRF includes an event detecting unit 801 and a detection result returning unit 802.
  • the event detecting unit 801 is configured to receive a bearer event detection request sent by the AF, and detect the event of the type in the event detection range of each event type, where the bearer event detection request includes an event detection type range and corresponding An event detection range for each event type in the range of event detection types.
  • the detection result return unit 802 is configured to return the type of the event of the detected event to the AF and the influence range of the detected event.
  • the embodiment of the present invention first provides a method for detecting a bearer event by using an AF.
  • the AF request PCRF detects the reported event type and the detection range, and the detection range may be any combination of the entire Diameter session or the media stream, the media substream, and the IP stream, and different
  • the detection range of the event may be the same or different.
  • the event type may request to detect and report all event types in a wildcard manner, or may request to detect and report one or some events; the PCRF cooperates with the PCEF according to the AF request.
  • the AF specified event is detected within the range specified by the AF. After detecting the corresponding event, the PCRF reports to the AF
  • the event type and the scope of the impact may be any combination of the entire Diameter session or the media stream, the media substream, and the IP stream.
  • the event impact range indicated by the PCRF reporting must be within the detection range specified by the AF request, and the AF designation. Events that occur outside of the detection range are not reported, and AF does not specify the type of event and does not report it.
  • the PCRF can report multiple events at once, and the impact range of these events can be the same or different.
  • the AF can also take corresponding measures according to the policies of the application layer and the reported events (such as tearing down services, modifying services through signaling, etc.).
  • the PCRF can be requested to cancel the report bearer event, indicating the type of the event to be canceled and the detection range.
  • the detection range can be any combination of the entire Diameter session or media stream, media substream and IP stream.
  • the event type can be used in the wildcard mode to cancel the detection and report all event types, or cancel the detection to report some or some events.
  • the detection range when the AF cancels the reporting event may be larger than the detection range indicated when the previous requesting the reporting event (for example, after requesting an event to be reported on a certain media stream, requesting to cancel the reporting event on the entire session, in the media stream) Of course, it is also canceled.) (For example, after requesting an event to be reported on the entire Diameter session, requesting to cancel the event on a media stream, indicating that the event is continuously detected on other media streams) may also be equal. .
  • the PCRF can be requested to increase the detection and reporting of the bearer event.
  • the AF can request to modify the range of detecting the bearer event (increase or decrease).
  • the PCRF After the PCRF detects the reported event, it can request the PCRF to update and detect the reported event type and detection range, that is, directly replace the request with the reported event type and detection range carried in the new message.
  • the AF may request the PCRF to report the event, or may request to add, cancel, or modify the reported event, which may be indicated in the request message (such as AAR) sent by the AF to the PCRF. It can also be indicated in the response message (such as RAA) of the AF response PCRF.
  • the PCRF reports an event to the AF, it may be indicated in a request message (such as RAR) sent by the PCRF to the AF, or may be indicated in a response message (such as AAA) of the PCRF response AF.
  • the AF may request the PCRF to report certain events at any time, and may also cancel the detection of reporting certain events, increasing the detection of other events, or modifying the detection range of the event.
  • the granularity of detection of an event can be any combination of the entire Diameter session or media stream, media substream, and IP stream. Therefore, the problem that the existing mechanism event detection granularity is too large (only the entire Diameter session) is unnecessary, the event influence range indication is ambiguous (the minimum can only reach the media substream, and the IP flow cannot be indicated) is solved. At the same time, it also solves the problem that the existing event detection reporting mechanism is inflexible (can only be specified in the first request message sent by the AF to the PCRF, and cannot be modified later).
  • the mechanism described in the implementation of the present invention can also be used for signaling path state detection.
  • the signaling-Media-Component-Number can be 0 or a special number (a ratio of 3 ⁇ 4 ports).
  • OxFFFFFFFF the flow-number AVP is specified by the AF (which can be sorted according to the size of the port number, etc.), and the signaling flow can also be described by the Flow-Description AVP, so that the event detection report of the signaling flow is consistent with the event detection report of the media stream. There is no need to establish a new Diameter session for signaling path state detection.

Landscapes

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

Abstract

L'invention concerne un procédé, un système et un dispositif servant à examiner un événement de transport, dans lesquels une fonction d'application (AF) envoie une demande d'examen de l'événement de transport à une fonction de règles de facturation et de contrôle des règles (PCRF), la demande d'examen de l'événement de transport comprend les types de portée d'examen d'un événement et de portée de l'examen d'un événement correspondant à chaque type d'événement dans les types de portée de l'examen d'un événement ; la PCRF examine l'événement avec ce genre de type dans la portée de l'examen d'un événement de chaque type d'événement, et retourne le type d'événement d'un événement examiné et la portée d'influence de l'événement examiné à l'AF.
PCT/CN2008/070762 2007-04-26 2008-04-22 Procédé, système et dispositif servant à examiner un événement de transport WO2008131674A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN200710102006.X 2007-04-26
CN200710102006XA CN101296094B (zh) 2007-04-26 2007-04-26 检测承载事件的方法、***和装置

Publications (1)

Publication Number Publication Date
WO2008131674A1 true WO2008131674A1 (fr) 2008-11-06

Family

ID=39925205

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2008/070762 WO2008131674A1 (fr) 2007-04-26 2008-04-22 Procédé, système et dispositif servant à examiner un événement de transport

Country Status (2)

Country Link
CN (1) CN101296094B (fr)
WO (1) WO2008131674A1 (fr)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101453380B (zh) * 2007-11-28 2011-08-24 华为技术有限公司 应用事件检测的方法、***以及分组流优化功能实体
CA3013516C (fr) * 2016-02-02 2021-06-29 Shanghai Jiao Tong University Mecanisme d'interaction d'informations et procede de transmission de reseau dans un systeme multimedia
CN111726347B (zh) * 2016-02-26 2022-04-15 上海交通大学 一种多媒体***中信息交互机制及网络传输方法
CN107800544B (zh) * 2016-08-30 2022-09-09 中兴通讯股份有限公司 用户位置信息处理方法和装置

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005008496A1 (fr) * 2003-07-11 2005-01-27 Alex Zakonov Algorithme de decouverte dynamique
CN1645806A (zh) * 2004-08-11 2005-07-27 华为技术有限公司 基于分组数据流计费触发事件和重鉴权事件的处理方法
CN1874345A (zh) * 2005-12-26 2006-12-06 华为技术有限公司 媒体网关上报终端统计参数值的方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005008496A1 (fr) * 2003-07-11 2005-01-27 Alex Zakonov Algorithme de decouverte dynamique
CN1645806A (zh) * 2004-08-11 2005-07-27 华为技术有限公司 基于分组数据流计费触发事件和重鉴权事件的处理方法
CN1874345A (zh) * 2005-12-26 2006-12-06 华为技术有限公司 媒体网关上报终端统计参数值的方法

Also Published As

Publication number Publication date
CN101296094A (zh) 2008-10-29
CN101296094B (zh) 2011-02-16

Similar Documents

Publication Publication Date Title
CA2682979C (fr) Procede, systeme et entite de realisation de detection d'evenement
US9503483B2 (en) Method and apparatuses for identifying and reporting quality of service rules applicable to a communication session
EP2339781B1 (fr) Procédé et système pour réaliser la commande de politique et de facturation sur la scène de multiples réseaux de données par paquets (pdn)
JP5298203B2 (ja) Ｎａｔ経由のデータセッションのポリシー及び課金制御のための制御セッションのトークンベースの相関
US7957314B2 (en) System and method for provisioning charging and policy control in a network environment
CN101841797B (zh) 一种终端通过多接入网接入的计费方法和***及上报方法
AU2006344794B2 (en) Loss of signalling bearer transport
RU2513711C2 (ru) Триггер события услуги
US20100186064A1 (en) Method and device for obtaining capabilities of policy and charging enforcement function
US20070281699A1 (en) Inter-access handover with access specific policy control functions
KR101412683B1 (ko) 원격통신 서비스들에 대한 서비스 품질 및/또는 서비스 요금의 제어를 허용하는 방법
US20160269905A1 (en) Handling of Authorization Requests For a Packet-Based Service in a Mobile Network
WO2012058998A1 (fr) Procédé de commande de politique et de facturation soutenant une mobilité de flux ip dans un scénario d'itinérance
WO2011029289A1 (fr) Procédé et système de transmission d'un mode de commande de support dans des scénarios d'itinérance
WO2012103770A1 (fr) Procédé et système de contrôle d'utilisation servant de support à une fonction de détection du trafic
WO2011079773A1 (fr) Procédé, dispositif et système destinés à commander une police de séance d'utilisateur
WO2006015548A1 (fr) Methode de traitement fondee sur un evenement de declenchement de chargement et sur un evenement de reautorisation de flux de donnees de paquets
WO2011063688A1 (fr) Procédé et système de sélection d'entité à fonction de règles de politique et de facturation
WO2011085621A1 (fr) Procédé et système de traitement de service
US20170163819A1 (en) Method, Device, and System for Processing Policy Control
WO2011085614A1 (fr) Procédé de gestion de ressources dans un réseau convergent à service complet et système correspondant
WO2009024056A1 (fr) Procédé, système et dispositif relatifs à une règle de commande de politique et de facturation d'extension
WO2014135185A1 (fr) Contrôle de congestion sur le plan usager
WO2011088702A1 (fr) Procédé et système permettant de contrôler des ressources dans un réseau de convergence multiservice
WO2008131674A1 (fr) Procédé, système et dispositif servant à examiner un événement de transport

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

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

Country of ref document: EP

Kind code of ref document: A1