SatSig topic:

FEC vs Number of Satmodems

(Read 7099 times)

May 30^th, 2011 at 9:44am

Hi,

i have to configure one or two return carrier in a network that will contain 60/70 satmdodems.

I can use two kind of modulations (frame lenght = 125.000 ms):
- QPSK .66 --> 244 time slots
- QPSK .79 --> 63 time slots

Can I use a 63 slots network with more than 63 satmodems?

Can I use two 63 time slots networks with Frequency Hopping (126 total timeslots)?

Satmodem will made a simple internet traffic. What is the better solution for this kind of network?

Thanks

May 30^th, 2011 at 12:52pm

You will need two carriers if you intend to use large block (4096) FEC (.793).

Keep in mind that each remote uses a single timeslot for keepalive ...therefore with a contention of 60+ remotes, you will be using an entire upstream carrier simply for keep alive traffic. (be advised, the one slot per remote MIR can be adjusted at the network level, but this modification has an effect on IP ramping and latency...)

QPSK .66 (1k block size) may be better suited for the contention ratio you're describing/anticipating. Granted, the payloading ability of QPSK .66 (72 Bytes) is not near the caliber of large block .793 (@ 394 bytes per slot) but at least you will have MORE slots...which will be necessary for keepalives..and still have some residual slots for payloading legimate IP traffic (other than keep alives). So, you are building in the potential for growth!

Not to mention, you will have a lower threshold C/n at the Rx line card with .66...vice .793. I (personally) prefer .793, but in an effort to sustain your contention I recommend you go with .66 unless you are comfortable using one of your carriers entirely for keepalive and retaining the other for IP traffic.

May 30^th, 2011 at 1:52pm

Thank you.

You suggest me to use .66 FEC for my network with 60/70 satmodems.

Frequency Hopping allows the remote to transmit on one timeslot in one carrier, then transmit on another timeslot on another carrier in the same inroute group. This can happen in the same frame [ Topic: Frequency hopping].

So, With FEC 0.79 (63 timeslots), using Frequency Hopping, are 126 the total timeslots available?

I would use 0.79 FEC because, as you wrote, system has 4096 block size available for transmission.

Which is a good value between number of timeslots and number of satmodems?

Thanks.

May 30^th, 2011 at 2:57pm

Yes, 126 slots if you configure for x2 - QPSK .793 upstreams (63 timeslots per TDMA inbound carrier). The info rate associated with that config is a little over a T-1 (1536k) - per carrier. The remotes will simply freq hop between the two upstreams. The main point I was trying to make is that in configing for large block (.793), you are using a lot of slots for keepalives....but it is still doable.

Timeslots (BW) vs. Number of remotes is referred to as a contention ratio. Contention ratios, whether they are 10:1 or 100:1 are situationally dependent, as you need to have a firm understanding of each remotes anticipated BW requirements (voice calls, video teleconferencing requirements, and overall traffic expectations based on the applications used at the node) - prior to sizing up outbound and inbound/return carriers for your network.

This (network) planning is typically done on the front end prior to even building the network. Read: You are literally developing the network around the nodal requirements (be advised, this is an important step that most HNOs/ISPs leap right over because they are in a hurry to nail up Xponder space in an effort to start generating revenue). That said, if you short change the nodal requirements by configuring inadequate carriers (forward and return), then you will have service issues. Other things you need to consider are: TCP enhancement and QoS...as they are critical in successful implementations.

May 30^th, 2011 at 3:49pm

Thankyou very much,

You convinced me: for Internet traffic is better to use small blocks that allow me also to have a high number of timeslots.

I will study better the network to develop the carriers.

Good Bye.

May 31^st, 2011 at 1:01am

If you desire, you can initially config at QPSK .793 TPC to see how it does/performs, and if you dont like what you are seeing, you can always roll the upstreams over to .66 in an effort to leverage more slots. That is the beauty of iDirect - how quickly you can scale a network to accomodate your needs/requirements. Have a good one...

M

Jun 2^nd, 2011 at 10:51pm

You should also take into account the type of traffic users will use. And how active are they going to be for the inroute.

In my practice having less than 10 timeslots per active remotes leads to severe lack of the timeslots which lead to performance degradation of certain applications.

Note also that TCP and UDP cannot go in the same timeslot, therefore if you are having both of these on the network (most networks do) you may multiply bu two number of your remotes.

Jun 3^rd, 2011 at 9:54am

Quote:

TCP and UDP cannot go in the same timeslot

this is very important information, satmodem on my network make traffic both TCP and UDP, so I think it is better to use several timeslots.
Thanks

Jun 4^th, 2011 at 12:00am

mmurtas, as I said less than 10 timeslots per active remotes most probably will lead to lack of timeslots available.

if you have very few UDP and few TCP traffic, that means that 126 timeslots are already busy. and none of the remotes is capable of sending anything but what will fit in one timeslots.

In most of the networks, you will have some traffic coming from the remotes - emails, files, voice, backup etc... this requires some spare timeslots.

Jun 4^th, 2011 at 4:45pm

maybe I expressed myself badly... satmodems on my network make a traffic both UCP and TCP. In order to ensure slots for all satmodems, i chose to use two carriers (frequency hopping) with QPSK .66 - 244 time slots = 488 timeslots. This solution ensure all satmodems to have enough timeslots to transmit all the traffic (classic internet traffic: small packets in upstream). This solution will allow me to increase the satmodems on my network because in the future I may add a third carrier.

Jun 4^th, 2011 at 9:12pm

I think that is a good call.

Jul 6^th, 2012 at 12:15pm

Quote:

Note also that TCP and UDP cannot go in the same timeslot.

Can you please indicate me which iDirect Guide describes this kind of information?

Thanks,
Regards