Subject: RE: Silence compression, a necessary feature for TDM emulation?

From: "Yaakov Stein" <[email-masked]>
Date: Thu, 26 Jun 2003 08:56:01 +0300

Max, 

> It seems silence compression is considered an important 
> feature of the TDM emulation. During the discussion on Tom's prposal for TDM 
> emulation we agreed to keep silence compression out of the basic 
> specification for TDM emulation.

There are actually two distinct levels here,
activity detection and silence compression.

Activity detection is more general,
and may be based on TDM signaling
(on-hook vs. off-hook status) for simple cases.
True "silence detection" or Voice Activity Detection (VAD)
requires that the computational resources be available.

I think leaving out discussion of activity detection based
on signaling is a major lacuna. VAD is perhaps
more specifically a voice-services issue,
and perhaps beyond the scope of the TDM requirements
document.

> Just silence compression, or should we go for some kind of 
> generic data compression with reasonable efficiency for voice signals?

Silence "compression" is not really compression at all.
I don't see the connection with data compression.

Data compression is definitely out of scope here,
as it is not TDM specific; but perhaps someone would like
to write a draft on generic data compression for PWE.

Y(J)S

---

From: "Amnon Ilan" <[email-masked]>
Date: Thu, 26 Jun 2003 09:49:23 +0200

Max,

> Is there a reason to add silence compression as an additional
> requirement in the TDM requirements I-D?
>
IMO TDM requirements should relate to silence compression: it
should be an optional feature (not a must).
As Yaakov wrote, there are two basic approaches:
1. Adding and tearing-down specific DS0 channels from a trunk\bundle
  based on the signaling information.
  The requirement from the TDM-PW in this case is to be able to add
  and tear-down DS0 in "real-time" (the application should be able
  to snoop and parse the specific signaling protocol, but this
  has no implication to the TDM-PW itself).
2. Using VAD (voice activity detection) and CNG (comfort noise
  generation). The requirement from the TDM-PW in this case is to
  be able to send the coded CNG information across the PSN.
  This method is more general than the former, since it is
  independent of the signaling protocol on the TDM line.

> generic data
> compression with reasonable efficiency for voice signals?
>
An issue relevant for that question is low-bit-rate coding for voice
traffic. There should be an option for both sides of a TDM-PW to
signal or have some payload type specifying the coder (with the
TDMoIP approach this could be done using AAL2). This should also
be an optional feature mentioned in the requirements.

Amnon.

---

From: [email-masked]
Date: Thu, 26 Jun 2003 09:50:00 +0100

Max,

As Amnon and Yaakov have pointed out, there are actually two issues here, 
suppressing unused channels and silence suppression.

The first, turning off channels when not in use was accounted for in the 
DB-CES standard for ATM (af-vtoa-0085). However, as far as I am aware, 
this was not widely deployed. This was due to the fact that in order to 
obtain the Constant Bit Rate class of service in ATM, the bandwidth had to 
be provisioned anyway, so saving bandwidth using DB-CES didn't actually 
free up any bandwidth for anything else.

For "carrier class" circuit emulation, I think we will have the same 
issues. In order to deliver full quality TDM, and meet any service level 
guarantees, it will be necessary to provision the bandwidth for the peak 
case. Therefore once again, there is not much point to suppressing unused 
channels.

For "enterprise class" circuit emulation (e.g. across a corporate network 
or VPN), it may be a useful technique to save bandwidth, while accepting 
the drop in quality over use of the PSTN. Since a corporate network is 
usually small relative to the carrier networks, this drop in quality may 
not necessarily be large.

Therefore I would support the suppression of unused channels being an 
_optional_ requirement.

Silence suppression is another topic entirely, due to its intensive DSP 
requirement. I agree with Yaakov that this is probably outside the scope 
of PWE3. Similarly with low-bit rate voice coding. 

Regards,
Tim

"Amnon Ilan" <[email-masked]>
Sent by: [email-masked]
26-Jun-2003 08:49 AM
Please respond to ailan

        To:     "'Max Riegel'" <[email-masked]>, <[email-masked]>
        cc: 
        Subject:        RE: [PWE3] Silence compression, a necessary feature for TDM emulation?

Max,

Amnon.

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

---

From: Max Riegel <[email-masked]>
Date: Thu, 26 Jun 2003 23:39:58 +0200

It seems there is consensus, that we should add suppression of unused 
channels as an optional requirement to the TDM requirements I-D.

Thank you Yakovv, Amnon and Tim for your explaination of the issues 
arising with silence compression. I agree that the voice activity 
detection requireing voice-service specific signal processing belongs to 
payload specifics and is outside the scope of wire emulation.

We have already mentioned in chapter 7.5: PSN bandwidth utilization

    3.  The encapsulation layer MAY provide the ability to save the PSN
        bandwidth for the structured case by not sending sub-circuits
        that are inactive.

This describes the static case of configuring a PW for a fixed number of 
channels. To extend the ability to dynamically suppress unused channels 
from transmission I would add:

    4.  The encapsulation layer MAY enable the dynamic suppression of
        temporally unused channels from transmission for the structured
        case.

I think that such a kind of function makes only sense for structured 
circuits.

Bye
Max

[email-masked] wrote:
> ...