...
In order to limit the latency and the risk of race conditions, we proposed a separate and a shorter time period between EVE calls to radio POST API. Additionally, EVE will not make radio POST calls while a change is ongoing, thus enforcing at most one configuration change to be in progress at a time. Conversely, when an airplane mode change is finalized, EVE may call radio POST API with radio state update immediately, instead of waiting for the timer to fire. Internally, we will also try to minimize delay in communication between microservices (zedagent, nim, wwan).
Another issue is that when an external modem (e.g. USB dongle) gets physically re-connected, or if the entire device reboots, the operational state of the radio resets back to online. It was at least the case with the LTE modem tested for this proposal. Between modem resetting or edge device booting and wwan service noticing that the state is not as intended, there is a delay during which the device might emit power over radio, which is a safety risk. In Linux, the rfkill subsystem provides a kernel command line option to disable/enable radio on boot automatically. We may need to implement something similar for EVE. Perhaps the radio could be always disabled on boot, with only wwan service having the control to enable it once the configuration is received with airplane mode turned off. But please note that device reboots during the airplane mode are not acceptable for this particular customer, hence the priority is to keep the device running.
One last One more issue, or rather an open question, is whether we can actually combine the Local Profile server with the airplane mode or if there is a customer requirement to have them separated and managed from different applications. This remains to be communicated with the customer. However, by having /api/v1/radio and /api/v1/local_profile as separate endpoints, it should be possible and relatively easy to allow them to be handled by different applications.