YOBIIQ LoRaWAN Stack Information

LoRaWAN Communication

General

The LoRaWAN Interface is in compliance with the LoRa Alliance specifications, and is based on the LoRa transmission standards.

Using the LoRa protocol the device can reliably transmit data over large distances without permanent communication.

The interface constantly adapts to the optimal transmit and receive parameters individually to ensure a stable and reliable link to the LoRaWAN Gateway.

Products with a display show the status of the link to the LoRaWAN network; see the product's Technical Reference Manual.

• The LoRaWAN interface is compatible with LoRaWAN V1.0.4.
• The device class is set in production for each product (register 0xFF9F: Class C in the current products, which are all mains powered) and can be changed with that register; a new class applies at the next join, and to BLE advertising at the next restart, see BLE Advertising.
• The required parameters and configuration of the LoRaWAN interface are permanently saved inside the device.

All devices are delivered with OTAA mode enabled, the DevEUI of the device is listed on the package and on the device itself.

Infrastructure

IoT System Components

The Customer is responsible for a working LoRaWAN Infrastructure, a typical LoRaWAN infrastructure consists out of;

1. Node / Device : a device that is equipped with a wireless communication module which forms the payload to send to a gateway or receive data from a gateway.
2. Gateway : a device that can be seen as a router, equipped with a LoRa concentrator, that receives the LoRa packets and send them on their way to a network server / platform.
3. Server Platform : a platform that is usually cloud based where all communication is being prepared and processed. The processing can either be done on the platform where it's being stored, analysed and presented or it can be forwarded to an IoT Platform that handles these actions.

If needed YOBIIQ can support customer with the selection and configuration of the infrastructure, this however is not covered by the normal support coverage.

YOBIIQ also supplies a turn-key LoRaWAN Infrastructure if customer has no experience with the required infrastructure.

Operational Procedure

Join Process

The device joins the network with OTAA. The data rate of each join request follows the LoRaWAN join distribution of the region, whatever the device class: in EU868 the join requests are spread over SF7 to SF12, mostly SF7.

Automatic connection on power-up

When the device is turned on, it sends a join request as part of the start-up cycle.

• If the join succeeds, the device sends the generic device information uplink.
• If the join fails, the device tries again every 10 minutes, within the join duty cycle of the LoRaWAN standard. By default it keeps trying without limit.

Register 0xFFA4 Join Attempts limits the number of join requests (default 0: no limit). After a restart, and again after the network is lost, the device sends at most that many join requests, the first one included; when they have all failed, it stops joining until the next restart or LoRaWAN Reset. A new value applies at the next restart.

Link checks and rejoins

The device checks its link with a LinkCheckReq MAC command, sent at the current data rate:

• every Link Check Timeframe (register 0xFFA5, default 1440 minutes), counted from the last LinkCheckReq, join or downlink received from the network: with application data, an acknowledgment, MAC commands only (on fPort 0 or in the frame header), a multicast downlink or a class B beacon. Multicast downlinks count so that a FUOTA session, which suspends the uplinks, does not end in a rejoin;
• 5 seconds after 5 consecutive confirmed uplink transmissions without acknowledgment.

After 3 consecutive LinkCheckReq without answer, with nothing received from the network in between, the device considers the network lost: it sets the LoRaWAN communication alarm (register 0xFFA7), leaves the network and joins again 5 seconds later, see Communication Watchdog.

A new Link Check Timeframe applies at the next restart. Values from 60 to 34566 minutes are used; for other values the device checks its link every 8 hours.

note

Logging uplinks, rejoins and communication watchdog alarms on the device with a timestamp is not yet supported by the SDK.

Network Quality Test

After each join, the device tests the quality of its link: it sends a LinkCheckReq and classifies the link margin given in the answer. With this information the installer knows the quality of the network and can move the device to a place with a better coverage.

Result	Link Margin
Good	link margin >= 16
Medium	link margin > 6 and < 16
Bad	link margin <= 6

note

How the result is shown (for example with an LED) and whether a test can be requested by downlink depend on the product, and some products support neither. The product's Technical Reference Manual describes what the product supports.

Time synchronization

The device synchronizes its clock with the network (DeviceTimeReq MAC command) right after each join, then every 24 hours. Periodic uplinks start after the first synchronization, so until the network answers once after a join, the device tries again every 10 minutes. After that, when the network does not answer, it tries again one hour later.

The device will adjust its internal clock to match with the time returned by the time synchronization.

Carrier Sense Multiple Access (CSMA) for LoRaWAN

The stack supports the CSMA (Carrier Sense Multiple Access) feature designed to prevent collisions in LoRa packet transmissions. This is based on LoRa Alliance Technical Recommendations TR0013.

CSMA is enabled on every device; it cannot be disabled by a register or a downlink.

LoRaWAN Lifecycle Monitoring

note

LoRaWAN lifecycle monitoring is not yet supported by the SDK. This section describes the planned feature.

It’s desirable to monitor the LoRaWAN lifecycle on end-devices in order to get an understanding of possible issues when end-devices are deployed ‘in the field’.

The planned monitoring will retrieve the following information provided by the modem and the network, and log it on the device:

• Duty cycle limitation status
• Maximum size of the next uplink
• Available datarates
• Number of consecutive uplinks without downlink

The lifecycle monitoring will not perform any LoRaWAN MAC procedures; the retrieved data is taken from the normal LoRaWAN operation of the device.

Confirmed Uplinks

If an uplink is sent as a confirmed message, the device expects an acknowledgment (ACK) from the LoRaWAN network. When no ACK is received, or the uplink could not be sent, the device sends it again 15 seconds later, up to 3 attempts in total. If the last attempt is not acknowledged either, the uplink is dropped. Each attempt is itself made of up to NbTrans transmissions, see Uplink Repetitions and Retries.

Uplink Repetitions and Retries

An uplink can be sent more than once, by two independent mechanisms:

• Repetitions (NbTrans), in the LoRaWAN MAC layer, for unconfirmed and confirmed uplinks. Each uplink is transmitted up to NbTrans times, each repetition 1 to 3 seconds after the receive windows of the previous transmission, or later when the duty cycle requires it. The repetitions stop as soon as the device receives a downlink in the receive windows (RX1, RX2) of one of them, for example the acknowledgment of a confirmed uplink. An unconfirmed uplink usually gets no downlink, so it is normally sent NbTrans times. A repetition is the same frame with the same frame counter (FCnt): the network server treats it as a copy of the same uplink and forwards the data to the application once.
• Retries, in the SDK, for confirmed uplinks only. When no acknowledgment is received, or the uplink could not be sent, the device sends it again 15 seconds later, up to 3 attempts in total, see Confirmed Uplinks. Each attempt is made of up to NbTrans transmissions. A retry is a new frame with the next frame counter (FCnt) and the same data: when the network received an earlier attempt but its acknowledgment was lost, the application receives the same data again. The FF01 timestamp of a periodic uplink identifies such a duplicate.

Who sets NbTrans:

Set by	When	NbTrans
Device, ADR by network (0xFFA0 = 1, 0xFFA2 = 0)	At each join, and when 0xFFA0, 0xFFA1 or 0xFFA2 changes	1
Device, ADR disabled (0xFFA0 = 0)	At each join, and when 0xFFA0, 0xFFA1 or 0xFFA2 changes	1
Device, Long Range or Low Power ADR profile (0xFFA2 = 1 or 2)	At each join, and when 0xFFA0, 0xFFA1 or 0xFFA2 changes	3
Device, ADR backoff (ADR by network only)	When no downlink has been received for 96 uplinks, then every 32 more: the device first restores its default transmit power, then lowers the data rate one step at a time; at the lowest data rate it sets NbTrans back to 1 and re-enables the default channels	1
Network, LinkADRReq MAC command	When the network sends one, normally only with ADR by network (the only setting in which the device sets the ADR bit of its uplinks); the value holds until the device sets it again	1 to 15
Product firmware	When joined, not with ADR by network; the value holds until the device sets it again. The SDK provides it, but no current product uses it, and no register or downlink changes NbTrans	1 to 15

Transmissions of one uplink, with the NbTrans set by the device:

ADR setting	NbTrans	Unconfirmed uplink	Confirmed uplink (up to 3 attempts, 15 s apart)
ADR by network	1, or the value set by the network	Up to NbTrans transmissions	Up to 3 x NbTrans transmissions
ADR disabled	1	1 transmission	Up to 3 transmissions
Long Range	3	Up to 3 transmissions	Up to 9 transmissions
Low Power	3	Up to 3 transmissions	Up to 9 transmissions

Which uplinks are confirmed:

Uplink	fPort	Confirmed	Attempts
Periodic uplink	1-10	As configured by record FF15, see Periodic Transmission Configuration	3 when confirmed, else 1
FUOTA status report	203	Yes	3
Generic device information	50	No	1
Command answers (status and register read answer)	1-10, 50, 100	No	1
Alarm uplink (sent by the product application, not by the SDK)	11 by default	Set by each product: unconfirmed by default and in every current product, see the product's Technical Reference Manual	1, up to 3 when a product makes it confirmed

Repetitions and retries multiply the airtime of an uplink and count against the duty cycle of the region.

ADR ACK Request

danger

To be implemented? Is there a practical reason?

Communication Watchdog

When 3 consecutive LinkCheckReq are not answered (see Join Process), the device considers the network lost. It sets the LoRaWAN communication alarm, leaves the network and joins again 5 seconds later, following the join retry rules. The device does not restart.

The LoRaWAN communication alarm, register 0xFFA7, reads 1 from the loss of the network until the next successful join, and 0 otherwise. It is saved, so it survives a restart. It is not sent as an uplink, see Alarms.

Product watchdogs, such as a relay watchdog, react to the same loss of the network and are described in the product's Technical Reference Manual.

Sending measurement registers

The device reads the configured registers at each interval boundary, counted in UTC time, and sends them once, stamped with that boundary time, see Periodic Transmissions. Periodic uplinks start after the first time synchronization.

Example of a transmission interval of 15 minutes:

• 10:00:00: the device reads the configured registers and sends them with the timestamp 10:00:00.
• 10:15:00: the device reads them again and sends them with the timestamp 10:15:00.

An uplink that cannot be sent is not sent again at a later interval.

Notes on the transmission of measurements;

• Be aware that, if you operate multiple devices in the same LoRaWAN network, transmissions by these meters may collide. The device will however adjust its transmit parameters to ensure smooth transmissions.
• Please make sure that both the device and the LoRaWAN network are configured in such a way that the device can transmit its full package to avoid losing data in failed transmissions.

Data Retransmission

note

Data retransmission depends on the product and is not supported by every product, for example because it needs additional storage. The product's Technical Reference Manual states whether it is available. On a product without it, data measured while the device is not joined is not sent later, and register 0xFFA6 has no effect.

On products that support it, data retransmission ensures that all available data is submitted to the network server and overcomes downtimes of the LoRaWAN network.

If enabled, the data retransmission is triggered by a failure of the LinkCheckReq: the device records the timestamp of the failure and stores the uplinks in a buffer. When the LinkCheckReq packets get a response again, the device retransmits all the data logged in the buffer since the failure.

warning

The amount of data you can save into the buffer depends on the type of device, the buffer operates on a FiFo method meaning that once the buffer reaches it's maximum size it will replace the oldest entry in the buffer.

note

When the Data Retransmission is utilized it can lead to an increased amount of uplinks and shorten the battery life of a device.

Payloads

Payload Structure

Uplinks and downlinks carry register records. A record is the 2-byte register address followed by the register value. All multi-byte values are big endian.

Address 1	Value 1	Address 2	Value 2	...
2 bytes	N bytes	2 bytes	N bytes

The length of a value follows the type of its register:

Type	Value length
u8, bool	1 byte
u16, i16	2 bytes
u32	4 bytes
u8[N]	N bytes
string	1 length byte, then the characters

Periodic uplinks and alarm uplinks start with the record FF01, whose value is a 4-byte UTC timestamp in UNIX seconds: the start of the interval for a periodic uplink, the time of the alarm for an alarm uplink (0 when the device has no network time yet).

Payload	fPort	Layout
Periodic uplink	1-10	FF01 + timestamp, then the configured register records
Alarm uplink	11	FF01 + timestamp, then the alarm register records
Generic device information uplink	50	Register records
Register write downlink	50	Register records
Register read answer	100	Register records

The register read request and the command status answers have their own layouts, described under Downlinks.

Example of a periodic uplink:

FF016ABA56C0FF690100FF7A09C4
// FF01 6ABA56C0 -> timestamp: 2026-09-28 12:00:00 UTC
// FF69 0100     -> firmware version 1.0
// FF7A 09C4     -> internal temperature: 2500 = 25.00 °C

Downlinks

Command Framework

The device handles three kinds of downlink commands:

fPort	Command	Layout
50 (register 0xFF9D)	Register write	Register records, see Payload Structure
100	Register read	FFCC + register addresses, see Device Parameter Reading
1-10	Periodic transmission configuration	Configuration records, see Periodic Transmission Configuration

Rules for every command:

• A command is at most 64 bytes long. A longer downlink is ignored, without an answer. The device holds up to 5 commands, the one being processed included; further downlinks are ignored until one has been handled.
• The device answers each command with a status uplink on the same fPort: 00 when the command was applied, 01 when it was rejected.
• A register write can hold several registers, which are applied together. If one record is rejected (unknown or read only register, value out of range, record cut short), none of the registers of the command is changed and a restart or LoRaWAN reset written in the same command is cancelled. A restart or LoRaWAN reset accepted by an earlier command still takes place.
• New values are saved when the command completes. A restart or LoRaWAN reset starts 10 seconds later, see Restart Device.

Example

To set the Device Name to AHU-3 and enable ADR in one command, send the following payload on fPort 50:

FF34054148552D33FFA001
// FF34 05 4148552D33 -> Device Name: length 5, "AHU-3"
// FFA0 01            -> ADR Mode: enabled

The device answers 00 on fPort 50.

Restart Device

Two registers restart the device or its LoRaWAN connection. Write them with a register write downlink on fPort 50, see Payload Structure. Any value other than 01 is rejected.

Register	Name	Value	Effect
0xFF6F	Device Restart	01	The device restarts 10 seconds after the command
0xFF95	LoRaWAN Reset	01	10 seconds after the command, the device leaves the network and joins again with its stored keys

Example

To restart the LoRaWAN connection, send the following payload on fPort 50:

FF9501
// FF95 -> register LoRaWAN Reset
// 01   -> execute

The device first answers 00 (command accepted) on fPort 50; a rejected command is answered 01.

Device Parameter Reading

To read registers, send a register read request on fPort 100: FFCC followed by 1 to 10 register addresses.

Bytes	Content
2	FFCC (read request)
2 per register	Register address, 1 to 10 addresses

The device answers on fPort 100 with two uplinks:

1. A status byte: 00 when at least one register was read, 01 when the request is malformed (odd length, no address, more than 10 addresses) or no register could be read.
2. The register records of the registers read, see Payload Structure. Registers that cannot be read are left out: unknown addresses, and the registers that are not readable over LoRaWAN (DevEUI 0xFF9A, AppEUI 0xFF9B, AppKey 0xFF9C, Password 0xFF6E, and the write-only Device Restart 0xFF6F and LoRaWAN Reset 0xFF95). The answer holds at most 128 bytes: a register whose record does not fit is left out. When the answer is longer than the current data rate allows, the last records are left out.

Example

To read the model, serial number and battery percentage, send the following payload on fPort 100:

FFCCFF67FF68FF6D
// FFCC -> read request
// FF67 -> Device Model
// FF68 -> Serial Number
// FF6D -> Battery Percentage

The device answers 00 on fPort 100, then:

FF670352434DFF6800BC614EFF6D00
// FF67 0352434D -> Device Model: length 3, "RCM"
// FF68 00BC614E -> Serial Number: 12345678
// FF6D 00       -> Battery Percentage: 0 % (mains powered device)

Periodic Transmission Configuration

The device sends up to 10 periodic transmissions, one per fPort from 1 to 10. Each one is configured by a downlink on its own fPort, made of configuration records: a 2-byte record code followed by its value.

Record	Value	Content
FF14	u16	Transmission interval in minutes, 1 to 65535
FF15	u8	0: unconfirmed uplinks, 1: confirmed uplinks
FF16	u8	0: inactive, 1: active
FF17	Length byte + addresses	Registers to send: a length byte (2 x the number of registers), then 1 to 10 register addresses

A command may hold only some of the records; the others keep their current value. Send all four records to set up an fPort that has no configuration yet. A command with any other record, a value out of range or more than 10 registers is rejected (status 01) and changes nothing. The default configuration of each fPort is product specific and is described in each product's Technical Reference Manual.

Example

To send the firmware version and the internal temperature every 15 minutes, unconfirmed, on fPort 2, send the following payload on fPort 2:

FF14000FFF1500FF1601FF1704FF69FF7A
// FF14 000F         -> interval: 15 minutes
// FF15 00           -> unconfirmed uplinks
// FF16 01           -> active
// FF17 04 FF69 FF7A -> 2 registers: Firmware Version, Internal Temperature

The device answers 00 on fPort 2.

Uplinks

Generic Device Information

After each successful network join, the device sends one uplink with its generic device information on fPort 50, unconfirmed. It holds register records without a timestamp, see Payload Structure, in this order:

Register	Name	Type	Content
0xFF6A	Hardware Version	u16	Major x 256 + minor, 0100 is version 1.0
0xFF69	Firmware Version	u16	Major x 256 + minor, 0100 is version 1.0
0xFF68	Serial Number	u32	Serial number of the device
0xFF9F	Device Class	u8	0: Class A, 1: Class B, 2: Class C
0xFF6B	Power Status	u8	0: battery power, 1: mains power
0xFF6C	Battery Voltage	u8	Volts x 10, 0 on mains powered devices
0xFF67	Device Model	string	Length byte, then the model name

When the current data rate cannot carry the whole payload, the records that do not fit are left out, starting from the end of the list.

Example

An RCM with hardware and firmware version 1.0 and serial number 12345678, in Class C and mains powered, sends:

FF6A0100FF690100FF6800BC614EFF9F02FF6B01FF6C00FF670352434D
// FF6A 0100     -> Hardware Version: 1.0
// FF69 0100     -> Firmware Version: 1.0
// FF68 00BC614E -> Serial Number: 12345678
// FF9F 02       -> Device Class: Class C
// FF6B 01       -> Power Status: mains power
// FF6C 00       -> Battery Voltage: 0 (mains powered)
// FF67 0352434D -> Device Model: length 3, "RCM"

Alarms

When an alarm occurs, the device sends an alarm uplink on fPort 11, unconfirmed and ahead of the periodic uplinks. It starts with the FF01 timestamp record (the time of the alarm), followed by one register record per alarm: the alarm register address and its current value, see Payload Structure.

Record	Content
FF01	UTC time of the alarm, 4 bytes, UNIX seconds
Alarm register	Address of the alarm register, then its value

The alarms and their registers are product specific and are described in each product's Technical Reference Manual.

note

The LoRaWAN communication alarm and the internal temperature alarm are not sent as uplinks. The LoRaWAN communication alarm can be read in register 0xFFA7, see LoRaWAN Data Registers.

Periodic Transmissions

Each active periodic transmission sends, on its fPort and once per interval, the FF01 timestamp record (the start of the interval) followed by the records of the configured registers, in the configured order, see Payload Structure. Registers that cannot be read are left out.

An uplink carries at most 68 bytes, and at most what the current data rate allows. When the records do not all fit, the registers that remain go in the next uplinks on the same fPort, sent one after the other as soon as the previous one is sent or has failed. Each of these uplinks starts with the same FF01 record (the start of the interval), so that it decodes on its own, and no register of the list is lost. A register whose record does not fit in an uplink after the FF01 record, at the current data rate, is left out: for example a f32 register (6-byte record) at 11 bytes (US902-928 DR0).

The periodic transmissions are configured by downlink, see Periodic Transmission Configuration.

Generic Device Data Registers

Register Reference

The following table lists the common registers available in the generic range.

Address	Name	Type	Access	Range	Default	Unit	Description
Identification
0xFF65	Manufacturer	string	R	-	Provisioned	-	Device manufacturer name.
0xFF66	OEM	string	R	-	Provisioned	-	Original Equipment Manufacturer information.
0xFF67	Device Model	string	R	-	Provisioned	-	Model designation of the device.
0xFF68	Serial Number	u32	R	-	Provisioned	-	Unique hardware serial number.
0xFF69	Firmware Version	u16	R	-	-	-	Running firmware version: major x 256 + minor, 0x0100 is version 1.0.
0xFF6A	Hardware Version	u16	R	-	Provisioned	-	Hardware version: major x 256 + minor, 0x0100 is version 1.0.
0xFF34	Device Name	string	RW	0 to 15 characters	None	-	User-assigned name for the device.
Location
0xFF32	Building Name	string	RW	0 to 15 characters	None	-	Name or ID of the building.
0xFF33	Building Room	string	RW	0 to 15 characters	None	-	Room or location identifier.
System
0xFF64	Device Status	u8	R	-	0	-	Operation mode (0: Normal, 1: Special, 2-255: Custom).
0xFF6B	Power Status	u8	R	-	Provisioned (1 in current products)	-	Source (0: battery power, 1: mains power).
0xFF6C	Battery Voltage	u8	R	-	-	V	Battery voltage, resolution 0.1 V (36 = 3.6 V); 0 on mains powered devices.
0xFF6D	Battery Percentage	u8	R	-	-	%	Remaining battery life; 0 on mains powered devices.
0xFF6E	Password	string	-	0 to 15 characters	Provisioned	-	Access password, written over BLE only and never read back.
0xFF6F	Device Restart	u8	W	1	-	-	Write 0x01: the device restarts 10 seconds after the command.
Telemetry
0xFF7A	Internal Temp	i16	R	-	-	°C	Circuit temperature, resolution 0.01 °C.
0xFF7B	Internal Humidity	u8	R	-	-	%	Circuit relative humidity.
0xFF82	Ambient Temp	i16	R	-	-	°C	Environmental temperature, resolution 0.01 °C.
0xFF83	Ambient Humidity	u8	R	-	-	%	Environmental relative humidity.
0xFF78	Temp Sensor Error	bool	R	-	0	-	Status of the internal temperature sensor; always 0 in the current firmware.
0xFF79	Temp Alarms	u32	R	-	0	-	Total count of temperature alarms triggered; always 0 in the current firmware.

Notes:

• Access is given for LoRaWAN: R read, W write, RW read and write, - not accessible over LoRaWAN. BLE has the same access unless the description says otherwise.
• Range gives the values accepted on write; other values are rejected. Provisioned values are set in production for each device.
• Strings (string): a length byte followed by the ASCII characters, at most 15 characters; a longer string is rejected. For example, Device Name AHU-3 is written as FF34054148552D33 (register 0xFF34, length 05, characters 4148552D33).
• Multi-byte numbers are big endian.

Device Naming and Location Context

As deployments grow in scale and complexity, identifying a specific device by its serial number or hardware address alone becomes increasingly impractical. To address this, v2.3.0 introduces three dedicated writable registers Device Name, Building Name, and Building Room that allow system integrators to embed contextual metadata directly on the device.

Device Name

The Device Name register (0xFF34) allows a human-readable label to be assigned to each individual device. Rather than relying solely on identifiers such as the DevEUI or serial number, integrators can write a meaningful name (e.g., AHU-Controller-3 or Entrance-Sensor) that travels with the device's data payloads and register reads. This simplifies device management in dashboards, monitoring platforms, and field diagnostics.

Building Name and Building Room

The Building Name (0xFF32) and Building Room (0xFF33) registers extend this concept to physical location. In multi-site or multi-floor environments, such as office complexes, industrial facilities, or smart campuses, these fields allow each device to declare where it is installed. A device might report Building Name: HQ-North and Building Room: Server Room B2, providing immediate spatial context without requiring a separate asset registry lookup.

Together, these three registers enable richer data collection pipelines. When location context is embedded at the device level, downstream systems can group, filter, and aggregate telemetry by building or room without relying exclusively on network-side configuration or manual mapping. This is particularly valuable in environments where devices are managed by multiple parties, or where network server metadata may not be synchronized with the physical installation.

All three registers are read/write, persist across reboots, and can be configured via downlink or direct register access through the standard tooling.

LoRaWAN Data Registers

Register Reference

The following table lists the LoRaWAN registers available in the generic range.

Address	Name	Type	Access	Range	Default	Unit	Description
0xFF96	Join Status	bool	R	-	-	-	Network connection status (1: Joined).
0xFF97	Radio Module	string	R	-	Provisioned (SX1262)	-	Integrated radio transceiver model.
0xFF98	Region	u8	R	-	0x01	-	LoRaWAN region, 0x01 (EU863-870) in current products.
0xFF99	LoRaWAN Version	u8[3]	R	-	01 00 04	-	LoRaWAN specification version (Major.Minor.Patch), 01 00 04 is 1.0.4.
0xFF9D	App Port	u8	R	-	50	-	FPort of the register write downlinks, see Command Framework.
0xFF9E	Join Type	u8	R	-	1	-	Activation method (fixed to 0x01: OTAA).
0xFF95	LoRaWAN Reset	u8	W	1	-	-	Write 0x01: 10 seconds after the command, the device leaves the network and joins again with its stored keys.
0xFF9A	Device EUI	u8[8]	-	-	Provisioned	-	LoRaWAN DevEUI, read and written over BLE only. A new value is used from the next LoRaWAN Reset or restart.
0xFF9B	App EUI	u8[8]	-	-	Provisioned	-	LoRaWAN AppEUI/JoinEUI, read and written over BLE only. A new value is used from the next LoRaWAN Reset or restart.
0xFF9C	App Key	u8[16]	-	-	Provisioned	-	LoRaWAN AppKey, read and written over BLE only. A new value is used from the next LoRaWAN Reset or restart.
0xFF9F	Device Class	u8	RW	0 to 2	Provisioned (2 in current products)	-	LoRaWAN Class (0: A, 1: B, 2: C). Applies at the next join, and to BLE advertising at the next restart.
0xFFA0	ADR Mode	bool	RW	0, 1	1	-	Adaptive Data Rate (1: Enabled). Applies at once when joined, otherwise at the next join.
0xFFA1	Spreading Factor	u8	RW	0 to 6	0	-	Data rate used when ADR is disabled. Applies at once when joined, otherwise at the next join.
0xFFA2	ADR Profile	u8	RW	0 to 2	0	-	ADR optimization strategy. Applies at once when joined, otherwise at the next join.
0xFFA3	Radio Mode	u8	RW	0 to 2	0	-	Radio mode selection; only 0x00 (LoRaWAN) is used, iQ D2D is not available.
0xFFA4	Join Attempts	u8	RW	0 to 255	0	-	Maximum number of join requests after a restart or a lost network, 0: no limit. Applies at the next restart, see Join Process.
0xFFA5	Link Check TF	u16	RW	1 to 65535	1440	min	Link check interval; values from 60 to 34566 are used. Applies at the next restart, see Join Process.
0xFFA6	Retransmission	bool	RW	0, 1	1	-	Enables data retransmission on products that support it; no effect otherwise.
0xFFA7	Comm Alarm	u8	R	-	0	-	LoRaWAN communication alarm: 1 from the loss of the network until the next successful join, 0 otherwise, see Communication Watchdog.

Access, ranges, strings and numbers follow the notes under Generic Device Data Registers.

LoRaWAN Region

Register 0xFF98 gives the LoRaWAN region the device works in. The region is fixed by the firmware of the product and cannot be changed by a register; current products use EU863-870 (0x01). Make sure it matches your network, as LoRaWAN regions are country dependent.

Value	Description
0x01	EU863-870
0x02	AS923 group 1
0x03	US902-928
0x04	AU915-928
0x05	CN470
0x06	2.4 GHz worldwide
0x07	AS923 group 2
0x08	AS923 group 3
0x09	IN865
0x0A	KR920
0x0B	RU864
0x0C	CN470 (RP 1.0)
0x0D	AS923 group 4

Spread Factor

The Spread Factor is the fixed DR used by the device when the ADR is disabled.

Value	Description
0x00	DR0 (SF12 BW125 in EU868 region)
0x01	DR1 (SF11 BW125 in EU868 region)
0x02	DR2 (SF10 BW125 in EU868 region)
0x03	DR3 (SF9 BW125 in EU868 region)
0x04	DR4 (SF8 BW125 in EU868 region)
0x05	DR5 (SF7 BW125 in EU868 region)
0x06	DR6 (SF7 BW250 in EU868 region)

ADR Profile

The ADR (Adaptive Data Rate) can be set to ON or OFF. More specifically this result in:

ADR ON: the device uses a so called ADR profile to decide how to adapt the data rate.
By default, the profile is set to ADR by network : actually means that DR is network controlled, i.e. the LoRaWAN network is responsible for telling the device how to adjust the data rate (spreading factor)

ADR OFF: the device uses the DR set to spread factor register. (Fixed Data Rate)

The ADR profile that the device uses when ADR is set to ON can be changed through a downlink.

Name	Value	Description
ADR by network	0x00	DR controlled by the network
Long Range	0x01	The used SF is distributed as: 30% SF9, 30% SF10, 20% SF11, 20% SF12. It's a tradeoff that favours long range above low power. Each uplink is sent up to 3 times (NbTrans 3).
Low Power	0x02	The used SF is distributed as: 30% SF7, 30% SF8, 30% SF9, 10% SF10. It's a tradeoff that favours low power above long range. Each uplink is sent up to 3 times (NbTrans 3).

With the Long Range and Low Power profiles, unconfirmed and confirmed uplinks alike are sent up to 3 times (NbTrans 3), see Uplink Repetitions and Retries.

Radio Mode

Register 0xFFA3 selects the radio mode of the device. iQ D2D is not available in the current firmware: only 0x00 (LoRaWAN) is used, and the values 0x01 and 0x02 are accepted and stored but have no effect.

Value	Description
0x00	LoRaWAN
0x01	iQ D2D
0x02	iQ D2D + LoRaWAN

Bluetooth Low Energy (BLE)

BLE Advertising

The device advertises over BLE so that it can be found and connected for local configuration and firmware updates. How it advertises depends on its LoRaWAN class, register 0xFF9F, as set when the device starts:

• Class C (the current products, as delivered): the device advertises without a time limit, every 100 to 150 ms. It advertises again after each BLE connection ends.
• Class A or Class B: the device advertises for 1 minute each time it starts advertising, every 1 to 1.2 s, then stops. It starts advertising when the device starts, see the Device Startup section of the product's Technical Reference Manual. It does not advertise again after a BLE connection ends: restart the device to advertise for another minute.

Class A and Class B are not the class of the current products. A device set to one of them by mistake can still be reached over BLE within 1 minute of a restart, for example to write 0xFF9F back to 2 (Class C) before restarting it.

Relay Support

LoRaWAN Relay support is under testing.

After testing and implementation proof of concept details will be recorded here.

Firmware Updates Over The Air (FUOTA)

FUOTA Introduction

note

FUOTA is supported by every YOBIIQ SDK product from firmware version 1.0.

In a LoRaWAN network, there are sometimes many different Internet-of-Things (IoT) devices that require regular maintenance. One issue here, for example, is the installation of new firmware. An important requirement may be to be able to perform this process remotely. LoRaWAN provides an efficient and secure method for this using multicast messages. This service is provided by a set of application layer packets. The article provides an outline of the most important aspects of Firmware Update Over-The-Air (FUOTA) and highlights three of the application layer packets in detail.

6 STEPS TO UPDATE FIRMWARE

1. Identification of the devices to be updated and classification into multicast groups.
2. Generation of a binary firmware patch file for the device platform to be updated
3. Sending the binary file to the group of devices to be updated
4. The signature to authenticate the file and its origin is verified by each device
5. Each device installs the firmware update
6. Reporting the status of the update process (success or failure) by each device

Even though the above steps are very device specific, it is possible to standardize a FUOTA process so that it works for almost any device in a LoRaWAN network.

A certain limitation is the low bit rate at which data is transmitted in a LoRaWAN network. This challenge is countered by multicast messages. These ensure that a given radio packet transmitted over the network can be received by many devices. As a result, only one transmission is sufficient to reach all devices at once.

With LoRaWAN, there are three primary application layer packets for FUOTA:

• Clock Synchronization
• Remote Multicast Setup
• Fragmented Data Block Transport

On the device side, these packets reside at the Application layer. They use the LoRaWAN MAC layer to send and receive messages to and from the network. Additionally, other packets may be present at the Application layer of the device. The first step in updating firmware on a LoRaWAN network is to identify and list the devices to be updated and add them to a LoRaWAN multicast group. This group can be created and set up dynamically.​​​​​

REMOTE MULTICAST SETUP

Each device in a LoRaWAN network is equipped with a unicast identity that is used to uniquely identify and authenticate the device on the network. Within Remote Multicast Setup, the following applications can be performed:

1. Query the implementation version of the package.
2. Query the list and status of multicast groups to which a device has been assigned.
3. Create or modify a multicast group for a specific device.
4. Delete a multicast group definition from a device.
5. Define a Class C session and associate it with a multicast group.

LoRaWAN-based devices are battery-powered and normally wake up only when they have data to transmit, then immediately go back to sleep. Therefore, to transmit a message to an entire group of devices, the system must first ensure that the receivers of all devices within the multicast group are active at the same time and for the same duration.

To synchronize the time of LoRaWAN-based devices with the time of the network, the Clock Synchronization packet is used. Once the device clocks are synchronized, the device management service must program the devices to open their receivers simultaneously and use the same radio channel and data rate. For this purpose, either a Class C or Class B multicast session can be defined using the Remote Multicast Setup package.

The Remote Multicast Setup package makes no assumptions about the content of messages transmitted by the network during a Class C or Class B multicast session. Therefore, during a multicast session, a way must be provided to efficiently fragment a file to ensure complete delivery to each device in the group. The Fragmented Data Block Transport package was created for this purpose.

FRAGMENTED DATA BLOCK TRANSPORT

The use of radio multicast transmissions greatly improves the efficiency of the network. However, the challenge is that not all data packages reach the receiver. To successfully transmit as many data packets as possible, the Fragmented Data Block Transport package implements a "forward error correction code".

The file to be sent is split into fragments of equal length and the forward error correction code is implemented so that individual fragments can be recovered to ensure transmission of the complete file. In addition, the Fragmented Data Block Transport package provides the following functions:

• Query the implementation version of the fragmentation package.
• Create a fragmentation session
• Query a device or group of devices to determine the status of a fragmentation session
• Delete a fragmentation session

Before sending a file to a device or group of devices, a fragmentation session must be created. This tells the device or devices the details of the file to be sent. Although multicast transmissions are more efficient for sending the same file to a group of devices, the fragmentation package also allows fragments to be sent over a unicast downlink. Using a unicast or multicast message, the server can query the status of each device after all encoded fragments have been sent. Additional encoded fragments can be sent to devices that have not yet been able to fully reassemble the file. These fragments can be sent as unicast downlinks, or a new multicast session can be established if too many devices have not been able to reassemble the file.

Basic Fuota

note

It should be noted that FUOTA will not be supported to all end users, YOBIIQ will select Network Service Providers on which the FUOTA functionality will be tested.

They will be listed under the Verified Network Service Providers section.

Basic Fuota

The FUOTA functionality is based on the LoRa Alliance application layer packages. Two versions of these packages are available, selected when the firmware is built:

• FUOTA V1 is fully operational and is the default.
• FUOTA V2 is available but not fully tested yet.

Package	FUOTA V1	FUOTA V2	fPort
Remote Multicast Setup (TS005)	v1.0.0	v2.0.0	200
Fragmented Data Block Transport (TS004)	v1.0.0	v2.0.0	201
Application Layer Clock Synchronization (TS003)	v1.0.0	v2.0.0	202
Firmware Management Protocol (TS006)	v1.0.0	v1.0.0	203

The FUOTA service of the network server must use the same package versions as the device. With the Firmware Management Protocol, the device reports the status of a received firmware image, and the network server can query and manage the firmware.

Within the basic fuota functionality there are a few steps that are taken (behind the scenes);

1. Synchronize the device clock AppTimeReq & AppTimeAns
2. Setup a multicase group using McGroupSetupReq & McGroupSetupAns
3. Setup a class C session using McClassCsessionReq & McClassCsessionAns
4. Setup a fragmentation session via FragSessionSetupReq & FragSessionSetupAns
5. Transfer the fragmented data. Lost fragments are recovered from the redundant fragments (forward error correction).
6. When the image is complete, report its status on fPort 203. 60 seconds later the device restarts and the bootloader checks the signature of the image before installing it. The new firmware confirms itself at its first start.

During a multicast session the device sends no other uplinks.

Configuration