-----Original Message----- From: Claudio Takahasi [mailto:claudio.takahasi@xxxxxxxxxxxxx] Sent: Monday, October 25, 2010 11:55 AM To: Mike Tsai Cc: BlueZ development Subject: Re: [RFC] LE connections and advertising management On Mon, Oct 25, 2010 at 3:16 PM, Mike Tsai <Mike.Tsai@xxxxxxxxxxx> wrote: > > > -----Original Message----- > From: Claudio Takahasi [mailto:claudio.takahasi@xxxxxxxxxxxxx] > Sent: Monday, October 25, 2010 10:56 AM > To: Mike Tsai > Cc: BlueZ development > Subject: Re: [RFC] LE connections and advertising management > > On Mon, Oct 25, 2010 at 2:11 PM, Mike Tsai <Mike.Tsai@xxxxxxxxxxx> wrote: >> >> -----Original Message----- >> From: linux-bluetooth-owner@xxxxxxxxxxxxxxx [mailto:linux-bluetooth-owner@xxxxxxxxxxxxxxx] On Behalf Of Claudio Takahasi >> Sent: Monday, October 25, 2010 5:53 AM >> To: BlueZ development >> Subject: [RFC] LE connections and advertising management >> >> Hi all, >> >> Interleave BR/EDR/LE discovery is implemented, the next step in the >> user space is how to manage advertising and LE connections. >> >> Some aspects: >> 1. Only one LE connection is allowed(per peer), meaning only one >> GAttrib instance will be allowed otherwise it will not be possible to >> serialize commands/events >> 2. The remote/Peripheral can support more than one GATT primary service >> 3. We are planning to use "direct" connections only, meaning that we >> will not use whitelist and the application interested must inform the >> remote address/object to connect to. >> 4. Kernel manages the connection establishment, currently there isn't >> a Âway to change the connection parameters. BMI or ioctls will be >> required to change the default parameters and also to trigger SMP >> negotiation. >> >> >> Some ideas: >> 1. implement a characteristic driver: basically to provide an >> abstraction to GATT clients. ex: Proximity, Health, ... >> 2. We don't need to implement Proximity and other GATT clients as a >> plugin at the moment, it can be enabled automatically by >> --enable-attrib >> 3. GATT clients could register a watcher/filter for advertising events >> 4. GATT clients doesn't need to know ATT, in theory it can handle >> characteristics only >> 5. GATT clients needs to control/request LE connections based on the >> advertisement received >> >> An initial draft implementing part of this idea is here: >> git://git.infradead.org/users/cktakahasi/bluez.git devel >> >> Comments? >> >> Regards, >> Claudio >>>>MT comments, >> >> 1. Only one LE connection is allowed(per peer), meaning only one >> GAttrib instance will be allowed otherwise it will not be possible to >> serialize commands/events >> >>>> You mean the master (or client) can only connect to 1 slave (or server) or a slave can only connect to 1 master? > [Claudio Takahasi] > The master can be connected to more than one slave. But here, I wanna > emphasize that only one instance of GAtttrib shall be created to > represent the physical channel between two LE capable devices. GAttrib > is the abstraction that we created in BlueZ to represent the GATT/ATT > connection, it is necessary to address multiple applications/profiles > and queue commands/events. > [Mike Tsai] > I see. In order to handle multiple profiles (as multiple applications running on top of the GAttrib) in a single physical link, you will need something like "application handle" to dispatch the response/identification to the appropriate application correctly. > May you refer me to the API document that you are opening to the GATT client(s) from this GAttrib? [Claudio Takahasi] Hi Mike, At the moment it is not clear to me if an "application handle" will be needed, maybe we can also hide it from the higher layers. All requests are serialized and for each request there is a response, the exceptions are write without response and notification. Each primary service representation will have an object path, meaning that maybe it is possible forward the response to the right source based on the last request and handle information. GAttrib will not be exposed to the UI. UI needs to access BlueZ GATT clients services using D-Bus. GATT clients in general will have two pieces: 1- UI: Qt, GTK, python, ... 2- "module" in the BlueZ for profile specific tasks and D-Bus service interface. You can find the current attribute API in the file: doc/attribute-api.txt Claudio [Mike Tsai] Hi Claudio, I look at the API and it is well-defined with high level of abstraction. However, I did have a few questions here, hopefully you can answer them, On Client side: 1. I see you didn't offer any service discovery API for client to discover the server service database (basically to get the attribute handles). So I assume that you consider GATT discovery procedure works the same way as SDP, done automatically by GATT after link is established without application's initiative. Am I correct? 2. The characteristic descriptor set via SetProperty API is limited to the 6 characteristic descriptors defined in GATT spec. However, there could be profile specific characteristic descriptors beyond these, will the SetProperty able to support these? 3. The characteristic monitoring is set up via 128 bits UUID. Do you have mechanism to handle duplicated characteristic within a server's database? How do you identify them via your API? On Server side: 1. Is there an API that allows server application to register new attributes? (primary service, characteristic, included service, et al), Regards, Mike > >> >> 4. GATT clients doesn't need to know ATT, in theory it can handle >> characteristics only >> >>>> You mean both characteristic value and characteristic descriptors of characteristic? > [Claudio Takahasi] > Both. For the GATT client role, an interface can be created exporting > profile specific details. > Sometimes GATT clients will also need to access some low level information. > [Mike Tsai] > Yes, I will really appreciate if you may show me the planned API for this GAttrib, > > > Regards, > Claudio >> >> Regards, >> >> Mike >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> More majordomo info at Âhttp://vger.kernel.org/majordomo-info.html >> > -- -- Claudio Takahasi Instituto Nokia de Tecnologia Recife - Pernambuco - Brasil +55 81 30879999 ÿô.nlj·Ÿ®‰†+%ŠË±é¥Šwÿº{.nlj·¥Š{±ý¶ â^n‡r¡öë¨è&£ûz¹Þúzf£¢·hšˆ§~††Ûÿÿïÿ‘ê_èæ+v‰¨þ)ßø
