Hierarchical Quality of Service (HQoS) uses a queue scheduling mechanism to guarantee the bandwidth of multiple services of multiple subscribers served by the service provider. HQoS uses multi-level scheduling to distinguish user-specific or service-specific traffic and provide differentiated bandwidth management.
Servcie providers will use HQoS to provide differentiated QoS guarantee for key users and services, improving user experience.
Elevator Pitch
Magma 5G SA is required to support for Multi-Level Scheduling QoS (Two-Level Scheduling) for multiple sessions of different QoS. Refer to REQ-OCN-03 of TIP OCN FWA requirements specification.
UPF supports the following functions for UE’s Uplink (DL) and Downlink (DL) traffic:
• Traffic Classification
• Prioritization
• rate shaping
Magma 5G SA supports traffic classification and queueing in Linux kernel for egress and ingress traffic as a basic configuration (default config) as below:
This process allows some packets to egress earlier than others, and is performed by the pfifo_fast qdisc ( First-In and First-Out). The QDisc which implements a simple three band prioritization scheme based on the TOS bits.
Figure 01: Hierarchical Token Bucket Structure
Individual QDiscs may implement classes in order to handle subsets of the traffic differently and Not all QDiscs have support for multiple classes. For example, the Hierarchical Token Bucket (HTB) QDisc allows the user to configure 500Kbps and 300Kbps classes and direct traffic to each as desired. The hierarchical token bucket (HTB) algorithm allows to specify per-flow bitrate guarantees and enables excess bandwidth sharing between flows of the same class.
Filters are the mechanism used to classify traffic to a particular QDisc or class. There are many different types of filters of varying complexity.
Following features are needed in Magma 5G SA:
• To extend support PriorityQueue for htb that different priority levels allow the HTBQueue to interfere in the fair excess bandwidth sharing mechanism, in favor of the higher priority flow.
• The hierarchical design of HTB allows to assign each traffic flow two bandwidth parameters: an assured rate and a ceiling rate. While the first one is the minimum guaranteed rate, the second one is an upper limit until which the flow can borrow excess bandwidth.
<class id="className">
<parentId> classParent</parentId>
<rate type="int">Rassured, className</rate>
<ceil type="int">Rceiling, className</ceil>
<burst type="int">burst</burst>
<cburst type="int">cburst</cburst>
<level type="int">classLevel</level>
<quantum type="int">quantum</quantum>
<mbuffer type="int">mbuffer</mbuffer>
<priority>priority</priority> [only for the leaf classes]
<queueNum type="int">n</queueNum> [corresponding packet queue index, only for the leaf class]
</class>
Hierarchical class of service is most frequently used in the following scenarios:
Services to Subscribers: Multiservice network operators face a challenge to provide different types of services on the same infrastructure to residential and business subscribers. The network operator needs to make sure each subscriber gets the network resources they paid for and each service gets the network resources it needs to operate properly. Using hierarchical class of service, the network edge device can have up to five levels of scheduling and prioritization. So the traffic can be shaped and prioritized per customer and per service type.
By allowing network operators to consolidate different services and multiple customers on the same physical infrastructure, hierarchical class of service helps maximize the ability to offer revenue generating services while simultaneously minimizing capital cost.
Services to Businesses: Hierarchical class of service is a valuable tool for service providers that support business customers who are running applications with different prioritization and scheduling requirements over the same infrastructure. In this scenario hierarchical class of service allows lower priority traffic to fully utilize the available bandwidth on a port, while simultaneously ensuring low latency and guaranteed bandwidth to higher priority traffic on the same port. This allows a provider to consolidate different services on the same physical device and physical infrastructure thus optimizing network resources while maintaining the required level of service.
All of this maximizes revenue and minimizes cost.
Wireless Backhaul: Wireless backhaul is very sensitive to fluctuations in the packet stream (Jitter) because it relies on synchronization. In this scenario, hierarchical class of service allows each type of traffic to receive the required resources and quality of service while being delivered over the same infrastructure. By consolidate different services on the same physical infrastructure, HCoS helps maximize revenue and minimize cost.
Project Details
Using iproute2 (command line utility), The tc tool performs all of the configuration of the kernel structures required to support traffic control. The utility takes as its first non-option argument one of three Linux traffic control components, qdisc, class or filter.
The following tasks are needed to implement for achieve this functionality:
Create HTB class for a UE session with correct value of rate limiting (GBR value).
Create HTB class for a UE session with priority value of QoS policy.
Create HTB class for a UE session with root and leaf value as parent for multi sessions (IMSI).
Create TC Filter for HTB class with parent ID and Priority.
Create nested token buckets for controlling the assured and ceiling rate.
Add for GBR and QoS policy priority attributes value from SMF to UPF.
Delivery Approach
Feature will be delivered in one milestone. Every milestone will have the following 5 process gates
Design
Development & Unit Testing
Code review
Integration testing
Resolve integration issues and regression issues
System test
User Acceptance test
Milestone1
Tasks to be handled on PipelineD
• Implement the namedtuple for QosInfo with GBR and MBR value.
• Implement the value set for qos_handle_root and qos_handle_leaf.
• Implement the grpc messages SMF-UPF for passing the GBR, MBR and priority attributes.
• Implement the functionality of Classifies packets into correct leaf classes using pyroute2.
• CLI Stub for functionality verification.
Tasks to be handled on Sessiond, PolicyDB and Ocr8r (NMS):
• Support for configure the gbr UL/DL attributes in NMS dashboard
• Implement the grpc attributes for Ocr8r to Sessiond to Pipelined.
Unit tests will be added for all new functions introduced.
Test Plan
Following is the set of tests or scenarios to verify the multi qos policy for multi sessions:
• Multi PDU session Establishment with single QoS
• Multi PDU session Establishment with multi QoS
• Send UDP/TCP traffic with Rate value and Ceil value
MS | FUNCTIONAL AREA | DELIVERABLES
-- | -- | -- | --
M1.0 | Pipelined | Implement the QosInfo
--|--| Implement the functionality of Classifies packets.
--|--| Implement CLI stub for verification the functionality.
--| SMF, Ocr8r, NMS | Support GBR and Priority set and grpc messages.
M2.0 | Integration Testing | Complete testing with multi qos configure in NMS and pdu establishment with UERANSIM | $39000
--| System Integration Testing | Traffic Throughput Testing with multi qos (Audio, Video etc)
Overview
Hierarchical Quality of Service (HQoS) uses a queue scheduling mechanism to guarantee the bandwidth of multiple services of multiple subscribers served by the service provider. HQoS uses multi-level scheduling to distinguish user-specific or service-specific traffic and provide differentiated bandwidth management. Servcie providers will use HQoS to provide differentiated QoS guarantee for key users and services, improving user experience.
Elevator Pitch
Magma 5G SA is required to support for Multi-Level Scheduling QoS (Two-Level Scheduling) for multiple sessions of different QoS. Refer to REQ-OCN-03 of TIP OCN FWA requirements specification. UPF supports the following functions for UE’s Uplink (DL) and Downlink (DL) traffic: • Traffic Classification • Prioritization • rate shaping Magma 5G SA supports traffic classification and queueing in Linux kernel for egress and ingress traffic as a basic configuration (default config) as below:
class htb 1:1 parent 1:fffe prio 0 quantum 1000 rate 12Kbit ceil 40Kbit linklayer ethernet burst 1599b/1 mpu 0b cburst 1600b/1 mpu 0b level 0 priority 10 queueNum 1 class htb 1:fffe root rate 80Kbit ceil 80Kbit linklayer ethernet burst 1600b/1 mpu 0b cburst 1600b/1 mpu 0b level 7
Use cases
Hierarchical class of service is most frequently used in the following scenarios:
Project Details
Using iproute2 (command line utility), The tc tool performs all of the configuration of the kernel structures required to support traffic control. The utility takes as its first non-option argument one of three Linux traffic control components, qdisc, class or filter. The following tasks are needed to implement for achieve this functionality:
Delivery Approach
Feature will be delivered in one milestone. Every milestone will have the following 5 process gates
Milestone1
Tasks to be handled on PipelineD • Implement the namedtuple for QosInfo with GBR and MBR value. • Implement the value set for qos_handle_root and qos_handle_leaf. • Implement the grpc messages SMF-UPF for passing the GBR, MBR and priority attributes. • Implement the functionality of Classifies packets into correct leaf classes using pyroute2. • CLI Stub for functionality verification. Tasks to be handled on Sessiond, PolicyDB and Ocr8r (NMS): • Support for configure the gbr UL/DL attributes in NMS dashboard • Implement the grpc attributes for Ocr8r to Sessiond to Pipelined. Unit tests will be added for all new functions introduced.
Test Plan
Following is the set of tests or scenarios to verify the multi qos policy for multi sessions:
Parent/Master Rate Ceil UC1 80kbit 80kbit UC2 90kbit 90kbit
Integration Testing using CLI Stub.
• Multi PDU session Establishment with single QoS • Multi PDU session Establishment with multi QoS • Send UDP/TCP traffic with Rate value and Ceil value
Feature Roadmap
Feature will be delivered in Two Milestones. Each milestone duration is 45 calendar days. <html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
MS | FUNCTIONAL AREA | DELIVERABLES -- | -- | -- | -- M1.0 | Pipelined | Implement the QosInfo --|--| Implement the functionality of Classifies packets. --|--| Implement CLI stub for verification the functionality. --| SMF, Ocr8r, NMS | Support GBR and Priority set and grpc messages. M2.0 | Integration Testing | Complete testing with multi qos configure in NMS and pdu establishment with UERANSIM | $39000 --| System Integration Testing | Traffic Throughput Testing with multi qos (Audio, Video etc)