Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 3 additions & 1 deletion doc/releases/release-notes-4.0.rst
Original file line number Diff line number Diff line change
Expand Up @@ -385,10 +385,12 @@ Libraries / Subsystems
* Fixed formatting of milliseconds in :c:enum:`OS_MGMT_ID_DATETIME_STR` by adding
leading zeros.
* Added support for custom os mgmt bootloader info responses using notification hooks, this
can be enabled witbh :kconfig:option:`CONFIG_MCUMGR_GRP_OS_BOOTLOADER_INFO_HOOK`, the data
can be enabled with :kconfig:option:`CONFIG_MCUMGR_GRP_OS_BOOTLOADER_INFO_HOOK`, the data
structure is :c:struct:`os_mgmt_bootloader_info_data`.
* Added support for img mgmt slot info command, which allows for listing information on
images and slots on the device.
* Added support for LoRaWAN MCUmgr transport, which can be enabled with
:kconfig:option:`CONFIG_MCUMGR_TRANSPORT_LORAWAN`.

* hawkBit

Expand Down
2 changes: 2 additions & 0 deletions include/zephyr/mgmt/mcumgr/transport/smp.h
Original file line number Diff line number Diff line change
Expand Up @@ -148,6 +148,8 @@ enum smp_transport_type {
SMP_UDP_IPV4_TRANSPORT,
/** SMP UDP IPv6 */
SMP_UDP_IPV6_TRANSPORT,
/** SMP LoRaWAN */
SMP_LORAWAN_TRANSPORT,
/** SMP user defined type */
SMP_USER_DEFINED_TRANSPORT
};
Expand Down
3 changes: 3 additions & 0 deletions subsys/mgmt/mcumgr/transport/CMakeLists.txt
Original file line number Diff line number Diff line change
Expand Up @@ -25,6 +25,9 @@ zephyr_library_sources_ifdef(CONFIG_MCUMGR_TRANSPORT_UART
zephyr_library_sources_ifdef(CONFIG_MCUMGR_TRANSPORT_UDP
src/smp_udp.c
)
zephyr_library_sources_ifdef(CONFIG_MCUMGR_TRANSPORT_LORAWAN
src/smp_lorawan.c
)
zephyr_library_sources_ifdef(CONFIG_MCUMGR_TRANSPORT_DUMMY
src/smp_dummy.c
)
Expand Down
2 changes: 2 additions & 0 deletions subsys/mgmt/mcumgr/transport/Kconfig
Original file line number Diff line number Diff line change
Expand Up @@ -77,6 +77,8 @@ rsource "Kconfig.dummy"

rsource "Kconfig.bluetooth"

rsource "Kconfig.lorawan"

rsource "Kconfig.shell"

rsource "Kconfig.uart"
Expand Down
93 changes: 93 additions & 0 deletions subsys/mgmt/mcumgr/transport/Kconfig.lorawan
Original file line number Diff line number Diff line change
@@ -0,0 +1,93 @@
#
# Copyright (c) 2024, Jamie McCrae
#
# SPDX-License-Identifier: Apache-2.0
#

# The Kconfig file is dedicated to the LoRaWAN transport of MCUmgr
# subsystem and provides Kconfig options to control aspects of
# the transport.
#
# Options defined in this file should be prefixed:
# MCUMGR_TRANSPORT_LORAWAN_

menuconfig MCUMGR_TRANSPORT_LORAWAN
bool "LoRaWAN MCUmgr SMP transport"
depends on LORAWAN
help
Enables handling of SMP commands received over LoRaWAN.

if MCUMGR_TRANSPORT_LORAWAN

config MCUMGR_TRANSPORT_LORAWAN_FRAME_PORT
int "LoRaWAN SMP frame port"
range 1 223
default 2
help
LoRaWAN download and uplink frame port used for communication. All messages received on
this port will be treated as SMP packets.

config MCUMGR_TRANSPORT_LORAWAN_CONFIRMED_UPLINKS
bool "Use confirmed packets for uplinks"
default y
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sending confirmed uplinks is discouraged by TheThingsNetwork as the gateway downlink traffic bandwidth is very limited. Should we use unconfirmed messages by default?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This only applies to the (public) things network because they're trying to get you to pay for their commercial offering (the things industries), it does not have any relation to anything in the spec or LoRa in general

help
Will use confirmed uplink packets for responses if enabled, otherwise will use
unconfirmed packets.

config MCUMGR_TRANSPORT_LORAWAN_REASSEMBLY
bool "Reassemble LoRaWAN SMP messages"
select MCUMGR_TRANSPORT_REASSEMBLY
default y
help
Will reassemble downlink LoRaWAN messages together to allow for messages larger than a
single message to be received, otherwise will support messages up to a single packet in
size.

menuconfig MCUMGR_TRANSPORT_LORAWAN_POLL_FOR_DATA
bool "Send empty packet if partial packet received"
depends on MCUMGR_TRANSPORT_LORAWAN_REASSEMBLY
default y
help
Will send an empty packet if a partial (fragmented) message has been received from the
server, this will allow the next packet to be received without waiting for next
transmission window.

Note: this requires a dedicated thread in order to prevent blocking the system workqueue.
Comment on lines +46 to +55
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is an FPending flag for downlink messages for exactly this purpose. Can we not use that instead?

Quote from the spec:

4.3.1.4 Frame pending bit (FPending in FCtrl, downlink only)
The frame pending bit (FPending) is only used in downlink communication, indicating that
the network has more data pending to be sent and therefore asking the end-device to open
another receive window as soon as possible by sending another uplink message.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see how that would work any differently? If the flag is set, you still all the same code, the way it is right now means it only sends an empty frame if there is outstanding data for the current MCUmgr packet which in my mind is all this should handle, something non-MCUmgr can be retrieved by the application code

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought the LoRaWAN stack would handle the FPending flag automatically, but it doesn't seem to be the case. I agree your implementation makes sense.


if MCUMGR_TRANSPORT_LORAWAN_POLL_FOR_DATA

config MCUMGR_TRANSPORT_LORAWAN_POLL_FOR_DATA_STACK_SIZE
int "Poll thread stack size"
default 1800
help
Stack size of the thread that will poll for empty additional packets when a partial
frame is received.

config MCUMGR_TRANSPORT_LORAWAN_POLL_FOR_DATA_THREAD_PRIORITY
int "Poll thread priority"
default 3
help
Priority of the thread for polling for empty additional packets when a partial frame
is received.

config MCUMGR_TRANSPORT_LORAWAN_POLL_FOR_DATA_RETRIES
int "Poll thread retries"
default 3
help
Number of LoRaWAN message send retries if sending fails for the thread for polling for
empty additional packets when a partial frame is received.

endif # MCUMGR_TRANSPORT_LORAWAN_POLL_FOR_DATA

config MCUMGR_TRANSPORT_LORAWAN_FRAGMENTED_UPLINKS
bool "Fragment uplink messages"
default y
help
Will fragment messages into multiple uplink messages if they are too big to fit into a
single uplink message. If disabled then uplinks that are too large will not be sent.

module = MCUMGR_TRANSPORT_LORAWAN
module-str = LoRaWAN MCUmgr SMP transport
source "subsys/logging/Kconfig.template.log_config"

endif # MCUMGR_TRANSPORT_LORAWAN
Loading
Loading