RESONETZ LINK TECHNOLOGY

NETWORK LAYER TECHNOLOGIES

THE NETWORK LAYER SYSTEM

THE 7-LAYER OSI Model *

OSI Layer Model

LAYER 1

“Copper. Fiber. Wireless”

Layer 1

The Physical Layer defines the fundamental network hardware connectivity.

It provides the hardware interface for the logical data structures of the higher network levels and specifies the basic networking transmission technologies, e. g. electrical connectors, optical fibers, broadcast frequencies, transmission modes (Simplex, Duplex ...).

LAYER 2

“Ethernet”

Layer 2

The Data Link Layer parses addresses from the stream, to find the traffic intented for itself.

It can deliver data between devices in the same local network, but canot extend beyond a LAN. Connecting to other LANs or WANs, including the internet, requires a router and the addition of Layer 3 capabilities to the transmission protocol.

LAYER 3

“IP”

Layer 3

The Network Layer routes data packets to/from the destination, specified by an unique network (IP) address.

In doing this, it defines the basic function principle of a network, the connectionless communication. Data packets can travel from sender to recipient without the recipient having to send an acknowledgement. **

* The Open System Interconnection (OSI) model is a concept to describe the internal functions of the complex network communication system by separating it into layers. The abstract scheme groups similar communication functions into one of seven logical layers. A layer serves the layer above and is served by the layer below. Layers don´t “communicate” with other layers.

** IP adress: Every host in the network must have an unique address that determines where it is, so the packets find the way through the network to the recipient.

NETWORK LAYERS IN REAL APPLICATIONS

AUDIO-OVER-NETWORK PROTOCOLS

LAYER 1

Protocols in this category using simply Ethernet wiring and some network components. They canot use the frame structure of local area networks (LANs) or the internet. Most are simple point-to-point audio interconnections.

PROTOCOLS

Open: AES50/SuperMac, AES-X213 (MADI w. CAT5)
Proprietary: A-Net, M11, RockNet (Riedel), ZIPI

Layer 1 Example

LAYER 2

Audio data will be encapsulated in standard Ethernet packets and can use local network infrastructures, including “flat” hubs/ switches, but canot use routers and cross out of the LAN. Some audio protocols need a dedicated audio network structure.

PROTOCOLS

Open: AES51, AVB (IEEE 1722 - Ethernet-only)
Proprietary: SoundGrid (Waves), CobraNet, EtherSound (Digigram/Yamaha), NetCira

Layer 2 Example

LAYER 3

Audio data in network layer 3 packets allow the transmission to cross the router border, become streaming media and use the most popular layer 3 protocol, the Internet Protocol (IP - v4/6), but not necessarily WANs or the internet itself.

PROTOCOLS

Open: Ravenna, AES67 (Interoperability standard)
Proprietary: Dante, LiveWire, Q-LAN, RESONETZ

Layer 3 Example

LAYER 4 ADDITIONS: REALTIME. SYNC. CONTROL.

Layer 4

In most Layer 3 protocols the audio data will be further packed into layer 4 transport packets UDP and RTP (Realtime Transport Protocol). Protocols are further using additions, like Realtime Transport Control Protocol (RTCP) and PTP-Synchronization (Precision Time Protocol) to achieve stream control and time synchronization.

This allows them to use standard network hardware, like routers, and even the internet itself. Error & flow control, retransmission and sequenced delivery will be possible.

COMPARISON: MADI vs. IP AUDIO NETWORK

READ ON

MADI-BASED AUDIO NETWORK

“Smart” network - “dumb” end points.

The network controls and routes the traffic via "star" routers.

  • One cable for one signal path.
  • The system structure is pre-defined. Difficult to enhance. Limited flexibility.
  • Needs special "smart" MADI router hardware for audio distribution (“Kreuzschiene”).
  • Advantage: Lowest latency.
  • Advantage: Unmatched reliability.

AUDIO IN AN IP NETWORK

“Dumb” network - “smart” end points.

The nodes control and route the traffic via packet addresses.

  • Cables can be used universally for all kind of IP traffic (Audio, Video, Mail, Data downloads ...).
  • Free growable and decentralized structure. Unmatched flexibility.
  • Most protocols work with low-cost, off-the-shelf hardware (cables, switches, routers).
  • Higher latency (5 network switches add around 1 ms delay).
  • Limited reliability (packets can get lost).

CREATING A STREAM

DIGITAL MEDIA DATA - CONVERTED TO PACKETS.

May the packet be with you.

Network media means streaming media. Time synchronized audio signals become a stream of countless small packets, which travels over network hardware to their supposed destination(s).

Audio and control data (GPI/O, MIDI) will be "packetized" by the RESONETZ device. Every "sliced" part will be enclosed into a combined IP/UDP and RTP packet and send via the netowork port to the destination, specified by the header of the packet.

The receiving device unpacks the "delivery" and combines the "sliced" parts to source-identical audio and control data. Packets become MADI, Analog, AES/EBU or MIDI again.

REALTIME PACKET DISTRIBUTION WITH RESONETZ LINK

1. UDP: EFFICIENT TRANSMISSIONS

RESONETZ utilizes the common USER DATAGRAM PROTOCOL (UDP) for packet distribution. UDP is a member of the Layer 4 transport protocol suite (see above). It’s supported by any off-the-shelf network hardware. It provides a very simple, but highly efficient transmission solution for UNICAST and MULTICAST transmissions and works on top of the underlying IP layer.

UDP Packets were just sent to their destination, without error checking, without arriving acknowledgments, congestion control or an included re-transmission system for lost packets. This way UDP packets travel independently of previous or future packets in a data stream.

The lacking reliability mechanisms look like a flaw, but provide a decisive advantage: UDP avoids the inevitable overhead processing of other Layer 4 protocols like TCP/IP (see below).

With it’s “fire and forget” principle UDP enables a time-sensitive delivery and makes realtime streaming possible. In case of audio streaming, dropping some packets on the way is favorable than waiting for delayed packets. The tasks for a reliable communication could be better featured by smart applications on the end points.

RESONETZ LINK provides sophisticated end-point technologies, like Realtime Network Condition Monitoring via RTCP and Forward Error Correction (FEC) on top of UDP to deal with “dropped” packets and maintain the playback order. It’s integrated hardware logic decouples the communication from the networking limits and problems. RESONETZ LINK delivers an impressive Audio-over-IP reliability with realtime streaming and a strong robustness against packet loss.

UDP IN THE ENCAPSULATED STRUCTURE OF A RESONETZ PACKET:

UDP Packet

UDP PACKET HEADER

The small UDP header displays the limits of the protocol. It adds two services to the packets, which are not provided by the underlying IP layer: Port numbers to adress different requests at the sender/receiver and an optionally checksum for data integrity verification.

UDP Packet Header

2. RTP. THE "SMART" ADDITION.

With the Realtime Transport Protocol (RTP) RESONETZ integrates the primary standard for audio/video IP streaming solutions and enhances it with innovative features.

RTP is a flexible transfer addition to lower layer network protocols. RTP runs on top of RESONETZ’s UDP solution and extends it with reliability features, high-resolution timing sync and the capability to transport media content (payload).

Thanks to RTP every RESONETZ packet will be equipped with time stamp, sequence number for source-orderly recreation, prioritization info and finally - the audio payload.

A special RESONETZ HARDWARE RTP CORE (FPGA design) provides intelligent, network-aware applications on both end points of the stream - capable of reacting to problems introduced by the unreliable network in between. The HRTP CORE encodes media data and assembles them in RTP packets with appropriate timestamps and increasing sequence numbers. The receiving RESONETZ HRTP core captures the packet stream, detects missing packets, reorders out-of-sync packets and decodes the payload data. Finally it hands over the orderly recreated audio stream to the hardware outputs of the device (e. g. MADI, AES/EBU, Analog, MIDI, GP I/O).

PACKET ADDITIONS VIA RTP:

UDP Packet

The RTP data is encapsulated in several packet layers. The outer shell is formed by an ethernet packet, to transport the packet over the ethernet. The payload of the ethernet packet consists of an IP packet used to travel across routers and sending data over the internet. The payload of the IP frame contains the UDP packet. Finally, the data portion of the UDP packet holds the RTP packet with it’s header and the payload.

The RESONETZ LINK RTP payload can be filled with a wide range of chunks of media formats, like uncompressed linear audio samples.

E. g. the RESONETZ ETHERMADI-64 "packetizes" the professional MADI format with up to 24 Bit and 192 kHz.

The payload size of a RESONETZ packet can vary between different audio sample sizes. The size of the payload defines how much packets are needed to transmits a the same amount of audio. A smaller encapsulated chunk of data results in more packets and decreases the network efficiency, as much more protocol data have to be processed.

On the other hand smaller packets reduce the latency and the impact of a missing packet, as the loss of a few audio samples is often tolerable.

In the end the RTP payload size (= packet size) as the best compromise between packetization delay and protocol overhead is automatically chosen.

RTP in the encapsulated structure of a RESONETZ packet:

UDP Packet

* RTP HEADER: V (Version no.), P (Padding bit), Extension bit (X), M (Marker bit), PT (Payload type).

EXCURSION: RTP AND RTCP - REALTIME TRANSPORT AND CONTROL.

READ ON

RTP is not a full-scale Layer 4 transport protocol but works like an extension to transport protocols (TCP, UDP). It’s often viewed as a sub-layer of the transport layer. RTP runs on end systems. With the help of the Realtime Control Protocol (RTCP) it provides the necessary hooks for adding intelligent reliability features and flow/congestion control to the “dumb” network in between.

As end-to-end solution RTP usually canot ensure realtime delivery, but provides key functionality for carrying realtime content, e.g. timestamps, sequence numbers and control mechanisms for synchronizing different streams with timing properties. RTP does not define any mechanisms for recovering of lost packets. For audio transmission Forward Error Correction (adding redundant data) is used.

While RTP carries the media streams (e.g. audio and video), RTCP is used to monitor transmission statistics and quality of service (QoS). In giving a feedback on the performance of the application and the network.

RTCP provides statistics on quality aspects of the media distribution and transmits the gathered data to the source and other receivers. RTCP packets do not encapsulate chunks of audio and were sent periodically with the sender and/or receiver statistic reports. The exchanged information will be be used for diagnostics, adaptive efforts (packet size) and the detection of transmission errors. Including the number of packets sent, the number of lost packets and information about interarrival jitter.

NETWORK CONTROL

RESONETZ LINK realtime with UDP and RTP:
Fast network transmission with smart end-points.

Smart End Points

HIGH RESOLUTION SYNCHRONIZATION

RESONETZ LINK provides highly accurate clock synchronization for all nodes in a LAN based on the PRECISION TIME PROTOCOL (PTP Version 2).

Audio streams and playback, as well as the word clock of all RESONETZ nodes can be tightly synchronized throughout the whole network. The seamless word clock distribution, easily achieving the AES11 accuracy specifications, avoids a seperate clock link between every node via an extensive copper cable network spanning the whole building.

With PTPv2 supporting network switches in a LAN RESONETZ nodes provide phase accuracy precision - the clock precision is within a few nanoseconds.

Without PTP supported network hardware in a LAN and even in WANs and the Internet RESONETZ provides sample accurate synchronization across all linked nodes (e.g. with local master devices synced to a highly accurate timebase, like GPS).

RESONETZ LAN NODE synchronization process via PTP packets:

UDP Packet

Pro audio synchronization within the boundaries of an IP network is a complex task and differs from traditional audio clock solutions. In point-to-point connected digital audio systems - via Word Clock, AES/EBU or MADI cables - the synchronization takes place with the transmission of the signal’s sampling rate - one sound sample stands also for a sync point.

In a packet-based networks with the rules of Ethernet and IP the synchronisation process has to take place with high-frequency packet exchanges. Like any other packet, clock synchronisation packets are also delayed on the network path.

In RESONETZ’s PTP solution the master device sends synchronization packets with timestamps to all slave clocks, providing them with a high-precision tracking of the master clock.

With exchanged exchanged sync/delay messages, up to 10 times per second the slave clocks in the linked RESONETZ nodes are able to identify and compensate the timing differences, introduced by the network, e. g.:

  • Network stack jitter delays (packet processing)
  • The latency between master and slave.
  • Jitter in network elements (repeaters, switches, routers). *

* Network switches and repeaters introduce usually no countable jitter. This can change if the hardware is a state of high load or even overloaded. Delay jitter of up to one millisecond can occur, depending of the lenght and number of buffered packets.

CLOCK DISTRIBUTION IN HARDWARE

As usual with all pro audio digital hardware, quality, resolution and stability of the local clock are essential for an exceptional performance.

RESONETZ devices implement the clock synchronization directly in the main hardware core. Together with the timestamp unit and the whole packetization process, all relevant processing has been converted into hardware.

The FPGA-based zero-latency processing does not introduce any relevant delays and qualifies the solution for accuracies in the lower nanosecond range.

Thanks to the various clock sources of the RESONETZ devices external hardware can be synced easily throughout a whole LAN/WAN.

This way RESONETZ nodes can work as a highly stable and flexible clock distribution system for large broadcast facility LANs and beyond - spanning even globally connected WANs.

PTP V2 - THE Precision Time Protocol

READ ON

PTP (IEEE-1588-2008 = PPT Version 2) is a standardized protocol used to synchronize the clocks of connected devices within a computer network. It is supported in local and wide area networks, including the internet. PTP provides sub-microsecond synchronization over long distances with standard cabling. All available clocks in a PTP sync array are organized into a master-slave hierarchy, based on IP Multicast communication.

The network will choose the most accurate clock automatically as “grand” master - based on International Atomic Time, available as radio time or via GPS.

Every master in a system of nodes synchronizes itself to the grand master. Each slave synchronizes to its master, based on high-frequency packet exchanges, measuring the delay, up to 10 times per second. This way processing jitter, fluctuations and wait times in switches were effectively compensated.

The resulting accuracy in the sub-microsecond range - even in larger networks - makes PTP not only suitable for financial applications, measurement and control systems, but the first choice for professional audio as well.

PTP measures the run times in the networkand measures the clocks accordingly. The network timing delay depends on several reasons, like switch perfomance and the bandwidth. On 100 Mbps networks the delay of packet queuing is significant higher, than on a Gigabit network.

READ ON: RESONETZ LINK. APPLICATION EXAMPLES.