RE: How to deal with broadcasting collision?

Susheel Nuguru — Tue, 10 May 2016 11:47:18 GMT

I am book marking this not just because of the math (which is awesome BTW), but also because of the efforts you took to explain this. you rock :)

RE: How to deal with broadcasting collision?

RK — Tue, 10 May 2016 11:42:41 GMT

I'm not sure all the assumptions in it are right, pretty sure the maths is right based on the assumptions and the numbers it gave seemed to agree with my back of the envelope guesses about how long the advertising interval would need to be. But it could be a factor of 10 or more out as far as I really know.

RE: How to deal with broadcasting collision?

Susheel Nuguru — Tue, 10 May 2016 08:43:15 GMT

I am gonna bookmark this answer RK :)

RE: How to deal with broadcasting collision?

qoboty — Fri, 06 May 2016 08:17:54 GMT

Thanks,

How many device I could scan out at most? or How many devices could send adverting packet on the advertise channels support ? Is there fomula to caculate?

RE: How to deal with broadcasting collision?

RK — Fri, 06 May 2016 07:41:36 GMT

Yes bluetooth has a mechanism to deal with broadcast collisions by adding in a small element of randomness between advertisements. If you have enough devices however and a short enough advertising interval on every one of them, you could eventually get to the point there's always more than one broadcasting on every channel at one time.

Let's try to develop some idea of how likely it is one transmitting device will get an advertising packet out with nothing else overlapping it ..

Say your advertising interval is I and the length of an advertising packet is a. Assuming that the randomness factor makes the start of any given packet in an interval random and uniformly distributed, what's the probability that another given advertiser's packet will overlap any piece of yours?

Well if it starts anywhere between a before you start up until when you finish, it will overlap, so that's a window of 2a. However it could be on a different channel, so that gives us a 1/3 probability that it's on your channel. If the distribution is uniform over I then

P(overlap) = 2a/3I

so therefore the probability that it doesn't overlap is

P(miss) = 1 - 2a/3I

Let's say there are N advertisers and make the somewhat incorrect assumption that to get your packet out in the clear to even be possible to find, you must miss all of them.

P(miss all) = ( 1 - 2a/3I )^( N-1 )

Let's put some numbers in. Advertising packets are 80-376 bits long at 1Mb/s, let's say it's not a max length packet, it's 300bits so that's 300e-6 seconds or 3e-4 seconds. Your interval is 40mS which is 4e-2 so

P(miss all) = ( 1 - 2x3e-4 / 3x4e-2 ) ^ 499 = ( 1 - .0006 / 0.12 )^499 = .082, or about 8.2%.

Let's go the other way

P(miss all) = P(miss) ^ ( N - 1 ) --> P(miss) = exp( ln( P(miss all) / ( N - 1 ) )

say you want it to be 1/2 and you have your N as 500 still, so

P(miss) = exp( ln ( 0.5 ) / 499 ) = 0.9986

so ( 1 - 2a / 3I ) = .9986

Since the length of the advertising packet is fixed at (I assumed) 3e-4 we have

( 1 - 6e-4 / 3I ) = .9986 --> I = 6e-4/( 3 x ( 1 - .9986 ) ) = 0.143

So with these rather broad assumptions, if you have 500 devices each with a 300 bit advertising packet (including preamble), in order to have a 50% chance any given advertising packet gets out in the clear, ie not overlapped by any other packet, you need an advertising interval of around 150ms.

So on average at 40ms your device gets about 8% of its advertising packets out in the clear, which would make discovery a bit slow. At 150ms 50% of them get out in the clear.

That's my back-of-the-envelope calculation, you should see the device eventually however it may take a while for the randomness to slide it into that 8% window.