SWRA513C January   2020  – September 2020 CC3120 , CC3120MOD , CC3135 , CC3135MOD , CC3220MOD , CC3220MODA , CC3220R , CC3220S , CC3220SF , CC3235MODS , CC3235MODSF , CC3235S , CC3235SF

 

  1.   Trademarks
  2. 1Introduction
    1. 1.1 Terminology
  3. 2Overview
    1. 2.1 General Description
  4. 3Provisioning Configuration Modes
    1. 3.1 AP Provisioning
    2. 3.2 SmartConfig Provisioning
    3. 3.3 AP Plus SmartConfig Provisioning
    4. 3.4 AP Plus SmartConfig Plus External Configuration Provisioning
  5. 4Initiating the Provisioning Process
    1. 4.1 Host-Initiated Provisioning
    2. 4.2 Auto-Provisioning
    3. 4.3 Ending the Provisioning Process
  6. 5Profile Confirmation
    1. 5.1 Feedback
      1. 5.1.1 Local Feedback
      2. 5.1.2 External Feedback (Cloud)
    2. 5.2 Confirmation Fail
  7. 6External Configuration
  8. 7Host APIs
    1. 7.1 Provisioning Command
    2. 7.2 Provisioning Status Event
    3. 7.3 Provisioning Profile-Added Event
    4. 7.4 Reset Request Event
    5. 7.5 Blocking APIs During Provisioning
  9. 8Provisioning Use Examples
    1. 8.1 Successful SmartConfig Provisioning
    2. 8.2 Unsuccessful SmartConfig Provisioning
    3. 8.3 Successful SmartConfig Provisioning With AP Fallback
    4. 8.4 Successful AP Provisioning
    5. 8.5 Successful AP Provisioning With Cloud Confirmation
    6. 8.6 Using External Configuration Method: WAC
    7. 8.7 Successful SmartConfig Provisioning While External Configuration Enabled
  10. 9Provisioning HTTP/HTTPS Server APIs
  11.   Revision History

8.5 Successful AP Provisioning With Cloud Confirmation

Figure 8-5 shows a sequence diagram describing a successful provisioning process using cloud confirmation AP provisioning.

GUID-7C078CF3-AFC1-4D0B-BB12-3B3761BC2F1D-low.gifFigure 8-5 Successful AP Provisioning Cloud Example
Note:

When user feedback is provided through a cloud server (external confirmation), the APIs are unblocked immediately after the CONFIRMATION_IP_ACQUIRED provisioning status event is sent to the host. At this point the host is able to send to the networking subsystem the socket commands needed to connect to the cloud server.

Because the networking subsystem is unaware of the confirmation result coming from the cloud server, the host is responsible for stopping the provisioning process (and ordering the networking subsystem to stay in its active role, STA) if the confirmation is successful. For the same reason the host must order the networking subsystem to switch back to the configuration stage (by sending the ABORT_EXTERNAL_CONFIRMATION command) if the confirmation failed.