RAN Sharing

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
Issue 3.1 (2016-08-26) Huawei Proprietary and Confidential 1

Copyright Huawei Technologies Co., Ltd
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
Mauro Grandi (employee
2016-05-13 01 Completed the first draft
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
4.3.5 Reduce BE Traffic in VLAN 30 ............................................................................................................ 44

RAN Sharing HQoS guidelines Contents
4.3.6 Increase all streams within the 3G VLAN ............................................................................................ 44

RAN Sharing HQoS guidelines 1 Introduction
1 Introduction
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.

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.

Figure 3 HQoS implementation in Huawei MW equipment
The following chapters report some HQoS configurations based on customers requirements.

RAN Sharing HQoS guidelines 2 Customer T RAN sharing
2 Customer T RAN sharing
2.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.
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 (2nd 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.

RTN
Row DSCP Queue WRR IPVPN
4G Service Classifier Coloring
# Marking Type % CoS
and Queue
1 Not used for 4G services (56) CS7 SP NA NA BE
2 Not used for 4G services NC (48) CS6 SP NA NA BE
QCI-1 (Conversational
3 EF (46) EF SP NA NA EF
voice)
4 M-plane AF11 (10) AF1 WRR 5% NA AF11
QCI-2 (Conversational
5 AF31 (26) AF2 Green AF11
video)
QCI-3 (Real-time
6 AF42 (36) AF2 Yellow AF12
gaming) WRR 30%
QCI-4
7 (Non-conversational AF32 (28) AF2 Red AF12
video)
QCI-5 (IMS signaling)
8 AF41 (34) AF3 WRR 10% NA AF11
and C-plane
9 QCI-6 ('Gold') AF21 (18) AF4 WRR 15% NA AF11
10 QCI-7 ('Silver') AF23 (22) BE Green AF11
QCI-8 ('Bronze') and
11 DF & CS0 (0) BE WRR 30% Yellow DE
ICMP
12 QCI-9 ('Oak') CS1 (8) BE Red DE
RTN
DSCP Queue WRR IPVPN
Marking Type % CoS
and Queue
Network
15 EF (46) EF SP NA NA EF
Control/S-Plane/RT R99
C-plane/HSPA FP
16 AF41 (34) AF3 WRR 45% NA AF11
Control
NRT R99/Streaming
17 AF31 (26) AF2 WRR 45% NA AF11
HSPA/PS data
19 NRT HSPA and ICMP DF & CS0 (0) BE WRR 7% NA DE
RTN
DSCP Queue WRR IPVPN
Marking Type % CoS
and Queue
Network
22 Control/S-Plane/CS-Voic EF (46) EF SP NA NA EF
e
23 C-plane AF41 (34) AF3 WRR 45% NA AF11
24 PS Data AF31 (26) AF2 WRR 45% NA AF11
26 ICMP DF & CS0 (0) BE WRR 7% NA DE
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
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

Queue
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

2.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.
Figure 5 RTN HQoS model for E-Line services
2.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 VPN Groups in Core Network

OAM CT Site 1
OAM CV Site 1
OAM VPN
OAM CT Site 2
OAM CV Site 2
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.

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 3 Configuration
3 Configuration
3.1 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 2 Link 1
Site 2 Site 1 Hub Site

Figure 8 MW network example.
Figure 9 Link 2 data configuration

Figure 10 Link 1 data configuration
3.2 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
In Figure 13 are shown all the e-line services configured.
Figure 13 E-line service configuration

3.3 HQoS tests

In this paragraph are reported some tests done using the testbed network shown in paragraphs 2.3 , 3.1 and 3.2 .
The Spirent TestCenter (Data Generator Analyzer) is configured with the streams reported in Figure 14 and
Figure 15.
Figure 14 Streams used to test HQoS

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.

Figure 16 Test 1
Figure 17 Test 2

Figure 18 Test 3
3.4 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.
3.4.1 U2000 and RTN950 SVR

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

Figure 19 U2000 SVR
Figure 20 RTN950 SVR
3.4.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

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.

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.

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

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.

Figure 30 DS profile downloaded and configured on the port
3.4.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

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.

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
3.4.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.

Figure 36 Service WRED profile creation step 1
Figure 37 Service WRED profile creation step 2

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.

Figure 40 WRED profile on the NE
3.4.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

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.

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

Figure 46 V-UNI Egress profile on the NE Application Object
3.4.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
3.4.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

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

Figure 50 UNI QoS menu configuration on NE
3.4.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

Figure 52 V-UNI group creation on a NE
Figure 53 V-UNI group created on a NE

3.4.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
4 Appendix
4.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.
4.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.

4/1 VLAN 3
VLAN 20
4/2 4/4 VLAN 30
4/3
Node 2 Node 1
VLAN 3 NE3
VLAN 20 NE2 MC3
VLAN 30
IDU
IDU 22 IDU
IDU 11
NE1
Modem 1 Modem 1 DWRR Weighting

VLAN 3 wieghting 20
VLAN 20 weighting 40
VLAN 30 Weighting 40
Throughput 100Mbps
Figure 55 Testbed measurement setup
4.3 Testing
4.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:
Technology VLAN CIR Mbps EIR Mbps PIR Mbps

3G 3 20 80 100
Co-TX1 20 40 60 100
Co-TX2 30 40 60 100
The test will be based on the following traffic analysis from MBNL:

IPAbis 3G 4G
EF % 39.00% EF % 9.00% EF % 2.50%
AF4 % 1.00% AF4 % 1.00% AF4 % 0.00%
AF3% 0.00% AF3% 0.00% AF3% 0.00%
AF2% 1.00% AF2% 0.00% AF2% 0.00%
AF1% 57.00% AF1% 0.00% AF1% 2.00%
BE % 2.00% BE % 90.00% BE % 95.50%
To this end the VLANs and streams will be setup as follows:
VLAN CIR Mbps PIR Mbps Scheduler Weight

3 20 100 DWRR 20
20 40 100 DWRR 40
30 40 100 DWRR 40
The VLANs will be mapped to the following queue profiles.
Stream VLAN/Tech Guarantee Sheduler Weight

1 3 (3G) 2Mbps SP
2 3 (3G) 2Mbps SP
3 3 (3G) DWRR 2
4 3 (3G) DWRR 1
5 20 (Co-TX1) 2Mbps SP
7 20 (Co-TX1) DWRR 2
8 20 (Co-TX1) DWRR 1
11 30 (Co-TX2) DWRR 2
12 30 (Co-TX2) DWRR 1
4.3.2 Baseline MW link

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

Stream VLAN/Tech PHB DSCP Pbit Bits Tx Mbps Rx Mbps

1 3 (3G) EF 46 6 110 2
2 3 (3G) AF4 34 5 101 2
3 3 (3G) AF1 10 1 001 1
4 3 (3G) BE 0 0 000 15
5 20 (Co-TX1) EF 46 6 110 2
6 20 (Co-TX1) AF4 34 5 101 2
7 20 (Co-TX1) AF1 10 1 001 2
8 20 (Co-TX1) BE 0 0 000 34
9 30 (Co-TX2) EF 46 6 110 2
10 30 (Co-TX2) AF4 34 5 101 2
11 30 (Co-TX2) AF1 10 1 001 2
12 30 (Co-TX2) BE 0 0 000 34
4.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:

1 3 (3G) EF 46 6 110 2
2 3 (3G) AF4 34 5 101 2
3 3 (3G) AF1 10 1 001 1
4 3 (3G) BE 0 0 000 25
5 20 (Co-TX1) EF 46 6 110 2
6 20 (Co-TX1) AF4 34 5 101 2
7 20 (Co-TX1) AF1 10 1 001 2
8 20 (Co-TX1) BE 0 0 000 50
9 30 (Co-TX2) EF 46 6 110 2
10 30 (Co-TX2) AF4 34 5 101 2
11 30 (Co-TX2) AF1 10 1 001 2
12 30 (Co-TX2) BE 0 0 000 50
4.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:
Technology VLAN CIR Mbps EIR Mbps PIR Mbps

3G 3 20 80 100
Co-TX1 20 40 60 100
Co-TX2 30 10 10 20


1 3 (3G) EF 46 6 110 2
2 3 (3G) AF4 34 5 101 2
3 3 (3G) AF1 10 1 001 1
4 3 (3G) BE 0 0 000 25
5 20 (Co-TX1) EF 46 6 110 2
6 20 (Co-TX1) AF4 34 5 101 2
7 20 (Co-TX1) AF1 10 1 001 2
8 20 (Co-TX1) BE 0 0 000 50
9 30 (Co-TX2) EF 46 6 110 2
10 30 (Co-TX2) AF4 34 5 101 2
11 30 (Co-TX2) AF1 10 1 001 2
12 30 (Co-TX2) BE 0 0 000 50
4.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.

1 3 (3G) EF 46 6 110 2
2 3 (3G) AF4 34 5 101 2
3 3 (3G) AF1 10 1 001 1
4 3 (3G) BE 0 0 000 25
5 20 (Co-TX1) EF 46 6 110 2
6 20 (Co-TX1) AF4 34 5 101 2
7 20 (Co-TX1) AF1 10 1 001 2
8 20 (Co-TX1) BE 0 0 000 50
9 30 (Co-TX2) EF 46 6 110 2
10 30 (Co-TX2) AF4 34 5 101 2
11 30 (Co-TX2) AF1 10 1 001 2
12 30 (Co-TX2) BE 0 0 000 20
This test can be repeated for the other PHBs if required and different burst rates measured.
4.3.6 Increase all streams within the 3G VLAN

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


1 3 (3G) EF 46 6 110 4
2 3 (3G) AF4 34 5 101 4
3 3 (3G) AF1 10 1 001 2
4 3 (3G) BE 0 0 000 32
5 20 (Co-TX1) EF 46 6 110 2
6 20 (Co-TX1) AF4 34 5 101 2
7 20 (Co-TX1) AF1 10 1 001 2
8 20 (Co-TX1) BE 0 0 000 34
9 30 (Co-TX2) EF 46 6 110 2
10 30 (Co-TX2) AF4 34 5 101 2
11 30 (Co-TX2) AF1 10 1 001 2
12 30 (Co-TX2) BE 0 0 000 34


RAN Sharing - HQoS Guidelines - Ver. 3.1

Uploaded by

Copyright:

Available Formats

RAN Sharing - HQoS Guidelines - Ver. 3.1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

RAN Sharing - HQoS Guidelines - Ver. 3.1

Uploaded by

Copyright:

Available Formats

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue 3.1 (2016-08-26) Huawei Proprietary and Confidential 1

About This Document

Reviewed by Hubaoshun (employee ID 376325) Date 2016-08-26

Issue 3.1 (2016-08-26) Huawei Proprietary and Confidential 2

About This Document ..................................................................................................................... 2

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

Issue 3.1 (2016-08-26) Huawei Proprietary and Confidential 3

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

Issue 3.1 (2016-08-26) Huawei Proprietary and Confidential 4

1.2 HQoS vs traditional QoS

Issue 3.1 (2016-08-26) Huawei Proprietary and Confidential 5

Figure 1 RAN sharing and transport network example

Figure 2 Traditional DiffServ QoS

Issue 3.1 (2016-08-26) Huawei Proprietary and Confidential 6

Figure 3 HQoS implementation in Huawei MW equipment

Issue 3.1 (2016-08-26) Huawei Proprietary and Confidential 7

2 Customer T RAN sharing

2.1 Network scenario

Figure 4 CT MW cluster with logical services

Issue 3.1 (2016-08-26) Huawei Proprietary and Confidential 8

Issue 3.1 (2016-08-26) Huawei Proprietary and Confidential 9

Issue 3.1 (2016-08-26) Huawei Proprietary and Confidential 10

Scheduling Weight WRR Weight WRR

Issue 3.1 (2016-08-26) Huawei Proprietary and Confidential 11

2.2 RTN HQoS system architecture

Figure 5 RTN HQoS model for E-Line services

2.3 MW network example

Figure 6 Customer network example

Issue 3.1 (2016-08-26) Huawei Proprietary and Confidential 12

MW Services VPN Groups in Core Network

In order to plan HQoS we must consider that:

Issue 3.1 (2016-08-26) Huawei Proprietary and Confidential 13

Figure 7 MW HQoS configuration

Issue 3.1 (2016-08-26) Huawei Proprietary and Confidential 14

3.1 MW link configuration

Site 2 Site 1 Hub Site

Figure 9 Link 2 data configuration

Issue 3.1 (2016-08-26) Huawei Proprietary and Confidential 15

Figure 10 Link 1 data configuration

3.2 Service configuration

Figure 11 E-Lines services configured on MW network

Issue 3.1 (2016-08-26) Huawei Proprietary and Confidential 16

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

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

Figure 13 E-line service configuration

Issue 3.1 (2016-08-26) Huawei Proprietary and Confidential 17

3.3 HQoS tests

Figure 14 Streams used to test HQoS

Issue 3.1 (2016-08-26) Huawei Proprietary and Confidential 18

Figure 15 Streams configured on Spirent TestCenter

Issue 3.1 (2016-08-26) Huawei Proprietary and Confidential 19

Issue 3.1 (2016-08-26) Huawei Proprietary and Confidential 20

3.4 HQoS configuration

3.4.1 U2000 and RTN950 SVR

Issue 3.1 (2016-08-26) Huawei Proprietary and Confidential 21