1. 13 November, 2007
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: [Coexistence with 60 GHz systems]
Date Submitted: [13 November, 2007]
Source: [James P. K. Gilb1, BeomJin (Paul) Jeon2] Company [1SiBEAM, 2LG Electronics Inc.]
Address [1555 N. Mathilda, Suite 100, Sunnyvale, CA 94085, 216 Woomyeon-Dong, Seocho-Gu, Seoul , Korea, ]
Voice:[ , ], FAX: [ ], [1last name at ieee dot org, 2bjjeon at lge dot com]
Re: [ c]
Abstract: [Coexistence mechanisms for devices operating in the 60 GHz band.]
Purpose: [This document proposes a method for coexistence among devices operating in the 60 GHz band.]
Notice: This document has been prepared to assist the IEEE P 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 acknowledges and accepts that this contribution becomes the property of IEEE and may be made publicly available by P
James P. K. Gilb, SiBEAM

2. Common Mode Ideas for 802.15.3c 13 November, 2007
James P. K. Gilb, SiBEAM

3. Three classes of devices
13 November, 2007
Three classes of devices
LOS – shorter range, ultra low power
Single carrier
Simple connectivity
NLOS – A/V streaming
OFDM for NLOS
Beam steering
CDEV - Combination LOS/NLOS device
Supports both LOS and NLOS protocols
James P. K. Gilb, SiBEAM

4. Goals Coexistence Interoperation
13 November, 2007
Goals
Coexistence
Minimize impact of nearby networks through cooperation
Interoperation
Allow LOS, NLOS, and CDEV devices to exchange data
Potentially high data rates (> 1 Gb/s)
Exchange of data between LOS and NLOS devices may require presence of CDEV devices
Minimal impact on single protocol DEVs
Low complexity and cost for LOS DEVs
Full range and and capabilities for NLOS DEVs
James P. K. Gilb, SiBEAM

5. Possible Solution: Common Mode via Scheduling
13 November, 2007
Possible Solution: Common Mode via Scheduling
TDMA protocols can allocate time for any use
One CDEV links the two networks together
Acts as PNC in at least one network
Requests CTBs in the other network
Bridges data between networks
Each network is optimized for its use case
Time is allocated for each network
No throughput lost to collisions
QoS is preserved as well
Common PHY modes not required
MAC parameters for two network can be independently tuned for NLOS streaming QoS and LOS low power
James P. K. Gilb, SiBEAM

6. Spatial Reuse Consideration
13 November, 2007
Spatial Reuse Consideration
The directivity of mmWave
We pay much for it. Now we have to use it.
That is : It is highly possible that we can make two separate transmissions at the same time without any interference to each other if the beams are not overlapped (If the paths are independent).
Issues are how to check the path independency and how to resolve it when it happens due to mobility of devices.
James P. K. Gilb, SiBEAM

7. Quality of Experience Consideration
13 November, 2007
Quality of Experience Consideration
The sensitivity of “user” to the interference
Even though there is interference, we can bear it if the minimum QoE can be maintained.
That is : Interference may mean only transmission speed degradation to a user who is doing file transfer. We shall not prevent a user do his job at its minimum performance if it dose not interfere existing higher priority transmission.
Issues are how to detect priority level of applications which are running on the devices using different PHYs and how to detect the interference that a device cause to its superior application if it does.
James P. K. Gilb, SiBEAM

8. Optimal Coexistence Mechanism Consideration
13 November, 2007
Optimal Coexistence Mechanism Consideration
TDD may not be optimal for IEEE 15.3c
Even though TDD over common scheduling may be clear way to prevent interference between different PHY systems, it is not optimal for mmWave because it allow only one transmission at a time. No consideration for directivity of mmWave it uses and no consideration of QoE impact.
Rather, we’d should investigate optimal way that enables more connections, at the same time, managing QoE of each application.
James P. K. Gilb, SiBEAM

9. 13 November, 2007
Types of piconets in
Independent piconet: A piconet with no dependent piconets and no parent piconets.
Parent piconet: A piconet that has one or more dependent piconets.
Dependent piconet: A piconet that requires a time allocation in another piconet, called the parent piconet, and is synchronized with the parent piconet’s timing.
James P. K. Gilb, SiBEAM

10. Dependent piconets in 802.15.3 Child network Neighbor network
13 November, 2007
Dependent piconets in
Child network
Section in IEEE Std
Allows piconets to share channel time and avoid interference.
Child PNC is full member of parent piconet
Neighbor network
Section in IEEE Std
Specifically allows non piconets to interoperate with piconets
Only PNC of neighbor piconet needs to support protocol of parent piconet
James P. K. Gilb, SiBEAM

11. Child piconet illustration in 802.15.3
13 November, 2007
Child piconet illustration in
James P. K. Gilb, SiBEAM

12. 13 November, 2007
Child piconet MSC
James P. K. Gilb, SiBEAM

13. Starting a child piconet
13 November, 2007
Starting a child piconet
DEV associates with an existing piconet
Gets regular DEVID
Authenticates, if a secure piconet
Request channel time from PNC
If successful, allocation has SrcID = DestID = DEVID of requesting device
Allocation is a pseudo-static CTA
Once allocation has been granted
DEV can begin beaconing
James P. K. Gilb, SiBEAM

14. Neighbor Piconet Illustration in 802.15.3
13 November, 2007
Neighbor Piconet Illustration in
James P. K. Gilb, SiBEAM

15. 13 November, 2007
Neighbor piconet MSC
James P. K. Gilb, SiBEAM

16. Starting a neighbor piconet
13 November, 2007
Starting a neighbor piconet
DEV associates with an existing piconet
Gets neighbor DEVID (NbrID: 0xF7-0xFA)
Is not required to authenticates
Request channel time from PNC
If successful, allocation has SrcID = DestID = NbrID of requesting device
Allocation is a pseudo-static CTA
Once allocation has been granted
DEV can begin beaconing
James P. K. Gilb, SiBEAM

17. Handover for dependent piconets
13 November, 2007
Handover for dependent piconets
PNC handover is a key part of the system.
Handover for dependent piconets is more complicated than regular PNC handover
One difference is that the CTA in the parent piconet is ‘owned’ by the dependent PNC
James P. K. Gilb, SiBEAM

18. 13 November, 2007
Dependent handover (1)
James P. K. Gilb, SiBEAM

19. 13 November, 2007
Dependent handover (2)
James P. K. Gilb, SiBEAM

20. Handover failures Regular PNC handover cannot be refused
13 November, 2007
Handover failures
Regular PNC handover cannot be refused
Dependent PNC handover, however, can be refused
The selected dependent PNC may be unable to join the parent network
It may fail to gain control over the dependent network’s CTA
James P. K. Gilb, SiBEAM

21. Handing over control of CTA
13 November, 2007
Handing over control of CTA
James P. K. Gilb, SiBEAM

22. Failed handover, unable to join parent piconet
13 November, 2007
Failed handover, unable to join parent piconet
James P. K. Gilb, SiBEAM

23. Failure to get CTA transferred (1)
13 November, 2007
Failure to get CTA transferred (1)
James P. K. Gilb, SiBEAM

24. Failure to get CTA transferred (2)
13 November, 2007
Failure to get CTA transferred (2)
James P. K. Gilb, SiBEAM

25. 802.15.3 reference architecture
13 November, 2007
reference architecture
James P. K. Gilb, SiBEAM

26. Bridging data Data can be bridged using 802.1
13 November, 2007
Bridging data
Data can be bridged using 802.1
Already used to bridge LAN to WLAN
A/V bridging is under development
has interface to 802.1
Annex A (normative)
James P. K. Gilb, SiBEAM

27. 13 November, 2007
802.2/802.1 interface
James P. K. Gilb, SiBEAM

28. Child PNC bridging data between piconets
13 November, 2007
Child PNC bridging data between piconets
James P. K. Gilb, SiBEAM

29. Conclusions for New Common Mode Approach
13 November, 2007
Conclusions for New Common Mode Approach
Simple method
Low cost
Works with non devices
Promotes spatial re-use
Time sharing allowed for devices that want the complexity
Already optional in
Market will drive adoption levels
We should allow implementations, if desired, but not required.
Common radio can be employed for bridge systems
Both methods permit minimal change while preserving advantages of each architecture
James P. K. Gilb, SiBEAM