Device attributes
tip
In ThingPark's user interface, editable fields are displayed with grey background.
General attributes
| Attribute | Definition |
|---|---|
| Name | Friendly name of your device. - It is given during the initial declaration of the device on ThingPark, but can be changed any time from the device's detailed dashboard. - You may search devices by their name on ThingPark's user interface. - The device name is reported to third party applications in the LoRaWAN packet metadata, alongside the DevEUI and the DevAddr. |
| DevEUI | Globally-unique identifier of the device. - A DevEUI is composed of 32 hexadecimal digits (0 to 9, and A to F). It is usually written on the device casing. - The first 6, 7 or 9 digits identify the device manufacturer (all LoRaWAN® device vendors must buy an IEEE OUI block from IEEE). - Example: F0-3D-29-00-0B-B1-7A-AA |
| DevAddr | The Device address consists of 8 hexadecimal digits, acting as a short identifier in the LoRaWAN® network. - For OTAA devices, DevAddr is allocated by the Network Server during the Join procedure. - For ABP devices, DevAddr is directly personalized at manufacturing, then set in ThingPark when the device is added to the system. - The most significant bits of the DevAddr identify the LoRaWAN® network ID (NwkID), which is derived from the operator's NetID. - Example: 00-AB-C4-89 |
| Manufacturer | The device manufacturer is set by the device manager in the system. If the manufacturer is unknown, it may be set to Generic. |
| Model | The Model allows associating each device with the adequate technical profile that defines the following information about each model: - A set of LoRaWAN parameters: such as the LoRaWAN version and class, the supported MAC commands etc. - The device capabilities: such as the supported TxPower range etc. - The driver metadata allowing to associate each model with the right payload driver. - The model image Device managers may change the Model associated with existing devices at any time without re-provisioning them in the system. |
| ISM band | Defines the regional profile of the device, such as EU868 or US915 or AS923 etc. In the detailed dashboard of each device, the ISM band is displayed beside the Model in the Information widget. |
| Motion Indicator | Speed of the device movement, set when the device is added to the system and editable at any time by the device manager. Example If the device tracks a parcel, you should set "vehicle speed". By default, the motion indicator takes the value configured in the technical profile associated with this Model. The motion indicator is used to: - Determine whether the selection of the best-serving base station for downlink transmission shall be based on the history of the last packets received by the network (relevant for near-static motion indication) or shall only rely on the very last packet received by the network (relevant for other mobility profiles). - Enhance the network geolocation accuracy. |
| Tags | Each device may be associated with one or several tags. Tags may serve various purposes: - Administrative tags, to easily group objects and filter them accordingly. - Segregated processing by Application Servers, since device tags are reported as metadata in uplink reports sent to AS. |
| Domains | If the segregation based on domains has been enabled by an administrator, the Domains attribute contains the list of domains associated with the device. If your user account has domain restrictions, the domains you associate with your device must match your domain restrictions without any domain prefix (only full domains can be assigned to resources). See About domains for more details. |
| Connections | List of connections used to route the device traffic to external Application Servers. - It may be edited at any time by the device manager. - A device may be associated with multiple Connections (up to 5 by default). - If the device is not associated with any Connection, its traffic is only visible in the device dashboard and in Wireless Logger, without being routed to any external Application Server. To learn more about the different Connection types, see Connecting an application. |
| Connectivity Plan | A Connectivity Plan (CP) defines a set of parameters associated with each device and determining its service profile, such as - the type of LoRaWAN communication: unicast or multicast - the activation status of value-added services, like roaming and network geolocation - the QoS targets to be achieved by ThingPark ADR, such as the target uplink Packet Error Rate (PER), set to 10% by default. Each ThingPark Enterprise subscription is associated with 4 system-default unicast Connectivity Plans, defining the 4 activation combinations of roaming and geolocation features. TPE-SaaS subscriptions support 2 modes: - Implicit (basic) mode: this is the default mode, whereby Connectivity Plans are hidden and replaced by the Roaming and Network Geolocation activation flags. - Explicit (advanced) mode: this mode is available only for subscriptions that are configured to use customized Connectivity Plans besides the default ones. This mode is required only for customers having specific deployment use cases that require fine-tuning of the technical LoRaWAN settings included in the Connectivity Plan. Self-hosted TPE use exclusively the implicit/basic CP mode, hence Connectivity Plans are hidden in the user interface. |
| Location Mode | Technique used to locate the device. It may be changed at any time by the device manager. You can choose among the following modes: - No location, if the location of the device does not matter. - Manual, the device location (latitude and longitude) is manually set by the device manager, using one of the following options: * Either via the Search box on the top of the map, * or by directly placing the marker on the map, * or by setting the latitude and longitude in text input below the map. The compass button allows switching between decimal and degree/minute/second formats. - Network geolocation, the device is geo-located by the network via triangulation techniques. This mode is particularly interesting to track moving devices, but it may also be used for stationary devices. To use network geolocation, the device must be covered by at least three base stations. If this is not the case, activating this feature is not recommended to avoid excessive draining of the device battery. |
| Driver | Designates the payload driver used to decode application payloads of the device. Each driver is associated with metadata, split into 2 parts: - The model Identifier is a string identifying the device model, like abeeway:micro-tracker:2 - The Protocol Identifier is a block of information composed of Protocol Manufacturer, Protocol Name and Protocol Version. Example: abeeway:asset-tracker:2 There are 2 types of payload drivers (with their respective Protocol Identifiers): - Built-in: inherited from the device Model, they identify system drivers included in ThingPark's off-the-shelf driver catalog. - Custom: they identify custom drivers created by the user in TPX IoT Flow. |
| Payload Encryption | Designates the encryption policy of the application payload: - Radio encrypted means that the payload is only encrypted on the radio interface, then it is decrypted by ThingPark and reported in clear form to the application server. - End-to-end encrypted means that the payload is encrypted on the radio interface and reported encrypted to the application without being decrypted by ThingPark. This mode implies associating the device with an Application Server Transport Key (ASTK) and requires a Hardware security module (HSM) either collocated with the local Join Server or embedded with ThingPark Activation service. |
| Application Server Transport Key (ASTK) | Key-encryption-key used to encrypt the AppSKey between the Hardware Security Module (HSM) and the Application Server when an OTAA device uses the end-to-end encryption mode. At any time, associating (or dissociating) a device with an ASTK automatically activates (respectively deactivates) the end-to-end encryption mode. However, the change takes effect only on the next join cycle of this device. Associating a device with an ASTK to provide end-to-end encryption is only possible for OTAA devices activated on external Join Server (specifically ThingPark Activation). In this case, the ASTK association with the device is directly done in ThingPark Activation. |
| Added | Date/time of the device addition to your ThingPark account. |
| Additional information | Any useful administrative information related to the device (free text). It may be changed anytime by the device manager. |
LoRaWAN-specific attributes
| Attribute | Definition |
|---|---|
| NetID | 24-bit network identifier assigned to LoRaWAN networks by the LoRa Alliance. To learn more, see LoRaWAN NetID. |
| LoRaWAN Class | LoRaWAN® class of the device: A, B or C. - It is retrieved from the technical information associated with the Model (device profile). - Class-B-capable devices have their class set to class B only when they report this flag in the LoRaWAN MAC header of their uplink packets, otherwise their class is set to class A. |
| Activation Mode | Defines how the device is activated on the LoRaWAN network: either ABP or OTAA with local Join Server or OTAA with external Join Server. To learn more, see Activation modes. |
| AppKey | Root key for OTAA devices (not relevant for ABP devices). The Application Key is an AES-128 key specific for each OTAA end-device, programmed in factory by the device manufacturer. It is composed of 32 hexadecimal digits (0 to 9, and A to F) and used to derive the session keys that allow LoRaWAN® to secure the communication with the Network Server and the Application Server. - For OTAA devices activated with a local Join Server: the AppKey must be provisioned when adding the device to ThingPark. It is provided by the device manufacturer when you purchase the device. - For OTAA devices activated with an external Join Server: the AppKey is directly set by the device manufacturer in the Join Server, where it is securely stored. Device owners do not need to provision AppKey in ThingPark Enterprise, they only need to provide the proof of ownership (known as the Owner Token) when adding devices to their subscription. |
| JoinEUI (AppEUI) | Identifies the Join Server (JS) for OTAA devices (not relevant for ABP devices). - Global application ID that uniquely identifies the Join-Server that is able to assist in the processing of the Join procedure and the derivation of session keys. - It consists of 16 hexadecimal digits (0 to 9, and A to F) and is provided by the device manufacturer. - In LoRaWAN's early days, this ID was called "AppEUI". - The JoinEUI is included in the Join Request message, but it must be provisioned in ThingPark for OTAA devices activated with an external Join Server, since this information is required to claim the device ownership in the JS on behalf of the device owner, using the Owner Token. |
| Owner Token | Acts as a proof of ownership for OTAA devices activated on an external Join Server. - This token is provided by the device manufacturer after pre-commissioning the device on the external Join Server, ThingPark Activation for instance. - It is typically included in the LoRaWAN-standard QR code printed on the device sticker. To learn more, see Activation QR codes. - Thanks to the Owner Token, the network server can execute the claim procedure in the Join Server on behalf of the device owner. To learn more, see Seamless integration with ThingPark Activation. |
| NwkSKey | Network Session Key, relevant only for LoRaWAN 1.0 devices. - Composed of 32 hexadecimal digits (0 to 9, and A to F). - It is used in data integrity and encryption of MAC commands sent on Fport 0. - For OTAA devices, this session key is generated with each Join cycle, it cannot be pre-configured in ThingPark. - For ABP devices, this key is personalized by the device manufacturer in factory and should be provided to the device owner to provision it when adding the ABP device in ThingPark. |
| AppSKey | Application Session Key, relevant for all LoRaWAN devices. - Composed of 32 hexadecimal digits (0 to 9 and A to F). - It is used to encrypt the application payload over the air. - For OTAA devices, this session key is generated with each Join cycle, it cannot be pre-configured in ThingPark. - For ABP devices, this key is personalized by the device manufacturer in factory and should be provided to the device owner to provision it when adding the ABP device in ThingPark. |
| NwkKey | Network Key, only relevant for LoRaWAN 1.1 OTAA devices. - AES-128 key specific for each LoRaWAN 1.1 OTAA end-device, programmed in factory by the device manufacturer alongside AppKey. - It is composed of 32 hexadecimal digits (0 to 9, and A to F) and provided by the device manufacturer. - Used as root key to encrypt the device communication with the Network Server, by deriving network-related session keys: FNwkSInKey, SNwkSIntKey and NwkSEncKey. |
| FNwkSIntKey | Forwarding Network Session Integrity Key, relevant only for LoRaWAN 1.1 devices. - Composed of 32 hexadecimal digits (0 to 9, and A to F). - It provides integrity protection to roaming devices. - For OTAA devices, this session key is generated with each Join cycle, it cannot be pre-configured in ThingPark. - For ABP devices, this key is personalized by the device manufacturer in factory and should be provided to the device owner to provision it when adding the ABP device in ThingPark. |
| SNwkSIntKey | Serving Network Session Integrity Key, relevant only for LoRaWAN 1.1 devices. - Composed of 32 hexadecimal digits (0 to 9, and A to F). - It provides integrity protection, through the Message Integrity Code (MIC). - For OTAA devices, this session key is generated with each Join cycle, it cannot be pre-configured in ThingPark. - For ABP devices, this key is personalized by the device manufacturer in factory and should be provided to the device owner to provision it when adding the ABP device in ThingPark. |
| NwkSEncKey | Network Session Encryption Key, relevant only for LoRaWAN 1.1 devices. - Composed of 32 hexadecimal digits (0 to 9, and A to F). - It is used to encrypt MAC commands between LoRaWAN 1.1 end-devices and the Network Server. - For OTAA devices, this session key is generated with each Join cycle, it cannot be pre-configured in ThingPark. - For ABP devices, this key is personalized by the device manufacturer in factory and should be provided to the device owner to provision it when adding the ABP device in ThingPark. |
Dynamic attributes (related to device operation)
| Attribute | Definition |
|---|---|
| Health state | This attribute describes the current status of the device. See health states for more details. |
| Last uplink | Timestamp of the last uplink packet received by the network from the device (excluding repeated uplink packets). |
| Last downlink | Timestamp of the last downlink packet sent to the device. |
| Packets (24h) | Aggregated count of distinct uplink + downlink packets exchanged with the device over the last 24 hours. Note Uplink repetitions are not counted. |
| Average SNR | Average Signal to Noise Ratio (in decibels, dB), measured by each LoRaWAN base station when receiving uplink packets. - SNR determines the quality of reception, the typical range for LoRaWAN® is [-20, +15 dB]. To learn more, see Signal to Noise Ratio. - To mitigate measurement fluctuation caused by RF signal fading, the SNR associated with the device status in ThingPark is averaged over the last 5 uplink packets. |
| Average RSSI | Received Signal Strength Indicator (in dBm), measured by each LoRaWAN base station when receiving uplink packets. - RSSI measures the total RF power received on a given RF channel, summing up the desired LoRaWAN® signal and the background noise. To learn more, see Received Signal Strength Indicator. - To mitigate measurement fluctuation caused by RF signal fading, it is recommended to compute an average RSSI over at least 5 uplink packets. |
| Average ESP | Estimated Signal Power of uplink packets (in dBm). - ESP is an estimate of the LoRaWAN® useful signal power, computed from SNR and RSSI measurements reported by each base station. To learn more, see Estimated Signal Power. - To mitigate measurement fluctuation caused by RF signal fading, the ESP associated with the device status in ThingPark is averaged over the last 10 uplink packets. |
| Long-term Packet Error Rate (PER) | The long-term Packet Error Rate (PER) (also called "Mean PER") is computed over the full history of the last distinct uplink packets, as follows: Long-term PER = 1 - [Distinct_Pkts / (FCntUP(N) - FCntUP(M) + 1)], where: * Distinct_Pkts is the number of distinct uplink packets stored in the last packets history (the history may contain up to the last 50 uplink packets). * FCntUp(N) is the FCntUp of the newest uplink packet in this history list. * FCntUp(M) is the FCntUp of the oldest uplink packet in this history list. Note A device reset/rejoin resets the Long-term PER to 0. |
| Instant Packet Error Rate (PER) | The instantaneous PER is computed over the 2 last distinct uplink packets as follows: Instant PER = 1 – [ 2 / (FCntUp(N) - FCntUp(N-1) + 1)], where: * FCntUp(N) is the FCntUp of the last uplink packet * FCntUp(N-1) is the FCntUp of the previous uplink packet (excluding repetitions). Example If the two last received uplink packets have FCntUp 33 and 36, then InstantPER = 1 - [2/(36-33+1)] = 0.5 = 50% (because frames 34 & 35 were missing, so 4 packets were expected but only 2 were received). Note A device reset/rejoin resets the Instant PER to 0. |
| Last Spreading Factor (SF) | Designates the LoRaWAN® Spreading Factor used for the last uplink packet received from the device. The Spreading Factor determines the data rate used during transmission. - LoRaWAN® SF range is [7 - 12]: SF7 corresponds to the fastest data rate (~5.5 kbits/sec) while SF12 corresponds to the slowest data rate (~300 bits/sec). |
| Best LRR ID | ID of the base station acting as best-server for the device. For a same device, the best server may be different between uplink and downlink packets: - For uplink packets: the best server designates the base station having received the last uplink packet of this device with the highest SNR. - For downlink packets: the best server designates the base station offering the best RF link budget to the device. Depending on the motion indicator of each device, the derivation of the DL best server may rely on the history of the last packets instead of only relying on the very last packet. |
| Best relay | DevEUI of the device used as LoRaWAN relay to serve this end-device. Only valid if the device uses the relay protocol. |
| Active alarms | Number of alarms - split by severity - currently raised on this device and not yet acknowledged. To learn more, see Device alarms. Tip Click on a colored alarm badge to access the list of corresponding active and not-acked alarms. |
| Location history | Designates all location details for the seven days before the last reported location. It is only available if the location mode is Network Geolocation. It is expressed by the following data: - Date of the geolocation - Computed latitude and longitude - Geolocation precision (meters) - Computed altitude and its precision (in meters) - Computed moving speed (meters per second) and the moving direction relative to the North (degrees). |
Device health states
A device may go through different health states, as depicted in the following figure:
A color code is used to identify the health state of each device, it is visible on:
- the devices dashboard,
- the device list, as a colored bullet alongside the device logo,
- the devices map, as a colored marker.
| Health state | Color | Description |
|---|---|---|
| Active | Green | The device is properly commissioned and successfully exchanges packets with the network server. |
| Initialization | Orange | The device has not completed its activation or reactivation process, or has just been resumed after being administratively suspended. |
| Connection Error | Red | The device is commissioned and has communicated in the past, but no longer communicates or does not match the expected communication pattern. It needs attention (for instance, check the device battery). If the device is no longer used, you can decommission it. To troubleshoot the absence of uplink activity, see No uplink activity 004. |
| Suspended | Light blue | The device has been administratively suspended and all its packets are ignored by the network server. To learn more, see Suspending a device. |