SupportDocumentationRoutersService RoutersNetEngine 8000Configuration & CommissioningConfiguration Guide

NetEngine 8000 M14, M8 and M4 V800R023C00SPC500 Configuration Guide

Appendix: GX Interface

Appendix: GX Interface

About This Document

Description Agreement

This document focuses on Gx interface messages, including CCR/CCA and RAR/RAA messages. This document does not describe capability exchange messages such as the CER/CEA message. For details, see RFC3588.

The mandatory parameters described in this document refer to the mandatory elements in messages. If a mandatory parameter does not exist in messages, the PCRF/PCEF considers the messages to be invalid and service operations cannot be triggered by these messages.

Even if optional parameters do not exist in the messages generated by the PCEF, the PCRF still considers the messages valid. In this case, certain functions may be unavailable but basic procedures are still normal. If optional parameters do not exist in the messages generated by the PCRF, the user does not subscribe to relevant services and the PCEF considers the messages to be valid.

The static rules mentioned in this document are defined by the PCEF. The PCRF can provide instructions on use of one or several static rules by using the Charging-Rule-Name attribute-value pair (AVP) without providing detailed definitions of the rules. The specific Charging-Rule-Name AVP is used only after the PCRF and PCEF complete negotiation.

Dynamic rules are created by users based on the service information and policy configuration on the PCRF. The PCRF allocates a dynamic rule a unique Charging-Rule-Name. During deployment of the policy, the PCRF provides the PCEF with detailed parameters of a rule, for example, QoS parameters and CC-Time. Subsequently, the PCRF can instruct the PCEF to modify or delete the rule by using the Charging-Rule-Name AVP.

Static rules can be activated and deactivated.

Dynamic rules can be deployed, modified, and deleted.

An device receives but does not process *[AVP] in the AVP format description. This means that device processes the attributes described in this document but ignores other redundant attributes.

Description of the Gx Interface

Definition of the Gx Interface

The Gx interface is located between the Policy and Charging Enforcement Function (PCEF) and the Policy and Charging Rules Function (PCRF) The Gx interface is used for provisioning and removal of PCC rules from the PCRF to the PCEF and the transmission of traffic plane events from the PCEF to the PCRF. The Gx interface can be used for charging control, policy control or both by applying AVPs relevant to the application.

Figure 1-4835 Gx reference point at the Policy and Charging Control (PCC) architecture

The preceding figure is a copy of Figure 4.1 in 3GPP TS 29.212 V9.7.0.

The PCEF and PCRF are described as follows:

  • PCEF: checks service data flows, obtains service-based control and charging policies from the PCRF, and enforces the policies.

    When functioning as the PCEF, device supports RADIUS accounting but does not support Gy or Gz interfaces.

  • PCRF: defines control and charging policies based on service characteristics and user attributes and dynamically delivers the policies to the PCEF.

devicecan function only as the PCEF.

Functions of the Gx Interface

The Gx interface provides the following functions:
  • Delivers PCC rules from the PCRF to the PCEF.
  • Deletes PCC rules from the PCEF.
  • Transmits events from the PCEF to the PCRF.
PCC rules are classified into the following categories:

  • Dynamic PCC rules: The PCRF dynamically delivers PCC rules to the PCEF through the Gx interface. Dynamic PCC rules can be installed, modified, or deleted any time.

    Dynamic PCC rules are created by users based on the service information and policy configuration on the PCRF. The PCRF allocates a unique Charging-Rule-Name to each dynamic PCC rule. During deployment of the policy, the PCRF provides the PCEF with detailed parameters of a rule(such as QoS,CC-Time,and so on). Subsequently, the PCRF uses the Charging-Rule-Name AVP to instruct the PCEF to modify or delete the rule.

  • Static PCC rules: PCC rules are pre-configured on the PCEF. Static PCC rules can be activated or deactivated by the PCRF any time.

    The static PCC rules mentioned in this document are defined by the PCEF. The PCRF uses the specified Charging-Rule-Name attribute-value pair (AVP) to provide instructions for the use of one or several static rules [negating the provision of detailed rule definitions]. The specific Charging-Rule-Name AVP is used only after the PCRF and PCEF complete negotiation.

Diameter Protocol Stack on the Gx Interface

Diameter is used for information exchanging on the Gx interface.

Diameter is an Authentication, Authorization, and Accounting (AAA) protocol developed by the Internet Engineering Task Force (IETF) for next-generation AAA servers. Diameter is defined in RFC 3588 and derived from the Remote Authentication Dial In User Service (RADIUS) protocol.

Diameter is mainly used in mobile communication systems, whereas RADIUS defined in RFC 2865 is used for fixed network access. However, as fixed and mobile networks converge, demands for unified AAA servers are becoming urgent and the Diameter protocol stack is required, therefore, to support fixed network access.

As shown in Figure 1-4836, Diameter is used in the application layer of the protocol stack, and Transport Control Protocol (TCP) or Stream Control Transmission Protocol (SCTP) is used in the transport layer. The device supports IP and does not support SCTP or IPsec.

Figure 1-4836 Diameter protocol stack structure

When Diameter is used on the Gx interface, its extended application protocols are called Gx applications. Figure 1-4837 shows the Gx interface protocol stack.

Figure 1-4837 Figure 1-3 Gx interface protocol stack

Message Exchanging on the Gx Interface

Figure 1-4838 shows the message exchanging process on the Gx interface.

Figure 1-4838 Message exchanging process on the Gx interface

Table 1-1666 describes six messages exchanged over the Gx interface.

Table 1-1666 Messages over the Gx interface

Name

Direction

Description

CCR(Gx Message)

PCEF -> PCRF

The interworking between the PCEF and the PCRF involves three CCR messages: IP connectivity access network (IP-CAN) session authorization request, session modification message (including event notification), and session termination message. The PCEF sends CCR messages to indicate that a user is online or offline and to report quota.

CCA(Gx Message)

PCRF -> PCEF

A Credit-Control-Answer (CCA) message is the response to a CCR message. The interworking between the PCEF and the PCRF involves three CCA messages, which are associated with three CCR messages accordingly. The PCRF manages a policy or returns a CCA message to the PCEF after the policy is released. CCA messages are responses to CCR messages that indicate whether a user is online or offline.

RAR(Gx Message)

PCRF -> PCEF

The PCRF sends Re-Auth-Request (RAR) messages to the PCEF to modify, add, or delete value-added service policies.

RAA(Gx Message)

PCEF -> PCRF

After updating a policy based on an RAR message from the PCRF, the PCEF returns a Re-Auth-Answer (RAA) message to the PCRF to inform the PCRF that the policy is updated.

ASR(Optional)(Base Message)

PCRF -> PCEF

When the PCRF operates abnormally and must forcibly remove the policy on it, the PCRF sends an Abort-Session-Request (ASR) message to the PCEF. Upon receiving the ASR message, the PCEF returns an ASA message carrying a CCR-Terminate.

The ASR message is an extended message. It is used when supported by the PCEF.

ASA(Optional)(Base Message)

PCEF -> PCRF

An Abort-Session-Answer (ASA) message is the response to an ASR message.

The device receives but does not process *[AVP]. That is, the device processes only the AVPs listed in this document and ignores other optional AVPs.

Description of the Gx Interface Messages

Message Format Convention

Format

Description

<>

The fixed position of the AVP is defined.

{}

The AVP must be present and can appear anywhere in the message.

[]

The AVP is optional and can appear anywhere in a message. The number of times that the AVP appears can be 0 or 1.

*[]

The AVP can appear anywhere in a message.

This document focuses on Gx messages, including CCR/CCA and RAR/RAA messages. This document does not introduce CER/CEA messages. For details about CER/CEA messages, refer to RFC 3588.

The device receives but does not process *[AVP]. That is, the device processes only the AVPs listed in this document and ignores other optional AVPs.

CCR

Message Function

The Credit Control Request (CCR) command, indicated by the Command-Code field set to 272 and the R bit set in the Command Flags field, is sent by the PCEF to the PCRF in order to request PCC rules. The CCR command is also sent by the PCEF to the PCRF in order to indicate PCC rule related events or the termination of the IP CAN session.

There are three types of CCR message: CCR-Initial, CCR-Update, and CCR-Terminate.

  • CCR-Initial: Upon receiving an IP-CAN session establishment request message (for example, request for Internet access), the PCEF sends an IP-CAN session authorization request message to the PCRF. Based on the IP-CAN session authorization request message, the PCRF generates a charging control policy.

  • CCR-Update: CCR-Update messages are used by the PCEF to request updated PCC rules from the PCRF during the following scenarios:

    • An IP CAN session is being established, modified, or terminated.

    • UE resources change.

    • An event is triggered.

  • CCR-Terminate: After receiving a request for going offline from a user, the PCEF must terminate the IP-CAN session. The PCEF sends an IP session termination authorization request message (a CCR message) to the PCRF to instruct the PCRF to release the related policy.

CCR-Initial Message Format

<CC-Request> ::= < Diameter Header: 272, REQ, PXY >                
                      < Session-Id >                               
                     { Auth-Application-Id }                       
                     { Origin-Host }                               
                     { Origin-Realm }                              
                     [ Destination-Host ]                          
                     { Destination-Realm }                         
                     { CC-Request-Type }  [Note1]                 
                     { CC-Request-Number }  [Note2]               
                     [ Supported-Features ]                       
                             { Vendor-Id }                         
                             { Feature-List-ID }                   
                             { Feature-List }                      
                    *[ Subscription-Id ]  [Note3]                 
                             { Subscription-Id-Type }              
                             { Subscription-Id-Data }              
                     [ Framed-IP-Address ]  [Note4]               
                     [ Framed-IPv6-Prefix ]  [Note5]              
                     [ IP-CAN-Type ]  [Note6]                     
                     [ User-Equipment-Info ]  [Note7]             
                             { User-Equipment-Info-Type }          
                             { User-Equipment-Info-Value }         
                     [ X-HW-User-Physical-Info-Value ]  [Note8]   
                     [ QoS-Information ]  [Note9]                 
                             [ Max-Requested-Bandwidth-UL ]        
                             [ Max-Requested-Bandwidth-DL ]        
                             [ Guaranteed-Bitrate-UL ]             
                             [ Guaranteed-Bitrate-DL ]

Note Index

Note Description

[Note1]

In the IP-CAN session authorization establishment request message, the value of CC-Request-Type is INITIAL_REQUEST.

[Note2]

The CC-Request-Number AVP is used to distinguish requests or responses in a session because a Session-Id is globally unique. The value of this AVP is set to 0 when a session is established.

[Note3]

A CCR-Initial message must carry the Subscription-Id AVP; otherwise, a failure will occur. This AVP consists of the Subscription-Id-Type AVP and the Subscription-Id-Data AVP. For device, the Subscription-Id-Type AVP is set to END_USER_NAI. The Subscription-Id-Data AVP is set to a user name consisting of a maximum of 253 bytes (for example, 206c6d2d0000@rm-1).

[Note4]

An IP-CAN session authorization request message must include the Framed-IP-Address AVP or Framed-IPv6-Prefix AVP (specifically, it must contain a user address). Otherwise, the message is considered invalid. If a request message carries both of the preceding AVPs, the PCRF uses an IPv4 address as the user address.

[Note5]

Either an IPv6 address or the Framed-IP-Address AVP must exist.

[Note6]

The IP-CAN-Type AVP indicates the type of the access network to which users are connected for PCRF management. The value of IP-CAN-Type of the device V800R021C10SPC500 is permanently set to XDSL(2). For other values, see related AVP descriptions.

[Note7]

The User-Equipment-Info AVP is used to report user equipment information (user MAC addresses). The AVP consists of User-Equipment-Info-Type AVP and User-Equipment-Info-Value AVP. For the device V800R021C10SPC500, the received AVP is not processed.

[Note8]

The X-HW-User-Physical-Info-Value AVP is a private AVP. It is used to report physical information of a user, such as slot ID, sub-slot ID, port ID, and VLANID. The format of the X-HW-User-Physical-Info-Value AVP is similar to that of the RADIUS NAS-PORT-ID AVP and is set to a maximum of 65 bytes. An example of the X-HW-User-Physical-Info-Value AVP is: {atm|eth|trunk} NAS_slot/NAS_subslot/NAS_port:XPI.XCI.

CCR-Update Message Format

<CC-Request> ::= < Diameter Header: 272, REQ, PXY >               
                      < Session-Id >                              
                     { Auth-Application-Id }                      
                     { Origin-Host }                              
                     { Origin-Realm }                             
                     [ Destination-Host ]                         
                     { Destination-Realm }                        
                     { CC-Request-Type } [ Note 1 ]               
                     { CC-Request-Number } [ Note 2 ]             
                     [ Subscription-Id ] [ Note 3 ]               
                                { Subscription-Id-Type }          
                                { Subscription-Id-Data }          
                     [ Framed-IP-Address ] [ Note 4 ]             
                     [ Framed-IPv6-Prefix ] [ Note 5 ]            
                     [ IP-CAN-Type ] [ Note 6 ]                   
                     [ User-Equipment-Info ] [ Note 7 ]           
                                { User-Equipment-Info-Type }       
                                { User-Equipment-Info-Value }      
                     *[ Charging-Rule-Report ]                    
                                *[ Charging-Rule-Name ]       
                                [ PCC-Rule-Status ]       
                                [ Rule-Failure-Code ]       
                     [ X-HW-User-Physical-Info-Value ] [ Note 8 ] 
                     *[ Event-Trigger ] [ Note 9 ]                
                     *[ Usage-Monitoring-Information ] [ Note 10 ]
                                [ Monitoring-Key ]                
                                [ Usage-Monitoring-Level ]        
                                [ Used-Service-Unit ]             
                                           [ CC-Time ]            
                                           [ CC-Total-Octets ]    
                                [ Usage-Monitoring-Report ]

Note Index

Note Description

[Note1]

In the IP-CAN session authorization modification request message, the value of CC-Request-Type is UPDATE_REQUEST.

[Note2]

The CC-Request-Number AVP is used to distinguish requests or responses in a session because a Session-Id is globally unique. The value of CC-Request-Number increases by 1 each time a session is modified.

[Note3]

The Subscription-Id AVP consists of the Subscription-Id-Type AVP and Subscription-Id-Data AVP.

[Note4]

An IP-CAN session authorization request message must include the Framed-IP-Address AVP or Framed-IPv6-Prefix AVP (specifically, it must contain a user address). Otherwise, the message is considered invalid. If a request message carries both of the preceding AVPs, the PCRF uses an IPv4 address as the user address.

[Note5]

Either an IPv6 address or the Frame-IP-Address AVP must exist.

[Note6]

The IP-CAN-Type AVP indicates the type of the access network to which users are connected for PCRF management. The value of IP-CAN-Type of the device is permanently set to XDSL(2). For other values, see related AVP descriptions.

[Note7]

The User-Equipment-Info AVP is used to report user equipment information (user MAC addresses). This AVP consists of the User-Equipment-Info-Type AVP and the User-Equipment-Info-Value AVP.

[Note8]

X-HW-User-Physical-Info-Value is a private AVP. It is used to report physical information of a user, such as slot ID, sub-slot ID, port ID, and VLANID. The format of the X-HW-User-Physical-Info-Value AVP is similar to that of the RADIUS NAS-PORT-ID AVP and is set to a maximum of 65 bytes. An example of the X-HW-User-Physical-Info-Value AVP is: {atm|eth|trunk} NAS_slot/NAS_subslot/NAS_port:XPI.XCI.

[Note9]

The PCEF sends to the PCRF an Event-Trigger AVP to indicate the occurrence of an event on the gateway. While the event is ongoing, the PCEF sends the affected AVPs in addition to the Event-Trigger AVP. For the value range, see the related AVP definition.

[Note10]

The Usage-Monitoring-Information AVP in a CCR-Update message indicates the quota amount used by a user. Its format is as follows:

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

[ Monitoring-Key ]----This sub-AVP must be carried.

[ Used-Service-Unit ]----Indicates the used quota amount, including the traffic volume or duration quota.

[ Usage-Monitoring-Level ]----Indicates the monitoring level (session level or rule level).

CCR-Terminate Message Format

<CC-Request> ::=  < Diameter Header: 272, REQ, PXY >                  
                       < Session-Id >                                 
                       { Auth-Application-Id }                        
                       { Origin-Host }                                
                       { Origin-Realm }                               
                       [ Destination-Host ]                           
                       { Destination-Realm }                          
                       { CC-Request-Type } [ Note 1 ]                 
                       { CC-Request-Number } [ Note 2 ]               
                       [ Event-Trigger ] [ Note 3 ]                   
                       *[ Usage-Monitoring-Information ] [ Note 4 ]   
                           [ Monitoring-Key ]                         
                           [ Usage-Monitoring-Level ]                 
                           [ Used-Service-Unit ]                      
                                  [ CC-Time ]                         
                                  [ CC-Total-Octets ]                 
                           *[ AVP ]                 
                           [ Usage-Monitoring-Report ]    
 
                       { Termination-Cause } [ Note 5 ]

Note Index

Note Description

[Note1]

In the IP-CAN session termination authorization request message, the value of the CC-Request-Type AVP is TERMINATION_REQUEST. The PCRF usually focuses on only the Termination-Cause AVP in the IP-CAN session termination authorization request message.

[Note2]

The CC-Request-Number AVP is used to distinguish requests or responses in a session because a Session-Id is globally unique. The value of CC-Request-Number increases by 1 each time a session is modified.

[Note3]

The Event-Trigger AVP is set to USAGE-REPORT, indicating that usage is monitored and reported.

[Note4]

The Usage-Monitoring-Information AVP carries the accumulated usage (quota fragment) of a user. Its format is as follows:

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

[ Monitoring-Key ]----If this AVP is not carried, the monitoring is at session level.

[ Used-Service-Unit ]----Indicates the used quota amount, including the traffic volume or duration quota.

[ Usage-Monitoring-Level ]----Indicates the monitoring level (session level or rule level).

[Note5]

The Termination-Cause AVP indicates the cause of the user's logout. When a user logs out normally, this AVP is set to DIAMETER_LOGOUT 1. Other values indicate that a user logs out abnormally. For details, see related AVP description.

Reference Standards

3GPP TS 29.212 V9.7.0 clause 5.6.2

CCA (Credit-Control-Answer)

Message Function

The Credit Control Answer (CCA) command, indicated by the Command-Code field set to 272 and the 'R' bit cleared in the Command Flags field, is sent by the PCRF to the PCEF in response to the CCR command. It is used to provision PCC rules and event triggers for the session and to provide the selected bearer control mode for the IP-CAN session. If the PCRF performs the bearer binding, PCC rules will be provisioned at bearer level. The primary and secondary CCF and/or primary and secondary OCS addresses may be included in the initial provisioning.

here are three types of CCA message: CCA-Initial, CCA-Update and CCA-Terminate.

  • CCA-Initial: After processing the IP-CAN session authorization establishment request message, the PCRF generates a policy and sends it to the PCEF through an IP-CAN session authorization answer message.

  • CCA-Update: After processing the IP-CAN session authorization update request message, the PCRF generates a policy and sends it to the PCEF through an IP-CAN session authorization answer message.

  • CCA-Terminate: After processing an IP-CAN session authorization request message, the PCRF generates a policy and sends it to the PCEF through an IP-CAN session termination authorization answer message.

CCA-Initial Message Format

<CC-Answer> ::=  < Diameter Header: 272, PXY >              
                 < Session-Id >                             
                 { Auth-Application-Id }                    
                 { Origin-Host }                            
                 { Origin-Realm }                           
                 [ Result-Code ] [ Note 1]                  
                 [ Experimental-Result ]                    
                          { Vendor-Id }                     
                          { Experimental-Result-Code }      
                 { CC-Request-Type }             
                 { CC-Request-Number }                      
                *[ Event-Trigger ] [ Note 2]                
                *[ Charging-Rule-Install ] [ Note 3]        
                          *[ Charging-Rule-Definition ]          
                                    { Charging-Rule-Name }             
                                    [ QoS-Information ]    
                                            [ Max-Requested-Bandwidth-UL ]   
                                            [ Max-Requested-Bandwidth-DL ]   
                                            [ Guaranteed-Bitrate-UL ]        
                                            [ Guaranteed-Bitrate-DL ]        
                                            *[ AVP ]                           
                                   [ Monitoring-Key ]                 
                                   [ X-HW-Service-Type ]     
                                   [ X-HW-ACL-Group-Name ]   
                                   [ X-HW-Interim-Interval ] 
                                   *[AVP]                             
                          *[ Charging-Rule-Name ]                
                          *[ AVP ]                                 
                *[ QoS-Information ] [ Note 4]              
                          [ Max-Requested-Bandwidth-UL ]         
                          [ Max-Requested-Bandwidth-DL ]         
                          [ Guaranteed-Bitrate-UL ]              
                          [ Guaranteed-Bitrate-DL ]              
                          *[ AVP ]                                 
                *[ Usage-Monitoring-Information ] [ Note 5] 
                      [ Monitoring-Key ]                    
                      [ Granted-Service-Unit ]              
                         [ CC-Time ]                        
                         [ CC-Total-Octets ]                
                         *[AVP]                             
                      [ Usage-Monitoring-Level ]            
                      [ Usage-Monitoring-Report ]           
      
                      *[AVP]                                
                 *[AVP]

The device receives but does not process *[AVP]. That is, the device processes only the AVPs listed in this document and ignores other optional AVPs.

Note Index

Note Description

[Note1]

Either the Result-Code AVP or Experimental-Result AVP must exist.

[Note2]

This AVP indicates a group AVP for policy deletion. In case of a dynamic policy, the Charging-Rule-Name AVP indicates the PCC rule name generated by the PCRF. Otherwise, the AVP indicates the predefined rule name.

[Note3]
This AVP indicates the installation policy and consists of the Charging-Rule-Definition and Charging-Rule-Name AVPs.
  • The Charging-Rule-Definition AVP refers to the PCC rule generated on the PCRF and is usually called a dynamic policy. This AVP also consists of several AVPs.
  • The Charging-Rule-Name AVP refers to the policy configured on the PCEF. On the PCEF, only the rule name (template name) must be provided to instruct the PCEF to apply a rule to a service flow, providing the definition of the rule is not required. A policy is activated or deactivated depending on the predefined rule and is generally called a static policy.

[Note4]

The QoS-Information AVP at the command level includes user bandwidth information. The QoS-Information AVP at the service level refers to the QoS-Information AVP in the Charging-Rule-Definition AVP.

[Note5]

The Usage-Monitoring-Information AVP in CCA-Initial message indicates the usage allocated by the PCRF.

[Note6]

When the Event-Trigger AVP is sent by the PCRF to the PCEF, the Event-Trigger AVP indicates an event in which the PCC rule is requested again.

CCA-Update Message Format

<CC-Answer> ::=  < Diameter Header: 272, PXY >                       
                 < Session-Id >                                      
                 { Auth-Application-Id }                             
                 { Origin-Host }                                     
                 { Origin-Realm }                                    
                 [ Result-Code ] [ Note 1]                           
                 [ Experimental-Result ]                             
                         { Vendor-Id }                               
                         { Experimental-Result-Code }                
                 { CC-Request-Type }                              
                 { CC-Request-Number }                            
                 *[ Supported-Features ]
                 *[ Event-Trigger ] [ Note 2]                      
                 *[ Charging-Rule-Remove ] [ Note 3]               
                         *[ Charging-Rule-Name ]                     
                         *[ AVP ]                                    
                 *[ Charging-Rule-Install ] [ Note 4]              
                         *[ Charging-Rule-Definition ]        
                                 { Charging-Rule-Name }              
                                 [ QoS-Information ]                 
                                       [ Max-Requested-Bandwidth-UL ]
                                       [ Max-Requested-Bandwidth-DL ]
                                       [ Guaranteed-Bitrate-UL ]     
                                       [ Guaranteed-Bitrate-DL ]     
                                      *[ AVP ]                       
                                 [ Monitoring-Key ]                  
                                 [ X-HW-Service-Type ]              
                                 [ X-HW-ACL-Group-Name ]          
                                 [ X-HW-Interim-Interval ]           
                                *[ AVP ]                             
                         *[ Charging-Rule-Name ]                     
                         *[ AVP ]                                    
                 *[ QoS-Information ] [ Note 5]                     
                          [ Max-Requested-Bandwidth-UL ]             
                          [ Max-Requested-Bandwidth-DL ]             
                          [ Guaranteed-Bitrate-UL ]                  
                          [ Guaranteed-Bitrate-DL ]                  
                         *[ AVP ]                                    
                  *[ Usage-Monitoring-Information ] [ Note 6]       
                          [ Monitoring-Key ]                         
                          [ Granted-Service-Unit ]                   
                                 [ CC-Time ]                         
                                 [ CC-Total-Octets ]                 
                                 [ CC-Output-Octets ]
                                *[ AVP ]                             
                          [ Usage-Monitoring-Level ]                 
                          [ Usage-Monitoring-Report ]                
       
                         *[ AVP ]

The device receives but does not process *[AVP]. That is, the device processes only the AVPs listed in this document and ignores other optional AVPs.

Note Index

Note

[Note1]

The Result-Code AVP is an error code. Either the Result-Code or Experimental-Result AVP must exist.

[Note2]

When the Event-Trigger AVP is sent by the PCRF to the PCEF, the Event-Trigger AVP indicates an event in which the PCC rule is requested again.

[Note3]

The Charging-Rule-Remove AVP indicates a removal policy and consists of several AVPs. If the policy is a dynamic policy, the Charging-Rule-Name AVP is the PCC rule name generated by the PCRF. Otherwise, the Charging-Rule-Name AVP is the predefined rule name.

[Note4]
The Charging-Rule-Install AVP indicates the installation policy and consists of the Charging-Rule-Definition and Charging-Rule-NameAVPs.
  • The Charging-Rule-Definition AVP refers to the PCC rule generated on the PCRF and is usually called a dynamic policy. This AVP also consists of several AVPs.
  • The Charging-Rule-Name AVP refers to the policy configured on the PCEF. On the PCRF, only the rule name (template name) must be provided to instruct the PCEF to apply a rule to a service flow; providing the definition of the rule is not required. A policy is activated or deactivated depending on the predefined rule and is generally called a static policy.

[Note4]

The QoS-Information AVP at the command level includes user bandwidth information. The QoS-Information AVP at the service level refers to the QoS-Information AVP in the Charging-Rule-Definition AVP.

[Note5]

The QoS-Information AVP at the command level includes user bandwidth information. The QoS-Information AVP at the service or rule level refers to the QoS-Information AVP in the Charging-Rule-Definition AVP.

[Note6]

The Usage-Monitoring-Information AVP in a CCA-Update message indicates the amount used by the user.

CCA-Terminate Message Format

<CC-Answer> ::=  < Diameter Header: 272, PXY >   
                   < Session-Id >                
                   { Auth-Application-Id }       
                   { Origin-Host }               
                   { Origin-Realm }              
                   [ Result-Code ] [Note1]       
                   [ Experimental-Result ]       
                        { Vendor-Id }               
                        { Experimental-Result-Code }
                   { CC-Request-Type}          
                   { CC-Request-Number}          
                   *[ AVP ]

The device receives but does not process *[AVP]. That is, the device processes only the AVPs listed in this document and ignores other optional AVPs.

Note Index

Note Description

[Note1]

Both the Result-Code AVP and the Experimental-Result-Code AVP define an error code. In an IP-CAN session termination authorization answer message, either the Result-Code or Experimental-Result-Code AVP must exist.

Reference Standards

3GPP TS 29.212 V9.7.0 clause 5.6.3

RAR

Message Function

The Re-Auth-Request (RAR) command, indicated by the Command-Code field set to 258 and the R bit set in the Command Flags field, is sent by the PCRF to the PCEF in order to provision PCC rules using the PUSH procedure initiate the provision of unsolicited PCC rules. It is used to provision PCC rules, event triggers and event report indications for the session. If the PCRF performs the bearer binding, PCC rules will be provisioned at bearer level.

Message Format

<RA-Request> ::= < Diameter Header: 258, REQ, PXY >             
                 < Session-Id >                                 
                 { Auth-Application-Id }                        
                 { Origin-Host }                                
                 { Origin-Realm }                               
                 { Destination-Realm }                          
                 { Destination-Host }                           
                 { Re-Auth-Request-Type } [ Note 1 ]            
                 *[ Event-Trigger ] [ Note 2 ]                  
                 *[ Charging-Rule-Remove ] [ Note 3 ]           
                     *[ Charging-Rule-Name ]                    
                     *[ AVP ]                                   
                 *[ Charging-Rule-Install ] [ Note 4 ]          
                     *[ Charging-Rule-Definition ]              
                           { Charging-Rule-Name }                 
                           [ QoS-Information ]                    
                                 [ Max-Requested-Bandwidth-UL ] 
                                 [ Max-Requested-Bandwidth-DL ] 
                                 [ Guaranteed-Bitrate-UL ]      
                                 [ Guaranteed-Bitrate-DL ]      
                           [ Monitoring-Key ]                     
                           [ X-HW-Service-Type ]                  
                           [ X-HW-ACL-Group-Name ]                
                           [ X-HW-Interim-Interval ]              
                           *[ AVP ]                               
                     *[ Charging-Rule-Name ]                   
                     *[ AVP ]                                  
                 *[ QoS-Information ] [ Note 5 ]                
                      [ Max-Requested-Bandwidth-UL ]            
                      [ Max-Requested-Bandwidth-DL ]            
                      [ Guaranteed-Bitrate-UL ]                 
                      [ Guaranteed-Bitrate-DL ]                 
                      *[ AVP ]                                  
                 *[ Usage-Monitoring-Information ] [ Note 6 ]   
                          [ Monitoring-Key ]                         
                          [ Granted-Service-Unit ]                   
                                 [ CC-Time ]                         
                                 [ CC-Total-Octets ]                 
                                 [ CC-Output-Octets ]
                                *[ AVP ]                             
                          [ Usage-Monitoring-Level ]                 
                          [ Usage-Monitoring-Report ]                
       
                         *[ AVP ]

An device receives but does not process *[AVP] in the message format description. This means that the device processes the AVPs described in this document but ignores other AVPs.

Note Index

Note Description

[Note1]

The Re-Auth-Request-Type AVP is set to AUTHORIZE_ONLY, indicating an authorization request.

[Note2]

When the Event-Trigger AVP is sent by the PCRF to the PCEF, the Event-Trigger AVP indicates an event in which the PCC rule is requested again.

[Note3]

The Charging-Rule-Remove AVP indicates a removal policy and consists of several AVPs. If the policy is a dynamic policy, the Charging-Rule-Name AVP is the PCC rule name generated by the PCRF. Otherwise, the Charging-Rule-Name AVP is the predefined rule name.

[Note4]
The Charging-Rule-Install AVP indicates the installation policy and consists of the Charging-Rule-Definition and Charging-Rule-Name AVPs.
  • The Charging-Rule-Definition AVP refers to the PCC rule generated on the PCRF and is usually called a dynamic policy. This AVP also consists of several AVPs.
  • The Charging-Rule-Name AVP refers to the policy configured on the PCEF. On the PCRF, only the rule name (template name) must be provided to instruct the PCEF to apply a rule to a service flow; providing the definition of the rule is not required. A policy is activated or deactivated depending on the predefined rule and is generally called a static policy.

[Note5]

The QoS-Information AVP at the command level includes user bandwidth information. The QoS-Information AVP at the service or rule level refers to the QoS-Information AVP in the Charging-Rule-Definition AVP.

[Note6]

The Usage-Monitoring-Information AVP consists of several AVPs. CCA-Initial indicates the usage allocated by the PCRF.

Reference Standards

3GPP TS 29.212 V9.7.0 clause 5.6.4

RAA (Re-Auth-Answer)

Message Function

The Re-Auth-Answer (RAA) command, indicated by the Command-Code field set to 258 and the R bit cleared in the Command Flags field, is sent by the PCEF to the PCRF in response to the RAR command.

Message Format

<RA-Answer> ::=  < Diameter Header: 258, PXY >
                    < Session-Id >
                    { Origin-Host }
                    { Origin-Realm }
                    [ Result-Code ]
                    [ Experimental-Result ] [ Note 1 ]
                         { Vendor-Id }
                         { Experimental-Result-Code }
                   *[ Charging-Rule-Report] [ Note 2 ]
                         *[ Charging-Rule-Name ]
                         [ PCC-Rule-Status ]
                         [ Rule-Failure-Code ]

Note Index

Note Description

[Note1]

The Experimental-Result AVP includes the error codes for request processing allocated by vendors. It is specified by the protocol stack. When a PCC rule cannot be deployed or activated, the Experimental-Result AVP is set to DIAMETER_PCC_RULE_EVENT(5142). If an RAA message does not include the result code, the PCRF considers the result to be success.

[Note2]

The Charging-Rule-Report AVP indicates the execution result of a PCC rule and consists of several AVPs.

Reference Standards

3GPP TS 29.212 V9.7.0 clause 5.6.5

Abort-Session-Request (ASR)

Message Function

The PCRF sends an ASR message to the PCEF to stop the service of a specified Session-Id. The Command-Code is set to 274, and the R bit in the flag field is set.

Message Format

<ASR> ::=  < Diameter Header: 274, REQ, PXY >
                    < Session-Id >
                    { Origin-Host }
                    { Origin-Realm }
                    { Destination-Realm }
                    { Destination-Host }
                    { Auth-Application-Id }
                    [ User-Name ]
                    [ Origin-State-Id ]
                  * [ Proxy-Info ]
                  * [ Route-Record ]
                  * [ AVP ]

References

Section 8.5.1 in RFC 3588

Abort-Session-Answer (ASA)

Message Function

After receiving an ASR message, the PCEF sends an ASA message to the PCRF. The Command-Code is set to 274, and the R bit in the flag field is cleared.

Message Format

<ASA> ::=  < Diameter Header: 274, PXY >
                    < Session-Id >
                    { Result-Code }[Note 1]
                    { Origin-Host }
                    { Origin-Realm }
                    [ User-Name ]
                    [ Origin-State-Id ]
                    [ Error-Message ]
                    [ Error-Reporting-Host ]
                    [ Failed-AVP ]
                  * [ Redirect-Host ]
                    [ Redirect-Host-Usage ]
                    [ Redirect-Max-Cache-Time ]
                  * [ Proxy-Info ]
                  * [ AVP ]

Note ID

Remarks

[Note 1]
  • DIAMETER_SUCCESS indicates that the session is successfully ended.
  • DIAMETER_UNKNOWN_SESSION_ID indicates that the session is not activated.
  • DIAMETER_UNABLE_TO_COMPLY indicates that the session is not ended. For example, a Diameter activated DAA service exists.

References

Section 8.5.2 in RFC 3588

Description of Associated AVPs

AVP Format Convention

Format

Description

<>

The fixed position of the AVP is defined.

{}

The AVP must be present and can appear anywhere in a message.

[]

The AVP is optional and can appear anywhere in a message. The number of times that the AVP appears can be 0 or 1.

*[]

The AVP can appear anywhere in a message.

Auth-Application-Id AVP

Description of AVP

AVP

Description

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.

NOTE:

On the device, the Auth-Application-Id AVP indicates the specific application of a Diameter message, and the value of Auth-Application-Id used by PCC on a Gx interface is 16777238.

The Auth-Application-Id AVP is a sub-AVP, which is used in the group AVP vendor-specific-application-id.

Reference Standards

RFC 3588 clause 6.8

CC-Output-Octets AVP

Description

AVP

Description

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.

References

RFC 4006 clause 8.25

CC-Request-Number AVP

Description of AVP

AVP

Description

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.

NOTE:

On the device, the CC-Request-Number AVP identifies the sequence number of the CCR message.

The count starts from 0 and the value does not change in retransmitted messages.

This AVP is used independently.

Reference Standards

RFC 4006 clause 8.2

CC-Request-Type AVP

Description of AVP

AVP

Description

CC-Request-Type
The CC-Request-Type AVP (AVP Code 416) is of type Enumerated and contains the reason for sending the credit-control request message. It must be present in all Credit-Control-Request messages. The following values are defined for the CC-Request-Type AVP:

  • INITIAL_REQUEST(1)

    An Initial request is used to initiate a credit-control session, and contains credit control information relevant to the initiation.

  • UPDATE_REQUEST(2)

    An Update request contains information about an existing credit-control session. An Update credit-control request needs to be sent each time a credit-control re-authorization is required at the expiry of the allocated quotas or validity time. In addition, additional service-specific events may trigger an Update request.

  • 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 status in the credit-control server. This request contains all information relevant to the service, and can be only used for a service request. The reason for the Event request is further detailed in the Requested-Action AVP. The Requested-Action AVP must be carried in Credit-Control-Request messages when CC-Request-Type is set to EVENT_REQUEST.

NOTE:

This AVP is used independently.

Currently, the device supports the following types of CC requests:

  • INITIAL_REQUEST(1)
  • UPDATE_REQUEST(2)
  • TERMINATION_REQUEST(3)

Reference Standards

RFC 4006 clause 8.3

CC-Time AVP

Description of AVP

AVP

Description

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.

References

RFC 4006 clause 8.21

CC-Total-Octets AVP

Description

AVP

Description

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.

References

RFC 4006 clause 8.23

Charging-Rule-Definition AVP

Description of AVP

AVP

Description

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 ]
NOTE:

The device receives but does not process *[AVP] in the AVP format description, that is, the device processes the AVPs listed in this document and ignores other AVPs.

The Charging-Rule-Definition AVP is a sub-AVP, which is used in the group AVP charging-rule-install. The Charging-Rule-Definition AVP is also a group AVP, which contains the charging-rule-name, precedence, gx-x-hw-service-type, qos-information, and gx-r9-usage-monitoring-key sub-AVPs.

Reference Standards

3GPP TS 29.212 V9.7.0 clause 5.3.4

Charging-Rule-Install AVP

Description of AVP

AVP

Description

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 ]
NOTE:

The device receives but does not process *[AVP] in the AVP format description, that is, the device processes the AVPs listed in this document and ignores other AVPs.

The Charging-Rule-Install AVP is a group AVP, which contains the charging-rule-definition and charging-rule-name sub-AVPs.

Reference Standards

3GPP TS 29.212 V9.7.0 clause 5.3.2

Charging-Rule-Name AVP

Description of AVP

AVP

Description

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.

Reference Standards

3GPP TS 29.212 V9.7.0 clause 5.3.6

Charging-Rule-Remove AVP

Description of AVP

AVP

Description

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 ]
NOTE:

The device receives but does not process *[AVP] in the AVP format description, that is, the device processes the AVPs listed in this document and ignores other AVPs.

Reference Standards

3GPP TS 29.212 V9.7.0 clause 5.3.3

Charging-Rule-Report AVP

Description of AVP

AVP

Description

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]
NOTE:

The device receives but does not process *[AVP] in the AVP format description, that is, the device processes the AVPs listed in this document and ignores other AVPs.

The Charging-Rule-Report AVP is a group AVP, which contains the charging-rule-name, pcc-rule-status, rule-failure-code, and final-unit-indication sub-AVPs.

Reference Standards

3GPP TS 29.212 V9.7.0 clause 5.3.18

Destination-Host AVP

Description of AVP

AVP

Description

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.

Reference Standards

RFC 3588 clause 6.5

Destination-Realm AVP

Description of AVP

AVP

Description

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.

Reference Standards

RFC 3588 clause 6.6

Error-Message AVP

Description of AVP

AVP

Description

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.

Reference Standards

RFC 3588 clause 7.3

Experimental-Result AVP

Description of AVP

AVP

Description

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 }

Reference Standards

RFC 3588 clause 7.6

Experimental-Result-Code AVP

Description of AVP

AVP

Description

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.

Reference Standards

RFC 3588 clause 7.7

Event-Trigger AVP

Description of AVP

AVP

Description

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.

The following values are defined in 3GPP TS 29.212 V9.7.0:
  • SGSN_CHANGE (0)
  • QOS_CHANGE (1)
  • RAT_CHANGE (2)
  • TFT_CHANGE (3)
  • PLMN_CHANGE (4)
  • LOSS_OF_BEARER (5)
  • RECOVERY_OF_BEARER (6)
  • IP-CAN_CHANGE (7)
  • QOS_CHANGE_EXCEEDING_AUTHORIZATION (11)
  • RAI_CHANGE (12)
  • USER_LOCATION_CHANGE (13)
  • NO_EVENT_TRIGGERS (14)
  • OUT_OF_CREDIT (15)
  • REALLOCATION_OF_CREDIT (16)
  • REVALIDATION_TIMEOUT (17)
  • UE_IP_ADDRESS_ALLOCATE (18)
  • UE_IP_ADDRESS_RELEASE (19)
  • DEFAULT_EPS_BEARER_QOS_CHANGE (20)
  • AN_GW_CHANGE (21)
  • SUCCESSFUL_RESOURCE_ALLOCATION (22)
  • RESOURCE_MODIFICATION_REQUEST (23)
  • PGW_TRACE_CONTROL (24)
  • UE_TIME_ZONE_CHANGE (25)
  • TAI_CHANGE (26)
  • ECGI_CHANGE (27)
  • CHARGING_CORRELATION_EXCHANGE (28)
  • APN-AMBR_MODIFICATION_FAILURE (29)
  • USER_CSG_INFORMATION_CHANGE (30)
  • USAGE_REPORT (33)

  • DEFAULT-EPS-BEARER-QOS_MODIFICATION_FAILURE (34)

  • USER_CSG_HYBRID_SUBSCRIBED_INFORMATION_CHANGE (35)

  • USER_CSG_HYBRID_UNSUBSCRIBED_INFORMATION_CHANGE (36)

NOTE:

The Event-Trigger AVP is used independently.

The following values are supported for the Event-Trigger AVP on the device:

  • LOSS_OF_BEARER_3GPP (5): This value is used in the CCA and RAR messages sent by the PCRF to indicate that the PCEF informs the PCRF of bearer loss. For example, a service is not enabled or a delivered service rule cannot be activated or installed. In this case, the bearer of the service is thought to be lost. The PCEF informs the PCRF of bearer restoration after the service is enabled or the PCRF delivers the service rule. When used in a CCR message, the LOSS_OF_BEARER_3GPP value indicates that the PCEF sends the CCR message because the bearer associated with the PCC rule indicated by the Charging-Rule-Report AVP is lost. In the Charging-Rule-Report AVP, the PCC-Rule-Status AVP should indicate that the PCC rule is temporarily inactive (TEMPORARILY_INACTIVE).

  • RECOVERY_OF_BEARER_3GPP (6): This value is used in the CCA and RAR messages sent by the PCRF to indicate that the gateway informs the PCRF of bearer restoration. When used in a CCR message, the RECOVERY_OF_BEARER_3GPP value indicates that the PCEF sends the CCR message because the bearer associated with the PCC rule indicated by the Charging-Rule-Report AVP is restored. In the Charging-Rule-Report AVP, the PCC-Rule-Status AVP should indicate that the PCC rule becomes active again (ACTIVE).

  • IP_CAN_CHANGE (7): When the access mode of a user changes, the PCEF sends a message carrying the new access mode to request the PCRF to deliver the relevant policy to implement policy control. The policy delivered by the PCRF varies with the user access mode (3GPP/DOCSIS/xDSL/WIMAX/3GPP2). The IP_CAN_CHANGE trigger must be configured when policy control is implemented based on access mode.

  • USAGE_REPORT (33): When the PCRF sends the quota through the Usage-Monitoring-Information AVP (including the Monitoring-Key AVP and the Granted-Service-Unit AVP) in a CCA or RAR message, the PCRF must also send the Event-Trigger of USAGE_REPORT. When the PCEF reports usage through the Usage-Monitoring-Information AVP (including the Monitoring-Key AVP and the Used-Service-Unit AVP) in a CCR message, the PCEF must send the Event-Trigger of USAGE_REPORT to implement policy control based on the status of accounts or the quotas.

    NOTE:

    NetEngine 8100 M, NetEngine 8000E M, NetEngine 8000 M can identify USAGE_REPORT(26) by default. After receiving an Event-Trigger AVP with a value of 33, NetEngine 8100 M, NetEngine 8000E M, NetEngine 8000 M does not process it.

Reference Standards

3GPP TS 29.212 V9.7.0 clause 5.3.7

Feature-List AVP

Description

AVP

Description

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.

References

3GPP TS 29.212 V9.7.0 clause 5.4.1

3GPP TS 29.229 V8.7.0 clause 6.3.31

Feature-List-ID AVP

Description

AVP

Description

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.

References

3GPP TS 29.212 V9.7.0 clause 5.4.1

3GPP TS 29.229 V8.7.0 clause 6.3.30

Framed-IP-Address AVP

Description of AVP

AVP

Description

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.

Reference Standards

RFC 4005 clause 6.11.1

Framed-IPv6-Prefix AVP

Description of AVP

AVP

Description

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.

Three IPv6 address formats are supported:

  • The complete format is X:X:X:X:X:X:X:X, in which each X is a 16-bit hexadecimal address segment, for example: 2001:DB8:7654:4210:FEDC:BA98:7654:3210 and 2001:DB8:0:0:0:8:800:201C:417A. Zeros in front of each group of values can be omitted. For example, 0008 can appear as 8.

  • The "::" symbol is used to replace the 16 octets with multiple zeros. It can appear only once in an address. The symbol can also be used to compress zeros in the front and rear parts of an address. For example:
    • 2001:DB8:0:0:0:8:800:201C:417A->2001:DB8::8:800:201C:417A

    • 2001:DB8:0:0:0:0:0:101->2001:DB8::101

    • 0:0:0:0:0:0:0:1->::1

    • 0:0:0:0:0:0:0:0->::

  • An IPv6 address containing an IPv4 address is expressed in the format X:X:X:X:X:X.D.D.D.D, in which the Xs are high-order 16-bit hexadecimal values and the Ds are low-order 8-bit decimal values (expressed in IPv4 format). For example:

    • 2001:DB8:0:0:0:0:192.168.32.29

    • 2001:DB8:0:0:0:FFFF:192.168.32.30

    The preceding addresses can be written as: 2001:DB8::192.168.32.29 and 2001:DB8::FFFF.192.168.32.30.

Reference Standards

RFC 4005 clause 6.11.6

Granted-Service-Unit AVP

Description of AVP

AVP

Description

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 ]
NOTE:

The device receives but does not process *[AVP] in the AVP format description, that is, the device processes the AVPs listed in this document and ignores other AVPs.

Reference Standards

RFC 4006 clause 8.17

Guaranteed-Bitrate-DL AVP

Description of AVP

AVP

Description

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.

Reference Standards

3GPP TS 29.212 V9.7.0 clause 5.3.25

Guaranteed-Bitrate-UL AVP

Description of AVP

AVP

Description

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:

Reference Standards

3GPP TS 29.212 V9.7.0 clause 5.3.26

IP-CAN-Type AVP

Description of AVP

AVP

Description

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.

The following values are defined in 3GPP TS 29.212:

  • 3GPP-GPRS (0)

    This value shall be used to indicate that the IP-CAN is associated with a 3GPP GPRS access that is connected to the GGSN based on the Gn/Gp interfaces and is further detailed by the RAT-Type AVP. RAT-Type AVP will include applicable 3GPP values, except EUTRAN.

  • DOCSIS (1)

    This value shall be used to indicate that the IP-CAN is associated with a DOCSIS access.

  • xDSL (2)

    This value shall be used to indicate that the IP-CAN is associated with an xDSL access.

  • WiMAX (3)

    This value shall be used to indicate that the IP-CAN is associated with a WiMAX access (IEEE 802.16).

  • 3GPP2 (4)

    This value shall be used to indicate that the IP-CAN is associated with a 3GPP2 access connected to the 3GPP2 packet core as specified in 3GPP2 X.S0011 [20] and is further detailed by the RAT-Type AVP.

  • 3GPP-EPS (5)

    This value shall be used to indicate that the IP-CAN associated with a 3GPP EPS access and is further detailed by the RAT-Type AVP.

  • Non-3GPP-EPS (6)

    This value shall be used to indicate that the IP-CAN associated with an EPC based non-3GPP access and is further detailed by the RAT-Type AVP.

NOTE:
For device, the value range of IP-CAN-Type AVP is as follows:

  • xDSL (2)

    This value shall be used to indicate that the IP-CAN is associated with an xDSL access.

  • WLAN (1050)

    This value shall be used to indicate that the IP-CAN is associated with a WLAN access.

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.

Reference Standards

3GPP TS 29.212 V9.7.0 clause 5.3.27

Max-Requested-Bandwidth-DL AVP

Description of AVP

AVP

Description

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.

Reference Standards

3GPP TS 29.214 V11.6.0 clause 5.3.14

Max-Requested-Bandwidth-UL AVP

Description of AVP

AVP

Description

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.

Reference Standards

3GPP TS 29.214 V11.6.0 clause 5.3.15

Monitoring-Key AVP

Description of AVP

AVP

Description

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.

NOTE:

On the device, the value of the Monitoring-Key AVP is set to 9 for BOD services and must also be set to 9 on the PCRF for BOD services.

The Monitoring-Key AVP is a sub-AVP, which is used in the group AVP Gx-R9-Usage-Monitoring-Info.

Reference Standards

3GPP TS 29.212 V9.7.0 clause 5.3.59

Origin-Host AVP

Description of AVP

AVP

Description

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.

Reference Standards

RFC 3588 clause 6.3

Origin-Realm AVP

Description of AVP

AVP

Description

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.

NOTE:

On the device, the Origin-Realm AVP indicates the domain name contained in Local Info that is configured on the PCEF, which is the peer domain for the PCRF.

The Origin-Realm AVP is used independently.

Reference Standards

RFC 3588 clause 6.4

Origin-State-Id

Description of AVP

AVP

Description

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.

NOTICE:

The device can receives but does not process the Origin-State-Id AVP.

Reference Standards

RFC 3588 clause 8.16

PCC-Rule-Status AVP

Description of AVP

AVP

Description

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

Reference Standards

3GPP TS 29.212 V9.7.0 clause 5.3.19

QoS-Information AVP

Description of AVP

AVP

Description

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]
NOTE:

The device receives but does not process *[AVP] in the AVP format description, that is, the device processes the AVPs listed in this document and ignores other AVPs.

The device supports only the QoS-Information attribute as a sub-attribute of Charging-Rule-Definition for delivery.

The QoS-Information AVP is a sub-AVP, which is used in the group AVP Charging-Rule-Definition. The QoS-Information AVP is also a group AVP, which contains the Qos-Class-Identifier, Max-Requested-Bandwidth-UL, Max-Requested-bandwidth-DL, Guaranteed-Bitrate-UL, and Guaranteed-Bitrate-DL sub-AVPs.

Reference Standards

3GPP TS 29.212 V9.7.0 clause 5.3.16

Re-Auth-Request-Type AVP

Description of AVP

AVP

Description

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.

NOTE:

device does not support the AVP.

Reference Standards

RFC 3588 clause 8.12

Result-Code AVP

Description of AVP

AVP

Description

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.

Reference Standards

RFC 3588 clause 7.1

Rule-Failure-Code AVP

Description of AVP

AVP

Description

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.

Reference Standards

3GPP TS 29.212 V9.7.0 clause 5.3.38

Session-Id AVP

Description of AVP

AVP

Description

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 must be globally and eternally unique, as it is meant to uniquely identify a user session without reference to any other information, and may be needed to correlate historical authentication information with accounting information. The Session-Id includes a mandatory portion and an implementation-defined portion; a recommended format for the implementation-defined portion is outlined below.

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

    • <high 32 bits> and <low 32 bits> are decimal representations of the high and low 32 bits of a monotonically increasing 64-bit value. The 64-bit value is rendered in two parts to simplify formatting by 32-bit processors. At startup, the high 32 bits of the 64-bit value MAY be initialized to the time, and the low 32 bits MAY be initialized to zero. This will for practical purposes eliminate the possibility of overlapping Session-Ids after a reboot, assuming the reboot process takes longer than a second. Alternatively, an implementation may keep track of the increasing value in non-volatile memory.

    • <optional value> is implementation specific but may include a modem's device ID, a layer 2 address, or a timestamp.

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.

NOTE:

The Session-Id AVP has a maximum of 127 bytes. This AVP is generated by the PCEF and must be unique on the entire network to avoid misoperation when resources are inconsistent.

On an device, the format is:
  • host-name: the local host name of the device.
  • active-time: the TICK value of the subrack, 32 bits.
  • MID: a fixed value of 1. It is 32 bits.
  • user-ID: the index of a user.

Reference Standards

RFC 3588 clause 8.8

Session-Release-Cause AVP

Description of AVP

AVP

Description

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)
NOTICE:

For the release of an IP-CAN session initiated by the PCRF, 3GPP defines three different mechanisms successively. The first mechanism is based on Diameter based protocol (DBP) ASR/ASA messages; the second mechanism is based on the RAR messages (in which all deployed rules are removed) sent by the PCRF; the third mechanism is based on the RAR messages (carrying the Session-Release-Cause AVP) sent by the PCRF. The PCEF removes the deployed policies and sends a CCR-T message to the PCRF, requesting the PCRF to terminate an IP-CAN session. From the angle of interoperability and compatibility, the third mechanism is mandatory and the other two are optional.

Reference Standards

3GPP TS 29.212 V9.7.0 clause 5.3.44

Subscription-Id AVP

Description of AVP

AVP

Description

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 }
NOTE:

On the device, the Subscription-Id-Type AVP is set to END_USER_NAI (3) On an device, the Subscription-Id-Data AVP is set to a user name consisting of at most 253 bytes (such as 50ec931b0000@rm-3).

The Subscription-Id AVP is a group AVP, which contains the Subscription-id-Type and Subscription-id-Data sub-AVPs.

Reference Standards

RFC 4006 clause 8.46

Subscription-Id-Data AVP

Description of AVP

AVP

Description

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.

References

RFC 4006 clause 8.48

Subscription-Id-Type AVP

Description of AVP

AVP

Description

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.

The values are as follows:
  • END_USER_E164(0): The identifier is in international E.164 format (for example, MSISDN).
  • END_USER_IMSI(1): The identifier is in international IMSI format.
  • END_USER_SIP_URI(2): The identifier is in the form of a SIP URI.
  • END_USER_NAI(3): The identifier is in the form of a Network Access Identifier.
  • END_USER_PRIVATE(4): The Identifier is a credit-control server private identifier.
NOTE:

The device supports only END_USER_NAI(3).

The Subscription-Id-Type AVP is a sub-AVP, which is used in the group AVP Subscription-ID.

References

RFC 4006 clause 8.47

Supported-Features AVP

Description of AVP

AVP

Description

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]
NOTE:

The device receives but does not process *[AVP] in the AVP format description, that is, the device processes the AVPs listed in this document and ignores other AVPs.

The flag of the Supported-Features AVP in a CCR-Initial message is mandatory ("M").

The Supported-Features AVP is a group AVP, which contains the Vendor-ID, Feature-List-ID, and Feature-List sub-AVPs.

Reference Standards

3GPP TS 29.212 V9.7.0 clause 5.4.1

3GPP TS 29.229 V8.7.0 clause 6.3.29

Termination-Cause

Description of AVP

AVP

Description

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.

NOTE:
device supports only the following value:

  • DIAMETER_LOGOUT (1)

    The user initiated a disconnect.

Reference Standards

RFC 3588 clause 8.15

Usage-Monitoring-Information AVP

Description of AVP

AVP

Description

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 ]
NOTE:

The Usage-Monitoring-Information AVP is a group AVP, which contains the gx-r9-usage-monitoring-key, granted-service-unit, and gx-r9-usage-monitoring-level sub-AVPs.

An device receives but does not process *[AVP] in the message format description. This means that the device processes the AVPs described in this document but ignores other AVPs.

Reference Standards

3GPP TS 29.212 V9.7.0 clause 5.3.60

Usage-Monitoring-Level AVP

Description of AVP

AVP

Description

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.

The following values are defined:

  • SESSION_LEVEL(0)

    This value, if provided within an RAR or CCA message by the PCRF, indicates that the quota monitoring instance applies to the entire IP-CAN session.

  • PCC_RULE_LEVEL (1)

    This value is the default value if the Usage-Monitoring-Level AVP is not carried in a message.

Reference Standards

3GPP TS 29.212 V9.7.0 clause 5.3.61

Usage-Monitoring-Report AVP

Description of AVP

AVP

Description

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.

The following values are defined in 3GPP TS 29.212:

  • USAGE_MONITORING_REPORT_REQUIRED(0)

    This value, if provided within an RAR or CCA command by the PCRF indicates that accumulated usage shall be reported by the PCEF.

NOTE:

On device, BOD service does not support this AVP.

The Usage-Monitoring AVP is a sub-AVP, which is used in the group AVP gx-r9-usage-monitoring-info.

Reference Standards

3GPP TS 29.212 V9.7.0 clause 5.3.62

User-Equipment-Info AVP

Description of AVP

AVP

Description

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 }
NOTE:

The User-Equipment-Info AVP is a group AVP, which contains the user-equipment-info-type and user-equipment-info-value sub-AVPs.

It is used by the device to report MAC addresses of users.

Reference Standards

RFC 4006 clause 8.49

User-Equipment-Info-Type AVP

Description of AVP

AVP

Description

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.

NOTE:

The User-Equipment-Info-Type AVP is a sub-AVP, which is used in the group AVP user-equipment-info.

The device uses the User-Equipment-Info-Type AVP to report MAC addresses of users. This AVP is permanently set to MAC (1).

Reference Standards

RFC 4006 clause 8.50

User-Equipment-Info-Value AVP

Description of AVP

AVP

Description

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.

Reference Standards

RFC 4006 clause 8.51

Used-Service-Unit AVP

Description of AVP

AVP

Description

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 ]
NOTE:

The Used-Service-Unit AVP is a sub-AVP, which is used in the group AVP gx-r9-usage-monitoring-info. The Used-Service-Unit AVP is also a group AVP, which contains the cc-time and cc-total-octets sub-AVPs.

The PCEF reports upstream traffic and downstream traffic separately, and the PCRF is required to sum the traffic. The device supports duration reporting.

An device receives but does not process *[AVP] in the message format description. This means that the device processes the AVPs described in this document but ignores other AVPs.

Reference Standards

RFC 4006 clause 8.19

Vendor-Id AVP

Description of AVP

AVP

Description

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.

NOTE:

The Vendor-Id AVP is a sub-AVP, which is used in the group AVP vendor-specific-application-id.

Reference Standards

RFC 4006 clause 5.3.3

Vendor-Specific-Application-Id AVP

Description of AVP

AVP

Description

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 }
NOTE:

The Vendor-Specific-Application-Id AVP is a group AVP, which contains the vendor-id and auth-application-id sub-AVPs.

References

RFC 3588 clause 6.11

X-HW-User-Physical-Info-Value AVP

Description of AVP

AVP

Description

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

Reference Standards

This AVP is a private AVP, so there are no reference standards.

X-HW-MS-Group-Name AVP

Description of AVP

AVP

Description

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

Reference Standards

This AVP is a private AVP, so there are no reference standards.

X-HW-ACL-Group-Name AVP

Description of AVP

AVP

Description

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

Reference Standards

This AVP is a private AVP, so there are no reference standards.

X-HW-Interim-Interval AVP

Description of AVP

AVP

Description

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

Reference Standards

This AVP is a private AVP, so there are no reference standards.

X-HW-Service-Type AVP

Description of AVP

AVP

Description

X-HW-Service-Type
The X-HW-Service-Type AVP (Code 2024) is of type Enumerated. The PCEF supports BOD, and DAA services. The X-HW-Service-Type AVP is defined as follows:

  • <enum name="SERVICE_TYPE_BOD" value="1"/>

  • <enum name="SERVICE_TYPE_DAA" value="2"/>

This AVP is defined as follows:

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

NOTE:

The name of a static policy must be unique on the PCEF, that is, the service can be identified according to the static policy name.

The X-HW-Service-Type AVP is a sub-AVP, which is used in the group AVP charging-rule-definition.

Reference Standards

This AVP is a private AVP, so there are no reference standards.

Synchronization Conventions for Message Processing

Session Establishment

  • Scenario 1

    A user who has subscribed to a service is configured on the PCRF. When the user goes online, the PCEF is requested to send a CCR-Initial message to the PCRF.

  • Processing

    When the PCRF detects the subscription information about the user and a session is established successfully, the PCRF returns a CCA-Initial message carrying the PCC rule for the user.

  • Scenario 2

    A user is not configured on the PCRF. When the user goes online, the PCEF is requested to send a CCR-Initial message to the PCRF.

  • Processing

    When the PCRF does not detect the subscription information about the user and a session fails to be established, the PCRF returns a CCA-Initial message carrying the Result-Code AVP whose value is DIAMETER_UNKNOWN_SESSION_ID.

Response to the RAR Message

  • Scenario 1

    A session is established successfully and a user who has subscribed to a service updates the service or a trigger enables the new service to be effective.

  • Processing

    The PCRF sends an RAR message to the PCEF. Upon receiving the RAR message, the PCEF immediately returns an RAA message to the PCRF, and then activates, deactivates, deploys, or removes the rule in the RAR message. If the operation fails, the PCEF sends a CCR-Update message to the PCRF.

  • Scenario 2

    A session is established successfully and a user who has subscribed to a service updates the service or a trigger enables the new service to be effective. Upon receiving an RAR message, the PCEF returns an RAA message and detects that the link status is down.

  • Processing

    The PCEF does not send an RAA message but remove the local session. In this case, the PCEF notifies the service module of the link status and the service module determines when to initiate a request for bringing a user online. If the PCRF does not receive the RAA message, the PCRF removes the local session.

Error Code of the Gx Interface

Table 1-1667 lists the common error codes.

Table 1-1667 Error codes of the interface

Code Value

Meaning

Possible Causes

4

GW_PCEF_MALFUNCTION

The device internal processing is incorrect, for example, the PCRF delivers a policy that is not defined on the server, the service type of BOD services is incorrect, or the dynamic policy to be deleted is not installed.

1004

QOS_CONTENT_ERROR

The configured QoS content is incorrect.

5002

DIAMETER_UNKNOWN_SESSION_ID

The request contains an unknown Session-Id.

5012

DIAMETER_UNABLE_TO_COMPLY

The request is rejected.

Compliance Information for Standards

Compliance Information of CCR Command

Message Format (AVP)

AVP Code

AVP Type

Standard

device Compliance

Max length supported in device(Unit: bytes)

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

-

-

3GPP TS 29.212 V9.7.0 clause 5.6.2

√

-

< Session-Id >

263

UTF8String

RFC 3588 clause 8.8

√

127+8+4

{ Auth-Application-Id }

258

Unsigned32

RFC 3588 clause 6.8

√

4

{ Origin-Host }

264

DiameterIdentity

RFC 3588 clause 6.3

√

127

{ Origin-Realm }

296

DiameterIdentity

RFC 3588 clause 6.4

√

127

{ Destination-Realm }

283

DiameterIdentity

RFC 3588 clause 6.6

√

127

{ CC-Request-Type }

416

Enumerated

RFC 4006 clause 8.3

√

4

{ CC-Request-Number }

415

Unsigned32

RFC 4006 clause 8.2

√

4

[ Destination-Host ]

293

DiameterIdentity

RFC 3588 clause 6.5

√

127

[ Origin-State-Id ]

278

Unsigned32

RFC 3588 clause 8.16

×

-

*[ Subscription-Id ]

443

Grouped

RFC 4006 clause 8.46

√

2048

{ Subscription-Id-Type }

450

Enumerated

RFC 4006 clause 8.47

√

4

{ Subscription-Id-Data }

444

UTF8String

RFC 4006 clause 8.48

√

253

*[ Supported-Features ]

628

Grouped

3GPP TS 29.229 V8.7.0 clause 6.3.29

√

2048

{ Vendor-Id }

266

Unsigned32

RFC 3588 clause 5.3.3

√

4

{ Feature-List-ID }

629

Unsigned32

3GPP TS 29.229 V8.7.0 clause 6.3.30

√

4

{ Feature-List }

630

Unsigned32

3GPP TS 29.229 V8.7.0 clause 6.3.31

√

4

*[ AVP]

-

-

-

-

-

[ Network-Request-Support ]

1024

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.24

×

-

*[ Packet-Filter-Information ]

1061

Grouped

3GPP TS 29.212 V9.7.0 clause 5.3.56

×

-

[ Packet-Filter-Identifier ]

1060

OctetString

3GPP TS 29.212 V9.7.0 clause 5.3.55

×

-

[ Packet-Filter-Content ]

1059

IPFilterRule

3GPP TS 29.212 V9.7.0 clause 5.3.54

×

-

[ ToS-Traffic-Class ]

1014

OctetString

3GPP TS 29.212 V9.7.0 clause 5.3.15

×

-

[ Security-Parameter-Index ]

1056

OctetString

3GPP TS 29.212 V9.7.0 clause 5.3.51

×

-

[ Flow-Label ]

1057

OctetString

3GPP TS 29.212 V9.7.0 clause 5.3.52

×

-

*[ AVP ]

-

-

-

-

-

[ Packet-Filter-Operation ]

1062

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.57

×

-

[ Bearer-Identifier ]

1020

OctetString

3GPP TS 29.212 V9.7.0 clause 5.3.20

×

-

[ Bearer-Operation ]

1021

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.21

×

-

[ Framed-IP-Address ]

8

OctetString

RFC 4005 clause 6.11.1

√

4

[ Framed-IPv6-Prefix ]

97

OctetString

RFC 4005 clause 6.11.6

√

18

[ IP-CAN-Type ]

1027

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.27

√

4

[ 3GPP-RAT-Type ]

21

OctetString

3GPP TS 29.061 V8.2.0 clause 16.4.7

×

-

[ RAT-Type ]

1032

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.31

×

-

[ Termination-Cause ]

295

Enumerated

RFC 3588 clause 8.15

√

4

[ User-Equipment-Info ]

458

Grouped

RFC 4006 clause 8.49

√

2048

{ User-Equipment-Info-Type }

459

Enumerated

RFC 4006 clause 8.47

√

4

{ User-Equipment-Info-Value }

460

OctetString

RFC 4006 clause 8.48

√

6

[ QoS-Information ]

1016

Grouped

3GPP TS 29.212 V9.7.0 clause 5.3.16

√

2048

[ QoS-Class-Identifier ]

1028

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.17

×

-

[ Max-Requested-Bandwidth-UL ]

516

Unsigned32

3GPP TS 29.214 V8.3.0 clause 5.3.15

√

4

[ Max-Requested-Bandwidth-DL ]

515

Unsigned32

3GPP TS 29.214 V8.3.0 clause 5.3.14

√

4

[ Guaranteed-Bitrate-UL ]

1026

Unsigned32

3GPP TS 29.212 V9.7.0 clause 5.3.26

√

4

[ Guaranteed-Bitrate-DL ]

1025

Unsigned32

3GPP TS 29.212 V9.7.0 clause 5.3.25

√

4

[ Bearer-Identifier ]

1020

OctetString

3GPP TS 29.212 V9.7.0 clause 5.3.20

×

-

[ Allocation-Retention-Priority]

1034

Grouped

3GPP TS 29.212 V9.7.0 clause 5.3.32

×

-

{Priority-Level}

1046

Unsigned32

3GPP TS 29.212 V9.7.0 clause 5.3.45

×

-

[Pre-emption-Capability]

1047

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.46

×

-

[Pre-emption-Vulnerability]

1048

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.47

×

-

[ APN-Aggregate-Max-Bitrate-UL]

1041

Unsigned32

3GPP TS 29.212 V9.7.0 clause 5.3.40

×

-

[ APN-Aggregate-Max-Bitrate-DL]

1040

Unsigned32

3GPP TS 29.212 V9.7.0 clause 5.3.39

×

-

*[ AVP ]

-

-

-

-

-

[ QoS-Negotiation ]

1029

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.28

×

-

[ QoS-Upgrade ]

1030

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.29

×

-

[ Default-EPS-Bearer-QoS ]

1049

Grouped

3GPP TS 29.212 V9.7.0 clause 5.3.48

×

-

[ QoS-Class-Identifier ]

1028

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.17

×

-

[ Allocation-Retention-Priority]

1034

Grouped

3GPP TS 29.212 V9.7.0 clause 5.3.32

×

-

{Priority-Level}

1046

Unsigned32

3GPP TS 29.212 V9.7.0 clause 5.3.45

×

-

[Pre-emption-Capability]

1047

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.46

×

-

[Pre-emption-Vulnerability]

1048

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.47

×

-

*[ AVP ]

-

-

-

-

-

0*2[ AN-GW-Address ]

1050

Address

3GPP TS 29.212 V9.7.0 clause 5.3.49

×

-

[ 3GPP-SGSN-MCC-MNC ]

18

UTF8String

3GPP TS 29.061 V8.1.0 clause 16.4.7

×

-

[ 3GPP-SGSN-Address ]

6

OctetString

3GPP TS 29.061 V8.1.0 clause 16.4.7

×

-

[ 3GPP-SGSN-IPv6-Address ]

15

OctetString

3GPP TS 29.061 V8.1.0

×

-

[ RAI ]

909

UTF8String

3GPP TS 29.061 V8.1.0 clause 17.7.12

×

-

[ 3GPP-User-Location-Info]

22

OctetString

3GPP TS 29.061 V8.1.0 clause 16.4.7

×

-

[ 3GPP-MS-TimeZone ]

23

OctetString

3GPP TS 29.061 V8.1.0 clause 16.4.7

×

-

[ Called-Station-ID ]

30

UTF8String

RFC 4005 clause 4.5

×

-

[ PDN-Connection-ID ]

1065

OctetString

3GPP TS 29.212 clause 5.3.58

×

-

[ Bearer-Usage ]

1000

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.1

×

-

*[ TFT-Packet-Filter-Information ]

1013

Grouped

3GPP TS 29.212 V9.7.0 clause 5.3.14

×

-

[ TFT-Filter ]

1012

IPFilterRule

3GPP TS 29.212 V9.7.0 clause 5.3.13

×

-

[ ToS-Traffic-Class ]

1014

OctetString

3GPP TS 29.212 V9.7.0 clause 5.3.15

×

-

[ Security-Parameter-Index ]

1056

OctetString

3GPP TS 29.212 V9.7.0 clause 5.3.51

×

-

[ Flow-Label ]

1057

OctetString

3GPP TS 29.212 V9.7.0 clause 5.3.52

×

-

*[ AVP ]

-

-

-

-

-

*[ Charging-Rule-Report ]

1018

Grouped

3GPP TS 29.212 V9.7.0 clause 5.3.18

√

2048

*[ Charging-Rule-Name ]

1005

OctetString

3GPP TS 29.212 V9.7.0 clause 5.3.6

√

67

[ PCC-Rule-Status ]

1019

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.19

√

4

[ Rule-Failure-Code ]

1031

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.38

√

4

[ Final-Unit-Indication ]

430

Grouped

RFC 4006 clause 8.34

×

-

{ Final-Unit-Action }

449

Enumerated

RFC 4006 clause 8.35

×

-

*[ Restriction-Filter-Rule ]

438

IPFilterRule

RFC 4006 clause 8.36

×

-

*[ Filter-Id ]

11

UTF8String

RFC 4005 clause 6.7

×

-

*[ AVP ]

-

-

-

-

-

*[ AVP ]

-

-

-

-

-

*[ Event-Trigger]

1006

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.7

√

4

[ Event-Report-Indication ]

1033

Grouped

3GPP TS 29.212 V11.6.0 clause 5.3.30

×

-

*[Event-Trigger]

1006

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.7

×

-

*[CSG-Information-Reporting]

1071

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.64

×

-

[RAT-Type]

1032

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.31

×

-

[QoS-Information]

1016

Grouped

3GPP TS 29.212 V9.7.0 clause 5.3.16

-

-

[ QoS-Class-Identifier ]

1028

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.17

×

-

[ Max-Requested-Bandwidth-UL ]

516

Unsigned32

3GPP TS 29.214 V8.3.0 clause 5.3.15

×

-

[ Max-Requested-Bandwidth-DL ]

515

Unsigned32

3GPP TS 29.214 V8.3.0 clause 5.3.14

×

-

[ Guaranteed-Bitrate-UL ]

1026

Unsigned32

3GPP TS 29.212 V9.7.0 clause 5.3.26

×

-

[ Guaranteed-Bitrate-DL ]

1025

Unsigned32

3GPP TS 29.212 V9.7.0 clause 5.3.25

×

-

[ Bearer-Identifier ]

1020

OctetString

3GPP TS 29.212 V9.7.0 clause 5.3.20

×

-

[ Allocation-Retention-Priority]

1034

Grouped

3GPP TS 29.212 V9.7.0 clause 5.3.32

×

-

{Priority-Level}

1046

Unsigned32

3GPP TS 29.212 V9.7.0 clause 5.3.45

×

-

[Pre-emption-Capability]

1047

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.46

×

-

[Pre-emption-Vulnerability]

1048

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.47

×

-

[ APN-Aggregate-Max-Bitrate-UL]

1041

Unsigned32

3GPP TS 29.212 V9.7.0 clause 5.3.40

×

-

[ APN-Aggregate-Max-Bitrate-DL]

1040

Unsigned32

3GPP TS 29.212 V9.7.0 clause 5.3.39

×

-

*[ AVP ]

-

-

-

-

-

[ RAI ]

909

UTF8String

3GPP TS 29.061 V8.1.0 clause 17.7.12

×

-

[3GPP-User-Location-Info]

22

OctetString

3GPP TS 29.061 V8.1.0 clause 16.4.7

×

-

[Trace-Data]

1458

Grouped

3GPP TS 29.272 clause 7.3.63

×

-

[Trace-Reference]

-

OctetString

3GPP TS 29.272 clause 7.3.64

×

-

[3GPP2-BSID]

9010

UTF8String

3GPP2 X.S0057-0

×

-

[3GPP-MS-TimeZone]

23

OctetString

3GPP TS 29.061 clause 16.4.7

×

-

[3GPP-SGSN-Address]

6

OctetString

3GPP TS 29.061 clause 16.4.7

×

-

[3GPP-SGSN-IPv6-Address]

15

OctetString

3GPP TS 29.061 clause 16.4.7

×

-

*[AVP]

-

-

-

-

-

[ Access-Network-Charging-Address ]

501

Address

3GPP TS 29.214 V8.3.0 clause 5.3.2

×

-

*[ Access-Network-Charging-Identifier-Gx ]

1022

Grouped

3GPP TS 29.212 V9.7.0 clause 5.3.22

×

-

{ Access-Network-Charging-Identifier-Value}

503

-

3GPP TS 29.214 V8.3.0 clause 5.3.4

×

-

*[ Charging-Rule-Name ]

1005

OctetString

3GPP TS 29.212 V9.7.0 clause 5.3.6

×

-

*[ CoA-Information ]

1039

Grouped

3GPP TS 29.212 clause 5.3.37

×

-

{ Tunnel-Information }

1038

Grouped

3GPP TS 29.212 clause 5.3.36

×

-

[ Tunnel-Header-Length ]

1037

Unsigned32

3GPP TS 29.212 clause 5.3.35

×

-

2[ Tunnel-Header-Filter ]

1036

IPFilterRule

3GPP TS 29.212 clause 5.3.34

×

-

*[ AVP ]

-

-

-

-

-

{ CoA-IP-Address }

1035

Address

3GPP TS 29.212 clause 5.3.33

×

-

*[AVP]

-

-

-

-

-

*[ Usage-Monitoring-Information ]

1067

Grouped

3GPP TS 29.212 V9.7.0 clause 5.3.60

√

2048

[ Monitoring-Key ]

1066

OctetString

3GPP TS 29.212 V9.7.0 clause 5.3.59

√

32

[ Used-Service-Unit ]

446

Grouped

RFC 4006 clause 8.19

√

2048

[ Tariff-Change-Usage ]

451

Time

RFC 4006 clause 8.2

×

-

[ CC-Time ]

420

Unsigned32

RFC 4006 clause 8.21

√

4

[ CC-Money ]

413

Grouped

RFC 4006 clause 8.22

×

-

{ Unit-Value }

445

Grouped

RFC 4006 clause 8.8

×

-

{ Value-Digits }

447

Integer64

RFC 4006 clause 8.1

×

-

[ Exponent ]

429

Integer32

RFC 4006 clause 8.9

×

-

[ Currency-Code ]

425

Unsigned32

RFC 4006 clause 8.11

×

-

[ CC-Total-Octets ]

421

Unsigned64

RFC 4006 clause 8.23

√

8

[ CC-Input-Octets ]

412

Unsigned64

RFC 4006 clause 8.24

×

-

[ CC-Output-Octets ]

414

Unsigned64

RFC 4006 clause 8.25

×

-

[ CC-Service-Specific-Units ]

417

Unsigned64

RFC 4006 clause 9.26

×

-

*[ AVP ]

-

-

-

-

-

[ Usage-Monitoring-Level ]

1068

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.61

√

4

[ Usage-Monitoring-Report ]

1069

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.62

√

4

[ Usage-Monitoring-Support ]

1070

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.63

√

4

*[ AVP ]

-

-

-

-

-

*[ Proxy-Info ]

284

Grouped

RFC 3588 clause 6.7.2

×

-

{ Proxy-Host }

280

DiameterIdentity

RFC 3588 clause 6.7.3

×

-

{ Proxy-State }

33

OctetString

RFC 3588 clause 6.7.4

×

-

*[ AVP ]

-

-

-

-

-

*[ Route-Record ]

282

DiameterIdentity

RFC 3588 clause 6.7.1

×

-

[ X-HW-User-Physical-Info-Value ]

2025

UTF8String

HUAWEI private AVP

√

200

*[ AVP ]

-

-

-

-

-

Compliance Information of CCA Command

Message Format (AVP)

AVP Code

AVP Type

Standard

device Compliance

Max length supported in device(Unit: Bytes)

<CC-Answer> ::= < Diameter Header: 272, PXY >

-

-

3GPP TS 29.212 V9.7.0 clause 5.6.3

√

-

< Session-Id >

263

UTF8String

RFC 3588 clause 8.8

√

127+8+4

{ Auth-Application-Id }

258

Unsigned32

RFC 3588 clause 6.8

√

4

{ Origin-Host }

264

DiameterIdentity

RFC 3588 clause 6.3

√

128

{ Origin-Realm }

296

DiameterIdentity

RFC 3588 clause 6.4

√

128

[ Result-Code ]

268

Unsigned32

RFC 3588 clause 7.1

√

4

[ Experimental-Result ]

297

Grouped

RFC 3588 clause 7.6

√

2048

{ Vendor-Id }

266

Unsigned32

RFC 3588 clause 5.3.3

√

4

{ Experimental-Result-Code }

298

Unsigned32

RFC 3588 clause 7.7

√

4

{ CC-Request-Type }

416

Enumerated

RFC 4006 clause 8.3

√

4

{ CC-Request-Number }

415

Unsigned32

RFC 4006 clause 8.2

√

4

*[ Supported-Features ]

628

Grouped

3GPP TS 29.229 V8.7.0 clause 6.3.29

×

-

{ Vendor-Id }

266

Unsigned32

RFC 3588 clause 5.3.3

×

-

{ Feature-List-ID }

629

Unsigned32

3GPP TS 29.229 V8.7.0 clause 6.3.30

×

-

{ Feature-List }

630

Unsigned32

3GPP TS 29.229 V8.7.0 clause 6.3.31

×

-

*[ AVP]

-

-

-

-

-

[ Bearer-Control-Mode ]

1023

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.23

×

-

*[ Event-Trigger ]

1006

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.7

√

4

[ Origin-State-Id ]

278

Unsigned32

RFC 3588 clause 8.16

×

-

*[ Redirect-Host ]

-

-

RFC 3588 clause 6.12

×

-

[ Redirect-Host-Usage ]

261

Enumerated

RFC 3588 clause 6.13

×

-

[ Redirect-Max-Cache-Time ]

262

Unsigned32

RFC 3588 clause 6.14

×

-

*[ Charging-Rule-Remove ]

1002

Grouped

3GPP TS 29.212 V9.7.0 clause 5.3.3

√

2048

*[ Charging-Rule-Name ]

1005

OctetString

3GPP TS 29.212 V9.7.0 clause 5.3.6

√

67

*[ AVP ]

-

-

-

-

-

*[ Charging-Rule-Install ]

1001

Grouped

3GPP TS 29.212 V9.7.0 clause 5.3.2

√

2048

*[ Charging-Rule-Definition ]

1003

Grouped

3GPP TS 29.212 V9.7.0 clause 5.3.4

√

2048

{ Charging-Rule-Name }

1005

OctetString

3GPP TS 29.212 V9.7.0 clause 5.3.6

√

12

[ Service-Identifier ]

439

Unsigned32

RFC 4006 clause 8.28

×

-

[ Rating-Group ]

432

Unsigned32

RFC 4006 clause 8.29

×

-

*[ Flow-Information ]

1058

Grouped

3GPP TS 29.212 V9.7.0 clause 5.3.53

×

-

[ Flow-Description ]

507

IPFilterRule

3GPP TS 29.214 V8.3.0 clause 5.3.8

×

-

[ Packet-Filter-Identifier ]

1060

OctetString

3GPP TS 29.212 V9.7.0 clause 5.3.55

×

-

[ Packet-Filter-Usage ]

1072

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.66

×

-

[ ToS-Traffic-Class ]

1014

OctetString

3GPP TS 29.212 V9.7.0 clause 5.3.15

×

-

[ Security-Parameter-Index ]

1056

OctetString

3GPP TS 29.212 V9.7.0 clause 5.3.51

×

-

[ Flow-Label ]

1057

OctetString

3GPP TS 29.212 V9.7.0 clause 5.3.52

×

-

[ Flow-Direction ]

1080

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.65

×

-

*[ AVP ]

-

-

-

-

-

[ Flow-Status ]

511

Enumerated

3GPP TS 29.214 V8.3.0 clause 5.3.11

×

-

[ QoS-Information ]

1016

Grouped

3GPP TS 29.212 V9.7.0 clause 5.3.16

√

2048

[ QoS-Class-Identifier ]

1028

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.17

×

-

[ Max-Requested-Bandwidth-UL ]

516

Unsigned32

3GPP TS 29.214 V8.3.0 clause 5.3.15

√

4

[ Max-Requested-Bandwidth-DL ]

515

Unsigned32

3GPP TS 29.214 V8.3.0 clause 5.3.14

√

4

[ Guaranteed-Bitrate-UL ]

1026

Unsigned32

3GPP TS 29.212 V9.7.0 clause 5.3.26

√

4

[ Guaranteed-Bitrate-DL ]

1025

Unsigned32

3GPP TS 29.212 V9.7.0 clause 5.3.25

√

4

[ Bearer-Identifier ]

1020

OctetString

3GPP TS 29.212 V9.7.0 clause 5.3.20

×

-

[ Allocation-Retention-Priority]

1034

Grouped

3GPP TS 29.212 V9.7.0 clause 5.3.32

×

-

{Priority-Level}

1046

Unsigned32

3GPP TS 29.212 V9.7.0 clause 5.3.45

×

-

[Pre-emption-Capability]

1047

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.46

×

-

[Pre-emption-Vulnerability]

1048

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.47

×

-

[ APN-Aggregate-Max-Bitrate-UL]

1041

Unsigned32

3GPP TS 29.212 V9.7.0 clause 5.3.40

×

-

[ APN-Aggregate-Max-Bitrate-DL]

1040

Unsigned32

3GPP TS 29.212 V9.7.0 clause 5.3.39

×

-

*[ AVP ]

-

-

-

-

-

[ Reporting-Level ]

1011

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.12

×

-

[ AF-Charging-Identifier ]

505

OctetString

3GPP TS 29.214 V8.3.0 clause 5.3.6

×

-

*[ Flows ]

510

Grouped

3GPP TS 29.214 V8.3.0 clause 5.3.10

×

-

{ Media-Component-Number }

518

Unsigned32

3GPP TS 29.214 V8.3.0 clause 5.3.17

×

-

*[ Flow-Number ]

509

Unsigned32

3GPP TS 29.214 V8.3.0 clause 5.3.9

×

-

[ Final-Unit-Action ]

449

Enumerated

RFC 4006 clause 8.35

×

-

[ Monitoring-Key ]

1066

OctetString

3GPP TS 29.212 V9.7.0 clause 5.3.59

√

32

[ AF-Signalling-Protocol ]

529

Enumerated

3GPP TS 29.214 V8.3.0 clause 5.3.26

×

-

[ X-HW-Service-Type ]

2024

Enumerated

HUAWEI private AVP

√

4

[ X-HW-ACL-Group-Name ]

2022

UTF8String

HUAWEI private AVP

√

31

[ X-HW-Interim-Interval ]

2023

Unsigned32

HUAWEI private AVP

√

4

*[ AVP ]

-

-

-

-

-

*[ Charging-Rule-Name ]

1005

OctetString

3GPP TS 29.212 V9.7.0 clause 5.3.6

√

67

*[ AVP ]

-

-

-

-

-

[ Primary-Event-Charging-Function-Name ]

619

DiameterURI

3GPP TS 29.229 V8.6.0 clause 6.3.20

×

-

[ Secondary-Event-Charging-Function-Name ]

620

DiameterURI

3GPP TS 29.229 V8.6.0 clause 6.3.22

×

-

[ Primary-Charging-Collection-Function-Name ]

621

DiameterURI

3GPP TS 29.229 V8.6.0 clause 6.3.22

×

-

[ Secondary-Charging-Collection-Function-Name ]

622

DiameterURI

3GPP TS 29.229 V8.6.0 clause 6.3.23

×

-

*[ AVP]

-

-

-

-

-

*[ QoS-Information ]

1016

Grouped

3GPP TS 29.212 Va.6.0 clause 5.3.16

√

2048

[ QoS-Class-Identifier ]

1028

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.17

×

-

[ Max-Requested-Bandwidth-UL ]

516

Unsigned32

3GPP TS 29.214 V8.3.0 clause 5.3.15

√

4

[ Max-Requested-Bandwidth-DL ]

515

Unsigned32

3GPP TS 29.214 V8.3.0 clause 5.3.14

√

4

[ Guaranteed-Bitrate-UL ]

1026

Unsigned32

3GPP TS 29.212 V9.7.0 clause 5.3.26

√

4

[ Guaranteed-Bitrate-DL ]

1025

Unsigned32

3GPP TS 29.212 V9.7.0 clause 5.3.25

√

4

[ Bearer-Identifier ]

1020

OctetString

3GPP TS 29.212 V9.7.0 clause 5.3.20

×

-

[ Allocation-Retention-Priority]

1034

Grouped

3GPP TS 29.212 V9.7.0 clause 5.3.32

×

-

{Priority-Level}

1046

Unsigned32

3GPP TS 29.212 V9.7.0 clause 5.3.45

×

-

[Pre-emption-Capability]

1047

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.46

×

-

[Pre-emption-Vulnerability]

1048

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.47

×

-

[ APN-Aggregate-Max-Bitrate-UL]

1041

Unsigned32

3GPP TS 29.212 V9.7.0 clause 5.3.40

×

-

[ APN-Aggregate-Max-Bitrate-DL]

1040

Unsigned32

3GPP TS 29.212 V9.7.0 clause 5.3.39

×

-

*[ AVP ]

-

-

-

-

-

[ Default-EPS-Bearer-QoS ]

1049

Grouped

3GPP TS 29.212 V9.7.0 clause 5.3.48

×

-

[ QoS-Class-Identifier ]

1028

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.17

×

-

[ Allocation-Retention-Priority ]

1034

Grouped

3GPP TS 29.212 V9.7.0 clause 5.3.32

×

-

{Priority-Level}

1046

Unsigned32

3GPP TS 29.212 V9.7.0 clause 5.3.45

×

-

[Pre-emption-Capability]

1047

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.46

×

-

[Pre-emption-Vulnerability]

1048

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.47

×

-

*[ AVP ]

-

-

-

-

-

[ Bearer-Usage ]

1000

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.1

×

-

[ 3GPP-User-Location-Info ]

22

OctetString

3GPP TS 29.061 V8.1.0 clause 16.4.7

×

-

*[ Usage-Monitoring-Information ]

1067

Grouped

3GPP TS 29.212 V9.7.0 clause 5.3.60

√

2048

[ Monitoring-Key ]

1066

OctetString

3GPP TS 29.212 V9.7.0 clause 5.3.59

√

32

[ Granted-Service-Unit ]

431

Grouped

RFC 4006 clause 8.17

√

2048

[ Tariff-Change-Usage ]

451

Time

RFC 4006 clause 8.2

×

-

[ CC-Time ]

420

Unsigned32

RFC 4006 clause 8.21

√

4

[ CC-Money ]

413

Grouped

RFC 4006 clause 8.22

×

-

{ Unit-Value }

445

Grouped

RFC 4006 clause 8.8

×

-

{ Value-Digits }

447

Integer64

RFC 4006 clause 8.1

×

-

[ Exponent ]

429

Integer32

RFC 4006 clause 8.9

×

-

[ Currency-Code ]

425

Unsigned32

RFC 4006 clause 8.11

×

-

[ CC-Total-Octets ]

421

Unsigned64

RFC 4006 clause 8.23

√

8

[ CC-Input-Octets ]

412

Unsigned64

RFC 4006 clause 8.24

×

-

[ CC-Output-Octets ]

414

Unsigned64

RFC 4006 clause 8.25

×

-

[ CC-Service-Specific-Units ]

417

Unsigned64

RFC 4006 clause 9.26

×

-

*[ AVP ]

-

-

-

-

-

[ Usage-Monitoring-Level ]

1068

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.61

√

4

[ Usage-Monitoring-Report ]

1069

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.62

√

4

[ Usage-Monitoring-Support ]

1070

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.63

√

4

*[ AVP ]

-

-

-

-

-

*[ CSG-Information-Reporting ]

1071

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.64

×

-

[ User-CSG-Information ]

2319

Grouped

3GPP TS 32.299 V12.6.0

×

-

[ Error-Message ]

281

UTF8String

RFC 3588 clause 7.3

×

-

*[ Failed-AVP ]

279

Grouped

RFC 3588 clause 7.5

×

-

1*{ AVP }

-

-

-

-

-

*[ Proxy-Info ]

284

Grouped

RFC 3588 clause 6.7.2

×

-

{ Proxy-Host }

280

DiameterIdentity

RFC 3588 clause 6.7.3

×

-

{ Proxy-State }

33

OctetString

RFC 3588 clause 6.7.4

×

-

*{ AVP }

-

-

-

-

-

*[ Route-Record ]

268

Unsigned32

RFC 3588 clause 6.7.1

×

-

*[ AVP ]

-

-

-

-

-

Compliance Information of RAR Command

Message Format(AVP)

AVP Code

AVP Type

Standard

device Compliance

Max length supported in device(Unit: Bytes)

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

-

-

3GPP TS 29.212 V9.7.0 clause 5.6.4

√

-

< Session-Id >

263

UTF8String

RFC 3588 clause 8.8

√

127+8+4

{ Auth-Application-Id }

258

Unsigned32

RFC 3588 clause 6.8

√

4

{ Origin-Host }

264

DiameterIdentity

RFC 3588 clause 6.3

√

127

{ Origin-Realm }

296

DiameterIdentity

RFC 3588 clause 6.4

√

127

{ Destination-Realm }

283

DiameterIdentity

RFC 3588 clause 6.6

√

127

{ Destination-Host }

293

DiameterIdentity

RFC 3588 clause 6.5

√

127

{ Re-Auth-Request-Type }

285

Enumerated

RFC 3588 clause 8.12

×

4

[ Session-Release-Cause ]

1045

Enumerated

3GPP TS 29.212 Vb.0.1 clause 5.3.44

×

-

[ Origin-State-Id ]

278

Unsigned32

RFC 3588 clause 8.16

×

-

*[ Event-Trigger ]

1006

Enumerated

3GPP TS 29.212 V11.6.0 clause 5.3.7

√

4

[ Event-Report-Indication ]

1033

Grouped

3GPP TS 29.212 V11.6.0 clause 5.3.30

×

-

*[Event-Trigger]

1006

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.7

×

-

*[CSG-Information-Reporting]

1071

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.64

×

-

[RAT-Type]

1032

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.31

×

-

[QoS-Information]

1016

Grouped

3GPP TS 29.212 V9.7.0 clause 5.3.16

×

-

[ QoS-Class-Identifier ]

1028

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.17

×

-

[ Max-Requested-Bandwidth-UL ]

516

Unsigned32

3GPP TS 29.214 V8.3.0 clause 5.3.15

×

-

[ Max-Requested-Bandwidth-DL ]

515

Unsigned32

3GPP TS 29.214 V8.3.0 clause 5.3.14

×

-

[ Guaranteed-Bitrate-UL ]

1026

Unsigned32

3GPP TS 29.212 V9.7.0 clause 5.3.26

×

-

[ Guaranteed-Bitrate-DL ]

1025

Unsigned32

3GPP TS 29.212 V9.7.0 clause 5.3.25

×

-

[ Bearer-Identifier ]

1020

OctetString

3GPP TS 29.212 V9.7.0 clause 5.3.20

×

-

[ Allocation-Retention-Priority]

1034

Grouped

3GPP TS 29.212 V9.7.0 clause 5.3.32

×

-

{Priority-Level}

1046

Unsigned32

3GPP TS 29.212 V9.7.0 clause 5.3.45

×

-

[Pre-emption-Capability]

1047

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.46

×

-

[Pre-emption-Vulnerability]

1048

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.47

×

-

[ APN-Aggregate-Max-Bitrate-UL]

1041

Unsigned32

3GPP TS 29.212 V9.7.0 clause 5.3.40

×

-

[ APN-Aggregate-Max-Bitrate-DL]

1040

Unsigned32

3GPP TS 29.212 V9.7.0 clause 5.3.39

×

-

*[ AVP ]

-

-

-

-

-

[RAI]

909

UTF8String

3GPP TS 29.061 V8.1.0 clause 17.7.12

×

-

[3GPP-User-Location-Info]

22

OctetString

3GPP TS 29.061 V8.1.0 clause 16.4.7

×

-

[Trace-Data]

1458

Grouped

3GPP TS 29.272

×

-

[Trace-Reference]

1459

OctetString

3GPP TS 29.272

×

-

[3GPP2-BSID]

9010

UTF8String

3GPP2 X.S0057-0

×

-

[3GPP-MS-TimeZone]

23

OctetString

3GPP TS 29.061 clause 16.4.7

×

-

[3GPP-SGSN-Address]

6

OctetString

3GPP TS 29.061 clause 16.4.7

×

-

[3GPP-SGSN-IPv6-Address]

15

OctetString

3GPP TS 29.061 clause 16.4.7

×

-

*[ AVP ]

-

-

-

-

-

*[ Charging-Rule-Remove ]

1002

Grouped

3GPP TS 29.212 Va.6.0 clause 5.3.3

√

2048

*[ Charging-Rule-Name ]

1005

OctetString

3GPP TS 29.212 V9.7.0 clause 5.3.6

√

67

*[ AVP ]

-

-

-

-

-

*[ Charging-Rule-Install ]

1001

Grouped

3GPP TS 29.212 Va.6.0 clause 5.3.2

√

-

*[ Charging-Rule-Definition ]

1003

Grouped

3GPP TS 29.212 V9.7.0 clause 5.3.4

√

2048

{ Charging-Rule-Name }

1005

OctetString

3GPP TS 29.212 V9.7.0 clause 5.3.6

√

12

[ Service-Identifier ]

439

Unsigned32

RFC 4006 clause 8.28

×

-

[ Rating-Group ]

432

Unsigned32

RFC 4006 clause 8.29

×

-

*[ Flow-Information ]

1058

Grouped

3GPP TS 29.212 V9.7.0 clause 5.3.53

×

-

[ Flow-Description ]

507

IPFilterRule

3GPP TS 29.214 V8.3.0 clause 5.3.8

×

-

[ Packet-Filter-Identifier ]

1060

OctetString

3GPP TS 29.212 V9.7.0 clause 5.3.55

×

-

[ Packet-Filter-Usage ]

1072

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.66

×

-

[ ToS-Traffic-Class ]

1014

OctetString

3GPP TS 29.212 V9.7.0 clause 5.3.15

×

-

[ Security-Parameter-Index ]

1056

OctetString

3GPP TS 29.212 V9.7.0 clause 5.3.51

×

-

[ Flow-Label ]

1057

OctetString

3GPP TS 29.212 V9.7.0 clause 5.3.52

×

-

[ Flow-Direction ]

1080

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.65

×

-

*[ AVP ]

-

-

-

-

-

[ Flow-Status ]

511

Enumerated

3GPP TS 29.214 V8.3.0 clause 5.3.11

×

-

[ QoS-Information ]

1016

Grouped

3GPP TS 29.212 V9.7.0 clause 5.3.16

√

2048

[ QoS-Class-Identifier ]

1028

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.17

×

-

[ Max-Requested-Bandwidth-UL ]

516

Unsigned32

3GPP TS 29.214 V8.3.0 clause 5.3.15

√

4

[ Max-Requested-Bandwidth-DL ]

515

Unsigned32

3GPP TS 29.214 V8.3.0 clause 5.3.14

√

4

[ Guaranteed-Bitrate-UL ]

1026

Unsigned32

3GPP TS 29.212 V9.7.0 clause 5.3.26

√

4

[ Guaranteed-Bitrate-DL ]

1025

Unsigned32

3GPP TS 29.212 V9.7.0 clause 5.3.25

√

4

[ Bearer-Identifier ]

1020

OctetString

3GPP TS 29.212 V9.7.0 clause 5.3.20

×

-

[ Allocation-Retention-Priority]

1034

Grouped

3GPP TS 29.212 V9.7.0 clause 5.3.32

×

-

{Priority-Level}

1046

Unsigned32

3GPP TS 29.212 V9.7.0 clause 5.3.45

×

-

[Pre-emption-Capability]

1047

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.46

×

-

[Pre-emption-Vulnerability]

1048

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.47

×

-

[ APN-Aggregate-Max-Bitrate-UL]

1041

Unsigned32

3GPP TS 29.212 V9.7.0 clause 5.3.40

×

-

[ APN-Aggregate-Max-Bitrate-DL]

1040

Unsigned32

3GPP TS 29.212 V9.7.0 clause 5.3.39

×

-

*[ AVP ]

-

-

-

-

-

[ Reporting-Level ]

1011

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.12

×

-

[ AF-Charging-Identifier ]

505

OctetString

3GPP TS 29.214 V8.3.0 clause 5.3.6

×

-

*[ Flows ]

510

Grouped

3GPP TS 29.214 V8.3.0 clause 5.3.10

×

-

{ Media-Component-Number }

518

Unsigned32

3GPP TS 29.214 V8.3.0 clause 5.3.17

×

-

*[ Flow-Number ]

509

Unsigned32

3GPP TS 29.214 V8.3.0 clause 5.3.9

×

-

[ Final-Unit-Action ]

449

Enumerated

RFC 4006 clause 8.35

×

-

[ Monitoring-Key ]

1066

OctetString

3GPP TS 29.212 V9.7.0 clause 5.3.59

√

32

[ AF-Signalling-Protocol ]

529

Enumerated

3GPP TS 29.214 V8.3.0 clause 5.3.26

×

-

*[ Flow-Description ]

507

IPFilterRule

3GPP TS 29.214 V8.3.0 clause 5.3.8

×

-

[ X-HW-Service-Type ]

2024

Enumerated

HUAWEI private AVP

√

4

[ X-HW-ACL-Group-Name ]

2022

UTF8String

HUAWEI private AVP

√

31

[ X-HW-Interim-Interval ]

2023

Unsigned32

HUAWEI private AVP

√

4

*[ AVP ]

-

-

-

-

-

*[ Charging-Rule-Name ]

1005

OctetString

3GPP TS 29.212 V9.7.0 clause 5.3.6

√

67

*[ AVP ]

-

-

-

-

-

[ Default-EPS-Bearer-QoS ]

1049

Grouped

3GPP TS 29.212 Va.6.0 clause 5.3.48

×

-

[ QoS-Class-Identifier ]

1028

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.17

×

-

[ Allocation-Retention-Priority ]

1034

Grouped

3GPP TS 29.212 V9.7.0 clause 5.3.32

×

-

{Priority-Level}

1046

Unsigned32

3GPP TS 29.212 V9.7.0 clause 5.3.45

×

-

[Pre-emption-Capability]

1047

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.46

×

-

[Pre-emption-Vulnerability]

1048

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.47

×

-

*[ AVP ]

-

-

-

-

-

*[ QoS-Information ]

1016

Grouped

3GPP TS 29.212 Va.6.0 clause 5.3.16

√

2048

[ QoS-Class-Identifier ]

1028

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.17

×

-

[ Max-Requested-Bandwidth-UL ]

516

Unsigned32

3GPP TS 29.214 V8.3.0 clause 5.3.15

√

4

[ Max-Requested-Bandwidth-DL ]

515

Unsigned32

3GPP TS 29.214 V8.3.0 clause 5.3.14

√

4

[ Guaranteed-Bitrate-UL ]

1026

Unsigned32

3GPP TS 29.212 V9.7.0 clause 5.3.26

√

4

[ Guaranteed-Bitrate-DL ]

1025

Unsigned32

3GPP TS 29.212 V9.7.0 clause 5.3.25

√

4

[ Bearer-Identifier ]

1020

OctetString

3GPP TS 29.212 V9.7.0 clause 5.3.20

×

-

[ Allocation-Retention-Priority]

1034

Grouped

3GPP TS 29.212 V9.7.0 clause 5.3.32

×

-

{Priority-Level}

1046

Unsigned32

3GPP TS 29.212 V9.7.0 clause 5.3.45

×

-

[Pre-emption-Capability]

1047

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.46

×

-

[Pre-emption-Vulnerability]

1048

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.47

×

-

[ APN-Aggregate-Max-Bitrate-UL]

1041

Unsigned32

3GPP TS 29.212 V9.7.0 clause 5.3.40

×

-

[ APN-Aggregate-Max-Bitrate-DL]

1040

Unsigned32

3GPP TS 29.212 V9.7.0 clause 5.3.39

×

-

*[ AVP ]

-

-

-

-

-

*[ Usage-Monitoring-Information ]

1067

Grouped

3GPP TS 29.212 Va.6.0 clause 5.3.60

√

2048

[ Monitoring-Key ]

1066

OctetString

3GPP TS 29.212 V9.7.0 clause 5.3.59

√

4

[ Granted-Service-Unit ]

431

Grouped

RFC 4006 clause 8.17

√

2048

[ Tariff-Change-Usage ]

451

Time

RFC 4006 clause 8.2

×

-

[ CC-Time ]

420

Unsigned32

RFC 4006 clause 8.21

√

4

[ CC-Money ]

413

Grouped

RFC 4006 clause 8.22

×

-

{ Unit-Value }

445

Grouped

RFC 4006 clause 8.8

×

-

{ Value-Digits }

447

Integer64

RFC 4006 clause 8.1

×

-

[ Exponent ]

429

Integer32

RFC 4006 clause 8.9

×

-

[ Currency-Code ]

425

Unsigned32

RFC 4006 clause 8.11

×

-

[ CC-Total-Octets ]

421

Unsigned64

RFC 4006 clause 8.23

√

8

[ CC-Input-Octets ]

412

Unsigned64

RFC 4006 clause 8.24

×

-

[ CC-Output-Octets ]

414

Unsigned64

RFC 4006 clause 8.25

×

-

[ CC-Service-Specific-Units ]

417

Unsigned64

RFC 4006 clause 9.26

×

-

*[ AVP ]

-

-

-

-

-

[ Usage-Monitoring-Level ]

1068

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.61

√

4

[ Usage-Monitoring-Report ]

1069

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.62

√

4

[ Usage-Monitoring-Support ]

1070

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.63

√

4

*[ AVP ]

-

-

-

-

-

*[ Proxy-Info ]

284

Grouped

RFC 3588 clause 6.7.2

×

-

{ Proxy-Host }

280

DiameterIdentity

RFC 3588 clause 6.7.3

×

-

{ Proxy-State }

33

OctetString

RFC 3588 clause 6.7.4

×

-

*{ AVP }

-

-

-

-

-

*[ Route-Record ]

268

Unsigned32

RFC 3588 clause 6.7.1

×

-

*[ AVP]

-

-

-

-

-

Compliance Information of RAA Command

Message Format(AVP)

AVP Code

AVP Type

Standard

device Compliance

Max length supported in device(Unit: Bytes)

<RA-Answer> ::= < Diameter Header: 258, PXY >

 - -

3GPP TS 29.212 V9.7.0 clause 5.6.5

 √ -

< Session-Id >

263

UTF8String

RFC 3588 clause 6.8

 √

127+8+4

{ Auth-Application-Id }

258

Unsigned32

RFC 3588 clause 6.8

 √

4

{ Origin-Host }

264

DiameterIdentity

RFC 3588 clause 6.8

 √

127

{ Origin-Realm }

296

DiameterIdentity

RFC 3588 clause 6.3

 √

127

[ Result-Code ]

268

Unsigned32

RFC 3588 clause 7.1

 √

4

[ Experimental-Result ]

297

Grouped

RFC 3588 clause 7.6

 √

2048

{ Vendor-Id }

266

Unsigned32

RFC 3588 clause 5.3.3

 √

4

{ Experimental-Result-Code }

298

Unsigned32

RFC 3588 clause 7.7

 √

4

[ Origin-State-Id ]

278

Unsigned32

RFC 3588 clause 8.16

 × -

[ IP-CAN-Type ]

1027

Enumerated

3GPP TS 29.212 Va.6.0 clause 5.3.27

 × -

[ RAT-Type ]

1032

Enumerated

3GPP TS 29.212 Va.6.0 clause 5.3.31

 × -

0*2[ AN-GW-Address ]

1050

Address

3GPP TS 29.212 Va.6.0 clause 5.3.49

 × -

[ 3GPP-SGSN-MCC-MNC ]

18

UTF8String

3GPP TS 29.061 V8.1.0 clause 16.4.7

 × -

[ 3GPP-SGSN-Address ]

6

OctetString

3GPP TS 29.061 V8.1.0 clause 16.4.7

 × -

[ 3GPP-SGSN-IPv6-Address ]

15

OctetString

3GPP TS 29.061 V8.1.0 clause 16.4.7

 × -

[ RAI ]

909

UTF8String

3GPP TS 29.061 V8.1.0 clause 17.7.12

 × -

[ 3GPP-User-Location-Info ]

22

OctetString

3GPP TS 29.061 V8.1.0 clause 16.4.7

 × -

[ 3GPP-MS-TimeZone ]

23

OctetString

3GPP TS 29.061 V8.1.0 clause 16.4.7

 × -

*[ Charging-Rule-Report]

1018

Grouped

3GPP TS 29.212 Va.6.0 clause 5.3.18

 √

2048

*[ Charging-Rule-Name ]

1005

OctetString

3GPP TS 29.212 V9.7.0 clause 5.3.6

 √

67

[ PCC-Rule-Status ]

1019

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.19

 √

4

[ Rule-Failure-Code ]

1031

Enumerated

3GPP TS 29.212 V9.7.0 clause 5.3.38

 √

4

[ Final-Unit-Indication ]

430

Grouped

RFC 4006 clause 8.34

 × -

{ Final-Unit-Action }

449

Enumerated

RFC 4006 clause 8.35

 × -

*[ Restriction-Filter-Rule ]

438

IPFilterRule

RFC 4006 clause 8.36

 × -

*[ Filter-Id ]

11

UTF8String

RFC 4005 clause 6.7

 × -

*[ AVP ]

 - - - - -

*[ AVP ]

 - - - - -

[ Access-Network-Charging-Address ]

501

Address

3GPP TS 29.214 V8.3.0 clause 5.3.2

 × -

*[ Access-Network-Charging-Identifier-Gx ]

1022

Grouped

3GPP TS 29.212 V9.7.0 clause 5.3.22

 × -

{ Access-Network-Charging-Identifier-Value}

503

OctetString

3GPP TS 29.214 V8.3.0 clause 5.3.4

 × -

*[ Charging-Rule-Name ]

1005

OctetString

3GPP TS 29.212 V9.7.0 clause 5.3.6

 × -

[ Error-Message ]

281

UTF8String

RFC 3588 clause 7.3

 × -

*[ Failed-AVP ]

279

Grouped

RFC 3588 clause 7.5

 × -

1*{ AVP }

 - - - - -

*[ Proxy-Info ]

284

Grouped

RFC 3588 clause 6.7.2

 × -

{ Proxy-Host }

280

DiameterIdentity

RFC 3588 clause 6.7.3

 × -

{ Proxy-State }

33

OctetString

RFC 3588 clause 6.7.4

 × -

*{ AVP }

 - - - - -

*[ AVP ]

 - - - - -

Standard Compliance of ASR Messages

Message Format (AVP)

AVP Code

AVP Type

Standard

device Compliance

Maximum Length Supported by the device (Bytes)

<ASR> ::= < Diameter Header: 274, REQ, PXY >

 - -

Section 8.5.1 in RFC 3588

 √ -

< Session-Id >

263

UTF8String

Section 8.8 in RFC 3588

 √

127+8+4

{ Origin-Host }

264

DiameterIdentity

Section 6.3 in RFC 3588

 √

127

{ Origin-Realm }

296

DiameterIdentity

Section 6.4 in RFC 3588

 √

127

{ Destination-Realm }

283

DiameterIdentity

Section 6.6 in RFC 3588

 √

127

{ Destination-Host }

293

DiameterIdentity

Section 6.5 in RFC 3588

 √

127

{ Auth-Application-Id }

258

Unsigned32

Section 6.8 in RFC 3588

 √

4

[ User-Name ]

1

UTF8String

Section 8.14 in RFC 3588

 x -

[ Origin-State-Id ]

278

Unsigned32

Section 8.16 in RFC 3588

 x -

*[ Proxy-Info ]

284

Grouped

Section 6.7.2 in RFC 3588

 x -

{ Proxy-Host }

280

DiameterIdentity

Section 6.7.3 in RFC 3588

 x -

{ Proxy-State }

33

OctetString

Section 6.7.4 in RFC 3588

 x -

*{ AVP }

 - - - - -

*[ Route-Record ]

268

Unsigned32

Section 6.7.1 in RFC 3588

 x -

*[ AVP]

 - - - - -

Standard Compliance of ASA Messages

Message Format (AVP)

AVP Code

AVP Type

Standard

device Compliance

Maximum Length Supported by the device (Bytes)

<ASA> ::= < Diameter Header: 274, PXY >

-

-

Section 8.5.2 in RFC 3588

√

-

< Session-Id >

263

UTF8String

Section 6.8 in RFC 3588

√

127+8+4

{ Result-Code }

268

Unsigned32

Section 7.1 in RFC 3588

√

4

{ Origin-Host }

264

DiameterIdentity

Section 6.8 in RFC 3588

√

127

{ Origin-Realm }

296

DiameterIdentity

Section 6.3 in RFC 3588

√

127

[ User-Name ]

1

UTF8String

Section 8.14 in RFC 3588

x

-

[ Origin-State-Id ]

278

Unsigned32

Section 8.16 in RFC 3588

x

-

[ Error-Message]

281

UTF8String

Section 7.3 in RFC 3588

x

-

[ Error-Reporting-Host ]

294

DiameterIdentity

Section 7.4 in RFC 3588

x

-

* [ Failed-AVP ]

279

Grouped

Section 7.5 in RFC 3588

x

-

*{ AVP }

-

-

-

-

-

*[ Redirect-Host ]

-

-

Section 6.12 in RFC 3588

x

-

[ Redirect-Host-Usage ]

261

Enumerated

Section 6.13 in RFC 3588

x

-

[ Redirect-Max-Cache-Time ]

262

Unsigned32

Section 6.14 in RFC 3588

x

-

*[ Proxy-Info ]

284

Grouped

Section 6.7.2 in RFC 3588

x

-

{ Proxy-Host }

280

DiameterIdentity

Section 6.7.3 in RFC 3588

x

-

{ Proxy-State }

33

OctetString

Section 6.7.4 in RFC 3588

x

-

*{ AVP }

-

-

-

-

-

*[ AVP]

-

-

-

-

-
Translation
Favorite
Download
Update Date：2024-04-01
Document ID：EDOC1100335691
Views：119158
Downloads：659
Average rating：5.0Points

Related Documents

Digital Signature File

digtal sigature tool