UniPro protocol stack
In mobile-telephone technology, the UniPro protocol stack[1] follows the architecture of the classical OSI Reference Model.
The Physical Layer (L1) is covered in separate MIPI specifications in order to allow the PHY to be reused by other (less generic) protocols if needed.
Data rates of the D-PHY are variable, but are in the range of 500-1000 Mbit/s (lower speeds are supported, but at decreased power efficiency).
Data traffic in the forward and reverse directions are totally independent at this level of the protocol stack.
It is worth noting that UniPro supports the power efficient low speed communication modes provided by both the D-PHY (10 Mbit/s) and M-PHY (3 Mbit/sec up to 500 Mbit/s).
Furthermore, both PHY technologies provide additional power saving modes because they were optimized for use in battery-powered devices.
Abstracted PHY details include the various power states and employed symbol encoding schemes.
In the figures, the control bits are shown in "L1.5 red" as a reminder that they are defined in- and used by protocol Layer 1.5.
To the user, such a multi-lane link simply looks like a faster physical layer because the symbols are sent across 2, 3 or 4 lanes.
Starting in UniPro v1.4, L1.5 automatically discovers the number of usable M-PHY lanes for each direction of the link.
In addition to the L1.5 link power management the PACP is also used to access control and status parameters of the peer UniPro device.
L2 clusters 17-bit UniPro L1.5 symbols into packet-like data frames (the term packet is reserved for L3).
High speed communication at low power levels can lead to occasional errors in the received data.
This results in an incorrect data or control frame checksum at the receiver side and will lead to its automatic retransmission.
In UniPro version 1.1, an option was introduced to allow simple endpoint devices to implement only one of the two Traffic Classes if they choose to.
This is different from, for example, the widely used TCP protocol that detects errors at the endpoints and relies on end-to-end retransmission in case of corrupted or missing data.
Switches within a multi-hop network use this address to decide in which direction to route individual packets.
Version 1.4 of the UniPro spec does not specify the details of a switch, but does specify enough to allow a device to work in a future networked environment.
This implies that, in UniPro, the concepts of an L2 Frame, an L3 Packet and an L4 Segment (see below) are so closely aligned that they are almost synonyms.
This mechanism aims to allow UniPro v1.4 devices to be able to be upgraded in order to support protocols that require the as-yet undefined long-header packets.
Applications are required to use L4's top interface to interact with UniPro and are not expected to bypass L4 to directly access lower layers.
Note that the interface at the top of L4 provided for transmitting or receiving data is defined at the behavioral or functional level.
The main field in the short L4 header is a 5-bit "CPort" identifier which can be seen as a sub-address within a UniPro device and is somewhat analogous to the port numbers used in TCP or UDP.
Unless resolved fast, this traffic jam at the destination quickly grows into a network-wide gridlock.
This is highly undesirable as it can greatly affect network performance for all users or, worse, can lead to deadlock situations.
But L4 flow control works between a pair of CPorts (potentially multiple hops apart) and aims to isolate connections from one another ("virtual wire" analogy).
In contrast, L2 flow control is per-hop and avoids basic loss of data due to lack of receiver buffer space.
UniPro provides "safety net" mechanisms that mandate that a CPort absorbs all data sent to it without stalling.
Message boundaries are triggered by the application-level protocol using UniPro and are signaled via a bit in the segment header.
It provides access to control and status parameters in all layers, manages the power mode transitions of the Link and handles the boot-up, hibernate and reset of the stack.
