module 5 - iub plannig

For internal use onlyPresentation / Author / Date 1 © Nokia Siemens Networks

Module 5 – Iub planning


Overview of Iub Planning

• The Iub planning module will include following items– Ethernet interface planning– Scheduling– Iub user plane configuration– Iub control plane configuration– IP addressing– Protection and resiliency– Routing– QoS– Site solution for Iub

• Note: cRNC (“classical RNC”) is used to address RNC196/450/2600


Iub Planning

• Ethernet interface planning

• Scheduling

• Iub user plane configuration

• Iub control plane configuration

• IP addressing

• Protection and resiliency

• Routing

• QoS

• mcRNC site solution for Iub


Ethernet interface in the cRNC - NPGE

• RNC2600 can be equipped with up to 16 NP2GE units, 16 NPGE or 8+8 NPGEP), creating a total of 28 Gbit Ethernet ports configurable for use with Iu-CS, Iu-PS, Iub, and Iur.

• With respect to the (protected) NPGEP configuration a fixed assignment of working (WO) and spare (SP) units exists:

Working unit 0 2 4 6 8…

Spare (protecting) unit 1 3 5 7 9

Area [unit] NPGE limit

Comment

Throughput [bps] 2 x 1Gbps

Backplane connection in RNC limits total throughput to 1.65Gbps

IP packets [1/s] 2.6Mpps

UDP ports [number] 64509 Per IP address

Number of static routes

3000

Number of VLANs 600

Number of IP based routes

1024

Number of BFD sessions

600


NPGE and NPS1 Units in RNC2600

• The max number of possible NPGEs is depending also on the number of needed NPS1 units


Ethernet Interface Parameters in NPGE

• All ports that are connected towards RNC must be configured to auto-negotiation mode in external switch in RU20– Reason for this is that in RNC IPA2800 HW port mode is always auto-

negotiation (cannot be changed)


NPGE and Control Plane Limitation

• In addition there is a control plane limitation depending on the logical interfaces located within the NPGE– Normally it is recommended to separate the Iu and Iub on separate interfaces

or even NPGEs

• There are weights defined for the different signalling events for calculating the NPGE fill rate (like RNC2600 control plane rule)

• For Iub the weights apply for IP Iub

NPGE(P) CS BHCA NPGE(P) PS BHCA

Iu-CS/Iu-PS 1280000 850590

Iub 626370 512160

Iub/Iu-CS/Iu-PS 583960 386950

NPGE dimensioning


Ethernet Interface in the mcRNC - EIPU

6 x 1 or 10 Gbps 16 x 1 Gbps


Ethernet Interfaces in EIPU for mcRNC

• The External Interface Processing Unit hosts the networking and transport stacks needed for processing both signaling and user plane data– It also handles the load balancing and distribution to other units.

• mcRNC offers – SFP bays (for 1 Gigabit Ethernet connections) – SFP+ bays, which can be equipped with both 1 Gigabit and 10 Gigabit

modules.

• Supported standards are:– 1000Base-TX, RJ-45 connector, electrical transmission using twisted pair cable– 1000Base-SX/LX, LC connector, optical transmission using single-mode fiber

(SMF) – 10GBase-LR, LC connector, optical transmission using single-mode fiber (SMF) – 10GBase-SR, LC connector, optical transmission using multi-mode fiber (MMF)

• Both external network interfaces in mcRNC and those connected in the site switches will be configured to L3 mode, i.e. being assigned dedicated IP addresses


Iub Planning


• Scheduling



• IP addressing


• Routing

• QoS



Scheduling

• The logical scheduling architecture is composed of two levels: – One level controlling the egress traffic for each IP based route

separately

– One level handling IP traffic for the whole IP interface The IP interface can be the physical Ethernet interface or in the case of

mcRNC Link Aggregation Group (LAG).

Available only for Iub


IP Based Route Scheduler

• The rate limiting is done using Internal Flow Control (IFC)– Only available for Iub

– IFC can be applied to AF1, AF2, AF3, AF4, and BE traffic

– In the mcRNC the average rate of the aggregate traffic can be limited by IFC or by using E-RED queue management that drops packets from the queue in case of congestion new parameter in IP based route for mcRNC

By default the queues Q1, Q2 and Q6 are used without Iub transport QoS feature

Q7 is used for Iur traffic


IP Based Route Scheduler in mcRNC

• The IP based route scheduling in the cRNC is always virtual• In the mcRNC there are two alternatives for scheduling in

the mcRNC at IP based route level

1. Virtual Scheduling means the system is not providing dedicated buffers for each of the queues of each IP based route

Instead packets are stored in the physical (interface) queues directly and individual queues are represented by byte/packet counters

IFC event triggering queue management shall only be provided in case of virtual scheduling

2. Real Scheduling means the system is providing dedicated buffers for each of the queues of each IP based route

This allows more accurate scheduling/shaping than the virtual scheduling approach at the cost of memory and processing power

E-RED queue management that drops packets from the queue in case of congestion is used


Interface Scheduler

• There is no flow control in interface level, no rate limiting

• Exponential Random Early Detection (E-RED) queue management is supported in the cRNC and in the mcRNC in the interface level to avoid TCP global synchronization


Iub Planning


• Scheduling



• IP addressing


• Routing

• QoS


Iub User Plane Configuration

• IP based route is a proprietary concept of Nokia Siemens Networks

• It defines bandwidths available for the user plane connection between the RNC and another network element (NE)

• There can be one or two IP based routes for an Iub connection – The second IP based route can be taken into use, if RAN 1709 VLAN

Based Traffic Differentiation is taken into use

– Otherwise one IP based route per destination is recommended

• IP based route is normally attached to one interface, but load sharing for Iub is also possible


IP Based Route

User plane:

IP based route

Signalling (no IPBR)

RNC

MGW

Destination

RNC

Source

Ro

ute

BW

IP based committed BW

Incl. sig and dcn

SGSN

BTS


IP based Route for Iub - IFC = OFF & CAC in use

• When IFC is OFF and CAC is in use: CAC reservation is limited to IP based committed BW,

• non-CAC Traffic will occupy the unused capacity within Interface BW

• Interface_BW is the limiting factor for all traffic combined

• Used for example together with HSDPA CC when doing HSDPA user differentiation (IFC=OFF)

CAC controlled Traffic

Non-CAC traffic

Reservation

IP based route BW

Interface BW


– committed DCN BW

– committed sig BW


IP based Route for Iub - IFC = ON & CAC in use

• When IFC = ON and CAC is in use: CAC reservation is limited to IP based committed BW – sign BW – dcn BW (actual traffic can be less depending on configured AFs)

• non-CAC Traffic will occupy the unused capacity within the IP based route BW

• IP based route BW is the limiting factor for all traffic combined

Non-CAC traffic

IP based route BW

Interface BW

CAC controlled Traffic


– committed DCN BW

– committed sig BW

Reservation


Basic IP based route parameters in RNC for Iub

IP Route BW (kbps)

Committed BW (kbps)

Committed Signaling BW

(kbps)

Committed DCN BW (kbps)

IFC

30000 20000 1000 100 ON

CAC is enabled by setting these parameters.

IFC is enabled by setting it ON hence the IP Route BW value has an impact.


IP Based RouteDiscussion points

• When would you need to enable CAC for an IP based route?


Optional IP based Route ParametersEfficient Transport for Small Packets

• New parameters to IP based route related to Efficient transport for small packets

Optional IP Based Route Parameters Data format Value Range Units

Default Value

Example

UdpMuxEnabled NUMERIC 0 (Disable), 1 (Enable)

0 optional

LocalMuxUDPPort NUMERIC 49152..65535, step 1

65535 optional

MaxMuxPackets NUMERIC 5..30, step 1 30 optional

UdpMuxDSCP NUMERIC 0..63, step 1 46 optional

RemoteMuxUDPPort NUMERIC 49152..65535, step 1

65535 optional

Note that "RAN2338 Iub loadsharing with protected NPGEs" and "RAN1886 Efficient Transport for Small IP Packets" influence each other. With RAN2338 transport bearers are distributed across multiple NPGEs and thus multiple destination IP addresses in RNC, frame protocol multiplexing performed by RAN1886 however can only take effect on IP packets with same IP address. Nonetheless, when RAN2338 is applied in Iub the highest voice call efficiency is provided with RAN1886 applied in addition.


IP Based Route Parameters in mcRNC

• The concept for the IP based route is the same in the cRNC and mcRNC

• However there are some optional parameters for IP based route related to QoS, internal flow control for NRT DCH and HSDPA traffic and scheduler type.


Iub Load Sharing

• Load sharing in the Iub interface is not officially supported before RU30 on top and the feature RAN2338 Iub load sharing with protected NPGEs

• Before RAN2338 Iub load sharing is used with the limitation of– IFC cannot be used – IP CAC can not be used

• This is fine as long as there is enough capacity towards the BTS and there is no real need to limit the traffic to ensure QoS for CS and NRT DCH services.

• Load sharing is working also for the Iub control plane from RU20 on top onwards (correction related to RAN1709). – When the control plane is created, the NPGE allocation is done. Before

RU20 on top, the control plane was using the NPGE unit with the lowest index.


Load sharing with Protected NPGEs (RAN2338)

• Load sharing with protected NPGEs means that BTS is logically connected to a pool of NP2GEs instead of single NP2GE

• Iub load i.e. transport bearer is allocated using round robin to different interfaces– The IP address selection shall happen each time a user plane bearer is

created– Reduced operational effort for planning and dimensioning as well as

reduced need for re-homing BTSs to different NP2GE– RAN2338 will also enable using IP CAC for Iub when load sharing is

used CAC functionality is moved from interface unit NPGE to RSMU

– Traffic shaping per BTS cannot be done (no IFC) therefore there would need to be enough bandwidth towards the BTS

• One IP based route shall support up to 16 IP addresses on cRNC side interface units.


Iub Load Sharing with NPGEs

• If the IP based route contains the IP addresses on only one NP2GE unit, it supports also the IP based route rate shaping– This kind of IP based route could be used in case that there is a bandwidth limitation in last mile or

certain location.


Iub Load Sharing in mcRNC

• IP based route for the Iub connection can be associated to several IP addresses on different EIPU units


VLAN Differentiation in RNC

• There are different options to configure VLAN differentiation– One IP based route attached to two IP addresses on the same or

different physical interface on the same NPGE(P) unit (picture)

– Two IP based routes attached to two IP addresses on different GE interfaces on two different NPGE(P) units

Configuring IP connection to NPGE

Document link


VLAN Differentiation in RNC

• IP based route is assigned to NPGE unit and with the same command the PHBs are assigned to VLAN interface

• Example on one IP based route assigned to two VLAN interfaces– ZQRU:ADD:20,"IPROUTE":11000:10000:100:100:OFF;

– ZQRC:NPGEP,0:VL2:IPV4=10.33.160.4:ID=20:PHB="EF,AF4";

– ZQRC:NPGEP,0:VL3:IPV4=10.33.160.20:ID=20:PHB="AF1,AF2,AF3,BE";

– Value of 'ifc_option' is OFF, which means there is no flow control for this IP-based route and RNC does no traffic shaping for the BTS.

– The PHB sets are configured complementary to each other and together cover all the six PHBs.


VLAN Differentiation in BTS

• Traffic shaping type is either 1. Path – traffic shaper per VLAN (SIR, SBS)

2. WFQ – traffic shaped WFQ aggregator level to a value defined by the Total shaper information rate

3. OFF – interface level shaping only

1

1

2 3


VLAN Differentiation

• Parameter considerations

It was found out in RU20EP1 tests that

low priority VLAN CIR cannot be

defined = 0, but for example 0.1 Mbps


Iub UP Planning Using RNC Data FillIP Based Route


Iub UP Planning Using RNC Data FillIP Based Routes Network


UDP port allocationGeneral

• The UDP ports are used to identify the different user plane transport bearers

• RNC and Node B choose their local UDP ports independently

• The local UDP ports are exchanged between RNC and Node B using NBAP messages during radio link setup

• The Node B has theoretical a pool of approx. 16000 ports.

• The RNC has a pool of approx. 64000 ports per IP address => 1.2M ports per interface unit (without VLANs)– The pool in one IP address is shared by all the Node Bs for which that IP

address is allocated

– The sharing of the pool depends on the configuration of the minUDPPortIub parameter

– Maximum port number cannot be achieved due to the limited number of calls that the NPGE can handle


UDP port allocationNode B

The Node B allocates the local UDP ports during call setup, starting by the lower end of the range, as defined by the parameter minUDPPortFor this use case the number of ports is estimated in 210 (according to the traffic model)UDP port overlapping at BTS side is allowed as each BTS has a different user plane IP Address

Network Element minUDPPort UDP port range

BTS1 49152 49152-49361

BTS2 49152 49152-49361

BTS3 49152 49152-49361

UDP port pool (for one BTS)

minUDPPort

Estimated maximum UDP Port (implicitly defined by the number of expected calls)

49152 65535


UDP port allocationRNC

Same user plane IP address at RNC side is configured for the considered Node Bs. By default all the RNC will allocate ports for all the Node Bs starting the range at the same point, as defined by the parameter minUDPPortIub.The parameter minUDPPortIub could be the same for all Node B (default value)

Network Element minUDPPortIub

RNC for BTS1 1026

RNC for BTS2 1026

RNC for BTS3 1026

UDP port pool (per IP address)

minUDPPortIub

1026 65535

In the current implementation RNC will simply continue to use increasing port number until reaching the 65535 and then start over from the minUpdPort

For all BTSs in the RNC the default 1026 can be used


Iub Planning


• Scheduling



• IP addressing


• Routing

• QoS


Iub Control Plane Capacity

• Capacity for Iub control plane is reserved using IP based route signaling bandwidth parameter– It limits the user plane connections (IP based route committed BW – IP

based route signaling BW – IP based route dcn BW)

• However, the signaling traffic is not limited by this parameter

• Capacity is ensured by allowing only CAC controlled traffic into EF and AF4 queues in the RNC

• The recommendation is 6% – see Dimensioning WCDMA RAN for more details https://

online.portal.nokiasiemensnetworks.com/pic/nedproxy/NED?library=a25003a0000b5240376p1&action=retrieve&identifier=dn19660707&edition=1&language=en&coverage=global&encoding=oem_pdf_a4&idmapencoding=ned_toc_1_0&source=xdoc&component=data&item=pdf/wran_dim_access_net.pdf


Iub Control Plane Configuration

• Iub Control plane configuration requires– SCTP port configuration for CNBAP, DNBAP

Number of SCTP ports depends on the BTS type


SCTP port allocationGeneral (I)

The SCTP ports are used to identify the different NBAP links– Flexi (1 C-NBAP and 1 D-NBAP): 2 ports– Ultra (1 C-NBAP and 6 D-NBAP): 7 ports (maximum)

The Node B allocates the local SCTP ports in a predefined manner when the configuration is downloaded, based on the value of the parameter minSCTPPortAlso the RNC allocates the local SCTP ports in a predefined manner (same as Node B) when the IP based routes are configured, based on the value of the parameter minSCTPPort (one parameter per Node B)The first port allocated for each Node B is for C-NBAP and the rest for D-NBAP:

MinSCTPPort => C-NBAP MinSCTPPort + 1 => D-NBAP (WAM0) (also D-NBAP for Flexi) MinSCTPPort + 2 => D-NBAP (WAM1) MinSCTPPort + 3 => D-NBAP (WAM2) MinSCTPPort + 4 => D-NBAP (WAM3) MinSCTPPort + 5 => D-NBAP (WAM4) MinSCTPPort + 6 => D-NBAP (WAM5)


SCTP port allocationGeneral (II)

SCTP ports used by the RNC and the Node B for a given NBAP link must be the same

SCTP ports used by the RNC for any two Node B’s must be different

Approx 16000 SCTP ports can be used for one RNC

SCTP Port Allocation requires careful planning “SCTP Port List per RNC/BTS”


SCTP port pool (one per RNC)

SCTP port allocationNode B

In this example, 2 ports are allocated for Flexi and 7 for each Ultra.

Network Element minSCTPPort SCTP port range

BTS1 (Flexi) 49152 49152-49153 (CNBAP: 49152)

BTS2 (Ultra) 49154 49154-49160 (CNBAP: 49154)

BTS3 (Ultra) 49161 49161-49167 (CNBAP: 49161)

minSCTPPort

(BTS1)

minSCTPPort

(BTS2)

minSCTPPort

(BTS3)

49152 65535


Iub Planning


• Scheduling



• IP addressing


• Routing

• QoS



IP Addressing PrinciplescRNC

• The user plane connections are terminated in the interface units– The external user plane address of the RNC uses a dedicated /29

subnet in case HSRP is used– A /30 subnet does not provide enough IP addresses, because both

routers need an address in this subnet and the HSRP virtual IP takes another one

– These addresses are also the gateways for the control plane

• Control plane connections are terminated in the ICSU units– /26 control plane subnet

• Another RNC internal subnet contains the DCN addresses. A /28 subnet is used for OMU address.

• At the site routers, a separate /29 subnet is configured for the ToP master clock


Virtual IP address 1.1.1.1

IP Addressing Principles for Iub UP and CPExample L3 Iub


IP Addressing Principles for Iub UP and CPExample L2 Iub with VLAN differentiation


IP Addressing PrinciplesmcRNC

• Each EIPU is connected to both site routers– /30 subnet is required in the mcRNC interface and in the router

interfaces (no HSRP used)– HSRP is used to provide a single (virtual) IP address for the ToP

master and the standalone OMS For them /29 is used due to HSRP.

• IP addresses for Iub user plane and control plane applications terminations (configured to recovery groups RGs)– Iub user plane termination requires one address per each EIPU– Iub control plane termination requires one address per each EIPU

One /26 subnet used for Iub control plane terminations (/26 was used to be aligned with cRNC to simplify migrations)

RNC will automatically allocate one of these when a new Node B is integrated to RNC


IP Addressing Principles for Iub UP and CPExample with two mcRNC Modules

Interface addressesUser plane

Terminations

IPa-IPd

Control plane

Terminations

IP1-IP4


IP Addressing Principles for O&MExample with two mcRNC Modules

• 2N protected OMUs (one working (WO), one standby (SP) process)– Both using the same IP addresses, one for Iub O&M, another one for DCN O&M towards

NetAct)

– 1 Element Management Port (LAN1, also known as eth0 in the management interface) in first two BCN, providing external DCN network connectivity for OMU

– 1 External IP interface address for forwarding traffic towards OMU for the first two BCN

– 2 DCN routers, connecting mcRNC site with DCN


IP addresses in BTS

• Application IP addresses are user for User, Control, Management and Synchronization plane termination– This IP address is either a Network Interface IP address or a Virtual IP address

– Also the IP addresses for site support equipment are considered as application IP addresses

• Network Interface IP address are assigned to a physical or logical NE external network interface (e.g. Ethernet, VLAN, or IP-over-ATM interface)

• Virtual IP addresses is an IP address which is not bound to a physical or logical NE external network interface


IP addresses in BTS

Ethernet Interface

Transport Subnet

O&M Subnet

MP @ Ethernet Interface

Exit. Site Support Equipment

IP Transport Network

BTS

Network Interface IP@

Virtual IP@

CP @

UP @

SP @

Ethernet Interface

Transport Subnet

Network Interface IP@

Application addresses

Interface addresses


Example: IP addresses in BTS

• The user and control plane share the IP address 1.1.0.5/28, which is also a transport IP address from the subnet used on VLAN 37

• The management application uses the IP address 2.1.0.1/28, a local craft terminal connected to the management port uses the IP address 2.1.0.9/28. – These applications can be reached

via the transport IP addresses 1.1.1.5/28 and 1.1.2.5/28

• One of the corresponding VLANs might be used for the actual management traffic, the other one of the VLANs might be used for management of a microwave radios.


IP Addressing Example

To be done


Iub Planning


• Scheduling



• IP addressing


• Routing

• QoS



Interface Protection in the cRNC

• Protection in the cRNC is done using NPGE 1+1 unit protection– Link failure detection:

Ingress direction: due to loss of signal or loss of carrier detection. Egress direction: decoding the Link Status Bit set by the peer node.

– In case of link failure of at least one direction the RNC will perform an automatic switch-over to the redundant NPGE.

– RNC will detect equipment failure in case of HW/SW failures on the NPGE

– From RU20 on Top onwards it is possible to set the NPGEP switchover as "revertive" or "not-revertive" according to customer needs.

• Load sharing configuration can be also considered as “protection” against interface or link failure– Note that ongoing connections will be lost


Gateway Protection for cRNC

• Site router is duplicated for high-availability connection to the core and to the BTSs

• Each NPGEP is connected via two GbE link to one router in the site

• The active NPGEP unit must be connected to a different router than the backup unit.

• Fast IP Reroute to protect beyond site router


BCN-1

BCN-2

EIPU-0

EIPU-2

EIPU-1

EIPU-3

QNUP-1

QNUP-2

QNIUB-1

QNIUB-2

QNUP-3

QNUP-4

QNIUB-3

QNIUB-4

QNUP-3

QNUP-4

QNIUB-3

QNIUB-4

QNUP-X Active RU

QNUP-X Standby RU

Recovery Group

Redundant EIPU pair

EIPU-0 and EIPU-1

Redundant EIPU pair

EIPU-2 and EIPU-3

QNUP-1

QNUP-2

QNIUB-1

QNIUB-2

IF

RedundancyIub connections

• IP addresses are assigned to RG and are is available only in the active RU

• QNUP can terminate both Iub and Iu user planes

• QNIUB terminates the Iub control plane connection

• One IP address per EIPU for Iub UP and CP needed– /26 reserved for CP

to support migrations from cRNC

IF

IF

IF

IF

IF

IF

IF

QNUP-1


Redundancy EIPU pairs

• In case there are more than two BCNs, they create EIPU pairs like shown in the figure

• Capacity steps for the mcRNC are in pairs of two BCNs– 2, 4, 6 and 8 BCNs

BCN-4

EIPU-5

EIPU-7

BCN-3

EIPU-4

EIPU-6

BCN-2

EIPU-1

EIPU-3

BCN-1

EIPU-0

EIPU-2

Redundant EIPU pair

EIPU-7 and EIPU-6


mcRNC Protection Principles

• Several means shall be implemented to protect the network access

• The following failure cases are covered:– Failure of certain SW or HW functionality in mcRNC (can be a single

SW process, but also a complete BCN),

– Failure of an Ethernet link

– Failure of an mcRNC site router

– Failures in the transport network

– Packet forwarding failures between mcRNC and the transport network (transport link between mcRNC and network physically operational, but still (e.g. due to router malfunction) packets are not forwarded -> traffic blackholing)


Protection against EIPU Failure


Protection against Application Failure


Protection against Link Failure


Protection against Router Failure


Bidirectional Forwarding Detection (BFD)

• BFD can be used in Iub for 1. Monitoring IP connection availability and raising an alarm when the

connection is lost

2. HSPA transport fallback in Dual Iub

3. Enabling protection switching between static routes (feature Fast IP Reroute RU30 on top)

4. Checking route availability for OSPF (RU30 on top)

• Multi-hop or single hop– Typically Multi-hop BFD is used

– Single-hop mode Cisco does not support Multi-hop BFD Multi-hop BFD is not suitable for routing decisions, as it could happen that

packets reach the destination via some detour, e.g. further L3 hops By using single hop you can ensure that packet was delivered via single L2

segment.


BFD Parameters

• Detection time depends on the BFD configuration of both peers:Detection time =

DetectMult (received from the peer) x MAX[RequiredMinRxInterval, DesiredMinTXInterval (received from the peer)] = 5 x 500 ms = 2,5 s (with default values)

• RNC and NodeB parameters (in UltraBTS with IFUH: maximum value of BFD timeout is 30 seconds):– BfdSourceIPAddress, BfdDestIPAddress

– BfdDetectMult: [2..10], step 1, default 5

– BfdDesiredMinTxInterval: [500, 5000], step 500, default 500

– BfdRequiredMinRxInterval: [500, 5000], step 500, default 500


Iub Planning


• Scheduling



• IP addressing


• Routing

• QoS



Routing in Iub

• Static routing– Destination and source based routing

– Fast IP Reroute will enable protection switching for static route

• Dynamic routing– OSPF with Hello (Dynamic routing with OSPF)

– OSPF with BFD (OSPF Enhancements)

• The different alternatives were introduced in the RU30 features Module 3.


Static Routing in mcRNC

• Static routes in RNC are configured following these basic guidelines:– Egress traffic from certain EIPU shall– Primarily use one network interface of the same EIPU, and– Use the other network interface of the same EIPU for backup.– Ingress traffic received by some EIPU shall always be forwarded to the target

as long as it is a valid IP address which is configured to some EIPU or OMU– Egress traffic from OMU shall always be forwarded via both EIPUs in same

module by using ECMP configuration. For routing in EIPU itself rules as stated above apply.

• Static routes in site switches are configured following these basic guidelines:– Packets towards certain application IP address in RNC shall be sent primarily

via a suitable network interface of the same EIPU, or– Via a suitable network interface of the EIPU hosting the protecting instance of

the application as a backup

• Iub O&M traffic is terminated in only one of the two IP addresses in OMU. The other IP address in OMU is only used for communication with NetAct/EM.


Basic Routing Configuration


Router Configuration in RNC Site

• There is guideline for the RNC site route configuration for cRNC– https://

sharenet-ims.inside.nokiasiemensnetworks.com/Overview/D413530165

• Configuration of the routers for mcRNC to be added


Iub Planning


• Scheduling



• IP addressing


• Routing

• QoS



Thanks to the QoS and congestion control features of the BTS transport cards, overbooking can be applied to BTS level, aggregating the traffic from the cells

1. All Average2. All Average / Single Peak3. Single Peak plus All-but-one-Average4. All Peak

BTS level Overbooking

„All-Average“

The backhaul connection supports the aggregated

average capacity o all cells. The average

capacity is determined by subscriber statistics per

cell.

Non guaranteed capacity

Guaranteed capacitySignalling

Iub Interface

Ce

llpe

ak

Cell average

All-Average/

Single-PeakAll-Peak

eN

Btr

an

sp

ort

All-AverageSingle-Peak/

All-but-oneAverage

Ce

llpe

ak

Ce

llpe

ak

Cell average

All-Average/

Single-Peak

All-Average/

Single-PeakAll-Peak

eN

Btr

an

sp

ort

All-Average

eN

Btr

an

sp

ort

All-AverageSingle-Peak/

All-but-oneAverage

„All-Average/Single-Peak“

The backhaul supports the max capacity

between the aggregated average capacity of all

cells, or the peak capacity of one cell.

Cell peak traffic is preserved.

„Single Peak/All but one average“

The backhaul connection supports the cell peak plus all

but one average. This approach can be

used for mild overbooking

strategies

„All-Peak“

The backhaul connection

supports the aggregated peak

capacity of all cells (“non-blocking”). This approach will generally lead to

over-dimensioning and extra costs.


In real-life networks, high traffic in BTSs is only for 2-3 hours per day and it is distributed unevenly in time across the network. If we consider a certain geographical area the traffic is quite evenly spread out in most of the day and it is much lower than the sum of peak rate of the considered BTSs.

Network level Overbooking

3G IP Iub

3G IP Iub

RNC

Low overbooking due to similar

peak hour time of BTSs area

High overbooking due to variable peak hour

time of considered BTSs area

Office area high traffic between 10am-14pm

Residential area: High traffic between 17pm and 21pm


Total overbooking factor should be evaluated as a compromise between BTS level overbooking and Network level overbooking.

1. Higher overbooking at BTS level generally brings to lower TCO but also deeper congestion situations (due to the relatively small number of subscriber affected)

2. Higher overbooking at Network level generally brings to higher TCO but less severe congestion situations (due to less correlated traffic)

Overbooking – BTS and Network level compromise

3G IP Iub

3G IP Iub

RNC

BTS level overbooking,

Aggregated traffic from subscribers

under one BTS area

Network level overbooking, traffic

aggregated from several BTSs distributed in

geographical area


QoS and Overbooking of data traffic

Best Effort traffic

Best effort

QoS profile 2

QoS profile 1

QoS profile 3

QoS profile 0

QoS profile 4

QoS profile 5

QoS differentiation

time

Different applications/subscribers are treated differently and monitored separately

In case of congestion packets are randomly discarded. This is limiting the overbooking factor that can be applied.

Congestion has equally impacts on all users and all data services.

In case of congestion packets are discarded on priority base,

Higher overbooking factors can be applied.



BTS 1 guaranteed capacity

BTS 1 Signalling & O & M






BTS 1 Signalling & O &M


BTS guaranteed capacity

BTS 2 Signalling & O&M



BTS 3 Signalling & O&M


CAC

No CAC

Ethernet interface rate

Traffic where overbooking

applies

3

45

6

Congestion control and QoS

enforcement

Packet Network

RNC

Guaranteed traffic – not affected by overbooking


Traffic overbooking ExamplesIn real life networks overbooking rate is mainly driven by the amount of investment that each operator is willing to sustain. For this reason the overbooking factors are extremely variable from network to network.

NSN is ready to provide customized support in network planning (and overbooking calculation) based on our wide experience in MBH network deployment.

Overbooking

Subscriber

traffic model

Geographical

Distribution

Network TCO

and existing

infrastructure

Factors ranging from 20% to 80% are common experience as operator requirements.


RAN QoS Parameters

Guaranteed bitrate

Transfer delay

THP

Traffic Class

ARP

Maximum bitrate

Delivery order

Maximum SDU size

Delivery of Erraneous SDUs

SDU Error ratio

Residual BER

RAB QoS profile

Guaranteed bitrate

Transfer delay

THP

Traffic Class

ARP

Maximum bitrate

Delivery order

Maximum SDU size

Delivery of Erraneous SDUs

SDU Error ratio

Residual BER

RAB QoS profile

Guaranteed bitrate

Nominal bit rate

Priority

Transfer delay

Maximum bitrate

BLER target (RLC layer)

RNC/RB QoS attribute

Guaranteed bitrate

Nominal bit rate

Priority

Transfer delay

Maximum bitrate

BLER target (RLC layer)

RNC/RB QoS attribute WRAB parameters

RT PS only

Discard time

Guaranteed bitrate

Service priority indication

HSPA QoS attributes in BTS

Discard time

Guaranteed bitrate

Service priority indication

HSPA QoS attributes in BTS

RT PS only

Mapping

WCELparameters

• RNC translates Core network QoS parameters to SPI values and transport connections

• ATM: VC’s, AAL2 Queues

• IP: DSCP’s, PHB’s, p-bits

Core Network RNC BTS


RAN QoS Features

• In the air-interface– HSPA QoS Aware HSPA Scheduling (RAN1262)

Maintains user HSPA throughput based on users QoS class weight

– Streaming QoS for HSPA (RAN1004)

• In the transport network– HSDPA/HSUPA Congestion Control (RAN1110)

Maintains in case of transport congestion HSPA throughput based on users QoS class weight

if all HSPA connections using Congestion Control are mapped to same transport connection (VCC, AAL2 queue, PHB, DSCP, p-bit)

– Iub Transport QoS (RAN1253) Allows mapping of radio QoS classes to separate transport connections

• ATM: AAL2 Queues in FlexiBTS and RNC NPS1• IP: PHB’s in BTS / RNC and external transport network connections via DSCP’s and p-bits

Maintains in case of transport congestion total QoS class throughput based on QoS class weights at transport layer in BTS, RNC and transport network equipment

Required if congestion in the transport


Iub Transport QoS - Iub traffic Scheduling

Q1

Q2

Q3

Q4

EF

AF4

AF3

AF2

W1

W2

W3

SP

WFQ

Q5

Q6

W4

AF1

BE

W5

IP Based route

shaping

•Available capacity is divided between queues based on queue weights

•User throughputs depend on number of users per queue

esActiveQueu

tQueueWeightQueueWeighapacityAvailableCgeRateQueueAvera /

•WFQ rule:

Normally for CAC controlled traffic


Iub Transport QoSTQM Parameter Structure

TQM QosPriToDSCPDefault Value

TQM CSTrafficToDSCP 46 (EF)

TQM PchFachRachToDSCP 46 (EF)

TQM SRBToDSCP 46 (EF)

TQMDCHQoSPri15ToDSCP to DCHQoSPri0ToDSCP 34 (AF41)

TQMHSPAQoSPri15ToDSCP to HSPAQoSPri0ToDSCP 0 (BE)

TQM AfHSDPAQoSPri5Default Value Range

TQMAfHSDPAQoSPri0 to AfHSDPAQoSPri15 1 0..1

TQMAfHSUPAQoSPri0 to AfHSUPAQoSPri15 1 0..1

• The TQM object is defined to the WBTS by giving the TQM object ID in the WBTS object.

• Value 0: TQM not used

• When used TQM settings will be used instead of WBTS object DSCPs

• There can be 4 different TQM objects defined in one RNC


Iub Transport QoS Queue weights in the Default PHB Profile in the RNC

Default Profile ID = 0

PHB name Queue schedule

Queue length

Queue weight

Queue priority

Min Thd (%) Max Thd (%)

Max Drop (%)

Exp. Weight

VLAN priority

BE WFQ 500 1 NRT 75 100 10 0 0

AF1 WFQ 300 4 NRT 75 100 10 0 1

AF2 WFQ 300 10 NRT 75 100 10 0 3

AF3 WFQ 300 25 NRT 75 100 10 0 4

AF4 WFQ 100 60 RT 100 100 0 0 5

EF SP 100 N/A RT 100 100 0 0 6

Need to be adjusted per network

The p-bit 6 is sometimes used for

control


FTM QoS Parameters (FlexiBTS Manager)

In the Flexi NTS also same weights as in RNC can be used


HSDPA Congestion Control

• The congestion control can be adjusted per SPI with BTSSC/qosSchedulingList/ccPolicy parameter– 0: Control All Data

Intended for BG and IA traffic classes. In case of Iub overload, congestion control is allowed to reduce the bit rate on

Iub frame protocol level down to 0 credits, if needed.

– 1: Control Data over GBR Intended for Streaming and Conversational RT traffic classes to protect the

Guaranteed Bit Rate (GBR). In case of Iub overload, congestion control is allowed to reduce the bit rate on

Iub frame protocol level only down to bit rate defined by GBR, if needed.

– 2: OFF Congestion Control is off for this SPI class.


HSDPA Congestion Control

RNC BTS

CRC, FSN, DRT

HS-DSCH Credits,

Congestion Status Congestion

Control

HS-DSCH FP

DRT

FSN

CRC

Flow

Control

5. Frame Loss congestion and Iub Delay congestion are evaluated.

If congestion is detected, credit amount is limited.

3. CRC result of FP headerand payload, Frame sequence number

and delay reference timeare provided to CC for congestion

detection.

4. Flow control calculates the credits taking account the data

amount in user buffer, the throughput of the user and the

possible guaranteed bit rate requirement.

Proposed

HS-DSCH credits

1. RNC inserts the input fields to HS-DSCH Data Frames of the MAC-d flow.

2. FP frame is received from the RNC.

6. New credit allocation is sent to the RNC in HS-DSCH Capacity Allocation Frame. Defined ccPolicy and user

priority is taken into account in credit limitation


SPI Mapping Details

When RNC receives the RANAP_ASSIGNMENT_REQUEST it will look up the corresponding SPI from the configured parameters based on

• Traffic class

• Allocation Retention Priority (ARP:1..3)

• Traffic Handling Priority in case of Interactive traffic class (THP:1..3)

RNC Parameter QoSPriorityMapping (Structure) contains the SPI Mapping parameters beside

Parameter Name Range Default

PriForStreamARP1 0…15 13



PriForIntSignaling 0…12 12

PriForIntTHP1ARP1 0…11 11









PriForBackARP1 0…11 0



Used in QoS aware HSPA scheduling

and HSDPA Congestion Control


QoS in BTS HSDPA scheduler

• Scheduling weight and the HSDPA CC Policy are defined in the same parameter structure - per SPI

• BTSSC Parameter qosSchedulingList (16 instances)

– ccPolicy – enables, limits disables HSDPA congestion control

– weight – scheduling weight

– id – the SPI to which the two above apply


HSDPA CC Threshold Commissioning Parameters

• The default values for UltraSite were different (50, 250, 1000) with SW release used in first pilot.

• Fix in WN5.0 CD3 BTS Site Manager

• In general the default values are a bit high for most networks


Experiences from HSDPA Congestion ControlNumber of Schedulers

• In case there are multi-scheduler configurations in the BTS (RU20EP1)– BTS scheduler is not able to priorities between users connected to different

schedulers according to SPI and SPI weight

• This would be solved in RU30 when there will one hsTUP SW block and in the BTS and all HSDPA traffic would flow through it

• BUT in case there are multiple system modules that have HSDPA enabled, priorities cannot be ensured if the users are connected to different system modules– It is possible to map part of the cells to extension system module in RU30 so

there can be up to two hsTUP entities with Flexi R2

– You can still have two schedulers with 504 Mbps under one system module, however hsTUP max HSDPA throughput limitation in RU30 is 168Mbps

Max. number of HSDPA schedulers per System Module Rel’2 / EUBB subrack

Max. number of HSDPA Active Users per System Module Rel’2 / EUBB subrack

Max. number of HSDPA cells per System Module Rel’2 / EUBB subrack

Max. HSDPA peak throughput per System Module Rel’2 / EUBB subrack

480 12 504 Mbps (2 HSDPA schedulers activated) (2 HSDPA schedulers activated) (2 HSDPA schedulers activated)2


Experiences from HSDPA Congestion ControlBTS Hardware

• Flexi R2 (ultra with EUBB as well)– RU20EP1 algorithm works well– Algorithm is able to detect delay and frame loss– Reduces credits linearly from 0% to 20% between min threshold and

max threshold– Max credit reduction 20%

• Ultra BTS (without EUBB) and Flexi R1– Different algorithm compared to Flexi R2– Problems detecting static delay– No plans to change the algorithm/behavior of the HSDPA CC in these– User differentiation works when there is delay build-up or frame loss

detected Frame loss causes 40% credit reduction


Iub Planning


• Scheduling



• IP addressing


• Routing

• QoS



mcRNC site solutionIP Iub with L2 access

EVCs in the backhaul network are identified by VLANs, which are defined in Cisco site routers and NodeBs. Selection of the appropriate VLAN ID in the routers is based on destination (Node B) IP address.

Cisco routers operate as Layer 3 devices Protection of the two RNC side UNIs needs to be provided by appropriate mechanisms, e.g. by applying HSRP and interface state tracking (in the uplink direction only).


mcRNC site solutionmcRNC site solution with IP Iub with L3 access

Mobile traffic is configured to a dedicated VPN based on VLAN IDs in RNC site routers and PE routers. This enables sharing of the network with other services, such as enterprise or residential services.


Comparison of Site Solutions

RAN1884 RAN1711RNC HW RN 4.0 mcRNC Rel-1.0

Site router HW 2x Cisco 7609-S, IOS 12.2 (33) SRC2

L1 connectivity RNC 16x 1GE (electrical/optical) 10x 1GE (electrical/optical)

L1 connectivity ToP master

2x 1GE (to site router) 2x 1GE (to the site router)

Link level redundancy Based on NPGEP protection Based on Link Aggregation

L2 connectivity RNCL2 domain spanning WO/SP NPGE unit and both site routers

L2 domains only between mcRNC ports and directly connected site router

L2 connectivity site routers

VLAN trunk between site routers L3 connectivity between site routers

L2 spanning treeRequired for RNC ESA24 units and connected site router ports.

not required

L3 redundancy RNCBased on NPGEP protection or OSPF (RAN1510)

Based on redundant static routes or OSPF

L3 redundancy site routers

Based on HSRPBased on redundant static routes or dynamic routing

O&M connectivity to DCNUsing RNC ESA24 switches (based on L2)

Using special Eth ports of mcRNC (based on L3)

QoS DiffServ marking

IPsec solution Security GW integrated to site routers

OMS RNC integrated OMS (until RN5.0) Standalone OMS mandatory


Summary

• Iub planning is dependent on the used transport technology and there are plenty of choices– NG-SDH

– MetroEthernet

– MWR

– DSL…

• They have an affect on the – Capacities

– Traffic separation

– IP addressing

– Protection

– QoS settings

• RAN sharing is coming to the picture having affect as well


References

• RU30 Iub planning guideline– https://sharenet-ims.inside.nokiasiemensnetworks.com/Overview/D426547170

• Mobile Access multiradio planning training – https://sharenet-ims.inside.nokiasiemensnetworks.com/Overview/D426240861

• Impact of transport impairments on WCDMA network performance

• Multiradio shared transport QoS Solution Study

• RNC - FlexiPacket QoS parameter aligment case study – https://sharenet-ims.inside.nokiasiemensnetworks.com/Overview/D425138371

• IP Functional Area Description– https://online.portal.nokiasiemensnetworks.com/pic/nedproxy

/NED?library=a25003a0000b5240276p1&action=retrieve&identifier=dn19660707&edition=1&language=en&coverage=global&encoding=oem_pdf_a4&idmapencoding=ned_pdf_toc_1_0&source=xdoc&component=data&item=pdf/wran_fad_ipt.pdf

Multiradio shared transport QoS

Impact of network impairments

module 5 - iub plannig

Documents