Master and Slave Roles#

Introduction#

Bluetooth Low Energy is a powerful and complex technology. It is not like classic Bluetooth with a predefined set of official profiles to choose from. Although there are predefined (a.k.a. "adopted") profiles specified by the Bluetooth SIG, these are just the tip of the iceberg, a small subset of the functionality you can achieve with BLE.

In many (or even most) cases, the best option is to create a custom profile(s) for your application because it provides ultimate flexibility and doesn't cost anything. In fact, it can be even easier than using one of the adopted profiles because you get to define how everything works rather than conforming your application into something that is already defined. Also, because there is no official generic "serial port profile" in the BLE world like SPP in classic Bluetooth, sometimes a custom implementation is the only option to do what you need.

To have an effective custom implementation, it is important to understand how a BLE connection works, what roles are played by the devices involved, and how data is transferred from one device to the other over the air. Many terms are used, they are usually not interchangeable, and mean different things: master, slave, central, peripheral, client, server, advertise, scan, read, write, notify, and indicate. Understanding the terminology will make it easier to describe and build your BLE application.

Quick Overview#

This document covers the following:

  • Master (or "central") devices scan for other devices, and initiate connection. Usually, the master is the smartphone/tablet/PC.

  • Slave (or "peripheral") devices advertise and wait for connections. Usually, the slave is the BGMxxx module of EFR32 device.

To learn about server and client roles, see GATT Server and Client Roles

Master vs. Slave - Connection Roles#

An important concept in BLE connectivity is the difference between a master device and a slave device. First, the terms are not interchangeable with client/server, which are explained in GATT Server and Client Roles. In the BLE world, the master/slave difference is very easy to define and recognize:

  • Master / Central - the BLE device which initiates an outgoing connection request to an advertising peripheral device

  • Slave / Peripheral - the BLE device which accepts an incoming connection request after advertising

These terms are the only ones in the list above which are actually interchangeable. References to a "master" or "central" device are describing the same thing, and references to a "slave" or "peripheral" device are also each describing the same thing. In the CoreBluetooth APIs provided by Apple for iOS development, the "Central" and "Peripheral" nomenclature is used; you will not generally see references to master or slave devices in this context.

The BLE specification does not limit the number of slaves a master may connect to, but there is always a practical limitation, especially on small embedded modules. Our 2.8.1 BLE stack can support up to 8 simultaneous connections device, when properly configured (the default is 4). Our stack supports dual-topology and multi-master connections (which are part of the Bluetooth 4.1 spec) which means that a device can be simultaneously a master and a slave and it can also connect to multiple masters a slave device. The connection limit applies to the total number of connections regardless of the role.

The connection role, whether a device is a master or slave, is defined the moment the connection is made. Our stack is capable of acting either as a master or as a slave device. If a device is operating as a slave, it needs to advertise (accomplished in our BLE stack with the gecko_cmd_le_gap_start_advertising command); if it is operating as a master, it will optionally scan for devices (accomplished in our stack with gecko_cmd_le_gap_start_discovery) and initiate a connection request to another device (accomplished in our stack with gecko_cmd_le_gap_connect).