Optimum software update transmission parameters are determined and used for transmitting a software update from a host to servers of a computer network. The software update is transmitted while the servers are live and required to meet certain quality of service requirements for tenants of the computer network. Transmission parameters for transmitting the software update are adjusted and updated based on service performance data. Based on iterative adjustments, optimum transmission parameters may be determined. Additionally or alternatively, machine learning is used to generate a model that determines predicted optimum transmission parameters. The predicted optimum transmission parameters may be initially used for transmitting a software update, while the transmission parameters continue to be adjusted throughout transmission.

Data is received describing a local model of a first device generated by the first device based on sensor readings at the first device and a global model is updated that is hosted remote from the first device based on the local model and modeling devices in a plurality of different asset taxonomies. A particular operating state affecting one or more of a set of devices deployed in a particular machine-to-machine network is detected and the particular machine-to-machine network is automatically reconfigured based on the global model.

Data is received describing a local model of a first device generated by the first device based on sensor readings at the first device and a global model is updated that is hosted remote from the first device based on the local model and modeling devices in a plurality of different asset taxonomies. A particular operating state affecting one or more of a set of devices deployed in a particular machine-to-machine network is detected and the particular machine-to-machine network is automatically reconfigured based on the global model.

Systems, methods and/or computer program products optimizing network policies between microservices of a service mesh. The service mesh tracks incoming API calls of applications and based on the historical transactions, the context of API calls, and the microservices in the microservice chain being invoked, network controls and policy configurations are set to optimize the transactions performed by the service mesh. Dimensions of the communications between microservices of the service mesh are dynamically optimized via the service mesh control plane using a policy optimizer. Optimized dimensions of service mesh transactions includes automated policy adjustments to retries between microservices, circuit breaking between microservices, automated timeout adjustments between microservices and intelligent rate limiting between microservices and/or rate limiting applied to user profiles.

Systems, software, and methods for managing networks of connected electronic devices are described. In one example, network management policy and network management applications are transferred automatically upon detection and identification of a new device, protocol or application on the network. In another example, information related to at least one aspect of the network is obtained by an NMAS, and at least one applicable management policy is identified by the NMAS; and the identified policy is used to manage at least one aspect of the network's operation.

Systems, software, and methods for managing networks of connected electronic devices are described. In one example, network management policy and network management applications are transferred automatically upon detection and identification of a new device, protocol or application on the network. In another example, information related to at least one aspect of the network is obtained by an NMAS, and at least one applicable management policy is identified by the NMAS; and the identified policy is used to manage at least one aspect of the network's operation.

Disclosed herein are enhancements for deploying application in an edge system of a communication network. In one implementation, a runtime environment identifies a request from a Hypertext Transfer Protocol (HTTP) accelerator service to be processed by an application. In response to the request, the runtime environment may identify an isolation resource to support the request, initiate execution of code for the application, and pass context to the code. Once initiated, the runtime environment may copy data from the artifact to the isolation resource using the context and return control to the HTTP accelerator service upon executing the code.

Methods, systems, and devices are provided herein for a mechanism to identify link down reasons. As described herein, a first port of a first peer device may be determined to have unexpectedly changed to a port down state. Subsequently, a topology file may be referenced to identify a second port of a second peer device with which the first peer device is intended to have a link if not for the first port being in a port down state. In some examples, port settings of the first port may be compared with port settings of the second port. If a port setting for the first port mismatches an associated port setting for the second port, an alert message may be transmitted to a network administrator indicating this mismatch as a possible reason for the first port being in the port down state.

A plurality of virtual internet protocol addresses for a first single network interface card of a node of a storage cluster are provided to a client. A separate connection is established between the client and the node for each of the plurality of virtual internet protocol addresses. The separate connections are utilized together in parallel to transfer data between the client and the node.

To provide a low latency near RT RIC, some embodiments separate the RIC's functions into several different components that operate on different machines (e.g., execute on VMs or Pods) operating on the same host computer or different host computers. Some embodiments also provide high speed interfaces between these machines. Some or all of these interfaces operate in non-blocking, lockless manner in order to ensure that critical near RT RIC operations (e.g., datapath processes) are not delayed due to multiple requests causing one or more components to stall. In addition, each of these RIC components also has an internal architecture that is designed to operate in a non-blocking manner so that no one process of a component can block the operation of another process of the component. All of these low latency features allow the near RT RIC to serve as a high speed IO between the E2 nodes and the xApps.