Hi,
LE profiles have different requirements for connection parameters. Mainly
trying to balance between power consumption and latencies. Probably more will
factors will be in future.
Currently I have plan to introduce new l2cap socket option which can be used
before connection creation to set inital settings and also change settings
while having a connection.
Since there is no equivalents in EDR/BR connection I'm planning to make then
apply only LE connection.
Other question which parameters should be exposed to user space? Connection
creation and connection update have these common parameters. Connection
creation has in addition some other parameters also but they should be handled
in some other way.
__le16 conn_interval_min;
__le16 conn_interval_max;
__le16 conn_latency;
__le16 supervision_timeout;
__le16 min_ce_len;
__le16 max_ce_len;
So far I have had two ideas. The first is to simply expose all these fields
with sock_opt. In that way profiles would be able to define their requirements
also in future without any sock opt changes.
Second is to define BT_LE_LOW_LAT for low latency connection requirements and
BT_LE_LOW_POWER connection where the latency is not an issue. It would make
usage of this sock opt interface simplier. OTOH the only user should be
bluetoothd so it doesn't need to be as simple as possible.
Comments please.
--
Ville
Hi Ville,
* Ville Tervo <[email protected]> [2010-11-15 17:17:39 +0200]:
> Hi Tim,
>
> Please stop top posting on this ml.
>
> On Mon, Nov 15, 2010 at 03:24:29PM +0100, ext [email protected] wrote:
> > Hi Ville,
> >
> > As you note the different profiles would likely have different connection parameters. The different profiles may be running on the same LE link (indeed the same L2CAP [fixed] channel).
> >
>
> I guess the latency should override power requirements. Low power profile can
> operate on low latency link but low latency profile fails on high latency. Of
> course this gets much more complicated if there are more requirements.
>
> Are these (latency and power) the only characteristics we need to deal with.
> There might be some also. I'm not too familiar with profile drafts.
>
> > Do you have a view on how the different profiles - on the same link - would have different requests arbitrated, and where that arbitration would be done? I'd imagine that the API towards the profiles should be of the abstract form - such as you mention (eg BT_LE_LOW_LAT). This would make it easier to arbitrate the different requests, as compared to if the profiles see an API of the "numerical" form (eg interval = N ms). I guess the arbitration could happen in user or kernel space; as long as there is something with singleton-like semantics to do it.
> >
>
> I think I need to get more details from profile specs and try to find out the
> requirements from them.
>
> Right now I'm trying to find out what would be the right interface from kernel
> to user space.
If you go with the abstraction in userspace (inside bluetoothd) will be easy to
create usage profiles on top of it or even do a fine tune of the parameters
for a specific usage. New profiles should be created in the future and we
can't foresee its requirements. And I'm seeing that we will have many
many different use cases for LE in the future. It can be hard to extend
the API if we do the abstraction in the kernel because we can't break
the API that we are going to create.
We also have to check if we really need all the parameters you are
proposing, maybe we can simplify that API. What about you send a e-mail
explaining why we should add each parameter to the API?
--
Gustavo F. Padovan
http://profusion.mobi
Hi,
On Tue, Nov 16, 2010 at 11:56 AM, <[email protected]> wrote:
> Ville,
>
>> > As you note the different profiles would likely have different
>> connection parameters. ?The different profiles may be running on the
>> same LE link (indeed the same L2CAP [fixed] channel).
>> >
>>
>> I guess the latency should override power requirements. Low power
>> profile can
>> operate on low latency link but low latency profile fails on high
>> latency. Of
>> course this gets much more complicated if there are more requirements.
>
> Agreed.
>
>>
>> Are these (latency and power) the only characteristics we need to deal
>> with.
>> There might be some also. I'm not too familiar with profile drafts.
>
> I think these are the main issues; however I wonder whether link supervision timeout may conflict for different use cases. ?Even if it is not the link supervision the lifetime of the physical link may differ between profiles (some may want the link up for a long time but send no data). Slightly off-topic; but still it raises issues around the type of API and the arbitration of different profile requirements on the same link.
>> > Do you have a view on how the different profiles - on the same link -
>> would have different requests arbitrated, and where that arbitration
>> would be done? ?I'd imagine that the API towards the profiles should be
>> of the abstract form - such as you mention (eg BT_LE_LOW_LAT). ?This
>> would make it easier to arbitrate the different requests, as compared
>> to if the profiles see an API of the "numerical" form (eg interval = N
>> ms). ?I guess the arbitration could happen in user or kernel space; as
>> long as there is something with singleton-like semantics to do it.
>> >
>>
>> I think I need to get more details from profile specs and try to find
>> out the
>> requirements from them.
>
> As an aside, it's not just the application profiles. ?If you have a link to a device with high latency and need to do more service search using GATT then you might want to lower the latency temporarily. ?This may impact the type of API control you give GATT applications versus any in-built GATT service discovery.
Well maybe we could have some sort of QoS API for l2cap sockets, for
instance using link supervision timeout would be very nice to detect
link loss on audio profiles where 20 sec. is way too big, and the
timeout to enter sniff mode could be dynamically adjusted. Normally we
don't export those for userspace but I guess for LE this has to be
done anyway and iirc l2cap sockets require privileges so basically
only root will be able to play with this so e.g. would be able
bluetoothd to adjust the parameter depending on the profile.
--
Luiz Augusto von Dentz
Computer Engineer
Ville,
> > As you note the different profiles would likely have different
> connection parameters. The different profiles may be running on the
> same LE link (indeed the same L2CAP [fixed] channel).
> >
>
> I guess the latency should override power requirements. Low power
> profile can
> operate on low latency link but low latency profile fails on high
> latency. Of
> course this gets much more complicated if there are more requirements.
Agreed.
>
> Are these (latency and power) the only characteristics we need to deal
> with.
> There might be some also. I'm not too familiar with profile drafts.
I think these are the main issues; however I wonder whether link supervision timeout may conflict for different use cases. Even if it is not the link supervision the lifetime of the physical link may differ between profiles (some may want the link up for a long time but send no data). Slightly off-topic; but still it raises issues around the type of API and the arbitration of different profile requirements on the same link.
> > Do you have a view on how the different profiles - on the same link -
> would have different requests arbitrated, and where that arbitration
> would be done? I'd imagine that the API towards the profiles should be
> of the abstract form - such as you mention (eg BT_LE_LOW_LAT). This
> would make it easier to arbitrate the different requests, as compared
> to if the profiles see an API of the "numerical" form (eg interval = N
> ms). I guess the arbitration could happen in user or kernel space; as
> long as there is something with singleton-like semantics to do it.
> >
>
> I think I need to get more details from profile specs and try to find
> out the
> requirements from them.
As an aside, it's not just the application profiles. If you have a link to a device with high latency and need to do more service search using GATT then you might want to lower the latency temporarily. This may impact the type of API control you give GATT applications versus any in-built GATT service discovery.
> Right now I'm trying to find out what would be the right interface from
> kernel
> to user space.
>
> > Also - a quick observation: yes, the connection parameters are only
> for LE links; however they have some semantic similarity with sniff
> mode in BR. Especially in the abstract form ("Low Latency" verus "Low
> Power"). Does BlueZ present an API like this already for BR (I'm new
> to BlueZ...I was more of a Symbian guy ;)? If not it might be worth
> having one API for both BR/Sniff and LE/Connection Parameters - and do
> the appropriate mapping "under the hood".
>
> Actually this has been discussed earlier and we need also some api to
> change
> sniff behaviour. Reason for this is broken devices which does not turn
> on
> normal mode when low latency is needed. I guess Jaikumar had some
> patches
> regarding this?
I think it's a bit deeper than broken devices: the specifications offer no real way for devices to agree why a particular mode (eg active or sniff) is needed at a particular time. This then gives interoperability problems because one side may decide it wants sniff mode; but the other does not know why.
Tim
This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.
Hi Mike,
n Mon, Nov 15, 2010 at 07:15:44PM +0100, ext Mike Tsai wrote:
> Hi Ville,
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of Ville Tervo
> Sent: Monday, November 15, 2010 4:07 AM
> To: [email protected]
> Subject: [RFC] Interface to set LE connection parameters
>
> Hi,
>
> LE profiles have different requirements for connection parameters. Mainly
> trying to balance between power consumption and latencies. Probably more will
> factors will be in future.
>
> Currently I have plan to introduce new l2cap socket option which can be used
> before connection creation to set inital settings and also change settings
> while having a connection.
>
> Since there is no equivalents in EDR/BR connection I'm planning to make then
> apply only LE connection.
>
>
> Other question which parameters should be exposed to user space? Connection
> creation and connection update have these common parameters. Connection
> creation has in addition some other parameters also but they should be handled
> in some other way.
>
> __le16 conn_interval_min;
> __le16 conn_interval_max;
> __le16 conn_latency;
> __le16 supervision_timeout;
> __le16 min_ce_len;
> __le16 max_ce_len;
>
> So far I have had two ideas. The first is to simply expose all these fields
> with sock_opt. In that way profiles would be able to define their requirements
> also in future without any sock opt changes.
>
> Second is to define BT_LE_LOW_LAT for low latency connection requirements and
> BT_LE_LOW_POWER connection where the latency is not an issue. It would make
> usage of this sock opt interface simplier. OTOH the only user should be
> bluetoothd so it doesn't need to be as simple as possible.
>
>
> Comments please.
>
> [MTsai] - how about following parameters,
>
> Scan internal,
> Scan window,
> Peer address type,
These are connection creation parameters. Maybe BT_LE_LOW_LAT/BT_LE_LOW_POWER
could be used also for these values. But I think they should defined in some
other way.
--
Ville
Hi Ville,
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Ville Tervo
Sent: Monday, November 15, 2010 4:07 AM
To: [email protected]
Subject: [RFC] Interface to set LE connection parameters
Hi,
LE profiles have different requirements for connection parameters. Mainly
trying to balance between power consumption and latencies. Probably more will
factors will be in future.
Currently I have plan to introduce new l2cap socket option which can be used
before connection creation to set inital settings and also change settings
while having a connection.
Since there is no equivalents in EDR/BR connection I'm planning to make then
apply only LE connection.
Other question which parameters should be exposed to user space? Connection
creation and connection update have these common parameters. Connection
creation has in addition some other parameters also but they should be handled
in some other way.
__le16 conn_interval_min;
__le16 conn_interval_max;
__le16 conn_latency;
__le16 supervision_timeout;
__le16 min_ce_len;
__le16 max_ce_len;
So far I have had two ideas. The first is to simply expose all these fields
with sock_opt. In that way profiles would be able to define their requirements
also in future without any sock opt changes.
Second is to define BT_LE_LOW_LAT for low latency connection requirements and
BT_LE_LOW_POWER connection where the latency is not an issue. It would make
usage of this sock opt interface simplier. OTOH the only user should be
bluetoothd so it doesn't need to be as simple as possible.
Comments please.
[MTsai] - how about following parameters,
Scan internal,
Scan window,
Peer address type,
Thanks,
Mike
--
Ville
Hi Tim,
Please stop top posting on this ml.
On Mon, Nov 15, 2010 at 03:24:29PM +0100, ext [email protected] wrote:
> Hi Ville,
>
> As you note the different profiles would likely have different connection parameters. The different profiles may be running on the same LE link (indeed the same L2CAP [fixed] channel).
>
I guess the latency should override power requirements. Low power profile can
operate on low latency link but low latency profile fails on high latency. Of
course this gets much more complicated if there are more requirements.
Are these (latency and power) the only characteristics we need to deal with.
There might be some also. I'm not too familiar with profile drafts.
> Do you have a view on how the different profiles - on the same link - would have different requests arbitrated, and where that arbitration would be done? I'd imagine that the API towards the profiles should be of the abstract form - such as you mention (eg BT_LE_LOW_LAT). This would make it easier to arbitrate the different requests, as compared to if the profiles see an API of the "numerical" form (eg interval = N ms). I guess the arbitration could happen in user or kernel space; as long as there is something with singleton-like semantics to do it.
>
I think I need to get more details from profile specs and try to find out the
requirements from them.
Right now I'm trying to find out what would be the right interface from kernel
to user space.
> Also - a quick observation: yes, the connection parameters are only for LE links; however they have some semantic similarity with sniff mode in BR. Especially in the abstract form ("Low Latency" verus "Low Power"). Does BlueZ present an API like this already for BR (I'm new to BlueZ...I was more of a Symbian guy ;)? If not it might be worth having one API for both BR/Sniff and LE/Connection Parameters - and do the appropriate mapping "under the hood".
Actually this has been discussed earlier and we need also some api to change
sniff behaviour. Reason for this is broken devices which does not turn on
normal mode when low latency is needed. I guess Jaikumar had some patches
regarding this?
--
Ville
Hi Ville,
As you note the different profiles would likely have different connection parameters. The different profiles may be running on the same LE link (indeed the same L2CAP [fixed] channel).
Do you have a view on how the different profiles - on the same link - would have different requests arbitrated, and where that arbitration would be done? I'd imagine that the API towards the profiles should be of the abstract form - such as you mention (eg BT_LE_LOW_LAT). This would make it easier to arbitrate the different requests, as compared to if the profiles see an API of the "numerical" form (eg interval = N ms). I guess the arbitration could happen in user or kernel space; as long as there is something with singleton-like semantics to do it.
Also - a quick observation: yes, the connection parameters are only for LE links; however they have some semantic similarity with sniff mode in BR. Especially in the abstract form ("Low Latency" verus "Low Power"). Does BlueZ present an API like this already for BR (I'm new to BlueZ...I was more of a Symbian guy ;)? If not it might be worth having one API for both BR/Sniff and LE/Connection Parameters - and do the appropriate mapping "under the hood".
Cheers,
Tim
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Ville Tervo
Sent: 15 November 2010 12:07
To: [email protected]
Subject: [RFC] Interface to set LE connection parameters
Hi,
LE profiles have different requirements for connection parameters. Mainly
trying to balance between power consumption and latencies. Probably more will
factors will be in future.
Currently I have plan to introduce new l2cap socket option which can be used
before connection creation to set inital settings and also change settings
while having a connection.
Since there is no equivalents in EDR/BR connection I'm planning to make then
apply only LE connection.
Other question which parameters should be exposed to user space? Connection
creation and connection update have these common parameters. Connection
creation has in addition some other parameters also but they should be handled
in some other way.
__le16 conn_interval_min;
__le16 conn_interval_max;
__le16 conn_latency;
__le16 supervision_timeout;
__le16 min_ce_len;
__le16 max_ce_len;
So far I have had two ideas. The first is to simply expose all these fields
with sock_opt. In that way profiles would be able to define their requirements
also in future without any sock opt changes.
Second is to define BT_LE_LOW_LAT for low latency connection requirements and
BT_LE_LOW_POWER connection where the latency is not an issue. It would make
usage of this sock opt interface simplier. OTOH the only user should be
bluetoothd so it doesn't need to be as simple as possible.
Comments please.
--
Ville