Content deleted Content added
m →top: Typo fixing, replaced: Iterface → Interface |
|||
| (44 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]] In mobile-telephone technology, the '''
{| border="1" cellpadding="3" style="margin: 1em auto 1em auto"
|+ ''UniPro protocol stack (this color
|- 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
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 MHz clock frequency is often rated as a 900
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/
{| 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 ||
|- style="background:#FF1804; color:white"
| align="center" | D-PHY
| align="center" | 1.
| align="center" | 8b/9b
| align="center" |
| align="center" | 4
| align="center" |
|- style="background:#FF1804; color:white"
| align="center" | M-PHY
| align="center" | 3.1
| align="center" | 8b/10b
| align="center" |
| align="center" |
| align="center" |
|- 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
===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
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;"
|- style="background:#F8F8F8; color:black" align="center"
| style="background:#FF1804; color:white" | 1
Line 134 ⟶ 142:
===L1.5 link power management===
Starting in UniPro v1.4, L1.5 has a built in protocol called PACP (PA Control Protocol) that allows L1.5 to communicate with its peer L1.5 entity at the other end of an M-PHY-based link. Its main usage is to provide a simple and reliable way for a controller at one end of the link to change the power modes of both the forward and reverse directions of the link. This means that a controller situated at one end of the link can change the power mode of both link directions in a single atomic operation. The intricate steps required for doing this in a fully reliable way are handled transparently within L1.5.
===L1.5 peer parameters control===
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.
===L1.5 guarantees===
The mechanisms in L1.5 guarantee the following to upper layer protocols:
* after reset, each L1.5 transmitter will wait until the connected L1.5 receiver is known to be active (handled via a handshake)
* if more than one lane is used, the ordering of the original symbol stream is preserved (despite usage of multiple lanes and freedom on how to interconnect these lanes)
Line 148 ⟶ 159:
L2 clusters 17-bit UniPro L1.5 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.
Note that two or more of the 288 bytes are used by higher layers of the UniPro protocol. The maximum frame size of 288 payload bytes per frame was chosen to ensure that the entire protocol stack could easily transmit 256 bytes of application data in a single chunk. Payloads consisting of odd numbers of bytes are supported by padding the frame to an even number of bytes and inserting a corresponding flag in the trailer.
{| border="1" cellpadding="3" style="margin: 1em auto 1em auto"
|+ ''Example UniPro Data Frame''
|- style="background:#D8D8D8; color:black"
| align="center background:#FF1804;"
|- style="background:#FF9400; color:black" align="center"
| style="background:#FF1804; color:white" | 1
Line 180 ⟶ 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 187 ⟶ 198:
|+ ''Example UniPro Control Frame''
|- style="background:#D8D8D8; color:black"
| align="center background:#FF1804;"
|- style="background:#FF9400; color:black" align="center"
| style="background:#FF1804; color:white" | 1
Line 202 ⟶ 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
===L2 flow control===
Line 220 ⟶ 231:
* a transmitted data frame will reach the peer's receiver (after potential retransmissions)
* there will be room to accommodate received data frames (L2 flow control)
* the content of a data frame will
* data frames within the same Traffic Class will be received and passed to the upper protocol layers in order
Thus individual links autonomously provide reliable data transfer. This is different from, for example, the widely used [[Transmission Control Protocol|TCP protocol]] that detects errors at the endpoints and relies on end-to-end retransmission in case of corrupted or missing data.
Line 227 ⟶ 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.
===L3 addressing===
Line 235 ⟶ 246:
===L3 packets===
The diagram shows an example of 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,
===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 ([[
{| 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;"
|- style="background:#FF9400; color:black" align="center"
| style="background:#FF1804; color:white" | 1
Line 270 ⟶ 281:
===L3 long-header packets===
Long-header packets are intended to be introduced in a future version of the UniPro specification, so their format is undefined (except for one bit) in the current UniPro v1.
===L3 guarantees===
Although details of switches are still out of scope in the UniPro v1.
* that packets will be delivered to the addressed destination device (and packets addressed to non-existent devices are discarded)
* that payload sent by an L3 source to a single L3 destination as a series of one or more short-header packets within a single Traffic Class will arrive in order and with the correct payload (reliability)
==Transport Layer (L4)==
The features of UniPro's Transport layer are not especially complex,
UniPro's L4 also has special significance because it is the top protocol layer in the UniPro specification. 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. This high level of abstraction avoids restricting implementation options. Thus, although the specification contains an annex with a signal-level interface as a non-normative example, a UniPro implementation is not required to have any specific set of hardware signals or software function calls at its topmost interface.
Line 285 ⟶ 295:
===L4 features===
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
* allows a UniPro device to simultaneously connect to multiple other devices (this requires switches as supported in a [[UniPro#
* 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 294 ⟶ 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
{| 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;"
|- style="background:#FF9400; color:black" align="center"
| style="background:#FF1804; color:white" | 1
Line 324 ⟶ 334:
|}
A single bit in the segment header also allows segments to be defined with long segment headers. UniPro v1.
===L4 connections===
UniPro calls a pair of CPorts that communicate with each other a
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
===L4 flow control===
CPorts also contain
===L4 flow control versus L2 flow control===
Line 347 ⟶ 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 356 ⟶ 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}}
{{DEFAULTSORT:Unipro Protocol Stack}}
| |||