IEEE 802.15.2 DRAFT RECOMMENDED PRACTICE Clause 14: Collaborative Coexistence Mechanism – IEEE...

Preview:

Citation preview

IEEE 802.15.2 DRAFT RECOMMENDED PRACTICEClause 14: Collaborative Coexistence Mechanism – IEEE 802.11 and 802.15.1

Steve Shellhammer (Symbol Technologies)

Jim Lansford, Adrian P Stephens(Mobilian Corporation)

Outline Introduction (5) Collaborative Mechanism (14)

(MAC Layer Solution) Simulation Result (4) Conclusion Reference

Introduction (1/5) 4 Task Groups

TG1: WPAN/Bluetooth TG2: Coexistence TG3: WPAN High Rate TG4: WPAN Low Rate

1 Public Committee

Introduction (2/5) 802.15.2 Scope

To develop a recommended practice for an IEEE 802.15 Wireless Personal Area network that coexists with other selected wireless devices operating in unlicensed frequency bands

Introduction (3/5) Two Categories:

Collaborative Mechanism (Collocated) To be defined as a coexistence

mechanism where WPAN and WLAN exchange information between one another to minimize mutual interference

Non-Collaborative Mechanism No exchange of information is used

between two wireless

Introduction (4/5)Presenter Title Non- / Collaborative Author Classification

NIST 802.11b Deterministic Frequency Nulling Collaborative R.E. Van Dyck PHY -- OptionMobilian Method for Coexistence Collaborative J. Lansford Time Domain SchedulingSymbol TDMA of BT and 802.11 Collaborative S. Shellhammer Time Domain Scheduling

TI

Proposal for Collaborative Bluetooth and802.11b MAC Mechanisms for Enhancing

Coexistence Collaborative J. Liang Time Domain Scheduling

TIProposal for Non-Collaborative BluetoothMechanisms for Enhancing coexistence Non-Collaborative J. Liang Adaptive Packet Selection, Scheduling

NISTPower Control and Packet Scheduling for

Bluetooth Non-Collaborative N. Golmie Scheduling, Power Control (PC)

Bandspeed Adaptive Frequency Hopping Non-Collaborative H. Gan, B. Treister AFH -- Adaptive Frequency HoppingIPC, Inc. Selective Hopping for Hit Avoidance Non-Collaborative K.C. Chen AFH, Scheduling

TI Proposal for Intelligent Bluetooth Frequency

Hopping for Enhancing Coexistence Non-CollaborativeA. Batra, J. M. Ho,K. Anim-Appiah AFH

TI Power Control for Enhanced Coexistence Non-Collaborative O. Eliezer AFH

TIProposal for 802.11b Power Control for

Enhancing Coexistence Non-Collaborative M. ShoemakePower Control (PC), Data Rate Scaling(DRS)

Combined proposal

Combined proposal

Introduction (5/5) Non-collaborative mechanism

summary: AFH (Adaptive Frequency Hopping) Adaptive Packet Selection and Scheduling Transmit Power Control / Rate Scaling

Collaborative mechanism summary : Per-Transmission Request/Confirm TDMA-Base Mechanism

Collaborative Mechanism Introduction Collaborative Mechanism (14)

(MAC Layer Solution) Simulation Result Conclusion Reference

Collaborative Mechanism (1/14)

By sharing information between collocated 802.11 and 802.15.1 stacks and locally controlling transmissions to avoid interference

No new on-air signaling is required Be interoperable with devices that

do not include it

Collaborative Mechanism (2/14)

Overall Structure:

802.11MAC

802.15.1 LM+ LC

802.11 PLCP+ PHY

802.15.1Baseband

TDMAControl

MEHTAControl

Status Status

Tx Enable Tx Enable

Tx Confirm(status)

Tx Confirm(status)

Tx RequestTx Request

CollaborativeCoexistenceMechanism

802.11 Stack 802.15.1 Stack

AWMAControl

Collaborative Mechanism (3/14)

AWMA Control Entity 802.11 AP and 802.15 master are

collocated MEHTA Control Entity

802.11 STAs and 802.15 slaves are collocated

Collaborative Mechanism (4/14) Alternating Wireless Medium Access

Feature: 802.15 master and 802.11 AP should

collocated in the same physical unit 802.11 STAs are synchronized by AP 802.11 AP should send a physical

synchronization signal to 802.15 master

WPAN slavers’s ACL data transmission is controlled by 802.15 master

Limitation: Could not support SCO link

Collaborative Mechanism (5/14)

AWMA

W P A N In te rv a lW L A N In te rv a l

T B T T

M ed iu mF ree

T ru e

F a lse

W P A N In te rv a lW L A N In te rv a l

BT

W LA NT W P A NT

T B T T

1T

TBTT

Collaborative Mechanism (6/14)

Structure of the MEHTA Entity

802.11MAC

802.15.1 LM+ LC

802.11 PLCP+ PHY

802.15.1Baseband

802.15.1Control

Status Status

Tx Confirm(status)

Tx Confirm(status)

Tx Request

Tx Request

MEHTAControl

802.11 Stack 802.15.1 Stack

802.11Control

Collaborative Mechanism (7/14)

Known Physical-Layer Characteristic 802.11b pass-band 802.15 hopping pattern

Local 802.11 Activity

Local 802.15.1 Activity

Transmit Receive

In-band Out-of-band In-band Out-of-band

Transmit Transmit None Transmit-Receive or None

Transmit-Receive or None

Receive Transmit-Receive or None

Transmit-Receive or None

Receive None

Collaborative Mechanism (8/14) Known 802.11 States:

Current or expected receive and transmit activity

Channel number Current State End Time

802.11 Tx Request State: Packet Type Duration

Collaborative Mechanism (9/14)

Known 802.15 States: Current or expected receive and

transmit activity Channel List Duration Time Remaining

CurrentCollision? Yes

No

Tx Request

Denied

Yes

FutureCollision?

802.15.1Future slotpriority >

802.11 packetpriority ?

Yes Yes

No

Allowed

No

No Yes

No

802.15.1Current slot

priority >802.11 packet

priority ?

Is 802.15.1Currently

Transmitting?

Decision Logic for 802.11 Tx Request

Collaborative Mechanism (11/14)

Access Mechanism

Effect of Tx Confirm (status=denied)

DCF The denied result appears to be a transient carrier-sense condition that requires a DIFS time to expire before a subsequent transmit request can be made. The denied result has no effect on the contention window (CW) or retry variables because no transmission has occurred.(But it’s will aggregate collision…)

PCF(as CF-pollable STA)

No transmission from the STA occurs, and the AP can resume transmission after a PIFS.(But it’s will cause wasting…)

PCF as PC No transmission from the AP occurs, and the AP can resume transmission after a PIFS.

Decision Logic for 802.15 Tx Request

Responseor

SCO?

Yes

Collision?

802.11current state

priority >802.15.1 packet

priority ?

Yes

No

No

Collision?Slave SlotCollision?

no

NoNo

Tx Request

Allowed

Denied

Yes Yes

Yes

Collaborative Mechanism (13/14)

Recommended Priority Comparison An 802.11 ACK MPDU should have a

higher priority than all 802.15.1 packets

An 802.15.1 SCO packet should have a higher priority than 802.11 DATA MPDUs.

Other priority comparisons are a implementation-specific

Collaborative Mechanism (14/14) Maintaining QoS

A device can optionally monitor QoS by defining metrics (such as PER and delay)

Maintaining SCO QoS An implementation can optionally attempt to

maintain SCO QoS so as not to exceed some level of SCO packet loss by monitoring the SCO PER and comparing with a threshold. The priority of the SCO packet is increased when the SCO PER is above the threshold.

Simulation Result (4) Introduction Collaborative Mechanism (MAC

Layer Solution) Simulation Result Conclusion Reference

0

1

2

3

4

5

6

7

8

0 10 20 30 40 50 60 70 80 90 100Received Signal Power (-dBm)

Th

rou

gh

pu

t (M

b/s

)

BT=OFF (measured) BT=1m (measured)

BT=OFF (simulated) BT=1m (simulated)

Simulation Tool accurately models

experimental WLAN / BT performance

Experimental Results (1/4)

Conference Room Usage (2/4)

Many stations, each with independent piconets

Bluetooth speakerphone As before, aggregate

throughput is shared among all users

0

1

2

3

4

5

6

7

8

1 10 100 1000

Distance from AP (m)

WL

AN

Th

rou

gh

pu

t (M

b/s

)

no interference non TR TR

Back to Single User Scenario

Conference Room ScenarioConference Room Scenario

Office Usage Model (3/4) Cluster of users in

cubicles, each of which has an independent piconet

Throughput is aggregate throughput measured from Access Point

0

1

2

3

4

5

6

7

8

1 10 100

Distance frpom AP (m)

WL

AN

Th

rou

gh

pu

t (M

b/s

)

no interference non TR TR

Back to Single User Scenario

Office ScenarioOffice Scenario

Individual User (4/4)

BT headset operating from same laptop as Wi-Fi station

0

1

2

3

4

5

6

7

8

1 10 100 1000

Distance from AP (m)

WL

AN

Th

rou

gh

pu

t (M

b/s

)

no interference non TR TR

Individual ScenarioIndividual Scenario

Conclusion Introduction Collaborative Mechanism

(MAC Layer Solution) Simulation Result Conclusion Reference

Conclusion The Combination of two proposal

should revise to be more meaningful

There might be some research topic address to the coexistence issue in the 802.11 point of view

The QoS mechanism under the coexistence condition might be a discussible issue as well.

Reference(1/2) TG2 Submission Matrix

IEEE P802.15 Doc 01/078r0 TG2 Coexistence Mechanism Summary Matrix

IEEE P802.15 Doc 01/078r2 IEEE 802.15.2 Clause 14.1 - Collaborative Coexistence

Mechanism IEEE P802.15 Doc 01/340r0

TG2 Mobilian Draft Text IEEE P802.15 Doc 01/300r1

Clause 14.3 - Adaptive Frequency Hopping IEEE P802.15 Doc 01/366r1

Reference(2/2) Clause 1 - Scope and Purpose

IEEE P802.15 Doc 01/313r1 Clause 5.1 - Description of the Interference Problem

IEEE P802.15 Doc 01/314r0 Clause 5.3 - Overview of Coexistence Mechanisms

IEEE P802.15 Doc 01/363r0 Clause 14.2 - MAC Scheduling Mechanism

IEEE P802.15 Doc 01/316r0 Collaborative Coexistence Mechanism Submission:

META + TDMA IEEE P802.15 Doc 01/164r0

Recommended