Doc.: IEEE 802.22-06/0128r0 Submission July 2006 Ed Callaway, MotorolaSlide 1 A Preliminary Proposal...

July 2006

Ed Callaway, Motorola

Slide 1

doc.: IEEE 802.22-06/0128r0

Submission

A Preliminary Proposal for the 802.22.1 StandardIEEE P802.22 Wireless RANs Date: 2006-07-14

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


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].>

July 2006


Slide 2

doc.: IEEE 802.22-06/0128r0

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, an

intercommunication channel between protected

devices, and AES-based beacon authentication.

July 2006


Slide 3

doc.: IEEE 802.22-06/0128r0

Submission

PHY

July 2006


Slide 4

doc.: IEEE 802.22-06/0128r0

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 (~ 35 km)

is the critical issue in the 22.1 beacon design.

July 2006


Slide 5

doc.: IEEE 802.22-06/0128r0

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.

July 2006


Slide 6

doc.: IEEE 802.22-06/0128r0

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 (190 s) to ameliorate multipath and sensitivity concerns– To assist simultaneous cyclostationary detection of both systems,

the symbol rate is selected to be 5.255 kBaud, the ATSC symbol rate divided by 2048.

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

Sync N Sync N-1 Sync N-2 … Sync 2 Sync 1 Sync 0 BEACON PSDU

~4.4 ms

2 s

BURST

~4.567 ms24 bits

~68.5 ms360 bits

July 2006


Slide 7

doc.: IEEE 802.22-06/0128r0

Submission

The Burst-Beacon Design (2)

For fading protection, a wider (spread) signal is desirable. We propose DSSS with a 16-chip pn sequence (augmented 15-chip m-sequence), with fchip = 84.080 kchip/s (= ATSC / 128).– 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

Sync N Sync N-1 Sync N-2 … Sync 2 Sync 1 Sync 0 BEACON PSDU

~4.567 ms24 bits

2 s

BURST

~68.5 ms360 bits

July 2006


Slide 8

doc.: IEEE 802.22-06/0128r0

Submission

Burst Design

Synchronization word is the same 15-bit m-sequence used for spreading (but not augmented)

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

9-bit index word sufficient for 512 bursts – 422 bursts actually sent every 2 s

INDEXSYNCHRONIZATION

15 bits 9 bits

~4.567 ms

July 2006


Slide 9

doc.: IEEE 802.22-06/0128r0

Submission

5 6 7 8 9 10 11

10-4

10-3

10-2

10-1

100

Eb/No (dB)

Det

ectio

n E

rror

Rat

e

Sync Burst

Beacon Packet

Noise falsing probability forSync Burst < 1e-6

Burst and Beacon Detection Error Rates

July 2006


Slide 10

doc.: IEEE 802.22-06/0128r0

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

July 2006


Slide 11

doc.: IEEE 802.22-06/0128r0

Submission

Intercommunication

We propose an “interbeacon channel” for communication between protected devices– To be placed in the lowest 100 kHz of each television channel

– To be used, e.g., for coordinating the transmission of information on beacons

July 2006


Slide 12

doc.: IEEE 802.22-06/0128r0

Submission

MAC

July 2006


Slide 13

doc.: IEEE 802.22-06/0128r0

Submission

Beacon Frame Format

6 1 1

Parameter

3

Parameter

4

Additional

Data

Message Integrity

Code

n 16 Octets: 2 1 1 1 8 8

Sync

Index (0)

Parameter

1

Parameter

2

Parent

Callsign

Location

Timestamp

Description Length in bytes Length in bits

PHY layer (sync word + index) 3 24

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

1 3/3/2

Parameter 2: Reference device (no by default)/ Beacon Length (bytes) 1 1/7

Parent Callsign (Designator) 8 64

Location 8 64

Time stamp (GPS time) 6 48

Parameter 3: Channel sub-division/Keep Out Zone 1 6/2

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

Additional data space (valid range: 0 ≤ n ≤ 82 bytes) - -

Message Integrity Code (AES-128 Authentication) 16 128

Total (plus additional data space) 45 360

July 2006


Slide 14

doc.: IEEE 802.22-06/0128r0

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

July 2006


Slide 15

doc.: IEEE 802.22-06/0128r0

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) via the interbeacon channel• 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

July 2006


Slide 16

doc.: IEEE 802.22-06/0128r0

Submission

MAC Flow Chart

Set beacon reference to TRUE

Transmit on burst-beacon channel

Co-located beacon detected?Y

Shutdownbeacon?

N

N

Y

Initialize beacon unitand read parameter set

= User interface function

Beacon deactivated

Listen to burst-beacon channel for co-located

beacon activity

Parameter Defaults:- Reference Mode = FALSE

Y

N

Proposed commands for the interbeacon channel:- DISABLE COMMAND – notify beacon to

disable transmit operation on burst-beacon channel

- Merge COMMAND – aggregate parameter setVia interbeaconchannel merge parameter

set

Bursts Beacon2s

68msVia interbeacon channel request to merge parameter

set

Merge parameterset permitted?

Co-located beacon detected?

Listen to interbeaconchannel

N

A

B

Transmission on burst-beacon channel

DISABLED?

N

AY

Beacon reference set to TRUE?

Y

N

B

Y

Follow predetermined policy to (ENABLE/DISABLE) transmission on burst-

beacon channel

Transmission DISABLED?

A

Y

B

N

July 2006


Slide 17

doc.: IEEE 802.22-06/0128r0

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

– The interbeacon channel, for communication between protected devices

– AES-based beacon authentication

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

July 2006


Slide 18

doc.: IEEE 802.22-06/0128r0

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

Interbeacon channel in lowest 100 kHz of TV channel; provision for multiple parent information to be included in one beacon

Optional means to provide a channel coordination function

Interbeacon channel

Transmitter specifications DSSS; 5.255 kBaud; 84.080 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

Interbeacon channel

July 2006


Slide 19

doc.: IEEE 802.22-06/0128r0

Submission

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

Interbeacon channel; 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

Interbeacon channel; 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); perhaps the interbeacon channel?

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 9)

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

Sophisticated use of interbeacon communication; use of countdown timer and indoor/outdoor subfields, etc.

Doc.: IEEE 802.22-06/0128r0 Submission July 2006 Ed Callaway, MotorolaSlide 1 A Preliminary Proposal...

Documents

Transcript of Doc.: IEEE 802.22-06/0128r0 Submission July 2006 Ed Callaway, MotorolaSlide 1 A Preliminary Proposal...