Doc.: IEEE 802.22-06/0128r1 Submission September 2006 Ed Callaway, MotorolaSlide 1 A Proposal for the 802.22.1 Standard IEEE P802.22 Wireless RANs Date:

September 2006

Ed Callaway, Motorola

Slide 1

doc.: IEEE 802.22-06/0128r1

Submission

A Proposal for the 802.22.1 StandardIEEE P802.22 Wireless RANs Date: 2006-09-18

Name Company Address Phone email Ed Callaway Motorola 8000 W. Sunrise Blvd., M/S 2141,

Plantation, Florida 33322 USA +1-954-608-7537 [email protected]

Paul Gorday Motorola 8000 W. Sunrise Blvd., M/S 2141, Plantation, Florida 33322 USA

+1-954-723-4047 [email protected]

Dave Silk Motorola 1303 E Algonquin Rd., 4th Floor Schaumburg, Illinois 60196 USA


Greg Buchwald Motorola 1301 E Algonquin Rd., M/S 2921 Schaumburg, Illinois 60196 USA


Steve Kuffner Motorola 1301 E Algonquin Rd., M/S 2912 Schaumburg, Illinois 60196 USA


Monique Brown

Motorola 1150 Kifer Road, Suite 100, Sunnyvale, California 94086 USA


Authors:

Notice: This document has been prepared to assist IEEE 802.22. 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 grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.22.

Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures http://standards.ieee.org/guides/bylaws/sb-bylaws.pdf including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair Carl R. Stevenson as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE 802.22 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at [email protected].>

September 2006


Slide 2

doc.: IEEE 802.22-06/0128r1

Submission

Abstract

We propose a beacon protocol for the IEEE

802.22.1 Enhanced Detection of Part 74 Devices

standard. Novel features of this proposal

include a “burst-beacon” PHY layer structure

to address multipath propagation effects,

interbeacon communication, and AES-based

beacon authentication.

September 2006


Slide 3

doc.: IEEE 802.22-06/0128r1

Submission

Changes from rev. 0• Faster signaling→ new <2.5 ms burst duration

– New bit rate (9.6091 kbps)

– New chip rate (76.873 kcps)

– New PN code (8 chips long instead of 16)

– Beacons now sent every 1 s

– Can detect full burst during 5 ms US frame (Rx for BS) or DS frame (Rx for CPE) in off-channel sensing (no sensing during Tx required)

– Can despread one full bit in < 200 s (< 1 OFDMA quiet baud for fast sensing)

• Inter-device communication now done via beacons– New RTS/ACK scheme

– Frees spectrum

• 6 byte channel occupancy bitmap added

September 2006


Slide 4

doc.: IEEE 802.22-06/0128r1

Submission

PHY

September 2006


Slide 5

doc.: IEEE 802.22-06/0128r1

Submission

PHY Philosophy

The conflict between– Available transmission time (≤ 5 ms)– Amount of data to be sent (~ 50 bytes)– Available spectrum bandwidth (< 200 kHz)– Required sensitivity (as good as possible)– Required range (≥ 10 km)

is the critical issue in the 22.1 beacon design.

September 2006


Slide 6

doc.: IEEE 802.22-06/0128r1

Submission

Specifically…

Sending 50 bytes in 5 ms requires a data rate of 80 kb/s, or a bit length of 12.5 s.

Path loss aside, a path of even 10 km has a propagation delay of 33 s, so multipath is a significant issue.

Multipath mitigation methods, such as equalization and OFDM, add undesirable complexity.

September 2006


Slide 7

doc.: IEEE 802.22-06/0128r1

Submission

The Burst-Beacon Design (1)

Our solution is to transmit a continuous series of 24-bit “bursts” before the beacon, containing only a sync word and a decrementing index. – Since only 24 bits are sent in the burst, the symbol time is long

enough (104 s) to ameliorate multipath and sensitivity concerns– To assist simultaneous cyclostationary detection of both systems,

the symbol rate is selected to be 9.6091 kBaud, the ATSC symbol rate divided by 1120 = 32 × 7 × 5.

– From the index, the WRAN determines when the beacon will be sent, and schedules a receiving frame accordingly.

Rx period

BURSTS

Sync N Sync N-1 Sync 1 Sync 0… Sync NANP …

Frame period

BEACON

BEACON PSDU

Length

September 2006


Slide 8

doc.: IEEE 802.22-06/0128r1

Submission

The Burst-Beacon Design (2)

For fading protection, a wider (spread) signal is desirable. We propose DSSS with an 8-chip pn sequence (augmented 7-chip m-sequence), with fchip = 76.873 kchip/s (= ATSC / 140).– Bandwidth still < 200 kHz

– Simple implementations possible

Beacon placed on the ATSC pilot frequency, 309.440559 kHz above channel edge; 2 ppm stability ; DBPSK modulation

Rates and location to vary based on local TV standard

Rx period

BURSTS: Each 24b, 2.497 ms

Sync N Sync N-1 Sync 1 Sync 0… Sync NANP …

0.999063 s Frame period

BEACON: 51 bytes, 42.260 ms

BEACON PSDU

Length

September 2006


Slide 9

doc.: IEEE 802.22-06/0128r1

Submission

Burst Design

Synchronization word is a 15-bit m-sequence

15-bit synchronization makes falsing on noise unlikely – Rate in simulation less than one per day

9-bit index word sufficient for 512 bursts – Maximum of 382 bursts actually sent every 0.999063 s

INDEXSYNCHRONIZATION

15 bits 9 bits

~2.497 ms

September 2006


Slide 10

doc.: IEEE 802.22-06/0128r1

Submission

Rx period

Interbeacon Communication

Rx period

20b, 2.081 ms

Sync 0 Sync NANP …

4b, 0.416 ms

24b, 2.497 ms

16bRTS

2b, 0.208 ms

Primary

Secondary

•Secondary sends 16b RTS burst (4b sync and 12b codeword) during 20b Rx

period of Primary

•Primary sends Ack (1010 bit pattern) in 4b Ack/Nack Period (ANP)

•Primary sends sync bursts N to 1

•Secondary sends its beacon PPDU during beacon time of Primary

•Secondary monitors future primary beacons to ensure data is there

RxSync 1

Sync 0

ANP

RxRx

BEACON PSDU

Length

BEACON PSDU

Length

September 2006


Slide 11

doc.: IEEE 802.22-06/0128r1

Submission

0 2 4 6 8 10 1210

-5

10-4

10-3

10-2

10-1

100

Eb/No (dB)

Pac

ket

Err

or R

ate

Sync Burst

Beacon Frame

Burst and Beacon Error Rates (AWGN)

More info:06/0171r0

September 2006


Slide 12

doc.: IEEE 802.22-06/0128r1

Submission

Beacon Detection Error Rates (Fading)

0 5 10 15 20 25 30 35 4010

-5

10-4

10-3

10-2

10-1

100

Eb/No (dB)

Pac

ket

Err

or R

ate

(48-

byte

bea

con

fram

e)

No Fading

Profile A

Profile BProfile C

Flat Rayleigh Fading

More info:06/0171r0

September 2006


Slide 13

doc.: IEEE 802.22-06/0128r1

Submission

Beacon-to-Beacon Interference

0 1 2 3 4 5 6 70

1

2

3

4

5

6

7

8

9

Chip offset between signal and interferer

C/I

req

uire

d fo

r 1%

PE

REb/No=13dB

Eb/No=30dB

More info:06/0171r0

September 2006


Slide 14

doc.: IEEE 802.22-06/0128r1

Submission

Exemplary Implementations

D

DifferentialEncoder

Bits

SpreadingChip Pulse

ShapingBPSK

Modulation

RF

PN Generator Osc.

Modulator

Demodulator

DownConversion

RF

Osc.

ChipMatched Filter

D

DifferentialDetector

Bit Sync

Bit Sampling

Bits

Bit DecisionPN Sequence

Correlator

September 2006


Slide 15

doc.: IEEE 802.22-06/0128r1

Submission

MAC

September 2006


Slide 16

doc.: IEEE 802.22-06/0128r1

Submission

Beacon Frame Format

Description Length in bytes Length in bits

PHY layer (sync word + index + PHY header) 4 32

Parameter 1: Frame version number/Priority Level/Height of System Antenna (AGL)/Rank

1 3/3/1/1

Parent Callsign (Designator) 8 64

Location 8 64

Time stamp (GPS time) 6 48

Parameter 2: Reserved/Keep Out Zone 1 7/1

Parameter 3: Indoor-Outdoor (outdoor by default)/Required need timer 1 1/7

Subchannel Map: Bitmap of occupied subchannels 6 48

Frame Payload (valid range: 0 ≤ n ≤ 78 bytes) - -

Message Integrity Code (AES-128 Authentication) 16 128

Total (plus Payload) 51 408

Octets: 1 8 8

Frame

Payload

Parameter

3

Parameter

2

Timestamp

Location

Parent

Callsign

Parameter

1

n 6 1 1

MHR MAC payload

Message Integrity

Code

16

MFR

Sub-

channel Map

6

September 2006


Slide 17

doc.: IEEE 802.22-06/0128r1

Submission

SecurityTo protect WRANs from abuse by malicious persons, spoofing

or replaying of the beacon must be inhibited

This is typically done by appending a cryptographic Message Integrity Code (using symmetric key techniques) or a Digital Signature (using public key techniques) to the beacon

Since they do not share a secret key with the WRAN, public key techniques are preferred by incumbents

However, the best public key signature techniques known to the authors require a signature length of at least 32 bytes

We therefore propose a symmetric key technique that requires a message integrity code of only 16 bytes

We remain open to public key proposals

September 2006


Slide 18

doc.: IEEE 802.22-06/0128r1

Submission

Beacon Authentication

Spoofing of the beacon is inhibited by use of a 128-bit, AES-based, cryptographic Message Integrity Code (MIC), appended to the clear text– WRAN looks up key in restricted-access database, using value of

beacon’s Parent Callsign field as index

– Calculates MIC based on clear text and key; compares with received MIC

– If calculated MIC and received MIC match, beacon is authenticated

– Timestamp provided to eliminate replay attacks

– Does not provide encryption

September 2006


Slide 19

doc.: IEEE 802.22-06/0128r1

Submission

Beacon MAC Functional Description

Upon initialization, a protected device monitors the channel for beacons.– If none is detected, it starts its beacon transmission.

– If one or more is detected, the device optionally contacts the beaconing device(s) by interbeacon communication• It asks the beaconing device to send its information, too

• The beaconing device then adds this additional information in its beacon payload

– It may also elect to transmit its own beacon instead• For example, if it determines that it is unlikely that the transmitting

beacon will provide it adequate protection– Likely the case, if it has WRAN interference and can hear a beacon

September 2006


Slide 20

doc.: IEEE 802.22-06/0128r1

Submission

MAC Flow Chart (with some upper layer help)

Set beacon rank to TRUE

Transmit beacon

Co-located beacon detected?Y

N

Initialize beacon unitand read parameter set

= User interface function

Listen to burst-beacon channel for co-located

beacon activity

Parameter Defaults:- Reference Mode = FALSE

Y

N

Proposed commands for interbeacon communication:- DISABLE COMMAND – notify beacon to disable

transmit operation on burst-beacon channel- Merge COMMAND – aggregate parameter set

Via interbeaconCommunication, merge

parameter set

Bursts Beacon1s

42msVia interbeacon communication, request to

merge parameter set

Merge parameterset permitted?

Beacon received?

Y

A

B

Transmission on burst-beacon channel

DISABLED?

N

AY

Beacon rank set to TRUE?

Y

N

B

N

Follow predetermined policy to (ENABLE/DISABLE)

transmissionTransmission DISABLED?

A

Y

B

N

Send to next higher layer

New beacon received from

next higher layer?

Update beacon

N

Y

September 2006


Slide 21

doc.: IEEE 802.22-06/0128r1

Submission

Beacon Aggregation Caution

• Aggregated beacons are desired for spectral efficiency in microphone deployments

• However, if a WRAN discovers a primary beacon and abandons the channel prior to aggregation of a tardy secondary beacon, the WRAN will not be aware of the aggregated information

• If the secondary beacon is protecting devices on a separate channel, the WRAN will not be aware of them unless it revisits the primary beacon and demodulates a full PSDU

• For this reason we recommend that a beacon protect its own channel for some time prior to aggregating with existing beacons

September 2006


Slide 22

doc.: IEEE 802.22-06/0128r1

Submission

Enhancements and Extensions

Our proposal has benefited greatly from comments received from the 22.1 TG

We encourage others to propose enhancements and extensions to this proposal

For example, we are intrigued by ideas proposed by Baowei Ji and his colleagues at Samsung– E.g., the use of QPSK and a complex signaling channel

• Sending the bursts and beacon in parallel

– Not yet simulated

September 2006


Slide 23

doc.: IEEE 802.22-06/0128r1

Submission

Conclusion

Because of the unique function and requirements of the 802.22.1 beacon, its PHY and MAC design must also be unique

The combination of– The burst-beacon PHY, for long range detection

– Communication between protecting devices

– AES-based beacon authentication

produces a beacon protocol that meets today’s needs, with the flexibility for future growth.

September 2006


Slide 24

doc.: IEEE 802.22-06/0128r1

Submission

802.22.1 RFP Requirements Table (1)Means to identify operator of 802.22.1 protection system

Parent Call Sign field in beacon

Means to authenticate beacon 128-bit, AES-based Message Integrity Code in beacon

Means to signal the presence of, and identify channels in use by, wireless microphones associated with the beacon and operating in close proximity to the beacon

Subchannel bitmap transmitted in the beacon; provision for multiple protecting device information to be included in one beacon

Optional means to provide a channel coordination function

Communication via beacons

Transmitter specifications DSSS; 9.6091 kBaud; 76.873 kc/s; Part 74 compliant (max. 250 mW)

Optional means to identify the location of low power licensed device operation

Location field in beacon

Means to alleviate the effect of transmission channel fading and distortion

Low symbol rate; DSSS

Means to optimize spectrum usage by multiple beacons operating in close proximity

Communication between protecting devices via beacons

September 2006


Slide 25

doc.: IEEE 802.22-06/0128r1

Submission

802.22.1 RFP Requirements Table (2)Identify a means to aggregate wireless microphone channel use data. Identify the location of other beacons

Communication between protecting devices via beacons; location field in beacon

Means to allow the beacon to sense microphones operating in close proximity and automatically report those channels it finds in use

Communication between protecting devices via beacons; location field and channel use subfield in beacon

Meet Part 74 in the USA Part 74 compliant

Address international requirements that are similar to Part 74 protections in the USA

Compliant

Identify any issues that may require regulatory support

None known (other than reuse of the TV bands, period)?

Method by which TG1 will be able to assess the protection provided by proposed solution

Over a path that produces threshold-level interference to the protected device from the WRAN, determining that the signal of the proposed beacon is detectable (slide 10)

Issues of interest that may enable improved protection from interference by a WRAN system while minimizing impact on the WRAN

Sophisticated use of communication between protecting devices; use of countdown timer and indoor/outdoor subfields, etc.

Documents

Doc.: IEEE 802.22-06/0128r1 Submission September 2006 Ed Callaway, MotorolaSlide 1 A Proposal for the 802.22.1 Standard IEEE P802.22 Wireless RANs Date: