Radio Silence

Updated

1. Introduction

Radio silence is disabling all radio transmission for safety or security reasons. This is commonly used to mitigate the risk of radio frequency interference with other instruments in the vicinity of the Edge Node. However, it is often just the regulations prohibiting radio devices in some areas or during certain procedures.
 
The following illustration shows the possible ways of applications getting connected with different network instance types, along with the disabled WiFi and LTE connections.
Radio Silence.png
 

2. Permanent Radio Silence

In some countries/regions or designated areas, it may be required that an Edge Node is deployed with all wireless devices permanently disabled and with only wired connectivity options used to communicate with the controller. EVE-OS can easily accomplish this because the default state for wireless devices (as imposed by EVE-OS) is to disable radio transmission. As long as LTE/WiFi network adapter is configured with 'Disabled' interface usage in ZedUI, EVE-OS will prevent the device from emitting any power over the radio.
 

3. Temporary Radio Silence

In situations where wireless communication may interfere with other instruments during a certain procedure of limited duration, it may be necessary to disable radio transmission temporarily. If there are no wired connection alternatives, the Edge Node will lose connectivity with the controller. Still, it should not cause the node to reboot, fall back to the previous network configuration or do anything else that may negatively affect applications running on it. For safety reasons and uncertain accessibility to the controller, it is typically required that the radio silence mode be switched ON and OFF locally and not managed remotely.
 
With these requirements in mind, EVE-OS was designed to use the Local profile server (a designated application overriding controller for a small subset of the config) with a separate Radio endpoint to obtain the required state of the radio silence mode periodically and to publish the actual state. Intentionally, it is not possible to enable or disable radio silence remotely through the controller. Still, the controller is at least used to deploy the application, mark it as a Local profile server, and specify string token that the application will have to present to EVE-OS with each request to authenticate itself. This is submitted to the Edge Node using the local_profile_server and profile_server_token fields from EdgeDevConfig.
 

3.1. Radio Endpoint Semantic

Without a Local profile server deployed or configured (from the controller), the default behavior is to enable radio transmission for all wireless devices with a network configuration attached and disable the rest. In other words, temporary radio silence is disabled by default, and only unused devices are (permanently) silenced.
 
Once a Local profile server has been deployed and the application transitioned to the "running" state, EVE-OS will start periodically making a POST request to the Radio endpoint. If this (optional) endpoint is not implemented, the default policy for radio transmission will remain in effect. If the endpoint is available, EVE-OS will provide an update of the current state of wireless devices in the POST request body, formatted and marshaled using the RadioStatus proto message.
 
Suppose a response from the application contains no content (response code 204). In that case, EVE-OS assumes that the intended radio silence state has not changed (the initial intended state is a disabled radio silence). Application response with non-empty content (response code 200) is unmarshalled into RadioConfig protobuf message. EVE-OS will accept the new radio configuration if the unmarshalling succeeds and the token matches the expected value configured through the controller. Currently, apart from the token, RadioConfig contains only a single boolean field which determines if the radio silence should be imposed or lifted.
 
Whenever the newly received intended state of the radio silence mode differs from the currently applied state, EVE-OS will trigger an operation of switching radio transmission ON/OFF on all (used) wireless devices. This operation takes some time, during which EVE-OS stops publishing radio status updates and receiving new radio configs. This is purely to simplify the implementation and avoid any interleaving between config updates and state changes. Once the new radio config was applied (successfully or with an error), EVE-OS will restart the periodic radio status updates and POST the operation's outcome back to the application via the radio endpoint.
 
A formal definition for the syntax and the semantics of the radio endpoint can be found
here
​

3.2. Persistence

The intended radio silence configuration does not change even if the application or the Edge Node reboots (see risks and limitations associated with the Edge Node reboot).
 
Once the Local profile server is unconfigured or undeployed, EVE-OS discards the last radio config and restores the default behavior of disabled radio silence.
 

3.3. Controller Connectivity

While the radio silence is imposed, it is normal for the Edge Node to lose access to the controller, especially if there are no wired connectivity alternatives. Typically, this could cause the network configuration to fall back to a previous state in an attempt to restore the connectivity. However, in this case, this behavior is not desirable. Therefore the network connectivity testing and the fallback mechanism are disabled during the radio silence.
 
Please note that there is also a timer inside EVE-OS to reboot the device if it has not had controller connectivity for a prolonged time period - by default, this is configured to one week. Since it is not expected that a temporary radio silence would remain turned ON for an extended time in practice, this timer remains enabled even when radio communication is disabled.
 

3.4. Expected Application Behavior

An application acting as a Local Profile Server for the radio management is expected to behave as follows:
 
  • The application provides UI on the user-side and runs an HTTP server with /api/v1/radio the endpoint on the EVE-OS side.
  • The application UI should allow to:
    • Toggle the radio silence intended state (ON/OFF) and as a result, change the message content that the HTTP server will respond with to /api/v1/radio POST calls.
    • Show the last received actual state and the last error if there was any (periodically POSTed to /api/v1/radio by EVE-OS).
    • Show that an operation of changing the radio state is still ongoing (e.g., a "loading gif"). This starts from a moment of a user changing the intended state in the UI, continues through the next POST API call (from which EVE-OS learns the new intended state, different from the actual state), up to the second next POST API call with the actual radio state after attempting to apply the new intended config (please remember that for simplicity's sake there will be no POST API calls while a change is ongoing).
 

3.5. Radio Silence Indication

When radio silence is temporarily imposed, the device status indicator (by default, LED of the disk) repeats a pattern of blinking 5 times in a row. The pattern is the same regardless of the device's state before the radio silence was imposed. More information about the node state indication using LED can be found here.
 
Additionally, Diagnostics prints information about radio silence state changes into the console, mostly for debugging purposes.
 

4. Risks and Limitations

The current implementation of the radio silence mode has a few limitations that users should be aware of, mainly if used for safety-critical use-cases.
 
  • Currently supported are cellular modems and WiFi adapters. Bluetooth devices are NOT covered.
  • The Linux rfkill subsystem is used for WiFi adapters to enable/disable radio communication. However, this requires a corresponding rfkill driver to be available and loaded into the kernel for every attached WiFi adapter. Run rfkill command from the debug console and look for a table entry with wlan TYPE. For some devices, it may be necessary to enable certain *_RFKILL=y kernel parameters to build their drivers (e.g. CONFIG_ATH9K_RFKILL=y).
  • For cellular modems, we use QMI and MBIM protocols for management. Both of these protocols provide APIs to enable/disable radio transmission. However, cellular modems that do not support any of these protocols (and likely only AT commands) cannot be managed by EVE-OS. The radio transmission will remain in the modem's default state (which usually is ON).
  • Radio silence only applies to wireless network adapters visible to EVE-OS. Adapters directly assigned to applications are not covered. It is up to those applications to manage the state of radio transmission.
  • The intended radio configuration is obtained from the Local profile server through periodic polling. However, because we want to limit the delay between a user turning radio silence ON/OFF and the requested change taking effect, the polling period is set to 5 seconds, i.e., substantially less than the default 1 minute period for Edge Node config retrieval from the controller. Still, it may take several seconds to enable/disable radio silence. Especially with cellular modems and QMI/MBIM protocols, there is some latency in response from the modem itself. Users should wait for the Local profile server application to display a confirmation in the UI of a finalized state change (and whether it succeeded).
  • Suppose the radio silence is imposed while the Edge Node reboots. There could be a short window between the boot and EVE-OS microservices starting and applying the persisted state, during which wireless devices might, in theory, manage to turn on and transmit some signals quickly. This also applies to permanently disabled wireless devices (i.e., without network config). However, this risk is mitigated in EVE-OS quite well. WiFi cards avoid this by using a kernel command line parameterrfkill.default_state=0to ensure that WiFi radios are initially all disabled and can be turned ON only by an EVE-OS microservice. However, we rely on cellular modems to support configuration persistence. For example, SierraWireless modems EM7565 and MC7455that were tested and verified with EVE-OS do support persistence.
  • The last limitation (not a risk) is that by design, the local profile override and the radio silence mode both have to be managed by the same application.
Was this article helpful?
1 out of 1 found this helpful