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

From: "Eduardo Cardona" <[email-masked]>
Date: Mon, 17 Oct 2005 06:53:45 -0600

Thanks Bert for the review

I am also expecting validation from vendor at the least this week so I
can publish D-14 by the end of the week 

To your question :
4+4*64 or 4+8*64
The total number of taps ( forward and reverse ) are up to 64 

Your interpretation of 8*64 seems to indicate to me you are assuming:
Forward taps  =  Reverse Taps (Always) and up to 64 taps

To make that clear, few text suggestions to the TEXTUAL-CONVENTION are
below  
...
           1 byte Number of forward taps: n
           1 byte Number of reverse taps: m
...
           DOCSIS specifications requires up to a maximum of 
           64 equalizer taps (n + m); therefore, this object size 
           can get up 260 bytes (4 + 4x64).  

Thanks

Eduardo

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
Sent: Sunday, October 16, 2005 5:06 PM
To: Eduardo Cardona; Ipcdn (E-mail); [email-masked]
Cc: Randy Presuhn (E-mail)
Subject: RE: [ipcdn] RE: AD
re-review:draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic:
docsIfCmtsCmStatusEqualizationData & docsIfSigQEqualizationData

Sorry that it took a while to respond.

I think the most important 2 things are:
- Have a CLEAR description of the MIB objects, so that implementers
  (both at the agent and at the manager side) know what to do and/or
  what to expect. The discussion below is clearly helping to go
  for a solution in that direction.
- From a MIB doctor perspective, your proposals look OK. It is 
  important though to have those vendors that have been providing
  input DO take a look at your proposed changes and agree as to
  what the best solution is and to make sure that that is what
  they have (or plan to) implement(ed).

One thing I wondered. Is the max length not 4+8*64 instead of 4+4*64?
If not, then I do not understand the DESCRIPTION clause of the TC.

Bert

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> Eduardo Cardona
> Sent: Tuesday, October 11, 2005 13:59
> To: Eduardo Cardona; Ipcdn (E-mail); Wijnen, Bert (Bert);
> [email-masked]
> 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); [email-masked]
> 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: n
>           1 byte Number of reverse taps: m
>           
>           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 (N + M), 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ipcdn
> 
> 
> 
> _______________________________________________
> IPCDN mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ipcdn
> 

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

---

From: "Eduardo Cardona" <[email-masked]>
Date: Tue, 18 Oct 2005 09:06:55 -0600

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:[email-masked]] 
Sent: Wednesday, October 12, 2005 1:32 PM
To: Eduardo Cardona; 'Ipcdn (E-mail)'; 'Wijnen, Bert (Bert)';
[email-masked]

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: [email-masked] [mailto:[email-masked]] On Behalf
Of
Eduardo Cardona
Sent: Tuesday, October 11, 2005 1:59 PM
To: Eduardo Cardona; Ipcdn (E-mail); Wijnen, Bert (Bert);
[email-masked]
Subject: RE: [ipcdn] RE: AD
re-review:draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic:
docsIfCmtsCmStatusEqualizationData & docsIfSigQEqualizationData

Thanks

Eduardo

-----Original Message-----
From: Eduardo Cardona
Sent: Monday, October 03, 2005 3:35 PM
To: Ipcdn (E-mail); Wijnen, Bert (Bert); [email-masked]
Subject: RE: [ipcdn] RE: AD

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

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.

- Not required by the spec : Reverse Taps (DS equalizers) could be also
T,
T/2 and T/4 spaced
enough
indication of that 

The discussions held with RF experts identified the following management
requirements : 

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:
path,

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

d)

Proposal details :

a) 

          1 byte Number of forward taps
          1 byte Number of reverse taps

         
          64 equalizer taps , therefore, this object size can get up
          260 bytes (4 + 4x64).

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

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.

c)

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:

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

            "At the CM, returns the equalization data for the downstream
 
------------------------  

Andre Lejeune - ATI

 

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

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:
 
Number of forward taps per symbol (1 byte) Number of forward taps (1
byte)

------------------------
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:

as an example.
 
Hal

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