Kitz Forum
Broadband Related => Broadband Technology => Topic started by: stevebrass on April 17, 2017, 09:03:25 PM
-
Attached two pics of recent work around here. First shows the PCP has gained a Pod and second shows the new DSLAM that has been recently installed.
Is the old DSLAM an ECI and the new a Huawei?
-
yup!
-
It's exactly that. It's exactly what happened at my ECI cabinet. The "pod" on the PCP is for the tie cables for the shiny new 288 line Huawei DSLAM. In the past your PCP would have got a 2nd ECI cabinet but OpenReach are no longer deploying ECI cabinets. I managed to get my line moved over (http://forum.kitz.co.uk/index.php/topic,18678.0.html) to the new Huawei.
-
And still John has not seen any G.INP on his line since the move from ECI to Huawei cabinet and the errored seconds tell us he needs G.INP, it is almost like his circuit still thinks it's connected to the ECI cabinet without any DLM being present very odd indeed.
-
it is almost like his circuit still thinks it's connected to the ECI cabinet without any DLM being present very odd indeed.
Good idea that. Certainly plausible that DLM works in such a way that this data sticks, or worse, it cannot distinguish between the two.
-
Isn't the DLM in the cabinet though?
I've still no idea if my new Huawei cabinet is live.
-
http://www.kitz.co.uk/adsl/DLM_system.htm
The DSLAM holds your line profile, and the sync process works to those settings. It also holds the statistics, in the same way we see in the modem.
Outside the DSLAM will be a part of the OSS system (operation support system) called an element manager. It knows how to write line profiles into the DSLAM (probably a MIB using SNMP) and how to read the statistics. This element manager is remote, but I don't know how many there will be across the country.
DLM is also a centralised process, running in a "RAMBO" box. It analyses the statistics pulled by the element manager, and follows its rules on adapting your line profile ... writing a change back via the element manager.
Nowadays, DLM will also extract that CPE information to place limitations on the allowable line profiles - almost certainly via the element manager too. We don't know how it extracts DSLAM limitation data though ... and I'm prepared to believe it wasn't coded to cope with a PCP with multiple DSLAM types.
-
Thanks wwwombat, I can now see what you mean.
-
DLM is also a centralised process, running in a "RAMBO" box. It analyses the statistics pulled by the element manager, and follows its rules on adapting your line profile ... writing a change back via the element manager.
Nowadays, DLM will also extract that CPE information to place limitations on the allowable line profiles - almost certainly via the element manager too. We don't know how it extracts DSLAM limitation data though ... and I'm prepared to believe it wasn't coded to cope with a PCP with multiple DSLAM types.
I doubt DLM would have any visibility of what PCP any line is connected to, nor would it care. It would almost certainly only be aware of DSLAMs. There is no value to the DLM system having any visibility of the PCP a line is connected to. It would certainly have an ID for every circuit it uses along with an ID for each DSLAM, in the case of here there are 2 DSLAMs so their IDs are painted on them.
I'm not saying you're wrong I just can't see any value at all in either the FTTC element manager or DLM caring about which PCP DSLAMs are connected to; there should be other databases for the copper side and a primary key ID across both for each circuit.
-
Just wondering if a DLM reset on Johns circuit would be beneficial to recalibrate the circuit to that of a Huawei MSAN but John maybe happy in this current state where the DLM ignores his line :-\
-
http://forum.kitz.co.uk/index.php/topic,18678.msg345385.html#msg345385
If the provisioning is still not complete for whatever reason that explains it. DLM isn't aware the line is active so isn't monitoring it.
-
Well there you go then the answer to the odd DLM behavior :giggle:
-
http://forum.kitz.co.uk/index.php/topic,18678.msg345385.html#msg345385
If the provisioning is still not complete for whatever reason that explains it. DLM isn't aware the line is active so isn't monitoring it.
I, too, had forgotten about that post. :-[
-
I doubt DLM would have any visibility of what PCP any line is connected to, nor would it care.
I'm not saying you're wrong I just can't see any value at all in [...]
I write software, and see both the limitations and faults that get written in. And I get to write code that is forced to interface to legacy systems, so I know how limitations get forced on you sometimes (*).
I agree that DLM shouldn't need to know anything about the PCP to do its job. But I can certainly see a way that it could end up in the code in a less-than-ideal world.
(*) Never underestimate the havoc that can be wrought by a software engineer armed only with a keyboard and an old API (https://www.youtube.com/watch?v=gp_D8r-2hwk)