1 / 20

Ioannis Broustis 1 , Michael Paterakis 1,2 (1) Information & Computer Networks Laboratory

On the Feasibility of Integrated MPEG Teleconference and Data Transmission over IEEE 802.11 WLANs. Networking 2004 Conference. Ioannis Broustis 1 , Michael Paterakis 1,2 (1) Information & Computer Networks Laboratory Department of Electronic & Computer Engineering &

Download Presentation

Ioannis Broustis 1 , Michael Paterakis 1,2 (1) Information & Computer Networks Laboratory

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. On the Feasibility of Integrated MPEG Teleconference and Data Transmission over IEEE 802.11 WLANs Networking 2004 Conference Ioannis Broustis1, Michael Paterakis1,2 (1) Information & Computer Networks Laboratory Department of Electronic & Computer Engineering & (2) Telecommunication Systems Institute Technical University of Crete (broustis, pateraki)@telecom.tuc.gr

  2. Motivation • Teleconference applications are used increasingly more by companies, universities, etc. • Such applications • Require large amounts of bandwidth • Are delay – sensitive • Have been tested in high-speed wired networks • We want to assess the capability of WLAN IEEE 802.11 protocols to transmit real-time video traffic.

  3. Why test 802.11? • The most widespread Wireless LANs are based today on the IEEE 802.11 standard. • Bluetooth technology does not provide the required bandwidth and its range is short. • Ultra Wide Band (UWB) technology has not been standardized yet, while the provided range will be quite short.

  4. Roadmap of the Talk • The IEEE 802.11b MAC Protocol • System Requirements • Teleconference Scenarios & Performance Evaluation • Full Teleconference • Teleconference for Pairs of Users • Teleconference for Groups of Users • Conclusions

  5. IEEE 802.11 MAC • In every 802.11 WLAN, a single channel is available for use by all stations. • The MAC has been designed to support multiple users in the shared medium. • The MAC can be implemented in two different modes: • Contention: The nodes must contend in order to gain access to the common channel • Contention-Free: The channel usage is determined by a polling coordinator (usually located at the Access Point)

  6. Contention (DCF) DCF (Distributed Coordination Function) • Stations follow the CSMA-CA algorithm • If a node senses that the medium is idle for a certain amount of time, then it will initiate a transmission. • Upon successful transmission, a positive ACK is sent back to the sender. • If a collision occurs, the respective stations initiate backoff timers that count backwards. • The first station, whose timer reaches zero, will try to transmit again.

  7. Contention-Free (PCF) PCF (Point Coordination Function) • An Access Point (AP) decides which station will transmit, according to an algorithm (usually of Round Robin nature). • A polling list is maintained • The node on top of the list transmits next. After the end of its transmission, this node is placed at the bottom of the list. • The scheme guarantees that each station will be able to transmit after a certain time interval.

  8. Contention-Free Contention Contention Contention-Free Β PCF DCF Β PCF DCF Alternation between modes • The DCF and PCF periods may alternate in time. • A beacon informs stations about the DCFPCF alternation. … • We choose to transmit video frames during the PCF period, since the scheduled access within can provide QoS. All packets go through the AP. • During the DCF, nodes exchange 53-byte data packets directly.

  9. System Requirements • All stations run a common teleconference application, which uses the MPEG-4 video compression algorithm. • Video frames, larger than a threshold value (1034 bytes), are fragmented into packets. • Low quality video • Minimum bit rate: 42Kbits/sec • Peak bit rate: 690Kbits/sec • Packet Video Drop (PVD) = • We require: PVD ≤ 10-4

  10. Teleconference operation • Two basic problems with Teleconference • Delay – Sensitive application • At each node, a new video frame is generated every 0.04 sec. • Every video frame must be received within 0.04 sec from the time it was generated. • The video packet that a station transmits must be received by all the other participants! • Obvious solution: Broadcasting / Multicasting • No Acknowledgements are sent back • Alternative:The Access Point unicasts video packet copies

  11. ΑΡ Scenario 1: Full Teleconference • 1st way: The sender makes the copies and sends them to the AP • Problem on the uplink: Only 1 packet upstream each time! For N users, it takes N-1 Round Robin cycles until a packet is transmitted to everyone. The copy procedure is performed by the sender

  12. Scenario 1: Full Teleconference • 2nd way: The Access point performs the copy procedure. The copy procedure is performed behind the Access Point ΑΡ COPY FUNCTION

  13. Scenario 1: Performance Evaluation • For 7 or more users, the system does not operate efficiently (the PVD increases abruptly). Average Video Packet Delay (usec) Packet Video Drop Number of stations Number of stations Average video packet delays are acceptable

  14. Scenario 1: Performance Evaluation • Average data packet delays are acceptable, they increase abruptly when we have 7 stations in the network Video Average Data Packet Delay (usec) Time left for actual transmissions (usec) Data Number of stations Number of stations The amount of time left for video and data packet transmissions is quite small.

  15. Scenario 2: Pairs of users • Every pair of users holds its own teleconference 2 2 1 1 Each video packet sent by a node is destined to one node only, its teleconference partner. We do not have to replicate packets. 3 3 1 1 2 2 3 3 ΑΡ 6 5 4 6 5 4 4 4 5 5 6 6

  16. Scenario 2: Performance Evaluation • The system can now support up to 16 users (8 pairs), that is 10 more users than in the previous scenario. • Asweaddmoreusers, weobserveasevereincrease in the average data packet delays • In a system with many users, it is more difficult for a station to gain access to the medium through the CSMA-CA algorithm.

  17. Scenario 3: Groups of users • For groups with more than two users, we must use a copy function, which copies video packets behind the AP. • These packets suffer higher delays (scenario #1) • Groups of different sizes do not interfere with each other! • Large groups suffer from delays and losses, while smaller ones hold teleconference more efficiently. VIDEO

  18. Scenario 3: Performance Evaluation

  19. Conclusions • It is difficult for an 802.11b Wireless LAN to support teleconference applications for a large number of users. • Such applications are delay – sensitive. • The QoS requirements regarding video packet dropping are strict. • The time overheads of the protocol are quite large. • The transmission rate (max 11Mbits/sec) is not enough.

  20. Conclusions • Possible solutions? • Import broadcasting / multicasting functionalities and don’t care about acknowledgements • What about about reliability? • Extension: Use multiple channels simultaneously • Parallel packet transmissions could take place! • Use of newer 802.11 versions • 802.11g may provide up to 22Mbits/sec  Are they enough? No! The network capacity increases only by 4 to 5 additional users.

More Related