RE: [ipcdn] RE: AD re-review:draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic: docsIfCmtsCmStatusEqualizationData & docsIfSigQEqualizationData

["Eduardo Cardona" <[e-mail]>]

Hi Margo, 
Sorry, I missed your response, 

I think you have a good point, 
Some management applications may decide to just look at the main tap and
ignore the others to simplify the parsing and processing of the values.

Early discussions with PHY experts, they where divided if main tap
pointer was needed or not -- It can be determined as the biggest
magnitude of the coefficient series.

Your suggestion is clear for the US equalization. For DS, David Hull had
a point of making the CM handling of coefficients open to CM
implementations. See his comments ( bottom of this email, copied for
convenience below ). 

Therefore, in the interest of leaving the header an even number ( and a
multiple of four) it was considered not requiring the Main tap location

David Hull -Conexant 

"With regard to #1, the definition in Fig 6-22 of the DOCSIS 1.1 spec
that
Andre referred to seems good enough but I would allow the number of taps
per
symbol to be defined independently for the forward section AND the
reverse
section just in case someone implemented the two sections with different
tap
spacing.  Short of officially "specifying" the DS equalizer like we have
done for the upstream one, I don't see too much more that could be
done."


Shall we consider two TEXTUAL-CONVENTIONS 
One for US and one for DS ? 

DocsUpstreamEqualizerData   -- No Main Tap
          1 byte Number of forward taps per symbol
          1 byte Number of reverse taps per symbol
          1 byte Number of forward taps
          1 byte Number of reverse taps

DocsDownstreamEqualizerData
          1 byte Main Tap Location
          1 byte Number of forward taps per symbol
          1 byte Number of forward taps
          1 byte Number of reverse taps

Or should we just add the extra byte of the main tap in the current
TEXTUAL CONVENTION (SIZE 261)

DocsEqualizerData 
          1 byte Main Tap Location
          1 byte Number of forward taps per symbol
          1 byte Number of reverse taps per symbol -- 1 for US
equalizers
          1 byte Number of forward taps
          1 byte Number of reverse taps



Thanks



Eduardo


-----Original Message-----
From: Margo Dolas [mailto:[e-mail]] 
Sent: Wednesday, October 12, 2005 1:32 PM
To: Eduardo Cardona; 'Ipcdn (E-mail)'; 'Wijnen, Bert (Bert)';
[e-mail]
Subject: RE: [ipcdn] RE: AD
re-review:draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic:
docsIfCmtsCmStatusEqualizationData & docsIfSigQEqualizationData

Eduardo,

Thanks for going to the effort of clarifying these objects!  I only have
one
comment.  The creation of the DocsEqualizerData convention is good, but
would it be possible to change the definition to match that of the
RNG-RSP
from DOCSIS1.1, removing the number of reverse taps per symbol and
adding
the main tap location?   It's unnecessary to specify the number of
reverse
taps per symbol, since it would be a T-spaced DFE.  The main tap
location is
important (at least for the upstream) because it refers to the position
of
the zero delay tap for a ranging consideration.

DocsEqualizerData ::= TEXTUAL-CONVENTION
     STATUS       current
     DESCRIPTION
         "This data type represents the equalizer data
          as measured at the receiver interface.
          The format of the equalizer follows a similar structure
          Transmit Equalization Adjust RNG-RSP TLV of DOCSIS RFI 
          v1.1 specification with slight modifications as
          follows :
          1 byte Main Tap Location
          1 byte Number of forward taps per symbol
          1 byte Number of forward taps
          1 byte Number of reverse taps
          ...

In terms of options (b-1) and (b-2), I don't have a strong preference,
but a
small preference for (b-2).

Margo  

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of
Eduardo Cardona
Sent: Tuesday, October 11, 2005 1:59 PM
To: Eduardo Cardona; Ipcdn (E-mail); Wijnen, Bert (Bert);
[e-mail]
Subject: RE: [ipcdn] RE: AD
re-review:draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic:
docsIfCmtsCmStatusEqualizationData & docsIfSigQEqualizationData

Does anyone get the chance to review the proposed clarifications ? 

Please reply with comments by the end of the week 

Thanks

Eduardo



-----Original Message-----
From: Eduardo Cardona
Sent: Monday, October 03, 2005 3:35 PM
To: Ipcdn (E-mail); Wijnen, Bert (Bert); [e-mail]
Subject: RE: [ipcdn] RE: AD
re-review:draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic:
docsIfCmtsCmStatusEqualizationData & docsIfSigQEqualizationData

Hi IPCDN participants,

Here is an update on one of the pending items from Bert's review:
After consultations with DOCSIS vendors, I am proposing the
clarifications
required to define the size constraints for
docsIfCmtsCmStatusEqualizationData and docsIfSigQEqualizationData

Please review the details and send your comments.

You will find in this email a summary of the proposed changes as well as
a
log of comments provided by vendors to place the discussion in the
context
of the IPCDN participants. 


Please comment on the proposals and make the appropriate comments Item
a)
Item  c) Item  d) Comments and pick an alternative from
b-1)
and
b-2)



----  

CM/CMTS Equalizer Data: 


Summary:
docsIfSigQEqualizationData and  docsIfCmtsCmStatusEqualizationData have
OCTET STRING with no constraints in the object size (RFC 2669), in fact
the
format of the pre-equalizers was never normalized and left vendor
specific
In draft 06 of RFIv2.0 It was added a size constraint of 512 octets but
no
special reason was defined:
Some basic Math will indicate that up to 64 taps ( RFI requirements) and
4 bytes per tap will indicate 256 bytes, still uncertain why 512 was
selected.

Even though the selection of 256 (or 512) does not seem to be accurate
number considering some possible byte controls to indicate:
- Taps could be T, T/2 or T/4 spaced. 
- Forward Taps and Reverse Taps could have different numbers
- Not required by the spec : Reverse Taps (DS equalizers) could be also
T,
T/2 and T/4 spaced
- Any need to indicate main tap position ( or the highest value is
enough
indication of that 

The discussions held with RF experts identified the following management
requirements : 
 
1) CM DS post-equalization have been defined in
docsIfSigQEqualizationData 

2) CM Upstream pre-equalizer ( not to be defined in this version of the
MIB) something to reflect the CMTS RNG-RSP equalizer value 

CMTS equalization Data:
3) Equalization in the Upstream has relative importance for CMTS CM
path,
docsIfCmtsCmStatusEqualizationData
Meanings:
When Pre-eq is off, the value will indicate the CM-CMTS path RF
distortions.

When re-eq is on, the value indicates how well pre-equalization is
working
as the value of all should be close to zero with the exception of the
main
tap

4) The equalization data per US interface defined as an average value in
docsIfSigQEqualizationData This concept is confusing since there is no
in
the RFI spec a methodology to calculate that average. 
It could include : 
- CMs with different configuration: pre-eq on|off,
- Different number of Taps per CM,
- Tap spacing per CM
The average formula should've being
The recommendation is to remove that requirement


Proposed resolution:
a)
Use the same format as in the CM equalization data for 1) and 3)  for CM
docsIfSigQEqualizationData and docsIfCmtsCmStatusEqualizationData

b)
remove the CMTS requirement for docsIfSigQEqualizationData
- Future spec efforts will work to define more meaningful values for
CMTS US
that could lead to objects that defines MER measurements prior and after
channel signal compensation or mitigation by the CMTS

c) Description of docsIfCmtsCmStatusEqualizationData

d)
CM upstream pre-equalizer Perhaps in further revisions of the DOCSIS
specification and RFI MIB updates
 

Proposal details :

a) 

-- Add a new textual Convention
DocsEqualizerData ::= TEXTUAL-CONVENTION
     STATUS       current
     DESCRIPTION
         "This data type represents the equalizer data
          as measured at the receiver interface.
          The format of the equalizer follows a similar structure
          Transmit Equalization Adjust RNG-RSP TLV of DOCSIS RFI 
          v1.1 specification with slight modifications as
          follows :
          1 byte Number of forward taps per symbol
          1 byte Number of reverse taps per symbol
          1 byte Number of forward taps
          1 byte Number of reverse taps
          
          Following are the equalizer coefficients:
          First forward taps coefficients :
          2 bytes F1 (real),  2 bytes  F1 (imag)
          ...
          2 bytes Fn (real),  2 bytes  Fn (imag)
          
          Then reverse taps coefficients :
          2 bytes D1 (real),  2 bytes  D1 (imag)
          ...
          2 bytes Dm (real),  2 bytes  Dm (imag)

          The equalizers coefficient are considered signed 16 bit
          integers in the range -32768 (0x8000) to 32767 (0x7FFF).
         
          DOCSIS specifications requires up to a maximum of 
          64 equalizer taps , therefore, this object size can get up
          260 bytes (4 + 4x64).
          The minimum object size (other than zero) for a t-spaced Tab
          with a minimum of 8 symbols will be 36 (4 + 4x8)"
     SYNTAX       OCTET STRING(SIZE 0|36..260))


alternative b-1) 

docsIfSigQEqualizationData OBJECT-TYPE
        SYNTAX      DocsEqualizerData
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
            "At the CM, returns the equalization data for the downstream
             channel.
             
             At the CMTS, this object is not applicable and might return

             a zero-length OCTET STRING. Note that previous CMTS 
             implementations may instantiate this object in two ways:
             - An equalization value different of the zero-length
               octet string to indicate an equalization average for
               the upstream channel. Those values have vendor 
               dependent interpretation.
             - Return a zero-length OCTET STRING as described below.
             
             A returned zero-length OCTET STRING indicate the value
             is unknown or if there is no equalization data available
             or defined."
        REFERENCE
            "DOCSIS Radio Frequency Interface Specification,
             Figure 6-23."
        ::= { docsIfSignalQualityEntry 7 }

--Note: same compliance statements as in draft 13


alternative b-2) 

docsIfSigQEqualizationData OBJECT-TYPE
        SYNTAX      DocsEqualizerData
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
            "At the CM, returns the equalization data for the downstream
             channel.
             
             At the CMTS, this object is not applicable and is not 
             instantiated. Note that previous CMTS implementations 
             may instantiate this object in two ways:
             - An equalization value different of the zero-length
               octet string to indicate an equalization average for
               the upstream channel. Those values have vendor 
               dependent interpretation.
             - Return a zero-length OCTET STRING as described below.
             
             A returned zero-length OCTET STRING indicate the value
             is unknown or if there is no equalization data available
             or defined."
        REFERENCE
            "DOCSIS Radio Frequency Interface Specification,
             Figure 6-23."
        ::= { docsIfSignalQualityEntry 7 }

-- Changes in compliance statements: 
docsIfBasicGroupV2 OBJECT-GROUP
     OBJECTS {
         docsIfDownChannelId,
-- ... snip ...
-- delete
--         docsIfSigQEqualizationData,
--- ...snip ...
     }
     STATUS      current
     DESCRIPTION
         "Group of objects implemented in both cable modems and
          cable modem termination systems."
     ::= { docsIfGroups 5 }


docsIfCmGroupV2 OBJECT-GROUP
     OBJECTS {
         docsIfCmCmtsAddress,
-- ... snip ...
        docsIfCmServiceExtTxSlotsDed,
-- Add
         docsIfSigQEqualizationData
--- ...snip ...
     }
     STATUS      current
     DESCRIPTION
         "Group of objects implemented in cable modems."
     ::= { docsIfGroups 6 }

c)
docsIfCmtsCmStatusEqualizationData OBJECT-TYPE
     SYNTAX      OCTET STRING (SIZE (0..512))
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
         "Equalization data for this CM as measured by the CMTS.
          Returns the zero-length OCTET STRING if the value is 
          unknown or if there is no equalization data available
          or defined."
     REFERENCE
         "Data-Over-Cable Service Interface Specifications: Radio
          Frequency Interface Specification SP-RFIv2.0-I07-041210,
          Figure 8-23."
     ::= { docsIfCmtsCmStatusEntry 8 }




Summary of comments received in a vendor internal discussion Copied for
IPCDN participants background 

------------------
Hal Roberts - ADC

Colleagues,
 
While we are looking at this question we should make sure we end up with
precise definitions of the equalization coefficient format for DOCSIS
3.0
for both the CMTS and the CM. Note that DOCSIS 3.0 Enhanced Signal
Quality
Monitoring goals include:
 
-	Pre-Equalization (Already in spec) 
*	Review language to make sure output is standardized for
processing. 
 
docsIfSigQEqualizationData
For the cable modem "the equalization data for the downstream channel"
has an unambiguous meaning.  So for the cable modem it is the tap format
which must be made unambiguous (this should be agreed upon by cable
modem
and/or cable modem chip manufacturers).
With regard to the CMTS, the MIB docsIfSigQEqualizationData is supposed
to
provide the 'average' equalization data for the upstream channel as seen
by
the CMTS. This is an ambiguous statement. There is no 'average'
equalization data since the equalization coefficients uniquely apply to
each
upstream path from each CM to the CMTS receiver. These coefficients are
complex numbers, so in what way does one average them? If one can define
a
formula that results in a single real number from each set of
coefficients
as they come from the CMTS for each CM then one could envision averaging
these numbers into something approaching a meaningful assessment of the
linear distortions on a given upstream channel. (Tom Kolze has just such
a
formula and we have found it to be an accurate estimate of the MER of a
channel due to distortions alone. Tom may be willing to share this with
the
working group).
 
Therefore I think that the definition of 'average equalization data for
the
upstream channel' must be clarified or the CMTS portion of the MIB
should be
removed.
 
docsIfCmtsCmStatusEqualizationData
With regard to the MIB docsIfCmtsCmStatusEqualizationData, when
pre-equalization is on there is little or no meaning to the equalization
coefficients from the CMTS (even on a per-cable-modem basis rather than
per
channel). If pre-equalization is working correctly there should be very
little residual channel distortion left and the coefficients will no
longer
have any relationship to the channel characteristics. Possibly the only
use
for these coefficients when pre-equalization is on, is to actually see
if
pre-equalization is doing the job.
 
On the other hand, when pre-equalization is turned off,
docsIfCmtsCmStatusEqualizationData will accurately reflect distortions
on
the RF path between the given cable modem and the CMTS receiver.
 
Therefore I think that agreeing on the format of this MIB is what is
necessary. One other suggestion, the text "Equalization data for this
CM"
might be clearer if it stated "Equalization data for this CM, as
measured by
the CMTS"
 
Hal
 
 
docsIfSigQEqualizationData OBJECT-TYPE
        SYNTAX      OCTET STRING
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
            "At the CM, returns the equalization data for the downstream
             channel. At the CMTS, returns the average equalization
             data for the upstream channel. Returns an empty string
             if the value is unknown or if there is no equalization
             data available or defined."
        REFERENCE
            "DOCSIS Radio Frequency Interface Specification,
             Figure 6-23."
        ::= { docsIfSignalQualityEntry 7 }
 
------------------------  

Andre Lejeune - ATI

We report the docsIfSigQEqualizationData for our CM in the following
format:
 
F1 (real) 16 bits,   F1 (imag) 16 bits
F2 (real) 16 bits,   F2 (imag) 16 bits
...
Fn (real) 16 bits,   Fn (imag) 16 bits
 
The number of taps is deduced from the length of the octet string.


------------------------  

David Hull - Conexant 

The DS equalizer has never been specified in terms of its exact
implementation.  This has been left to the individual silicon vendor;
therefore they are all a bit different. Some implementations use T
spaced
all the way through and (I believe) some implementations may use
fractional
spacing for the front end (prior to the reference tap).  Not all
implementations have the same length of DS equalizer or the same center
tap
position (relative to the overall length) either.  If all we want to do
is
compute the frequency response by a DFT on the tap weights, I don't
think it
matters what the CT position is but the length and the tap spacing would
need to be conveyed if fractional spacing is used.

------------------------  

Andre Lejeune - ATI


I am sorry I took some time to respond. I clearly needed to discuss this
internally before continuing on the subject.
 
The format I sent earlier was for our modem. But now I realize that even
our
own solution will be changing and the format below won't be appropriate.
I
agree that more information needs to be carried in this MIB. A solution
proposed by Mike Grimwood is to use the format from DOCSIS 1.1, figure
6.23
(without the type and length), which allows for Main Tap Location,
Spacing,
number of FF and FB taps. Even that may not be sufficient, if I properly
understand Dave below, if different fractional spacing is used for the
different taps. I'll let Dave explain this further if he thinks it is
necessary. The main tap location is not absolutely required, as it
generally
can be easily derived, but could be useful under certain error
conditions:
 
Main Tap Location (1 byte)
Number of forward taps per symbol (1 byte) Number of forward taps (1
byte)
Number of reverse taps (1 byte)
F1 (real) 16 bits,   F1 (imag) 16 bits
F2 (real) 16 bits,   F2 (imag) 16 bits
...
Fn (real) 16 bits,   Fn (imag) 16 bits

D1 (real) 16 bits,   D1 (imag) 16 bits
D2 (real) 16 bits,   D2 (imag) 16 bits
...
Dn (real) 16 bits,   Dn (imag) 16 bits
 
------------------------
Hal Roberts  - ADC 

To summarize:
1.	Equalization MIBS from the CM - We need well defined MIBs from
the CM for both the downstream post-equalizer and the upstream
pre-equalizer
values. If no uniform format for the downstream taps can be defined due
to
proprietary implementations, perhaps the vendors can simply provide a
'frequency response or impulse response' as calculated from the
equalizer
(but in a uniform format). For the upstream taps it should be easy to
provide a uniform tap format as it is already mostly defined in the RFI.
2.	Equalization MIBS from the CMTS when Pre-equalization is OFF -
As mentioned before, an average equalization data from the CMTS on a per
upstream channel basis is not defined and could take a number of
meanings.
Without an unambiguous definition of channel based equalization data, it
would be better to remove this part of the definition as it simply leads
to
mass confusion. Note that equalization MIBs from the CMTS on a per CM
basis
do have significant value for plant monitoring and debug purposes. These
merely need to be defined in format; this format could be the same
format as
in the pre-equalizer MIB from the CM as they are representing the same
plant
characteristic.
3.	Equalization MIBS from the CMTS when Pre-equalization is ON -
These have no significant value other than seeing if pre-equalization is
operating properly. When pre-equalization is operating properly then the
CMTS should see little or no plant distortion and the equalizer
coefficients
should be close to all-zeros except for the main tap for all modems.
Hal

------------------------
David Hull -Conexant 

With regard to #1, the definition in Fig 6-22 of the DOCSIS 1.1 spec
that
Andre referred to seems good enough but I would allow the number of taps
per
symbol to be defined independently for the forward section AND the
reverse
section just in case someone implemented the two sections with different
tap
spacing.  Short of officially "specifying" the DS equalizer like we have
done for the upstream one, I don't see too much more that could be done.

------------------------
Hal Roberts - ADC 

Dave,
 
It may be elsewhere in the spec or it may be obvious but I think we need
to
have more detail, for example the numbers should be represented in a
specific numerical format perhaps:
 
"Standard twos-complement format, from -32768 (0x8000) to 32767
(0x7FFF)"
 
as an example.
 
Hal

------------------------  





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



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






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