Electronic – Bluetooth Low Energy general questions

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.