Kitz Forum
Broadband Related => Telephony Wiring + Equipment => Topic started by: digitalnemesis on April 22, 2016, 04:53:46 PM
-
What exactly is in involved and how does the engineer ensure that the right FTTC profile remains in place? As in, not accidently put onto a 40/10 line profile from 80/20 since the wires are different?
Would you consider a line pair change the same as a having a new line installed?
-
Its just simply moving a jumper from one D side pair to another in the cab and moving your dropwire at the DP. Nothing changes as far as broadband is concerned.
-
Its just simply moving a jumper from one D side pair to another in the cab and moving your dropwire at the DP. Nothing changes as far as broadband is concerned.
So basically the same location in the cabinet and DP but just swap the line pairs? Like swapping an ethernet lead on a router?
-
So basically the same location in the cabinet and DP but just swap the line pairs? Like swapping an ethernet lead on a router?
Yes, exactly. :)
-
So basically the same location in the cabinet and DP but just swap the line pairs? Like swapping an ethernet lead on a router?
Yes, exactly. :)
Now I was thinking, what if a new port was required in the cabinet? How would the engineer someone update records so that the new pair is linked to the same line? So that there won't be any discrepancies in line profiles, etc.?
-
Its just another pair of copper wires, nothing too technical.
-
My line got a pair swap as part of a water ingress issue causing instability, a DLM reset was also performed afterwards :)
This I guess depends on the nature of the fault being voice or broadband.
-
Its just another pair of copper wires, nothing too technical.
Yes, but I mean, what if due to a faulty port in the cab, another port had to be assigned? Would the cabinet automatically know it's the same "line, phone number"?
Like I've been reading about people's lines being switch for another number by some dodgy engineers?
-
I believe if they swap ports in the FTTC cab, they need to call up to get the port swapped before the service can be issued from that new port.
However, others will confirm
-
True ...... we can only provide a new port if the DCoE deem it suitable (and they kick the ar4e out of the stats before they do this).
The simple 'Copper pair'. Not as simple as some would have you believe. There's a whole host of 'things' that can and do go wrong, plus the 'disturbers' within the bundle that will affect the X-Talk. We can do tests to check on the 'noise' levels of the disturbers, but generally wont. It is a legacy service ......... you get what you get for the most part.
-
True ...... we can only provide a new port if the DCoE deem it suitable (and they kick the ar4e out of the stats before they do this).
The simple 'Copper pair'. Not as simple as some would have you believe. There's a whole host of 'things' that can and do go wrong, plus the 'disturbers' within the bundle that will affect the X-Talk. We can do tests to check on the 'noise' levels of the disturbers, but generally wont. It is a legacy service ......... you get what you get for the most part.
How easy it is for the DCoE to allow a line pair swap to clear a fault?
-
That can come across as a loaded question. IF there has been a fault identified, it's incredibly easy to allocate a new port.
However, I would imagine the skill comes in deciphering the difference between pedants, and genuine fault scenarios. I have no idea of the parameters, but can well imagine the DCoE have their very own targets regarding allocation of new ports ??