Revision as of 21:03, 28 March 2009 edit BeenAroundAWhile (talk \| contribs) Extended confirmed users 103,575 edits Removing advice. ← Previous edit		Revision as of 21:33, 28 March 2009 edit undo SmackBot (talk \| contribs) 3,734,324 edits m Date maintenance tags and general fixes Next edit →
Line 1: {{Expert-verify\|date=March 2009}} In mobile-telephone technology, the''' [[UniPro]]<ref name="UniPro1.0">[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</ref> protocol stack''' follows the architecture of the classical [[~~OSI_model~~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/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</ref> in other [[~~Mobile_Industry_Processor_Interface~~Mobile Industry Processor Interface\|MIPI Alliance]] specifications. {\| border="1" cellpadding="3" style="margin: 1em auto 1em auto" Line 43: ==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]]<ref>[https://members.mipi.org/mipi-adopters/file/Specifications/Board%20Approved/MIPI%20D-PHY%20Specification_v00-90-00_final_11152007132023.pdf MIPI D-PHY 0.90 specification],requires an account at the MIPI website</ref> 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. Line 76 ⟶ 75: ===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 [[8B/~~10B_encoding~~10B encoding\|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. Line 88 ⟶ 87: {\| border="1" cellpadding="3" style="margin: 1em auto 1em auto" \|+ ''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 \| colspan="8" \| 1st byte of L1.5 payload (control symbol) \| colspan="8" \| 2nd byte of L1.5 payload (control symbol) \|- style="background:#F8F8F8; color:black" align="center" \| style="background:#FF1804; color:white" \| 0 \| colspan="8" \| 1st byte of L1.5 payload (data symbol) \| colspan="8" \| 2nd byte of L1.5 payload (data symbol) \|- style="background:#F8F8F8; color:black" align="center" \| style="background:#FF1804; color:white" \| 0 \| colspan="8" \| 1st byte of L1.5 payload (data symbol) \| colspan="8" \| 2nd byte of L1.5 payload (data symbol) \|- style="background:#F8F8F8; color:black" align="center" \| style="background:#FF1804; color:white" \| 0 \| colspan="8" \| 1st byte of L1.5 payload (data symbol) \| colspan="8" \| 2nd byte of L1.5 payload (data symbol) \|- style="background:#F8F8F8; color:black" align="center" \| style="background:#FF1804; color:white" \| 0 \| colspan="8" \| 1st byte of L1.5 payload (data symbol) \| colspan="8" \| 2nd byte of L1.5 payload (data symbol) \|- style="background:#F8F8F8; color:black" align="center" \| style="background:#FF1804; color:white" \| 1 \| colspan="8" \| 1st byte of L1.5 payload (control symbol) \| colspan="8" \| 2nd byte of L1.5 payload (control symbol) \|- style="background:#F8F8F8; color:black" align="center" \| style="background:#FF1804; color:white" \| 0 \| colspan="8" \| 1st byte of L1.5 payload (data symbol) \| colspan="8" \| 2nd byte of L1.5 payload (data symbol) \|} Line 143 ⟶ 133: \|- 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 \| colspan="16" \| Start-of-Frame symbol (header) \|- style="background:#F8F8F8; color:black" align="center" \| style="background:#FF1804; color:white" \| 0 \| colspan="16" \| Frame payload \|- style="background:#F8F8F8; color:black" align="center" \| style="background:#FF1804; color:white" \| 0 \| colspan="16" \| : \|- style="background:#F8F8F8; color:black" align="center" \| style="background:#FF1804; color:white" \| 0 \| colspan="16" \| : \|- style="background:#F8F8F8; color:black" align="center" \| style="background:#FF1804; color:white" \| 0 \| colspan="16" \| Frame payload \|- style="background:#FF9400; color:black" align="center" \| style="background:#FF1804; color:white" \| 1 \| colspan="16" \| End of Frame control symbol (trailer) \|- style="background:#FF9400; color:black" align="center" \| style="background:#FF1804; color:white" \| 0 Line 184 ⟶ 167: \|- 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 \| colspan="16" \| Start-of-Frame symbol (header) \|- style="background:#FF9400; color:black" align="center" \| style="background:#FF1804; color:white" \| 0 \| colspan="16" \| Control frame payload (AFC only) \|- style="background:#FF9400; color:black" align="center" \| style="background:#FF1804; color:white" \| 0 Line 212 ⟶ 192: ==Network Layer (L3)== [[Image:~~UniPro_network~~UniPro network.png\|thumb\|Example system architecture showing multiple UniPro devices connected via UniPro switches]] 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. Line 225 ⟶ 205: \|- 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 \| colspan="16" \| Start-of-Frame symbol (header) \|- style="background:#F8F8F8; color:black" align="center" \| style="background:#FF1804; color:white" \| 0 \| colspan="8" style="background:#FAF931" \| L3 header with L3 destination address \| colspan="8" \| Packet payload \|- style="background:#F8F8F8; color:black" align="center" \| style="background:#FF1804; color:white" \| 0 \| colspan="16" \| Packet payload \|- style="background:#F8F8F8; color:black" align="center" \| style="background:#FF1804; color:white" \| 0 \| colspan="16" \| : \|- style="background:#F8F8F8; color:black" align="center" \| style="background:#FF1804; color:white" \| 0 \| colspan="16" \| Packet payload \|- style="background:#FF9400; color:black" align="center" \| style="background:#FF1804; color:white" \| 1 \| colspan="16" \| End of Frame control symbol (trailer) \|- style="background:#FF9400; color:black" align="center" \| style="background:#FF1804; color:white" \| 0 Line 280 ⟶ 253: \|- 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 \| colspan="16" \| Start-of-Frame symbol (header) \|- style="background:#F8F8F8; color:black" align="center" \| style="background:#FF1804; color:white" \| 0 \| colspan="8" style="background:#FAF931" \| L3 header with L3 destination address \| colspan="8" style="background:#C2FA31" \| L4 header with L4 destination address \|- style="background:#F8F8F8; color:black" align="center" \| style="background:#FF1804; color:white" \| 0 \| colspan="16" \| Segment payload \|- style="background:#F8F8F8; color:black" align="center" \| style="background:#FF1804; color:white" \| 0 \| colspan="16" \| : \|- style="background:#F8F8F8; color:black" align="center" \| style="background:#FF1804; color:white" \| 0 \| colspan="16" \| Segment payload \|- style="background:#FF9400; color:black" align="center" \| style="background:#FF1804; color:white" \| 1 \| colspan="16" \| End of Frame control symbol (trailer) \|- style="background:#FF9400; color:black" align="center" \| style="background:#FF1804; color:white" \| 0 Line 316 ⟶ 282: 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 [[~~Transmission_Control_Protocol~~Transmission Control Protocol\|TCP]] protocol, has a similar congestion management feature, although it works very differently. ===L4 and Messages=== Line 328 ⟶ 294: ==See also== * [[UniPro]] * [[~~Mobile_Industry_Processor_Interface~~Mobile Industry Processor Interface\|MIPI Alliance]] [[Category:Embedded systems]]

UniPro protocol stack: Difference between revisions