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

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

Does anyone get the chance to review the proposed clarifications ? 

Please reply with comments by the end of the week 

Thanks

Eduardo



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

Hi IPCDN participants,

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

Please review the details and send your comments.

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


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



----  

CM/CMTS Equalizer Data: 


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

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

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

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

CMTS equalization Data:
3) Equalization in the Upstream has relative importance for CMTS CM
path, docsIfCmtsCmStatusEqualizationData
Meanings:
When Pre-eq is off, the value will indicate the CM-CMTS path RF
distortions. 
When re-eq is on, the value indicates how well pre-equalization is
working as the value of all should be close to zero with the exception
of the main tap

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


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

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

c) Description of docsIfCmtsCmStatusEqualizationData

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

Proposal details :

a) 

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

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


alternative b-1) 

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

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

--Note: same compliance statements as in draft 13


alternative b-2) 

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

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


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

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




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

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

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

Andre Lejeune - ATI

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


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

David Hull - Conexant 

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

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

Andre Lejeune - ATI


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

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

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

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

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

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

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

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





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



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