- Peripheral devices are small, low power, resource contrained devices that can connect to a much more powerful central device. Peripheral devices are things like a heart rate monitor, a BLE enabled proximity tag, etc.
- Central devices are usually the mobile phone or tablet that you connect to with far more processing power and memory.
Both payloads are identical and can contain up to 31 bytes of data, but only the advertising data payload is mandatory, since this is the payload that will be constantly transmitted out from the device to let central devices in range know that it exists. The scan response payload is an optional secondary payload that central devices can request, and allows device designers to fit a bit more information in the advertising payload such a strings for a device name, etc.
A peripheral will set a specific advertising interval, and every time this interval passes, it will retransmit it's main advertising packet. A longer delays saves power but feels less responsive if the device only advertises itself once every 2 seconds instead of every 20ms.
If a listening device is interested in the scan response payload (and it is available on the peripheral) it can optionally request the scan response payload, and the peripheral will respond with the additional data.
The main use case here is where you want a peripheral to send data to more than one device at a time. This is only possible using the advertising packet since data sent and received in connected mode can only be seen by those two connected devices.
By including a small amount of custom data in the 31 byte advertising or scan response payloads, you can use a low cost Bluetooth Low Energy peripheral to sent data one-way to any devices in listening range, as shown in the illustration below. This is known as Broadcasting in Bluetooth Low Energy.
This is the approach use by Apple's iBeacon, for example, which inserts a custom payload in the main advertising packet, using the Manufacturer Specific Data field.