July 2006 doc IEEE 802 22 060130 r

  • Slides: 72
Download presentation
July 2006 doc. : IEEE 802. 22 -06/0130 r 0 A Beacon-based Proposal to

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 A Beacon-based Proposal to IEEE 802. 22. 1 IEEE P 802. 22 Wireless RANs Date: 2006 -07 -14 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 patcom@iee. org. > Submission 1 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Outline • Introduction •

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Outline • Introduction • The PHY Proposal • The MAC Proposal • Conclusions Submission 2 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Introduction • Need for

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 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… Submission 3 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Introduction • We propose

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Introduction • We propose a fully distributed beacon-based solution to be used for the protection of Part 74 (P 74) 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 P 74 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 Submission 4 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Requirement • For better

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 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 – … Submission 5 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 The PHY Submission 6

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 The PHY Submission 6 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 The PHY • The

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 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 Submission 7 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 The PHY (Mode A)

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 The PHY (Mode A) Submission 8 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 PHY Outline • MAC

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 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 Submission 9 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 PPDU Frame Format •

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 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 Submission 10 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 PLCP Preamble • S

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 PLCP Preamble • S 1 to S 7: each block consists of a 15 -bit pseudo random sequence (TBD) – S 6: Inverted polarity compared with rest of the symbol blocks • GI: Guard interval (CP or ZP) – Could be repetition of C 1 • C 1, C 2: Repetition of a 15 -bit sequence – Used for channel estimation • BPSK/QPSK modulation Submission 11 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 PLCP Header • PHY

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 PLCP Header • 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 Submission 12 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 PHY Header • Rate

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 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 Submission 13 Rate (b 4 b 3 b 2) Modulation Type Coding Rate 000 QPSK ½ 001 QPSK 2/3 010 QPSK ¾ 011 Reserved 100 16 -QAM ½ 101 16 -QAM 2/3 110 16 -QAM ¾ 111 Reserved Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Encoding of PLCP HDR

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Encoding of PLCP HDR • Rate – ½ convolutional coder • BPSK modulation • Transmitted in 112 symbols – Duration = 112 x TSYM Submission 14 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 PSDU • Frame payload

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 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 Submission 15 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 PSDU Encoding • The

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 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 Submission 16 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Rate – ½ Convolutional

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Rate – ½ Convolutional Code • Constraint length = 5 • Generator poly – [23 o 35 o] Submission 17 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Puncturing and Bit-Insertion •

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Puncturing and Bit-Insertion • Defined for rate – 2/3 and rate – 3/4 Code rate Submission ½ 2/3 ¾ Convolutional coder output A 1 B 1 A 2 B 2 A 3 B 3 Puncturer output/bitinserter input A 1 B 1 A 2 A 1 B 2 A 3 Decoder input A 1 B 1 A 2 0 A 1 B 10 B 2 A 30 18 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Symbol Mapping (QPSK) •

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 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 Submission Input bits (b 1 b 0) I component Q component 00 -1 -1 01 -1 1 10 1 -1 11 1 1 19 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Symbol Mapping (16 -QAM)

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 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 (b 1 b 0) I component Input bits (b 3 b 2) Q component 00 -3 01 -1 10 3 11 1 Submission 20 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Pulse Shaping • The

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 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 Submission 21 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 The PHY (Mode B)

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 The PHY (Mode B) Submission 22 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 PHY Outline • MAC

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 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 Submission 23 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 PPDU Frame Format •

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 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) Submission 24 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 PLCP Preamble Long PLCP

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 PLCP Preamble Long PLCP Preamble Short PLCP Preamble • Burst detection bits – Long preamble: 20 bits – Short preamble: 8 bits • Frame Detection: 4 bits Submission 25 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 PHY Header • PHY

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 PHY Header • 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 Submission 26 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 PSDU • Frame payload

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 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 Submission 27 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 DSS Spreading • All

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 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 Submission 28 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 The MAC Submission 29

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 The MAC Submission 29 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 MAC Outline • Beacon

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 MAC Outline • Beacon period • Beacon frame • Information elements (IE) related to: – Beacon period – P 74 devices • • • Sensing Transmission and reception of beacons DEV discovery by WRAN Beacon collision and resolution Beacon period merging Submission 30 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Beacon Period Overview •

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 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 P 74 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 Submission 31 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 The Network Beacon Period

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 The Network Beacon Period Overview The Network Beacon contains Information regarding: • Device Address (Dev. Addr) • 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 P 74 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! Submission 32 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 The Foreign Beacon Period

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 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 P 74 devices • USU quiet periods • List of TV channels occupied by P 74 devices, RSSI, start time and duration • Location Information of USU • Etc… Allows for bi-directional communication! Submission 33 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Beacon Period and BP

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Beacon Period and BP Length PLCP Preamble header m. Beacon. Slot. Length Payload m. Max. Beacon. Length Submission 34 p. SIFS+m. Guard. Time Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Beacon Frame • MAC

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Beacon Frame • MAC header octets: 1 2 Frame Control Src. Addr bits: b 7 -b 5 b 4 -b 3 b 2 b 1 -b 0 Frame Subtype Frame Type Secure Protocol Version • Frame body octets: Ln 2 Frame Payload FCS – 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 Submission 35 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Beacon Frame Header field

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Beacon Frame Header field Value Protocol Version 0 Secure 0 Frame Type 0 (beacon frame) Frame Subtype 0 or 1 (NBP or FBP) Src. Addr Dev. Addr of the transmitter • Secure – Beacon security level • Frame Type Value Beacon 0 Command 1 Reserved 2 -3 – Command frames handle probing (IEs), application support, etc. • Frame Subtype Value Network beacon 0 Foreign beacon 1 Reserved 2 -7 • Src. Addr – Abbreviated 2 bytes Dev. Addr of the transmitter Submission 36 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Beacon Frame Payload •

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Beacon Frame Payload • octets: 10 Beacon Paramet ers L 1 … Information Element 1 LN … Information Element N octets: 6 1 1 IEEE 802 48 -bit MAC address Beacon Channel Number Beacon Sub-Channel Number Beacon Slot Number Device Control 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) bits: b 7 -b 6 b 5 -b 2 b 1 b 0 Security Mode Reserved Signaling Slot Movable • IEs – at least one: BP Occupancy IE and Location Information IE – BP switch IE – Channel change IE – Part 74 Occupancy IE – Etc. Submission 37 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Information Elements General Format

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Information Elements General Format Octets: 1 1 N Element ID Length (=N) IE-specific fields • 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 IEspecific fields that follow • The IE-specific fields contain information specific to the IE Submission 38 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Types of Information Elements

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 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 (P 74 OIE) • 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… Submission Foreign Beacon IEs 39 • Part 74 Occupancy IE (P 74 OIE) • Spectrum Occupancy IE • Prioritized Channel List IE (suggested for use by P 74 incumbent devices) • USU Quiet Period IE • Location Information IE • USU Descriptor IE • DEV Authentication IE • Etc… Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Types of Information Elements

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Types of Information Elements • Two IEs of key importance are described here: Beacon Period Occupancy IE (BPOIE) and Part 74 Occupancy IE (P 74 OIE) • BPOIE – Provides detailed information on the entire BP observed by the DEV sending the IE • P 74 OIE – Provides information on the channel usage by P 74 incumbent devices as known by the DEV sending the IE – Can be rebroadcast over multiple hops to increase protection to P 74 services and to offer better spatial reuse Submission 40 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Beacon Period Occupancy IE

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Beacon Period Occupancy IE (BPOIE) octets: 1 1 1 K 2 … 2 Element ID Length (=2+K+2×N) NBP Length FBP Length Mode Information Beacon Slot Info Bitmap Dev. Addr 1 … Dev. Addr N • • bits: 1 7 Mode Cycle Length 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 Dev. Addr list • List of corresponding Dev. Addr(s) from which a beacon was received in the previous superframe – Included in ascending beacon slot order – If received with an invalid HCS, the Dev. Addr is set to Bcst. Addr. Submission 41 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Beacon Slot Status Element

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Beacon Slot Status Element 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-movable A 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 & movable A 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 & movable A 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. Submission 42 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 (Non-)Movable Beacon Slot •

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 (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. Submission 43 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Part 74 Occupancy IE

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Part 74 Occupancy IE (P 74 OIE) octets: 1 1 1 2 7 Element ID Length (=2+7×N) Mode Information Dev. Addr Part 74 Usage Info 1 • Incremental or full dump • … Part 74 Usage Info N octets: 1 1 2 2 1 Channel No. Sub-Channel No. Start Time Duration RSSI Duration – Duration of P 74 service operation, if known Address of DEV who made the report • TV channel number of P 74 device Sub-Channel No. – • Cycle Length Channel No. – • Mode Dev. Addr – • 7 Mode Information – • bits: 1 7 RSSI – The received signal strength from the P 74 device, if known Sub-channel index within Channel No. , if known Start Time – Submission Start time of P 74 service operation, if known 44 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Sensing • A DEV

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 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 3 ms per TV channel to detect a WRAN Submission 45 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Beacon Transmission and Reception

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 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 P 74 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 m. BPExtention(8) slots after highest-numbered unavailable slot up to m. Max. BPLength/2. Submission 46 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Beacon Transmission and Reception

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 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 Submission 47 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Beacon Transmission and Reception

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 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 Submission 48 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Beacon Transmission and Reception

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 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 P 74 incumbent user, then there is no need to rebroadcast the P 74 OIE – 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 Submission 49 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 DEV Discovery by WRAN

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 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 P 74 device is operating? – A number of P 74 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 P 74 device or WRAN – Interference to co-channel WRANs; – Collision of DEV beacons; – Power consumption of DEVs; etc. Submission 50 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 DEV Discovery by WRAN

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 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 P 74 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 P 74 channels • Devices can take turn in beacon transmission and hence better mitigate fading and shadowing • Both solutions are supported Submission 51 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Power-saving Consideration • Need

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 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 m. BPExtension (8) • Invalid FCS • Detection of medium activity, but invalid HCS Submission 52 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Signaling Slot • To

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Signaling Slot • To inform the neighbor’s that its beacon slot is located beyond the BP length of any of its neigh – – • • • The device transmit the same beacon, except with the Signaling Slot bit set to one, in signaling beacon slot in 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 m. Max. Lost. Beacons superframes if needed, have to wait for at least m. Max. Lost. Beacons Submission 53 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Beacon Collision Resolution Upon

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 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 m. BPExtension beacon slots – located after the highest-numbered unavailable beacon slot it observed in the last superframe m. Max. BPlength Submission DEV 8 Collision in slot 5 DEV 8 • 54 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Beacon Collision Detection Overview

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Beacon Collision Detection Overview C B A • Dev. Addr (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 Dev. Addr in received BPOIE for a duration of m. Max. Lost. Beacons • Collision in up to 2 hops shall be detected and resolved (thus disallowed) G D E F CBAEF GD BPST beacon slot #5 (a-1) Beacon collision between one- hop neighbors CBADF GE BPST (a-2) Beacon collision between two- hop neighbors Submission 55 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Beacon Collision Detection Details

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Beacon Collision Detection Details (I) • Detection by aperiodically skipping sending beacon at least every m. Max. Neighbor. Detection. Interval – 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. C G A D E F B Submission 56 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Beacon Collision Detection Details

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 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 Dev. Addr is neither its own nor Bcst. Addr – two top collision • Its beacon slot has been reported as occupied and the corresponding Dev. Addr has been Bcst. Addr in the BPOIE of a beacon it received in the same beacon slot in each of the latest m. Max. Lost. Beacons superframes. G B Submission A C C 57 D E F Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Beacon Collision Resolution: Performance

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 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 theory, it is proved that it takes Θ(log 24) rounds before all users are allocated one noncolliding beacon slot Submission 58 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 DEV 2 Beacon Period

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 DEV 2 Beacon Period Contraction • If in the latest m. Max. Lost. Beacons (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 Submission 59 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Merging of Multiple BPs:

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Merging of Multiple BPs: Overview C B A • Unaligned BPSTs may come into range due to G D E F – Mobility – Changes in propagation – Channel change, etc. • Alien Beacon: a received beacon that indicates nonaligned BPST • Alien BP: The BP in alien beacon defined by CBA GE D F BPST 1 BPST 2 (b-1) Before merging the BPs GE D C FCBA – BPST – BP length BPST 2 (b-2) After merging the BPs Submission • Beacon collision 60 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Merging of Multiple BPs:

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 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*m. Guard. Time. • Two cases – Overlapping BPs – Non-overlapping BPs Submission 61 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Overlapping BPs • •

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Overlapping BPs • • • Corner case Align its BPST to the BPST of the alien BP Adjust beacon Slot Number – – • Either highest occupied beacon slot (in alien beacon) +1 Or join alien BP normally No transmission of beacon in former BP BPST 1 BP length CBA GE D F BPST 2 C B A (b-1) Before merging the BPs G D E F F C B A GE D C BPST 1 (b-2) After merging the BPs Submission 62 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Non-overlapping BPs BPST 1

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Non-overlapping BPs BPST 1 Alien BP CBA GE D F BPST 2 (b-1) Before merging the BPs G C B A D E F GE D C FCBA BPST 2 (b-2) After merging the BPs Submission 63 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Merging of Non-Overlapping BPs:

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 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: m. BPMerge. Wait. Time (say, 128 superframes) – The Second half of Superframe: 1. 5 xm. BPMerge. Wait. Time • If the first BP does not merge – Coordinate the BP merging by dissemination of BP switch IE Submission 64 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Coordinated BP Merging using

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Coordinated BP Merging using BP Switch IE octets: 1 1 2 Element ID Length (=4) BP Move Countdown Beacon Slot Offset BPST Offset Beacon Slot Offset CBA GE D F BPST 1 • Disseminate BP Switch IE • Advantage – when multiple alien BP exist, devices merge to the same BP – No beacon collision among devices after BP merging BPST 2 (b-1) Before merging the BPs GE D C FCAB BPST 2 (b-2) After merging the BPs Submission 66 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Dissemination of BP Switch

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 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 Submission 67 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Dissemination of BP Switch

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Dissemination of BP Switch IE (II) • Reset a countdown counter – Multiple hop devices merge to the alien BP – Reduced service disruption superframe A 1 (7, +3) 2 (7, +2) (7, +3) 3 (7, +1) (7, +2) (7, +3) 4 (7, +0) (7, +1) (7, +2) (7, +3) (7, +0) (7, +1) (7, +2) (7, +0) (7, +1) 5 6 B C D 7 8 9 F (7, +0) (a, b): (beacon slot offset, move countdown) Submission E Neighbors merge one after the other 68 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Dissemination Algorithm Submission 69

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Dissemination Algorithm Submission 69 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Beacon Relocation • At

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Beacon Relocation • At end of the superframe in which BP Move Countdown ==0 • Adjust BPST based on its BPST Offset • In the new BP (alien BP), relocate its beacon to slot number – Beacon Slot number + Beacon Slot Offset (≠ 0) – Otherwise (=0), join the alien BP normally • May skip one beacon transmission • Remove BP Switch IE in new beacon Submission 70 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Merging of Multiple BPs:

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 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 P 74 services Submission 71 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Conclusions Submission 72 Carlos

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Conclusions Submission 72 Carlos Cordeiro, Philips

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 Conclusions • We have

July 2006 doc. : IEEE 802. 22 -06/0130 r 0 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 – – Submission Assured protection to Part 74 services Fully distributed beaconing protocol Unidirectional and bi-directional communication Allows for better spectrum usage 73 Carlos Cordeiro, Philips