Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)
Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)
15
May 2003 Jai Balakrishnan et al., Texas Ins truments Slide 1 doc.: IEEE 802.15- 03/218r0 Submiss ion Project: IEEE P802.15 Working Group for Wireless Personal Area Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Networks (WPANs) Submission Title: [Rake Span Requirements for Multi-band UWB Systems] Date Submitted: [14 May, 2003] Source: [Jaiganesh Balakrishnan et al.] Company [Texas Instruments] Address [12500 TI Blvd, MS 8649, Dallas, TX 75243 ] Voice:[214-480-3756], FAX: [972-761-6966], E-Mail:[[email protected]] Re: [] Abstract: [This document describes the rake span requirements for multi-band UWB systems.] Purpose: [For discussion by IEEE 802.15 TG3a.] Notice: This document has been prepared to assist the IEEE P802.15. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Release: The contributor acknowledges and accepts that this contribution becomes the property of IEEE and may be made publicly available by P802.15.
description
Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [ Rake Span Requirements for Multi-band UWB Systems ] Date Submitted: [ 14 May, 2003 ] Source: [ Jaiganesh Balakrishnan et al. ] Company [ Texas Instruments ] - PowerPoint PPT Presentation
Transcript of Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)
May 2003
Jai Balakrishnan et al., Texas InstrumentsSlide 1
doc.: IEEE 802.15-03/218r0
Submission
Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: [Rake Span Requirements for Multi-band UWB Systems]Date Submitted: [14 May, 2003]Source: [Jaiganesh Balakrishnan et al.] Company [Texas Instruments]
Address [12500 TI Blvd, MS 8649, Dallas, TX 75243]Voice:[214-480-3756], FAX: [972-761-6966], E-Mail:[[email protected]]
Re: []
Abstract: [This document describes the rake span requirements for multi-band UWB systems.]
Purpose: [For discussion by IEEE 802.15 TG3a.]
Notice: This document has been prepared to assist the IEEE P802.15. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributor acknowledges and accepts that this contribution becomes the property of IEEE and may be made publicly available by P802.15.
May 2003
Jai Balakrishnan et al., Texas InstrumentsSlide 2
doc.: IEEE 802.15-03/218r0
Submission
Rake Span Requirements for Multi-band UWB Systems
Jaiganesh Balakrishnan, Anuj Batra Anand Dabak, Jerry Lin, Ranjit Gharpurey, and Simon
Lee
Texas Instruments12500 TI Blvd, MS 8649
Dallas, TX
May 14, 2003
May 2003
Jai Balakrishnan et al., Texas InstrumentsSlide 3
doc.: IEEE 802.15-03/218r0
Submission
Outline
Overview of multi-path energy capture.
RAKE design parameters.
RAKE design: no group delay variations.
RAKE design: group delay variations.
Buildability issues with multiple RX chains.
Conclusions.
May 2003
Jai Balakrishnan et al., Texas InstrumentsSlide 4
doc.: IEEE 802.15-03/218r0
Submission
Multi-path Energy Capture
In multi-path environments, the RMS delay spreads for a UWB channel can be large (14 ns for CM3, 25 ns for CM4).
Uncaptured multi-path energy results in loss in performance of the UWB device.
One method for energy collection is to use a RAKE receiver.
SampledMatched-Filter
Output
w1 w2 w3 wN
RAKEoutput
t
May 2003
Jai Balakrishnan et al., Texas InstrumentsSlide 5
doc.: IEEE 802.15-03/218r0
Submission
RAKE Design Parameters
There are two main parameters that need to be considered when designing a RAKE receiver for a multi-band system: The total number of RAKE fingers (see also 03/210r0) Span of the RAKE receiver.
The total number of RAKE fingers determines the RX digital complexity.
Span of the RAKE receiver determines the number of analog RX chains needed. Optimal RAKE finger placement does not need to be contiguous. Ex: 2 RAKE fingers can be separated by a considerable number of samples.
t
10 symbols
May 2003
Jai Balakrishnan et al., Texas InstrumentsSlide 6
doc.: IEEE 802.15-03/218r0
Submission
Design of a RAKE
Assumption: System #1: A 7-band multi-band system that transmits a 3.9 ns
pulse once every 7.8 ns in each sub-band (132 Msps). System #2: A 7-band multi-band system that transmits a 3.9 ns
pulse once every 3.9 ns in each sub-band (264 Msps). Impact of ISI is expected to be negligible and hence not considered.
A smaller RAKE span results in loss of collected multi-path energy.
Inherent trade-off: Number of RX chains vs. multi-path energy collection.
Symbol Rate
Rake Span for 1 RX Chain
Rake Span for 2 RX Chains
Rake Span for 3 RX Chains
132 Msps 7.8 ns 15.6 ns 23.4 ns
264 Msps 3.9 ns 7.8 ns 11.7 ns
Lynn Miller
have all black bullets come up at saem time and red text come up aftterwards
May 2003
Jai Balakrishnan et al., Texas InstrumentsSlide 7
doc.: IEEE 802.15-03/218r0
Submission
RAKE Design: No Group Delay (1)
Assumption: Synchronous hopping across the sub-bands. No group delay due to front-end filtering.
Optimal timing is typically not feasible with a single receive chain:
Reason: optimal sampling time for RAKE in sub-bands #2 and #3 overlap. Impossible to do with a single receive chain.
Transmit Receive
7.8 ns 7.8 ns
h(t)
Lynn Miller
have all black bullets come up at saem time and red text come up aftterwards
May 2003
Jai Balakrishnan et al., Texas InstrumentsSlide 8
doc.: IEEE 802.15-03/218r0
Submission
RAKE Design: No Group Delay (2)
To ensure that multi-path energy is collected across all sub-bands, we need to constrain the RAKE fingers to be in the same location regardless of the sub-band.
Location is chosen to maximize the overall received energy.
7.8 ns
Transmit Receive
7.8 ns
h(t)
7.8 ns
Lynn Miller
have all black bullets come up at saem time and red text come up aftterwards
May 2003
Jai Balakrishnan et al., Texas InstrumentsSlide 9
doc.: IEEE 802.15-03/218r0
Submission
RAKE Design: No Group Delay (3)
Assumptions: Ideal channel estimation. No front-end group delay variations. Zero switching time. Sample timing chosen to maximize
collected energy for “symbol” spaced sampling (264 MHz).
Normalized the channel impulse responses to unity to remove effects of shadowing/fading.
Captured energy averaged over 100 channel realizations.
Lynn Miller
have all black bullets come up at saem time and red text come up aftterwards
May 2003
Jai Balakrishnan et al., Texas InstrumentsSlide 10
doc.: IEEE 802.15-03/218r0
Submission
RAKE Design: No Group Delay (4)
Captured energy versus RAKE span for CM2 channel environment:
A 3 dB performance loss 30% loss in range.
Conclusion: to achieve less than 3 dB performance loss in CM2: Need 2 receive chains for a 132 Msps systems Need 3 receive chains for a 264 Msps systems.
Loss In Captured Multi-path
Energy
Number of RX Chains
for 132 Msps System
Number of RX Chains
for 264 Msps System
5.3 dB 1 1
3.9 dB 1 2
3.0 dB 2 3
2.4 dB 2 4
1.9 dB 3 5
1.5 dB 3 6
May 2003
Jai Balakrishnan et al., Texas InstrumentsSlide 11
doc.: IEEE 802.15-03/218r0
Submission
RAKE Design: No Group Delay (5)
Captured energy versus RAKE span for CM3 channel environment:
A 3 dB performance loss 30% loss in range.
Conclusion: to achieve less than 3 dB performance loss in CM3: Need 3 receive chains for a 132 Msps systems Need 5 receive chains for a 264 Msps systems.
Loss In Captured Multi-path
Energy
Number of RX Chains
for 132 Msps System
Number of RX Chains
for 264 Msps System
7.4 dB 1 1
5.1 dB 1 2
4 dB 2 3
3.3 dB 2 4
2.8 dB 3 5
2.4 dB 3 6
May 2003
Jai Balakrishnan et al., Texas InstrumentsSlide 12
doc.: IEEE 802.15-03/218r0
Submission
RAKE Design: Group Delay (1)
Consider a multi-band system whose operating bandwidth includes the U-NII band.
If a notch filter is used to suppress the interference from the U-NII band, then there could be significant group delay variations on sub-bands on either side of the notch.
Notch filter is one of the components that will result in group delay variations. Other components include antenna, LNA, etc.
May 2003
Jai Balakrishnan et al., Texas InstrumentsSlide 13
doc.: IEEE 802.15-03/218r0
Submission
RAKE Design: Group Delay (2)
Assumption: CM1 channel environment. Synchronous hopping across the
sub-bands. Due to group delay variations,
impulse response for sub-bands 4 and 6 are delayed by 3.9 ns relative to the other sub-bands.
Conclusions: With one RAKE finger, the loss in
performance is nearly 1 dB. However, as the number of RAKE
fingers increases the additional degradation due to group delay variations is small (also true for CM2, CM3, and CM4).
Lynn Miller
have all black bullets come up at saem time and red text come up aftterwards
May 2003
Jai Balakrishnan et al., Texas InstrumentsSlide 14
doc.: IEEE 802.15-03/218r0
Submission
Buildability Issues with Multiple RX Chains
Hardware penalty for multiple receive chains. Need to duplicate entire receive chain after LNA, including
mixer, VGA, channel select filter, and ADC. Increased die size, power consumption, and cost. Analog section does not scale with improvements in
technology node.
Potential issues: LNA loading results in a trade-off between bandwidth,
power, and noise figure. Cross-talk between receiver chains. Increased design time.
May 2003
Jai Balakrishnan et al., Texas InstrumentsSlide 15
doc.: IEEE 802.15-03/218r0
Submission
Conclusions
Studied RAKE span requirements for multi-band UWB systems.
Multi-band UWB systems need multiple RX chains for CM2, CM3 and CM4 environments.
If more than 1 Rx chain is used, the impact due to group delay variations is negligible.
Multiple receive chains results in a hardware penalty and has potential implementation issues.
