Doc.: IEEE 802.22-06/0130r0 Submission July 2006 Carlos Cordeiro, PhilipsSlide 1 A Beacon-based Proposal to IEEE 802.22.1 IEEE P802.22 Wireless RANs Date:

July 2006

Carlos Cordeiro, Philips

Slide 1

doc.: IEEE 802.22-06/0130r0

Submission

A Beacon-based Proposal to IEEE 802.22.1IEEE P802.22 Wireless RANs Date: 2006-07-14

Name Company Address Phone email Carlos Cordeiro Philips USA 914-945-6091 [email protected]

Monisha Ghosh Philips USA 914-945-6415 [email protected]

Vasanth Gaddam Philips USA 914-945-6424 [email protected]

Kiran Challapali Philips USA 914-945-6127 [email protected]

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

http://standards.ieee.org/guides/bylaws/sb-bylaws.pdf

mailto:[email protected]

mailto:[email protected]

July 2006


Slide 2

doc.: IEEE 802.22-06/0130r0

Submission

Outline

• Introduction

• The PHY Proposal

• The MAC Proposal

• Conclusions

July 2006


Slide 3

doc.: IEEE 802.22-06/0130r0

Submission

Introduction

• Need for enhanced protection to low-power licensed devices (FCC Part 74 services in the USA) operating in the TV broadcast band

– Signal the presence of licensed devices to license-exempt services

• Some of the issues that need to be addressed include:– Means to signal the presence of, and identify channels in use by, low

power licensed devices associated with the beacon and operating in close proximity to the beacon

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

– Means to aggregate wireless microphone channel use data– Means to alleviate the effect of transmission channel fading and distortion– Means to provide a channel coordination function for low power licensed

devices– Etc…

July 2006


Slide 4

doc.: IEEE 802.22-06/0130r0

Submission

Introduction

• We propose a fully distributed beacon-based solution to be used for the protection of Part 74 (P74) devices

• Some of the features of this proposal include:– Autonomous network formation amongst Part 74 beacon devices (DEV)– DEVs within radio range discover each other and conglomerate as to share

the same channel for beacon transmissions– Dynamic merging of multiple DEV networks can be done– Distribution of information on channels occupied by P74 devices

• Plus, feedback to Part 74 users on channel utilization as to promote better spectrum usage

– Sensing capability by DEVs– To allow for bi-directional communication, DEVs are also capable of

receiving beacons from the unlicensed secondary user (USU) – in this case, 802.22

– A DEV can rebroadcast information received from neighboring DEVs

July 2006


Slide 5

doc.: IEEE 802.22-06/0130r0

Submission

Requirement

• For better spectrum usage (and not due to a limitation of this proposal), DEVs are required to know their location information– GPS– Through a 802.22 BS, provided DEVs have the capability to

understand the WRAN– …

July 2006


Slide 6

doc.: IEEE 802.22-06/0130r0

Submission

The PHY

July 2006


Slide 7

doc.: IEEE 802.22-06/0130r0

Submission

The PHY

• The range of beaconing device is same as the WRAN BS (upto 33 Km)

• Two PHY modes– Range, data-rate, receiver complexity trade-offs

• Single carrier modulation• Receiver determines which mode is transmitted/received• Energy sensing and preamble sensing

July 2006


Slide 8

doc.: IEEE 802.22-06/0130r0

Submission

The PHY (Mode A)

July 2006


Slide 9

doc.: IEEE 802.22-06/0130r0

Submission

PHY Outline

• MAC payload is transmitted in one beacon slot• BPSK, QPSK, 16-QAM modulation options• Constraint length 5, Rate – ½ convolutional code

– Rate – 2/3 and ¾ with puncturing

• Optional equalization provides performance improvement

July 2006


Slide 10

doc.: IEEE 802.22-06/0130r0

Submission

PPDU Frame Format

• PLCP preamble– Signal detection and synchronization

• PLCP HDR– PHY and MAC headers

• PSDU– Payload (MPDU), tail bits and pad bits

• Includes 2 byte frame check sequence (FCS)– The coding rate and modulation type is selected so that it fully utilizes the

beacon slot

PLCP Preamble PLCP HDR PSDU

150 symbols 112 symbols Fixed # of symbols

July 2006


Slide 11

doc.: IEEE 802.22-06/0130r0

Submission

PLCP Preamble

• S1 to S7: each block consists of a 15-bit pseudo random sequence (TBD)

– S6: Inverted polarity compared with rest of the symbol blocks• GI: Guard interval (CP or ZP)

– Could be repetition of C1• C1, C2: Repetition of a 15-bit sequence

– Used for channel estimation• BPSK/QPSK modulation

S1 GIS7S6S5S4S3S2 C2C1

15 sym 150 symbols

July 2006


Slide 12

doc.: IEEE 802.22-06/0130r0

Submission

• PHY header – 2 bytes• MAC header – 3 bytes• HCS – 1 byte

– Generated on PHY header and MAC header– Generator polynomial: CCITT CRC-8:

• Tail bits are used to bring the coder to zero state• BPSK/QPSK modulation

PLCP Header

PHY HDR Tail bits MAC HDR + HCS Tail

bits

2 bytes 4 bits 4 bytes 4 bits

12378 xxxx

July 2006


Slide 13

doc.: IEEE 802.22-06/0130r0

Submission

PHY Header

• Rate – Coding rate and modulation type for PSDU – 3 bits

• Length – number of octets in the frame payload (before encoding)– 7 bits (0 – 127)

• 6 reserved (R) bits

0R

11MSB

1098765LSB

4MSB

32LSB

1R

15R

14R

13R

12R

Rate Length

Rate(b4 b3 b2)

Modulation Type

Coding Rate

000 QPSK ½

001 QPSK 2/3

010 QPSK ¾

011 Reserved Reserved

100 16-QAM ½

101 16-QAM 2/3

110 16-QAM ¾

111 Reserved Reserved

July 2006


Slide 14

doc.: IEEE 802.22-06/0130r0

Submission

Encoding of PLCP HDR

• Rate – ½ convolutional coder• BPSK modulation• Transmitted in 112 symbols

– Duration = 112 x TSYM

Rate - 1/2 Convolutional

codermapping Modulator

July 2006


Slide 15

doc.: IEEE 802.22-06/0130r0

Submission

PSDU

• Frame payload size before encoding: 0 – 127 bytes• Frame check sequence: 2 bytes

– CCITT CRC-16: generator polynomial• Tail bits are not scrambled• Pad bits are added in order to occupy the entire beacon slot

151216 xxx

FCS Tail bitsFrame payload

0 – 127 bytes 2 bytes 4 bits

Pad bits

Variable

July 2006


Slide 16

doc.: IEEE 802.22-06/0130r0

Submission

PSDU Encoding

• The PSDU data and FCS is first randomized• 4 tail bits are appended to randomizer output• The resulting vector is encoded using a rate – ½ convolutional

coder and punctured according to the rate specified• Optional interleaver• QPSK and 16-QAM mapping

PuncturerRate - 1/2

Convolutional coder

Interleaver(optional) mapping ModulatorRandomizer

July 2006


Slide 17

doc.: IEEE 802.22-06/0130r0

Submission

Rate – ½ Convolutional Code

• Constraint length = 5• Generator poly – [23o 35o]

D DDDData in

Output A

+

Output B

+

July 2006


Slide 18

doc.: IEEE 802.22-06/0130r0

Submission

Puncturing and Bit-Insertion

• Defined for rate – 2/3 and rate – 3/4

Code rate ½ 2/3 ¾

Convolutional coder output A1B1 A1B1A2B2 A1B1A2B2A3B3

Puncturer output/bit-

inserter inputA1B1 A1B1A2 A1B1B2A3

Decoder input A1B1 A1B1A20 A1B10B2A30

July 2006


Slide 19

doc.: IEEE 802.22-06/0130r0

Submission

Symbol Mapping (QPSK)• The output of puncturer/interleaver is divided into groups of 2

bits and then converted into complex numbers using QPSK constellation mapping

• Normalization factor = 1/√2

Input bits (b1b0)

I component Q component

00 -1 -1

01 -1 1

10 1 -1

11 1 1

July 2006


Slide 20

doc.: IEEE 802.22-06/0130r0

Submission

Symbol Mapping (16-QAM)• The output of puncturer/interleaver is divided into groups of 4

bits, Gray coded and then converted into complex numbers using 16-QAM constellation mapping

• Normalization factor = 1/√10

Input bits (b1b0)

I component

00 -3

01 -1

10 3

11 1

Input bits (b3b2)

Q component

00 -3

01 -1

10 3

11 1

July 2006


Slide 21

doc.: IEEE 802.22-06/0130r0

Submission

Pulse Shaping

• The I and Q components of the signal are square root raised cosine (SQRC) filtered prior to modulation

• Roll-off factor is 0.15

July 2006


Slide 22

doc.: IEEE 802.22-06/0130r0

Submission

The PHY (Mode B)

July 2006


Slide 23

doc.: IEEE 802.22-06/0130r0

Submission

PHY Outline

• MAC payload is transmitted in multiple superframes (in a fixed beacon slot)– Enables simple receiver architectures since less amount of data is

transmitted in each slot

• DSS using a 7-chip code• BPSK/QPSK mapping• Option to use short preamble

July 2006


Slide 24

doc.: IEEE 802.22-06/0130r0

Submission

PPDU Frame Format

• PLCP preamble– Signal detection and synchronization

• PHY HDR– PSDU Length

• PSDU– Payload (MPDU), tail bits and pad bits

• Includes 1 byte frame check sequence (FCS)

Long PLCP Preamble PHY HDR PSDU

24 Bits 8 Bits Fixed # of Bits

Short PLCP Preamble PHY HDR PSDU

12 Bits 8 Bits Fixed # of Bits

July 2006


Slide 25

doc.: IEEE 802.22-06/0130r0

Submission

PLCP Preamble

• Burst detection bits– Long preamble: 20 bits– Short preamble: 8 bits

• Frame Detection: 4 bits

Burst Detection Frame Detection

20 Bits 4 Bits

Burst Detection Frame Detection

8 Bits 4 Bits

Long PLCP Preamble

Short PLCP Preamble

July 2006


Slide 26

doc.: IEEE 802.22-06/0130r0

Submission

• PHY header: 1 byte– Length: 5 bits (0-31)

• Indicates length of PSDU in octets– Preamble type (PT): 1 bit– Parity (P): 1 bit– Reserved: 1 bit

PHY Header

3210LSB

7P

6PT

5R

4MSB

Length

July 2006


Slide 27

doc.: IEEE 802.22-06/0130r0

Submission

PSDU

• Frame payload size before encoding: 0 – 31 bytes• Frame check sequence: 1 byte

– CCITT CRC-8: generator polynomial• Pad bits are added in order to occupy the entire beacon slot

FCSFrame payload

0 – 31 bytes 1 byte

Pad bits

Variable

12378 xxxx

July 2006


Slide 28

doc.: IEEE 802.22-06/0130r0

Submission

DSS Spreading

• All the bits are spread using a 7-chip code before transmission• Preamble and header are transmitted using BPSK modulation• PSDU is transmitted using either BPSK or QPSK

July 2006


Slide 29

doc.: IEEE 802.22-06/0130r0

Submission

The MAC

July 2006


Slide 30

doc.: IEEE 802.22-06/0130r0

Submission

MAC Outline

• Beacon period• Beacon frame• Information elements (IE) related to:

– Beacon– Beacon period– P74 devices

• Sensing• Transmission and reception of beacons• DEV discovery by WRAN• Beacon collision and resolution• Beacon period merging

July 2006


Slide 31

doc.: IEEE 802.22-06/0130r0

Submission

Beacon Period Overview

• Within a superframe, there are two Beacon Periods (BPs)– Network BP (NBP): Used for communication and networking amongst

DEVs– Foreign BP (FBP): Used for receiving beacons from foreign networks

(e.g., 802.22 – or simply, USU) that wish to communicate with the DEVs• The BP provides a fully distributed and autonomous mechanism

for coordination of DEVs, and better spectrum use by both P74 devices and 802.22

– Does not rely on a central coordinator, who is a point of failure and hence could compromise incumbent protection

• The remaining of the superframe is termed as the Sense/Sleep/Beacon Period (SSBP)

– Period used by DEVs for sensing channels, sleeping, or for out-of-band beaconing

July 2006


Slide 32

doc.: IEEE 802.22-06/0130r0

Submission

NBP

Superframe (Tsf)

NetworkBeaconPeriod

ForeignBeaconPeriod

Superframe (32 MAS)

BPST BPST BPST

SSBP

Medium Access Slot(MAS)(TMAS)

FBP

SSBP

NBP FBP

The Network Beacon Period Overview

The Network Beacon contains Information regarding:

• Device Address (DevAddr) • NBP and FBP Length• Beacon Channel and Sub-Channel

Number• Beacon Slot Number• List of Neighbors• Sensing and Sleep Periods• List of TV channels occupied by P74

devices, RSSI, start time and duration• Location Information of DEV• Authentication Key• User specific information; Etc…

Every Part 74 beacon device (DEV) sends at least one beacon!

Slotted Network Beacon Period

DE

V 7

DE

V 2

DE

V 5

DE

V 1

DEV

6

DEV

3

DE

V 8

Network Beacon Period Length (DYNAMIC)

BeaconSlot

...

July 2006


Slide 33

doc.: IEEE 802.22-06/0130r0

Submission

NBP

Superframe (Tsf)

NetworkBeaconPeriod

ForeignBeaconPeriod

Superframe (32 MAS)

BPST BPST BPST

SSBP

Medium Access Slot(MAS)(TMAS)

FBP

SSBP

NBP FBP

The Foreign Beacon Period Overview

The USU Beacon contains information regarding:

• BS ID• Info on DEV authentication• Spectrum Occupancy (e.g.,

occupied, vacant, etc.)• Prioritized channel list suggested

for use by P74 devices• USU quiet periods• List of TV channels occupied by

P74 devices, RSSI, start time and duration

• Location Information of USU• Etc…

Allows for bi-directional communication!

Slotted Foreign Beacon Period

US

U 3

US

U 2

US

U 4

US

U 1

US

U 5

Foreign Beacon Period Length(DYNAMIC)

BeaconSlot

...

July 2006


Slide 34

doc.: IEEE 802.22-06/0130r0

Submission

Preamble PLCP header Payload

Beacon Period and BP Length

mMaxBeaconLengthpSIFS+mGuardTime

mBeaconSlotLength

DEV

5

DEV

9

DEV

3D

EV1

DEV

8 ...

DEV

8

Beacon Slots

Signaling slots

Highest-numbered unavailablebeacon slot seen by DEV 8

0 1 2 3 4 5

SSBP

mMaxBPLength

Largest NBP Lengthannounced

USU

1

USU

2

0 1 2 3

Largest FBPLength

announced

mMaxBPLength

Signaling slots

Superframe

July 2006


Slide 35

doc.: IEEE 802.22-06/0130r0

Submission

Beacon Frame

• MAC header

• Frame body

– Variable length– The FCS field contains a 16-bit CRC– To verify payload is correctly received

• Information within the Beacon can operate in either full dump or incremental mode– Minimizes data rate requirements with incumbent protection

octets: 1 2

Frame Control SrcAddr

octets: Ln 2

Frame Payload FCS

bits: b7-b5 b4-b3 b2 b1-b0

Frame Subtype Frame Type Secure Protocol Version

July 2006


Slide 36

doc.: IEEE 802.22-06/0130r0

Submission

Beacon Frame Header

Header field Value

Protocol Version 0

Secure 0

Frame Type 0 (beacon frame)

Frame Subtype 0 or 1 (NBP or FBP)

SrcAddr DevAddr of the transmitter

• Secure – Beacon security level• Frame Type

– Command frames handle probing (IEs), application support, etc.

• Frame Subtype

• SrcAddr – Abbreviated 2 bytes DevAddr of the transmitter

Frame Type Value

Beacon 0

Command 1

Reserved 2-3

Frame Subtype Value

Network beacon 0

Foreign beacon 1

Reserved 2-7

July 2006


Slide 37

doc.: IEEE 802.22-06/0130r0

Submission

Beacon Frame Payload• Beacon Parameters

– Device Identifier– Beacon Channel Number– Beacon Sub-Channel Number– Beacon Slot Number

• To derive BPST– Device Control

• Security Mode– at which the device is operating

• Is it Signaling Slot• Is it Movable (device beacon)

• IEs– at least one: BP Occupancy IE

and Location Information IE– BP switch IE– Channel change IE– Part 74 Occupancy IE– Etc.

octets: 10 L1 … LN

Beacon Parameters

Information Element 1

… Information Element N

octets: 6 1 1 1 1

IEEE 802 48-bit MAC

address

Beacon Channel Number

BeaconSub-Channel

Number

Beacon Slot

Number

Device Control

bits: b7-b6 b5-b2 b1 b0

Security Mode Reserved Signaling Slot Movable

July 2006


Slide 38

doc.: IEEE 802.22-06/0130r0

Submission

Information Elements General Format

• Element ID field is set to the value that identifies the information element

• The Length field is set to the length, in octets, of the IE-specific fields that follow

• The IE-specific fields contain information specific to the IE

Octets: 1 1 N

Element ID Length (=N) IE-specific fields

July 2006


Slide 39

doc.: IEEE 802.22-06/0130r0

Submission

Types of Information Elements

• A number of IEs are defined for both Network Beacons (NBP) and Foreign Beacons (FBP)

• Examples:

Network Beacon IEs

• BP Occupancy IE (BPOIE)• Part 74 Occupancy IE (P74OIE)• Hibernation Mode IE (for sleep periods)• Channels to Sense IE• Spectrum Occupancy IE• Location Information IE• Channel Change IE• BP Switch IE• Probe IE• MAC Capabilities IE• Operator/User/Application-specific IE; Etc…

Foreign Beacon IEs• Part 74 Occupancy IE (P74OIE)• Spectrum Occupancy IE• Prioritized Channel List IE (suggested for

use by P74 incumbent devices)• USU Quiet Period IE• Location Information IE• USU Descriptor IE• DEV Authentication IE• Etc…

July 2006


Slide 40

doc.: IEEE 802.22-06/0130r0

Submission

Types of Information Elements

• Two IEs of key importance are described here: Beacon Period Occupancy IE (BPOIE) and Part 74 Occupancy IE (P74OIE)

• BPOIE– Provides detailed information on the entire BP observed by the

DEV sending the IE• P74OIE

– Provides information on the channel usage by P74 incumbent devices as known by the DEV sending the IE

– Can be rebroadcast over multiple hops to increase protection to P74 services and to offer better spatial reuse

July 2006


Slide 41

doc.: IEEE 802.22-06/0130r0

Submission

Beacon Period Occupancy IE (BPOIE)

• NBP Length and FBP Length• Mode Information

– Incremental or full dump• Beacon Slot Info Bitmap

– BP slot Status (details in the next slide)– Stateless bitmap (heard in previous BP)– 1-to-1 with the following DevAddr list

• List of corresponding DevAddr(s) from which a beacon was received in the previous superframe

– Included in ascending beacon slot order – If received with an invalid HCS, the DevAddr is set to BcstAddr.

octets: 1 1 1 1 1 K 2 … 2

Element ID Length (=2+K+2×N) NBP Length FBP Length Mode Information

Beacon Slot Info Bitmap DevAddr 1 … DevAddr N

bits: 1 7

Mode Cycle Length

July 2006


Slide 42

doc.: IEEE 802.22-06/0130r0

Submission

Beacon Slot StatusElement

value Beacon slot status

0

Unoccupied (non-movable)No PHY indication of medium activity was received in the corresponding beacon slot in the last superframe, or any frame header received with a valid HCS was not a beacon

frame.

1

Occupied & non-movableA beacon frame was received with a valid HCS and FCS in the corresponding beacon

slot in the last superframe, and the Movable bit in that beacon was set to zero, or a beacon frame was received in the corresponding beacon slot in a previous superframe

that indicated a hibernation period that has not expired.

2

Occupied & movableA PHY indication of medium activity was received in the corresponding beacon slot in the last superframe, but did not result in reception of a frame with valid HCS and FCS.

3

Occupied & movableA beacon frame was received with a valid HCS and FCS in the corresponding beacon

slot in the last superframe, and the Movable bit in that beacon was set to one.

July 2006


Slide 43

doc.: IEEE 802.22-06/0130r0

Submission

(Non-)Movable Beacon Slot

• In current superframe, a device find at least one available beacon slot between signaling slots and its own beacon

• A device that includes a Hibernation Mode IE in its beacon shall consider its beacon to be non-movable during the announced hibernation period.

July 2006


Slide 44

doc.: IEEE 802.22-06/0130r0

Submission

Part 74 Occupancy IE (P74OIE)

• Mode Information– Incremental or full dump

• DevAddr– Address of DEV who made the report

• Channel No.– TV channel number of P74 device

• Sub-Channel No.– Sub-channel index within Channel No., if

known• Start Time

– Start time of P74 service operation, if known

• Duration– Duration of P74 service operation,

if known• RSSI

– The received signal strength from the P74 device, if known

octets: 1 1 1 2 7 7

Element ID Length (=2+7×N) Mode Information DevAddr Part 74 Usage Info 1

…Part 74 Usage Info N

octets: 1 1 2 2 1

Channel No. Sub-Channel No.

Start Time Duration RSSI

bits: 1 7

Mode Cycle Length

July 2006


Slide 45

doc.: IEEE 802.22-06/0130r0

Submission

Sensing

• A DEV shall have, at a minimum, the capability to perform the following types of detection– Energy detection– Preamble detection (of other DEVs)

• This will allow DEVs to build a channel map which distinguishes:– Channels occupied by wideband emitters (TV signal or WRAN)– Channels occupied by narrowband emitters (Part 74 devices)

• This may require more than one measurement per TV channel with associated timing requirement– E.g., about 3ms per TV channel to detect a WRAN

July 2006


Slide 46

doc.: IEEE 802.22-06/0130r0

Submission

Beacon Transmission and Reception (I)

• At power-up, a DEV scans TV channels searching for DEV beacons first (at least 1 superframe per sub-channel)

– If no beacon is received after the scan procedure• If the DEV has a pre-programmed channel Ni (sub-channel i within TV channel

N), or knows in which TV channel N the P74 device will operate– sets its own BPST and sends the first beacon (in the first slot after the signaling slots)

through channel Ni

• Else– As a result of sensing, selects a vacant channel N, sets its own BPST and sends the

first beacon (in the first slot after the signaling slots) through channel Ni

– If another beacon is received• looks for an empty slot within mBPExtention(8) slots after highest-numbered

unavailable slot up to mMaxBPLength/2.

July 2006


Slide 47

doc.: IEEE 802.22-06/0130r0

Submission

Beacon Transmission and Reception (II)

• Within a TV channel, the sub-channel i where the beacon is transmitted can be:– Determined dynamically: long search procedure and higher delay– Pre-determined in the standard: fast discovery by both other DEVs

and USUs (i.e., 802.22)• Would this require regulatory approval?

• Once a slot is chosen by DEV, the beacon is always sent in the same slot unless – A collision is detected– Or contraction is required

July 2006


Slide 48

doc.: IEEE 802.22-06/0130r0

Submission

Beacon Transmission and Reception (III)

• Every DEV sends at least one beacon per BP

• DEVs may transmit multiple times within a BP. For example:– In case there are free slots– No or few number of neighboring DEVs

• This will facilitate detection by the WRAN

July 2006


Slide 49

doc.: IEEE 802.22-06/0130r0

Submission

Beacon Transmission and Reception (IV)

• Upon receiving a beacon, a DEV processes it• This includes determining the applicability of the

information received and updating its own beacon, if needed. For example:– If the receiving DEV is “far enough away” (based on location

information) from the actual DEV reporting the P74 incumbent user, then there is no need to rebroadcast the P74OIE

– Information within the beacon shall not be rebroadcast for more than X number of hops

• A DEV rebroadcasts the relevant information obtained from its neighbors after processing all beacons received

July 2006


Slide 50

doc.: IEEE 802.22-06/0130r0

Submission

DEV Discovery by WRAN (I)

• Problem– How does the WRAN find out about DEVs?– What if the Beacon Channel Number is different from the

channel(s) the P74 device is operating?– A number of P74 devices may be operating in proximity (e.g., one

hop, two hops, …)• A poor design choice would be to have each DEV to

independently send a beacon through each channel occupied by a P74 device or WRAN– Interference to co-channel WRANs;– Collision of DEV beacons;– Power consumption of DEVs; etc.

July 2006


Slide 51

doc.: IEEE 802.22-06/0130r0

Submission

DEV Discovery by WRAN (II)

• Two options are possible:– Passive: The out-of-band measurement capability of the WRAN is used

to discover the BP of nearby DEVs• Scheme 1

– The WRAN knows a priori which sub-channel i the DEVs’ BP operate– A timely out-of-band measurement capability detects the DEVs’ BP within the

required Channel Detection Time• Scheme 2

– DEVs use pilot signals, with the WRAN employing a pilot detection scheme– Proactive: DEVs switch to channels occupied by P74 services and

transmit beacons through those channels• This is also known as out-of-band beaconing• Through the BP, DEVs dynamically negotiate who will transmit beacons

through which P74 channels• Devices can take turn in beacon transmission and hence better mitigate fading

and shadowing• Both solutions are supported

July 2006


Slide 52

doc.: IEEE 802.22-06/0130r0

Submission

Power-saving Consideration

• Need only listen for beacons during the BP length (network and foreign) it announced in the last superframe, except if it receives a beacon in a signaling slot

• On the reception of a beacon in signaling slot– On successful reception, extend it BP to include the beacon slot– On unsuccessful reception, extend its BP for an additional

mBPExtension (8)• Invalid FCS• Detection of medium activity, but invalid HCS

July 2006


Slide 53

doc.: IEEE 802.22-06/0130r0

Submission

Signaling Slot

• To inform the neighbor’s that its beacon slot is located beyond the BP length of any of its neighbors

– The device transmit the same beacon, except with the Signaling Slot bit set to one, in signaling beacon slot in the BP

– The signaling slot is randomly chosen• Until its neighbors extend their BP length to include its beacon• Shall only transmit in a signaling slot for up to mMaxLostBeacons superframes• if needed, have to wait for at least mMaxLostBeacons

DEV

5

DEV

9

DEV

3D

EV1

DEV

8 ...

DEV

8

Beacon Slots

Signaling slots


0 1 2 3 4 5

SSBP

mMaxBPLength

Largest NBP Lengthannounced

USU

1

USU

2

0 1 2 3

Largest FBPLength

announced

mMaxBPLength

Signaling slots

Superframe

July 2006


Slide 54

doc.: IEEE 802.22-06/0130r0

Submission

Beacon Collision Resolution • Upon detection of a beacon collision, the device shall choose a different beacon

slot for its subsequent beacon transmissions – from up to mBPExtension beacon slots – located after the highest-numbered unavailable beacon slot it observed in the last

superframe

DEV

5

DEV

9

DEV

3D

EV 1

DEV

8 ...

DEV

8Superframe

Beacon Slots

Data period

Signaling slots


Largest BP Length announced

mMaxBPLength

0 1 2 3 4 5

mMaxBPlength

Collision in slot 5

DEV

8

DEV

8

July 2006


Slide 55

doc.: IEEE 802.22-06/0130r0

Submission

A B

C

D E F

G

C B A E D G

F

C B A D E G

F

(a-1) Beacon collision between one hop neighbors-

(a-2) Beacon collision between two hop neighbors -

BPST

BPST

beacon slot #5

Beacon Collision Detection Overview

• DevAddr (of the transmitter) received is recorded, when receiving a beacon.

• And transmitted in the device’s BPOIE in the next superframe

• If the device does not hear back its own DevAddr in received BPOIE for a duration of mMaxLostBeacons

• Collision in up to 2 hops shall be detected and resolved (thus disallowed)

July 2006


Slide 56

doc.: IEEE 802.22-06/0130r0

Submission

Beacon Collision Detection Details (I)

• Detection by aperiodically skipping sending beacon at least every mMaxNeighborDetectionInterval

– One hop collision• When skipping beacon transmission in the current superframe, it receives in its beacon slot in the

current superframe: a MAC header of type beacon frame, or a PHY indication of medium activity that does not result in correct reception of a MAC header

– Two hop collision• After skipping beacon transmission in the previous superframe, its beacon slot is reported as

occupied in the BPOIE of any beacon it receives in the current superframe.

A

B

C

D E F

G

July 2006


Slide 57

doc.: IEEE 802.22-06/0130r0

Submission

Beacon Collision Detection Details (II)• Detection without skipping beacon

– one hop collision• Its beacon slot is reported as occupied in the BPOIE in any beacon it receives in the

current superframe, but the corresponding DevAddr is neither its own nor BcstAddr– two top collision

• Its beacon slot has been reported as occupied and the corresponding DevAddr has been BcstAddr in the BPOIE of a beacon it received in the same beacon slot in each of the latest mMaxLostBeacons superframes.

AC D E F

G

B C

July 2006


Slide 58

doc.: IEEE 802.22-06/0130r0

Submission

Beacon Collision Resolution: Performance

• Let us assume the BP to contain 24 beacon slots

• We can show that this problem is similar to the balls and bins problem where the bins are equivalent to slots and balls are users

• From the theory, it is proved that it takes Θ(log log 24) rounds before all users are allocated one non-colliding beacon slot

July 2006


Slide 59

doc.: IEEE 802.22-06/0130r0

Submission

Beacon Period Contraction

• If in the latest mMaxLostBeacons (3) superframes– Its beacon has been movable– And all later beacon slots (within BP length) are non-movable

• Then, move to the earliest available non-signaling slot

DEV

5

DEV

9

DEV

3D

EV 1...

DE

V 8

DEV

5

DEV

9

DEV

3D

EV 1...

DE

V 8

DEV

4D

EV 6

Not MovablemMaxBPLength mMaxBPLength

... ...

Movable

DEV

2

DEV

2

July 2006


Slide 60

doc.: IEEE 802.22-06/0130r0

Submission

Merging of Multiple BPs: Overview

• Unaligned BPSTs may come into range due to – Mobility– Changes in propagation– Channel change, etc.

• Alien Beacon: a received beacon that indicates non-aligned BPST

• Alien BP: The BP in alien beacon defined by– BPST– BP length

• Beacon collision

A B

C

E F

G

E D G F C B A

(b-1) Before merging the BPs

BPST 1 BPST 2

C BE D G F

(b-2) After merging the BPs

BPST 2

C A

D

July 2006


Slide 61

doc.: IEEE 802.22-06/0130r0

Submission

Merging of Multiple BPs: Details

• Non-aligned slot boundary may cause synchronization problem

• Definition of alignment– A device may appear to be an alien device due to loss of synchronization– A device shall consider BPSTs to be aligned if time difference is less than

2*mGuardTime.

• Two cases– Overlapping BPs– Non-overlapping BPs

July 2006


Slide 62

doc.: IEEE 802.22-06/0130r0

Submission

Overlapping BPs• Corner case • Align its BPST to the BPST of the alien BP• Adjust beacon Slot Numberbeacon Slot Number

– Either highest occupied beacon slot (in alien beacon) +1– Or join alien BP normally

• No transmission of beacon in former BP

A B

C

D E F

G

C B E D G F


(b-2) After merging the BPs BPST 1

C A

E D G F

C B A

BPST 2

BPST 1 BP length

July 2006


Slide 63

doc.: IEEE 802.22-06/0130r0

Submission

Non-overlapping BPs

A B

C

D E F

G

C B

E D G F

E D G F

C B A



BPST 1

BPST 2

BPST 2

C A

Alien BP

July 2006


Slide 64

doc.: IEEE 802.22-06/0130r0

Submission

Merging of Non-Overlapping BPs: Details

• The DEV shall relocate its beacon within the time specified below, if Alien BPST falls in – The first half of Superframe: mBPMergeWaitTime (say, 128

superframes)

– The Second half of Superframe: 1.5xmBPMergeWaitTime• If the first BP does not merge

– Coordinate the BP merging by dissemination of BP switch IE

July 2006


Slide 66

doc.: IEEE 802.22-06/0130r0

Submission

Coordinated BP Merging using BP Switch IE

• Disseminate BP Switch IE• Advantage

– when multiple alien BP exist, devices merge to the same BP

– No beacon collision among devices after BP merging

octets: 1 1 1 1 2

Element ID Length (=4) BP Move Countdown Beacon Slot Offset BPST Offset

C A

E D G F

E D G F

C B A



BPST 1 BPST 2

BPST 2

C B

BPST Offset Beacon Slot Offset

July 2006


Slide 67

doc.: IEEE 802.22-06/0130r0

Submission

Dissemination of BP Switch IE (I)

• If a larger BPST Offset is observed, copy the larger offset and reset the BP Move Countdown value

• If a larger Beacon Slot Offset is observed, copy the larger offset and reset the BP Move Countdown value

• Otherwise, decrement BP Move Countdown

July 2006


Slide 68

doc.: IEEE 802.22-06/0130r0

Submission

Dissemination of BP Switch IE (II)• Reset a countdown counter

– Multiple hop devices merge to the alien BP– Reduced service disruption

superframe A B C D E F

1 (7,+3)

2 (7,+2) (7,+3)

3 (7,+1) (7,+2) (7,+3)

4 (7,+0) (7,+1) (7,+2) (7,+3)

5 (7,+0) (7,+1) (7,+2) (7,+3)

6 (7,+0) (7,+1) (7,+2) (7,+3)

7 (7,+0) (7,+1) (7,+2)

8 (7,+0) (7,+1)

9 (7,+0)

(a,b): (beacon slot offset, move countdown) Neighbors merge one after the other

July 2006


Slide 69

doc.: IEEE 802.22-06/0130r0

Submission

Dissemination Algorithm

July 2006


Slide 70

doc.: IEEE 802.22-06/0130r0

Submission

Beacon Relocation

• At end of the superframe in which BP Move CountdownBP Move Countdown ==0

• Adjust BPST based on its BPST OffsetBPST Offset• In the new BP (alien BP), relocate its beacon to slot

number – Beacon Slot numberBeacon Slot number + Beacon Slot Offset (Beacon Slot Offset (≠0)≠0)– Otherwise (=0), join the alien BP normally

• May skip one beacon transmission• Remove BP Switch IE in new beacon

July 2006


Slide 71

doc.: IEEE 802.22-06/0130r0

Submission

Merging of Multiple BPs: Conclusion

• BPs within radio range can be merged dynamically– Same or different channels

• If BPs are in different channels, a channel change precedes the merging procedure

• Some advantages:– Better spectrum usage– More diversity– Enhanced protection to P74 services

July 2006


Slide 72

doc.: IEEE 802.22-06/0130r0

Submission

Conclusions

July 2006


Slide 73

doc.: IEEE 802.22-06/0130r0

Submission

Conclusions

• We have proposed a PHY and MAC layer that fully addresses the 802.22.1 requirements

• PHY– Two PHY modes– Single carrier modulation– Receiver determines which mode is transmitted/received– Energy sensing and preamble sensing

• MAC– Assured protection to Part 74 services– Fully distributed beaconing protocol– Unidirectional and bi-directional communication– Allows for better spectrum usage

Doc.: IEEE 802.22-06/0130r0 Submission July 2006 Carlos Cordeiro, PhilipsSlide 1 A Beacon-based Proposal to IEEE 802.22.1 IEEE P802.22 Wireless RANs Date:

Documents