• Contact Us
  • Support
  • Sign In
    • MQcentral
MachineQ company logo, a Comcast company, link to homepage.
  • Home
  • Build IoT Solutions
  • Enterprise Solutions
  • Products
  • Platform
  • Company
    • Blog
    • Events
    • News
    • Contact Us
  • Shop
  • Contact Us
  • Support
  • Sign In
  • MQcentral

View our latest news content

  • Cable travels tech-agnostic road to smart cities
  • The 10 Coolest IoT Connectivity Companies: The 2020 Internet Of Things 50
  • Mouser Electronics Signs Agreement with MachineQ to Distribute Enterprise Sensors and LoRaWAN Gateways
  • City of College Park Turns to Comcast for Smart City Capabilities
  • MachineQ Brings 'Smart City' Events to Philadelphia
  • Penn and Comcast Announce First Winner of Comcast-Pennovation Challenge
  • Comcast's MachineQ Deploys Smart City Solution in Philly Holiday Hotspots
  • Comcast's MachineQ™ Enterprise Internet of Things Service Announces New Customers
  • Comcast's latest thing: Helping Victor's wireless rodent traps send kill alerts
  • MachineQ to Sponsor Startup City at IoT World 2018
  • Streetwise: How a smart Philadelphia would embrace transformational technologies
  • Comcast’s MachineQ Enterprise IoT Service Announces Next Wave of Customers
  • 6 Executives Quietly Pulling the Strings on Cable's Convergence into Wireless
  • Momentum is Building for LoRaWAN™
  • Meet the 17 people tasked with advising Philly on smart city best practices
  • MachineQ is Building Products to Improve How the World Operates
  • Universal Parks Taps Comcast’s MachineQ To Infuse IoT Intelligence Into Park Operations In Universal Orlando Resort
  • LoRa Alliance™ Recognizes 2019 Board of Directors, Including MachineQ's Alex A. Khorram and Michael Putterman

View our latest blog content

  • Three Ways to Simplify IoT Network Management
  • Over-The-Air Updates Are Critical to Your IoT Deployment. Here’s What It Means for You.
  • Adopting IoT? Learn Why One-Off Solutions Can’t Compete with Platforms
  • Introducing the MQcentral October 2019 Release
  • IoT Solutions to Tackle Everyday Restaurant Challenges
  • Introducing the MQcentral August 2019 Release
  • Introducing 10 New Ways to Use the MQ Platform to Scale Your IoT Solutions
  • Simplifying Wireless IoT Gateway Deployment With Secure Backhaul
  • H2O Degree Simplifies Submetering in 30-acre Apartment Complex Using Just 1 MachineQ Gateway
  • How to Optimize your Smart Office Lighting System to Save Energy and Money
  • Three Ways MQcentral Just Got a Whole Lot Better
  • The City of Wichita Gets Smart with LoRaWAN®
  • PNI Utilizes the MachineQ Network to Eliminate Parking Headaches
  • Why Choose LoRaWAN™?
  • Simplicity Rules at Radio Bridge
  • Range Testing with Radio Bridge and MachineQ
  • How to Detect Connection Loss on a LoRaWAN® Device, and Why it Matters
  • The Global Impact of Sensoterra’s Smart Solution
  • With MachineQ, H2O Degree Provides “Smart Metering at its Best”
  • MQcentral: Making IoT Management a Cinch
  • How UX Expands Beyond the Digital Sphere at MachineQ
  • OTA Updates – It’s Not Rocket Science
  • Q+A with Peter Owens: President + Founder at SteamIQ
  • Victor and MachineQ Partner to Revolutionize Pest Control
  • 2019 Predictions – Enterprise IoT
  • How to Manage the “I” of IoT
  • Why Real-Time Energy Monitoring Is a Disruptive Technology That Matters

View our latest events content

  • Air Conditioning, Heating & Refrigeration Expo
  • LoRa Alliance Members Meeting
  • PGA Merchandise Show
  • Nation Retail Federation (NRF)
  • LoRa Boot Camp
  • Sustainable Brands
  • LoRa Alliance Annual Members Meeting
  • HITEC
  • BOMA International Conference & Expo
  • Sensors Expo & Conference
  • Semtech LoRa Boot Camp
  • Microsoft Inspire
  • Internet of Things for Sustainability is Smart Business Conference
  • ST Technology Tour – Boston
  • MWC19 Los Angeles
  • ST Technology Tour – Minneapolis
  • ST Technology Tour – Vancouver
  • ST Developers Conference
  • FSTEC

View our latest solution providers content

  • KS Technologies (KST)
  • Tapdn
  • Eddy Solutions
  • Reservoir
  • Microshare
  • netLiNK Controls
  • Radiator Labs
  • Concrete Sensors
  • H2O Degree
  • Vutiliti
  • Subeca
  • Sensoterra
  • StormSensor
  • Kwant.ai
  • STRATIS
  • Fairway IQ
  • Mission Data
  • PNI

View our latest additional pages content

  • Apps
  • Sensors
  • Smart Cities

When writing a LoRaWAN® end device’s firmware, one feature that often gets overlooked is connection loss detection and remediation. There are several reasons why an end device could land in this stranded state where it does not receive any downlink messages from the network, including:

  • The device transitioned quickly between two gateways with channel maps that don’t overlap
  • The device’s RX1 and RX2 reception parameters become out of sync with the network server
  • The device roamed to a different network provider’s region (if there is no roaming agreement between those two providers)

While these occurrences aren’t common, their importance is elevated when you consider that some LoRaWAN devices are designed to last a decade or more. The burden of handling these states lies 100% with the end device’s application firmware. Obviously, a network is unable to send a downstream message instructing the device to rejoin the network if that device is unable to receive downstream messages.

The LoRaWAN specification provides a few methods to detect connectivity loss, but the specification is silent on exactly when a device should consider itself stranded, and what it should do in response. These decisions are left up to the application layer. There are a few different methods of detecting a connection loss:

1. Confirmed Transmissions

The easiest-to-grasp method for detecting a connection loss is what happens when an end device transmits a confirmed message upstream that is not acknowledged by the network. Section 18.4 of the LoRaWAN1.0.2 specification includes a table and provides examples of when an end device should lower its data rate upon not receiving an acknowledgment. Basically, the end device will lower its data rate one step every time two acknowledgments are not received.

Assuming the end device does not receive an acknowledgment after seven retransmissions, MachineQ doesn’t recommend immediately considering the connection lost. Perhaps the end device is only in range of a single gateway and it was rebooted or the gateway’s backhaul went down temporarily. A longer timeframe should be used to determine connection loss since joining the network itself can take a few minutes and require multiple transmissions.

2. Unconfirmed Transmission

Devices transmitting upstream using unconfirmed messages do not normally receive any type of response to their transmission. This transmission mode saves the most downstream capacity and can even lower upstream packet loss when using a half-duplex gateway that cannot receive any messages when it is transmitting downstream.

Devices using unconfirmed messages may periodically receive a downstream mac message. When this happens, the device can know it is still connected to the network, even though the downstream message did not specifically acknowledge any upstream message.

However, after many upstream transmissions without receiving any downstream commands, the LoRaWAN 1.0.2 specification (section 4.3.1.1) provides an interesting way to determine connectivity loss. After 64 transmissions (by default), the ADRACKReq bit is set in the frame’s header. This instructs the network server to send a downstream acknowledgment, but not necessarily immediately. If the network server knows the gateway(s) that received a frame from the end device does not currently have downstream capacity, the network server can choose to not respond to the first request.

This also prevents the end device from expecting an acknowledgment, so it doesn’t start dropping its data rate nor retransmit like a normal confirmed uplink transmission. Instead, the end device continues to enable this ADRACKReq bit in all upstream transmissions for 32 more transmissions (by default). At this point, if it still hasn’t received a downstream message, the end device will lower its data rate, unless it is already at the minimum.

After this process, the end device would be at the minimum data rate, it would have requested an acknowledgment to many uplinks, and if it still didn’t receive a downlink it could consider itself disconnected from the network.

3. Link Check Request/Answer

This is a mac command that will be responded to using a link check answer. The answer will include a margin of reception (in dB) and the number of gateways that the upstream request was received by.

This method is not recommended because sending a link check request command will take an additional byte in the upstream frame. While this may not matter most of the time, at data rate 0 aka spreading factor 10, devices only have 11 bytes of payload available in the US band. Additionally, if this link check frame is sent every 10 messages as an example, then a connection state is only detected for those frames containing the link check request. Compared to using the ADRACKReq bit which would be in every upstream message (after a delay), with no additional payload requirement.

End devices could include a link check request in every single upstream frame, but at that point it would make more sense to just switch to confirmed upstream transmissions and again not be burdened by the additional payload requirement.

Get Started

MachineQ delivers best-in-class LoRaWAN™-based hardware, enterprise-grade software and expertise to accelerate innovation and reduce time to market.

Contact Us
MachineQ footer logo
  • MachineQ
    • Build IoT Solutions
    • Enterprise Solutions
    • Products
    • Platform
    • Solution Providers
  • About Us
    • Company
    • Blog
    • Events
    • News
    • Contact Us
  • Store
    • Indoor Gateways
    • Outdoor Gateways
    • Devices
    • MachineQ QuickStart
  • Social
    • Twitter
    • LinkedIn
  • Tools & Resources
    • Coverage Tools
    • Support
    • Getting Started

© 2021 MachineQ™ All Rights Reserved. Terms of Service | Privacy Policy | Cal. Civ. Code §1798.135: Do Not Sell My Info