Two links on the same Nordic chip

[Samuel.P]

Hello,

I would like to set up in the same chip (nRF51) :

• one open connection for an access control application – unlimited smartphones (no bond) and fast connection - Datas are encrypted by another system.
• one secure connection for a configuration application.

I think, according to the documentation, that the BLE link isn’t flexible. If I configure the pairing in the software, it’s impossible to connect without bond (with other service or characteristic).

For moment, I configure the chip in open connection. After connection the mobile application (configuration application) ask to change the connection. The Nordic chip reset and configure the secure connection. So, the application can to connect in secure connection and send his parameters.

Have you got another solution for this configuration more official and cleaner?

Configuration:

• nRF51822
• SoftDevices S130
• SDK 12.2.0 F012EFA
• uVision - GCC

Thank you

[Hung Bui]

Hi Samuel, 

I don't see a reason why you need two connections here. 

You can simply define different permission requirements for different attributes (characteristic). For example use BLE_GAP_CONN_SEC_MODE_SET_OPEN() for those access control characteristics and use BLE_GAP_CONN_SEC_MODE_SET_ENC_NO_MITM() for those configuration characteristics.

When a phone only needs to do access control it won't need to pair to the device. When it need to access the configuration, it will be asked to pair. 

[Samuel.P]

Thanks for your reply.
I have already try this solution, but I had a problem.
When the software receives the event BLE_GAP_EVT_SEC_PARAMS_REQUEST. How differentiate the connection mode (how I know the characteristic and respond with the good parameter : “Pairing supported” or “Pairing not supported”).
Have you got an exemple with one characteristic OPEN and one characteristic ENC_NO_MITM in same service?
Thank you

[Hung Bui]

What do you mean by "how I know the characteristic" ? BLE_GAP_EVT_SEC_PARAMS_REQUEST is received when the peer device request to pair. In a normal usage if the peer only access the open characteristics it wouldn't need to send the pair request. 

I'm not sure I understand your use case, please give more information on how exactly you want to it to be, and what is the issue you currently have with difference permission level for difference characteristic. 

[Samuel.P]

I retried the solution with different permissions. Thank you to had refocuse me on this solution, you have understanding my problem. Forgot my last message, I had other problems in the software … Now the software works with two different permission :

• The access control application with open link.
• The configuration application with encrypt link.

I have a last problem :

When the configuration application is used before the access control application, the link between access control application and Nordic chip is encrypted but works.

I feel that the configuration application stores a bond (pairing) and after the access control application use the bond. Is it logical? If no, what is the problem? Is it the access control application or the software in the Nordic chip?

Thank you

[Hung Bui]

Hi Samuel, 

Glad to hear that it works now. Regarding your question, it's a little bit different from what you are thinking of. The GATT characteristic/service wouldn't have anything to do with the pairing and bonding which is on GAP. The characteristics just got the property (permission) saying that the link must be encrypted before it can be access. 

In your case the configuration characteristic requires encryption, and the link will be encrypted after the phone trying to read/write that characteristic. The link won't be downgrade to open connection when you then access the access control characteristic. The access control characteristic wouldn't care if the link is open or encrypted, its permission requirement is lower so it just accept the access. 

The configuration characteristic wouldn't store the bond information, it's the GAP layer (then the application) that deal with that information and re-pairing. 

[Samuel.P]

Thank you for this extra informations.
If I understood your explains, I conclude that my configuration is good.
Thank for your disponibility.