HUAWEI UGW9811 V900R009C01 Gy Interface Specification

HUAWEI UGW9811V900R009C01

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.

NoticeThe 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 BaseBantian, LonggangShenzhen 518129People's Republic of China

Website: http://www.huawei.com

Email: [email protected]

Issue 01 (2011-10-31) Huawei Proprietary and Confidential Copyright Huawei Technologies Co.,

Ltd

i

HUAWEI UGW9811Gy Interface Specification Contents

About This Document

PurposeThis document describes the detailed specification of Gn reference point implemented in UGW9811.

Intended AudienceThis document is intended for:

Policy planning engineers Installation and commissioning engineers Technical support engineers

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


Ltd

ii


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


Ltd

iii


Contents

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


Ltd

iv

HUAWEI UGW9811Gy Interface Specification 3 Interface Definition

1 Protocol Definition1.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 Format1.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 |


Ltd

1


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 Flag0 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 messages.

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

2


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

3


1.2.3 AVP Head FormatThe 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

4


1.2.4 AVP Data FormatsThe 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

5


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

6


2 Interface Description2.1 Online Charging Framework

Figure a.1 Online charging framework


Ltd

1


2.2 Basic principlesAs 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 ModesIn 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

2


2.3.1 Immediate Event ChargingFigure 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 casesIf OCS rejects the resource request. In this case, the GW should disallows the service access..


Ltd

3


2.3.2 Event Charging with ReservationFigure a.1 Online charging sECUR mode

OCS GW

6. CCR (TERMINATION_REQUEST, USU)

8. CCA (TERMINATION_REQUEST, CI) 7.. Perform Charging Control

Debit Units Operation

2. CCR (INITIAL_REQUEST, RSU) 3. Perfor m Charging Control

1. Service Request

5. Service Delivery

Reserve Units Operation

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


Ltd

4


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

5


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

6


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

7


3 Interface Definition3.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:

::= < Diameter Header: 272, REQ, PXY >

{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

1


[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:

::= < Diameter Header: 272, PXY >

{Result-Code}{Origin-Host}{Origin-Realm}{Auth-Application-Id}{CC-Request-Type}{CC-Request-Number}[CC-Session-Failover]*[Multiple-Services-Credit-Control]


Ltd

2


[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:

::= < 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:

::= < Diameter Header: 258, PXY >< Session-Id >{ Result-Code }{ Origin-Host }{ Origin-Realm }[ User-Name ][ Origin-State-Id ]*[ AVP ]



Ltd

3


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:

::= < 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:

::= < Diameter Header: 280, REQ >


Ltd

4


{ 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:

::= < 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:

::= < 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:

::= < Diameter Header: 282 >{ Result-Code }{ Origin-Host }{ Origin-Realm }



Ltd

5


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:

::= < 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:

::= < 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

6


3.2 AVP Definition3.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-PriorityAVP 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-ULAVP 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

7


3.2.4 Auth-Application-IdAVP 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-IntervalAVP 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-IdentifierAVP 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-TypeAVP name CC-Request-Type

AVP code 416


Ltd

8


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 4An 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-NumberAVP 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-TimeAVP name CC-Time

AVP code 420

AVP type Unsigned32


Ltd

9


AVP name CC-Time

Note: This AVP defines the requested, allocated or used time in the unit of second.

3.2.10 CC-Total-OctetsAVP 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-OctetsAVP 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-OctetsAVP 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-UnitsAVP name CC-Service-Specific-Units

AVP code 417

AVP type Unsigned64


Ltd

10


AVP name CC-Service-Specific-Units

Note: Requested, allocated or used units (events identified and counted by the GW).

3.2.14 CC-Unit-TypeAVP 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 0TOTAL-OCTETS 2

3.2.15 Credit-Control-Failure-HandlingAVP name Credit-Control-Failure-Handling

AVP code 427

AVP type Enumerated


Ltd

11


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-AddressAVP name CG-Address

AVP code 846

AVP type IPAddress

Note; Charging Gateway IP address.

3.2.17 CC-Session-FailoverAVP name CC-Session-Failover

AVP code 418

AVP type Enumerated


Ltd

12


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 0When 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 1When 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-IdAVP 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-NameAVP 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-HostAVP name Destination-Host

AVP code 293


Ltd

13


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-HandlingAVP 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-RealmAVP name Destination-Realm

AVP code 283



Ltd

14


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-TimestampAVP 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-TimeStampAVP 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 EnvelopeAVP name Envelope

AVP code 1266

AVP type Grouped


Ltd

15


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-TimeAVP 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-TimeAVP 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-ReportingAVP name Envelope-Reporting

AVP code 1268

AVP type Enumerated


Ltd

16


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 ExponentAVP 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-IdAVP 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-IndicationAVP name Final-Unit-Indication

AVP code 430

AVP type Grouped


Ltd

17


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-ActionAVP name Final-Unit-Action

AVP code 449

AVP type Enumerated


Ltd

18


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 0DCC client must end service session. This is the default processing when DCC user terminal receives a Final-Unit-Action that is not supported.REDIRECT 1The service processing unit must redirect the user to the address that is designated in Redirect-Server-Address.RESTRICT_ACCESS 2The default behavior configured in GGSN will take effect.

3.2.33 G-S-U-Pool-ReferenceAVP 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

19


3.2.34 G-S-U-Pool-IdentifierAVP 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-AddressAVP name GGSN-Address

AVP code 847

AVP type IPAddress

Note: GGSN IP address.

3.2.36 Granted-Service-UnitAVP 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 ] [ CC-Output-Octets ] *[ AVP ]


Ltd

20


3.2.37 Guaranteed Bitrate-DLAVP 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-ULAVP 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. 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.39 Max-Requested-Bandwidth-ULAVP name Max-Requested-Bandwidth-UL

AVP code 516

AVP type Unsigned32

Note: The MaxBandwidth-UL AVP (AVP code 516) is of type Unsigned32, and it indicates the maximum requested bandwidth in bits per second for an uplink IP flow. The bandwidth contains all the overhead coming from the IP-layer and the layers above, e.g. IP, UDP, RTP and RTP payload.

3.2.40 Max-Requested-Bandwidth-DLAVP name Max-Requested-Bandwidth-DL

AVP code 515

AVP type Unsigned32


Ltd

21


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-IndicatorAVP 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-ControlAVP 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 users 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

22


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

23


3.2.43 Origin-HostAVP 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-RealmAVP name Origin-Realm

AVP code 296


Note: Home filed of the device on the start end.Example: huawei.com.

3.2.45 Origin-State-IdAVP 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-IdAVP name PDN-Connection-Id

AVP code 2050

AVP type Unsigned32


Ltd

24


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-AddressAVP 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-TypeAVP 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 PRIMARY1 SECONDARYThis AVP shall only be present in the CCR Initial.

3.2.49 Pre-emption-CapabilityAVP name Pre-emption-Capability

AVP code 1047

AVP type Enumerated


Ltd

25


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-VulnerabilityAVP 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. The following values are defined:PRE-EMPTION_VULNERABILITY_ENABLED (0)This value indicates that the resources assigned to the service data flow can be pre-empted and allocated to a service data flow with a higher priority level. This is the default value applicable if this AVP is not supplied.PRE-EMPTION_VULNERABILITY_DISABLED (1)This value indicates that the resources assigned to the service data flow shall not be pre-empted and allocated to a service data flow with a higher priority level.

3.2.51 Priority-LevelAVP name Priority-Level

AVP code 1046

AVP type Unsigned32


Ltd

26


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-InformationAVP name PS-Information

AVP code 874

AVP type Grouped


Ltd

27


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-InformationAVP name PS-Furnish-Charging-Information

AVP code 865

AVP type Grouped


Ltd

28


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-IdentifierAVP name QoS-Class-Identifier

AVP code 1028

AVP type Enumerated


Ltd

29


AVP name QoS-Class-IdentifierNote: 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

30


3.2.55 QoS-InformationAVP 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

31


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-TimeAVP 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-TimeAVP name Quota-Consumption-Time

AVP code 881

AVP type Unsigned32


Ltd

32


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

33


3.2.59 Refund-InformationAVP name Refund-Information

AVP code 2022

AVP type OctetString

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-ActionAVP 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 users 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 users 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

34


3.2.61 Result-CodeAVP 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-ReasonAVP 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 0This 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 1This 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 2This value is used to indicate that the reason for usage reporting of all quota types of the


Ltd

35


AVP name Reporting-Reason

Multiple-Service-Credit-Control AVP where its appears is that a normal PDP context termination has happened.QUOTA_EXHAUSTED 3This 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 quota has been exhausted.VALIDITY_TIME 4This 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 credit authorization lifetime provided in the Validity-Time AVP has expired.OTHER_QUOTA_TYPE 5This 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, for a multi-dimensional quota, one reached a trigger condition and the other quota is being reported.RATING_CONDITION_CHANGE 6This 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 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 7This 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 it is there has been a Server initiated re-authorization procedure, i.e. receipt of RAR command.POOL_EXHAUSTED 8This value is used to indicate that the reason for usage reporting of the particular quota type 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 indica

Documents

HUAWEI UGW9811 V900R009C01 Gy Interface Specification