Download ppt - 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

March 2001

Peter Johansson / Congruent Software, Inc.

– 1 –

IEEE 802.11-00/181

Submission

IEEE P802.11eA quality transport for IEEE 1394?

Peter JohanssonCongruent Software, Inc.

Chair, IEEE P1394.1

March 2001


– 2 –

IEEE 802.11-00/181

Submission

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

March 2001


– 3 –

IEEE 802.11-00/181

Submission

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

Kitchen BedroomWireless

Living Room Bedroom

OfficeWireless

March 2001


– 4 –

IEEE 802.11-00/181

Submission

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

WirelessLiving Room

Bedroom

Office

Wiring ClosetKitchen Bedroom

March 2001


– 5 –

IEEE 802.11-00/181

Submission

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

March 2001


– 6 –

IEEE 802.11-00/181

Submission

Scope of work

1 Investigate the suitability of IEEE 802.112Design a protocol adaptation layer (PAL)

specific to IEEE 802.113 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

March 2001


– 7 –

IEEE 802.11-00/181

Submission

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

March 2001


– 8 –

IEEE 802.11-00/181

Submission

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

March 2001


– 9 –

IEEE 802.11-00/181

Submission

Wireless products enabled

• Firmware developed for (wired) IEEE 1394 products can migrate to wireless domain

• Minimize reengineering between wiredand wireless domains

IEEE 802.11

DVCR

1394 PAL

IEEE 802.11

DTV

1394 PAL

March 2001


– 10 –

IEEE 802.11-00/181

Submission

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

March 2001


– 11 –

IEEE 802.11-00/181

Submission

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 1394IEEE 802.11

?

March 2001


– 12 –

IEEE 802.11-00/181

Submission

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 1394IEEE 802.11

March 2001


– 13 –

IEEE 802.11-00/181

Submission

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.11IEEE 1394IEEE 1394

March 2001


– 14 –

IEEE 802.11-00/181

Submission

portal 0 portal 1internal 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

March 2001


– 15 –

IEEE 802.11-00/181

Submission

1394 Trade Association project scopeDevelop 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.

March 2001


– 16 –

IEEE 802.11-00/181

Submission

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

March 2001


– 17 –

IEEE 802.11-00/181

Submission

What does “isochronous” really mean?

• iso•chro•nous \ adj [Gk isokronos] (1706) : uniform in time; having equal duration; recurring at regular intervals

• 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

March 2001


– 18 –

IEEE 802.11-00/181

Submission

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

March 2001


– 19 –

IEEE 802.11-00/181

Submission

Isochronous cycles

• Cycle start packet adjusts for delay• Subaction gap ends cycle

cycle n - 1 cycle n + 1cycle n

cycle start

cycle start

ch

ch

ch

ch…

asyncQ

asyncP

asyncR

isochronous asynchronous

ch

asyncQ

cycle synch cycle synch

nominal 125 µs

cycle offset (delay) cycle offset (delay)

March 2001


– 20 –

IEEE 802.11-00/181

Submission

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

March 2001


– 21 –

IEEE 802.11-00/181

Submission

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

March 2001


– 22 –

IEEE 802.11-00/181

Submission

Contact information

Peter JohanssonCongruent Software, Inc.98 Colorado AvenueBerkeley, CA 94707(510) 527-3926(510) 527-3856 [email protected]