TP Enterprise 5.2.2 - Rev2 SAAS User Guide

Actility ThingPark Enterprise
Software as a Service
User Guide
Under NDA
NOTICE
This document contains proprietary and confidential material of ACTILITY SA. This document
is provided under and governed by either a license or confidentiality agreement. Any
unauthorized reproduction, use, or disclosure of this material, or any part thereof, is strictly
prohibited.
The material provided in this document is believed to be accurate and reliable. However, no
responsibility is assumed by Actility SA for the use of this material. Actility SA reserves the
right to make changes to the material at any time and without notice. This document is
intended for information and operational purposes only. No part of this document shall
constitute any contractual commitment by Actility SA.
© 2019 ACTILITY SA. All rights reserved.
Portions of this documentation and of the software herein described are used by permission
of their copyright owners.
Actility, ThingPark, are registered trademarks of Actility SA or its subsidiaries may also be
registered in other countries.
Other denoted product names of Actility SA or other companies may be trademarks or
registered trademarks of Actility SA or its subsidiaries, or their respective owners.
Headquarters
Actility Lannion,
Actility S.A 4 rue Ampère BP 30225
22300 Lannion France
www.actility.com
Under Non-Disclosure Agreement

Actility S.A. au capital de 1 122 916 € - 4 rue Ampère, 22300 Lannion, France
RCS St Brieuc 522 305 473, Siret 522 305 473 00012, TVA FR62522305473
TP_Enterprise_5.2.2_-rev2_SAAS_User_Guide 2
VERSIONS
Version Date Author Details

01 2017/06/15 ML Ancelle Initial Version
02 2017/07/07 ML Ancelle Version of TPE for 4.2 Release
03 2017/08/02 ML Ancelle Editorial changes regarding the Wireless Logger
04 2017/08/09 ML Ancelle ▪ Additional changes from Version 4.2
▪ Version of TPE for 4.3 Release
05 2018/01/05 ML Ancelle Version of TPE OCP for 4.3.1 Release

06 2018/04/12 ML Ancelle Version of TPE OCP for 5.0 Release
07 2018/11/27 ML Ancelle Version 2 of TPE OCP for 5.0 Release
09 2019/06/06 ML Ancelle Version of TPE OCP for 5.1.5 Release updated
11 2019/10/31 ML Ancelle Version of TPE SaaS for 5.2.2 Release
12 2019/11/25 ML Ancelle Version of TPE SaaS for 5.2.2 Release – Revision 2
REFERENCE INFORMATION
Documents Author
R1 ThingPark Enterprise Installation and Configuration Guide N Boulahya
R2 ThingPark Enterprise LRC-AS Tunnel Interface Developer Guide LoRaWAN® S. Dufour

WHAT’S NEW
New/Enhanced For More Information, See… Release

Functionalities
A Device model must be ▪ 8.3 Importing Devices in 2 steps 5.1.5
available to the subscriber
for mass import (RDTP-
8481)
▪ LRR Software upgrade ▪ 6.5.6 Base Station Status

5.2.2
▪ The backup and

▪ 6.5.7.2 Using the Backup Procedure
restoration of the LRR
software and
configuration allow the
▪ 6.5.7.3 Using the Restore Procedure
rollback to the previous

version (RDTP-4777)
An LRR software upgrade

depends on the firmware and
▪ 6.3.2 Activating A Base Station in 2 Steps 5.2.2
the Field-Programmable Gate ▪ 6.5.1 Overview
Array (FPGA) that are
installed on the Base Station
▪ 6.5.2 Main Parameters and Definitions
Related to Base Station management
(RDTP-7849)
▪ 6.5.3 Updating the Base Station
Information
▪ 6.5.6 Base Station Status

MQTT application is
supported on ThingPark
▪ 7.2 Application Parameters 5.2.2
Enterprise. It is used to ▪ 7.3.5 Connecting to an MQTT Protocol-
publish uplink messages from based Application
ThingPark Enterprise into an
MQTT queue and subscribe
to that queue in order to
retrieve downlink messages
(RDTP-4234).
License and catalogs ▪ 10.2 Managing the License 5.2.2
▪ 10.4 Managing Catalogs
Amazon AWS Applications

fully support the SSL protocol
▪ 7.3.2 Connecting to Amazon AWS IoT 5.2.2
Platform
(RDTP 7321)

Functionalities
▪ Support of TWA alarm’s ▪ 10.6.2 Concepts 5.2.2
refactoring (RDTP-
4544)
▪ Management of alarm’s
occurrences (RDTP-
9073)
Login and Licenses ▪ 4 Logging-in ThingPark Enterprise 5.2.2 SaaS

▪ 10.2 Managing the License
▪ 10.6.3 Definitions
▪ 10.6.9 Creating Notifications

Public Key Authentication
using the Key Installer (RDTP
▪ 6.1 Overview 5.2.2 SaaS
7582) ▪ 6.3.2 Activating A Base Station in 2 Steps
▪ 6.5.8 Activating Public Key Authentication

Presentation of ThingPark
Enterprise for a SaaS
▪ 2 ThingPark Enterprise 5.2.2 SaaS
solution
Number of Base Stations
available in the license size
▪ 4.1.2 Required Licenses 5.2.2 SaaS
changed ▪ 7.1.1 Supported Applications Limitations -
removed
For more information about earlier, new and enhanced functionalities implemented in this
document, see What’s New History.

ACRONYMS AND DEFINITIONS
Acronym Definition
AS Application Server
AS Key Application Server Key
BS Base Station
DC Duty Cycle
DevAddr Device Address in the network
DevEUI Unique Address of the Device
End Device A sensor or an actuator
ESP Estimated Signal Power
FCNT Frame Counter
FSK Frequency Shift Keying
HTTP Hypertext Transfer Protocol
IoT Internet of Thing
IPsec Internet Protocol Security (IPsec)
KPI Key Performance Indicator
LC Logical Channel
®
LoRa Long Range
LoRaWAN® Long-Range Wide Area NW
LRC Long-Range Controller
LRR Long-Range Relay
LRR ID Base Station Identifier - Unique Identifier on the Network
LRR UUID Long-Range Relay Universal Unique IDentifier
MAC layer Media Access Control layer
MQTT Message Queuing Telemetry Transport
NS Network Server
NOC Network Operations Center
OCP On Customer Premises
TNP Time synchronization using Network Synchronization Protocol
PER Packet Error Rate
PKI Public Key Infrastructure
RF Region Radio Frequency Channel Plan
RSSI Received Signal Strength Indicator
SaaS Software as a Service

Acronym Definition
SF Spreading Factor
SNMP Single Network Management Protocol
SMTP Simple Mail Transfer Protocol
SNR Signal to Noise Ratio
SSL Secure Sockets Layer
SW Software
TCP Transmission Control Protocol
TPE ThingPark Enterprise
UL/DL packets Uplink/Downlink packets
Wi-Fi Wireless local area networking
WSS Web Services Security

TABLE OF CONTENTS
NOTICE ................................................................................................................................. 2
VERSIONS.............................................................................................................................. 3
WHAT’S NEW ........................................................................................................................ 4
ACRONYMS AND DEFINITIONS ............................................................................................... 6
TABLE OF CONTENTS ............................................................................................................. 8
1 SCOPE ................................................................................................................ 14
2 THINGPARK ENTERPRISE ..................................................................................... 15
3 CREATING THE IOT NETWORK ............................................................................. 17
4 LOGGING-IN THINGPARK ENTERPRISE ................................................................. 18

4.1.1 Prerequisites .................................................................................... 18
4.1.2 Required Licenses ............................................................................. 18
4.1.3 First time log-in ................................................................................ 18
5 DEFAULT DASHBOARD ........................................................................................ 20
5.1 What can you find in the Dashboard? .............................................................. 20
5.1.1 Top Bar Area ..................................................................................... 21
5.1.2 Left Menu Bar ................................................................................... 22
5.1.3 Center Pane ...................................................................................... 22
5.1.4 Color codes ....................................................................................... 23
5.1.4.1 Color Codes used for Base Stations............................................................. 23
5.1.4.2 Color Codes used for Devices ...................................................................... 23
5.1.4.3 Color Codes used for Applications .............................................................. 24
5.1.5 Buttons ............................................................................................. 24
5.1.6 Accessing Network Elements ............................................................. 24
5.2 Using the Tablet Version of ThingPark Enterprise ........................................... 25
5.3 Using My Profile ............................................................................................... 25
5.3.1 Overview .......................................................................................... 25
5.3.2 Prerequisites .................................................................................... 25
5.3.3 Filling in My Profile ........................................................................... 26

5.3.3.1 Password Policy ........................................................................................... 26
5.4 Using Contact us ............................................................................................... 27
5.4.1 Overview .......................................................................................... 27
5.4.2 Prerequisites .................................................................................... 27
5.4.3 Filling in Contact us .......................................................................... 27
6 ACTIVATING A BASE STATION TO YOUR IOT NETWORK ........................................ 29
6.1 Overview ........................................................................................................... 29
6.2 Securing Base Station Access to Cloud Backend .............................................. 29
6.2.1 Main Concept ................................................................................... 29
6.2.2 Workflow .......................................................................................... 29
6.2.3 Reinforcing Security Using Private/Public Keys .................................. 30
6.2.3.1 Case 1 – When provisioning a new Base Station......................................... 31
6.2.3.2 Case 1 - When Activating the Feature on an existing Base Station ............ 31
6.3 Activating a new Base Station .......................................................................... 32
6.3.1 Prerequisites .................................................................................... 32
6.3.2 Activating A Base Station in 2 Steps .................................................. 32
6.3.2.1 Getting the LRR UUID and the Public Key Using SUPLOG via SSH ............... 33
6.3.2.2 Activating the Base Station Using
the ThingPark Enterprise User Interface ..................................................... 35
6.4 Viewing Base Stations....................................................................................... 39
6.4.1 Overview .......................................................................................... 39
6.4.2 Description of Base Station Parameters ............................................ 39
6.4.3 Viewing all Base Stations .................................................................. 40
6.4.4 Viewing a single Base Station ............................................................ 40
6.5 Managing Base Stations ................................................................................... 41
6.5.1 Overview .......................................................................................... 41
6.5.2 Main Parameters and Definitions
Related to Base Station management ................................................ 41
6.5.3 Updating the Base Station Information ............................................. 45
6.5.4 Duplicating a Base Station ................................................................. 47
6.5.5 Deleting a Base Station ..................................................................... 47
6.5.6 Base Station Status ........................................................................... 47
6.5.6.1 Restarting the Base Station ......................................................................... 49
6.5.6.2 Scanning the Radio ...................................................................................... 49
6.5.7 Performing Advanced Maintenance Operations
and Troubleshooting Tasks on a Base Station .................................... 50
6.5.7.1 Using the Remote Access ............................................................................ 50
6.5.7.2 Using the Backup Procedure ....................................................................... 50
6.5.7.3 Using the Restore Procedure ...................................................................... 50
6.5.8 Activating Public Key Authentication ................................................. 51
6.5.8.1 Activating the Public Key using SUPLOG via SSH......................................... 51
6.5.8.2 Adding the new Public Key Using the ThingPark Enterprise
User Interface .............................................................................................. 51
6.5.9 Managing the Security Certificate ..................................................... 53
6.5.10 Modifying the Location of the Base Station ....................................... 54
6.5.11 Checking the Radio Traffic History of the Base Station ...................... 56
6.5.12 Checking IP Address and Connectivity ............................................... 57
6.5.13 Checking the Backhaul Network Traffic Profile .................................. 57
6.5.14 Checking the LoRaWAN ® Data Rate/Spreading Factor Distribution .... 58
6.5.15 Checking the RF Signal Strength, Background Noise and Duty Cycle ... 59
6.5.16 Checking the System Load ................................................................. 60
7 CONNECTING AN APPLICATION TO YOUR IOT NETWORK ..................................... 61
7.1 Overview ........................................................................................................... 61
7.2 Application Parameters .................................................................................... 61
7.3 Connecting Applications ................................................................................... 61
7.3.1 Connecting to an HTTPS Application Server ....................................... 61
7.3.1.1 Required Parameters .................................................................................. 62
7.3.1.2 Connecting an HTTPS Application in 2 Steps .............................................. 62
7.3.2 Connecting to Amazon AWS IoT Platform .......................................... 65
7.3.2.1 Prerequisites and Required Parameters ..................................................... 65
7.3.2.2 Connecting an Amazon AWS IoT Application in 2 Steps ............................. 67
7.3.2.3 Changing the Protocol of the Amazon AWS Connection after Creation ..... 70
7.3.3 Connecting to Microsoft Azure Cloud Computing Service (IoT Hub) ... 70
7.3.3.2 Connecting to an Azure IoT Hub Application in 2 Steps.............................. 70
7.3.4 Connecting to a Beta IBM Watson IoT Platform ................................. 72
7.3.4.2 Connecting to a Beta IBM Watson IoT Application in 2 Steps .................... 73
7.3.5 Connecting to an MQTT Protocol-based Application .......................... 75
7.3.5.2 Connecting to an MQTT Protocol-based Application in 2 steps ................. 76
7.4 Managing Applications ..................................................................................... 78
7.4.1 Viewing all Applications .................................................................... 78
7.4.2 Viewing/editing an Application ......................................................... 79
7.4.3 Checking the Deployment Status ....................................................... 79
7.4.4 Switching off the Activation Status.................................................... 80
7.4.5 Viewing the Last 25 Uplink/Downlink Packets of an Application ........ 80
7.4.6 Checking the LoRaWAN ® Devices Associated to an Application .......... 81
7.4.7 Checking the Communication History of the Application ................... 81
8 ACTIVATING A DEVICE TO YOUR IOT NETWORK ................................................... 83
8.1 Overview ........................................................................................................... 83
8.2 Activating Devices............................................................................................. 83
8.2.1 Main Device Parameters ................................................................... 84
8.2.2 Creating a Device in 3 Steps .............................................................. 85
8.3 Importing Devices in 2 steps ............................................................................ 87
8.4 Viewing Devices ................................................................................................ 98
8.4.1 Viewing all Devices ........................................................................... 98
8.4.2 Viewing and Editing Device Details .................................................... 99
8.5 Managing Devices............................................................................................. 99
8.5.1 Overview .......................................................................................... 99
8.5.2 Device Parameters ............................................................................ 99
8.5.3 Updating Device Parameters ........................................................... 101
8.5.3.1 Sending a test Downlink frame ................................................................. 102
8.5.4 Removing a Device .......................................................................... 103
8.5.5 Duplicating a Device ....................................................................... 103

8.5.6 Checking the Status Information of the Device ................................ 103
8.5.7 Activating a Device with an Application ........................................... 104
8.5.8 Modifying the Location of the Device .............................................. 105
8.5.9 Checking the Radio Communication History of a Device .................. 107
8.5.10 Monitoring Device Uplink ESP ......................................................... 108
8.5.11 Viewing Recent Uplink / Downlink Activity of a Device .................... 108
9 THINGPARK ENTERPRISE API ............................................................................. 111
10 MANAGING A THINGPARK ENTERPRISE INSTANCE ............................................. 112

10.1 Overview ......................................................................................................... 112
10.2 Managing the License ..................................................................................... 113
10.3 Managing User Accounts ................................................................................ 114
10.3.1 Creating User Accounts ................................................................... 114
10.3.2 Viewing User Accounts .................................................................... 115
10.3.3 Modifying or Deleting User Profiles ................................................. 115
10.3.4 Resetting User Password Settings ................................................... 116
10.3.5 Session Expiration ........................................................................... 116
10.4 Managing Catalogs in ThingPark Enterprise................................................... 117
10.4.1 Managing Catalogs of Base Station Models ..................................... 117
10.4.1.1 Updating Catalogs of Base Station Models ............................................... 117
10.4.1.2 Viewing Catalogs of Base Station Models ................................................. 117
10.4.2 Managing Catalogs of Device Models .............................................. 118
10.4.2.1 Updating Catalogs of Device Models ........................................................ 118
10.4.2.2 Viewing Catalogs of Device Models .......................................................... 118
10.4.3 Managing RF Region Catalogs .......................................................... 119
10.4.3.1 Updating RF Region Catalogs .................................................................... 119
10.4.3.2 Viewing RF Region Catalogs ...................................................................... 119
10.5 Using Network Tools ...................................................................................... 120
10.5.1 Main Concepts ................................................................................ 120
10.5.2 Using the Wireless Logger ............................................................... 120
10.5.3 Using the Network Survey Tool ....................................................... 121
10.5.4 Using the Spectrum Analysis Tool .................................................... 122
10.6 Managing ThingPark Enterprise Base Stations and Devices Alarms .............. 123
10.6.1 Overview ........................................................................................ 123
10.6.2 Concepts ......................................................................................... 123
10.6.3 Definitions ...................................................................................... 124
10.6.4 Viewing Alarms in the User Interface .............................................. 125
10.6.5 Management of Alarms’ Occurrences .............................................. 127
10.6.5.1 Device Alarms Triggered by a State .......................................................... 127
10.6.5.2 Device Alarms Triggered by an Event........................................................ 128
10.6.5.3 Base Station Alarms Triggered by a State ................................................. 128
10.6.5.4 Base Station Alarms Triggered by an Event .............................................. 129
10.6.6 Alarms Used for Troubleshooting Base Stations .............................. 130
10.6.7 Alarms Used for Troubleshooting Devices ....................................... 139
10.6.8 Uplink Activity Alarms ..................................................................... 144
10.6.9 Creating Notifications ..................................................................... 144
11 OTHER TASKS AND USER INFORMATION ........................................................... 146
WHAT’S NEW HISTORY ...................................................................................................... 148
ABOUT ACTILITY ................................................................................................................ 150

1 SCOPE
The scope of this guide is to describe ThingPark Enterprise user interface and how to use it.
This document is intended for users of ThingPark Enterprise Software as a Service (SaaS) for
5.2.2 release.

2 THINGPARK ENTERPRISE
ThingPark Enterprise is an Internet of Things (IoT) platform optimized to manage a LoRaWAN®
network at enterprise scale. ThingPark Enterprise may be run in hosted mode using Actility
SaaS platform or using a dedicated instance which may be run on the customer premises:
ThingPark Enterprise OCP. ThingPark Enterprise SaaS enables enterprises and industries to
avoid deploying a core network on site. It requires internet connection between the remote
Base Stations installed on enterprise premises (with secure access via VPN tunnels) and the
cloud-based ThingPark core/backend networks.
ThingPark Enterprise allows then enterprise IoT administrators to manage the LoRaWAN®
network:
▪ Form the network infrastructure by creating, managing and removing LoRaWAN® Base
Stations (also called gateways).
▪ Add new Devices to the network and manage existing Devices.
▪ Monitor the network operations using dashboards, alarms and status data.
▪ Control the flow of data to your application servers or to popular IoT cloud platforms.
The LoRaWAN® network consists of Base Stations which can be installed both indoor and
outdoor. Devices, which comply with LoRaWAN® 1.0.x and LoRaWAN® 1.1 versions of the
protocol, are not attached to any Base Station in particular. Any Base Station which receives
an uplink frame will process it: this macro-diversity increases the robustness of
communication in the unlicensed radio spectrum. Base Stations transmit the uplink frames
received from LoRaWAN® Devices, together with specific radio receiver metadata, to the
LoRaWAN® Network Server function of ThingPark Enterprise, which deduplicates the uplink
frames and relays this data to configured Application Servers. The Network Server function in
the ThingPark architecture runs the LoRaWAN® protocol state machine and network layer and
selects dynamically the best Base Station when transmitting downlink frames received from
Application Servers.
The data flow within your IoT network operates as follows:
▪ Devices transmit data to the network Base Stations (uplink frames).
▪ Devices listen for downlink frames from the Base Stations, after each uplink
transmission (class A), periodically (class B), or always (class C).
▪ Base Stations proxy the data to and from the via a backhaul wide area network,
typically Ethernet, cellular M2M or WIFI.
▪ The Network Server relays the data frames to/from Applications Servers via a
messaging protocol (e.g. HTTPS), and to/from cloud IoT platforms by their native
connectors.
The following diagram illustrates the data flow in the IoT private Network. XXXX IOT_image XXXX

3 CREATING THE IOT NETWORK
The configuration of ThingPark Enterprise consists of the following main steps:
1. Activating a Base Station
2. Connecting an Application
3. Activating Devices and associate them to an Application.
Activating the Base

Station
Activating the Device Connecting the

and associate it with Application
the Application
It is compulsory that you add at least one Application prior to creating the Device, so that you
can associate the Device to the Application.

4 LOGGING-IN THINGPARK ENTERPRISE
4.1.1 Prerequisites
For you to deploy your platform in a SaaS environment you need the following requirements
to be fulfilled. These conditions are described in the following table.
Requirements Explanation
Installation and This action is performed by your Vendor or your ThingPark Enterprise Channel
configuration of the prior to delivering the TPE SaaS platform.
SaaS platform
Supported browsers
▪ The minimum version of Google Chrome browser is 72 and 64 for
Mozilla Firefox browser.
▪ Note Older browsers or other browsers may run the Application but
can experience random issues.
4.1.2 Required Licenses

You have purchased a license with your Vendor or your ThingPark Enterprise Channel. Your
license contains the maximum number of Base Stations that you have purchased.
An example of license size is described in the following table.
License Size Description Number of

Base Stations
Small 1 to 10
▪ 3 ThingPark Dataflow Connectors
▪ ThingPark Essential Support and Maintenance

Medium Up to 50

Large Up to 100

X Large Unlimited
4.1.3 First time log-in

Your Vendor or your ThingPark Enterprise Channel has provided you with an account for
using the ThingPark Enterprise platform.
You should receive an activation e-mail that allows you to create your password so that you
can access the platform.

1. Click the link that has been provided to you to activate your account.
2. Update your password and user profile to activate your account.
3. Click Submit.
 Your account has been updated.
4. In your Internet browser, type the link to access ThingPark Enterprise:

https://thingparkenterprise.cc.actility.com/ where cc corresponds to “eu” (Europe) or
“au” (Australia) depending on the regional SaaS platform associated with your
subscription.
 A dashboard that looks like the one that is shown in 5 Default Dashboard.
Note If you want to view the number of licenses that you purchased, click Manage >
Operating Management. Then, the License Management panel displays. For more
information, see 10.2 Managing the License.

5 DEFAULT DASHBOARD
5.1 What can you find in the Dashboard?
The ThingPark UI displays a dashboard that looks like this.: XXXXglobal_dashboard_5.1.5_1XXXX

The ThingPark Enterprise dashboard consists of three main areas which are described in the
following table:
Areas Explanation
Top bar area Corresponds to the Information menu. For more information, see 5.1.1
Top Bar Area.
Left menu bar Lists the menu options related to the network management. For more
information, see 5.1.2 Left Menu Bar.
Center pane Corresponds to the network elements as well as the News part. For more
information, see 5.1.3 Center Pane.
5.1.1 Top Bar Area

The top bar area contains the following items:
Information menu Description
▪ My profile tells you whether you are logged in to access your

profile. Click on it to access your account settings.
For more information, see 5.3 Using My Profile.
▪ Help information directs you to the user documentation.
▪ Contact your Vendor or your ThingPark Enterprise Channel if

you need to require additional information. See 5.4 Using
Contact us.
▪ Logs out from the User Interface.
▪ Search category to filter search results.
▪ Search category to filter Devices, Base Stations and

Applications.
▪ The Search button that allows to filter the results in the

selected category.

▪ Hides or shows the columns in the menu. When you click the
lines, a menu displays with a checklist. It allows you to select
the items that you want to display in the menu.
▪ Refers to the Home page. It takes you back to the dashboard.
▪ Indicates both the software and application versions. This

information is important for support interactions.
5.1.2 Left Menu Bar

The menu options related to the network management are available in the left menu bar. They
are provided on the left side of the window.
Status tab Description

Dashboard
▪ The dashboard displaying the distribution of the various statuses
of the active Base Stations, Devices and Applications.
Base Station
▪ The Base Station tab to list and create Base Stations.
Devices
▪ The Device tab to list and create Devices. The Devices are
attached to the Applications.
Applications
▪ The Application tab to list and create Applications.
Manage
▪ The manage tab used to create and manage users and execute
operational actions.
5.1.3 Center Pane

The center pane is structured in four sub-areas:
Sub-area Description
Base Station
▪ This pie-chart displays the status of Base Stations. Clicking one
of the sectors of the pie chart takes you to the corresponding
Base Station’s list.
Devices
▪ This pie-chart displays the status of Devices. Clicking one of the
sectors of the pie-chart takes you to the corresponding Device’s
list.
Applications
▪ This table lists the provisioned applications and the number of
Devices that are associated to each application.
▪ Click a line to go to the application management or click the
title to see the complete list.

Sub-area Description
News
▪ Insystem.
this widget you can share messages with other users of the
▪ Clicking the paper airplane posts your update to the news list.
▪ The widget is refreshed after update or delete.
Clicking the trash symbol deletes your edit (after confirmation).
▪ All users may post and share news messages.
▪
Recent Alarms
▪NoteTheOnly
area where you can view recent alarms.
the last 10 most recent alarms are visible on the
dashboard.
▪ Clicking the widget takes you to Alarms Management.
5.1.4 Color codes

Color codes are used to identify the status of Base Stations and Devices. The color code used
for illustrating the status of the Base Station and that of the Devices are different. Both color
codes are described in the following tables.
5.1.4.1 COLOR CODES USED FOR BASE STATIONS
Color Description
Active (Green)
▪ A green bullet means that the Base Station is connected to the
Network Server and is able to send or receive LoRaWAN®
packets to or from a Device.
Initialization
(Orange) ▪ An orange bullet is an initialized Base Station which has not
communicated yet. It corresponds to the initial Base Station
status after its creation.
Connection Error
(Red) ▪ A red bullet is a Base Station that has backhaul connection
issues and cannot communicate with the Network Server.
Radio Error (Grey)
▪ A grey bullet relates to a Radio Error - A Base Station that has
radio transmission issues and cannot send or receive LoRaWAN ®
packets to or from a Device.
The difference in the color code used between that of the Base Stations and the Devices
resides in the fact that the grey color (Radio error) only apply to Base Stations.
5.1.4.2 COLOR CODES USED FOR DEVICES
Color Description
Active (Green)
▪ A green bullet means that the Device is commissioned, and its
communication pattern corresponds to the expected profile,
e.g. the uplink frequency matches the minimal frequency
configured in the Device profile.

Color Description
Initialization
(Orange) ▪ An orange bullet is an initialized Device which has not
communicated yet. It corresponds to the initial Device status
after its creation.
Connection Error
(Red) ▪ A red bullet is a Device that is commissioned on the ThingPark
system and has communicated in the past, but no longer
communicates or does not match the expected communication
pattern. It needs attention (e.g. change the Device battery). If
the Device is no longer used, you can de-commission it.
5.1.4.3 COLOR CODES USED FOR APPLICATIONS

A green bullet means that an application is activated; an orange one signifies that the
application is deactivated.
5.1.5 Buttons
Buttons are used to perform the following actions:
Button Description
▪ Used to post a new piece of news.
▪ Used to delete a piece of news.
▪ Used to create a new network element.
▪ Used to display password (while mouse button is clicked).
▪ Used to download charts or export in CSV format.
5.1.6 Accessing Network Elements

You can access the network elements using different ways:
Button Description
Base Stations,
Devices and ▪ You can access these network elements using the dedicated
menu, the Search button or the network element’s area.
Applications
Base Station element
and Device element ▪ You can access single network elements with their status by
clicking each color of the circle of the network element.
Application element
▪ You can access each Application by clicking the Application icon
in the Application area.
5.2 Using the Tablet Version of ThingPark Enterprise
ThingPark Enterprise is also available on tablet as an Early Availability version.
Functionalities are the same as for a TPE OCP platform with the following limitations:
Functionalities Description
"Eye" button ▪ Is used to show the clear text password on the Login panel.
▪ Is hidden.
Moving over ▪ Is hidden. However, tooltips associated with buttons are
tooltips available.
Widgets ▪ Are displayed within the screen.
▪ Are always displayed one below the other and never next
to each other.
Some columns are ▪ BS list

not displayed by o "LRR-ID"
default in tables o "LRR-UUID"
▪ Device list
o "DevEUI"
o "DevAddr"
o "Application"
o "Best LRR"
Note Other differences from a regular browser version that are not listed yet (above) may be
present.
5.3 Using My Profile

5.3.1 Overview
Access My Profile to perform the following settings:
▪ Modify your name and surname.
▪ Modify your email address.
▪ Change your password.

Name, surname and email are also used for technical support.
5.3.2 Prerequisites
Prior to using My Profile you must have the following information ready to be used:
▪ A user account.
▪ A valid email address.

5.3.3 Filling in My Profile
My Profile allows you to change the following information items:
Parameter Definition
First Name
▪ Designates your first name.
Last Name
▪ Designates your last name.
Email Address
▪ Designates a valid email address
Phone Number
▪ Designates a phone number or a landline that works.
Language
▪ Provides the language you want to work in. English (USA) is the
default language.
Password
▪ Designates the old, new and confirmation password.
▪ You have two ways for modifying personal information. Either you use the My Profile
widget (described in 10.3.3 Modifying or Deleting User Profiles or change your Profile
through the My Profile widget on the upper right side of the screen.
Note All fields with an asterisk are mandatory.
 Upon changing profile information, a message in a green box appears on the

upper right side of your screen to tell you that the information has been
updated.
5.3.3.1 PASSWORD POLICY
If you choose to change your password and for your password to turn green, ensure the
following:
▪ The password must contain at least 6 characters.
▪ The password must contain at most 16 characters.
▪ The password must contain lower characters.
▪ The password must contain upper characters.
▪ The password must contain digit characters: The password must contain special
characters in this list: ‘ ~ @ # $ % ^ & * () _ - + = { } [ ] \ | : ; < > , . ? / .
Otherwise, the password strength will be considered as weak and be displayed in red.
1. Confirm your new password.
2. Click Save.
 If you changed your password correctly a message in a green box appears on the
upper right side of your screen to tell you that the password has been updated.
5.4 Using Contact us
5.4.1 Overview
Prior to using Contact us section when you have any question regarding the usage of the
ThingPark Enterprise platform.
5.4.2 Prerequisites
Prior to using Contact us you must have the following information ready to be used:
▪ A user account.
▪ A valid email address.
5.4.3 Filling in Contact us

The form allows you to input the following parameters:
I need support for

▪ Designates the part of the User Interface for what you have
questions about.
▪ Selects among Application, Device and Base Station.
Object
▪ Designates what you need support from while using the
ThingPark Enterprise platform
Your message
▪ Describes the problem that you encounter.
Organization
▪ Designates the name of the company where you have a user
account and email.
Email address
▪ Designates the email address under which you are registered.
Phone number
▪ Specifies the phone number where one can reach you, if need
be.

To fill-in the form:
1. On the upper right side of you screen click the Contact us widget.
The following default screen appears.
2. Describe briefly the object of your request. For instance, write “I created a Base
Station, but it does not display in the list of created Base Stations.”.
3. Fill in mandatory fields.
4. Click Send.

6 ACTIVATING A BASE STATION TO YOUR IOT NETWORK
6.1 Overview
This section explains how to perform the following tasks:
▪ Create a new LoRaWAN® network.
▪ Activate one or several Base Stations using the Public Key in a LoRaWAN® network.
▪ Change the parameter settings of a Base Station.
▪ Monitor the activity of the network.
▪ Secure the transmissions between the Base Stations and the Network Server.
▪ Quickly create another Base Station by using an existing Base Station as a template.
▪ Check the system load of a Base Station: CPU usage, RAM usage and Disk usage.
The ThingPark Enterprise license model that you purchase allows you to create the size of the
network that you wish.
For more information, see 10.2 Managing the License.
6.2 Securing Base Station Access to Cloud Backend

6.2.1 Main Concept
Authentication is the process that verifies that the Base Stations connecting to the ThingPark
Enterprise platform are those that claim to access the platform. Thus, only authenticated Base
Stations will be able to connect to the platform. This security measure prevents not authorized
Base Station or any network element from malicious access.
On a ThingPark Enterprise SaaS platform, as of version 5.2.2, a Base Station is authenticated
according to a private/public Key Authentication principle.
Public-key cryptography, also known as asymmetric cryptography, is any cryptographic system
that uses pairs of keys: public keys which may be disseminated widely, and private keys which
are known only to the owner. This accomplishes authentication function, where the Public Key
verifies that a holder of the paired private key sent the message.
For more information, see Public key cryptography on this resource.
Once authenticated, the Base Station shall retrieve its security certificates (X.509-based) to
establish a secure VPN tunnel towards the ThingPark Enterprise cloud backend. This VPN
tunnel is typically based on IPsec protocol, but TLS protocol is also supported as an alternative
to IPsec.
6.2.2 Workflow
The private/public key authentication is used when the Base Station contacts the Network
Server for the first time. That allows a specific Base Station to retrieve its own X.509 certificate.
The X.509 certificate is then used by the Base Station to establish the IPsec tunnel securing
the link toward the Network Server of the ThingPark Enterprise SaaS platform.
IP filtering was used in previous ThingPark Enterprise versions instead of private/public key
authentication. This new authentication scheme provides a stronger security and more
flexibility as public IP of the Base Station is not needed to be static.
For more information, see X.509 on this resource.
The workflow is illustrated in the following graphic. XXXXpublic_key_authentication_5.2.2 - BXXX
6.2.3 Reinforcing Security Using Private/Public Keys

The Public Key authentication functionality must be enabled on the Base Stations that you
want to provision on your ThingPark Enterprise platform. As of ThingPark Enterprise 5.2.2, all
Base Stations are provided with this functionality.
There are two cases where you need to generate a private/public key pair to secure your TPE
SaaS platform:
1. When provisioning a new Base Station.

2. When activating the feature on an existing Base Station.

6.2.3.1 CASE 1 – WHEN PROVISIONING A NEW BASE STATION
▪ Step 1: Get the LRR UUID and the Public Key using the Base Station configuration tool
called SUPLOG via SSH. Note that the LRR UUID is also available on the package of the
Base Station.
▪ Step 2: Activate the Base Station using the ThingPark Enterprise User Interface.
For more information, see the TP Enterprise BS Installation Guide corresponding to your Base
Station model. This document is available by clicking Download the base station
documentation from the Base Station’s detailed view.
For more information, see 6.3.2 Activating A Base Station in 2 Steps.
6.2.3.2 CASE 1 - WHEN ACTIVATING THE FEATURE ON AN EXIST ING BASE STATION
Pre-requisites To activate the Public Key Authentication mode on an existing Base Station, the
LRR software version should be at least 2.4.88 or higher. If not, upgrade the LRR software
version. For more information, see 6.5.3 Updating the Base Station Information.
▪ Step 1: Activate the Public Key using SUPLOG via SSH.
▪ Step 2: Add the new Public Key using the ThingPark Enterprise User Interface.
The following table summarizes the cases where you need to activate Public Key
Authentication on a Base Station on a ThingPark Enterprise SaaS platform.
Tools/Actions per Case Provisioning a new Base Activating the feature on an

Station existing Base Station
SUPLOG ▪ Get the LRR UUID (or from

the package)
▪ Activate the Public Key
Authentication
▪ Get the Public Key
▪ Get a new Public Key
This can also be done via the

Remote Access which is accessible
from the TPE User Interface
ThingPark Enterprise ▪ Enter the values of the

LRR UUID and the Public
▪ Enter the new Public Key
User Interface
Key in the Base Station
creation form to activate
the Base Station
For more information, see 6.5.8 Activating Public Key Authentication.

6.3 Activating a new Base Station
6.3.1 Prerequisites
You need to have the following information ready.
Base Station Name

▪ Name of the Base Station that you want to register.
Base Station Model

▪ Name of the model.
LRR UUID
▪ Long-Range Relay Universally Unique Identifier, that is Base
Station Universally Unique Identifier. The Base Station Universal
Unique Identifier (LRR UUID) is a concatenation of LRR OUI and
LRR GID.
▪ <LRR-OUI> is the IEEE OUI of the Base Station vendor (6
hexadecimal characters).
<LRR-GID> is the Base Station identifier relatively to the vendor
(allowed characters: [0-9][a-z]-_, max 256 characters).
▪ Kerlink: <LRR-GID> = full eth0 MAC address
▪ Cisco:<LRR-GID> = full Cisco S/N

RF Region
▪ The LoRaWAN® specification “LoRaWAN® Regional Parameters”,
defines several RF profiles depending on the regional RF
regulatory context. These regional parameters are grouped into
a set of radio parameters along with a frequency allocation that
is adapted to the ISM Band called RF Region.
Additional
information ▪ Any useful information related to the Base Station. It can be
where you want to install the Base Station. It can be for
instance, a room for checking humidity.
6.3.2 Activating A Base Station in 2 Steps

You can connect several brands of Base Stations with ThingPark Enterprise. A list of sample
brands is as follows:
▪ Cisco
▪ Gemtek
▪ IMST
▪ Kerlink
▪ Multitech
▪ Tektelic
▪ UfiSpace

The list of Base Stations is dynamically increased as the number of Base Stations’ profiles get
certified by the ThingPark Enterprise solution. To add Base Stations’ profiles, contact your
Vendor or your ThingPark Channel.
Procedures for activating a new Base Station are the same for all Base Station models. All
manufacturer’s Base Stations present in the creation form have at least one Base Station
model compliant with a configured ISM Band. If your TPE SaaS instance has not been pre-
configured with the desired ISM Band, contact your Vendor or your ThingPark Channel.
6.3.2.1 GETTING THE LRR UUID AND THE PUBLIC KEY USING SUPLOG VIA SSH
1. Connect to the Base Station using its IP address. For instance, 10.100.52.75.
2. Connect to SUPLOG using the credentials that your Vendor or your ThingPark
Enterprise has provided you with.
Note Ensure that you display a full window of the Base Station configuration tool. This will
ensure that you copy the whole Public Key.
 The main menu is displayed. This looks like the screen shown in 6.5.7.1 Using the
Remote Access.
3. In the main menu go to LRR configuration.
4. Go to Get LRR UID.
5. From the result window that displays copy/note the UID, for instance, 001558-
46584254C00014EF.
6. Go back to the Main Menu.
7. Go to VPN Configuration.
8. Go to Generate new key pair.
 A message that looks like this displays: XXXX_generating_public_keys_XXXX
9. Enter ‘yes’ and Confirm.
 The Base Station configuration tool generates a pair of keys.

10. In the same window that displays, go to Generating keys.

11. Go to OK.
12. Go back to the Main Menu.
13. Go back to LRR configuration.
14. Go to Get Public Key.
A window that looks like this displays the new Public Key. XXXX-publick_key_XXXX
15. Copy the Public Key.

6.3.2.2 ACTIVATING THE BASE STATION USING THE THINGPARK ENTERPRISE USER
INTERFACE
1. Click Base Stations > Create or from the Dashboard, click the icon.
The following screen (excerpt) appears: xx004_GW Creation_1_Emptyxx

2. To create the Base Station, select first the Base Station manufacturer brand.
A form (empty) that looks like as shown in the capture below displays.
You need to enter the LRR UUID that you retrieved from SUPLOG or from the package of
the Base Station. XXXX_base_station_creation_5.2.2_public_key_XXXX
3. Fill in the form as in the example above.

Note Parameters with an * are mandatory.
You need to enter the Public Key that you retrieved from SUPLOG.
XXXX_base_station_creation_5.2.2_public_key_2_A_XXXX

4. Update the Base Station installation location.
a. Select the location.

Note If the location using Google Maps does not display, it means that the Google
Maps API key has not been installed on the platform. For more information, contact
your technical support.
b. Click Save.
Note You cannot set the Base Station location unless you have filled in the Base
Station information.
 A confirmation message appears on the upper right corner of your screen telling
you that the Base Station has been created.
This message also provides you with the option to duplicate the Base Station or
to review its parameters.
Duplicate the Base Station if you want to create the same type of Base Station. Otherwise,
View the Base Station.
5. Click View the Base Station.

 You are redirected to the Managing Base Stations screen. For more information,
see 6.5 Managing Base Stations.

6.4 Viewing Base Stations
6.4.1 Overview
▪ See detailed configuration information regarding any Base Station.
▪ Check the status and current activity of Base Stations for monitoring purposes.
▪ View Base Station security status and information.
▪ Execute Base Station operational functions for debugging and maintenance purposes.
6.4.2 Description of Base Station Parameters

Note These parameters are read-only in the Viewing screen.
Base Station Name

▪ Name of the Base Station.
LRR UUID
▪ Long-Range Relay Universally Unique Identifier, that is Base
LRR GUID.
▪ <LRR-OUI> is the IEEE OUI of the Base Station manufacturer (6
hexadecimal characters)
▪ <LRR-GID> is the Base Station identifier relatively to the vendor
(allowed characters: [0-9][a-z]-_, max 256 characters)
o Kerlink: <LRR-GID> = full eth0 MAC address
o Cisco: <LRR-GID> = full Cisco S/N
LRR ID
▪ Base Station network Identifier, unique within the network
(allocated by network).
▪ LRR ID (32 bits) is automatically generated and dynamically
associated with the LRR.
SW Version
▪ LRR software version that has been installed on the Base
Station.
SW Restart
▪ Last restart time of the Base Station LRR software.
Backhaul Networks
Traffic ▪ Traffic exchange on the backhaul network interface between
the Base Station and the Network Server. This interface may use
different physical technologies such as Ethernet, cellular
connectivity or Wi-Fi.
Last Uplink /
Downlink ▪ Frame details for the last uplink and downlink messages
processed by the gateway.

6.4.3 Viewing all Base Stations
1. Click Base Stations > List.
The following screen appears and displays all existing Base Stations.
XXXX all_bs_all_states XXXX
The Base Station’s type icons are decorated with a color bullet, corresponding to the overall
Base Station’s status. For more information about the colors of the bullets, see 5.1.4.1 Color
Codes used for Base Stations.
Note If you have reached the maximum number of Base Stations, a message informing you
about it will display on your screen.
In the Base Station’s panel on the upper right side of your screen, you can filter Base Stations
by state.
6.4.4 Viewing a single Base Station

2. In the Base Stations screen, select a Base Station.
3. Click the name of the Base Station.
A screen displaying the detailed information of the Base Station appears.
4. Move your cursor down to your screen to view the information that you are
interested in.
Note The detailed information screen of the Base Station allows you to set the
parameters of the Base Station. For more information, see 6.5 Managing Base
Stations.

6.5 Managing Base Stations
6.5.1 Overview
▪ View/Update the name or other parameters of a Base Station.
▪ View/Update the location of a Base Station.
▪ Monitor the backhaul network connectivity status of a Base Station.
▪ Execute Base Station management commands such as restart a Base Station.
▪ View radio traffic and network activity history, including transmit and receive duty-
cycle, receiver noise level and signal strength.
▪ Inspect recent LoRaWAN® communication frames, including data payload and MAC
command details to troubleshoot LoRaWAN® communication issues.
▪ Inspect LoRaWAN® RF physical layer subsystem activity and error counters, restart
the RF subsystem if needed.
▪ Inspect recent LoRaWAN® uplink/downlink transmission statistics, data rate

(LoRaWAN® Spreading Factor) distribution, transmission error causes.
▪ Perform a spectrum analysis of the radio frequencies on your Base Stations. Scanning
the radio frequency will determine the best radio frequencies to use by your Base
Stations in the RF Region plan. For more information on spectrum analysis, see the
Spectrum Analysis User Guide.
▪ Monitor time synchronization status of the Base Station, including current time
synchronization source.
▪ View Devices which have a given Base Station as their best server.
▪ Re-generate an X.509 certificate to authenticate a Base Station.
▪ Perform an LRR software version upgrade.
▪ Run maintenance operations.
6.5.2 Main Parameters and Definitions Related to Base Station management

In this menu all parameters are read-only unless otherwise notified.
Base Station Name

▪ The name given to the Base Station when it has been added to
the network (Editable).
Manufacturer
▪ Name of the company that produces the Base Station.

Base Station Model

▪ Name of the model.
LRR UUID
▪ Long-Range Relay Universally Unique Identifier, that is the Base
LRR GUID.
▪ <LRR-OUI> is the IEEE OUI of the Base Station vendor (6
hexadecimal characters).
<LRR-GID> is the Base Station identifier relatively to the vendor
(allowed characters: [0-9][a-z]-_, max 256 characters)
o Kerlink: <LRR-GID> = full eth0 MAC address
o Cisco: <LRR-GID> = full Cisco S/N
LRR ID
▪ Base Station network Identifier allocated by the network and
unique within the network.
▪ Base Station network Identifier, unique within the network
(allocated by network).
▪ LRR ID (32 bits) is automatically generated and dynamically
associated with the LRR.
LRR Software Version
▪ Version of the Long-Range Relay software installed on the Base
Station.
▪ A specific widget close to the field of this parameter shows the
Base Station’s versions. This includes:
o Base Station Firmware Version that is installed on the
Base Station
o Field-Programmable Gate Array (FPGA) Firmware
Version that is installed on the Base Station
o Hardware Abstraction Layer (HAL) Version that is linked
with the LRR software running of the Base Station
o Hardware Version (indicated, if available)
o OS Version (indicated, if available)
o Custom Build Version (indicated, if available)
o Configuration Version(indicated, if available)
Note When providing the list of LRR software packages
available for upgrade, only LRR software packages
compatible with the firmware version and the FPGA
version currently installed on the targeted Base Station
are offered.
RF Region
▪ The LoRaWAN® specification “LoRaWAN® Regional Parameters”,
defines several RF profiles depending on the regional RF
regulatory context. These regional parameters are grouped into
a set of radio parameters along with a frequency allocation that
is adapted to the ISM Band called RF Region.
Additional
information ▪ Any useful information related to the Base Station. We
recommend that you write information related to the antenna,
as well as precise location information (Editable).
Time Synchronization
(NTP)
▪ Time synchronization using Network Synchronization Protocol
(NTP); refers to Base Station clock synchronization service.
Last Uplink
▪ Last packets that were sent from a LoRaWAN® Device and
received by the Base Station.
Last Downlink
▪ Last packets were transmitted by the Base Station.
Radio traffic history

▪ History of radio traffic (Uplink/Downlink) on a Base Station. It
gives a view of the network activity over time.
Packets
▪ LoRaWAN® frames are presented with decoded frame headers
and MAC commands, payload remains encrypted.
Payload
▪ User data carried by the LoRaWAN® frame, encrypted by the
AppSkey negotiated during network Join procedure (OTA
Devices).
Latency
▪ Round-trip communication time between the Base Station and
the Network Server.
Backhaul network
Traffic ▪ Packets exchanged between the Base Station and the Network
Server, and from the Network Server to the Base Station.
Spreading Factor (SF)

▪ 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
(~250 bits/sec) in consideration of the LoRaWAN® regional
configuration.
SNR (Noise)
▪ Signal to Noise Ratio
▪ Determines the ratio between the received LoRaWAN® signal
strength of the desired signal and the signal strength of the
background noise. Unlike conventional radio technologies,
LoRaWAN® reception does not require positive SNR, you may see
correct reception of LoRaWAN® frames with negative SNR up to
-20dB (SF12).
RSSI (Signal Strength)
▪ Received Signal Strength Indicator.
▪ Determines the total received signal strength over a given
Logical Channel, summing up both the desired signal and the
background noise. When SNR is negative, this effectively
measures the background noise.
Duty Cycle
▪ Uplink Duty Cycle determines the aggregated effective
reception time by the Base Station over a given channel for all
received Devices, over a time window (typically one hour). Due
to ALOHA network technology of LoRaWAN®, Uplink Duty Cycle
should stay below about 10%. Increase macro diversity by adding
Base Stations, if the Duty Cycle gets above 10%.
▪ Downlink Duty Cycle determines the aggregated transmission
time of the Base Station over a given channel, over a
granularity period (typically one hour).
LC
▪ Logical Channel
▪ A LoRaWAN® logical channel is characterized by its central radio
frequency and bandwidth. For example, in ISM band eu868
profile default settings, LC1 refers to a center frequency =
868.1MHz and a channel bandwidth of 125kHz.
▪ Simultaneous transmissions using different Logical Channels
don't interfere with each other. Within a given Logical Channel,
transmissions with different Spreading Factors also have a high
degree of isolation.

Asymmetric downlink
channel ▪ Channels that are used for downlink messages for specific ISM
bands, using different frequency than uplink channels.
Asymmetric downlink channels are used for instance in US915
RF region.
System load
▪ CPU, RAM and disk usage are indicators of the system load of
the Base Station.
CPU
▪ Central Processing Unit usage of the Base Station.
RAM
▪ RAM usage of the Base Station.
Disk
▪ Disk usage of the Base Station, often Flash memory disk.
X.509 certificate
▪ An X.509 certificate is a digital certificate that uses the widely
accepted international X.509 Public Key infrastructure (PKI)
standard to verify that a Public Key belongs to the user,
computer or service identity contained within the certificate.

6.5.3 Updating the Base Station Information
1. Click Base Stations > List and the Base Station Name for which you want to change the
information.
The Base Station information displays as follows: XXXX base_station_information_5.2.2XXXX
2. Only the RF Regions having an ISM band compatible with the Base Station are
proposed in the drop-down list.
 Note If there is an updated version of the RF Region, a message is displayed below

the RF Region parameter. Upgrade the RF Region and confirm your choice. For more
information, see 10.4.3 Managing RF Region Catalogs.

In this example an LRR software version upgrade is available for your Base Station. The LRR
software upgrade is only proposed if at least one LRR software compatible with the Base
Station firmware version and the FPGA version currently installed on the targeted Base
Station is available in the Base Station catalog. If several compatible LRR software packages
are found, only the upgrade to the latest version is proposed.
Note The Base Station upgrade applies only to the LRR software. It concerns neither the
Base Station firmware, nor the FGPA.
Caution Prior to performing an LRR software version upgrade, we recommend that you first
backup the current LRR software and configuration before upgrading the new version. For
more information, see 6.5.7.2 Using the Backup Procedure.
Note The LRR software upgrade procedure will take several minutes while the Base
Station will be unavailable during this time.
3. Click Upgrade.
 A dialog box regarding the LRR software upgrade opens. This dialog box will guide
you through the whole procedure.
4. You are asked to confirm each action that is required for the upgrade.
 The LRR software upgrade runs until the new software version is downloaded and
the Base Station is upgraded. If the upgrade is successful, a similar dialog box
displays on your screen:
5. Click Close.
The LRR software upgrade may fail in the following cases:

▪ The Base Station is not reachable. Ensure that your Base Station is connected to a
power source and to the network.
▪ The upgrade command returned an error. You need to restart the procedure.

6.5.4 Duplicating a Base Station
The following screen is displayed.
2. Click Duplicate.
 You are redirected to the Creating a Base Station in 2 Steps screen. For more
information, see 6.3.2 Activating A Base Station in 2 Steps.
3. Fill in the parameters, as requested.
6.5.5 Deleting a Base Station

Note Ensure that you really want to delete the Base Station from your network. Be aware that
this operation cannot be reverted.
1. Click Base Station > List.

A similar screen as shown in the preceding section is displayed.
A confirmation dialog box asks you if you want to delete the Base Station or cancel the action.
2. Click Delete.
®
 The Base Station is removed from the Base Station table and from the LoRaWAN
network.
If the Base Station is disconnected from the network, it still appears in the Base Station
table with a “Connection Error” status. It still can be reconnected to the network.
If you need to delete the Base Station from the network, it disappears from the Base
Station table. You need to recreate it to reconnect it.
For more information, see 6.3.2 Activating A Base Station in 2 Steps.
6.5.6 Base Station Status

In the Base Station Status widget, you can perform the following actions:
▪ Restarting the Base Station
▪ Stopping the Radio
▪ Scanning the Radio
▪ Performing advanced maintenance operations and troubleshooting tasks on an

unreachable Base Station using a remote access connection.
1. Click Base Stations > List and the name of the Base Station for which you want to
display the updated status.
The Base Station status information appears as in the following example: XXXX
base_station_status_5.2.2 XXXX
2. Unfold the Base Station commands.

The following commands are displayed as follows: XXXXX base_station_commands_5.1.5 XXXX
6.5.6.1 RESTARTING THE BASE STATION
Prior to restarting the Base Station, you can check the latest restart time in the widget.
Otherwise, proceed as follows:
1. Click Base Station Restart to restart the Base Station, if need be.
An animation is visible on the Restart Base Station button while the command is being
executed. If you want to check the latest restarting date, check the Base Station Widget.
6.5.6.2 SCANNING THE RADIO
1. Click Scan the radio to launch a spectrum analysis of the radio.
 A message in a green box appears on the upper right side of your screen to ask you if
you want to confirm your action. You are informed that the action may take several
minutes.
2. Click Confirm.
 The button displays an animation to indicate that the scan is in progress. When the
scan is complete, the spectrum analysis displays from the Spectrum Analysis Tool. For
more information, see 9.6.5 Using the Spectrum Analysis Tool.
3. Click Cancel to cancel the scan.
 The button Scan the radio returns to the initial state.

6.5.7 Performing Advanced Maintenance Operations and Troubleshooting Tasks on
a Base Station
6.5.7.1 USING THE REMOTE ACCESS

Caution Use the remote access functionality carefully as it may cause a malfunction of Base
Stations' operations.
1. Click Remote Access.

After a few seconds a Base Station Remote Access window is displayed as follows.
Xxxx base_station_remote_access_5.1 xxxx
1. Analyze the different configurations that you need for completing advanced
maintenance tasks and troubleshooting operations on the Base Station.
2. Exit the remote access mode.
6.5.7.2 USING THE BACKUP PROCEDURE

This procedure launches a backup of the current LRR software and configuration.
Caution You must use this command carefully as the last backup will be erased and replaced
by the new one.
1. Click Backup.
A dialog box informs you that the LRR software backup will be launched.
2. Click Confirm to start the backup procedure. Otherwise, click Cancel.

 A message in a green box appears on the upper right side of your screen to tell you
that the backup request has been sent to the Base Station.
6.5.7.3 USING THE RESTORE PROCEDURE

This procedure restores the backup of the LRR software and configuration. The execution of
the command may take several minutes. The Base Station will be rebooted and unavailable
during this time.
Caution You must use this command carefully as the current configuration will be erased and
replaced by the last backup configuration.
1. Click Restore.
 A dialog box informs you that the LRR software restore procedure will be launched.
2. Click Confirm to start the restore procedure. Otherwise, click Cancel.
that the restore request has been sent to the Base Station.
6.5.8 Activating Public Key Authentication

As described in 6.2.3 Reinforcing Security Using Private/Public Keys, secure access of the Base
Station to ThingPark Enterprise backend relies on public/private key pairs. This section guides
you through the procedure to activate this feature on existing Base Stations.
Pre-requisites To activate the Public Key Authentication mode on an existing Base Station, the
LRR software version should be at least 2.4.88 or higher. If not, please upgrade the LRR
software version. For more information, see 6.5.3 Updating the Base Station Information.
6.5.8.1 ACTIVATING THE PUBLIC KEY USING SUPLOG VIA SSH
Note You can retrieve the Public Key either using SUPLOG via SSH or using the Remote
Access which is accessible from the ThingPark Enterprise User Interface.
1. Click Base Stations > List and select the updated Base Station for which you want to
change the Public Key (001558-46584254C00014EF).
2. In the Base Station commands of the Base Station Status Information, click Remote
Access.
 You are connected to SUPLOG.

3. In the main menu go to VPN Configuration.
4. Go to Key Installer Public Key authentication.
 You are asked if you want to enable the Public Key Authentication.
5. Enter “x” and confirm your choice.
6. Generate the Public Key as explained in Getting the LRR UUID and the Public Key
Using SUPLOG via SSH.
7. Copy the new Public Key.
6.5.8.2 ADDING THE NEW PUBLIC KEY USING THE THINGPARK ENTERPRISE USER
INTERFACE

2. Select the Base Station for which you want to change the Public Key, for instance,
My_Pico_BS.
The Base Station security information appears as follows:
XXXX security_509_public_key XXXX
3. Click Manage Public Key.
 A similar screen displays: XXXX_manage_public_key_update_A_XXXX
Caution You must use this command carefully as setting a wrong Public Key will disconnect
the Base Station.
4. Enter the new Public Key that you retrieved from SUPLOG or the remote access.
5. Click Save.

that the Public Key has been updated.
Note If the same Public Key is re-used, an error message displays on your screen.
You need to regenerate a new Public Key.
6.5.9 Managing the Security Certificate
check the authentication.
 The Base Station security information appears as follows: XX base station security_5.1.5X
2. Click Regenerate X.509 Certificate.
 A message is displayed asking you if you want to complete this action.

When you regenerate a new X.509 certificate of a Base Station, the previous certificate is
revoked, and a new certificate is generated. If you launch this action, a message is displayed
on your screen as follows:
When the old certificate is revoked and replaced by a new one, the Base Station loses
connection to the ThingPark Enterprise backend. The interruption duration is 5 minutes if the
LRR version is 2.4.88 or higher (30 minutes for LRR versions < 2.4.88).
Caution To avoid service disruption, regenerating the security certificate of a Base Station
should be limited to the case when the current certificate has been corrupted/compromised.

6.5.10 Modifying the Location of the Base Station
1. Click Base Stations - > List and the name of the Base Station for which you want to
change the location.
A box appears where to enter in the new location.
2. Click Change Location.

3. Select the types of coordinates that you need to locate your Base Station. Choose
between Google Maps, other supported maps or GPS geographical coordinates. For
more information, see 4.1.1 Prerequisites.
Note If the location using Google Maps does not display, it means that the Google
Maps API key has not been installed on the platform. For more information, see 4.1.1
Prerequisites.
Note To choose the Google Maps coordinates, you can also move the cursor related
to the Base Station over the map or click any location on the map. The cursor moves
to the position where you click.

4. Select Location using Google Maps, for instance.
A map where you can update the location of the Base Station appears.
3. Enter the new location.

4. Click Save.
The location is updated and is displayed in the Location area: XXXXdevice_change_locationXXXX

Note If the widget is deactivated, you will see a message that looks like this:
“The widget has been deactivated. You should configure a Google API key to enable
the widget” (For more information, see the ThingPark Enterprise Installation guide).
6.5.11 Checking the Radio Traffic History of the Base Station

1. Click Base Station > List and the name of the Base Station for which you want to
check the radio traffic.
The RF traffic information appears as follows: XXXXX radio_traffic_packets_bs_5.2.2 XXXXX
In the example, you can view the distribution of the network activity of a Base Station
for a given time.
2. Click the Payloads tab to check payload sizes.

The payloads graph appears as follows: XXXX radio_traffic_payloads_bs_5.2.2 XXXX

6.5.12 Checking IP Address and Connectivity
1. Click Base Stations > List and the name of the Base Station for which you want to see
the IP connectivity status.
The IP connectivity information appears as follows: networks_information
In this example, the widget is adapted per configured network interface. In this case
the mobile network is not connected and not shown.
2. Click Ping Base Station to test the Base Station backhaul connection.
that the Base Station has been pinged.
6.5.13 Checking the Backhaul Network Traffic Profile

check the backhaul network traffic.

The backhaul network traffic information appears as follows:
XXXbackhaul_network_traffic_bs_5.2.2XXXX
In this graph, you can view that the counted messages are those that are exchanged
between the Base Station and the core network at the applicative level. This applies
both to LoRaWAN® traffic and signaling traffic.
2. Move the mouse over “Sent” or “Received” to view specifically the sent or the
received packets.
3. Move the mouse over a day to view the sent and received packets at the same time.
6.5.14 Checking the LoRaWAN ® Data Rate/Spreading Factor Distribution

1. Click List and the name of the Base Station for which you want to check the data rate
distribution.
The data rate distribution information appears as follows: xxxx spreading_factor_5.2.2 xxxx
You should have only a small fraction of frames using the lower data rates (SF11 and
SF12). As these low data rates use more airtime, LoRaWAN® networks have lower
capacity at low data rates. Devices will use more energy when operating at lower
data rates. If you see that your network operates mostly at SF11 and SF12:
▪ Check that the aggregate uplink duty cycle remains below 10% for all RF channels
(see section 6.5.15 below).
▪ Check that the aggregate downlink duty cycle remains below regulatory limits. If
not, you will experience downlink packet drop as ThingPark Enterprise will
enforce duty cycle compliance.
▪ Check that Base Station antenna is placed in a position where it has least
obstacles between Devices and Base Station antenna.
▪ Add more Base Stations to improve RF coverage. ThingPark Enterprise adaptive

data rate (ADR) feature will automatically leverage the better radio conditions to
increase Device communication data rates, reducing network collisions, Device
power consumption and optimizing packet error rate (PER).
6.5.15 Checking the RF Signal Strength, Background Noise and Duty Cycle
check the RF signal strength, background noise and duty cycle.
RF signal strength, background noise and duty cycle information appear as follows:
XXXX signal_strength_noise_duty_cycle_5.2.2 XXXX
The uplink and downlink duty cycles are provided for each Logical Channel (LC).
4. Move the mouse over “Uplink Duty Cycle” or “Downlink Duty Cycle” to view
specifically the uplink or downlink duty cycles.
5. Move the mouse over time axis to view the uplink and downlink duty cycle
simultaneously.
2. Select Received Signal Strength Indicator (RSSI) or Signal to Noise Ratio (SNR) in the
upper right corner of the graph to view the corresponding time series.

3. Depending on Base Station hardware and RF Region settings, you may have 8 or 16
uplink Logical Channels and several downlink logical channels. Select Logical Channel
ranges in the drop-down list on the upper left corner of the graph to display a new
page of Logical Channels.
The list of Logical channels includes:
▪ Symmetrical Logical channels (same frequency used for uplink and downlink
communication), in which case both uplink and downlink data will appear
when you select the Logical Channel tab.
▪ Asymmetric downlink Logical Channels Select, in which case only downlink

data will appear when you select the Logical Channel tab.
6.5.16 Checking the System Load

1. Click Base Stations -> List -> Base Station Name.
The following screen appears. XXXX_system_load_5.2.2_XXXX
2. Move the mouse over CPU, RAM or a Disk to view the usage level details.
3. Move the mouse over the time axis to view a usage level summary for a specific day.
The number of displayed disks shown on the graph depends on the number of partitions which
are configured on the Base Station. One disk is displayed per partition. The number of disks
depends on the Base Station model.

7 CONNECTING AN APPLICATION TO YOUR IOT NETWORK
7.1 Overview
▪ Create Application instances in an existing LoRaWAN® network.
▪ Change the parameter settings of an Application.
▪ Associate an Application to Devices.
7.2 Application Parameters

Several types of Cloud Computing Platform Applications are available in ThingPark Enterprise:
▪ Amazon AWS® IoT: cloud applications leveraging the Amazon AWS® infrastructure
and using Amazon AWS® APIs as a communication method.
▪ HTTPS applications: LoRaWAN® applications built on top of an HTTP server, using

HTTP POST as a communication method.
▪ IBM Watson® IoT: cloud applications leveraging the IBM Watson® infrastructure and
using IBM Watson® APIs as a communication method.
▪ Microsoft Azure® IoT Hub: cloud applications leveraging the Microsoft Azure®
infrastructure and using Microsoft Azure® APIs as a communication method.
▪ Message Queuing Telemetry Transport (MQTT) messaging protocol: LoRaWAN®

applications built on top of an MQTT server, using MQTT subscribe and publish as a
communication method.
▪ Other cloud computing platform applications platforms can be configured upon

request. Contact your Vendor or your ThingPark Channel.
Each application platform requires specific parameters, which may change from time to time
depending on API updates of the cloud computing platform. The up-to-date Application’s
parameter details are available at the following location:
https://dx-api.thingpark.com/dataflow/latest/product/connectors.html
7.3 Connecting Applications

After retrieving the Application parameter details, you can setup the connection between
ThingPark Enterprise and the selected Cloud Computing platform Application.
The configuration of all Applications is the same for all applications. Only the parameters to
fill in differ from one Application to the other.
7.3.1 Connecting to an HTTPS Application Server

7.3.1.1 REQUIRED PARAMETERS
You need to configure the following parameters:
Application ID ▪ Type of Application that you want to create.
Application Name ▪ Name of the Application that you want to register (Editable).
URL ▪ The URL of the application platform/server where the Device

data is sent to and received from.
Content Type ▪ The type of encoding used to report Device data to your
Application (XML or JSON format) (Editable).
Tunnel Interface ▪ A 32-hexadecimal digits with a high entropy that is associated

with the application to secure the uplink and downlink packets.
Authentication Key
Additional ▪ Any useful information that is related to the Application.

information
In addition, your HTTPS application server will need to understand and handle the Token
security key provided by ThingPark Enterprise, which is required to send downlink information
from the Application Server to ThingPark Enterprise. For more information, see the ThingPark
Enterprise LRC-AS Tunnel Interface Developer Guide LoRaWAN®.
7.3.1.2 Connecting an HTTPS Application in 2 Steps
1. Click Applications > Create or from the Dashboard, click .
 The following screen appears: XXXX_ creating_applications_2.2.2

2. Click the HTTPS Application type.
 A form (empty) that looks like this displays: XXXX https_application_5.2.2 XXXX

Note Parameters marked with * are mandatory.

4. Click Save.
 A message in a green box appears on the upper right side of your screen to
confirm that the Application has been created.
5. Click View the Application to view the application details.
 You are redirected to the Application Information frame.
7.3.2 Connecting to Amazon AWS IoT Platform
7.3.2.1 PREREQUISITES AND REQUIRED PARAMETERS

You must have an active Amazon AWS IoT account prior to connecting to an Amazon AWS IoT
Application. ThingPark does not create AWS application instances.
You will need to configure the following parameters:
Application Name
▪ Name of the Application that you want to register (Editable).
Downlink Port
▪ If downlink is supported and enabled, indicate which LoRaWAN ®
port should be used to send the downlinks to the associated
Devices. As only one type of Amazon AWS platform can be
created, you should set a homogeneous set of Devices in the
Amazon AWS IoT account.
Account Prefix
▪ Account Prefix of the AWS IoT account.
AWS Region ▪ Region that is hosting the AWS Application for example us-west-
2.
AccessKeyId ▪ Id of the access key for the AWS IoT account.
SecretAccessKey ▪ Secret access key for the AWS IoT account.
Protocol ▪ Protocol to be used for the connection with AWS IoT account -
WSS (MQTT over Web Services Security) or SSL (MQTT with
Secured Sockets Layer certificates).
Certificate Id ▪ Id of the certificate registered in your AWS IoT account.

▪ This parameter does not apply to the WSS protocol.
Certificate ▪ The certificate file registered in your AWS IoT account.

Private Key ▪ The private key file registered in your AWS IoT account.

DeviceType ▪ AWS IoT Device type to be associated with the Devices
processed by the Application for example waterSensorType.
Only one Device type is supported.
Topics ▪ Provides a list of port/link associations. Messages related to

uplink ports in that list, will be pushed to the corresponding
AWS IoT topics.
▪ Overrides ‘the Downlink Port’ parameter. Downlink port means
that on receiving a downlink on a specific topic, the downlink is
transmitted on a specific port. There is a relationship between
port and downlink because you need to define a port on the
reception of a downlink.
▪ Topic examples:
o If the port is 2, then the topic is humiditySensor.
o If the port is 3, then the topic is temperatureSensor.
Account Prefix
▪ Account prefix of the AWS IoT account in format alpha numeric.
▪ To obtain an AWS server URL you will need the account prefix
and the region attributes
<accountPrefix>.iot.<region>.amazonaws.com
In our example:
o "accountPrefix": "a2shubp7zpiozr"
o "region": "us-west-2"
The URL will be a2shubp7zpiozr.iot.us-west-2.amazonaws.com
For detailed information on Amazon AWS IoT configuration and parameters, see
https://aws.amazon.com/iot/

7.3.2.2 CONNECTING AN AMAZON AWS IOT APPLICATION IN 2 STEPS
You can connect this type of application using the SSL or the WSS protocol depending on the
security level that you want to put in place.
This procedure describes how you can connect an Amazon AWS application using the SSL
protocol. The difference between both protocols resides in the fact that there is neither a
certificate, nor a private key that are required for creating a connection via WSS.
1. Select the Amazon IoT application type as explained in 7.3.1.2 Connecting an HTTPS
Application in 2 Steps.

 A form (empty) that looks like this displays: XXXX aws_application_1 XXXXX


3. Select the SSL protocol. xxxx aws_application_2 xxxx
4. Click Save.
that the Application has been created.
5. Click View the Application to view the application details.
 You are redirected to the Application Information pane.

7.3.2.3 CHANGING THE PROTOCOL OF THE AMAZON AWS CONNECTION AFTER CREATION
You can change the protocol after the creation of the Amazon AWS application.
If you change the protocol from WSS to SSL, the Certificate ID, Certificate and Private Key fields
are displayed and highlighted in red if empty in order to alert you that they must be filled.
If you change the protocol from SSL to WSS, the Certificate ID, Certificate and Private Key fields
are hidden, but their current values are kept and still provided in dataflow properties. The
values are automatically recovered if the protocol is updated to "SSL", and the Certificate ID,
Certificate and Private Key fields are displayed again.
7.3.3 Connecting to Microsoft Azure Cloud Computing Service (IoT Hub)

You must have an Azure IoT Hub account prior to connecting your Azure IoT Hub Application.
You will need to fill-up the following information:
Application Name
Host Name
▪ The Hostname of your Azure IoT Hub account. Example:
myaccountname.azure-devices.net
IoT Hub Name
▪ Hub name of the IoT network
Primary key
▪ A valid key for the selected access policy within the Azure IoT
Hub account.
Access Policy Name
▪ The shared Access Policy Name within the Azure IoT Hub
account. Example: iothubowner.
Protocol
▪ Protocol to be used for the connection.
▪ Only ‘AMQPS’ protocol is supported. AMQP is to be used on field
and cloud gateways to take advantage of connection multiplexing
across Devices.
▪ Other protocols exist:
o HTTPS - Use for Devices that cannot support other
protocols.
o MQTT - Use on all Devices that do not require to connect
multiple Devices.
For detailed information on Microsoft Azure IoT configuration and parameters, see
https://docs.microsoft.com/en-us/azure/iot-hub/
7.3.3.2 CONNECTING TO AN AZURE IOT HUB APPLICATION IN 2 STEPS

1. Select the Azure AWS IoT Hub Application type as explained in 7.3.1.2 Connecting an
HTTPS Application in 2 Steps.

A form (empty) that looks like this displays: XXXX_azure_application_1_B_XXXX

3. Click Save.

 A message in a green box appears on the upper right side of your screen to confirm
4. Click View the Application to view the application parameters.
7.3.4 Connecting to a Beta IBM Watson IoT Platform

You must have a Beta IBM Watson IoT Application account prior to connecting your IBM
Watson IoT Application.
Application Name
Downlink port
▪ If downlink is supported and enabled, indicates which LoRaWAN®
port should be used to send the downlink to the Device.
Organization ID
▪ Identification number of the organization.
Device Type
▪ IBM Watson IoT Device type to be associated with the Devices
processed by the Application.
Gateway Type
▪ Watson IoT gateway type of the Watson IoT gateway that is used
by the Application.
Gateway ID
▪ ID of the gateway that is created in the Watson IoT account,
which is used by the Application.
Gateway Token
▪ Authentication token of the Watson IoT gateway that is used by
the Application.
API Key
▪ Watson IoT API key to be associated with the Application.
Authentication
Token ▪ The Watson IOT Authentication Token to be associated with the
Application.
Topics
▪ Provides a list of port/link associations. Messages related to
uplink ports in that list, will be pushed to the corresponding Beta
IBM Watson topics.
▪ Topic examples:
Additional
Information ▪ Any useful information related to the application.

For detailed information on IBM Watson IoT configuration and parameters, see
https://console.bluemix.net/docs/services/IoT/index.html#gettingstartedtemplate
7.3.4.2 CONNECTING TO A BETA IBM WATSON IOT APPLICATION IN 2 STEPS
1. Select the IBM Watson IoT Application type as explained in 7.3.1.2 Connecting an HTTPS

 A form (empty) that looks like this displays: XXXXibm_watson_application_1_AXXXX

3. Click Save.

7.3.5 Connecting to an MQTT Protocol-based Application

You must have deployed an MQTT server prior to connecting with the MQTT protocol-based
application. The MQTT server must be accessible from your ThingPark Enterprise server.
Name ▪ A name you want for your application that allows you to identify
it on your IoT network. For example, “Vehicle Tracking”, “Smart
Lighting”.
Application ID ▪ Application IDentifier
Downlink Port ▪ If downlink is supported and enabled, indicates the LoRaWAN ®

port used to send the downlink to the Device.
Hostname ▪ The hostname/IP and port of your MQTT server. For example,
“myhostname.com:8883”.
Account prefix ▪ The account prefix for all your topics.
Protocol ▪ Protocol to be used for your connection with your MQTT server.
Choose among SSL, WSS and TCP.
MQTT Username ▪ The username to access your MQTT server.
MQTT Password ▪ The password to access your MQTT server.
Certificate
▪ The client certificate file (X.509 with .crt format only) used to
connect to your MQTT server. Only required when you are using
double factor authentication (login/password and client
interface).
▪ This parameter does not apply to TCP protocol.

Private Key
▪ The client Private Key file (PKCS#8 format only) used to connect
to your MQTT server. Only required when you are using double
factor authentication (login/password and client interface).
▪ This parameter does not apply to TCP protocol.

Topics ▪ Provides a list of port/link associations. Messages related to

uplink ports in that list will be pushed to the corresponding MQTT
topics.
▪ Topic examples:
Additional
Information ▪ Any useful information related to the application.
7.3.5.2 CONNECTING TO AN MQTT PROTOCOL-BASED APPLICATION IN 2 STEPS
1. Select the MQTT Application type as explained in 7.3.1.2 Connecting an HTTPS


 A form (empty) that looks like this displays: XXXX mqtt_application_1_A XXXX

6. Click Save.
7.4 Managing Applications

After creating applications, you can manage them by first viewing and then modifying their
configuration.
7.4.1 Viewing all Applications

1. Click Applications > List.
The following screen appears and displays all existing applications with their associated
Devices. It also includes the MQTT Application. XXXXX all_applications_includng_mqtt

You can see the following information items:
Application Name
▪ Name of the Application.
AppId ▪ Application ID.
Devices ▪ Number of Devices that are associated to the Application
Last Uplink (UL) ▪ Timestamp of the Uplink radio that is received on the best Base
Station.
Last Downlink (DL) ▪ Timestamp of the Downlink radio that is sent on the best Base
Station.
7.4.2 Viewing/editing an Application

1. Click Applications > List.
2. In the Applications screen, select one of the Applications that are available.
3. Click the Application.
The application parameter screen presented in 7.3.1.2 Connecting an HTTPS Application in
2 Steps appears. You can update any parameter.
4. Click Save.
 A screen displaying the detailed Application parameters appears.

Note The detailed information screen of the Application also allows you to remove
the Application.
7.4.3 Checking the Deployment Status

The deployment status indicates if the application has been properly deployed on the
ThingPark Enterprise platform. The following table lists the possible status and the corrective
actions to take, if any.
Status Explanation Action to take

Awaiting
validation ▪ The application connector is
waiting to be validated for
▪ N/A
deployment (SaaS only).
Awaiting update ▪ The application connector is

waiting for the execution
▪ N/A
instance to be updated.

Status Explanation Action to take
Ready ▪ The application connector is
deployed and ready to be used.
▪ N/A
Deploy error ▪ The application connector could

not be deployed due to an error.
▪ Check the configuration
parameters.
Packets ▪ An error occurred in the

application connector during the
▪ Check the configuration
parameters.
processing error
uplink or downlink processing.
▪ The error may be caused by a

wrong configuration of the
application.
Unknown ▪ The application connector state

could not be retrieved.
▪ Contact your
Vendor or
your ThingPark
Channel.
7.4.4 Switching off the Activation Status

The Activation Status button allows you to temporary suspend the reporting of uplink
messages to the Application without having to delete the Application.
When an Application is switched off, uplink frames from its associated Devices are not
reported to the Application and the Application is not able to submit downlink payloads.
When you attempt to switch off the Application, a message displays on your screen asking you
to confirm that you want to deactivate the Application. You can reactivate your Application at
any time.
7.4.5 Viewing the Last 25 Uplink/Downlink Packets of an Application

1. Click Applications > List and the name of the application for which you want to
check the last 25 Uplink/Downlink Packets that are sent from/to the Device.
2. The last 25 Uplink/Downlink frames are presented as in the example below:

xxxx_last_25_packets_devices_xxxx

7.4.6 Checking the LoRaWAN ® Devices Associated to an Application
1. Perform steps 1 to 4 as described in 7.4.2 Viewing/editing an Application.
2. The list of Devices associated to the Application appears. XXXX_ four_associated_devices_XXXX
7.4.7 Checking the Communication History of the Application

1. Perform steps 1 to 4 in 7.4.2 Viewing/editing an Application.
 The recent communication history of the Application is presented as in the example

below.

2. Click the Payloads tab to view payload size time series.

8 ACTIVATING A DEVICE TO YOUR IOT NETWORK
8.1 Overview
This section explains how to commission Devices in the LoRaWAN® network.
Depending on your license, ThingPark Enterprise allows you to manage up to 20 000 Devices.
Note ThingPark Enterprise only supports the Over-the-Air Activation (OTAA) and not
Activation By Personalization (ABP). OTAA is the preferred and most secure way to connect
with Devices into the network. Devices perform a Join-procedure with the network, during
which a dynamic DevAddr is assigned and security keys are negotiated with the Device.
8.2 Activating Devices

You can connect several types of Devices with ThingPark Enterprise. As of editing this user
guide the following brands were supported, and more brands are added over time as
ThingPark Enterprise synchronizes with Actility Device profile repository:
▪ Abeeway
▪ Adeunis RF
▪ Digital Matter
▪ Finsecur
▪ Flashnet
▪ Foxconn
▪ FullUp sprl
▪ GlobalSat
▪ LoRaWAN® Generic Devices
▪ Multitech
▪ SemTech
▪ Sensing Labs
▪ Solvera Lynx
▪ Turbo Technologies Corporation
▪ Twave Technologie
▪ Watteco/NKE
Note Other brands can be connected upon request. Contact your Vendor or your ThingPark
Channel.

8.2.1 Main Device Parameters
You will need to configure the following parameters:
Device Name
▪ Name of the Device that you want to register
Device Model
▪ Name of the Device model.
▪ Each Device model is associated to a preconfigured LoRaWAN ®
profile template which ensures interoperability with the Device.
DevEUI ▪ Globally unique address of the Device. The DevEUI is usually
written on the Device casing. The DevEUI is based on IEEE
Organizationally Unique Identifier (OUI). The 24, 28, or 36
leading bits identify the vendor which the OUI was assigned by
the IEEE. All LoRaWAN® Device vendors must buy an IEEE OUI
block from IEEE.
▪ A DevEUI is composed of 32 hexadecimal digits (0 to 9, and A to
F), the first 6, 7 or 9 digits identify the Device manufacturer.
▪ Example: F0-3D-29-00-0B-B1-7A-AA.
JoinEUI (AppEUI)
▪ Global application ID that identifies uniquely the application
provider of the Device.
▪ The JoinEUI is a global application ID in IEEE EUI64 address

space that uniquely identifies the Join Server that is able to
assist in the processing of the Join procedure and the session
keys derivation for OTAA devices.
▪ Composed of 16 hexadecimal digits (0 to 9, and A to F). Is

provided by the Device manufacturer.
▪ This parameter is displayed as "JoinEUI (AppEUI)" for LoRaWAN ®

1.0 devices and "JoinEUI" for LoRaWAN 1.1® devices.
NwkKey ▪ Network Key. Encrypts the Device communication with the

network. It is composed of 32 hexadecimal digits (0 to 9, and A
to F).
▪ It is provided by the Device manufacturer.
▪ This is a LoRaWAN® 1.1 parameter.
AppKey ▪ The Application Key is an AES-128 key specific for each end-
Device, programmed in factory by the Device manufacturer. It
is used to derive the session keys that allow LoRaWAN® to
secure communication with the Network Server and the
Application Servers.
▪ The AppKey is provided by the Device manufacturer when you
purchase the Device. In the future, the manufacturer may also
provide you with an ownership claim key and a JoinEUI, which
together will allow ThingPark Wireless to reach the
manufacturer’s Join server and negotiate session keys without
ever communicating the AppKey in clear. Ask your Vendor or
your ThingPark Channel about Actility ThingPark Activation
Server for more information.
Additional
Information ▪ Any useful information related to the Device. It can be where
you want to install the Device for instance, a room for checking
humidity.
8.2.2 Creating a Device in 3 Steps

1. Click Devices > Create or from the dashboard, click the icon.
 The following screen displays: XXXX creating_a_device_in_3_stepsXXXX
2. To activate a Device, select one of the Device Manufacturers displaying on your screen.
a) If your Device Manufacturer is not displayed on your screen, click View More
Manufacturers.
 A more complete list of pre-configured manufacturers appears.

b) If the manufacturer or model is not listed, but you are a LoRaWAN ® expert and know
how to profile LoRaWAN® for this Device, select “Generic”.
 A form (empty) that looks like this displays:

Note A description of the manufacturer is displayed under the logo.
This differentiates IoT activities among several manufacturers.
4. Connect your Device to your Application.

a. In the ‘Associate Your Device With Your Application’s section, choose an
existing Application in the list that you want to connect to your Device.
5. Set your Device location.

a. Select the Device location in the location box. You may use Google Maps,
other supported maps or GPS geographical coordinates. For more
information, see 4.1.1 Prerequisites.
Note If the location using Google Maps does not display, it means that the Google Maps
API key has not been installed on the platform. For more information, see 4.1.1
Prerequisites.
6. Click Save.

 A message asks you to confirm if you want to duplicate or to view the Device. For
more information about duplicating a Device, see 8.5.5 Duplicating a Device.
7. Click View the Device to view the Device information.
8.3 Importing Devices in 2 steps

You can import up to 4000 Devices in a row instead of creating the Devices one by one.
The import functionality only applies to Devices that are associated with HTTP
applications.
1. Click Devices -> Import.

The following screen appears: xxxx Importing_devices_2_steps xxxx
2. Proceed as displayed on your screen.
a. Prepare your Device import file. Ensure that the format of your Device
import file complies with the .CSV file format given in the sample; click
SAMPLE FILE. For more information on HTTPS applications, see 7.3.1.
Connecting to an HTTPS Application.

In the .CSV file you will find a list that shows you the Devices’ models and their
corresponding models’ IDs. This list is as follows:
Manufacturer Name Model Name Device Model ID and their region

deployment
Finsecur Calypso (European ISECUR/CalypsoA.1_EU (Europe)

deployments)
Finsecur Calypso (American ISECUR/CalypsoA.1_US (USA)

deployments)
GlobalSat CO Temp Humidity - LS-112 - GLBSAT/LS-112_A.1_EU (Europe)

class A
GlobalSat CO Temp Humidity - LS-112 - GLBSAT/LS-112_A.1_US (USA)

class A
GlobalSat CO Temp Humidity - LS-112 - GLBSAT/LS-112_C.1_EU (Europe)

class C
GlobalSat CO Temp Humidity - LS-112 - GLBSAT/LS-112_C.1_US (USA)

class C
GlobalSat CO2 Temp Humidity - LS-111 - GLBSAT/LS-111_A.1_EU (Europe)

class A
GlobalSat CO2 Temp Humidity - LS-111 - GLBSAT/LS-111_A.1_US (USA)

class A
GlobalSat CO2 Temp Humidity - LS-111 - GLBSAT/LS-111_C.1_EU (Europe)

class C
GlobalSat CO2 Temp Humidity - LS-111 - GLBSAT/LS-111_C.1_US (USA)

class C
Solvera Lynx Combox L - 2T-B SLVRA/COMBOX-L_2T-B_A.1_EU

(Europe)
Solvera Lynx Combox L - CI-B SLVRA/COMBOX-L_CI-B_A.1_EU

(Europe)

deployment
Solvera Lynx Combox L - DI-B SLVRA/COMBOX-L_DI-B_A.1_EU

(Europe)
Abeeway Compact-Tracker ABEE/DEABE205-

177EU.1.0.2b_ETSI_Rx2-SF12
(Europe)

178US.1.0.2b_FCC_Rx2-SF12 (USA)

179AS.1.0.2b_AS_Rx2-SF10 (Asia)
Adeunis RF Demonstrator ADRF/DemonstratorA.1_EU (Europe)
Adeunis RF Field Test Device - class A ADRF/FielTestDeviceA.1_EU (Europe)
Adeunis RF Field Test Device - class A ADRF/FielTestDeviceA.1_US (USA)
Adeunis RF Field Test Device - class C ADRF/FielTestDeviceC.1_EU (Europe)
Adeunis RF Field Test Device - class C ADRF/FielTestDeviceC.1_US (USA)
Flashnet FRE-220 FHNT/FRE-220.1_EU (Europe)
Flashnet FRE-220 FHNT/FRE-220.1_US (USA)
FullUp sprl FuelUp FULLUP/FUELUPA.1_ETSI_Rx2-SF12

(Europe)
Sensing Labs Generic Senlab - class A SLABS/SenlabAB.1_EU (Europe)
Adeunis RF Generic Sensors - class A ADRF/SensorsA.1_EU (Europe)
GlobalSat GPS Tracker - LT-100E - class A GLBSAT/LT-100E_A.1_EU (Europe)
GlobalSat GPS Tracker - LT-100E - class A GLBSAT/LT-100H_A.1_US (USA)

deployment
GlobalSat GPS Tracker - LT-100E - class C GLBSAT/LT-100E_C.1_EU (Europe)
GlobalSat GPS Tracker - LT-100E - class C GLBSAT/LT-100H_C.1_US (USA)
GlobalSat GPS Tracker - LT-100H - class A GLBSAT/LT-100H_A.1_AS (Asia)
GlobalSat GPS Tracker - LT-100H - class C GLBSAT/LT-100H_C.1_AS (Asia)
Foxconn Infrared Motion Sensor - ZB11A FOXCONN/ZB11A.1_AS (Asia)
Foxconn Light Sensor - Z311G FOXCONN/Z311G.1_AS (Asia)
Semtech LoRaMote EU fw4 - class A SMTC/LoRaMoteA.1_EU (Europe)
Semtech LoRaMote EU fw4 - class C SMTC/LoRaMoteC.1_EU (Europe)
Generic LoRaWAN 1.0 - class A - LORA/GenericA.1_AS923_Rx2-

Rx2_SF10 SF10_1.0 (Asia)
Generic LoRaWAN 1.0 - class A - LORA/GenericA.1_ETSI_Rx2-SF12

Rx2_SF12 (Europe)
Generic LoRaWAN 1.0 - class A - LORA/GenericA.1_FCC_Rx2-SF12

Rx2_SF12 (USA)
Generic LoRaWAN 1.0 - class A - LORA/GenericA.1_ETSI_Rx2-SF9

Rx2_SF9 (Europe)
Generic LoRaWAN 1.0 - class A - LORA/GenericA.1_FCC_Rx2-SF9 (USA)

Rx2_SF9
Generic LoRaWAN 1.0 - class C - LORA/GenericC.1_AS923_Rx2-

Rx2_SF10 SF10_1.0 (Asia)
Generic LoRaWAN 1.0 - class C - LORA/GenericC.1_ETSI_Rx2-SF12

Rx2_SF12 (Europe)

deployment
Generic LoRaWAN 1.0 - class C - LORA/GenericC.1_FCC_Rx2-SF12

Rx2_SF12 (USA)
Generic LoRaWAN 1.0 - class C - LORA/GenericC.1_ETSI_Rx2-SF9

Rx2_SF9 (Europe)
Generic LoRaWAN 1.0 - class C - LORA/GenericC.1_FCC_Rx2-SF9 (USA)

Rx2_SF9
Generic LoRaWAN 1.0.2 - class A - revB - LORA/GenericA.1revB_IN865_Rx2-

Rx2_SF12 SF12 (India)
Generic LoRaWAN 1.0.2 - class A - revB - LORA/GenericA.1revB_AU915_Rx2-

Rx2_SF12 SF12 (Australia)
Generic LoRaWAN 1.0.2 - class A - LORA/GenericA.1_AS923_Rx2-SF10

Rx2_SF10 (Asia)
Generic LoRaWAN 1.0.2 - class A - LORA/GenericA.1_KR920_Rx2-SF12

Rx2_SF12 (Korea)
Generic LoRaWAN 1.0.2 - class A - LORA/GenericA.1_CN470_Rx2-SF12

Rx2_SF12 (China)
Generic LoRaWAN 1.0.2 - class C - revB - LORA/GenericC.1revB_IN865_Rx2-

Rx2_SF12 SF12 (India)
Generic LoRaWAN 1.0.2 - class C - revB - LORA/GenericC.1revB_AU915_Rx2-

Rx2_SF12 SF12 (Australia)
Generic LoRaWAN 1.0.2 - class C - LORA/GenericC.1_AS923_Rx2-SF10

Rx2_SF10 (Asia)
Generic LoRaWAN 1.0.2 - class C - LORA/GenericC.1_KR920_Rx2-SF12

Rx2_SF12 (Korea)
Generic LoRaWAN 1.0.2 - class C - LORA/GenericC.1_CN470_Rx2-SF12

Rx2_SF12 (China)

deployment
Generic LoRaWAN 1.0.2 revA - class A - LORA/GenericA.1.0.2a_ETSI_Rx2-

Rx2_SF12 SF12 (Europe)
Generic LoRaWAN 1.0.2 revA - class A - LORA/GenericA.1.0.2a_FCC_Rx2-SF12

Rx2_SF12 (USA)
Generic LoRaWAN 1.0.2 revA - class B - LORA/GenericB.1.0.2a_ETSI_Rx2-

Generic LoRaWAN 1.0.2 revA - class B - LORA/GenericB.1.0.2a_AS923_Rx2-

Rx2_SF12 SF12 (Asia)
Generic LoRaWAN 1.0.2 revA - class B - LORA/GenericB.1.0.2a_FCC_Rx2-SF12

Rx2_SF12 (USA)
Generic LoRaWAN 1.0.2 revA - class C - LORA/GenericC.1.0.2a_ETSI_Rx2-

Generic LoRaWAN 1.0.2 revA - class C - LORA/GenericC.1.0.2a_FCC_Rx2-SF12

Rx2_SF12 (USA)
Generic LoRaWAN 1.0.2 revB - class A - LORA/GenericA.1.0.2b_ETSI_Rx2-

Generic LoRaWAN 1.0.2 revB - class B - LORA/GenericB.1.0.2b_ETSI_Rx2-

Generic LoRaWAN 1.0.2 revB - class B - LORA/GenericB.1.0.2b_AS923_Rx2-

Generic LoRaWAN 1.0.2 revB - class B - LORA/GenericB.1.0.2b_FCC_Rx2-SF12

Rx2_SF12 (USA)
Generic LoRaWAN 1.0.2 revB - class C - LORA/GenericC.1.0.2b_ETSI_Rx2-

Generic LoRaWAN 1.1 revA - class A LORA/GenericA.1.1a_ETSI_Rx2-SF12

(Europe)

deployment
Generic LoRaWAN 1.1 revA – clas s A LORA/GenericA.1.1a_AS923_Rx2-

SF12 (Asia)
Generic LoRaWAN 1.1 revA - class A LORA/GenericA.1.1a_FCC_Rx2-SF12

(USA)
Generic LoRaWAN 1.1 revA - class B - LORA/GenericB.1.1a_ETSI_Rx2-SF12

Rx2_SF12 (Europe)
Generic LoRaWAN 1.1 revA - class B - LORA/GenericB.1.1a_AS923_Rx2-

Generic LoRaWAN 1.1 revA - class B - LORA/GenericB.1.1a_FCC_Rx2-SF12

Rx2_SF12 (USA)
Generic LoRaWAN 1.1 revA - class C LORA/GenericC.1.1a_ETSI_Rx2-SF12

(Europe)
Generic LoRaWAN 1.1 revA - class C LORA/GenericC.1.1a_AS923_Rx2-

SF12 (Asia)
Generic LoRaWAN 1.1 revA - class C LORA/GenericC.1.1a_FCC_Rx2-SF12

(USA)
Abeeway Master-Tracker ABEE/DEABE202-

(Europe)
Abeeway Master-Tracker ABEE/DEABE203-

Abeeway Master-Tracker ABEE/DEBAE203-

163AS.1.0.2b_AS_Rx2-SF10 (Asia)
Multitech mDot Box - class A MT/mdotboxA.1_US (USA)
Abeeway Micro-Tracker ABEE/DEABE003-

(Europe)

deployment



168AS.1.0.2b_AS_Rx2-SF10 (USA)
Nordic Automation Multical Module 1 NASYS/MULTICAL-M1-

Systems A.1.0.2b_EU_Rx2-SF12 (Europe)
NKE-Watteco NKE-NKE-Watteco fw 3.2 - WECO/GenericA.3.2_EU (Europe)

Generic - class A (deprecated)
NKE-Watteco NKE-NKE-Watteco fw 3.2 - WECO/GenericC.3.2_EU (Europe)

Generic - class C (deprecated)
NKE-Watteco NKE-Watteco fw 3.2 - Generic - WECO/GenericA.3.2_US (USA)

class A (deprecated)
NKE-Watteco NKE-Watteco fw 3.2 - Generic - WECO/GenericC.3.2_US (Europe)

class C (deprecated)
NKE-Watteco NKE-Watteco fw 3.4 - Generic - WECO/GenericA.3.4_EU (Europe)

class A
NKE-Watteco NKE-Watteco fw 3.4 - Generic - WECO/GenericA.3.4_US (Europe)

class A
NKE-Watteco NKE-Watteco fw 3.4 - Generic - WECO/GenericC.3.4_EU (Europe)

class C
NKE-Watteco NKE-Watteco fw 3.4 - Generic - WECO/GenericC.3.4_US (Europe)

class C
Digital Matter Oyster Tracker DMAT/OysterTrackerA.1_AS923_Rx2-

SF10 (Asia)

deployment
GlobalSat PM2.5 Temp Humidity - LS-113 GLBSAT/LS-113_A.1_EU (Europe)

- class A
GlobalSat PM2.5 Temp Humidity - LS-113 GLBSAT/LS-113_A.1_US (USA)

- class A
GlobalSat PM2.5 Temp Humidity - LS-113 GLBSAT/LS-113_C.1_EU (Europe)

- class C
GlobalSat PM2.5 Temp Humidity - LS-113 GLBSAT/LS-113_C.1_US (USA)

- class C
Laird Sentrius RS1xx series 455-0001 LAIRD/RS1xx.1.0.1_FCC_Rx2-SF12

(USA)
Laird Sentrius RS1xx series 455-0002 LAIRD/RS1xx.1.0.1_ETSI_Rx2-SF12

(Europe)
Twave Technologie Smove TWAVE/SmoveA.1_ETSI_Rx2-SF12

(Europe)
Turbo Technologies TBS-200 TBOTC/TBS200A.1_ETSI_Rx2-SF12

Corporation (Europe)
Foxconn Temp Humidity - Z716A FOXCONN/Z716A.1_AS (Asia)
Lansitec Temperature, Humidity LANSITEC/TmpHuA.1.0.2a_ETSI_Rx2-

SF12 (Europe)
Foxconn ufiSpace LoRa Parking Sensor FOXCONN/SKF800P-

923U_A.1_AS923_Rx2-SF10 (Asia)
PNI Sensor VS-NA915LR PNI/VS-NA915LR.1.0.2a_FCC_Rx2-

Corporation SF12 (USA)

 A .CSV file downloads.
Note The Device import only supports Devices associated with HTTP
applications.
b. After verification of your .CSV file, upload your Device import file and click
IMPORT.
The Devices are processed. The import results in two reports.

▪ A message displays that n Devices are successfully imported. Go to the Device
list to view all imported Devices.
▪ A message displays that n Devices are successfully imported
and y Devices failed to import with errors.. failed_file_import
3. Analyze and correct the errors in the .CSV file and re-import the file.
After successful Device import, go to the Device list to view all imported Devices.

8.4 Viewing Devices
8.4.1 Viewing all Devices
1. Click Devices > List.
The following screen appears and displays the first 100 Devices configured on the
system. If there are more Devices, paging will be used.
The Device type icons are decorated with a color bullet, corresponding to the overall Device
status. For more information about the colors of the bullets, see 5.1.4.2 Color Codes used for
Devices.
If the Device is not mains electric powered, and if the Device supports the DevStatusReq
LoRaWAN® command, the list also presents the battery status.
Green means good level (battery level is greater than 30%) range, low level (battery level is
comprised between 15% and 30%), red (battery level is lower than 15%) and grey means the
battery level is unknown (typically because the Device does not support the DevStatusReq
command).
A status filter in the upper right side of the list allows to select only Devices with a specific
status, that is, Initialization. The list is then filtered and only Devices in the selected state (that
is, Initialization) are displayed: 004_list_devices_initialization_state_4.2
Device statuses are explained in the previous section Devices > List.

8.4.2 Viewing and Editing Device Details
2. In the Devices screen, select a Device.
3. Click the name of the Device or any other parameter in the table.
A screen displaying the detailed Device parameters appears. You may also edit these
parameters. For more information, see 8.5.3 Updating Device Parameters.
8.5 Managing Devices

8.5.1 Overview
1. Modify the parameters of the Device, such as model, class, name and additional
information.
2. Duplicate the Device to quickly create a Device by using an existing Device as
template: the same vendor, model, AppEUI, additional information, application and
the same location are automatically selected.
3. Delete the Device from the LoRaWAN® Network Server.
4. Send downlink packets to the Device.
5. Monitor the connection status of the Device and RF signal quality, view network
activity recent history.
6. Manage associated Applications.
7. Update the Device location.
8. Determine which Base Stations receive the Device signal.
8.5.2 Device Parameters

The following Device parameters are used in the Device management user interface. These
are read-only parameters, unless otherwise notified.
Device Name
▪ Name of the Device (Editable).
Manufacturer
▪ Name of the Device manufacturer.
Class
▪ LoRaWAN® class of the Device, class A, B or C. (Editable)
Note Device class B is supported as of ThingPark Enterprise v6.0.

Model
▪ Device model, corresponding to a preconfigured LoRaWAN®
parameter template (Editable).

DevEUI
▪ Globally unique address of the Device. The DevEUI is usually
written on the Device casing. The DevEUI is based on IEEE
Organizationally Unique Identifier (OUI). The 24, 28, or 36
leading bits identify the vendor which the OUI was assigned by
the IEEE. All LoRaWAN® Device vendors must buy an IEEE OUI
block from IEEE.
▪ A DevEUI is composed of 32 hexadecimal digits (0 to 9, and A to
F), the first 6, 7 or 9 digits identify the Device manufacturer.
DevAddr
▪ 8-digit hexadecimal Device address in the LoRaWAN® network,
unique within the network and allocated by the Network Server.
▪ The most significant bits of the DevAddr identify a LoraWAN ®
network operator ID. Network identifiers are available to LoRa
Alliance® members and are needed if your Devices need to roam
out of your ThingPark Enterprise network (requires roaming
agreement with an operator; ask your Vendor or your ThingPark
Enterprise Channel for ThingPark Exchange roaming hub). If you
do not own a network identifier, the first 7 bits will be set to
‘0000000’, or ‘0000001’ which are reserved values for local
networks.
▪ Example: 00-AB-C4-89
Additional
Information ▪ Any useful information related to the Device. (Editable)
Last Uplink (UL)

▪ Last packet that was sent from the Device.
Last Downlink (DL)

▪ Last Downlink packet that was sent by the Network Server to
the Device.
Applications
▪ Applications associated with the Device.
Connection
▪ Device status: Active, Initialization, Radio Error or Connection
Error.
SNR
▪ Signal to Noise Ratio in Decibels (dB). Determines the quality of
LoRaWAN® reception. LoRaWAN® physical layer can receive
signals with negative SNR, up to about -20dB for SF12.
FCNT
▪ Frame Counter. There are separate uplink and downlink frame
counters. Whenever an uplink or downlink packet is sent, the
corresponding counter is incremented.
PER
▪ Packet Error Rate in percentage (%). Measures the ratio of
missing uplink packets to total uplinks.
RSSI
▪ Received Signal Strength Indicator. Measures in dBm the total
RF power received on a given RF channel, summing up the
desired LoRaWAN® signal and the background noise. When the
SNR is negative, it is a good approximation of the background
noise power.
ESP
▪ Estimated Signal Power measured in dBm. It is an estimate of
the LoRaWAN® useful signal power, computed from SNR and RSSI
estimates.

SF
▪ LoRaWAN® 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 best Base Station (LRR) in range for the Device, i.e.
with the best and most stable ESP value. It will be chosen for
downlink transmission.
8.5.3 Updating Device Parameters

1. Click Devices > List and then the name of the Device in the table for which you want
to change parameters.
The Device information panel appears as follows.: XXXX device_information_5.2.2XXXXX
2. Update or edit the parameter that you wish to change.

3. Confirm your changes.
4. Fill in above parameters, as requested.
Note You can change the Device model from class A to class C.
8.5.3.1 SENDING A TEST DOWNLINK FRAME

You may send a downlink frame to the Device in two different ways:
▪ From the Device details’ panel
▪ From the Device table
Note This functionality is active only when an application is connected.
1. In the Device Information frame that opens, click Send Downlink.

A Send Downlink box opens where you are asked to enter the payload and the target
LoRaWAN® port number.
a. Enter the desired Payload (FRMPayload in LoRaWAN® specification) that you want
to send to the Device in a downlink packet, in hexadecimal format. The maximum
size is 242 bytes: a hexadecimal digit (0 to 9, and A to F) with a multiple of 2 number
of digits, up to a maximal length of 484 digits
b. Enter the LoRaWAN® Port. This corresponds to the FPort in LoRaWAN®
specification, associated with the payload, with an integer value between 1 and
223.
c. The Network Server will always transmit a “confirmed” downlink data frame
towards the Device. Upon the reception of this data frame, requiring an
acknowledgement, the Device transmits a frame with the acknowledgement
(LoRaWAN® ACK bit set) at its own discretion (depends on attributes such as
LoRaWAN® Device class type and application). Once submitted and received, these
messages can be viewed in the Device ‘Last 10 packets’ table.
2. Click Validate.
The data payload is added to the Device downlink queue. The effective transmission of the
data payload in a downlink packet is scheduled according to the Device class and radio
conditions. There may be a long latency for class A Device, as downlinks may be sent only after
an uplink received from the Device. Some Devices provide means to force an uplink
transmission, refer to your Device documentation.
After successful sending or abort of the downlink packet containing the data payload, the
downlink packet is visible in the list of recent packets transmitted to the Device.
 A message in a green box appears on the right side of your screen to confirm that the
downlink has been sent to the Device.

8.5.4 Removing a Device
You have two ways to remove the Device from the LoRaWAN® network:
▪ From the Device details’ panel
▪ From the Device table.
1. Click Devices > List and the Device that you want to remove.
In the example, the Device information appears as displayed in the previous screen.
2. Click Remove Device.
 A message in a green box appears on the right side of your screen to confirm that
the Device has been removed.
8.5.5 Duplicating a Device

The following screen is displayed. XXXXX devices_5.2.2 XXXXX
2. Click the icon actions <…>, then select Duplicate.

 You are redirected to the edit Device screen. For more information, see 8.2.2
Creating a Device in 3 Steps.
3. Fill in the parameters, as requested.
8.5.6 Checking the Status Information of the Device

1. Click Devices > List and then the name of the Device or any other parameter in the
table for which you want to view the status of the Device.

The status information appears as follows: XXXX devices_status_5.2.2XXXX
8.5.7 Activating a Device with an Application

1. Click Devices > List and then the name of the Device or any other parameter in the
table for which you want to connect an Application.
2. Select the Application that you want to connect to the Device.
The Application selection drop down list appears: XXXXadd_an_application_5.2.2XXXX
3. Select an Application in the list.
4. Confirm your changes.

5. Click Add an Application if you want to add a new application to associate to your
Device.
confirm that the Application has been updated.
8.5.8 Modifying the Location of the Device

1. Click Devices - > List and the name of the Device for which you want to change the
location.
 A box where you can enter the location of the Device appears.
2. Click Change Location.
3. Select the types of coordinates that you need to locate your Base Station. Choose
between Google Maps, other supported maps or GPS geographical coordinates. For
more information, see 4.1.1 Prerequisites.
Note If the location using Google Maps does not display, it means that the Google Maps
API key has not been installed on the platform. For more information, see 4.1.1
Prerequisites.
Note To choose the Google Maps coordinates, you can also move the cursor related to
the Base Station over the map or click any location on the map. The cursor moves to the
position where you click.

4. Select Location using Google Maps, for instance.
A map where you can update the location of the Base Station appears.
XXXX location_information_changed XXXX
5. Enter the new location.
6. Click Save.
The location is updated and displayed in the Location area.

Note If the widget is deactivated, you will see a message that looks like this:
“The widget has been deactivated. You should configure a Google API key to enable the
widget”. For more information, see the ThingPark Enterprise Installation Guide.

8.5.9 Checking the Radio Communication History of a Device
1. Click Devices > List and the name of the Device or any other parameter in the table
for which you want to check the radio traffic.
The radio traffic timeline appears as follows: ffic_history_devices_4.2
2. Click the Payloads tabs to monitor payload sizes.

The payloads timeline appears as follows.: radio_traffic_history_payloads_4.2
3. Click the ‘Uplink’, ‘Downlink’ or ‘Downlink Failed’ to filter the corresponding

attribute.

8.5.10 Monitoring Device Uplink ESP
1. Click Devices > List and the name of the Device or any other parameter in the table
for which you want to check the ESP level.
The uplink Signal to Noise timeline for the Device appears as follows:
XXXXXradio_statistics_devices_ESP_5.2.2
In the example, the mean Estimated Signal Power (ESP) per Device is given.
Select another graph if you want to display the Packet Error Rate (PER), the Received Signal
Strength Indicator (RSSI), the Signal to Noise Radio (SNR) or the Spreading Factor (SF).
8.5.11 Viewing Recent Uplink / Downlink Activity of a Device

1. Click Devices > List and the name of the Device in the table for which you want to
view the last 10 Uplink/Downlink frames.

The last 10 Uplink/Downlink frame sequence is displayed as follows:
XXXX last_ten_packets_devices_5.2.2XXXX
For each type of radio activity of a dedicated uplink or downlink frame a range value is defined
as illustrated in the following table.
Radio metric Range High Range Low Unit

ESP 0 - 142 dBm
RSSI 0 - 125 dbm
SNR 15 - 24 dB
SF 7 12 SF
A color code is associated with each value or range value as depicted in the following table.
Color associated RSSI SNR SF ESP

with the type of
Radio Activity
Red N/A SNR <= -16.5 12 - 135
Orange N/A -14 <= SNR < -16.5 11 - 130
Dark green N/A -11.5 <= SNR < -14 10 -120
Intermediate N/A -9 <= SNR < -11.5 9 - 110
Green -1

Color associated RSSI SNR SF ESP
with the type of
Radio Activity
Intermediate N/A -7 <= SNR < -9 8 - 100
Green 2
Light Green N/A SNR > -7 7 - 90
2. Scroll down to display SHOW ALL.
 This takes you to the Wireless Logger application to view the entire traffic history and
obtain additional details. For more information, see 10.5 Using Network Tools.

9 THINGPARK ENTERPRISE API
All operations available via the user interface, and more, are available via REST
OpenAPI/Swagger APIs.
An overview of this API platform is available at https://dx-api.thingpark.com/platform/
The detailed swagger contracts are documented in:
▪ https://<domain>/thingpark/dx/core/latest/doc/index.html
▪ https://<domain>/thingpark/dx/admin/latest/doc/index.html
The dataflow contracts are documented at:

https://<domain>/dx-api.thingpark.com/dataflow/latest/doc/index.html

10 MANAGING A THINGPARK ENTERPRISE INSTANCE
10.1 Overview
1. Manage usage license granted to the platform.
2. Manage user accounts.
3. View and update the catalogs of Base Stations and Devices to update the list of
preconfigured model templates.
4. Update RF Region Catalogs.
5. Use the ThingPark Wireless Logger for advanced monitoring of LoRaWAN® traffic. For
more information, see the ThingPark Wireless Logger User Guide.
6. Use the ThingPark Survey Tool, that is, visualize Device data (radio metrics, payload
information) on the map. For more information, see the ThingPark Wireless Network
Survey User Guide.
7. Use the ThingPark Spectrum Analysis Tool to display noise-scan results generated by
the Base Station, and to determine the noise level seen by each frequency within the
defined spectrum. For more information, see the ThingPark Wireless Spectrum
Analysis User Guide.
8. Manage ThingPark Enterprise alarms.

10.2 Managing the License
The number of licenses depends on what you have purchased. For more information, see 4.1.2
Required Licenses.
1. Click Manage > Operating Management.

The following screen displays. XXXX_license_5.2.2_SAAS_XXXX
The license information indicates the maximum number of devices and the maximum number
of Base Stations that have been granted to your Enterprise.
To increase your license, contact your Vendor or your ThingPark Enterprise Channel.

10.3 Managing User Accounts
10.3.1 Creating User Accounts
1. Click Manage > User Accounts > Create or from the Dashboard, click .
The following screen appears.
2. Enter the parameters above.

3. Click Save.
that the user account has been created.
Creating the user account redirects you to the User Accounts Administration screen where
you can see that the user account is visible in the account’s table.

10.3.2 Viewing User Accounts
1. Click Manage > User Accounts > List.
The following screen appears. user_accounts_administration_5.1.5
You can view the latest connection date per user and their status.
10.3.3 Modifying or Deleting User Profiles

2. Move the mouse above the <…> symbol of the line you want to edit.
A pop-up window appears displaying options modify, delete and reset user password.
3. Select Modify user or Delete User
confirm you that the action has been performed.
Note In this release all administrator users have the same access rights and privileges.
Creating, Modifying and Deleting users is an available operation to all users.

10.3.4 Resetting User Password Settings
You have to follow the rules described in 5.3.3 Filling in My Profile to change your password
settings.
2. Move the mouse above the <…> symbol of the line corresponding to the selected user.
A pop-up window appears displaying a menu used to modify a user, delete a user or
reset the user password as shown in 10.3.3 Modifying or Deleting User Profiles.
3. Select Reset password.
confirm that the action has been performed.
10.3.5 Session Expiration

If your ThingPark Enterprise platform is not active for 12 hours, your session expires. A
message telling you that your session is expired displays on your screen. You will need to log-
in again.
1. Enter your password.

2. Click OK.
You are redirected to the ThingPark Enterprise dashboard.

10.4 Managing Catalogs in ThingPark Enterprise
You can trigger catalog updates at any time.
The update procedure can be used for initial loading of catalogs when first logging-in to
ThingPark Enterprise, and later to update these catalogs.
Note To update the catalogs ensure that the ThingPark Enterprise server is connected to
internet.
10.4.1 Managing Catalogs of Base Station Models
10.4.1.1 UPDATING CATALOGS OF BASE STATION MODELS

The following screen appears: XXXX_base_station_models_5.2.2_update_library_XXXX
2. Click Update Library.
 The catalog is automatically upgraded to the latest version which is displayed on your
screen.
10.4.1.2 VIEWING CATALOGS OF BASE STATION MODELS

The following screen appears. XXXXX base_station_models_5.2.2XXXXX

In the previous screen you can see that the catalog version of the Base Station models is
already present in the ThingPark Enterprise library. The models are up-to-date. You do not
have anything to do.
10.4.2 Managing Catalogs of Device Models
10.4.2.1 UPDATING CATALOGS OF DEVICE MODELS

The following screen appears. XXXX_device_models_5.2.2_update_library_XXXX
2. Click Update Library.
screen.
10.4.2.2 VIEWING CATALOGS OF DEVICE MODELS

The following screen appears. XXXXX device_models_5.2.2 XXXX
In the previous screen you can see that the catalog version of the Device models is already
present in the ThingPark Enterprise library. The models are up-to-date. You do not have
anything to do.

10.4.3 Managing RF Region Catalogs
Each RF Region available in the ThingPark Enterprise catalog provides a set of RF configuration
parameters and RF channel plan compatible with the ISM band and the associated regulatory
rules of the country in question.
10.4.3.1 UPDATING RF REGION CATALOGS

The following screen appears. XXXXX rf_region_catalog_5.2.2_update_catalog XXXXX
1. Click Update Catalog.
screen.
10.4.3.2 VIEWING RF REGION CATALOGS

The following screen appears. XXXX rf_region_catalog_up_to_date_5.2.2XXXX
In the previous screen you can see that RF Region catalog version is already present in the
ThingPark Enterprise library. The catalog is up to date. You do not have anything to do.

10.5 Using Network Tools
10.5.1 Main Concepts
You must fill in the following parameters.
DevAddr ▪ Device Address on the LoRaWAN® network, allocated by the LRC

and unique on the network.
▪ Composed of 8 digits (0 to 9, and A to F), it identifies the
Device on the current network. The most significant 7 bits of
the DevAddr are the LoraWAN® network operator ID.
▪ Example: 05-AB-C4-89 or 14-77-5E-A1
DevEUI ▪ Globally unique address of the Device provided by the Device

manufacturer.
▪ Composed of 16 digits (0 to 9, and A to F), the first 6, 7 or 9
digits identify the Device manufacturer.
LRR Id ▪ Designates the Long-Range Relay (Actility’s name for a

LoRaWAN® Base station) Unique Identifier on the network.
LRC Id ▪ Designates the Long-Range Controller (Actility’s name for a

LoRaWAN® Network Server (NS8) Unique ID.
10.5.2 Using the Wireless Logger

1. Click Manage > Operating Management > Network Tools. xxxnetwork_tool_wireless_logger_4.2XXX
The following screen appears:
2. Click Wireless Logger.

The following screen appears:
The signification of the range values of each type of radio activity and the colors used
to illustrate these values is given in 8.5.11 Viewing Recent Uplink / Downlink Activity
of a Device.
For further use of the ThingPark Wireless Logger, contact your Vendor or your
ThingPark Channel.
10.5.3 Using the Network Survey Tool
1. Click Manage > Operating Management > Network Tools.
The following screen appears. XXXX network_survey_tool_5.1.5 XXXX

2. Click Network Survey Tool.
The following screen appears. xxxxnetwork_survey_tool_details_5.1.5xxxx
For further use of the ThingPark Network Survey Tool, contact your Vendor or your
ThingPark Channel.
10.5.4 Using the Spectrum Analysis Tool
1. Click Manage > Operating Management > Network Tools.

The following screen appears. xxxx spectrum_analysis_5.1.5 xxxx
2. Click Spectrum Analysis Tool.

The following screen appears. xxxx spectrum_analysis_details_5.1.5xxxx
For further use of the ThingPark Spectrum Analysis Tool, contact your Vendor or your
ThingPark Channel.

10.6 Managing ThingPark Enterprise Base Stations and Devices
Alarms
10.6.1 Overview
This chapter describes common alarms concepts and explains how to perform the following
tasks:
▪ Manage alarms to prioritize corrective actions when required.
▪ Send notifications to designated recipients for the user to take the proper corrective
actions regarding faulty Base Stations or Devices.
▪ Set alarms thresholds to Base Stations and Devices to identify a low uplink activity
causing the malfunction of the LoRaWAN® network.
10.6.2 Concepts
To monitor a LoRaWAN® network ThingPark Enterprise uses an alarm management system.
An alarm in ThingPark Enterprise is a visible signal used to indicate to the enterprise that an
equipment malfunction, a process deviation or an abnormal condition requires a response.
When a fault occurs on a Base Station or a Device, an alarm is raised in ThingPark Enterprise.
The system qualifies the alarm and assigns it a with a specific state: an Indeterminate, a
Warning, Minor, Major, Critical or Cleared state is set. For more information on alarm’s states,
see 10.6.4 Viewing Alarms in the User Interface.
The state of each type of alarm changes as it is subject to triggering and clearing conditions.
These conditions are based on the Network Server (Base Stations or Devices) reports and time
stimulus.
The alarm generation process is illustrated in the following graphic. XXXX alarm_clearing XXXX
▪ When the triggering conditions are satisfied, an alarm is created, an existing alarm is
updated (if not cleared) or an existing Alarm is recycled (if cleared).
▪ When the clearing conditions are satisfied, an existing alarm is cleared.

Alarms can be acknowledged (Acked) by users. Acknowledgement has no impact over the
alarm severity state.
An alarm not cleared and Acked is automatically unacknowledged if the alarm severity
increases.
A cleared alarm is recycled if the same alarm is triggered again. Hence a cleared alarm never
expires.
When an alarm cleared is recycled, the number of occurrences is reinitialized. In all other
cases, the number of occurrences is incremented each time the alarm is triggered once again.
Alarms are deleted when the associated Device or a Base Station is deleted.
There are two specific types of alarms for which you can configure thresholds in ThingPark
Enterprise:
▪ A Device no uplink activity alarm that applies when no Device uplink activity has
occurred in a certain period.
▪ A Base Station low uplink activity alarm that applies if a Base Station has encountered
a low uplink activity in a certain period.
These types of alarms have the same state as service or fault-related alarms.
When an alarm is triggered or when the severity state of an alarm changes, a recipient or
recipients receive an email notification. If an alarm is Acked, the notification is only sent if the
severity state of the alarm increases. This requires a pre-configuration of the email
notification. For more information, see 10.6.9 Creating Notifications.
10.6.3 Definitions
An alarm in ThingPark Enterprise has the following characteristics:
Alarm Description
characteristics
State
▪ Severity state of the alarm
Alarm Name
▪ Alarm name
Base Station
Name / Device ▪ Name of the Base Station/Device related to the alarm
Name
LRR ID / DevEUI
▪ Base Station ID
▪ Device Global Unique Identifier
Date
▪ Timestamp of the last occurrence or last state of the alarm
Occurrence
▪ For an event-driven alarm, the number of occurrences increases each
time the event associated with the alarm is detected.

Alarm Description
characteristics
▪ For a state-driven alarm, the number of occurrences is not applicable

and always set to 1.
Acked
▪ Confirms the acknowledgment of the alarm. The acknowledgement
cannot be reversed.
▪ You can select the Acked state by ticking the corresponding box.
An alarm raise can be associated with an email notification. For more information, see 10.6.9
Creating Notifications.
10.6.4 Viewing Alarms in the User Interface

Alarms are represented graphically in a dashboard within the User Interface of the TPE
platform. The dashboard looks like this: . XXXX alarms_dashboard_5.1.5 XXXXX
The Base Station Alarms’ widget and the Device Alarms’ widget display a global view of the
severity states of Base Stations and Devices’ alarms.
Two pie charts distribute the severity states of Base Stations and that of the Devices: critical,
major, minor, warning and indeterminate.

The following table explains the alarms’ severity states color codes.
Severity State Definition
Critical
▪ The service is affected. An immediate corrective action is required.
Major
▪ The service is partly affected. An urgent action is required.
Minor
▪ A fault that does not affect the service should be corrected to prevent
the problem from aggravating further.
Warning
▪ A potential or impending fault affecting the service should be diagnosed
and corrected, if necessary.
Indeterminate
▪ The severity cannot be determined.
Clear
▪ The alarm has been fixed.
▪ Alarms in "Clear" state are not visible in the pie charts but are visible in
the Alarms’ table.
The following screen illustrates the different severity states of Base Station’s alarms.
XXXXalarms_base_stations_5.2.2XXX
You can filter alarms by severity states.

Alarms are ordered by Acked status (not Acked alarms first), then by last update timestamps
in a decreasing order.
All alarms are displayed:
▪ Cleared or not cleared alarms.
▪ Acked or not Acked alarms are displayed.
All alarms are visible on the User Interface even if you acknowledge them.

Expanding an alarm state, as shown in the preceding screen, deploys the alarm state’s details
and the troubleshooting actions for the user to do. For further information, see the ThingPark
Enterprise Troubleshooting Guide.
10.6.5 Management of Alarms’ Occurrences

The TPE platform manages the number of occurrences of alarms that are raised according to
a classification of alarms.
▪ State-driven alarms
▪ Event-driven alarms
For a state-driven alarm, the number of occurrences is not applicable and always set to 1.
For an event-driven alarm, the number of occurrences increases each time the event
associated with the alarm is detected. Hence, a high number of occurrences of an event-driven
alarm can be considered as an aggravating factor of the severity of the alarm.
Note Existing alarms are not migrated. Hence, existing state-driven alarms with a number of
occurrences greater than 1 will still exist after an upgrade. For these alarms, the number of
occurrences will be reset to 1 when the alarm will be recycled (that is, updated from clear to
non-clear state).
The following tables detail this categorization.
10.6.5.1 DEVICE ALARMS TRIGGERED BY A STATE
Alarm number Alarm description
001
▪ Battery level threshold
004
▪ No uplink activity warning
005
▪ Node uses higher data rate than expected
006
▪ Node uses lower data rate than expected
012
▪ MAC command transmission blocked because of rejection
013
▪ MAC command transmission blocked because of no reply

10.6.5.2 DEVICE ALARMS TRIGGERED BY AN EVENT
002
▪ Traffic exceeds the downlink regulator settings
003
▪ Traffic exceeds the uplink regulator settings
007
▪ Join request replay detected (DevNonce replay)
008
▪ Wrong MIC detected in Join request
009
▪ Join request replay detected (wrong MIC correlation)
010
▪ Uplink frame replay detected (wrong FCnt)
011
▪ Uplink frame replay detected (repeated FCnt)
014
▪ Invalid AppEUI detected in Join request
015
▪ Join request replay detected (invalid DevNonce)
016
▪ Wrong MIC detected in Uplink frame
10.6.5.3 BASE STATION ALARMS TRIGGERED BY A STATE
102
▪ Base station connection status
103
▪ Unusually low uplink traffic level
104
▪ Unusually high level of invalid uplink physical CRC
105
▪ Downlink frame rate exceeds the RF cell capacity
106
▪ Unusually high CPU usage level
107
▪ Unusually high RAM usage level
108
▪ Unusually high file system usage level
109
▪ Time synchronization lost

110
▪ Power failure detected
111
▪ Beacon transmission failure
112
▪ Abnormal log activation
121
▪ Backhaul network interface status
10.6.5.4 BASE STATION ALARMS TRIGGERED BY AN EVENT
101
▪ LRR software restarted by watchdog
114
▪ Wrong MIC detected in Join request
115
▪ Join request replay detected (wrong MIC correlation)
116
▪ Uplink frame replay detected (wrong FCnt)
117
▪ Wrong MIC detected in Uplink frame
118
▪ Uplink frame replay detected (repeated FCnt)
119
▪ Invalid AppEUI detected in Join request
120
▪ Join request replay detected (invalid DevNonce)

10.6.6 Alarms Used for Troubleshooting Base Stations
You can use the following tables to help you troubleshoot Base Stations. They explain the
meaning of each alarm, its probable cause and corrective actions.

10.6.6.1.1 System Alarms
Alarm Alarm name Explanation Possible Root Causes Guidelines

ID
101 LRR software Base Station The alarm gets triggered once Use the remote access to
restarted by software gets the watchdog process stops collect logs and contact your
watchdog rebooted by the receiving reporting signals from support. For more information,
system protection LRR on its working state within a see 6.5.7.1 Using the Remote
algorithm via set period of time. Access.
execution of the
proper keystrokes
102 Base Station Informs on Base Six diverse alarm states occur Check the Base Station power
connection Station’s connection accordingly to Base Station’s for potential power failure.
status status to ThingPark administrative state (active,
LRC-cluster validating, suspended) along
Check the Ethernet/Cellular
with Base Station’s connection
state (never connected, connection for potential
disconnected). network failure.
▪ The BS is not yet

Check if the lrr.x process is
validated by the
administrator (minor running, restart it if needed.
alarm by default)
Check if LRC-cluster has
▪ The BS has been
restarted, causing
suspended by the
administrator (major disconnection of the LRR-LRC
alarm by default) link.
▪ The BS is
Use the remote access to
administratively active
collect logs and contact your
but has never connected
support. For more information,
to the core network
see 6.5.7.1 Using the Remote
(warning alarm by
Access.
default)
▪ The BS is
administratively active
but is disconnected
from the core network
(critical alarm by
default)

ID
106 Unusually CPU usage reaches The alarm gets triggered once Use the remote access to
high CPU an abnormal level the CPU’s average and standard collect logs and contact your
usage level deviation cumulated load support. For more information,
exceeds 85%:
▪ Warning alarm if
Access.
average + standard
deviation of the CPU
load > 85%
▪ Major alarm if average +

standard deviation of
the CPU load > 95%
107 Unusually RAM usage reaches The alarm gets triggered once Use the remote access to
high RAM an abnormal level the RAM’s average and standard collect logs and contact your
usage level deviation cumulated load support. For more information,
exceeds 80%:
Access.
average + standard
load > 80%

the CPU load > 90%
108 Unusually File-system usage The alarm gets triggered once Use the remote access to
high file reaches an abnormal the file-system average and collect logs and contact your
system usage level standard deviation cumulated support. For more information,
level load exceeds 95%:
Access.
average + standard
load > 95%

the CPU load > 99%

ID
109 Time
synchronizati
The Base Station uses
the local time instead
▪ NTP launched before Connect on the Base station
and restart the NTP: settime
getting an IP address.
on lost of using the NTP time restart.
reference. ▪ The Base station
restarted but the NTP Use the remote access to
was not launched collect logs and contact your
correctly support. For more information,
Access.
110 Power failure
detected
Power supply defect
detected; the Base
▪ Base station ▪ Check the connection
disconnected from the of the Base station to
Station is running on grid the grid.
battery.
▪ Power grid failure ▪ Check the power of the
grid.
112 Abnormal log
activation
▪ Critical ▪ Log is activated without ▪ Activate RAM disk
alarm: Log is RAM disk usage usage if not already
activated activated.
with trace ▪ Log is activated since
level > 0
several days ▪ If an ongoing
troubleshooting
without RAM
session does not justify
disk usage.
the log activation,
▪ Major alarm: deactivate it.
Log is
activated
If the alarm persists, contact
with trace
your support if the LRR trace
level > 0 for 7
level cannot be set to 0.
days (by
default)
Note In some cases when a
Base Station makes many
insertions into flash memory, it
might damage the normal
usage and behavior of the Base
Station.

ID
121 Backhaul
network
At least one backhaul
link of this Base
▪ IP address issue, e.g. ▪ Use manual IP address
due to DHCP. allocation in case of
interface Station is lost DHCP issue.
status ▪ For cellular interface:
3G/LTE network failure, ▪ Check the interface
no SIM card, bad configuration in the
network coverage. LRR and correct
configuration issues if
▪ Bad configuration of the
needed.
backhaul interface in
the LRR ▪ For alarms related to
cellular backhaul check
cellular network
coverage, SIM card
status and subscription
with cellular operator

10.6.6.1.2 RF Cell Alarms

ID
103 Unusually low
uplink traffic
No uplink frame for
more than X hours;
▪ No Devices in the LRR ▪ Check if there is an
covered area. active Device in the
level the number X defines area covered by the
the alarm state and ▪ LRR signal interfered by
Base Station.
can be configured. an external jammer
For more
▪ LRR RF chain defect ▪ Check if an RF
information, see equipment has been
10.6.8 Uplink Activity installed next to the
Alarms. Base Station (causing
potential interference).
▪ Scan the radio on the

Base Station to check
the noise level.

your Support.
104 Unusually high

level of invalid
LoRa frames received
by the LRR (on the
▪ Number of packets ▪ If the uplink duty cycle
generated by devices in of the Base Station is
uplink physical last hour) cannot be the cell is too high high, switch off some
CRC demodulated (frame collisions). Devices.
properly, or there are
many non-LoRa ▪ Noise generated by ▪ Check if an RF
frames received by another LoRa® equipment has been
the gateway with network's gateway installed next to the
physical preamble nearby. Base Station (causing
similar to LoRa®. potential interference).
▪ Jammer/Non-LoRa®
equipment is interfering ▪ Scan the radio on the
(most likely if ratio is Base Station to check
very high). the noise level.
▪ LRR RF chain defect.

your support.

ID
105 Downlink
frame rate
This alarm is raised
when downlink
Too many LoRaWAN®
acknowledgments or
▪ Reduce the
acknowledgements
exceeds the RF packets are dropped reconfigurations attempts requested by your
cell capacity by the Base Station Devices.
(received by the LRR
but not sent over- ▪ Reduce the downlinks
the-air) because the sent by your
RF cell modem was applications.
busy. Therefore, the
LRR was not able to ▪ Have a better
send these downlink repartition of the
packets (e.g. a downlink MAC
downlink packet of a reconfiguration
class 'A' Device for messages (e.g. RF
which the Region updates) over
transmission window time to prevent
is outdated). temporary saturation
of downlink capacity.
▪ Add a new Base Station

to your network.

your support.
111 Beacon
transmission
A failure linked to the
transmission of the
▪ Radio is stopped. ▪ Check the radio status
of the Base Station.
failure last time- ▪ Listen Before Talk (LBT)
synchronized beacon procedure did not allow ▪ Check the GPS status of
from the Base Station the transmission. the Base Station.
to the Class B Device.
▪ GPS synchronization is ▪ Check the duty cycle on
lost. Beacon RF sub-band.
▪ Beacon is received too ▪ Check if the latency

late for beacon slot. between the Base
Station and the
▪ Duty cycle constraint is
network server is
reached.
reasonable.

your support.

ID
113 Join request
replay
A repetitive request
for a Device
▪ A malicious user: The If the number of the alarm
occurrences is high:
Base Station is the
detected
(DevNonce
activation (Join
Request) using the
victim of a join request ▪ Check if the Device
replay attack. sent a join request
replay) same DevNonce has containing a DevNonce
been detected by ▪ The Device sent a join
already used and fix it.
ThingPark for the request containing a
same Device. DevNonce already used. ▪ The Base Station may
be the victim of a join
request replay attack.
Stop the radio and try
to identify the attacker.
your support.
114 Wrong MIC

detected in
A wrong MIC has
been detected in a
▪ The LRR is the target of If the number of the alarm
a join request replay occurrences is high:
Join request Join request, failing attack. 1. Check the Device's
to authenticate the
information and behavior
activation request for ▪ A Device sent a join
and fix issues.
the Device in request containing a
question. wrong MIC possibly due 2. The Base Station may be
to wrong Device the victim of a join request
provisioning (that is, bad replay attack. Stop the
Appkey). radio and try to identify the
attacker.
your support.
115 Join request A wrong MIC If the number of the alarm Stop the radio and try to
replay correlation has been occurrences is high, the Base identify the attacker.
detected detected between a
Station may be the victim of a
(wrong MIC Join request and the
correlation) following Uplink join request replay attack. If the alarm persists, contact
frame, invalidating your support.
the last join request
received from this
Device.

ID
116
Uplink frame
A wrong FCnt has
been detected in an
▪ The LRR is the target of ▪ If the number of
an uplink frame replay occurrences is high:
replay Uplink frame. attack. stop the radio and try
detected
to identify the attacker.
(wrong FCnt) ▪ A Device reset has not
been detected by the ▪ Reset the security
Network Server. context of the Device,
if and only if the Device
has really reset while
this reset was not
detected by the
Network Server.
117 Wrong MIC

detected in
A wrong MIC has
been detected in an
Uplink frame Uplink frame, failing attack. 1. If the Device has sent an
to authenticate the
uplink packet containing a
frame. ▪ A Device sent an uplink
wrong MIC, fix it (check
frame containing a
wrong MIC (for instance, NwkSKey).
bad NwkSKey 2. The Base Station may be
provisioned for ABP the victim of a join request
Device). replay attack. Stop the
radio and try to identify the
attacker.
your support.
118 Uplink frame

replay
A repeated FCnt has
been detected in an
detected Uplink frame. attack 1. Stop the radio and try to
(repeated
identify the attacker.
FCnt) ▪ A Device exceeds its
2. Check the behavior of the
configured number of
transmissions Device and fix it if needed.
If the alarms persist, contact
your support.

ID
Invalid AppEUI An invalid AppEUI The AppEUI value has changed If the Device has used more
119
detected in has been detected in too many times for this Device. than 32 different AppEUIs, fix
Join request a Join request. it.
If the alarms persist, contact
your support.
120 Join request A DevNonce attack If the number of the alarm If a join request replay attack:
replay has been detected in occurrences is high, the Base stop the radio and try to
detected a Join request when Station may be the victim of a identify the attacker.
(invalid the Device is join request replay attack.
If the alarms persists, contact
DevNonce) supposed to use
your support.
counter-based
DenNonce.
10.6.7 Alarms Used for Troubleshooting Devices

You can use the following tables to help you troubleshoot Devices. They explain the meaning
of each alarm, its probable cause and corrective actions.

ID
001 Battery level The power of the The battery of the Device has a Change the battery of the
threshold battery is very very low power. Device.
low.
(state-driven)
002 Traffic exceeds
the downlink
The Device is
receiving too
▪ Too many 1. Check the downlink packets
sent to verify if the Device's
acknowledgments or
regulator many packets. downlink packets from behavior is normal.
settings application servers. 2. If the alarm persists, contact
(event-driven)
▪ The limit set by the your support.
administrator does not
match the Device behavior.
003 Traffic exceeds The Device The Device may send too many 1. If the power level of the
the uplink exceeds the packets. It may quickly discharge Device is low, change the
regulator administrator the battery. battery.
settings policy.
2. Reduce the number of
(event-driven) packets sent by the Device.
3. If the alarm persists, contact
your support.

ID
004 No uplink
activity
The Device has
not sent any
▪ The Device is OFF. 1. Check if the Device is ON.
warning packet for the ▪ No power or power too low 2. If the power level of the
Device is low, change the
to transmit packets.
past X hours
(state-driven) battery.
according to the ▪ The Device cannot connect
3. If the Device is not located
thresholds you to the network.
have defined. For in the coverage area of the
more information, ▪ Wrong provisioning of the
network, move the Device.
Device.
see 10.6.8 Uplink 4. Check the Device
Activity Alarms information.
your support.
005 Node uses
higher data
The Device sends
packets whose
▪ The Device's firmware does 1. Check the Device's firmware
ADR configuration (see your
not support ADR or is
rate than Spreading Factor configured with a fixed Device documentation).
expected is too low (e.g. SF7 Spreading Factor. 2. Check the coverage of the
instead of SF10)
(state-driven)
▪ The Device did not receive Device and move the Device
if necessary.
the LoRaWAN® ADR
command to adjust 3. Check if Alarm 002 -Traffic
Spreading Factor. exceeds the downlink
regulator settings has been
triggered, because it
prevents the Device from
receiving LoRaWAN®
commands.
your support.

ID
006 Node uses
lower data
The Device sends
packets whose
▪ The Device's firmware does 1. Check the Device's firmware
ADR configuration (see your
not support ADR or is
rate than Spreading Factor configured with a fixed Device documentation).
expected is too high (e.g. Spreading Factor. 1. Check the coverage of the
SF10 instead of
(state-driven)
SF8) ▪ The Device did not receive Device and move the Device
if necessary.
the LoRaWAN® ADR
command to adjust 2. Check if Traffic exceeds the
Spreading Factor. downlink regulator settings
▪ The Device is using (alarm 002) has been
triggered, because it
Spreading Factor fallback
procedure (SNR degraded). prevents the Device from
receiving LoRaWAN®
commands.
your support.
007 Join request
replay
A DevNonce
replay has been
▪ The Device is the victim of 1. If the number of the alarm
a join request replay
detected detected in a Join attack. If the Device sent a join
(DevNonce request (Last
replay) occurrence was ▪ The Device sent a join request containing a
DevNonce already used, fix
request containing a
for the given
(event-driven) DevNonce already used. it.
DevNonce)
The Device may be the victim
of a join request replay
attack. Stop the radio and
try to identify the attacker.
your support.
008 Wrong MIC
detected in
A wrong MIC has
been detected in a
a join request adversary
Join request Join request attack. Check the Device's information
(event-driven)
▪ The Device sent a join and behavior, and fix issues.
The Device may be the victim
request containing a wrong
MIC possibly due to wrong of a join request replay
Device provisioning (e.g. attack. Stop the radio and
bad Appkey). try to identify the attacker.
your support.

ID
009 Join request A wrong MIC The Device is the victim of a join 1. If the number of the alarm
replay correlation has request replay attack. occurrences is high, the
detected been detected Device may be the victim of
(wrong MIC between a Join a join request replay attack.
correlation) request and the Stop the radio and try to
following uplink identify the attacker.
(event-driven)
packet (Last
2. If the alarm persists,
occurrence was
contact your support.
for the given
DevNonce)
010 Uplink frame
replay
A wrong FCnt has
been detected in
occurrences is high, the
an uplink packet replay
detected an uplink packet attack. Base Station may be the
(wrong FCnt) (Last occurrence victim of a join request
(event-driven)
was for the given ▪ The Device reset has not
replay attack. Stop the radio
been detected by the
FCnt) and try to identify the
network server.
attacker.
your support.
012 MAC The transmission The Device rejects the MAC 1. Check the behavior of the
command of the given MAC command sent by the network Device and fix it.
transmission command has server.
blocked been blocked
your support.
(transmission after a given
rejected) attempts and
rejected.
(state-driven)
013 MAC
command
The transmission
of the given MAC
▪ The Device did not receive 1. Check if the Device is ON.
the MAC command sent by 2. If the power level of the
transmission command has the network server. Device is low, change the
blocked (no been blocked
reply) after a given ▪ The Device's firmware does battery.
not support the MAC 3. If the Device is not located
number of
(state-driven) command.
attempts because in the coverage area of the
of no reply. LoRaWAN® network, move
the Device.
4. Check the behavior of the
Device and fix it.
your support.

ID
014 Invalid AppEUI An invalid AppEUI The Device has changed too many 1. If a LoRaWAN®1.0 Device,
detected in issue has been times its AppEUI/JoinEUI value check that it supports the
Join request detected in a Join (maximum allowed: 32). counter-based DevNonce
request feature and that the model
(event-driven)
concerning the used to create the Device is
For LoRaWAN® used AppEUI (or correct. If yes, the replay
1.0 OTAA JoinEUI in attack risk will not
devices, only LoRaWAN 1.1). jeopardize the Device
applies if the operation. If not, change the
Device model.
supports
2. If the Device has used more
counter-based
than 32 different AppEUIs,
DevNonce and
fix it.
has been
created using a 3. Check the behavior of the
model Device and fix it.
activating this
behavior.
your support.
Applies to all
LoRaWAN® 1.1
OTAA devices.

ID
015 Join request A DevNonce A DevNonce has been reused with 1. If a LoRaWAN® 1.0 Device,
replay replay attack has the same AppEUI/Join EUI: The check that it supports the
detected been detected in a Device is the victim of a join counter-based DevNonce
(invalid Join request request replay attack. feature and that the model
DevNonce) concerning the used to create the Device is
DevNonce used correct. If yes, the replay
(event-driven)
with the AppEUI attack risk will not
For LoRaWAN® (or JoinEUI in jeopardize the Device
1.0 OTAA LoRaWAN 1.1). operation. If not, change
devices, only the model.
applies if the 2. If the number of the alarm
Device occurrences is high, the
supports Device may be the victim of
counter-based a join request replay attack.
DevNonce and Stop the radio and try to
has been identify the attacker.
created using a
model
your support.
activating this
behavior.
Applies to all
LoRaWAN® 1.1
OTAA devices.
10.6.8 Uplink Activity Alarms

You can define an inactivity alarm per Base Station or per Device and set one or two thresholds
to trigger this alarm. For example, triggering the alarm after two days of inactivity, and
triggering the alarm again after five days of inactivity.
10.6.9 Creating Notifications
If an alarm state having a registered recipient is reached, an email for all Base Stations and
Devices impacted is sent:
▪ Whenever a new alarm is triggered with this alarm state.
▪ Whenever an existing alarm changes to this alarm state.

Note: For an event-driven alarm, no email is sent for any new occurrence if the alarm
state is the same.

▪ Whenever the alarm has been acknowledged and increases to this alarm state.
Note: When an acknowledged alarm increases its alarm state, the acknowledgement
is cancelled by the system.
1. Go to Manage -> Alarms Management.

2. Go to Base Station Alarms Recipients or Devices Alarms Recipients widgets. A screen
looks like this: XXXX base_station_alarms_recipients XXXX
3. Add one or more recipients.
 The recipient(s) will be notified by the alarms.

11 OTHER TASKS AND USER INFORMATION
In the viewing panels of Base Stations, Devices and Applications, you can also perform the
following tasks by clicking the dedicated icon:
▪ Log out.
▪ Add a new network element, a Base Station for instance.
▪ The refresh or reload function behaves differently according to

the network elements used in the platform, that is, Base
Stations, Devices and Applications.
▪ Download charts in PDF, JPEG or PNG format. This functionality

is only valid for Base Stations and Devices.
▪ Export CSV data in Excel format. This functionality only applies
to Applications.
▪ All objects can be viewed on a single page.
▪ Show or hide columns in a table. This saves the selection of the

column in the lists and graphs. This selection is saved in the
Browser’s cache and applies to the same PC and Browser.
▪ This applies to “list of Base Stations” and “list of Devices”, “list
of applications”, as well as list of “Last 10 packets”. A sample
of field is given in the left column of the table besides.
▪ Select an action of your choice for a table entry.
▪ Expand the frame to full screen view.
▪ Select the time window and aggregation step of timeseries

(hourly, daily, last 7 days and last 15 days).
▪ If the message “No data” is displayed in the widget, it can mean

the following:

o There is not enough radio traffic going through the Base
Station to compute the selected time aggregation step.
o There is no Device that is associated with any Application.
o There is no recent communication with the Application.
o The Device was recently added or when high packet loss
conditions occur.
In this case, you need to refresh the icon.
▪ Delete.
▪ Edit.
▪ Confirm changes.
▪ Discard changes.
▪ Display the password when clicked.
▪ Upload a file.
▪ Regenerate.

WHAT’S NEW HISTORY
This section lists changes implemented in the previous versions of this document.

Functionalities
Deactivation of Google ▪ 6.5.10 Modifying the Location of the Base 4.3

Maps widget and Google Station
API key
▪ 8.5.8 Modifying the Location of the Device
IBM Watson IoT Application ▪ 7.3.4 Connecting to a Beta IBM Watson IoT 4.3
TPE On Customer Premise ▪ 7.4 Managing Applications 4.3.1 for OCP
configuration
TPE SaaS configuration ▪ 2 ThingPark Enterprise 5.0 for OCP
applies to On Customer
Premises’ Configuration ▪ 5 Default Dashboard
▪ 6 Activating a Base Station to your IoT

Network
▪ 7 Connecting an Application to your IoT

Network
▪ 8 Activating a Device to your IoT Network
▪ 10 Managing a ThingPark Enterprise

Instance
user-password-policy-
indicator (NFR 999)
▪ 5.3.3 Password Policy
5.0 for OCP
▪ Feature that is specific ▪ 6.4.6.2 Scanning the Radio - removed 5.0 for OCP
to a TPE OCP
configuration ▪ 9.4.5 Using the Spectrum Analysis Tool -
removed
▪ Features that are
related to ThingPark
Enterprise OCP and ▪ 9.4.4 Using the Network Survey Tool -
removed
SaaS configurations
▪ 10.4 Managing Catalogs added
Restructuring content for
optimizing information access
▪ 7.2 Application Parameters 5.0 for OCP
A TPE platform supports
Baidu maps
▪ 4.1.1 Prerequisites 5.1 - 5.1.5
A single TPE OCP platform
supports several ISM bands
▪ 6.3.1 Prerequisites 5.1 - 5.1.5
▪ 6.3.2 Activating A Base Station in 2 Steps

Functionalities
▪ 6.5.2 Main Parameters and Definitions

Related to Base Station management
Device average ESP
▪ 8.5.10 Monitoring Device Uplink ESP 5.1 - 5.1.5
▪ 8.5.11 Viewing Recent Uplink / Downlink
Activity of a Device
▪ 10.5.2 Using the Wireless Logger

Device import
▪ 8.3 Importing Devices in 2 steps 5.1 – 5.1.5
A TPE platform supports RF
Region Catalogs
▪ 10.4.3 Managing RF Region Catalogs 5.1 – 5.1.5
IPsec for Base Station
communication must be
▪ Error! Reference source not found. Error! 5.1 – 5.1.5
Reference source not found.
optional for a TPE OCP
platform
A TPE platform supports TPE
in tablet mode
▪ 5.2 Using the Tablet Version of ThingPark 5.1 – 5.1.5
Enterprise
Amazon AWS Applications
▪ 7.3.2 Connecting to Amazon AWS IoT 5.1 -5.1.5
platform
A TPE platform supports beta
IBM Watson IoT Applications
▪ 7.4.1 Viewing all Applications 5.1 – 5.1.5
Accessing Network Tools ▪ 10.5 Using Network Tools 5.1 – 5.1.5
A TPE OCP platform supports
SNMP Traps in the Platform
▪ 10.6.3 Definitions 5.1 – 5.1.5
Monitoring Framework
A JSON typed Content-Type
for an HTTP Generic
▪ 7.3.1.2 Connecting an HTTPS Application in 5.1 – 5.1.5
2 Steps
application is supported
LRR software upgrade is
supported on a TPE OCP
▪ 6.5.3 Updating the Base Station 5.1 – 5.1.5
Information
platform
A TPE platform supports ▪ 8.2.1 Main Device Parameters 5.1 – 5.1.5
LoRaWAN® 1.1 devices
▪ 8.2.2 Creating a Device in 3 Steps

ABOUT ACTILITY
Actility is an industry leader in LPWAN (Low Power Wide Area) large scale infrastructure with
ThingPark™, the new generation standard-based M2M communication platform. Actility’s
ThingPark Wireless™ network provides long-range coverage for low-power sensors used in
SmartCity, SmartBuilding and SmartFactory Applications. Actility also provides the ThingPark
X which provides big data storage for sensor data and exposes sensor function through an
open API allowing developers to provide vertical Applications on top of rolled out sensors. To
help vendors transform their sensors, Actility provides the ThingPark IoT platform which
include embedded software solutions and cloud solutions to help Devices connect to
innovative Applications. Via the ThingPark Market, an online marketplace engine dedicated to
the IoT sensors, Applications and network solutions, Actility enables the roll-out of new
innovative IoT services for sensor vendors and network solution vendors. Actility is a founding
member of the LoRa Alliance®: the largest, most powerful standards-based effort to enable
the Internet of Things (IoT). Visit www.actility.com.
LoRaWAN®, the LoRa Alliance®, and LoRa Alliance CertifiedCM are trademarks of Semtech
Corporation, used with permission under a sublicense granted to the LoRa Alliance™ and its
members.


TP Enterprise 5.2.2 - Rev2 SAAS User Guide

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

TP Enterprise 5.2.2 - Rev2 SAAS User Guide

Uploaded by

Copyright:

Available Formats

Actility ThingPark Enterprise

© 2019 ACTILITY SA. All rights reserved.

Under Non-Disclosure Agreement

Version Date Author Details

▪ Version of TPE for 4.3 Release

05 2018/01/05 ML Ancelle Version of TPE OCP for 4.3.1 Release

R2 ThingPark Enterprise LRC-AS Tunnel Interface Developer Guide LoRaWAN® S. Dufour

Under Non-Disclosure Agreement

New/Enhanced For More Information, See… Release

▪ LRR Software upgrade ▪ 6.5.6 Base Station Status

▪ The backup and

rollback to the previous

An LRR software upgrade

▪ 6.5.6 Base Station Status

Amazon AWS Applications

Under Non-Disclosure Agreement

Login and Licenses ▪ 4 Logging-in ThingPark Enterprise 5.2.2 SaaS

▪ 10.6.9 Creating Notifications

▪ 6.5.8 Activating Public Key Authentication

Under Non-Disclosure Agreement

Under Non-Disclosure Agreement

Under Non-Disclosure Agreement

WHAT’S NEW ........................................................................................................................ 4

ACRONYMS AND DEFINITIONS ............................................................................................... 6

TABLE OF CONTENTS ............................................................................................................. 8

2 THINGPARK ENTERPRISE ..................................................................................... 15

3 CREATING THE IOT NETWORK ............................................................................. 17

4 LOGGING-IN THINGPARK ENTERPRISE ................................................................. 18

Under Non-Disclosure Agreement

Under Non-Disclosure Agreement

10 MANAGING A THINGPARK ENTERPRISE INSTANCE ............................................. 112

WHAT’S NEW HISTORY ...................................................................................................... 148

ABOUT ACTILITY ................................................................................................................ 150

Under Non-Disclosure Agreement

Under Non-Disclosure Agreement

▪ Add new Devices to the network and manage existing Devices.

The data flow within your IoT network operates as follows:

▪ Devices transmit data to the network Base Stations (uplink frames).

Under Non-Disclosure Agreement

Activating the Base

Activating the Device Connecting the

Under Non-Disclosure Agreement

4.1.2 Required Licenses

License Size Description Number of

▪ ThingPark Essential Support and Maintenance

▪ ThingPark Essential Support and Maintenance

▪ ThingPark Essential Support and Maintenance

▪ ThingPark Essential Support and Maintenance

4.1.3 First time log-in

Under Non-Disclosure Agreement

2. Update your password and user profile to activate your account.

 Your account has been updated.

4. In your Internet browser, type the link to access ThingPark Enterprise:

Under Non-Disclosure Agreement

Under Non-Disclosure Agreement

5.1.1 Top Bar Area

Information menu Description

▪ My profile tells you whether you are logged in to access your

▪ Help information directs you to the user documentation.

▪ Contact your Vendor or your ThingPark Enterprise Channel if

▪ Logs out from the User Interface.

▪ Search category to filter search results.

▪ Search category to filter Devices, Base Stations and