Subject: [Adslmib] Draft VDSL MIB - more comments

From: [email-masked]
Date: Sun, 28 Apr 2002 19:55:55 +0300

Hi,

The following are further changes that required in the MIB. Some are line
code independent and some are specific for SCM.

Line code independent changes:
1. ANSI Part 1 (common spec for SCM and MCM) defines two deployment
scenarios (Fiber-To-The-Cabinet and Fiber-To-The-Exchange). Therefore,
there should be a new table (e.g., vdslLinkConfProfileTable) with a single
entry per profile (in ADDITION to vdslLineConfProfileTable which is per
unit) with a single index vdslLineConfProfileIndex, and create there an
object to specify the deployment scenario.
     vdslLinkConfDeploymentScenario OBJECT-TYPE
          SYNTAX  INTEGER {
                     FttCab(1),
                     FttEx(2)
                 }
          MAX-ACCESS  read-write
          STATUS  current
          DESCRIPTION
            "The VDSL link deployment scenario. When using
             'FttCab' scenario, the VTU-C is located in
      a street cabinet. When using 'FttEx' scenario,
      the VTU-C is located in the central office."
          ::= { vdslLinkConfProfileEntry xxxx }

2. The VDSL link may be trained according to either ANSI, ETSI or ITU-T
(see ITU-T G.994.1). This should be supported by appropriate objects in the
MIB. At least The " new" table (vdslLinkConfProfileTable) should have an
object to specify the applicable standard.
     vdslLinkConfApplicStandard OBJECT-TYPE
          SYNTAX  INTEGER {
                     ETSI(1),
                     ANSI(2),
                     ITU(3)
                 }
          MAX-ACCESS  read-write
          STATUS  current
          DESCRIPTION
            "The VDSL standard to be used for the respective line"
          ::= { vdslLinkConfProfileEntry xxxx }

3. It is important to specify the band plan used for the VDSL link, when
the VDSL line is trained according to ETSI or ITU-T specs. The " new" table
(vdslLinkConfProfileTable) should have an object to specify the band plan.
     vdslLinkConfBandPlan OBJECT-TYPE
          SYNTAX  INTEGER {
                     Band997(1),
                     Band998(2),
                     BandFx(3)
                 }
          MAX-ACCESS  read-write
          STATUS  current
          DESCRIPTION
            "The VDSL Band Plan"
          ::= { vdslLinkConfProfileEntry xxxx }

4. When the VDSL line is trained according to ETSI (maybe also for ITU-T).
The " new" table (vdslLinkConfProfileTable) should have an object to
specify whether the VDSL may occupy the ADSL frequency range. We believe
that for ANSI standard this object is not required.
     vdslLinkConfAdslOccuopy OBJECT-TYPE
          SYNTAX  TruthValue
          MAX-ACCESS  read-write
          STATUS  current
          DESCRIPTION
            "Does the VDSL may occupy the ADSL frequency range"
          ::= { vdslLinkConfProfileEntry xxxx }

4. ANSI Part 1 defines two PSD templates  (M1 and M2) per VTU. The required
support is adding the following object to the vdslLineConfProfileTable:
    vdslLineConfPsdTemplate OBJECT-TYPE
          SYNTAX  INTEGER {
                     TemplateMask1(1),
                     TemplateMask2(2)
                 }
          MAX-ACCESS  read-write
          STATUS  current
          DESCRIPTION
            "The PSD template."
          ::= { vdslLineConfProfileEntry xxxx }

5. There is no reference to UPBO control.

SCM Specific changes:
1. SCM may include two bands per transmit direction. We need to add the
following object to vdslLineSCMConfProfileTable:
    vdslLineSCMConfBands OBJECT-TYPE
          SYNTAX  INTEGER {
                     SingleBand(1),
                     TwoBands(2)
                 }
          MAX-ACCESS  read-write
          STATUS  current
          DESCRIPTION
            "Number of bands on Tx direction."
          ::= { vdslLineSCMConfProfileEntry xxxx }

2. There should be a per band table, vdslLineSCMConfProfileTxBandTable,
with 3 indexes (vdslLineConfProfileIndex, vdslPhysSide and
vdslSCMConfProfileTxBandNumber). There is always an entry for
vdslSCMConfProfileTxBandNumber=1, however there is an entry for
vdslSCMConfProfileTxBandNumber=2 only if vdslLineSCMConfBands=TwoBands for
the referred unit.

3. The following objects should be moved from the existing
vdslLineSCMConfProfileTable to the "new" vdslLineSCMConfProfileTxBandTable:
- vdslLineSCMConfProfileTransmitPSDLevel,
- vdslLineSCMConfProfileSymbolRateProfile,
- vdslLineSCMConfProfileConstellationSize, and
- vdslLineSCMConfProfileCenterFrequency

4. In vdslLineSCMConfProfileTable it is not enough to specify the fast
channel codeword size. We also need to specify the size of FEC section
within the codeword..
    vdslLineSCMConfProfileFastFecSize OBJECT-TYPE
          SYNTAX  INTEGER (0..16)
          MAX-ACCESS  read-write
          STATUS  current
          DESCRIPTION
            "When fast channel is being used, this object specifies
              the size of FEC in the codeword. Possible values are:
              0 (no FEC), 2, 4 or 16"
          ::= { vdslLineSCMConfProfileEntry xxxx }

Bob/Rajesh: Please modify the MIB accordingly.

Best Regards,
Moti Morgenstern

Senior System Engineer
Inovia Telecoms Ltd.
Member of the ECI Telecom group
30 Hasivim St.
Petach Tikva, Israel 49133
Tel.: +972-3-9266258 Fax: +972-3-9268182
e-mail: [email-masked]

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