1 / 8

Extend FEC BB to RTP streaming?

Extend FEC BB to RTP streaming?. Michael Luby Digital Fountain. Motivation. A lot of careful thought and experience has gone into the FEC BB It is a modular, reusable building block that has successfully been the basis of File delivery apps (FLUTE, commercial)

soo
Download Presentation

Extend FEC BB to RTP streaming?

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. Extend FEC BB to RTP streaming? Michael Luby Digital Fountain

  2. Motivation • A lot of careful thought and experience has gone into the FEC BB • It is a modular, reusable building block that has successfully been the basis of • File delivery apps (FLUTE, commercial) • Streaming apps (proprietary, commercial) • Based on this experience, there is a proposal to improve the FEC BB in its move from Experimental to Proposed Standard status • This is a good time to officially allow FEC BB to apply to streaming

  3. Motivation • 3GPP SA4 MBMS service has adopted an FEC protection architecture for RTP streaming data that fits into the FEC BB • Generic approach to using FEC for streaming has been identified and verified to be applicable to the 5/6 FEC schemes under consideration for MBMS • S4-AHP159, S4-AHP138, S4-AHP166, S4-AHP181 • Most likely will end up being part of MBMS in Release 6 • 3GPP intention is to bring this work back to IETF (at least in form of Informational RFC)

  4. FEC streaming source block formation example Symbol size = 7 bytes First RTP packet = 8 bytes Second RTP packet = 24 bytes Source block = length of RTP packet, RTP packet (padded out to full symbol) Source symbol 0 0 8 B0,0 B0,1 B0,2 B0,3 B0,4 Source symbol 1 B0,5 B0,6 B0.7 0 0 0 0 0 24 B1,0 B1,1 B1,2 B1,3 B1,4 Source symbol 2 B1,5 B1,6 B1,7 B1,8 B1,9 B1,10 B1,11 Source symbol 3 B1,12 B1,13 B1,14 B1,15 B1,16 B1,17 B1,18 Source symbol 4 B1,19 B1,20 B1,21 B1,22 B1,23 0 0 Source symbol 5 Source block

  5. Source Packet FEC Payload ID SBN ESI • SBN (Source Block Number) • Numbered consecutively • Identifies the source block that the source RTP packets is part of • ESI (Encoding Symbol ID) • Index of first source symbol in source block where this RTP packet starts • Interpretation is FEC scheme independent (except for possibly the length of the field)

  6. Repair packet FEC Payload ID • FEC Scheme dependent • SBN • Identifies the source block from which the repair symbols are generated • Used by all FEC Schemes • ESI • Identifies how the repair symbols are generated • This is FEC scheme dependent • Used by all FEC Schemes • SBL • Number of source symbols in the source block • For some FEC Schemes, this may be part of OTI • EBL • Maximum number of encoding symbols generated for the source block • Used by some FEC Schemes • For some FEC Schemes, this may be part of the OTI • T • Symbol length • For many FEC schemes, this may be part of the OTI

  7. Objective • Proper split of work between AVT and RMT • Streaming issues to be addressed in AVT • How signaling of OTI is done • How source blocks are formed • How source packets and repair packets are multiplexed and demultiplexed • FEC issues to be addressed in RMT • FEC Schemes defined • FEC Payload ID(s) to be used • FEC OTI parameters defined

  8. Possibilities for FEC BB • Explicitly allow applicability to streaming • Currently limited to object delivery by RMT charter • Some FEC Encoding IDs may not be applicable to streaming (leave as is) • Some FEC Encoding IDs may be applicable to streaming without modification (allow mention of this) • Some FEC Encoding IDS may be applicable to both with minor modifications (e.g., use a subset of OTI parameters for streaming) • Use different FEC Encoding IDs for objects and streaming? • Use one FEC Encoding ID and explicit indication in OTI of whether streaming or object delivery? • Use one FEC Encoding ID and implicit indication based on what is included in OTI? • Define FEC Encoding ID for only repair packets and let AVT define generic format for source FEC packets?

More Related