stc qosdifferentiation feature fni

8/12/2019 STC QOSdifferentiation Feature FNI

http://slidepdf.com/reader/full/stc-qosdifferentiation-feature-fni 1/44

All Rights Reserved © Alcatel-Lucent 2013

QOS differentiation

STC Deep Dive

November, 2013



All Rights Reserved © Alcatel-Lucent 20132 | QOS Differentiation | November 2013

Agenda Introduction

Feature Overview

Agreed profiles

Activation strategy

KPI results

Conclusion

Future Steps




Agenda Introduction

Feature Overview

Agreed profiles

Activation strategy

KPI results

Conclusion

Future Steps




Introduction

Quality of Service (QoS) is a broad term used to describe the overall experience a user or

application will receive over a network. QoS involves a broad range of technologies,architecture and protocols. Network operators achieve end-to-end QoS by ensuring that

network elements apply consistent treatment to traffic flows as they traverse the

network.

The QoS mechanisms must provide a vehicle to optimize radio and network resources in a

manner that allows the network operator to satisfy the end-user requirements with theminimum amount of network infrastructure possible.

The operator must be able to engineer the network in the most cost effective manner

possible.

QoS controls are an integral part of the network engineering procedures/controls.




Introduction

The QoS mechanisms provide the network operator with the following capabilities:

• The enabling of new sophisticated applications which offer preferential treatment tohigher tiered subscribers.

• Market differentiator. Enables service personalization.

• Increased customer loyalty. Improved end user satisfaction.




Introduction

The purpose of QoS Differentiation is to establish user differentiation in UTRAN,

according to three different profiles (Gold/Silver/Bronze), by managing users withdifferent levels of priority according to the customer strategy

Network operators may want to differentiate the offered QoS for different user groups,based on different classes of subscriptions

These customers categories are entered in the subscriber database, along with the

relevant QoS profiles, which are used, whenever the context is activated

For example, a Gold user should be able to experience a higher Quality of Service than aBronze user, both in terms of throughput and network access (priority in cases ofcongestion)

The QoS Differentiation definition can be divided in two main aspects:

• Definition of the type of priority differentiation

• Definition of the level of priority for each type of user




Introduction

In simple terms, QoS differentiation can be implemented at several stages of the call, by

using different features that implement distinct network behaviours for the users:• During call admission by giving precedence to high priority users or services in case of

lack of resources (preemption of low priority users/services, fair sharing of resourcesbetween DCH and HSDPA)

• While the PS HSDPA data transfer is on-going, by ensuring higher bit rate to a usercategory, traffic class or service (mainly achieved through SPI scheduling, which takesinto account the guaranteed bit rate and minimum bit rate – respectively for PSStreaming and PS Interactive/Background – and the management of HSDPA relative bitrates, in case of Iub congestion)

• While the PS R99 data transfer is on-going, by allowing higher bit rates to high priorityusers, when adapting the resources to the user needs (bit rate selection according toiRM table, in case of RB Bit Rate Adaptation)

• While the AMR call is on-going, by checking the several cell load criteria and reducingthe rates for lower priority users in case of high load

• In either case (call setup or during the call), by limiting the maximum DL traffic transmitpower for lower priority users (differentiation per OLS) or services (speech versus PS)




Introduction

QoS negotiation is primarily a Call Admission Control (CAC) control plane function.

However, it also interacts with other 3GPP control plane functions

Below Figure provide high-level call setup flows for the PS domain.




Agenda Introduction

Feature Overview

Agreed profiles

Activation strategy

KPI results

Conclusion

Future Steps




Feature Overview:

•Overview

•QoS differentiation Based on TC, ARP and THP

•MAC-hs Scheduler Improvement

•MAC-e Scheduler Enhancements• PS Core Network Requested RAB Modification

• MBR Handling in the HSDPA Scheduler

•MBR Handling in the HSUPA Scheduler




Feature Overview:

•Overview









Overview

Qos differentiation in ALU system take a lot of features to be activated

Below table shows features that will be implemented in STC Network

In the following section we are going to introduce brief explanation on each feature

algorithm in ALU system

Feature ID Name

PM25080 QoS differentiation Based on TC, ARP and THP (UA5.0)

PM29807 MAC-hs Scheduler Improvement (UA5.0)

PM33327 MAC-e Scheduler Enhancements (UA6.0)

PM34653 PS Core Network Requested RAB Modification (UA7.1)

PM30742 MBR Handling in the HSUPA Scheduler (UA7.1)

Iu traffic conformance MBR Handling in the HSDPA Scheduler




Feature Overview:

•Overview









QoS differentiation Based on TC, ARP and THP

From UA5.0, the QoS Differentiation is implemented based on the following parameters: Traffic Class (TC) Allocation/Retention Priority (ARP) Traffic Handling Priority (THP), only applicable for the „Interactive‟ Traffic Class

These values are HLR subscription parameters, sent to the RNC from the Core Network inthe RANAP RAB ASSIGNMENT REQUEST message, and the RNC uses them to prioritize usersand servicesInternally, the RNC maps the received TC/ARP/THP RAB parameters into one of threelevels of priority: Gold, Silver or Bronze, Gold being associated to the highest priority,and Bronze with the lowest

This priority level defines the Olympic Level of Service (OLS) of the user, which is used byRNC Control Plane as a reference index to the QoS-related configuration tables (definedby the operator) to control the QoS at UTRAN level

The list of QoS parameters using the QoS differentiation based on TC/ARP/THPencompasses: iRM tables UL / DL, to derive UlAsConf and DlASConf during RAB Matching on a iRM-

eligible PS RAB Always On timer tables DSCP marking Mac Logical channel Priority (MLP) Scheduling Priority Information (SPI) BLER quality target tables for DCH configuration UL/DL





Feature PM25080 aims at:

Increasing the operator’s flexibility by supporting THP-based QoS differentiation for ‘Interactive’ class and by implementing a global OLS activation/deactivation mechanismfor all OLS-based features

Enhance OAM model simplicity and consistency for QoS features by reducing the numberof parameters to be provisioned at OAM level, by defining of a central table to derive OLS,MLP and SPI from the incoming TC, ARP and THP and by making QoS Differentiationconsistent across features

QoS DifferentiationMapping Table

defined in RNC

Traffic Handling Priority(THP)

Traffic Class (TC)

Allocation Retention Priority(ARP)

Scheduling Priority Indicator (SPI)

Core Network RNC NodeB

Scheduling Priority Indicator (edchSPI)

Olympic Level Service(OLS)





For each combination TC/ARP/THP, one can associate: OLS (Gold, Silver, Bronze), used as input to iRM Table and Always-On MLP (1 .. 8), used to prioritize the different PS I/B RABs assigned to the same user at the

MAC layer HSDPA SPI (1 .. 15), used by the MAC-hs scheduler (PM29807, PM29804, PM97431) EDCH SPI (1 .. 15), used by the MAC-e scheduler (PM33327) Target Bit Rate (RANAP GBR for PS Streaming or minBrForHsdpa for PS I/B), used by Fair

Sharing of Resources feature (PM33694)

The Allocation/Retention Priority (ARP) is an optional RAB parameter: When absent, the RNC will consider the RAB as being the lowest priority level, compliant

with 3GPP TS25.413 - UTRAN Iu interface RANAP signalling When present, the received ARP priority level is matched with the IuPriorityLevel values

datafilled in the table, to select the ARPBasedQoS instance




Feature Overview:

•Overview









MAC-hs Scheduler Improvement

The MAC-hs scheduler improvements can be separated in two different aspects:• Introduction of different scheduler types• Management of SPI in the MAC-hs scheduler

MAC-hs scheduling consists of selecting the MAC-d flow (QId) to serve, which is based onradio (CQI) and priority (SPI) criteriaThe selection of the QId to be scheduled is based on a single cost function (QId with lowestcost is scheduled first) with inputs from these two criteria (two cost sub-functions, C 1 andC2):• The first one depends on the scheduler type and takes into consideration the radio

conditions• The second one takes into account the priority of the QId and mainly depends on the

Base Credits assigned to this SPI priority and the average CQIBase Credits are assigned per priority, and provide the relative weight given per priority(absolute values are not meaningful as only the ratio between priorities is important)The SPI management is supported by schedulers Classic Proportional Fair and Alcatel-Lucent Proportional Fair, introduced by PM29807 for iCEMWith the introduction of the xCEM, two new schedulers are available, also supporting SPImanagement: CRmax and Proportional Throughput (iso-functional with iCEM schedulerClassic Proportional Fair)




MAC-hs Scheduler Improvement

The SPI management based on relative weight

allows having a proportional differentiation,that is to say the priority between two users iscomputed so that their throughput is proportionalto the ratio of their relative weight, assuming theyhave experienced the same RF conditions (this isachieved by the second cost function, C2).

This function is based on the priority of the QId, thebase credits allocated to this SPI priority and theaverage CQI in order to share the HSDPA radio capacity of the cell between users so thatthe throughput of each QId will be proportional to the weight of the SPI and to thetransport block size corresponding to the averaged CQI reported by the UE:

The base credits assigned per SPI priority (through parameter hsdpaSpiRelativeWeight )provide the relative weight given per priorityTo disable the QoS differentiation, all the relative weights hsdpaSpiRelativeWeight haveto be set with the same value (the value 100 disables totally the SPI managementalgorithm) or all the SPI have to be set with the same value (through parameter spi )




Feature Overview:

•Overview









MAC-e Scheduler Enhancements

This feature comprises several sub-features, among which is PM33614 – PriorityInformation in MAC-e Scheduler, that implements priority management on MAC-e scheduler

The management of priorities is done through E-DCH Scheduling Priority Indicator (SPI),which is retrieved from the Traffic Class (TC), Allocation/Retention Priority (ARP) and TrafficHandling Priority (THP), included in the RANAP RAB ASSIGNMENT REQUEST message

It is possible to configure and signal 16 SPI values to the NodeB, but only 4 priority levelsare supported in UA7Since only 4 behaviours are possible but 16 SPI values available, the operator shall ensurethat only the highest SPI values are usedSimilarly to MAC-hs scheduler, the MAC-e scheduler shall support relative weightingaccording to SPI in order to obtain relative throughput when UEs are under the same radioand traffic conditions




Feature Overview:

•Overview









PS Core Network Requested RAB Modification

In order for a user to be able to transfer PS data, a Packet Data Protocol (PDP) contextmust be activated in the UE and the Core Network (CN)

The PDP context defines the Quality of Service (QoS) requirements negotiated between theUE and the CN and, once activated, the SGSN creates a RAB Assignment Request messagecontaining the negotiated QoS and sends it to the RNC

RAB parameters are then used by the RNC to allocate the Radio Bearer (RB) that willsupport the service (if Call Admission Control is successful)

The applied QoS may need to be modified during the call if the CN identifies:

• A new application type (streaming data flow, peer-to-peer, HTTP)

• A need to provide an increased or reduced data bandwidth to a specific user

The QoS change can be initiated by UE, HLR, SGSN and GGSN

Ps Core Network requested modification procedure changes RAB parameters that werenegotiated during an activation procedure for one or several PDP contexts, by sending aRAB Assignment Request message to the RNC, indicating one or several RAB parameters tomodify




PS Core Network Requested RAB Modification

RNC and Node B support the modification of the following QoS parameters:

Traffic Class (TC) – Interactive to/from Background Maximum Bit Rate (MBR)

Allocation/Retention Priority (ARP)

Traffic Handling Priority (THP)

Signalling Indicator (SI)

Modification of the following QoS parameters is not supported:

Guaranteed Bit Rate (GBR)

Transfer Delay (TD)

Transport Layer Information (TLI)

Traffic Class (TC) – Streaming to/from Interactive or Background




Feature Overview:

•Overview









MBR Handling in the HSDPA Scheduler

For HS-DSCH (HSDPA) and E-DCH traffic (HSUPA), the RNC implements a traffic

conformance mechanism on the Iu interface to ensure that the user traffic neverexceeds the maximum bit rate negotiated at RAB establishment. This mechanism is

optional and can be activated at RNC level (applicable to HSxPA Services)

This capability is based on a token bucket algorithm.

This algorithm is used to verify that traffic packets submitted by the Core Network to

a UMTS bearer do not exceed the requested Max value. It uses the following two parameters (r and b) for the traffic contract and one variable (TBC) for the internal

usage.

• r: token rate, (corresponds to the monitored Maximum bit rate).

• b: bucket size, (the upper bound of TBC, corresponds to bounded burst size).

• TBC (Token bucket counter): the number of remaining tokens at any time.




MBR Handling in the HSDPA Scheduler

Each Time a packet of length Li arrives, the value of TBC is checked. If TBC is large

enough (b ≥ Li), meaning that the packet fits into the buffer, the traffic is considered as conformant and the packet is accepted (as L1 and L2 in picture above), otherwise

it is deleted (as L3).

The value of TBC increases at a rate of “r” by time unit, and does not exceed “b”.

The RNC will actually update TBC each time it receives a packet, by dT*r where dT is

the difference of time between the reception of the current packet and the previouspacket.

In the scope of HSxPA implementation, this algorithm is used to make sure users do

not exceed the original QoS contract.




Feature Overview:

•Overview









MBR Handling in the HSUPA Scheduler

Before this feature was made available, the UL maximum bit rate was handled in the RNCby the Iu Traffic Conformance mechanism, which was not appropriate because the RNCwould typically discarded frames in excess, with severe impact on TCP performance

With the introduction of PM30742, the RNC handles the MBR received in the RANAP RAB ASSIGNMENT REQUEST message and sends it to the Node B in NBAP messages, which willthen limit the scheduling grants, not allowing UE data rates higher than the core specifiedE-DCH MBR

This means the UE generated UL data rate will be restricted to the MBR, thus avoidingdiscarding

MBR is sent only for traffic class PS I/B on E-DCH, as streaming on E-DCH is not supported

The MBR feature is designed to limit the maximum bit rate on physical layer withoutconsidering the HARQ BLER, so the effective rate is lower than MBR in case of high BLER onE-DCH, especially in highly loaded cells where nHarqRetransTargetSx is equal to 1.5.

The E-DCH MBR sent from the RNC to the Node B is calculated as follows




Agenda Introduction

Feature Overview

Agreed profiles

Activation strategy

KPI results

Conclusion

Future Steps




Agreed Profiles

According to STC agreement, we got the following input parameters in order to perform

alignment with core side

We agreed on the below configuration from ALU side

Package Subscriber QoSProfile Name QCI TC THP A RP SPI M BR M BR FUP Weight RNC OLS Classi ficati on EDCH SPI w eight HSDPA SPI wei ght HSDPA SPI EDCH SPI

VIP EQOSVIP BearerQoS_42M bps 6 Interac tive 1 1 7 N/A N/A N o 4000 100.00% 100.00% 7 15

Turbo EQOSTUR BearerQoS_turbo 6 Interactive 1 2 6 N/A N/A No 1000 25.00% 25.00% 6 14

Gold, Silver & Iphone

EQOSGOLD,

EQOSSILVER

&EQOSIPHON

E

BearerQoS_14Mbps,

BearerQoS_7Mbps

&

BearerQoS_4Mbps

7 Interac tive 2 2 4 4096 14400 10GB 450 SILVER 12.00% 12.00% 4 13

Bronze EQOSBRONZE BearerQoS_512kbps 8 Interactive 3 2 3 384 512 1GB 300 5.00% 8.00% 3 12

FUP-profile EQOSFUP BearerQoS_64kbps 8 In te rac tive 3 3 1 64 64 N/A 10 5.00% 1.00% 1 12

default EQOSDEF BearerQoS_default 9 Background N/A 2 2048 7232 N/A 200 5.00% 5.00% 2 12

GOLD

BRONZE




Agenda Introduction

Feature Overview

Agreed profiles

Activation strategy

KPI results

Conclusion

Future Steps




Activation Strategy

Feature plan has been performed to be activated in September.

During activation we faced some problems as we have noticed that some Ues areconfigured with Gold profile (AFAQ Wireless Ues)

It was agreed that these complete unification for profiles will be performed from core

side.

Below table shows feature activation dates on RNC 3RS04

Feature ID Name Implementation date

PM25080 QoS differentiation Based on TC, ARP and THP (UA5.0) 9/9/2013

PM34653 PS Core Network Requested RAB Modification (UA7.1) 9/9/2013

PM30742 MBR Handling in the HSUPA Scheduler (UA7.1) 9/9/2013PM29807 MAC-hs Scheduler Improvement (UA5.0) 11/14/2013 16:00

PM33327 MAC-e Scheduler Enhancements (UA6.0) 11/18/2013 13:54

Iu traffic conformance MBR Handling in the HSDPA Scheduler 11/21/2013 10:04




Agenda Introduction

Feature Overview

Agreed profiles

Activation strategy

KPI results

Conclusion

Future Steps




KPIs results

After feature activation, we noticed that we have some Ues configured on Gold profile.

Problem was escalated to STC and we figured out:“It was agreed that all profiles are correctly mapped from core on the same profile ARP THP 2,2 giving silver profiles, after KPIs checking we found that AFAQ wireless users are mapped on 2,1 profiles providing gold users. Freezewas kept till problem is solved.”

We resumed rest of feature activation on 14th of November.

We still didn‟t get any feedback about all profiles unification from core side




KPIs results

No degradation in Call setup success rate after feature activation




KPIs results

No degradation in Throughput after feature activation

2msec TTI disabled at 11/11/2013 14:00




Agenda Introduction

Feature Overview

Agreed profiles

Activation strategy

KPI results

Conclusion

Future Steps




Conclusion

• Feature is working properly

•

Main KPIs didn‟t affect by feature activation • Roll Out from core side not performed yet so real impact on network not accessed

• We are currently recommend that test SIMs to be configured from core side and

perform some tests with different scenarios at different cell load to ensure end user

quality of experience




Agenda Introduction

Feature Overview

Agreed profiles

Activation strategy

KPI results

Conclusion

Future Steps




Future Steps

• Feature Roll out on the whole network is to be planned

•

Performing tests on new policy server internet.SGSN4 using configured test SIMs inorder to test end user quality of service

• Roll Out from core side in order to perform alignment and to get correct assessment



www.alcatel-lucent.com

stc qosdifferentiation feature fni

Documents