Provisioning Link Establishment

[smart_life]

Hey everyone, 

1) can you explain me please what is going on by the Link Establishment Process by the Provisioning: do we set up a connection like by the TCP and after the Link is Opened we will get an acknowledgement  for every provisioning message ?  (why do wee need the link establishment process in this point ?)

2) where can i find code for he private key derivation from the exchanged public keys on both sides  ?

[awneil]

Are you talking about Bluetooth Mesh?

Are you asking in general, or specifically about one of the Nordic Mesh SDK demos?

The Nordic Mesh SDK includes all the source code.

[smart_life]

I'm asking in general about Bluetooth Mesh which is specified in v1.0 but if there are some differences between the specification and  nordic implementation than please tell me additional about the differences also 

[awneil]

smart_life said:

I'm asking in general about Bluetooth Mesh

Remember that we can't read your mind - so you need to say that in your post!

The Bluetooth Specification defines what happens within the mesh - where BLE is used as the transport.

See the Bluetooth SIG pages for details.

See the links here for starters: https://devzone.nordicsemi.com/f/nordic-q-a/39892/ble-mesh-1-0-cellphone/154813#154813

How details about the provisioning process get communicated to things outside the Mesh is beyond the scope of the specification - so implementations will vary as required for the specific application.

eg, the Nordic light switch demo uses the Dev Kit buttons, and log messages for status output...

[smart_life]

Im not talking about the whole Provisioning Process , I just what to know the reason for the Link Establishment in the Specification v1.0 in (5.3.2) .  In Nordic Mesh provisioning Introduction it seems that you also use the Link Establishment Mechanism as the Bluetooth SIG specified it: see picture below (in the begin in blue you have Link establishment  Messages) . It is also necessary and you implement it but i don't understand the reason. Do we have a connection after link establishment messages between the provisioner and provisionee with handshake and necessary message acknowledgement or it is done for some other reasons?

[Bjørn Kvaale]

Yes, if you compare the diagram you uploaded with the diagram in Figure 5.10 in the Mesh Spec, you notice they are almost identical:

We are required to follow the spec so that our mesh stack is Bluetooth SIG certified. The SIG writes the spec & the developers follow the spec, but can decide how to best implement the spec in code.

smart_life said:

Do we have a connection after link establishment messages between the provisioner and provisionee with handshake and necessary message acknowledgement or it is done for some other reasons?

Like the spec says, the link is established to provision the unprovisioned device. If this answer is not satisfactory, I am afraid I do not fully understand the question. The link is first established between the provisioner & unprovisioned device, then the provisioning process occurs & finally the link closes.

[Bjørn Kvaale]

Regarding Q2 in your original question, see the mesh_provisionee.c file of the light switch server in mesh sdk v2.2.0:

        case NRF_MESH_PROV_EVT_STATIC_REQUEST:
            APP_ERROR_CHECK(nrf_mesh_prov_auth_data_provide(&m_prov_ctx,
                                                                 m_params.p_static_data,
                                                                 NRF_MESH_KEY_SIZE));

In the provisioner example, you can take a look at prov_provisioner.c:

        case NRF_MESH_PROV_OOB_METHOD_STATIC:
            /* Request static provisioning data from the application. */
            event.type = NRF_MESH_PROV_EVT_STATIC_REQUEST;
            event.params.static_request.p_context =  p_ctx;
            p_ctx->state = NRF_MESH_PROV_STATE_WAIT_OOB_STATIC;
            p_ctx->event_handler(&event);

& also provisioner_helper.c:

   case NRF_MESH_PROV_EVT_STATIC_REQUEST:
        {
            const uint8_t static_data[NRF_MESH_KEY_SIZE] = STATIC_AUTH_DATA;
            ERROR_CHECK(nrf_mesh_prov_auth_data_provide(p_evt->params.static_request.p_context, static_data, NRF_MESH_KEY_SIZE));
            __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "Static authentication data provided\n");
            break;

[smart_life]

Thank you for the answer,  it is not satisfactory but i think i got it now.  I thought the link establishment message is an indicator for the Provisionee that after that link open message and till the link is closed ,each message has to be acknowledged on some provisioning protocol layer. In other words i thought link establishment == connection  , like the TCP connection. TCP provides reliable, ordered, and error-checked delivery of a stream of octets.  But it seams that we need the link establishment just to distinguish between sessions and we need it to say how long the session will be. We still have an unreliable delivery without of packet order and error checked delivery. But in case of PB-GATT we have a real connection right ? 

 In Mesh Specification in 5.3.2 we have the definition of the  link establishment procedure:

The Link Establishment procedure is used to establish a session for a bearer that does not have inherent
session management. A session is identified by using a Link ID that is static for the duration of the
session and shall be randomly generated to prevent collisions between sessions.

The Link Open message contains the Device UUID of the device. On PB-ADV, the PB-ADV PDU format includes a Link ID field.

[Bjørn Kvaale]

smart_life said:

But in case of PB-GATT we have a real connection right ? 

 In PB-GATT you have a standard BLE connection. See the documentation: "After provisioning, the proxy server application starts advertising a connectable proxy beacon, which can be connected to by a Proxy Client to interact with the mesh. The Proxy Client acts like any other mesh device, but sends all its mesh communication over a BLE connection to a Proxy Server, which relays it into the mesh."

If that is what you mean by "real connection", then yes, you are correct.