[Namaste-dev] Re: My reading of the latest Link Analysis
kb5mu at amsat.org
Tue Jul 1 14:11:33 PDT 2008
At 8:34 PM -0400 6/30/08, Bob McGwier wrote:
>On the desirability and need for FH-CDMA, I am in some doubt. When we left San Diego in 2006, we had decided that the spacecraft would announce unoccupied channels and the user terminal would "pick one at random". This relieves the major sources of interference does it not?
It might not be quite good enough, or so I suspect based on back-of-the-envelope calculations. The issue is access collisions. Check me here...
Assume an FDMA system, and let's concentrate on voice communications. When does the user have to make a random access to the satellite? The two obvious choices are when a user joins a conversation, and when a user hits push to talk (PTT). I believe the answer has to be when he hits PTT, because if we reserve a channel for every user in a conversation, we'll be throwing away a lot of channel capacity. Hams tend to have roundtable conversations with many people listening most of the time. We can't afford to have a channel assigned to each of those users.
Now if we assume that the channel access happens when the user hits PTT, what does that tell us? It tells us that channel access had better be very quick and it had better be very reliable.
If channel access isn't quick, we'll have to impose an operating discipline like they use on trunked radio systems: the user hits PTT, and then has to wait for a beep before he can talk. I submit that's completely unacceptable to hams. They aren't used to it, and it interferes with the normal rhythms of conversation. Bad enough that we have an unavoidable long delay due to the satellite link. Adding an additional wait-for-the-beep hoop for the user to jump through on every transmission would degrade the perceived level of service unacceptably.
If channel access isn't reliable, the user perception of the voice service will be poor. If it fails even one time in a thousand, the heavy user is going to be aware of it and perceive the service as flaky.
OK, so quick and reliable. Since we have a long turnaround time due to propagation delay, quick means that channel access must be open loop. Fire and forget. The ground terminal will have to emit whatever preambles or access codes are required and then immediately begin sending voice data, and that has to be sufficient to guarantee successful access to the system 99.9% of the time, or better. It will still need programmed procedures for recovering from an access failure, but that had better be a very rare case.
Now look at the numbers. It looks like we have bandwidth available for 250 uplink channels, give or take a factor of 2. But not all 250 are available for random access. Some of them are in use. If the system is busy, that number might be as high as 50 simultaneous conversations being retransmitted on the downlink. That number depends on the amount of power available for the downlink, of course, but let's say 50 for now. That leaves 200 channels available for random access.
Or does it? We'll need to run some real numbers, but that calculation assumes that an uplink channel is instantly deallocated when the user releases PTT (and thus stops using the power-limited downlink resource). That's probably not the right rule, though, since users who have transmitted recently are especially likely to transmit again soon. It will probably turn out to be better to keep the channel allocated for some period of time. The real number of channels that need to be allocated to match a 50-user downlink is probably 100 or 150 or even more, which would further reduce the number of channels available for random access. But let's ignore that for the moment.
OK, 200 channels for random access. What's the probability of collision?
We need to step back and define collision. At time T0, station Alpha chooses channel X and begins transmitting. Alpha emits a few frames of preamble and then begins transmitting voice data. The spacecraft detects the preamble and allocates X to Alpha, and deletes X from the list of available channels. Periodically the spacecraft transmits the list of available channels. Stations Bravo, Charlies, etc. all receive the updated list and store it in their respective local databases of access information, at time T1. If any other station makes an access in the interval T0 to T1, and happens to choose X, his transmission will interfere with Alpha's. Even if he's lucky enough to not interfere with Alpha's preamble (and thus her channel assignment), he has still stomped on a number of Alpha's voice frames.
How long is T1-T0? It's bounded below by the round trip propagation time, plus a few frames for preamble detection, processing, and re-transmitting the available channel list. Roughly, 300 milliseconds or more. That's a pretty big window.
Now, how closely spaced are these random accesses? That's a hard question. If we assume that the satellite can support 50 rooms, in which everybody takes turns speaking and never doubles, and an average transmission duration of 10 seconds, that's about 5 accesses per second. However, it's not that simple. People are not independent random processes. Let's say that one of those rooms contains a rare DX station working a pileup. He has attracted the attention of 100 stations, and they ALL transmit every time he says "QRZ?". That's not an unrealistic scenario, as anyone who was active on AO-13 can attest. Maybe we had better design for 100 accesses per second, which is about 30 accesses per collision window.
That's bad. Our probability of choosing the same channel is already way too high with even a single access in the window (since I want 1/1000 or better and I only have 1/200). But it looks like, under heavy load, we might have as many as 30 (on average!) in the window. That makes a collision rate of something like 14%, which is Not Good.
What to do about it? Well at least one of those numbers I assumed is going to have to give. We don't want to cut the capacity. It would be really dumb if our satellite system design were limited by access collisions instead of by spacecraft power capabilities. So what can we change? Well, we can change the number of effective channels by using CDMA. The timing and number of users and power limits don't change, but the definition of collision does. It's not a collision if the spacecraft can demodulate both users successfully. Chances are that some symbols will be lost to interference from other accessing stations, but we can design the system to be able to decode through that interference.
What I've given above is not an airtight argument by any means. I'm sure you can see all sorts of ways to adjust it. However, I think it's sufficient to justify doing more analysis on both FH-CDMA and FDMA in order to make an informed decision about which will really work better.
kb5mu at amsat.org
More information about the Namaste-dev