ETSI TS 183 026 V3.1.1 (2010-03)

Technical Specification
Telecommunications and Internet converged Services and
Protocols for Advanced Networking (TISPAN);
Resource and Admission Control;
Protocol for QoS reservation information exchange between
the Service Policy Decision Function (SPDF) and the
Access-Resource and Admission Control Function (A-RACF)
in the Resource and Protocol specification

2 ETSI TS 183 026 V3.1.1 (2010-03)

Reference
RTS/TISPAN-03210-NGN-R3
Keywords
interface, stage 3
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: +33 4 92 94 42 00  Fax: +33 4 93 65 47 16

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
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.

© European Telecommunications Standards Institute 2010.
All rights reserved.
TM TM TM TM
DECT , PLUGTESTS , UMTS , TIPHON , the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered
for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
LTE™ is a Trade Mark of ETSI currently being registered
for the benefit of its Members and of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 ETSI TS 183 026 V3.1.1 (2010-03)
Contents
Intellectual Property Rights . 5
Foreword . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 7
3 Definitions and abbreviations . 7
3.1 Definitions . 7
3.2 Abbreviations . 8
4 Rq interface . 8
4.1 Overview . 8
4.2 Rq reference model . 9
4.3 Functional elements and capabilities . 9
4.3.1 Service Policy Decision Function (SPDF) . 9
4.3.2 Access-Resource Admission Control Function (A-RACF) . 9
5 Resource control procedures . 9
5.1 Procedures at the SPDF . 11
5.1.1 Initial Reservation for a Session . 11
5.1.2 Session Modification . 12
5.1.3 Session Termination . 13
5.1.4 Event notification . 13
5.2 Procedures at the A-RACF . 14
5.2.1 Initial Reservation for a Session . 14
5.2.2 Session Modification . 16
5.2.3 Session Termination . 16
5.2.4 Event Notification . 17
6 Rq protocol . 17
6.1 Protocol support . 17
6.1.1 Advertising Application Support . 17
6.1.2 Transport protocol . 17
6.1.3 Securing Rq messages . 18
6.1.4 Use of sessions . 18
6.2 Rq messages . 18
6.2.1 AA-Request (AAR) Command . 18
6.2.2 AA-Answer (AAA) Command . 18
6.2.3 Re-Auth-Request (RAR) Command . 19
6.2.4 Re-Auth-Answer (RAA) Command . 19
6.2.5 Session-Termination-Request (STR) Command . 20
6.2.6 Session-Termination-Answer (STA) Command . 20
6.2.7 Abort-Session-Request (ASR) Command . 20
6.2.8 Abort-Session-Answer (ASA) Command . 21
6.3 Experimental-Result-Code AVP values . 21
6.3.1 Experimental-Result-Code AVP values imported from TS 129 209 . 21
6.3.2 Experimental-Result-Code AVP values defined in the present document . 21
6.4 AVPs . 22
6.4.1 AVPs defined in the present document . 22
6.4.2 AVPs imported from TS 129 209 . 22
6.4.3 AVPs imported from TS 183 017 . 23
6.4.4 AVPs imported from ES 283 034 . 23
6.4.5 Abort-Cause AVP . 24
6.4.6 AF-Application-Identifier AVP . 24
6.4.7 Flow-Description AVP . 24
6.4.8 Flow-Grouping AVP. 25
ETSI
4 ETSI TS 183 026 V3.1.1 (2010-03)
6.4.9 Flow-Number AVP . 25
6.4.10 Flows AVP. 25
6.4.11 Flow-Status AVP . 25
6.4.12 Flow-Usage AVP . 26
6.4.13 Specific-Action AVP . 26
6.4.14 Max-Requested-Bandwidth-DL AVP . 27
6.4.15 Max-Requested-Bandwidth-UL AVP . 27
6.4.16 Media-Component-Description AVP . 27
6.4.17 Media-Component-Number AVP . 27
6.4.18 Media-Sub-Component AVP . 27
6.4.19 Media-Type AVP . 28
6.4.20 Reservation-Class AVP . 28
6.4.21 Globally-Unique-Address AVP . 28
6.4.22 Address-Realm AVP. 28
6.4.23 Reservation-Priority AVP . 29
6.4.24 Session-Bundle-Id AVP . 29
6.4.25 AF-Charging-Identifier AVP . 29
6.4.26 Service-Class AVP . 29
6.4.27 Transport-Class AVP . 30
6.4.28 Overbooking-indicator AVP . 30
6.4.29 Authorization-Package-Id AVP . 30
6.4.30 Media-Authorization-Context-Id AVP . 30
6.4.31 Logical-Access-ID AVP . 30
Annex A (informative): Resource reservation flow states maintained by A-RACF . 31
Annex B (informative): Change history . 33
History . 34

ETSI
5 ETSI TS 183 026 V3.1.1 (2010-03)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://webapp.etsi.org/IPR/home.asp).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Technical Specification (TS) has been produced by ETSI Technical Committee Telecommunications and Internet
converged Services and Protocols for Advanced Networking (TISPAN).
ETSI
6 ETSI TS 183 026 V3.1.1 (2010-03)
1 Scope
The present document provides the stage 3 specification of the Rq interface. The functional requirements and the
stage 2 specifications of the Rq interface are contained in ES 282 001 [1] and ES 282 003 [2]. The Rq interface is the
interface between the Service Policy Decision Function (SPDF) and the Access - Resource and Admission Control
Function (A-RACF) and is used for QoS resource reservation information exchange between the SPDF and the
A-RACF. Via the Rq interface the SPDF issues requests for resources in the access network, indicating IP QoS
characteristics. The A-RACF uses the IP QoS information to perform admission control and indicate to the SPDF via
the Rq interface its admission control decisions. Due to the possible business roles in an access environment, the SPDF
may be either in the same domain or in a different domain as the A-RACF.
The present document defines:
• The information to be exchanged between SPDF and A-RACF over the Rq interface.
• An Rq interface definition based on the Diameter protocol.
In situations where no generic overload control mechanism is used on the Rq interface, the interface shall only be
capable of supporting a one-to-one relationship between the A-RACF and SPDF (i.e. one SPDF may only contact one
A-RACF, and that A-RACF may only contact that same SPDF). Overload control need not be supported in this
situation due to the fact that it should be possible to traffic engineer the capabilities of the two entities, so that the
capacity of one entity matches the capacity of the other.
2 References
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.
• Non-specific reference may be made only to a complete document or a part thereof and only in the following
cases:
- if it is accepted that it will be possible to use all future changes of the referenced document for the
purposes of the referring document;
- for informative references.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee
their long term validity.
2.1 Normative references
The following referenced documents are indispensable for the application of the present document. For dated
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document
(including any amendments) applies.
[1] ETSI ES 282 001 (V3.y.z): "Telecommunications and Internet converged Services and Protocols
for Advanced Networking (TISPAN); NGN Functional Architecture".
[2] ETSI ES 282 003 (V3.y.z): "Telecommunications and Internet converged Services and Protocols
for Advanced Networking (TISPAN); Resource and Admission Control Sub-System (RACS):
Functional Architecture".
ETSI
7 ETSI TS 183 026 V3.1.1 (2010-03)
[3] ETSI ES 282 004 (V3.y.z): "Telecommunications and Internet converged Services and Protocols
for Advanced Networking (TISPAN); NGN Functional Architecture; Network Attachment Sub-
System (NASS)".
[4] ETSI ES 283 034 (V2.y.z): "Telecommunications and Internet converged Services and Protocols
for Advanced Networking (TISPAN); Network Attachment Sub-System (NASS); e4 interface
based on the DIAMETER protocol".
[5] ETSI TS 183 017 (Release 3): "Telecommunications and Internet converged Services and
Protocols for Advanced Networking (TISPAN); Resource and Admission Control: DIAMETER
protocol for session based policy set-up information exchange between the Application Function
(AF) and the Service Policy Decision Function (SPDF); Protocol specification".
[6] ETSI TS 129 207: "Digital cellular telecommunications system (Phase 2+); Universal Mobile
Telecommunications System (UMTS); Policy control over Go interface (3GPP TS 29.207)".
[7] ETSI TS 129 209: "Universal Mobile Telecommunications System (UMTS); Policy control over
Gq interface (3GPP TS 29.209)".
[8] ETSI TS 133 210: "Digital cellular telecommunications system (Phase 2+); Universal Mobile
Telecommunications System (UMTS); 3G security; Network Domain Security (NDS); IP network
layer security (3GPP TS 33.210)".
[9] IETF RFC 2960: "Stream Control Transmission Protocol".
[10] IETF RCF 3309: "Stream Control Transmission Protocol (SCTP) Checksum Change".
[11] IETF RFC 3588: "Diameter Base Protocol".
[12] IETF RFC 4005: "Diameter Network Access Server Application".
2.2 Informative references
The following referenced documents are not essential to the use of the present document but they assist the user with
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including
any amendments) applies.
Not applicable.
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
Attribute-Value Pair (AVP): corresponds to an Information Element in a Diameter message
NOTE: See RFC 3588 [11].
hard-state reservation: type of reservation whereby the requested resources are reserved without time limit
NOTE: Hard-state reservations are terminated if the DIAMETER session is terminated.
soft-state reservation: type of reservation whereby the requested resources are reserved for a finite amount of time,
soft-state reservations are terminated when the DIAMETER session is terminated
ETSI
8 ETSI TS 183 026 V3.1.1 (2010-03)
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AAA AA-Answer
AAR AA-Request
AF Application Function
A-RACF Access-Resource and Admission Control Function
ASA Abort-Session-Answer
ASP Application Service Provider
ASR Abort-Session-Request
ATM VC Asynchronous Transfer Mode Virtual Circuit
AVP Attribute-Value Pair
BGF Border Gateway Function
BTF Basic Transport Functions
IANA Internet Assigned Numbers Authority
IP Internet Protocol
IP-CAN IP-Connectivity Access Network
NASREQ Network Access Server REQuirements
RAA Re-Auth-Answer
RACF Resource and Admission Control Function
RACS Resource and Admission Control Subsystem
RAR Re-Auth-Request
RCEF Residual Code Excited Field
RTCP Real-time Transport Control Protocol
RTP Real-time Transport Protocol
SDI Session Description Information
SPDF Service-based Policy Decision Function
STA Session-Termination-Answer
STR Session-Termination-Request
UDP User Datagram Protocol
xDSL x Digital Subscriber Line
4 Rq interface
4.1 Overview
In the following clause, the Rq interface is described in detail concerning what type of information that needs to be
transported between the SPDF and the A-RACF. The functional requirements and the stage 2 specifications of the Rq
interface are contained in ES 282 001 [1] and ES 282 003 [2]. Due to the possible business roles in an access
environment, an SPDF instance may be either in the same domain or in a different domain as the A-RACF instance with
which it interacts. This means that Rq reference point should support both the case when an SPDF instance and the A-
RACF instance with which it interacts are located in the same domain, and when they are located in different domains.
The Rq reference point is an open vendor interface and an open operator interface. One A-RACF instance shall be able
to serve more than one SPDF instance and one given SPDF instance may interact with a number of A-RACF instances,
although on a session basis, it shall interact with only a single A-RACF instance.
ETSI
9 ETSI TS 183 026 V3.1.1 (2010-03)
4.2 Rq reference model
The Rq interface is defined between the SPDF and the A-RACF.

AFAF
GqGq ’’
RfRf
RACSRACS
RdRd ’’ , , RiRi ’’
e4e4
NANASSSS
Rq
Rq
SPDFSPDF
RrRr
xx --
RARACFCF
ReRe IaIa
RCEFRCEF BGBGFF
BTBTFF
TrTrananssppoorrtt ProProcesscessiinngg FuncFunctitioonnss

Figure 1: Rq interface architecture model
4.3 Functional elements and capabilities
4.3.1 Service Policy Decision Function (SPDF)
The SPDF is a functional element that coordinates the resource reservations requests received from by the AF. The
SPDF makes policy decisions using policy rules and forwards the session and media related information obtained from
the AF to the A-RACF via the Rq reference point for admission control purposes. The functionality of the SPDF is
further detailed in ES 282 003 [2].
4.3.2 Access-Resource Admission Control Function (A-RACF)
The A-RACF is a functional element performing resource reservation admission control and network policy assembly.
The A-RACF receives resource reservation requests from the SPDF via the Rq reference point. The functionality of the
SPDF is further detailed in ES 282 003 [2].
5 Resource control procedures
The resource control procedures are defined in seven interaction procedures:
1) Reservation.
2) Commit.
3) Reservation and commit.
4) Refresh.
5) Modification.
6) Release.
ETSI
10 ETSI TS 183 026 V3.1.1 (2010-03)
7) Event notification.
These interactions are described in the following clauses. During the interactions Diameter AVPs are passed between
the SPDF and the A-RACF.
Figure 2 describes the flow states as maintained by the A-RACF F according to the procedures. Annex A provides a
table further clarifying how states change at different events and actions taken by the A-RACF.

IdIdIdllleee
ReReRessseeerrrvvvaaatttiiiooonnn
ReRecceeiivveedd S STTRR
ModiModiModifffiiicccaaatttiiiononon
ooorrr R R Reeefrefrefressshhh
ReReRessseeerrrvvveeeddd
RRReeessseeerrrvvvatatatiiion&on&on&CCCooommmmmmiiittt
CCCooommitmmitmmit
ReRecceeiivveedd S STTR oR orr
ModiModiModifffiiicccaaatiotiotionnn
RReelleeasasee R Reequequesstt
ooorrr R R Reeefrefrefressshhh
CCCooommitmmitmmitttteeeddd
Figure 2: Flow state
The Flow-Status AVP (see clause 6.4.11) is used to define the action to be taken for each AA-Request made by the
SPDF to the A-RACF. The rules for interpreting the Flow-Status AVP are the following:
• Reservation: New Media-Description-Component AVP(s) and Media-Sub-Component AVP(s). Optional
Flow-Status AVP(s) set to DISABLED (3).
• Modification: Updated Media-Description-Component AVP(s) and/or Media-Sub-Component AVP(s).
Flow-Status AVP not modified, unless the state needs to be modified (e.g. for committing a resource
reservation, or for releasing a resource reservation).
• Commit: Media-Description-Component AVP(s) and optionally Media-Sub-Component AVP(s) of existing
reservations with Flow-Status AVP(s) set to ENABLED-UPLINK (0), ENABLED-DOWNLINK (1) or
ENABLED (2).
• ReservationAndCommit: New Media-Component-Description AVP(s) and Media-Sub-Component AVP(s).
Flow-Status AVP(s) set to ENABLED-UPLINK (0), ENABLED-DOWNLINK (1) or ENABLED (2).
• Release: Media-Description-Component AVP(s) and optionally Media-Sub-Component AVP(s) of existing
reservations with Flow-Status AVP(s) set to REMOVED (4).
• Refresh: Existing reservation unchanged (Media-Component-Description AVP(s) not specified or unchanged),
Flow-Status AVP unchanged.
ETSI
11 ETSI TS 183 026 V3.1.1 (2010-03)
5.1 Procedures at the SPDF
5.1.1 Initial Reservation for a Session
The SPDF may request the A-RACF to allocate resources for a new session (i.e. make an initial reservation request).
The SPDF issues such request by sending an AA-Request message to the A-RACF. This message contains one or more
Media-Component-Description Attribute-Value-Pair(s) (AVP(s)). Each Media-Component-Description AVP describes
the set of flows of a particular media type (i.e. it contains one or more Media-Sub-Component AVP(s) and requirements
for the flows (see clause 6.4.16)).
The SPDF may in the AA-Request include the Flow-Grouping AVP(s) to request a particular way for how the IP Flows
are to be distributed to IP-CAN bearers. The SPDF may also forward an AF-Charging-Identifier AVP from the AF in
the message for charging correlation purposes between AF and RACS.
An AA-Request issued to request an initial reservation contains a new Session-Id obtained by the SPDF. As specified in
RFC 3588 [11], the Session-Id is globally unique and is meant to uniquely identify a user session without reference to
any other information. The Session-Id begins with the sender's identity encoded in the DiameterIdentity type.
The specific action that shall be performed by the A-RACF for each individual media and flow (i.e. the Reserve or the
ReserveAndCommit operation) is defined by the Flow-Status AVP:
• Reservation; the value of the Flow-Status AVP shall be set to DISABLED (3).
• ReservationAndCommit; the value of the Flow-Status AVP shall be set to ENABLED-UPLINK (0),
ENABLED-DOWNLINK (1) or ENABLED (2).
• The Flow-Status AVP shall be specified in the Media-Component-Description AVP and in the
Media-Sub-Component AVP(s). The Flow-Status AVP shall be set to the same value in both these AVPs.
Table 1: Initial Reservation operations
Message Flow-Status AVP at the level of: Meaning
Type Media Sub-Media
AAR New Media, New flow, Reserve Resources for all the flows in the request. The
DISABLED DISABLED media(s) and flow(s) descriptions MUST be new ones.
AAR [New Media, New flow, Reserve Resources. In addition, commit resources for some
ENABLE*] ENABLE* of the flows. The media(s) and flow(s) descriptions MUST be
new ones.
As specified in clause 8.9 of RFC 3588 [11], the SPDF may specify the Authorization-Lifetime AVP in the AA-Request
to request a maximum lifetime for a session. To request a hard-state session the SPDF shall omit the
Authorization-Lifetime AVP in the AA-Request. To request a soft-state session the SPDF shall specify this AVP in the
AA-Request.
The AA-Answer may contain the Authorization-Lifetime AVP. The AA-Answer may contain the Auth-Grace-Period
AVP in addition to the Authorization-Lifetime AVP. The Authorization-Lifetime AVP specifies the maximum number
of seconds before the Session must be refreshed by the SPDF. The Auth-Grace-Period AVP contains the number of
seconds the A-RACF will wait for a Refresh following the expiration of the Authorization-Lifetime AVP.
Whether the Authorization-Lifetime AVP and Auth-Grace-Period need to be included in the AA-Answer is a local
decision of the A-RACF. This means that the SPDF may be offered a soft-state reservation although it asked for
hard-state or a hard-state reservation although it asked for soft-state. Should the SPDF not accept what is offered by the
A-RACF it must explicitly terminate the session.
The SPDF may specify the Reservation-Priority AVP (see clause 6.4.23) as a main AVP of the AA-Request in order to
assign a priority to the request. The SPDF may further specify the Reservation-Priority AVP in
Media-Component-Description AVP(s) in order to assign priority to individual media. If the Reservation-Priority AVP
is not specified the requested priority is DEFAULT.
The SPDF may specify, in the Specific-Action AVP of the AA-Request through which the initial reservation request is
made, the events of which it wants to be informed. The supported events are listed in clause 6.4.13.
ETSI
12 ETSI TS 183 026 V3.1.1 (2010-03)
The SPDF may specify in the initial AAR the authorization context to be used for a media component or for the session
by including one or more Media-Authorization-Context-Id AVP or Authorization-Package-Id AVPs respectively. In the
case of a multicast reservation, the derived authorisation context stored in A-RACF may provide information on the
multicast channels allowed or not allowed during the session and their respective QoS requirements.
Should the AA-Answer contain one or more Session-Bundle-Id AVPs the SPDF shall store the association between the
Session-Bundle-Id AVP(s) and the Session-ID AVP of the session in question.
The behaviour when the SPDF does not receive an 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, is outside the scope of the
present document.
5.1.2 Session Modification
The SPDF may modify an existing session by sending an AA-Request to the A-RACF with zero or more updated
Media-Component-Description AVP(s) and/or Media-Sub-Component AVP(s). The Session-Id shall be an existing one
and refer to the session that is to be modified. The Reservation-Priority may be specified as a main AVP and/or in
Media-Component-Description AVP(s). If the Reservation-Priority AVP is not specified the requested priority is
DEFAULT. The SPDF may perform the following operations:
• Add a new flow within a media component by providing a new Media-Sub-Component AVP within the
corresponding Media-Component-Description AVP.
• Add a new flow within a new media component by providing a new Media-Component-Description AVP.
• Modify a media component by updating the corresponding Media-Component-Description AVP (e.g. increase
or decrease the allocated bandwidth).
• Modify a flow within a media component by updating the corresponding Media-Sub-Component AVP.
• Modify a media flow state from Reserved to Committed by providing a Flow-Status AVP of the corresponding
Media-Component-Description AVP and/or Media-Sub-Component AVP(s). The Flow-Status AVP shall be
set to one of the values ENABLED-UPLINK, ENABLED-DOWNLINK or ENABLED, according to the
direction in which the resources are to be committed. This operation requires that the media and flows are in
the Reserved state prior to the AA-Request.
• Release a media component by providing the corresponding Media-Component-Description AVP with the
Flow-Status AVP set to the value REMOVED.
• Release a flow within a media by providing the corresponding Media-Sub-Component AVP with the
Flow-Status AVP set to the value REMOVED.
• Refresh a soft-state session by providing an AA-Request message containing the Session-Id of the session that
is to be refreshed. The AA-Request may contain the Authorization-Lifetime AVP to request a maximum
lifetime of the refreshed session. If this AVP is not included, the refresh message requests the lifetime to be
extended by a default value. The AA-Request may contain Media-Component-Description AVP(s) and
Media-Sub-Component AVP(s) (e.g. to modify media, flows and/or commit status).
• Modify the media level authorization context - provide new Media-Authorization-Context-Id AVP(s). The
new Media-Authorization-Context-Id AVP(s) replace any authorization context previously associated to the
media component.
• Modify the session level authorization context - provide new Authorization-Package-Id AVP(s). The new
Authorization-Package-Id AVP(s) replace any authorization context previously associated to the session.
The Flow-Status AVP in the Media-Sub-Component AVP shall always be the same as the Flow-Status AVP in the
Media-Component-Description AVP containing the Media-Sub-Component AVP. When providing new
Media-Component-Description AVP(s) and/or Media-Sub-Component AVP(s) the SPDF may in the AA-Request
include the Flow-Grouping AVP(s) to request a particular way for how the IP Flows are to be distributed to IP-CAN
bearers.
The SPDF SHALL NOT use the RAA to modify the session service information. As an option, the SPDF MAY send an
AAR command following an RAA to update the session service information.
ETSI
13 ETSI TS 183 026 V3.1.1 (2010-03)
Table 2: Modification operations
Message Type Flow-Status AVP at the level of: Meaning
Media Sub-Media
AAR Existing Media Existing Flow, Unchanged Modify a media. In addition, modify a flow
Flow-Status according to the new parameters specified in
the Media-Sub-Component AVP. The Media
and Flow must exist (see notes 1, 2 and 5).
AAR Existing Media New flow. Same Flow-Status Modify a media. In addition, add a new flow
AVP as in the media in a media. The Flow must be new (see
(see note 3) notes 3 and 5).
AAR Existing Media REMOVED Modify a media. In addition, release an
(see note 4) existing flow within an existing media. If the
flow does not exist, the request shall be
ignored by the A-RACF (see notes 2 and 5).
AAR Existing Media, Existing Flow, Flow-Status Modify the commit status (see note 5).
Modified Flow-Status AVP = REMOVED
AAR Existing Media Existing Flow (see note 5).
NOTE 1: If the media is not an existing one, the AAR is interpreted as a reservation for a new media (see clause 5.1).
NOTE 2: The parameters specified at flow-level (in the Media-Sub-Component AVP(s)) take precedence over the
parameters specified at media-level (in the updated Media-Component-Description AVP).
NOTE 3: The Flow-Status AVP of a new flow within a media shall be the same as the Flow-Status of the media. For
example, it makes no sense to commit a flow within a media that is not yet committed.
NOTE 4: As the Modify operation is also used for the Commit operation, the Flow-Status AVP of the
Media-Component-Description AVP may actually be modified.
NOTE 5: In case of a soft-state reservation, extend its lifetime.

The behaviour when the SPDF does not receive an 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, is outside the scope of the
present document.
5.1.3 Session Termination
The SPDF may issue a Session-Termination-Request (STR) command to the A-RACF, in order to terminate the session.
This command releases all the resources associated with the session identified by the provided Session-Id AVP.
Table 3: Termination operations
Message Flow-Status AVP at the level of: Meaning
Type
Media Sub-Media
STR  Release a session: all the media(s) and flow(s) within
that session are released
When receiving an Abort-Session-Request (ASR) message from the A-RACF the SPDF shall if the session involves
BGF resources release those resources and inform the AF of that the session identified by the Session-Id AVP is
terminated. If the ASR message contains one or more Session-Bundle-Id AVPs the SPDF shall perform these
procedures for all sessions associated with the Session-Bundle-Id AVP(s).
5.1.4 Event notification
Notifications for specific events may be implicitly requested through policies established in the A-RACF. The SPDF
may further specify, in the Specific-Action AVP of an initial AA-Request command, the events of which it wants to be
informed. The supported events are listed in clause 6.4.
As an option, when the SPDF receives an RAR command from the A-RACF, this may result in the SPDF sending an
AAR command to the A-RACF to update the service information. However, application-specific authentication and/or
authorization messages are not mandated for the Rq application in response to an RAR command.
ETSI
14 ETSI TS 183 026 V3.1.1 (2010-03)
5.2 Procedures at the A-RACF
5.2.1 Initial Reservation for a Session
An initial AA-Request contains one or more Media-Component-Description AVP(s) including one or more
Media-Sub-Component AVP(s). For initial reservation requests in which the Session-Id is new the
Media-Component-Number(s) and Flow-Number(s) are interpreted by the A-RACF as new ones.
The Reservation-Priority AVP may be specified (see clause 6.4.23) main AVP in the AA-Request. The AA-Answer
from the A-RACF may echo the Reservation-Priority AVP. If the Reservation-Priority AVP is not specified in the
AA-Request, the priority associated with the reservation shall be DEFAULT. If the A-RACF is not able to comply with
the requested priority level, the entire reservation shall fail and the A-RACF shall include the
Experimental-Result-Code AVP with the value PRIORITY_NOT_GRANTED.
When provided as a main AVP in an AA-Request, the Reservation-Priority AVP indicates the priority of the message to
the A-RACF. The A-RACF may use this indication when receiving and processing the message (e.g. high priority
AA-Request messages may be assigned precedence over low priority AA-Request messages).
Upon reception of an AF-Application-Identifier AVP in an initial AA-Request from the SPDF, the A-RACF shall store
this identifier together with the states created and maintained for the new session for the purpose of charging correlation
between AF and RACS. The identifier is opaque to the A-RACF.
The A-RACF shall identify the access profile that applies to the AA-Request from an identifier. This identifier comes in
the form of the Subscriber ID, the Globally Unique IP Address, or both (see clause 5.2.2.2.7 in ES 282 003 [2]). The
mapping of these parameters to the Diameter AVPs is described in table 4. If the A-RACF does not receive at least one
of these parameters, it shall return an AA-Answer that include a Result-Code AVP set to the value
DIAMETER_MISSING_AVP. The Failed-AVP AVP should be included in the message. The Failed-AVP AVP must
contain an example of the missing AVP. The value field of the missing AVP example should be of correct minimum
length and contain zeroes.
If the A-RACF cannot identify an access profile that applies to the AA-Request, it shall return an
Experimental-Result-Code AVP to the SPDF set to ACCESS_PROFILE_FAILURE.
Table 4: Mapping of information element names to Diameter AVPs
Information element name Mapping to Diameter AVP Cat. AVP used in
Subscriber ID in RACS [2] and in NASS [3] User-Name O Rq and e4 [4]
Globally Unique IP Address in RACS [2] and Globally-Unique-Address O Rq and e4 [4]
in NASS [3]
QoS Profile in NASS [3] QoS-Profile O e4 [4]
Requestor Name in RACS [2] AF-Application-Identifier O Rq
Requestor Name in NASS [3] Application-Class-ID O e4 [4]
Media Type in NASS [3] and in RACS [2] Media-Type O Rq and e4 [4]
Reservation Class in RACS [2] Reservation-Class O Rq
Transport Service Class in RACS [2] and in Transport-Class O Rq and e4 [4]
NASS [3]
Service Class in RACS [2] Service-Class O Rq
Authorization package ID in RACS [2] Authorization-Package-Id O Rq and Gq’ [5]
Media Authorization context ID Media-Authorization-Context-Id O Rq and Gq’ [5]

If the identified access profile contains one or more QoS Profiles the A-RACF shall for each
Media-Component-Description AVP in the AA-Request use the combined meaning of the AF-Application-Identifier
AVP, the Transport-Class AVP and the Media-Type AVP to identify a QoS Profile to which the request applies. For
this identification process the AF-Application-Identifier AVP, the Transport-Class AVP and the Media-Type AVP in
the AA-Request received over Rq shall be matched with the information stored in the A-RACF that corresponds to the
Application-Class-ID AVP, the Transport-Class AVP and the Media-Type AVP in the QoS Profile(s) obtained from
NASS via e4 [3].
It should be noted that an access profile obtained from NASS via e4 ES 283 034 [4] may contain one or more QoS
Profile AVPs with left out Application-Class-ID AVP, Transport-Class AVP and/or Media-Type AVP. The absence of
these AVPs allows the A-RACF to apply default QoS Profiles to any Requestor Name, any Transport Service Class,
and any Requestor Name and Transport Service Class.
ETSI
15 ETSI TS 183 026 V3.1.1 (2010-03)
If the access profile does not contain any QoS Profile the A-RACF shall instead apply a default QoS Profile to the
request. If the Reservation-Priority AVP is not specified in the Media-Component-Description AVP for which a QoS
profile applies the requested priority is DEFAULT.
The A-RACF shall return an Experimental-Result-Code AVP to the SPDF set to QOS_PROFILE_FAILURE if the
request needs to be denied for any of the following reasons:
• The User-Name AVP and/or the Globally-Unique-Address AVP do not match any access profile.
• The AF-Application-Identifier AVP, Transport-Class AVP and Media-Type AVP do not match any QoS
profile of the access profile (identified by the User-Name AVP and/or the Globally-Unique-Address AVP).
• The Max-Requested-Bandwidth-UL AVP and/or the Max-Requested-Bandwidth-DL AV
...