1 / 22

IEEE 802.11e for IEEE 1394: Wireless Home Network Solution

Explore the integration of IEEE 1394 into wireless home networks, enabling seamless connectivity for consumer electronics. Develop adaptation layers to bridge wired and wireless domains effectively.

rodriquezb
Download Presentation

IEEE 802.11e for IEEE 1394: Wireless Home Network Solution

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IEEE P802.11eA quality transport for IEEE 1394? Peter JohanssonCongruent Software, Inc. Chair, IEEE P1394.1 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 Peter Johansson / Congruent Software, Inc.

  3. Kitchen Bedroom Wireless Wireless Living Room Bedroom Office 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 Peter Johansson / Congruent Software, Inc.

  4. Wiring Closet Kitchen Bedroom Wireless Living Room Office Bedroom 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 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 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 Peter Johansson / Congruent Software, Inc.

  7. Application 1394 PAL IEEE 802.11 What is a PAL? • A “glue layer” on top of a lower level • 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 Peter Johansson / Congruent Software, Inc.

  8. Application 1394 PAL IEEE 802.11 What use is a PAL? • Leverages applications already developed Application IEEE 1394 • Applications developed for IEEE 1394 expect: • Read, write and lock transactions • Infrastructure CSRs and configuration ROM • Isochronous services Peter Johansson / Congruent Software, Inc.

  9. DVCR DTV 1394 PAL 1394 PAL IEEE 802.11 IEEE 802.11 Wireless products enabled • Firmware developed for (wired) IEEE 1394 products can migrate to wireless domain • Minimize reengineering between wiredand wireless domains 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 Peter Johansson / Congruent Software, Inc.

  11. IEEE 1394 IEEE 802.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 Peter Johansson / Congruent Software, Inc.

  12. IEEE 1394 IEEE 802.11 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 Peter Johansson / Congruent Software, Inc.

  13. IEEE 1394 IEEE 1394 IEEE 802.11 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 Peter Johansson / Congruent Software, Inc.

  14. cycle clock portal 0 portal 1 internal fabric 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 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. Peter Johansson / Congruent Software, Inc.

  16. What’s 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 Peter Johansson / Congruent Software, Inc.

  17. What does “isochronous” really mean? • iso•chro•nous \ adj [Gk isokronos] (1706) —————————————————————————————Send it soon—and 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 • iso•chro•nous \ adj [Gk isokronos] (1706) : uniform in time; having equal duration; recurring at regular intervals 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 Peter Johansson / Congruent Software, Inc.

  19. cycle n + 1 cycle n asyncQ cycle start ch ch ch … ch asyncP asyncQ asyncR cycle start ch cycle n - 1 isochronous asynchronous cycle offset (delay) cycle offset (delay) nominal 125 µs cycle synch cycle synch Isochronous cycles • Cycle start packet adjusts for delay • Subaction gap ends cycle 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 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 Peter Johansson / Congruent Software, Inc.

  22. Contact information Peter Johansson Congruent Software, Inc.98 Colorado AvenueBerkeley, CA 94707 (510) 527-3926(510) 527-3856 FAX PJohansson@ACM.org Peter Johansson / Congruent Software, Inc.

More Related