-
Notifications
You must be signed in to change notification settings - Fork 154
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Gy interface #43
Comments
As agreed today @aferreiraguido, I assigned this to you. |
Thanks @FerUy, just to be clear on the matter, let me write down some concepts: We do have first the RFC-4006, which is the base for any Credit Control Application (id 4, vendor 0) over Diameter, plus it's also the base definition for messages exchange, here we have CCR/CCA messages defined plus the re-authorization for sub-sessions RAR/RAA. With the basic CC Application, you can charge one time event (even refund) and data sessions as well. Then it goes Ro (id 4, vendor 10415) from 3GPP which is the online charging reference point from any 3G network element and the OCS. We do also have Gy from 3GPP which is the same interface, although defined specifically for PCEF <-> OCS interworking, while the first is related to any CTF [MRFC] on the 3G network. In general, we can see Ro and Gy the same, actually both are considered functionaly equivalents by 3GPP. Having said that, we require some extra messages to be defined for Ro/Gy to be fully compliant with 3GPP standards [32240, 32251, 32299]. The base CCR/CCA and Re-Auth are defined in app/cca seamlessly app/ro, although Disconnect-Peer and Abort-Session not, besides implementing Device-Watchdog and Capabilities-Exchange as well, to be fully compliant with Ro/Gy, which I do recommend to complete the app/ro classes and events. Hope this clarifies the issue. |
I don't understand what exactly differentiates Ro from Gy. We may miss support for properly handling ASR/ASA in Ro but I don't see how Disconnect-Peer, Device-Watchdog and Capabilities-Exchange come into discussion here, as these are peer management messages that are unrelated to the specification, they are provided by Diameter Base and at no point should any Diameter Application interfere with these. So I think what might be relevant to this issue is to understand what (if anything) differs between Ro an Gy (in my understanding they are the same, use the same Messages and AVPs but they apply to different networks and are between different elements). If there's nothing differentiating them, we should just keep Ro and fix it where it falls short. Possibly Gy introduces some new(er) AVPs, but if that's the case and the only difference, it's best to overload Ro with those. Maintaining two identical interfaces seems overkill. |
Mmm maybe I did not explain myself completely. app/cca is perfectly well. Regarding functionally equivalences, Ro = Gy (just that somehow the Ro interface between PCEF and OCS is labeled Gy). 3GPP TS 32.299 defines those extra messages which are also referenced as format defined in RFC 3588. As per my understanding according with the standard, those should be managed within Ro/Gy, maybe not... |
Ro is the generic interface that can be used to describe any OCS interface, where Gy is an example of a specific one for charging. Ro and Gy both use different application IDs - and this is being defined in the dictionary xml. Also Gy requires some additional AVPs which provide the actual charging functionality. So in my mind Ro and Gy are different. I've got a working Gy implementation - should be able to post a pull request in a couple of days @brainslog I get your point the similarities between the interfaces, a lot of the jdiameter interfaces appear very similar so there could be an opportunity to refactor here |
@pmcgleenon as mentioned before, Ro is the generic online charging interface between CTF (Charging Triggering Function) and OCF (Online Charging Function), which is basically the same you state in your message. Thus, according to my understanding, Ro is the interface for functions, while Gy is a name for the Ro interface for PCEF - OCS interworking systems in the PS domain. That is what is stated in section 4.4.2.1 [3GPP TS 32.240 V14.0.0 (2016-06)], which mention Ro as the generic interface between CTF and OCF, although in 4.4.2.3 and regarding Gy says "The Gy reference point is functionally equivalent to Ro, and hence is replaced by Ro within the common charging architecture". I am also not aware of the different AppId's nor avp's you mention for Ro and Gy, please let me know where those are recommended as maybe I overead something on 32.251 or 32.240 besides 32.240 mentioned by @FerUy. I concur with you (and @FerUy) on the required message implementation for Ro, but also concur with @brainslog to avoid having two set of classes to cover interfaces that are basically the same, I think the Ro require the missing implementation, but for me Gy shall fall back to Ro messages and state machine Impl, if not just used as a label when adding listeners and generating instances from factory classes. Regarding the pull request... that would be awesome! actually I was about to implement as I require that for a potential project, but if you can share, I will be more than happy to include in my version 👍 |
@FerUy, @aferreiraguido & @pmcgleenon, I am still not convinced that Gy is any different from Ro. And the more I try to figure out, the more convinced I am that they aren't, as in section 4.3 of 3GPP TS 32.251, namely: Can someone provide actual evidence of differences ? Thanks! |
Hello @brainslog, As per my understanding and as stated on my last post, Gy is just the name given to the OCS-PCEF Ro reference point, I do only use Ro to refer to the charging interface reference point ever since. Although and regarding the main subject that motivated this thread, I am still positive that some messages are missing on Ro reference point which I think we should implement those, would be great if we can discuss the best approach as you mentioned some of them are on the underlying protocol as well. Regards, |
For SMS over LTE, like mentioned in RestComm/smscgateway#85, it will be crucial also to fully implement Gy interface between OCS and and PCEF (Policy and Charging Enforcing Function), analog to Ro interface, already implemented. Diameter messages for Gy are defined in 3GPP TS 32.299, charging architecture and principles in 3GPP TS 32.240, Packet-Switched domain charging in 3GPP TS 32.251.
The text was updated successfully, but these errors were encountered: