Re: [bluetooth] question...

[Alban Villain <Alban.Villain@inventel.fr>]

Hi Niko,

The problem you point concerning error is always valid for any
transmission/reception system, and especially for wireless
systems.

When you receive data, even protected with any error correction code,
there is always a non zero probability that these data are
corrupted.

So, for the Bluetooth baseband case, if you decode a wrong payload length
: 
- if it is > to the max length for this packet type (that you know
from the packet header), trash the packet ;
- if it is not > to the max length for this packet type, you may
detect that it is a wrong packet using the CRC. However, it may happen
that for a wrong packet, the CRC circuitry calculate the same CRC as the
one received (with a probability of 1/(2^16)). 

So, to summarize, in general you can discard bad packets by looking at
the CRC, or by looking at the FEC2/3 correction if it has detected a
non-correctable arror, or ly looking their length according to packet
type.

However, in a very few case, it may happen that a bad packet
passes all the tests above....

In this case, the baseband has no choice, it has to send this packet to
the higher layers of the stack. Then it depends of what happen to this
packet. The layer concerned with this packet may not recognize a valid
opcode or a valid packet structure or a valid high level error control
check sequence (RFCOMM uses FCS), and discard the packet.

At last a Bluetooth stack crash may occur because of this bad packet....
and then you need to restart your device !!! However, as it may happen
statistically 1 time every lots of hours it is not so dramatic... because
in general Windows (if you use a PC as Bluetooth host) will have crashed
before that ;-) I

Regards,

Alban

> Hi Alban,
>
> Thank you so much for your swift response !
> The problem I saw with the FEC 2/3 decoding is that the FEC 2/3 can not
> detect all errors, so what if the paylenght indicator field has errors
> ?  
> This error would then only be detected at the CRC ?
>
> Or doesn't it matter ?  If the lenght field is wrong, and we decode
> a wrong number of bits, then this will be flagged almost for sure by the
> CRC, and we'll have to retransmit the packet anyway ?
>
> Thanks for your help !
>
> Niko
>
>
> > From: Alban Villain
> > <Alban.Villain@inventel.fr>
> > Reply-To: bluetooth@opencores.org
> > To: bluetooth@opencores.org
> > Subject: Re: [bluetooth] question...
> > Date: Thu, 16 Jan 2003 09:56:59 +0100
> >
> > Hi Niko,
> >
> > I cannot see where there is a problem....
> > The payload that are FEC2/3 encoded all have a CRC and are at least 3
> > byte long prior to FEC 2/3 encoding (1 byte for payload header and 2
> > bytes for CRC).
> > That is, you have enough bit to decode the payload length before the end
> > of the packet.
> > This was for 1 slot packet, the same applies for 3 and 5-slots
> > packets.
> >
> > Hope it helps,
> >
> > Regards,
> >
> > Alban


Alban Villain

Inventel -
http://www.inventel.com
Paris

**********************************************************************
This e-mail and its attachments are confidential and intended solely for
the 
addressees. If you are not the intended recipient of this message, then
please delete it and notify the sender. Since the integrity of this
message 
cannot be guaranteed on the Internet, Inventel cannot therefore be 
considered responsible for its content. 
**********************************************************************