Atlona OmniStream AT-OMNI-111 Quick reference guide

Atlona Manuals
OmniStream
AT-OMNI-121
AT-OMNI-122
AT-OMNI-512
AT-OMNI-521 AT-OMNI-232
AT-OMNI-111
AT-OMNI-112
IT Deployment Guide

AT-OMNI-XXX
2
Version Release Date Notes
1 08/17 Initial release
2 11/17 Added language to cover both OmniStream Pro and R-Type
Version Information

AT-OMNI-XXX
3
Network Topologies 4
Single Logical Switch 4
Advantages 4
Disadvantages 4
Star 5
Advantages 5
Disadvantages 5
Fat Tree 6
Advantages 6
Disadvantages 6
Layer Terminology 7
Per Stream Bandwidth Utilization 8
Scrambling 8
Redundancy (OmniStream Pro Only) 8
Video 9
FEC (OmniStream Pro Only) 9
Audio 9
FEC (OmniStream Pro Only) 10
Data 10
Trunk Bandwidth Utilization 11
Unicast vs Multicast Routing 11
Trunk Port Denition 13
Trunk Uplink 13
Trunk Downlink 15
IGMP / Multicast Routing Requirements 16
Multicast Address Assignment 16
IGMP Snooping 16
IGMP Querier 16
Multicast Routing 16
Handling of Unregistered Multicasts 17
Special Notes for networks with Dante (AT-OMNI-232) 17
Multicast DNS (mDNS) 17
Switchport Conguration 17
Jumbo Frames 17
QoS 17
PoE 18
AMS 18
Table of Contents

AT-OMNI-XXX
4
Network Topologies
A network topology is how the various components of a network are arranged. For our purposes, this refers to the
various devices that OmniStream is connected to and how those devices are connected to each other.
Although there are a variety of dierent network topologies, OmniStream will nearly always be connected to one of
three groups: single logical switch, star, or fat tree. Each of these topologies has its own distinct advantages and
disadvantages, which we’ll briey discuss here.
By far, the simplest network topology we will come across is that of a single switch. In this type of system, each
OmniStream device is connected to a single logical switch that is not connected to any other switches/routers.
Note that this type of topology could refer to a single physical switch, or multiple physical switches that are stacked
and act as one logical switch.
Note that this type of topology could refer to a single physical switch, or multiple physical switches that are stacked
and act as one logical switch.
• Simple.
• Easy to manage.
• Limited network impact of video trac.
• Inexpensive.
• Atlona provided conguration les available for some Cisco SG300 SKUs.
• Limited scalability options.
• No network redundancy; single point of failure.
Single Logical Switch
Advantages
Disadvantages

AT-OMNI-XXX
5
Network Topologies
For systems needing more scalability than that oered by a single logical switch, multiple logical switches can be
each connected to a single switch for intercommunication. In this topology, the central switch is referred to as a
“core” switch, with the other switches being referred to as “access” switches. This type of system will typically see
OmniStream connected to the access switches.
• Much more scalable than a single logical switch.
• Multiple access switches can create a level of redundancy.
• Physical network layout can make cabling very expensive, as all access switches must be directly connected to
the core.
• Single core switch creates a single point of failure.
Star
Advantages
Disadvantages
“Core” Switch
“Access” Switch
“Access” Switch
“Access” Switch
“Access” Switch

AT-OMNI-XXX
6
“Core” Switch
“Access” Switch
“Access” Switch
“Access” Switch
“Access” Switch
“Access” Switch
“Access” Switch
Network Topologies
Very large network systems often fall into the category of a fat tree topology. Here, access switches are connected
to a distribution switch in a manner like a star network. Multiple distribution switches are in turn connected to a core
switch. There can be multiple layers of distribution switches, and multiple core switches can be interconnected. Links
further up the tree (closer to core switches) are “fatter”, or higher bandwidth, than links further down the tree (closer
to access switches).
• Ultimate scalability.
• Potential for highly redundant networks.
• Highly complex to manage.
• Very expensive.
Fat Tree
Advantages
Disadvantages

AT-OMNI-XXX
7
Users often refer to switches as a “layer 2 switch” or a “layer 3 switch”, often insisting that a “layer 3 switch” is
necessary for a multicast network to function properly. This statement isn’t always true, but to understand why, the
terms “layer 2 switch” and “layer 3 switch” must be rst understood.
These terms come from the OSI (Open Systems Interconnection) model, which denes how networks communicate
by partitioning the system into layers. In this model, layer 2 refers to the data link layer and layer 3 refers to the
network layer.
As such, a “layer 2 switch” is one that performs switching on the data link layer using MAC addresses. A “layer 3
switch” is one that performs switching on the network link layer using IP addresses.
Another easy way to understand it to relate the layer terminology to a more common vernacular:
• Layer 2 switch = switch.
• Layer 3 switch = switch/router.
Layer Terminology
Network Topologies

AT-OMNI-XXX
8
Per Stream Bandwidth Utilization
To eectively plan a network, it is necessary to understand how bandwidth on that network will be utilized. By rst
understanding how much bandwidth each stream on each switch will utilize, it becomes easy to see how bandwidth
across the system will be utilized.
OmniStream Pro and R-Type products support AES 128 scrambling of their video and audio streams, enabling
protection of content across the IP link.
The bandwidth penalty for using scrambling is negligible and does not noticeably increase the overall bandwidth
utilization of the system.
OmniStream Pro products support redundancy of video and audio streams, allowing for decoders to automatically
detect stream failures and switch to backups.
For encoder bandwidth utilization per port, add the calculated bandwidth utilization for each session congured for
the port in question together.
For decoder bandwidth utilization per port, the calculation must be done dierently depending on the redundancy
mode used.
• Join when active – In this mode, only the active stream is subscribed, so total bandwidth utilization is the sum of
either primary or backup, using whichever stream’s utilization is higher so that worst case is calculated. Take care
to ensure that if it is possible for both HDMI’s input streams can ow on the same port, that this is included in the
calculation. For example:
»IP input 1 – 450 Mbps, ETH1, primary video for HDMI 1
»IP input 2 – 450 Mbps, ETH1, primary video for HDMI 2
»IP input 3 – 450 Mbps, ETH2, backup video for HDMI 1
»IP input 4 – 450 Mbps, ETH2, backup video for HDMI 2
»In this case, it should be gured that bandwidth per port is calculated as 900 Mbps, but the unit (both ports)
will not exceed 900 Mbps.
• Join always – As both primary and backup streams are always subscribed, the total bandwidth utilization is the
sum of all streams congured for the port in question.
Scrambling
Redundancy (OmniStream Pro Only)

AT-OMNI-XXX
9
Per Stream Bandwidth Utilization
Configured bitrate Used for video Used for FEC
FEC disabled 900 Mbps 900 Mbps 0 Mbps
FEC enabled, 4x4 900 Mbps 600 Mbps 300 Mbps
FEC enabled, 10x10 900 Mbps 750 Mbps 150 Mbps
FEC enabled, 20x20 900 Mbps 818 Mbps 82 Mbps
FEC enabled, 4x4 450 Mbps 300 Mbps 150 Mbps
FEC enabled, 10x10 450 Mbps 375 Mbps 75 Mbps
FEC enabled, 20x20 450 Mbps 409 Mbps 41 Mbps
Forward Error Correction (FEC) has a bandwidth penalty associated with its use. Atlona’s implementation of FEC
is per SMPTE 2022-5:2013 and does not require any extra network consideration beyond the bandwidth penalty
described here.
For video streams, OmniStream adjusts the bitrate used for video encoding automatically so that video bitrate + FEC
= congured bit rate.
FEC (OmniStream Pro Only)
Video bandwidth utilization has the most signicant impact on the network.
For OmniStream Pro units, the total bandwidth utilization for a video stream is the value congured for Bit Rate, on
the Encoding tab, of the encoder generating the stream.
For OmniStream R-Type, the total bandwidth utilization for a video stream is 900 Mbps.
Video
OmniStream Pro and R-Type PCM audio bandwidth utilization in Mbps can be calculated using this formula:
For two channel PCM formats, see the quick reference chart on the next page for bitrates.
Audio
Bitrate (Mbps) =
8 x (Sampling rate in Hz) x (Number of channels) x (4 bytes per sample)
1000000

AT-OMNI-XXX
10
Per Stream Bandwidth Utilization
For compressed formats, such as Dolby® Digital or DTS®, 3.07 Mbps should be used as a worst-case calculation.
OmniStream 232 Dante audio bandwidth utilization can be assumed to be 1.5 Mbps per channel.
Sampling rate (Hz) Channels Bitrate (Mbps)
32000 2 2.05
44100 2 2.82
48000 2 3.07
88200 2 5.64
96000 2 6.14
176400 2 11.29
192000 2 12.29
Atlona’s implementation of FEC is per SMPTE 2022-5:2013 and does not require any extra network consideration
beyond the bandwidth penalty described here.
Unlike video, audio FEC bandwidth utilization must be calculated if needed. Typically, as the bandwidth utilization of
audio is quite small compared to video, this is not necessary.
To calculate audio FEC bandwidth utilization, use the following formula.
As data trac is comparatively low bandwidth (typically < 100 kbps), it doesn’t signicantly impact the overall system
bandwidth utilization calculations.
FEC (OmniStream Pro Only)
Bandwidth utilization = Audio bitrate x
Rows + Columns
Rows x Columns
Data

AT-OMNI-XXX
11
Trunk Bandwidth Utilization
In star or fat tree topologies, multiple switches are interconnected with trunk links. Trunk links are interconnections
between switches which enable higher bandwidth connections between switches. To understand how link bandwidth
will be used, you must rst understand how the trac will ow.
It is recommended that trunk link bandwidth utilization not exceed 80% of trunk link capacity.
For unicast streams, the network will automatically nd a path for trac to ow from source to destination.
Figure 1 shows an encoder and decoder on the same switch in unicast mode. Figure 2, on the following page,
shows an encoder and decoder on separate switches in unicast mode.
Figure 1 - Unicast mode: encoder and decoder using same switch.
Unicast vs Multicast Routing
“Core” Switch
“Access” Switch
“Access” Switch
AT-OMNI-112
(Encoder)
AT-OMNI-122
(Decoder)
121 2
HDMI
PWR
LINK
VOLUME
DISPLAY
INPUT
ID
AT-OMNI-112
1 2
LINK
PWR
ID
AT-OMNI-122
Legend
Data flow
Unused connection

AT-OMNI-XXX
12
Trunk Bandwidth Utilization
For multicast streams, the network will do two things:
• Find a path for trac to ow.
• Propagate all multicast sources to the master IGMP querier/multicast router.
»For networks with multiple IGMP queriers, the IGMP querier with the lowest IP address is automatically
selected as the master IGMP querier. The master IGMP querier can optionally be statically dened, but this
requires extra conguration on all switches.
Figure 2 - Unicast mode: encoder and decoder using dierent switches.
Figure 3 - Multicast mode: encoder and decoder using the same switch.
“Core” Switch
“Access” Switch
“Access” Switch
AT-OMNI-112
(Encoder)
AT-OMNI-122
(Decoder)
121 2
HDMI
PWR
LINK
VOLUME
DISPLAY
INPUT
ID
AT-OMNI-112
1 2
LINK
PWR
ID
AT-OMNI-122
Legend
Data flow
Unused connection
“Core” Switch
IGMP querier
“Access” Switch
“Access” Switch
AT-OMNI-112
(Encoder)
AT-OMNI-122
(Decoder)
121 2
HDMI
PWR
LINK
VOLUME
DISPLAY
INPUT
ID
AT-OMNI-112
1 2
LINK
PWR
ID
AT-OMNI-122
Legend
Data flow
Unused connection

AT-OMNI-XXX
13
Trunk Bandwidth Utilization
Figure 4 - Multicast mode: encoder and decoder using dierent switches.
AT-OMNI-122
(Decoder)
“Core” Switch
IGMP querier
“Access” Switch
“Access” Switch
AT-OMNI-112
(Encoder)
1 2
LINK
PWR
ID
AT-OMNI-122
Legend
Data flow
Unused connection
121 2
HDMI
PWR
LINK
VOLUME
DISPLAY
INPUT
ID
AT-OMNI-112
Trunk ports on a switch are simply those ports used to connect to other switches. Note that multiple physical ports
can be bonded to create a higher bandwidth trunk link. Trunk links are always full duplex, which means that a 20
Gbps trunk link is capable of 20 Gbps uplink and 20 Gbps downlink simultaneously.
Trunk Port Denition
The trunk uplink bandwidth utilization is the sum of all trac owing from the switch in question to the other switch
connected to the link.
When computing trunk uplink bandwidth utilization, remember that any multicast sources (encoders) connected to
the switch in question must send their payloads to the master IGMP querier/multicast router. If another switch is the
master IGMP querier/multicast router, then the multicast trac must ow to that switch.
Refer to the next page for an example diagram showing uplink calculation.
Trunk Uplink

AT-OMNI-XXX
14
Trunk Bandwidth Utilization
“Core” Switch
IGMP querier
“Access” Switch
“Access” Switch
“Access” Switch
900 Mbps
900 Mbps
7200 Mbps
AT-OMNI-112
(Encoder)
121 2
HDMI
PWR
LINK
VOLUME
DISPLAY
INPUT
ID
AT-OMNI-112
AT-OMNI-112
(Encoder)
121 2
HDMI
PWR
LINK
VOLUME
DISPLAY
INPUT
ID
AT-OMNI-112
AT-OMNI-112
(Encoder)
121 2
HDMI
PWR
LINK
VOLUME
DISPLAY
INPUT
ID
AT-OMNI-112
900 Mbps
900 Mbps
AT-OMNI-112
(Encoder)
121 2
HDMI
PWR
LINK
VOLUME
DISPLAY
INPUT
ID
AT-OMNI-112
900 Mbps
900 Mbps
900 Mbps
900 Mbps
AT-OMNI-112
(Encoder)
121 2
HDMI
PWR
LINK
VOLUME
DISPLAY
INPUT
ID
AT-OMNI-112
900 Mbps
900 Mbps
5400 Mbps
1800 Mbps
Figure 5 - Diagram showing uplink calculation (multicast mode).

AT-OMNI-XXX
15
Trunk Bandwidth Utilization
The trunk downlink bandwidth utilization is the sum of all trac owing to the switch in question to the other switch
connected to the link.
When computing trunk downlink bandwidth utilization, it is best practice to assume worst-case by accounting for the
maximum amount of multicast trac possible, coming from another switch.
Trunk Downlink
“Core” Switch
IGMP querier
“Access” Switch
“Access” Switch
“Access” Switch
7200 Mbps
900 Mbps
900 Mbps
900 Mbps
900 Mbps
900 Mbps
900 Mbps
900 Mbps
900 Mbps
5600 Mbps
1800 Mbps
900 Mbps
900 Mbps
AT-OMNI-122
(Decoder)
1 2
LINK
PWR
ID
AT-OMNI-122
AT-OMNI-122
(Decoder)
1 2
LINK
PWR
ID
AT-OMNI-122
AT-OMNI-122
(Decoder)
1 2
LINK
PWR
ID
AT-OMNI-122
AT-OMNI-122
(Decoder)
1 2
LINK
PWR
ID
AT-OMNI-122
AT-OMNI-122
(Decoder)
1 2
LINK
PWR
ID
AT-OMNI-122
Figure 5 - Diagram showing downink calculation (multicast mode).
NOTE: The following diagram does not show encoders. It is assumed that all encoders are
connected to a separate switch that is connected to the “core”/IGMP querier switch.

AT-OMNI-XXX
16
IGMP / Multicast Routing Requirements
For networks using unicast only (point to single point), there is no special conguration needed for IGMP/multicast
routing.
For networks using multicast or a combination of unicast and multicast, IGMP/multicast routing must be properly
congured to avoid trac ooding ports and causing unnecessary outages.
Note that based on unit conguration, multiple unicasts/multicasts can be generated from single HDMI sources.
It is recommended that each stream be assigned a unique multicast address and port address.
Each switch carrying multicast trac must have IGMP snooping enabled.
For networks that do not require routing multicasts from one VLAN to another, only an IGMP querier is needed.
Important parameters are detailed here.
• Query interval – 30s
• Query response interval – 10s
• Last member query interval – 100ms
• IGMP querier version – v2
• Immediate leave enabled
»Lack of immediate leave will often cause issues with stream switching.
For networks that need multicasts routed from one VLAN to another, a multicast router is necessary. We will only
discuss Protocol-Independent Multicast (PIM), as that is the most common method of routing multicasts between
VLANs. There are three basic types of PIM, with PIM sparse mode being the recommended mode for multicasting
high bitrate video.
• PIM sparse mode (PIM-SM) (recommended mode) – multicasts are only propagated across VLAN boundaries
when a device request necessitates it. A rendezvous point (RP) is used in a similar manner to an IGMP querier.
• PIM dense mode (PIM-DM) – multicasts are ooded to all parts of the network and then pruned back based
on which devices request to continue receiving them. With high bitrate video multicasts, this can quickly cause
ooding issues.
• Bidirectional PIM (bidir-PIM) – similar to PIM-SM for downstream trac, but with enhancements for upstream
trac. Requires that all multicast routers in the domain have bidir-PIM enabled. Also not compatible with some
network redundancy schemes, as trac can never utilize multiple paths simultaneously.
Multicast Address Assignment
IGMP Snooping
IGMP Querier
Multicast Routing

AT-OMNI-XXX
17
IGMP / Multicast Routing Requirements
Some switches (e.g., Cisco SG300) allow the user to choose whether to lter or ood unregistered multicasts. If this
option is available, it should always be set to lter unregistered multicasts on all ports to avoid ooding when new
video streams are added.
For networks using Dante devices, including the AT-OMNI-232, several multicasts must be ooded to any ports
that may have Dante Controller connected in order for it to function properly. Note that some switches (e.g., Cisco
Catalyst 2960-X) do this automatically, but other switches do not (e.g., Cisco SG300). The Dante monitoring
multicasts are listed here.
• 224.0.0.230
• 224.0.0.231
• 224.0.0.232
The Atlona Management System (AMS) uses mDNS for automatic device discovery. By default, mDNS discovery
does not function beyond VLAN/subnet boundaries.
On switches that support it, any ports connected to OmniStream devices should have the below options congured
to enable the port to establish a link quickly upon device connection.
• Ports dened as access ports.
• Spanning tree portfast should be enabled.
Jumbo frame support is not necessary for OmniStream.
Quality of service (QoS) is not necessary or recommended for networks running OmniStream. If it must be used, it
is recommended that OmniStream’s DSCP value be congured to “Highest” and the network be congured so that
OmniStream packets have the lowest probability of being dropped.
Handling of Unregistered Multicasts
Special Notes for networks with Dante (AT-OMNI-232)
Multicast DNS (mDNS)
Switchport Conguration
Jumbo Frames
QoS
NOTE: A DSCP value of “Highest” on OmniStream correlates to 101 000, or 40 (CS5).

AT-OMNI-XXX
18
IGMP / Multicast Routing Requirements
OmniStream devices using Power over Ethernet (PoE) should plan 15.4 W consumption per device connected to PoE.
If analog audio is going to be used on OmniStream Pro AT-OMNI-12x devices, an external 48V power supply must be
used.
Dual channel OmniStream devices (AT-OMNI-112, AT-OMNI-122, and AT-OMNI-512) support load balancing/sharing
between the two PoE ports, but do not consume more than a total of 15.4 W per device.
The Atlona Management System (AMS) is used for centralized management of OmniStream devices.
All UDP ports between AMS and OmniStream must be open and available, as AMS uses WebSockets to
communicate with OmniStream.
System requirements for AMS including operating system and minimum hardware can be found in the AMS user
manual.
PoE
AMS
IMPORTANT: Some switches (e.g., Cisco Catalyst switches) will allocate 15.4 W to each PoE
capable port connected, regardless of whether that much power is consumed or not. For these
switches, it is important to plan 15.4 W consumption per port connected, even if both ports are on
the same OmniStream device. Other switches (e.g., Cisco SG300) do not try to intelligently allocate
power and thus do not require this.

atlona.com • 408.962.0515 • 877.536.3976
© 2017 Atlona Inc. All rights reserved. “Atlona” and the Atlona logo are registered trademarks of Atlona Inc. All other brand names and trademarks or registered trademarks are the property of their respective owners. Pricing, specications and availability
subject to change without notice. Actual products, product images, and online product images may vary from images shown here.