As I know, if I want compute BER, I need compare the resultant signal with original and compute an error.
No, that's an error vector magnitude (or something similar), not a bit error rate: there's no bits here! Only signals.
Bit error rate can only be determined when you're back to bits to compare – so you need to implement or at least assume a characteristic of a receiver.
but now I wanted to see the BER performance of changing the data rate ( check what data rate I can reach).
Well, how to do that depends on how you change the data rate. For example, if changing the data rate by a factor of $\alpha$ simply means using $\alpha$ times more bandwidth (at fixed transmit power!), you typically also get $\alpha$ times as much noise power (white noise -> constant PSD -> noise power proportional to bandwidth), and hence $1/\alpha$ times the original SNR: It's simple as that!
If you changing the data rate means changing the transmitter in some way, you'll need to describe how the receiver reacts to that.
Do you plot BER vs data rate?
Yes, but rarely on a system: you'll typically adjust your system in a way that guarantees a specific BER prior to the decoder or a specific BER at the output of the decoder. That way, "BER vs data rate" becomes a bit of a boring graph – if you designed your system reasonably, it's more or less a flat curve (aside from unrealistically good SNRs).
The general idea is that BER is kind of non-negotiable: if it's too high, your transmission is broken and your system won't work. So, you go into your system design and say "I need to achieve this BER". Then, you go and search for the fastest transceiver approach that can achieve that BER.
You might, however, not be at the system design level, but at level where you're trying to figure out what BER a specific approach can do! That's great, but then don't plot BER over data rate for the overall system, but plot BER over SNR (or Eb/N0) for the different approaches – you don't know which approach you'll end up using for which data rate.
It all boils down to a different design process. It's a bit "write all of this down!"-focused, so you can later make decisions based on your requirements, and not require based on your decisions:
- you start by defining the BER you need to achieve at the output of the decoder, so the overall system BER, and
- the data rate your system needs to achieve at least to be useful, and
- the range of SNRs and channel models you need to work with, and
- (this might be hard at this point, so maybe safe for later) a maximum receiver computational complexity, and finally,
- (optional, but recommended) get a coffee, tea or glass of water, and add "basic skills in requirements engineering for communications engineering" to your resume.
- You write down your design space:
- Which bandwidths are available? (often defined by law)
- What types of equalizers (if your channel model dictates that) are available? (this heavily depends on bandwidth and channel model!)
- Which modulations can you use? (sensibly!)
- For these, what are the available deciders? Are there hard- and/or soft-output deciders?
- Which channel codes would be sensible for this use case? Which decoders?
- Convert the above design space into a set of design specs.
Fix the first item (e.g., bandwidth, say, 10 MHz),
look at the choices for the second (say, modulation: 2-FSK, 4-FSK, 8-FSK, BPSK, QPSK, 8-PSK, 16-QAM, 64-QAM, 256-QAM), then
for each of these select from another bullet point above select the reasonable choices (say, equalizer: OFDM (works for all but the FSKs), SC-FDMA (same), DFE, CMA (only works on the PSKs)…)
You get a tree of possible design choices. You can prune the tree early – for example, if your channel is wide (in terms of ISI), you generally won't do FSK, but things like OFDM.
In the end, you've got a tree that has candidates for your system, at every design SNR.
- Define the relevant performance metrics between the levels of your tree - for example, for your equalizer you get an input SNR, and you get an output error vector magnitude. At the input of your decider, you get an error vector magnitude and get an output symbol error rate. At the input of your decoder, you get a symbol error rate, and produce a bit error rate. This allows you to walk top to bottom and say "Ok, for the design choices made when I walk this specific path trough my tree, I can combine output/input curves of each node on that design path, and get a BER/SNR curve for the design choice at the end.
- At each leaf of your tree, do write down the data rate you'd achieve with it.
- For each achievable data rate, highlight the method that does it with the least BER for a given SNR – and ignore the rest at that SNR! That's your Pareto frontier.
This is a lot. That's why you usually don't start with designing rate adaptive systems until you have a lot of experience with calculating single-rate systems (otherwise, the pruning and the selection of the best candidate steps just take a lot of work).
