Command Execution Extension service (CEX) extends the communication capability of Kaa Protocol (1/KP) by implementing Command Execution Protocol (11/CEP). CEX supports this extension protocol to deliver commands to endpoint and consume endpoint command execution result. As with other Kaa extension services, CEX uses Extension Service Protocol (4/ESP) for integration with a communication service.

Commands are provided by command invocation caller. CEX implements a proactive command push—commands are sent to an endpoint as soon as possible, and an explicit endpoint subscription is not required. Note that explicit subscription is still recommended.


CEX supports a number of interfaces to perform its functional role. The key supported interfaces are summarized in the following diagram.

CEX interfaces diagram

For inter-service communication, Kaa services mainly use REST APIs and messaging protocols that run over NATS messaging system.

Command invocation protocol

CEX acts as a command invocation agent according to 12/CIP. This protocol is used to accept command invocation request and return command invocation result back to command invocation caller

Extension service protocol

CEX uses 4/ESP over NATS to exchange 11/CEP messages with endpoints through a communication service.

Command store

In some scenarios, endpoint can be inaccessible during command invocation request emission, thus it will not get a message with a command.

CEX persists commands for a configurable amount of time. So endpoint has an ability to request already scheduled commands.

Command store is maintained in Redis.

Command execution flow

The overall command invocation and execution sequence diagram can be illustrated as follows:

CEX sequence diagram