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: [Requirements and Objectives for Mesh Networking using the 802.15.3 MAC] Date Submitted: [06 April, 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 describe requirements, assumptions and objectives for the work.] Purpose:[Starting point for discussion during the April 6, 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. Target Application Environment • Consumer Residential (and incidental light commercial) • Up to whole home coverage • Mix of audiovisual, communications and IT applications including (but not constrained to) • Television, including DVD, distribution HD and SD • Digital audio • Multiplayer games • Web browsing, file transfer, email, IM, etc. • IP telephony, videotelephony,video conferencing

3. Target Physical Environment • Principally Indoor • Four reference premises • 4800 sq. ft (446 m2) single family occupancy, having two stories on a 60’x40’ (18 m x 12 m) footprint and 8’ (2.4 m) between floors • One unit of a two story duplex, with units of 1300 sq. ft (121 m2) each, having a footprint of 36’x36’ (11 x 11 m) • One unit of a 4 unit townhouse, two story units of 2400 sq. ft. (223 m2) each, each with a footprint of 30’x40’ (9 m x 12 m) , total footprint 120x40 (37 m x 12m) • One unit of a high rise building, 7 units per floor, each unit 1080 sq. ft (100 m2) with a 30’ x 36’ (9 m x 11 m) footprint, total footprint 120’ x 80’ (37 m x 24 m), including a 36’x 30’ (11 m x 9 m) common space with elevator (lift) bank, utility closet with risers and rubbish chute. • Meshes with overlapping coverage (different owners) possible • Must make sure they don’t interfere or accidentally join

4. Services • Edge-to-edge frame delivery • Frame delimitation • Maximum MAC-SDU size at least 1536 bytes • In-order delivery (with very high probability) • Strong error detection, equivalent in power to a CRC-32 • A connectionless (stateless) pure best effort service, • No notion of a traffic contract or QoS objectives • Optional rate guarantees • A connection-based (stateful) variable bitrate-like service • intended for bursty traffic • QoS objectives for packet delay variation and packet loss • A connection-based (stateful) constant bitrate-like service • Intended for constant rate traffic, • QoS objectives for packet delay variation and packet loss • A connection-oriented isochronous service • Intended for extremely jitter sensitive traffic • QoS objectives for packet delay jitter and packet loss • Unicast, Broadcast and Multicast • Optional delay equalization for correlated unicast and multicast streams arriving at different destination end systems

5. Topology • One channel • Size (# of DEVs): • Median: ≈ 20 • Absolute worst case: ≈ 200 • Degree • Depends on physical topology, radio characteristics, possiblyTx power control • Should try to be at least 2-connected • Diameter • Median: 3 hops • Nominal worst case: 5 hops • Max: Limited by delay constraint of application • Mobile and Fixed DEVs • Mobile DEVs primarily battery powered • Fixed DEVs primarily mains powered • All DEVs subject to device handovers due to: • DEV moves • Link failure As well as PNC handovers • Pedstrian speed mobility • Must be self-organizing • At least one DEV capable of human interaction for management

6. Radio • Omnidirectional antennas • Channel environment • Combination of AWGN LOS (CM1), Multipath (CM2), NLOS (CM3) • Non-stationary due to moving objects and mobile DEVs • Symmetric • Nominal reach (AWGN LOS) is 8.5 M at about 500 Mbit/s • Battery powered DEVs • Sleep mode (DSPS, PSPS)

7. Edge to Edge Performance • Throughput • Isochronous, CBR or VBR stream • Nominal worst case payload bitrate: 19.4 Mbit/s (i.e., ATSC HD distribution television) • Extreme worst case: 38.8 Mbit/s (i.e., E-ATSC HD Distribution television with MPEG2 coding) • Packet rate: 8000 packets/s (interdeparture time = 125µs) • Asynchronous stream • As fast as possible! • Target: ≈ 80 Mbit/s (transfer 240 MByte movie in ≈ 30 s) • Extreme worst case: about 1/3 of lowest PHY rate on path • Delay • As small as possible • Depends on topology, coverage etc. • Target for 5 hops ≈ 20 ms • Peak-peak Delay Jitter • Isochronous and CBR streams: Target ≈ 10 µs • VBR streams: 1 superframe time max

8. System Considerations • Modifications to the 802.15.3 MAC should be minimized. • Incremental functionality should be in a new mesh layer • Non-mesh aware devices will not be able to fully participate in the mesh • Non-mesh aware DEVs be able to communicate within a piconet that doesn’t include the mesh. • Perfectly optimal utilization is not a design objective • Such an objective would inevitably lead to computationally intractable (“NP-complete” or “NP-hard”) problems. • Reasonable steps should be taken to avoid waste in the form of extra hops, fragmentation, duplicative overhead, signaling overhead, etc. • Must respect transmit time/power averaging limits • Tradeoff between transmit power/bit rate and spatial reuse to favor short bursts at high bitrates even if fewer transmitter/receiver pairs are 3rd adjacent or better • Processing load for the mesh should be spread as fairly as possible between mains-powered DEVs. • Choice of distributed or centralized approaches to specific computational problems • To be made on a case-by-case basis. • Needs to balance available capacity in DEV performing the necessary computations in a centralized approach against signalling and computational overhead associated with a distributed approach. • Battery powered DEVs, especially those in power-save modes, should never be PNCs, and will rarely be required to forward packets.