Ken Dong
    • Create new note
    • Create a note from template
      • Sharing URL Link copied
      • /edit
      • View mode
        • Edit mode
        • View mode
        • Book mode
        • Slide mode
        Edit mode View mode Book mode Slide mode
      • Customize slides
      • Note Permission
      • Read
        • Only me
        • Signed-in users
        • Everyone
        Only me Signed-in users Everyone
      • Write
        • Only me
        • Signed-in users
        • Everyone
        Only me Signed-in users Everyone
      • Engagement control Commenting, Suggest edit, Emoji Reply
    • Invite by email
      Invitee

      This note has no invitees

    • Publish Note

      Share your work with the world Congratulations! 🎉 Your note is out in the world Publish Note No publishing access yet

      Your note will be visible on your profile and discoverable by anyone.
      Your note is now live.
      This note is visible on your profile and discoverable online.
      Everyone on the web can find and read all notes of this public team.

      Your account was recently created. Publishing will be available soon, allowing you to share notes on your public page and in search results.

      Your team account was recently created. Publishing will be available soon, allowing you to share notes on your public page and in search results.

      Explore these features while you wait
      Complete general settings
      Bookmark and like published notes
      Write a few more notes
      Complete general settings
      Write a few more notes
      See published notes
      Unpublish note
      Please check the box to agree to the Community Guidelines.
      View profile
    • Commenting
      Permission
      Disabled Forbidden Owners Signed-in users Everyone
    • Enable
    • Permission
      • Forbidden
      • Owners
      • Signed-in users
      • Everyone
    • Suggest edit
      Permission
      Disabled Forbidden Owners Signed-in users Everyone
    • Enable
    • Permission
      • Forbidden
      • Owners
      • Signed-in users
    • Emoji Reply
    • Enable
    • Versions and GitHub Sync
    • Note settings
    • Note Insights New
    • Engagement control
    • Make a copy
    • Transfer ownership
    • Delete this note
    • Save as template
    • Insert from template
    • Import from
      • Dropbox
      • Google Drive
      • Gist
      • Clipboard
    • Export to
      • Dropbox
      • Google Drive
      • Gist
    • Download
      • Markdown
      • HTML
      • Raw HTML
Menu Note settings Note Insights Versions and GitHub Sync Sharing URL Create Help
Create Create new note Create a note from template
Menu
Options
Engagement control Make a copy Transfer ownership Delete this note
Import from
Dropbox Google Drive Gist Clipboard
Export to
Dropbox Google Drive Gist
Download
Markdown HTML Raw HTML
Back
Sharing URL Link copied
/edit
View mode
  • Edit mode
  • View mode
  • Book mode
  • Slide mode
Edit mode View mode Book mode Slide mode
Customize slides
Note Permission
Read
Only me
  • Only me
  • Signed-in users
  • Everyone
Only me Signed-in users Everyone
Write
Only me
  • Only me
  • Signed-in users
  • Everyone
Only me Signed-in users Everyone
Engagement control Commenting, Suggest edit, Emoji Reply
  • Invite by email
    Invitee

    This note has no invitees

  • Publish Note

    Share your work with the world Congratulations! 🎉 Your note is out in the world Publish Note No publishing access yet

    Your note will be visible on your profile and discoverable by anyone.
    Your note is now live.
    This note is visible on your profile and discoverable online.
    Everyone on the web can find and read all notes of this public team.

    Your account was recently created. Publishing will be available soon, allowing you to share notes on your public page and in search results.

    Your team account was recently created. Publishing will be available soon, allowing you to share notes on your public page and in search results.

    Explore these features while you wait
    Complete general settings
    Bookmark and like published notes
    Write a few more notes
    Complete general settings
    Write a few more notes
    See published notes
    Unpublish note
    Please check the box to agree to the Community Guidelines.
    View profile
    Engagement control
    Commenting
    Permission
    Disabled Forbidden Owners Signed-in users Everyone
    Enable
    Permission
    • Forbidden
    • Owners
    • Signed-in users
    • Everyone
    Suggest edit
    Permission
    Disabled Forbidden Owners Signed-in users Everyone
    Enable
    Permission
    • Forbidden
    • Owners
    • Signed-in users
    Emoji Reply
    Enable
    Import from Dropbox Google Drive Gist Clipboard
       Owned this note    Owned this note      
    Published Linked with GitHub
    • Any changes
      Be notified of any changes
    • Mention me
      Be notified of mention me
    • Unsubscribe
    # 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 : ![](https://i.imgur.com/CLyNPPe.png) ### 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. ![](https://i.imgur.com/FW1PkS2.png) 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 ? ) ![](https://i.imgur.com/ICc7DKC.png) ---- ## 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、冰淇淋、提款機等等… 且客人可能需要多種以上的服務,而在客人一邊移動一邊享有服務的同時,我們安排他們要到哪一家便利商店去,才能最大化便利商店的營收,並且讓客人以最快的速度能結帳) ![](https://i.imgur.com/06Om1tv.png) ### 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的負載 ![](https://i.imgur.com/KH5mnfS.png) #### 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 ### 評估的效能指標與方式

    Import from clipboard

    Paste your markdown or webpage here...

    Advanced permission required

    Your current role can only read. Ask the system administrator to acquire write and comment permission.

    This team is disabled

    Sorry, this team is disabled. You can't edit this note.

    This note is locked

    Sorry, only owner can edit this note.

    Reach the limit

    Sorry, you've reached the max length this note can be.
    Please reduce the content or divide it to more notes, thank you!

    Import from Gist

    Import from Snippet

    or

    Export to Snippet

    Are you sure?

    Do you really want to delete this note?
    All users will lose their connection.

    Create a note from template

    Create a note from template

    Oops...
    This template has been removed or transferred.
    Upgrade
    All
    • All
    • Team
    No template.

    Create a template

    Upgrade

    Delete template

    Do you really want to delete this template?
    Turn this template into a regular note and keep its content, versions, and comments.

    This page need refresh

    You have an incompatible client version.
    Refresh to update.
    New version available!
    See releases notes here
    Refresh to enjoy new features.
    Your user state has changed.
    Refresh to load new user state.

    Sign in

    Forgot password
    or
    Sign in via Facebook Sign in via X(Twitter) Sign in via GitHub Sign in via Dropbox Sign in with Wallet
    Wallet ( )
    Connect another wallet

    New to HackMD? Sign up

    By signing in, you agree to our terms of service.

    Help

    • English
    • 中文
    • Français
    • Deutsch
    • 日本語
    • Español
    • Català
    • Ελληνικά
    • Português
    • italiano
    • Türkçe
    • Русский
    • Nederlands
    • hrvatski jezik
    • język polski
    • Українська
    • हिन्दी
    • svenska
    • Esperanto
    • dansk

    Documents

    Help & Tutorial

    How to use Book mode

    Slide Example

    API Docs

    Edit in VSCode

    Install browser extension

    Contacts

    Feedback

    Discord

    Send us email

    Resources

    Releases

    Pricing

    Blog

    Policy

    Terms

    Privacy

    Cheatsheet

    Syntax Example Reference
    # Header Header 基本排版
    - Unordered List
    • Unordered List
    1. Ordered List
    1. Ordered List
    - [ ] Todo List
    • Todo List
    > Blockquote
    Blockquote
    **Bold font** Bold font
    *Italics font* Italics font
    ~~Strikethrough~~ Strikethrough
    19^th^ 19th
    H~2~O H2O
    ++Inserted text++ Inserted text
    ==Marked text== Marked text
    [link text](https:// "title") Link
    ![image alt](https:// "title") Image
    `Code` Code 在筆記中貼入程式碼
    ```javascript
    var i = 0;
    ```
    var i = 0;
    :smile: :smile: Emoji list
    {%youtube youtube_id %} Externals
    $L^aT_eX$ LaTeX
    :::info
    This is a alert area.
    :::

    This is a alert area.

    Versions and GitHub Sync
    Get Full History Access

    • Edit version name
    • Delete

    revision author avatar     named on  

    More Less

    Note content is identical to the latest version.
    Compare
      Choose a version
      No search result
      Version not found
    Sign in to link this note to GitHub
    Learn more
    This note is not linked with GitHub
     

    Feedback

    Submission failed, please try again

    Thanks for your support.

    On a scale of 0-10, how likely is it that you would recommend HackMD to your friends, family or business associates?

    Please give us some advice and help us improve HackMD.

     

    Thanks for your feedback

    Remove version name

    Do you want to remove this version name and description?

    Transfer ownership

    Transfer to
      Warning: is a public team. If you transfer note to this team, everyone on the web can find and read this note.

        Link with GitHub

        Please authorize HackMD on GitHub
        • Please sign in to GitHub and install the HackMD app on your GitHub repo.
        • HackMD links with GitHub through a GitHub App. You can choose which repo to install our App.
        Learn more  Sign in to GitHub

        Push the note to GitHub Push to GitHub Pull a file from GitHub

          Authorize again
         

        Choose which file to push to

        Select repo
        Refresh Authorize more repos
        Select branch
        Select file
        Select branch
        Choose version(s) to push
        • Save a new version and push
        • Choose from existing versions
        Include title and tags
        Available push count

        Pull from GitHub

         
        File from GitHub
        File from HackMD

        GitHub Link Settings

        File linked

        Linked by
        File path
        Last synced branch
        Available push count

        Danger Zone

        Unlink
        You will no longer receive notification when GitHub file changes after unlink.

        Syncing

        Push failed

        Push successfully