03 - RN30033EN40GLA0 - CRNC - Iub Planning PDF

3GTPL cRNC Iub Planning
RN30033EN40GLA0 ©2014 Nokia Solutions and Networks. All rights reserved.

Nokia Solutions and Networks Academy
Legal notice
Intellectual Property Rights

All copyrights and intellectual property rights for Nokia Solutions and Networks
training documentation, product documentation and slide presentation material, all of
which are forthwith known as Nokia Solutions and Networks training material, are the
exclusive property of Nokia Solutions and Networks. Nokia Solutions and Networks
owns the rights to copying, modification, translation, adaptation or derivatives
including any improvements or developments. Nokia Solutions and Networks has the
sole right to copy, distribute, amend, modify, develop, license, sublicense, sell,
transfer and assign the Nokia Solutions and Networks training material. Individuals
can use the Nokia Solutions and Networks training material for their own personal
self-development only, those same individuals cannot subsequently pass on that
same Intellectual Property to others without the prior written agreement of Nokia
Solutions and Networks. The Nokia Solutions and Networks training material cannot
be used outside of an agreed Nokia Solutions and Networks training session for
development of groups without the prior written agreement of Nokia Solutions and
Networks.
2 RN30033EN40GLA0 ©2014 Nokia Solutions and Networks. All rights reserved.

Objectives
After this module, the student will be able to understand:
• Explain the Ethernet interface scheduling and parameters

• Understand the meaning of IP based route and Iub load sharing
concepts for Iub user plane
• Go through different configurations for VLAN differentiation
• Identify the parameters used for Iub control plane planning
• Explain IP addressing and routing alternatives for BTS
• Explore resiliency and protection alternatives
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 and VLAN planning
• Protection and resiliency
• Routing
• IPSec
• RSTP

Ethernet interface in the cRNC - NPGE
• RNC2600 can be equipped with up Area [unit] NPGE Comment

limit
to 16 NP2GE units, 16 NPGE or
8+8 NPGEP), creating a total of 28 Throughput [bps] 2x Backplane
1Gb connection in
Gbit Ethernet ports configurable for ps RNC limits total
use with Iu-CS, Iu-PS, Iub, and Iur. throughput to
1.65Gbps
• With respect to the (protected) IP packets [1/s] 2.6Mpps
NPGEP configuration a fixed
UDP ports [number] 64509 Per IP address
assignment of working (WO) and
Number of static 3000
spare (SP) units exists: routes
Number of VLANs 600
Number of IP based 1024

routes
Working unit 0 2 4 6 8
… Number of BFD 600
Spare (protecting) unit 1 3 5 7 9 sessions

Ethernet Interface Parameters in NPGE
• All ports that are connected towards RNC must be configured

to auto-negotiation mode in external switch
– 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
NPGE(P) CS BHCA NPGE(P) PS BHCA
Iu-CS/Iu-PS 1280000 850590

Iub 626370 512160
Iub/Iu-CS/Iu-PS 583960 386950

Iub Planning

• Scheduling
• Routing
• IPSec
• RSTP

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

Iub Planning

• Scheduling
• Routing
• IPSec
• RSTP

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
Destination
Source
BTS
Signalling (no IPBR)

RNC
User plane: RNC
IP based route
Route BW
MGW
IP based committed BW
Incl. sig and dcn
SGSN

IP based Route for Iub - IFC = OFF & CAC in use
Interface BW
Non-CAC traffic
IP based route BW
Reservation – committed DCN BW
– committed sig BW
CAC controlled Traffic
• 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)

IP based Route for Iub - IFC = ON & CAC in use
Interface BW
Non-CAC traffic
IP based route BW
Reservation – committed DCN BW
– committed sig BW
CAC controlled Traffic
• 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
Basic IP based route parameters in cRNC for Iub
IP Route BW Committed Committed Committed DCN IFC

(kbps) BW (kbps) Signaling BW BW (kbps)
(kbps)
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.

Optional IP based Route Parameters
Efficient Transport for Small Packets
• New parameters to IP based route related to Efficient transport for small

packets (there are more parameters needed in the BTS side and PRFILE)
Optional IP Based Route Parameters Data format Value Range Units Default Example
Value
UdpMuxEnabled NUMERIC 0 (Disable), 1 0 optional
(Enable)
LocalMuxUDPPort NUMERIC 49152..65535, step 65535 optional
1
MaxMuxPackets NUMERIC 5..30, step 1 30 optional
UdpMuxDSCP NUMERIC 0..63, step 1 46 optional
RemoteMuxUDPPort NUMERIC 49152..65535, step 65535 optional

1
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 Setting in the BTS
• The IP based route parameters in the BTS

▪ These parameters are used for UL CAC, when Traffic shaping type is OFF
or WFQ (see next slide)
• UL CAC is able to use following capacity for user connections
▪ CAC committed bit rate – signaling bit rate – DCN bit rate

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
– See more examples in Configuring IP connection to IPA RNC

Scheduling 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
Enable QoS check
box enables the
use of multiple
queues for
scheduling
2 3

Scheduling in BTS, cont.
The VLAN scheduling for User Plane is performed using six queues. Each of
the three VLANs for control, management, and synchronization planes have
one optional dedicated queue.
The traffic is shaped per VLAN, based on the Shaper Information Rate (SIR)
and Shaper Burst Size (SBS) parameters when the Traffic shaping type in the
BTS site manager has been selected as Path.
The BTS can also shape the traffic per IP Interface at the WFQ aggregator
level to a value defined by the Total shaper information rate when the Traffic
shaping type in the BTS has been selected as WFQ.
Shaping may also be switched off entirely (Off) and in this case there is
shaping only the interface rate level, e.g. 100 Mbps for the FE interface.

VLAN CAC in BTS
• Per VLAN CAC in BTS

– Performed against CIR of the VLAN
– On IP level / no Ethernet overhead considered
– IP Bit rate of connection = MAX_Bitrate x 0.2+ AVE_Bitrate x 0.8
– Traffic descriptors signalled from RNC
– DCN and SIG committed bitrate relevant if included in VLAN
• Static CAC for VLANs

– Configuration time checks like ATM CAC
– SUM(Logical_Ethernet(CIR)) ≤ shapedBandwidth, when Traffic
Shaping = Off of Path
– SUM(Logical_Ethernet(CIR)) ≤ sirTotal When Traffic Shaping = WFQ

VLAN Differentiation Settings in BTS
If both VLAN(s) and
Ethernet interface is
• Parameter considerations configured (IP address
not empty), then the
Transport Ethernet
interface does not
represent the overall
Ethernet interface, but
interface that
transmits/receives only
untagged frames.
It was found out in

RU20EP1 tests that
VLAN carrying
HSPA, the CIR
cannot be defined =
0, but for example
0.1 Mbps

Summary on CAC, Scheduling and Shaping
Parameters in BTS
Path Type CAC Scheduling Shaping

VLAN Interface VLAN Interface
CAC Committed Bit Rate - PHB-based 6-Q Round robin None Shaped
OFF (DCN Committed Bit Rate scheduler for Bandwidth based.
+ Signaling Committed Bit QOS-enabled IF
Rate)
CAC Committed Bit Rate - PHB-based 6-Q VLAN CIR None SIR Total based.
WFQ (DCN Committed Bit Rate scheduler for based WFQ
+ Signaling Committed Bit QOS-enabled IF
Rate)
VLAN CIR - (DCN PHB-based 6-Q VLAN CIR VLAN SIR based Shaped
Path Committed Bit Rate + scheduler for based WFQ Bandwidth based.
Signaling Committed Bit QOS-enabled IF
Rate)

Summary on CAC, Scheduling and Shaping
Parameters in BTS, cont.
If one or more VLAN interfaces are configured, and the “Transport

Ethernet interface” is also configured (IP address not empty), then the
Transport Ethernet interface does not represent the overall Ethernet
interface anymore, but the so-called “untagged VLAN”. This is yet another
VLAN interface that transmits/receives only untagged frames. And the CIR
parameter has the same meaning than for the tagged VLAN interfaces:
CAC is calculated against it and the weight of the WFQ scheduler that
aggregates the traffic of all VLAN interfaces is derived from it.

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.
• At the Iub interface NPGEP are needed since the Iub control plane does
not work with unprotected units
– NPGE protection ensured that calls and common control channels are
protected in case of NPGE unit failure
• 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)
Without 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 Protected
round robin to different interfaces NP2GE units
– 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- With RAN2338
homing BTSs to different NP2GE
– CAC functionality is moved from interface
unit NPGE to RSMU
– Traffic shaping per BTS cannot be done (no NP2GE unit
IFC) therefore there would need to be pool
enough bandwidth towards the BTS
• One IP based route shall support up to 64 IP
addresses on cRNC side interface units.

Centralised CAC
Iub Load Sharing with NPGEPs available from RU30
EP1 onwards for all
logical interfaces
always
NPGEP0 GE0
(WO) GE1 Sıte router
NPGEP1 GE0 Last miles without
Iub IP based route 1 GE1 bandwidth limitation
(SP)
(no IFC) WBTS 1
NPGEP2 GE0
(WO) GE1 Traffic-prioritization-
NPGEP3 GE0 capable device
(SP) GE1
Iub IP based route 2 Transport
(no IFC) Network
ESA24
WBTS 2
ESA24 DCN
Iub IP based route 3
(IFC) NPGEP4 GE0
GE1 Sıte router
(WO)
Bandwidth-limited WBTS 3
NPGEP5 GE0 last mile
(SP) GE1
RNC
• In Iub loadsharing configuration, CAC supported, IFC is not supported.

• In Iub loadsharing configuration, where last mile link is bandwidth-limited, in congestion
situation low priority traffic can cause high priority packet drops in the last mile. In this case,
protection of high priority traffic could be provided with a traffic-prioritization-capable device
connected to the last mile link.

Iub UP Planning Using cRNC Data Fill
IP Based Route

Iub UP Planning Using cRNC Data Fill
IP Based Routes Network

UDP port allocation
General
• 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 allocation
Node 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 minUDPPort
For 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
49152 65535
UDP port pool (for one BTS)
Estimated maximum UDP Port

(implicitly defined by the
minUDPPort number of expected calls)

UDP port allocation
RNC
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
1026 65535
UDP port pool (per IP address)
In the current implementation RNC will simply continue to use

minUDPPortIub 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
UDP port allocation in NPGE
• Overall port space is 2^16 = 65536 ports (as defined by RFC)
• Lower 1026 plus few reserved ones (e.g. BFD) apply
 Roughly 64000 UDP ports per IP address remain for user plane
• Port allocation algorithm in NPGE (until RU20)
– NPGE assigns next free even numbered port to requested new bearer
▪ Subsequent odd numbered port is reserved for associated connection
(RTCP use in Iu-CS case)
– Consequences with respect to logical interface
▪ Iu-PS: no limitation as only single port used anyway
▪ Iu-CS
• Max. 32k AMR bearers supported per IP address
(matching the limit for internal connections, see previous slide)
▪ Iub
• 4 UDP ports are typically used for common channels per cell
• Between 2..4 UDP ports are used depending on call type
• Also matching the internal connection limits,
but there is no different classes of UDP ports

UDP Port allocation per IP address
• Iu-PS
– Just a single port allocated for GTP-U (2152)
• Iu-CS
– For each AMR call, two UDP ports are allocated:
▪ Even port is used for RTP user plane connection
▪ Odd port is allocated/reserved for RTCP
• Iub
– 4 UDP ports are needed for each cell: PCH, FACH-C, FACH-U, RACH
– In addition, a different amount of UDP ports is needed per call type
Call type UDP port #1 UDP port #2 UDP port #3 UDP port #4 Ports
SRB DL/UL: AMR DL/UL:
AMR 2
Rel'99 DCH Rel'99 DCH
SRB DL/UL: PS DL/UL:
PS Rel'99 2
Rel'99 DCH Rel'99 DCH
PS UL:
SRB DL/UL: PS DL:
PS HSPA Rel'99 DCH UL 3
Rel'99 DCH HS-DSCH
E-DCH
SRB DL:
PS & SRB SRB UL: PS DL: PS UL:
Rel'99 DCH 4
HSPA E-DCH HS-DSCH E-DCH
HS-DSCH

RU30 Improvements
• Dedicated UDP port allocation algorithm for Iub

– Takes full use of the whole port range 1026..65535
– Enables use of up to ~64000 UDP ports per IP address for Iub
• Recommendations
– As each transport IP address has its own UDP port pool, the issue can
be resolved by using multiple IP addresses.
– As a rule of thumb, each Iub NPGE should use at least two IP
addresses for Iub user plane
– In special cases (high traffic load, many BTS etc) study of UDP ports
may be reasonable using M609 measurement

Iub Planning

• Scheduling
• Routing
• IPSec
• RSTP

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 in NOLS for more details
https://online.portal.nokiasiemensnetworks.com/pic/nedproxy/NED?library=a25003a0000b5240376p
1&action=retrieve&identifier=dn19660707&edition=1&language=en&coverage=global&encoding=oe
m_pdf_a4&idmapencoding=ned_toc_1_0&source=xdoc&component=data&item=pdf/wran_dim_acce
ss_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

Iub Control Plane in IPA-RNC
• Iub control plane in IPA-RNC is terminated in ICSU unit

– When creating the IPNB object, static route is done from the ICSU towards the
BTS using NPGE as a gateway
– NPGE is selected based on the IPBR id assigned, i.e. the same NPGE is used
for the control plane connection as is used for the user plane connection

SCTP port allocation
General (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
minSCTPPort
Also 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)
General (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

Node 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)
49152 65535
SCTP port pool (one per RNC)
minSCTPPort minSCTPPort minSCTPPort

(BTS1) (BTS2) (BTS3)

Iub Planning

• Scheduling
• Routing
• IPSec
• RSTP

IP Addressing Principles
cRNC
• 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

IP Addressing Principles for Iub UP and CP
Example L3 Iub
Virtual IP address 1.1.1.1

L2 transport network for Iub
• If the network is pure L2 and number of BTSs share the same

VLAN
– The number of hosts in the network should be limited
– There is no absolute number, but 50 hosts per VLAN should be
possible to avoid broadcast storms
• ToP master is not able to support more than 255 number of

VLANs (release 2.0)

IP Addressing Principles for Iub UP and CP
Example L2 Iub with VLAN differentiation

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
• Two non-overlapping subnets required

– transport address subnet of /29
– O&M subnet /29

IP addresses in BTS
Interface addresses BTS
O&M Subnet
Exit. Site
Support
MP @ Ethernet Equipment
Transport Subnet
Interface
Network
Ethernet Interface
Interface IP@
IP CP @
Transport
Network
Transport Subnet
UP @ Application addresses
Network
Ethernet Interface
Interface IP@
SP @
Virtual
IP@

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.

Iub Planning

• Scheduling
• Routing
• IPSec
• RSTP

Interface Protection in the cRNC
• Protection in the cRNC is done using NPGE 2N 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.

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

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

BFD Parameters, cont.
Detect Mult
Detection time multiplier. BFD Detect Mult parameter is defining the
number of packets that can be lost before the IP link is considered
down. The negotiated transmit interval, multiplied by this value, provides
the detection time for the transmitting system.
Desired Min TX Interval
This is the minimum interval, in microseconds, that the local system
would like to use when transmitting BFD Control packets (value zero is
reserved).
Required Min RX Interval
This is the minimum interval, in microseconds, between received BFD
Control packets that this system is capable of supporting. If this value is
zero, the transmitting system does not want the remote system to send
any periodic BFD Control packets.
Required Min Echo RX Interval
This is the minimum interval, in microseconds, between received BFD
Echo packets that this system is capable of supporting. If this value is
zero, the transmitting system does not support the receipt of BFD Echo
packets.

Iub Planning

• Scheduling
• Routing
• IPSec

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 routing alternatives are described in Module 2 IP

Features.

Iub Planning

• Scheduling
• Routing
• IPSec
• RSTP

Iub basic configuration scenario
RNC Site
 Only one interface (logical

or physical) is used on BTS Iub ToP
NodeB
Site router/SeGW IP @
 Single IP Tunnel between To
NodeB and SeGW P
 Multiple traffic flows are UP, CP U

P
IPSec IPSec Tunnel IPSec
UP
IP @ SA SA Subnet
supported within the tunnel
C IPSec Tunnel RNC
Single IPsec SA for each P
IPSec
SA
IPSec
SA
CP
Subnet
plane
IPSec
Traffic within the tunnel is SA IPSec
SA
MP
Subnet
terminated in multiple Interface Interface Tunnel Interface
subnets at both ends of the Site MP IP @ IP @ IP @ IP @ IP @
support
tunnel (site to site type of SS
E&
equipmen
configuration) t
MP CMP/LD
BTS subnet AP
ToP, CMP, and LDAP
traffic is configured to
bypass the IPsec tunnel
Subnet
O&M connections are
secured by TLS CMP/LD
Certificate
WCDMA BTS supports up to 10 AP
IKEv2 is used. IKEv1 is IKE SAs, and 20 inbound and 20 Authority
possible but not outbound IPsec SAs
recommended
NetAct site

Iub VLAN support scenario RNC Site
Multiple VLANs defined

between WCDMA BTS and Iub Site router/SeGW
the SeGW, each carrying a ToP
traffic type and/or a QoS ToP To VLAN IP @
class NodeB IP @ P
 Each VLAN has different

VLAN
IP addresses in the WCDMA UP HP IPSec IPSec IPSec
BTS and the SeGW IP @ 1 UP SA Tunnel SA
Interface IP @ Interface
RNC has separate Interface IP @ Interface
IP @
IP @ (UP
IP @ 1) RNC
subnets for each VLAN
VLAN
5 VLANs per WCDMA UP LP
UP
IPSec IPSec IPSec
IP @ 2 SA Tunnel SA
BTS: two VLANs for UP, one Interface IP @ Interface
Interface IP @ Interface IP @ (UP
per each: ToP, CP, MP IP @ IP @ 2)
Only IKEv2 is VLAN

CP C CP
recommended IP @ P
IPSec IPSec
Tunnel
IPSec
Subnet
SA SA
One-to-one mapping Interface IP @
Interface IP @ Interface Interface
IP @ IP @
between VLAN and IPsec
Site
tunnels support MP IP @ VLAN
SS MP
Traffic within the tunnel is equipment E&
MP
IPSec
SA
IPSec
Tunnel
IPSec
SA Subnet
terminated in multiple BTS subnet Interface IP @
Interface IP @ Tunnel IP Interface Interface
subnets at both ends of the @ IP @ IP @
tunnel (site to site type of

configuration)
Subnet
CMP and LDAP traffic is
configured to bypass the CMP/LD
NetAct
Certificate
IPsec tunnel AP
CMP/LD site
AP
Authority

Iub Planning

• Scheduling
• Routing
• IPSec
• RSTP

Design Impact
Root Bridge Selection
• It is strongly recommended to manually influence Root Bridge election procedure

• In ring topology the node aggregating the traffic should become Root Bridge
• Any other node failure will not trigger Root Bridge election procedure (thus decreasing convergence
time)
• In case Root Bridge is down, all the ring traffic is lost anyway
• Switch expected to be the Root has to be equipped with at least 3 ETH interfaces (for zero
footprint solutions base stations with FTLB, FTFB, FTIA, FTJA and FSMr3 with transport
units are fulfilling this requirement, otherwise external switch should be used)
• Bridge with lowest Bridge Priority is elected as Root Bridge
• Bridge Priority can be changed by configurable Bridge Identifier Priority field (controlled by
bridgeIdentifierPriority parameter)
• Following exemplary values can be used (for reference scenario presented below):
• FTIB units: default bridgeIdentifierPriority
parameter (8)
Root
• FTLB unit: decreased bridgeIdentifierPriority FTIB FTIB Bridge
parameter (4)
• Anytime new bridge is inserted into given RSTP
domain, it will be elected as bridge if its Packet
FTIB FTLB
priority is the highest (lowest numerical value). Network
FTIB FTIB

Design Impact
Selection of the link to be blocked by RSTP during stable conditions
Break up point selection criteria depend on operator’s preference
- Traffic load
Operator’s priority is to equally distribute the load during stable network conditions (this scenario is most
applicable in the cases, where limited capacity MWR links are deployed between BTS sites)
2 Root
Bridge
3 1
Traffic load per site: 10 Mbps
Packet
Network
Links 1, 2, 3, 4 capacity: 155 Mbps
4 6
Link
Links 5, 6 capacity: 34 Mbps
blocked
by RSTP
5
- Convergence time
Operator’s priority is the convergence time, so the RSTP blocking link is selected to achieve fastest
convergence time (this scenario is most applicable in the cases, where high capacity links, e.g. optical
fiber, are deployed between BTS sites). In this scenario link planned to be blocked by RSTP should be
equally distant from the Root Bridge on both sides of the ring.
2 Root
Bridge
Traffic load per site: 10 Mbps
3 1
Packet
Links 1, 2, 3, 4, 5, 6 capacity: 1000 Mbps
Network
6 Alternatively link 3 could be blocked

4 Link
blocked
by RSTP
5

Design Impact
Selection of the link to be blocked by RSTP during stable conditions
(continued)
• Link blocked by RSTP in stable conditions can be manually configured by purposely
“spoiling” relevant link cost (configurable by portPathCost parameter)
• It is sufficient to change the parameter in ETH port on one side of the link
• Default link costs according to RSTP standard are given in the table below
Data rate STP Cost (802.1D-1998) RSTP Cost (802.1W-2001)
4 Mbit/s 250 5,000,000
10 Mbit/s 100 2,000,000
16 Mbit/s 62 1,250,000
100 Mbit/s 19 200,000
1 Gbit/s 4 20,000
2 Gbit/s 3 10,000
10 Gbit/s 2 2,000
• Link cost configuration for the exemplary case presented below

• Links 1, 2, 3, 4, 6: default portPathCost 2 Root
parameter (20000) Bridge
• Link 5: increased portPathCost 3 1
parameter (100000) Packet

Network
• sum of 1, 2, 3, 4 link costs < sum of 5, 6 link costs 4 6
5
Link planned to be
blocked by RSTP in
stable conditions

Design Impact
Recommended cases to disable RSTP
• It is recommended to disable RSTP in some nodes or ports:

- No benefit is seen to enable RSTP on chain links, or where there is only single connection to the
aggregation network (since no physical loops can be created using these ports)
- If single link is available to the aggregation network this will additionally prevent from undesired
spanning tree topology recalculations or Root Bridge elections (when another RSTP node is added,
or there is attempt to destabilize the network by spoofing BPDU messages)
• Operator can manually disable RSTP per port using disableStpParticipation
parameter
• RSTP can be disabled per node using actRstp parameter
In these nodes
RSTP can be
disabled RSTP should
completely be disabled
on these ports
Packet
Network

Design Impact
RSTP and VLANs
• RSTP protocol is VLAN unaware (only physical ETH topology matters).

• If some VLANs are configured within a part of RSTP domain, they can be simply cut off
due to RSTP decision (either during stable network setup or due to RSTP topology change
after link/node failure). Now this link is
unblocked by Root
Root RSTP, but nodes
1 and 2 still Bridge
Link planned to be Bridge
blocked by RSTP cannot use it due
in stable conditions to missing VLAN
membership on
this side of the
ring Packet
Packet 2 Network
VLAN1 Network VLAN1
VLAN2 VLAN2 Link

1 failure
• To prevent this behavior all VLANs have to configured over all links in physical topology.
• This issue is not present when RAN1847 Basic Ethernet Switching feature is enabled in
FTM (RAN1847 is also VLAN unaware), however this is not a recommended solution due
to lack of scheduling capabilities in FTM (RAN1769 is recommended).
Root
Link planned to be Bridge
blocked by RSTP
in stable conditions
Packet
VLAN1 Network
VLAN2

Discussion points for Iub planning
• What kind of transport network solution could prevent using

load sharing for Iub?
– Is it possible to combine load sharing and non load sharing
configuration in the same RNC
– Main benefits for load sharing?
• What are the main drawbacks of L2 transport network for Iub?

03 - RN30033EN40GLA0 - CRNC - Iub Planning PDF

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

03 - RN30033EN40GLA0 - CRNC - Iub Planning PDF

Uploaded by

Copyright:

Available Formats

3GTPL cRNC Iub Planning

RN30033EN40GLA0 ©2014 Nokia Solutions and Networks. All rights reserved.

Intellectual Property Rights

2 RN30033EN40GLA0 ©2014 Nokia Solutions and Networks. All rights reserved.

After this module, the student will be able to understand:

• Explain the Ethernet interface scheduling and parameters

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

4 RN30033EN40GLA0 ©2014 Nokia Solutions and Networks. All rights reserved.

• Ethernet interface planning

5 RN30033EN40GLA0 ©2014 Nokia Solutions and Networks. All rights reserved.

• RNC2600 can be equipped with up Area [unit] NPGE Comment

Number of IP based 1024

6 RN30033EN40GLA0 ©2014 Nokia Solutions and Networks. All rights reserved.

• All ports that are connected towards RNC must be configured

7 RN30033EN40GLA0 ©2014 Nokia Solutions and Networks. All rights reserved.

• In addition there is a control plane limitation depending on the logical

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

Iu-CS/Iu-PS 1280000 850590

8 RN30033EN40GLA0 ©2014 Nokia Solutions and Networks. All rights reserved.

• Ethernet interface planning

9 RN30033EN40GLA0 ©2014 Nokia Solutions and Networks. All rights reserved.

• The logical scheduling architecture is composed of two levels:

Available only for Iub

10 RN30033EN40GLA0 ©2014 Nokia Solutions and Networks. All rights reserved.

• The rate limiting is done using Internal Flow Control (IFC)

By default the queues

11 RN30033EN40GLA0 ©2014 Nokia Solutions and Networks. All rights reserved.

• Ethernet interface planning

12 RN30033EN40GLA0 ©2014 Nokia Solutions and Networks. All rights reserved.

• IP based route is a proprietary concept of Nokia Siemens

13 RN30033EN40GLA0 ©2014 Nokia Solutions and Networks. All rights reserved.

Signalling (no IPBR)

14 RN30033EN40GLA0 ©2014 Nokia Solutions and Networks. All rights reserved.

CAC controlled Traffic

15 RN30033EN40GLA0 ©2014 Nokia Solutions and Networks. All rights reserved.

CAC controlled Traffic

• When IFC = ON and CAC is in use: CAC reservation is limited to IP based

IP Route BW Committed Committed Committed DCN IFC

CAC is enabled by setting these parameters.

IFC is enabled by setting it ON hence the IP Route BW value

17 RN30033EN40GLA0 ©2014 Nokia Solutions and Networks. All rights reserved.

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

UdpMuxDSCP NUMERIC 0..63, step 1 46 optional

RemoteMuxUDPPort NUMERIC 49152..65535, step 65535 optional

18 RN30033EN40GLA0 ©2014 Nokia Solutions and Networks. All rights reserved.

• The IP based route parameters in the BTS

19 RN30033EN40GLA0 ©2014 Nokia Solutions and Networks. All rights reserved.

• There are different options to configure VLAN differentiation

20 RN30033EN40GLA0 ©2014 Nokia Solutions and Networks. All rights reserved.

• Traffic shaping type is either

22 RN30033EN40GLA0 ©2014 Nokia Solutions and Networks. All rights reserved.

23 RN30033EN40GLA0 ©2014 Nokia Solutions and Networks. All rights reserved.

• Per VLAN CAC in BTS

• Static CAC for VLANs

24 RN30033EN40GLA0 ©2014 Nokia Solutions and Networks. All rights reserved.

It was found out in

25 RN30033EN40GLA0 ©2014 Nokia Solutions and Networks. All rights reserved.

Path Type CAC Scheduling Shaping

26 RN30033EN40GLA0 ©2014 Nokia Solutions and Networks. All rights reserved.

If one or more VLAN interfaces are configured, and the “Transport

27 RN30033EN40GLA0 ©2014 Nokia Solutions and Networks. All rights reserved.

28 RN30033EN40GLA0 ©2014 Nokia Solutions and Networks. All rights reserved.

29 RN30033EN40GLA0 ©2014 Nokia Solutions and Networks. All rights reserved.