167355118 HUAWEI UGW9811 V900R009C01 Gy Interface Specification

HUAWEI UGW9811V900R009C01

Gy Interface Specification

Issue 01

Date 2011-10-31

HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2011. All rights reserved.

No part of this document may be reproduced or transmitted in any form or by any means without prior written consent of Huawei Technologies Co., Ltd.

Trademarks and Permissions

and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.

All other trademarks and trade names mentioned in this document are the property of their respective holders.

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

mailto:[email protected]

http://www.huawei.com/

HUAWEI UGW9811Gy Interface Specification Contents

About This Document

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

Intended AudienceThis document is intended for:

Policy planning engineers

Installation and commissioning engineers

Technical support engineers

Symbol ConventionsThe symbols that may be found in this document are defined as follows.

Symbol Description

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

Alerts you to a medium or low risk hazard that could, if not avoided, result in moderate or minor injury.

Alerts you to a potentially hazardous situation that could, if not avoided, result in equipment damage, data loss, performance deterioration, or unanticipated results.

Provides a tip that may help you solve a problem or save time.

Provides additional information to emphasize or supplement important points in the main text.


Ltd

ii


Change HistoryChanges between document issues are cumulative. The latest document issue contains all the changes made in earlier issues.

Issue 01 (2011-10-31)

Initial field trial release.


Ltd

iii


Contents

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


Ltd

iv

HUAWEI UGW9811Gy Interface Specification 3 Interface Definition

1 Protocol Definition

1.1 Protocol ArchitectureThe 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 FormatThe message architecture of the Diameter protocol is shown in the following figure. These segments are sent in the order of network byte.

Figure a.1 Message head format

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Version | Message Length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| command flags | Command-Code |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Application-ID |


Ltd

1


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Hop-by-Hop Identifier |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| End-to-End Identifier |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| AVPs ...

+-+-+-+-+-+-+-+-+-+-+-+-+-

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

Message Length: The Message Length field is three octets and indicates the length of the Diameter message including the header fields.

Command flags: The Command Flags field is eight bits. The following bits are assigned:

Figure a.2 Command 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 messages.

− T(Potentially re-transmitted message)- This flag is set after a link failover procedure, to aid the removal of duplicate requests. It is set when resending requests not yet acknowledged, as an indication of a possible duplicate due to a link failure. This bit MUST be cleared when sending a request for the first time, otherwise the sender MUST set this flag. Diameter agents only need to be concerned about the number of requests they send based on a single received request; retransmissions by other entities need not be tracked. Diameter agents that receive a request with the T flag set, MUST keep the T flag set in the forwarded request. This flag MUST NOT be set if an error answer message (e.g., a protocol error) has been received for the earlier message. It can be set only in cases where no answer has been received from the server for a request and the request is sent again. This flag MUST NOT be set in answer messages.

− r(eserved) - these flag bits are reserved for future use, and MUST be set to zero, and ignored by the receiver.

Command-Code: The Command-Code field is three octets, and is used in order to communicate the command associated with the message. The 24-bit address space is managed by IANA. Command-Code values 16,777,214 and 16,777,215 (hexadecimal values FFFFFE -FFFFFF) are reserved for experimental use.

Application-ID: Application-ID is four octets and is used to identify to which application the message is applicable for. The application can be an authentication application, an accounting application or a vendor specific application. See Section for the possible values that the application-id may use.

The application-id in the header MUST be the same as what is contained in any relevant AVPs


Ltd

2


contained in the message.

Hop-by-Hop Identifier: The Hop-by-Hop Identifier is an unsigned 32-bit integer field (in network byte order) and aids in matching requests and replies. The sender MUST ensure that the Hop-by-Hop identifier in a request is unique on a given connection at any given time, and MAY attempt to ensure that the number is unique across reboots. The sender of an Answer message MUST ensure that the Hop-by-Hop Identifier field contains the same value that was found in the corresponding request. The Hop-by-Hop identifier is normally a monotonically increasing number, whose start value was randomly generated. An answer message that is received with an unknown Hop-by-Hop Identifier MUST be discarded.

End-to-End Identifier: The End-to-End Identifier is an unsigned 32-bit integer field (in network byte order) and is used to detect duplicate messages. Upon reboot implementations MAY set the high order 12 bits to contain the low order 12 bits of current time, and the low order 20 bits to a random value. Senders of request messages MUST insert a unique identifier on each message. The identifier MUST remain locally unique for a period of at least 4 minutes, even across reboots. The originator of an Answer message MUST ensure that the End-to-End Identifier field contains the same value that was found in the corresponding request. The End-to-End Identifier MUST NOT be modified by Diameter agents of any kind. The combination of the Origin-Host and this field is used to detect duplicates. Duplicate requests SHOULD cause the same answer to be transmitted, and MUST NOT affect any state that was set when the original request was processed. Duplicate answer messages that are to be locally consumed SHOULD be silently discarded.

AVPs: AVPs are a method of encapsulating information relevant to the Diameter message.

1.2.2 Message List

Figure a.1 Message List of DCCA

Command Name Acronym Command Code

Credit-Control-Request CCR 272

Credit-Control-Answer CCA 272

Re-Auth-Request RAR 258

Re-Auth-Answer RAA 258

Abort-Session-Request ASR 274

Abort-Session-Answer ASA 274

Device-Watchdog-Request DWR 280

Device-Watchdog-Answer DWA 280

Disconnect-Peer-Request DPR 282

Disconnect-Peer-Answer DPA 282

Capabilities-Exchange-Request CER 257

Capabilities-Exchange-Answer CEA 257


Ltd

3


1.2.3 AVP Head FormatThe segments in the AVP should be sent in the order of network byte. The AVP head format is shown in the following figure.

Figure a.1 AVP head format

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| AVP Code |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|V M P r r r r r| AVP Length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Vendor-ID (opt) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Data ...

+-+-+-+-+-+-+-+-+

AVP Code

The AVP Code, combined with the Vendor-Id field, identifies the attribute uniquely. AVP numbers 1 through 255 are reserved for backward compatibility with RADIUS, without setting the Vendor-Id field. AVP numbers 256 and above are used for Diameter, which are allocated by IANA.

AVP Flags

The AVP Flags field informs the receiver how each attribute must be handled. The 'r' (reserved) bits are unused and SHOULD be set to 0. Note that subsequent Diameter applications MAY define additional bits within the AVP Header, and an unrecognized bit SHOULD be considered an error. The 'P' bit indicates the need for encryption for end-to-end security.

The 'M' Bit, known as the Mandatory bit, indicates whether support of the AVP is required. If an AVP with the 'M' bit set is received by a Diameter client, server, proxy, or translation agent and either the AVP or its value is unrecognized, the message MUST be rejected. Diameter Relay and redirect agents MUST NOT reject messages with unrecognized AVPs.

AVPs with the 'M' bit cleared are informational only and a receiver that receives a message with such an AVP that is not supported, or whose value is not supported, MAY simply ignore the AVP.

The 'V' bit, known as the Vendor-Specific bit, indicates whether the optional Vendor-ID field is present in the AVP header. When set the AVP Code belongs to the specific vendor code address space.

Unless otherwise noted, AVPs will have the following default AVP

Flags field settings:

The 'M' bit MUST be set. The 'V' bit MUST NOT be set.

AVP Length

The AVP Length field is three octets, and indicates the number of octets in this AVP including the AVP Code, AVP Length, AVP Flags, Vendor-ID field (if present) and the AVP data. If a message is received with an invalid attribute length, the message SHOULD be rejected.


Ltd

4


1.2.4 AVP Data FormatsThe Data field is zero or more octets and contains information specific to the Attribute. The format and length of the Data field is determined by the AVP Code and AVP Length fields. The format of the Data field MUST be one of the following base data types.

OctetString

The data contains arbitrary data of variable length. Unless otherwise noted, the AVP Length field MUST be set to at least 8 (12 if the 'V' bit is enabled). AVP Values of this type that are not a multiple of four-octets in length is followed by the necessary padding so that the next AVP (if any) will start on a 32-bit boundary.

Integer32

32 bit signed value, in network byte order. The AVP Length field MUST be set to 12 (16 if the 'V' bit is enabled).

Integer64

64 bit signed value, in network byte order. The AVP Length field MUST be set to 16 (20 if the 'V' bit is enabled).

Unsigned32

32 bit unsigned value, in network byte order. The AVP Length field MUST be set to 12 (16 if the 'V' bit is enabled).

Unsigned64

64 bit unsigned value, in network byte order. The AVP Length field MUST be set to 16 (20 if the 'V' bit is enabled).

Float32

This represents floating point values of single precision as described by IEEE 754-1985. The 32-bit value is transmitted in network byte order. The AVP Length field MUST be set to 12 (16 if the 'V' bit is enabled).

Float64

This represents floating point values of double precision as described by IEEE 754-1985. The 64-bit value is transmitted in network byte order. The AVP Length field MUST be set to 16 (20 if the 'V' bit is enabled).

Grouped

The Data field is specified as a sequence of AVPs. Each of these AVPs follows - in the order in which they are specified - including their headers and padding. The AVP Length field is set to 8 (12 if the 'V' bit is enabled) plus the total length of all included AVPs, including their headers and padding. Thus the AVP length field of an AVP of type Grouped is always a multiple of 4.

Address

The Address format is derived from the OctetString AVP Base Format. It is a discriminated union, representing, for example a 32-bit (IPv4) or 128-bit (IPv6) address, most significant octet first. The first two octets of the Address AVP represent the AddressType, which contains an Address Family defined in IANAADFAM. The AddressType is used to discriminate the content and format of the remaining octets.


Ltd

5


Time

The Time format is derived from the OctetString AVP Base Format. The string MUST contain four octets, in the same format as the first four bytes are in the NTP timestamp format. This represents the number of seconds since 0h on 1 January 1900 with respect to the Coordinated Universal Time (UTC). On 6h 28m 16s UTC, 7 February 2036 the time value will overflow. SNTP describes a procedure to extend the time to 2104.This procedure MUST be supported by all DIAMETER nodes.

UTF8String

The UTF8String format is derived from the OctetString AVP Base Format. This is a human readable string represented using the ISO/IEC IS 10646-1 character set, encoded as an OctetString using the UTF-8 transformation format described in RFC 2279.

DiameterIdentity

The DiameterIdentity format is derived from the OctetString AVP Base Format.

DiameterIdentity = FQDN

DiameterIdentity value is used to uniquely identify a Diameter node for purposes of duplicate connection and routing loop detection.

The contents of the string MUST be the FQDN of the Diameter node. If multiple Diameter nodes run on the same host, each Diameter node MUST be assigned a unique DiameterIdentity. If a Diameter node can be identified by several FQDNs, a single FQDN should be picked at startup, and used as the only DiameterIdentity for that node, whatever the connection it is sent on.

Enumerated

Enumerated is derived from the Integer32 AVP Base Format. The definition contains a list of valid values and their interpretation and is described in the Diameter application introducing the AVP.


Ltd

6


2 Interface Description

2.1 Online Charging Framework

Figure a.1 Online charging framework


Ltd

1


2.2 Basic principlesAs described in 3GPP, there are two sub-functions for online charging that affect online charging: rating and unit determination. Both rating and unit determination can be implemented centralized, i.e. on the OCS, or decentralized, that is, on the GW.

Unit determination refers to the calculation of the number of non-monetary units (service units, data volume, time and events) that shall be assigned prior to starting service delivery.

Rating refers to the calculation of a price out of the non-monetary units calculated by the unit determination function.

For Huawei GW, only centralized mode is supported, and GW focus on packet inspections and categorise and control traffic flows according to charging rules either from local configuration or policy server(i.e. PCRF, AAA, etc)

So basic behavior on OCS and GW is described below:

OCS determines the number of non-monetary units that a certain service user can consume based on a rating group / service identifier received from the GW

After checking the service user's account balance, the OCS returns the number of granted units to the GW. GW is then responsible for the supervision of service delivery. Particularly, the GW shall limit service delivery to the corresponding number of granted units.

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


Ltd

2


2.3.1 Immediate Event Charging

Figure a.1 Online charging IEC mode

In IEC mode, GW identify charging event first and then forwards the charging event to the OCS;

Then OCS determines the value of the requested resource usage and debits this value from the subscriber account immediately and response the resource usage to GW to authorise this charging event request.

GW executes the resource usage according to the user request and the OCS authorisation.

After completion of the resource usage, if the service access failed, GW informs OCS accordingly about the failure to refund the corresponding quota to the subscriber account immediately

Exceptions and abnormal cases

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


Ltd

3


2.3.2 Event Charging with Reservation

Figure a.1 Online charging sECUR mode

OCS GW

6. CCR (TERMINATION_REQUEST, USU)

8. CCA (TERMINATION_REQUEST, CI)

7.. Perform Charging Control

Debit Units Operation

2. CCR (INITIAL_REQUEST, RSU)

3. Perfor m Charging Control

1. Service Request

5. Service Delivery

Reserve Units Operation

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


Ltd

4


Figure a.2 Online charging eECUR mode

In ECUR mode, GW identify charging event first and then forwards the charging event to the OCS; Then OCS determines the value of the requested resource usage and reserves this value from the subscriber account;

The OCS response the resource usage to GW to authorise this charging event request.

GW executes the resource usage according to the user request and the OCS authorisation.

After completion (or failure) of the resource usage, the GW informs the OCS accordingly about the completion or failure;

In line with the result report from the GW, the OCS either debits the reserved amount from the subscriber account (success), or it refund the unused amount back to the subscriber account (failure).

Exceptions and abnormal cases:

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

For ECUR mode, 3GPP defination changes between 2005 and 2006 releases. In old defination, ECUR mode has CC-Update interaction, which was delete in new Release in 2006.


Ltd

5


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

2.3.3 Session charging with Reservation

Figure a.1 Online charging SCUR mode

In SCUR mode Session based online charging always involves reservation within the credit control procedure (SCUR), as there is no way for the OCS to predict the amount of resource usage that occurs during the user session.

To begin with, the GW forward generates a charging chargeable event that corresponds to the resource usage request and maps onto the user session, and forwards it to the OCS. In the OCS, the online charging session is started and a certain amount quota reserved from the user subscriber account. This amount is determined by the OCS based on the information reported with the charging event and on local configuration, i.e. operator policy.

Further charging events are sent from the GW to the OCS upon the detection of further chargeable events within the session .e.g. the expiry of in intervals configured on the GW or instructed by the OCS, or when the authorised quota expires, or when session characteristics


Ltd

6


change (e.g. change of QoS of a PDP context). The OCS then furnishes a new quota to the GW as required, or rejects the charging event, e.g. due to exhaust of credit on the subscriber account.

As described above about the three modes of online charging, SCUR is the basic online charging mode mostly used for volume / time based charging, which interactive with OCS in a single DCC session.ECUR / IEC is an additional mode to handle event based charging, which interactive with OCS in another DCC session different with SCUR session.

For event based charging, IEC mode is recommended because of saving lots of signaling normally ( most service access could be success and saves signaling for refund quota).


Ltd

7


3 Interface Definition

3.1 Message Format DefinitionIn the following statement, "<>" means that it is compulsory and should be in the beginning of the message, "{}" means that it is compulsory, "[]" means that it is optional, and "*[]" means that the option can be repeated.

M Compulsory

C Condition optional

OM Compulsory option defined by the operator

OC Condition optional option defined by the operator

3.1.1 Credit-Control-Request (CCR)The Credit-Control-Request message (CCR) is indicated by the command-code field being set to 272 and the 'R' bit being set in the Command Flags field. It is used between the Diameter credit-control client and the credit-control server to request credit authorization for a given service.

Message format:

<Credit-Control-Request> ::= < Diameter Header: 272, REQ, PXY >

<Session-Id>

{Origin-Host}

{Origin-Realm}

{Destination-Realm}

{Auth-Application-Id}

{Service-Context-Id}

{CC-Request-Type}

{CC-Request-Number}

[Requested-Action]

[Destination-Host]

[User-Name]

[Origin-State-Id]

[Event-Timestamp]

*[Subscription-Id]

[Termination-Cause]

[Multiple-Services-Indicator]

*[Multiple-Services-Credit Control]


Ltd

1


[User-Equipment-Info]

[Service-Information]

*[AVP]

The PS-Information AVP is shown below:

Service-Information :: = < AVP Header: 873>

[ PS-Information ]

[ 3GPP-Charging-Id ]

[ 3GPP-PDP-Type ]

*[ PDP-Address ]

[ 3GPP-GPRS-Negotiated-QoS-Profile ]

[ SGSN-Address ]

[ GGSN-Address ]

[ CG-Address ]

[ 3GPP-IMSI-MCC-MNC ]

[ 3GPP-GGSN- MCC-MNC ]

[ 3GPP-NSAPI ]

[ Called-Station-Id ]

[ 3GPP-Session-Stop-Indicator ]

[ 3GPP-Selection-Mode ]

[ 3GPP-Charging-Characteristics ]

[ 3GPP-SGSN-MCC-MNC ]

[ 3GPP-MS-TimeZone ]

[ Charging-Rule-Base-Name ]

[ 3GPP-User-Location-Info ]

[ 3GPP-RAT-Type ]

[ PS-Furnish-Charging-Information ]

[ PDP-Context-Type ]

[ PDN-Connection-ID]

[ Serving-Node-Type]

[ Start-Time ]

[ Stop-Time ]

3.1.2 Credit-Control-Answer (CCA)The Credit-Control-Answer message (CCA) is indicated by the command-code field being set to 272 and the 'R' bit being cleared in the Command Flags field. It is used between the credit-control server and the Diameter credit-control client to acknowledge a Credit-Control-Request command.

Message Format:

<Credit-Control-Answer> ::= < Diameter Header: 272, PXY >

<Session-Id>

{Result-Code}

{Origin-Host}

{Origin-Realm}

{Auth-Application-Id}

{CC-Request-Type}

{CC-Request-Number}

[CC-Session-Failover]

*[Multiple-Services-Credit-Control]


Ltd

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:

<Re-Auth-Request> ::= < Diameter Header: 258, REQ, PXY >

< Session-Id >

{ Origin-Host }

{ Origin-Realm }

{ Destination-Realm }

[ Destination-Host ]

{ Auth-Application-Id }

{ Re-Auth-Request-Type }

[ User-Name ]

[ G-S-U-Pool-Identifier ]

[ Origin-State-Id ]

[ Rating-Group ]

[Service-Identifier]

*[ AVP ]

For the specific definitions, refer to RFC 3588 “Diameter Base Protocol”.

3.1.4 Re-Auth-Answer(RAA)The Re-Auth-Answer (RAA), indicated by the Command-Code set to 258 and the message flags' 'R' bit clear, is sent in response to the RAR. The Result-Code AVP MUST be present, and indicates the disposition of the request.

A successful RAA message MUST be followed by an application-specific authentication and/or authorization message.

Message Format:

<Re-Auth-Answer> ::= < Diameter Header: 258, PXY >

< Session-Id >

{ Result-Code }

{ Origin-Host }

{ Origin-Realm }

[ User-Name ]

[ Origin-State-Id ]

*[ AVP ]



Ltd

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:

<Abort-Session-Request> ::= < Diameter Header: 274, REQ, PXY >

< Session-Id >

{ Origin-Host }

{ Origin-Realm }

{ Destination-Realm }

{ Destination-Host }

{ Auth-Application-Id }

[ User-Name ]

[ Origin-State-Id ]

*[ AVP ]


3.1.6 Abort-Session-Answer(ASA)The Abort-Session-Answer (ASA), indicated by the Command-Code set to 274 and the message flags' 'R' bit clear, is sent in response to the ASR. The Result-Code AVP MUST be present, and indicates the disposition of the request.

If the session identified by Session-Id in the ASR was successfully terminated, Result-Code is set to DIAMETER_SUCCESS. If the session is not currently active, Result-Code is set to DIAMETER_UNKNOWN_SESSION_ID. If the access device does not stop the session for any other reason, Result-Code is set to DIAMETER_UNABLE_TO_COMPLY.

Message Format:

< Abort-Session-Answer> ::= < Diameter Header: 274, PXY >

< Session-Id >

{ Result-Code }

{ Origin-Host }

{ Origin-Realm }

[ User-Name ]

[ Origin-State-Id ]

*[ AVP ]


3.1.7 Device-Watchdog-Request(DWR)The Device-Watchdog-Request (DWR), indicated by the Command-Code set to 280 and the Command Flags' 'R' bit set, is sent to a peer when no traffic has been exchanged between two peers (see Section 5.5.3). Upon detection of a transport failure, this message MUST NOT be sent to an alternate peer.

Message Format:

<Device-Watchdog-Request> ::= < Diameter Header: 280, REQ >


Ltd

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:

<DWA> ::= < Diameter Header: 280 >

{ Result-Code }

{ Origin-Host }

{ Origin-Realm }

[ Original-State-Id ]


3.1.9 Disconnect-Peer-Request(DPR)The Disconnect-Peer-Request (DPR), indicated by the Command-Code set to 282 and the Command Flags' 'R' bit set, is sent to a peer to inform its intentions to shutdown the transport connection. Upon detection of a transport failure, this message MUST NOT be sent to an alternate peer.

Message Format:

<DPR> ::= < Diameter Header: 282, REQ >

{ Origin-Host }

{ Origin-Realm }

{ Disconnect-Cause }


3.1.10 Disconnect-Peer-Answer(DPA)The Disconnect-Peer-Answer (DPA), indicated by the Command-Code set to 282 and the Command Flags' 'R' bit cleared, is sent as a response to the Disconnect-Peer-Request message. Upon receipt of this message, the transport connection is shutdown.

Message Format:

<DPA> ::= < Diameter Header: 282 >

{ Result-Code }

{ Origin-Host }

{ Origin-Realm }



Ltd

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:

<CER> ::= < Diameter Header: 257, REQ >

{ Origin-Host }

{ Origin-Realm }

1*{ Host-IP-Address }

{ Vendor-Id }

{ Product-Name }

[ Origin-State-Id ]

*[ Auth-Application-Id ]

*[ Vendor-Specific-Application-Id ]

[ Firmware-Revision ]

[ Inband-Security-Id ]

*[ AVP ]


3.1.12 Capabilities-Exchange-Answer (CEA)The Capabilities-Exchange-Answer (CEA), indicated by the Command-Code set to 257 and the Command Flags' 'R' bit cleared, is sent in response to a CER message.

Message Format:

<CEA> ::= < Diameter Header: 257 >

{ Result-Code }

{ Origin-Host }

{ Origin-Realm }

1*{ Host-IP-Address }

{ Vendor-Id }

{ Product-Name }

[ Origin-State-Id ]

*[ Supported-Vendor-Id ]

*[ Auth-Application-Id ]

[ Firmware-Revision ]

*[ AVP ]



Ltd

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

AVP Format:

Allocation-Retention-Priority ::= < AVP Header: 1034 >{Priority-Level}

[Pre-emption-Capability] [Pre-emption-Vulnerability]

3.2.3 APN-Aggregated-Max-Bitrate-UL

AVP name APN-Aggregated-Max-Bitrate-UL

AVP code 1041

AVP type Unsigned32

Note: The APN-Aggregated-Max-Bitrate-UL AVP (AVP code 1041) is of type Unsigned32, and it indicates the maximum aggregate bit rate in bits per seconds for the uplink direction across all non-GBR bearers related with the same APN.


Ltd

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 3

Relay 0xffffffff

DCCA 4

3.2.5 Base-Time-Interval

AVP name Base-Time-Interval

AVP code 1265

AVP type Unsigned32

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

3.2.6 Bearer-Identifier

AVP name Bearer-Identifier

AVP code 1020

AVP type OctetString

Note: The Bearer-Identifier AVP (AVP code 1020) is of type OctetString, and it indicates the bearer to which specific information refers.

When present within a CC-Request Diameter command, subsequent AVPs within the CC-Request refer to the specific bearer identified by this AVP.

The bearer identifier of an IP CAN bearer shall be unique within the corresponding IP CAN session. The bearer identifier shall be selected by the PCEF.

3.2.7 CC-Request-Type

AVP name CC-Request-Type

AVP code 416


Ltd

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 Credit-Control-Request message when CC-Request-Type is set to EVENT_REQUEST.

3.2.8 CC-Request-Number

AVP name CC-Request-Number

AVP code 415

AVP type Unsigned32

Note: The CC-Request-Number AVP (AVP Code 415) is of type Unsigned32 and identifies this request within one session. As Session-Id AVPs are globally unique, the combination of Session-Id and CC-Request-Number AVPs is also globally unique and can be used in matching credit-control messages with confirmations.

Set the value to 0 for a credit-control request of type INITIAL_REQUEST and EVENT_REQUEST and to set the value to 1 for the first UPDATE_REQUEST, to 2 for the second, and so on until the value for TERMINATION_REQUEST is one more than for the last UPDATE_REQUEST.

3.2.9 CC-Time

AVP name CC-Time

AVP code 420

AVP type Unsigned32


Ltd

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


Ltd

10


AVP name CC-Service-Specific-Units

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

3.2.14 CC-Unit-Type

AVP name CC-Unit-Type

AVP code 454

AVP type Enumerated

The CC-Unit-Type AVP (AVP Code 454) is of type Enumerated and specifies the type of units considered to be pooled into a credit pool.

The following values are supported for the CC-Unit-Type AVP:

TIME 0

TOTAL-OCTETS 2

3.2.15 Credit-Control-Failure-Handling

AVP name Credit-Control-Failure-Handling

AVP code 427

AVP type Enumerated


Ltd

11


AVP name Credit-Control-Failure-Handling

Note: when the CC message sent from the client to the server fails temporarily because of network failure, CC client uses the information in this AVP to decide how to do. When CC server cannot charge in the service because of different service logic, it can command the client to end the service immediately or switch to the standby server.

The following values are defined by this AVP:

TERMINATE 0

When the Credit-Control-Failure-Handling AVP is set to TERMINATE, the service MUST only be granted for as long as there is a connection to the credit-control server. If the credit-control client does not receive any Credit-Control-Answer message within the Tx timer, the credit-control request is regarded as failed, and the end user's service session is terminated.

This is the default behavior if the AVP isn't included in the reply from the authorization or credit-control server.

CONTINUE 1

When the Credit-Control-Failure-Handling AVP is set to CONTINUE, the credit-control client SHOULD re-send the request to an alternative server in the case of transport or temporary failures, provided that a failover procedure is supported in the credit-control server and the credit-control client, and that an alternative server is available. Otherwise, the service SHOULD be granted, even if credit-control messages can't be delivered.

RETRY_AND_TERMINATE 2

When the Credit-Control-Failure-Handling AVP is set to RETRY_AND_TERMINATE, the credit-control client SHOULD re-send the request to an alternative server in the case of transport or temporary failures, provided that a failover procedure is supported in the credit-control server and the credit-control client, and that an alternative server is available. Otherwise, the service SHOULD not be granted when the credit-control messages can't be delivered.

3.2.16 CG-Address

AVP name CG-Address

AVP code 846

AVP type IPAddress

Note; Charging Gateway IP address.

3.2.17 CC-Session-Failover

AVP name CC-Session-Failover

AVP code 418

AVP type Enumerated


Ltd

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


Ltd

13


AVP name Destination-Host

AVP type DiameterIdentity

Note: Device ID on the destination end. The global network allocates it centrally. Different Diameter peers should be unique.

It should appear in the request message but cannot appear in the response message.

Example: ocs001.huawei.com.

3.2.21 Direct-Debiting-Failure-Handling

AVP name Direct-Debiting-Failure-Handling

AVP code 428

AVP type Enumerated

Note: This AVP will only be used in IEC mode. The credit-control client uses information in this AVP to decide what to do if sending credit-control messages (Requested-Action AVP set to DIRECT_DEBITING) to the credit-control server has been, for instance, temporarily prevented due to a network problem.

TERMINATE_OR_BUFFER 0

When the Direct-Debiting-Failure-Handling AVP is set to TERMINATE_OR_BUFFER, the service MUST be granted for as long as there is a connection to the credit-control server. If the credit-control client does not receive any Credit-Control-Answer message within the Tx timer, the credit-control request is regarded as failed. The client SHOULD terminate the service if it can determine from the failed answer that units have not been debited.

This is the default behavior if the AVP isn't included in the reply from the authorization server.

CONTINUE 1

When the Direct-Debiting-Failure-Handling AVP is set to CONTINUE, the service SHOULD be granted, even if credit-control messages can't be delivered, and the request should be deleted.

3.2.22 Destination-Realm

AVP name Destination-Realm

AVP code 283



Ltd

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


Ltd

15


AVP name Envelope

Note: This AVP reports the start and end time of one time envelope using the Envelope-Start-Time and Envelope-End-Time AVPs.

Envelope ::= < AVP Header: 1266>

{ Envelope-Start-Time }

[ Envelope-End-Time ]

[ CC-Total-Octets ]

[ CC-Input-Octets ]

[ CC-Output-Octets ]

[ CC-Service-Specific-Units ]

*[ AVP ]

3.2.26 Envelope-Start-Time

AVP name Envelope-Start-Time

AVP code 1269

AVP type Time

Note: This AVP is set to the time of the packet of user data which caused the time envelope to start.

3.2.27 Envelope-End-Time

AVP name Envelope-End-Time

AVP code 1267

AVP type Time

Note: This AVP is set to the time of the end of the time envelope.

3.2.28 Envelope-Reporting

AVP name Envelope-Reporting

AVP code 1268

AVP type Enumerated


Ltd

16


AVP name Envelope-Reporting

Note: This AVP is used in the CCA (INITIAL) to indicate whether the client shall report the start and end of each time envelope, in those cases in which quota is consumed in envelopes.

It can take the values:

DO_NOT_REPORT_ENVELOPES (0)

REPORT_ENVELOPES (1)

REPORT_ENVELOPES_WITH_VOLUME (2)

REPORT_ENVELOPES_WITH_EVENTS (3)

REPORT_ENVELOPES_WITH_VOLUME_AND_EVENTS (4)

If this AVP is not included in the CCA (INITIAL) then the client shall not report the individual envelopes.

3.2.29 Exponent

AVP name Exponent

AVP code 429

AVP type Integer32

Note: Exponent AVP is of type Integer32 (AVP Code 429) and contains the exponent value to be applied for the Value-Digit AVP within the Unit-Value AVP.

The Exponent AVP should always be zero, or should be absent within the Unit-Value AVP.

3.2.30 Filter-Id

AVP name Filter-Id

AVP code 11

AVP type UTF8String

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

3.2.31 Final-Unit-Indication

AVP name Final-Unit-Indication

AVP code 430

AVP type Grouped


Ltd

17


AVP name Final-Unit-Indication

Note: It indicated in the CCA message or AA answers the number of the final units included in Granted-Service-Unit. When these units are used up, the DCC client executes the actions designated in Final-Unit-Action.

If multiple service types are received in CCA, the service unit type that is first used up causes the DCC client to execute the designated actions.

At the first interworking, if Final-Unit-Action is REDIRECT or RESTRICT_ACCESS, CCA or AA answer may not include Granted-Service-Unit, and this indicates that DCC client executes the designated actions immediately. If the home service provider's policy provision is to end the service, the server should return proper temporary failure to activate the action designated by the policy.

Final-Unit-Action defines the action executed by service processing node when the user account balance is not enough to pay for the service charge. If Final-Unit-Indication exists, Final-Unit-Action must also exist.

If Final-Unit-Action is configured as TERMINATE, other AVPs in the Final-Unit-Indication AVP group must not appear.

If Final-Unit-Action is configured as REDIRECT, Redirect-Server must appear. If users are allowed to access to other services that cannot be got through Redirect-Server designating address, Restriction-Filter-Rule or Filter-Id can be portable in the CCA message.

If Final-Unit-Action is configured as RESTRICT_ACCESS, the default behavior configured in GGSN will take effect.

Filter-Id AVP can be used to refer to the IP filter list established on access device by other non-DCC application, for example, home configuration and other entity configuration.

Final-Unit-Indication AVP is an AVP group. The ABNF grammars are as follows:

Final-Unit-Indication ::= < AVP Header: 430 >

{ Final-Unit-Action }

*[ Restriction-Filter-Rule ]

*[ Filter-Id ][ Redirect-Server ]

3.2.32 Final-Unit-Action

AVP name Final-Unit-Action

AVP code 449

AVP type Enumerated


Ltd

18


AVP name Final-Unit-Action

Note: It indicates the action when the user account balance is not enough to pay for the service charge.

Final-Unit-Action defines following values:

TERMINATE 0

DCC client must end service session. This is the default processing when DCC user terminal receives a Final-Unit-Action that is not supported.

REDIRECT 1

The service processing unit must redirect the user to the address that is designated in Redirect-Server-Address.

RESTRICT_ACCESS 2

The default behavior configured in GGSN will take effect.

3.2.33 G-S-U-Pool-Reference

AVP name G-S-U-Pool-Reference

AVP code 457

AVP type Grouped

NOTE: The G-S-U-Pool-Reference AVP (AVP Code 457) is of type Grouped. It is used in the Credit-Control-Answer message, and associates the Granted-Service-Unit AVP within the Multiple-Services-Credit-Control AVP within which it appears with a credit pool within the session.

The G-S-U-Pool-Identifier AVP specifies the credit pool from which credit is drawn for this unit type. It should be an unsigned integer within the range from 0 to 2^32-2.

The CC-Unit-Type AVP specifies the type of units for which credit is pooled. It can only be TOTAL-OCTETS or TIME.

The Unit-Value AVP specifies the multiplier, which converts between service units of type CC-Unit-Type and abstract service units within the credit pool (and thus to service units of any other service or rating group associated with the same pool). The Unit-Value AVP should be within the range from 1 to 2^32-1.

Only quotas of the same unit type can be linked to one credit pool, for example the volume quotas could be pooled in one pool, while the time quota should be allocated to a different pool. If time quotas are pooled in one credit pool, the quota consumption mechanism of the services should be the same,

The G-S-U-Pool-Reference AVP is defined as follows:

G-S-U-Pool-Reference::= < AVP Header: 457 >

{ G-S-U-Pool-Identifier }

{ CC-Unit-Type }

{ Unit-Value }


Ltd

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 ]


*[ AVP ]


Ltd

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


Ltd

21


AVP name Max-Requested-Bandwidth-DL

Note: The Max-Requested-Bandwidth-DL AVP (AVP code 515) is of type Unsigned32, and it indicates the maximum bandwidth in bits per second for a downlink IP flow. The bandwidth contains all the overhead coming from the IP-layer and the layers above, e.g. IP, UDP, RTP and RTP payload.

3.2.41 Multiple-Services-Indicator

AVP name Multiple-Services-Indicator

AVP code 455

AVP type Enumerated

Note: Multiple services Indicator. It is used to indicate whether the DCC client has the capability to deal with multiple services independently in a (sub) session. Omitting this AVP means not supporting multiple services.

If the DCC server does not support independent multiple service credit control, then this AVP should be regarded as invalid.

For the same session, the client only needs to use this AVP in the first query.

The following values are defined in the Multiple-Services-Indicator AVP:

MULTIPLE_SERVICES_NOT_SUPPORTED 0

The client does not support independent multiple service credit control in one (sub) session.

MULTIPLE_SERVICES_SUPPORTED 1

The client supports independent multiple service credit control in one (sub) session.

3.2.42 Multiple-Services-Credit-Control

AVP name Multiple-Services-Credit-Control

AVP code 456

AVP type Grouped

Note: It contains the related AVP of multiple service independent credit control. Each instance contains one or more services, or a unit related with Rating-Group.

The Service-Identifier and the Rating-Group AVP are used to associate the granted units to a given service or rating group. If only the Rating-Group AVP is present, the Multiple-Services-Credit-Control AVP relates to all the services that belong to the specified rating group. Note: Rating Group is mandatory for Multiple-Services-Credit-Control.

The Requested-Service-Unit AVP MAY contain the amount of requested service units or the requested monetary value. It MUST be present in the initial interrogation and within the intermediate interrogations in which new quota is requested. If the credit-control client does not include the Requested-Service-Unit AVP in a request command, because for instance, it has determined that the end-user terminated the service, the server MUST debit the used amount from the user’s account but MUST NOT return a new quota in the corresponding answer. The Validity-Time, Result-Code, and Final-Unit-Indication AVPs MAY be present in


Ltd

22


AVP name Multiple-Services-Credit-Control

an answer command for the graceful service termination.

When both the Tariff-Time-Change and Tariff-Change-Usage AVPs are present, the server MUST include two separate instances of the Multiple-Services-Credit-Control AVP with the Granted-Service-Unit AVP associated to the same rating-group. Where the two quotas are associated to the same pool or to different pools. The Tariff-Change-Usage AVP MUST NOT be included in request commands to report used units before, and after tariff time change the Used-Service-Unit AVP MUST be used.

A server not implementing the independent credit-control of multiple services functionality MUST treat the Multiple-Services-Credit-Control AVP as an invalid AVP.

The G-S-U-Pool-Reference AVP allows the server to specify a G-S-U-Pool-Identifier identifying a credit pool within which the units of the specified type are considered pooled. If a G-S-U-Pool-Reference AVP is present, then actual service units of the specified type MUST also be present. For example, if the G-S-U-Pool-Reference AVP specifies Unit-Type TIME, then the CC-Time AVP MUST be present.

Multiple-Services-Control AVP is an AVP group. The specific ABNF grammars are as follows.

Multiple-Services-Credit-Control ::= < AVP Header: 456>

[Granted-Service-Unit]

[Requested-Service-Unit]

*[Used-Service-Unit]

{Rating-Group}

[Service-Identifier]

* [ G-S-U-Pool-Reference ]

[Validity-Time]

[Result-Code]

[Final-Unit-Indication]

[Time-Quota-Threshold ]

[Volume-Quota-Threshold ]

[Unit-Quota-Threshold ]

[ Quota-Holding-Time ]

[ Quota-Consumption-Time ]

*[ Reporting-Reason ]

[Trigger]

[ PS-Furnish-Charging-Information ]

*[ Envelope ]

[Tariff-Time-Change]

[ Envelope-Reporting ]

[ Time-Quota-Mechanism ]


Ltd

23


3.2.43 Origin-Host

AVP name Origin-Host

AVP code 264


Note: Device ID of the start end. The global network allocates it centrally. Different Diameter peers should be unique.

Example: SCP001.huawei.com.

3.2.44 Origin-Realm

AVP name Origin-Realm

AVP code 296


Note: Home filed of the device on the start end.

Example: huawei.com.

3.2.45 Origin-State-Id

AVP name Origin-State-Id

AVP code 278

AVP type Unsigned32

Note: The original ID sent by the Diameter client to the server. It is a monotonically increasing integer. The client can set the restart time as the Origin-State-Id value to make sure that this value is increasing after the restart.

When the Diameter server receives the Origin-State-Id from the same Diameter client, the Diameter server should terminate all the sessions whose Origin-State-Ids are less than this value from the client.

3.2.46 PDN-Connection-Id

AVP name PDN-Connection-Id

AVP code 2050

AVP type Unsigned32


Ltd

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


Ltd

25


AVP name Pre-emption-Capability

Note: The Pre-emption-Capability AVP (AVP code 1047) is of type Enumerated. The AVP defines whether a service data flow can get resources that were already assigned to another service data flow with a lower priority level.

The following values are defined:

PRE-EMPTION_CAPABILITY_ENABLED (0)

This value indicates that the service data flow is allowed to get resources that were already assigned to another service data flow with a lower prioriy level.

PRE-EMPTION_CAPABILITY_DISABLED (1)

This value indicates that the service data flow is not allowed to get resources that were already assigned to another service data flow with a lower prioriy level. This is the default value applicable if this AVP is not supplied.

3.2.50 Pre-emption-Vulnerability

AVP name Pre-emption-Vulnerability

AVP code 1048

AVP type Enumerated

Note: The Pre-emption Vulnerability AVP (AVP code 1048) is of type Enumberated. The AVP defines whether a service data flow can lose the resources assigned to it in order to admit a service data flow with higher priority level.


PRE-EMPTION_VULNERABILITY_ENABLED (0)

This value indicates that the resources assigned to the service data flow can be pre-empted and allocated to a service data flow with a higher priority level. This is the default value applicable if this AVP is not supplied.

PRE-EMPTION_VULNERABILITY_DISABLED (1)

This value indicates that the resources assigned to the service data flow shall not be pre-empted and allocated to a service data flow with a higher priority level.

3.2.51 Priority-Level

AVP name Priority-Level

AVP code 1046

AVP type Unsigned32


Ltd

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


Ltd

27


AVP name PS-Information

Note: PS Domain service information group.

PS-Information AVP is an AVP group. The specific ABNF grammars are as follows:

PS-Information :: = < AVP Header: 20200>

[3GPP-Charging-Id]

[ PDN-Connection-ID ]

[3GPP-PDP-Type]

*[PDP-Address]

[QoS-Information]

[SGSN-Address]

[GGSN-Address]

[CG-Address]

[ Serving-Node-Type ]

[3GPP-IMSI-MCC-MNC]

[3GPP-GGSN- MCC-MNC]

[3GPP-NSAPI]

[Called-Station-Id]

[3GPP-Session-Stop-Indicator]

[3GPP-Selection-Mode]

[3GPP-Charging-Characteristics]

[3GPP-SGSN-MCC-MNC]

[3GPP-MS-TimeZone]

[Charging-Rule-Base-Name]

[3GPP-User-Location-Info]

[3GPP-RAT-Type]

[PS-Furnish-Charging-Information]

[PDP-Context-Type]

[ PDN-Connection-ID]

[ Serving-Node-Type]

[ Start-Time ]

[ Stop-Time ]

3.2.53 PS-Furnish-Charging-Information

AVP name PS-Furnish-Charging-Information

AVP code 865

AVP type Grouped


Ltd

28


AVP name PS-Furnish-Charging-Information

Note: This AVP purpose is to add online charging session specific information, received via the Ro reference point, onto the Rf reference point in order to facilitate its inclusion in CDRs. This information element may be received in a CCA message via the Ro reference point. In situations where online and offline charging are active in parallel, the information element is transparently copied into an ACR to be sent on the Rf reference point.

It has the following ABNF grammar:

PS-Furnish-Charging-Information :: = < AVP Header: 865> { 3GPP-Charging-Id } { PS-Free-Format-Data } [ PS-Append-Free-Format-Data ]

Note: In Huawei UGW9811 the total length of PS-Free-Format-Data must be less than 63 bytes.

3.2.54 QoS-Class-Identifier

AVP name QoS-Class-Identifier

AVP code 1028

AVP type Enumerated


Ltd

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)


QCI_3 (3)


QCI_4 (4)


QCI_5 (5)


QCI_6 (6)


QCI_7 (7)


QCI_8 (8)


QCI_9 (9)


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

0: Reserved

10-127: Reserved

128-254: Operator specific

255: Reserved


Ltd

30


3.2.55 QoS-Information

AVP name QoS-Information

AVP code 1016

AVP type Grouped

Note: The QoS-Information AVP (AVP code 1016) is of type Grouped, and it defines the QoS information for resources requested by the UE, an IP-CAN bearer, PCC rule, QCI or APN. When this AVP is sent from the PCEF to the PCRF, it indicates the requested QoS information associated with resources requested by the UE, an IP CAN bearer or the subscribed QoS information at APN level. When this AVP is sent from the PCRF to the PCEF, it indicates the authorized QoS for:

- an IP CAN bearer (when appearing at CCA or RAR command level or

- a service flow (when included within the PCC rule) or

- a QCI (when appearing at CCA or RAR command level with the QoS-Class-Identifier AVP and the Maximum-Requested-Bandwidth-UL AVP and/or the Maximum-Requested-Bandwidth-DL AVP) or

- an APN (when appearing at CCA or RAR command level with APN-Aggregate-Max-Bitrate-DL and APN-Aggregate-Max-Bitrate-DL).

The QoS class identifier identifies a set of IP-CAN specific QoS parameters that define QoS, excluding the applicable bitrates and ARP. It is applicable both for uplink and downlink direction.

The Max-Requested-Bandwidth-UL defines the maximum bit rate allowed for the uplink direction.

The Max-Requested-Bandwidth-DL defines the maximum bit rate allowed for the downlink direction.

The Guaranteed-Bitrate-UL defines the guaranteed bit rate allowed for the uplink direction.

The Guaranteed-Bitrate-DL defines the guaranteed bit rate allowed for the downlink direction.

The APN-Aggregate-Max-Bitrate-UL defines the total bandwidth usage for the uplink direction of non-GBR QCIs at the APN. This AVP applies to all access types except 3GPP-GPRS access.

The APN-Aggregate-Max-Bitrate-DL defines the total bandwidth usage for the downlink direction of non-GBR QCIs at the APN. This AVP applies to all access types except 3GPP-GPRS access.

The Bearer Identifier AVP shall be included as part of the QoS-Information AVP if the QoS information refers to an IP CAN bearer initiated by the UE and the PCRF performs the bearer binding. The Bearer Identifier AVP identifies this bearer. Several QoS-Information AVPs for different Bearer Identifiers may be provided per command.

When the QoS-Information AVP is provided within the CCR command along with the RESOURCE_MODIFICATION_REQUEST event trigger, the QoS-information AVP includes only the QoS-Class-Identifier AVP and Guaranteed-Bitrate-UL and/or Guaranteed-Bitrate-DL AVPs.

The Allocation-Retention-Priority AVP is an indicator of the priority of allocation and retention for the Service Data Flow.

If the QoS-Information AVP has been supplied previously but is omitted in a Diameter


Ltd

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-Service-Credit-Control AVP group. This AVP is also used in distributing time quota and volume quota.

If the value of Quota-Holding-Time is 0, the quota holding timer system is not used. If Quota-Holding-Time AVP does not appear, the client uses the default value of the local configuration.

3.2.57 Quota-Consumption-Time

AVP name Quota-Consumption-Time

AVP code 881

AVP type Unsigned32


Ltd

32


AVP name Quota-Consumption-Time

Note: Quota consumption time. The unit is second. For some data application base on time charging, its traffic may not be continuous. When the traffic interruption is caused by the factors that are not related to users, for example, the server is busy and cannot reply temporarily, users may complain the charging for this no traffic time. To provide better customer experience, the carrier can use charging method based on time period for discontinuous traffic. When the data packet in the user access line stops transfer for some time, client does not calculate this time period into service time. It is indicated by Quota consumption time.

As an optional function, the Diameter server can command the client to stop calculating user quota consumption when data packet stops transfer for some time or after the session ends. This is realized through Quota-Consumption-Time AVP carried in CCA message. The idle time after the data packet stops transfer and before Quota-Consumption-Time arrives must be calculated into user quota consumption. The calculation of user quota consumption resumes once data packet resumes to transfer.

If data on the user access line is still allowed to transfer during CCR/CCA message exchange process, and Quota-Consumption-Time carried by the new quota got from the exchange is the same with that of the original quota, the CCR/CCA exchange time is also possibly calculated in the waiting time of quota consumption time. For example, if the data packet transfer on the user access line has stopped for five seconds (suppose QCT is ten seconds), and CCA is got two seconds late, then QCT timer will expire three seconds later (if no data packet is transferred after receiving CCA). And the later five second of the QCT will be calculated in to user's new quota consumption, even if no actual data packet is transferred during this period that is after new quota is received.

If Quota-Consumption-Time carried by the new quota is different from that of the original quota, or data on the user line is not allowed to transfer during CCR/CCA information exchange process, the QCT timer will be stopped. The new quota consumption is calculated when next data stream that meets the charging rules starts.

If the value of Quota-Consumption-Time AVP is 0, or Quota-Consumption-Time AVP is not carried in CCA, the quota consumption starts continuous calculation from the moment quota is got.

3.2.58 Rating-Group

AVP name Rating-Group

AVP code 432

AVP type Unsigned32

Note: Rating group ID. All the services of the same Rating type is in the same Rating group. The requested Rating group can be identified uniquely through the combination of Service-Context-Id and Rating-Group AVP.

Rating-Group can correspond to one or more Service-Identifers, which means it contains multiple rate packets of multiple services. Usually, it is used for the charging request based on session in the PS domain.


Ltd

33


3.2.59 Refund-Information

AVP name Refund-Information

AVP code 2022


Note: The Refund-Inforamtion AVP is of type OctetString and it conveys relevant information for the OCS application relative to refund mechanism. When refund mechanism is implemented in the OCS this AVP may be included in the CCA of the previous IEC. This AVP must be used by the CTF in case of a refund scenario and thus must be included in the CCR for refund if previously received in CCA for IEC.

3.2.60 Requested-Action

AVP name Requested-Action

AVP code 436

AVP type Enumerated

Note: The Requested-Action AVP (AVP Code 436) is of type Enumerated and

contains the requested action being sent by Credit-Control-Request

command where the CC-Request-Type is set to EVENT_REQUEST. The

following values are defined for the Requested-Action AVP:

DIRECT_DEBITING 0

This indicates a request to decrease the end user’s account

according to information specified in the Requested-Service-Unit

AVP and/or Service-Identifier AVP (additional rating information

may be included in service-specific AVPs or in the Service-

Parameter-Info AVP). The Granted-Service-Unit AVP in the Credit-

Control-Answer command contains the debited units.

REFUND_ACCOUNT 1

This indicates a request to increase the end user’s account

according to information specified in the Requested-Service-Unit

AVP and/or Service-Identifier AVP (additional rating information

may be included in service-specific AVPs or in the Service-

Parameter-Info AVP). The Granted-Service-Unit AVP in the Credit-

Control-Answer command contains the refunded units.


Ltd

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


Ltd

35


AVP name Reporting-Reason

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

QUOTA_EXHAUSTED 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


Ltd

36


AVP name Requested-Service-Unit

Note: Requested service unit or total amount.

Requested-Service-Unit must be contained in the first or middle CCR request. If the DCC client (for example: test that the terminal user terminates the service) does not contain Requested-Service-Unit in the request, then the DCC server should deduct the used amount form the user’s account. In addition, new quota cannot be returned in the response. Reply with Validity-Time, Result-Code and Final-Unit-Indication to terminate the service elegantly.

Requested-Service-Unit AVP is an AVP group. The specific ABNF grammars are as follows.

Requested-Service-Unit ::= < AVP Header: 437 >

[ CC-Time ]

[ CC-Total-Octets ]


3.2.64 Redirect-Server

AVP name Redirect-Server

AVP code 434

AVP type Grouped

Note: It includes the address information of the redirect server, for example, HTTP Redirect Server and SIP Redirect Server. When the user account balance is not enough to pay for the service charge, the user is redirected to the redirect server.

When Final-Unit-Action is configured as REDIRECT, Redirect-Server must be specified.

Redirect-Server AVP is an AVP group. The ABNF grammars are as follows:

Redirect-Server ::= < AVP Header: 434 >

{ Redirect-Address-Type }

{ Redirect-Server-Address }

3.2.65 Redirect-Address-Type

AVP name Redirect-Address-Type

AVP code 433

AVP type Enumerated


Ltd

37


AVP name Redirect-Address-Type

Note: It defines the address types provided in Redirect-Server-Address.

The values defined by address types are as follows:

Ipv4 Address 0

The address type is Ipv4 form defined in [Ipv4].

Ipv6 Address 1

The address type is Ipv6 form defined in [Ipv6Addr]. The address format can be the preferred form or alternate form defined in [Ipv6Addr]. Implementation construction must support preferred form and should support alternate form.

URL 2

The address type is URL form defined in [URL].

SIP URI 3

The address type is SIP URI form defined in [SIP].

3.2.66 Redirect-server-Address

AVP name Redirect-Server-Address

AVP code 435

AVP type UTF8String

Note: It defines the address information of the redirect server, for example, HTTP Redirect Server and SIP Redirect Server. When the user account balance is not enough to pay for the service charge, the user is redirected to this address.

3.2.67 Restriction-Filter-Rule

AVP name Restriction-Filter-Rule

AVP code 343

AVP type IPFilterRule

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

3.2.68 Service-Context-Id

AVP name Service-Context-Id

AVP code 461


Ltd

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 ]


Ltd

39

mailto:[email protected]


3.2.71 Serving-Node-Type

AVP name Serving-Node-Type

AVP code 2047

AVP type Enumerated

Note: The Serving-Node-Type AVP (AVP Code 2047) is of type Enumerated and identifies the type of Serving Node. It may take the following values:

0 SGSN

1 PMIPSGW

2 GTPSGW

3 ePDG

4 hSGW

5 MME

3.2.72 Session-Id

AVP name Session-Id

AVP code 263

AVP type UTF8String

Note: Session ID, uniquely identifying once DCC session process.

Grammar:

<DiameterIdentity>;<high 32 bits>;<low 32 bits>[;<optional value>]

Example for SPUD board.

<high 32 bits>: Session create time in UTC format (seconds from 1900).

<low 32 bits>: Slot and CPU number from 0~4095.

<optional value>: Sequence number.

The above fields are separated with ";".

Example: ggsnv9;3447404749;529;10

Example for SPUE board.

3.2.73 SGSN-Address

AVP name SGSN-Address

AVP code 1228

AVP type IPAddress


Ltd

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


Ltd

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 Used-Service-Unit AVP, this value indicates the amount of resource units used before a tariff change had occurred.

UNIT_AFTER_TARIFF_CHANGE 1

When present in the Multiple-Services-Credit-Control AVP, this value indicates the amount of the units allocated for use after a tariff change occurs. When present in the Used-Service-Unit AVP, this value indicates the amount of resource units used after tariff change had occurred.

UNIT_INDETERMINATE 2

The used unit contains the amount of units that straddle the tariff change (e.g., the metering process reports to the credit-control client in blocks of n octets, and one block straddled the tariff change). This value is to be used only in the Used-Service-Unit AVP.

3.2.77 Tariff-Time-Change

AVP name Tariff-Time-Change

AVP code 451

AVP type Time

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

Ignoring this AVP means charging rate switchover report is not needed.

3.2.78 Termination-Cause

AVP name Termination-Cause

AVP code 295

AVP type Enumerated


Ltd

42


AVP name Termination-Cause

Note: It used to indicate the reason for the session termination of the Diameter client.


DIAMETER_LOGOUT 1

The user initiated disconnect.

DIAMETER_SERVICE_NOT_PROVIDED 2

This value is used when the user disconnected prior to the receipt of the authorization answer message.

DIAMETER_BAD_ANSWER 3

This value indicates that the authorization answer received by the access device was not processed successfully.

DIAMETER_ADMINISTRATIVE 4

The user was not granted access, or was disconnected, due to administrative reasons, such as the receipt of a Abort-Session-Request message.

DIAMETER_LINK_BROKEN 5

The communication to the user was abruptly disconnected.

DIAMETER_AUTH_EXPIRED 6

The user’s access was terminated since its authorized session time has expired.

DIAMETER_USER_MOVED 7

The user is receiving services from another access device.

DIAMETER_SESSION_TIMEOUT 8

The user’s session has timed out, and service has been terminated.

3.2.79 Time-Quota-Threshold

AVP name Time-Quota-Threshold

AVP code 868

AVP type Unsigned32

Note: It includes threshold value calculated by second. When Multiple-Services-Credit-Control includes Granted-Service-Units and Granted-Service-Units includes CC-Time (the quota distributed is time quota), Multiple-Services-Credit-Control may include Time-Quota-Threshold.

When Time-Quota-Threshold is received, DCC client will send CCR reauthorization to apply for new quota if the quota left is lower than the threshold value defined by Time-Quota-Threshold. During the reauthorization process, DCC client allows users to continue to use the service until the original quota is used up.


Ltd

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:

<Trigger>::= < AVP Header: 1264 >

* [ Trigger-Type ]


Ltd

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 re-authorize to apply new quota.

Trigger-Type must be used when the Reporting-Reason in CCR is RATING_CONDITION_CHANGE.

The following values are defined in Trigger-Type:

CHANGE_IN_SGSN_IP_ADDRESS 1

It shows that the SGSN IP address changes so that the DCC client requests new authority quota.

CHANGE_IN_QOS 2

It shows that the QoS negotiated by the terminal user changes so that the DCC client requests new authority quota.

CHANGE_IN_LOCATION 3

It shows that the terminal user location changes so that the DCC client requests new authority quota.

CHANGE_IN_RAT 4

It shows that the radio access techniques change so that the DCC client requests new authority quota.

3.2.84 Unit-Quota-Threshold

AVP name Unit-Quota-Threshold

AVP code 1226

AVP type Unsigned32

Note: It includes threshold value calculated by unit. When Multiple-Services-Credit-Control includes Granted-Service-Units and Granted-Service-Units include CC-Service-Specific-Units (the quota distributed is unit quota), Multiple-Services-Credit-Control may include Unit-Quota-Threshold.

When Unit-Quota-Threshold is received, DCC client will send CCR reauthorization to apply for new quota if the quota left is lower than the threshold value defined by Unit -Quota-Threshold. During the reauthorization process, DCC client allows users to continue to use the service until the original quota is used up.


Ltd

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 ]



*[ Event-Charging-TimeStamp ]

3.2.87 User-Equipment-Info

AVP name User-Equipment-Info

AVP code 458

AVP type Grouped


Ltd

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 ::= <AVP Header: 458>

{User-Equipment-Info-Type}

{User- Equipment-Info-Value}

3.2.88 User-Equipment-Info-Type

AVP name User-Equipment-Info-Type

AVP code 459

AVP type Enumerated

Note: This field determines the type of the identifier. The used value is 0 for the international mobile equipment identifier and software version according to 3GPP TS 23.003.

3.2.89 User-Equipment-Info-Value

AVP name User-Equipment-Info-Value

AVP code 460


Note: This field contains the user IMEISV.

IMEISV supports both BCD type and UTF8Sting type by the control of software parameter BYTE33 BIT1 and BIT2:

Bit1 Bit2 Description

0 0 IMEIV filled as BCD code.

1 0 IMEIV filled as UTF8 string, for length 15 IMEIV, the last two bytes was filled by FF.

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

3.2.90 User-Name

AVP name User-Name

AVP code 1

AVP type UTF8String


Ltd

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


Ltd

48


AVP name Volume-Quota-Threshold

Note: It includes threshold value calculated by byte. When Multiple-Services-Credit-Control includes Granted-Service-Units and Granted-Service-Units include CC-Total-Octets, CC-Input-Octets or CC-Output-Octets (the quota distributed is volume quota), Multiple-Services-Credit-Control may include Volume-Quota-Threshold.

When Volume-Quota-Threshold is received, DCC client will send CCR reauthorization to apply for new quota if the quota left is lower than the threshold value defined by Volume-Quota-Threshold. During the reauthorization process, DCC client allows users to continue to use the service until the original quota is used up.

3.2.94 3GPP-Charging-Id

AVP name 3GPP-Charging-Id

AVP code 2

AVP type Unsigned32

Note: Charging ID. The combination of 3GPP-Charging-Id and GGSN-Address can be used to identify the charging records of all the related SGSN and GGSN of a PDP context. Charging ID is generated by the GGSN during PDP context activation, and is sent to the SGSN which sends the Context request. Because the GGSN allocates Charging ID independently, different GGSNs may allocate the same Charging ID, which needs to be identified by the server according to the GGSN address and the start time stamp of the charging record.

3.2.95 3GPP-PDP-Type

AVP name 3GPP-PDP-Type

AVP code 3

AVP type Enumerated

Note: PDP context type, such as Ipv4, Ipv6 or PPP.

Enumeration type:

Ipv4 0

Ipv6 1

PPP 2

3.2.96 3GPP-GPRS-Negotiated-Qos-Profile

AVP name 3GPP-GPRS-Negotiated-Qos-Profile

AVP code 5

AVP type UTF8String


Ltd

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


Note: The identification of the service access point to the network layer. In the MS, the NASPI is used to identify PDP-SAP. Between the SGSN and the GGSN, the NASPI is used to identify the PDP context that is associated with a PDP address.

3.2.100 3GPP-Session-Stop-Indicator

AVP name 3GPP-Session-Stop-Indicator

AVP code 11

AVP type BitString


Ltd

50


AVP name 3GPP-Session-Stop-Indicator

Note: Session abort identification. It identifies a session is over when the session is released and is used in CCR (final).

3.2.101 3GPP-Selection-Mode

AVP name 3GPP-Selection-Mode

AVP code 12

AVP type UTF8String

Note: Selection mode.

It is received from the Create PDP Context Request Message.

The values allowed by the GGSN:

0

MS or network provided APN, subscribed verified

1

MS provided APN, subscription not verified

2

Network provided APN, subscription not verified

3.2.102 3GPP-Charging-Characteristics

AVP name 3GPP-Charging-Charateristics

AVP code 13

AVP type Unsigned32

Note: Charging characteristics. It is received from the Create PDP Context Request Message.

3.2.103 3GPP-SGSN-MCC-MNC

AVP name 3GPP-SGSN-MCC-MNC

AVP code 18

AVP type UTF8String

Note: The PLMN identification of the SGSN.


Ltd

51


3.2.104 3GPP-MS-TimeZone

AVP name 3GPP-MS-TimeZone

AVP code 23


Note: Time zone of the terminal.

3.2.105 3GPP-User-Location-Info

AVP name 3GPP-User-Location-Info

AVP code 22


Note: User location identification.

3.2.106 3GPP-RAT-Type

AVP name 3GPP-RAT-Type

AVP code 21


Note: Radio access techniques. Radio side parameters.

3.3 AVP Flag Defination

3.3.1 Basic AVPs from IETF

Figure a.1 AVPs from IETF

AVP Name AVP

Code

AVP Flag Rules

Must May Should

not

Must

not

May

Encr.

Acct-Application-Id 259 M P - V N

Auth-Application-Id 258 M P - V N

Called-Station-Id 30 M P - V N


Ltd

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

CC-Service-Specific-Units 417 M P - V Y

CC-Session-Failover 418 M P - V Y

CC-Time 420 M P - V Y

CC-Total-Octets 421 M P - V Y

CC-Unit-Type 454 M P - V Y

Credit-Control-Failure-Handling 427 M P - V Y

Destination-Host 293 M P - V N

Destination-Realm 283 M P - V N

Direct-Debiting-Failure-Handling 428 M P - V Y

Event-Timestamp 55 M P - V N

Exponent 429 M P - V N

Failed-AVP 279 M P - V N

Filter-Id 11 M P - V Y

Final-Unit-Action 449 M P - V Y

Final-Unit-Indication 430 M P - V Y

Granted-Service-Unit 431 M P - V Y

G-S-U-Pool-Identifier 453 M P - V Y

G-S-U-Pool-Reference 457 M P - V Y

Multiple-Services-Credit-Control 456 M P - V Y

Multiple-Services-Indicator 455 M P - V Y

Origin-Host 264 M P - V N

Origin-Realm 296 M P - V N

Origin-State-Id 278 M P - V N

Proxy-Info 284 M - - P,V N

Proxy-Host 280 M - - P,V N

Proxy-State 33 M - - P,V N

Rating-Group 432 M P - V Y

Redirect-Address-Type 433 M P - V Y


Ltd

53


Redirect-Server 434 M P - V Y

Redirect-Server-Address 435 M P - V Y

Requested-Action 436 M P - V Y

Requested-Service-Unit 437 M P - V Y

Restriction-Filter-Rule 438 M P - V Y

Result-Code 268 M P - V N

Route-Record 282 M - - P,V N

Service-Context-Id 461 M P - V Y

Service-Identifier 439 M P - V Y

Session-Id 263 M P - V Y

Subscription-Id 443 M P - V Y

Subscription-Id-Data 444 M P - V Y

Subscription-Id-Type 450 M P - V Y

Tariff-Change-Usage 452 M P - V Y

Tariff-Time-Change 451 M P - V Y

Unit-Value 445 M P - V Y

Used-Service-Unit 446 M P - V Y

User-Equipment-Info 458 - P,M - V Y

User-Equipment-Info-Type 459 - P,M - V Y

User-Equipment-Info-Value 460 - P,M - V Y

User-Name 1 M P - V Y

Value-Digits 447 M P - V Y

Validity-Time 448 M P - V Y

Vendor-Id 266 - - - - -

Vendor-Specific-Application-Id 260 - - - - -

When AVPs are applied in different site, the flag rules may be defined differently according to Operator’s requirement.


Ltd

54


3.3.2 3GPP Specific AVPs

Figure a.2 3GPP Specific AVPs

AVP Name AVP

Code

AVP Flag Rules

Must May Should

not

Must

not

May

Encr.

Access-Network-Charging-Identifier-Value 503 V,M P Y

Access-Network-Information 1263 V,M P N

AF-Charging-Identifier 505 V,M P Y

Base-Time-Interval 1265 V,M P - N

CG-Address 846 V,M P Y

Charging-Rule-Base-Name 1004 V,M P Y

Envelope 1266 V,M P - 　 N

Envelope-Start-Time 1269 V,M P - 　 N

Envelope-End-Time 1267 V,M P - 　 N

Envelope-Reporting 1268 V,M P - 　 N

Event-Charging-TimeStamp 1258 V,M P - N

GGSN-Address 847 V,M P N

PDP-Address 1227 V,M P Y

PDP-Context-Type 1247 V,M P N

PS-Append-Free-Format-Data 867 V,M P N

PS-Free-Format-Data 866 V,M P N

PS-Furnish-Charging-Information 865 V,M P N

PS-Information 874 V,M P N

Quota-Consumption-Time 881 V,M P N

Quota-Holding-Time 871 V,M P N

Reporting-Reason 872 V,M P N

Service-Information 873 V,M P N

SGSN-Address 1228 V,M P N

Time-Quota-Mechanism 1270 V,M P - 　 N

Time-Quota-Threshold 868 V,M P N

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


Ltd

55


AVP Name AVP

Code

AVP Flag Rules

Trigger 1264 V,M P N

Trigger-Type 870 V,M P N

Unit-Quota-Threshold 1226 V,M P - 　 N

Volume-Quota-Threshold 869 V,M P N

3GPP-Charging-Characteristics 13 V,M P Y

3GPP-Charging-Id 2 V,M P Y

3GPP-GGSN- MCC-MNC 9 V,M P Y

3GPP-GPRS-Negotiated-QoS-Profile 5 V,M P Y

3GPP-IMSI-MCC-MNC 8 V,M P Y

3GPP-MS-TimeZone 23 V,M P Y

3GPP-NSAPI 10 V,M P Y

3GPP-PDP-Type 3 V,M P Y

3GPP-RAT-Type 21 V,M P Y

3GPP-Selection-Mode 12 V,M P Y

3GPP-Session-Stop-Indicator 11 V,M P Y

3GPP-SGSN-MCC-MNC 18 V,M P Y

3GPP-User-Location-Info 22 V,M P Y

When AVPs are applied in different site, the flag rules may be defined differently according to Operator’s requirement.

3.4 Traffic Control Behaviour on CCA Result Codes

3.4.1 Result Codes on Command LevelFor command level result codes, each result code (except 2001 and 2002 )behavior could be specificly configured for items below:

Terminate with CCR-T: to tear down the PDP context and send CCR-T.

Terminate without CCR-T: to tear down the PDP context and not to send CCR-T.

Offline: to allow the PDP as offline service and generate the offline GCDR if


Ltd

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 Comment

DIAMETER_SUCCESS (2001) Depends on MSCC result code

DIAMETER_LIMITED_SUCCESS (2002)

Depends on MSCC result code

Specific result code Behaviour Configurable for

Terminate with CCR-T

Terminate without CCR-T

Offline

Failover

All other result codes Default Behaviour


Ltd

57


Figure a.4 List of typical result code


Ltd

58

HUAWEI UGW9811Gy Interface Specification

3 Interface Definition


Ltd

59

CCA Result code on command level

Traffic Behaviour Origin Comment

DIAMETER_MULTI_ROUND_

AUTH(1001)

Default Behaviour RFC3588

DIAMETER_SUCCESS (2001) Depends on MSCC result code

RFC3588


Depends on MSCC result code

RFC3588

DIAMETER_COMMAND_

UNSUPPORTED (3001)


DIAMETER_UNABLE_TO_DELIVER (3002)

Failover RFC3588

DIAMETER_REALM_NOT_

SERVED(3003)


DIAMETER_TOO_BUSY (3004) Failover RFC3588

DIAMETER_LOOP_DETECTED (3005)

Failover RFC3588

DIAMETER_REDIRECT_

INDICATION(3006)


DIAMETER_APPLICATION_UNSUPPORTED (3007)


DIAMETER_INVALID_HDR_BITS (3008)


DIAMETER_INVALID_AVP_BITS (3009)


DIAMETER_UNKNOWN_PEER (3010)

Failover RFC3588

DIAMETER_AUTHENTICATION_REJECTED(4001)


DIAMETER_OUT_OF_SPACE (4002)

Failover RFC3588

DIAMETER_ELECTION_LOST(4003)


DIAMETER_END_USER_

SERVICE_DENIED(4010)


DIAMETER_CREDIT_CONTROL_NOT_APPLICABLE (4011)

No credit control RFC4006

DIAMETER_CREDIT_LIMIT_REACHED (4012)


DIAMETER_AVP_UNSUPPORTED(5001)


DIAMETER_UNKNOWN_SESSION_ID (5002)

Terminate PDP no CCR RFC3588

DIAMETER_AUTHORIZATION_REJECTED(5003)

Terminate PDP with CCR

RFC3588

After PDP context activation procedure. Used Quota must be included


3.4.2 Result Codes on MSCC LevelFor 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


Ltd

60

CCA Result code in MSCC

Traffic Behaviour Comment

DIAMETER_SUCCESS (2001) Allow Traffic


Allow Traffic

Specific result code Behaviour Configurable for

Block

Offline

Redirect

Terminate

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

All other result codes Default Behaviour


3.4.3 Final Unit Action on MSCC Level

Figure a.6 Final Unit Action on MSCC level

3.4.4 Default Behaviour

The default behaviour can be configured separately for Command level and MSCC level result codes locally on GGSN.

Command level result code

Terminate with CCR-T: to tear down the PDP context and send CCR-T. It is default value.

Terminate without CCR-T: to tear down the PDP context and not to send CCR-T.

Offline: to allow the PDP as offline service and generate the offline GCDR if configured

Failover: to take failure handling according to CCFH configuration.

For MSCC level result code not specifically configured, MSCC level default behaviors below could be configured:

Block: to block the service but keep the PDP context. It is default value.

Redirect: to redirect browsing services to configured web server.


Ltd

61

CCA Result code in MSCC

Final-Unit-Action

Traffic Comment

DIAMETER_SUCCESS (2001)

Terminate Block Traffic is blocked when quota is exhausted

Redirect Redirection Redirection is done when the quota is exhausted

Restrict-Access Restrict-Access

Restrict-Access is done when quota is exhausted

DIAMETER_CREDIT_LIMIT_REACHED (4012)

Terminate Block

Redirect Redirection

Restrict-Access Restrict-Access

All other result codes Terminate Default Behaviour

Redirect Default Behaviour

Restrict-Access Default Behaviour


Offline: to allow the service as offline service and generate the offline GCDR if configured

Terminate: to Tear down the PDP context

3.5 Work Flow

3.5.1 Signalling Flow

Figure a.1 Initial Balance Check & Authentication

Figure a.2 Volume Based Charging


Ltd

62


Figure a.3 Time Based Charging


Ltd

63


Figure a.4 Redirection when Balance Exhausted & Recharge Notification


Ltd

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.


Ltd

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 Granted-Service-Unit AVP(s) and maybe also includes the other AVPs of credit control description. In addition, the OCS may set the Validity-Time, and the AVP used to deal with message delivery failure is possible to be included, such as Credit-Control-Failure-Handling AVP and Direct-Debiting-Failure-Handling AVP.

3. After the GGSN receives the CCA, it authorizes the terminal users to use the corresponding service. At the same time, the immediate credit control request is generated.

4. When the reserved capital of the user is to be used up or expire, the GGSN sends new reservation request to the OCS again. The OCS once again reserves capital from the user account, returns the corresponding limits to the GGSN. Then the GGSN updates the reservation capital of the user.

5. When the user account is used up or the enabled service is to end, the GGSN sends a message of terminating credit control service to the OCS. Set the corresponding CC-Request-Type AVP as TERMINATION_REQUEST. The message should contain the Event-Timestamp AVP for identifying the service end time and the Used-Service-Unit AVP used by the actual service. The OCS needs to return the rest reserved capital to the user account and deduct the cost.

Figure a.1 Charging Based on Tariff Changes

1. The user sends the PDP Context request.

6. The GGSN sends the CCR Initial information, asking the OCS to set up control connection.

7. The OCS replies the CCA Initial information which contains Result Code Success.

8. The PDP Context is set up successfully.

9. The user sends the cat 1 service request.

10. The GGSN sends the CCR Update information which contains Rating Group=1.


Ltd

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


Ltd

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 FlowSolutions When Tx Timer Does Not Receive CCA Before It Times Out

After the GGSN sends the CCR message to the OCS and consumes the credit quota of this user, before receiving the CCA message, the GGSN can support:

Not breaking the service being used by the pre-paid charging users. (If this method is used, then the quota used by the users during this period should be recorded in G-CDR and the credit control request message of the next time.)

Pausing the service being used by the pre-paid charging service until it receives the CCA message from the OCS and is authorized.

Terminating the service being used by the pre-paid charging users.


Ltd

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 re-sending the credit control request.

If the CCFH is set as the TERMINATE value, the OCS switchover flow will not work. If fault occurs to the active OCS server, the GGSN will directly prevent the user from using this service, as shown in the following figure.

Figure a.1 Failure Handling—Terminate

When the CCFH is set as the CONTINUE or the RETRY_AND_TERMINATE value, when fault occurs, it will start the OCS switchover flow, If the active OCS server is abnormal, the GGSN sends the path test message. If the path test fails, the OCS switchover will be enabled to re-send the CCR message to the standby OCS server, as shown in the following figure.


Ltd

69


Figure a.2 Failure Handling—Retry and Success


Ltd

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

OM Compulsory option defined by the operator

OC Condition optional option defined by the operator

The different option attributes of each AVP in the specific situation (First, Intermediate, Final and EVENT) is defined in the following table.

If an AVP has father node, then whether it appears depends on whether its father node appears. If the optional father node does not appear, then even this AVP attribute is compulsory, this AVP will not appear.

Document--<Gy AVP Table.xls> indicates detail information of AVPs for each DCC messages.


Ltd

71

HUAWEI UGW9811Gy Interface Specification B Glossary

Figure a.1 Reference Standand

The clauses in the following files become the clauses of this specification through reference. All the sequent modification sheets (excluding the corrigenda) of the referenced files marked with date are not fit for this specification. However, the parties that reach an agreement according to this specification are recommended to study whether the latest versions of these files can be used. The latest versions for all the referenced files without date are fit for this specification.

[1] IETF RFC 4006: “Diameter Credit-Control Application”.

[2] IETF RFC 3588: “Diameter Base Protocol”.

[3] 3GPP TS 32.299: “Telecommunication management; Charging management; Diameter charging application”.

[4] 3GPP TS 32.251: “Telecommunication management; Charging management; Packet Switched (PS) domain charging”.

[5] Gy AVP Table.xls


Ltd

72


Figure a.2 Glossary

AAA Authentication, Authorization and Accounting.

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

AuthorizationThe 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 AgentA Diameter Agent is a Diameter node that provides either relay, proxy, redirect or translation services.

Diameter ClientA 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 NodeA Diameter node is a host process that implements the Diameter protocol, and acts either as a Client, Agent or Server.

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


Ltd

73


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.

DownstreamDownstream 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-by-hop security does not protect the entire Diameter user session. End-to-end security is security between two Diameter nodes, possibly communicating through Diameter Agents. This security protects the entire Diameter communications path from the originating Diameter node to the terminating Diameter node.

Home RealmA 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 multi-session would be a Multi-link PPP bundle. Each leg of the bundle would be a session while the entire bundle would be a multi-session.

Network Access Identifier The Network Access Identifier, or NAI, is used in the Diameter protocol to extract a user's identity and realm. The identity is used to identify the user during authentication and/or authorization, while the realm is used for message routing purposes.

Proxy Agent or Proxy In addition to forwarding requests and responses, proxies make policy decisions relating to resource usage and provisioning. This is typically accomplished by tracking the state of NAS devices. While proxies typically do not respond to client Requests prior to receiving a Response from the server, they may originate Reject messages in cases where policies are violated. As a result, proxies need to understand the semantics of the messages passing through them, and may not support all Diameter applications.


Ltd

74


Realm The string in the NAI that immediately follows the '@' character. NAI realm names are required to be unique, and are piggybacked on the administration of the DNS namespace. Diameter makes use of the realm, also loosely referred to as domain, to determine whether messages can be satisfied locally, or whether they must be routed or redirected. In RADIUS, realm names are not necessarily piggybacked on the DNS namespace but may be independent of it.

Real-time Accounting Real-time accounting involves the processing of information on resource usage within a defined time window. Time constraints are typically imposed in order to limit financial risk.

Relay Agent or Relay Relays forward requests and responses based on routing-related AVPs and realm routing table entries. Since relays do not make policy decisions, they do not examine or alter non-routing AVPs. As a result, relays never originate messages, do not need to understand the semantics of messages or non-routing AVPs, and are capable of handling any Diameter application or message type. Since relays make decisions based on information in routing AVPs and realm forwarding tables they do not keep state on NAS resource usage or sessions in progress.

Redirect Agent Rather than forwarding requests and responses between clients and servers, redirect agents refer clients to servers and allow them to communicate directly. Since redirect agents do not sit in the forwarding path, they do not alter any AVPs transiting between client and server. Redirect agents do not originate messages and are capable of handling any message type, although they may be configured only to redirect messages of certain types, while acting as relay or proxy agents for other types. As with proxy agents, redirect agents do not keep state with respect to sessions or NAS resources.

Roaming Relationships Roaming relationships include relationships between companies and ISPs, relationships among peer ISPs within a roaming consortium, and relationships between an ISP and a roaming consortium.

Security Association A security association is an association between two endpoints in a Diameter session which allows the endpoints to communicate with integrity and confidentially, even in the presence of relays and/or proxies.

Session A session is a related progression of events devoted to a particular activity. Each application SHOULD provide guidelines as to when a session begins and ends. All Diameter packets with the same Session-Identifier are considered to be part of the same session.

Session state A stateful agent is one that maintains session state information, by keeping track of all authorized active sessions. Each authorized session is bound to a particular service, and its state is considered active either until it is notified otherwise, or by expiration.

Sub-session A sub-session represents a distinct service (e.g., QoS or data characteristics) provided to a given session. These services may happen concurrently (e.g., simultaneous voice and data transfer during the same session) or serially. These changes in sessions are tracked with the Accounting-Sub-Session-Id.


Ltd

75


Transaction state The Diameter protocol requires that agents maintain transaction state, which is used for failover purposes. Transaction state implies that upon forwarding a request, the Hop-by-Hop identifier is saved; the field is replaced with a locally unique identifier, which is restored to its original value when the corresponding answer is received. The request's state is released upon receipt of the answer. A stateless agent is one that only maintains transaction state.

Translation Agent A translation agent is a stateful Diameter node that performs protocol translation between Diameter and another AAA protocol, such as RADIUS.

Transport Connection A transport connection is a TCP or SCTP connection existing directly between two Diameter peers, otherwise known as a Peer-to-Peer Connection.

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

User The entity requesting or using some resource, in support of which a Diameter client has generated a request.


Ltd

76

HUAWEI UGW9811Gy Interface Specification C Acronyms and Abbreviations

Figure a.3 Acronyms and Abbreviations

AAA Authentication, Authorization and Accounting

ABNF Augmented BNF for Syntax Specifications

AVP Attribute Value Pairs

BTI Base Time Interval

CDR Charging Data Record

CCFH Credit-Control-Failure-Handling

CTP Continuous Time Period

DCC Diameter Credit Control

DTP Discrete Time Period

FUI Final Unit Indication

GSU Granted Service Units

IP Internet Protocol

IT Inactivity Time

MSCC Multiple Services Credit Control

OCS Online Charging System

QCT Quota Consumption Time

QHT Quota Holding Time

RADIUS Remote Authentication Dial-In User Service

RG Rating Group

SCTP Stream Control Transmission Protocol

TCP Transmission Control Protocol

TLS Transport Layer Security

TQT Time Quota Threshold

USU Used Service Units


Ltd

77

HUAWEI UGW9811Gy Interface Specification C Acronyms and Abbreviations

VQT Volume Quota Threshold

VSA Vendor Specific Attribute, Data Element in Radius

VT Validity Time


Ltd

78

Documents

167355118 HUAWEI UGW9811 V900R009C01 Gy Interface Specification