(Written and Published by Scala, Inc.)
Allocating Bandwith
When proposing a visual communications network, it
is essential to begin calculating bandwidth
allocations, even when there will be as few as 20
remote sites. Though many customers plan ahead
with client-side broadband access with DSL or cable,
some forget the server to be just as important
when it comes to traffic. Luckily, InfoChannel’s
flexibility can scale to handle networks of any size,
from cable or closed circuit television to campus-wide
information systems to nationwide retail signage or
worldwide corporate communications. A single LAN or
outbound T-1 line may be enough for a single
computer running both Designer and Network Manager
in small installations. However, larger
deployments rely on the scalability of Scala software
to handle off-site servers and multiple types of
Internet access in the same network – even satellite/IP
multicast.
Whatever the method of data delivery,
Scala’s InfoChannel software suite distributes
content
intelligently and saves on transmission costs compared
to streaming video. Yet bandwidth is still an
important consideration. The truth is that server
side limitations can actually have a greater effect
on
transmissions than anything else. Depending on the
type of content and the number of locations you
are trying to reach, a T-1 line may or may not be
enough to handle all file transfers.
For example, suppose 800 Players are all connecting
via 56K dialup modems, downloading 10MB per
month per site from one T-1 line hosting an FTP server
in-house. Most dialup modems can expect
transfer rates of 4KB/s, and one modem could generally
download this amount of data in an hour or
two. So at first glance, it seems like a modest network.
Yet when 800 sites try to connect simultaneously,
the single T-1 line becomes 20 times oversaturated!
One decent T-1 line can only expect to deliver content
at around 150KB/s. Therefore, by doing some
simple math, we find that multiplying 800 Players
by 4KB/s equals 3200KB/s of traffic. The T-1 line
running at 150KB/s can only connect with 37 Players
at a time, and each can only download at less
than 200 bytes per second per Player throughput! With
this lack of bandwidth, it is mathematically
impossible to serve this many locations. Even after
adding a second T-1 line, the network will be 10
times oversaturated.
However, the traffic is still relatively
minor at only 8GB per month, so a satellite infrastructure
should not be necessary in this case. The solution
involves hosting the FTP service at a remote co-location
site
that has excellent bandwidth to overcome the internal
bottleneck. As you can see, standard terrestrial
networks are still feasible if the content is kept
to mostly lightweight updates, even in large networks.
One just needs to ensure that there will be enough
bandwidth available to access the FTP server.
Of course smaller networks, especially
those found in cable and community television or the
hospitality
industry, would rarely need to worry about these considerations.
With only a few InfoChannel Players,
the network is almost invisible. Content creation,
scheduling, and file distribution all can easily be
done
from the same computer. And as your needs grow, the
same flexible architecture of Scala InfoChannel
scales to accommodate external or off-site FTP servers
and even satellite/IP multicast networks for
hundreds or thousands of digital signs, billboards,
or kiosks.
Terrestrial vs. Multicast
Still, since InfoChannel is one of the few visual
communication network solutions that can handle so
many types of networks, it is a common misconception
that satellites are needed regardless of the size
of the deployment. However, our optional InfoChannel
Broadcast Server is only recommended in
networks controlling 50 or more remote sites. It is
designed to take advantage of multicast technology
to save bandwidth cost and download time, but is actually
not meant for most broadcast television
applications. Therefore, in this connotation, broadcast
means transmitting data nationally or even globally
via Satellite and IP/Multicast. Local cable operators
are usually better suited to using a few
InfoChannel Players connected via LAN or modem with
InfoChannel Network Manager.
In other words, InfoChannel Broadcast
Server is only necessary when you plan to use an IP/Multicast
Network (i.e. a network that can "broadcast"
to hundreds of locations in a single transmission).
Multicast is most often done with satellites but choices
also exist for terrestrial lines. However, it is
important not to confuse multicast with simple broadband.
While more data can be transferred via
broadband (cable or DSL) than with regular dialup
modems, these are still unicast technologies that
must communicate with each remote site individually,
only a few at a time.
Though there may be no theoretical limit
on the number of InfoChannel Players supported in
a
terrestrial WAN, there is a physical limit due to
the fact that each remote site has to "pull"
its content
from the central FTP server. The pull model allows
for more flexibility in smaller networks but becomes
burdensome as networks scale to hundreds or thousands
of sites. The limit for terrestrial broadband
networks depends on the bandwidth available at the
central FTP server as well as the amount of data
that needs to be regularly updated or transmitted.
Multicast, on the other hand, is a traditional
push model for downloading to occur in parallel, so
that
data can be sent simultaneously to any number of remote
sites without increasing bandwidth. The
unique scalability of InfoChannel is that both push
and pull technologies can take place in the same
network. One example of this is health monitoring.
A thousand-site deployment will probably use oneway
satellite communications for downloading the majority
of content. Yet assuming these computers are equipped
with modems, an administrator can also request weekly
logs for confirmation of playback and billing of advertisers.
Upon retrieving the job, the remote players would
dial in and send their accumulated data back to the
Network Manager. This completes the cycle of content
creation, distribution, playback, and verification.
In an interactive kiosk environment,
network operators can even ask for answers collected
at the point-of-sale or real-time inventory databases
and use that to determine their next content rollout.
It is this kind of power that separates an isolated
information booth updated by CD-ROM or DVD from a
network of intelligently managed kiosks. An InfoChannel
network does not just save time and money on logistics;
it provides people with the feedback they need to
be even more successful in the future.
Questions to Ask Prior to Deployment
Before choosing your network, it is important to determine
the type and file size of your regularly
changing content in addition to knowing how many Players
will have to be updated at once (as well as
how often).
• What file type, resolution, and length of
content you intend to send? DVD-quality video requires
around 40MB of file space per minute for standard
NTSC resolution, 720x480. HDTV-quality
video is about 140MB per minute at 1920x1080i. However,
if the video you plan to use is
primarily a live feed via TV Tuners, you may not need
to send any large files over the network at
all! Investing a little extra during installation
can save much more in the long run.
• Will the video be updated often or will only
graphical and textual changes likely be made? If the
largest files remain constant, you can take advantage
of InfoChannel’s store-and-forward
Intelligent File Transfer. Only the content that changes
needs to be resent because files are
saved separately. Sending all of your video at first
and pre-installing large amounts of content
may allow you to save money on bandwidth in the future.
• Are the remote sites playing the same content?
If large amounts of video are similar throughout
the network, then InfoChannel Broadcast Server’s
multicast support will be even more beneficial
because it sends data all at once instead of requiring
each remote site to establish a connection
individually.
• How many remote sites need to connect simultaneously
to the FTP server? Even though
updates may only be downloaded once a week, if it
is important that all changes be made quickly,
then traditional servers can be overloaded quickly.
• How often does the content need to be sent?
Making continual bandwidth-intensive changes can
cripple non-multicast traffic if network transmission
jobs do not finish by the time you want to
update again.
• Will you be sharing the network with other
departments inside your organization? If you are
working with existing corporate infrastructure, your
IT staff may have already set a limit to network
traffic, so you may have to rebalance your bandwidth
allocation or increase your monthly budget.
While it is possible to maintain large
networks with normal terrestrial lines, we typically
suggest
satellites in most deployments of 500 or more Players.
If you plan to constantly send large amounts of
video (e.g. cinema previews or movie rentals), then
multicast can also become cost effective to even
fewer than 100 remote sites.
Content Distribution and Administration
When talking of scalability, it is also important
to note that the FTP server that actually "serves
the
content" does not need to be the same physical
computer as the server running Scala’s InfoChannel
Network Manager software. Of course the FTP server
and the Network Manager can be the same
physical computer, but they do not have to be. The
Network Manager administers the remote sites and
schedules content distribution while the FTP server
is no more than a file warehouse. The reason why
the central FTP server is sometimes a separate computer
(or even location) from the InfoChannel
Network Manager is that the FTP server can be hosted
by an ISP for 24/7 physical security, high bandwidth
availability, backup, and support.
Customers of this size often have these
kinds of facilities themselves, and then the FTP server
and the
Network Manager can in fact be hosted on the same
computer. The answers to all of these questions
(both dependent on the network and content) determine
the final configuration of the Network Manager
computer. The most critical issues are of course the
bandwidth required and how much is available
from the FTP server, whether or not it is on the same
computer as the Network Manager.
• What network connections are
available at the remote sites? What is the speed of
each? Even if
you plan for satellite multicast, not every location
may be accessible with a dish. InfoChannel can
still handle multiple protocols within the same network,
but you may have to plan for increased
terrestrial traffic to handle areas still relying
on low bandwidth.
• What bandwidth is available to the FTP server?
It may just be a question of throttling traffic that
your company already leases.
• How quickly does the content need to get delivered?
Can it wait a day or two if your server
becomes saturated?
Maximize Network Potential
Take for example, 250 remote sites, which all connect
over terrestrial lines at 256Kbps (low speed DSL
or Frame Relay). Let's also assume that you do weekly
updates of 250MB of content and that all the
Players are updated at the same time.
We can therefore calculate 250 Players
multiplied by 250MB of content, which equals approximately
63GB of traffic each week. Does your network have
that much spare capacity? If you are hosting your
FTP server, this number will drive your monthly recurring
cost for hosting.
250 Players multiplied by 256Kbps DSL
(about 25 kilobytes per second, or KB/s) equals about
an
overall transfer rate of 5MB/s. Therefore, you'll
need at least four T-1 lines at your FTP server to
support updating every site at the same time. If you
are hosting the FTP server yourself, and have only
one T-1 line full allocated for this job, the bandwidth
to each player will be one fourth or 64Mbps. This
is actually a waste of money if you are paying for
a 256Kbps connection.
Assuming that your FTP server is not your bottleneck,
then it will take over 3 hours for the remote sites
to download the new content. If your connection to
the screens is more or less than 256Kbps, you have
more or less than 250MB of content, or if you have
a bottleneck at your FTP server, this number would
scale accordingly.
If this same network expands to 500
or 1,000 Players or more, you may then want to start
considering a multicast technology.
