SAFETY DURING DEVICE ONBOARDING

Abstract

In one aspect, a system and procedure for emulating network device onboarding can be provided. During operation, a computer can receive a list of network devices from a device activation platform to be onboarded via a device management platform procedure. For each network device on the list, the system can collect hardware and firmware information associated with that device and, using this information, emulate the onboarding process, which involves exchanging one or more handshake messages with the device activation platform.In response to the failure to receive a confirmation message from the device management platform indicating that the emulated onboarding process was successful, the system can perform a diagnostic operation to identify one or more potential problems associated with the onboarding process of the respective network device and display the result of the diagnostic operation on a user interface.

Description

BACKGROUNDField FieldThis disclosure relates generally to a method and system for onboarding a network device. More specifically, this disclosure relates to monitoring and debugging the onboarding process.BRIEF DESCRIPTION OF THE NUMBERSFIG. 1 shows an example of a scenario for embedding devices according to an aspect of the present application. FIG. 2A illustrates an example block diagram of a device activation platform, in accordance with an aspect of the present application. FIG. 2B shows an example block diagram of an emulation system for embedding devices according to an aspect of the present application. FIG. 3 shows an example graphical user interface (GUI) according to an aspect of the present application. FIG. 4A is a flow diagram illustrating an example of an onboarding emulation process according to an aspect of the present application. FIG. 4B is a flow diagram illustrating example onboarding emulation operations performed by a computing device according to an aspect of the present application. FIG. 5 illustrates an example computer system that facilitates emulation of boarding a device according to an aspect of the present application.In the figures, like numerals refer to the same elements of the figure.DETAILED DESCRIPTIONThe rapid development of cloud computing technology has altered the manner in which people store, retrieve, and process data and applications. Rather than rely solely on local servers or personal computing devices, cloud computing utilizes the performance of remote servers and networks to provide a wide range of services over the Internet. In addition to providing storage space, computing power, and software, cloud computing may also provide Network as a Service (NaaS) that allows companies to access and configure network resources as needed without having to own, wait, or invest physical network hardware and devices.As part of the NaaS solution, the device providers may also provide a cloud-based management platform to the enterprise users, such that each enterprise user may manage a large number (e.g., hundreds or even thousands) of network devices via the cloud-based management platform. For example, a provider of WLAN devices (e.g., access points or switches) may provide a centralized network management platform to allow enterprise users to view and control their network.A corporate user using the network management platform to manage network devices (e.g., access points or switches) should first operate these network devices, which may include initially configuring and providing the network devices to securely interact with the network management platform. The onboarding of the network devices can ensure that they have the corresponding permissions and the corresponding firmware to interact with the network management platform.In order to improve user-friendliness (e.g., to reduce the time required to start up network devices), it is desirable to implement zero touch provisioning (ZTP), which can automatically provide a large number of network devices. The ZTP process may be managed by a device activation platform, which may receive a configuration request from the network device and then send a corresponding configuration file to the network device. In addition to providing ZTP, the activation platform may also be responsible for installing the network device with the correct and current firmware. For example, when onboarding a network device, the device activation platform may first perform a ZTP process to provide the network device and then check whether the firmware currently running on the network device is compatible with the management platform. If so, the activation platform may complete the onboarding process to allow the device to communicate with the management platform. If incompatible firmware runs on the network device or the device certificate has expired, the network device cannot establish a connection to the management platform. In such a situation, the activation platform may enable automatic firmware upgrades to the network device (e.g., by pushing the firmware onto the network device or sending a link to download the firmware to the network device). After updating the firmware, the network device may initiate communication with the management platform and the onboarding process is successfully completed. Successful onboarding often results in the management platform sending an acknowledgement message (e.g., a "Willing" message) to the network device. It is noted that a network device does not become visible in the management platform until it has completed the onboarding process.The process of device binding can be transparent to the users. From a user's point of view, a network device may be connected to the management platform once it is powered on and connected to the network. However, the onboarding of a network device is not always successful. Many factors may cause a device to fail to onboard. For example, problems associated with the user's local area network may prevent proper communication between the device and the activation platform, resulting in failed or interrupted ZTP operation. The ZTP service or firmware update service may fail and may not properly provide the device or update its firmware. In another example, the firmware needs to be updated, but the corresponding device image is missing or not linked in the firmware upgrade service. Domain Name System (DNS) errors may also prevent the network device from retrieving the proper Uniform Resource Locator (URL) of the activation or management platform. It is also possible that the network device itself has a problem. If a network device cannot incorporate the management platform, it may be very difficult to determine the exact cause of the fault. A common approach to debugging a failed device onboarding process is to organize a debugging meeting in which both the customer and multiple technical teams of the NaaS provider participate, e.g., a team that debugs the device, a team that debugs the activation platform, and a team that debugs the cloud-based management platform. The customer's involvement is required to allow direct access to the network device. Such a recovery process is extremely cumbersome, especially for customers.In order to reduce the cost for the customers, the solution proposed here for the device binding can automatically limit the possible cause(s) of the fault if the device binding fails. More specifically, a device binding emulation system may be implemented to automatically detect and report potential onboarding issues associated with network devices without the customer being affected thereby.FIG. 1 shows an example of a device onboarding scenario according to an aspect of the present application. In the example shown in FIG. 1, a number of network devices (including switches 102 and 104 and AP 106) are to be embedded in a device management platform 108 by a device activation platform 110. In particular, the network devices may be connected to the device management platform 108 and the device activation platform 110 via a local network 112 and the Internet 114. The local area network 112 may generally comprise any type of wired or wireless communication channel capable of interconnecting computing nodes. In an example, the local area network 112 may include the customer's intranet.The device activation platform 110 may include a ZTP service 116 and a firmware service 118. The ZTP service 116 may be responsible for providing the network devices, e.g., sending the device management software and the URL of the device management platform 108 to the network devices. The firmware service 118 may be responsible for ensuring that the firmware on each network device is correct and compatible with the device management platform 108. In one aspect, the firmware service 118 may check the version of the firmware currently running on the network device. If the firmware is not compatible or the device certificate has expired due to legacy firmware, the firmware service 118 may facilitate downloading the current firmware to the network device.FIG. 1 also shows a series of potential fault points that may result in a fault when the device is powered on (denoted by an "X"). In the example of onboarding switch 102, one potential fault point may be a device fault at switch 102 (e.g., a hardware fault), and another fault point may be a network fault. It should be noted that the network fault may occur in local area network 112, Internet 114, or both. Possible network failures may be gateway failures, address resolution protocol (ARP) failures, or DNS failures. Failures can also occur with the ZTP service 116 or the firmware service 118, e.g., service or server failures. For example, hardware or software errors may occur in the ZTP or firmware server. Hardware or software errors can also occur in the device management platform 108, which can lead to a failure of the switch 102 when it is switched on.As seen in FIG. 1, the network device onboarding fault may be caused by any one or any combination of the potential fault points dispersed throughout the network, from the customer site to the public cloud hosting the device management platform 108 and the device activation platform 110. Debugging a failed onboarding process would involve identifying one or more fault points among all possible fault points, which may be a challenge, particularly given that a customer may have many network devices with different hardware configurations and / or firmware versions / buildings. In accordance with some aspects of the present application, a customer device inclusion emulation system 120 may be deployed to assist the customer in identifying and eliminating potential network device inclusion issues. In one aspect, emulation system 120 may be part of a side car monitoring system that includes a series of network sensors connected to local area network 112. In an alternative aspect, emulation system 120 may include an independent application running on a computer connected to local area network 112. Because the network sensors or computing device on which the application is running are connected to the local area network 112 and the Internet 114, the device onboarding emulation system 120 can detect all potential issues associated with the local area network 112 and the Internet 114.In accordance with some aspects of the present application, prior to attempting a customer to include a network device, the device onboarding emulation system 120 may emulate the network device onboarding process based on various device parameters, e.g., the device type and model, the media access control (MAC) address, the serial number, the firmware version / build, etc. In response to detecting an error in the emulated onboarding process, the emulation system 120 may perform a series of debug operations to identify possible causes for the onboarding error. The device onboarding emulation system 120 may also display the results of the device onboarding emulation for a number of network devices on a user interface.To emulate the onboarding of a network device, the system 120 that emulates the onboarding of a device may interact with the device activation platform 110 as if it is a network device to be onboarded. Each system may include different entities for performing different functions associated with device onboarding, and the different entities may interact with each other to achieve successful device onboarding.In the example shown in FIG. 1, the device management platform 108 and the device activation platform 110 are shown as separate entities and may run on different computer server systems. In practice, the device management platform 108 and the device activation platform 110 may run on a single server or reside in the cloud. It is also possible that the device management platform 108 and the device activation platform 110 are integrated into a single system that supports the activation and management of network devices.FIG. 2A illustrates an example block diagram of a device activation platform, in accordance with an aspect of the present application. The device activation platform 200 may include a front end unit 202, a firmware database 204, a firmware management unit 206, a device inventory database 208, and a ZTP unit 210.Front end unit 202 may provide a user interface through which customers may access device activation platform 200. For example, a customer may log into a user account to verify the activation status of network devices. In alternative aspects, the user interface provided by the front end unit 202 may be accessible only to administrators of the device activation platform 200.The firmware database 204 may store firmware applicable to different devices and versions. In one aspect, the firmware database 204 may store the firmware for each type / model of network device. The stored firmware may include all versions compatible with the device management platform or software systems, including the most up-to-date version. The firmware management unit 206 may be responsible for checking whether the firmware installed on a network device corresponds to the device type / model, is current, or is compatible with the device management platform. When the firmware on the network device needs to be updated, the firmware management unit 206 may retrieve the correct version of the firmware from the firmware database 204 and send the obtained firmware to the network device.The device inventory database 208 may maintain an inventory list for each customer. More specifically, each customer may be associated with a unique customer identifier assigned by the manufacturer, and the device activation platform 200 may use such a unique identifier to identify each customer. When a customer places an order for network devices, detailed information for each ordered device may be added to the device inventory database 208. The device information may include, but is not limited to, the device type (e.g., AP, gateway, switch, router, etc.), the device model, the serial number of the device, the MAC address of the device, the name and version number of the installed firmware, the device activation status, etc. In accordance with some aspects of the present application, a separate system that manages the device ordering process may send the device information to the device inventory database 208 via a Representational State Transfer (REST) application programming interface. Note that the initial activation status of an entry for a purchased network device is set to "not yet activated". After successful activation or onboarding, the activation status can be updated to "activated". If an error occurs in the onboarding process, the activation status may be updated to "onboarding errors found.".The ZTP unit 210 may be responsible for performing the standard operations for embedding devices. For example, the ZTP unit 210 may receive from a network device a request to include the network device in the device management platform. In response to the request, the ZTP unit 210 may exchange a series of handshake messages with the network device to authenticate the network device and send the appropriate instructions to the network device to allow the network device to connect to the management platform. For example, the ZTP unit 210 may notify the network device of the management platform's URL.FIG. 2B shows an example block diagram of an emulation system 220 for device connectivity according to an aspect of the present application. The device onboarding emulation system 220 may include a front end unit 222, a device orchestration manager 224, an onboarding initiation unit 226, an onboarding problem analysis unit 228, and a packet detection unit 230. The device onboarding emulation system 220 may be installed and launched by the customer on a computing device connected to the customer's local area network before the customer attempts to onboard network devices connected to the same local area network.The front end unit 222 may provide a user interface through which customers may access the device application emulation system 220. It should be noted that a customer's account within the device login emulation system 220 may be associated with the unique customer identifier assigned by the provider. For example, each customer may use the unique customer identifier to establish a user account in emulation system 220 for the device application. In some aspects, the user interface may be a graphical user interface (GUI) that may facilitate the client in selecting devices for emulation. The GUI may also be used to display the result of the onboarding emulation to the customer.The device orchestration manager 224 may be responsible for creating a device orchestration list. In some aspects, once a customer logs into the customer account, the device orchestration manager 224 may be caused to send a device request message to the device activation platform 200. In some aspects, the device request message may include identification information (e.g., user ID and password) associated with the customer to enable the device inventory database 208 within the device activation platform 200 to look up an inventory list corresponding to the customer. The inventory list may contain records about all network devices that the customer ever ordered. Each device dataset may include device information (e.g., device type, model, MAC address, serial number, firmware version, etc.) as well as the activation status of the device. In response to the device request message, the device activation platform 200 may send the customer's inventory list to the device orchestration manager 224. The device orchestration manager 224 may then compile a device orchestration list based on the received device inventory list. The device orchestration list may include devices that are not yet included (or invisible) in the management system. In one example, the device inventory list of a particular customer 50 may include wireless access points (APs) of different models. Of the 50 APs, 30 APs have already been activated and are visible to the management platform, while the other 20 APs are to be included in the management platform. Accordingly, the device orchestration manager 224 may create a device orchestration list that includes the 20 APs to bind. Each entry in the device orchestration list may contain detailed information about the device, such as device type, model, MAC address, serial number, firmware version, etc.The unit 226 initiating the onboarding may be responsible for initiating processes for onboarding devices using the parameters of the network devices in the device orchestration list. More specifically, the onboarding initiating unit 226 may exchange a sequence of handshake messages with the activation platform for each device. In some aspects, in response to receiving a user command, the onboarding initiating unit 226 may emulate the onboarding process for a network device by sending an onboarding request message to the ZTP unit within the activation platform. The onboarding request message may be generated based on the device parameters associated with the emulated device (i.e., a device on the device orchestration list). The onboarding initiating unit 226 may send the onboarding request message to the activation platform via a network interface of the computing device hosting the emulation system 220 for the device onboarding.From the perspective of the ZTP entity receiving the onboarding request, the onboarding process is initiated by a network device that is almost identical to the emulated device because both devices are connected to the same local network and have the same device parameters (e.g., device type, model, MAC address, serial number, firmware version, etc.). Thus, if the onboarding process initiated by the onboarding initiation unit 226 is successful, the actual onboarding of the emulated device will also be successful. On the other hand, if the onboarding process initiated by the onboarding initiation unit 226 encounters a problem (e.g., a problem with network connectivity or a problem with the firmware version), the actual onboarding of the emulated device is faced with a similar problem.When the emulated onboarding process for a particular network device is successfully completed, the onboarding initiating unit 226 may receive an acknowledgement message (e.g., a "Willing" message) from the management platform. Depending on the firmware version, the confirmation message can be slightly different from one network device to the other. In some aspects, the onboarding initiation unit 226 may perform the onboarding emulation for each individual network device in the device orchestration list. For example, if there are 50 devices in the device orchestration list, the onboarding initiation unit 226 may send 50 onboarding request messages to the activation platform. If all the onboarding processes have been successfully run, the onboarding initiating unit 226 receives 50 acknowledgement messages from the management platform.Given that devices of the same type, model, and firmware version may have similar onboarding behavior, according to alternative aspects, onboarding emulation may be performed for all different types / models of network devices and all different firmware versions. For example, if the 50 network devices on the device orchestration list all have the same device type / model and operate with the same firmware version (i.e., they are completely identical), rather than performing 50 onboarding emulations for the 50 network devices, the onboarding initiation unit 226 may emulate the onboarding process only once (e.g., by sending an onboarding request message to the activation platform). If the emulated onboarding process is successful, the onboarding initiating unit 226 may receive an acknowledgment message from the management platform. In another example, the 50 network devices may have the same device type / model, but operate on different firmware versions, with 20 devices operating on firmware version 1 and the other 30 devices operating on firmware version 2. Accordingly, the onboarding initiating unit 226 may emulate two onboarding processes with the same device type / model and two different firmware versions.When there are multiple device types / models and multiple firmware versions among the devices to be bound, the binding initiating unit 226 may group these devices into different groups, each group including devices having the same type / model and firmware version. The onboarding initiating unit 226 may emulate the onboarding process for each group based on the device type / model and the firmware version.In some aspects, the onboarding initiating unit 226 may initiate the onboarding processes for multiple devices one after the other, meaning that the onboarding initiating unit 226 may perform the onboarding emulation for one device at a time. For example, the unit 226 initiating the onboarding may send an onboarding request for a network device on the device orchestration list and wait for the acknowledgment message from the management platform. The binding initiating unit 226 sends a binding request for another network device on the device overview list after an acknowledgement message is received or after a predetermined time interval has elapsed for the acknowledgement message to be received.In alternative aspects, the onboarding initiation unit 226 may initiate the onboarding processes for multiple network devices in parallel, meaning that the onboarding initiation unit 226 may perform the onboarding emulation for multiple devices simultaneously. For example, the onboarding initiating unit 226 may simultaneously send multiple onboarding request messages corresponding to multiple devices on the device orchestration list to the device activation platform.The onboarding problem analysis unit 228 may be responsible for analyzing the possible cause(s) of an onboarding fault. When the onboarding initiating unit 226 does not receive the confirmation message corresponding to an onboarding process after a predetermined time interval (e.g., a few seconds), the onboarding initiating unit 226 may send an onboarding failure message together with the device information associated with the device at which the failure occurs to the onboarding problem analyzing unit 228. In some aspects, the onboarding problem analyzer 228 may perform a series of diagnostic tests based on the received device information (e.g., device model and firmware version) in response to receiving the onboarding fault message.In some aspects, the series of diagnostic tests may include at least one of a local network connectivity test, a gateway reachability test, an ARP test, a DNS test, a firmware test, a protocol test, a management platform test, etc.To test connectivity of the local area network, the onboarding problem analyzer 228 may determine whether the computing device running the emulation application for onboarding the device may receive a valid Internet Protocol (IP) address. If it fails to obtain a valid IP address, this may indicate that the local area network has connectivity problems or the network interface of the computing device is faulty. Further problems associated with the local area network may be caused by the default gateway router of the local area network being faulty. The onboarding problem analyzer 228 may also determine whether the default gateway is reachable and / or whether the ARP server for the default gateway is functioning properly.The onboarding problem analyzer 228 may also perform the DNS test by determining whether the DNS resolutions for the activation platform and the management platform are successful. In one aspect, the onboarding problem analyzer 228 may apply a DNS verification tool to the URLs of the activation platform and the management platform. The onboarding problem analyzer 228 may also determine whether the DNS server is functioning properly on the network.The onboarding problem analyzer 228 may determine whether the firmware currently installed in the emulated device matches the device type / model and is compatible with the management platform. If the firmware is incompatible (e.g., does not meet the minimum requirements), the onboarding problem analyzer 228 may also check whether the firmware repository (e.g., the firmware database 204 in the device activation platform 200) may provide the required firmware upgrade to the network device (i.e., whether the network device may access the firmware repository and download the firmware upgrade).If the device passes the firmware test (i.e., it has been the correct firmware version or the firmware update successful), the onboarding problem analysis unit 228 may perform a protocol test to determine whether a protocol fault is present in the activation platform. More specifically, the onboarding problem analyzer 228 may determine whether the device is provided the proper URL for the management platform.The onboarding problem analysis unit 228 may also determine whether the management platform is functioning properly. In one example, the onboarding problem analyzer 228 may anping the server hosting the management platform. In another example, the onboarding problem analyzer 228 may send an onboarding request message using the hardware / firmware parameters of the computing device running the emulation application for the device binding to check whether it can receive an acknowledgment message.The onboarding problem analysis unit 228 may summarize the results of the series of diagnostic tests to determine the root cause of the onboarding fault. In most cases, the onboarding error may be caused by a single reason (e.g., the DNS or ARP error, inability to update the firmware, local area network failure, server failure at the activation or management platform, etc.). In some cases, there may also be several reasons for the onboarding failing. In some embodiments, each individual reason that results in the onboarding failure may be associated with a unique onboarding identifier (ID) that may be presented to the customer. In one example, the onboarding problem ID may be numerical. In another example, a three digit number (e.g., 001, 002, etc.) may be used to represent a particular onboarding problem ID.The packet detection unit 230 may be responsible for detecting packets sent and received by the device binding emulation system 200 during the device binding emulation process. In some aspects, the onboarding problem analyzer 228 may also perform an analysis of the detected packets in determining the root cause of the onboarding fault. For example, a response packet from the management platform may indicate that the management platform encounters certain errors. In further aspects, the packet detection unit 230 may apply a series of filters (e.g., filters based on destination addresses) to ensure that it detects only packets associated with the onboarding process (including the series of diagnostic tests). The collected packages can be packaged with the results of the diagnostic tests to present to the customer.FIG. 3 shows an example graphical user interface (GUI) according to an aspect of the present application. Device emulation user interface 300 may include a device table 302, a "Emulate All Devices" button 304, and a "Emulate Selected Devices" button 306.The device table 302 may include a series of entries, each entry corresponding to a network device to be connected. Each table entry may include information about the device hardware (e.g., device serial number, device type / model, MAC address of the device, etc.) and information about the device firmware (e.g., the firmware version).The customer may select a number of network devices for onboarding emulation and click on button 306 to emulate the onboarding processes of the selected network devices. Alternatively, the customer may also click on button 304 to emulate the onboarding processes for all network devices in device table 302. As mentioned above, emulation can be performed for each individual network device or group of identical network devices (i.e., network devices having the same device type / model and firmware version). In emulation of device onboarding, the emulation system can send an onboarding request to the activation platform one after the other for each device or group of identical devices.The result of emulation of the device binding can be presented in table 302 for each network device. In some aspects, the emulation result may indicate whether or not the network device passes the onboarding test. More specifically, if the emulated onboarding process for a particular network device may result in an acknowledgment message from the management platform, the particular network device is said to have passed the onboarding test. If the network device fails the onboarding test (e.g., if no acknowledgment message is received after a predetermined amount of time), the emulation result may include one or more onboarding issue IDs associated with the failed onboarding test. In the example shown in FIG. 3, the displayed emulation result for a failed test may also include a link through which the customer may download a detailed onboarding fault report that includes the analysis of the cause of the onboarding fault and may also include the captured packages.FIG. 4A is a flow diagram illustrating an example of an onboarding emulation process according to an aspect of the present application. During operation, a customer enters an order for a number of network devices (operation 402). The device parameters of the ordered network devices may be sent to the device activation platform and added to a device inventory list for the customer in the device inventory database maintained by the device activation platform (operation 404). Each device dataset may include information about the device hardware (e.g., type and model, serial number, MAC address, etc.) and information about the firmware (e.g., version number) installed on the device.These network devices can be used in the customer's local area network. Prior to incorporating the network devices into the management platform, the customer may wish to test whether these network devices can be successfully incorporated and perform the necessary diagnostic tests if an incorporation failure occurs at one or more network devices. To do so, the customer may install and launch the device mount emulation system on a computer system located on the same local area network as the network devices to be mounted (operation 406). For example, the customer can install the emulation system for the device binding on a personal computer (PC) or a laptop which is connected to the same local network in which the network devices to be bound are also used.The emulation system for device onboarding may then access the device activation platform to obtain the device inventory list and create a device orchestration list (operation 408). The device orchestration list may include the customer's network devices to be bound and displayed on a user interface to allow the customer to select a number of network devices for onboarding emulation. In one aspect, the network devices to be bound may be grouped based on the device type / model and the firmware version. Network devices of the same type and model installed with the same firmware version can be grouped together.The customer may enter a user command to perform the onboarding emulation (operation 410). For example, the customer may click on button 304 or button 306 in device introduction emulation user interface 300 to initiate emulation of the onboarding process for all network devices or selected network devices, respectively. In response to the user command, the emulation system may perform emulation of the device port with various parameters associated with the emulated devices (operation 412). For example, the emulation system may send a sequence of onboarding request messages to the activation platform to exchange handshake messages with the onboarding request system. Each onboarding request message may correspond to a network device or group of network devices of the same type / model and firmware version. The onboarding request message may include information about the device hardware (e.g., type / model, serial number, MAC address, etc.) and information about the device firmware (e.g., firmware version).For each emulated onboarding process, the emulation system may determine whether the onboarding is successful (operation 414). More specifically, the emulation system may determine whether an acknowledgment message may be received from the management platform within a predetermined time interval in response to a particular onboarding request message. If so, the particular onboarding emulation is considered successful and the emulation system displays the result in the GUI (operation 416). If the respective onboarding emulation fails, the emulation system may perform a series of diagnostic tests (operation 418). The diagnostic tests may include, but are not limited to, a local area network connectivity test, a gateway reachability test, an ARP server test, a DNS server test, a firmware upgrade test available as needed, a test whether the activation platform contains a protocol fault, a test whether the management platform has a fault, etc. In some aspects, performing the diagnostic tests may include sending query packets to the standard gateway, the ARP server, the DNS server, the activation platform, the management platform, etc. Performing the diagnostic tests may also include collecting packets associated with the emulated onboarding process and the diagnostic tests.The emulation system may further analyze the results of the diagnostic tests and the detected packets to determine the possible cause(s) of the onboarding fault (operation 420). The emulation system may then display the result of the fault analysis in the GUI (operation 416). According to some aspects of the instant application, each cause (e.g., a local network connectivity problem, a DNS problem, an ARP problem, a firmware server problem, an activation server problem, a management server problem, etc.) may be associated with an onboarding problem ID displayed in the GUI. In further aspects, the GUI may also provide a link that allows the customer to download a detailed error report file containing the error analysis and the captured packages.If the onboarding emulation for a particular network device is successful, the customer can perform the actual onboarding of the network device (i.e., turn on the device and connect it to the network). If the actual onboarding fails, it is very likely that the network device has faulty components (e.g. a faulty network card). If the onboarding emulation for a particular network device is not successful, the customer may take remedial action based on the fault report. For example, the error may be due to the proper firmware update not being available and the customer may contact the device manufacturer to request the update file. If the fault is due to local area network connection problems, the customer must address these connection problems before operating the network device. The situation is similar for ARP or DNS problems which the customer has to remedy before the network device is put into operation.FIG. 4B is a flow diagram illustrating example onboarding emulation operations performed by a computing device according to an aspect of the present application. During operation, a computing device may receive from a device activation platform a list of network devices to be included in a device management platform (operation 422). The device activation platform may collect customer inventory information using various methods. In one example, the device activation platform may receive a report from a centralized device shopping system tracking the network devices purchased by all customers. The report may include the customer identifier, the type / model of the device, the serial number and MAC address of the device, the version of the firmware / software installed on the device, etc. In another example, the device activation platform may also receive the customer inventory information from the customer.For a corresponding network device in the list of network devices, the computing device may collect hardware and firmware information associated with the corresponding network device (operation 424). In one example, the computing device may maintain a list of network devices to be taken onboard and collecting hardware and firmware information associated with a network device may include performing a search based on the serial number of a network device.The computing device may emulate the onboarding process of the respective network device using the collected hardware and firmware information, which includes exchanging one or more handshake messages with the device activation platform (operation 426). For example, the computing device may send an onboarding request message to the device activation platform on behalf of the network device.In response to the absence of receipt of an acknowledgement message from the device management platform indicating that the emulated onboarding process was successful, the computing device may perform a diagnostic operation to determine one or more potential issues associated with the onboarding process of the respective network device (operation 428). The computing device may further display the result of the diagnostic operation on a user interface (operation 430).Although the example method in FIGS. 4A-4B shows a particular order of performing particular operations, the methods are not limited to this order. For example, the operations shown in the flowchart sequentially may be performed in a different order, simultaneously or partially simultaneously, or combinations thereof.FIG. 5 illustrates an example computer system that facilitates emulation of boarding a device according to an aspect of the present application. The computer system 500 may include a processor 502, a memory 504, and a storage device 506. Moreover, computer system 500 may be coupled to peripheral input / output user devices 510, e.g., a display device 512, a keyboard 514, and a pointing device 516. Storage medium 516 may store operating system 518, emulation system for embedding devices 520, and data 540.The device onboarding system 520 may include instructions that, when executed by the computer system 500, may cause the computer system 500 or the processor 502 to perform the methods and / or processes described in this disclosure. In particular, the computer system 500 may, by executing these instructions, achieve the goal of emulating the device onboarding processes for a number of network devices and identifying the most likely cause of an onboarding fault. The device onboarding emulation system 520 may include instructions to implement a front end (front end implementation instructions 522), instructions to generate a device orchestration list based on a device inventory list (device orchestration instructions 524) maintained by the device activation platform, instructions to emulate the device onboarding processes for a plurality of devices or a plurality of device groups (device onboarding emulation instructions 526), instructions to recover the onboarding process in the event of a device onboarding recovery (device onboarding troublessting instructions 528) failure, Instructions to Capture Network Packets during Onboarding Emulation (Packet Capping Instructions 530) and Instructions to Display the Emulation Result (Emulation Result Displaying Instructions 532). The data 540 may include a device orchestration list 542.In general, the disclosure describes a mechanism for emulation of the onboarding process of network devices. More specifically, prior to actual onboarding of network devices (e.g., APs, gateways, switches, routers, etc.) into a device management platform provided by the device manufacturer, the customer may launch an application for emulation of device onboarding on a computer (e.g., a personal computer or laptop) in the customer's local area network. The device onboarding emulation application may retrieve a list of network devices purchased from the customer and create an orchestration device list that includes a plurality of onboarding devices. Each entry in the orchestration device list corresponds to a network device to be bound and may contain information about the device hardware (e.g., device type and model, serial number, MAC address, etc.) and information about the device firmware (e.g., firmware version). For each device or group of devices with a unique combination of device model and firmware version, the device entry emulation application may emulate the device entry process using the device hardware and firmware information. The device onboarding emulation application may exchange handshake messages with a device activation platform on behalf of any emulated device or device group. Successful emulation may result in the device management platform sending an acknowledgement message to the device-on-boarding emulation application. Emulation is considered to have failed if such an acknowledgment message cannot be received after a predetermined interval. In response to a failed onboarding emulation, the device onboarding emulation application may perform a series of diagnostic tests (e.g., a local area network connectivity test, an ARP test, a DNS test, a firmware test, tests on the servers, etc.) and analyze the test results to determine the most likely cause of the onboarding fault. The device onboarding emulation application may present the fault analysis to the customer via a graphical user interface. The device onboarding emulation application may also interface to a packet detection application to detect a series of network packets associated with the onboarding emulation process, including the error recovery process. The captured network packets may also be analyzed along with the diagnostic test results to improve the accuracy of the diagnostic. If the emulated onboarding process for a network device succeeds, but the network device has an onboarding fault, it is very likely that the onboarding fault is caused by faulty hardware components (e.g., a faulty network card or NIC) of the network device.One aspect of the present application may provide a system and method for emulation of network device onboarding. In operation, a computing device may receive from a device activation platform a list of network devices to be included in a device management platform method. For a corresponding network device on the list of network devices, the system may collect hardware and firmware information associated with the corresponding network device and emulate an onboarding process of the corresponding network device using the collected hardware and firmware information that includes exchanging one or more handshake messages with the device activation platform. In response to the absence of receipt from the device management platform of an acknowledgement message indicating that the emulated onboarding process was successful, the system may perform a diagnostic operation to determine one or more potential issues associated with the onboarding process of the respective network device and indicate the result of the diagnostic operation on a user interface.In a variation of this aspect, the hardware information may include one or more of the following: a device type, a device model, a serial number, and a media access control (MAC) address.In a variant of this aspect, the firmware information comprises a firmware version number.In a variant of this aspect, the system can select a subset of network devices from the list of network devices to be bound and emulate the onboarding processes of the selected subset of network devices.In another variation, emulation of the onboarding processes of the selected subset of network devices may include sequentially sending a set of onboarding request messages corresponding to the selected subset of network devices to the device activation platform.In another variant, emulation of the onboarding processes of the selected subset of network devices may include sending a set of onboarding request messages corresponding to the selected subset of network devices to the device activation platform in parallel.In a variant of this aspect, performing the diagnostic operation includes performing a series of tests that include one or more of: a connectivity test on a local area network to which the network device is coupled; a reachability test on a standard local area network gateway; a test on an address resolution protocol (ARP) server; a test on a domain name system (DNS) server; a test whether a firmware upgrade is available; a test whether the device activation platform includes a protocol fault; and a test whether the device management platform encounters a fault.In another variant, performing the diagnostic operation may also include detecting incoming and outgoing communication packets during the diagnostic operation.In another variant, the determination of the one or more potential issues may include analyzing the results of the test series and the recorded communication packets.The terminology used herein is for the purpose of describing examples only and is not to be taken as limiting. As used herein, the singular forms "a", "an" and "the" also include the plural forms, unless the context clearly indicates otherwise. The term "plurality" as used herein is defined as two or more than two. Although the terms "first", "second", etc. are used herein to describe various elements, these elements should not be limited by these terms, as these terms are only used to distinguish one element from another unless stated otherwise or the context indicates otherwise. As used herein, the term "includes" means including, but not limited to, the term "including" means including, but not limited to. The term "based on" means based at least in part on.The above description is intended to enable those skilled in the art to make and use the examples and is provided in connection with a particular application and its requirements. Various modifications to the examples shown will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other implementations and applications without departing from the spirit and scope of the present disclosure. Therefore, the scope of the present disclosure is not limited to the examples shown, but is intended to achieve the greatest possible scope consistent with the principles and features disclosed herein.The methods and processes described in the Detailed Description section may be embodied as code and / or data that may be stored in a computer readable storage medium as described above. When a computer system reads and executes the code and / or data stored on the computer readable storage medium, the computer system executes the methods and processes embodied as data structures and code and stored in the computer readable storage medium. The computer readable storage medium may be any electronic, magnetic, optical, or other physical storage device that contains or stores information such as executable instructions, data, and the like. For example, any computer readable storage medium described herein may be a RAM, EEPROM, volatile memory, non-volatile memory, flash memory, a storage drive (e.g., a HDD, an SSD), any type of storage disk (e.g., a compact disc, a DVD, etc.), or the like, or a combination thereof. Moreover, any computer readable storage medium described herein may be non-transitory.Moreover, the methods and processes described above may be incorporated into hardware devices or devices. The hardware components or devices may include, but are not limited to, application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), dedicated or shared processors executing a particular software unit or piece of code at a particular time, as well as other known or later developed programmable logic components. When the hardware devices or devices are activated, they perform the methods and processes included therein.The foregoing descriptions of examples are for illustration and description only. They are not intended to be exhaustive and do not limit the scope of this disclosure to the forms disclosed. Accordingly, many modifications and variations will be apparent to those skilled in the art.

Claims

A method comprising: obtaining, by a computing device, a list of network devices to be included in a device management platform from a device activation platform; for a respective network device in the list of network devices, collecting hardware and firmware information associated with the respective network device; emulating an onboarding process of the respective network device using the collected hardware and firmware information that comprises exchanging one or more handshake messages with the device activation platform; in response to the failure to receive an acknowledgement message indicating that the emulated onboarding process was successful from the device management platform, perform a diagnostic operation to determine one or more potential issues associated with the onboarding process of the respective network device; and display the result of the diagnostic operation on a user interface.The method of claim 1, wherein the device activation platform is to access a centralized device purchase system that tracks network devices purchased from customers to obtain inventory information associated with each customer; and wherein obtaining the list of network devices to be bound comprises accessing the inventory information associated with the customer.The method of claim 1, wherein the hardware information comprises one or more of: a device type; a device model; a serial number and a media access control (MAC) address; and wherein the firmware information comprises a firmware version number.The method of claim 1, further comprising: selecting a subset of network devices from the list of network devices to be bound; and emulating the onboarding processes of the selected subset of network devices.The method of claim 4, wherein emulating the onboarding processes of the selected subset of network devices comprises sequentially sending a set of onboarding request messages corresponding to the selected subset of network devices to the device activation platform.The method of claim 4, wherein emulating the onboarding processes of the selected subset of network devices comprises sending a set of onboarding request messages corresponding to the selected subset of network devices to the device activation platform in parallel.The method of claim 1, wherein performing the diagnostic operation comprises performing a series of tests comprising one or more of: a connectivity test in a local area network to which the network device is coupled; a reachability test on a standard local area network gateway; a test on an address resolution protocol (ARP) server; a test on a domain name system (DNS) server; a test whether a firmware upgrade is available; a test whether the device activation platform contains a protocol fault; and a test whether a fault is present in the device management platform.The method of claim 7, wherein performing the diagnostic operation further comprises detecting incoming and outgoing communication packets during the diagnostic operation.The method of claim 8, wherein determining the one or more potential issues comprises analyzing the results of the test series and the detected communication packets.A computer system comprising: a processor; and a storage device storing instructions that, when executed by the processor, cause the processor to perform a method, the method comprising: obtaining from a device activation platform a list of network devices to be included in a device management platform; for a respective network device in the list of network devices, collecting hardware and firmware information associated with the respective network device; emulating an onboarding process of the respective network device using the collected hardware and firmware information comprising exchanging one or more handshake messages with the device activation platform; in response to the failure to receive an acknowledgement message indicating that the emulated onboarding process was successful from the device management platform, perform a diagnostic operation to determine one or more potential issues associated with the onboarding process of the respective network device; and display the result of the diagnostic operation on a user interface.The computer system of claim 10, wherein the device activation platform accesses a centralized device purchase system that tracks network devices purchased from customers to obtain inventory information associated with each customer; and wherein obtaining the list of network devices to be bound comprises accessing the inventory information associated with the customer.The computer system of claim 10, wherein the hardware information comprises one or more of: a device type; a device model; a serial number and a media access control (MAC) address; and wherein the firmware information comprises a firmware version number.The computer system of claim 10, wherein the method further comprises: selecting a subset of network devices from the list of network devices to be bound; and emulating the onboarding processes of the selected subset of network devices.The computer system of claim 13, wherein emulating the onboarding processes of the selected subset of network devices comprises sequentially sending a set of onboarding request messages corresponding to the selected subset of network devices to the device activation platform.The computer system of claim 13, wherein emulating the onboarding processes of the selected subset of network devices comprises sending a set of onboarding request messages corresponding to the selected subset of network devices to the device activation platform in parallel.The computer system of claim 10, wherein performing the diagnostic operation comprises performing a series of tests comprising one or more of: a connectivity test in a local area network to which the network device is coupled; a reachability test on a standard local area network gateway; a test on an address resolution protocol (ARP) server; a test on a domain name system (DNS) server; a test whether a firmware upgrade is available; a test whether the device activation platform contains a protocol fault; and a test whether a fault is present in the device management platform.The computer system of claim 16, wherein performing the diagnostic operation further comprises detecting incoming and outgoing communication packets during the diagnostic operation.The computer system of claim 17, wherein determining the one or more potential issues comprises analyzing the results of the test series and the detected communication packets.A non-transitory computer readable storage medium storing instructions that, when executed by a processor, cause the processor to perform a method, the method comprising: obtaining, from a device activation platform, a list of network devices to be included in a device management platform; for a respective network device in the list of network devices, collecting hardware and firmware information associated with the respective network device; emulating an onboarding process of the respective network device using the collected hardware and firmware information comprising exchanging one or more handshake messages with the device activation platform; in response to the failure to receive an acknowledgement message indicating that the emulated onboarding process was successful from the device management platform, perform a diagnostic operation to determine one or more potential issues associated with the onboarding process of the respective network device; and display the result of the diagnostic operation on a user interface.The non-transitory computer readable storage medium of claim 19, wherein performing the diagnostic operation comprises performing a series of tests comprising one or more of: a connectivity test in a local area network to which the network device is coupled; a reachability test on a standard local area network gateway; a test on an address resolution protocol (ARP) server; a test on a domain name system (DNS) server; a test whether a firmware upgrade is available; a test whether the device activation platform contains a protocol fault; and a test whether a fault is present in the device management platform.

Images