rfc2728.txt

<VC++网络游戏建摸与实现>源代码

   if (Byte & 1)
      Byte = Byte + 255;
   Byte = Byte >> 1;
   Bit = alog[power[255 + alog[sum0] - Byte]] << 3;
   while (Bit > 255)
      Bit = Bit - 255;

   The error is correctable if Byte is less than the number of bytes in
   the codeword and Bit is less than eight.  For this math to be valid
   both sum0 and sum1 must be non-zero.  The codeword is corrected by:

   codeword[Byte] = codeword[Byte] ^ (1 << Bit);


12.4.2. Double Bit Correction

   Double bit correction is much more complex than single bit correction
   for two reasons.  First, not all double bit errors are deterministic.
   That is two different bit patterns can generate the same sums.
   Second, the solution is iterative.  To find two bit errors you assume
   one bit in error and then solve for the second error as a single bit
   error.

   The procedure is to iteratively move through the bits of the codeword
   changing each bit's state.  The new sums are calculated for the
   modified codeword. Then the single bit calculation above determines
   if this is the correct solution.  If not, the bit is restored and the
   next bit is tried.

   For a long codeword, this can involve many calculations.  However,
   tricks can speed the process.  For example, the vertical sums give a
   strong indication of which bytes are in error horizontally.  Bits in
   other bytes need not be tried.







Panabaker, et al.           Standards Track                    [Page 18]

RFC 2728                         IPVBI                     November 1999


12.4.3. Single Byte Correction

   For single byte correction, the byte position and bits to correct
   must be calculated.  The equations are:

   Byte = 1/2*LOGalpha(S1/S0)
   Mask = S0/POWERalpha[Byte]

   Notice that the byte position is the same calculation as for single
   bit correction.  The mask will allow more than one bit in the byte to
   be corrected.  In "C" the mask calculation looks like:

   Mask = power[255 + alog[sum0] - Byte]

   Both sum0 and sum1 must be non-zero for the calculations to be valid.
   The Byte value must be less than the codeword length but Mask can be
   any value.  This corrects the byte in the codeword by:

   Codeword[Byte] = Codeword[Byte] ^ Mask

12.4.4. Packet Replacement

   If a packet is missing, as determined by the continuity index, then
   its byte position is known and does not need to be calculated.  The
   formula for single packet replacement is therefore the same as for
   the Mask calculation of single byte correction.  Instead of XORing an
   existing byte with the Mask, the Mask replaces the missing codeword
   position:

   Codeword[Byte] = Mask

   When two packets are missing, both the codeword positions are known
   by the continuity index.  This again gives two equations with two
   unknowns, which is solved to give the following equations.  Mask2 =
   POWERalpha(2*Byte1)*S0+S1

   POWERalpha(2*Byte1+Byte2) +POWERalpha(3*BYTE2)
   Mask1 = S0 + Mask2*POWERalpha(Byte2)/POWERalpha(BYTE1)













Panabaker, et al.           Standards Track                    [Page 19]

RFC 2728                         IPVBI                     November 1999


In "C" these equations are written:

if (sum0 == 0)
{
   if (sum1 == 0)
      mask2 = 0;
   else
      mask2=power[255+alog[sum1]-alog[power[byte2+2*byte1]
                  ^power[3*Byte2]]];
}
else
{
   if ((a=sum1^power[alog[sum0]+2*byte1]) == 0)
      mask2 = 0;
   else
      mask2 =
power[255+alog[a]-alog[power[byte2+2*byte1]^power[3*byte2]]];
}

if (mask2 = 0)
{
   if (sum0 == 0)
      mask1 = 0;
   else
      mask1 = power[255+alog[sum0]-byte1];
}
else
{
   if ((a=sum0^power[alog[mask2] + byte2]) == 0)
      mask1 = 0;
   else
      mask1 = power[255+alog[a]-byte1];
}

   Notice that, in the code above, care is taken to check for zero
   values.  The missing codeword position can be fixed by:

         codeword[byte1] = mask1;
         codeword[byte2] = mask2;

12.5. FEC Performance Considerations

   The section above shows how to correct the different types of errors.
   It does not suggest how these corrections may be used in an algorithm
   to correct a bundle.  There are many possible algorithms and the one
   chosen depends on many variables.  These include:





Panabaker, et al.           Standards Track                    [Page 20]

RFC 2728                         IPVBI                     November 1999


      . The amount of processing power available
      . The number of packets per VBI to process
      . The type of hardware capturing the data
      . The delivery path of the VBI
      . How the code is implemented

   As a minimum, it is recommended that the algorithm use single bit or
   single byte correction for one pass in each direction followed by
   packet replacement if appropriate.  It is possible to do more than
   one pass of error correction in each direction.  The theory is that
   errors not corrected in the first pass may be corrected in the second
   pass because error correction in the other direction has removed some
   errors.

   In making choices, it is important to remember that the code has
   several possible states:

   1)    Shows codeword as correct and it is.

   2)    Shows codeword as correct and it is not (detection failure).

   3)    Shows codeword as incorrect but cannot correct (detection).

   4)    Shows codeword as incorrect and corrects it correctly
         (correction).

   5)    Shows codeword as incorrect but corrects wrong bits (false
         correction).

   There is actually overlap among the different types of errors.  For
   example, a pair of sums may indicate both a double bit error and a
   byte error.  It is not possible to know at the code level which is
   correct and which is a false correction.  In fact, neither might be
   correct if both are false corrections.

   If you know something about the types of errors in the delivery
   channel, you can greatly improve efficiency.  If you know that errors
   are randomly distributed (as in a weak terrestrial broadcast) then
   single and double bit correction are more powerful than single byte.












Panabaker, et al.           Standards Track                    [Page 21]

RFC 2728                         IPVBI                     November 1999


13. Appendix B: Architecture

   The architecture that this document is addressing can be broken down
   into three areas: insertion, distribution network, and receiving
   client.

   The insertion of IP data onto the television signal can occur at any
   part of the delivery system.  A VBI encoder typically accepts a video
   signal and an asynchronous serial stream of bytes forming framed IP
   packets as inputs and subsequently packetizes the data onto a
   selected set of lines using NABTS and an FEC.  This composite signal
   is then modulated with other channels before being broadcast onto the
   distribution network. Operators further down the distribution chain
   could then add their own data, to other unused lines, as well.  The
   distribution networks include coax plant, off-air, and analog
   satellite systems and are primarily unidirectional broadcast
   networks.  They must provide a signal to noise ratio, which is
   sufficient for FEC to recover any lost data for the broadcast of data
   to be effective.

   The receiving client must be capable of tuning, NABTS waveform
   sampling as appropriate, filtering on NABTS addresses as appropriate,
   forward error correction, unframing, verification of the CRC and
   decompressing the UDP/IP header if they are compressed. All of the
   above functions can be carried out in PC software and inexpensive
   off-the-shelf hardware.

14. Appendix C: Scope of proposed protocols

   The protocols described in this document are for transmitting IP
   packets.  However, their scope may be extensible to other
   applications outside this area.  Many of the protocols in this
   document could be implemented on any unidirectional network.

   The unidirectional framing protocol provides encapsulation of IP
   datagrams on the serial stream, and the compression of the UDP/IP
   headers reduces the overhead on transmission, thus conserving
   bandwidth.  These two protocols could be widely used on different
   unidirectional broadcast networks or modulation schemes to
   efficiently transport any type of packet data.  In particular, new
   versions of Internet protocols can be supported to provide a
   standardized method of data transport.









Panabaker, et al.           Standards Track                    [Page 22]

RFC 2728                         IPVBI                     November 1999


15.  Full Copyright Statement

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Panabaker, et al.           Standards Track                    [Page 23]