UniPro protocol stack: Difference between revisions

Revision as of 14:52, 1 April 2011

Latest revision as of 12:33, 30 July 2025

(32 intermediate revisions by 19 users not shown)

Line 1:

{{short description|Interface technology communication architecture}}
{{About|a technical explanation of the architecture of the [[UniPro]]^SM protocol stack|an overview of the protocol stack, its purpose, usage and status|UniPro}}

{{Orphan|date=September 2010}}

In mobile-telephone technology, the ''' [[UniPro]] protocol stack'''<ref name="UniPro1.1">[https://members.mipi.org/mipi-adopters/file-fix/Specifications/Board%20Approved/mipi_UniPro_Specification_v01-10-01a.pdf MIPI Alliance Specification for Unified Protocol (UniPro^SM) v1.10.01 ], requires an account at the MIPI website</ref> protocol stack''' follows the architecture of the classical [[OSI model|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<ref>[http://www.mipi.org/specifications Overview of MIPI specifications], D-PHY is used in the DSI, CSI, and UniPro specifications, M-PHY is used in the UniPro, DigRFv4 and LLI specifications</ref> in other [[Mobile Industry Processor Interface|MIPI Alliance]] specifications.

{| border="1" cellpadding="3" style="margin: 1em auto 1em auto"

|+ ''UniPro protocol stack (this color -coding is a long-standing UniPro tradition)''

|- style="background:#D8D8D8; color:black"

! colspan="2" | Layer # || Layer name || Functionality || Data unit name

Line 47:

==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. Data rates of the D-PHY are variable, but are in the range of 500-1000 &nbsp;Mbit/s (lower speeds are supported, but at decreased power efficiency). The D-PHY was named after the Roman number for 500 ("D").

The [[D-PHY]]<ref>[https://members.mipi.org/mipi-adopters/file-fix/Specifications/Board%20Approved/mipi_D-PHY_specification_v01-00-00.pdf MIPI Alliance Specification for D-PHY v1.00.00] {{Webarchive|url=https://web.archive.org/web/20110727084541/https://members.mipi.org/mipi-adopters/file-fix/Specifications/Board%20Approved/mipi_D-PHY_specification_v01-00-00.pdf |date=2011-07-27 }}, requires an account at the MIPI website</ref> uses differential signaling to convey PHY symbols over micro-stripline wiring. A second differential signal pair is used to transmit the associated clock signal from the source to the destination. The D-PHY technology thus uses a total of 2 clock wires per direction plus 2 signal wires per lane and per direction. For example, a D-PHY might use 2 wires for the clock and 4 wires (2 lanes) for the data in the forward direction, but 2 wires for the clock and 6 wires (3 lanes) for the data in the reverse direction. Data traffic in the forward and reverse directions are totally independent at this level of the protocol stack.

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: a PHY implementation running with a 450&nbsp;MHz clock frequency is often rated as a 900 &nbsp;Mbit/s PHY, while only 800 &nbsp;Mbit/s is then available for the UniPro stack.

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.

==={{Anchor|M-PHY}}M-PHY===

Versions 1.4 and beyond of UniPro support both the [[D-PHY]] as well as [[M-PHY]]<ref>[https://members.mipi.org/mipi-adopters/file-fix/Specifications/VotingBoard%20Draft20Approved/mipi_M-PHY_specification_v0PHY_specification_v1-9000-00_r0-0500.pdf MIPI Draft Specification for M-PHY version 01.9000.00] r0{{Webarchive|url=https://web.05]archive.org/web/20111007190626/https://members.mipi.org/mipi-adopters/file-fix/Specifications/Board%20Approved/mipi_M-PHY_specification_v1-00-00.pdf |date=2011-10-07 }}, requires an account at the MIPI website</ref> technology. The M-PHY technology is still in draft status, but supports high-speed data rates starting at about 1000 &nbsp;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 [[8B/10B encoding|8b10b encoding]]. Again, a PHY capable of transmitting user data at 1000 &nbsp;Mbit/s is typically specified as being in 1250 &nbsp;Mbit/s mode due to the 8b10b encoding.

{| border="1" cellpadding="3" style="margin: 1em auto 1em auto"

|+ ''Physical layer technologies supported by UniPro''

|- style="background:#D8D8D8; color:black"

! PHY technology || Version / Released || Symbol encoding || MbitGbit/s (payload) || Signal wireslanes || Supported in

|- style="background:#FF1804; color:white"

| align="center" | D-PHY

| align="center" | 1.00.00 2/September 14-May-20092014

| align="center" | 8b/9b

| align="center" | up4.5 to circa 900Gbit/s/lane

| align="center" | 4 perlane directionport

| align="center" | UniPro 0.80 and up

|- style="background:#FF1804; color:white"

| align="center" | M-PHY

| align="center" | 3.1.00.00 /June Under adoption process 2014

| align="center" | 8b/10b

| align="center" | 100011.6 and higherGbit/s/lane

| align="center" | 24+1 perlane directionport

| align="center" | UniPro 1.40 and up

|- style="background:#FF1804; color:white"

| align="center" | C-PHY

| align="center" | 1.00.00 / October 2014

| align="center" |

| align="center" | ? 2.5Gbit/s/lane ?

| align="center" | 3 lane port

| align="center" |

|}

The D- and M-PHY are expected to co-exist for several years because the. D-PHY is a less complex technology while the, M-PHY provides higher bandwidths with fewer signal wires, and C-PHY provides low-power.

===Low speed modes and power savings===

It is worth noting that UniPro supports the power efficient low speed communication modes provided by both the D-PHY (10 &nbsp;Mbit/s) and M-PHY (3 &nbsp;Mbit/sec uptoup 500to 500&nbsp;Mbit/s). In these modes, power consumption roughly scales with the amount of data that is sent.

Furthermore, both PHY technologies provide additional power saving modes because they were optimized for use in battery-powered devices.

==PHY Adapter Layer (L1.5)==

Line 94 ⟶ 102:

|+ ''Example sequence of a UniPro's 17-bit L1.5 symbols''

|- style="background:#D8D8D8; color:black"

| align="center background:#FF1804;" | ctl || b15 || b14 || b13 || b12 || b11 || b10 || b09 || b08 || b07 || b06 || b05 || b04 || b03 || b02 || b01 || b00

|- style="background:#F8F8F8; color:black" align="center"

| style="background:#FF1804; color:white" | 1

Line 156 ⟶ 164:

|+ ''Example UniPro Data Frame''

|- style="background:#D8D8D8; color:black"

| align="center background:#FF1804;" | ctl || b15 || b14 || b13 || b12 || b11 || b10 || b09 || b08 || b07 || b06 || b05 || b04 || b03 || b02 || b01 || b00

|- style="background:#FF9400; color:black" align="center"

| style="background:#FF1804; color:white" | 1

Line 183 ⟶ 191:

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 type ("AFC- Acknowledgement and L2 Flow Control", 3 symbols) serves to acknowledge successfully received data frames.

* The other type ("NAC", 2 symbols) notifies the corresponding transmitter that an incorrect frame has been received.

Note that these L2 types of control frames are sent autonomously by L2.

Line 190 ⟶ 198:

|+ ''Example UniPro Control Frame''

|- style="background:#D8D8D8; color:black"

| align="center background:#FF1804;" | ctl || b15 || b14 || b13 || b12 || b11 || b10 || b09 || b08 || b07 || b06 || b05 || b04 || b03 || b02 || b01 || b00

|- style="background:#FF9400; color:black" align="center"

| style="background:#FF1804; color:white" | 1

Line 205 ⟶ 213:

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 errors that can be detected at L2 (using NAC control frames). The most likely cause of an error at L2 is that a data frame was corrupted at the electrical level (noise, EMI). This results in an incorrect data or control frame checksum at the receiver side and will lead to its automatic retransmission. Note that data frames are acknowledged (AFC) or negatively acknowledged (NAC). Corrupt control frames are detected by timers that monitor expected or required responses.

A bandwidth of 1 &nbsp;Gbit/s and a bit-error rate of 10⁻¹² at a speed of 1 gigabit/s would imply an error every 1000 seconds or once veryevery 10001000th transmitted Gbit. Layer 2 thus automatically corrects these errors at the cost of marginal loss of bandwidth and at the cost of buffer space needed in L2 to store copies of transmitted data frames for possible retransmission or "replay".

===L2 flow control===

Line 230 ⟶ 238:

[[Image:UniPro network.png|500px|thumb|Example system architecture showing multiple UniPro devices connected via UniPro switches]]

The network layer is intended to route 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 7-bit destination address is added by L3 to all L2 data frames. In the example shown in the figure, this allows Device #3 to not only communicate with Device #1, #2 and #5, but also enables it to communicate with Devices #4 and #6.

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.

Line 242 ⟶ 250:

===L3 short-header packet structure===

UniPro short-header packets use a single header byte for L3 information. It includes the 7-bit L3 destination address. The remaining bit indicates the short-header packet format. For short-header packets, the L3 source address is not included in the header because it is assumed that the two communicating devices have exchanged such information beforehand ([[Connection-oriented|connection-oriented communication]] communication).

{| border="1" cellpadding="3" style="margin: 1em auto 1em auto"

|+ ''UniPro Short-Header Packet within a Data Frame''

|- style="background:#D8D8D8; color:black"

| align="center background:#FF1804;" | ctl || b15 || b14 || b13 || b12 || b11 || b10 || b09 || b08 || b07 || b06 || b05 || b04 || b03 || b02 || b01 || b00

|- style="background:#FF9400; color:black" align="center"

| style="background:#FF1804; color:white" | 1

Line 288 ⟶ 296:

UniPro's Transport layer can be seen as providing an extra level of addressing within a UniPro device. This

* allows a UniPro device to communicate with another UniPro device using multiple logical data streams (example: sending audio and video and control information separately).

* allows a UniPro device to simultaneously connect to multiple other devices (this requires switches as supported in a [[UniPro#Versions_and_roadmapVersions and roadmap|future version of UniPro]]) using multiple logical data streams.

* provides mechanisms to reduce the risk of congestion on the network.

* provides a mechanism to structure a stream of bytes as a stream of messages.

Line 296 ⟶ 304:

An L4 segment, is essentially the payload of an L3 packet. The L4 header, in its short form, consists of just a single byte.

The main field in the short L4 header is a 5-bit "CPort" identifier which can be seen as a subaddresssub-address within a UniPro device and is somewhat analogous to the [[TCP and UDP port|port]] numbers used in [[Transmission Control Protocol|TCP]] or [[User Datagram Protocol|UDP]]. Thus every segment (with a short header) is addressed to a specific CPort of specific UniPro device.

{| border="1" cellpadding="3" style="margin: 1em auto 1em auto"

|+ ''UniPro Segment within a Data Frame''

|- style="background:#D8D8D8; color:black"

| align="center background:#FF1804;" | ctl || b15 || b14 || b13 || b12 || b11 || b10 || b09 || b08 || b07 || b06 || b05 || b04 || b03 || b02 || b01 || b00

|- style="background:#FF9400; color:black" align="center"

| style="background:#FF1804; color:white" | 1

Line 326 ⟶ 334:

|}

A single bit in the segment header also allows segments to be defined with long segment headers. UniPro v1.14 does not define the structure of such segment formats (except for this single bit). Long header segments may be generated via the long header trap described in the L3 section.

===L4 connections===

UniPro calls a pair of CPorts that communicate with each other a connectionConnection (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. Because UniPro connections are bidirectional, the destination CPort is also configured to allow data to be sent back to the source CPort.

In UniPro 1.0/1.1 connection setup is implementation specific.

In UniPro 1.0/1.1 connection setup is assumed to be relatively static: the settings of the paired CPorts in somehow made to match (e.g. hardcoded in firmware within both devices or communicated by proprietary means). This will be replaced by a conventional (dynamic) connection management protocol in a future version of UniPro.

In UniPro 1v1.0/1.14 connection setup is assumed to be relatively static: the settingsparameters of the paired CPorts inare somehowconfigured madeby tosetting matchthe (e.g.corresponding connection hardcodedAttributes in firmwarethe local withinand bothpeer devices orusing communicated by proprietarythe means)DME. This will be replacedsupplemented by a conventional (dynamic) connection management protocol in a future version of UniPro.

===L4 flow control===

CPorts also contain variables (state) variables that can be used to track how much buffer space the peer or connected CPort has. This is used to prevent the situation whereby a CPort sends segments to a CPort which has insufficient buffer space to hold the data, thus leading to stalled data traffic. 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. The described L4 mechanism is known as end-to-end flow control (E2E FC) because it involves the endpoints of a connection.

===L4 flow control versus L2 flow control===

Line 349 ⟶ 359:

UniPro needs to be told by the application where or when to insert message boundaries into the byte stream: the boundaries have no special meaning for UniPro itself and are provided as a service to build higher-layer protocols on top of UniPro. Messages can be used to indicate (e.g. via an interrupt) to the application that a unit of data is complete and can thus be processed. Messages can also be useful as a robust and efficient mechanism to implement resynchronization points in some applications.

UniPro v1.4 introduces the notion of message fragment, a fragment being a portion of a message passed between the application and the CPort. This option can be useful when specifying Applications on top of UniPro that need to interrupt the Message creation based on information from the UniPro stack, e.g., incoming Messages, or backpressure.

===L4 guarantees===

Line 358 ⟶ 370:

* It is safe for an application-level protocol to wait for a peer's response (e.g. an answer or acknowledgement) to a sent L4 message (e.g. a question or command). But it is unsafe for an application-level protocol to await a peer's response to a sent partial message.

* The content of received short header packets/segments will always be correct. Although delivery at the long-header trap interface is not guaranteed, a future protocol extension plans to make the delivery of such packets reliable. This protocol extension could be implemented in software on top of the long-header trap.

==Device Management Entity (DME)==

The DME (Device Management Entity) controls the layers in the UniPro stack. 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. Furthermore, it provides means to control the peer UniPro stack on the Link.

==References==

{{reflist}}

==See also==

* [[UniPro]]

* [[Mobile Industry Processor Interface|MIPI Alliance]]

{{DEFAULTSORT:Unipro Protocol Stack}}