Auth-Application-Id

The Auth-Application-Id AVP (AVP Code 258) is of type Unsigned32 and is used to advertise support of the authentication and authorization of an application. The Auth-Application-Id must also be carried in all authentication and/or authorization messages that are defined in a separate Diameter specification and have an Application ID assigned. The maximum length of the Auth-Application-Id AVP supported by device is 127 bytes.

CC-Output-Octets

The code and type of the CC-Output-Octets AVP are 414 and Unsigned64, respectively. The AVP, with the maximum length of 8 bytes, indicates the total number of used downlink traffic bytes. This AVP is a sub-AVP and is used in the group AVP named Granted-Service-Unit.

CC-Request-Number

The CC-Request-Number AVP (AVP Code 415) is of type Unsigned32 and identifies this request within one session. As Session-Id AVPs are globally unique, the combination of Session-Id and CC-Request-Number AVPs is also globally unique and can be used in matching credit-control messages with confirmations. An easy way to produce unique numbers is to 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.

CC-Request-Type

CC-Time

The CC-Time AVP (AVP Code 420) is of type Unsigned32 and indicates the length of the requested, granted, or used time in seconds. The CC-Time AVP is a sub-AVP, which is used in the group AVP Granted-Service-Unit.

CC-Total-Octets

The CC-Total-Octets AVP (AVP Code 421) is of type Unsigned64 and contains the total number of requested, granted, or used octets regardless of the direction (sent or received). The CC-Total-Octets AVP is a sub-AVP, which is used in the group AVP Granted-Service-Unit.

Charging-Rule-Definition

The Charging-Rule-Definition AVP (AVP code 1003) is of type Grouped, and it defines the PCC rule for a service flow sent by the PCRF to the PCEF. A Charging-Rule-Name AVP is generated by a PCRF and is globally unique. If a PCC rule needs to be deleted, add the value of the Charging-Rule-Name AVP in the Charging-Rule-Remove AVP. If optional AVPs within a Charging-Rule-Definition AVP are omitted, but corresponding information has been provided in previous Gx messages, the previous information remains valid. The Monitoring-Key AVP contains the monitoring key that can be applied to the PCC rule.

Charging-Rule-Definition ::= < AVP Header: 1003 >

                             { Charging-Rule-Name }

                             [ QoS-Information ]

                             [ Monitoring-Key ]

                             [ X-HW-ACL-Group-Name ]

                             [ X-HW-Interim-Interval ]

                             *[ AVP ]

Charging-Rule-Install

The Charging-Rule-Install AVP (AVP code 1001) is of type Grouped, and it is used to activate, install or modify PCC rules as instructed from the PCRF to the PCEF.

For installing a new PCC rule or modifying a PCC rule already installed, Charging-Rule-Definition AVP shall be used.

For activating a specific PCC rule predefined at the PCEF, Charging-Rule-Name AVP shall be used as a reference for that PCC rule.

Charging-Rule-Install ::= < AVP Header: 1001 >

                         *[ Charging-Rule-Definition ]

                         *[ Charging-Rule-Name ]

                         *[ AVP ]

Charging-Rule-Name

The Charging-Rule-Name AVP (AVP code 1005) is of type OctetString, and it defines a name for PCC rule. For PCC rules provided by the PCRF it uniquely identifies a PCC rule within one IP CAN session. For PCC rules pre-defined at the PCEF it uniquely identifies a PCC rule within the PCEF. The maximum length of the Charging-Rule-Name AVP is 67 bytes.

Charging-Rule-Remove

The Charging-Rule-Remove AVP (AVP code 1002) is of type Grouped, and it is used to deactivate or remove PCC rules from an IP CAN session.

Charging-Rule-Name AVP is a reference for a specific PCC rule at the PCEF to be removed or for a specific PCC rule predefined at the PCEF to be deactivated.

AVP Format:

Charging-Rule-Remove ::= < AVP Header: 1002 >

                       *[ Charging-Rule-Name ]

                      *[ AVP ] 

Charging-Rule-Report

The Charging-Rule-Report AVP (AVP code 1018) is of type Grouped, and it is used to report the status of PCC rules.

• Charging-Rule-Name AVP is a reference for a specific PCC rule at the PCEF that has been successfully installed, modified or removed (for dynamic PCC rules), or activated or deactivated (for predefined PCC rules).

• The Charging-Rule-Report AVP can also be used to report the status of the PCC rules for which credit is no longer available or credit has been reallocated after the former out of credit indication. In this case, the Charging-Rule-Name AVP is used to specify the name of the PCC rule that fails to be activated.

AVP Format:

Charging-Rule-Report ::= < AVP Header:1018 >

                        *[Charging-Rule-Name]

                         [PCC-Rule-Status]

                         [Rule-Failure-Code]

                        *[AVP]

Destination-Host

The Destination-Host AVP (AVP Code 293) is of type DiameterIdentity. The Destination-Host AVP may be carried in request messages, and must not be carried in response messages.

The absence of the Destination-Host AVP will cause a request to be sent to any Diameter server that supports the application within the realm specified in Destination-Realm AVP.

The Destination-Host AVP must be placed as close to the Diameter packet header as possible.

Destination-Realm

The Destination-Realm AVP (AVP Code 283) is of type DiameterIdentity. The maximum length of the Destination-Realm AVP is 127 bytes.

The Destination-Realm AVP must not be carried in response messages. The User-Name AVP needs to be added to a request sent by a Diameter client. Diameter servers initiate a request message using the value of the Origin-Realm AVP carried in a previous message that is sent from the target host. The Destination-Realm AVP is used to perform message routing decisions.

The Destination-Realm AVP must be placed as close to the Diameter packet header as possible.

Error-Message

The Error-Message AVP (AVP Code 281) is of type UTF8String, and it may accompany a Result-Code AVP as a readable error message. The Error-Message AVP cannot be parsed by NEs.

Experimental-Result

The Experimental-Result AVP (AVP Code 297) is of type Grouped, and it indicates whether a particular vendor-specific request was completed successfully or whether an error occurred, and the vendor ID.

AVP Format:

Experimental-Result ::= < AVP Header:297 >

                        { Vendor-Id }

                        { Experimental-Result-Code }

Experimental-Result-Code

The Experimental-Result-Code AVP (AVP Code 298) is of type Unsigned32 and it contains a vendor-assigned value representing the result of processing the request. The maximum length is 4 bytes.

Event-Trigger

The Event-Trigger AVP (AVP code 1006) is of type Enumerated. When sent from the PCRF to the PCEF the Event-Trigger AVP indicates an event that shall cause a re-request of PCC rules. When sent from the PCEF to the PCRF the Event-Trigger AVP indicates that the corresponding event has occurred at the gateway. Whenever one of these events occurs, the PCEF shall send the related AVP that has changed together with the event trigger indication.

Feature-List

The Feature-List AVP (AVP Code 630) is of type Unsigned32 and contains a bit mask indicating the supported features of an application. The Feature-List AVP is a sub-AVP, which is used in the group AVP Supported-Features.

Feature-List-ID

The Feature-List-ID AVP (AVP Code 629) is of type Unsigned32 and contains the identity of a feature list. The Feature-List-ID AVP is a sub-AVP, which is used in the group AVP Supported-Features.

Framed-IP-Address

The Framed-IP-Address AVP (AVP Code 8) is of type OctetString and contains an IPv4 address of the type specified in the attribute value to be configured for the user. An IPv4 address and/or an IPv6 address must be carried in a CCR message. The Framed-IP-Address AVP length is 4 bytes.

Framed-IPv6-Prefix

The Framed-IPv6-Prefix AVP (AVP Code 97) is of type OctetString and contains the IPv6 prefix to be configured for the user. An IPv6 prefix or an IPv4 address must be carried in a CCR message. The Framed-IPv6-Prefix AVP length is 18 bytes. The first byte is reserved and the second byte indicates the prefix length (the prefix length ranges from 0 to 128 bytes). The last 16 bytes constitute the prefix.

Granted-Service-Unit

Granted-Service-Unit AVP (AVP Code 431) is of type Grouped and it indicates the quotas sent from the PCRF to users.

AVP Format:

Granted-Service-Unit ::= < AVP Header:431 > 

                         [ CC-Time ]

                         [ CC-Total-Octets ] 

                         *[ AVP ]

Guaranteed-Bitrate-DL

The Guaranteed-Bitrate-DL AVP (AVP code 1025) is of type Unsigned32, and it indicates the guaranteed bit rate for a downlink service data flow, in bit/s. The Guaranteed-Bitrate-DL AVP length supported by device is 4 bytes.

Guaranteed-Bitrate-UL

The Guaranteed-Bitrate-UL AVP (AVP code 1026) is of type Unsigned32, and it indicates the guaranteed bit rate for an uplink service data flow, in bit/s. The Guaranteed-Bitrate-UL AVP length supported by device is 4 bytes.

AVP format:

IP-CAN-Type

The IP-CAN-Type AVP (AVP code 1027) is of type Enumerated, and it shall indicate the type of Connectivity Access Network in which the user is connected.

The IP-CAN-Type AVP shall always be present during the IP-CAN session establishment. This AVP is included in a CCR-Initial message.

For WiFi users, the IP-CAN-Type AVP is set to WLAN. In other modes, the IP-CAN-Type AVP is set to XDSL.

The PCRF determines a policy for users based on the IP-CAN-Type AVP. The policy used varies with the access mode. When the access mode changes, the PCEF sends a message carrying a new access mode and the IP_CAN_CHANGE trigger. The message requests that the PCRF deliver a relevant policy so that the PCEF can implement policy control based on the access mode.

Max-Requested-Bandwidth-DL

The Max-Requested-Bandwidth-DL AVP (AVP code 515) is of type Unsigned32, and it indicates the maximum bandwidth for a downlink IP flow, in bit/s. The Max-Requested-Bandwidth-DL AVP length supported by device is 4 bytes.

If the Max-Requested-Bandwidth-DL AVP is carried in CC-Request messages, it indicates the maximum requested bandwidth. If the Max-Requested-Bandwidth-DL AVP is carried in CC-Answer messages, it indicates the maximum requested bandwidth of the PCRF.

Max-Requested-Bandwidth-UL

The Max-Bandwidth-UL AVP (AVP code 516) is of type Unsigned32, and it indicates the maximum requested bandwidth for an uplink IP flow, in bit/s. The Max -Bandwidth-UL AVP length supported by device is 4 bytes.

If the Max-Requested-Bandwidth-UL AVP is carried in CC-Request messages, it indicates the maximum requested bandwidth. If the Max-Requested-Bandwidth-UL AVP is carried in CC-Answer messages, it indicates the maximum requested bandwidth of the PCRF.

Monitoring-Key

The Monitoring-Key AVP (AVP code 1066) is of type OctetString. The Monitoring-Key AVP is an identifier of a quota monitoring instance and used for quota monitoring.

The Usage-Monitoring-Information AVP is defined in messages. If the Monitoring-Key AVP appears in the Charging-Rule-Definition AVP, the Usage-Monitoring-Information AVP is associated based on the Monitoring-Key AVP. For the predefined rules, the value of the Monitoring-Key AVP must be configured on the PCEF.

Origin-Host

The Origin-Host AVP (AVP Code 264) is of type DiameterIdentity. The maximum length supported by device is 127 bytes. The host name configured on the PCEF is the Peer-Host for the PCRF. The Origin-Host AVP must be carried in all Diameter messages.

• The value of the Origin-Host AVP is guaranteed to be unique within a single host.

• Note that the Origin-Host AVP may resolve to more than one address as the Diameter peer may support more than one address.

• This AVP SHOULD be placed as close to the Diameter header as possible.

Origin-Realm

The Origin-Realm AVP (AVP Code 296) is of type DiameterIdentity and the maximum length is 127 bytes. The Origin-Realm AVP contains the realm that generates any Diameter message, and must be carried in all messages.

This AVP SHOULD be placed as close to the Diameter header as possible.

Origin-State-Id

The Origin-State-Id AVP (AVP Code 278) is of type Unsigned32 and the length is 4 bytes. The Origin-State-Id AVP is a monotonically increasing value that is used whenever a Diameter entity restarts with the loss of a previous status, for example upon reboot. The Origin-State-Id AVP can be carried in any Diameter message, including CER. Typically, Origin-State-Id is used by an access device that always starts up with no active sessions; that is, any session that is active before the restart will be lost. By carrying the Origin-State-Id AVP in a message, it allows other Diameter entities to infer that sessions associated with a lower Origin-State-Id are no longer active. If an access device does not intend for such inferences, the device must include the Origin-State-Id AVP in any message or set its value to 0.

PCC-Rule-Status

The PCC-Rule-Status AVP (AVP code 1019) is of type Enumerated, and describes the status of one or a group of PCC Rules.

The following values are defined for the PCC-Rule-Status AVP:

• ACTIVE(0)

  The value indicates that the PCC rules are successfully installed (for those provided by the PCRF) or activated (for those pre-defined in PCEF).

• INACTIVE(1)

  The value indicates hat the PCC rules are removed (for those provided by the PCRF) or deactivated (for those pre-defined in PCEF).

• TEMPORARILYINACTIVE(2)

  The value indicates that installed or activated PCC rules are temporarily disabled for some reason (for example, loss of bearer).

QoS-Information

The QoS-Information AVP (AVP code 1016) is of type Grouped.

The QoS-Information AVP defines the QoS information of IP-CAN sessions and PCC rules. When the QoS-Information AVP is sent by the PCEF to the PCRF through a CCR-Initial message for requesting the PCRF to establish a session, this AVP indicates the initial QoS information of the users in an IP-CAN session. When the QoS-Information AVP is sent by the PCRF to the PCEF, this AVP indicates the total bandwidth of the users in an IP-CAN session or the authorized QoS parameter for a rule or service.

AVP format:

QoS-Information ::= < AVP Header: 1016>

                    [ Max-Requested-Bandwidth-UL ]

                    [ Max-Requested-Bandwidth-DL ]

                    [ Guaranteed-Bitrate-UL ]

                    [ Guaranteed-Bitrate-DL ]

                    *[ AVP]

Re-Auth-Request-Type

The Re-Auth-Request-Type AVP (AVP Code 285) is of type Enumerated and is carried in application-specific authentication responses to inform the client of the Authorization-Lifetime expiration. If the response message contains an Authorization-Lifetime AVP with a positive value, the Re-Auth-Request-Type AVP must be carried in a response message.

The following values are defined for the Re-Auth-Request-Type AVP:

• AUTHORIZE_ONLY(0)

  A re-auth-request process is expected upon the Authorization-Lifetime expiration. This is the default value if the Re-Auth-Request-Type AVP is not carried in response messages that carry the Authorization-Lifetime.

• AUTHORIZE_AUTHENTICATE(1)

  A re-auth-request process is expected upon the Authorization-Lifetime expiration.

Result-Code

The Result-Code AVP (AVP Code 268) is of type Unsigned32 and the length is 4 bytes. It indicates whether a particular request was completed successfully or whether an error occurred. This AVP is carried in a response message to indicate the result code of a request message. The Result-Code AVP and/or the Experimental-Result AVP must exist.

After processing an RAR message successfully, the PCEF sends an RAA message in which the value of the Result-Code AVP is DIAMETER_SUCCESS.

The PCRF checks whether a user is online. If the user is offline, the PCRF returns the Result-Code AVP whose value is DIAMETER_UNKNOWN_SESSION_ID.

Rule-Failure-Code

The Rule-Failure-Code AVP (AVP code 1031) is of type Enumerated, and it is sent by the PCEF to the PCRF and is used to specify the cause value of the error that occurs in the PCC rule during sending of the Charging-Rule-Report AVP.

The following values are defined in RFC 3588:

• UNKNOWN_RULE_NAME(1)

  This value is used to indicate that the pre-provisioned PCC rule could not be successfully activated because the Charging-Rule-Name is unknown to the PCEF.

• RATING_GROUP_ERROR(2)

  This value is used to indicate that the PCC rule could not be successfully installed or enforced because the Rating-Group specified within the Charging-Rule-Definition AVP by the PCRF is unknown or, invalid.

• SERVICE_IDENTIFIER_ERROR(3)

  This value is used to indicate that the PCC rule could not be successfully installed or enforced because the Service-Identifier specified within the Charging-Rule-Definition AVP by the PCRF is invalid, unknown, or not applicable to the service being charged.

• GW/PCEF_MALFUNCTION(4)

  This value is used to indicate that the PCC rule could not be successfully installed (for those provisioned from the PCRF) or activated (for those pre-provisioned in PCEF) or enforced (for those already successfully installed) due to GW/PCEF malfunction.

• RESOURCES_LIMITATION (5)

  This value is used to indicate that the PCC rule could not be successfully installed (for those provisioned from PCRF) or activated (for those pre-provisioned in PCEF) or enforced (for those already successfully installed) due to a limitation of resources at the PCEF.

• MAX_NR_BEARERS_REACHED (6)

  This value is used to indicate that the PCC rule could not be successfully installed (for those provisioned from PCRF) or activated (for those pre-provisioned in PCEF) or enforced (for those already successfully installed) due to the fact that the maximum number of bearers has been reached for the IP-CAN session.

• UNKNOWN_BEARER_ID (7)

  This value is used to indicate that the PCC rule could not be successfully installed or enforced at the PCEF because the Bearer-Id specified within the Charging-Rule-Install AVP by the PCRF is unknown or invalid. Applicable only for GPRS in the case the PCRF performs the bearer binding.

• MISSING_BEARER_ID (8)

  This value is used to indicate that the PCC rule could not be successfully installed or enforced at the PCEF because the Bearer-Id is not specified within the Charging-Rule-Install AVP by the PCRF. Applicable only for GPRS in the case the PCRF performs the bearer binding.

• MISSING_FLOW_DESCRIPTION (9)

  This value is used to indicate that the PCC rule could not be successfully installed or enforced because the Flow-Information AVP is not specified within the Charging-Rule-Definition AVP by the PCRF during the first install request of the PCC rule.

• RESOURCE_ALLOCATION_FAILURE (10)

  This value is used to indicate that the PCC rule could not be successfully installed since the bearer establishment or modification procedure could not be completed successfully.

• UNSUCCESSFUL_QOS_VALIDATION (11)

  This value is used to indicate that the QoS validation has failed.

In device, the following values are defined:

• UNKNOWN_RULE_NAME (1)
• RATING_GROUP_ERROR (2)
• SERVICE_IDENTIFIER_ERROR (3)
• GW/PCEF_MALFUNCTION (4)

• QOS_CONTENT_ERROR (1004)

  This value is used to indicate that, in the QoS-information AVP delivered by the PCRF, the Guaranteed-Bitrate (Guaranteed-Bandwidth) is greater than the Max-Requested-Bandwidth, which causes the QoS delivered by the PCRF to fail to take effect.

Session-Id

The Session-Id AVP (AVP Code 263) is of type UTF8String and the maximum length is 139 bytes. It is used to identify a specific session. All messages pertaining to a specific session must include only one Session-Id AVP and the same value must be used throughout the life of a session. When present, the Session-Id should appear immediately following the Diameter Header.

The Session-Id AVP is created by the Diameter application initiating the session, which in most cases is done by the client. Note that a Session-Id may be used for both the authorization and accounting commands of a given application.

Session-Release-Cause

The Session-Release-Cause AVP (AVP Code 1045) is of type Enumerated and it determines the reason of the IP-CAN session released by the PCRF.

The following values are defined for the Session-Release-Cause AVP:

• UNSPECIFIED_REASON (0)

  This value is used for unspecified reasons.

• UE_SUBSCRIPTION_REASON (1)

  This value is used to indicate that the UE subscription data has changed (for example, subscription data was deleted) and a session needs to be terminated.

• INSUFFICIENT_SERVER_RESOURCES (2)

  This value is used to indicate that the server is overloaded and a session needs to be terminated.

• UE_SUBSCRIPTION_REASON (1)

Subscription-Id

The Subscription-Id AVP (AVP Code 443) is of type Grouped and it is used to identify the end user's subscription data.

The Subscription-Id AVP consists of the Subscription-Id-Data AVP and the Subscription-Id-Type AVP. The Subscription-Id-Data AVP includes one ID and the Subscription-Id-Type AVP defines the ID type.

It is defined as follows (per the grouped-avp-def of RFC 3588 [DIAMBASE]):

Subscription-Id ::= <AVP Header: 443 >

                    { Subscription-Id-Type }

                    { Subscription-Id-Data }

Subscription-Id-Data

The Subscription-Id-Data AVP (AVP Code 444) is used to identify the end user and is of type UTF8String. The Subscription-Id-Type AVP defines which type of identifier is used. The Subscription-Id-Data AVP is a sub-AVP, which is used in the group AVP Subscription-Id.

Subscription-Id-Type

The Subscription-Id-Type AVP (AVP Code 450) is of type Enumerated, and it is used to determine which type of identifier is carried by the Subscription-Id AVP.

Supported-Features

The Supported-Features AVP (Code 628) is of type Grouped. If this AVP is present it may inform the destination host about the features that the origin host supports. The Feature-List AVP contains a list of supported features of the origin host. The Vendor-Id AVP and the Feature-List AVP shall together identify which feature list is carried in the Supported-Features AVP.

AVP format:

Supported-Features :: = < AVP Header: 628 10415 >

                       { Vendor-Id }

                       { Feature-List-ID }

                       { Feature-List }

                       *[ AVP]

Termination-Cause

The Termination-Cause AVP (AVP Code 295) is of type Enumerated and it is used to indicate the reason of a session termination on an access device.

The following values are defined in RFC 3588:

• DIAMETER_LOGOUT(1)

  The user initiated a 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 an 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.

Usage-Monitoring-Information

Usage-Monitoring-Information AVP (AVP code 1067) is of type Grouped, and it contains quota monitoring information and identifies a usage monitoring event.

• The Granted-Service-Unit AVP shall be used by the PCRF to provide a threshold for the PCEF. The CC-Total-Octets AVP shall be used for providing a threshold for a total volume, or the CC-Input-Octets and/or CC-Output-Octets AVPs shall be used for providing a threshold for the uplink volume and/or the downlink volume
• The Used-Service-Unit AVP shall be used by the PCEF to provide a measured usage for the PCRF. Reporting shall be done, as requested by the PCRF, in CC-Total-Octets, CC-Input-Octets or CC-Output-Octets AVPs of the Used-Service-Unit AVP.
• The Usage-Monitoring-Level AVP determines the scope of the quota monitoring instance.
• The Usage-Monitoring-Report AVP determines if accumulated usage shall be reported for the quota monitoring key included in Monitoring-Key AVP.

AVP format:

Usage-Monitoring-Information ::= <AVP Header: 1067 >

                                [ Monitoring-Key ]

                                 [ Usage-Monitoring-Level ]

                                 [ Granted-Service-Unit ]

                                 [ Used-Service-Unit ]

                                 [ Usage-Monitoring-Report ]

                                 *[ AVP ]

Usage-Monitoring-Level

The Usage-Monitoring-Level AVP (AVP code 1068) is of type Enumerated and it contains quota monitoring information and identifies a quota monitoring event. This AVP is included in an RAR or CCA message delivered by the PCRF.

Usage-Monitoring-Report

The Usage-Monitoring-Report AVP (AVP code 1069) is of type Enumerated and it is used by the PCRF to indicate the accumulated usage to be reported by the PCEF, regardless of whether a usage threshold is reached for certain quota monitoring key. If no monitoring key is specified, the PCRF instructs the PCEF to report session-level usage.

User-Equipment-Info

The User-Equipment-Info AVP (AVP Code 458) is of type Grouped and is used to report a user's MAC address.

It is defined as follows (per the grouped-avp-def of RFC 3588 [DIAMBASE]):

User-Equipment-Info ::= < AVP Header: 458 >

                       { User-Equipment-Info-Type }

                       { User-Equipment-Info-Value }

User-Equipment-Info-Type

The User-Equipment-Info-Type AVP is of type Enumerated (AVP Code 459) and defines the type of user equipment information contained in the User-Equipment-Info-Value AVP.

This specification defines the following user equipment types.

• IMEISV (0)

  The identifier contains the International Mobile Equipment Identifier and Software Version in the international IMEISV format according to 3GPP TS 23.003 [3GPPIMEI].

• MAC(1)

  The 48-bit MAC address.

• EUI64(2)

  The 64-bit identifier used to identify hardware instance of the product.

• MODIFIED_EUI64(3)

  There are a number of types of terminals that have identifiers other than IEEE 802 MACs, or EUI-64. These identifiers can be converted to modified EUI-64 format as described in [IPv6Addr] or by using some other methods referred to in the service-specific documentation.

User-Equipment-Info-Value

The User-Equipment-Info-Value AVP (AVP Code 460) is of type OctetString. The User-Equipment-Info-Type AVP defines which type of identifier is used. The maximum length supported is 6 bytes.

Used-Service-Unit

The Used-Service-Unit AVP is of type Grouped (AVP Code 446) and it indicates the used quotas measured from the last report, which are sent from the PCEF to the PCRF.

The Used-Service-Unit AVP is defined as follows (per the grouped-avp-def of RFC 3588 [DIAMBASE]):

Used-Service-Unit ::= <AVP Header: 446>

                      [ CC-Time ]

                      [ CC-Total-Octets ]

Vendor-Id

The Vendor-Id AVP (AVP Code 266) is of type Unsigned32 and contains the IANA "SMI Network Management Private Enterprise Codes" [ASSIGNNO] value assigned to the vendor of the Diameter application. In combination with the Supported-Vendor-Id AVP, this may be used in order to know which vendor specific attributes may be sent to the peer. It is also envisioned that the combination of the Vendor-Id, Product-Name and the Firmware-Revision AVPs may provide very useful debugging information.

A Vendor-Id value of zero in the CER or CEA messages is reserved and indicates that this field is ignored.

Feature-List-ID AVP

The Vendor-Specific-Application-Id AVP (AVP Code 260) is of type Grouped and is used to advertise support of a vendor-specific Diameter Application. Exactly one of the Auth-Application-Id and Acct-Application-Id AVPs MAY be present.

This AVP MUST also be present as the first AVP in all experimental commands defined in the vendor-specific application.

This AVP SHOULD be placed as close to the Diameter header as possible.

AVP Format:

<Vendor-Specific-Application-Id> ::=< AVP Header: 260 >

                                   1*[ Vendor-Id ]

                                   0*1{Auth-Application-Id }

                                   0*1{ Acct-Application-Id }

X-HW-User-Physical-Info-Value

The X-HW-User-Physical-Info-Value AVP (Code 2025) is of type UTF8String and it indicates physical information such as slot ID, sub-slot ID, port ID, and VLAN ID. The HW-User-Physical-Info-Value AVP format is similar to that of the Diameter NAS-PORT-ID AVP. An example of the HW-User-Physical-Info-Value AVP is: {atm|eth|trunk} NAS_slot/NAS_subslot/NAS_port:XPI.XCI.

This AVP is defined as follows: <avpEntry name="X-HW-User-Physical-Info-Value" code="2025" flag="May_M" vendorId="2011" datatype="UTF8String" avpname="240"/>

X-HW-MS-Group-Name

The X-HW-MS-Group-Name AVP (Code 2021) is of type UTF8String and the maximum length is 31 bytes. It indicates a multicast group name. The PCRF sends this AVP based on its configurations.

This AVP is defined as follows:

<avpEntry name="X-HW-MS-Group-Name" code="2021" flag="May_M" vendorId="2011" datatype="UTF8String" avpname="243"/>

X-HW-ACL-Group-Name

The X-HW-ACL-Group-Name AVP (Code 2022) is of type UTF8String and the maximum length is 31 bytes. It indicates an ACL group name configured on the PCEF (device). An ACL user group can be modified to implement ACL-based traffic behaviors.

This AVP is defined as follows:

<avpEntry name="X-HW-ACL-Group-Name" code="2022" flag="May_M" vendorId="2011" datatype="UTF8String" avpname="244"/>

X-HW-Interim-Interval

The X-HW-Interim-Interval AVP is of type Unsigned32 (Code 2023) and has a length of 4 bytes. The HW-Interim-Interval AVP indicates a real-time charging interval (in seconds) of the PCEF (device). Setting its value to more than or equal to 60 is recommended. The HW-Interim-Interval AVP value ranges from 0 to 3932100. The value 0 indicates that real-time charging is not required, and a value greater than 3932100 indicates that a user fails to go online. The PCRF sends this AVP based on its configurations.

This AVP is defined as follows:

<avpEntry name="X-HW-Interim-Interval" code="2023" flag="May_M" vendorId="2011" datatype="Unsigned32" avpname="245"/>

X-HW-Service-Type

This AVP is defined as follows:

<avpEntry name="X-HW-Service-Type" code="2024" flag="M" vendorId="2011" datatype="Enumerated" avpname="246">