Supported Diameter Messages
The messages sent and received by the diameter infrastructure are as follows:
- Capability Exchange Request (CER)—Sent upon new connection establishment from the SCE to peer. The main purpose of this message is to advertise which applications are supported by peers. It also includes some other details such as realm, host, and so on.
- Capability Exchange Answer (CEA)—Responds to the CER message.
- Watch Dog Request (WDR)—Sent by one peer to another. The purpose is to ensure that the connection is up and running. If three watch dog messages in a row are not answered, the connection is closed and reopened, and only after three messages are answered will it be considered up.
- Watch Dog Answer (WDA)—Responds to WDR message.
- Disconnect Peer Request (DPR)—Tells the peer that the connection will be disconnected.
- Disconnect Peer Answer (DPA)—Responds to the DPR message.
Figure 1-1 displays the typical connection flow of diameter messages and responses.
Figure 1-1 Typical Connection Flow
The SCE initiates the TCP connection (the only transport layer currently supported by SCE). After the TCP connection is established, the SCE sends the CER message. The CER message is answered by the CEA message. At this stage the connection is up. The WDR and WDA messages are exchanged between the peers. The time gap between watch dog messages is defined by the Tx timer. If the peer is removed, the connection is gracefully closed by sending the DPR message and receiving the DPA message.
Gx-Supported Messages
The following messages are supported:
CCR Initiate is sent by the SCE to the PCRF (Gx Server) upon login of a subscriber (for example, using SceSubsciberAPI) or upon new flow mapped to a Gx anonymous group. Upon login, the CCR includes parameters that identify the subscriber to the PCRF, such as Framed-ip and Subscription-Id (not on anonymous-group).
CCR Terminate is sent on logout.
– Responding to a CCR Initial request—The CCA message includes the subscriber policy parameters and RADIUS VSA attributes (or some subset of it).
– Responding to a CCR Terminate request—The CCA message generally includes only results of the action.
- Re-Authorize Request (RAR)—A RAR message is initiated by the PCRF. The RAR message can include new parameters (package, and so on) and RADIUS VSA attributes. The RAR message is initiated by an external event.
- Re-Authorize Answer (RAA)—A RAA message is the response to the RAR. It usually includes the result of the action.
- Abort Session Request (ASR)—An ASR message is sent from the PCRF to the SCE to close the subscriber session, and in some cases to trigger a logout of the subscriber. A subscriber owned by a Gx (anonymous group manager), is logged out.
- Abort Session Answer (ASA)—An ASA message is the response to ASR message and usually contains the result of the action.
Credit Control Request (CCR)
|
|
|
|
|
'R' bit set |
SCE to PCRF |
Sent to:
- Request SCE rules for a subscriber
- Indicate termination of the subscriber
|
Message Format:
<CC-Request> ::= < Diameter Header: 272, REQ, PXY >
The format of the Session-Id is “pid; ip; time”
, where:
- PID is a 32-bit integer type indicating the unique PID for a specific Gx session.
- IP is a 32-bit unsigned integer type indicating the framed IP of the subscriber for which the session is created. IP is in decimal format.
TIME is a 32-bit unsigned integer type indicating the time when session is created. Time is in number of seconds starting from January 1, 1970.
Message Response:
- Auth-Application-Id is set to the application ID of the Gx protocol.
- Origin-Host is set to the SCE host id (its IP).
- Origin-Realm is set to “SCE” defined realm.
- Destination-Host and Destination-Realm define the PCRF destination. The destination host is not mandatory, it depends on the SCE and PCRF configurations.
- CC-Request-Type is set to “Initial” on session creation (SCE login) and “Termination” on session termination (SCE logout).
CC-Request-Number is a unique number within a session-id.
- Framed-IP-Address and Subscription-Id will be sent depending on the scenario.
Case 1: Login mode
- The CCR includes both parameters.
- Framed-IP-Address is the IP address of the subscriber. (Will not be sent on “TERMINATE”.)
- Subscription-Id is set to the subscriber-ID used by the SCE (for example, IMSI/MSISDN).
- The subscription-Id will be introduced to the SCE by a different API.
Case 2: Pull mode
- The CCR includes only the Framed-IP-Address AVP. The subscription-Id is returned as part of the CCA.
- Framed-IP-Address is the IP address of the subscriber.
- In this mode, the Gx interface is also used to introduce the subscribers to the SCE.
Sample Message Login mode:
Command Code = Credit-Control-Request (272)
Application Id = 16777238
Session-Id = "27; 3232262425; 1311857000"
Auth-Application-Id = 16777238
Origin-Host = "10.101.23.34"
Destination-Realm = "att.com"
Destination-Host = "PCRF host"
CC-Request-Type = INITIAL_REQUEST (1)
Framed-IP-Address = 10.10.1.10
Subscription-Id = 05412345566
Sample Message Pull mode:
Command Code = Credit-Control-Request (272)
Application Id = 16777238
Session-Id = "27; 3232262425; 1311857000"
Auth-Application-Id = 16777238
Origin-Host = "10.101.23.34"
Destination-Realm = "att.com"
Destination-Host = "PCRF host"
CC-Request-Type = INITIAL_REQUEST (1)
Framed-IP-Address = 10.10.1.10
The format of the Session-Id is “pid; ip; time”
, where:
- PID is a 32-bit integer type indicating the unique PID for a specific Gx session.
- IP is a 32-bit unsigned integer type indicating the framed IP of the subscriber for which the session is created. IP is in decimal format.
TIME is a 32-bit unsigned integer type indicating the time when session is created. Time is in number of seconds starting from January 1, 1970.
Credit Control Answer (CCA)
The CCA command has two formats:
- CCA Initial
- CCA Update/Terminate
|
|
|
|
|
'R' bit cleared |
PCRF to SCE |
Sent in response to the CCR command. Used to provision SCE rules and event triggers for the subscriber. |
CCA Initial
Message Format:
<CC-Answer> ::= < Diameter Header: 272, PXY >
[ Cisco-SCA BB-Package-Install ]
[ Cisco-SCA BB-Package-Install ]
[ Cisco-SCA BB-Real-time-monitor-Install ]
[ Cisco-SCA BB-Vlink-Upstream-Install ]
[ Cisco-SCA BB-Vlink-Downstream-Install ]
[3GPP-GPRS-QoS-Negotiated-Profile]
[3GPP-Charging-Characteristics]
[3GPP-User-Location-Info]
[3GPP-GGSN-Address-Code-7]
[3GPP-SGSN-Address-Code-6]
Message Response:
- Session-Id is set to the CCR Session-Id.
- Auth-Application-Id is set to the same value as the CCR.
- Origin-Host is set to the message generating host (PCRF which responds).
- Origin-Realm is set to the PCRF realm.
- CC-Request-Type and CC-Request-Number are set to the same type as in the CCR.
- Subscription-Id is set to the subscriber-ID used by the SCE.
- Cisco-SCA BB-Package-Install is set to the subscriber assigned package ID.
- Cisco-SCA BB-Real-time-monitor-Install is set to real monitor activation value.
- Cisco-SCA BB-Vlink-Upstream-Install is set to the upstream vlink assigned ID.
- Cisco-SCA BB-Vlink-Downstream-Install is set to the downstream vlink assigned ID.
For Login mode, only the Cisco-SCA BB-Package-Install is mandatory. For Pull mode, both Cisco-SCA BB-Package-Install and Subscription-Id are mandatory. Additional attributes are sorted and can be used by other interfaces, such as Gy.
Sample Message:
Command Code = Credit-Control-Answer (272)
Application Id = 16777238
Session-Id = "27; 3232262425; 1311857000"
Auth-Application-Id = 16777238
Origin-Host = "PCRF host"
Origin-Realm = "PCRF Realm"
CC-Request-Type = INITIAL_REQUEST (1)
Subscription-Id = 05412345566
Subscription-Id-Type = END_USER_E164 (0)
Subscription-Id-Value = 1110123456
Result-Code = DIAMETER_SUCCESS
Cisco-SCA BB-Package-Install = 5
Cisco-SCA BB-Real-time-monitor-Install = 1
The format of the Session-Id is “pid; ip; time”
, where:
- PID is a 32-bit integer type indicating the unique PID for a specific Gx session.
- IP is a 32-bit unsigned integer type indicating the framed IP of the subscriber for which the session is created. IP is in decimal format.
- TIME is a 32-bit unsigned integer type indicating the time when session is created. Time is in number of seconds starting from January 1, 1970.
Error Handling
- If a timeout event occurs, or if a CCA is returned with an error code, the SCE tries to open the session again after 15 seconds, 30 seconds, 60 seconds, and then every 120 seconds.
- Rejection is not supported. To reject a subscriber, the PCRF must return a CCA with a success code that installs a special package used for this purpose.
- If the user is not recognized by the PCRF server, the PCRF should return a CCA with fail code and wait for retry. It is also possible to return a success code that installs the blocking\rejecting\limiting package, and update it later by using RAR, when the PCRF gets new information about the subscriber.
CCA Update/Terminate
Message Format:
<CC-Answer> ::= < Diameter Header: 272, PXY >
[ Cisco-SCA BB-Package-Install ]
[ Cisco-SCA BB-Package-Install ]
[ Cisco-SCA BB-Real-time-monitor-Install ]
[ Cisco-SCA BB-Vlink-Upstream-Install ]
[ Cisco-SCA BB-Vlink-Downstream-Install ]
[3GPP-GPRS-QoS-Negotiated-Profile]
[3GPP-Charging-Characteristics]
[3GPP-User-Location-Info]
[3GPP-GGSN-Address-Code-7]
[3GPP-SGSN-Address-Code-6]
Message Response:
- Session-Id is set to the CCR Session-Id.
- Auth-Application-Id is set to the same value as the CCR.
- Origin-Host is set to the message generating host (PCRF which responds).
- Origin-Realm is set to the PCRF realm.
- CC-Request-Type and CC-Request-Number are set to the same type as in the CCR.
- Cisco-SCA BB-Package-Install is set to the subscriber assigned package ID.
- Cisco-SCA BB-Real-time-monitor-Install is set to real monitor activation value.
- Cisco-SCA BB-Vlink-Upstream-Install is set to the upstream vlink assigned ID.
- Cisco-SCA BB-Vlink-Downstream-Install is set to the downstream vlink assigned ID.
Sample Message:
Command Code = Credit-Control-Answer (272)
Application Id = 16777238
Session-Id = "27; 3232262425; 1311857000"
Auth-Application-Id = 16777238
Origin-Host = "PCRF host"
Origin-Realm = "PCRF Realm"
CC-Request-Type = UPDATE_REQUEST (1)
Result-Code = DIAMETER_SUCCESS
Cisco-SCA BB-Package-Install = 5
Cisco-SCA BB-Real-time-monitor-Install = 1
The format of the Session-Id is “pid; ip; time”
, where:
- PID is a 32-bit integer type indicating the unique PID for a specific Gx session.
- IP is a 32-bit unsigned integer type indicating the framed IP of the subscriber for which the session is created. IP is in decimal format.
- TIME is a 32-bit unsigned integer type indicating the time when session is created. Time is in number of seconds starting from January 1, 1970.
Error Handling
No errors are supported.
For a Terminate message if timeout or error occurs, the SCE updates the appropriate counter and closes the session.
Re-Authorize Request (RAR)
|
|
|
|
|
'R' bit set |
PCRF to SCE |
Sent to provision SCE rules using the PUSH procedure to initiate the provisioning of unsolicited SCE rules. It is used to provision SCE rules for the subscriber. |
Message Format:
<RA-Request> ::= < Diameter Header: 258, REQ, PXY >
[ Cisco-SCA BB-Package-Install ]
[ Cisco-SCA BB-Real-time-monitor-Install ]
[ Cisco-SCA BB-Vlink-Upstream-Install ]
[ Cisco-SCA BB-Vlink-Downstream-Install ]
[3GPP-GPRS-QoS-Negotiated-Profile]
[3GPP-Charging-Characteristics]
[3GPP-User-Location-Info]
[3GPP-GGSN-Address-Code-7]
[3GPP-SGSN-Address-Code-6]
Message Response:
- Session-Id is set to the CCR Session-Id.
- Auth-Application-Id is set to the same value as the CCR.
- Origin-Host is set to the message generating host (PCRF which responds).
- Origin-Realm is set to the PCRF realm.
- CC-Request-Type and CC-Request-Number are set to the same type as in the CCR.
- Subscription-id is set to the subscriber-ID used by the SCE.
- Cisco-SCA BB-Package-Install is set to the subscriber assigned package ID.
- Cisco-SCA BB-Real-time-monitor-Install is set to real monitor activation value.
- Cisco-SCA BB-Vlink-Upstream-Install is set to the upstream vlink assigned ID.
- Cisco-SCA BB-Vlink-Downstream-Install is set to the downstream vlink assigned ID.
Sample Message:
Command Code = Re-Auth-Request (258)
Application Id = 16777238
Session-Id = "27; 3232262425; 1311857000"
Auth-Application-Id = 16777238
Origin-Host = "PCRF Host"
Origin-Realm = "PCRF Realm"
Destination-Realm = "SCE Realm"
Destination-Host = "SCE Host"
Re-Auth-Request-Type = AUTHORIZE_ONLY (0)
Framed-IP-Address = 10.1.1.1
Subsscription-Id = 05412321312
Cisco-SCA BB-Package-Install = 5
The format of the Session-Id is “pid; ip; time”
, where:
- PID is a 32-bit integer type indicating the unique PID for a specific Gx session.
- IP is a 32-bit unsigned integer type indicating the framed IP of the subscriber for which the session is created. IP is in decimal format.
- TIME is a 32-bit unsigned integer type indicating the time when session is created. Time is in number of seconds starting from January 1, 1970.
Re-Authorize Answer (RAA)
|
|
|
|
|
'R' bit cleared |
SCE to PCRF |
Sent in response to the RAR command. |
Message Format:
<RA-Answer> ::= < Diameter Header: 258, PXY >
Sample Message:
Command Code = Re-Auth-Request (258)
Application Id = 16777238
Session-Id = "27; 3232262425; 1311857000"
Auth-Application-Id = 16777238
Origin-Realm = "SCE Realm"
Error-Code = DIAMETER_SUCCESS
The format of the Session-Id is “pid; ip; time”
, where:
- PID is a 32-bit integer type indicating the unique PID for a specific Gx session.
- IP is a 32-bit unsigned integer type indicating the framed IP of the subscriber for which the session is created. IP is in decimal format.
- TIME is a 32-bit unsigned integer type indicating the time when session is created. Time is in number of seconds starting from January 1, 1970.
Error Handling:
- DIAMETER_UNKNOWN_SESSION_ID is returned if no such session id exits in the SCE database.
- DIAMETER_UNABLE_TO_COMPLY is returned when the RAR is received in the middle of initiating new session (CCR-I was sent). SCE can also return this error code when the update fails for an unknown reason.
- DIAMETER_INVALID_AVP_VALUE is returned when the value of an AVP is not valid; for example, package out of range.
- DIAMETER_MISSING_AVP_SCE is returned when the message format of the RAR is not valid.
Abort Session Request (ASR)
|
|
|
|
|
'R' bit set |
Server to access device |
May be sent by any server to the access device providing session service, requesting it to stop the session identified by the Session-Id. |
Message Format:
<ASR> ::= < Diameter Header: 274, REQ, PXY >
Message Response:
- Origin-Host is set to the SCE host ID (its IP).
- Origin-Realm is set to the SCE-defined realm.
- Destination-Host and Destination-Realm define the PCRF destination. The destination host is not mandatory, it depends on the SCE and PCRF configurations.
- Auth-Application-Id is set to the application ID of the Gx protocol.
Sample Message:
Version = 1
Message Length = XXX
Command Code = Re-Auth-Request (274)
Application Id = 16777238
Session-Id = "27; 3232262425; 1311857000"
Auth-Application-Id = 16777238
Origin-Host = "PCRF Host"
Origin-Realm = "PCRF Realm"
Destination-Realm = "att.com"
Destination-Host = "SCE host"
Auth=Application-id = 16777238
The format of the Session-Id is “pid; ip; time”
, where:
- PID is a 32-bit integer type indicating the unique PID for a specific Gx session.
- IP is a 32-bit unsigned integer type indicating the framed IP of the subscriber for which the session is created. IP is in decimal format.
- TIME is a 32-bit unsigned integer type indicating the time when session is created. Time is in number of seconds starting from January 1, 1970.
Abort Session Answer (ASA)
|
|
|
|
|
'R' bit clear |
Access device to server |
Sent in response to the ASR. The Result-Code AVP must be present; it indicates the disposition of the request. |
Message Format:
<ASA> ::= < Diameter Header: 274, PXY >
Message Response:
- Origin-Host is set to the SCE host ID (its IP).
- Origin-Realm is set to the SCE realm.
- Error-Message is set to error description if the SCE is unable to comply.
- The Result-Code is set as follows:
– If the session identified by Session-Id in the ASR was successfully terminated, Result-Code is set to DIAMETER_SUCCESS.
– If the session is not currently active, Result-Code is set to DIAMETER_UNKNOWN_SESSION_ID.
– If the access device does not stop the session for any other reason, Result-Code is set to DIAMETER_UNABLE_TO_COMPLY.
- The SCE tries to comply only in Pull mode.
Sample Message:
Command Code = Re-Auth-Request (274)
Application Id = 16777238
Session-Id = "27; 3232262425; 1311857000"
Result-Code = DIAMETER_SUCCESS
Origin-Realm = "SCE Realm"
The format of the Session-Id is “pid; ip; time”
, where:
- PID is a 32-bit integer type indicating the unique PID for a specific Gx session.
- IP is a 32-bit unsigned integer type indicating the framed IP of the subscriber for which the session is created. IP is in decimal format.
- TIME is a 32-bit unsigned integer type indicating the time when session is created. Time is in number of seconds starting from January 1, 1970.
Error Handling:
- DIAMETER_UNKNOWN_SESSION_ID is returned if no such session id exits in the SCE database.
- DIAMETER_UNABLE_TO_COMPLY is returned when ASR is received in the middle of ending a session (CCR-T was sent). It is also returned when the SCE fails to logout the subscriber for an unknown reason.
Gy-Supported Messages
The following messages are supported on the Gy interface:
Supported Gx RLS9 Messages and AVPs—Used between the SCE and the OCS to request credit authorization for a given service.
Credit Control Request (CCR)—The CCR message indicates diameter session create, update, and close.
Credit Control Answer (CCA)—Used between the credit-control server and the SCE to acknowledge a Credit-Control-Request command. The SCE listens to the CCA messages and updates the SCA BB with quota grants, failure conditions, and result codes. The CCA message is also used for failure indication and failure handling.
Re-Authorize Request (RAR)—Sent by any server to the access device that is providing session service, to request that the user be reauthenticated or be reauthorized. In the SCE Gy implementation, RAR messages are used by the OCS to request usage information on either a specific bucket-id or all buckets. The SCE listens to RAR messages and signals SCA BB to send usage information to the OCS. RAR messages arrive in an asynchronous manner from the server and with no correlation to any request completed by the SCE.
Re-Authorize Answer (RAA)—Sent in response to the RAR message. The Result-Code AVP must be present and indicate the disposition of the request. A successful RAA message must be followed by an application-specific authentication and/or authorization message. This message is sent by the Gy application in response to RAR right after the SCA BB is notified that a RAR message has been received.
Credit Control Request (CCR)
|
|
|
|
|
'R' bit set |
SCE to OCS |
Sent to request credit authorization for a given service. |
The Auth-Application-Id value is set to 4, indicating the Diameter credit-control application.
Table 1-1 lists the CCR message structure.
Table 1-1 CCR Message Structure
|
|
AVP Code
(Code / Vendor-id)
|
|
|
Session-Id |
M |
263 |
String Format: <pid; ip; time> |
Session-Id. |
Origin-Host |
M |
264 |
DiameterIdentifier |
IP of the SCE platform. |
Origin-Realm |
M |
296 |
DiameterIdentifier |
Configured value. |
Destination-Realm |
M |
283 |
DiameterIdentifier |
Configured value in CCR (Initial). For subsequent CCRs, the Origin-Realm received in the last CCA is used as Destination-Realm. |
Destination-Host |
Oc |
293 |
DiameterIdentifier |
Not sent in the first CCR message. The Origin-Host in the CCA is used as Destination-Host in the next CCR message. |
Auth-Application-Id |
M |
258 |
4 |
Value for DCCA. |
Service-Context-Identifier |
M |
461 |
— |
— |
CC-Request-Type |
M |
416 |
1 = INITIAL_REQUEST 2 = UPDATE_REQUEST 3 = TERMINATION_ REQUEST 4 = EVENT_REQUEST |
Type “EVENT_REQUEST” is not supported. |
CC-Request-Number |
M |
415 |
A monotonically increasing number |
Value of “0” is used for CCR (INITIAL_REQUEST). |
Event-Timestamp |
Oc |
55 |
Time when quota is requested |
— |
Subscription-Id |
Om |
443 |
Grouped AVP |
Grouped AVP consisting of Subscription-Id-Type and Subscription-Id-Data. |
Subscription-Id-Type |
Om |
450 |
END_USER_E164 (0) |
— |
Subscription-Id-Data |
Om |
444 |
MSISDN (string) |
— |
Termination-Cause |
Oc |
295 |
Integer value (as per RFC 3588) |
Only sent in CCR (FINAL) |
Multiple-Services-Indicator |
Om |
455 |
MULTIPLE_SERVICES_ SUPPORTED (1) |
Present only in CCR (INITIAL) |
Multiple-Services-Credit- Control (see separate description for Multiple Services Credit Control AVP) |
Om |
456 |
Grouped AVP |
See Multiple Services Credit Control AVP. Multiple of these attributes can be present. Contains the usage for each category. |
Service-Information AVP |
Om |
— |
Grouped AVP |
— |
PS-Information |
Om |
— |
Grouped AVP |
— |
Called-Station-Id |
Oc |
30 |
APN name (string) |
In PS-Information. |
SGSN-Address |
Oc |
1228 |
IPv4 Address |
Subscriber attributes. |
3GPP-GPRS-QoS- Negotiated-profile |
Oc |
5/10415 |
Negotiated QoS profile |
QoS profile of the Primary PDP context will be sent. However, if a primary PDP is deleted before the secondary PDPs, subsequent CCR messages contain the negotiated QoS of the first Secondary PDP context. (Subscriber attributes, received from Gx or SCE subscriber API) (in PS-Information). |
3GPP-SGSN-MCC-MNC |
Oc |
18/10415 |
— |
Subscriber attributes, received from Gx or SCE subscriber API (in PS-Information). |
3GPP-Charging- Characteristics |
Oc |
13/10415 |
Charging Char received from SGSN |
— |
CCR Message Formats
This section contains:
CCR Initial Message Fields
<Credit-Control-Request> ::= < Session-Id >
[ Multiple-Services-Indicator ]
*[ Multiple-Services-Credit-Control ]
[ Requested-Service-Unit ]
[3GPP-GPRS-QoS-Negotiated-Profile]
[3GPP-Charging-Characteristics]
[3GPP-User-Location-Info]
[3GPP-GGSN-Address-Code-7]
[3GPP-SGSN-Address-Code-6]
CCR Update Message Fields
<Credit-Control-Request> ::= < Session-Id >
*[ Multiple-Services-Credit-Control ]
[ CC-Service-Specific-Units ]
[3GPP-GPRS-QoS-Negotiated-Profile]
[3GPP-Charging-Characteristics]
[3GPP-User-Location-Info]
[3GPP-GGSN-Address-Code-7]
[3GPP-SGSN-Address-Code-6]
CCR Final Message Fields
<Credit-Control-Request> ::= < Session-Id >
*[ Multiple-Services-Credit-Control ]
[ CC-Service-Specific-Units ]
Credit Control Answer (CCA)
|
|
|
|
|
'R' bit cleared |
Credit control server to SCE. |
Sent to acknowledge a CCR command. |
The SCE listens to CCA messages and updates SCA BB with grant quotas, failure conditions, and result codes. CCA is also used for failure indication and failure handling.
Table 1-2 lists the CCA message structure.
Table 1-2 CCA Message Structure
|
|
AVP Code
(Code / Vendor-Id)
|
|
|
Session-Id |
M |
263 |
String |
|
Origin-Host |
M |
264 |
DiameterIdentifier |
Address of the DCCA server. |
Origin-Realm |
M |
296 |
DiameterIdentifier |
Realm of the DCCA server. |
Result-Code |
M |
268 |
Integer value (as per RFC 3588 & DCCA draft) |
— |
Auth-Application-Id |
M |
258 |
4 |
Value for DCCA. |
CC-Request-Type |
M |
416 |
1 = INITIAL_REQUEST 2 = UPDATE_REQUEST 3 = TERMINATION_ REQUEST 4 = EVENT_REQUEST |
Value 4 (Event) is not supported. |
CC-Request-Number |
M |
415 |
Same as the one sent in corresponding CCR message |
— |
CC-Session-Failover |
Oc |
— |
— |
— |
Multiple-Services-Credit-Control |
Om |
456 |
Grouped AVP |
Contains the quota granted. There can be multiple instances of this attribute, one for each category. |
Service-Context-Id |
Oc |
— |
— |
— |
Subscription-Id |
Oc |
— |
— |
— |
CC-Failure-Handling |
Oc |
— |
— |
— |
Failed-AVP |
Oc |
279 |
Grouped AVP. Contains the list of attributes causing failure condition |
Optionally present. If the Result-Code is not SUCCESS. There can be multiple instances of this AVP. |
CCA Message Format
<Credit-Control-Answer> ::= < Session-Id >
*[ Multiple-Services-Credit-Control ]
[ CC-Service-Specific-Units ]
[ Final-Unit-Indication ]
[ Volume-Quota-Threshold ]
[ Quota-Consuption-Time ]
[ Credit-Control-Failure-Handling ]
Re-Auth Request (RAR)
|
|
|
|
|
'R' bit set |
Server to access device |
Sent to the access device that is providing session service to request that the user be reauthenticated or reauthorized. |
In the SCE, Gy implementation of RAR messages may be used by the OCS to request usage information about a specific bucket-id or about all the buckets. The SCE listens to the RAR messages and signals the SCA BB to send usage information to the OCS.
RAR messages may arrive asynchronously from the server, with no correlation to any request from the SCE. The SCE behavior upon receiving an RAR message is common to other scenarios as well, such as logout or package change.
Table 1-3 lists the RAR message structure.
Table 1-3 RAR Message Structure
|
|
AVP Code
(Code/Vendor Id)
|
|
|
Session-Id |
M |
263 |
String |
— |
Origin-Host |
M |
264 |
Host name of Diameter server |
— |
Origin-Realm |
M |
296 |
Origin realm of Diameter server |
— |
Destination-Realm |
M |
283 |
Destination realm of diameter peer |
— |
Destination-Host |
M |
293 |
Host name of diameter peer |
— |
Auth-Application-Id |
M |
258 |
4 |
— |
Re-Auth-Request-Type |
M |
285 |
Authorize-Only |
— |
Rating-Group |
Oc |
432 |
Category Id |
Presence of this AVP means that reauthorization is done for this specific category. |
RAR Message Format
<Re-Auth-Request> ::= < Session-Id >
Re-Auth Answer (RAA)
|
|
|
|
|
'R' bit cleared |
Access device to server |
Sent in response to the RAR. |
The Result-Code AVP must be present, and indicates the disposition of the request.
A successful RAA message must be followed by an application-specific authentication, authorization message, or both.
This message is sent by the Gy application in response to RAR right after the SCA BB is notified with the RAR.
Table 1-4 lists the RAA message structure.
Table 1-4 RAA Message Structure
|
|
AVP Code
(Code/Vendor Id)
|
|
|
Session-Id |
M |
263 |
String, Format: <pid; ip; time> |
— |
Result-Code |
M |
268 |
2001, 2002 |
A value of 2001 is sent if no CCR (Update) is sent. A value of 2002 is sent if a subsequent CCR (Update) follows. |
Origin-realm |
M |
296 |
DiameterIdentifier |
Configured value. |
Origin-Host |
M |
264 |
DiameterIdentifier |
Configured value. |
RAA Message Format
<Re-Auth-Answer> ::= < Session-Id >
Supported Gy Messages and AVPs
Table 1-5 lists the Gy messages and the AVPs used for Gy client interface support.
Table 1-5 Supported Gy Messages and AVPs
|
|
|
|
|
|
|
|
|
|
|
|
|
+ |
+ |
+ |
+ |
+ |
+ |
Session-Id |
M |
— |
— |
— |
— |
+ |
— |
+ |
Result-Code |
M |
— |
+ |
+ |
+ |
+ |
+ |
+ |
Origin-Host |
M |
— |
+ |
+ |
+ |
+ |
+ |
+ |
Origin-Realm |
M |
— |
+ |
+ |
+ |
— |
+ |
— |
Destination-Realm |
M |
— |
+ |
+ |
+ |
+ |
+ |
— |
Auth-Application-Id |
M |
— |
— |
— |
— |
— |
+ |
— |
Re-Auth-Request-Type |
M |
— |
+ |
+ |
+ |
— |
— |
— |
Service-Context- Identifier |
M |
— |
+ |
+ |
+ |
+ |
— |
— |
CC-Request-Type |
M |
— |
+ |
+ |
+ |
+ |
— |
— |
CC-Request-Number |
M |
— |
— |
— |
— |
+ |
— |
— |
CC-Session-Failover |
Oc |
— |
— |
— |
— |
— |
+ |
— |
Destination-Host |
Oc (M for RAR) |
— |
— |
— |
— |
— |
(+) |
— |
Rating-Group |
Oc |
— |
+ |
+ |
+ |
— |
— |
— |
Event-Timestamp |
Om |
— |
+ |
+ |
+ |
— |
— |
— |
Subscription-Id |
Om |
Grouped AVP |
+ |
+ |
+ |
— |
— |
— |
Subscription-Id-Type |
Om |
— |
+ |
+ |
+ |
— |
— |
— |
Subscription-Id-Data |
Oc |
— |
— |
— |
+ |
— |
— |
— |
Termination-Cause |
Om |
Reporting reason is used for regular logout, unsupported tariff-change, and unsupported unit type. |
+ |
— |
— |
— |
— |
— |
Multiple-Services- Indicator |
Om |
— |
+ |
+ |
+ |
+ |
— |
— |
Multiple-Services- Credit-Control |
Om |
Grouped AVP |
+ |
+ |
+ |
— |
— |
— |
Service-Identifier |
— |
— |
+ |
— |
— |
— |
— |
— |
Requested-Service-Unit |
Oc |
Empty |
— |
+ |
+ |
— |
— |
— |
Used-Service-Unit |
Oc |
Grouped AVP |
— |
+ |
+ |
— |
— |
— |
Reporting-Reason |
Oc |
— |
— |
+ |
+ |
— |
— |
— |
Tariff-Change-Usage |
Oc |
— |
— |
+ |
+ |
— |
— |
— |
CC-Time |
Oc |
— |
— |
+ |
+ |
— |
— |
— |
CC-Total-Octets |
Oc |
— |
— |
+ |
+ |
— |
— |
— |
CC-Input-Octets |
Oc |
— |
— |
+ |
+ |
— |
— |
— |
CC-Output-Octets |
Oc |
— |
— |
+ |
+ |
— |
— |
— |
CC-Service-Specific- Units |
Oc |
— |
— |
— |
— |
+ |
— |
— |
Granted-Service-Unit |
Oc |
Grouped AVP |
— |
— |
— |
+ |
— |
— |
Tariff-Time-Change |
Oc |
— |
— |
— |
— |
+ |
— |
— |
CC-Time |
Oc |
— |
— |
— |
— |
+ |
— |
— |
CC-Total-Octets |
Oc |
— |
— |
— |
— |
+ |
— |
— |
CC-Input-Octets |
Oc |
— |
— |
— |
— |
+ |
— |
— |
CC-Output-Octets |
Oc |
— |
— |
— |
— |
+ |
— |
— |
CC-Service-Specific- Units |
Oc |
— |
(+) |
+ |
+ |
+ |
— |
— |
Rating-Group |
Oc |
— |
— |
— |
— |
+ |
— |
— |
Validity-Time |
Oc |
— |
— |
— |
— |
+ |
— |
— |
Result-Code |
Oc |
Considered only if the Result-Code value present at the command level is SUCCESS. The value is defined by 3GPP TS 32.299 V6.6.0 section 7.15. |
— |
— |
— |
+ |
— |
— |
Final-Unit-Indication |
Oc |
Grouped AVP |
— |
— |
— |
+ |
— |
— |
Final-Unit-Action |
Oc |
TERMINATE, REDIRECT, or RESTRICT_ACCESS |
— |
— |
— |
+ |
— |
— |
Time-Quota-Threshold |
Oc |
— |
— |
— |
— |
+ |
— |
— |
Volume-Quota-Threshold |
Oc |
— |
— |
— |
— |
+ |
— |
— |
Unit-Quota-Threshold |
Oc |
— |
— |
— |
— |
+ |
— |
— |
Quota-Holding-Time |
Oc |
— |
— |
— |
— |
+ |
— |
— |
Quota-Consumption- Time |
Oc |
— |
— |
— |
— |
+ |
— |
— |
Credit-Control-Failure- Handling |
— |
— |
+ |
— |
— |
— |
— |
— |
Service-Information AVP |
Om |
Grouped AVP |
+ |
— |
— |
— |
— |
— |
PS-Information |
Om |
Grouped AVP |
+ |
— |
— |
— |
— |
— |
Called-Station-Id |
Om |
— |
+ |
— |
— |
— |
— |
— |
SGSN-Address |
Om |
— |
+ |
— |
— |
— |
— |
— |
3GPP-GPRS-Negotiated- QOS-Profile |
Om |
— |
+ |
— |
— |
— |
— |
— |
3GPP-SGSN-MCC-MNC |
Om |
— |
+ |
— |
— |
— |
— |
— |
3GPP-Charging- Characteristics |
Om |
— |
Multiple Services Credit Control AVP
The Multiple Services Credit Control (MSCC) AVP is used for granting and reporting quota for each bucket (rating-group). Figure 1-2 illustrates the structure of this attribute, and Table 1-6 lists the structure.
When the MSCC AVP is present in CCA messages, it represents quota being granted. When it is present in CCR messages, it represents usage being reported. If quota/usage is being reported for more than one rating-group, then multiple MSCC AVPs are present in the message.
There are some attributes that can be present at the command level and the MSCC level.
If the Result-Code present at the command level is SUCCESS, the Result-Code present at MSCC level takes effect.
The Validity-Time present at the command level applies to all the categories. If Validity-Time is present at MSCC level, its value is used for that particular category.
This AVP must be present at the command level for CCR (initial). When the quota request for a particular category is made using CCR (update), it is present at the MSCC level for that category.
Figure 1-2 MSCC AVP Structure
Table 1-6 MSCC AVP Structure
|
|
AVP Code
(Code / Vendor-Id)
|
|
|
Granted-Service-Unit |
Oc |
431 |
Grouped AVP |
Present inside MSCC of a CCA (initial) and CCA (update) message. |
Requested-Service-Unit |
Oc |
437 |
Empty value |
Conditionally present inside MSCC of a CCR (update) message. |
Used-Service-Unit |
Oc |
446 |
Grouped AVP |
Present inside MSCC of a CCR (update) and CCR (final) message. There can be multiple instances of this AVP. |
Rating-Group |
Oc |
432 |
— |
Used to indicate service. |
Validity-Time |
Oc |
448 |
Time until quota is valid |
A value of “0” is considered invalid. Present inside MSCC of CCA messages. |
Result-Code |
Om |
268 |
Value as per DCCA RFC |
Considered only if the Result-Code value present at command level is SUCCESS. Present inside MSCC of CCA messages. |
CC-Final-Unit-Indication |
Oc |
— |
Grouped AVP |
— |
Final Unit Indication |
Oc |
— |
— |
— |
Time-Quota-Threshold |
Oc |
868/10415 |
Quota threshold for time quota in seconds |
Present inside MSCC of CCA messages. This AVP is ignored if no time quota is granted (that is, CC-Time AVP is not present inside Granted-Service-Unit AVP). |
Volume-Quota-Threshold |
Oc |
869/10415 |
Quota threshold for volume quota in octets |
Present inside MSCC of CCA messages. This AVP is ignored if no volume quota is granted (that is, CC-Total-Octets is not present inside Granted-Service-Unit AVP). |
Unit-Quota-Threshold |
Oc |
869/10415 |
Quota threshold for unit quota in octets |
Present inside MSCC of CCA messages. This AVP is ignored if no unit quota is granted (i.e. CC-Unit-Quota is not present inside Granted-Service-Unit AVP). |
CC-Time |
Oc |
420 |
Time quota in seconds |
Present in Granted-Service-Unit AVP and Used-Service-Unit AVP. |
CC-Service-Specific-Units |
Oc |
417 |
Events quota |
Refer to the service identified in the Service-Identifier AVP. |
CC-Total-Octets |
Oc |
421 |
Volume quota in octets (64 bit number) |
Present in Granted-Service-Unit AVP and Used-Service-Unit AVP. |
Tariff-Time-Change |
Oc |
451 |
Number of seconds since 01/01/1900 UTC |
Refer to the time when tariff of the service will be changed. Present in Granted-Service-Unit AVP. |
Tariff-Change-Usage |
Oc |
452 |
UNIT_BEFORE_TARIFF_ CHANGE (0), UNIT_AFTER_TARIFF_ CHANGE (1), UNIT_UNDETERMINATE (2) |
Present in Used-Service-Unit AVP. |
CC-Input-Octets |
Oc |
412 |
Number of octets received from the end user |
Present in Used-Service-Unit. |
CC-Output-Octets |
Oc |
414 |
Number of octets sent to the end user |
Present in Used-Service-Unit. |
Gy Support Session and Call Flows
This section provides information on Gy support session initiation, quota usage reporting, package changes, and call flows.
Initiating Session
Once a login event occurs on SCA BB, it sends a Session Creation RDR if the subscriber quota is externally provisioned. The Gy interface listens to these messages and in return sends a CCR initial message to the OCS with or without quota usage information. This process is completed to allow PDP context creation on the OCS as quickly as possible.
Table 1-7 lists the required fields in the CCR initial message and their sources and Figure 1-3 displays the session creation call flow.
Table 1-7 CCR Initial Message Fields and Sources
|
|
|
|
|
|
|
|
Session-Id |
M |
Session ID pool |
— |
Origin-Host |
M |
Diameter Config |
— |
Origin-Realm |
M |
Diameter Config |
— |
Destination-Realm |
M |
Diameter Routing Table |
— |
Auth-Application-Id |
M |
Preconfigured |
— |
Service-Context-Identifier |
M |
Preconfigured |
— |
CC-Request-Type |
M |
— |
Reporting-Reason |
CC-Request-Number |
M |
Session context CCR counter |
— |
Event-Timestamp |
Om |
System clock |
— |
Subscription-Id |
Om |
— |
— |
Subscription-Id-Type |
Om |
Preconfigured |
— |
Subscription-Id-Data |
Oc |
— |
Subscriber id |
Multiple-Services-Indicator |
Om |
Always MULTIPLE_SERVICES_ SUPPORTED (1) |
— |
Multiple-Services-Credit-Control |
Om |
— |
— |
Service-Identifier |
— |
— |
— |
Requested-Service-Unit |
Oc |
— |
— |
Rating-Group |
Oc |
— |
Bucket-id |
Service-Information AVP |
Om |
— |
— |
PS-Information |
Om |
— |
— |
Called-Station-Id |
Om |
Subscriber’s attributes |
— |
SGSN-Address |
Om |
Subscriber’s attributes |
— |
3GPP-GPRS-Negotiated-QOS- Profile |
Om |
Subscriber’s attributes |
— |
3GPP-SGSN-MCC-MNC |
Om |
Subscriber’s attributes |
— |
3GPP-Charging-Characteristics |
Om |
Subscriber’s attributes |
— |
Figure 1-3 Session Creation
Reporting Quota Usage
The SCE reports the quota usage for each category under the circumstances listed in Table 1-8 .
Table 1-8 Quota Reporting Usage Conditions and Reasons
|
|
Threshold hit |
THRESHOLD |
Quota breach |
QUOTA_EXHAUSTED |
Quota Holding Timer expired |
QHT |
Validity Timer expired |
VALIDITY_TIME |
Package Change |
RATING_CONDITION_CHANGE (TERMINATE and INITIAL) |
Server initiated reauthorization procedure |
FORCED_REAUTHORIZATION |
Quota usage is reported by SCA BB using the Quota Status RDR, the Gy client listens to these messages and delivers them by a CCR update message to the OCS.
Table 1-9 lists the structure of a CCR update message and the source for each field and Figure 1-4 displays the quota usage update call flow.
Table 1-9 CCR Update Message Structure
|
|
|
|
Session-Id |
M |
Session ID pool |
— |
Origin-Host |
M |
Diameter Config |
— |
Origin-Realm |
M |
Diameter Config |
— |
Destination-Realm |
M |
Diameter Routing Table |
— |
Auth-Application-Id |
M |
Preconfigured |
— |
Service-Context-Identifier |
M |
Preconfigured |
— |
CC-Request-Type |
M |
— |
Reporting-Reason |
CC-Request-Number |
M |
Session context CCR counter |
— |
Event-Timestamp |
Om |
System clock |
— |
Subscription-Id |
Om |
— |
— |
Subscription-Id-Type |
Om |
Preconfigured |
— |
Subscription-Id-Data |
Oc |
— |
Subscriber id |
Multiple-Services-Credit-Control |
Om |
— |
— |
Service-Identifier |
— |
— |
— |
Rating-Group |
Oc |
— |
Bucket-id |
Used-Service-Unit |
Oc |
— |
— |
Reporting-Reason |
Oc |
— |
Reporting-Reason |
Tariff-Change-Usage |
Oc |
— |
Tarrif-Change-Usage |
CC-Time |
Oc |
— |
Units-Type +Unit-Amount |
CC-Total-Octets |
Oc |
— |
Units-Type + Unit-Amount |
CC-Input-Octets |
Oc |
— |
Units-Type + Unit-Amount |
CC-Output-Octets |
Oc |
— |
Units-Type + Unit-Amount |
CC-Service-Specific-Units |
Oc |
— |
Units-Type + Unit-Amount |
Figure 1-4 Quota Usage Update
The exact structure of CCR update is also used for CCR terminate. Figure 1-5 displays the session termination initiated by the SCA BB call flow. Figure 1-6 displays the reauthorization request initiated by the OCS.
Figure 1-5 Session Termination Initiated by SCA BB
Figure 1-6 Reauthorization Request Initiated by the OCS
Package Change
Upon package change, the SCA BB sends a Session Termination RDR, which contains the final indication and usage reporting on all the buckets and the reporting reason of the pre-package. As a result, the Gy interface sends a CCR final message with usage information. After this, the SCA BB sends a Quota Status RDR with reporting reason of postpackage, the Gy client issues a CCR initial message with bucket IDs. Figure 1-7 displays the tariff change call flow and Figure 1-8 displays the package change call flow.
Figure 1-7 Tariff Change
Figure 1-8 Package Change
Note The SCE immediately forwards messages from the data plane to OCS without buffering it. It does not wait to receive the CCA message from OCS before sending the next message. Robust OCS implementation should be able to cope with receiving the CCR-U message from the SCE before the CCA-I message was sent and receiving the CCR-T message before the CCA-U message was sent.