蓝牙核心规范AUX_ADV_IND示例是否存在CRC计算勘误？

蓝牙核心规范第6.C.4.2.2节（第2909页）给出了一个扩展广播PDU示例：

PDU:
11100000 00001000 01010010 10010010 01110101 10110101 00110101
11010101 01010101 10010101 00111101 01010111 01101011 10100000
11100000 10010000 11010000 10110000
CRC:
00011011 11000100 01110101

数据包的上述部分是第6.B.3.1.1节（第2733-2734页）定义的CRC算法唯一处理的内容。通过以下Perl脚本生成的白化序列可以验证原始PDU的正确性（两者完全匹配，无错误）：

$ perl -e '$c=0x71;$a="11100000 00001000 01010010 10010010 01110101 "
   ."10110101 00110101 11010101 01010101 10010101 00111101 01010111 "
   ."01101011 10100000 11100000 10010000 11010000 10110000 00011011 "
   ."11000100 01110101"; for$d(0..length($a)-1){$e=substr($a,$d,1); 
   if($e=~y/01//){$c+=$c;if($c&0x80){$c^=0x91;$e=~y/01/10/;}} 
   print$e;}print"
";'
00011100 01111110 01111011 11101111 00100101 00000010 10101001
01111001 10010100 00100000 11101100 11000110 01101001 11101101
11011101 01010011 00101000 01011100 01001001 00111110 11010100

但我无法重现示例中给出的CRC值。按照规范，广播数据包的CRC移位寄存器应预设为常量0x555555，这也是CRC RevEng工具的默认设置：

$ reveng -m crc-24/ble -c 07104a49aeadacabaaa9bcead60507090b0d
a68bc4

转换为二进制后结果如下：

01100101 11010001 00100011

将消息的第一个字节0x07修改为0x27，就能得到示例中给出的CRC值（以下为十六进制等价形式）：

$ reveng -m crc-24/ble -c 27104a49aeadacabaaa9bcead60507090b0d
d823ae

但白化序列已经验证了原始PDU的正确性（否则两者都会出错）。另外，改用修改后的初始向量0x515555也能得到相同结果，效果和上述比特翻转一致：

$ reveng -m crc-24/ble -i 515555 -c 07104a49aeadacabaaa9bcead60507090b0d
d823ae

这个0x515555常量并未在蓝牙规范中提及，也没有任何线索说明它的推导方式。

因此我有以下疑问：

• 此场景下CRC初始向量是否应为0x515555？
• 规范中的PDU示例是否存在错误？
• 还是示例中的CRC计算本身有误？

内容的提问来源于stack exchange，提问作者regregex