3GPP TSG-CT WG3 Meeting #109e C3-202252

E-Meeting, 16th – 24th April 2020 (revision of C3-

202xyz)
CR-Form-v12.0

CHANGE REQUEST
29.214 CR 1640 rev - Current version: 16.2.0
For HELP on using this form: comprehensive instructions can be found at
http://www.3gpp.org/Change-Requests.

Proposed change affects: UICC apps ME Radio Access Network Core Network X

Title: Access Type Report for a MA PDU session

Source to WG: Ericsson
Source to TSG: C3
Work item code: ATSSS Date: 2020-04-14
Category: B Release: Rel-16
Use one of the following categories: Use one of the following releases:
F (correction) Rel-8 (Release 8)
A (mirror corresponding to a change in an earlier Rel-9 (Release 9)
release) Rel-10 (Release 10)
B (addition of feature), Rel-11 (Release 11)
C (functional modification of feature) Rel-12 (Release 12)
D (editorial modification) Rel-13 (Release 13)
Detailed explanations of the above categories can Rel-14 (Release 14)
be found in 3GPP TR 21.900. Rel-15 (Release 15)
Rel-16 (Release 16)

Reason for change: TS 23.503, clause 6.1.3.18 specifies that the Access Type event, for MA PDU
Session, may include information about the two Access Types the user is
currently using.
Summary of change: Definition of a new grouped AVP, MA-Information AVP that includes information
about an additional/released IP-CAN type and RAT type (if available). The MA-
Information AVP also includes the new AVP MA-Information-Action, which
indicates whether the included access information should be added or released in
relation to previously reported access information.
The applicability of these AVPs is ruled by the ATSSS feature.
Consequences if not Misalignment with SA2 requirements.
approved:
Clauses affected: 3.2, 5.3.0, 5.3.13, 5.3.x1, 5.3.x2, 5.4.1, 5.6.2, 5.6.3, E.x1
Y N
Other specs X Other core specifications TS/TR ... CR ...
affected: X Test specifications TS/TR ... CR ...
(show related CRs) X O&M Specifications TS/TR ... CR ...

Other comments:

This CR's revision history:

Additional discussion(if needed):

Proposed changes:

*** 1st Change ***

3.2 Abbreviations
For the purpose of the present document, the abbreviations given in 3GPP TR 21.905 [1] and the following apply:

5GS 5G System
ADC Application Detection and Control
AF Application Function
AS Application Server
ASP Application Service Provider
ATSSS Access Traffic Steering, Switching and Splitting
AVP Attribute Value Pair
CHEM Coverage and Handoff Enhancements using Multimedia error robustness feature
CRF Charging Rules Function
DRMP Diameter Routing Message Priority
DSCP Differentiated Services Code Point
FLUS Framework for Live Uplink Streaming
GCS Group Communication Service
GCS AS Group Communication Service Application Server
IP-CAN IP Connectivity Access Network
MPS Multimedia Priority Service
MA Multi-Access
PCC Policy and Charging Control
PCEF Policy and Charging Enforcement Function
PCF Policy Control Function
PCRF Policy and Charging Rule Function
PDF Policy Decision Function
P-CSCF Proxy-Call Session Control Function
PSAP Public Safety Answering Point
RCAF RAN Congestion Awareness Function
RLOS Restricted Local Operator Services
QoS Quality of Service
SCEF Service Capability Exposure Function
SCS Service Capability Server
SDF Service Data Flow
SMF Session Management Function
SPR Subscriber Profile Repository
TDF Traffic Detection Function
UDC User Data Convergence
UE User Equipment
UDR User Data Repository
XML Extensible Markup Language

*** 2nd Change ***

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 Clause Value Type Mus Ma Shoul Mus May Applicability
Code define (Note 2) t y d not t not Encr (Note 3)
d .
Abort-Cause 500 5.3.1 Enumerate M,V P Y
d
Access-Network-Charging- 501 5.3.2 Address M,V P Y
Address
Access-Network-Charging- 502 5.3.3 Grouped M,V P Y
Identifier
Access-Network-Charging- 503 5.3.4 OctetString M,V P Y
Identifier-Value
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 Enumerate V P M Y ProvAFsignalFlow
d
Application-Service- 532 5.3.29 UTF8String V P M Y SponsoredConnectivity
Provider-Identity
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 MediaComponentVersionin
g
Desired-Max-Latency 567 5.3.64 Float32 V P M Y FLUS
Desired-Max-Loss 568 5.3.65 Float32 V P M Y FLUS
Extended-Max-Requested- 554 5.3.52 Unsigned32 V P M Y Extended-Max-Requested-
BW-DL BW-NR
Extended-Max-Requested- 555 5.3.53 Unsigned32 V P M Y Extended-Max-Requested-
BW-UL BW-NR
Extended-Max-Supported- 556 5.3.54 Unsigned32 V P M Y Extended-BW-
BW-DL E2EQOSMTSI-NR
Extended-Max-Supported- 557 5.3.55 Unsigned32 V P M Y Extended-BW-
BW-UL E2EQOSMTSI-NR
Extended-Min-Desired-BW- 558 5.3.56 Unsigned32 V P M Y Extended-BW-
DL E2EQOSMTSI-NR
Extended-Min-Desired-BW- 559 5.3.57 Unsigned32 V P M Y Extended-BW-
UL E2EQOSMTSI-NR
Extended-Min-Requested- 560 5.3.58 Unsigned32 V P M Y Extended-Min-Requested-
BW-DL BW-NR
Extended-Min-Requested- 561 5.3.59 Unsigned32 V P M Y Extended-Min-Requested-
BW-UL 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 Enumerate M,V P Y
d
Flow-Usage 512 5.3.12 Enumerate M,V P Y
d
FLUS-Identifier 566 5.3.63 OctetString V P M Y FLUS
GCS-Identifier 538 5.3.36 OctetString V P M Y GroupComService
IMS-Content-Identifier 563 5.3.60 OctetString V P Y VBC
IMS-Content-Type 564 5.3.61 Enumerate V P Y VBC
d
IP-Domain-Id 537 5.3.35 OctetString V P M Y
MA-Information 569 5.3.x1 Grouped V P M Y ATSSS
MA-Information-Action 570 5.3.x2 Unsigned32 V P M Y ATSSS
Max-Requested-Bandwidth- 515 5.3.14 Unsigned32 M,V P Y
DL
Max-Requested-Bandwidth- 516 5.3.15 Unsigned32 M,V P Y
UL
Max-Supported-Bandwidth- 543 5.3.41 Unsigned32 V P M Y E2EQOSMTSI
DL
Max-Supported-Bandwidth- 544 5.3.42 Unsigned32 V P M Y E2EQOSMTSI
UL
 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- 517 5.3.16 Grouped M,V P Y
Description
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 Enumerate M,V P Y
d
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- 534 5.3.32 Unsigned32 V P M Y Rel10
DL
Min-Requested-Bandwidth- 535 5.3.33 Unsigned32 V P M Y Rel10
UL
Priority-Sharing-Indicator 550 5.3.47 Enumerate V P M Y PrioritySharing
d
Pre-emption-Control-Info 553 5.3.51 Unsigned32 V P M Y MCPTT-Preemption
Required-Access-Info 536 5.3.34 Enumerate V P M Y NetLoc
d
Retry-Interval 541 5.3.39 Unsigned32 V P M Y DeferredService
Rx-Request-Type 533 5.3.31 Enumerate V P M Y
d
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 Enumerate M,V P Y
d
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 Enumerate M,V P Y
d
SIP-Forking-Indication 523 5.3.22 Enumerate M,V P Y
d
Sponsor-Identity 531 5.3.28 UTF8String V P M Y SponsoredConnectivity
Sponsored-Connectivity- 530 5.3.27 Grouped V P M Y SponsoredConnectivity
Data (NOTE 4) SCTimeBasedUM
Sponsoring-Action 542 5.3.40 Enumerate V P M Y SponsorChange
d
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 subclause 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.

*** 3rd Change ***

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 subclause E.x1.

Editor's note: Whether additional information about the forwarding of the traffic on the available access types is
required is FFS.

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. Applicable to
functionality introduced with the PLMNInfo feature as described in subclause 5.4.1.

EPS_FALLBACK (17)

In the RA-Request (RAR), this value shall be used by the PCF 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 the PCF 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.

*** 4th Change ***

5.3.x1 MA-Information AVP
The MA-Information AVP (AVP code 569) 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: 569 >
[ IP-CAN-Type ]
[ RAT-Type ]
[ MA-Information-Action ]
*[ AVP ]

Editor's note: Whether additional information about the forwarding of the traffic on the available access types is
required is FFS.

*** 5th Change ***

5.3.x2 MA-Information-Action AVP

The MA-Information-Action AVP (AVP code 570) 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.

*** 6th Change ***

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 Feature M/O Description
bit
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], subclause 6.1.19.
19 PLMNInfo O This feature indicates that reporting on changes of PLMN info is
supported.
20 MediaComponentVersionin O This feature indicates the support of media component versioning as
g defined in subclause 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, the release cause code information from the access network can include RAN/NAS release
cause(s), a TWAN release cause or an untrusted WLAN release cause.

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

Feature Feature M/O Description

bit
0 PCSCF-Restoration- O This feature indicates support of P-CSCF Restoration Enhancement. It is
Enhancement used for the PCRF and the P-CSCF to indicate if they support P-CSCF
Restoration Enhancement.
1 Extended-Max- O This feature indicates the support of the extended Max-Requested-
Requested-BW-NR Bandwidth for NR.
2 Extended-Min- O This feature indicates the support of the extended Min-Requested-
Requested-BW-NR Bandwidth for NR. It requires that Rel-10 feature is also supported.
3 Extended-BW- O This feature indicates the support of the extended E2EQOSMTSI
E2EQOSMTSI-NR 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 subclause 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 subclause 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 subclause E.3.
9 ATSSS O This feature indicates the support of the report of multiple access types
for a MA PDU session as defined in subclause E.x1.
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.

*** 7th Change ***

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 ]
[ 3GPP-SGSN-MCC-MNC ]
*[ 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 ]

*** 8th Change ***

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 ]
[ 3GPP-SGSN-MCC-MNC ]
[ TWAN-Identifier ]
[ TCP-Source-Port ]
[ UDP-Source-Port ]
[ UE-Local-IP-Address ]
[ Origin-State-Id ]
*[ Class ]
*[ Proxy-Info ]
*[ Route-Record ]
*[ AVP ]

*** 9th Change ***

E.x1 IP-CAN type change Notification for a MA PDU
session
If the AF has successfully subscribed to change notifications in UE’s IP-CAN type and RAT type, the ATSSS feature is
supported and the PDU session is a MA PDU session the PCF shall send an RAR command when the corresponding
event occurs, i.e.:

- when a UE’s IP-CAN type or RAT type changes; or

- a new IP-CAN type and RAT type become available for the UE and the MA PDU session; or

- an IP-CAN type and RAT type become unavailable (are released) for the UE and the MA PDU session.

In this case the RAR from the PCF shall include the Specific-Action AVP for the subscribed event and include:

- if it is the first access type report:

i. the IP-CAN-Type AVP, RAT-Type AVP (if applicable) for the UE’s IP-CAN/RAT type values; and

ii. if both, 3GPP and non-3GPP access information is available, the additional IP-CAN type information and
RAT type information (if available) in the MA-Information AVP;

- if it is a subsequent access type change report:

i. if a new access type is added to the MA PDU session, the MA-Information AVP with the added IP-CAN
type information encoded in the IP-CAN-Type AVP and the RAT type information encoded within the RAT-
Type AVP if applicable;

ii. if an access type is released in the MA PDU session, the MA-Information AVP with the released IP-CAN
type information encoded in the IP-CAN-Type AVP, the RAT type information encoded within the RAT-
Type AVP, if applicable, and the MA-Information-Action AVP set to 1 (RELEASE);

iii. if the RAT type changed within an already reported IP-CAN type, the IP-CAN-Type AVP and the RAT-
Type AVP (if applicable) for the UE’s new IP-CAN/RAT type values.

Editor's note: Whether additional information about the forwarding of the traffic on the available access types is
required is FFS.

*** End of Changes ***