Streaming and Elastic Traffic Service in 5G-Sliced Wireless Networks and Mutual Utilization of Guaranteed Resource Units

№

Comment / Recommendation

Reply

-

The manuscript presents Preemption-based service Prioritization (PP2) scheme, that merges the capabilities of Resource Reservation (RR) and Service Prioritization (SP) schemes (developed by authors and presented in their previous papers) and realizes the coexistence of streaming and elastic traffic at 5G radio access network. The authors developed a mathematical model of the system, a mathematical model of the proposed scheme and present the results of a comparative analysis between their current and previous works. The introduction does not state the problem clearly. The covered review topic of related works of other authors is not completed, in practice it is missing. Most of the references are not relevant. The paper is not clearly written but is well organized. The authors try to explain the significance of the paper but their claims are not well founded. The paper contribution is difficult to evaluate as the results are not compared with the results of other authors.

Thank you for spending your time and efforts on reviewing our manuscript.

We would like to add the following precisions.

We proposed two slicing strategies: the PP in previous manuscript (https://www.mdpi.com/1999-5903/14/10/299) and the PP2 in current manuscript.

Both strategies resolve the issue of achieving at the same time (i) the mandatory isolation among network slices and (ii) the effective utilization of gNB’s resource.

The difference between the two strategies is that the PP can be applied only among non-TCP streaming slices, while the PP2 — among TCP elastic and/or non-TCP streaming slices. In that sense, comparing PP and PP2 only results in KPI equality (PP == PP2 without TCP elastic slice(s)).

As in the previous manuscript ([10] https://www.mdpi.com/1999-5903/14/10/299), we compare our PP2 slicing strategy with the classical resource reservation (which is widely used by researchers [5, 6, 8]), which solves the isolation problem but does not solve the resource efficiency problem.

Furthermore, we agree with the idea of comparing our PP2 slicing strategy with others in a future work (though we foresee gains for our PP2, since almost all the developed by other researchers slicing strategies are based-on the resource reservation).

1

The abstract does not state the problem clearly enough and the authors’ contribution and must be extended.

We are very thankful for spotting this inconsistency of our manuscript. We updated the abstract (lines 1-10) to bolster its precision about the issue and our contribution:

“Researchers of 5g-sliced Wireless Networks are faced with the task of achieving at the same time (i) the mandatory isolation among network slices and (ii) the effective utilization of resource at Fifth Generation Base Station (gNB). This article proposes the second version of the Preemption-based service Prioritization (PP2) scheme that merges the capabilities of classical Resource Reservation (RR) and Service Prioritization (SP) schemes and realizes the coexistence of non-TCP streaming and TCP elastic traffic at gNB. The proposed PP2 scheme extends its predecessor PP scheme by adding TCP elastic traffic. Analytical methods are given for Dynamic Resource Sharing (DRS) and Dynamic Resource Reallocation (DRR) with data rate reduction and service preemption. As main results, under some baseline scenario, PP2 scheme, in comparison with RR, does increase up to 52 % the minimum data rate utilization in the TCP elastic slice while ensuring 100 % in system capacity utilization.”

2

The key words are not selected appropriately. The abbreviations RAC and QoS should be given in full, “resources” should be “resource allocation”, what is elastic and streaming. TCP and non-TCP are not used in the paper.

We are very grateful for bringing out the flaws in our keywords.

Keywords, according to MDPI, should be “reasonably common within the subject discipline” (see Front Matter at https://www.mdpi.com/journal/information/instructions#preparation).

To the best of our knowledge, the terms “RAC”, “QoS”, “resources”, etc. are very common and specific to our field.

We updated the keywords of our manuscript according to your suggestions at lines 11-12:

“5G, slicing, quality of service, radio admission control, resource allocation, TCP elastic traffic, non-TCP streaming traffic”.

3

The Introduction does not provide a sufficient background and problem description. The cited references are just listed even not in the proper context and not discussed.

Thank you for spotting the absence of such a moment in our manuscript.

The reader can find an extensive overview of information and descriptions of the problem of achieving both (i) mandatory isolation between network slices and (ii) efficient use of the gNB resource in our previous paper ([10] https://www.mdpi.com/1999-5903/14/10/299), where the authors proposed a solution to this problem for the case of a network with only non-TCP streaming slices (without TCP elastic slices).

Note that the analytical approach applied by the authors for the PP and PP2 schemes corresponds to dynamic slice allocation mechanisms, when the resource is re-sliced upon the occurrence of certain events — the receipt of a request for the provision of a service or the end of servicing a request.

We added the following at line 21:

“For the review, we refer the reader to [10].”

The review in [10] can be supplemented by articles on proactive and dynamic slice allocation mechanisms, for example, recent articles added to our manuscript:

“[13] Gonçalves, D.M.; Bittencourt, L.F.; Madeira, E.R. Overhead and Performance of Dynamic Network Slice Allocation for Mobile Users. Future Generation Computer Systems 2024, 160, 739–751. https://doi.org/10.1016/j.future.2024.05.035 

[14] Camargo, J.S.; Coronado, E.; Ramirez, W.; Camps, D.; Deutsch, S.S.; Pérez-Romero, J.; Antonopoulos, A.; Trullols-Cruces, O.; Gonzalez-Diaz, S.; Otura, B.; et al. Dynamic slicing reconfiguration for virtualized 5G networks using ML forecasting of computing capacity. Computer Networks 2023, 236, 110001. https://doi.org/10.1016/j.comnet.2023.110001”, where the authors, among other things, evaluate the impact of network slice reconfiguration overhead on the overall network performance.

4

There is a lack of analysis of related works. The authors should provide more references and discuss each of the works separately with its contributions and limitations in a Section “Related works”.

Thank you for this very welcomed suggestion. A review of related work and a discussion of each work separately with its contributions and limitations is contained in our previous paper [10]. We have taken the liberty not to duplicate the review in this work, which is an extension and continuation of [10], in order to concentrate on the mathematical side related to the coexistence of elastic TCP and non-TCP stream slices.

We added the following at line 21:

“For the review, we refer the reader to [10].”

5

3GPP is a standardization body which creates standards, while Docomo and Ericsson are not created the concept of network slicing.

Thank you for clarifying such an essential moment of our manuscript. We fully agree and have corrected this inaccuracy at lines 22-30:

“The NS concept, standardized by Third Generation Partnrship Project (3GPP) and implemented by Docomo and Ericsson, aims at an efficient resource utilization while meeting the slices aggregated Quality of Service (QoS) requirements [1, 3– 7].”

6

As to 5G standards, the name of 5G base station is gNB and not 5GBS. The authors cannot introduce a new concept for something that is standardized.

We are grateful for this significant precision. Furthermore, we updated the manuscript accordingly at lines 3, 15, 19, etc. by changing “5GBS” into “gNB”.

7

In the new section “Related works” the authors must clearly describe the difference between their works cited as [10] and [12].

Thank you for this very kind and interesting suggestion. We agree that there is no significant difference between these two. Our aim in [12] was to investigate the optimum/maximum number of non-TCP streaming slices that one can parametrize at a gNB. Furthermore, we excluded https://doi.org/10.14357/19922264230113 from the list of references to reduce self-citations.

8

The references [5], [6], [7], [8], [9], [14], [26] etc. are white papers or technical reports which are not appropriate for a scientific paper. In fact, the relevant references are few and 2 of them are self-citations.

Thank you very much for spotting this aspect of our paper. We believe that understanding what revolves around the network slicing (NS) technology from some of the most important telecom bodies/organizations (such as 3gpp, Docomo and Ericsson) is mandatory.

This undoubtedly shows us how they see the NS and how they likely foresee its practical implementation.

In particular, for many scientific papers, and for us also, these documents served as a source for parameterizing the model in numerical analysis. Therefore, we consider it important to retain the references to these sources.

We updated our manuscript by removing [5], [6], [7], [8] and [9] in previous version, and adding the references:

“[5] Vila, I.; Sallent, O.; Umbert, A.; Perez-Romero, J. An Analytical Model for Multi-Tenant Radio Access Networks Supporting Guaranteed Bit Rate Services. IEEE Access 2019, 7, 57651–57662. https://doi.org/10.1109/access.2019.2913323.

[6] Banchs, A.; de Veciana, G.; Sciancalepore, V.; Costa-Perez, X. Resource Allocation for Network Slicing in Mobile Networks. IEEE Access 2020, 8, 214696–214706. https://doi.org/10.1109/access.2020.3040949.

[7] Narmanlioglu, O.; Zeydan, E.; Arslan, S.S. Service-Aware Multi-Resource Allocation in Software-Defined Next Generation Cellular Networks. IEEE Access 2018, 6, 20348–20363. https://doi.org/10.1109/access.2018.2818751.

[8] Fu, X.; Shen, Q.; Wang, W.; Hou, H.; Gao, X. Slice Merging/Spliting Operations and Tenant Profit Optimization Across 5G Base Stations. IEEE Access 2021, 9, 9706–9718. https://doi.org/10.1109/access.2020.3048062.

[14] Khodapanah, B.; Awada, A.; Viering, I.; Francis, J.; Simsek, M.; Fettweis, G.P. Radio Resource Management in context of Network Slicing: What is Missing in Existing Mechanisms? In Proceedings of the 2019 IEEE Wireless Communications and Networking Conference (WCNC). IEEE, 2019, p. 1–7. https://doi.org/10.1109/wcnc.2019.8885942.”

9

When a book is cited, pages must be indicated, see [18], [19], [20], [21], [22], [23], [25].

We thank you for bringing out these flaws of our manuscript. We updated our manuscript accordingly at lines 174-175:

“... an iterative method [21, pp. 103-204], [26, pp. 106-179], [23], [24], [25] …”

10

In the Introduction, the authors must define what is an elastic service, give examples and compare it with the streaming service. Explanation is needed also why elastic services cloud use the slice of streaming services, and why don’t use a slice customized to their needs. For example, for different types of services different functions are configured at RRC, PDCP, RLC, MAC and PHY layers, so slides for elastic services could not be appropriated for streaming services and vice versa.

We once again thank the reviewer for the indispensable criticism that will help to draw attention to the merits of the proposed PP2 method.

An essential feature of our PP2 method is that slices for TCP elastic services can be adapted for non-TCP streaming services and vice versa, while resources for high-priority slices are freed up in low-priority slices by reducing the quality to the allowed minimum of the QoS standards, and if these measures are insufficient - even by interrupting the service of users in low-priority slices.

We note that our approach assumes static location of subscribers. So, for each subscriber, the conditions of radio signal propagation and, consequently, the quality of the radio channel and the bandwidth in Hz that will be required to provide a specific service to this subscriber with the minimum QoS defined by the standards for this service do not change.

The model is built at the top level of abstraction, without particular attention to the configuration details at the RRC, PDCP, RLC, MAC and PHY levels, since the configuration at these levels ultimately results in the required bandwidth in Hz in the gNB radio transmitter frequency range to provide the service with adequate quality. From this point of view we agree that the gNB radio transmitter frequency range may be considered as the resource, then the resource unit is 1Hz. At the same time,  at a fixed static location of users in a cell, for each user, its bandwidth in Hz in the gNB radio frequency range results in the available bitrate (see e.g. [16] https://doi.org/10.1016/j.comcom.2022.02.019), then the resource unit is 1 bit/s.

We chose the bitrate (1 bit/s) as r.u. mainly because the QoS requirements for services are primarily specified in terms of bitrate and latency.

11

In Section 2, the system model needs more explanations (e.g. what is r. u.?).

Thank you very much for this suggestion. We updated the manuscript accordingly at lines 50-54:

“We note that the model is built at the top level of abstraction, without particular 50

attention to the configuration details at the lower layers of OSI/ISO model. Thus, we 51

consider the bitrate (one bit per second) as the resource unit (r.u.) since the Quality of 52

Service (QoS) requirements for services are primarily specified in terms of bitrate. From 53

this point of view, the slice capacity is measured in r.u.”

12

The authors must explain what is slice capacity as a core concept on which their claims are based? The slice is a virtual network defined for a particular user with specific needs. 3GPP specification has defined the following 5G KPIs related to network slicing: Accessibility KPIs: registered subscribers through AMF and UDM, registration success rate per network slice instance (NSI); Integrity KPIs: end-to-end latency of the 5G network, upstream/downstream throughput for Network Slice In stance (NSI) and at N3 interface, RAN-UE throughput; Utilization KPIs: mean number of Protocol Data Unit sessions for NSI, virtualized resource utilization for NSI. If the authors introduce a new concept, they must define it.

Thank you for bringing out this inconsistency of our manuscript.

As in response to comment 10, we note that we picked the bitrate (1 bit/s) as a r.u. since the QoS requirements for services are primarily specified in terms of bitrate. From this point of view, “slice capacity” is measured in resource units.

We are very thankful for reminding the 5G KPIs related to network slicing. We consider the utilization KPIs (18), (19), (22)-(24), and the accessibility KPIs (20), (21) in our manuscript (see [3]).

Furthermore, we updated our manuscript accordingly at lines 205-242, and figures 6-8.

13

What is elastic slice violator? If a customer needs more resources, the respective RAN slices would be allocated to that customer. The authors must consider the scientific woks related to proactive and dynamic slice allocation.

We thank you for this very important question. A slice-violator is a slice (non-TCP streaming or TCP elastic) that uses resource units (r.u.) guaranteed to another slice (slice-owner — also non-TCP streaming or TCP elastic) during time intervals when those r.u. are not required/claimed by that another slice due to a lack of customers.

We updated our manuscript accordingly at lines 82-85:

“Thus, a slice-violator is a slice (non-TCP streaming or TCP elastic slice) that uses r.u. guaranteed to another slice (slice-owner — also non-TCP streaming or TCP elastic slice) during time intervals when those r.u. are not required/claimed by that another slice due to a lack of customers.”

14

All abbreviation must be explained when are used for the first time, e.g. RAC is explained in line 138 and used several times before that.

We thank you for this comment. The term “RAC” with its definition were introduced at line 119:

“Given the above DRS method, we organize the Radio Admission Control (RAC) scheme in such a way that …”

15

What are resource units of a network slice?

Thank you for asking to clarify this essential moment of our manuscript.

As in response to comment 11, we note that the model is built at the top level of abstraction, without particular attention to the configuration details at the lower layers of OSI/ISO model. From this point of view, we picked the bitrate (1 bit/s) as a r.u. since the QoS requirements for services are primarily specified in terms of bitrate. From this point of view, “slice capacity” is measured in resource units.

We updated the manuscript at lines 50-54 to clarify about the resource units (r.u.):

“We note that the model is built at the top level of abstraction, without particular 50

attention to the configuration details at the lower layers of OSI/ISO model. Thus, we 51

consider the bitrate (one bit per second) as the resource unit (r.u.) since the Quality of 52

Service (QoS) requirements for services are primarily specified in terms of bitrate. From 53

this point of view, the slice capacity is measured in r.u.”

For example, following lines 55-61, a customer in non-TCP streaming slice ks needs for service a constant data rate b_ks = 5 r.u., while a customer in TCP elastic slice ke — a minimum data rate b_ke = 8 r.u.

16.0

In Section 4, the authors compare the results of the proposed PP2 scheme with other their works without explaining the essence of their previous works.

Thank you for spotting this unclear moment of our manuscript.

We compare in Section 4 our slicing strategy — the PP2 strategy — with one of the classic and widely used slicing strategies — the resource reservation (RR) strategy, also known as the complete partitioning (CP) strategy in the previous generations of wireless networks ( [5, 6,, 8]) — see response 1.

Unlike PP that ensures isolation while optimizing resource utilization among slices, each providing streaming service (non-TCP streaming slice), PP2 does the same among slices, each providing either streaming or elastic service (TCP elastic-slice).

The classical RR strategy, at the opposite of PP/PP2, ensures slice isolation, but does not optimize resource utilization, especially during network outages.

We updated our manuscript at lines 193-194:

“... the classical RR scheme (Complete Partitioning, where Ck = Qk, k = 1, 2, 3, with C1 + C2 + C3 = 100 % of C) [ 5 ,6, 8] …”

16.1

Postulating that given slice is providing "either streaming or elastic service" (see line 39), but no mix is allowed, narrows the system model down to something like "service-type-based slice" which is rather unusual.

We thank you for this comment, which allows us to concisely clarify our system model. We are building a model for a “service-type-based slice”. Furthermore, we included a mention of this at lines 42-43:

“Thus, we consider a system model with «service-type-based slice» [3,4,10].”

According to 3gpp [TS 28.554, TS 22.261, TS 29.512], each network slice should be dedicated to a single service. Of course, there is also the concept of “intra-slice” that allows one slice to support various service types.

In any case, introducing the concept of intra-slice may well be unnecessary in our manuscript, since one can simply create a new slice to handle any new service type.

16.2

The customer arrival flow might be regarded as Poisson flow (line 47), but especially elastic types of data flows, generated by given user, might be of fatter-tail types of distributions. Besides, the reader, who is youtuber', is left in confusion if on-off type of traffic has to be fit in the proposed system model.

We are grateful for bringing out these possible flaws of our manuscript. As for plenty of papers, the choice of a Poisson flow is due to the possibility of obtaining tractable compact analytical formulas. We agree that for modeling real distributions for elastic traffic, using fatter-tail types of distributions would provide a more realistic estimate of performance indicators. As for modeling serving of streaming traffic, supporting playback continuity and smoothness in our model is provided by isolation requirements while building the model. We know that several mechanisms can be used to ensure playback continuity and smoothness when providing non-TCP streaming media services, for instance, buffering on the UE side. In our manuscript, we consider playback continuity as one of the main constraints when formulating the optimization problem: the threshold b_min is responsible for the playback continuity.

16.3

The introduced abbreviations {r.,s.,t.}u. (lines 47-52) deserve full description and the dimensions for constant (line 49) and minimum (line 51) data rates look like that miss 's' at the end of 'customer'.

Thank you for spotting these unclear moments of our manuscript. We updated the manuscript accordingly at lines 55-61:

“time units (t.u.) … resource units (r.u.) … size units (s.u.)”

16.4

Having denoted the symbols at lines 53 to 58, it seems that in eq. 1 the second sum as restriction is not necessary.

We thank you for noticing this. We completely agree. Therefore, we updated equation 1.

16.5

The assumption (line 62) about "uniform allocation" is another loss of generality for the system model.

Thank you for your important comment. The assumption of uniform distribution of slice resource between users is perhaps the most unpleasant generalization we had to make in order to obtain tractable, compact analytical formulas for performance metrics. We agree that in real life, the resource required (and allocated) to a user to ensure the provision of a service with the required quality depends on the of the user's radio channel’s conditions and may differ for two users from the same slice (receiving the same service). This can definitely be an exciting research topic for the future.

16.6

The lemma should be transformed to definitions as far as both miss clearly outlined proof part.

We thank you for this significant suggestion. It may not be seen as a proof, but the logic behind each lemma is illustrated by annotations in figures 2 and 4.

We transformed the lemmas into definitions.

17

Moderate editing of English language required.

Thank you for suggesting this. We spared no effort in removing the inconsistencies and flaws of our manuscript.

№

Comment / Recommendation

Reply

-

This paper proposes PP2 scheme, improved version of the Preemption-based service Prioritization scheme(PP).  The improvement of this scheme is that it considers the coexistence of streaming and elastic traffic.  The author constructs the system model and mathematical model, then KPI is described so that numerical simulation quantifies the improvement from RR versus PP2.

This paper addresses the improvement of network slicing of 5G base station and is a theoretical contribution.

Network slicing in 5G is still under active development and needs a lot of contribution in both theory and experiment. This is original and relevant to the field.

This scheme is an improvement of already established one called Preemption-based service Prioritization (PP) scheme.

This paper addresses a specific application case where streaming and elastic traffic coexists.

The author tried 5 different scenarios with simulation and their scheme showed improvement of capacity utilization in 4 cases (out of 5 cases).

However, the comparison was made only against Resource Reservation and would like to see the comparison against its predecessor, PP.

Having said that, I still think it is worth publishing the idea, looking forward to the future work.

I hope to see the comparison between PP and PP2 but it is in the future work.  In that sense, the significance of this work is reduced, but I think this paper is constracted in a sound manner over all.

Idea is proposed clearly, KPI is defined, and developed mathematical model for it, and evaluated analytically, and the performance was compared.  The process is good and didn’t find problem.

The references are appropriate and the tables and figures are clear and effective.

We are very thankful for committing time and efforts in reading and evaluating our manuscript.

We would like to add the following precisions.

We proposed two slicing strategies: the PP in previous manuscript (https://www.mdpi.com/1999-5903/14/10/299) and the PP2 in current manuscript.

Both strategies resolve the issue of achieving at the same time (i) the mandatory isolation among network slices and (ii) the effective utilization of gNB’s resource.

The difference between the two strategies is that the PP can be applied only among non-TCP streaming slices, while the PP2 — among TCP elastic and/or non-TCP streaming slices. In that sense, comparing PP and PP2 only results in KPI equality (PP == PP2 without TCP elastic slice(s)).

Furthermore, we are thankful for the idea of comparing our PP2 slicing strategy with others in a future work.