UniPro protocol stack
The UniPro protocol stack follows the classical OSI reference architecture (ref). For practical reasons, OSI's 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.
| Layer # | Layer name | Functionality | Data unit name |
|---|---|---|---|
| LA | Application | Payload and transaction semantics | Message |
| 4 | Transport | Ports, multiplexing, flow control | Segment |
| 3 | Network | Addressing, routing | Packet |
| 2 | Data link | Single-hop reliability and priority-based arbitration | Frame |
| 1.5 | PHY adapter | Physical layer abstraction and multi-lane support | UniPro symbol |
| 1 | Physical layer (PHY) | Signaling, clocking, line encoding, power modes | PHY symbol |
The UniPro specification itself covers Layers 1.5, 2, 3, and 4. The Application Layer (LA) is out of scope because different uses of UniPro will require different LA protocols. 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.
Note that OSI Layers 5 (Session) and 6 (Presentation) are, where applicable, counted as part of the Application Layer.
Physical Layer (L1)
D-PHY
Versions 1.0 and 1.1 of UniPro use MIPI's D-PHY technology for the off-chip Physical Layer. This PHY allows inter-chip communication over printed circuit board traces as well over roughly 20 cm of cabling. Data rates of the D-PHY are variable, but are in the order of 500-1000 Mbit/s (although lower speeds are supported). The D-PHY was named after the Roman number for 500 ("D").
The D-PHY uses differential signaling to convey PHY symbols over micro-stripline wiring. A second differential signal is used to transmit the associated clock signal from the source to the destination. The D-PHY technology thus uses a total of 4 signal wires per direction. Traffic and return traffic are totally independent at this protocol level.
In UniPro, the D-PHY is used in a mode (called "8b9b" encoding) which conveys 8-bit bytes as 9-bit symbols. The UniPro protocol uses this to represent special control symbols (outside the usual 0 to 255 values). The PHY itself uses this to represent certain special symbols that have meaning to the PHY itself (e.g. IDLE symbols). Note that the ratio 8:9 can cause some confusion when specifying the data rate of the D-PHY.
The D-PHY also supports a Low-Power Data Transmission (LPDT) mode and various other low-power modes for use when no data needs to be sent.
| PHY technology | Version / Released | Symbol encoding | Mbit/s (payload) | Signal wires | Supported in | Spec pages |
|---|---|---|---|---|---|---|
| D-PHY | 0.90.00 / 13-Nov-2007 | 8b/9b | up to circa 900 | 4 per direction | UniPro 0.80 and up | 131 |
| M-PHY | t.b.d. / t.b.d. | 8b/10b | 1000 and higher | 2 per direction | UniPro 1.50 and up | ? |
M-PHY
Versions 1.5 and beyond of UniPro plan to support both the D-PHY as well as M-PHY technology. The M-PHY technology is still unreleased, but is expected to support data rates starting at about 1000 Mbit/s (the M-PHY was named after the Roman number for 1000). In addition to higher speeds, the M-PHY will use fewer signal wires because the clock signal is embedded with the data through the use of industry-standard 8b10b encoding.
The D- and M-PHY are expected to co-exist for multiple years because the D-PHY is a less complex technology while the M-PHY provides higher bandwidths despite using fewer signal wires.
PHY Adapter Layer (L1.5)
The main feature provided by L1.5 is to allow the UniPro bandwidth to be scaled by using multiple PHY lanes. This increases the bandwidth up to four times. Applications that mainly require bandwidth in one direction but require modest bandwidth in the opposite direction, can have multiple lanes in one direction and a single lane in the other direction.
Architecturally, the PHY Adapter layer also serves to hide the differences between the alternative PHY technologies (D- and M-PHY). This abstraction thus mainly gives architectural flexibility. Abstracted PHY details include the various power states and employed symbol encoding schemes.
| ctl | b15 | b14 | b13 | b12 | b11 | b10 | b09 | b08 | b07 | b06 | b05 | b04 | b03 | b02 | b01 | b00 |
| 1 | 1st byte of L1.5 payload (control symbol) | 2nd byte of L1.5 payload (control symbol) | ||||||||||||||
| 0 | 1st byte of L1.5 payload (data symbol) | 2nd byte of L1.5 payload (data symbol) | ||||||||||||||
| 0 | 1st byte of L1.5 payload (data symbol) | 2nd byte of L1.5 payload (data symbol) | ||||||||||||||
| 0 | 1st byte of L1.5 payload (data symbol) | 2nd byte of L1.5 payload (data symbol) | ||||||||||||||
| 0 | 1st byte of L1.5 payload (data symbol) | 2nd byte of L1.5 payload (data symbol) | ||||||||||||||
| 1 | 1st byte of L1.5 payload (control symbol) | 2nd byte of L1.5 payload (control symbol) | ||||||||||||||
| 0 | 1st byte of L1.5 payload (data symbol) | 2nd byte of L1.5 payload (data symbol) | ||||||||||||||
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.
| ctl | b15 | b14 | b13 | b12 | b11 | b10 | b09 | b08 | b07 | b06 | b05 | b04 | b03 | b02 | b01 | b00 |
| 1 | Start-of-Frame symbol (header) | |||||||||||||||
| 0 | Frame payload | |||||||||||||||
| 0 | : | |||||||||||||||
| 0 | : | |||||||||||||||
| 0 | Frame payload | |||||||||||||||
| 1 | End of Frame control symbol (trailer) | |||||||||||||||
| 0 | 16-bit checksum | |||||||||||||||
L2 control frames
In addition to data frames which contain user data, L2 also transmits and receives control frames. The control frames can be distinguished from data frames by three bits in the first symbol. There are two types of control frames:
- One ("AFC", 3 symbols) serves to acknowledge successfully received data frames.
- The other ("NAC", 2 symbols) notifies the corresponding transmitter that an incorrect frame has been received.
Note that these L2 control frames are sent autonomously by L2, without any control by higher layers.
| ctl | b15 | b14 | b13 | b12 | b11 | b10 | b09 | b08 | b07 | b06 | b05 | b04 | b03 | b02 | b01 | b00 |
| 1 | Start-of-Frame symbol (header) | |||||||||||||||
| 0 | Control frame payload (AFC only) | |||||||||||||||
| 0 | 16-bit checksum | |||||||||||||||
L2 retransmission
High speed communication at low power levels can lead to occasional errors in the received data. The Data Link layer contains a protocol to automatically acknowledge correctly received data frames (using AFC control frames) and to actively signal any error (using NAC control frames). The latter is usually because a frame with an incorrect checksum was received.
A bandwidth of 1 Gbit/s and a bit-error rate of 10-12 would imply an error every 1000 seconds of use. Layer 2 thus, automatically corrects these infrequent events at the cost of marginal loss of bandwidth and at the cost of buffer space needed to "replay" data packets in case of errors.
L2 flow control
Another feature of L2 is the ability for an L2 transmitter to know whether there is buffer space for the frame at the receiving end. This again relies on L2 control frames (AFC) which allow a receiver to tell the connected transmitter how much buffer space is available. This allows the receiver to slow down the transmitter, thus avoiding buffer overflow. The link-level retransmission and link-level flow control together imply that any transmitted UniPro packet is guaranteed to reach its final destination (unlike the TCP/IP protocol stack which detects and corrects errors at the endpoints rather than per hop in the network).
L2 traffic classes and arbitration
UniPro currently supports two priority levels for frames called Traffic Class 0 (TC0) and Traffic Class 1 (TC1). TC1 has higher priority than TC0. This means that if an L2 transmitter has a mix of TC0 and TC1 frames to send, the TC1 frames will be sent first. Assuming that most data traffic uses TC0 and that the network has congestion, this helps ensure that TC1 frames arrive at their destination faster than TC0 frames (analogous to emergency vehicles and normal road traffic). Furthermore, L2 can even interrupt or "preempt" an outgoing TC0 frame to transmit a TC1 frame. Similar rules applies to control frames - these have even higher priority than TC1 traffic.
In a multi-hop network, the arbitration is done by every L2 transmitter at every hop. The traffic class assigned to data does not change as data progresses through the network. It is up to the applications to decide how to use the priority system.
Network Layer (L3)
The network layer is responsible for routing packets through the network toward their destination. Switches within a multi-hop network use this address to decide in which direction to route individual packets. To enable this, a header containing a one-byte destination address is added by L3 to all L2 data frames. In the example shown in the figure, this allows UniPro Device 3 to not only communicate with UniPro Device 1, 2 and 5, but also enables it to communicate with Devices 4 and 6.
In principle, any of the UniPro devices can take the initiative to communicate with any of the other devices. This lack of a master/slave distinction in UniPro is thus similar to a TCP/IP network where all computers are peers as far as TCP/IP protocols are concerned. This differs from USB or PCI Express in which a central master needs to initiate communication. This allows UniPro to scale from a centralized environment with passive peripherals to more distributed architectures with smarter peripherals.
L3 addressing
Although the role of the L3 address is the same as the IP address in packets on the Internet, a UniPro DeviceID address is only 7 bit long, thus limiting networks to a maximum of 128 different UniPro devices. Note that, as far as UniPro is concerned, all UniPro devices are created equal: unlike PCI Express or USB, any device can take the initiative to communicate with any other device. This makes UniPro a true network rather than a bus with one master.
| ctl | b15 | b14 | b13 | b12 | b11 | b10 | b09 | b08 | b07 | b06 | b05 | b04 | b03 | b02 | b01 | b00 |
| 1 | Start-of-Frame symbol (header) | |||||||||||||||
| 0 | L3 header with L3 destination address | Packet payload | ||||||||||||||
| 0 | Packet payload | |||||||||||||||
| 0 | : | |||||||||||||||
| 0 | Packet payload | |||||||||||||||
| 1 | End of Frame control symbol (trailer) | |||||||||||||||
| 0 | 16-bit checksum | |||||||||||||||
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 UniPro 2.0)
- 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.
| ctl | b15 | b14 | b13 | b12 | b11 | b10 | b09 | b08 | b07 | b06 | b05 | b04 | b03 | b02 | b01 | b00 |
| 1 | Start-of-Frame symbol (header) | |||||||||||||||
| 0 | L3 header with L3 destination address | L4 header with L4 destination address | ||||||||||||||
| 0 | Segment payload | |||||||||||||||
| 0 | : | |||||||||||||||
| 0 | Segment payload | |||||||||||||||
| 1 | End of Frame control symbol (trailer) | |||||||||||||||
| 0 | 16-bit checksum | |||||||||||||||
L4 connection 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.