Subject: RE: [Megaco] CAS Metering Pulse support

From: "Soncodi, Adrian" <[email-masked]>
Date: Fri, 3 Oct 2003 12:12:15 -0500

In some countries a tandem switch is required to propagate meter pulses (backwards) from the outgoing R2 trunk to the incoming R2 trunk. These pulses are used for billing. A potential problem is that the pulse rate may be very high, sometimes it can be a sub-second interval. Therefore, a tandem MGC which has a considerable number of R2 trunks will have a big overhead for propagating meter pulses, which will affect its call processing rate.

So I'm wondering if anything can be done about this. Here are two possibilities:

1) Allow the MG to detect meter pulses but report them in chunks of N. By default, N=1 (report every pulse), but the MGC could also select, say, N=10, in which case the MG reports once every 10 pulses. (A residual pulse count could be reported on Subtract). This method saves a lot of NTFY messages. However, on the other side, the MGC would be forced to propagate the pulses as bursts-of-N, and I am not sure a switch is allowed to transform constant-rate pulsing into bursts. (On the other hand why not? because it's only the total pulse count that is relevant for charging. Time-of-day periods with higher charging rates actually result in more meter pulses.)

2) Define a mode which allows the meter pulses to be propagated directly between MGs, without MGC involvement, i.e. by a method similar to RFC2833. RFC2833 does not currently have an event defined for meter pulses, but it could be extended, since it defines a lot of signaling-related tones anyway. In addition to solving the NTFY messaging overhead, this method would have the side benefit that it would also work between two MGCs that use SIP or BICC between them. Currently, there is no way to transport meter pulse information in SIP or BICC, and this would have a terrible overhead anyway.
Of course, the ability to detect meter pulses is still required, because there is always the possibility that the MGC must perform the meter-pulse-based charging itself (rather than propagate).

Any other ideas or comments?

Adrian Soncodi

-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: Thursday, October 02, 2003 10:38 PM
To: Aleksandr Ryabin
Cc: [email-masked]; Kevin Boyle
Subject: Re: [Megaco] CAS Metering Pulse support

Hello Aleksandr,

I'm happy enough to have the your proposed amendment if the editor agrees.

Regards, Christian

Aleksandr Ryabin wrote:
> Hi Christian,
> 
> No description of the event does say how to use it for detection
> incoming metering pulse. More over it explicitly limits to generation:
> "This event is used in conjunction with the "enable metering" and
> "metering pulse burst" signals defined in this package..."
> 
> My point being that descriptions of amet events and statistics
> are siting that event pr is generated and statistics are changed
> only based on previously applied em, or mbp signal.
> 
> The wording needs to be amended to cover the cases when event
> is generated and statistics are changed as a result *detection* of
> incoming metering pulse.
> 
> That is, for example, the text you have referenced should be changed
> to something like this (I've placed the changes in [] for visibility):
> 
> "If following the application [or detection] of any metering pulse 
> (regardless
> of [whether it was detected, or] whether it was generated as a result
> of the signal em or as a result of the signal mbp), the EventsDescriptor
> contains the event pr, and if the value of pcslr is equal to the value 
> of the
> EventsDescriptor parameter rp, then the pr event shall be notified, and
> the value of the statistic pcslr shall be reset to zero.  The detection of
> the event pr shall not cause the termination of the signal em or the
> signal mbp, [if currently active,] even if the KeepActive flag is not
> set for the pr event."
> 
> Regards,
>         Aleks
> 
> At 07:46 PM 10/2/2003, Christian Groves wrote:
> 
>> Hello Aleksandr,
>>
>> I agree that no new package is needed for the detection of metering 
>> pulse functionality. From the description of the event it seems that 
>> it clear how it to be used.
>>
>> The package also contains the procedural text:
>> "If following the application of any metering pulse (regardless of 
>> whether it was generated as a result of the signal em or as a result 
>> of the signal mbp), the EventsDescriptor contains the event pr, and if 
>> the value of pcslr is equal to the value of the EventsDescriptor 
>> parameter rp, then the pr event shall be notified, and the value of 
>> the statistic pcslr shall be reset to zero.  The detection of the 
>> event pr shall not cause the termination of the signal em or the 
>> signal mbp, even if the KeepActive flag is not set for the pr event."
>>
>> Is this text sufficient?
>>
>> Regards, Christian
>>
>> Aleksandr Ryabin wrote:
>>
>>> Hi,
>>> In continuation to this metering pulse support.
>>> I've looked through amet package and it does not seem to
>>> define procedure to detect metering pulses, it only has
>>> a procedure to generate metering pulses.
>>> I see no reason of defining a new package for detecting incoming
>>> metering pulses and I propose to reuse amet and amend it to
>>> define procedure for detecting incoming metering pulses.
>>> Here is the summary of a proposed metering pulse detection
>>> procedure using amet package:
>>> The detection of metering pulse on a termination could be enabled
>>> by MGC when no amet signals are played on a termination by
>>> requesting detection amet/pr event with a required repetition period.
>>> MG would Notify MGC with amet/pr event when number of metering
>>> pulses is detected according to repetition period parameter set.
>>> On Subtract, or explicit AuditValue MG would send amet/cpc
>>> and amet/pcslr statistics similar to as described in the package
>>> provided their description extended to detection as well.
>>> Comments?
>>> Thanks
>>>         Aleks
>>> BTW IANA MEGACO page is still not updated.
>>> At 10:50 AM 9/16/2003, Aleksandr Ryabin wrote:
>>>
>>>> It is updated with H.248.22 and 25, but not with 23, 24, 26, 27
>>>> while all of them are dated in ITU the same. Strange.
>>>>         Aleks
>>>>
>>>> At 10:46 AM 9/16/2003, Kevin Boyle wrote:
>>>>
>>>>> If it is NOT updated, that is. (Apparently, it's going to be one of 
>>>>> those days!)
>>>>>
>>>>> Kevin
>>>>>
>>>>> -----Original Message-----
>>>>> From: Boyle, Kevin [NCRTP:3Z40:EXCH]
>>>>> Sent: Tuesday, September 16, 2003 10:39 AM
>>>>> To: Aleksandr Ryabin; [email-masked]
>>>>> Subject: RE: [Megaco] CAS Metering Pulse support
>>>>>
>>>>> Ummm... yeah.  That's what I get for not looking it up before 
>>>>> sending the message. :)  While amet is defined in the "Extended 
>>>>> Analog Lines Packages" doc, there is nothing in the amet package 
>>>>> that actually limits it to analog lines.
>>>>>
>>>>>
>>>>> The updates for all the new (as of May) H.248 Sub-series 
>>>>> Recommendations have already been requested of IANA.  If it is 
>>>>> updated by the end of the month, I'll ping them again.
>>>>>
>>>>>
>>>>> Kevin
>>>>>
>>>>> -----Original Message-----
>>>>> From: Aleksandr Ryabin [mailto:[email-masked]]
>>>>> Sent: Tuesday, September 16, 2003 10:32 AM
>>>>> To: Boyle, Kevin [NCRTP:3Z40:EXCH]; [email-masked]
>>>>> Subject: RE: [Megaco] CAS Metering Pulse support
>>>>>
>>>>> Hi,
>>>>>
>>>>> I guess you meant H.248.26.
>>>>> Yes it seem to address the needs assuming it is extended to digital 
>>>>> lines as well.
>>>>>
>>>>> BTW IANA registry should be updated with H.248.26 and H.248.27
>>>>> http://www.iana.org/assignments/megaco-h248
>>>>> <http://www.iana.org/assignments/megaco-h248>
>>>>>
>>>>> Thanks,
>>>>>         Aleks
>>>>>
>>>>> At 10:00 AM 9/16/2003, Kevin Boyle wrote:
>>>>>
>>>>>
>>>>> H.248.27 has a metering package (automatic metering package or 
>>>>> amet).  This package may address your needs.
>>>>>
>>>>> Kevin
>>>>>
>>>>> -----Original Message-----
>>>>> From: Aleksandr Ryabin [mailto:[email-masked] 
>>>>> <mailto:[email-masked]> ]
>>>>> Sent: Tuesday, September 16, 2003 9:34 AM
>>>>> To: [email-masked]
>>>>> Subject: [Megaco] CAS Metering Pulse support
>>>>>
>>>>> Hi all,
>>>>>
>>>>> Below are excerpts from a previous exchange related to defining of 
>>>>> CAS Metering Pulse procedures in MEGACO.
>>>>>
>>>>> Now that CAS packages related work has been moved to ITU has anyone 
>>>>> done and/or planned anything in the direction to define CAS 
>>>>> Metering Pulse procedures/package for MEGACO?
>>>>>
>>>>> Thanks
>>>>>          Aleks
>>>>>
>>>>> >From: [email-masked]
>>>>> >To: Aleksandr Ryabin <[email-masked]>
>>>>> >cc: [email-masked], [email-masked], [email-masked]
>>>>> >Date: Tue, 4 Mar 2003 12:47:37 +0530
>>>>> >Subject: Re: [Megaco] Re: draft-ietf-megaco-r2package-03.txt : 
>>>>> Difference
>>>>> >         from previous revision
>>>>> ...
>>>>> >Aleksandr Ryabin <[email-masked]> on 03/03/2003 10:43:20 PM
>>>>> ...
>>>>> >3. I can't seem to find a way to implement "Metering Pulse" procedure
>>>>> >defined for some R2 variants using ether bcas or R2 packages? For
>>>>> >example, one of the definitions of such a pulse is a "seizure ack"
>>>>> >pulse from a terminating end on a circuit in connected/answer state.
>>>>> >
>>>>> >[Kushanava] Metering is not specific to R2. It may be present in any
>>>>> >CAS signaling. Moreover not all flavours of R2 permit metering to be
>>>>> >mandatory. There should be therefore a general philosophy of 
>>>>> attacking
>>>>> >this problem common to all CAS signaling. The solution should be
>>>>> >sensitive to
>>>>> >a) Realizing that MGC is the master for collecting and generating 
>>>>> charging
>>>>> >information
>>>>> >b) Interworking of the CAS "metering pulse" signals with other 
>>>>> signaling
>>>>> >(both PDN and PSTN)
>>>>> >c) Optimizing the network traffic if metering information is 
>>>>> transported to
>>>>>
>>>>> >and fro between MGC and MG
>>>>> >d) Latency, if metering information is transported to and fro 
>>>>> between MGC
>>>>> >and MG
>>>>> >We are working towards a separate package that addresses this issue.
>>>>> >Any suggestions?
>>>>> ...
>>>>>
>>>>> _______________________________________________
>>>>> Megaco mailing list
>>>>> [email-masked]
>>>>> https://www1.ietf.org/mailman/listinfo/megaco
>>>>> <https://www1.ietf.org/mailman/listinfo/megaco>
>>>>> _______________________________________________
>>>>> Megaco mailing list
>>>>> [email-masked]
>>>>> https://www1.ietf.org/mailman/listinfo/megaco
> 
> 

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed.  If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.  If you have received this email in error please notify the sender and delete the email. 

Santera, a Tekelec Company
http://www.santera.com
972-461-4100

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: Kushanava Laha <[email-masked]>
Date: Fri, 3 Oct 2003 11:55:04 -0700 (PDT)

All,

The primary reason why MGC is involved in CAS metering
is because it may need to do the billing. In which
case, metering pulse 'detection' on CAS trunks is the
only thing that it would be interested in and that too
the bulk aggregation of pulses at the end of the call.
So a simple stats property on the CAS termination
should serve the purpose (without the need of MGC
having to 'instruct' how the MG should collect the
pulses or how it should report the accumulated
pulses). At end of the call, MGC 'reads' the stats
through Subtract or explicit audits.

Secondly, in a pure CAS network, pulses traverse
end-to-end and it is usually a toll CAS exchange that
generates the pulses. Now, if one has CAS MGs in the
path, then the MGs should be capable of propagating
the metering pulses end-to-end. 

One way of doing this is to have MGs propagate the
metering pulses on RTP - similar to RFC 2833 (as
Adrian agrees). So the metering-receiving MG converts
the CAS metering pulses to RTP special payload packets
and the metering-transmitting MG regenerates the CAS
metering pulses from the RTP special payload packets.

The other way to do the same and also desired in other
interworking scenarios would be the out-of-band
propagation of the metering pulse via MGC. In order to
do so, the minimal information that needs to be known
by the MGC are a) Notification that MG has started
receiving pulses and the periodicity of the pulses b)
Update notifications from MG, when the pulse
periodicity changes e.g time-of-day transition.
Therefore, the metering-receiving MG must implement a
process of 'learning' the metering periodicity and
notify whenever there is a change (MG can notify a
default periodicity in the beginning so that charging
corresponding to the first couple of pulses are not
lost). Based on these two information, MGC can
recreate or regenerate the metering pulse information
on the other MG. 

On the metering-transmitting CAS MG if the metering
pulse needs to be applied out-of-band via the MGC, MGC
should be equipped with the metering pulse application
package. In same lines, the minimal information that
needs to be applied to the CAS MG are (a) Start
generating pulses at periodicity 'x' (b) Updates of
the new periodicity, whenever the period changes. On
the transmitting MG there also could be a statistics
by which the MGC can read at the end of the call how
many total pulses the MG has transmitted. This could
also be used by the MGC for billing the CAS trunks of
the transmitting MG.

All said and done, I also feel that notification of
pulse counts from both the receiving and transmitting
MGs are also necessary during a call (and not just at
the end of the call). This could be required by the
MGC to monitor the call based on charging e.g.
pre-paid calls. Hence we should retain the mechanism
of MGC signaling the MG to report the pulse
transmit/receive bucket when it crosses a
MGC-set-threshold.

The CAS metering solution should take all of the above
into account.

regards,
Kushanava   

Question is why do we at all require MGC to know
(detect) or apply the metering pulses in case of CAS.
(1) MGC will do the billing
(2) MGC needs to pass the metering 

--- "Soncodi, Adrian" <[email-masked]>
wrote:
> In some countries a tandem switch is required to
> propagate meter pulses (backwards) from the outgoing
> R2 trunk to the incoming R2 trunk. These pulses are
> used for billing. A potential problem is that the
> pulse rate may be very high, sometimes it can be a
> sub-second interval. Therefore, a tandem MGC which
> has a considerable number of R2 trunks will have a
> big overhead for propagating meter pulses, which
> will affect its call processing rate.
> 
> 1) Allow the MG to detect meter pulses but report
> them in chunks of N. By default, N=1 (report every
> pulse), but the MGC could also select, say, N=10, in
> which case the MG reports once every 10 pulses. (A
> residual pulse count could be reported on Subtract).
> This method saves a lot of NTFY messages. However,
> on the other side, the MGC would be forced to
> propagate the pulses as bursts-of-N, and I am not
> sure a switch is allowed to transform constant-rate
> pulsing into bursts. (On the other hand why not?
> because it's only the total pulse count that is
> relevant for charging. Time-of-day periods with
> higher charging rates actually result in more meter
> pulses.)
> 
> 2) Define a mode which allows the meter pulses to be
> propagated directly between MGs, without MGC
> involvement, i.e. by a method similar to RFC2833.
> RFC2833 does not currently have an event defined for
> meter pulses, but it could be extended, since it
> defines a lot of signaling-related tones anyway. In
> addition to solving the NTFY messaging overhead,
> this method would have the side benefit that it
> would also work between two MGCs that use SIP or
> BICC between them. Currently, there is no way to
> transport meter pulse information in SIP or BICC,
> and this would have a terrible overhead anyway.
> Of course, the ability to detect meter pulses is
> still required, because there is always the
> possibility that the MGC must perform the
> meter-pulse-based charging itself (rather than
> propagate).
> 
> From: Christian Groves
> [mailto:[email-masked]]
=== message truncated ===

=====
Kushanava Laha
Hughes Software Systems

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

---

From: Kushanava Laha <[email-masked]>
Date: Fri, 3 Oct 2003 11:55:04 -0700 (PDT)

All,

regards,
Kushanava   

=====
Kushanava Laha
Hughes Software Systems