Is it possible to host a passive GATT Service "i.e one that does not advertises itself" , but can entertain connections.

[german_wings]

I was having an idea about an ESP32 hosted GATT Service that did not advertise itself (I think it might save power! I have an Application Level Understanding of the BLE Protocol not in depth ! so peace) , I did observe the Bluez Stack behavior when I host a GATT Service it advertises, but once someone has connected to it, it stops advertising but maintains the connection(I know the BLE protocol only allows one device to be connected at a time except for MESH ) , My idea has stemmed from this observation , if advertising consumes power(No matter even if minimal) and in a closed loop project like mine , where I know both the Peripheral and Master device and trust them , Advertising in such an environment is purely optional and once connected advertising stops anyway , so "Can I skip advertisement on my ESP32 BLE server and let my phone directly connect to it."

I tried using neils (Mr Kolban) BLE Server example and conveniently commented out the advertising line , but I could not connect it on my phone.

Any alternative or am I missing something(Not the BLE SIG Documentation Please ) , or this is simply not possible? , or has security issues ?(There might be many ) , Or is there a better option then BLE ??

Please comment and let me know ..

[vinodstanur]

You can do something called directed advertising to a particular MAC address which I believe other devices won't see. But you cannot target an iPhone central because iPhone changes its Mac address often. It uses random Mac address. May be you can use it to target android or any other fixed MAC ble central. Apart from that you can add whitelisted MAC addresses of central devices so that others cannot connect until or unless they imitate the MAC address of the whitelisted devices or directed advertising device.

Other than that, from my knowledge, at least from ble 4.1 specs ( I am not sure about 4.2 or greater), you cannot hide a ble by stopping it's advertising packet and wait for a connection. Because the protocol itself is designed such a way that if the advertisement is a connectable type (unlike the beacon type), the advertising RF front end enters into receiving mode for a very small fraction of time after the advertising packet on air. In this period of short RX time the central device need to send CONNECT_REQ packet and if the advertising peripheral receives it properly without any synchronisation error or packet corruption, it will start the subsequent connection process with proper handshakes etc.

So this is how ble works. Now I am not sure about the latest improvements and protocols from 4.2 onwards, may be you can check those.

Apart from that, I am not sure why you are worried about power consumption of advertising, practically a ble device advertising is designed for ultra low power consumption by making the advertising interval larger with a penalty of a bit higher connection latency (say few seconds delay, 2 or 3 or 4 sec etc). By this way, the ble alone can advertise for several months or even year on a coin cell. So if power is your concern the ble won't take much power if the advertising intervals are large enough, I generally keep those to 300 to 500 Milli seconds to achieve a very low power consumption. (Haven't tried on esp32, but on other platforms like Nordic, St bluenrg, ti cc2541 etc). Higher values are also theoritcally possible but again you have to compromise on the latency to connect. Plus in real-world, RF noise can also affect the connection time apart from the advertising interval.

If you are thinking of ble advertising power, then before that you have to utilise the sleep modes in esp32 to achieve a current consumption below 500 micro amperes and then try to play with advertising intervals. Because always the esp32 cpu itself will be a bottleneck which takes Milli amperes of current if the sleep modes are not utilised properly. I haven't tried achieving such a low power mode in esp32 yet to find a considerable difference in power consumption, so the first bottle neck is the cpu power consumption and if you are able to bring it below 1mA or 500uA while ble is advertising, then start playing with advertising intervals, if not you will not find much difference in power consumption because ble is not at all a bottleneck for esp32 if power consumption is the topic.