IP over Cable Data Network (ipcdn)

Eduardo Cardona | 3 Oct 2005 23:35

RE: RE: AD re-review:draft-ietf-ipcdn-docs-rfmibv2-13.txt Topic: 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

(Continue reading)

headers

Woundy, Richard | 4 Oct 2005 01:08

RE: cable dev mib draft09 - WG consensus requested on proposed changes

Based on the lack of response to this email, I presume the answer to issue #4 is MUST NOT. That is, "docsDevFilterLLCTable" and most other tables MUST NOT persist their table entries. I am comfortable with that approach, since I believe that is how DOCSIS cable modems implement these tables at the current time, and how most operators expect their cable modems to behave.

I am going to attempt to post an official -10 draft by this Friday October 7, based on the CD MIB draft changes recommended below. It is a month later than I originally expected. :^(

But hopefully there is time to review, and if necessary, post a "final" draft version before the Monday October 24 deadline before the Vancouver IETF.

-- Rich

-----Original Message-----
From: Jean-Francois Mule [mailto:jf.mule <at> cablelabs.com]
Sent: Monday, September 05, 2005 1:35 PM
To: Nakanishi Greg-MGI8179; ipcdn <at> ietf.org
Cc: Woundy, Richard; Marez Kevin-MGI1375
Subject: RE: [ipcdn] cable dev mib draft09 - WG consensus requested on proposed changes

Thanks Greg for reviewing the proposed changes.

3 weeks have passed since August 15: we have reached WG consensus on the proposed changes.

One comment was received from Greg on issue #4, to consider the stronger ‘MUST NOT’ rather than ‘SHOULD NOT’. I personally prefer SHOULD NOT as it is already quite strong of a requirement and it allows a device to remain complaint if the implementer has a good reason not to implement the MUST NOT.

Rich, Kevin, others - any preference?

if noone else responds by September 9, 9am ET, I propose we go with Greg’s preference: MUST NOT.

Jean-François

IPCDN co-chair

From: Nakanishi Greg-MGI8179 [mailto:gnakanishi <at> motorola.com]
Sent: Thursday, September 01, 2005 10:44 AM
To: Jean-Francois Mule; ipcdn <at> ietf.org
Subject: RE: [ipcdn] cable dev mib draft09 - WG consensus requested on proposed changes

I concur with the proposed resolution.

For Issue 4, my preference is that 'MUST NOT' be used, rather than 'SHOULD NOT'. I think a device will run into operational problems if it maintains these table entries across reboots. When the device reboots, the config log will attempt to create rows in these tables and will fail if the rows already exists.

greg

From: ipcdn-bounces <at> ietf.org [mailto:ipcdn-bounces <at> ietf.org] On Behalf Of Jean-Francois Mule
Sent: Monday, August 15, 2005 3:20 PM
To: ipcdn <at> ietf.org
Subject: [ipcdn] cable dev mib draft09 - WG consensus requested on proposed changes

Folks,

   As you may have read in meeting notes from last week, we spent the IETF 63 meeting discussing the closure of open issues on the CD mib v2.

   The meeting notes proposed some changes to get final (yes, final) closure on this mib.

Please review the text below and please speak up if you have some concerns (it's also welcome that you express your agreement).

Thanks,

Jean-François

[extract from ipcdn minutes]

3.1/ DOCSIS Cable Device MIB version 2

     draft-ietf-ipcdn-device-mibv2-09.txt

     Editors: Kevin Marez & Rich Woundy

http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mibv2-09.txt

We spent most of the meeting reviewing the 4 top remaining issues, see

summary sent by Rich and Kevin in:

http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01664.html

+ ISSUE #1: DEFVAL for docsDevNmAccessInterfaces

Raised by Randy, the issue is, in the defval we have a 4 octet value

=> How can systems with interfaces in a number not multiple

of 8 interpret the DEFVAL value. Are bits ignored?

Randy commented that he would be ok if there was some mention like

'octets containing bits corresponding to non-existent interfaces are

ignored.' That said, if there are implementations that would reject a

SET, then we need to say something about that.

Rich commented that the DEFVAL was added due to prior MIB doctor

comment and that the object is now deprecated. Bert asked whether

there was any concern deleting the DEFVAL.

Proposal for wg review:

a) in docsDevNmAccessInterfaces, delete DEFVAL { '00000001'h }

b) consider the following (NICE TO HAVE kind of fix)

    adding a sentence to say something like:

    bits set corresponding to non-existing interfaces is

    implementation specific (to warn the mgmt admin/apps that no

    assumptions should be made on existing implementations of this

    object. (Randy's suggestion)

+ ISSUE #2: docsDevNmAccessStatus

-- Also, we should change the DESCRIPTION of docsDevCpeStatus

-- and docsDevCpeInetRowStatus to document how the agent adds rows.

See issue raised by Randy and the email summary provided by Rich for

the context around this issue #2.

We had some discussions around the persistency of those tables, the

fact that the CM config file drives the row creation at boot-up and

the fact that they are read-create tables so admins can also create

entries as Bert pointed out.

In most cases (except for docsDevEvControlTable), entries do not

persist across CM reboots. Even in the case of docsDevEvControlTable,

after some discussion, we believe that the entries are cleared and

"recreated" after the CM reads the config file. That is the common

understanding.

Bert said: add a statement ("this is a deprecated table, this is

vendor specific as to what vendors do with this table, mgmt app cannot

expect a certain behavior").

+ ISSUE #3: docsDevEvReporting and local(0) rows

Comment close: ID authors agree with Randy's comment re: local(0) rows

MUST persist. Text will be revised.

in docsDevFilterLLCTable:

             Any attempt to SET the traps(1) or syslog(2) bits

             without setting the local(0) or localVolatile(8)

             bits MUST result in an error being generated.

Proposal:

   DELETE above text if nobody complains after reading the meeting

   notes

+ ISSUE #4: docsDevFilterLLCTable

Issue is around text for the level of requirements on table

persistence. Agree with Rich's text proposal:

|"Table entries MUST NOT persist across reboots for cable modems."

Rich also proposed to apply this requirement to:

NmAccess, FilterLLC, FilterIp, Policy, Tos,

Cpe and InetCpe tables.

It was suggested to use SHOULD NOT rather than MUST NOT but other than

that, proposal is ok.

+ Other items on CD Device MIB:

Randy added for consideration:

wherever we have this "must not persist" langage in table definitions,

it would be a plus to indicate that they may come back as entries may

reappear when CM reboots and comes up with config file. Or consider

adding this in the front paper as a consideration for users of the

MIBs if that is too many little edits in the MIB objects.

Proposal:

add a note on persistence model explaining the persistance of some

mib objects and the CM re-creating them upon config file reloading.

A comment was made that in general, we should indicate the persistency

model in each object rather than in the compliance section.

Bert also commented on the compliance sections: if different

requirements apply to CM and CMTS, suggestion is to make 2 different

compliances. Rich added that the new compliance statement is designed

like that.

# AI: [authors: Kevin Marez & Rich Woundy]

# Authors to summarize list of agreed changed and the technical

# changes in the text per wg consensus and issue new draft after AD

# review comments are in.

# Due by early September?

# AD review by Bert due by August 15

_______________________________________________
IPCDN mailing list
IPCDN <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn

headers

Sumanth Channabasappa | 7 Oct 2005 23:20

RE: Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt

Greg, Randy, Eugene,

Thanks for the comments. A few clarifications inline:

#1:
- The description makes mention of throttling events using SNMP and
Syslog.  What about the local log?  Are events written to the local log
not subject to throttling?  
[s] The objective of the MIB Objects belonging to 'pktcDevEventThrottle'
was to limit the throttling of events to the network (esp. in
power-up-after-a-blackout scenario), not locally.

Regarding local logging of events:
- the MTAs are currently required to store 2^31 events (in the local
log) and if we have questions regarding the size we should change the
index value 'pktcDevEvLogIndex' (suggestions anyone, MTA vendors?)

- Further, if we want to throttle local logging, we should probably
define a new MIB Object for local events only (since the throttling
conditions would vary between network and local storage) - thoughts?

#2:
- pktcDevEventDescrText and pktcDevEventDescrClass - These objects are
read-write.  It seems odd to me that these objects would be writable.
Is it really intended that these are writable objects?
[s] Yes, this is intended since an operator could change the
'Description of an event' to better suit 'Operational specific values'
(via SNMP or by using the configuration file at bootstrapping time).
E.g. MSO XYZ could change a lengthy description such as 'Error in TFTP
response to the MTA due to XYZ' into a shortened string such as
'TFTP-ERR:XYZ'.

>>> FYI <<<
I am working on a couple of other comments, but the following (mostly
from Greg and some internal) have been incorporated as-is:

There are a number of places in the document that makes reference to
"PacketCable device".  Shouldn't this be "PacketCable or IPCablecom
device"?  Or more simply "MTA device".

The naming convention we've been using on other MIB modules in IPCDN
adds "-IETF-" to the module name to distinguish it from the
corresponding MIB module being developed in CableLabs.  So, it this
case, the MIB module name should be something like
"PKTC-IETF-EVENT-MIB".

I think the ORGANIZATION clause should be IPCDN rather than CableLabs.

The DESCRIPTION clause is missing the mandatory copyright notice.

pktcDevEnvetReportStatus - The last sentence of the DESCRIPTION clause
states "... Defined by PacketCable by default."  Should this just
PacketCable or PacketCable and IPCablecom.

pktcDevEvThrottleAdminStatus
- "A value of stopAtThreshold(3) causes event message transmission to
cease at the threshold, and not resume until directed to do so." How is
the device directed to resume sending event messages?

pktcDevEvThrottleInterval  - The DEFVAL clause should be on a separate
line for readability.

pktcDevEventDescrTable - Should the reference to "PacketCable" be
"PacketCable/IPCablecom"?

pktcDevEventDescrId - "The event identifier can either be PacketCable
defined or vendor-specific." Would be good to provide a reference to the
PacketCable spec where the events are defined.

pktcDevEventDescrReporting - Should define what each one of the bit
values mean.

pktcDevEvLogCorrelationId - "...per section 5.4.5 of [3]"  Reference [3]
doesn't exist in the references section.

pktcDevEvLogCorrelationId
     "This MIB Object contains the correlation ID 
     generated by the MTA during the initiation of the
     last provisioning flow, within or following which
     the event occurred. 
     For information on the generation of correlation ids,
     refer to the corresponding PacketCable/IPCableCom
     Device Provisioning specifications."

[PKT-SP-EVEMIB1.5] - There is an odd character after the "PacketCable"

Reference section - There are number of reference in the body of the
text that do not exist in the references section.  Need to make sure all
reference are cited.  The ones I found are PKT-SP-PROV, PKT-SP-MIB-MTA,
PKT-SP-MGCP, RFC3435, PKT-SP-CODEC, and RFC2119.

Security Considerations - Per the MIB Guidelines, need to explicit
discuss all MIB objects, even if to only state that there are no
security issues with the object.

- There is no MIB Object defined as 'pktcDevEventThrottle 3' (we have
MIB Objects for 2 and 4)

- The Reference in the description of the MIB Object
'pktcDevEvLogCorrelationId' seems to be out of place.

headers

Eduardo Cardona | 11 Oct 2005 19:59

RE: 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); david.raftus <at> ati.com
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
IPCDN <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn

headers

Margo Dolas | 12 Oct 2005 21:31

RE: 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: ipcdn-bounces <at> ietf.org [mailto:ipcdn-bounces <at> ietf.org] On Behalf Of
Eduardo Cardona
Sent: Tuesday, October 11, 2005 1:59 PM
To: Eduardo Cardona; Ipcdn (E-mail); Wijnen, Bert (Bert);
david.raftus <at> ati.com
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); david.raftus <at> ati.com
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
IPCDN <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn

_______________________________________________
IPCDN mailing list
IPCDN <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn

headers

Jean-Francois Mule | 13 Oct 2005 22:28

DRAFT Agenda for the IETF#64 IPCDN meetin in Vancouver

Folks,

Rich and I would like to propose following the same wg meeting format as last time: no slide deck and general
updates, just a working session to address open issues on active drafts.

We have 5 I-Ds left, and are expecting 2 more ID updates before the meeting (Cable Device mib v10 and MTA MIB v7).

Below is a proposed agenda for your review, let us know if you plan to attend and have any modifications to the agenda.

Rich and Jean-François
IPCDN Co-chairs
-----------------------------------------------------------------------

 IP over Cable Data Network WG (ipcdn)
 IETF #64

THURSDAY, November 10, 2005, from 1510-1610 
(Afternoon Session II)  
==========================================

Chairs:
   Richard Woundy <Richard_Woundy <at> cable.comcast.com>
   Jean-Francois Mule <jfm <at> cablelabs.com>

AGENDA:

 I.   Agenda Bashing

 II.  Administration

 III. IPCDN DOCSIS mibs

    o DOCSIS Cable Device MIB version 2  (ID update pending)
      draft-ietf-ipcdn-device-mibv2-10.txt
      Editors: Kevin Marez & Rich Woundy 

http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mibv2-10.txt

    o RF MIB v2
      draft-ietf-ipcdn-docs-rfmibv2-13.txt
      Editor: Eduardo Cardona http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-docs-rfmibv2-13.txt

 IV. IPCablecom/PacketCable Submissions

    o MTA MIB
      draft-ietf-ipcdn-pktc-mtamib-07.txt (ID update pending) http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-mtamib-07.txt

    o Signaling MIB
      draft-ietf-ipcdn-pktc-signaling-09.txt 

http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-signaling-09.txt 

    o Management Event MIB
      draft-ietf-ipcdn-pktc-eventmess-04.txt

http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-eventmess-04.txt

 V. Next steps

-- Richard Woundy and Jean-Francois Mule, IPCDN co-chairs

headers

Wijnen, Bert (Bert | 17 Oct 2005 01:06

RE: RE: AD re-review:draft-ietf-ipcdn-docs-rfmibv2-13.txt Topic: 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: ipcdn-bounces <at> ietf.org 
> [mailto:ipcdn-bounces <at> ietf.org]On Behalf Of
> Eduardo Cardona
> Sent: Tuesday, October 11, 2005 13:59
> To: Eduardo Cardona; Ipcdn (E-mail); Wijnen, Bert (Bert);
> david.raftus <at> ati.com
> 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); david.raftus <at> ati.com
> 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
> IPCDN <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/ipcdn
> 
> 
> 
> _______________________________________________
> IPCDN mailing list
> IPCDN <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/ipcdn
>

headers

Eduardo Cardona | 17 Oct 2005 14:53

RE: 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:bwijnen <at> lucent.com] 
Sent: Sunday, October 16, 2005 5:06 PM
To: Eduardo Cardona; Ipcdn (E-mail); david.raftus <at> ati.com
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: ipcdn-bounces <at> ietf.org 
> [mailto:ipcdn-bounces <at> ietf.org]On Behalf Of
> Eduardo Cardona
> Sent: Tuesday, October 11, 2005 13:59
> To: Eduardo Cardona; Ipcdn (E-mail); Wijnen, Bert (Bert);
> david.raftus <at> ati.com
> 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); david.raftus <at> ati.com
> 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
> IPCDN <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/ipcdn
> 
> 
> 
> _______________________________________________
> IPCDN mailing list
> IPCDN <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/ipcdn
>

headers

Wijnen, Bert (Bert | 17 Oct 2005 16:32

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

Thanks, that would make it clearer I think.

Bert

> -----Original Message-----
> From: Eduardo Cardona [mailto:e.cardona <at> CableLabs.com]
> Sent: Monday, October 17, 2005 08:54
> To: Wijnen, Bert (Bert); Ipcdn (E-mail); david.raftus <at> ati.com
> 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:bwijnen <at> lucent.com] 
> Sent: Sunday, October 16, 2005 5:06 PM
> To: Eduardo Cardona; Ipcdn (E-mail); david.raftus <at> ati.com
> 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: ipcdn-bounces <at> ietf.org 
> > [mailto:ipcdn-bounces <at> ietf.org]On Behalf Of
> > Eduardo Cardona
> > Sent: Tuesday, October 11, 2005 13:59
> > To: Eduardo Cardona; Ipcdn (E-mail); Wijnen, Bert (Bert);
> > david.raftus <at> ati.com
> > 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); david.raftus <at> ati.com
> > 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
> > IPCDN <at> ietf.org
> > https://www1.ietf.org/mailman/listinfo/ipcdn
> > 
> > 
> > 
> > _______________________________________________
> > IPCDN mailing list
> > IPCDN <at> ietf.org
> > https://www1.ietf.org/mailman/listinfo/ipcdn
> > 
> 
>

headers

Eduardo Cardona | 18 Oct 2005 17:06

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

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:mdolas <at> broadcom.com] 
Sent: Wednesday, October 12, 2005 1:32 PM
To: Eduardo Cardona; 'Ipcdn (E-mail)'; 'Wijnen, Bert (Bert)';
david.raftus <at> ati.com
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: ipcdn-bounces <at> ietf.org [mailto:ipcdn-bounces <at> ietf.org] On Behalf
Of
Eduardo Cardona
Sent: Tuesday, October 11, 2005 1:59 PM
To: Eduardo Cardona; Ipcdn (E-mail); Wijnen, Bert (Bert);
david.raftus <at> ati.com
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); david.raftus <at> ati.com
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
IPCDN <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn

_______________________________________________
IPCDN mailing list
IPCDN <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn

1	September 2010
3	May 2010
4	April 2009
3	October 2008
4	August 2008
2	June 2008
2	March 2008
6	January 2008
1	November 2007
4	October 2007
2	September 2007
5	August 2007
3	July 2007
4	June 2007
4	March 2007
2	January 2007
4	December 2006
4	November 2006
8	October 2006
2	September 2006
3	July 2006
10	June 2006
20	March 2006
16	February 2006
14	January 2006
15	December 2005
20	November 2005
27	October 2005
58	September 2005
36	August 2005
27	July 2005
37	June 2005
4	May 2005
6	April 2005
7	March 2005
26	February 2005
121	January 2005
7	December 2004
20	November 2004
47	October 2004
35	September 2004
42	August 2004
53	July 2004
19	June 2004
19	May 2004
74	April 2004
16	March 2004
43	February 2004
59	January 2004
22	December 2003
22	November 2003
72	October 2003
40	September 2003
78	August 2003
50	July 2003
37	June 2003
24	May 2003
24	April 2003
37	March 2003
34	February 2003
97	January 2003
51	December 2002
23	November 2002
33	October 2002
13	September 2002
4	August 2002
10	July 2002
11	June 2002
17	April 2002

Mon	Tue	Wed	Thu	Fri	Sat	Sun

					1	2
3	4	5	6	7	8	9
10	11	12	13	14	15	16
17	18	19	20	21	22	23
24	25	26	27	28	29	30
31