tolaris.com » satellite

srrctl, a Perl script to control a Quintech L-band switch

Tyler Wagner — Tue, 28 Apr 2009 15:51:52 +0000

We use Quintech SRR2150 L-band switches at our teleports. These are simple devices for switching L-band inputs and outputs. The most common application for one is to switch inputs to a spectrum analyser. This allows me to use one spectrum analyser to monitor several inputs (multiple antennas, multiple polarisations on the same antenna, etc).

Quintech’s switches are pretty basic. They have a front control panel, an interactive shell accessible by serial or telnet, and a custom communications protocol over 9100/TCP. Quintech provide a basic Windows management application, but it is either rudimentary (version 1.0) or totally broken (version 2.06). Why not control it from the command line? Thankfully Quintech have fully documented their management protocol, and implementing it in Perl was a few hours’ work back in 2007.

Behold, srrctl. The current version is 0.31. Right-click, save it somewhere like $HOME/bin, and make it executable:

chmod +x srrctl

It’s pretty easy to use. You can send any documented command with the -c option, but the two you’ll use the most are -g to get the active input, and -s to set it.

srrctl 192.168.3.101 -g

Q01

srrctl 192.168.3.101 -s 1

If this seems odd to you, that’s the literal communications protocol output. To request the current input, you send a “Q” character to 9100/TCP along with a header and checksum, and get back “Q” followed by a 2-digit port number. To set the input you do something similar, and get back an “S” to confirm that it was set correctly.

With srrctl you can now script L-band switch actions, or even make a simple modperl web page to control them.

Quintech switches are definitely not secure. Firewall them or someone’s going to do bad things to it. The new nmap scripting system and srrctl makes that really easy to do.

Carrier sizing and the decibel scale

Tyler Wagner — Tue, 07 Apr 2009 17:11:24 +0000

In the satellite world we frequently work with the decibel scale. Decibels (dB) are a way of expressing the relative difference in signal strength between two sources. It is a logarithmic scale, so increasing numbers represent an exponentional increase in power. In simple terms, they are a convenient way of using addition instead of multiplication.

There are plenty of good places to understand decibels. I want to focus on how this helps us answer a few important questions in carrier sizing.

I have two carriers, P1 and P2. What is the difference in power (Y) between them? Commonly this question appears as “Customer has capacity P1 and wants P2. How much additional power does he need to support the new carrier?”
I have carrier P1 of a certain size, and Y dB margin (additional power available). How large can I make my new carrier P2? Or if Y is negative, how small?

This breaks down to fairly simple math. We know two of three variables P1, P2, and Y, and we want to solve for the missing one.

First, the basics. A decibel is the base 10 logarithm of the ratio of the power of two signals, times 10:

dB = 10 * log₁₀ (P2 / P1)

Where P1 and P2 are the two signals to be compared. Since this is base 10, we can be express this without the explicit base:

dB = 10 * log (P2 / P1)

The handy rule of thumb of the decibel scale is this: 3 dB means twice the power. A carrier transmitted at 6 dB is twice as powerful as a carrier transmitted at 3 dB. And a carrier transmitted at 9 dB is four times as powerful as that 3 dB carrier. The scale can run negative as well, so a carrier transmitted at 0 dB is half the power of that 3 dB carrier, and at -3 is one-quarter the power. Remember that 0 dB does not mean “no power”, it is just another point on the scale.

So, if one carrier is 800 kHz in size, and another is 400 kHz in size, what is the difference in power between the two carriers?

P2 = 800, P1 = 400 10 * log (800/400) = 3 dB

Twice the power. Which is logical; if you want to transmit a carrier that is twice as big as your current carrier, you need twice the power.

What if the math isn’t so easy? Let’s say my old carrier is 685 kHz in size, and I want to increase to 976 kHz.

P2 = 976, P1 = 685 10 * log (976/685) = 10 * log (1.425) = 1.54 dB

So we’ll need 1.5 dB more power to transmit the new carrier P2. So if I want to transmit this carrier, I must improve that carrier’s C/N by 1.5 dB somehow. That means a larger antenna or transmitter (BUC) on the transmitting side, or a larger antenna on the receiving side. The same math works for a smaller carrier. Let’s start with a 500 kHz carrier and reduce it to 375 kHz:

P2 = 375, P1 = 500 10 * log (375/500) = -1.25 dB

So I need 1.25 dB less power. We might be able to use a smaller antenna or BUC.

Now we have an answer to the first question – what is the difference in power between two carriers? Now I’ll take a moment to explain a few more things before answering the second question.

Decibels are relative; on their own, they do not express an absolute value. They only tell you how two signals relate to one another. This means you can compare P1 and P2 in any equivalent terms. Let’s use IP rate in kbit instead of Hertz (both carriers must use the same modulation and encoding; we must compare apples to apples). Old carrier is 512 kbit, and new carrier is 768 kbit.

10 * log (768/512) = 1.76 dB

Decibels are sometimes expressed as relative to some reference. When this happens we write them as “dBX”, where X is the reference. I commonly work with dBW (where P2 is expressed in Watts of power and P1 is 1 W) or dBm (where P2 is expressed in milliwatts of power, and P1 is 1 mW). Converting between these two scales is easy; just add or subtract 30 dB.

10 * log (1000/1) = 30 dB

Examples:

0 dBW = 30 dBm 5 dBW = 35 dBm -30 dBW = 0 dBm

Which you use – dBW or dBm – does not matter as long as all your inputs are using the same scale. Modems often express transmit power in dBm.

Now we answer the second question. I have a carrier P1 that is 512 kbit in size. My modem is transmitting at -15 dBm, and has a C/N which is exactly what we need for reliable service. My maximum safe transmit power, which we determined early by a 1-dB compression test, is -12 dBm. So we calculate the margin:

Y = -15 - (-12) = 3 dB

How large can I make this carrier if I want to have 0 dB margin?

10 * log (P2 / 512) = 3 dB

If you’ve been paying attention, you know that 3 dB means “double the power”, so the quick answer is P2 = 512 * 2 = 1024 kbit. But let’s do the math anyway. To solve for P2, we need to convert decibels back to a linear scale. The magic formula is:

log_ax = y a^y = x

Remember that we’re using log base 10, so a = 10. Therefore,

10 * log (P2 / 512) = 3 dB log₁₀(P2/512) = 3 / 10 log₁₀(P2/512) = 0.3 10^0.3 = P2 / 512 P2 = 512 * 10^0.3 P2 = 1021.57

So we can transmit a 1021.57 kbit carrier. Why isn’t that 1024 kbit? Because I wasn’t entirely honest with you. “3 dB equals double the power” is just an estimate. It’s not really equal to 2; it is 3 dB = 10^0.3 = 1.995. But that is close enough for quick estimates.

Now you can solve the second problem – how to best resize a carrier given Y margin.

Homework problems:

You are transmitting a carrier at 350 kbit, and want to transmit a carrier at 800 kbit. How much additional power will you need?
You are transmitting a carrier at 700 kHz, and have 7 dB of margin. What is the largest carrier you can transmit with only 2 dB of margin?

Frequency math, or don’t touch my local oscillator

Tyler Wagner — Thu, 23 Oct 2008 16:04:03 +0000

Satellite engineers have a very poor showing on the Internet. I started writing about satellite stuff because of how difficult it has been for me to find reliable information. I’ve had to do a lot of learning by doing. Perhaps other satellite engineers enjoy their business being a black art, but like locksmiths and security alarm salesmen, they’re just waiting for the light of responsible disclosure to toss their world upside down.

And that brings me to a trend I have noticed in the satellite Internet business. There are two camps: radio guys who somehow configure a router, and IP guys who somehow align an antenna. Usually the IP guys do better in business than the radio guys. Perhaps this is because radio guys tend to be former military and unused to competition. Perhaps this is because they think all you have to do is deliver a carrier and everyone is happy. But the customer doesn’t care about Hertz, he cares about bits. And really, the space link is still a Layer 1 problem, and the harder work is above that.

On with revealing a little black magic.

Satellite systems communicate over a variety of frequencies. Modems and other terrestrial equipment commonly communicate between each other in one frequency range, yet the actual spacelink communication happens in another frequency range entirely.

The frequency bands I most commonly deal in my job managing satellite Internet services are (band, receive range, transmit range):

L-band, Rx 950-1450 MHz, Tx 1250-1750 MHz
C-band, Rx 3625-4200 MHz, Tx 5850-6425 MHz
Ku-band, Rx 10.95-12.75 GHz, Tx 13.75-14.5 GHz

There are a lot of ways to get confused here. The definitions of these bands varies from region to region. There are a lot of confusing terms like “standard Ku” and “extended Ku” despite there being overlap between the two ranges they define. The C-band I define above is actually called “extended C-band”, yet there is no “standard C band” as far as I can tell. And the Wikipedia articles on these things are a mess.

Satellite communication is normally a one-way process. Internet communication is by nature two-way, but from a satellite perspective we can regard it as two one-way processes. * So we’ll analyse it from that perspective.

During the entire one-way process, the physical communication signal changes frequencies four times. This is done to avoid radio interference at the satellite and ground antennas, and to avoid electrical resistance when communicating over copper.

Assuming Ku-band communication with the satellite, the devices that do the translating are:

BUC, or Block Up-Converter, which steps a carrier up from Tx L-band to Tx Ku-band
The frequency translator at the transponder on board the satellite, which steps a carrier down from the Tx Ku-band to the Rx Ku-band for retransmission to Earth
LNB, or Low-Noise Block down-converter, which steps a carrier down from Rx Ku-band to Rx L-band

These devices work by using a fixed translation amount, called the LO, for Local Oscillator. If you’ve guessed this is because an actual fixed oscillating clock is used, you are correct! It is very important to know what the LO value is, or you don’t know what frequency your transmission will become.

Let’s say a modem starts transmitting at 1131 MHz over a copper wire. This signal reaches a BUC with an LO of 12800 MHz. 1131 + 12800 = 13931 MHz, which is then transmitted into space as radio. The satellite receives 13931 MHz, where the transponder’s translator has an LO too. Here, it is 1260 MHz, and 13931 – 1260 = 12671 MHz, so 12671 MHz is then transmitted back to Earth as radio. ** Finally this 12671 MHz reaches the customer’s LNB with an LO of 11300 MHz. 12671 – 11300 = 1371 MHz, which is what reaches the customer’s modem.

In summary:

1131 MHz (modem)
1131 + 12800 = 13931 MHz (BUC)
13931 – 1260 = 12671 MHz (transponder translation)
12671 – 11300 = 1371 MHz (LNB)

The process repeats itself when the customer transmits in return, using whatever BUC and LNB are installed in the opposite direction. It’s common for both BUCs to have the same LO, and both LNBs, which makes the math easy for me. Each group of transponders on a satellite has its own transponder translation frequency, and these are different between C-band, Ku-band, K-band, and so on. The average technical user guide for the satellites Talia operates on is 35 pages. Read carefully.

I have a large spreadsheet tracking frequency translations like this. When you call a satellite operator to complain about a problem, they want the downlink frequency (12671 MHz in the example above). They certainly don’t know or care what your L-band frequencies are, because they can be different depending on the LO of your equipment!

A spectrum analyser is a common tool for observing satellite carriers, checking for interference, and measuring transmission power. Spectrum analysers commonly operate in L-band. This means that you must spot a problem in L-band and then do the math to find the downlink frequency before reporting a problem to the satellite operator. It seems to me that internally calculating the translation values would be a simple feature of a spectrum analyser, but most cheap ones (under $10,000 USD) don’t offer this. You’d need to define profiles for your different hardware/satellite configurations, but anyway it’s something that an IP engineer would think to add and a radio engineer just expects they’ll have to do manually.

I have yet to find even a single open source package to manage frequency plans or carrier assignments, by even the simplest methods. My spreadsheet is the most advanced free tool I have for this.

* Sometimes satellite Internet services are one-way. The download link is via satellite, and the upload link via terrestrial modem. But that method is unpopular today.

** I find it interesting that satellites themselves receive in the Tx range and transmit in the Rx range.

Identifying undersea fibre and satellite links with traceroute

Tyler Wagner — Thu, 09 Oct 2008 20:07:40 +0000

I frequently travel to the Middle East, which means I often find myself on the wrong end of a slow Internet link. Sometimes that is oversold undersea fibre, such as in Dubai. More often – because of my work – it is VSAT. I’m an engineer, which means I’m a curious monkey that takes everything apart just to understand how it works. Network topology is one of those things.

I wrote about something similar on my other blog last year.

First, some background information on VSAT. The single biggest limitation of satellite Internet service is latency. In network terms, latency is the total round trip time for your packet to reach its destination and for the reply to return. When we speak of “ping time”, what we mean is latency.

Here are some common latency measurements in milliseconds (ms):

1 ms – within your LAN
25 ms – my home cable service in London to servers located in mainland UK
90 ms – typical home DSL in the US to google.com
100-150 ms – the transatlantic cable between the UK and New York state
600-2000 ms – typical VSAT remote to hub link

Why is VSAT latency so high? Geosynchronous satellites orbit at an altitude of 35,000 km. VSAT remotes connect to the Internet via a star-shaped network with a hub at the centre. When a remote modem pings google.com, its traffic must travel up to the satellite, then back down to our teleport, and then over the terrestrial Internet to google.com. The reply does the opposite, returning back over the terrestrial Internet, back up to the satellite and down again to the remote. That means every single ping you send is travelling 35,000 x 4 = 120,000 km. Divide by c, and you find the minimum latency for any VSAT is 480 ms. Further time is added due to radio modulation, error correction, router delay, and various technical issues with shared bandwidth satellite networks. All that adds up to a minimum effective latency for all VSAT communications of about 600 ms. If that network is busy, it goes up.

So when one of our customers makes a VoIP phone call, there is an audible (600 ms) delay between when he speaks and when he can expect a reply. We constantly work to keep that number as low as possible. People seem to tolerate up to 250 ms without noticing, but when you start edging up to one second, it quickly becomes intolerable – less like a phone, more like a radio.

This latency is immediately noticeable on ping and traceroute. I prefer mtr, a tool that combines the two. Plain old tracert / traceroute will show you the same results, just a lot slower. Here is an example run from a VSAT link:

mtr yahoo.com

 Host                                       Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 192.168.5.1                              0.0%    10    1.3   3.3   1.2   7.2   2.4
 2. 172.16.4.97                              0.0%     9  605.8 672.2 605.8 764.5  54.4
 3. 172.16.4.1                               0.0%     9  699.6 690.7 611.9 761.6  50.7
 4. 172.16.3.1                               0.0%     9  637.1 666.6 578.1 763.7  58.6
 5. kln-145-253-9-73.arcor-ip.net            0.0%     9  671.4 638.1 592.0 699.7  38.2
 6. kln-145-254-9-153.arcor-ip.net           0.0%     9  640.2 638.9 578.5 736.1  46.8
 7. dus-145-254-18-194.arcor-ip.net          0.0%     9  655.3 650.9 609.2 684.5  24.2
 8. amd-145-254-16-130.arcor-ip.net          0.0%     9  702.0 667.6 604.8 778.2  60.2
 9. ge-1-3-0.pat1.ams.yahoo.com              0.0%     9  740.9 665.1 595.4 740.9  47.3
10. ge-1-2-0.pat2.ams.yahoo.com              0.0%     8  677.7 673.2 621.4 739.4  37.2
11. so-3-1-0-pat1.the.yahoo.com              0.0%     8  711.9 680.5 616.7 773.4  56.4
12. so-2-1-0-pat1.nyc.yahoo.com              0.0%     8  706.9 706.0 682.0 732.4  17.1
13. so-3-0-0.pat1.dcp.yahoo.com              0.0%     8  685.3 726.9 685.3 755.4  29.3
14. ae2-p170.msr2.re1.yahoo.com              0.0%     8  731.8 747.0 731.3 779.9  18.3
    ae2-p160.msr1.re1.yahoo.com
15. ge-9-3.bas-a1.re4.yahoo.com              0.0%     8  677.9 757.3 677.9 819.1  45.2
    te-8-3.bas-a2.re4.yahoo.com
16. w2.rc.vip.re4.yahoo.com                  0.0%     8  789.1 785.1 708.1 853.4  48.6

Note the huge jump in latency between hops 1 and 2. This must be the space link – hop 1 is the remote modem and hop 2 is the hub modem (the one in the teleport).

The jump in latency is obvious in both directions. From a terrestrial link to a VSAT IP:

 Host                                       Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 192.168.1.1                              0.0%    25    0.9   1.1   0.6   6.2   1.1
 2. 192.168.55.34                            0.0%    25    1.1   0.7   0.4   1.1   0.2
 3. 172.16.21.71                             0.0%    25    4.5   4.0   3.6   4.9   0.3
 4. 217.239.41.18                            0.0%    25   39.5  41.5  39.1  67.7   6.9
 5. 193.159.224.254                          0.0%    25   44.6  88.3  44.1 596.8 136.2
 6. 83.137.59.9                              0.0%    24   41.7  42.3  41.4  49.5   1.6
 7. 192.168.140.4                            0.0%    24   42.5  42.7  41.6  44.6   0.6
 8. 192.168.100.50                           0.0%    24   48.1  47.4  46.2  50.3   0.9
 9. 192.168.103.149                          0.0%    24  613.7 719.6 592.2 1128. 127.2
10. 80.86.24.6                               0.0%    24  620.9 787.1 582.9 1678. 272.7

Here the space link is between hops 8 and 9.

Similar increases in latency are detectable along undersea fibre. From my home in London to my alma mater Cal Poly:

 1. gw-belafonte                             0.0%     5    1.0   1.1   1.0   1.2   0.1
 2. 10.181.120.1                             0.0%     5   56.3  41.1  23.5  56.3  14.6
 3. osr01camd-v15.network.virginmedia.net    0.0%     5   32.1  39.9  19.0  89.7  28.8
 4. osr02hari-tenge71.network.virginmedia.n  0.0%     5   40.6  34.6  15.3  54.2  15.0
 5. pop-bb-b-ge-200-0.network.virginmedia.n 20.0%     5   46.1  34.6  18.6  46.1  13.2
 6. gfd-bb-a-so-010-0.network.virginmedia.n 20.0%     5   42.5  47.7  41.7  54.1   6.5
 7. 213.152.245.49                           0.0%     5   23.8  45.8  23.8  65.3  19.1
 8. so-0-0-0.mpr2.ams5.nl.above.net          0.0%     5   46.0  58.0  35.2  83.0  18.3
 9. so-2-0-0.mpr1.lhr2.uk.above.net          0.0%     5   65.2  74.8  47.3 100.2  19.8
10. so-1-1-0.mpr1.dca2.us.above.net          0.0%     5  124.5 120.6 105.2 135.4  10.9
11. so-1-2-0.mpr1.lga5.us.above.net          0.0%     5  132.6 152.9 121.6 216.0  39.1
12. so-2-1-0.mpr1.sjc2.above.net             0.0%     5  187.3 205.8 183.9 251.1  27.0
13. so-4-0-0.mpr3.pao1.us.above.net          0.0%     5  280.9 227.7 200.4 280.9  33.3
14. paix-px1--abovenet.cenic.net            20.0%     5  267.4 232.9 189.2 279.1  46.9
15. dc-svl-core1--svl-dc1-ge.cenic.net       0.0%     5  255.3 240.6 206.3 274.7  26.5
16. dc-sol-agg1--svl-core1-ge.cenic.net      0.0%     5  218.7 216.9 196.6 249.3  19.8
17. dc-sol-agg2--sol-agg1-ge-2.cenic.net    25.0%     5  209.8 209.3 199.1 218.9   9.9
18. dc-slo-dc1--sol-dc2-pos.cenic.net        0.0%     5  240.6 221.6 203.3 240.6  19.9
19. primary-pix-outside.netadm.calpoly.edu  25.0%     5  271.3 247.0 200.7 271.3  40.1
20. 129.65.1.41                              0.0%     5  245.9 213.7 190.7 245.9  23.3
21. ???

Now we can see that my home is named “Belafonte” (hop 1), that I have a network connection via Virgin Media (hops 3-6), that Virgin Media finds it cheaper to route via Above.net through Amsterdam and back to the UK rather than direct within the UK (hops 8 and 9), and that we cross the Atlantic between hops 9 and 10. Also, Cal Poly should know better than to use DNS names that state both function and operating system to anyone looking (hop 19, a Cisco PIX firewall at their network’s border).

Note the 60 ms increase in crossing the Atlantic, which is actually quite good for such a long fibre run. Compare a route from Dubai to the UK:

 1. 192.168.1.1                              0.0%     7    0.5   0.8   0.5   2.4   0.7
 2. 195.229.244.26                           0.0%     7   10.9  18.4   8.0  48.8  14.9
 3. 195.229.245.98                           0.0%     7   15.3  17.0   7.5  28.3   9.4
 4. 194.170.0.234                            0.0%     7    7.5   8.3   7.5   8.8   0.5
 5. 195.229.1.181                            0.0%     7   10.8  14.4  10.8  28.7   6.6
 6. 195.229.1.166                            0.0%     7   14.4  14.8  14.1  15.4   0.5
 7. pos10-0.cr02.hkg05.pccwbtn.net           0.0%     7  292.6 293.7 292.3 298.9   2.6
 8. uunet.pos1-2.cr02.frf02.pccwbtn.net      0.0%     7  258.8 259.1 258.8 259.5   0.3
 9. ge-1-2-0.TL2.FFT1.ALTER.NET              0.0%     6  259.1 259.1 258.6 259.6   0.3
10. so-0-0-0.XR2.LND9.ALTER.NET              0.0%     6  247.2 250.8 246.7 266.3   7.8
11. POS2-0.GW9.LND10.ALTER.NET               0.0%     6  258.3 259.7 258.3 262.4   1.9

Care to spot the fibre there? Here’s the kicker – it looks like it’s routing direct from the UAE to the US, then on to the UK! If memory serves, that’s probably the FLAG cable that runs from the Persian Gulf to the West Coast of the US. Yes, they make runs that long!