Mesh Issues Outline: Enhancing 802.15.3b MAC for Ad-Hoc Networks

1. Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Issues Outline for Mesh Using the 802.15.3b MAC] Date Submitted: [22 March, 2005] Source: [Dan Grossman] Company [Motorola.] Address [111 Locke Drive Marlborough, MA USA 01752] Voice:[+1 508 786 7527] E-Mail:[dan.grossman@motorola.com] Re : [] Abstract:[At the March 2005 Plenary, WG 3b asked the author to lead an ad-hoc activity to frame a proposal to build upon, and extend where nececessary, the 802.15.3b MAC to operate as an ad-hoc mesh network. This contribution attempts to outline the major issues that will need to be addressed.] Purpose:[Starting point for discussion during the March 23, 2005 conference call] 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.

2. Why 802.15.3b is “Different”

3. Streams • Supports both connection oriented data transfer (i.e., streams) and connectionless data transfer. • Mechanisms for connection establishment (i.e., CTRq), modification, handover and release. • Most extant mesh architectures assume purely connectionless data transfer at the MAC layer. • Rate reservation needed to achieve QoS objectives for some kinds of streams. • Capacity limits must be observed during stream establishment. • Capacity limits of the shared medium ((link rate * number of TUs in the superframe) – overhead) • Spatial reuse • Derating for retransmission due to link error rate • DEVs might have limited frame forwarding rates. • Need for per-hop admission control and capacity-sensitive path computation. • Changes in link throughput need to be signalled in a timely fashion to the PNC so that CTA duration and frequency can be appropriately adjusted. • In-order delivery • At each forwarding hop, frames must wait at each for a CTA associated with that stream. • Latency due to arbitrary placement of CTAs will result on an average wait of ½ superframe time per hop. • May result in end-to-end delays which are unacceptable to some applications. • Need to minimize per-hop processing, not preclude hardware based forwarding

4. TDMA mediated by PNC(s) • MAC uses TDMA • Channel access and timing mediated by centralized Piconet Controller (PNC) • Hierarchy of child PNCs • Other meshing schemes • Tend to use ALOHA- or CSMA-based MAC • Infrastructure (e.g., 802.11 APs) mediates access (e.g. by polling), but not timing. • Implications: • Every DEV (especially child PNCs) must be must be able to receive beacon from a PNC. • Need to select DEVs to become PNCs, so that coverage is achieved. • The timing of private CTAs locked to the timing of the superframe signalled from root PNC – even if descendant PNCs cannot receive the beacon sent by the root. • Loss of a PNC is fatal. PNCs might not have time to perform handover. Need to failover cleanly. • Number of TUs allocated to a flow will vary at different hops at different times. • Mobile DEVs need handover as they transit from in range of one PNC to another

5. Coverage • MAC implicitly assumes that the coverage area of a piconet (and all of its child and/or neighbor piconets) is not larger than the nominal range of the PHY. • Proposed 802.15.3a PHYs are short range. • Coverage beyond a radius of several metres will cause nodes to be hidden from each other. • Multi-hop forwarding capability to permit end-to-end communications between DEVs out of range of each other • “Orphan” DEVs that can’t see a PNC but can see other DEVs

6. Functional Areas To Be Addressed

7. High Level Considerations • Functional Requirements • Beyond the IEEE P802.15-04/655 TG5 Technical Requirements • Functional Partitioning • Services • “QoS” • Addressing and Identifiers • Topology • Will need different “views”

8. Mesh Organization • Startup • Scanning and Discovery • Partitions and “Orphans” • Selecting DEVs to become PNCs • Establishing connectivity between PNCs • Reorganizing when topology changes • PNC Failover (was “Next PNC”) • Communication between PNCs • Mesh Sublayer Protocols for startup and reorg

9. Device Association • How Mesh layer association relates to MAC layer association • Association • Handover • Disassociation • Piconet services • PNC-PNC association management protocol

10. Forwarding • Next-hop information • Forwarding process • ACKs • Relationship to streams

11. Routing • Key decisions • Reactive vs proactive • State-based vs flooding • Centralized vs decentralized • Link state vs distance vector • Hop-by-hop vs source • …. • Topology database • Metrics, constraints • Path calculation • Topology discovery • Topology update

12. Streams • Stream Management • Establishment • Modification • Handover • Release • Private CTA allocation • Pseudostatic CTA coordination • Admission Control • PNC-PNC stream establishment protocol

13. PHY/MAC/Mesh Interactions • Transmit power control • Link quality assessment • Dynamic rate control Interactions with • CTA allocation • PNC selection • Topology/connectivity • Routing metrics/constraints • Path calculation • DEV handover • PNC failover