RE: RE: AD re-review:draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic: docsIfCmtsCmStatusEqualizationData & docsIfSigQEqualizationData
"Eduardo Cardona" <[email protected]> Mon, 17 Oct 2005 06:53:45 -0600
| Newsgroups | gmane.ietf.ipcdn |
|---|---|
| Message-ID | <[email protected]> |
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 protected]]
Sent: Sunday, October 16, 2005 5:06 PM
To: Eduardo Cardona; Ipcdn (E-mail); [email protected]
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 protected]
> [mailto:[email protected]]On Behalf Of
> Eduardo Cardona
> Sent: Tuesday, October 11, 2005 13:59
> To: Eduardo Cardona; Ipcdn (E-mail); Wijnen, Bert (Bert);
> [email protected]
> 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 protected]
> 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 protected]
> https://www1.ietf.org/mailman/listinfo/ipcdn
>
>
>
> _______________________________________________
> IPCDN mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/ipcdn
>