2010-10-06 00:58:22 +08:00
|
|
|
Background
|
|
|
|
==========
|
|
|
|
|
|
|
|
- Priority scale: High, Medium and Low
|
|
|
|
|
|
|
|
- Complexity scale: C1, C2, C4 and C8. The complexity scale is exponential,
|
|
|
|
with complexity 1 being the lowest complexity. Complexity is a function
|
|
|
|
of both task 'complexity' and task 'scope'.
|
|
|
|
|
|
|
|
The general rule of thumb is that a complexity 1 task should take 1-2 weeks
|
|
|
|
for a person very familiar with BlueZ codebase. Higher complexity tasks
|
|
|
|
require more time and have higher uncertainty.
|
|
|
|
|
|
|
|
Higher complexity tasks should be refined into several lower complexity tasks
|
|
|
|
once the task is better understood.
|
|
|
|
|
2010-10-15 21:03:01 +08:00
|
|
|
Low Energy
|
|
|
|
==========
|
|
|
|
|
|
|
|
- Avoid Characteristic discovery for non connectable devices. Proper parsing
|
|
|
|
of LE Advertising Report Event is missing. Event_Type field needs to be
|
|
|
|
extracted and its value shall be considered before to start the LE
|
|
|
|
connection on the channel 4. Characteristic discovery should not be
|
|
|
|
started for non connectable devices.
|
|
|
|
|
|
|
|
Priority: Medium
|
|
|
|
Complexity: C2
|
2010-10-14 01:44:27 +08:00
|
|
|
|
2010-10-20 05:27:11 +08:00
|
|
|
- Advertising management. Adapter interface needs to be changed to manage
|
|
|
|
connection modes, adapter type and advertising policy. See Volume 3,
|
|
|
|
Part C, section 9.3. If Attribute Server is enabled the LE capable
|
|
|
|
adapter shall to start advertising. Further investigation is necessary
|
|
|
|
to define which connectable mode needs to be supported: Non-connectable,
|
|
|
|
directed connectable and undirected connectable. Basically, two connectable
|
|
|
|
scenarios shall be addressed:
|
|
|
|
1. GATT client is disconnected, but intends to become a Peripheral to
|
|
|
|
receive indications/notifications.
|
|
|
|
2. GATT server intends to accept connections.
|
|
|
|
|
|
|
|
Priority: Medium
|
|
|
|
Complexity: C2
|
|
|
|
|
2010-10-20 05:27:12 +08:00
|
|
|
- Define Auto Connection Establishment Procedure. Some profiles such as
|
|
|
|
Proximity requires an active link to identify path lost situation. It is
|
|
|
|
necessary to define how to manage connections, it seems that White List
|
|
|
|
is appropriated to address auto connections, however is not clear if the
|
|
|
|
this procedure shall be a profile specific detail or if the remote device
|
|
|
|
object can expose a property "WhiteList", maybe "Trusted" property can be
|
|
|
|
also used for this purpose. Another alternative is to define a method to
|
|
|
|
allow application to request/register the wanted scanning/connection
|
|
|
|
parameters. Before start this task, a RFC/PATCH shall be sent to the ML.
|
|
|
|
See Volume 3, Part C, section 9.3.5 for more information.
|
|
|
|
|
|
|
|
Priority: Medium
|
|
|
|
Complexity: C2
|
|
|
|
|
2010-10-14 01:44:27 +08:00
|
|
|
- Device Name Characteristic is a GAP characteristic for Low Energy. This
|
|
|
|
characteristic shall be integrated/used in the discovery procedure. The
|
|
|
|
ideia is to report the value of this characteristic using DeviceFound signals.
|
|
|
|
Discussion with the community is needed before to start this task. Other GAP
|
|
|
|
characteristics for LE needs to follow a similar approach. It is not clear
|
|
|
|
if all GAP characteristics can be exposed using properties instead of a primary
|
|
|
|
service characteristics.
|
|
|
|
See Volume 3, Part C, section 12.1 for more information.
|
|
|
|
|
|
|
|
Priority: Low
|
|
|
|
Complexity: C2
|
2010-10-06 00:58:22 +08:00
|
|
|
|
|
|
|
ATT/GATT
|
|
|
|
========
|
|
|
|
|
2010-10-08 00:21:55 +08:00
|
|
|
- Add ATT/GATT parsing to hcidump
|
|
|
|
|
|
|
|
Priority: Medium
|
|
|
|
Complexity: C2
|
|
|
|
|
|
|
|
- GATT server: fix MTU exchange
|
|
|
|
|
|
|
|
Priority: Medium
|
|
|
|
Complexity: C2
|
|
|
|
|
|
|
|
- GATT server: fix read by UUID (read by handle works)
|
|
|
|
|
|
|
|
Priority: Medium
|
|
|
|
Complexity: C2
|
|
|
|
|
|
|
|
- gatttool: add an interactive command prompt mode. Many LE devices
|
|
|
|
expect the connection to stay up a long time and disable advertising
|
|
|
|
after a disconnection so it's inconvenient to use gatttool in the
|
|
|
|
current "single operation at a time" mode.
|
|
|
|
|
|
|
|
Priority: Medium
|
|
|
|
Complexity: C2
|
|
|
|
|
2010-10-06 17:21:17 +08:00
|
|
|
- gatttool should have the ability to wait for req responses before
|
|
|
|
quitting (some servers require a small sleep even with cmd's). Maybe a
|
|
|
|
--delay-exit or --timeout command line switch.
|
2010-10-06 00:58:22 +08:00
|
|
|
|
|
|
|
Priority: Low
|
|
|
|
Complexity: C1
|
|
|
|
|
2010-10-07 04:43:23 +08:00
|
|
|
- Client needs to export a property in the Device Characteristic hierarchy
|
|
|
|
to manage characteristic value changes reports in the remote device.
|
|
|
|
Currently, Client Characteristic Configuration attribute is not exposed
|
|
|
|
as an object. The user needs to use gatttool to change the value of the
|
|
|
|
this attribute to receive notification/indications. Export this attribute
|
|
|
|
as a property is a proposal that needs further discussion.
|
|
|
|
|
|
|
|
Priority: Low
|
|
|
|
Complexity: C1
|
|
|
|
|
2010-10-07 05:00:05 +08:00
|
|
|
- Attribute server should process queued GATT/ATT commands if the
|
|
|
|
client disconnects. The client can simply send a command and quit,
|
|
|
|
without wait for a response(ex: Write Command). For this scenario
|
|
|
|
that the client disconnects the link quickly the queued received
|
|
|
|
command is ignored.
|
|
|
|
|
|
|
|
Priority: Low
|
|
|
|
Complecity: C1
|
|
|
|
|
2010-10-06 00:58:22 +08:00
|
|
|
- Add sdp discovery support to gattool with BR (--sdp, default is 0x1f)
|
|
|
|
|
|
|
|
Priority: Low
|
|
|
|
Complexity: C1
|
|
|
|
|
2010-10-14 00:37:13 +08:00
|
|
|
- Implement Server characteristic Configuration support in the attribute
|
|
|
|
server to manage characteristic value broadcasting. There is a single
|
|
|
|
instance of the Server Characteristic Configuration for all clients.
|
|
|
|
See Volume 3, Part G, section 3.3.3.4 for more information.
|
|
|
|
|
|
|
|
Priority: Low
|
|
|
|
Complexity: C1
|
|
|
|
|
2010-10-08 00:21:55 +08:00
|
|
|
- Long reads/writes don't work (consisting of multiple request packets)
|
2010-10-06 17:20:28 +08:00
|
|
|
|
2010-10-08 00:21:55 +08:00
|
|
|
Priority: Low
|
2010-10-06 17:20:28 +08:00
|
|
|
Complexity: C2
|
2010-10-06 19:40:29 +08:00
|
|
|
|
2010-10-08 00:21:55 +08:00
|
|
|
- Attribute server shall implement attribute permission verification,
|
|
|
|
returning an error code if necessary. See Volume 3, Part F, 3.2.5
|
|
|
|
for more information.
|
2010-10-06 19:40:29 +08:00
|
|
|
|
2010-10-08 00:21:55 +08:00
|
|
|
Priority: Low
|
2010-10-06 19:40:29 +08:00
|
|
|
Complexity: C2
|
2010-10-14 00:34:10 +08:00
|
|
|
|
|
|
|
- Implement Client Characteristic Configuration support in the attribute
|
|
|
|
server to manage indications and notications. This is a per client attribute
|
|
|
|
to control how the client wants to receive reports of changes in a given
|
|
|
|
characteristic value.
|
|
|
|
See Volume 3, Part G, section 3.3.3.3 for more information
|
|
|
|
|
|
|
|
Priority: Low
|
|
|
|
Complexity: C2
|
2010-10-15 21:03:02 +08:00
|
|
|
|
|
|
|
- Define attribute server API. External applications needs to register,
|
|
|
|
change attributes and to be notified about changes. Example: Proximity,
|
|
|
|
Time and Alert Profiles. "Local Service hierarchy" in the attribute-api
|
|
|
|
needs to be proposed and a RFC shall be sent to the ML.
|
|
|
|
|
|
|
|
Priority: Low
|
|
|
|
Complexity: C2
|
2010-10-20 05:27:10 +08:00
|
|
|
|
|
|
|
- gattrib needs to be extended to handle Attribute Protocol Transactions
|
|
|
|
timeout. See Volume 3, Part F, section 3.3.3 and Part G, section 4.14
|
|
|
|
for more information.
|
|
|
|
|
|
|
|
Priority: Low
|
|
|
|
Complexity: C2
|