![Scala - Digital Signage Software [Logo]](/images/layout_main.gif)
Scalable Network Agnostic Solutions.
Planning Network Architecture.
by Gerard Bucas, Jeff Porter, and Adam Edwards, Scala, Inc., February 2004
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.
Allocating Bandwidth.
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 one-way 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 with 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?
Maximizing 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.
