Supported Message Formats
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:
- Credit Control Request (CCR)—The CCR message indicates Gx diameter session create, update, and close.
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.
- Credit Control Answer (CCA)—A CCA message is sent from the server to the SCE.
–
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)
|
Field |
Field |
|
|
|---|---|---|---|
|
|
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.
- 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.
- 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.
- 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.
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.
Credit Control Answer (CCA)
The CCA command has two formats:
|
Field |
Field |
|
|
|---|---|---|---|
|
|
Sent in response to the CCR command. Used to provision SCE rules and event triggers for the subscriber. |
CCA Initial
- 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.
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.
- 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
- 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.
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.
For a Terminate message if timeout or error occurs, the SCE updates the appropriate counter and closes the session.
Re-Authorize Request (RAR)
- 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.
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)
|
Field |
Field |
|
|
|---|---|---|---|
|
|
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.
- 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)
- 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.
Message Length = XXX
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)
|
Field |
Field |
|
|
|---|---|---|---|
|
|
Sent in response to the ASR. The Result-Code AVP must be present; it indicates the disposition of the request. |
- 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 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.
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)
|
Field |
Field |
|
|
|---|---|---|---|
|
|
The Auth-Application-Id value is set to 4, indicating the Diameter credit-control application.
Table 1-1 lists the CCR message structure.
|
|
|
(Code / Vendor-id) |
|
|
|---|---|---|---|---|
M1 |
||||
Configured value in CCR (Initial). For subsequent CCRs, the Origin-Realm received in the last CCA is used as Destination-Realm. |
||||
Oc2 |
Not sent in the first CCR message. The Origin-Host in the CCA is used as Destination-Host in the next CCR message. |
|||
Om3 |
Grouped AVP consisting of Subscription-Id-Type and Subscription-Id-Data. |
|||
Multiple-Services-Credit- |
See Multiple Services Credit Control AVP. Multiple of these attributes can be present. Contains the usage for each category. |
|||
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). |
||||
Subscriber attributes, received from Gx or SCE subscriber API (in PS-Information). |
||||
CCR Message Formats
CCR Initial Message Fields
CCR Update Message Fields
CCR Final Message Fields
Credit Control Answer (CCA)
|
Field |
Field |
|
|
|---|---|---|---|
|
|
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.
|
|
|
(Code / Vendor-Id) |
|
|
|---|---|---|---|---|
M4 |
||||
Oc5 |
||||
Om6 |
Contains the quota granted. There can be multiple instances of this attribute, one for each category. |
|||
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
Re-Auth Request (RAR)
|
Field |
Field |
|
|
|---|---|---|---|
|
|
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.
|
|
|
(Code/Vendor Id) |
|
|
|---|---|---|---|---|
M7 |
||||
Oc8 |
Presence of this AVP means that reauthorization is done for this specific category. |
RAR Message Format
Re-Auth Answer (RAA)
|
Field |
Field |
|
|
|---|---|---|---|
|
|
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.
|
|
|
(Code/Vendor Id) |
|
|
|---|---|---|---|---|
M9 |
||||
A value of 2001 is sent if no CCR (Update) is sent. A value of 2002 is sent if a subsequent CCR (Update) follows. |
||||
|
9.This parameter is mandatory and must be present in the event/CDR. |
RAA Message Format
Supported Gy Messages and AVPs
Table 1-5 lists the Gy messages and the AVPs used for Gy client interface support.
|
|
|
|
|
|||||
|---|---|---|---|---|---|---|---|---|
|
Initial |
Update |
Termination |
|
|
|
|
|
|
M10 |
||||||||
Oc11 |
||||||||
Om12 |
||||||||
Reporting reason is used for regular logout, unsupported tariff-change, and unsupported unit type. |
||||||||
Considered only if the Result-Code value present at the command level is SUCCESS. The value is defined by |
||||||||
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.
|
|
|
(Code / Vendor-Id) |
|
|
|---|---|---|---|---|
Oc13 |
Present inside MSCC of a CCA (initial) and CCA (update) message. |
|||
Conditionally present inside MSCC of a CCR (update) message. |
||||
Present inside MSCC of a CCR (update) and CCR (final) message. There can be multiple instances of this AVP. |
||||
Om14 |
Considered only if the Result-Code value present at command level is SUCCESS. |
|||
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). |
||||
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). |
||||
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). |
||||
Present in Granted-Service-Unit AVP and Used-Service-Unit AVP. |
||||
Refer to the service identified in the Service-Identifier AVP. |
||||
Present in Granted-Service-Unit AVP and Used-Service-Unit AVP. |
||||
Refer to the time when tariff of the service will be changed. Present in Granted-Service-Unit AVP. |
||||
UNIT_BEFORE_TARIFF_ |
||||
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.
|
|
|
|
|
|---|---|---|---|
|
|
|
|
|
M15 |
|||
Om16 |
|||
Oc17 |
|||
Reporting Quota Usage
The SCE reports the quota usage for each category under the circumstances listed in Table 1-8 .
|
|
|
|---|---|
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.
|
|
|
|
|
|---|---|---|---|
M18 |
|||
Om19 |
|||
Oc20 |
|||
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.
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.
Supported Gx RLS9 Messages and AVPs
Table 1-10 summarizes the message types and AVPs that Gx RLS9 supports.
Usage-Monitoring-Information
The Usage-Monitoring-Information AVP is enabled when the value of the Event-Trigger AVP is USAGE_REPORT.
The SCE reports the accumulated usage under the following conditions:
- When a usage threshold is reached
- When a package (containing the predefined PCC rules) is changed
- When usage monitoring is explicitly disabled by the PCRF
- When the session is terminated
- When requested by the PCRF (by setting the value of USAGE_MONITORING_REPORT_
REQUIRED (0) in the Usage-Monitoring-Report AVP in an RAR or CCA message).
To report, the SCE sends a CCR message as follows:
- CC-Request-Type AVP = "UPDATE_REQUEST"
- Event-Trigger AVP = "USAGE_REPORT"
- Usage-Monitoring-Information AVP includes:
– Monitoring key (SCA BB bucket ID) in the Monitoring-Key AVP
– The accumulated usage since the last report in the Used-Service-Unit AVP (using CC-Total-Octets, CC-Input-Octets, or CC-Output-Octets).
Usage-Monitoring-Information AVP Format
[ Grante-Service-Unit ]
Feedback