Subject: RE: [ipcdn] IETF NCS Sig MIB Gain (loss) plan and tone Levels

From: "Eugene Nechamkin" <[email-masked]>
Date: Wed, 22 Jun 2005 11:23:23 -0700

After looking at the "pktcNcsEndPntConfigTxGain" and
"pktcNcsEndPntConfigRxGain" MIB objects more closely, here are some concerns
with these objects resurrected in draft-08 since being obsolete in draft-02.
 
The concerns are two-fold:
 
1. The real value in having this solution for future proofing:
As Rich pointed out, we are trying to future proof the unknown requirements.
If this becomes important in the future then we can figure it out then, it is
impossible to solve everything up front without understanding all the
problems and consequences. The draft-02 has obsolete these two objects after
the extensive discussions. Are the problems these two MIB objects are
presumably solving important enough to consider the draft change given the
current late stage.
 
2. Implementation problems associated with the functionality introduced by
these two objects
We understand the benefits of having configurability to meet different
country specifications. However, the gain/loss plan is only one component in
trying to adapt to different country deployments. The MIB doesn't address
other items such as complex impedance, ring voltage, etc. By trying to
address the gain/loss in isolation we are actually creating implementation
difficulties. This is already solved by MTA manufactures through more
intelligent and coordinated methods using both H/W and S/W
 
Providing the ability to dynamically adjust gains means that you are
inherently limiting the dynamic range of the DSP to try and address all
corner case scenarios. This is a huge implementation problem. Often the per
country matching of complex impedances and gains is done in H/W or within the
analog interface components like the SLIC. These interfaces are configured
for a given country specifications independent of signaling MIBs. This
creates a problem when you want to have the gain setting larger than the
natural country default. The only solution to meet the desired MIB value is
to generate a loud signal (likely clipping within the DSP) in order to adjust
for the analog hardware gain.
 
Eugene Nechamkin,
 
Broadcom Corp.

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Woundy, Richard
Sent: Tuesday, February 15, 2005 4:48 PM
To: 'Freyman Phillip-FPF300'
Cc: [email-masked]'
Subject: RE: [ipcdn] IETF NCS Sig MIB Gain (loss) plan and tone Levels

>While it is recognized that current standard connection establishment
protocols (NCS, SIP) do not support dynamic gain (loss) plan negotiation or
assignment at this time, it should be recognized that by establishing the MIB
now will enable future protocol updates to improve the end user experience.
 
Or sometimes, they interfere with future protocol updates. :^(
 
For example, do your proposed read-write MIB object value override the
NCS/SIP negotiated value? Or vice versa?
 
-- Rich, ordinary cable guy, Comcast

	-----Original Message-----
	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Freyman Phillip-FPF300
	Sent: Tuesday, February 15, 2005 2:07 PM
	To: [email-masked]'; [email-masked]'
	Subject: [ipcdn] IETF NCS Sig MIB Gain (loss) plan and tone Levels

	Colleagues,

	This is a proposal to establish the Transmit and Receive gain (loss)
plan parameters in the SigMIB to provide a solution to the setting of
supervisory tone levels at the a-b termination points and it also provides an
intelligent approach to future migration of a dynamic gain (loss) plan based
on the connection requirements.

	The first point to consider in this proposal is when the MTA passes
in band signaling tones.  Per CableLabs and ETSI these tones are passed to
the POTS a-b (T/R) termination points through signal paths that apply a known
loss.  This is usually implemented in the POTS SLIC circuitry either with
fixed loss devices or provisioned by the vendor/operators. 

	However, when directed by the Call Agent the MTA may generate the
supervisory tones locally.  The same loss plan specifications per CableLabs
and ETSI for in band signaling are assumed to still be active when the tones
are locally generated.  Therefore it is necessary for the internal
supervisory tone generator to compensate for the analog gain (loss) in the
MTA (Typically in the POTS SLIC circuitry) to achieve the desired level at
the a-b (T/R) termination point.  While this gain (loss) may be known to a
vendor during manufacture, the second consideration in this proposal suggests
that this gain (loss) may be required to be changed based on far end (analog
loop) connection characteristics that change depending on the actual far end
connection point.

	While CableLabs PKT-SP-EMTS-PRIMARY-I01-001128 Clause 8.4.4 and
Telcodia GR-909-CORE R5-17 guildance suggest a 2 dB loss plan default
setting, there is also guildance in GR-909-CORE R4-134 referencing ANSI
T1.401-1988 Figure 24 that DTMF levels may be as high as +4 dBm under low
loop current conditions.  Per Telcordia GR-506-CORE Clause 15.1.5, the DTMF
receiver acceptance levels must be greater than -25 dBm and less than 0 dBm.
Considering a + 4dBm DTMF level applied to a 2 dB loss plan would resulting a
DTMF PCM coding level greater than the GR-506-CORE guidance of 0 dBm maximum
for the DTMF detector.  The setting of the default value to -4 dB gain,
ensures proper DTMF signal quality for proper detection and is also
consistent with Telcordia GR-909-CORE which references TR-NWT-000057 for
parameter settings and where 6.1.8 DLC System Loss O-11 suggests a DLC
transmission path loss in each direction o the RT line unit should be 4 dB
+/-2 dB (- 4 dB gain).  

	Guidance in TIA/EIA TSB122-A and ETSI ES 202 020 further offers the
need to adjust the gain (loss) plan based on if a given MTA is attempting a
connection to one of several analog POTS termination points.  In reviewing
these documents if one considers the MTA as the referenced ONU unit, various
connection cases can be made (ONU to OPS, DGS, WAN, DAL, FXO, FXD, or ATT or
these terminations back to the ONU) where the recommended gain (loss) plan
per connection vary between 0 dB and 9 dB in loss or in some cases 3 dB of
gain.

	While it is recognized that current standard connection establishment
protocols (NCS, SIP) do not support dynamic gain (loss) plan negotiation or
assignment at this time, it should be recognized that by establishing the MIB
now will enable future protocol updates to improve the end user experience.

	Finally, a text enhancement is proposed to clarify the
pktcSigDevToneDbLevel tone level setting measurement with respect to complex
tones (tones sometimes consisting of more than one frequency).

	Respectfully,

	Phillip Freyman

	Distinguished Member of the Technical Staff

	Motorola Connected Home Solutions (formally BCS)

	
=============================================================================
=============================================

	   pktcNcsEndPntConfigTxGain                  Integer32,  

	       pktcNcsEndPntConfigRxGain                  Integer32  

	   pktcNcsEndPntConfigTxGain    OBJECT-TYPE  

	       SYNTAX       Integer32 

	       UNITS        "dB"  

	       MAX-ACCESS   read-write

	       STATUS       current  

	       DESCRIPTION  

	           "The per line transmitter (A/D) gain.  A positive number
reflects a signal gain, a negative number reflects a signal loss.  This
Object may provision the gain or it may be used to document a
non-provisionable gain between the telco (POTS) a-b (T/R) terminals and the
analog codec maximum PCM coding limit (PCM maximum coding limit).  

	Based on the default G.711 Vocoder maximum of 3.14 or 3.17 dBm the -4
dB gain default provides Vocoder coding protection against TE maximum signals
while also providing an initial loss to minimize analog signal echo.  

	       DEFVAL { -4 }  

	       ::= { pktcNcsEndPntConfigEntry 42 }  

	 

	   pktcNcsEndPntConfigRxGain    OBJECT-TYPE  

	       SYNTAX       Integer32 

	       UNITS        "dB"  

	       MAX-ACCESS   read-write  

	       STATUS       current  

	       DESCRIPTION  

	           "The per line receiver (D/A) gain. A positive number
reflects a signal gain, a negative number reflects a signal loss.  This
object may provision the gain or it may be used to document a
non-provisionable gain for use with the pktcSigDevToneDbLevel Object to set
the desired level at the a-b (T/R) terminals.  

	Based on the default G.711 Vocoder maximum of 3.14 or 3.17 dBm the -4
dB gain default provides a maximum analog signal level at the a-b (T/R)
termination point. It should be noted that ETSI TS 101 909-4 provides
guidance of 11 dB loss (-11 dB gain) and based on this reference a DEFVAL {
-11 } in international markets may be considered.  

	       DEFVAL { -4 }  

	       ::= { pktcNcsEndPntConfigEntry 43 }  

	pktcSigDevToneDbLevel    OBJECT-TYPE 

	       SYNTAX       TenthdBm (-250..-30) 

	       UNITS        "dBm"  

	       MAX-ACCESS   read-write  

	       STATUS       current  

	       DESCRIPTION  

	           "This is the decibel level for each analog signal (tone)
that is locally generated (verses in band supervisory tones) and sourced to
the a-b terminals (TE connection point).  Per the PktcSigDevToneEntry this
DbLevel represents the level required for each tone where each tone may
consist of multiple frequencies which may be summed or amplitude modulated.
This Object must reflect the desired level at the Telco (POTS) a-b (T/R)
terminals including the affect of the pktcNcsEndPntConfigRxGain setting on
the delivered tone.  The wide range of levels for this Object is required to
provide signal generator levels across the wide range of gains but does not
imply the entire range is to be achievable given the range of negative values
of gain (positive loss).     This Object must be set for each tone so as to
generate the combined frequency level at the a-b (T/R) terminals." 

	       DEFVAL { -40 }  

	       ::={pktcSigDevToneEntry 2 }  

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

---

From: "Sumanth Channabasappa" <[email-masked]>
Date: Wed, 22 Jun 2005 16:14:22 -0600

Eugene,
 
The discussion resulting in this addition is detailed as COMMENT SET
#6/7 in the email referenced
via the following link (and you did reference the contents in your email
as well):
 
http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01594.html

Since there were no concerns posted then, it was submitted as
recommended. 
 
(I should admit that the exclusion in draft-02 was not realized when the
proposal was 
submitted - apologies)
 
I would appreciate other thoughts from implementors or experts on this
subject matter since
the issues raised seem to be that of implementation.

Thanks
Sumanth

  _____  

From: Eugene Nechamkin [mailto:[email-masked]] 
Sent: Wednesday, June 22, 2005 12:23 PM
To: Richard Woundy @ Comcast; Freyman Phillip-FPF300
Cc: [email-masked]
Subject: RE: [ipcdn] IETF NCS Sig MIB Gain (loss) plan and tone Levels

After looking at the "pktcNcsEndPntConfigTxGain" and
"pktcNcsEndPntConfigRxGain" MIB objects more closely, here are some
concerns with these objects resurrected in draft-08 since being obsolete
in draft-02.

1. The real value in having this solution for future proofing:
As Rich pointed out, we are trying to future proof the unknown
requirements. If this becomes important in the future then we can figure
it out then, it is impossible to solve everything up front without
understanding all the problems and consequences. The draft-02 has
obsolete these two objects after the extensive discussions. Are the
problems these two MIB objects are presumably solving important enough
to consider the draft change given the current late stage.
 
2. Implementation problems associated with the functionality introduced
by these two objects
We understand the benefits of having configurability to meet different
country specifications. However, the gain/loss plan is only one
component in trying to adapt to different country deployments. The MIB
doesn't address other items such as complex impedance, ring voltage,
etc. By trying to address the gain/loss in isolation we are actually
creating implementation difficulties. This is already solved by MTA
manufactures through more intelligent and coordinated methods using both
H/W and S/W
 
Providing the ability to dynamically adjust gains means that you are
inherently limiting the dynamic range of the DSP to try and address all
corner case scenarios. This is a huge implementation problem. Often the
per country matching of complex impedances and gains is done in H/W or
within the analog interface components like the SLIC. These interfaces
are configured for a given country specifications independent of
signaling MIBs. This creates a problem when you want to have the gain
setting larger than the natural country default. The only solution to
meet the desired MIB value is to generate a loud signal (likely clipping
within the DSP) in order to adjust for the analog hardware gain.
 
Eugene Nechamkin,
 
Broadcom Corp.

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Woundy, Richard
Sent: Tuesday, February 15, 2005 4:48 PM
To: 'Freyman Phillip-FPF300'
Cc: [email-masked]'
Subject: RE: [ipcdn] IETF NCS Sig MIB Gain (loss) plan and tone Levels

>While it is recognized that current standard connection establishment
protocols (NCS, SIP) do not support dynamic gain (loss) plan negotiation
or assignment at this time, it should be recognized that by establishing
the MIB now will enable future protocol updates to improve the end user
experience.

 

	-----Original Message-----
	Subject: [ipcdn] IETF NCS Sig MIB Gain (loss) plan and tone
Levels

	Colleagues,

	This is a proposal to establish the Transmit and Receive gain
(loss) plan parameters in the SigMIB to provide a solution to the
setting of supervisory tone levels at the a-b termination points and it
also provides an intelligent approach to future migration of a dynamic
gain (loss) plan based on the connection requirements.

	The first point to consider in this proposal is when the MTA
passes in band signaling tones.  Per CableLabs and ETSI these tones are
passed to the POTS a-b (T/R) termination points through signal paths
that apply a known loss.  This is usually implemented in the POTS SLIC
circuitry either with fixed loss devices or provisioned by the
vendor/operators. 

	However, when directed by the Call Agent the MTA may generate
the supervisory tones locally.  The same loss plan specifications per
CableLabs and ETSI for in band signaling are assumed to still be active
when the tones are locally generated.  Therefore it is necessary for the
internal supervisory tone generator to compensate for the analog gain
(loss) in the MTA (Typically in the POTS SLIC circuitry) to achieve the
desired level at the a-b (T/R) termination point.  While this gain
(loss) may be known to a vendor during manufacture, the second
consideration in this proposal suggests that this gain (loss) may be
required to be changed based on far end (analog loop) connection
characteristics that change depending on the actual far end connection
point.

	While CableLabs PKT-SP-EMTS-PRIMARY-I01-001128 Clause 8.4.4 and
Telcodia GR-909-CORE R5-17 guildance suggest a 2 dB loss plan default
setting, there is also guildance in GR-909-CORE R4-134 referencing ANSI
T1.401-1988 Figure 24 that DTMF levels may be as high as +4 dBm under
low loop current conditions.  Per Telcordia GR-506-CORE Clause 15.1.5,
the DTMF receiver acceptance levels must be greater than -25 dBm and
less than 0 dBm.  Considering a + 4dBm DTMF level applied to a 2 dB loss
plan would resulting a DTMF PCM coding level greater than the
GR-506-CORE guidance of 0 dBm maximum for the DTMF detector.  The
setting of the default value to -4 dB gain, ensures proper DTMF signal
quality for proper detection and is also consistent with Telcordia
GR-909-CORE which references TR-NWT-000057 for parameter settings and
where 6.1.8 DLC System Loss O-11 suggests a DLC transmission path loss
in each direction o the RT line unit should be 4 dB +/-2 dB (- 4 dB
gain).  

	Guidance in TIA/EIA TSB122-A and ETSI ES 202 020 further offers
the need to adjust the gain (loss) plan based on if a given MTA is
attempting a connection to one of several analog POTS termination
points.  In reviewing these documents if one considers the MTA as the
referenced ONU unit, various connection cases can be made (ONU to OPS,
DGS, WAN, DAL, FXO, FXD, or ATT or these terminations back to the ONU)
where the recommended gain (loss) plan per connection vary between 0 dB
and 9 dB in loss or in some cases 3 dB of gain.

	While it is recognized that current standard connection
establishment protocols (NCS, SIP) do not support dynamic gain (loss)
plan negotiation or assignment at this time, it should be recognized
that by establishing the MIB now will enable future protocol updates to
improve the end user experience.

	Finally, a text enhancement is proposed to clarify the
pktcSigDevToneDbLevel tone level setting measurement with respect to
complex tones (tones sometimes consisting of more than one frequency).

	Respectfully,

	Phillip Freyman

	 
	
========================================================================
==================================================

	       SYNTAX       Integer32 

	       UNITS        "dB"  

	       MAX-ACCESS   read-write

	       STATUS       current  

	       DESCRIPTION  

	           "The per line transmitter (A/D) gain.  A positive
number reflects a signal gain, a negative number reflects a signal loss.
This Object may provision the gain or it may be used to document a
non-provisionable gain between the telco (POTS) a-b (T/R) terminals and
the analog codec maximum PCM coding limit (PCM maximum coding limit).  

	Based on the default G.711 Vocoder maximum of 3.14 or 3.17 dBm
the -4 dB gain default provides Vocoder coding protection against TE
maximum signals while also providing an initial loss to minimize analog
signal echo.  

	       DEFVAL { -4 }  

	 

	       SYNTAX       Integer32 

	       UNITS        "dB"  

	       MAX-ACCESS   read-write  

	       STATUS       current  

	       DESCRIPTION  

	           "The per line receiver (D/A) gain. A positive number
reflects a signal gain, a negative number reflects a signal loss.  This
object may provision the gain or it may be used to document a
non-provisionable gain for use with the pktcSigDevToneDbLevel Object to
set the desired level at the a-b (T/R) terminals.  

	Based on the default G.711 Vocoder maximum of 3.14 or 3.17 dBm
the -4 dB gain default provides a maximum analog signal level at the a-b
(T/R) termination point. It should be noted that ETSI TS 101 909-4
provides guidance of 11 dB loss (-11 dB gain) and based on this
reference a DEFVAL { -11 } in international markets may be considered.  

	       DEFVAL { -4 }  

	

	       UNITS        "dBm"  

	       MAX-ACCESS   read-write  

	       STATUS       current  

	       DESCRIPTION  

	           "This is the decibel level for each analog signal
(tone) that is locally generated (verses in band supervisory tones) and
sourced to the a-b terminals (TE connection point).  Per the
PktcSigDevToneEntry this DbLevel represents the level required for each
tone where each tone may consist of multiple frequencies which may be
summed or amplitude modulated. This Object must reflect the desired
level at the Telco (POTS) a-b (T/R) terminals including the affect of
the pktcNcsEndPntConfigRxGain setting on the delivered tone.  The wide
range of levels for this Object is required to provide signal generator
levels across the wide range of gains but does not imply the entire
range is to be achievable given the range of negative values of gain
(positive loss).     This Object must be set for each tone so as to
generate the combined frequency level at the a-b (T/R) terminals." 

	       DEFVAL { -40 }

---

From: "Eugene Nechamkin" <[email-masked]>
Date: Wed, 22 Jun 2005 18:39:38 -0700

Sumanth,
 
Here is some recap of the prehistory of the issue with the corresponding
dates:
 
02/12/2005:     e-mail "[pkt-sig-mib] Comments/Resolutions on draft 07" is
circulated with the changes proposed for draft-08 from draft-07. There is no
mentioning of the "pktcNcsEndPntConfigTxGain" and "pktcNcsEndPntConfigRxGain"
MIB objects in it.
 
02/15/2005:     e-mail "IETF NCS Sig MIB Gain (loss) plan and tone Levels" is
circulated which contains the proposal to get the "pktcNcsEndPntConfigTxGain"
and "pktcNcsEndPntConfigRxGain" MIB objects back to draft-08. 
 
02/20/2005 (Sunday):    e-mail "[PKT-SIG-MIB] Draft 08 (Summary Of Changes)"
is circulated. This e-mail includes the proposal to get the
"pktcNcsEndPntConfigTxGain" and "pktcNcsEndPntConfigRxGain" MIB objects back
to the SIG MIB draft.
 
02/22/2005:     e-mail "I-D ACTION:draft-ietf-ipcdn-pktc-signaling-08.txt" is
circulated announcing the publication of the draft-08.
 
It would be very difficult, probably even unrealistic to expect that 5
working days is a sufficent amount of time for the community to be able to
carefully analyse the proposal and to come up with the appropriate comments
on the reflector. This is especially true having in mind that these two
particular objects have been already carefully considered in the past, and
the decision had been made to remove these two objects from the draft-02.
 
Given this, I think, it would be logical and reasonable to recognize that the
resurrection of these two MIB objects in the draft-08 was not sufficiently
discussed as a result of an oversight of the fact that the objects had been
excluded from the draft-02. Further, as the return of these objects already
raised some concerns expressed on the reflector, it would be also reasonable
to make an assumption that these two objects are not present in the draft-08.
Based on this premise we can start discussing the neccessity and arguments
for inclusion of these two objects to the next SIG MIB draft-09.
 
Regards,
 
Eugene.

From: Sumanth Channabasappa [mailto:[email-masked]] 
Sent: Wednesday, June 22, 2005 3:14 PM
To: Eugene Nechamkin; Richard Woundy @ Comcast; Freyman Phillip-FPF300
Cc: [email-masked]
Subject: RE: [ipcdn] IETF NCS Sig MIB Gain (loss) plan and tone Levels

Eugene,
 
The discussion resulting in this addition is detailed as COMMENT SET #6/7 in
the email referenced
via the following link (and you did reference the contents in your email as
well):

Since there were no concerns posted then, it was submitted as recommended. 

Thanks
Sumanth

 

 

Eugene Nechamkin,
 
Broadcom Corp.

---

From: "Sumanth Channabasappa" <[email-masked]>
Date: Thu, 23 Jun 2005 07:43:45 -0600

Eugene,
 
I am not disagreeing, but trying to get more input on this issue since
it has been around since 02/12/2005 as you indicated and is 
being raised now.
 
regards
Sumanth

  _____  

From: Eugene Nechamkin [mailto:[email-masked]] 
Sent: Wednesday, June 22, 2005 7:40 PM
To: Sumanth Channabasappa
Cc: [email-masked]
Subject: RE: [ipcdn] IETF NCS Sig MIB Gain (loss) plan and tone Levels

Sumanth,

02/12/2005:     e-mail "[pkt-sig-mib] Comments/Resolutions on draft 07"
is circulated with the changes proposed for draft-08 from draft-07.
There is no mentioning of the "pktcNcsEndPntConfigTxGain" and
"pktcNcsEndPntConfigRxGain" MIB objects in it.
 
02/15/2005:     e-mail "IETF NCS Sig MIB Gain (loss) plan and tone
Levels" is circulated which contains the proposal to get the
"pktcNcsEndPntConfigTxGain" and "pktcNcsEndPntConfigRxGain" MIB objects
back to draft-08. 
 
02/20/2005 (Sunday):    e-mail "[PKT-SIG-MIB] Draft 08 (Summary Of
Changes)" is circulated. This e-mail includes the proposal to get the
"pktcNcsEndPntConfigTxGain" and "pktcNcsEndPntConfigRxGain" MIB objects
back to the SIG MIB draft.
 
02/22/2005:     e-mail "I-D
ACTION:draft-ietf-ipcdn-pktc-signaling-08.txt" is circulated announcing
the publication of the draft-08.
 
It would be very difficult, probably even unrealistic to expect that 5
working days is a sufficent amount of time for the community to be able
to carefully analyse the proposal and to come up with the appropriate
comments on the reflector. This is especially true having in mind that
these two particular objects have been already carefully considered in
the past, and the decision had been made to remove these two objects
from the draft-02.
 
Given this, I think, it would be logical and reasonable to recognize
that the resurrection of these two MIB objects in the draft-08 was not
sufficiently discussed as a result of an oversight of the fact that the
objects had been excluded from the draft-02. Further, as the return of
these objects already raised some concerns expressed on the reflector,
it would be also reasonable to make an assumption that these two objects
are not present in the draft-08. Based on this premise we can start
discussing the neccessity and arguments for inclusion of these two
objects to the next SIG MIB draft-09.
 
Regards,
 
Eugene.

  _____  

Eugene,

 

Thanks
Sumanth

  _____  

 

 

Eugene Nechamkin,
 
Broadcom Corp.