METHODS AND EQUIPMENT FOR IMPROVING RADIO ACCESS NETWORKS IN COMMUNICATION SYSTEMS

Abstract

A pre-5th generation (5G) or 5G communications system to support higher data rates beyond 4th generation (4G) communications systems such as long term evolution (LTE). Methods and / or electronic means for managing software upgrades of network elements of a random access network (RAN) by a management data analysis service (MDAS) producer are provided. The method includes: receiving a request related to an optimal time for a software upgrade of a network element in a RAN, from a MDAS consumer; identifying information related to a dedicated radio carrier (DRB); identifying information related to an optimal time for a software upgrade of the network element based on information related to the DBR; and sending a report including information related to the optimal time for the software upgrade of the network element.

Description

Description METHODS AND EQUIPMENT FOR IMPROVING RADIO ACCESS NETWORKS IN COMMUNICATION SYSTEMS Field of Invention Engineering Embodiments herein relate to upgrading a radio access network (RAN), and more particularly to methods and apparatus for upgrading virtual RAN node software of a 5th generation (5G) communications network using management data analysis services (MDAS). Background of the Invention To meet the increasing demand for wireless data traffic since the deployment of the 4th generation (4G) communication system, efforts have been made to develop better 5G or pre-5G communication systems. Therefore, these 5G or pre-5G communication systems are also called 'beyond 4G networks' or 'post-LTE systems'. The 5G communication system is assumed to be implemented in higher frequency bands (mmWave), for example, 60GHz band, thus achieving higher data rates. In order to reduce the radio wave propagation loss and increase the transmission distance, beamforming, massive multiple input multiple output (MIMO), full-dimensional MIMO (FD-MIMO), array antenna, analog beamforming, large-scale antenna techniques are discussed in the 5G communication system. In addition, in the 5G communication system, developments for system network enhancement are being carried out based on advanced small cells, cloud radio access networks (RANs), ultra-dense networks, device-to-device (D2D) communications, wireless network routing, mobile networks, cooperative communications, coordinated multi-point (CoMP), receiving-end interference cancellation and the like. In 5G systems, hybrid FSK and QAM (FQAM) modulation and sliding window superposition coding (SWSC) as advanced coding modulation (ACM), and filter bank multi-carrier (FBMC), non-orthogonal multiple access (NOMA), and cavity code multiple access (SCMA) as advanced access technologies have been developed. A telecommunications network element may include a number of software blocks. These software blocks need to be upgraded periodically to fix bug related issues and introduce new features in the telecommunications network element. A telecommunications network operator tends to trigger software upgrades of certain software blocks or telecommunications network elements at night, which requires manual intervention. The requirement for manual intervention can be overwhelming for telecommunications network operators, as manual intervention requires having dedicated personnel on standby to check whether the current traffic conditions are likely to trigger a software upgrade. Since software upgrades will disrupt service availability, it is necessary to ensure that such traffic is minimal during software upgrades. In-service software upgrades allow network operators to address software bugs and add new features to telecommunications network elements without disrupting network availability. Although in-service software upgrades are preferred, implementing an in-service software upgrade on a telecommunications network element requires introducing changes to the telecommunications network element. Brief Description of the Invention Technical Issues Various example embodiments disclose methods and / or apparatus for providing a machine learning (ML) model for estimating optimal timestamps for enhancing the software of a virtual network element of a 5G network based on an analysis of parameters relating to traffic conditions of the virtual network element of the 5G network. Various example embodiments enable automatic software updates of virtual network elements by integrating ML models with cloud management systems (CMS) such as network function virtualization management and network orchestration (NFV MANO). Various example embodiments generate a bearer information analysis report (BIAR), with an ML model, upon receiving a request from an NFV MANO to provide an optimal timestamp for upgrading the software of a virtual network element, wherein the request specifies at least one target virtual network element and a reporting interval, at which said NFV MANO initiates the software upgrade of the at least one target virtual network element, based on the BIAR. Various example embodiments generate BIAR reports based on data traffic associated with different bearer types, wherein the data traffic is aggregated from at least one target virtual network element in the 5G network. Various example embodiments provide a BIAR report to the NFV MANO to enable the NFV MANO to trigger a software upgrade of at least one target virtual network element at a predicted optimal time moment. Various example embodiments maintain contextual information relating to a carrier connecting at least one user equipment (UE) to at least one target virtual network element, wherein the contextual information is maintained for a predetermined period of time and verified after the upgrade is complete. According to an embodiment of the present invention, a method for managing a software upgrade of a network element of a radio access network (RAN) by a managing data analysis service (MDAS) producer is provided. The method may include receiving a request related to an optimal time for a software upgrade of a network element in the RAN, from an MDAS consumer. The method may include identifying information related to a specific radio bearer (DRB). The method may include identifying information related to an optimal time for a software upgrade of the network element based on information related to the DBR. The method may include sending a report that includes information related to an optimal time for a software upgrade of the network element. According to an embodiment of the present invention, a manufacturer's data management analysis service (MDAS) electronic device for managing software upgrades of network elements of a radio access network (RAN) is provided. The electronic device may include memory, and at least one processor coupled to the memory. The at least one processor may be configured to receive a request relating to an optimal time for a software upgrade of a network element in the RAN. The at least one processor may be configured to identify information relating to a specific radio carrier (DRB). The at least one processor may be configured to identify information relating to an optimal time for a software upgrade of a network element based on information relating to the DBR.At least one processor may be configured to send a report that includes information related to the optimal timing for upgrading network element software. According to an embodiment of the present invention, a non-transient computer-readable storage medium that stores program code that, when executed by at least one processor of a manufacturer's electronic device (MDAS) for managing software upgrades of network elements of a radio access network (RAN), causes the electronic device to perform operations is provided. The operations may include receiving a request related to an optimal time for a software upgrade of a network element in the RAN, from a consumer of the MDAS. The operations may include identifying information related to a specific radio bearer (DRB). The operations may include identifying information related to an optimal time for a software upgrade of a network element based on information related to the DBR.Such operations may include sending reports that include information related to the optimal timing for network element software upgrades. These and other aspects of the embodiments herein will be better appreciated and understood when considered in conjunction with the following description and accompanying drawings. However, it should be understood that the following description, while showing the embodiments and many of their specific details, is provided by way of illustration and not limitation. Many changes and modifications may be made within the scope of the embodiments herein without departing from the essence thereof, and the embodiments herein include all such modifications. Short Description of Image The above and other aspects, features and advantages of certain exemplary embodiments will become clearer from the following detailed descriptions, taken together with the accompanying drawings, wherein: Figure 1 illustrates the central unit-control plane (CU-CP) and central unit-user plane (CU-UP) interfaces for exemplary embodiments; Figure 2 illustrates the various components of a CU-CP for an example embodiment; Figure 3 illustrates the various components of a CU-UP for an example embodiment; Figure 4 depicts the components of a network function virtualization (NFV) framework, which virtualizes the network functions of a 5G radio access network (RAN) node for an example embodiment; Figure 5 is a sequence diagram illustrating the CU-CP enhancement mechanism present for an example embodiment; Figure 6 is a block diagram illustrating the processes involved in software enhancement of the network functionality of a 5G virtual network RAN, according to various example embodiments; Figure 7 is a sequence diagram illustrating the information flow involved in the automatic upgrade of network functionality software of a network element of a 5G virtual RAN, according to various example embodiments; Figure 8 illustrates components of an example machine learning (ML) model used to estimate optimal timestamps for enhancing virtual network elements of a 5G virtual RAN, according to various example embodiments; Figure 9 is a sequence diagram illustrating the CU-CP software upgrade at an estimated optimal timestamp, according to an embodiment as disclosed herein; and Figure 10 is a flowchart illustrating a method for upgrading virtual network element software of a virtual RAN of a 5G network using management data analytics services (MDAS), according to various example embodiments. Full Description of the Invention The exemplary embodiments herein and their various advantageous features and details are more fully explained by reference to the non-limiting embodiments illustrated in the accompanying drawings and detailed in the following description. Descriptions of known components and processing techniques are omitted so as not to unnecessarily obscure the embodiments herein. The examples used herein are intended only to facilitate an understanding of the manner in which the embodiments herein may be practiced and to further enable one skilled in the invention to practice the embodiments herein. Accordingly, the examples should not be construed as limiting the scope of the embodiments herein. The 5G RAN architecture is divided into two functional units, namely, distributed unit (DU) and central unit (CU). There is also a separation of the control plane (CP) and user plane (UP) of the CU. Therefore, the CU includes CU-CP and CU-UP. Figure 1 illustrates the CU-CP and CU-UP interfaces for example embodiments. As depicted in Figure 1, the CU-CP (110) and the CUUP (130) can be connected, directly or indirectly, to each other using a point-to-point link using the E-1 interface. The E-1 interface separates the radio network layer from the transport network layer. The E-1 interface supports the exchange of information between the CU-CP (110) and the CU-UP (130). Such information may be information related to user (EU) or non-EU equipment. Figure 2 illustrates the various components of a CU-CP for an example embodiment. As depicted in Figure 2, the CU-CP (110) includes three components, namely, a CU-CP management component (CU-CPMC) (210), a CU-CP interface component (CU-CP-IC) (230), and a CU-CP processing component (CU-CP-PC) (250). The CU-CP-MC (210) includes all configurable databases and operational databases. The CU-CP-MC (210) may further include performance data and error-related data. The CU-CP-IC (230) may be configured to manage interfaces connected to external components and the CU-CP-PC(s) (250). The CU-CPPC (250) may be configured to process and fulfill all control plane related requests, such as handling all RRC related requests. Figure 3 illustrates the various components of a CU-UP for an example embodiment. As shown in Figure 3, the CU-UP (130) includes at least three components, namely, a CUUP management component (CU-UP-MC) (310), a CU-UP interface component (CU-UP-IC) (330), and a CU-UP processing component (CU-CP-PC) (350). The CU-UP-MC (310) includes all configurable databases and operational databases. The CU-UP-MC (310) may further include performance data and error-related data for a particular CU-UP. The CU-UP-IC (330) may be configured to manage interfaces connected to external components and CU-UP-PC(s). The CU-UP-PC (350) may be configured to process and fulfill all user-area related requests such as UE and DRB-related processing. The CU-CP (110) is manually powered off to undergo critical maintenance for a very short duration. The software upgrade of the CU-CP can be a critical maintenance scenario. At this time, during the software upgrade procedure, the CU-CP (110) causes all bearers associated with the UEs to be released. The resources managed by the CU-CP (110) (which is powered off) for bearer functions, security functions, mobility management functions, and so on, need to be cleaned up during the software upgrade procedure. The CUCP (110) sends an E-1 reset message to the CU-UP (130). Upon receiving the E-1 reset message, the CU-UP (130) releases all UEs and their associated dedicated radio bearers (DRBs). The DRBs are reconfigured on another CU-CP (standby CU-CP). The CU-CP (110) attaches the UEs to the standby CU-CP (considered active during the software upgrade procedure). The DRBs are reconfigured again when the previous CU-CP comes up (now upgraded). The upgraded CU-UP can reattach the DRBs to the UEs during the reattachment procedure in the CU-CP (110). This results in the re-establishment of all DRBs. The detachment and (re)attachment of DRBs causes significant service impact (in terms of service disruption) and operational impact (in terms of operational costs). The CU in the 5G RAN Node system can be a virtualized RAN CU Node, which is installed in the market data center (MDC) or edge data center (EDC). The RAN CU Node can process the radio resource control (RRC) layer functionality and packet data convergence protocol (PDCP). The virtualization of the CU improves the scalability of the 5G system and facilitates the operation of the CU. The virtualization can be a virtualization technology implemented on a network function virtualization (NFV) platform. Figure 4 illustrates the components of an NFV framework that virtualizes 5G RAN node network functions for an example embodiment. As depicted in Figure 4, the NFV framework includes network management and orchestration (MANO) (450), virtualized network functions (VNFs) (410), and NFV infrastructure (NFVI) (430). The CU-CP (401) and CU-UP (403, 405) can be implemented as VNFs (410), which can be scaled independently based on traffic volume. The CU-CP (401) can process RRC and PDCP-C (PDCPControl) signaling messages. The CU-UP (403, 405) can process packet data related to the GPRS (general packet radio service) tunneling protocol (GTP) and packet data related to PDCP. The VNFs (410) may run on Virtual Machines (VMs), and perform specific network functions of the 5G CU RAN and 5G DU RAN nodes. Therefore, the VNFs (410) may be considered as virtual CU RAN nodes. For example, consider the VNFs (410) that perform the CU-CP network function (401) running on VM-1, VM-2, VM-3, and VM-4. Note that the CU-UP is divided into CU-UP1 (403) and CU-UP2 (405). The VNFs (410) that perform the CU-UP1 network function (403) running on VM-5, VM-6, and VM-7. The VNFs (410) that perform the CU-UP2 network function (405) running on VM-8, VM-9, and VM-10. The network functions CU-CP (401) and CU-UP (403, 405) are installed by loading VNFs (410) that perform specific network functions on the VMs. Therefore, VNFs (410) corresponding to the CU-CP network functions (401) are upgraded during the CU-CP software upgrade. The MANO (450) may include a management data analysis function (MDAF) (451), an NFV orchestrator (NFVO) (453), a virtualized network function manager (VNFM) (455), a virtualized infrastructure manager (VIM) (457) and a physical infrastructure manager (PIM) (459). A virtualized system manager (VSM) provides management functions to operate and maintain the RAN CU-Nodes and RAN DU-Nodes. In addition, the VSM provides a north interface for interoperability of the operations support system (OSS). The VSM interfaces with the VNFM (455), which is responsible for managing VNF software management functions such as loading VNF and VNF enhancement. The VIM (457) may manage virtual resources of the NFVI (430), for example, virtual computing, virtual storage, and virtual networking. The PIM (459) may manage hardware resources of the NFVI (430), for example, computing hardware, storage hardware, and networking hardware. Figure 5 is a sequence diagram illustrating the existing CU-CP upgrade mechanism for an example embodiment. As depicted in Figure 5, the Active CU-CP (510) is the CU-CP that needs to be upgraded. The UEs are connected to the Active CU-CP (510) via DRBs. Since the CU-CP is a virtualized RAN-CU node, the VIM (590) is involved in the software upgrade of the CU-CP. When the Active CU-CP (510) is upgraded, the UEs can connect to the standby CU-CP (530). After the UEs connect to the standby CU-CP (530), the standby CU-CP (530) becomes the Active CU-CP (510). The software upgrade procedure can be triggered by the NFVO (570). The NFVO graphical user interface (NFVO GUI) can inspect the packet details of the VNFs that function as CU-CPs (performing the network functions of the CU-CP). The VNFs that function as CU-CPs can be considered as the Active CU-CPs (510). If the NFVO (570) determines that the CU-CP needs to be upgraded at step 501, the NFVO (570) may send a VNF upgrade request to the VNFM (550) at step 503. Since the VNFM (550) manages the VNF software management functions, the VNFM (550) may forward the VNF upgrade request to the Active CU-CP (510) at step 505. The Active CU-CP (510) may generate an upgrade sequence and track the upgrade sequence. The upgrade sequence is the sequence in which different components of the CU-CP need to be updated. For example, the update sequence may be CU-CP-MC, followed by CU-CP-IC, followed by CU-CP-PC. The Active CU-CP (510) may send an upgrade sequence to the VNFM (550) in step 507. The VNFM (550) may forward the Active CU-CP upgrade sequence to the NFVO (570) in step 509. The Active CU-CP upgrade begins after the Active CU-CP (510) sends an upgrade sequence to the VNFM (550). The UEs attached to the Active CU-CP (510) are released and the DRBs connecting the UEs to the Active CU-CP (510) are cleared in step 511. When the DRBs are cleared, a switchover event occurs in step 513, where the UEs are connected to the Standby CU-CP (530) in step 515. The VIM (590) may send new VNF packets, for the upgrade of CU-CP-MC, CU-CP-IC, and CU-CP-PC, to the Active CU-CP (510), via file transfer protocol (FTP) in step 517. The DRBs are reconfigured at the Standby CU-CP (530), which becomes the Active CU-CP (510) during a software upgrade procedure in step 519. The DRBs can be reconfigured again with the previous (previously Active) CU-CP when the previous (previously Active) CU-CP is upgraded with a new VNF package. The upgraded (previously Active) CU-CP can reattach the DRBs with the UEs during the reattachment procedure at the upgraded CU-CP. The CU-CP upgrade causes data loss and operational loss because the DRBs need to be reconfigured at the Standby CU-CP (530) and reattached to the Active CU-CP (510) (after the upgrade). And the Standby CU-CP (530) can create SRBs in step 521. Embodiments herein disclose methods and apparatus for upgrading the software of a 5G virtual radio access network (RAN) element using management data analysis services (MDAS).The software upgrade is performed at an optimal timestamp within an optimal time window, where the optimal timestamp is estimated based on an analysis of parameters related to the traffic conditions of the virtual network element. Example embodiments may include generating, using a machine learning (ML) model, a bearer information analysis report (BIAR), upon receiving a request, from the network function virtualization management and network orchestration (NFV MANO), to provide an optimal timestamp for upgrading the virtual network element software. The estimated optimal timestamp is included in the BIAR and provided to the NFV MANO. The NFV MANO can determine whether an optimal timestamp, estimated based on parameters related to the traffic conditions of the virtual network element, is suitable for triggering a software upgrade of the virtual network element. The indication is based on conditions, which can be determined based on BIAR. The NFV MANO initiates a software upgrade of the virtual network element at an optimal timestamp, included in the BIAR, determined accordingly based on those conditions. The virtual network element may retain contextual information relating to a bearer, which connects at least one user equipment (UE) to the virtual network element, prior to the initiation of the software upgrade. The virtual network element may retain the contextual information for a predetermined period of time. The virtual network element verifies the bearer after the software upgrade has been successfully completed. Now referring to the drawings, and more particularly to Figures 6 through 10, wherein similar reference characters indicate corresponding features consistently throughout the drawings, various exemplary embodiments are shown. Each embodiment herein may be used in combination with any of the other embodiments described herein. Figure 6 is a block diagram illustrating the process involved in upgrading the network functionality software of a 5G virtual network RAN, according to embodiments as disclosed herein. Such embodiments may upgrade the network functionality software of certain virtual network elements of the 5G virtual RAN. In one embodiment, the network functionality software of a virtual network element of a 4th generation (4G) network or a 6th generation (6G) network may be upgraded using such a process. For example, if the virtual network element to be upgraded is a CU-CP, then the CU-CP functionality software may be upgraded. In an embodiment, the software upgrade may be performed based on parameters related to data traffic in the 5G network. The software upgrade procedure may be assisted by an MDAS (603), which is a component of the NFV MANO. The MDAS (603) may be requested to perform the software upgrade by an NFVO (605), which is also a component of the NFV MANO. The MDAS (603) may provide an estimated schedule to the NFVO (605) to initiate the software upgrade of the virtual network element in the 5G virtual RAN (611). In one embodiment, the software upgrade procedure is assisted by a traffic classifier (601) and an MDAS (603). In one embodiment, the traffic classifier (601) and the MDAS (603) may be part of an element management system (EMS) (609). The traffic classifier (601) collects data relating to traffic conditions in the 5G virtual RAN (611). Such data may include parameters relating to handover, carrier condition, carrier type, error recovery, and the like. Based on the data collected by the traffic classifier (601), the MDAS (603) may determine whether the current moment in time is suitable for performing the software upgrade. The MDAS (603) may also estimate a future moment in time that is suitable for performing the software upgrade of the network elements of the 5G virtual RAN (611). The MDAS (603) may send a suitable future time moment to perform a software upgrade of a network element of the 5G virtual RAN (611) to the NFVO (605). The MDAS (603) may collaborate with the NFVO (605) to validate whether the software upgrade needs to be performed at a suitable future time. The accuracy of the estimation of a suitable future time moment to perform the software upgrade may be improved through collaboration. If the NFVO (605) is inclined to initiate a software upgrade procedure, the NFVO (605) may send a VNF upgrade request to the VNFM (607). The VNFM (607) may forward the upgrade request to the 5G virtual RAN (611) or the network element of the 5G virtual RAN (611) that needs to be upgraded. The network element of the 5G virtual RAN (611) may initiate a software upgrade. Example embodiments may include maintaining a bearer state or context that connects UEs to the network element of the 5G virtual RAN (611). The network element of the 5G virtual RAN (611) may be loaded with a new VNF packet. The bearer may be validated by the network element of the 5G virtual RAN (611) to ensure that the software upgrade was successful. Figure 7 is a sequence diagram illustrating the information flow involved in the automatic software upgrade of network functionality of a network element of a 5G virtual RAN, according to an embodiment as disclosed herein. For example, the network element (703) to be updated is a CU-CP. Part of (703), wherein the network element (703) is The 5G virtual RAN network element is located, which may be a next generation Node B (gNB). The software upgrade of the network functionality of the CU-CP may be triggered automatically. In an embodiment, the MDAS consumer (702) may subscribe to a carrier info analysis report (BIAR) from the MDAS producer (701), which will include a circuit, in step 711. The MDAS consumer (702) may be an NFV MANO (NFVO of NFV MANO), and may include a circuit. The MDAS producer (701) is an MDAS (see FIG. 6), which is provided by the management data analysis function (MDAF) located in the EMS. The BIAR may include parameters that enable the MDAS consumer (702) to determine whether a software upgrade needs to be initiated at a future time point. The future time point is estimated by the MDAS producer (701) and included in the BIAR. The BIAR may be generated by the MDAS producer (701) based on data collected from the target gNBs. In an embodiment, the data may include traffic parameters related to the traffic conditions of the target gNBs. In an embodiment, the MDAS consumer (702) may request the MDAS producer (701) to provide an optimal timestamp at which a software upgrade procedure needs to be triggered such that the impact of the software upgrade procedure on the operator and user experience is low. The request may include an optimal time window and at least one target gNB. The reporting interval may indicate to the MDAS producer (701) that the MDAS consumer (702) expects the MDAS producer (701) to indicate the optimal timestamp for triggering a software upgrade of at least one virtual network element (703) within the optimal time window.At least one target gNB may indicate to the MDAS producer (701) that the MDAS consumer expects the MDAS producer (701) to analyze the traffic conditions of the at least one particular gNB and indicate an optimal timestamp for triggering a software upgrade of at least one virtual network element (703) of the at least one target gNB. The MDAS producer (701), which may include a circuit, may collect data relating to traffic conditions from at least one target gNB in ​​steps 713 and 715. Such data may include parameters relating to quality of service (QoS), carrier, mobility, error recovery, and the like. The MDAS producer (701) may generate a BIAR based on the collected data relating to traffic conditions from at least one target gNB in ​​step 717. The BIAR may include a plurality of parameters, including an estimated future time stamp moment that is optimal for performing a software upgrade of at least one virtual network element (703). After the BIAR is generated by the MDAS producer (701), the BIAR is communicated to the MDAS consumer (702) in step 719. The MDAS consumer (702) decides whether to trigger a software upgrade of at least one virtual network element (703) of at least one target gNB based on the BIAR in step 721. The MDAS consumer (702) may observe a plurality of parameters included in the BIAR and decide whether to initiate a software upgrade procedure. The MDAS consumer (702) may also collaborate with the MDAS producer (701) to improve the accuracy of the estimation of a suitable future time moment to perform the software upgrade of at least one virtual network element (703) of at least one target gNB. Figure 8 illustrates an example component of an ML model (800) used to estimate an optimal timestamp for upgrading a virtual network element of a 5G virtual RAN, according to an embodiment as disclosed herein. The ML model (800) is a component in an MDAS producer (701) and is configured to generate BIAR reports. The ML model (800) enables integration of the generated BIAR reports with an MDAS consumer (702), e.g., NFV MANO. The ML model (800) may enable in-service software upgrades of virtual network elements (703) in the 5G virtual RAN. The ML model (800) enables automated software upgrades of virtual network elements (703) in the 5G virtual RAN at optimal timestamps. The optimal timestamps are estimated by the ML model (800) and included in the BIAR. The ML model (800) reduces the potential difficulties that telecommunications network operators may experience during software upgrades of virtual network elements (703). Accurate prediction of the optimal timestamp for upgrading virtual network elements (703) in a 5G virtual RAN, and upgrading the software of the virtual network elements (703) at timestamps that are expected to cause minimal or low impact of the software upgrade on the user experience. The ML model (800) includes a single variable time series forecast engine (801) and an optimization engine (802). The single variable time series forecast engine (801) and the optimization engine (802) are part of a trigger forecast engine. The ML model (800) performs data preprocessing and optimal time window detection. In one embodiment, the data includes information relating to traffic conditions at the virtual network element (703). The ML model (800) may collect information relating to traffic conditions at the virtual network element (703) based on a plurality of input parameters (traffic parameters). The ML model (800) may generate a BIAR (which may include an optimal timestamp) based on the traffic parameters. The detected optimal time window is a time interval, where the optimal timestamp is located, to trigger a software update of the network element (703). In an embodiment, the traffic parameters include, but are not limited to, 5GQoS class identifier (5G-QCI), long-term evolution (LTE)-QCI, radio bearer state, bearer modification count, handover in progress, general packet radio service (GPRS) tunneling protocol (GTP) error indication, and the like. The single-variable time series forecast engine (801) may include a plurality of time series models. The traffic parameters are provided to the single-variable time series forecast engine (801). The number of time series models included in the single-variable time series forecast engine (801) is based on the number of traffic parameters (inputs) fed to the single-variable time series forecast engine (801). For example, if six traffic parameters are fed to the single-variable time series forecast engine (801), the single-variable time series forecast engine (801) may include six time series models. The single variable time series forecasting engine 801 may assign weights to traffic parameters at different timestamps. The weight values ​​and input parameters may influence the triggering of software updates of the network element 703 at different timestamps. In an embodiment, if the weight value at a particular timestamp (current or future) is high, then the traffic parameters, to which the weights are associated, may inhibit the triggering of software updates. Conversely, if the weight value at a particular timestamp is low, then the traffic parameters may facilitate the triggering of software updates. The 5G-QCI indicates the type of resource carrier. The carrier types can be guaranteed bit-rate (GBR) carriers, delay critical carriers, and non-GBR carriers. The single variable time series forecasting engine 801 (time series model 1) can utilize this type to infer the total number of active sessions at different timestamps within the optimal time window. Based on the number of active sessions, the time series model 1 can determine the weights that need to be assigned to the 5G-QCI at different timestamps. The weight value at a particular timestamp is directly proportional to the number of active sessions. Therefore, when the number of active sessions is low, the 5G-QCI can facilitate the triggering of software updates. Similarly, when the number of active sessions is high, the 5G-QCI can prevent or reduce the triggering of software updates. The LTE QCI indicates the types of GBR and non-GBR resource carriers. The time series model 2 of the single variable time series forecasting engine 801 can utilize this type to infer the total number of active LTE GBR sessions and active LTE non-GBR sessions at different timestamps within the optimal time window. Based on the number of active LTE sessions, the time series model 2 can determine the weights that need to be assigned to the LTE-QCI at different timestamps. The weight value associated with the LTE-QCI at a particular timestamp is directly proportional to the number of active LTE GBR sessions and active LTE non-GBR sessions. However, the contribution of active LTE GBR sessions to the weight is greater than the contribution of active LTE non-GBR sessions. Therefore, when the number of active LTE GBR sessions and active LTE non-GBR sessions is low, the LTE-QCI can facilitate the triggering of software updates.Similarly, when the number of active LTE GBR sessions and active LTE non-GBR sessions is high, LTE-QCI can prevent or reduce software update triggers. The state of the radio carrier indicates whether the radio carrier is in an active state or an idle state. The state of the radio carrier is used to determine the state of the carrier connection. The time series model 3 of the single variable time series forecasting engine 801 can utilize the state of the radio carrier to infer the total number of idle / active connections at different timestamps within an optimal time window. The time series model 3 can determine the weights that need to be assigned to the state of the radio carrier based on the number of idle / active connections at different timestamps. The weight value associated with the state of the radio carrier at a particular timestamp is directly proportional to the number of active connections. Therefore, when the number of idle connections is high and the number of active connections is low, the state of the radio carrier can facilitate the triggering of software updates.Similarly, when the number of idle connections is low and the number of active connections is high, the state of the radio carrier can prevent or reduce the triggering of software updates. The number of carrier modifications may indicate, for a particular carrier session, the number of times the carrier has undergone modification since its creation. The time series model 4 of the single variable time series forecasting engine 801 may utilize the number of carrier modifications to determine the frequency of modifications experienced by each carrier at different timestamps within an optimal time window. The time series model 4 may determine the number of carrier sessions that are susceptible to subsequent carrier modifications at different timestamps. The weight that needs to be assigned to the number of carrier modifications at a particular timestamp is based on the number of sessions that are susceptible to subsequent carrier modifications at that particular timestamp. The weight associated with the number of carrier modifications is proportional to the number of sessions that are susceptible to carrier modifications.Therefore, when the number of sessions vulnerable to carrier modification is low, the number of carrier modifications facilitates software update triggers. Similarly, when the number of sessions vulnerable to carrier modification is high, the number of carrier modifications prevents or reduces software update triggers. The traffic parameter ‘handover in progress’ can indicate whether a particular bearer is undergoing handover. The time series model 5 of the single variable time series forecasting engine 801 can utilize ‘handover in progress’ to infer the number of bearer sessions undergoing handover at different timestamps within an optimal time window. The weights that need to be assigned to the traffic parameter ‘handover in progress’ are based on the number of sessions undergoing handover at different timestamps. The weight value at a particular timestamp is directly proportional to the number of sessions undergoing handover at that particular timestamp. Therefore, when the number of sessions undergoing handover is low, software update triggers are facilitated. Similarly, when the number of sessions undergoing handover is high, software update triggers are prevented or reduced. The GTP error indications allow the determination of whether a GTP path is in an error state and awaiting recovery. The time series model (6) of the single variable time series forecasting engine (801) can utilize the GTP error indications to infer the number of carrier sessions that recovered due to errors in their respective GTP paths at different timestamps within the optimal time window. The weights that need to be assigned to the GTP error indications are based on the number of sessions that are in an error state at different timestamps. The weight value associated with a GTP error indication at a particular timestamp is directly proportional to the number of sessions in an error state at that particular timestamp. Therefore, when the number of sessions in an error state is low, the GTP error indications facilitate the triggering of software updates. Similarly, when the number of sessions in an error state is high, the GTP error indications prevent or reduce the triggering of software updates. The single variable time series forecasting engine (801) can compute the value of the following sum of products at each time stamp in the optimal time window: (5G-QCI weight) * (5G-QCI) + (LTE-QCI weight) * (LTE-QCI) + (radio carrier state weight) * (radio carrier state) + (carrier modification count weight) * (carrier modification count) + (handover in progress weight) * (handover in progress weight) + (GTP error indication weight) * (GTP error indication). The single variable time series forecasting engine (801) may, for example, determine a minimum value of the sum of the products and a timestamp corresponding to the minimum value of the sum of the products, among all the sums of the products corresponding to different timestamps within an optimal time window. When the optimal time window includes a future timestamp, then the minimum value of the sum of the products may be the predicted value, corresponding to the future timestamp. The single variable time series forecasting engine (801) may consider the timestamp with the minimum sum of the product values ​​or a low sum of the product values, for example, as the output of a 'future timestamp'. The future timestamp may be the optimal timestamp at which a software upgrade of the network element (703) is to be triggered to ensure that the impact of the software upgrade on user experience and service disruption is reduced or minimized. The single variable time series forecast engine (801) may generate a BIAR that includes a future timestamp, the timestamp at which the BIAR is generated (the reporting timestamp), an indication of whether the reporting timestamp is optimal for triggering a virtual network element software upgrade (703), the number of active GBR DRBs predicted at the future timestamp, the number of active non-GBR DRBs predicted at the future timestamp, the number of active GBR DRBs at the reporting timestamp, and the number of active non-GBR DRBs predicted at the reporting timestamp. The single variable time series forecast engine (801) may deliver the BIAR to an MDAS consumer (702) (NFV MANO or NFVO). Once the optimal timestamp to trigger a network element software upgrade is estimated and provided to, MDAS -> NFVO (702), the NFVO (702) may provide feedback to the optimization engine (802) regarding the optimization of the estimated future timestamp. The optimization engine (802) may validate whether the estimated future timestamp is optimal to trigger a software upgrade based on the feedback received from the NFVO (702). If the estimated future timestamp is invalid, the single variable time series forecasting engine (801) may estimate whether the timestamp is optimal. Otherwise, if the estimated future timestamp is valid, the NFVO (702) may trigger a software upgrade. If the number of non-GBR DRBs is greater than the number of GBR DRBs (as indicated in BIAR), at a certain timestamp, based on a factor or weight, packet loss can be anticipated. This condition is optimal for assuming delay tolerance, which is also the optimal condition for upgrading. Therefore, software upgrades can be triggered at certain timestamps. Figure 8 shows an exemplary unit of the ML model (800), but it should be understood that other embodiments are not limited thereto. In other embodiments, the ML model (800) may include fewer or more units. Furthermore, the labels or names of the units of the ML model (800) are used for illustrative purposes only and are not limiting in scope. One or more units may be combined together to perform the same or substantially similar functions in the ML model (800). Figure 9 is a sequence diagram illustrating a CU-CP software upgrade at an estimated optimal timestamp, according to an embodiment as disclosed herein. The CU-CP is a virtual network element (703), which is part of a gNB. The gNB is part of a 5G virtual RAN. The NFVO (MDAS consumer (702)) may request the traffic analyzer (MDAS producer (701)) to provide a timestamp, which is optimal for triggering a CU-CP software upgrade within a time window. Triggering a CU-CP software upgrade at the optimal timestamp needs to involve minimal operational cost in performing the software upgrade, prevent or mitigate data loss due to the software upgrade, and have minimal or reduced impact of the software upgrade on the user experience.The traffic analyzer can estimate the optimal timestamp to trigger a CU-CP software upgrade based on the analysis of traffic conditions in the CU-CP. The traffic analyzer can analyze a number of traffic parameters related to traffic conditions in the CU-CP to estimate the optimal timestamp. As depicted in Figure 9, the active CU-CP (901) and the standby CU-CP (903) need to be upgraded. The active CU-CP (901) can connect with UEs via DRBs. The traffic analyzer can generate a report relevant to the carrier condition, which can include an estimated optimal timestamp. The traffic analyzer can forward the report to the NFVO (909) at step 920. The NFVO (909) can decide whether to trigger a software upgrade based on the report at step 921. In an embodiment, if the NFVO (909) decides to trigger a software upgrade, the standby CU-CP (903) is upgraded first. If the network functionality CUCP software of the standby CU-CP (903) is successfully upgraded, the NFVO (909) triggers a network functionality CU-CP software upgrade of the active CUCP. The NFVO graphical user interface (NFVO GUI) may inspect the packet details of the VNFs serving as the CU-CP prior to the initiation of the network functionality CU-CP software upgrade. When the NFVO (909) triggers a software upgrade of the standby CU-CP, the NFVO (909) may send a VNF upgrade request to the VNFM (907) in step 923. The VNFM (907) may forward the VNF upgrade request to the standby CU-CP (903) in step 925. The standby CU-CP (903) may generate an upgrade sequence and track the upgrade sequence. And the standby CU-CP (903) may send a successful VNF upgrade to the NFVO (909) in step 926. The VIM (911) may send an upgraded VNF packet, which corresponds to different components of the standby CU-CP (903), to the standby CUCP (903) via file transfer protocol (FTP). This enables the upgrade of the standby CU-CP (903). After the NFVO (909) verifies that the software upgrade of the standby CU-CP (903) has been successfully completed, the software upgrade of the active CU-CP (901) can be initiated. When the NFVO (909) triggers a software upgrade of the active CU-CP (901), the NFVO (909) may send a VNF upgrade request to the VNFM (907) in step 927. The VNFM (907) may forward the VNF upgrade request to the active CU-CP (901) in step 929. The active CU-CP (901) may inform the NFVO (909) and the VNFM (907) that the VNFs running on the VMs of the active CU-CP (901) will be upgraded in steps 931 and 933. The active CU-CP (901) may request the CU-UP (905) to maintain the state of the bearer connecting the UEs (end-user devices) to the CU-CP in step 935. The bearer is maintained for a predetermined recovery time interval. In one embodiment, the recovery time interval is determined based on negotiation between the active CU-CP (901) and the CU-UP (905) via radio resource configuration (RRC) messages.Maintaining the bearer state can significantly reduce the signaling overhead involved in establishing a radio bearer, which would be required if UEs were connected to other CU-CPs. Therefore, maintaining the bearer state reduces the operational overhead involved in setting up redundant CU-CP nodes while the active CU-CP (901) is undergoing a software upgrade. After that, the active CU-CP (901) enters the software upgrade mode at the optimal time moment estimated in step 937. It can be noted, that the recovery time interval starts when the active CU-CP (901) enters the software upgrade. The VIM (911) may send a new VNF packet to the active CU-CP via FTP in step 939, to upgrade different components of the active CU-CP. When the active CU-CP (901) exits software upgrade mode with an updated VNF package, the CU The active CP sends an RRC message to the CU-UP (905) in step 941. The RRC message indicates that the software upgrade of the active CU-CP (901) was successful. The retained bearer entry is validated at the CU-CP with the help of the UEs. Otherwise, if the active CU-CP does not become functional, for example, if the CU-CP remains in software upgrade mode after a predetermined recovery time interval, the retained bearer entry is marked as invalid in step 943. In this case, the software upgrade is not considered successful. Figure 10 is a flowchart 1000 illustrating a method for upgrading software of a virtual network element of a virtual RAN of a 5G network using MDAS, according to an embodiment as disclosed herein. In step 1001, the method may include analyzing, by the MDAS producer 701 , data relating to traffic conditions of at least one virtual network element 703 of the virtual RAN. In an embodiment, the data may include traffic parameters such as, but not limited to, 5G-QCI, LTE QCI, radio bearer state, number of bearer modifications, handovers in progress, GTP error indications, and the like. The MDAS producer 701 obtains the traffic parameters upon receiving a request from the MDAS consumer 702 to provide a BIAR, which may include an optimal timestamp to trigger the software upgrade of at least one virtual network element 703 . In one embodiment, the request may include at least one virtual network element (703) (to be upgraded) and an optimal time window. In one embodiment, the optimal timestamp to trigger a software upgrade of the at least one virtual network element (703) lies within the optimal time window. In step 1002, the method may include estimating an optimal timestamp to trigger a software upgrade of at least one virtual network element 703 based on the analyzed data. In an embodiment, the optimal timestamp is estimated, based on traffic parameters, using a time series forecast using a time series model. Each traffic parameter indicates a traffic condition and is associated with a weight, which may affect the prediction of the optimal timestamp to trigger a software upgrade. The weights may vary based on the traffic parameters. For example, 5G-QCI indicates the number of active sessions at different timestamps within an optimal time window. The weights associated with 5G-QCI are proportional to the number of active sessions. When the number of active sessions is low, software update triggering is facilitated. When the number of active sessions is high, software update triggering is prevented or reduced. Since traffic parameters tend to vary at different timestamps throughout the optimal time window, the weights associated with those traffic parameters vary at different timestamps throughout the optimal time window. Example embodiments may include calculating the sum of the products of the traffic parameters and their associated weights at each of the different timestamps throughout the optimal time window. The timestamps for which the sum of those products is minimum are examples of optimal timestamps for triggering a software upgrade of at least one virtual network element 703 within the optimal time window. Example embodiments may include generating a BIAR, which may include an optimal timestamp, the timestamp at which the BIAR was generated (the reporting timestamp), an indication of whether the reporting timestamp is optimal for triggering a software upgrade of at least one virtual network element (703), the number of active GBR DRBs at the optimal timestamp, and the number of active non-GBR DRBs at the optimal timestamp. Example embodiments may include delivering the BIAR to an MDAS consumer (702). In step 1003, the method may include receiving feedback from the MDAS consumer (702) regarding the suitability of triggering a software upgrade of at least one virtual network element (703) at the estimated optimal timestamp. In an embodiment, the MDAS consumer (702) may send the feedback to the MDAS producer (701). The MDAS producer (701) may validate whether the estimated optimal timestamp is suitable for triggering the software upgrade based on the feedback. If the estimated future timestamp is not valid, an example embodiment may include estimating another optimal timestamp for triggering the software upgrade. This may improve the accuracy of the optimal timestamp prediction. In an embodiment, suitable conditions for triggering a software upgrade are, but are not limited to, when the number of active bearer sessions is low, when only default bearer sessions are active, when the number of bearer modifications undergone by active GBR / Critical GBR sessions is low, when a majority of bearer sessions are not in the active state, when handover is not taking place for a majority of active bearer sessions, when a majority of active bearer sessions are not in the GT error indication state, and the like. In step 1004, the method may include initiating the software upgrade at an estimated optimal timestamp, determined accordingly based on feedback. The MDAS consumer (702) may send a VNF upgrade request to a VNFM, which is responsible for managing network functions, e.g., VNFs, running on VMs representing at least one virtual network element (703). The VNFM may forward the VNF upgrade request to the at least one virtual network element (703). “Based on” as used herein includes at least based on. The at least one virtual network element (703) may maintain a bearer state connecting the at least one UE to the at least one virtual network element (703). Example embodiments may include maintaining the bearer for a predetermined recovery time interval. The at least one virtual network element (703) enters a software upgrade mode at a predicted optimal time moment. The at least one virtual network element (703) is loaded with a new VNF package during the software upgrade. Example embodiments may include validating the retained bearer entry after a successful software upgrade. If the software upgrade does not complete within the predetermined recovery time interval, the retained bearer entry is released. The various actions in the flowchart 1000 may be performed in the order presented, in a different order, or simultaneously. Furthermore, in some embodiments, some of the actions listed in Figure 10 may be omitted. The embodiments disclosed herein may be implemented through at least one software program running on at least one hardware device and performing network management functions to control a network element. The network element shown in Figure 7 includes a block that may be at least one of a hardware device, or a combination of a hardware device and a software module. Each “module” herein may include circuitry. Embodiments disclosed herein describe methods and apparatus for providing an ML model for estimating optimal timestamps for upgrading software of a virtual network element of a 5G network based on analysis of parameters relating to traffic conditions of the virtual network element of the 5G network. Accordingly, it is understood that the scope of protection extends to such a program and in addition to the computer-readable means having a message therein, said computer-readable storage means containing program code means for implementing one or more steps of the method, when said program is running on a server or mobile device or any suitable programmable device.The method is implemented in a preferred embodiment by means of or in conjunction with a software program written in, for example, Very High Speed ​​Integrated Circuit Hardware Description Language (VHDL), or any other programming language, or implemented by one or more VHDLs or software modules executing on at least one hardware device. The hardware device may be any type of portable programmable device. The device may also include means, which may be, for example, hardware means, for example, an application-specific integrated circuit (ASIC), or a combination of hardware and software means, for example, an ASIC and a programmable field gate array (FPGA), or at least one microprocessor and at least one memory with software modules located therein.The embodiment methods described herein may be implemented partly in hardware and partly in software. Alternatively, the various example embodiments may be implemented on different hardware devices, for example using a plurality of central processing units (CPUs). Each CPU and each “processor” herein includes circuitry. The foregoing description of the particular embodiments will fully disclose the general nature of the embodiments herein that others may, by applying present knowledge, readily modify and / or adapt them for various applications of such particular embodiments without departing from the general concept, and, therefore, such adaptations and modifications shall and are intended to be understood to be equivalent in meaning and scope to the disclosed embodiments. It should be understood that the phraseology or terminology used herein is for purposes of description and not limitation. Therefore, while the embodiments herein have been described in terms of preferred embodiments, those skilled in the art will recognize that the embodiments herein may be practiced with modifications within the scope of the embodiments as described herein.While the present invention has been illustrated and described with reference to various embodiments, it will be understood that the various embodiments are intended to be illustrative and not limiting. It will further be understood by those skilled in the art that various changes in form and detail may be made without departing from the true spirit and full scope of the present invention, which includes the appended claims and their equivalents. It will also be understood that any of the embodiments described herein may be used in conjunction with any of the other embodiments described herein.

Claims

1. A method for managing a software upgrade of a network element of a radio access network (RAN) by a producer of a management data analysis service (MDAS), the method including: receiving a request related to an optimal time for a software upgrade of a network element in the RAN, from a consumer of the MDAS; identifying information related to a specific radio bearer (DRB); identifying information related to an optimal time for a software upgrade of the network element based on information related to the DBR; and sending a report including information related to the optimal time for the software upgrade of the network element.

2. The method of claim 1, wherein the request received from said MDAS consumer includes information indicating a network element and a predetermined time window in which said optimal time is included.

3. The method of claim 1, wherein the information associated with the DBR includes at least one of a radio carrier state, a carrier modification count, and a handover status associated with the DRB.

4. The method of claim 1, wherein the information related to the optimal time for the network element software upgrade includes at least one of an optimal time for the network element software upgrade, a number of guaranteed bit rate (GBR) DRBs at the optimal time, and a number of non-GBR DRBs at the optimal time.

5. The method of claim 1, wherein further comprises optimizing the optimal time by at least collaborating with the MDAS consumer, wherein said collaboration involves the MDAS consumer providing feedback to the MDAS producer regarding the optimization of the optimal time for upgrading the network element software at the optimal time.

6. The method of claim 5, further comprising re-identifying information related to the optimal time based on feedback indicating that the optimal time is not optimal for the network element software upgrade.

7. An electronic device from a manufacturer of a management data analysis service (MDAS) for managing software upgrades of network elements of a radio access network (RAN), the electronic device including: memory; and at least one processor coupled to the memory, wherein the at least one processor is configured to: receive a request related to the optimal time for a software upgrade of a network element in the RAN; identify information related to a specific radio bearer (DRB); identify information related to the optimal time for a software upgrade of the network element based on information related to the DBR; and send a report that includes information related to the optimal time for a software upgrade of the network element.

8. The electronic device of claim 7, wherein said request received from said MDAS consumer includes information indicating a network element and a predetermined time window in which said optimal time is included.

9. The electronic device of claim 7, wherein the information associated with the DBR includes at least one of a radio carrier state, a number of carrier modifications, and a submission status associated with the DRB.

10. The electronic device of claim 7, wherein the information related to the optimal time for said network element software upgrade includes at least one of an optimal time for said network element software upgrade, a number of guaranteed bit rate (GBR) DRBs at the optimal time, and a number of nonGBR DRBs at the optimal time.

11. The electronic device of claim 7, wherein said at least one processor is further configured to optimize the optimal time at least in collaboration with the MDAS consumer, wherein said collaboration involves the MDAS consumer providing feedback to the MDAS producer regarding the optimal time optimization for upgrading the network element software at the optimal time.

12. The electronic device of claim 11, wherein said at least one processor is further configured to re-identify information related to the optimal time based on feedback indicating that said optimal time is not optimal for upgrading the network element software.

13. A non-transient computer-readable storage medium that stores program code that, when executed by at least one processor of a manufacturer's electronic device (MDAS) for managing software upgrades of network elements of a radio access network (RAN), causes the electronic device to perform operations, the operations including: receiving a request related to an optimal time for a software upgrade of a network element in the RAN; identifying information related to a specific radio carrier (DRB); identifying information related to an optimal time for a software upgrade of the network element based on information related to the DBR; and sending a report that includes information related to the optimal time for the software upgrade of the network element.

14. The non-transient computer-readable storage medium of claim 13, wherein said request received from said MDAS consumer includes information indicating a network element and a predetermined time window in which said optimal time is included.

15. The non-transient computer-readable storage medium of claim 13, wherein the information associated with said DBR includes at least one of a radio carrier state, a number of carrier modifications, and a submission status associated with the DRB.

16. The non-transient computer-readable storage medium of claim 13, wherein the information relating to an optimal time for a network element software upgrade includes at least one of an optimal time for a network element software upgrade, a number of guaranteed bit-rate (GBR) DRBs at the optimal time, and a number of non-GBR DRBs at the optimal time.

17. The non-transient computer-readable storage medium of claim 13, wherein said operation further includes optimizing the optimal time at least by collaborating with the MDAS consumer, wherein said collaboration involves the MDAS consumer providing feedback to the MDAS producer regarding the optimization of the optimal time for upgrading the network element software at the optimal time.

18. The non-transient computer-readable storage medium of claim 17, wherein said operation further includes re-identifying information associated with the optimal time based on feedback indicating that said optimal time 5 is not optimal for upgrading the network element software.

Images