"Essentiality" and IoT - Guest Post by Graham Bell

I first met Graham Bell during the Innovatio MDL litigation.[1]  Innovatio IP Ventures, LLC (Innovatio) had acquired patents from Broadcom Corporation (“Broadcom”) that, during the Innovatio litigation, were found to be essential to the Wi-Fi standard.  Innovatio sent thousands of letters to small businesses and mom and pop shops alleging that their use of Wi-Fi infringed those patents.  Innovatio demanded as much as $2,500 per location to use Wi-Fi and to provide (usually free) Wi-Fi to customers of these small businesses.  Innovatio also filed numerous lawsuits against coffee companies, restaurant chains, supermarkets and hotels alleging infringement through their use of Wi-Fi. 

At that time, I was in-house counsel at Cisco Systems, Inc. (“Cisco). Cisco received hundreds of inquiries from customers because of Innovatio’s litigation and licensing campaign.  So, in 2011, Cisco filed a declaratory judgment action against Innovatio.  Cisco was not alone in doing so—a number of other Wi-Fi implementers, including Motorola Solutions, Inc., SonicWALL, Inc., Netgear, Inc., and Hewlett-Packard Co., also filed declaratory judgement actions. 

This was in the early days of SEP litigation.[2]  There was not much guidance from the courts about how to properly value RAND committed SEPs.  We had some ideas about how to do the valuation but we did not have enough information to do the type of analysis we wanted to do.[3]  In particular,  because the IEEE allows blanket letters of assurance (and most companies provide blanket LoAs), at that time no one really knew how many patents were likely to be essential to the 802.11 standard.

PA Consulting already had done a cellular SEP landscape so they seemed like the right team to answer our question.  At the time, Graham was working for PA Consulting and he became involved in doing the work that resulted in the 802.11 patent landscape report.  But Graham’s expertise transcends Wi-Fi to all things radio based including cellular, GPS, short range RFID and the like.  He is now at a company called Cubicibuc Ltd.[4] 

Last year, I published a series of posts on how the cellular standard has lost its way.  One of these posts, The Bloatware That Is 5G, discussed how the 5G standard has become full of bits and bobs that most implementers neither need nor want nor use.  By trying to be everything to all possible applications (smart phones, base station equipment, IoT, cars, satellites), it has become larded with features and functionality that are not useful or used by many devices. This type of overreach, and the many new applications for existing technology, has substantially morphed the notion of essentiality.  It used to be the case, that essential to a standard meant necessary, i.e. unless a device included all of the “essential” technology, the device would not be able to function properly to communicate within the network. 

Even with respect to 4G, that is no longer the case.  As Graham discusses, there is a lot of functionality in the cellular standard[5] that is unnecessary to most implementing devices and that many device makers do not need or use. What follows is Graham’s post from his more technical perspective on what cellular LTE technology is, and is not, used in IoT devices and on why this means that “essential” no longer means necessary. 

Graham's Post:

Introduction

Mobility is a key technology for communications. It’s literally what puts the “mobile” in “mobile-phone”. Mobility allows users to remain connected, making calls, watching content, sending and receiving emails as they move around an environment: walking around a city, as a passenger in a vehicle or sitting in a high-speed train.

I wanted to focus here on one type of mobility and a specific set of applications, i.e. on the cellular IoT standards (C-IoT) developed by 3GPP. There are of course non-cellular wireless standards that can be used for IoT applications, such as WiFi. A key difference between cellular and WiFi is spectrum. The majority of the time, when we talk about cellular, we inherently mean applications that use the licensed spectrum.  I will note that LTE cellular also supports the use of unlicensed spectrum which has gained popularity particularly in private network deployments [Note from Marta, see footnote 1 in Convergence and Competition – A Tale of Two Standards Part 3 (The IoT Market) for a discussion of the problems with this].

Licensed spectrum has the advantage that a single network operator (often called a carrier or service provider) will have been granted a license by the applicable governmental body (such as Ofcom in the UK)  to operate in that radio spectrum, as well as guarantees that protect the usage from interference by limiting other usage in and around that same part of the spectrum. In contrast, unlicensed spectrum, which is used by WiFi, is open for public use (within certain power limits), allowing for affordable, flexible deployments by consumers without the need for a formal relationship with a service provider. Solutions like Wi-Fi are easily deployed by consumers but have a much higher potential for interference and congestion due to shared access from other WiFi access points or other technologies using the same spectrum. 

LTE

When LTE (which stands for Long Term Evolution) was first released in 2008 it supported five categories of device: Cat 1 to Cat 5 – see 3GPP Technical Specification TS 36.306 “User Equipment (UE) radio access capabilities” – which broadly built on the UE categories previously specified for 3G in 3GPP TS 25.306 “UE Radio Access Capabilities.”[6]

LTE UE Cat 1 to Cat 5 as defined in TS 36.306 were focused on defining capabilities for LTE handsets – mobile phones – each providing ever greater bandwidths for consumers. The technical specification defines different maximum numbers of bits that could be received by a device within a time interval (TTI) as well as how many layers of multiplexing could be supported (1 for Cat 1 up to a maximum of 4 for Cat 5). While these categories of UEs could be used for other types of devices and applications they were never optimised for such other uses.  They were optimised for mobile handsets, e.g. smartphones.

In order to understand what optimised/not optimised means in this context, I wanted to give some common IoT examples from which a number of characteristics become evident.

Smart Utility Meters

A good example to start with is smart utility meters[7] – gas, electric and water metering. Adding smart functions to such meters is a prime example of the potential benefits of IoT. For the utility companies, smart meters enable regular automatic collection of data without the need of engineers visiting each and every property to manually take readings – an obvious business benefit.[8]

Such meter readings are perhaps taken periodically: weekly or monthly. Meter readings consist of very small packets of data sent to the network (uplink) – hence smart meters have very low throughput/very low bandwidth needs.

There is often no need for a downlink since in many applications there is no data being sent from the network to the smart meter. Likewise, there is typically no urgency around the delivery of the data.  No one really cares if the delay, the so-called latency, between taking the meter reading and receiving it at the destination is minutes or even hours.

Utility meters are also fixed assets; they are installed and typically not moved for 10 or 20 years – hence there is no need for mobility.  By mobility, I mean the ability of the device to move from place to place while still maintaining a continuous network connection. Your cell phone is often in motion and so a large part of the cellular standard is devoted to the “seamless” transition from one cell tower to another of that mobile device.  By seamless, I mean a transition that takes place without the call being dropped or even without you noticing that the device has changed its attachment point to the network, as the device moves around.

On the other hand, smart meters are often installed deep in buildings, in basements or understairs.  They require deeper indoor/in-building coverage (sometimes termed in-building penetration) beyond that which might be expected to be used or needed by typical mobile phones.  In other words, if you are in the basement of a building, your mobile phone may not be able to pick up a signal but your smart meter needs to be able to.

Smart Home and Smart Monitoring Devices

Within a smart home, in addition to smart utility meters, consumers may also add their own IoT devices. Typical examples might include smart appliances, sensors for monitoring temperature, or the status of doors or windows for basic home automation. Like utility meters, such applications are likely to be fixed location (at least limited to the relatively small zone of the property), use a very low data rate, and be focused on sending uplink data with limited or no downlink data.[9]

Additionally, home automation may rely solely or frequently on battery powered solutions – hence the enhanced need for low power operation and power saving modes/features.  In contrast, other uses such as home surveillance systems transmit video images, which unlike simple sensors, needs high data rates and low latency. Real-time video for security requires large bandwidth, and low latency (lag).

Medical devices may also fall into this category.  Medical devices often require periodic status reporting to the network from a patient monitoring device which may be battery powered.  These medical IoT devices include everything from smartwatches that monitor vital signs (as well as steps) to smart glucose monitoring systems that allow diabetics to automatically monitor blood glucose levels to implantable sensors that provide early detection of conditions ranging from strokes to potential heart attacks in those at risk.   

You can imagine that both smart home and medical devices would need significant security features.  You would not want hackers to be able to use your home surveillance systems or to hack into your implanted medical device.

In both domestic and industrial applications there also is a clear recognition that both size and cost matter in order to be useful and commercially successful. A sensor may sell for only a few dollars so adding wireless communication capabilities to it would be unreasonable if it cost more than the sensor (or even a substantial portion of the price of the sensor).

Connected Vehicles and Robotics

In the context of autonomous “things” such as autonomous vehicles or more generally robotics, sensors are likely to be combined with actuators which perform some kind of action at the IoT device or connected machinery. Modern cars may have connected passenger applications such as maps that “phone home” for updates.  These updates may be briefly bandwidth heavy but do not really require low latency (they can be done slowly and typically at any time).  Safety critical applications such as autonomous vehicles, on the other hand, require ultra-low latency bi-directional communications, and may include video as well as sensor feeds.

The 3GPP response to IoT

As in the examples above, there are many different types of IoT devices with many different connection needs.  At one end of the IoT spectrum, applications that are safety critical require bi-directional low latency high-bandwidth links. But it’s also clear that at the other end of the spectrum, some IoT devices only use small packets of low-rate data with delay tolerant characteristics.  Some are battery powered so low power draw is important.  In many applications there is limited need for the traditional mobility mechanisms so important to smartphones. Conversely, some (but not all) of IoT applications need greater in-building penetration than traditional smartphones.  And, even though there are already hundreds of millions of smartphones, it is expected that there will be many, many more IoT devices.[10]

It is with these kinds of application in mind that 3GPP launched a study into “'Cellular System Support for Ultra Low Complexity and Low Throughput Internet of Things”. 3GPP Technical Report TR 45.820[11] contains the output of the 3GPP study and captures the objectives, performance criteria and options for the introduction of IoT into the 3GPP standards. The performance objectives included:

·        Improved indoor coverage

·        Support of massive number of low throughput devices

·        Reduced complexity

·        Improved power efficiency

·        Latency

In 2016, this section of the 45 series was updated to include enhancements for new types of MTC (machine type communication) with the introduction of Cat NB1, Cat M. and Cat 1bis (seen as a re-do of Cat 1).

NB-IoT (Narrowband IoT, i.e. Cat NB1) was developed in response to the 3GPP study item, and in part to address the challenge of fixed wireless access – pushing 3GPP technologies into the spaces where standards such as WiFi operate.  This is essentially a modified cellular standard for use with IoT devices.  Despite being based on cellular technology, NP-IoT doesn’t even support mobility. 

The table below summarizes key technical parameters (data rates, latency, etc.) for NB‑IoT, LTE‑M, and Cat‑1bis as the key IoT standards deployed today. Cat1-bis can be considered a first attempt at an IoT optimised category established in 2016 in Release 13.  The “bis” in the name comes from the Latin meaning “again” or twice:  Cat1bis is very much a second attempt to get the Cat1 type right. Cat1-bis is a cut-down variant of Cat1 offering minimal reductions in capability for size and cost constraints, but still offering voice, video and mobility. LTE-M (“Long Term Evolution Machine Type Communication) is an LTE based standardised feature set that was developed by 3GPP for low-power IoT applications.  NB-IoT (“Narrowband Internet of Things”) is another low-power radio standard developed by 3GPP as an option for IoT applications that need fewer features.

Table 1: Key technical parameters (data rates, latency, etc.) for NB IoT, LTE M, and Cat 1bis

	NB‑IoT (Cat‑NB)	LTE‑M (Cat‑M1)	LTE Cat‑1bis
Release (3GPP)	Cat NB1 in Rel‑13 Cat NB2 in Rel‑14	Cat M1 in Rel‑13 Cat M2 in Rel‑14	Rel‑13
Bandwidth	180 kHz (1 LTE Resource Block RB)	1.4 MHz (6 RB)	20 MHz (LTE channel)
Duplex	Half‑duplex FDD only	Half‑duplex FDD (Cat‑M1) TDD for Cat‑M2	Full‑ or half‑duplex FDD (like LTE Cat1)
Peak DL (downlink)/ UL (uplink) rate	~26–127 kb/s DL ~66–150 kb/s UL	~300 kb/s DL ~375 kb/s UL	10 Mb/s DL 5 Mb/s UL
Latency	High (seconds): ~1.6–10	Moderate: ~50–100 ms	Low: sub‑100 ms (e.g. ~8 ms for 500-byte transfer
Power saving – PSM (Power Saving Mode) and eDRX (extended Discontinuous Reception)	PSM & eDRX supported (years of battery)	PSM & eDRX supported; higher Tx power than NB‑IoT	PSM & eDRX supported; single‑antenna saves ~2–3 dB vs Cat1
Coverage (Link Budget)	Very high (~164 dB) (≈+20 dB vs LTE)	Extended (~156 dB) (≈+12 dB vs LTE)	~141 dB (≈Cat1, ≈3 dB below Cat1’s 144 dB)
Mobility/Handover	NB1 devices typically “move” cells only on cell change	Full LTE mobility	Full LTE mobility

Looking in more detail at NB-IoT (Cat NB) we can see that it does not support significant aspects of the cellular standard.  For example, 3GPP Technical Specification TS 36.300 lists 23 functions that all standard variety LTE devices must do that are explicitly not supported by IoT devices that implement NB-IoT:

Table 2: 3GPP TS 36.300 V13.8.0 (2017-06)

4.10     NB-IoT

NB-IoT provides access to network services using physical layer optimized for very low power consumption (e.g. full carrier bandwidth is 180 kHz, subcarrier spacing can be 3.75 kHz or 15 kHz).

As indicated in the relevant subclauses in this specification, a number of E-UTRA protocol functions supported by all Rel-8 UEs are not used for NB-IoT and need not be supported by eNBs and UEs only using NB-IoT.

In this version of the specification, a number of functions including inter-RAT mobility, handover, measurement reports, public warning functions, GBR, CSG, support of HeNBs, relaying, carrier aggregation, dual connectivity, NAICS, MBMS, real-time services, interference avoidance for in-device coexistence, RAN assisted WLAN interworking, sidelink communication/discovery, MDT, emergency call, CS fallback, self-configuration/self-optimisation, ACB, EAB, ACDC and SSAC are not supported for NB-IoT. This is not further stated in the corresponding procedures.

An Estimate of the Reduction of Use of Portions of the Cellular Standard

Mobility, handover and measurement functionality accounts for a significant part of the LTE standard. A sample of the 36 series technical specifications shows mobility and handover covers a significant portion of normative text (e.g. the portion of the text that contains the rules and instructions to be followed) in the technical specification documents:

Technical Specification	Sections relating to mobility / handover	Page count	% of normative text
TS 36.300 (v13.8.0)	Section 10	48 pages from 314 pages	15%
TS 36.133 (v.13.8.0)	Sections 4, 5 & 6	52 pages from 435 pages	12%
TS 36.331 (v13.8.0)	Sections 5.4 & 5.5	39 pages from 407 pages	9.5%

A similar exercise could be undertaken for other features of the cellular standard that are not supported by NB-IoT. From the text extract above from section 4.10 of TS 36.300, MBMS (“Multimedia Broadcast Services) and Sidelink (which allows for direct device-to-device communications) are two other feature sets that are excluded from NB-IoT. These two features account for approximately 10 pages (section 5.8) and 24 pages (section 5.10) respectively – together another 8% of TS 36.331.

As far as I know, no one has yet reviewed and identified all of the relevant TS documents, and sections within, that are different between NB-IoT and LTE. While such an exercise is beyond the scope of this post, it is by no means impossible. The same is true for other features that are excluded from NB-IoT because they are not required for many IoT applications – these would include voice and video codecs.

IoT SEP Licensing - Caveat Emptor?

Some of the biggest SEP holders (including the larger patent pools) have launched (cellular) IoT SEP licensing programs.[12] Many consider IoT to be the next battle ground for SEP licensing. However, IoT is not a homogeneous set of devices and applications and so casting such a wide net for the definition of IoT is the cause of many issues.

You have to ask, what should be the implications of this (often dummied down) variants of the LTE standard for IoT SEP licensing?

One take-away from this is that IoT is such a broad definition that it is probably not sufficient alone. This is true for module makers, device makers and SEP licensing programs.

In prior generations such as 2G, a holder of a 2G SEP could legitimately claim that any and all 2G compliant products necessarily infringed their 2G essential patent because all such patents were, de facto, truly essential. In other words, all required sections of the 2G standard (depending of course on which version of the 2G standard a device implemented) were necessary to make a device that could communicate using the 2G standard. This was also generally true for each version of 3G. That same, however, cannot be said of today’s LTE SEPs, particularly when talking about the vast majority of IoT devices. Even when devices use LTE for connectivity, they may only use a very small amount of the “essential,” i.e. normative, portions of the TS 36.xxx standards which define the full set of radio features of “the” LTE standard.

In this post, I have highlighted some of the aspects of the situation with NB-IoT and in particular its lack of support for mobility. Mobility is a fundamental driver of value for typical LTE devices – i.e. for smartphones. Without mobility smartphones would not be able to achieve something we now take for granted – the ability to continue a call or a data transfer while in transit. Yet for NB-IoT, this feature is absent and any SEPs relating to it - or the other 22 features I have identified that are not supported by NB-IoT plus any other such features that I have not identified – are therefore not relevant to a multitude of IoT “LTE” devices.

It is incumbent on those involved in SEP licensing that this element of the discussion be understood and that Licensors and courts do not require licensing of cellular SEPs just because they are “essential.”  In the modern world of cellular (and other) standards, “essential” no longer means truly necessary.  Nor does it necessarily mean “used by all devices that implement that particular standard.”

Rather than caveat emptor, perhaps we should encourage scientia potentia est – knowledge is power:

• For device makers: know what specific variant of the LTE standard your product utilises, understand what features and functions this implies are and aren’t present, and be able to challenge SEP holders to present their portfolios in a meaningful way. 

• For Licensors: do not overreach.  Just because your patent is “essential” to LTE, does not mean it is used in every so-called LTE device. 

• For Courts and Regulators:  do not allow SEP holders to collect fees for patents that are not used by the specific device just because the patent is deemed “essential” to the standard. 

Essential no longer means required in order to make your product function and thus there are “essential” features in the standard that are not used by many devices that implement the standard.  These days, many “essential” features are only truly used, or truly useful, for a small subset of the types of devices that implement “the” standard.

[1]          All of the cases ended up coordinated in multi-district litigation in the Northern District of Illinois with Judge Holderman presiding:  In re Innovatio IP Ventures, LLC Patent Litigation, MDL Docket No. 2302, Case No. 11 C 9308.

[2]          Judge Robarts’ seminal decisions in the Motorola vs. Microsoft SEP lawsuit, case no. Case No. C10-1823JLR (W.D.WA), had not been issued at the time that Cisco and the other manufacturers filed their lawsuits.  However, Judge Robart issued those decisions before Judge Holderman issued his in the Innovatio MDL.

[3]          A big shout out to Greg Leonard who was the primary driver of the economic analysis.

[4]          Our Team - CUBICIBUC 's Director: Graham Bell

[5]          As I have said before, there is no such thing as “the cellular standard.”  There are various different technical specification series promulgated by 3GPP that may, or may not, work together (some of them are mutually exclusive) that are related to each generation of “the” cellular standard.  It is important to be aware of this when contemplating the meaning of “essential.”  Here though Graham is discussing essentiality within the context of a single technical specification series.

[6]          In the world of 3GPP standardisation, technical specifications are grouped in series. “TS” means Technical Specification.  In the case of TS 36.xxx, the number 36 denotes the series of documents relating to LTE radio technology and the “xxx” represents a specific portion of the overall document that is TS 36.  Cellular networks of course also use other TS’ and other standardised technology that describe other aspects of the network that are needed to make cellular networks function.  Similarly, the number 25 in TS 25.xxx denotes the series of documents relating to the radio aspects of certain versions of what is known as 3G.  You can find them here: Specifications by Series: 3GPP.

[7]          Note from Marta: Smart meters (and mesh networking) are in no way new.  There was, for example, a company called Metricom that was founded in 1985 by David Elliott and the legendary Paul Baran.  It did connected meters using a radio-based system before the development of the first Wi-Fi standard and before the 3G cellular standard was released.  They also had an early wireless service called Ricochet that operated in Silicon Valley and other places.  This operated using mesh-networking technology.  Fun fact:  I have it from a reputable source that in the early days some of the Metricom people used to climb telephone poles and street lights at night to guerilla install their own base-station like devices to run these services.

[8]          Note from Marta: there is also an obvious environmental benefit.  Smart meters both reduce driving (by not requiring site visits to read meters) and allow for tiered time of use rate plans that charge higher rates during peak hours and lower rates off-peak which is intended to limit peak use and so reduce the need for new energy generation sources.   

[9]          Note from Marta:  Smart homes also help reduce energy usage.  That is one of the reasons why it is so horrendously bad that the EU has withdrawn its Proposal for a Regulation of the European Parliament and of the Council on standard essential patents and amending Regulation (EU) 2017/1001.  That proposal would have helped the IoT industry which makes so many necessary green products.  See, A Greener Future - EU Proposal Part Two.

[10]        Note from Marta:  See Convergence and Competition – A Tale of Two Standards Part 3 (The IoT Market) for more about this.

[11]        The 3GPP 45 series of documents relates to radio aspects of GSM/EDGE communications, and TS 45.820 is a portion of the series related to “Cellular system support for ultra-low complexity and low throughput Internet of Things (CIoT)”

[12]        Note from Marta:  See for example, Avanci IoT - Avanci