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

["Wijnen, Bert (Bert)" <[e-mail]>]

Thanks, that would make it clearer I think.

Bert

> -----Original Message-----
> From: Eduardo Cardona [mailto:[e-mail]]
> Sent: Monday, October 17, 2005 08:54
> To: Wijnen, Bert (Bert); Ipcdn (E-mail); [e-mail]
> Cc: Randy Presuhn (E-mail)
> Subject: RE: [ipcdn] RE: AD
> re-review:draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic:
> docsIfCmtsCmStatusEqualizationData & docsIfSigQEqualizationData
> 
> 
> 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:[e-mail]] 
> Sent: Sunday, October 16, 2005 5:06 PM
> To: Eduardo Cardona; Ipcdn (E-mail); [e-mail]
> 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: [e-mail] 
> > [mailto:[e-mail]]On Behalf Of
> > Eduardo Cardona
> > Sent: Tuesday, October 11, 2005 13:59
> > 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: 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
> > [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