# Load balancing in Network Slice
###### tags: `Independent Study`
[TOC]
:::warning
Ref
- []
:::
# <Center>The Topic - Load balancing in Network Slice</Center>
## Some journal articles related to topic
### [1. DeepSlice](https://www.bing.com/search?q=DeepSlice%3A+A+Deep+Learning+Approach+towards+an+Efficient+and+Reliable+Network+Slicing+in+5G+Networks&cvid=5aac9ba2c6f8424485d6b9ac390a5d56&aqs=edge.0.69i59j69i58j69i60j69i61.325j0j1&pglt=931&FORM=ANNTA1&PC=EDGEDSE)
### [2. Hybrid DL Model](https://link.springer.com/content/pdf/10.1007/s10922-021-09636-2.pdf)
### Abstract
In order to provide consumers lots of application, e.g., IoT devices, AR-VR devices, Industry 4.0, smart city, smart homes, operaotrs use "slices" to run these service types on each base stations around us; currently, the most common slice are eMBB, mMTC, and URLLC that require very high high-speed user connectivity, high capacity, and low latency.
To develop a smart decision-making mechanism for predicting the slice for an unknown device type, offering load balancing of slices in each base stations, and restricting network slice failures.
In papers, they both use deep learning to do smart decision-making mechanism by using available network Key Performance Indicators (KPIs).
### Introduction
The current 4G network is not flexible to meet specific business demands since service providers need to configure several components and equipment to that specific one.
In 5G Network Slicing providing different business demands in each base stations, Machine Learning can monitor the status of diferent devices( emerging applications) to automatically reconfigure network slice in real time to meet the QoS of customers.
In network slicing, the accurate load balancing is further important because it results in effcient utilization of all the available resources, which prevent customers in on-time connection establishment, and long wait in queue scenarios while help service providers save much of the resources that are not required by the users at that particular time.
### The problem
In 4G era, the service provider need to manually configure the several components and equipments in order to provide different services to consumers in certain area. While in 5G, services provide the different network slicing in each base stations enabelling us provide differnet services in anywhere. To leverage the different service types, namely, the different slices for customers without any human intervention since there will be too many factors for a human to consider for choosing the needed slice in real time when given a unknown UE (Since data of transmitted from UE into wireless network will be compressed and modulated in base stations so we don't know how to effectively identify and classify applications).
In the **reconfgurable** network environments, and each network slice can be isolated, have individual control and policy management systems. Machine learning will monitor the status of diferent devices and predict the needed slice combining a variety of factors, which make intelligent and real-time decision from analyzing the huge data.
### Summary
假使網路的每個基地台在已做Network Slice且網路設備可reconfigure的狀態下,要如何盡量滿足不同user不同應用的需求(e.g., latency, reliability ,bandwidth, coverage, security),以選擇不同的Slice ?
人可能無法用演算法去窮舉所有的case,所以論文使用AI透過資料自己去歸納規則,為到來的用戶選擇Slice(Slice以可提供user需求),以盡量滿足大家對不同應用的需求
論文有關Load Balancing的部分不太詳細,有提到DeepSlice可以預測負載的量來選擇Slice,但以論文表示的方法來看,是直接為Slice設定一個threshold,當超過threshold時才轉換到別的Slice。我們假設每個基地台都已做Network Slice,但基地台每個Slice可提供的容量是有限,所以我們必須做Slice的負載平衡,而論文以threshold來分配資療並不能最大化每個基地台Slice的使用量,平衡基地台的負載,以降低使用者無法使用服務的可能
### Data Set
Both Paper use the same data set in [here] to do network slice should a user use (https://www.kaggle.com/datasets/anuragthantharate/deepslice)
Input & Output layer was shown as below :

### Model
DeepSlice use Random Forest (RF) algorithm & convolutional neural network (CNN) to construct the Model.
The RF algorithm is used to maintains the accuracy when some input data is missing.
While the CNN is used to select the correct slice for unknown device types and predict the network load of each network slice based on the incoming connection to help redirect traffic to the Master slice (A master slice is used to carry the device when a slice utilization exceeds a pre-defined threshold) as shown below.

The hybrid DL Model use CNN & LSTM to construct the model.
CNN is used to do slice selection.
While LSTM is used to do load balancing(predict the load and select the best load ? )

----
## About load balancing with Network Slicing
### Some Paper
#### [1. Handover with Network Slicing in 5G Networks](https://ieeexplore.ieee.org/document/9618576)
此論文假設每個UE對他所屬的Slice的data rate都一致,且Slice的容量是有限的
Defined Problem是如何同時考慮user所需求的slice,每一個slice能提供給user的使用量,以及周遭基地台Slice的使用狀況,以應付user對不同應用的需求
目標是最大化每個基地台Slice的使用量,以最佳化Defined Problem
驗證方法是讓user進行不規則移動300秒,而每兩秒就執行一次演算法
#### [2. SliceSim2: A Load Balancing Simulation Suite for 5G Network Slicing](https://cmpe.boun.edu.tr/content/slicesim2-load-balancing-simulation-suite-5g-network-slicing)
考慮一個user有多個Slice服務在跑時,要如何平衡基地台之間Slice的負載
驗證方法是用Random user的分配,在執行演算法
#### [3. Efficient Handover Mechanism for Radio Access Network Slicing by Exploiting Distributed Learning](https://ieeexplore.ieee.org/document/9223714)
5G引進了Network Slice的技術,以為不同服務類型提供不同的網路服務,然而在此Slice的狀況下,比起傳統基地台間的切換,加上Slice會大大增加基地台換手的複雜度,因為可能會有很多種情況,如在相同基地台中換Slice,用戶移動時換基地台但不換Slice,用戶移動時換基地台也換Slice。傳統使用RSRP信號強度的換手方式沒有保證user在不同Slice的QoS,且不同的handover也需要考慮不同信號的狀況以及次數,因為會影響handover所消耗的資源與QoS表現不佳的狀況。
論文中假設有不同類型的基地台,且這些基地台分別提供不同的Slice,在考慮不同handover cost的狀況下,盡力滿足Slice的QoS
驗證方法是用Random user的分配,在執行演算法與ML
---
更:
有講到因為受限於實體層的資源,傳統只基於RSRP的換手方法在換手之後基地台不一定能提供每位使用者他們所需要的服務,已不適用於有Slice的狀況
**但是** 他們假設 分配給ue的資源都是 固定 並且 是ue的最低需求
考慮的只有如何降低handover 的 cost
我覺得這樣怪怪的,假設選到的cost比較低,但是資源已經不夠了,那假設狀況就和實際狀況不符合
```
Bj , a bandwidth allocation vector of NS j from all BSs.
The value of Bj is fixed, which means that bandwidth
allocation for NS is static.
we assume that NS allocates the minimal
required bandwidth to fulfil UE QoS requirement
```
#### [4. User Access Control in Open Radio Access Networks: A Federated Deep Reinforcement Learning Approach](https://ieeexplore.ieee.org/document/9600616/)
在O-RAN的架構下,基地台被拆分為CU DU RU,在大量的佈署下,傳統用接收信號強度(RSS)選擇基地台的用戶存取控制(User Access Control)的方式會讓會導致頻繁的handover以及負載不平衡的問題,就好像一堆牆頭草又選項很多,一下子大量湧入一個基站,過沒多久又湧入
所以需要開發一個適用於O-RAN架構的用戶存取控制方法,來考慮如何執行handover,平衡基地台的負載並同時最大化throughput
系統模型中假設有OFDMA、所有BSs平均分配RBs、UE只能access一個BS且分配到下行的RB都一樣、BSs之間有channel的干擾
驗證方法是讓user執行演算法的移動,RIC偵測,再執行演算法與ML輸出要UE應該要被assign到哪個基地台
#### [5. A Deep Learning Approach to Downlink User Throughput Prediction in Cellular Networks](https://www.bing.com/search?q=A+Deep+Learning+Approach+to+Downlink+User+Throughput+Prediction+in+Cellular+Networks&cvid=e27254f5a4d048b3b8ee726ba170aa27&aqs=edge..69i57.376j0j1&FORM=ANAB01&PC=EDGEDSE)
此篇論文的目的是預測user downlink throughput,定義throughput為the bits per second a UE on the cellular network can receive
假設Cell之間有Signals interfere,通道的狀況會隨著時間和空間變化,造成UE移動或換Cell時,throughput可能會有劇烈的變化,**此篇論文只考慮預測user downlink的throughput**
現在的protocol無法應付此變化,造成QoE很差, 如果protocol可以知道未來的throughput的話就能做更好的決定,例如UE在看vedio的時候有的畫質低,表示throughput低,那protocol就可以先行buffer一些data以免到時候卡頓,可是我們怎麼知道他要看什麼畫質的影片,所以要predict througpuht,相對來說就可以避免一些data被discard掉,也就可以降低網路的load
Collected from SK Telecom BS Dataset,且量測時UE都固定一個Cell服務,每1分鐘量測一次UE的throughput
### Summary
我覺得[3]或[4] define的問題是相似的,因為他們都有考慮到基地台換手的cost,而在[3]是在考慮基地台和Network Slice的狀況下考慮換手的cost,而[4]的cost單純是signalling overheads and power consumptions。
[3]與[4]或[1]與[4]論文的結合正好是O-RAN架構下Network Slice的handover,也許論文的資訊是可以結合的。
而[1] 和 [3]與[4] 的差別在於 [1]的方法在一個短時間內的表現比[3]與[4]好,而[3]與[4]長期的表現比[1]好。
總結來說,我認為以目前OSC xApp的發展狀況與[RIC Test可提供的](https://hackmd.io/@87pBT_HNTnSO7vkP9K831Q/SydGRGj79),Traffic Steerging xApp是屬於一個最後判斷是否要為UE換基站的xApp,我認為可以參考[1]與參考[5](or 其他論文)改善QP xApp做配合,改善TS xApp決定的機制(目前只是看其他的cell的throughput有沒有大於目前服務的cell),以及QP xApp的AI演算法。
### Paper [1] 哪邊有問題,如何改進?
[1]在短的時間(<1s)找出,盡量增加Slice的利用率,同時減少handover次數的方法以基站的角度來看很不錯,但以UE的角度來看,有以下缺點:
1. 論文假設UE在Cell內throughput都是一樣的,但直觀上throughput會被距離影響,沒有考慮到UE的slice throughput => 可使用[4]提出的方法,或是在QP xApp先行預測slice throughput
3. 沒有考慮不同handover的cost是不同的,如[2]所述 => 但RIC Test只能換基地台,目前不能解決
## Load balancing with Network Slicing - Describe the problem & Assumption
### To define the problem under the assumptions
根據[RIC Test的筆記](https://hackmd.io/@87pBT_HNTnSO7vkP9K831Q/SydGRGj79#User-Guide-v12---Scenario-Generation)、[RIC Test Data list](https://hackmd.io/@87pBT_HNTnSO7vkP9K831Q/HJE0XI24q)以及[1],專題可以假設,UE會移動且可以連上每個基地台的每個UE都可以多於一種Slice、UE的throughput不一樣、每個Slice的容量是有限並一樣的
Defined Problem是在UE移動的狀況下,考慮user所需求的slice,以及周遭基地台Slice的容量,以最大化每個Slice的使用量,同時最大化UE的throughput
(就好像外面有許多密集的便利商店,我們假定每一間都可以提供所有服務(ibon、冰淇淋、提款機等等… 且客人可能需要多種以上的服務,而在客人一邊移動一邊享有服務的同時,我們安排他們要到哪一家便利商店去,才能最大化便利商店的營收,並且讓客人以最快的速度能結帳)

### Goal
改善目前TS xApp沒有考慮基地台負載的問題以及只考慮download throughput來判斷是否handover、以及改善QP xApp predict throughput的方式
### System Model
可用來描述問題:
- UE Set
- BS Set
- Slice Set
- Coverage area information of UE $k$ by BS $n$ is denoted by the binary variable (基站的範圍 - 關係到訊號強度,訊號強度太低就不選擇那個基站)
- The demand of UE $k$ to use slice $s$ is represented by the binary variable (未來UE有需求的Slice - 關係到我們該如何分配負載)
- Each slice $s$ has a limited capacity on each BS $n$ (Slice的負載 - 關係到我們可以分配多少UE給Slice)
- required data rate to use each slice is fixed for each user (Slice可提供UE的data rate - 關係到一個Slice可以有多少個UE)
- Connectivity information of UE $k$ to BS $n$ (是否有與基地台取得連線 - 目前想是不會被列入異常的UE?)
- the acceptance or rejection information of the request of UE $k$ to get service from slice $s$ (UE是否被提供此Slice - 目前想是Slice的使用量?)
為什麼可以用這樣的model來描述現在的問題 :
## Load balancing with Network Slicing - Proposed Method
### 流程
1. TS xApp從KPIMON取得UE的資料,開始對所有UE執行演算法
2. TS xApp要求QP xApp執行throughput的prediction
3. QP xApp回傳給TS xApp throughput的預測結果
4. TS xApp在考量UE throughput與最大化Slice的使用量的狀況下,為UE們選擇基地台
5. TS xApp發起handover request
以目前OSC xApp的發展狀況,Traffic Steerging xApp是屬於一個最後判斷是否要為UE換基站的xApp,我認為可以參考[1]與參考[5]改善QP xApp做配合,改善TS xApp決定的機制(目前只是看其他的cell的throughput有沒有大於目前服務的cell),以及QP xApp的AI演算法。
```sequence
participant TeraVM RIC Test
participant KPIMON xApp
participant InfluxDB
participant AD xApp
participant Load Balance xApp
participant QP xApp
participant RC xApp
KPIMON xApp->TeraVM RIC Test:E2 Subscription(REPORT)
TeraVM RIC Test->KPIMON xApp:E2 Sbuscription Resp
TeraVM RIC Test->KPIMON xApp:E2 Indication
KPIMON xApp->InfluxDB:Populate time series UE & Cell Data
AD xApp->InfluxDB:Read UE Data
Note over AD xApp:Anomaly Detection
AD xApp->InfluxDB:Write Anomaly
AD xApp->Load Balance xApp:Parameters for Load Balance
Load Balance xApp->QP xApp:Prediction Request
QP xApp->InfluxDB:Read Data
Note over QP xApp:Throughput Prediction
QP xApp->InfluxDB:UE Future Throughput
QP xApp->Load Balance xApp:Response
Note over Load Balance xApp:Load Balance Algorithm
Load Balance xApp->InfluxDB:Slice Load
Load Balance xApp->RC xApp:HO Request
RC xApp->TeraVM RIC Test:HO Request
```
### TS xApp
#### Heuristic 演算法
[1]的Intelligent Handover是直覺來自觀察什麼的現象?
#### 定義演算法參數
**與[1]不同的是,每個UE在同個Slice上能拿到的不一樣的throughput**
### QP xApp
#### Correlation table
Collected from SK Telecom BS Dataset...
量測時UE都固定一個Cell服務,每1分鐘量測一次UE的throughput,每10秒記錄一次Cell的負載

#### Input
- 1. The signal strength => 雖然是相關度低,但考慮UE在移動的狀況下,power是對throughput有影響的,如我離Wifi太遠就沒辦法傳輸資料 ([考慮移動的狀況下,這張圖跑出了power跟throughput的關係](https://hackmd.io/wHRnfBt1SFChBSMywlhlQA?view#RSS-amp-TCP-RTO-Relation))
- 2. The signal to noise ratio => moderately correlated to bw(download throughput),可解釋成雜訊(其他RF設備的訊號干擾)太強就容易有collision/重傳,因此throughput就會低。
- 3. The downlink cell load => moderately correlated to bw(download throughput),直觀上來講就是道路上車輛越多,車輛的移動速度就越慢
#### ML/DL Model
Vector AutoRegression
#### Output
Downlink Throughput
### 評估的效能指標與方式