Transient Performance Modelling of 5G Slicing with Mixed Numerologies for Smart Grid Traffic
H. V. Kalpanie Mendis∗, Poul E. Heegaard∗, Vicente Casares-Giner†, Frank Y. Li,‡ and Katina Kralevska∗
∗Department of Information Security and Communication Technology,
NTNU - Norwegian University of Science and Technology, N-7491 Trondheim, Norway
†Department of Communications, Universitat Polit`ecnica de Val`encia, Val`encia 46022, Spain
‡Dept. of Information and Communication Technology, University of Agder (UiA), N-4898 Grimstad, Norway Email:{kalpanie.mendis; poul.heegaard; katinak}@ntnu.no; [email protected]; [email protected]
Abstract—Network slicing enabled by fifth generation (5G) sys- tems has the potential to satisfy diversified service requirements from different vertical industries. As a typical vertical industry, smart distribution grid poses new challenges to communication networks. This paper investigates the behavior of network slicing for smart grid applications in 5G radio access networks with heterogeneous traffic. To facilitate network slicing in such a network, we employ different 5G radio access numerologies for two traffic classes which have distinct radio resource and quality of service requirements. Three multi-dimensional Markov models are developed to assess the transient performance of network slicing for resource allocation with and without traffic priority.
Through analysis and simulations, we investigate the effects of smart grid protection and control traffic on other types of parallel traffic sessions as well as on radio resource utilization.
Index Terms—Markov modelling, RAN slicing, resource allo- cation, smart grid, 5G numerologies.
I. INTRODUCTION
Network slicing is a novel paradigm in fifth generation (5G) systems which facilitates multiple virtual end-to-end (E2E) networks by reserving resources based upon one physical network infrastructure. A network slice is a logical network with specific network capabilities and network characteristics, tailored to offer customized communication services. For instance, different slices could be defined to satisfy the diverse service requirements imposed by the three 5G use cases, i.e., enhanced mobile broadband (eMBB), ultra-reliable low latency communications (URLLC), and massive machine-type communications (mMTC).
An E2E network slice is composed of an access network (wired, or wireless radio access network (RAN)), and a core network(s) (sub-)slices between end users or devices. Recently, there is a surge of interests in RAN-based network slicing from both academia and standardization bodies [1] [2]. For instance, the 3rd generation partnership project (3GPP) is currently investigating RAN support of network slicing [3].
In this paper, we are interested in radio resource allocation in a RAN, which constitutes a part of an E2E network slice, referredto as a RAN slice. The numerology design in 5G new radio (NR) facilitates the flexibility of customized RAN slice design according to the heterogeneous requirements of vertical applications.
Considering the dynamic nature of network traffic, adaptive resource sharing can make network resource utilization more efficient. An approach for radio resource virtualization and RAN resource allocation was proposed in [4]. Targeting at two RAN slices for eMBB and URLLC services, [5] proposed a two-level medium access control (MAC) scheduling algorithm for radio resource sharing and dynamic adjustment. However, resource sharing also brings challenges for slice isolation.
Accordingly, a proof-of-concept prototype for RAN run-time slicing which has the capability of isolating, sharing, and customizing resources for three use cases was demonstrated in [6]. Based on a flexible numerology structure in 5G NR, dynamic resource allocation was formulated as an optimization problem for quality of service (QoS) provisioning given the co-existence of eMBB and URLLC services in [7].Moreover, the authors in [8] presented a QoS-aware resource allocation scheme in multi-carrier systems supported by the flexibility obtained through mixed numerologies.
Considering both guaranteed and non-guaranteed bit rate services, a continuous time Markov chain model for RAN slicing was presented in [9], targeting at characterizing diverse radio resource management strategies in multi-tenant and multi-service 5G scenarios. However, no Markov model which analyzes network slicing and resource allocation at the frame or subframe level in 5G NR exists so far, especially when the transient behavior is of interest.
As network slicing offers context-related and customized services, its applicability to many vertical industries is promis- ing. Power distribution grid is a typical example of a vertical industry as it is regarded to be a critical infrastructure in our modern society. In smart grid applications, power outages must be handled in milliseconds for power operator and consumers.
Hence, mission-critical operations such as protection and control in smart grid cannot be accomplished without URLLC.
In this paper, we apply 5G RAN slicing to smart grid applications with power distribution protection and evaluate its performance considering two types of traffic. More specif- ically, the offered traffic to a 5G RAN is categorized into two traffic classes based on their radio resource, priority, latency, and reliability requirements. For the mission-critical protection message type, the 5G URLLC traffic class is needed [10], and is treated in one RAN slice instance, whereas the background
TABLE I: 5G New Radio numerologies [11]
Numerology,β SCS [kHz] PRB size [kHz] #slots/subframe Cyclic prefix (CP) Symbol duration [µs] CP duration [µs]
0 15 180 1 Normal 71.43 4.69
1 30 360 2 Normal 35.71 2.34
2 60 720 4 Normal, extended 17.86 1.17
3 120 1440 8 Normal 8.92 0.57
4 240 2880 16 Normal 4.46 0.29
traffic type includes both power grid traffic with less restrictive requirements, and traffic from other non-critical services is considered as background traffic in another RAN slice. The radio link between end devices and their associated next generation NodeB (gNb) is considered to have limited capacity for each network slice and its resource utilization is assessed.
In a nutshell, the main contributions of this paper include (i) the proposed criteria for selecting the most preferable numerology for a set of services and under given network conditions; and (ii) performance assessment of 5G RAN slicing with hybrid numerologies to support heterogeneous traffic classes, focusing on the transient behavior of sliced networks. To do so, three multi-dimensional Markov models are developed and applied to smart grid operations (which receive high priority due to their stringent low latency and high reliability requirements).
The remainder of this paper is organized as follows. Sec. II summarizes 5G NR and numerology schemes, and introduces various message types that are defined for grid protection and control. Then the network scenario is presented in Sec. III, and the proposed multi-dimensional Markov models are presented in Sec. IV. Afterwards, qualitative and quantitative results are presented in Sec. V. Finally, Sec. VI concludes the paper.
II. PRELIMINARIES
5G NR defines a flexible time-frequency lattice, enabling a multi-numerology structure. Thanks to this flexibility, NR is capable of providing services across diverse usage scenarios.
A. 5G New Radio
5G frequency range 1 (FR-1) includes sub-6GHz frequency bands and is envisaged to carry much of the traditional cellular communication traffic in low traffic density areas. At higher frequency bands from 24.25 GHz to 52.6 GHz, frequency range 2 (FR-2) aims at providing ultra-high data rate capability within short ranges in high density traffic areas. As 5G NR can be operated in both wider and narrower channel bandwidth, the orthogonal frequency division multiplexing (OFDM) sub- carrier spacing (SCS) has to scale accordingly so that the complexity of fast Fourier transformation (FFT) does not increase exponentially with wider bandwidth.
Compared with long term evolution (LTE) and LTE- advanced (LTE-A) that support carrier bandwidth up to 20 MHz with a fixed 15 kHz OFDM SCS, 5G NR offers scalable OFDM numerology to support diverse spectrum bands and deployment modes. This is achieved by enabling multiple numerologies obtained by multiplying the basic LTE/LTE- A SCS with 2β where β is an integer between 0 and 4.
Tab. I presents the main features of each of the 5 numerology structures defined in 5G NR [11].
The resource grid of 5G NR comprises of a set of physical resource blocks (PRBs). A PRB in NR is defined as the product of 12 consecutive SCSs in the frequency domain and one OFDM symbol in the time domain. For downlink traffic, one PRB is the smallest frequency-time unit that can be assigned to a device or user equipment (UE). The same as in LTE/LTE-A, one NR frame contains 10 sub-frames each lasting for 1 ms. With different number of slots within one sub- frame, flexible resource allocation with various granularity is enabled. However, the number of OFDM symbols within one slot does not change with numerology and it remains as 14.
A contiguous set of PRBs selected for a given numerology is referred to as a bandwidth part (BWP).
A network slice may contain a certain number of BWPs and PRBs. Depending on the amount of radio resources a service provider owns as well as the types of services and traffic volume, it may define a network slice for a specific type of service or a common slice for multiple types of services.
Both static and dynamic slice configuration are possible.
B. Communication Requirements in Smart DistributionGrid Various smart distribution grid operations impose diverse communication service requirements in terms of latency, band- width, reliability, security, etc. Therefore, smart grid applica- tions may benefit from a scalable and flexible communication architecture which can be realized through 5G network slic- ing. A few power grid operation examples are analyzed and multiple service requirements are specified in [12].
Intelligent electronic device (IED) refers to any device that has processing and communication capabilities. These devices are expected to exchange information with a control panel and to make decisions based on the information they receive.
Furthermore, international electrotechnical commission (IEC) 61850 is a standard that defines a set of communica- tion protocols and abstracts data models for IEDs. The IEC 61850 standard defines two real-time, peer-to-peer communi- cation methods: sampled values (SV) messaging and generic object oriented substation event (GOOSE) messaging. For measurement-type communications, SV messages are adopted and the data transmission frequency is pre-configured by the distribution grid operator. On the other hand, GOOSE is typically event driven and this type of messages will be generated when an event (e.g., alarm, failure, or any mission- critical event) occurs. In [10], different message types used for distribution grid protection and control are categorized according to two key performance requirements (availability
and latency) and mapped onto the three major 5G use cases presented above.
GOOSE messaging is operated based on a publisher- subscriber mechanism with its messages broadcast over a local network to all devices that are listening to or have subscribed to the network. For achieving higher reliability for information dissemination, a GOOSE message may be sent more than once. To reduce latency, no acknowledgement mechanism is introduced. Therefore, URLLC service is expected in order to ensure reliable operation as well as to meet the real-time requirement of GOOSE transmissions.
When there is no GOOSE event, a publishing IED sends heartbeat messages at a time interval of tmax = 1000 [ms] to all subscribing IEDs. If a receiving IED does not receive a GOOSE message within2·tmax, it will regard that the sending IED as being offline [13]. The publishing IED which notices a failure, for instance in a feeder, will change the payload of the GOOSE message accordingly and send it instantly. The IED will go to a mode referred to as the fast repetition mode and will send the above GOOSE message repeatedly every5 [ms]
until the network has been recovered.
III. NETWORKSCENARIO
In this study, we focus on a common 5G NR infrastructure where the radio resources belonging to the same RAN (con- sidering a service provider with a common network infrastruc- ture)are shared by two types of services with multiple tenants.
Two network slices are available and are managed by(a single) management and orchestration (MANO) entity. The envisaged scenario is illustrated in Fig. 1 where two network slices share the samephysicalresources but these two types of services are separated by two logical network slices. The considered two traffic types are GOOSE messages (for smart distribution grid protection and control traffic) served by sliceS1and interactive video sessions (either adaptive or non-adaptive) served by sliceS2, respectively. Three network configurations (NCs) are investigated in this study, as presented below.
• NC1: Both traffic types are mapped onto a shared network resource pool (shown in Fig. 1) and no priority is given to the GOOSE traffic.
• NC2: Within the shared resource pool, higher priority is given to GOOSE messages and coexisting video sessions are non-adaptive. By non-adaptive, it is meant that a video session always runs at a full rate and it will be dropped or rejected if no sufficient resource is available.
• NC3: The same as in NC2 but coexisting video sessions are adaptive. By adaptive, it is meant that a video session may be operated at a downgraded rate (at a half rate in this work) with less resources instead of being dropped as in NC2. It may be dropped if the resource is still insufficient for downgraded flows.
In a multi-tenant environment with a shared RAN, the physical or virtual infrastructure resources may be dedicated to a network slice or shared with other network slices. In order to guarantee performance isolation and to avoid service interruptions, resources maybe pre-reserved for a specific
Protection IED Protection IED Protection IED
core network CDN SCADA
Distributed production GOOSE
Video Network slice
<latexit sha1_base64="D+hbAi/C4Gj+8le0NgM7IxfVh0A=">AAAB9HicbVDLSgMxFL1TX7W+qi7dBIvgqsyIqMuCG5cV7QPaoWTS2zY0kxmTTKEM/Q43LhRx68e482/MtLPQ1gOBwzn3ck9OEAuujet+O4W19Y3NreJ2aWd3b/+gfHjU1FGiGDZYJCLVDqhGwSU2DDcC27FCGgYCW8H4NvNbE1SaR/LRTGP0QzqUfMAZNVbyuyE1I0ZF+jDreb1yxa26c5BV4uWkAjnqvfJXtx+xJERpmKBadzw3Nn5KleFM4KzUTTTGlI3pEDuWShqi9tN56Bk5s0qfDCJlnzRkrv7eSGmo9TQM7GQWUi97mfif10nM4MZPuYwTg5ItDg0SQUxEsgZInytkRkwtoUxxm5WwEVWUGdtTyZbgLX95lTQvqt5V1bu/rNQu8zqKcAKncA4eXEMN7qAODWDwBM/wCm/OxHlx3p2PxWjByXeO4Q+czx+3DJIF</latexit>
S1
<latexit sha1_base64="/dlbSbaPU9aIow9S7yIfPBrXwo8=">AAAB9HicbVDLSgMxFL1TX7W+qi7dBIvgqsyUoi4LblxWtA9oh5JJM21oJhmTTKEM/Q43LhRx68e482/MtLPQ1gOBwzn3ck9OEHOmjet+O4WNza3tneJuaW//4PCofHzS1jJRhLaI5FJ1A6wpZ4K2DDOcdmNFcRRw2gkmt5nfmVKlmRSPZhZTP8IjwUJGsLGS34+wGRPM04f5oDYoV9yquwBaJ15OKpCjOSh/9YeSJBEVhnCsdc9zY+OnWBlGOJ2X+ommMSYTPKI9SwWOqPbTReg5urDKEIVS2ScMWqi/N1IcaT2LAjuZhdSrXib+5/USE974KRNxYqggy0NhwpGRKGsADZmixPCZJZgoZrMiMsYKE2N7KtkSvNUvr5N2repdVb37eqVRz+sowhmcwyV4cA0NuIMmtIDAEzzDK7w5U+fFeXc+lqMFJ985hT9wPn8AuJCSBg==</latexit>
S2
<latexit sha1_base64="sslTsIb+c0HxeeqHSNqy4GCvVeA=">AAAB8nicbVDLSsNAFL2pr1pfVZduBovgqiQi6rLgxmVF+4A2lMl00g6dTMLMjVBCP8ONC0Xc+jXu/BsnbRbaemDgcM69zLknSKQw6LrfTmltfWNzq7xd2dnd2z+oHh61TZxqxlsslrHuBtRwKRRvoUDJu4nmNAok7wST29zvPHFtRKwecZpwP6IjJULBKFqp148ojhmV2cNsUK25dXcOskq8gtSgQHNQ/eoPY5ZGXCGT1Jie5yboZ1SjYJLPKv3U8ISyCR3xnqWKRtz42TzyjJxZZUjCWNunkMzV3xsZjYyZRoGdzCOaZS8X//N6KYY3fiZUkiJXbPFRmEqCMcnvJ0OhOUM5tYQyLWxWwsZUU4a2pYotwVs+eZW0L+reVd27v6w1Los6ynACp3AOHlxDA+6gCS1gEMMzvMKbg86L8+58LEZLTrFzDH/gfP4AiWqRYQ==</latexit>
S
Fig. 1: Illustration of the network scenario. SCADA stands for supervisory control and data acquisition.
network slice. However, it is worth mentioning that in our scenario no resources are reserved to the GOOSE traffic so that the idle resources inS1can be utilized by other types of traffic (background, video, etc.)if no GOOSE event occurs.
IV. MARKOVMODELS
In this paper, we apply Markov loss models [14] to study and quantify the cross-dependence between network slices hosting GOOSE and video sessions. We compare configura- tions with and without priority between the slices (priority of GOOSE over video). In what follows, we present first the basic loss model, and then develop three models which are dedicated to the three network configurations explained above.
Afterwards, a number of performance metrics are defined.
A. Generic System Model andn-Dimensional Loss Model To develop Markov models for the system with three NCs presented in Sec. III, we have defined the system state as ω = {ω1,· · · , ωn}, where ωi ∈ [0;si] is the number of active sessions of service type i, si the maximum number of session of typei, andnthe number of traffic types. Then- dimensional state space is denoted byΩ. The number of active sessions at timetisM(t) ={M1(t),· · ·, Mn(t)},M(t)∈Ω.
These notations will be used in Subsec. IV-E when we define performance metrics. λi(ω)is the arrival rate, 1/µi(ω)is the expected session duration,δi is the number of resource blocks per session, and lastlyC denotes the total number of resource blocks (i.e., the system capacity).
All times in the system are assumed to be exponentially distributed, i.e., the events are generated by Poisson processes.
Hence, the system models in this paper are Markovian. Al- though the effect of this assumption may be further inves- tigated, we believe that the results obtained based on our models provide valuable insight on network behavior, espe- cially during the transient period when a GOOSE burst is the injected. The GOOSE bursts are modelled as a train of GOOSE packets with their interarrival times much shorter than the time between video sessions, and hence, the consequence of assuming exponential instead of any other general distribution is negligible.
Based on the generic system model, we develop a basic n-dimensional loss model, where each dimension is a traffic type. A type is either defined by the slice (k≤n) it belongs
GOOSE session completion
video session completion
GOOSE priority:
discarding a video session rejected
sufficient capacity
GOOSE session arrival
<latexit sha1_base64="6kvCVE7zVDZcHzd90jbjWHFezNY=">AAAB8HicbVDLSgMxFL1TX7W+qi7dBIvgQsqMiLosuHFZwdZKO5RMJtOG5jEkGaEM/Qo3LhRx6+e4829M21lo64HA4Zxzyb0nSjkz1ve/vdLK6tr6RnmzsrW9s7tX3T9oG5VpQltEcaU7ETaUM0lblllOO6mmWEScPkSjm6n/8ES1YUre23FKQ4EHkiWMYOukxx530Rj3g3615tf9GdAyCQpSgwLNfvWrFyuSCSot4diYbuCnNsyxtoxwOqn0MkNTTEZ4QLuOSiyoCfPZwhN04pQYJUq7Jy2aqb8nciyMGYvIJQW2Q7PoTcX/vG5mk+swZzLNLJVk/lGScWQVml6PYqYpsXzsCCaauV0RGWKNiXUdVVwJweLJy6R9Xg8u6/7dRa1xVtRRhiM4hlMI4AoacAtNaAEBAc/wCm+e9l68d+9jHi15xcwh/IH3+QNh15AQ</latexit>
1
sufficient capacity
rejected video session arrival
<latexit sha1_base64="HZJvzphrEuiXWWk4qz0txxtsp9k=">AAAB8HicbVDLSgMxFL1TX7W+qi7dBIvgQspMEXVZcOOygn1IO5RMJtOGJpkhyQhl6Fe4caGIWz/HnX9jOp2Fth4IHM45l9x7goQzbVz32ymtrW9sbpW3Kzu7e/sH1cOjjo5TRWibxDxWvQBrypmkbcMMp71EUSwCTrvB5Hbud5+o0iyWD2aaUF/gkWQRI9hY6XHAbTTEw8awWnPrbg60SryC1KBAa1j9GoQxSQWVhnCsdd9zE+NnWBlGOJ1VBqmmCSYTPKJ9SyUWVPtZvvAMnVklRFGs7JMG5erviQwLracisEmBzVgve3PxP6+fmujGz5hMUkMlWXwUpRyZGM2vRyFTlBg+tQQTxeyuiIyxwsTYjiq2BG/55FXSadS9q7p7f1lrXhR1lOEETuEcPLiGJtxBC9pAQMAzvMKbo5wX5935WERLTjFzDH/gfP4AY1uQEQ==</latexit>
2
<latexit sha1_base64="AaOP+cUlZYD2JoIxtsJgHHMW+mw=">AAAB+nicbZDLSgMxFIbPeK31NtWlm2ARXEiZKVJdFty4rGAv0A5DJs20oUlmSDJKqX0UNy4UceuTuPNtTNtZaOsPgY//nMM5+aOUM20879tZW9/Y3Nou7BR39/YPDt3SUUsnmSK0SRKeqE6ENeVM0qZhhtNOqigWEaftaHQzq7cfqNIskfdmnNJA4IFkMSPYWCt0S71E0AEO/YscqqFb9ireXGgV/BzKkKsRul+9fkIyQaUhHGvd9b3UBBOsDCOcTou9TNMUkxEe0K5FiQXVwWR++hSdWaeP4kTZJw2au78nJlhoPRaR7RTYDPVybWb+V+tmJr4OJkymmaGSLBbFGUcmQbMcUJ8pSgwfW8BEMXsrIkOsMDE2raINwV/+8iq0qhW/VvHvLsv1Wh5HAU7gFM7Bhyuowy00oAkEHuEZXuHNeXJenHfnY9G65uQzx/BHzucPY7eTZg==</latexit>
!1, !2
<latexit sha1_base64="Wtv1DfJP9LO9yEzcDS6NFA9b1Wg=">AAAB/HicbZDLSsNAFIYnXmu9Rbt0M1iELrQkRdRlwY3LCvYCbQiT6aQdOpcwMxFCqK/ixoUibn0Qd76N0zYLbf1h4OM/53DO/FHCqDae9+2srW9sbm2Xdsq7e/sHh+7RcUfLVGHSxpJJ1YuQJowK0jbUMNJLFEE8YqQbTW5n9e4jUZpK8WCyhAQcjQSNKUbGWqFbGUhORij0zwtoXPihW/Xq3lxwFfwCqqBQK3S/BkOJU06EwQxp3fe9xAQ5UoZiRqblQapJgvAEjUjfokCc6CCfHz+FZ9YZwlgq+4SBc/f3RI641hmPbCdHZqyXazPzv1o/NfFNkFORpIYIvFgUpwwaCWdJwCFVBBuWWUBYUXsrxGOkEDY2r7INwV/+8ip0GnX/qu7fX1abtSKOEjgBp6AGfHANmuAOtEAbYJCBZ/AK3pwn58V5dz4WrWtOMVMBf+R8/gBEq5PK</latexit>
!1, !2 1
<latexit sha1_base64="THawPzm5ZktmL/mDKHbuBxw0t8Q=">AAAB/HicbZDLSsNAFIYnXmu9Rbt0M1iEglKSIuqy4MZlBXuBNoTJdNIOnUuYmQgh1Fdx40IRtz6IO9/GaZuFtv4w8PGfczhn/ihhVBvP+3bW1jc2t7ZLO+Xdvf2DQ/fouKNlqjBpY8mk6kVIE0YFaRtqGOkliiAeMdKNJrezeveRKE2leDBZQgKORoLGFCNjrdCtDCQnIxT6FwU0zv3QrXp1by64Cn4BVVCoFbpfg6HEKSfCYIa07vteYoIcKUMxI9PyINUkQXiCRqRvUSBOdJDPj5/CM+sMYSyVfcLAuft7Ikdc64xHtpMjM9bLtZn5X62fmvgmyKlIUkMEXiyKUwaNhLMk4JAqgg3LLCCsqL0V4jFSCBubV9mG4C9/eRU6jbp/VffvL6vNWhFHCZyAU1ADPrgGTXAHWqANMMjAM3gFb86T8+K8Ox+L1jWnmKmAP3I+fwBBoZPI</latexit>
!1, !2+ 1
<latexit sha1_base64="xXJID6TccGPnZfe5HhtKdLjdeX4=">AAAB/HicbZDLSsNAFIYnXmu9Rbt0M1iELrQkRdRlwY3LCvYCbQiT6aQdOpcwMxFCqK/ixoUibn0Qd76N0zYLbf1h4OM/53DO/FHCqDae9+2srW9sbm2Xdsq7e/sHh+7RcUfLVGHSxpJJ1YuQJowK0jbUMNJLFEE8YqQbTW5n9e4jUZpK8WCyhAQcjQSNKUbGWqFbGUhORij0L/zzAhuhW/Xq3lxwFfwCqqBQK3S/BkOJU06EwQxp3fe9xAQ5UoZiRqblQapJgvAEjUjfokCc6CCfHz+FZ9YZwlgq+4SBc/f3RI641hmPbCdHZqyXazPzv1o/NfFNkFORpIYIvFgUpwwaCWdJwCFVBBuWWUBYUXsrxGOkEDY2r7INwV/+8ip0GnX/qu7fX1abtSKOEjgBp6AGfHANmuAOtEAbYJCBZ/AK3pwn58V5dz4WrWtOMVMBf+R8/gBBtZPK</latexit>
!1 1, !2
<latexit sha1_base64="iuIFJHDQSgCyFEJYpAUoTFrVebI=">AAAB/HicbZDLSsNAFIYnXmu9Rbt0M1iEglKSIuqy4MZlBXuBNoTJdNIOnUuYmQgh1Fdx40IRtz6IO9/GaZuFtv4w8PGfczhn/ihhVBvP+3bW1jc2t7ZLO+Xdvf2DQ/fouKNlqjBpY8mk6kVIE0YFaRtqGOkliiAeMdKNJrezeveRKE2leDBZQgKORoLGFCNjrdCtDCQnIxT65/5FgY3QrXp1by64Cn4BVVCoFbpfg6HEKSfCYIa07vteYoIcKUMxI9PyINUkQXiCRqRvUSBOdJDPj5/CM+sMYSyVfcLAuft7Ikdc64xHtpMjM9bLtZn5X62fmvgmyKlIUkMEXiyKUwaNhLMk4JAqgg3LLCCsqL0V4jFSCBubV9mG4C9/eRU6jbp/VffvL6vNWhFHCZyAU1ADPrgGTXAHWqANMMjAM3gFb86T8+K8Ox+L1jWnmKmAP3I+fwA+mZPI</latexit>
!1+ 1, !2
<latexit sha1_base64="Ki3fTZnBY5IO3VmyquAYKEspZNg=">AAACAXicbVDLSgMxFM3UV62vUTeCm2ARCmqZFFGXBTcuK9gHdIYhk2baYJIZkoxQSt34K25cKOLWv3Dn35i2s9DWAxdOzrmX3HuilDNtPO/bKSwtr6yuFddLG5tb2zvu7l5LJ5kitEkSnqhOhDXlTNKmYYbTTqooFhGn7ej+euK3H6jSLJF3ZpjSQOC+ZDEj2FgpdA/8RNA+DtEJOvV9mL9qZyh0y17VmwIuEpSTMsjRCN0vv5eQTFBpCMdad5GXmmCElWGE03HJzzRNMbnHfdq1VGJBdTCaXjCGx1bpwThRtqSBU/X3xAgLrYcisp0Cm4Ge9ybif143M/FVMGIyzQyVZPZRnHFoEjiJA/aYosTwoSWYKGZ3hWSAFSbGhlayIaD5kxdJq1ZFF1V0e16uV/I4iuAQHIEKQOAS1MENaIAmIOARPINX8OY8OS/Ou/Mxay04+cw++APn8wfvdJUw</latexit>
!1+ 1,
!2 1
<latexit sha1_base64="WRDVyh5J2KQmHkgBXx6As73QEQg=">AAAB9XicbVDLSgMxFM3UV62vqks3wSK4kDIRUZcFNy4r2Ad0xiGTZtrQPIYko5Sh/+HGhSJu/Rd3/o1pOwttPXDhcM693HtPnHJmrO9/e6WV1bX1jfJmZWt7Z3evun/QNirThLaI4kp3Y2woZ5K2LLOcdlNNsYg57cSjm6nfeaTaMCXv7TilocADyRJGsHXSQ6AEHeAIwUBkEYqqNb/uzwCXCSpIDRRoRtWvoK9IJqi0hGNjeshPbZhjbRnhdFIJMkNTTEZ4QHuOSiyoCfPZ1RN44pQ+TJR2JS2cqb8nciyMGYvYdQpsh2bRm4r/eb3MJtdhzmSaWSrJfFGScWgVnEYA+0xTYvnYEUw0c7dCMsQaE+uCqrgQ0OLLy6R9XkeXdXR3UWucFXGUwRE4BqcAgSvQALegCVqAAA2ewSt48568F+/d+5i3lrxi5hD8gff5A5X9kdk=</latexit>
!1µ1
<latexit sha1_base64="/r2ySx3rjl4xuCtPPg1NwAeSYIg=">AAAB9XicbVBNS8NAEJ34WetX1aOXxSJ4kJIUUY8FLx4r2A9oYthsN+3S3WzY3Sgl9H948aCIV/+LN/+N2zYHbX0w8Hhvhpl5UcqZNq777aysrq1vbJa2yts7u3v7lYPDtpaZIrRFJJeqG2FNOUtoyzDDaTdVFIuI0040upn6nUeqNJPJvRmnNBB4kLCYEWys9OBLQQc4rCNfZGE9rFTdmjsDWiZeQapQoBlWvvy+JJmgiSEca93z3NQEOVaGEU4nZT/TNMVkhAe0Z2mCBdVBPrt6gk6t0kexVLYSg2bq74kcC63HIrKdApuhXvSm4n9eLzPxdZCzJM0MTch8UZxxZCSaRoD6TFFi+NgSTBSztyIyxAoTY4Mq2xC8xZeXSbte8y5r3t1FtXFexFGCYziBM/DgChpwC01oAQEFz/AKb86T8+K8Ox/z1hWnmDmCP3A+fwCZC5Hb</latexit>
!2µ2
Fig. 2:State(ω1, ω2)of the model with non-adaptive video sessions.
to, or a traffic type (e.g., full rate or downgraded rate video).
An arrival of a new session of type i will be rejected if no sufficient capacity (in terms of resource blocks) is available, i.e., Pn
j=1δj(ωj+ 1i)> C, where 1i= 1 whenj=i, and 0 otherwise.
Note that the model presented in this subsection is generic and it can be applied to multiple types of services. In what follows, we develop three models where n= 2 for NC1 and NC2 and n= 3 for NC3 respectively, dedicated to the three network configurations presented in Sec. III.
B. Model for NC1: Non-Priority, Non-Adaptive Video Traffic A system with two traffic classes (GOOSE and non-adaptive video) and no priority between these classes (e.g., they are mapped onto the same network resource pool) can be modelled by the generic Markov model introduced above.
The general state (ω1, ω2) of this Markov model is illus- trated in Fig. 2 (with the transition to the state “GOOSE priority” disabled). The yellow labels explain the events and the conditions that cause the transition. λ1 is the GOOSE session arrival rate and λ2 is the video session arrival rate, whileµ1andµ2are the session departure rates of GOOSE and video traffic, respectively. Note that if there is not sufficient capacity C upon the arrival of either class, the session is rejected, e.g., if (ω1+ 1)δ1+ω2δ2 > C ≥ ω1δ1 +ω2δ2, a GOOSE session arrival will be rejected. This is due to the fact that in NC1 no priority is given to the GOOSE traffic.
C. Model for NC2: Priority, Non-Adaptive Video Traffic To model a system with two traffic classes (GOOSE and non-adaptive video) but now with priority on the GOOSE ses- sions (e.g., each class has its own network slice), the Markov model in Fig. 2 is slightly updated. If a GOOSE session arrives in a state with insufficient capacity to accommodate both GOOSE and video session, then the system will discard an ongoing video session and accept the GOOSE session. If all PRBs are occupied by GOOSE sessions, new arrivals (both video and GOOSE) will be rejected. This is illustrated by the transition to the state “GOOSE priority” (the state marked in purple) in the same figure.
GOOSE session completion
video session completion
downgraded video session completion
sufficient capacity, accept new GOOSE session
downgrading a video session
discarding a video session sufficient capacity,
accept new video session
downgrading a video session and accept the new session
rejected
rejected
discarding a downgraded video session accepting a downgraded video session
<latexit sha1_base64="6kvCVE7zVDZcHzd90jbjWHFezNY=">AAAB8HicbVDLSgMxFL1TX7W+qi7dBIvgQsqMiLosuHFZwdZKO5RMJtOG5jEkGaEM/Qo3LhRx6+e4829M21lo64HA4Zxzyb0nSjkz1ve/vdLK6tr6RnmzsrW9s7tX3T9oG5VpQltEcaU7ETaUM0lblllOO6mmWEScPkSjm6n/8ES1YUre23FKQ4EHkiWMYOukxx530Rj3g3615tf9GdAyCQpSgwLNfvWrFyuSCSot4diYbuCnNsyxtoxwOqn0MkNTTEZ4QLuOSiyoCfPZwhN04pQYJUq7Jy2aqb8nciyMGYvIJQW2Q7PoTcX/vG5mk+swZzLNLJVk/lGScWQVml6PYqYpsXzsCCaauV0RGWKNiXUdVVwJweLJy6R9Xg8u6/7dRa1xVtRRhiM4hlMI4AoacAtNaAEBAc/wCm+e9l68d+9jHi15xcwh/IH3+QNh15AQ</latexit>
1
<latexit sha1_base64="HZJvzphrEuiXWWk4qz0txxtsp9k=">AAAB8HicbVDLSgMxFL1TX7W+qi7dBIvgQspMEXVZcOOygn1IO5RMJtOGJpkhyQhl6Fe4caGIWz/HnX9jOp2Fth4IHM45l9x7goQzbVz32ymtrW9sbpW3Kzu7e/sH1cOjjo5TRWibxDxWvQBrypmkbcMMp71EUSwCTrvB5Hbud5+o0iyWD2aaUF/gkWQRI9hY6XHAbTTEw8awWnPrbg60SryC1KBAa1j9GoQxSQWVhnCsdd9zE+NnWBlGOJ1VBqmmCSYTPKJ9SyUWVPtZvvAMnVklRFGs7JMG5erviQwLracisEmBzVgve3PxP6+fmujGz5hMUkMlWXwUpRyZGM2vRyFTlBg+tQQTxeyuiIyxwsTYjiq2BG/55FXSadS9q7p7f1lrXhR1lOEETuEcPLiGJtxBC9pAQMAzvMKbo5wX5935WERLTjFzDH/gfP4AY1uQEQ==</latexit>
2 video session
arrival
GOOSE session arrival
<latexit sha1_base64="3kP9MDu40tX/0pgmLQB5wzfttkA=">AAACBnicbZDLSgMxFIYzXmu9jboUIVgEwVImVdRlwY3LCvYC7TBk0kwbmkyGJCOUoSs3voobF4q49Rnc+Tam7Sy09YfAx3/O4eT8YcKZNp737Swtr6yurRc2iptb2zu77t5+U8tUEdogkkvVDrGmnMW0YZjhtJ0oikXIaSsc3kzqrQeqNJPxvRkl1Be4H7OIEWysFbhHXSloHwfoDJVzrJZhTueBW/Iq3lRwEVAOJZCrHrhf3Z4kqaCxIRxr3UFeYvwMK8MIp+NiN9U0wWSI+7RjMcaCaj+bnjGGJ9bpwUgq+2IDp+7viQwLrUcitJ0Cm4Ger03M/2qd1ETXfsbiJDU0JrNFUcqhkXCSCewxRYnhIwuYKGb/CskAK0yMTa5oQ0DzJy9Cs1pBlxV0d1GqlfM4CuAQHINTgMAVqIFbUAcNQMAjeAav4M15cl6cd+dj1rrk5DMH4I+czx/zxpdz</latexit>
!1+ 1, !2, !3
<latexit sha1_base64="oXhYam4RmCXhewRthLEgBlrS0co=">AAACBnicbZDLSgMxFIYzXmu9jboUIVgEF7VMqqjLghuXFewF2mHIpJk2NJkMSUYoQ1dufBU3LhRx6zO4821M21lo6w+Bj/+cw8n5w4QzbTzv21laXlldWy9sFDe3tnd23b39ppapIrRBJJeqHWJNOYtpwzDDaTtRFIuQ01Y4vJnUWw9UaSbjezNKqC9wP2YRI9hYK3CPulLQPg7QGSrnWC3DnM4Dt+RVvKngIqAcSiBXPXC/uj1JUkFjQzjWuoO8xPgZVoYRTsfFbqppgskQ92nHYowF1X42PWMMT6zTg5FU9sUGTt3fExkWWo9EaDsFNgM9X5uY/9U6qYmu/YzFSWpoTGaLopRDI+EkE9hjihLDRxYwUcz+FZIBVpgYm1zRhoDmT16EZrWCLivo7qJUK+dxFMAhOAanAIErUAO3oA4agIBH8AxewZvz5Lw4787HrHXJyWcOwB85nz/29pd1</latexit>
!1 1, !2, !3
<latexit sha1_base64="f8Y6AZZ98zxU4U+hLKKIpp8Z/AQ=">AAACBnicbZDLSgMxFIYzXmu9jboUIVgEF7VMqqjLghuXFewF2mHIpJk2NJkMSUYoQ1dufBU3LhRx6zO4821M21lo6w+Bj/+cw8n5w4QzbTzv21laXlldWy9sFDe3tnd23b39ppapIrRBJJeqHWJNOYtpwzDDaTtRFIuQ01Y4vJnUWw9UaSbjezNKqC9wP2YRI9hYK3CPulLQPg5QOYfqGSrDnM8Dt+RVvKngIqAcSiBXPXC/uj1JUkFjQzjWuoO8xPgZVoYRTsfFbqppgskQ92nHYowF1X42PWMMT6zTg5FU9sUGTt3fExkWWo9EaDsFNgM9X5uY/9U6qYmu/YzFSWpoTGaLopRDI+EkE9hjihLDRxYwUcz+FZIBVpgYm1zRhoDmT16EZrWCLivo7qJUK+dxFMAhOAanAIErUAO3oA4agIBH8AxewZvz5Lw4787HrHXJyWcOwB85nz/57Jd1</latexit>
!1, !2 1, !3
<latexit sha1_base64="QrCTfqwQQj7u68vjcAsHwVluXoE=">AAACBnicbZDLSgMxFIYzXmu9jboUIVgEF7VMqqjLghuXFewF2mHIpJk2NJkMSUYoQ1dufBU3LhRx6zO4821M21lo6w+Bj/+cw8n5w4QzbTzv21laXlldWy9sFDe3tnd23b39ppapIrRBJJeqHWJNOYtpwzDDaTtRFIuQ01Y4vJnUWw9UaSbjezNKqC9wP2YRI9hYK3CPulLQPg5QOYdqGeZ0foYCt+RVvKngIqAcSiBXPXC/uj1JUkFjQzjWuoO8xPgZVoYRTsfFbqppgskQ92nHYowF1X42PWMMT6zTg5FU9sUGTt3fExkWWo9EaDsFNgM9X5uY/9U6qYmu/YzFSWpoTGaLopRDI+EkE9hjihLDRxYwUcz+FZIBVpgYm1zRhoDmT16EZrWCLivo7qJUK+dxFMAhOAanAIErUAO3oA4agIBH8AxewZvz5Lw4787HrHXJyWcOwB85nz/8xpd1</latexit>
!1, !2, !3 1
<latexit sha1_base64="vFl7Xkv8RUPTBFTlZLzhPuSEQhc=">AAACBHicbZC7SgNBFIZn4y3G26plmsEgWISwG0UtAzaWEcwFkmWZncwmQ+ayzMwKYUlh46vYWChi60PY+TZOki008YeBj/+cw5nzRwmj2njet1NYW9/Y3Cpul3Z29/YP3MOjtpapwqSFJZOqGyFNGBWkZahhpJsognjESCca38zqnQeiNJXi3kwSEnA0FDSmGBlrhW65LzkZotCv5lCvwpzOQ7fi1by54Cr4OVRArmbofvUHEqecCIMZ0rrne4kJMqQMxYxMS/1UkwThMRqSnkWBONFBNj9iCk+tM4CxVPYJA+fu74kMca0nPLKdHJmRXq7NzP9qvdTE10FGRZIaIvBiUZwyaCScJQIHVBFs2MQCworav0I8QgphY3Mr2RD85ZNXoV2v+Zc1/+6i0qjmcRRBGZyAM+CDK9AAt6AJWgCDR/AMXsGb8+S8OO/Ox6K14OQzx+CPnM8fEP2XAw==</latexit>
!1, !2, !3
<latexit sha1_base64="BDylguf7IQwlShQQN3Cz5bM0++Q=">AAACBnicbZDLSgMxFIYzXmu9jboUIVgEwVImVdRlwY3LCvYC7TBk0kwbmkyGJCOUoSs3voobF4q49Rnc+Tam7Sy09YfAx3/O4eT8YcKZNp737Swtr6yurRc2iptb2zu77t5+U8tUEdogkkvVDrGmnMW0YZjhtJ0oikXIaSsc3kzqrQeqNJPxvRkl1Be4H7OIEWysFbhHXSloHweonEP1DJVhzueBW/Iq3lRwEVAOJZCrHrhf3Z4kqaCxIRxr3UFeYvwMK8MIp+NiN9U0wWSI+7RjMcaCaj+bnjGGJ9bpwUgq+2IDp+7viQwLrUcitJ0Cm4Ger03M/2qd1ETXfsbiJDU0JrNFUcqhkXCSCewxRYnhIwuYKGb/CskAK0yMTa5oQ0DzJy9Cs1pBlxV0d1GqlfM4CuAQHINTgMAVqIFbUAcNQMAjeAav4M15cl6cd+dj1rrk5DMH4I+czx/2zpdz</latexit>
!1, !2+ 1, !3
<latexit sha1_base64="DWSmJMC+8EGn8aq8efKsYjF07gA=">AAACBnicbZDLSgMxFIYzXmu9jboUIVgEwVImVdRlwY3LCvYC7TBk0kwbmkyGJCOUoSs3voobF4q49Rnc+Tam7Sy09YfAx3/O4eT8YcKZNp737Swtr6yurRc2iptb2zu77t5+U8tUEdogkkvVDrGmnMW0YZjhtJ0oikXIaSsc3kzqrQeqNJPxvRkl1Be4H7OIEWysFbhHXSloHweonEO1DHM6P0OBW/Iq3lRwEVAOJZCrHrhf3Z4kqaCxIRxr3UFeYvwMK8MIp+NiN9U0wWSI+7RjMcaCaj+bnjGGJ9bpwUgq+2IDp+7viQwLrUcitJ0Cm4Ger03M/2qd1ETXfsbiJDU0JrNFUcqhkXCSCewxRYnhIwuYKGb/CskAK0yMTa5oQ0DzJy9Cs1pBlxV0d1GqlfM4CuAQHINTgMAVqIFbUAcNQMAjeAav4M15cl6cd+dj1rrk5DMH4I+czx/5vJdz</latexit>
!1, !2, !3+ 1
<latexit sha1_base64="S4bOjH+NHJW90Z5wEuf5MfJfKJ4=">AAACEnicbVDLSgMxFM3UVx1foy7dBIugWMukigpuCm5cVrAP6AxDJs20oZnMkGSEUvoNbvwVNy4UcevKnX9j2s5CqxcC53EvN/eEKWdKu+6XVVhYXFpeKa7aa+sbm1vO9k5TJZkktEESnsh2iBXlTNCGZprTdiopjkNOW+HgeuK37qlULBF3ephSP8Y9wSJGsDZS4Bx5SUx7OEDHqOx50M5ptQwNy8npCYLeVeCU3Io7LfgXoByUQF71wPn0ugnJYio04VipDnJT7Y+w1IxwOra9TNEUkwHu0Y6BAsdU+aPpSWN4YJQujBJpntBwqv6cGOFYqWEcms4Y676a9ybif14n09GlP2IizTQVZLYoyjjUCZzkA7tMUqL50ABMJDN/haSPJSbapGibEND8yX9Bs1pB5xV0e1aqlfM4imAP7INDgMAFqIEbUAcNQMADeAIv4NV6tJ6tN+t91lqw8pld8Kusj29uwZq6</latexit>
!1+ 1,
!2,
!3 1
<latexit sha1_base64="d4yThBIlTWG3a051H158PbdeHvU=">AAACFHicbVDLSgMxFM34rPU16tJNsAhCa5lUUcFNwY3LCvYBnWHIpJk2NJkZkoxQhn6EG3/FjQtF3Lpw59+YtrPQ1guB87iXm3uChDOlHefbWlpeWV1bL2wUN7e2d3btvf2WilNJaJPEPJadACvKWUSbmmlOO4mkWASctoPhzcRvP1CpWBzd61FCPYH7EQsZwdpIvl12Y0H72EdlVHFdWMxp7RRVoOE5PSsj6F77dsmpOtOCiwDloATyavj2l9uLSSpopAnHSnWRk2gvw1Izwum46KaKJpgMcZ92DYywoMrLpkeN4bFRejCMpXmRhlP190SGhVIjEZhOgfVAzXsT8T+vm+rwystYlKSaRmS2KEw51DGcJAR7TFKi+cgATCQzf4VkgCUm2uRYNCGg+ZMXQatWRRdVdHdeqlfyOArgEByBE4DAJaiDW9AATUDAI3gGr+DNerJerHfrY9a6ZOUzB+BPWZ8/WlObKg==</latexit>
!1+ 1,
!2 1,
!3+ 1
<latexit sha1_base64="OVUdyYpNS4a9zk6aqoVPnLzpgjs=">AAACEnicbVDLSgMxFM3UVx1foy7dBIugWMukigpuCm5cVrAP6AxDJs20oZnMkGSEUvoNbvwVNy4UcevKnX9j2s5CqxcC53EvN/eEKWdKu+6XVVhYXFpeKa7aa+sbm1vO9k5TJZkktEESnsh2iBXlTNCGZprTdiopjkNOW+HgeuK37qlULBF3ephSP8Y9wSJGsDZS4Bx5SUx7OEDHqOx50M5p9QSVoeE5PYXeVeCU3Io7LfgXoByUQF71wPn0ugnJYio04VipDnJT7Y+w1IxwOra9TNEUkwHu0Y6BAsdU+aPpSWN4YJQujBJpntBwqv6cGOFYqWEcms4Y676a9ybif14n09GlP2IizTQVZLYoyjjUCZzkA7tMUqL50ABMJDN/haSPJSbapGibEND8yX9Bs1pB5xV0e1aqlfM4imAP7INDgMAFqIEbUAcNQMADeAIv4NV6tJ6tN+t91lqw8pld8Kusj29rUZq6</latexit>
!1+ 1,
!2 1,
!3
<latexit sha1_base64="XGBMJ+ypinFTxy702HXL5RWPiBA=">AAACEnicbVDLSgMxFM3UVx1foy7dBIugWMukigpuCm5cVrAP6AxDJs20ocnMkGSEUvoNbvwVNy4UcevKnX9j2s5CqxcC53EvN/eEKWdKu+6XVVhYXFpeKa7aa+sbm1vO9k5TJZkktEESnsh2iBXlLKYNzTSn7VRSLEJOW+HgeuK37qlULInv9DClvsC9mEWMYG2kwDnyEkF7OEBlz4N2TqonqAwNz+npcRV6V4FTcivutOBfgHJQAnnVA+fT6yYkEzTWhGOlOshNtT/CUjPC6dj2MkVTTAa4RzsGxlhQ5Y+mJ43hgVG6MEqkebGGU/XnxAgLpYYiNJ0C676a9ybif14n09GlP2Jxmmkak9miKONQJ3CSD+wySYnmQwMwkcz8FZI+lphok6JtQkDzJ/8FzWoFnVfQ7VmpVs7jKII9sA8OAQIXoAZuQB00AAEP4Am8gFfr0Xq23qz3WWvBymd2wa+yPr4Bc8Kauw==</latexit>
!1,
!2 1,
!3+ 2
Fig. 3:State(ω1, ω2, ω3)of the Markov model of the high priority GOOSE sessions and adaptive video sessions.
D. Model for NC3: Priority, Adaptive Video Traffic
To avoid discarding too many ongoing video sessions, an alternative is to downgrade their service rates. This means that less resource blocks are needed per session (i.e.,δiis reduced) after downgrading. The consequence is either a lower quality (by changing encoding scheme for instance to an embedded scheme with lower resolution) or increased download times.
To model the behavior of NC3 where both full rate and downgraded rate video sessions coexist, we extend the model presented above by introducing one more dimension to form a 3-dimensional model(ω1, ω2, ω3), whereω3 is the number of downgraded video sessions andδ3< δ2. With this update, the arrival of a GOOSE session will then be accepted despite insufficient capacity, since we can downgrade a video session instead of discarding it. If the system capacity is still insuffi- cient after downgrading all ongoing video sessions, a GOOSE session could still be rejected. Similarly, upon the arrival of a video session to a state with insufficient capacity, the system first tries to downgrade it before it is rejected. A detailed transition diagram for this model is illustrated in Fig. 3. See the yellow labels in the figure for further explanations.
E. Performance Metrics
For performance comparison among the different configu- rations, a set of performance metrics are defined. Recall that Mi(t) is the number of sessions of type i at time t and ci(t) = Mi(t)δi is the number of resource blocks occupied by type i at time t. This gives the total number of resource blocks at timetas C(t) =Pn
i=1ci(t). Accordingly,resource block utilization, denoted byρ(t), is defined as the number of physical resource blocks normalized by the total capacity, i.e., ρ(t) =C(t)/C (ρis the utilization whent→ ∞).
<latexit sha1_base64="wZ50VXNQIEPPbBA+3KyDWl2DHTY=">AAAB9HicbVDLSgMxFL3js9ZX1aWbYBVclRkRdVlw47KifUA7lDtp2oZmMmOSKZSh3+HGhSJu/Rh3/o2ZdhbaeiBwOOde7skJYsG1cd1vZ2V1bX1js7BV3N7Z3dsvHRw2dJQoyuo0EpFqBaiZ4JLVDTeCtWLFMAwEawaj28xvjpnSPJKPZhIzP8SB5H1O0VjJ74RohhRF+jDtut1S2a24M5Bl4uWkDDlq3dJXpxfRJGTSUIFatz03Nn6KynAq2LTYSTSLkY5wwNqWSgyZ9tNZ6Ck5s0qP9CNlnzRkpv7eSDHUehIGdjILqRe9TPzPayemf+OnXMaJYZLOD/UTQUxEsgZIjytGjZhYglRxm5XQISqkxvZUtCV4i19eJo2LindV8e4vy9XTvI4CHMMJnIMH11CFO6hBHSg8wTO8wpszdl6cd+djPrri5DtH8AfO5w+wuJH0</latexit>
S0
<latexit sha1_base64="wZ50VXNQIEPPbBA+3KyDWl2DHTY=">AAAB9HicbVDLSgMxFL3js9ZX1aWbYBVclRkRdVlw47KifUA7lDtp2oZmMmOSKZSh3+HGhSJu/Rh3/o2ZdhbaeiBwOOde7skJYsG1cd1vZ2V1bX1js7BV3N7Z3dsvHRw2dJQoyuo0EpFqBaiZ4JLVDTeCtWLFMAwEawaj28xvjpnSPJKPZhIzP8SB5H1O0VjJ74RohhRF+jDtut1S2a24M5Bl4uWkDDlq3dJXpxfRJGTSUIFatz03Nn6KynAq2LTYSTSLkY5wwNqWSgyZ9tNZ6Ck5s0qP9CNlnzRkpv7eSDHUehIGdjILqRe9TPzPayemf+OnXMaJYZLOD/UTQUxEsgZIjytGjZhYglRxm5XQISqkxvZUtCV4i19eJo2LindV8e4vy9XTvI4CHMMJnIMH11CFO6hBHSg8wTO8wpszdl6cd+djPrri5DtH8AfO5w+wuJH0</latexit>
S0
<latexit sha1_base64="u6tX7b2h/nz8KPXtoVJ8roY59zQ=">AAAB9HicbVDLSgMxFL3js9ZX1aWbYBVclRkRdVlw47KifUA7lEyatqGZzJjcKZSh3+HGhSJu/Rh3/o2ZdhbaeiBwOOde7skJYikMuu63s7K6tr6xWdgqbu/s7u2XDg4bJko043UWyUi3Amq4FIrXUaDkrVhzGgaSN4PRbeY3x1wbEalHnMTcD+lAib5gFK3kd0KKQ0Zl+jDtet1S2a24M5Bl4uWkDDlq3dJXpxexJOQKmaTGtD03Rj+lGgWTfFrsJIbHlI3ogLctVTTkxk9noafkzCo90o+0fQrJTP29kdLQmEkY2MkspFn0MvE/r51g/8ZPhYoT5IrND/UTSTAiWQOkJzRnKCeWUKaFzUrYkGrK0PZUtCV4i19eJo2LindV8e4vy9XTvI4CHMMJnIMH11CFO6hBHRg8wTO8wpszdl6cd+djPrri5DtH8AfO5w+yPJH1</latexit>
S1
<latexit sha1_base64="u6tX7b2h/nz8KPXtoVJ8roY59zQ=">AAAB9HicbVDLSgMxFL3js9ZX1aWbYBVclRkRdVlw47KifUA7lEyatqGZzJjcKZSh3+HGhSJu/Rh3/o2ZdhbaeiBwOOde7skJYikMuu63s7K6tr6xWdgqbu/s7u2XDg4bJko043UWyUi3Amq4FIrXUaDkrVhzGgaSN4PRbeY3x1wbEalHnMTcD+lAib5gFK3kd0KKQ0Zl+jDtet1S2a24M5Bl4uWkDDlq3dJXpxexJOQKmaTGtD03Rj+lGgWTfFrsJIbHlI3ogLctVTTkxk9noafkzCo90o+0fQrJTP29kdLQmEkY2MkspFn0MvE/r51g/8ZPhYoT5IrND/UTSTAiWQOkJzRnKCeWUKaFzUrYkGrK0PZUtCV4i19eJo2LindV8e4vy9XTvI4CHMMJnIMH11CFO6hBHRg8wTO8wpszdl6cd+djPrri5DtH8AfO5w+yPJH1</latexit>
S1
<latexit sha1_base64="2042vybx5dlS9cJISUZiNLUlmnM=">AAAB9HicbVDLSgMxFL1TX7W+qi7dBKvgqswUUZcFNy4r2ge0Q8mkmTY0k4xJplCGfocbF4q49WPc+Tdm2llo64HA4Zx7uScniDnTxnW/ncLa+sbmVnG7tLO7t39QPjxqaZkoQptEcqk6AdaUM0GbhhlOO7GiOAo4bQfj28xvT6jSTIpHM42pH+GhYCEj2FjJ70XYjAjm6cOsX+uXK27VnQOtEi8nFcjR6Je/egNJkogKQzjWuuu5sfFTrAwjnM5KvUTTGJMxHtKupQJHVPvpPPQMnVtlgEKp7BMGzdXfGymOtJ5GgZ3MQuplLxP/87qJCW/8lIk4MVSQxaEw4chIlDWABkxRYvjUEkwUs1kRGWGFibE9lWwJ3vKXV0mrVvWuqt79ZaV+ltdRhBM4hQvw4BrqcAcNaAKBJ3iGV3hzJs6L8+58LEYLTr5zDH/gfP4As8CR9g==</latexit>
S2
<latexit sha1_base64="2042vybx5dlS9cJISUZiNLUlmnM=">AAAB9HicbVDLSgMxFL1TX7W+qi7dBKvgqswUUZcFNy4r2ge0Q8mkmTY0k4xJplCGfocbF4q49WPc+Tdm2llo64HA4Zx7uScniDnTxnW/ncLa+sbmVnG7tLO7t39QPjxqaZkoQptEcqk6AdaUM0GbhhlOO7GiOAo4bQfj28xvT6jSTIpHM42pH+GhYCEj2FjJ70XYjAjm6cOsX+uXK27VnQOtEi8nFcjR6Je/egNJkogKQzjWuuu5sfFTrAwjnM5KvUTTGJMxHtKupQJHVPvpPPQMnVtlgEKp7BMGzdXfGymOtJ5GgZ3MQuplLxP/87qJCW/8lIk4MVSQxaEw4chIlDWABkxRYvjUEkwUs1kRGWGFibE9lWwJ3vKXV0mrVvWuqt79ZaV+ltdRhBM4hQvw4BrqcAcNaAKBJ3iGV3hzJs6L8+58LEYLTr5zDH/gfP4As8CR9g==</latexit>
S2
<latexit sha1_base64="jqZ9WuV+zg61IXhFu68nczUxXYA=">AAAB9HicbVDLSgMxFL1TX7W+qi7dBKvgqsyoqMuCG5cV7QPaoWTSTBuaScYkUyhDv8ONC0Xc+jHu/Bsz7Sy09UDgcM693JMTxJxp47rfTmFldW19o7hZ2tre2d0r7x80tUwUoQ0iuVTtAGvKmaANwwyn7VhRHAWctoLRbea3xlRpJsWjmcTUj/BAsJARbKzkdyNshgTz9GHau+iVK27VnQEtEy8nFchR75W/un1JkogKQzjWuuO5sfFTrAwjnE5L3UTTGJMRHtCOpQJHVPvpLPQUnVqlj0Kp7BMGzdTfGymOtJ5EgZ3MQupFLxP/8zqJCW/8lIk4MVSQ+aEw4chIlDWA+kxRYvjEEkwUs1kRGWKFibE9lWwJ3uKXl0nzvOpdVb37y0rtJK+jCEdwDGfgwTXU4A7q0AACT/AMr/DmjJ0X5935mI8WnHznEP7A+fwBtUSR9w==</latexit>
S3
<latexit sha1_base64="jqZ9WuV+zg61IXhFu68nczUxXYA=">AAAB9HicbVDLSgMxFL1TX7W+qi7dBKvgqsyoqMuCG5cV7QPaoWTSTBuaScYkUyhDv8ONC0Xc+jHu/Bsz7Sy09UDgcM693JMTxJxp47rfTmFldW19o7hZ2tre2d0r7x80tUwUoQ0iuVTtAGvKmaANwwyn7VhRHAWctoLRbea3xlRpJsWjmcTUj/BAsJARbKzkdyNshgTz9GHau+iVK27VnQEtEy8nFchR75W/un1JkogKQzjWuuO5sfFTrAwjnE5L3UTTGJMRHtCOpQJHVPvpLPQUnVqlj0Kp7BMGzdTfGymOtJ5EgZ3MQupFLxP/8zqJCW/8lIk4MVSQ+aEw4chIlDWA+kxRYvjEEkwUs1kRGWKFibE9lWwJ3uKXl0nzvOpdVb37y0rtJK+jCEdwDGfgwTXU4A7q0AACT/AMr/DmjJ0X5935mI8WnHznEP7A+fwBtUSR9w==</latexit>
S3
<latexit sha1_base64="k4CM4OOLwhHICS4MkKdSjpR/83o=">AAAB9HicbVDLSgMxFL1TX7W+qi7dBKvgqsxIUZcFNy4r2ge0Q8mkmTY0k4xJplCGfocbF4q49WPc+Tdm2llo64HA4Zx7uScniDnTxnW/ncLa+sbmVnG7tLO7t39QPjxqaZkoQptEcqk6AdaUM0GbhhlOO7GiOAo4bQfj28xvT6jSTIpHM42pH+GhYCEj2FjJ70XYjAjm6cOsX+uXK27VnQOtEi8nFcjR6Je/egNJkogKQzjWuuu5sfFTrAwjnM5KvUTTGJMxHtKupQJHVPvpPPQMnVtlgEKp7BMGzdXfGymOtJ5GgZ3MQuplLxP/87qJCW/8lIk4MVSQxaEw4chIlDWABkxRYvjUEkwUs1kRGWGFibE9lWwJ3vKXV0nrsupdVb37WqV+ltdRhBM4hQvw4BrqcAcNaAKBJ3iGV3hzJs6L8+58LEYLTr5zDH/gfP4AtsiR+A==</latexit>
S4
<latexit sha1_base64="k4CM4OOLwhHICS4MkKdSjpR/83o=">AAAB9HicbVDLSgMxFL1TX7W+qi7dBKvgqsxIUZcFNy4r2ge0Q8mkmTY0k4xJplCGfocbF4q49WPc+Tdm2llo64HA4Zx7uScniDnTxnW/ncLa+sbmVnG7tLO7t39QPjxqaZkoQptEcqk6AdaUM0GbhhlOO7GiOAo4bQfj28xvT6jSTIpHM42pH+GhYCEj2FjJ70XYjAjm6cOsX+uXK27VnQOtEi8nFcjR6Je/egNJkogKQzjWuuu5sfFTrAwjnM5KvUTTGJMxHtKupQJHVPvpPPQMnVtlgEKp7BMGzdXfGymOtJ5GgZ3MQuplLxP/87qJCW/8lIk4MVSQxaEw4chIlDWABkxRYvjUEkwUs1kRGWGFibE9lWwJ3vKXV0nrsupdVb37WqV+ltdRhBM4hQvw4BrqcAcNaAKBJ3iGV3hzJs6L8+58LEYLTr5zDH/gfP4AtsiR+A==</latexit>
S4
cell size
frequency
U R L L C m
M T C
eMBB
cell size
frequency URLLC
eMBB mMTC
<latexit sha1_base64="aDGMeEDAPPfuxbrpIaiUTs0h4SM=">AAAB7nicbVDLSgNBEOyNrxhfUY9eBoPgKeyKqMegF48RzAOSJcxOepMhsw9meoUQ8hFePCji1e/x5t84SfagiQUNRVU33V1BqqQh1/12CmvrG5tbxe3Szu7e/kH58KhpkkwLbIhEJbodcINKxtggSQrbqUYeBQpbwehu5reeUBuZxI80TtGP+CCWoRScrNTqBki85/XKFbfqzsFWiZeTCuSo98pf3X4isghjEoob0/HclPwJ1ySFwmmpmxlMuRjxAXYsjXmExp/Mz52yM6v0WZhoWzGxufp7YsIjY8ZRYDsjTkOz7M3E/7xORuGNP5FxmhHGYrEozBSjhM1+Z32pUZAaW8KFlvZWJoZcc0E2oZINwVt+eZU0L6reVdV7uKzUbvM4inACp3AOHlxDDe6hDg0QMIJneIU3J3VenHfnY9FacPKZY/gD5/MH7kaPTg==</latexit>
1
<latexit sha1_base64="etOIa2rNhn6zcWjrWwwvBOmY4ag=">AAAB7nicbVDLSgNBEOz1GeMr6tHLYBA8hd0g6jHoxWME84BkCbOT3mTI7IOZXiGEfIQXD4p49Xu8+TdOkj1oYkFDUdVNd1eQKmnIdb+dtfWNza3twk5xd2//4LB0dNw0SaYFNkSiEt0OuEElY2yQJIXtVCOPAoWtYHQ381tPqI1M4kcap+hHfBDLUApOVmp1AyTeq/ZKZbfizsFWiZeTMuSo90pf3X4isghjEoob0/HclPwJ1ySFwmmxmxlMuRjxAXYsjXmExp/Mz52yc6v0WZhoWzGxufp7YsIjY8ZRYDsjTkOz7M3E/7xORuGNP5FxmhHGYrEozBSjhM1+Z32pUZAaW8KFlvZWJoZcc0E2oaINwVt+eZU0qxXvquI9XJZrt3kcBTiFM7gAD66hBvdQhwYIGMEzvMKbkzovzrvzsWhdc/KZE/gD5/MH78qPTw==</latexit>
2
<latexit sha1_base64="7zEZUqDMj2YJyIR+t7kJKrjmh7U=">AAAB7nicbVBNS8NAEJ3Ur1q/qh69BIvgqSQq6rHoxWMFawttKJvtpF262YTdiVBKf4QXD4p49fd489+4bXPQ1gcDj/dmmJkXplIY8rxvp7Cyura+UdwsbW3v7O6V9w8eTZJpjg2eyES3QmZQCoUNEiSxlWpkcSixGQ5vp37zCbURiXqgUYpBzPpKRIIzslKzEyKx7nm3XPGq3gzuMvFzUoEc9W75q9NLeBajIi6ZMW3fSykYM02CS5yUOpnBlPEh62PbUsViNMF4du7EPbFKz40SbUuRO1N/T4xZbMwoDm1nzGhgFr2p+J/Xzii6DsZCpRmh4vNFUSZdStzp725PaOQkR5YwroW91eUDphknm1DJhuAvvrxMHs+q/mXVv7+o1G7yOIpwBMdwCj5cQQ3uoA4N4DCEZ3iFNyd1Xpx352PeWnDymUP4A+fzB/FOj1A=</latexit>
3
<latexit sha1_base64="QktByrfA5m++wsxKjGtsq32y7L4=">AAAB7nicbVDLSgNBEOyNrxhfUY9eBoPgKeyKqMegF48RzAOSJcxOepMhsw9meoUQ8hFePCji1e/x5t84SfagiQUNRVU33V1BqqQh1/12CmvrG5tbxe3Szu7e/kH58KhpkkwLbIhEJbodcINKxtggSQrbqUYeBQpbwehu5reeUBuZxI80TtGP+CCWoRScrNTqBki8d9krV9yqOwdbJV5OKpCj3it/dfuJyCKMSShuTMdzU/InXJMUCqelbmYw5WLEB9ixNOYRGn8yP3fKzqzSZ2GibcXE5urviQmPjBlHge2MOA3NsjcT//M6GYU3/kTGaUYYi8WiMFOMEjb7nfWlRkFqbAkXWtpbmRhyzQXZhEo2BG/55VXSvKh6V1Xv4bJSu83jKMIJnMI5eHANNbiHOjRAwAie4RXenNR5cd6dj0VrwclnjuEPnM8f8tKPUQ==</latexit>
4
<latexit sha1_base64="S4uK+GLZv6kpGuW9Kaf8h1E7awQ=">AAAB7nicbVDLSgNBEOyNrxhfUY9eBoPgKeyKqMegF48RzAOSJcxOepMhsw9meoUQ8hFePCji1e/x5t84SfagiQUNRVU33V1BqqQh1/12CmvrG5tbxe3Szu7e/kH58KhpkkwLbIhEJbodcINKxtggSQrbqUYeBQpbwehu5reeUBuZxI80TtGP+CCWoRScrNTqBki85/bKFbfqzsFWiZeTCuSo98pf3X4isghjEoob0/HclPwJ1ySFwmmpmxlMuRjxAXYsjXmExp/Mz52yM6v0WZhoWzGxufp7YsIjY8ZRYDsjTkOz7M3E/7xORuGNP5FxmhHGYrEozBSjhM1+Z32pUZAaW8KFlvZWJoZcc0E2oZINwVt+eZU0L6reVdV7uKzUbvM4inACp3AOHlxDDe6hDg0QMIJneIU3J3VenHfnY9FacPKZY/gD5/MH7MKPTQ==</latexit>
0
FR-1 FR-2
Fig. 4:Criteria for numerology selections.
A GOOSE burst duration (T) is the time period from the instant when the first GOOSE session enters the system to the instant when all GOOSE sessions have left the system.
To measure the impact of GOOSE burst arrivals on video traffic, we define three other metrics, as the ratios of the number of rejected, downgraded, and discarded video sessions and the number of arrivals over the observation period (nga).
These ratios are denoted by rvr, rvdw, and rvdc, respectively.
Furthermore, the ratio of a rejected video session (without GOOSE) is rv.
To study the transient effect of GOOSE sessions, we further define a GOOSE burst period, denoted by Tg, as the time duration from injecting sg sessions at time instant TI until they are completed, Tg = max({t|Mg(t)>0})−TI, where Mg(t)is the number of GOOSE sessions at timet.
F. Simulation of Markov Models
From the Markov models developed above, the performance metrics introduced in Subsec. IV-E can be obtained. For steady state analysis, solutions such as Kaufman-Roberts [15] [16]
can be applied (in our case for the non-priority case, NC1).
For transient solutions which is the focus in the paper, we apply simulation of the Markov model [17]. Performing Markov simulations based on the models we developed above (shown in Fig. 2 and Fig. 3 respectively) is a viable alternative for performance evaluation of transient network behavior.
Obtaining closed-form analytical expressions for transient be- havior is rather complicated or intangible, and it is thus beyond the scope of this paper. See Subsec. V-B for more details on simulation of Markov chains.
V. QUALITATIVE ANDQUANTITATIVEASSESSMENTS
This section discusses selection of numerology qualitatively and presents the network performance quantitatively.
A. Qualitative Considerations of Numerology Selection One objective of this paper is to investigate the tradeoffs to be made in mapping traffic classes to 5G numerologies with respect to resource utilization with network slicing.
1) Mapping traffic classes to numerologies: In general, the selection of numerology will depend upon various factors including type of deployment (i.e., dense urban, rural, urban macro etc.), carrier frequency, service requirements (latency, reliability, and throughput), hardware impairments (oscillator
phase noise), mobility and implementation complexity. Note further that not all five SCS options are applicable to all frequency bands [11] [18].
High numerologies can be advantageous for latency-critical services such as URLLC since wider SCS implies a shorter transmission time interval (TTI). Deployments with smaller cell sizes using higher frequency bands are affected from high levels of phase noise. The phase noise can be mitigated using a wider SCS. Moreover, for scenarios with higher Doppler spread, which is affected by mobility, multipath propagation and angular speed, a larger SCS needs to be adopted. Lower numerologies, on the other hand, can be utilized for nar- rowband devices implemented for mMTC use cases. Large cells have a large time dispersion (long delay spread), thus benefiting from narrower SCS. A summarized illustration for selecting a suitable numerology is given in Fig. 4.
In our simulations presented later, we apply numerology 1 to GOOSE traffic and numerology 2 to video traffic respectively.
This is because GOOSE packets are generally small requiring less bandwidth whereas video sessions require higher data rates.
2) Guard band and guard period overheads: Isolation is one of the key requirements for network slicing deployment. A network slice instance (NSI) which stands for an activated slice may be fully or partly, logically and/or physically, isolated from other NSIs [19]. In order to ensure the isolation among RAN slices, the resources allocated to one NSI must not overlap with that of other NSIs.
Although 5G NR improves spectral efficiency, it also in- troduces non-orthogonality to the system, causing interfer- ence among different numerologies, which is known asinter- numerology interference (INI). Thus, the flexibility of multi- numerology structure comes at a cost of computational com- plexity and signal overhead. To minimize INI, solutions with adaptive guards in both time and frequency domains may be applied [20].
3GPP [11] specifies the minimum guard band,G, for each UE channel bandwidth and SCS, asG= (C−δ·SCS·12)/2.
For any given bandwidth, a gNB shall ensure that the above minimum guard band is met when allocating the number of PRBs in a cell. For our simulations presented in Subsec. V-B, we have considered channel bandwidth of 25 [MHz], which requires 1.33 [MHz] guard bands on each side of the carrier.
Furthermore, when multiple numerologies are multiplexed inside the same subframe, a guard band or guard period has to be configured to mitigate INI. In 5G NR, two frame structures exist for frequency division duplex (FDD) and time division duplex (TDD) respectively. For FDD with full-duplex, no explicit guard period is needed. For FDD with half-duplex, it requires a guard period of one OFDM symbol. For TDD, a guard period may vary from one to ten OFDM symbols depending on downlink pilot time slot (DwPTS) and uplink pilot time slot (UpPTS) configurations.In this study, we do not consider signalling overhead or initial access as we concentrate on resource allocation after the handshake phase. Since the required guard period is negligible in terms of the radio
10000 2000 3000 4000 5000time, t 5
10 15 20 25 30 35
#of sessions
GOOSE
Video, downgraded Video
(a)λ2= 1/20[s−1],ρ= 0.76,rv= 0.11
10000 2000 3000 4000 5000time, t
5 10 15 20 25 30
#of sessions35
GOOSE
Video, downgraded
Video
(b)λ2= 1/40[s−1],ρ= 0.49,rv= 0.003 Fig. 5:Number of sessions over time,Mi(t), resource block utilization ρ, and rejected video sessionsrv. TABLE II: Simulation parameter configurations
Type of traffic,i 1: GOOSE 2: Video
Arrival rate,λi[s−1] Injection rate:1 1/10,1/20,1/40 Service rate,µi[s−1] 1/60 1/600
Numerology,β 1 2
Resources/session,δi[kHz] 360 720 (full-rate) or360 (downgraded)
Max. no. of sessions,si 62 31
Priority High|none Low|none
resource occupancy, we have ignored this overhead in our simulations.
B. Quantitative Assessment of Cross-Slice Effects
Extensive simulations are performed to assess the cross- slice effects based on the three configurations presented above.
The duration of the observation period is configured as 6 seconds. In the initial phase, only video sessions are carried out. Then GOOSE sessions are injected atTI= 2000 [ms]. The observation period terminates either when the observation time reachesT = 6000 [ms]or when there ares1GOOSE sessions.
The simulation is replicated 30 times with the same initial and terminating conditions. Then the sample mean values and the sample variances are obtained and shown in Figs. 5 and 6 respectively. The simulation configurations are listed in Tab. II.
1) Number of sessions: Due to the page limit, we present only the results for NC3 in Fig. 5. The curves therein illustrate how the number of sessions Mi(t)varies over time for video full rate, downgraded rate, and GOOSE, respectively. When the number of full rate video sessions reaches the maximum number of sessions allowed, i.e., when the total system ca- pacity is occupied, the newly arriving video sessions will be downgraded. That is when the downgraded video sessions appear on the plot. When the GOOSE sessions are injected into the network at TI = 2000 [ms], a significant amount of full rate video sessions have to be switched to downgraded video. Some video sessions may be even discarded due to insufficient capacity. After the GOOSE bursts have left the network, the number of video sessions increases to fill up the capacity available in the network, released by GOOSE traffic.
20000 2100 2200 2300 2400 2500time, t
5 10 15 20 25 30
#of sessions35
No priority, high load ( ) No priority, medium load ( )
GOOSE priority, or low load ( ) with no priority
<latexit sha1_base64="5U3MIYCZnGI5I7RJ3BdSpWzVNpk=">AAAB+3icbVDLSsNAFJ34rPEV69LNYBFc1Uwp6kYouHFZwT6gDWEymbRDJ5MwMxFL6K+4caGIW3/EnX/jpM1CWw8MHM45l3vnBClnSrvut7W2vrG5tV3ZsXf39g8OnaNqVyWZJLRDEp7IfoAV5UzQjmaa034qKY4DTnvB5Lbwe49UKpaIBz1NqRfjkWARI1gbyXeqQ27CIfYb8AaiC+Tatu/U3Lo7B1wlqCQ1UKLtO1/DMCFZTIUmHCs1QG6qvRxLzQinM3uYKZpiMsEjOjBU4JgqL5/fPoNnRglhlEjzhIZz9fdEjmOlpnFgkjHWY7XsFeJ/3iDT0bWXM5FmmgqyWBRlHOoEFkXAkElKNJ8agolk5lZIxlhiok1dRQlo+curpNuoo8s6um/WWs2yjgo4AafgHCBwBVrgDrRBBxDwBJ7BK3izZtaL9W59LKJrVjlzDP7A+vwBT16R9w==</latexit>
2= 1/10
<latexit sha1_base64="KIvhnGF9SMTHD095N2pQ/euFmEw=">AAAB+3icbVDLSsNAFL3xWeMr1qWbwSK4qkkp6kYouHFZwT6gDWEymbRDJw9mJmIJ/RU3LhRx64+482+ctFlo64GBwznncu8cP+VMKtv+NtbWNza3tis75u7e/sGhdVTtyiQThHZIwhPR97GknMW0o5jitJ8KiiOf054/uS383iMVkiXxg5qm1I3wKGYhI1hpybOqQ67DAfYa6AY5Fw3bND2rZtftOdAqcUpSgxJtz/oaBgnJIhorwrGUA8dOlZtjoRjhdGYOM0lTTCZ4RAeaxjii0s3nt8/QmVYCFCZCv1ihufp7IseRlNPI18kIq7Fc9grxP2+QqfDazVmcZorGZLEozDhSCSqKQAETlCg+1QQTwfStiIyxwETpuooSnOUvr5Juo+5c1p37Zq3VLOuowAmcwjk4cAUtuIM2dIDAEzzDK7wZM+PFeDc+FtE1o5w5hj8wPn8AUOWR+A==</latexit>
2= 1/20
<latexit sha1_base64="/7xuz8Jj9jMBAjQmXcMvUJhXqos=">AAAB+3icbVDLSsNAFL3xWeMr1qWbwSK4qkkp6kYouHFZwT6gDWEymbRDJw9mJmIJ/RU3LhRx64+482+ctFlo64GBwznncu8cP+VMKtv+NtbWNza3tis75u7e/sGhdVTtyiQThHZIwhPR97GknMW0o5jitJ8KiiOf054/uS383iMVkiXxg5qm1I3wKGYhI1hpybOqQ67DAfYa6AY5F03bND2rZtftOdAqcUpSgxJtz/oaBgnJIhorwrGUA8dOlZtjoRjhdGYOM0lTTCZ4RAeaxjii0s3nt8/QmVYCFCZCv1ihufp7IseRlNPI18kIq7Fc9grxP2+QqfDazVmcZorGZLEozDhSCSqKQAETlCg+1QQTwfStiIyxwETpuooSnOUvr5Juo+5c1p37Zq3VLOuowAmcwjk4cAUtuIM2dIDAEzzDK7wZM+PFeDc+FtE1o5w5hj8wPn8AU/OR+g==</latexit>
2= 1/40
Fig. 6:GOOSE burst periodsT forλ2={1/10,1/20,1/40}[s−1].
Fig. 5a) and Fig. 5b) reveal the performance when the video arrival rate is λ2 = 1/20 [s−1] andλ2 = 1/40 [s−1], respectively. Clearly, the expected number of full rate video sessions is dependent on the arrival intensity. At a low arrival rate, the number of full rate sessions will be higher, and vice versa. Atλ2= 1/40[s−1], we observe that no video sessions need to be downgraded before a GOOSE burst occurs. When GOOSE sessions are injected, a number of video sessions need to switch to a downgraded video rate in order to accommodate GOOSE sessions. With a higherλ2, the resource utilization,ρ, will be higher, at a cost of a higher number of rejected video sessionsrv.
2) Duration of the GOOSE bursts: In Fig. 6, we show the variation of the GOOSE burst duration (T) when λ2 varies, with and without GOOSE traffic priority. As can be observed, the mean GOOSE burst duration versus the number of GOOSE session curves almost overlap when GOOSE traffic priority is endorsed. This is because GOOSE sessions are guaranteed to obtain sufficient resources and will not be affected by parallel video sessions. Not surprisingly, it is observed that if no priority is given, the mean GOOSE burst duration increases significantly as the video traffic load increases (λ2 increases).
3) Reject, discard, and downgrade ratios: In Fig. 7, the three defined ratios in Subsec. IV-E are illustrated. For NC3
0.0 0.1 0.2 0.3 0.4 0.5
λ2=1/10 λ2=1/20 λ3=1/40
downgraded discarded discarded rejected
adaptive non-adaptive no priority
Fig. 7:Reject (rv), discard (rvdc), and downgrade (rvdw) ratios.
(with both priority and adaptive video rate), we observe two ratios for downgraded and discarded video flows, as video sessions will be downgraded first and then discarded if there is still no sufficient resources after downgrading, in order to provide resources to GOOSE sessions. When video traffic load is high in the network, many video sessions would be discarded even before the GOOSE sessions are injected into the system. Thus for λ2 = 1/10 [s−1], the discard ratio is substantially high whereas the downgrade ratio is comparatively low.
For NC2 (with priority but non-adaptive video) and NC1 (neither priority nor adaptive), video sessions would be dis- carded directly without downgrading when insufficient system capacity occurs. As traffic load increases, more video sessions will be discarded or rejected.
VI. CONCLUSIONS ANDFUTUREWORK
In this paper, we have proposed three multi-dimensional Markov models to address the resource allocation problem in 5G RAN slicing using mixed numerologies for smart grid control and protection traffic. Based on the developed models, we evaluate the transient performance of two traffic types (using different numerology) with and without traffic priority and investigate resource utilization with respect to system capacity versus the number of sessions served. Through analysis and simulations, we reveal the behavior of a sliced network with heterogeneous traffic during the transient period and demonstrate the importance of traffic priority as well as the necessity of service adaptation.In addition, we proposed a design principle for selecting the most appropriate numerology or numerologies in a 5G RAN based on resource availability and service requirements. Our study provides a reference framework for 5G cellular operators to increase RAN resource utilization by flexible allocation of radio resources considering both normal and busty traffic conditions.
As our future work, we will investigate dynamic resource allocation at a frame or subframe level considering hybrid numerologies in a subframe. Initial access considering smart grid traffic priority could be another topic of interest.
ACKNOWLEDGMENTS
This paper has been funded by CINELDI - Centre for intel- ligent electricity distribution, an 8 year Research Centre under the FME-scheme (Centre for Environment-friendly Energy Re- search, 257626/E20). The authors gratefully acknowledge the financial support from the Research Council of Norway and the CINELDI partners. For the work of V. Casares-Giner and F.
Y. Li, the research leading to these results has received funding from the NO Grants 2014–2021, under Project contract no.
42/2021 - “A Massive MIMO Enabled IoT Platform with Networking Slicing for Beyond 5G IoV/V2X and Maritime Services (SOLID-B5G).” The work of V. Casares-Giner has also been supported by the Spanish National Project no.
PGC2018-094151-B-I00.
REFERENCES
[1] C. Sexton, N. Marchetti, and L. A. DaSilva, “Customization and trade- offs in 5G RAN slicing,” IEEE Commun. Mag., vol. 57, no. 4, pp.
116–122, Apr. 2019.
[2] A. Ksentini and N. Nikaein, “Toward enforcing network slicing on RAN:
Flexibility and resources abstraction,” IEEE Commun. Mag., vol. 55, no. 6, pp. 102–108, Jun. 2017.
[3] 3GPP TR 38.832, “Study on enhancement of radio access network (RAN) slicing,” R17, v1.0.0, Mar. 2021.
[4] C.-Y. Chang, N. Nikaein, and T. Spyropoulos, “Radio access network re- source slicing for flexible service execution,” inProc. IEEE INFOCOM Workshops, Apr. 2018, pp. 668–673.
[5] S. Bakri, P. A. Frangoudis, and A. Ksentini, “Dynamic slicing of RAN resources for heterogeneous coexisting 5G services,” in Proc. IEEE GLOBECOM, Dec. 2019, pp. 1–6.
[6] C.-Y. Chang and N. Nikaein, “RAN runtime slicing system for flexible and dynamic service execution environment,” IEEE Access, vol. 6, pp.34018–34042, Jun. 2018.
[7] C. Tang, X. Chen, Y. Chen, and Z. Li, “Dynamic resource optimization based on flexible numerology and Markov decision process for hetero- geneous services,” inProc. IEEE ICPADS, Dec. 2019, pp. 610–617.
[8] A. Gonzalez, S. Kuhlmorgen, A. Festag, and G. Fettweis, “Resource allocation for block-based multi-carrier systems considering QoS re- quirements,” inProc. IEEE GLOBECOM, Dec. 2017, pp. 1–7.
[9] I. Vil`a, J. P´erez-Romero, O. Sallent, and A. Umbert, “Characterization of radio access network slicing scenarios with 5G QoS provisioning,”
IEEE Access, vol. 8, pp. 51414–51430, Mar. 2020.
[10] H. V. K. Mendis, P. E. Heegaard, and K. Kralevska, “5G network slicing as an enabler for smart distribution grid operations,” inProc. Int. Conf.
and Exhibition on Electricity Distribution (CIRED), Jun. 2019, pp. 1–5.
[11] 3GPP TR 38.101-4, “User equipment (UE) radio transmission and reception; Part 4: Performance requirements,” R16, v16.0.0, Mar. 2020.
[12] 3GPP TR 22.104, “Technical specification group services and system aspects; Service requirements for cyber-physical control applications in vertical domains,” R17, v17.0.0, Jun. 2019.
[13] W. Huang, “A practical guide of troubleshooting IEC 61850 GOOSE communication,” in Proc. IEEE Conf. for Protective Relay Engineers (CPRE), Apr. 2017, pp. 1–8, 2017.
[14] V. B. Iversen, Teletraffic Engineering Handbook. ITU–D, Study Group 2, Jun. 2001. [Online]. Available: https://www.itu.int/dmspub/itu- d/opb/stg/D-STG-SG02.16.1-2001-PDF-E.pdf.
[15] J. Kaufman, “Blocking in a shared resource environment,”IEEE Trans.
Commun., vol. 29, no. 10, pp. 1474–1481, Oct. 1981.
[16] J. W. Roberts, “A service system with heterogeneous user requirement,”
Performance of Data Commun. Syst. and Their Appl., p. 423–431, 1981.
[17] A. Jensen, “Markoff chains as an aid in the study of Markoff processes,”
Scandinavian Actuarial J., vol. 1953, no. sup1, pp. 87–91, Mar. 1953.
[18] J. Peisa, “5G techniques for ultra reliable low latency communication,”
inProc. IEEE CSCN, Sep. 2017, pp.
[19] 3GPP TR 28.801, “Study on management and orchestration of network slicing for next generation network,” R15, v15.1.0, Jan. 2018.
[20] A. F. Demir and H. Arslan, “Inter-numerology interference management with adaptive guards: A cross-layer approach,”IEEE Access, vol. 8, pp.
30378–30386, Feb. 2020.
