Design Article
New transmission mechanisms for MOST enable powerful video applications
Juergen Baumgartner
9/10/2009 11:38 AM EDT
The de-facto standard, now established in all areas requiring networked infotainment components, is MOST (Media Oriented Systems Transport). The philosophy behind MOST in transferring audio and video data lies in reserving a dedicated channel with the necessary bandwidth. This is the only way to guarantee the highest quality of service (QoS).
Until now, this was available solely to transmission of synchronous data. Under MOST25, for example, an MPEG data stream was artificially "stuffed" with bits, or the stream was converted (transcoded) to a fixed bit rate. Sample rate converters are sometimes used for audio applications to adapt PCM audio data to the MOST frame rate. However, not all audio or video data streams can be simply synchronized to this MOST time base. To support transmission of this type of data in accordance with the MOST philosophy, MOST150 introduced isochronous transfer. Isochronous channels are handled in much the same way as synchronous channels in MOST: the required bandwidth is firmly reserved, which means channels for isochronous data are allocated, and the data is routed as needed.
MOST150 can handle three different isochronous mechanisms designed for different applications.
A/V Packetized Isochronous Streaming
This mechanism permits transfers of video data streams that arrive without any reference to the MOST time frame. The data is already consolidated in small data packets, which can optionally include a time stamp. MPEG data streams that are coded either with variable (VBR) or constant bit rates (CBR) are a typical example of this. A MOST transfer initially reserves the maximum isochronous bandwidth required. The data arriving at the network interface controller (MOST150 INIC) is transferred automatically by INIC to internal memory whose content is transferred cyclically via MOST. The network interface controller of a data sink can copy the isochronous data from the bus to its internal memory, and pass it via a suitable interface on to the external hardware - an MPEG decoder, for example. The whole handling of MPEG data is encapsulated completely in the MOST150 INIC, so that all the application has to do is reserve the required isochronous bandwidth and configure the corresponding connections.
Besides isochronous transfer, additional improvements for transferring video data are featured in the MOST150 INIC. Besides a range of standard interfaces, the network interface controller for the MOST150 includes a Transport Stream Interface (TSI), now an established standard for video chipsets. This enables the direct connection of video chipsets to the MOST150 INIC. Additional hardware (glue logic) is not required. It means, for example, that the DVB-T tuner in a digital TV receiver can be directly connected to the MOST-150 INIC via the TSI interface. Via a second interface, an MPEG encoder for an additional analog tuner can even be connected. Despite the limited number of pins, various predefined layout profiles enable many available interfaces in a 48-pin housing. In addition to a control port, one of these profiles is intended precisely for these two TSI interfaces.
A/V Packetized Isochronous Streaming has the following benefits:
• Generic transmission of MPEG data.
• Highest quality of service.
• Glueless connection to video chipsets, requiring no additional hardware and, as a result, saving costs.
•Connections are handled in the same way as synchronous MOST connections.
Figures 1 and 2 show the isochronous data transmission of MPEG data via one isochronous port/socket per node.
Figure 1: Isochronous data transfer of MPEG data over an isochronous port/socket and the Transport Stream Interface (TSI). To see a bigger version of this graphic click here.
Figure 2: Isochronous data transfer of MPEG data over an isochronous port/socket and TSI or Media Local Bus (MediaLB). To see a bigger version of this graphic click here.
DiscreteFrame Isochronous Streaming
Although audio data streams are synchronous in nature (a constant volume of data per time unit that is dispatched together with a highly accurate clock signal), they are often not synchronized to the same time base as MOST. One example is transfers of PCM audio data, which might have been sampled at a frequency of 44.1 (or 96) kHz, via a MOST150 network operating at a MOST frame rate of 48 kHz. The sample rate used for audio CDs is 44.1 kHz.
Another example is the transfer of an S/PDIF signal (Sony Philips Digital InterFace or Sony Philips Digital Interconnect Format) via MOST. S/PDIF is an interface standard used to interface audio data on decoder chipsets and in general use in the home audio domain, using optical TOSLINK or electric cinch and/or RCA jacks. Home audio equipment usually features components with one or more digital S/PDIF inputs or outputs. The interface is used for unidirectional transfer of PCM audio data according to IEC 60958 or compressed audio data according to IEC 61937 such as DTS, Dolby Digital (AC-3) or THX. S/PDIF is a further audio source ideal for isochronous transfers with MOST.
Using isochronous transfer, these types of data streams can be "tunneled" via MOST, without the need to synchronize them to the MOST frame rate or convert the data with a sample-rate converter. The last can thus be realized centrally in the audio sink in a DSP, for example. For sink devices, a mixing of several source signals, sampled at different sample rates, is frequently required anyway. All in all, this approach can save on sample-rate converters and attendant costs in the system. Plus, there are no quality compromises caused by repeated conversions.
To transfer an audio signal isochronously, it is not enough to simply tunnel the data via MOST. In addition, the time base has to be maintained. This means the time base must be transferred and the sink needs to re-synthesize the clock with high precision.
The MOST150 INIC features inputs for non-MOST clock signals. The incoming signal needs to be sampled and the time base needs to be transferred along with the data. The time base (representing the clock), is restored in the sink after transfer through the network by a dedicated unit in the INIC, and the data is re-output at this clock rate. Thanks to the synchronous nature of MOST, this involves a minimum of overhead. The process of handling this clock tunneling has been completely abstracted for the application via the INIC's API, with all necessary mechanisms encapsulated in the MOST150 INIC. All the application has to do is reserve the required isochronous bandwidth and configure the connections.
DiscreteFrame Isochronous Streaming has the following benefits:
• Transparent transfers of audio data and clock signals not synchronized to MOST.
• Glueless connection to audio codecs and DSPs requiring no additional hardware and, as a result, saving costs.
• Optimized system architecture by reducing sample-rate converters that in turn saves on system costs.
• No potential quality losses caused by superfluous sample-rate converters.
• Minimum overhead (bandwidth efficiency).• Generic transfer of S/PDIF.
• Connections are handled in the same way as synchronous MOST channels.
• Automatic recognition of optical S/PDIF and/or MOST signals for home applications. The unidirectional point-to-point S/PDIF connection permits its use in networks.
Figures 3 and 4 show the isochronous data transfer of audio data via two isochronous ports/sockets, one for data and the other for the time base.
Figure 3. Isochronous data transfer of audio data via two isochronous ports/sockets. Data output and clock recovery via the INIC's streaming port. To see a bigger version of this graphic click here.
Figure 4. Isochronous data transfer of audio data via two isochronous ports/sockets. Data output is via the Media Local Bus (MediaLB), clock recovery through the INIC's streaming port. To see a bigger version of this graphic click here.
QoS IP Streaming
More and more applications in the fast-moving consumer world now use IP-based communication. In the perfect scenario, these applications can be adopted without changes in the in-car multimedia scenery, allowing lower development costs and faster availability on the market.
It can be assumed that IP-based communication will enter the automotive market. Original Ethernet data packets (frames) can be transferred via the MOST150's Ethernet channel. MOST150 INIC also supports MAC addressing for these packets. For users, this type of communication is the same as if it came by Ethernet. All this makes MOST150 the automotive qualified physical layer for Ethernet. TCP/IP stacks and IP-based communication protocols can thus communicate via MOST without modification.
A third isochronous transfer mechanism was designed for IP-based packet data. For data streams requiring a high QoS (e.g. Voice over IP and Video over IP), a private isochronous channel can be used instead of the packet channel. This can be accomplished because MOST150's isochronous mechanism also supports packets.
It works by distributing packets simultaneously via an isochronous channel to one or several nodes in the system. In this way, transfers to several recipients require no additional bandwidth. The data transferred is not forced to share the available bandwidth with other packet data. The other packet data would typically come with a generally low or non-existent QoS, and it would need to be arbitrated simultaneously as the QoS packet data on the classic or Ethernet packet channel.
Here, as with the other isochronous mechanisms, a certain amount of bandwidth is reserved, guaranteeing its availability for data transfers of this type.
QoS IP Streaming has the following advantages:
•Highest QoS for packet data.
• Supports all Ethernet-based protocols and standards.
• Uses standard TCP/IP stacks.
• Point-to-multipoint transfer requiring no additional bandwidth (bandwidth efficiency).
• Transparent transfer of Ethernet frames.
• Complete MAC addressing.
ᾴ No delays by arbitration of packets.
• Fair arbitration of standard Ethernet data packets.
• No collisions or packet loss.
• Efficient use of available bandwidth through early and automatic detection of a full receive buffer.
• MOST is the automotive qualified physical layer for Ethernet.
Figures 5, 6, 7 and 8 show the synchronous and isochronous transfer of audio data in the MOST150 network, the isochronous transfer of video data and transfer of Ethernet data packets and "classic" MOST packet data with and without QoS.
Figure 5. Synchronous transfer of audio data via a MOST150 network. To see a bigger version of this graphic click here.
Figure 6. Isochronous transfer of video and audio data via a MOST150 network To see a bigger version of this graphic click here.
Figure 7.Transfer of Ethernet data packets and "classic" MOST packet data with and without QoS via a MOST150 network. To see a bigger version of this graphic click here.
Figure 8. Synchronous and isochronous transfer of audio data, isochronous transfer of video data, and transfer of Ethernet data packets and "classic" MOST packet data with and without QoS via a MOST150 network. To see a bigger version of this graphic click here.
DTCP
As with MOST25, MOST150 even permits the application to use copy-protected channels to transfer DVD or Blu-ray content, both on synchronous, isochronous and packet-oriented channels. To do this, a technology called DTCP (Digital Transmission Content Protection) is used.
This requires mutual authentication (AKE = Authentication and Key Exchange) from sources and sinks. The multimedia streams must also be encrypted before they are sent from the source device via a digital network. The sink at the other end must be able to decrypt the digital content.
Encryption of audio and/or video data using MOST occurs outside the network interface controller. The reason for this is purely economic: If the modules (hardware and/or software) required for AKE and encryption/decryption were implemented in the network interface controller, every single MOST node would carry the additional cost whether or not it required DTCP. This partitioning makes cost-optimized nodes possible. DTCP solutions for MOST that match the SMSC network interface controllers are available in hardware as well as in software from various suppliers. Furthermore, SMSC also markets INIC companion devices, which include powerful DTCP hardware solutions.
A wise addition
It goes without saying that MOST150 can handle the proven synchronous transmission mechanisms that will still be extensively used. Synchronous and isochronous mechanisms, as well as mechanisms for classic MOST and Ethernet packet data, packet data with QoS, and mechanisms for real-time control, can be used in a MOST150-based system simultaneously and interference-free, and they complement one another. In addition to opening the door to video applications, the new isochronous mechanisms in MOST represent an important enrichment to audio data transfers, enabling new and optimized system architectures.
Since MOST audio and video data can be transferred synchronously and/or isochronously, and thus with practically no overhead (no addressing or collisions, data availability on every node), MOST150 makes a net capacity available that other packet-oriented networks only attain at far higher bandwidths, if at all.
References:
[1] MOST Cooperation website: www.mostcooperation.com
[2] Grzemba, A. (publisher): MOST: The Automotive Multimedia Network. Franzis-Verlag, Poing 2008, ISBN 978-3-7723-5316-1.
Juergen Baumgartner, Dipl.-Ing. (FH), studied communications engineering at the University of Applied Sciences in Karlsruhe. After graduating, he worked in system development where his focus was on real-time emulation of microcontrollers. For the last five years he has been responsible for several product lines at SMSC Europe.



