Performance Analysis of 5G RAN Slicing Deployment Options in Industry 4.0 Factories

Dit artikel analyseert verschillende 5G-RAN-slicing-deployeropties voor Industry 4.0-fabrieken met uRLLC-eisen en concludeert dat, hoewel slice-sharing de aggregatie-efficiëntie verbetert, alleen per-flow-slicing delay-schendingen onder resource-schaarste voorkomt, terwijl de voorgestelde planner geschikt is voor implementatie als rApp in de O-RAN Non-RT RIC.

De kern

Stel je voor dat een moderne fabriek een enorm drukke luchthaven is. In plaats van vliegtuigen, hebben we hier data-pakketjes (informatie) die van sensoren, robots en besturingssystemen naar elkaar moeten reizen. Deze data moet razendsnel en onfeilbaar aankomen, net als een ambulance die geen moment mag vertragen. Dit noemen we uRLLC (ultra-reliable low-latency communication).

Het probleem? De "luchthaven" (het 5G-netwerk) heeft een beperkt aantal start- en landingsbanen (radio-kanalen). Als er te veel vliegtuigen tegelijk willen landen, ontstaat er een file. In een fabriek betekent een file dat een robot zijn arm niet op tijd beweegt, wat kan leiden tot defecte producten of zelfs gevaar.

Dit artikel onderzoekt hoe we deze "luchthaven" het beste kunnen organiseren om files te voorkomen. De auteurs vergelijken vier verschillende manieren om de startbanen in te delen. Ze noemen dit Network Slicing (netwerk-schijven).

Hier is de uitleg van de vier strategieën, vertaald naar alledaagse analogieën:

De Vier Strategieën voor de "Fabrieks-Luchthaven"

Stel je voor dat de fabriek drie productielijnen heeft (Lijn 1, 2 en 3). Elke lijn heeft zijn eigen "vliegtuigen" met verschillende prioriteiten:

• De Spoedvliegtuigen: Robots die milliseconden-reageren (ze mogen nooit vertragen).
• De Normale Vliegtuigen: Sensoren die data sturen, maar iets minder haast hebben.
• De Vakantievliegtuigen: Camera-beelden of logbestanden die gewoon maar moeten aankomen.

De auteurs testen vier manieren om de startbanen te verdelen:

1. Optie 1: "Eén lijn, één eigen baan" (Geen delen)

   • Analogie: Elke productielijn krijgt zijn eigen exclusieve startbaan. Lijn 1 heeft baan A, Lijn 2 heeft baan B. Ze delen niets.
   • Voordeel: Als Lijn 1 een file heeft door een storing, heeft Lijn 2 daar geen last van.
   • Nadeel: Als Lijn 1 weinig vliegtuigen heeft, staat de helft van de baan leeg. Het is inefficiënt.

2. Optie 2: "Iedere vliegtuigsoort zijn eigen baan" (Per-flow isolatie)

   • Analogie: Dit is de meest gedetailleerde aanpak. Elke individuele robot of sensor krijgt zijn eigen mini-baan. De spoedrobots hebben een VIP-baan, de camera's hebben een aparte baan.
   • Voordeel: Dit is de enige manier om altijd te garanderen dat de spoedvliegtuigen (robots) op tijd zijn, zelfs als het enorm druk is.
   • Nadeel: Het kost veel tijd en rekenkracht om al die banen te beheren.

3. Optie 3: "Alle lijnen delen één grote baan" (Delen)

   • Analogie: Alle productielijnen delen één enorme, gemeenschappelijke startbaan.
   • Voordeel: Zeer efficiënt gebruik van ruimte; er staan nooit lege plekken.
   • Nadeel: Als de "vakantievliegtuigen" (camera's) plotseling veel data sturen, blokkeren ze de "spoedvliegtuigen". De robots gaan trager werken. Dit is gevaarlijk in een fabriek.

4. Optie 4: "De slimme mix" (Hybride)

   • Analogie: De spoedvliegtuigen krijgen een eigen VIP-baan, maar de minder belangrijke vliegtuigen delen een grote baan.
   • Voordeel: Een goede balans. De robots zijn veilig, en de rest deelt ruimte om ruimte te besparen.
   • Nadeel: Als het extreem druk wordt, kunnen de minder belangrijke vliegtuigen toch nog in de problemen komen, maar de spoedvliegtuigen blijven veilig.

Wat hebben ze ontdekt?

De auteurs hebben een slimme computer (een "planner") gebruikt om te berekenen welke optie het beste werkt. Ze gebruikten wiskunde (Stochastic Network Calculus) om te voorspellen hoe lang het duurt voordat een pakketje aankomt.

• Bij veel ruimte: Als de fabriek genoeg startbanen heeft, maakt het niet veel uit welke optie je kiest. Alles werkt prima.
• Bij weinig ruimte (de echte test): Als er weinig startbanen zijn (zoals vaak het geval is in drukke fabrieken), is Optie 2 (Per-flow) de enige die echt werkt. Alleen door elke robot zijn eigen beschermde ruimte te geven, kun je garanderen dat ze nooit vertragen.
• De prijs: Optie 2 is wel zwaar voor de computer om te berekenen. Het duurt even voordat de planner de juiste banen heeft ingedeeld.

De "Planner" en de Open RAN

De auteurs hebben ook een algoritme bedacht dat deze beslissingen neemt. Ze zeggen: "Dit is niet iets dat je elke milliseconde hoeft te doen."

• Analogie: Het is alsof je de verkeersregels voor de luchthaven niet elke seconde opnieuw bedenkt, maar elke paar minuten of uur, gebaseerd op het verkeer van de afgelopen tijd.
• Dit past perfect in het nieuwe Open RAN-systeem (een moderne manier om 5G-netwerken op te bouwen). De planner werkt als een "manager" die op de achtergrond werkt (niet in real-time), maar wel zorgt dat de "verkeersregels" voor de robots perfect zijn ingesteld.

Conclusie in één zin

Als je in een fabriek wilt garanderen dat je robots nooit vertragen, zelfs niet als het netwerk overbelast is, moet je de data van elke robot strikt scheiden van de rest (Optie 2). De andere opties zijn sneller of efficiënter, maar ze riskeren dat de kritieke machines vastlopen als het druk wordt. De auteurs tonen aan dat hun slimme planner dit kan regelen binnen de tijdslimieten van moderne 5G-fabrieken.

Technische samenvatting

Titel: Prestatieanalyse van 5G RAN-slicing-deployopties in Industrie 4.0-fabrieken

Auteurs: Oscar Adamuz-Hinojosa et al. (Universiteit van Granada)
Publicatie: EuCNC/6G Summit 2026 (IEEE)

---

1. Probleemstelling

De adoptie van 5G in Industrie 4.0 (IIoT) is essentieel voor real-time automatisering en cyber-fysieke systemen. Deze toepassingen vereisen ultra-reliabele lage latentie communicatie (uRLLC). Echter, onder omstandigheden van radio-bron-schaarste (congestie) en heterogene verkeersstromen (bijv. besturingsdata, video, sensoren), kunnen zwaar belaste stromen de prestaties van kritieke stromen degraderen.

Bestaande literatuur richt zich vaak op architectuur of resource-algoritmes, maar mist een systematische analyse van Radio Access Network (RAN) slicing-deployopties binnen één fabriek. De kernvraag is: hoe moet RAN-slicing worden geïmplementeerd om te voldoen aan de uiteenlopende Kwaliteit van Dienst (QoS)-eisen van meerdere productielijnen en heterogene stromen, zonder de isolatie of resource-efficiëntie te schaden?

2. Methodologie

De auteurs analyseren vier verschillende deployopties voor RAN-slicing en evalueren deze met een analytisch raamwerk gebaseerd op Stochastic Network Calculus (SNC).

A. Geanalyseerde Deployopties (DO)

De opties worden gedefinieerd op basis van twee dimensies: slicing-niveau (per productielijn vs. per flow) en deling (gedeeld vs. niet-gedeeld tussen lijnen):

1. DO-#1: Één slice per productielijn, geen deling tussen lijnen. (Isolatie op lijnniveau).
2. DO-#2: Meerdere slices per productielijn (per flow), geen deling. (Finest granulariteit, volledige isolatie).
3. DO-#3: Één slice per productielijn, wel gedeeld tussen lijnen. (Efficiëntie door deling, minder isolatie).
4. DO-#4: Meerdere slices per lijn, waarbij sommige slices gedeeld zijn. (Hybride aanpak).

B. Analytisch Raamwerk (SNC)

• Verkeersmodel: Poisson-aankomstprocessen met variabele pakketgroottes.
• Kanaalmodel: Rayleigh fading met vaste gemiddelde SNR binnen een planningsvenster (Non-RT tijdschaal).
• Delay-berekening: Gebruik van SNC om probabilistische bovenkanten voor packet delay te berekenen. Dit houdt rekening met variabiliteit in aankomsttijden en draadloze service (door MCS-adaptatie).
• Planner: Een heuristische algoritme (twee fasen) dat Resource Blocks (RB's) toewijst aan slices om te voldoen aan delay-doelstellingen ($W_f$) binnen de celcapaciteit.
  • Fase A: Balancering van RB's tussen slices om de ergste delay te verminderen.
  • Fase B: "Tightening" van resources; verwijdering van RB's zolang de delay-eisen nog worden gehaald (voorkomen van over-provisioning).

C. Implementatie Context

De planner is ontworpen voor de Non-RT RAN Intelligent Controller (RIC) in de Open RAN (O-RAN) architectuur. Het werkt op venster-basis (minuten) en stuurt beleid door naar de near-RT scheduler.

3. Belangrijkste Bijdragen

1. Vergelijkende Analyse: Identificatie en vergelijking van vier RAN-slicing-strategieën in industriële omgevingen, met focus op isolatie versus aggregatie-efficiëntie.
2. SNC-Raamwerk: Een analytisch model voor het afleiden van per-flow delay-bounds dat dient als gemeenschappelijke basis voor vergelijking.
3. Heuristische Planner: Een algoritme dat RB-toewijzingen optimaliseert om delay-doelen te halen zonder onnodige resource-verspilling, en die bewezen werkt binnen Non-RT tijdschalen.

4. Resultaten

De simulaties zijn uitgevoerd voor een fabrieksscenario met drie productielijnen en twee bandbreedte-configuraties (50 MHz en 100 MHz).

• Prestaties onder Bron-schaarste (50 MHz):

  • DO-#0 (Geen slicing): Leidt tot ernstige delay-overtredingen voor kritieke flows.
  • DO-#1 & DO-#3: Bieden onvoldoende bescherming voor de meest kritieke flows (zoals besturingsstromen) omdat deze gemengd worden met minder kritiek verkeer binnen dezelfde slice. Delay-overtredingen treden op.
  • DO-#2 (Per-flow slicing): Is de enige optie die consistent voldoet aan de uRLLC-eisen onder schaarste. Door elke flow een eigen slice te geven, kan de planner RB's precies afstemmen op de specifieke delay-eisen.
  • DO-#4 (Hybride): Vermijdt overtredingen voor de meest kritieke flows, maar schuift overtredingen door naar flows met gemiddelde eisen.

• Resource-efficiëntie:

  • DO-#2 vereist de minste totale RB's om aan de eisen te voldoen (bijv. 50 RB's in plaats van 65), omdat het over-provisioning voorkomt.
  • Gedeelde slices (DO-#3, DO-#4) vereisen meer resources om de heterogene eisen binnen één slice te accommoderen.

• Uitvoeringstijd en Schaalbaarheid:

  • De planner convergeert binnen seconden tot enkele tientallen seconden (afhankelijk van het aantal flows en RB's).
  • Zelfs de meest complexe scenario's (DO-#2 met veel flows) blijven binnen de Non-RT tijdschaal (minuten), wat implementatie als een rApp in de O-RAN RIC mogelijk maakt.
  • De uitvoeringstijd neemt toe met het aantal flows, maar de heuristiek convergeren sneller bij hogere schaarste (minder mogelijke herschikkingen).

5. Betekenis en Conclusie

Het artikel concludeert dat er een fundamentele trade-off bestaat tussen isolation en aggregatie-efficiëntie:

• Voor strikte uRLLC-eisen in een schaarste-omgeving is per-flow slicing (DO-#2) de enige veilige optie om delay-overtredingen te voorkomen.
• Gedeelde of lijn-gebaseerde slices verbeteren de aggregatie-efficiëntie, maar ten koste van de garantie voor de meest delay-kritieke stromen.

De studie valideert dat een SNC-gebaseerde planner haalbaar is voor Non-RT O-RAN implementaties. Dit biedt industriële netwerkbouwers een onderbouwd kader om te beslissen hoe ze slices moeten structureren: kiezen voor maximale isolatie (per flow) voor kritieke automatisering, of kiezen voor gedeelde slices voor minder kritieke, maar volumineuze datatypen, afhankelijk van de beschikbare spectrumcapaciteit.

Toekomstig werk richt zich op de integratie van Time-Sensitive Networking (TSN) voor nog strakkere synchronisatie in industriële systemen.