The information below is taken from MDK v.0.2
Project Ara utilizes the UniPro protocol for inter-module communication. The UniPro specification is defined by the MIPI Alliance. UniPro’s design follows a layered architecture, and specifies how communication shall occur up to the Application layer in the OSI model. Project Ara’s architecture requires an application layer specification which can handle dynamic device insertion and removal from the system at any time and at variable locations. It also requires that existing modules interoperate with modules introduced at later dates.
In addition to UniPro, Project Ara also specifies a small number of other interfaces between modules and the endoskeleton. These include a power bus, signals which enable hotplug and power management functions, and interface pins for modules which emit radio signals. The Greybus Specification also defines the behavior of the system’s software with respect to these interfaces.
A Project Ara module is a device that slides into a physical slot on a Project Ara endoskeleton. Each module communicates with other modules on the network via one or more UniPro CPorts. A CPort is a bidirectional pipe through which UniPro traffic is exchanged. Modules send messages via CPorts; messages are datagrams with ancillary metadata. All CPort traffic is peer-to-peer; multicast communication is not supported.
Project Ara presently requires that exactly one application processor (AP) is present on the system for storing user data and executing applications. The module which contains the AP is the AP module; the Greybus specification defines a Control Protocol to allow the AP module to accomplish its tasks.
In order to ensure interoperability between the wide array of application processors and hardware peripherals commonly available on mobile handsets, the Greybus Specification defines a suite of Device Class Connection Protocols, which allow for communication between the various modules on the system, regardless of the particulars of the chipsets involved.
The main functional chipsets on modules may communicate via a native UniPro interface or via bridges, special-purpose ASICs which intermediate between these chipsets and the UniPro network. In order to provide a transition path for chipsets without native UniPro interfaces, the Greybus Specification defines a variety of “bridged-phy-protocols”, which allow module developers to expose these existing protocols to the network. In addition to providing a “on-ramp” to the platform, this also allows the implementation of modules which require communication that does not comply with a device class protocol.