关键词: CRC, FCS, 生成多项式, 检错重传
引言
CRC的全称为Cyclic Redundancy Check，中文名称为循环冗余校验。它是一类重要的线性分组码，编码和解码方法简单，检错和纠错能力强，在通信领域广泛地用于实现差错控制。实际上，除数据通信外，CRC在其它很多领域也是大有用武之地的。例如我们读软盘上的文件，以及解压一个ZIP文件时，偶尔会碰到“Bad CRC”错误，由此它在数据存储方面的应用可略见一斑。
差错控制理论是在代数理论基础上建立起来的。这里我们着眼于介绍CRC的算法与实现，对原理只能捎带说明一下。若需要进一步了解线性码、分组码、循环码、纠错编码等方面的原理，可以阅读有关资料。
利用CRC进行检错的过程可简单描述为：在发送端根据要传送的k位二进制码序列，以一定的规则产生一个校验用的r位监督码(CRC码)，附在原始信息后边，构成一个新的二进制码序列数共k+r位，然后发送出去。在接收端，根据信息码和CRC码之间所遵循的规则进行检验，以确定传送中是否出错。这个规则，在差错控制理论中称为“生成多项式”。
1 代数学的一般性算法
在代数编码理论中，将一个码组表示为一个多项式，码组中各码元当作多项式的系数。例如 1100101 表示为
1·x6+1·x5+0·x4+0·x3+1·x2+0·x+1，即 x6+x5+x2+1。
设编码前的原始信息多项式为P(x)，P(x)的最高幂次加1等于k；生成多项式为G(x)，G(x)的最高幂次等于r；CRC多项式为R(x)；编码后的带CRC的信息多项式为T(x)。
发送方编码方法：将P(x)乘以xr(即对应的二进制码序列左移r位)，再除以G(x)，所得余式即为R(x)。用公式表示为
T(x)=xrP(x)+R(x)
接收方解码方法：将T(x)除以G(x)，如果余数为0，则说明传输中无错误发生，否则说明传输有误。
举例来说，设信息码为1100，生成多项式为1011，即P(x)=x3+x2，G(x)=x3+x+1，计算CRC的过程为
xrP(x) x3(x3+x2) x6+x5 x
-------- = ---------- = -------- = (x3+x2+x) + --------
G(x) x3+x+1 x3+x+1 x3+x+1
即 R(x)=x。注意到G(x)最高幂次r=3，得出CRC为010。
如果用竖式除法，计算过程为
1110
-------
1011 /1100000 (1100左移3位)
1011
----
1110
1011
-----
1010
1011
-----
0010
0000
----
010
因此，T(x)=(x6+x5)+(x)=x6+x5+x, 即 1100000+010=1100010
如果传输无误，
T(x) x6+x5+x
------ = --------- = x3+x2+x,
G(x) x3+x+1
无余式。回头看一下上面的竖式除法，如果被除数是1100010，显然在商第三个1时，就能除尽。
上述推算过程，有助于我们理解CRC的概念。但直接编程来实现上面的算法，不仅繁琐，效率也不高。实际上在工程中不会直接这样去计算和验证CRC。
下表中列出了一些见于标准的CRC资料：
名称
生成多项式
简记式*
应用举例
CRC-4
x4+x+1
ITU G.704
CRC-12
x12+x11+x3+x+1
CRC-16
x16+x12+x2+1
1005
IBM SDLC
CRC-ITU**
x16+x12+x5+1
1021
ISO HDLC, ITU X.25, V.34/V.41/V.42, PPP-FCS
CRC-32
x32+x26+x23+...+x2+x+1
04C11DB7
ZIP, RAR, IEEE 802 LAN/FDDI, IEEE 1394, PPP-FCS
CRC-32c
x32+x28+x27+...+x8+x6+1
1EDC6F41
SCTP
* 生成多项式的最高幂次项系数是固定的1，故在简记式中，将最高的1统一去掉了，如04C11DB7实际上是104C11DB7。
** 前称CRC-CCITT。ITU的前身是CCITT。
2 硬件电路的实现方法
多项式除法，可用除法电路来实现。除法电路的主体由一组移位寄存器和模2加法器(异或单元)组成。以CRC-ITU为例，它由16级移位寄存器和3个加法器组成，见下图(编码/解码共用)。编码、解码前将各寄存器初始化为"1"，信息位随着时钟移入。当信息位全部输入后，从寄存器组输出CRC结果。
3 比特型算法
上面的CRC-ITU除法电路，完全可以用软件来模拟。定义一个寄存器组，初始化为全"1"。依照电路图，每输入一个信息位，相当于一个时钟脉冲到来，从高到低依次移位。移位前信息位与bit0相加产生临时位，其中bit15移入临时位，bit10、bit3还要加上临时位。当全部信息位输入完成后，从寄存器组取出它们的值，这就是CRC码。
typedef unsigned char bit;
typedef unsigned char byte;
typedef unsigned short u16;
typedef union {
u16 val;
struct {
u16 bit0 : 1;
u16 bit1 : 1;
u16 bit2 : 1;
u16 bit3 : 1;
u16 bit4 : 1;
u16 bit5 : 1;
u16 bit6 : 1;
u16 bit7 : 1;
u16 bit8 : 1;
u16 bit9 : 1;
u16 bit10 : 1;
u16 bit11 : 1;
u16 bit12 : 1;
u16 bit13 : 1;
u16 bit14 : 1;
u16 bit15 : 1;
} bits;
} CRCREGS;
// 寄存器组
CRCREGS regs;
// 初始化CRC寄存器组：移位寄存器置为全"1"
void crcInitRegisters()
{
regs.val = 0xffff;
}
// CRC输入一个bit
void crcInputBit(bit in)
{
bit a;
a = regs.bits.bit0 ^ in;
regs.bits.bit0 = regs.bits.bit1;
regs.bits.bit1 = regs.bits.bit2;
regs.bits.bit2 = regs.bits.bit3;
regs.bits.bit3 = regs.bits.bit4 ^ a;
regs.bits.bit4 = regs.bits.bit5;
regs.bits.bit5 = regs.bits.bit6;
regs.bits.bit6 = regs.bits.bit7;
regs.bits.bit7 = regs.bits.bit8;
regs.bits.bit8 = regs.bits.bit9;
regs.bits.bit9 = regs.bits.bit10;
regs.bits.bit10 = regs.bits.bit11 ^ a;
regs.bits.bit11 = regs.bits.bit12;
regs.bits.bit12 = regs.bits.bit13;
regs.bits.bit13 = regs.bits.bit14;
regs.bits.bit14 = regs.bits.bit15;
regs.bits.bit15 = a;
}
// 输出CRC码(寄存器组的值)
u16 crcGetRegisters()
{
return regs.val;
}
crcInputBit中一步一步的移位/异或操作，可以进行简化：
void crcInputBit(bit in)
{
bit a;
a = regs.bits.bit0 ^ in;
regs.val >>= 1;
if(a) regs.val ^= 0x8408;
}
细心的话，可以发现0x8408和0x1021(CRC-ITU的简记式)之间的关系。由于我们是从低到高输出比特流的，将0x1021左右反转就得到0x8408。将生成多项式写成 G(x)=1+x5+x12+x16，是不是更好看一点？
下面是一个典型的PPP帧。最后两个字节称为FCS(Frame Check Sequence)，是前面11个字节的CRC。
FF 03 C0 21 04 03 00 07 0D 03 06 D0 3A
我们来计算这个PPP帧的CRC，并验证它。
byte ppp[13] = {0xFF, 0x03, 0xC0, 0x21, 0x04, 0x03, 0x00, 0x07, 0x0D, 0x03, 0x06, 0x00, 0x00};
int i,j;
u16 result;
/// 以下计算FCS
// 初始化
crcInitRegisters();
// 逐位输入，每个字节低位在先，不包括两个FCS字节
for(i = 0; i < 11; i++)
{
for(j = 0; j < 8; j++)
{
crcInputBit((ppp[i] >> j) & 1);
}
}
// 得到CRC：将寄存器组的值求反
result = ~crcGetRegisters();
// 填写FCS，先低后高
ppp[11] = result & 0xff;
ppp[12] = (result >> 8) & 0xff;
/// 以下验证FCS
// 初始化
crcInitRegisters();
// 逐位输入，每个字节低位在先，包括两个FCS字节
for(i = 0; i < 13; i++)
{
for(j = 0; j < 8; j++)
{
crcInputBit((ppp[i] >> j) & 1);
}
}
// 得到验证结果
result = crcGetRegisters();
可以看到，计算出的CRC等于0x3AD0，与原来的FCS相同。验证结果等于0。初始化为全"1"，以及将寄存器组的值求反得到CRC，都是CRC-ITU的要求。事实上，不管初始化为全"1"还是全"0"，计算CRC取反还是不取反，得到的验证结果都是0。
4 字节型算法
比特型算法逐位进行运算，效率比较低，不适用于高速通信的场合。数字通信系统(各种通信标准)一般是对一帧数据进行CRC校验，而字节是帧的基本单位。最常用的是一种按字节查表的快速算法。该算法基于这样一个事实：计算本字节后的CRC码，等于上一字节余式CRC码的低8位左移8位，加上上一字节CRC右移8位和本字节之和后所求得的CRC码。如果我们把8位二进制序列数的CRC(共256个)全部计算出来，放在一个表里 ，编码时只要从表中查找对应的值进行处理即可。
CRC-ITU的计算算法如下：
a.寄存器组初始化为全"1"(0xFFFF)。
b.寄存器组向右移动一个字节。
c.刚移出的那个字节与数据字节进行异或运算，得出一个指向值表的索引。
d.索引所指的表值与寄存器组做异或运算。
f.数据指针加1，如果数据没有全部处理完，则重复步骤b。
g.寄存器组取反，得到CRC，附加在数据之后。
CRC-ITU的验证算法如下：
a.寄存器组初始化为全"1"(0xFFFF)。
b.寄存器组向右移动一个字节。
c.刚移出的那个字节与数据字节进行异或运算，得出一个指向值表的索引。
d.索引所指的表值与寄存器组做异或运算。
e.数据指针加1，如果数据没有全部处理完，则重复步骤b (数据包括CRC的两个字节)。
f.寄存器组的值是否等于“Magic Value”(0xF0B8)，若相等则通过，否则失败。
下面是通用的CRC-ITU查找表以及计算和验证CRC的C语言程序：
// CRC-ITU查找表
const u16 crctab16[] =
{
0x0000, 0x1189, 0x2312, 0x329b, 0x4624, 0x57ad, 0x6536, 0x74bf,
0x8c48, 0x9dc1, 0xaf5a, 0xbed3, 0xca6c, 0xdbe5, 0xe97e, 0xf8f7,
0x1081, 0x0108, 0x3393, 0x221a, 0x56a5, 0x472c, 0x75b7, 0x643e,
0x9cc9, 0x8d40, 0xbfdb, 0xae52, 0xdaed, 0xcb64, 0xf9ff, 0xe876,
0x2102, 0x308b, 0x0210, 0x1399, 0x6726, 0x76af, 0x4434, 0x55bd,
0xad4a, 0xbcc3, 0x8e58, 0x9fd1, 0xeb6e, 0xfae7, 0xc87c, 0xd9f5,
0x3183, 0x200a, 0x1291, 0x0318, 0x77a7, 0x662e, 0x54b5, 0x453c,
0xbdcb, 0xac42, 0x9ed9, 0x8f50, 0xfbef, 0xea66, 0xd8fd, 0xc974,
0x4204, 0x538d, 0x6116, 0x709f, 0x0420, 0x15a9, 0x2732, 0x36bb,
0xce4c, 0xdfc5, 0xed5e, 0xfcd7, 0x8868, 0x99e1, 0xab7a, 0xbaf3,
0x5285, 0x430c, 0x7197, 0x601e, 0x14a1, 0x0528, 0x37b3, 0x263a,
0xdecd, 0xcf44, 0xfddf, 0xec56, 0x98e9, 0x8960, 0xbbfb, 0xaa72,
0x6306, 0x728f, 0x4014, 0x519d, 0x2522, 0x34ab, 0x0630, 0x17b9,
0xef4e, 0xfec7, 0xcc5c, 0xddd5, 0xa96a, 0xb8e3, 0x8a78, 0x9bf1,
0x7387, 0x620e, 0x5095, 0x411c, 0x35a3, 0x242a, 0x16b1, 0x0738,
0xffcf, 0xee46, 0xdcdd, 0xcd54, 0xb9eb, 0xa862, 0x9af9, 0x8b70,
0x8408, 0x9581, 0xa71a, 0xb693, 0xc22c, 0xd3a5, 0xe13e, 0xf0b7,
0x0840, 0x19c9, 0x2b52, 0x3adb, 0x4e64, 0x5fed, 0x6d76, 0x7cff,
0x9489, 0x8500, 0xb79b, 0xa612, 0xd2ad, 0xc324, 0xf1bf, 0xe036,
0x18c1, 0x0948, 0x3bd3, 0x2a5a, 0x5ee5, 0x4f6c, 0x7df7, 0x6c7e,
0xa50a, 0xb483, 0x8618, 0x9791, 0xe32e, 0xf2a7, 0xc03c, 0xd1b5,
0x2942, 0x38cb, 0x0a50, 0x1bd9, 0x6f66, 0x7eef, 0x4c74, 0x5dfd,
0xb58b, 0xa402, 0x9699, 0x8710, 0xf3af, 0xe226, 0xd0bd, 0xc134,
0x39c3, 0x284a, 0x1ad1, 0x0b58, 0x7fe7, 0x6e6e, 0x5cf5, 0x4d7c,
0xc60c, 0xd785, 0xe51e, 0xf497, 0x8028, 0x91a1, 0xa33a, 0xb2b3,
0x4a44, 0x5bcd, 0x6956, 0x78df, 0x0c60, 0x1de9, 0x2f72, 0x3efb,
0xd68d, 0xc704, 0xf59f, 0xe416, 0x90a9, 0x8120, 0xb3bb, 0xa232,
0x5ac5, 0x4b4c, 0x79d7, 0x685e, 0x1ce1, 0x0d68, 0x3ff3, 0x2e7a,
0xe70e, 0xf687, 0xc41c, 0xd595, 0xa12a, 0xb0a3, 0x8238, 0x93b1,
0x6b46, 0x7acf, 0x4854, 0x59dd, 0x2d62, 0x3ceb, 0x0e70, 0x1ff9,
0xf78f, 0xe606, 0xd49d, 0xc514, 0xb1ab, 0xa022, 0x92b9, 0x8330,
0x7bc7, 0x6a4e, 0x58d5, 0x495c, 0x3de3, 0x2c6a, 0x1ef1, 0x0f78,
};
// 计算给定长度数据的16位CRC。
u16 GetCrc16(const byte* pData, int nLength)
{
u16 fcs = 0xffff; // 初始化
while(nLength>0)
{
fcs = (fcs >> 8) ^ crctab16[(fcs ^ *pData) & 0xff];
nLength--;
pData++;
}
return ~fcs; // 取反
}
// 检查给定长度数据的16位CRC是否正确。
bool IsCrc16Good(const byte* pData, int nLength)
{
u16 fcs = 0xffff; // 初始化
while(nLength>0)
{
fcs = (fcs >> 8) ^ crctab16[(fcs ^ *pData) & 0xff];
nLength--;
pData++;
}
return (fcs == 0xf0b8); // 0xf0b8是CRC-ITU的"Magic Value"
}
使用字节型算法，前面出现的PPP帧FCS计算和验证过程，可用下面的程序片断实现：
byte ppp[13] = {0xFF, 0x03, 0xC0, 0x21, 0x04, 0x03, 0x00, 0x07, 0x0D, 0x03, 0x06, 0x00, 0x00};
u16 result;
// 计算CRC
result = GetCrc16(ppp, 11);
// 填写FCS，先低后高
ppp[11] = result & 0xff;
ppp[12] = (result >> 8) & 0xff;
// 验证FCS
if(IsCrc16Good(ppp, 13))
{
... ...
}
该例中数据长度为11，说明CRC计算并不要求数据2字节或4字节对齐。
至于查找表的生成算法，以及CRC-32等其它CRC的算法，可参考RFC 1661, RFC 3309等文档。需要注意的是，虽然CRC算法的本质是一样的，但不同的协议、标准所规定的初始化、移位次序、验证方法等可能有所差别。
结语
CRC是现代通信领域的重要技术之一。掌握CRC的算法与实现方法，在通信系统的设计、通信协议的分析以及软件保护等诸多方面，能发挥很大的作用。如在作者曾经设计的一个多串口数据传输系统中，每串口速率为460kbps，不加校验时误码率大于10-6，加上简单的奇偶校验后性能改善不很明显，利用CRC进行检错重传，误码率降低至10-15以下，满足了实际应用的要求。
参考文献
1. Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, 1994
2. J. Stone, "Stream Control Transmission Protocol (SCTP) Checksum Change", RFC 3309, 2002
3. J. Satran, "Internet Protocol Small Computer System Interface (iSCSI) Cyclic Redundancy Check (CRC)/Checksum Considerations", RFC 3385, 2002
4. International Standardization,"High-level data link control (HDLC) procedures", ISO/IEC 3309, 1992
5. ITU-T V.41, "Code-independent error-control system", 1989
6. 郭梯云等,《数据传输(修订本)》, 人民邮电出版社, 1998
扫一扫
3860
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
