Huawei 96-line DSLAM

In a thread a while ago, we were all discussing exactly how the 96 lines of a small Huawei DSLAM were internally divided. I mentioned that I'd seen the wooden boxes that they were delivered in, but couldn't find the photos I took. Well, I found one (you can hover your cursor over it and then click on the magnifying glass to zoom in a bit). So it seems they are delivered (at least in this case) with one "32-line VDSL board", and they can add another two. Presumably if OR wanted it to be delivered with full capacity, the "contents" list would have three lines reading "32-line VDSL board", and no blanking plate.

Is the "BiDi Transceiver" bit for the remotely readable electricity meter?

Sorry if this post seems to be for very little reason, again, it was just a continuation of a discussion which petered out a month or two ago. Hopefully someone finds it interesting.

The BiDi transceiver is a bi-directional optical transceiver. I guess it connects the DSLAM to the fibre optic cable.

Ah, that does make more sense, doesn't it... I did look on Wikipedia but their only offering for "bidi" was bi-directional text. Still closer than my guess, I suppose.

The MA5616 ships as standard with blanking plates though it has four card slots. How those slots are occupied is dynamic. There are 16-port cards as well as 24-port, 32-port and 48-port, for that model.

There's also no problem mixing cards with different port densities, nor is there a problem mixing VDSL with ADSL cards.

What is depressing is that Openreach is still shipping out DSLAMs with the CCUB control board. These are not vectoring-capable. How old is that photo?

14th October 2014. The two PCPs and two DSLAMs are installed but not active. It's a BDUK EO re-arrangement. I think a lot of the work might be done, but they're definitely not active. The commercial rollout in the same town is complete, and the "exchange" (or aggregation nodes, or possibly head end, or whatever) also supplies DSLAMs for at least two villages ~5 miles away. All of the DSLAMs on the commercial rollout are ECI 128 cabs. Are they capable of vectoring? Seems like there is a bit of an undiscovered problem here.

Edited by deleted (Sun 15-Mar-15 03:14:29)

In reply to a post by gazzyk1ns:

Presumably if OR wanted it to be delivered with full capacity, the "contents" list would have three lines reading "32-line VDSL board", and no blanking plate.

As far as I'm aware, DSLAMs are shipped from BTs warehouse and are then fitted with the correct capacity in the field, presumably because it's still factory sealed.

In reply to a post by gazzyk1ns:

Is the "BiDi Transceiver" bit for the remotely readable electricity meter?

As has been stated, the "BiDi" (Bi-directional) transceiver is a little module (Not a card) which the fibre optic cable slots into. This assembly is then slotted into the Gb Interface Card on the DSLAM. If you are familiar with switching, another name for it is a GBIC (GigaBit Interface Converter).

These are usually separate from the interface card because of the different fibre cable types; some are multi-mode (Shorter distances, larger core), and some are single-mode (Longer distances, smaller core); the transceiver is usually the swappable component so you don't have to replace the entire card if you switch to a different cable spec.

That transceiver looks like it's for a single-mode fibre cable with LC connectors on the end of it.

In reply to a post by gazzyk1ns:

All of the DSLAMs on the commercial rollout are ECI 128 cabs. Are they capable of vectoring? Seems like there is a bit of an undiscovered problem here.

These ECIs are board-level (aka card-level) vectoring-capable, after firmware upgrade. But not system-level vectoring-capable.

Board-level vectoring is very limited. To work even half efficiently, the subscriber lines in a particular cable bundle or binder - where they crosstalk with each other - must all be lifted-and-shifted to one linecard in the DSLAM.

That is because the ECI's vectoring engine is embedded in the firmware of the card itself, rather than in the DSLAM controller unit. The latter - where the DSLAM controller unit mitigates crosstalk between ports on different linecards - is known as system-level vectoring.

At first glance it might seem possible, if inconvenient, to do that lift-and-shift of every subscriber line to make board-level vectoring work. However, the distribution of lines across multiple binders - with different binder sizes, different take-up rates for lines in each binder, and whatnot - rarely makes that possible.

The next problem with vectoring, is that Openreach has started to 'cascade' DSLAMs in the street. When one DSLAM reaches capacity, another DSLAM is added in an adjacent cabinet. Which means that crosstalk is potentially spread across two (or more) separate DSLAMs. And that requires node-level vectoring. The Huaweis (can) support this, but so far as I know, the ECIs cannot.

Maybe vectoring algorithms will continue to improve - but a lot of people could be disappointed to find vectoring isn't the panacea they'd hoped. It probably won't return their DSL performance to its original (pre-crosstalk) state. Could be wrong though. Hopefully!

Edited by deleted (Sun 15-Mar-15 19:40:38)

We need a big database of every installed cabinet and its arrangement with others, and which vectoring options they are capable of.

In reply to a post by gazzyk1ns:

We need a big database of every installed cabinet and its arrangement with others, and which vectoring options they are capable of.

As of right now outside of a small trial area there's no vectoring so not really an issue.

Chances are vectoring will be done strategically, not as a mass deployment. G.fast is on the way.

Edited by deleted (Sun 15-Mar-15 19:25:32)