Hi,
I am dealing with a UMTS uplink receiver implementation with USRP N210.
I
have some general questions that I hope that someone can answer:
- Is it completely necessary to implement a rake receiver? I have been
reading quite a lot about it, and it seems extremely complex because it
needs channel estimation, and this means to process the received signals
in
real time (which is not my purpose). Moreover, in the uplink there is no
pilot channel like the CPICH in the downlink. The Rake receiver improves
the
SNR of the signal by combining the multipath effects, but I wonder if
the
reception of the signal would be too bad if the Rake receiver is not
implemented.
- My idea is not to use the Rake receiver, because of its complexity.
The
SDR blocks that I have on mind for the receiver are, in a general
sketch::
Root Raised Cosine filter—QPSK DEMODULATOR------
-De-scrambling--------------------------De-spreading( correlating with
the
output of a OSVF code generator)
(correlating with
the
output of a scrambling code generator)
What do you think?any ideas?
Best regards,
Miguel
Hi Miguel,
You’re correct that the rake receiver combines multipath effects. If
there
is little or no multipath then a rake receiver is not necessary.
However, in any real world system a receiver needs to track timing
offset
with respect to the transmitter. To do this the receiver needs to
correlate
against the transmitted scrambling code at a series of lags to find the
peak. The result of these correlations is the channel impulse response,
so
in reality implementing a rake receiver isn’t much more difficult than a
single path receiver.
There actually is a pilot “channel” on the uplink, just not a dedicated
one.
For the standard QPSK uplink transmission, the control information is on
the
Q (imaginary) axis (see 3GPP TS 25.213 section 4.2.1.1). Uplink control
channel formatting varies (see 3GPP TS 25.211 Section 5.2.11), but at
least
some of the control bits in a frame are pilot bits. You can use these
bits
to derotate the data channel, similar to the way the CPICH is used on
the
downlink.
Furthermore your signal processing chain isn’t correct. You need to
first
descramble, then despread, then you can use a QPSK slicer/demodulator.
You
might consider first implementing a UMTS downlink receiever as it’s
similar
to the uplink, but a bit simpler.
Finally, if you plan on using this receiver to receive actual UMTS
uplink
signals keep in mind there are 2^24 possible codes (if the system is
using
long codes). If you don’t know the code number, it will take a very long
time to crunch through all the possibilities.
Good luck!
Michael J.
Software Radio Architect
Epiq Solutions
www.eqiqsolutions.com
Michael is correct. before demodulation the received signal should be
correlated. Michael, you said UMTS using scrambling code to do the
timing recovery. But the scrambling code is to distinguish MS in the
uplink,
each MS use different scrambling code so I think the correlation
shouldn’t be related to distinguish user. Is there any document about
UMTS
timing recovery tech?
Regards!
On Tue, Oct 25, 2011 at 10:59 PM, Michael J. <
Despite the NodeB’s best efforts, the transmissions from the mobiles
will
not arrive at the NodeB at precisely the same time. The timing offset
for
each mobile needs to tracked. The best way to do this is to correlate
against each mobile’s scrambling code.
If, in Miguel’s case he’s trying to receive the uplink and is not
physically
located near the NodeB, the mobile transmissions most definitely will
not be
arriving at the same time.
Michael J. wrote in post #1028387:
Hi Miguel,
You’re correct that the rake receiver combines multipath effects. If
there
is little or no multipath then a rake receiver is not necessary.
However, in any real world system a receiver needs to track timing
offset
with respect to the transmitter. To do this the receiver needs to
correlate
against the transmitted scrambling code at a series of lags to find the
peak. The result of these correlations is the channel impulse response,
so
in reality implementing a rake receiver isn’t much more difficult than a
single path receiver.
There actually is a pilot “channel” on the uplink, just not a dedicated
one.
For the standard QPSK uplink transmission, the control information is on
the
Q (imaginary) axis (see 3GPP TS 25.213 section 4.2.1.1). Uplink control
channel formatting varies (see 3GPP TS 25.211 Section 5.2.11), but at
least
some of the control bits in a frame are pilot bits. You can use these
bits
to derotate the data channel, similar to the way the CPICH is used on
the
downlink.
Furthermore your signal processing chain isn’t correct. You need to
first
descramble, then despread, then you can use a QPSK slicer/demodulator.
You
might consider first implementing a UMTS downlink receiever as it’s
similar
to the uplink, but a bit simpler.
Finally, if you plan on using this receiver to receive actual UMTS
uplink
signals keep in mind there are 2^24 possible codes (if the system is
using
long codes). If you don’t know the code number, it will take a very long
time to crunch through all the possibilities.
Good luck!
Michael J.
Software Radio Architect
Epiq Solutions
www.eqiqsolutions.com
Hi Michael,
Does the procedure you metioned is done in a receiver for Uplink of UMTS
systems(in practice)?
Can you introduce me any ref for further study?
Tnx
Hamed