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 M2M. Show all posts
Showing posts with label M2M. Show all posts

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?

Tuesday, July 11, 2017

Sensors: implications for wireless connectivity & video communications

Quick summary
  • Sensor technology is complex, diverse, fascinating & fast-evolving.
  • There are dozens of sensor types & technologies.
  • Nobody believes the 20-50bn devices forecasts, especially if they are based on assumptions that 1 sensor = 1 device
  • Some sensors improve the capabilities of already-connected devices, like phones or (increasingly) cars.
  • Some sensors enable creation of new forms of connected device & application.
  • Most sensors connect first via one or two tiers of local gateways, sub-systems or controllers, rather than directly connect to the Internet / cloud individually
  • While the amount of sensor-generated data is growing hugely, not all of this needs real-time collection and analysis, and so network needs are less-extreme.
  • Many industrial sensors use niche or unfamiliar forms of connectivity.
  • Genuine real-time controls often need sensors linked to "closed-loop" systems, rather than using Internet connections / cloud.
  • WiFi & short-range wireless technologies like Bluetooth & ZigBee are growing in importance. There is limited concern about using unlicensed spectrum
  • LoRa radios (sometimes but not always with LoRaWAN protocols) are growing in importance rapidly
  • Cellular connectivity is important for certain (especially standalone, remote/mobile & costly) sensor types, or sensor-rich complex objects like vehicles. 
  • The US seems more keen on LTE Cat-1 / Cat-M than NB-IoT for sensor-based standalone devices. Europe and Asia seem more oriented towards NB-IoT
  • There are no obvious & practical sensor use-cases that need 5G, but it will likely improve the performance / economics / reach of some 4G applications.
  • Camera / image sensors are becoming hugely important and diverse. These are increasingly linked to either AI systems (machine vision) or new forms of IoT-linked communication applications
  • "Ordinary" video sensors/modules are being supplemented by 3D, depth-sensing, emotion-sensing, 360degs, infra-red, microscopy and other next-gen capabilities.
  • AI and analytics will sometimes be performed on the sensor or controller/gateway itself, and sometimes in the cloud. This may reduce the need for realtime data transmission, but increase the need for batch transfer of larger files.
  • Conclusion: sensors are central to IoT and evolving fast, but the impact on network connectivity - especially new cellular 4G and 5G variants - is diffuse and non-linear.

Narrative
 
A couple of weeks ago I went to Sensors Expo 2017 in San Jose. This topic is slightly outside my normal beat, but fits with my ongoing interest in "telcofuturism", especially around the intersection of IoT, networks and AI. It also dovetails well with recent writing I've done on edge computing (link & link), a webinar [this week] and paper on IoT+video for client Dialogic (link), and an upcoming report I'll be writing on LPWAN for my Future of the Network research stream at STL Partners (link).

First things first: listening to some of the conference speeches, and then walking around the show floor, made me realise just how little I actually knew about sensors, and how they fit into the rest of the IoT industry. I suspect a lot of people in telecoms - or more broadly in wireless networking and equipment - don't really understand the space that well either.

For a start, there's a bewildering array of sensor types and technologies - from tiny silicon accelerometers that can be built into a chip (based on MEMS - micro-electromechanical systems), right up to sensors woven into large-scale fabrics, that can be used to make tarpaulins or tents which know when someone tries to cut them. There's all manner of detectors for gases, proximity, light, pressure, force, airflow, air quality, humidity, torque, electrical current, vibration, magnetic fields, temperature, distance, and so forth.

Secondly, a lot of sensors have historically been part of "closed-loop" systems, without much in the way of "fully-connected" computing, permanent data collection, networking, cloud platforms or analysis. 

An easy example to think about is an old-fashioned thermostat for a heating system. It senses temperature - and switches a boiler or radiator on or off accordingly - without "compute" or networking resource. This has been reinvented by Nest and others. Plenty of other sensors just interact with "real-time" systems - for example older cars' airbags, or motion-detection alarms which switch on lights.

In industry, a lot of sensors hook into the "real-time control" systems, whether that's for industrial production machinery, quality control, aircraft avionics or whatever. These often use fixed connectivity, with a bewildering array of network and interface types. It's not just TCP/IP or familiar wireless technologies. If you haven't come across things like Modbus or Profibus, or terms like RS485 physical connections, you perhaps don't realise the huge complexity and unfamiliarity of some of these systems. This is not telco territory.

This is important, as it brings in an entire new realm to think about. From a telco perspective, we're comfortable talking about the touch-points of networks and IT. We are don't often talk about OT or "operational technology". A lot of people seem to naively believe that we can hook up a sensor or a robot or a piece of industrial machinery straight to a 4G/5G/WiFi connection, then via Internet or VPN to a cloud application to control it, and that's all there is to it. 

In fact, there may well be one, two or three layers of other technology involved first, notably PLC units (programmable logic controllers) as well as local gateways. A lot of this is the intranet-of-things, not the Internet-of-things - and may well not even be using IP as most people in networking and telecoms normally think about it.

In other words, there's a lot more optionality around ISO layers - there are a broad range of sector-specific or proporietary protocols, that control sensors or IoT devices over a particular "physical layer". That contrasts with most users' (and telco-world observers') day-to-day expectations of "IP everywhere" and using HTTP and TCP/IP and similar protocols over ethernet, WiFi, 4G or whatever. The sensor world is much more fragmented than that.

These are some of the specific themes I noted at the event:
  • Despite the protocol zoo I've discussed, WiFi is everywhere nonetheless. Pretty much all the sensor types have WiFi connectivity options somewhere, unless they're ultra-low power. There's quite a bit of Bluetooth and ZigBee / other varieties of IEEE 802.15.4 for short-range access too.
  • Almost nobody seems bothered about the vagaries of unlicensed spectrum, apart from a few seriously mission-critical, time-critical applications, in which case they'll probably use fixed connections if they can. Bear in mind that a lot of sensors are actually fairly time-insensitive so temporary interference or congestion doesn't matter much. Temperatures usually only change over seconds / minutes, not milliseconds, for example. Bear in mind though, that this is for sensing (ie gathering data) not actuating (doing stuff, eg controlling machines or robots).
  • Most sensors send small bursts of data - either at set intervals, or when something changes. There are exceptions (notably camera / image sensors)
  • I saw a fair amount of talk about 5G (and also 4G and NB-IoT) but comparatively little action. Unlike Europe, the US seems more interested in LTE Cat-1 and Cat-M rather than NB-IoT. Cat-M can support VoLTE, which makes it interesting for applications like elder/child-trackers, wearable and building security. NB-IoT seems fairly well-suited to things like parking meters, environmental sensors, energy metering etc. where each unit is comparatively standalone, and needs to link to cloud/external resources like payments.
  • There's also lot of interest in LoRa, both as a public network service (Senet was prominently involved), and also as privately-owned infrastructure. I think we're going to see a lot of private LoRa embedded into medium-area sensor networks. Imagine 100 moisture sensors for a farm, connected back to a central gateway on top of the barn, and then on to a wide-area connection (fixed or mobile) and a cloud-based application. The 100 sensors don't need a wireless "service" - they'll be owned by the farmer, or else perhaps the connectivity will be offered as a part of a broader "managed irrigation service" by the software company.
  • There's an interest in wireless connectivity to reduce regulatory burdens for some sensors. For example, to connect a temperature sensor in an area of an oil refinery with explosion risks, to a server in another building, requires all manner of paperwork and certification. The trenching, ducting and physical wire between them needs approval, inspection and so on. It's much simpler to do it with wireless transmitters and receivers.
  • A lot of the extra sensors getting connected are going to be bundled with existing sensors. Rather than just a vibration sensor, the unit might also include temperature and pressure sensors in integrated form. That probably adds quite a lot to the IoT billions number-count, without needing separate network links.
  • A lot of sensors will get built into already-connected objects. Cars and aircraft will continue to add cameras, material stress sensors, chemical analysis probes for exhaust gases, air/fluid flow sensors, battery sensors of numerous types, more accelerometers and so on. This means more data being collected, and perhaps more ways to justify always-on connections because of new use-cases - but it also means a greater need for onboard processing and "bulk" transfers of data in batches.
  • Safety considerations often come ahead of security, and a long way ahead of performance. A factory robot needs sensors to avoid killing humans first. Production quality, data for machine learning and efficiency come further down the list. That means that connecting devices and sensors via wider-range networks might make theoretical or economic sense - but it'll need to be seen through a safety lens (and often sector-specific regulation) first. Taking things away from realtime connections and control systems, into a non-deterministic IP or wireless domain, will need careful review.
  • Discussion of sensor security issues is multi-layer, and encouragingly pervasive. Plenty of discussions around data integrity, network protection, even device authenticity and counterfeiting.
  • Imaging sensors (cameras and variants of them) are rapidly proliferating in terms of both capabilities and reach into new device categories. 3D depth-sensing cameras are expected on phones soon, for example for facial recognition. 360-degree video is rapidly growing, for example with drones. Vehicles will use cameras not just for awareness of surrounding, but also to identify drivers or check for attentiveness and concentration. Rooms or public-spaces will use cameras to count occupancy numbers or footfall data. New video endpoints will link into UC and collaboration systems "Sensed video" will need greater network capacity in many instances. [I am doing a webinar with Dialogic about IoT+video on July 13th - sign up here: link]
  • Microphones are sensors too, and are also getting smarter and more capable. Expect future audio devices to be aware of directionality, correct for environmental issues such as wind noise, recognise audio events as triggers - and even do their own voice recognition in the sensor itself.
  • Textile and fabric sensors are really cool - anything from smart tarpaulins for trucks to stop theft, through to bandages which can measure moisture and temperature changes, to signal a need for medical attention. 
  • There's a lot of modularity being built into sensors - they can work with multiple different network types depending on the use-case, and evolve over time. A vibration sensor module might be configurable to ship with WiFi, BLE, LoRa, NB-IoT, ZigBee and various combinations. I spoke to Advantech and Murata and TE Connectivity, among others, who talked about this.
  • Not many people seemed to have thought about SIMs/eSIMs much, at a sensor level. The expectation is that they will be added by solution integrators, eg vehicle manufacturers or energy-meter suppliers, as needed.
  • AI will have a range of impacts both positive and negative from a connectivity standpoint. The need for collecting and pooling large volumes of data from sensors will increase the need for network transport... but conversely, smarter endpoints might process the data locally more effectively, with just occasional bulk uploads to help train a central system.
Overall - this has really helped to solidify some of my thinking about IoT, connectivity, the implications for LPWAN and also future 4G/5G coverage and spectrum requirements. I'd recommend readers in the mainstream telecom sector to drop in to any similar events for a day or two - it's a good way to frame your understanding of the broader IoT space and recognise that "sensors" are diverse and have varying impacts on network needs.

Wednesday, August 03, 2016

NEW: eSIM Status and Forecast report published

Beyond M2M: eSIM Status & Forecasts
Overcoming practical & economic issues for mid-term consumer-market eSIM adoption


Disruptive Analysis has published a 36-page report on the emerging technology of eSIM and SIM remote-provisioning. The focus is on the use-cases, practicalities, drivers and obstacles for bringing eSIM-based devices to market, alongside suitable mobile data plans or subscriptions.

The report addresses both the motivations (lower costs, higher revenues, better experience) and problems (business-case, user journey, regulation, transition) that will be experienced by operators (MNOs) and device vendors (OEMs).

Forecasts are given for annual shipments of eSIM-enabled devices (phones, wearables, M2M, tablets), and for the installed base that will be a target for after-market eSIM provisioning.

Key findings:
  • There are numerous use-cases for “remote provisioning” of SIMs with mobile operator “profiles”, especially where the SIM hardware is built-into devices
  • eSIM adoption will have a slow start. 2016-17 consumer deployment will mostly be early concepts, allowing MNOs and OEMs to gain practical eSIM experience and refine implementation and processes. eSIM phones will emerge very gradually.
  • Adoption should ramp up in 2019-2021 as cost, industry value-chain and user-experience problems are progressively solved.
  • Apple and Samsung are unlikely to use eSIM to become MVNOs / carriers. Neither will they aggressively push eSIM into their flagship products.
  • For many M2M/IoT devices, the eSIM decision is secondary to justifying the extra cost, space and power needs of the cellular radio itself. 
  • eSIM is "necessary but not sufficient" to drive adoption of cellular M2M. It is unlikely to change the competitive dynamics vs. LPWAN technologies like SigFox or LoRa.
  • There remain unanswered questions about regulation, customer-support and business model for eSIM. Although some projected cost-savings are attractive for operators, it is unclear that it will help OEMs generate extra revenues/loyalty. 
  • There will other approaches to remote provisioning beyond GSMA's vision of eSIM. Some OEMs may adopt proprietary versions, while standards-body ETSI is intending to develop specifications which go beyond just mobile use of chip-cards 
  • By 2021, 630m mobile & IoT devices will ship with embedded SIMs annually, driven mostly by smartphones, although vehicles and tablets show growth earlier.
  • By end-2021, the installed base of eSIM-enabled devices will exceed 1 billion 
  • While significant, this only represents around 10% of total cellular connections
In a nutshell: eSIM is an important evolution for some use-cases, but it is neither an outright "game-changer" nor a major risk to traditional cellular business models.


To purchase the report, see below



Report Contents

Executive Summary
Introduction & Outline
   The Potential
   What is eSIM / eUICC?
   New uses for eSIM & other programmable-SIM technologies
   A device-centric view of SIM provisioning             
   A growing variety of “SIM evolution” options
The Practicalities             
   Economics and demand
   SIM/eSIM irrelevant if radio module costs too high          
   Operational issues          
   User experience              
   Retail and channel management              
   Maintenance and lifecycle-management               
   Security               
   Transition issues: the need for hybrid SIM + eSIM devices             
   Regulatory considerations           
   Ecological considerations: fit with other telecoms trends
The Phones        
   Low-end vs. high-end phones
   Apple-specific considerations
   Conclusions and Forecasts          
   Forecasts            
About Disruptive Analysis            

Figure 1: Understanding the definition & semantics of “eSIM”     
Figure 2: Advantages of “programmability” vs. “embeddability” varies by device 
Figure 3: SIM evolution – multiple variants are emerging, not just GSMA eSIM     
Figure 4: SIM evolution – costs and key stakeholders       
Figure 5: Few handsets’ gross margins can sustain extra BoM cost from eSIM       
Table 6: Forecast eSIM shipments, by device category, 2016-2021             
Figure 7: eSIM shipments, by device category, 2016-2021             
Figure 8: eSIM device shipments, hybrid SIM/eSIM vs. eSIM-only
Table 9: eSIM active installed base, by device category, 2016-2021           
Figure 10: eSIM installed base, by device category, 2016-2021     
Figure 11: Overall SIM & eSIM active installed base, end-2021     
 

Ordering & payment


The report (delivered as a PDF) costs:
  • US$900 for a 1-3 user licence
  • US$1500 for a corporate-wide licence + a free 1-hour conference-call discussion
  • (plus VAT in UK/EU as appropriate)

Payment is via credit-card and Paypal (see below), or where a purchase-order and invoicing details are submitted by email to information at disruptive-analysis dot com. The report will be emailed to you within 24 hours of receipt of payment.

[Note: Sometimes Paypal's credit-card transaction process is a little variable, especially with corporate cards. Please drop me an email if you have problems]

eSIM Report, 1-3 users




eSIM Report, Corporate