• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 53 subscribers
  • Views 2529 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

CC2640: How to setup CC2640 to send/receive directed advertisement

CC2640: Directed advertisement with RPA addresses

kaeraz
Prodigy 140 points
Part Number: CC2640

Hello All,

I am struggling with setting up the BLE5-Stack on CC2640R2 modules, to perform following scenario (I am using simple_peripheral and simple_central examples):

Scenario is taken from BLE5 spec:

Let’s call peripheral device as PD, and central device as CD.

  • Pair of IRKs is given (one for PD and one for CD).
  • Generated IRKs are flashed into PD and CD firmware and are added to their Resolving Lists (so that each device knows its peer).
  • Both PD and CD uses Resolvable Private Address (RPA) modes.
  • PD enters Advertising state and sends Directed Advertisements (Directed, Connectable, Legacy) to the CD.
  • CD enters Scanning state and passively scans for Directed Advertisements. When one is received and its advertiser’s and target's identity is resolved, I would like to see the Advertisement Report e.g. print it.

The issue is, that I am able to receive the report on CD only when PD's advertisement payload contains "TargetA" field equal to current CD's RPA (exactly equal to). According the BLE 5 Spec:

"When an initiator receives a directed connectable advertising event that contains a resolvable private address for the target’s address (TargetA field), the Link Layer shall resolve the private address using the Local IRK values(see Section 1.3.2.3)."

When I use following code:

GapAdv_params_t advParamLegacy = GAPADV_PARAMS_DIRECT_ADV_CONN;

advParamLegacy.peerAddrType = PEER_ADDRTYPE_RANDOM_OR_RANDOM_ID;
LL_PRIV_GenerateRPA(thisIrk, generatedRpa);
memcpy(&(advParamLegacy.peerAddr[0]), &generatedRpa[0], 6);

// Create Advertisement set #1 and assign handle
status = GapAdv_create(&SimplePeripheral_advCallback, &advParamLegacy,
                               &advHandleLegacy);

to create an advertisement, the CD device cannot resolve TargetA address. Why is that?

Of course I have set the IRK on the CD device equal to "thisIrk" from the code snippet.

Can anybody help me with my isse? Maybe my conception is wrong, and it is only possible to send ADV_DIRECT_IND using TargetA equal to current CD's RPA? But why?

BR,

Krzysztof

 

  • 0
    TI__Mastermind 34660 points
    Hello. Your understanding is correct. It is difficult to comment on exactly what is wrong since there many ways that this could have gone wrong.

    Firstly, how and why are you directly loading the IRK's? Usually these are transferred during the pairing process. It is possible that you are missing steps since you are essentially bypassing the stack. In any case, how do you know that the IRK's are loaded correctly? It kind of sounds like they are not.

    Also, you should not be using LL_PRIV_GenerateRPA() as this is not exposed through ICall.

    Maybe we should take a step back here. What are you trying to accomplish at a top level?
  • 0 in reply to Tim C
    Prodigy 140 points

    Hello Tim C,

    thanks for the reply. Let me describe the idea in detail - I would like to do directed advertising to a central device which uses resolvable private address.

    • CD and PD share pre-defined IRKs (flashed into firmware).
    • The PD computes valid RPA of the CD using flashed IRK.
    • The PD sends ADV_DIRECT_IND to the CD with TargetA = computed RPA, AdvA = its own current RPA.
    • The CD receives it and:
      • stack resolves the TargetA address using its Local IRK.
      • stack resolves the AdvA address
      • receives Event from the stack that report is available
      • prints the report

    Is it possible to implement such scenario? Which function should I use to compute valid CD's RPA to set it as peerAddr in advertisement?

    How can I tell the stack to resolve the TargetA and AdvA addresses? Should I use Resolving List? How to add Local and peer IRKs at startup?

    "Firstly, how and why are you directly loading the IRK's? Usually these are transferred during the pairing process"

    Yes, I understand that IRK's are shared during pairing process. However, two things are unclear for me:

    1. How PD advertises the first time to start paring with CD? Can directed adv be used? Does it require to use Device Addresses in TargetA and AdvA fields? Is it possible to use RPA? If, so how the PB may know what the current CD's RPA is?
    2. Let's say that bond is created, peer data is stored in NV memory and connection is terminated. How the PD can now advertise to the CD? What to put in TargetA and AdvA fields in directed adv?

    Br,

    Krzyszotf

  • 0 in reply to kaeraz
    TI__Mastermind 34660 points
    1. The idea is that you would not use directed advertising the first time you connect. How would you know what address to connect to if this was an actual product? The general procedure is:
    - Scanner listens for (non-direct) advertisements and looks in advertising data for something that it wants to connect to such as a specific profile UUID or some manufacturer specific data. It will only know the devices RPA at this point.
    - Scanner than sends connection request to this device using the RPA.
    - Devices pair and exchange identity information: IRK's, identity addresses and identity address types
    - For future connections, from our stack's perspective, you should then use the identity address to identify the other device. The controller will handle translating this identity address to the appropriate RPA and use this over-the-air.
    2. So if you want to use directed advertising at this time, you should use the identity address for the target address.
  • 0 in reply to Tim C
    Prodigy 140 points

    I understand the idea, it is a typical scenario also presented in the TI examples. However is it possible to populate the Resolving List with predefined IRKs, and IDs, so that Directed Advertising is possible from the beginning (step 1 from your postnot needed)?

  • 0 in reply to kaeraz
    TI__Mastermind 34660 points
    It should be possible but will be quite difficult and not recommended as you are bypassing a significant portion of the stack. If you want to try, you should use the HCI_LE_AddDeviceToResolvingListCmd() API to add devices to the resolving list. Note that the address type should only be 0 or 1 (public or random)