Sample Diameter

Diameter Protocol Support
7retpahC
This chapter contains the following topics:
+ Overview
+ Diameter Architecture
+ Diameter Network Deployment
+ Diameter Converged Network
+ Product Implementation: Protocol Compliance
+ Product Solution Implementation: Diameter Messages and Parameter Mapping
+ Sequence Diagrams
Revision 02 108
----------------------------------------------------------------
Overview
The Diameter protocol is a popular AAA (Authentication, Authorization and Accounting) protocol for
next-generation services in IP networks. The Diameter base protocol (RFC 3588) and Diameter
applications, which build on the basic standard to enable services such as IP mobility, SIP
authentication, and online charging, were developed by the IETF (Internet Engineering Task Force) to
overcome several limitations of the legacy RADIUS protocol. Diameter has better failover mechanisms,
better processor efficiency through alignment, and support for vendor-specific commands and
attributes than RADIUS.
Diameter has been selected by 3GPP (3rd Generation Partnership Project) as the standard for AAA
functions and SIP for session management and service control. 3GPP has added several extensions to
support AAA functions in the IMS (IP Multimedia Subsystem), which defines a set of reference points
between different IMS entities that can use Diameter to exchange subscription-, presence-, and billing-
related messages. Diameter provides a flexible, reliable, scalable AAA framework that addresses major
security concerns for next-generation networks and complements SIP and SS7 signaling protocols.
With Product 11.0, support for Diameter is limited to supporting access for and providing real-time
credit control and charging for data services, such as GPRS and SMS, in IP networks (Phase 1). The
Credit Control Application (CCA) utilizes mechanisms provided by Diameter to provide online and
offline charging support for event-based and session-based services, with and without credit
reservations.
Revision 02 109
----------------------------------------------------------------
Diameter Architecture
Diameter is defined in terms of a base protocol and a set of applications. This design allows the
protocol to be extended to new access technologies. The Diameter base protocol must be used in
conjunction with a Diameter application - for example, MIP (Mobile IPv4), NASREQ, or CCA as
shown in the following figure.
Figure 7-5 Diameter Architecture
Revision 02 110
----------------------------------------------------------------
Diameter Converged Network

The following diagram shows a typical converged data services network (GSM and IP).
Figure 7-6 Typical GSM and IP Converged Data Services Network
Revision 02 111
----------------------------------------------------------------
Diameter Network Deployment

The following diagram represents a typical network layout of a Diameter AAA network. From a
network perspective, Product is the Diameter Server. The black lines indicate all possible interactions
between the Product system and other Diameter network entities. The red line indicates the currently
implemented interaction between the Diameter Client and Product 11.0.
Figure 7-7 Typical Diameter Network
Glossary of Terms
Term Definition
Client A Diameter Client is a device at the edge of the network that performs access
control. Examples of Diameter Clients are Network Access Servers (NAS),
mobility agents (foreign agents), and credit control client applications.
Server A Diameter Server is a server that handles authentication, authorization, and

accounting requests for a particular realm.
Relay Agent A relay agent routes Diameter messages based on information found in the
messages. This routing decision is performed using a list of supported realms
and known peers. Relay agents are largely transparent. A relay agent can
modify Diameter messages only by inserting and/or removing routing
information, but cannot modify any other portion of a message.
Proxy Agent A proxy agent also routes Diameter messages. However, a proxy agent may
modify messages to implement policy decisions, such as controlling resource
usage, providing admission control, and provisioning.
Revision 02 112
----------------------------------------------------------------
Term Definition
Redirect Agent A redirect agent also provides a routing function, generally acting as a
centralized source of Realm/Server address mappings for members of a
roaming consortium. Unlike the other agents that relay requests, a redirect
agent returns a special type of answer message to the peer that sent the
request. This answer message contains routing information that allows the
peer to send the request again, directly to the correct destination server. The
redirect agent is then out of the routing path; a redirect agent does not relay
requests.
Translation Agent A translation agent translates between two protocols, such as RADIUS and
Diameter. In this case, the translation agent supports a RADIUS to Diameter
migration, allowing server conversions to Diameter, for example, while
permitting the NAS to be converted at a slower pace.
Revision 02 113
----------------------------------------------------------------
Product Implementation: Protocol Compliance

Product has developed a TCP/IP-based server application, Diameter Interface Server, to interface to
external Diameter Client nodes / applications. The Diameter Interface Server comprises three main
components - External Protocol Adaptor (EPA), Gateway, and the Internal Protocol Adaptor (IPA).
This server application is compliant to Diameter protocol specifications as follows, and interacts with
the GCE system to achieve charging and accounting functionalities. The interaction between the
Diameter Interface Server and GCE rater applications is conducted over the message center (INI)
framework.
Product 11.0 is compliant with the following specifications:
+ RFC 3588
+ Diameter Credit Control Application (IETF DRAFT)
+ 3GPP TS 32.299 - Diameter Charging Applications
RFC 3588
Requirement Category: Mandatory
The application is compliant to the RFC 3588 IETF Diameter Base Protocol specifications. This
specification, being driven by the IETF AAA Working Group, is intended to provide an AAA
framework for applications dealing with network access, data charging, IP mobility, etc.
Features Supported
+ TCP/IP Transport Mechanism
+ Interactions with external Diameter Clients
+ Accounting Functionality for offline charging and accounting functionality
+ Accounting Request (ACR)
+ Accounting Answer (ACA)
+ Capabilities Exchange with Diameter Clients only
+ Capabilities Exchange Request (CER)
+ Capabilities Exchange Answer (CEA)
+ Disconnecting Peer Connections
+ Disconnect Peer Request (DPR)
+ Disconnect Peer Answer (DPA)
+ Transport Failure Detection
+ Device Watchdog Request (DWR)
+ Device Watchdog Answer (DWA)
+ Duplicate Detection (Vide T Flag support)
Features Not Supported
+ Interactions with Diameter Agents (Relay, Proxy, Redirect, Translation)
+ Authorization and Authentication Functionality
Revision 02 114
----------------------------------------------------------------
+ SCTP Transport Mechanism

+ Diameter Security (IPSec, TLS, Peer-to-Peer considerations, etc.)
+ Peer Discovery (Dynamic and Static)
+ Failover and Failback Procedures
+ Reauthorization (RAR - RAA)
+ Session Termination (STR - STA)
+ Session Abort (ASR - ASA)
Diameter Credit Control Application (IETF DRAFT)

The application is compliant to the IETF Draft specifications - Diameter Credit-Control Application.
This specification, being driven by the IETF AAA Working Group, specifies a Diameter application
that can be used to implement real-time credit control and charging functionalities for a variety of end-
user data services such as network access, messaging services, download services, content-based
services, etc.
Features Supported
+ Credit Control Messages for online charging functionality
+ Credit Control Request (CCR)
+ Credit Control Answer (CCA)
+ Session-Based Credit Control
+ One-Time Event
+ Server Initiated Credit Reauthorization.
+ Failover procedures
+ Multiple Services (within a sub-session) Credit Control
+ Tariff Change Mechanism
3GPP TS 32.299 - Diameter Charging Applications

The application is compliant to the 3GPP TS 32.299 specifications - Diameter Charging Application.
This standard lays out the details of charging functionality and charging management in GSM / UMTS
networks.
Features Supported
+ Basic Online Charging Scenarios
+ Immediate Event Charging for online data services:
– Direct Debiting
– Balance Check
Revision 02 115
----------------------------------------------------------------
– Service Price Inquiry

– Refund
+ Event Charging with Reservation
+ Session Charging with Reservation
– Basic Offline Charging Scenarios
– Event-Based Charging
– Session-Based Charging

+ Reauthorizations
+ Threshold based Reauthorization triggers
+ Termination Action
+ Support of tariff changes during an active session
+ Quota Consumption Time
Revision 02 116
----------------------------------------------------------------
Product Solution Implementation: Diameter Messages and Parameter

Mapping
Capabilities Exchange
On receiving a client socket connection from an external Diameter Client, the Diameter Interface
Server EPA component will initialize the state of the data stream to OPEN, and start a timer TCER.
On timer expiration, the connection is forcibly terminated and all resources allocated to the stream are
released. The TCER timer is stopped after receipt of the Capabilities-Exchange-Request message. Also,
the state of the data stream is changed to CONNECTED.
Capabilities Exchange Request (CER) Message

This message is receivable only in the data stream state OPEN. If this message is received in any other
state, it is silently discarded. The error handling related to this ignore factor will be handled by the
external Diameter Client. On successful receipt of the message, the EPA will create an entry in the
inbound transaction table for the session. This record will remain alive for the duration of the session.
As part of the transaction record creation, the timer TCER is started. The value for this timer is system
configurable.
Attribute-Value-Pair Usage Description
(AVP)
Origin-Host Yes Validated against list of configured hosts.
Origin-Realm Yes Validated against list of configured realms.
Host-IP-Address Yes IP Address received in this AVP is stored as part of
the transaction table. It may be possible to use this as
Node-Id for all messages in this particular session.
Vendor-Id No May be used only for logging and informational
purposes.
Product-Name No May be used only for logging and informational
purposes.
Origin-State-Id No Unused.
Supported-Vendor-Id No May be used only for logging and informational
purposes.
Auth-Application-Id No Unused.
Inband-Security-Id No Unused as security is not supported in Phase 1.
Acct-Application-Id Yes Validated against the 3GPP defined value [1].
Vendor-Specific- Yes Validated against the 3GPP defined value [10415].
Application-Id
Firmware-Revision No May be used only for logging and informational
purposes.
AVP TBD Need confirmation from Vendor as to whether vendor
specific AVPs will be included as part of this AVP
and whether we will be required to support them in
subsequent messages.
Successful Processing
The CER message is completely processed by the Diameter Interface Server EPA component. The
processing is not propagated to the Gateway and IPA components. On successful processing of the
CER message and validation of received and required AVPs:
+ TCER timer is stopped.
Revision 02 117
----------------------------------------------------------------
+ Data stream connection state is set to CONNECTED.

+ The inbound transaction table is updated with the Host-IP-Address AVP.
+ CEA message is sent to the Diameter peer.
Unsuccessful Processing
Unsuccessful processing may result from missing AVPs, unsupported values in AVPs, and unknown
hosts and / or realms. On unsuccessful processing of the CER message:
+ TCER timer is stopped.
+ CEA message (with appropriate error code) is sent to the Diameter peer.
+ Data stream connection is closed.
+ All resources allocated to the stream (transaction record etc.) are released.
TCER Timer Expiration
On timer expiration, the data stream connection is closed and all resources allocated to the stream
(transaction record, etc.) are released.
Capabilities Exchange Answer (CEA) Message

The CEA message consists of the following AVP listing:
(AVP)
Result-Code Yes Populated on the basis of the processing results.
[As defined in RFC-3588, Section 7.1]. Protocol
errors will additionally have the E bit set in command
code flags byte of the Diameter message header.
Origin-Host Yes Populated with self host id.
Origin-Realm Yes Populated with configurable self host realm.
Host-IP-Address Yes Populated with IP Address of the host.
Vendor-Id Yes Configurable [Verify IANA assignment rules].
Product-Name Yes Configurable [“PrepayIN Diameter”].
Origin-State-Id No Unused by Diameter Interface Server application.
Error-Message Yes Populated with a PrepayIN-specific textual description
of the nature of error encountered.
Failed-AVP Yes Populated with unrecognized / badly formatted AVPs
in the request message.
Supported-Vendor-Id No Unused by Diameter Interface Server application.
Auth-Application-Id No Unused by Diameter Interface Server application.
Inband-Security-Id No Unused by Diameter Interface Server application.
Acct-Application-Id Yes Populated with 3GPP specified value [1].
Vendor-Specific- Yes Populated with 3GPP specified value [10415].
Application-Id
Firmware-Revision Yes Configurable Application Version Id [1].
AVP No Unused by Diameter Interface Server application.
Revision 02 118
----------------------------------------------------------------
Transport Failure Detection

In order to achieve compliance to Diameter Base Protocol RFC 3588 and 3GPP Specification TS
32.299, the Diameter Interface Server application supports Diameter Watchdog messages. The
Diameter Interface Server application will respond only to received Diameter Watchdog Request
(DWR) messages. Since the Diameter Interface Server does not maintain any relationship with
Diameter agents, the application does not initiate DWR messages on its own.
Device Watchdog Request (DWR) Message

This message is receivable only in the data stream state CONNECTED. If this message is received in
any other state, it is silently discarded. The error handling related to this ignore factor will be handled
by the external Diameter client. On receipt and successful processing, the Device Watchdog Answer
(DWA) message is returned back to the peer. Unsuccessful processing due to protocol errors will be
returned with appropriate error codes. DWR messages from unrecognized hosts and / or realms will
be silently discarded. This implies that DWR messages have been received in the OPEN state.
(AVP)
Origin-Host Yes Validated against configurable list of allowable hosts.
Origin-Realm Yes Validated against configurable list of allowable
realms.
The DWR message is completely processed by the Diameter Interface Server EPA component. The
processing is not propagated to the Gateway and IPA components. On successful processing of the
DWR message, the DWA message is sent to the Diameter peer.
hosts and / or realms. On unsuccessful processing of the DWR message:
+ DWA message (with appropriate error code) is sent to the Diameter peer.
+ DWA is not sent in case of bad state and unknown hosts / realms.
Revision 02 119
----------------------------------------------------------------
Device Watchdog Answer (DWA) Message

The DWA message consists of the following AVP listing:
(AVP)
Disconnecting Peer Connections

The Diameter Interface Server application supports received Disconnect-Peer-Request (DPR)
messages. The system responds only to received requests with Disconnect-Peer-Answer (DPA)
messages, and does not initiate such requests.
Disconnect Peer Request (DPR) Message

This message can be received in any state. This message indicates the intention of the peer to disconnect
and terminate the Diameter relationship. As a result, the Diameter Interface Server application will not
terminate the TCP/IP connection and await such action from the peer. The AVP listing for this
message is as follows:
(AVP)
Origin-Host Yes Validated against configurable list of allowable hosts.
Origin-Realm Yes Validated against configurable list of allowable
realms.
Disconnect-Cause Yes Used for logging and informational purposes.
The DPR message is completely processed by the Diameter Interface Server EPA component. The
presence of mandatory AVPs as well as appropriate values is validated. On successful processing of the
DPR message:
+ DPA message is sent to the Diameter peer.
+ Invocation is sent downstream to Gateway and IPA components to clean up internal resources and
resolve outstanding GCE reservations, if any.
hosts and / or realms. On unsuccessful processing of the DPR message:
Revision 02 120
----------------------------------------------------------------
+ DPA message (with appropriate error code) is sent to the Diameter peer.
+ Invocation is sent downstream to Gateway and IPA components to clean up internal resources and
resolve outstanding GCE reservations, if any.
Disconnect Peer Answer (DPA) Message

The DPA message consists of the following AVP listing:
(AVP)
Online Charging
The Diameter Interface Server application supports Credit Control Request (CCR) messages. The
system responds to received requests with the Credit Control Answer (CCA) message.
Credit Control Request (CCR) Message

This message is processed only in the CONNECTED state. If received in the OPEN state, the
associated stream will be closed in accordance with Diameter message processing rules. A transaction
table entry will be maintained for timeouts and duplicate detection. Only AVPs pertinent to the
processing of the incoming request will be parsed and validated.
Revision 02 121
----------------------------------------------------------------
The table below encapsulates the parameter mapping between CCR and Rating Invoke messages:
Attribute-Value-Pair Used Description
(AVP)
Session ID Yes Used in Session Id parameter of Rating Invoke msg.
Origin-Host Yes This parameter provides the location information.
Origin-Realm Yes This parameter provides the network element id.
The network element id may also be configurable.
Destination-Realm Yes Used for validations only.
Auth-Application-Id No
Destination-Host No
Vendor-Specific- No
Application-Id
User-Name No
Acct-Multi-Session-Id No
Origin-State-Id No
Event-Timestamp Yes This parameter provides the Invoke time for the
service.
Proxy-Info No
Route-Record No
Termination-Cause No
AVP No
CC-Request-Type Yes This is the service determination parameter, i.e.
whether session based or event based.
CC-Request-Number Yes Used in transaction tables. Also used in generating
the transaction id values in rating invoke messages.
CC-Sub-Session-Id No
Subscription-Id Yes Provides the IMSI / MDN values.
Requested-Action Yes Used for service determination in event based
charging.
Requested-Service-Unit Yes Populated into Usage units parameter of rating
invoke message for Create Operations.
Used-Service-Unit Yes Populated into Usage units parameter of rating
invoke message for Resolve operations.
Service-Parameter-Info Yes Provides the service Id parameter in rating invoke
message.
CC-Correlation-Id No
Service-Identifier No
Multiple-Services- No
Credit-Control
User-Equipment-Info No
Service-Information No
The CCR message is validated for all mandatory and required AVPs. On successful processing:
+ Rating Invoke message is constructed.
+ The Rating Invoke message is sent to the GCE Rater process.
+ Inbound Transaction table entry recorded for timeout and duplicate detection.
Revision 02 122
----------------------------------------------------------------
Unsuccessful processing may result from missing AVPs, unsupported values in AVPs, etc. The
processing is similar in the case of timeouts by the Diameter Interface Server while waiting for a
response from the GCE rater process. On unsuccessful processing:
+ CCA message is sent to the Diameter peer with the appropriate error code.
+ Transaction table entries are deleted in the case of timeouts.
Duplicate Detection
Duplicate detection is performed on the basis of the retransmitted flag present in the CCR header and
the existence of the Session ID and CC Request Number AVP values in the inbound transaction table.
Duplicates will be silently ignored.
Credit Control Answer (CCA) Message

The following table describes the AVP listing for CCA messages and their corresponding mapping
details:
(AVP)
Session ID Yes Echoed back from request
Result-Code Yes Populated on the basis of the GCE Response
message.
Origin-Host Yes Configurable / Self host id
Origin-Realm Yes Configurable / Self host realm
Auth-Application-Id Yes As per specification [Draft]. Value of 4 will be
populated.
Vendor-Specific- Yes As per specification [3GPP]. Value of 10415 will
Application-Id be populated.
User-Name No
Redirect-Host No
Redirect-Host-Usage No
Redirect-Max-Cache- No
Time
Origin-State-Id No
Event-Timestamp Yes Echoed back from request
Proxy-Info No
continued on next page
Revision 02 123
----------------------------------------------------------------

(AVP)
Route-Record No
AVP No
CC-Request-Type Yes Echoed back from request
CC-Request-Number Yes Echoed back from request
CC-Sub-Session-Id No
CC-Session-Failover No
Subscription-Id No
Granted-Service-Unit Yes Populated from Usage units and alt usage units.
Both time and volume units will be provided. No
accumulation necessary.
Cost-Information Yes GCE Response Message. Need to investigate if

Balance Information / Account Balance can be
populated for BALANCE-CHECK requests.
Final-Unit-Indication No Cannot be performed. GCE limitation.
Check-Balance-Result Yes Based on response code to CHECK_BALANCE
requests. The possible values are
ENOUGH_CREDIT and NO_CREDIT.
Credit-Control-Failure- Yes Configurable - default value RETRY-AND-
Handling TERMINATE.
Validity-Time Yes Populated from Usage / Alt Usage units. Should
correspond to the time units received in the GCE
Response message.
Trigger-Type No
Direct-Debiting-Failure- Yes Configurable - default value TERMINATE-OR-
Handling BUFFER
Multiple-Services- No
Credit-Control
PS-Furnish-Charging- No
Information
Quota-Consumption- No
Time
Failed-AVP Yes Populated if protocol errors encountered.
The Diameter Interface Server application supports Accounting Request (ACR) messages. The system
responds to received requests with the Accounting Answer (ACA) messages.
Accounting Request (ACR) Message

This message is processed only in the CONNECTED state. If received in the OPEN state, the
associated stream is closed in accordance to Diameter message processing rules. A transaction table
entry is maintained for timeouts and duplicate detection. Only AVPs pertinent to the processing of the
incoming request will be parsed and validated.
Revision 02 124
----------------------------------------------------------------
The following table encapsulates the parameter mapping between ACR and Rating Invoke messages:
b

(AVP)
Session-Id Yes Populated to Session Id
Origin-Host Yes Populated to Location Info
Origin-Realm Yes Populated to Network Element Id
Destination-Realm Yes Used for validations
Accounting-Record- Service Determination - Session based / Event
Type Yes based. [Event, Start, Stop and Interim Record]
Accounting-Record-
Number Yes Populated to Transaction Id
Should contain the 3GPP defined value of 1. Need
Acct-Application-Id No to verify if this is required to be validated.
Vendor-Specific- Configurable, as defined in 3GPP specifications
Application-Id Yes [10415]
User-Name No
Accounting-Sub-
Session-Id No
Accounting-RADIUS-
Session-Id No
Acct-Interim-Interval No
Accounting-Realtime-
Required No
Origin-State-Id No
Event-Timestamp Yes Populated to Invoke Time
Proxy-Info No
Route-Record No
AVP No
Event-Type No
Role-Of-Node No
User-Session-Id No
Calling-Party-Address Yes Populated to MDN
Called-Party-Address No
Time-Stamps No
Inter-Operator-Identifier No
IMS-Charging-Identifier No
SDP-Session-
Description No
SDP-Media-Component No
GGSN-Address No Consider using this for Location Info
Served-Party-IP-Address No
Authorized-QoS No
Server-Capabilities No
Trunk-Group-ID No
continued on next page
Revision 02 125
----------------------------------------------------------------

(AVP)
Bearer-Service No
Service-Id No
Service-Specific-Data No
UUS-Data Yes Vendor Confirmation required for usage units.
Cause No
PS-Furnish-Charging- No
Information
The ACR message is validated for all mandatory and required AVPs. On successful processing:
+ Rating Invoke message is constructed.
+ The Rating Invoke message is sent to the GCE Rater process.
+ Inbound Transaction table entry recorded for timeout and duplicate detection.
Unsuccessful processing may result from missing AVPs, unsupported values in AVPs, etc. The
processing is similar in the case of timeouts by the Diameter Interface Server while waiting for a
response from the GCE rater process. On unsuccessful processing:
+ ACA message is sent to the Diameter peer with the appropriate error code.
+ Transaction table entries are deleted in the case of timeouts.
Duplicate Detection
Duplicate detection is performed on the basis of the retransmitted flag present in the ACR header and
the existence of the Session ID and Accounting Record Number AVP values in the inbound transaction
table. Duplicates will be silently ignored.
Revision 02 126
----------------------------------------------------------------
Accounting Answer (ACA) Message

The following table shows the AVP listing for ACA messages and their corresponding mapping details:
(AVP)
Session-Id Yes Echoed back from Request.
Result-Code Yes Populated on the basis of GCE Response Code.
Origin-Host Yes Configurable self host id.
Origin-Realm Yes Configurable self host realm.
Accounting-Record-
Type Yes Echoed back from Request.
Accounting-Record-
Number Yes Echoed back from Request.
Acct-Application-Id No
Vendor-Specific-
Application-Id Yes Configurable, as per 3GPP definition [10415]
User-Name Yes Echoed back from Request.
Accounting-Sub-
Session-Id No
Accounting-RADIUS-
Session-Id No
Error-Reporting-Host No
Acct-Interim-Interval No
Accounting-Realtime-
Required No
Origin-State-Id Yes Echoed back from Request.
Event-Timestamp Yes Echoed back from Request.
Proxy-Info No
Revision 02 127
----------------------------------------------------------------
Sequence Diagrams
Capabilities Exchange
Brief Description
Diameter capabilities negotiation (Capabilities Exchange Request [CER]/Capabilities Exchanging
Answer [CEA]) MUST be carried out in order to determine what Diameter applications are supported
by the AAA server. These messages allow the discovery of a peer's identity and its capabilities (protocol
version number, supported Diameter applications, security mechanisms, etc.). Possible service
scenarios include:
+ Session-based Charging
+ GPRS Data Download/Web Access, etc. (Reservation based)
+ Mobile TV
+ Event-based Charging
+ SMS
+ Balance Inquiry
+ Direct Debit/Credit
+ Rate only services
Actors
Initiators Roles Participants Beneficiaries
Diameter Client X Request service from the

AAA server by sending
messages
AAA Server Responds to messages X

sent from any Diameter
Client
Service User End user that uses the X

service (e.g., SMS)
Rating Subsystem Software that actually X

performs the service
operations
Pre-Conditions
The Diameter AAA server is up and running and a TCP/IP socket connection has been established
with the Diameter Client. The Diameter Interface Server starts a timer TCER and waits for a message
from the Diameter client. If this timer expires, then the socket connection is dropped.
Revision 02 128
----------------------------------------------------------------
Flow of Events
Figure 7-8 Capabilities Exchange
a. The Diameter Client sends CER message to the AAA server.

b. In Response, the server sends a CEA message back to the client. This message MUST contain
one Host-IP-Address AVP for each potential IP address that MAY be locally used when
transmitting Diameter messages.
Alternative Flows
If the AAA server does not have any applications in common with the Client, then it MUST return a
CEA with the Result-Code AVP set to Diameter_NO_COMMON_APPLICATION, and SHOULD
disconnect the transport layer connection.
If the AAA server does not have any security mechanisms in common with the Client MUST return a
CEA with the Result-Code AVP set to Diameter_NO_COMMON_SECURITY, and SHOULD
disconnect the transport layer connection.
CERs received from unknown peers MAY be silently discarded, or a CEA MAY be issued with the
Result-Code AVP set to Diameter_UNKNOWN_PEER. In both cases, the transport connection is
closed.
If the local policy permits receiving CERs from unknown hosts, a successful CEA MAY be returned.
If a CER from an unknown peer is answered with a successful CEA, the lifetime of the peer entry is
equal to the lifetime of the transport connection. In case of a transport failure, all the pending
transactions destined to the unknown peer can be discarded.
Simple Accounting Session

Brief Description
A simple Accounting session is established and the connection is immediately torn down. In real
deployments, peer connections are long lived, and many accounting connections are multiplexed over
the connection.
Revision 02 129
----------------------------------------------------------------
Pre-Conditions
The Diameter AAA server is up and running and a TCP/IP socket connection has been established
with the Diameter Client. The Diameter Interface Server starts a timer TCER and waits for a message
from the Diameter client. If this timer expires, then the socket connection is dropped.
Flow of Events
Figure 7-9 Simple Accounting Session
a. The Diameter Client sends a CER to the AAA server.
Revision 02 130
----------------------------------------------------------------
b. In Response, the server sends a CEA message back to the client which MUST contain one
Host-IP-Address AVP for each potential IP address that MAY be locally used when
transmitting Diameter messages.
c. The Diameter Client sends an Accounting-Request (ACR) with Accounting-Record-Type
AVP set to START_RECORD to the Diameter Interface Server. The Diameter Interface
Server updates the CDR in question.
d. The Diameter Interface Server returns Accounting-Answer (ACA) message with Accounting-
Record-Type set to START_RECORD to the Diameter Client and possibly Acct-Interim-
Interval AVP (AII) set to non-zero value indicating the desired intermediate charging interval.
e. When AII timer (at the Diameter Client end) elapses the Diameter Client sends an ACR with
Accounting-Record-Type AVP set to INTERIM_RECORD to the Diameter Interface
Server. The Diameter Interface Server updates the CDR in question.
f. The Diameter Interface Server returns an ACA message with Accounting-Record-Type set to
INTERIM_RECORD to the Diameter Client.
g. The service is terminated. The Diameter Client sends an ACR with Accounting-Record-Type
AVP set to STOP_RECORD to the Diameter Interface Server. The Diameter Interface
Server stops the TAST timer.
h. The Diameter Interface Server returns an ACA message with Accounting-Record-Type set to
STOP_RECORD to the Diameter Client.
i. The Disconnect-Peer-Request message is used by a Diameter node to inform its peer of its
intent to disconnect the transport layer, and that the peer shouldn't reconnect unless it has a
valid reason to do so (e.g., message to be forwarded). Diameter node MUST include the
Disconnect-Cause AVP (REBOOTING 0, BUSY 1,
DO_NOT_WANT_TO_TALK_TO_YOU 2) in the Disconnect-Peer-Request message to
inform the peer of the reason for its intention to shutdown the transport connection.
j. Disconnect-Peer-Answer is returned, which SHOULD contain an error if messages have
recently been forwarded, and are likely in flight, which would otherwise cause a race
condition. The receiver of the Disconnect-Peer-Answer initiates the disconnection of the
transport.
Online Charging / IEC

Brief Description
The Diameter application shall support both one-time event charging capabilities. It is mandatory to
support the following services:
+ Direct Debiting
+ Balance Check
The following services may be optionally supported:
+ Service Price Inquiry
+ Refund
Revision 02 131
----------------------------------------------------------------
Actors

messages

Client

service (e.g., SMS)

operations
Pre-Conditions
a. The Diameter AAA server is up and running and a TCP connection has been established with
the Diameter Client. The Diameter Interface Server starts a timer TSCE and waits for a
message from the Diameter client. If this timer expires, then the socket connection is
dropped.
b. Diameter capabilities negotiation (CER/CEA) MUST be carried out in order to determine
what Diameter applications are supported by the AAA server. These messages allow the
discovery of a peer's identity and its capabilities (protocol version number, supported
Diameter applications, security mechanisms, etc.)
Post-Conditions
The Credit-Control-Answer message has to be checked by the Diameter client accordingly and the
requested service is controlled concurrently with service delivery.
Revision 02 132
----------------------------------------------------------------
Flow of Events
Direct Debiting
Figure 7-10 Direct Debiting
a. A Diameter credit-control client sends a Credit-Control-Request (CCR) with CC-Request-

Type AVP set to EVENT_REQUEST to indicate service-specific information to the
Diameter Interface Server. The Requested-Action AVP (RA) is set to
DIRECT_DEBITING. The Subscription-Id AVP SHOULD be included to identify the
End-User in the credit-control server. The Event-Timestamp AVP SHOULD be included in
the request and contains the time when the service event is requested in the service element.
The Service-Context-Id AVP indicates the service specific document applicable to the
request. The Diameter credit-control client MAY include the monetary amount to be charged
in the Requested-Service-Unit AVP, if it knows the cost of the service event (Decentralized
Unit Determination and Decentralized Rating). If the Diameter credit-control client does not
know the cost of the service event, the Requested-Service-Unit AVP MAY contain the
number of requested service events (Decentralized Unit Determination and Centralized
Rating).
The Service-Identifier AVP always indicates the concerned service. Additional service event
information to be rated MAY be sent as service specific AVPs or MAY be sent within the
Service-Parameter-Info AVP. Having transmitted the Credit-Control-Request message the
Diameter client starts the communication supervision timer 'Tx'. Upon receipt of the Credit-
Control- Answer (CCA) message the Diameter client shall stop timer Tx.
b. The Diameter Interface Server determines the relevant service charging parameters. It creates
a Rating Invoke message with Operation set to CHARGE, and Usage Units or Monetary
Amount set according to value of Requested-Service-Unit AVP in CCR message. It then
sends it to the GCE for Rating.
Revision 02 133
----------------------------------------------------------------
c. GCE sends back a Rating Invoke response to the Diameter Interface Server with the final
balance after debiting.
d. The Diameter Interface Server returns Credit-Control-Answer message with CC-Request-
Type AVP set to EVENT_REQUEST to the Diameter client in order to authorize the
service execution (Granted-Service-Unit AVP [GSU] and possibly Cost-Information AVP
[CI]) indicating the cost of the service are included in the CCA message). If the credit-control
server determines that no credit-control is needed for the service, it can include the result
code indicating that the credit-control is not applicable (e.g., the service is free of charge).
Alternative Flows
Price Inquiry
It is possible to perform also PRICE_ENQUIRY, CHECK_BALANCE, and REFUND_ACCOUNT
using the above described mechanism by setting the Requested-Action AVP (RA) in the CCR message.
The message flows are as given below.
Figure 7-11 Price Inquiry
a. A Diameter credit-control client requesting the cost information MUST set the CC-Request-
Type AVP equal to EVENT_REQUEST, include the Requested-Action AVP set to
PRICE_ENQUIRY, and set the requested service event information into the Service-
Identifier AVP in the Credit-Control-Request message. Additional service event information
may be sent as service-specific AVPs or may be sent within the Service-Parameter-Info AVP.
The Service-Context-Id AVP indicates the service-specific document applicable to the
request.
b. The Diameter Interface Server determines the relevant service charging parameters. This is a
case of Centralized Unit Determination and Centralized Rating. It creates a Rating Invoke
message with Operation set to RATE, and NodeServiceId set to the Service information
from the Service-Parameter-Info AVP and sends it to the GCE for Rating.
c. GCE sends back a Rating Invoke response to the Diameter Interface Server with the cost of
the service and balance.
Revision 02 134
----------------------------------------------------------------
d. The estimated cost of the requested service event is returned to the credit-control client in the
Cost-Information AVP in the Credit-Control-Answer message.
Check Balance
Figure 7-12 Check Balance
a. A Diameter credit-control client requesting the balance check MUST set the CC-Request-
Type AVP equal to EVENT_REQUEST, include Requested-Action AVP set to
CHECK_BALANCE, and include the Subscription-Id AVP to identify the End-User in the
credit-control server. The Service-Context-Id AVP indicates the service-specific document
applicable to the request.
a Rating Invoke message with Operation set to RATE, Default Usage Units set to FALSE ,
and sends it to the GCE for Rating.
d. The result of balance check (ENOUGH_CREDIT/NO_CREDIT) is returned to the credit-
control client in the Check-Balance-Result AVP in the Credit-Control-Answer message.
Revision 02 135
----------------------------------------------------------------
Refund
Figure 7-13 Refund
a. The Diameter credit-control client MUST set CC-Request-Type to the value

EVENT_REQUEST and the Requested-Action AVP to REFUND in the Credit-Control-
Request message. The Subscription-Id AVP SHOULD be included to identify the End-User
in the credit-control server. The Service-Context-Id AVP indicates the service specific
document applicable to the request. The Diameter credit-control client MAY include the
monetary amount to be refunded in the Requested-Service-Unit AVP (Decentralized Rating).
The Service-Identifier AVP always indicates the concerned service. If the Diameter credit-
control client does not know the monetary amount to be refunded, in addition to the Service-
Identifier AVP it MAY send service specific AVPs or the Service-Parameter-Info AVP
containing additional service event information to be rated (Centralized Unit Determination
and Centralized Rating).
a Rating Invoke message with Operation set to CREDIT and sends it to the GCE for Rating.
d. For informative purposes, the Credit-Control-Answer message MAY also include the Cost-
Information AVP containing the estimated monetary amount of refunded unit.
Offline Event-Based Charging

Brief Description
In the case of event-based charging, the network reports the usage or the service rendered where the
service offering is rendered in a single operation.
Revision 02 136
----------------------------------------------------------------
Actors

messages

Client

service (e.g., SMS)

operations
Pre-Conditions
the Diameter Client. The Diameter Interface Server starts a timer TSCE and waits for a
dropped.
c. The service has been delivered to the subscriber and the Diameter client receives the
acknowledgement (shown in figure below).
Post-Conditions
Revision 02 137
----------------------------------------------------------------
Flow of Events
Figure 7-14 Offline Event-Based Charging
a. The Diameter client sends Accounting-Request (ACR) with Accounting-Record-Type AVP

set to EVENT_RECORD to indicate service-specific information to the Diameter Interface
Server.
b. The Diameter Interface Server receives the relevant service charging parameters and
processes accounting request. The Diameter Interface Server determines the relevant service
charging parameters. It creates a Rating Invoke message with Operation set to
RATE_CHARGE and sends it to the GCE for Rating.
Record-Type AVP set to EVENT_RECORD to the Diameter client in order to inform that
charging information was received.
Offline Session-Based Charging

Brief Description
Session-based charging is the process of reporting usage reports for a session and uses the START,
INTERIM, and STOP accounting data. During a session, a Diameter client may transmit multiple ACR
Interims depending on the proceeding of the session.
Actors

messages
Revision 02 138
----------------------------------------------------------------

Client

service (e.g., SMS)

operations
Pre-Conditions
the Diameter Client. The Diameter Interface Server starts a timer TCER and waits for a
dropped.
c. The service has been delivered to the subscriber and the Diameter client receives the
acknowledgement (as shown in figure below).
Post-Conditions
Revision 02 139
----------------------------------------------------------------
Flow of Events
Figure 7-15 Offline Session-Based Charging
a. In order to start an accounting session, the Diameter Client sends Accounting-Request (ACR)
with Accounting-Record-Type AVP set to START_RECORD to the Diameter Interface
Server.
b. The Diameter Interface Server receives the relevant service charging parameters and starts a
timer TAST. The Diameter Interface Server determines the relevant service charging
Revision 02 140
----------------------------------------------------------------
parameters. It creates a Rating Invoke message and sends it to the GCE for Rating. The
Diameter Interface Server opens a CDR for current session.
Record-Type set to START_RECORD to the Diameter Client and possibly Acct-Interim-
Interval AVP (AII) set to non-zero value indicating the desired intermediate charging interval.
e. When AII timer (at the Diameter Client end) elapses the Diameter Client sends an
Accounting-Request (ACR) with Accounting-Record-Type AVP set to
INTERIM_RECORD to the Diameter Interface Server. The Diameter Interface Server
updates the CDR in question.
f. The Diameter Interface Server resets the TAST timer. It determines the relevant service
charging parameters. It creates a Rating Invoke message and sends it to the GCE for Rating.
Then it updates the CDR for current session.
g. GCE sends back a Rating Invoke response to the Diameter Interface Server with the cost of
h. The Diameter Interface Server returns an ACA message with Accounting-Record-Type set to
INTERIM_RECORD to the Diameter Client.
i. The service is terminated. The Diameter Client sends an ACR with Accounting-Record-Type
AVP set to STOP_RECORD to the Diameter Interface Server.
j. The Diameter Interface Server stops the TAST timer. It determines the relevant service
charging parameters. It creates a Rating Invoke message and sends it to the GCE for Rating.
k. GCE updates the CDR accordingly and closes the CDR and send back a Rating Invoke
response to the Diameter Interface Server with the cost of the service and balance.
l. The Diameter Interface Server returns an ACA message with Accounting-Record-Type set to
STOP_RECORD to the Diameter Client.
Revision 02 141
----------------------------------------------------------------
Event Charging with Unit Reservation

Brief Description
Event Charging with Unit Reservation (ECUR) also includes the process of requesting, reserving,
releasing, and returning unused units. The deduction of the corresponding monetary units then occurs
upon conclusion of the ECUR transaction.
Actors

messages

Client

service (e.g., SMS)

operations
Pre-Conditions
the Diameter Client.
c. The Diameter Client receives a service request. The service request may be initiated either by
the user or the other Diameter Client.
Post-Conditions
Revision 02 142
----------------------------------------------------------------
Flow of Events
Figure 7-16 Event Charging with Unit Reservation
Reserve Unit Operation

a. In order to perform Reserve Units operation for a number of units (monetary or non-
monetary), the Diameter Client sends a Credit-Control-Request (CCR) with CC-Request-
Type AVP set to INITIAL-REQUEST to the Diameter Interface Server. With the
Decentralized Unit Determination approach, the Diameter Client determines how many units
are required to start service delivery. Therefore, it may include Requested-Service-Unit (RSU)
Revision 02 143
----------------------------------------------------------------
AVP monetary or non monetary units and Acc-Interim-Interval (AII) AVP in the request
message.
b. The Diameter Interface Server creates a Rating Invoke request and sends to GCE for rating.
The Operation is RATE_CHARGE and the reservation parameters
(ReservationId=<internally generated> and ReservationOp=CREATE) are set. If the cost of
the service is included in the request, then it is placed in the UsageUnits parameter in the
Rating Invoke request.
c. If the service cost information is not received by the Diameter Interface Server, GCE
determines the price of the desired service according to the service specific information
received by issuing a rating request to the Rating Function. This is the Centralized rating
approach. If the credit balance is sufficient, the Diameter Interface Server reserves the
corresponding amount from the user's account.
d. Once the reservation has been made by GCE, the Diameter Interface Server returns Credit-
Control-Answer (CCA) message with CC-Request-Type AVP set to INITIAL-REQUEST to
the AS/MRFC in order to authorize the service execution (Granted-Service-Unit and
possibly Cost-Information indicating the cost of the service are included in the CC A
message). If requested, the Diameter Interface Server returns the Acc-Interim-Interval (AII)
AVP with the value field set to a non-zero value. Content/service delivery starts and the
reserved units are concurrently controlled.
Reserve Units and Debit Units Operation

e. During content/service delivery, in order to perform Debit Units and subsequent Reserve
Units operations, the Diameter Client sends a CCR with CC-Request-Type AVP set to
UPDATE-REQUEST, to report the units used and request additional units, respectively. The
CCR message with CC-Request-Type AVP set to UPDATE-REQUEST must be sent by the
Diameter Client between the INITIAL-REQUEST and TERMINATE-REQUEST either on
request of the credit control application within the interim interval or if the interim interval is
elapsed. If known, the Diameter Client may include Requested-Service-Unit AVP (monetary
or non monetary units) in the request message. This is the Decentralized rating approach. The
Used-Service-Unit (USU) AVP is included in the CCR message to deduct units from both the
user's account and the reserved units, respectively. This is the Centralized rating approach
where GCE is going to rate the service based on the USU.
f. The Diameter Interface Server creates a Rating Invoke Multi request according to the service-
specific information received and sends to GCE for rating. This message contains two
individual Rating Invoke requests. One Rating Invoke has the Operation as
RATE_CHARGE and the reservation parameters (ReservationId=< previous reservationId
value > and ReservationOp=RESOLVE). If the USU is included in the CCR, then it is placed
in the UsageUnits parameter. If the service cost information is received by the interface, then
the MonetaryAmount parameter is populated with this value. The second Rating Invoke has
the Operation as RATE_CHARGE and the reservation parameters
(ReservationId=<internally generated> and ReservationOp=CREATE). If the RSU is
included in the request, then it is placed in the UsageUnits parameter in this Rating Invoke
request.
g. The GCE Rating system deducts the amount used from the subscriber's account. If the
service cost information is not sent by the Diameter Interface Server, it determines the price
of the desired service. If the cost of the service is included in the request, the Rating system
directly reserves the specified monetary amount. If the credit balance is sufficient, it reserves
the corresponding amount from the users account and sends back a Rating Invoke response
to allow the service.
Revision 02 144
----------------------------------------------------------------
h. The Diameter Interface Server returns a CCA message with CC-Request-Type set to
UPDATE-REQUEST to the client in order to allow the content/service delivery to continue
(new Granted-Service-Unit [GSU] AVP and possibly Cost-Information [CI] AVP indicating
the cumulative cost of the service are included in the CCA message). The Diameter Interface
Server may include in the CCA message the Final-Unit-Indication (FUI) AVP to indicate the
final granted units. Content/service delivery continues and the reserved units are
concurrently controlled.
Debit Units Operation

i. When content/service delivery is completed or the final granted units have been consumed,
the Diameter Client sends a CCR with CC-Request-Type AVP set to TERMINATE-
REQUEST to terminate the active accounting session and report the used units. This is the
Centralized rating approach where the client knows the number of units to be rated.
j. The Diameter Interface Server creates a Rating Invoke request and sends it to GCE for
rating. The Operation is RATE_CHARGE and the reservation parameters
(ReservationId=<previous reservationId value> and ReservationOp=RESOLVE) are set.
The UsageUnits parameter in the Rating Invoke request is set to the number of units given in
the CCR .
k. The GCE Rating system deducts the amount (based on Monetary Amount or USU) used
from the subscriber's account. Unused reserved units are released, if applicable.
l. The Diameter Interface Server acknowledges the reception of the CCR message by sending a
CCA message with CCRequest-Type AVP indicating TERMINATE-REQUEST (possibly
Cost-Information AVP indicating the cumulative cost of the service is included in the CCA
message).
Session Charging with Unit Reservation

Brief Description
Session Charging with Unit Reservation (SCUR) is used for credit control of sessions. It also includes
the process of requesting, reserving, releasing, and returning unused units. The deduction of the
corresponding monetary units then occurs upon conclusion of the SCUR transaction.
Actors

messages

Client

service (e.g., SMS)

operations
Revision 02 145
----------------------------------------------------------------
Pre-Conditions
the Diameter Client.
c. The network element receives a session initiation. The session initiation may be done either
by the user or the other network element.
Post-Conditions
Revision 02 146
----------------------------------------------------------------
Flow of Events
Figure 7-17 Session Charging with Unit Reservation
Reserve Units Operation

a. In order to perform Reserve Units operation for a number of units (monetary or non-
monetary units), the Diameter Client sends a Credit-Control-Request (CCR) with CC-
Request-Type AVP set to INITIAL-REQUEST to the Diameter Interface Server. If known,
the Diameter Client may include Requested-Service-Unit (RSU) AVP (monetary or non
monetary units) and Acc-Interim-Interval (AII) AVP in the request message. If the units
contain a monetary amount, then this is the Decentralized rating approach. If the units (non-
Revision 02 147
----------------------------------------------------------------
monetary) are to be rated by the Diameter Interface Server, then this is the Centralized rating
approach.
b. The Diameter Interface Server creates a Rating Invoke request and sends to GCE for rating.
The Operation is RATE_CHARGE and the reservation parameters
(ReservationId=<internally generated> and ReservationOp=CREATE) are set. If the cost of
the service is included in the request, then it is placed in the UsageUnits parameter in the
Rating Invoke request.
c. If the service cost information is not received by the Diameter Interface Server, GCE
determines the price of the desired service according to the service specific information
received by issuing a rating request to the Rating Function. If the credit balance is sufficient,
the Diameter Interface Server reserves the corresponding amount from the users account.
d. Once the reservation has been made by GCE, the Diameter Interface Server returns the
Credit-Control-Answer (CCA) message with CC-Request-Type set to INITIAL-REQUEST
to the AS/MRFC in order to authorize the service execution (Granted-Service-Unit and
possibly Cost-Information indicating the cost of the service are included in the CCA
message). If requested, the Diameter Interface Server returns the Acc-Interim-Interval (AII)
AVP with value field set to a non-zero value. Content/service delivery starts and the reserved
units are concurrently controlled.
Reserve Units and Debit Units Operations

e. During session delivery, in order to perform Debit Units and subsequent Reserve Units
operations, the Diameter Client sends an CCR with CC-Request-Type AVP set to UPDATE-
REQUEST to report the units used and request additional units, respectively. The CCR
message with CC-Request-Type AVP set to UPDATE-REQUEST must be sent by the
Diameter Client between the INITIAL-REQUEST and TERMINATE-REQUEST either on
request of the credit control application within the interim interval or if the interim interval is
elapsed. If known, the Diameter Client may include Requested-Service-Unit AVP (monetary
or non monetary units) in the request message. The Used-Service-Unit (USU) AVP is
included in the CCR message to deduct units from both the user's account and the reserved
units, respectively.
f. The Diameter Interface Server creates a Rating Invoke Multi request according to the service-
specific information received and sends to GCE for rating. This message contains two
individual Rating Invoke requests. One Rating Invoke has the Operation as
RATE_CHARGE and the reservation parameters (ReservationId=< previous ReservationId
value > and ReservationOp=RESOLVE). If the USU is included in the CCR, then it is placed
in the UsageUnits parameter. If the service cost information is received by the interface, then
the MonetaryAmount parameter is populated with this value. The second Rating Invoke has
the Operation as RATE_CHARGE and the reservation parameters
(ReservationId=<internally generated> and ReservationOp=CREATE). If the RSU is
included in the request, then it is placed in the UsageUnits parameter in this Rating Invoke
request.
g. The GCE Rating system deducts the amount used from the subscriber's account. If the
service cost information is not sent by the Diameter Interface Server, it determines the price
of the desired service. If the cost of the service is included in the request, the Rating system
directly reserves the specified monetary amount. If the credit balance is sufficient, it reserves
the corresponding amount from the users account and sends back a Rating Invoke response
to allow the service.
Revision 02 148
----------------------------------------------------------------
h. The Diameter Interface Server returns a CCA message with CC-Request-Type set to
UPDATE-REQUEST to the client in order to allow the content/service delivery to continue
(new Granted-Service-Unit [GSU] AVP and possibly Cost-Information [CI] AVP indicating
the cumulative cost of the service are included in the CCA message). The Diameter Interface
Server may include in the CCA message the Final-Unit-Indication (FUI) AVP to indicate the
final granted units. Content/service delivery continues and the reserved units are
concurrently controlled.
Debit Units Operation

i. When session delivery is terminated or the final granted units have been consumed, the
Diameter Client sends a CCR with CC-Request-Type AVP set to TERMINATE-REQUEST
to terminate the active credit control session and report the used units.
j. The Diameter Interface Server creates a Rating Invoke request and sends it to GCE for
rating. The Operation is RATE_CHARGE and the reservation parameters
(ReservationId=<previous reservationId value> and ReservationOp=RESOLVE) are set.
The UsageUnits parameter in the Rating Invoke request is set to Zero.
k. The GCE Rating system deducts the amount (based on Monetary Amount or USU) used
from the subscriber's account. Unused reserved units are released, if applicable.
l. The Diameter Interface Server acknowledges the reception of the CCR message by sending a
CCA message with CC-Request-Type AVP indicating TERMINATE-REQUEST (possibly
Cost-Information AVP indicating the cumulative cost of the service is included in the CCA
message)
Revision 02 149

Sample Diameter

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Sample Diameter

Încărcat de

Drepturi de autor:

Formate disponibile

Diameter Protocol Support

This chapter contains the following topics:

Figure 7-5 Diameter Architecture

Diameter Converged Network

Figure 7-6 Typical GSM and IP Converged Data Services Network

Diameter Network Deployment

Figure 7-7 Typical Diameter Network

Server A Diameter Server is a server that handles authentication, authorization, and

Product Implementation: Protocol Compliance

+ SCTP Transport Mechanism

Diameter Credit Control Application (IETF DRAFT)

3GPP TS 32.299 - Diameter Charging Applications

– Service Price Inquiry

Features Not Supported

Product Solution Implementation: Diameter Messages and Parameter

Capabilities Exchange Request (CER) Message

+ Data stream connection state is set to CONNECTED.

Capabilities Exchange Answer (CEA) Message

Transport Failure Detection

Device Watchdog Request (DWR) Message

Device Watchdog Answer (DWA) Message

Disconnecting Peer Connections

Disconnect Peer Request (DPR) Message

Disconnect Peer Answer (DPA) Message

Credit Control Request (CCR) Message

Credit Control Answer (CCA) Message

continued on next page

Attribute-Value-Pair Used Description

Cost-Information Yes GCE Response Message. Need to investigate if

Accounting Request (ACR) Message

Attribute-Value-Pair Used Description

continued on next page

Attribute-Value-Pair Used Description

Accounting Answer (ACA) Message

Initiators Roles Participants Beneficiaries

Diameter Client X Request service from the

AAA Server Responds to messages X

Service User End user that uses the X

Rating Subsystem Software that actually X

Figure 7-8 Capabilities Exchange

a. The Diameter Client sends CER message to the AAA server.

Simple Accounting Session

Figure 7-9 Simple Accounting Session

a. The Diameter Client sends a CER to the AAA server.

Online Charging / IEC

Initiators Roles Participants Beneficiaries

Diameter Client X Request service from the

AAA Server Responds to messages X

Service User End user that uses the X

Rating Subsystem Software that actually X

Figure 7-10 Direct Debiting

a. A Diameter credit-control client sends a Credit-Control-Request (CCR) with CC-Request-

Figure 7-11 Price Inquiry

Figure 7-12 Check Balance

Figure 7-13 Refund

a. The Diameter credit-control client MUST set CC-Request-Type to the value

Offline Event-Based Charging

Initiators Roles Participants Beneficiaries

Diameter Client X Request service from the

AAA Server Responds to messages X

Service User End user that uses the X

Rating Subsystem Software that actually X

Figure 7-14 Offline Event-Based Charging

a. The Diameter client sends Accounting-Request (ACR) with Accounting-Record-Type AVP