Plusnet to BT - DLM reset or not?

Hi All - I've posted this on the BT forum too but no replies.

My move from Plusnet Unlimited Fibre to Infinity 2 completes on Mon 25th. What I was wondering was if DLM gets reset? I'm already on fibre with Plusnet so figure there's nothing in the Exchange or CAB to do so in theory (my theory so probably wrong!) I just switch and that's it.

Am I wrong?

As a side, G.inp is currently enabled on my line. Am I bets staying with my Billion 8800nl rather than using the HH5? I believe the HH5 isn't G.inp capable.

I wouldn't have thought any FTTC to FTTC transfer caused a DLM reset. As for hardware I'd stay with what you're comfortable with unless you need the specific features of an HH5. PN don't require that you use the HH5 and won't even bother sending it to you unless you ask and agree to pay the P&P.

It's BT that will be sending him the HH5 .

I had a DLM reset when I migrated my connection - FTTC to FTTC transfer.

Was that between two ISP's that use the BT Wholesale backhaul?

No

That'll be why then, you would have had a physical port change and a new circuit provisioned on the new port.

Why would I have a physical port change?

Shifts between LLU to SMPF and vice versa usually trigger a port change, as its easiest way of handling the phone side of things.

So will the move from Plusnet to BT involve a port change?

No, as neither PlusNet nor BT are LLU.

Just switched today from a TTB to BT

Got disconnected i changed username and i reconnected in under 25s to my new ISP

i'm using the same port i reckon so no DLM reset?

or the engineer is very fast in the cabinet lol

In reply to a post by lee111s:

No, as neither PlusNet nor BT are LLU.

So you're saying that a port change only occurs when LLU is involved?

In reply to a post by RobertoS:

It's BT that will be sending him the HH5 .

Oops, yeah.

Switching to or from LLU as I understand it.

Happy to be corrected.

Depends on if you are changing /migrating from /to a different BT open reach product or not

BT openreach FTTC products are, 80/20 55/10 40/10 & 40/2 though a regrade from 40/2 to 40/10 and or 40/10 to/55/10 may not trigger a DLM reset , But going from 80/20 to any of the others would, same if is reversed Also which DLM stability profile is used by the loosing and gaining isp could also trigger a dlm reset to some point, as the MTBE is different for each of the 3 available stability profiles

Also quite why Openreach would carry out any work at a street cab for BTW to LLU migrations i don't know, as all that changes on the FTTC side of things is the handover onto the different GEA cable link at the exchange the PTSN side of things would be changed at the exchange too, but the port in the FTTC cab wouldn't be touched

Edited by tommy45 (Thu 21-Apr-16 20:02:58)

In reply to a post by MrSaffron:

Shifts between LLU to SMPF and vice versa usually trigger a port change, as its easiest way of handling the phone side of things.

Yes at the exchange & not in the FTTC cab, as a certain poster seems to think

That's handy

In reply to a post by tommy45:

In reply to a post by MrSaffron:

Shifts between LLU to SMPF and vice versa usually trigger a port change, as its easiest way of handling the phone side of things.

Yes at the exchange & not in the FTTC cab, as a certain poster seems to think

If that's not the case then can it be explained why a number of customers who switch provider suddenly find there are no spare ports on the day of migration and they lose service (presumably because the port they were connected to is turned off? I've seen 10+ customers this year on the BT forums with thos exact issue.

I'm also not sure that an Openreach product change does always trigger a DLM reset. I always thougt it did, but again on the BT forums, a number of people on banded connections have recontracted their Infinity 1 for the new 55/10 service however, despite them losing sync in the early hours, they remain banded. It's happened to 3 or 4 people since it became available last Friday.

Edited by deleted (Thu 21-Apr-16 20:05:17)

In reply to a post by lee111s:

I've seen 10+ customers this year on the BT forums with thos exact issue.

Do you have a link for any of those handy?

I'll dig out a thread, give me a few minutes.

Maybe because the ISP somehow fubarred the migration and OR systems treated them incorrectly as Cease & provides, which is pretty dumb imo As BTOR should know that joe blogs on port 53 has an active FTTC service, but is migrating ISP and will still require that service/port , it ain't rocket science
Some of these cases may have been due to the likes of tt systems that wouldn't allow FTTC ><Migrations, so they had customers put on DSL for a short time then back onto FTTC doing that could mean that they would loose their old port, and would be the fault of the gaining ISP TT they must use systems that came out of the ark

Edited by tommy45 (Thu 21-Apr-16 20:22:45)

Can't locate one where the customer has actually moved but here's a thread where the customer can't place an order to migrate because there's a waiting list.

If there was no port change then ports being available or not wouldn't be an issue.

https://community.bt.com/t5/Bills-Packages/Transfer-...

I agree, I've never understood why a new port would be needed, but on many occasions I've seen customers complain because their port has been essentially given away when they've migrated.

Thanks.

Proves nothing unfortunately

Hehehehehe.

Why else would a migration order be prevented being placed?

Because BT don't actually know what they're doing?

In reply to a post by lee111s:

I agree, I've never understood why a new port would be needed, but on many occasions I've seen customers complain because their port has been essentially given away when they've migrated.

It's not normal practice for BTOR to swap ports when someone migrates between BTwholesale & LLU , But if the way that the gaining ISP handles the migration in a non standard way ie downgrading incoming FTTC migrations onto DSL this would trigger a cease on the existing FTTC service, loosing the port , as the jumpers would have to be removed to allow DSL on those lines , So as well as the loss of the customers port, this also creates a lot of unnecessary engineering work at the street cab and to the customer Pulse8 was one ISP that had to do migrations this way , due to how tt wholesale worked,apparently

Edited by tommy45 (Thu 21-Apr-16 20:43:34)

Thanks for all the replies all. So in essence, there should be no DLM reset and to keep G.inp active I should keep my trusty 8800nl then - correct?

I seem to remember reading somewhere that BT don't require a password set in the modem and that the username I use can be anything as long as it ends in @btbroadband.com - have I got that right?

Yes although some modems require you to enter a password as they don't allow the field to be blank.

In reply to a post by WelshWArrior:

Thanks for all the replies all. So in essence, there should be no DLM reset and to keep G.inp active I should keep my trusty 8800nl then - correct?

I seem to remember reading somewhere that BT don't require a password set in the modem and that the username I use can be anything as long as it ends in @btbroadband.com - have I got that right?

Sounds about right to me so long as you ain't also changing between OR products as well as per my earlier post, definitely keep the billion especially if on a Huawei cab

Edited by tommy45 (Thu 21-Apr-16 21:26:52)

No need to use the HH5 unless you also have BT TV or you want to allow BT Wifi users to use your connection.

Thanks all. Well I'll be keeping my beloved Billion then

Now fingers crossed the transfer goes smoothly!!

Why else would a migration order be prevented being placed?

Most likely because of a 'computer says no' scenario. It won't allow you to allocate a new port because it says there's none spare .... (your current one isn't spare, you are using it)

In reply to a post by Zarjaz:

Why else would a migration order be prevented being placed?

Most likely because of a 'computer says no' scenario. It won't allow you to allocate a new port because it says there's none spare .... (your current one isn't spare, you are using it)

Indeed but why would a port need allocating if during a migration the port isn't changed?

In reply to a post by lee111s:

Indeed but why would a port need allocating if during a migration the port isn't changed?

Quite.