HUAWEI UGW9811 V900R009C01 Gy Interface Specification PDF

HUAWEI UGW9811
V900R009C01
Gy Interface Specification
Issue 01
Date 2011-10-31
HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2011. 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 the 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 01 (2011-10-31) Huawei Proprietary and Confidential i

Copyright © Huawei Technologies Co.,
Ltd
HUAWEI UGW9811
Gy Interface Specification Contents
About This Document
Purpose
This document describes the detailed specification of Gn reference point implemented in
UGW9811.
Intended Audience
This document is intended for:
 Policy planning engineers
 Installation and commissioning engineers
 Technical support engineers
Symbol Conventions
The symbols that may be found in this document are defined as follows.
Symbol Description
Alerts you to a high risk hazard that could, if not avoided,

result in serious injury or death.
Alerts you to a medium or low risk hazard that could, if not

avoided, result in moderate or minor injury.
Alerts you to a potentially hazardous situation that could, if not

avoided, result in equipment damage, data loss, performance
deterioration, or unanticipated results.
Provides a tip that may help you solve a problem or save time.
Provides additional information to emphasize or supplement
important points in the main text.
Issue 01 (2011-10-31) Huawei Proprietary and Confidential ii

Ltd
HUAWEI UGW9811
Change History
Changes between document issues are cumulative. The latest document issue contains all the
changes made in earlier issues.
Issue 01 (2011-10-31)
Initial field trial release.
Issue 01 (2011-10-31) Huawei Proprietary and Confidential iii

Ltd
HUAWEI UGW9811
Contents
About This Document.......................................................................ii
Issue 01 (2011-10-31) Huawei Proprietary and Confidential iv

Ltd
HUAWEI UGW9811
Gy Interface Specification 3 Interface Definition
1 Protocol Definition
1.1 Protocol Architecture

The protocol architecture of the DCCA (Diameter Credit Control Application) is as follows.
Figure a.1 Protocol Architecture of DCCA
1.2 Protocol Format

1.2.1 Message Head Format
The message architecture of the Diameter protocol is shown in the following figure. These
segments are sent in the order of network byte.
Figure a.1 Message head format

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| command flags | Command-Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application-ID |
Issue 01 (2011-10-31) Huawei Proprietary and Confidential 1

Ltd
HUAWEI UGW9811
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop-by-Hop Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End-to-End Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVPs ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
 Version: This Version field MUST be set to 1 to indicate Diameter Version 1.

 Message Length: The Message Length field is three octets and indicates the length of the
Diameter message including the header fields.
 Command flags: The Command Flags field is eight bits. The following bits are assigned:
Figure a.2 Command Flag

0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|R P E T r r r r|
+-+-+-+-+-+-+-+-+
− R(equest) - If set, the message is a request. If cleared, the message is an answer.

− P(roxiable) –If set, the message MAY be deputized, relayed or redirected. If cleared,
the message MUST be locally processed.
− E(rror) - If set, the message contains a protocol error, and the message will not
conform to the ABNF described for this command. Messages with the 'E' bit set are
commonly referred to as error messages. This bit MUST NOT be set in request messa
ges.
− T(Potentially re-transmitted message)- This flag is set after a link failover procedure,
to aid the removal of duplicate requests. It is set when resending requests not yet
acknowledged, as an indication of a possible duplicate due to a link failure. This bit
MUST be cleared when sending a request for the first time, otherwise the sender
MUST set this flag. Diameter agents only need to be concerned about the number of
requests they send based on a single received request; retransmissions by other
entities need not be tracked. Diameter agents that receive a request with the T flag set,
MUST keep the T flag set in the forwarded request. This flag MUST NOT be set if an
error answer message (e.g., a protocol error) has been received for the earlier
message. It can be set only in cases where no answer has been received from the
server for a request and the request is sent again. This flag MUST NOT be set in
answer messages.
− r(eserved) - these flag bits are reserved for future use, and MUST be set to zero, and
ignored by the receiver.
 Command-Code: The Command-Code field is three octets, and is used in order to
communicate the command associated with the message. The 24-bit address space is
managed by IANA. Command-Code values 16,777,214 and 16,777,215 (hexadecimal
values FFFFFE -FFFFFF) are reserved for experimental use.
 Application-ID: Application-ID is four octets and is used to identify to which application
the message is applicable for. The application can be an authentication application, an
accounting application or a vendor specific application. See Section for the possible
values that the application-id may use.
The application-id in the header MUST be the same as what is contained in any relevant AVPs
Ltd
HUAWEI UGW9811
contained in the message.

 Hop-by-Hop Identifier: The Hop-by-Hop Identifier is an unsigned 32-bit integer field (in
network byte order) and aids in matching requests and replies. The sender MUST ensure
that the Hop-by-Hop identifier in a request is unique on a given connection at any given
time, and MAY attempt to ensure that the number is unique across reboots. The sender
of an Answer message MUST ensure that the Hop-by-Hop Identifier field contains the
same value that was found in the corresponding request. The Hop-by-Hop identifier is
normally a monotonically increasing number, whose start value was randomly generated.
An answer message that is received with an unknown Hop-by-Hop Identifier MUST be
discarded.
 End-to-End Identifier: The End-to-End Identifier is an unsigned 32-bit integer field (in
network byte order) and is used to detect duplicate messages. Upon reboot
implementations MAY set the high order 12 bits to contain the low order 12 bits of
current time, and the low order 20 bits to a random value. Senders of request messages
MUST insert a unique identifier on each message. The identifier MUST remain locally
unique for a period of at least 4 minutes, even across reboots. The originator of an
Answer message MUST ensure that the End-to-End Identifier field contains the same
value that was found in the corresponding request. The End-to-End Identifier MUST
NOT be modified by Diameter agents of any kind. The combination of the Origin-Host
and this field is used to detect duplicates. Duplicate requests SHOULD cause the same
answer to be transmitted, and MUST NOT affect any state that was set when the original
request was processed. Duplicate answer messages that are to be locally consumed
SHOULD be silently discarded.
 AVPs: AVPs are a method of encapsulating information relevant to the Diameter
message.
1.2.2 Message List

Figure a.1 Message List of DCCA
Command Name Acronym Command Code
Credit-Control-Request CCR 272
Credit-Control-Answer CCA 272
Re-Auth-Request RAR 258
Re-Auth-Answer RAA 258
Abort-Session-Request ASR 274
Abort-Session-Answer ASA 274
Device-Watchdog-Request DWR 280
Device-Watchdog-Answer DWA 280
Disconnect-Peer-Request DPR 282
Disconnect-Peer-Answer DPA 282
Capabilities-Exchange-Request CER 257
Capabilities-Exchange-Answer CEA 257

Ltd
HUAWEI UGW9811
1.2.3 AVP Head Format

The segments in the AVP should be sent in the order of network byte. The AVP head format is
shown in the following figure.
Figure a.1 AVP head format

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V M P r r r r r| AVP Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-ID (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-+-+-+-+
 AVP Code
The AVP Code, combined with the Vendor-Id field, identifies the attribute uniquely. AVP
numbers 1 through 255 are reserved for backward compatibility with RADIUS, without
setting the Vendor-Id field. AVP numbers 256 and above are used for Diameter, which are
allocated by IANA.
 AVP Flags
The AVP Flags field informs the receiver how each attribute must be handled. The 'r'
(reserved) bits are unused and SHOULD be set to 0. Note that subsequent Diameter
applications MAY define additional bits within the AVP Header, and an unrecognized bit
SHOULD be considered an error. The 'P' bit indicates the need for encryption for end-to-end
security.
The 'M' Bit, known as the Mandatory bit, indicates whether support of the AVP is required. If
an AVP with the 'M' bit set is received by a Diameter client, server, proxy, or translation agent
and either the AVP or its value is unrecognized, the message MUST be rejected. Diameter
Relay and redirect agents MUST NOT reject messages with unrecognized AVPs.
AVPs with the 'M' bit cleared are informational only and a receiver that receives a message
with such an AVP that is not supported, or whose value is not supported, MAY simply ignore
the AVP.
The 'V' bit, known as the Vendor-Specific bit, indicates whether the optional Vendor-ID field
is present in the AVP header. When set the AVP Code belongs to the specific vendor code
address space.
Unless otherwise noted, AVPs will have the following default AVP
Flags field settings:
The 'M' bit MUST be set. The 'V' bit MUST NOT be set.
 AVP Length
The AVP Length field is three octets, and indicates the number of octets in this AVP including
the AVP Code, AVP Length, AVP Flags, Vendor-ID field (if present) and the AVP data. If a
message is received with an invalid attribute length, the message SHOULD be rejected.

Ltd
HUAWEI UGW9811
1.2.4 AVP Data Formats

The Data field is zero or more octets and contains information specific to the Attribute. The
format and length of the Data field is determined by the AVP Code and AVP Length fields.
The format of the Data field MUST be one of the following base data types.
 OctetString
The data contains arbitrary data of variable length. Unless otherwise noted, the AVP Length
field MUST be set to at least 8 (12 if the 'V' bit is enabled). AVP Values of this type that are
not a multiple of four-octets in length is followed by the necessary padding so that the next
AVP (if any) will start on a 32-bit boundary.
 Integer32
32 bit signed value, in network byte order. The AVP Length field MUST be set to 12 (16 if the
'V' bit is enabled).
 Integer64
64 bit signed value, in network byte order. The AVP Length field MUST be set to 16 (20 if the
'V' bit is enabled).
 Unsigned32
32 bit unsigned value, in network byte order. The AVP Length field MUST be set to 12 (16 if
the 'V' bit is enabled).
 Unsigned64
64 bit unsigned value, in network byte order. The AVP Length field MUST be set to 16 (20 if
the 'V' bit is enabled).
 Float32
This represents floating point values of single precision as described by IEEE 754-1985. The
32-bit value is transmitted in network byte order. The AVP Length field MUST be set to 12
(16 if the 'V' bit is enabled).
 Float64
This represents floating point values of double precision as described by IEEE 754-1985. The
64-bit value is transmitted in network byte order. The AVP Length field MUST be set to 16
(20 if the 'V' bit is enabled).
 Grouped
The Data field is specified as a sequence of AVPs. Each of these AVPs follows - in the order
in which they are specified - including their headers and padding. The AVP Length field is set
to 8 (12 if the 'V' bit is enabled) plus the total length of all included AVPs, including their
headers and padding. Thus the AVP length field of an AVP of type Grouped is always a
multiple of 4.
 Address
The Address format is derived from the OctetString AVP Base Format. It is a discriminated
union, representing, for example a 32-bit (IPv4) or 128-bit (IPv6) address, most significant
octet first. The first two octets of the Address AVP represent the AddressType, which contains
an Address Family defined in IANAADFAM. The AddressType is used to discriminate the
content and format of the remaining octets.

Ltd
HUAWEI UGW9811
 Time
The Time format is derived from the OctetString AVP Base Format. The string MUST contain
four octets, in the same format as the first four bytes are in the NTP timestamp format. This
represents the number of seconds since 0h on 1 January 1900 with respect to the Coordinated
Universal Time (UTC). On 6h 28m 16s UTC, 7 February 2036 the time value will overflow.
SNTP describes a procedure to extend the time to 2104.This procedure MUST be supported
by all DIAMETER nodes.
 UTF8String
The UTF8String format is derived from the OctetString AVP Base Format. This is a human
readable string represented using the ISO/IEC IS 10646-1 character set, encoded as an
OctetString using the UTF-8 transformation format described in RFC 2279.
 DiameterIdentity
The DiameterIdentity format is derived from the OctetString AVP Base Format.
DiameterIdentity = FQDN
DiameterIdentity value is used to uniquely identify a Diameter node for purposes of duplicate
connection and routing loop detection.
The contents of the string MUST be the FQDN of the Diameter node. If multiple Diameter
nodes run on the same host, each Diameter node MUST be assigned a unique
DiameterIdentity. If a Diameter node can be identified by several FQDNs, a single FQDN
should be picked at startup, and used as the only DiameterIdentity for that node, whatever the
connection it is sent on.
 Enumerated
Enumerated is derived from the Integer32 AVP Base Format. The definition contains a list of
valid values and their interpretation and is described in the Diameter application introducing
the AVP.

Ltd
HUAWEI UGW9811
2 Interface Description
2.1 Online Charging Framework

Figure a.1 Online charging framework

Ltd
HUAWEI UGW9811
2.2 Basic principles

As described in 3GPP, there are two sub-functions for online charging that affect online
charging: rating and unit determination. Both rating and unit determination can be
implemented centralized, i.e. on the OCS, or decentralized, that is, on the GW.
 Unit determination refers to the calculation of the number of non-monetary units (service
units, data volume, time and events) that shall be assigned prior to starting service
delivery.
 Rating refers to the calculation of a price out of the non-monetary units calculated by the
unit determination function.
For Huawei GW, only centralized mode is supported, and GW focus on packet inspections
and categorise and control traffic flows according to charging rules either from local
configuration or policy server(i.e. PCRF, AAA, etc)
So basic behavior on OCS and GW is described below:
OCS determines the number of non-monetary units that a certain service user can consume
based on a rating group / service identifier received from the GW
After checking the service user's account balance, the OCS returns the number of granted
units to the GW. GW is then responsible for the supervision of service delivery. Particularly,
the GW shall limit service delivery to the corresponding number of granted units.
2.3 Charging Modes

In 3GPP, in order to perform event charging via Gy, the scenarios between the involved
entities UE-A, OCS and GW need to be defined. There are three interactive modes between
GW and OCS for online charging can be deployed for different scenarios :

Ltd
HUAWEI UGW9811
2.3.1 Immediate Event Charging

Figure a.1 Online charging IEC mode
In IEC mode, GW identify charging event first and then forwards the charging event to the
OCS;
Then OCS determines the value of the requested resource usage and debits this value from
the subscriber account immediately and response the resource usage to GW to authorise this
charging event request.
GW executes the resource usage according to the user request and the OCS authorisation.
After completion of the resource usage, if the service access failed, GW informs OCS
accordingly about the failure to refund the corresponding quota to the subscriber account
immediately
Exceptions and abnormal cases

If OCS rejects the resource request. In this case, the GW should disallows the service access..

Ltd
HUAWEI UGW9811
2.3.2 Event Charging with Reservation

Figure a.1 Online charging sECUR mode
GW OCS
1. Service Request
Reserve Units Operation
2. CCR (INITIAL_REQUEST, RSU)
3. Perfor m
Charging Control
4. CCA (INITIAL_REQUEST, GSU, [VT])
5. Service Delivery
Debit Units Operation
6. CCR (TERMINATION_REQUEST, USU)
7.. Perform Charging Control
8. CCA (TERMINATION_REQUEST, CI)

Ltd
HUAWEI UGW9811
Figure a.2 Online charging eECUR mode
In ECUR mode, GW identify charging event first and then forwards the charging event to the
OCS; Then OCS determines the value of the requested resource usage and reserves this value
from the subscriber account;
The OCS response the resource usage to GW to authorise this charging event request.
GW executes the resource usage according to the user request and the OCS authorisation.
After completion (or failure) of the resource usage, the GW informs the OCS accordingly
about the completion or failure;
In line with the result report from the GW, the OCS either debits the reserved amount from
the subscriber account (success), or it refund the unused amount back to the subscriber
account (failure).
Exceptions and abnormal cases:

If OCS rejects the resource request. In this case, the GW should disallows the service access..
For ECUR mode, 3GPP defination changes between 2005 and 2006 releases. In old
defination, ECUR mode has CC-Update interaction, which was delete in new Release in
2006.

Ltd
HUAWEI UGW9811
Huawei GW supports both kinds of ECUR mode and it could be configured locally. And
normally refered the old ECUR mode with CC-Update interaction as eECUR (enhanced-
ECUR) mode, and the new ECUR without CC-Update interaction as sECUR(standard-
ECUR).
2.3.3 Session charging with Reservation

Figure a.1 Online charging SCUR mode
In SCUR mode Session based online charging always involves reservation within the credit
control procedure (SCUR), as there is no way for the OCS to predict the amount of resource
usage that occurs during the user session.
To begin with, the GW forward generates a charging chargeable event that corresponds to the
resource usage request and maps onto the user session, and forwards it to the OCS. In the
OCS, the online charging session is started and a certain amount quota reserved from the user
subscriber account. This amount is determined by the OCS based on the information reported
with the charging event and on local configuration, i.e. operator policy.
Further charging events are sent from the GW to the OCS upon the detection of further
chargeable events within the session .e.g. the expiry of in intervals configured on the GW or
instructed by the OCS, or when the authorised quota expires, or when session characteristics

Ltd
HUAWEI UGW9811
change (e.g. change of QoS of a PDP context). The OCS then furnishes a new quota to the
GW as required, or rejects the charging event, e.g. due to exhaust of credit on the subscriber
account.
As described above about the three modes of online charging, SCUR is the basic online
charging mode mostly used for volume / time based charging, which interactive with OCS in
a single DCC session.ECUR / IEC is an additional mode to handle event based charging,
which interactive with OCS in another DCC session different with SCUR session.
For event based charging, IEC mode is recommended because of saving lots of signaling
normally ( most service access could be success and saves signaling for refund quota).

Ltd
HUAWEI UGW9811
3 Interface Definition
3.1 Message Format Definition

In the following statement, "<>" means that it is compulsory and should be in the beginning
of the message, "{}" means that it is compulsory, "[]" means that it is optional, and "*[]"
means that the option can be repeated.
 M Compulsory
 C Condition optional
 OM Compulsory option defined by the operator
 OC Condition optional option defined by the operator
3.1.1 Credit-Control-Request (CCR)

The Credit-Control-Request message (CCR) is indicated by the command-code field being set
to 272 and the 'R' bit being set in the Command Flags field. It is used between the Diameter
credit-control client and the credit-control server to request credit authorization for a given
service.
Message format:
<Credit-Control-Request> ::= < Diameter Header: 272, REQ, PXY >
<Session-Id>
{Origin-Host}
{Origin-Realm}
{Destination-Realm}
{Auth-Application-Id}
{Service-Context-Id}
{CC-Request-Type}
{CC-Request-Number}
[Requested-Action]
[Destination-Host]
[User-Name]
[Origin-State-Id]
[Event-Timestamp]
*[Subscription-Id]
[Termination-Cause]
[Multiple-Services-Indicator]
*[Multiple-Services-Credit Control]

Ltd
HUAWEI UGW9811
[User-Equipment-Info]
[Service-Information]
*[AVP]
The PS-Information AVP is shown below:

Service-Information :: = < AVP Header: 873>
[ PS-Information ]
[ 3GPP-Charging-Id ]
[ 3GPP-PDP-Type ]
*[ PDP-Address ]
[ 3GPP-GPRS-Negotiated-QoS-Profile ]
[ SGSN-Address ]
[ GGSN-Address ]
[ CG-Address ]
[ 3GPP-IMSI-MCC-MNC ]
[ 3GPP-GGSN- MCC-MNC ]
[ 3GPP-NSAPI ]
[ Called-Station-Id ]
[ 3GPP-Session-Stop-Indicator ]
[ 3GPP-Selection-Mode ]
[ 3GPP-Charging-Characteristics ]
[ 3GPP-SGSN-MCC-MNC ]
[ 3GPP-MS-TimeZone ]
[ Charging-Rule-Base-Name ]
[ 3GPP-User-Location-Info ]
[ 3GPP-RAT-Type ]
[ PS-Furnish-Charging-Information ]
[ PDP-Context-Type ]
[ PDN-Connection-ID]
[ Serving-Node-Type]
[ Start-Time ]
[ Stop-Time ]
3.1.2 Credit-Control-Answer (CCA)

The Credit-Control-Answer message (CCA) is indicated by the command-code field being set
to 272 and the 'R' bit being cleared in the Command Flags field. It is used between the credit-
control server and the Diameter credit-control client to acknowledge a Credit-Control-Request
command.
Message Format:
<Credit-Control-Answer> ::= < Diameter Header: 272, PXY >
<Session-Id>
{Result-Code}
{Origin-Host}
{Origin-Realm}
{Auth-Application-Id}
{CC-Request-Type}
{CC-Request-Number}
[CC-Session-Failover]
*[Multiple-Services-Credit-Control]

Ltd
HUAWEI UGW9811
[Credit-Control-Failure-Handling]
[Direct-Debiting-Failure-Handling]
[Service-Information]
[Validity-Time]
*[AVP]
3.1.3 Re-Auth-Request (RAR)

The Re-Auth-Request (RAR), indicated by the Command-Code set to 258 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 user be re-authenticated and/or re-authorized.
Message Format:
<Re-Auth-Request> ::= < Diameter Header: 258, REQ, PXY >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
[ Destination-Host ]
{ Auth-Application-Id }
{ Re-Auth-Request-Type }
[ User-Name ]
[ G-S-U-Pool-Identifier ]
[ Origin-State-Id ]
[ Rating-Group ]
[Service-Identifier]
*[ AVP ]
For the specific definitions, refer to RFC 3588 “Diameter Base Protocol”.
3.1.4 Re-Auth-Answer(RAA)
The Re-Auth-Answer (RAA), indicated by the Command-Code set to 258 and the message
flags' 'R' bit clear, is sent in response to the RAR. The Result-Code AVP MUST be present,
and indicates the disposition of the request.
A successful RAA message MUST be followed by an application-specific authentication
and/or authorization message.
Message Format:
<Re-Auth-Answer> ::= < Diameter Header: 258, PXY >
< Session-Id >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ User-Name ]
[ Origin-State-Id ]
*[ AVP ]

Ltd
HUAWEI UGW9811
3.1.5 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 Format:
<Abort-Session-Request> ::= < Diameter Header: 274, REQ, PXY >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Destination-Host }
{ Auth-Application-Id }
[ User-Name ]
[ Origin-State-Id ]
*[ AVP ]
3.1.6 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. The Result-Code AVP MUST be
present, and indicates the disposition of the request.
If the session identified by Session-Id in the ASR was successfully terminated, Result-Code is
set to DIAMETER_SUCCESS. If the session is not currently active, Result-Code is set to
DIAMETER_UNKNOWN_SESSION_ID. If the access device does not stop the session for
any other reason, Result-Code is set to DIAMETER_UNABLE_TO_COMPLY.
Message Format:
< Abort-Session-Answer> ::= < Diameter Header: 274, PXY >
< Session-Id >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ User-Name ]
[ Origin-State-Id ]
*[ AVP ]
3.1.7 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 when no traffic has been exchanged between two
peers (see Section 5.5.3). Upon detection of a transport failure, this message MUST NOT be
sent to an alternate peer.
Message Format:
<Device-Watchdog-Request> ::= < Diameter Header: 280, REQ >

Ltd
HUAWEI UGW9811
{ Origin-Host }
{ Origin-Realm }
[ Origin-State-Id ]
3.1.8 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 Format:
<DWA> ::= < Diameter Header: 280 >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ Original-State-Id ]
3.1.9 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. Upon detection of a transport failure, this message MUST NOT be sent to an
alternate peer.
Message Format:
<DPR> ::= < Diameter Header: 282, REQ >
{ Origin-Host }
{ Origin-Realm }
{ Disconnect-Cause }
3.1.10 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. Upon receipt of this message, the transport connection is shutdown.
Message Format:
<DPA> ::= < Diameter Header: 282 >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }

Ltd
HUAWEI UGW9811
3.1.11 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. Upon detection of a
transport failure, this message MUST NOT be sent to an alternate peer.
Message Format:
<CER> ::= < Diameter Header: 257, REQ >
{ Origin-Host }
{ Origin-Realm }
1*{ Host-IP-Address }
{ Vendor-Id }
{ Product-Name }
[ Origin-State-Id ]
*[ Auth-Application-Id ]
*[ Vendor-Specific-Application-Id ]
[ Firmware-Revision ]
[ Inband-Security-Id ]
*[ AVP ]
3.1.12 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 Format:
<CEA> ::= < Diameter Header: 257 >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
1*{ Host-IP-Address }
{ Vendor-Id }
{ Product-Name }
[ Origin-State-Id ]
*[ Supported-Vendor-Id ]
*[ Auth-Application-Id ]
[ Firmware-Revision ]
*[ AVP ]

Ltd
HUAWEI UGW9811
3.2 AVP Definition

3.2.1 APN-Aggregated-Max-Bitrate-DL
AVP name APN-Aggregated-Max-Bitrate-DL
AVP code 1040
AVP type Unsigned32
Note: 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.
3.2.2 Allocation-Retention-Priority
AVP name Allocation-Retention-Priority
AVP code 1034

AVP type Grouped
Note: 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.
AVP Format:
Allocation-Retention-Priority ::= < AVP Header: 1034 >
{Priority-Level}
[Pre-emption-Capability]
[Pre-emption-Vulnerability]
3.2.3 APN-Aggregated-Max-Bitrate-UL
AVP name APN-Aggregated-Max-Bitrate-UL
AVP code 1041
AVP type Unsigned32
Note: 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.

Ltd
HUAWEI UGW9811
3.2.4 Auth-Application-Id
AVP name Auth-Application-Id
AVP code 258

AVP type Unsigned32
Note: The only ID for re-authentication/authorization.
Diameter Common Messages 0
NASREQ 1 [NASREQ]
Mobile-IP 2 [DIAMMIP]
Diameter Base Accounting 3
Relay 0xffffffff
DCCA 4
3.2.5 Base-Time-Interval
AVP name Base-Time-Interval
AVP code 1265

AVP type Unsigned32
Note: The Base-Time-Interval AVP (AVP code 1265) is of type Unsigned32. It contains the
length of the base time interval, for controlling the consumption of time quota, in seconds.
3.2.6 Bearer-Identifier
AVP name Bearer-Identifier
AVP code 1020

AVP type OctetString
Note: The Bearer-Identifier AVP (AVP code 1020) is of type OctetString, and it
indicates the bearer to which specific information refers.
When present within a CC-Request Diameter command, subsequent AVPs within
the CC-Request refer to the specific bearer identified by this AVP.
The bearer identifier of an IP CAN bearer shall be unique within the corresponding
IP CAN session. The bearer identifier shall be selected by the PCEF.
3.2.7 CC-Request-Type
AVP name CC-Request-Type
AVP code 416

Ltd
HUAWEI UGW9811
AVP name CC-Request-Type
AVP type Enumerated

Note: The reason for sending CCR message. It is an enumeration type and should appear in
the CCR message.
The following values are defined in the CC-Request AVP:
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.
UPDATE_REQUEST 2
An Update request contains credit-control information for an existing credit-control session.
Update credit-control requests SHOULD be sent every time a credit-control re-authorization
is needed at the expiry of the allocated quota or validity time.
TERMINATION_REQUEST 3
A Termination request is sent to terminate a credit-control session and contains credit-control
information relevant to the existing session.
EVENT_REQUEST 4
An Event request is used when there is no need to maintain any credit-control session state in
the credit-control server. This request contains all information relevant to the service, and is
the only request of the service. The reason for the Event request is further detailed in the
Requested-Action AVP. The Requested-Action AVP MUST be included in the Credit-
Control-Request message when CC-Request-Type is set to EVENT_REQUEST.
3.2.8 CC-Request-Number
AVP name CC-Request-Number
AVP code 415

AVP type Unsigned32
Note: 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.
Set the value to 0 for a credit-control request of type INITIAL_REQUEST and
EVENT_REQUEST and to set the value to 1 for the first UPDATE_REQUEST, to 2 for the
second, and so on until the value for TERMINATION_REQUEST is one more than for the
last UPDATE_REQUEST.
3.2.9 CC-Time
AVP name CC-Time
AVP code 420

AVP type Unsigned32

Ltd
HUAWEI UGW9811
AVP name CC-Time
Note: This AVP defines the requested, allocated or used time in the unit of second.
3.2.10 CC-Total-Octets
AVP name CC-Total-Octets
AVP code 421

AVP type Unsigned64
Note: Total requested, allocated or used bytes. This value is not related to the direction
(sending or receiving).
3.2.11 CC-Input-Octets
AVP name CC-Input-Octets
AVP code 412

AVP type Unsigned64
Note: Requested, allocated or used uplink bytes (sent by the user).
3.2.12 CC-Output-Octets
AVP name CC-Output-Octets
AVP code 414

AVP type Unsigned64
Note: Requested, allocated or used downlink bytes (received by the user).
3.2.13 CC-Service-Specific-Units
AVP name CC-Service-Specific-Units
AVP code 417

AVP type Unsigned64

Ltd
HUAWEI UGW9811
AVP name CC-Service-Specific-Units
Note: Requested, allocated or used units (events identified and counted by the GW).
3.2.14 CC-Unit-Type
AVP name CC-Unit-Type
AVP code 454

AVP type Enumerated
The CC-Unit-Type AVP (AVP Code 454) is of type Enumerated and specifies the type of
units considered to be pooled into a credit pool.
The following values are supported for the CC-Unit-Type AVP:
TIME 0
TOTAL-OCTETS 2
3.2.15 Credit-Control-Failure-Handling
AVP name Credit-Control-Failure-Handling
AVP code 427

AVP type Enumerated

Ltd
HUAWEI UGW9811
AVP name Credit-Control-Failure-Handling
Note: when the CC message sent from the client to the server fails temporarily because of
network failure, CC client uses the information in this AVP to decide how to do. When CC
server cannot charge in the service because of different service logic, it can command the
client to end the service immediately or switch to the standby server.
The following values are defined by this AVP:
TERMINATE 0
When the Credit-Control-Failure-Handling AVP is set to TERMINATE, the service MUST
only be granted for as long as there is a connection to the credit-control server. If the credit-
control client does not receive any Credit-Control-Answer message within the Tx timer, the
credit-control request is regarded as failed, and the end user's service session is terminated.
This is the default behavior if the AVP isn't included in the reply from the authorization or
credit-control server.
CONTINUE 1
When the Credit-Control-Failure-Handling AVP is set to CONTINUE, the credit-control
client SHOULD re-send the request to an alternative server in the case of transport or
temporary failures, provided that a failover procedure is supported in the credit-control
server and the credit-control client, and that an alternative server is available. Otherwise, the
service SHOULD be granted, even if credit-control messages can't be delivered.
RETRY_AND_TERMINATE 2
When the Credit-Control-Failure-Handling AVP is set to RETRY_AND_TERMINATE, the
credit-control client SHOULD re-send the request to an alternative server in the case of
transport or temporary failures, provided that a failover procedure is supported in the credit-
control server and the credit-control client, and that an alternative server is available.
Otherwise, the service SHOULD not be granted when the credit-control messages can't be
delivered.
3.2.16 CG-Address
AVP name CG-Address
AVP code 846

AVP type IPAddress
Note; Charging Gateway IP address.
3.2.17 CC-Session-Failover
AVP name CC-Session-Failover
AVP code 418

AVP type Enumerated

Ltd
HUAWEI UGW9811
AVP name CC-Session-Failover
Note: It indicates whether the AVP can transfer the CC message stream to the standby server
in a CC session process. If the CC server supports failover system, the CC message stream
can be transferred to the standby CC server in case of communication failure. If the name of
the secondary CC server can be got from home Diameter AAA server, this name can be the
address of the standby server. Failover is not necessary in application because it requires that
CC session message must be kept on the standby server.
The following values are defined in CC-Session-Failover AVP:
FAILOVER_NOT_SUPPORTED 0
When the CC-Session-Failover is configured as FAILOVER_NOT_SUPPORTED, CC
message stream cannot be transferred to the standby destination in case of communication
failure. When the authorized answer of the CC server does no include CC-Session-Failover
AVP, by default the CC server does not support failover.
FAILOVER_SUPPORTED 1
When the CC-Session-Failover is configured as FAILOVER_SUPPORTED, CC message
stream is transferred to the standby destination in case of communication failure. Meanwhile
message related to CC session needs to be transferred from the failure server to the standby
server.
3.2.18 Called-Station-Id
AVP name Called-Station-Id
AVP code 30
AVP type UTF8String
Note: Includes the APN name that the user is connected to. In the GGSN, it can identify both
the external network and the service type.
3.2.19 Charging-Rule-Base-Name
AVP name Charging-Rule-Base-Name
AVP code 1004

AVP type UTF8String
Note: 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.
3.2.20 Destination-Host
AVP name Destination-Host
AVP code 293

Ltd
HUAWEI UGW9811
AVP name Destination-Host
AVP type DiameterIdentity

Note: Device ID on the destination end. The global network allocates it centrally. Different
Diameter peers should be unique.
It should appear in the request message but cannot appear in the response message.
Example: ocs001.huawei.com.
3.2.21 Direct-Debiting-Failure-Handling
AVP name Direct-Debiting-Failure-Handling
AVP code 428

AVP type Enumerated
Note: This AVP will only be used in IEC mode. The credit-control client uses information in
this AVP to decide what to do if sending credit-control messages (Requested-Action AVP set
to DIRECT_DEBITING) to the credit-control server has been, for instance, temporarily
prevented due to a network problem.
TERMINATE_OR_BUFFER 0
When the Direct-Debiting-Failure-Handling AVP is set to TERMINATE_OR_BUFFER,
the service MUST be granted for as long as there is a connection to the credit-control server.
If the credit-control client does not receive any Credit-Control-Answer message within the
Tx timer, the credit-control request is regarded as failed. The client SHOULD terminate the
service if it can determine from the failed answer that units have not been debited.
This is the default behavior if the AVP isn't included in the reply from the authorization
server.
CONTINUE 1
When the Direct-Debiting-Failure-Handling AVP is set to CONTINUE, the service
SHOULD be granted, even if credit-control messages can't be delivered, and the request
should be deleted.
3.2.22 Destination-Realm
AVP name Destination-Realm
AVP code 283


Ltd
HUAWEI UGW9811
AVP name Destination-Realm
Note: Home field of the device on the destination end. This attribute cannot appear in the
response message.
Example: huawei.com.
3.2.23 Event-Timestamp
AVP name Event-Timestamp
AVP code 55
AVP type Time
Note: Time stamp. Count in second from 1900 00:00 UTC January 1st.
3.2.24 Event-Charging-TimeStamp
AVP name Event-Charging-TimeStamp
AVP code 1258

AVP type Time
Note: The Event-Charging-TimeStamps AVP (AVP code 1258) is of type Time, and it holds the
timestamp of the event reported in the CC-Service-Specific-Units AVP when event based
charging applies.
3.2.25 Envelope
AVP name Envelope
AVP code 1266

AVP type Grouped

Ltd
HUAWEI UGW9811
AVP name Envelope
Note: This AVP reports the start and end time of one time envelope using the Envelope-Start-
Time and Envelope-End-Time AVPs.
Envelope ::= < AVP Header: 1266>
{ Envelope-Start-Time }
[ Envelope-End-Time ]
[ CC-Total-Octets ]
[ CC-Input-Octets ]
[ CC-Output-Octets ]
[ CC-Service-Specific-Units ]
*[ AVP ]
3.2.26 Envelope-Start-Time
AVP name Envelope-Start-Time
AVP code 1269

AVP type Time
Note: This AVP is set to the time of the packet of user data which caused the time envelope
to start.
3.2.27 Envelope-End-Time
AVP name Envelope-End-Time
AVP code 1267

AVP type Time
Note: This AVP is set to the time of the end of the time envelope.
3.2.28 Envelope-Reporting
AVP name Envelope-Reporting
AVP code 1268

AVP type Enumerated

Ltd
HUAWEI UGW9811
AVP name Envelope-Reporting
Note: This AVP is used in the CCA (INITIAL) to indicate whether the client shall report the
start and end of each time envelope, in those cases in which quota is consumed in envelopes.
It can take the values:
DO_NOT_REPORT_ENVELOPES (0)
REPORT_ENVELOPES (1)
REPORT_ENVELOPES_WITH_VOLUME (2)
REPORT_ENVELOPES_WITH_EVENTS (3)
REPORT_ENVELOPES_WITH_VOLUME_AND_EVENTS (4)
If this AVP is not included in the CCA (INITIAL) then the client shall not report the
individual envelopes.
3.2.29 Exponent
AVP name Exponent
AVP code 429

AVP type Integer32
Note: Exponent AVP is of type Integer32 (AVP Code 429) and contains the exponent value
to be applied for the Value-Digit AVP within the Unit-Value AVP.
The Exponent AVP should always be zero, or should be absent within the Unit-Value AVP.
3.2.30 Filter-Id
AVP name Filter-Id
AVP code 11
AVP type UTF8String
Note: The Filter-Id AVP (AVP Code 11) is of type UTF8String and contains the name of the
filter list for this user.
3.2.31 Final-Unit-Indication
AVP name Final-Unit-Indication
AVP code 430

AVP type Grouped

Ltd
HUAWEI UGW9811
AVP name Final-Unit-Indication
Note: It indicated in the CCA message or AA answers the number of the final units included
in Granted-Service-Unit. When these units are used up, the DCC client executes the actions
designated in Final-Unit-Action.
If multiple service types are received in CCA, the service unit type that is first used up
causes the DCC client to execute the designated actions.
At the first interworking, if Final-Unit-Action is REDIRECT or RESTRICT_ACCESS, CCA
or AA answer may not include Granted-Service-Unit, and this indicates that DCC client
executes the designated actions immediately. If the home service provider's policy provision
is to end the service, the server should return proper temporary failure to activate the action
designated by the policy.
Final-Unit-Action defines the action executed by service processing node when the user
account balance is not enough to pay for the service charge. If Final-Unit-Indication exists,
Final-Unit-Action must also exist.
If Final-Unit-Action is configured as TERMINATE, other AVPs in the Final-Unit-Indication
AVP group must not appear.
If Final-Unit-Action is configured as REDIRECT, Redirect-Server must appear. If users are
allowed to access to other services that cannot be got through Redirect-Server designating
address, Restriction-Filter-Rule or Filter-Id can be portable in the CCA message.
If Final-Unit-Action is configured as RESTRICT_ACCESS, the default behavior configured
in GGSN will take effect.
Filter-Id AVP can be used to refer to the IP filter list established on access device by other
non-DCC application, for example, home configuration and other entity configuration.
Final-Unit-Indication AVP is an AVP group. The ABNF grammars are as follows:
Final-Unit-Indication ::= < AVP Header: 430 >
{ Final-Unit-Action }
*[ Restriction-Filter-Rule ]
*[ Filter-Id ][ Redirect-Server ]
3.2.32 Final-Unit-Action
AVP name Final-Unit-Action
AVP code 449

AVP type Enumerated

Ltd
HUAWEI UGW9811
AVP name Final-Unit-Action
Note: It indicates the action when the user account balance is not enough to pay for the
service charge.
Final-Unit-Action defines following values:
TERMINATE 0
DCC client must end service session. This is the default processing when DCC user terminal
receives a Final-Unit-Action that is not supported.
REDIRECT 1
The service processing unit must redirect the user to the address that is designated in
Redirect-Server-Address.
RESTRICT_ACCESS 2
The default behavior configured in GGSN will take effect.
3.2.33 G-S-U-Pool-Reference
AVP name G-S-U-Pool-Reference
AVP code 457

AVP type Grouped
NOTE: The G-S-U-Pool-Reference AVP (AVP Code 457) is of type Grouped. It is used in
the Credit-Control-Answer message, and associates the Granted-Service-Unit AVP within the
Multiple-Services-Credit-Control AVP within which it appears with a credit pool within the
session.
The G-S-U-Pool-Identifier AVP specifies the credit pool from which credit is drawn for this
unit type. It should be an unsigned integer within the range from 0 to 2^32-2.
The CC-Unit-Type AVP specifies the type of units for which credit is pooled. It can only be
TOTAL-OCTETS or TIME.
The Unit-Value AVP specifies the multiplier, which converts between service units of type
CC-Unit-Type and abstract service units within the credit pool (and thus to service units of
any other service or rating group associated with the same pool). The Unit-Value AVP should
be within the range from 1 to 2^32-1.
Only quotas of the same unit type can be linked to one credit pool, for example the volume
quotas could be pooled in one pool, while the time quota should be allocated to a different
pool. If time quotas are pooled in one credit pool, the quota consumption mechanism of the
services should be the same,
The G-S-U-Pool-Reference AVP is defined as follows:

G-S-U-Pool-Reference::= < AVP Header: 457 >
{ G-S-U-Pool-Identifier }
{ CC-Unit-Type }
{ Unit-Value }

Ltd
HUAWEI UGW9811
3.2.34 G-S-U-Pool-Identifier
AVP name G-S-U-Pool-Identifier
AVP code 453

AVP type Unsigned32
Note: The G-S-U-Pool-Identifier AVP is of type Unsigned32 and identifies a credit pool
within the session, The G-S-U-Pool-Identifier AVP should be an unsigned integer within the
range from 0 to 2^32-2. The G-S-U-Pool-Identifier AVP set to 2^32-1 would be treated as an
invalid AVP.
3.2.35 GGSN-Address
AVP name GGSN-Address
AVP code 847

AVP type IPAddress
Note: GGSN IP address.
3.2.36 Granted-Service-Unit
AVP name Granted-Service-Unit
AVP code 431

AVP type Grouped
Granted-Service-Unit includes the number of the units that allow DCC client to provide
service to terminal users. When these units are used up, the DDC client must apply for new
quota from the DCC server or stop providing service to the terminal users. The DCC client
needs not distinguish all unit types. In the CCA answers when the client receives a unit type
that cannot be distinguished or supported, the CCA is regarded as error, and DCC client must
abort the session by sending a CCR message in which the Termination-Cause is
DIAMETER_BAD_ANSWER.
Granted-Service-Unit AVP is an AVP group. The ABNF grammars are as follows:
Granted-Service-Unit ::= < AVP Header: 431 >
[ Tariff-Time-Change ]
[ CC-Time ]
[ CC-Total-Octets ]
[ CC-Input-Octets ]
*[ AVP ]

Ltd
HUAWEI UGW9811
3.2.37 Guaranteed –Bitrate-DL

AVP name Guaranteed –Bitrate-DL
AVP code 1025

AVP type Unsigned32
Note: 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.
3.2.38 Guaranteed –Bitrate-UL

AVP name Guaranteed –Bitrate-UL
AVP code 1026
AVP type Unsigned32
Note: 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.
3.2.39 Max-Requested-Bandwidth-UL
AVP name Max-Requested-Bandwidth-UL
AVP code 516

AVP type Unsigned32
Note: 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.
3.2.40 Max-Requested-Bandwidth-DL
AVP name Max-Requested-Bandwidth-DL
AVP code 515
AVP type Unsigned32

Ltd
HUAWEI UGW9811
AVP name Max-Requested-Bandwidth-DL
Note: 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.
3.2.41 Multiple-Services-Indicator
AVP name Multiple-Services-Indicator
AVP code 455

AVP type Enumerated
Note: Multiple services Indicator. It is used to indicate whether the DCC client has the
capability to deal with multiple services independently in a (sub) session. Omitting this AVP
means not supporting multiple services.
If the DCC server does not support independent multiple service credit control, then this
AVP should be regarded as invalid.
For the same session, the client only needs to use this AVP in the first query.
The following values are defined in the Multiple-Services-Indicator AVP:
MULTIPLE_SERVICES_NOT_SUPPORTED 0
The client does not support independent multiple service credit control in one (sub) session.
MULTIPLE_SERVICES_SUPPORTED 1
The client supports independent multiple service credit control in one (sub) session.
3.2.42 Multiple-Services-Credit-Control
AVP name Multiple-Services-Credit-Control
AVP code 456

AVP type Grouped
Note: It contains the related AVP of multiple service independent credit control. Each
instance contains one or more services, or a unit related with Rating-Group.
The Service-Identifier and the Rating-Group AVP are used to associate the granted units to a
given service or rating group. If only the Rating-Group AVP is present, the Multiple-
Services-Credit-Control AVP relates to all the services that belong to the specified rating
group. Note: Rating Group is mandatory for Multiple-Services-Credit-Control.
The Requested-Service-Unit AVP MAY contain the amount of requested service units or the
requested monetary value. It MUST be present in the initial interrogation and within the
intermediate interrogations in which new quota is requested. If the credit-control client does
not include the Requested-Service-Unit AVP in a request command, because for instance, it
has determined that the end-user terminated the service, the server MUST debit the used
amount from the user’s account but MUST NOT return a new quota in the corresponding
answer. The Validity-Time, Result-Code, and Final-Unit-Indication AVPs MAY be present in

Ltd
HUAWEI UGW9811
AVP name Multiple-Services-Credit-Control
an answer command for the graceful service termination.

When both the Tariff-Time-Change and Tariff-Change-Usage AVPs are present, the server
MUST include two separate instances of the Multiple-Services-Credit-Control AVP with the
Granted-Service-Unit AVP associated to the same rating-group. Where the two quotas are
associated to the same pool or to different pools. The Tariff-Change-Usage AVP MUST NOT
be included in request commands to report used units before, and after tariff time change the
Used-Service-Unit AVP MUST be used.
A server not implementing the independent credit-control of multiple services functionality
MUST treat the Multiple-Services-Credit-Control AVP as an invalid AVP.
The G-S-U-Pool-Reference AVP allows the server to specify a G-S-U-Pool-Identifier
identifying a credit pool within which the units of the specified type are considered pooled.
If a G-S-U-Pool-Reference AVP is present, then actual service units of the specified type
MUST also be present. For example, if the G-S-U-Pool-Reference AVP specifies Unit-Type
TIME, then the CC-Time AVP MUST be present.
Multiple-Services-Control AVP is an AVP group. The specific ABNF grammars are as
follows.
Multiple-Services-Credit-Control ::= < AVP Header: 456>
[Granted-Service-Unit]
[Requested-Service-Unit]
*[Used-Service-Unit]
{Rating-Group}
[Service-Identifier]
* [ G-S-U-Pool-Reference ]
[Validity-Time]
[Result-Code]
[Final-Unit-Indication]
[Time-Quota-Threshold ]
[Volume-Quota-Threshold ]
[Unit-Quota-Threshold ]
[ Quota-Holding-Time ]
[ Quota-Consumption-Time ]
*[ Reporting-Reason ]
[Trigger]
[ PS-Furnish-Charging-Information ]
*[ Envelope ]
[Tariff-Time-Change]
[ Envelope-Reporting ]
[ Time-Quota-Mechanism ]

Ltd
HUAWEI UGW9811
3.2.43 Origin-Host
AVP name Origin-Host
AVP code 264

Note: Device ID of the start end. The global network allocates it centrally. Different
Diameter peers should be unique.
Example: SCP001.huawei.com.
3.2.44 Origin-Realm
AVP name Origin-Realm
AVP code 296

Note: Home filed of the device on the start end.
Example: huawei.com.
3.2.45 Origin-State-Id
AVP name Origin-State-Id
AVP code 278

AVP type Unsigned32
Note: The original ID sent by the Diameter client to the server. It is a monotonically
increasing integer. The client can set the restart time as the Origin-State-Id value to make
sure that this value is increasing after the restart.
When the Diameter server receives the Origin-State-Id from the same Diameter client, the
Diameter server should terminate all the sessions whose Origin-State-Ids are less than this
value from the client.
3.2.46 PDN-Connection-Id
AVP name PDN-Connection-Id
AVP code 2050

AVP type Unsigned32

Ltd
HUAWEI UGW9811
AVP name PDN-Connection-Id
Note: The PDN-Connection-Id contains the charging identifier to identify different records
belonging to same PDN connection. This field includes Charging Id of first IP-CAN bearer
activated within the PDN connection. Together with P-GW address this uniquely identifies
the PDN connection.
3.2.47 PDP-Address
AVP name PDP-Address
AVP code 1227

AVP type IPAddress
Note: PDP context address. It corresponds to the network layer address of the PDP context of
an MS. It may be Ipv4 or Ipv6. For different PDP types, the PDP-Address is allocated with
temporary or permanent value (for dynamic or static addresses respectively).
3.2.48 PDP-Context-Type
AVP name PDP-Context-Type
AVP code 1247

AVP type Enumerated
Note: The PDP-Context-Type indicates the type of a PDP context.
The values for requested are:
0 PRIMARY
1 SECONDARY
This AVP shall only be present in the CCR Initial.
3.2.49 Pre-emption-Capability
AVP name Pre-emption-Capability
AVP code 1047

AVP type Enumerated

Ltd
HUAWEI UGW9811
AVP name Pre-emption-Capability
Note: The Pre-emption-Capability AVP (AVP code 1047) is of type Enumerated. The
AVP defines whether a service data flow can get resources that were already
assigned to another service data flow with a lower priority level.
The following values are defined:
PRE-EMPTION_CAPABILITY_ENABLED (0)
This value indicates that the service data flow is allowed to get resources that were
already assigned to another service data flow with a lower prioriy 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 prioriy level. This is
the default value applicable if this AVP is not supplied.
3.2.50 Pre-emption-Vulnerability
AVP name Pre-emption-Vulnerability
AVP code 1048

AVP type Enumerated
Note: The Pre-emption Vulnerability AVP (AVP code 1048) is of type Enumberated.
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.
3.2.51 Priority-Level
AVP name Priority-Level
AVP code 1046
AVP type Unsigned32

Ltd
HUAWEI UGW9811
AVP name Priority-Level
Note: 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.
3.2.52 PS-Information
AVP name PS-Information
AVP code 874

AVP type Grouped

Ltd
HUAWEI UGW9811
AVP name PS-Information
Note: PS Domain service information group.

PS-Information AVP is an AVP group. The specific ABNF grammars are as follows:
PS-Information :: = < AVP Header: 20200>
[3GPP-Charging-Id]
[ PDN-Connection-ID ]
[3GPP-PDP-Type]
*[PDP-Address]
[QoS-Information]
[SGSN-Address]
[GGSN-Address]
[CG-Address]
[ Serving-Node-Type ]
[3GPP-IMSI-MCC-MNC]
[3GPP-GGSN- MCC-MNC]
[3GPP-NSAPI]
[Called-Station-Id]
[3GPP-Session-Stop-Indicator]
[3GPP-Selection-Mode]
[3GPP-Charging-Characteristics]
[3GPP-SGSN-MCC-MNC]
[3GPP-MS-TimeZone]
[Charging-Rule-Base-Name]
[3GPP-User-Location-Info]
[3GPP-RAT-Type]
[PS-Furnish-Charging-Information]
[PDP-Context-Type]
[ PDN-Connection-ID]
[ Serving-Node-Type]
[ Start-Time ]
[ Stop-Time ]
3.2.53 PS-Furnish-Charging-Information
AVP name PS-Furnish-Charging-Information
AVP code 865

AVP type Grouped

Ltd
HUAWEI UGW9811
AVP name PS-Furnish-Charging-Information
Note: This AVP purpose is to add online charging session specific information, received via
the Ro reference point, onto the Rf reference point in order to facilitate its inclusion in
CDRs. This information element may be received in a CCA message via the Ro reference
point. In situations where online and offline charging are active in parallel, the information
element is transparently copied into an ACR to be sent on the Rf reference point.
It has the following ABNF grammar:
PS-Furnish-Charging-Information :: = < AVP Header: 865>
{ 3GPP-Charging-Id }
{ PS-Free-Format-Data }
[ PS-Append-Free-Format-Data ]
Note: In Huawei UGW9811 the total length of PS-Free-Format-Data must be less than 63
bytes.
3.2.54 QoS-Class-Identifier
AVP name QoS-Class-Identifier
AVP code 1028

AVP type Enumerated

Ltd
HUAWEI UGW9811
AVP name QoS-Class-Identifier

Note: 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 and ARP for the IP-CAN bearer or service flow. The
following values are defined:
QCI_1 (1)
This value shall be used to indicate standardized characteristics associated with

standardized QCI value 1 from 3GPP TS 23.203 [7].
QCI_2 (2)

QCI_3 (3)

QCI_4 (4)

QCI_5 (5)

QCI_6 (6)

QCI_7 (7)

QCI_8 (8)

QCI_9 (9)

The QCI values 0, 10 – 255 are divided for usage as follows:

0: Reserved
10-127: Reserved
128-254: Operator specific
255: Reserved

Ltd
HUAWEI UGW9811
3.2.55 QoS-Information
AVP name QoS-Information
AVP code 1016

AVP type Grouped
Note: The QoS-Information AVP (AVP code 1016) is of type Grouped, and it defines the
QoS information for resources requested by the UE, an IP-CAN bearer, PCC rule, QCI or
APN. When this AVP is sent from the PCEF to the PCRF, it indicates the requested QoS
information associated with resources requested by the UE, an IP CAN bearer or the
subscribed QoS information at APN level. 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) or
- an APN (when appearing at CCA or RAR command level with APN-Aggregate-Max-
Bitrate-DL and APN-Aggregate-Max-Bitrate-DL).
The QoS class identifier identifies a set of IP-CAN specific QoS parameters that define QoS,
excluding the applicable bitrates and ARP. It is applicable both for uplink and downlink
direction.
The Max-Requested-Bandwidth-UL defines the maximum bit rate allowed for the uplink
direction.
The Max-Requested-Bandwidth-DL defines the maximum bit rate allowed for the downlink
direction.
The Guaranteed-Bitrate-UL defines the guaranteed bit rate allowed for the uplink direction.
The Guaranteed-Bitrate-DL defines the guaranteed bit rate allowed for the downlink
direction.
The APN-Aggregate-Max-Bitrate-UL defines the total bandwidth usage for the uplink
direction of non-GBR QCIs at the APN. This AVP applies to all access types except 3GPP-
GPRS access.
The APN-Aggregate-Max-Bitrate-DL defines the total bandwidth usage for the downlink
direction of non-GBR QCIs at the APN. This AVP applies to all access types except 3GPP-
GPRS access.
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.
When the QoS-Information AVP is provided within the CCR command along with the
RESOURCE_MODIFICATION_REQUEST event trigger, the QoS-information AVP
includes only the QoS-Class-Identifier AVP and Guaranteed-Bitrate-UL and/or Guaranteed-
Bitrate-DL AVPs.
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

Ltd
HUAWEI UGW9811
AVP name QoS-Information
message or AVP, the previous information remains valid. If the QoS-Information AVP has
not been supplied from the PCRF to the PCEF previously and is omitted in a Diameter
message or AVP, no enforcement of the authorized QoS shall be performed.
AVP Format:
QoS-Information ::= < AVP Header: 1016 >
[ QoS-Class-Identifier ]
[ Max-Requested-Bandwidth-UL ]
[ Max-Requested-Bandwidth-DL ]
[ Guaranteed-Bitrate-UL ]
[ Guaranteed-Bitrate-DL ]
[ Bearer-Identifier ]
[ Allocation-Retention-Priority]
[ APN-Aggregate-Max-Bitrate-UL]
[ APN-Aggregate-Max-Bitrate-DL]
* [AVP]
3.2.56 Quota-Holding-Time
AVP name Quota-Holding-Time
AVP code 871

AVP type Unsigned32
Note: Quota occupancy time. The unit is second. The client should start the quota holding
timer when quota consumption ends. When data communication ends timing, for example,
communication equipment renews timing after each data packet is sent, no quota-related
volume occurs in the time period that is defined in AVP, CC client should regard this quota
as expired.
This optional AVP is only used in the CCA command and is included in Multiple-Service-
Credit-Control AVP group. This AVP is also used in distributing time quota and volume
quota.
If the value of Quota-Holding-Time is 0, the quota holding timer system is not used. If
Quota-Holding-Time AVP does not appear, the client uses the default value of the local
configuration.
3.2.57 Quota-Consumption-Time
AVP name Quota-Consumption-Time
AVP code 881

AVP type Unsigned32

Ltd
HUAWEI UGW9811
AVP name Quota-Consumption-Time
Note: Quota consumption time. The unit is second. For some data application base on time
charging, its traffic may not be continuous. When the traffic interruption is caused by the
factors that are not related to users, for example, the server is busy and cannot reply
temporarily, users may complain the charging for this no traffic time. To provide better
customer experience, the carrier can use charging method based on time period for
discontinuous traffic. When the data packet in the user access line stops transfer for some
time, client does not calculate this time period into service time. It is indicated by Quota
consumption time.
As an optional function, the Diameter server can command the client to stop calculating user
quota consumption when data packet stops transfer for some time or after the session ends.
This is realized through Quota-Consumption-Time AVP carried in CCA message. The idle
time after the data packet stops transfer and before Quota-Consumption-Time arrives must
be calculated into user quota consumption. The calculation of user quota consumption
resumes once data packet resumes to transfer.
If data on the user access line is still allowed to transfer during CCR/CCA message exchange
process, and Quota-Consumption-Time carried by the new quota got from the exchange is
the same with that of the original quota, the CCR/CCA exchange time is also possibly
calculated in the waiting time of quota consumption time. For example, if the data packet
transfer on the user access line has stopped for five seconds (suppose QCT is ten seconds),
and CCA is got two seconds late, then QCT timer will expire three seconds later (if no data
packet is transferred after receiving CCA). And the later five second of the QCT will be
calculated in to user's new quota consumption, even if no actual data packet is transferred
during this period that is after new quota is received.
If Quota-Consumption-Time carried by the new quota is different from that of the original
quota, or data on the user line is not allowed to transfer during CCR/CCA information
exchange process, the QCT timer will be stopped. The new quota consumption is calculated
when next data stream that meets the charging rules starts.
If the value of Quota-Consumption-Time AVP is 0, or Quota-Consumption-Time AVP is not
carried in CCA, the quota consumption starts continuous calculation from the moment quota
is got.
3.2.58 Rating-Group
AVP name Rating-Group
AVP code 432

AVP type Unsigned32
Note: Rating group ID. All the services of the same Rating type is in the same Rating group.
The requested Rating group can be identified uniquely through the combination of Service-
Context-Id and Rating-Group AVP.
Rating-Group can correspond to one or more Service-Identifers, which means it contains
multiple rate packets of multiple services. Usually, it is used for the charging request based
on session in the PS domain.

Ltd
HUAWEI UGW9811
3.2.59 Refund-Information
AVP name Refund-Information
AVP code 2022

Note: The Refund-Inforamtion AVP is of type OctetString and it conveys relevant
information for the OCS application relative to refund mechanism. When refund mechanism
is implemented in the OCS this AVP may be included in the CCA of the previous IEC. This
AVP must be used by the CTF in case of a refund scenario and thus must be included in the
CCR for refund if previously received in CCA for IEC.
3.2.60 Requested-Action
AVP name Requested-Action
AVP code 436
AVP type Enumerated
Note: The Requested-Action AVP (AVP Code 436) is of type Enumerated and
contains the requested action being sent by Credit-Control-Request
command where the CC-Request-Type is set to EVENT_REQUEST. The
following values are defined for the Requested-Action AVP:
DIRECT_DEBITING 0
This indicates a request to decrease the end user’s account
according to information specified in the Requested-Service-Unit
AVP and/or Service-Identifier AVP (additional rating information
may be included in service-specific AVPs or in the Service-
Parameter-Info AVP). The Granted-Service-Unit AVP in the Credit-
Control-Answer command contains the debited units.
REFUND_ACCOUNT 1
This indicates a request to increase the end user’s account
according to information specified in the Requested-Service-Unit
AVP and/or Service-Identifier AVP (additional rating information
may be included in service-specific AVPs or in the Service-
Parameter-Info AVP). The Granted-Service-Unit AVP in the Credit-
Control-Answer command contains the refunded units.

Ltd
HUAWEI UGW9811
3.2.61 Result-Code
AVP name Result-Code
AVP code 268

AVP type Unsigned32
Note: This AVP shows whether a specific request is executed successfully or error occurs.
All Diameter replies defined in the IETF application should include Result-Code. If the host
that configures the Result-Code AVP is not one that is designated in Origin-Host AVP, an
unsuccessful Result-Code AVP should include Error-Reporting-Host AVP.
The Result-Code data includes a 32 bit address space managed by INAN to show an error.
The error code types provided by the Diameter are as follows and the error types is
distinguished by the thousands digit:
- 1xxx (Information)
- 2xxx (Succeed)
- 3xxx (Protocol error)
- 4xxx (Temporary failure)
- 5xxx (Permanent failure)
The type that cannot be distinguished (the first one is excluded in the definition) must be
defined as permanent failure.
For the value definition of this field, refer to Chapter 5.4 (Specification Appendix).
3.2.62 Reporting-Reason
AVP name Reporting-Reason
AVP code 872

AVP type Enumerated
Note: Specifies the reason for usage reporting for one or more types of quota for a particular
category. When the CCR reports the credit use situation, the Reporting-Reason can occur
directly in the Multiple-Services-Credit-Control AVP, or in the Used-Service-Units AVP
within a Credit Control Request command reporting credit usage. It shall not be used at
command level. It shall always and shall only be sent when usage is being reported.
Reporting-Reason has the following definitions:
THRESHOLD 0
This value is used to indicate that the reason for usage reporting of the particular quota type
indicated in the Used-Service-Units AVP where it appears is that the threshold has been
reached.
QHT 1
This value is used to indicate that the reason for usage reporting of all quota types of the
Multiple-Service-Credit-Control AVP where its appears is that the quota holding time
specified in a previous CCA command has been hit (i.e. the quota has been unused for that
period of time).
FINAL 2

Ltd
HUAWEI UGW9811
AVP name Reporting-Reason
Multiple-Service-Credit-Control AVP where its appears is that a normal PDP context

termination has happened.
QUOTA_EXHAUSTED 3
indicated in the Used-Service-Units AVP where it appears is that the quota has been
exhausted.
VALIDITY_TIME 4
Multiple-Service-Credit-Control AVP where its appears is that the credit authorization
lifetime provided in the Validity-Time AVP has expired.
OTHER_QUOTA_TYPE 5
indicated in the Used-Service-Units AVP where it appears is that, for a multi-dimensional
quota, one reached a trigger condition and the other quota is being reported.
RATING_CONDITION_CHANGE 6
Multiple-Service-Credit-Control AVP where its appears is that a change has happened in
some of the rating conditions that were previously armed (through the Trigger-Type AVP,
e.g. QoS, Radio Access Technology,…). The specific condition that has changed is indicated
in an associated Trigger-Type AVP.
FORCED_REAUTHORISATION 7
Multiple-Service-Credit-Control AVP where its appears is that it is there has been a Server
initiated re-authorization procedure, i.e. receipt of RAR command.
POOL_EXHAUSTED 8
indicated in the User-Service-Units AVP where it appears is that granted units are still
available in the pool but are not sufficient for a rating group using the pool.
The values QHT, FINAL, VALIDITY_TIME, FORCED_REAUTHORISATION,

RATING_CONDITION_CHANGE apply for all quota types and are used directly in the
Multiple-Services-Credit-Control AVP, whereas the values THRESHOLD,
QUOTA_EXHAUSTED and OTHER_QUOTA_TYPE apply to one particular quota type
and shall occur only in the Used-Service-Units AVP. The value POOL_EXHAUSTED apply
to all quota types using the credit pool and occurs in the Used-Service-Units AVP.When the
value RATING_CONDITION_CHANGE is used, the Trigger-Type AVP shall also be
included to indicate the specific event which caused the re-authorization request.
3.2.63 Requested-Service-Unit
AVP name Requested-Service-Unit
AVP code 437

AVP type Grouped

Ltd
HUAWEI UGW9811
AVP name Requested-Service-Unit
Note: Requested service unit or total amount.

Requested-Service-Unit must be contained in the first or middle CCR request. If the DCC
client (for example: test that the terminal user terminates the service) does not contain
Requested-Service-Unit in the request, then the DCC server should deduct the used amount
form the user’s account. In addition, new quota cannot be returned in the response. Reply
with Validity-Time, Result-Code and Final-Unit-Indication to terminate the service elegantly.
Requested-Service-Unit AVP is an AVP group. The specific ABNF grammars are as follows.
Requested-Service-Unit ::= < AVP Header: 437 >
[ CC-Time ]
[ CC-Total-Octets ]
3.2.64 Redirect-Server
AVP name Redirect-Server
AVP code 434

AVP type Grouped
Note: It includes the address information of the redirect server, for example, HTTP Redirect
Server and SIP Redirect Server. When the user account balance is not enough to pay for the
service charge, the user is redirected to the redirect server.
When Final-Unit-Action is configured as REDIRECT, Redirect-Server must be specified.
Redirect-Server AVP is an AVP group. The ABNF grammars are as follows:
Redirect-Server ::= < AVP Header: 434 >
{ Redirect-Address-Type }
{ Redirect-Server-Address }
3.2.65 Redirect-Address-Type
AVP name Redirect-Address-Type
AVP code 433

AVP type Enumerated

Ltd
HUAWEI UGW9811
AVP name Redirect-Address-Type
Note: It defines the address types provided in Redirect-Server-Address.

The values defined by address types are as follows:
Ipv4 Address 0
The address type is Ipv4 form defined in [Ipv4].
Ipv6 Address 1
The address type is Ipv6 form defined in [Ipv6Addr]. The address format can be the
preferred form or alternate form defined in [Ipv6Addr]. Implementation construction must
support preferred form and should support alternate form.
URL 2
The address type is URL form defined in [URL].
SIP URI 3
The address type is SIP URI form defined in [SIP].
3.2.66 Redirect-server-Address
AVP name Redirect-Server-Address
AVP code 435

AVP type UTF8String
Note: It defines the address information of the redirect server, for example, HTTP Redirect
Server and SIP Redirect Server. When the user account balance is not enough to pay for the
service charge, the user is redirected to this address.
3.2.67 Restriction-Filter-Rule
AVP name Restriction-Filter-Rule
AVP code 343

AVP type IPFilterRule
Note: 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.
3.2.68 Service-Context-Id
AVP name Service-Context-Id
AVP code 461

Ltd
HUAWEI UGW9811
AVP name Service-Context-Id
AVP type UTF8String

Note: The Service-Context-Id contains a unique identifier of the Diameter Credit Control service
specific document that applies to the request. This is an identifier allocated by the service
provider/operator, by the service element manufacturer or by a standardization body and MUST
uniquely identify a given Diameter Credit Control service specific document.
Format:
“extensions”.MNC.MCC.”Release”.”service-context” “@” “domain”
The 3GPP specific values for “service-context” “@” “domain” are:
For PS charging: 32251@3gpp.org
The “Release” indicates the 3GPP Release the service specific document is based upon e.g. 6 for
Release 6.
As a minimum, Release “service-context” “@” “domain” shall be used. If the minimum is used
all operator configurable parameters (Oc and Om) are optional.
The MNC.MCC identifies the operator implementing the service specific document, which is
used to determine the specific requirements for the operator configurable parameters.
The “extensions” is operator specific information to any extensions in a service specific
document.
3.2.69 Service-Identifier
AVP name Service-Identifier
AVP code 439

AVP type Unsigned32
Note: The Service-Identifier AVP is of type Unsigned32 (AVP Code 439) and contains the
identifier of a service. The specific service the request relates to is uniquely identified by the
combination of Service-Context-Id and Service-Identifier AVPs.
3.2.70 Service-Information
AVP name Service-Information
AVP code 873

AVP type Grouped
Note: Service information group. Defining this AVP is to allow the client to deliver specific
additional service information.
Service-Information AVP is an AVP group. The specific ABNF grammars are as follows:
Service-Information :: = < AVP Header: 20100>
*[ Subscription-Id ]
[ PS-Information ]

Ltd
HUAWEI UGW9811
3.2.71 Serving-Node-Type
AVP name Serving-Node-Type
AVP code 2047

AVP type Enumerated
Note: The Serving-Node-Type AVP (AVP Code 2047) is of type Enumerated and identifies
the type of Serving Node. It may take the following values:
0 SGSN
1 PMIPSGW
2 GTPSGW
3 ePDG
4 hSGW
5 MME
3.2.72 Session-Id
AVP name Session-Id
AVP code 263

AVP type UTF8String
Note: Session ID, uniquely identifying once DCC session process.
Grammar:
<DiameterIdentity>;<high 32 bits>;<low 32 bits>[;<optional value>]
Example for SPUD board.
<high 32 bits>: Session create time in UTC format (seconds from 1900).
<low 32 bits>: Slot and CPU number from 0~4095.
<optional value>: Sequence number.
The above fields are separated with ";".
Example: ggsnv9;3447404749;529;10
Example for SPUE board.
3.2.73 SGSN-Address
AVP name SGSN-Address
AVP code 1228

AVP type IPAddress

Ltd
HUAWEI UGW9811
AVP name SGSN-Address
Note: SGSN IP address. This AVP can be used to identify the PLMN of the SGSN to which
the user logs on.
3.2.74 Start-Time
AVP name Start-Time
AVP code 2041

AVP type Time
Note: The Start-Time AVP is of type Time and holds the time in UTC format which
represents the start of a user session at the S-GW/P-GW.
3.2.75 Stop-Time
AVP name Stop-Time
AVP code 2042

AVP type Time
Note: The Stop-Time AVP is of type Time and holds the time in UTC format which
represents the termination of a user session at the S-GW/P-GW.
3.2.76 Tariff-Change-Usage
AVP name Tariff-Change-Usage
AVP code 452

AVP type Enumerated

Ltd
HUAWEI UGW9811
AVP name Tariff-Change-Usage
Note: It defines whether the used unit is before or after the rate switchover, or spans different
rates when rate switchover happens in a report schedule. If this AVP is neglected, it shows
that no rate switchover happens.
When the response message is Multiple-Service-Credit-Control AVP, this AVP defines
whether the allocated unit is used before or after the rate switchover.
In the response message, if this AVP is neglected, it shows that unique quota mechanism is
used.
The following values are defined in the Tariff-Change-Usage AVP:
UNIT_BEFORE_TARIFF_CHANGE 0
When present in the Multiple-Services-Credit-Control AVP, this value indicates the amount
of the units allocated for use before a tariff change occurs. When present in the Used-
Service-Unit AVP, this value indicates the amount of resource units used before a tariff
change had occurred.
UNIT_AFTER_TARIFF_CHANGE 1
When present in the Multiple-Services-Credit-Control AVP, this value indicates the amount
of the units allocated for use after a tariff change occurs. When present in the Used-Service-
Unit AVP, this value indicates the amount of resource units used after tariff change had
occurred.
UNIT_INDETERMINATE 2
The used unit contains the amount of units that straddle the tariff change (e.g., the metering
process reports to the credit-control client in blocks of n octets, and one block straddled the
tariff change). This value is to be used only in the Used-Service-Unit AVP.
3.2.77 Tariff-Time-Change
AVP name Tariff-Time-Change
AVP code 451

AVP type Time
Note: The charging rate switchover system is optional to both the client and the server, and is
not used in the service based on continuous time. If the client does not support the charging
rate switchover system, the CCA answer message including Tariff-Time-Change is regarded
as failure. Then the client ends credit CC session and shows the termination cause is
DIAMETER_BAD_ANSWER in Termination-Cause AVP.
Ignoring this AVP means charging rate switchover report is not needed.
3.2.78 Termination-Cause
AVP name Termination-Cause
AVP code 295

AVP type Enumerated

Ltd
HUAWEI UGW9811
AVP name Termination-Cause
Note: It used to indicate the reason for the session termination of the Diameter client.
DIAMETER_LOGOUT 1
The user initiated disconnect.
DIAMETER_SERVICE_NOT_PROVIDED 2
This value is used when the user disconnected prior to the receipt of the authorization answer
message.
DIAMETER_BAD_ANSWER 3
This value indicates that the authorization answer received by the access device was not
processed successfully.
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.
DIAMETER_LINK_BROKEN 5
The communication to the user was abruptly disconnected.
DIAMETER_AUTH_EXPIRED 6
The user’s access was terminated since its authorized session time has expired.
DIAMETER_USER_MOVED 7
The user is receiving services from another access device.
DIAMETER_SESSION_TIMEOUT 8
The user’s session has timed out, and service has been terminated.
3.2.79 Time-Quota-Threshold
AVP name Time-Quota-Threshold
AVP code 868

AVP type Unsigned32
Note: It includes threshold value calculated by second. When Multiple-Services-Credit-
Control includes Granted-Service-Units and Granted-Service-Units includes CC-Time (the
quota distributed is time quota), Multiple-Services-Credit-Control may include Time-Quota-
Threshold.
When Time-Quota-Threshold is received, DCC client will send CCR reauthorization to
apply for new quota if the quota left is lower than the threshold value defined by Time-
Quota-Threshold. During the reauthorization process, DCC client allows users to continue to
use the service until the original quota is used up.

Ltd
HUAWEI UGW9811
3.2.80 Time-Quota-Mechanism
AVP name Time-Quota-Mechanism
AVP code 1270

AVP type Grouped
Note: This AVP It has the following syntax:
Time-Quota-Mechanism ::= < AVP Header: 1270>
{ Time-Quota-Type }
{ Base-Time-Interval }
The OCS may include this AVP in a Multiple-Services-Credit-Control AVP, when granting
time quota.
3.2.81 Time-Quota-Type
AVP name Time-Quota-Type
AVP code 1271

AVP type Enumerated
Note: This AVP is used to indicate which time quota consumption mechanism shall be used
for the associated Rating Group.
It has the following values:
DISCRETE_TIME_PERIOD (0)
CONTINUOUS_TIME_PERIOD (1)
3.2.82 Trigger
AVP name Trigger
AVP code 1264

AVP type Grouped
Note: The Trigger AVP is of type Grouped and holds the trigger types. The presence of the
Trigger AVP without any Trigger-Type AVP in a CCA allows OCS to disable all the triggers.
The presence of the Trigger AVP in the CCR identifies the event(s) triggering the CCR.
It has the following ABNF grammar:
<Trigger>::= < AVP Header: 1264 >
* [ Trigger-Type ]

Ltd
HUAWEI UGW9811
3.2.83 Trigger-Type
AVP name Trigger-Type
AVP code 870

AVP type Enumerated
Note: It is used to indicate a re-authorization time type. When Trigger-Type appears in the
CCA command, it indicates the event which causes that the DCC client re-applies quota.
When the event which does not be included in Trigger AVP, the client should not re-
authorize to apply new quota.
Trigger-Type must be used when the Reporting-Reason in CCR is
RATING_CONDITION_CHANGE.
The following values are defined in Trigger-Type:
CHANGE_IN_SGSN_IP_ADDRESS 1
It shows that the SGSN IP address changes so that the DCC client requests new authority
quota.
CHANGE_IN_QOS 2
It shows that the QoS negotiated by the terminal user changes so that the DCC client
requests new authority quota.
CHANGE_IN_LOCATION 3
It shows that the terminal user location changes so that the DCC client requests new
authority quota.
CHANGE_IN_RAT 4
It shows that the radio access techniques change so that the DCC client requests new
authority quota.
3.2.84 Unit-Quota-Threshold
AVP name Unit-Quota-Threshold
AVP code 1226

AVP type Unsigned32
Note: It includes threshold value calculated by unit. When Multiple-Services-Credit-Control
includes Granted-Service-Units and Granted-Service-Units include CC-Service-Specific-
Units (the quota distributed is unit quota), Multiple-Services-Credit-Control may include
Unit-Quota-Threshold.
When Unit-Quota-Threshold is received, DCC client will send CCR reauthorization to apply
for new quota if the quota left is lower than the threshold value defined by Unit -Quota-
Threshold. During the reauthorization process, DCC client allows users to continue to use
the service until the original quota is used up.

Ltd
HUAWEI UGW9811
3.2.85 Unit-Value
AVP name Unit-Value
AVP code 445

AVP type Grouped
Note: The Unit-Value AVP specifies the units as decimal value.
The Unit-Value is a value with an exponent. The value part should be within the range from
1 to 2^32-1.The absence of the exponent part MUST be interpreted as an exponent equal to
zero. If the exponent part is present, it should be zero.
The Used-Service-Unit AVP is of type Grouped, and is defined as follows:
Unit-Value ::= < AVP Header: 445 >
{ Value-Digits }
[ Exponent ]
3.2.86 Used-Service-Unit
AVP name Used-Service-Unit
AVP code 446

AVP type Grouped
Note: The number of total used units tested after the service is activated (if middle charging
time is adopted, then the number is counted from the end of the test of last time).
Used-Service-Unit AVP is an AVP group. The specific ABNF grammars are as follows.
Used-Service-Unit ::= < AVP Header: 446>
[ Reporting-Reason ]
[ Tariff-Change-Usage ]
[ CC-Time ]
[ CC-Total-Octets ]
[ CC-Input-Octets ]
*[ Event-Charging-TimeStamp ]
3.2.87 User-Equipment-Info
AVP name User-Equipment-Info
AVP code 458

AVP type Grouped

Ltd
HUAWEI UGW9811
AVP name User-Equipment-Info
Note: User device information.

User-Equipment-Info is an AVP group. The specific ABNF grammars are as follows.
User-Equipment -–Info ::= <AVP Header: 458>
{User-Equipment-Info-Type}
{User- Equipment-Info-Value}
3.2.88 User-Equipment-Info-Type
AVP name User-Equipment-Info-Type
AVP code 459

AVP type Enumerated
Note: This field determines the type of the identifier. The used value is 0 for the international
mobile equipment identifier and software version according to 3GPP TS 23.003.
3.2.89 User-Equipment-Info-Value
AVP name User-Equipment-Info-Value
AVP code 460

Note: This field contains the user IMEISV.
IMEISV supports both BCD type and UTF8Sting type by the control of software parameter
BYTE33 BIT1 and BIT2:
Bit1 Bit2 Description
0 0 IMEIV filled as BCD code.
1 0 IMEIV filled as UTF8 string, for length 15 IMEIV, the last two bytes was filled
by FF.
0 1 IMEIV filled as UTF8 string, for length 15 IMEIV, only the 15 valid bits will be
filled.
3.2.90 User-Name
AVP name User-Name
AVP code 1
AVP type UTF8String

Ltd
HUAWEI UGW9811
AVP name User-Name
Note: The User-Name AVP (AVP Code 1) [RADIUS] is of type UTF8String, which
contains the User-Name, in a format consistent with the NAI
specification [NAI].
3.2.91 Validity-Time
AVP name Validity-Time
AVP code 448

AVP type Unsigned32
Note: This AVP is sent from the DCC server to the DCC client and includes valid time of the
distributed service unit, recorded by seconds. The valid time is recorded from the time the
client receives CCA message including Validity-Time. If the allocated service units are not
used up in the valid time, the DCC client must send a CCR request to the server to apply for
quota.
Validity-Time is also used to end the service elegantly. It is used to indicate how long the
user can use the network resource after the DCC client begins a specific action, for example,
REDIRECT or RESTRICT_ACCESS. When the valid time expires, the DCC client will
send new interworking to the server.
The Validity-Time AVP on command level is not defined by 3GPP but in rfc4006. When this
AVP is received the DCC client starts a validity timer. It is not stopped when the DCC client
reports quota for a single MSCC. If the validity timer expires the DCC client has to report
quota for all MSCCs.
3.2.92 Value-Digits
AVP name Value-Digits
AVP code 447

AVP type Integer64
Note: The Value-Digits AVP is of type Integer64 (AVP Code 447) and contains the
significant digits of the number. The Value-Digits AVP should be within the range from 1 to
2^32-1.
3.2.93 Volume-Quota-Threshold
AVP name Volume-Quota-Threshold
AVP code 869

AVP type Unsigned32

Ltd
HUAWEI UGW9811
AVP name Volume-Quota-Threshold
Note: It includes threshold value calculated by byte. When Multiple-Services-Credit-Control

includes Granted-Service-Units and Granted-Service-Units include CC-Total-Octets, CC-
Input-Octets or CC-Output-Octets (the quota distributed is volume quota), Multiple-
Services-Credit-Control may include Volume-Quota-Threshold.
When Volume-Quota-Threshold is received, DCC client will send CCR reauthorization to
apply for new quota if the quota left is lower than the threshold value defined by Volume-
Quota-Threshold. During the reauthorization process, DCC client allows users to continue to
use the service until the original quota is used up.
3.2.94 3GPP-Charging-Id
AVP name 3GPP-Charging-Id
AVP code 2
AVP type Unsigned32
Note: Charging ID. The combination of 3GPP-Charging-Id and GGSN-Address can be used
to identify the charging records of all the related SGSN and GGSN of a PDP context.
Charging ID is generated by the GGSN during PDP context activation, and is sent to the
SGSN which sends the Context request. Because the GGSN allocates Charging ID
independently, different GGSNs may allocate the same Charging ID, which needs to be
identified by the server according to the GGSN address and the start time stamp of the
charging record.
3.2.95 3GPP-PDP-Type
AVP name 3GPP-PDP-Type
AVP code 3
AVP type Enumerated
Note: PDP context type, such as Ipv4, Ipv6 or PPP.
Enumeration type:
Ipv4 0
Ipv6 1
PPP 2
3.2.96 3GPP-GPRS-Negotiated-Qos-Profile
AVP name 3GPP-GPRS-Negotiated-Qos-Profile
AVP code 5
AVP type UTF8String

Ltd
HUAWEI UGW9811
AVP name 3GPP-GPRS-Negotiated-Qos-Profile
Note: Negotiated QoS. It should be consistent with the requested QoS version. This avp is
replaced by QoS-Information since 3Gpp 32.299 870.
3.2.97 3GPP-IMSI-MCC-MNC
AVP name 3GPP-IMSI-MCC-MNC
AVP code 8
AVP type UTF8String
Note: The Mobile Country Code (MCC) and Mobile Network Code (MNC) messages
extracted from the IMSI.
3.2.98 3GPP-GGSN-MCC-MNC
AVP name EGPP-GGSN-MCC-MNC
AVP code 9
AVP type UTF8String
Note: The MCC and MNC of the GGSN.
3.2.99 3GPP-NSAPI
AVP name 3GPP-NSAPI
AVP code 10
Note: The identification of the service access point to the network layer. In the MS, the
NASPI is used to identify PDP-SAP. Between the SGSN and the GGSN, the NASPI is used
to identify the PDP context that is associated with a PDP address.
3.2.100 3GPP-Session-Stop-Indicator
AVP name 3GPP-Session-Stop-Indicator
AVP code 11
AVP type BitString

Ltd
HUAWEI UGW9811
AVP name 3GPP-Session-Stop-Indicator
Note: Session abort identification. It identifies a session is over when the session is released
and is used in CCR (final).
3.2.101 3GPP-Selection-Mode
AVP name 3GPP-Selection-Mode
AVP code 12
AVP type UTF8String
Note: Selection mode.
It is received from the Create PDP Context Request Message.
The values allowed by the GGSN:
0
MS or network provided APN, subscribed verified
1
MS provided APN, subscription not verified
2
Network provided APN, subscription not verified
3.2.102 3GPP-Charging-Characteristics
AVP name 3GPP-Charging-Charateristics
AVP code 13
AVP type Unsigned32
Note: Charging characteristics. It is received from the Create PDP Context Request Message.
3.2.103 3GPP-SGSN-MCC-MNC
AVP name 3GPP-SGSN-MCC-MNC
AVP code 18
AVP type UTF8String
Note: The PLMN identification of the SGSN.

Ltd
HUAWEI UGW9811
3.2.104 3GPP-MS-TimeZone
AVP name 3GPP-MS-TimeZone
AVP code 23
Note: Time zone of the terminal.
3.2.105 3GPP-User-Location-Info
AVP name 3GPP-User-Location-Info
AVP code 22
Note: User location identification.
3.2.106 3GPP-RAT-Type
AVP name 3GPP-RAT-Type
AVP code 21
Note: Radio access techniques. Radio side parameters.
3.3 AVP Flag Defination

3.3.1 Basic AVPs from IETF
Figure a.1 AVPs from IETF
AVP Name AVP AVP Flag Rules
Cod Must May Should Must May
e
not not Encr.
Acct-Application-Id 259 M P - V N
Auth-Application-Id 258 M P - V N
Called-Station-Id 30 M P - V N

Ltd
HUAWEI UGW9811
CC-Input-Octets 412 - P,M - V Y

CC-Output-Octets 414 M P - V Y
CC-Request-Number 415 M P - V Y
CC-Request-Type 416 M P - V Y
CC-Service-Specific-Units 417 M P - V Y
CC-Session-Failover 418 M P - V Y
CC-Time 420 M P - V Y
CC-Total-Octets 421 M P - V Y
CC-Unit-Type 454 M P - V Y
Credit-Control-Failure-Handling 427 M P - V Y
Destination-Host 293 M P - V N
Destination-Realm 283 M P - V N
Direct-Debiting-Failure-Handling 428 M P - V Y
Event-Timestamp 55 M P - V N
Exponent 429 M P - V N
Failed-AVP 279 M P - V N
Filter-Id 11 M P - V Y
Final-Unit-Action 449 M P - V Y
Final-Unit-Indication 430 M P - V Y
Granted-Service-Unit 431 M P - V Y
G-S-U-Pool-Identifier 453 M P - V Y
G-S-U-Pool-Reference 457 M P - V Y
Multiple-Services-Credit-Control 456 M P - V Y
Multiple-Services-Indicator 455 M P - V Y
Origin-Host 264 M P - V N
Origin-Realm 296 M P - V N
Origin-State-Id 278 M P - V N
Proxy-Info 284 M - - P,V N
Proxy-Host 280 M - - P,V N
Proxy-State 33 M - - P,V N
Rating-Group 432 M P - V Y
Redirect-Address-Type 433 M P - V Y

Ltd
HUAWEI UGW9811
Redirect-Server 434 M P - V Y
Redirect-Server-Address 435 M P - V Y
Requested-Action 436 M P - V Y
Requested-Service-Unit 437 M P - V Y
Restriction-Filter-Rule 438 M P - V Y
Result-Code 268 M P - V N
Route-Record 282 M - - P,V N
Service-Context-Id 461 M P - V Y
Service-Identifier 439 M P - V Y
Session-Id 263 M P - V Y
Subscription-Id 443 M P - V Y
Subscription-Id-Data 444 M P - V Y
Subscription-Id-Type 450 M P - V Y
Tariff-Change-Usage 452 M P - V Y
Tariff-Time-Change 451 M P - V Y
Unit-Value 445 M P - V Y
Used-Service-Unit 446 M P - V Y
User-Equipment-Info 458 - P,M - V Y
User-Equipment-Info-Type 459 - P,M - V Y
User-Equipment-Info-Value 460 - P,M - V Y
User-Name 1 M P - V Y
Value-Digits 447 M P - V Y
Validity-Time 448 M P - V Y
Vendor-Id 266 - - - - -
Vendor-Specific-Application-Id 260 - - - - -
When AVPs are applied in different site, the flag rules may be defined differently according to
Operator’s requirement.

Ltd
HUAWEI UGW9811
3.3.2 3GPP Specific AVPs

Figure a.2 3GPP Specific AVPs
Cod Must May Should Must May
e
not not Encr.
Access-Network-Charging-Identifier-Value 503 V,M P Y
Access-Network-Information 1263 V,M P N
AF-Charging-Identifier 505 V,M P Y
Base-Time-Interval 1265 V,M P - N
CG-Address 846 V,M P Y
Charging-Rule-Base-Name 1004 V,M P Y
Envelope 1266 V,M P - 　 N
Envelope-Start-Time 1269 V,M P - 　 N
Envelope-End-Time 1267 V,M P - 　 N
Envelope-Reporting 1268 V,M P - 　 N
Event-Charging-TimeStamp 1258 V,M P - N
GGSN-Address 847 V,M P N

PDP-Address 1227 V,M P Y
PDP-Context-Type 1247 V,M P N
PS-Append-Free-Format-Data 867 V,M P N
PS-Free-Format-Data 866 V,M P N
PS-Furnish-Charging-Information 865 V,M P N
PS-Information 874 V,M P N
Quota-Consumption-Time 881 V,M P N
Quota-Holding-Time 871 V,M P N
Reporting-Reason 872 V,M P N
Service-Information 873 V,M P N
SGSN-Address 1228 V,M P N
Time-Quota-Mechanism 1270 V,M P - 　 N
Time-Quota-Threshold 868 V,M P N

Time-Quota-Type 1271 V,M P - 　 N

Ltd
HUAWEI UGW9811
Trigger Cod
1264 V,M P N
e
Trigger-Type 870 V,M P N
Unit-Quota-Threshold 1226 V,M P - 　 N
Volume-Quota-Threshold 869 V,M P N
3GPP-Charging-Characteristics 13 V,M P Y
3GPP-Charging-Id 2 V,M P Y
3GPP-GGSN- MCC-MNC 9 V,M P Y
3GPP-GPRS-Negotiated-QoS-Profile 5 V,M P Y
3GPP-IMSI-MCC-MNC 8 V,M P Y
3GPP-MS-TimeZone 23 V,M P Y
3GPP-NSAPI 10 V,M P Y
3GPP-PDP-Type 3 V,M P Y
3GPP-RAT-Type 21 V,M P Y
3GPP-Selection-Mode 12 V,M P Y
3GPP-Session-Stop-Indicator 11 V,M P Y
3GPP-SGSN-MCC-MNC 18 V,M P Y
3GPP-User-Location-Info 22 V,M P Y
When AVPs are applied in different site, the flag rules may be defined differently according to
Operator’s requirement.
3.4 Traffic Control Behaviour on CCA Result

Codes
3.4.1 Result Codes on Command Level
For command level result codes, each result code (except 2001 and 2002 )behavior could be
specificly configured for items below:
 Terminate with CCR-T: to tear down the PDP context and send CCR-T.
 Terminate without CCR-T: to tear down the PDP context and not to send CCR-T.
 Offline: to allow the PDP as offline service and generate the offline GCDR if

Ltd
HUAWEI UGW9811
configured
 Failover: to take failure handling according to CCFH configuration.
 Block: to block all subscriber services (including subsequently requested services and
services for which quota has been allocated)
 Redirect: to redirect all subscriber services (including subsequently requested services
and services for which quota has been allocated)
All other result codes which are not specially configured and not 2001/ 2002 will behave as
Command level default behavior.
Figure a.3 Command level result code action.

CCA Result code on Traffic Behaviour Comment
command level
DIAMETER_SUCCESS (2001) Depends on MSCC result

code
DIAMETER_LIMITED_SUCCESS Depends on MSCC result
(2002) code
Specific result code Behaviour Configurable for
Terminate with CCR-T
Terminate without CCR-T
Offline
Failover
All other result codes Default Behaviour

Ltd
HUAWEI UGW9811
Figure a.4 List of typical result code

Ltd
CCA Result code on Traffic Behaviour Origin Comme
command level nt
HUAWEI UGW9811 3 Interface Definition
DIAMETER_MULTI_ROUND_
Gy Interface Specification Default Behaviour RFC358
AUTH(1001) 8
DIAMETER_SUCCESS (2001) Depends on MSCC RFC358

result code 8
DIAMETER_LIMITED_SUCCESS Depends on MSCC RFC358
(2002) result code 8
DIAMETER_COMMAND_ Default Behaviour RFC358
UNSUPPORTED (3001) 8
DIAMETER_UNABLE_TO_DELIVE Failover RFC358

R (3002) 8
DIAMETER_REALM_NOT_ Default Behaviour RFC358
SERVED(3003) 8
DIAMETER_TOO_BUSY (3004) Failover RFC358

8
DIAMETER_LOOP_DETECTED Failover RFC358
(3005) 8
DIAMETER_REDIRECT_ Default Behaviour RFC358
INDICATION(3006) 8
DIAMETER_APPLICATION_UNSU Default Behaviour RFC358

PPORTED (3007) 8
DIAMETER_INVALID_HDR_BITS Default Behaviour RFC358
(3008) 8
DIAMETER_INVALID_AVP_BITS Default Behaviour RFC358
(3009) 8
DIAMETER_UNKNOWN_PEER Failover RFC358
(3010) 8
DIAMETER_AUTHENTICATION_R Default Behaviour RFC358
EJECTED(4001) 8
DIAMETER_OUT_OF_SPACE Failover RFC358
(4002) 8
DIAMETER_ELECTION_LOST(400 Default Behaviour RFC358
3) 8
DIAMETER_END_USER_ Default Behaviour RFC400
SERVICE_DENIED(4010) 6
DIAMETER_CREDIT_CONTROL_N No credit control RFC400

OT_APPLICABLE (4011) 6
DIAMETER_CREDIT_LIMIT_REAC Default Behaviour RFC400
HED (4012) 6
DIAMETER_AVP_UNSUPPORTED( Default Behaviour RFC358
5001) 8
DIAMETER_UNKNOWN_SESSION Terminate PDP no CCR RFC358
_ID (5002) 8
DIAMETER_AUTHORIZATION_RE Terminate PDP with RFC358 After PDP
Issue 01 (2011-10-31)JECTED(5003) Huawei Proprietary and Confidential
CCR 8 context 59
Copyright © Huawei Technologies Co., activation
Ltd procedure.
Used
Quota
must be
HUAWEI UGW9811
3.4.2 Result Codes on MSCC Level

For MSCC level result codes, each result code (except 2001 and 2002 )behavior could be
specificly configured for items below:
 Block: to block the service but keep the PDP context. It is default value.
 Offline: to allow the service as offline service and generate the offline GCDR if
configured
 Redirect: to redirect browsing services to configured web server.
 Terminate: to Tear down the PDP context
All other result codes which are not specially configured and not 2001/ 2002 will behave as
MSCC level default behavior.
Figure a.5 MSCC level result code

CCA Result code in Traffic Behaviour Comment
MSCC
DIAMETER_SUCCESS (2001) Allow Traffic

DIAMETER_LIMITED_SUCC Allow Traffic
ESS (2002)
Specific result code Behaviour Configurable Except “Terminate”, all
for behavoir will be done only
Block on the service traffics of the
Rating Group indicated in
Offline the MSCC.
Redirect
Terminate
All other result codes Default Behaviour

Ltd
HUAWEI UGW9811
3.4.3 Final Unit Action on MSCC Level

Figure a.6 Final Unit Action on MSCC level
CCA Result code in Final-Unit- Traffic Comment
MSCC Action
DIAMETER_SUCCESS Terminate Block Traffic is blocked

(2001) when quota is
exhausted
Redirect Redirection Redirection is done
when the quota is
exhausted
Restrict-Access Restrict- Restrict-Access is
Access done when quota is
exhausted
DIAMETER_CREDIT_LIMIT Terminate Block
_REACHED (4012)
Redirect Redirection
Restrict-Access Restrict-
Access
All other result codes Terminate Default
Behaviour
Redirect Default
Behaviour
Restrict-Access Default
Behaviour
3.4.4 Default Behaviour
The default behaviour can be configured separately for Command level and MSCC level
result codes locally on GGSN.
Command level result code
 Terminate with CCR-T: to tear down the PDP context and send CCR-T. It is default
value.
 Terminate without CCR-T: to tear down the PDP context and not to send CCR-T.
 Offline: to allow the PDP as offline service and generate the offline GCDR if
configured
 Failover: to take failure handling according to CCFH configuration.
For MSCC level result code not specifically configured, MSCC level default behaviors below
could be configured:
 Block: to block the service but keep the PDP context. It is default value.
 Redirect: to redirect browsing services to configured web server.

Ltd
HUAWEI UGW9811
 Offline: to allow the service as offline service and generate the offline GCDR if
configured
 Terminate: to Tear down the PDP context
3.5 Work Flow

3.5.1 Signalling Flow
Figure a.1 Initial Balance Check & Authentication
Figure a.2 Volume Based Charging

Ltd
HUAWEI UGW9811
Figure a.3 Time Based Charging

Ltd
HUAWEI UGW9811
Figure a.4 Redirection when Balance Exhausted & Recharge Notification

Ltd
HUAWEI UGW9811
Figure a.5 PDP Update Signalling Flow
Figure a.6 Charging Flow Based on Session
1. The user sends a service request to the GGSN. After the GGSN receives the request, it sends a
CCR request to the OCS. The CCR message includes the Credit-Control AVP which is used to
describe the credit control capability and the other AVPs which are used to describe the
authorization and authentication situation.

Ltd
HUAWEI UGW9811
2. The OCS carries out rating for this request and reserves the capital in the user account. Then it
sends a reply message CCA to the CCR request. The reply message includes the Granted-
Service-Unit AVP(s) and maybe also includes the other AVPs of credit control description. In
addition, the OCS may set the Validity-Time, and the AVP used to deal with message delivery
failure is possible to be included, such as Credit-Control-Failure-Handling AVP and Direct-
Debiting-Failure-Handling AVP.
3. After the GGSN receives the CCA, it authorizes the terminal users to use the corresponding
service. At the same time, the immediate credit control request is generated.
4. When the reserved capital of the user is to be used up or expire, the GGSN sends new
reservation request to the OCS again. The OCS once again reserves capital from the user
account, returns the corresponding limits to the GGSN. Then the GGSN updates the
reservation capital of the user.
5. When the user account is used up or the enabled service is to end, the GGSN sends a message
of terminating credit control service to the OCS. Set the corresponding CC-Request-Type AVP
as TERMINATION_REQUEST. The message should contain the Event-Timestamp AVP for
identifying the service end time and the Used-Service-Unit AVP used by the actual service.
The OCS needs to return the rest reserved capital to the user account and deduct the cost.
Figure a.1 Charging Based on Tariff Changes
1. The user sends the PDP Context request.

6. The GGSN sends the CCR Initial information, asking the OCS to set up control connection.
7. The OCS replies the CCA Initial information which contains Result Code Success.
8. The PDP Context is set up successfully.
9. The user sends the cat 1 service request.
10. The GGSN sends the CCR Update information which contains Rating Group=1.

Ltd
HUAWEI UGW9811
11. The OCS carries out rating, counting the traffic quota.
12. The OCS replies the CCA Update information to allocate the quota, and informs the GGSN of
the idle time timer and the minimum quota threshold.
13. The user used traffic reaches the minimum quota threshold.
14. The GGSN sends the CCR Update, reporting the used quota. The report reason is that the
used traffic reaches the minimum quota threshold.
15. The OCS carries out rating, accounting the used traffic quota. The OCS tests the oncoming
tariff switch time. Here, TS-current time is less than VT. The OCS can provide the available
quota before and after the tariff switch time.
16. The OCS replies the CCA Update information to re-allocate the quota an return the tariff
switch time of the parameter.
17. The user used traffic reaches the minimum quota threshold.
18. The GGSN reports the used traffic before and after the tariff switch time.
19. The OCS carries out rating, accounting the used traffic quota before and after the tariff switch
time.
20. The OCS replies the CCA Update information to re-allocate the quota.
Figure a.1 Re-Authorization Flow Launched by Server
The OCS can launch the re-authentication/authorization service by sending a Re-Auth-

Request (RAR). For example, for the pre-paid charging service, the initially authorized OCS
may confirm whether the user is still using this service. If the service supports re-
authentication/authorization, the access device receives the RAR information in which the
Session-ID is the same as the current activity session. Otherwise, the access device should
send re-authentication/authorization to the user.

Ltd
HUAWEI UGW9811
1. The OCS sends the Re-Auth-Request (RAR) message to launch a re-authentication flow.
21. When the GGSN receives the RAR information with some RG, it accepts the request from the
OCS, sends a RAA with result code 2002 to the OCS to inform that the re-authentication has
started, and then send CCR message to re-auth quota of the RG indicated in RAR message.
22. After the GGSN receives the CCA containing Granted-Service-Unit, the credit control session
and the service continue with new quota granted from OCS.
Figure a.1 Abort Session Flow Launched by Server
The OCS can launch the abort session service by sending an Abort-Session-Request (ASR).
For example, for the pre-paid charging service, the initially authorized OCS may confirm that
the user cannot use this service any more. If the service supports abort session, the access
device receives the ASR information in which the Session-ID is the same as the current
activity session. Otherwise, the access device should send abort session to the user.
1. The OCS sends the Abort-Session-Request (ASR) message to launch a abort session flow.
23. When the GGSN receives the ASR information, it accepts the request from the OCS, sends an
ASA to the OCS to inform that the user can abort the service, sends an instruction to the use
to abort the service, and then sends CCR(Terminate) to the OCS to report the rest traffic.
24. The GGSN receives CCA(Terminate), and the session is over.
3.5.2 Abnormal Flow

Solutions When Tx Timer Does Not Receive CCA Before It Times Out
After the GGSN sends the CCR message to the OCS and consumes the credit quota of this
user, before receiving the CCA message, the GGSN can support:
 Not breaking the service being used by the pre-paid charging users. (If this method is
used, then the quota used by the users during this period should be recorded in G-CDR
and the credit control request message of the next time.)
 Pausing the service being used by the pre-paid charging service until it receives the CCA
message from the OCS and is authorized.
 Terminating the service being used by the pre-paid charging users.

Ltd
HUAWEI UGW9811
Switchover Flow When the OCS Server Is Abnormal

The GGSN can configure two active/standby OCS servers. When the active OCS server is
abnormal, the GGSN can switch to communicate with the standby OCS server.
The GGSN exchanges the DWR/DWA path monitoring message with the OCS server on fixed
time to monitor the path situation between them.
After the GGSN sends the credit control request to the OCS server, if it does not receive any
response until timeout, the GGSN can use the methods specified in the Diameter protocol to
perform any of the follows according to the CCFH value set by the carriers.
 Not breaking the service being used by the pre-paid charging users. (If this method is
used, then the quota used by the users during this period should be recorded in G-CDR
and the credit control request of the next time.)
 Re-sending the credit control request. If the retrials still fail, then terminate the service
used by the pre-paid charging users.
 Terminating the service being used by the pre-paid charging users directly instead of re-
sending the credit control request.
If the CCFH is set as the TERMINATE value, the OCS switchover flow will not work. If fault
occurs to the active OCS server, the GGSN will directly prevent the user from using this
service, as shown in the following figure.
Figure a.1 Failure Handling—Terminate
When the CCFH is set as the CONTINUE or the RETRY_AND_TERMINATE value, when
fault occurs, it will start the OCS switchover flow, If the active OCS server is abnormal, the
GGSN sends the path test message. If the path test fails, the OCS switchover will be enabled
to re-send the CCR message to the standby OCS server, as shown in the following figure.

Ltd
HUAWEI UGW9811
Figure a.2 Failure Handling—Retry and Success

Ltd
HUAWEI UGW9811
4 Defined AVP Table
In the following statement, "<>" means that it is compulsory and should be in the beginning
of the message, "{}" means that it is compulsory, "[]" means that it is optional, and "*[]"
means that the option can be repeated.
 M Compulsory
 C Condition optional
 OM Compulsory option defined by the operator
 OC Condition optional option defined by the operator
The different option attributes of each AVP in the specific situation (First, Intermediate, Final
and EVENT) is defined in the following table.
If an AVP has father node, then whether it appears depends on whether its father node
appears. If the optional father node does not appear, then even this AVP attribute is
compulsory, this AVP will not appear.
Document--<Gy AVP Table.xls> indicates detail information of AVPs for each DCC messages.

Ltd
HUAWEI UGW9811
Gy Interface Specification B Glossary
Figure a.1 Reference Standand
The clauses in the following files become the clauses of this specification through reference.
All the sequent modification sheets (excluding the corrigenda) of the referenced files marked
with date are not fit for this specification. However, the parties that reach an agreement
according to this specification are recommended to study whether the latest versions of these
files can be used. The latest versions for all the referenced files without date are fit for this
specification.
[1] IETF RFC 4006: “Diameter Credit-Control Application”.
[2] IETF RFC 3588: “Diameter Base Protocol”.
[3] 3GPP TS 32.299: “Telecommunication management; Charging management; Diameter
charging application”.
[4] 3GPP TS 32.251: “Telecommunication management; Charging management; Packet
Switched (PS) domain charging”.
[5] Gy AVP Table.xls

Ltd
HUAWEI UGW9811
Figure a.2 Glossary
AAA Authentication, Authorization and Accounting.

The act of collecting information on resource usage for the purpose of
Accounting
capacity planning, auditing, billing or cost allocation.
An accounting record represents a summary of the resource
consumption of a user over the entire session. Accounting servers
Accounting Record creating the accounting record may do so by processing interim
accounting events or accounting events from several devices serving
the same user.
Authentication The act of verifying the identity of an entity (subject).
The act of determining whether a requesting entity (subject) will be
Authorization
allowed access to a resource (object).
The Diameter protocol consists of a header followed by one or more
Attribute-Value-Pairs (AVPs). An AVP includes a header and is used to
AVP
encapsulate protocol-specific data (e.g., routing information) as well as
authentication, authorization or accounting information.
A broker is a business term commonly used in AAA infrastructures. A
broker is either a relay, proxy or redirect agent, and MAY be operated
Broker
by roaming consortiums. Depending on the business model, a broker
may either choose to deploy relay agents or proxy agents.
Credit pool is a mechanism to avoid the credit fragmentation introduced
by credit reservation on OCS server. The OCS server allocates the
Credit Pool quotas with a reference to a credit pool. A credit pool is formed on the
client by multiple quotas linked to one credit pool, from which all
services draw units.
A Diameter Agent is a Diameter node that provides either relay, proxy,
Diameter Agent
redirect or translation services.
A Diameter Client is a device at the edge of the network that performs
Diameter Client access control. An example of a Diameter client is a Network Access
Server (NAS) or a Foreign Agent (FA).
A Diameter node is a host process that implements the Diameter
Diameter Node
protocol, and acts either as a Client, Agent or Server.
A Diameter Peer is a Diameter Node to which a given Diameter Node
Diameter Peer
has a direct transport connection.

Ltd
HUAWEI UGW9811
Diameter Security A Diameter Security Exchange is a process through which two Diameter
Exchange nodes establish end-to-end security.
A Diameter Server is one that handles authentication, authorization and
accounting requests for a particular realm. By its very nature, a
Diameter Server
Diameter Server MUST support Diameter applications in addition to the
base protocol.
Downstream is used to identify the direction of a particular Diameter
Downstream
message from the home server towards the access device.
TLS and IPsec provide hop-by-hop security, or security across a
transport connection. When relays or proxy are involved, this hop-by-
hop security does not protect the entire Diameter user session. End-to-
End-to-End Security end security is security between two Diameter nodes, possibly
communicating through Diameter Agents. This security protects the
entire Diameter communications path from the originating Diameter
node to the terminating Diameter node.
A Home Realm is the administrative domain with which the user
Home Realm
maintains an account relationship.
Home Server See Diameter Server.
An interim accounting message provides a snapshot of usage during a
user's session. It is typically implemented in order to provide for partial
Interim accounting accounting of a user's session in the case of a device reboot or other
network problem prevents the reception of a session summary
message or session record.
Local Realm A local realm is the administrative domain providing services to a user.
An administrative domain MAY act as a local realm for certain users,
while being a home realm for others. Multi-session A multi-session
represents a logical linking of several sessions. Multi-sessions are
tracked by using the Acct-Multi-Session-Id. An example of a multi-
session would be a Multi-link PPP bundle. Each leg of the bundle would
be a session while the entire bundle would be a multi-session.
Network Access Identifier The Network Access Identifier, or NAI, is used in the Diameter protocol
to extract a user's identity and realm. The identity is used to identify the
user during authentication and/or authorization, while the realm is used
for message routing purposes.
Proxy Agent or Proxy In addition to forwarding requests and responses, proxies make policy
decisions relating to resource usage and provisioning. This is typically
accomplished by tracking the state of NAS devices. While proxies
typically do not respond to client Requests prior to receiving a
Response from the server, they may originate Reject messages in
cases where policies are violated. As a result, proxies need to
understand the semantics of the messages passing through them, and
may not support all Diameter applications.

Ltd
HUAWEI UGW9811
Realm The string in the NAI that immediately follows the '@' character. NAI
realm names are required to be unique, and are piggybacked on the
administration of the DNS namespace. Diameter makes use of the
realm, also loosely referred to as domain, to determine whether
messages can be satisfied locally, or whether they must be routed or
redirected. In RADIUS, realm names are not necessarily piggybacked
on the DNS namespace but may be independent of it.
Real-time Accounting Real-time accounting involves the processing of information on
resource usage within a defined time window. Time constraints are
typically imposed in order to limit financial risk.
Relay Agent or Relay Relays forward requests and responses based on routing-related AVPs
and realm routing table entries. Since relays do not make policy
decisions, they do not examine or alter non-routing AVPs. As a result,
relays never originate messages, do not need to understand the
semantics of messages or non-routing AVPs, and are capable of
handling any Diameter application or message type. Since relays make
decisions based on information in routing AVPs and realm forwarding
tables they do not keep state on NAS resource usage or sessions in
progress.
Redirect Agent Rather than forwarding requests and responses between clients and
servers, redirect agents refer clients to servers and allow them to
communicate directly. Since redirect agents do not sit in the forwarding
path, they do not alter any AVPs transiting between client and server.
Redirect agents do not originate messages and are capable of handling
any message type, although they may be configured only to redirect
messages of certain types, while acting as relay or proxy agents for
other types. As with proxy agents, redirect agents do not keep state
with respect to sessions or NAS resources.
Roaming Relationships Roaming relationships include relationships between companies and
ISPs, relationships among peer ISPs within a roaming consortium, and
relationships between an ISP and a roaming consortium.
Security Association A security association is an association between two endpoints in a
Diameter session which allows the endpoints to communicate with
integrity and confidentially, even in the presence of relays and/or
proxies.
Session A session is a related progression of events devoted to a particular
activity. Each application SHOULD provide guidelines as to when a
session begins and ends. All Diameter packets with the same Session-
Identifier are considered to be part of the same session.
Session state A stateful agent is one that maintains session state information, by
keeping track of all authorized active sessions. Each authorized session
is bound to a particular service, and its state is considered active either
until it is notified otherwise, or by expiration.
Sub-session A sub-session represents a distinct service (e.g., QoS or data
characteristics) provided to a given session. These services may
happen concurrently (e.g., simultaneous voice and data transfer during
the same session) or serially. These changes in sessions are tracked
with the Accounting-Sub-Session-Id.

Ltd
HUAWEI UGW9811
Transaction state The Diameter protocol requires that agents maintain transaction state,
which is used for failover purposes. Transaction state implies that upon
forwarding a request, the Hop-by-Hop identifier is saved; the field is
replaced with a locally unique identifier, which is restored to its original
value when the corresponding answer is received. The request's state
is released upon receipt of the answer. A stateless agent is one that
only maintains transaction state.
Translation Agent A translation agent is a stateful Diameter node that performs protocol
translation between Diameter and another AAA protocol, such as
RADIUS.
Transport Connection A transport connection is a TCP or SCTP connection existing directly
between two Diameter peers, otherwise known as a Peer-to-Peer
Connection.
Upstream Upstream is used to identify the direction of a particular Diameter
message from the access device towards the home server.
User The entity requesting or using some resource, in support of which a
Diameter client has generated a request.

Ltd
HUAWEI UGW9811
Gy Interface Specification C Acronyms and Abbreviations
Figure a.3 Acronyms and

Abbreviations
AAA Authentication, Authorization and Accounting

ABNF Augmented BNF for Syntax Specifications
AVP Attribute Value Pairs
BTI Base Time Interval
CDR Charging Data Record
CCFH Credit-Control-Failure-Handling
CTP Continuous Time Period
DCC Diameter Credit Control
DTP Discrete Time Period
FUI Final Unit Indication
GSU Granted Service Units
IP Internet Protocol
IT Inactivity Time
MSCC Multiple Services Credit Control
OCS Online Charging System
QCT Quota Consumption Time
QHT Quota Holding Time
RADIUS Remote Authentication Dial-In User Service
RG Rating Group
SCTP Stream Control Transmission Protocol
TCP Transmission Control Protocol
TLS Transport Layer Security
TQT Time Quota Threshold
USU Used Service Units

Ltd
HUAWEI UGW9811
Gy Interface Specification C Acronyms and Abbreviations
VQT Volume Quota Threshold

VSA Vendor Specific Attribute, Data Element in Radius
VT Validity Time

Ltd

HUAWEI UGW9811 V900R009C01 Gy Interface Specification PDF

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

HUAWEI UGW9811 V900R009C01 Gy Interface Specification PDF

Uploaded by

Copyright:

Available Formats

HUAWEI UGW9811

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue 01 (2011-10-31) Huawei Proprietary and Confidential i

About This Document

Alerts you to a high risk hazard that could, if not avoided,

Alerts you to a medium or low risk hazard that could, if not

Alerts you to a potentially hazardous situation that could, if not

Issue 01 (2011-10-31) Huawei Proprietary and Confidential ii

Issue 01 (2011-10-31) Huawei Proprietary and Confidential iii

About This Document.......................................................................ii

Issue 01 (2011-10-31) Huawei Proprietary and Confidential iv

1.1 Protocol Architecture

Figure a.1 Protocol Architecture of DCCA

1.2 Protocol Format

Figure a.1 Message head format

Issue 01 (2011-10-31) Huawei Proprietary and Confidential 1

 Version: This Version field MUST be set to 1 to indicate Diameter Version 1.

Figure a.2 Command Flag

− R(equest) - If set, the message is a request. If cleared, the message is an answer.

contained in the message.

1.2.2 Message List

Credit-Control-Request CCR 272

Credit-Control-Answer CCA 272

Re-Auth-Request RAR 258

Re-Auth-Answer RAA 258

Abort-Session-Request ASR 274

Abort-Session-Answer ASA 274

Device-Watchdog-Request DWR 280

Device-Watchdog-Answer DWA 280

Disconnect-Peer-Request DPR 282

Disconnect-Peer-Answer DPA 282

Capabilities-Exchange-Request CER 257

Capabilities-Exchange-Answer CEA 257

Issue 01 (2011-10-31) Huawei Proprietary and Confidential 3

1.2.3 AVP Head Format

Figure a.1 AVP head format

Issue 01 (2011-10-31) Huawei Proprietary and Confidential 4

1.2.4 AVP Data Formats

Issue 01 (2011-10-31) Huawei Proprietary and Confidential 5

Issue 01 (2011-10-31) Huawei Proprietary and Confidential 6

2.1 Online Charging Framework

Issue 01 (2011-10-31) Huawei Proprietary and Confidential 1

2.2 Basic principles

2.3 Charging Modes

Issue 01 (2011-10-31) Huawei Proprietary and Confidential 2

2.3.1 Immediate Event Charging

Exceptions and abnormal cases

Issue 01 (2011-10-31) Huawei Proprietary and Confidential 3

2.3.2 Event Charging with Reservation

Reserve Units Operation

2. CCR (INITIAL_REQUEST, RSU)

4. CCA (INITIAL_REQUEST, GSU, [VT])

Debit Units Operation

6. CCR (TERMINATION_REQUEST, USU)

7.. Perform Charging Control

8. CCA (TERMINATION_REQUEST, CI)

Issue 01 (2011-10-31) Huawei Proprietary and Confidential 4

Figure a.2 Online charging eECUR mode

Exceptions and abnormal cases:

Issue 01 (2011-10-31) Huawei Proprietary and Confidential 5

2.3.3 Session charging with Reservation