IEEE 802.11-00/181 Submission March 2001 Peter Johansson / Congruent Software, Inc.– 1 – IEEE P802.11e A quality transport for IEEE 1394? Peter Johansson

  • View
    214

  • Download
    0

Embed Size (px)

Text of IEEE 802.11-00/181 Submission March 2001 Peter Johansson / Congruent Software,...

  • Slide 1

IEEE 802.11-00/181 Submission March 2001 Peter Johansson / Congruent Software, Inc. 1 IEEE P802.11e A quality transport for IEEE 1394? Peter Johansson Congruent Software, Inc. Chair, IEEE P1394.1 Slide 2 IEEE 802.11-00/181 Submission March 2001 Peter Johansson / Congruent Software, Inc. 2 Why should IEEE 802.11e care? IEEE 1394 is the transport chosen for consumer electronics equipment More rapid deployment in these entertainment applications than in computer productivity applications Wide-spread deployment of home networks likely for entertainment, not productivity Initial home networks likely to rely on wireless technology Slide 3 IEEE 802.11-00/181 Submission March 2001 Peter Johansson / Congruent Software, Inc. 3 Wireless home network topology Wireless domain is home network backbone Eliminate (or defer) retrofit costs to existing houses Device clusters (hard-wired) within rooms Wireless bandwidth is a severe constraint Multiple domains may ease the problem KitchenBedroom Wireless Living RoomBedroom Office Wireless Slide 4 IEEE 802.11-00/181 Submission March 2001 Peter Johansson / Congruent Software, Inc. 4 Alternate home network topology Wireless domain is a leaf connected to the wired home network backbone Mobility support for devices carried from room to room Wireless Living Room Bedroom Office Wiring Closet KitchenBedroom Slide 5 IEEE 802.11-00/181 Submission March 2001 Peter Johansson / Congruent Software, Inc. 5 What needs to be done? Develop methods to mimic IEEE 1394 behaviors within an 802.11 services set Wireless endpoint devices (DTV, DVCR, etc. ) Develop methods to connect an 802.11 services set to IEEE 1394 Wireless endpoint devices interoperate with wired endpoint devices Wired endpoint devices interoperate with each other via an intermediate 802.11 services set Slide 6 IEEE 802.11-00/181 Submission March 2001 Peter Johansson / Congruent Software, Inc. 6 Scope of work 1 Investigate the suitability of IEEE 802.11 2 Design a protocol adaptation layer (PAL) specific to IEEE 802.11 3 Specify bridges to interconnect the wired and wireless domains Essentially complete in draft standard IEEE P1394.1 4 Profile the details of P1394.1 specifically applicable to bridges for IEEE 802.11 Slide 7 IEEE 802.11-00/181 Submission March 2001 Peter Johansson / Congruent Software, Inc. 7 What is a PAL? A glue layer on top of a lower level IEEE 802.11 Application 1394 PAL Hides low-level details of underlying layer Mimics high-level behavior of target protocol For example, IP1394 is a PAL that permits Internet protocol to be carried by IEEE 1394 Slide 8 IEEE 802.11-00/181 Submission March 2001 Peter Johansson / Congruent Software, Inc. 8 What use is a PAL? Leverages applications already developed Applications developed for IEEE 1394 expect: Read, write and lock transactions Infrastructure CSRs and configuration ROM Isochronous services IEEE 802.11 Application 1394 PAL IEEE 1394 Application Slide 9 IEEE 802.11-00/181 Submission March 2001 Peter Johansson / Congruent Software, Inc. 9 Wireless products enabled Firmware developed for (wired) IEEE 1394 products can migrate to wireless domain Minimize reengineering between wired and wireless domains IEEE 802.11 DVCR 1394 PAL IEEE 802.11 DTV 1394 PAL Slide 10 IEEE 802.11-00/181 Submission March 2001 Peter Johansson / Congruent Software, Inc. 10 1394 PAL ground rules Shall support IEEE 1394 TRAN layer functions Read, write and lock Shall support isochrony and streaming data Shall coexist with other users of the underlying IEEE 802.11 transport Should behave like IEEE 1394 Should conceal differences between IEEE 1394 and IEEE 802.11 physical and link layers Slide 11 IEEE 802.11-00/181 Submission March 2001 Peter Johansson / Congruent Software, Inc. 11 Connect wireless to wired? 1394 PAL for IEEE 802.11 permits wireless devices to talk to each other Not interesting unless wireless devices can also talk to (wired) IEEE 1394 devices IEEE 1394 IEEE 802.11 ? Slide 12 IEEE 802.11-00/181 Submission March 2001 Peter Johansson / Congruent Software, Inc. 12 Wired to wireless via bridges Bridge isolates physical and link layer differences in each domain from the other Bridge preserves transaction layer similarities Transaction routes configured autonomously Explicit isochronous stream setup / tear down IEEE 1394 IEEE 802.11 Slide 13 IEEE 802.11-00/181 Submission March 2001 Peter Johansson / Congruent Software, Inc. 13 Wired across wireless via bridges Wireless domain serves as backbone to connect wired clusters in different rooms Reduces installation costs of home network Bandwidth limitations of wireless may limit the longevity of this strategy IEEE 802.11 IEEE 1394 Slide 14 IEEE 802.11-00/181 Submission March 2001 Peter Johansson / Congruent Software, Inc. 14 portal 0portal 1 internal fabric cycle clock Bridge model Common cycle clock (synchronized to one portal) Internal fabric implementation-dependent Stores and forwards IEEE 1394 primitives Read, write and lock requests and responses Isochronous stream data Neither a router nor aware of higher-level protocols Slide 15 IEEE 802.11-00/181 Submission March 2001 Peter Johansson / Congruent Software, Inc. 15 1394 Trade Association project scope Develop a document that specifies methods to a) mimic IEEE 1394 infrastructure (transactions, isochrony, stream data, configuration ROM and CSR architecture) using the facilities of IEEE 802.11 and b) implement IEEE P1394.1 bridge behaviors in the same domain. The methods are to be compatible with the simultaneous use of IEEE 802.11 by other protocols, e.g., Internet protocol. Slide 16 IEEE 802.11-00/181 Submission March 2001 Peter Johansson / Congruent Software, Inc. 16 Whats needed from IEEE 802.11? Isochronous data requires: Scheduled availability of the wireless medium High probability that data payload is successfully delivered In a nutshell: reliable quality of service All other mappings of IEEE 1394 behavior to the 802.11 MAC are reasonably straightforward Slide 17 IEEE 802.11-00/181 Submission March 2001 Peter Johansson / Congruent Software, Inc. 17 What does isochronous really mean? isochronous \ adj [Gk isokronos] (1706) : uniform in time; having equal duration; recurring at regular intervals isochronous \ adj [Gk isokronos] (1706) Send it soonand get it right the first time! Isochronous data is generally useless if it is late Either the source or sink has no time to wait Efficient bandwidth utilization may preclude retries Slide 18 IEEE 802.11-00/181 Submission March 2001 Peter Johansson / Congruent Software, Inc. 18 Why does isochronous delivery matter? Worst-case delivery delay for any packet is bounded and easily calculable Bounded latency is small enough to make interesting real-time applications economical Digital audio: 420 s at 1.5 Mbps (81 bytes) SD video: 383 s at 28 Mbps (1,340 bytes) Larger buffers necessary in wireless domain Additional delay should be less than 20 ms Slide 19 IEEE 802.11-00/181 Submission March 2001 Peter Johansson / Congruent Software, Inc. 19 Isochronous cycles Cycle start packet adjusts for delay Subaction gap ends cycle cycle n - 1 cycle n + 1 cycle n cycle start ch async Q async P async R isochronous asynchronous ch async Q cycle synch nominal 125 s cycle offset (delay) Slide 20 IEEE 802.11-00/181 Submission March 2001 Peter Johansson / Congruent Software, Inc. 20 Isochronous streams Owner allocates bandwidth and channel number Cooperative allocation insures low latency Cycle master broadcasts cycle start packet every 125 s, on average Single talker per channel broadcasts zero or one isochronous data packets per cycle Multiple listeners receive isochronous data packets by channel number Slide 21 IEEE 802.11-00/181 Submission March 2001 Peter Johansson / Congruent Software, Inc. 21 Additional desiderata Resource allocation should be designed into the MAC protocols Avoid use of RSVP as the only method to control traffic specifications Dissociate coordination functions from access point functions Design contention algorithms to select a single coordination point from multiple stations capable of performing this function Slide 22 IEEE 802.11-00/181 Submission March 2001 Peter Johansson / Congruent Software, Inc. 22 Contact information Peter Johansson Congruent Software, Inc. 98 Colorado Avenue Berkeley, CA 94707 (510) 527-3926 (510) 527-3856 FAX PJohansson@ACM.org