Name

AVP Code

Data Type

Vendor

Abort-Cause

500

Enumerated

3GPP

Signaling to determine the cause of an abort session request (ASR) or a reauthorization request (RAR) indicating bearer release.

This AVP provides a reason for terminating an Application Function (AF) session or a bearer session, ensuring that network elements understand the cause of termination.

Enumerated Values:

0: BEARER_RELEASED: The bearer (PDP Context for GPRS) was deactivated due to normal signaling handling or failure in resource allocation for an AF session.

1: INSUFFICIENT_SERVER_RESOURCES: The session was aborted due to server overload, requiring immediate termination.

2: INSUFFICIENT_BEARER_RESOURCES: The bearer was deactivated due to insufficient resources at a transport gateway (e.g., GGSN for GPRS).

3: PS_TO_CS_HANDOVER: The AF session was terminated due to a packet-switched (PS) to circuit-switched (CS) handover.

4: SPONSORED_DATA_CONNECTIVITY_DISALLOWED: The session was terminated due to operator policy restricting sponsored data connectivity (e.g., in roaming scenarios).

Acceptable-Service-Info

526

Grouped

3GPP

Indicates the maximum acceptable bandwidth for an AF session or for specific media components as authorized by the PCRF (Policy and Charging Rules Function).

The AVP structure is defined as follows:

Media-Component-Description (517, Grouped): Defines acceptable bandwidth for individual media components within an AF session.

Max-Requested-Bandwidth-DL (515, Unsigned32): Specifies the maximum acceptable downlink bandwidth for the entire AF session (in bits per second).

Max-Requested-Bandwidth-UL (516, Unsigned32): Specifies the maximum acceptable uplink bandwidth for the entire AF session (in bits per second).

Extended-Max-Requested-BW-DL (554, Unsigned32): Extended downlink bandwidth limit, used for high-speed connections requiring bandwidth values above 4 Gbps.

Extended-Max-Requested-BW-UL (555, Unsigned32): Extended uplink bandwidth limit, used for high-speed connections requiring bandwidth values above 4 Gbps.

Behavior:

• If acceptable bandwidth applies to the entire AF session, only the Max-Requested-Bandwidth AVPs (DL/UL) and Extended-Max-Requested-BW AVPs will be included.

• If acceptable bandwidth applies to specific media components, only the Media-Component-Description AVP will be included.

Both cases are mutually exclusive.

Access-Network-Charging-Address

501

Address

3GPP

Used to specify the IP address of the network entity responsible for charging within the access network. This could be, for example, the GGSN (Gateway GPRS Support Node) IP address in a mobile network.

This AVP helps identify the charging entity for network usage accounting and billing purposes but should not be forwarded over an inter-operator interface to protect sensitive network information.

Access-Network-Charging-Identifier

502

Grouped

3GPP

The Access-Network-Charging-Identifier AVP is a Grouped AVP that contains the charging identifier associated with a specific network session or flow.

The AVP structure is defined as follows:

Access-Network-Charging-Identifier-Value (Mandatory): A unique charging identifier (e.g., GCID – GPRS Charging Identifier).

Flows (Optional, multiple allowed): Specifies the individual flows transported within the corresponding bearer. If omitted, the charging identifier applies to all flows within the AF session.

This AVP is primarily used for charging correlation between the AF (Application Function) and the PCRF (Policy and Charging Rules Function).

Access-Network-Charging-Identifier-Value

503

OctetString

3GPP

Contains a unique charging identifier for an AF session. This identifier is typically used for charging correlation between the Application Function (AF) and the Policy and Charging Rules Function (PCRF).

AF-Application-Identifier

504

OctetString

3GPP

Identifies the specific application service associated with an Application Function (AF) service session. 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.

AF-Charging-Identifier

505

OctetString

3GPP

Contains a charging identifier assigned by the Application Function (AF). This identifier is used to facilitate charging correlation between the application layer (AF session) and the bearer layer (PCEF/TDF level charging).

AF-Requested-Data

551

Bitmask (Unsigned32)

3GPP

Represents a bitmask indicating the type of information the Application Function (AF) requests from the Policy and Charging Rules Function (PCRF).

Each bit in the bitmask corresponds to a specific data request.

Bit 0 (Least Significant Bit) is defined as follows:

EPC-Level Identities Required (Bit 0 = 0x0001):

If set, the AF requests the PCRF to provide EPC-level identities associated with the IP-CAN session.

These identities include:

• MSISDN (Mobile Subscriber ISDN Number)

• IMSI (International Mobile Subscriber Identity)

• IMEI(SV) (International Mobile Equipment Identity with Software Version)

AF-Signalling-Protocol

529

Enumerated

3GPP

Specifies the signaling protocol used between the User Equipment (UE) and the Application Function (AF).

Enumerated Values:

0: NO_INFORMATION: No information about the AF signaling protocol is provided. This is the default value if the AVP is missing in the request.

1: SIP: The Session Initiation Protocol (SIP) is used as the signaling protocol between the UE and AF.

Application-Service-Provider-Identity

532

UTF8String

3GPP

Used to identify the Application Service Provider (ASP) in sponsored data connectivity scenarios.

Callee-Information

565

Grouped

3GPP

Provides information about the callee in an Application Function (AF) service session. Helps enable volume-based charging models that depend on the callee’s identity. 

The AVP structure is defined as follows:

Called-Party-Address: Contains the callee’s address, typically a phone number or SIP URI.

Requested-Party-Address: A list of parties the user intends to reach.

Called-Asserted-Identity: A list of network-asserted identities associated with the callee.

Codec-Data

524

OctetString

3GPP

Contains codec-related information that is known at the Application Function (AF).

It provides Session Description Protocol (SDP) information for media negotiation in an AF session.

The first line specifies the direction of the SDP source:

"uplink": SDP received from the UE and sent to the network.

"downlink": SDP received from the network and sent to the UE.

The second line specifies the type of SDP information:

"offer": SDP offer as per [RFC3264] (used for media session negotiation).

"answer": SDP answer as per [RFC3264].

"description": SDP session description when [RFC3264] offer-answer mechanism is not used (e.g., RTSP Describe replies).

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. 

For backwards compatibility, it is expected that the codec algorithms in the PCRF described in 3GPP [TS 29.213] 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.

Content-Version

552

Unsigned64

3GPP

Used to indicate the version of a specific content within a media session.

It is typically associated with the Media-Component-Description AVP and helps track content updates over time. The content version shall be unique for the content and for the lifetime of that content.

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.

Desired-Max-Latency

567

Float32

3GPP

Defines the maximum desirable end-to-end transport latency for packet transmission in milliseconds. It is used to ensure that real-time applications meet strict latency requirements. The value excludes any application level processing in the sender and receivers, such as e.g. application-level retransmission or encoding/decoding.

Desired-Max-Loss

568

Float32

3GPP

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

Extended-Max-Requested-BW-DL

554

Unsigned32

3GPP

Specifies the maximum requested downlink bandwidth for an IP flow in kilobits per second (kbps). 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.

Extended-Max-Requested-BW-UL

555

Unsigned32

3GPP

Defines the maximum requested uplink bandwidth for an IP flow, expressed in kilobits per second (kbps). 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.

Extended-Max-Supported-BW-DL

556

Unsigned32

3GPP

Specifies the maximum supported downlink bandwidth for an IP flow, expressed in kilobits per second (kbps) 3GPP [TS 26.114]. The bandwidth contains all the overhead coming from the IP-layer and the layers above, e.g. IP, UDP, RTP and RTP payload.

Extended-Max-Supported-BW-UL

557

Unsigned32

3GPP

Specifies the maximum supported uplink bandwidth for an IP flow, measured in kilobits per second (kbps) 3GPP [TS 26.114]. The bandwidth contains all the overhead coming from the IP-layer and the layers above, e.g. IP, UDP, RTP and RTP payload.

Extended-Min-Desired-BW-DL

558

Unsigned32

3GPP

Defines the minimum acceptable bandwidth for a downlink IP flow, measured in kilobits per second (kbps) 3GPP [TS 26.114]. The bandwidth contains all the overhead coming from the IP-layer and the layers above, e.g. IP, UDP, RTP and RTP payload.

Extended-Min-Desired-BW-UL

559

Unsigned32

3GPP

Specifies the minimum acceptable bandwidth for an uplink IP flow, measured in kilobits per second (kbps) 3GPP [TS 26.114]. The bandwidth contains all the overhead coming from the IP-layer and the layers above, e.g. IP, UDP, RTP and RTP payload.

Extended-Min-Requested-BW-DL

560

Unsigned32

3GPP

Specifies the minimum requested bandwidth for a downlink IP flow, measured in kilobits per second (kbps). 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.

Extended-Min-Requested-BW-UL

561

Unsigned32

3GPP

Specifies the minimum requested bandwidth for an uplink IP flow, measured in kilobits per second (kbps). 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.

5GMM-Cause

573

Unsigned32

3GPP

Conveys 5G Mobility Management (5GMM) cause codes, which indicate the reason for mobility-related signaling failures, session terminations, or registration events. This AVP aligns with clause 9.11.3.2 of 3GPP [TS 24.501], defining standardized cause values for 5GMM operations.

5GSM-Cause

574

Unsigned32

3GPP

Conveys 5G Session Management (5GSM) cause codes, which indicate session-related failures, rejection reasons, and resource allocation decisions in 5G Core (5GC) networks. This AVP is defined in clause 9.11.4.2 of 3GPP [TS 24.501], listing standardized failure reasons for PDU session establishment, modification, and release.

5GS-RAN-NAS-Release-Cause

572

Grouped

3GPP

Provides information about RAN and NAS release causes in both 3GPP and non-3GPP access types within a 5G System (5GS). It encapsulates multiple failure codes that explain why a UE session was released, rejected, or handed over between access types.

The AVP structure is defined as follows:

5GMM-Cause: NAS Layer release cause (e.g., network failure, UE authentication issues, operator policy restrictions)

5GSM-Cause: 5G Session Management release cause (e.g., QoS policy failure, network slice unavailability, session rejection)

NGAP-Cause: RAN-specific release cause (e.g., radio link failure, handover rejection, congestion).

Flow-Description

507

IPFilterRule

3GPP

Used to define an IP flow filter for Quality of Service (QoS) enforcement, policy control, and traffic shaping within the Rx interface in 3GPP networks. This AVP 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.

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.

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.

Flow-Number

509

Unsigned32

3GPP

Contains the ordinal number of the IP flow(s), assigned according to the rules in Annex B [TS 29.214].

Flows

510

Grouped

3GPP

Provides IP flow identifiers for policy enforcement, charging, and QoS control.

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.

The AVP structure is defined as follows:

Media-Component-Number (Unsigned32): Identifies the media component this flow belongs to.

Flow-Number (Unsigned32): Identifies individual IP flows within the media component.

Content-Version (Unsigned64): Identifies the version of the media content.

Final-Unit-Action (Enumerated): Defines the action applied to flows when credit is exhausted.

Media-Component-Status (Enumerated): Indicates the status of the media component (e.g., active, inactive).

Flow-Status

511

Enumerated

3GPP

Defines the operational status of an IP flow in the Rx interface between the AF (Application Function) and PCRF (Policy and Charging Rules Function). It determines whether a flow is enabled, disabled, or removed, affecting QoS, policy enforcement, and traffic management.

Enumerated Values:

0: ENABLED-UPLINK: Enables uplink IP flow(s) and disables downlink flow(s).

1: ENABLED-DOWNLINK: Enables downlink IP flow(s) and disables uplink flow(s).

2: ENABLED: Enables both uplink and downlink IP flows.

3: DISABLED: Disables both uplink and downlink IP flows.

4: REMOVED: Removes the associated IP flows from consideration in QoS authorization.

The interpretation of values for the RTCP flows in the Rx interface is described within the procedures in clause 4.4.3 [TS 29.214].

The interpretation of values for IMS flows when SIP Forking is supported is described within the procedures in Annex A.3.1 [TS 29.214].

Flow-Usage

512

Enumerated

3GPP

Provides classification information for IP flows in the Rx interface. Defines whether an IP flow is used for general traffic, RTCP (Real-time Transport Control Protocol), or AF (Application Function) signaling.

Enumerated Values:

0: NO_INFORMATION: No specific usage information is provided about the IP flow. (Default value)

1: RTCP: Indicates that the IP flow is used to transport RTCP (Real-time Transport Control Protocol).

2: AF_SIGNALLING: Indicates that the IP flow is used to transport Application Function signaling protocols (e.g., SIP/SDP).

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

FLUS-Identifier

566

OctetString

3GPP

Uniquely identifies media components used for FLUS (Fast Link-Uplink Sharing) media. It is derived from the "a=label:" attribute in SDP (Session Description Protocol) messages, as specified in [RFC4574]. It contains the string after "a=label:" starting with "flus" and may be followed by more characters as described in 3GPP [TS 26.238].

GCS-Identifier

538

OctetString

3GPP

Used in Diameter-based AF (Application Function) sessions to indicate that a session is part of a Group Communication Session (GCS) requiring prioritization. The values that identify the Group Communication session are not specified.

GLI-Identifier

580

OctetString

3GPP

Used to store and transmit a Global Line Identifier (GLI) clause 28.16.3 of 3GPP [TS 23.003], a standardized identifier used in fixed broadband networks for subscriber line identification. It is representing the GLI value (up to 150 bytes) as specified in BBF [RT-470].

HFC-Node-Identifier

579

OctetString

3GPP

Used to store and transmit an HFC (Hybrid Fiber-Coax) Node Identifier in cable broadband networks. Defined in CableLabs [WR-TR-5WWC-ARCH].

IMS-Content-Identifier

563

OctetString

3GPP

Used to store and transmit a unique identifier for an IMS (IP Multimedia Subsystem) communication service or session dialogue. This information may be used by the PCRF, for example, to differentiate Charging for different communication dialogs in the IMS session.

IMS-Content-Type

564

Enumerated

3GPP

Defines the type of IMS (IP Multimedia Subsystem) communication service associated with an AF (Application Function) session. Allows differentiation of IMS services such as customized alert tones and conference calls.

Enumerated Values:

0: NO_CONTENT_DETAIL: No information about the IMS communication service type is provided.

1: CAT: The IMS service is Customized Alerting Tones (CAT).

2: CONFERENCE: The IMS service is a Three-Party (3PTY) Conference Call.

IP-Domain-Id

537

OctetString

3GPP

Provides domain information to assist in session binding.

Line-Type

581

Enumerated

3GPP

Specifies the type of wireline broadband access used in a session. It helps identify whether the access is via DSL (Digital Subscriber Line) or PON (Passive Optical Network).

Enumerated Values:

0: DSL: Indicates Digital Subscriber Line (DSL) broadband access.

1: PON: Indicates Passive Optical Network (PON) broadband access.

MA-Information

570

Grouped

3GPP

Provides additional or released IP-CAN Type and RAT Type for a Multi-Access (MA) PDU Session. It is used in scenarios where a device transitions between different access networks (e.g., 5G to Wi-Fi, LTE to 5G, etc.).

The AVP structure is defined as follows:

IP-CAN-Type (Enumerated): Identifies the IP-CAN (IP Connectivity Access Network) type.

RAT-Type (Enumerated): Identifies the Radio Access Technology (RAT) used by the session.

MA-Information-Action (Enumerated): Specifies whether an IP-CAN or RAT change is added, removed, or replaced.

MA-Information-Action

571

Enumerated

3GPP

Specifies the action to be applied to the IP-CAN Type and RAT Type values included in the MA-Information AVP. It determines whether a new IP-CAN/RAT type is being added or released from a Multi-Access (MA) PDU session.

Enumerated Values:

0: ADD (Default): The IP-CAN Type and RAT Type included in the MA-Information AVP are now available for the MA PDU Session.

1: RELEASE: The IP-CAN Type and RAT Type included in the MA-Information AVP are released and are no longer available for the MA PDU Session.

Max-Requested-Bandwidth-DL

515

Unsigned32

10415

Specifies the maximum bandwidth (in bits per second) requested for a downlink (DL) IP flow. This value includes all protocol overhead from the IP layer and above (e.g., IP, UDP, RTP, and RTP payload).

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 [TS 29.214].

Max-Requested-Bandwidth-UL

516

Unsigned32

3GPP

Specifies the maximum bandwidth (in bits per second) requested for an uplink (UL) IP flow. This value includes all protocol overhead from the IP layer and 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 [TS 29.214].

Max-Supported-Bandwidth-DL

543

Unsigned32

3GPP

Defines the maximum bandwidth (in bits per second) supported for a downlink (DL) IP flow. This value includes all protocol overhead from the IP layer and 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 [TS 29.214].

Max-Supported-Bandwidth-UL

544

Unsigned32

3GPP

Defines the maximum supported bandwidth (in bits per second) for an uplink (UL) IP flow 3GPP [TS 26.114]. This value includes all protocol overhead from the IP layer and 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 [TS 29.214].

MCPTT-Identifier

547

OctetString

3GPP

The MCPTT-Identifier AVP (Mission-Critical Push-To-Talk Identifier) contains namespace values used for Mission-Critical Push-To-Talk (MCPTT) services, as defined in [RFC8101].

MCVideo-Identifier

562

OctetString

3GPP

Used to identify the MCVideo service provider. It serves as a textual or encoded identifier that allows network elements to associate a particular MCVideo session or service instance with a specific service provider.

Media-Component-Description

517

Grouped

3GPP

Used in the Policy and Charging Control (PCC) framework to define service information for a single media component within an Application Function (AF) session. It describes the QoS parameters, bandwidth requirements, and flow classifiers required for bearer authorization and PCC rule selection.

Each Media-Component-Description AVP represents a single media component, such as audio, video, or data, and contains bandwidth parameters, flow statuses, codec data, and pre-emption settings.

If a Media-Component-Description AVP is omitted in an AA-Request (AAR), the previously provided media component description remains valid.

If Flow-Status is set to REMOVED, all associated IP flows are disabled, and the PCRF removes the associated filters and state information.

The AVP structure is defined as follows:

Media-Component-Number (Mandatory): Specifies the ordinal number of the media component within the AF session.

Media-Sub-Component (Optional, Multiple): Defines a set of flows identified by a common Flow-Identifier.

AF-Application-Identifier (Optional): Identifies the AF application for policy decisions.

FLUS-Identifier (Optional): Indicates the FLUS feature for media classification.

Media-Type (Optional): Specifies whether the media component is Audio, Video, Data, Text, Control, or Message.

Max-Requested-Bandwidth-UL/DL (Optional): Defines the maximum bandwidth (in bits per second) required for uplink/downlink.

Min-Desired-Bandwidth-UL/DL (Optional): Specifies the minimum acceptable bandwidth.

Flow-Status (Optional): Defines whether the media component is ACTIVE or REMOVED.

Priority-Sharing-Indicator (Optional): Indicates whether multiple AF sessions can share the same priority.

Pre-emption-Capability (Optional): Defines whether the media component can preempt other lower-priority flows.

Pre-emption-Vulnerability (Optional): Defines whether the media component can be preempted by higher-priority flows.

Reservation-Priority (Optional): Determines the priority level of the media component during admission control.

RS-Bandwidth / RR-Bandwidth (Optional): Defines bandwidth for RTCP Sender and Receiver reports.

Codec-Data (Optional, Up to 2): Contains SDP-derived codec parameters for media sessions.

Sharing-Key-DL/UL (Optional): Identifies media components that can share resources in a given direction.

Content-Version (Optional): Specifies the content version of the media component.

Max-PLR-DL/UL (Optional): Indicates the Maximum Packet Loss Rate in Downlink/Uplink.

Desired-Max-Latency (Optional): Specifies the acceptable latency in milliseconds.

Desired-Max-Loss (Optional): Specifies the acceptable packet loss rate.

Behavior:

AF Sends AA-Request (AAR): The AF provides media component details via Media-Component-Description AVP. The PCRF evaluates QoS policies based on the provided parameters.

PCRF Processes the AVP: Determines authorized QoS and bearer classification. Assigns bandwidth limits, flow statuses, and priority levels.

AA-Answer (AAA) Response: PCRF returns the accepted or modified media component information. May reject unsupported QoS values and suggest alternatives.

Media-Component-Number

518

Unsigned32

3GPP

Used in the Rx interface to uniquely identify a media component in a multimedia session. It provides an ordinal number assigned to each media component according to the rules specified in Annex B of 3GPP [TS 29.214].

When this AVP refers to AF signalling, this is indicated by using the value 0.

Media-Component-Status

549

Enumerated

3GPP

Used in the Rx interface to indicate the status of PCC (Policy and Charging Control) rules or QoS (Quality of Service) rules associated with a specific media component in a multimedia session.

If this AVP is not supplied, the default value is INACTIVE (1).

If INDICATION_OF_FAILED_RESOURCES_ALLOCATION (9) is received in the Specific-Action AVP, all media components without this AVP should be considered INACTIVE.

Enumerated Values

0: ACTIVE: The PCC/QoS rule(s) related to this media component are active.

1: INACTIVE: The PCC/QoS rule(s) related to this media component are inactive (default value).

Media-Sub-Component

519

Grouped

3GPP

Represents a subset of IP flows within a Media-Component-Description AVP. It is used to manage QoS parameters, requested bandwidth, and flow descriptions for these flows. Each Media-Sub-Component AVP contains one or more Flow Descriptions, which define IP packet filters based on source/destination IP, port, and protocol.

Priority Handling:

Bandwidth and Flow-Status AVPs in Media-Sub-Component take precedence over those in Media-Component-Description.

If Flow-Description AVPs are included, they replace all previous definitions.

If the Flow-Status AVP is set to REMOVED, all associated flows are permanently disabled.

Session Persistence:

If a Media-Sub-Component AVP is omitted from a request, previously provided values remain valid unless new information is supplied in Media-Component-Description AVP.

The AF-Signalling-Protocol AVP can only be included if Flow-Usage AVP is set to AF_SIGNALLING.

The AVP structure is defined as follows:

Flow-Number (Mandatory): Specifies the ordinal number of the flow in the session.

Flow-Description (Optional, Up to 2): Defines IP packet filters (e.g., source/destination IP, port).

Flow-Status (Optional): Indicates whether the flow is ACTIVE or REMOVED.

Flow-Usage (Optional): Specifies flow usage type (e.g., AF Signalling, Default Bearer, Dedicated Bearer).

Max-Requested-Bandwidth-UL/DL (Optional): Defines the maximum requested uplink/downlink bandwidth in bits per second.

Extended-Max-Requested-BW-UL/DL (Optional): Used when the requested bandwidth exceeds 2^32-1 bps.

AF-Signalling-Protocol (Optional): Specifies the signaling protocol for AF communication.

ToS-Traffic-Class (Optional): Defines Type of Service (ToS) for IPv4 and Traffic Class for IPv6.

Behavior:

AF Sends AA-Request (AAR): The AF provides IP flow details via Media-Sub-Component AVP. Each Flow-Description AVP defines a packet filter. The PCRF processes these flows to enforce policies.

PCRF Evaluates the Request: Determines QoS policies, bandwidth allocation, and flow status. Matches packet filters against existing PCC rules.

AA-Answer (AAA) Response: PCRF approves, modifies, or rejects flow settings.

The AF is informed about allowed QoS parameters.

Media-Type

520

Enumerated

3GPP

Defines the type of media associated with a session component. The values in this AVP align with Session Description Protocol (SDP) media types, as defined in [RFC4566]. It helps identify the nature of the media being exchanged in a session.

Enumerated Values

0: AUDIO: The session component represents an audio stream.

1: VIDEO: The session component represents a video stream.

2: DATA: The session component represents generic data transfer.

3: APPLICATION: The session component represents an application-specific data stream.

4: CONTROL: The session component is used for control signaling.

5: TEXT: The session component represents text-based communication.

6: MESSAGE: The session component is for message-oriented communication (e.g., instant messaging).

0xFFFFFFFF: OTHER: The session component represents an unknown or unspecified media type.

Min-Desired-Bandwidth-DL

545

Unsigned32

3GPP

Specifies the minimum desired downlink bandwidth (in bits per second) for an IP flow. It ensures that the required QoS is met for downlink traffic, taking into account IP-layer and higher-layer overhead, including 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 [TS 29.214].

Min-Desired-Bandwidth-UL

546

Unsigned32

3GPP

Defines the minimum desired uplink bandwidth (in bits per second) for an IP flow. It ensures that the required QoS is maintained for uplink traffic, including all overhead from IP-layer and higher layers (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 [TS 29.214].

Min-Requested-Bandwidth-DL

534

Unsigned32

3GPP

Defines the minimum requested downlink bandwidth (in bits per second) for an IP flow. It ensures that the required QoS is maintained for downlink traffic, considering all protocol overhead from IP-layer and 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 [TS 29.214].

Min-Requested-Bandwidth-UL

535

Unsigned32

3GPP

Specifies the minimum requested uplink bandwidth (in bits per second) for an IP flow. It ensures that the necessary QoS is maintained for uplink traffic, considering all protocol overhead from IP-layer and 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 [TS 29.214].

MPS-Action

582

Enumerated

3GPP

Specifies whether Mission-Critical Push-to-Talk (MPS) is enabled or disabled for Dedicated Traffic Sessions (DTS) and Application Function (AF) signaling. This AVP is used in Policy and Charging Rules Function (PCRF) to manage priority service activation for users based on their subscription and network conditions.

Enumerated Values:

0: DISABLE_MPS_FOR_DTS: Disables Mission-Critical Push-to-Talk (MPS) for Dedicated Traffic Sessions (DTS).

1: ENABLE_MPS_FOR_DTS: Enables MPS for DTS, ensuring priority traffic handling for mission-critical users.

2: AUTHORIZE_AND_ENABLE_MPS_FOR_DTS: The PCRF checks the user's MPS subscription and, if allowed, enables MPS for DTS.

3: AUTHORIZE_AND_ENABLE_MPS_FOR_AF_SIGNALLING: The PCRF checks the user's MPS subscription and, if authorized, enables MPS for AF signaling.

MPS-Identifier

528

OctetString

3GPP

Used to associate an Application Function (AF) session with a Mission-Critical Push-to-Talk (MPS) session. It contains a national variant of the MPS service name, such as NGN GETS (Next-Generation Network Government Emergency Telecommunications Service), allowing the Policy and Charging Rules Function (PCRF) to recognize and prioritize mission-critical traffic.

NGAP-Cause

575

Grouped

3GPP

The NGAP-Cause AVP represents an NG Application Protocol (NGAP) cause value, as specified in 3GPP [TS 38.413].

The AVP structure is defined as follows:

NGAP-Group: Indicates the category of the cause (e.g., transport failure, radio network issues, etc.).

NGAP-Value: Specifies the detailed reason within the selected group.

This AVP is essential in 5G Core (5GC) signaling, where NGAP handles communication between gNB (5G base stations) and AMF (Access and Mobility Management Function).

NGAP-Group

576

Unsigned32

3GPP

Defines the category of an NG Application Protocol (NGAP) cause, mapping to specific cause groups as outlined in 3GPP [TS 38.413]. It is an Unsigned32 AVP that categorizes NGAP failures into predefined groups, assisting in efficient error handling and network troubleshooting.

NGAP Cause Group Description:

0: radioNetwork: Issues related to radio conditions, handovers, and RAN failures.

1: transport: Errors related to NG-U and NG-C transport failures, connectivity problems.

2: nas: Failures originating from NAS signaling between UE and AMF.

3: protocol: Issues due to NGAP protocol errors, message formatting, and ASN.1 violations.

4: misc: Other miscellaneous failures not covered by the above categories.

NGAP-Value

577

Unsigned32

3GPP

Represents the specific cause value within a predefined NGAP cause group (as defined in the NGAP-Group AVP). It provides a more granular categorization of NGAP failures, aligning with the cause codes specified in clause 9.4.5 of 3GPP [TS 38.413].

NID

569

OctetString

3GPP

Used in 5G System (5GS) to uniquely identify a Standalone Non-Public Network (SNPN). It consists of a 44-bit identifier represented as 11 hexadecimal digits, as specified in 3GPP [TS 23.003], clause 12.7.

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

Pre-Emption-Control-Info

553

Unsigned32 (Bitmask)

3GPP

Used in Policy and Charging Control (PCC) to specify how the PCRF (Policy and Charging Rules Function) should handle pre-emption among multiple media flow candidates with the same priority. It provides a bitmask value, where only one bit may be set at a time, defining which media flow should be pre-empted first.

This AVP is typically used in Authorization and Authentication Requests (AAR) messages and applies to all potential media flows in the session.

Bitmask Values:

Each bit position in the bitmask represents a different pre-emption policy:

0: Most recent added flow: The newest media flow in the session should be pre-empted first.

1: Least recent added flow: The oldest media flow in the session should be pre-empted first.

2: Highest bandwidth flow: The media flow with the highest bandwidth should be pre-empted first.

Only one bit may be set at a time. If multiple pre-emption rules apply, the most recent provided value is used.

Priority-Sharing-Indicator

550

Enumerated

3GPP

Used to specify whether a media component is allowed to share the Allocation and Retention Priority (ARP) with other media components in different Application Function (AF) sessions but within the same IP-CAN session. The ability to share priority settings is essential in QoS management to ensure efficient resource allocation across multiple AF sessions. 

Enumerated Values

0: PRIORITY_SHARING_ENABLED: The media component is allowed to share the Allocation and Retention Priority (ARP) with other media components that also have this AVP set to PRIORITY_SHARING_ENABLED.

1: PRIORITY_SHARING_DISABLED: The media component is NOT allowed to share its ARP with other media components in other AF sessions. This is the default value if this AVP is not included.

Default Behavior: If this AVP is not provided, it is assumed that priority sharing is disabled (PRIORITY_SHARING_DISABLED).

Required-Access-Info

536

Enumerated

3GPP

Specifies the type of access network information required for a given Application Function (AF) session. The Policy and Charging Rules Function (PCRF) uses this AVP to determine what kind of user access information needs to be reported in Diameter messages.

Enumerated Values

0: USER_LOCATION: Requests user location information, including 3GPP-User-Location-Info, Serving Network Identifier (PLMN ID), NID (for 5GS and SNPNs), TWAN-Identifier, UE-Local-IP-Address, UDP/TCP Source Ports, and User-Location-Info-Time AVP.

1: MS_TIME_ZONE: Requests user timezone information, which shall be reported using the 3GPP-MS-TimeZone AVP.

Default Behavior: If this AVP is not provided, the system assumes no specific access information is required.

If both values are required, the PCRF must send multiple instances of the AVP.

Retry-Interval

541

Unsigned32

3GPP

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

RR-Bandwidth

521

Unsigned32

3GPP

Specifies the maximum required bandwidth (in bits per second) for Receiver Report (RR) packets in Real-time Transport Control Protocol (RTCP) sessions. This AVP is used to manage bandwidth allocation for RTCP receiver reports within a media session, ensuring efficient resource usage as defined in [RFC3556]. The bandwidth contains all the overhead coming from the IP-layer and the layers above, i.e. IP, UDP and RTCP.

RS-Bandwidth

522

Unsigned32

3GPP

Defines the maximum required bandwidth (in bits per second) for Sender Report (SR) packets in Real-time Transport Control Protocol (RTCP) sessions. This AVP ensures efficient allocation of bandwidth for RTCP Sender Reports, which provide QoS statistics and network feedback, as specified in [RFC3556]. The bandwidth contains all the overhead coming from the IP-layer and the layers above, i.e. IP, UDP and RTCP.

Rx-Request-Type

533

Enumerated

3GPP

Specifies the reason for sending an AA-Request (AAR) message within the Rx interface. This AVP ensures that the PCRF (Policy and Charging Rules Function) correctly processes session initiation, updates, and restorations.

Enumerated Values:

0: INITIAL_REQUEST: Indicates that this is the first request to initiate an Rx session. The request contains all relevant information required for session establishment.

1: UPDATE_REQUEST: Used to update an existing Rx session. This may be triggered when there are changes in media parameters, QoS needs, or policy rules.

2: PCSCF_RESTORATION: Used when a Proxy Call Session Control Function (P-CSCF) restoration is needed. This is specific to the P-CSCF-Restoration-Enhancement feature defined in 3GPP [TS 29.214], clause 5.4.1.

Service-Authorization-Info

548

Bitmask (Unsigned32)

3GPP

Used to indicate the result of the authorization for a service request from the Application Function (AF). It is encoded as a bitmask, where each bit provides information regarding the transfer policy of the service request.

Bitmask Values:

0: The transfer policy is known/unknown: When set (1), it indicates that the transfer policy is unknown. When unset (0), it indicates that the transfer policy is known.

1: The transfer policy has expired/has not expired: When set (1), it indicates that the transfer policy has expired. When unset (0), it means the policy is still valid.

2: The time window of the transfer policy has occurred/has not yet occurred: When set (1), it indicates that the time window for the transfer policy has not yet occurred. When unset (0), it means the time window is active.

Service-Info-Status

527

Enumerated

3GPP

Used to indicate the status of the service information that the Application Function (AF) provides to the PCRF (Policy and Charging Rules Function). It defines whether the service information is final or preliminary.

Enumerated Values:

0: FINAL SERVICE INFORMATION: This value indicates that the service has been fully negotiated between the two ends, and the provided service information is final. No further modifications are expected.

1: PRELIMINARY SERVICE INFORMATION: This value indicates that the provided service information is not final and may still need further negotiation between the two ends (e.g., IMS SDP Offer/Answer Model).

Service-URN

525

OctetString

3GPP

Used to indicate that an Application Function (AF) session is utilized for emergency services or Resilient Location and Object Services (RLOS) traffic. It contains values of the service URN and it may include subservices, as defined in [RFC5031] 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".

Sharing-Key-DL

539

Unsigned32

3GPP

Used to indicate resource-sharing policies for media components in the downlink (DL) 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.

Sharing-Key-UL

540

Unsigned32

3GPP

Used to determine resource-sharing policies for media components in the uplink (UL) 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.

SIP-Forking-Indication

523

Enumerated

3GPP

Used to indicate whether multiple SIP dialogues are associated with a single Diameter session. It helps in managing SIP forking scenarios, where a single SIP INVITE may lead to multiple parallel call legs.

Enumerated Values

0: SINGLE_DIALOGUE: Indicates that the Diameter session is associated with a single SIP dialogue. This is the default value when the AVP is omitted.

1: SEVERAL_DIALOGUES: Indicates that the Diameter session is associated with multiple SIP dialogues. Used in cases where SIP forking occurs, leading to multiple call legs.

Specific-Action

513

Enumerated

3GPP

Defines various actions and notifications that can be triggered in response to network events, particularly in PCRF-initiated Re-Authorization Requests (RAR) and initial AA-Requests (AAR) from the Application Function (AF).

Within an AAR:

• The AF requests notifications for certain bearer events (e.g., loss of bearer, QoS updates).

• If omitted, no notifications are requested.

• One-time-specific-action values may be included in subsequent AARs, while non-one-time actions apply for the session lifetime.

Within an RAR:

• The PCRF reports bearer-related events (e.g., resource allocation success/failure, credit exhaustion).

• The PCRF decides whether to send INDICATION_OF_RELEASE_OF_BEARER or INDICATION_OF_FAILED_RESOURCES_ALLOCATION when a bearer fails.

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.

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

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.

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.

Enumerated Values

0: Void: Reserved for future use.

1: CHARGING_CORRELATION_EXCHANGE: Informs the AF of charging identifiers used in the network.

2: INDICATION_OF_LOSS_OF_BEARER: Reports bearer loss to the AF (e.g., due to PDP context modification to 0 Kbps for GBR bearers).

3: INDICATION_OF_RECOVERY_OF_BEARER: Reports bearer recovery to the AF when a GBR bearer regains bandwidth.

4: INDICATION_OF_RELEASE_OF_BEARER: Reports bearer removal to the AF (e.g., PDP context removal).

5: Void: Reserved for future use.

6: IP-CAN_CHANGE: Indicates an IP-CAN or RAT type change (e.g., UE switches from LTE to Wi-Fi).

7: INDICATION_OF_OUT_OF_CREDIT: Reports to the AF that credit for a flow has run out, triggering a Final-Unit-Action.

8: INDICATION_OF_SUCCESSFUL_RESOURCES_ALLOCATION: Notifies that requested resources were successfully allocated.

9: INDICATION_OF_FAILED_RESOURCES_ALLOCATION: Notifies that requested resources could not be allocated.

10: INDICATION_OF_LIMITED_PCC_DEPLOYMENT: Informs the AF that dynamic PCC policies are not applicable.

11: USAGE_REPORT : Reports accumulated usage volume or time when a threshold is reached.

12: ACCESS_NETWORK_INFO_REPORT: Reports user location or timezone when received from the PCEF.

13: INDICATION_OF_RECOVERY_FROM_LIMITED_PCC_DEPLOYMENT: Reports that limited PCC deployment conditions no longer apply.

14: INDICATION_OF_ACCESS_NETWORK_INFO_REPORTING_FAILURE: Reports failure to obtain access network info.

15: INDICATION_OF_TRANSFER_POLICY_EXPIRED: Reports that the transfer policy has expired.

16: PLMN_CHANGE: Reports Public Land Mobile Network (PLMN) change.

17: EPS_FALLBACK: Reports EPS fallback for voice media sessions.

18: INDICATION_OF_REALLOCATION_OF_CREDIT: Reports that credit has been restored after a previous out-of-credit event.

19: SUCCESSFUL_QOS_UPDATE: Reports that the default bearer QoS was successfully updated.

20: FAILED_QOS_UPDATE: Reports that the default bearer QoS update failed.

Sponsored-Connectivity-Data

530

Grouped

3GPP

Contains sponsored data connectivity details. It is primarily used in policy control and charging (PCC) frameworks, enabling Application Functions (AFs) and Policy and Charging Rules Functions (PCRFs) to manage sponsored data sessions.

Sponsored connectivity allows third-party sponsors (e.g., app providers) to pay for a user's data consumption instead of the user. This is commonly used for zero-rating applications, sponsored video streaming, or promotional data access.

• AF Includes this AVP in AA-Requests (AARs): When requesting a sponsored session, the AF identifies the sponsor and provides usage thresholds. The PCRF enforces the policy and monitors usage.

• PCRF Includes this AVP in AA-Answers (AAAs): When confirming a sponsored session, the PCRF reports used service units to the AF.

The AVP structure is defined as follows:

Sponsor-Identity (UTF8String): Identifies the sponsor of the data session (e.g., a mobile service provider or a company). It shall be included by the AF in the Sponsored-Connectivity-Data AVP except for the case of disabling sponsored data connectivity.

Application-Service-Provider-Identity (UTF8String): Identifies the application service provider using sponsored connectivity. It shall be included by the AF in the Sponsored-Connectivity-Data AVP except for the case of disabling sponsored data connectivity.

Granted-Service-Unit (Grouped): Defines the usage threshold (volume/time) that is granted for the sponsored session.

Used-Service-Unit (Grouped): Defines the actual data usage reported by the PCRF 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 (Enumerated): Specifies whether the sponsorship should be enabled or disabled (0 = DISABLE, 1 = ENABLE).

Sponsor-Identity

531

UTF8String

3GPP

Used in sponsored data connectivity scenarios to identify the sponsor of a data session.

Sponsoring-Action

542

Enumerated

3GPP

Used in sponsored data connectivity scenarios to indicate whether sponsored data connectivity should be enabled or disabled for a user session. This AVP is typically included within the Sponsored-Connectivity-Data AVP and instructs the PCRF (Policy and Charging Rules Function) whether a sponsorship request is active or should be deactivated.

Enumerated Values

0: DISABLE_SPONSORING: Disables or does not enable sponsored data connectivity.

1: ENABLE_SPONSORING: Enables sponsored data connectivity.

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.

Wireline-User-Location-Info

578

Grouped

3GPP

Used to provide location information for wireline users, including both cable-based and broadband-based (BBF) connections. This AVP is a Grouped AVP, meaning it contains multiple sub-AVPs to specify different types of wireline location identifiers. 

The AVP structure is defined as follows:

HFC-Node-Identifier: Indicates wireline cable location and contains an HFC Node Identifier (Hybrid Fiber-Coaxial).

GLI-Identifier: Indicates broadband-based wireline BBF location, containing a Global Line Identifier.

Line-Type: Specifies the type of wireline connection used in the GLI-Identifier AVP.