IRIS Edge Gateway Management

Gateway Stopped Java edge runtime

Local cluster - -

Visible nodes - Coordinator: -

RELAY3 Disabled Site: -

External API Disabled -

Quick actions

Operational controls only.

Save writes your staged configuration to disk only. Apply & Restart validates it, saves it, and restarts the tactical runtime.

Use Guided Profile if you want a more user-friendly way to set transport, discovery and multi-site behaviour without hand-editing the JGroups JSON.

Current site state

Gateway: Stopped
Coordinator: -
Local view: -
RELAY site: -
State file: -
SITE-SYNC: Unknown

Operator summary

Plain-language interpretation of the current settings.

Recent events

Visual multi-site topology

Shows the local site, visible local nodes, the elected Site Master, remote sites, RELAY route health and the current SITE-SYNC state.

Local node Elected Site Master Remote site Route usable Route degraded / pending Route unavailable Live rate = measured JGroups bridge traffic, not radio bearer capacity

SITE-SYNC state

Waiting for runtime information.

RELAY route health

Visible site summary

Data rate

Measured JGroups transport traffic for the local cluster and RELAY3 bridges, sampled independently from route-health checks (2 s default). Reconnect samples establish a fresh baseline and are not counted as traffic. Current, peak and time-weighted average are over the selected window. Not radio bearer capacity.

RELAY3 bridge counters

Cumulative JGroups transport counters per configured bridge since the runtime started.

Node identity

These values identify this Edge Gateway to other IRIS nodes.

Node name / Callsign Use a unique, recognisable name such as EDGE-HQ or COY-A-EDGE. Local IRIS cluster Nodes on the same local IRIS site normally use the same cluster. SITE-SYNC state file Stores durable symbol and sketch state so the gateway can recover correctly after restart.

WAN echelon

Host the echelon that remote IRIS devices join over the internet: this gateway runs the GossipRouter, coordinates the cluster and issues every device its credential.

Host the WAN echelon

On: this node's local network becomes a TUNNEL cluster through an embedded GossipRouter with TLS, device-certificate authentication and ASYM_ENCRYPT, coordinated by this gateway. Every certificate is generated at start. Off: the local network returns to UDP and the router is disabled; nothing else changes.

Public address(es) Comma-separated host[port] a device reaches this gateway by from outside (DDNS name or public IP). Forward TCP 12001 on your internet router to this host. Written into every enrolment bundle; this gateway's own local address is appended automatically.

Derived from the router port and bind address, this node's bind address and its callsign. Open Advanced only to override a value; an override is kept until one of those changes.

Enrolment needs the router running: apply first, then add devices. Same action as the page-level button.

Devices

Each device gets its own certificate, admitted in the truststore under its callsign. Add one, send the operator the .iriswan file by whatever channel you trust and read them the passphrase; it is shown once and not stored. Remove revokes: the device's connections are closed and its certificate stops being accepted immediately.

Add device by callsignLetters, digits, ., -, _. Must match the callsign the device will use.

Advanced: router bind, timeouts, this gateway's own link and bring-your-own certificates

Pre-filled by the switch. A server keystore or device truststore that does not exist is generated when the gateway starts (self-signed EC P-256 server certificate, CN = this gateway's callsign, SAN = the public addresses and this gateway's local address; an empty truststore) and an existing file is never touched, so point these at your own PKCS12 files to bring your own certificates. This gateway's own tunnel credential (the transport TLS stores under "This gateway's link" below) is generated the same way. With client authentication NEED, a device whose certificate is not in the truststore fails the handshake and never registers; the device sees no error, it just keeps reconnecting. The router starts before this node joins and stops with the gateway; a start failure stops the gateway.

Router

Router bind address Router portThe one TCP port to forward. Client authentication NEED refuses devices without a trusted certificate; enrolment needs NEED. Connection expiry (ms)0 = never reap idle connections. Reaper interval (ms)Set together with expiry, or both 0. Router TLSOff is a plain router: no device authentication and no enrolment. Server keystore path (.p12) Server keystore password Server keystore alias Device truststore path (.p12) Device truststore password

This gateway's link

How this gateway itself joins the echelon as a TUNNEL member of its own router. Filled by the switch and re-derived on every change of the router port, a bind address or the callsign; an edit here stands until then. The fields below are the local stack's and return to the local network card when the switch is off.

Multi-site RELAY3 / SITE-SYNC

Create one or more independent relay bridges. Each bridge can use a different local network interface and bridge network.

Enable Gateways on this node

Matches the current IRIS application baseline. Normal nodes can participate in RELAY3 while Site Master eligibility remains separately controlled.

RELAY3 site: IRIS

Derived automatically from the Local IRIS cluster name so local cluster and RELAY3 site identity cannot diverge.

Can become Site Master Enable only on a gateway that owns at least one enabled bridge. IRIS permits one elected Site Master per site.

Loading relay configuration...

Site-Master bridges

Each bridge owns an independent JGroups bridge stack. New bridges start with the same default values used by the IRIS application.

Bridge interface selection: choose an IPv4 interface from the dropdown. The gateway saves it using the same IRIS matcher form, for example match-address:10.10.20.*,site_local,loopback, so the bridge stays associated with that subnet when the host address changes.

RELAY3 forwarding rules

Define hierarchical/asymmetric routes for destination sites that are not local and not directly connected. Each enabled rule maps a destination-site expression to a directly reachable gateway site.

Forwarding rule syntax: to is a Java regular expression matched against the destination site name and gateway is the directly connected remote site that should receive the message next. Example: to=NET3, gateway=NET2. A catch-all route can use to=.*.

Forwarding rules are only used for destinations that are neither local nor directly connected. The gateway site must be a remote site reachable through the configured RELAY3 bridge topology. Avoid routing a rule back to the local site.

A bridge can exist while disabled. A node is only Site-Master eligible when Gateways are enabled, Can become Site Master is selected, and at least one bridge is enabled. maxSiteMasters remains fixed at 1.

Guided JGroups profile

Select a deployment style for a more user-friendly way to configure the underlying JGroups profile.

Approved profile file

Profile file Available profiles

Plain-language profile summary

Engineering view: raw profile JSON

AI / External Tactical API

This is the controlled interface for an AI adapter or other external edge workload.

Enable External Tactical API

Allows one authorised adapter to subscribe to IRIS operational data and publish approved results.

Listen address Use 127.0.0.1 when the AI adapter runs on the same computer. Port Token file A token is mandatory if the API is exposed beyond localhost. The secret itself is not stored in the gateway JSON.

Recommended pattern: keep the AI platform out of the tactical routing path. The AI adapter subscribes to selected operational data and publishes results back to IRIS; JGroups, RELAY3 and SITE-SYNC continue independently.

AI Provider Adapter

Expose AI to the IRIS network without placing the model in the JGroups, RELAY3 or SITE-SYNC routing path.

Disabled

Enable IRIS AI Provider Adapter

The deployed IRIS ai.request/ai.response contract stays the same regardless of the selected AI environment.

AI environment Maximum output tokens Context events retained Only the conservative operational event allow-list is retained for AI context. Maximum context characters Request timeout (seconds) Additional deployment instructions

Model Reasoning effort Allow OpenAI response storage. Leave off for the normal IRIS edge configuration.

OpenAI endpoint and credential settings

Responses API URL API key environment variableEach organisation supplies its own project/service credential. API key secret file (optional)

AI deployment environments

Cloud AIIRIS Edge Gateway → controlled HTTPS → OpenAI. Loss of Internet affects AI only; IRIS networking continues.

Air-gapped AIIRIS Edge Gateway → authorised internal GDC network → Vertex AI/model endpoint. Public Internet is not required for the AI path.

Deployed IRIS usersDesktop/Android users continue to send the same direct ai.request; the gateway hides provider-specific authentication and returns ai.response.

Deployed IRIS AI Service

Allow authorised IRIS Desktop or Android clients to ask this gateway AI through the normal PluginEnvelope path.

Disabled

Accept direct ai.request messages

Responses are returned directly to the actual requesting IRIS user as ai.response; provider credentials never leave the gateway.

AI NETWORK SERVICE NOT ACTIVE. Enable both the External Tactical API and the AI Provider Adapter before accepting direct ai.request messages.

Maximum request characters Maximum concurrent requests Maximum requests per minute Allowed IRIS requesters (optional)Comma-separated callsigns/site-qualified identities. Leave empty to allow any node that can directly address this gateway. Also accept broadcast AI requests. Leave off unless the architecture deliberately has one responding AI gateway. Enable AI Tool Calling v1. Allows the AI to request bounded, read-only IRIS data from the originating client during an active request. Maximum tool calls / request Tool response timeout (seconds) Maximum tool-result characters

pluginId: com.neoplexus.iris.ai
request: ai.request / com.neoplexus.iris.ai.request.v1
tool: ai.tool_request ↔ ai.tool_response / v1
response: ai.response / com.neoplexus.iris.ai.response.v1

Service stateUnknown

Reason-

Network AI requestsUnknown

AI Tool CallingUnknown

Tool calls requested / completed / failed0 / 0 / 0

Last tool-

Accepted / completed0 / 0

Failed / rejected0 / 0

Last requester-

AI credentialUnknown

Credential source-

IRIS Tactical APINot connected

AI providerNot tested

Model-

Ask IRIS AI Assistant

No AI request has been sent.

For cloud AI, do not send classified, controlled or otherwise restricted operational information unless the deployment has the required approval and data-handling controls. GDC air-gapped mode still requires the customer's own accreditation, network policy, identity and data-governance controls.

Gateway plugins

Add headless capability at this edge node without changing the IRIS Desktop or core Gateway. Plugins can ingest external feeds and publish authorised information into the IRIS network.

Entity publish throttle (seconds per track) Minimum interval between publishes of the same entity UID by one plugin. Extra reports inside the interval are dropped and counted as throttled; the next report after it carries the current position. 0 disables throttling. Applies on Apply & Restart.

Install .irisg package The package contains a manifest plus a Java plugin JAR. Installed plugins are disabled by default.

Trusted code boundary. Gateway plugins execute inside the Gateway JVM. Install only trusted packages. The manifest permission list controls host services such as publishing IRIS entities, but it is not a Java sandbox.

Headless by design. A feed plugin does not need to render anything locally. For example, an ADS-B plugin can poll or receive aircraft observations and publish them into the IRIS network for Desktop/Android nodes to consume and correlate.

Loading installed Gateway plugins…

Web management

Controls how this browser interface is exposed. Changes take effect after restarting the Java application itself.

Enable browser management

Listen address Default 127.0.0.1 is safest. Port Auto-start gateway when web management starts Web-management token file Required for any non-loopback bind. Enable HTTPS Keystore type Keystore file Keystore password file The password can alternatively come from IRIS_EDGE_WEB_KEYSTORE_PASSWORD. Log directory Read by the Logs tab. Leave blank for the Windows service layout; a relative path resolves against the configuration file's directory. Takes effect on Save.

Remote web administration requires HTTPS and authentication. The server deliberately refuses a non-loopback management bind without both.

Gateway log files

The process log the service captures: JGroups (TUNNEL, GossipRouter, TLS handshakes), the embedded router and enrolment, and the gateway's own output. Tails the file from the end; the filter is a case-insensitive regular expression applied per line.

Auto-refresh (5 s)

Loading log files…

Live events

Gateway, JGroups, RELAY3, SITE-SYNC and management events.

Overview

Quick actions

Current site state

Operator summary

Recent events

Visual multi-site topology

SITE-SYNC state

RELAY route health

Visible site summary

Data rate

RELAY3 bridge counters

Node identity

WAN echelon

Devices

Router

This gateway's link

Local tactical network (LAN)

Multi-site RELAY3 / SITE-SYNC

Site-Master bridges

RELAY3 forwarding rules

Guided JGroups profile

Approved profile file

Plain-language profile summary

AI / External Tactical API

AI Provider Adapter

AI deployment environments

Deployed IRIS AI Service

Gateway plugins

Web management

Gateway log files

Live events