5 Rx protocol

29.2143GPPPolicy and charging control over Rx reference pointRelease 17TS

5.1 Protocol support

The Rx interface in the present release is based on Rx and Gq protocols defined for Release 6 as specified in 3GPP TS 29.211 [7] and 3GPP TS 29.209 [5] respectively. However, to be able to separate the policy and charging rules function (PCRF) of the present release from the policy decision function (PDF) and charging rules function (CRF) of Release 6, the Rx application in the present release has an own vendor specific Diameter application.

The Rx application is defined as an IETF vendor specific Diameter application, where the vendor is 3GPP and the Application-ID for the Rx application in the present release is 16777236. The vendor identifier assigned by IANA to 3GPP (http://www.iana.org/assignments/enterprise-numbers) is 10415.

NOTE: A route entry can have a different destination based on the application identification AVP of the message. Therefore, Diameter agents (relay, proxy, redirection, translation agents) must be configured appropriately to identify the 3GPP Rx application within the Auth-Application-Id AVP in order to create suitable routeing tables.

Tthe Rx application identification shall be included in the Auth-Application-Id AVP.

With regard to the Diameter protocol defined over the Rx reference point, the PCRF acts as a Diameter server, in the sense that it is the network element that handles AF session authorization requests for a particular realm. The AF acts as the Diameter client, in the sense that is the network element requesting the authorization of resources for an AF session.

5.2 Initialization, maintenance and termination of connection and session

The initialization and maintenance of the connection between each AF and PCRF pair is defined by the underlying protocol. Establishment and maintenance of connections between Diameter nodes is described in IETF RFC 6733 [52].

After establishing the transport connection, the PCRF and the AF shall advertise the support of the Rx specific Application by including the value of the application identifier in the Auth-Application-Id AVP and the value of the 3GPP (10415) in the Vendor-Id AVP of the Vendor-Specific-Application-Id AVP contained in the Capabilities‑Exchange-Request and Capabilities-Exchange-Answer commands. The Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands are specified in the Diameter Base Protocol (IETF RFC 6733 [52]).

The termination of the Diameter user session is specified in IETF RFC 6733 [52] in clauses 8.4 and 8.5. The description of how to use of these termination procedures in the normal cases is embedded in the procedures description (clause 4.4).

5.3 Rx specific AVPs

5.3.0 General

Table 5.3.0.1 describes the Diameter AVPs defined for the Rx interface protocol, their AVP Code values, types, possible flag values, whether or not the AVP may be encrypted and which supported feature the AVP is applicable to. The Vendor-Id header of all AVPs defined in the present document shall be set to 3GPP (10415).

NOTE: Most of these AVPs have already been defined in 3GPP TS 29.209 [5] for Rel-6. Their definition is based on the one used for Rel-6 with some possible modifications to be applied to the Rel-7 protocols.

Table 5.3.0.1: Rx specific Diameter AVPs

				AVP Flag rules (Note 1)
Attribute Name	AVP Code	Clause defined	Value Type (Note 2)	Must	May	Should not	Must not	May Encr.	Applicability (Note 3)
5GMM-Cause	573	5.3.70	Unsigned32	V	P		M	Y	RAN-NAS-Cause
5GS-RAN-NAS-Release-Cause	572	5.3.69	Grouped	V	P		M	Y	RAN-NAS-Cause
5GSM-Cause	574	5.3.71	Unsigned32	V	P		M	Y	RAN-NAS-Cause
Abort-Cause	500	5.3.1	Enumerated	M,V	P			Y
Access-Network-Charging-Address	501	5.3.2	Address	M,V	P			Y
Access-Network-Charging-Identifier	502	5.3.3	Grouped	M,V	P			Y
Access-Network-Charging-Identifier-Value	503	5.3.4	OctetString	M,V	P			Y
Acceptable-Service-Info	526	5.3.24	Grouped	M,V	P			Y
AF-Application-Identifier	504	5.3.5	OctetString	M,V	P			Y
AF-Charging-Identifier	505	5.3.6	OctetString	M,V	P			Y
AF-Requested-Data	551	5.3.50	Unsigned32	V	P		M	Y
AF-Signalling-Protocol	529	5.3.26	Enumerated	V	P		M	Y	ProvAFsignalFlow
Application-Service-Provider-Identity	532	5.3.29	UTF8String	V	P		M	Y	SponsoredConnectivity
Callee-Information	565	5.3.62	Grouped	V	P		M	Y	VBCLTE
Codec-Data	524	5.3.7	OctetString	M,V	P			Y
Content-Version	552	5.3.49	Unsigned64	V	P		M	Y	MediaComponentVersioning
Desired-Max-Latency	567	5.3.64	Float32	V	P		M	Y	FLUS QoSHint
Desired-Max-Loss	568	5.3.65	Float32	V	P		M	Y	FLUS QoSHint
Extended-Max-Requested-BW-DL	554	5.3.52	Unsigned32	V	P		M	Y	Extended-Max-Requested-BW-NR
Extended-Max-Requested-BW-UL	555	5.3.53	Unsigned32	V	P		M	Y	Extended-Max-Requested-BW-NR
Extended-Max-Supported-BW-DL	556	5.3.54	Unsigned32	V	P		M	Y	Extended-BW-E2EQOSMTSI-NR
Extended-Max-Supported-BW-UL	557	5.3.55	Unsigned32	V	P		M	Y	Extended-BW-E2EQOSMTSI-NR
Extended-Min-Desired-BW-DL	558	5.3.56	Unsigned32	V	P		M	Y	Extended-BW-E2EQOSMTSI-NR
Extended-Min-Desired-BW-UL	559	5.3.57	Unsigned32	V	P		M	Y	Extended-BW-E2EQOSMTSI-NR
Extended-Min-Requested-BW-DL	560	5.3.58	Unsigned32	V	P		M	Y	Extended-Min-Requested-BW-NR
Extended-Min-Requested-BW-UL	561	5.3.59	Unsigned32	V	P		M	Y	Extended-Min-Requested-BW-NR
Flow-Description	507	5.3.8	IPFilterRule	M,V	P			Y
Flow-Number	509	5.3.9	Unsigned32	M,V	P			Y
Flows	510	5.3.10	Grouped	M,V	P			Y
Flow-Status	511	5.3.11	Enumerated	M,V	P			Y
Flow-Usage	512	5.3.12	Enumerated	M,V	P			Y
FLUS-Identifier	566	5.3.63	OctetString	V	P		M	Y	FLUS
GCS-Identifier	538	5.3.36	OctetString	V	P		M	Y	GroupComService
GLI-Identifier	580	5.3.77	OctetString	V	P		M	Y	NetLoc-Wireline
HFC-Node-Identifier	579	5.3.76	OctetString	V	P		M	Y	NetLoc-Wireline
IMS-Content-Identifier	563	5.3.60	OctetString	V	P			Y	VBC
IMS-Content-Type	564	5.3.61	Enumerated	V	P			Y	VBC
IP-Domain-Id	537	5.3.35	OctetString	V	P		M	Y
Line-Type	581	5.3.78	Unsigned32	V	P		M	Y	NetLoc-Wireline
MA-Information	570	5.3.66	Grouped	V	P		M	Y	ATSSS
MA-Information-Action	571	5.3.67	Unsigned32	V	P		M	Y	ATSSS
Max-Requested-Bandwidth-DL	515	5.3.14	Unsigned32	M,V	P			Y
Max-Requested-Bandwidth-UL	516	5.3.15	Unsigned32	M,V	P			Y
Max-Supported-Bandwidth-DL	543	5.3.41	Unsigned32	V	P		M	Y	E2EQOSMTSI
Max-Supported-Bandwidth-UL	544	5.3.42	Unsigned32	V	P		M	Y	E2EQOSMTSI
MCPTT-Identifier	547	5.3.45	OctetString	V	P		M	Y	MCPTT
MCVideo-Identifier	562	5.3.45A	OctetString	V	P		M	Y	MCVideo
Media-Component-Description	517	5.3.16	Grouped	M,V	P			Y
Media-Component-Number	518	5.3.17	Unsigned32	M,V	P			Y
Media-Component-Status	549	5.3.48	Unsigned32	V	P		M	Y
Media-Sub-Component	519	5.3.18	Grouped	M,V	P			Y
Media-Type	520	5.3.19	Enumerated	M,V	P			Y
MPS-Identifier	528	5.3.30	OctetString	V	P		M	Y	Rel10
Min-Desired-Bandwidth-DL	545	5.3.43	Unsigned32	V	P		M		E2EQOSMTSI
Min-Desired-Bandwidth-UL	546	5.3.44	Unsigned32	V	P		M		E2EQOSMTSI
Min-Requested-Bandwidth-DL	534	5.3.32	Unsigned32	V	P		M	Y	Rel10
Min-Requested-Bandwidth-UL	535	5.3.33	Unsigned32	V	P		M	Y	Rel10
MPS-Action	582	5.3.79	Enumerated	V	P		M	Y	MPSforDTS
NGAP-Cause	575	5.3.72	Grouped	V	P		M	Y	RAN-NAS-Cause
NGAP-Group	576	5.3.73	Unsigned32	V	P		M	Y	RAN-NAS-Cause
NGAP-Value	577	5.3.74	Unsigned32	V	P		M	Y	RAN-NAS-Cause
NID	569	5.3.68	OctetString	V	P		M	Y
Priority-Sharing-Indicator	550	5.3.47	Enumerated	V	P		M	Y	PrioritySharing
Pre-emption-Control-Info	553	5.3.51	Unsigned32	V	P		M	Y	MCPTT-Preemption
Required-Access-Info	536	5.3.34	Enumerated	V	P		M	Y	NetLoc
Retry-Interval	541	5.3.39	Unsigned32	V	P		M	Y	DeferredService
Rx-Request-Type	533	5.3.31	Enumerated	V	P		M	Y
RR-Bandwidth	521	5.3.20	Unsigned32	M,V	P			Y
RS-Bandwidth	522	5.3.21	Unsigned32	M,V	P			Y
Service-Authorization-Info	548	5.3.46	Unsigned32	V	P		M	Y
Service-URN	525	5.3.23	OctetString	M,V	P			Y
Service-Info-Status	527	5.3.25	Enumerated	M,V	P			Y
Sharing-Key-DL	539	5.3.37	Unsigned32	V	P		M	Y	ResShare
Sharing-Key-UL	540	5.3.38	Unsigned32	V	P		M	Y	ResShare
Specific-Action	513	5.3.13	Enumerated	M,V	P			Y
SIP-Forking-Indication	523	5.3.22	Enumerated	M,V	P			Y
Sponsor-Identity	531	5.3.28	UTF8String	V	P		M	Y	SponsoredConnectivity
Sponsored-Connectivity-Data (NOTE 4)	530	5.3.27	Grouped	V	P		M	Y	SponsoredConnectivity SCTimeBasedUM
Sponsoring-Action	542	5.3.40	Enumerated	V	P		M	Y	SponsorChange
Wireline-User-Location-Info	578	5.3.75	Grouped	V	P		M	Y	NetLoc-Wireline
NOTE 1: The AVP header bit denoted as ‘M’, indicates whether support of the AVP is required. The AVP header bit denoted as ‘V’, indicates whether the optional Vendor-ID field is present in the AVP header. For further details, see IETF RFC 6733 [52]. NOTE 2: The value types are defined in IETF RFC 6733 [52]. NOTE 3: AVPs marked with a supported feature (e.g. "ProvAFsignalFlow", "SponsoredConnectivity", "Rel10" or "NetLoc") are applicable as described in clause 5.4.1 NOTE 4: Volume Usage monitoring control functionality is applicable for SponsoredConnectivity supported feature. Time Based Usage monitoring control is applicable for SCTimeBasedUM supported feature.

5.3.1 Abort-Cause AVP

The Abort-Cause AVP (AVP code 500) is of type Enumerated, and determines the cause of an abort session request (ASR) or of a RAR indicating a bearer release. The following values are defined:

BEARER_RELEASED (0)

This value is used when the bearer has been deactivated as a result from normal signalling handling. For GPRS the bearer refers to the PDP Context. It is also used when all the resource allocation corresponding to an AF session fails.

INSUFFICIENT_SERVER_RESOURCES (1)

This value is used to indicate that the server is overloaded and needs to abort the session.

INSUFFICIENT_BEARER_RESOURCES (2)

This value is used when the bearer has been deactivated due to insufficient bearer resources at a transport gateway (e.g. GGSN for GPRS).

PS_TO_CS_HANDOVER (3)

This value is used when the PCRF needs to initiate the AF session termination due to PS to CS handover.

SPONSORED_DATA_CONNECTIVITY_ DISALLOWED (4)

This value is used in the ASR when the PCRF needs to initiates the AF session termination due to the operator policy (e.g. disallowing the UE accessing the sponsored data connectivity in the roaming case).

5.3.2 Access-Network-Charging-Address AVP

The Access-Network-Charging-Address AVP (AVP code 501) is of type Address, and it indicates the IP Address of the network entity within the access network performing charging (e.g. the GGSN IP address). The Access‑Network‑Charging-Address AVP should not be forwarded over an inter-operator interface.

5.3.3 Access-Network-Charging-Identifier AVP

The Access-Network-Charging-Identifier AVP (AVP code 502) is of type Grouped, and contains a charging identifier (e.g. GCID) within the Access-Network-Charging-Identifier-Value AVP along with information about the flows transported within the corresponding bearer within the Flows AVP. If no Flows AVP is provided, the Access‑Network‑Charging-Identifier-Value applies for all flows within the AF session.

The Access-Network-Charging-Identifier AVP can be sent from the PCRF to the AF. The AF may use this information for charging correlation with session layer.

AVP Format:

Access-Network-Charging-Identifier ::= < AVP Header: 502 >

{ Access-Network-Charging-Identifier-Value}

*[ Flows ]

5.3.4 Access-Network-Charging-Identifier-Value AVP

The Access-Network-Charging-Identifier-Value AVP (AVP code 503) is of type OctetString, and contains a charging identifier (e.g. GCID).

5.3.5 AF-Application-Identifier AVP

The AF-Application-identifier AVP (AVP code 504) is of type OctetString, and it contains information that identifies the particular service that the AF service session belongs to. This information may be used by the PCRF to differentiate QoS for different application services.

For example the AF-Application-Identifier may be used as additional information together with the Media-Type AVP when the QoS class for the bearer authorization at the Gx interface is selected. The AF-Application-Identifier may be used also to complete the QoS authorization with application specific default settings in the PCRF if the AF does not provide full service information.

The AF-Application-Identifier AVP may also be used to trigger the PCRF to indicate to the PCEF/TDF to perform the application detection based on the operator’s policy.

5.3.6 AF-Charging-Identifier AVP

The AF-Charging-Identifier AVP (AVP code 505) is of type OctetString, contains the AF Charging Identifier that is sent by the AF. This information may be used for charging correlation with bearer layer.

5.3.7 Codec-Data AVP

The Codec-Data AVP (AVP code 524) is of type OctetString.

The Codec-Data AVP shall contain codec related information known at the AF. This information shall be encoded as follows:

– The first line of the value of the Codec-Data AVP shall consist of either the word "uplink" or the word "downlink" (in ASCII, without quotes) followed by a new-line character. The semantics of these words are the following:

– "uplink" indicates that the SDP was received from the UE and sent to the network.

– "downlink" indicates that the SDP was received from the network and sent to the UE.

NOTE 1: The first line indicates the direction of the source of the SDP used to derive the information. The majority of the information within the Codec-Data AVP indicating "downlink" describes properties, for instance receiver capabilities, of the sender of the SDP, the network in this case and is therefore applicable for IP flows in the uplink direction. Similarly, the majority of the information within the Codec-Data AVP indicating "uplink" describes properties, for instance receiver capabilities, of the sender of the SDP, the UE in this case and is therefore applicable for IP flows in the downlink direction.

– The second line of the value of the Codec-Data AVP shall consist of either the word "offer" or the word "answer", or the word "description" (in ASCII, without quotes) followed by a new-line character. The semantics of these words are the following:

– "offer" indicates that SDP lines from an SDP offer according to RFC 3264 [18] are being provisioned in the Codec-Data AVP;

– "answer" indicates that SDP lines from an SDP answer according to RFC 3264 [18] are being provisioned in the Codec-Data AVP;

– "description" indicates that SDP lines from a SDP session description in a scenario where the offer-answer mechanism of RFC 3264 [18] is not being applied are being provisioned in the Codec-Data AVP. For instance, SDP from an RTSP "Describe" reply may be provisioned.

– The rest of the value shall consist of SDP line(s) in ASCII encoding separated by new-line characters, as specified in IETF RFC 4566 [13]. The first of these line(s) shall be an "m" line. The remaining lines shall be any available SDP "a" and "b" lines related to that "m" line. However, to avoid duplication of information, the SDP "a=sendrecv", "a=recvonly ", "a=sendonly", "a=inactive", "a=bw-info", "b:AS", "b:RS" and "b:RR" lines do not need to be included.

NOTE 2: For backwards compatibility, it is expected that the codec algorithms in the PCRF described in 3GPP TS 29.213 [9] allow the introduction of new SDP lines without rejecting the request when Codec-Data AVP is provided as part of the Media-Component-Description AVP. The QoS derivation in that case will not take the new SDP line(s) into account.

5.3.8 Flow-Description AVP

The Flow-Description AVP (AVP code 507) is of type IPFilterRule, and defines a packet filter for an IP flow with the following information:

– Direction (in or out). The direction "in" refers to uplink IP flows, and the direction "out" refers to downlink IP flows.

– Source and destination IP address (possibly masked).

– Protocol.

– Source and destination port.

NOTE 1: When "ip" as key word is used in the protocol, the port(s) are used to describe the port(s) of any protocol if available.

The IPFilterRule type shall be used over Rx interface with the following restrictions:

– The Source Port may be omitted to indicate that any source port is allowed. Lists or ranges shall not be used.

– Only the Action "permit" shall be used.

– No "options" shall be used.

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

– The keyword "assigned" shall not be used.

NOTE 2: For TCP protocol, destination port can also be omitted.

If any of these restrictions is not observed by the AF, the server shall send an error response to the AF containing the Experimental-Result-Code AVP with value FILTER_RESTRICTIONS.

For the Rx interface, the Flow description AVP shall be used to describe a single IP flow.

5.3.9 Flow-Number AVP

The Flow-Number AVP (AVP code 509) is of type Unsigned32, and it contains the ordinal number of the IP flow(s), assigned according to the rules in Annex B.

5.3.10 Flows AVP

The Flows AVP (AVP code 510) is of type Grouped, and it indicates IP flows via their flow identifiers.

When reporting an out of credit condition, the Final-Unit-Action AVP indicates the termination action applied to the impacted flows.

If no Flow-Number AVP(s) are supplied, the Flows AVP refers to all Flows matching the media component number.

When reporting a resource allocation failure related to the modification of session information, the Media-Component-Status AVP may be included to report the status of the PCC/QoS rules related to the media component.

The Content-Version AVP(s) shall be included if it was included in the Media-Component-Description AVP when the corresponding media component was provisioned.

AVP Format:

Flows::= < AVP Header: 510 >

{Media-Component-Number}

*[Flow-Number]

*[ Content-Version ]

[Final-Unit-Action]

[Media-Component-Status]

*[AVP]

5.3.11 Flow-Status AVP

The Flow-Status AVP (AVP code 511) is of type Enumerated, and describes whether the IP flow(s) are enabled or disabled. The following values are defined:

ENABLED-UPLINK (0)

This value shall be used to enable associated uplink IP flow(s) and to disable associated downlink IP flow(s).

ENABLED-DOWNLINK (1)

This value shall be used to enable associated downlink IP flow(s) and to disable associated uplink IP flow(s).

ENABLED (2)

This value shall be used to enable all associated IP flow(s) in both directions.

DISABLED (3)

This value shall be used to disable all associated IP flow(s) in both directions.

REMOVED (4)

This value shall be used to remove all associated IP flow(s). The IP Filters for the associated IP flow(s) shall be removed. The associated IP flows shall not be taken into account when deriving the authorized QoS.

NOTE 1: The interpretation of values for the RTCP flows in the Rx interface is described within the procedures in clause 4.4.3.

NOTE 2: The interpretation of values for IMS flows when SIP Forking is supported is described within the procedures in Annex A.3.1.

5.3.12 Flow-Usage AVP

The Flow-Usage AVP (AVP code 512) is of type Enumerated, and provides information about the usage of IP Flows. The following values are defined:

NO_INFORMATION (0)

This value is used to indicate that no information about the usage of the IP flow is being provided.

RTCP (1)

This value is used to indicate that an IP flow is used to transport RTCP.

AF_SIGNALLING (2)

This value is used to indicate that the IP flow is used to transport AF Signalling Protocols (e.g. SIP/SDP).

NO_INFORMATION is the default value.

NOTE: An AF may choose not to identify RTCP flows, e.g. in order to avoid that RTCP flows are always enabled by the server.

5.3.13 Specific-Action AVP

The Specific-Action AVP (AVP code 513) is of type Enumerated.

Within a PCRF initiated Re-Authorization Request, the Specific-Action AVP determines the type of the action.

Within an initial AA request the AF may use the Specific-Action AVP to request any specific actions from the server at the bearer events and to limit the contact to such bearer events where specific action is required. If the Specific-Action AVP is omitted within the initial AA request, no notification of any of the events defined below is requested at this time.

For one time specific actions, as identified in the value descriptions below, the AF may also provide the Specific-Action AVP with the applicable one-time-specific-action value(s) in subsequent AA-Requests. Non-one-time-specific-action value(s) may only be provided in the initial AA-Request and shall then be applicable for the entire lifetime of the Rx session.

NOTE 1: One time specific actions are reported once the required action is fulfilled and are not reported again unless the AF sends a new request.

NOTE 2: Unless otherwise stated in the definition of the specific action value, when the AF requests specific actions in the initial AA-Request, the PCRF reports that action whenever new related information is available during the lifetime of the Rx session.

NOTE 2a: Whether the PCRF decides to report INDICATION_OF_RELEASE_OF_BEARER (4) or INDICATION_OF_FAILED_RESOURCES_ALLOCATION (9) upon receipt of a bearer failure from the PCEF is left to the implementation.

The following values are defined:

Void (0)

CHARGING_CORRELATION_EXCHANGE (1)

Within a RAR, this value shall be used when the server reports the access network charging identifier to the AF. The Access-Network-Charging-Identifier AVP shall be included within the request. In the AAR, this value indicates that the AF requests the server to provide the access network charging identifier to the AF for each authorized flow, when the access network charging identifier becomes known at the PCRF.

INDICATION_OF_LOSS_OF_BEARER (2)

Within a RAR, this value shall be used when the server reports a loss of a bearer (in the case of GPRS PDP context bandwidth modification to 0 kbit for GBR bearers) to the AF. The SDFs that are deactivated as a consequence of this loss of bearer shall be provided within the Flows AVP. In the AAR, this value indicates that the AF requests the server to provide a notification at the loss of a bearer.

INDICATION_OF_RECOVERY_OF_BEARER (3)

Within a RAR, this value shall be used when the server reports a recovery of a bearer (in the case of 3GPP-GPRS or 3GPP-EPS when PGW interoperates with a Gn/Gp SGSN, PDP context bandwidth modification from 0 kbit to another value for GBR bearers) to the AF. The SDFs that are re-activated as a consequence of the recovery of bearer shall be provided within the Flows AVP. In the AAR, this value indicates that the AF requests the server to provide a notification at the recovery of a bearer.

INDICATION_OF_RELEASE_OF_BEARER (4)

Within a RAR, this value shall be used when the server reports the release of a bearer (e.g. PDP context removal for 3GPP-GPRS or bearer/PDP context removal for 3GPP-EPS) to the AF. The SDFs that are deactivated as a consequence of this release of bearer shall be provided within the Flows AVP. In the AAR, this value indicates that the AF requests the server to provide a notification at the removal of a bearer. The content version corresponding to the affected media component may be provided in the Content-Version AVP included within the Flows AVP.

Void (5)

IP-CAN_CHANGE (6)

This value shall be used in RAR command by the PCRF to indicate a change in the IP-CAN type or RAT type (if applicable). When used in an AAR command, this value indicates that the AF is requesting subscription to IP-CAN change and RAT change notification. When used in RAR it indicates that the PCRF generated the request because of an IP-CAN or RAT change. IP-CAN-Type AVP, RAT-Type AVP (if applicable) ,AN-Trusted AVP (if applicable) and AN-GW-Address AVP (if applicable) shall be provided in the same request with the new/valid value(s).

If an IP-CAN type or RAT type change is due to IP flow mobility and a subset of the flows within the AF session is affected, the affected service data flows shall be provided in the same request.

If ATSSS feature is supported, and the PDU session is a MA PDU session, the PCF may include the MA-Information AVP in the RAR command with the additional/released IP-CAN type and RAT type (if applicable), with the new/valid values as described in clause E.4.

INDICATION_OF_OUT_OF_CREDIT (7)

Within a RAR, this value shall be used when the PCRF reports to the AF that SDFs have run out of credit, and that the termination action indicated by the corresponding Final-Unit-Action AVP applies (3GPP TS 32.240 [23] and 3GPP TS 32.299 [24]. The SDFs that are impacted as a consequence of the out of credit condition shall be provided within the Flows AVP. In the AAR, this value indicates that the AF requests the PCRF to provide a notification of SDFs for which credit is no longer available. Applicable to functionality introduced with the Rel8 feature as described in clause 5.4.1.

INDICATION_OF_SUCCESSFUL_RESOURCES_ALLOCATION (8)

Within a RAR, this value shall be used by the PCRF to indicate that the resources requested for particular service information have been successfully allocated. The SDFs corresponding to the resources successfully allocated shall be provided within the Flows AVP and the content version within the Content-Version AVP as included when the corresponding media component was provisioned.

In the AAR, this value indicates that the AF requests the PCRF to provide a notification when the resources associated to the corresponding service information have been allocated.

Applicable to functionality introduced with the Rel8 feature as described in clause 5.4.1.

NOTE 3: This value applies to applications for which the successful resource allocation notification is required for their operation since subscription to this value impacts the resource allocation signalling overhead towards the PCEF/BBERF.

INDICATION_OF_FAILED_RESOURCES_ALLOCATION (9)

Within a RAR, this value shall be used by the PCRF to indicate that the resources requested for a particular service information cannot be successfully allocated. The SDFs corresponding to the resources that could not be allocated shall be provided within the Flows AVP. In case of session modification failure, the status of the related service information may be reported in the Media-Component-Status AVP included within the Flows AVP and the content version within the Content-Version AVP as included when the corresponding media component was provisioned.

In the AAR, this value indicates that the AF requests the PCRF to provide a notification when the resources associated to the corresponding service information cannot be allocated. Applicable to functionality introduced with the Rel8 feature as described in clause 5.4.1.

NOTE 4: This value applies to applications for which the unsuccessful resource allocation notification is required for their operation since subscription to this value impacts the resource allocation signalling overhead towards the PCEF/BBERF.

INDICATION_OF_LIMITED_PCC_DEPLOYMENT (10)

Within a RAR, this value shall be used when the PCRF reports the limited PCC deployment (i.e. dynamically allocated resources are not applicable) as specified at Annex K and Annex L in 3GPP TS 23.203 [2] to the AF. In the AAR, this value indicates that the AF requests the PCRF to provide a notification for the limited PCC deployment. Applicable to functionality introduced with the Rel8 feature as described in clause 5.4.1.

USAGE_REPORT (11)

In the RA-Request (RAR), this value shall be used by the PCRF to report accumulated usage volume and/or time of usage when the usage threshold provided by the AF has been reached.

In the AA-Request (AAR), this value indicates that the AF requests PCRF to report accumulated usage volume and /or time of usage when it reaches the threshold.

Applicable to functionality introduced with the SponsoredConnectivity feature for volume usage reporting and with SCTimeBased UM feature for time usage reporting as described in clause 5.4.1.

ACCESS_NETWORK_INFO_REPORT (12)

In the RA-Request (RAR), this value shall be used by the PCRF to report access network information (i.e.user location and/or user timezone information) when the PCRF receiving an Access Network Information report corresponding to the AF session from the PCEF/BBERF.

In the AA-Request (AAR), this value indicates that the AF requests PCRF to report one time access network information when the PCRF receives the first Access Network Information report corresponding to the AF session from the PCEF/BBERF after the AF request for the access network information. The required access information is provided within the Required-Access-Info AVP. Applicable to functionality introduced with the NetLoc feature as described in clause 5.4.1.

The Specific-Action AVP with this value indicates a one time specific action.

INDICATION_OF_RECOVERY_FROM_LIMITED_PCC_DEPLOYMENT (13)

Within a RAR, this value shall be used when the PCRF reports the recovery from limited PCC deployment (i.e. the UE moves from the VPLMN to the HPLMN as specified at Annex K in 3GPP TS 23.203 [2]) to the AF. In the AAR, this value indicates that the AF requests the PCRF to provide a notification for the recovery from limited PCC deployment. Applicable to functionality introduced with the Rel8 feature as described in clause 5.4.1.

NOTE 5: This value is optional and only applicable to the scenario where PCC is deployed in the HPLMN but not in the VPLMN and dynamic policy provisioning only occurs in the home routed roaming cases if no BBERF is employed.

INDICATION_OF_ACCESS_NETWORK_INFO_REPORTING_FAILURE (14)

In the RAR, this value shall be used when the PCRF reports the access network information reporting failure. When applicable, the NetLoc-Access-Support AVP may be provided as well to indicate the reason for the access network information reporting failure. This specific action does not require to be provisioned by the AF. Applicable to functionality introduced with the NetLoc feature as described in clause 5.4.1.

INDICATION_OF_TRANSFER_POLICY_EXPIRED (15)

In the RAR, this value shall be used when the PCRF determines that the transfer policy has expired. This specific action does not require to be provisioned by the AF.

PLMN_CHANGE (16)

In the AA-Request (AAR), this value indicates that the AF requests PCRF to report changes of PLMN. In the RA-Request (RAR), this value shall be used by the PCRF to indicate that there was a change of PLMN. 3GPP-SGSN-MCC-MNC AVP shall be provided in the same RAR command with the new value and, if available, the NID AVP. Applicable to functionality introduced with the PLMNInfo feature as described in clause 5.4.1.

The NID AVP is only applicable in 5GS when the serving network is an SNPN, as described in Annex E.

EPS_FALLBACK (17)

In the RA-Request (RAR), this value shall be used to report EPS Fallback for the resources requested for a particular service information (media type voice).

In the AA-Request (AAR), this value indicates that the AF requests to provide a notification when the access network initiates EPS Fallback for the requested resources associated to service information for voice media type.

Applicable to functionality introduced with the EPSFallbackReport feature as described in clause 5.4.1.

This value is only applicable to 5GS as described in Annex E.

INDICATION_OF_REALLOCATION_OF_CREDIT (18)

Within a RAR, this value shall be used to report to the AF the SDFs for which credit has been reallocated after the former out of credit indication (3GPP TS 32.240 [23] and 3GPP TS 32.299 [24]). The SDFs that are impacted as a consequence of the reallocation of credit condition shall be provided within the Flows AVP. In the AAR, this value indicates the AF requests to provide a notification of SDFs for which credit has been reallocated after the former out of credit indication. Applicable to functionality introduced with the ReallocationOfCredit feature as described in clause 5.4.1.

This value is only applicable to 5GS as described in Annex E.

SUCCESSFUL_QOS_UPDATE (19)

Within a RAR, this value shall be used by the PCRF to indicate that the QoS of the default bearer has been successfully updated.

In the AAR, this value indicates that the AF requests the PCRF to provide a notification when the QoS of the default bearer has been successfully updated.

Applicable to functionality introduced with the MPSforDTS feature as described in clause 5.4.1.

FAILED_QOS_UPDATE (20)

Within a RAR, this value shall be used by the PCRF to indicate that the QoS of the default bearer has failed to update.

In the AAR, this value indicates that the AF requests the PCRF to provide a notification when the QoS of the default bearer has failed to update.

Applicable to functionality introduced with the MPSforDTS feature as described in clause 5.4.1.

5.3.14 Max-Requested-Bandwidth-DL AVP

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

When provided in an AA-Request, it indicates the maximum requested bandwidth. When provided in an AA-Answer, it indicates the maximum bandwidth acceptable by PCRF.

When the Extended-Max-Requested-BW-NR feature is supported and the value to be transmitted exceeds 2^32-1, the Extended-Max-Requested-Bandwidth-DL AVP shall be used , see clause 4.4.10 and clause 5.3.52.

5.3.15 Max-Requested-Bandwidth-UL AVP

The Max –Bandwidth-UL AVP (AVP code 516) is of type Unsigned32, and it indicates the maximum requested bandwidth in bits per second for an uplink IP flow. The bandwidth contains all the overhead coming from the IP-layer and the layers above, e.g. IP, UDP, RTP and RTP payload.

When provided in an AA-Request, it indicates the maximum requested bandwidth. When provided in an AA-Answer, it indicates the maximum bandwidth acceptable by PCRF.

When the Extended-Max-Requested-BW-NR feature is supported and the value to be transmitted exceeds 2^32-1, the Extended-Max-Requested-Bandwidth-UL AVP shall be used, see clause 4.4.10 and clause 5.3.53.

5.3.16 Media-Component-Description AVP

The Media-Component-Description AVP (AVP code 517) is of type Grouped, and it contains service information for a single media component within an AF session or the AF signalling information. The service information may be based on the SDI exchanged between the AF and the AF session client in the UE. The information may be used by the PCRF to determine authorized QoS and IP flow classifiers for bearer authorization and PCC rule selection.

Within one Diameter message, a single IP flow shall not be described by more than one Media-Component-Description AVP.

Bandwidth information and Flow-Status information provided within the Media-Component-Description AVP applies to all those IP flows within the media component, for which no corresponding information is being provided within Media-Sub-Component AVP(s). As defined in 3GPP TS 29.213 [9], the bandwidth information within the media component level Max-Requested-Bandwidth-DL and Max-Requested-Bandwidth-UL AVPs applies separately to each media subcomponent except for RTCP media subcomponent.

The mapping of bandwidth information for RTCP media subcomponent is defined in 3GPP TS 29.213 [9] clause 6.2.

If CHEM feature is supported, Max-PLR-DL AVP and Max-PLR-UL AVP information is provided within the Media-Component-Description AVP as defined in 3GPP TS 29.213 [9].

If the QoSHint feature is supported the Desired-Max-Latency AVP and/or Desired-Max-Loss AVP may be provided within the Media-Component-Description AVP as defined in 3GPP TS 29.213 [9].

If FLUS feature is supported the FLUS-Identifier AVP may be provided within the Media-Component-Description AVP. Additionally, the Desired-Max-Latency AVP and/or the Desired-Max-Loss AVP may be provided as defined in 3GPP TS 29.213 [9].

The Max-Requested-Bandwidth-UL, Max-Requested-Bandwidth-DL, Max-Supported-Bandwidth-UL, Max-Supported-Bandwidth-DL, Min-Desired-Bandwidth-UL, Min-Desired-Bandwidth-DL, Min-Requested-Bandwidth-UL and Min-Requested-Bandwidth-DL AVPs only represent bandwidth values up 2^32-1 bps. To represent higher values, the Extended-Max-Requested-Bandwidth-UL, Extended-Max-Requested-Bandwidth-DL, Extended-Max-Supported-Bandwidth-UL, Extended-Max-Supported-Bandwidth-DL, Extended-Min-Desired-Bandwidth-UL, Extended-Min-Desired-Bandwidth-DL, Extended-Min-Requested-Bandwidth-UL and Extended-Min-Requested-Bandwidth-DL AVPs may be used as described in clause 4.4.10.

If a Media-Component-Description AVP is not supplied by the AF, or if optional AVP(s) within a Media-Component-Description AVP are omitted, but corresponding information has been provided in previous Diameter messages, the previous information for the corresponding IP flow(s) remains valid.

All IP flows within a Media-Component-Description AVP are permanently disabled by supplying a Flow Status AVP with value "REMOVED". The server may delete corresponding filters and state information.

Reservation-Priority provided within the Media-Component-Description AVP in the request from the AF applies to all those IP flows within the media component and describes the relative importance of the IP flow as compared to other IP flows. The PCRF may use this value to implement priority based admission. If the Reservation-Priority AVP is not specified the IP flow priority is DEFAULT (0).

Each Media-Component-Description AVP shall contain either zero, or one, or two Codec-Data AVPs. In the case of conflicts, information contained in other AVPs either within this Media-Component-Description AVP, or within the corresponding Media-Component-Description AVP in a previous message, shall take precedence over information within the Codec-Data AVP(s). The AF shall provision all the available information in other applicable AVPs in addition to the information in the Codec-Data AVP, if such other AVPs are specified.

If the SDP offer-answer procedures of IETF RFC 3264 [18] are applicable for the session negotiation between the two ends taking part in the communication (e.g. for IMS), the following applies:

– The AF shall provision information derived from an SDP answer and shall also provision information derived from the corresponding SDP offer.

– If the Media-Component-Description AVP contains two Codec-Data AVPs, one of them shall represent an SDP offer and the other one the corresponding SDP answer.

– If the Media-Component-Description AVP contains one Codec-Data AVP, and this AVP represents an SDP offer, the AF shall provision the corresponding SDP answer information in a Codec-Data AVP within a subsequent Rx message.

NOTE 1: Some SDP parameters for the same codec in the SDP offer and answer are independent of each other and refer to IP flows in opposite directions, for instance some MIME parameters conveyed within "a=fmtp" SDP lines and the packetization time within the "a=ptime" line. Other parameters within the SDP answer take precedence over corresponding parameters within the SDP offer.

If SDP is applied without using the offer-answer procedures, zero or one Codec-Data AVP shall be provisioned.

Sharing-Key-DL AVP and/or Sharing-Key-UL AVP provided within the Media-Component-Description AVP indicates that the media components that include the same value of the Sharing-Key-UL AVP and/or Sharing-Key-DL AVP may share resources in the related direction.

NOTE 2: RTCP traffic is not subject to resource sharing.

The Content-Version AVP may be included in order to indicate the content version of a media component.

The Priority-Sharing-Indicator AVP may be included to indicate that the media component can use the same Allocation and Retention Priority as media flows which are assigned the same QCI in the PCRF belonging to other AF sessions for the same IP-CAN session that also contain the Priority-Sharing-Indicator AVP.

The Pre-emption-Capability AVP and Pre-emption-Vulnerability AVP may be included together with Priority-Sharing-Indicator AVP for PCRF Allocation and Retention Priority decision.

The PCRF may provide the Media-Component-Description AVP(s) within the Acceptable-Service-Info AVP in the AA-Answer command if the service information received from the AF is rejected. For this usage, the Media-Component-Description AVP shall only include the appropriate Media-Component-Number AVP and the Max-Requested-Bandwidth-UL and/or Max-Requested-Bandwidth-DL AVPs and/ or the Extended-Max-Requested-BW-UL AVP and/or the Extended-Max-Requested-BW-DL AVP (see clause 4.4.10) indicating the maximum acceptable bandwidth.

AVP format:

Media-Component-Description ::= < AVP Header: 517 >

{ Media-Component-Number } ; Ordinal number of the media comp.

*[ Media-Sub-Component ] ; Set of flows for one flow identifier

[ AF-Application-Identifier ]

[ FLUS-Identifier ]

[ Media-Type ]

[ Max-Requested-Bandwidth-UL ]

[ Max-Requested-Bandwidth-DL ]

[ Max-Supported-Bandwidth-UL ]

[ Max-Supported-Bandwidth-DL ]

[ Min-Desired-Bandwidth-UL ]

[ Min-Desired-Bandwidth-DL ]

[ Min-Requested-Bandwidth-UL ]

[ Min-Requested-Bandwidth-DL ]

[ Extended-Max-Requested-BW-UL ]

[ Extended-Max-Requested-BW-DL ]

[ Extended-Max-Supported-BW-UL ]

[ Extended-Max-Supported-BW-DL ]

[ Extended-Min-Desired-BW-UL ]

[ Extended-Min-Desired-BW-DL ]

[ Extended-Min-Requested-BW-UL ]

[ Extended-Min-Requested-BW-DL ]

[ Flow-Status ]

[ Priority-Sharing-Indicator ]

[ Pre-emption-Capability ]

[ Pre-emption-Vulnerability ]

[ Reservation-Priority ]

[ RS-Bandwidth ]

[ RR-Bandwidth ]

0*2[ Codec-Data ]

[ Sharing-Key-DL ]

[ Sharing-Key-UL ]

[ Content-Version ]

[ Max-PLR-DL ]

[ Max-PLR-UL ]

[ Desired-Max-Latency ]

[ Desired-Max-Loss ]

*[ AVP ]

5.3.17 Media-Component-Number AVP

The Media-Component-Number AVP (AVP code 518) is of type Unsigned32, and it contains the ordinal number of the media component, assigned according to the rules in Annex B.

When this AVP refers to AF signalling, this is indicated by using the value 0 according to the rules in Annex B.

5.3.18 Media-Sub-Component AVP

The Media-Sub-Component AVP (AVP code 519) is of type Grouped, and it contains the requested bitrate and filters for the set of IP flows identified by their common Flow-Identifier. The Flow-Identifier is defined in Annex B.

Possible Bandwidth information and Flow-Status information provided within the Media-Sub-Component AVP takes precedence over information within the encapsulating Media Component Description AVP. If a Media-Sub-Component- AVP is not supplied, or if optional AVP(s) within a Media-Sub-Component AVP are omitted, but corresponding information has been provided in previous Diameter messages, the previous information for the corresponding IP flow(s) remains valid, unless new information is provided within the encapsulating Media‑Component-Description AVP. If Flow-Description AVP(s) are supplied, they replace all previous Flow‑Description AVP(s), even if a new Flow-Description AVP has the opposite direction as the previous Flow‑Description AVP. The AF may also include the ToS-Traffic-Class AVP for requesting Type of Service or Traffic Class (for IPv4 and IPv6 respectively) based packet filter for the related flow.

The AF-Signalling-Protocol AVP may be included only if the Flow-Usage AVP has a value of ‘AF_SIGNALLING’.

All IP flows within a Media-Sub-Component- AVP are permanently disabled by supplying a Flow Status AVP with value "REMOVED". The server may delete corresponding filters and state information.

AVP format:

Media-Sub-Component ::= < AVP Header: 519 >

{ Flow-Number } ; Ordinal number of the IP flow

0*2 [ Flow-Description ] ; UL and/or DL

[ Flow-Status ]

[ Flow-Usage ]

[ Max-Requested-Bandwidth-UL ]

[ Max-Requested-Bandwidth-DL ]

[ Extended-Max-Requested-BW-UL ]

[ Extended-Max-Requested-BW-DL ]

[ AF-Signalling-Protocol ]

[ ToS-Traffic-Class ]

*[ AVP ]

5.3.19 Media-Type AVP

The Media-Type AVP (AVP code 520) is of type Enumerated, and it determines the media type of a session component. The media types indicate the type of media in the same way as the SDP media types with the same names defined in RFC 4566 [13]. The following values are defined:

– AUDIO (0)

– VIDEO (1)

– DATA (2)

– APPLICATION (3)

– CONTROL (4)

– TEXT (5)

– MESSAGE (6)

– OTHER (0xFFFFFFFF)

5.3.20 RR-Bandwidth AVP

The RR-Bandwidth AVP (AVP code 521) is of type Unsigned32, and it indicates the maximum required bandwidth in bits per second for RTCP receiver reports within the session component, as specified in IETF RFC 3556 [11]. The bandwidth contains all the overhead coming from the IP-layer and the layers above, i.e. IP, UDP and RTCP.

5.3.21 RS-Bandwidth AVP

The RS-Bandwidth AVP (AVP code 522) is of type Unsigned32, and it indicates the maximum required bandwidth in bits per second for RTCP sender reports within the session component, as specified in RFC 3556 [11]. The bandwidth contains all the overhead coming from the IP-layer and the layers above, i.e. IP, UDP and RTCP.

5.3.22 SIP-Forking-Indication AVP

The SIP-Forking-Indication AVP (AVP code 523) is of type Enumerated, and describes if several SIP dialogues are related to one Diameter session:

SINGLE_DIALOGUE (0)

This value is used to indicate that the Diameter session relates to a single SIP dialogue.
This is the default value applicable if the AVP is omitted.

SEVERAL_DIALOGUES (1)

This value is used to indicate that the Diameter session relates to several SIP dialogues.

5.3.23 Service-URN AVP

The Service-URN AVP (AVP code 525) is of type OctetString, and it indicates that an AF session is used for emergency or RLOS traffic.

It contains values of the service URN and it may include subservices, as defined in [21] for emergency and other well-known services or registered at IANA. The string "urn:service:" in the beginning of the URN shall be omitted in the AVP and all subsequent text shall be included. Examples of valid values of the AVP are "sos", "sos.fire", "sos.police" and "sos.ambulance".

5.3.24 Acceptable-Service-Info AVP

The Acceptable-Service-Info AVP (AVP code 526) is of type Grouped, and contains the maximum bandwidth for an AF session and/or for specific media components that will be authorized by the PCRF. The Max-Requested-Bandwidth-DL AVP, the Max-Requested-Bandwidth-UL AVP, the Extended-Max-Requested-BW-DL AVP and the Extended-Max-Requested-BW-UL AVP (see clause 4.4.10)directly within the Acceptable-Service-Info AVP indicate the acceptable bandwidth for the entire AF session. The Max-Requested-Bandwidth-DL AVP, Max-Requested-Bandwidth-UL AVP, Extended-Max-Requested-BW-DL AVP and Extended-Max-Requested-BW-UL AVP within a Media-Component-Description AVP included in the Acceptable-Service-Info AVP indicate the acceptable bandwidth for the corresponding media component.

If the acceptable bandwidth applies to one or more media components, only the Media-Component-Description AVP will be provided. If the acceptable bandwidth applies to the whole AF session, only the Max-Requested-Bandwidth-DL AVP the Max-Requested-Bandwidth-UL AVP, the Extended-Max-Requested-BW-DL AVP and the Extended-Max-Requested-BW-DL AVP will be included.

Acceptable-Service-Info::= < AVP Header: 526 >

*[ Media-Component-Description]

[ Max-Requested-Bandwidth-DL ]

[ Max-Requested-Bandwidth-UL ]

[ Extended-Max-Requested-BW-DL ]

[ Extended-Max-Requested-BW-UL ]

*[ AVP ]

5.3.25 Service-Info-Status-AVP

The Service-Info-Status AVP (AVP code 527) is of type Enumerated, and indicates the status of the service information that the AF is providing to the PCRF. If the Service-Info-Status AVP is not provided in the AA request, the value FINAL SERVICE INFORMATION shall be assumed.

FINAL SERVICE INFORMATION (0)

This value is used to indicate that the service has been fully negotiated between the two ends and service information provided is the result of that negotiation.

PRELIMINARY SERVICE INFORMATION (1)

This value is used to indicate that the service information that the AF has provided to the PCRF is preliminary and needs to be further negotiated between the two ends (e.g. for IMS when the service information is sent based on the SDP offer).

5.3.26 AF-Signalling-Protocol-AVP

The AF-Signalling-Protocol AVP (AVP code 529) is of type Enumerated, and indicates the protocol used for signalling between the UE and the AF. If the AF-Signalling-Protocol AVP is not provided in the AA-Request, the value NO_INFORMATION shall be assumed.

NO_INFORMATION (0)

This value is used to indicate that no information about the AF signalling protocol is being provided.

SIP (1)

This value is used to indicate that the signalling protocol is Session Initiation Protocol.

5.3.27 Sponsored-Connectivity-Data AVP

The Sponsored-Connectivity-Data AVP (AVP code 530) is of type Grouped, and contains the data associated with the sponsored data connectivity.

The Sponsor-Identity AVP identifies the sponsor. It shall be included by the AF in the Sponsored-Connectivity-Data AVP except for the case of disabling sponsored data connectivity.

The Application-Service-Provider-Identity AVP identifies the application service provider. It shall be included by the AF in the Sponsored-Connectivity-Data AVP except for the case of disabling sponsored data connectivity.

The Granted-Service-Unit AVP shall be used by the AF to provide usage threshold to the PCRF if the volume and/or time of traffic allowed during the sponsored data connectivity is to be monitored.

The Used-Service-Unit AVP shall be used by the PCRF to provide the measured usage to the AF. Reporting shall be done, as requested by the AF, in CC-Total-Octets, CC-Input-Octets, CC-Output-Octets or CC-Time of the Used-Service-Unit AVP.

Sponsoring-Action AVP shall be used by the AF to provide the indication to the PCRF if sponsored data connectivity is to be enabled or disabled.

AVP format:

Sponsored-Connectivity-Data::= < AVP Header: 530 >

[ Sponsor-Identity ]

[ Application-Service-Provider-Identity ]

[ Granted-Service-Unit ]

[ Used-Service-Unit ]

[ Sponsoring-Action ]

*[ AVP ]

5.3.28 Sponsor-Identity AVP

The Sponsor-Identity AVP (AVP code 531) is of type UTF8String and is used for sponsored data connectivity purposes as an identifier of the sponsor.

5.3.29 Application-Service-Provider-Identity AVP

The Application-Service-Provider-Identity AVP (AVP code 532) is of type UTF8String and is used for sponsored data connectivity purposes as an identifier of the application service provider.

5.3.30 MPS-Identifier AVP

The MPS-Identifier AVP (AVP code 528) is of type OctetString, and it indicates that an AF session relates to an MPS session. It contains the national variant for MPS service name (e.g., NGN GETS).

5.3.31 Rx-Request-Type AVP

The Rx-Request-Type AVP (AVP code 533) is of type Enumerated, and contains the reason for sending the AA-Request message.

The following values are defined:

INITIAL_REQUEST (0)

An initial request is used to initiate an Rx session and contains information that is relevant to initiation.

UPDATE_REQUEST (1)

An update request is used to update an existing Rx session.

PCSCF_RESTORATION (2)

A P-CSCF Restoration is requested. This value is only applicable to the PCSCF-Restoration-Enhancement feature defined in clause 5.4.1.

5.3.32 Min-Requested-Bandwidth-DL AVP

The Min-Requested-Bandwidth-DL AVP (AVP code 534) is of type Unsigned32, and it indicates the minimum requested bandwidth in bits per second for a downlink IP flow. The bandwidth contains all the overhead coming from the IP-layer and the layers above, e.g. IP, TCP, UDP, HTTP, RTP and RTP payload.

When provided in an AA-Request, it indicates the minimum requested bandwidth.

When the Extended-Min-Requested-BW-NR feature is supported and the value to be transmitted exceeds 2^32-1, the Extended-Min-Requested-Bandwidth-DL AVP shall be used, see clause 4.4.10 and clause 5.3.58.

5.3.33 Min-Requested-Bandwidth-UL AVP

The Min-Requested-Bandwidth-UL AVP (AVP code 535) is of type Unsigned32, and it indicates the minimum requested bandwidth in bits per second for an uplink IP flow. The bandwidth contains all the overhead coming from the IP-layer and the layers above, e.g. IP, TCP, UDP, HTTP, RTP and RTP payload.

When provided in an AA-Request, it indicates the minimum requested bandwidth.

When the Extended-Min-Requested-BW-NR feature is supported and the value to be transmitted exceeds 2^32-1, the Extended-Min-Requested-Bandwidth-UL AVP shall be used, see clause 4.4.10 and clause 5.3.59.

5.3.34 Required-Access-Info AVP

The Required-Access-Info AVP (AVP code 536) is of type Enumerated, and contains the access network information required for that AF session.

The following values are defined:

USER_LOCATION (0)

Indicates that the user location information shall be reported, the PCRF shall report the user location information within the 3GPP-User-Location-Info AVP (if available), the serving network identifier containing PLMN identifier within the 3GPP-SGSN-MCC-MNC AVP (if available) and NID AVP (if available), the user location information within the TWAN-Identifier (if available) , UE-Local-IP-Address AVP (if available) , UDP-Source-Port AVP (if available), TCP-Source-Port AVP (if available) and User-Location-Info-Time AVP (if available).

The NID AVP is only applicable in 5GS when the serving network is an SNPN, as described in Annex E.

MS_TIME_ZONE (1)

Indicates that the user timezone information shall be reported, the PCRF shall report the user timezone information within the 3GPP-MS-TimeZone AVP.

5.3.35 IP-Domain-Id AVP

The IP-Domain-Id AVP (AVP code 537) is of type (OctetString), and indicates the domain information which assists session binding.

5.3.36 GCS-Identifier AVP

The GCS-Identifier AVP (AVP code 538) is of type OctetString, and it indicates that an AF session relates to a Group Communication session that requires prioritization.The values that identify the Group Communication session are not specified.

5.3.37 Sharing-Key-DL AVP

The Sharing-Key-DL AVP (AVP code 539) is of type Unsigned32 and is used to identify what media components may share resource in the downlink direction.

The Sharing-Key-DL AVP shall be used as follows:

– If resource sharing applies between media components across AF sessions for the same user, the same value of the Sharing-Key-DL AVP shall be used;

– If resource sharing does not apply between media components across AF sessions for the same user, a different value of the Sharing-Key-DL AVP shall be used for each media component.

5.3.38 Sharing-Key-UL AVP

The Sharing-Key-UL AVP (AVP code 540) is of type Unsigned32 and is used to identify what media components may share resource in the uplink direction.

The Sharing-Key-UL AVP shall be used as follows:

– If resource sharing applies between media components across AF sessions for the same user, the same value of the Sharing-Key-UL AVP shall be used;

– If resource sharing does not apply between media components across AF sessions for the same user, a different value of the Sharing-Key-UL AVP shall be used for each media component.

5.3.39 Retry-Interval AVP

The Retry-Interval AVP (AVP code 541) is of type Unsigned32, and it indicates a time interval in seconds to wait until which the AF retries to send the same service information to the PCRF (for the same IP-CAN session) when the service information is temporarily rejected by the PCRF (e.g. due to the detected congestion status of the cell the user is located in).

5.3.40 Sponsoring-Action AVP

The Sponsoring-Action AVP (AVP code 542) is of type Enumerated, and contains the indication whether to enable or disable/not enable sponsored data connectivity.

The following values are defined:

DISABLE_SPONSORING (0)

Disable sponsored data connectivity or not enable sponsored data connectivity

ENABLE_SPONSORING (1)

Enable sponsored data connectivity.

NOTE: The use of value DISABLE_SPONSORING (0) to "not enable" sponsored data connectivity is used at initial provisioning of session information to provide sponsor information but not enable it at that point in time and to "disable" sponsored data connectivity is used at modification of session information when disabling sponsored data connectivity previously enabled.

5.3.41 Max-Supported-Bandwidth-DL AVP

The Max-Supported-Bandwidth-DL AVP (AVP code 543) is of type Unsigned32, and it indicates the maximum supported bandwidth in bits per second for a downlink IP flow as defined in 3GPP TS 26.114 [41]. The bandwidth contains all the overhead coming from the IP-layer and the layers above, e.g. IP, UDP, RTP and RTP payload.

When the Extended-BW-E2EQOSMTSI-NR feature is supported and the value to be transmitted exceeds 2^32-1, the Extended-Max-Supported-Bandwidth-DL AVP shall be used, see clause 4.4.10 and clause 5.3.54.

5.3.42 Max-Supported-Bandwidth-UL AVP

The Max-Supported-Bandwidth-UL AVP (AVP code 544 is of type Unsigned32, and it indicates the maximum supported bandwidth in bits per second for an uplink IP flow as defined in 3GPP TS 26.114 [41]. The bandwidth contains all the overhead coming from the IP-layer and the layers above, e.g. IP, UDP, RTP and RTP payload.

When the Extended-BW-E2EQOSMTSI-NR feature is supported and the value to be transmitted exceeds 2^32-1, the Extended-Max-Supported-Bandwidth-UL AVP shall be used, see clause 4.4.10 and clause 5.3.55.

5.3.43 Min-Desired-Bandwidth-DL AVP

The Min-Desired-Bandwidth-DL AVP (AVP code 545) is of type Unsigned32, and it indicates the minimum desired bandwidth in bits per second for a downlink IP flow as defined in 3GPP TS 26.114 [41]. The bandwidth contains all the overhead coming from the IP-layer and the layers above, e.g. IP, UDP, RTP and RTP payload.

When the Extended-BW-E2EQOSMTSI-NR feature is supported and the value to be transmitted exceeds 2^32-1, the Extended-Min-Desired-Bandwidth-DL AVP shall be used, see clause 4.4.10 and clause 5.3.56.

5.3.44 Min-Desired-Bandwidth-UL AVP

The Min-Desired-Bandwidth-DL AVP (AVP code 546) is of type Unsigned32, and it indicates the minimum desired bandwidth in bits per second for an uplink IP flow as defined in 3GPP TS 26.114 [41]. The bandwidth contains all the overhead coming from the IP-layer and the layers above, e.g. IP, UDP, RTP and RTP payload.

When the Extended-BW-E2EQOSMTSI-NR feature is supported and the value to be transmitted exceeds 2^32-1, the Extended-Min-Desired-Bandwidth-UL AVP shall be used, see clause 4.4.10 and clause 5.3.57.

5.3.45 MCPTT-Identifier AVP

The MCPTT-Identifier AVP (AVP code 547) is of type OctetString, and it includes either one of the namespace values used for MCPTT (see IETF RFC 8101 [45]) and it may include the name of the MCPTT service provider.

5.3.45A MCVideo-Identifier AVP

The MCVideo-Identifier AVP (AVP code 562) is of type OctetString, and it includes the name of the MCVideo service provider.

5.3.46 Service-Authorization-Info AVP

The Service-Authorization-Info AVP (AVP code 548) is of type Unsigned32, it shall contain a bit mask and indicatethe result of the authorization for the service request from the AF. The bit 0 shall be the least significant bit. For example, to get the value of bit 0, a bit mask of 0x0001 should be used. The meaning of the bits shall be as defined below:

Table 5.3.46: Service-Authorization-Info

Bit	Name	Description
0	The transfer policy is known/unknown.	This bit, when set, indicates that the transfer policy is unknown.
1	The transfer policy has expired/has not expired	This bit, when set, indicates that the transfer policy has expired.
2	The time window of the transfer policy has occurred/has not yet occurred	This bit, when set, indicates that the time window of the transfer policy has not yet occurred.

5.3.47 Priority-Sharing-Indicator AVP

The Priority-Sharing-Indicator AVP (AVP code 550) is of type Enumerated and is used to indicate that the related media component can use the same Allocation and Retention Priority as media component(s) which are assigned the same QCI in the PCRF belonging to other AF sessions for the same IP-CAN session that also contain the Priority-Sharing-Indicator AVP set to PRIORITY_SHARING_ENABLED.

The following values are defined:

PRIORITY_SHARING_ENABLED (0)

This value indicates that the related media component is allowed to share the Allocation and Retention Priority with media components belonging to other AF sessions that have also indicated that priority sharing is enabled.

PRIORITY_SHARING_DISABLED (1)

This value indicates that the related media component is not allowed to share the Allocation and Retention Priority with media components belonging to other AF sessions. This is the default value applicable if this AVP is not supplied.

5.3.48 Media-Component-Status AVP

The Media-Component-Status AVP (AVP code 549) is of type Unsigned32, and it describes the status of the PCC/QoS rule(s) related to a media component.

The following values are defined in this specification:

0 (ACTIVE):

This value shall be used to indicate that the PCC/QoS rule(s) related to certain media component are active.

1 (INACTIVE):

This value shall be used to indicate that the PCC/QoS rule(s) related to certain media component are inactive. This is the default value applicable if this AVP is not supplied.

NOTE: It is assumed that the AF considers the PCC/QoS rule(s) related to the media component(s) for which the Media-Component-Status AVP(s) are not received as inactive when the Specific-Action AVP set to INDICATION_OF_FAILED_RESOURCES_ALLOCATION (9) is received.

5.3.49 Content-Version AVP

The Content-Version AVP (AVP code 552) is of type Unsigned64, and it indicates the version of some content, e.g. of the content of a media component included within the Media-Component-Description AVP. The content version shall be unique for the content and for the lifetime of that content.

NOTE: The method of assigning content versions within the Content-Version AVPs is implementation specific. Example implementations are a monotonically increasing number or a value based on a timestamp.

5.3.50 AF-Requested-Data AVP

The AF-Requested-Data AVP (AVP code 551) is of type Unsigned32 and indicates the information that the AF requested to be exposed, it shall contain a bit mask. The bit 0 shall be the least significant bit. For example, to get the value of bit 0, a bit mask of 0x0001 should be used. The meaning of the bits shall be as defined below:

Table 5.3.50.1: AF-Requested-Data

Bit	Name	Description
0	EPC-level identities required	This bit, when set, indicates that the AF requests the PCRF to provide the EPC-level identities (MSISDN, IMSI, IMEI(SV)) available for that IP-CAN session.

5.3.51 Pre-emption-Control-Info AVP

The Pre-emption-Control-Info (AVP code 553) is of type Unsigned32, it shall contain a bit mask and indicate that how the PCRF to perform pre-emption among multiple potential media flow candidates of same priority. Pre-emption-Control-Info AVP is provided at the AAR command level and the latest provided value within the Pre-emption-Control-Info AVP shall be applied to all potential media flow candidates. The bit 0 shall be the least significant bit. For example, to get the value of bit 0, a bit mask of 0x0001 should be used. The meaning of the bits shall be as defined below:

The following values are defined, only one bit shall be set at the same time:

Table 5.3. 51: Pre-emption-Control-Info

Bit	Name	Description
0	Most recent added flow	This bit, when set, indicates that the most recent added flow is to be pre-empted.
1	Least recent added flow	This bit, when set, indicates that the least recent added flow is to be pre-empted.
2	Highest bandwidth flow	This bit, when set, indicates that the highest bandwidth flow is to be pre-empted.

5.3.52 Extended-Max-Requested-BW-DL AVP

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

When provided in an AA-Request, it indicates the maximum requested bandwidth. When provided in an AA-Answer, it indicates the maximum bandwidth acceptable by PCRF.

5.3.53 Extended-Max-Requested-BW-UL AVP

The Extended-Max–Requested-BW-UL AVP (AVP code 555) is of type Unsigned32, and it indicates the maximum requested bandwidth in kbit per second for an uplink IP flow. The bandwidth contains all the overhead coming from the IP-layer and the layers above, e.g. IP, UDP, RTP and RTP payload.

When provided in an AA-Request, it indicates the maximum requested bandwidth. When provided in an AA-Answer, it indicates the maximum bandwidth acceptable by PCRF.

5.3.54 Extended-Max-Supported-BW-DL AVP

The Extended-Max-Supported-BW-DL AVP (AVP code 556) is of type Unsigned32, and it indicates the maximum supported bandwidth in kbit per second for a downlink IP flow as defined in 3GPP TS 26.114 [41]. The bandwidth contains all the overhead coming from the IP-layer and the layers above, e.g. IP, UDP, RTP and RTP payload.

5.3.55 Extended-Max-Supported-BW-UL AVP

The Extended-Max-Supported-BW-UL AVP (AVP code 557) is of type Unsigned32, and it indicates the maximum supported bandwidth in kbit per second for an uplink IP flow as defined in 3GPP TS 26.114 [41]. The bandwidth contains all the overhead coming from the IP-layer and the layers above, e.g. IP, UDP, RTP and RTP payload.

5.3.56 Extended-Min-Desired-BW-DL AVP

The Extended-Min-Desired-BW-DL AVP (AVP code 558) is of type Unsigned32, and it indicates the minimum desired bandwidth in kbit per second for a downlink IP flow as defined in 3GPP TS 26.114 [41]. The bandwidth contains all the overhead coming from the IP-layer and the layers above, e.g. IP, UDP, RTP and RTP payload.

5.3.57 Extended-Min-Desired-BW-UL AVP

The Extended-Min-Desired-BW-UL AVP (AVP code 559) is of type Unsigned32, and it indicates the minimum desired bandwidth in kbit per second for an uplink IP flow as defined in 3GPP TS 26.114 [41]. The bandwidth contains all the overhead coming from the IP-layer and the layers above, e.g. IP, UDP, RTP and RTP payload.

5.3.58 Extended-Min-Requested-BW-DL AVP

The Extended-Min-Requested-BW-DL AVP (AVP code 560) is of type Unsigned32, and it indicates the minimum requested bandwidth in kbit per second for a downlink IP flow. The bandwidth contains all the overhead coming from the IP-layer and the layers above, e.g. IP, TCP, UDP, HTTP, RTP and RTP payload.

When provided in an AA-Request, it indicates the minimum requested bandwidth.

5.3.59 Extended-Min-Requested-BW-UL AVP

The Extended-Min-Requested-Bandwidth-UL AVP (AVP code 561) is of type Unsigned32, and it indicates the minimum requested bandwidth in kbit per second for an uplink IP flow. The bandwidth contains all the overhead coming from the IP-layer and the layers above, e.g. IP, TCP, UDP, HTTP, RTP and RTP payload.

When provided in an AA-Request, it indicates the minimum requested bandwidth.

5.3.60 IMS-Content-Identifier AVP

The IMS-Content-Identifier AVP (AVP code 563) is of type OctetString, and it contains information that identifies the particular IMS communication service or communication dialogue that the AF service session belongs to. This information may be used by the PCRF, for example, to differentiate Charging for different communication dialogs in the IMS session.

5.3.61 IMS-Content-Type AVP

The IMS-Content-Type AVP (AVP code 564) is of type Enumerated, and it indicates the type of IMS communication service the AF session refers to. The following values are defined:

NO_CONTENT_DETAIL (0)

This value is used to indicate that no information about the type of IMS communication service is being provided

CAT (1)

This value is used to indicate that the type of IMS communication service is Customized Alerting Tones

CONFERENCE (2)

This value is used to indicate that the type of IMS communication service is 3PTY conference

5.3.62 Callee-Information AVP

The Callee-Information AVP (AVP code 565) is of type Grouped, and it contains information that identifies the callee information of the AF service session. This information may be used by the PCRF, for example, to provide the callee information in the PCC rule decision for further volume based charging.

AVP Format:

Callee-Information::= < AVP Header: 565 >

[Called-Party-Address]

*[Requested-Party-Address]

*[Called-Asserted-Identity]

*[AVP]

5.3.63 FLUS-Identifier AVP

The FLUS-Identifier AVP (AVP code 566) is of type OctetString, and it indicates that a media component is used for FLUS media.

It is derived from the media level attribute "a=label:" (see IETF RFC 4574 [68]) obtained from the SDP body. It contains the string after "a=label:" starting with "flus" and may be followed by more characters as described in 3GPP TS 26.238 [69].

5.3.64 Desired-Max-Latency AVP

The Desired-Max-Latency AVP (AVP code 567) is of type Float32 and describes the maximum desirable end to end transport level packet latency in milliseconds as a zero-based integer or as a non-zero real value. The value excludes any application level processing in the sender and receivers, such as e.g. application-level retransmission or encoding/decoding.

5.3.65 Desired-Max-Loss AVP

The Desired-Max-Loss AVP (AVP code 568) is of type Float32 and describes the maximum desirable end to end transport level packet loss rate in percent (without "%" sign) as a zero-based integer or as a non-zero real value.

5.3.66 MA-Information AVP

The MA-Information AVP (AVP code 570) is of type Grouped, and contains the additional or released IP-CAN type and RAT type for a MA PDU session.

MA-Information::= < AVP Header: 570 >

[ IP-CAN-Type ]

[ RAT-Type ]

[ MA-Information-Action ]

*[ AVP ]

5.3.67 MA-Information-Action AVP

The MA-Information-Action AVP (AVP code 571) is of type Unsigned32, and it indicates the action to apply to the IP-CAN type and RAT type values included in the MA-Information AVP.

The following values are defined in this specification:

0 (ADD):

This value shall be used to indicate that the IP-CAN Type/RAT Type included in the MA-Information AVP are available for the MA PDU session.

1 (RELEASE):

This value shall be used to indicate that the IP-CAN Type/RAT Type included in the MA-Information AVP are released and not available for the MA PDU session.

0 (ADD) is the default value.

5.3.68 NID AVP

The NID AVP (AVP code 569) is of type OctetString, and it indicates Network Identifier (NID) consisting on 44 bits (11 hexadecimal digits), as specified in 3GPP TS 23.003 [38], clause 12.7.

The NID AVP is only applicable in 5GS when the serving network is an SNPN, as described in Annex E.

5.3.69 5GS-RAN-NAS-Release-Cause AVP (3GPP-5GS and Non-3GPP-5GS access type)

The 5GS-RAN-NAS-Release-Cause AVP (AVP code 572) is of type Grouped, and indicates the RAN or NAS release cause code information in 3GPP-5GS and non-3GPP-5GS access types.

AVP Format:

5GS-RAN-NAS-Release-Cause ::= < AVP Header: 572 >

[5GMM-Cause]

[5GSM-Cause]

[NGAP-Cause]

*[ AVP ]

5.3.70 5GMM-Cause AVP

The 5GMM-Cause AVP (AVP code 573) is of type Unsigned32 and indicates the 5GMM cause code information. The AVP shall be coded as per the 5GMM Cause in clause 9.11.3.2 of 3GPP TS 24.501 [70].

5.3.71 5GSM-Cause AVP

The 5GSM-Cause AVP (AVP code 574) is of type Unsigned32 and indicates the 5GSM cause code information. The AVP shall be coded as per the 5GSM Cause in clause 9.11.4.2 of 3GPP TS 24.501 [70].

5.3.72 NGAP-Cause AVP

The NGAP-Cause AVP (AVP code 575) is of type Grouped and indicates the NG Application Protocol cause value as specified in clause 9.4.5 of 3GPP TS 38.413 [71].

AVP Format:

NGAP-Cause ::= < AVP Header: 575 >

{NGAP-Group}

{NGAP-Value}

5.3.73 NGAP-Group AVP

The NGAP-Group AVP (AVP code 576) is of type Unsigned32, and it indicates the group of the NGAP cause. The value of this IE shall equal to the ASN.1 value of the specified NGAP cause group

NGAP supports cause groups defined as separate enumerations, as specified in clause 9.4.5 of 3GPP TS 38.413 [71]. The following values are defined in this specification:

0:

This value indicates the NGAP cause group is "radioNetwork".

1:

This value indicates the NGAP cause group is "transport".

2:

This value indicates the NGAP cause group is "nas".

3:

This value indicates the NGAP cause group is "protocol".

4:

This value indicates the NGAP cause group is "misc".

5.3.74 NGAP-Value AVP

The NGAP-Value AVP (AVP code 577) is of type Unsigned32 and indicates the NG AP cause value in specific cause group identified by the NGAP-Group AVP, as specified in clause 9.4.5 of 3GPP TS 38.413 [71].

5.3.75 Wireline-User-Location-Info AVP

The Wireline-User-Location-Info AVP (AVP code 578) is of type Grouped and contains either wireline Cable or wireline BBF user location information.

The HFC-Node-Identifier AVP indicates wireline cable location and contains an HFC Node Identifer.

The GLI-Identifier AVP indicates wireline BBF location and contains a Global Line Identifier. The Line-Type AVP indicates the type of line included in the GLI-Identifier AVP.

AVP Format:

Wireline-User-Location-Info ::= < AVP Header: 578 >

[ HFC-Node-Identifier ]

[ GLI-Identifier ]

[ Line-Type ]

*[ AVP ]

5.3.76 HFC-Node-Identifier AVP

The HFC-Node-Identifier AVP (AVP code 579) is of type OctetString and contains an HFC Node Identifier as specified in CableLabs WR-TR-5WWC-ARCH [73].

5.3.77 GLI-Identifier AVP

The GLI-Identifier AVP (AVP code 580) is of type OctetString and contains a Global Line Identifier (see clause 28.16.3 of 3GPP TS 23.003 [38]) encoded as base64-encoded characters, representing the GLI value (up to 150 bytes) as specified in BBF WT-470 [74].

5.3.78 Line-Type AVP

The Line-Type AVP (AVP code 581) is of type Unsigned32 and it indicates the type of wireline (DSL or PON) for the wireline BBF access.

The following values are defined in this specification:

0 (DSL):

This value shall be used to indicate DSL line.

1 (PON):

This value shall be used to indicate PON line.

5.3.79 MPS-Action AVP

The MPS-Action AVP (AVP code 582) is of type Enumerated, and contains the indication whether to enable or disable MPS for DTS.

The following values are defined:

DISABLE_MPS_FOR_DTS (0)

Disable MPS for DTS.

ENABLE_MPS_FOR_DTS (1)

Enable MPS for DTS.

AUTHORIZE_AND_ENABLE_MPS_FOR_DTS (2)

The PCRF shall check the user’s MPS subscription and enable MPS for DTS.

5.4 Rx re-used AVPs

5.4.0 General

Table 5.4.0.1 lists the Diameter AVPs re-used by the Rx reference point from existing Diameter Applications, including a reference to their respective specifications and when needed, a short description of their usage within the Rx reference point. 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 Rx protocol. 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: Rx re-used Diameter AVPs

Attribute Name		Reference		Comments		Applicability (notes 1, 2)
3GPP-MS-TimeZone		3GPP TS 29.061 [34]		Indicates the offset between universal time and local time in steps of 15 minutes of where the MS currently resides. This AVP shall have the ‘M’ bit cleared.		NetLoc RAN-NAS-Cause
3GPP-SGSN-MCC-MNC		3GPP TS 29.061 [34]		Indicates the serving core network operator ID. For GPRS accesses the MCC and the MNC of the SGSN. For EPS 3GPP/non-3GPP accesses, the MCC and the MNC provided by the SGW, ePDG or TWAG. This AVP shall have the ‘M’ bit cleared.		NetLoc, RAN-NAS-Cause
3GPP-User-Location-Info		3GPP TS 29.061 [34]		Indicates details of where the UE is currently located (e.g. SAI or CGI), Coding shall be done as defined in 3GPP TS 29.274 [33]. The values "NCGI" and "5GS TAI and NCGI" (which are not applicable in some specification using this AVP) shall be applicable. This AVP shall have the ‘M’ bit cleared.		NetLoc RAN-NAS-Cause
AN-GW-Address		3GPP TS 29.212 [8]		Carries the IP address of the ePDG used as IPSec tunnel endpoint with the UE. This AVP shall have the ‘M’ bit cleared.
AN-Trusted		3GPP TS 29.273 [39]		Indicates whether the access network is trusted or untrusted for the Non-3GPP access network. This AVP shall have the ‘M’ bit cleared.
Called-Asserted-Identity		3GPP TS 32.299 [24]		The address (Public User ID: SIP URI, E.164, etc.) of the finally asserted called party.		VBCLTE
Called-Party-Address		3GPP TS 32.299 [24]		The address (SIP URI, Tel URI or URN) of the party to whom the call is addressed.		VBCLTE
Called-Station-Id		IETF RFC 4005 [12]		The PDN 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 [38], clause 9.1. The inclusion of the APN Operator Identifier can be configurable.		Rel8
Calling-Party-Address		3GPP TS 32.299 [24]		The address (SIP URI or Tel URI) which identifies the party (Public User Identity or Public Service Identity) initiating a SIP transaction. This information may be used by the PCRF, for example, to provide the caller information in the PCC rule decision for further volume based charging.		VBCLTE
DRMP		IETF RFC 7944 [43]		Allows Diameter endpoints to indicate the relative priority of Diameter transactions.
Final-Unit-Action		IETF RFC 8506 [75]		The action applied by the PCEF when the user’s account cannot cover the service cost.		Rel8
Framed-IP-Address		IETF RFC 4005 [12]		The valid routable Ipv4 address that is applicable for the IP Flows towards the UE at the PCEF. The PCRF shall use this address to identify the correct IP‑CAN session (session binding). For example, the IP address may actually be that of the network interface of a NAT device between the UE and the GW. The values 0xFFFFFFFF and 0xFFFFFFFE are not applicable as described in RFC 4005 [12].
Framed-Ipv6-Prefix		IETF RFC 4005 [12]		A valid full Ipv6 address that is applicable to an IP flow or IP flows towards the UE at the PCEF. The PCRF shall use this address to identify the correct IP-CAN session (session binding, refer to TS 29.213 [9]). For example, the IP address may actually be that of the network interface of a NAT device between the UE and the GW. The encoding of the value within this Octet String type AVP shall be as defined in RFC 3162 [20], clause 2.3. The "Reserved", "Prefix-Length" and "Prefix" fields shall be included in this order. The AF shall set the "Prefix Length" to 128 and encode the Ipv6 address of the UE within the "Prefix" field.
Granted-Service-Unit (NOTE 3)		IETF RFC 8506 [75]		The volume and/or time thresholds for sponsored data connectivity. Only CC-Total-Octets, one of the CC-Input-Octets and CC-Output-Octets, or CC-Time AVPs are reused. This AVP shall have the ‘M’ bit cleared.		SponsoredConnectivity, SCTimeBasedUM
IP-CAN-Type		3GPP TS 29.212 [8]		IP-CAN type of the user.
Load		IETF RFC 8583 [51]		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.
Max-PLR-DL		3GPP TS 29.212 [8]		indicates ratio of lost packets per number of packets sent in unit of tenth of percent for a downlink voice service data flow.		CHEM
Max-PLR-UL		3GPP TS 29.212 [8]		indicates ratio of lost packets per number of packets sent in unit of tenth of percent for an uplink voice service data flow.		CHEM
NetLoc-Access-Support		3GPP TS 29.212 [8]		Indicates the level of support for NetLoc procedures provided by the current access network.		NetLoc
OC-OLR		IETF RFC 7683 [35]		Contains the necessary information to convey an overload report.
OC-Supported-Features		IETF RFC 7683 [35]		Defines the support for the Diameter overload indication conveyence by the sending node.
Pre-emption-Capability		3GPP TS 29.212 [8]		Indicates whether a service data flow can get resources that were already assigned to another service data flow with a lower priority level.		MCPTT-Preemption
Pre-emption-Vulnerability		3GPP TS 29.212 [8]		Indicates whether a service data flow can lose the resources assigned to it in order to admit a service data flow with higher priority level.		MCPTT-Preemption
RAN-NAS-Release-Cause		3GPP TS 29.212 [8]		Indicates RAN and/or NAS release cause code information. TWAN release cause code information or untrusted WLAN release cause code information.		RAN-NAS-Cause
RAT-Type		3GPP TS 29.212 [8]		Indicate which Radio Access Technology is currently serving the UE.		Rel8
Requested-Party-Address		3GPP TS 32.299 [24]		The address (SIP URI, Tel URI or URN) of the party to whom the call was originaly addressed.		VBCLTE
Reference-Id		3GPP TS 29.154 [47]		Indicates the transfer policy stored in the SPR.
Reservation-Priority		3GPP TS 183.017 [15]		The vendor-id shall be set to ETSI (13019) [15]. 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.
Subscription-Id		IETF RFC 8506 [75]		The identification of the subscription (IMSI, MSISDN, etc.).
Supported-Features		3GPP TS 29.229 [25]		If present, this AVP informs the destination host about the features that the origin host requires to successfully complete this command exchange.		Rel8
TCP-Source-Port		3GPP TS 29.212 [8]		Contains the TCP source port number in the case that a NAT and firewall are detected and the IKEv2 messages exchanged between the UE and the ePDG are transported using the firewall traversal tunnel as described in 3GPP TS 24.302 [50].This AVP shall have the ‘M’ bit cleared.		NetLoc-Untrusted-WLAN
TWAN-Identifier		3GPP TS 29.061 [34]		Indicates the UE location in a Trusted WLAN or Untrusted WLAN Access Network. This AVP shall have the ‘M’ bit cleared.		Netloc-Trusted-WLAN RAN-NAS-Cause NetLoc- Untrusted-WLAN
ToS‑Traffic‑Class		3GPP TS 29.212 [8]		Indicates the DSCP code to be used for packet filter. The first octet contains the DSCP code and the second octet contains the mask field set to 11111100.		DSCP
UDP-Source-Port		3GPP TS 29.212 [8]		Contains the UDP source port number in the case that NAT is detected and the IKEv2 messages exchanged between the UE and the ePDG are encapsulated in the UDP messages according to IETF RFC 3948 [49]. This AVP shall have the ‘M’ bit cleared.		NetLoc-Untrusted-WLAN
UE-Local-IP-Address		3GPP TS 29.212 [8]		Indicates the local IP address of the UE. This AVP shall have the ‘M’ bit cleared.		NetLoc-Untrusted-WLAN
Used-Service-Unit (NOTE 3)		IETF RFC 8506 [75]		The measured volume and/or time for sponsored data connectivity. Only CC-Total-Octets, one of the CC-Input-Octets and CC-Output-Octets, or CC-Time AVPs are reused. This AVP shall have the ‘M’ bit cleared.		SponsoredConnectivity SCTimeBasedUM
User-Equipment-Info		IETF RFC 8506 [75]		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.
User-Equipment-Info-Extension		IETF RFC 8506 [75]		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.		User-Equipment-Info-Extension
User-Location-Info-Time		3GPP TS 29.212 [8]		Indicates the time the UE was last known to be in the location.		NetLoc RAN-NAS-Cause
NOTE 1: AVPs marked with "Rel8" are applicable as described in clause 5.4.1. NOTE 2: AVPs marked with "SponsoredConnectivity" are applicable for sponsored data connectivity. NOTE 3: Volume Usage monitoring control functionality is applicable for SponsoredConnectivity supported feature. Time Based Usage monitoring control is applicable for SCTimeBasedUM supported feature.

5.4.1 Use of the Supported-Features AVP on the Rx 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 of 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 Rx 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 [25].

The base functionality for the Rx 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 Rx commands. As defined in clause 7.1.1 of 3GPP TS 29.229 [25], 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 [25], the Supported-Features AVP is of type grouped and contains the Vendor-Id, Feature-List-ID and Feature-List AVPs. On the Rx 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 Rx 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 [25]. The following exceptions apply to the initial and stateless AAR/AAA command pair:

– If the AF supporting post-Rel-7 Rx functionality is able to interoperate with a PCRF supporting Rel-7, the AAR shall include the features supported by the AF within Supported-Features AVP(s) with the ‘M’ bit cleared. Otherwise, the AAR 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 AAR command does not contain any Supported-Features AVP(s) and the PCRF supports Rel-7 Rx functionality, the AAA command shall not include the Supported-Features AVP. In this case, both AF and PCRF shall behave as specified in the Rel-7 version of this document.

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

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

Once the PCRF and AF 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 table below defines the features applicable to the Rx interfaces for the feature list with a Feature-List-ID of 1.

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

Feature bit	Feature	M/O	Description
0	Rel8	M	This feature indicates the support of the base 3GPP Rel-8 functionality, including the AVPs and corresponding procedures supported by the base 3GPP Rel-7 Rx standard, but excluding those features represented by separate feature bits. AVPs introduced with this feature are marked with "Rel8" in Table 5.4.0.1.
1	Rel9	M	This feature indicates the support of the base 3GPP Rel-9 functionality, including the AVPs and corresponding procedures supported by the Rel8 feature bit, but excluding those features represented by separate feature bits.
2	ProvAFsignalFlow	O	This indicates support for the feature of provisioning of AF signalling flow information as described in clause 4.4.5A. If the PCRF supports this feature the AF may provision AF signalling flow information. NOTE: This feature is used by the IMS Restoration Procedures to provide to the PDN-Gateway the address of the P-CSCF selected by the UE, refer to TS 23.380 [28].
3	SponsoredConnectivity	O	This feature indicates support for sponsored data connectivity feature. If the PCRF supports this feature, the AF may provide sponsored data connectivity to the subscriber.
4	Rel10	M	This feature indicates the support of the base 3GPP Rel-10 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.
5	NetLoc	O	This feature indicates the support of the Access Network Information Reporting.
6	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.
7	SCTimeBasedUM	O	This feature indicates support for sponsored data connectivity feature with time-based usage monitoring control required. If the PCRF supports this feature, the AF may provide time threshold for the usage monitoring control.
8	Netloc-Trusted-WLAN	O	This feature indicates the support for the Trusted WLAN access. It requires that NetLoc feature is also supported.
9	RAN-NAS-Cause	O	This feature indicates the support for the release cause code information (NOTE 1) from the access network.
10	GroupComService	O	This feature indicates the support of Group Communication services as described in TS 23.468 [36] for unicast services.
11	ResShare	O	This feature indicates the support of resource sharing among several AF sessions.
12	DeferredService	O	This feature indicates the support of deferred transfer of service information from the AF.
13	DSCP	O	This feature indicates that the AF may provide a DSCP value when describing a service flow by supplying the ToS‑Traffic‑Class AVP.
14	SponsorChange	O	This feature indicates that the AF provides information on whether it wants to enable or disable/not enable sponsoring a service. It requires that SponsoredConnectivity is also supported.
15	E2EQOSMTSI	O	This feature indicates that the AF supports QoS End-to-end MTSI extensions as defined in 3GPP TS 26.114 [41]
16	NetLoc-Untrusted-WLAN	O	This feature indicates the support of the Untrusted WLAN access as described in 3GPP TS 23.203 [2]. It requires that NetLoc feature is also supported.
17	MCPTT	O	This feature indicates the support of Mission Critical Push To Talk services as described in 3GPP TS 23.179 [44]
18	PrioritySharing	O	This feature indicates that Priority Sharing is supported as described in 3GPP TS 23.203 [2], clause 6.1.19.
19	PLMNInfo	O	This feature indicates that reporting on changes of PLMN info is supported.
20	MediaComponentVersioning	O	This feature indicates the support of media component versioning as defined in clause 4.4.9.
21	MCPTT-Preemption	O	This feature indicates the support of service pre-emption based on the information provided by the AF. It requires that both PrioritySharing and MCPTT features are also supported.
22	MCVideo	O	This feature indicates the support of Mission Critical Video services as described in 3GPP TS 23.281 [61].
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"). Description: A clear textual description of the feature. NOTE 1: In this release, 5GS and EPS release cause code information is supported. The 3GPP-EPS and Non-3GPP EPS release cause code information from the access network is encoded in the RAN-NAS-Release-Cause AVP and can include RAN/NAS release cause(s), a TWAN release cause or an untrusted WLAN release cause. The 3GPP 5GS and Non-3GPP 5GS release cause code is encoded in the 5GS-RAN-NAS-Release-Cause AVP and is only applicable to Rx interworking with N7 as specified in Annex E.

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

Feature bit	Feature	M/O	Description
0	PCSCF-Restoration-Enhancement	O	This feature indicates support of P-CSCF Restoration Enhancement. It is used for the PCRF and the P-CSCF to indicate if they support P-CSCF Restoration Enhancement.
1	Extended-Max-Requested-BW-NR	O	This feature indicates the support of the extended Max-Requested-Bandwidth for NR.
2	Extended-Min-Requested-BW-NR	O	This feature indicates the support of the extended Min-Requested-Bandwidth for NR. It requires that Rel-10 feature is also supported.
3	Extended-BW-E2EQOSMTSI-NR	O	This feature indicates the support of the extended E2EQOSMTSI bandwidth values for NR. It requires that E2EQOSMTSI feature and the Extended-Max-Requested-BW-NR are also supported.
4	VBC	O	This feature indicates the support of Volume Based Charging of IMS services as defined in clause A.16.
5	CHEM	O	This feature indicates the support of Coverage and Handover Enhancements for Media (CHEM)
6	VBCLTE	O	This feature indicates the support of providing the caller and callee information as defined in clause A.16.
7	FLUS	O	This feature indicates the support of FLUS functionality as described in 3GPP TS 26.238 [69].
8	EPSFallbackReport	O	This feature indicates the support of the report of EPS Fallback as defined in clause E.3.
9	ATSSS	O	This feature indicates the support of the report of multiple IP-CAN types for a MA PDU session as defined in clause E.4.
10	QoSHint	O	This feature indicates the support of specific QoS hint parameters as described in 3GPP TS 26.114 [41], clause 6.2.10.
11	ReallocationOfCredit	O	This feature indicates the support of the report of reallocation of credit. It only applies to 5GS as defined in Annex E.
12	Netloc-Trusted-N3GA	O	This feature indicates the support for the Trusted N3GA access. It requires that NetLoc-Trusted-WLAN feature is also supported.
13	NetLoc-Wireline	O	This feature indicates the support for the Wireline access as specified in in 3GPP TS 23.316 [72]. It only applies to 5GS as defined in Annex E. It requires that NetLoc feature is also supported.
14	MPSforDTS	O	This feature indicates the support of MPS for DTS as defined in clauses 4.4.11. and 4.4.12
15	User-Equipment-Info-Extension	O	This feature indicates the support of the User-Equipment-Info-Extension AVP as defined in IETF RFC 8506 [75].
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"). Description: A clear textual description of the feature.

5.5 Rx specific Experimental-Result-Code AVP values

5.5.1 Permanent Failures

Errors that fall within the Permanent Failures category shall be used to inform the peer that the request failed, and should not be attempted again.

IETF RFC 6733 [52] specifies the Experimental-Result AVP containing Vendor-ID AVP and Experimental-Result-Code AVP. The Experimental-Result-Code AVP (AVP Code 298) is of type Unsigned32 and contains a vendor-assigned value representing the result of processing a request. The Vendor-ID AVP shall be set to 3GPP (10415).

Specific values of the Rx specific Experimental-Result-Code AVP are:

INVALID_SERVICE_INFORMATION (5061)

The PCRF rejects new or modified service information the service information provided by the AF is invalid or insufficient for the server to perform the requested action.

FILTER_RESTRICTIONS (5062)

The PCRF rejects new or modified service information because the Flow-Description AVP(s) cannot be handled by the server because restrictions defined in clause 5.3.8 are not observed.

REQUESTED_SERVICE_NOT_AUTHORIZED (5063)

The PCRF rejects new or modified service information because the requested service, as described by the service information provided by the AF, is not consistent with either the related subscription information, operator defined policy rules and/or the supported features in the IP-CAN network.

DUPLICATED_AF_SESSION (5064)

The PCRF rejects a new Rx session setup because the new Rx session relates to an AF session with another related active Rx session, e.g. if the AF provided the same AF charging identifier for this new Rx session that is already in use for the other ongoing Rx session.

IP-CAN_SESSION_NOT_AVAILABLE (5065)

The PCRF rejects a new Rx session setup when it fails to associate the described service IP flows within the session information received from the AF to an existing IP-CAN session.

UNAUTHORIZED_NON_EMERGENCY_SESSION (5066)

The PCRF rejects a new Rx session setup because the session binding function associated a non-Emergency IMS session to an IP-CAN session established to an Emergency APN.

UNAUTHORIZED_SPONSORED_DATA_CONNECTIVITY (5067)

The PCRF rejects a new Rx session setup because the PCRF can’t authorize the sponsored data connectivity based on the sponsored data connectivity profile or the operator policy (e.g. the sponsored data connectivity not authorized in the roaming case).

TEMPORARY_NETWORK_FAILURE (5068)

The PCRF rejects new or modified service information because there is a temporary failure in the access network (e.g. the SGW has failed).

UNAUTHORIZED_NON_RLOS_SESSION (5069)

The PCRF rejects a new Rx session setup because the session binding function associated a non-RLOS IMS session to an IP-CAN session established to an RLOS APN.

5.5.2 Transient Failures

Errors that fall within the transient failures category are used to inform a peer that the request could not be satisfied at the time it was received, but may be able to satisfy the request in the future.

The Result-Code AVP values defined in Diameter Base IETF RFC 6733 [52] are applicable. Also the following specific Rx Experimental-Result-Code value is defined for transient failures:

REQUESTED_SERVICE_TEMPORARILY_NOT_AUTHORIZED (4261)

The PCRF temporarily rejects new or modified service information because the network is temporarily not able to provide the service delivery that the AF requested, e.g. due to the service information is not consistent with the operator defined policy rules for the congestion status of the user.

5.6 Rx messages

5.6.0 General

Existing Diameter command codes from the Diameter base protocol IETF RFC 6733 [52] and the NASREQ Diameter application (RFC 4005 [12]) are used with the Rx specific AVPs. An Rx specific Auth‑Application id is used together with the command code to identify the Rx messages.

NOTE 1: The notion of NAS (Network Access Server) is not used here, NASREQ is just used for protocol purposes, not for its functional meaning.

NOTE 2: Some of the AVPs included in the messages formats below are in bold to highlight that these AVPs are used by this specific protocol and do not belong to the original Diameter Base Protocol IETF RFC 6733 [52].

NOTE3: Multiple instances of the Subscription-Id AVP in the AAR or RAR command correspond to multiple types of identifier for the same subscriber, for example IMSI and MSISDN.

5.6.1 AA-Request (AAR) command

The AAR command, indicated by the Command-Code field set to 265 and the ‘R’ bit set in the Command Flags field, is sent by an AF to the PCRF in order to provide it with the Session Information.

Message Format:

<AA-Request> ::= < Diameter Header: 265, REQ, PXY >

< Session-Id >

[ DRMP ]

{ Auth-Application-Id }

{ Origin-Host }

{ Origin-Realm }

{ Destination-Realm }

[ Destination-Host ]

[ IP-Domain-Id ]

[ Auth-Session-State ]

[ AF-Application-Identifier ]

*[ Media-Component-Description ]

[ Service-Info-Status ]

[ AF-Charging-Identifier ]

[ SIP-Forking-Indication ]

*[ Specific-Action ]

*[ Subscription-Id ]

[ OC-Supported-Features ]

*[ Supported-Features ]

[ Reservation-Priority ]

[ Framed-IP-Address ]

[ Framed-Ipv6-Prefix ]

[ Called-Station-Id ]

[ Service-URN ]

[ Sponsored-Connectivity-Data ]

[ MPS-Identifier ]

[ GCS-Identifier ]

[ MCPTT-Identifier ]

[ MCVideo-Identifier ]

[ IMS-Content-Identifier ]

[ IMS-Content-Type ]

*[ Calling-Party-Address ]

[ Callee-Information ]

[ Rx-Request-Type ]

*[ Required-Access-Info ]

[AF-Requested-Data ]

[ Reference-Id ]

[ Pre-emption-Control-Info ]

[ MPS-Action ]

[ Origin-State-Id ]

*[ Proxy-Info ]

*[ Route-Record ]

*[ AVP ]

5.6.2 AA-Answer (AAA) command

The AAA command, indicated by the Command-Code field set to 265 and the ‘R’ bit cleared in the Command Flags field, is sent by the PCRF to the AF in response to the AAR command.

Message Format:

<AA-Answer> ::= < Diameter Header: 265, PXY >

< Session-Id >

[ DRMP ]

{ Auth-Application-Id }

{ Origin-Host }

{ Origin-Realm }

[ Result-Code ]

[ Experimental-Result ]

[ Auth-Session-State ]

*[ Access-Network-Charging-Identifier ]

[ Access-Network-Charging-Address ]

[ Acceptable-Service-Info ]

0*2[ AN-GW-Address ]

[ AN-Trusted ]

[ Service-Authorization-Info ]

[ IP-CAN-Type ]

[ MA-Information ]

[ NetLoc-Access-Support ]

[ RAT-Type ]

*[ Flows ]

[ OC-Supported-Features ]

[ OC-OLR ]

*[ Supported-Features ]

*[ Subscription-Id ]

[ User-Equipment-Info ]

[ User-Equipment-Info-Extension ]

[ 3GPP-SGSN-MCC-MNC ]

[ NID ]

*[ Class ]

[ Error-Message ]

[ Error-Reporting-Host ]

[ Failed-AVP ]

[ Retry-Interval ]

[ Origin-State-Id ]

*[ Redirect-Host ]

[ Redirect-Host-Usage ]

[ Redirect-Max-Cache-Time ]

*[ Proxy-Info ]

*[ Load ]

*[ AVP ]

5.6.3 Re-Auth-Request (RAR) command

The 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 AF in order to indicate an Rx specific action.

Message Format:

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

< Session-Id >

[ DRMP ]

{ Origin-Host }

{ Origin-Realm }

{ Destination-Realm }

{ Destination-Host }

{ Auth-Application-Id }

*{ Specific-Action }

[ OC-Supported-Features ]

*[ Access-Network-Charging-Identifier ]

[ Access-Network-Charging-Address ]

0*2[ AN-GW-Address ]

[ AN-Trusted ]

*[ Flows ]

*[ Subscription-Id ]

[ Abort-Cause ]

[ IP-CAN-Type ]

[ MA-Information ]

[ NetLoc-Access-Support ]

[ RAT-Type ]

[ Sponsored-Connectivity-Data ]

[ 3GPP-User-Location-Info ]

[ User-Location-Info-Time ]

[ 3GPP-MS-TimeZone ]

*[ RAN-NAS-Release-Cause ]

*[ 5GS-RAN-NAS-Release-Cause ]

[ 3GPP-SGSN-MCC-MNC ]

[ NID ]

[ TWAN-Identifier ]

[ TCP-Source-Port ]

[ UDP-Source-Port ]

[ UE-Local-IP-Address ]

[ Wireline-User-Location-Info ]

[ Origin-State-Id ]

*[ Class ]

*[ Proxy-Info ]

*[ Route-Record ]

*[ AVP ]

5.6.4 Re-Auth-Answer (RAA) command

The 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 AF to the PCRF in response to the RAR command.

Message Format:

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

< Session-Id >

[ DRMP ]

{ Origin-Host }

{ Origin-Realm }

[ Result-Code ]

[ Experimental-Result ]

[ OC-Supported-Features ]

[ OC-OLR ]

*[ Media-Component-Description ]

[ Service-URN ]

[ Origin-State-Id ]

*[ Class ]

[ Error-Message ]

[ Error-Reporting-Host ]

*[ Redirect-Host ]

[ Redirect-Host-Usage ]

[ Redirect-Max-Cache-Time ]

[ Failed-AVP ]

*[ Proxy-Info ]

*[ AVP ]

5.6.5 Session-Termination-Request (STR) command

The STR command, indicated by the Command-Code field set to 275 and the ‘R’ bit set in the Command Flags field, is sent by the AF to inform the PCRF that an established session shall be terminated.

Message Format:

<ST-Request> ::= < Diameter Header: 275, REQ, PXY >

< Session-Id >

[ DRMP ]

{ Origin-Host }

{ Origin-Realm }

{ Destination-Realm }

{ Auth-Application-Id }

{ Termination-Cause }

[ Destination-Host ]

[ OC-Supported-Features ]

*[ Required-Access-Info ]

*[ Class ]

[ Origin-State-Id ]

*[ Proxy-Info ]

*[ Route-Record ]

*[ AVP ]

5.6.6 Session-Termination-Answer (STA) command

The STA command, indicated by the Command-Code field set to 275 and the ‘R’ bit cleared in the Command Flags field, is sent by the PCRF to the AF in response to the STR command.

Message Format:

<ST-Answer> ::= < Diameter Header: 275, PXY >

< Session-Id >

[ DRMP ]

{ Origin-Host }

{ Origin-Realm }

[ Result-Code ]

[ Error-Message ]

[ Error-Reporting-Host ]

[ OC-Supported-Features ]

[ OC-OLR ]

[ Failed-AVP ]

[ Sponsored-Connectivity-Data ]

[ Origin-State-Id ]

[ 3GPP-User-Location-Info ]

[ User-Location-Info-Time ]

[ 3GPP-MS-TimeZone ]

*[ RAN-NAS-Release-Cause ]

*[ 5GS-RAN-NAS-Release-Cause ]

[ 3GPP-SGSN-MCC-MNC ]

[ NID ]

[ TWAN-Identifier ]

[ TCP-Source-Port ]

[ UDP-Source-Port ]

[ UE-Local-IP-Address ]

[ Netloc-Access-Support ]

[ Wireline-User-Location-Info ]

*[ Class ]

*[ Redirect-Host ]

[ Redirect-Host-Usage ]

[ Redirect-Max-Cache-Time ]

*[ Proxy-Info ]

*[ Load ]

*[ AVP ]

5.6.7 Abort-Session-Request (ASR) command

The ASR command, indicated by the Command-Code field set to 274 and the ‘R’ bit set in the Command Flags field, is sent by the PCRF to inform the AF that bearer for the established session is no longer available.

Message Format:

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

< Session-Id >

[ DRMP ]

{ Origin-Host }

{ Origin-Realm }

{ Destination-Realm }

{ Destination-Host }

{ Auth-Application-Id }

[ OC-Supported-Features ]

{ Abort-Cause }

[ Origin-State-Id ]

*[ Proxy-Info ]

*[ Route-Record ]

*[ AVP ]

5.6.8 Abort-Session-Answer (ASA) command

The ASA command, indicated by the Command-Code field set to 274 and the ‘R’ bit cleared in the Command Flags field, is sent by the AF to the PCRF in response to the ASR command.

Message Format:

<AS-Answer> ::= < Diameter Header: 274, PXY >

< Session-Id >

[ DRMP ]

{ Origin-Host }

{ Origin-Realm }

[ Result-Code ]

[ OC-Supported-Features ]

[ OC-OLR ]

[ Origin-State-Id ]

[ Error-Message ]

[ Error-Reporting-Host ]

[ Failed-AVP ]

*[ Redirect-Host ]

[ Redirect-Host-Usage ]

[ Redirect-Max-Cache-Time ]

*[ Proxy-Info ]

*[ AVP ]

Annex A (normative):
IMS Related P-CSCF Procedures over Rx