Device attributes

tip

In ThingPark's user interface, editable fields are displayed with grey background.

General attributes

Common 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 packet metadata, alongside the DevEUI and the DevAddr.
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 protocol 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.
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.
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 only applicable to LoRaWAN® devices 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.
Added	Date/time of the device addition to your ThingPark account.
Device Topic Path	Custom MQTT topic path segment(s) used to resolve topic templates for this device in associated basic MQTT connections. This field is displayed only if the device is associated with at least one basic MQTT connection. The value may contain one or multiple topic levels separated by /. It can also represent the full MQTT topic when used with a topic template containing only {DeviceTopicPath}. The value must match the following regular expression: ^[^#+/](?:/[^#+/])*$.
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
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
Device address	The device address (DevAddr) consists of 8 hexadecimal digits, acting as a short identifier in the LoRaWAN® network. For OTAA devices, the device address is allocated by the Network Server during the Join procedure. For ABP devices, the device address is directly personalized at manufacturing, then set in ThingPark when the device is added to the system. The most significant bits of the device address identify the LoRaWAN® network ID (NwkID), which is derived from the operator's NetID. Example: 00-AB-C4-89
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.
Connectivity plan	A Connectivity plan (CP) defines a set of parameters associated with each device and determining its service profile, such as 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.
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 The Protocol Identifier is a block of information designating the protocol used in encoding/decoding. To learn more, see Payload drivers
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.
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.

Cellular-specific attributes

Attribute	Definition
DevEUI	Globally-unique identifier of the device. A DevEUI is composed of 32 hexadecimal digits (0 to 9, and A to F). It is generated by thingPark and starts with F0-3D-29-00. For backward compatibility purposes, the IMEI is used as DevEUI for cellular devices provisioned prior to ThingPark 8.0. Example: F0-3D-29-00-0B-B1-7A-AA
Device address	The device address consists of the device's IPv4 address. The device address is allocated according to the network context's IPv4 configuration. Example: 192.168.3.130
Enforced IMEI	International Mobile Equipment Identity of the physical device. An IMEI is composed of 15 digits (14 digits + 1 digit for Luhn checksum). When configured, the IMEI is enforced and any traffic corresponding to another IMEI is rejected for this device.
SIM identifier	IMSI, ICCID or eID depending on the SIM type. To learn more, see SIM types.
Network context	A network context manages the IPv4 connectivity the device and defines the communication modes. To learn more, see Managing network contexts.
Connectivity plan	A Connectivity plan (CP) defines a set of parameters associated with each device and determining its service profile, such as the allowed communication modes: message mode and/or direct IP mode the message mode traffic policy parameters: token bucket regulators for uplink and downlink packets the direct IP mode traffic policy parameters: maximum uplink and downlink bandwidth.

Dynamic attributes (related to device activity)

Common attributes

Attribute	Definition
Health state	This attribute describes the current status of the device. See health states for more details.
Packets for the last 24 hours	Aggregated count of distinct uplink + downlink packets exchanged with the device over the last 24 hours. Note Uplink repetitions are not counted.
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.

LoRaWAN-specific attributes

Attribute	Definition
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.
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.
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).

Cellular-specific attributes

Attribute	Definition
Last message mode uplink	Timestamp of the last message mode uplink packet received by the network from the device.
Last message mode downlink	Timestamp of the last message mode downlink packet sent to the device.
Last direct IP traffic	Timestamp of the last microflow event reported for the direct IP traffic of the device.
Radio access type	Technology used by the device to connect to the cellular network.
Cell ID	Globally unique identifier of the cellular base station.
Cell MCC MNC	Mobile Country and Network Code of the operator operating the cellular base station.
Cell TAC	Tracking Area Code of the cellular base station.
Serving network MCC MNC	Mobile Country and Network Code of the operator of the serving network.
IMEI	International Mobile Equipment Identity of the last packet. If no enforced IMEI is configured, any IMEI is accepted (the SIM can be used in different physical devices).
IMSI	International Mobile Subscriber Identity of the last packet.
MSISDN	Mobile Station International Subscriber Directory Number of the last packet.

Device health states

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.

The possible transitions for a LoRaWAN® device are depicted in the following figure:

The possible transitions for a cellular device are depicted in the following figure: