HUAWEI UGW9811 V900R009C01 Gy Interface Specification

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:

[email protected]

Issue 01 (2011-10-31)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd

i

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)


ii


Contents

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)


iii


Contents

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

Issue 01 (2011-10-31)


iv


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)


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 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 Issue 01 (2011-10-31)


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

Issue 01 (2011-10-31)


3



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. Issue 01 (2011-10-31)


4



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.

Issue 01 (2011-10-31)


5

HUAWEI UGW9811 Gy Interface Specification 


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.

Issue 01 (2011-10-31)


6



2

Interface Description

2.1 Online Charging Framework Figure a.1 Online charging framework

Issue 01 (2011-10-31)


1



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 :

Issue 01 (2011-10-31)


2



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

Issue 01 (2011-10-31)


3



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)

Issue 01 (2011-10-31)


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. Issue 01 (2011-10-31)


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 (enhancedECUR) mode, and the new ECUR without CC-Update interaction as sECUR(standardECUR).

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 Issue 01 (2011-10-31)


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

Issue 01 (2011-10-31)


7



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



OM Compulsory option defined by the operator



OC Condition optional option defined by the operator

Condition optional

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]

Issue 01 (2011-10-31)


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

Issue 01 (2011-10-31)


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 ]

For the specific definitions, refer to RFC 3588 “Diameter Base Protocol”. Issue 01 (2011-10-31)


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 >

Issue 01 (2011-10-31)


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 }

For the specific definitions, refer to RFC 3588 “Diameter Base Protocol”. Issue 01 (2011-10-31)


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 ]


Issue 01 (2011-10-31)


6



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 QoSInformation-AVP or for the EPS default bearer if provided within the Default-EPSBearer-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.

Issue 01 (2011-10-31)


7



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 Relay

0xffffffff

DCCA

4

3

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

Issue 01 (2011-10-31)


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

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

Issue 01 (2011-10-31)


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

Issue 01 (2011-10-31)


10



AVP name


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

Issue 01 (2011-10-31)


11


AVP name



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

Issue 01 (2011-10-31)


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

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

Issue 01 (2011-10-31)


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

AVP type

DiameterIdentity

Issue 01 (2011-10-31)


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

Issue 01 (2011-10-31)


15



AVP name

Envelope

Note: This AVP reports the start and end time of one time envelope using the Envelope-StartTime 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

Issue 01 (2011-10-31)


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 REPORT_ENVELOPES_WITH_EVENTS REPORT_ENVELOPES_WITH_VOLUME_AND_EVENTS

(2) (3) (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

Issue 01 (2011-10-31)


17



AVP name


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

Issue 01 (2011-10-31)


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

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 }

Issue 01 (2011-10-31)


19



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 ] [ CC-Output-Octets ] *[ AVP ]

Issue 01 (2011-10-31)


20



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. 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-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. 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-DL AVP name

Max-Requested-Bandwidth-DL

AVP code

515

AVP type

Unsigned32

Issue 01 (2011-10-31)


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-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 MultipleServices-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 Issue 01 (2011-10-31)


22


AVP name



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 ]

Issue 01 (2011-10-31)


23



3.2.43 Origin-Host AVP name

Origin-Host

AVP code

264

AVP type

DiameterIdentity

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

AVP type

DiameterIdentity

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

Issue 01 (2011-10-31)


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

Issue 01 (2011-10-31)


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-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. The following values are defined: PRE-EMPTION_VULNERABILITY_ENABLED (0) This value indicates that the resources assigned to the service data flow can be preempted 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

Issue 01 (2011-10-31)


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-Information AVP name

PS-Information

AVP code

874

AVP type

Grouped

Issue 01 (2011-10-31)


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-Information AVP name

PS-Furnish-Charging-Information

AVP code

865

AVP type

Grouped

Issue 01 (2011-10-31)


28


AVP name



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

Issue 01 (2011-10-31)


29



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) This value shall be used to indicate standardized characteristics associated with standardized QCI value 2 from 3GPP TS 23.203 [7]. QCI_3 (3) This value shall be used to indicate standardized characteristics associated with standardized QCI value 3 from 3GPP TS 23.203 [7]. QCI_4 (4) This value shall be used to indicate standardized characteristics associated with standardized QCI value 4 from 3GPP TS 23.203 [7]. QCI_5 (5) This value shall be used to indicate standardized characteristics associated with standardized QCI value 5 from 3GPP TS 23.203 [7]. QCI_6 (6) This value shall be used to indicate standardized characteristics associated with standardized QCI value 6 from 3GPP TS 23.203 [7]. QCI_7 (7) This value shall be used to indicate standardized characteristics associated with standardized QCI value 7 from 3GPP TS 23.203 [7]. QCI_8 (8) This value shall be used to indicate standardized characteristics associated with standardized QCI value 8 from 3GPP TS 23.203 [7]. QCI_9 (9) This value shall be used to indicate standardized characteristics associated with standardized QCI value 9 from 3GPP TS 23.203 [7].

The QCI values 0, 10 – 255 are divided for usage as follows: 0: Reserved 10-127: Reserved 128-254: Operator specific 255: Reserved

Issue 01 (2011-10-31)


30



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-RequestedBandwidth-DL AVP) or - an APN (when appearing at CCA or RAR command level with APN-Aggregate-MaxBitrate-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 3GPPGPRS 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 3GPPGPRS 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 GuaranteedBitrate-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 Issue 01 (2011-10-31)


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

Issue 01 (2011-10-31)


32



AVP name


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

Issue 01 (2011-10-31)


33



3.2.59 Refund-Information AVP 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-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 ServiceParameter-Info AVP). The Granted-Service-Unit AVP in the CreditControl-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 ServiceParameter-Info AVP). The Granted-Service-Unit AVP in the CreditControl-Answer command contains the refunded units.

Issue 01 (2011-10-31)


34



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

This value is used to indicate that the reason for usage reporting of all quota types of the Issue 01 (2011-10-31)


35



AVP name

Reporting-Reason

Multiple-Service-Credit-Control AVP where its appears is that a normal PDP context termination has happened. QUOTA_EXHAUSTED

3

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 quota has been exhausted. VALIDITY_TIME

4

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 credit authorization lifetime provided in the Validity-Time AVP has expired. OTHER_QUOTA_TYPE

5

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, for a multi-dimensional quota, one reached a trigger condition and the other quota is being reported. RATING_CONDITION_CHANGE

6

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

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 it is there has been a Server initiated re-authorization procedure, i.e. receipt of RAR command. POOL_EXHAUSTED

8

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

Issue 01 (2011-10-31)


36



AVP name


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 ] [ CC-Service-Specific-Units ]

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

Issue 01 (2011-10-31)


37



AVP name


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

Issue 01 (2011-10-31)


38



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:

[email protected]

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 ]

Issue 01 (2011-10-31)


39



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: ;;[;] Example for SPUD board. : Session create time in UTC format (seconds from 1900). : Slot and CPU number from 0~4095. : 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

Issue 01 (2011-10-31)


40


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

Issue 01 (2011-10-31)


41



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 UsedService-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-ServiceUnit 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

Issue 01 (2011-10-31)


42



AVP name

Termination-Cause

Note: It used to indicate the reason for the session termination of the Diameter client. The following values are defined: 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-CreditControl includes Granted-Service-Units and Granted-Service-Units includes CC-Time (the quota distributed is time quota), Multiple-Services-Credit-Control may include Time-QuotaThreshold. 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 TimeQuota-Threshold. During the reauthorization process, DCC client allows users to continue to use the service until the original quota is used up.

Issue 01 (2011-10-31)


43



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: ::= < AVP Header: 1264 > * [ Trigger-Type ]

Issue 01 (2011-10-31)


44



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 reauthorize to apply new quota. Trigger-Type must be used RATING_CONDITION_CHANGE.

when

the

Reporting-Reason

in

CCR

is

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-SpecificUnits (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 -QuotaThreshold. During the reauthorization process, DCC client allows users to continue to use the service until the original quota is used up.

Issue 01 (2011-10-31)


45



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 ] [ CC-Output-Octets ] [ CC-Service-Specific-Units ] *[ Event-Charging-TimeStamp ]

3.2.87 User-Equipment-Info AVP name

User-Equipment-Info

AVP code

458

AVP type

Grouped

Issue 01 (2011-10-31)


46



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

AVP type

OctetString

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 0

Bit2 0

Description IMEIV filled as BCD code.

1 0 by FF.

IMEIV filled as UTF8 string, for length 15 IMEIV, the last two bytes was filled

0 1 filled.

IMEIV filled as UTF8 string, for length 15 IMEIV, only the 15 valid bits will be

3.2.90 User-Name AVP name

User-Name

AVP code

1

AVP type

UTF8String

Issue 01 (2011-10-31)


47



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

Issue 01 (2011-10-31)


48



AVP name


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, CCInput-Octets or CC-Output-Octets (the quota distributed is volume quota), MultipleServices-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 VolumeQuota-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

Issue 01 (2011-10-31)


49



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

AVP type

OctetString

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

Issue 01 (2011-10-31)


50



AVP name


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.

Issue 01 (2011-10-31)


51



3.2.104 3GPP-MS-TimeZone AVP name

3GPP-MS-TimeZone

AVP code

23

AVP type

OctetString

Note: Time zone of the terminal.

3.2.105 3GPP-User-Location-Info AVP name

3GPP-User-Location-Info

AVP code

22

AVP type

OctetString

Note: User location identification.

3.2.106 3GPP-RAT-Type AVP name

3GPP-RAT-Type

AVP code

21

AVP type

OctetString

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 e

Must

Acct-Application-Id

259

M

Auth-Application-Id

258

Called-Station-Id

30

Issue 01 (2011-10-31)

May

Should

Must

May

not

not

Encr.

P

-

V

N

M

P

-

V

N

M

P

-

V

N


52



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


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


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


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


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


433

M

P

-

V

Y

Issue 01 (2011-10-31)


53



Redirect-Server

434

M

P

-

V

Y

Redirect-Server-Address

435

M

P

-

V

Y

Requested-Action

436

M

P

-

V

Y


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.

Issue 01 (2011-10-31)


54



3.3.2 3GPP Specific AVPs Figure a.2 3GPP Specific AVPs AVP Name

AVP

AVP Flag Rules

Cod e

Must

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

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

-

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


865

V,M

P

N

PS-Information

874

V,M

P

N


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

Time-Quota-Threshold

868

V,M

P

Time-Quota-Type

1271

V,M

P

Issue 01 (2011-10-31)


May

Should

Must

May

not

not

Encr.

-

-

N

N

　

N N

-

　

N

55



AVP Name

AVP

AVP Flag Rules

Trigger

V,M

P

N

Trigger-Type

Cod 1264 e 870

V,M

P

N

Unit-Quota-Threshold

1226

V,M

P


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


11

V,M

P

Y

3GPP-SGSN-MCC-MNC

18

V,M

P

Y

3GPP-User-Location-Info

22

V,M

P

Y

-

　

N

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

Issue 01 (2011-10-31)


56



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 command level

Traffic Behaviour

DIAMETER_SUCCESS (2001)

Depends on MSCC result code

DIAMETER_LIMITED_SUCCESS (2002)

Depends on MSCC result code

Specific result code

Behaviour Configurable for

Comment

Terminate with CCR-T Terminate without CCR-T Offline Failover All other result codes

Issue 01 (2011-10-31)

Default Behaviour


57



Figure a.4 List of typical result code

Issue 01 (2011-10-31)


58

CCA Result code on command level HUAWEI UGW9811 DIAMETER_MULTI_ROUND_ Gy Interface Specification AUTH(1001)

Traffic Behaviour Default Behaviour

Origin

Comme nt 3 Interface Definition RFC358 8


Depends on result code

MSCC

RFC358 8

DIAMETER_LIMITED_SUCCESS (2002)

Depends on result code

MSCC

RFC358 8

DIAMETER_COMMAND_

Default Behaviour

RFC358 8

DIAMETER_UNABLE_TO_DELIVE R (3002)

Failover

RFC358 8

DIAMETER_REALM_NOT_

Default Behaviour

RFC358 8

DIAMETER_TOO_BUSY (3004)

Failover

RFC358 8

DIAMETER_LOOP_DETECTED (3005)

Failover

RFC358 8

DIAMETER_REDIRECT_

Default Behaviour

RFC358 8

DIAMETER_APPLICATION_UNSU PPORTED (3007)

Default Behaviour

RFC358 8

DIAMETER_INVALID_HDR_BITS (3008)

Default Behaviour

RFC358 8

DIAMETER_INVALID_AVP_BITS (3009)

Default Behaviour

RFC358 8

DIAMETER_UNKNOWN_PEER (3010)

Failover

RFC358 8

DIAMETER_AUTHENTICATION_R EJECTED(4001)

Default Behaviour

RFC358 8

DIAMETER_OUT_OF_SPACE (4002)

Failover

RFC358 8

DIAMETER_ELECTION_LOST(400 3)

Default Behaviour

RFC358 8

DIAMETER_END_USER_

Default Behaviour

RFC400 6

DIAMETER_CREDIT_CONTROL_N OT_APPLICABLE (4011)

No credit control

RFC400 6

DIAMETER_CREDIT_LIMIT_REAC HED (4012)

Default Behaviour

RFC400 6

DIAMETER_AVP_UNSUPPORTED( 5001)

Default Behaviour

RFC358 8

DIAMETER_UNKNOWN_SESSION _ID (5002)

Terminate PDP no CCR

RFC358 8

UNSUPPORTED (3001)

SERVED(3003)

INDICATION(3006)

SERVICE_DENIED(4010)

DIAMETER_AUTHORIZATION_RE Terminate PDP CCR Issue 01 (2011-10-31)JECTED(5003) Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd

with

RFC358 8

After PDP context 59 activation procedure. Used Quota must be



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 MSCC

Traffic Behaviour


Allow Traffic

DIAMETER_LIMITED_SUCC ESS (2002)

Allow Traffic

Specific result code

Behaviour Configurable for Block Offline

Comment

Except “Terminate”, all behavoir will be done only on the service traffics of the Rating Group indicated in the MSCC.

Redirect Terminate All other result codes

Issue 01 (2011-10-31)

Default Behaviour


60



3.4.3 Final Unit Action on MSCC Level Figure a.6 Final Unit Action on MSCC level CCA Result code in MSCC

Final-UnitAction

Traffic

Comment


Terminate

Block

Traffic is blocked when quota is exhausted

Redirect

Redirection

Redirection is done when the quota is exhausted

Restrict-Access

RestrictAccess

Restrict-Access is done when quota is exhausted

Terminate

Block

Redirect

Redirection

Restrict-Access

RestrictAccess

Terminate

Default Behaviour

Redirect

Default Behaviour

Restrict-Access

Default Behaviour

DIAMETER_CREDIT_LIMIT _REACHED (4012)

All other result codes

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.

Issue 01 (2011-10-31)


61





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

Issue 01 (2011-10-31)


62



Figure a.3 Time Based Charging

Issue 01 (2011-10-31)


63



Figure a.4 Redirection when Balance Exhausted & Recharge Notification

Issue 01 (2011-10-31)


64



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. Issue 01 (2011-10-31)


65



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 GrantedService-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 DirectDebiting-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. Issue 01 (2011-10-31)


66



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-AuthRequest (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 reauthentication/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. Issue 01 (2011-10-31)


67



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.

Issue 01 (2011-10-31)


68



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

Issue 01 (2011-10-31)


69



Figure a.2 Failure Handling—Retry and Success

Issue 01 (2011-10-31)


70



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



OM Compulsory option defined by the operator



OC Condition optional option defined by the operator

Condition optional

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-- indicates detail information of AVPs for each DCC messages.

Issue 01 (2011-10-31)


71


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]

Issue 01 (2011-10-31)

Gy AVP Table.xls


72


B Glossary

Figure a.2

Glossary

AAA

Authentication, Authorization and Accounting.

Accounting

The act of collecting information on resource usage for the purpose of capacity planning, auditing, billing or cost allocation.

Accounting Record

An accounting record represents a summary of the resource consumption of a user over the entire session. Accounting servers 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).

Authorization

The act of determining whether a requesting entity (subject) will be allowed access to a resource (object).

AVP

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 encapsulate protocol-specific data (e.g., routing information) as well as authentication, authorization or accounting information.

Broker

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 by roaming consortiums. Depending on the business model, a broker may either choose to deploy relay agents or proxy agents.

Credit Pool

Credit pool is a mechanism to avoid the credit fragmentation introduced by credit reservation on OCS server. The OCS server allocates the 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.

Diameter Agent

A Diameter Agent is a Diameter node that provides either relay, proxy, redirect or translation services.

Diameter Client

A Diameter Client is a device at the edge of the network that performs access control. An example of a Diameter client is a Network Access Server (NAS) or a Foreign Agent (FA).

Diameter Node

A Diameter node is a host process that implements the Diameter protocol, and acts either as a Client, Agent or Server.

Diameter Peer

A Diameter Peer is a Diameter Node to which a given Diameter Node has a direct transport connection.

Issue 01 (2011-10-31)


73


B Glossary

Diameter Security Exchange

A Diameter Security Exchange is a process through which two Diameter nodes establish end-to-end security.

Diameter Server

A Diameter Server is one that handles authentication, authorization and accounting requests for a particular realm. By its very nature, a Diameter Server MUST support Diameter applications in addition to the base protocol.

Downstream

Downstream is used to identify the direction of a particular Diameter message from the home server towards the access device.

End-to-End Security

TLS and IPsec provide hop-by-hop security, or security across a transport connection. When relays or proxy are involved, this hop-byhop security does not protect the entire Diameter user session. End-toend 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.

Home Realm

A Home Realm is the administrative domain with which the user maintains an account relationship.

Home Server

See Diameter Server.

Interim accounting

An interim accounting message provides a snapshot of usage during a user's session. It is typically implemented in order to provide for partial 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 multisession 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.

Issue 01 (2011-10-31)


74


B Glossary

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

Issue 01 (2011-10-31)


75


B Glossary

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.

Issue 01 (2011-10-31)


76


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


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

Issue 01 (2011-10-31)


77


C Acronyms and Abbreviations

VQT

Volume Quota Threshold

VSA

Vendor Specific Attribute, Data Element in Radius

VT

Validity Time

Issue 01 (2011-10-31)


78

HUAWEI UGW9811 V900R009C01 Gy Interface Specification

Recommend Documents