7 Use cases and requirements for MDA capabilities and services

28.1043GPPManagement and orchestrationManagement Data Analytics (MDA)Release 17TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

7.1 General

The following clauses describe the use cases and requirements for MDA capabilities and MDA MnSs. The MDA capabilities are grouped under specific categories.

7.2 MDA capabilities

7.2.1 Coverage related analytics

7.2.1.1 Coverage problem analysis

7.2.1.1.1 Description

This MDA capability is for analysis of coverage related problem.

7.2.1.1.2 Use case

The RAN coverage problem may cause UEs to be out of service or result in a downgrade of network performance offered to the UEs, such as failure of random access, paging, RRC connection establishment or handover, low data throughput, abnormal releases of RRC connection or UE context, and dissatisfied QoE.

There are various types of coverage problems, e.g. weak coverage, a coverage hole, a pilot pollution, an overshoot coverage, or a DL and UL channel coverage mismatch, etc., caused by different sorts of reasons, such as insufficient or weak transmission power, blocked by constructions and/or restricted by terrain.

The 5G related coverage problem may exist in NR, in E-UTRA or both.

To unravel a coverage problem, it is necessary for MDAS consumer to determine the details about when and where the problem occurred or likely to occur, and the type and cause(s) of the problem. Therefore, it is desirable for MDA to correlate and analyze multifold data (such as performance measurements, MDT reports, RLF reports, RCEF reports, UE location reports, together with the geographical, terrain and configuration data of the RAN) to detect and describe the problem with detailed information.

The RAN coverage related problems can cause network performance degradation and in the extreme cases can result into service degradation. So besides identifying the problems after they have happened, it is also necessary to proactively avoid the RAN coverage related problems well before they occur.

To avoid coverage related problems or to proactively undertake actions to avoid their occurrence, the consumer of MDA MnS may wish to know the characteristics and quality of the coverage of the RAN. This may be expressed graphically on a Map, called a Radio Environment Map, that shows the coverage quality for a set of cells. Such a map may be constructed e.g. to show the RSRP or the SINR of the cells as derived from the observed UE performance and/or from radio configuration parameters of the cells including transmit powers, antenna gains, antenna tilts, etc. It is desirable that the MDAS producer can provide the Radio Environment Map in an appropriate graphical form.

Moreover, where a new RAN node is provisioned, the MDAS producer should be able to take into considerations the coverage of existing cells as defined by a Radio Environment Map and derive the configuration of the new cell(s) and the existing cells to optimize the coverage. Image analytics should help to identify the most optimized set of initial radio configurations that can be assigned to a new RAN NE.

To help MDAS consumer to solve the coverage problem as quickly as possible, MDA may also provide, along with the description of the problem, the recommended remedy actions (e.g. reconfigure or add cells, beams, antennas, etc.).

7.2.1.1.3 Requirements

Table 7.2.1.1.3-1

Requirement label	Description	Related use case(s)
REQ-COV_MDA-01	MDA capability for coverage problem analysis shall be able to provide the analytics for issues including, weak coverage, coverage holes, pilot pollution, overshoot coverage, or DL and UL channel coverage mismatch.	Coverage problem analysis
REQ-COV_MDA-02	MDA capability for coverage problem analysis shall be able to provide the analytics for area specific coverage problem analysis.	Coverage problem analysis
REQ-COV_MDA-03	MDA capability for coverage problem analysis shall be able to provide a radio environment map that graphically describes the radio coverage characteristics (e.g. RSRP or SINR) of the selected cluster of cells.	Coverage problem analysis
REQ-COV_MDA-04	MDA capability for coverage problem analysis shall be able to provide the optimum configurations of a RAN node based on the radio environment map that graphically describes the radio coverage characteristics (e.g. RSRP or SINR) of a selected cluster of cells.	Coverage problem analysis

7.2.1.2 Slice coverage analysis

7.2.1.2.1 Description

This MDA capability is for the slice coverage analysis.

7.2.1.2.2 Use case

The slice coverage is one of the indicators when a 3^rd party (i.e. slice tenant) issues a slice request and is mapped into the desired geographical coverage area with the available radio coverage which depends on the base station planning and deployment. In order to map the desired slice coverage perfectly, MDA can be used to optimize the slice coverage on the slice instantiation and runtime considering:

i) slice-aware statistics, e.g. slice-UE distributions and mobility patterns;

ii) slice SLA; and

iii) access node capabilities.

In 5G the notion of coverage is represented by a set of one or more Tracking Areas (TAs), which are contained in a Registration Area (RA), which is assigned to a UE once it registers to the network. Depending on the MDA MnS producer output, TA and RA planning, i.e. grouping cells to form a TA and then TAs to an RA, can be optimized and the RAN parameters can be adjusted to shape the cell edges and load distribution. The main objective is to fulfill a given slice SLA involving as few cells as possible by leveraging the benefits of adjusting cell configurations for satisfying the desired coverage.

7.2.1.2.3 Requirements

Table 7.2.1.2.3-1

Requirement label	Description	Related use case(s)
REQ-NS_COV_MDA-01	MDA capability for slice coverage analysis shall be able to provide the analytics output describing the slice coverage and slice availability.	Slice coverage analysis
REQ-NS_COV_MDA-02	MDA capability for slice coverage analysis shall be able to provide the analytics of the mapping between slice coverage and actual radio deployment.	Slice coverage analysis
REQ-NS_COV_MDA-03	MDA capability for slice coverage analysis shall be able to provide recommended actions that involve options to reconfigure TA and/or RAN attributes including HO parameters, cell reselection parameters, beam configuration, computing resource and slice support in a cell.	Slice coverage analysis

7.2.1.3 Paging optimization analysis

7.2.1.3.1 Description

This MDA capability is for enabling various functionalities related to paging optimization.

7.2.1.3.2 Use Case

As per the current procedures, if the UE goes Out-Of-Coverage (OOC) the paging which was initiated by the network Access and Mobility Management Function (AMF) fails. The re-attempts continue to fail until UE enters the coverage and respond to the paging attempts. This repetitive paging attempts result in the wastage of network resources. As an example, the use case includes a user or a group of users getting into an area, with no cellular coverage on a regular basis for a considerably long duration, for e.g. the user gets into a shielded room for some testing purpose every day for a defined period. The Network initiated paging for such users will fail until they are back in the area with cellular coverage. This would result in in-efficient network resource usage.

It is desirable to use MDAS (Management data analytic service) to optimize the current paging procedures in 5G networks. MDAS producer provides an analytics output containing the user(s) paging analytics indicating the time window at which a group of users are OOC on a regular basis at the particular location. MDAS producer also provides the geographical map within which the UEs would experience paging issues and hence will not be able to respond on a network-initiated paging. Based on the provided MDA output, MDAS consumer (e.g. AMF, gNB) decides on whether, when and where to initiate or not to initiate the paging procedures, thereby ensuring the efficient paging procedures and optimal network resource utilization, as paging can be initiated only when there are more chances for it to be successful.

7.2.1.3.3 Requirements

Table 7.2.1.3.3-1

Requirement label	Description	Related use case(s)
REQ-PAG_MDA-01	MDA capability for paging optimization analysis shall be able to provide analytics output describing paging result patterns for a group of users.	Paging optimization analysis
REQ-PAG_MDA-02	MDA capability for paging optimization analysis shall be able to provide analytics output describing paging result patterns based on geographical area.	Paging optimization analysis
REQ-PAG_MDA-03	MDA capability for paging optimization analysis shall be able to provide analytics output describing the paging result patterns based on successful and un-successful paging attempts at a particular time and duration based on geographical area.	Paging optimization analysis
REQ-PAG_MDA-04	MDA capability for paging optimization analysis shall be able to provide analytics output describing the paging result patters to contain the following information: – Identification of a group of users. – Identify the geographical area of concern. – Prediction of the time window during which UE is out-of-coverage periodically. – Prediction of the last known location before UE going out‑of‑coverage periodically. – The recommended action which may suggest stopping paging the UE for Daily-OOC-Duration at Daily-OOC-Location.	Paging optimization analysis

7.2.2 SLS analysis

7.2.2.1 Service experience analysis

7.2.2.1.1 Description

This MDA capability is for the service experience analysis.

7.2.2.1.2 Use case

Service experience of end user is key indicator that directly reflects the user satisfaction degree. In 5G system, the diversity of network services is expanding all the time and the requirements of different services especially from vertical users are being standardized. Considering these diverse requirements and expectation from end user perspective (e.g. priorities of SLA related attributes such as latency, throughput, maximum number of users or different required values of these attributes), the service experience as a comprehensive indicator need to be extensively analysed.

7.2.2.1.3 Requirements

Table 7.2.2.1.3-1

Requirement label	Description	Related use case(s)
REQ-SER_EXP_MDA-01	MDA capability for service experience analysis shall be able to identify the source of service experience issue, e.g. RAN issue, CN issue, TN issue, UE issue, service provider issue.	Service experience analysis
REQ-SER_EXP_MDA-02	MDA capability for service experience analysis shall be able to provide the analytics output with following information describing the current service experience aspects and potentially future prediction: – The predicted future service experience and/or observed service experience statistics. – Service experience degradation root cause analysis.	Service experience analysis
REQ-SER_EXP_MDA-03	MDA capability for service experience analysis shall be able to provide the level of service experience.	Service experience analysis
REQ-SER_EXP_MDA-04	MDA capability for service experience analysis shall be able to provide the recommendation for improving service experience.	Service experience analysis

7.2.2.2 Network slice throughput analysis

7.2.2.2.1 Description

This MDA capability is for the network slice throughput analysis.

7.2.2.2.2 Use case

Throughput is of great importance which represents the end users’ experiences and also reflects the network problems, e.g. low UE throughput may be caused by resource shortage. In order to satisfy the requirements of dL/ulThptPerSlice in the ServiceProfile, MDAS may be utilized for throughput related analysis/predictions for network slice instance.

MDAS producer allows the consumer to request analytics of network slice throughput related issues and identify the corresponding root cause(s) to assist throughput assurance. Network slice throughput analysis can be for a specific domain and/or for cross-domain. The two level MDAS producers, i.e. domain-specific and cross-domain may work in coordination to assure the optimum throughput performance.

7.2.2.2.3 Requirements

Table 7.2.2.2.3-1

Requirement label	Description	Related use case(s)
REQ-THR_MDA-1	MDA capability for network slice throughput analysis shall be able to identify the network slice throughput issues, including those RAN‑related and CN-related issues.	Network slice throughput analysis
REQ-THR_MDA -2	MDA capability for network slice throughput analysis shall be able to provide the root cause analysis of the network slice throughput issue(s).	Network slice throughput analysis
REQ-THR_MDA -3	MDA capability for network slice throughput analysis shall be able to provide the analytics output of the network slice throughput which contain the following information: – Network slice throughput statistics. – Network slice throughput predictions.	Network slice throughput analysis
REQ-THR_MDA-04	MDA capability for network slice throughput analysis shall be able to provide the prompt when the network slice throughput exceeds or falls below a certain threshold.	Network slice throughput analysis

7.2.2.3 Network slice traffic prediction

7.2.2.3.1 Description

This MDA capability is for the prediction of network slice traffic patterns.

7.2.2.3.2 Use case

It is desirable to use MDAS to get the network slice traffic predictions including individual traffic load predictions on each of the constituent network function instance present in the network slice. The traffic load predictions per constituent network function instances can be used for better resource provisioning of the network slice. For example, resources can be pre-configured considering the predicted traffic on the network slice.

7.2.2.3.3 Requirements

Table 7.2.2.3.3-1

Requirement label

Description

Related use case(s)

REQ-TRA_MDA–01

MDA capability for network slice traffic prediction shall be able to provide analytics output describing traffic load prediction of the network slice including traffic load prediction for each of its constituent network function instances.

Network slice traffic prediction

REQ-TRA_MDA-02

MDA capability for network slice traffic prediction shall be able to provide analytics output describing traffic load prediction for the network slice which include the following information:

– Predicted uplink and downlink throughput on each User Plane Function instance (UPF) in the network slice.

– Predicted number of Packet Data Unit (PDU) session for each Session Management Function (SMF) instance in the network slice.

– Predicted number of UE or Registered subscriptions for each AMF instance in the network slice.

– Predicted maximum packet size for each UPF instance in the network slice.

– Predicted UE uplink and downlink throughput on each gNodeB (gNB) instance in the network slice.

– Predicted number of UE for each gNB/NR cell instance in the network slice.

Network slice traffic prediction

7.2.2.4 E2E latency analysis

7.2.2.4.1 Description

This MDA capability is for E2E latency related issue analysis.

7.2.2.4.2 Use case

E2E latency is an important parameter for URLLC services. User data packets should be successfully delivered within certain time constraints to satisfy the end users requirements. Latency could be impacted by the network capability and network configurations. These factors may be the root cause if the latency requirements cannot be achieved. Packet transmission latency may dynamically change if these factors change. The latency requirement should be assured even if some of the network conditions may degrade. It is important for the MDAS producer to analyze the latency related issues to support SLS assurance.

7.2.2.4.3 Requirements

Table 7.2.2.4.3-1

Requirement label	Description	Related use case(s)
REQ-LAT_MDA-01	MDA capability for E2E latency analytics shall be able to identify the type of the E2E latency issue, including, RAN- related latency issue, CN‑related latency issue, TN-related latency issue, UE-related latency issue and service provider originated latency issue.	E2E latency analytics
REQ-LAT_MDA-02	MDA capability for E2E latency analytics shall be able to provide the root cause analysis of the E2E latency issue.	E2E latency analytics
REQ-LAT_MDA-03	MDA capability for E2E latency analytics shall be able to provide the recommended actions to solve the E2E latency issue.	E2E latency analytics

7.2.2.5 Network slice load analysis

7.2.2.5.1 Description

This MDA capability is for network slice load analysis.

7.2.2.5.2 Use cases

Network slice load may vary during different time periods. Therefore, network resources allocated initially could not always satisfy the traffic requirements, for example, the network slice may be overloaded or underutilized. Overload of signalling in control plane and/or user data congestion in user plane will lead to underperforming network. Besides, allocating excessive resources for network slice with light load will decrease resource efficiency.

The analysis of network slice load should consider the load of services with different characteristics (e.g. QoS information, service priority), load distribution to derive the corresponding resource requirements. Load distribution analytic result may be provided, e.g. load distribution for network slices, different locations and/or time periods etc.

Traffics and resources related performance measurements and UE measurements can be utilized by MDAS producer to identify degradation of the performance measurements and KPI documented in an SLS due to load issues, e.g. radio resource utilization. MDAS producer may further provide recommendations to the network slice load issue. This analytics results can be considered as an input to support SLA assurance to perform further evaluation.

7.2.2.5.3 Requirements

Table 7.2.2.5.3-1

Requirement label	Description	Related use case(s)
REQ-NS_LOAD_MDA-01	MDA capability for network slice load analytics shall be able to identify the domain of the network slice load issue, including, RAN issue, CN issue and TN-related issues.	network slice load analytics
REQ-NS_LOAD_MDA-02	MDA capability for network slice load analytics shall be able to identify the phase of the network slice load issue, e.g. historic/ongoing/potential network slice load issue.	network slice load analytics
REQ-NS_LOAD_MDA-03	MDA capability for network slice load analytics shall be able to identify the state of the network slice load issue, e.g. overload/underutilized network slice load issue.	network slice load analytics
REQ-NS_LOAD_MDA-04	MDA capability for network slice load analytics shall be able to identify the list of the network entities which are involved in the network slice load issue.	network slice load analytics
REQ-NS_LOAD_MDA-05	MDA capability for network slice load analytics shall be able to provide analytics related to network slice load within specified time schedules and geographic locations or target objects.	network slice load analytics
REQ-NS_LOAD_MDA-06	MDA capability for network slice load analytics shall be able to provide the root cause and recommended actions to the network slice load issue.	network slice load analytics

7.2.3 MDA assisted fault management

7.2.3.1 Failure prediction

7.2.3.1.1 Description

This MDA capability is for failure prediction.

7.2.3.1.2 Use case

There are multiple sources of faults which may cause the 5G system to fail to provide the expected service. These faults and the associated failures need extensive troubleshooting. In order to reduce network and service failure time and performance degradation, it is necessary to supervise the status of various network functions and resources, and predict the running trend of network and potential failures to intervene in advance. These predictions can be used by the management system to autonomously maintain the health of the network, e.g. speedy recovery actions on a network function related to the predicted potential failure.

Due to the fact that failure prediction could depend on the existing alarm incidents and relevant historical and real‑time data (performance measurement information, configuration data, network topology information, etc.), there is a possibility for MDA to be used in conjunction with AI/ML technologies and model training to predict potential failures.

In order to avoid the occurrence of failures and abnormal network status, it is necessary for consumers of analytics to obtain the required details of potential failure and the corresponding degradation trend (abnormal KPI, performance measurement information, possible alarm type, fault root cause, etc.). Therefore, MDA, may in conjunction with AI/ML technology, be required to obtain basic health maintenance knowledge (e.g. the relationship between the failures or potential failures and the related maintenance actions) through predefined expertise or model training, so as to effectively predict potential failures. The basic health maintenance knowledge could be updated with feedback.

If necessary, MDA could also provide corresponding recommended actions for failure prevention.

7.2.3.1.3 Requirements

Table 7.2.3.1.3-1

Requirement label	Description	Related use case(s)
REQ-FAILURE_PRED_MDA-01	MDA capability for failure prediction shall be able to collect, correlate, filter and analyse the required data (including, alarm information, historical and real-time data) as inputs for analytics and provide the analytics output.	Failure prediction
REQ-FAILURE_PRED_MDA-02	MDA capability for failure prediction shall be able to obtain basic health maintenance knowledges (including, the relationship between the failures or potential failures and the related maintenance actions) through predefined expertise or model training.	Failure prediction
REQ-FAILURE_PRED_MDA-03	MDA capability for failure prediction shall be able to provide the analytics output including predictions of potential service failures, as well as the possible recommendation actions to prevent failures.	Failure Prediction

7.2.4 MDA assisted Energy Saving

7.2.4.1 Energy saving analysis

7.2.4.1.1 Description

This MDA capability is for the energy saving analysis.

7.2.4.1.2 Use cases

Operators are aiming at decreasing power consumption in 5G networks to lower their operational expense with energy saving management solutions. Energy saving is achieved by activating the energy saving mode of the NR capacity booster cell or 5GC NFs (e.g. UPF etc.). The energy saving decision making is typically based on the load information of the related cells/UPFs, the energy saving policies set by operators and the energy saving recommendations provided by MDAS producer. To achieve an optimized balance between the energy consumption and the network performance, MDA can be used to assist the MDAS consumer to make energy saving decisions.

To make the energy saving decision, it is necessary for MDAS consumer to determine where the energy efficiency issues (e.g. high energy consumption, low energy efficiency) exist, and the cause of the energy efficiency issues. Therefore, it is desirable for MDA to correlate and analyze the energy saving related performance measurements (e.g. PDCP data volume of cells, power consumption, etc.) and the network analysis data (e.g. observed service experience related network data analytics) to provide the analytics results which indicate current network energy efficiency. In some low-traffic scenarios, MDA MnS consumers may expect to reduce energy consumption to save energy. In this case, the MDA MnS consumer may request the MDAS producer to report only high energy consumption issue related analytics results. When the consumer expects to improve energy efficiency, although it may lead to high energy consumption in network or in certain parts of network, then the related issue is the low energy efficiency one. In that case, the consumer may request analytics results related to low energy efficiency issue. So, the target could be to enhance the performance of NF for a given energy consumption. This will result in higher Energy Efficiency of network.

To make the energy saving decision, it is necessary for MDAS consumer to determine which Energy Efficiency (EE) KPI related factor(s) (e.g. traffic load, end-to-end latency, active UE numbers, etc.) are affected or potentially affected. The MDAS producer can utilize historical data to predict the EE KPI related factors (e.g. load variation of cells at some future time, etc.). The prediction result of these information can then be used by operators to make energy-saving decision to guarantee the service experience.

The MDAS producer may also provide energy saving related recommendation with the energy saving state to the MDAS consumer. Under the energy saving state, the required network performance and network experience should be guaranteed. Therefore, it is important to formulate appropriate energy saving policies (start time, dynamic threshold setting, base station parameter configuration, etc.). The MDAS consumer may take the recommendations with the energy saving state into account for making analysis or making energy saving decisions. After the recommendations have been executed, the MDA producer may start evaluating and further analyzing network management data to optimize the recommendations.

7.2.4.1.3 Requirements

Table 7.2.4.1.3-1

Requirement label	Description	Related use case(s)
REQ-ES_MDA-01	MDA capability for energy saving analysis shall be able to identify the energy efficiency issue (including high energy consumption, low energy efficiency), and identify the cell/NFs or location area of where the indicated energy efficiency issue exists.	Energy saving analysis
REQ-ES_MDA-02	MDA capability for energy saving analysis shall be able to identify the root cause of the energy efficiency issue when necessary.	Energy saving analysis
REQ-ES_MDA-03	MDA capability for energy saving analysis shall be able to utilize the network status analysis and predictions information of the energy efficiency KPI factors (including, traffic load trends) to assist achieving energy saving.	Energy saving analysis
REQ-ES_MDA-04	MDA capability for energy saving analysis shall be able to provide the energy saving recommendation, including policies and configuration actions to guarantee the network performance and end user service experience.	Energy saving analysis

7.2.5 MDA assisted mobility management

7.2.5.1 Mobility performance analysis

7.2.5.1.1 Description

This MDA capability is for the mobility performance analysis.

7.2.5.1.2 Use case

The mobility performance related problems may result from too-early/too-late/ping-pong handovers due to inappropriate handover parameters. MDAS can be used to analyse service experience and network performance during handover period in different mobility scenarios. MDAS producer may also be capable to provide the recommendations of optimal handover parameters to MDAS consumer.

In different NSA and SA deployment architecture scenarios, handover mechanisms (e.g. DAPS, CHO or RACH-less handover) will have different impacts on the mobility performance. The analytics report to identify the most optimal handover mechanism may be provided by MDAS producer.

7.2.5.1.3 Requirements

Table 7.2.5.1.3-1

Requirement label	Description	Related use case(s)
REQ-MRO_MDA-01	MDA capability for mobility performance issue analysis shall be able to provide the mobility performance in NSA and SA deployment architectures.	Mobility performance issue analysis
REQ-MRO_MDA-02	MDA capability for mobility performance issue analysis shall be able to provide the mobility issue analysis including too-early handovers, too-late handovers and ping-pong handovers.	Mobility performance issue analysis
REQ-MRO_MDA-03	MDA capability for mobility performance issue analysis shall be able to identify the most optimal handover mechanism including DAPS, CHO or RACH-less handover.	Mobility performance issue analysis
REQ-MRO_MDA-04	MDA capability for mobility performance issue analysis shall be able to provide the area specific mobility performance analysis.	Mobility performance issue analysis

7.2.5.2 Handover optimization analysis

7.2.5.2.1 Description

This MDA capability is for the handover optimization analysis.

7.2.5.2.2 Use cases

7.2.5.2.2.1 Handover optimization

Current handover procedures are mainly based on radio conditions for selecting the target gNB upon a handover. The target gNB accepts or rejects the Handover (HO) request depending on various conditions. In virtualized environment, the HO may be rejected due to inadequate available resources within the target gNB. The notion of resources may include virtual resources (e.g. compute, memory) and/or radio resources (e.g. PRB, RRC connected users). If the HO request is rejected, a UE will try to connect to a different gNB until the request is successfully accepted. Several target gNBs can be tried until the request is successfully accepted. This process can result in wastage of UE and network resources, while it may also introduce service disruption due to increased latency and Radio Link Failures (RLFs). It also introduces inefficiency in the HO or other network procedures.

To address this handover optimization issue, it is desirable to use MDA (Management Data Analytics) to provision and/or select a particular target gNB for handover in order to reduce or even avoid HO rejections. The MDAS producer provides a HO optimization analytics output containing the current and future/predicted resource consumption, resources capabilities and other KPIs’ status for the available target gNB(s). The analytics output also provides recommended actions to optimize the target gNB for handover. This may include resource re-configuration or the updated selection criteria for target gNB. Based on the output, the MDAS consumer adjusts (e.g. scale-out/up the virtual resource, re-schedule/optimize radio resource) the resources before continuing with the handover and/or adjusts the selection criteria of the target gNB by also considering the overlapping coverages of inter‑frequency and inter-RAT deployments.

7.2.5.2.2.2 Handover optimization based on UE Load

The target node, eNB, may not have adequate resources to accept certain handover requests. In the context of network virtualization, these resources may include not only legacy radio resources, but also virtual resources such as processor and memory. Handover optimization can benefit from knowledge about the projected UE load on the target cell including additional radio and virtual resources.

7.2.5.2.3 Requirements

Table 7.2.5.2.3-1

Requirement label	Description	Related use case(s)
REQ-MOB_MDA-01	MDA capability for handover optimization shall be able to provide the analytics output related to current statistics and future predictions of virtual resource consumption of gNB.	Handover optimization
REQ-MOB_MDA-02	MDA capability for handover optimization shall be able to provide the analytics output related to current statistics and future predictions of radio resource consumption of gNB.	Handover optimization
REQ-MOB_MDA-03	MDA capability for handover optimization shall be able to provide an analytics output indicating a selection priority for the target cell, among a set of candidate inter-frequency cells.	Handover optimization
REQ-MOB_MDA-04	MDA capability for handover optimization shall be able to provide an analytics output indicating a list of target cells to spare, i.e. avoid, a handover for an indicated time period.	Handover optimization
REQ-MOB_MDA-05	MDA capability for handover optimization shall be able to provide the analytics output describing inter-frequency target cell selection for handover including information for provisioning or selecting a target gNB with respect to a specific service or slice, if the same Network Slice Instance (NSI) is available in both the current and target gNB.	Handover optimization
REQ-MOB_MDA-06	MDA capability for handover optimization shall be able to provide the analytics output describing inter-frequency target cell selection for handover including indication of current and expected QoE (for the UE) at the current and target gNB.	Handover optimization
REQ-MOB_MDA-07	MDA capability for handover optimization shall be able to provide the analytics output including the following information that can be used to optimize handover decisions: – Indication on whether the target gNB is optimal for handover. – Recommended action to optimize the target gNB and/or the selection of the target gNB for handover.	Handover optimization
REQ-MOB_MDA-08	MDA capability for handover optimization shall be able to provide an analytics output indicating the projected UE load with respect to virtual resource and radio resource on the target cell.	Handover optimization based on UE Load

7.2.5.3 Inter-gNB beam selection optimization

7.2.5.3.1 Description

This MDA capability is for inter-gNB beam selection optimization.

7.2.5.3.2 Use case

With the deployment of 5G networks, Massive MIMO has been used on a large scale. Beamforming, as a key technology to reduce user interference, which can suppress interference signals in non-target directions and enhance sound signals in target directions, is always combined with Massive MIMO to further decrease interference. A cell can make use of multiple beams for serving residing users (SSB or CSI-RS) with each user served by a single beam at a time. The cell level quality can be represented as an aggregated metric over one or more beams. So, although handover is performed between two 5G cells, the granularity of handover can be further broken down to beam level.

The handover of beams could be performed if the network resource or the user’s state have changed to obtain better network performance. Beam optimization includes the handover between different beams and configuration of beam parameters.

In order to avoid selecting the wrong beam to perform RACH on the target cell and causing RLF of the UE, MDA can be used to recommend a means to prioritize and/or select the beam in case of handover for a specific target cell. MDA can provide a beam level HO optimization analysis considering information on the handover performance of different beam combinations between the source and target cell pairs. Beams of the target cell with a successful handover are preferred in the selection.

MDA could also provide recommended actions and priority options for beam selection. Based on the recommended actions, the MDA MnS consumer adjusts the priorities for the beam selection at HO, i.e. the beam combinations that are likely to succeed are prioritized, less optimal beam combinations are down prioritized. The target cell may also obtain analytics to allocate RACH resources in a way that ensures HO success.

In order to optimize antenna and beam configuration, so as to reduce energy loss and enhance network performance, MDA can be used to analyze the current network status.

7.2.5.3.3 Requirements

Table 7.2.5.3.3-1

Requirement label	Description	Related use case(s)
REQ-HO_BEAM_OPT-01	MDA capability for inter-gNB beam selection optimization shall be able to provide the analytics of the handover performance of beam pair combinations between cell pairs.	Inter-gNB beam selection optimization
REQ-HO_BEAM_OPT-02	MDA capability for inter-gNB beam selection optimization shall be able to provide an indication if a beam pair is to be prioritized or down prioritized.	Inter-gNB beam selection optimization
REQ-HO_BEAM_OPT-03	MDA capability for inter-gNB beam selection optimization shall be able to provide feasible antenna and beam configuration analysis.	Inter-gNB beam selection optimization

7.2.6 MDA assisted critical maintenance management

7.2.6.1 RAN Node Software Upgrade

7.2.6.1.1 Description

This MDA capability is for network critical maintenance during RAN node software upgrade process.

7.2.6.1.2 Use case

As per the current mechanism of software upgrade at RAN node results in service disruption or huge operational cost. Consider a scenario, when a RAN Node is required to shut down manually to undergo critical maintenance for a very short duration of time. Software upgrade can be one such critical maintenance scenario. In such cases, all the resources (bearer, security functions, mobility management) that are managed by this RAN Node need to be purged and reconfigured at another RAN Node (standby RAN Node) or if another RAN Node is not available then resources will be reconfigured again when former RAN Node comes up after software upgrade. Both the situations lead to additional operational expenses and data loss. Operational expense in terms of all the resources to be released/attached again and data loss for all GBR sessions/bearer.

It is expected to use MDAS to optimize the procedure of software upgrade at RAN Node by providing the right time to execute the required upgrade. The software upgrade should be automatically initiated by the OAM system, once configured, during the time frame when the expected impacts are minimum i.e. at the optimal time when there would be minimum expected operational cost and data loss. The Optimal Time (current or futuristic) can be derived by collecting and analysing the data related to DRBs including GBR/non-GBR, state, modification count, ongoing handover etc. MDAS can utilize historical data and AI/ML (e.g. time series based) algorithm to derive the future optimal time frame for software upgrade.

Note: RAN Node above refers to CU-CP in case of gNB split case.

7.2.6.1.3 Requirements

Table 7.2.6.1.3-1

Requirement label	Description	Related use case(s)
REQ-SWA_MDA-01	MDA capability for RAN Node software upgrade shall be able to provide the DRB info analytics output describing the DRBs info at a particular RAN Node(s).	RAN Node software upgrade
REQ-SWA_MDA-02	MDA capability for RAN Node software upgrade shall be able to provide the DRB info analytics output describing the DRB info based on the following DRB characteristics; type (GBR/non-GBR), state (idle/active), modification count (indicating number of times, this bearer has gone for modification since its creation), handover in-progress (indicates whether the bearer is undergoing handover or not).	RAN Node software upgrade
REQ-SWA_MDA-03	MDA capability for RAN Node software upgrade shall be able to provide output describing the DRB info that contain the following information: – Time frame/duration at which the output is generated. – Whether RAN Node is optimal for upgrade at present. – Whether RAN Node will be optimal for upgrade during a future time frame. This will also provide a future frame. – Total number of GBR and non-GBR DRBs at future point of time frame. This will also provide a future frame.	RAN Node software upgrade

7.3 MDA MnS

7.3.1 MDA request and control

7.3.1.1 Description

The MDA request and control allow any authorized MDA MnS consumer to request management data analytics.

7.3.1.2 Use case

The MDA MnS consumer can request the MDA MnS producer to provide MDA output for a list of specified MDA type of analytics, i.e. MDA type, which corresponds to an MDA capability, which is to support analytics for a set of data or analytics for a certain PM, KPI, trace or QoE data. The MDA MnS consumer may introduce control attributes related to the MDA output with respect to the geographical location (i.e. area scope) and/or the target objects, e.g. managed elements, time schedule for obtaining an MDA output, time conditions related to the preparation of MDA output (i.e. time schedule for start, end and duration of analytics, etc.), and potential filter conditions to be met before an MDA output is made available, e.g. load or delay threshold crossing related to a target object. The geographical location indicates an area of interest for obtaining MDA output and/or target objects include affected objects or objects of interest for obtaining MDA output.

The MDA MnS consumer may control the MDA output attributes related to, e.g. time schedule, geographical location, target objects, etc., and has the capability to modify them at any point in time. The MDA MnS consumer can request the MDA MnS producer to generate an MDA output that contains numeric output results, e.g. average, normal distribution, etc., recommendation options, e.g. potential handover target cells, or root cause analysis, e.g. alarm prediction.

The MDA MnS consumer can be informed with an acknowledgment if the request was successful. If the request was not successful, the consumer is informed about potential errors indicating the reasons. The MDA MnS consumer can also deactivate the MDA reporting control request once it is no longer needed.

7.3.1.3 Requirements

Table 7.3.1.3-1

Requirement label	Description	Related use case(s)
REQ-MDA-CONT-01	The MDA MnS producer shall have the capability to allow any authorized MDA MnS consumer to request MDA output, while indicating its selection on the MDA type.	All use cases
REQ-MDA-CONT-02	The MDA MnS producer shall have the capability to allow any authorized MDA MnS consumer to request MDA output, while indicating its selection on the reporting time schedule.	All use cases
REQ-MDA-CONT-03	The MDA MnS producer shall have the capability to allow any authorized MDA MnS consumer to request MDA output, while indicating its selection on geographic location and/or the target objects if applicable.	All use cases
REQ-MDA-CONT-04	The MDA MnS producer shall have the capability to allow any authorized MDA MnS consumer to request MDA output, while indicating its selection on the time schedule related to specific part of MDA results.	All use cases
REQ-MDA-CONT-05	The MDA MnS producer shall have the capability to allow any authorized MDA MnS consumer to modify the attributes related to the requested MDA output.	All use cases
REQ-MDA-CONT-6	The MDA MnS producer shall have the capability to allow any authorized MDA MnS consumer to specify filter conditions on target objects based on threshold crossing for MDA output when this is applicable.	All use cases

7.3.2 Obtaining MDA Output

7.3.2.1 Description

Following a successful MDA request any authorized MDA MnS consumer can obtain management data analytics from the corresponding MDA MnS producer. The MDA MnS consumer can control the MDA output by modifying the attributes related to the MDA request at any point in time.

7.3.2.2 Use case

The MDA MnS producer allow consumers to obtain MDA output when the conditions indicated in the MDA request are met. The level of details and granularity of MDA output results would depend on the MDA request and nature of MDA capability. Therefore an MDA output can vary in complexity and may contain one or more MDA results, which may be:

i) numeric, e.g. average, etc.;

ii) recommendation options, e.g. potential handover target cells; or

iii) root cause analysis, e.g. alarm prediction.

These results may be related to one or more MDA types, which correspond to MDA capabilities, and can also contain information regarding the time schedule or the validity time of the provided MDA output.

MDA MnS producer may allow consumers to request and obtain different MDA output results. The MDA MnS producer may also allow consumers to obtain information regarding the geographical location and/or the target objects, e.g. managed elements, related to the provided MDA result – from the corresponding element.

The MDA MnS producer may allow consumers options to obtain MDA output results either by pulling or pushing mechanisms. Any MDA output may be obtained once it is prepared or when the specified MDA request and control conditions are met.

7.3.2.3 Requirements

Table 7.3.2.3-1

Requirement label	Description	Related use case(s)
REQ-MDA_REP-01	The MDA MnS producer shall have a capability allowing MDA MnS consumers to obtain analytics output per the MDA request.	All use cases
REQ-MDA_REP-02	The MDA MnS producer shall have a capability allowing MDA MnS consumers to indicate if produced analytics output shall be pushed to the MDA MnS consumer or whether the MDA MnS consumer pulls the data.	All use cases
REQ-MDA_REP-03	The MDA MnS producer shall allow MDA MnS consumer to obtain the geographical location and/or the target objects related to the MDA output if applicable.	All use cases
REQ-MDA_REP-04	The MDA MnS producer shall allow MDA MnS consumer to obtain time schedule information related to the MDA output.	All use cases