1 / 75

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: [ mmWave OFDM Physical Layer Proposal (Previously TensorCom Physical Layer Proposal)] Date Submitted: [ September 19, 2007 ]

kimball
Download Presentation

Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [mmWave OFDM Physical Layer Proposal (Previously TensorCom Physical Layer Proposal)] Date Submitted: [ September 19, 2007] Source:[Ismail Lakkis(1), BeomJin (Paul) Jeon(2), Pascal Pagani(3) , Ekhard Grass (4) , Shuzo Kato(5), Seongsoo Kim(6), Edwin Kwon(6), John Marshall(7), Chiu Ngo(6), Jisung Oh(6)] Company [ (1) Tensorcom, (2) LG Electronics Inc., (3) France Telecom, (4) IHP, (5) NICT, (6) Samsung Electronics, Co., Ltd, (7)SiBEAM, Inc.] Address [See Next Page for Contact Info.] Voice:[], FAX: [], E-Mail:[] Re: [This submission is in response to the TG3C call for Proposals (IEEE P802.15-07-0586-02-003c)] Abstract: [Physical layer proposal for IEEE 802.15 TG3C.] Purpose: [For considereation and discussion by IEEE 802.15 TG3C.] 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. Various Authors, TG3c Proposal

  2. Contact Information • Ismail Lakkis • Tensorcom Corporation • Voice: 858-231-9753 • Email: ilakkis@tensorcom.com • Beomjin (Paul) Jeon, & YongHoon Kim • LG Electronics Inc. • Voice : 82-2-526-4065 • Email : bjjeon@lge.com , yonghkim2002@empal.com • John Marshall • SiBEAM, Inc. • Voice : 408-245-3120 • Email : jmarshall@sibeam.com • Echard Grass • IHP • Email: grass@ihp-microelectronics.com • Pascal Pagani and Wei Li • France Telecome • Voice:+33-2-99-12-48-72 • Email: pascal.pagani@orange-ftgroup.com • Shuza Kato • NICT • Voice: +81-46-847-5083 • Shu.kato@nict.go.jp Various Authors, TG3c Proposal

  3. Contact Information • Seongsoo Kim, Edwin Kwon, Chiu Ngo, and Jisung Oh – Samsung Electronics Co., Ltd • 416 Maetan-3Dong, Youngtong-Gu, Suwon-Shi, Gyungki-Do 443-742, Korea • seongsoo1.kim at samsung dot com, cy dot kwon at samsung dot com, chiu.ngo at samsung dot com, jisung0714.oh at samsung.com • Gary Baldwin, Dengwei Fu, James P. K. Gilb, Jeff Gilbert, Ricky Ho, John Marshall, Steve Pope, Bernard Shung, Karim Toussi – SiBEAM, Inc. • 555 N Mathilda Ave Ste 100, Sunnyvale, CA 94085, +1 408 245 3120 • gbaldwin at sibeam dot com, dfu at sibeam dot com, gilb at ieee dot org, jgilbert at sibeam dot com, kpho at sibeam dot com, spope at sibeam dot com, bshung at sibeam dot com, kntoussi at sibeam dot com • Yasuhisa Nakajima – Sony Corporation • TV Business Group, Sony Corporation • jim dot nakajima at jp dot sony dot com Various Authors, TG3c Proposal

  4. mmWaveOFDM Physical Layer Various Authors, TG3c Proposal

  5. 2160 MHz 1728 MHz 120 MHz 240 MHz 1296 MHz 2 4 1 3 57 58 59 60 61 62 63 64 65 66 fGHz Frequency Band Plan Various Authors, TG3c Proposal

  6. PPDU Structure Transmit Order (from left to right) TIME STAMP (24 bits) SCRAMBLER ID (4 bits) MCS (6 bits) FRAME LENGTH (16 bits) CES MODE (1 bit) CP MODE (2 bits) PCES MODE (2 bits) PREAMBLE TYPE (2 bits) IFS MODE (2 bits) NUMBER OF SUBFRAMES (4 bits) UEP-MAPPING INDICATOR (1 bit) INTERLEAVER TYPE (1 bit) ANTENNA DIRECTION (8 bits) RESERVED BITS 151 bits T0:T23 0:23 S0:S3 24:27 M0:M5 28:33 L0:L15 34:49 CE0 50 CP0:CP1 51:52 PC0:PC1 53:54 P0:P1 55:56 I0:I1 57:58 N0:N3 59:62 U0 63 IT 64 D0:D7 65:72 R0:R150 73:223 PHY Header 28 octets MAC Header 10 Octets HCS 2 Octets RS Parity Symbols 16 Octets MAC SubHeader 80 Octets HCS 2 Octets RS Parity Symbols 16 Octets PLCP Preamble Frame Header PSDU 43Mbps, 171Mbps, 342Mbps, 684Mbps 58Mbps to 7.35Gbps Frame Payload 0-65535 Octets FCS 4 Octets Tail Bits 0(6) Pad Bits Various Authors, TG3c Proposal

  7. Frame control 2 Octets PNID 2 Octets DestID 1 Octet SrcID 1 Octet Fragmentation control 3 Octets Stream index 1 Octet MAC SubHeader Transmission direction 10 octets PHY Header MAC Header HCS RS Parity Symbols MAC SubHeader HCS RS Parity Symbols Subframe 1 subheader 40 bits Subframe 2 subheader 40 bits Subframe 16 subheader 40 bits MCS 6 bits CRC Present 1 bit Retransmission policy 2 bits MSDU Number 4 bits Fragment Number 4 bits Subframe Length 12 bits Subframe Information 2 bits Selective ACK Request 1 bit Reserved 8 bits Subframe contains • MSB/LSB • MSB • LSB • Request Sel-ACK • Follow ACK policy in MAC header Various Authors, TG3c Proposal

  8. Subframe 1 MSB FCS LSB FCS Subframes & Sel-ACK (Selective ACK) • Frame type = Sel-ACK • ACK policy = no-ACK PHY Header MAC Header HCS MAC SubHeader HCS Subframe 1 … Subframe n MSB LSB MSB LSB Indicate which part (MSB, LSB) has an error Subframe Various Authors, TG3c Proposal

  9. OFDM signaling Mode • Outer Reed Solomon (K+16,K) • Inner Hamming(12,8) PSDU Rates Header Rates Various Authors, TG3c Proposal

  10. Frame Format 512 chips ~ 197.5ns 32, 64, 96, & 128 CP OFDM Data Symbol CP OFDM Data Symbol CP OFDM Data Symbol 2 symbols PCES Data Block PCES Data Block PCES Data Block 128, 256 or 512 symbols when PCES is present PLCP Preamble PLCP Header PSDU Packet/Frame Sync Sequence 8, 4, or 2 symbols SFD Start Frame Delimiter CES Channel Estimation Sequence CES Channel Estimation Sequence 128 s512 s512 s512 -s512 aCP u512 bCP v512 Optional Extended CES (2 symbols) Various Authors, TG3c Proposal

  11. Rate-Dependent Parameters (LDPC) • RS encoded data bits with an outer RS(216,200) UEP Mode Various Authors, TG3c Proposal

  12. Rate-Dependent Parameters (Convolutional) Various Authors, TG3c Proposal

  13. Timing-Related Parameters * Allocated for PAPR and OOB power reduction Various Authors, TG3c Proposal

  14. Frame-Related Parameters (1) Duration is based on the default CP of 64 Various Authors, TG3c Proposal

  15. The Preambles Long: Tpre = 2.173ms, Npre = 11 Medium: Tpre = 1.383ms, Npre = 07 Short: Tpre = 0.790ms, Npre = 04 PLCP Preamble • Three preambles are defined: • Long preamble : 8 sync symbols, 1 SFD symbol, 2 CES symbols • Medium preamble : 4 sync symbols, 1 SFD symbol, 2 CES symbols • Short preamble : 2 sync symbols, 1 SFD symbol, 1 CES symbol • Different preamble lengths reduces overhead and latency and enable efficient beamforming • For data transmission, switching from long to medium or short preamble is upon device request. • First packet shall use the long PLCP preamble, the remaining packets may use either one of the three preambles. • When using medium or short preamble, packets shall be separated by MIFS. • For beamforming, different preamble lengths are used to maintain a balanced spreading gain-antenna gain • A unique preamble sequence set is assigned to each piconet within the same frequency channel (frequency & spatial reuse). Packet/Frame Sync Sequence 8, 4, or 2 symbols SFD Start Frame Delimiter CES Channel Estimation Sequence CES Channel Estimation Sequence 128 128 s512 s512 s512 -s512 aCP u512 bCP v512 aCP u512 bCP v512 Various Authors, TG3c Proposal

  16. The Preambles • Four preamble sequence sets (labeled by the parameter m) are provided for the purpose of frequency/spatial reuse • A preamble sequence set consists of a base sequence s512,m and two CES sequences u512,m and v512,m. • The length 512 base sequence s512,m is the Kronecker product of a length 4 cover sequence, c4,m and a length 128 modified Golay sequence u128,m. s512,m[n] = c4,m[floor(n/128)]×u128,m[n mod 128] n=0:511 • The cover sequences and modified Golay sequences are listed in Tables 1 & 2 respectively. • The base sequences occupy four non-overlapping frequency bin sets, and therefore are orthogonal in time and frequency domain. The mth base sequence occupies frequency bins m, m+4, m+8, m+12, … • Modified Golay sequences, are obtained from Golay sequences using time (or frequency) domain filtering to guarantee that only the used subcarriers are populated rather than the entire 512 subcarriers. Various Authors, TG3c Proposal

  17. + + + input - - - + + + + + + The Preambles • Golay complementary sequences (denoted a and b) of length N = 2M are specified by: • 1. A delay vector D of length M with distinct elements from the set 2m with m = 0:M-1; • 2. A seed vector W of length M with elements from the QPSK constellation (±1, ±j); • The receiver may use the efficient 2-levels (on I & Q) low-complexity Golay matched filter shown above for packet and frame detection. function [a,b] = golaySub(M,N,D,W); a = [1 zeros(1,N-1)];b = a; for m=1:M, ii = mod([0:N-1]-D(m),N); an = W(m)*a + b(ii+(1)); bn = W(m)*a - b(ii+(1)); a = an;b = bn; end; return; Various Authors, TG3c Proposal

  18. The Preambles • The length 512 CES sequencesu512,m and v512,m are modified complementary Golay sequences derived from Golay sequences a512,m and b512,m . They are listed in Table 3. • Modified complementary Golay sequences enable perfect channel estimation in both time and frequency domains • The Golay matched filter (shown before) can be used to provide simultaneously matched filter outputs to codes a and b. Combining the two outputs appropriately provide a perfect channel estimation in time domain; • Frequency domain channel estimation is done in the conventional way. The complementarity property is conserved in frequency domain. • OFDM systems can benefit from time-domain channel estimation due to dimensionality (ranking) issue; • The Pilot CES (PCES) field is an optional field. When present, it is equivalent to the CES field and is repeated periodically to allow channel tracking. Three periods are provided which correspond to pedestrian speeds of 1, 3, and 6m/s. Various Authors, TG3c Proposal

  19. Frame Header Encoding Process Various Authors, TG3c Proposal

  20. The PHY Header TIME STAMP (24 bits) SCRAMBLER ID (4 bits) MCS (6 bits) FRAME LENGTH (16 bits) CES MODE (1 bit) CP MODE (2 bits) PCES MODE (2 bits) PREAMBLE TYPE (2 bits) IFS MODE (2 bits) NUMBER OF SUBFRAMES (4 bits) UEP-MAPPING INDICATOR (1 bit) INTERLEAVER TYPE (1 bit) ANTENNA DIRECTION (8 bits) RESERVED BITS 151 bits T0:T23 0:23 S0:S3 24:27 M0:M5 28:33 L0:L15 34:49 CE0 50 CP0:CP1 51:52 PC0:PC1 53:54 P0:P1 55:56 I0:I1 57:58 N0:N3 59:62 U0 63 IT 64 D0:D7 65:72 R0:R150 73:223 Various Authors, TG3c Proposal

  21. Transmitter Reference diagram Pad Bits (zeros) Frame Payload FCS Append & Scramble Scrambled Frame Payload LENGTH octets Scrambled FCS 32b Scrambled Pad Bits Npad bits FEC Coder, Puncturer & Interleaver QPSK/QAM Mapper Preamble, Pilot/DC Insertion Tone Interleaver Scrambled PSDU MixedSig, Analog & RF LPF Symbol Shaper OFDM Modulator Various Authors, TG3c Proposal

  22. Serial Data In Scrambled/Descrambled Serial Data Out vn sn xn xn-1 xn-14 xn-15 D D D D The Scrambler matlab code function [dataOut] = tcScrambler(dataIn,a,b,c,d) shiftRegister = [1 1 0 1 0 0 0 0 1 0 1 a b c d]; fork = 0:length(dataIn) -1, feedback = xor( shiftRegister(13+(1)) , shiftRegister(14+(1)) ); dataOut(k+(1)) = mod(dataIn(k+(1))+feedback , 2); shiftRegister = [feedback shiftRegister([0:13]+(1))]; end; return; Various Authors, TG3c Proposal

  23. X Y Message block Input: m0, m1, …, mK-1 X gM-2 rM-1 Y First to enter encoder gM-1 Last out from encoder X Y r0 g0 r1 g1 CRC: rM-1, rM-2…, r0 rM-2 g2 The FCS & HCS • Encoding Operation • Step 1. Reset Shift Register (SR) to all ones. • Step 2. The 3 switches are placed in position X and the K bits are fed into the encoder. • Step 3. After the last bit (m0) has been fed into the Shift Register (SR), the switches are moved to position Y. At this point the SR contains the CRC bits. These bits are then shifted out of the SR and complemented. • CRC • MAC frame payload FCS generator polynomial (M = 32): g(x) = x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7 + x5 + x4 + x2 + x + 1 = [111011011011100010000011001000001] • PLCP Header HCS generator polynomial (M=16): g(x) = x16 + x12 + x5 + 1 = [10000100000010001] • MAC payload or PLCP Header message polynomial: m(x) = m0 + m1 x + ... + mK-1xK-1 With (mK-1 = lsb of first octet of MAC payload or PLCP Header) • matlab code (indexing from 1 rather than 0) • r = ones(1,M); • for k = 1:K, • f = mod(d(k) + r(M),2); r = mod([0 r(1:M-1)] + f*g(1:M),2) • end; • r = xor(r(M:-1:1),1) Various Authors, TG3c Proposal

  24. rT-1 gT-1 g3 r0 g0 r1 g1 r2 r3 rT-2 g2 The Reed Solomon FEC over GF(28) RS(K+16,K) & RS(K+8,K) • RS(K+16,K) : N = 255, T = 16 • RS(K+8,K) : N = 255, T = 8 X Y Message block Input: m0, m1, m2, … , mN-T-1 X X Y Y First to enter encoder Last out from encoder Code Word Output: mN-T-1, … , m2 , m1 , m0, rT-1, …, r0 Example matlab code (255,239) Data = round(rand(8,239)) data = (2.^[0:7])*data parity = rsenc(gf(data,8),255,239); parity = parity(:,end-15:end); parity = reshape(de2bi(parity,8)',1,128); code = [data parity]; Various Authors, TG3c Proposal

  25. FEC Option I: RQ-LDPC • No interleaving is required • Supports rates ½, ¾, and 7/8 • Very low complexity systematic encoder • Low complexity highly parallelizable decoder (gate count ~ 105Kgates) • Throughput matched to that of RS • 1 RS and 1 LDPC Decoder engine is needed for LDR devices • Throughput of ~ 6 Gbps with Master clock of 324 MHz (BW/8) and 32 iterations Various Authors, TG3c Proposal

  26. FEC Option I: RQ-LDPC Various Authors, TG3c Proposal

  27. FEC Option I: RQ-LDPC • Parity check matrix H is specified by an exponent matrix E, i.e. H = JE • Matrix J is the cyclic shift of the 21x21 Identity matrix, i.e. • J = 0; J0 = I; J21 = I E78: Rate 7/8 E34: Rate 3/4 Various Authors, TG3c Proposal

  28. FEC Option II: RQ-Convolutional • Inner convolutional codes combined with outer Reed Solomon codes • Outer-interleaver in-between : 4x224 bytes block interleaver • Outer code rate : RS(224, 216) 8 parallel encoders Convolutional Encoder MSB RS Encoder Outer Interleaver Demux 1:4 Bit Interleaver MUX 8:1 Convolutional Encoder RS Encoder Outer Interleaver Demux 1:4 LSB Convolutional Encoder Various Authors, TG3c Proposal

  29. FEC Option II: RS-Convolutional Convolutional Encoder & Puncturer Convolutional encoder : R = 1/3, K = 7 Generator polynomial : g0=1338, g1=1718, g2=1658 Various Authors, TG3c Proposal

  30. FEC Option II: RS-Convolutional • Data multiplexer combines data from all convolutional encoders • EEP Mux/interleaver • Bit interleaver size: 48 • A1…A6 come from encoder A, and similarly for BCDEFGH Various Authors, TG3c Proposal

  31. FEC Option II: RS-Convolutional • UEP-Mapping Mux/Interleaver • Overall bit interleaver size 48 Various Authors, TG3c Proposal

  32. FEC Option II: RS-Convolutional • UEP-Coding Mux/Interleaver • Overall bit interleaver size 96 • For first half cycle of 48 bits: A1…A7 come from encoder A, similarly for BCD; E1…E5 come from encoder E, similarly for FGH • For second half cycle of 48 bits: A1…A7 come from encoder A, similarly for BCD; E1…E5 come from encoder E, similarly for FGH Various Authors, TG3c Proposal

  33. Binary Interleaving • Optimized binary interleaver based on an iterative structure [1-4] • Effectively maximizes both intra- and inter- symbols interleaving spreading • Efficiently improves decoder performance Various Authors, TG3c Proposal

  34. Initial block of K coded bits Successive iterations k I I I Iterative Block Interleaving Various Authors, TG3c Proposal

  35. Qk b4kb4k+1b4k+2b4k+3 00 10 01 10 11 10 10 10 +3 00 11 01 11 11 11 10 11 +1 -3 -1 +1 +3 Ik 00 01 01 01 11 01 10 01 -1 00 00 01 00 11 00 10 00 -3 The Constellation Mapper Qk b2kb2k+1 10 11 QPSK encoding table +1 -1 +1 Ik 00 01 -1 16-QAM mapping Various Authors, TG3c Proposal

  36. The Constellation Mapper 64-QAM mapping Qk b6kb6k+1b6k+2b6k+3b6k+4b6k+5 000 100 001 100 011 100 010 100 110 100 111 100 101 100 100 100 +7 000 101 001 101 011 101 010 101 110 101 111 101 101 101 100 101 +5 000 111 001 111 011 111 010 111 110 111 111 111 101 111 100 111 +3 000 110 001 110 011 110 010 110 110 110 111 110 101 110 100 110 +1 -7 -5 -3 -1 +1 +3 +5 +7 Ik 000 010 001 010 011 010 010 010 110 010 111 010 101 010 100 010 -1 000 011 001 011 011 011 010 011 110 011 111 011 101 011 100 011 -3 000 001 001 001 011 001 010 001 110 001 111 001 101 001 100 001 -5 000 000 001 000 011 000 010 000 110 000 111 000 101 000 100 000 -7 Various Authors, TG3c Proposal

  37. Skewed Constellation for UEP-Mapping LSB = b1 QPSK MSB = b0 LSB = b1,b3 MSB = b0, b2 16-QAM Various Authors, TG3c Proposal

  38. The Tone Interleaver • Normal FFT requires a bit-reversal operation before “butterflying” • Bit-reversal interleaving pattern can be combined with FFT operation to reduce complexity • Interleaving Rule : Various Authors, TG3c Proposal

  39. The OFDM Modulator IFFT Inputs & Outputs • CP Default value is 64, Optional: 32, 96, & 128 IFFT s512-CP … s511 s0 s1 … s510 s511 0 0 Null 1 Null 1 2 #2 2 #3 3 3 #177 177 177 178 178 Reserved Reserved 185 185 Guard 186 186 Frequency Domain Inputs Time Domain Outputs Guard 326 326 327 Free 327 334 Free 334 335 #-177 335 509 #-3 509 510 #-2 510 511 NULL 511 Subcarrier frequency allocation: 16 groups, 22 subcarriers per group (21 data & 1 pilot) 0 -2 -1 +1 +2 -34 -35 -99 -90 -89 -79 -78 -77 -68 -67 -57 -56 -55 -46 -45 -36 -24 -23 -13 -11 -12 +57 +11 +12 +13 +23 +24 +33 +34 +35 +45 +46 +55 +56 +67 +68 +77 +78 +79 +89 +99 +90 -177 -167 -166 -165 -156 -155 -145 -144 -143 -134 -133 -123 -122 -121 -112 -111 -101 -100 +101 +111 +112 +121 +122 +123 +133 +134 +143 +144 +145 +156 +157 +165 +166 +167 +177 +100 Various Authors, TG3c Proposal

  40. Optional Beamforming I Various Authors, TG3c Proposal

  41. Beamforming Requirements • A unified messaging protocol that supports : • 1. Different antenna configurations on either side (Tx or Rx): • Omni or quasi-omni antennas • Directional single antenna • Switch diversity antennas • Sectored antennas • Beamforming antennas • Etc,… • 2. Both pro-active and on-demand beamforming • 3. Different usage models • Per packet beamforming from PNC to multiple DEVs and DEVs to PNC • PNC to one DEV • DEV-DEV • Others,… • The unified messaging protocol should be independent of the specifics of the beamforming algorithm and antenna configuration implementation. Therefore, the actual beamforming algorithm will be left to the implementer. • However, the tools enabling the beamforming should be defined. These tools should support all scenarios while enabling: • 1. Reduced latency • 2. Reduced overhead • 3. Fast beamforming Various Authors, TG3c Proposal

  42. Beamforming tools • Four type of packets can be used during beamforming; • These packets are SC packets based on the CM (common mode) and therefore can be decoded by all DEVs; • Most packets have no body. i.e. preamble only; • Usage example: • Quasi-Omni transmission with 0~3dB antenna gain: uses type I • Directional transmission with 3~6dB antenna gain: uses type II • Directional transmission with 6~9dB antenna gain: uses type III • Directional transmission with 9~12 dB antenna gain: uses type IV Various Authors, TG3c Proposal

  43. Pro-Active Beamforming MIFS SIFS or MIFS Beacon Period for Superframe # m • Pro-active beamforming is useful when the PNC is the source of data to one or multiple DEVs. • Usage model example: Kiosk, STB, Laptop: • The PNC is the source of data to multiple DEVs; • The PNC can send each packet in a different direction, optimized to the destined device. Q-Omni Beacon #1 Q-Omni Beacon #2 Q-Omni Beacon #L Directional Beacon #(m-1)×N+1 Directional Beacon #(m-1) ×N+2 Directional Beacon #m×N Superframe # m Beacon Period CAP (Contention Access Period) CTAP (Channel Time Allocation Period) COMPA Requested to Add optional Directional-CAPs as well to align with their beamforning Q-CAP #1 Q-CAP #2 Q-CAP #L Packet To User #1 Direction #j1 Packet To User #2 Direction #j2 Packet To User #L Direction #jL SIFS or MIFS Various Authors, TG3c Proposal

  44. Pro-Active Beamforming Beacon Period for Superframe # 1 Q-Omni Beacon #1 Q-Omni Beacon #2 Q-Omni Beacon #L Directional Beacon #1 Directional Beacon #2 Directional Beacon #N • The first L transmissions in each superframe use Quasi-Omni (Q-Omni) beacons that together provide a Quasi-omni pattern; • For a PNC capable of a Quasi-omni coverage, L = 1; • For a PNC with sectored antennas, L would be the number of sectors; • For a PNC with switching transmit diversity antennas, L would be the number of transmit antennas; • It is assumed that the PNC can beamform in J = N×M directions; • A direction does not necessarily mean a single beam; it can be any number of beams. • The directional beacons are distributed over M superframes with N directional beacons per superframe; • The structure is periodic of period M superframes; • The CAP is divided into L sub-CAP periods corresponding to the L Q-omni beacons. During the lth Q-CAP, the PNC antenna is in the same direction it used to transmit the lth Q-Omni beacon. Beacon Period for Superframe # 2 Q-Omni Beacon #1 Q-Omni Beacon #2 Q-Omni Beacon #L Directional Beacon #N+1 Directional Beacon #N+2 Directional Beacon #2×N Beacon Period for Superframe # M Q-Omni Beacon #1 Q-Omni Beacon #2 Q-Omni Beacon #L Directional Beacon #(M-1)×N+1 Directional Beacon #(M-1)×N+2 Directional Beacon #M×N Various Authors, TG3c Proposal

  45. Pro-Active Beamforming • The first L beacons may be of any packet type. For example: • Omni beacons shall use packet type I with long preamble; • Q-Omni beacons using sectored antennas or antenna arrays with say 3-6dB gain may use type I or type II; • Q-Omni beacons using sectored antennas or antenna arrays with say 6-9dB gain may use type I, type II, or type-III; … • When used, the packet type shall be indicated in the SFD. Upon SFD detection, DEV knows the header and data rates and can decode the packet; • Each Q-Omni shall carry the beamforming IE (Information element); indicated in the next slide; in addition to the default information required by 802.13b; • The new information element would inform all devices listening to the PNC about the exact structure of the beamforming beacons; • After a DEV decodes any one of the Q-omni beacons during any superframe, it is capable of understanding the entire beamforming cycle; • Each directional beacon consists of a preamble only, i.e. it contains no header or data body; Various Authors, TG3c Proposal

  46. Pro-Active Beamforming Piconet synchronization parameters field format: 21+3n octets Beamforming Information Element Beamforming Information Element Format Directional Beacon PLCP Preamble Type I, II or III Various Authors, TG3c Proposal

  47. Pro-Active Beamforming Examples • O-DEV (Omni DEV), fast way: • An O-DEV may chose to listen to the Q-omni beacons of only one superframe; • Upon detection of the Q-omni beacons, the O-DEV stores a Link-Quality Factor (LQF) for each of the Q-omni beacons, than it sorts these L LQFs [LQF(1), …, LQF(L)] and identify the best PNC direction l corresponding to the highest LQF; l = arg{max[LQF(i)]} i=1:L • DEV associates with the PNC during the lth CAP of the current superframe, and informs the PNC that all further communications should happen with the PNC using its lth Q-omni direction; • DEV can still choose to track the set of Ls best directions by monitoring the corresponding Q-omni beacons every Q superframes. If a direction, say the rth Q-omni direction, is found with a better LQF, DEV can choose to inform the PNC to transmit the next packet using the rth Q-omni direction by encoding it in the “NEXT DIRECTION” filed in the PHY header. • Q-DEV (Single Directional Antenna): • An SD-DEV may choose to listen to the entire cycle of M superframes; • If a DEV starts listening during the mth superframe, than upon detection of one of the Q-Omni beacons, it will learn that this is the mth superframe, and will listen to superframes number: m, m+1, … , m+M-1; • During this cycle of M superframes, SD-DEV can measure, store, and sort J LQFs corresponding to the J directional PNC directions. During the same cycle, it measures the L LQFs corresponding to the L Q-omni PNC directions. Denote by j the best directional direction and by l the best Q-omni direction. • DEV associates with the PNC during the lth CAP of the (m+M-1)th superframe, and informs the PNC that all further communications should happen with the PNC using its jth directional direction; • DEV can still choose to track the set of Js best directions by monitoring the corresponding directional beacons every Q×M superframes. If a direction, say the rth directional direction, is found with a better LQF, DEV can choose to inform the PNC to transmit the next packet using the rth directional direction by encoding it in the “NEXT DIRECTION” filed in the PHY header. Various Authors, TG3c Proposal

  48. Pro-Active Beamforming Examples • D-DEV (Directional DEV) capable of transmitting/receiving in at least one Q-omni direction and I directional directions: • D-DEV starts with its antenna in one of the Q-omni directions; • If the D-DEV starts listening during the mth superframe, than upon detection of one, or the best, Q-Omni beacon (say Q-omni beacon number l) , it will learn that this is the mth superframe; • DEV can choose to do one of the following options: • Lazy approach: DEV listen to I×J superframes, J superframes for each of its I directions as follows: • DEV sets its directional direction to number 1, than listens to M superframes number: m, m+1, … , m+M-1 and store and sort the corresponding J LQFs, LQF(1,1)…LQF(1,J) where the first index refers to the DEV’s direction whereas the 2nd index refers to the PNC’s direction; • DEV sets its directional direction to number 2 and listen to the next superframes and store the J LQFs: LQF(2,1) ... LQF(2,J); • … • DEV sets its directional direction to number I and listen to the next M superframes and store the J LQFs: LQF(2,1) ... LQF(2,J). • DEV finds the best directional combination (i,j) referring to DEV using its ith directional direction and PNC using it jth directional direction. • DEV associates to PNC during the lth Q-CAP period and informs the PNC of the best direction (or best Js combinations). • Fast approach: • DEV sets its directional direction to number 1, than listens to the N directional beacons during the current superframe. If a direction, say jth PNC directional direction, with adequate LQF is found than DEV will associate to the PNC during the lth Q-CAP period and informs the PNC to use its jth direction for data communication. DEV can still choose to scan for better directions. If one is found it can inform the PNC to switch to the new direction by encoding appropriately the field “NEXT DIRECTION” in the PHY header. • If no adequate direction is found, than DEV switches to another direction, for example direction r, which is orthogonal to direction 1. and listen to the next superframe. If no adequate direction is found, DEV can switch to another direction and continue the search until an adequate direction is found. Various Authors, TG3c Proposal

  49. DEV starts on Direction i=1 and set m=0, and timer t=0 Optional: DEV sorts matrix LQF And keep the best Q directions in decreasing order (i1,j1), (i2,j2), … (iQ,jQ) While t < Tmax, DEV looks for a Q-Omni BF Detection Successful? No: Device starts PNC or go to sleep Optional: DEV listens to another I×M SFs And rescan these best Q directions For verification Yes: Locked to Q-Omni #S DEV reads Beacon information. (DEV now knows L, J, N, M, SF timing and all timing parameters of all BFs) DEV switches to Direction 1, set y=0 Yes DEV restarts Scan y = Y ? y = y + 1 NO Knowing the timing of directional Beacons, DEV listens and detect directional BFs on SF#m. Device stores Link quality Factors: LQF(i,(m-1)×N+1), … , LQF(i,(m-1)×N+N) DEV transmits during Q-CAP listening period #l on SF #y & requests that all further communications are exchanged using direction j1 for PNC NO m = M ? m = m + 1 Device waits for an ACK from PNC YES i = i + 1 & before start of next SF, DEV switched to direction i Successful ACK ? NO YES i = I ? Device switches to Direction i1, and ADD is SUCCESSFUL Pro-Active Beamforming: Lazy ADD Algorithm Various Authors, TG3c Proposal

  50. On-Demand Beamforming • On-demand beamforming is the beamforming of choice between two DEVs or between PNC and one DEV. Since the details are the same, we describe the case of the two DEVs; • On-demand beamforming will take place in the CTA allocated to the link between the TWO DEVs; • When a DEV is talking to multiple DEVs, the same messaging protocol as the pro-active beamforming messaging protocol is used. In this case, the CTA will play the role of the beacon period during the beamforming phase, and will be used for data communication thereafter. • For the case of two DEVs only, since the CTA is a direct link between them, it is possible to devise a more collaborative and interactive on-demand beamforming messaging protocol; Various Authors, TG3c Proposal

More Related