top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

Does OCS have capability to terminate the session

+1 vote
598 views

Hi,

this question is related to gy interface. whenever OCS sends terminate or restrict access in the Final unit action avp to GGSN. does ocs convey the message to GGSN to disconnect the session from GGSN side or OCS will disconnect the session .

I mean Does OCS have the authority to disconnect the ongoing online charging session or it always decided on core N/W

posted Mar 30, 2016 by Dhinesh Ram

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

1 Answer

+2 votes

Hi Dhinesh,

From RFC-4006 Section 5.4 , It states that "When the end user terminates the service session, or when the graceful service termination described in section 5.6 takes place, the Diameter credit-control client MUST send a final Credit-Control-Request message to the credit-control server. The CC-Request-Type AVP is set to the value TERMINATION_REQUEST. The Service-Context-Id AVP indicates the service specific document applicable to the request."

Also one more scenario If the user logs off during an ongoing credit-control session, or if some other reason causes the user to become logged off (e.g., final-unit indication causes user logoff according to local policy), the service element, according to application specific policy, may send a Session-Termination-Request (STR) to the home Diameter AAA server as usual [DIAMBASE]. Figure 4 illustrates the case when the final-unit indication causes user logoff upon consumption of the final grantedunits and the generation of STR.

 Service Element        AAA Server        CC Server
   End User         (CC Client)
      | Service Delivery  |                    |                    |
      |<----------------->|                    |                    |
      |         :         |                    |                    |
      |         :         |                    |                    |
      |         :         |                    |                    |
      |                   |                    |                    |
      |                   | CCR(Update,Used-Units)                  |
      |                   |------------------->| CCR(Update,Used-Units)
      |                   |                    |------------------->|
      |                   |                  CCA(Final-Unit, Terminate)
      |              CCA(Final-Unit, Terminate)|<-------------------|
      |                   |<-------------------|                    |
      |         :         |                    |                    |
      |         :         |                    |                    |
      |  Disconnect user  |                    |                    |
      |<------------------| CCR(Termination,Used-Units)             |
      |                   |------------------->| CCR(Term.,Used-Units)
      |                   |                    |------------------->|
      |                   |                    |                CCA |
      |                   |                CCA |<-------------------|
      |                   |<-------------------|                    |
      |                   | STR                |                    |
      |                   |------------------->|                    |
      |                   |               STA  |                    |
      |                   |<-------------------|                    |

       Figure 1: User disconnected due to exhausted account

I request you to please refer the diagram from RFC-4006 from Section 5.4 , here I am not able to do proper identation.
Basically it is always Diameter Credit Control Client which may be GGSN or P-GW.

Thanks

answer Mar 30, 2016 by Chinmoy Padhi
Thanks Buddy
Similar Questions
+2 votes

Hi,

I am going through the spec 3gpp 29.219(Sy interface) and trying to understand the call flow and AVPS between the OCS and PCRF.

The PCRF sends the the list of Policy counters to OCS initially and OCS will store it against the Sy session. How does the Counter identifiers be identified uniquely b.w OCS and PCRF ?

Because the spec says, If the OCS determines that any policy counter identifiers are invalid, the OCS shall return a response with the Result-Code AVP set to DIAMETER_INVALID_AVP_VALUE.

But my doubt is, how the Policy counter Ids are known across the OCS and PCRF.

Any help in this area is very helpful

Thanks

+1 vote

I would like to know the behavior of GGSN when it receives ASR(Abort-Session-Request) from OCS(Online Charging System).

As I have gone through the RFC 3588, it was not explicitly stated that GGSN should report the usage of existing services(classified based on Rating-Group/Service-Identifier).

Could some explain here what is the expected behavior from GGSN?

Will GGSN come back to OCS with CCR-T with USU for all the existing services? Please shed some lights on this topic.

Can the below behavior be expected from GGSN? Appreciate your response on this topic.

+2 votes

Does the GGSN have an internal validity time configuration to terminate a gprs session?

+1 vote

Can we have a live scenario wherein PCRF gets multiple attach request(CCR-I) where only the Framed-IP-Address and Session-Id are different but Subscriber-Id information and APN remain same? From network point of view, what can be the use case for this?

...