Hello Chris. Yes, this scenario is possible in theory, as per the Bluetooth specification. You just have to believe me :) I can't prove it right now with iOS device and some peripheral. But I hope I'll get a chance to try it in the nearest future. This should work exactly as Andras described: " 1. the phone scans and finds the watch 2. the phone connects to the watch 3. the watch, using the connection built up by the phone, starts discovering the services of the phone and attaches notification handlers to the ANCS characteristics" and so on... Phone is Central, watch is Peripheral. But any side can start acting as GATT client and use this connection to send GATT requests. If other side supports GATT server role and has some GATT services registered, it will reply with corresponding info. Also see my earlier reply today. CBPeripheralManager in this case must be used just as Andras said: "CBPeripheralManager could be used to extend the list of services. It is not used for advertisement, only the services are added and implemented". So here CBPeripheralManager is not used for Peripheral functionality, it's used for GATT server functionality. And Chris, I want to correct you a little. Below you say: "Then the intention is for the external device to immediately initiate a connection back to the iOS device, connecting to some service published by the iOS device." There will be no "connection back" in fact. Bluetooth connection (or say link) is already set up with iOS device being a Central (Master) and external device being a Peripheral(Slave). This connection persists. External device can take a role of GATT client and start using this connection to send GATT (strictly saying, ATT - see my earlier reply) PDUs. There's no even such notion as "connect to some service" in GATT. You just discover services, discover characteristics, read characteristics values, discover characteristic descriptors, write descriptors values to configure notifications and etc. Regards, Sergey. ________________________________________ От: Chris Miles <miles.chris@gmail.com> Отправлено: 13 ноября 2013 г. 3:58 Кому: Andras Kovi Копия: Chris Miles; Mozhaev Sergey-BDP687; Bluetooth-dev@lists.apple.com Тема: Re: BLE central device as GATT server I see what you mean. However, I don't believe the Bluetooth LE protocol works like that. If I understand the spec correctly, the peripheral, as the server role, cannot initiate read/write requests. The central (client) role cannot send notify events. I don't believe they can switch roles without a new connection. Does that sound right? I guess the first question is, is this scenario possible with Bluetooth LE in theory (iOS aside)? Cheers, Chris On 13 Nov 2013, at 10:42 am, Andras Kovi <allprog@gmail.com> wrote:
To be more precise:
Say we have an iPhone and a Smart Watch, and say that the Smart Watch cannot scan or start connections but only receive them and advertise itself.
1. the phone scans and finds the watch 2. the phone connects to the watch 3. the watch, using the connection built up by the phone, starts discovering the services of the phone and attaches notification handlers to the ANCS characteristics
From here on, the watch is able to receive the updates from the phone, even though it did not explicitly start a connection to the phone. Of course, if the connection breaks, the phone has to connect again.
To give a little more twist to the story, CBPeripheralManager could be used to extend the list of services. It is not used for advertisement, only the services are added and implemented. The question is whether this will be visible for a connected peer that was connected from the phone’s side.
Interesting, isn’t it?
Cheers, Andras
On 2013.11.13., at 0:28, Chris Miles <miles.chris@gmail.com> wrote:
So you suggesting a scenario where the iOS device discovers and connects to an external device for the purposes of informing the external device that the iOS device is nearby. Then the intention is for the external device to immediately initiate a connection back to the iOS device, connecting to some service published by the iOS device.
I believe that kind of scenario is possible, it is similar to the test scenarios I had described. When the iOS app successfully connects to the external device, it can publish its service and wait for the external device to connect back to it.
Perhaps there is a bit more to it, though. Can you describe a real world use case, that may better explain the complexities to solve?
Cheers, Chris
On 13 Nov 2013, at 10:16 am, Andras Kovi <allprog@gmail.com> wrote:
I guess what Sergey is proposing is a little more convoluted and impossible to simulate with solely iOS devices. So as I see the scenario in question is the following:
1. the iOS device connects to an external peripheral (key fob, BLE112 module, anything) 2. the peripheral stats acting as GATT client and starts discovering the iOS device’s (now acting as GATT server) services (battery, time, ANCS) 3. use CBPeripheralManager to extend the services provided in GATT server mode
2 and 3 need to be confirmed or confuted. Unfortunately, this is impossible to carry out with iOS devices as the Core Bluetooth API does not allow it but other BLE modules should be able to try as long as their stack supports.
So far I’ve been thinking of peripherals as receivers and centrals as initiators, I have never thought the roles could change once the connection is established. Brilliant!
Sergey, you’ve got my respect for coming up with this scheme! I’m looking forward to hearing from someone implementing it as I may not have enough time in the near future to do it.
Regards, Andras
On 2013.11.12., at 23:50, Chris Miles <miles.chris@gmail.com> wrote:
Yes, case 2 as you describe it is certainly possible. iOS can act in both Central and Peripheral roles simultaneously.
In fact, an application can be both Central and Peripheral simultaneously. I have tested an iOS application that acts effectively as a BLE proxy. It connects to a peripheral (heart rate monitor in my test case) and reads values continuously (via notifications) while also publishing the HRM values as a service of its own. Another device could connect to the iOS device and read the proxied HRM values (via notifications).
I have also tested another iOS application which acted as both Central and Peripheral. Two iOS devices could connect to each other, both servicing the other, responding to read/write requests simultaneously.
I hope that helps.
Cheers, Chris Miles
On 13 Nov 2013, at 7:59 am, Mozhaev Sergey-BDP687 <BDP687@motorolasolutions.com> wrote:
Hi all.
Let me share my thoughts on this question. I'm not an iOS developer, mostly I'm embedded software engineer, and what I'm saying here about iOS is just my understanding based on knowledge of Bluetooth spec, not on iOS experience.
Stephan, you are asking: "I would like to know if it's possible in iOS to implement a GATT server when acting as a central". In my opinion, you don't have to do anything to implement GATT server, it's already implemented in iOS internals. And it already has Battery, Time and ANCS services available to any GATT client that wants to use them. You can use CBPeripheralManager to add/remove your own proprietary services if you wish. But another question if how to make these services available? Two cases are possible here: 1) When iOS device is not yet connected to any Bluetooth LE device and wants to make its services available. Then you have to use CBPeripheralManager to start advertising. Then, some remote device can establish connection to iOS. So, iOS becomes Peripheral and GATT Server. 2) iOS device is already connected to an accessory, and iOS is Central in this connection. iOS is GATT Client and accessory is GATT Server. Nothing prevents accessory from taking the role of GATT Client and starting service discovery to find GATT services available on iOS. If iOS supports GATT Server (and it really does, according to documentation), it will respond with a list of supported services. Then, accessory can start using these services.
I think case 2) is more suitable to what you're trying to achieve. Actually, when you say " from the nRF8001, I was able to connect to the Time Service published by iOS", I guess you have set Bluetooth LE link from iOS side (iOS being Central and nRF8001 - Peripheral) and then you established GATT connection from nRF8001 side. BTW, could you share more information about these steps and how it worked? and correct me if I am wrong in my assumptions.
My understanding of Central and Peripheral roles and GATT Client and Server is the following: Cenral and Peripheral only pertain to the stage of connection establishment. Central initiates the establishment of a physical connection and becomes Master. Peripheral accepts connection requests and becomes Slave. Once this physical connection is established, both devices can be GATT Client and/or GATT Server. Though it is more natural for Peripherals to be Servers. May be names of classes in Core Bluetooth are a bit misleading. Because actually CBCentralManager (and its associated delegate) also implements GATT client functionality and CBPeripheralManager (and peripheral delegate) also implements GATT server functionality. But, if you already has physical link in Central role, you can deploy CBPeripheralManager for only GATT server functionality without using any Peripheral role-specific things (like advertising). And vice versa, in Peripheral role you can use CBCentralManager to perform GATT service discovery and etc. Though, when you're Peripheral in a connection (i.e. you're Slave), you can't connect to any other device, you can only communicate with device you're already connected to. For more details, see Bluetooth Core Spec 4.0, Volume 6, Part B, chapter 1.1 - Link Layer States.
Hope it wasn't very boring and makes sense.
P.S. I would very much appreciate if someone could try case 2) and check that it really works as I said.
Best regards, Sergey Mozhaev, Senior Software Engineer, Motorola Solutions Inc.
_______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists.... This email sent to site_archiver@lists.apple.com