module 5 - iub plannig
DESCRIPTION
NSN IuB PlanningTRANSCRIPT
For internal use onlyPresentation / Author / Date 1 © Nokia Siemens Networks
Module 5 – Iub planning
For internal use onlyPresentation / Author / Date 2 © Nokia Siemens Networks
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
For internal use onlyPresentation / Author / Date 3 © Nokia Siemens Networks
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
For internal use onlyPresentation / Author / Date 4 © Nokia Siemens Networks
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
For internal use onlyPresentation / Author / Date 5 © Nokia Siemens Networks
NPGE and NPS1 Units in RNC2600
• The max number of possible NPGEs is depending also on the number of needed NPS1 units
For internal use onlyPresentation / Author / Date 6 © Nokia Siemens Networks
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)
For internal use onlyPresentation / Author / Date 7 © Nokia Siemens Networks
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
For internal use onlyPresentation / Author / Date 8 © Nokia Siemens Networks
Ethernet Interface in the mcRNC - EIPU
6 x 1 or 10 Gbps 16 x 1 Gbps
For internal use onlyPresentation / Author / Date 9 © Nokia Siemens Networks
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
For internal use onlyPresentation / Author / Date 10 © Nokia Siemens Networks
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
For internal use onlyPresentation / Author / Date 11 © Nokia Siemens Networks
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
For internal use onlyPresentation / Author / Date 12 © Nokia Siemens Networks
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
For internal use onlyPresentation / Author / Date 13 © Nokia Siemens Networks
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
For internal use onlyPresentation / Author / Date 14 © Nokia Siemens Networks
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
For internal use onlyPresentation / Author / Date 15 © Nokia Siemens Networks
Iub Planning
• Ethernet interface planning
• Scheduling
• Iub user plane configuration
• Iub control plane configuration
• IP addressing
• Protection and resiliency
• Routing
• QoS
For internal use onlyPresentation / Author / Date 16 © Nokia Siemens Networks
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
For internal use onlyPresentation / Author / Date 17 © Nokia Siemens Networks
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
For internal use onlyPresentation / Author / Date 18 © Nokia Siemens Networks
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
IP based committed BW
– committed DCN BW
– committed sig BW
For internal use onlyPresentation / Author / Date 19 © Nokia Siemens Networks
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
IP based committed BW
– committed DCN BW
– committed sig BW
Reservation
For internal use onlyPresentation / Author / Date 20 © Nokia Siemens Networks
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.
For internal use onlyPresentation / Author / Date 21 © Nokia Siemens Networks
IP Based RouteDiscussion points
• When would you need to enable CAC for an IP based route?
For internal use onlyPresentation / Author / Date 22 © Nokia Siemens Networks
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.
For internal use onlyPresentation / Author / Date 23 © Nokia Siemens Networks
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.
For internal use onlyPresentation / Author / Date 24 © Nokia Siemens Networks
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.
For internal use onlyPresentation / Author / Date 25 © Nokia Siemens Networks
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.
For internal use onlyPresentation / Author / Date 26 © Nokia Siemens Networks
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.
For internal use onlyPresentation / Author / Date 27 © Nokia Siemens Networks
Iub Load Sharing in mcRNC
• IP based route for the Iub connection can be associated to several IP addresses on different EIPU units
For internal use onlyPresentation / Author / Date 28 © Nokia Siemens Networks
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
For internal use onlyPresentation / Author / Date 29 © Nokia Siemens Networks
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.
For internal use onlyPresentation / Author / Date 30 © Nokia Siemens Networks
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
For internal use onlyPresentation / Author / Date 31 © Nokia Siemens Networks
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
For internal use onlyPresentation / Author / Date 32 © Nokia Siemens Networks
Iub UP Planning Using RNC Data FillIP Based Route
For internal use onlyPresentation / Author / Date 33 © Nokia Siemens Networks
Iub UP Planning Using RNC Data FillIP Based Routes Network
For internal use onlyPresentation / Author / Date 34 © Nokia Siemens Networks
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
For internal use onlyPresentation / Author / Date 35 © Nokia Siemens Networks
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
For internal use onlyPresentation / Author / Date 36 © Nokia Siemens Networks
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
For internal use onlyPresentation / Author / Date 37 © Nokia Siemens Networks
Iub Planning
• Ethernet interface planning
• Scheduling
• Iub user plane configuration
• Iub control plane configuration
• IP addressing
• Protection and resiliency
• Routing
• QoS
For internal use onlyPresentation / Author / Date 38 © Nokia Siemens Networks
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
For internal use onlyPresentation / Author / Date 39 © Nokia Siemens Networks
Iub Control Plane Configuration
• Iub Control plane configuration requires– SCTP port configuration for CNBAP, DNBAP
Number of SCTP ports depends on the BTS type
For internal use onlyPresentation / Author / Date 40 © Nokia Siemens Networks
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)
For internal use onlyPresentation / Author / Date 41 © Nokia Siemens Networks
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”
For internal use onlyPresentation / Author / Date 42 © Nokia Siemens Networks
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
For internal use onlyPresentation / Author / Date 43 © Nokia Siemens Networks
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
For internal use onlyPresentation / Author / Date 44 © Nokia Siemens Networks
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
For internal use onlyPresentation / Author / Date 45 © Nokia Siemens Networks
Virtual IP address 1.1.1.1
IP Addressing Principles for Iub UP and CPExample L3 Iub
For internal use onlyPresentation / Author / Date 46 © Nokia Siemens Networks
IP Addressing Principles for Iub UP and CPExample L2 Iub with VLAN differentiation
For internal use onlyPresentation / Author / Date 47 © Nokia Siemens Networks
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
For internal use onlyPresentation / Author / Date 48 © Nokia Siemens Networks
IP Addressing Principles for Iub UP and CPExample with two mcRNC Modules
Interface addressesUser plane
Terminations
IPa-IPd
Control plane
Terminations
IP1-IP4
For internal use onlyPresentation / Author / Date 49 © Nokia Siemens Networks
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
For internal use onlyPresentation / Author / Date 50 © Nokia Siemens Networks
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
For internal use onlyPresentation / Author / Date 51 © Nokia Siemens Networks
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
For internal use onlyPresentation / Author / Date 52 © Nokia Siemens Networks
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.
For internal use onlyPresentation / Author / Date 53 © Nokia Siemens Networks
IP Addressing Example
To be done
For internal use onlyPresentation / Author / Date 54 © Nokia Siemens Networks
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
For internal use onlyPresentation / Author / Date 55 © Nokia Siemens Networks
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
For internal use onlyPresentation / Author / Date 56 © Nokia Siemens Networks
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
For internal use onlyPresentation / Author / Date 57 © Nokia Siemens Networks
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
For internal use onlyPresentation / Author / Date 58 © Nokia Siemens Networks
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
For internal use onlyPresentation / Author / Date 59 © Nokia Siemens Networks
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)
For internal use onlyPresentation / Author / Date 60 © Nokia Siemens Networks
Protection against EIPU Failure
For internal use onlyPresentation / Author / Date 61 © Nokia Siemens Networks
Protection against Application Failure
For internal use onlyPresentation / Author / Date 62 © Nokia Siemens Networks
Protection against Link Failure
For internal use onlyPresentation / Author / Date 63 © Nokia Siemens Networks
Protection against Router Failure
For internal use onlyPresentation / Author / Date 64 © Nokia Siemens Networks
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.
For internal use onlyPresentation / Author / Date 65 © Nokia Siemens Networks
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
For internal use onlyPresentation / Author / Date 66 © Nokia Siemens Networks
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
For internal use onlyPresentation / Author / Date 67 © Nokia Siemens Networks
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.
For internal use onlyPresentation / Author / Date 68 © Nokia Siemens Networks
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.
For internal use onlyPresentation / Author / Date 69 © Nokia Siemens Networks
Basic Routing Configuration
For internal use onlyPresentation / Author / Date 70 © Nokia Siemens Networks
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
For internal use onlyPresentation / Author / Date 71 © Nokia Siemens Networks
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
For internal use onlyPresentation / Author / Date 72 © Nokia Siemens Networks
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.
For internal use onlyPresentation / Author / Date 73 © Nokia Siemens Networks
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
For internal use onlyPresentation / Author / Date 74 © Nokia Siemens Networks
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
For internal use onlyPresentation / Author / Date 75 © Nokia Siemens Networks
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.
For internal use onlyPresentation / Author / Date 76 © Nokia Siemens Networks
Non guaranteed capacity
BTS 1 guaranteed capacity
BTS 1 Signalling & O & M
BTS 2 guaranteed capacity
BTS 3 guaranteed capacity
BTS 2 Signalling & O & M
BTS 3 Signalling & O & M
BTS 1 guaranteed capacity
BTS 1 Signalling & O &M
Non guaranteed capacity
BTS guaranteed capacity
BTS 2 Signalling & O&M
Non guaranteed capacity
BTS 3 guaranteed capacity
BTS 3 Signalling & O&M
Non guaranteed capacity
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
For internal use onlyPresentation / Author / Date 77 © Nokia Siemens Networks
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.
For internal use onlyPresentation / Author / Date 78 © Nokia Siemens Networks
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
For internal use onlyPresentation / Author / Date 79 © Nokia Siemens Networks
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
For internal use onlyPresentation / Author / Date 80 © Nokia Siemens Networks
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
For internal use onlyPresentation / Author / Date 81 © Nokia Siemens Networks
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
For internal use onlyPresentation / Author / Date 82 © Nokia Siemens Networks
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
For internal use onlyPresentation / Author / Date 83 © Nokia Siemens Networks
FTM QoS Parameters (FlexiBTS Manager)
In the Flexi NTS also same weights as in RNC can be used
For internal use onlyPresentation / Author / Date 84 © Nokia Siemens Networks
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.
For internal use onlyPresentation / Author / Date 85 © Nokia Siemens Networks
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
For internal use onlyPresentation / Author / Date 86 © Nokia Siemens Networks
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
PriForStreamARP2 0…15 13
PriForStreamARP3 0…15 13
PriForIntSignaling 0…12 12
PriForIntTHP1ARP1 0…11 11
PriForIntTHP1ARP2 0…11 11
PriForIntTHP1ARP3 0…11 11
PriForIntTHP2ARP1 0…11 8
PriForIntTHP2ARP2 0…11 8
PriForIntTHP2ARP3 0…11 8
PriForIntTHP3ARP1 0…11 5
PriForIntTHP3ARP2 0…11 5
PriForIntTHP3ARP3 0…11 5
PriForBackARP1 0…11 0
PriForBackARP2 0…11 0
PriForBackARP3 0…11 0
Used in QoS aware HSPA scheduling
and HSDPA Congestion Control
For internal use onlyPresentation / Author / Date 87 © Nokia Siemens Networks
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
For internal use onlyPresentation / Author / Date 88 © Nokia Siemens Networks
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
For internal use onlyPresentation / Author / Date 89 © Nokia Siemens 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
For internal use onlyPresentation / Author / Date 90 © Nokia Siemens Networks
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
For internal use onlyPresentation / Author / Date 91 © Nokia Siemens Networks
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
For internal use onlyPresentation / Author / Date 92 © Nokia Siemens Networks
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).
For internal use onlyPresentation / Author / Date 93 © Nokia Siemens Networks
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.
For internal use onlyPresentation / Author / Date 94 © Nokia Siemens Networks
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
For internal use onlyPresentation / Author / Date 95 © Nokia Siemens Networks
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
For internal use onlyPresentation / Author / Date 96 © Nokia Siemens Networks
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