Thanks Martin for a detailed reply. sorry for the delay ( due to time zone difference)
I understand about the boundaries and objectives of the clear water project. So, with that perspective, my question is still a deviation from the scope and the objectives you have described. Anyway, i am duty bound to give you an answer/update you with my perspective about my recommendations. May be once your current objectives of the clear water project are met, then these recommendations may bring out some relevancy. 1. QoS - SCP - a larger perspective over and above the session charging function. It is about the service control function interface. ( from the service stratum), since the core IMS interfaces with the Virtual network and transport interfaces in this proposed implementation. Particularly the QoS signalling set to be handled by the Admission control function (more than the admission decisions, the inherited QoS decisions) of the NGN core policy decision and QoS enforcement engine. The use case is obvious one like service mobility over HetNet environment, which is essentially the way forward. 2. I accept your view on my second recommendation. since from my perspective it will be an equally important but relevant to my first recommendations. In addition to the P-preferred Identify of the SDP capability which is a first step towards handling and managing multiple but associated end points for one or more sessions, the value of managing multiple PUI for multiple device or service end points based on any specific of particular user profile and its associated signalling and QoS may make the enforcement a bit complex. Anyway that is not the current focus of clear water. I understand. 3. Thanks. I may be more interested in taking a serious part when you are doing the IOT with MGCP and also during its preparation. If possible, i would be more than willing to see the code base for its readiness and any value add.. Thanks Chandra On Mon, Jun 10, 2013 at 7:12 PM, Martin Taylor <[email protected] > wrote: > Chandra**** > > ** ** > > It would be helpful to get a bit more information from you about the use > cases that you have in mind for items (1) and (2) on your list, but I’ll > try and respond as best I can without fully understanding the requirement. > **** > > ** ** > > Item (1) is concerned with the Session Charging Function, which is defined > in IMS as an Application Server that keeps an eye on session usage for each > pre-paid subscriber and tears down sessions when credit runs out. We can > imagine a use case where QoS is reduced once credit runs out – is this what > you have in mind? However it’s not clear how you would signal that change > of QoS from the SCF through the IMS core. In any case, SCF is, by > necessity, a dialog-stateful entity and because of this we would not plan > to implement it as part of Clearwater. The Clearwater architecture is > transaction-stateful only, and this is what makes it possible to scale out > in the Cloud very straightforwardly, so we don’t really want to compromise > that. In other words, we view SCF as out of scope for Clearwater, but you > could certainly connect an SCF to Clearwater’s ISC interface.**** > > ** ** > > Item (2) feels like a candidate for implementation in the access SBC, > which would typically talk to a Policy and Charging Rules Function and is > therefore in a good position to request different QoS levels for different > public identities. It isn’t clear to us that this would be all that useful > though, since a given user can signal any P-Preferred-Identity that it owns > and hence would be in a position to “cheat” if you had different QoS > classes for different public identities.**** > > ** ** > > On item (3), Clearwater does already implement a very basic BGCF which > simply uses ENUM to drive decisions on routing to other networks. It is > our intention that Clearwater supports the Mg and Mj interfaces towards the > MGCF and in principle that function is already present in the codebase, > although we still have some work to do to ensure that we actually interop > with real-world MGCFs. We will be testing with Metaswitch’s Media Gateway > Controller product ( > http://www.metaswitch.com/sites/default/files/Metaswitch-IMS-MGCF.pdf) in > due course. We don’t have any plans to open source the MGCF.**** > > ** ** > > Martin**** > > ** ** > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Chandra > Pillai > *Sent:* 10 June 2013 14:15 > *To:* [email protected] > *Subject:* [Clearwater] Fwd: Signup at Project Clearwater**** > > ** ** > > Hi All,**** > > > I want to suggest the following for the **** > > Ro**** > > admap. > > 1. QoS from SCF > > 2. QoS in a situation like multiple Public ids associated for different > end user application with one private id > > 3.**** > > MGCF and BGCF - Control plane Mi,j,g**** > > Thanks**** > > Chandra**** > > --**** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > -- > Copy right protected, private materials, content and details are attached > with this mail. This Message is a PRIVATE communication and sent in > confidence to the addressee only. It may contain legally privileged > information. The contents are not to be disclosed to anyone other than the > addressee. Unauthorized recipients are hereby requested/notified that any > dissemination, review, disclosure, printing, copying, distribution or use > of the information contained in or attached to this message is strictly > prohibited, in order to preserve the confidentiality and to advise the > sender immediately of any error in transmission and then delete it from > their system. E-mail may be corrupted, intercepted or amended and so we do > not accept any liability for the contents received unless they are the same > as sent by us. The recipient should check this email and any attachments > for the presence of viruses. We accept no liability for any damage caused > by any virus transmitted by this email. E&OE.**** > -- Copy right protected, private materials, content and details are attached with this mail. This Message is a PRIVATE communication and sent in confidence to the addressee only. It may contain legally privileged information. The contents are not to be disclosed to anyone other than the addressee. Unauthorized recipients are hereby requested/notified that any dissemination, review, disclosure, printing, copying, distribution or use of the information contained in or attached to this message is strictly prohibited, in order to preserve the confidentiality and to advise the sender immediately of any error in transmission and then delete it from their system. E-mail may be corrupted, intercepted or amended and so we do not accept any liability for the contents received unless they are the same as sent by us. The recipient should check this email and any attachments for the presence of viruses. We accept no liability for any damage caused by any virus transmitted by this email. E&OE.
_______________________________________________ Clearwater mailing list [email protected] http://lists.projectclearwater.org/listinfo/clearwater
