TPE configuration
TPE configuration is accessible from the TPE configuration Cockpit module.
Installation ID
The Installation ID is read-only. It is the identifier of the installation and is hardware-dependent.
If the TPE instance must be reinstalled on new hardware, the license becomes invalid. Additionally, for online installation, the repository (that is used for yum, docker images, catalogs, and Base Station images) also becomes unreachable unless a new license is subscribed.
To change your license subscription or subscribe to a new license, go to the Actility Central portal.
Feature settings
To save server resources and depending on your need, some features may be disabled. This includes:
- DX API: manage your devices and base stations through a simple REST API. This feature is enabled by default.
- ThingPark X IoT Flow: provides a wide range of professionally supported IoT connectors towards the leading IoT platforms (Amazon AWS IoT, Microsoft Azure, IBM Watson, ThingWorx, Yandex, Cumulocity and many others…). ThingPark X IoT Flow also supports generic MQTT and HTTP connections. This feature is enabled by default.
- Node-RED: a browser-based flow editor that is used for building Internet of Things applications. It provides you with code blocks known as nodes, each node describing a task. When linked together, the nodes make up a flow. This feature is disabled by default.
- LoRa Basics™ Station: connect base stations running LoRa Basics™ Station, an implementation of a LoRa® packet forwarder. This feature is disabled by default.
Mail settings
An SMTP server is required to send transactional emails to users for the following events:
- Activation of a user account,
- Password reset,
- Contact-us form,
- Alarm notification.
SMTP configuration is optional starting TPE 6.1. When Outgoing mails is disabled, no email will be sent to the users. As a consequence, the following features will be disabled:
- Self-service password reset (i.e. password lost),
- Contact-us,
- Alarm notification.
When Outgoing mails is enabled, you must set valid entries for the following fields:
- SMTP server: Hostname or IP address of the SMTP server used to send emails (you can optionally set a port number).
- SMTP security: select one of the available options (None, SSL or TLS) depending on the SMTP server you will use.
- SMTP Login and SMTP password.
- SMTP no reply email: email sender "From" of all emails sent by the TPE instance.
- User-initiated action lifespan: Maximum time before an action request - notified to the user by email - expires. This parameter addresses the user's response to an action initiated by the user himself, e.g.: forgotten password. Therefore, this lifespan is recommended to be short because it is expected that the user would quickly react to self-initiated actions. Default value is 15 min.
- Admin-initiated action lifespan: Maximum time before an action request - notified to the user by email - expires. This parameter addresses the user's response to an action initiated by the administrator, e.g.: account creation. Therefore, this lifespan is recommended to be long to allow admins to send emails to users that are currently offline. Default value is 60 min.
You can change these settings from Cockpit at any time.
TLS certificate for HTTP traffic
These parameters (certificate and private key) allow uploading the certificate and key used to secure your HTTP connection to the TPE instance.
The TLS certificate for HTTP traffic is also used to secure the LoRa Basics™ station, flows. See LoRa Basics™ station configuration section for more details.
The default certificate is issued for actility.local
and *.actility.local
.
The certificate is signed by a root that is randomly generated at the
initialization of the instance.
The default certificate should not be kept but replaced by a certificate issued
for the hostname/IP address of your TPE instance. A subjectAltName
with this
hostname/IP address must be configured to be compatible with browsers and
Basics Stations ([alt_names] DNS.1 = yourdomain
or [alt_names] IP.1 = yourIPaddress
if this certificate is generated by OpenSSL, see
sample openssl.cnf.certificate file) and the
certificate signed by a known root certificate. This root certificate should be
deployed on the web browsers of TPE users. The certificate should be issued by a
well-known certificate authority, for example by the corporate PKI.
When the LoRa Basics™ station feature is enabled, this root certificate should
also be provided in the Root certificate field.
Carefully configuring the TLS certificate for HTTP traffic is essential to secure access to the TPE instance. TPE users should not have to bypass the browser security check.
You can change these settings from Cockpit at any time.
IPsec/TLS certificate for base stations traffic
The root certificate and the private key are used to secure your Base Station connections to the TPE instance. The root certificate/key are randomly generated by the system at the initialization of the TPE instance.
It is strongly recommended to keep it. If you need to set your own PKI certificate or key, see IPsec certificate Generation for base stations traffic.
If the certificates/keys are modified after the first boot of the TPE service, all base stations will be temporarily disconnected to retrieve a new certificate.
Network Server hostname(s)
These settings do not apply to LoRa Basics™ station.
- For standalone deployment
- Network server hostname: set the hostname or IPV4 address used by base stations to reach the TPE server.
- For HA deployment
- Primary network server hostname: set the hostname or IPV4 address used by base stations to reach the node 1 of the TPE cluster.
- Secondary network server hostname: set the hostname or IPV4 address used by base stations to reach the node 2 of the TPE cluster.
Changing the Network Server hostname(s) or IPV4 address(es) of your TPE instance has an impact on all the Base Stations configured on the TPE instance. Already connected base stations will continue to use the old configuration until:
- the base station certificate is regenerated to propagate the new hostname(s) or IPV4 address(es) to the base station (certificate regeneration is the only way to push a new configuration to the base station),
- the new hostname(s) or IPV4 address(es) is set in the Suplog menu.
IPsec/TLS for base station to TPE connection
The parameter "IPSec (X.509) for base station to TPE connection" determines the security policy used by Base Stations to connect to the TPEcore network:
- Enforced: All Base Stations must use the IPSec. Only encrypted and authenticated connections are allowed.
- Optional: Base Stations may or may not use IPSec. In such cases, the configuration is done on each Base Station, using Suplog. Both encrypted and unencrypted connections are allowed.
- Disabled: All Base Stations must not use IPSEC. Only unencrypted connections are allowed.
When LoRa Basics™ station feature is enabled, only Enforced and Optional should be used.
- The Base Station's PKI configuration (in BS image or through Suplog configuration menus) must be set in accordance with the security strategy defined in Cockpit and TPE UI.
- Changing the security level to Optional is authorized at any time.
- Changing the security level in any other case might cause existing base stations to stop working
- If the Base Station's default security is switched from Disabled to Enforced, all the existing Base Stations will stop working because the unencrypted access is closed.
- If the Base Station's default security is switched from Optional to Enforced, only existing Base Stations configured to connect without encryption will stop working because the unencrypted access is closed.
- If the Base Station's default security is switched to Disabled,
the PKI (Public Key Infrastructure) service will be terminated.
This action leads to two significant consequences:
- Disruption of encrypted connections: All Base Stations currently configured to operate with encryption will cease to function.
- Loss of certificate management: For the affected Base Stations, it will no longer be possible to revoke existing certificates, nor delete base stations.
AS security level
By default, HTTPs connection from TPE to the applications servers must pass the SSL validation, i.e. the certificate exposed by the application server must be signed by a trusted certificate authority and must match the hostname.
If your application servers are using auto-signed certificates or certificates signed by untrusted certificate authorities, the AS security level should be set to Loose. Note that this setting applies to all application servers. Because Loose is unsecure, it should be used exceptionally.
You can change this configuration parameter at any time.
HTTP hostname or IP address
Sets the hostname/IP address of the TPE instance and defines the URL that is used to access the TPE portal GUI.
- For standalone deployment, set the IP address of the TPE server or a hostname resolved on it.
- For HA deployment, set the floating IP address or the load balancer of the TPE cluster or a hostname resolved on it.
You can change this configuration parameter at any time.
Ensure that the TLS certificate for HTTP traffic is issued for the provided hostname/IP address.
Logo
Allow to change the logo displayed in login page and top menu of TPE portal GUI.
The image should be in PNG format and less than 50 kB. Recommended size is 300 x 100 px.
You can change it at any time.
Virtual IP settings
This configuration, available only in TPE HA deployment, is used to set the Virtual IP address of the TPE instance. It allows supporting cluster node failover mechanisms, particularly for TPE GUI and API access.
This should be disabled when using an external load balancer.
- Virtual IP: set to Enabled if you want to use a floating IP address to support a cluster node failover, particularly for TPE GUI and API access.
- IP address: set the floating IP address (must be different from the one already configured on each node).
- Network interface: set with the name of the network interface where you want to bind the virtual IP (i.e.: bound0, eth2). The interface name must be the one where is configured the IP address of TPE nodes and same interface name must be configured on each TPE node.
You can change the VIP settings at any time.
Maps settings
Defines the Map service used by the TPE instance.
The supported map services are the following:
- Google Maps For Google Maps setting, you need to enter your API key.
- Baidu Maps For Baidu Map configuration, you need to enter your API key.
- OpenStreetMap For OpenStreetMap configuration, you need to provide the URLs of your Tiles server and Nominatim server.
- No Map: Service deactivated.
If "No Map" is selected, all map widgets in the TPE portal GUI are deactivated and the application Network Survey is unusable.
You can change this configuration parameter at any time.
Device and base station alarm notification
This configuration is used to set the SNMP server receiver of alarms as SNMP traps. An SNMP server accepting trap is required to use this feature.
You can set:
- SNMP trap destination server: Hostname or IPV4 address of the SNMP trap destination server.
- SNMP trap community: set it to public by default.
You can change the device and base station alarm notification configuration at any time.
Services monitoring
Source addresses allowed to access the services monitoring SNMP: list of network addresses (IP address/Mask, comma-separated values) that are allowed to connect. See SNMP monitoring for more information.
Example: 10.100.30.0/23,192.168.1.0/23
You can change the services monitoring configuration at any time.
Advanced settings
Maximum IoT flow connections
Allow to configure the maximum number of IoT flow connections allowed simultaneously. As each connection consumes hardware resources (CPU, RAM), this value should be set carefully.
The minimum value is 1, and the maximum value is 30.
This parameter is displayed only when the IoT Flow feature is enabled.
Following the hardware sizing profile, you cannot exceed the following limits:
- segment S: 5
- segment L and M: 10
- segment XL or upper: 20
Can be changed at any time.
Traffic history retention period
Allow to configure the lifespan of LoRaWAN™ uplink and downlink frames. The default value of 15 days is enough for a normal usage of ThingPark Enterprise. Extending the default value consumes hardware resources (RAM, Disk space), please contact your support before any change.
Possible value: 15 to 90 days (15 days by default).
This parameter can be changed at any time.
Extra hosts
Allow to configure extra hostname mappings, to be used in connections configuration.
Additional hosts must be set as HOSTNAME:IP. One value per line.
This parameter can be changed at any time
Subnets configuration
The TPE internal subnet can be changed after installation. It is an advanced maintenance task described here. The current TPE internal subnet configuration is available on the TPE Services Cockpit module (TPE Cluster operations -> Show infra configuration). This subnet does not include the IPsec subnets.
When you change the IPsec subnets, make sure it does not overlap with the subnets used by the private network base stations are deployed in and with the TPE internal subnet configured on cluster creation.
-
Primary IPsec subnet:
IPV4 subnet used by base stations using IPsec security. The subnet should contain one address for each base station. If IPsec is not used, this configuration can be ignored. This parameter can be changed at any time. Note that base stations using IPsec will be disconnected during the IPsec services restart. -
Secondary IPsec subnet:
IPV4 subnet used by base stations using IPsec security. The subnet should contain one address for each base station. If IPsec is not used or the TPE is deployed in standalone mode, this configuration can be ignored.
This parameter can be changed at any time. Note that base stations using IPsec will be disconnected during the IPsec services restart.
Corporate or private Certificate Authority (CA)
Certificate Authority (CA) certificate that signs the TLS Certificate for SMTP or an external IDP in Base64 ASCII encoded PEM format when a corporate or private Certificate Authority (CA) is used. Can be changed anytime.
Authentication federation
This configuration is used to activate the user's authentication delegation to an external identity provider.
To enable authentication federation, the parameters below must be set properly:
- Client ID: Client ID used to authenticate the users on the federated IDP
- Client Secret: Client Secret used to authenticate the users on the federated IDP
- OpenID Connect Issuer: URL of the OpenID Connect IDP
The Button Check Issuer can be used to validate the OpenID Connect Issuer.
See Authentication federation for more details.
LoRa configuration
ISM Bands
Choose the desired ISM Bands (also known as Regional RF profile) for your deployment. The Base Station and Device Catalogs will be automatically filtered on the TPE Portal GUI according to this setting. On the TPE Portal GUI, it will be possible to create Base Stations and Devices that match the ISM Bands set on Cockpit.
This configuration should be done during the TPE instance initialization only. Anyway, it can be updated afterwards, but you must keep consistency with the deployments of your Base Stations and Devices.
Roaming / Activation
Allow to configure the LoRaWAN™ Activation and passive roaming. The possible values are:
- None: default value.
- Activation: allows the activation of devices pre-commissioned on agreed external join servers.
- Roaming in: allows devices from agreed foreign networks to use local base stations for uplink and downlink communications (in addition to LoRaWAN™ Activation).
- Roaming out: allows local devices to use base stations from agreed foreign networks for uplink and downlink communications (in addition to LoRaWAN™ Activation).
This parameter must not be changed once base stations and devices are deployed.
When Roaming and/or Activation is enabled, the TEX configuration must be defined through the following parameters:
- NSID: LoRaWAN™ 64 bits network server identifier. This information is part of the ThingPark Exchange (TEX) subscription. Can be changed anytime.
- TEX URL: URL of ThingPark Exchange (TEX). Can be changed anytime.
- TEX HubID: HubID of ThingPark Exchange (TEX). Can be changed anytime.
- Username for TEX authentication: Username of the ThingPark Exchange (TEX) account. Can be changed anytime.
- Password for TEX authentication: Password of the ThingPark Exchange (TEX) account. Can be changed anytime.
TEX synchronization status with LRC can be monitored in "TPE Services" under the menu "TEX operations -> TEX synchronization" (see ThingPark Enterprise Administration and Troubleshooting Guide for more details).
NetID
This parameter allows to configure the LoRaWAN™ 24 bits network identifier. A dedicated NetID assigned by the LoRa Alliance® is required when roam out is enabled. Possible values are 6 hexadecimal digits (case insensitive) restricted to the following list:
- Default value: 000001
- 000000 (shared NetID 0) – forbidden if roam out is enabled
- 000001 (shared NetID 1) – forbidden if roam out is enabled
- 000002-00003F (dedicated NetID type 0) - Assigned to Sponsor members
- 600000-7FFFFF (dedicated NetID type 3) - Assigned to Contributor members
- C00000-DFFFFF (dedicated NetID type 6) - Assigned to Adopter and Institutional members
- E00000-FFFFFF (dedicated NetID type 7) - May be assigned without being a LoRa-Alliance member
For type 7 NetIDs, the first NetID of the block must be configured.
NetIDs block size
This parameter is displayed only when NetID type 7 is configured and allows to configure the number of contiguous assigned type 7 NetIDs.
Can be changed at any time.
DevAddr subnet
This parameter allows to display/configure the DevAddr subnet (and so the DevAddr range) to be used for OTAA devices. The DevAddr subnet is expressed as a DevAddr hexadecimal prefix followed by a slash (/) and the size of the bitmask:
- When NetID type 7 is configured: this parameter displays the value of DevAddr subnet based on NetIDs block size configuration.
- When NetID type 0, 3 or 6 is configured: this parameter allows to configure the DevAddr subnet. This subnet must match the configured NetID. Can be changed at any time.
This parameter is optional and can be configured if you want to do roaming between TPE instances sharing the same NetID. In such case, you can define a dedicated DevAddr subnet to each TPE instance.
DevAddr subnet validation is done as follows:
- The binary NetID DevAddr prefix is computed based on the configured NetID:
- NetID DevAddr prefix is Type | NwkID
- If NetID is type 0 (3 MSB are
0b000
):- Type is
0b0
- NwkID is the 6 LSB of NetID
- Type is
- Else if NetID is type 3 (3 MSB are
0b011
):- Type is
0b1110
- NwkID is the 11 LSB of NetID
- Type is
- Else if NetID is type 6 (3 MSB are
0b110
):- Type is
0b1111110
- NwkID is the 15 LSB of NetID
- Type is
- Else If NetID is type 7 (3 MSB are
0b111
):- Type is
0b11111110
- NwkID is the 17 LSB of NetID
- Type is
- The binary SubNetID DevAddr prefix is computed based on the configured
DevAddr subnet:
- Left part is translated from hexadecimal to binary.
- Only the number of MSB specified in the right part are kept. For NetID type 7, the right part must be ≥ 20.
- DevAddr subnet is valid if SubNetID DevAddr prefix binary string starts with NetID DevAddr prefix binary string.
Below are some valid and invalid DevAddr subnet configurations based on configured NetID:
-
Example #1 - Type 0: NetID
000002
/ DevAddr subnet040/12
- NetID DevAddr prefix:
0b0000010
- Type is
0b0
- NwkID is
0b000010
- Type is
- SubNetID DevAddr prefix:
0b000001000000
- DevAddr subnet is valid (
0b000001000000
is the prefix of0b0000010
)
- NetID DevAddr prefix:
-
Example #2 - Type 3: NetID
60000F
/ DevAddr subnetE01E0/20
- NetID DevAddr prefix:
0b111000000001111
- Type is
0b1110
- NwkID is
0b00000001111
- Type is
- SubNetID DevAddr prefix:
0b11100000000111100000
- DevAddr subnet is valid (
0b11100000000111100000
is the prefix of0b111000000001111
)
- NetID DevAddr prefix:
-
Example #3 - Type 6: NetID
C0000F
/ DevAddr subnetFC0038/24
- NetID DevAddr prefix:
0b1111110000000000001111
- Type is
0b1111110
- NwkID is
0b000000000001111
- Type is
- SubNetID DevAddr prefix:
0b111111000000000000111000
- DevAddr subnet is invalid (
0b111111000000000000111000
is NOT the prefix of0b1111110000000000001111
)
- NetID DevAddr prefix:
-
Example #4 - Type 7: NetID
E00020
(first of 16 NetIDs rangeE00020-E0002F
) / DevAddr subnetFE001000/21
- NetID DevAddr prefix:
0b1111111000000000000100000
- Type is
0b11111110
- NwkID is
0b00000000000100000
- Type is
- SubNetID DevAddr prefix:
0b111111100000000000010
- DevAddr subnet is valid (
0b111111100000000000010
is the prefix of0b1111111000000000000100000
)
- NetID DevAddr prefix:
-
Example #5 - Type 7: NetID
E00020
(first of 32 NetIDs rangeE00020-E0003F
) / DevAddr subnetFE001000/20
- NetID DevAddr prefix:
0b1111111000000000000100000
- Type is
0b11111110
- NwkID is
0b00000000000100000
- Type is
- SubNetID DevAddr prefix:
0b11111110000000000001
- DevAddr subnet is valid (
0b11111110000000000001
is the prefix of0b1111111000000000000100000
)
- NetID DevAddr prefix:
-
Example #6 - Type 7: NetID
E00020
(first of 16 NetIDs rangeE00020-E0002F
) / DevAddr subnetFE000000/21
- NetID DevAddr prefix:
0b1111111000000000000100000
- Type is
0b11111110
- NwkID is
0b00000000000100000
- Type is
- SubNetID DevAddr prefix:
0b111111100000000000000
- DevAddr subnet is invalid (
0b111111100000000000000
is NOT the prefix of0b1111111000000000000100000
)
- NetID DevAddr prefix:
-
Example #7 - Type 7: NetID
E00020
(first of 32 NetIDs rangeE00020-E0003F
) / DevAddr subnetFE001000/7
- NetID DevAddr prefix:
0b1111111000000000000100000
- Type is
0b11111110
- NwkID is
0b00000000000100000
- Type is
- SubNetID DevAddr prefix:
0b1111111
- DevAddr subnet is invalid (right part of DevAddr subnet is > 20)
- NetID DevAddr prefix:
NetID Type
Display the NetID type (0, 3, 6 or 7) based on configured NetID.
DevAddr range
Display the DevAddr range for OTAA devices based on configured DevAddr subnet.
Catalogs update mode
When set to Repository
, catalogs are served by the repository configured
below. When set to Manual upload
, catalogs are manually uploaded in the
ThingPark Enterprise user interface. Can be changed anytime.
Catalogs and LRR software repository
URL of the repository serving catalogs and LRR software. This URL must be reachable
from the ThingPark Enterprise servers.
The URL may point out the local repository. Can be changed anytime.
Proxy settings
Starting from ThingPark Enterprise 6.0, there are two different proxy settings:
-
The proxy settings under TPE Configuration are used for the access of ThingPark Enterprise resources repository (see Catalogs and LRR software repository and Base station images repository for more details):
- URL of the proxy server, only HTTP is supported.
- Username of the proxy account
- Password of the proxy account
- Enable proxy for LRC uplinks: tick the checkbox if you want to use the proxy for LRC uplinks on the tunneling interface.
-
The proxy URL under TPE Services is used for the access of ThingPark Enterprise installation repository, only HTTP is supported.
You can change the proxy configuration at any time.
Marketplace URL
URL of Marketplace available in TPE portal GUI. You can change it at any time.
Support contact email
This parameter is used to change the destination of the emails sent on the "Contact us" screen on the TPE portal.
You can change the support contact email address from Cockpit at any time.
Base station images repository
URL of the repository serving base station images. This URL must be reachable
from web browsers.
The URL cannot point out the local repository. Can be changed anytime.