Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)

1. Project: IEEE P802.15 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 37-724, Korea, ] Voice:[1858-229-4822, 2+82-2-526-4065], FAX: [1858-485-1528], E-Mail:[1last name at ieee dot org, 2bjjeon at lge dot com] Re: [15-07-0532-00-003c] 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 P802.15. 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 P802.15. James P. K. Gilb, SiBEAM

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

3. 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 • 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 • 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 • 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 • 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 • 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. Types of piconets in 802.15.3 • 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 • Section 8.2.5 in IEEE Std 802.15.3-2003 • Allows 802.15.3 piconets to share channel time and avoid interference. • Child PNC is full member of parent piconet • Neighbor network • Section 8.2.6 in IEEE Std 802.15.3-2003 • Specifically allows non-802.15.3 piconets to interoperate with 802.15.3 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 James P. K. Gilb, SiBEAM

12. Child piconet MSC James P. K. Gilb, SiBEAM

13. 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 James P. K. Gilb, SiBEAM

15. Neighbor piconet MSC James P. K. Gilb, SiBEAM

16. 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 • PNC handover is a key part of the 802.15.3 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. Dependent handover (1) James P. K. Gilb, SiBEAM

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

20. 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 James P. K. Gilb, SiBEAM

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

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

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

25. 802.15.3 reference architecture James P. K. Gilb, SiBEAM

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

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

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

29. Conclusions for New Common Mode Approach • Simple method • Low cost • Works with non 802.15.3 devices • Promotes spatial re-use • Time sharing allowed for devices that want the complexity • Already optional in 802.15.3 • 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