Gy interface - sitting between OCS and PCEF

Last time I tried to cover Gx interface topic, with many details such as Diameter based PCC rules flow, short description on PCEF and PCRF functions, and Policy Charging and Control (PCC) itself. Every thing what I just mentioned you can find here. Almost whole article is based on information mentioned earlier. I will put links to every section if needed.

Gy is between Online Charging System (OCS) and PCEF. In most cases PCEF is based inside PDN GW (Packed Data Network Gateway) or just short PGW.

Gy interface allows online credit control for service data flow based charging. 

As always, today is also good way to start with a quite high level abstract figure. So.. please enjoy.

Fig. 1. Gy reference point at the Policy Charging and Control (PCC) architecture

The basic structure follows a mechanism where the online client (in OCS represented by CTF) requests resource allocation and reports credit control information to the Online Charging System (OCS). As described earlier charging could be based on different Charging Scenarios.

Basic principles for Diameter OCS

Online Credit Control Application Requirements

For online charging the basic functionality as defined by IETF Diameter Credit Control application is used. The basic structure follows a mechanism where the online client (CTF) requests resource allocation and reports credit control information to the OCS (Online Charging System).

The online client implements the state machine described in RFC 4006 for "CLIENT, EVENT BASED" and/or "CLIENT, SESSION BASED".

I.e. when the client applies for Immediate Event Charging (IEC) it uses the "CLIENT, EVENT BASED" state machine, and when the client applies Event Charging with Unit Reservation (ECUR) defined in 3GPP (or described previously by me here) it uses the "CLIENT, SESSION BASED" state machine for the first and final interrogations.

The usage and values of Validity-Time AVP and the time "Tcc" are under the sole controlof the credit control server (OCS) and determinated by operator configuration of the OCS.

Procedures over Gy interface

For Online Charging (OCS) additional AVPs were defined in Diameter protocol.

Three cases for control of users credit for online charging are distinguished:

• Immediate Event Charging (IEC)
• Event Charging with Unit Reservation (ECUR)
• Session Charging with Unit Reservation (SCUR)

In the case of Immediate Event Charging (IEC),  the credit control process for events is controlled by the corresponding CC-Requested-Type EVENT_REQUEST that is sent with Credit-Control-Request (CCR) for a given credit control event.

In the case of Event Charging with Unit Reservation (ECUR) the CC-Request-Type INITIAL / TERMINATION_REQUEST are used for charging for a given credit control event, however,  hwere a reservation is made prior to service delivery and committed on execution of a successful delivery.

Session Charging with Unit Reservation (ECUR) the CC-Request-Type INITIAL / UPDATE and TERMINATION_REQUEST.

The network element may apply IEC where CCR Event messages are generated, or ECUR, using CCR Initial and Termination. The decision whether to apply IEC or ECUR is based on the service and/or operator's policy.

Immediate Event Charging (IEC)

Fig. 2. shows the transaction that are required on the Gy interface in order to perform event based Direct Debiting operation. The Direct Debiting operation may alternatively be carried out prior to service/content delivery. The Network Element must ensure that the requested service execution is successful, when this scenario is used.

Fig. 2. IEC Direct Debiting Operation

Step 1. The network element receives a service request.

Step 2. The network element performs direct debiting prior to service execution. Network element (acting as DCCA client) sends Credit-Control-Request (CCR) with CC-Request-Type AVP set to EVENT_REQUEST to indicate service specific information to the OCS (acting as DCCA server). The Requested-Action AVP (RA) is set to DIRECT_DEBITING. If known, the network element may include Requested-Service-Unit AVP (RSU) (monetary or non-monetary units) in the request message.

Step 3. Having transmitted the Credit-Control-Request message the network element starts the communication supervision timer 'Tx'. Upon receipt of the Credit-Control- Answer (CCA) message the network element shall stop timer Tx.

Step 4. The OCS determines the relevant service charging parameters .

Step 5. The OCS returns Credit-Control-Answer message with CC-Request-Type AVP set to EVENT_REQUEST to the network element in order to authorize the service execution
(Granted-Service-Unit AVP (GSU) and possibly Cost-Information AVP (CI) indicating the cost of the service and Remaining-Balance AVP are included in the Credit-Control-Answer message).
The Credit-Control-Answer message has to be checked by the network element accordingly and the requested service is controlled concurrently with service delivery. The Refund-Information AVP may be included in the Credit-Control-Answer message  in order to be sent during  the REFUND-ACCOUNT mechanism, see below scenario.

Step 6. Service is being delivered.

NOTE: It is possible to perform also, CHECK_BALANCE and PRICE_ENQUIRY using above described mechanism.

Let's have a look at transaction for refund purpose.

Fig. 3. IEC Direct Debiting Operation for refund purpose

The Direct debiting operation is performed.

Step 1. The service charged previously through Direct Debiting Operation is finally proved to be  unsuccessfully delivered.

Step 2. As a consequence, the network element performs direct debiting operation in order to perform the related refund. Network element (acting as DCCA client) sends Credit-Control-Request (CCR) with CC-Request-Type AVP set to EVENT_REQUEST to indicate service specific information to the OCS (acting as DCCA server). The Requested-Action AVP (RA) is set to REFUND-ACCOUNT. The network element includes Refund-Information AVP if received in the previous IEC CCA.

Step 3. Having transmitted the Credit-Control-Request message the network element starts the communication supervision timer 'Tx' (RFC 4006 [402]). Upon receipt of the Credit-Control- Answer (CCA) message the network element shall stop timer Tx.

Step 4. The OCS reads the AVPs included in the CCR and performs the refund accordingly.

Step 5. The OCS returns Credit-Control-Answer message with CC-Request-Type AVP set to EVENT_REQUEST and the related result code.

Please note that I changed way of drawing flow sequence figures, I did it because UE is simply not so important on them. That's why from now in this article on next figures you wont find UE as a separate entity. Please keep that in mind.

And one more thing.. Figure 1 is missing something, there should be additional frame, like on Figure 2, starting from step 2., ending after step 5., named "Direct Debiting Operation". I'm to tired to fixed it. Please forgive me.

Event Charging with Unit Reservation (ECUR)

Fig. 4. shows the transactions that are required on the Gy interface in order to perform ECUR. ECUR is used when event charging needs separate reserve and commit actions.

Fig. 4. ECUR for session based credit control

Step 1. The network element receives a service request. The service request may be initiated either by the user or the other network element.

Step 2. In order to perform Reserve Units operation for a number of units (monetary or non-monetary units), the network element sends a Credit-Control-Request (CCR) with CC-Request-Type AVP set to INITIAL_REQUEST to the OCS. If known, the network element may include Requested-Service-Unit (RSU) AVP (monetary or non monetary units) in the request message.

Step 3. If the service cost information is not received by the OCS, the OCS 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 cost of the service is included in the request, the OCS directly reserves the specified monetary amount. If the credit balance is sufficient, the OCS reserves the corresponding amount from the users account.

Step 4. Once the reservation has been made, the OCS returns Credit-Control-Answer (CCA) message with CC-Request-Type set to INITIAL_REQUEST to the network element in order to authorize the service execution (Granted-Service-Unit and possibly Cost-Information indicating the cost of the service and Remaining-Balance AVP are included in the Credit-Control-Answer message).  The OCS may return the Validity-Time (VT) AVP with value field set to a non-zero value. The OCS may indicate in the Low-Balance-Indication AVP that the subscriber account balance has fallen below a predefined treshold of this account.

Step 5. Content/service delivery starts and the reserved units are concurrently controlled.

Step 6. When content/service delivery is completed, the network element sends CCR with CC-Request-Type AVP set to TERMINATION_REQUEST to terminate the active credit control session and report the used units.

Step 7. The OCS deducts the amount used from the account. Unused reserved units are released, if applicable.

Step 8. The OCS acknowledges the reception of the CCR message by sending CCA message with CC-Request-Type AVP indicating TERMINATION_REQUEST (possibly Cost-Information AVP indicating the cumulative cost of the service and Remaining-Balance AVP are included in the Credit-Control-Answer message).

NOTE: This scenario is supervised by corresponding timers (e.g. validity time timer) that are not shown in the figure above..

Session Charging with Unit Reservation (SCUR)

Fig. 5. shows the transactions that are required on the Gy interface point in order to perform the SCUR.

Fig. 5. SCUR for session based credit control

Step 1. The network element receives a session initiation. The session initiation may be done either by the user or the other network element.

Step 2. In order to perform Reserve Units operation for a number of units (monetary or non-monetary units), the network element sends a Credit-Control-Request (CCR) with CC-Request-Type AVP set to INITIAL_REQUEST to the OCS. If known, the network element may include Requested-Service-Unit (RSU) AVP (monetary or non monetary units) in the request message.

Step 3. If the service cost information is not received by the OCS, the OCS 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 cost of the service is included in the request, the OCS directly reserves the specified monetary amount. If the credit balance is sufficient, the OCS reserves the corresponding amount from the users account.

Step 4. Once the reservation has been made, the OCS returns Credit-Control-Answer (CCA) message with CC-Request-Type set to INITIAL_REQUEST to the network element in order to authorize the service execution (Granted-Service-Unit and possibly Cost-Information indicating the cost of the service and Remaining-Balance AVP are included in the Credit-Control-Answer message).  The OCS may return the Validity-Time (VT) AVP with value field set to a non-zero value. The OCS may indicate in the Low-Balance-Indication AVP that the subscriber account balance has fallen below a predefined threshold of this account.

Step 5. Content/service delivery starts and the reserved units are concurrently controlled.

Step 6. During session delivery, in order to perform Debit Units and subsequent Reserve Units operations, the network element 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 network element between the INITIAL_REQUEST and TERMINATION_REQUEST either on request of the credit control application within the validity time or if the validity time is elapsed. If known, the network element may include Requested-Service-Unit AVP (monetary or non monetary units) in the request message.  The Used-Service-Unit (USU) AVP is complemented in the CCR message to deduct units from both the user's account and the reserved units, respectively.

Step 7. The OCS deducts the amount used from the account. If the service cost information is not received by the OCS, the OCS 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 cost of the service is included in the request, the OCS directly reserves the specified monetary amount. If the credit balance is sufficient, the OCS reserves the corresponding amount from the users account.

Step 8. Once the deduction and reservation have been made, the OCS returns Credit-Control-Answer message with CC-Request-Type set to UPDATE_REQUEST to the network element, 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 and Remaining-Balance AVP are included in the Credit‑Control-Answer message). The OCS may include in the CCA message the Final-Unit-Indication (FUI) AVP to indicate the final granted units. The OCS may indicate in the Low-Balance-Indication AVP that the subscriber account balance has fallen below a predefined threshold of this account.

Step 9. Session delivery continues and the reserved units are concurrently controlled.

Step 10. The session is terminated at the network element.

Step 11. The network element sends CCR with CC-Request-Type AVP set to TERMINATION_REQUEST to terminate the active credit control session and report the used units.

Step 12. The OCS deducts the amount used from the account. Unused reserved units are released, if applicable.

Step 13. The OCS acknowledges the reception of the CCR message by sending CCA message with CC-Request-Type AVP indicating TERMINATION_REQUEST (possibly Cost-Information AVP indicating the cumulative cost of the service and Remaining-Balance AVP are included in the Credit-Control-Answer message).

NOTE:      This scenario is supervised by corresponding timers (e.g. validity time timer) that are not shown in figure above.

Source:

3GPP TS 32.299