doc: IEEE July/2009 Zhen, Li and Kohno Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [NICTs MAC proposal for TG6] Date Submitted: [May, 2009] Source: [Bin Zhen, Huan-Bang Li and Ryuji Kohno] Company [National Institute of Information and Communications Technology (NICT)] Address [3-4 Hikarino-oka, Yokosuka, , Kanagawa, Japan] Voice:[ ], FAX: [ ], Abstract:[NICTs MAC proposal to TG6] Purpose:[In response to TG6 call for proposals] 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

doc: IEEE July/2009 Zhen, Li and Kohno Slide 2 Suggested TG6s MAC baseline (for proposal merging discussion) Bin Zhen, Huan-bang Li and Ryuji Kohno National Institute of Information and Communications Technology (NICT)

doc: IEEE July/2009 Zhen, Li and Kohno Slide 3 Baseline featuresComment Star topology limited tree topology extension Superframe structure – beacon, PAP CAP, and CFP – equal slot duration – minislot in CAP and priority time slot – fixed number of slot in superfrmae – number of slots in PAP, CAP and CFP is configurable – slot duration is configurable PAP= priority time slot + embedded priority period beacon is for superframe management CAP is mainly for channel request CFP is mainly for data (periodic and burst) PAP is only for emergency traffic slot is the basic timing unit in a superframe 4 or 8 minislots in a slot superframe parameters are TBD Power management – group superframe consists of active superframe and inactive superframe – distributed beacon listening – dynamic duty cycle no beacon broadcast in inactive superframe after listening to beacon, device can directly wakeup at the defined slot device are not needed to listen to every beacon B-E beacon broadcast Traffic classification – Medical event > voice > video > best effort data rate related classification? MAC Baseline features

doc: IEEE July/2009 Zhen, Li and Kohno Slide 4 Baseline featuresComment Beacon mode channel access in active superframe – slotted ALOHA in CAP – scheduled TDMA in CFP – contention based access in PAP to synchronize nodes via beacon CSMA can work over some PHYs traffic in PAP is low duty cycle POLL/POSTER command – can be random access – should be in CAP or CFP? QoS differentiation service – traffic-based transmit probabilities in CAP – exclusive GTS and generation GTS Non-beacon mode channel access in inactive superframe – handshake protocol (device initiative and coordinator initiative) – wakeup radio for very low duty cycle device to save power and implant in case of medical event switch between beacon mode and non-beacon mode non-beacon mode provides minimum function set wakeup radio is an add-on

doc: IEEE July/2009 Zhen, Li and Kohno Slide 5 Baseline featuresComment ACK policy – no ACK, imm-ACK, group-ACK – information piggybacked ACK (ip_ACK) delay ACK/ block ACK ip-ACK allows flexible re-transmission Device state and link management – battery description – traffic state – link stability and handover effective description of battery and traffic emergency? useful for multihop Coexistence and interference mitigation – TH and FH – wrapped superframe in time domain ? – inactive superframe sync. and asyn. of multiple BAN? coexistence of medical and non-medical traffic MAC header and frame type – short MAC head – frame type visible at MAC header mixed of data and MAC command Security