Skip to main content

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.

WARNING

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)​

tip

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.
WARNING

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.
WARNING

When LoRa Basics™ station feature is enabled, only Enforced and Optional should be used.

WARNING
  • 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.

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.

WARNING

Ensure that the TLS certificate for HTTP traffic is issued for the provided hostname/IP address.

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.
WARNING

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.

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:

  1. 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
    • Else if NetID is type 3 (3 MSB are 0b011):
      • Type is 0b1110
      • NwkID is the 11 LSB of NetID
    • Else if NetID is type 6 (3 MSB are 0b110):
      • Type is 0b1111110
      • NwkID is the 15 LSB of NetID
    • Else If NetID is type 7 (3 MSB are 0b111):
      • Type is 0b11111110
      • NwkID is the 17 LSB of NetID
  2. 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.
  3. 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 subnet 040/12

    1. NetID DevAddr prefix: 0b0000010
      • Type is 0b0
      • NwkID is 0b000010
    2. SubNetID DevAddr prefix: 0b000001000000
    3. DevAddr subnet is valid (0b000001000000 is the prefix of 0b0000010)

  • Example #2 - Type 3: NetID 60000F / DevAddr subnet E01E0/20

    1. NetID DevAddr prefix: 0b111000000001111
      • Type is 0b1110
      • NwkID is 0b00000001111
    2. SubNetID DevAddr prefix: 0b11100000000111100000
    3. DevAddr subnet is valid (0b11100000000111100000 is the prefix of 0b111000000001111)

  • Example #3 - Type 6: NetID C0000F / DevAddr subnet FC0038/24

    1. NetID DevAddr prefix: 0b1111110000000000001111
      • Type is 0b1111110
      • NwkID is 0b000000000001111
    2. SubNetID DevAddr prefix: 0b111111000000000000111000
    3. DevAddr subnet is invalid (0b111111000000000000111000 is NOT the prefix of 0b1111110000000000001111)

  • Example #4 - Type 7: NetID E00020 (first of 16 NetIDs range E00020-E0002F) / DevAddr subnet FE001000/21

    1. NetID DevAddr prefix: 0b1111111000000000000100000
      • Type is 0b11111110
      • NwkID is 0b00000000000100000
    2. SubNetID DevAddr prefix: 0b111111100000000000010
    3. DevAddr subnet is valid (0b111111100000000000010 is the prefix of 0b1111111000000000000100000)

  • Example #5 - Type 7: NetID E00020 (first of 32 NetIDs range E00020-E0003F) / DevAddr subnet FE001000/20

    1. NetID DevAddr prefix: 0b1111111000000000000100000
      • Type is 0b11111110
      • NwkID is 0b00000000000100000
    2. SubNetID DevAddr prefix: 0b11111110000000000001
    3. DevAddr subnet is valid (0b11111110000000000001 is the prefix of 0b1111111000000000000100000)

  • Example #6 - Type 7: NetID E00020 (first of 16 NetIDs range E00020-E0002F) / DevAddr subnet FE000000/21

    1. NetID DevAddr prefix: 0b1111111000000000000100000
      • Type is 0b11111110
      • NwkID is 0b00000000000100000
    2. SubNetID DevAddr prefix: 0b111111100000000000000
    3. DevAddr subnet is invalid (0b111111100000000000000 is NOT the prefix of 0b1111111000000000000100000)

  • Example #7 - Type 7: NetID E00020 (first of 32 NetIDs range E00020-E0003F) / DevAddr subnet FE001000/7

    1. NetID DevAddr prefix: 0b1111111000000000000100000
      • Type is 0b11111110
      • NwkID is 0b00000000000100000
    2. SubNetID DevAddr prefix: 0b1111111
    3. DevAddr subnet is invalid (right part of DevAddr subnet is > 20)

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 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.

Last updated on
Copyright © 2024 Actility
On this page