Re: [Bluez-users] AUX1 packets

Re: [Bluez-users] AUX1 packets

[Thor Egil Skaug]

I am doing research on quality of service and fault tolerance in distributed 
systems,
and what I am working on is a configurable middleware with QoS 
(MicroQoSCORBA).
Currently I am researching meaningful QoS mechanisms for wireless 
transports, and right
now I am focusing on Bluetooth.

Middleware is supposed to mask all these things for the user (application 
designer),
including the different mechanisms for getting Bluetooth or whatever 
wireless or wired
transport to achieve the QoS that he/she expects.

So I am doing a lot of tests by playing around with the things you can do to 
make a BT connection
behave differently, to define a QoS space. In other wireless transports 
there are other switches
to play with. I am not necessarily looking to prove that a certain thing 
works, but also to prove
it doesn't.

What I wanted to do was let the middleware decide on the packet types for 
Bluetooth,
and since the same logic will be at both ends, both transports will choose 
the same packet
type as the link quality changes. Which makes sense since the time between a 
request is
sent from a client to a reply is sent from a server could be enough to have 
a decent change
in link quality.

Bringing me to the next question:

If I issue create_connection with a DH5 packet, the LM knows it can use DH5 
and DM1.
If I later issue change_conn_packet_type with DH3, is the LM allowed to 
switch to
DH5 behind my back if it wants to? Or is there a stored bit pattern in the 
LM of the
packet types that I allow that gets overwritten completely with the pattern 
in change_conn_pt?

I understand that the more meaningful thing to do is allowing all DH and DM 
packets, and let
the LM decide.

Thor

_________________________________________________________________
Click, drag and drop. My MSN is the simple way to design your homepage. 
http://click.atdmt.com/AVE/go/onm00200364ave/direct/01/



-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] AUX1 packets

[Steven Singer]

Thor Egil Skaug wrote:
> Middleware is supposed to mask all these things for the user (application designer),
> including the different mechanisms for getting Bluetooth or whatever wireless or wired
> transport to achieve the QoS that he/she expects.

If you want to mask it from the user then just let the controller do
the right thing. It has much more direct control than you do. It will
continuously be trying to optimise link.

It's not clear to me how knowing the QoS settings for link will alter
what settings are best for the link, so it's not clear to me what your
middleware brings to the situation.

Rather than concentrating on packet types, there are more useful things
the middleware can be doing - such as working out what are the optimum
number of ACL tokens to use for each link to avoid having so few
associated with a given link that the link starves and yet to avoid
having so many that if the link stalls (for example, because the two
devices are out of range) then there are insufficient to keep the other
links running.

> What I wanted to do was let the middleware decide on the packet types for Bluetooth,
> and since the same logic will be at both ends, both transports will choose the same packet
> type as the link quality changes. Which makes sense since the time between a request is
> sent from a client to a reply is sent from a server could be enough to have a decent change
> in link quality.

No.

The link quality is not symmetric. It's perfectly possible to have a
clear link in one direction and a noisy return link. For example, if
one end were near an interferer (such as the not unlikely scenario of
having an 802.11b card in the same PC one of the Bluetooth devices).

If we call the Bluetooth transmit power P_B dBm, the interferer power
P_I dBm and the link loss L dB, then at the end far from the interferer,
the Bluetooth power is P_B - L dBm and the interferer power is P_I - L dBm
so the signal to interferer ratio is (P_B - L) - (P_I - L) = P_B - P_I dB.
However, at the end near the interferer, the received Bluetooth power
is P_B - L dBm, but the received interferer power is P_I, so the signal
to interferer ratio is P_B - P_I - L dB. It would be easy to have a
signal to noise ratio at the far end of +20 dB (virtually every packet
received cleanly) and simultaneously for the near end to be at -20 dB
(virtually every packet lost while the interferer is on).

Then, to make matters worse, you can measure only the *received* bit
error rate, yet you can alter only the *transmitted* packet types. In
the scenario above, the far end will be receiving a low bit error rate
and, by your algorithm, be transmitting DH packets, yet the near end
will be receiving a high bit error rate and be transmitting DM packets.

This type of link control doesn't work unless you can communcate the
information to the other side in real time which, funnily enough, is
exactly what the standard Bluetooth CQDDR system will do.

You're trying to reinvent the wheel badly.

> If I issue create_connection with a DH5 packet, the LM knows it can use DH5  and DM1.
> If I later issue change_conn_packet_type with DH3, is the LM allowed to switch to
> DH5 behind my back if it wants to?

It's not allowed to do that - it's allowed to use only the packets in
the last command it received.

	- Steven
-- 



**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************



-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

RE: [Bluez-users] AUX1 packets

[Thor Egil Skaug]

>It's not clear to me how knowing the QoS settings for link will alter
what settings are best for the link, so it's not clear to me what your
middleware brings to the situation.

My research intends to enumerate mechanisms for QoS in wireless CORBA
transports - figuring out the switches in each standard that can be
toggeled to change the behavior of the wireless network. Then the
application designer (using CORBA) will decide on a type of wireless
network, and network requirements (these are generecized and not tied to
BT/IEEE8011.b etc). The middleware then takes these requirements and
uses the hooks specific to the wirless network to achieve what was
asked.

>You're trying to reinvent the wheel badly.

Thanks for the info on the received signal strenght versus the
transmission packet type. I didn't think of that. I could of course be
stubborn and say that if I wanted to let the application decide packet
types, I'd attach a byte of link quality to every message for the
receiver to use. But as you say, it is really reinventing the wheel
somewhat.

But if there are multiple CORBA server replicas, it could be interesting
to send each CORBA request to both servers, one link having packet
requirements, and the other letting CQDDR decide, then the client uses
the first reply and discards the other (in a CORBA client/server
application using BT).

More interesting: Is CQDDR implemented on all devices? I have a couple
that don't support reading RSSI/Link Quality?

Anyway, it makes some sence to me to try and force certain packet types,
since the system may have strict latency requirements, combining this
with flush timeouts for the connection.

Thor


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

[Bluez-users] AUX1 packets

[Thor Egil Skaug]

Is there any way of having an ACL connection use AUX1 packets?

The packet type is not defined in the Bluetooth specification for
the HCI_create_connection command.

I am using Belkin USB devices (CSR).

Can this be done by setting one of the reserved packet types,
or using a vendor specific command, or is it simply not possible?

The reason I want to do this is to measure the effect of having
CRC, FEC and ARQ on the software side, also using proactive
retransmits.

Thanks,

Thor E. Skaug


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] AUX1 packets

[Marcel Holtmann]

Hi Thor,

> Is there any way of having an ACL connection use AUX1 packets?
> 
> The packet type is not defined in the Bluetooth specification for
> the HCI_create_connection command.

you can't control this from the host stack side, because as you already
have seen it is not defined for the HCI_create_connection command. It is
the job of the link manager to choose the right packet types.

Regards

Marcel




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

RE: [Bluez-users] AUX1 packets

[Thor Egil Skaug]

>Hi Thor,
>
> Is there any way of having an ACL connection use AUX1 packets?
> 
> The packet type is not defined in the Bluetooth specification for the 
> HCI_create_connection command.
>
>you can't control this from the host stack side, because as you already
have seen it is not defined for the HCI_create_connection command. It is
the job of the link manager to choose the right packet types.
>
>Regards
>
>Marcel

Regarding DM and DH packets:
Am I correct in assuming the following?

If I use the HCI_change_connection_packet_type command, I can change the
packet type for the connection
as long as it is supported by both devices? It is then mostly my
decision what packet type is used for the
connection, although the link controller may use DM1 packets if
necessary.

I am trying to have my application select different packet types based
on the current BER.

Thor

Re: [Bluez-users] AUX1 packets

[Steven Singer]

Thor Egil Skaug wrote:
> I am trying to have my application select different packet types based
> on the current BER.

If both ends of the link support CQDDR then the Link Managers will do
this automatically.

If you try to do this yourself, you'll just end up with the host and the
controller fighting each other.

	- Steven
-- 




**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

RE: [Bluez-users] AUX1 packets

[Thor Egil Skaug]

>If both ends of the link support CQDDR then the Link Managers will do
this automatically.
>
>If you try to do this yourself, you'll just end up with the host and
the controller fighting each other.
>
>	- Steven

But the LM can only use packet types that I specified in
create_connection or change_connection_packet_type,
in addition to the mandatory DM1 type. Am I correct in assuming this?

Will the link manager notify me through events that CQDDR scheme has
changed packet type?

How do I know whether CQDDR is supported, and is there any way of
disabling this?

Thor


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] AUX1 packets

[Steven Singer]

Thor Egil Skaug wrote:
> But the LM can only use packet types that I specified in
> create_connection or change_connection_packet_type,
> in addition to the mandatory DM1 type. Am I correct in assuming this?

This is true, but, if you specify DM and DH packets, then the Link
Manager will switch automatically. If you try to specify just DH packets
but the Link Manager thinks the link is too poor to use them then, since
DM1 packets are always allowed, it will drop to DM1 giving poor bandwidth
(whereas if you'd left it alone it would have used DM5).

The only thing that works is specifying DM packets only.

Note also that you can alter the packet types only for the packets
sent by the controller. The information is not communicated over the
air, so the other side will be using whatever packet types its host
has suggested.

> Will the link manager notify me through events that CQDDR scheme has
> changed packet type?

No, and seeing as the LM can adapt very quickly, this could lead to
the host being flooded by messages.

> How do I know whether CQDDR is supported, and is there any way of
> disabling this?

CQDDR is supported if the appropriate features bit is set. BlueZ
reports it as Channel Quality (IIRC).

There's no standard way of disabling it. I've yet to be convinved
it would be a good thing.

In what way is automatic CQDDR inappropriate for your application.

	- Steven
-- 



**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************



-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users