Self-Organizing Networks for 5G and Beyond: A View from the Top

Round 1

Reviewer 1 Report

The proposed paper, in principle, is well organised and structured in distinct sections.

Section 1 serves as a long but comprehensible introduction. The proposed content is presented explicitly. However, some further clarifications have to be given as of the included Fig.1, where the authors provide some "steps" together with some time estimations. Although the order of magnitude may seem reasonable from the practical experience, the authors need to provide more justifications and/or correlate their concerns and time-frame selections to related and specific references from the bibliography. In addition, it is proposed to enhance the quality of the figure, especially those parts marked in red-colored characters.

In the same section, the authors have introduced the abbreviation "5+G". It is not evident what exactly is meant by such notation. Thus, some clarifications have to be given by the authors.

Section 2 is mainly about the description of the basic SON architecture. Here, Figure 2 has to be discussed in more detail as there is no indication why the proposed steps are distinct one to another and why there are subsequent steps; that is, the authors have selected a simple flow of activities without considering potential two-way interactivity between intermediate "steps". Thus, it is essential to provide more clarifications about the way how the contents of Figure 2 have been produced. 

In addition, the authors claim that: "In our case we focus on self-optimization scenarios since these are the most widely developed, resolve more complex issues if compared to self-configuration or self-healing use cases and they are planned to be essential for 5G networks management". This view has to be further justified by supportive argumentation and/or by specific references.

In the same section, the authors say that "European research programs such as 5GPPP, SOCRATES, ...". Actually 5GPPP is not a research program but a generalised research initiative/framework so text has to be corrected, accordingly!

In the same section, as for the case of Figure 4, it is necessary to include more discussion and explain "what is actually depicted by this figure". The authors must include some clarification to explain the various appearing "forms of interactivity", between different levels.

it is also proposed to extend the description for the case of Figure 5 as well, especially by introducing the rationale for the proposed three distinct phases.

In section 2.5, the authors include a list of 10 different categories of "the essential information that must be collected from the network for the needs
of system dimensioning and architecture design". Here it is essential to correlate each category - or at least most of the categories- to dedicated references from the bibliography. In the same framework, as of the case of category 10, the authors claim that "A typical real scenario for a medium sized operator might include 6.000.000 subscribers in total, 60.000 GSM cells, 90.000 UMTS cells, 80.000 LTE cells, 25 BSCs and RNCs and 5 MMEs". It is not obvious why this is a typical scenario. So further clarifications have to be given.

Some parts of Table 1 are given with text in capitals. This practically creates confusion to any potential reader and so text has to be homogenized in that table. In addition, the proposed correlation has to be given in a more explicit way that is by adding some extra text to comment table's content.

In the same section, the authors also discuss in brief some basic system design decisions. It is essential to include supportive references, per case.

By concluding section 2, the authors provide Figure 6. Here there is textual description, but it is given in an abstracted way. Some more discussion has to be provided for this figure.

Section 3 is about the SON applications.  

In section 3.1, the authors claim that "In our review we focus on the most popular applications which are ANR, MLB and CCO, ...". Here the authors have to explain "why these are the most popular applications". 

Section 3.2.3 lacks of corresponding references! Authors have to incorporate some related references for this part of the paper.

In section3.2.4, authors have to select a common way of writing abbreviations such as MLB and TS, that is "Mobility Load Balancing" and "Traffic Steering", in all textual cases.

Figure 8 has to be accompanied with some explanatory text.

Section 4 is about Machine Learning Algorithms for SON. If compared to all other section, it is very "limited" and related information is given in a brief and occasionally "abstracted" way. Here it is recommended: (i) to extend the textual description, and; (ii) to include more essential references, per case, as in total there are very few related references included in the present version. 

Section 5 discusses Future SON Research Directions. 

In section 5.1, it is recommended to include an extra figure, for the depiction of the related basic architectural blocks of an NFV architecture, which is actually missing.

Moreover, part of the text mentions that "Moreover C-RAN (Cloud-RAN), or Centralized-RAN, was first proposed as an architecture by China Mobile Research Institute in April 2010 providing a...". The related reference has to be explicitly included in this part of the document.

In section 5.2 the authors mention in their text the case of "a Hungarian Algorithm Assisted Clustering (HAAC) approach" for which a dedicated reference also needs to be included!

Section 5.3 correlates to 2 references, only. Some extra ones need to be included here. Also correct the text by replacing "...to lower SINR values (Related to..." by using "..to lower SINR values (related to..." instead.

In section 5.6 there are no references at all, so it is necessary to incorporate some relevant ones.

Section 5.8 discusses SON for 6G networks. It is recommended to extend this part by including more discussion and more references.

Section 6 is about conclusions. This part is somehow "identical" to the abstract of the paper. The authors have to extend the text and provide explicit conclusions, by properly correlating the conceptual sequence of the previous sections.

General Comments 

In general, not all abbreviations in the paper have been explained. For textual conformity and textual homogeneity purposes, the authors must explain all abbreviations in their text. For example UMTS, HSPA, GSM, LTE, BSC, RNC, MME, AMF, PCI, RF, IP, CI, CM, SNMP, PS, UE, BTS, HO, vEPC, 5GEPC, LoRa and M2M are not explained in the core document.     

In addition, the authors have to rewrite several of their proposed references to appear in a homogeneous way. Authors have to agree to use the same style for all references belonging to the same category (i.e. journal papers, conference papers, books, websites, projects, etc.). In particular, there is strong differentiation for the cases of conference papers (as in Refs. [11], [12], [61], [62], [64], [65], [67], [68], [75], [88], [92], [95], [98]) that are presented in different ways. The same also stands for the case of journal papers, where only in some cases dois (digital object idnetifiers) are given. For some books, ISBNs are given for some cases. In conclusion, authors have to spend some effort so that to have a homogeneous inclusion of references.

Author Response

Section 1 serves as a long but comprehensible introduction. The proposed content is presented explicitly. However, some further clarifications have to be given as of the included Fig.1, where the authors provide some "steps" together with some time estimations. Although the order of magnitude may seem reasonable from the practical experience, the authors need to provide more justifications and/or correlate their concerns and time-frame selections to related and specific references from the bibliography. In addition, it is proposed to enhance the quality of the figure, especially those parts marked in red-colored characters.

We fully agree. Figure quality is enhanced, especially those parts marked in red-colored characters.

Moreover, the following text was added as well as reference [116].

Additionally, and especially for the RAN optimization aspect, which is our focus, the following figure depicts the comparison of the traditional, legacy (manual) approach compared to automated optimization through SON. The benefits are prominent, as shown in Figure 1, since the conventional Radio Access Network optimization process needs approximately 8 weeks. while automated can be completed in hours. More specifically, the conventional optimization rationale followed included three basic steps that had to be repeated manually many times till the optimum result is achieved. In order to optimize a RAN, the first step is to collect data from drive tests and measurement campaigns, define KPIs, and consider customer complaints and existing configuration. Step 1 consists of the input to step 2 that includes the reconfiguration and optimization steps so that network performance is improved. Finally step 3 includes the monitoring of the changes and reconfiguration deployed during step 2 and it provides feedback about how beneficial these are. The process repeats till the optimum result is achieved in a manual manner leading to a never ending and time-consuming process. Network automation is the key to eliminate delays and the error prone nature of manual activities by replacing the mentioned steps with automated procedures performed by ML algorithms [8, 116].

Figure 1. Traditional vs. automated optimization.

In the same section, the authors have introduced the abbreviation "5+G". It is not evident what exactly is meant by such notation. Thus, some clarifications have to be given by the authors.

We replaced "5+G" with B5G throughout, according to the second reviewers’ prompt, as well as the wide use in the recent bibliography.

Section 2 is mainly about the description of the basic SON architecture. Here, Figure 2 has to be discussed in more detail as there is no indication why the proposed steps are distinct one to another and why there are subsequent steps; that is, the authors have selected a simple flow of activities without considering potential two-way interactivity between intermediate "steps". Thus, it is essential to provide more clarifications about the way how the contents of Figure 2 have been produced. 

We fully agree. The following description was added:

More specifically, the following figure describes the planning process from the early stage of detecting the need for a new site till the activation of an LTE site. As the very first step the need of a new site is identified based on known coverage holes or capacity advancement needs for specific areas. After the radio propagation environment is examined and simulated and exact capacity needs are identified, a coverage simulation is deployed, and the initial RAN parameters are designed by taking into account any neighboring sites. A configuration file is created, planned to be committed by the OSS to the RAN and the activation takes place. As a last step, real time network KPIs are monitored, and drive testing takes place so that the whole coverage area is examined and a clear outcome about any possible optimization actions needed is extracted. Apart from the initial steps of understanding the need for a new site due to poor coverage or capacity needs and coverage simulation the configuration procedure can be substituted by SON self-configuration applications able to eliminate human errors since the interaction with neighboring sites is what creates complexity. 

Figure 2. RAN planning and configuration lifecycle.

In addition, the authors claim that: "In our case we focus on self-optimization scenarios since these are the most widely developed, resolve more complex issues if compared to self-configuration or self-healing use cases and they are planned to be essential for 5G networks management". This view has to be further justified by supportive argumentation and/or by specific references.

We fully agree. The following was deleted from the text and more details were provided in the section that described SON applications:

In our case we focus on self-optimization scenarios since these are the most widely developed, resolve more complex issues if compared to self-configuration or self-healing use cases and they are planned to be essential for 5G networks management.

In the same section, the authors say that "European research programs such as 5GPPP, SOCRATES, ...". Actually 5GPPP is not a research program but a generalised research initiative/framework so text has to be corrected, accordingly!

We fully agree. Corrected according to the following:

Organizations such as 5GPPP and European research programs such as SOCRATES, SEMAFOUR, SESAME, COGNET, Gandalf, and BeFEMTO, describe and propose SON architectures [25–32], while the NGMN alliance, founded by leading international mobile network operators in 2006 as an industry organization to provide innovation platforms for next generation mobile networks, was the first to propose SON use cases and prerequisites for deployment in modern mobile networks [33–35].

In the same section, as for the case of Figure 4, it is necessary to include more discussion and explain "what is actually depicted by this figure". The authors must include some clarification to explain the various appearing "forms of interactivity", between different levels.

We fully agree. The following text was added:

A SON platform consists of the hardware part including the servers and RAN database, the SON applications management and orchestration module that handles SON applications, and APIs providing the ability to handle and manage the RAN database. The SON servers cluster interacts with the LTE OSS system of each RAN (vendor) and uses the latter to commit configuration plans that include the changes that each SON application decides. Configuration plans are committed to the OSS of each vendor, in case more than one exist, and through the MME to the base stations.

it is also proposed to extend the description for the case of Figure 5 as well, especially by introducing the rationale for the proposed three distinct phases.

We fully agree. The following paragraph was enriched:

As depicted in Figure 5, the snapshot period concerns the evaluation of the current state of the network according to the counters for the collection of KPIs prior to any SON actions taken, the action phase concerns the creation and execution of a script for the OSS through SON applications, and the feedback period concerns the evaluation of the action phase taken and a decision to keep a specific action in the network, or revert it to the initial (pre-SON) operation status [57,66].

In section 2.5, the authors include a list of 10 different categories of "the essential information that must be collected from the network for the needs
of system dimensioning and architecture design". Here it is essential to correlate each category - or at least most of the categories- to dedicated references from the bibliography. In the same framework, as of the case of category 10, the authors claim that "A typical real scenario for a medium sized operator might include 6.000.000 subscribers in total, 60.000 GSM cells, 90.000 UMTS cells, 80.000 LTE cells, 25 BSCs and RNCs and 5 MMEs". It is not obvious why this is a typical scenario. So further clarifications have to be given.

The following paragraph was changed. (Confidentially, the specific case comes from the experience gained and the involvement of Mr. A. Papidas in a real case scenario of one of the first operators in Europe as a part of DT-Group that started testing SON platforms.)

A typical real case scenario for a medium size operator in Europe might include 6.000.000 subscribers in total, 60.000 GSM cells, 90.000 UMTS cells, 80.000 LTE cells, 25 BSCs and RNCs and 5 MMEs. The number of OSS subsystems depends on the different vendors an operator might use.

Reference and system design decisions come from real networks in Europe and due to confidentiality reasons we amended referring to these. We have not found any research papers referring to this design. Dimensioning information can be found on ITU white papers such as the following:

https://www.itu.int/en/ITU-D/Regional-Presence/AsiaPacific/SiteAssets/Pages/Events/2016/Aug-WBB-Iran/Wirelessbroadband/core%20network%20dimensioning.pdf

Some parts of Table 1 are given with text in capitals. This practically creates confusion to any potential reader and so text has to be homogenized in that table. In addition, the proposed correlation has to be given in a more explicit way that is by adding some extra text to comment table's content.

We fully agree. Table changed accordingly.

In the same section, the authors also discuss in brief some basic system design decisions. It is essential to include supportive references, per case.

Reference and system design decisions come from real networks in Europe and due to confidentiality reasons we amended referring to these. We have not found any research papers referring to this design. Dimensioning information can be found on ITU white papers such as the following:

https://www.itu.int/en/ITU-D/Regional-Presence/AsiaPacific/SiteAssets/Pages/Events/2016/Aug-WBB-Iran/Wirelessbroadband/core%20network%20dimensioning.pdf

By concluding section 2, the authors provide Figure 6. Here there is textual description, but it is given in an abstracted way. Some more discussion has to be provided for this figure.

We fully agree. The following was added and linked to figure 4.

The specific figure comes as an extension of figure 4 and includes the coexistence of a UMTS and an LTE network. In case a 5G network is included, the design rationale is identical with an AMF interacting with the nNBs, the 5G OSS and the 5G KPIs database (db). Finally, platform and applications initial tuning according to the desired policy must be performed before starting the system.

Figure 6. Interconnection of SON servers cluster with UMTS and LTE OSS (Centralized architecture).

Section 3 is about the SON applications.  

In section 3.1, the authors claim that "In our review we focus on the most popular applications which are ANR, MLB and CCO, ...". Here the authors have to explain "why these are the most popular applications". 

We fully agree. Changed as follows:

We believe that the most popular applications are ANR, MLB and CCO thus we explain their operation rationale, the factors that led to the need for them, and the issues that they address.

Section 3.2.3 lacks of corresponding references! Authors have to incorporate some related references for this part of the paper.

We fully agree. The following references are added

[60-65, 88]

In section3.2.4, authors have to select a common way of writing abbreviations such as MLB and TS, that is "Mobility Load Balancing" and "Traffic Steering", in all textual cases.

We fully agree.

Changed to the following:

In a similar manner, Mobility Load Balancing (MLB) or Traffic Steering (TS) is one of the key optimization activities applied, either independently, or in combination, in case multiple radio access technologies coexist. The target of MLB is to forward voice and data traffic to the most appropriate frequency/carrier or hierarchy cell layer or radio technology according to the radio parameters policy followed by the network operator. MLB can be applied either in idle or in connected mode states of a UE (Inter/Intra-frequency or Inter-RAT scenarios).

In GSM/UMTS networks static load balancing procedures usually take place while in LTE and 5G mechanisms for MLB are embedded in 3GPP standardized SON functions, leading to autonomous operation based on network counters feedback [36-42, 119-120]. Basic parameters that affect TS concern neighbor cell level parameters related with intra-inter frequency, or intersystem relations, or cell parameters that concern only a specific cell [22,21]. Currently, key mechanisms for TS include tuning of inter- or intra-frequency handover, reselection parameters, Absolute Priorities (AP) (where the UE is informed in idle mode about the priority of a candidate camp frequency or candidate RAT), and Basic Biasing (BB) (i.e., triggering cell selection or reselection in idle mode).

As a definition, network load can be described by the following scenarios, with the first one being the most common [21-23, 119-120].

• Radio resource load related with blocking due to lack of resources.
• BTS/NodeB/eNodeB/gNB hardware resource load.
• Transport/backhaul network resource load.

Figure 8 has to be accompanied with some explanatory text.

We fully agree.

Added the following:

As an example, after MLB changes, handover performance degradation might be noticed and, as expected, problems exist with the MRO application regarding that user’s mobility [21-22,67]. Figure 8 depicts the conflicts that might be created in mobility thresholds (Idle and Connected mode) for the MLB and MRO applications, since both applications interact with Idle and Connected mode thresholds, thus conflicts can easily occur.   

Section 4 is about Machine Learning Algorithms for SON. If compared to all other section, it is very "limited" and related information is given in a brief and occasionally "abstracted" way. Here it is recommended: (i) to extend the textual description, and; (ii) to include more essential references, per case, as in total there are very few related references included in the present version. 

We fully agree.

References [117-118] and [122-124] are added especially for the case of Reinforcement Learning, which is the most recent advance in the field.

We added text on Reinforcement Learning and deep reinforcement learning since these are considered as the most recent advancements on the field of ML for next generation networks. The text is marked in red font.

Section 5 discusses Future SON Research Directions. 

In section 5.1, it is recommended to include an extra figure, for the depiction of the related basic architectural blocks of an NFV architecture, which is actually missing.

Moreover, part of the text mentions that "Moreover C-RAN (Cloud-RAN), or Centralized-RAN, was first proposed as an architecture by China Mobile Research Institute in April 2010 providing a...". The related reference has to be explicitly included in this part of the document.

We fully agree. Reference was added as follows:

Moreover C-RAN (Cloud-RAN), or Centralized-RAN, was first proposed as an architecture by China Mobile Research Institute in April 2010, providing a unified, centralized and Cloud computing solution leading to virtualization of the RAN part of 2G, 3G, 4G and 5G networks [79].

In section 5.2 the authors mention in their text the case of "a Hungarian Algorithm Assisted Clustering (HAAC) approach" for which a dedicated reference also needs to be included!

We fully agree. Reference added:

By combining a Hungarian Algorithm Assisted Clustering (HAAC) approach and a deep learning assisted regression algorithm, cell application characteristics are identified and used for SON optimization, leading to a better classification of useful KPIs per cell and better QoE [92].

Section 5.3 correlates to 2 references, only. Some extra ones need to be included here. Also correct the text by replacing "...to lower SINR values (Related to..." by using "..to lower SINR values (related to..." instead.

We added 1 reference in subsection 5.3 and corrected the relevant text as follows:

The tradeoff for this includes Radio Link Failures (RLFs) due to SINR deterioration (related with handover measurements) and smaller coverage. However, a centralized SON coordinator might improve the former.

In section 5.6 there are no references at all, so it is necessary to incorporate some relevant ones.

We fully agree. The specific section describes the security measures needed as well as typical misconfiguration activities that might cause damage to the SON system. We added an overarching reference here, [121].

We also modified this subsection (5.6) to be more descriptive and added text accordingly. Kindly refer to 5.6

Section 5.8 discusses SON for 6G networks. It is recommended to extend this part by including more discussion and more references.

We fully agree. References [111-115] are added.

Section 6 is about conclusions. This part is somehow "identical" to the abstract of the paper. The authors have to extend the text and provide explicit conclusions, by properly correlating the conceptual sequence of the previous sections.

We fully agree. We changed Section 6 (Conclusions) based on this recommendation.

General Comments 

In general, not all abbreviations in the paper have been explained. For textual conformity and textual homogeneity purposes, the authors must explain all abbreviations in their text. For example UMTS, HSPA, GSM, LTE, BSC, RNC, MME, AMF, PCI, RF, IP, CI, CM, SNMP, PS, UE, BTS, HO, vEPC, 5GEPC, LoRa and M2M are not explained in the core document.   

We fully agree. All the needed abbreviations are explained.

In addition, the authors have to rewrite several of their proposed references to appear in a homogeneous way. Authors have to agree to use the same style for all references belonging to the same category (i.e. journal papers, conference papers, books, websites, projects, etc.). In particular, there is strong differentiation for the cases of conference papers (as in Refs. [11], [12], [61], [62], [64], [65], [67], [68], [75], [88], [92], [95], [98]) that are presented in different ways. The same also stands for the case of journal papers, where only in some cases dois (digital object idnetifiers) are given. For some books, ISBNs are given for some cases. In conclusion, authors have to spend some effort so that to have a homogeneous inclusion of references.

Doi and ISBN information was removed since it is not critical.

Note: All changes are marked in red font in the updated manuscript. Kindly inform us in case any additional changes are needed.

Submission Date

13 February 2022

Date of this review

01 Mar 2022 01:44:13

Author Response File: Author Response.pdf

Reviewer 2 Report

General comments:

The presented review was devoted to the well-known issues related to the self-organizing mobile networks. The topic is particularly timely in 5G systems, because the number of highly differentiated services and the drive to popularize IoT communications mean that the management of all types of resources must be automated. I believe the review paper can be published, but requires significant extensions towards analysis-oriented solutions for 5G/6G.

Detailed comments:

The paper was written in a concise and legible manner, but in order to make it more up-to-date, some extensions and corrections are required:

1. The main part of the paper is presented against the background of the 4G architecture, which makes the study out-of-date. The terms gNB/AMF are not used and the 5G system architecture has not been introduced (3GPP TS 23.501). The 5G system is not the future, it is the present. The C-RAN/O-RAN architecture is the basis of NG-RAN, so it will definitely be used in an advanced version in 6G. Therefore, when analyzing SON solutions for 5G, the C-RAN/O-RAN architecture (3GPP and O-RAN Alliance) and "network slicing" should be in the foreground, which was only mentioned at the beginning and end of the paper. The 3GPP recommendations (TS 28.313_2021.12, TS 28.552_2021.12 and TS 28.541_2021.12) should be the starting point for the 5G-SON analysis. In this respect, the presented analysis results requires a thorough reconstruction !!!
2. I suggest replacing the term "5+G" with "B5G", as it is used in scientific documents.
3. There are sometimes unfortunate phrases like (page 9) "... is the decision with decisions for ...". It is worth reviewing the document in this regard.
4. "SON Applications" in heading 3.2 should be removed.
5. The analysis of ML and AI applications and solutions in 5G/6G-SON should be significantly extended, as it is the key to increasing the efficiency of next generation mobile systems and networks !!!

Summary:

Please focus on the SON solutions dedicated to 5G and 6G of mobile systems. Such a results will be much more interesting for the readers. Descriptions of 3G/4G solutions can be found in academic books. Literature study should be revised towards much newer references.

Author Response

The presented review was devoted to the well-known issues related to the self-organizing mobile networks. The topic is particularly timely in 5G systems, because the number of highly differentiated services and the drive to popularize IoT communications mean that the management of all types of resources must be automated. I believe the review paper can be published, but requires significant extensions towards analysis-oriented solutions for 5G/6G.

Detailed comments:

The paper was written in a concise and legible manner, but in order to make it more up-to-date, some extensions and corrections are required:

1. The main part of the paper is presented against the background of the 4G architecture, which makes the study out-of-date. The terms gNB/AMF are not used and the 5G system architecture has not been introduced (3GPP TS 23.501). The 5G system is not the future, it is the present. The C-RAN/O-RAN architecture is the basis of NG-RAN, so it will definitely be used in an advanced version in 6G. Therefore, when analyzing SON solutions for 5G, the C-RAN/O-RAN architecture (3GPP and O-RAN Alliance) and "network slicing" should be in the foreground, which was only mentioned at the beginning and end of the paper. The 3GPP recommendations (TS 28.313_2021.12, TS 28.552_2021.12 and TS 28.541_2021.12) should be the starting point for the 5G-SON analysis. In this respect, the presented analysis results requires a thorough reconstruction !!!

            We were focused on the description of LTE SON functions as described in TS 32.500. The majority of TS 28.313_2021.12 functions that regard 5G derive from TS 32.500. Moreover section 5 is focused on 5G SON while multiple references are research papers included in relevant sections.

AMF and gNB were added/used at multiple points in the paper.

Figure 4 was changed with cases including 5G.

We fully agree that a 5G architecture scheme is missing, thus we added references [119] and [120], the following description, and Figure 10.

Figure 10. depicts the key entities of a non-roaming 5G architecture as defined by 3GPP in [119]. The basic ones are the following:

• Network Slice Selection Function (NSSF).
• Network Exposure Function (NEF).
• Network Repository Function (NRF).
• Policy Control Function (PCF).
• Unified Data Management (UDM).
• Application Function (AF).
• Network Slice Specific Authentication and Authorization Function (NSSAAF).
• Authentication Server Function (AUSF).
• Access and Mobility Management Function (AMF).
• Session Management Function (SMF).
• Service Communication Proxy (SCP).
• User Equipment (UE).
• (Radio) Access Network ((R)AN).
• User Plane Function (UPF).
• Data Network (DN), e.g. operator services, Internet access or 3rd party services.

Figure 10. Non-Roaming 5G Architecture.

Finally, connection to B5G took place in multiple points.

1. I suggest replacing the term "5G+" with "B5G", as it is used in scientific documents.

We fully agree. Changed.

1. There are sometimes unfortunate phrases like (page 9) "... is the decision with decisions for ...". It is worth reviewing the document in this regard.

We fully agree. Changed.

1. "SON Applications" in heading 3.2 should be removed.

We fully agree.

It has been removed.

1. The analysis of ML and AI applications and solutions in 5G/6G-SON should be significantly extended, as it is the key to increasing the efficiency of next generation mobile systems and networks !!!

We fully agree.

References [117-118] and [122-124] are added especially for the case of Reinforcement Learning, which is the most recent advance in the field.

We added text on Reinforcement Learning and deep reinforcement learning since these are considered as the most recent advancements on the field of ML for next generation networks. The text is marked in red font.

Summary:

Please focus on the SON solutions dedicated to 5G and 6G of mobile systems. Such a results will be much more interesting for the readers. Descriptions of 3G/4G solutions can be found in academic books. Literature study should be revised towards much newer references.

We fully agree. We added references and key points and expanded the text so that the manuscript is focused on SON solutions mainly for 5G systems. 6G references are added as well.

Note: All changes are marked in red font in the updated manuscript. Kindly inform us in case any additional changes are needed.

Submission Date

13 February 2022

Date of this review

20 Feb 2022 17:38:31

Author Response File: Author Response.pdf

Round 2

Reviewer 2 Report

All the recommended corrections indicated in the previous version of the review were taken into account. Thank you for meticulously correcting the paper. I have no further comments.