GSOC2024RLUsability5G: Difference between revisions

From Nsnam
Jump to navigation Jump to search
Line 61: Line 61:


* Studied cttc-nr-demo example with cttc-nr-demo tutorial
* Studied cttc-nr-demo example with cttc-nr-demo tutorial
::- quasi-ideal assumption
::quasi-ideal assumption
::- RAN Lifecycle (i.e. downlink packet flow from gNB to UE)
::RAN Lifecycle (i.e. downlink packet flow from gNB to UE)
::- How to configure the scenario, EPC, physical layer, and traffic(application)
::How to configure the scenario, EPC, physical layer, and traffic(application)
::- ''(Doubt) What do I consider when I configure bands, carrier component, BWP?''
::''(Doubt) What do I consider when I configure bands, carrier component, BWP?''


=== Week 2 [Jun. 02 - Jun. 09] ===
=== Week 2 [Jun. 02 - Jun. 09] ===
Line 70: Line 70:


* Studied schedulers in 5g-lena
* Studied schedulers in 5g-lena
::- Studied MAC Layer section related to schedulers in NR module documentation
::Studied MAC Layer section related to schedulers in NR module documentation
::- Studied cttc-nr-simple-qos-sched example
::Studied cttc-nr-simple-qos-sched example


=== Week 3 [Jun. 10 - Jun. 16]===
=== Week 3 [Jun. 10 - Jun. 16]===
Line 77: Line 77:


* Analyzed the QoS Scheduler in 5g-lena
* Analyzed the QoS Scheduler in 5g-lena
::- Page: [https://mye280c37.github.io/posts/gsoc2024-01/#simulation-results-analysis QoS Scheduler Simulation Results Analysis]
::Page: [https://mye280c37.github.io/posts/gsoc2024-01/#simulation-results-analysis QoS Scheduler Simulation Results Analysis]
::- Reference: Koutlia, Katerina, Sandra Lagén, and Biljana Bojovic. "Enabling QoS Provisioning Support for Delay-Critical Traffic and Multi-Flow Handling in ns-3 5G-LENA." Proceedings of the 2023 Workshop on ns-3. 2023.
::Reference: Koutlia, Katerina, Sandra Lagén, and Biljana Bojovic. "Enabling QoS Provisioning Support for Delay-Critical Traffic and Multi-Flow Handling in ns-3 5G-LENA." Proceedings of the 2023 Workshop on ns-3. 2023.
 
* Created an initial example code
* Created an initial example code
::- Created the example based on the example named 'cttc-nr-simple-qos-sched'
::Created the example based on the example named 'cttc-nr-simple-qos-sched'
::- Altered the default UE count to 3, assigning each UE a single QoS flow represented by 5QI indices 1, 80, and 87, which denote GBR, non-GBR, and Delay Critical GBR resource types, respectively
::Altered the default UE count to 3, assigning each UE a single QoS flow represented by 5QI indices 1, 80, and 87, which denote GBR, non-GBR, and Delay Critical GBR resource types, respectively
::- Commit: [https://gitlab.com/mye280c37/5g-lena-integrated-with-ns-3-gym/-/commit/80523b0b9baf3199554e1d0b72a4682ef560b62e Add new example cttc-nr-initial-my-sched]
::Commit: [https://gitlab.com/mye280c37/5g-lena-integrated-with-ns-3-gym/-/commit/80523b0b9baf3199554e1d0b72a4682ef560b62e Add new example cttc-nr-initial-my-sched]


=== Week 4 [Jun. 17 - Jun. 23]===
=== Week 4 [Jun. 17 - Jun. 23]===
Line 88: Line 89:


* Modified the initial example
* Modified the initial example
::- Added a new parameter `numTrafficProfile`
::Added a new parameter `numTrafficProfile`
::::Specified the flow profile based on the number of traffic types. Possible values are 2 and 3
::::Specified the flow profile based on the number of traffic types. Possible values are 2 and 3
::::If the `numTrafficProfile`  is 2, two types of traffic (5QI 80, 87), same as ‘cttc-nr-multi-flow-qos-sched’, is installed in 3 UEs. Two UE have 5QI 80 traffic and the other has 5QI 87 traffic
::::If the `numTrafficProfile`  is 2, two types of traffic (5QI 80, 87), same as ‘cttc-nr-multi-flow-qos-sched’, is installed in 3 UEs. Two UE have 5QI 80 traffic and the other has 5QI 87 traffic
::::If the `numTrafficProfile`  is 3, three types of traffic (5QI 1, 80, 87), as defined initially, is installed in 3 UEs repectively.
::::If the `numTrafficProfile`  is 3, three types of traffic (5QI 1, 80, 87), as defined initially, is installed in 3 UEs repectively.
::- Commit: [https://gitlab.com/mye280c37/5g-lena-integrated-with-ns-3-gym/-/commit/7eafd7d5cd173a1d3e25603c53065e50966945cb Add a parameter for the number of traffic types]
::Commit: [https://gitlab.com/mye280c37/5g-lena-integrated-with-ns-3-gym/-/commit/7eafd7d5cd173a1d3e25603c53065e50966945cb Add a parameter for the number of traffic types]


* Evaluated the QoS scheduler in various scenarios
* Evaluated the QoS scheduler in various scenarios
::- Evaluated the results when non-GBR and DC GBR are installed in different UEs to verify the simulation results analysis from the previous week
::Evaluated the results when non-GBR and DC GBR are installed in different UEs to verify the simulation results analysis from the previous week
::- As a result of this evaluation, I observed that all non-GBR traffic experienced more severe delays compared to DC GBR traffic
::As a result of this evaluation, I observed that all non-GBR traffic experienced more severe delays compared to DC GBR traffic
::- From my analysis of the simulation results in the QoS scheduler paper, non-GBR traffic benefits when the UE with non-GBR traffic also has DC GBR traffic in a multi-flow configuration.
::From my analysis of the simulation results in the QoS scheduler paper, non-GBR traffic benefits when the UE with non-GBR traffic also has DC GBR traffic in a multi-flow configuration.
::- Page: [https://mye280c37.github.io/posts/gsoc2024-02/ QoS Scheduler Evaluation]
::Page: [https://mye280c37.github.io/posts/gsoc2024-02/ QoS Scheduler Evaluation]


* Designed a new scheduler
* Designed a new scheduler
::- Made the assumption that all UEs have a single flow for simplicity (extend it further to multi-flow after achieving the first goal)
::Made the assumption that all UEs have a single flow for simplicity (extend it further to multi-flow after achieving the first goal)
::- Decided the goals of the scheduler
::Decided the goals of the scheduler
::::▻ Candidate 1: Minimize the total delay of the gNB
::::‣ Option 1: Minimize the total delay of the gNB
::::▻ Candidate 2: The scheduler schedules UEs to meet their PDB requirements (primary goal). Among DC-GBR and other types of traffic, DC-GBR traffic has higher priority in scheduling (secondary goal)
::::‣ Option 2: The scheduler schedules UEs to meet their PDB requirements (primary goal). Among DC-GBR and other types of traffic, DC-GBR traffic has higher priority in scheduling (secondary goal)
 
=== Week 5 [Jun. 24 - Jun. 30]===
Design Scheduler (2)
 
* The scheduler is designed to be user-friendly and easy to reuse
::৹ To facilitate ease of reuse, the scheduler's design should be simple and easily understandable
::৹ For simplicity, the goal of the scheduler is to minimize the total delay of the gNB while considering the priority of each attached UE
::::‣ As analyzed before, one of the issues in the QoS scheduler is the unfairness of delay between DC-GBR and other types of traffic
::::‣ To address this issue, the designed scheduler focuses on minimizing the total delay
::৹ Page: [https://mye280c37.github.io/posts/gsoc2024-03/ Scheduler Design]
::৹ TBD: the reward function

Revision as of 11:23, 3 July 2024

Main Page - Roadmap - Summer Projects - Project Ideas - Developer FAQ - Tools - Related Projects

HOWTOs - Installation - Troubleshooting - User FAQ - Samples - Models - Education - Contributed Code - Papers

Back to GSoC 2024 projects

Project Overview

  • Project Name: Enhancement of RL Approach Accessibility in NR
  • Student: Hyerin Kim
  • Mentors: Amir Ashtari, Katerina Koutlia, Bijana Bojovic, Gabriel Ferreira
  • Google page: https://summerofcode.withgoogle.com/programs/2024/projects/vPuZgTe1
  • Project Goals: In this project, I will design a new RL based MAC scheduler of NR and implement it in 5g-lena integrating with ns3-gym. Additionally, I will enhance the usability of 5G-lena in terms of RL approach by providing an example using the designed RL based scheduler.
  • Repository: https://gitlab.com/mye280c37/5g-lena-integrated-with-ns-3-gym/-/tree/gsoc24-nr-usability?ref_type=heads (fork nr GitLab)
  • About Me: I am currently pursuing a Master's degree in Computer Science and Engineering at Seoul National University, South Korea. My research at the Mobile Computing & Communications Laboratory focuses on resource allocation methods in NR V2X Sidelink. As an undergraduate, I conducted research on improving spatial reuse in dense Wi-Fi environments and implemented a Reinforcement Learning (RL)-based modified OBSS/PD algorithm using ns3 gym. I believe that participating in GSoC 2024 presents an excellent opportunity for me to contribute to enhancing the usability of 5G and RL experiences on ns-3, while also deepening my understanding of 5G technology, mechanisms, and system architecture.

Milestones

The planned milestones are outlined below

Phase1. Design example (3 weeks)

  • Familiar with 5g-lena (2 weeks)
  • Design Scenario (e.g., UEs deployment, UEs speed, cell configuration, …) (1 week)
- Define Assumption (e.g., delay, TDMA/OFDMA, …)

Phase2. Design RL based Scheduler (6 +1 weeks)

  • Design scheduler (2 weeks)
- input/output
- goal of optimization
  • Design RL process (1 week)
- Define suitable RL techniques considering optimization objective of the scheduler and computational complexity
  • Implementation of RL based scheduler in 5g lena (3 +1 weeks)
- Create the test
- Create documentation
- Create MR to 5g lena (Milestone 1)

Phase3. RL Integration (4 weeks)

  • Design RL framework (1 week)
- Define RL technique
  • Develop gym scripts (3 weeks)
- Develop gym python scripts
- Develop ns3 gym interface in RL 5g lena example
- Validate RL process of the example
- Create MR to 5g lena (Milestone 2)

Phase4. Evaluation (3 +1 weeks)

  • Evaluate the result of example compared with other schedulers
- Write simulation campaign scripts
- Execute scripts
- Plotting python scripts
  • Address review comment of the MR 1 and 2
  • Update MR 1 and 2 with necessary modification
  • Create brief description of the work and the results for 5g lena blog (Milestone 3)

Weekly Report

Week 1 [May 27 - Jun. 02]

Familiar with 5g-lena (1)

  • Studied cttc-nr-demo example with cttc-nr-demo tutorial
৹ quasi-ideal assumption
৹ RAN Lifecycle (i.e. downlink packet flow from gNB to UE)
৹ How to configure the scenario, EPC, physical layer, and traffic(application)
(Doubt) What do I consider when I configure bands, carrier component, BWP?

Week 2 [Jun. 02 - Jun. 09]

Familiar with 5g-lena (2)

  • Studied schedulers in 5g-lena
৹ Studied MAC Layer section related to schedulers in NR module documentation
৹ Studied cttc-nr-simple-qos-sched example

Week 3 [Jun. 10 - Jun. 16]

Design Scenario

  • Analyzed the QoS Scheduler in 5g-lena
৹ Page: QoS Scheduler Simulation Results Analysis
৹ Reference: Koutlia, Katerina, Sandra Lagén, and Biljana Bojovic. "Enabling QoS Provisioning Support for Delay-Critical Traffic and Multi-Flow Handling in ns-3 5G-LENA." Proceedings of the 2023 Workshop on ns-3. 2023.
  • Created an initial example code
৹ Created the example based on the example named 'cttc-nr-simple-qos-sched'
৹ Altered the default UE count to 3, assigning each UE a single QoS flow represented by 5QI indices 1, 80, and 87, which denote GBR, non-GBR, and Delay Critical GBR resource types, respectively
৹ Commit: Add new example cttc-nr-initial-my-sched

Week 4 [Jun. 17 - Jun. 23]

Design Scheduler (1)

  • Modified the initial example
৹ Added a new parameter `numTrafficProfile`
‣ Specified the flow profile based on the number of traffic types. Possible values are 2 and 3
‣ If the `numTrafficProfile` is 2, two types of traffic (5QI 80, 87), same as ‘cttc-nr-multi-flow-qos-sched’, is installed in 3 UEs. Two UE have 5QI 80 traffic and the other has 5QI 87 traffic
‣ If the `numTrafficProfile` is 3, three types of traffic (5QI 1, 80, 87), as defined initially, is installed in 3 UEs repectively.
৹ Commit: Add a parameter for the number of traffic types
  • Evaluated the QoS scheduler in various scenarios
৹ Evaluated the results when non-GBR and DC GBR are installed in different UEs to verify the simulation results analysis from the previous week
৹ As a result of this evaluation, I observed that all non-GBR traffic experienced more severe delays compared to DC GBR traffic
৹ From my analysis of the simulation results in the QoS scheduler paper, non-GBR traffic benefits when the UE with non-GBR traffic also has DC GBR traffic in a multi-flow configuration.
৹ Page: QoS Scheduler Evaluation
  • Designed a new scheduler
৹ Made the assumption that all UEs have a single flow for simplicity (extend it further to multi-flow after achieving the first goal)
৹ Decided the goals of the scheduler
‣ Option 1: Minimize the total delay of the gNB
‣ Option 2: The scheduler schedules UEs to meet their PDB requirements (primary goal). Among DC-GBR and other types of traffic, DC-GBR traffic has higher priority in scheduling (secondary goal)

Week 5 [Jun. 24 - Jun. 30]

Design Scheduler (2)

  • The scheduler is designed to be user-friendly and easy to reuse
৹ To facilitate ease of reuse, the scheduler's design should be simple and easily understandable
৹ For simplicity, the goal of the scheduler is to minimize the total delay of the gNB while considering the priority of each attached UE
‣ As analyzed before, one of the issues in the QoS scheduler is the unfairness of delay between DC-GBR and other types of traffic
‣ To address this issue, the designed scheduler focuses on minimizing the total delay
৹ Page: Scheduler Design
৹ TBD: the reward function