Transport mechanism in DeviceLink

This is the address of the MQTT broker that manages the MQTT communication. Devices will use this address to establish a connection.

The MQTT broker listens on a specific port for incoming connections. Standard MQTT uses port 1883, and MQTT over TLS uses port 8883.

Each MQTT client (device) needs a unique identifier to connect to the broker. The unique identifier (Client ID) is included in the CONNECT packet when the device first attempts to establish a connection with the broker.

Example:

{
  "packetType": "CONNECT",
  "protocolName": "MQTT",
  "protocolLevel": 4,
  "clean": true,
  "keepAlive": 60,
  "clientId": "GPS_Tracker_001"
}

Upon receiving a CONNECT packet, the Navixy IoT Gateway will validate and register the client based on this Client ID. If the ID is unique and passes the validation checks, the gateway establishes a session for that client and maintains it for the duration of the connection.

If the MQTT broker is set up to require authentication, these parameters are used by the device to provide a username and password. On the device side, the authentication parameters (username and password) are included in the CONNECT packet alongside the Client ID.

Example:

{
  "packetType": "CONNECT",
  "protocolName": "MQTT",
  "protocolLevel": 4,
  "clean": true,
  "keepAlive": 60,
  "clientId": "GPS_Tracker_001",
  "username": "DeviceUsername",
  "password": "DevicePassword"
}

In this example, "DeviceUsername" and "DevicePassword" are the authentication credentials of the device. When the Navixy IoT Gateway receives this CONNECT packet, it will validate the credentials. If the username and password match a valid user in the system, the gateway allows the connection; otherwise, it rejects the connection.

MQTT is based on a publish/subscribe model, and topics are the "channels" that devices publish to or subscribe from. The gateway should provide a way for devices to specify the topic(s) they will publish their data to.

MQTT supports three levels of QoS: 0 (at most once), 1 (at least once), and 2 (exactly once). The Navixy IoT gateway allows the device to specify the QoS level for their messages.

This is the maximum time interval that is permitted to elapse between the point at which a Client finishes transmitting one Control Packet and the point it starts sending the next.

This parameter specifies whether the broker should remember the client's subscriptions and undelivered messages when it disconnects.

This is a message that the broker will publish on behalf of the client if it unexpectedly disconnects.

This feature is particularly useful for monitoring the connection status of clients, as other clients can subscribe to the will message's topic to be notified when a device goes offline.

When the client first establishes the connection with the broker, it includes the Will message in the CONNECT packet. This message includes the topic, the payload, and other properties of the Will message such as QoS (Quality of Service) level and the retain flag.

The IP address where the Navixy IoT Gateway is running. Devices will use this address to send UDP packets.

The port that the Navixy IoT Gateway is listening to for incoming UDP packets.

Though UDP is connectionless, a timeout may still be useful to know how long to wait for a response in a request-response model.

Currently, this feature is under consideration and is not yet supported by the Navixy IoT Gateway.

The method used to encode the data as it is sent over the network.

Currently, the data is expected as a UTF-8 encoded string only.

The IP address where the Navixy IoT Gateway is running. The devices will use this address to establish a TCP connection.

The port that the Navixy IoT Gateway is listening to for incoming TCP connections.

The maximum amount of time the server should wait for a response from a device before closing the connection. This could be set to a default value but could also be adjustable depending on the needs of the application.

A setting to periodically send a message to the device to check if the connection is still active. This can help to detect when a device has disconnected unexpectedly.

The method used to encode the data as it is sent over the network. Currently, the data is expected as a UTF-8 encoded string.

If the data being transmitted is sensitive, you might want to encrypt the TCP connection using SSL or TLS. This requires additional parameters like a certificate and private key.

The HTTP(S) URL that the IoT devices or IoT proxy servers will send their data to. This includes the server address (IP or domain name) and the specific path on the server that will handle the incoming data.

This could be POST, PUT depending on how the devices will be sending data.

• POST: This method is used to send data to the server to create a new resource. The data sent to the server with a POST request is stored in the request body. For example, a GPS tracker might use a POST request to send a new GPS location.

• PUT: This method is similar to POST, but it is used to update an existing resource. The data sent to the server with a PUT request is also stored in the request body. For instance, if your IoT device is updating its status, it might use a PUT request.

Here are simple examples of what a POST and PUT request might look like:

POST request:

POST /gps_location HTTP/1.1
Host: navixy-gateway.com
Content-Type: application/json
Content-Length: 81

{
  "device_id": "GPS_Tracker_001",
  "latitude": 40.712776,
  "longitude": -74.005974
}

POST request:

PUT /device_status HTTP/1.1
Host: navixy-gateway.com
Content-Type: application/json
Content-Length: 55

{
  "device_id": "GPS_Tracker_001",
  "status": "battery_low"
}

In these examples, the IoT device sends a JSON payload to the Navixy IoT Gateway with either a new GPS location (using POST) or an updated device status (using PUT).

These headers tell the server (in this case, the Navixy IoT Gateway) how to process the request.

In current version of the implementation Navixy IoT Gateway exclusively expects JSON data, this parameter is optional, but recommended for the future compatibility. Then all HTTP requests from IoT devices should include the header "Content-Type: application/json".

Here is an example of what an HTTP POST request might look like from an IoT device to the Navixy gateway:

POST /device_data HTTP/1.1
Host: gateway.navixy.com
Content-Type: application/json
Content-Length: 81

{
  "device_id": "Device_001",
  "temperature": 22.5,
  "humidity": 45.3
}

In this example, the Content-Type: application/json header instructs the Navixy gateway to interpret the enclosed data (device_id, temperature, humidity) as a JSON object.

Other headers like Content-Length, which indicates the size of the payload, and Authorization, used for authenticating the device, might also be required depending on the specifics of your implementation.

If the data being transmitted is sensitive, you might want to use HTTPS (HTTP Secure) which uses SSL/TLS to encrypt the HTTP connection.

To ensure the data is coming from an authenticated device, some form of authentication may be required. This could be Basic Authentication (username and password), Bearer Token, or API key.

You need to specify the structure and format of the payload that devices are expected to send. This could be a JSON object, XML, or another format, depending on the needs of the application.

It the current version of implementation, Navixy IoT Gateway exclusively expects JSON data.

The maximum amount of time the server should wait for a response from a device before closing the connection.