Uplink LoRaWAN® packets
This topic describes reference information about uplink LoRaWAN® packets.
Uplink packets
Uplink packets are LoRaWAN® packets sent by devices to the ThingPark network, either directly or through a LoRaWAN® relay. They are represented in Wireless Logger by blue icons:
- illustrates an uplink packet received on-time by the LRC core network and successfully reported to the application destinations associated with this device. On-time means that the packet was immediately forwarded by the base station to the core network.
- illustrates an uplink packet
received late by the LRC core network (
L
stands for Late). This would be typically the case of a packet queued by the base station due to temporary network connection issue with the core network, then forwarded later on to the network after the connection was reestablished. - illustrates an uplink packet received in the
context of a passive roaming agreement with a peer LoRaWAN® network
(
R
stands for Roaming). To learn more, see Passive Roaming packets. - illustrates an uplink packet forwarded via a LoRaWAN
relay.
F
stands for "Forwarded". To learn more, see Using LoRaWAN relays.
The delivery status of the uplink packet to external application servers over HTTPS protocol is illustrated as follows:
- In case of successful reporting to all the target applications, no colored dot displays, for instance .
- When the delivery fails on the preferred destination for at least one application
server but the packet is successfully delivered to a secondary destination
associated with this same application, an orange dot displays.
- Example: , or .
- When the delivery completely fails for at least one application server, a red dot
displays.
- Example: , or .
In each case, the detailed transmission status is displayed in the expandable panel.
Displaying the transmission status towards external application servers is only applicable to applications integrated with ThingPark through the Basic HTTP type of connections (also known as NS/AS tunnel interface). It does not apply to connections using ThingPark X IoT Flow.
You can see and filter several categories of uplink packets in Wireless Logger according to their content. A frame is a packet.
Uplink packet | Content | Description |
---|---|---|
MAC frames | When an uplink packet is tagged mac only, it means that it does not contain any applicative data payload towards the application server. These packets are either uplink packets carrying only Layer-2 LoRaWAN® MAC commands and/or MAC acknowledgements to a previous downlink confirmed packet. | |
Data frames | These uplink packets contain applicative data payload that is routed towards application servers but do not contain any MAC commands. | |
MAC + Data frames | These uplink packets contain both MAC commands/acknowledgments and applicative data payload. | |
Join Request frames | These uplink packets are relevant only for OTAA devices. |
Uplink packet deduplication
Repeated uplink packets are deduplicated by the LRC network server, so they are not sent several times to application servers or TWA/Wireless Logger. Then, when a device sends the same uplink packet multiple times to the LRC network server (in case of frame repetition), only a single uplink packet is displayed in Wireless Logger.
Example If the device transmits 3 times the same uplink packet with frame counter number 39 (if number of transmissions controlled by ADR algorithm is set to 3 in this case), and if this same packet is received more than once by the network server, only the first received copy is displayed by Wireless Logger whereas other copies received for this same packet are not visible.
Receiving base stations and best-LRR
Wireless Logger can display up to ten base stations that have received the same uplink packet.
Each base station is identified by the LRR Id receiving the uplink packet and displays the associated reception radio metadata such as the RSSI, SNR and ESP. For more information, LoRaWAN® radio metrics.
When the same uplink packet is received by several base stations, ThingPark identifies the uplink best-LRR as the LRR that has received the uplink packet with the highest SNR (Signal to Noise Ratio).
For more information, see LRR table in Uplink expandable panel.
Uplink metadata columns
Metadata is a series of information related to the transmission or reception of each uplink packet. It allows you to monitor the radio conditions of each packet and the network-based MAC layer configurations.
The most important uplink metadata are directly displayed as distinct columns in Wireless Logger and are listed in the following table. For more information about other metadata displayed in the expandable panel of the packet, see Uplink expandable panel.
This set of metadata also applies to passive roaming uplinks. For more information, see Passive roaming LoRaWAN® packets.
Metadata | Description |
---|---|
Message direction | Green arrow shows the uplink packet (from the device to the network); the red arrow the downlink packet (from the network to the device). |
Message type | data indicates that the packet contains some applicative payload measured by the device (temperature, GPS coordinates and so forth...). mac indicates that the packet contains some MAC layer service commands (ADR modification and so forth…). join indicates the Join Request message (for OTAA devices). See Uplink packets for more details. |
UTC Timestamp | UTC timestamp, using ISO 8601 format. |
Local Timestamp | Timestamp translated to browser time zone, using ISO 8601 format. |
DevAddr | Device address (4bytes). |
DevEUI | Device EUI (8bytes) is a global end-device ID in IEEE EUI64 address space that uniquely identifies the end-device. If the network server acts as a forwarding network server (fNS) and the message type is data, the DevEUI is only available if LoRaWAN® Backend Interfaces version > 1.0. |
FPort | Application port of the packet. |
FCnT | Uplink frame counter. |
LRR RSSI | RSSI (Received Signal Strength Indicator) of the received uplink packet on LRR side. To learn more about RSSI definition, see RF metrics. |
LRR SNR | SNR (Signal-to-Noise Ratio) of the received uplink packet on LRR side. To learn more about SNR definition, see RF metrics. |
LRR ESP | ESP (Estimated Signal Power) of the received uplink packet on the LRR side. To learn more about ESP definition, see RF metrics. |
SF/DR | Spreading Factor or Data Rate of the uplink packet. |
Sub Band | Radio frequency sub band corresponding to the logical channel used to transmit the uplink packet by the device. |
Channel | Logical Channel used to transmit the uplink packet by the device. |
LRC Id | Identifier of the LRC network server. |
Relay Id | DevEUI of the relay that forwarded the uplink packet from the end-device. |
LRR Id | ID of the best-LRR having received the uplink packet with the highest SNR. For roaming-out use case (sNS passive roaming), the LRR Id corresponds to the identity of the best foreign gateway if this Id has been reported by fNS, otherwise a virtual LRR Id is displayed in Wireless Logger. |
LRR Lat | Latitude of the best-LRR. |
LRR Long | Longitude of the best-LRR. |
LRR GwCnt | Number of LRR gateways (LRR base stations) receiving the uplink packet. The system performs a 250ms buffering upon receiving an uplink packet to check if the same packet arrives through other LRRs, the LRR Count is then aggregated within this 250ms deduplication window. |
Device Lat / Device Long / LoS Distance (m) / Map / Trip | Respectively: Device latitude / Device longitude / Distance between the device and the best-LRR / Displays the device and the LRR base station on a map / Displays the location path of the device (if device location is available). The GPS data are filled only if the device gives its location: - Manual location: Provisioned in Device Manager application - GPS location reported by the device in the uplink payload: This option is only valid if the payload decoder is selected and the application session key (AppSKey) of the device is known to ThingPark. For more information, see Displaying decoded data payloads - Network-based geolocation: based on TDoA/RSSI geolocation algorithms. |
MIC | Message Integrity Checksum. |
Uplink expandable panel
The following elements are displayed in the expandable panel for each LoRaWAN® uplink packet. To access the expandable panel of each packet, click the left side of the packet.
This topic also applies to passive roaming uplinks. For more information, see Passive roaming LoRaWAN® packets.
Field | Description |
---|---|
Mtype | Indicates the type of message: ConfirmedDataUp, UnConfirmedDataUp, or JoinRequest: - Join Request is sent by OTAA devices to request initial access to the network. It is displayed in Wireless Logger with logo and message type (Mtype) as JoinRequest. - If the uplink packet requires an acknowledgment by the network, it is sent in CONFIRMED mode. In this case, Wireless Logger displays the message type (Mtype) as ConfirmedDataUp. - Otherwise, uplink packets can be sent in UNCONFIRMED mode, meaning that the device does not request any acknowledgment from the network on its uplink data. This corresponds to the UnconfirmedDataUp message type. |
Flags | MAC layer flags available in the Frame Header (for more details, see LoRaWAN® MAC Layer specification): - ADR: set to 1 if ADR enabled by the device, 0 otherwise. When ADR is set to 1 by the device, the device authorizes the LRC network server to optimize the uplink Spreading Factor (SF), number of transmissions and transmission power according to the ADR algorithm configured in the LRC. - ACK: set to 1 if the packet contains an acknowledgement to the previous downlink packet, 0 otherwise. - ADRACKReq: set to 1 when the device requests an acknowledgment to validate the network-controlled ADR as per LoRaWAN specifications. |
MAC (hex) | Contains the uplink MAC commands in hexadecimal format, followed by the decoded content of each MAC command. |
Data (hex) | Contains the uplink application payload in hexadecimal format. Note This payload may be hidden for sake of confidentiality. To learn more, see Displaying decoded data payloads. The payload encryption status (encrypted vs. not encrypted) is displayed between square brackets. |
Driver metadata | Metadata associated with the device profile corresponding to the device in question. This metadata allows Wireless Logger application to automatically map the device to the right payload decoder from the list of IoT Flow drivers. For more information, see Displaying decoded data payloads. |
Decoded data | Decoded applicative payload, available only when a valid payload driver exists for this device model and Wireless Logger decoder is not set to "no decoding". For more information, see Displaying decoded data payloads. |
Data size (bytes) | Size of the applicative payload in bytes. |
AirTime (s) | Time duration of the packet over the air (in seconds). |
LRR table | Reception metadata for each LRR that received the uplink packet (up to 10 LRRs), ordered from highest to lowest uplink SNR. To learn more about RSSI/SNR/ESP metrics, see RF metrics. For each LRR, the reception timestamp by each RF chain (corresponding to an RF antenna) is displayed. Note When the packet is fine-timestamped by the receiving LRR, Wireless Logger displays {GPS_RADIO} beside the timestamp, as per the following example: GWID, GWToken, DLAllowed and Foreign Operator NetID/NSID are metadata specific to passive roaming traffic. To learn more, see Passive roaming packets. Note If the packet is forwarded by a LoRaWAN relay, the relay ID (relay's DevEUI) is reported in the "Relay" column. |
Device position | Device position (Longitude/Latitude) issued from network-based geo-location, if the feature is activated for this device and the geolocation solver can resolve the device position based on TDoA/RSSI algorithms. The geolocation details provided here (radius, accuracy, velocity estimation etc.) are the same as those provided in the Location Reports. |
Reporting Status | Status of the uplink reporting to ThingPark core network: - On-time: the uplink packet was sent by LRR to LRC core network without significant delay. - Late: the uplink packet was delayed in the LRR (that means buffered) before reaching the LRC core network. This is typically due to backhaul instability or temporary outage. |
ISM Band | LoRaWAN® ISM band (also known as regional profile as per LoRaWAN Regional Parameters specification) associated with the device and its best-LRR (BestLRR or BestGWID). |
RF Region | RF region of the best base station (BestLRR or BestGWID). |
AS ID | ThingPark ID of the application server(s) which the uplink packets are routed to. |
Frequency | Physical frequency (in MHz) used by the device to transmit the uplink packet. The corresponding Logical Channel is displayed in the Channel column. |
Current Class | Current LoRaWAN® class used by the device, that is class A/B/C. Note For LoRaWAN® 1.0.x devices, class A and class C devices cannot dynamically change their class; whereas class B devices can switch between class A and class B depending on their application layer and the device synchronization status through beacon signals. |
Tags | List of administrative tags associated with the device in question, if applicable. |
Transmission Status to AS over tunnel interface | Transmission status of the report sent by the LRC to the Application Server identified by the AS ID, over the tunnel interface (also known as Basic HTTPS type of connections). Two possibles values are: Ok or Error. In case of transmission error, the related error message is displayed in the "Transmission errors" column. Note This status is only relevant for "Basic HTTP" type of connections. Delivery errors related to TPX connections are currently not visible in Wireless Logger. |
Transmission errors | Applicable only if the transmission Status is Error. Idx: Index of the destination that caused the error. Starting value at 0. Url: The destination URL that returned the error. An HTTP Application Server can be configured with several destination URLs. Status: - Timeout: The report was not successfully acknowledged by the destination within the expected time frame. - Error: The report was rejected by the destination. (HTTP error, network error, DNS error). - Overload: The report was not sent to the destination because the network server reached the OVERLOAD state and the destination's average round trip time is too bad. - Blacklist: The report was not sent to the destination because the network server reached the BLACKLIST state and the destination's average round trip time is bad. - Unreachable: The report was not sent to the destination because this destination was deemed unreachable due to irresponsive behavior over the last observation window. Note This information is only relevant for "Basic HTTP" type of connections. Delivery errors related to TPX connections are currently not visible in Wireless Logger. |
Current pingslot period | Only valid for class B devices, it defines the pingslot periodicity reported by the device when it uses class B. This field is displayed only when the device uses class B mode. |
Confirmed Application frame counter down (ConfAFCntDn) | Only valid for LoRaWAN® 1.1 devices when the uplink packet acknowledges the last downlink packet sent in confirmed mode. The downlink frame counter AFCntDown acknowledged by the device is retrieved by the LRC after MIC check procedure. |
Confirmed network frame counter down (ConfNFCntDn) | Only valid for LoRaWAN® 1.1 devices when the uplink packet acknowledges the last downlink packet sent in confirmed mode. The downlink frame counter NFCntDown acknowledged by the device is retrieved by the LRC after MIC check procedure. |