FTTP connection taken by persons unknown & loss of service

The saga so far....
It appears that persons unknown have placed an order for FTTP on a clients circuit, the first indication was loss of service just after midnight.

The FTTPoD connection is provided by Cerberus - they sent loosing provider information including outstanding charges (as still in contract) by email only, but not from one of their usual contact addresses so ended up in a SPAM folder and not seen.

As the circuit has been transferred Cerberus say all they can do is try to take over the circuit with the inherent 10-day cooling-off period, I presume the gaining CP could actually fix the problem more quickly (whoever ordered a service from them won't have one either) but Cerberus don't know who it is and Openreach won't tell them!

Via various convoluted remote tunnelling I've managed to do a PPPoE scan on the connection to the ONT which indicates the PPPoE server / access concentrator is now A0:F3:E4:7C:96:30 sr10.enmid - does anyone have any ideas who the CP may be? (Previously the server was acc-aln2.leb)

Given that there is no telephone number to check the CP can just pick any address, and if they are similar (e.g. Something Farm, Something Cottage, something Farm Cottage) with the same postcode there isn't much to stop this happening more frequently - an current user may be away for a couple of weeks rather than a letter/email not being seen. More importantly there doesn't seem to be any quick method of redressing the problem.

Something doesn’t quite stack up here….

Cerberus will immediately send out an unsolicited cease notification by email to the bill payer when they receive notice from the gaining provider - this will be in advance if the cease. This email comes from the Provisioning Group.

When the cease is effected at some later point, only then will Cerberus issue outstanding invoices etc. This comes from Accounts. The same email address as all usual monthly billing.

If all email correspondence from Cerberus was going into your clients spam mailbox, then how were they receiving their monthly invoices?

They haven't had the billing email yet, only the unsolicited cease email which indicated there would be charges as still in contract. I don't know why that particular email got tagged as SPAM, the original provisioning emails and monthly invoices were/are fine.

What a time for a spam filter epic fail!

Think I would immediately instruct Cerberus to takeover the service again with immediate effect. Need to make clear that client didn’t authorise the original migrate order. They should get compensated by the “gaining” provider.

This could take some days to resolve though and I’m guessing no service as pppoe auth is preventing matters. You at least know the CP isn’t either of TalkTalk or Sky….

Indeed. As the transfer was completed they have said it will take 10 working days, they are effectively starting a new takeover of the service from whichever CP now has it.

Yes, without knowing what the PPPoE credentials should be there isn't any way to authenticate.

It could still be TalkTalk Business as they use PPPoE, only their residential services are IPoE.

Edited by tdw42 (Mon 27-Sep-21 23:28:14)

Won’t be TTB either as their pppoe uses dummy creds - the old Cerberus creds would have re-auth’d after the disconnect and the new connection just comes up. Been there got the shirt.

The systems in use are clearly wrong, surely the rules need changing so that the original service provider needs to get permission or acknowledgment first to their "Sorry you are leaving" email or letter before allowing the transfer? Although perhaps OFCOM don't want the original supplier being able to block the transfer in anyway so maybe that is why they can't do anything to stop it.

On a FTTP migration doesn't the customer need to supply the ONT serial number? I guess this number could have been taken down wrong, although then the new ISP should have been able to see mismatching addresses, assuming they checked.

I do hope you get it sorted out soon, but the system does seem to be setup for these mistakes to happen all too easily.

In reply to a post by E300:

perhaps OFCOM don't want the original supplier being able to block the transfer in anyway so maybe that is why they can't do anything to stop it.

I think that's the case - to minimise friction on transfers.

I had this happen to me on copper/FTTC, with our Plusnet service being "slammed" by Talktalk.

A letter and package arrived at our house, addressed to some random person - both of which we returned unopened as "not known at this address". Plusnet didn't notify us that the service was being taken over. We didn't know it at the time, but the package was almost certainly a Talktalk router.

We lost our service, including our phone number, for about three weeks.

Plusnet couldn't reinstate the account exactly as before - I ended up with a new account, a new static IP, and lost my referrals - so I now have to ask for a discount on each renewal.

In reply to a post by E300:

On a FTTP migration doesn't the customer need to supply the ONT serial number?

I don't think so.

In an ideal world, each line would have a circuit reference: if there are multiple ONTs in the same premise, then there's scope for confusion. I believe copper lines have such references ("CBUK..." if I remember rightly?) but consumers are generally unaware of them. The phone number was normally good enough, even though the phone number can move between lines.

In reply to a post by E300:

On a FTTP migration doesn't the customer need to supply the ONT serial number? I guess this number could have been taken down wrong, although then the new ISP should have been able to see mismatching addresses, assuming they checked.

Not as things stand, they don’t need to give the serial number. Probably a good idea, although there would be complaints from the CPs I reckon. Would however stop this sort of thing happening. Not sure how widespread a problem it is…

The AC name suggests sr10.enmid.isp.sky.com - although why PPPoE discovery would work on a DHCP connection is anyone's guess.

That’s frankly appalling! Did you ever receive any explanation and/or apology (dare I ask compensation) from TalkTalk as to how this happened? Sounds like Plusnet were also culpable in not sending you any sort of unsolicited cease notice.

What a shocker 😤

Thanks, I tried plain DHCP last night but will have a go with MER / option 61 later and see if that does anything

In reply to a post by Pheasant:

That’s frankly appalling! Did you ever receive any explanation and/or apology (dare I ask compensation) from TalkTalk as to how this happened? Sounds like Plusnet were also culpable in not sending you any sort of unsolicited cease notice.

What a shocker 😤

No compensation from anyone. Plusnet obviously refunded me for the period while I was out of service. Talktalk were extremely hard to get hold of; I did manage to speak to them a couple of times, but they didn't say anything substantial, since I wasn't actually their customer. It was Plusnet who pushed through the process to reclaim the line and our phone number.

The name of the person on the account was not anyone from our street. It appears Talktalk created a line take-over order for a random address, and we were just unlucky it was us.

The only silver lining was that my FTTPoD service had gone live just a few days before, so at least we weren't cut off from the Internet.

In reply to a post by Pheasant:

They should get compensated by the “gaining” provider.

Not sure how compensation applies. Both providers appear to have followed the required Ofcom processor for migration. If the email address that Cerberus sent the email to was the one provided by the customer then Cerberus would also have done nothing wrong. Technically no-one is at fault here as everything was undertaken as they are required to do.

The CBUK reference is pretty much obsolete these days. Superseded by OGEA references, and LLXX________

Given this….

The name of the person on the account was not anyone from our street. It appears Talktalk created a line take-over order for a random address, and we were just unlucky it was us.

I’d beg to differ that TT followed process.

Let’s hope this new “One Touch Switch” process I’ve just read about over at ISPreview is better.

They have 18 months to get it right!

https://www.ispreview.co.uk/index.php/2021/09/ofcom-...

How would TalkTalk know if it wasn't someone new buying the property? That is the whole reason the losing provider sends the email/letter to the current customer to tell them that someone has applied. There isn't a check I know of that TalkTalk could do to prove that someone had mistakenly ordered - if I was moving into a new house then I can buy a new service there and the supplier would have no way to tell whether it was legitimate or not.

When I moved from Cerberus to IDNet on FTTP, IDNet asked me to send them a picture of the ONT with serial number in view, so that seems a pretty good safety check. Of course this doesn't work with VDSL on a telephone line.

Surely the losing ISP should be mandated to undertake due diligence before cancelling. This could take the form of clicking a link in the 'sorry you are leaving' email (to confirm they received it) and if they don't get this confirmation they should write to the address of the bill payer. Assuming any email is going to be received is always going to cause a problem at some point as you can't assume an email ever reaches the recipient unless they confirm it has. Also there must be some check available by Openreach that confirms a telephone is registered to a certain address to avoid mistakes?

I think reliable communication from the losing ISP is the only safeguard.

Confirming the telephone number doesn't help: in our case, the Talktalk service that we got slammed with had its own telephone number.

The internet PPPoE stopped working, but it was by dialling outbound that we were able to prove that the line had been taken over.

In reply to a post by E300:

When I moved from Cerberus to IDNet on FTTP, IDNet asked me to send them a picture of the ONT with serial number in view, so that seems a pretty good safety check. Of course this doesn't work with VDSL on a telephone line.

That's at least an attempt by the gaining provider to exercise some diligence here. Of course not all providers do anything like this; we know first hand TalkTalk don't ask for any corroborating checks. They didn't for me and they didn't for candlerb's slamming.

Lack of *ANY* proper diligence by the gaining provider is the first part of the problem.

Surely the losing ISP should be mandated to undertake due diligence before cancelling. This could take the form of clicking a link in the 'sorry you are leaving' email (to confirm they received it) and if they don't get this confirmation they should write to the address of the bill payer. Assuming any email is going to be received is always going to cause a problem at some point as you can't assume an email ever reaches the recipient unless they confirm it has. Also there must be some check available by Openreach that confirms a telephone is registered to a certain address to avoid mistakes?

Agreed - making the receipt of a response from the connected customer mandatory on the cease notice would be the simplest way to perform diligence on the cease. That would be the fail safe.

Not really that hard and it would avoid all the needless hassle, disruption and cost of when this process is initiated in error.

In reply to a post by Pheasant:

Agreed - making the receipt of a response from the connected customer mandatory on the cease notice would be the simplest way to perform diligence on the cease. That would be the fail safe.

Not really that hard and it would avoid all the needless hassle, disruption and cost of when this process is initiated in error.

Some sort of fail safe is needed but I can see awkward cases where someone is moving into a property and wants a service provided but the person moving out does not respond to ISP communication from the previous provider. There would be an obvious break point when the original resident stopped paying the bill but that could take a while. If you start putting time limits on we are back to where we started. No easy answer but the present system is clearly more risky than a sensible world would like to accept.

In reply to a post by GonePostal:

In reply to a post by Pheasant:

Agreed - making the receipt of a response from the connected customer mandatory on the cease notice would be the simplest way to perform diligence on the cease. That would be the fail safe.

Not really that hard and it would avoid all the needless hassle, disruption and cost of when this process is initiated in error.

Some sort of fail safe is needed but I can see awkward cases where someone is moving into a property and wants a service provided but the person moving out does not respond to ISP communication from the previous provider. There would be an obvious break point when the original resident stopped paying the bill but that could take a while. If you start putting time limits on we are back to where we started. No easy answer but the present system is clearly more risky than a sensible world would like to accept.

I had this exact experience when moving into my current house about 9 years ago. The previous owner was in no hurry to tell Sky they had moved and I had to keep making requests to BT to get a ADSL service. Thankfully that delay of a few weeks was just long enough to find out the area was getting FTTC so I was able to go straight to FTTC about 4 weeks after we moved in. I still think there needs to be a mechanism to take over ownership of a connection. Hopefully this is something that can be improved going forward.

In reply to a post by ft247:

The AC name suggests sr10.enmid.isp.sky.com - although why PPPoE discovery would work on a DHCP connection is anyone's guess.

Many thanks for this info, it is indeed a Sky connection so adding generic Sky-style option 61 provides an IP address - at least there is reasonable bandwidth available now, just the incoming access to the original static IPs not available.

And yes, why they have a PPPoE server / access concentrator listening when they don't use it is a mystery - but exceedingly fortunate in this case.

Cerberus are being as helpful as they can be, despite the whole thing being kicked off by Sky not correctly matching records trying to unwind this is completely hampered by Openreach systems/processes.

I would suggest the taking over ISP has to write a letter to the address with a code in that you then have to ring the ISP up and provide to complete the move. No verification code then no move.

I would suggest that it should have something on the outside indicating that the broadband connection is about to be moved to give a heads up to a person being slammed. It should also have a number to call to prevent the slam, and the taking over ISP should then be prevented from attempting another take over for three months on that line/address. It should also have the name of the person attempting to take over the line.

I know my brother had problems when someone provided the wrong address when moving house. He got the notification from TalkTalk, and rang them up to prevent the slam. However the other party just provided the same wrong details again and he had to do it again. The taking over ISP went all data protection and falsely claimed they could not provide the name of the person attempting the take over. Thing is information they hold about your address/line is *yours* and they actually *HAVE* to turn it over (though they can ask for a fee). In fact failure to do so is an offence and a failure to correct the wrong information is another offence.

Far to many companies hide behind data protection for reasons not to do something or cover up there mistakes. The best one was IBM claiming that logs from the BMC on one of my servers at work was covered by GDPR. Except GDPR only covers personal data and there is no personal data in the logs. They also tried to claim Lenovo held the copyright on the data (IBM provide support for Lenovo servers in the UK). Even better IBM have you stick GDPR stickers on faulty DRAM that you return!!!

In reply to a post by jabuzzard:

I would suggest the taking over ISP has to write a letter to the address with a code in that you then have to ring the ISP up and provide to complete the move. No verification code then no move.

[EDIT] That's roughly how it used to work until 2014. The codes were called MAC codes. You first contacted the losing ISP to get the code, and then had 30 days to give the code to the gaining ISP.

The process was abandoned as it didn't work well. In particular, the losing ISP had a strong incentive to make it extremely difficult to get hold of your MAC code.

https://recombu.com/digital/article/no-more-mac-code...

Your proposal is more or less the same, except the other way round. There would still be a strong disincentive for the losing ISP to accept the code: I expect they would keep "accidentally" losing it, claiming it was invalid etc.

Or are you saying that the gaining ISP writes to the address, and the gaining ISP has to have their own code read back to them over the phone?

Edited by candlerb (Thu 30-Sep-21 08:11:08)

Agree, the whole idea of the new system was to stop losing providers from being able to block moves. There were times people just couldn't leave an ISP because the losing provider didn't or wouldn't process the instructions.

When the new process came in there were lots of discussions about it but ultimately both systems have issues - the current issue can result in gazumped connections if the losing ISP doesn't manage to get the message to the customer and the old system could result in it being virtually impossible to leave an ISP if they wouldn't process the instruction. I think we see fewer issues with the new system than with the old but the impact on the ones it happens to is high with lost connection.

Good that you’re up and running - just be careful (legally) using what is effectively someone else’s service. I know they’ve slammed you, but you don’t really want any possible comebacks from Sky now.

I see his proposal as the new ISP sends a code by post to the address and then the new ISP won't complete the order until they receive the code back by telephone or web form.

Thanks
Dan

Where this will fail is if you legitimately order service at the new address, but don't have access to it yet. In particular, you're moving in on a particular day, but nobody lives there right now, or the current occupier doesn't cooperate, or just returns the mail to sender as it's not addressed to them.

I think the fix is better the other way round: the losing ISP sends a letter to *their* customer at that address, and if the customer doesn't contact them to stop the transfer, then it goes ahead.

Letters do occasionally get delayed or lost, but it's not that often.

The mobile networks had the 'losing-provider-obstructs-code-issue' problem - regulation solved it with the introduction of the text-to-switch process, where a PAC code must be issued in response to an SMS.

I'd suggest that the gaining provider needs to include the losing provider account number in the port request. That would prevent slamming while allowing minimal room for the losing provider to obstruct the process.

I'd imagine account numbers are included on all paper and electronic billing statements already, and if not that would be a reasonable regulatory requirement.

90% of customers will be able to access their account online to check a statement for the required account number, and those that don't just need to request a bill from the losing provider - a request they're already set up to deal with and one that doesn't involve discussing switching away.

This doesn't solve the problem of house moves, but I'd say most sellers would be happy to provide the details after exchange of contracts. There will always be messier situations like reposessions, disappearing international tenants leaving a service live and a direct debit that keeps getting paid... and who knows what else. Without a way to prove ownership of an address it's very difficult.

Edited by ft247 (Thu 30-Sep-21 14:09:54)

It's a tricky one, as the issue was caused by lack of due diligence by Sky compounded by the communications going astray. If there was a mechanism to address this quickly I wouldn't have bothered but a couple of weeks on a not brilliant FTTC backup connection just isn't acceptable for the business users, and it isn't as though anyones credentials have been misappropriated. The local MP is on the case and can hopefully prod something at a higher level to get things moving more quickly.

There do need to be better checks for transfers, it is different to other utilities - you still get gas or electricity even if you haven't signed up with a suppler before you move in somewhere, for example.

I know there were issues with the MAC system with loosing providers dragging things out, but given that ONTs have a serial number on them and this information is available to communication providers making it mandatory for working-line takeover isn't unreasonable, nor would sellers providing it at exchange of contract for house sales.

Copper circuits are more difficult as they often don't have an ID on the NTE, and it may not be correct if the phone number has been migrated elsewhere, obviously this is a time-limited problem as copper withdrawal draws closer.

Agreed. For FTTP services, if the gaining provider had to ask for the ONT serial number then gave that to OR, at least it would prove it was the right service *and* the customer was in possession of the property, or had at least access to it. Due diligence complete without too much mucking around.

In reply to a post by Pheasant:

Agreed. For FTTP services, if the gaining provider had to ask for the ONT serial number then gave that to OR, at least it would prove it was the right service *and* the customer was in possession of the property, or had at least access to it. Due diligence complete without too much mucking around.

Communication Providers who place orders with Openreach have access to installed ONT serial numbers (I can look them up for a postcode and address via a reseller account I have some access to, for example) so it could still be gamed, but it would go a long way to verifying an order is correct.

There is hopefully some honour among.. errr CPs

It's a nuclear option but you could divert subscribers to a captive portal type system that explains that another provider is taking over the service, names them, and gives a "yes" or "no" option to click to allow the transfer to take place.

I think realistically a combination of email and text message should be enough - it's not too much to ask subscribers to keep contact details up to date.

What a PITA.

I appreciate that some providers may try to be highly err, persuasive in retaining customers which is why customers don't want to contact them but ofcom ought to bring back the MAC code with a requiremnt for ISPs to provide it within your account management/billing portal to at least make this more difficult.

Had a narrow escape myself a couple of years back when my neighbours ordered broadband froma well known provider owned by the forumer UK teleoms monopoly but the person taking the order from them put my house number instead.

II didn't know anything until I got a letter addressed to someone else (neighbours hadn;t introduced themselves at that time). and they even tried to deliver a router.

I rang said provider and told them I didn't know the person and hadn;t ordered broadband from them but it didn't stop there, they even sent an Openreach person to activate a copper landline!

I went and knocked and they apologised profusely.

Fortunately they'd ordered copper broadband at the time otherwise I too might have found myself with my FTTP connection taken over as has happened in your client's case.

I did talk to Zen after this and they told me providers aren;'t permitted to turn down these requests even if the account holder puts in writing that they want these requests declined unless they receive written notification from the account holder that they wish to leave.

I'm sure this is a mistake but this seems like a gaping hole that someone will exploit at some point.

I hope you get it fixed quickly.

In reply to a post by jpm:

It's a nuclear option but you could divert subscribers to a captive portal type system that explains that another provider is taking over the service, names them, and gives a "yes" or "no" option to click to allow the transfer to take place.

That would be excessively heavy-handed.

I think realistically a combination of email and text message should be enough - it's not too much to ask subscribers to keep contact details up to date.

For something important as this relying on a single method of communication without any acknowledgment is just open to problems arising. In this case the contact details were correct, something in the email flagged it as spam despite other emails being received OK and there was no secondary notification. I believe Plusnet send email & post on transfer/termination, for example.

Some closed-loop system with an acknowledgement could actually speed up the process, I've not looked at the detail of the proposed one-touch system yet to see how that is going to work. The real issue with the current system is there is no way to quickly revert the change if information has gone astray.

In reply to a post by tdw42:

I believe Plusnet send email & post on transfer/termination, for example.

Sadly, not to me they didn't

In reply to a post by Pheasant:

If the gaining provider had to ask for the ONT serial number then gave that to OR, at least it would prove it was the right service *and* the customer was in possession of the property, or had at least access to it. Due diligence complete without too much mucking around.

We actually already do, as we spotted a flaw in systems without some validation. Whenever we get orders for a Port Restart or Transfer, we request the ONT SN and check that it matches before proceeding. If there is a mismatch, we then take whatever steps to resolve.

So some of us are either ahead of the game or used our heads

Very senseible indeed. Thank you.

Did you get reconnected OK in the end?

Yes thanks. A week / 5 working days after discovering which ISP had taken over the service, which allowed resolution to be progressed at higher levels, the Sky service disappeared late afternoon. Openreach dragged things out by not closing the order off, normal service was eventually restored early the following afternoon.

All in all rather stressful, hopefully some sort of validation will be incoporated in the new switching processes to reduce similar ocurrences.

Thank you for the update.

Had wondered if Sky had circled back and explained or said anything further (or apologised) on the matter, considering it was their fault/lack of due diligence.

You'd hope there would be some sort of lessons learned from these mistakes....

Glad its all back to normal now anyway.

Edited by Pheasant (Mon 01-Nov-21 17:33:02)

In reply to a post by aquiss:

We actually already do, as we spotted a flaw in systems without some validation. Whenever we get orders for a Port Restart or Transfer, we request the ONT SN and check that it matches before proceeding. If there is a mismatch, we then take whatever steps to resolve.

So some of us are either ahead of the game or used our heads

Now we just need OFCOM to make that mandatory for all FTTP transfers. Asking someone for the serial number of their ONT is perfectly reasonable and at a stroke virtually eliminates the problem.

An alternative would be to introduce compensation say £50 per lost day of service payable by the ISP wrongfully taking over the service and leave it to the ISP's to introduce methods to stop the problem. You can be dam sure that new checks would come in PDQ in that scenario.

The basic problem at the moment is an ISP that wrongfully takes someones service suffers no downsides so there is no incentive to do anything to eliminate the problem.

You also have to do something about house moves though, so that someone can book a service to be activated on the day they move in. This is a very common scenario, and there will be many existing owners or landlords who won't cooperate (in particular, they won't be bothered to visit the property to record the serial number)

Maybe instead it would be better for the person ordering service to provide documentation proving that they will be entitled to llive at that address from that given date (e.g. copy of purchase contract, copy of tenancy agreement). That seems more reasonable to me.

In reply to a post by candlerb:

Maybe instead it would be better for the person ordering service to provide documentation proving that they will be entitled to llive at that address from that given date (e.g. copy of purchase contract, copy of tenancy agreement). That seems more reasonable to me.

How about this: anyone whose line is slammed is entitled to £500 compensation from the slamming ISP, unless that person was selling or letting their property and pulls out of the deal.

Taking over an active FTTP service requires the ONT SN. If that's not available, credit card details to be taken and warnings to be issued that placing an order for someone else's property is a costly business.

Admittedly I can see the flaws (there's a strong incentive to slam yourself) but something in this direction could work.

You do have to balance this with the difficulty of moving legitimately. If you charge an ISP a fine of £500 for slamming then they will put in a number of additional hoops to jump through to be able to change ISP - the whole idea of the Ofcom changes to how you switch ISPs was to make it easier to do so and this would go against that goal.

"You also have to do something about house moves though, so that someone can book a service to be activated on the day they move in."

Problem with that is that completion and exchange are two different things and until the exchange day (usually the move in day) both parties can pull out.

In reply to a post by broadband66:

"You also have to do something about house moves though, so that someone can book a service to be activated on the day they move in."

Problem with that is that completion and exchange are two different things and until the exchange day (usually the move in day) both parties can pull out.

Indeed outside Scotland that is the case. So back to the serial number for the ONT. Unlike FTTC or ADSL regardless of your vendor there is always the same physical link from the ONT back to the same port on the OLT regardless of who you actually get the service from when it is based on the Openreach network.

At this point it is a configuration issue on the OLT where the data from the relevant ONT is directed to. That is no actual engineer is required to visit any physical pieces of kit for the connection to be migrated from one provider to another.

So in the case of a move, it should be perfectly possible to provide the serial number of the ONT to the taking over ISP on the day and it should be a short period of time before the reconfiguration is done so that ONT points to the new ISP.

Any new router that is required could be sent to the customers old address in advance of the move in date.

As such I see no good reason why for FTTP the customer cannot be required to provide the serial number of the ONT to the ISP taking over the line. This would with one fell swoop eliminate people being slammed by mistake on FTTP lines, because the chances of reading out the wrong serial number that would match up with a given address should be very small.

Better still would be if the serial numbers on the ONT had a suitable check digit too, so the ISP could double check the customer had read it correctly.

I'm not directly involved (we designed the network, did the main installation commissioning and provide ongong second/third line support, the FTTPoD rental is held by locals who also provide first line support), but it did filter back that the Sky systems autopopulate the ONT details at an address, and this is not the first occurrance. I believe that they are going to look at their provisioning process, but whether that actually leads to change will have to be seen.

Although we are looking at permanent backup options it doesn't always help - another system operated along similar lines has FTTC backup (installed after that FTTPoD connection had a couple of days outage due to damage to a connection at the head-end exchange) recently had an outage. Both connections lost service at 13:25, the FTTPoD connection eventually reappeared at 22:05 and the FTTC connection at 22:45 (once the FTTPoD connection had been restored we could see the modem was synced but no PPPoE server response until this time).

For one of the networks the only local mobile mast (EE) has recently been upgraded to 4G, so that is a possibility to diversify backup connectivity, although it likely shares the same spine fibre back to the exchange. The other network has no mobile coverage at all from any provider so that wouldn't be an option there.