This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
The Diameter Base protocol is defined in RFC 3588. It is intended to provide an Authentication, Authorization and Accounting (AAA) framework for differentapplications. The Diameter Base protocol provides the minimum requirements
needed for an AAA protocol.
Main components of the Diameter Base protocol:
A Diameter Client is a device that performs access control. It generates Diametermessages to request authentication, authorization, and accounting services for the
user.
A Diameter server performs authentication and/or authorization of the user.
Generates answer message.
A Diameter node may act as a client for certain requests while acting as a server forothers.
Relay Agents are Diameter agents that accept requests and route messages toother Diameter nodes based on information found in the messages (e.g., Destination-Realm). Relays modify Diameter messages by inserting and removing routinginformation, but do not modify any other portion of a message.
In the example provided in Figure 1, peer connection A is established between theClient and its local Relay. Peer connection B is established between the Relay andthe Server. User session X is ranging from the Client via the Relay to the Server.
Proxy Agents are similarly to relays. They route Diameter messages using theDiameter Routing Table. However, they differ since they modify messages byimplementation of policy enforcement. Proxies maintain the state of their downstreampeers (e.g. access devices).
Redirect Agents do not relay messages, and only return an answer with theinformation necessary for Diameter agents to communicate directly. They do notmodify messages. Since redirect agents do not receive answer messages, theycannot maintain session state.
The Diameter Base protocol is a peer-to-peer protocol. Any node can initiate arequest.
A connection is a transport level connection between two peers, used to send andreceive Diameter messages.
A session is a logical concept at the application layer, and is shared between theDiameter Client and the Diameter Server. It is identified via the Session-Id AVP
(Attribute-Value-Pair). The Session-Id is globally unique and is meant to uniquelyidentify a user session without reference to any other information.
The life cycle of the session starts when the Diameter Client issues the first requestto the Server - AAR (Authentication-Authorization-Request). This request contains aSession-Id AVP, which is used in all subsequent messages. Diameter Server must
reply with AAA (Authentication-Authorization-Answer) message. A session is terminated by sending a STR (Session-Termination-Request) messageto the Diameter server, to notify it that the session is no longer active. The Diameterserver that receives a STR message must clean up all resources associated with this
Session-Id and send back a STA (Session-Termination-Answer). In this way, sessionis moved to the Idle State.
In order to provide well defined transport behavior, Diameter Base runs over reliabletransport (TCP, SCTP).
The Diameter Base protocol is designed to be extensible. Diameter Applications canextend the base protocol by:
adding new Diameter messagesadding new AVPs (attribute-value pairs) information element in a Diameter message
or
defying new AVP value for an existing AVP.
An AVP is used to carry protocol specific data.
Additionally, it is possible to modify specific procedure, like error handling orunrecognized information handling. Unless otherwise specified, the procedures areunmodified.
The reuse of existing AVP values, AVPs and Diameter applications is stronglyrecommended. Reuse simplifies standardization and implementation and avoids
potential interoperability issues. It is expected that command codes are reused; newcommand codes can only be created by IETF Consensus. In order to allocate a new AVP value, to create a new AVP or a new application, a request must be sent toIANA.
Each Diameter application must have Application Identifier, assigned by IANA. Thebase protocol does not require an Application Identifier since its support ismandatory. During the capabilities exchange, Diameter nodes inform their peers ofsupported Application. Furthermore, all Diameter messages contain an ApplicationIdentifier. In this context, a Diameter Application means a protocol.
Example:The Gq application
Application ID:16777222.Vendor is 3GPP and vendor identifier assigned by IANA to 3GPP is 10415.
The Gx application. Application ID:16777238.Vendor is 3GPP and vendor identifier assigned by IANA to 3GPP is 10415.
The communication between 2 Diameter Agents is done via message-exchange.Messages are always in pairs, one is a Command Code Request (from Client toServer), and the next is an Answer.
A Diameter Message consists of a Header (20 octets long), called the DiameterHeader , followed by a changeable number of AVPs. This message structure is the
same in all Diameter applications.
The Header is 20 octets long.
The Header is followed by one or more Attribute-Value-Pairs (AVPs). An AVP isused to encapsulate protocol-specific data. It is possible, for a new application, to
create a new AVP or define a new AVP value. Of course, new applications shouldattempt to reuse AVPs defined in existing applications always when possible.
In order to create a new AVP, a request must be sent to IANA, with a specification forthis AVP. The request must include the commands that would make use of this AVP.
The Version field MUST be set to 1 to indicate Diameter Version 1
Message Length
The Message Length field is three octets and indicates the length of the Diametermessage including the header fields.
Command-Code
The Command-Code field is three octets, and is used to identify Diametercommands. Every Diameter message MUST contain a command code in its header's
Command-Code field, which is used to determine the action that is to be taken for aparticular message. Both the request and the answer for a given command share thesame command code.
Command Flags
The Command Flags field consists of eight bits.:
R P E T r r r r
R(equest) or REQ
If set, the message is a request. if cleared, the message is an answer.
P(roxiable) or PRXIf set, the message MAY be proxied, relayed or redirected. If cleared, themessage MUST be locally processed.
E(rror) or ERR
If set, the message contains a protocol error. This bit MUST NOT be set in therequest messages.
T(Potentially re-transmitted message)
This flag is set after a link failover procedure, to aid the removal of duplicaterequests. It is set when resending requests not yet acknowledged, as an
indication of a possible duplicate due to a link failure. This bit MUST be cleared
when sending a request for the first timer(eserved)
These flag bits are reserved for future use, and MUST be set to zero, and ignored
The Application-ID is four octets and is used to identify a specific Diameter
Application (the meaning of application is protocol!) to which the message isapplicable. The application can be an authentication application, an accountingapplication or a vendor specific application.
There are standards-track application ids and vendor specific application ids. IANAhas assigned the range 0x00000001 to 0x00ffffff for standards-track applications; and0x01000000 - 0xfffffffe for vendor specific applications.
The following values are allocated for standard Applications:
- Diameter Common Messages: 0
- NASREQ: 1 [NASREQ]
- Mobile-IP: 2 [DIAMMIP]
- Diameter Base Accounting: 3
Some Identifiers for Vendor-Specific Application:
Gq protocol: the Application-Id 16777222, vendor is 3GPP (10415)
Gx protocol: the Application-Id=16777238, vendor is 3GPP (10415)
Gy protocol: the Application-Id=4, vendor is 3GPP (10415)
Hop-by-Hop Identifier
The Hop-by-Hop Identifier is an unsigned 32-bit integer field and aids in matchingrequests and replies. The sender of an Answer message must ensure that the Hop-
by-Hop Identifier field contains the same value that was found in the correspondingrequest. The Hop-by-Hop identifier is normally a monotonically increasing number,whose start value was randomly generated. An answer message that is received withan unknown Hop-by-Hop Identifier MUST be discarded.
End-to-End Identifier
The End-to-End Identifier is an unsigned 32-bit integer field and is used to detectduplicate messages. Senders of request messages MUST insert a unique identifieron each message. The same End-to-End identifier of the request is used in the
answer. Duplicate requests should cause the same answer to be transmitted.
Every message must contain one Command Code and Command Flags. EachRequest/Answer pair gets the same Command Code value. According to the flagfield (R bit) the request or the answer is identified.
Error-Flag:
If set in an Answer message, the originating Request contained a
The Device-Watchdog-Request (DWR) is sent to a peer when no traffic has beenexchanged between them. Upon detection of a transport failure, this message mustnot be sent.
Command Code 280;
REQ - set
Device-Watchdog-Answer (DWA) Command
DWA is sent as a response to the Device-Watchdog-Request message.
Watchdog timer is applicable for all the diameter interfaces defined in PCS-5000system. Timer is a configurable value (PCS_ServiceConfigParams, Gx-Interface, Gy-Interface…). The duration of the watchdog interval is in seconds. On expiry of the
timer, PCS-5000 sends a watchdog request to check the health of the diameterconnection.
Default value: 6 sec.
Range: 0-30 sec.
Watchdog Failure Handling
Diameter retries for 6 times before initiating any disconnect procedures. In case ofPCS-5000 failing to get DWA, then will initiate a Disconnect-peer-request towards theGGSN, if TCP connection exists. Otherwise, all the peer information will be deletedand PCS-5000 shifts back to the listening mode for new connections.
AVPs carry specific details for the request and reply. Some AVPs may be listed morethan once. AVP consists of a Header, called AVP Header, followed by AVP Data
AVP Header
AVP Header consists of:
AVP Code
AVP Length
AVP Flags
Vendor Id
AVP Code
The AVP Code, combined with the Vendor-Id field, identifies the attribute uniquely. AVP numbers 1 through 255 are reserved for backward compatibility with RADIUS,without setting the Vendor-Id field. AVP numbers 256 and above are used for
Diameter. They are allocated by IANA.
AVP Flags
The AVP Flags field informs the receiver how each attribute must be handled.
V - Vendor-Specific bit indicates whether the optional Vendor-ID field is present in
the AVP header. When set, the AVP Code belongs to the specific vendor codeaddress space.
M - Mandatory bit indicates that support of the AVP is required. If an AVP with the'M' bit set is received by a Diameter agent and either the AVP or its value isunrecognized, the message must be rejected.
AVPs with the 'M' bit cleared are informational only and a receiver that receives amessage with such an AVP that is not supported, or whose value is not supported,may simply ignore this AVP.
P- Protected bit indicates the need for encryption for end-to-end security.
The AVP Length field consists of three octets. It and indicates the number of octets inthis AVP including the AVP Code, AVP Length, AVP Flags, Vendor-ID field (if
present) and the AVP data. If a message is received with an invalid attribute length,the message should be rejected.
Vendor-ID
The Vendor-ID field is present if the 'V' bit is set in the AVP Flags field. The optionalfour-octet Vendor-ID field contains the IANA assigned value. Any vendor wishing toimplement a vendor-specific Diameter AVP MUST use his own Vendor-ID along with
The Data field is length of several octets and contains information specific to the
Attribute. The format and length of the Data field is determined by the AVP Code and AVP Length fields. The format of the Data field must be one of the base data types ora data type derived from the base data types.
Some Basic AVP Data Formats
OctetString
The data contains arbitrary data of variable length. AVP Values of this type that are
not a multiple of four-octets in length is followed by the necessary padding so that the
next AVP (if any) will start on a 32-bit boundary. Each AVP of type OctetString MUSTbe padded to align on a 32-bit boundary, while other AVP types align naturally. Anumber of zero-valued bytes are added to the end of the AVP Data field till a wordboundary is reached. The length of the padding is not reflected in the AVP Lengthfield.
Unsigned32
32 bit unsigned value. The AVP Length field must be set to 12 (16 if the 'V' bit isenabled).
Integer32
32 bit signed value, in network byte order. The AVP Length field must be set to 12
(16 if the 'V' bit is enabled).Grouped
The Data field is specified as a sequence of AVPs. Each of these AVPs is presentedwith their headers and AVP Data. The AVP Length field is set to 8 (12 if the 'V' bit is
enabled) plus the total length of all included AVPs, including their headers and AVPData. Thus the AVP length field of an AVP of type Grouped is always a multiple of 4.
It is possible to include an AVP with a Grouped type within a Grouped type, that is, tonest them. If any of the AVPs encapsulated within a Grouped AVP has the 'M'(mandatory) bit set, the Grouped AVP itself MUST also include the 'M' bit set.
Some Derived AVP Data Formats
UTF8String
The UTF8String format is derived from the OctetString AVP Base Format. This is ahuman readable string represented using the ISO/IEC IS 10646-1 character set,encoded as an OctetString using the UTF-8 [UFT8] transformation format describedin RFC 2279.
The DiameterIdentity (DiamIdent) format is derived from the OctetString AVP BaseFormat. The DiameterIdentity value is used to uniquely identify a Diameter node for
purposes of duplicate connection and routing loop detection. The contents of thestring MUST be the FQDN of the Diameter node.
Enumerated
Enumerated is derived from the Integer32. For AVPs of type Enumerated anapplication may require a new value to communicate some service-specificinformation. In order to allocate a new AVP value, a request must be sent to IANA,
along with an explanation of the new AVP value.
IPFilterRule
The Address format is derived from the OctetString AVP Base Format. It represents,for example a 32-bit (IPv4) or 128-bit (IPv6) address, most significant octet first. Thefirst two octets of the Address AVP represent the AddressType, which contains an Address Family. The AddressType is used to discriminate the content and format ofthe remaining octets.
The Auth-Application-Id AVP (AVP Code 258) is of type Unsigned32 and is used inorder to advertise support of the Authentication and Authorization portion of anapplication
The Origin-Host AVP (AVP Code 264) is of type DiameterIdentity, and MUST bepresent in all Diameter messages. This AVP identifies the endpoint that originatedthe Diameter message. Relay agents MUST NOT modify this AVP. The value of theOrigin-Host AVP is guaranteed to be unique within a single host.
The Session-Id AVP (AVP Code 263) is of type UTF8String and is used to identify aspecific session. All messages pertaining to a specific session must include only oneSession-Id AVP and the same value must be used throughout the life of a session.The Session-Id must uniquely identify a user session without reference to any otherinformation. The Session-Id includes a mandatory portion and an implementation-defined portion.
The Session-Id is created by the Diameter application initiating the session, which inmost cases is done by the client.
1.5.1 Result codes at Diameter Base protocolEvery response command in Diameter carries a Result-Code AVP. The receiver ofthe command can use this AVP in the message to check how the previous command
was processed.
Two different types of errors in Diameter protocol are possible:
protocol errors: occur at the base protocol level (e.g.:DIAMETER_UNABLE_TO_DELIVER
application errors: occur due to a problem with a function specified in a Diameterapplication (e.g.: DIAMETER_MISSING_AVP)
The Result-Code AVP (AVP Code 268) is of type Unsigned32 and indicates whethera particular request was completed successfully or whether an error occurred. AllDiameter answer messages must include one Result-Code AVP. A non-successful
Result-Code AVP contains a non 2xxx value.
Result-Code AVP values that are used to report protocol errors must only be present
in answer messages whose 'E' bit is set. Result-Code AVP is set to the appropriateprotocol error value.
Diameter provides the following classes of errors, all identified by the thousands digitin the decimal notation:
The Experimental-Result AVP (AVP Code 297) is of type Grouped. It indicates
whether a particular vendor-specific request was completed successfully or whetheran error occurred.
Experimental-Result ::= < AVP Header: 297 >
{ Vendor-Id }
{ Experimental-Result-Code }
The Vendor-Id AVP identifies the vendor responsible for the assignment of the resultcode which follows. All Diameter answer messages defined in vendor-specific
applications MUST include either one Result-Code AVP or one Experimental-Result
AVP.The Experimental-Result-Code AVP (AVP Code 298) is of type Unsigned32 andcontains a vendor-assigned value representing the result of processing the request.
It is recommended that vendor-specific result codes follow the same conventionsgiven for the Result-Code AVP regarding the different types of result codes and thehandling of errors (for non 2xxx values).
Gx reference pointThe Gx reference point is located between the Policy and Charging Rules Function(PCRF) and the Policy and Charging Enforcement Function (PCEF). The Gx
reference point is used for provisioning and removal of Policy and Charging Control(PCC) rules from the PCRF to the PCEF and the transmission of traffic plane eventsfrom the PCEF to the PCRF. The Gx reference point can be used for charging
control, policy control or both by applying AVPs relevant to the application.Gx reference point is specified in:
the stage 2 specifications, functional requirements:3GPP TS 23.203 - Policy and charging control architecture and
the stage 3 specifications, Technical specification:3GPP TS 29.212 - Policy and Charging Control over Gx interface
PCRFThe PCRF is a functional element that is responsible for policy control decision andflow based charging control.The PCC Rule decisions may be based on one or more of the following:
Information received from the AF via the Rx reference point, e.g. the session,media and subscriber related information.
Information obtained from the PCEF via the Gx reference point, e.g. IP-CAN
bearer attributes, request type and subscriber related information. Information obtained from the SPR via the Sp reference point, e.g. subscriber and
service related data.
Own PCRF pre-configured information.
The PCRF shall report events to the AF via the Rx reference point.The PCRF shall inform the PCEF through the use of PCC rules on the treatment ofeach service data flow that is under PCC control, in accordance with the PCRF policydecision.
PCEF
The PCEF is the functional element that performs policy enforcement and flow basedcharging functionalities. This function is located at the Gateway (e.g. GGSN in the
GPRS case). It provides control over the user plane traffic handling at the Gatewayand its QoS, and provides service data flow detection and counting as well as onlineand offline charging interactions.If requested by the PCRF, the PCEF shall report to the PCRF when the status of therelated service data flow changes. This procedure can be used to monitor an IP-CANbearer dedicated for AF signaling traffic.
Request and Provisioning of PCC rulesThe PCRF shall indicate, via the Gx reference point, PCC rules to be applied at thePCEF. This may be done by using one of the following procedures:
PULL procedure (Provisioning solicited by the PCEF): In response to a request forPCC rules being made by the PCEF (CC-Request), the PCRF shall provision PCC
rules in the CC-Answer.
PUSH procedure (Unsolicited provisioning): The PCRF may decide to provisionPCC rules without obtaining a request from the PCEF, e.g. in response toinformation provided to the PCRF via the Rx reference point, or in response to aninternal trigger within the PCRF. To provision PCC rules without a request from thePCEF, the PCRF shall include these PCC rules in an RA-Request (Re-Auth-
Request) message.
The PCEF shall select a PCC rule for each received downlink and uplink IP packet
within an IP CAN session
Policy Control 3GPP Reference Architecture
PCEF
Rx
Sp
Gy
Gz
Gx
SPR
OCS
UE
OFCS
AF
PCRF
AF: Aplication Function
PCRF: Policy and ChargingRule Function
SPR: Subscription Profile Repository
OCS: Online Charging SystemOFCS: Offline Charging SystemUE: User Equipment
The Gx application is defined as a vendor specific Diameter application, where thevendor is 3GPP and the Application-ID for the Gx Application in the present releaseis 16777238. The vendor identifier assigned by IANA to is 10415.
With regard to the Diameter protocol defined over the Gx interface, the PCRF acts asa Diameter server, in the sense that it is the network element that handles PCC Rulerequests for a particular realm. The PCEF acts as the Diameter client, in the sense
that is the network element requesting PCC rules in the transport plane networkresources
2.3 MessagesExisting Diameter command codes from the Diameter base protocol RFC 3588 [5]and the Diameter Credit Control Application RFC 4006 [9] are used with the Gxspecific AVPs.
A Gx specific Auth-Application id is used together with the command code to identifythe Gx messages.
The CCR command, indicated by the Command-Code field set to 272 and the 'R' bit
set in the Command Flags field, is sent by the PCEF to the PCRF in order to requestPCC rules for a bearer. The CCR command is also sent by the PCEF to the PCRF inorder to indicate bearer or PCC rule related events or the termination of the IP CANbearer and/or session.
Indicates the bearer event that causesa request for PCC rules
TERMINATION (0)
ESTABLISHMENT(1)
MODIFICATION(2)
Framed-IP-Address(8) The valid routable IPv4 address thatis applicable for the IP Flows towardsthe UE at the PCEF. The PCRF shalluse this address to identify the correct
IP-CAN session (session binding).
127.0.3.54
IP-CAN-Type(1027) the type of Connectivity AccessNetwork in which the user is conn.
The CCA command, indicated by the Command-Code field set to 272 and the 'R' bit
cleared in the Command Flags field, is sent by the PCRF to the PCEF in response tothe CCR command. It is used to provision PCC rules and event triggers for thebearer/session and to provide the selected bearer control mode for the IP-CANsession. If the PCRF performs the bearer binding, PCC rules will be provisioned at
bearer level. The primary and secondary CCF and/or primary and secondary OCSaddresses may be included in the initial provisioning.
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 PCEF in order toprovision PCC rules using the PUSH procedure initiate the provision of unsolicitedPCC rules. It is used to provision PCC rules and event triggers for the session. If thePCRF performs the bearer binding, PCC rules will be provisioned at bearer level.
When event trigger is sent from the PCRF to the PCEF the Event-Trigger AVP
indicates an event that shall cause a re-request of PCC rules. When sent from thePCEF to the PCRF the Event-Trigger AVP indicates that the corresponding event hasoccurred at the gateway.
Example:
Event Trigger Name Code
SGSN_CHANGE 0
QOS_CHANGE 1
RAT_CHANGE 2
TFT_CHANGE 3
PLMN_CHANGE 4
LOSS_OF_BEARER 5
RECOVERY_OF_BEARER 6
IP-CAN_CHANGE 7`
QOS_CHANGE_EXCEEDING_AUTHORIZATION 11
RAI_CHANGE 12
USER_LOCATION_CHANGE 13
NO_EVENT_TRIGGERS 14
OUT_OF_CREDIT 15
REVALIDATION_TIMEOUT 17
USAGE_REPORT 26
In the PCS_GeneralConfigParams.xml file operator can specify set of default eventtriggers.
Answer timerThe timer is initiated by the PCS-5000 as protection against non-receipt of responsesfor any session based scenarios. Answer Timer is a configurable value(PCS_GeneralConfigParams, Gx-Interface, Answer-Timer_ms). The value of thetimer is configured in milliseconds.
Default value: 2000.
Range: 500-65535
Example: after RAR message, RAA is not received.
Session Release Delay Timer
The timer is initiated by the PCS-5000 in case of any diameter connection gettingdisconnected with the peer. PCS waits for the configured duration, before terminatingall the sessions related to the peer.
If the reconnection is successful before the timer expires, all the sessions aremaintained in the PCS-5000 for the peer.
The value should be grater then the maximum Gx reconnection time configured onthe PCEF (GGSN).
Timer is a configurable value (PCS_GeneralConfigParams, Gx-Interface, Session-
Release-Delay-Timer_ms).
The value of the timer is configured in milliseconds.
Tunnel-Information 1038 5.3.36 Grouped V P M Y All(NOTE 8)
BothRel8
RAT-Type 1032 5.3.31 Enumerated V P M Y All(NOTE 4)
BothRel8
Revalidation-Time 1042 5.3.41 Time M,V P Y All BothRule-Activation-Time 1043 5.3.42 Time M,V P Y All Both
Usage-Monitoring-Information 1067 5.3.60 Grouped V P M Y All BothRel9
Rule-Deactivation-Time 1044 5.3.43 Time M,V P Y All Both
Usage-Monitoring-Level 1068 5.3.61 Enumerated V P M Y All BothRel9
Usage-Monitoring-Report 1069 5.3.62 Enumerated V P M Y All BothRel9
Usage-Monitoring-Support 1070 5.3.63 Enumerated V P M Y All BothRel9
NOTE 1: The AVP header bit denoted as 'M', indicates whether support of the AVP is required. The AVP header bitdenoted as 'V', indicates whether the optional Vendor-ID field is present in the AVP header. For furtherdetails, see RFC 3588 [4].
NOTE 2: The value types are defined in RFC 3588 [4].NOTE 3: AVPs marked with "CC" are applicable to charging control, AVPs marked with "PC" are applicable to policy
control and AVPs marked with "Both" are applicable to both charging control and policy control.NOTE 4: RAT-Type AVP applies to 3GPP, Non-3GPP-EPS, and 3GPP2 access types.NOTE 5: This AVP does not apply to 3GPP-GPRS access type.NOTE 6: The 3GPP2 usage is defined in 3GPP2 X.S0062 [30]. Non-3GPP-EPS usage applies to GTP based S2b,NOTE 7: This AVP only applies to case 2b as defined in 3GPP TS 29.213 [8].NOTE 8: This AVP only applies to case 2a as defined in 3GPP TS 29.213 [8].NOTE 9: AVPs marked with "Rel8", "Rel9" or "IFOM" are applicable as described in clause 5.4.1.
1. The GW receives an Establish IP-CAN (IP Connectivity Access Network SessionRequest). After this step, UE has been assigned an IP address
2. The GW informs the PCRF of the establishment of the IP-CAN Session bysending a CCR. CC-Request-Type AVP is set to the value INITIAL_REQUEST.
The GW provides following information: UE identity information and/or the UE IPaddress types of IP-CAN, QoS.
3. The PCRF stores the information received in the Diameter CCR.
4. If the PCRF requires subscription-related information and does not have it, thePCRF sends a request to the SPR in order to receive the information.
5. The SPR replies with the subscription related information containing theinformation about the allowed service(s), QoS information and PCC Rulesinformation.
6. The PCRF selects PCC Rule(s) to be installed:The PCRF decides whether service flows described in the PCC Rules are to beenabled or disabled. If it is enabled, derives an authorized QoS.
Selected PCC Rules are stored.
7. The PCC Rules are provisioned by the PCRF to the GW using Diameter CCA.
8. The GW installs the received PCC Rules. The GW also enforces the authorizedQoS and enables or disables service flow according to the flow status of the
corresponding PCC Rules.
9. The GW sends a response to the Establish IP-CAN Session Request.For GPRS, the GGSN accepts the PDP Context Request based on the results ofthe authorization policy decision enforcement. If the requested QoS parametersdo not correspond to the authorized QoS, the GGSN adjusts (downgrades/upgrades) the requested QoS parameters to the authorized values.
1. The GW receives a Remove IP-CAN Session Request.
2. The GW sends a Diameter CCR message to the PCRF, indicating the IP-CANSession termination. The GW requests the termination of the session using theCC-Request-Type AVP set to the value TERMINATION_REQUEST.
3. The PCRF stores the information received in the Diameter CCR.
4. If the PCRF requires subscription-related information and does not have it, thePCRF sends a request to the SPR in order to receive the information.
5. The SPR replies with the subscription related information.
6. The PCRF performs policy evaluation
7. Result of policy evaluation can be update of SPR. Then PCRF sends Update
Request. SPR sends as response8. Update Response.
9. The PCRF acknowledges the session termination by sending a Diameter CCAmessage.
10. The GW sends a response to the Remove IP-CAN Session Request.:
Similar is when the initiator for the session termination is GW. Messages betweenPCRF and GW are the same.
1. The PCRF detects that the termination of an IP-CAN Session is required.
2. The PCRF sends a Diameter RAR to request that the GW removes all PCCRules previously installed for the IP CAN session and deactivates all PCC rulespreviously activated for the IP CAN session.
3. The GW removes the identified PCC Rules.
4. The GW sends RAA to acknowledge the RAR.
5. The GW sends a Remove IP-CAN Session Request that request the deactivation
of the IP-CAN Session.
6. The GW receives a response to the Remove IP-CAN Session Request.
7. The GW sends a Diameter CCR message to the PCRF. CC-Request-Type AVP
set to the value TERMINATION_REQUEST.8. The PCRF identifies AF sessions that are bound to IP flows of the removed IP-
CAN Session.
9. The PCRF acknowledges the session termination by sending a Diameter CCAmessage.
Not in the diagram:
Like in previous case, after CCR, PCRF will perform Policy Evaluation. Result ofpolicy evaluation can be update of SPR. Then PCRF sends Update Request andSPR sends as response Update Response.
1. The PCRF receives an internal or external trigger (e.g. from AF) to re-evaluate
PCC Rules and policy decision for an IP-CAN Session.
2. The PCRF selects the PCC Rule(s) to be installed, modified or removed for theIP-CAN Session.
3. The PCRF stores the updated PCC Rules.
4. The PCRF sends a Diameter RAR to request that the GW installs, modifies orremoves PCC Rules and updates the policy decision.
5. The GW installs, modifies or removes the identified PCC Rules. The GW alsoenforces the authorized QoS and enables or disables service flow according tothe flow status of the corresponding PCC Rules.
6. The GW sends RAA to acknowledge the RAR. The PCEF informs the PCRFabout the outcome of the PCC rule operation
7. For GPRS, the GGSN initiates the procedure to Create/Update or TerminatePDP Context Request message to the SGSN.
8. The GW sends the notifications needed to the PCRF. The notification is made byusing a CCR messages with the needed AVPs.
9. The PCRF stores the information coming in the notification and acknowledgesthe CCR with a CCA command.
Rx reference pointThe Rx reference point is located between the PCRF and the AF. The Rx referencepoint is used to exchange application level session information between the Policyand Charging Rules Function (PCRF) and the Application Function (AF).
Rx reference point is specified in:
3GPP TS 29.214 - Policy and Charging Control over Rx reference point
Application Function (AF) is element offering application(s) that require the Policyand Charging Control of traffic plane resources The AF use the Rx reference point toprovide session information to the PCRF.
One example of an application function is the P-CSCF.
PCRFThe PCRF is a functional element that is responsible for policy control decision andflow based charging control.The PCC Rule decisions may be based on one or more of the following:
Information received from the AF via the Rx reference point, e.g. the session,
media and subscriber related information.
Information obtained from the PCEF via the Gx reference point, e.g. IP-CANbearer attributes, request type and subscriber related information.
Information obtained from the SPR via the Sp reference point, e.g. subscriber andservice related data.
Own PCRF pre-configured information.
The PCRF shall report events to the AF via the Rx reference point.The PCRF shall inform the PCEF through the use of PCC rules on the treatment ofeach service data flow that is under PCC control, in accordance with the PCRF policydecision.
The Rx application is defined as a vendor specific Diameter application, where thevendor is 3GPP and the Application-ID is 16777236. The vendor identifierassigned by IANA to is 10415.
With regard to the Diameter protocol defined over the Rx interface, the PCRF acts asa Diameter server, in the sense that it is the network element that handles PCC Rulerequests for a particular realm. The AF acts as the Diameter client, in the sense that
is the network element requesting PCC rules in the transport plane networkresources
3.3 MessagesExisting Diameter command codes from the Diameter base protocol RFC 3588 [5]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 identifythe Rx messages.
Diameter messages supported by PCS:
Message from PCS to PCS
Diameter Base MessagesCapabilities-Exchange-Request (CER) X
UTF8String. Used to identify a specific session; must begin
with the sender's identity.
Auth-Application-Id Unsigned32. Must contain the Rx application identifier(16777236).
{ Origin-Host }
(AVP Code 264)Diameter Identity. The host name of the system where themessage originated.
{ Origin-Realm }
(AVP Code 296) Diameter Identity. The PCS5000 domain name.
{ Destination-Realm }
(AVP Code 283) Diameter Identity. The PCS5000 domain name.
[ Destination-Host ]
(AVP Code 293) Diameter Identity. The hosts name of the system whereexactly the destination of the message is.
[AF-Application-Identifier ]
(AVP code 504)OctetString. Identifies the particular service that the AFservice session belongs to
*[ Media-Component-Description ]
(AVP code 517)
Grouped. Contains service information for a single mediacomponent within an AF session or the AF signaling
information
[Service-Info-Status ]
(AVP code 527)
Enumerated. Indicates the status of the service informationthat the AF is providing to the PCRF. If the Service-Info-Status AVP is not provided in the AA request, the value FINAL
SERVICE INFORMATION shall be assumed
[ AF-Charging-Identifier ]
(AVP code 505)
OctetString. Contains the AF Charging Identifier that is sent bythe AF. This information may be used for charging correlation
with bearer layer
[ SIP-Forking-Indication ] (AVP code523) Enumerated, and describes if several SIP dialogues are
related to one Diameter session
*[ Specific-Action ]
(AVP code 513)Enumerated
*[ Subscription-ID ]The identification of the subscription (IMSI, MSISDN, etc.)
[ Reservation-Priority ]Vendor-id: ETSI (13019) [15]..
[ Framed-IP-Address ] The valid routable IPv4 address that is applicable for the IPFlows towards the UE at the PCEF. The PCRF shall use thisaddress to identify the correct IP-CAN session (session
binding).
[ Service-URN ]
(AVP code 525)OctetString. Indicates that an AF session is used for
The AAA command, indicated by the Command-Code field set to 265 and the 'R' bitcleared in the Command Flags field, is sent by the PCRF to the AF in response to the AAR command.
The RAR command, indicated by the Command-Code field set to 258 and the 'R' bitset in the Command Flags field, is sent by the PCRF to the AF in order to indicate anRx specific action.
(AVP Code 263)UTF8String. Used to identify a specific session; must begin with the
sender's identity.
{ Origin-Host }
(AVP Code 264)
Diameter Identity. The host name of the system where the message
originated.
{ Origin-Realm }
(AVP Code 296) Diameter Identity. The PCS5000 domain name.
{ Destination-Realm }
(AVP Code 283) Diameter Identity. The PCS5000 domain name.
[ Destination-Host ]
(AVP Code 293)Diameter Identity. The hosts name of the system where exactly thedestination of the message is.
Auth-Application-Id (AVP code 504) is of type OctetString, and it contains information thatidentifies the particular service that the AF service session belongs to
{ Specific-Action }
(AVP code 513) Enumerated
*[ Flows ]
(AVP code 510)Grouped. Indicates IP flows via their flow identifiers
*[ Access-Network-Charging-Identifier ]
(AVP Code 502) Grouped
[ Access-Network-
Charging-Address ]
(AVP Code 502) Address
[ Abort-Cause ]
(AVP code 500)
The Session-Abort-Cause AVP is of type Enumerated, anddetermines the cause of an abort session request (ASR) or of a RAR
indicating a PDP context release
[ IP-CAN-Type ] IP-CAN type of the user
[ 3GPP-RAT-Type ]Indicate which Radio Access Technology is currently serving the UE.