5.4 Gx re-used AVPs

29.2123GPPPolicy and Charging Control (PCC)Reference pointsRelease 17TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

5.4.0 General

Table 5.4.0.1 lists the Diameter AVPs re-used by the Gx reference point from existing Diameter Applications, reference to their respective specifications, short description of their usage within the Gx reference point, the applicability of the AVPs to charging control, policy control or both, and which supported features the AVP is applicable to. Other AVPs from existing Diameter Applications, except for the AVPs from Diameter base protocol, do not need to be supported. The AVPs from Diameter base protocol are not included in table 5.4.0.1, but they are re-used for the Gx reference point. Unless otherwise stated, re-used AVPs shall maintain their ‘M’, ‘P’ and ‘V’ flag settings. Where 3GPP Radius VSAs are re-used, unless otherwise stated, they shall be translated to Diameter AVPs as described in RFC 4005 [12] with the exception that the ‘M’ flag shall be set and the ‘P’ flag may be set.

Table 5.4.0.1: Gx re-used Diameter AVPs

Attribute Name	Reference	Description	Acc. Type	Applicability (notes 1, 4)
3GPP-Charging-Characteristics	3GPP TS 29.061 [11]	The Charging Characteristics applied to the IP-CAN session. This AVP shall have the ‘M’ bit cleared.	All	ABC
3GPP-GGSN-Address	3GPP TS 29.061 [11]	The Ipv4 address of the P-GW. This AVP shall have the ‘M’ bit cleared.	All (NOTE 8)	Both EPC-routed, ABC
3GPP-GGSN-Ipv6-Address	3GPP TS 29.061 [11]	The Ipv6 address of the P-GW. This AVP shall have the ‘M’ bit cleared.	All (NOTE 8)	Both EPC-routed, ABC
3GPP-MS-TimeZone	3GPP TS 29.061 [11]	Indicate the offset between universal time and local time in steps of 15 minutes of where the MS currently resides.	All	Both
3GPP-RAT-Type (NOTE 3)	3GPP TS 29.061 [11]	Indicate which Radio Access Technology is currently serving the UE.	3GPP-GPRS	Both
3GPP-Selection-Mode	3GPP TS 29.061 [11]	An index indicating how the APN was selected. This AVP shall have the ‘M’ bit cleared.	All	ABC
3GPP-SGSN-Address	3GPP TS 29.061 [11]	The Ipv4 address of the SGSN	3GPP-GPRS, 3GPP-EPS	Both
3GPP-SGSN-Ipv6-Address	3GPP TS 29.061 [11]	The Ipv6 address of the SGSN	3GPP-GPRS. 3GPP-EPS	Both
3GPP-SGSN-MCC-MNC (NOTE 6)	3GPP TS 29.061 [11]	For GPRS the MCC and the MNC of the SGSN. For 3GPP/non-3GPP accesses the MCC and the MNC provided by the serving gateway (SGW, or AGW or TWAG).	All	Both
3GPP-User-Location-Info	3GPP TS 29.061 [11]	Indicates details of where the UE is currently located (e.g. SAI, CGI or eNodeB ID)	3GPP-GPRS. 3GPP-EPS	Both
3GPP2-BSID	3GPP2 X.S0057 [24]	For 3GPP2 indicates the BSID of where the UE is currently located (e.g. Cell-Id, SID, NID). The Vendor-Id shall be set to 3GPP2 (5535) [24]. The support of this AVP shall be advertised in the capabilities exchange mechanisms (CER/CEA) by including the value 5535, identifying 3GPP2, in a Supported-Vendor-Id AVP. This AVP shall have the ‘M’ bit cleared.	3GPP2, Non-3GPP-EPS	Both Rel8
Access‑Network-Charging-Address	3GPP TS 29.214 [10]	Indicates the IP Address of the network entity within the access network performing charging (e.g. the GGSN IP address).	All	CC
Access‑Network-Charging-Identifier-Value	3GPP TS 29.214 [10]	Contains a charging identifier (e.g. GCID).	All	CC
AF-Charging-Identifier	3GPP TS 29.214 [10]	The AF charging identifier that may be used in charging correlation. For IMS the ICID. This AVP may only be included in a Charging-Rule-definition AVP if the SERVICE_IDENTIFIER_LEVEL reporting is being selected with the Reporting-Level AVP.	All	CC
AF-Signalling-Protocol	3GPP TS 29.214 [10]	Indicates the protocol used for signalling between the UE and the AF.	All	Both ProvAF-signalFlow
AN-Trusted	3GPP TS 29.273 [48]	Indicates whether the access network is trusted or untrusted for the Non-3GPP access network. This AVP shall have the ‘M’ bit cleared.	Non-3GPP-EPS	Both
Application-Service-Provider-Identity	3GPP TS 29.214 [10]	For sponsored connectivity, the identity of the application service provider that is delivering a service to a end user.	All	Both SponsoredConnectivity
BSSID	3GPP TS 32.299 [19]	Contains the BSSID of the access point where UE is located.	FBA	Both FBAC
Called-Station-Id	IETF RFC 4005 [12]	The address the user is connected to. For GPRS and EPS the APN. When used to contain the APN, the APN is composed of the APN Network Identifier only, or the APN Network Identifier and the APN Operator Identifier as specified in TS 23.003 [25], clause 9.1. The inclusion of the APN Operator Identifier can be configurable.	All	Both
Callee-Information	3GPP TS 29.214 [10]	Contains the callee information.	EPS	VBCLTE
Calling-Party-Address	3GPP TS 32.299 [19]	The address or addresses (Public User ID or Public Service ID) of the party requesting a service or initiating a session.	EPS	VBCLTE
CC-Request-Number	IETF RFC 8506 [66]	The number of the request for mapping requests and answers	All	Both
CC-Request-Type	IETF RFC 8506 [66]	The type of the request (initial, update, termination)	All	Both
Charging-Information	3GPP TS 29.229 [14]	The Charging-Information AVP is of type Grouped, and contains the addresses of the charging functions in the following AVPs: – Primary-Event-Charging-Function-Name is of type DiameterURI and defines the address of the primary online charging system. The protocol definition in the DiameterURI shall be either omitted or supplied with value "Diameter". – Secondary-Event-Charging-Function-Name is of type DiameterURI and defines the address of the secondary online charging system for the bearer. The protocol definition in the DiameterURI shall be either omitted or supplied with value "Diameter". – Primary-Charging-Collection-Function-Name is of type DiameterURI and defines the address of the primary offline charging system for the bearer. If the GTP’ protocol is applied on the Gz interface as specified in TS 32.295 [16], the protocol definition in the DiameterURI shall be omitted. If Diameter is applied on the Gz interface, the protocol definition in DiameterURI shall be either omitted or supplied with value "Diameter". The choice of the applied protocol on the Gz interface depends upon configuration in the PCEF. – Secondary-Charging-Collection-Function-Name is of type DiameterURI and defines the address of the secondary offline charging system for the bearer. If the GTP’ protocol is applied on the Gz interface as specified in TS 32.295 [16], the protocol definition in the DiameterURI shall be omitted. If Diameter is applied on the Gz interface, the protocol definition in DiameterURI shall be either omitted or supplied with value "Diameter". The choice of the applied protocol on the Gz interface depends upon configuration in the PCEF.	All	CC
Content-Version	3GPP TS 29.214 [10]	It indicates the content version of a PCC rule. It uniquely identifies a version of the PCC rule as defined in subclause 4.5.28	All	RuleVersioning
DRMP	IETF RFC 7944 [53]	Allows Diameter endpoints to indicate the relative priority of Diameter transactions.	All	Both
Dynamic-Address-Flag	3GPP TS 32.299 [19]	Indicates whether the PDP context/PDN address is statically or dynamically allocated. This AVP shall have the ‘M’ bit cleared.	All	ABC
Dynamic-Address-Flag-Extension	3GPP TS 32.299 [19]	Indicates that the Ipv4 PDN address has been dynamically allocated for that particular IP-CAN bearer (PDN connection) of PDN type Ipv4v6, while the dynamic Ipv6 address is indicated in Dynamic Address Flag. This AVP shall have the ‘M’ bit cleared.	All	ABC
Extended-Max-Requested-BW-DL	3GPP TS 29.214 [10]	Defines the maximum authorized bandwidth in kbit per second for downlink.	All	PC Extended-BW-NR
Extended-Max-Requested-BW-UL	3GPP TS 29.214 [10]	Defines the maximum authorized bandwidth in kbit per second for uplink.	All	PC Extended-BW-NR
Final-Unit-Indication	IETF RFC 8506 [66]	The action applied by the PCEF, and the related filter parameters and redirect address parameters (if available), when the user’s account cannot cover the service cost.	All	CC
Flow-Description	3GPP TS 29.214 [10], 5.4.2	Defines the service data flow filter parameters for a PCC rule or routing filter parameters for an IP flow mobility routing rule. The rules for usage on Gx are defined insub clause 5.4.2.	All	Both
Flows	3GPP TS 29.214 [10]	The flow identifiers of the IP flows related to a PCC rule as provided by the AF. May be only used in charging correlation together with AF-Charging-Identifier AVP.	All	CC
Flow-Status	3GPP TS 29.214 [10]	Defines whether the service data flow is enabled or disabled. The value "REMOVED" is not applicable to Gx.	All	Both
Framed-IP-Address	IETF RFC 4005 [12]	The Ipv4 address allocated for the user.	All	Both
Framed-Ipv6-Prefix	IETF RFC 4005 [12]	The Ipv6 prefix allocated for the user. The encoding of the value within this Octet String type AVP shall be as defined in IETF RFC 3162 [15], clause 2.3. The "Reserved", "Prefix-Length" and "Prefix" fields shall be included in this order. For FBA, it may indicate an Ipv6 address by setting the "Prefix Length" to 128 and encoding the Ipv6 address of the fixed device within the "Prefix" field as defined in annex G.5.2.	All	Both
Granted-Service-Unit (NOTE 5) (NOTE 7)	IETF RFC 8506 [66]	The volume and/or time threshold for usage monitoring control purposes. Only the CC-Total-Octets, one of the CC-Input-Octets and CC-Output-Octets or CC-Time AVPs are re-used. Monitoring-Time AVP as defined in 5.3. 99 may be optionally added to the grouped AVP if UMCH feature is supported. This AVP shall have the ‘M’ bit cleared.	All	Both Rel9 TimeBasedUM
Load	IETF RFC 8583 [60]	The AVP used to convey load information between Diameter nodes. This AVP and all AVPs within this grouped AVP shall have the ‘M’ bit cleared.	All
Logical-Access-ID	3GPP TS 283 034 [37]	Contains a Circuit‑ID (as defined in RFC 3046 [36]). The Logical Access ID may explicitly contain the identity of the Virtual Path and Virtual Channel carrying the traffic. The vendor-id shall be set to ETSI (13019) [37]. The support of this AVP shall be advertised in the capabilities exchange mechanisms (CER/CEA) by including the ETSI parameter in the Supported-Vendor-Id AVP. This AVP shall have the ‘M’ bit cleared.	xDSL	Both Rel10
Max-Requested-Bandwidth-UL (NOTE 2)	3GPP TS 29.214 [10]	Defines the maximum authorized bandwidth in bit per second for uplink.	All	PC
Max-Requested-Bandwidth-DL (NOTE 2)	3GPP TS 29.214 [10]	Defines the maximum authorized bandwidth in bit per second for downlink.	All	PC
Maximum-Wait-Time	3GPP TS 29.273 [48]	It indicates the number of milliseconds since the originating time stamp during which the originator of a request waits for a response.	All
OC-OLR	IETF RFC 7683 [49]	Contains the necessary information to convey an overload report	All	Both
OC-Supported-Features	IETF RFC 7683 [49]	Defines the support for the Diameter overload indication conveyence by the sending node	All	Both
Origination-Time-Stamp	3GPP TS 29.273 [48]	It indicates the UTC time when the originating entity (i.e. MME, SGSN, TWAN or ePDG) initiated the request.	All
PDN-Connection-Charging-ID	3GPP TS 32.299 [19]	Contains the charging identifier to identify different records belonging to same PDN connection. When NBIFOM is supported, this field includes the Charging Id assigned by the PGW for the PDN connection. Otherwise,this field includes Charging Id of first IP-CAN bearer activated within the PDN connection (the EPS default bearer in case of GTP based connectivity or the unique Charging Id in the PMIP based connectivity case). This AVP shall have the ‘M’ bit cleared.	All	ABC
Physical-Access-ID	ETSI TS 283 034 [37]	Identifies the physical access to which the user equipment is connected. Includes a port identifier and the identity of the access node where the port resides. The vendor-id shall be set to ETSI (13019) [37]. The support of this AVP shall be advertised in the capabilities exchange mechanisms (CER/CEA) by including the ETSI parameter in the Supported-Vendor-Id AVP. This AVP shall have the ‘M’ bit cleared.	xDSL	Both Rel10
Quota-Consumption-Time	3GPP TS 32.299 [19]	Defines the time interval in seconds after which the time measurement shall stop for the Monitoring Key, if no packets are received belonging to the corresponding Monitoring Key. This AVP shall have the ‘M’ bit cleared.	All	TimeBasedUM
RAI	3GPP TS 29.061 [11]	Contains the Routing Area Identity of the SGSN where the UE is registered	3GPP-GPRS. 3GPP-EPS	Both
Rating-Group	IETF RFC 8506 [66]	The charging key for the PCC rule used for rating purposes	All	CC
Redirect-Address-Type	IETF RFC 8506 [66]	Defines the address type of the address given in the Redirect-Server-Address AVP.	All	PC ADC
Redirect-Server-Address	IETF RFC 8506 [66]	Indicates the target for redirected application traffic.	All	PC ADC
Required-Access-Info	3GPP TS 29.214 [10]	Indicates the access network information for which the AF entity requests the PCRF reporting.	3GPP-GPRS. 3GPP-EPS	CC NetLoc
Service-Identifier	IETF RFC 8506 [66]	The identity of the service or service component the service data flow in a PCC rule relates to.	All	CC
Sharing-Key-DL	3GPP TS 29.214 [10]	Indicates, by containing the same value, what PCC rules may share resource in downlink direction.	All	ResShare
Sharing-Key-UL	3GPP TS 29.214 [10]	Indicates, by containing the same value, what PCC rules may share resource in uplink direction.	All	ResShare
Sponsor-Identity	3GPP TS 29.214 [10]	For sponsored data connectivity, it Identifies the sponsor willing to pay for the operator’s charge for connectivity.	All	CC SponsoredConnectivity
SSID	3GPP TS 29.273 [48]	Contains the SSID of the access point where UE is located	FBA	Both FBAC
Subscription-Id	IETF RFC 8506 [66]	The identification of the subscription (IMSI, MSISDN, etc)	All	Both
Supported-Features	3GPP TS 29.229 [14]	If present, this AVP informs the destination host about the features that the origin host requires to successfully complete this command exchange.	All	Both Rel8
Trace-Data (NOTE 5)	3GPP TS 29.272 [26]	Contains trace control and configuration parameters, specified in TS 32.422 [27]. This AVP shall have the ‘M’ bit cleared.	3GPP-EPS	Both Rel8
Trace-Reference	3GPP TS 29.272 [26]	Contains the trace reference parameter, specified in TS 32.422 [27]. This AVP shall have the ‘M’ bit cleared.	3GPP-EPS	Both Rel8
TWAN-Identifier	3GPP TS 29.061 [11]	Indicates the UE location in a Trusted WLAN Access Network. Indicates the UE location in an Untrusted WLAN Access Network.	Non-3GPP-EPS	Trusted-WLAN NetLoc-Trusted-WLAN NetLoc- Untrusted-WLAN
User-CSG-Information	3GPP TS 32.299 [19]	Indicates the user "Closed Subscriber Group" Information associated to CSG cell access: it comprises the CSG-Id, CSG-Access-Mode and CSG-Membership-Indication AVPs.	3GPP-EPS	CC Rel9
User-Equipment-Info	IETF RFC 8506 [66]	The identification and capabilities of the terminal (IMEISV, etc.) When the User-Equipment-Info-Type is set to IMEISV(0), the value within the User-Equipment-Info-Value shall be a UTF-8 encoded decimal.	All	Both
User-Equipment-Info-Extension	IETF RFC 8506 [66]	The identification and capabilities of the terminal (IMEISV, IMEI, etc.) When the User-Equipment-Info-IMEISV or the User-Equipment-Info-IMEI is used, it shall be a UTF-8 encoded decimal.	All	Both User-Equipment-Info-Extension
Used-Service-Unit (NOTE 5) (NOTE 7)	IETF RFC 8506 [66]	The measured volume and/or time for usage monitoring control purposes. The volume threshold for usage monitoring control purposes. Only the CC-Total-Octets, one of the CC-Input-Octets and CC-Output-Octets, or CC-Time AVPs are re-used. Monitoring-Time AVP as defined in clause 5.3.99 may be optionally added to the grouped AVP if UMCH feature is supported. This AVP shall have the ‘M’ bit cleared.	All	Both Rel9 TimeBasedUM
NOTE 1: AVPs marked with "CC" are applicable to charging control, AVPs marked with "PC" are applicable to policy control and AVPs marked with "Both" are applicable to both charging control and policy control. NOTE 2: When sending from the PCRF to the PCEF, the Max-Requested-Bandwidth-UL/DL AVP indicate the maximum allowed bit rate for the uplink/downlink direction; when sending from the PCEF to the PCRF, the Max-Requested-Bandwidth-UL/DL AVP indicate the maximum requested bit rate for the uplink/downlink direction. NOTE 3: This AVP is included for backward compatibility purposes when the PCEF only supports features that are not required for the successful operation of the session. NOTE 4: AVPs marked with a supported feature (e.g. "Rel8", "Rel9", "ProvAFsignalFlow" or "SponsoredConnectivity" or "ADC" ) are applicable as described in clause 5.4.1. NOTE 5: AVPs included within this grouped AVP shall have the ‘M’ bit cleared. NOTE 6: For Trusted WLAN access, TWAG provides the MCC and the MNC of the selected PLMN as described in subclause16.2.1 of TS 23.402 [23]. NOTE 7: Volume Usage monitoring control functionality is applicable for Rel9 supported feature. Time Based Usage monitoring control is applicable for TimeBasedUM supported feature. NOTE 8: For EPC routed feature, only Non-3GPP-EPS is applicable.

5.4.1 Use of the Supported-Features AVP on the Gx reference point

The Supported-Features AVP is used during session establishment to inform the destination host about the required and optional features that the origin host supports. The client shall, in the first request in a Diameter session indicate the set of supported features. The server shall, in the first answer within the Diameter session indicate the set of features that it has in common with the client and that the server shall support within the same Diameter session. Any further command messages shall always be compliant with the list of supported features indicated in the Supported-Features AVPs during session establishment. Features that are not advertised as supported shall not be used to construct the command messages for that Diameter session. Unless otherwise stated, the use of the Supported-Features AVP on the Gx reference point shall be compliant with the requirements for dynamic discovery of supported features and associated error handling on the Cx reference point as defined in clause 7.2.1 of 3GPP TS 29.229 [14].

The base functionality for the Gx reference point is the 3GPP Rel-7 standard and a feature is an extension to that functionality. If the origin host does not support any features beyond the base functionality, the Supported-Features AVP may be absent from the Gx commands. As defined in clause 7.1.1 of 3GPP TS 29.229 [14], when extending the application by adding new AVPs for a feature, the new AVPs shall have the M bit cleared and the AVP shall not be defined mandatory in the command ABNF.

As defined in 3GPP TS 29.229 [14], the Supported-Features AVP is of type grouped and contains the Vendor-Id, Feature-List-ID and Feature-List AVPs. On the Gx reference point, the Supported-Features AVP is used to identify features that have been defined by 3GPP and hence, for features defined in this document, the Vendor-Id AVP shall contain the vendor ID of 3GPP (10415). If there are multiple feature lists defined for the Gx reference point, the Feature-List-ID AVP shall differentiate those lists from one another.

On receiving an initial request application message, the destination host shall act as defined in clause 7.2.1 of 3GPP TS 29.229 [14]. The following exceptions apply to the initial CCR/CCA command pair:

– If the PCEF supporting post-Rel-7 Gx functionality is able to interoperate with a PCRF supporting Rel-7, the CCR shall include the features supported by the PCEF within Supported-Features AVP(s) with the ‘M’ bit cleared. Otherwise, the CCR shall include the supported features within the Supported-Features AVP(s) with the M-bit set.

NOTE 1: One instance of Supported-Features AVP is needed per Feature-List-ID.

– If the CCR command does not contain any Supported-Features AVP(s) and the PCRF supports Rel-7 Gx functionality, the CCA command shall not include the Supported-Features AVP. In this case, both PCEF and PCRF shall behave as specified in the Rel-7 version of this document.

– If the CCR command contains the Supported-Features AVP, the PCRF shall include the Supported-Features AVP in the CCA command, with the ‘M’ bit cleared, indicating only the features that both the PCRF and PCEF support. In this case, the PCRF should not use the ‘M’ bit setting of the Supported-Features AVP(s) to determine if the CCR is accepted or rejected.

NOTE 2: The client will always declare all features that are supported according to table 5.4.1.1 and 5.4.1.2. When more than one feature identifying a release is supported by both PCEF and PCRF, the PCEF will work according to the latest common supported release.

Once the PCRF and PCEF have negotiated the set of supported features during session establishment, the set of common features shall be used during the lifetime of the Diameter session.

The tables below define the features applicable to the Gx interfaces for the feature lists with a Feature-List-ID of 1 and 2.

Table 5.4.1.1: Features of Feature-List-ID 1 used in Gx

Feature bit	Feature	M/O	Description
0	Rel8	M	This feature indicates the support of base 3GPP Rel-8 Gx functionality, including the AVPs and corresponding procedures supported by the base 3GPP Rel-7 Gx standard, but excluding those features represented by separate feature bits. AVPs introduced with this feature are marked with "Rel8" in table 5.3.0.1.
1	Rel9	M	This feature indicates the support of base 3GPP Rel-9 Gx functionality, including the AVPs and corresponding procedures supported by the Rel8 feature bit, but excluding those features represented by separate feature bits. AVPs introduced with this feature are marked with "Rel9" in table 5.3.0.1.
2	ProvAFsignalFlow	O	This feature indicates support for the feature of IMS Restoration as described in subclause 4.5.18. If PCEF supports this feature the PCRF may provision AF signalling IP flow information.
3	Rel10	M	This feature indicates the support of base 3GPP Rel-10 Gx functionality, including the AVPs and corresponding procedures supported by the Rel8 and Rel9 feature bit, but excluding those features represented by separate feature bits. AVPs introduced with this feature are marked with "Rel10" in table 5.3.0.1.
4	SponsoredConnectivity	O	This feature indicates support for sponsored data connectivity feature. If the PCEF supports this feature, the PCRF may authorize sponsored data connectivity to the subscriber.
5	IFOM	O	This feature indicates support for IP flow mobility feature. If the PCEF supports this feature, the PCRF shall behave as described in subclause 4a.5.7.3.
6	ADC	O	This feature indicates support for the Application Detection and Control feature.
7	vSRVCC	O	This feature indicates support for the vSRVCC feature (see TS 23.216 [40]).
8	EPC-routed	O	This feature indicates support for interworking with Fixed Broad band Access networks when the traffic is routed via the EPC network as defined in Annex E.
9	rSRVCC	O	This feature indicates support for the CS to PS SRVCC feature (see TS 23.216 [40]).
10	NetLoc	O	This feature indicates the support of the Access Network Information Reporting for GPRS and EPS. If the PCEF supports this feature, the PCRF shall behave as described in subclause 4.5.22
11	UMCH	O	This feature indicates support for Usage Monitoring Congestion Handling. If the PCEF supports this feature, the behaviour shall be as specified in subclause 4.5.17.6.
12	ExtendedFilter	O	This feature indicates the support for the local (i.e. UE) address and mask being present in filters signalled between network and UE.
13	Trusted-WLAN	O	This feature indicates the support for the Trusted WLAN access as defined in 3GPP TS 23.402 [23].
14	SGW-Rest	O	This feature indicates the support of SGW Restoration procedures as defined in 3GPP TS 23.007 [43].
15	TimeBasedUM	O	This feature indicates support for Time based Usage Monitoring Control. If the PCEF supports this feature, the behaviour shall be as specified in corresponding clauses in this specification.
16	PendingTransaction	O	This feature indicates support for the race condition handling as defined in 3GPP TS 29.213 [8].
17	ABC	O	This feature indicates support for Application Based Charging.
18	void
19	NetLoc-Trusted-WLAN	O	This feature indicates the support of the Access Network Information Reporting for Trusted WLAN. If supported, the PCEF and the PCRF shall behave as described in annex D.3, this feature is applicable only if NetLoc feature and Trusted-WLAN feature are also supported.
20	FBAC	O	This feature indicates support for the Fixed Broadband Access Convergence as defined in Annex G.
21	ConditionalAPNPolicyInfo	O	This feature indicates support for APN related policy information with condition as defined in subclause 4.5.5.7. Not applicable to IPFlowMobility functionality feature (IFOM) as described in clause 5.4.1 or NBIFOM functionality feature as defined in subclause 4.5.25.
22	RAN-NAS-Cause	O	This feature indicates the support for the detailed release cause code information (NOTE 1) from the access network.
23	CNO-ULI	O	This feature indicates support for Presence Reporting Area Information reporting. If the PCEF supports this feature, the PCRF shall behave as described in Annex B.3.16. (NOTE 2)
24	PCSCF-Restoration-Enhancement	O	This feature indicates support of P-CSCF Restoration Enhancement. It is used for the PCEF to indicate if it supports P-CSCF Restoration Enhancement.
25	MissionCriticalQCIs	O	This feature indicates support for the Mission Critical QCI values 65, 69 and 70, and the Non Mission Critical QCI value 66 within the QoS-Class-Identifier AVP defined in subclause 5.3.17.
26	ResShare	O	This feature indicates the support of service data flows that share resources. If the PCEF supports this feature, the PCRF shall behave as described in subclause 4.5.5.11.
27	ExUsage	O	This feature indicates support for excluding the corresponding service data flow for the volume and/or time measurement on IP-CAN session level.
28	NBIFOM	O	This feature indicates support for network-based IP flow mobility as described in 3GPP TS 23.161 [51].
29	TSC	O	This feature indicates support for traffic steering control in the (S)Gi-LAN. If the PCEF supports this feature, the PCRF shall behave as described in subclause 4.5.2.8.
30	NetLoc-Untrusted-WLAN	O	This feature indicates the support of the Access Network Information Reporting for Untrusted WLAN access as defined in 3GPP TS 23.203 [7]. If supported, the PCEF shall behave as described in annex D.4.It requires that NetLoc feature is also supported.
31	CondPolicyInfo	O	This feature indicates support for time controlled APN-AMBR as defined in subclause 4.5.5.12. Not applicable to IPFlowMobility functionality feature (IFOM) as described in subclause 5.4.1 or NBIFOM functionality feature as defined in subclause 4.5.25 if this feature is used together with the feature ConditionalAPNPolicyInfo.
Feature bit: The order number of the bit within the Feature-List AVP where the least significant bit is assigned number "0". Feature: A short name that can be used to refer to the bit and to the feature, e.g. "EPS". M/O: Defines if the implementation of the feature is mandatory ("M") or optional ("O") in this 3GPP Release. Description: A clear textual description of the feature. NOTE 1: In this release, the release cause code information from the access network can include RAN/NAS release cause(s), a TWAN release cause or an untrusted WLAN release cause. NOTE 2: CNO-ULI feature will only be used when the PCEF and/or the PCRF does not support Multiple-PRA (see Table 5.4.1.2) and both PCEF and PCRF support CNO-ULI.

Table 5.4.1.2: Features of Feature-List-ID 2 used in Gx

Feature bit	Feature	M/O	Description
0	Enh-RAN-NAS-Cause	O	This feature indicates the support of the detailed release cause code information from the access network in the PCRF-initiated PCC Rule removal scenarios. It requires that RAN-NAS-Cause feature is also supported.
1	ENB-Change	O	This feature indicates support of eNodeB change reporting Enhancement. It is used for the PCEF to indicate if it supports eNodeB change reporting Enhancement.
2	RuleVersioning	O	This feature indicates the support of PCC rule versioning as defined in subclause 4.5.28
3	Multiple-PRA	O	This feature indicates support for Multiple Presence Reporting Area Information reporting. If the PCEF supports this feature, the PCRF shall behave as described in Annex B.3.17.
4	CondPolicyInfo-DefaultQoS	O	This feature indicates support for time controlled default EPS bearer QoS as defined in subclause 4.5.5.12. It requires that Rule-Bound-to-Default-Bearer feature is also supported.
5	Rule-Bound-to-Default-Bearer	O	This feature indicates support for policy provisioning and enforcement of authorized QoS for service data flows that shall be bound to the default bearer feature as defined in subclause 4.5.5.13.
6	3GPP-PS-Data-Off	O	This feature indicates the support of 3GPP PS Data off status change reporting. If this feature is supported, the PCEF and the PCRF shall behave as defined in subclause 4.5.29.
7	Extended-BW-NR	O	This feature indicates the support of extended bandwidth values for NR.
8	RAN-Support-Info	O	This feature indicates the support of maximum packet loss rate value(s) for uplink and/or downlink voice service data flow(s).
9	MCVideoQCI	O	This feature indicates support for the Mission Critical Video QCI value 67 within the QoS-Class-Identifier AVP defined in subclause 5.3.17.
10	UE-Status-Change	O	This feature indicates the support of report when the UE is suspended and then resumed from suspend state. If this feature is supported, the PCEF and the PCRF shall behave as defined in subclause 4.5.31.
11	ADC-Add-Redirection	O	This feature indicates support for additional redirection information in application detection and control. It requires the support of ADC feature.
12	VBCLTE	O	This feature indicates the support of providing the caller and callee information for Volume Based Charging as defined in subclause A.16 3GPP TS 29.214 [10].
13	MPSforDTS	O	Indicates support for MPS for DTS as described in subclauses 4.5.19.1.1 and 4.5.19.1.4
14	User-Equipment-Info-Extension	O	This feature indicates the support of the User-Equipment-Info-Extension AVP as defined in IETF RFC 8506 [66].
Feature bit: The order number of the bit within the Feature-List AVP where the least significant bit is assigned number "0". Feature: A short name that can be used to refer to the bit and to the feature, e.g. "EPS". M/O: Defines if the implementation of the feature is mandatory ("M") or optional ("O") in this 3GPP Release. Description: A clear textual description of the feature.

5.4.2 Flow-Description AVP

The Flow-Description AVP (AVP code is defined in 3GPP TS 29.214 [10]) is of type IPFilterRule, and defines a packet filter for an IP flow with the following information:

– Action shall be keyword permit"

– Direction shall be keyword "out".

– Protocol shall be the decimal protocol number or, to indicate that the value is not used for matching packets, the keyword "ip".

– Source IP address (possibly masked) or, to indicate that the value is not used for matching packets, the keyword "any".

– Source port is optional and, if present, shall be the decimal port number or port range.

– Destination IP address (possibly masked) or, to indicate that the value is not used for matching packets, the keyword "assigned".

– Destination port is optional and, if present, shall be the decimal port number or port range.

The IPFilterRule type shall be used with the following restrictions:

– The parameter encoding shall comply with IETF RFC 6733 [61].

– No "options" shall be used.

– The invert modifier "!" for addresses shall not be used.

The direction "out" indicates that the IPFilterRule "source" parameters correspond to the "remote" parameters in the packet filter and the IPFilterRule "destination" parameters correspond to the "local" (UE end) parameters. The Flow-Description AVP applies in the direction(s) as specified in the accompanying Flow-Direction AVP.