Someone asked me, if I ran BT, what would I have done differently to stop these problems?
The basic problem is the service BT provide, which is one-sided. They have a modem at the exchange and the end user or ISP provides a modem. If they work, then good. If not, then there is no way to really be sure who's at fault. The service is provided "at the master socket", but to test at that point is expensive for BT as they have to send an engineer.
The result is ISPs ordered engineers, because they were free, even when it was end user problems. BT retaliated by charging for engineers when proved to be end users fault. Except they went too far and charged when they could not find a fault in BT, so assuming end user is cause (not proving). They also refused to meet at the handover point - i.e. to test where the service is delivered - insisting one orders an optional engineering service without proving it was not a BT fault first. There have been many shots fired both ways in this war, and it is still an issue. The latest is over co-op calls from engineers, but the battles will keep going forever I am sure.
So really, what should be done. What is the right way to do this? What would I have done?
The answer is very simple, and probably not actually stupidly expensive. See the picture. It is of a faceplate splitter and of a small DSL modem. The ADSL chipsets are getting smaller and more integrated all of the time. You can see how a DSL modem could fit in the space of one of these splitters with very little effort.
What we need is a faceplate DSL modem with Ethernet PPPoE jumbo frame (either talking PPPoA on the wire or jumbo frame bridging). Preset to BT's settings of 0/38. No config pages, nothing. If acting as a PPPoE endpoint then it could do with some PPPoE negotiation options (lets write an RFC) to allow an attached router to set alternative options for the line, and to get sync status, but the default should be a proper PPPoE endpoint supporting full 1508 PPPoE (1500 payload). If bridging, it does not need these options even.
It probably needs a power jack on the side as I doubt it can, yet, be line powered. For bonus points make it work on PoE as well.
Importantly it also needs back-end OAM type tests allowing BT to see line status, carry out low level echo tests on the ATM side, and even do tests out on to the Ethernet port including basic TDM (which is standard in many Ethernet chipsets). It must be able to do good quality line level testing and test beyond the handover point on the Ethernet (so confirming cable presence, length, number of pairs, far end connected, etc).
These need to be mass produced and made a standard Openreach level service that plugs in to GEA in the exchange. BT need to provide tests to check the line and Ethernet port. The faceplate itself could be self install of the BT modem, or engineer visit, but self install makes a lot more sense.
We see DSL routers as low as £15. In the quantities BT would need I bet the could get these for £10 or less.
So why would this solve the SFI battle? The answer is simple, and we see this with FTTC now. It is because the service from BT would no longer be one-sided. It would be delivered to the Ethernet port, and include testing up to and including that port. BT could actually prove the service to the handover point. Engineers would only ever be needed if there really is a fault, so no chance of spurious engineers being ordered. BT could go back to the same system where engineers do not get charged for. ISPs could eliminate BT from the problem by simple BT provided tests.
It would still allow all of the features of both sophisticated and cheap routers, allowing end user and ISP choice of kit. The routers would be PPPoE, but would work as well for ADSL, FTTC or FTTP. If the modem took PoE the routers would have PoE to power them, avoiding extra power bricks. Routers already exist!
By making this GEA, it means that GEA in the exchange (as used by BTW and other ISPs) could handle FTTP, FTTC and ADSL all on the same links with the same ordering and management interfaces and fault reporting. Obviously it would be neat to get VDSL chipsets down to the same size and having same levels of testing. FTTP is already done as an "active NTE", and this would just complete the set offering 250k to 330M in the same orthogonal Openreach service.
It could run along side existing DSL services as an option that costs slightly more to install. BT could do self install via ISPs who manage the shipping of the modem to the end user. BT would be able to tell their modem is on the line, and the design would mean it has to be at the master socket, eliminating splitter issues and extension wiring.
To quote from last nights excellent stand-up at Woking, in the words of Alan Davies: That's my view, anyway.
So sensible it will never happen...
ReplyDeleteHypothetically, let's assume Mr/Mrs BT is reading this and thinks "My, that surely is a splendid idea.", how much work would they have to do to get it implemented, do you think? A year or two?
ReplyDeleteOn the other hand, is there any reason why Mr/Mrs BT shouldn't think "What a ridiculous idea. I think we'd rather keep on the way we are and charging for it."?
Just out of interest.
That is a good question. I am sure a suitable modem manufacturer would be happy to take on the project given some assurance of order quantities, and I would be surprised if they needed more than 6 to 9 months development time. It is a product design not new chipsets. Basically, we could probably manage that using standard chipsets! There may be solutions just needing the right packaging. Managing GEA would be harder as it means Openreach doing DSLAMs (like they do for FTTC now) but at the exchange. It could be quicker if the line and modem was openreach but the DSLAM was still BTW. i.e. Openreach selling an "active broadband" service to BTW.
DeleteI've never understood why we even have PPP on ADSL links - why not do plain bridged Ethernet (which they do in other parts of the world, such as Denmark).
ReplyDeletePPP gives us authentication and autoconfiguration:
- Authentication isn't required because BT can tell which subscriber you are by which physical line you're using, exactly the same as POTS - your POTS handset doesn't authenticate with the exchange, the exchange already knows that that physical bit of copper is connected to a specific subscriber.
- Autoconfiguration is already easy over plain ethernet; an uplink to an ISP needs no more autoconfiguration than your average LAN connection, which is already handled by protocols such as DHCP.
Well, we can do that on FTTC and FTTP now, using GEA. If this was done, with ADSL over GEA, we could offer that too.
DeleteJust run the internet already. Or at least BT.
ReplyDelete