Page History

...

message RadioStatus {
	// true if enabled AND successfully applied
	bool airplane_mode = 1;
	// If the last radio configuration change failed, error message is reported here.
	// Please note that there is also a per-modem configuration error reported under CellularStatus.
	string config_error = 2;
	// for every LTE network
	repeated CellularStatus cellular_status = 3;
	// later we can add status for every WiFi network
}

message CellularStatus {
	// logicallabel ofLogical label assigned to the physical devicecellular modem.
	string deviceNamelogicallabel = 1;
	CellularModem modemorg.lfedge.eve.common.ZCellularModuleInfo module = 2;
	OperatingState operatingStaterepeated org.lfedge.eve.common.ZSimcardInfo simCards = 3;
	string controlProtocolrepeated org.lfedge.eve.common.ZCellularProvider providers = 4; // "qmi" or "mbim"
	string imeiconfigError = 510;
	repeatedstring CellularProvider providersprobeError = 611;
	// if the last configuration change failed, error message is reported here
	string configError = 10;
	// wwan servise periodically pings configured IP address. 
	// If the last probing failed, stderr of the probing method is published here.
	string probeError = 11;
}

message CellularModem {
	string model = 1;
	string revision = 2;
}  

enum CellularOperatingState {
	OPERATING_STATE_UNSPECIFIED = 0;
	OPERATING_STATE_ONLINE = 1;
	OPERATING_STATE_ONLINE_AND_CONNECTED = 2;
	OPERATING_STATE_RADIO_OFF = 3;  (AKA airplane mode)
	OPERATING_STATE_OFFLINE = 4;
	...
}

message CellularProvider {
	string plmn = 1;
	string description = 2;
	bool currentServing = 3;
	bool roaming = 4;
}

The Local profile server application may either reply with status 204 (No content), acknowledging the received state data update but not requiring any configuration changes, or return 200 (OK) and append response body with the intended radio state encoded using this proto message:

message RadioConfig {
	bool airplaneMode = 1;
	string serverToken = 2;
}

If the actual state and the returned intended state differ, EVE will trigger the operation of applying the intended state (e.g. disabling the radio). The outcome of this operation (i.e. the new state, with potential error message if the change failed) will be published by the next POST call. If the actual and the intended state are the same, EVE will not perform any airplane-mode changes at least until the next POST call.

EVE API - device configuration (i.e. API between EVE and the controller)

Since we are reusing the Local profile server here, the existing configuration fields are sufficient to enable and select the application that will manage the airplane mode state.

Specifically, these two parameters will be reused for the airplane mode purposes:

message EdgeDevConfig {
  ...

  // local_profile_server, if set, indicates a hostname/IPv4/IPv6 address and
  // optional port number at which EVE will request for a local profile.
  // If such a local profile is retrieved, it will override the global_profile.
  // The syntax follows the usual URL server name syntax thus the following
  // are example valid strings:
  //    [fe80::1]:1234
  //    10.1.1.1:1234
  //    hostname:1234
  //    [fe80::1]
  //    10.1.1.1
  //    hostname
  // If the port number is not specified, it will default to 8888
  string local_profile_server = 28;
  // Together with a local_profile_server one can specify a
  // profile_server_token. EVE must verify that the response from the
  // local_profile_server contains this token.
  string profile_server_token = 29;
}

As a result, no changes/additions are needed to be implemented on the controller side.  Only the UI / documentation could mention that there is this additional usage of the local profile server. Also, the current state of the airplane mode will be presented to the controller (see below) and it could be therefore displayed alongside other network state information.

EVE API - device info (i.e. API between EVE and the controller)

}

Where ZCellularModuleInfo, ZSimcardInfo and ZCellularProvider are defined in api/proto/evecommon/wireless.proto as follows:

enum ZSimcardState {
  Z_SIMCARD_STATE_INVALID     = 0;
  Z_SIMCARD_STATE_ASSIGNED    = 1;
  Z_SIMCARD_STATE_PROVISIONED = 2;
  Z_SIMCARD_STATE_ACTIVE      = 3;
  Z_SIMCARD_STATE_SUSPENDED   = 4;
  Z_SIMCARD_STATE_CANCELLED   = 5;
}

message ZSimcardInfo {
  // Name is a SIM card identifier. For example ICCID if available.
  // Guaranteed to be unique only in the scope of the edge node.
  string name = 1;
  // Reference to ZCellularModuleInfo.name
  string cellularModuleName = 2;
  string imsi = 3;
  string iccid = 4;
  ZSimcardState state = 5;
}

message ZCellularModuleInfo {
  // Name is a module identifier. For example IMEI if available.
  // Guaranteed to be unique only in the scope of the edge node.
  string name = 1;
  string imei = 2;
  string firmwareVersion = 3;
  string model = 4;
  ZCellularOperatingState operatingState = 5;
  ZCellularControlProtocol controlProtocol = 6;
}

enum ZCellularOperatingState {
  OPERATING_STATE_UNSPECIFIED = 0;
  OPERATING_STATE_OFFLINE = 1;
  OPERATING_STATE_RADIO_OFF = 2; // AKA airplane mode
  OPERATING_STATE_ONLINE = 3;
  OPERATING_STATE_ONLINE_AND_CONNECTED = 4;
  OPERATING_STATE_UNRECOGNIZED = 5;
}

enum ZCellularControlProtocol {
  CONTROL_PROTOCOL_UNSPECIFIED = 0;
  CONTROL_PROTOCOL_QMI = 1;
  CONTROL_PROTOCOL_MBIM = 2;
}

message ZCellularProvider {
  // Public land mobile network code.
  string plmn = 1;
  string description = 2;
  // True if this is the provider currently being used.
  bool currentServing = 3;
  bool roaming = 4;
}

The Local profile server application may either reply with status 204 (No content), acknowledging the received state data update but not requiring any configuration changes, or return 200 (OK) and append response body with the intended radio state encoded using this proto message:

message RadioConfig {
	string serverToken = 1;
	bool airplaneMode = 2;
}

If the actual state and the returned intended state differ, EVE will trigger the operation of applying the intended state (e.g. disabling the radio). The outcome of this operation (i.e. the new state, with potential error message if the change failed) will be published by the next POST call. If the actual and the intended state are the same, EVE will not perform any airplane-mode changes at least until the next POST call.

EVE API - device configuration (i.e. API between EVE and the controller)

Since we are reusing the Local profile server here, the existing configuration fields are sufficient to enable and select the application that will manage the airplane mode state.

Specifically, these two parameters will be reused for the airplane mode purposes:

message EdgeDevConfig {
  ...

  // local_profile_server, if set, indicates a hostname/IPv4/IPv6 address and
  // optional port number at which EVE will request for a local profile.
  // If such a local profile is retrieved, it will override the global_profile.
  // The syntax follows the usual URL server name syntax thus the following
  // are example valid strings:
  //    [fe80::1]:1234
  //    10.1.1.1:1234
  //    hostname:1234
  //    [fe80::1]
  //    10.1.1.1
  //    hostname
  // If the port number is not specified, it will default to 8888
  string local_profile_server = 28;
  // Together with a local_profile_server one can specify a
  // profile_server_token. EVE must verify that the response from the
  // local_profile_server contains this token.
  string profile_server_token = 29;
}

As a result, no changes/additions are needed to be implemented on the controller side.  Only the UI / documentation could mention that there is this additional usage of the local profile server. Also, the current state of the airplane mode will be presented to the controller (see below) and it could be therefore displayed alongside other network state information.

EVE API - device info (i.e. API between EVE and the controller)

message DevicePort {
	...
	WirelessStatus wirelessStatus = XY;
}

message WirelessStatus {
	// either LTE or WiFi (or not wireless)
	WirelessType type = 1;
	// for LTE:
	repeated CellularStatus cellularStatus = 5; 
	// later we may add status for WiFi
}

message ZCellularStatus {
  // Name reference (ZCellularModuleInfo.name) to the corresponding cellular module
  // from the list ZInfoDevice.cellularModules
  string cellularModule = 1;
  // Each item is a name reference (ZSimcardInfo.name) to a SIM card from the list ZInfoDevice.simCards
  // Ordered by slot numbers.
  repeated string simCards = 2;
  // List of available cellular service providers.
  repeated org.lfedge.eve.common.ZCellularProvider providers = 3;
  // If EVE failed to configure the cellular connection, the error is published here.
  string configError = 10;
  // if the connectivity probing is failing, error is reported here
  // (see CellularConnectivityProbe).
  string probeError = 11;

message DevicePort {
	...
	WirelessStatus wirelessStatus = XY;
}

message WirelessStatus {
	// either LTE or WiFi (or not wireless)
	WirelessType type = 1;
	// for LTE; see CellularStatus defined above
	repeated CellularStatus cellularStatus = 5; 
	// later we may add status for WiFi
}

EVE API - device metrics (requested by the same customer)

message deviceMetric {
	...
	repeated CellularMetric cellularMetric = XY;
}      

message CellularMetric {
	// logicallabel of the physical device
	string deviceNamelogicallabel = 1;
	CellularSignalStrength signalStrength = 2;
	CellularPacketStats    packetStats = 3;
}      

// Value of 0xFFFF means that the particular metric is not available.
message CellularSignalStrength {
	int32 rssi = 1;
	int32 rsrq = 2;
	int32 rsrp = 3;
	int32 snr = 4;
}

// Collected by the modem itself and can be obtained using
// e.g. "qmicli -d /dev/cdc-wdm0 --wds-get-packet-statistics"
message CellularPacketStats {
	// NetworkStats are already defined in EVE API
	NetworkStats rx = 1;
	NetworkStats tx = 2;
}

...

A new /run/wwan/config.json will be addedto submit LTE configuration from nim to wwan service, including the required airplane mode state, e.g.:

{
	“airplane"airplane-mode”mode": true,
	"modemsnetworks": [
		{
			"devicelogical-namelabel": "lte-modem1", # logicallabel oflogical label assigned to the physical modem device
			"physical-addrs": {
				# nim will specify one/some of these. With multiple LTE modems the USB address is the most unambiguous and reliable.
				“interface”: “wwan0”"interface": "wwan0",
				“usb”"usb": “1"1:2.3”3", # <bus>:[port]
				"pci": "0000:11:00.0",
			},
			“apns”"apns": [“internet”],
			“probe-address”: “8.8.8.8”"internet"],
			"probe": {
				"disable": "false"
				"address": "8.8.8.8",
				"interval": 300  # in seconds
            }
		},
	]
}

Note: interface/usb/pci will be obtained by nim from AssignableAdapters based on the PhyLabel of NetworkPortConfig.

Next a new /run/wwan/status.json with modem cellular state data will be published by wwan service for nim to read. Status file will contain MD5 checksum of the last applied revision of config.json. With this, EVE will know when there are no more pending configuration changes, so that it is ready to publish radio state up to the application.

{
	// MD5 checksum of config.json applied at the time of publishing this info
	"config-checksum": "d7548db5594b064f2c9ec0599e84523e",
	"modemsnetworks": [
		{
			"devicelogical-namelabel": "lte-modem1",    # can be empty for modems not configured from the controller
			"physical-addrs: {
				# all addresses will be filled by wwan service
				“interface”: “wwan0”,
				“usb”: “1:2.3”, # <bus>:[port]
				"pci": "0000:11:00.0",
			},
			"cellular-module": {
				“interface”"imei": “wwan0”“310170845466094”,
				“usb”"model": “1:2.3”, # <bus>:[port]"QUECTEL Mobile Broadband Module",
				"pcirevision": "0000:11:00.0EC21ECGAR06A04M1G",
			},
			"control-protocol": "qmi" | "mbim",
				"operating-mode": "offline" | "online" | "online-and-connected" | "radio-off" | "unrecognized"
			},
			"imeisim-cards": “310170845466094”,[
				"modem": {
					"modeliccid": "QUECTEL Mobile Broadband Module8991101200003204514",
					"revisionimsi": "EC21ECGAR06A04M1G313460000000001",
				}
			],
			"config-error": "",
			"probe-error": "Failed to ping 8.8.8.8 (2 packets transmitted, 0 received, 100% packet loss, time 1029ms)",
			"providers": [
				{
					"plmn": "310-410",
					"description": "AT&T",
					"current-serving": true,
					"roaming": false
				},
				{
					"plmn": "310-120",
					"description": "O2",
					"current-serving": false,
					"roaming": false
				}
			]
		}
	]
}

...

{
	"modems": [
		{
			"devicelogical-namelabel": "lte-modem1",    # can be empty for modems not configured from the controller
			"physical-addrs: {
				# all addresses will be filled by wwan service
				“interface”: “wwan0”,
				“usb”: “1:2.3”, # <bus>:[port]
				"pci": "0000:11:00.0"
			},
			"packet-stats": {
				"rx-bytes": 456456,
				"rx-packets": 1234,
				"rx-drops": 0
				"tx-bytes": 23485,
				"tx-packets": 758,
				"tx-drops": 12
			},
			"signal-info": {
				"rssi": -42,
				"rsrq": -11,
				"rsrp": -98,
				"snr": 56
			}
		}
	]
}

...