GPP X.S00-0-0 Version.0 Date: December 0 All-IP Core Network Multimedia Domain Service Based Bearer Control Ty Interface Stage COPYRIGHT NOTICE GPP and its Organizational Partners claim copyright in this document and individual Organizational Partners may copyright and issue documents or standards publications in individual Organizational Partner's name based on this document. Requests for reproduction of this document should be directed to the GPP Secretariat at secretariat@gpp.org. Requests to reproduce individual Organizational Partner's documents should be directed to that Organizational Partner. See www.gpp.org for more information.
0 0 0 This page intentionally left blank.
X.S00-0-0 v.0 0 0 0 Contents Contents...i List of Tables... iii Foreword...iv Revision History...v Introduction... References.... Normative References.... Informative References... Definitions, symbols and abbreviations.... Definitions.... Symbols.... Abbreviations... Void... Diameter based Ty.... Procedures for Diameter based Ty Interface..... Initialization and maintenance of connection..... Request for PCC rules from the AGW..... Provision of authorized QoS or charging rules from the PCRF...... Selecting a PCC rule for Uplink IP packets...... Selecting a PCC rule and IP-CAN Bearer for Downlink IP packets...... Gate function...... Policy enforcement for "Authorized QoS" per PCC Rule..... Provision of event triggers from the PCRF..... Provision of charging addresses from the PCRF..... Provisioning of Authorized QoS..... Indication of IP flow termination (from AGW to PCRF)..... Indication of IP-CAN session termination (from AGW to PCRF)..... Request of IP-CAN session termination (from PCRF to AGW)..... Request of IP flow termination (from PCRF to AGW)..... PCC Rule Error Handling.... Diameter Protocol..... Ty Diameter messages...... CC-Request (CCR) Command...... CC-Answer (CCA) Command...... Re-Auth-Request (RAR) Command...... Re-Auth-Answer (RAA) Command...... Experimental-Result/Experimental-Result-Code AVP Values...... Experimental-Result AVP Format..... Ty specific Diameter AVPs...... Flow-Operation AVP...... Charging-Rule-Install AVP...... Charging-Rule-Remove AVP...... Charging-Rule-Definition AVP...... Charging-Rule-Base-Name AVP...... Charging-Rule-Name AVP...... Event-Trigger AVP...... Metering-Method AVP...... Offline AVP...... Online AVP...... Precedence AVP... i
X.S00-0-0 v.0... Reporting-Level AVP...... Void...... Void...... Void...... QoS-Information AVP...... QoS-Class-Identifier AVP (All access types)...... Charging-Rule-Report AVP (All access types)...... AGW-IP-Address AVP...... AGW-IPv-Address AVP...... RAT-Type AVP...... Flow-Info AVP...... Flow-Identifier AVP...... PCC-Rule-Status AVP...... Granted-QoS AVP...... Requested-QoS AVP...... Guaranteed-Bitrate-UL AVP...... Guaranteed-Bitrate-DL AVP...... Access-Network-Charging-Identifier-Ty AVP......0 Flow-Description-Info AVP...... Rule-Reason-Code AVP...... AGW-MCC-MNC AVP..... Ty re-used AVPs..... Ty specific Experimental-Result-Code AVP values...... Success...... Permanent Failures... 0 0 0 ii
X.S00-0-0 v.0 0 0 0 List of Tables Table.-: Ty Specific GPP Diameter AVPs... Table.-: Ty Specific GPP Diameter AVPs... Table.: QCI to QoS parameters mapping... Table.: Ty re-used Diameter AVPs... iii
X.S00-0-0 v.0 Foreword (This foreword is not part of this document). This document was prepared by GPP TSG-X. This document contains major modifications from the previous revision. This document is part of the series of documents X.S00. This document contains portions of material copied from GPP document number TS.. The copyright on the GPP document is owned by the Organizational Partners of GPP (ARIB - Association of Radio Industries and Businesses, Japan; ; CCSA China Communications Standards Association, China; ETSI European Telecommunications Standards Institute; ATIS Alliance for Telecommunication Industry Solutions, USA; TTA - Telecommunications Technology Association, Korea; and TTC Telecommunication Technology Committee, Japan), which have granted license for reproduction and for use by GPP and its Organizational Partners. 0 0 0 iv
X.S00-0-0 v.0 0 0 0 Revision History Revision Content Changes Date.0 Initial publication. December 0 v
X.S00-0-0 v.0 0 0 0 vi This page intentionally left blank.
X.S00-0-0 v.0 0 0 0 Introduction This document addresses the Stage- protocol between an Access Gateway (AGW) and a Policy and Charging Rules Function (PCRF) in support of Service Based Bearer Control as described in [X.S00-0]. The reference point between the AGW and the PCRF is designated as the Ty reference point and supports all cdma00 radio technologies.. The protocol between the PCRF and the AGW enables the PCRF to dynamically control policy and charging behavior at the AGW. The protocol allows: Interactions for the purpose of local authorization of bearer level QoS resources based on the resources negotiated at the application layer and/or based on local policy. In addition it supports the passing of information that may be used to establish flow based charging policy. Features of the protocol include the following:. Provision and removal of rules from the PCRF to the AGW;. Request for Policy and Charging Control (PCC) rules from the AGW to the PCRF;. Notification of bearer level events from the AGW to the PCRF;. Control of the flow of packets at the bearer level including the restriction of flow end-points (flow filtering); and. Support of general policy considerations for the allocation of resources on the bearer level in the local domain. cdma00 is the trademark for the technical nomenclature for certain specifications and standards of the Organizational Partners (OPs) of GPP. Geographically (and as of the date of publication), cdma00 is a registered trademark of the Telecommunications Industry Association (TIA-USA) in the United States.
X.S00-0-0 v.0 References The following documents contain provisions, which through reference in this text, constitute provisions of the present document. References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific. For a specific reference, subsequent revisions do not apply. For a non-specific reference, the latest version applies.. Normative References [RFC] [RFC00] [RFC00] [X.S00-00] IETF RFC : "Diameter Base Protocol". IETF RFC 00: "Diameter Network Access Server Application". IETF RFC 00: "Diameter Credit Control Application". GPP X.S00-00, "Cx Interface based on the Diameter Protocol; Protocol Details. [X.S00-0] GPP X.S00-0: Service Based Bearer Control Stage. [X.S00-0] GPP X.S00-0, "Service Based Bearer Control Stage- for Tx Interface".. Informative References [C.R0] [E.] GPP C.R0, Administration of Parameter Value Assignments for cdma00 Spread Spectrum Standards. ITU-T Recommendation E., The International Identification Plan for Mobile Terminals and Mobile Users. 0 0 0
X.S00-0-0 v.0 0 0 0 Definitions, symbols and abbreviations. Definitions Application Function: The Application Function is the element that requests the application of restrictions on the use of bearer resources. One example of an application function is the P-CSCF. The Application Function represents the application level intelligence for any service running over the IP bearer, which needs Service Based Authorization. Policy and Charging Control Rule: This term refers to a rule provided by the PCRF to the AGW over the Ty reference point. The purpose of the PCC rule is to: - Provide detection information for a packet belonging to a service data flow, - Provide policy control for a service data flow, and to - Provide applicable charging parameters for a service data flow. Service Based Authorization: This term refers to the authorization of use of bearer resources in the access network based on a determination by the application, possibly due to negotiation involving the user. In general, bearer resources may be authorized if the resources requested at the bearer do not exceed the resources negotiated or requested at the service level. Service Based Policy: This term refers to the instantiation of a policy for use of bearer resources in the access network based on Authorization by a service. Subscription Based Authorization: This term refers to the authorization of use of bearer resources in the access network based on a user s subscription with the operator. Subscription Based Policy: This term refers to the instantiation of a policy for use of bearer resources in the access network based on a users subscription.. Symbols For the purposes of the present document the following symbols apply: Tx Ty The reference point between an AF and a PCRF The reference point between a PCRF and an AGW. Abbreviations For the purposes of the present document the following abbreviations apply. AAA AAA AAR AF AGW Authentication, Authorization, and Accounting AA-Answer AA-Request Application Function Access Gateway
X.S00-0-0 v.0 AVP Attribute-Value Pair IANA Internet Assigned Numbers Authority IMS IP Multimedia Subsystem IP-CAN IP Connectivity Access Network MMD Multimedia Domain OCS Online Charging Server PCC Policy and Charging Control PCRF Policy and Charging Rules Function QoS Quality of Service RAA Re-Auth-Answer RAN Radio Access Network RAR Re-Auth-Request SBBC Service Based Bearer Control 0 0 0
X.S00-0-0 v.0 0 0 0 Void
X.S00-0-0 v.0 Diameter based Ty. Procedures for Diameter based Ty Interface.. Initialization and maintenance of connection The initialization and maintenance of the connection between a PCRF and AGW is defined by the underlying protocol. Establishment and maintenance of connections between Diameter nodes are described in [RFC ]. The AGW contacts the PCRF based on provisioned information... Request for PCC rules from the AGW The AGW shall indicate to the PCRF, via the Ty reference point, a request for PCC rules. If the PCRF is acting as a V-PCRF [X.S00-0], it determines the H-PCRF based on the Destination-Realm, Destination-Host, and Subscription-Id associated with the request, and routes the request to the H-PCRF. The AGW may initiate a request in any of the following instances. ) At IP-CAN session establishment: The AGW shall send a CC-Request (CCR) with CC-Request-Type AVP set to the value INITIAL_REQUEST. The AGW shall supply user identification and other attributes to allow the PCRF to identify the PCC rules to be applied. The other attributes shall include the type of the radio access technology (e.g CDMA00 X, HRPD, UMB, WLAN) and the UE s IP address. The AGW may also include the Access-Network-Charging-Address, the AGW-MCC-MNC, the Access-Network-Physical- Access-ID or all in the CCR. For the Packet Data Subsystem, information about the user (e.g., NAI and AGW address). The IP-CAN session establishment corresponds to an IP address assignment. So, if the same UE is assigned multiple IP addresses (for example, if the same UE is assigned an IPv and IPv address), each such address assignment is considered as a new IP-CAN session establishment. ) At IP-CAN session modification if an Event trigger is met (including creation, loss, or release of IP-CAN flow): The AGW shall send a CCR with CC-Request-Type AVP set to the value UPDATE_REQUEST. The AGW shall supply within the PCC rule request the specific event that caused the IP-CAN session modification (within the Event-Trigger AVP) and any previously provisioned PCC rule(s) affected by the IP-CAN session modification within the Charging-Rule-Report AVP. The AGW may include the Access-Network-Charging-Address and Access-Network-Physical-Access-ID AVPs in the CCR. The following represent normal operation as requested by the mobile and reported using the TFT_CHANGE Event- Trigger: If a new IP flow is being established, the AGW shall assign a new identifier to this IP flow, include this identifier within the Flow-Identifier AVP, and include the Flow-Operation AVP set to the value of ESTABLISHMENT. For cdma00 networks, IP-CAN Flow establishment occurs when a new packet filter is added to an already established IP-CAN session. If an existing IP flow is being modified, the AGW shall include the assigned flow identifier of this IP flow within the Flow-Identifier AVP, and include the Flow-Operation AVP set to the value of 0 0 0
X.S00-0-0 v.0 0 0 0 MODIFICATION. For cdma00 networks, IP-CAN Flow modification occurs when a packet filter is modified for an already established IP-CAN session. If an existing IP flow is being terminated, the AGW shall include the assigned flow identifier of this IP flow within the Flow-Identifier AVP, and include the Flow-Operation AVP set to the value of TERMINATION. For cdma00 networks, IP-CAN Flow termination occurs when a packet filter is deleted for an already established IP-CAN session. When the AGW receives unsolicited PCC rules in a RAR from the PCRF for a flow which contains no Flow- Identifier AVP, the AGW may assign a Flow-Identifier and return it in the Re-Auth-Answer Diameter command. For GPP IP-CAN, if Mobile IPv is used, the Flow-Info AVP sent from the AGW to the PCRF shall contain the flow information corresponding to the home address. NOTE: The flow information corresponding to the home address is derived from source address, destination address and the mobility related header (e.g., Type Routing Header, Home Address Option, etc.) information in the packet filters... Provision of authorized QoS or charging rules from the PCRF The PCRF shall indicate, via the Ty reference point, PCC rules to be applied at the AGW. This may be using one of the following procedures: - PULL procedure: In response to a request for PCC rules being made by AGW (i.e., to a request made as described in the preceding section), the PCRF shall provision PCC rules by CCA command, or - PUSH procedure: Unsolicited by the AGW by using the RAR command, the PCRF may provision PCC rules. The PUSH procedure occurs whenever the PCRF decides to perform an operation using PCC rule(s) and/or QoS information on an AGW without receiving a CCR from that AGW. The following are examples of events that trigger a PUSH procedure: The PCRF may have an internal trigger; The PCRF may be acting as a V-PCRF [X.S00-0] in response to information from the H-PCRF; The PCRF may wish to modify previously provided information to the AGW. For the PUSH procedure, the PCC rules are included in the RAR message and no CCR/CCA messages are triggered. Regardless of the provisioning model used (i.e., PUSH or PULL), the PCRF may provision PCC rules. The PCRF may perform an operation on a single PCC rule by one of the following means: - To activate or deactivate a PCC rule that is predefined at the AGW, the PCRF shall provision a reference to this PCC rule within a Charging-Rule-Name AVP and indicate the required action by choosing either the Charging-Rule-Install AVP or the Charging-Rule-Remove AVP. - To install or modify a PCRF-provisioned PCC rule, the PCRF shall provision a corresponding Charging- Rule-Definition AVP within a Charging-Rule-Install AVP. - To remove a PCC rule which has previously been provisioned by the PCRF, the PCRF shall provision the name of this rule as the value of a Charging-Rule-Name AVP within a Charging-Rule-Remove AVP. As an alternative to providing a single PCC rule, the PCRF may provide a Charging-Rule-Base-Name AVP within a Charging-Rule-Install AVP or the Charging-Rule-Remove AVP as a reference to a group of PCC rules predefined at the AGW. With a Charging-Rule-Install AVP, a predefined group of PCC rules is activated or modified. With a Charging-Rule-Remove AVP, a predefined group of PCC rules is deactivated. The PCRF may combine PCC rule operations using a single CCA or RAR message.
X.S00-0-0 v.0 To activate a predefined PCC rule at the AGW, the PCC rule name within a Charging-Rule-Name AVP shall be supplied within a Charging-Rule-Install AVP as a reference to the predefined PCC rule. To activate a group of predefined PCC rules within the AGW (e.g., gold users or gaming services) the PCC rule base name within a Charging-Rule-Base-Name AVP shall be supplied within a Charging-Rule-Install AVP as a reference to the group of predefined PCC rules. The PCRF shall indicate the IP flow where the PCC rules shall be activated using the Flow-Description and Flow-Identifier AVPs within the Charging-Rule-Install AVP. If the PCC rule is being activated for a flow for which the PCRF has no Flow-Identifier, then the Flow-Identifier AVP is omitted. When the PCRF is installing a new PCC rule or modifying an existing PCC rule, the Charging-Rule-Definition AVP shall be used. If a PCC rule already exists at the AGW with the same rule name as supplied in the Charging-Rule- Name AVP within the Charging-Rule-Definition AVP, the new PCC rule shall update the previously installed PCC rule as specified in... If the existing PCC rule already has attributes also included in the new PCC rule definition, the existing attributes shall be overwritten. In order for the PCRF to deactivate a single predefined PCC rule or PCRF-provided PCC rule(s), the Charging- Rule-Name AVP shall be supplied within a Charging-Rule-Remove AVP. To deactivate a group of predefined PCC rules, the PCRF shall supply a Charging-Rule-Base-Name AVP within a Charging-Rule-Remove AVP.... Selecting a PCC rule for Uplink IP packets If PCC is enabled, the AGW shall select the applicable PCC rule for each received uplink IP packet by evaluating the packet against service data flow filters of PCRF-provided or predefined active PCC rules in the order of the precedence of the PCC rules. When a packet matches a service data flow filter, the packet matching process for that packet is completed, and the PCC rule for that filter shall be applied. Uplink IP packets which do not match any PCC rule shall be silently discarded. For GPP IP-CAN, if Mobile IPv is used, the service data flow filter contains the HoA of the UE and the CN. When route optimization is not used, the AGW matches the inner IP header of the tunnelled packets against the service data flow filters. When route optimization is used, the address matching may need to consider source address, destination address, and the mobility related headers (e.g., Type Routing Header, Home Address Option, etc.) in the IP packet.... Selecting a PCC rule and IP-CAN Bearer for Downlink IP packets If PCC is enabled, the AGW shall select a PCC rule for each received downlink IP packet within an IP -CAN session by evaluating the packet against service data flow filters of PCRF-provided or predefined active PCC rules in the order of the precedence of the PCC rules. When a packet matches a service data flow filter, the packet matching process for that packet is completed, and the PCC rule for that filter shall be applied. The downlink IP packet shall be transported over the IP-CAN bearer determined by the flow mapping information present in the AGW. Downlink IP packets which do not match any PCC rule of the IP-CAN session shall be silently discarded. For GPP IP-CAN, if Mobile IPv is used, the service data flow filter contains the HoA of the UE and the CN. When route optimization is not used, the AGW matches the inner IP header of the tunnelled packets against the service data flow filters. When route optimization is used, the address matching may need to consider source address, destination address, and the mobility related headers (e.g., Type Routing Header, Home Address Option, etc.) in the IP packet.... Gate function The Gate Function represents a user plane function enabling or disabling the forwarding of service flow packets. A gate is described within a PCC rule. If the PCC rule contains Flow-Description AVP(s) applicable for uplink IP flows, it shall describe a gate for the corresponding uplink IP flows. If the PCC rule contains Flow-Description AVP(s) applicable for downlink IP flows, it shall describe a gate for the corresponding downlink IP flows. The Flow Status AVP of the PCC rule shall describe if the possible uplink and possible downlink gate is opened or closed. The commands to open or close the gate shall lead to the enabling or disabling of the passage for corresponding IP packets. If the gate is closed all packets of the related IP flows shall be dropped. If the gate is opened the packets of the related IP flows are allowed to be forwarded. 0 0 0
X.S00-0-0 v.0 0 0 0 If the PCC rule contains no Flow-Status AVP, the service flows matching the PCC rule shall be enabled.... Policy enforcement for "Authorized QoS" per PCC Rule The PCRF provides the authorized QoS for a PCC rule to the AGW. The Provisioning of authorized QoS per PCC Rule shall be performed using the PCC rule provisioning procedure. For a PCRF-provided PCC rule, the Authorized QoS shall be encoded using a QoS-Information AVP within the Charging-Rule-Definition AVP of the PCC rule. If the PCRF is acting as a V-PCRF, then the V-PCRF may downgrademodify the Authorized QoS PCC Rule based on visited network policy and home operator concurrence (e.g., roaming agreement). If Authorized QoS is provided for a PCC rule, the AGW shall enforce the corresponding policy. The AGW may include Requested-QoS and Granted-QoS AVPs in CCR and RAA messages to the PCRF. These AVPs indicate to the PCRF the QoS requested by the UE and the QoS granted in the access network for a particular IP flow... Provision of event triggers from the PCRF The PCRF may provide event triggers within an Event-Trigger AVP to the AGW using the PCC rule provision procedure. Event triggers may be used to determine which IP flow modification or specific event causes the AGW to re-request PCC rules. Event triggers apply for an IP flow depending on the particular event and may be provided in combination with the initial or subsequent PCC rule provisioning... Provision of charging addresses from the PCRF Within the initial PCC rule provisioning only, the PCRF may provide AAA and/or OCS addresses to the AGW defining the offline and online charging system addresses respectively using the Charging-Information AVP. These addresses shall overwrite any predefined addresses at the AGW. The PCRF shall simultaneously provide both primary and secondary addresses for AAA or OCS. Provisioning AAA or OCS addresses without PCC rules for offline or online charged service data flows, respectively, shall not be considered an error by the AGW since PCC rules may be predefined in the TPF or provided later... Provisioning of Authorized QoS The PCRF may provide authorized QoS to the AGW. The AGW may provide requested and granted QoS information to the PCRF. The provisioning of authorized QoS may be performed separate or in combination with the PCC rule provisioning procedure. The AGW may indicate requested and granted QoS information to the PCRF in the CCR and RAA messages within Flow-Info AVP.The authorized QoS shall be provisioned within a CCA or RAR Diameter message as QoS-Information AVP within a Charging-Rule-Definition AVP. The authorized QoS provides an upper bound on the resources that can be reserved or allocated in the AGW and in the RAN. The AGW ensures that the granted QoS does not exceed the Authorized QoS per IP flow. The AGW needs the "Authorized QoS" information for the uplink as well as for the downlink direction. The authorized bandwidth is supplied separately for uplink and downlink direction. The QoS class identifier in the "Authorized QoS" information shall be applicable for uplink and downlink IP flows. The AGW shall perform the mapping between the IP QoS information and the specific access technology QoS information. This mapping is performed by the translation/mapping function which maps the "Authorized QoS" information into access specific QoS information and vice-versa. Upon receiving the QoS-Information AVP from the PCRF in CCA or in RAR, the AGW shall derive the highest allowed traffic class for the IP flow from the QoS class identifier in the "Authorized QoS" AVP. For HRPD or UMB, when sending the Granted-QoS and Requested-QoS AVPs to the PCRF in the CCR or RAA, the AGW uses the information in [C.R0] to determine the translation between FlowProfileID and the traffic class and if availabe UL/DL bandwidth information for the IP flow. In the case of real-time flows (conversational and streaming traffic classes), the AGW shall consider, the data rate value of the "Authorized QoS" information as the maximum value of the 'Guaranteed bitrate', whereas the 'Maximum bitrate' is limited by the subscriber and service specific setting in the AAA and by the
X.S00-0-0 v.0 capacity/capabilities/service configuration of the network. In the case of non-real-time IP flows (interactive and background traffic classes) the AGW shall consider, the data rate value of the "Authorized QoS" information as the maximum value of the 'Maximum bitrate'. When the AGW receives an unsolicited authorization decision from the PCRF with updated QoS information for an IP flow, the AGW shall update the stored authorized QoS. - If the existing QoS of the IP flow exceeds the updated authorized QoS and the IP flow was not initiated by the network, the AGW may start a timer and wait for the UE to modify the IP flow to decrease the QoS to within the authorized limit until expiry of that timer. Upon expiry of the timer, if the IP flow still exceeds the authorized QoS, the AGW shall either perform a network initiated IP flow modification to reduce the QoS to the authorized level or terminate IP flow... Indication of IP flow termination (from AGW to PCRF) If the last IP flow within an IP-CAN session is being terminated, the AGW shall apply the procedures in Clause.. to indicate the IP-CAN session termination. Otherwise, this procedure shall be carried out as part of a Request for PCC rules at IP-CAN session modification. If an event trigger is met, the AGW shall send a CCR with CC-Request-Type AVP set to the value "UPDATE_REQUEST" and shall include the following additional information: - The AGW shall include the Charging-Rule-Report AVP indicating the disabling of any affected PCC rules. - The AGW shall include the assigned flow identifier of this IP flow within the Flow-Identifier AVP and include the Flow-Operation AVP set to the value TERMINATION. When the PCRF receives the CCR indicating an IP flow termination, it shall acknowledge the message by sending a CC-Answer (CCA) to the AGW. The AGW shall remove all PCC rules previously applied to the terminated IP flow... Indication of IP-CAN session termination (from AGW to PCRF) The AGW indicates to the PCRF, via the Ty reference point, that an IP-CAN session is terminated via the release of the corresponding Diameter session. The AGW shall send a CCR with CC-Request-Type AVP set to the value TERMINATION_REQUEST. The termination indication identifies the session being removed by the usage of the corresponding Diameter session. When the PCRF receives the CCR, it shall acknowledge this message by sending a CCA to the AGW. The AGW shall remove all PCC rules previously applied to any IP flow terminated at the time the IP-CAN session is terminated... Request of IP-CAN session termination (from PCRF to AGW) The PCRF may request the termination of an IP-CAN session by using the PCC rule provisioning procedures in Clause.. to remove all PCRF-provisioned PCC rules and deactivate all PCC rules predefined within the AGW, which have been applied to this IP-CAN session. If no more PCC rules are applied to an IP-CAN session, the AGW shall apply IP-CAN specific procedures to terminate the IP-CAN session. Furthermore, the AGW shall apply the indication of IP-CAN Session Termination procedure in Clause..... Request of IP flow termination (from PCRF to AGW) If the termination of the last IP flow within an IP-CAN session is requested, the PCRF and AGW shall apply the procedures in section... Otherwise, the PCRF may request the termination of an existing IP flow within an IP-CAN session by using the PCC rule provisioning procedures in section.. to remove all PCRF-provisioned PCC rules and deactivate all 0 0 0
X.S00-0-0 v.0 0 0 0 PCC rules predefined within the AGW, which have been applied to this IP flow. The PCRF completely removes these PCC rules from the IP-CAN session. If no more PCC rules are applied to an IP flow, the AGW shall apply IP-CAN specific procedures to terminate the IP flow, if such procedures exist for this IP-CAN type. Furthermore, the AGW shall apply the indication of IP flow Termination procedure in section..... PCC Rule Error Handling If the installation/activation or enforcement of one or more PCC rules fails, the AGW shall include a Charging-Rule- Report AVP in either a CCR or an RAA command as described below for each of the affected PCC rules. Within each Charging-Rule-Report AVP, the AGW shall identify the failed PCC rule(s) by name (or base name), shall include a failed reason code (Rule-Reason-Code), and shall include the PCC-Rule-Status as described below: If the installation/activation of one or more PCC rules fails using a PULL mode (i.e., the PCRF installs/activates a rule using a CCA command) and the PCRF included the PCC_RULE_FAILURE Event- Trigger in the CCA or had previously installed the PCC_RULE_FAILURE Event-Trigger, the AGW shall send the PCRF a new CCR command and include the Event-Trigger PCC_RULE_FAILURE. The AGW shall set the PCC-Rule-Status to INACTIVE for rules which fail to be installed/activated using a PULL mode. If the installation/activation of one or more PCCs rules fails using a PUSH mode (i.e., the PCRF installs/activates a rule using RAR command), the AGW shall communicate the failure to the PCRF in the RAA response to the RAR. The AGW shall include the Experimental-Result-Code AVP set to DIAMETER_PCC_RULE_EVENT. If an update (i.e., installation of PCC rules which were previously successfully installed) to one or more PCC rules fails using a PUSH mode, the state of the failed rules is unchanged (i.e., as if the update did not occur) if the PCC-Rule-Status is set to ACTIVE. A PCC-Rule- Status set to INACTIVE means that the affected PCC rule(s) is/are no longer valid. If a PCC rule was successfully installed/activated, but can no longer be enforced by the AGW and the PCRF had previously installed the PCC_RULE_FAILURE Event-Trigger, the AGW shall send the PCRF a new CCR command and include the Event-Trigger PCC_RULE_FAILURE. The AGW shall set the PCC- Rule-Status to INACTIVE for each rule which can no longer be enforced. Depending on the cause of the failure, the PCRF can decide if re-installation, modification, removal of PCC rules, or any other action apply.. Diameter Protocol The Diameter Base Protocol as specified in [RFC] and Diameter Credit Control Application [RFC00] shall apply except as modified by the defined Ty application specific procedures and AVPs. Unless otherwise specified, the procedures (including error handling and unrecognized information handling) are unmodified. Existing Diameter command codes from the Diameter base protocol [RFC] and the Diameter Credit Control Application [RFC00] are used with the Ty specific AVPs defined within the clause... The Diameter AVPs from the Diameter Credit Control Application [RFC00] and other Diameter applications are defined in clause... With regard to the Diameter protocol defined over the Ty interface, the PCRF may act as a Diameter server when handling PCC rules for a particular realm, and/or a Diameter proxy when handling PCC rules from an H-PCRF. The AGW acts as the Diameter Client, in the sense that it is the network element requesting PCC rules with respect to these resources. The status of the rule is INACTIVE when reporting an error in a new CCR command since the new CCR/CCA transaction contains no previous state information regarding the definition and status of the rule.
X.S00-0-0 v.0 The Ty application is defined as an IETF vendor specific Diameter application with application ID, where the vendor is GPP. The vendor identifier assigned by IANA to GPP (http://www.iana.org/assignments/enterprise-numbers) is. The AGW and the PCRF shall advertise the support of the Ty specific Application by including the value as the application identifier in the Auth-Application-Id AVP within the Vendor-Specific-Application-Id AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands. The vendor identifier value of GPP () shall be included in the Vendor-Id AVP within the Vendor-Specific-Application-Id AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands. The AGW and PCRF shall advertise support of GPP and GPP vendor-specific AVPs by including the vendor identifier value of GPP () within a Supported-Vendor-Id AVP, and the vendor identifier value of GPP () within a Supported-Vendor-Id AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands. The Capabilities-Exchange- Request and Capabilities-Exchange-Answer commands are specified in the Diameter Base Protocol [RFC]. For secure transport of Diameter messages, see [RFC]. In order to support both PULL and PUSH procedures, a Ty Diameter session needs to be established for each IP- CAN session. NOTE: Some of the AVPs included in the messages formats below are in bold to highlight that these AVPs are used by this specific protocol and do not belong to the original message definition in the DCC Application [RFC00] or Diameter Base Protocol [RFC]. Those AVPs can be specified in other specifications... Ty Diameter messages Ty Messages are carried within the Diameter Application(s) described in the sub-clauses below. These Applications are defined as GPP vendor specific Diameter applications. The vendor identifier assigned by IANA to GPP is. The association between the PDS session and the Diameter Credit Control sessions shall be done in a one-to-one basis (i.e., PDS session = DCC session). Any modification to the PDS session, including the establishement, modification, or release of IP flows within the PDS session may result in modifications to the DCC session if an Event-Tigger is met. The release of the last IP flow shall be indicated by the release of the DCC session. A Ty Application specific Auth-Application-Id is used together with the command code to identify the Ty Application messages. NOTE: The Diameter Base Protocol [RFC] requires that Answer type commands have a Result-Code AVP. However, in certain Answer commands an optional Experimental-Result AVP may be present. When the Experimental-Result AVP is present the Result-Code AVP is not required.... CC-Request (CCR) Command The CCR command, indicated by the Command-Code field set to and the 'R' bit set in the Command Flags field, is sent by the AGW to the PCRF in order to request PCC rules for a bearer. The CCR command is also sent by the AGW to the PCRF in order to indicate the termination of the bearer. Message Format: <CC-Request> ::= < Diameter Header:, REQ, PXY > < Session-Id > { Auth-Application-Id } { Origin-Host } { Origin-Realm } { Destination-Realm } { CC-Request-Type } { CC-Request-Number } [ Destination-Host ] [ Origin-State-Id ] 0 0 0
X.S00-0-0 v.0 0 0 0 *[ Subscription-Id ] [ Flow-Operation ] *[ Flow-Info ] [ Framed-IP-Address ] [ Framed-IPv-Prefix ] [ RAT-Type ] [ Termination-Cause ] [ User-Equipment-Info ] [ AGW-MCC-MNC ] [ AGW-IP-Address ] [ AGW-IPv-Address ] [ Called-Station-ID ] *[ Charging-Rule-Report] *[ Event-Trigger] [ Access-Network-Charging-Address ] *[ Access-Network-Charging-Identifier-Ty ] [ Access-Network-Physical-Access-ID ] *[ Proxy-Info ] *[ Route-Record ] *[ AVP ]... CC-Answer (CCA) Command The CCA command, indicated by the Command-Code field set to and the 'R' bit cleared in the Command Flags field, is sent by the PCRF to the AGW in response to the CCR command. It is used to provision PCC rules and event triggers for the IP flow. The primary and secondary CCF and/or primary and secondary OSC addresses may be included in the initial provisioning. Either the Result-Code AVP or the Experimental-Result AVP must be present to indicate the disposition of the request. Message Format: <CC-Answer> ::= < Diameter Header:, PXY > < Session-Id > { Auth-Application-Id } { Origin-Host } { Origin-Realm } [ Result-Code ] [ Experimental-Result ] { CC-Request-Type } { CC-Request-Number } *[ Event-Trigger ] [ Origin-State-Id ] *[ Charging-Rule-Remove ] *[ Charging-Rule-Install ] [ Charging-Information ] [ Error-Message ] [ Error-Reporting-Host ] *[ Failed-AVP ] *[ Redirect-Host] [ Redirect-Host-Usage ] [ Redirect-Max-Cache-Time ] *[ Proxy-Info ] *[ Route-Record ] *[ AVP ]... Re-Auth-Request (RAR) Command The RAR command, indicated by the Command-Code field set to and the 'R' bit set in the Command Flags field, is sent by the PCRF to the AGW in order to provision PCC rules using the PUSH procedure to initiate the provision of unsolicited PCC rules. Message Format: <RA-Request> ::= < Diameter Header:, REQ, PXY > < Session-Id > { Auth-Application-Id }
X.S00-0-0 v.0 { Origin-Host } { Origin-Realm } { Destination-Realm } { Destination-Host } { Re-Auth-Request-Type } [ Origin-State-Id ] *[ Class ] *[ Event-Trigger ] *[ Charging-Rule-Remove ] *[ Charging-Rule-Install ] *[ Proxy-Info ] *[ Route-Record ] *[ AVP]... Re-Auth-Answer (RAA) Command The RAA command, indicated by the Command-Code field set to and the 'R' bit cleared in the Command Flags field, is sent by the AGW to the PCRF in response to the RAR command. Either the Result-Code AVP or the Experimental-Result AVP must be present to indicate the disposition of the request. Message Format: <RA-Answer> ::= < Diameter Header:, PXY > < Session-Id > { Origin-Host } { Origin-Realm } [ Result-Code ] [ Experimental-Result ] [ Origin-State-Id ] *[ Class ] [ Event-Trigger ] *[ Charging-Rule-Report] [ Access-Network-Charging-Address ] *[ Access-Network-Charging-Identifier-Ty ] [ Access-Network-Physical-Access-ID ] [ Error-Message ] [ Error-Reporting-Host ] *[ Failed-AVP ] *[ Redirect-Host] [ Redirect-Host-Usage ] [ Redirect-Max-Cache-Time ] *[ Proxy-Info ] *[ Flow-Info ] *[ AVP ]... Experimental-Result/Experimental-Result-Code AVP Values 0 0 0
X.S00-0-0 v.0 0 0 0... Experimental-Result AVP Format The Experimental-Result AVP (AVP Code ) which is defined in [RFC] is of type Grouped, and indicates whether a particular vendor-specific request was completed successfully or whether an error occurred. Message Format: <Experimental-Result> ::= < AVP Header: > { Vendor-ID } { Experimental-Result-Code } The Vendor-Id AVP identifies the vendor responsible for the assignment of the experimental result code which follows. All Diameter answer messages defined in vendor-specific applications must include either one Result-Code AVP or one Experimental-Result AVP. Unless otherwise indicated, the Vendor-Id AVP shall take the value of (GPP) for Experimental-Result-Code specified in this document... Ty specific Diameter AVPs Table.- describes the GPP Diameter AVPs defined for the Ty reference point, their AVP Code values, types, possible flag values and whether or not the AVP may be encrypted. Table.- describes the GPP Diameter AVPs defined for the Ty reference point, their AVP Code values, types, possible flag values and whether or not the AVP may be encrypted. The Vendor-Id header of all AVPs defined in the present document shall be set to (GPP) unless specified otherwise. In other cases, as specified, the Vendor-Id shall be set to (GPP). Table.-: Ty Specific GPP Diameter AVPs AVP Flag rules (note ) Attribute Name AVP Clause Value Type Must May Should Must May Acc. Code defined (note ) not not Encr. Type Charging-Rule-Remove 0... Grouped M,V P Y All Charging-Rule-Base-Name 0... UTFString M,V P Y All Charging-Rule-Name 0... OctetString M,V P Y All Metering-Method 0... Enumerated M,V P Y All Offline 0... Enumerated M,V P Y All Online 0... Enumerated M,V P Y All Precedence... Unsigned M,V P Y All Reporting-Level... Enumerated M,V P Y All QoS-Class-Identifier... Enumerated M,V P Y All Access- Network-Charging-... Grouped M,V P Y All Identifier-Ty (note ) PCC-Rule-Status... Enumerated M,V P Y All Guaranteed-Bitrate-UL... Unsigned M,V P Y All Guaranteed-Bitrate-DL... Unsigned M,V P Y All NOTE : The AVP header bit denoted as 'M', indicates whether support of the AVP is required. The AVP header bit denoted as 'V', indicates whether the optional Vendor-ID field is present in the AVP header. For further details, see [RFC]. NOTE : The value types are defined in [RFC]. NOTE : This AVP has a different name (Ty rather than Gx) but otherwise is identical to the GPP AVP with the same AVP code.
X.S00-0-0 v.0 Table.-: Ty Specific GPP Diameter AVPs AVP Flag rules (note ) Attribute Name AVP Clause Value Type Must May Should Must May Acc. Code defined (note ) not not Encr. Type Flow-Operation 00... Enumerated M,V P Y All Charging-Rule-Install 0... Grouped M,V P Y All Charging-Rule-Definition 0... Grouped M,V P Y All Event-Trigger 0... Enumerated M,V P Y All QoS-Information 0... Grouped M,V P Y All Charging-Rule-Report 0... Grouped M,V P Y All AGW-IP-Address 0... OctetString M,V P Y All AGW-IPv-Address 0... OctetString M,V P Y All RAT-Type 0... Enumerated M,V P Y All Flow-Info 0... Grouped M,V P Y All Flow-Identifier... OctetString M,V P Y PDS Granted-QoS... Grouped M,V P Y PDS Requested-QoS... Grouped M,V P Y PDS Flow-Description-Info...0 Grouped M,V P Y All Rule-Reason-Code... Enumerated M,V P Y All AGW-MCC-MNC... UTFString M,V P Y All NOTE : The AVP header bit denoted as 'M', indicates whether support of the AVP is required. The AVP header bit denoted as 'V', indicates whether the optional Vendor-ID field is present in the AVP header. For further details, see [RFC]. NOTE : The value types are defined in [RFC].... Flow-Operation AVP The Flow-Operation AVP (AVP code 00) is of type of Enumerated, and it indicates the IP-CAN flow event that causes a request for PCC rules. The GPP vendor ID shall be used for this AVP. The following values are defined: TERMINATION (0) This value is used to indicate that an existing IP-CAN flow is being removed. ESTABLISHMENT () This value is used to indicate that a new IP-CAN flow is being established. MODIFICATION () This value is used to indicate that an existing IP-CAN flow is being modified.... Charging-Rule-Install AVP The Charging-Rule-Install AVP (AVP code 0) is of type Grouped, and it is used for installing or modifying PCC rules for a bearer as instructed from the PCRF to the AGW. Charging-Rule-Name AVP is a reference for activating a specific PCC rule predefined at the AGW. The Charging-Rule-Base-Name AVP is a reference for activating a group of PCC rules predefined at the AGW. The Charging-Rule-Definition AVP is used for installing or modifying PCC rules provisioned over the Ty interface. The GPP vendor ID shall be used for this AVP. AVP Format: Charging-Rule-Install ::= < AVP Header: 0 > *[ Charging-Rule-Definition ] *[ Charging-Rule-Name ] *[ Charging-Rule-Base-Name ] *[ AVP ] 0 0 0
X.S00-0-0 v.0 0 0 0... Charging-Rule-Remove AVP The Charging-Rule-Remove AVP (AVP code 0) is of type Grouped, and it is used for removing PCC rules from a bearer. Charging-Rule-Name AVP is a reference for a specific PCC rule at the AGW to be removed or for a specific PCC rule predefined at the AGW to be deactivated. The Charging-Rule-Base-Name AVP is a reference for a group of PCC rules predefined at the AGW to be deactivated. AVP Format: Charging-Rule-Remove ::= < AVP Header: 0 > *[ Charging-Rule-Name ] *[ Charging-Rule-Base-Name ] *[ AVP ]... Charging-Rule-Definition AVP The Charging-Rule-Definition AVP (AVP code 0) is of type Grouped, and it defines the PCC rule for a service flow sent by the PCRF to the AGW. The Charging-Rule-Name AVP uniquely identifies the PCC rule for a bearer and it is used to reference to a charging rule in communication between the AGW and the PCRF. The Flow- Description AVP(s) determines the traffic that belongs to the service flow. The GPP vendor ID shall be used for this AVP. With the exception of the Flow-Description and Flow-Identifier AVP(s), if optional AVP(s) within a Charging-Rule- Definition AVP are omitted, previous information that corresponds to the omitted AVP(s) shall remain valid. For example, if the Offline AVP was supplied in a Charging-Rule-Definition, but omitted in an update to the PCC rule, the value of the previously supplied Offline AVP applies to the updated PCC rule, etc. The Flow-Identifier and Flow-Description AVPs in a Charging-Rule-Definition identify or describe the set of IP flows the PCC rule applies to. If a Charging-Rule-Definition is updated, the new set of Flow-Identifier and/or Flow- Description AVPs (if any) entirely replace previously supplied AVP values (if any). As a result, whenever the Charging-Rule-Description is updated, the resulting PCC rule shall only be applied to the set of IP flows identified or described within that update. If Flows AVP(s) are supplied, they replace all previous Flows AVP(s). AVP Format: Charging-Rule-Definition ::= < AVP Header: 0 > { Charging-Rule-Name } [ Service-Identifier ] [ Rating-Group ] [ Flow-Identifier ] *[ Flow-Description ] [ Flow-Status ] [ QoS-Information ] [ Reporting-Level ] [ Online ] [ Offline ] [ Metering-Method ] [ Precedence ] [ AF-Charging-Identifier ] *[ Flows ] *[ AVP ]... Charging-Rule-Base-Name AVP The Charging-Rule-Base-Name AVP (AVP code 0) is of type UTFString, and it indicates the name of a pre-defined group of PCC rules residing at the AGW.... Charging-Rule-Name AVP The Charging-Rule-Name AVP (AVP code 0) is of type OctetString and it defines a name for PCC rule. For PCC rules provided by the PCRF it uniquely identifies a PCC rule for a bearer. For PCC rules pre-defined at the AGW it uniquely identifies a PCC rule within the AGW.
X.S00-0-0 v.0... Event-Trigger AVP The Event-Trigger AVP (AVP code 0) is of type Enumerated. When sent from the PCRF to the AGW, the Event- Trigger AVP indicates an event that shall cause a re-request of PCC rules. When sent from the AGW to the PCRF, the Event-Trigger AVP indicates that the corresponding event has occurred at the gateway. The GPP vendor Id shall be used for this AVP. The scope of the Event-Trigger AVP depends on the event type. If the event type is related to the IP flow (e.g., QOS_CHANGE, TFT_CHANGE, LOSS_OF_FLOW, RECOVERY_OF_FLOW), the Event-Trigger AVP should apply to IP flows associated with the PCC rules provisioned in the same message. Otherwise, it should apply to the IP-CAN session Whenever one of these events occurs, the AGW shall send any related AVP(s) that has changed together with the event trigger indication. The following values are defined: PCF_CHANGE (0) This value shall be used in CCA and RAR commands by the PCRF to indicate that upon the change of the serving PCF, PCC rules shall be requested. When used in a CCR command, this value indicates that the AGW generated the request because the serving PCF changed. QOS_CHANGE () This value shall be used in CCA and RAR commands by PCRF to indicate that the upon QoS change PCC rules shall be requested. When used in a CCR command, this value indicates that the AGW generated the request because there has been a change in the requested QoS (e.g., the previously maximum authorized QoS has been exceeded). Applicable for all access-types. RAT_CHANGE () This value shall be used in CCA and RAR commands by PCRF to indicate that the upon RAT change PCC rules shall be requested. When used in a CCR command, this value indicates that the AGW generated the request because of a RAT change. TFT_CHANGE () This value shall be used in CCA and RAR commands by PCRF to indicate that for the installation or modifcation of a TFT, PCC rules shall be requested. When used in a CCR command, this value indicates that the AGW generated the request because of a change in the TFT, including the establishment, modification, or termination of an IP flow. PLMN_CHANGE () This value shall be used in CCA and RAR commands by the PCRF to indicate that upon a PLMN change PCC rules shall be requested. When used in a CCR command, this value indicates that the AGW generated the request because there was a change of PLMN. LOSS_OF_FLOW () This value shall be used in CCA and RAR commands by PCRF to indicate that upon loss of flow, AGW should inform PCRF. When used in a CCR command, this value indicates that the AGW generated the request because the flow associated with the PCC rules indicated by the corresponding Charging Rule Report AVP was lost, e.g., due to a loss of the radio link, which is beyond the control of the mobile. The mechanism of indicating loss of flow to the AGW is IP-CAN access type specific. RECOVERY_OF_FLOW () 0 0 0
X.S00-0-0 v.0 0 0 0 This value shall be used in CCA and RAR commands by PCRF to indicate that upon recovery of flow, AGW should inform PCRF. When used in a CCR command, this value indicates that the AGW generated the request because the flow associated with the PCC rules indicated by the corresponding Charging Rule Report AVP was recovered. The mechanism for indicating recovery of flow to the AGW is IP-CAN access type specific. IP-CAN_CHANGE () This value shall be used in CCA and RAR commands by PCRF to indicate that upon a change in the IP-CAN, PCC rules shall be requested. When used in a CCR command, this value indicates that the AGW generated the request because there was a change of IP-CAN. Applicable for all access types. PCC_RULE_FAILURE () This value shall be used in CCA and RAR commands by the PCRF to indicate that upon a failure in the installation/activation or enforcement of PCC rules, the AGW shall inform the PCRF. When used in a CCR command, this value indicates that the AGW generated the request because the PCC rules cannot be enforced, installed, or activated as described in section.. PCC Rule Error Handling. ACCESS_NETWORK_PHYSICAL_ACCESS_ID_CHANGE () This value shall be used in CCA and RAR commands by the PCRF to indicate that upon the AGW becoming aware of a change in the acceess network that invalidates the current (if any) Access-Network-Physical-Access-ID value or realm, the AGW shall inform the PCRF. When used in a CCR command, this value indicates that the AGW generated the request because of a change to the physical access identity information. It may be possible to derive the reason for the change through other AVPs present in the CCR. For example, if a RAT_CHANGE, PCF_CHANGE, or PLMN_CHANGE was also noted in the CCR from the AGW.... Metering-Method AVP The Metering-Method AVP (AVP code 0) is of type Enumerated, and it defines what parameters shall be metered for offline charging. The following values are defined: DURATION (0) This value shall be used to indicate that the duration of the service flow shall be metered. VOLUME () This value shall be used to indicate that volume of the service flow traffic shall be metered. DURATION_VOLUME () This value shall be used to indicate that the duration and the volume of the service flow traffic shall be metered.... Offline AVP The Offline AVP (AVP code 0) is of type Enumerated, and it defines whether the offline charging interface from the AGW for the associated charging rule shall be enabled. The absence of this AVP indicates that the default configuration shall be used. The following values are defined: DISABLE_OFFLINE (0) This value shall be used to indicate that the offline charging interface for the associated PCC rule shall be disabled. ENABLE_OFFLINE () This value shall be used to indicate that the offline charging interface for the associated PCC rule shall be enabled.