[ [https://members.mipi.org/mipi-adopters/file/Specifications/Board%20Approved/MIPI%20UniPro%20Specification_v01-00-00.pdf UniPro 1.00 spec] , requires an account at the MIPI website] protocol stack follows the architecture of the classical OSI Reference Model. In UniPro, the OSI Physical Layer is split into two sublayers: Layer 1 (the actual physical layer) and Layer 1.5 (the PHY Adapter layer) which abstracts from differences between alternative Layer 1 technologies. The actual physical layer is a separate specification as the various PHY options are reused [ [http://www.mipi.org/wgoverview.shtml Overview of MIPI specifications] , D-PHY is used in the DSI, CSI, and UniPro specifications, M-PHY is used in the UniPro and DigRFv4 specifications] in other MIPI Alliance specifications.]L1.5 thus has its own (conceptual) symbol encoding consisting of 17-bit symbols. These 17-bit symbols never show up on the wiring, because they are first converted by L1.5 to a pair of PHY symbols. The extra 17th control bit indicates special control symbols which are used by L2. In the figures, the control bits are shown in red as a reminder that they are defined in- and used by protocol Layer 1.5.
Data Link Layer (L2)
The main task of UniPro's Data Link layer is to enable communication across a single hop of the network in a reliable way.
L2 data frames
The Data Link layer (L2) clusters 17-bit UniPro symbols into packet-like data frames (the term packet is reserved for L3). These data frames start with a 17-bit start-of-frame control symbol, followed by up to 288 bytes of data (144 data symbols) and followed by an end-of-frame control symbol and a checksum. The value of 288 was chosen to ensure that the entire protocol stack could easily transmit 256 bytes of application data in a single chunk.
Payload consisting of odd numbers of bytes are supported by padding the frame to an even number of bytes and a corresponding flag in the trailer.
L3 packet structure
The picture shows an L3 packet which starts at the first L2 payload byte of an L2 frame and ends at the last L2 payload byte of an L2 frame. For simplicity and efficiency reasons no other options are allowed: an L3 packet cannot span multiple L2 frames and an multiple L3 packets cannot be squeezed onto one frame. This implies that, in UniPro, the concepts of L2 Frame, L3 Packet and L4 Segment (see below) are so closely aligned that they are almost synonyms. The distinction (and "coloring") is however still made to ensure that the specification can be described in a strictly layered fashion.
Note that some UniPro packets (will) have more than a single byte L3 header. The shown structure is, however, a common and typical one.
Transport Layer (L4)
Although Transport Layer part of the UniPro specification is not especially long or complex, it is somewhat subtle because its features are not easily related to physical transport of data in space. The layer tends to exist in the twilight zone between "clearly" hardware and "clearly" software worlds. Some of the confusion will be because UniPro's L4 is clearly different from what hardware bus people may be used to (system busses, PCI Express), but also different (due to different requirements) from corresponding layer (TCP and UDP) in the TCP/IP protocol stack.
L4 features
UniPro's Transport layer adds one extra level of addressing within an L3 device. This
* allows two UniPro devices to communicate with each other using more than one stream of data (like an audio and a video link).
* allows a UniPro device to simultaneously connect to multiple other devices (this requires switches as supported in a future version of UniPro)
* defines the structure of the top interface which UniPro exposes to its applications.
* provides mechanisms to avoid congestion on the network.UniPro L4's End-of-Message feature will be explained separately later.
L4 segments
An L4 segment, is essentially the L4 equivalent of an L3 packet. The main addition in the extra L4 header (one byte or more) is an extra CPort identifier. This 5-bit address can be seen as a subaddress of an L3 device and is somewhat analogous to the port numbers used in TCP/IP. Thus every segment which crosses the network is addressed to a specific port of specific UniPro device.
L4 connections and flow control
UniPro calls a pair of CPorts that communicate with each other a connection (hence the C in CPort). Setting up a connection means that one CPort has been initialized to create segments which are addressed to a specific L4 CPort of a specific L3 DeviceID using a particular L2 Traffic Class and vice versa (UniPro connections and CPorts are bi-directional).
In UniPro 1.0/1.1 connection setup is assumed to be relatively static (states of both connected CPorts aligned by the rspective UniPro devices). In a later version, this will be be replaced by a conventional (dynamic) connection management protocol.
CPorts also contain variables (state) used to track how much buffer space the peer CPort at the other end of the link has. This is used to prevent the situation whereby a CPort sends segments to a CPort which it cannot store, thus leading to a traffic jam that starts at the destination and a rapidly moves towards the data source, congesting the network for other users as well. This mechanism at L4 is known as end-to-end flow control because it involves the endpoints of a connection regulating their mutual traffic. This makes L4 flow control complementary to L2 flow control. The latter is less fine grained (no distinction between connections) and serves to avoid data loss rather than avoid congestion on the network. Internet's equivalent, the TCP protocol, has a similar congestion management feature, although it works very differently.
L4 and Messages
UniPro L4 allows a connection to be structured (by the application protocol) as a stream of so-called messages rather than as a stream of bytes. Boundaries between subsequent messages need to coincide with segment boundaries and are signaled via a bit (End-of-Message flag) in the L4 header. UniPro itself thus does not know where to place these EoM flags unless told by the application and does not know what they mean. UniPro merely conveys the information to the final destination.
This can be useful as a mechanism to implement robust and efficient resynchronization points in some application streams. It saves having to define some special magic sequence of bytes for this and having to worry about whether that sequence can occur under other circumstances. There are other (also advanced) uses thinkable for the EoM flag.
References
ee also
* UniPro
* MIPI Alliance
