Browse Prior Art Database

IMPROVING SERVICEABILITY IN LoRaWAN® AND INTERNET OF THINGS DEVICES

IP.com Disclosure Number: IPCOM000249342D
Publication Date: 2017-Feb-17
Document File: 6 page(s) / 232K

Publishing Venue

The IP.com Prior Art Database

Related People

Muhilan Natarajan: AUTHOR [+4]

Abstract

A set of Media Access Control (MAC) commands provide device alive status of LoRaWAN® Class A end devices to a network server. This enables network administrators to confirm whether Internet of Things (IoT) devices/sensors are still operating normally, even if the IoT devices do not have transmissions to send over long periods of time. This greatly reduces the need to dispatch technicians to visually check/inspect LoRaWAN end devices to determine whether the devices are still operational because the devices periodically check in and indicate their operational status.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 30% of the total text.

Copyright 2017 Cisco Systems, Inc. 1

IMPROVING SERVICEABILITY IN LoRaWAN® AND INTERNET OF THINGS DEVICES

AUTHORS: Muhilan Natarajan

David White Michael O'Brien Shaun Roberts

CISCO SYSTEMS, INC.

ABSTRACT

A set of Media Access Control (MAC) commands provide device alive status of

LoRaWAN® Class A end devices to a network server. This enables network administrators

to confirm whether Internet of Things (IoT) devices/sensors are still operating normally,

even if the IoT devices do not have transmissions to send over long periods of time. This

greatly reduces the need to dispatch technicians to visually check/inspect LoRaWAN end

devices to determine whether the devices are still operational because the devices

periodically check in and indicate their operational status.

DETAILED DESCRIPTION

LoRaWAN Class A end devices (e.g., IoT devices/sensors) were designed to

consume minimal battery power. As such, they transmit data only when there is a

communication need, and sit idle otherwise. These devices often do not transmit data for

very long periods of time. During these periods, it is unknown whether the device is still

operating normally. This is further complicated by devices that do not transmit data on any

fixed periodic schedule. A network operator is unable to determine whether the device has

nothing to send or has instead malfunctioned. As such, a human is often physically

dispatched to the sensor to investigate.

The below proposed modifications to the LoRaWAN protocol solve this problem

by requesting that the sensor check-in to ensure it is still operational. More specifically, a

proprietary MAC command signals to a LoRaWAN Class A device when to periodically

check in, thereby indicating that the device is functional.

Copyright 2017 Cisco Systems, Inc. 2

When a remote IoT device/sensor is deployed in a hard-to-reach location (e.g.,

geographically remote, challenging for a human to access, etc.), the desire is to allow the

sensor to run for as long as possible on its existing battery. As a result, most deployed

LoRaWAN devices today leverage the Class A specification, in which the sensor wakes up

only when it has data to send, and only receives data after sending data. This allows these

sensors to have extremely long battery life (e.g., 10 years). However, because these devices

do not have to transmit at any specific time, operators are challenged with determining

whether the devices are still functioning after the devices have not been heard from for

some period of time.

In contrast to LoRaWAN Class A devices, LoRaWAN Class B and Class C devices

allow for more frequent communications to their gateway, thereby resolving this issue.

However, due to power consumption requirements, these devices are not widely used.

Today, companies dispatch humans to manually check the Class A device in order

to ensure it is still operating normally if no data has been received from the device for some

amount of time. Provided herein are methods that allow LoRaW...