Satellite Internet forum
https://www.satsig.net/cgi-bin/yabb/YaBB.pl
Anything else >> General and other topics >> Bandwidth calculations for VSAT Systems
https://www.satsig.net/cgi-bin/yabb/YaBB.pl?num=1364362196

Message started by martin.amara on Mar 27th, 2013 at 5:29am

Title: Bandwidth calculations for VSAT Systems
Post by martin.amara on Mar 27th, 2013 at 5:29am
Dear Eric

I am a trainee trying to learn and make career in satcom. Below are some of my questions that will regarding basic concepts of VSAT systems kindly help me in finding the answer.

1- I have to calculate the bandwidth required for a 512kbps full duplex circuit. the modem can support QPSK and 8PSK modulations. What are the other parameters I need and how can I calculate bandwidth in MHz required for this SCPC circuit.

2- If i have given data rate only how can I calculate symbol rate from this information.


Martin

Title: Re: Bandwidth calculations for VSAT Systems
Post by Eric Johnston on Mar 27th, 2013 at 9:54am
You start with the information bit rate, 512 kbit/s.

Now add on the effect of forward error correction (FEC). FEC operates with various ratios. Values vary from about 0.5 to 0.95, with the value often alternatively expressed as a fraction, like 1/2, 3/4, 7/8 etc.

The transmission bit rate is then, for example 512/(3/4) = 682.67 kbit/s.

Next, to find the symbol rate, you need to consider the modulation method.
Note:
BPSK has one transmission rate bit per symbol
QPSK has two transmission rate bits per symbol
8-PSK has three transmission rate bits per symbol
16-QAM has four transmission rate bits per symbol

If you choose 8-PSK modulation, your symbol rate will be 682.67 / 3 = 227.55 k symbols per second.

The amount of transponder bandwidth needed for a 227.55 kbit/s carrier is about 1.2 to 1.4 times the symbol rate. I assume 1.35 below.


In the above example 512k 3/4 FEC 8PSK
the bandwidth needed is approx 1.35 x 227.55 = 307 kHz.

This is what you pay for. You are assigned a proportional amount of satellite eirp power. If you need more power (due to a too small dish size) then you can pay more. You will be given proportionally more bandwidth simultaneously as you are basically buying bandwidth plus its fair share of the total transponder power, less the output back off for multicarrier operation.

The 1.35 value is approximate and depends on filter roll off factor and the amount of adjacent carrier interference you can accept. If you have very small carriers, e.g. 16 ksps, then additional bandwidth may need to be assigned to allow for frequency error and drift. Your satellite operator will agree with you what bandwidth is needed for your carriers and may insist on a nominal factor of 1.4 If you want to claim for a lesser values make sure you fully understand the output spectrum from your particular make of modem.

The least bandwidth (and thus lowest cost) transponder arrangement is with 16-QAM and an FEC like 7/8 and sharp filtering like 1.2. Such a carrier requires a very high carrier to noise ratio (C/N) or energy per bit per noise power per Hz (Eb/No) and therefore requires larger earth station dish size, low phase noise and high linearity amplifer (BUC). A less efficient satellite system such as QPSK and FEC 3/4 and 1.4 works well at lower C/N and enables smaller dishes, but costs more due to the larger transponder bandwidth needed.

If you have a point to point service with two earth stations then use large dishes to get the transponder cost down. If you can see your own signals you may even be able to put two carriers (the go and return) on top of one another and make further big savings in transponder costs. If you have many sites save money on the costs of the many dishes and spend more on the satellite transponder lease.

Best regards, Eric.

Title: Re: Bandwidth calculations for VSAT Systems
Post by martin.amara on Mar 27th, 2013 at 11:41am
Dear Eric

Thanks for providing detailed answer for my query.

Martin

Title: Re: Bandwidth calculations for VSAT Systems
Post by martin.amara on Mar 27th, 2013 at 12:02pm
In case of a DVB-S2 outbound carrier how we can calculate required banwidth as ACM will also work there and modulation and data rate changes

Title: Re: Bandwidth calculations for VSAT Systems
Post by USN - Retired on Mar 27th, 2013 at 8:49pm
DBV-S2 is not actually related to your original question - or to Eric's response - as it's primarily a  broadcast technique. You asked about full duplex application. S2 is used extensively in satellite TV, as well as in bandwidth-sharing satellite internet hubs.

//greg//

Title: Re: Bandwidth calculations for VSAT Systems
Post by martin.amara on Mar 28th, 2013 at 5:23am
Yes that is right but i just want to understand that if we have DVB-S2/SCPC system then how can we calculate the required bandwidth in Mhz for this type of system. Also in case we are running iDirect HUB and need to plan DVB-S2 outbound then how can we calculate the required bandwidth for outbound

Title: Re: Bandwidth calculations for VSAT Systems
Post by Eric Johnston on Mar 28th, 2013 at 8:25am
A DVB-S2 carrier will have a constant symbol rate, but, in a VSAT network, the FEC and modulation may vary, from moment to moment, according to the weather at the destination earth station(s). In a VSAT network, sites with high C/N might be using 8-PSK while sites experiencing rain might be temporarily using QPSK. 16-APSK and 32-APSK are available for larger dish sites, where a very high C/N is available.

So the bandwidth needed is related to the symbol rate and transmit modem filter roll off only.

See https://www.newtec.eu/support/dvb-s2-calculator/
This is a downloadable excel spreadsheet calcuator and will give you allocated bandwidths for various symbol rates and filter roll offs. Choose the multicarrier mode. Macros may need to be turned on in your excel security seetings. Repeat the calculations manually to check that they make common sense as it is easy to produce nonsense results with automated calculators if you don't get every input parameter as the programmer expected.

Best regards, Eric.

Title: Re: Bandwidth calculations for VSAT Systems
Post by tearepa13 on Nov 24th, 2014 at 12:59pm
Just following up on that, to work out the information bit rate required for the Vsat remote, ie. what applications are required from the end user and how much bandwidth they chew up typically eg. email, P2P, browsing, voip, maybe bit of youtube...Is there a calculator that anybody knows out there that can predict the typical bandwidth usage for your most typical applications, as a starting point for your link budget?

Title: Re: Bandwidth calculations for VSAT Systems
Post by Admin1 on Nov 24th, 2014 at 2:01pm
I would allow 30 kbit/s per customer PC.

To make the "up to" download speed acceptable you need to find many customers. If you have a carrier download bit rate of 2 Mbit/s (so you can sell an "up to 2 Mbit/s" service), you can have up to 67 customers sharing, each paying their share of the total cost.

Your fair access policy needs to limit heavy users, by limiting the amount (Mbytes or Gbytes) per hour, day, month etc. Restrict or disallow remote servers, file sharing, virus/spam email sending etc.

Other people are welcome to add below what they think each customer should be allowed. 

Best regards, Eric.

Title: Re: Bandwidth calculations for VSAT Systems
Post by tearepa13 on Nov 24th, 2014 at 9:20pm
So in terms of a relatively acceptable throughput speed per terminal for your small office scenario as pointed out, I would think between 1 or 2 Mbit/s would do? I think with ADSL that would be minimum for advanced web browsing like facebook, email open, SD video occasionally running, a pretty typical SOHO (small office home office) scene.

If I have 30kbps per customer and I need 1 or 2 Mbit/s to keep the customer happy how does one relate the two figures? I'm not sure how you got to 30 kbps, it seems to me an average.

Thanks.

Title: Re: Bandwidth calculations for VSAT Systems
Post by Eric Johnston on Nov 24th, 2014 at 10:05pm
The carrier bit rate e.g. 1 Mbit/s, 2 Mbit/s or 20 Mbit/s etc is what you want to sell the service as the "up to bit rate".
The cost of providing it is according to that bit rate.
The price per customer is the bit rate divided by number of customers.
 
About 30 kbit/s * per customer seems about right to me now in 2014.

Example: 67 customer PCs, each 30 kbit/s, total 2 Mbit/s.

*  10 years ago in 2004, I was advising 10 kbit/s download and 3 kbit/s  upload per customer.

If you have fewer customer and still give them 2 Mbit/s the cost per customer becomes rather high and the service excessively good.

If you have 3 customer PCs and give them a shared carrier of 90 kbit/s then the price per PC will be the same but the "up to 90 kbit/s rate" will be disappointing to today's users. 

At any instant only one customer is using the downlink.

If many are inactive, which is normally the case, then the users might experience 2 Mbit/s for several seconds. Try to minimise use of continuous transmissions like video and audio etc in the daytime 0600 - 2400.

30 kbit/s is not the average usage.  It is an allowance which you need to allow for each customer PCs as a share of the carrier bit rate.  If you allow too little they will be annoyed.  if you allow too much the service will be excellent but may cost too much. You decide your figure - e.g 20, 30, 40 kbit/s. My personal choice now is 30 kbit/s.

The average usage is much lower since customers cannot fill up the carrier to the limit without unacceptable congestion. Read up on the erlang formula and congestion.  You do better with larger trunks and larger numbers of customers.

Try selling the night capacity 0000 - 0600 at lower price or find some customer who can use it for some purpose like major data downloads, backups, newspaper printing etc.

A customer on a basic tariff (e.g. Tooway 2GB per month) has an average usage of 6 kbit/s per month, for which I would suggest 15 kbit/s allocation.  i.e 1330 customers per 20 Mbit/s carrier.

Higher price tariffs are available for those that want Catch-up-TV, YouTube videos, Skype etc.

I would welcome comments on this. What do you think is appropriate these days ?

Best regards, Eric

Title: Re: Bandwidth calculations for VSAT Systems
Post by VSATEngineer on Feb 23rd, 2015 at 7:55am
Eric, have good day, I just have a question what do you mean about this "If you can see your own signals you may even be able to put two carriers (the go and return) on top of one another and make further big savings in transponder costs"?

Thanks in Advance!

Title: Re: Bandwidth calculations for VSAT Systems
Post by Admin1 on Feb 23rd, 2015 at 11:36am
Normally, if you transmitted two carriers on top of one another they would mutually interfere and neither signal would be receivable.

If you are in the same beam coverage area you can receive your own transmitted signal and also the one from the other site.  These two carriers may potentially be both on the same frequency and on top of one another.

At your site you can also see a third signal, your own clean transmit carrier before it is transmitted.  Using a copy of this and delaying it by the up/down propagation delay and reversing its phase you can subtract it from the dual carrier received 'noise' and thus reveal the wanted carrier from the far end.

This is a bit of suprise, but it does work.

You need special equipment at each end. See https://www.comtechefdata.com/technologies/doubletalk

The amount of bandwidth needed from the transponder is half, so the total monthly transponder bandwidth rental cost is half also.

The disadvantage is that you probably need larger antennas to get the required C/N, as the power available per carrier is halved.  Modern satellites have higher power spectral densities so this may not be the case, particularly if you are using older larger antennas anyway.

If you have a significant requirement, and it is a point to point service, and you are in the same beam coverage, then the savings on space segment will often far outweigh the initial higher costs of the two larger antennas and special equipment.

Best regards, Eric.

Powered by YaBB 2.5.2!
YaBB Forum Software © 2000-. All Rights Reserved.