This paper is the best publicly available definition I've seen of the security of a Bluetooth connection, although this now-withdrawn NIST paper is instructive as well.
According to that document, HMAC is not used at all in Bluetooth Low Energy; instead, AES-CMAC is used for key derivation and AES-CCM is used for encryption. (HMAC is used in regular Bluetooth.) That's likely because Bluetooth Low Energy devices are often highly constrained and implementing just AES plus variants on it requires fewer resources than implementing AES and HMAC.
Note that AES-CMAC is a message authentication code, just like HMAC, so it can be used to ensure the integrity of a message or as a PRF to derive keys, like it's used in Bluetooth Low Energy.
To actually prevent tampering with the message, AES-CCM is used. CCM, which is Counter Mode with CBC-MAC, is what we call an AEAD: an authenticated encryption with additional data mode. This type of mode encrypts and authenticates data at the same time, avoiding the need for a separate MAC.
In general, in order to prevent tampering, either an AEAD or an unauthenticated cipher mode with an additional MAC is needed. AEADs are very popular these days because they tend to be simple, secure, fast, and somewhat harder to misuse than a separate MAC. However, provided the construction is secure, either one is fine.
This type of encryption is actually what "securing the link" means. We don't have a physical electrical layer to secure, so since we're sending wireless data, using a secure key exchange method, which we then use to derive keys for a secure encryption and authentication scheme, is the only possible method of securing the link.
Note that this assumes the use of the Secure Connections mode. Bluetooth also supports several legacy methods which are substantially less secure.