RAN sharing

HQoS guidelines

Issue

3.1

Date

2016-08-26

HUAWEI TECHNOLOGIES CO., LTD.

Copyright Huawei Technologies Co., Ltd. 2011. All rights reserved.

No part of this document may be reproduced or transmitted in any form or by any means without prior
written consent of Huawei Technologies Co., Ltd.

Trademarks and Permissions

and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective
holders.

Notice
The purchased products, services and features are stipulated by the contract made between Huawei and
the customer. All or part of the products, services and features described in this document may not be
within the purchase scope or the usage scope. Unless otherwise specified in the contract, all statements,
information, and recommendations in this document are provided "AS IS" without warranties, guarantees
or representations of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute a warranty of any kind, express or implied.

Huawei Technologies Co., Ltd.

Address:

Huawei Industrial Base

Bantian, Longgang
Shenzhen 518129
People's Republic of China

Website:

http://www.huawei.com

Email:

support@huawei.com

RAN Sharing HQoS guidelines

About This Document

About This Document

Author
Prepared by

Mauro Grandi (employee ID 00737927)

Date

2016-05-13

Reviewed by

Hubaoshun (employee ID 376325)

Date

2016-08-26

Reviewed by

Date

Granted by

Date

Change History
Date

Revised
Version

Change Description

Author

2016-05-13

01

Completed the first draft

Mauro Grandi (employee

ID 00737927)

2016-06-23

02

Added some figures and parameters

Mauro Grandi (employee

ID 00737927)

2016-08-17

03

Modified some figures and paragraphs

Mauro Grandi (employee

ID 00737927)

2016-08-26

03.1

Changed WRED thresholds and added SVR

Mauro Grandi (employee

ID 00737927)

RAN Sharing HQoS guidelines

Contents

Contents
About This Document.......................................................................2
Contents......................................................................................... 3
1 Introduction.................................................................................5
1.1 Objective............................................................................................................................................................5
1.2 HQoS vs traditional QoS...................................................................................................................................5

2 Customer T RAN sharing................................................................8

2.1 Network scenario...............................................................................................................................................8
2.2 RTN HQoS system architecture.......................................................................................................................12
2.3 MW network example......................................................................................................................................12

3 Configuration.............................................................................. 15
3.1 MW link configuration....................................................................................................................................15
3.2 Service configuration.......................................................................................................................................16
3.3 HQoS tests.......................................................................................................................................................18
3.4 HQoS configuration.........................................................................................................................................21
3.4.1 U2000 and RTN950 SVR.......................................................................................................................21
3.4.2 DS profile...............................................................................................................................................22
3.4.3 WRR Scheduling Profile........................................................................................................................27
3.4.4 Service WRED Profile............................................................................................................................29
3.4.5 V-UNI Egress profile..............................................................................................................................32
3.4.6 HQoS port and service setting................................................................................................................35
3.4.7 HQoS Group...........................................................................................................................................37
3.4.8 Egress DSCP Mapping...........................................................................................................................39

4 Appendix.................................................................................... 40
4.1 Specific request of HQoS measurements from a customer.............................................................................40
4.2 Testbed setup....................................................................................................................................................40
4.3 Testing..............................................................................................................................................................41
4.3.1 Testing configuration..............................................................................................................................41
4.3.2 Baseline MW link...................................................................................................................................42
4.3.3 Oversubscribe BE on all VLANS...........................................................................................................43
4.3.4 Oversubscribe BE on all VLANS and Reduce CIR/PIR VLAN 30.......................................................43

RAN Sharing HQoS guidelines

Contents

4.3.5 Reduce BE Traffic in VLAN 30.............................................................................................................44

4.3.6 Increase all streams within the 3G VLAN..............................................................................................44

RAN Sharing HQoS guidelines

1 Introduction

Introducti
on

1.1 Objective
This document is based on Customer T (called in the following CT) transport network for mobile
technologies: 2G, 3G and 4G. They have RAN sharing with Customer V (called in the following CV). This
means that in the same mobile site there are 2 customers using the same transport network. In this case in
order to guarantee each operator a certain amount of data bandwidth: HQoS must be implemented.

1.2 HQoS vs traditional QoS

Hierarchical quality of service (HQoS) is a technology used to guarantee the bandwidth of multiple services
of many subscribers in the differentiated service (DiffServ) model through a queue scheduling mechanism.
The traditional DiffServ QoS technology schedules services based on ports. However, a single port
differentiates service priorities but does not differentiate subscribers. If the traffic data from different
subscribers have the same priority and the traffic data enter the same port queue, these traffic data compete
for the same queue resources and the service quality of all subscribers cannot be guaranteed.
In the HQoS technology recommended by TR-059 on the DSL Forum, data flows are classified into
subscriber queues and service queues. The bandwidth and priority scheduling of subscriber data and service
data are ensured separately through hierarchical scheduling technology. Therefore, the HQoS technology
prevents different subscriber data and service data from preempting bandwidths.
In Figure 1 is shown a possible network scenario where MW is used to carry different services. eNodeB 1
and eNodeB 2 belong to different customers.

RAN Sharing HQoS guidelines

1 Introduction

Figure 1 RAN sharing and transport network example

Referring to network depicted in Figure 1, in Figure 2 is reported traditional DiffServ QoS with the
limitations above mentioned that are solved with the implementation of HQoS.

Figure 2 Traditional DiffServ QoS

In Figure 3 is depicted how HQoS technology is implemented in Huawei MW. It schedules Ethernet services
that are transmitted through five levels, finely controlling the service quality of different subscriber data and
service data.
Level 5: subdivides the services of a subscriber into voice, video, Internet traffic, and others.
Controls the bandwidth of each service type of the subscriber.
Level 4: identifies each subscriber and controls the bandwidth of each subscriber.
Level 3: identifies each subscriber group and controls the bandwidth of each subscriber group. (For
example, the subscribers using different types of base stations can form different subscriber groups.)
Level 2: limits the rate of each queue at an egress port.
Level 1: limits the rate of each egress port.

RAN Sharing HQoS guidelines

Figure 3 HQoS implementation in Huawei MW equipment

The following chapters report some HQoS configurations based on customers requirements.

1 Introduction

RAN Sharing HQoS guidelines

4 Appendix

Customer

T RAN sharing
1.1 Network scenario
CT is sharing RAN sites with CV.
In Figure 4 is reported a simple case of CT MW network topology. For each site there are: OAM, 2G, 3G and
4G data that are carried by MW network to the core network.
For each mobile site, for each customer and for each service (OAM, 2G, 3G, 4G CT and 4G CV) there is an
E-line service configured on MW univocally identified by one VLAN.
On core network there is one VPN configured for each technology for the whole cluster. In total there are 4
VPN for each cluster: 1 VPN for 4G CT, 1 VPN for 4G CV, 1 VPN for 2G/3G together and 1 VPN for OAM.
The number of VPNs is not changing: it does not depend of how many sites there are in the single cluster.

RAN Sharing HQoS guidelines

4 Appendix

Figure 4 CT MW cluster with logical services

Table 1 reports for each service (4G, 3G, 2G) the correspondent DSCP and the PHB expected by the
transport network. OAM is treated as 2G.
MW network (3rd column) must classify packets based on DSCP (2 nd column). Further DSCP must not be
modified by RTN network. In the same way RTN must leave VLAN-priority bits (COS) as they are at the
ingress of the network.

RAN Sharing HQoS guidelines

Row
#
1
2
3
4
5
6
7
8
9
10
11
12

4G Service
Not used for 4G services
Not used for 4G services
QCI-1 (Conversational
voice)
M-plane
QCI-2 (Conversational
video)
QCI-3 (Real-time
gaming)
QCI-4 (Nonconversational video)
QCI-5 (IMS signaling)
and C-plane
QCI-6 ('Gold')
QCI-7 ('Silver')
QCI-8 ('Bronze') and
ICMP
QCI-9 ('Oak')
3G Service

13
14

18

Not used for 3G services

Not used for 3G services
Network Control/SPlane/RT R99
C-plane/HSPA FP
Control
NRT R99/Streaming
HSPA/PS data
M-plane

19

NRT HSPA and ICMP

15
16
17

2G Service
20
21

23
24
25

Not used for 3G services

Not used for 2G services
Network Control/SPlane/CS-Voice
C-plane
PS Data
M-plane

26

ICMP

22

4 Appendix

(56)
NC (48)

RTN
Classifier
and Queue
CS7
CS6

EF (46)

EF

SP

NA

NA

EF

AF11 (10)

AF1

WRR

5%

NA

AF11

AF31 (26)

AF2

Green

AF11

AF42 (36)

AF2

Yellow

AF12

AF32 (28)

AF2

Red

AF12

AF41 (34)

AF3

WRR

10%

NA

AF11

AF21 (18)
AF23 (22)

AF4
BE

WRR

15%

NA
Green

AF11
AF11

DF & CS0 (0)

BE

WRR

30%

Yellow

DE

CS1 (8)

Red

DE

(56)
NC (48)

BE
RTN
Classifier
and Queue
CS7
CS6

EF (46)

DSCP
Marking

DSCP
Marking

Queue
Type

WRR
%

Coloring

IPVPN
CoS

SP
SP

NA
NA

NA
NA

BE
BE

WRR

30%

Queue
Type

WRR
%

Coloring

IPVPN
CoS

SP
SP

NA
NA

NA
NA

BE
BE

EF

SP

NA

NA

EF

AF41 (34)

AF3

WRR

45%

NA

AF11

AF31 (26)

AF2

WRR

45%

NA

AF11

AF11 (10)

AF1

WRR

3%

NA

AF11

DF & CS0 (0)

WRR

7%

NA

DE

Queue
Type

WRR
%

Coloring

IPVPN
CoS

(56)
NC (48)

BE
RTN
Classifier
and Queue
CS7
CS6

SP
SP

NA
NA

NA
NA

BE
BE

EF (46)

EF

SP

NA

NA

EF

AF41 (34)
AF31 (26)
AF11 (10)

AF3
AF2
AF1

WRR
WRR
WRR

45%
45%
3%

NA
NA
NA

AF11
AF11
AF11

DF & CS0 (0)

BE

WRR

7%

NA

DE

DSCP
Marking

Table 1 DSCP mapping for transport network

Queue AF2 and BE for 4G services (rows 5-7, 10-12) are supposed to work with colored packets (color
aware with DSCP), in order to use this information WRED must be implemented on these queues. RTN with
simple classification can work with colored packets in queues AF4-AF1, so BE is not working on this mode

RAN Sharing HQoS guidelines

4 Appendix

and in order to accomplish what requested by CT we have suggested to swap AF1 with BE queues with
correspondent weights, both queues are in WRR the behavior will remain the same.
The 4 different types of services 4G, 3G, 2G and OAM have the mapping between common DSCP and
queue that perfectly overlaps, so it will be possible create only one simple classification map in ingress . In
Table 2 are reported the DSCP values against the PHB in the RTN network. Each packet entering the RTN
network is classified based on DSCP and it is scheduled according with values reported in the table. As
already mentioned DSCP is color aware; it means that on the same AF queue, there are packets with high
(RED), medium (YELLOW) and low (GREEN) discarding probability in case of congestion. In the table are
reported only DSCP and queues used by CT.
DSCP
PHB
46
EF
18
AF41
34
AF31
26
AF21
36
AF22
28
AF23
22
AF11
0
AF12
8
AF13
10
BE
Table 2. DSCP mapping in RTN
For the 4 services the scheduling type queues are the same: CS7, CS6 and EF in SP, the remaining queues in
WRR. The weights of WRR between 4G and 2G/3G/OAM services are different. CS7 and CS6 at the
moment are not used by CT MW network.
Scheduling
Weight WRR Weight WRR
Type
4G
2G-3G-OAM
CS7
SP
CS6
SP
EF
SP
AF4
WRR
15
0
AF3
WRR
10
45
AF2
WRR
30
45
AF1
WRR
30
7
BE
WRR
5
3
Table 3. Queues scheduling type and weights for each service
Queue

1.2 RTN HQoS system architecture

In order to guarantee for each site, for each customer and for each technology a certain amount of bandwidth:
HQoS must be applied.
In Figure 5 is reported RTN HQoS system architecture applicable to E-Line services.

RAN Sharing HQoS guidelines

4 Appendix

Figure 5 RTN HQoS model for E-Line services

1.3 MW network example

In Figure 6 is shown a simple MW network example used in order to explain the RTN detailed configuration in
terms of services and HQoS configuration.
There are 2 mobile sites (site 1 and site 2) and 2 MW links (link 1 and link 2).

Figure 6 Customer network example

Both sites have the following data: OAM, 2G, 3G and 4G for each customer. In the core network there are 4 VPN
OAM, 2G/3G, 4G CT, 4G CV. All services above mentioned are reported in Table 4.
MW Services
OAM CT Site 1
OAM CV Site 1
OAM CT Site 2
OAM CV Site 2

VPN Groups in Core Network

OAM VPN

RAN Sharing HQoS guidelines

4G CT Site 1
4G CT VPN
4G CT Site 2
4G CV Site 1
4G CV VPN
4G CV Site 2
3G CT Site 1
3G CV Site 1
3G CT Site 2
3G CV Site 2
2G/3G VPN
2G CT Site 1
2G CV Site 1
2G CT Site 2
2G CV Site 2
Table 4. Services configured in MW network examples
In order to plan HQoS we must consider that:
1. Each service (2G, 3G, 4G, OAM) has different BW requirements
2. Each service is identified by a VLAN ID
3. The MW links have different capacities
4. There are always 4 VPN in the core network are independent from the cluster size
5. Each VPN has a fixed capacity independent from cluster size
6. RTN QoS and HQoS features/limitations:
a. CIR <= Reference modulation BW
b. PIR <= Maximum modulation BW
Considering all points above mentioned, in Figure 7 are shown the HQoS parameters:
configured for each single service
configured for each site
the V-UNI groups configured in order to be compliant with VPN core network BW.

4 Appendix

RAN Sharing HQoS guidelines

4 Appendix

Figure 7 MW HQoS configuration

In the next chapter is reported the MW configuration for the network depicted in Figure 6, with HQoS settings
and with some test cases in order to verify HQoS behavior.

RAN Sharing HQoS guidelines

4 Appendix

Configurat
ion

1.4 MW link configuration

Starting from scenario depicted in Figure 6, we configured MW network as shown in Figure 8, with the available
data BW reported in Figure 9 and Figure 10.

Link 1

Link 2

Site 2

Site 1

Figure 8 MW network example.

Hub Site

RAN Sharing HQoS guidelines

4 Appendix

Figure 9 Link 2 data configuration

Figure 10 Link 1 data configuration

RAN Sharing HQoS guidelines

1.5 Service configuration

In Figure 11 and Figure 12 are shown the services configured on MW network example.

Figure 11 E-Lines services configured on MW network

Figure 12 Ports, services, VLAN ID configured for each sites

4 Appendix

RAN Sharing HQoS guidelines

4 Appendix

In Figure 13 are shown all the e-line services configured.

Figure 13 E-line service configuration

1.6 HQoS tests

In this paragraph are reported some tests done using the testbed network shown in paragraphs 1.3, 1.4and 1.5.
The Spirent TestCenter (Data Generator Analyzer) is configured with the streams reported in Figure 14 and Figure
15.

RAN Sharing HQoS guidelines

4 Appendix

Figure 14 Streams used to test HQoS

RAN Sharing HQoS guidelines

4 Appendix

Figure 15 Streams configured on Spirent TestCenter

In Figure 16, Figure 17 and Figure 18 are reported 3 test cases in order to verify that HQoS is working as
expected.

RAN Sharing HQoS guidelines

4 Appendix

Figure 16 Test 1

Figure 17 Test 2

RAN Sharing HQoS guidelines

4 Appendix

Figure 18 Test 3

1.7 HQoS configuration

There are different ways to configure HQoS parameters on the RTN equipment. It is always possible to configure
each NE step by step using U2000 or WebLCT, in addition for some parameters there is also the possibility to
create a template on U2000, download it to the NE and apply it in order to deploy the configuration. This second
option is faster than configuring each NE manually and in addition it avoids possible configuration mistakes.
In the following paragraphs there are HQoS configuration menus explained.

1.7.1 U2000 and RTN950 SVR

The entire configurations reported in this document are based on SVR shown in Figure 19 and Figure 20.

RAN Sharing HQoS guidelines

4 Appendix

Figure 19 U2000 SVR

Figure 20 RTN950 SVR

1.7.2 DS profile
In the following are listed the steps in order to create a DS profile template. In Figure 22 and Figure 23 the values
in IP DSCP column are configured according to Table 2.

Figure 21 DS profile creation step 1

RAN Sharing HQoS guidelines

4 Appendix

Figure 22 DS profile creation step 2

Figure 23 DS profile created

In Figure 24 how to download the DS profile template on the NEs.

RAN Sharing HQoS guidelines

4 Appendix

Figure 24 DS profile download on NE

On each NE there is CT_DS_Profile.

Figure 25 DS profile on the NE

It is also possible to directly download and configure the DS profile on the ports. In Figure 26, Figure 27, Figure
28, Figure 29 are reported all the steps required to do it.

RAN Sharing HQoS guidelines

4 Appendix

Figure 26 DS profile download to port:1st step

Figure 27 DS profile download to port: 2nd step, NE and port selection

RAN Sharing HQoS guidelines

Figure 28 DS profile download to port: 3rd step, application object selection on the port

Figure 29 DS profile downloaded successfully to port

On the port there is CT_DS_Profile configured.

4 Appendix

RAN Sharing HQoS guidelines

4 Appendix

Figure 30 DS profile downloaded and configured on the port

1.7.3 WRR Scheduling Profile

In this paragraph are reported the steps in order to create a WRR Scheduling Profile template. In Figure 32 and
Figure 33 the values of IP DSCP column are configured according to Table 3. Please note that the example refers
only to 4G service, the same configuration has been done for 2G-3G service.

Figure 31 WRR Scheduling profile creation step 1

RAN Sharing HQoS guidelines

4 Appendix

Figure 32 WRR Scheduling profile creation step 2

Figure 33 WRR Scheduling profile created

In Figure 34 how to download the WRR profile template on the NEs.

RAN Sharing HQoS guidelines

4 Appendix

Figure 34 WRR Scheduling profile template downloading on NE

On each NE there are 4Gservice and 2G3Gservice WRR scheduling profile.

Figure 35 WRR Scheduling profiles on the NE

1.7.4 Service WRED Profile

In Figure 37 and Figure 38 are reported the steps in order to create a WRED profile template. Please note that the
values for the thresholds reported below are right for RTN950, other type of RTN device, please contact HQ team
to check the parameters.

RAN Sharing HQoS guidelines

4 Appendix

Figure 36 Service WRED profile creation step 1

Figure 37 Service WRED profile creation step 2

RAN Sharing HQoS guidelines

4 Appendix

Figure 38 Service WRED profile created

In Figure 39 how to download the WRED profile template on the NEs.

Figure 39 WRED profile template downloading on NE

On each NE there is WRED_CT profile.

RAN Sharing HQoS guidelines

4 Appendix

Figure 40 WRED profile on the NE

1.7.5 V-UNI Egress profile

In Figure 42 and Figure 43 are reported the steps in order to create a V-UNI egress profile template.

Figure 41 V-UNI Egress profile creation step 1

RAN Sharing HQoS guidelines

4 Appendix

Figure 42 V-UNI Egress profile creation step 2

Figure 43 V-UNI Egress profile created

In the same way 2G-3G V-UNI Egress profile has been created.
In Figure 44 how to download the V-UNI Egress profile template on the NEs.

RAN Sharing HQoS guidelines

4 Appendix

Figure 44 V-UNI Egress profile downloading on NE

On each NE there is V-UNI Egress profile (see Figure 45 and Figure 46).

Figure 45 V-UNI Egress profile on the NE CoS configuration

RAN Sharing HQoS guidelines

4 Appendix

Figure 46 V-UNI Egress profile on the NE Application Object

1.7.6 HQoS port and service setting

In Figure 47 there is an example of Port QoS configurations over one e-line service done directly from
U2000. It is configured a 4G service with classification based on IP DSCP and matching CT_DS_Profile (see
1.7.2) along all the interfaces passed through by the service. In Figure 48 is reported the same configuration
above mentioned on a single NE.

Figure 47 Port QoS menu configuration example

RAN Sharing HQoS guidelines

4 Appendix

Figure 48 Diffserv Domain Management menu on NE

In Figure 49 there is an example of UNI QoS configurations over one e-line service done directly from
U2000. In the example there is the HQoS configuration for 4G CT Site 2. In Figure 50 is reported the same
configuration above mentioned on a single NE.

Figure 49 UNI QoS menu configuration example

RAN Sharing HQoS guidelines

4 Appendix

Figure 50 UNI QoS menu configuration on NE

1.7.7 HQoS Group

In Figure 51 are reported all the services (e-lines) configured on a NE. It is possible to form a group with 1
or more services and configure CIR/PIR on it. In Figure 52 and Figure 53 for example 4G CT site 1 and site
2 are grouped and with a CIR and PIR.

Figure 51 Different E-Lines service configured on a NE

RAN Sharing HQoS guidelines

4 Appendix

Figure 52 V-UNI group creation on a NE

Figure 53 V-UNI group created on a NE

RAN Sharing HQoS guidelines

4 Appendix

1.7.8 Egress DSCP Mapping

In order to leave DSCP as it is when enters the MW network configure Egress DSCP Mapping Status
Disables as depicted in Figure 54.

Figure 54 Egress DSCP Mapping status menu

RAN Sharing HQoS guidelines

4 Appendix

Appendix

2.1 Specific request of HQoS measurements

from a customer
At the beginning of 2016 one customer came to Milan MW Testbed in order to verify some RTN HQoS features.
The MBNL Network of the customer has evolved to carry 2G, 3G and 4G services. However these services are
separated with dedicated capacity which works fine when the network is not congested. As the network becomes
congested the ability to deploy QoS per VLAN for segregation of services over MW radios becomes a
requirement. This was the scope of the visit: make some tests in order to understand the RTN capabilities in terms
of HQoS. In the following are summarised the tests directly proposed by this customer.

2.2 Testbed setup

In order to verify HQoS MW features the testbed was setup as reported in Figure 55. From port 4/4 on the tester
was delivered a fibre connection carrying VLANs 2, 20 and 30, each VLAN contains streams of EF, AF4, AF1
and BE traffic. This traffic is then transported across a contended MW link to establish how the traffic was
prioritised and dropped.
All testing is done using random packet size 64 to 1500 Bytes.
The frequency and modulation are set to make the MW link throughput around 100Mbps.

RAN Sharing HQoS guidelines

4 Appendix

Figure 55 Testbed measurement setup

2.3 Testing
2.3.1 Testing configuration
The IDU will be set with 100Mbps on the MW link and CIR/EIR/PIR will be set as follows on the MW link:

The test will be based on the following traffic analysis from MBNL:

RAN Sharing HQoS guidelines

To this end the VLANs and streams will be setup as follows:

The VLANs will be mapped to the following queue profiles.

2.3.2 Baseline MW link

The tester will be set to the following to reflect both the traffic streams and the VLANS.

4 Appendix

RAN Sharing HQoS guidelines

4 Appendix

2.3.3 Oversubscribe BE on all VLANS

This test is to ensure only BE traffic is dropped from within each VLAN.
The tester will be set with the following configuration:

2.3.4 Oversubscribe BE on all VLANS and Reduce

CIR/PIR VLAN 30
This is to ensure a maximum capacity can be attributed to any VLAN.
Se the CIR/PIR to VLAN 30 as follows:

RAN Sharing HQoS guidelines

4 Appendix

2.3.5 Reduce BE Traffic in VLAN 30

Return the CIR/PIR to original values then reduce BE on VLAN 30.
This is to ensure that the additional BE load is able to burst into unused BE capacity in other VLANs but that
native prioritisation is not affected.

This test can be repeated for the other PHBs if required and different burst rates measured.

2.3.6 Increase all streams within the 3G VLAN

This is to ensure all WRR traffic is treated correctly against the VLAN.

RAN Sharing HQoS guidelines

4 Appendix