Setting antenna gain doesnt take immediate affect

[virtualguy]

Summary

When changing the antenna gain on a gateway it has no affect until a gateway disconnects. It takes a full disconnection timeout until messages start being scheduled with the new TX power

Steps to Reproduce

1. Gateway connected with antenna.gain set to 0
2. Using ttn-lw-cli set antenna gain to 10
3. Observe downlinks still being scheduled at the same tx power (i.e. 30dBm for AU915)

Current Result

Transmit power doesnt change until gateway disconnects

Expected Result

Gain takes affect immediately and transmit power changes

Relevant Logs

No response

URL

No response

Deployment

The Things Stack Open Source (self-hosted)

The Things Stack Version

3.28.0

Client Name and Version

No response

Other Information

No response

Proposed Fix

Compare changes to the antenna properties and require a gateway disconnect here

Contributing

• I can help by doing more research.
• I can help by implementing a fix after the proposal above is approved.
• I can help by testing the fix before it's released.

Code of Conduct

• I agree to follow TTN's Community Code of Conduct.

[KrishnaIyer]

This is actually by design. Gateway settings are stored in the Identity Server and gateways connect to the Gateway Server. These may be in different clusters and we use the gateway reconnection to sync settings.

If you are using LBS, we need to report the antenna gain to the gateway during the connection. This means that the changes cannot reflect in the same connection.

For UDP, I don't see a technical reason for waiting for a new connection other than the TTS architecture.

What we can do is to trigger a server-side disconnect of the gateway if the antenna gain is adjusted? Then the gateway can reconnect and fetch new data. Would that be something that works for your requirement?

[virtualguy]

Yes that sounds good, a server side forced reconnection should do the trick

[KrishnaIyer]

Ok thanks. Do @adriansmares or @johanstokking see a reason against triggering a gateway reconnection on antenna gain change? We have this mechanism already for changes in the location type.

[adriansmares]

I don't see a reason against it - we probably should just update this check to also look at the antenna gain.

lorawan-stack/pkg/gatewayserver/gatewayserver.go

Lines 601 to 630 in ed1a5f8

	func requireDisconnect(connected, current *ttnpb.Gateway) bool {
	if !sameAntennaLocations(connected.GetAntennas(), current.GetAntennas()) {
	// Gateway Server may update the location from status messages. If the locations aren't the same, but if the new
	// location is a GPS location, do not disconnect the gateway. This is to avoid that updating the location from a
	// gateway status message results in disconnecting the gateway.
	if len(current.Antennas) > 0 && current.Antennas[0].Location != nil && current.Antennas[0].Location.Source != ttnpb.LocationSource_SOURCE_GPS {
	return true
	}
	}
	if connected.DownlinkPathConstraint != current.DownlinkPathConstraint ||
	connected.DisablePacketBrokerForwarding != current.DisablePacketBrokerForwarding ||
	connected.EnforceDutyCycle != current.EnforceDutyCycle ||
	connected.LocationPublic != current.LocationPublic ||
	connected.RequireAuthenticatedConnection != current.RequireAuthenticatedConnection ||
	ttnpb.StdDurationOrZero(connected.ScheduleAnytimeDelay) != ttnpb.StdDurationOrZero(current.ScheduleAnytimeDelay) ||
	connected.ScheduleDownlinkLate != current.ScheduleDownlinkLate ||
	connected.StatusPublic != current.StatusPublic ||
	connected.UpdateLocationFromStatus != current.UpdateLocationFromStatus ||
	connected.FrequencyPlanId != current.FrequencyPlanId ||
	len(connected.FrequencyPlanIds) != len(current.FrequencyPlanIds) ||
	connected.GatewayServerAddress != current.GatewayServerAddress {
	return true
	}
	for i := range connected.FrequencyPlanIds {
	if connected.FrequencyPlanIds[i] != current.FrequencyPlanIds[i] {
	return true
	}
	}
	return false
	}

[johanstokking]

Yes, sounds like a good reason to reconnect.