UPCC V300R006C10 GX Interface Specification

Doc.
Code
UPCC
V300R006C10
Gx Interface Specification
Issue 1.42
Date 2014-3-27
HUAWEI TECHNOLOGIES CO., LTD.

Copyright Huawei Technologies Co., Ltd. 2014. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any means without prior written
consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions

and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
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.
Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website: http://www.huawei.com
Email: support@huawei.com
Issue 1.42 (2014-3-27) Huawei Proprietary and Confidential i

Copyright Huawei Technologies Co.,
Ltd
Revision Record
Date Revision Change Description

Version
2007-8-20 1.0 Initial
2009-09-24 1.1 Add the X-HW-Monitoring-Key for usage
collection into rule definition.
2009-11-07 1.2 1. Add the 3GPP R8 Revalidation-Time related
AVP
2. Add private Proto-Classifier-Name AVP to
Charging-Rule-Definition to support dynamic
rule of Layer7.
2010-06-09 1.3 1. Add the 3GPP R9 Usage report related
AVPs, Event-Trigger.
2. Add Session-Release-Cause to RAR
message to support RAR/RAA triggered
session termination.
2010-8-26 1.4 1.Add the RAT-Type AVP in the CCR message
and the defination for this AVP.
2.Add the Default-EPS-Bearer-QoS AVP in the
CCA/RAR and the defination for Default-EPS-
Bearer-QoS, Pre-emption-Capability and Pre-
emption-Vulnerability.
3.Add the APN-Aggregate-Max-Bitrate-DL and
APN-Aggregate-Max-Bitrate-UL as the Sub-AVP
in the QoS-Information AVP and the defination.
4.Add the AN-GW-Address AVP in the CCR
message and the defination for this AVP.
5.Add the supported Location Type in the
defination for 3GPP-User-Location-Info.
6.Add the Allocation-Retention-Priority as the
Sub-AVP in QoS-Information AVP.
7.Add the Supported-Features AVP in the
CCR/CCA/RAR messages and the defination.
8.Add the Rule-Activation-Time and Rule-
Deactivation-Time as the Sub-AVP in Charging-
Rule-Install AVP and the defination.
9.Add X-HW-Subscriber-Service-Definition AVP
in the CCA/RAR messages. Add the X-HW-
Subscriber-Service-Name as the Sub-AVP in
Issue 1.42 (2014-3-27) Huawei Proprietary and Confidential ii

Ltd
Version
Charging-Rule-Definition AVP. Add the defination
for X-HW-Subscriber-Service-Definition,
X-HW-Subscriber-Service-Name,
X-HW-Subscriber-Service-Username and X-
HW-Subscriber-Service-Password.
2010-10-20 1.5 1.Add Event-Trigger(s):
(jiangguilan- RESOURCE_MODIFICATION_REQUEST (23)
VoLTE) CHARGING_CORRELATION_EXCHANGE (29)
2.Add the AVP(s):
Flow-Information AVP
Packet-Filter-Content AVP
Packet-Filter-Identifier AVP
Packet-Filter-Information AVP
Packet-Filter-Operation AVP
Charging-Correlation-Indicator AVP
2010-12-2 1.6 Add the AVP(s):
(jiangguilan- User-Equipment-Info AVP
UserEquipment) User-Equipment-Info-Type AVP
User-Equipment-Info-Value AVP
2010-12-02 1.7 1.Add Event-Trigger(s):
(wangqing) UE_TIME_ZONE_CHANGE (25)
TAI_CHANGE (25)
ECGI_CHANGE (25)
2.Modify the AVP(s):
QoS-Negotiation
QoS-Upgrade
3GPP-User-Location-Info
Granted-Service-Unit
Used-Service-Unit
3.Add AVP:
3GPP-MS-TimeZone
CC-Time
4. Modify Gx Message:
Credit-Control-Request (CCR)
2011-9-7 1.8 1. Add Event-Trigger:
(wangjuhui) APPLICATION_START(39)
APPLICATION_STOP(40)
2. Add AVP:
Application-Detection-Information AVP
TDF-Application-Identifier AVP
Issue 1.42 (2014-3-27) Huawei Proprietary and Confidential iii

Ltd
Version
2011-9-14 1.9 1. Add Event-Trigger:
(yangming) CELL_CONGESTED(1003)
CELL_ CLEAR(1004)
2. Add AVP:
X-HW-Cell-Congestion-Level AVP
2011-9-21 1.10 1. Add X-HW-Session-Restoration AVP
(wangqing) 2. Modify Charging-Rule-Definition AVP
2011-9-21 1.11 Add AVP:
(liuxianghui) 1. Gx-TMO-Redirect-Server AVP
2. Gx-TMO-Redirect-Address-Type
3. Gx-TMO-Redirect-Server-Address
4. Gx-TMO-Append-Original-URL
5. Gx-TMO-Deactivate-By-Redirect
6. Gx-TMO-Append-MSISDN
7. Gx-TMO-Append-IMSI
8. Gx-TMO-Append-IMEI
9. Gx-TMO-Append-MSIP
2011-09-23 1.12 Add AVP:
(xuezhen) 1. X-HW-User-Physical-Info-Value
2. X-HW-Service-Type
3. X-HW-MS-Group-Name
4. X-HW-ACL-Group-Name
5. X-HW-Interim-Interval
6. IP-CAN-Type
2011-11-11 1.13 1. Delete Event-Trigger:
APPLICATION_START(39)
APPLICATION_STOP(40)
2. Delete AVP:
Application-Detection-Information AVP
2011-11-30 1.14 Add AVP:
(yangming) 1. Flow-Direction
2. Packet-Filter-Usage
2012-02-17 1.15 Baseline for UPCC V300R005C10
(yangming)
2012-03-11 1.16 Baseline for UPCC V300R005C01 from PCC
(yubin/39067) V300R005C10
2012-03-17 1.16 Add AVP
(wangqing54499) 1. X-HW-Content-Filter
2. X-HW-Content-Filter-Information
Issue 1.42 (2014-3-27) Huawei Proprietary and Confidential iv

Ltd
Version
3. X-HW-Content-Filter-Category-Basename
2012-3-27 1.17 1. Add Event-TriggerTethering_Report(101)
shixian 2. Add AVPX-HW-Tethering-Status
00111731
2012-4-18 1.18 Add event trigger:
(wanglin 39122) SUCCESSFUL_RESOURCE_ALLOCATION
(22)
2012-5-26 1.19 1. Add AVP: X-HW- Redirect-Times

xubin 38208 2. Add AVP: X-HW-Redirect-Report
3. Add Event-Trigger: Redirection(100)
2012-8-15 1.20 Add AVP:
(wanglin 39122) Resource-Allocation-Notification
(jiangzhihua V300R005C01
58189
(jiangzhihua V300R005C13
58189
2013-1-28 1.22 1. Add event trigger:
(liuhongyan ACCESS_NETWORK_INFO_REPORT (45)
138761) 2. Add Required-Access-Info AVP included in
Charging-Rule-Definition AVP.
2013-1-29 1.23 1. Add X-HW-Validity-Time AVP included in
(jiangguilan Charging-Rule-Install AVP.
67049) 2. Add AVP
X-HW-Validity-Time,
X-HW-Activation-Time,
X-HW-Deactivation-Time,
X-HW-Activation-Day,
X-HW-Deactivation-Day,
X-HW-Activity-Timer
2013-03-02 1.24 Add AVP:
(jianzhihua 58189) SN-Service-Flow-Detection
Add Trigger:
SERVICE_FLOW_DETECTION (1002)
2013-03-22 1.25 According to DTS2013032100707:
(jiangguilan 1. Add Event-Trigger:
67049) APPLICATION_START(39)
2. Add AVP:
Application-Detection-Information
Issue 1.42 (2014-3-27) Huawei Proprietary and Confidential v

Ltd
Version
TDF-Application-Identifier
ADC-Rule-Install
ADC-Rule-Remove
ADC-Rule-Name
ADC-Rule-Report
2013-04-09 1.26 Delete the Follow AVP:
1. X-HW-Validity-Time AVP included in
Charging-Rule-Install AVP.
2.
X-HW-Validity-Time,
X-HW-Activation-Time,
X-HW-Deactivation-Time,
X-HW-Activation-Day,
X-HW-Deactivation-Day,
X-HW-Activity-Timer
2013-05-04 1.27 According to DTS2013042503529 :
1. Add AVP:
AF-Signalling-Protocol,
Event-Report-Indication AVP
2. Add AF-Signalling-Protocol AVP included in
Charging-Rule-Definition AVP.
3. Add Event-Report-Indication AVP included
in Re-Auth-Request (RAR)
2013-05-09 1.28 Baseline for UPCC V300R005C16 from UPCC
V300R005C15
2013-06-04 1.29 Modify AVP:
CC-Input-Octets
CC-Output-Octets
2013-06-26 1.30 Add Trigger
APN-AMBR_MODIFICATION_FAILURE (29)
DEFAULT-EPS-BEARER-
QOS_MODIFICATION_FAILURE (34)
V300R005C16 and V300R006C00
2013-09-24 1.32 Add 3 AVP for subscriber profile fucntion:
X-Header-Enrichment
X-Header-Enrichment-ID
X-Header-Enrichment-Data
2013-10-22 1.33 Add Priority-Level AVP under Allocation-
Retention-Priority AVP
Issue 1.42 (2014-3-27) Huawei Proprietary and Confidential vi

Ltd
Version
V300R006C01
2013-12-2 1.35 Add Trigger:
OUT_OF_CREDIT (15)
REALLOCATION_OF_CREDIT (16)
Add AVP:
Final-Unit-Indication
Final-Unit-Action
Restriction-Filter-Rule
Filter-Id
Redirect-Server
Redirect-Address-Type
Redirect-Server-Address
2013-12-2 1.36 Add AVP:
CT-Extension
Subnet-Identifier
2013-12-21 1.37 Synchronize changes from V300R006C01
between 2013/10/29 and 2013/12/21
V300R006C02
2013-12-30 1.39 Add Redirect-Host AVP in CCA message.
2014-01-08 1.40 Add TDF-Information AVP in CCR message.
2014-03-13 1.41 Add Trigger:
SUBNET_CHANGE (2000)
2014-03-23 1.42 Add Rule-Failure-Code AVP introduction.
2014-05-13 1.43 Add
Redirect-Information AVP
Mute-Notification AVP
within Charging-Rule-Definition AVP.
Add
Flow-Information AVP
within Application-Detection-Information AVP.
Add
APPLICATION_STOP (40)
within Event-Trigger AVP.
Issue 1.42 (2014-3-27) Huawei Proprietary and Confidential vii

Ltd
UPCC
Gx Interface Specification Catalog
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
Issue 1.42 (2014-3-27) Huawei Proprietary and Confidential viii

Ltd
UPCC
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
Issue 1.42 (2014-3-27) Huawei Proprietary and Confidential ix

Ltd
UPCC
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
Issue 1.42 (2014-3-27) Huawei Proprietary and Confidential x

Ltd
UPCC
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
Issue 1.42 (2014-3-27) Huawei Proprietary and Confidential xi

Ltd
UPCC
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
Issue 1.42 (2014-3-27) Huawei Proprietary and Confidential xii

Ltd
UPCC
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
Issue 1.42 (2014-3-27) Huawei Proprietary and Confidential xiii

Ltd
UPCC
List of abbreviations
WCDMA Wide Code Division Multiplex Access

GPRS General Packet Radio Service
PCC Policy and Charging Control
FBC Flowed Based Charging
SBLP Service Based Local Policy
GGSN Gateway GPRS Support Node
SGSN Serving GPRS Support Node
PCRF Policy and Charging Rule Function
PCEF Policy and Charging Enforcement Function
OCS Online Charging System
OFCS Offline Charging System
AF Application Function
SPR Subsciber Profile Repository
IPN Intelligent Packet Network
BCM Bearer Control Mode
NRSPCA Network Requested Secondary PDP Context Activation
SDF Service Data Flow
QoS Quality of Service
QCI QoS Class Identifier
AAA Authentication, Authorization and Accounting
RADIUS Remote Authentication Dial-In User Server
FBC Flow Based Charging
COPS Common Open Policy Service
NSAPI Network Service Access Point Identifier
TI Transaction Identifier
TFT Traffic Filtering Template
IMS IP Multimedia Subsystem
SDP Session Description Protocol
CSCF Call Session Control Function
P-CSCF Proxy Call Session Control Function
ICID IMS Charging Identifier
Issue 1.42 (2014-3-27) Huawei Proprietary and Confidential xiv

Ltd
UPCC
SPR Subscription Profile Repository

APN Access Point Name
BRAS Broadband Remote Access Server
Issue 1.42 (2014-3-27) Huawei Proprietary and Confidential xv

Ltd
UPCC Gx Interface Specification ReferenceReference
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".
Issue 1.42 (2014-3-27) Huawei Proprietary and Confidential 1

Ltd
UPCC Gx Interface Specification Introduction and scopeIntroduction and scope
2 Introduction and scope
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.

Ltd
UPCC Gx Interface Specification Introduction and scopeIntroduction and scope
Figure 1.1 Gx Reference Model
Subscription Profile AF
Repository
(SPR)
Rx
Sp Policy and Charging

Rules Function
(PCRF)
Online Charging System (OCS)
CAMEL Service Data Flow Scope of Gx

SCP Based this
Credit Control document
PCEF
Gy
GW
Gz
Offline
Charging
System
(OFCS)

Ltd
UPCC Gx Interface Specification TerminologyTerminology
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

Ltd
UPCC Gx Interface Specification TerminologyTerminology
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.

Ltd
UPCC Gx Interface Specification Protocol OverviewProtocol Overview
4 Protocol Overview
Information is exchanged over Gx reference point through messages specified by Diameter

Base Protocol, Diameter Credit Control Application and Gx Application. Diameter is the
newest AAA protocol developed in 2001 from the older AAA protocol RADIUS. Diameter
Base Protocol provides a framework for AAA, and it is expected to be extended to support
new applications. Diameter Credit Control Application is developed to provide a general
solution to real-time cost and credit control. Gx application provides extended authorization
for policy and charging control and it is based on both Diameter Base Protocol and Diameter
Credit Control Application. Figure 1.2 shows the layout of Gx Interface protocol stack is
depicted as follows:
Figure 1.2 Gx Interface Protocol Stack
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.

Ltd
UPCC Gx Interface Specification Protocol OverviewProtocol Overview
4.2 Diameter Base Protocol

The Diameter Base Protocol defines the base specification for AAA, which includes support
for accounting. The Diameter Base Protocol may be used by itself for accounting applications,
but for use in authentication and authorization it is always extended for a particular
application. The Diameter Base Protocol concerns itself with capabilities negotiation, how
messages are sent and how peers may eventually be abandoned, etc. The base protocol also
defines certain rules that apply to all exchanges of messages between Diameter nodes.
Please refer to RFC3558 for details.
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.
4.4 Interface Authentication mechanism

This interface is using Diameter protocol. This interface can use IP address for authentication.

Ltd
UPCC Gx Interface Specification TransportTransport
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.

Ltd
UPCC Gx Interface Specification ConstraintsConstraints
6 Constraints
6.1 Bearer Control Mode

In 3GPP release 7, the concept of bearer control mode is incorporated to support network
initiated QoS control, and PCC framework also provides support for this.
Huaweis UPCC supports UE-Initiated Bearer Establishment mode based on primary PDP
context activation procedure, as defined in 3GPP Rel-7.
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.2 QoS negotiation

In 3GPP Release 7 there have been some additions in relation with the QoS capabilities that
the SGSN could support. According to Stage 3 GPRS specifications, SGSN may indicate the
GGSN:
Whether it supports QoS upgrading from the GGSN.
Whether it is possible to negotiate the QoS provided in the PDP Update PDP Context.
The SGSN limitations have to be provided to PCRF so that it can act accordingly when
authorizing the received QoS information in the cases where the PCRF makes the bearer
binding. Two new AVPs has been created for this purpose, QoS-Negotiation AVP and QoS-
Upgrade AVP, so that the PCEF can inform PCRF about the QoS limitations (QoS upgrading
not supported & QoS negotiation not supported) of the IP-CAN.
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.

Ltd
UPCC Gx Interface Specification ConstraintsConstraints
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.

Ltd
UPCC Gx Interface Specification MessagesMessages
7 Messages
7.1 Message Format

Figure 1.3 shows the diameter message format.
Figure 1.3 Diameter Message Format
Diameter Header AVP AVP AVP
AVP Header AVP Data
7.2 Base Messages

7.2.1 Capabilities-Exchange-Request (CER)
The Capabilities-Exchange-Request (CER), indicated by the Command-Code set to 257 and
the Command Flags' 'R' bit set, is sent to exchange local capabilities.
Message syntax:
<CER>::= < Diameter Header: 257, REQ >
{ Origin-Host }
{ Origin-Realm }
1* { Host-IP-Address }

Ltd
{ 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.2 Capabilities-Exchange-Answer (CEA)

The Capabilities-Exchange-Answer (CEA), indicated by the Command-Code set to 257 and
the Command Flags' 'R' bit cleared, is sent in response to a CER message.
Message Syntax:
<CEA>::= < Diameter Header: 257 >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
1* { Host-IP-Address }
{ Vendor-Id }
{ Product-Name }
[ Origin-State-Id ]
[ Error-Message ]
* [ Failed-AVP ]
* [ Supported-Vendor-Id ]
* [ Auth-Application-Id ]
* [ Inband-Security-Id ]
* [ Acct-Application-Id ]
* [ Vendor-Specific-Application-Id ]
[ Firmware-Revision ]
* [ AVP ]

Ltd
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 >

Ltd
{ 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 ]
7.2.8 Abort-Session-Answer (ASA)

The Abort-Session-Answer (ASA), indicated by the Command-Code set to 274 and the
message flags' 'R' bit clear, is sent in response to the ASR.
Message syntax:
<ASA>::= < Diameter Header: 274, PXY >
< Session-Id >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ Origin-State-Id ]
[ Error-Message ]
[ Error-Reporting-Host ]

Ltd
* [ 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 >
{ Origin-Host }
{ Origin-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 ]

Ltd
[ 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]

Ltd
*[ ADC-Rule-Report ]
*[ AVP ]
7.3.2 Credit-Control-Answer (CCA)

The CCA command, indicated by the Command-Code field set to 272 and the 'R' bit cleared
in the Command Flags field, is sent by the PCRF to the PCEF in response to the CCR
command. It is used to provision PCC rules and event triggers for the bearer/session and to
provide the selected bearer control mode for the IP-CAN session.
Message syntax:
<CC-Answer> ::= < Diameter Header: 272, PXY >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
[ Result-Code ]
[ Experimental-Result ]
{ CC-Request-Type }
{ CC-Request-Number }
[ Bearer-Control-Mode ]
*[ Event-Trigger ]
[ Origin-State-Id ]
*[ Redirect-Host ]
*[ Charging-Rule-Remove ]
*[ Charging-Rule-Install ]
*[ QoS-Group-Rule-Remove ]
*[ QoS-Group-Rule-Install ]
[ Charging-Information ]
[ Online ]
[ Offline ]
*[ QoS-Information ]
[ Revalidation-Time ]
[ Default-EPS-Bearer-QoS ]
[X-HW-Usage-Report]
[Session-Release-Cause]

Ltd
*[ X-HW-Subscriber-Service-Definition ]
[X-HW-Session-Restoration]
[X-HW-Content-Filter]
[X-HW-Content-Filter-Information]
[ Error-Message ]
*[ Failed-AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
*[ ADC-Rule-Install]
*[ ADC-Rule-Remove]
[X-Header-Enrichment]
*[ AVP ]
7.3.3 Re-Auth-Request (RAR)

The RAR command, indicated by the Command-Code field set to 258 and the 'R' bit set in the
Command Flags field, is sent by the PCRF to the BBERF/PCEF in order to provision
QoS/PCC rules using the PUSH procedure initiate the provision of unsolicited QoS/PCC
rules. It is used to provision QoS/PCC rules, event triggers and event report indications for the
session.
Message syntax:
<RA-Request>::=< Diameter Header: 258, REQ, PXY >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Host }
{ Re-Auth-Request-Type }
[ Session-Release-Cause ]
[ Origin-State-Id ]
*[ Event-Trigger ]
[Event-Report-Indication]
*[ Charging-Rule-Remove ]

Ltd
*[ Charging-Rule-Install ]
*[ QoS-Group-Rule-Remove ]
*[ QoS-Group-Rule-Install ]
[ Default-EPS-Bearer-QoS ]
*[ QoS-Information ]
[ X-HW-Usage-Report ]
[Revalidation-Time]
*[ 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]
7.3.4 Re-Auth-Answer (RAA)

The RAA command, indicated by the Command-Code field set to 258 and the 'R' bit cleared
in the Command Flags field, is sent by the PCEF to the PCRF in response to the RAR
command.
Message syntax:
<RA-Answer>::= < Diameter Header: 258, PXY >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
[ Result-Code ]
[ Experimental-Result ]
[ Origin-State-Id ]
[ Event-Trigger ]
*[ Charging-Rule-Report]
[ Access-Network-Charging-Address ]
*[ Access-Network-Charging-Identifier-Gx ]
[ Error-Message ]

Ltd
*[ Failed-AVP ]
*[ Proxy-Info ]
*[ ADC-Rule-Report ]
*[ AVP ]

Ltd
UPCC Gx Interface Specification ProceduresProcedures
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.
8.1 Capability Negotiation for 3GPP R7 Gx Application

Capability negotiation allows PCEF and PCRF to discovery its peers identify and capabilities
such as supported applications. Figure 1.4 exemplified the signaling flows for this procedure
from the point of view of UPCC.

Ltd
Figure 1.4 Capability Negotiation for 3GPP R7 Gx Application

Ltd
1. The PCEF establishes transport connection with the PCRF.

2. The PCEF sends Capability-Exchange-Request message to the PCRF. Application Id in
diameter header is set to 0, indicating the Diameter Base Protocol and a Vendor-Specific-
Application-Id AVP is included in the message body, indicating the support of 3GPP R7
Gx application.
3. The PCRF acknowledges and returns a Capability-Exchange-Answer message to the
PCEF. Application Id in diameter header is also to 0, indicating the Diameter Base
Protocol, and also a Vendor-Specific-Application-Id AVP is included in the message
body, indicating the support of 3GPP R7 Gx application.
4. After the capability exchange of both sides is succeeded, interaction between 3GPP R7
Gx application peers is enabled for PCEF and PCRF. For each Gx transaction,
Application Id in diameter header will be set to 16777238, indicating the 3GPP R7 Gx
application, and Auth-Application-Id AVP is included in the message body, also
indicating the 3GPP R7 Gx application.
8.2 IP-CAN Session Establishment

The activation of a primary PDP context causes a new IP-CAN session to be established.
Figure 4.1 exemplifies the signaling flows for this procedure.
Figure 4.1 IP-CAN Session Establishment
1. The UE attaches to GPRS network.

2. The UE sends an Activate PDP Context Request (NSAPI, TI, PDP Type, PDP Address,
Access Point Name, QoS Requested, and Protocol Configuration Options) message to
the SGSN.
3. The SGSN validates the Activate PDP Context Request and send a Create PDP Context
Request message to the selected PCEF.

Ltd
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.
8.3 UE Side Initiated IP-CAN Bearer Modification

The update of a PDP context causes the corresponding IP-CAN bearer to be modified. Figure
7.1 exemplifies the signaling flows for this procedure.
Figure 7.1 UE Side Initiated IP-CAN Bearer Modification
1. The MS sends a Modify PDP Context Request (TI, QoS Requested, TFT, and Protocol
Configuration Options) message to the SGSN.

Ltd
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.
8.4 UE Side Initiated IP-CAN Session Termination

The deactivation of PDP context causes the corresponding IP-CAN bearer to be terminated. If
the removed PDP context is the last one in IP-CAN session, IP-CAN session will be
terminated. Figure 6.1 exemplifies the signaling flows for this procedure.
Figure 6.1 UE Side Initiated IP-CAN Session Termination
1. The MS sends a Deactivate PDP Context Request message to the SGSN.

2. The SGSN validates the Deactivate PDP Context Request sends Delete PDP Context
Request message to the GGSN.
3. The GGSN locates the corresponding PDP context and IP-CAN session. If PCC is
enabled for this IP-CAN session and thats the last PDP context of the IP-CAN session,

Ltd
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.
8.5 PCRF Initiated IP-CAN Session Modification

Re-authorization pushed from PCRF causes corresponding IP-CAN session to be modified.
Figure 6.1 PCRF Initiated IP-CAN Session Modification
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-

Ltd
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.
8.6 PCRF Initiated IP-CAN Session Termination

Forced removal of authorization initiated by PCRF causes corresponding IP-CAN session to
be terminated. Figure 5.1 exemplifies the signaling flows for this procedure.
Figure 5.1 PCRF Initiated IP-CAN Session Termination
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.

Ltd
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.
8.7 Usage Report

Accumulated usage information of subscriber can be used for policy decision. To support the
usage accumulation in PCRF the PCEF shall report usage information to PCRF as required.
The principle is as follows:
5. On initial policy authorization, PCRF can indicate PCEF to report traffic usage
information for specified quota thresholds of services (or the total traffic in IP-CAN
session).
6. On reaching quota threshold, PCEF reports traffic usage information to PCRF in an
incremental way.
7. On receiving traffic usage report from PCEF, PCRF re-calculates the accumulated usage,
and updates policy accordingly. At the same time, the quota threshold for reporting may
also be updated.
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.
Figure 7.1 is an illustration of this procedure.

Ltd
Figure 7.1 Illustration of Policy Control Based On Accumulated Usage
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.

Ltd
When usage monitoring and reporting is disabled.

When a PCC revalidation timeout occurs.
When an IP-CAN session is terminated.
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 PCRF initiated IP-CAN Session Audit
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.

Ltd
Figure 3.1 PCEF Initiated IP-CAN Session Audit
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.

Ltd
UPCC Gx Interface Specification AVPs DefinitionAVPs Definition
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.
The maximum length of Session-Id is 64 bytes.

DiameterIdentity is encoded as the PCEFs host identifier, and the remainder can be any
sequence which is guaranteed to be eternally unique.
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

Ltd
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.
In this version, only the value 10415 assigned to 3GPP is supported.
9.4 Product-Name
The Product-Name AVP (AVP Code 269) is of type UTF8String, and contains the vendor
assigned name for the product.
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.
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.
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 }

Ltd
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.
The maximum length of Origin-Host is 64 Bytes.
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.
Maximum length is 64 Bytes.
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.
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.

Ltd
The Destination-Realm AVP is always absent from answer messages.

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.
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)

Ltd
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.
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.
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.
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.

Ltd
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.
In this version, Error-Message AVP is ignored.
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.
In this version, Failed-AVP AVP is ignored.
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.
Maximum length supported is 64 Bytes.
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.

Ltd
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.
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.
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.

Ltd
9.26 Service-Identifier
The Service-Identifier AVP is of type Unsigned32 (AVP Code 439) and contains the identifier
of a service.
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 }
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 }
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)

Ltd
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
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
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

Ltd
Octets 8 7 6 5 4 3 2 1
1 3GPP type = 18
2 3GPP Length= n
3 MCC digit1 (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)
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)
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.

Ltd
9.35 Access Network-Charging-Address

The Access-Network-Charging-Address AVP (AVP code 501) is of type Address, and contains
the GGSN IP address.
For details, please refer to 3GPP TS 29.214.
9.36 Access Network-Charging-Identifier-Value

The Access-Network-Charging-Identifier-Value AVP (AVP code 503) is of type OctetString,
and contains the GCID.
For details, please refer to 3GPP TS29.214.
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.

Ltd
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]
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.
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.

Ltd
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.
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 ]

Ltd
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.
Maximum length of Access-Network-Charging-Identifier-Value is 16 Bytes.
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.
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.
Maximum supported length is 16 Bytes.
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)

Ltd
This value is used to indicate that a new bearer is being established.

36. MODIFICATION (2)
This value is used to indicate that an existing bearer is being modified.
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.
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 ]

Ltd
[ Rule-Activation-Time ]
[ Rule-Deactivation-Time ]
[ Resource-Allocation-Notification ]
[ Charging-Correlation-Indicator ]
[ SN-Service-Flow-Detection]
*[ AVP ]
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 >
*[ 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.
Charging-Rule-Definition ::= < AVP Header: 1003 >
{ Charging-Rule-Name }
[ Service-Identifier ]

Ltd
[ 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 ]

Ltd
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.
The maximum length of Charging-Rule-Base-Name is 20 Bytes.
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.
The maximum length of Charging-Rule-Name is 20 Bytes.
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.
Charging-Rule-Report ::= < AVP Header: 1018 >

Ltd
*[Charging-Rule-Name]
*[Charging-Rule-Base-Name]
[PCC-Rule-Status]
[Rule-Failure-Code]
[Final-Unit-Indication]
*[AVP]
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)
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)
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)
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)
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

Ltd
PLMN. 3GPP-SGSN-MCC-MNC AVP shall be provided in the same request with the
new value.
44. LOSS_OF_BEARER (5)
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)
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)
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)
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-

Ltd
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)
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)
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)
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)

Ltd
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)
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)
a change in the TAI, PCEF shall inform the PCRF. When used in a CCR command, this
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)
a change in the ECGI, PCEF shall inform the PCRF. When used in a CCR command, this
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)

Ltd
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)
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)
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)
68. DEFAULT_EPS_BEARER_QOS_CHANGE (20)
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.

Ltd
73. ACCESS_NETWORK_INFO_REPORT (45)

completion of an IP-CAN bearer establishment, modification or termination procedure,
or upon termination of the IP-CAN session, and if the AF requests the PCRF to report
the access network information, the PCEF shall report the corresponding user location
(or PLMN identifier if the user location is not available) and/or UE Timezone to the
PCRF accordingly. When used in a CCR command, this value indicates that the PCEF
generated the request because the PCEF reports the corresponding access network
information to the PCRF as requested.
74. APPLICATION_START (39)
PCEF shall inform the PCRF when the start of the applications traffic for the
application, required for detection, has been identified, unless a request to mute such a
notification (Mute-Notification AVP) is part of the corresponding ADC-Rule-Definition
AVP.
When used in a CCR command, this value indicates that the PCEF identified the start of
the corresponding applications traffic for an applicationidentified by a TDF-
Application-Identifier AVP.The detected application(s) shall be identified by the
Application-Detection-Information AVP(s). Applicable to functionality introduced with
the ADC feature as described in clause 5.4.1.
75. APPLICATION_STOP (40)
PCEF shall inform the PCRF when the stop of the applications traffic for the
application, required for detection, has been identified, unless a request to mute such a
notification (Mute-Notification AVP) is part of the corresponding Charging-Rule-
Definition AVP.
When used in a CCR command, this value indicates that the PCEF identified the stop of
the corresponding applications traffic for an applicationidentified by a TDF-
Application-Identifier AVP . The detected application(s) shall be identified by the
Application-Detection-Information AVP(s). Applicable to functionality introduced with
the ADC feature as described in subclause 5.4.1.
For unsolicited application reporting, APPLICATION_STOP Event Trigger is always set
and does not need to be subscribed by the PCRF.
76. APN-AMBR_MODIFICATION_FAILURE (29, 3GPP 29212-970)
The PCEF shall use this value to indicate to the PCRF that APN-AMBR modifications
have failed. The PCEF shall use this value in a new CCR command that indicates the
failure of either a PUSH initiated modification or a PULL initiated modification. This
event trigger needs no subscription. Applicable to functionality introduced with the Rel8
feature as described in clause 5.4.1.
77. DEFAULT-EPS-BEARER-QOS_MODIFICATION_FAILURE (34)
The PCEF shall use this value to indicate to the PCRF that Default EPS Bearer QoS
modifications have failed. The PCEF shall use this value in a new CCR command that
indicates the failure of either a PUSH initiated modification or a PULL initiated
modification. This event trigger needs no subscription. Applicable to functionality
introduced with the Rel8 feature as described in clause 5.4.1.
78. OUT_OF_CREDIT (15)
PCEF shall inform the PCRF about the PCC rules for which credit is no longer available,
together with the applied termination action. When used in a CCR command, this value
indicates that the PCEF generated the request because the PCC rules indicated by the
corresponding Charging-Rule-Report AVP have run out of credit, and that the

Ltd
termination action indicated by the corresponding Final-Unit-Indication AVP applies

(3GPP TS 32.240 [21] and 3GPP TS 32.299 [19]).
79. REALLOCATION_OF_CREDIT (16)
PCEF shall inform the PCRF about the PCC rules for which credit has been reallocated
after the former out of credit indication. When used in a CCR command, this value
indicates that the PCEF generated the request because the PCC rules indicated by the
corresponding Charging-Rule-Report AVP have been reallocated credit after the former
out of credit indication (3GPP TS 32.240 [21] and 3GPP TS 32.299 [19]).
80. SUBNET_CHANGE (2000)
PCEF shall inform the PCRF when Subnet-Identifier is changed. The new Subnet-
Identifier value shall be provided in the CT-Extension AVP.
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.
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.

Ltd
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.
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.
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.
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.
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

Ltd
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.
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.
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.
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.

Ltd
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.
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.
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.
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

Ltd
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.
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.
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.
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.
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.

Ltd
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.
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]
[ Allocation-Retention-Priority]

Ltd
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.
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
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.
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.

Ltd
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".
- No options shall be used.
- The invert modifier "!" for addresses shall not be used.
The direction "out" refers to downlink direction.
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].
TFT-Packet-Filter-Information ::= < AVP Header: 1013 >
[ Precedence ]
[ TFT-Filter ]
[ ToS-Traffic-Class ]

Ltd
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].
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.
X-HW-Usage-Report ::= < AVPCode::= 2005, Vendor-Id::=2011>
[X-HW-Session-Usage]
*[ X-HW-Service-Usage]
Maximum X-HW-Service-Usage number of X-HW-Usage-Report is 10.
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.
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

Ltd
combination of Rating-Group and Service-Identifier. Service-Identifier is optional, and when

used, it should be aligned with the reporting level of IP-CAN session.
X-HW-Service-Usage :=< AVPCode::= 2007, Vendor-Id::=2011 >
[Rating-Group]
[Service-Identifier]
[CC-Input-Octets]
[CC-Output-Octets]
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]

Ltd
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

Ltd
enable 1 // 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)
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.

Ltd
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 ]
Maximum Usage-Monitoring-Information number of CCR/CCA/RAR message is 10.
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).
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) .
USAGE_MONITORING_REPORT_REQUIRED (0)

Ltd
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.
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.
The Monitoring-Key in Huawei UPCC is treated as Unsigned Integer.

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.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.

Ltd
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 ]

Ltd
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.

WLAN (0)
This value shall be used to indicate that the RAT is WLAN.
UTRAN (1000)
This value shall be used to indicate that the RAT is UTRAN. For further details refer to
3GPP TS 29.060 [18].
GERAN (1001)

Ltd
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]
9.92 Allocation-Retention-Priority AVP

The Allocation-Retention-Priority AVP (AVP code 1034) is of type Grouped, and it is used to
indicate the priority of allocation and retention, the pre-emption capability and pre-emption
vulnerability for the SDF if provided within the QoS-Information-AVP or for the EPS default
bearer if provided within the Default-EPS-Bearer-QoS AVP.
Allocation-Retention-Priority ::= < AVP Header: 1034 >
{Priority-Level}

Ltd
[Pre-emption-Capability]
[Pre-emption-Vulnerability]
9.93 Priority-Level AVP (All access types)

The Priority-Level AVP (AVP code 1046) is of type Unsigned 32. The AVP is used for
deciding whether a bearer establishment or modification request can be accepted or needs to
be rejected in case of resource limitations (typically used for admission control of GBR
traffic). The AVP can also be used to decide which existing bearers to pre-empt during
resource limitations. The priority level defines the relative importance of a resource request.
Values 1 to 15 are defined, with value 1 as the highest level of priority.
Values 1 to 8 should only be assigned for services that are authorized to receive prioritized
treatment within an operator domain. Values 9 to 15 may be assigned to resources that are
authorized by the home network and thus applicable when a UE is roaming.
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.
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.
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.

Ltd
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.
9.98 AN-GW-Address AVP

The AN-GW-Address AVP (AVP code 1050) is of type Address, and it contains the IPv4 and/
or IPv6 (if available) address(es) of the access node gateway (SGW for 3GPP and AGW for
non-3GPP networks).
Only one AN-GW-Address AVP can be provided in the CCR message.
9.99 Supported-Features AVP

The Supported-Features AVP is of type Grouped. If this AVP is present it may inform the
destination host about the features that the origin host supports. The Feature-List AVP
contains a list of supported features of the origin host. The Vendor-Id AVP and the Feature-
List AVP shall together identify which feature list is carried in the Supported-Features AVP.
Where a Supported-Features AVP is used to identify features that have been defined by 3GPP,
the Vendor-Id AVP shall contain the vendor ID of 3GPP. Vendors may define proprietary
features, but it is strongly recommended that the possibility is used only as the last resort.
Where the Supported-Features AVP is used to identify features that have been defined by a
vendor other than 3GPP, it shall contain the vendor ID of the specific vendor in question.
If there are multiple feature lists defined by the same vendor, the Feature-List-ID AVP shall
differentiate those lists from one another. The destination host shall use the value of the
Feature-List-ID AVP to identify the feature list.
AVP format
Supported-Features ::= < AVP header: 628 10415 >
{ Vendor-Id }
{ Feature-List-ID }

Ltd
{ Feature-List }
*[AVP]
9.100 Feature-List-ID AVP

The Feature-List-ID AVP is of type Unsigned32 and it contains the identity of a feature list.
9.101 Feature-List AVP

The Feature-List AVP is of type Unsigned32 and it contains a bit mask indicating the
supported features of an application. When the bit set, indicates the corresponding feature is
supported by the application.
Table 1.1 defines the features applicable to the Gx interfaces for the feature list with a
Feature-List-ID of 1.
Table 1.1 Features of Feature-List-ID 1 used in Gx

Feature Feature M/O Description
bit
0 Rel8 M This feature is applicable for the CCR/CCA command pair

and indicates that the origin host requires support of the
base 3GPP Rel-8 Gx functionality, excluding those features
represented by separate feature bits, to successfully
complete this command exchange.
Feature bit: The order number of the bit within the Feature-List AVP where the least
significant bit is assigned number 0.
Feature: A short name that can be used to refer to the bit and to the feature, e.g. "EPS".
M/O: Defines if the implementation of the feature is mandatory ("M") or optional ("O").
Description: A clear textual description of the feature.
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

Ltd
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.
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]
Maximum X-HW-Subscriber-Service-Definition number in CCA/RAR is 10.

Its used for HW specific scenarios which can support multiple service/APN.
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.
9.108 Flow-Information (All access types)

The Flow-Information AVP (AVP code 1058) is of type Grouped, and it is sent from the PCRF
to the PCEF and contains the information from a single IP flow packet filter.
The Flow-Information AVP shall include the Flow-Direction AVP, declaring in what
direction(s) the filter applies.

Ltd
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 ]
[ 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.
No options shall be used.
The invert modifier "!" for addresses shall not be used.

Ltd
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 ]
[ 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.

Ltd

DELETION (0)
This value is used to indicate that the resources reserved for the provided packet filter
identifiers are to be deleted and are no longer used by the UE.
ADDITION (1)
This value is used to indicate that the UE requests resources allocated for the provided
packet filters.
MODIFICATION (2)
This value is used to indicate that the reserved QoS, the filter, the precedence, or any of
the fields for the provided packet filter identifiers are being modified.
9.113 Charging-Correlation-Indicator (All access types)

The Charging-Correlation-Indicator AVP (AVP code 1073) is of type Enumerated.
If the Charging-Correlation-Indicator AVP is included within a Charging-Rule-Install AVP it
indicates that the Access-Network-Charging-Identifier-Gx AVP assigned to the dynamic PCC
rules need to be provided.
CHARGING_IDENTIFIER_REQUIRED (0)
This value shall be used to indicate that the Access-Network-Charging-Identifier-Gx AVP for
the dynamic PCC rule(s) shall be reported to the PCRF by the PCEF.
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.
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.
User-Equipment-Info ::= < AVP Header: 458 >

Ltd
{ 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.

Ltd

DISABLE_SESSION_RESTORATION (0)
This value is used to indicate GGSN doesnt need to remove old rules.
DELETE_DEFAULT_BEARER_RULES (1)
This value is used to indicate GGSN should remove old rules of default bearers.
DELETE_DEFAULT_AND_DEDICATED_BEARER_RULES (2)
This value is used to indicate GGSN should remove old rules of default bearers and
dedicated bearer.
9.121 Gx-TMO-Redirect-Server
The TMO-Redirect-Server AVP (AVP Code 111) is of type Grouped and contains the address
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>
IPv4 Address 0
The address type is in the form of "dotted-decimal" IPv4 address, as defined in [8].
IPv6 Address 1

Ltd
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>
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>
disable 0 (default) // the rule is not deactivated once enforced
enable 1 // the rule is deactivated once enforced

Ltd
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>
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?
Gx-TMO-Append-IMSI ::= < AVP Header: AVP Code 116, V-Bit set, Vendor-ID 29168>
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?
Gx-TMO-Append-IMEI ::= < AVP Header: AVP Code 117, V-Bit set, Vendor-ID 29168>
disable 0 (default) // do not append the IMEI
enable 1 // append the IMEI

Ltd
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?
Gx-TMO-Append-MSIP ::= < AVP Header: AVP Code 118, V-Bit set, Vendor-ID 29168>
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.
DPI 0

Ltd
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.
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.

Ltd
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.
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.
Maximum X-HW-Content-Filter-Category-Basename number of CCR/CCA/RAR message is 5.
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 >

Ltd
The X-HW-Content-Filter-Category-Basename AVP(AVP Code 2027) is of type UTF8String.

It defines the operator delivered content filtering service packages that can be the user opt-in
or not.
If some of the category basename(s) provisioned dose not exist in PCEF, only these name(s)
are ignored and others can be taken effect in PCEF. If all of the category basename(s) are
invalid, the content filtering category configured in PCEF will be used.
This category basename should be configured in PCEF, which includes URL
category actiontime range information.
PCEF gets corresponding URL Category-ID of all the HTTP/WAP traffic belong to this IP-
CAN session by interacting with ICAP Server, then match the Category-ID with X-HW-
Content-Filter-Category-Basename, PCEF would carry out the action.
The maximum length of X-HW-Content-Filter-Category-Basename is 31 Bytes.
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.
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.
Disable (0): No need to report Redirection to PCRF
Enable (1): Need to report Redirection to PCRF

Ltd
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.
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.
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.
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.

Ltd
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.
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.

Ltd
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
IPv4 Address 0
IPv6 Address 1
URL 2

Ltd
SIP URI 3
9.153 Redirect-Server-Address
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 ]

Ltd
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.

Ltd
9.159 Event-Report-Indication (All access types)

The Event-Report-Indication AVP (AVP code 1033) is of type Grouped. When sent from the
PCRF to the PCEF, it is used to report an event coming from the Access Network GW
(BBERF) and relevant info to the PCEF. When sent from the PCEF to the PCRF, it is used to
provide the information about the required event triggers to the PCRF. Only Event-Trigger
AVP will be supplied in this case.
The PCEF may require adding new event triggers or removing the already provided ones. In
order to do so, the PCEF shall provide the new complete list of applicable event triggers
within the Event-Trigger AVP included in the Event-Report-Indication AVP to the PCRF.
The PCEF may require removing all previously provided event triggers by providing the
Event-Trigger AVP set to the value NO_EVENT_TRIGGERS included in the Event-Report-
Indication AVP to the PCRF.
If the event triggers required by the PCEF are associated with certain parameter values, the
PCRF shall provide those values to the PCEF.
The PCEF may subscribe to different or common set of event triggers at different BBERFs by
including the Routing-IP-Address AVP in the Event-Report-Indication AVP to the PCRF.
The PCEF may provide the following Event-Trigger values to the PCRF: QOS_CHANGE,
RAI_CHANGE, RAT_CHANGE, USER_LOCATION_CHANGE,
UE_TIME_ZONE_CHANGE, USER_CSG_INFORMATION_CHANGE,
USER_CSG_HYBRID_SUBSCRIBED_INFORMATION_CHANGE, USER_CSG_
HYBRID_UNSUBSCRIBED_INFORMATION_CHANGE, TAI_CHANGE and
ECGI_CHANGE.
Event-Trigger value QOS_CHANGE shall be used to report a change in APN-Aggregate-
Max-Bitrate-DL AVP and/or APN-Aggregate-Max-Bitrate-UL AVP included within the QoS-
Information AVP.
Applicability of the Event-Triggers to the different accesses is defined in clause 9.55 Event-
Trigger.
AVP Format:
Event-Report-Indication ::= < AVP Header: 1033 >
*[ Event-Trigger ]
[ RAT-Type ]
[ QoS-Information ]
[ RAI ]
[ 3GPP-User-Location-Info ]
[ 3GPP2-BSID ]
[ 3GPP-MS-TimeZone ]
[ 3GPP-SGSN-Address ]
[ 3GPP-SGSN-IPv6-Address ]
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.

Ltd
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.
9.163 Final-Unit-Indication AVP

The Final-Unit-Indication AVP (AVP Code 430) is of type Grouped and indicates that the
Granted-Service-Unit AVP in the Credit-Control-Answer, or in the AA answer, contains the
final units for the service. After these units have expired, the Diameter credit-control client is
responsible for executing the action indicated in the Final-Unit-Action AVP (see section 5.6).
If more than one unit type is received in the Credit-Control-Answer, the unit type that first
expired SHOULD cause the credit-control client to execute the specified action.
In the first interrogation, the Final-Unit-Indication AVP with Final-Unit-Action REDIRECT
or RESTRICT_ACCESS can also be present with no Granted-Service-Unit AVP in the Credit-
Control-Answer or in the AA answer. This indicates to the Diameter credit-control client to
execute the specified action immediately. If the home service provider policy is to terminate
the service, naturally, the server SHOULD return the appropriate transient failure (see section
9.1) in order to implement the policy-defined action.
The Final-Unit-Action AVP defines the behavior of the service element when the user's
account cannot cover the cost of the service and MUST always be present if the Final-Unit-
Indication AVP is included in a command.
If the Final-Unit-Action AVP is set to TERMINATE, no other AVPs MUST be present.
If the Final-Unit-Action AVP is set to REDIRECT at least the Redirect-Server AVP MUST be
present. The Restriction-Filter-Rule AVP or the Filter-Id AVP MAY be present in the Credit-
Control-Answer message if the user is also allowed to access other services that are not
accessible through the address given in the Redirect-Server AVP.
If the Final-Unit-Action AVP is set to RESTRICT_ACCESS, either the Restriction-Filter-Rule
AVP or the Filter-Id AVP SHOULD be present. The Filter-Id AVP is defined in [NASREQ].

Ltd
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.164 Final-Unit-Action AVP

The Final-Unit-Action AVP (AVP Code 449) is of type Enumerated and indicates to the
credit-control client the action to be taken when the user's account cannot cover the service
cost.
The Final-Unit-Action can be one of the following:
TERMINATE (0)
The credit-control client MUST terminate the service session. This is the default handling,
applicable whenever the credit-control client receives an unsupported Final-Unit-Action
value, and it MUST be supported by all the Diameter credit-control client
implementations conforming to this specification.
REDIRECT (1)
The service element MUST redirect the user to the address specified in the Redirect-Server-
Address AVP. The redirect action is defined in section 5.6.2.
RESTRICT_ACCESS (2)
The access device MUST restrict the user access according to the IP packet filters defined in
the Restriction-Filter-Rule AVP or according to the IP packet filters identified by the Filter-Id
AVP. All the packets not matching the filters MUST be dropped.
9.165 Restriction-Filter-Rule AVP

The Restriction-Filter-Rule AVP (AVP Code 438) is of type IPFilterRule and provides filter
rules corresponding to services that are to remain accessible even if there are no more service
units granted. The access device has to configure the specified filter rules for the subscriber
and MUST drop all the packets not matching these filters. Zero, one, or more such AVPs
MAY be present in a Credit-Control-Answer message or in an AA answer message.

Ltd
9.166 Filter-Id AVP

The Filter-Id AVP (AVP Code 11) is of type UTF8String and contains the name of the filter
list for this user.
9.167 Redirect-Server AVP

The Redirect-Server AVP (AVP Code 434) is of type Grouped and contains the address
user is to be connected when the account cannot cover the service cost. It MUST be present
when the Final-Unit-Action AVP is set to REDIRECT.
Redirect-Server ::= < AVP Header: 434 >
{ Redirect-Address-Type }
{ Redirect-Server-Address }
9.168 Redirect-Address-Type AVP

IPv4 Address (0)
IPv6 Address (1)
URL (2)
SIP URI (3)
9.169 Redirect-Server-Address AVP


Ltd
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 >

Ltd
*[ 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.

Ltd
9.177 TDF-Information AVP

The TDF-Information AVP (AVP code 1087) is of type Grouped and may be sent from the
PCEF to the PCRF in a Gx CCR with CC-Request-Type set to INITIAL-REQUEST. This
AVP contains the information about the TDF that shall handle the application detection and
reporting for that IP-CAN Session. The PCRF shall create the TDF session with that TDF.
The TDF-Information AVP shall include either the TDF-Destination-Realm and TDF-
Destination-Host AVP, or the TDF-IP-Address AVP.
NOTE: The TDF-Information AVP may also be pre-provisioned in the PCRF. In case the
TDF-Information AVP pre-provisioned at the PCRF and not received from the PCEF, it is
being handled e.g. by configuration that PCEF routes the traffic to the same TDF. In case the
TDF-Information is pre-provisioned in the PCRF and also the value is received in CC-
Request from the PCEF, the value received in CC-Request takes precedence over pre-
provisioned value.
AVP Format:
TDF-Information::= < AVP Header: 1087 >
[ TDF-Destination-Realm ]
[ TDF-Destination-Host ]
[ TDF-IP-Address ]
In this version, TDF-Destination-Realm AVP is not supported.
9.178 TDF-Destination-Host AVP

The TDF-Destination-Host AVP (AVP code 1089) is of type DiameterIdentity and contains
the Destination-Host of the TDF.
9.179 TDF-IP-Address AVP

The TDF-IP-Address AVP (AVP Code 1091) is of type Address and contains the address of
the corresponding TDF node.
The address type may be IPv4 or IPv6.
9.180 Rule-Failure-Code AVP (All access types)

The Rule-Failure-Code AVP (AVP code 1031) is of type Enumerated. It is sent by the PCEF
to the PCRF within a Charging-Rule-Report AVP to identify the reason a PCC Rule is being
reported.
UNKNOWN_RULE_NAME (1)

Ltd
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)
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)
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)
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)
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)
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)
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)
maintained since the bearer establishment/modification failed, or the bearer was released.
UNSUCCESSFUL_QOS_VALIDATION (11)

Ltd
This value is used to:

indicate that the QoS validation has failed or,
- Indicate when Guaranteed Bandwidth > Max-Requested-Bandwidth.
INCORRECT_FLOW_INFORMATION (12)
modified at the PCEF because the provided flow information is not supported by the network
(e.g. the provided IP address(es) or IPv6 prefix(es) do not correspond to an IP version
applicable for the IP-CAN session).
PS_TO_CS_HANDOVER (13)
This value is used to indicate that the PCC rule could not be maintained because of PS to
CS handover. This value is only applicable for 3GPP-GPRS and 3GPP-EPS.
TDF_APPLICATION_IDENTIFIER_ERROR (14)
This value is used to indicate that the rule could not be successfully installed or enforced
because the TDF-Application-Identifier is invalid, unknown, or not applicable to the
application required for detection.
NO_BEARER_BOUND (15)
This value is used to indicate that there is no IP-CAN bearer which the PCEF can bind
the PCC rule(s) to.
FILTER_RESTRICTIONS (16)
This value is used to indicate that the Flow-Description AVP(s) cannot be handled by the
PCEF because one of the following restrictions was not met.
- 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.
AN_GW_FAILED (17)
This value is used to indicate that the AN-Gateway has failed and that the PCRF should
refrain from sending policy decisions to the PCEF until it is informed that the S-GW has been
recovered.
MISSING_REDIRECT_SERVER_ADDRESS (18)
enforced at the PCEF because there is no valid Redirect_Server_Address within the Redirect-
Server-Address AVP provided by the PCRF and no preconfigured redirection address for this
PCC rule at the PCEF.
CM_END_USER_SERVICE_DENIED (19)
This value is used to indicate that the charging system denied the service request due to
service restrictions (e.g. terminate rating group) or limitations related to the end-user, for
example the end-user's account could not cover the requested service.
CM_CREDIT_CONTROL_NOT_APPLICABLE (20)

Ltd
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.

Ltd

UPCC V300R006C10 GX Interface Specification

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

UPCC V300R006C10 GX Interface Specification

Uploaded by

Copyright:

Available Formats

Doc.

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue 1.42 (2014-3-27) Huawei Proprietary and Confidential i

Date Revision Change Description

Issue 1.42 (2014-3-27) Huawei Proprietary and Confidential ii

Issue 1.42 (2014-3-27) Huawei Proprietary and Confidential iii

Issue 1.42 (2014-3-27) Huawei Proprietary and Confidential iv

2012-5-26 1.19 1. Add AVP: X-HW- Redirect-Times

Issue 1.42 (2014-3-27) Huawei Proprietary and Confidential v

Issue 1.42 (2014-3-27) Huawei Proprietary and Confidential vi

Issue 1.42 (2014-3-27) Huawei Proprietary and Confidential vii

Issue 1.42 (2014-3-27) Huawei Proprietary and Confidential viii

Issue 1.42 (2014-3-27) Huawei Proprietary and Confidential ix

Issue 1.42 (2014-3-27) Huawei Proprietary and Confidential x

Issue 1.42 (2014-3-27) Huawei Proprietary and Confidential xi

Issue 1.42 (2014-3-27) Huawei Proprietary and Confidential xii

Issue 1.42 (2014-3-27) Huawei Proprietary and Confidential xiii

WCDMA Wide Code Division Multiplex Access

Issue 1.42 (2014-3-27) Huawei Proprietary and Confidential xiv

SPR Subscription Profile Repository

Issue 1.42 (2014-3-27) Huawei Proprietary and Confidential xv

Issue 1.42 (2014-3-27) Huawei Proprietary and Confidential 1

2 Introduction and scope

Issue 1.42 (2014-3-27) Huawei Proprietary and Confidential 1

Figure 1.1 Gx Reference Model

Sp Policy and Charging

CAMEL Service Data Flow Scope of Gx

Issue 1.42 (2014-3-27) Huawei Proprietary and Confidential 2

Issue 1.42 (2014-3-27) Huawei Proprietary and Confidential 1

Issue 1.42 (2014-3-27) Huawei Proprietary and Confidential 2

Information is exchanged over Gx reference point through messages specified by Diameter

Figure 1.2 Gx Interface Protocol Stack

Issue 1.42 (2014-3-27) Huawei Proprietary and Confidential 1

4.2 Diameter Base Protocol

4.4 Interface Authentication mechanism

Issue 1.42 (2014-3-27) Huawei Proprietary and Confidential 2

Issue 1.42 (2014-3-27) Huawei Proprietary and Confidential 1

6.1 Bearer Control Mode

6.2 QoS negotiation

Issue 1.42 (2014-3-27) Huawei Proprietary and Confidential 1

Issue 1.42 (2014-3-27) Huawei Proprietary and Confidential 2

7.1 Message Format

Figure 1.3 Diameter Message Format

Diameter Header AVP AVP AVP

AVP Header AVP Data

Please refer to RFC3588 for details.

7.2 Base Messages

Issue 1.42 (2014-3-27) Huawei Proprietary and Confidential 1

7.2.2 Capabilities-Exchange-Answer (CEA)

Issue 1.42 (2014-3-27) Huawei Proprietary and Confidential 2

Issue 1.42 (2014-3-27) Huawei Proprietary and Confidential 3

7.2.8 Abort-Session-Answer (ASA)

Issue 1.42 (2014-3-27) Huawei Proprietary and Confidential 4

Issue 1.42 (2014-3-27) Huawei Proprietary and Confidential 5

Issue 1.42 (2014-3-27) Huawei Proprietary and Confidential 6

7.3.2 Credit-Control-Answer (CCA)

Issue 1.42 (2014-3-27) Huawei Proprietary and Confidential 7

7.3.3 Re-Auth-Request (RAR)

Issue 1.42 (2014-3-27) Huawei Proprietary and Confidential 8

7.3.4 Re-Auth-Answer (RAA)

Issue 1.42 (2014-3-27) Huawei Proprietary and Confidential 9