Provision of automated software upgrades for transport layer devices

Abstract

An automatic software upgrade for transport layer devices is described. One or more transport layer devices from a device list for upgrade are presented on a user interface (UI). A user selects one or more transport layer devices from the device list for upgrade via the UI. Upgrade details for upgrading the one or more transport layer devices selected from the device list for upgrade are received via the UI. Based on the upgrade details, an upgrade of the one or more transport layer devices is initiated. During the upgrade of the one or more transport layer devices, real-time information returned from the one or more transport layer devices is presented on the UI. The upgrade of the one or more transport layer devices is verified based on the real-time information.

Description

Technical Field

[0001] This description relates to a Configuration Manager (CM) User Interface (UI) for providing automatic software upgrades for transport layer devices, and a method of using the same.

Background Art

[0002] The expansion of applications and the data using data and communication networks have grown significantly. The data streaming of audio and video files, and the increase in network data applications and traffic have strained resources. The strain has been further exacerbated by the increasing use of Internet of Things (IoT) devices.

Summary of the Invention

Problems to be Solved by the Invention

[0003] To support the increasing network traffic, transport layer devices such as gateways, routers, switches, and firewalls rely on vendors and operation teams to upgrade the configuration files and firmware on the devices to ensure smooth operation. Upgrades are also performed to solve software problems and improve security on these devices. The use of wireless or Over-The-Air (OTA) methods has increased the efficiency of upgrade execution, but upgrades rely on manual methods for performing upgrades to configuration files and firmware. For example, a user manually logs on to the device and executes a sequence of command line interface commands to perform the upgrade. The same manual technique is used to verify the device configuration and compare the pre-upgrade and post-upgrade configurations.

[0004] In addition, the user checks to ensure that the device to be upgraded is not receiving network traffic. Ensuring that the device is not receiving network traffic is performed using additional manual checks. The user also manually backs up the device configuration to allow for a rollback to the pre-upgrade configuration in case the upgrade to the device is unsuccessful.

[0005] To upgrade multiple devices, users must manually perform these processes for each device individually. These manual processes are cumbersome and time-consuming. Upgrading multiple devices multiplies the time required to upgrade each device. Furthermore, because users are not provided with timely status information, upgrades continue even if they result in errors or invalid configurations. [Means for solving the problem]

[0006] In at least one embodiment, a method is provided for providing an automated software upgrade for transport layer devices. The method includes receiving a selection of one or more transport layer devices from a device list for upgrade on a user interface (UI); receiving upgrade details for the upgrade of the one or more transport layer devices selected from the device list for upgrade via the UI; initiating the upgrade of one or more transport layer devices based on the upgrade details; presenting real-time information returned from one or more transport layer devices on the UI during the upgrade of one or more transport layer devices; and verifying the upgrade of one or more transport layer devices based on the real-time information.

[0007] In at least one embodiment, a device is provided for performing an automated software upgrade for transport layer devices. The device includes a memory for storing computer-readable instructions and a processor connected to the memory. The processor is configured to execute computer-readable instructions to perform the following: present one or more transport layer devices from a device list for upgrade on a user interface (UI); receive a selection of one or more transport layer devices from the device list for upgrade via the UI; receive upgrade details for the upgrade of one or more transport layer devices selected from the device list for upgrade via the UI; initiate the upgrade of one or more transport layer devices based on the upgrade details; present real-time information returned from one or more transport layer devices on the UI during the upgrade of one or more transport layer devices; and verify the upgrade of one or more transport layer devices based on the real-time information.

[0008] In at least one embodiment, a non-temporary computer-readable medium is provided which stores computer-readable instructions causing a processor to perform an operation that, when executed by the processor, includes: receiving a selection of one or more transport layer devices from a device list for upgrade on a user interface (UI); receiving upgrade details for the upgrade of one or more transport layer devices selected from the device list for upgrade via the UI; initiating the upgrade of one or more transport layer devices based on the upgrade details; presenting real-time information returned from one or more transport layer devices on the UI during the upgrade of one or more transport layer devices; and verifying the upgrade of one or more transport layer devices based on the real-time information. [Brief explanation of the drawing]

[0009] Aspects of this disclosure are best understood from the following detailed description, which is read in conjunction with the accompanying drawings. Note that, in accordance with industry practice, various features are not depicted to actual size. In fact, the dimensions of various features may be increased or decreased for the sake of clarity in the discussion.

[0010] Figure 1 is a diagram of a system for performing a device upgrade according to at least one embodiment.

[0011] Figure 2 is an end-to-end flow diagram of an upgrade process according to at least one embodiment.

[0012] Figure 3 shows an example of the command-line interface used to perform a manual upgrade.

[0013] Figure 4 is a diagram of a Configuration Manager User Interface (CM UI) according to at least one embodiment.

[0014] Figure 5 is a diagram of an upgrade details input UI according to at least one embodiment.

[0015] Figure 6 is a diagram of an upgrade history UI according to at least one embodiment.

[0016] Figure 7 is a flowchart of a method for merging regions according to at least one embodiment.

[0017] Figure 8 is a high-level functional block diagram of a processor-based system according to at least one embodiment. [Modes for carrying out the invention]

[0018] The embodiments described herein describe examples for implementing different features of the subject matter provided. Examples of components, values, operations, materials, arrangements, etc., are described below for the sake of simplicity of this disclosure. These are, needless to say, examples and are not intended to be limiting. Other components, values, operations, materials, arrangements, etc., are also conceivable. For example, the formation of a first feature above or on a second feature in the following descriptions includes embodiments in which the first and second features are formed in direct contact, and embodiments in which an additional feature is formed between the first and second features so that the first and second features are not in direct contact. In addition, this disclosure repeats reference numbers and / or letters in various examples. This repetition is for simplicity and clarity and does not indicate relationships between the various embodiments and / or configurations discussed.

[0019] Furthermore, spatially relative terms such as "beneath," "below," "lower," "above," and "upper" are used here for ease of description in describing the relationship between one element or feature and other elements or features, as illustrated in the diagram. The spatially relative terms are intended to encompass different orientations of the device during use or operation, in addition to the orientation shown in the diagram. The device or apparatus may be oriented in other directions (rotated 90 degrees or in other directions), and the spatially relative descriptors used here are interpreted accordingly.

[0020] Terms such as “User Equipment,” “Mobile Station,” “Mobile,” “Mobile Device,” “Subscriber Station,” “Subscriber Equipment,” “Access Terminal,” “Terminal,” and “Handset,” and similar terms, refer to wireless devices used by subscribers or users of wireless communication services for receiving or transmitting data, control, voice, video, sound, gaming, or data streams or signaling streams. The above terms are used interchangeably in the subject matter specification and related drawings. Terms such as “Access Point,” “Base Station,” “Node B,” “Evolved Node B (eNode B),” “Next Generation Node B (gNB),” “Enhanced gNB (en-gNB),” “Home Node B (HNB),” and “Home Access Point (HAP)” refer to wireless network components or devices that provide and receive data, control, voice, video, sound, gaming, or substantially any data streams or signaling streams to and from the UE.

[0021] In at least one embodiment, a Configuration Manager (CM) user interface (UI) performs end-to-end upgrade and real-time status checks, presents failure details, and performs configuration verification for pre- and post-upgrade operations. The CM UI provides real-time data tracking to address any issues that arise during the upgrade process. The CM UI communicates with the device using applications supported by Northbound Netconf. The upgrade is performed based on a single action performed on the CM UI.

[0022] While traditional solutions rely on users to manually log on to all devices and perform upgrades, the CM UI allows users to run the upgrade process on one or multiple devices in parallel. The CM UI handles command execution using the Netconf interface and with the assistance of supported northbound modules / applications. The CM UI tracks real-time updates from one or more devices being upgraded. It provides visibility into end-to-end automation of use cases by providing logs to resolve upgrade issues, for example, using a debugging process. Planned upgrades can be identified and canceled within the CM UI. A history of devices being upgraded is also presented.

[0023] The embodiments described herein offer advantages over manual upgrade processes, including time savings, cost and expense reductions, and simplify the management of the upgrade process. Manual efforts to upgrade devices, even with the use of scripts, are cumbersome tasks. The CM UI also allows for the saving of human resources and provides safeguards against human error.

[0024] FIG. 1 is a diagram of a system 100 for performing device upgrades according to at least one embodiment.

[0025] In FIG. 1, a configuration manager (CM) 110 presents a CM user interface (UI) 112 to automate upgrades to a device. CM 110 is coupled to a northbound service 120 to interact with transport layer devices “1 - n” 130, 150 according to the type of interface (e.g., Nefconf) supported by the transport layer devices “1 - n” 130, 150. For example, Netconf provides a mechanism for installing, operating, deleting, and upgrading the configuration of transport layer devices. The northbound service 120 can access the transport layer devices “1 - n” 130, 150. As an example, the transport layer device “1” 130 includes a processor 132 and a non - transient storage medium 134.

[0026] The non - transient storage medium 134 includes instructions / applications 136 executable by the processor 132 to perform the functions of the transport layer device “1” 130. The non - transient storage medium 134 of the transport layer device “1” 130 also includes a configuration file 138. Communication is provided by a transceiver 140 that enables the transport layer device “1” 130 to communicate with the northbound service 120 via the network 160 and communicate wired or wirelessly with other devices including the transport layer device “n” 150.

[0027] In at least one embodiment, one or more of connections 170-176 are implemented using at least one of a wireless connection or a wired connection. In at least one embodiment, one or more of connections 170-176 are implemented as a wireless connection that operates according to a wireless technology protocol for exchanging data using any of the IEEE 802.11 Wi-Fi protocols, Bluetooth protocols, Bluetooth Low Energy (BLE), or CBRS (citizens broadband radio service) band, 2.4 GHz band, 5 GHz band, or 6 GHz band, or other short-range protocols that operate according to any licensed or unlicensed band. Additionally, in at least one embodiment, one or more of connections 170-176 are implemented using a wireless connection that operates according to the RF4CE protocol, ZigBee protocol, Z-Wave protocol, or IEEE 802.15.4 protocol (not limited thereto). In at least one embodiment, one or more of connections 170-176 are implemented using a coax (MoCA) network. In at least one embodiment, one or more of connections 170-176 are a wired Ethernet connection. In at least one embodiment, one or more of connections 170-176 are implemented as a 4G or 5G connection.

[0028] CM110 provides a multi-vendor performance and observable framework for accessing network system data. CM User Interface (UI) 112 provides a visual display of the network and associated parameter status. Settings on CM UI 112 allow for selection of domain, vendor, and technology. CM UI presents parameters in a network tree to view the current configuration of network elements. In at least one embodiment, CM UI 112 performs end-to-end upgrade and real-time status check provision, presents failure details, and performs configuration verification for pre- and post-upgrade operations. CM UI 112 provides real-time data tracking to address any issues that arise during the upgrade process. CM UI 112 communicates with transport layer devices "1-n" 130, 150 using applications supported by northbound service 120, such as Netconf applications.

[0029] The upgrade is performed based on a single action executed on the CM UI 112. While traditional solutions rely on the user to manually log on to all devices and perform the upgrade, the CM UI 112 allows the user to run the upgrade process on a single transport layer device 130 or in parallel on multiple transport layer devices "1-n" 130, 150. The CM UI 112 handles command execution, for example, using the Netconf interface and with the assistance of a supported northbound service 120. The CM UI 112 tracks real-time updates from one or more transport layer devices "1-n" 130, 150 being upgraded.

[0030] CM UI112 provides visibility into end-to-end automation of use cases, for example, by providing logs to resolve upgrade issues using a debugging process. Planned upgrades can be identified and canceled in CM UI112. A history record of the devices being upgraded is also presented. CM UI112 further presents one or more upgrades of transport layer devices "1-n" 130, 150 and the associated history records.

[0031] CM UI112 offers advantages over manual upgrade processes, including time savings, cost and expense reductions, and simplifies the management of the upgrade process. Manual efforts to upgrade devices, even with the use of scripts, are cumbersome tasks. The automated upgrade process implemented using CM UI112 allows for the saving of human resources and provides safeguards against human error.

[0032] Netconf in Northbound Service 120 supports Configuration Data and Notification Data Protocol operations to retrieve and edit configuration data, encode RPC (remote procedure call) and notifications, and provide secure and reliable message transport between clients and servers. Netconf in Northbound Service 120 enables authorized users to remotely configure, manage, and monitor devices, and allows devices to proactively report alarms and events for real-time display in the CM UI 112.

[0033] Figure 2 is an end-to-end flow diagram 200 of the upgrade process according to at least one embodiment.

[0034] In Figure 2, the CM UI 202 synchronizes with the backend database (204) to dynamically update state changes. State changes are presented on the CM UI 202. The CM UI 202 is used by the user to share device details and determine which devices to perform the upgrade on. The code for performing the upgrade is based on the northbound entity 220 controlled by the CM 210. Once details for one or more transport layer devices 230 are obtained, upgrade details (e.g., operating system (OS) version, etc.) provided in a specific file for performing the upgrade are set to update one or more transport layer devices 230.

[0035] CM210 communicates with the Northbound Entity 220 in middleware, and the Northbound Entity 220 communicates with one or more devices to be upgraded. The Northbound Entity 220 performs the upgrade on one or more devices with details shared via CM UI 202. The status of the process is directly reflected on CM UI 202 using databases, status changes, logs, etc. Status changes and logs are communicated to CM UI 202 to provide users with visibility into the upgrade process. CM UI 202 displays status information in a network tree. For example, CM UI 202 shows information such as the device in the planned state, whether an upgrade is in progress for the device, whether an upgrade for the device has failed, whether an upgrade for the device has been successful in the past, warnings, and other attributes.

[0036] When CM210 triggers an upgrade, the flow step is managed by the northbound entity 220 (e.g., middleware / Netconf). The CM UI 202 of CM210 generates a trigger with device details (e.g., using a REST API call 240). The northbound entity 220 receives the details and signals to change the status in the database to "Planned" for one or more devices to be upgraded (242). When the upgrade begins, the northbound entity 220 changes the status in the database to "In Progress" (250). Upgrades to one or more transport layer devices 230 are triggered using the Netconf interface of the northbound entity 220 (252).

[0037] The transport layer device 230 captures the upgrade and associated responses provided to the northbound entity 220 (260). Based on the responses from one or more transport layer devices 230, the northbound entity 220 determines a final state such as success, failure, or warning (270). Based on the final state determined by the northbound entity 220, the northbound entity 220 changes the state in the database to "success" (272), to "failure" (274), or to "warning" (276).

[0038] Figure 3 shows an example of the command-line interface 300 used to perform a manual upgrade.

[0039] To upgrade a device, the user logs on to each device via the command line interface 300. Commands 310, 312, 314, and 316 are also used to perform prerequisite activities, such as removing network traffic from the device. The user generates further commands 310, 312, 314, and 316 to verify that traffic passing through the device has stopped. The user then enters additional commands 310, 312, 314, and 316 on the terminal command line interface 300 to configure the basic settings. Commands 310, 312, 314, and 316 are also entered to back up the device so that the configuration can be rolled back to the pre-upgrade version in case of any problems that occur during the upgrade process. Commands 310, 312, 314, and 316 are then executed.

[0040] Responses 320, 322, 324, and 326 are returned in response to the execution of commands 310, 312, 314, and 316. After the upgrade is complete, the configuration is manually verified using commands 310, 312, 314, and 316 by comparing the pre-upgrade and post-upgrade configurations. Using scripts to execute commands 310, 312, 314, and 316 only slightly improves the time required to upgrade the device. Nevertheless, the scripts must be configured for one or more devices to be upgraded. Other processes, such as performing verification, receiving real-time status feedback, and validating the upgrade, are not automated. Furthermore, clear and easily interpretable visualization of the upgrade status and process is not provided through the use of scripts.

[0041] Figure 4 is a diagram of a configuration manager user interface (CM UI) 400 according to at least one embodiment.

[0042] In Figure 4, the CM UI displays status information about the network tree 402. A search window 410 is provided, and a drop-down menu 412 allows the user to select the scope of the search (e.g., the network tree 414). Through the setting icon 416, the user can select a view of the operational domain 418 (e.g., RAN 420, core 421, transport 422, security 423). In Figure 4, the domain 418 of transport 422 is selected. Under transport 422, further selections (e.g., "NW Co1" 424, "NW Co2" 425) are available. As an example, under "NW Co2" 424, "4G" 426 is selected. Under "4G" 426, "AGI" 427 is selected. Window 428 presents the results based on the selection made under transport 422. In Figure 4, window 428 shows 300 of the 551 network elements 429 identified by network element (NE) name 430. For example, 16 devices 431 are shown for provisioning in window 428 of the CM UI 400.

[0043] Window 428 also includes columns for Status 432, Date and Time of Last Configuration (Config) Update 434, Domain Identification 436, Equipment Type 438, Software (SW) Version 440, Configuration Conflict 442 Identification, and Status of Golden Configuration Parameters 444. For navigation within Window 428, an Up / Down navigation bar 446 and a Left / Right navigation bar 448 are provided.

[0044] In Figure 4, single or bulk upgrades are selectable. To upgrade a single device, the user selects row 451 (for example, NE element "ABC123xyzXY02" 449 is identified by NE name 430) and starts the upgrade for that device. To upgrade multiple devices in a trigger event, the user can select the menu option of bulk upgrade icon 450. In this way, the CM UI 400 can perform multiple upgrades, including logons for each device, whereas in the manual method, the user logs on to each device one by one. When an upgrade is selected, the CM UI 400 automatically creates a backup of the devices selected for upgrade and stops traffic on the devices selected for upgrade.

[0045] Once the device details are retrieved by the CM UI400, the user selects an upgrade file containing the upgrade details to perform the upgrade (see Figure 5 for details on selecting an upgrade file). For example, the upgrade file provides CM UI400 data such as the operating system (OS) version.

[0046] The CM UI400 communicates with the northbound entity and middleware, and the northbound entity communicates with one or more devices to be upgraded. The northbound entity performs the upgrade on one or more devices using the details provided via the CM UI400. The status of the process is directly reflected on the CM UI400 using databases, status changes, logs, etc. Status changes and logs are communicated to the CM UI400 to provide users with visibility into the upgrade process.

[0047] Selecting the setting icon 452 displays the upgrade status menu 454. As shown in Figure 4, real-time information 460 about the device's upgrade status is presented. The CM UI 400 provides information generated by tracing logs, along with updates to the upgrade process for the device and the associated real-time information 460. The user can see the exact stage the NE is currently in during the upgrade process. Because the real-time information 460 in the CM UI 400 shows the upgrade status, the user can verify that the selected device and associated traffic have stopped. The user can identify the NE whose upgrade process failed. The user can then select the NE element by clicking on the NE and see exactly what went wrong in the upgrade process for the selected device. Selecting a device displays the upgrade history UI 600 in Figure 6.

[0048] CM UI400 allows users to cancel planned upgrades. Upgrades can also be canceled by removing them from upgrade schedule 484. For example, if a user has scheduled upgrades for a large number of devices, scheduled upgrades for selected devices may be canceled. For example, if a user has scheduled upgrades for a large number of devices, scheduled upgrades for selected devices (e.g., several devices shown in plan status 462) may be canceled.

[0049] The cross "X" 464 indicates that the upgrade for the device has been canceled. Real-time information 460 also includes information icons 466 that can be selected to obtain information about the upgrade for the device. The warning icon 468 indicates that the upgrade is in a warning state. When the start time arrives, the status changes to "In Progress". The hourglass icon 470 indicates that the upgrade is in progress. After the upgrade is complete, the status will be displayed as "Successful" or "Failed". The checkmark icon 472 represents a successful upgrade. The failure icon 474 represents that the upgrade for the device has failed.

[0050] After the upgrade is complete, the CM UI 400 verifies the pre- and post-configurations. Depending on the mismatch detected between the pre- and post-configurations, an alarm (e.g., warning icon 468) is displayed on the CM UI 400. For example, there may be some new features that are not upgraded. The user can decide whether to proceed with the upgrade if the mismatch is acceptable, or select the rollback icon 482 to roll back the configuration to its pre-update status.

[0051] In Figure 4, the network element "ABC123xyzXY02" 449 is selected. In addition, function icons (e.g., rollback 482, scheduled upgrade 484, upload 486, download 488) are shown for the network element "ABC123xyzXY02" 449. The user can select the reset icon 490 to roll back the upgrade. After reviewing the real-time status information presented in window 428, the user can select the apply icon 492 to apply the upgrade.

[0052] Vendors and users can directly perform configuration pushes from the CM UI400 and visualize the execution information. The CM UI400 uses configuration files provided by the user (as described later in Figure 5). In at least one embodiment, the configuration file is provided in JSON format using template data provided by the user.

[0053] The CM UI400 enables users to perform end-to-end upgrades, provide real-time status checks, present failure details, and perform configuration verification for pre- and post-upgrade operations. The CM UI400 provides real-time data tracking to address any issues that arise during the upgrade process. The CM UI400 communicates with devices using applications supported by Northbound Netconf. The CM UI400 executes upgrades based on a single action performed on the CM UI400. While manual solutions require users to manually log on to each device to perform upgrades, the CM UI400 allows users to run the upgrade process on a single device or in parallel across multiple devices.

[0054] The CM UI400 handles command execution using the Netconf interface and with the assistance of supported northbound modules / applications. The CM UI400 tracks real-time updates from one or more devices being upgraded. It provides visibility into end-to-end automation of use cases by providing logs, for example, to resolve upgrade issues using a debugging process. Planned upgrades can be identified and canceled within the CM UI400. A history of devices being upgraded is also presented.

[0055] CM UI400 supports single-device upgrades, where the upgrade is performed on a single device. The user provides upgrade details through the upgrade details input UI500 shown in Figure 5. Bulk device upgrades are similar to the single-device upgrade feature, but involve the selection of multiple devices and the bulk upgrade icon 450.

[0056] Real-time Information 460 provides real-time status of devices whose upgrades are scheduled / in progress. CM UI 400 automatically performs upgrades to transport layer devices without human intervention and provides real-time tracking data to address any issues that arise during the upgrade process. CM UI 400 provides visibility into end-to-end automation of use cases by providing logging for debugging purposes in case problems occur during the upgrade process. In this way, users are given improved visibility and control over the upgrade process using CM UI 400.

[0057] Planned upgrades can be canceled through the CM UI400. The CM UI also provides many pre-upgrade and post-upgrade check / verification activities that would normally require considerable effort using manual methods. The CM UI400 works with many types of transport layer devices and northbound modules, such as northbound modules that support Netconf applications. The CM UI400 communicates with devices to be upgraded using northbound-supported Netconf applications. For example, in at least one embodiment, the execution of automated commands provided by the CM UI400 is performed by the Netconf interface and northbound services.

[0058] Figure 5 shows an upgrade details input UI 500 according to at least one embodiment.

[0059] In Figure 5, the upgrade details input UI 500 is used to provide upgrade details. The current version 510 is pulled from the device to be upgraded. The current version 510 is shown as "6.5.2" 511. The new version 512 identifies the upgrade to provision for the device. The new version 512 is shown as "7.3.2" 513. The schedule date 520 and schedule time 522 provide the day and time to schedule the upgrade. The schedule date 520 is shown as "2022-10-01" 521, and the schedule time 522 is shown as "14:30" 523.

[0060] The MD5 checksum 530 is provided for the files selected by the user to perform the upgrade. The transit threshold 532 is related to network traffic verification, for example, to determine if network traffic has been stopped.

[0061] The new package name 540 identifies the name of the upgrade package to be used. In Figure 5, the new package name 540 is shown as "IOS-XR" 541. The current package name 542 identifies the name of the current configuration. In Figure 5, the current package name 542 is shown as "IOS-XR" 543. Other package names (e.g., "NX-OS", "IOS XE", etc.) may be displayed for both the new package name 540 and the current package name 542. For example, the upgrade may be from "IOS XR" to "IOS XE".

[0062] The filename 550 identifies the name of the upgrade file used for the upgrade. In Figure 5, the filename 550 is identified as "sampleFile" 551. The control relationship identifier (CR ID) 552 identifies the control relationship between the control point and the controller. In Figure 5, the CR ID 552 is identified as "sampleCR" 553.

[0063] The expected package list 560 is used to list packages that are candidates for upgrade. Sample packages are shown as "samplePackage" 562. Users can reject "samplePackage" 562 by clicking on "X" 564. Additional details and metadata can be selected or entered by clicking on additional SMU information 566.

[0064] After the upgrade details are entered on the upgrade details input UI 500, the user selects the save button 570. The upgrade begins, and progress information is displayed in real time on the CM UI 400 in Figure 4.

[0065] Figure 6 is a diagram of the upgrade history UI 600 according to at least one embodiment.

[0066] When an upgrade is selected in the CM UI400 in Figure 4, the upgrade history UI600 is displayed. The upgrade history UI600 provides upgrade history data for the device, allowing the user to determine how many times the device has been upgraded, when the device was upgraded, etc. For example, the upgrade history UI600 shows a device that has been upgraded twice.

[0067] Figure 6 shows the change history 610 for “ABC123xxxXY02” 612 in the network tree 614. The upgrade history UI 600 is identified as upgrade history 620. The upgrade history UI 600 can show the upgrade history of a device that includes multiple upgrades (e.g., 0-20 upgrades).

[0068] Window 630 includes columns for Status 631, Stage 632, NE ID 633, Upgrade Date / Time 634, Previous Version 635, and Upgraded Version 636. Window 630 shows a device with NE ID 633 of "ABC123xxxXY02" 612 that has undergone two upgrades 660, 670.

[0069] Upgrade 660 is the most recent upgrade history for “ABC123xxxXY02” 612 and has a warning status of 631 for 640. NE ID 632 is shown as “ABC123xxxXY02” 642. Upgrade time / day 633 is shown as “2022-10-01 03:05:01:00.0” 643. The upgrade and the associated version changes are shown. The previous version 634 is shown as “1.2.3” 644, and the upgraded version 635 is shown as “1.1.1” 645.

[0070] Upgrade 670 is the next upgrade history for "ABC123xxxXY02" 612, with status 631 of failure 650. NE ID 632 is shown as "ABC123xxxXY02" 652. Upgrade time / day 633 is shown as "2022-10-01 01:30:00:00.0" 653. Changes in upgrade 670 and associated versions are shown. Previous version 634 is shown as "1.2.3" 654, and upgraded version 635 is shown as "1.1.1" 655.

[0071] Selecting information icons 646 and 656 will display further details related to upgrades 660 and 670, respectively.

[0072] Figure 7 is a flowchart 700 of a method for merging regions according to at least one embodiment.

[0073] In Figure 7, the upgrade process begins, and one or more transport layer devices from the list of devices for upgrade are presented on the user interface UI (S710).

[0074] The selection of one or more transport layer devices is received via the UI from the device list for upgrade (S714). The selection of one or more devices includes logging on to one or more devices selected from the device list for upgrade, creating backups of one or more devices selected from the device list for upgrade, and stopping network traffic on one or more devices selected from the device list for upgrade.

[0075] Upgrade details for the upgrade of one or more transport layer devices selected from the device list are received via the UI (S718). The upgrade details include a schedule for initiating the upgrade of one or more transport layer devices. The user can cancel the upgrade of at least one of the one or more transport layer devices.

[0076] Based on the upgrade details, the upgrade of one or more transport layer devices is initiated (S722).

[0077] During the upgrade of one or more transport layer devices, real-time information returned from one or more transport layer devices is presented on the UI (S726). The real-time information includes status changes and logs, identification of configuration conflicts, and the status of configuration parameters, associated with one or more devices selected from the device list for upgrade. The real-time information also includes alarms for at least one of the one or more transport layer devices in response to a mismatch detected between the pre-upgrade and post-upgrade configurations. The user can provide input to roll back the post-upgrade configuration of at least one of the one or more transport layer devices associated with an alarm to the pre-upgrade configuration.

[0078] Upgrades of one or more transport layer devices are validated based on real-time information (S730). Validation includes receiving a selection of failed devices identified as having failed upgrades based on real-time information, and displaying the upgrade history associated with the failed devices.

[0079] The upgrade process is completed, but it can be repeated (S740).

[0080] At least one embodiment of a method for providing automated software upgrades for transport layer devices includes: receiving a selection of one or more transport layer devices from a device list for upgrade on a user interface (UI); receiving upgrade details for the upgrade of the one or more transport layer devices selected from the device list for upgrade via the UI; initiating the upgrade of the one or more transport layer devices based on the upgrade details; presenting real-time information returned from the one or more transport layer devices on the UI during the upgrade of the one or more transport layer devices; and verifying the upgrade of the one or more transport layer devices based on the real-time information.

[0081] Figure 8 is a high-level functional block diagram of a processor-based system 800 according to at least one embodiment.

[0082] In at least one embodiment, processing circuit 800 provides an automated software upgrade for a transport layer device. Processing circuit 800 implements the automated software upgrade for the transport layer device using a processor 802. Processing circuit 500 also includes a non-transient computer-readable storage medium 804 used to implement the automated software upgrade for the transport layer device. The storage medium 804 is, in particular, encoded with an instruction 806 (i.e., computer program code executed by the processor 802) that causes the processor 802 to perform an operation to provide the automated software upgrade for the transport layer device (i.e., it stores the instruction 806). The execution of the instruction 806 by the processor 802 represents (at least in part) an application that implements at least a portion of the method described herein (hereinafter referred to as process and / or method) according to one or more embodiments.

[0083] The processor 802 is electrically coupled to the computer-readable storage medium 804 via the bus 808. The processor 802 is electrically coupled to the input / output (I / O) interface 810 via the bus 808. The network interface 812 is also electrically connected to the processor 802 via the bus 808. The network interface 812 is connected to the network 814, and the processor 802 and the computer-readable storage medium 804 can be connected to external elements via the network 814. The processor 802 is configured to execute instructions 806 encoded in the computer-readable storage medium 804 so that the processing circuit 800 can be used to execute at least a portion of a process and / or method. In one or more embodiments, the processor 802 is a central processing unit (CPU), a multiprocessor, a distributed processing system, an ASIC (Application Specific Integrated Circuit), and / or a suitable processing unit.

[0084] The processing circuit 800 includes an I / O interface 810. The I / O interface 810 is coupled to an external circuit. In one or more embodiments, the I / O interface 810 includes a keyboard, keypad, mouse, trackball, trackpad, touchscreen, and / or cursor directional keys for transmitting information and commands to the processor 802.

[0085] The processing circuit 800 also includes a network interface 812 coupled to the processor 802. The network interface 812 enables the processing circuit 800 to communicate with a network 814 to which one or more other computer systems are connected. The network interface 812 includes wireless network interfaces such as Bluetooth, Wi-Fi, Worldwide Interoperability for Microwave Access (WiMAX), General Packet Radio Service (GPRS), or Wideband Code Division Multiple Access (WCDMA), or wired network interfaces such as Ethernet, Universal Serial Bus (USB), or Institute of Electrical and Electronics Engineers (IEEE) 864.

[0086] The processing circuit 800 is configured to receive information through the I / O interface 810. The information received through the I / O interface 810 includes one or more instructions, data, design rules, cell libraries, and / or other parameters for processing by the processor 802. The information is transferred to the processor 802 via the bus 808. The processing circuit 800 is also configured to receive information about the user interface (UI) through the I / O interface 810.

[0087] In one or more embodiments, one or more non-temporary computer-readable storage media 804 store (in compressed or uncompressed form) instructions used to program a computer, processor, or other electronic device to perform the processes or methods described herein. One or more non-temporary computer-readable storage media 804 include one or more electronic storage media, magnetic storage media, optical storage media, quantum storage media, etc.

[0088] For example, computer-readable storage media include, but are not limited to, hard drives, floppy disks, optical discs, read-only memory (ROM), random access memory (RAM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory, magnetic or optical cards, solid-state memory devices, or other types of physical media suitable for storing electronic instructions. In one or more embodiments using optical discs, one or more non-temporary computer-readable storage media 804 include compact disk read-only memory (CD-ROM), compact disk read / write (CD-R / W), and / or digital video discs (DVD).

[0089] In one or more embodiments, the storage medium 804 stores computer program code 806 configured to cause a processing circuit 800 to execute at least a portion of a process and / or method for providing an automated software upgrade for a transport layer device. In one or more embodiments, the storage medium 804 also stores information such as algorithms that facilitate the execution of at least a portion of the process and / or method for providing an automated software upgrade for a transport layer device. Thus, in at least one embodiment, the processor circuit 800 executes a method for providing an automated software upgrade for a transport layer device.

[0090] The process for providing automated software upgrades for transport layer devices includes: receiving the selection of one or more transport layer devices from a device list for upgrade on the user interface (UI); receiving upgrade details for the upgrade of one or more transport layer devices selected from the device list via the UI; initiating the upgrade of one or more transport layer devices based on the upgrade details; presenting real-time information returned from one or more transport layer devices on the UI during the upgrade of one or more transport layer devices; and verifying the upgrade of one or more transport layer devices based on the real-time information.

[0091] A process for providing automated software upgrades for transport layer devices offers at least the benefits of saving time, reducing costs and expenses, and simplifying the management of the upgrade process. Manual efforts to upgrade devices, even with the use of scripts, are cumbersome tasks. A CM UI also allows for the saving of human resources and reduces human errors that can occur when performing upgrades.

[0092] Other instances of these programs may be executed on or distributed across any number of other computer systems. Thus, although certain steps are described as being performed by a specific device, software program, process, or entity, this is not required. Various alternative implementations will be understood by those skilled in the art.

[0093] In addition, those skilled in the art will readily recognize that the aforementioned technologies are applicable to a variety of devices, environments, and situations. Although embodiments have been described in terms specific to structural features or methodological actions, the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described. Rather, specific features and actions are disclosed as exemplary forms that implement the claims.

Claims

1. A method for providing an automated software upgrade for a transport layer device by computer, On the user interface (UI), the system accepts the selection of multiple transport layer devices from a list of devices for upgrade, Through the UI, the system receives upgrade details for the upgrade of the multiple transport layer devices selected from the device list for the upgrade, Based on the upgrade details, in order to initiate the upgrade of the plurality of transport layer devices, generate instructions according to the interface types supported by the plurality of transport layer devices selected from the device list, In accordance with the generated instructions, the upgrades of each of the multiple transport layer devices are to be initiated simultaneously with each other, On the UI, during the upgrade of each of the multiple transport layer devices, real-time information returned from the multiple transport layer devices is presented. The upgrade of each of the aforementioned multiple transport layer devices is verified based on the real-time information, A method for providing this.

2. The method according to claim 1, wherein presenting the real-time information includes receiving status changes and logs associated with the plurality of transport layer devices selected from the device list for upgrade.

3. Presenting the aforementioned real-time information means In response to detecting a mismatch between the pre-upgrade configuration and the post-upgrade configuration, an alarm is displayed for at least one of the multiple transport layer devices. Receiving input to roll back the upgraded configuration of at least one of the multiple transport layer devices associated with the alarm to the pre-upgrade configuration, The method according to claim 2, including the method described in claim 2.

4. Receiving the selection of the plurality of transport layer devices means that To log on to the multiple transport layer devices selected from the device list for the upgrade, To create backups of the multiple transport layer devices selected from the device list for the upgrade, To stop network traffic on the multiple transport layer devices selected from the device list for the upgrade, The method according to claim 1, including the method described in claim 1.

5. Based on the aforementioned real-time information, receive a selection of failed devices identified as having failed the upgrade, Display the upgrade history associated with the aforementioned failed device, The method according to claim 1, further comprising:

6. The method according to claim 1, wherein receiving upgrade details for the upgrade of the plurality of transport layer devices includes receiving a schedule for initiating the upgrade of the plurality of transport layer devices.

7. The method according to claim 6, wherein receiving the schedule for initiating the upgrade of the plurality of transport layer devices includes receiving the cancellation of the upgrade of at least one of the plurality of transport layer devices.

8. A device for performing automated software upgrades on transport layer devices, On the user interface (UI), the system accepts the selection of multiple transport layer devices from a list of devices for upgrade, Through the UI, the system receives upgrade details for the upgrade of the multiple transport layer devices selected from the device list for the upgrade, Based on the upgrade details, in order to initiate the upgrade of the plurality of transport layer devices, generate instructions according to the interface types supported by the plurality of transport layer devices selected from the device list, In accordance with the generated instructions, the upgrades of each of the multiple transport layer devices are to be initiated simultaneously with each other, On the UI, during the upgrade of each of the multiple transport layer devices, real-time information returned from the multiple transport layer devices is presented. The upgrade of each of the aforementioned multiple transport layer devices is verified based on the real-time information, A device configured to perform an action.

9. The device according to claim 8, further configured to perform the task of presenting the real-time information by presenting the changes in state and logs associated with the plurality of transport layer devices selected from the device list for an upgrade.

10. In response to detecting a mismatch between the pre-upgrade configuration and the post-upgrade configuration, an alarm is displayed for at least one of the multiple transport layer devices. Receiving input to roll back the upgraded configuration of at least one of the multiple transport layer devices associated with the alarm to the pre-upgrade configuration, Further configured to perform the presentation of the aforementioned real-time information, The device according to claim 9.

11. To log on to the multiple transport layer devices selected from the device list for the upgrade, To create backups of the multiple transport layer devices selected from the device list for the upgrade, To stop network traffic on the multiple transport layer devices selected from the device list for the upgrade, Further configured to receive the selection of the plurality of transport layer devices, The device according to claim 8.

12. Based on the aforementioned real-time information, receive a selection of failed devices identified as having failed the upgrade, Display the upgrade history associated with the aforementioned failed device, Further configured to perform, The device according to claim 8.

13. The device according to claim 8, further configured to receive upgrade details for the upgrade of the plurality of transport layer devices by receiving a schedule for initiating the upgrade of the plurality of transport layer devices.

14. The device according to claim 13, further configured to receive the schedule for initiating the upgrade of the plurality of transport layer devices by receiving the cancellation of the upgrade of at least one of the plurality of transport layer devices.

15. When it is executed, On the user interface (UI), the system accepts the selection of multiple transport layer devices from a list of devices for upgrade, Through the UI, the system receives upgrade details for the upgrade of the multiple transport layer devices selected from the device list for the upgrade, Based on the upgrade details, in order to initiate the upgrade of the plurality of transport layer devices, generate instructions according to the interface types supported by the plurality of transport layer devices selected from the device list, In accordance with the generated instructions, the upgrades of each of the multiple transport layer devices are to be initiated simultaneously with each other, On the UI, during the upgrade of each of the multiple transport layer devices, real-time information returned from the multiple transport layer devices is presented. The upgrade of each of the aforementioned multiple transport layer devices is verified based on the real-time information, A non-temporary computer-readable medium containing computer-readable instructions for performing operations that include the following:

16. The non-temporary computer-readable medium according to claim 15, wherein the presentation of the real-time information includes receiving status changes and logs associated with the plurality of transport layer devices selected from the device list for upgrade.

17. Presenting the aforementioned real-time information means In response to detecting a mismatch between the pre-upgrade configuration and the post-upgrade configuration, an alarm is displayed for at least one of the multiple transport layer devices. Receiving input to roll back the upgraded configuration of at least one of the multiple transport layer devices associated with the alarm to the pre-upgrade configuration, A non-temporary computer-readable medium according to claim 16, including the following:

18. Receiving the selection of the plurality of transport layer devices means that To log on to the multiple transport layer devices selected from the device list for the upgrade, To create backups of the multiple transport layer devices selected from the device list for the upgrade, To stop network traffic on the multiple transport layer devices selected from the device list for the upgrade, A non-temporary computer-readable medium according to claim 15, including the following:

19. Based on the aforementioned real-time information, receive a selection of failed devices identified as having failed the upgrade, Display the upgrade history associated with the aforementioned failed device, A non-temporary computer-readable medium according to claim 15, further comprising:

20. The non-temporary computer-readable medium according to claim 15, wherein receiving upgrade details for the upgrade of the plurality of transport layer devices includes receiving a schedule for initiating the upgrade of the plurality of transport layer devices.

Images