Doc.: IEEE /274 Submission May 2001 John M. Kowalski et al, Sharp. AV Multicast for e: Benefits/Challenges Sharp Corporation John Kowalski
Doc.: IEEE /274 Submission May 2001 John M. Kowalski et al, Sharp. CONTENTS Multicast Applications Limitations of Current & Draft Standard Requirements for AV Multicast Options to meet this challenge Discussion Points of AV Multicast Summary
Doc.: IEEE /274 Submission May 2001 John M. Kowalski et al, Sharp. Multicast Application –1 For the Home Application, there are many AV devices. “1 to n” communication will be necessary especially for the AV application. - e.g. Tuner and TV TV on 2 nd floor TV in Living room Mobile Viewer BS/CS Tuner CATV STB
Doc.: IEEE /274 Submission May 2001 John M. Kowalski et al, Sharp. Multicast Application –2 For the Home Application, Several AV devices will be used for realizing the one AV application. – e.g. Home theater System Monitor Stereo DVD Player Rear surround speaker
Doc.: IEEE /274 Submission May 2001 John M. Kowalski et al, Sharp. Multicast Application –3 For Office, Multicast also might be useful. – e.g. Video conference System Center Projector VIDEO Sharing White Board Sharing
Doc.: IEEE /274 Submission May 2001 John M. Kowalski et al, Sharp. Limitations of Current & Draft Standard Multicast groups need to be defined - that take advantage of 11e- in order to do true multicasting (as opposed to multiple synch’d streams) AND –Multicast is an unacknowledged service (in 802.2) –BUT we need some ACK mechanism at least in the near term.
Doc.: IEEE /274 Submission May 2001 John M. Kowalski et al, Sharp. Discussion Points of AV Multicast Groupcast address definition for AV Multicast –Which kind of address should be used? –How to make a standard? Grouping sequence –How to decide the address? HC? Image source? –How does the ESTA join the group? –How to inform the group address?
Doc.: IEEE /274 Submission May 2001 John M. Kowalski et al, Sharp. Requirements for AV Multicast For realizing the AV application, the followings are required for the Multicast transfer. –Forward error correction (RS-code) –Delayed Acknowledgement –Retransmission mechanism
Doc.: IEEE /274 Submission May 2001 John M. Kowalski et al, Sharp. So what are our options? (1) Do nothing –Positive: We don’t have to do anything. –Negative: We miss out on a huge application market OR use multiple synch’d streams, which are horrendously inneficient.
Doc.: IEEE /274 Submission May 2001 John M. Kowalski et al, Sharp. So what are our options? (2) Work with 802.? to develop recommended practice for QoS enabled multicast groups with acknowledged service –Positive: Would provide a single solution for all 802.X wireless systems. Long term solution –Negative: Takes time. Problems with legacy equipment?
Doc.: IEEE /274 Submission May 2001 John M. Kowalski et al, Sharp. So what are our options? (3) Provide a solution that works for –Positive: Would harmonize well with work going on to integrate with AV/1394 systems. Could be done relatively quickly. –Negative: Would have to provide an interface, and services that would not be conformant to current standard.
Doc.: IEEE /274 Submission May 2001 John M. Kowalski et al, Sharp. So what are our options? (4) Use Transport Layer via IETF practices for Multicasting... –Positive: Would harmonize well with work going on to integrate with AV/1394 systems. Could be done relatively quickly. –Negative: Can latency/jitter/buffer size requirements be met?
Doc.: IEEE /274 Submission May 2001 John M. Kowalski et al, Sharp. Summary We believe the AV multicast expands the wireless application market greatly for We want to start the discussion about the AV multicast. Any help/additional options would be greatly appreciated.