But deploying vc has two significant costs:
1. The initial costs around purchase of vc equipment, installation, training, upgrading of network infrastructure, etc; and
2. The cost of sending all that new vc traffic across your network links.
Here I talk about that second cost – vc network traffic, and more specifically how to work out just how much extra traffic will be generated across your network links by the vc sessions.
Broadly speaking there are two types of network links organizations can get:
· (higher) Fixed cost per month, with no extra charges for volumes of data sent across those links; and
· (lower) fixed cost per month + data charges
Organisations looking to deploy vc need to work out just how much data they are likely to use in order to ascertain the least cost type of network connection for their particular requirements, and to ensure they "size" their network links appropriately. (There are of course many other factors that go into selecting the most suitable network connections for an organisation, such as availability at each of your sites, existing telco relationships, security implications, etc.)
We talk about running our vc sessions at a given (nominal) data rate. I.e. 256Kbps, or 384Kbps, or 512Kbps, or 1 Mbps etc.
In general terms, the higher the data rate, the better the picture quality (resolution) we get. Basically we are sending/receiving more pixels, and thus get a higher resolution image. The capabilities of the vc systems used come into play here as well. Older systems often cannot support higher resolutions.
To go from there to working out how much bandwidth will be consumed (charged for by your ISP or network provider) by your vc sessions, we go through a series of calculations.
An important thing to note is that these calculations are not exact, rather they give a rough indication of the bandwidth used. The actual data volume used will vary from the theoretical calculations below, due to things like frame rates, amount of movement in the vc shot (less data is sent over the vc session if there is less movement in the field of view), etc, etc.
So, to the calculations:
We start with the selected data rate (eg 512Kbps) for the vc session, and then apply the following factors:
This is the extra data added (such as address / sender information etc) to send the vc information over the IP network. A factor of 20% is commonly used for this.
Multiply by 1.2
Send AND receive
In a vc session we both send and receive video data. We are usually charged for the data sent in each direction. Upstream & downstream.
Multiply by 2
The data rate is measured in seconds. I.e the data sent/received per second by a vc session.
So to work out how much data will be consumed by any given vc session, we multiply by the duration of the session(s).
60 seconds per minute, 60 minutes per hour.
We are normally interested in working out what we will be charged for data usage per month.
So, work out how many hours of vc sessions you expect to run in the month, and use that figure.
Multiply by 3,600 (seconds per hour) x hours used per month
Bits to Bytes to Gigabytes
The data rate is typically measured in bits per second (bps). Most traffic charges are stated in MegaBytes (MB) or GigaBytes (GB). There are 8 bits per Byte.
Note that the abbreviation “b” – lower case b - is used to represent bits, and the abbreviation “B” – upper case B - is used to represent Bytes.
Divide by 8 to get from bits to Bytes
Divide by 1024 to get from KB to MB (in some cases the network vendor will use 1000 here rather than 1024)
Divide by 1024 to get from MB to GB (again - may sometimes be 1000)
(so divide by 8,388,608 to go from bits to GB)
512 Kbps x 1.2 (IP overhead) x 2 (send & receive) x 3,600 (seconds to hours) x 12 hours of vc sessions per month / 8,388,608 (bits to GigaBytes) = 6.3 GB
The overall factor works out to be 1.055 for Kbps to MB per hour. I.e multiply Kbps by 1.055 to get a rough approximation of the equivalent MB per hour.
In a point-to-point vc session, we have one site in a vc with one other site. The traffic is as calculated as above for each network link involved.
When we combine 3 or more sites in a single vc session this is called a multi-point call, and the process of joining the different legs of the call together is called bridging.
For smaller setups, the bridging functionality is often built into one of the vc systems.
The traffic to such a bridge is simply the sum of the other vc systems/sites/endpoints participating in the vc session. I.e. n-1 x the traffic calculated per site, where n is the total number of systems/sites in the call. (assuming all sites connected at the same data rate)
For larger setups, the bridging will be done in a stand-alone bridge, and then the traffic to the bridge is simply the sum of the traffic to each site in the call.
Comment by cisconz, on 21-Jul-2010 19:00
Thanks for this Andrew, Helpful to have a nice guide.
Comment by networkn, on 25-Jul-2010 16:48
Thanks for this, I found it really very useful!
Comment by networkn, on 25-Jul-2010 17:12
I'd really be interested in the same for audio/voip.
Comment by Norman Birnbach, on 30-Jul-2010 11:34
Good article. For another look at bandwidth management issues, you might want to take a look at "Bandwidth Management: Critical Factor for Enterprise Videoconferencing" (http://twurl.nl/i0h4gh), an article by Chris Lauwers, CTO at Avistar (my client) that appeared in Computer Technology Review. (By the way, Polycom licenses IP from Avistar.)
Add a comment
Please note: comments that are inappropriate or promotional in nature will be deleted.
E-mail addresses are not displayed, but you must enter a valid e-mail address to confirm your comments.
Are you a registered Geekzone user? Login to have the fields below automatically filled in for you and to enable links in comments. If you have (or qualify to have) a Geekzone Blog then your comment will be automatically confirmed and placed in the moderation queue for the blog owner's approval.