LTE AND BEYOND

LTE, 4G, MME, PGW, SGW, Interfaces and beyond

If you liked it, or content was helpful to you please add "+1" to article you used or share it on facebook or so.
Make it easier to find for others who could need those information, allow them find these articles on the spot.
But.. it's your call.
Recommendations until now

JAN 23, 2012

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 LowBalance-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-RequestType 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 CCRequest-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 LowBalance-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-RequestType 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 CostInformation (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 FinalUnit-Indication (FUI) AVP to indicate the final granted units. The OCS may indicate in the Low-BalanceIndication 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 CCRequest-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.