US20110225280A1 - Methods, systems, and computer readable media for communicating policy information between a policy charging and rules function and a service node - Google Patents

Methods, systems, and computer readable media for communicating policy information between a policy charging and rules function and a service node Download PDF

Info

Publication number
US20110225280A1
US20110225280A1 US13048607 US201113048607A US2011225280A1 US 20110225280 A1 US20110225280 A1 US 20110225280A1 US 13048607 US13048607 US 13048607 US 201113048607 A US201113048607 A US 201113048607A US 2011225280 A1 US2011225280 A1 US 2011225280A1
Authority
US
Grant status
Application
Patent type
Prior art keywords
message
example
id
illustrates
avp
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.)
Abandoned
Application number
US13048607
Inventor
Mark Delsesto
Michael Mercurio
Tarek Abou-Assali
Uri Baniel
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.)
Tekelec Global Inc
Original Assignee
Tekelec Global Inc
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

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATIONS NETWORKS
    • H04W28/00Network traffic or resource management
    • H04W28/16Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
    • H04W28/18Negotiating wireless communication parameters
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L29/00Arrangements, apparatus, circuits or systems, not covered by a single one of groups H04L1/00 - H04L27/00 contains provisionally no documents
    • H04L29/12Arrangements, apparatus, circuits or systems, not covered by a single one of groups H04L1/00 - H04L27/00 contains provisionally no documents characterised by the data terminal contains provisionally no documents
    • H04L29/12009Arrangements for addressing and naming in data networks
    • H04L29/12792Details
    • H04L29/1283Details about address types
    • H04L29/12896Telephone numbers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L29/00Arrangements, apparatus, circuits or systems, not covered by a single one of groups H04L1/00 - H04L27/00 contains provisionally no documents
    • H04L29/12Arrangements, apparatus, circuits or systems, not covered by a single one of groups H04L1/00 - H04L27/00 contains provisionally no documents characterised by the data terminal contains provisionally no documents
    • H04L29/12009Arrangements for addressing and naming in data networks
    • H04L29/12792Details
    • H04L29/1283Details about address types
    • H04L29/12905International Mobile Subscriber Identity [IMSI] numbers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements or network protocols for addressing or naming
    • H04L61/10Mapping of addresses of different types; Address resolution
    • H04L61/103Mapping of addresses of different types; Address resolution across network layers, e.g. resolution of network layer into physical layer addresses or address resolution protocol [ARP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements or network protocols for addressing or naming
    • H04L61/10Mapping of addresses of different types; Address resolution
    • H04L61/106Mapping of addresses of different types; Address resolution across networks, e.g. mapping telephone numbers to data network addresses
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements or network protocols for addressing or naming
    • H04L61/15Directories; Name-to-address mapping
    • H04L61/1588Directories; Name-to-address mapping containing mobile subscriber information, e.g. home subscriber server [HSS]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M15/00Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M15/00Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/66Policy and charging system
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATIONS NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/24Accounting or billing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements or network protocols for addressing or naming
    • H04L61/60Details
    • H04L61/6018Address types
    • H04L61/605Telephone numbers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements or network protocols for addressing or naming
    • H04L61/60Details
    • H04L61/6018Address types
    • H04L61/6054International mobile subscriber identity [IMSI] numbers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATIONS NETWORKS
    • H04W24/00Supervisory, monitoring or testing arrangements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATIONS NETWORKS
    • H04W8/00Network data management
    • H04W8/26Network addressing or numbering for mobility support

Abstract

According to one aspect, the subject matter described herein includes a method for communicating policy information. The method includes steps occurring at a policy charging and rules function (PCRF) node. The method also includes receiving, from a service node, a message requesting a policy rule, wherein the message includes an Internet protocol (IP) address associated with a subscriber. The method further includes determining a network access identifier (NAI) for the subscriber based on the IP address. The method further includes selecting a policy rule for the subscriber based on the NAI. The method further includes communicating the policy rule to the service node.

Description

    PRIORITY CLAIM
  • This application claims the benefit of U.S. Provisional Patent Application Ser. No. 61/313,953, filed Mar. 15, 2010; U.S. Provisional Patent Application Ser. No. 61/315,130, filed Mar. 18, 2010; and U.S. Provisional Patent Application Ser. No. 61/322,533, filed Apr. 9, 2010; the disclosure of which are incorporated herein by reference in their entirety.
  • TECHNICAL FIELD
  • The subject matter described herein relates to communicating policy information between a policy charging and rules function and a service node. More specifically, the subject matter relates to methods, systems, and computer readable media for communicating policy information between a policy charging and rules function and a service node.
  • BACKGROUND
  • A policy charging and rules function (PCRF) node may be utilized by multimedia networks to determine policy rules in real-time. Utilization of a PCRF may aid a network operator in making real-time, subscriber specific, policy decisions that may be utilized to provide varying levels of quality of service (QoS).
  • Telecommunications networks may include various service nodes for performing a variety of services. Service nodes may include functionality for deep packet inspection (DPI), content-filtering, and/or web-optimization. DPI is the use of a packet's non-header information by a network entity that is not an endpoint for that packet. DPI is employed by network operators for a wide variety of uses, e.g., anti-virus, spam filtering, intrusion detection, and gathering statistical information. Content-filtering is the blocking of specified content based on analysis of the content itself rather than other criteria such as its source. Web-optimization is provided to enhance a user's experience and may involve refining and/or altering content to better suit the hardware and/or software utilized by a particular user.
  • Based on operator policy, a PCRF node may need to communicate policy information between itself and a service node.
  • Accordingly, a need exists for methods, systems, and computer readable media for communicating policy information between a policy charging and rules function and a service node.
  • SUMMARY
  • According to one aspect, the subject matter described herein includes a method for communicating policy information. The method includes steps occurring at a policy charging and rules function (PCRF) node. The method also includes receiving, from a service node, a message requesting a policy rule, wherein the message includes an Internet protocol (IP) address associated with a subscriber. The method further includes determining a network access identifier (NAI) for the subscriber based on the IP address. The method further includes selecting a policy rule for the subscriber based on the NAI. The method further includes communicating the policy rule to the service node.
  • According to another aspect, the subject matter described herein includes a system for communicating policy information. The system includes a PCRF node. The PCRF node includes a communication interface. The PCRF node further includes a communication module. The communication module is configured to utilize the communication interface to receive, from a service node, a message requesting a policy rule, wherein the message includes an IP address associated with a subscriber. The communication module is further configured to determine a NAI for the subscriber based on the IP address. The communication module is further configured to select a policy rule for the subscriber based on the NAI. The communication module is further configured to utilize the communication interface to communicate the policy rule to the service node.
  • As used herein, the term “node” refers to a physical computing platform including one or more processors and memory.
  • The subject matter described herein can be implemented in software in combination with hardware and/or firmware. For example, the subject matter described herein may be implemented in software executed by one or more processors. In one exemplary implementation, the subject matter described herein may be implemented using a non-transitory computer readable medium having stored thereon computer executable instructions that when executed by the processor of a computer control the computer to perform steps. Exemplary computer readable media suitable for implementing the subject matter described herein include non-transitory computer readable media, such as disk memory devices, chip memory devices, programmable logic devices, and application specific integrated circuits. In addition, a computer readable medium that implements the subject matter described herein may be located on a single device or computing platform or may be distributed across multiple devices or computing platforms.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • The subject matter described herein will now be explained with reference to the accompanying drawings of which:
  • FIG. 1 is a network diagram illustrating an exemplary network environment for communicating policy information according to an embodiment of the subject matter described herein;
  • FIG. 2 is a message flow diagram illustrating the communication of policy information in response to an external trigger according to an embodiment of the subject matter described herein;
  • FIG. 3 is a message flow diagram illustrating an exemplary PCRF initiated termination of a session for communicating policy information according to an embodiment of the subject matter described herein;
  • FIG. 4 is a message flow diagram illustrating an exemplary externally initiated termination of a session for communicating policy information according to an embodiment of the subject matter described herein;
  • FIG. 5 is a message flow diagram illustrating an exemplary policy rule push for communicating policy information according to an embodiment of the subject matter described herein;
  • FIG. 6 is a message flow diagram illustrating an exemplary audit procedure for communicating policy information according to an embodiment of the subject matter described herein;
  • FIG. 7 is a message flow diagram illustrating exemplary event subscription and notification for communicating policy information according to an embodiment of the subject matter described herein;
  • FIG. 8 is a flow chart illustrating an exemplary process for communicating policy information according to an embodiment of the subject matter described herein; and
  • FIG. 9 is a block diagram of an exemplary PCRF node for communicating policy information according to an embodiment of the subject matter described herein.
  • DETAILED DESCRIPTION
  • Methods, systems, and computer readable media for communicating policy information are provided. FIG. 1 is a network diagram illustrating an exemplary network environment for communicating policy information according to an embodiment of the subject matter described herein. Referring to FIG. 1, network environment 100 may include access network 102. Access network 102 may include nodes, functions, devices, and/or components for providing user equipment (UE) 104 access to services, functions, or devices in one or more networks. In one embodiment, access network 102 may be a radio access network (RAN). For example, access network 102 may be a global system for mobile communications (GSM) RAN (GRAN), a general packet radio service (GPRS) access network, a universal mobile telecommunications system (UMTS) RAN (UTRAN), an evolved UTRAN (eUTRAN), an Internet protocol (IP) connectivity access network (IPCAN), a code division multiple access (CDMA) network, an evolution-data optimized (EV-DO) network, a wideband CDMA (WCDMA) network, a high speed packet access (HPSA) network, an evolved HPSA (EHPSA+) network, or a long term evolution (LTE) access network. Access network 102 may include one or more transceiver nodes 106 for communicating with UE 104. UE 104 may include a computer, a pager, a mobile phone, a smartphone, a wireless modem, or other devices through which a subscriber accesses network services.
  • Network environment 100 may further include a carrier network 108. Carrier network 108 may be utilized by UE 104 to access Internet 110. Carrier network 108 may include a bearer binding and event reporting function (BBERF) node 112. BBERF node 112 may be, for example, a service gateway (SGW) or a serving general packet radio service (GPRS) support node (SGSN). Carrier network 108 may further include a PCRF node 114. PCRF node 114 is a centralized node that can act as a policy decision point for carrier network 108. PCRF node 114 may take operator defined service policies, subscription information pertaining to a user, and other data into account to build policy decisions. Policy decisions may be formulated as policy control and charging (PCC) rules. PCC rules may contain information about user plane traffic expressed as a packet filter. A packet filter may take the form of an IP five-tuple specifying: (1) source IP address(es), (2) destination IP address(es), (3) source port number(s), (4) destination port number(s), and (5) application protocol(s) (e.g., transmission control protocol (TCP), user datagram protocol (UDP)). All IP packets matching a packet filter of a PCC rule may be designated an SDF.
  • Flow-based charging models may introduce the ability to charge for SDFs identified by service data flow filters according to specified charging rules. Charging rules may contain information that allows the filtering of traffic to identify packets belonging to a particular SDF (e.g., IP multimedia subsystem (IMS), file transfer protocol (FTP), browsing) and allow an operator to define how a particular SDF is to be charged (e.g., different media streams within a single packet data protocol (PDP) context.) Charging rules may be requested by a policy and charging enforcement function (PCEF) node (e.g., by a packet data network (PDN) gateway in an evolved packet system (EPS)), at bearer establishment, upon a specified trigger event, and/or upon bearer termination. Such a request may be made using a Gx reference point towards a PCRF.
  • Carrier network 108 may also include PCEF node 116. PCEF node 116 may serve as a policy enforcement point and may be placed in line between access network 102 and PCRF node 114. PCEF node 116 may be, for example, a gateway GPRS support node (GGSN) or a PDN gateway. As an enforcement point, PCEF node 116 may request and receive policy rules from PCRF node 114. Policy rules may take the form of, for example, Gx rules contained in credit control messages.
  • Carrier network 108 may also include subscriber data management (SDM) node 118. SDM node 118 may contain a comprehensive subscriber database, including information pertaining to subscribers' locations and Internet protocol information. SDM node 118 may be, for example, a home subscriber server (HSS), a subscription profile repository (SPR), or a user profile serving function (UPSF).
  • Carrier network 108 may further include service node 120. Service node 120 may include functionality for DPI, content-filtering, and/or web-optimization. DPI is the use of a packet's non-header information by a network entity that is not an endpoint for that packet. For example, service node 120 may include functionality enabling it to examine packets originating in Internet 110 and destined for UE 104. Content-filtering is the blocking of specified content based on analysis of the content itself rather than other criteria such as its source. For example, service node 120 may include functionality enabling it to analyze the content of packets originating in Internet 110 and destined for UE 104. Based on such content-analysis, service node 120 may filter or prevent the content from reaching UE 104. Web-optimization is provided to enhance a user's experience and may involve refining and/or altering content to better suit the hardware and/or software utilized by a particular user. For example, service node 120 may include functionality enabling it to optimize content originating in Internet 110 and destined for UE 104 based on, for example, the type of device UE 104 is. For example, service node 120 may detect video streaming from a source located in Internet 110 and destined for UE 104. In response, service node 120 may, for example, resize the video for optimal display on UE 104. A service node may or may not support the full blown Gx protocol as specified in 3GPP 29.212. For example, service node 120 may not include support for the full blown Gx protocol. In accordance with embodiments of the subject matter described herein, a service node that does not include support for the full blown Gx protocol may communicate with a PCRF node, enabling it to subscribe to SDF event notifications and install policy rules.
  • FIG. 2 is a message flow diagram illustrating the communication of policy information in response to an external trigger according to an embodiment of the subject matter described herein. Referring to FIG. 2, at step 1, UE 104 may initiate establishment of an IP CAN session with PCEF node 116 for the purpose of communicating with a host in Internet 110. At step 2, PCEF node 116 may send a credit-control-request initial (CCR-I) message to PCRF node 114. The CCR-I message may include a user ID and IP address associated with UE 104. At step 3, PCRF node 114 may send a credit-control-answer initial (CCA-I) message to PCEF node 116. The CCA-I message may include a charging rule for PCEF node 116 to implement with respect to UE 104's IP CAN session. PCEF node 116 may support an implementation of the full blown Gx protocol and thus the CCR-I/CCA-I exchange, between PCEF node 116 and PCRF node 114, may utilize the Gx protocol.
  • User data plane 200, carrying traffic associated with UE 104's IP CAN session, may traverse service node 120. PCRF node 114 may desire to communicate with service node 120 in order to subscribe to SDF event notifications and/or install policy rule(s). Service node 120 may not implement the full blown Gx protocol and thus utilization of the Gx protocol may not be possible. In accordance with embodiments of the subject matter described herein, PCRF node 114 and service node 120 may utilize a subset of the Gx application/protocol that does not include all of the parameter/attribute value pairs (AVPs) designated as mandatory in 3GPP 29.212 to communicate (hereinafter “Gx-Lite”). At step 4, service node 120 may receive an external trigger. For example, commonly owned, co-pending U.S. patent application entitled “Methods, Systems, and Computer Readable Media for Triggering a Service Node to Initiate a Session with a Policy Charging and Rules Function,” filed on Mar. 15, 2011, Attorney Docket No. 1322-405-22-2, (Serial No. not yet assigned), herein incorporated by reference in its entirety, discloses the creation of such an external trigger by a PCRF node. The external trigger may include an IP address associated with UE 104.
  • At step 5, in response to the external trigger, service node 120 may send a message to PCRF node 114 which includes the IP address. The message may be sent, for example, via a Gx-Lite CCR-I Diameter message.
  • Table 1 illustrates an exemplary Gx-Lite CCR-I message. The message may include the version field for specifying version information. For example, Line 1 illustrates the version field specifying version 1.0. The message may further include the message length field for specifying the message's length, including any header information. For example, Line 2 illustrates the message length field specifying the symbolic message length “XXX” to denote the length of the message. The message may further include the command flags field. For example, Line 3 illustrates the command flags field with the r-bit set to “REQ” to indicate that the message is a request and the p-bit set to “PXY” to indicate that the message is proxiable. The message may further include the command codes field. For example, Line 4 illustrates the command codes field with the credit-control command code 272, corresponding with a credit-control-request. The message may further include the application ID field to identify to which application the message is applicable. For example, Line 5 illustrates the application ID field with a four octet vendor specific application ID. The message may further include a hop-by-hop ID field to aid in matching requests and replies. For example, Line 6 illustrates the hop-by-hop ID field specifying a symbolic hop-by-hop ID “YYYY” to denote a unique hop-by-hop ID. The message may further include an end-to-end ID field for detecting duplicate messages. For example, Line 7 illustrates an end-to-end ID field specifying a symbolic end-to-end ID “ZZZZZZZZ” to denote a unique end-to-end ID. The message may further include the AVPs field for indicating the beginning of AVPs. For example, Line 8 illustrates the AVPs field.
  • AVPs may be used to encapsulate information relevant to the message. The message may include a session ID AVP. For example, Line 9 illustrates a session ID AVP corresponding with the global identifier of the session. The message may further include an authentication application ID AVP or an accounting application ID AVP. For example, Line 10 illustrates an authentication ID AVP identifying the authentication and authorization portion of the application. The message may further include the origin host AVP and convey the fully qualified domain name of the node that generated the request. For example, Line 11 illustrates an origin host AVP corresponding with service node 120. The message may further include the origin realm AVP indicating the realm of the node that generated the request. For example, Line 12 illustrates an origin realm AVP indicating the realm of service node 120. The message may further include the destination realm AVP indicating the realm of the node the message is destined for. For example, Line 13 illustrates a destination realm AVP indicating the realm of PCRF node 114. The message may further include the CC-request-type AVP indicating the type of credit control request. For example, Line 14 illustrates the CC-request-type AVP corresponding with an initial request. The message may further include the CC-request-number AVP indicating the credit control request number. For example, Line 15 illustrates the CC-request-number AVP “0” denoting a first request.
  • The message may include an indication of the beginning of subscription information. For example, Line 16 illustrates an indication that subscription information is included. In some embodiments, PCRF node 114 may support receiving multiple subscription IDs in a single message. The message may further include the subscription-ID-type AVP for specifying the format of the subscription ID information. For example, Line 17 illustrates the subscription-ID-type AVP indicating that the subscription ID information is an end user IMSI. The message may further include the subscription-ID-data AVP for providing the subscription ID information itself. For example, Line 18 illustrates the subscription-ID-data AVP specifying the symbolic value “IMSI” to denote an IMSI associated with UE 104. The message may further include the supported-features AVP for informing the destination host of the features supported by the originating host. For example, Line 19 illustrates the supported-features AVP for informing PCRF node 114 of the features supported by service node 120. The message may further include the vendor-ID AVP for identifying the vendor of the originating host. For example, Line 20 illustrates the vendor-ID AVP specifying the vendor “Camiant” of service node 120. The message may further include the feature-list-ID AVP identifying the appropriate feature list from multiple possible supported feature lists. For example, Line 21 illustrates the feature-list-ID AVP indicating symbolic feature list “1” of multiple possible supported feature lists. The message may further include the feature-list AVP identifying the supported features. For example, Line 22 illustrates the feature-list AVP specifying features supported by service node 120 (e.g., “Gx-Lite”). The message may further include the framed-IP-address AVP indicating an address to be configured for the user. The IP address specified may be, for example, a version 4 or version 6 address. For example, Line 23 illustrates the framed-IP-address AVP specifying an IP address associated with UE 104.
  • TABLE 1
    01: Version = 1
    02: Message Length = XXX
    03: Command Flags = REQ, PXY
    04: Command Code = Credit-control (272)
    05: Application Id = 16777238
    06: Hop-By-Hop-Id = YYYY
    07: End-To-End-Id = ZZZZZZZZ
    08: AVPs
    09: Session-Id = NON-3GPP PCEF.Op.com;
    1876543210;102
    10: Auth-Application-Id = 16777238
    11: Origin-Host = NON-3GPP PCEF.Op.com
    12: Origin-Realm = Op.com
    13: Destination-Realm = Op.com
    14: CC-Reguest-Type = INITIAL_REQUEST (1)
    15: CC-Request-Number = 0
    16: [Subscription-Id] // optional
    17: Subscription-Id-Type = END_USER_IMSI (1)
    18: Subscription-Id-Data = <IMSI>
    19: Supported-Features
    20: Vendor-Id = Camiant (21274)
    21: Feature-List-ID = TBD [e.g., 1]
    22: Feature-List = TBD [e.g., Gx-Light]
    23: Framed-IP-Address = 192.168.2.11
  • Utilizing the IP address included in the CCR-I message, PCRF node 114 may determine a network access identifier (NAI) for a subscriber associated with UE 104. The NAI may be an international mobile station identifier (IMSI), a mobile subscriber integrated services digital network number (MSISDN), a uniform resource identifier (URI), an IMS public identity, or an IMS private identity. PCRF node 114 may query SDM node 118 in order to determine a NAI for the subscriber based on the IP address. In one embodiment, PCRF node 114 may utilize information derived from exchanges with PCEF node 116 to determine the NAI. For example, commonly owned, co-pending U.S. patent application entitled “Methods, Systems, and Computer Readable Media for Performing PCRF-Based User Information Pass Through,” filed on Mar. 15, 2011, Attorney Docket No. 1322-405-20-2, (Serial No. not yet assigned), herein incorporated by reference in its entirety, discloses an approach for providing a PCRF with user ID and/or IP address information.
  • Having determined a NAI for the subscriber associated with UE 104, PCRF node 114 may utilize the NAI to select an appropriate policy rule. The policy rule selected may authorize or de-authorize a content-filtering service and/or a web-optimization service for the subscriber associated with UE 104. The policy rule selected may specify user data plane content that is to be blocked for the subscriber associated with UE 104. For example, the policy rule may specify to block user data plane content associated with a uniform resource location (URL), a web page, a text string, an image, and/or a video. At step 6, PCRF node 114 may communicate the selected policy rule to service node 120 via a message. The message may be sent, for example, via a Gx-Lite CCA-I Diameter message.
  • Table 2 illustrates an exemplary Gx-Lite CCA-I message. The message may include the version field for specifying version information. For example, Line 1 illustrates the version field specifying version 1.0. The message may further include the message length field for specifying the message's length, including any header information. For example, Line 2 illustrates the message length field specifying the symbolic message length “XXX” to denote the length of the message illustrated. The message may further include the command flags field. For example, Line 3 illustrates the command flags field with the p-bit set to “PXY” to indicate that the message is proxiable. The message may further include the command codes field. For example, Line 4 illustrates the command codes field with the credit-control command code 272, corresponding with a credit-control-request. The message may further include the application ID field to identify to which application the message is applicable. For example, Line 5 illustrates the application ID field with a four octet vendor specific application ID. The message may further include a hop-by-hop ID field to aid in matching requests and replies. For example, Line 6 illustrates the hop-by-hop ID field specifying a symbolic hop-by-hop ID “YYYY” to denote a unique hop-by-hop ID. The message may further include an end-to-end ID field for detecting duplicate messages. For example, Line 7 illustrates an end-to-end ID field specifying a symbolic end-to-end ID “ZZZZZZZZ” to denote a unique end-to-end ID. The message may further include the AVPs field for indicating the beginning of AVPs. For example, Line 8 illustrates the AVPs field.
  • AVPs may be used to encapsulate information relevant to the message. The message may include a session ID AVP. For example, Line 9 illustrates a session ID AVP corresponding with the global identifier of the session. The message may further include a result code AVP for reporting potential errors. For example, Line 10 illustrates the result code AVP “2001” indicating that the request was successfully completed. The message may further include the origin host AVP and convey the fully qualified domain name of the node that generated the answer. For example, Line 11 illustrates an origin host AVP corresponding with PCRF node 114. The message may further include the origin realm AVP indicating the realm of the node that generated the answer. For example, Line 12 illustrates an origin realm AVP indicating the realm of PCRF node 114. The message may further include an authentication application ID AVP or an accounting application ID AVP. For example, Line 13 illustrates an authentication ID AVP identifying the authentication and authorization portion of the application. The message may further include the CC-request-type AVP indicating the type of credit control request. For example, Line 14 illustrates the CC-request-type AVP corresponding with an initial request. The message may further include the CC-request-number AVP indicating the credit control request number. For example, Line 15 illustrates the CC-request-number AVP “0” denoting a first request.
  • The message may further include the supported-features AVP for informing the destination host of the features supported by the originating host. For example, Line 16 illustrates the supported-features AVP for informing service node 120 of the features supported by PCRF node 114. The message may further include the vendor-ID AVP for identifying the vendor of the originating host. For example, Line 17 illustrates the vendor-ID AVP specifying the vendor “Camiant” of PCRF node 114. The message may further include the feature-list-ID AVP identifying the appropriate feature list from multiple possible supported feature lists. For example, Line 18 illustrates the feature-list-ID AVP indicating symbolic feature list “1” of multiple possible supported feature lists. The message may further include the feature-list AVP identifying the supported features. For example, Line 19 illustrates the feature-list AVP specifying features supported by PCRF node 114 (e.g., “Gx-Lite”). The message may further include the charging rule install AVP for specifying charging rules to be installed. For example, Line 20 illustrates the charging rule install AVP. The message may further include the charging rule name AVP and identify charging rules to install. Charging rules may be predefined or dynamic. For example, Lines 21 and 22 both illustrate the charging rule name AVP respectively specifying the predefined “Default_Traffic” charging rule and the predefined “P2P_Traffic” charging rule for installation at service node 120 with respect to UE 104's IP CAN session.
  • TABLE 2
    01:  Version = 1
    02:  Message Length = XXX
    03:  Command Flags = PXY
    04:  Command Code = Credit-control (272)
    05:  Application Id = 16777238
    06:  Hop-By-Hop-Id = YYYY
    07:  End-To-End-Id = ZZZZZZZZ
    08:  AVPs
    09:    Session-Id = NON-3GPP PCEF.Op.com;
    1876543210;102
    10:    Result-Code = DIAMETER_SUCCESS (2001)
    11:    Origin-Host = pcrf1.Op.com
    12:    Origin-Realm = Op.com
    13:    Auth-Application-Id = 16777238
    14:    CC-Request-Type = INITIAL_REQUEST(1)
    15:    CC-Request-Number = 0
    16:    Supported Features
    17:      Vendor-Id = Camiant (21274)
    18:      Feature-List-ID = TBD [e.g., 1]
    19:      Feature-List = TBD [e.g., Gx-Light]
    20:    Charging-Rule-Install
    21:      Charging-Rule-Name = Default-Traffic
    22:      Charging-Rule-Name = P2P_Traffic
  • Upon receiving the message from PCRF node 114, service node 120 may implement the policy rule(s) with respect to UE 104's IP CAN session.
  • FIG. 3 is a message flow diagram illustrating an exemplary PCRF initiated termination of a session for communicating policy information according to an embodiment of the subject matter described herein. Referring to FIG. 3, an IP CAN session may exist between UE 104 and PCEF node 116 enabling UE 104 to communicate with a host in Internet 110. User data plane 300, carrying traffic associated with UE 104's IP CAN session, may traverse service node 120. At step 1, UE 104 may initiate termination of the IP CAN session with PCEF node 116. At step 2, PCEF node 116 may send a credit-control-request termination (CCR-T) message to PCRF node 114. The CCR-T message may include a session ID identifying a session between PCEF node 116 and PCRF node 114 associated with UE 104's IP CAN session. At step 3, PCRF node 114 may acknowledge PCEF node 116's request by sending, to PCEF node 116, a credit-control-answer termination (CCA-T) message. The CCA-T message may include the session ID identifying the session between PCEF node 116 and PCRF node 114 associated with UE 104's IP CAN session. PCEF node 116 may support an implementation of the full blown Gx protocol and thus the CCR-T/CCA-T exchange, between PCEF node 116 and PCRF node 114, may utilize the Gx protocol.
  • PCRF node 114 may desire to terminate an existing session with service node 120 associated with UE 104's IP CAN session. Service node 120 may not implement the full blown Gx protocol and thus utilization of the Gx protocol may not be possible. In accordance with embodiments of the subject matter described herein, PCRF node 114 may terminate the existing session with service node 120. For example, at step 4, PCRF node 114 may send a re-authorization-request (RAR) message to service node 120. The RAR message may include a session ID identifying a session between PCRF node 114 and service node 120 associated with UE 104's IP CAN session and may further include a reason for terminating the session. The message may be sent, for example, via a Gx-Lite RAR Diameter message.
  • Table 3 illustrates an exemplary Gx-Lite RAR message. The message may include the version field for specifying version information. For example, Line 1 illustrates the version field specifying version 1.0. The message may further include the message length field for specifying the message's length, including any header information. For example, Line 2 illustrates the message length field specifying the symbolic message length “XXX” to denote the length of the message. The message may further include the command flags field. For example, Line 3 illustrates the command flags field with the r-bit set to “REQ” to indicate that the message is a request and the p-bit set to “PXY” to indicate that the message is proxiable. The message may further include the command codes field. For example, Line 4 illustrates the command codes field with the re-authorization command code 258, corresponding with a re-authorization-request. The message may further include the application ID field to identify to which application the message is applicable. For example, Line 5 illustrates the application ID field with a four octet vendor specific application ID. The message may further include a hop-by-hop ID field to aid in matching requests and replies. For example, Line 6 illustrates the hop-by-hop ID field specifying a symbolic hop-by-hop ID “YYYY” to denote a unique hop-by-hop ID. The message may further include an end-to-end ID field for detecting duplicate messages. For example, Line 7 illustrates an end-to-end ID field specifying a symbolic end-to-end ID “ZZZZZZZZ” to denote a unique end-to-end ID. The message may further include the AVPs field for indicating the beginning of AVPs. For example, Line 8 illustrates the AVPs field.
  • AVPs may be used to encapsulate information relevant to the message. The message may include a session ID AVP. For example, Line 9 illustrates a session ID AVP corresponding with the global identifier of the session. The message may further include an authentication application ID AVP or an accounting application ID AVP. For example, Line 10 illustrates an authentication ID AVP identifying the authentication and authorization portion of the application. The message may further include the origin host AVP and convey the fully qualified domain name of the node that generated the request. For example, Line 11 illustrates an origin host AVP corresponding with PCRF node 114. The message may further include the origin realm AVP indicating the realm of the node that generated the request. For example, Line 12 illustrates an origin realm AVP indicating the realm of PCRF node 114. The message may further include the destination host AVP and convey the fully qualified domain name of the node the message is destined for. For example, Line 13 illustrates a destination host AVP corresponding with service node 120. The message may further include the destination realm AVP indicating the realm of the node the message is destined for. For example, Line 14 illustrates a destination realm AVP indicating the realm of service node 120. The message may further include the re-authorization request type AVP to inform the client of the action expected upon expiration of the authorization. For example, Line 15 illustrates the re-authorization request type AVP set to “AUTHORIZE_ONLY” to indicate the expiration of the authorization lifetime. The message may further include the session release cause AVP for indicating a reason for the termination. For example, Line 16 illustrates the session release cause AVP indicating an unspecified reason for the termination.
  • TABLE 3
    01:  Version = 1
    02:  Message Length = XXX
    03:  Command Flags = REQ, PXY
    04:  Command Code = Re-Auth (258)
    05:  Application Id = 16777238
    06:  Hop-By-Hop-Id = YYYY
    07:  End-To-End-Id = ZZZZZZZZ
    08:  AVPs
    09:    Session-Id = NON-3GPP PCEF.Op.com;
    1876543210;102
    10:    Auth-Application-Id = 16777238
    11:    Origin-Host = pcrf1.Op.com
    12:    Origin-Realm = Op.com
    13:    Destination-Host = non-3GPP PCEF.Op.com
    14:    Destination-Realm = Op.com
    15:    Re-Auth-Request-Type = AUTHORIZE_ONLY
    16:    Session-Release-Cause = UNSPECIFIED_REASON
  • At step 5, service node 120 may acknowledge PCRF node 114's RAR message by sending a re-authorization-answer (RAA) message to PCRF node 114. The message may be sent, for example, via a Gx-Lite RAA Diameter message.
  • Table 4 illustrates an exemplary Gx-Lite RAA message. The message may include the version field for specifying version information. For example, Line 1 illustrates the version field specifying version 1.0. The message may further include the message length field for specifying the message's length, including any header information. For example, Line 2 illustrates the message length field specifying the symbolic message length “XXX” to denote the length of the message. The message may further include the command flags field. For example, Line 3 illustrates the command flags field with the p-bit set to “PXY” to indicate that the message is proxiable. The message may further include the command codes field. For example, Line 4 illustrates the command codes field with the re-authorization command code 258, corresponding with a re-authorization-request. The message may further include the application ID field to identify to which application the message is applicable. For example, Line 5 illustrates the application ID field with a four octet vendor specific application ID. The message may further include a hop-by-hop ID field to aid in matching requests and replies. For example, Line 6 illustrates the hop-by-hop ID field specifying a symbolic hop-by-hop ID “YYYY” to denote a unique hop-by-hop ID. The message may further include an end-to-end ID field for detecting duplicate messages. For example, Line 7 illustrates an end-to-end ID field specifying a symbolic end-to-end ID “ZZZZZZZZ” to denote a unique end-to-end ID. The message may further include the AVPs field for indicating the beginning of AVPs. For example, Line 8 illustrates the AVPs field.
  • AVPs may be used to encapsulate information relevant to the message. The message may include a session ID AVP. For example, Line 9 illustrates a session ID AVP corresponding with the global identifier of the session. The message may further include an authentication application ID AVP or an accounting application ID AVP. For example, Line 10 illustrates an authentication ID AVP identifying the authentication and authorization portion of the application. The message may further include the origin host AVP and convey the fully qualified domain name of the node that generated the answer. For example, Line 11 illustrates an origin host AVP corresponding with service node 120. The message may further include the origin realm AVP indicating the realm of the node that generated the answer. For example, Line 12 illustrates an origin realm AVP indicating the realm of service node 120. The message may further include a result code AVP for reporting potential errors. For example, Line 13 illustrates the result code AVP “2001” indicating that the request was successfully completed.
  • TABLE 4
    01:  Version = 1
    02:  Message Length = XXX
    03:  Command Flags = PXY
    04:  Command Code = Re-Auth (258)
    05:  Application Id = 16777238
    06:  Hop-By-Hop-Id = YYYY
    07:  End-To-End-Id = ZZZZZZZZ
    08:  AVPs
    09:    Session-Id = NON-3GPP PCEF.Op.com;
    1876543210;102
    10:    Auth-Application-Id = 16777238
    11:    Origin-Host = non-3GPP PCEF.Op.com
    12:    Origin-Realm = Op.com
    13:    Result-Code = DIAMETER_SUCCESS (2001)
  • At step 6, service node 120 may send a CCR-T message to PCRF node 114. The message may be sent, for example, via a Gx-Lite CCR-T Diameter message.
  • Table 5 illustrates an exemplary Gx-Lite CCR-T message. The message may include the version field for specifying version information. For example, Line 1 illustrates the version field specifying version 1.0. The message may further include the message length field for specifying the message's length, including any header information. For example, Line 2 illustrates the message length field specifying the symbolic message length “XXX” to denote the length of the message. The message may further include the command flags field. For example, Line 3 illustrates the command flags field with the r-bit set to “REQ” to indicate that the message is a request and the p-bit set to “PXY” to indicate that the message is proxiable. The message may further include the command codes field. For example, Line 4 illustrates the command codes field with the credit-control command code 272, corresponding with a credit-control-request. The message may further include the application ID field to identify to which application the message is applicable. For example, Line 5 illustrates the application ID field with a four octet vendor specific application ID. The message may further include a hop-by-hop ID field to aid in matching requests and replies. For example, Line 6 illustrates the hop-by-hop ID field specifying a symbolic hop-by-hop ID “YYYY” to denote a unique hop-by-hop ID. The message may further include an end-to-end ID field for detecting duplicate messages. For example, Line 7 illustrates an end-to-end ID field specifying a symbolic end-to-end ID “ZZZZZZZZ” to denote a unique end-to-end ID. The message may further include the AVPs field for indicating the beginning of AVPs. For example, Line 8 illustrates the AVPs field.
  • AVPs may be used to encapsulate information relevant to the message. The message may include a session ID AVP. For example, Line 9 illustrates a session ID AVP corresponding with the global identifier of the session. The message may further include an authentication application ID AVP or an accounting application ID AVP. For example, Line 10 illustrates an authentication ID AVP identifying the authentication and authorization portion of the application. The message may further include the origin host AVP and convey the fully qualified domain name of the node that generated the request. For example, Line 11 illustrates an origin host AVP corresponding with service node 120. The message may further include the origin realm AVP indicating the realm of the node that generated the request. For example, Line 12 illustrates an origin realm AVP indicating the realm of service node 120. The message may further include the destination realm AVP indicating the realm of the node the message is destined for. For example, Line 13 illustrates a destination realm AVP indicating the realm of PCRF node 114. The message may further include the destination host AVP and convey the fully qualified domain name of the node the message is destined for. For example, Line 14 illustrates a destination host AVP corresponding with PCRF node 114. The message may further include the CC-request-type AVP indicating the type of credit control request. For example, Line 15 illustrates the CC-request-type AVP corresponding with a termination request. The message may further include the CC-request-number AVP indicating the credit control request number. For example, Line 16 illustrates the CC-request-number AVP “1” denoting a first request. The message may further include the termination cause AVP containing information about the termination reason. For example, Line 17 illustrates a termination cause AVP specifying the termination reason as a Diameter logout.
  • TABLE 5
    01:  Version = 1
    02:  Message Length = XXX
    03:  Command Flags = REQ, PXY
    04:  Command Code = Credit-control (272)
    05:  Application Id = 16777238
    06:  Hop-By-Hop-Id = YYYY
    07:  End-To-End-Id = ZZZZZZZZ
    08:  AVPs
    09:    Session-Id = NON-3GPP PCEF.Op.com;
    1876543210;102
    10:    Auth-Application-Id = 16777238
    11:    Origin-Host = NON-3GPP PCEF.Op.com
    12:    Origin-Realm = Op.com
    13:    Destination-Realm = Op.com
    14:    Destination-Host = pcrf1.Op.com
    15:    CC-Request-Type = TERMINATION_REQUEST (3)
    16:    CC-Request-Number = 1
    17:    Termination-Cause = DIAMETER_LOGOUT (1)
  • At step 7, PCRF node 114 may acknowledge service node 120's CCR-T message by sending a CCA-T message to service node 120. The message may be sent, for example, via a Gx-Lite CCA-T Diameter message.
  • Table 6 illustrates an exemplary Gx-Lite CCA-T message. The message may include the version field for specifying version information. For example, Line 1 illustrates the version field specifying version 1.0. The message may further include the message length field for specifying the message's length, including any header information. For example, Line 2 illustrates the message length field specifying the symbolic message length “XXX” to denote the length of the message. The message may further include the command flags field. For example, Line 3 illustrates the command flags field with the p-bit set to “PXY” to indicate that the message is proxiable. The message may further include the command codes field. For example, Line 4 illustrates the command codes field with the credit-control command code 272, corresponding with a credit-control-request. The message may further include the application ID field to identify to which application the message is applicable. For example, Line 5 illustrates the application ID field with a four octet vendor specific application ID. The message may further include a hop-by-hop ID field to aid in matching requests and replies. For example, Line 6 illustrates the hop-by-hop ID field specifying a symbolic hop-by-hop ID “YYYY” to denote a unique hop-by-hop ID. The message may further include an end-to-end ID field for detecting duplicate messages. For example, Line 7 illustrates an end-to-end ID field specifying a symbolic end-to-end ID “ZZZZZZZZ” to denote a unique end-to-end ID. The message may further include the AVPs field for indicating the beginning of AVPs. For example, Line 8 illustrates the AVPs field.
  • AVPs may be used to encapsulate information relevant to the message. The message may include a session ID AVP. For example, Line 9 illustrates a session ID AVP corresponding with the global identifier of the session. The message may further include an authentication application ID AVP or an accounting application ID AVP. For example, Line 10 illustrates an authentication ID AVP identifying the authentication and authorization portion of the application. The message may further include the origin host AVP and convey the fully qualified domain name of the node that generated the answer. For example, Line 11 illustrates an origin host AVP corresponding with PCRF node 114. The message may further include the origin realm AVP indicating the realm of the node that generated the answer. For example, Line 12 illustrates an origin realm AVP indicating the realm of PCRF node 114. The message may further include the CC-request-type AVP indicating the type of credit control request. For example, Line 13 illustrates the CC-request-type AVP corresponding with a termination request. The message may further include the CC-request-number AVP indicating the credit control request number. For example, Line 14 illustrates the CC-request-number AVP “1” denoting a first request. The message may further include a result code AVP for reporting potential errors. For example, Line 15 illustrates the result code AVP “2001” indicating that the request was successfully completed.
  • TABLE 6
    01:  Version = 1
    02:  Message Length = XXX
    03:  Command Flags = PXY
    04:  Command Code = Credit-control (272)
    05:  Application Id = 16777238
    06:  Hop-By-Hop-Id = YYYY
    07:  End-To-End-Id = ZZZZZZZZ
    08:  AVPs
    09:    Session-Id = NON-3GPP PCEF.Op.com;
    1876543210;102
    10:    Auth-Application-Id = 16777238
    11:    Origin-Host = perf1.Op.com
    12:    Origin-Realm = Op.com
    13:    CC-Request-Type = TERMINATION_REQUEST (3)
    14:    CC-Request-Number = 1
    15:    Result-Code = DIAMETER_SUCCESS (2001)
  • FIG. 4 is a message flow diagram illustrating an exemplary externally initiated termination of a session for communicating policy information according to an embodiment of the subject matter described herein. Referring to FIG. 4, an IP CAN session may exist between UE 104 and PCEF node 116 enabling UE 104 to communicate with a host in Internet 110. User data plane 400, carrying traffic associated with UE 104's IP CAN session, may traverse service node 120. Upon the occurrence of specified conditions, service node 120 may desire to terminate an existing session with PCRF node 114 associated with UE 104's IP CAN session. Service node 120 may not implement the full blown Gx protocol and thus utilization of the Gx protocol may not be possible. In accordance with embodiments of the subject matter described herein, service node 120 may terminate the existing session with PCRF node 114. For example, at step 1, a triggering event may occur at service node 120. For example, an inactivity timer associated with the session may expire. In response to the triggering event, at step 2, service node 120 may send a CCR-T message to PCRF node 114. The message may include a session ID identifying the session between service node 120 and PCRF node 114 associated with UE 104's IP CAN session. The message may be sent, for example, via a Gx-Lite CCR-T Diameter message.
  • Table 7 illustrates an exemplary Gx-Lite CCR-T message. The message may include the version field for specifying version information. For example, Line 1 illustrates the version field specifying version 1.0. The message may further include the message length field for specifying the message's length, including any header information. For example, Line 2 illustrates the message length field specifying the symbolic message length “XXX” to denote the length of the message. The message may further include the command flags field. For example, Line 3 illustrates the command flags field with the r-bit set to “REQ” to indicate that the message is a request and the p-bit set to “PXY” to indicate that the message is proxiable. The message may further include the command codes field. For example, Line 4 illustrates the command codes field with the credit-control command code 272, corresponding with a credit-control-request. The message may further include the application ID field to identify to which application the message is applicable. For example, Line 5 illustrates the application ID field with a four octet vendor specific application ID. The message may further include a hop-by-hop ID field to aid in matching requests and replies. For example, Line 6 illustrates the hop-by-hop ID field specifying a symbolic hop-by-hop ID “YYYY” to denote a unique hop-by-hop ID. The message may further include an end-to-end ID field for detecting duplicate messages. For example, Line 7 illustrates an end-to-end ID field specifying a symbolic end-to-end ID “ZZZZZZZZ” to denote a unique end-to-end ID. The message may further include the AVPs field for indicating the beginning of AVPs. For example, Line 8 illustrates the AVPs field.
  • AVPs may be used to encapsulate information relevant to the message. The message may include a session ID AVP. For example, Line 9 illustrates a session ID AVP corresponding with the global identifier of the session. The message may further include an authentication application ID AVP or an accounting application ID AVP. For example, Line 10 illustrates an authentication ID AVP identifying the authentication and authorization portion of the application. The message may further include the origin host AVP and convey the fully qualified domain name of the node that generated the request. For example, Line 11 illustrates an origin host AVP corresponding with service node 120. The message may further include the origin realm AVP indicating the realm of the node that generated the request. For example, Line 12 illustrates an origin realm AVP indicating the realm of service node 120. The message may further include the destination realm AVP indicating the realm of the node the message is destined for. For example, Line 13 illustrates a destination realm AVP indicating the realm of PCRF node 114. The message may further include the destination host AVP and convey the fully qualified domain name of the node the message is destined for. For example, Line 14 illustrates a destination host AVP corresponding with PCRF node 114. The message may further include the CC-request-type AVP indicating the type of credit control request. For example, Line 15 illustrates the CC-request-type AVP corresponding with a termination request. The message may further include the CC-request-number AVP indicating the credit control request number. For example, Line 16 illustrates the CC-request-number AVP “1” denoting a first request. The message may further include the termination cause AVP containing information about the termination reason. For example, Line 17 illustrates a termination cause AVP specifying the termination reason as a Diameter logout.
  • TABLE 7
    01:  Version = 1
    02:  Message Length = XXX
    03:  Command Flags = REQ,PXY
    04:  Command Code = Credit-control (272)
    05:  Application Id = 16777238
    06:  Hop-By-Hop-Id = YYYY
    07:  End-To-End-Id = ZZZZZZZZ
    08:  AVPs
    09:    Session-Id = NON-3GPP PCEF.Op.com;
    1876543210;102
    10:    Auth-Application-Id = 16777238
    11:    Origin-Host = NON-3GPP PCEF.Op.com
    12:    Origin-Realm = Op.com
    13:    Destination-Realm = Op.com
    14:    Destination-Host = pcrf1.Op.com
    15:    CC-Request-Type = TERMINATION_REQUEST (3)
    16:    CC-Request-Number = 1
    17:    Termination-Cause = DIAMETER_LOGOUT (1)
  • At step 3, PCRF node 114 may acknowledge service node 120's CCR-T message by sending a CCA-T message to service node 120. The message may be sent, for example, via a Gx-Lite CCA-T Diameter message.
  • Table 8 illustrates an exemplary Gx-Lite CCA-T message. The message may include the version field for specifying version information. For example, Line 1 illustrates the version field specifying version 1.0. The message may further include the message length field for specifying the message's length, including any header information. For example, Line 2 illustrates the message length field specifying the symbolic message length “XXX” to denote the length of the message. The message may further include the command flags field. For example, Line 3 illustrates the command flags field with the p-bit set to “PXY” to indicate that the message is proxiable. The message may further include the command codes field. For example, Line 4 illustrates the command codes field with the credit-control command code 272, corresponding with a credit-control-request. The message may further include the application ID field to identify to which application the message is applicable. For example, Line 5 illustrates the application ID field with a four octet vendor specific application ID. The message may further include a hop-by-hop ID field to aid in matching requests and replies. For example, Line 6 illustrates the hop-by-hop ID field specifying a symbolic hop-by-hop ID “YYYY” to denote a unique hop-by-hop ID. The message may further include an end-to-end ID field for detecting duplicate messages. For example, Line 7 illustrates an end-to-end ID field specifying a symbolic end-to-end ID “ZZZZZZZZ” to denote a unique end-to-end ID. The message may further include the AVPs field for indicating the beginning of AVPs. For example, Line 8 illustrates the AVPs field.
  • AVPs may be used to encapsulate information relevant to the message. The message may include a session ID AVP. For example, Line 9 illustrates a session ID AVP corresponding with the global identifier of the session. The message may further include an authentication application ID AVP or an accounting application ID AVP. For example, Line 10 illustrates an authentication ID AVP identifying the authentication and authorization portion of the application. The message may further include the origin host AVP and convey the fully qualified domain name of the node that generated the answer. For example, Line 11 illustrates an origin host AVP corresponding with PCRF node 114. The message may further include the origin realm AVP indicating the realm of the node that generated the answer. For example, Line 12 illustrates an origin realm AVP indicating the realm of PCRF node 114. The message may further include the CC-request-type AVP indicating the type of credit control request. For example, Line 13 illustrates the CC-request-type AVP corresponding with a termination request. The message may further include the CC-request-number AVP indicating the credit control request number. For example, Line 14 illustrates the CC-request-number AVP “1” denoting a first request. The message may further include a result code AVP for reporting potential errors. For example, Line 15 illustrates the result code AVP “2001” indicating that the request was successfully completed.
  • TABLE 8
    01:  Version = 1
    02:  Message Length = XXX
    03:  Command Flags = PXY
    04:  Command Code = Credit-control (272)
    05:  Application Id = 16777238
    06:  Hop-By-Hop-Id = YYYY
    07:  End-To-End-Id = ZZZZZZZZ
    08:  AVPs
    09:    Session-Id = NON-3GPP PCEF.Op.com;
    1876543210;102
    10:    Auth-Application-Id = 16777238
    11:    Origin-Host = pcrf1.Op.com
    12:    Origin-Realm = Op.com
    13:    CC-Request-Type = TERMINATION_REQUEST (3)
    14:    CC-Request-Number = 1
    15:    Result-Code = DIAMETER_SUCCESS (2001)
  • FIG. 5 is a message flow diagram illustrating an exemplary policy rule push for communicating policy information according to an embodiment of the subject matter described herein. Referring to FIG. 5, an IP CAN session may exist between UE 104 and PCEF node 116 enabling UE 104 to communicate with a host in Internet 110. User data plane 500, carrying traffic associated with UE 104's IP CAN session, may traverse service node 120. Upon the occurrence of specified conditions, PCRF node 114 may desire to push a policy rule update associated with UE 104's IP CAN session to service node 120. Service node 120 may not implement the full blown Gx protocol and thus utilization of the Gx protocol may not be possible. In accordance with embodiments of the subject matter described herein, PCRF node 114 may push a policy rule update associated with UE 104's IP CAN session to service node 120. For example, at step 1, a triggering event may occur at PCRF node 114. For example, a time-of-day condition may occur at PCRF node 114. In response to the triggering event, at step 2, PCRF node 114 may send a RAR message to service node 120. The message may include a session ID identifying the session between service node 120 and PCRF node 114 associated with UE 104's IP CAN session. The message may further include a charging rule(s) update for service node 120 to implement with respect to UE 104's IP CAN session. The message may be sent, for example, via a Gx-Lite RAR Diameter message.
  • Table 9 illustrates an exemplary Gx-Lite RAR message. The message may include the version field for specifying version information. For example, Line 1 illustrates the version field specifying version 1.0. The message may further include the message length field for specifying the message's length, including any header information. For example, Line 2 illustrates the message length field specifying the symbolic message length “XXX” to denote the length of the message illustrated. The message may further include the command flags field. For example, Line 3 illustrates the command flags field with the r-bit set to “REQ” to indicate that the message is a request and the p-bit set to “PXY” to indicate that the message is proxiable. The message may further include the command codes field. For example, Line 4 illustrates the command codes field with the re-authorization command code 258, corresponding with a re-authorization-request. The message may further include the application ID field to identify to which application the message is applicable. For example, Line 5 illustrates the application ID field with a four octet vendor specific application ID. The message may further include a hop-by-hop ID field to aid in matching requests and replies. For example, Line 6 illustrates the hop-by-hop ID field specifying a symbolic hop-by-hop ID “YYYY” to denote a unique hop-by-hop ID. The message may further include an end-to-end ID field for detecting duplicate messages. For example, Line 7 illustrates an end-to-end ID field specifying a symbolic end-to-end ID “ZZZZZZZZ” to denote a unique end-to-end ID. The message may further include the AVPs field for indicating the beginning of AVPs. For example, Line 8 illustrates the AVPs field.
  • AVPs may be used to encapsulate information relevant to the message. The message may include a session ID AVP. For example, Line 9 illustrates a session ID AVP corresponding with the global identifier of the session. The message may further include an authentication application ID AVP or an accounting application ID AVP. For example, Line 10 illustrates an authentication ID AVP identifying the authentication and authorization portion of the application. The message may further include the origin host AVP and convey the fully qualified domain name of the node that generated the request. For example, Line 11 illustrates an origin host AVP corresponding with PCRF node 114. The message may further include the origin realm AVP indicating the realm of the node that generated the request. For example, Line 12 illustrates an origin realm AVP indicating the realm of PCRF node 114. The message may further include the destination host AVP and convey the fully qualified domain name of the node the message is destined for. For example, Line 13 illustrates a destination host AVP corresponding with service node 120. The message may further include the destination realm AVP indicating the realm of the node the message is destined for. For example, Line 14 illustrates a destination realm AVP indicating the realm of service node 120. The message may further include the re-authorization request type AVP to inform the client of the action expected upon expiration of the authorization. For example, Line 15 illustrates the re-authorization request type AVP set to “AUTHORIZE_ONLY” to indicate the expiration of the authorization lifetime. The message may further include the charging rule remove AVP for specifying charging rules to be uninstalled. For example, Line 16 illustrates the charging rule remove AVP. The message may further include the charging rule name AVP and identify a charging rule to remove. The charging rule may be predefined or dynamic. For example, Line 17 illustrates the charging rule name AVP specifying the predefined “normal_bw_p2p” charging rule for removal at service node 120 with respect to UE 104's IP CAN session. The message may further include the charging rule install AVP for specifying charging rules to be installed. For example, Line 18 illustrates the charging rule install AVP. The message may further include the charging rule name AVP and identify a charging rule to install. The charging rule may be predefined or dynamic. For example, Line 19 illustrates the charging rule name AVP specifying the predefined “happyHour_bw_p2p” charging rule for installation at service node 120 with respect to UE 104's IP CAN session.
  • TABLE 9
    01:  Version = 1
    02:  Message Length = XXX
    03:  Command Flags = REQ, PXY
    04:  Command Code = Re-Auth (258)
    05:  Application Id = 16777238
    06:  Hop-By-Hop-Id = YYYY
    07:  End-To-End-Id = ZZZZZZZZ
    08:  AVPs
    09:    Session-Id = NON-3GPP PCEF.Op.com;
    1876543210;102
    10:    Auth-Application-Id = 16777238
    11:    Origin-Host = pcrf1.Op.com
    12:    Origin-Realm = Op.com
    13:    Destination-Host = non-3GPP PCEF.Op.com
    14:    Destination-Realm = Op.com
    15:    Re-Auth-Request-Type = AUTHORIZE_ONLY
    16:    [Charging-Rule-Remove]
    17:      Charging-Rule-Name = normal_bw_p2p
    18:    [Charging-Rule-Install]
    19:      Charging-Rule-Name = happyHour_bw_p2p
  • Service node 120 may then install the charging rule(s) update (i.e., uninstall the “normal_bw_p2p” charging rule and install the “happyHour_bw_p2p” charging rule) with respect to UE 104's IP CAN session.
  • At step 3, service node 120 may acknowledge PCRF node 114's RAR message by sending a RAA message to PCRF node 114. The message may be sent, for example, via a Gx-Lite RAA Diameter message.
  • Table 10 illustrates an exemplary Gx-Lite RAA message. The message may include the version field for specifying version information. For example, Line 1 illustrates the version field specifying version 1.0. The message may further include the message length field for specifying the message's length, including any header information. For example, Line 2 illustrates the message length field specifying the symbolic message length “XXX” to denote the length of the message. The message may further include the command flags field. For example, Line 3 illustrates the command flags field with the p-bit set to “PXY” to indicate that the message is proxiable. The message may further include the command codes field. For example, Line 4 illustrates the command codes field with the re-authorization command code 258, corresponding with a re-authorization-request. The message may further include the application ID field to identify to which application the message is applicable. For example, Line 5 illustrates the application ID field with a four octet vendor specific application ID. The message may further include a hop-by-hop ID field to aid in matching requests and replies. For example, Line 6 illustrates the hop-by-hop ID field specifying a symbolic hop-by-hop ID “YYYY” to denote a unique hop-by-hop ID. The message may further include an end-to-end ID field for detecting duplicate messages. For example, Line 7 illustrates an end-to-end ID field specifying a symbolic end-to-end ID “ZZZZZZZZ” to denote a unique end-to-end ID. The message may further include the AVPs field for indicating the beginning of AVPs. For example, Line 8 illustrates the AVPs field.
  • AVPs may be used to encapsulate information relevant to the message. The message may include a session ID AVP. For example, Line 9 illustrates a session ID AVP corresponding with the global identifier of the session. The message may further include an authentication application ID AVP or an accounting application ID AVP. For example, Line 10 illustrates an authentication ID AVP identifying the authentication and authorization portion of the application. The message may further include the origin host AVP and convey the fully qualified domain name of the node that generated the answer. For example, Line 11 illustrates an origin host AVP corresponding with service node 120. The message may further include the origin realm AVP indicating the realm of the node that generated the answer. For example, Line 12 illustrates an origin realm AVP indicating the realm of service node 120. The message may further include a result code AVP for reporting potential errors. For example, Line 13 illustrates the result code AVP “2001” indicating that the request was successfully completed.
  • TABLE 10
    01:  Version = 1
    02:  Message Length = XXX
    03:  Command Flags = PXY
    04:  Command Code = Re-Auth (258)
    05:  Application Id = 16777238
    06:  Hop-By-Hop-Id = YYYY
    07:  End-To-End-Id = ZZZZZZZZ
    08:  AVPs
    09:    Session-Id = NON-3GPP PCEF.Op.com;
    1876543210;102
    10:    Auth-Application-Id = 16777238
    11:    Origin-Host = non-3GPP PCEF.Op.com
    12:    Origin-Realm = Op.com
    13:    Result-Code = DIAMETER_SUCCESS (2001)
  • FIG. 6 is a message flow diagram illustrating an exemplary audit procedure for communicating policy information according to an embodiment of the subject matter described herein. Referring to FIG. 6, an IP CAN session may exist between UE 104 and PCEF node 116 enabling UE 104 to communicate with a host in Internet 110. User data plane 600, carrying traffic associated with UE 104's IP CAN session, may traverse service node 120. Upon the occurrence of specified conditions, PCRF node 114 may desire to determine whether a session between itself and service node 120 associated with UE 104's IP CAN session remains active or has become inactive. Service node 120 may not implement the full blown Gx protocol and thus utilization of the Gx protocol may not be possible. In accordance with embodiments of the subject matter described herein, PCRF node 114 may determine whether a session between itself and service node 120 associated with UE 104's IP CAN session remains active or has become inactive. For example, at step 1, a triggering event may occur at PCRF node 114. For example, a periodic audit condition may occur at PCRF node 114. In response to the triggering event, at step 2, PCRF node 114 may send a RAR message to service node 120. The message may include a session ID identifying the session between service node 120 and PCRF node 114 associated with UE 104's IP CAN session. The message may be sent, for example, via a Gx-Lite RAR Diameter message.
  • Table 11 illustrates an exemplary Gx-Lite RAR message. The message may include the version field for specifying version information. For example, Line 1 illustrates the version field specifying version 1.0. The message may further include the message length field for specifying the message's length, including any header information. For example, Line 2 illustrates the message length field specifying the symbolic message length “XXX” to denote the length of the message illustrated. The message may further include the command flags field. For example, Line 3 illustrates the command flags field with the r-bit set to “REQ” to indicate that the message is a request and the p-bit set to “PXY” to indicate that the message is proxiable. The message may further include the command codes field. For example, Line 4 illustrates the command codes field with the re-authorization command code 258, corresponding with a re-authorization-request. The message may further include the application ID field to identify to which application the message is applicable. For example, Line 5 illustrates the application ID field with a four octet vendor specific application ID. The message may further include a hop-by-hop ID field to aid in matching requests and replies. For example, Line 6 illustrates the hop-by-hop ID field specifying a symbolic hop-by-hop ID “YYYY” to denote a unique hop-by-hop ID. The message may further include an end-to-end ID field for detecting duplicate messages. For example, Line 7 illustrates an end-to-end ID field specifying a symbolic end-to-end ID “ZZZZZZZZ” to denote a unique end-to-end ID. The message may further include the AVPs field for indicating the beginning of AVPs. For example, Line 8 illustrates the AVPs field.
  • AVPs may be used to encapsulate information relevant to the message. The message may include a session ID AVP. For example, Line 9 illustrates a session ID AVP corresponding with the global identifier of the session. The message may further include an authentication application ID AVP or an accounting application ID AVP. For example, Line 10 illustrates an authentication ID AVP identifying the authentication and authorization portion of the application. The message may further include the origin host AVP and convey the fully qualified domain name of the node that generated the request. For example, Line 11 illustrates an origin host AVP corresponding with PCRF node 114. The message may further include the origin realm AVP indicating the realm of the node that generated the request. For example, Line 12 illustrates an origin realm AVP indicating the realm of PCRF node 114. The message may further include the destination host AVP and convey the fully qualified domain name of the node the message is destined for. For example, Line 13 illustrates a destination host AVP corresponding with service node 120. The message may further include the destination realm AVP indicating the realm of the node the message is destined for. For example, Line 14 illustrates a destination realm AVP indicating the realm of service node 120. The message may further include the re-authorization request type AVP to inform the client of the action expected upon expiration of the authorization. For example, Line 15 illustrates the re-authorization request type AVP set to “AUTHORIZE_ONLY” to indicate the expiration of the authorization lifetime.
  • TABLE 11
    01:  Version = 1
    02:  Message Length = XXX
    03:  Command Flags = REQ, PXY
    04:  Command Code = Re-Auth (258)
    05:  Application Id = 16777238
    06:  Hop-By-Hop-Id = YYYY
    07:  End-To-End-Id = ZZZZZZZZ
    08:  AVPs
    09:    Session-Id = NON-3GPP PCEF.Op.com;
    1876543210;102
    10:    Auth-Application-Id = 16777238
    11:    Origin-Host = pcrf1.Op.com
    12:    Origin-Realm = Op.com
    13:    Destination-Host = non-3GPP PCEF.Op.com
    14:    Destination-Realm = Op.com
    15:    Re-Auth-Request-Type = AUTHORIZE_ONLY
  • At step 3, service node 120 may acknowledge PCRF node 114's RAR message by sending a RAA message to PCRF node 114. The message may include a result code indicating whether the session remains active or has become inactive. The message may be sent, for example, via a Gx-Lite RAA Diameter message.
  • Table 12 illustrates an exemplary Gx-Lite RAA message. The message may include the version field for specifying version information. For example, Line 1 illustrates the version field specifying version 1.0. The message may further include the message length field for specifying the message's length, including any header information. For example, Line 2 illustrates the message length field specifying the symbolic message length “XXX” to denote the length of the message. The message may further include the command flags field. For example, Line 3 illustrates the command flags field with the p-bit set to “PXY” to indicate that the message is proxiable. The message may further include the command codes field. For example, Line 4 illustrates the command codes field with the re-authorization command code 258, corresponding with a re-authorization-request. The message may further include the application ID field to identify to which application the message is applicable. For example, Line 5 illustrates the application ID field with a four octet vendor specific application ID. The message may further include a hop-by-hop ID field to aid in matching requests and replies. For example, Line 6 illustrates the hop-by-hop ID field specifying a symbolic hop-by-hop ID “YYYY” to denote a unique hop-by-hop ID. The message may further include an end-to-end ID field for detecting duplicate messages. For example, Line 7 illustrates an end-to-end ID field specifying a symbolic end-to-end ID “ZZZZZZZZ” to denote a unique end-to-end ID. The message may further include the AVPs field for indicating the beginning of AVPs. For example, Line 8 illustrates the AVPs field.
  • AVPs may be used to encapsulate information relevant to the message. The message may include a session ID AVP. For example, Line 9 illustrates a session ID AVP corresponding with the global identifier of the session. The message may further include an authentication application ID AVP or an accounting application ID AVP. For example, Line 10 illustrates an authentication ID AVP identifying the authentication and authorization portion of the application. The message may further include the origin host AVP and convey the fully qualified domain name of the node that generated the answer. For example, Line 11 illustrates an origin host AVP corresponding with service node 120. The message may further include the origin realm AVP indicating the realm of the node that generated the answer. For example, Line 12 illustrates an origin realm AVP indicating the realm of service node 120. The message may further include if/else decisional logic surrounding result code AVPs for reporting potential errors that may correspond with whether the session remains active or has become inactive. For example, Lines 13-16 illustrate pseudo code for if/else decisional logic that will invoke the result code AVP “2001” indicating that the request was successfully completed if the session remains active and will invoke the result code AVP “5002” indicating that the request contained an unknown session ID if the session has become inactive.
  • TABLE 12
    01:  Version = 1
    02:  Message Length = XXX
    03:  Command Flags = PXY
    04:  Command Code = Re-Auth (258)
    05:  Application Id = 16777238
    06:  Hop-By-Hop-Id = YYYY
    07:  End-To-End-Id = ZZZZZZZZ
    08:  AVPs
    09:   Session-Id = NON-3GPP PCEF.Op.com;
    1876543210;102
    10:   Auth-Application-Id = 16777238
    11:   Origin-Host = non-3GPP PCEF.Op.com
    12:   Origin-Realm = Op.com
    13:   if the session exists then
    14:    Result-Code = DIAMETER_SUCCESS (2001)
    15:   else
    16:    Result-Code = DIAMETER_UNKNOWN_SESSION_ID
    (5002)
  • In response to service node 120's RAA message indicating that the session has become inactive, PCRF node 114 may invoke procedures to free up resources associated with the session.
  • FIG. 7 is a message flow diagram illustrating exemplary event subscription and notification for communicating policy information according to an embodiment of the subject matter described herein. Referring to FIG. 7, at step 1, UE 104 may initiate establishment of an IP CAN session with PCEF node 116 for the purpose of communicating with a host in Internet 110. At step 2, PCEF node 116 may send a CCR message to PCRF node 114. The CCR message may include a user ID and IP address associated with UE 104. At step 3, PCRF node 114 may send a CCA message to PCEF node 116. The CCA message may include a charging rule for PCEF node 116 to implement with respect to UE 104's IP CAN session. PCEF node 116 may support an implementation of the full blown Gx protocol and thus the CCR/CCA exchange, between PCEF node 116 and PCRF node 114, may utilize the Gx protocol.
  • User data plane 700, carrying traffic associated with UE 104's IP CAN session, may traverse service node 120. PCRF node 114 may desire to communicate with service node 120 in order to subscribe to SDF event notifications and/or install policy rule(s). Service node 120 may not implement the full blown Gx protocol and thus utilization of the Gx protocol may not be possible. In accordance with embodiments of the subject matter described herein, PCRF node 114 may communicate with service node 120 in order to subscribe to SDF event notifications and/or install policy rule(s).
  • At step 4, service node 120 may receive an external trigger indicating that it should establish a session with PCRF node 114. The external trigger may include an IP address associated with UE 104. At step 5, in response to the external trigger, service node 120 may send a message to PCRF node 114 which includes the IP address. The message may be sent, for example, via a Gx-Lite CCR-I Diameter message.
  • Table 13 illustrates an exemplary Gx-Lite CCR-I message. The message may include the version field for specifying version information. For example, Line 1 illustrates the version field specifying version 1.0. The message may further include the message length field for specifying the message's length, including any header information. For example, Line 2 illustrates the message length field specifying the symbolic message length “XXX” to denote the length of the message. The message may further include the command flags field. For example, Line 3 illustrates the command flags field with the r-bit set to “REQ” to indicate that the message is a request and the p-bit set to “PXY” to indicate that the message is proxiable. The message may further include the command codes field. For example, Line 4 illustrates the command codes field with the credit-control command code 272, corresponding with a credit-control-request. The message may further include the application ID field to identify to which application the message is applicable. For example, Line 5 illustrates the application ID field with a four octet vendor specific application ID. The message may further include a hop-by-hop ID field to aid in matching requests and replies. For example, Line 6 illustrates the hop-by-hop ID field specifying a symbolic hop-by-hop ID “YYYY” to denote a unique hop-by-hop ID. The message may further include an end-to-end ID field for detecting duplicate messages. For example, Line 7 illustrates an end-to-end ID field specifying a symbolic end-to-end ID “ZZZZZZZZ” to denote a unique end-to-end ID. The message may further include the AVPs field for indicating the beginning of AVPs. For example, Line 8 illustrates the AVPs field.
  • AVPs may be used to encapsulate information relevant to the message. The message may include a session ID AVP. For example, Line 9 illustrates a session ID AVP corresponding with the global identifier of the session. The message may further include an authentication application ID AVP or an accounting application ID AVP. For example, Line 10 illustrates an authentication ID AVP identifying the authentication and authorization portion of the application. The message may further include the origin host AVP and convey the fully qualified domain name of the node that generated the request. For example, Line 11 illustrates an origin host AVP corresponding with service node 120. The message may further include the origin realm AVP indicating the realm of the node that generated the request. For example, Line 12 illustrates an origin realm AVP indicating the realm of service node 120. The message may further include the destination realm AVP indicating the realm of the node the message is destined for. For example, Line 13 illustrates a destination realm AVP indicating the realm of PCRF node 114. The message may further include the CC-request-type AVP indicating the type of credit control request. For example, Line 14 illustrates the CC-request-type AVP corresponding with an initial request. The message may further include the CC-request-number AVP indicating the credit control request number. For example, Line 15 illustrates the CC-request-number AVP “0” denoting a first request.
  • The message may include an indication of the beginning of subscription information. For example, Line 16 illustrates an indication that subscription information is included. In some embodiments, PCRF node 114 may support receiving multiple subscription IDs in a single message. The message may further include the subscription-ID-type AVP for specifying the format of the subscription ID information. For example, Line 17 illustrates the subscription-ID-type AVP indicating that the subscription ID information is an end user IMSI. The message may further include the subscription-ID-data AVP for providing the subscription ID information itself. For example, Line 18 illustrates the subscription-ID-data AVP specifying the symbolic value “IMSI” to denote an IMSI associated with UE 104. The message may further include the supported-features AVP for informing the destination host of the features supported by the originating host. For example, Line 19 illustrates the supported-features AVP for informing PCRF node 114 of the features supported by service node 120. The message may further include the vendor-ID AVP for identifying the vendor of the originating host. For example, Line 20 illustrates the vendor-ID AVP specifying the vendor “Camiant” of service node 120. The message may further include the feature-list-ID AVP identifying the appropriate feature list from multiple possible supported feature lists. For example, Line 21 illustrates the feature-list-ID AVP indicating symbolic feature list “1” of multiple possible supported feature lists. The message may further include the feature-list AVP identifying the supported features. For example, Line 22 illustrates the feature-list AVP specifying features supported by service node 120 (e.g., “Gx-Lite”). The message may further include the framed-IP-address AVP indicating an address to be configured for the user. The IP address specified may be, for example, a version 4 or version 6 address. For example, Line 23 illustrates the framed-IP-address AVP specifying an IP address associated with UE 104.
  • TABLE 13
    01:  Version = 1
    02:  Message Length = XXX
    03:  Command Flags = REQ, PXY
    04:  Command Code = Credit-control (272)
    05:  Application Id = 16777238
    06:  Hop-By-Hop-Id = YYYY
    07:  End-To-End-Id = ZZZZZZZZ
    08:  AVPs
    09:    Session-Id = NON-3GPP PCEF.Op.com;
    1876543210;102
    10:    Auth-Application-Id = 16777238
    11:    Origin-Host = NON-3GPP PCEF.Op.com
    12:    Origin-Realm = Op.com
    13:    Destination-Realm = Op.com
    14:    CC-Request-Type = INITIAL_REQUEST (1)
    15:    CC-Request-Number = 0
    16:    [Subscription-Id] // optional
    17:      Subscription-Id-Type = END_USER_IMSI (1)
    18:      Subscription-Id-Data = <IMSI>
    19:    Supported-Features
    20:      Vendor-Id = Camiant (21274)
    21:      Feature-List-ID = TBD [e.g., 1]
    22:      Feature-List = TBD [e.g., Gx-Light]
    23:      Framed-IP-Address = 192.168.2.11
  • Utilizing the IP address included in the CCR-I message, PCRF node 114 may determine a NAI for a subscriber associated with UE 104. The NAI may be an IMSI, a MSISDN, a URI, an IMS public identity, or an IMS private identity. PCRF node 114 may query SDM node 118 in order to determine a NAI for the subscriber based on the IP address. In one embodiment, PCRF node 114 may utilize information derived from exchanges with PCEF node 116 to determine the NAI.
  • Having determined a NAI for the subscriber associated with UE 104, PCRF node 114 may utilize the NAI to select an appropriate policy rule. The policy rule selected may authorize or de-authorize a content-filtering service and/or a web-optimization service for the subscriber associated with UE 104. The policy rule selected may specify user data plane content that is to be blocked for the subscriber associated with UE 104. For example, the policy rule may specify to block user data plane content associated with a URL, a web page, a text string, an image, and/or a video. Additionally, PCRF node 114 may determine that it should be notified upon the detection of an SDF event by service node 120 and that it should therefore subscribe to the appropriate SDF detection. At step 6, PCRF node 114 may communicate the selected policy rule and/or the SDF detection subscription to service node 120 via a message. The message may be sent, for example, via a Gx-Lite CCA-I Diameter message.
  • Table 14 illustrates an exemplary Gx-Lite CCA-I message. The message may include the version field for specifying version information. For example, Line 1 illustrates the version field specifying version 1.0. The message may further include the message length field for specifying the message's length, including any header information. For example, Line 2 illustrates the message length field specifying the symbolic message length “XXX” to denote the length of the message. The message may further include the command flags field. For example, Line 3 illustrates the command flags field with the p-bit set to “PXY” to indicate that the message is proxiable. The message may further include the command codes field. For example, Line 4 illustrates the command codes field with the credit-control command code 272, corresponding with a credit-control-request. The message may further include the application ID field to identify to which application the message is applicable. For example, Line 5 illustrates the application ID field with a four octet vendor specific application ID. The message may further include a hop-by-hop ID field to aid in matching requests and replies. For example, Line 6 illustrates the hop-by-hop ID field specifying a symbolic hop-by-hop ID “YYYY” to denote a unique hop-by-hop ID. The message may further include an end-to-end ID field for detecting duplicate messages. For example, Line 7 illustrates an end-to-end ID field specifying a symbolic end-to-end ID “ZZZZZZZZ” to denote a unique end-to-end ID. The message may further include the AVPs field for indicating the beginning of AVPs. For example, Line 8 illustrates the AVPs field.
  • AVPs may be used to encapsulate information relevant to the message. The message may include a session ID AVP. For example, Line 9 illustrates a session ID AVP corresponding with the global identifier of the session. The message may further include a result code AVP for reporting potential errors. For example, Line 10 illustrates the result code AVP “2001” indicating that the request was successfully completed. The message may further include the origin host AVP and convey the fully qualified domain name of the node that generated the answer. For example, Line 11 illustrates an origin host AVP corresponding with PCRF node 114. The message may further include the origin realm AVP indicating the realm of the node that generated the answer. For example, Line 12 illustrates an origin realm AVP indicating the realm of PCRF node 114. The message may further include an authentication application ID AVP or an accounting application ID AVP. For example, Line 13 illustrates an authentication ID AVP identifying the authentication and authorization portion of the application. The message may further include the CC-request-type AVP indicating the type of credit control request. For example, Line 14 illustrates the CC-request-type AVP corresponding with an initial request. The message may further include the CC-request-number AVP indicating the credit control request number. For example, Line 15 illustrates the CC-request-number AVP “0” denoting a first request. The message may further include the event trigger AVP for identifying a specified event that should cause service node 120 to re-request PCC rule(s). For example, Line 16 illustrates the event trigger AVP and indicates that service node 120 should re-request PCC rule(s) upon SDF detection. The message may further include the charging rule install AVP for specifying charging rule(s) to be installed. For example, Line 17 illustrates the charging rule install AVP. The message may further include the charging rule name AVP and identify a charging rule(s) to install. A charging rule may be predefined or dynamic. For example, Line 18 illustrates the charging rule name AVP specifying the predefined “Default_Traffic” charging rule for installation at service node 120 with respect to UE 104's IP CAN session. The message may further include an additional charging rule install AVP for specifying additional charging rule(s) to be installed. For example, Line 19 illustrates an additional charging rule install AVP. The message may further include additional charging rule name AVP(s) and identify the additional charging rule(s) to install. For example, Line 20 illustrates an additional charging rule name AVP specifying the predefined “P2P_Traffic” charging rule for installation at service node 120 with respect to UE 104's IP CAN session. The message may further include the service flow detection AVP for enabling SDF event detection. For example, Line 21 illustrates a service flow detection AVP for enabling SDF event detection.
  • TABLE 14
    01:  Version = 1
    02:  Message Length = XXX
    03:  Command Flags = PXY
    04:  Command Code = Credit-control (272)
    05:  Application Id = 16777238
    06:  Hop-By-Hop-Id = YYYY
    07:  End-To-End-Id = ZZZZZZZZ
    08:  AVPs
    09:    Session-Id = NON-3GPP PCEF.Op.com;
    1876543210;102
    10:    Result-Code = DIAMETER_SUCCESS (2001)
    11:    Origin-Host = pcrf1.Op.com
    12:    Origin-Realm = Op.com
    13:    Auth-Application-Id = 16777238
    14:    CC-Request-Type = INITIAL_REQUEST (1)
    15:    CC-Request-Number = 0
    16:    Event-Trigger = SERVICE_FLOW_DETECTION
    (1002)
    17:    Charging-Rule-Install
    18:     Charging-Rule-Name = Default_Traffic
    19:    Charging-Rule-Install
    20:     Charging-Rule-Name = P2P_Traffic
    21:     Service-Flow-Detection = ENABLE_DETECTION(0)
  • At step 7, service node 120 may detect the SDF event specified in the message received from PCRF node 114. At step 8, service node 120 may send a credit-control-request update (CCR-U) message to PCRF node 114 indicating that the SDF event has been detected and re-requesting policy rule(s). The message may be sent, for example, via a Gx-Lite CCR-U Diameter message.
  • Table 15 illustrates an exemplary Gx-Lite CCR-U message. The message may include the version field for specifying version information. For example, Line 1 illustrates the version field specifying version 1.0. The message may further include the message length field for specifying the message's length, including any header information. For example, Line 2 illustrates the message length field specifying the symbolic message length “XXX” to denote the length of the message. The message may further include the command flags field. For example, Line 3 illustrates the command flags field with the r-bit set to “REQ” to indicate that the message is a request and the p-bit set to “PXY” to indicate that the message is proxiable. The message may further include the command codes field. For example, Line 4 illustrates the command codes field with the credit-control command code 272, corresponding with a credit-control-request. The message may further include the application ID field to identify to which application the message is applicable. For example, Line 5 illustrates the application ID field with a four octet vendor specific application ID. The message may further include a hop-by-hop ID field to aid in matching requests and replies. For example, Line 6 illustrates the hop-by-hop ID field specifying a symbolic hop-by-hop ID “YYYY” to denote a unique hop-by-hop ID. The message may further include an end-to-end ID field for detecting duplicate messages. For example, Line 7 illustrates an end-to-end ID field specifying a symbolic end-to-end ID “ZZZZZZZZ” to denote a unique end-to-end ID. The message may further include the AVPs field for indicating the beginning of AVPs. For example, Line 8 illustrates the AVPs field.
  • AVPs may be used to encapsulate information relevant to the message. The message may include a session ID AVP. For example, Line 9 illustrates a session ID AVP corresponding with the global identifier of the session. The message may further include an authentication application ID AVP or an accounting application ID AVP. For example, Line 10 illustrates an authentication ID AVP identifying the authentication and authorization portion of the application. The message may further include the origin host AVP and convey the fully qualified domain name of the node that generated the request. For example, Line 11 illustrates an origin host AVP corresponding with service node 120. The message may further include the destination host AVP and convey the fully qualified domain name of the node the message is destined for. For example, Line 12 illustrates a destination host AVP corresponding with PCRF node 114. The message may further include the origin realm AVP indicating the realm of the node that generated the request. For example, Line 13 illustrates an origin realm AVP indicating the realm of service node 120. The message may further include the destination realm AVP indicating the realm of the node the message is destined for. For example, Line 14 illustrates a destination realm AVP indicating the realm of PCRF node 114. The message may further include the CC-request-type AVP indicating the type of credit control request. For example, Line 15 illustrates the CC-request-type AVP corresponding with an update request. The message may further include the CC-request-number AVP indicating the credit control request number. For example, Line 16 illustrates the CC-request-number AVP “1” denoting an update request. The message may further include the origin state ID AVP for enabling other Diameter entities to infer that other sessions (i.e., sessions with a lower origin state ID) are no longer active. For example, Line 17 illustrates the origin state ID AVP indicating that sessions with an origin state ID lower than “1164772302” are no longer active. The message may further include the event trigger AVP for identifying the event trigger. For example, Line 18 illustrates the event trigger AVP and identifies the event trigger SDF detection. The message may further include the charging rule report AVP for indicating the beginning of the charging rule report. For example, Line 19 illustrates the charging rule report AVP and indicates the beginning of a charging rule report associated with the SDF detection. The message may further include the charging rule name AVP and identify a charging rule(s) associated with the report. For example, Line 20 illustrates the charging rule name AVP specifying the “P2P_Traffic” charging rule associated with the report. The message may further include the PCC rule status AVP for reporting the current status of the PCC rule. For example, Line 21 illustrates the PCC rule status AVP and reports the current status of the “P2P_Traffic” rule as active.
  • TABLE 15
    01:  Version = 1
    02:  Message Length = XXX
    03:  Command Flags = REQ, PXY
    04:  Command Code = Credit-control (272)
    05:  Application Id = 16777238
    06:  Hop-By-Hop-Id = YYYY
    07:  End-To-End-Id = ZZZZZZZZ
    08:  AVPs
    09:    Session-Id = NON-3GPP PCEF.Op.com;
    1876543210;102
    10:    Auth-Application-Id = 16777238
    11:    Origin-Host = NON-3GPP PCEF.Op.com
    12:    Destination-Host = pcrf1.Op.com
    13:    Origin-Realm = Op.com
    14:    Destination-Realm = Op.com
    15:    CC-Request-Type = UPDATE_REQUEST (2)
    16:    CC-Request-Number = 1
    17:    Origin-State-Id = 1164772302
    18:    Event-Trigger = SERVICE_FLOW_DETECTION
    (1002)
    19:    Charging-Rule-Report =
    20:          Charging-Rule-Name = P2P_Traffic
    21:          PCC-Rule-Status = Active (0)
  • In response to receiving service node 120's CCR-U message, at step 9, PCRF node 114 may send a credit-control-answer update (CCA-U) message to service node 120. The message may include a charging rule(s) update for service node 120 to implement with respect to UE 104's IP CAN session. The message may be sent, for example, via a Gx-Lite CCA-U Diameter message.
  • Table 16 illustrates an exemplary Gx-Lite CCA-U message. The message may include the version field for specifying version information. For example, Line 1 illustrates the version field specifying version 1.0. The message may further include the message length field for specifying the message's length, including any header information. For example, Line 2 illustrates the message length field specifying the symbolic message length “XXX” to denote the length of the message. The message may further include the command flags field. For example, Line 3 illustrates the command flags field with the p-bit set to “PXY” to indicate that the message is proxiable. The message may further include the command codes field. For example, Line 4 illustrates the command codes field with the credit-control command code 272, corresponding with a credit-control-request. The message may further include the application ID field to identify to which application the message is applicable. For example, Line 5 illustrates the application ID field with a four octet vendor specific application ID. The message may further include a hop-by-hop ID field to aid in matching requests and replies. For example, Line 6 illustrates the hop-by-hop ID field specifying a symbolic hop-by-hop ID “YYYY” to denote a unique hop-by-hop ID. The message may further include an end-to-end ID field for detecting duplicate messages. For example, Line 7 illustrates an end-to-end ID field specifying a symbolic end-to-end ID “ZZZZZZZZ” to denote a unique end-to-end ID. The message may further include the AVPs field for indicating the beginning of AVPs. For example, Line 8 illustrates the AVPs field.
  • AVPs may be used to encapsulate information relevant to the message. The message may include a session ID AVP. For example, Line 9 illustrates a session ID AVP corresponding with the global identifier of the session. The message may further include an authentication application ID AVP or an accounting application ID AVP. For example, Line 10 illustrates an authentication ID AVP identifying the authentication and authorization portion of the application. The message may further include the origin host AVP and convey the fully qualified domain name of the node that generated the answer. For example, Line 11 illustrates an origin host AVP corresponding with PCRF node 114. The message may further include the origin realm AVP indicating the realm of the node that generated the answer. For example, Line 12 illustrates an origin realm AVP indicating the realm of PCRF node 114. The message may further include the CC-request-type AVP indicating the type of credit control request. For example, Line 15 illustrates the CC-request-type AVP corresponding with an update request. The message may further include the CC-request-number AVP indicating the credit control request number. For example, Line 16 illustrates the CC-request-number AVP “1” denoting an update request. The message may further include a result code AVP for reporting potential errors. For example, Line 15 illustrates the result code AVP “2001” indicating that the request was successfully completed. The message may further include the charging rule remove AVP for specifying charging rules to be uninstalled. For example, Line 16 illustrates the charging rule remove AVP. The message may further include the charging rule name AVP and identify a charging rule to remove. The charging rule may be predefined or dynamic. For example, Line 17 illustrates the charging rule name AVP specifying the predefined “P2P-Traffic” charging rule for removal at service node 120 with respect to UE 104's IP CAN session. The message may further include the charging rule install AVP for specifying charging rules to be installed. For example, Line 18 illustrates the charging rule install AVP. The message may further include the charging rule name AVP and identify a charging rule to install. The charging rule may be predefined or dynamic. For example, Line 19 illustrates the charging rule name AVP specifying the predefined “block_p2p” charging rule for installation at service node 120 with respect to UE 104's IP CAN session.
  • TABLE 16
    01:  Version = 1
    02:  Message Length = XXX
    03:  Command Flags = PXY
    04:  Command Code = Credit-control (272)
    05:  Application Id = 16777238
    06:  Hop-By-Hop-Id = YYYY
    07:  End-To-End-Id = ZZZZZZZZ
    08:  AVPs
    09:    Session-Id = NON-3GPP PCEF.Op.com;
    1876543210;102
    10:    Auth-Application-Id = 16777238
    11:    Origin-Host = pcrf1.Op.com
    12:    Origin-Realm = Op.com
    13:    CC-Request-Type = UPDATE_REQUEST (2)
    14:    CC-Request-Number = 1
    15:    Result-Code = DIAMETER_SUCCESS (2001)
    16:    Charging-Rule-Remove
    17:     Charging-Rule-Name = P2P-Traffic
    18:    Charging-Rule-Install
    19:     Charging-Rule-Name = block_p2p
  • Service node 120 may then install the charging rule(s) update (i.e., uninstall the “P2P-Traffic” charging rule and install the “block_p2p” charging rule) with respect to UE 104's IP CAN session.
  • FIG. 8 is a flow chart illustrating an exemplary process for communicating policy information according to an embodiment of the subject matter described herein. Referring to FIG. 8, in step 800, a PCRF node receives, from a service node, a message requesting a policy rule, wherein the message includes an IP address, associated with a subscriber. For example, PCRF node 114 may receive, from service node 120, a message requesting a policy rule. The message may include an IP address associated with a subscriber utilizing UE 104. The message may be, for example, a CCR-I message similar to that illustrated in Table 1. In step 802, the PCRF node determines a NAI for the subscriber based on the IP address. For example, PCRF node 114 may determine a NAI for the subscriber utilizing UE 104 based on the IP address included in the received message. In step 804, the PCRF node selects a policy rule for the subscriber based on the NAI. For example, PCRF node 114 may select a policy rule (i.e., “P2P_Traffic”) based on the NAI determined in step 802. In step 806, the PCRF node communicates the policy rule to the service node. For example, PCRF node 114 may communicate the “P2P_Traffic” rule to service node 120 via a CCA-I message similar to the message illustrated in Table 2.
  • FIG. 9 is a block diagram of an exemplary PCRF node for communicating policy information according to an embodiment of the subject matter described herein. Referring to FIG. 9, PCRF node 114 includes a communication interface 900 for sending and receiving messages. Communication interface 900 may be capable of communicating with other nodes via any suitable interface, such as a Gx interface, a Gxx interface, a Gx-Lite interface, or an Rx interface. PCRF node 114 further includes a communication module 902 configured to utilize communication interface 900 to receive, from a service node, a message requesting a policy rule, wherein the message includes an IP address associated with a subscriber. For example, communication module 902 may be configured to utilize communication interface 900 to receive, from service node 120, a message requesting a policy rule, wherein the message includes an IP address associated with a subscriber utilizing UE 104. For example, communication module 902 may be configured to utilize communication interface 900 to receive a message similar to the CCR-I message illustrated in Table 1. Communication module 902 is further configured to determine a NAI for the subscriber based on the IP address. For example, communication module 902 may be configured to determine a NAI for the subscriber utilizing UE 104. Communication module 902 is further configured to select a policy rule for the subscriber based on the NAI. For example, communication module 902 may be configured to select a policy rule (e.g., “P2P_Traffic”) for the subscriber utilizing UE 104 based on the determined NAI. Communication module 902 is further configured to utilize communication interface 900 to communicate the policy rule to the service node. For example, communication module 902 may be configured to utilize communication interface 900 to communicate the “P2P_Traffic” policy rule to service node 120. For example, communication module 902 may be configured to utilize communication interface 900 to communicate a message similar to the CCA-I message illustrated in Table 2.
  • It will be understood that various details of the subject matter described herein may be changed without departing from the scope of the subject matter described herein. Furthermore, the foregoing description is for the purpose of illustration only, and not for the purpose of limitation, as the subject matter described herein is defined by the claims as set forth hereinafter.

Claims (20)

  1. 1. A method for communicating policy information, the method comprising:
    at a policy charging and rules function (PCRF) node:
    receiving, from a service node, a message requesting a policy rule, wherein the message includes an Internet protocol (IP) address associated with a subscriber;
    determining a network access identifier (NAI) for the subscriber based on the IP address;
    selecting a policy rule for the subscriber based on the NAI; and
    communicating the policy rule to the service node.
  2. 2. The method of claim 1 wherein the NAI comprises at least one of an international mobile station identifier (IMSI), a mobile subscriber integrated services digital network number (MSISDN), a uniform resource identifier (URI), an Internet protocol (IP) multimedia subsystem (IMS) public identity, and an IMS private identity.
  3. 3. The method of claim 1 wherein determining the NAI for the subscriber comprises querying a subscriber data management (SDM) node.
  4. 4. The method of claim 3 wherein the SDM node comprises at least one of a home subscriber server (HSS), a user profile serving function (UPSF), and a subscription profile repository (SPR).
  5. 5. The method of claim 1 wherein the message comprises a Diameter message.
  6. 6. The method of claim 1 wherein the policy rule is communicated via a Diameter message.
  7. 7. The method of claim 1 wherein the message is received via an interface that implements a subset of a Gx protocol or Gx application.
  8. 8. The method of claim 1 wherein the policy rule is communicated via an interface that implements a subset of a Gx protocol or Gx application.
  9. 9. The method of claim 1 wherein the policy rule authorizes or de-authorizes at least one of a content-filtering service for the subscriber and a web-optimization service for the subscriber.
  10. 10. The method of claim 1 wherein the policy rule specifies user data plane content that is to be blocked for the subscriber.
  11. 11. A system for communicating policy information, the system comprising:
    a policy and charging rules function (PCRF) node, the PCRF node comprising:
    a communication interface; and
    a communication module configured to:
    utilize the communication interface to receive, from a service node, a message requesting a policy rule, wherein the message includes an Internet protocol (IP) address associated with a subscriber;
    determine a network access identifier (NAI) for the subscriber based on the IP address;
    select a policy rule for the subscriber based on the NAI; and
    utilize the communication interface to communicate the policy rule to the service node.
  12. 12. The system of claim 11 wherein the NAI comprises at least one of an international mobile station identifier (IMSI), a mobile subscriber integrated services digital network number (MSISDN), a uniform resource identifier (URI), an Internet protocol (IP) multimedia subsystem (IMS) public identity, and an IMS private identity.
  13. 13. The system of claim 12 wherein the communications module is configured to determine the NAI for the subscriber by querying a subscriber data management (SDM) node.
  14. 14. The system of claim 13 wherein the SDM node comprises at least one of a home subscriber server (HSS), a user profile serving function (UPSF), and a subscription profile repository (SPR).
  15. 15. The system of claim 11 wherein the message composes a Diameter message.
  16. 16. The system of claim 11 wherein the communication module is configured to receive the message via the communication interface by implementing a subset of a Gx protocol or Gx application.
  17. 17. The system of claim 11 wherein the communication module is configured to communicate the policy rule via the communication interface by implementing a subset of a Gx protocol or Gx application.
  18. 18. The system of claim 11 wherein the policy rule authorizes or de-authorizes at least one of a content-filtering service for the subscriber and a web-optimization service for the subscriber.
  19. 19. The system of claim 11 wherein the policy rule specifies user data plane content that is to be blocked for the subscriber.
  20. 20. A non-transitory computer readable medium comprising computer executable instructions that when executed by a processor of a computer control the computer to perform steps comprising:
    receiving, from a service node, a message requesting a policy rule, wherein the message includes an Internet protocol (IP) address associated with a subscriber;
    determining a network access identifier (NAI) for the subscriber based on the IP address;
    selecting a policy rule for the subscriber based on the NAI; and
    communicating the policy rule to the service node.
US13048607 2010-03-15 2011-03-15 Methods, systems, and computer readable media for communicating policy information between a policy charging and rules function and a service node Abandoned US20110225280A1 (en)

Priority Applications (4)

Application Number Priority Date Filing Date Title
US31395310 true 2010-03-15 2010-03-15
US31513010 true 2010-03-18 2010-03-18
US32253310 true 2010-04-09 2010-04-09
US13048607 US20110225280A1 (en) 2010-03-15 2011-03-15 Methods, systems, and computer readable media for communicating policy information between a policy charging and rules function and a service node

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US13048607 US20110225280A1 (en) 2010-03-15 2011-03-15 Methods, systems, and computer readable media for communicating policy information between a policy charging and rules function and a service node

Publications (1)

Publication Number Publication Date
US20110225280A1 true true US20110225280A1 (en) 2011-09-15

Family

ID=44560983

Family Applications (2)

Application Number Title Priority Date Filing Date
US13048597 Active 2031-10-14 US9603058B2 (en) 2010-03-15 2011-03-15 Methods, systems, and computer readable media for triggering a service node to initiate a session with a policy and charging rules function
US13048607 Abandoned US20110225280A1 (en) 2010-03-15 2011-03-15 Methods, systems, and computer readable media for communicating policy information between a policy charging and rules function and a service node

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US13048597 Active 2031-10-14 US9603058B2 (en) 2010-03-15 2011-03-15 Methods, systems, and computer readable media for triggering a service node to initiate a session with a policy and charging rules function

Country Status (4)

Country Link
US (2) US9603058B2 (en)
EP (1) EP2548388A4 (en)
CN (1) CN102893640B (en)
WO (1) WO2011115991A3 (en)

Cited By (37)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100121960A1 (en) * 2008-06-05 2010-05-13 Camiant, Inc. Method and system for providing mobility management in network
US20110022702A1 (en) * 2009-07-24 2011-01-27 Camiant, Inc. Mechanism for detecting and reporting traffic/service to a pcrf
US20110167471A1 (en) * 2010-01-04 2011-07-07 Yusun Kim Riley Methods, systems, and computer readable media for providing group policy configuration in a communications network using a fake user
US20110165901A1 (en) * 2010-01-04 2011-07-07 Uri Baniel Methods, systems, and computer readable media for policy charging and rules function (pcrf) node selection
US20110202684A1 (en) * 2010-02-12 2011-08-18 Jeffrey Alan Craig Methods, systems, and computer readable media for inter-diameter-message processor routing
US20110202653A1 (en) * 2010-02-12 2011-08-18 Yusun Kim Riley Methods, systems, and computer readable media for service detection over an rx interface
US20110202676A1 (en) * 2010-02-12 2011-08-18 Jeffrey Alan Craig Methods, systems, and computer readable media for providing peer routing at a diameter node
US20110219426A1 (en) * 2010-03-05 2011-09-08 Yusun Kim Methods, systems, and computer readable media for enhanced service detection and policy rule determination
US20110225306A1 (en) * 2010-03-15 2011-09-15 Mark Delsesto Methods, systems, and computer readable media for triggering a service node to initiate a session with a policy charging and rules function
US20110282981A1 (en) * 2010-05-11 2011-11-17 Alcatel-Lucent Canada Inc. Behavioral rule results
US20110302458A1 (en) * 2010-06-07 2011-12-08 Alcatel-Lucent Canada, Inc. Framework for managing failures in outbound messages
US20110307790A1 (en) * 2010-06-14 2011-12-15 Alcatel-Lucent Canada, Inc. Extending revalidation-time of diameter sessions
US20110320544A1 (en) * 2010-06-29 2011-12-29 Alcatel-Lucent Canada, Inc. Diameter session audits
US20120036257A1 (en) * 2010-06-29 2012-02-09 Alcatel-Lucent Canada Inc. Diameter session audits
US20120224524A1 (en) * 2011-03-03 2012-09-06 Marsico Peter J Methods, systems, and computer readable media for enriching a diameter signaling message
US20120282955A1 (en) * 2011-05-06 2012-11-08 Tarek Abou-Assali Methods, systems, and computer readable media for providing a user record deletion notification
US8566474B2 (en) 2010-06-15 2013-10-22 Tekelec, Inc. Methods, systems, and computer readable media for providing dynamic origination-based routing key registration in a diameter network
CN103476022A (en) * 2012-06-08 2013-12-25 电信科学技术研究院 Method of determining user identification and informing the user identification, equipment and system thereof
US8644355B2 (en) 2010-12-23 2014-02-04 Tekelec, Inc. Methods, systems, and computer readable media for modifying a diameter signaling message directed to a charging function node
WO2014023327A1 (en) * 2012-08-06 2014-02-13 Telefonaktiebolaget L M Ericsson (Publ) Dynamic content filtering of data traffic in a communication network
US8737304B2 (en) 2011-03-01 2014-05-27 Tekelec, Inc. Methods, systems, and computer readable media for hybrid session based diameter routing
US20140153391A1 (en) * 2011-06-22 2014-06-05 Telefonaktiebolaget L M Ericsson (Publ) Method for Policy Control and Method for Bearer Control as Well as Corresponding Servers, Systems and Computer Programs
US8750126B2 (en) 2009-10-16 2014-06-10 Tekelec, Inc. Methods, systems, and computer readable media for multi-interface monitoring and correlation of diameter signaling information
US8813168B2 (en) 2008-06-05 2014-08-19 Tekelec, Inc. Methods, systems, and computer readable media for providing nested policy configuration in a communications network
US8825060B2 (en) 2011-03-01 2014-09-02 Tekelec, Inc. Methods, systems, and computer readable media for dynamically learning diameter binding information
US20140317300A1 (en) * 2011-09-29 2014-10-23 Telefonaktiebolaget L M Ericsson (Publ) Methods and Network Nodes for Controlling Resources of a Service Session as Well as Corresponding System and Computer Program
US8918469B2 (en) 2011-03-01 2014-12-23 Tekelec, Inc. Methods, systems, and computer readable media for sharing diameter binding data
US8942747B2 (en) 2011-02-04 2015-01-27 Tekelec, Inc. Methods, systems, and computer readable media for provisioning a diameter binding repository
US9059948B2 (en) 2004-12-17 2015-06-16 Tekelec, Inc. Methods, systems, and computer program products for clustering and communicating between internet protocol multimedia subsystem (IMS) entities and for supporting database access in an IMS network environment
US20150295723A1 (en) * 2012-10-01 2015-10-15 Orange Technique for Communication Between a Client Entity and a Packet Mode Data Network
US9237595B2 (en) 2014-02-20 2016-01-12 Oracle International Corporation Diameter based communication session discovery and recovery
US9319378B2 (en) 2013-01-23 2016-04-19 Tekelec, Inc. Methods, systems, and computer readable media for using a diameter routing agent (DRA) to obtain mappings between mobile subscriber identification information and dynamically assigned internet protocol (IP) addresses and for making the mappings accessible to applications
US9319318B2 (en) 2010-03-15 2016-04-19 Tekelec, Inc. Methods, systems, and computer readable media for performing PCRF-based user information pass through
US9668135B2 (en) 2015-08-14 2017-05-30 Oracle International Corporation Methods, systems, and computer readable media for providing access network signaling protocol interworking for user authentication
US9668134B2 (en) 2015-08-14 2017-05-30 Oracle International Corporation Methods, systems, and computer readable media for providing access network protocol interworking and authentication proxying
US9923984B2 (en) 2015-10-30 2018-03-20 Oracle International Corporation Methods, systems, and computer readable media for remote authentication dial in user service (RADIUS) message loop detection and mitigation
US10084755B2 (en) 2015-08-14 2018-09-25 Oracle International Corporation Methods, systems, and computer readable media for remote authentication dial in user service (RADIUS) proxy and diameter agent address resolution

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9185510B2 (en) 2010-03-03 2015-11-10 Tekelec, Inc. Methods, systems, and computer readable media for managing the roaming preferences of mobile subscribers
US9917700B2 (en) 2010-03-15 2018-03-13 Tekelec, Inc. Systems, methods, and computer readable media for policy enforcement correlation
US8812020B2 (en) 2010-10-15 2014-08-19 Tekelec, Inc. Methods, systems, and computer readable media for location-based policy enhancement
CN103493523B (en) 2011-03-18 2017-02-22 泰科来股份有限公司 The method based on the diameter of the guide, systems and apparatus for a mobile network access device
US9106769B2 (en) 2011-08-10 2015-08-11 Tekelec, Inc. Methods, systems, and computer readable media for congestion management in a diameter signaling network
WO2014014829A1 (en) 2012-07-14 2014-01-23 Tekelec, Inc. Methods, systems, and computer readable media for dynamically controlling congestion in a radio access network
US9473928B2 (en) 2012-07-14 2016-10-18 Tekelec, Inc. Methods, systems, and computer readable media for policy-based local breakout (LBO)
EP2875662B1 (en) * 2012-07-20 2017-12-27 Tekelec, Inc. Methods, systems and computer readable media for distributing policy rules to the mobile edge
US9241285B1 (en) 2012-08-10 2016-01-19 Sprint Communications Company L.P. PCRF/ANDSF interaction in a communication network
KR20160034370A (en) * 2013-07-24 2016-03-29 콘비다 와이어리스, 엘엘씨 Service domain charging systems and methods
CN104426837A (en) * 2013-08-20 2015-03-18 中兴通讯股份有限公司 Application specific packet filter method and device of file transfer protocol
US9313648B2 (en) 2013-09-09 2016-04-12 Sprint Communications Company L.P. Network selection support for wireless communication devices
US9451095B2 (en) * 2014-06-17 2016-09-20 Alcatel Lucent Charging in a software defined network

Citations (70)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6141686A (en) * 1998-03-13 2000-10-31 Deterministic Networks, Inc. Client-side application-classifier gathering network-traffic statistics and application and user names using extensible-service provider plugin for policy-based network control
US20020143914A1 (en) * 2001-03-29 2002-10-03 Cihula Joseph F. Network-aware policy deployment
US20020188562A1 (en) * 2001-06-07 2002-12-12 Yoichiro Igarashi Billing system, and device constituting same
US20030208523A1 (en) * 2002-05-01 2003-11-06 Srividya Gopalan System and method for static and dynamic load analyses of communication network
US6651101B1 (en) * 1998-12-04 2003-11-18 Cisco Technology, Inc. Method and apparatus for identifying network data traffic flows and for applying quality of service treatments to the flows
US6661780B2 (en) * 2001-12-07 2003-12-09 Nokia Corporation Mechanisms for policy based UMTS QoS and IP QoS management in mobile IP networks
US20040111519A1 (en) * 2002-12-04 2004-06-10 Guangrui Fu Access network dynamic firewall
US6880005B1 (en) * 2000-03-31 2005-04-12 Intel Corporation Managing policy rules in a network
US20050088977A1 (en) * 2000-12-14 2005-04-28 Nortel Networks Limited Dynamic virtual private network (VPN) tunnel quality of service (QoS) treatment
US20050122945A1 (en) * 2003-11-20 2005-06-09 Nokia Corporation Indication of service flow termination by network control to policy decision function
US20060013191A1 (en) * 2004-07-19 2006-01-19 Alan Kavanagh Method, security system control module and policy server for providing security in a packet-switched telecommunications system
US20060233101A1 (en) * 2005-04-13 2006-10-19 Luft Siegfried J Network element architecture for deep packet inspection
US20070004393A1 (en) * 2005-06-29 2007-01-04 Nokia Corporation System and method for automatic application profile and policy creation
US20070066286A1 (en) * 2005-08-31 2007-03-22 Tuija Hurtta Inter-access mobility and service control
US7209962B2 (en) * 2001-07-30 2007-04-24 International Business Machines Corporation System and method for IP packet filtering based on non-IP packet traffic attributes
US20070121812A1 (en) * 2005-11-22 2007-05-31 Samsung Electronics Co., Ltd. System and method for lawful intercept detection of call data and call content
US20070159976A1 (en) * 2003-12-31 2007-07-12 France Telecom Communications system, apparatus and method for providing mobility management information
US20070220251A1 (en) * 2006-03-06 2007-09-20 Rosenberg Jonathan D Establishing facets of a policy for a communication session
US20070226775A1 (en) * 2006-02-07 2007-09-27 Cisco Technology, Inc. System and Method for Enforcing Policy in a Communication Network
US20070242692A1 (en) * 1999-12-23 2007-10-18 Broadcom Corporation Apparatuses to utilize multiple protocols in a wireless communication system
US7289498B2 (en) * 2002-06-04 2007-10-30 Lucent Technologies Inc. Classifying and distributing traffic at a network node
US20070286117A1 (en) * 2006-03-24 2007-12-13 Srinivasan Balasubramanian Quality of service configuration for wireless communication
US20080046963A1 (en) * 2006-08-18 2008-02-21 Cisco Technology, Inc. System and method for implementing policy server based application interaction manager
US20080076388A1 (en) * 2004-07-15 2008-03-27 Alain Nochimowski Method and System for Processing a User's Identity
WO2008052744A2 (en) * 2006-10-30 2008-05-08 Nokia Corporation Processing of an emergency session in a wimax network
US20080120700A1 (en) * 2006-11-16 2008-05-22 Nokia Corporation Attachment solution for multi-access environments
US20080137541A1 (en) * 2006-12-07 2008-06-12 Kaitki Agarwal Providing dynamic changes to packet flows
US20080201772A1 (en) * 2007-02-15 2008-08-21 Maxim Mondaeev Method and Apparatus for Deep Packet Inspection for Network Intrusion Detection
US20080232376A1 (en) * 2007-03-23 2008-09-25 Huawei Technologies Co., Ltd. Control method, system and function entity for reporting bearer event of signaling ip flow
US20080276305A1 (en) * 2005-12-22 2008-11-06 Bce Inc. Systems, Methods and Computer-Readable Media for Regulating Remote Access to a Data Network
US20080313708A1 (en) * 2007-06-12 2008-12-18 Alcatel Lucent Data content matching
US20080316971A1 (en) * 2007-06-22 2008-12-25 Interdigital Technology Corporation Method and apparatus for resource management in handover operation
US20090089418A1 (en) * 2007-10-01 2009-04-02 Ebay Inc. Method and system to detect a network deficiency
US20090141625A1 (en) * 2007-07-05 2009-06-04 Rajat Ghai System and method for reducing latency in call setup and teardown
US20090177650A1 (en) * 2006-06-28 2009-07-09 Justus Petersson Method, communication system and collection controller allowing third party influence on the provision of a service to a user station
US20090196225A1 (en) * 2006-06-02 2009-08-06 Victor Manuel Avila Gonzalez Devices and method for guaranteeing quality of service per service data flow through the bearer layer
US7581249B2 (en) * 2003-11-14 2009-08-25 Enterasys Networks, Inc. Distributed intrusion response system
US20090222538A1 (en) * 2008-02-29 2009-09-03 Ntt Docomo, Inc Terminal function management server, communication system, and communication method
US20090227231A1 (en) * 2008-03-07 2009-09-10 Hu Q James Dynamic mobile service control deployment architecture
US20090228956A1 (en) * 2006-11-20 2009-09-10 Huawei Technologies Co., Ltd. System and charging control method of network convergence policy and charging control architecture
US20090285225A1 (en) * 2008-05-16 2009-11-19 Dahod Ashraf M Providing trigger based traffic management
US20090307028A1 (en) * 2006-02-06 2009-12-10 Mediakey Ltd. A method and a system for identifying potentially fraudulent customers in relation to electronic customer action based systems, and a computer program for performing said method
US20090323536A1 (en) * 2008-06-30 2009-12-31 Chengdu Huawei Symantec Technologies Co., Ltd. Method, device and system for network interception
US20100040047A1 (en) * 2006-06-20 2010-02-18 David Castellanos Zamora Loss of Signalling Bearer Transport
US20100039941A1 (en) * 2007-04-20 2010-02-18 Huawei Technologies Co., Ltd. Method, system and entity of realizing event detection
US20100048161A1 (en) * 2007-04-28 2010-02-25 Huawei Technologies Co., Ltd. Method, system and apparatuses thereof for realizing emergency communication service
US20100121960A1 (en) * 2008-06-05 2010-05-13 Camiant, Inc. Method and system for providing mobility management in network
US20100142373A1 (en) * 2008-12-09 2010-06-10 Qualcomm Incorporated Performing packet flow optimization with policy and charging control
US20100186064A1 (en) * 2007-09-30 2010-07-22 Shibi Huang Method and device for obtaining capabilities of policy and charging enforcement function
US20100185488A1 (en) * 2009-01-16 2010-07-22 Openet Research Limited Method and system for policy control in telecommunications services
US20100235877A1 (en) * 2009-03-12 2010-09-16 At&T Mobility Ii Llc Policy-based privacy protection in converged communication networks
US20110022722A1 (en) * 2008-03-25 2011-01-27 David Castellanos Zamora Policy and charging control architecture
US20110022702A1 (en) * 2009-07-24 2011-01-27 Camiant, Inc. Mechanism for detecting and reporting traffic/service to a pcrf
US20110041182A1 (en) * 2008-04-29 2011-02-17 John Stenfelt intrusion detection and notification
US7940683B2 (en) * 2008-02-29 2011-05-10 Alcatel Lucent In-bound mechanism that verifies end-to-end service configuration with application awareness
US20110111767A1 (en) * 2009-11-06 2011-05-12 Konstantin Livanos Method of call admission control for home femtocells
US20110167471A1 (en) * 2010-01-04 2011-07-07 Yusun Kim Riley Methods, systems, and computer readable media for providing group policy configuration in a communications network using a fake user
US20110170412A1 (en) * 2010-01-11 2011-07-14 Krishna Ramadas Radio access network load and condition aware traffic shaping control
US20110202653A1 (en) * 2010-02-12 2011-08-18 Yusun Kim Riley Methods, systems, and computer readable media for service detection over an rx interface
US20110219426A1 (en) * 2010-03-05 2011-09-08 Yusun Kim Methods, systems, and computer readable media for enhanced service detection and policy rule determination
US20110225306A1 (en) * 2010-03-15 2011-09-15 Mark Delsesto Methods, systems, and computer readable media for triggering a service node to initiate a session with a policy charging and rules function
US20110225309A1 (en) * 2010-03-15 2011-09-15 Yusun Kim Riley Methods, systems, and computer readable media for performing pcrf-based user information pass through
US20110296489A1 (en) * 2007-12-20 2011-12-01 Telefonaktiebolaget L M Ericsson (Publ) Selection of successive authentication methods
US8131831B1 (en) * 2006-09-19 2012-03-06 At&T Mobility Ii Llc Centralized policy management framework for telecommunication networks
US8146133B2 (en) * 2007-12-07 2012-03-27 Electronics And Telecommunications Research Institute Apparatus and method for managing P2P traffic
US20120084425A1 (en) * 2008-06-05 2012-04-05 Yusun Kim Riley Methods, systems, and computer readable media for providing nested policy configuration in a communications network
US8159941B2 (en) * 2008-08-28 2012-04-17 Alcatel Lucent In-band DPI media reservation modifications to RFC 3313
US20120144049A1 (en) * 2009-09-04 2012-06-07 Ana Maria Lopez Nieto Policy and/or charging control for a communication session
US8250646B2 (en) * 2007-09-27 2012-08-21 Huawei Technologies Co., Ltd. Method, system, and device for filtering packets
US8331229B1 (en) * 2006-12-15 2012-12-11 At&T Mobility Ii Llc Policy-enabled dynamic deep packet inspection for telecommunications networks

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001095208A1 (en) * 2000-06-02 2001-12-13 Iprint.Com, Inc. Integrated electronic shopping cart system and method
FR2857543B1 (en) 2003-07-08 2007-01-19 Cit Alcatel Using a communication network of facilities management system to manage network policy rules
FR2858900B1 (en) 2003-08-12 2006-01-06 Cit Alcatel Provision of services by resource reservation, within a network of communications management resources by policy rules
KR100813395B1 (en) 2004-09-24 2008-03-12 주식회사 케이티 System for monitoring remote servers based on instant messenger and method thereof
JP4516439B2 (en) * 2005-02-01 2010-08-04 富士通株式会社 Relay program, relay method and relay device
CN101379757B (en) 2006-02-07 2011-12-07 思科技术公司 Providing telephone service in a communication network as well as methods and systems implementation strategy
CN1937623A (en) 2006-10-18 2007-03-28 华为技术有限公司 Method and system for controlling network business
US20080263631A1 (en) 2007-03-16 2008-10-23 Qualcomm Incorporated User profile, policy, and pmip key distribution in a wireless communication network
EP1973070A1 (en) 2007-03-20 2008-09-24 Zonith Holding APS A method and system for automatic event monitoring and notification
KR100947740B1 (en) 2007-09-13 2010-03-17 주식회사 케이티 System and method for monitoring event in computing network and event management apparatus
WO2009051527A1 (en) 2007-10-16 2009-04-23 Telefonaktiebolaget Lm Ericsson (Publ) A method and system for enabling access policy and charging control
CA2708670C (en) 2007-12-27 2016-10-04 Redknee Inc. Policy-based communication system and method
US9146744B2 (en) 2008-05-06 2015-09-29 Oracle America, Inc. Store queue having restricted and unrestricted entries
US8467291B2 (en) 2008-06-10 2013-06-18 Telefonaktiebolaget Lm Ericsson (Publ) Policy control with predefined rules
US8005087B2 (en) 2008-09-16 2011-08-23 Alcatel Lucent Application-level processing for default LTE bearer
WO2010086013A1 (en) 2009-01-27 2010-08-05 Telefonaktiebolaget Lm Ericsson (Publ) Group session management for policy control
US8718075B2 (en) 2009-08-17 2014-05-06 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for adapting policy control
US8787174B2 (en) 2009-12-31 2014-07-22 Tekelec, Inc. Methods, systems, and computer readable media for condition-triggered policies

Patent Citations (77)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6141686A (en) * 1998-03-13 2000-10-31 Deterministic Networks, Inc. Client-side application-classifier gathering network-traffic statistics and application and user names using extensible-service provider plugin for policy-based network control
US6651101B1 (en) * 1998-12-04 2003-11-18 Cisco Technology, Inc. Method and apparatus for identifying network data traffic flows and for applying quality of service treatments to the flows
US20070242692A1 (en) * 1999-12-23 2007-10-18 Broadcom Corporation Apparatuses to utilize multiple protocols in a wireless communication system
US6880005B1 (en) * 2000-03-31 2005-04-12 Intel Corporation Managing policy rules in a network
US20050088977A1 (en) * 2000-12-14 2005-04-28 Nortel Networks Limited Dynamic virtual private network (VPN) tunnel quality of service (QoS) treatment
US20020143914A1 (en) * 2001-03-29 2002-10-03 Cihula Joseph F. Network-aware policy deployment
US20020188562A1 (en) * 2001-06-07 2002-12-12 Yoichiro Igarashi Billing system, and device constituting same
US7209962B2 (en) * 2001-07-30 2007-04-24 International Business Machines Corporation System and method for IP packet filtering based on non-IP packet traffic attributes
US6661780B2 (en) * 2001-12-07 2003-12-09 Nokia Corporation Mechanisms for policy based UMTS QoS and IP QoS management in mobile IP networks
US20030208523A1 (en) * 2002-05-01 2003-11-06 Srividya Gopalan System and method for static and dynamic load analyses of communication network
US7289498B2 (en) * 2002-06-04 2007-10-30 Lucent Technologies Inc. Classifying and distributing traffic at a network node
US20040111519A1 (en) * 2002-12-04 2004-06-10 Guangrui Fu Access network dynamic firewall
US7581249B2 (en) * 2003-11-14 2009-08-25 Enterasys Networks, Inc. Distributed intrusion response system
US20050122945A1 (en) * 2003-11-20 2005-06-09 Nokia Corporation Indication of service flow termination by network control to policy decision function
US20070159976A1 (en) * 2003-12-31 2007-07-12 France Telecom Communications system, apparatus and method for providing mobility management information
US20080076388A1 (en) * 2004-07-15 2008-03-27 Alain Nochimowski Method and System for Processing a User's Identity
US20060013191A1 (en) * 2004-07-19 2006-01-19 Alan Kavanagh Method, security system control module and policy server for providing security in a packet-switched telecommunications system
US20060233101A1 (en) * 2005-04-13 2006-10-19 Luft Siegfried J Network element architecture for deep packet inspection
US7719966B2 (en) * 2005-04-13 2010-05-18 Zeugma Systems Inc. Network element architecture for deep packet inspection
US20070004393A1 (en) * 2005-06-29 2007-01-04 Nokia Corporation System and method for automatic application profile and policy creation
US20070066286A1 (en) * 2005-08-31 2007-03-22 Tuija Hurtta Inter-access mobility and service control
US20070121812A1 (en) * 2005-11-22 2007-05-31 Samsung Electronics Co., Ltd. System and method for lawful intercept detection of call data and call content
US20080276305A1 (en) * 2005-12-22 2008-11-06 Bce Inc. Systems, Methods and Computer-Readable Media for Regulating Remote Access to a Data Network
US20090307028A1 (en) * 2006-02-06 2009-12-10 Mediakey Ltd. A method and a system for identifying potentially fraudulent customers in relation to electronic customer action based systems, and a computer program for performing said method
US20070226775A1 (en) * 2006-02-07 2007-09-27 Cisco Technology, Inc. System and Method for Enforcing Policy in a Communication Network
US8042148B2 (en) * 2006-02-07 2011-10-18 Cisco Technology, Inc. System and method for enforcing policy in a communication network
US20070220251A1 (en) * 2006-03-06 2007-09-20 Rosenberg Jonathan D Establishing facets of a policy for a communication session
US20070286117A1 (en) * 2006-03-24 2007-12-13 Srinivasan Balasubramanian Quality of service configuration for wireless communication
US20090196225A1 (en) * 2006-06-02 2009-08-06 Victor Manuel Avila Gonzalez Devices and method for guaranteeing quality of service per service data flow through the bearer layer
US20100040047A1 (en) * 2006-06-20 2010-02-18 David Castellanos Zamora Loss of Signalling Bearer Transport
US20090177650A1 (en) * 2006-06-28 2009-07-09 Justus Petersson Method, communication system and collection controller allowing third party influence on the provision of a service to a user station
US20080046963A1 (en) * 2006-08-18 2008-02-21 Cisco Technology, Inc. System and method for implementing policy server based application interaction manager
US8131831B1 (en) * 2006-09-19 2012-03-06 At&T Mobility Ii Llc Centralized policy management framework for telecommunication networks
WO2008052744A2 (en) * 2006-10-30 2008-05-08 Nokia Corporation Processing of an emergency session in a wimax network
US20080120700A1 (en) * 2006-11-16 2008-05-22 Nokia Corporation Attachment solution for multi-access environments
US20090228956A1 (en) * 2006-11-20 2009-09-10 Huawei Technologies Co., Ltd. System and charging control method of network convergence policy and charging control architecture
US20080137541A1 (en) * 2006-12-07 2008-06-12 Kaitki Agarwal Providing dynamic changes to packet flows
US8331229B1 (en) * 2006-12-15 2012-12-11 At&T Mobility Ii Llc Policy-enabled dynamic deep packet inspection for telecommunications networks
US20080201772A1 (en) * 2007-02-15 2008-08-21 Maxim Mondaeev Method and Apparatus for Deep Packet Inspection for Network Intrusion Detection
US20080232376A1 (en) * 2007-03-23 2008-09-25 Huawei Technologies Co., Ltd. Control method, system and function entity for reporting bearer event of signaling ip flow
US20100039941A1 (en) * 2007-04-20 2010-02-18 Huawei Technologies Co., Ltd. Method, system and entity of realizing event detection
US20100048161A1 (en) * 2007-04-28 2010-02-25 Huawei Technologies Co., Ltd. Method, system and apparatuses thereof for realizing emergency communication service
US20080313708A1 (en) * 2007-06-12 2008-12-18 Alcatel Lucent Data content matching
US20080316971A1 (en) * 2007-06-22 2008-12-25 Interdigital Technology Corporation Method and apparatus for resource management in handover operation
US20090141625A1 (en) * 2007-07-05 2009-06-04 Rajat Ghai System and method for reducing latency in call setup and teardown
US8250646B2 (en) * 2007-09-27 2012-08-21 Huawei Technologies Co., Ltd. Method, system, and device for filtering packets
US20100186064A1 (en) * 2007-09-30 2010-07-22 Shibi Huang Method and device for obtaining capabilities of policy and charging enforcement function
US20090089418A1 (en) * 2007-10-01 2009-04-02 Ebay Inc. Method and system to detect a network deficiency
US8146133B2 (en) * 2007-12-07 2012-03-27 Electronics And Telecommunications Research Institute Apparatus and method for managing P2P traffic
US20110296489A1 (en) * 2007-12-20 2011-12-01 Telefonaktiebolaget L M Ericsson (Publ) Selection of successive authentication methods
US20090222538A1 (en) * 2008-02-29 2009-09-03 Ntt Docomo, Inc Terminal function management server, communication system, and communication method
US7940683B2 (en) * 2008-02-29 2011-05-10 Alcatel Lucent In-bound mechanism that verifies end-to-end service configuration with application awareness
US20090227231A1 (en) * 2008-03-07 2009-09-10 Hu Q James Dynamic mobile service control deployment architecture
US20110022722A1 (en) * 2008-03-25 2011-01-27 David Castellanos Zamora Policy and charging control architecture
US20110041182A1 (en) * 2008-04-29 2011-02-17 John Stenfelt intrusion detection and notification
US20090285225A1 (en) * 2008-05-16 2009-11-19 Dahod Ashraf M Providing trigger based traffic management
US8433794B2 (en) * 2008-06-05 2013-04-30 Camiant, Inc. Method and system for providing mobility management in network
US20120084425A1 (en) * 2008-06-05 2012-04-05 Yusun Kim Riley Methods, systems, and computer readable media for providing nested policy configuration in a communications network
US20120131165A1 (en) * 2008-06-05 2012-05-24 Uri Baniel Method and system for providing mobility management in network
US20100121960A1 (en) * 2008-06-05 2010-05-13 Camiant, Inc. Method and system for providing mobility management in network
US8595368B2 (en) * 2008-06-05 2013-11-26 Camiant, Inc. Method and system for providing mobility management in a network
US20090323536A1 (en) * 2008-06-30 2009-12-31 Chengdu Huawei Symantec Technologies Co., Ltd. Method, device and system for network interception
US8159941B2 (en) * 2008-08-28 2012-04-17 Alcatel Lucent In-band DPI media reservation modifications to RFC 3313
US20100142373A1 (en) * 2008-12-09 2010-06-10 Qualcomm Incorporated Performing packet flow optimization with policy and charging control
US20100185488A1 (en) * 2009-01-16 2010-07-22 Openet Research Limited Method and system for policy control in telecommunications services
US20100235877A1 (en) * 2009-03-12 2010-09-16 At&T Mobility Ii Llc Policy-based privacy protection in converged communication networks
US8429268B2 (en) * 2009-07-24 2013-04-23 Camiant, Inc. Mechanism for detecting and reporting traffic/service to a PCRF
US20110022702A1 (en) * 2009-07-24 2011-01-27 Camiant, Inc. Mechanism for detecting and reporting traffic/service to a pcrf
US20120144049A1 (en) * 2009-09-04 2012-06-07 Ana Maria Lopez Nieto Policy and/or charging control for a communication session
US20110111767A1 (en) * 2009-11-06 2011-05-12 Konstantin Livanos Method of call admission control for home femtocells
US20110167471A1 (en) * 2010-01-04 2011-07-07 Yusun Kim Riley Methods, systems, and computer readable media for providing group policy configuration in a communications network using a fake user
US20110170412A1 (en) * 2010-01-11 2011-07-14 Krishna Ramadas Radio access network load and condition aware traffic shaping control
US20110202653A1 (en) * 2010-02-12 2011-08-18 Yusun Kim Riley Methods, systems, and computer readable media for service detection over an rx interface
US20110219426A1 (en) * 2010-03-05 2011-09-08 Yusun Kim Methods, systems, and computer readable media for enhanced service detection and policy rule determination
US8458767B2 (en) * 2010-03-05 2013-06-04 Tekelec, Inc. Methods, systems, and computer readable media for enhanced service detection and policy rule determination
US20110225309A1 (en) * 2010-03-15 2011-09-15 Yusun Kim Riley Methods, systems, and computer readable media for performing pcrf-based user information pass through
US20110225306A1 (en) * 2010-03-15 2011-09-15 Mark Delsesto Methods, systems, and computer readable media for triggering a service node to initiate a session with a policy charging and rules function

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
3GPP, 3rd Generation Partnership Project, Policy and Charging Control over Gx reference point (Release 8), May 2008 *

Cited By (81)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9288169B2 (en) 2004-12-17 2016-03-15 Tekelec, Inc. Methods, systems, and computer program products for clustering and communicating between internet protocol multimedia subsystem (IMS) entities and for supporting database access in an IMS network environment
US9059948B2 (en) 2004-12-17 2015-06-16 Tekelec, Inc. Methods, systems, and computer program products for clustering and communicating between internet protocol multimedia subsystem (IMS) entities and for supporting database access in an IMS network environment
US8433794B2 (en) 2008-06-05 2013-04-30 Camiant, Inc. Method and system for providing mobility management in network
US20100121960A1 (en) * 2008-06-05 2010-05-13 Camiant, Inc. Method and system for providing mobility management in network
US8595368B2 (en) 2008-06-05 2013-11-26 Camiant, Inc. Method and system for providing mobility management in a network
US8813168B2 (en) 2008-06-05 2014-08-19 Tekelec, Inc. Methods, systems, and computer readable media for providing nested policy configuration in a communications network
US8429268B2 (en) 2009-07-24 2013-04-23 Camiant, Inc. Mechanism for detecting and reporting traffic/service to a PCRF
US20110022702A1 (en) * 2009-07-24 2011-01-27 Camiant, Inc. Mechanism for detecting and reporting traffic/service to a pcrf
US8750126B2 (en) 2009-10-16 2014-06-10 Tekelec, Inc. Methods, systems, and computer readable media for multi-interface monitoring and correlation of diameter signaling information
US8640188B2 (en) 2010-01-04 2014-01-28 Tekelec, Inc. Methods, systems, and computer readable media for providing group policy configuration in a communications network using a fake user
US20110167471A1 (en) * 2010-01-04 2011-07-07 Yusun Kim Riley Methods, systems, and computer readable media for providing group policy configuration in a communications network using a fake user
US20110165901A1 (en) * 2010-01-04 2011-07-07 Uri Baniel Methods, systems, and computer readable media for policy charging and rules function (pcrf) node selection
US8615237B2 (en) 2010-01-04 2013-12-24 Tekelec, Inc. Methods, systems, and computer readable media for policy and charging rules function (PCRF) node selection
US8578050B2 (en) 2010-02-12 2013-11-05 Tekelec, Inc. Methods, systems, and computer readable media for providing peer routing at a diameter node
US20110202613A1 (en) * 2010-02-12 2011-08-18 Jeffrey Alan Craig Methods, systems, and computer readable media for answer-based routing of diameter request messages
US9166803B2 (en) 2010-02-12 2015-10-20 Tekelec, Inc. Methods, systems, and computer readable media for service detection over an RX interface
US9088478B2 (en) 2010-02-12 2015-07-21 Tekelec, Inc. Methods, systems, and computer readable media for inter-message processor status sharing
US20110202676A1 (en) * 2010-02-12 2011-08-18 Jeffrey Alan Craig Methods, systems, and computer readable media for providing peer routing at a diameter node
US8996636B2 (en) 2010-02-12 2015-03-31 Tekelec, Inc. Methods, systems, and computer readable media for answer-based routing of diameter request messages
US8995256B2 (en) 2010-02-12 2015-03-31 Tekelec, Inc. Methods, systems, and computer readable media for performing diameter answer message-based network management at a diameter signaling router (DSR)
US20110200047A1 (en) * 2010-02-12 2011-08-18 Mccann Thomas M Methods, systems, and computer readable media for diameter protocol harmonization
US8799391B2 (en) 2010-02-12 2014-08-05 Tekelec, Inc. Methods, systems, and computer readable media for inter-diameter-message processor routing
US8792329B2 (en) 2010-02-12 2014-07-29 Tekelec, Inc. Methods, systems, and computer readable media for performing diameter answer message-based network management at a diameter signaling router (DSR)
US8483233B2 (en) 2010-02-12 2013-07-09 Tekelec, Inc. Methods, systems, and computer readable media for providing local application routing at a diameter node
US8644324B2 (en) 2010-02-12 2014-02-04 Tekelec, Inc. Methods, systems, and computer readable media for providing priority routing at a diameter node
US20110202612A1 (en) * 2010-02-12 2011-08-18 Jeffrey Alan Craig Methods, systems, and computer readable media for providing origin routing at a diameter node
US20110199906A1 (en) * 2010-02-12 2011-08-18 Mark Edward Kanode Methods, systems, and computer readable media for performing diameter answer message-based network management at a diameter signaling router (dsr)
US20110202653A1 (en) * 2010-02-12 2011-08-18 Yusun Kim Riley Methods, systems, and computer readable media for service detection over an rx interface
US20110202614A1 (en) * 2010-02-12 2011-08-18 Jeffrey Alan Graig Methods, systems, and computer readable media for diameter application loop prevention
US8478828B2 (en) 2010-02-12 2013-07-02 Tekelec, Inc. Methods, systems, and computer readable media for inter-diameter-message processor routing
US20110200054A1 (en) * 2010-02-12 2011-08-18 Jeffrey Alan Craig Methods, systems, and computer readable media for providing local application routing at a diameter node
US8498202B2 (en) 2010-02-12 2013-07-30 Tekelec, Inc. Methods, systems, and computer readable media for diameter network management
US8504630B2 (en) 2010-02-12 2013-08-06 Tekelec, Inc. Methods, systems, and computer readable media for diameter application loop prevention
US8527598B2 (en) 2010-02-12 2013-09-03 Tekelec, Inc. Methods, systems, and computer readable media for answer-based routing of diameter request messages
US8532110B2 (en) 2010-02-12 2013-09-10 Tekelec, Inc. Methods, systems, and computer readable media for diameter protocol harmonization
US8601073B2 (en) 2010-02-12 2013-12-03 Tekelec, Inc. Methods, systems, and computer readable media for source peer capacity-based diameter load sharing
US20110202684A1 (en) * 2010-02-12 2011-08-18 Jeffrey Alan Craig Methods, systems, and computer readable media for inter-diameter-message processor routing
US8554928B2 (en) 2010-02-12 2013-10-08 Tekelec, Inc. Methods, systems, and computer readable media for providing origin routing at a diameter node
US20110202604A1 (en) * 2010-02-12 2011-08-18 Jeffrey Alan Craig Methods, systems, and computer readable media for source peer capacity-based diameter load sharing
US8458767B2 (en) 2010-03-05 2013-06-04 Tekelec, Inc. Methods, systems, and computer readable media for enhanced service detection and policy rule determination
US20110219426A1 (en) * 2010-03-05 2011-09-08 Yusun Kim Methods, systems, and computer readable media for enhanced service detection and policy rule determination
US20110225306A1 (en) * 2010-03-15 2011-09-15 Mark Delsesto Methods, systems, and computer readable media for triggering a service node to initiate a session with a policy charging and rules function
US9603058B2 (en) 2010-03-15 2017-03-21 Tekelec, Inc. Methods, systems, and computer readable media for triggering a service node to initiate a session with a policy and charging rules function
US9319318B2 (en) 2010-03-15 2016-04-19 Tekelec, Inc. Methods, systems, and computer readable media for performing PCRF-based user information pass through
US20110282981A1 (en) * 2010-05-11 2011-11-17 Alcatel-Lucent Canada Inc. Behavioral rule results
US8468395B2 (en) * 2010-06-07 2013-06-18 Alcatel Lucent Framework for managing failures in outbound messages
US8352803B2 (en) * 2010-06-07 2013-01-08 Alcatel Lucent Framework for managing failures in outbound messages
US20110302458A1 (en) * 2010-06-07 2011-12-08 Alcatel-Lucent Canada, Inc. Framework for managing failures in outbound messages
US20120324297A1 (en) * 2010-06-07 2012-12-20 Alcatel-Lucent Canada, Inc. Framework for managing failures in outbound messages
US8751876B2 (en) 2010-06-07 2014-06-10 Alcatel Lucent Framework for managing failures in outbound messages
US20110307790A1 (en) * 2010-06-14 2011-12-15 Alcatel-Lucent Canada, Inc. Extending revalidation-time of diameter sessions
US8825874B2 (en) * 2010-06-14 2014-09-02 Alcatel Lucent Extending revalidation-time of diameter sessions
US8566474B2 (en) 2010-06-15 2013-10-22 Tekelec, Inc. Methods, systems, and computer readable media for providing dynamic origination-based routing key registration in a diameter network
US20110320544A1 (en) * 2010-06-29 2011-12-29 Alcatel-Lucent Canada, Inc. Diameter session audits
US20120036257A1 (en) * 2010-06-29 2012-02-09 Alcatel-Lucent Canada Inc. Diameter session audits
US8539033B2 (en) * 2010-06-29 2013-09-17 Alcatel Lucent Diameter session audits
US8644355B2 (en) 2010-12-23 2014-02-04 Tekelec, Inc. Methods, systems, and computer readable media for modifying a diameter signaling message directed to a charging function node
US8942747B2 (en) 2011-02-04 2015-01-27 Tekelec, Inc. Methods, systems, and computer readable media for provisioning a diameter binding repository
US8825060B2 (en) 2011-03-01 2014-09-02 Tekelec, Inc. Methods, systems, and computer readable media for dynamically learning diameter binding information
US8737304B2 (en) 2011-03-01 2014-05-27 Tekelec, Inc. Methods, systems, and computer readable media for hybrid session based diameter routing
US8918469B2 (en) 2011-03-01 2014-12-23 Tekelec, Inc. Methods, systems, and computer readable media for sharing diameter binding data
US20120224524A1 (en) * 2011-03-03 2012-09-06 Marsico Peter J Methods, systems, and computer readable media for enriching a diameter signaling message
US8547908B2 (en) * 2011-03-03 2013-10-01 Tekelec, Inc. Methods, systems, and computer readable media for enriching a diameter signaling message
US20120282955A1 (en) * 2011-05-06 2012-11-08 Tarek Abou-Assali Methods, systems, and computer readable media for providing a user record deletion notification
US9172822B2 (en) * 2011-05-06 2015-10-27 Tekelec, Inc. Methods, systems, and computer readable media for providing a user record deletion notification
US9148524B2 (en) 2011-05-06 2015-09-29 Tekelec, Inc. Methods, systems, and computer readable media for caching call session control function (CSCF) data at a diameter signaling router (DSR)
US20140153391A1 (en) * 2011-06-22 2014-06-05 Telefonaktiebolaget L M Ericsson (Publ) Method for Policy Control and Method for Bearer Control as Well as Corresponding Servers, Systems and Computer Programs
US20140317300A1 (en) * 2011-09-29 2014-10-23 Telefonaktiebolaget L M Ericsson (Publ) Methods and Network Nodes for Controlling Resources of a Service Session as Well as Corresponding System and Computer Program
JP2014534706A (en) * 2011-10-18 2014-12-18 アルカテル−ルーセント Diameter session audit
CN103476022A (en) * 2012-06-08 2013-12-25 电信科学技术研究院 Method of determining user identification and informing the user identification, equipment and system thereof
WO2014023327A1 (en) * 2012-08-06 2014-02-13 Telefonaktiebolaget L M Ericsson (Publ) Dynamic content filtering of data traffic in a communication network
US20150215186A1 (en) * 2012-08-06 2015-07-30 Telefonaktiebolaget Lm Ericsson (Publ) Dynamic content filtering of data traffic in a communication network
US20150295723A1 (en) * 2012-10-01 2015-10-15 Orange Technique for Communication Between a Client Entity and a Packet Mode Data Network
US9319378B2 (en) 2013-01-23 2016-04-19 Tekelec, Inc. Methods, systems, and computer readable media for using a diameter routing agent (DRA) to obtain mappings between mobile subscriber identification information and dynamically assigned internet protocol (IP) addresses and for making the mappings accessible to applications
US9237595B2 (en) 2014-02-20 2016-01-12 Oracle International Corporation Diameter based communication session discovery and recovery
US9668135B2 (en) 2015-08-14 2017-05-30 Oracle International Corporation Methods, systems, and computer readable media for providing access network signaling protocol interworking for user authentication
US10084755B2 (en) 2015-08-14 2018-09-25 Oracle International Corporation Methods, systems, and computer readable media for remote authentication dial in user service (RADIUS) proxy and diameter agent address resolution
US9668134B2 (en) 2015-08-14 2017-05-30 Oracle International Corporation Methods, systems, and computer readable media for providing access network protocol interworking and authentication proxying
US9918229B2 (en) 2015-08-14 2018-03-13 Oracle International Corporation Methods, systems, and computer readable media for providing access network protocol interworking and authentication proxying
US9930528B2 (en) 2015-08-14 2018-03-27 Oracle International Corporation Methods, systems, and computer readable media for providing access network signaling protocol interworking for user authentication
US9923984B2 (en) 2015-10-30 2018-03-20 Oracle International Corporation Methods, systems, and computer readable media for remote authentication dial in user service (RADIUS) message loop detection and mitigation

Also Published As

Publication number Publication date Type
US20110225306A1 (en) 2011-09-15 application
CN102893640B (en) 2016-03-23 grant
CN102893640A (en) 2013-01-23 application
US9603058B2 (en) 2017-03-21 grant
EP2548388A4 (en) 2017-08-02 application
EP2548388A2 (en) 2013-01-23 application
WO2011115991A3 (en) 2011-12-22 application
WO2011115991A2 (en) 2011-09-22 application

Similar Documents

Publication Publication Date Title
US20140003225A1 (en) Dynamic reaction to diameter routing failures
US20120099715A1 (en) Methods, systems, and computer readable media for diameter routing agent (dra) based credit status triggered policy control
US20110126277A1 (en) Methods, systems, and computer readable media for providing diameter signaling router with firewall functionality
US20110199903A1 (en) Method for pcrf to autonomously respond to cell capacity shortage
US20090307746A1 (en) Method, system and device for implementing security control
US20110173332A1 (en) Method and system for implementing policy and charging control in multi-pdn scenario
US8331229B1 (en) Policy-enabled dynamic deep packet inspection for telecommunications networks
US20110225281A1 (en) Systems, methods, and computer readable media for policy enforcement correlation
US20110158090A1 (en) Methods, systems, and computer readable media for condition-triggered policies
US20120100849A1 (en) Methods, systems, and computer readable media for selective policy enhancement (pe) for high-usage roamers
US20110219426A1 (en) Methods, systems, and computer readable media for enhanced service detection and policy rule determination
US20110320620A1 (en) Method of authorizing af sessions using external subscriber database
US20120094685A1 (en) Methods, systems, and computer readable media for location-based policy enhancement
US20110320622A1 (en) Managing internet protocol connectivity access network sessions
US20110307790A1 (en) Extending revalidation-time of diameter sessions
US20110225309A1 (en) Methods, systems, and computer readable media for performing pcrf-based user information pass through
US20130041994A1 (en) Methods, systems, and computer readable media for policy event record generation
WO2010066295A1 (en) Token-based correlation of control sessions for policy and charging control of a data session through a nat
US20120117220A1 (en) Packet Classification Method And Apparatus
US20110317558A1 (en) Method and system for generating pcc rules based on service requests
US20120087262A1 (en) Method, Apparatus and System for Detecting Service Data of a Packet Data Connection
US20130188554A1 (en) Offline charging per service data flow
US20110225306A1 (en) Methods, systems, and computer readable media for triggering a service node to initiate a session with a policy charging and rules function
US20120221693A1 (en) Temporary restrictions and rollback
US20110202653A1 (en) Methods, systems, and computer readable media for service detection over an rx interface

Legal Events

Date Code Title Description
AS Assignment

Owner name: TEKELEC, NORTH CAROLINA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:DELSESTO, MARK;MERCURIO, MICHAEL;ABOU-ASSALI, TAREK;AND OTHERS;SIGNING DATES FROM 20110322 TO 20110516;REEL/FRAME:026413/0404

AS Assignment

Owner name: WILMINGTON TRUST, NATIONAL ASSOCIATION, MINNESOTA

Free format text: SECURITY INTEREST;ASSIGNORS:TEKELEC;CAMIANT, INC.;REEL/FRAME:028035/0659

Effective date: 20120127

AS Assignment

Owner name: TEKELEC GLOBAL, INC., NORTH CAROLINA

Free format text: CHANGE OF NAME;ASSIGNOR:TEKELEC;REEL/FRAME:028078/0287

Effective date: 20120130

AS Assignment

Owner name: TEKELEC, INC., NORTH CAROLINA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:TEKELEC GLOBAL, INC.;REEL/FRAME:028184/0119

Effective date: 20120427