By Simon Woodhead
We discussed recently what we’d like to see from the Narrowband Review. Less than 24 hours later Ofcom published its Wholesale Voice Markets Review 2021-2026. This is important and going to govern our industry for the next 5 years, and arguably reshape it forever.
Rather than brain-dump all our reactions (there are many) here, or indeed simply share our response, which by nature will be somewhat legalistic, we wanted instead to serialise a few points in plain English.
Our response will obviously feature these, so if they resonate with you and you think they matter, we would encourage you to respond to the consultation. You are very welcome to cite Simwood, this blog, or our formal response if it helps.
If you missed them, see Part 1 – Huawei bad for Internet; Huawei good for Voice over Internet, Part 2 – CP Status – we need a new one! , Part 3 – What the hell is IPX? and Part 4 – BT’s unchecked monopoly in porting.
We’ve touched on how porting could be improved in a stroke by Ofcom mandating all hosting networks treat hosted ranges as their own. That is a change which would affect only one hosting network, i.e. BT IPX, as the rest of us already do this. However, there is more to this that warrants exploring.
Even if an IPX Scrote isn’t involved, and a number can actually port, let’s say from Vodafone to Simwood but was originally on BT (and thus still is in our onward routing world), every stage of those porting requests requires the order to mirror the original installation as recorded at BT. Even if Vodafone were operating an IP service, as is the Simwood customer, the port must respect the hierarchy of the installation, e.g. a single main billing number and 5 ranges of 10 numbers that are ‘associated’ with it. Add in a few Virgin ranges that ported in whilst at BT (and thus also under that installation) and it gets even more complicated. The poor end-user needs to know all that, or the gaining network be able to find it out, usually from the previous gaining network. Get it wrong, port doesn’t happen. Get it right, there’s still massive room for BT to cock it up. It is a complete mess.
Now add into the mix some resellers who think that a number is just a number and have re-allocated some unused numbers to other customers and that mess quickly becomes what can only be described as a cluster-fuck! We’ve had instances where entire buildings of multiple businesses have gone offline because one tenant has moved out and ported ‘their’ number. The thing is, they haven’t, as they’re all tied together; the whole building has ported, and thus the whole building is off-line, all because someone tried to be clever 10 years previously. When this happens it takes us months and months to sort it out and either involves a dispute of ownership with one party losing, or the gaining CP doing something sensible until the next time someone wants to port any of the numbers. If the next time the two CPs involved are not both sensible, someone will lose their number permanently.
Now this is avoidable by resellers not re-allocating numbers as we ask repeatedly, but it also defies logic. Surely BT can split ranges? Well no!
We escalated an issue to Ofcom earlier this year as BT were refusing to split a range such that one of these situations could be resolved without one innocent end-user or another losing service. We half-won in that BT (under pressure or not, we don’t know) agreed to specify a solution to do so, and this is now at the ‘Statement of Requirements’ stage. No doubt if it ever gets implemented there will be limitations on the circumstances and manner in which ranges can be split. It won’t be a silver bullet; it never is!
Other than BT being obstructive, which is undoubtedly a factor, let’s explore legitimate reasons for this too. The BT network consists of hundreds of switches, many in the core but crucially 700-odd around the country in local exchanges (DLEs). These all need to maintain routing tables in order to know where to send calls to other ranges, and the less specific these can be, the better. For example, routing a range of 100k mobile numbers takes a single routing table entry, but so does a sub-range of 10, or worse a single number. In their implementation, each takes up 4 route entries to handle failover. BT has long sought to minimise the number of route-entries required and it makes sense why. Doing so makes management simpler but any device has a finite routing table size after which new routes cannot be added. Given DLEs at least used to be populated by old Ericcsson ACE10s or Marconi System Xs, the latter dating from 1979, one might conclude that however cutting edge they were in their day, they are pretty resource constrained nowadays. So yes, protecting those resources by keeping the routing table small makes sense.
What’s ironic here is that the same technology is used by Virgin, who outsourced the management of those switches to … you guess it! BT…but Virgin manage to be able to route at the single number level. The mind boggles. Anyway.
These DLEs were slated to be replaced by soft-switches as part of 21CN, but given 21CN seemed to focus more on broadband provision by the time it was implemented, one has to question how much of this estate was in fact replaced.
However, if it wasn’t before, this review covers BT’s plan to move to all IP for voice and withdraw their copper exchange-based services altogether (rightly or wrongly). This implies the use of modern soft-switches with far more capable routing tables. More likely, it implies the use of a distributed application routing engine, which itself implies a database or RADIUS backed lookup, and thus we can now consider the routing table practically unlimited. In fact, Simwood has worked this way since birth and taking a look at the production routing table we hold that in RAM it takes 300MB (0.3GB) for 3m entries, or 0.1GB per million. There’re 70m people in the UK, so let’s assume we have 10 numbers each (doesn’t everyone!?), we have 700m entries. Let’s further assume failover is defined per route rather than at a higher level, and we have 4 failover paths, that is 2.8bn. Hell, let’s call it 3bn, or 3,000m for simplicity. We’ve probably overstated that by a massive degree but even if we haven’t, that is a data set of at most 3,000*0.1GB which is 300GB. And that is before optimisation and with ludicrous assumptions for volumes. If we overstated it by 5x, or the data was sharded into 5, you could store it in RAM on a Raspberry Pi 4!! Failing that, the full thing could be stored in RAM on an AWS instance for 12 years for less than the cost of the block-chain project to-date. This isn’t a solution spec, but meant to be illustrative of the scale of the problem and the cost of a solution.
And that gets me to the main point. In a review working towards BT being IP based by 2025, and thus having single-number routing capability, this is a prime opportunity to simplify porting and remove all this installation / associated-number specific nonsense. If numbers could be ported individually we’d be so much closer to simplifying things and it’d lend itself so much better to a central database solution (be it blockchain or one that can be updated quicker than once per 20 minutes). Hell, you could say we already have one and it works pretty well for mobile!
This gives 5 years for BT to do what they’re doing anyway, and 5 years for the OTA to delete the multi-line section from the porting manual, both of which should surely be possible!? We expect most networks have retrofitted awareness of BT installation details to their databases purely for porting rather than routing based on it, so this should be a similarly simple change for industry – just treat every port as a single-line port once it leaves the original installation.
A regulatory bod will tell you that the regulation (both in the original European Union directives and in their transposition to the General Conditions) have been worded such as to require single number porting for many years, so we’re not asking for anything radical here.
Ofcom, this is a prime time to fix this though. Please don’t push addressing this end-user harm out beyond 2025!
