Next Article in Journal
Classification of Imbalanced Travel Mode Choice to Work Data Using Adjustable SVM Model
Next Article in Special Issue
Deducing of Optical and Electronic Domains Based Distortions in Radio over Fiber Network
Previous Article in Journal
New Frontiers towards Regeneration of the Intervertebral Disc: On Progenitor Cells, Growth Factors and Biomaterials
Previous Article in Special Issue
A Bit-Interleaved Sigma-Delta-Over-Fiber Fronthaul Network for Frequency-Synchronous Distributed Antenna Systems
 
 
Article
Peer-Review Record

A Multi-Provider End-to-End Dynamic Orchestration Architecture Approach for 5G and Future Communication Systems

by José Olimpio Rodrigues Batista, Jr. 1,*,†, Douglas Chagas da Silva 1,2,*,†, Moacyr Martucci, Jr. 1,†, Regina Melo Silveira 1,† and Carlos Eduardo Cugnasca 1,†
Reviewer 1: Anonymous
Reviewer 2:
Submission received: 19 October 2021 / Revised: 2 December 2021 / Accepted: 8 December 2021 / Published: 15 December 2021
(This article belongs to the Special Issue 5G and Beyond Fiber-Wireless Network Communications)

Round 1

Reviewer 1 Report

In this paper, Authors present an Architecture to support network slicing in 5G networks. The proposed topic is sound, and received a lot of interest in the last years. The Authors thoroughly describe their architecture and provide a simulation-based evaluation of it. The paper, however, presents various flaws in the presentation/organization, in the motivation and the description of the performance evaluation, that should be addressed before publication.
More in details, the following considerations are in order:

1) The introduction is effective in presenting the 5G context. However, is not as much effective in motivating the paper and in framing it within the (vast) literature on the topic. Among other things, I suggest authors to explicitly list the contribution of the paper in the introduction.

2) In section 2, a figure would be beneficial to picture the slicing process, especially for a non expert reader.

3) Section 2 does not formulate the problem (as the title states) nor specifies the contribution of the paper. It rather provides a (useful) background on network slicing and sketches a reference architecture. I suggest authors to use this section as background and to explicitly describe the problem and the intended contribution somewhere else (e.g. in the intro)

4) Section 3 provides a good overview of the SotA on NS orchestration. However, it does not highlights what limitations of the SotA are targeted (and solved) by this work. 

5) At page 8, it is stated "the use of AI tools is essential for operating this block due to the need for processing time". What is the meaning of "processing time" in this case? Which block the sentence is referring to? 

6) The paper contains several long sentences, which make some portions of the paper hard to follow. For example, pg. 6 contains a sentence that is 10-lines long.

7) Section 4 begins with a long descriptions of the operations that are followed during NS management. I suggest authors to provide a schematic representation to help the reader following this 2-page description.

8) OMNeT++ and Simu5G have been both described in research papers. I thus suggest authors to cite said works rather than referring to the project websites.

9) In section 5, authors state that they implemented their system on top of OMNeT and Simu5G. It would be interesting to know what are the modules that have been implemented, how they fit into the simulator's architecture, and to which level of detail they are implemented (although accurate, OMNeT is nonetheless a network simulator). Moreover, there is no description of the simulation scenario (apart from the number of nodes). Please describe the main simulation parameters and factors (what is kept constant and what is varied across different scenarios)

Author Response

November 19, 2021

 

Dear Reviewer of Applied Sciences,

 

First of all, we must say that your assessment is very important to improve our work. We believe that we have complied with all requests for review and are respectfully submitting our responses to your questions in the attached file.

Further information about our revised contribution follows in the Manuscript Status section of this submission. All changes made in the manuscript are in red text.

We keep open for any clarification and requests.

Thank you very much for your attention and consideration.

 

Yours Sincerely,

 

We, The authors

Author Response File: Author Response.pdf

Reviewer 2 Report

/* General comments */

  • The introductory part of the paper is very much extensive without providing any added value. There are a lot of pages (around 4) just pointing out other work without any critical review in most of the cited work. This can be reduced by just highlighting the specific related work that justify the proposed solution as beyond state of the art. The space gained can be used for better described the solution.
  • Section 3.2. What is the difference between TIP and MNO in terms of resources? Why this distinction between stakeholders? Please, describe better the purpose of this two type of resource owners.
  • Section 4, p. 7, line 293 onwards. This sequence of actions would be better represented with an accompanying workflow among the entities depicted in Fig. 1. So my suggestion is to add such workflow as a new figure.
  • Section 4, p. 8, steps 4 and 5. For the mentioned provision and simulation actions, what is the actual time employed for the overall slice provision? Which is the order of magnitude?
  • Section 4, p. 8, step 5. The proposed solution leverages on the fact of having visibility of performance, resources, etc, all from different providers. This can be a serious problem, since the providers could not want to expose their internal information to others. How is this solved in a realistic manner?
  • p. 9, line 359. How the isomorphic encryption guarantees the privacy? Please, explian, since mentioning that technique is not sufficient for understanding how it works.
  • p. 9, line 391. When the paper mentions handover, it is not clear if the handover is oriented to use other slices for guaranteeing QoS/QoE, or if it is simply related to the terminal (i.e. UE) handover. 
  • p. 10, line 424. Not clear what 5GIIK is. Please, add any reference.
  • Figure 2. It is not clear nor evident the mapping between components/modules in Fig.1 and Fig. 2. It is necessary to make evident such mapping, to identify the corresponding blocks between figures. As it is presented now, both figures seem to represent decoupled solutions.
  • p. 12, Section 4.1.1. There are modules not described (UNited ...). Why they are not described?
  • Section 4.1.2, line 476.  Why "end-user"? Does it mean a dedicated slice per end-user (i.e., per terminal)? Or does it refer to a slice per vertical? Please, clarify, now is confusing.
  • p. 12, line 491. The authors mention about slice templates, but there is no reference to the work in 3GPP / GSMA to slice templates (especially in GSMA with the definition of generic slice template). Please, comment n the relation with that initiatives, if any.
  • Fig. 3. The interaction between the decision maker and the mobility manager is not depicted in Fig 2, is this consistent? Please, clarify.
  • p. 14, line 562. Mnetion to central UNit and Distributed UNit. This comes from ORAN approach, however these concepts are not introduced previously, and probably there is no reason for doing so. I mean, probably they don't provide value to teh paper, so I suggest to remove. If not, please, provide then some introduction to these concepts. Now they don't provide value.
  • p. 14, lines 570 to 575. A lot of techniques are listed but they are not explained nor detailed. This dies not provide any value. It is better to just mention few (or one) and explaining how it can be applied / can help to the solution. 
  • Section 4.1. The module "multi-provider network slice functions" is not described at all. Please, add justification in the paper why it is not described (if it ccan be justified) or alternatively add a description of the module.
  • p. 16, paragraph starting line 612. Again, it seems the paper refers to a slice per end-user. This seems not very much scalable. Please, clarify the solutions in terms of scalability in some point of the text.
  • Section 4.2.2. It would be convenient also in this section to include a figure as Fig. 4 for the previous section. This can help to clarify the proposal.
  • Section 4.3. The paper considers the selection of slcie per end-user, but there is a problem not solved with this approach whioch is the dependency of the point of attachment (of the user) for determining the slice to be selected. The point of attachment is determined by the operator which with the end-user maintains the commercial relationship (SIM card, FTTH connection, etc). Please, comment on this since it can reduce the degrees of freedom for selecting slices.
  • Fig. 5. The figure is very repetitive. Probably better to represent the graph only one time and mentioning thta the X axis can take different values (i.e., something similar to Fig. 6).
  • p. 20, line 777. How long it takes for being executed? Is the solution viable for a real, operational system? Please, comment on that.
  • Table 6. In a real system, the slice would be selected by a singe test or there would be several tests before deciding teh slice?
  • Table 6. VAR seems to be very large, is that correct? What are the units of the values provided there?
  • Conclusions, line 819. There is a reference to the two components named United..., but they are not explained in the paper!!

/* Editorial comments */

  • There are a number of broken sentences being divided in two lines (e.g., p. 3 lines 96/97, p. 4 lines 157/158, p. 10 lines 418/419, p. 17 lines 697/698
  • p.13, line 520. It seems that section heading is missing.
  • p. 14, lines 561 and 564. Substitue "packages" by "packets"
  • p. 14, line 563. Segment Router -> Segment Routing
  • p. 20, line 764. "... built ... built..." <- please, change one of the two

Author Response

November 19, 2021

 

Dear Reviewer of Applied Sciences,

 

First of all, we must say that your assessment is very important to improve our work. We believe that we have complied with all requests for review and are respectfully submitting our responses to your questions in the attached file.

Further information about our revised contribution follows in the Manuscript Status section of this submission. All changes made in the manuscript are in red text.

We keep open for any clarification and requests.

Thank you very much for your attention and consideration.

 

Yours Sincerely,

 

We, The authors

Author Response File: Author Response.pdf

Round 2

Reviewer 1 Report

Authors answered all my previous comments.

I have a few minor comments still:

1) Table 5 hardly readable

2) Table 6 does not fit the page, having part of data falling outside the page

3) regarding references to OMNeT++ and Simu5G, I still suggest authors to refer the corresponding research papers (not the websites). You might use the references below, which can be found in other papers citing them.

[OMNeT++] Varga, A. and Hornig, R. (2008), "An overview of the OMNeT++ simulation environment", in Proc. SIMUTools '08, Marseille, France, March 2008.

[Simu5G] G. Nardini, D. Sabella, G. Stea, P. Thakkar and A. Virdis, "Simu5G—An OMNeT++ library for end-to-end performance evaluation of 5G networks", IEEE Access, vol. 8, pp. 181176-181191, 2020.

Author Response

Dear Reviewer of Applied Sciences,

 

First of all, we must say that your assessment is very important to improve our work. We believe that we have complied with all requests for review and are respectfully submitting our responses to your questions in the attached file.

Further information about our revised contribution follows in the Manuscript Status section of this submission. All changes made in the manuscript are in red text.

We keep open for any clarification and requests.

Thank you very much for your attention and consideration.

 

Yours Sincerely,

 

We, The authors

Author Response File: Author Response.pdf

Back to TopTop