3rd Generation Partnership Project;

3GPP TS 29.211
Technical Specification Group Core Network and Terminals;
Rx Interface and Rx/GxV6.4.0
signalling(2007-06)
flows
(Release
Technical 6)
Specification

GLOBAL SYSTEM FOR

MOBILE COMMUNICATIONS

The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP.

The present document has not been subject to any approval process by the 3GPP Organizational Partners and shall not be implemented.
This Specification is provided for future development work within 3GPP only. The Organizational Partners accept no liability for any use of this
Specification.
Specifications and reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organizational Partners' Publications Offices.
Release 6 2 3GPP TS 29.211 V6.4.0 (2007-06)

Keywords
UMTS, Charging

3GPP

Postal address

3GPP support office address

650 Route des Lucioles - Sophia Antipolis
Valbonne - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16

Internet
http://www.3gpp.org

Copyright Notification

No part may be reproduced except as authorized by written permission.

The copyright and the foregoing restriction extend to reproduction in all media.

© 2007, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TTA, TTC).
All rights reserved.

3GPP
Release 6 3 3GPP TS 29.211 V6.4.0 (2007-06)

Contents
Foreword...................................................................................................................................................5
1 Scope..............................................................................................................................................6
2 References.......................................................................................................................................6
3 Definitions and abbreviations.........................................................................................................6
3.1 Definitions...................................................................................................................................................6
3.2 Abbreviations..............................................................................................................................................7
4 Rx reference point...........................................................................................................................7
4.1 Overview....................................................................................................................................................7
4.2 Rx reference model.....................................................................................................................................8
4.3 Functional elements and capabilities..........................................................................................................9
4.3.1 Charging Rules Function (CRF)............................................................................................................9
4.3.2 Application Function (AF)....................................................................................................................9
5 FBC Procedures over Rx.................................................................................................................9
5.1 CRF.............................................................................................................................................................9
5.1.1 Initial Provision of Session Information................................................................................................9
5.1.2 Modification of Session Information.....................................................................................................9
5.1.3 FBC Gate function...............................................................................................................................10
5.1.4 AF Session Termination......................................................................................................................10
5.1.5 Bearer Release.....................................................................................................................................10
5.1.6 Other Bearer Events............................................................................................................................10
5.2 AF..............................................................................................................................................................10
5.2.1 Provision of Service Information at session establishment.................................................................10
5.2.2 Session modification...........................................................................................................................11
5.2.3 FBC Gate function...............................................................................................................................11
5.2.4 Void.....................................................................................................................................................11
5.2.5 AF Session Termination......................................................................................................................11
5.2.6 Bearer Release.....................................................................................................................................11
5.2.7 Other Bearer Events............................................................................................................................11
6 Binding the AF Session Information to the Bearers......................................................................11
7 Rx Protocol...................................................................................................................................12
7.1 Protocol Support........................................................................................................................................12
7.1.1 Advertising application support..........................................................................................................12
7.1.2 Experimental-Result-Code AVP values..............................................................................................12
7.2 Securing Diameter messages.....................................................................................................................12
7.3 Rx messages..............................................................................................................................................13
7.3.1 AA-Request (AAR) command............................................................................................................13
7.3.2 AA-Answer (AAA) command............................................................................................................13
7.3.3 Re-Auth-Request (RAR) command....................................................................................................13
7.3.4 Re-Auth-Answer (RAA) command.....................................................................................................14
7.3.5 Session-Termination-Request (STR) command..................................................................................14
7.3.6 Session-Termination-Answer (STA) command..................................................................................14
7.3.7 Abort-Session-Request (ASR) command............................................................................................15
7.3.8 Abort-Session-Answer (ASA) command............................................................................................15
7.4 Re-used AVPs for Rx Protocol................................................................................................................15
8 Rx/Gx Signalling Flows................................................................................................................17
8.1 AF session establishment or modification................................................................................................17
8.2 Request of Charging Rule.........................................................................................................................19
8.3 Removal of Charging Rules at AF session release...................................................................................21
8.4 Bearer Release...........................................................................................................................................22

Annex A (normative): Support for SIP forking..................................................................................26

A.1 Resources for early media for forked responses.......................................................................................26

3GPP
Release 6 4 3GPP TS 29.211 V6.4.0 (2007-06)

A.2 Updating the Charging Rules information at the final answer..................................................................26

Annex B (informative): Change history..................................................................................................27

3GPP
Release 6 5 3GPP TS 29.211 V6.4.0 (2007-06)

Foreword
This Technical Specification has been produced by the 3rd Generation Partnership Project (3GPP).

The contents of the present document are subject to continuing work within the TSG and may change following formal
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an
identifying change of release date and an increase in version number as follows:

Version x.y.z

where:

x the first digit:

1 presented to TSG for information;

2 presented to TSG for approval;

3 or greater indicates TSG approved document under change control.

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections,
updates, etc.

z the third digit is incremented when editorial only changes have been incorporated in the document.

3GPP
Release 6 6 3GPP TS 29.211 V6.4.0 (2007-06)

1 Scope
The present document provides the stage 3 specification of the Rx reference point interface.

The functional requirements and the stage 2 specifications of the Rx reference point are contained in 3GPP TS 23.125
[2]. The Rx reference point is used to exchange Flow Based Charging information between the Charging Rules
Function (CRF) and the Application Function (AF).

Whenever it is possible the present document specifies the protocol by reference to specifications produced by the IETF
within the scope of Diameter and to the Gq specification 3GPP TS 29.209 [4].

The present specification also provides detailed signalling flows for FBC procedures over the interfaces that correspond
to Rx and Gx reference points.

2 References
The following documents contain provisions which, through reference in this text, constitute provisions of the present
document.

 References are either specific (identified by date of publication and/or edition number or version number) or
non-specific.

 For a specific reference, subsequent revisions do not apply.

 For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same
Release as the present document.

[1] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications".

[2] 3GPP TS 23.125: "Overall high level functionality and architecture impacts of flow based
charging; Stage 2".

[3] 3GPP TS 29.210: "Charging rule provisioning over Gx interface".

[4] 3GPP TS 29.209: "Policy control over Gq interface".

[5] IETF RFC 3588: "Diameter Base Protocol".

[6] 3GPP TS 33.210: "3G Security; Network Domain Security (NDS); IP network layer security".

[7] IETF RFC 4005: "Diameter Network Access Server Application".

[8] IETF RFC 4006: "Diameter Credit Control Application".

[9] 3GPP TS 23.228: "IP Multimedia Subsystem (IMS); Stage 2".

3 Definitions and abbreviations

3.1 Definitions
For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [1] and 3GPP TS 23.125
[2] and the following apply:

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.

3GPP
Release 6 7 3GPP TS 29.211 V6.4.0 (2007-06)

AF Session: an 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.

Attribute-Value Pair (AVP): See RFC 3588 [5], corresponds to an Information Element in a Diameter message.

Binding: the CRF process of associating IP flows described in AF Service Information with bearers.

IP flow: a unidirectional flow of IP packets with the same source IP address and port number and the same destination
IP address and port number and the same transport protocol. Port numbers are only applicable if used by the transport
protocol.

Packet Flow: a specific user data flow carried through the Traffic Plane Function. A Packet Flow can be an IP flow.

Service Information: The set of information conveyed from the AF to the CRF over the Rx interface to be used as a
basis for Flow Based Charging decisions at the CRF, including information about the AF session (e.g. application
identifier, type of media, bandwidth, IP address and port number) and parameters controlling the CRF behavior. The
encoding of the Service Information is provided in 3GPP TS 29.209 [4].

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

AAA AA-Answer
AAR AA-Request
AF Application Function
ASA Abort-Session-Answer
ASR Abort-Session-Request
AVP Attribute-Value Pair
CCA Credit-Control-Answer
CCR Credit-Control-Request
CRF Charging Rules Function
FBC Flow Based Charging
IANA Internet Assigned Numbers Authority
IM IP Multimedia
RAA Re-Auth-Answer
RAR Re-Auth-Request
STA Session-Termination-Answer
STR Session-Termination-Request
TPF Traffic Plane Function

4 Rx reference point

4.1 Overview
The Rx interface is used to exchange Flow Based Charging control information between the Charging Rules Function
(CRF) and the Application Function (AF). As defined in the stage 2 specifications (3GPP TS 23.125 [2]), this
information is used by the CRF for the Flow Based Charging (FBC) decisions. The CRF exchanges the Flow Based
Charging control information with the Traffic Plane Function (TPF) as specified in 3GPP TS 29.210 [3].

The Rx interface may be an intra- or inter-domain interface. One CRF shall be able to serve more than one AF and one
given AF may interact with a number of CRFs, although on an AF session basis, it shall interact with only a single CRF.

3GPP
Release 6 8 3GPP TS 29.211 V6.4.0 (2007-06)

Signalling flows related to the both Rx and Gx interfaces are specified in clause 8 in this specification.

4.2 Rx reference model

The Rx interface is defined between the CRF and the AF. The CRF is in the same PLMN as the TPF. The relationships
between the different functional entities involved are depicted in figure 4.1a and 4.1b..

Figure 4.1a: Rx interface architecture model for service data flow based online bearer charging

Figure 4.1b: Rx interface architecture model for service data flow based offline bearer charging

3GPP
Release 6 9 3GPP TS 29.211 V6.4.0 (2007-06)

4.3 Functional elements and capabilities

4.3.1 Charging Rules Function (CRF)
The Charging Rules Function provides Service Data Flow level Charging Rules to the TPF and informs AF about
bearer session events. The CRF makes the Charging Rule decisions which may be based on the session and media
related information obtained from the AF via the Rx reference point, the bearer and subscriber related information
obtained from the TPF over the Gx reference point, and subscriber and service related data the CRF may be aware of.
The CRF shall provision Charging Rules the TPF via the Gx reference point. The CRF may also provide policy control
like functions based on Charging Rules provisioning to the TPF.

The CRF reports, via the Rx reference point, bearer events from the TPF to the AF, e.g. bearer release and bearer
establishment.

4.3.2 Application Function (AF)

The AF is an element offering applications that require the Flow Based Charging of IP bearer resources (e.g. UMTS PS
domain/GPRS domain resources). One example of an application function is the P-CSCF. The AF shall use the Rx
reference point to provide session information to the CRF.

5 FBC Procedures over Rx

5.1 CRF
5.1.1 Initial Provision of Session Information
When receiving an initial AA-Request from the AF, the CRF shall check if it contains the Media-Component-
Description Attribute-Value Pair(s) (AVP(s)) and if so, the CRF shall store the received Service Information.

If the Specific Action AVP is present in the AAR command the CRF shall store the requested notification for the
related bearers.

The CRF shall check whether the received Service Information requires Charging Rules to be provisioned towards
existing bearer(s). The CRF identifies suitable bearers using the binding mechanisms described in clause 6.

If the CRF identifies that Charging Rules need to be provisioned, the CRF shall immediately send a Diameter RA-
Request to the TPF for each of the affected bearer(s) to trigger the TPF to request Charging Rules using a Diameter CC-
Request. The CRF shall provide the Charging Rules to the TPF within the CC-Answer.

The CRF shall then send an AA Answer back to the AF. If the CRF needs to terminate the Rx session before it has sent
the AA Answer, the CRF shall send the AA Answer immediately and before the AS Request.

5.1.2 Modification of Session Information

If the AA-Request from the AF is received for a Diameter session already active (due to an AF session modification),
the CRF shall update the Service Information with the new information received. Due to the updated Service
Information, the CRF may send a Diameter RA-Request to the TPF for each of the affected bearer(s) to trigger the TPF
to request Charging Rules using a Diameter CC-Request. The CRF shall use the CC-Answer to install new Charging
Rules and/or, to modify or remove the currently installed Charging Rules as required due to the updated Service
Information. The CRF shall then send an AA Answer back to the AF. If the CRF needs to terminate the Rx session
before it has sent the AA Answer, the CRF shall send the AA Answer immediately and before the AS Request.

3GPP
Release 6 10 3GPP TS 29.211 V6.4.0 (2007-06)

5.1.3 FBC Gate function

The AF may indicate to the CRF as part of the Media-Component-Description AVP(s) whether the IP flows should be
enabled or disabled at the bearer level. The CRF may receive a separate AA-Request message(s) from the AF to enable
or disable IP flows based on the received Service Information, the CRF may decide to install or remove the
corresponding Charging Rule(s).

5.1.4 AF Session Termination

The CRF may receive a ST-Request from the AF, indicating an AF session termination. If any Charging Rules have
been provisioned for the corresponding Service Data Flow(s), the CRF shall immediately send a Diameter RA-Request
to the TPF for each of the affected bearer(s) to trigger the TPF to request Charging Rules using Diameter CC-Request.
The CRF shall use the CC-Answer to remove those Charging Rules from the TPF.

5.1.5 Bearer Release

If the CRF receives a CC-Request from the TPF with an indication of bearer termination, the CRF shall check for each
of the IP flows from AF Service Information bound to this bearer, if it needs to notify the corresponding AF. The CRF
shall notify the AF if, and only if, the IP flow is no longer bound to any existing bearer. The CRF shall use the
following procedures to notify the AF:

- If the CRF needs to notify the AF for all IP flows of an AF session, the CRF shall send a Diameter AS-Request.
The AF will terminate the corresponding Diameter session at the Rx interface using a Diameter ST-Request.

- If the CRF needs to notify the AF for some, but not all, IP flows of an AF session, the CRF shall send an
Diameter RA-Request. Within the RA-Request, the CRF shall set the value for the Specific-Action AVP to
INDICATION_OF_TERMINATION_OF_BEARER, shall indicate the affected IP flows with the Flows AVP(s)
and shall provide the appropriate Abort-Cause AVP value.

5.1.6 Other Bearer Events

If CRF receives a notification that a bearer is being established via the Gx interface and the CRF binds IP flow(s)
described in the Service Information of an AF session to this bearer, and if the corresponding AF has requested a
notification of bearer establishment from the CRF, the CRF shall send a RA-Request including the Specific Action
AVP with the value set to INDICATION_OF_ESTABLISHMENT_OF_BEARER and shall indicate the affected IP
flows with the Flows AVP(s) if not all IP flows within an AF session are affected.

NOTE: If the IP flow is being bound to several bearers, the AF will receive several of such notifications.

5.2 AF
5.2.1 Provision of Service Information at session establishment
When a new AF session is being established and media information for this AF session is available at the AF, the AF
shall send the corresponding Service Information to the CRF by sending the AA-Request message. The AF shall
include the corresponding Media-Component-Description AVP(s) into the message. The AF may include the Flow-
Grouping AVP(s) to indicate a particular way on how the IP flows described within the service description are
distributed to several bearers at the bearer establishment. The AF may also include the Specific-Action AVP to request
notification for certain bearer events, e.g., bearer termination or bearer establishment. To allow the CRF to match the
described service IP flows in an unambiguous manner with TFT filter information, the AF should supply both source
and destination IP addresses and port numbers within the Flow-Description AVP, if such information is available.

The behaviour when the AF does not receive the AAA, 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.

3GPP
Release 6 11 3GPP TS 29.211 V6.4.0 (2007-06)

5.2.2 Session modification

During the AF session modification, the AF shall send an update for the session description information to the CRF.
The AF does this by sending the AA-Request message containing the Media-Component-Description AVP(s)
containing the updated Service Information.

5.2.3 FBC Gate function

The AF shall indicate to the network as part of the Media-Component-Description whether the media IP flow(s) should
be enabled or disabled at the bearer level. Depending on the application, the AF may instruct the CRF also during the
session when the IP flow(s) are to be enabled or disabled to pass through the access network. The AF does this by
sending the AA-Request message containing the Media-Component- Description AVP(s) that contains the flow status
information for the flows to be enabled or disabled.

5.2.4 Void

5.2.5 AF Session Termination

When an AF session is terminated, the AF shall send Session-Termination-Request message to the CRF.

5.2.6 Bearer Release

Upon the reception of a Re-Auth-Request including an Abort-Cause AVP indicating that some of the IP flows (included
in the Flows AVP) of the AF session are being discontinued (typically PDP_CONTEXT_RELEASE cause), the AF will
issue a Re-Auth-Answer as a response to the CRF.

5.2.7 Other Bearer Events

Upon the reception of a Re-Auth-Request including an Specific Action AVP indicating bearer establishment the AF
will issue a Re-Auth-Answer as a response to the CRF.

6 Binding the AF Session Information to the Bearers

Binding refers to the CRF process of associating IP flows described in AF Service Information with bearers. The
association of IP flows with bearers shall reflect in which bearers an IP flow may be transported. An IP flow described
in the AF session information can be bound to multiple bearers, as the CRF does not necessarily know which bearer is
transporting this IP flow.

NOTE: IP flows described in many AF sessions may share the same bearer(s). Separate IP flows of a single AF
session may be transported over different bearers.

If an IP flow described in the AF Service Information is bound to a bearer, the CRF shall install a Charging Rule for
this bearer with a Service Data Flow Filter matching this IP flow.

NOTE: The CRF process of deriving Charging Rules from AF service information and Gx information about
bearer(s) depends on operator preferences and is not fully specified, but the binding of IP flows to bearers
can be taken into consideration. This does not preclude that a Charging Rule installed at a bearer also
contains Service Data Flow Filter(s) matching IP flow(s) not bound to this bearer, e.g. if a single
Charging Rule is used for multiple IP flows of the same service bound to different bearers.

Upon the release of a bearer or other bearer events, the CRF notifies AF(s) about IP flows bound to this bearer, as
described in Clauses 5.1.5 and 5.1.6.

3GPP
Release 6 12 3GPP TS 29.211 V6.4.0 (2007-06)

The following methods for binding are available:

- For all bearer types, the UE IP Address shall be used for binding purposes. For IPv6, if the CRF is only notified
about the address prefix at the Gx interface, it shall compare this prefix with the prefix of the UE IP address
provided at the Rx interface.

- For all bearer types, other UE identity information (e.g. IMSI or MSISDN) may be used for binding purposes if
the AF provided such information.

- In particular, for GPRS, it is also recommended to use TFT filters (from TPF via Gx) and Flow-Description
AVPs provided within the service information (from AF via Rx) to select the Changing Rules matching to a PDP
context. The flow grouping AVP(s) of the Service Information may be used for further analysis.

Also for GPRS, the QoS information (negotiated QoS from the TPF and QoS information derived from the
service information provided by the AF) may be used for further analysis.

The GPRS binding mechanism does not necessarily identify a single PDP context for an IP flow described in AF
Service Information, therefore the same Charging Rule may be installed over several PDP contexts, even if it
corresponds only to a single AF session IP flow.

7 Rx Protocol

7.1 Protocol Support

The Rx reference point shall be based on Gq protocol as specified in 3GPP TS 29.209 [4]. Most of the AVPs from the
Gq protocol are reused as specified in sub-clause 7.2.

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

Due to the definition of the commands used in Rx protocol, there is no possibility to skip the Auth-Application-Id AVP
and use the Vendor-Specific-Application-Id AVP instead. Therefore the Rx application identifier shall be included in
the Auth-Application-Id AVP.

With regard to the Diameter protocol defined over the Rx reference point, the CRF acts as a Diameter server, in the
sense that it is the network element that handles Charging Rule control for a particular realm. The AF acts as the
Diameter Client, in the sense that is the network element requesting FBC control in the bearer path network resources.

The support of Diameter agents between the CRF and the AF, is optional for the IMS, where the Rx is intra operator
i.e. for GPRS: TPF, CRF and P-CSCF are all in the same network.

7.1.1 Advertising application support

The AF and the CRF shall advertise the support of the Rx specific Application by including the value of the application
identifier in the Auth-Application-Id AVP and the value of the 3GPP (10415) in the Vendor-Id AVP of the
Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands as specified in RFC 3588 [4], i.e. as part
of the Vendor-Specific-Application-Id AVP. The Capabilities-Exchange-Request and Capabilities-Exchange-Answer
commands are specified in the Diameter Base Protocol.

7.1.2 Experimental-Result-Code AVP values

The specific Experimental-Result-Code AVP values used by Rx protocol are the same as used by Gq protocol. These
values shall be used as specified by Gq protocol in 3GPP TS 29.209 [4].

7.2 Securing Diameter messages

For secure transport of Diameter messages, see 3GPP TS 33.210 [6].

3GPP
Release 6 13 3GPP TS 29.211 V6.4.0 (2007-06)

7.3 Rx messages
Existing Diameter command codes from the Diameter base protocol RFC 3588 [5] and the NASREQ Diameter
application (IETF RFC 4005 [7]) 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: The notion of NAS (Network Access Server) is not used here, NASREQ is just used for protocol
purposes, not for its functional meaning.

NOTE: 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 [5].

7.3.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 CRF 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 }
*[ Media-Component-Description ]
*[ Flow-Grouping ]
[ AF-Charging-Identifier ]
[ SIP-Forking-Indication ]
*[ Specific-Action ]
*[ Subscription-ID ]
*[ Proxy-Info ]
*[ Route-Record ]
*[ AVP ]

7.3.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 CRF 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 ]
[ Error-Message ]
[ Error-Reporting-Host ]
*[ Failed-AVP ]
*[ Proxy-Info ]
*[ AVP ]

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

The values INDICATION_OF_ESTABLISHMENT_OF_BEARER and INDICATION_OF_RELEASE_OF_BEARER

of the Specific-Action AVP are the only ones used in for Rx. These values of the Specific-Action AVP shall not be
combined with each other in a Re-Auth-Request.

Message Format:
<RA-Request> ::= < Diameter Header: 258, REQ, PXY >
< Session-Id >

3GPP
Release 6 14 3GPP TS 29.211 V6.4.0 (2007-06)

{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Destination-Host }
{ Auth-Application-Id }
{ Specific-Action }
*[ Flows ]
*[ Subscription-ID ]
[ Abort-Cause ]
[ Origin-State-Id ]
*[ Proxy-Info ]
*[ Route-Record ]
*[ AVP ]

7.3.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 CRF in response to the RAR command.

Message Format:
<RA-Answer> ::= < Diameter Header: 258, PXY >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
[ Result-Code ]
[ Experimental-Result ]
[ Origin-State-Id ]
[ Error-Message ]
[ Error-Reporting-Host ]
*[ Failed-AVP ]
*[ Proxy-Info ]
*[ AVP ]

7.3.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 CRF 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 ]
*[ Class ]
[ Origin-State-Id ]
*[ Proxy-Info ]
*[ Route-Record ]
*[ AVP ]

7.3.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 CRF 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 ]
[ Experimental-Result ]
[ Error-Message ]
[ Error-Reporting-Host ]
*[ Failed-AVP ]
[ Origin-State-Id ]

3GPP
Release 6 15 3GPP TS 29.211 V6.4.0 (2007-06)

*[ Redirect-Host ]
[ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ]
*[ Proxy-Info ]
[ AVP ]

7.3.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 CRF 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 ]

7.3.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 CRF in response to the ASR command.

Message Format:
<AS-Answer> ::= < Diameter Header: 274, PXY >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
[ Result-Code ]
[ Experimental-Result ]
[ Origin-State-Id ]
[ Error-Message ]
[ Error-Reporting-Host ]
*[ Failed-AVP ]
*[ Redirected-Host ]
[ Redirected-Host-Usage ]
[ Redirected-Max-Cache-Time ]
*[ Proxy-Info ]
*[ AVP ]

7.4 Re-used AVPs for Rx Protocol

The table 7.3.1 lists the Diameter AVPs re-used by the Rx reference point from existing Diameter Applications,
including a reference to their respective specifications and when needed, a short description of their usage within the Rx
reference point. Other AVPs from existing Diameter Applications, except for the AVPs from Diameter Base Protocol,
do not need to be supported. The AVPs from Diameter Base Protocol are not included in table 7.3.1, but they are re-
used for the Rx protocol

The Vendor-Id header of all AVPs defined in the present document shall be set to 3GPP (10415).

3GPP
Release 6 16 3GPP TS 29.211 V6.4.0 (2007-06)

Table 7.3.1: Rx re-used Diameter AVPs

Attribute Name Reference Comments

Abort-Cause 3GPP TS 29.209 [4]
AF-Application-Identifier 3GPP TS 29.209 [4]
AF-Charging-Identifier 3GPP TS 29.209 [4]
Flow-Description 3GPP TS 29.209 [4]
Flow-Number 3GPP TS 29.209 [4]
Flows 3GPP TS 29.209 [4]
Flow-Status 3GPP TS 29.209 [4]
Flow-Usage 3GPP TS 29.209 [4]
Flow-Grouping 3GPP TS 29.209 [4]
Max-Requested-Bandwidth-DL 3GPP TS 29.209 [4]
Max-Requested-Bandwidth-UL 3GPP TS 29.209 [4]
Media-Component-Description 3GPP TS 29.209 [4]
Media-Component-Number 3GPP TS 29.209 [4]
Media-Sub-Component AVP 3GPP TS 29.209 [4]
Media-Type 3GPP TS 29.209 [4]
RR-Bandwidth 3GPP TS 29.209 [4]
RS-Bandwidth 3GPP TS 29.209 [4]
SIP-Forking-Indication 3GPP TS 29.209 [4]
Allowed values:

INDICATION_OF_
Specific-Action 3GPP TS 29.209 [4]
TERMINATION_OF_BEARER(4)
INDICATION_OF_ESTABLISMENT OF
BEARER (5)
The identification of the subscription
Subscription-Id RFC 4006 [8]
(IMSI, MSISDN, etc.)

3GPP
Release 6 17 3GPP TS 29.211 V6.4.0 (2007-06)

8 Rx/Gx Signalling Flows

The signaling flows in this Clause are examples.

8.1 AF session establishment or modification

This clause covers the provision of Service Information and related Charging Rules when an AF session is being
established or modified.

3GPP
Release 6 18 3GPP TS 29.211 V6.4.0 (2007-06)

1. The AF receives an internal or external trigger to provide Service Information, at a set-up of a new AF
session or at a modification of an existing AF session.
2. The AF identifies the Service Information needed (e.g. IP address of the IP flow(s), port numbers to be
used etc…).
3. The AF provides the Service Information to the CRF by sending a Diameter AAR for a new Rx Diameter
session at set-up of a new AF session, or for the existing Rx Diameter session in case of AF session
modification.
4. The CRF shall store the received Service Information
5. The CRF identifies any affected established bearer(s) by binding new or modified IP flows described in the
AF Service Information to bearer(s) using the bearer information previously received from the TPF and the
Service Information received from the AF.

If any affected bearer(s) are identified in step 5, steps 6, 7 and 8 are performed separately for each of these
bearer(s). If there are no bearer(s) affected, steps 6, 7 and 8 are not executed.
6. The CRF sends Diameter RAR to trigger the TPF to request Charging Rules.
7. The TPF sends RAA to acknowledge the RAR.
8 The TPF will request Charging Rules for the bearer identified in step 7, as described in Figure 8.2 starting
with step 2.

9. As soon as the CRF completes the provisioning of Charging Rules for the bearer(s) identified in step 5, the
CRF sends a Diameter AAA to the AF.

Figure 8.1: AF session establishment or modification

3GPP
Release 6 19 3GPP TS 29.211 V6.4.0 (2007-06)

8.2 Request of Charging Rule

This clause covers two cases:

- A bearer-event-initiated Request of Charging Rules occurs when a new bearer is established or when an existing
bearer is modified. For GPRS, these are PDP Context Activation(s) or Modification(s). A bearer modification
triggers a Charging Rule request only if the CRF has previously requested a Charging Rule Request for the given
bearer modification event.

- A CRF-initiated Request of Charging Rules is triggered by a Diameter RAR sent from the CRF to solicit a
Request of Charging Rules from the TPF. The RAR request may occur in several scenarios, as depicted in
Figures 8.1 – 8.4. A CRF-initiated Request of Charging Rules may also happen as a consequence of a bearer-
event-initiated Request of Charging Rules, as shown in figure 8.2.

3GPP
Release 6 20 3GPP TS 29.211 V6.4.0 (2007-06)

1. The TPF receives a trigger for a Charging Rule Request, such as the establishment or modification of a
bearer or an RAR from the CRF.
2. The Charging Rules are requested by the TPF, using the Diameter CCR. The TPF also provides
information about the bearer within the request.

3GPP
Release 6 21 3GPP TS 29.211 V6.4.0 (2007-06)

3. The CRF stores the received bearer information in the Diameter CCR, e.g. TFT filters and UE IP address
(prefix).
4. The CRF binds the bearer to all matching IP flow(s) of existing of AF session(s) using the bearer
information received from the TPF and the Service Information received from the AF(s).
5. The CRF defines new Charging Rule(s) to be installed for the identified bearer. For a modified bearer, the
CRF can also identify existing Charging Rules that need to be modified or removed. The Charging Rules
may relate to any of the matching AF sessions identified in step 4 or that may exist in the CRF without
matching to any AF session.
6. The CRF stores the selected Charging Rules for the bearer.
7. The Charging Rules are provisioned by the CRF to the TPF using Diameter CCA. The CRF may also
provide event triggers listing bearer events for which the CRF desires Charging Rule Requests.
8. The TPF installs the received Charging Rules. For a modified bearer the TPF may also have to modify or
remove previously installed Charging Rules.

If the trigger in step 1 was a bearer establishment, steps 9 and 10 are executed separately for each affected AF
session for which the AF has requested notification of bearer establishment.
9. The CRF sends a Diameter RAR to the AF to inform it about the bearer establishment.
10. The CRF sends RAA to acknowledge the RAR.

If IP flow(s) were possibly moved to other bearer(s), other bearer(s) may need to be modified. The following steps are
performed for each of these bearers. For GPRS, an IP flow may be possibly moved if a higher priority TFT filter in the
modified PDP context was removed and a lower priority TFT filter in another PDP context matches the IP flow.
11. The CRF sends Diameter RAR to trigger the TPF to request Charging Rules for the other bearer.
12. The TPF sends RAA to acknowledge the RAR.
13. The TPF will request Charging Rules for the bearer identified in step 11, as described in the present figure
starting with step 2.

Figure 8.2: Charging Rule Request.

8.3 Removal of Charging Rules at AF session release

This clause covers the removal of Charging Rules at the AF session release.

3GPP
Release 6 22 3GPP TS 29.211 V6.4.0 (2007-06)

1. The AF receives an internal or external trigger for a session release.

2. The AF sends a session termination request, Diameter STR, to the CRF to request the removal of the
session.
3. The CRF identifies the affected bearers where Charging Rules for the IP flow(s) of this AF session are
installed. These Charging Rules need to be removed.

If any affected bearer(s) are identified, steps 4, 5 and 6 are performed separately for each of these bearer(s).
4. The CRF sends a Diameter RAR to trigger the TPF to request Charging Rules.
5. The TPF sends a Diameter RAA to acknowledge the RAR.
6. The TPF will request Charging Rules for the bearer identified in step 7, as described in Figure 8.2 starting
with step 2. The CRF will request the TPF to remove the Charging Rules for the released AF session.

7. As soon as the CRF has requested the TPF to remove the Charging Rules for all the bearer(s) identified in
step 3, The CRF sends Diameter STA, session termination answer, to the AF.

Figure 8.3: Removal of Charging Rules at AF session release

8.4 Bearer Release

This clause covers the bearer release, which may be indicated to the AF. Three cases are covered:

3GPP
Release 6 23 3GPP TS 29.211 V6.4.0 (2007-06)

- bearer release that does not cause IP flow(s) within an AF session to be disabled;

- bearer release that causes at least one but not all the IP flow(s) within an AF session to be disabled and

- bearer release that causes all the IP flows within an AF session to be disabled.

Bearer release may not cause an IP flow within an AF session to be disabled if the IP flow is bound to more than one
bearer. For GPRS, those bearers may be PDP context(s) within a PDP session. The CRF does not necessary know
which PDP context carries the IP flow, thus a release of a PDP context does not necessarily mean that the IP flow is
disabled.

3GPP
Release 6 24 3GPP TS 29.211 V6.4.0 (2007-06)

3GPP
Release 6 25 3GPP TS 29.211 V6.4.0 (2007-06)

1. A bearer is deactivated. For GPRS, the SGSN deactivates the PDP context carrying IP flow(s) of by
sending the Delete PDP Context Request message to the GGSN.
2. The TPF sends a Diameter CCR message to the CRF, indicating bearer termination.
3. The CRF identifies the IP flows bound to the removed bearer and updates the stored bearer information.
The CRF re-evaluates the binding of IP flows, as IP flows may now be bound to other bearers. For GPRS,
an IP flow may be bound to another PDP Context if it was previously bound to the removed PDP context
due to a higher priority TFT filter, and a lower priority TFT filter in another PDP context matches the IP
flow.
4. The CRF acknowledges the bearer termination by sending a Diameter CCA message.

The following steps 5 to 8 or 5a to 8a apply for the case where at least one IP Flow within an AF session is being
disabled, i.e. if the IP Flow is not bound to any other bearer that is still established. The steps shall be performed
separately for each ongoing AF session that is affected by the bearer release as explained below.

If all IP flow(s) within the AF session are disabled by the bearer release:
5. The CRF indicates the session abort to the AF by sending a Diameter ASR message to the AF.
6. The AF responds by sending a Diameter ASA message to the CRF.
7. The AF sends a Diameter STR message to the CRF to indicate that the session has been terminated.
8. The CRF responds by sending a Diameter STA message to the AF.

If at least one but not all of the IP flow(s) within the AF session are disabled by the bearer release, and the AF has
requested notification of bearer removal:
5a. The CRF indicates the release of the bearer by sending a Diameter RAR to the AF.
6a. The AF responds by sending a Diameter RAA to the CRF.
7a. The AF may send an AAR to the CRF to update the session information.
8a. If step 7a occurs, the CRF responds by sending a AAA to the AF.

If IP Flow(s) were bound to other bearer(s), Charging Rules at these bearer(s) may need to be installed or modified.
The following steps are performed for each of these bearers. For GPRS, an IP flow may be bound to another PDP
context if it was previously bound to the removed PDP context due to a higher priority TFT filter, and a lower priority
TFT filter in the other PDP context matches the IP flow.
9. The CRF sends Diameter RAR to trigger the TPF to request Charging Rules for the other bearer.
10. The TPF sends RAA to acknowledge the RAR.
11. The TPF will request Charging Rules for the bearer identified in step 9, as described in figure 8.2 starting
with step 2.

Figure 8.4: Bearer Release

3GPP
Release 6 26 3GPP TS 29.211 V6.4.0 (2007-06)

Annex A (normative):
Support for SIP forking

The P-CSCF shall be able to handle forking when FBC is applied. Forking can occur as specified in
3GPP TS 23.228 [9].

A.1 Resources for early media for forked responses

When a SIP session has been originated by a connected UE, the P-CSCF may receive provisional responses associated
with different early dialogues due to forking before the first final answer is received. Multiple early media session may
be established during this process.

The UE and the P-CSCF become aware of the forking only when a subsequent provisional response arrives for a new
early dialogue. After the first early media session is established, for each subsequent provisional response establishing
an additional early media session, the P-CSCF shall use an AA-Request within the existing Diameter session containing
the SIP-Forking-Indication AVP with value SEVERAL_DIALOGUES and include the Service Information derived
from each corresponding provisional response.

The P-CSCF shall also provision the service information derived from any subsequent SDP offer-answer exchange
within an early dialogue (e.g. in PRACK and OK(PRACK), or UPDATE and OK(UPDATE) ) using an AA request
within the existing Diameter session containing the SIP-Forking-Indication AVP with value SEVERAL_DIALOGUES
and the derived service information.

When receiving an AA-Request containing the SIP-Forking-Indication AVP with value SEVERAL_DIALOGUES, the
CRF shall identify the existing Service Information for the corresponding AF session. The CRF shall send additional
Charging Rules as required by the Flow Description AVPs within the session information to the TPF. The CRF can also
use the highest QoS requested for an IP flow by any of the forked responses as the required QoS for that IP flow. The
CRF can enable or disable the IP flows by supplying appropriate flow filters on the Gx interface depending on the flow
status that is being provisioned. However, if a flow ID has been enabled in uplink or downlink direction or bothway
within previous service information, it should remain enabled even if the CRF receives service information that disable
this flow ID within an AA request containing the SIP-Forking-Indication AVP with value SEVERAL_DIALOGUES.

A.2 Updating the Charging Rules information at the final answer

The P-CSCF shall store the SDP information for each early dialogue separately until the first final SIP answer is
received. Then the corresponding early dialogue is progressed to an established dialogue to establish the final SIP
session. All the other early dialogues are terminated. The Service Information for the SIP session is updated to match
the requirements of the remaining early dialogue only.

When receiving the first final SIP response, the P-CSCF shall send an AA-Request without the SIP-Forking-Indication
AVP and include the Service Information derived from the SDP corresponding to the dialogue of the final response.
The P-CSCF shall provision the full service information including the applicable Flow-Description AVP(s) and Flow-
Status AVP(s).

When receiving an AA-Request with no SIP-Forking-Indication AVP or with a SIP-Forking-Indication AVP with value
SINGLE_DIALOGUE, the CRF shall update the installed Charging Rules information to match only the requirements
of the Service Information within this AA-Request. The CRF should immediately remove Charging Rule(s) not
matching IP flow(s) in the updated Service Information, to reduce the risk for initial clipping of the media stream, and
to minimize possible misuse of resources. The CRF should enable or disable IP Flows according to the flow status in
the received service information.

3GPP
Release 6 27 3GPP TS 29.211 V6.4.0 (2007-06)

Annex B (informative):
Change history

Date TSG # TSG Doc. CR Rev Subject/Comment Old New

12-2004 CN#26 Presented to CN#26 for information - 1.0.0
03-2005 CN#27 Presented to CN#27 for approval 1.0.0 2.0.0
03-2005 CN#27 NP-050118 Keyword in second page corrected and the format of Annex A 2.0.0 2.0.1
changed.
03-2005 CN#27 NP-050139 Reference [9] added and the header updated. 2.0.1 2.1.0
03-2005 CN#27 Upgraded to v6.0.0 2.1.0 6.0.0
03-2005 CP#28 CP-050047 2 2 Rx Abbreviations 6.0.0 6.1.0
03-2005 CP#28 CP-050047 3 Rx Packet Flows 6.0.0 6.1.0
03-2005 CP#28 CP-050047 4 Rx Reference Model update 6.0.0 6.1.0
03-2005 CP#28 CP-050047 5 3 Rx Request of Charging Rule Flow 6.0.0 6.1.0
03-2005 CP#28 CP-050233 6 3 Rx Auth-Application-Id AVP use 6.0.0 6.1.0
03-2005 CP#28 CP-050047 7 1 Sending AAA after Charging Rule provisioning 6.0.0 6.1.0
03-2005 CP#28 CP-050047 8 2 Provision of Service Information at session establishment 6.0.0 6.1.0
03-2005 CP#28 CP-050047 9 1 Clarifications on Binding 6.0.0 6.1.0
03-2005 CP#28 CP-050047 10 1 Unnecessary AVPs in RAA 6.0.0 6.1.0
03-2005 CP#28 CP-050047 11 3 Re-binding of IP Flows at Bearer Removal 6.0.0 6.1.0
09-2005 CP#29 CP-050384 12 1 Missing description of behaviour when AAA is not received 6.1.0 6.2.0
09-2005 CP#29 CP-050383 13 3 Experimental Result Codes 6.1.0 6.2.0
09-2005 CP#29 CP-050383 14 2 NASREQ Reference update 6.1.0 6.2.0
09-2005 CP#29 CP-050383 15 2 Procedure corrections 6.1.0 6.2.0
09-2005 CP#29 CP-050383 16 2 Usage of Specific Actions AVP in RAR 6.1.0 6.2.0
12-2005 CP#30 CP-050511 18 Rx Application Identifier 6.2.0 6.3.0
06-2007 CT#36 CP-070418 19 2 Handling of disabled flows for forking 6.3.0 6.4.0

3GPP