Rx Interface - 29.214
Overview
The Rx reference point is used to
exchange application level session information between the Policy and
Charging Rules Function (PCRF) and the Application Function (AF). Signalling
flows related to the both Rx and Gx interfaces are specified in 3GPP
TS 29.213
Rx Reference Model:
Definitions:
Application Function (AF):
Element offering application(s)
that use IP bearer
resources
NOTE: One example of an AF is the P-CSCF of the IM CN subsystem.
AF
Session:
application level session established by an application
level signalling protocol offered by the AF that requires a session
set-up with explicit session description before the use of the
service.
NOTE: One example of an application session is an IMS session.
Binding:
PCRF process of associating IP flows described in AF Service
Information with IP-CAN bearers.
PCC rule:
set of information
enabling the detection of a service data flow and providing
parameters for policy control and/or charging control
service information:
set of information conveyed from the AF to the PCRF over the Rx
interface to be used as a basis for PCC decisions at the PCRF,
including information about the AF session (e.g. application
identifier, type of media, bandwidth, IP address and port number)
service data flow:
An
aggregate set of packet flows.
AF
The AF is an element offering
applications that require the Policy and Charging Control of traffic
plane resources (e.g. UMTS PS domain/GPRS domain resources). One
example of an application function is the P-CSCF/SBC. The AF shall use
the Rx reference point to provide session information to the PCRF. i.e VoLTE/VoIP
PCRF
The PCRF (Policy Control and Charging
Rules Function) is a functional element that encompasses policy
control decision and flow based charging control functionalities.
The PCRF provides network control
regarding the service data flow detection, gating, QoS and flow based
charging (except credit management) towards the PCEF. The PCRF
receives session and media related information from the AF and
informs AF of traffic plane events.
If the AF requests it, the PCRF shall
report IP-CAN session events (including bearer events and events on
AF signalling transport) to the AF via the Rx reference point.
The PCRF PCC/QoS Rule decisions may
be based on one or more of the following:
- the
session and media related information obtained from the AF via the Rx
reference point;
- the
bearer and subscriber related information obtained from the PCEF over
the Gx reference point;
- the
bearer and subscriber related information obtained from the BBERF
over the Gxx reference point;
- subscriber
and service related data the PCRF may be aware of by configuration or
through the Sp reference point;
- pre-configured
information in the PCRF.
PCC procedures over Rx reference
point
Initial Provisioning
- AF shall open an Rx Diameter session with the PCRF
for the AF session using an AA-Request command, unless an Rx session
has already been established for the AF session . If an Rx Diameter session already exists for the
AF session, the AF uses the existing Rx Diameter session.
- The AF
shall provide the full IP address of the UE using either
Framed-IP-Address AVP or Framed-Ipv6-Prefix AVP, and the
corresponding Service Information within Media-Component-Description
AVP(s). The AF shall not include circuit-switched bearer related
media in the service information sent to the PCRF.
- The AF shall
indicate to the PCRF as part of the Media-Component-Description
whether the media IP flow(s) should be enabled or disabled with the
Flow-Status AVP.
NOTE 1: The AF does not need to open an Rx
Diameter session with the PCRF, if the SDP
payload is only proposing to use a circuit-switched bearer (i.e. “c=”
line set to “PSTN” and an “m=” line set to “PSTN”, refer
to 3GPP TS 24.292 [26]).
NOTE 2: The Rx Diameter session used for an AF
session is different from the Rx Diameter session possibly used for
the notifications of the status of the AF
signalling transmission path. A new
Rx Diameter session is established for each new AF
session.
- The AF may include the
AF-Application-Identifier AVP into the AA-Request in order to
indicate the particular service that the AF session belongs to. This
AVP can be provided at both AF session level, and
Media-Component-Description level. When provided at both levels, the
AF-Application Identifier provided within the
Media-Component-Description AVP will have precedence.
- The AF may include the
AF-Charging-Identifier AVP into the AA-Request for charging
correlation purposes.
- The AF may also include the Specific-Action AVP
to request notification for certain user plane events, e.g. bearer
termination.
- The AF may include the Service-URN
AVP in order to indicate that the new AF session relates to emergency
traffic. If the PCRF receives the Service-URN AVP indicating an
emergency session, the PCRF may apply special policies, for instance
prioritising service flows relating to the new AF session or allowing
these service flows free of charge.
- The AF may include the MPS-Identifier
AVP in order to indicate that the new AF session relates to an MPS
session. If the PCRF receives the MPS-Identifier AVP indicating an
MPS session, the PCRF may take specific actions on the corresponding
IP-CAN to ensure that the MPS session is prioritized as specified in
3GPP TS 29.212 [8].
- If the AF
provides service information that has been fully negotiated (e.g.
based on the SDP answer), the AF may include the Service-Info-Status
AVP set to FINAL_SERVICE_INFORMATION. In this case the PCRF shall
authorize the session and provision the corresponding PCC/QoS rules
to the PCEF/BBERF.
- The AF may
additionally provide preliminary service information not fully
negotiated yet (e.g. based on the SDP offer) at an earlier stage. To
do so, the AF shall include the Service-Info-Status AVP with the
value set to PRELIMINARY SERVICE INFORMATION. Upon receipt of such
preliminary service information, the PCRF shall perform an early
authorization check of the service information.
- For GPRS, the PCRF
shall not provision PCC rules towards the PCEF unsolicitedly.
However, the PCRF may authorize a PCC/QoS rule
request received from the PCEF/BBERF as per 3GPP TS 29.212 [8].
Further, if the AF requests the PCRF to report the access network
information together with preliminary service information, the PCRF
shall immediately configure the PCEF (or BBEF) to provide the access
network information.
- For sponsored data connectivity, the
AF shall provide the application service provider identity and the
sponsor identity to the PCRF by including the
Application-Service-Provider-Identity AVP and the Sponsor-Identity
AVP in the Sponsored-Connectivity-Data AVP in the AA-Request.
- To support
the usage monitoring of sponsored data connectivity, the AF may also
include the Granted-Service-Unit AVP in the
Sponsored-Connectivity-Data AVP and the Specific-Action AVP set to
the value USAGE_REPORT in the AA-Request to request notification when
the usage threshold has been reached.
NOTE 4: If the AF is in the user plane, the AF can handle the usage
monitoring and therefore it is not required to provide a usage
threshold to the PCRF as part of the sponsored data connectivity
information.
- If the UE is roaming with the visited
access case and the AF is located in the HPLMN or roaming with the
home routed case and operator policies do not allow accessing the
sponsored data connectivity with this roaming case, the H-PCRF shall
reject the service request indicating
UNAUTHORIZED_SPONSORED_DATA_CONNECTIVITY to the AF.
- If the UE is roaming with the visited
access case and the AF is located in the VPLMN, the V-PCRF shall
reject the service request indicating
UNAUTHORIZED_SPONSORED_DATA_CONNECTIVITY to the AF.
If the UE is in the non-roaming case or roaming with the home routed
case and the operator policies allow accessing the sponsored data
connectivity with this roaming case, the following procedures apply:
- If
the PCEF does not support sponsored connectivity and the required
reporting level for that service indicates a sponsored connectivity
level according to 3GPP TS 29.212 [8], subclause 4.5.20, then the
PCRF shall reject the request indicating
REQUESTED_SERVICE_NOT_AUTHORIZED.
- If
the PCEF supports sponsored data connectivity feature or the required
reporting level is different from sponsored connectivity level as
described in 3GPP TS 29.212[8], then the PCRF, based on operator
policies, shall check whether it is required to validate the
sponsored connectivity data. If it is required, it shall perform the
authorizations based on sponsored data
connectivity profiles. If the authorization fails, the PCRF responds
to the AF with an AA-Answer including the Experimental-Result-Code
AVP set to the value UNAUTHORIZED_SPONSORED_DATA_CONNECTIVITY.
The profile may include a list of Application Service Providers and
their applications per sponsor.
NOTE 5: If the AF is in the operator’s network and is based on the
OSA/Parlay-X GW, the PCRF is not required to verify that a trust
relationship exists between the operator and the sponsors.
When the
PCRF receives an initial AA-Request from the AF, the PCRF shall
perform session binding as described in 3GPP TS 29.213 [9]. To allow
the PCRF to identify the IP-CAN session for which this request
applies, the AF shall provide either the Framed-IP-Address or the
Framed-Ipv6-Prefix containing the full IP address applicable to an IP
flow or IP flows towards the UE. In case of private IP address being
used, the AF may provide PDN information if available in the
Called-Station-Id AVP for session binding. The AF may provide the
domain identity in the IP-Domain-Id AVP for session binding.
NOTE 6: The IP-Domain-Id AVP is helpful in the following scenario:
Within a PLMN, there are several separate IP address domains, with
PCEF(s) that allocate Ipv4 IP addresses out of the same private
address range to Ues. The same IP address can thus be allocated to
Ues served by PCEFs in different address domains. If one PCRF
controls several PCEFs in different IP address domains, the UE IP
address is thus not sufficient for the session binding. An AF can
serve Ues in different IP address domains, either by having direct IP
interfaces to those domains, or by having interconnections via NATs
in the user plane between PCEFs and the AF. If a NAT is used, the AF
obtains the IP address allocated to the UE via application level
signalling and supplies it for the session binding as
Framed-IP-Address to the PCRF. The AF supplies an IP-Domain-Id value
denoting the IP address domain behind the NAT in addition. The AF can
derive the appropriate value from the source address (allocated by
the NAT) of incoming user plane packets.
NOTE 7: When the scenario described in NOTE 6 applies and the AF is a
P-CSCF it is assumed that the P-CSCF has direct IP interfaces to the
different IP address domains and that no NAT is located between P-GW
and P-CSCF. How a non-IMS AF obtains the UE private IP address to be
provided to the PCRF is out of scope of the present release; it is
unspecified how to support applications that use a protocol that does
not retain the original UE’s private IP address.
If the
PCRF fails in executing session binding, the PCRF responds to the AF
with an AA-Answer including the Experimental-Result-Code AVP set to
the value IP-CAN_SESSION_NOT_AVAILABLE. Further details on how the
PCRF identifies suitable IP-CAN sessions can be found in the binding
mechanism described in 3GPP TS 29.213 [9].
If the
request contains Media-Component-Description Attribute-Value Pair(s)
(AVP(s)) the PCRF shall store the received Service Information. The
PCRF shall process the received Service Information according to the
operator policy and may decide whether the request is accepted or
not. The PCRF may take the priority information within the
Reservation-Priority AVP into account when making this decision. If
the service information provided in the AA-Request command is
rejected (e.g. the subscribed guaranteed bandwidth for a particular
user is exceeded), the PCRF shall indicate in the AA-Answer the cause
for the rejection with the Experimental-Result-Code AVP set to the
value REQUESTED_SERVICE_NOT_AUTHORIZED. The PCRF may additionally
provide the acceptable bandwidth within the Acceptable-Service-Info
AVP.
To allow the PCRF and PCEF to perform
PCC rule authorization and bearer binding for the described service
IP flows, the AF shall supply both source and destination IP
addresses and port numbers within the Flow-Description AVP, if such
information is available.
NOTE: In SDP source port information is usually not available.
The AF may specify the
Reservation-Priority AVP at request level in the AA-Request in order
to assign a priority to the AF Session as well as specify the
Reservation-Priority AVP at the media-component-description AVP level
to assign a priority to the IP flow. The presence of the
Reservation-Priority in both levels does not constitute a conflict as
they each represent different types of priority. Specifically the
Reservation-Priority at the AA-Request level provides the relative
priority for a session while the Reservation-Priority at the
media-component-description level provides the relative priority for
an IP flow within a session. If the Reservation-Priority AVP is not
specified the requested priority is DEFAULT (0).
The AF may request notifications of
specific IP-CAN session events through the usage of the
Specific-Action AVP in the AA-Request command. The PCRF shall make
sure to inform the AF of the requested notifications in the event
that they take place.
The AF may include the
Rx-Request-Type AVP set to INITIAL_REQUEST in the AAR.
The PCRF
shall check whether the received Service Information requires PCC/QoS
Rules to be created and provisioned and/or authorized QoS to be
provisioned. Provisioning of PCC/QoS Rules and Authorized QoS to the
PCEF/BBERF shall be carried out as specified at 3GPP TS 29.212 [8].
The PCRF
shall reply with an AA-Answer to the AF. The acknowledgement towards
the AF should take place before or in parallel with any required PCC
Rule provisioning towards the PCEF and shall include the
Access‑Network-Charging-Identifier(s) and may include the
Access-Network-Charging-Address AVP, if they are available. The
AA-Answer message shall also include the IP-CAN-Type AVP, if such
information is available. In that case, the AA-Answer message shall
also include the RAT-Type AVP when applicable for the specific IP-CAN
Type (e.g. 3GPP IP-CAN Type). In addition, if IP flow mobility
applies to service data flows as specified in 3GPP TS 29.212 [8],
such that a subset of the flows within the AF session are affected,
the PCRF shall also include IP-CAN-type and RAT-type information (if
applicable) to IP flow mobility related flows, if such information is
available. The IP flow mobility affected service data flows are
included within the Flows AVP at command level. If the PCRF needs to
terminate the Rx session before it has sent the AA Answer, the PCRF
shall send the AA Answer immediately and before the AS Request.
The behaviour when the AF does not
receive the AA Answer, or when it arrives after the internal timer
waiting for it has expired, or when it arrives with an indication
different than DIAMETER_SUCCESS, are outside the scope of this
specification and based on operator policy.
If the PCRF fails in installing
PCC/QoS rules based on the provided service information due to
resource allocation failure as specified in 3GPP TS 29.212 [8] and if
requested by the AF, the PCRF shall send an RAR command to the AF
with the Specific-Action AVP set to the value
INDICATION_OF_FAILED_RESOURCES_ALLOCATION to report the resource
allocation failure. The AF shall send an RAA command to acknowledge
the RAR command.
Rx messages
Existing Diameter command codes from
the Diameter base protocol RFC 3588 [10] 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 RFC
3588 [10].
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 >
{ Auth-Application-Id }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
[ Destination-Host ]
[ IP-Domain-Id
]
[ AF-Application-Identifier ]
*[
Media-Component-Description ]
[ Service-Info-Status
]
[ AF-Charging-Identifier ]
[ SIP-Forking-Indication ]
*[
Specific-Action ]
*[
Subscription-Id
]
*[
Supported-Features ]
[ Reservation-Priority ]
[ Framed-IP-Address ]
[ Framed-Ipv6-Prefix ]
[ Called-Station-Id
]
[ Service-URN ]
[ Sponsored-Connectivity-Data ]
[ MPS-Identifier
]
[ Rx-Request-Type ]
*[
Required-Access-Info ]
[ 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 >
{ Auth-Application-Id }
{ Origin-Host }
{ Origin-Realm }
[ Result-Code ]
[ Experimental-Result ]
*[
Access-Network-Charging-Identifier ]
[ Access-Network-Charging-Address ]
[ Acceptable-Service-Info
]
[ IP-CAN-Type ]
[ NetLoc-Access-Support ]
[ RAT-Type ]
*[
Flows ]
*[
Supported-Features ]
*[
Class ]
[ Error-Message ]
[ Error-Reporting-Host ]
*[
Failed-AVP ]
[ Origin-State-Id ]
*[
Redirect-Host ]
[ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ]
*[
Proxy-Info ]
*[
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 >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Destination-Host }
{ Auth-Application-Id }
*{
Specific-Action }
*[
Access-Network-Charging-Identifier ]
[ Access-Network-Charging-Address ]
*[
Flows ]
*[
Subscription-Id
]
[ Abort-Cause ]
[ IP-CAN-Type ]
[ NetLoc-Access-Support ]
[ RAT-Type
]
[ Sponsored-Connectivity-Data ]
[
3GPP-User-Location-Info ]
[
User-Location-Info-Time
]
[ 3GPP-MS-TimeZone
]
[ 3GPP-SGSN-MCC-MNC ]
[ 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 >
{ Origin-Host }
{ Origin-Realm }
[ Result-Code ]
[ Experimental-Result ]
*[
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 >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Auth-Application-Id }
{ Termination-Cause }
[ Destination-Host ]
*[
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 >
{ Origin-Host }
{ Origin-Realm }
[ Result-Code ]
[ Error-Message ]
[ Error-Reporting-Host ]
*
[ Failed-AVP ]
[ Sponsored-Connectivity-Data ]
[ Origin-State-Id ]
[
3GPP-User-Location-Info ]
[
User-Location-Info-Time ]
[ 3GPP-MS-TimeZone
]
[ 3GPP-SGSN-MCC-MNC ]
[ NetLoc-Access-Support ]
*[
Class ]
*[
Redirect-Host ]
[ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ]
*[
Proxy-Info ]
*[
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 >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Destination-Host }
{ Auth-Application-Id }
{ 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 >
{ Origin-Host }
{ Origin-Realm }
[ Result-Code ]
[ Origin-State-Id ]
[ Error-Message ]
[ Error-Reporting-Host ]
*[ Failed-AVP ]
*[ Redirect-Host ]
[ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ]
*[ Proxy-Info ]
*[ AVP ]
