Speaking Engagements & Private Workshops - Get Dean Bubley to present or chair your event

Need an experienced, provocative & influential telecoms keynote speaker, moderator/chair or workshop facilitator?
To see recent presentations, and discuss Dean Bubley's appearance at a specific event, click here

Showing posts with label QoS. Show all posts
Showing posts with label QoS. Show all posts

Thursday, January 12, 2023

Workarounds, hacks & alternatives to network QoS

Originally published Jan 12th 2023 on my LinkedIn Newsletter - see here for comments

Sometimes, upgrading the network isn't the answer to every problem.

For as long as I can remember, the telecom industry has talked about quality-of-service, both on fixed and mobile networks. There has always been discussion around "fast lanes", "bit-rate guarantees" and more recently "network slicing". Videoconferencing and VoIP were touted as needing priority QoS, for instance. 

There have also always been predictions about future needs of innovative applications, which would at a minimum need much higher downlink and uplink speeds (justifying the next generation of access technology), but also often tighter requirements on latency or predictability.

Cloud gaming would need millisecond-level latency, connected cars would send terabytes of data across the network and so on.

We see it again today, with predictions for metaverse applications adding yet more zeroes - we'll have 8K screens in front of our eyes, running at 120 frames per second, with Gbps speeds and sub-millisecond latencies need to avoid nausea or other nasty effects. So we'll need 6G to be designed to cope.

The issue is that many in the network industry often don't realise that not every technical problem needs a network-based solution, with smarter core network policies and controls, or huge extra capacity over the radio-network (and the attendant extra spectrum and sites to go with it).

Often, there are other non-network solutions that achieve (roughly) the same effects and outcomes. There's a mix of approaches, each with different levels of sophistication and practicality. Some are elegant technical designs. Others are best described as "Heath Robinson" or "MacGyver" approaches, depending on which side of the Atlantic you live.

I think they can be classified into four groups:

  • Software: Most obviously, a lot of data can be compressed. Buffers can be used to smooth out fluctuations. Clever techniques can correct for dropped or delayed packets. There's a lot more going on here though - some examples are described below.
  • Hardware / physical: Some problems have a "real world" workaround. Sending someone a USB memory stick is a (high latency) alternative to sending large volumes of data across a network. Phones with dual SIM-slots (or, now, eSIM profiles) allow coverage gaps or excess costs to be arbitraged.
  • Architectural: What's better? One expensive QoS-managed connection, or two cheaper unmanaged ones bonded together or used for diverse routing? The success of SDWAN provides a clue. Another example is the use of onboard compute (and Moore's Law) in vehicles, rather than processing telemetry data in the cloud or network-edge. In-built sound and image recognition in smart speakers or phones is a similar approach to distributed-compute architecture. That may have an extra benefit of privacy, too.
  • Behavioural: The other set of workaround exploit human psychology. Setting expectations - or warning of possible glitches - is often preferable to fixing or apologising for problems after they occur. Skype was one of the first communications apps to warn of dodgy connections - and also had the ability to reconnect when the network performance improved. Compare that with a normal PSTN/VoLTE call drop - it might have network QoS, but if you lose signal in an elevator, you won't get a warning, apology or a simplified reconnection.

These aren't cure-alls. Obviously if you're running a factory, you'd prefer not to have the automation system cough politely and quietly tell you to expect some downtime because of a network issue. And we certainly *will* need more bandwidth for some future immersive experiences, especially for uplink video in mixed reality.

But recently I've come across a few examples of clever workarounds or hacks, that people in the network/telecom industry probably wouldn't have anticipated. They potentially reduce the opportunity for "monetised QoS", or reduce future network capacity or coverage requirements, by shifting the burden from traffic to something else.

The first example relates to the bandwidth needs for AR/VR/metaverse connectivity - although I first saw this mentioned in the context of videoconferencing a few years ago. It's called "foveated rendering". (The fovea is the most dense part of the eye's retina). In essence, it uses the in-built eye tracking in headsets or good quality cameras. The system know what part of a screen or virtual environment you are focusing on, and reduces the resolution or frame-rate of the other sections in your peripheral vision. Why waste compute or network capacity on large swathes of an image that you're not actually noticing?

I haven't seen many "metaverse bandwidth requirement" predictions take account of this. They all just count the pixels & frame rate and multiply up to the largest number - usually in the multi-Gbps range. Hey presto, a 6G use-case! But perhaps don't build your business case around it yet...

Network latency and jitter is another area where there are growing numbers of plausible workarounds. In theory, lots of applications such as gaming require low latency connections. But actually, they mostly require consistent and predictable but low-ish latency. A player needs to have a well-defined experience, and especially for multi-player games there needs to be fairness.

The gaming industry - and also other sectors including future metaverse apps - have created a suite of clever approaches to dealing with network issues, as well as more fundamental problems where some players are remote and there are hard speed-of-light constraints. They can monitor latency, and actually adjust and balance the lags experienced by participants, even if it means slowing some participants.

There are also numerous techniques for predicting or anticipating movements and actions, so network-delivered data might not be needed continually. AI software can basically "fill in the gaps", and even compensate for some sorts of errors if needed. Similar concepts are used for "packet loss concealment" in VoIP or video transmissions. Apps can even subtly speed up or slow down streams to allow people to "catch up" with each other, or have the same latency even when distributed across the world.

We can expect much more of this type of software-based mitigation of network flaws in future. We may even get to the point where sending full video/image data is unnecessary - maybe we just store a high-quality 3D image of someone's face and room (with lighting) and just send a few bytes describing what's happening. "Dean turned his head left by 23degrees, adopted a sarcastic expression and said 'who needs QoS and gigabit anyway?' A cloud outside the window cast a dramatic shadow half a second later". It's essentially a more sophisticated version of Siri + Instagram filters + ChatGPT. (Yes, I know I'm massively oversimplyifying, but you get the direction of travel here).

The last example is a bit more left-field. I did some work last year on wireless passenger connectivity on trains. There's a huge amount of complexity and technical effort being done on dedicated trackside wireless networks, improving MNO 5G coverage along railways, on-train repeaters for better signal and passenger Wi-Fi using multi-SIM (or even satellite) gateways. None of these are easy or cheap - the reality is that there will be a mix of dedicated and public network connectivity, with cities and rural areas getting different performance, and each generation of train having different systems. Worse, the coated windows of many new trains, needed for anti-glare and insulation, effectively act as Faraday cages, blocking outdoor/indoor wireless signals.

It's really hard to take existing rolling-stock out of service for complex retrofits, install anything along operational tracks / inside tunnels, and anything electronic like repeaters or new access points need a huge set of certifications and installation procedures.

So I was really surprised when I went to the TrainComms conference last year and heard three big train operators say they were looking at a new way to improve wireless performance for their passengers. Basically, someone very clever realised that it's possible to laser-etch the windows with a fine grid of lines - which makes them more transparent to 4G/5G, without changing the thermal or visual properties very much. And that can be done much more quickly and easily for in-service trains, one window at a time.

I have to say, I wasn't expecting a network QoS vs. Glazing Technology battle, and I suspect few others did either.

The story here is that while network upgrades and QoS are important, there are often highly inventive workarounds - and very motivated software, hardware and materials-science specialists hoping to solve the same problems via a different path.

Do you think a metaverse app developer would rather work on a cool "foveated rendering" approach, or deal with 800 sets of network APIs and telco lawyers to obtain QoS contracts instead? And how many team-building exercises just involve hiring a high-quality boat to go across a lake, rather than working out how to build rafts from barrels and planks?

We'll certainly need faster, more reliable, lower-latency networks. But we need to be aware that they're not the only source of solutions, and that payments and revenue uplift for network performance and QoS are not pre-ordained.


#QoS #Networks #Regulation #NetNeutrality #5G #FTTX #metaverse #videoconferencing #networkslicing #6G

Thursday, July 14, 2022

Network Slicing is a huge error for the 5G industry

(Initially posted on LinkedIn, here. Probably best to use LI for comments & discussion)

I've started calling myself a "Slice Denier" or "Slicing Skeptic" on client calls and conference speeches on #5G.

Increasingly, I believe that #NetworkSlicing is one of the worst strategic errors made by the #mobile industry, since the catastrophic choice of IMS for communications applications. The latter has led to the fiascos of #VoLTE and #RCS, and loss of relevance of telcos in communications more broadly.

At best, slicing is an internal toolset that might allow telco operations or product teams (or their vendors) to manage their network resources. For instance, it could be used to separate part of a cell's capacity for FWA, and dynamically adjust that according to demand. It might be used as an "ingredient" to create a higher class of service for enterprise customers, for instance for trucks on a highway, or as part of an "IoT service" sold by MNOs. Public safety users might have an expensive, artisanal "hand-carved" slice which is almost a separate network. Maybe next-gen MVNOs.

(I'm talking proper 3GPP slicing here - not rebranded QoS QCI classes, private APNs, or something that looks like a VLAN, which will probably get marketed as "slices")

But the idea that slicing is itself a *product*, or that application developers or enterprises will "buy a slice" is delusional.

Firstly, slices will be dependent on [good] coverage and network control. A URLLC slice likely won't work reliably indoors, underground, in remote areas, on a train, on a neutral-host network, or while roaming. This has been a basic failure of every differentiated-QoS monetisation concept for many years, and 5G's often-higher frequencies make it worse, not better.

Secondly, there is no mature machinery for buying, selling, testing, supporting. price, monitoring slices. No, the 5G Network Exposure Function won't do it all. I haven't met a Slice salesperson yet, or a Slice-procurement team.

Thirdly, a "local slice" of a national 5G network will run headlong into a battle with the desire for separate private/dedicated local 5G networks, which may well be cheaper and easier. It also won't work well with the enterprise's IT/OT/IP domains, out of the box.

Also there's many challenges getting multi-operator slices, device OS links to slice APIs, slice "boundary controllers" between operators, aligning RAN and core slices, regulatory questionmarks and much more.

To use an appropriate analogy, consider an actual toaster, with settings for different timing, or a setting for bagels. Now imagine Toaster 5.0 with extra software smarts, perhaps cloud-native. Nobody wants to buy a single slice of toast, or a software profile. They'll just buy a toaster for their kitchen, or or get an "integrated breakfast solution" including toast in a cafe. They won't care about the slicing software. The chef might, but it's doubtful.

If you see 5G Network Slicing as a centrepiece of future "monetisation", you're in for an unpleasant smell of burning, and probably a blaring smoke alarm too.


 

Tuesday, September 15, 2020

Low-latency and 5G URLLC - A naked emperor?

Originally published as a LinkedIn Newsletter Article - see here

I think the low-latency 5G Emperor is almost naked. Not completely starkers, but certainly wearing some unflattering Speedos.

Much of the promise around the 5G – and especially the “ultra-reliable low-latency” URLLC versions of the technology – centres on minimising network round-trip times, for demanding applications and new classes of device.


 

Edge-computing architectures like MEC also often focus on latency as a key reason for adopting regional computing facilities - or even servers at the cell-tower. Similar justifications are being made for LEO satellite constellations.

The famous goal of 1 millisecond time is often mentioned, usually in the context of applications like autonomous vehicles with snappy responses, AR/VR headsets without nausea, cloud-gaming, the “tactile Internet” and remote drone/robot control.

(In theory this is for end-to-end "user plane latency" between the user and server, so includes both the "over the air" radio and the backhaul / core network parts of the system. This is also different to a "roundtrip", which is there-and-back time).

Usually, that 1ms objective is accompanied by some irrelevant and inaccurate mention of 20 or 50 billion connected devices by [date X], and perhaps some spurious calculation of trillions of dollars of (claimed) IoT-enabled value. Gaming usually gets a mention too.

I think there are two main problems here:

  • Supply: It’s not clear that most 5G networks and edge-compute will be able to deliver 1ms – or even 10ms – especially over wide areas, or for high-throughput data.
  • Demand: It’s also not clear there’s huge value & demand for 1ms latency, even where it can be delivered. In particular, it’s not obvious that URLLC applications and services can “move the needle” for public MNOs’ revenues.

Supply

Delivering URLLC requires more than just “network slicing” and a programmable core network with a “slicing function”, plus a nearby edge compute node for application-hosting and data processing, whether that in the 5G network (MEC or AWS Wavelength) or some sort of local cloud node like AWS Outpost. That low-latency slice needs to span the core, the transport network and critically, the radio.

Most people I speak to in the industry look through the lens of the core network slicing or the edge – and perhaps IT systems supporting the 5G infrastructure. There is also sometimes more focus on the UR part than the LL, which actually have different enablers.

Unfortunately, it looks to me as though the core/edge is writing low-latency checks that the radio can’t necessarily cash.

Without going into the abstruse nature of radio channels and frame-structure, it’s enough to note that ultra-low latency means the radio can’t wait to bundle a lot of incoming data into a packet, and then get involved in to-and-fro negotiations with the scheduling system over when to send it.

Instead, it needs to have specific (and ideally short) timed slots in which to transmit/receive low-latency data. This means that it either needs to have lots of capacity reserved as overhead, or the scheduler has to de-prioritise “ordinary” traffic to give “pre-emption” rights to the URLLC loads. Look for terms like Transmission Time Interval (TTI) and grant-free UL transmission to drill into this in more detail.

It’s far from clear that on busy networks, with lots of smartphone or “ordinary” 5G traffic, there can always be a comfortable coexistence of MBB data and more-demanding URLLC. If one user gets their 1ms latency, is it worth disrupting 10 – or 100 – users using their normal applications? That will depend on pricing, as well as other factors.

This gets even harder where the spectrum used is a TDD (time-division duplexing) band, where there’s also another timeslot allocation used for separating up- and down-stream data. It’s a bit easier in FDD (frequency-division) bands, where up- and down-link traffic each gets a dedicated chunk of spectrum, rather than sharing it.

There’s another radio problem here as well – spectrum license terms, especially where bands are shared in some fashion with other technologies and users. For instance, the main “pioneer” band for 5G in much of the world is 3.4-3.8GHz (which is TDD). But current rules – in Europe, and perhaps elsewhere - essentially prohibit the types of frame-structure that would enable URLLC services in that band. We might get to 20ms, or maybe even 10-15ms if everything else stacks up. But 1ms is off the table, unless the regulations change. And of course, by that time the band will be full of smartphone users using lots of ordinary traffic. There maybe some Net Neutrality issues around slicing, too.

There's a lot of good discussion - some very technical - on this recent post and comment thread of mine: https://www.linkedin.com/posts/deanbubley_5g-urllc-activity-6711235588730703872-1BVn

Various mmWave bands, however, have enough capacity to be able to cope with URLLC more readily. But as we already know, mmWave cells also have very short range – perhaps just 200 metres or so. We can forget about nationwide – or even full citywide – coverage. And outdoor-to-indoor coverage won’t work either. And if an indoor network is deployed by a 3rd party such as neutral host or roaming partner, it's far from clear that URLLC can work across the boundary.

Sub-1GHz bands, such as 700MHz in Europe, or perhaps refarmed 3G/4G FDD bands such as 1.8GHz, might support URLLC and have decent range/indoor reach. But they’ll have limited capacity, so again coexistence with MBB could be a problem, as MNOs will also want their normal mobile service to work (at scale) indoors and in rural areas too.

What this means is that we will probably get (for the forseeable future):

  • Moderately Low Latency on wide-area public 5G Networks (perhaps 10-20ms), although where network coverage forces a drop back to 4G, then 30-50ms.
  • Ultra* Low Latency on localised private/enterprise 5G Networks and certain public hotspots (perhaps 5-10ms in 2021-22, then eventually 1-3ms maybe around 2023-24, with Release 17, which also supports deterministic "Time Sensitive Networking" in devices)
  • A promised 2ms on Wi-Fi6E, when it gets access to big chunks of 6GHz spectrum

This really isn't ideal for all the sci-fi low-latency scenarios I hear around drones, AR games, or the cliched surgeon performing a remote operation while lying on a beach. (There's that Speedo reference, again).

* see the demand section below on whether 1-10ms is really "ultra-low" or just "very low" latency

Demand

Almost 3 years ago, I wrote an earlier article on latency (link), some of which I'll repeat here. The bottom line is that it's not clear that there's a huge range of applications and IoT devices that URLLC will help, and where they do exist they're usually very localised and more likely to use private networks rather than public.

One paragraph I wrote stands out:

I have not seen any analysis that tries to divide the billions of devices, or trillions of dollars, into different cohorts of time-sensitivity. Given the assumptions underpinning a lot of 5G business cases, I’d suggest that this type of work is crucial. Some of these use-cases are slow enough that sending data by 2G is fine (or by mail, in some cases!). Others are so fast they’ll need fibre – or compute capability located locally on-device, or even on-chip, rather than in the cloud, even if it’s an “edge” node.

I still haven't seen any examples of that analysis. So I've tried to do a first pass myself, albeit using subjective judgement rather than hard data*. I've put together what I believe is the first attempted "heatmap" for latency value. It includes both general cloud-compute and IoT, both of which are targeted by 5G and various forms of edge compute. (*get in touch if you'd like to commission me to do a formal project on this)

A lot of the IoT examples I hear about are either long time-series collections of sensor data (for asset performance-management and predictive maintenance), or have fairly loose timing constraints. A farm’s moisture sensors and irrigation pumps don’t need millisecond response times. Conversely, a chemical plant may need to alter measure and alter pressures or flows in microseconds.

I've looked at time-ranges for latency from microseconds to days, spanning 12 orders of magnitude (see later section for more examples). As I discuss below, not everything hinges on the most-mentioned 1-100 millisecond range, or the 3-30ms subset of that that 5G addresses.

I've then compared those latency "buckets" with distances from 1m to 1000km - 7 orders of magnitude. I could have gone out to geostationary satellites, and down to chip scales, but I'll leave that exercise to the reader.

  

The question for me is - are the three or four "battleground" blocks really that valuable? Is the 2-dimensional Goldilocks zone of not-too-distant / not-too-close and not-too-short / not-too long, really that much of a big deal?

And that's without considering the third dimension of throughput rate. It's one thing having a low-latency "stop the robot now!" message, but quite another doing hyper-realistic AR video for a remote-controlled drone or a long session of "tactile Internet" haptics for a game, played indoors at the edge of a cell.

If you take all those $trillions that people seem to believe are 5G-addressable, what % lies in those areas of the chart? And what are the sensitivities to to coverage and pricing, and what substitute risks apply - especially private networks rather than MNO-delivered "slices" that don't even exist yet?

Examples

Here are some more examples of timing needs for a selection of applications and devices. Yes, we can argue some of them, but that's not the point - it's that this supposed magic range of 1-100 milliseconds is not obviously the source of most "industry transformation" or consumer 5G value:

  • Sensors on an elevator doors may send sporadic data, to predict slowly-worsening mechanical problems – so an engineer might be sent a month before the normal maintenance visit. Similarly, sensors monitoring a building’s structural condition, vegetation cover in the Amazon, or oceanic acidity isn’t going to shift much month-by-month.
  • A car might download new engine-management software once a week, and upload traffic observations and engine-performance data once a day (maybe waiting to do it over WiFi, in the owner’s garage, as it's not time-critical).
  • A large oil storage tank, or a water well, might have a depth-gauge giving readings once an hour.
  • A temperature sensor and thermostat in an elderly person’s home, to manage health and welfare, might track readings and respond with control messages every 10 minutes. Room temperatures change only slowly.
  • A shared bicycle might report its position every minute – and unlock in under 10 seconds when the user buys access with their smartphone app
  • A payment or security-access tag should check identity and open a door, or confirm a transaction, in a second or two.
  • Voice communication seems laggy with anything longer than 200 millisecond latency.
  • A networked video-surveillance system may need to send a facial image, and get a response in 100ms, before the person of interest moves out of camera-shot.
  • An online video-game ISP connection will be considered “low ping” at maybe 50ms latency.
  • A doctor’s endoscope or microsurgery tool might need to respond to controls (and send haptic feedback) 100 times a second – ie every 10ms
  • Teleprotection systems for high-voltage utility grids can demand 6-10ms latency times
  • A rapidly-moving drone may need to react in 2-3 millisecond to a control signal, or a locally-recognised risk.
  • A sensitive industrial process-control system may need to be able to respond in 10s or 100s of microseconds to avoid damage to finely-calibrated machinery
  • Image sensors and various network sync mechanisms may require response times measured in nanoseconds
  • Photon sensors for various scientific uses may operate at picosecond durations
  • Ultra-fast laser pulses for machining glass or polymers can be measured in femtoseconds

Conclusion

Latency is important, for application developers, enterprises and many classes of IoT device and solution. But we have been spectacularly vague at defining what "low-latency" actually means, and where it's needed.

A lot of what gets discussed in 5G and edge-computing conferences, webinars and marketing documents is either hyped, or is likely to remain undeliverable. A lot of the use-cases can be adequately serviced with 4G mobile, Wi-Fi - or a person on a bicycle delivering a USB memory stick.

What is likely is that average latencies will fall with 5G. An app developer that currently expects a 30-70ms latency on 4G (or probably lower on Wi-Fi) will gradually adapt to 20-40ms on mostly-5G networks and eventually 10-30ms. If it's a smartphone app, they likely won't use URLLC anyway.

Specialised IoT developers in industrial settings will work with specialist providers (maybe MNOs, maybe fully-private networks and automation/integration firms) to hit more challenging targets, where ROI or safety constraints justify the cost. They may get to 1-3ms at some point in the medium term, but it's far from clear they will be contributing massively to MNOs or edge-providers' bottom lines.

As for wide-area URLLC? Haptic gaming from the sofa on 5G, at the edge of the cell? Remote-controlled drones with UHD cameras? Two cars approaching each other on a hill-crest on a country road? That's going to be a challenge for both demand and supply.

Saturday, August 08, 2020

A rant about 5G myths - chasing unicorns​

Exasperated rant & myth-busting time.

I actually got asked by a non-tech journalist recently "will 5G change our lives?"

Quick answer: No. Emphatically No.


#5G is Just Another G. It's not a unicorn

Yes, 5G is an important upgrade. But it's also *massively* overhyped by the mobile industry, by technology vendors, by some in government, and by many business and technology journalists.

- There is no "race to 5G". That's meaningless geopolitical waffle. Network operators are commercial organisations and will deploy networks when they see a viable market, or get cajoled into it by the terms & timing of spectrum licenses.

- Current 5G is like 4G, but faster & with extra capacity. Useful, but not world-changing.

- Future 5G will mean better industrial systems and certain other cool (but niche) use-cases.

- Most 5G networks will be very patchy, without ubiquitous coverage, except for very rudimentary performance. That means 5G-only applications will be rare - developers will have to assume 4G fallback (& WiFi) are common, and that dead-spots still exist.

- Lots of things get called 5G, but actually aren't 5G. It's become a sort of meaningless buzzword for "cool new wireless stuff", often by people who couldn't describe the difference between 5G, 4G or a pigeon carrying a message.

- Anyone who talks about 5G being essential for autonomous cars or remote surgery is clueless. 5G might get used in connected vehicles (self-driving or otherwise) if it's available and cheap, but it won't be essential - not least as it won't work everywhere (see above).

- Yes, there will be a bit more fixed wireless FWA broadband with 5G. But no, it's not replacing fibre or cable for normal users, especially in competitive urban markets. It'll help take FWA from 5% to 10-12% of global home broadband lines.

- The fact the 5G core is "a cloud-native service based architecture" doesn't make it world-changing. It's like raving about a software-defined heating element for your toaster. Fantastic for internal flexibility. But we expect that of anything new, really. It doesn't magically turn a mobile network into a "platform". Nor does it mean it's not Just Another G.

- No, enterprises are not going to "buy a network slice". The amount of #SliceWash I'm hearing is astonishing. It's a way to create some rudimentary virtualised sub-networks in 5G, but it's not a magic configurator for 100s or 1000s of fine-grained, dynamically-adjusted different permutations all coexisting in harmony. The delusional vision is very far removed from the mundane reality.

- The more interesting stuff in 5G happens in Phase 2/3, when 3GPP Release 16 & then Release 17 are complete, commercialised & common. R16 has just been finalised. From 2023-4 onward we should expect some more massmarket cool stuff, especially for industrial use. Assuming the economy recovers by then, that is.

- Ultra-reliable low-latency communications (URLLC) sounds great, but it's unclear there's a business case except at very localised levels, mostly for private networks. Actually, UR and LL are two separate things anyway. MNOs aren't going to be able sell reliability unless they also take legal *liability* if things go wrong. If the robot's network goes down and it injures a worker, is the telco CEO going to take the rap in court?

- Getting high-performance 5G working indoors will be very hard, need dedicated systems, and will take lots of time, money and trained engineers. It'll be a decade or longer before it's very common in public buildings - especially if it has to support mmWave and URLLC. Most things like AR/VR will just use Wi-Fi. Enterprises may deploy 5G in factories or airport hangars or mines - but will engineer it very carefully, examine the ROI - and possibly work with a specialist provider rather than a telco.

- #mmWave 5G is even more overhyped than most aspects. Yes, there's tons of spectrum and in certain circumstances it'll have huge speed and capacity. But it's go short range and needs line-of-sight. Outdoor-to-indoor coverage will be near zero. Having your back to a cell-site won't help. It will struggle to go through double-glazed windows, the shell of a car or train, and maybe even your bag or pocket. Extenders & repeaters will help, but it's going to be exceptionally patchy (and need tons of fibre everywhere for backhaul).

- 5G + #edgecomputing is a not going to be a big deal. If low-latency connections were that important, we'd have had localised *fixed* edge computing a decade ago, as most important enterprise sites connect with fibre. There's almost no FEC, so MEC seems implausible except for niches. And even there, not much will happen until there's edge federation & interconnect in place. Also, most smartphone-type devices will connect to someone else's WiFi between 50-80% of the time, and may have a VPN which means the network "egress" is a long way from the obvious geographically-proximal edge.

- Yes, enterprise is more important in 5G. But only for certain uses. A lot can be done with 4G. "Verticals" is a meaningless term; think about applications.

- No, it won't displace Wi-Fi. Obviously. I've been through this multiple times.

- No, all laptops won't have 5G. (As with 3G and 4G. Same arguments).

- No, 5G won't singlehandedly contribute $trillions to GDP. It's a less-important innovation area than many other things, such as AI, biotech, cloud, solar and probably quantum computing and nuclear fusion. So unless you think all of those will generate 10's or 100's of $trillions, you've got the zeros wrong.

- No, 5G won't fry your brain, or kill birds, or give you a virus. Conspiracy theorists are as bad as the hypesters. 5G is neither Devil nor Deity. It's just an important, but ultimately rather boring, upgrade.

There's probably a ton more 5G fallacies I've forgotten, and I might edit this with a few extra ones if they occur to me. Feel free to post comments here, although the majority of debate is on my LinkedIn version of this post (here). This is also the inaugural post for a new LinkedIn newsletter, Most of my stuff is not quite this snarky, but it depends on my mood. I'm @disruptivedean on Twitter so follow me there too.

If you like my work, and either need a (more sober) business advisory session or workshop, let me know. I'm also a frequent speaker, panellist and moderator for real and virtual events.

Just remember: #5GJAG. Just Another G.

Monday, September 23, 2019

Is there a potential market for 5G or other connectivity insurance policies?

[Reposted & slightly extended from my LinkedIn post here - see that page for some really good discussion in the comments]

This is a completely speculative post, on an area I’ll happily admit I know little about. It might be complete nonsense, or it could be a billion-dollar idea. Or it could be trivial & exist already with a different name. 

So: What happens if you blend radio spectrum policy & licenses, and 5G or WiFi networks, with the insurance industry? 

Is there a potential market for insuring radio networks against failures (interference, coverage gaps, latency etc), especially in enterprise environments? 

Or insurance against interfering with others' networks in shared spectrum like CBRS? (Sort of like radio liability insurance)

At the moment there is huge wariness by conventional operators or vendors in offering full SLAs, especially in mission-critical environments. Understandably, on the other hand very few users or developers will want to risk their mission critical (or possibly safety-critical) applications on networks that could fail. They're certainly not likely to pay much extra for a "slice" or QoS guarantee that has no penalties for failure.

Few existing incumbent spectrum-holders will be willing to share their bands, without governments forcing them to, either. Could a C-Band satellite operate be satisfied that their links would be interference-free, if mobile networks were allowed partial access to the band?

Insurance could offset some of these risks - although it would likely need more data and better measurement in order to calculate premiums.

Regulators typically focus on worst-case scenarios, rather than probabalistic ones. Insurance could put a price on problems, and enable more efficient use of spectrum resources. 

The insurance industry is good at modelling risks, and costs of various types of failure or problem. As well as familiar forms of insurance that pay for a replacement car or house if damage is incurred, some pay out based on specific measurable parameters, such as wind-speeds of a certain strength in a given place. This is called "parametric insurance" -
well-explained here by Swiss Re ("The key criteria for an insurable trigger is that it is fortuitous and it can be modelled”) or in this article.


This could be a huge & beneficial area, if my gut feeling is correct. It's not easy - and various of the LinkedIn comments highlight complexities and problems. But it seems to me that there could be something here, at least in situations where network coverage/performance can be both modelled and measured. There are various other intersections & use-cases I can think of too. 

Comments welcome! 

(Also: a hat-tip to Richard Womersley of LSTelcom, who I discussed this with briefly about 18 months ago).

Tuesday, November 27, 2018

Does the network need a "black box" as well as user data-retention?

What is the network equivalent of an aircraft's black-box? Is there an argument for governments pushing for more regulation on telco-side data-retention?

As far as I know, telcos are not under any obligation to maintain full logs of the state/operation of their network elements, either hardware or software – or make them available for authorities to inspect. As networks become more virtualised and complex, with NFV, orchestration, AI-led automation of network policies, slicing and so on, what happens if something goes seriously wrong? 

The industry is hoping that 5G and other networks will be used in safety-critical verticals, with "ultra-reliable" requirements, but that brings risks and responsibilities too.
That could mean authorities may need to do a diagnostic “post-mortem” if a network fails - or perhaps as a way to spot if the network is doing something it shouldn’t, such as discrimination in wholesale, or net neutrality violations.

Aviation has rigorous rules about flight data recorders (“black boxes”), and has an admirable record of learning lessons from catastrophe, and changing inspection and certification regimes, if needed. Air travel is a one-way ratchet, becoming ever-safer, because of this.

So, if a commercial 5G or FTTX network is being used for ultra-reliable uses (such as managing a power grid’s control, or a telemedicine app, or perhaps connected vehicles), is there a basis for countries having a “Network Accident Investigation Board” and better international cooperation? And would this not also imply a better way to store crucial background data is required? If a plane crashes, investigators can examine the physical wreckage, but this problem is much harder for software-controlled networks with no moving parts.

This is also an issue if a network gets compromised by hacking or a bug - who is responsible, how can it be fixed, and what prevents re-occurrence? And something similar applies for keeping records that may prove/disprove competition problems, eg did a virtualised network resource do something illegal, perhaps on a temporary basis? How could a complaint be investigated, or a prosecution brought?

The problems get multiplied massively if AI is involved, as any issues with underlying machine-learning algorithms are potentially a single point of failure, if that system is used widely (eg for coordinating 100’s or 1000’s of network-slices in an automated fashion).

Do regulators have the legal rights, obligation or ability to forensically analyse what’s gone wrong in such situations? Or the various cybersecurity agencies, or police forces?

One option might be to encrypt network configuration and operational logs, and keep them “in escrow” using blockchain to ensure anti-tamper properties, so that they could only be examined after a warrant or other legal instrument ordered decryption. There are likely numerous other technical approaches to consider as well.

In either case, as public networks become part of critical systems, this topic will only rise in importance. Policymakers should start thinking about it now - and the telecoms industry should face up to its responsibilities here, rather than push back without thinking. Do Boeing or Airbus complain about the need for data recorders?

Monday, December 04, 2017

5G & IoT? We need to talk about latency



Much of the discussion around the rationale for 5G – and especially the so-called “ultra-reliable” high QoS versions – centres on minimising network latency. Edge-computing architectures like MEC also focus on this. The worthy goal of 1 millisecond roundtrip time is often mentioned, usually in the context of applications like autonomous vehicles with snappy responses, AR/VR headsets without nausea, the “tactile Internet” and remote drone/robot control.

Usually, that is accompanied by some mention of 20 or 50 billion connected devices by [date X], and perhaps trillions of dollars of IoT-enabled value.

In many ways, this is irrelevant at best, and duplicitous and misleading at worst.

IoT devices and applications will likely span 10 or more orders of magnitude for latency, not just the two between 1-10ms and 10-100ms. Often, the main value of IoT comes from changes over long periods, not realtime control or telemetry.

Think about timescales a bit more deeply:

  • Sensors on an elevator doors may send sporadic data, to predict slowly-worsening mechanical problems – so an engineer might be sent a month before the normal maintenance visit.
  • A car might download new engine-management software once a week, and upload traffic observations and engine-performance data once a day (maybe waiting to do it over WiFi, in the owner’s garage, as it's not time-critical).
  • A large oil storage tank, or a water well, might have a depth-gauge giving readings once an hour.
  • A temperature sensor and thermostat in an elderly person’s home, to manage health and welfare, might track readings and respond with control messages every 10 minutes. Room temperatures change only slowly.
  • A shared bicycle might report its position every minute – and unlock in under 10 seconds when the user buys access with their smartphone app
  • A payment or security-access tag should check identity and open a door, or confirm a transaction, in a second or two.
  • A networked video-surveillance system may need to send a facial image, and get a response in a tenth of a second, before they move out of camera-shot.
  • A doctor’s endoscope or microsurgery tool might need to respond to controls (and send haptic feedback) 100 times a second – ie every 10ms
  • A rapidly-moving drone may need to react in a millisecond to a control signal, or a locally-recognised risk.
  • A sensitive industrial process-control system may need to be able to respond in 10s or 100s of microseconds to avoid damage to finely-calibrated machinery
  • Image sensors and various network sync mechanisms may require response times measured in nanoseconds
I have not seen any analysis that tries to divide the billions of devices, or trillions of dollars, into these very-different cohorts of time-sensitivity. Given the assumptions underpinning a lot of 5G business cases, I’d suggest that this type of work is crucial. Some of these use-cases are slow enough that sending data by 2G is fine (or by mail, in some cases!). Others are so fast they’ll need fibre – or compute capability located locally on-device, or even on-chip, rather than in the cloud, even if it’s an “edge” node.

I suspect (this is a wild guess, I'll admit) that the proportion of IoT devices, for which there’s a real difference between 1ms and 10ms and 100ms, will be less than 10%, and possibly less than 1% of the total. 

(Separately, the network access performance might be swamped by extra latency added by security functions, or edge-computing nodes being bypassed by VPN tunnels)

The proportion of accrued value may be similarly low. A lot of the IoT examples I hear about are either long time-series collections of sensor data (for asset performance-management and predictive maintenance), or have fairly loose timing constraints. A farm’s moisture sensors and irrigation pumps don’t need millisecond response times. Conversely, a chemical plant may need to alter measure and alter pressures or flows in microseconds.

Are we focusing 5G too much on the occasional Goldilocks of not-too-fast and not-too-slow?