Académique Documents
Professionnel Documents
Culture Documents
Code
UPCC
V300R006C10
Gx Interface Specification
Issue 1.42
Date 2014-3-27
All other trademarks and trade names mentioned in this document are the property of their respective holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and the customer.
All or part of the products, services and features described in this document may not be within the purchase scope or
the usage scope. Unless otherwise specified in the contract, all statements, information, and recommendations in this
document are provided "AS IS" without warranties, guarantees or representations of any kind, either express or
implied.
The information in this document is subject to change without notice. Every effort has been made in the preparation
of this document to ensure accuracy of the contents, but all statements, information, and recommendations in this
document do not constitute a warranty of any kind, express or implied.
Website: http://www.huawei.com
Email: support@huawei.com
Add
Flow-Information AVP
within Application-Detection-Information AVP.
Add
APPLICATION_STOP (40)
within Event-Trigger AVP.
Catalog
1 Reference.....................................................................................................................................1-1
2 Introduction and scope.............................................................................................................2-1
3 Terminology................................................................................................................................3-1
4 Protocol Overview......................................................................................................................4-1
4.1 Diameter.........................................................................................................................................................4-1
4.2 Diameter Base Protocol..................................................................................................................................4-2
4.3 Gx Application................................................................................................................................................4-2
4.4 Interface Authentication mechanism..............................................................................................................4-2
5 Transport......................................................................................................................................5-1
6 Constraints...................................................................................................................................6-1
6.1 Bearer Control Mode......................................................................................................................................6-1
6.2 QoS negotiation..............................................................................................................................................6-1
6.3 Limitations......................................................................................................................................................6-1
7 Messages......................................................................................................................................7-1
7.1 Message Format..............................................................................................................................................7-1
7.2 Base Messages................................................................................................................................................7-1
7.2.1 Capabilities-Exchange-Request (CER).................................................................................................7-1
7.2.2 Capabilities-Exchange-Answer (CEA).................................................................................................7-2
7.2.3 Disconnect-Peer-Request(DPR)............................................................................................................7-2
7.2.4 Disconnect-Peer-Answer(DPA)............................................................................................................7-3
7.2.5 Device-Watchdog-Request(DWR)........................................................................................................7-3
7.2.6 Device-Watchdog-Answer(DWA)........................................................................................................7-3
7.2.7 Abort-Session-Request(ASR)...............................................................................................................7-4
7.2.8 Abort-Session-Answer (ASA)...............................................................................................................7-4
7.3 Gx Messages...................................................................................................................................................7-5
7.3.1 Credit-Control-Request (CCR).............................................................................................................7-5
7.3.2 Credit-Control-Answer (CCA)..............................................................................................................7-7
7.3.3 Re-Auth-Request (RAR).......................................................................................................................7-8
7.3.4 Re-Auth-Answer (RAA).......................................................................................................................7-9
8 Procedures...................................................................................................................................8-1
8.1 Capability Negotiation for 3GPP R7 Gx Application.....................................................................................8-1
8.2 IP-CAN Session Establishment......................................................................................................................8-3
8.3 UE Side Initiated IP-CAN Bearer Modification............................................................................................8-4
8.4 UE Side Initiated IP-CAN Session Termination............................................................................................8-5
8.5 PCRF Initiated IP-CAN Session Modification...............................................................................................8-6
8.6 PCRF Initiated IP-CAN Session Termination................................................................................................8-7
8.7 Usage Report..................................................................................................................................................8-8
8.8 Audit.............................................................................................................................................................8-10
9 AVPs Definition.........................................................................................................................9-1
9.1 Session-Id.......................................................................................................................................................9-1
9.2 Auth-Application-Id.......................................................................................................................................9-1
9.3 Vendor-Id........................................................................................................................................................9-1
9.4 Product-Name.................................................................................................................................................9-2
9.5 Supported-Vendor-Id......................................................................................................................................9-2
9.6 Firmware-Revision.........................................................................................................................................9-2
9.7 Vendor-Specific-Application-Id.....................................................................................................................9-2
9.8 Origin-Host.....................................................................................................................................................9-3
9.9 Origin-Realm..................................................................................................................................................9-3
9.10 Destination-Host...........................................................................................................................................9-3
9.11 Destination-Realm........................................................................................................................................9-3
9.12 Termination-Cause........................................................................................................................................9-4
9.13 Disconnect-Cause.........................................................................................................................................9-4
9.14 Origin-State-Id..............................................................................................................................................9-5
9.15 Result-Code..................................................................................................................................................9-5
9.16 Experimental-Result.....................................................................................................................................9-5
9.17 Error-Message..............................................................................................................................................9-6
9.18 Failed-AVP...................................................................................................................................................9-6
9.19 Re-Auth-Request-Type.................................................................................................................................9-6
9.20 Called-Station-ID.........................................................................................................................................9-6
9.21 Framed-IP-Address.......................................................................................................................................9-6
9.22 Framed-IPv6-Prefix......................................................................................................................................9-7
9.23 CC-Request-Type.........................................................................................................................................9-7
9.24 CC-Request-Number....................................................................................................................................9-7
9.25 Rating-Group................................................................................................................................................9-7
9.26 Service-Identifier..........................................................................................................................................9-8
9.27 Subscription-Id.............................................................................................................................................9-8
9.28 User-Equipment-Info....................................................................................................................................9-8
9.29 3GPP-RAT-Type...........................................................................................................................................9-8
9.30 3GPP-SGSN-Address...................................................................................................................................9-9
9.31 3GPP-SGSN-IPv6-Address..........................................................................................................................9-9
9.32 3GPP-SGSN-MCC-MNC.............................................................................................................................9-9
9.33 3GPP-User-Location-Info..........................................................................................................................9-10
9.34 RAI.............................................................................................................................................................9-10
9.35 Access Network-Charging-Address............................................................................................................9-11
9.36 Access Network-Charging-Identifier-Value...............................................................................................9-11
9.37 AF-Charging-Identifier...............................................................................................................................9-11
9.38 Flow-Description........................................................................................................................................9-11
9.39 Flows..........................................................................................................................................................9-12
9.40 Flow-Status.................................................................................................................................................9-12
9.41 Max-Requested-Bandwidth-UL.................................................................................................................9-12
9.42 Max-Requested-Bandwidth-DL.................................................................................................................9-12
9.43 Charging-Information.................................................................................................................................9-13
9.44 Access-Network-Charging-Identifier-Gx...................................................................................................9-13
9.45 Bearer-Control-Mode.................................................................................................................................9-14
9.46 Bearer-Identifier.........................................................................................................................................9-14
9.47 Bearer-Operation........................................................................................................................................9-14
9.48 Bearer-Usage..............................................................................................................................................9-15
9.49 Charging-Rule-Install.................................................................................................................................9-15
9.50 Charging-Rule-Remove..............................................................................................................................9-16
9.51 Charging-Rule-Definition...........................................................................................................................9-16
9.52 Charging-Rule-Base-Name........................................................................................................................9-18
9.53 Charging-Rule-Name..................................................................................................................................9-18
9.54 Charging-Rule-Report................................................................................................................................9-18
9.55 Event-Trigger..............................................................................................................................................9-19
9.56 IP-CAN-Type..............................................................................................................................................9-25
9.56.2 Guaranteed-Bitrate-DL......................................................................................................................9-25
9.56.3 Guaranteed-Bitrate-UL......................................................................................................................9-26
9.56.4 Metering-Method..............................................................................................................................9-26
9.57 Network-Request-Support..........................................................................................................................9-26
9.58 Offline.........................................................................................................................................................9-27
9.59 Online.........................................................................................................................................................9-27
9.59.2 Precedence.........................................................................................................................................9-28
9.59.3 Reporting-Level................................................................................................................................9-28
9.60 PCC-Rule-Status.........................................................................................................................................9-29
9.61 QoS-Class-Identifier...................................................................................................................................9-29
9.62 QoS-Information.........................................................................................................................................9-29
9.63 QoS-Negotiation.........................................................................................................................................9-30
9.64 QoS-Upgrade..............................................................................................................................................9-31
9.65 TFT-Filter...................................................................................................................................................9-31
9.66 TFT-Packet-Filter-Information...................................................................................................................9-32
9.67 ToS-Traffic-Class........................................................................................................................................9-32
9.68 X-HW-Usage-Report..................................................................................................................................9-32
9.69 X-HW-Session-Usage.................................................................................................................................9-33
9.70 X-HW-Service-Usage.................................................................................................................................9-33
9.71 CC-Input-Octets.........................................................................................................................................9-33
9.72 CC-Output-Octets.......................................................................................................................................9-34
9.73 Redirect-Server...........................................................................................................................................9-34
9.74 Redirect-Address-Type...............................................................................................................................9-34
9.75 Redirect-Server-Address............................................................................................................................9-35
9.76 Append-Original-URL................................................................................................................................9-35
9.77 Deactivate-By-Redirect..............................................................................................................................9-35
9.78 X-HW-Monitoring-Key..............................................................................................................................9-35
9.79 Proto-Classifier-Name................................................................................................................................9-36
9.80 Usage-Monitoring-Information..................................................................................................................9-36
9.81 Usage-Monitoring-Level............................................................................................................................9-37
9.82 Usage-Monitoring-Report..........................................................................................................................9-37
9.83 Usage-Monitoring-Support.........................................................................................................................9-37
9.84 Monitoring-Key..........................................................................................................................................9-38
9.85 CC-Total-Octets..........................................................................................................................................9-38
9.86 Granted-Service-Unit.................................................................................................................................9-38
9.87 Used-Service-Unit......................................................................................................................................9-39
9.88 Revalidation-Time......................................................................................................................................9-39
9.89 Session-Release-Cause...............................................................................................................................9-39
9.90 RAT-Type....................................................................................................................................................9-40
9.91 Default-EPS-Bearer-QoS............................................................................................................................9-41
9.92 Allocation-Retention-Priority AVP.............................................................................................................9-41
9.93 Priority-Level AVP (All access types)........................................................................................................9-41
9.94 Pre-emption-Capability..............................................................................................................................9-42
9.95 Pre-emption-Vulnerability..........................................................................................................................9-42
9.96 APN-Aggregate-Max-Bitrate-DL...............................................................................................................9-42
9.97 APN-Aggregate-Max-Bitrate-UL...............................................................................................................9-42
9.98 AN-GW-Address AVP................................................................................................................................9-43
9.99 Supported-Features AVP.............................................................................................................................9-43
9.100 Feature-List-ID AVP.................................................................................................................................9-43
9.101 Feature-List AVP......................................................................................................................................9-43
9.102 Rule-Activation-Time...............................................................................................................................9-44
9.103 Rule-Deactivation-Time...........................................................................................................................9-44
9.104 X-HW-Subscriber-Service-Definition......................................................................................................9-44
9.105 X-HW-Subscriber-Service-Name.............................................................................................................9-45
9.106 X-HW-Subscriber-Service-Username......................................................................................................9-45
9.107 X-HW-Subscriber-Service-Password.......................................................................................................9-45
9.108 Flow-Information (All access types).......................................................................................................9-45
9.109 Packet-Filter-Content................................................................................................................................9-46
9.110 Packet-Filter-Identifier.............................................................................................................................9-46
9.111 Packet-Filter-Information.........................................................................................................................9-47
9.112 Packet-Filter-Operation............................................................................................................................9-47
9.113 Charging-Correlation-Indicator (All access types)..................................................................................9-48
9.114 3GPP-MS-TimeZone................................................................................................................................9-48
9.115 CC-Time...................................................................................................................................................9-48
9.116 User-Equipment-Info................................................................................................................................9-48
9.117 User-Equipment-Info-Type.......................................................................................................................9-48
9.118 User-Equipment-Info-Value.....................................................................................................................9-49
9.119 X-HW-Cell-Congestion-Level..................................................................................................................9-49
9.120 X-HW-Session-Restoration......................................................................................................................9-49
9.121 Gx-TMO-Redirect-Server........................................................................................................................9-50
9.122 Gx-TMO-Redirect-Address-Type............................................................................................................9-50
9.123 Gx-TMO-Redirect-Server-Address..........................................................................................................9-51
9.124 Gx-TMO-Append-Original-URL.............................................................................................................9-51
9.125 Gx-TMO-Deactivate-By-Redirect............................................................................................................9-51
9.126 Gx-TMO-Append-MSISDN.....................................................................................................................9-51
9.127 Gx-TMO-Append-IMSI...........................................................................................................................9-52
9.128 Gx-TMO-Append-IMEI...........................................................................................................................9-52
9.129 Gx-TMO-Append-MSIP..........................................................................................................................9-52
9.130 X-HW-MS-Group-Name..........................................................................................................................9-53
9.131 X-HW-ACL-Group-Name........................................................................................................................9-53
9.132 X-HW-Interim-Interval.............................................................................................................................9-53
9.133 X-HW-Service-Type.................................................................................................................................9-53
9.134 X-HW-User-Physical-Info-Value.............................................................................................................9-54
9.135 Flow-Direction.........................................................................................................................................9-54
9.136 Packet-Filter-Usage..................................................................................................................................9-54
9.137 X-HW-Content-Filter...............................................................................................................................9-54
9.138 X-HW-Content-Filter-Information...........................................................................................................9-55
9.139 X-HW-Content-Filter-Category-Basename..............................................................................................9-55
9.140 X-HW-Tethering-Status............................................................................................................................9-56
9.141 X-HW-Redirect-Times.............................................................................................................................9-56
9.142 X-HW-Redirect-Report............................................................................................................................9-56
9.143 3GPP2-BSID............................................................................................................................................9-57
9.144 Resource-Allocation-Notification............................................................................................................9-57
9.145 SN-Service-Flow-Detection.....................................................................................................................9-57
9.146 Required-Access-Info...............................................................................................................................9-57
9.147 Application-Detection-Information..........................................................................................................9-58
9.148 TDF-Application-Identifier......................................................................................................................9-58
9.149 Mute-Notification.....................................................................................................................................9-58
9.150 Redirect-Information................................................................................................................................9-59
9.151 Redirect-Support.......................................................................................................................................9-59
9.152 Redirect-Address-Type.............................................................................................................................9-59
9.153 Redirect-Server-Address..........................................................................................................................9-60
9.154 ADC-Rule-Install......................................................................................................................................9-60
9.155 ADC-Rule-Remove..................................................................................................................................9-60
9.156 ADC-Rule-Name......................................................................................................................................9-61
9.157 ADC-Rule-Report.....................................................................................................................................9-61
9.158 AF-Signalling-Protocol.............................................................................................................................9-61
9.159 Event-Report-Indication (All access types).............................................................................................9-62
9.160 X-Header-Enrichment..............................................................................................................................9-62
9.161 X-Header-Enrichment-ID.........................................................................................................................9-63
9.162 X-Header-Enrichment-Data......................................................................................................................9-63
9.163 Final-Unit-Indication AVP........................................................................................................................9-63
9.164 Final-Unit-Action AVP.............................................................................................................................9-64
9.165 Restriction-Filter-Rule AVP......................................................................................................................9-64
9.166 Filter-Id AVP.............................................................................................................................................9-64
9.167 Redirect-Server AVP.................................................................................................................................9-65
9.168 Redirect-Address-Type AVP.....................................................................................................................9-65
9.169 Redirect-Server-Address AVP..................................................................................................................9-65
9.170 CT-Extension............................................................................................................................................9-65
9.171 Subnet-Identifier.......................................................................................................................................9-66
9.172 QoS-Group-Rule-Install...........................................................................................................................9-66
9.173 QoS-Group-Rule-Remove........................................................................................................................9-67
9.174 QoS-Group-Rule-Definition.....................................................................................................................9-67
9.175 QoS-Group-Rule-Name............................................................................................................................9-67
9.176 Redirect-Host............................................................................................................................................9-67
9.177 TDF-Information AVP..............................................................................................................................9-68
9.178 TDF-Destination-Host AVP......................................................................................................................9-68
9.179 TDF-IP-Address AVP...............................................................................................................................9-68
9.180 Rule-Failure-Code AVP (All access types)...............................................................................................9-68
List of abbreviations
1 Reference
IETF RFC 2865: "Remote Authentication Dial In User Service (RADIUS) ".
IETF RFC 3162: "RADIUS and IPv6".
IETF RFC 3588: "Diameter Base Protocol".
IETF RFC 4006: "Diameter Credit Control Application".
3GPP TR 21.905: "Vocabulary for 3GPP Specifications".
3GPP TS 29.208: "End-to-end Quality of Service (QoS) signalling flows".
3GPP TS 23.203: "Policy Control and Charging architecture".
3GPP TS 29.212: "Policy and Charging Control over Gx reference point".
3GPP TS 29.213: "Policy and charging control signalling flows and Quality of Service
(QoS) parameter mapping".
3GPP TS 29.214: "Policy and Charging Control over Rx reference point".
3GPP TS 23.060: "General Packet Radio Service (GPRS); Service description; Stage 2".
3GPP TS 29.060: "General Packet Radio Service (GPRS); GPRS Tunnelling Protocol
(GTP) across the Gn and Gp interface".
3GPP TS 29.061: "Interworking between the Public Land Mobile Network (PLMN)
supporting packet based services and Packet Data Networks (PDN)".
3GPP TS 24.008: "Mobile radio interface Layer 3 specification".
3GPP TS 29.230: "Diameter applications;3GPP specific codes and identifiers".
3GPP TS 32.240: "Telecommunication management; Charging management; Charging
architecture and principles".
3GPP TS 32.251: "Telecommunication management;Charging management;Packet
Switched (PS) domain charging".
3GPP TS 32.260: "Telecommunication management; Charging management; IP
Multimedia Subsystem (IMS) charging".
3GPP TS 32.298: "Telecommunication management; Charging management; Charging
Data Record (CDR) encoding rules description".
3GPP TS 32.299: "Telecommunication management; Charging management; Diameter
charging applications".
In PCC architecture, there are six main components listed as follows: PCEF, PCRF, AF, OCS,
OFCS and SPR. The PCRF encompasses policy control decision and flow based charging
control functionalities. The PCEF encompasses service data flow detection, policy
enforcement and flow based charging functionalities. The reference point between PCRF and
PCEF is Gx which is used for provisioning and removal of PCC rules from the PCRF to the
PCEF and the transmission of traffic plane events from the PCEF to the PCRF.
Figure 1.1 Figure 1.1shows the reference model for Gx.
Subscription Profile AF
Repository
(SPR)
Rx
PCEF
Gy
GW
Gz
Offline
Charging
System
(OFCS)
3 Terminology
PDP Session: for GPRS, PDP session is a unique association between a subscriber and
network access service, which is identified by the combination of UE identity, APN and IP
address. A PDP session consists of one primary context and zero or more secondary PDP
contexts.
IP-CAN Session: IP-CAN session refers to the association between a UE and a PDN
identifier(for GPRS, APN). The association is identified by a UE IP address together with a
UE identity information, if available. An IP-CAN session incorporates one or more IP-CAN
bearers. For GPRS, an IP-CAN session is equal to a PDP session.
IP-CAN Bearer: IP-CAN bearer is a IP transmission path for special service flows with
defined capacity, delay and bit error rate, etc. for GPRS, an IP-CAN bearer is equal to a PDP
context.
Network Requested Secondary PDP Context Activation: Network Requested Secondary
PDP Context Activation procedure (NRSPCA) is a new GPRS session management procedure
incorporated in 3GPP release 7, which allows the PCEF to initiate the secondary PDP context
activation procedure [23.060 section 9.2.2.1.1].
Bearer Control Mode: Bearer Control Mode determines which side can initiate the
secondary PDP context activation procedure, network or UE. If the negotiation result is UE
Only, only the UE side can initiate the secondary PDP context activation procedure. If the
negotiation result is NW Only, only the network side can initiate the secondary PDP context
activation procedure. If the negotiation result is Mixed, both UE side and Network side can
initiate the secondary PDP context activation procedure.
PCC Rule: PCC rule is a set of information enabling the detection of a service data flow and
providing parameters for policy control and/or charging control. Each PCC rule has a unique
name within IP-CAN Session.
Dynamic PCC Rule: Dynamic PCC rule is a type of PCC rule for which the definition is
provided into the PCEF via the Gx reference point. These PCC rules may be either predefined
or dynamically generated in the PCRF.
Pre-defined PCC Rule: Pre-defined PCC rule is a type of PCC rule that is provisioned
directly into the PCEF by the operator and is referenced by PCRF through its name. Pre-
defined PCC rules within the PCEF may be grouped allowing the PCRF to dynamically
activate a set of PCC rules over the Gx reference point.
Service Data Flow Filter: Service data flow filter consists of a set of parameters used to
identify one or more of the packet flows constituting a service data flow. A service data flow
filter of a PCC rule that is predefined in the PCEF may use parameters that extend the packet
inspection beyond the IP 5-tuple.
Service Data Flow Template: Service data flow template is the collection of service data
flow filters in a PCC rule, required for defining a service data flow.
Service Data Flow: A service data flow is an aggregate set of packet flows that matches a
service data flow template.
Bearer Binding: Bearer binding means the association between a service data flow and the
IP-CAN bearer transporting that service data flow.
Bearer Binding Mechanism: Bearer Binding Mechanism refers to the method for creating,
modifying and deleting bearer bindings. It can be classified into two types: PCRF-based
bearer binding and PCEF-Based bearer binding. For PCRF-Based bearer binding, the
association between SDF and IP-CAN bearer is determined solely by PCRF. For PCEF-Based
bearer binding, SDF is associated with IP-CAN bearer mainly by PCEF. The output of PCEF-
Based bearer binding is recognized as the input of NRSPCA procedure.
QoS Class Identifier: QoS class identifier is an identifier representing QoS parameters, such
as Transport-Class, Transport-Priority, excluding the bitrates.
Authorized QoS: Authorized QoS is the maximum QoS that is authorized by PCRF. Three
types of authorized QoS are identified over Gx reference point: QoS per IP-CAN Bearer, QoS
per QCI and QoS per PCC rule. For QoS per IP-CAN Bearer, it applies to all service data
flows with an IP-CAN Bearer. For QoS per QCI, it is similar to QoS per IP-CAN Bearer,
while it is used with PCEF-Based bearer binding. For QoS per PCC rule, it applies to all
service data flows within a rule and it is usually used within dynamic PCC rule.
Rating-Group: Rating-Group is the charging key used by the online and offline charging
system for rating purposes.
Service-Identifier: Service-Identifier provides the most detailed identification, specified for
flow based charging, of a service data flow.
4 Protocol Overview
4.1 Diameter
Diameter is an AAA protocol and it was derived from the Radius protocol with many
improvements in different aspects. Diameter was chosen by the 3GPP as the foundation for all
AAA functionalities including policy and charging control. Currently, the Diameter
specification consists of a base specification [Diameter Base Protocol], a Transport Profile
[AAATRANS] and some exteneded applications such as Diameter Credit Control Application,
Gx Application, etc.
4.3 Gx Application
It is well-known that PCC is an evolution of FBC and SBLP. FBC is defined in 3GPP release
6, and for which an new Diameter application is incorporated to provide charging control
functionalities and is named as Gx. SBLP is defined in 3GPP release 5, and an COPS based
application is incorporated to provide policy control functionalities and is named as Go. In
3GPP release 7, PCC merged Release 6 Gx application and Release 5 Go application into a
new application which is also named as Gx. Of course, Release 7 Gx application is an fire-
new one, and it can provides policy control functionalities and charging control functionalities
at the same time. Also, there are some Gx variants, most of which are vendor specific and are
entended on the basis of 3GPP Release 6 Gx application.
In this version, only Release 7 Gx application is implemented, but it is extensible to add
adaption for Release 6 Gx application and other vendor specific variants.
For 3GPP Release 7 Gx application, Please refer to TS29.212 for details.
5 Transport
The Diameter Base Protocol mandates that the diameter server must support TCP and SCTP,
and mandates that the client must support either TCP or SCTP.
Please refer to RFC3588 for details.
6 Constraints
Huawei currently does not foresee any commercial demand for UE initialled QoS control, and the UE-
Initiated secondary PDP context activation procedure is to complex for the UE and not widely supported
in commercially available terminals. In the future UPCC will focus on the network centric QoS control
mechanism where dedicated bearers (i.e. secondary PDP contexts) are always established, modified, and
released by the network, and default bearers (i.e. primary PDP contexts) are only modified by the
network.
6.3 Limitations
Huawei UPCC can only accept 10 service level quota slices and 1 session level quota
slice at the same time in one CCR/RAA message.
Huawei UPCC can only send 10 service level quota slices and 1 session level quota slice
at the same time in one RAR/CCA message.
7 Messages
{ Vendor-Id }
{ Product-Name }
[ Origin-State-Id ]
* [ Supported-Vendor-Id ]
* [ Auth-Application-Id ]
* [ Inband-Security-Id ]
* [ Acct-Application-Id ]
* [ Vendor-Specific-Application-Id ]
[ Firmware-Revision ]
* [ AVP ]
7.2.3 Disconnect-Peer-Request(DPR)
The Disconnect-Peer-Request (DPR), indicated by the Command-Code set to 282 and the
Command Flags' 'R' bit set, is sent to a peer to inform its intentions to shutdown the transport
connection.
Message syntax:
<DPR>::= < Diameter Header: 282, REQ >
{ Origin-Host }
{ Origin-Realm }
{ Disconnect-Cause }
7.2.4 Disconnect-Peer-Answer(DPA)
The Disconnect-Peer-Answer (DPA), indicated by the Command-Code set to 282 and the
Command Flags' 'R' bit cleared, is sent as a response to the Disconnect-Peer-Request
message.
Message syntax:
<DPA>::= < Diameter Header: 282 >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ Error-Message ]
* [ Failed-AVP ]
7.2.5 Device-Watchdog-Request(DWR)
The Device-Watchdog-Request (DWR), indicated by the Command-Code set to 280 and the
Command Flags' 'R' bit set, is sent to a peer during idle time to pro-actively detect transport
failures.
Message syntax:
<DWR>::= < Diameter Header: 280, REQ >
{ Origin-Host }
{ Origin-Realm }
[ Origin-State-Id ]
7.2.6 Device-Watchdog-Answer(DWA)
The Device-Watchdog-Answer (DWA), indicated by the Command-Code set to 280 and the
Command Flags' 'R' bit cleared, is sent as a response to the Device-Watchdog-Request
message.
Message syntax:
<DWA>::= < Diameter Header: 280 >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ Error-Message ]
* [ Failed-AVP ]
[ Original-State-Id ]
7.2.7 Abort-Session-Request(ASR)
The Abort-Session-Request (ASR), indicated by the Command-Code set to 274 and the
message flags' 'R' bit set, may be sent by any server to the access device that is providing
session service, to request that the session identified by the Session-Id be stopped.
Message syntax:
<ASR>::= < Diameter Header: 274, REQ, PXY >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Destination-Host }
{ Auth-Application-Id }
[ Origin-State-Id ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]
* [ Failed-AVP ]
* [ Redirect-Host ]
[ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ]
* [ Proxy-Info ]
* [ AVP ]
7.3 Gx Messages
7.3.1 Credit-Control-Request (CCR)
The CCR command, indicated by the Command-Code field set to 272 and the 'R' bit set in the
Command Flags field, is sent by the PCEF to the PCRF in order to request PCC rules for a
bearer. The CCR command is also sent by the PCEF to the PCRF in order to indicate bearer or
PCC rule related events or the termination of the IP CAN bearer and/or session.
Message syntax:
<CC-Request> ::= < Diameter Header: 272, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ CC-Request-Type }
{ CC-Request-Number }
[ Destination-Host ]
[ Origin-State-Id ]
*[ Subscription-Id ]
*[ Supported-Features ]
[ TDF-Information ]
[ Bearer-Control-Mode ]
[ Network-Request-Support ]
*[ Packet-Filter-Information ]
[ Packet-Filter-Operation ]
[ Bearer-Identifier ]
[ Bearer-Operation ]
[ Framed-IP-Address ]
[ Framed-IPv6-Prefix ]
[ IP-CAN-Type ]
[3GPP-RAT-Type]
[RAT-Type]
[ Termination-Cause ]
[ User-Equipment-Info ]
[ QoS-Information ]
[ QoS-Negotiation ]
[ QoS-Upgrade ]
[ AN-GW-Address ]
[ 3GPP-SGSN-MCC-MNC ]
[ 3GPP-SGSN-Address ]
[ 3GPP-SGSN-IPv6-Address ]
[ RAI ]
[ 3GPP-User-Location-Info]
[ 3GPP-MS-TimeZone ]
[ Called-Station-ID ]
[ Bearer-Usage ]
[ Online ]
[ Offline ]
*[ TFT-Packet-Filter-Information ]
*[ Charging-Rule-Report]
*[ Event-Trigger]
[X-HW-Tethering-Status]
[ Access-Network-Charging-Address ]
*[ Access-Network-Charging-Identifier-Gx ]
[X-HW-Usage-Report]
*[ Usage-Monitoring-Information ]
*[ Proxy-Info ]
*[ Route-Record ]
[X-HW-Cell-Congestion-Level]
*[Application-Detection-Information]
[X-HW-User-Physical-Info-Value]
*[ ADC-Rule-Report ]
*[ AVP ]
*[ Usage-Monitoring-Information ]
*[ X-HW-Subscriber-Service-Definition ]
[X-HW-Session-Restoration]
[X-HW-Content-Filter]
[X-HW-Content-Filter-Information]
[ Error-Message ]
[ Error-Reporting-Host ]
*[ Failed-AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
*[ ADC-Rule-Install]
*[ ADC-Rule-Remove]
[X-Header-Enrichment]
*[ AVP ]
*[ Charging-Rule-Install ]
*[ QoS-Group-Rule-Remove ]
*[ QoS-Group-Rule-Install ]
[ Default-EPS-Bearer-QoS ]
*[ QoS-Information ]
[ X-HW-Usage-Report ]
[Revalidation-Time]
*[ Usage-Monitoring-Information ]
*[ X-HW-Subscriber-Service-Definition ]
[X-HW-Content-Filter]
[X-HW-Content-Filter-Information]
*[ Proxy-Info ]
*[ Route-Record ]
*[ ADC-Rule-Install]
*[ ADC-Rule-Remove]
*[ AVP]
[ Error-Reporting-Host ]
*[ Failed-AVP ]
*[ Proxy-Info ]
*[ ADC-Rule-Report ]
*[ AVP ]
8 Procedures
All signaling flows in this section are only for illustration purpose, so subtle difference between
description here and real implementation is allowed as long as it does not affect interoperability.
4. The GGSN validates the Create PDP Context Request, and on success, creates a new
entry in its PDP context table and IP-CAN session table. If PCC is enabled for the
designated APN, the GGSN will select a proper PCRF and associate it with the current
IP-CAN session. And then, the GGSN sends a Credit-Control-Request message to the
selected PCRF, indicating the establishment of the IP-CAN Session.
5. The PCRF makes a multi-dimensional authorization decision for this IP-CAN session,
based on all available information such as subscription, time, location, service, dynamic
AF session parameters, etc. And then, the PCRF returns the authorization result in
Credit-Control-Answer message to the GGSN.
6. The GGSN installs PCC rules and enforces authorized QoS according to the PCRFs
request. The GGSN continues all required steps for primary PDP context activation, and
on successful completion, the GGSN sends back a Create PDP Context Response(TEID,
PDP Address, Protocol Configuration Options, QoS Negotiated, Charging Id, Prohibit
Payload Compression, APN Restriction, Cause, CGI/SAI/RAI change report required,
BCM) message to the SGSN.
7. The SGSN verifies the Create PDP Context Response message and saves all necessary
information in its own context. In the end, the RAD is setup and the SGSN returns a
Activate PDP Context Accept (PDP Type, PDP Address, TI, QoS Negotiated, Radio
Priority, Packet Flow Id, Protocol Configuration Options) message to the UE.
1. The MS sends a Modify PDP Context Request (TI, QoS Requested, TFT, and Protocol
Configuration Options) message to the SGSN.
2. The SGSN validates the Modify PDP Context Request and sends an Update PDP
Context Request message to the GGSN.
3. The GGSN validates the Update PDP Context Request and locates the corresponding
PDP context and IP-CAN session. If PCC is enabled for this IP-CAN session, event-
triggers subscribed by PCRF will be checked. Once one or more event-triggers are met,
the GGSN will send a Credit-Control-Request message to the associated PCRF,
indicating the modification of the IP-CAN bearer.
4. The PCRF re-calculate authorization according to reported updates and returns the result
in Credit-Control-Answer message to the GGSN.
5. The GGSN installs, modifies, or removes PCC rules and enforces the authorized QoS
according to PCRFs indication. The GGSN replies Update PDP Context Response
message to the SGSN.
6. The SGSN verifies the Update PDP Context Response message and saves all necessary
information in its own context. After the RAB modified the SGSN returns a Modify PDP
Context Accept (TI, QoS Negotiated, Radio Priority, Packet Flow Id, and Protocol
Configuration Options) message to the UE.
the GGSN will send a Credit-Control-Request message to the PCRF, indicating the
termination of the IP-CAN session.
4. The PCRF revoke authorization for this IP-CAN session, and returns a confirming
Credit-Control-Answer message to the GGSN.
5. The GGSN removes all PCC rules bind with the IP-CAN session, release resources and
reply the SGSN with a Delete PDP Context Response message.
6. The SGSN release corresponding resources and sends back a Deactivate PDP Context
Accept message to the UE.
1. The PCRF receives an internal (e.g. special hour of day) or external trigger (AF session
established) to re-evaluate policy decision for an IP-CAN Session. If policy update is
needed the PCRF sends a Re-Auth Request message to the GGSN with new rules and
updated QoS.
2. The GGSN validates the Re-Auth Request message and Locates the IP-CAN session,
install/remove indicated rules, update QoS and response with Re-Auth Response
message to the PCRF.
3. If authorized QoS is updated GGSN will initial QoS reservation process. The GGSN
sends an Update PDP Context Request message to the SGSN.
4. In case of any error occur during the QoS reservation process, correlated rules will be
deactivated and GGSN shall create and send a CC-Request message with CC-Request-
Type set to be Update and contains one or more Charging-Rule-Report AVP to report
the infected rules.
5. Upon receiving a CC-Request with Charging-Rule-Report, the PCRF will recalculate
policies base on the infected rules and response with CC-Answer. Further interaction
may be needed to send notify to AF via Rx interface in case of AF session involved.
1. When the PCRF detects that the termination of an IP-CAN Session is required (e.g.
internal exception or subscriber locked), the PCRF will send an Abort-Session-Request
message to the GGSN.
Another way to initial session termination by PCRF is issue a RAR message with Session-Release-
Cause AVP.
2. The GGSN validates the Abort-Session-Request and locates the IP-CAN session. The
GGSN replies Abort-Session-Answer message to the PCRF and start the IP-CAN session
termination:
The GGSN s ends a Delete PDP Context Request message to the SGSN.
The SGSN sends a Deactivate PDP Context Request message to the UE.
The MS removes the PDP context and returns a Deactivate PDP Context Accept
message to the SGSN. At the same time, RAB for this PDP context is scheduled to
release.
The SGSN returns a Delete PDP Context Response (TEID) message to the GGSN.
The GGSN continues the processing steps for PDP deactivation, and on completion,
releases the PDP context table entry.
3. Upon completion, the GGSN release the IP-CAN session table entry, and sends a Credit-
Control-Request message to the PCRF, indicating the IP-CAN session is successfully
terminated.
4. The PCRF simply acknowledges and returns a Credit-Control-Answer message to the
GGSN.
From release V300R002C05 Huawei UPCC can supports 3GPP R9 Usage Monitoring mechanism,
which not described here. For more detail about 3GPP R9 Usage Monitoring please refer 3GPP
TS29.212.
In this release, only volume based threshold can be supported, and service is identified by the
combination of Rating-Group and Service-Identifier.
From the release of UPCC V300R002C05, the Service-Identifier will not be used to identify usage
combination, and the UPCC will not given Service-Identifier AVP in the X-HW-Service-Usage.
From the release of UPCC V300R002C05, the Rating-Group used for usage combination will be
replaced by the concept of Monitoring-Key, but same AVP will be used. That means, in the X-HW-
Service-Usage the Rating-Group shall be treated as the X-HW-Monitoring-Key.
When usage monitoring and reporting is enabled, the PCEF shall report accumulated usage to the
PCRF in the following conditions:
When a usage threshold is reached.
When all PCC rules for which usage monitoring and reporting is enabled for a
particular usage monitoring key are removed or deactivated.
8.8 Audit
Periodical audit is a frequently used technique for re-synchronization of state and it can be
used over Gx reference point. The following figure exemplifies the signaling flows for this
procedure.
PCRF Initiated IP-CAN Session Audit
To make sure every IP-CAN session table entry in use is aligned with PCEF, the PCRF can
periodically check with the PCEF by exchanging audit messages using Re-Auth-Request/Re-
Auth-Answer messages.
Figure 7.2 exemplifies the signaling flows for this procedure.
1. When periodical audit timer is expired, one or more IP-CAN sessions in use is selected
by PCRF for audit purpose. For each of these IP-CAN sessions, the PCRF sends an
empty Re-Auth-Request message to the PCEF with all inessential elements truncated.
2. The PCEF checks whether the IP-CAN session is still active (base on session-id) or not.
The PCEF negatively acknowledges by returning a Re-Auth-Answer message to the
PCRF with Result-Code set to DIAMETER_UNKNOWN_SESSION_ID if the
session is not exists on PCEF, otherwise the Result-Code set to Success if this session
still live.
3. Upon the receipt of Re-Auth-Answer message from the PCEF, the PCRF checks the
Result-Code. If it is DIAMETER_UNKNOWN_SESSION_ID, IP-CAN session will
be removed by PCRF locally.
PCEF Initiated IP-CAN Session Audit
To make sure every IP-CAN session table entry in use is aligned with PCRF, the PCEF can
periodically check with the PCRF by exchanging audit messages.
Figure 3.1 exemplifies the signaling flows for this procedure.
1. When periodical audit timer is expired, one or more IP-CAN sessions in use is selected
by PCEF for audit purpose. For each of these IP-CAN sessions, the PCEF sends a
Credit-Control-Request message to the PCRF, with all inessential elements truncated.
2. The PCRF checks whether the authorization of this IP-CAN session is still valid, and if it
is not, the PCRF negatively acknowledges by returning a Credit-Control-Answer
message to the PCEF, with Result-Code set to
DIAMETER_UNKNOWN_SESSION_ID.
3. Upon the receipt of Credit-Control-Answer message from the PCRF, the PCEF checks
the Result-Code. If it is DIAMETER_UNKNOWN_SESSION_ID, IP-CAN session
will be removed by PCEF locally.
9 AVPs Definition
9.1 Session-Id
The Session-Id AVP (AVP Code 263) is of type UTF8String is generated by PCEF to identify
a specific IP-CAN session. All messages pertaining to a specific IP-CAN session include only
one Session-Id AVP and the same value is used throughout the life of IP-CAN session. When
present, the Session-Id appears immediately following the Diameter Header.
The Session-Id includes a mandatory portion and an implementation - defined portion, and the
protocol recommended format is followed:
<DiameterIdentity>;<high 32 bits>;<low 32 bits>[;<optional value>]
For details, please refer to IETF RFC 3588.
9.2 Auth-Application-Id
The Auth-Application-Id AVP (AVP Code 258) is of type Unsigned32 and is used here to
advertise support of the Gx, Gxx application.
Now, only 3GPP Gx and Gxx application is supported, so this AVP will be encoded fixedly as
the value of 16777238 and 16777266.
For details, please refer to IETF RFC 3588, 3GPP TS 29.212 and 3GPP TS 29.230.
9.3 Vendor-Id
The Vendor-Id AVP (AVP Code 266) is of type Unsigned32 and contains the IANA "SMI
Network Management Private Enterprise Codes" value assigned to the vendor of the Diameter
application. In combination with the Supported-Vendor-Id AVP, this may be used in to know
which vendor specific attributes may be sent to the peer. It is also envisioned that the
combination of the Vendor-Id, Product-Name and the Firmware-Revision AVPs may provide
very useful debugging information. A Vendor-Id value of zero in the CER or CEA messages is
reserved and indicates that this field is ignored.
For details, please refer to IETF RFC 3588, 3GPP TS 29.212 and 3GPP TS 29.230.
9.4 Product-Name
The Product-Name AVP (AVP Code 269) is of type UTF8String, and contains the vendor
assigned name for the product.
For details, please refer to IETF RFC 3588.
9.5 Supported-Vendor-Id
The Supported-Vendor-Id AVP (AVP Code 265) is of type Unsigned32 and contains the IANA
"SMI Network Management Private Enterprise Codes" [ASSIGNNO] value assigned to a
vendor other than the device vendor. This is used in the CER and CEA messages in order to
inform the peer that the sender supports (a subset of) the vendor-specific AVPs defined by the
vendor identified in this AVP.
For details, please refer to IETF RFC 3588, 3GPP TS 29.212 and 3GPP TS 29.230.
In this version of Gx and Gxx application, 3GPP (10415) and 3GPP2 (5535) can be advertised
in this AVP between peers.
9.6 Firmware-Revision
The Firmware-Revision AVP (AVP Code 267) is of type Unsigned32 and is used to inform a
Diameter peer of the firmware revision of the issuing device.
For details, please refer to IETF RFC 3588.
9.7 Vendor-Specific-Application-Id
The Vendor-Specific-Application-Id AVP (AVP Code 260) is of type Grouped and is used to
in capability exchange procedure to advertise support of a vendor-specific Diameter
Application. Its Data field has the following ABNF grammar:
<Vendor-Specific-Application-Id> ::= < AVP Header: 260 >
1* [ Vendor-Id ]
0*1{ Auth-Application-Id }
0*1{ Acct-Application-Id }
In this version, Verdor-Id AVP is set to 3GPP (10415), one Auth-Application-Id is included
and is set 3GPP Release 7 Gx application(16777238), and Acct-Application-Id AVP is not
used.
For details, please refer to IETF RFC 3588 and 3GPP TS 29.212.
9.8 Origin-Host
The Origin-Host AVP (AVP Code 264) is of type DiameterIdentity, and is present in all
Diameter messages to identify the endpoint that originated the Diameter message. For
messages generated by GGSN, it is encoded as the PCEFs host identifier. For messages
generated by PCRF, it is encoded as the PCRFs host identifier.
For details, please refer to IETF RFC 3588.
9.9 Origin-Realm
The Origin-Realm AVP (AVP Code 296) is of type DiameterIdentity and is present in all
messages to identify the realm of the originator.
For details, please refer to IETF RFC 3588.
9.10 Destination-Host
The Destination-Host AVP (AVP Code 293) is of type DiameterIdentity. This AVP is always
presented in all unsolicited agent initiated messages, may be presented in request messages,
and is never presented in answer messages.
For details, please refer to IETF RFC 3588.
9.11 Destination-Realm
The Destination-Realm AVP (AVP Code 283) is of type DiameterIdentity, and contains the
realm the message is to be routed to.
For details, please refer to IETF RFC 3588.
9.12 Termination-Cause
The Termination-Cause AVP (AVP Code 295) is of type Enumerated, and is used to indicate
the reason why a IP-CAN session was terminated. The Termination-Cause AVP can only be
presented in Credit-Control-Request messages. The following values are defined:
4. DIAMETER_LOGOUT(1)
The user initiated a disconnect.
5. DIAMETER_SERVICE_NOT_PROVIDED(2)
This value is used when the user disconnected prior to the receipt of the authorization
answer message.
6. DIAMETER_BAD_ANSWER(3)
This value indicates that the authorization answer received by the access device was not
processed successfully.
7. DIAMETER_ADMINISTRATIVE(4)
The user was not granted access, or was disconnected, due to administrative reasons,
such as the receipt of a Abort-Session-Request message.
8. DIAMETER_LINK_BROKEN(5)
The communication to the user was abruptly disconnected.
9. DIAMETER_AUTH_EXPIRED(6)
The user's access was terminated since its authorized session time has expired.
10. DIAMETER_USER_MOVED(7)
The user is receiving services from another access device.
11. DIAMETER_SESSION_TIMEOUT(8)
The user's session has timed out, and service has been terminated.
For details, please refer to IETF RFC 3588.
9.13 Disconnect-Cause
The Disconnect-Cause AVP (AVP Code 273) is of type Enumerated and is included in the
Disconnect-Peer-Request message to inform the peer of the reason for its intention to
shutdown the transport connection. The following values are defined:
12. REBOOTING(0)
A scheduled reboot is imminent.
13. BUSY(1)
The peer's internal resources are constrained, and it has determined that the transport
connection needs to be closed.
14. DO_NOT_WANT_TO_TALK_TO_YOU(2)
The peer has determined that it does not see a need for the transport connection to exist,
since it does not expect any messages to be exchanged in the near future.
For details, please refer to IETF RFC 3588.
9.14 Origin-State-Id
The Origin-State-Id AVP (AVP Code 278), of type Unsigned32 and is used to allow rapid
detection of termination of sessions due to unanticipated shutdown of an access device.
In this version, it is not used, i.e., for messages originated from PCEF Origin-State-Id AVP is
always absent, and for messages from PCRF, Origin-State-Id AVP is always ignored.
For details, please refer to IETF RFC 3588.
9.15 Result-Code
The Result-Code AVP (AVP Code 268) is of type Unsigned32 and indicates whether a
particular request was completed successfully or whether an error occurred. The Result-Code
data field contains an IANA-managed 32-bit address space representing errors. Diameter
provides the following classes of errors, all identified by the thousands digit in the decimal
notation:
15. 1xxx (Informational)
16. 2xxx (Success)
17. 3xxx (Protocol Errors)
18. 4xxx (Transient Failures)
19. 5xxx (Permanent Failure)
A non-recognized class (one whose first digit is not defined above) is considered to be a
permanent failure.
For details, please refer to IETF RFC 3588.
9.16 Experimental-Result
The Experimental-Result AVP (AVP Code 297) is of type Grouped, and indicates whether a
particular vendor-specific request was completed successfully or whether an error occurred.
Its Data field has the following ABNF grammar:
Experimental-Result ::= < AVP Header: 297 >
{ Vendor-Id }
{ Experimental-Result-Code }
For Gx application, The Vendor-ID AVP is set to 3GPP (10415), and Experimental-Result-
Code is set to a vendor assigned value.
For details, please refer to IETF RFC 3588 and 3GPP TS 29.212.
9.17 Error-Message
The Error-Message AVP (AVP Code 281) is of type UTF8String and it is optionally used to
accompany a Result-Code AVP or Experimental-Result AVP as a human readable error
message.
For details, please refer to IETF RFC 3588.
9.18 Failed-AVP
The Failed-AVP AVP (AVP Code 279) is of type Grouped and is optionally used to
accompany a Result-Code AVP or Experimental-Result AVP to provide debugging
information about erroneous details of a specific AVP.
For details, please refer to IETF RFC 3588.
9.19 Re-Auth-Request-Type
The Re-Auth-Request-Type AVP (AVP Code 285) is of type Enumerated and is used to inform
the client of the action expected upon expiration of the Authorization-Lifetime. This AVP is
syntactically mandatory In Re-Auth-Request message, but in fact, for Gx application it is
useless.
For details, please refer to IETF RFC 3588, IETF RFC4006 and 3GPP TS 29.212.
9.20 Called-Station-ID
The Called-Station-Id AVP (AVP Code 30) is of type UTF8String and is used to describe the
address the user is connected to. For GPRS, it is encoded as the APN.
For details, please refer to IETF RFC 4005 and 3GPP TS 29.212.
9.21 Framed-IP-Address
The Framed-IP-Address AVP (AVP Code 8) [RADIUS] is of type OctetString and contains an
IPv4 address allocated for the user.
For details, please refer to IETF RFC 4005 and 3GPP TS 29.212.
9.22 Framed-IPv6-Prefix
The Framed-IPv6-Prefix AVP (AVP Code 97) is of type OctetString and contains the IPv6
prefix allocated for the user. The encoding of the value shall be as defined in IETF RFC 3162,
Clause 2.3. The "Reserved", "Prefix-Length" and "Prefix" fields shall be included in this
order.
For details, please refer to IETF RFC 3162, IETF RFC 4005 and 3GPP TS 29.212.
9.23 CC-Request-Type
The CC-Request-Type AVP (AVP Code 416) is of type Enumerated and contains the reason
for sending the credit-control request message. It is present in all Credit-Control-Request
messages.
In this version, following values are defined for the CC-Request-Type AVP:
20. INITIAL_REQUEST(1)
An Initial request is used to initiate a credit-control session, and contains credit control
information that is relevant to the initiation.
21. UPDATE_REQUEST(2)
An Update request contains credit-control information for an existing credit-control
session. Update credit-control requests are sent every time a credit-control re-
authorization event is triggered.
22. TERMINATION_REQUEST(3)
A Termination request is sent to terminate a credit-control session and contains credit-
control information relevant to the existing session.
For details, please refer to IETF RFC 4006.
9.24 CC-Request-Number
The CC-Request-Number AVP (AVP Code 415) is of type Unsigned32 and identifies this
request within one session. As Session-Id AVPs are globally unique, the combination of
Session-Id and CC-Request-Number AVPs is also globally unique and can be used in
matching credit-control messages with confirmations.
For details, please refer to IETF RFC 4006.
9.25 Rating-Group
The Rating-Group AVP is of type Unsigned32 (AVP Code 432) and contains the identifier of a
rating group. All the services subject to the same rating type are part of the same rating group.
For details, please refer to IETF RFC 4006.
9.26 Service-Identifier
The Service-Identifier AVP is of type Unsigned32 (AVP Code 439) and contains the identifier
of a service.
For details, please refer to IETF RFC 4006.
9.27 Subscription-Id
The Subscription-Id AVP (AVP Code 443) is used to identify the end user's subscription
(IMSI, MSISDN, etc) and is of type Grouped. The Subscription-Id AVP includes a
Subscription-Id-Data AVP that holds the identifier and a Subscription-Id-Type AVP that
defines the identifier type. It is defined as follows:
Subscription-Id ::= < AVP Header: 443 >
{ Subscription-Id-Type }
{ Subscription-Id-Data }
For details, please refer to IETF RFC 4006.
9.28 User-Equipment-Info
The User-Equipment-Info AVP (AVP Code 458) is of type Grouped and allows the credit-
control client to indicate the identity and capability (IMEISV, etc.) of the terminal the
subscriber is using for the connection to network. It is defined as follows:
User-Equipment-Info ::= < AVP Header: 458 >
{ User-Equipment-Info-Type }
{ User-Equipment-Info-Value }
For details, please refer to IETF RFC 4006.
9.29 3GPP-RAT-Type
3GPP-RAT-Type AVP is defined as an extension to RADIUS attribute Vendor-Specific and
is used to indicate which Radio Access Technology is currently serving the UE. For this AVP,
the value field of Vendor-Specific attribute is encoded as follows:
Bits
Octets 8 7 6 5 4 3 2 1
1 3GPP type = 21
2 3GPP Length= 3
3 RAT (octet string)
For details, please refer to IETF RFC 2865 and 3GPP TS 29.061.
9.30 3GPP-SGSN-Address
3GPP-SGSN-Address AVP is defined as an extension to RADIUS attribute Vendor-Specific
and is used to indicate the SGSN IPV4 address that is used by the GTP control plane. It may
be used to identify the PLMN to which the user is attached. For this AVP, the value field of
Vendor-Specific attribute is encoded as follows:
Bits
Octets 8 7 6 5 4 3 2 1
1 3GPP type = 6
2 3GPP Length= 6
3 SGSN addr Octet 1
4 SGSN addr Octet 2
5 SGSN addr Octet 3
6 SGSN addr Octet 4
For details, please refer to IETF RFC 2865 and 3GPP TS 29.061.
9.31 3GPP-SGSN-IPv6-Address
3GPP-SGSN-IPv6-Address AVP is defined as an extension to RADIUS attribute Vendor-
Specific and is used to indicate the SGSN IPV6 address that is used by the GTP control
plane. It may be used to identify the PLMN to which the user is attached. For this AVP, the
value field of Vendor-Specific attribute is encoded as follows:
Bits
Octets 8 7 6 5 4 3 2 1
1 3GPP type = 15
2 3GPP Length= 18
3 SGSN IPv6 addr Octet 1
4 SGSN IPv6 addr Octet 2
5-18 SGSN IPv6 addr Octet 3-16
For details, please refer to IETF RFC 2865 and 3GPP TS 29.061.
9.32 3GPP-SGSN-MCC-MNC
3GPP-SGSN-MCC-MNC AVP is defined as an extension to RADIUS attribute Vendor-
Specific and is used to indicate the MCC and MNC of the SGSN. It is extracted from the
RAI within the Create PDP Context Request or Update PDP Context Request message. For
this AVP, the value field of Vendor-Specific attribute is encoded as follows:
Bits
Octets 8 7 6 5 4 3 2 1
1 3GPP type = 18
2 3GPP Length= n
3 MCC digit1 (UTF-8 encoded character)
4 MCC digit2 (UTF-8 encoded character)
5 MCC digit3 (UTF-8 encoded character)
6 MNC digit1 (UTF-8 encoded character)
7 MNC digit2 (UTF-8 encoded character)
8 MNC digit3 if present (UTF-8 encoded character)
For details, please refer to IETF RFC 2865 and 3GPP TS 29.061.
9.33 3GPP-User-Location-Info
3GPP-User-Location-Info AVP is defined as an extension to RADIUS attribute Vendor-
Specific and is used to indicate details of where the UE is currently located (e.g. SAI or
CGI). For this AVP, the value field of Vendor-Specific attribute is encoded as follows:
Bits
Octets 8 7 6 5 4 3 2 1
1 3GPP type = 22
2 3GPP Length= m
3 Geographic Location Type
4-m Geographic Location (octet string)
For details, please refer to IETF RFC 2865 and 3GPP TS 29.061.
The supported Geographic Location Type is as follow, which is defined in 3GPP TS 29.274.
0 CGI
1 SAI
2 RAI
128 TAI
129 ECGI
130 TAI and ECGI
9.34 RAI
The RAI AVP (AVP Code 909) is of type UTF8String, and contains the Routing Area Identity
of the SGSN where the UE is registered.
For details, please refer to 3GPP TS 29.061 and 3GPP TS 23.003.
9.37 AF-Charging-Identifier
The AF-Application-identifier AVP (AVP code 504) is of type OctetString, and it contains
information that may be used in charging correlation, For IMS the ICID.
For details, please refer to 3GPP TS29.214.
9.38 Flow-Description
The Flow-Description AVP (AVP code 507) is of type IPFilterRule, and defines a packet filter
for an IP flow with the following information:
Direction (in or out).
Source and destination IP address (possibly masked).
Protocol.
Source and destination port (The Source Port may be omitted to indicate that any source
port is allowed.).
The IPFilterRule type shall be used with the following restrictions:
Only the Action "permit" shall be used.
No "options" shall be used.
The invert modifier "!" for addresses shall not be used.
The keyword "assigned" shall not be used.
The direction "in" refers to uplink IP flows, and the direction "out" refers to downlink IP
flows.
For details, please refer to IETF RFC 3588 and 3GPP TS 29.214.
9.39 Flows
The Flows AVP (AVP code 510) is of type Grouped, and it indicates the flow identifiers of the
IP flows related to a PCC rule as provided by the AF. It may be only used in charging
correlation together with AF-Charging-Identifier AVP. AVP Format is defined as follows:
Flows::= < AVP Header: x >
{ Media-Component-Number}
*[ Flow-Number]
For details, please refer to 3GPP TS 29.212 and 3GPP TS 29.214.
9.40 Flow-Status
The Flow-Status AVP (AVP code 511) is of type Enumerated, and describes whether the IP
flow(s) are enabled or disabled. The following values are defined:
23. ENABLED-UPLINK (0)
This value shall be used to enable associated uplink IP flow(s) and to disable associated
downlink IP flow(s).
24. ENABLED-DOWNLINK (1)
This value shall be used to enable associated downlink IP flow(s) and to disable
associated uplink IP flow(s).
25. ENABLED (2)
This value shall be used to enable all associated IP flow(s) in both directions.
26. DISABLED (3)
This value shall be used to disable all associated IP flow(s) in both directions.
For details, please refer to 3GPP TS 29.212 and 3GPP TS 29.214.
9.41 Max-Requested-Bandwidth-UL
The Max -Bandwidth-UL AVP (AVP code 516) is of type Unsigned32, and it indicates the
maximum requested bandwidth in bits per second for an uplink IP flow. The bandwidth
contains all the overhead coming from the IP-layer and the layers above, e.g. IP, UDP, RTP
and RTP payload.
For details, please refer to 3GPP TS29.212 and 3GPP TS 29.214.
9.42 Max-Requested-Bandwidth-DL
The Max-Requested-Bandwidth-DL AVP (AVP code 515) is of type Unsigned32, and it
indicates the maximum bandwidth in bits per second for a downlink IP flow. The bandwidth
contains all the overhead coming from the IP-layer and the layers above, e.g. IP, UDP, RTP
and RTP payload.
For details, please refer to 3GPP TS29.212 and 3GPP TS 29.214.
9.43 Charging-Information
The Charging-Information AVP (AVP Code 618) is of type Grouped, and contains the
addresses of the charging functions. AVP format is depicted as follows:
Charging-Information :: = < AVP Header : 618 10415 >
[ Primary-Event-Charging-Function-Name ]
[ Secondary-Event-Charging-Function-Name ]
[ Primary-Charging-Collection-Function-Name ]
[ Secondary-Charging-Collection-Function-Name ]
*[ AVP]
27. Primary-Event-Charging-Function-Name is of type DiameterURI and defines the address
of the primary online charging system. The protocol definition in the DiameterURI shall
be either omitted or supplied with value "Diameter".
28. Secondary-Event-Charging-Function-Name is of type DiameterURI and defines the
address of the secondary online charging system for the bearer. The protocol definition in
the DiameterURI shall be either omitted or supplied with value "Diameter".
29. Primary-Charging-Collection-Function-Name is of type DiameterURI and defines the
address of the primary offline charging system for the bearer. If the GTP' protocol is
applied on the Gz interface as specified in 3GPP TS 32.295 [16], the protocol definition
in the DiameterURI shall be omitted. If Diameter is applied on the Gz interface, the
protocol definition in DiameterURI shall be either omitted or supplied with value
"Diameter". The choice of the applied protocol on the Gz interface depends upon
configuration in the PCEF.
30. Secondary-Charging-Collection-Function-Name is of type DiameterURI and defines the
address of the secondary offline charging system for the bearer. If the GTP' protocol is
applied on the Gz interface as specified in 3GPP TS 32.295 [16], the protocol definition
in the DiameterURI shall be omitted. If Diameter is applied on the Gz interface, the
protocol definition in DiameterURI shall be either omitted or supplied with value
"Diameter". The choice of the applied protocol on the Gz interface depends upon
configuration in the PCEF.
For details, please refer to 3GPP TS29.212 and 3GPP TS 29.229.
9.44 Access-Network-Charging-Identifier-Gx
The Access-Network-Charging-Identifier-Gx AVP (AVP code 1022) is of type Grouped. It
contains a charging identifier (e.g. GCID) within the Access-Network-Charging-Identifier-
Value AVP and the related PCC rule name(s) within the Charging-Rule-Name AVP(s). The
AVP format is depicted as follows:
Access-Network-Charging-Identifier-Gx ::=< AVP Header: 1022 >
{ Access-Network-Charging-Identifier-Value}
*[ Charging-Rule-Base-Name ]
*[ Charging-Rule-Name ]
In this version, only GCID will be reported to PCRF, i.e., neither Charging-Rule-Name nor
Charging-Rule-Base-Name is reported to PCRF.
For details, please refer to 3GPP TS 29.212.
9.45 Bearer-Control-Mode
The Bearer-Control-Mode AVP (AVP code 1023) is of type of Enumerated. When sent from
PCEF to PCRF, it indicates the UE preferred bearer control mode. When sent from PCRF to
PCEF, it indicates the PCRF selected bearer control mode. If the Bearer-Control-Mode AVP
has not been previously provided by the PCEF, its absence shall indicate the value UE_ONLY.
If the Bearer-Control AVP has been provided, its value shall remain valid until it is provided
the next time. The following values are defined:
31. UE_ONLY (0)
This value is used to indicate that the UE shall request any additional bearer
establishment.
32. NW_ONLY (1)
This value is used to indicate that the PCEF shall request any additional bearer
establishment.
33. UE_NW (2)
This value is used to indicate that both the UE and PCEF may request any additional
bearer establishment and add own traffic mapping information to an IP-CAN bearer.
For details, please refer to 3GPP TS 29.212.
9.46 Bearer-Identifier
The Bearer-Identifier AVP (AVP code 1020) is of type OctetString, and it indicates the bearer
to which specific information refers. It is selected solely by the PCEF and its encoding is
transparent to the PCRF. When present within a CC-Request Diameter command, subsequent
AVPs within the CC-Request refer to the specific bearer identified by this AVP.
For details, please refer to 3GPP TS 29.212.
9.47 Bearer-Operation
The Bearer-Operation AVP (AVP code 1021) is of type of Enumerated, and it indicates the
bearer event that causes a request for PCC rules. The following values are defined:
34. TERMINATION (0)
This value is used to indicate that a bearer is being terminated.
35. ESTABLISHMENT (1)
9.48 Bearer-Usage
The Bearer-Usage AVP (AVP code 1000) is of type Enumerated, and it shall indicate how the
bearer is being used. If the Bearer-Usage AVP has not been previously provided, its absence
shall indicate that no specific information is available. If the Bearer-Usage AVP has been
provided, its value shall remain valid until it is provided the next time. The following values
are defined:
37. GENERAL (0)
This value shall indicate no specific bearer usage information is available.
38. IMS_SIGNALLING (1)
This value shall indicate that the bearer is used for IMS signaling only.
For details, please refer to 3GPP TS 29.212.
9.49 Charging-Rule-Install
The Charging-Rule-Install AVP (AVP code 1001) is of type Grouped, and it is used to
activate, install or modify PCC rules as instructed from the PCRF to the PCEF. For installing
a new PCC rule or modifying a PCC rule already installed, Charging-Rule-Definition AVP
shall be used. For activating a specific PCC rule predefined at the PCEF, Charging-Rule-
Name AVP shall be used as a reference for that PCC rule. The Charging-Rule-Base-Name
AVP is a reference that may be used for activating a group of PCC rules predefined at the
PCEF.
For GPRS scenarios where the bearer binding is performed by the PCRF, the Bearer Identifier
AVP shall be included as part of Charging-Rule-Install AVP. If present within Charging-Rule-
Install AVP, the Bearer-Identifier AVP indicates that the PCC rules within this Charging-Rule-
Install AVP shall be installed or activated within the IP CAN bearer identified by the Bearer-
Identifier AVP. If no Bearer-Identifier AVP is included within the Charging-Rule-Install AVP,
the PCEF shall select an IP CAN bearer for each of the PCC rules within this Charging-Rule-
Install AVP, were the PCC rule is installed or activated.
If Resource-Allocation-Notification AVP is included then it applies to all the rules within the
Charging-Rule-Install AVP. If a Charging-Rule-Install AVP does not include the Resource-
Allocation-Notification AVP, the resource allocation shall not be notified by the PCEF even if
this AVP was present in previous installations of the same rule.
AVP Format is depicted as follows:
Charging-Rule-Install ::= < AVP Header: 1001 >
*[ Charging-Rule-Definition ]
*[ Charging-Rule-Name ]
*[ Charging-Rule-Base-Name ]
[ Bearer-Identifier ]
[ Rule-Activation-Time ]
[ Rule-Deactivation-Time ]
[ Resource-Allocation-Notification ]
[ Charging-Correlation-Indicator ]
[ SN-Service-Flow-Detection]
*[ AVP ]
For details, please refer to 3GPP TS 29.212.
9.50 Charging-Rule-Remove
The Charging-Rule-Remove AVP (AVP code 1002) is of type Grouped, and it is used to
deactivate or remove PCC rules from an IP CAN session. Charging-Rule-Name AVP is a
reference for a specific PCC rule at the PCEF to be removed or for a specific PCC rule
predefined at the PCEF to be deactivated. The Charging-Rule-Base-Name AVP is a reference
for a group of PCC rules predefined at the PCEF to be deactivated. AVP Format is depicted as
follows:
Charging-Rule-Remove ::= < AVP Header: 1002 >
*[ Charging-Rule-Name ]
*[ Charging-Rule-Base-Name ]
*[ AVP ]
When PCRF indicates to remove a rule not existing on PCEF, the PCEF shall ignore the remove
indication with no error occurs and reply success.
9.51 Charging-Rule-Definition
The Charging-Rule-Definition AVP (AVP code 1003) is of type Grouped, and it defines the
PCC rule for a service flow sent by the PCRF to the PCEF. The Charging-Rule-Name AVP
uniquely identifies the PCC rule and it is used to reference to a PCC rule in communication
between the PCEF and the PCRF within one IP CAN session. The Flow-Description AVP(s)
determines the traffic that belongs to the service flow. If optional AVP(s) within a Charging-
Rule-Definition AVP are omitted, but corresponding information has been provided in
previous Gx messages, the previous information remains valid. If Flow-Description AVP(s)
are supplied, they replace all previous Flow-Description AVP(s). If Flows AVP(s) are
supplied, they replace all previous Flows AVP(s). Flows AVP may appear if and only if AF-
Charging-Identifier AVP is also present.
AVP Format is depicted as follows:
Charging-Rule-Definition ::= < AVP Header: 1003 >
{ Charging-Rule-Name }
[ Service-Identifier ]
[ Rating-Group ]
*[ Flow-Description ]
* [ Flow-Information ]
[ TDF-Application-Identifier ]
[ Flow-Status ]
[ QoS-Information ]
[AF-Signalling-Protocol]
[ Reporting-Level ]
[ Online ]
[ Offline ]
[ Metering-Method ]
[ Precedence ]
[ AF-Charging-Identifier ]
*[ Flows ]
[Redirect-Server]
[Proto-Classifier-Name]
[X-HW-Monitoring-Key]
[Monitoring-Key]
[ Redirect-Information ]
[ Mute-Notification ]
*[X-HW-Subscriber-Service-Name]
*[Gx-TMO-Redirect-Server]
[X-HW-Service-Type]
[X-HW-MS-Group-Name]
[X-HW-ACL-Group-Name]
[X-HW-Interim-Interval]
*[Required-Access-Info]
*[ AVP ]
The X-HW-Monitoring-Key AVP is used for Huawei private usage monitoring and cannot be used
with 3GPP Monitoring-Key simultaneously.
The Proto-Classifier-Name AVP is Huawei private extension used for dynamic layer-7
rules definition.
9.52 Charging-Rule-Base-Name
The Charging-Rule-Base-Name AVP (AVP code 1004) is of type UTF8String, and it indicates
the name of a pre-defined group of PCC rules residing at the PCEF.
For details, please refer to 3GPP TS 29.212.
9.53 Charging-Rule-Name
The Charging-Rule-Name AVP (AVP code 1005) 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 within
one IP-CAN session. For PCC rules pre-defined at the PCEF it uniquely identifies a PCC rule
within the PCEF.
For details, please refer to 3GPP TS 29.212.
9.54 Charging-Rule-Report
The Charging-Rule-Report AVP (AVP code 1018) is of types Grouped, and it is used to report
the status of PCC rules.
Charging-Rule-Name AVP is a reference for a specific PCC rule at the PCEF that has been
successfully installed, modified or removed (for dynamic PCC rules), or activated or
deactivated (for predefined PCC rules) because of trigger from the MS. Charging-Rule-Base-
Name AVP is a reference for a group of PCC rules predefined at the PCEF that has been
successfully activated or deactivated because of trigger from the MS.
The Charging-Rule-Report AVP can also be used to report the status of the PCC rules which
cannot be installed/activated at the PCEF. In this condition, the Charging-Rule-Name AVP is
used to indicate a specific PCC rule which cannot be installed/activated, and the Charging-
Rule-Base-Name AVP is used to indicate a group of PCC rules which cannot be activated.
Multiple instances of Charging-Rule-Report AVPs shall be used in the case it is required to
report different PCC-Rule-Status values for different groups of rules within the same
Diameter command.
AVP Format is depicted as follows:
Charging-Rule-Report ::= < AVP Header: 1018 >
*[Charging-Rule-Name]
*[Charging-Rule-Base-Name]
[PCC-Rule-Status]
[Rule-Failure-Code]
[Final-Unit-Indication]
*[AVP]
For details, please refer to 3GPP TS 29.212.
9.55 Event-Trigger
The Event-Trigger AVP (AVP code 1006) is of type Enumerated. When sent from the PCRF to
the PCEF the Event-Trigger AVP indicates an event that shall cause a re-request of PCC rules.
When sent from the PCEF to the PCRF the Event-Trigger AVP indicates that the
corresponding event has occurred at the gateway. Whenever one of these events occurs, the
PCEF shall send the related AVP that has changed together with the event trigger indication.
The following values are defined:
39. SGSN_CHANGE (0)
This value shall be used in CCA and RAR commands by the PCRF to indicate that upon
the change of the serving SGSN PCC rules shall be requested. When used in a CCR
command, this value indicates that the PCEF generated the request because the serving
SGSN changed. The new value of the serving SGSN shall be indicated in either 3GPP-
SGSN-Address AVP or 3GPP-SGSN-IPv6-Address AVP.
40. QOS_CHANGE (1)
This value shall be used in CCA and RAR commands by the PCRF to indicate that upon
any QoS change (even within the limits of the current authorization) at bearer level PCC
rules shall be requested. When used in a CCR command, this value indicates that the
PCEF generated the request because there has been a change in the requested QoS for a
specific bearer . The Bearer-Identifier AVP shall be provided to indicate the affected
bearer. QoS-Information AVP is required to be provided in the same request with the new
value.
41. RAT_CHANGE (2)
This value shall be used in CCA and RAR commands by the PCRF to indicate that upon
a RAT change PCC rules shall be requested. When used in a CCR command, this value
indicates that the PCEF generated the request because of a RAT change. The new RAT
type shall be provided in the 3GPP-RAT-Type AVP.
42. TFT_CHANGE (3)
This value shall be used in CCA and RAR commands by the PCRF to indicate that upon
a TFT change at bearer level PCC rules shall be requested. When used in a CCR
command, this value indicates that the PCEF generated the request because of a change
in the TFT. The Bearer-Identifier AVP shall be provided to indicate the affected bearer.
The new TFT values shall be provided in TFT-Packet-Filter-Information AVP.
43. PLMN_CHANGE (4)
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 PCEF generated the request because there was a change of
PLMN. 3GPP-SGSN-MCC-MNC AVP shall be provided in the same request with the
new value.
44. LOSS_OF_BEARER (5)
This value shall be used in CCA and RAR commands by the PCRF to indicate that upon
loss of bearer, GW should inform PCRF. When used in a CCR command, this value
indicates that the PCEF generated the request because the bearer associated with the
PCC rules indicated by the corresponding Charging Rule Report AVP was lost. The
PCC-Rule-Status AVP within the Charging Rule Report AVP shall indicate that these
PCC rules are temporary inactive. The mechanism of indicating loss of bearer to the GW
is IP-CAN access type specific. For GPRS, this is indicated by a PDP context
modification request with Maximum Bit Rate (MBR) in QoS profile changed to 0 kbps.
When the PCRF performs the bearer binding, the PCEF shall provide the Bearer-
Identifier AVP to indicate the bearer that has been lost.
45. RECOVERY_OF_BEARER (6)
This value shall be in CCA and RAR commands by the PCRF used to indicate that upon
recovery of bearer, GW should inform PCRF. When used in a CCR command, this value
indicates that the PCEF generated the request because the bearer associated with the
PCC rules indicated by the corresponding Charging Rule Report AVP was recovered.
The PCC-Rule-Status AVP within the Charging Rule Report AVP shall indicate that these
rules are active again. The mechanism for indicating recovery of bearer to the GW is IP-
CAN access type specific. For GPRS, this is indicated by a PDP context modification
request with Maximum Bit Rate (MBR) in QoS profile changed from 0 kbps to a valid
value. When the PCRF performs the bearer binding, the PCEF shall provide the Bearer-
Identifier AVP to indicate the bearer that has been recovered.
46. IP-CAN_CHANGE (7)
This value shall be used in CCA and RAR commands by the PCRF to indicate that upon
a change in the IP-CAN type PCC rules shall be requested. When used in a CCR
command, this value indicates that the PCEF generated the request because there was a
change of IP-CAN type. IP-CAN-Type AVP shall be provided in the same request with
the new value. For 3GPP IP-CAN type value, 3GPP-RAT-Type AVP shall also be
provided.
47. GW/PCEF_MALFUNCTION (8)
This value shall be used in CCA and RAR commands by the PCRF to indicate that upon
a failure in the enforcement of PCC rules due to GW/PCEF malfunction, the PCEF shall
inform the PCRF. When used in a CCR or RAA command, this value indicates that the
PCEF generated the request or answer due to a malfunction in the PCEF the PCC rules
cannot be enforced. The affected PCC rules will be provided in the Charging-Rule-
Report AVP. When PCRF performs the bearer binding, the PCEF must provide the
Bearer-Identifier AVP for the affected bearer and should provide the Charging-Rule-
Report AVP to indicate what PCC rules are affected within that bearer. In this case,
absence of the Charging-Rule-Report AVP means that all provided PCC rules for that
specific bearer are affected. When the PCEF performs the bearer binding, the PCEF
should provide the Charging-Rule-Report AVP to indicate the PCC rules that are
affected. In this case, absence of Charging-Rule-Report AVP means that all the PCC
rules for the corresponding IP-CAN session are affected.
48. RESOURCES_LIMITATION (9)
This value shall be used in CCA and RAR commands by the PCRF to indicate that upon
a failure to provide the required resource for the service flows described by the PCC
rules, the PCEF shall inform the PCRF. When used in a CCR or RAA command, this
value indicates that the PCEF generated the request or answer because of resource
limitation. The affected PCC rules will be provided in the Charging-Rule-Report AVP.
When the PCRF performs the bearer binding, the PCEF shall provide the Bearer-
Identifier for the affected bearer. In this case, absence of the Charging-Rule-Report AVP
means that all provided PCC rules for that specific bearer are affected. Otherwise, only
the PCC rules included in Charging-Rule-Report AVP are affected.
49. MAX_NR_BEARERS_REACHED (10)
This value shall be used in CCA and RAR commands by the PCRF to subscribe to this
event. If the PCRF subscribes to this event, the PCEF shall inform the PCRF whenever a
failure in the enforcement of PCC rules occurs due to the maximum number of bearer
have been reached for the IP-CAN session, PCEF shall inform PCRF. When used in a
CCR or RAA command, this value indicates that the PCEF generated the request or
answer because the PCC rules cannot be enforced since the IP-CAN session already
contains the maximum number of bearers allowed. The affected PCC rules will be
provided in the Charging-Rule-Report AVP.
50. QOS_CHANGE_EXCEEDING_AUTHORIZATION (11)
This value shall be used in CCA and RAR commands by the PCRF to indicate that only
upon a requested QoS change beyond the current authorized value(s) at bearer level PCC
rules shall be requested. When used in a CCR or RAA command, this value indicates
that the PCEF generated the request or answer because there has been a change in the
requested QoS beyond the authorized value(s) for a specific bearer. The Bearer-Identifier
AVP shall be provided to indicate the affected bearer. QoS-Information AVP is required
to be provided in the same request with the new value.
51. RAI_CHANGE (12)
This value shall be used in CCA and RAR commands by the PCRF to indicate that upon
a change in the RAI, PCEF shall inform the PCRF. When used in a CCR command, this
value indicates that the PCEF generated the request because there has been a change in
the RAI. The new RAI value shall be provided in the RAI AVP. If the user location has
been changed but the PCEF cannot get the detail location information for some reasons
(eg. handover from 3G to 2G network), the PCEF shall send the RAI AVP to the PCRF
by setting the LAC of the RAI to value 0x0000. Applicable only for GPRS.
52. USER_LOCATION_CHANGE (13)
This value shall be used in CCA and RAR commands by the PCRF to indicate that upon
a change in the user location, PCEF shall inform the PCRF. When used in a CCR
command, this value indicates that the PCEF generated the request because there has
been a change in the user location. The new location value shall be provided in the
3GPP-User-Location-Info AVP. If the user location has been changed but the PCEF
cannot get the detail location information for some reasons (e.g. handover from 3G to 2G
network), the PCEF shall send the 3GPP-User-Location-Info AVP to the PCRF by setting
the LAC of the CGI/SAI to value 0x0000. Applicable only for GPRS.
53. NO_EVENT_TRIGGER (14)
This value shall be used in CCA and RAR commands by the PCRF to indicate that PCRF
does not require any Event Trigger notification.
54. REVALIDATION_TIMEOUT (17)
This value shall be used in CCA and RAR commands by the PCRF to indicate that upon
revalidation timeout, PCEF shall inform the PCRF. When used in a CCR command, this
value indicates that the PCEF generated the request because there has been a PCC
revalidation timeout.
If usage monitoring and reporting is enabled and a revalidation timeout occurs, the PCEF
shall send a CCR to request PCC rules and shall report all accumulated usage for all
enabled monitoring since the last report (or since usage reporting was enabled if the
usage was not yet reported)
55. USAGE_REPORT (26)
This value shall be used in a CCA and RAR commands by the PCRF when requesting
usage monitoring at the PCEF. The PCRF shall also provide in the CCA or RAR
command the Usage-Monitoring-Information AVP(s) including the Monitoring-Key AVP
and the Granted-Service-Unit AVP.
When used in a CCR command, this value indicates that the PCEF generated the request
to report the accumulated usage for one or more monitoring keys. The PCEF shall also
provide the accumulated usage volume using the Usage-Monitoring-Information AVP(s)
including the Monitoring-Key AVP and the Used-Service-Unit AVP. Applicable to
functionality introduced with the Rel9 feature as described in TS 29.212.
56. SUCCESSFUL_RESOURCE_ALLOCATION (22)
This value shall be used in CCA and RAR commands by the PCRF to indicate that the
PCEF can inform the PCRF of successful resource allocation for those rules that requires
so.
When used in a CCR or RAA command, this value indicates that the PCEF informs the
PCRF that the resources for a rule have been successfully allocated. The affected rules
are indicated within the Charging-Rule-Report AVP with the PCC-Rule-Status AVP set to
the value ACTIVE (0).
57. RESOURCE_MODIFICATION_REQUEST (23)
This value shall be used in a CCR command to indicate that PCC rules are requested for
a resource modification request initiated by the UE. The Packet-Filter-Operation and
Packet-Filter-Information AVPs shall be provided in the same request. This event trigger
does not require to be provisioned by the PCRF. It shall be reported by the PCEF when
the corresponding event occurs even if the event trigger is not provisioned by the PCRF.
Applicable to functionality introduced with the Rel8 feature as described in clause
58. UE_TIME_ZONE_CHANGE (25)
This value shall be used in CCA and RAR commands by the PCRF to indicate that upon
a change to the time zone the UE is currently located in, PCC rules shall be requested.
When used in a CCR command, this value indicates that the PCEF generated the request
because the time zone the UE is currently located in has changed. The new value of the
UEs time zone shall be indicated in the 3GPP-MS-TimeZone AVP.
59. TAI_CHANGE (27)
This value shall be used in CCA and RAR commands by the PCRF to indicate that upon
a change in the TAI, PCEF shall inform the PCRF. When used in a CCR command, this
value indicates that the PCEF generated the request because there has been a change in
the TAI. The new TAI value shall be provided in the 3GPP-User-Location-Info AVP. If
the user tracking area location has been changed but the PCEF cannot get the detail
location information, the PCEF shall send the 3GPP-User-Location-Info AVP to the
PCRF by setting the TAC of the TAI to value 0x0000. Applicable only to 3GPP-EPS
access type and to functionality introduced with the Rel8 feature as described in clause
5.4.1.
60. ECGI_CHANGE (28)
This value shall be used in CCA and RAR commands by the PCRF to indicate that upon
a change in the ECGI, PCEF shall inform the PCRF. When used in a CCR command, this
value indicates that the PCEF generated the request because there has been a change in
the ECGI. The new ECGI value shall be provided in the 3GPP-User-Location-Info AVP.
If the ECGI has been changed but the PCEF cannot get the detail location information,
the PCEF shall send the 3GPP-User-Location-Info AVP to the PCRF by setting the ECI
of the ECGI to value 0x0000. Applicable only to 3GPP-EPS access type and to
functionality introduced with the Rel8 feature as described in clause 5.4.1.
61. CHARGING_CORRELATION_EXCHANGE (29)
The PCRF shall use this value in CCA and RAR commands to indicate that the PCEF
shall report the access network charging identifier associated to one or more dynamic
PCC Rules within the Access-Network-Charging-Identifier-Gx AVP. The Charging-
Correlation-Indicator AVP with value CHARGING_IDENTIFIER_REQUIRED shall be
provided.
When used in a CCR command, this value indicates that an access network charging
identifier has been assigned. The actual value shall be reported with the Access-Network-
Charging-Identifier-Gx AVP. Applicable to functionality introduced with the Rel8 feature
as described in clause 5.4.1.
62. REDIRECTION(100)
This value shall be used in a CCA and RAR commands by the PCRF when requesting
redirection monitoring at the PCEF. When used in a CCR command, this value indicates
that the PCEF generated the request to report the redirection behavior of current user.
63. TETHERING_REPORT (101)
This value shall be used in CCA and RAR commands by the PCRF to indicate that the
enforcement of tethering detection function in PCEF. When used in a CCR command by
the PCEF, this value indicates that the PCEF generated the request because the starting
or ending of tethering behavior of current user.
64. CELL_CONGESTED (1003)
This value shall be used in a CCA and RAR commands by the PCRF to indicate that the
PCEF shall inform the PCRF when the cell where the subscriber resides is congested.
65. CELL_CLEAR (1004)
This value shall be used in a CCA and RAR commands by the PCRF to indicate that the
PCEF shall inform the PCRF when the cell where the subscriber resides is cleared. For
details, please refer to 3GPP TS 29.212.
66. UE_IP_ADDRESS_ALLOCATE (18)
This value indicates that the PCRF allows the PCEF to report the event, but the PCRF
does not process it.
67. UE_IP_ADDRESS_RELEASE (19)
This value indicates that the PCRF allows the PCEF to report the event, but the PCRF
does not process it.
68. DEFAULT_EPS_BEARER_QOS_CHANGE (20)
This value indicates that the PCRF allows the PCEF to report the event, but the PCRF
does not process it.
69. AN_GW_CHANGE (21)
This value is used by the PCRF to indicate that upon the change in the IP address of the
serving Access Node Gateway (including the 3GPP SGW and non-3GPP AGW), PCC
rules are requested. The new value of the serving Access Node gateway must be
indicated in the AN-GW-Address AVP to request the PCRF to deliver the corresponding
policy to perform the ANGW-based policy control.
70. TFT_DELETED (1000)
This value is used by the PCEF to report the TFT flow filter that is deleted by the PCRF.
71. USAGE_THRESHOLD_REACHED (1001)
This value is used to report that the volume usage reaches the threshold when the PCRF
interworks with the Allot DPI.
72. SERVICE_FLOW_DETECTION (1002)
This value is used to report that the service flow detection at the PCEF.
9.56 IP-CAN-Type
The IP-CAN-Type AVP (AVP code 1027) is of type Enumerated, and it shall indicate the type
of Connectivity Access Network in which the user is connected. The IP-CAN-Type AVP shall
always be present during the IP-CAN session establishment. During an IP-CAN session
modification, this AVP shall be present when there has been a change in the IP-CAN type and
the PCRF requested to be informed of this event. The Event-Trigger AVP with value IP-CAN
CHANGE shall be provided together with the IP-CAN-Type AVP.
The following values are defined:
81. 3GPP (0)
This value shall be used to indicate that the IP-CAN is associated with a 3GPP access
and is further detailed by the 3GPP-RAT-Type AVP.
82. DOCSIS (1)
This value shall be used to indicate that the IP-CAN is associated with a DOCSIS access.
83. xDSL (2)
This value shall be used to indicate that the IP-CAN is associated with an xDSL access.
84. WiMAX (3)
This value shall be used to indicate that the IP-CAN is associated with a WiMAX access
(IEEE 802.16).
85. 3GPP2 (4)
This value shall be used to indicate that the IP-CAN is associated with a 3GPP2 access.
86. 3GPP-EPS (5)
This value shall be used to indicate that the IP-CAN associated with a 3GPP EPS access
and is further detailed by the RAT-Type AVP.
87. Non-3GPP-EPS (6)
This value shall be used to indicate that the IP-CAN associated with an EPC based non-
3GPP access and is further detailed by the RAT-Type AVP.
88. FBB-WLAN(1050)
This value shall be used to indicate that the IP-CAN is associated with a WLAN access.
This value is used by ME60.
9.56.1 Guaranteed-Bitrate-DL
The Guaranteed-Bitrate-DL AVP (AVP code 1025) is of type Unsigned32, and it indicates the
guaranteed bitrate in bits per second for a downlink service data flow. The bandwidth contains
all the overhead coming from the IP-layer and the layers above, e.g. IP, UDP, RTP and RTP
payload.
For details, please refer to 3GPP TS 29.212.
9.56.2 Guaranteed-Bitrate-UL
The Guaranteed Bitrate-UL AVP (AVP code 1026) is of type Unsigned32, and it indicates the
guaranteed bitrate in bits per second for an uplink service data flow. The bandwidth contains
all the overhead coming from the IP-layer and the layers above, e.g. IP, UDP, RTP and RTP
payload.
For details, please refer to 3GPP TS 29.212.
9.56.3 Metering-Method
The Metering-Method AVP (AVP code 1007) is of type Enumerated, and it defines what
parameters shall be metered for offline charging. If the Metering-Method AVP is omitted but
has been supplied previously, the previous information remains valid. If the Metering-Method
AVP is omitted and has not been supplied previously, the metering method pre-configured at
the PCEF is applicable as default metering method.
The following values are defined:
89. DURATION (0)
This value shall be used to indicate that the duration of the service flow shall be metered.
90. VOLUME (1)
This value shall be used to indicate that volume of the service flow traffic shall be
metered.
91. DURATION_VOLUME (2)
This value shall be used to indicate that the duration and the volume of the service flow
traffic shall be metered.
92. NO_CHARGING (128)
This value shall use to indicate that the service flow identified by this rule will not be
charged.
For details, please refer to 3GPP TS 29.212.
9.57 Network-Request-Support
The Network-Request-Support AVP (AVP code 1024) is of type of Enumerated and indicates
the UE and network support of the network requested bearer control mode. If the Network
Request Support AVP has not been previously provided, its absence shall indicate the value
NETWORK_REQUEST NOT SUPPORTED. If the Network Request Support AVP has been
provided, its value shall remain valid until it is provided the next time.
The following values are defined:
93. NETWORK_REQUEST NOT SUPPORTED (0)
This value is used to indicate that the UE and the access network do not support the
bearer establishment request procedure.
94. NETWORK_REQUEST SUPPORTED (1)
This value is used to indicate that the UE and the access network support the bearer
establishment request procedure.
For details, please refer to 3GPP TS 29.212.
In this version, only UE Only bearer control mode is supported, and so QoS per QCI is not
supported.
UE initialed secondary PDP is not supported.
9.58 Offline
The Offline AVP (AVP code 1008) is of type Enumerated.
If the Offline AVP is embedded within a Charging-Rule-Definition AVP it defines whether the
offline charging interface from the PCEF for the associated PCC rule shall be enabled. The
absence of this AVP within the first provisioning of the Charging-Rule-definition AVP of a
new PCC rule indicates that the default charging method for offline shall be used.
If the Offline AVP is embedded within the initial CCR on command level, it indicates the
default charging method for offline pre-configured at the PCEF is applicable as default
charging method for offline. The absence of this AVP within the initial CCR indicates that the
charging method for offline pre-configured at the PCEF is not available.
If the Offline AVP is embedded within the initial CCA on command level, it indicates the
default charging method for offline. The absence of this AVP within the initial CCA indicates
that the charging method for offline pre-configured at the PCEF is applicable as default
charging method for offline.
The default charging method provided by the PCRF shall take precedence over any pre-
configured default charging method at the PCEF.
The following values are defined:
95. DISABLE_OFFLINE (0)
This value shall be used to indicate that the offline charging interface for the associated
PCC rule shall be disabled.
96. ENABLE_OFFLINE (1)
This value shall be used to indicate that the offline charging interface for the associated
PCC rule shall be enabled.
For details, please refer to 3GPP TS 29.212.
9.59 Online
The Online AVP (AVP code 1009) is of type Enumerated.
If the Online AVP is embedded within a Charging-Rule-Definition AVP, it defines whether the
online charging interface from the PCEF for the associated PCC rule shall be enabled. The
absence of this AVP within the first provisioning of the Charging-Rule-Definition AVP of a
new PCC rule indicates that the default charging method for online shall be used.
If the Online AVP is embedded within the initial CCR on command level, it indicates the
default charging method for online pre-configured at the PCEF is applicable as default
charging method for online. The absence of this AVP within the initial CCR indicates that the
charging method for online pre-configured at the PCEF is not available.
If the Online AVP is embedded within the initial CCA on command level, it indicates the
default charging method for online. The absence of this AVP within the initial CCA indicates
that the charging method for online pre-configured at the PCEF is applicable as default
charging method for online.
The default charging method provided by the PCRF shall take precedence over any pre-
configured default charging method at the PCEF.
The following values are defined:
97. DISABLE_ONLINE (0)
This value shall be used to indicate that the online charging interface for the associated
PCC rule shall be disabled.
98. ENABLE_ONLINE (1)
This value shall be used to indicate that the online charging interface for the associated
PCC rule shall be enabled.
For details, please refer to 3GPP TS 29.212.
9.59.1 Precedence
The Precedence AVP (AVP code 1010) is of type Unsigned32. Within the Charging Rule
Definition AVP, the Precedence AVP determines the order, in which the service data flow
templates are applied at service data flow detection at the PCEF. A PCC rule with the
Precedence AVP with lower value shall be applied before a PCC rule with the Precedence
AVP with higher value.
The Precedence AVP is also used within the TFT-Packet-Filter-Information AVP to indicate
the evaluation precedence of the Traffic Mapping Information filters (for GPRS the TFT
packet filters) as received from the UE.
For details, please refer to 3GPP TS 29.212.
9.59.2 Reporting-Level
The Reporting-Level AVP (AVP code 1011) is of type Enumerated, and it defines on what
level the PCEF reports the usage for the related PCC rule. If the Reporting-Level AVP is
omitted but has been supplied previously, the previous information remains valid. If the
Reporting-Level AVP is omitted and has not been supplied previously, the reporting level pre-
configured at the PCEF is applicable as default reporting level.
The following values are defined:
99. SERVICE_IDENTIFIER_LEVEL (0)
This value shall be used to indicate that the usage shall be reported on service id and
rating group combination level.
100. RATING_GROUP_LEVEL (1)
This value shall be used to indicate that the usage shall be reported on rating group level.
For details, please refer to 3GPP TS 29.212.
9.60 PCC-Rule-Status
The PCC-Rule-Status AVP (AVP code 1019) is of type Enumerated, and describes the status
of one or a group of PCC Rules.
The following values are defined:
101. ACTIVE (0)
This value is used to indicate that the PCC rule(s) are installed successfully (for those
provisioned from PCRF) or activated (for those pre-provisioned in PCEF)
102. INACTIVE (1)
This value is used to indicate that the PCC rule(s) are removed (for those provisioned
from PCRF) or inactive (for those pre-provisioned in PCEF)
103. TEMPORARY INACTIVE (2)
This value is used to indicate that, for some reason (e.g. loss of bearer), already installed
or activated PCC rules are temporary disabled.
For details, please refer to 3GPP TS 29.212.
9.61 QoS-Class-Identifier
QoS-Class-Identifier AVP (AVP code 1028) is of type Enumerated, and it identifies a set of
IP-CAN specific QoS parameters that define the authorized QoS, excluding the applicable
bitrates for the IP-CAN bearer or service flow. It is only applicable to network initiated QoS
control procedures.
For details, please refer to 3GPP TS 29.212.
In this version, only UE Only bearer control mode is supported, and so QoS per QCI is not
supported.
UE initialed secondary PDP is not supported.
9.62 QoS-Information
The QoS-Information AVP (AVP code 1016) is of type Grouped, and it defines the QoS
information for an IP-CAN bearer, PCC rule or QCI. When this AVP is sent from the PCEF to
the PCRF, it indicates the requested QoS information for an IP CAN bearer. When this AVP is
sent from the PCRF to the PCEF, it indicates the authorized QoS for an IP CAN bearer (when
appearing at CCA or RAR command level or a service flow (when included within the PCC
rule) or a QCI (when appearing at CCA or RAR command level with the QoS-Class-Identifier
AVP and the Maximum-Requested-Bandwidth-UL AVP and/or the Maximum-Requested-
Bandwidth-DL AVP).
The Bearer Identifier AVP shall be included as part of the QoS-Information AVP if the QoS
information refers to an IP CAN bearer initiated by the UE and the PCRF performs the bearer
binding. The Bearer Identifier AVP identifies this bearer. Several QoS-Information AVPs for
different Bearer Identifiers may be provided per command.
The Allocation-Retention-Priority AVP is an indicator of the priority of allocation and
retention for the Service Data Flow.
If the QoS-Information AVP has been supplied previously but is omitted in a Diameter
message or AVP, the previous information remains valid. If the QoS-Information AVP has not
been supplied from the PCRF to the PCEF previously and is omitted in a Diameter message
or AVP, no enforcement of the authorized QoS shall be performed.
AVP Format is depicted as follows:
QoS-Information ::= < AVP Header: 1016 >
[ QoS-Class-Identifier ]
[ Max-Requested-Bandwidth-UL ]
[ Max-Requested-Bandwidth-DL ]
[ Guaranteed-Bitrate-UL ]
[ Guaranteed-Bitrate-DL ]
[ APN-Aggregate-Max-Bitrate-UL]
[ APN-Aggregate-Max-Bitrate-DL]
[ Bearer-Identifier ]
[ Allocation-Retention-Priority]
In this version, only UE Only bearer control mode is supported, and so QoS per QCI is not
supported.
UE initialed secondary PDP is not supported.
APN-Aggregate-Max-Bitrate-UL and APN-Aggregate-Max-Bitrate-DL may exist only when the
QoS-Information is included within the CCA/RAR.
9.63 QoS-Negotiation
The QoS-Negotiation AVP (AVP code 1029) is of type Enumerated. The value of the AVP
indicates for a single PCC rule request if the PCRF is allowed to negotiate the QoS by
supplying in the answer to this request an authorized QoS different from the requested QoS.
The following values are defined:
NO_QoS_NEGOTIATION (0)
This value indicates that a QoS negotiation is not allowed for the corresponding PCC
rule request.
QoS_NEGOTIATION_SUPPORTED (1)
This value indicates that a QoS negotiation is allowed for the corresponding PCC rule
request. This is the default value applicable if this AVP is not supplied
For details, please refer to 3GPP TS 29.212.
9.64 QoS-Upgrade
The QoS-Upgrade AVP (AVP code 1030) is of type Enumerated. The value of the AVP
indicates whether the SGSN supports that the GGSN upgrades the QoS in a Create PDP
context response or Update PDP context response. If the SGSN does not support a QoS
upgrade, the PCRF shall not provision an authorized QoS which is higher than the requested
QoS for this IP CAN bearer. The setting is applicable to the bearer indicated in the request
within the Bearer-Identifier AVP.
If no QoS-Upgrade AVP has been supplied for an IP CAN bearer, the default value
QoS_UPGRADE_NOT_SUPPORTED is applicable. If the QoS-Upgrade AVP has previously
been supplied for an IP CAN bearer but is not supplied in a new PCC rule request, the
previously supplied value remains applicable.
The following values are defined:
QoS_UPGRADE_NOT_SUPPORTED (0)
This value indicates that the IP-CAN bearer does not support the upgrading of the
requested QoS. This is the default value applicable if no QoS-Upgrade AVP has been
supplied for an IP CAN bearer.
QoS_UPGRADE_SUPPORTED (1)
This value indicates that the IP-CAN bearer supports the upgrading of the requested
QoS.
For details, please refer to 3GPP TS 29.212.
9.65 TFT-Filter
The TFT-Filter AVP (AVP code 1012) is of type IPFilterRule, and it contains the flow filter
for one TFT packet filter. The TFT-Filter AVP is derived from the Traffic Flow Template
(TFT) defined in 3GPP TS 24.008 [13]. The following information shall be sent:
- Action shall be set to "permit".
- Direction shall be set to "out" or "in".
- Protocol shall be set to the value provided within the TFT packet filter parameter
"Protocol Identifier/Next Header Type". If the TFT packet filter parameter "Protocol
Identifier/Next Header Type" is not provided within the TFT packet filter, Protocol shall
be set to "ip".
- Source IP address (possibly masked). The source IP address shall be derived from TFT
packet filter parameters "Source address" and "Subnet Mask". The source IP address
shall be set to "any", if no such information is provided in the TFT packet filter.
- Source and destination port (single value, list or ranges). The information shall be
derived from the corresponding TFT packet filter parameters. Source and/or destination
port(s) shall be omitted if such information is not provided in the TFT packet filter.
- The Destination IP address shall be set to "assigned".
The IPFilterRule type shall be used with the following restrictions:
- No options shall be used.
- The invert modifier "!" for addresses shall not be used.
The direction "out" refers to downlink direction.
For details, please refer to 3GPP TS 29.212.
9.66 TFT-Packet-Filter-Information
The TFT-Packet-Filter-Information AVP (AVP code 1013) is of type Grouped, and it contains
the information from a single TFT packet filter including the evaluation precedence, the filter
and the Type-of-Service/Traffic Class sent from the PCEF to the PCRF. The PCEF shall
include one TFT-Packet-Filter-Information AVP for each TFT packet filters applicable at a
PDP context in separate TFT-Packet-Filter-Information AVPs within each PCC rule request
corresponding to that PDP context. TFT-Packet-Filter-Information AVPs are derived from the
Traffic Flow Template (TFT) defined in 3GPP TS 24.008 [13].
AVP Format is depicted as follows:
TFT-Packet-Filter-Information ::= < AVP Header: 1013 >
[ Precedence ]
[ TFT-Filter ]
[ ToS-Traffic-Class ]
For details, please refer to 3GPP TS 29.212.
9.67 ToS-Traffic-Class
The ToS-Traffic-Class AVP (AVP code 1014) is of type OctetString, and it contains the Type-
of-Service/Traffic-Class of a TFT packet filter as defined in 3GPP TS 24.008 [13].
For details, please refer to 3GPP TS 29.212.
9.68 X-HW-Usage-Report
The X-HW-Usage-Report AVP (AVP code 2005) is of type Grouped. When sent from PCRF
to GGSN, it indicates that usage information for specified services and/or the whole IP-CAN
session should be reported, and contains corresponding thresholds for reporting. When sent
from GGSN to PCRF, it contains the detailed usage information accumulated from the time
point of last report to the time point of current report. Please be noted that usage report for
each services and/or IP-CAN session is independent of each other, and local counters for
usage accumulating are cleared immediately once reporting message is sent out.
AVP Format is depicted as follows:
X-HW-Usage-Report ::= < AVPCode::= 2005, Vendor-Id::=2011>
[X-HW-Session-Usage]
*[ X-HW-Service-Usage]
9.69 X-HW-Session-Usage
The X-HW-Session-Usage AVP (AVP code 2006) is of type Grouped. When sent from PCRF
to GGSN, it indicates that usage information for the whole IP-CAN session should be
reported, and contains corresponding threshold for reporting. When sent from GGSN to
PCRF, it contains the detailed usage information of the whole IP-CAN session accumulated
from the time point of last report to the time point of current report.
AVP Format is depicted as follows:
X-HW-Session-Usage :=< AVPCode::= 2006, Vendor-Id::=2011>
[CC-Input-Octets]
[CC-Output-Octets]
9.70 X-HW-Service-Usage
The X-HW-Service-Usage AVP (AVP code 2007) is of type Grouped. When sent from PCRF
to GGSN, it indicates that usage information for specified service should be reported, and
contains corresponding threshold for reporting. When sent from GGSN to PCRF, it contains
the detailed usage information of specified service accumulated from the time point of last
report to the time point of current report. For which service to report, it is specified by the
In release V300R002C02/C03, the Rating-Group and Service-Identifier are correlated to these in the
Charging-Rule-Definition to combine the usage and service flows. But from release V300R002C05, the
Rating-Group AVP here is mapped into the monitoring key defined in PCC rule, and the Service-
Identifier AVP here is abolished, and so from now on it can work independently with the charging
interfaces.
9.71 CC-Input-Octets
The CC-Input-Octets AVP (AVP Code 412) is of type Unsigned64 and contains the number
of requested, granted, or used octets that can be/have been received from the end user.
9.72 CC-Output-Octets
The CC-Output-Octets AVP (AVP Code 414) is of type Unsigned64 and contains the number
of requested, granted, or used octets that can be/have been sent to the end user.
9.73 Redirect-Server
The Redirect-Server AVP (AVP Code 434) is of type Grouped and contains the address
information of the redirect server (e.g., HTTP redirect server, SIP Server) with which the end
user is to be connected when the account cannot cover the service cost.
It is defined as follows (per the grouped-avp-def of RFC 3588 [DIAMBASE]):
Redirect-Server ::= < AVP Header: 434 >
{ Redirect-Address-Type }
{ Redirect-Server-Address }
[Append-Original-URL]
[Deactivate-By-Redirect] // one-shot redirection
[X-HW-Redirect-Times]
[X-HW-Redirect-Report]
Vendor-Id is 3GPP.
9.74 Redirect-Address-Type
The Redirect-Address-Type AVP (AVP Code 433) is of type Enumerated and defines the
address type of the address given in the Redirect-Server-Address AVP.
The address type can be one of the following:
IPv4 Address 0
The address type is in the form of "dotted-decimal" IPv4 address, as defined in [IPv4].
IPv6 Address 1
The address type is in the form of IPv6 address, as defined in [IPv6Addr]. The address is a
text representation of the address in either the preferred or alternate text form [IPv6Addr].
Conformant implementations MUST support the preferred form and SHOULD support the
alternate text form for IPv6 addresses.
URL 2
The address type is in the form of Uniform Resource Locator, as defined in [URL].
SIP-URI 3
The address type is in the form of SIP Uniform Resource Identifier, as defined in [SIP].
Vendor-Id is 3GPP.
9.75 Redirect-Server-Address
The Redirect-Server-Address AVP (AVP Code 435) is of type UTF8String and defines the
address of the redirect server (e.g., HTTP redirect server, SIP Server) with which the end user
is to be connected when the account cannot cover the service cost.
Vendor-Id is 3GPP.
9.76 Append-Original-URL
The Append-Original-URL AVP (AVP Code::=114 Vendor-Id::=2011) is of type Enumerated
and defines that the original URL of the HTTP get shall be included as a CGI parameter to the
redirection URL.
The original URL in the redirection URL should be sent via a CGI parameter separated with
question marks. E.g. Redirection URL=www.google.com/passes?
originalurl=www.yahoo.com.
The AVP can be set to one of the following values:
disable 0 (default) // do not append the original URL
9.77 Deactivate-By-Redirect
The Deactivate-By-Redirect AVP (AVP Code::=115 Vendor-Id::=2011) is of type Enumerated
and defines that the redirection rule shall be disabled immediately when the PCEF detects a
HTTP Get with the redirection URL in the redirection flow. (One-Shot-Redirection)
The AVP can be set to one of the following values:
disable 0 (default) // the rule is not deactivated once enforced
enable 1 // the rule is deactivated once enforced
9.78 X-HW-Monitoring-Key
The X-HW-Monitoring-Key AVP is of type Unsigned32 (AVP Code::=2008, Vendor-
Id::=2011) and contains the monitoring key for usage reporting. The value range is from
0x00000000 to 0xFFFFFFFF. If it has not been previously provided in PCC rules, its absence
shall indicate that the corresponding service is not subject to usage reporting. If it has been
provided, its value shall remain valid until it is provided the next time.
For these Monitoring-Key predefined on PCEF (e.g. contains within pre-defined rule or pre-defined rule
group) shall be within range of [0x0, 0x7FFFFFFD], i.e. [0, 2147483645].
9.79 Proto-Classifier-Name
The Proto-Classifier-Name (AVP-Code::= 2051, Vendor-Id::=2011) is type of UTF-8 string,
define the name of a protocol classifier or name of group of protocol classifiers predefined on
the PCEFs. For example, it could be p2p to indicate all P2P stream or Skype for special
application.
This AVP has mutually exclusive relation with the Flow-Description, i.e. they cannot be occurring in one
Charging-Rule-Definition.
9.80 Usage-Monitoring-Information
The Usage-Monitoring-Information AVP (AVP code 1067) is of type Grouped, and it contains
the usage monitoring control information.
The Monitoring-Key AVP identifies the usage monitoring control instance.
The Granted-Service-Unit AVP shall be used by the PCRF to provide the threshold level to
the PCEF. The CC-Total-Octets AVP shall be used for providing threshold level for the total
volume, or the CC-Input-Octets and/or CC-Output-Octets AVPs shall be used for providing
threshold level for the uplink volume and/or the downlink volume.
The Used-Service-Unit AVP shall be used by the PCEF to provide the measured usage to the
PCRF. Reporting shall be done, as requested by the PCRF, in CC-Total-Octets, CC-Input-
Octets or CC-Output-Octets AVPs of Used-Service-Unit AVP.
The Usage-Monitoring-Level AVP determines the scope of the usage monitoring instance.
The Usage-Monitoring-Report AVP determines if accumulated usage shall be reported for the
usage monitoring key included in Monitoring-Key AVP.
The Usage-Monitoring-Support AVP determines if a usage monitoring instance is disabled.
AVP Format:
Usage-Monitoring-Information::= < AVP Header: 1067 >
[ Monitoring-Key ]
[ Granted-Service-Unit ]
[ Used-Service-Unit ]
[ Usage-Monitoring-Level ]
[ Usage-Monitoring-Report ]
[ Usage-Monitoring-Support ]
*[ AVP ]
9.81 Usage-Monitoring-Level
The Usage-Monitoring-Level AVP (AVP code 1068) is of type Enumerated and is used by the
PCRF to indicate whether the usage monitoring instance applies to the IP-CAN session or to
one or more PCC rules.
If Usage-Monitoring-Level AVP is not provided, its absence shall indicate the value
PCC_RULE_LEVEL (1).
The following values are defined:
SESSION_LEVEL (0)
This value, if provided within an RAR or CCA command by the PCRF indicates that the
usage monitoring instance applies to the entire IP-CAN session.
PCC_RULE_LEVEL (1)
This value, if provided within an RAR or CCA command by the PCRF indicates that the
usage monitoring instance applies to one or more PCC rules.
9.82 Usage-Monitoring-Report
The Usage-Monitoring-Report AVP (AVP code 1069) is of type Enumerated and is used by
the PCRF to indicate that accumulated usage is to be reported by the PCEF regardless of
whether a usage threshold is reached for certain usage monitoring key (within a Usage-
Monitoring-Information AVP) .
The following values are defined:
USAGE_MONITORING_REPORT_REQUIRED (0)
This value, if provided within an RAR or CCA command by the PCRF indicates that
accumulated usage shall be reported by the PCEF.
9.83 Usage-Monitoring-Support
The Usage-Monitoring-Support AVP (AVP code 1070) is of type Enumerated and is used by
the PCRF to indicate whether usage monitoring shall be disabled for certain Monitoring Key.
The following values are defined:
USAGE_MONITORING_DISABLED (0)
This value indicates that usage monitoring is disabled for a monitoring key.
The PCRF may send an CCA/RAR with to disable usage monitoring for a monitoring key,
with the Usage-Monitoring-Information AVP including the applicable monitoring key within
the Monitoring-Key AVP and the Usage-Monitoring-Support AVP set to
USAGE_MONITORING_DISABLED.
When the PCRF disables usage monitoring in a RAR or CCA command, the PCEF shall send
a new CCR command to report accumulated usage for the disabled usage monitoring key(s).
When PCEF received a RAR/CCA which indicate to disable usage monitoring instances not existing, the
PCEF shall ignore the disable indication with no error occurs and reply success.
9.84 Monitoring-Key
The Monitoring-Key AVP (AVP code 1066) is of type OctetString and is used for usage
monitoring control purposes as an identifier to a usage monitoring control instance.
9.85 CC-Total-Octets
The CC-Total-Octets AVP (AVP Code 421) is of type Unsigned64 and contains the total
number of requested, granted, or used octets regardless of the direction (sent or received).
9.86 Granted-Service-Unit
Granted-Service-Unit AVP (AVP Code 431) is of type Grouped and contains the amount of
units that the Diameter credit-control client can provide to the end user until the service must
be released or the new Credit-Control-Request must be sent. A client is not required to
implement all the unit types, and it must treat unknown or unsupported unit types in the
answer message as an incorrect CCA answer. In this case, the client MUST terminate the
credit-control session and indicate in the Termination-Cause AVP reason
DIAMETER_BAD_ANSWER.
The Granted-Service-Unit AVP is defined as follows (per the grouped-avp-def of RFC 3588
[DIAMBASE]):
Granted-Service-Unit ::= < AVP Header: 431 >
[ Tariff-Time-Change ]
[ CC-Time ]
[ CC-Money ]
[ CC-Total-Octets ]
[ CC-Input-Octets ]
[ CC-Output-Octets ]
[ CC-Service-Specific-Units ]
*[ AVP ]
The CC-Total-Octets is used by the PCRF to indicate total granted volume (i.e. Input + Output).
The CC-Time is used by the PCRF to indicate total granted duration (i.e. Input + Output).
Tariff-Time-Change, CC-Money, CC-Input-Octets, CC-Output-Octets, and CC-Service-Specific-
Units are not used now.
*[AVP] is not supported.
9.87 Used-Service-Unit
The Used-Service-Unit AVP is of type Grouped (AVP Code 446) and contains the amount of
used units measured from the point when the service became active or, if interim
interrogations are used during the session, from the point when the previous measurement
ended. The Used-Service-Unit AVP is defined as follows (per the grouped-avp-def of RFC
3588 [DIAMBASE]):
Used-Service-Unit ::= < AVP Header: 446 >
[ Tariff-Change-Usage ]
[ CC-Time ]
[ CC-Money ]
[ CC-Total-Octets ]
[ CC-Input-Octets ]
[ CC-Output-Octets ]
[ CC-Service-Specific-Units ]
*[ AVP ]
The CC-Total-Octets shall be used by the PCEF to indicate total used volume (i.e. Input + Output).
The CC-Time shall be used by the PCEF to indicate total used duration (i.e. Input + Output).
Tariff-Time-Change, CC-Money, CC-Input-Octets, CC-Output-Octets, and CC-Service-Specific-
Units are not used now.
9.88 Revalidation-Time
The Revalidation-Time AVP (AVP code 1042) is of type Time. This value indicates the NTP
time before which the PCEF will have to re-request PCC rules. This value shall be provided
with the event trigger when REVALIDATION_TIMEOUT is provisioned via CCA or RAR.
9.89 Session-Release-Cause
The Session-Release-Cause AVP (AVP code 1045) is of type Enumerated, and determines the
cause of release the IP-CAN session by the PCRF. The following values are defined:
UNSPECIFIED_REASON (0)
This value is used for unspecified reasons.
UE_SUBSCRIPTION_REASON (1)
This value is used to indicate that the subscription of UE has changed (e.g. removed) and
the session needs to be terminated.
INSUFFICIENT_SERVER_RESOURCES (2)
This value is used to indicate that the server is overloaded and needs to abort the session.
9.90 RAT-Type
The RAT-Type AVP (AVP code 1032) is of type Enumerated and is used to identify the radio
access technology that is serving the UE.
Values 0-999 are used for generic radio access technologies that can apply to different IP-CAN types
and are not IP-CAN specific.
Values 1000-1999 are used for 3GPP specific radio access technology types.
Values 2000-2999 are used for 3GPP2 specific radio access technology types.
The informative Annex C presents a mapping between the code values for different access network
types.
This value shall be used to indicate that the RAT is GERAN. For further details refer to
3GPP TS 29.060 [18].
GAN (1002)
This value shall be used to indicate that the RAT is GAN. For further details refer to
3GPP TS 29.060 [18] and 3GPP TS 43.318 [29].
HSPA_EVOLUTION (1003)
This value shall be used to indicate that the RAT is HSPA Evolution. For further details
refer to 3GPP TS 29.060 [18].
EUTRAN (1004)
This value shall be used to indicate that the RAT is EUTRAN. For further details refer to
3GPP TS 29.274 [22]
CDMA2000_1X (2000)
This value shall be used to indicate that the RAT is CDMA2000 1X. For further details
refer to 3GPP2 X.S0011-D [20].
HRPD (2001)
This value shall be used to indicate that the RAT is HRPD. For further details refer to
3GPP2 X.S0011-D [20].
UMB (2002)
This value shall be used to indicate that the RAT is UMB. For further details refer to
3GPP2 X.S0011-D [20].
EHRPD (2003)
This value shall be used to indicate that the RAT is eHRPD. For further details refer to
3GPP2 X.P0057 [24].
9.91 Default-EPS-Bearer-QoS
The Default-EPS-Bearer-QoS AVP (AVP code 1049) is of type Grouped, and it defines the
QoS information for the EPS default bearer. When this AVP is sent from the PCEF to the
PCRF, it indicates the subscribed QoS for the default EPS bearer. When this AVP is sent from
the PCRF to the PCEF, it indicates the authorized QoS for the default EPS bearer.
Default-EPS-Bearer-QoS::= < AVP Header: 1049 >
[ QoS-Class-Identifier ]
[ Allocation-Retention-Priority]
* [AVP]
[Pre-emption-Capability]
[Pre-emption-Vulnerability]
9.94 Pre-emption-Capability
The Pre-emption-Capability AVP (AVP code 1047) is of type Enumerated. The AVP defines
whether a service data flow can get resources that were already assigned to another service
data flow with a lower priority level.
The following values are defined:
PRE-EMPTION_CAPABILITY_ENABLED (0)
This value indicates that the service data flow is allowed to get resources that were
already assigned to another service data flow with a lower priority level.
PRE-EMPTION_CAPABILITY_DISABLED (1)
This value indicates that the service data flow is not allowed to get resources that were
already assigned to another service data flow with a lower priority level. This is the
default value applicable if this AVP is not supplied.
9.95 Pre-emption-Vulnerability
The Pre-emption Vulnerability AVP (AVP code 1048) is of type Enumerated. The AVP defines
whether a service data flow can lose the resources assigned to it in order to admit a service
data flow with higher priority level.
The following values are defined:
PRE-EMPTION_VULNERABILITY_ENABLED (0)
This value indicates that the resources assigned to the service data flow can be pre-
empted and allocated to a service data flow with a higher priority level. This is the
default value applicable if this AVP is not supplied.
PRE-EMPTION_VULNERABILITY_DISABLED (1)
This value indicates that the resources assigned to the service data flow shall not be pre-
empted and allocated to a service data flow with a higher priority level.
9.96 APN-Aggregate-Max-Bitrate-DL
The APN-Aggregated-Max-Bitrate-DL AVP (AVP code 1040) is of type Unsigned32, and it
indicates the maximum aggregate bit rate in bits per seconds for the downlink direction across
all non-GBR bearers related with the same APN.
When provided in a CC-Request, it indicates the subscribed maximum bitrate. When provided
in a CC-Answer, it indicates the maximum bandwidth authorized by PCRF.
9.97 APN-Aggregate-Max-Bitrate-UL
The APN-Aggregated-Max-Bitrate-UL AVP (AVP code 1041) is of type Unsigned32, and it
indicates the maximum aggregate bit rate in bits per seconds for the uplink direction across all
non-GBR bearers related with the same APN.
When provided in a CC-Request, it indicates the subscribed maximum bandwidth. When
provided in a CC-Answer, it indicates the maximum bandwidth authorized by PCRF.
{ Feature-List }
*[AVP]
9.102 Rule-Activation-Time
The Rule-Activation-Time AVP (AVP code 1043) is of type Time. This value indicates the
NTP time at which the PCC rule has to be enforced. The AVP is included in Charging-Rule-
Install AVP and is applicable for all the PCC rules included within the Charging-Rule-Install
AVP
9.103 Rule-Deactivation-Time
The Rule-Deactivation-Time AVP (AVP code 1044) is of type Time. This value indicates the
NTP time at which the PCEF has to stop enforcing the PCC rule. The AVP is included in
Charging-Rule-Install AVP and is applicable for all the PCC rules included within the
Charging-Rule-Install AVP
9.104 X-HW-Subscriber-Service-Definition
The X-HW-Subscriber-Service-Definition AVP (AVP code 2009) is of type Grouped. It
defines the service of the subscriber.
AVP Format is depicted as follows:
X-HW-Subscriber-Service-Definition ::= < AVPCode::= 2009, Vendor-Id::=2011>
{X-HW-Subscriber-Service-Name}
[X-HW-Subscriber-Service-Username]
[ X-HW-Subscriber-Service-Password]
9.105 X-HW-Subscriber-Service-Name
The X-HW-Subscriber-Service-Name AVP (AVP Code 2010) is of type UTF8String, which
contains the service name. The X-HW-Service-Name MUST NOT be longer than 63 bytes in
length.
9.106 X-HW-Subscriber-Service-Username
The X-HW-Subscriber-Service-Username AVP (AVP Code 2011) is of type UTF8String,
which contains the username for the service. The X-HW-Service- Username MUST NOT be
longer than 63 bytes in length.
9.107 X-HW-Subscriber-Service-Password
The X-HW-Subscriber-Service-Password AVP (AVP Code 2012) is of type OctetString and
contains the password of the user for the service to be authenticated.
The X-HW-Subscriber-Service-Password AVP contains a user password and therefore
represents sensitive information.
The X-HW-Subscriber-Service-Password MUST NOT be longer than 63 bytes in length.
For PCC rules created as a result of UE-initiated resource allocation, the PCRF shall assign
and include the packet filter identifier in the Packet-Filter-Identifier AVP.
The Flow-Information AVP may also include the Type-of-Service/Traffic Class, the IPSec
SPI, and the Flow Label. The values of these AVPs are obtained from the packet filter
information provided by the PCEF.
The Flow-Direction AVP shall be included unless no other AVPs other than Packet-Filter-
Identifier AVP are included within the Flow-Information AVP.
AVP Format:
Flow-Information ::= < AVP Header: 1058 >
[ Flow-Description ]
[ Packet-Filter-Identifier ]
[ Packet-Filter-Usage ]
[ ToS-Traffic-Class ]
[ Security-Parameter-Index ]
[ Flow-Label ]
[ Flow-Direction ]
*[ AVP ]
9.109 Packet-Filter-Content
The Packet-Filter-Content AVP (AVP code 1059) is of type IPFilterRule, and it contains the
content of the packet filter as requested by the UE and required by the PCRF to create the
PCC rules. The following information shall be sent:
Action shall be set to "permit".
Direction shall be set to "out".
Protocol shall be set to the value provided within the packet filter provided by the UE. If
not provided, Protocol shall be set to "ip".
Source IP address (possibly masked). The Source IP address shall be derived from the
packet filter parameters, for the remote end, sent by the UE. If the Source IP address is
not provided by the UE, this field shall be set to "any".
Source and/or destination port (single value, list or ranges). The information shall be
derived from the remote and/or local port packet filter parameters. Source and/or
destination port(s) shall be omitted if the corresponding information is not provided in
the packet filter.
Destination IP address (possibly masked). The Destination IP address shall be derived
from the packet filter parameters sent by the UE. The Destination shall be set to the value
provided by the UE or "assigned", to refer to the IPv4 address and/or IPv6 prefix of the
UE as indicated by the Framed-IP-Address and/or Framed-IPv6-Prefix AVPs.
The IPFilterRule type shall be used with the following restrictions:
No options shall be used.
The invert modifier "!" for addresses shall not be used.
The direction "out" indicates that the IPFilterRule "source" parameters correspond to the
"remote" parameters in the packet filter and the IPFilterRule "destination" parameters
correspond to the "local" (UE end) parameters. The Packet-Filter-Content AVP applies in the
direction(s) as specified in the accompanying Flow-Direction AVP
9.110 Packet-Filter-Identifier
The Packet-Filter-Identifier AVP (AVP code 1060) is of type OctetString, and it indicates the
identity of the packet filter. The packet filter identifier is assigned by the PCRF and within
the scope of the PCRF is unique per UE.
9.111 Packet-Filter-Information
The Packet-Filter-Information AVP (AVP code 1061) is of type Grouped, and it contains the
information from a single packet filter sent from the PCEF to the PCRF. Depending on the
Packet-Filter-Operation included within the CCR command it may include the packet filter
identifier, evaluation precedence, filter value, filter direction, Type-of-Service/Traffic Class,
the IPSec SPI, and the Flow Label.
When the Packet-Filter-Operation AVP included within the CCR command indicates
DELETION, only the Packet-Filter-Identifier AVP shall be provided.
The Flow-Direction AVP shall be included unless no other AVPs other than Packet-Filter-
Identifier AVP are included within the Packet-Filter-Information AVP.
See annex B.3.4 for E-UTRAN specific details.
AVP Format:
Packet-Filter-Information ::= < AVP Header: 1061 >
[ Packet-Filter-Identifier ]
[ Precedence ]
[ Packet-Filter-Content ]
[ ToS-Traffic-Class ]
[ Security-Parameter-Index ]
[ Flow-Label ]
[ Flow-Direction ]
*[ AVP ]
9.112 Packet-Filter-Operation
The Packet-Filter-Operation AVP (AVP code 1062) is of type of Enumerated, and it indicates
a UE initiated resource operation that causes a request for PCC rules.
9.114 3GPP-MS-TimeZone
3GPP-MS-TimeZone AVP (AVP code 23) indicates the offset between universal time and
local time in steps of 15 minutes of where the MS currently resides.
For details, please refer to 3GPP TS 29.061 and 3GPP TS 23.003.
9.115 CC-Time
The CC-Time AVP (AVP Code 420) is of type Unsigned32 and indicates the length of the
requested, granted, or used time in seconds.
9.116 User-Equipment-Info
The User-Equipment-Info AVP (AVP Code 458) is of type Grouped and allows the credit-
control client to indicate the identity and capability of the terminal the subscriber is using for
the connection to network.
It is defined as follows (per the grouped-avp-def of RFC 3588 [DIAMBASE]):
User-Equipment-Info ::= < AVP Header: 458 >
{ User-Equipment-Info-Type }
{ User-Equipment-Info-Value }
9.117 User-Equipment-Info-Type
The User-Equipment-Info-Type AVP is of type Enumerated (AVP Code 459) and defines the
type of user equipment information contained in the User-Equipment-Info-Value AVP.
This specification defines the following user equipment types. However, new User-
Equipment-Info-Type values can be assigned by an IANA designated expert, as defined in
section 12.
IMEISV 0
The identifier contains the International Mobile Equipment Identifier and Software Version in
the international IMEISV format according to 3GPP TS 23.003 [3GPPIMEI].
MAC 1
The 48-bit MAC address is formatted as described in [RAD802.1X].
EUI64 2
The 64-bit identifier used to identify hardware instance of the product, as defined in [EUI64].
MODIFIED_EUI64 3
There are a number of types of terminals that have identifiers other than IMEI, IEEE 802
MACs, or EUI-64. These identifiers can be converted to modified EUI-64 format as described
in [IPv6Addr] or by using some other methods referred to in the service-specific
documentation.
9.118 User-Equipment-Info-Value
The User-Equipment-Info-Value AVP (AVP Code 460) is of type OctetString. The User-
Equipment-Info-Type AVP defines which type of identifier is used.
9.119 X-HW-Cell-Congestion-Level
The X-HW-Cell-Congestion-Level AVP (AVP Code 2028) is of type Unsigned32 and it
defines on what level the PCEF reports the congestion status for the cell.
9.120 X-HW-Session-Restoration
The X-HW-Session-Restoration AVP (AVP Code 2026) is of type Enumerated. If the X-HW-
Session-Restoration AVP is embedded within the CCA on command level, it indicates the
current session is restored, and GGSN should install the rules in the current CCA and remove
old rules. The absence of this AVP within the CCA indicates GGSN doesnt need to remove
old rules.
9.121 Gx-TMO-Redirect-Server
The TMO-Redirect-Server AVP (AVP Code 111) is of type Grouped and contains the address
information of the redirect server (e.g., HTTP redirect server, SIP Server) with which the end
user is to be redirected to.
Gx-TMO-Redirect-Server ::= < AVP Header: AVP Code 111, V-Bit set, Vendor-ID 29168>
It is defined as follows (per the grouped-avp-def of RFC 3588 [1]):
Gx-TMO-Redirect-Server ::= < AVP Header: 111 >
{ Gx-TMO-Redirect-Address-Type }
{ Gx-TMO-Redirect-Server-Address }
[Gx-TMO-Append-Original-URL ]
[Gx-TMO-Append-MSISDN ]
[Gx-TMO-Append-IMSI ]
[Gx-TMO-Append-IMEI ]
[Gx-TMO-Append-MSIP ]
[Gx-TMO-Deactivate-By-Redirect ]
*[ TMO-AVP ]
9.122 Gx-TMO-Redirect-Address-Type
The Gx-TMO-Redirect-Address-Type AVP (AVP Code 112) is of type Enumerated and
defines the address type of the address given in the TMO-Redirect-Server-Address AVP.
Gx-TMO-Redirect-Address-Type ::= < AVP Header: AVP Code 112, V-Bit set, Vendor-ID
29168>
The address type can be one of the following:
IPv4 Address 0
The address type is in the form of "dotted-decimal" IPv4 address, as defined in [8].
IPv6 Address 1
The address type is in the form of IPv6 address, as defined in [9]. The address is a text
representation of the address in either the preferred or alternate text form [9]. The PCEF
and the PCRF must support the preferred form and should support the alternate text form
for IPv6 addresses.
URL 2
The address type is in the form of Uniform Resource Locator, as defined in [10].
SIP URI 3
The address type is in the form of SIP Uniform Resource Identifier, as defined in [11].
9.123 Gx-TMO-Redirect-Server-Address
The Gx-TMO-Redirect-Server-Address AVP (AVP Code 113) is of type UTF8String and
defines the address of the redirect server (e.g., HTTP redirect server, SIP Server) with which
the end user is to be connected.
Gx-TMO-Redirect-Server-Address ::= < AVP Header: AVP Code 113, V-Bit set, Vendor-ID
29168>
9.124 Gx-TMO-Append-Original-URL
The Gx-TMO-Append-Original-URL AVP (AVP Code 114) is of type Enumerated and defines
that the original URL of the HTTP get shall be included as a CGI parameter to the redirection
URL.
The original URL in the redirection URL should be sent via a CGI parameter separated with
question marks.
E.g. Redirection URL=www.t-mobile.de/passes?originalurl=www.dbank.de/savings
Gx-TMO-Append-Original-URL ::= < AVP Header: AVP Code 114, V-Bit set, Vendor-ID
29168>
The AVP can be set to one of the following values:
disable 0 (default) // do not append the original URL
enable 1 // append the original URL
9.125 Gx-TMO-Deactivate-By-Redirect
The Gx-TMO-Deactivate-By-Redirect AVP (AVP Code 119) is of type Enumerated and
defines that the redirection rule shall be disabled immediately when the GGSN detects a
HTTP Get with the redirection URL in the redirection flow. (One-Shot-Redirection)
Gx-TMO-Deactivate-By-Redirect ::= < AVP Header: AVP Code 119, V-Bit set, Vendor-ID
29168>
The AVP can be set to one of the following values:
disable 0 (default) // the rule is not deactivated once enforced
enable 1 // the rule is deactivated once enforced
9.126 Gx-TMO-Append-MSISDN
The Gx-TMO-Append-MSISDN AVP (AVP Code 115) is of type Enumerated and defines that
the MSISDN of the mobile station shall be included as a CGI parameter to the redirection
URL.
E.g. Redirection URL=redirect.t-mobile.com/passes?
MSIDN=491715930327&IMSI=262011949000627&IMEI=353023016381662&MSIP=10.19
8.67.118&originalurl=www.dbank.de/savings?cookie1=1234&cookie2=2345
Gx-TMO-Append-MSISDN ::= < AVP Header: AVP Code 115, V-Bit set, Vendor-ID 29168>
The AVP can be set to one of the following values:
disable 0 (default) // do not append the MSISDN
enable 1 // append the MSISDN
9.127 Gx-TMO-Append-IMSI
The Gx-TMO-Append-IMSI AVP (AVP Code 116) is of type Enumerated and defines that the
IMSI of the mobile station shall be included as a CGI parameter to the redirection URL.
E.g. Redirection URL= redirect.t-mobile.com/ passes?
MSIDN=491715930327&IMSI=262011949000627&IMEI=353023016381662&MSIP=10.19
8.67.118&originalurl=www.dbank.de/savings?cookie1=1234&cookie2=2345
Gx-TMO-Append-IMSI ::= < AVP Header: AVP Code 116, V-Bit set, Vendor-ID 29168>
The AVP can be set to one of the following values:
disable 0 (default) // do not append the IMSI
enable 1 // append the IMSI
9.128 Gx-TMO-Append-IMEI
The Gx-TMO-Append-IMEI AVP (AVP Code 117) is of type Enumerated and defines that the
IMEI of the mobile station shall be included as a CGI parameter to the redirection URL.
E.g. Redirection URL= redirect.t-mobile.com/passes?
MSIDN=491715930327&IMSI=262011949000627&IMEI=353023016381662&MSIP=10.19
8.67.118&originalurl=www.dbank.de/savings?cookie1=1234&cookie2=2345
Gx-TMO-Append-IMEI ::= < AVP Header: AVP Code 117, V-Bit set, Vendor-ID 29168>
The AVP can be set to one of the following values:
disable 0 (default) // do not append the IMEI
enable 1 // append the IMEI
9.129 Gx-TMO-Append-MSIP
The Gx-TMO-Append-MSIP AVP (AVP Code 118) is of type Enumerated and defines that the
IP-Address assigned to the mobile station (PDP address, framed IP address) shall be included
as a CGI parameter to the redirection URL.
IPv4 and IPv6 addresses shall be supported.
In case of an IPv6 address, the address type is in the form of IPv6 address, as defined in [9].
The address is a text representation of the address in either the preferred or alternate text form
[9]. The PCEF and the PCRF must support the preferred form and should support the alternate
text form for IPv6 addresses.
E.g. Redirection URL= redirect.t-mobile.com/passes?
MSIDN=491715930327&IMSI=262011949000627&IMEI=353023016381662&MSIP=10.19
8.67.118&originalurl=www.dbank.de/savings?cookie1=1234&cookie2=2345
Gx-TMO-Append-MSIP ::= < AVP Header: AVP Code 118, V-Bit set, Vendor-ID 29168>
The AVP can be set to one of the following values:
disable 0 (default) // do not append the MSIP
enable 1 // append the MSIP
9.130 X-HW-MS-Group-Name
The X-HW-MS-Group-Name AVP (AVP Code 2021) is of type UTF8String and contains the
multi- broadcast group name. The X-HW-MS-Group-Name MUST NOT be longer than 31
bytes in length.
9.131 X-HW-ACL-Group-Name
The X-HW-ACL-Group-Name AVP (AVP Code 2022) is of type UTF8String and contains the
ACL group name. The X-HW-ACL-Group-Name MUST NOT be longer than 31 bytes in
length.
9.132 X-HW-Interim-Interval
The X-HW-Interim-Interval AVP (AVP Code 2023) is of type Unsigned32 and indicates that
after the interim interval, BRAS will send charging message to PCRF or AAA.
9.133 X-HW-Service-Type
The X-HW-Service-Type AVP (AVP Code 2024) is of type Enumerated and indicates the
service type which type service PCRF will send to BRAS.
The AVP can be set to one of the following values:
DPI 0
BOD 1
DAA 2
9.134 X-HW-User-Physical-Info-Value
The X-HW-User-Physical-Info-Value AVP (AVP Code 2025) is of type UTF8String and
contains the physical position where subscriber logs in at BRAS.
Format:{atm|eth|trunk}"NAS_slot/NAS_subslot/NAS_port:XPI.XCI
The X-HW-User-Physical-Info-Value MUST NOT be longer than 255 bytes in length.
9.135 Flow-Direction
The Flow-Direction AVP (AVP code 1080) is of type Enumerated. It indicates the
direction/directions that a filter is applicable, downlink only, uplink only or both down- and
uplink (bidirectional).
UNSPECIFIED (0)
The corresponding filter applies for traffic to the UE (downlink), but has no specific
direction declared. The service data flow detection shall apply the filter for uplink traffic
as if the filter was bidirectional. The PCRF shall not use the value UNSPECIFIED in
filters created by the network in NW-initiated procedures. The PCRF shall only include
the value UNSPECIFIED in filters in UE-initiated procedures if the same value is
received from in the CCR request from the PCEF.
DOWNLINK (1)
The corresponding filter applies for traffic to the UE.
UPLINK (2)
The corresponding filter applies for traffic from the UE.
BIDIRECTIONAL (3)
The corresponding filter applies for traffic both to and from the UE.
9.136 Packet-Filter-Usage
The Packet-Filter-Usage AVP (AVP code 1072) is of type of Enumerated, and it indicates
whether the UE shall be provisioned with the related traffic mapping information, i.e. the
packet filter. Traffic mapping information may be sent to the UE as per the relevant IP-CAN
specifications even if not instructed to do so with the Packet-Filter-Usage AVP.
The following values are defined:
SEND_TO_UE (1)
This value is used to indicate that the related traffic mapping information, i.e. the packet filter,
shall be sent to the UE, if applicable to the IP-CAN type as per relevant IP-CAN
specifications.
9.137 X-HW-Content-Filter
< X-HW- Content-Filter > ::=< AVP Header: AVP Code 2013, V-Bit set, Vendor-ID 2011 >
The X-HW-Content-Filter AVP (AVP Code 2013) is of type Enumerated. It indicates the
PCEF whether the current user has enabled Content Filter service. It can be provisioned or
updated at any time through CCA-I/CCA-U/RAR messages. This AVP is optional and its
absence means that the user doesnt subscribe the content filtering service.
The following values are defined:
DISABLE_CONTENT_FILTER (0)
This value shall be used to indicate that the Content Filter service shall be disabled.
ENABLE_CONTENT_FILTER (1)
This value shall be used to indicate that the Content Filter service shall be enabled.
9.138 X-HW-Content-Filter-Information
< X-HW-Content-Filter-Information > ::=< AVP Header: AVP Code 2038, V-Bit set, Vendor-
ID 2011 >
*[ X-HW-Content-Filter-Category-Basename ]
*[AVP]
The X-HW-Content-Filter-Information AVP (AVP Code 2038) is of type Grouped. It can only
be sent from PCRF to PCEF to indicate the PCEF the details of content filtering service. It
can also be carried in CCA-I/CCA-U or RAR message.
If X-HW-Content-Filter AVP is supplied and set to ENABLE_CONTENT_FILTER, X-HW-
Content-Filter-Information AVP is not supplied, There are two scenarios: the content filtering
service of this user will be enabled with the content filtering category(s) in PCEF when this
service is still not available. The other is PCEF will ignore this AVP when the content filtering
service is already enabled
If both X-HW-Content-Filter AVP and X-HW-Content-Filter-Information AVP are supplied
and X-HW-Content-Filter set to ENABLE_CONTENT_FILTER, The content filtering service
of this user will be enabled and the category(s) of X-HW-Content-Filter-Information will
overrides the previous one in PCEF.
If X-HW-Content-Filter AVP is supplied and set to DISABLE_CONTENT_FILTER , PCEF
will stop the content filtering service whatever X-HW-Content-Filter-Information AVP is
available or not.
9.139 X-HW-Content-Filter-Category-Basename
< X-HW-Content-Filter-Category-Basename > ::=< AVP Header: AVP Code 2027, V-Bit set,
Vendor-ID 2011 >
9.140 X-HW-Tethering-Status
< X-HW-Tethering-Status > ::=< AVP Header: AVP Code 2029, V-Bit set, Vendor-ID 2011 >
The X-HW-Tethering-Status AVP is of type Enumerated and indicates the tethering status of
the current user. The "TETHERING_REPORT (101)" Event-Trigger and X-HW-Tethering-
Status AVP must appear in the CCR message together.
The following values are defined:
Start (0): This value indicates that the beginning of the tethering behavior.
Stop (1): This value indicates that the end of the tethering behavior..
9.141 X-HW-Redirect-Times
<X-HW-Redirect-Times> ::= < AVPCode::= 2036, Vendor-Id::=2011> Unsigned32, value
range 1~254.
The X-HW-Redirect-Times indicates the number of Redirection allowed of the current user.
9.142 X-HW-Redirect-Report
<X-HW-Redirect-Report> ::= < AVPCode::= 2037, Vendor-Id::=2011> Enumerated
The X-HW- Redirect-Report indicates whether need the PCEF to report the redirection of the
current user.
The following values are defined:
Disable (0): No need to report Redirection to PCRF
Enable (1): Need to report Redirection to PCRF
9.143 3GPP2-BSID
The Flow-Direction AVP (AVP code 9010) is of type UTF8String, for 3GPP2 indicates the
BSID of where the UE is currently located (e.g. Cell-Id, SID, NID).
The Vendor-Id shall be set to 3GPP2 (5535) [24].
The support of this AVP shall be advertised in the capabilities exchange mechanisms
(CER/CEA) by including the value 5535, identifying 3GPP2, in a Supported-Vendor-Id AVP.
This AVP shall have the M bit cleared.
9.144 Resource-Allocation-Notification
The Resource-Allocation-Notification AVP (AVP code 1063) is of type Enumerated.
If the Resource-Allocation-Notification AVP is included within a Charging-Rule-Install AVP
it defines whether the rules included within the Charging-Rule-Install AVP need be notified.
The following values are defined:
ENABLE_NOTIFICATION (0)
This value shall be used to indicate that the allocation of resources for the related PCC rules
shall be confirmed.
9.145 SN-Service-Flow-Detection
<SN-Service-Flow-Detection> ::= < AVPCode::= 520, Vendor-Id::=8164> Enumerated.
The SN-Service-Flow-Detection indicates whether the service flow detection function is
enabled for the PCEF.
The following values are defined:
ENABLE_DETECTION(0): Need to report Redirection to PCRF
9.146 Required-Access-Info
The Required-Access-Info AVP (AVP code 536) is of type Enumerated, and contains the
access network information required for that AF session.
The following values are defined:
USER_LOCATION (0)
Indicates that the user location information shall be reported, the PCRF shall report the user
location information within the 3GPP-User-Location-Info AVP, if available. Otherwise, it
shall provide the serving PLMN identifier within the 3GPP-SGSN-MCC-MNC AVP.
9.147 Application-Detection-Information
The Application-Detection-Information AVP (AVP code 1098, Vendor-Id 10415) is of type
Grouped, and it is used to report once the start/stop of the application traffic, defined by TDF-
Application-Identifier, has been detected, in case PCRF has subscribed for
APPLICATION_START/APPLICATION_STOP Event-Triggers, unless a request to mute
such a notification (Mute-Notification AVP) is part of the corresponding ADC-Rule-
Definition AVP.
The corresponding TDF-Application-Identifier AVP shall be included under Application-
Detection-Information AVP. When the Event trigger indicates APPLICATION_START, the
Flow-Information AVP for the detected application, if deducible, shall be included under
Application-Detection-Information AVP. When the Flow-Information AVP is included, the
TDF-Application-Instance-Identifier AVP shall also be included. The Flow-Information AVP,
if present, shall contain the Flow-Description AVP and Flow-Direction AVP. Also, the
corresponding Event-Trigger (APPLICATION_START or APPLICATION_STOP) shall be
provided to PCRF. When the TDF-Application-Instance-Identifier AVP is included with an
APPLICATION_START event, it shall also be included when the corresponding
APPLICATION_STOP event is notified.
AVP Format:
Application-Detection-Information ::= < AVP Header: 1098 >
{ TDF-Application-Identifier }
*[ Flow-Information ]
*[ AVP ]
9.148 TDF-Application-Identifier
The TDF-Application-Identifier AVP (AVP Code 1088, Vendor-Id 10415) is of type
OctetString. It references the application (e.g. its value may represent an application such as a
list of URLs, etc.) for which the Application Detection and Control (ADC) rule applies.
9.149 Mute-Notification
The Mute-Notification AVP (AVP code 2809) is of type Enumerated, and it is used to mute
the notification to the PCRF of the detected application's start/stop for the specific PCC Rule
from the PCEF.
The following values are defined:
MUTE_REQUIRED (0)
This value is used to indicate that the PCEF shall not inform the PCRF when the applications
start/stop for the specific PCC rule(s) is detected.
Mute-Notification AVP shall be used for solicited application reporting only.
Absence of this AVP means that application start/stop notifications shall be sent for the
detected application.
9.150 Redirect-Information
The Redirect-Information AVP (AVP code 1085) is of type Grouped. It indicates whether the
detected application traffic should be redirected to another controlled address. The Redirect-
Information AVP is sent from the PCRF as a part of Charging-Rule-Definition AVP.
If the Redirect-Information AVP includes the Redirect-Server-Address AVP, the Redirect-
Address-Type AVP shall also be provided indicating the type of address given in the Redirect-
Server-Address AVP.
AVP Format:
Redirect-Information ::= < AVP Header: 1085 >
[ Redirect-Support ]
[ Redirect-Address-Type ]
[ Redirect-Server-Address ]
*[ AVP ]
9.151 Redirect-Support
The Redirect-Support AVP (AVP Code 1086) is of type Enumerated.
The following value is defined:
REDIRECTION_DISABLED (0)
This value indicates that redirection is disabled for a detected applications traffic.
REDIRECTION_ENABLED (1)
This value indicates that redirection is enabled for a detected applications traffic. This is
the default value applicable if a Redirect-Information AVP is provided for the first time and if
this AVP is not supplied.
9.152 Redirect-Address-Type
The Redirect-Address-Type AVP (AVP Code 433) is of type Enumerated and defines the
address type of the address given in the Redirect-Server-Address AVP.
The address type can be one of the following:
IPv4 Address 0
The address type is in the form of "dotted-decimal" IPv4 address, as defined in [IPv4].
IPv6 Address 1
The address type is in the form of IPv6 address, as defined in [IPv6Addr]. The address is a
text representation of the address in either the preferred or alternate text form [IPv6Addr].
Conformant implementations MUST support the preferred form and SHOULD support the
alternate text form for IPv6 addresses.
URL 2
The address type is in the form of Uniform Resource Locator, as defined in [URL].
SIP URI 3
The address type is in the form of SIP Uniform Resource Identifier, as defined in [SIP].
9.153 Redirect-Server-Address
The Redirect-Server-Address AVP (AVP Code 435) is of type UTF8String and defines the
address of the redirect server (e.g., HTTP redirect server, SIP Server) with which the end user
is to be connected when the account cannot cover the service cost.
9.154 ADC-Rule-Install
The ADC-Rule-Install AVP (AVP code 1092, Vendor-Id 10415) is of type Grouped, and it is
used to activate, install or modify ADC rules as instructed from the PCRF.
For installing a new ADC rule or modifying an ADC rule already installed, ADC-Rule-
Definition AVP shall be used.
For activating a specific predefined ADC rule, ADC-Rule-Name AVP shall be used as a
reference for that ADC rule. The ADC-Rule-Base-Name AVP is a reference that may be used
for activating a group of predefined ADC rules.
If Rule-Activation-Time or Rule-Deactivation-Time is specified then it applies to all the ADC
rules within the ADC-Rule-Install.
AVP Format:
ADC-Rule-Install ::= < AVP Header: 1092 >
*[ ADC-Rule-Name ]
*[ AVP ]
9.155 ADC-Rule-Remove
The ADC-Rule-Remove AVP (AVP code 1093, Vendor-Id 10415) is of type Grouped, and it is
used to deactivate or remove ADC rules as instructed from the PCRF.
ADC-Rule-Name AVP is a reference for a specific dynamic ADC rule to be removed or for a
specific predefined ADC rule to be deactivated. The ADC-Rule-Base-Name AVP is a
reference for a group of predefined ADC rules to be deactivated.
AVP Format:
ADC-Rule-Remove ::= < AVP Header: 1093 >
*[ ADC-Rule-Name ]
*[ AVP ]
9.156 ADC-Rule-Name
The ADC-Rule-Name AVP (AVP code 1096, Vendor-Id 10415) is of type OctetString, and it
defines a name for ADC rule. For ADC rules provided by the PCRF it uniquely identifies an
ADC rule within one IP-CAN session. For predefined ADC rules, it uniquely identifies an
ADC rule within the PCEF.
9.157 ADC-Rule-Report
The ADC-Rule-Report AVP (AVP code 1097, Vendor-Id 10415) is of type Grouped, and it is
used to report the status of ADC rules.
The ADC-Rule-Report AVP is used to report the status of the ADC rules which cannot be
installed/activated or enforced at the PCEF. In this condition, the ADC-Rule-Name AVP is
used to indicate a specific ADC rule which cannot be installed/activated or enforced, and the
ADC-Rule-Base-Name AVP is used to indicate a group of ADC rules which cannot be
activated. The PCC-Rule-Status AVP is set to INACTIVE. The Rule-Failure-Code indicates
the reason that the ADC rules cannot be successfully installed/activated or enforced.
AVP Format:
ADC-Rule-Report ::= < AVP Header: 1097 >
*[ ADC-Rule-Name ]
*[ ADC-Rule-Base-Name ]
[ PCC-Rule-Status ]
[ Rule-Failure-Code ]
*[ AVP ]
Multiple instances of ADC-Rule-Report AVPs shall be used in the case it is required to report
different PCC-Rule-Status or Rule-Failure-Code values for different groups of rules within
the same Diameter command.
9.158 AF-Signalling-Protocol
The AF-Signalling-Protocol AVP (AVP code 529) is of type Enumerated, and indicates the
protocol used for signalling between the UE and the AF. If the AF-Signalling-Protocol AVP is
not provided in the AA-Request, the value NO_INFORMATION shall be assumed.
NO_INFORMATION (0)
This value is used to indicate that no information about the AF signalling protocol is being
provided.
SIP (1)
This value is used to indicate that the signalling protocol is Session Initiation Protocol.
9.160 X-Header-Enrichment
The X-Header-Enrichment AVP (AVP code 2013, Vendor-Id 28458) is of type Grouped, and it
is used to carry the subscriber profile information as instructed from the PCRF.
AVP Format:
X-Header-Enrichment <AVP header:2013>
{X-Header-Enrichment-ID}
{X-Header-Enrichment-Data}
9.161 X-Header-Enrichment-ID
The X-Header-Enrichment-ID AVP (AVP code 2014, Vendor-Id 28458) is of type
Unsigned32, and it is used to carry the subscriber profile ID information as instructed from
the PCRF.
The value is 0 always.
9.162 X-Header-Enrichment-Data
The X-Header-Enrichment-ID AVP (AVP code 2015, Vendor-Id 28458) is of type
UTF8String, and it is used to carry the subscriber profile value information as instructed from
the PCRF.
The maximum length of this AVP is 15 bytes.
The Filter-Id AVP can be used to reference an IP filter list installed in the access device by
means other than the Diameter credit-control application, e.g., locally configured or
configured by another entity.
The Final-Unit-Indication AVP is defined as follows (per the grouped-avp-def of RFC 3588
[DIAMBASE]):
Final-Unit-Indication ::= < AVP Header: 430 >
{ Final-Unit-Action }
*[ Restriction-Filter-Rule ]
*[ Filter-Id ]
[ Redirect-Server ]
9.170 CT-Extension
The CT-Extension AVP (AVP code 2000, Vendor-Id 81000) is of type Grouped and contains
the location information of the UE.
It is defined as follows:
CT-Extension ::= < AVP Header: 2000>
[Subnet-Identifier]
*[AVP]
9.171 Subnet-Identifier
The Subnet-Identifier AVP (AVP code 2001, Vendor-Id 81000) is of type OctetString and it
indicates details of where the UE is currently located.
Subnet-Identifier is encoded as follows:
Bits
Octets 8 7 6 5 4 3 2 1
1 0 0 0 0 0 0 0 0
2 1 01 MCC(12bit)
3 MCC MNC
4 MNC(12bit)
5 MNC Prov(6bit)
6 Res(23bit)
7 Res
8 Res
9 IP Adress(32bit)
10 IP Adress
11 IP Adress
12 IP Adress
13 Color Code(8bit)
14 Sector(24bit)
15 Sector
16 Sector
9.172 QoS-Group-Rule-Install
The QoS-Group-Rule-Install AVP is used to activate qos-group-of-ruledefs for an IP-CAN
session and modify their parameters. It is defined for integrate with Cisco.
QoS-Group-Rule-Install ::= <AVP header: 132001 >
*[ QoS-Group-Rule-Definition ]
*[ AVP ]
9.173 QoS-Group-Rule-Remove
The QoS-Group-Rule-Remove AVP is used to deactivate qos-group-of-ruledefs for an IP-
CAN session. It is defined for integrate with Cisco.
QoS-Group-Rule-Remove ::= < AVP header: 132002 >
*[ QoS-Group-Rule-Name ]
*[ AVP ]
9.174 QoS-Group-Rule-Definition
The QoS-Group-Rule-Definition AVP specifies parameters for a configured qos-group-of-
ruledef whose name matches the QoS-Group-Rule-Name. It is defined for integrate with
Cisco.
QoS-Group-Rule-Definition ::= < AVP Header: 132003 >
{ QoS-Group-Rule-Name }
[ QoS-Information ]
[ Precedence ]
[ Monitoring-Key ]
[ Flow-Status ]
[ Redirect-Server ]
*[ AVP ]
9.175 QoS-Group-Rule-Name
The QoS-Group-Rule-Name AVP (AVP code = 132004) is of type OctetString and specifies
the name of a qos-group-of-ruledefs configured in ECS. Maximum String Length: 64
characters.
9.176 Redirect-Host
The Redirect-Host AVP(AVP code = 292) is of type DiamURI. One or more of instances of
this AVP MUST be present if the Result-Code AVP is set to
DIAMETER_REDIRECT_INDICATION(3006).
Upon receiving the above, the PCEF SHOULD forward the CCR directly to one of the hosts
identified in these AVPs.
This value is used to indicate that the pre-provisioned PCC rule could not be successfully
activated because the Charging-Rule-Name or Charging-Rule-Base-Name is unknown to the
PCEF.
RATING_GROUP_ERROR (2)
This value is used to indicate that the PCC rule could not be successfully installed or
enforced because the Rating-Group specified within the Charging-Rule-Definition AVP by the
PCRF is unknown or, invalid.
SERVICE_IDENTIFIER_ERROR (3)
This value is used to indicate that the PCC rule could not be successfully installed or
enforced because the Service-Identifier specified within the Charging-Rule-Definition AVP by
the PCRF is invalid, unknown, or not applicable to the service being charged.
GW/PCEF_MALFUNCTION (4)
This value is used to indicate that the PCC rule could not be successfully installed (for
those provisioned from the PCRF) or activated (for those pre-provisioned in PCEF) or
enforced (for those already successfully installed) due to GW/PCEF malfunction.
RESOURCES_LIMITATION (5)
This value is used to indicate that the PCC rule could not be successfully installed (for
those provisioned from PCRF) or activated (for those pre-provisioned in PCEF) or enforced
(for those already successfully installed) due to a limitation of resources at the PCEF.
MAX_NR_BEARERS_REACHED (6)
This value is used to indicate that the PCC rule could not be successfully installed (for
those provisioned from PCRF) or activated (for those pre-provisioned in PCEF) or enforced
(for those already successfully installed) due to the fact that the maximum number of bearers
has been reached for the IP-CAN session.
UNKNOWN_BEARER_ID (7)
This value is used to indicate that the PCC rule could not be successfully installed or
enforced at the PCEF because the Bearer-Id specified within the Charging-Rule-Install AVP
by the PCRF is unknown or invalid. Applicable only for GPRS in the case the PCRF performs
the bearer binding.
MISSING_BEARER_ID (8)
This value is used to indicate that the PCC rule could not be successfully installed or
enforced at the PCEF because the Bearer-Id is not specified within the Charging-Rule-Install
AVP by the PCRF. Applicable only for GPRS in the case the PCRF performs the bearer
binding.
MISSING_FLOW_INFORMATION (9)
This value is used to indicate that the PCC rule could not be successfully installed or
enforced because the Flow-Information AVP is not specified within the Charging-Rule-
Definition AVP by the PCRF during the first install request of the PCC rule.
RESOURCE_ALLOCATION_FAILURE (10)
This value is used to indicate that the PCC rule could not be successfully installed or
maintained since the bearer establishment/modification failed, or the bearer was released.
UNSUCCESSFUL_QOS_VALIDATION (11)
This value is used to indicate that the charging system determined that the service can be
granted to the end user but no further credit control is needed for the service (e.g. service is
free of charge or is treated for offline charging).
CM_AUTHORIZATION_REJECTED (21)
This value is used to indicate that the charging system denied the service request in order
to terminate the service for which credit is requested.
CM_USER_UNKNOWN (22)
This value is used to indicate that the specified end user could not be found in the
charging system.
CM_RATING_FAILED (23)
This value is used to inform the PCRF that the charging system cannot rate the service
request due to insufficient rating input, incorrect AVP combination or due to an AVP or an
AVP value that is not recognized or supported in the rating.