BLE connectable but not scannable

The advertisement packet your beacons send can contain custom data. However the space is very limited, around 31 bytes. About 16bytes of it goes to the 128bit "service UUID" of your beacon. The structure of the packet is defined by the bluetooth spec and it does have some overhead, so I'm not sure how much is actually available for the custom data.

The service UUID is an identifier which your iphone app will search for. The idea that each service has a unique identifier, so if an app wants to find heart rate monitors, it will scan for the heart rate monitor uuid. In iOS you can even do a wildcard scan, and it will return any ble advertisements it can find, regardless of the services it has. It is however recommended by Apple guidelines that you specify the service UUID.

There is no requirement for pairing in order to receive the advertisment packets from the beacon. There is also no theoretical limit that would prevent that the beacons couldn't be found, given an infinite amount of time.

I haven't heard anyone putting 500 advertising BLE beacons in the range of an iPhone to see how many it can detect. With 500 beacons advertising simultaneously there will be a lot of collisions between packets. This could theoretically be calculated with knowing the advertisement interval.

The iPhone scan window (how long the channels are actively listened to) and scan interval (how often the scanning window is entered) cannot be adjusted, isn't documented and cannot be relied to remain the same between versions. This means that there isn't a way to really calculate how the advertisements will be found.

There's some recommendations published by Apple about advertising: https://developer.apple.com/hardwaredrivers/BluetoothDesignGuidelines.pdf

Oh, and by default iOS will filter the results so you get one notification per scan session, per beacon. You can set the "allow duplicates" option in the scan to get multiple notifications per scan session for each beacon if this is needed, but again, apple doesn't recommend it.

If you end up testing this with 500 beacons, or even > 10, I thin a lot of people would be interested in your results. I personally would also appreciate hearing about your experiences.

I know its very late to answer this, but I think I can add some more weight to the good answers here and complete them for someone else who is at a stage where you were last year, when you asked this question. I hope that it is acceptable to the community.

Lets talk about them in the real terms of a generic practical use case:

• BLE Peripheral = GATT Server = (Mostly) A Slave of the communication, e.g. Sensor
• BLE Central = GATT Client = (Mostly) The Master of the communication, e.g. a Smartphone

First: How is a connection established?

The GATT Server (Sensor/Peripheral) broadcasts advertisement packets at a defined interval. The GATT Client (Smartphone/Central) does a scan for nearby devices. Central discovers advertisement and decides to connect to Peripheral. The operating modes of antenna are never distinguished as sending and receiving. The Link Layer (L2CAP) has the ability to send advertisement packets and check for connection requests from the Central at the same time.

Second: After connection loss/disconnection, is the above procedure mandatory to reconnect again or are there other ways? What about bonding/pairing? What if I know the MAC address of the peripheral?

To reduce the connection latency, there is a really robust structure (not syntactically a struct) of Events provided. Whenever the Peripheral is disconnected from Central, the BLE stack generates an event. As a service routine to this event, if you have a handler written, you can parse the received event packet and determine the reason of disconnection, either deliberate or accidental/unexpected. Depending upon that, you can decide upon whether you want to put it back in advertising mode or not. FWIK, and for the modules I have worked on, after a disconnect it doesn't automatically goes into advertising mode. It has to be done manually.
On the Central side (considering android), there is a method: connectGatt();, It takes 3 arguments, first and third is not of out interests right now (Context and Callback), the second argument is a boolean variable (I guess, please confirm), which decides whether to attempt a reconnection or not. I believe that, deep down at grass-root level, it must have been implemented using MAC Address only, because that is what makes a device unique and hence uniquely identifiable.

Third: How could they reconnect (as fast and energy saving as possible) if the connection is lost.

Again, I would say. "it depends". It depends majorly on the event handling implementation on the Peripheral side. The connection latency shall increase with event handler execution latency. The reason I am saying this, is that while developing on BLE112/BLE113 and BL600SA (Manufacturers: Bluegiga and Laird respectively) I have keenly observed the events that are invoked after a DISCONNECT event. The DISCONNECT event is actually the last to receive. It first generates events for each of the service for which the Central had enabled Notifications/Indications. Though you don't have much a time-consuming operations for those events, that would definitely introduce some latency in execution of the actual disconnect event handler.

Fourth: Is it possible to send/receive data from outside a connection (others then advertisements)? Or is a connection mandatory to register for notifications/indications etc?

To directly answer your sub-question here, "is a connection mandatory to register for notifications/indications etc?". To receive indications and notifications you have to be connected.
Now, "Is it possible to send/receive data from outside a connection (others then advertisements)?", while we can say that it is possible to send some data into the advertisement packet, it comes with its own disadvantages. Your data is broadcasted in the open. Any Application can parse your advertisement packet and play with your data. So, to overcome that you will decide upon a custom protocol known only to firmware on Peripheral and the app on Central. That would again cost its overheads since you don't have the liberty to send chunk of data over BLE. Again, overheads for splitting data and sending it over? At the application side, parsing it using some sort of protocol that you have agreed upon. Not a good idea.

Fifth: What is the best solution to establish an encrypted communication? Usually pairing/bonding allows for encryption. But how get the passkeys exchanged.

First question, do you really need to implement it (on your own)? No you don't. BLE has a layer, Security Manager dedicated for Security and Data integrity. I hope you know that when we say that we can send maximum of 20 bytes in a packet over BLE, its not actually a packet of 20 bytes which is sent over. 20 Bytes is Payload length limit and not the actual Packet length limit. Starting from a Preamble, it has many a things that are put around your Payload. BLE implements 128-bit AES for security and encryption, without you asking for it. I think that is good enough. If you need more encryption, it can be done at customized level, again overheads?

Sixth: While receiving advertisements, How do I know if the device is interesting for me? Does I need to connect and discover services? Is there a mechanism to determine the device class or type?

The advertisement packet does it for you. On a broader picture, I can think of one reason to make advertisement packets so informative by means of GAP, is as following. In the GAP service, you have something called Appearance which decides what that device is. If I am an application developer and I am interested in getting connected over a specific kind of a device like say, Generic Clock, I can do that using this Appearance value (256 for Generic Clock) set.