This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

BLE Address Types


I would like some clarification of the difference between Public and static BLE addresses. I have an off-the-shelf Bluetooth Smart Watch that has a "Static" address type when scanned using BTool. Wit my products the address shows as "Public". As I understand both addresses expose the device MAC address - what is the difference between the two?


  • Hi Eng,

    Essentially, static address is a random address while public is not.

    From Core Spec:

    The public address shall be created in accordance with section 9.2 ("48-bit universal LAN MAC addresses") of the IEEE 802-2001 standard (http://standards. and using a valid Organizationally Unique Identifier (OUI) obtained from the IEEE Registration Authority (see and sections 9 and 9.1 of the IEEE 802-2001 specification). The public device address is divided into the following two fields:
    • company_assigned field is contained in the 24 least significant bits
    • company_id field is contained in the 24 most significant bits

    A static address is a 48-bit randomly generated address and shall meet the following
    • The two most significant bits of the static address shall be equal to ‘1’
    • All bits of the random part of the static address shall not be equal to ‘1’
    • All bits of the random part of the static address shall not be equal to ‘0’

    Read more about static address in section 10.8.1 in Vol 3 of the Core spec. Device Address in general at section 1.3 Vol 6.

    Best Regards

  • Sorry but the link you provided for Core spec ( is not working.

    Could you please provide the correct link.

    Tanks in advance.

  • Dear Joakim Lindh

    what's the risk when i use a static address? 

    would it cause connect or function issue on some andriod or ios system?( did it  require special central device?)


  • The TI guy has this marked as solved so he's not looking any more.  Maybe I can help.

    As I understand it:

    The link-level "Access Address" on an advertisement may be:

    • Public Address = MAC Address
    • Private Address = Randomly generated - three types, distinguished by most significant bits:
      • 11:  Static:  MAY change when chip is rebooted, otherwise unchanging.
      • 01:  Non-resolvable:  The rest is just a 46-bit random number that changes every few minutes or so.
      • 00:  Resolvable:  The rest of the most significant half is a 22-bit random number that changes every few minutes or so, the other half is a 24-bit hash of it by a 128-bit Identity Resolving Key (IRK).  The key is that peripheral's identity.
        • If the central also has the peripheral's IRK it can check the random number against the hash and verify (1-in-2^22 chance of false-positive, false-negative is impossible) that it's the peripheral with that key, and if it has a list of IRKs it can try each of them to try to identify the peripheral from its Access Address.
        • If it doesn't have the peripheral's key, it can still connect (if it passes any other handshake checks).  But once it's disconnected again and the random number changes, it loses track of the peripheral, which is now a "new peripheral" to it again.

    I think the main risks with a private static address are:

    • If you are using it to determine which tag it is from the advertisement, you'll lose it when you change the batteries or reset it.
    • If it picks the same number as another tag (very unlikely) you can't distinguish them.

    The BLE stacks on ios devices hide the Access Address from the applications, so you have to identify your tags some other way.

  • Hi, sorry to dump into an old topic but I am under the impression that Michael McClary meant device address rather than access address.
  • Hi Michael,

    I think you confused the access address vs the device address. There are two different concepts in BLE

  • Absolutely correct. The original poster, and I, were referring to the device address. I got confused and used the name of another field that happened to have "address" in it.

    Sorry about that.