02 Rn30032en40gla0 Ran Ip Features

3GTPL IP Features
RN30032EN40GLA0 ©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 RN30032EN40GLA0 ©2014 Nokia Solutions and Networks. All rights reserved.

Objectives
The following module presents

– An overview on the new features in RU40 release
– An overview on the new features in RU30 on top release
Objective of this module is to

– Present the new RU40 and RU30 on top features that will have an
affect to BTS and RNC planning from transport point of view
Note: cRNC (“classical RNC”) is used to address RNC196/450/2600

3GTPL IP Features
• new features in RU40 release
– mcRNC 10GE based network connectivity
– Ethernet Link Aggregation for mcRNC
– Rapid Spanning Tree Protocol introduction
– IP Security
– Iub Transport Solution for Network Sharing
– Hybrid Backhaul with IP over ML-PPP and Ethernet
– Timing over Packet Resilience
– FTIF Eth+E1/T1/JT1 for Flexi Multiradio System Module
• new features in RU30 on top release

– Source based routing (RU30)
– Dynamic Routing by OSPF
– OSPF enhancements in BTS
– Fast IP Rerouting
– QoS Aware Ethernet Switching
– Efficient transport for small IP packets
– Load sharing for NPGEs
– BTS Backhaul over Physically Separated VLAN Interfaces
– IP over ML-PPP on E1/T1 Interfaces
– ProxyARP in BTS
– Synchronous Ethernet Generation

3GTPL IP Features

– IP Security

RAN2696: mcRNC 10 Gigabit Ethernet
Based Network Connectivity

RAN2696 mcRNC 10GE based network connectivity
Brief description
• Feature introduces 10 Gigabit Ethernet interface external connectivity for the
mcRNC based on the IEEE 802.3-2008 standard
• 10GBase-SR and 10GBase-LR SFP+ modules are supported
• New site solution options are developed for 1 Gigabit Ethernet and 10 Gigabit
Ethernet external interfaces.
Motivation and benefits

• Benefits for customers
– Higher throughput supported via fewer interfaces
– Simplified configuration due to fewer interfaces
• Benefits for NSN
– 10 Gigabit Ethernet is a good option for Iu-PS transport since the Ethernet Link Aggregation and
ECMP need special emphasis in case of Iu-PS transport (few IP addresses in RNC and CN, same
UDP port used in both ends for all connections, etc)
– Long term evolution of mcRNC will rely on 10 Gigabit Ethernet, thus the required configuration needs
to be described

With and Without RAN2696
• 1 Gigabit Ethernet • 10 Gigabit Ethernet

RAN2696 interfaces can be interfaces can be RAN2696
Not activated Activated
applied for external applied for external
connectivity connectivity in addition
to 1GE interfaces
S5-A1 Module #5 Module #6
S3-B2
S3-B2 Module #3 Module #4
Module #3 Module #4

S1-A1
Backbone Network NetAct

Backbone Network NetAct
DCN OMS
DCN OMS

Dependencies
RAN2696 mcRNC 10GE based network connectivity
OSPF Site Solution

requires the following
features in addition
RAN1510
Octeon II processor and Dynamic
BCN-B HW required routing by
OSPF
RAN2696 RAN2550
RAN2240 mcRNC 10 OSPF
mcRNC HW Enhancements
Gigabit Ethernet
release2 in mcRNC and
Based Network
support Flexi Direct BTS
Connectivity
RAN2257
Virtual Routing
and Forwarding

mcRNC hardware options
BCN-A1 modules (as available since Multicontroller RNC 1.0)

 Octeon+ processor
 1 Gigabit Ethernet network connectivity
BCN-B2 modules (introduced with Multicontroller RNC 3.0)
 Octeon II processor
 1 and 10 Gigabit Ethernet network connectivity
BCN-A1 BCN-B2
Configurations Configurations
Step S1-A1 Step S5-A1 Step S1-B2 Step S3-B2

Supported Ethernet interface types by mcRNC
hardware
• 1GE and 10GE Ethernet interfaces intended for user-, control- and management plane
connections
• Combination of 1*10GE + 10*1GE OR 2*10GE supported per BCN module
• The physical type of the interface is configured by plugging in a proper SFP/SFP+ module
• Any interface can be configured to be used as an Iu, Iub, or Iur interface
• Shared EIPU and Dedicated EIPU configurations are supported in mcRNC3.0
10Base-T/
IEEE 802.3 10GBase-SR/
100Base-TX/ 1000Base-LX 1000Base-SX
interface subtype 10GBase-LR
1000Base-T
300m (SR) / 10 000 m

Max cable length 100 m 5000 m 300 m
(LR)
Connector type RJ-45 LC duplex LC duplex LC duplex

Technical details
Connectors on front panel of mcRNC 3.0
2x USB
Software download
1x RJ-45
Hardware maintenance
Debugging
interfaces
1x SFP 9x SFP+ 10x SFP 4x RJ-45

Tracing 7x BCN interconnect, UTRAN interfaces
SFP Alarm and sync interfaces,
2x UTRAN interfaces not used by mcRNC
EM,
SFP13 – SFP22 DCN
10GE external
ports
SFP+ 11, SFP+ 12

Technical details
BCN-A hardware interface specification
Number
Interface of Printed
type interface label
s
Backplane External 1GE network connectivity is implemented
ports SFP1 – based
6
(Internal SFP6
10GE) on the following standards:
• 1000Base-TX, electrical transmission via SFP
External SFP7 –
16 with RJ-45 connector
1GE SFP22
• 1000Base-SX/LX, optical transmission via SFP
External with LC-type connector
0
10GE External 10GE network connectivity is implemented
based
Trace port 1
on the following standards:
• 10GBASE-SR acc. IEEE 802.3-2008 Clause 49
and 52.5
• 10GBASE-LR acc. IEEE 802.3-2008 Clause 49
and 52.6
Technical details
BCN-B hardware interface specification
Number
Interface Printed
of
type label
interfaces
Backplane
ports SFP0 –
7
(Internal SFP6
10GE) External 1GE network connectivity is implemented based
External SFP13 –
10 • 1000Base-TX, electrical transmission via SFP with RJ-
1GE SFP22
45 connector
• 1000Base-SX/LX, optical transmission via SFP with LC-
External SFP+ 11 type connector
2
10GE SFP+ 12
External 10GE network connectivity is implemented based
Trace port 1 • 10GBASE-SR acc. IEEE 802.3-2008 Clause 49 and 52.5
• 10GBASE-LR acc. IEEE 802.3-2008 Clause 49 and 52.6

mcRNC3.0 site solutions
• mcRNC Evolved Site Solution (mcRNC2.0)

• Site solution based on Ethernet switchport configuration in the site routers
• Static routes with BFD Single-Hop applied for next-hop supervision
• Available at mcRNC2.0 release
• Supports 1GE interfaces only
• mcRNC VRRP/HSRP Site Solution (new in mcRNC3.0)

• Site solution where site router redundancy is managed with VRRP or HSRP
protocols
• L2 Ethernet switching takes place in between the mcRNC and site routers
• Provides planning principles compatibility with the current IPA-RNC installed base
VRRP/HSRP site solutions
• Supports 1GE and 10GE interfaces
• mcRNC OSPF Site Solution (new in mcRNC3.0)

• Site solution featuring full IP layer resillience based on dynamic routing
• mcRNC learns the network destination subnets via the dynamic routing (depends
on the overall network planning)
• Supports 1GE and 10GE interfaces

VRRP/HSRP site solution overview
User plane, Iub Control plane

• Service IP address: Network
interface, IP address follows the
service
Backbo
• Routing: Static routes ne /
Backha
• Redundancy: Recovery Group, Link ul
State Detector, VRRP/HSRP
Iu/Iur Control plane
Logical view:
• IP address: Network VLAN1
interface/backplane, fixed IP address VLAN2
• Routing: Static routes
• Redundancy: SCTP Multi-Homing
• (Same configuration with OSPF
SiSo)

OSPF site solution overview
User plane, Iub Control plane

OSPF area
• Service IP address: Loopback interface,
IP address follows the service
• Routing: OSPF Backbo
ne /
• Redundancy: Recovery Group, Link State Backha
ul
Detector, OSPF
OSPF
Iu/Iur Control plane backbone
• IP address: Network interface/backplane,

fixed IP address
• Routing: Static routes
• Redundancy: SCTP Multi-Homing
• (Same configuration with VRRP/HSRP
SiSo)

3GTPL IP Features

– IP Security

RAN2256: Ethernet Link Aggregation for
mcRNC

Ethernet Link Aggregation for mcRNC
• This feature combines several physical Ethernet interfaces

between the mcRNC and the next hop router/switch. Each
Link Aggregation Group, LAG, comprises a logical interface
that supports more capacity than a single Ethernet interface
and improves availability in the event of single physical link
failures.
• With the implementation of the Link Aggregation Control
Protocol (LACP), the link aggregation functionality supports
automatic management of the link status and group status.
• This feature is supported in the Iub, Iur, Iu-CS, and Iu-PS
interfaces.

Benefits
Customer Benefits
• Ethernet link aggregation provides Ethernet link protection
using load sharing without the need for an additional
protecting Ethernet interface unit. The feature supports
higher IP interface capacity and thus simplifies the
configuration.

Functional Description
• Ethernet link aggregation (IEEE 802.1AX-2008) allows the combining of

multiple physical Ethernet interfaces between the mcRNC and next hop
router/switch as a means of link redundancy.
• Ethernet interfaces at the physical layer form a single link layer interface,
also known as a Link Aggregation Group (LAG) or bundle. The IP layer
sees the LAG as a logical Ethernet interface with a unique MAC address.
• If the whole LAG is down, new connections to this group are blocked.
Additionally, port operational state changes from “enabled” to “disabled”.
• In the mcRNC up to eight 1GE ports of the same Box Controller Node
(BCN) module can be aggregated within one link aggregation group. Up
to eight link aggregation groups are supported within the same BCN
module.
• Link aggregation is supported by ports that are defined for external
usage.

3GTPL IP Features

– IP Security

RAN2156: Rapid Spanning Tree in BTS

Brief Introduction & Benefits of RAN2156 (1/2)
• RAN2156 introduces Rapid Spanning Tree Protocol (according to IEEE 802.1D – 2004) in BTS
• Protection against link/node breaks in pure ETH network based on RSTP
• Reduces service unavailability and avoids immediate site visits
• Main RAN2156 applications:
• Deploying BTS as part of microwave radio or fiber based Ethernet ring topologies
• Redundant fiber access to a cell site
• Deploying multiple BTS at a single cell site (local ring instead of chain topology)
• Resolving connection errors by avoiding Ethernet loops
• RSTP is typically able to respond to topology changes within about 3s (based on minimum Hello
Time Interval of 1s) or less than 1s if connectivity failure causes a LOS to the switch and switch
supports Fast LOS detection which is the case with Flexi Multiradio 10 BTS
Aggregation
ring
Packet
Network Local ring
Active path
Cell site
Passive path

• Benefits for customer

• RSTP allows to include the BTS in Ethernet Ring topologies for the purpose of e.g.
• Deploying BTS as part of microwave radio or fiber based Ethernet ring topologies
• Redundant fiber access to a cell site
• Deploying multiple BTS at a single cell site (local ring)
• It provides resiliency, without need for an external cell site device, that can be activated
by software only and thus minimizes site and maintenance cost.
• Using this feature reduces service unavailability and avoids immediate site visit in case
of very rare but temporary/permanent failures like equipment failures, microwave radio
path outages, fiber breaks, site power cuts, site resets due to maintenance activities,
etc.
• RSTP resolves ETH loops
• RSTP is backward-compatible with the STP-enabled switches in the network
• Benefits for NSN
• RSTP is standard feature of Ethernet Switches and in BTS complements the integrated
QoS Aware Ethernet Switching function. It is explicitly requested in some tenders and/or
considered in offerings for covering customer needs like redundant fiber access to site.

RAN2156 RAN2156
Packet
Network
Packet Packet
Network Network
OR
• Pure ETH physical ring topology not • ETH ring protection topology
supported, or supported without a need for external
• ETH ring protection topology requires cell-site device (RSTP implemented in
external cell-site device supporting BTS integrated ETH switch)
RSTP

Requirements of RAN2156
Feature requirements:
OR
• At least two active transport ETH interfaces RAN1769 RAN1847
are needed, so one of the features below is QoS Aware Basic Ethernet
mandatory: Ethernet Switching Switching
• RU30EP1 RAN1769 QoS Aware Ethernet
Switching
• RU10 RAN1847 Basic Ethernet Switching
• It is strongly recommended to use
RAN1769 (where egress scheduling is RAN2156
supported), in order to preserve high priority Rapid Spanning
traffic when traffic is switched to alternative Tree (RSTP) in
path with limited bandwidth BTS
Hardware requirements:
• Supported WCDMA transport units (number of available ETH interfaces in brackets):
• FSMr2: FTIA (3), FTJA (3), FTIB (2), FTFB (4), FTLB (3)
• FSMr3 (indoor) without transport module (2)
• FSMr3 with transport module: FTIF (3), FIIF (3), FTLF (3)

This feature requires RAN1016/RAN1848: Flexi BTS Multimode System Module.
In the RNC RAN1226: HSPA Peak Rate Upgrade for RNC196 and RNC450 is
required.
FlexiBTS1.0
FlexiBTS2.0
FlexiBTS3.0
Flexi HW2.1
Flexi HW2.2
BTS_SW Release : WN5.0 CD2

WN6.0
WN6.0 EP1
WN7.0

RSTP introduction (1/2)
• Creating physical loops (e.g. ring or mesh MAC_DA: all “1”s

ETH loop
topology) in pure ETH networks is forbidden,
due to “broadcast storm” phenomenon:
• Received broadcats/multicast ETH frame is sent ETH loop
out (broadcasted) via all remaining switch ports
(this is standard compliant behavior)
ETH loop
• When two (or more) switches are connected in a
loop topology, broadcast/multicast frames are
endlessly sent out, saturating the links
ETH loop
MAC_DA: all “1”s

• In order to prevent broadcast storms,
Blocked by RSTP RSTP is dynamically creating logical
loop-free topology, by blocking some ports (data
plane frames are not forwarded, only RSTP control
BPDU messages are exchanged)
• Upon link failure, new loop-free topology is
calculated dynamically by RSTP (some previously
blocked ports may return back to forwarding state)

RSTP introduction (2/2)
• RSTP behavior is deterministic – for given physical topology

with assigned bridge priorities and port paths costs, root
bridge election and spanning tree topology calculation results
are unambiguous
• This in consequence means, that RSTP is revertive – when the
link/node failure is cleared, spanning tree topology will again be
recalculated and exactly the same state as before the failure will be
achieved • This loop-free topology is called spanning tree
with root bridge on top
Packet
Network • Note, that any bridge (depending on root election
Root Bridge
results) can play a root bridge role, however it is

advised that the device aggregating the traffic
from shared segment is the root (thus RSTP root
bridge election procedure should be manually
influenced)

RSTP key terms (1/2)
• RSTP bridge port states:

• Forwarding - A port receiving and sending data, normal operation. RSTP still monitors incoming
BPDUs that would indicate it should go to the Discarding state to prevent a loop.
• Learning - While the port does not yet forward frames it does learn source addresses from frames
received and adds them to the MAC table (it populates the MAC address table, but does not forward
frames).
• Discarding - no user data is sent or received, MAC address table is not being populated. If the other
links in use were to fail, the spanning tree algorithm can determine the port may transition to the
Forwarding state. MGMT frames (BPDU, Link OAM, SSM, ToP over Ethernet) are sent/received
during Discarding state. Prevents the use of looped paths.
• RSTP bridge port roles:

• Root - A Forwarding port that is the best port from non-root bridge to root bridge.
• Designated - A Forwarding port for given LAN segment. Each LAN segment can have only one
Designated port.
• Alternate - An alternate path to the root bridge. This path is different than using the Root port.
• Backup - A backup/redundant path to LAN segment where another bridge port already connects.
• Disabled - Not strictly part of RSTP, a network administrator can manually disable a port.
In a stable network, Root ports and Designated ports are Forwarding,

while Alternate, Backup, and Disabled ports are Discarding.
RSTP key terms (2/2)
RSTP port roles / port states

Packet Network Root Bridge
in stable network (example assuming
equal cost for all links)
Spanning-tree topology (loop-free)
Root / Forwarding
Designated / Forwarding
Alternate / Discarding
Backup / Discarding
Blocked links

RSTP operation
• Root Bridge election

The Root Bridge of the spanning tree is the bridge with the lowest Bridge
Identifier. Bridge Identifier comprises of configurable Bridge Identifier Priority and
globally unique Bridge MAC address. To compare two Bridge Identifiers, the
Bridge Identifier Priority is compared first. If two bridges have equal Bridge
Identifier Priority, then the MAC addresses are compared.
• Calculating spanning tree (loop free) topology

Based upon least cost paths to the Root Bridge, spanning tree algorithm is
assigning Root port roles and Designated port roles for other bridges (these ports
are in Forwarding state)
• Disable all other root paths

Any active port that is not a Root port or a Designated port is blocked (Discarding
state)

RSTP Convergence Time in Ring Topology (1/2)
• RSTP convergence time (recalculating spanning tree topology upon link/node failure) in ring
topology depends on:
• Failure detection time (D)
• BPDU Hello based  3 * BPDU hello timer (6 s using default 2 s BPDU hello timer)
• LOS based  less than 2 s, depending on HW capabilities (in optimal cases, e.g. FSMr3, ~100 ms)
• Number of bridges (which is equal to number of links) in the ring (N)
• Distance between actual failure point and link blocked by RSTP in stable network conditions (M)
• Number of RSTP steps required to converge: 2*M + N
• 5 ms is assumed per each step
• Total convergence time (C) can be estimated by the following formula:
C [s] = D [s] + (2*M + N) * 0.005 [s]
• To achieve shortest convergence times BPDU messages should use the highest scheduling
priority if RAN1769 QoS Aware Switch is enabled
• Convergence time estimated above is not taking into account Root Bridge election
procedure. It is recommended that ring aggregation device is elected as Root Bridge (by
manual configuration), so any RSTP topology change will not trigger Root Bridge election
procedure (unless the ring aggregation device is down, which will anyway cut the traffic for
entire ring).

RSTP Convergence Time in Ring Topology (2/2)
• Exemplary case for 6 nodes in the ring (N=6), LOS based detection time at 1 s
• For typical ring deployments (up to 6 nodes), failure detection time is the
most contributing factor to total RSTP convergence time
Minimum convergence time (link failure Maximum convergence time (link failure
next to link blocked by RSTP) distant from link blocked by RSTP)
M=1  1.04 s M=5 1.08 s
Root Actual link

Bridge failure
Actual link Root
failure Bridge
Packet
Network Packet
Network
Link blocked by
RSTP in stable
conditions
Link blocked by
RSTP in stable
conditions

WCDMA Synchronization Impact
• Timing over Packet (ToP)

RSTP L2 topology is transparent to L3, so any change triggered by RSTP will not influence ToP (except
for losing some Sync messages during convergence time, which should not be a problem in most cases).
If automatic sync signal recovery is required, ToP is recommended together with RSTP. This
scenario requires ToP support in BTS (RAN1254).
• Synchronous Ethernet (SyncE)

SyncE SSM messages (which distribute
information about clock quality of ETH PHY
signal) are not impacted by RSTP port states Packet Root Packet
(port in Discard or Learning state will still Network bridge Network
send/receive SSM messages). This means, PRC
that in case of link failure, SSM messages will Link
blocked SSM
SSM
not be automatically redirected by RSTP to by RSTP messages
messages
operational path. Therefore if automatic sync
signal recovery is required, SyncE is not
recommended together with RSTP. If the
configuration is manually adapted to the
SSM
changed topology the SyncE master/slave roles messages
have to be re-negotiated, then this results in a
temporary link break (during the negotiation SyncE distribution
phase no traffic can be transmitted on this link). Spanning tree topology
Exemplary scenario beside requires SyncE (independent from
support and generation in BTS (RAN1708 and spanning tree topology)
RAN2071).

BPDU messages
• RSTP control messages called Bridge Protocol Data Units (BPDUs) are
used to exchange information about bridge Bridge Identifiers (including
Bridge Identifier Priority) and root path costs.
• A bridge sends a BPDU frame using the unique MAC address of the port
itself as a source address, and a destination address of the STP multicast
address 01:80:C2:00:00:00.
• BPDU frames are not forwarded (broadcasted) by bridges (these frames are
exchanged between directly connected ETH interfaces)
• Two main types of control messages are exchanged:
• Configuration Messages (can be encoded as Configuration BPDU or
RST BPDU) aka BPDU Hello messages
• Topology Change Notification (TCN) Messages (can be encoded as
TCN BPDU or RST BPDU)
• Configuration BPDUs and TCN BPDUs encoding is supported to
provide backward RSTP compatibility with STP
• BPDUs are exchanged regularly (every 2 seconds by default, according to
configured Hello timer) and enable switches to keep track of network
changes and to start and stop forwarding at ports as required.

BPDU messages
[3] TS25.331 Radio Resource Control (RRC) Protocol Specification
10.3.3.42 UE radio access capability -> 728
The integer value n indicates that the nth DB-DC Configuration in table 5.0AA in
[21] is supported by the UE.
RP-45 RP-090923 3727 2 Introduction of Dual Band
HSDPA in 25.331 8.8.0 9.0.0
RP-46 RP-091337 3899 1 Dual band and DC+MIMO
capability signalling 9.0.0 9.1.0
Radio Link Reconfiguration??????????????
INTER_RAT_HANDOVER_INFO_TRANSFERRED
INTER RAT HANDOVER INFO
RRC CONNECTION SETUP COMPLETE
UE CAPABILITY INFORMATION
UE radio access capability

3GTPL IP Features

– IP Security

RAN1747: IP Security

Brief Introduction & Benefits of IP Security
IPsec suite
IPsec is a suite of protocols and services, ES IK

P E
designed to provide interoperable, high AES-
quality, cryptographically-based security for IP CBC
based traffic AH GDO
IPsec offers access control, connectionless
IPsec I
integrity, data origin authentication, protection ISAKM
against replays confidentiality RFC P
These services are provided at the IP layer, 4301
SA
offering protection for IP and/or upper layer
protocols.
Fundamental components of IPsec (RFC 4301):

Security protocols: Authentication Header (AH) and Encapsulating
Security Payload (ESP)
Security Associations (SAs)
Key management, manual and automatic, Internet Key Exchange (IKE)
Mathematical algorithms for authentication and encryption

Brief Introduction & Benefits of RAN1747
Security threats and solutions
Possible threats IPsec solution
Eavesdropping Encryption ESP protocol in IPsec provides data

confidentiality by encrypting IP packets
Cryptography-based keys, shared only by the sending

and receiving hosts, are used to create a cryptographic
Traffic manipulation Integrity validation checksum for each IP packet
IPsec
IPsec allows verification of identities without exposing that
Identity spoofing Authentication information to an attacker ensuring that traffic is coming from the
authorized BTS and RNC
Packet filtering IPsec uses IP packet filtering to allow or block traffic based on IP
DoS attack address ranges, IP protocols, or even specific TCP/UDP ports
While typical implementations of ATM networks are regarded secure, the use of IP
transport opens new possibilities for transport networks which cannot be regarded as
secure anymore.
The benefit of IP transport is a possibility of using public networks for backhaul
connectivity. In this case security risks become an important issue, that can be
resolved with implementation of IPsec protocol suite.

Securing interfaces
Benefits:
 It allows to use
transport networks that
cannot be fully trusted
 It implements
embedded IP security
functions for Iub
interface, so that an
external Security
Gateway (SeGW) at
the BTS site is not
needed (as IPsec is
not supported on the
RNC, SeGW is
required on that end)
 It complements the
RAN security solution

Brief Introduction & Benefits of RAN1747, cont.
RAN1747 IP Security feature introduces embedded support in Flexi

Multiradio BTS WCDMA for Iub traffic confidentiality, integrity, and
authentication by using IPsec. Apart from Iub traffic, the protection by
IPsec can as well be applied to circuit emulated traffic that is terminated
in BTS. At the RNC site, all IP traffic (that is, Iub, Iur, Iu-PS, Iu-CS, Iu-BC,
Iu-PC, and O&M) is configured to pass a Security Gateway (SeGW).
For the controller site (Iub, Iur, Iu-PS, Iu-CS, Iu-BC, Iu-PC, O&M)
IP security is provided by means of an external Security Gateway.
The solution can be used for all controller generations as there is
no strict dependency to it.
The same Security Gateway solution can be used for the Core Network site and
for I-HSPA.

With and Without Feature RAN1747 IP Security
IP Security IP Security
• IP traffic fragile to security • IP traffic secured with

threats: eavesdropping, traffic encryption, authentication and
manipulation, identity spoofing integrity protection
• Public IP networks not safe for • Embedded SeGW functionality
backhaul in WCDMA BTS
• Alternatively external SeGW • Possible use of public IP
required at WCDMA BTS site networks for backhauling with
no external SeGW

Use cases
Untrusted service provider
RNC
SGSN
L2 or L3 L2 or L3
service provider service provider Core Network
WCDMA SeGW SeGW

BTS
MGW
L2 or L3
service provider
Attacker
Often third party service providers are used SeGW

RNC
for backhauling to the WCDMA BTS, as well
as for Iu and Iur interfaces. Although traffic
confidentiality and integrity could be part of
the SLA with the service provider, additional
security measures can be undertaken

Feature Overview
Traffic security
User Plane Control Plane
• encryption by radio protocols at RLC • vulnerable as it carries sensitive
layer not sufficient information
• with RAN1747 UP traffic is • with RAN1747 CP traffic is encrypted,
encrypted, integrity protected, and integrity protected, and authenticated
authenticated
Secure IP Network
Synchronization Management Plane
• synchronization threat may lead to • Natively protected with TLS (Transport
system performance degradation Layer Security) protocol
• synchronization traffic is optionally • additionally with RAN1747
encrypted, integrity protected, and Management traffic (incl. including NTP
authenticated, although not and site support equipment traffic) is
recommended due to the possible effect encrypted, integrity protected, and
on the synchronization performance authenticated
Traffic of a collocated legacy 2G BTS, DHP traffic and traffic to/from the Certificate
aggregated with WCDMA IP traffic towards a Authority shall not be secured by IPsec.
common Ethernet backhaul can also be
encrypted and authenticated

Feature Overview
IPsec protocol details
 IPsec based VPN consists of two IPsec based VPN
communication channels: key exchange channel
and (one or more) data transmission channel SA SA
 For key exchange the Internet Key Exchange
protocol (IKE) is used. IKE provides authentication IKE
of the IPSec peers, negotiates IPsec keys, and
negotiates IPsec security associations. ESP
 For data encryption Authentication Header
(AH) or Encapsulating Security Payload (ESP)
protocol (or both at the same time) are used
All implementations of AH and ESP must support Security Association (SA). SA runs on top
of IP and is identified by a given Security Parameters Index (SPI). SA represents a policy
contract between two peers and describe how they use IPsec security services. SA contains:
• Authentication/Encryption algorithm, and keys used with Authentication/Encryption
• Key lifetime
• Type of network traffic being applied
• IPsec encapsulation protocol (AH or ESP, or both at the same time)
• Source Address of the SA

Feature Overview
IKEv1 vs. IKEv2
IKE, is the initial negotiation phase, where the two VPN endpoints agree on which methods will
be used to provide security for the underlying IP traffic. Nodes are authenticated and encryption keys
exchanged. For this purpose IKEv1 and IKEv2 (Internet Key Exchange) protocols are used.
Furthermore, IKE is used to manage connections, by defining a set of Security Associations (SA) for
each connection. It is possible to update or renegotiate keys in a circular manner
IKEv1 IKEv2
• RFC 2407, RFC 2408, RFC • RFC 5996
2409, RFC 4109, RFC 4995 • Two phases
• Two phases • Identity is always hidden
• Phase 1: Main Mode and • All messages are acknowledged
Aggressive mode and sequenced
• Peer identity is hidden only in • Extensible
Main Mode Authentication Protocol (EAP)
• No messages reliability used for authentication
• No authentication build in
IKEv2 is more robust against

DoS, better performing, allows
selecting the IPsec SA based on
the DSCP of the packet

Feature Overview
Authentication and encapsulation
After SAs are established, IPsec tunnels may be created and data transmitted. IP data is transmitted
using the encryption and authentication methods agreed upon in the IKE negotiation.
For data transmission ESP encapsulation is used, as it supports both authentication and
encryption.
Only Tunnel Mode is supported - entire original IP packet is encapsulated with a new packet header
added. This way ESP protection is afforded to the whole inner IP packet (including the inner header).
ESP header consists of Security Parameters Index (SPI), for identifying the security association of
the receiving party, and Sequence Number (SN), for protection against replay attacks.
Initialization Vector (IV) field is reserved for encryption protocol. Encryption is based on AES-CBC
or 3DES algorithm.
Padding is provided to allow block-oriented encryption algorithms room for multiples of their block
size
Authentication is based on HMAC-SHA-1-96 algorithm.
Authenticated
UDP ESP ESP

IP Header ESP Header IV Original IP Header UDP Payload Padding
Header Trailer Authentication
Encrypted

Public Key Infrastructure
Authentication of the WCDMA BTS is based on
X.509 certificates. Preferred way of managing
Certificate Server Certification certificates is via RAN963 Network Element Certificate
Authority Management feature. Each node has one certificate,
signed by the Certification Authority (CA), which is
used for authentication during key exchange
The peers have a device certificate each which is
signed by a trusted authority
Registration
Certificate
Certificate The certificates are presented during the IKE
Authority Repository negotiation as a proof of identity
For most efficient operation the Security Gateway
should be based on the Public Key Infrastructure (PKI)
and be interoperable with the NSN Certification
Authority solution as well
End entity (NB) For interoperation with other devices not supporting
PKI, the Security Gateways need to support
authentication based on Pre-Shared Keys (PSK) in
addition to certificates
 Registration Authority (RA) - responsible for the registration and initial authentication of subjects
(subscribers in case of humans) asking for a public certificate
 Certification Authority (CA) - responsible for establishing the identities and creating and signing the
digital certificates
 Certificate Repository - public available repository, place to publish public certificates, usually LDAP
directories
 Certificate Server - Machine or server responsible for certificate issuing
 RA, CA and Repository may share the same server or different machines
Traffic security steps (1/5)
5 steps to secure traffic

1 Secured traffic distinction
2 IKE Phase 1
3 IKE Phase 2 Determining what type of traffic is deemed

interesting is part of formulating a security
policy for use of a VPN. The policy is then
Information exchange via IPSec implemented for each particular IPsec peer
4
Tunnel Definition of traffic to be secured should be
one of the aspects of network planning
5 IPSec Tunnel termination Securing the whole traffic transmitted
through the network is not always necessary,
and sometimes not even recommended (i.e.
encryption of synchronization traffic may
cause significant drop in performance)
In some cases applying part of the
available policies is sufficient

2 IKE Phase 1
3 IKE Phase 2 The basic purpose of IKE Phase 1 is to

authenticate the IPsec peers and to set up a
secure channel between the peers to enable
4 Information exchange via IPSec IKE exchanges. IKE Phase 1 performs the
Tunnel following functions:
• Authentication and protection of the IPSec
5 IPSec Tunnel termination peers identities
• Negotiation of a matching IKE SA policy
between peers to protect the following IKE
exchange
• Perform an authenticated Diffie-Hellman
exchange with the end result of having
matching shared secret keys
• Setting up a secure tunnel to negotiate IKE
phase two parameters


2 IKE Phase 1
3 IKE Phase 2
The purpose of IKE Phase 2 is to negotiate
IPsec SAs to set up the IPsec tunnel. IKE
Phase 2 performs the following functions:
4 Information exchange via IPSec
Tunnel •Negotiation of IPsec SA parameters
protected by an existing IKE SA
5 IPSec Tunnel termination •Establishing IPsec SA’s
•Periodical renegotiation of IPsec SAs to
ensure security
•Optionally performs an additional Diffie-
Hellman exchange


2 IKE Phase 1
3 IKE Phase 2 After IKE Phase 2 is complete and IPsec

SAs are established, information is
exchanged by an IPsec tunnel
4 Information exchange via IPSec  Packets are encrypted and decrypted
Tunnel using the encryption specified in the IPsec SA
5 IPSec Tunnel termination


2 IKE Phase 1
3 IKE Phase 2 IPsec SAs terminate through deletion or by

timing out. SA time out can be defined by the
parameter saMaxLifeTime. When the
Information exchange via IPSec SAs terminate, the keys are also discarded
4
Tunnel When subsequent IPsec SAs are needed
for a flow, IKE performs a new Phase 2 and, if
necessary, a new Phase 1 negotiation. A
5 IPSec Tunnel termination successful negotiation results in new SAs and
new keys
New SAs can be established before the
existing SAs expire so that a given flow can
continue uninterrupted

3GTPL IP Features

– IP Security

RAN2647: Iub Transport Solution for
Network Sharing

Introduction
This feature provides a basic solution for splitting the Iub bandwidth in case
of Network Sharing by multiple operators. The feature provides:
• a fixed Iub bandwidth split for UL+DL / DL traffic for maximum 2 operators or
operator groups.
• a fixed Iub bandwidth split for DL for maximum 4 operators or operator groups.
• a dynamic transport split for UL and DL traffic for maximum 2 operators covering
NRT HSPA traffic.
Benefits for the customer

• The feature allows individual operators to agree on the share they want to use
and finance of a common Iub transport network.
• The feature allows multiple operators to share a common Iub transport network
according to their agreements.

Existing functionalities, which are used by feature RAN2647:

• IP Based Route scheduling
• IP QoS functionalities
• MOCN and MORAN features
New functionalities provided by RAN2647:

• WCDMA Iub traffic spliting based on the operators PLMN id's
• PLMN id to transport pipe mapping (IP Based Route instance, VLAN)
• PLMN id to TQM object mapping in order to introduce operator specific DSCP
allocations

Operator 1
RAN2647
CN
Not activated
Operator 2
CN
Iub 1
Operator 3 Iub 2
CN
Operator 4
CN
Examplary use cases

Operator 1
CN
Operator 2
CN
RAN2647
Activated
Operator 3
CN
Operator 4
CN

Requirements of RAN2647(transport area)
Feature Requirements:
• RAN74: The feature enables the use of native IP and Ethernet transport. RAN2647 Iub Transport Solution
for Network Sharing works only with IP Iub transport mode.
• RAN1253: The feature enables the Transport QoS Mapping. Feature RAN2647 requires in the RNC the
license of RAN1253 in the dynamic transport sharing use case because enables TQM object configuration
for operator specific DSCP assignments.
• RAN1634: The feature enables the use of native IP and Ethernet transport for UltraSite WCDMA BTS.
• RAN1709/RAN2197: The features enable the VLAN interface specific scheduling. Feature RAN2647
requires in the BTS/mcRNC the license of RAN1709/RAN2199 when VLAN based UL traffic separation is
applied.
RAN74 RAN1634
IP Based Iub for IP Based Iub for
RAN1253
Flexi WCDMA BTS UltraSite WCDMA BTS
Iub transport QoS
RAN1709 RAN2647 RAN2197

VLAN Traffic Iub transport solution VLAN Traffic
Differentiation for Network Sharing Differentiation for mcRNC

Requirements of RAN2647(RRM/Telecom)
Features Requirements:
• RAN2.0042: The feature allows up to four operators to share RNCs and BTSs. With the MORAN feature
the resources of one cell belong to one operator and subscribers of different operators use cells in different
frequencies.
• RAN966: The feature introduces 3GPP solution for RAN sharing. With the MOCN several operators can
share the resources of one cell.
• RAN834: The feature allows one RNC to be connected to several CN (16 CS-CN and 16 PS-CN) nodes
inside one Core Network (operator).
RAN834
Flexible Iu
RAN2.0042 RAN2647 RAN966

NSN Iub transport solution Multi-Operator
Multi-Operator RAN for Network Sharing Core Network

Limitations of RAN2647
• RAN2647 feature cannot be used at the same time

with RAN1110 and RAN992 features towards the same BTS.
• The HSPA Congestion Control cannot function properly
once there are different possible transport paths for the
HSPA traffic.
• The feature is not supported with Co-siting Inter-RNC
processing. Common IP layer scheduling cannot be done in
different HW (IPA-RNC NPGE, BCN EIPU).
• RAN2338: The IPBR scheduling is supported within one
NPGE node.

RAN2647 Technical details
MOCN configuration (1/2)
Service
Service Platforms
Operator A  Several core network operators can be
Platforms Operator B connected to the same RNC sharing fully all
HLR
RAN resources
HLR
 Operators can have shared RAN and own

MSC/SGSN
Selection of dedicated RAN networks
MSC/SGSN the correct CN
 Utilizes one or more shared carriers for

multiple operators
RNC
RAN2647 Iub  Common site and cell level parameters

transport solution
NodeB for Network Sharing
 RNC routes the UE’s initial access to one of
the available CN nodes
 Rel-6 UEs are connected directly to own CN
 For legacy UEs the RNC re-routing
functionality is used to find the correct CN
Shared A & B Operator
frequencies

MOCN configuration (2/2)
• Operators can have shared RAN and own dedicated RAN networks
(in this case Multiple PLMN support feature must be in use)
• The available Core Network Operators in the shared radio access network are
broadcast in the system information (SI) at RAN
System Info (SIB):

Operator 1 Common PLMN
CN Shared PLMN 1
Site PLMN 2
Shared lub Common frequency set
Operator 2
CN Shared RNC ell 1

MORAN configuration (1/2)
Service
Service Platforms
Operator A  Sharing one or more physical RNC and
Platforms Operator B NodeB between multiple operators
HLR
HLR
 Dedicated carrier unit per operator in NodeB
MSC/SGSN
 Own PLMN-id’s and frequencies
 Own cell level parameters
MSC/SGSN
 Common site level parameters
RNC  Up to 4 operators with own

 licensed frequencies
RAN2647 Iub
transport solution  core networks
NodeB for Network Sharing  services
Dedicated Dedicated
Operator A Operator B
frequencies frequencies

MORAN configuration (2/2)
• Operators can have shared RAN as well as own dedicated RAN

• MORAN does not require any special support from UE’s
• no impact on logo/NW name displaying
Dedicated Frequency set 1

Site
Operator 1
CN Shared
Site
Shared lub Frequency set 1
Frequency set 2
Operator 2
CN Shared RNC

Fixed Iub transport sharing support
Downlink:
• Up to 4 fixed bandwidth pipes can be configured per BTS Iub user plane connection
(the limitation orginates from MOCN / MORAN features)
• Implementation method is based on the IP Based Route level scheduling with separate
IPBR instances. L3 IP and VLAN connectivity options are supported at the RNC end.
Uplink:
• Up to 2 bandwidth pipes can be configured per BTS Iub user plane connection
(the limitation orginates from RAN1709 feature which supports 2 user plane VLANs)
• Implementation method is based on the VLAN interface specific scheduling.
Requires VLAN configuration in BTS and RAN1709 feature license.

PLMN delivery and selection in MORAN configuration
1. RAN2647 feature needs PLMN id for transport pipe mapping (IP Based Route instance,
VLAN). L3 can deliver core network PLMN id information to TRM during:
– Common channel setup (in case of MORAN configuration)
– Signalling Radio Bearer, Radio Bearer setup
2. PLMN delivery:
• RNC sets PLMN identity for RRC connection setup based on cell PLMN.
• PLMN identity of the cell is received by RRC/MCC in the rrc_connection_request_s
message.
• The same PLMN identity is used for all Iub transport connections.
3. Each Operator uses an independent frequency band

• UEs select PLNM using two normal methods
– Manual selection where User selects the desired Operator
– Automatic selection based on the following order
▪ PLMN selection based on pre-defined Priority
▪ If same priority, Random PLMN selection if CPICH RSCP >-95dBm
(e.g UE randomly selects if A= -85dBm / B= -75dBm) or Ordered by Signal
quality if CPICH RSCP <-95dBm (e.g UE selects A if A = -85dBm
and B = -98dBm)

PLMN delivery and selection in MOCN configuration (1/2)
• Each cell in shared RAN shall broadcast information of available core network operators in
the shared area and a Common PLMN that will be used by Non-supporting UEs.
• Multiple PLMN List is received by RRC/MCC in the rrc_connection_request_s message.
• MOCN Supporting UE decodes Multiple PLMN List and take the information concerning
available CN operators in network and cell (re-)selection procedures.
• Non-Supporting UEs are only able to read PLMN Identity which is the “Common PLMN” in
the shared RAN area
Master Information Block

Information Element/Group name Need Type and reference Version
Used by
CN information elements
Supporting UEs
Used by Non- Supported PLMN types MP PLMN Type to select CN
supporting UEs PLMN Identity CV-GSM PLMN Identity
to select CN
Multiple PLMN List OP Multiple PLMN List REL-6

PLMN delivery and selection in MOCN configuration (2/2)
• A temporary identity TMSI/P-TMSI is assigned by the serving MSS/SGSN to the UE upon

network registration/attach.
• RNC uses the NRI (Network Resource Identifier) configuration in the TMSI to keep UE
served by the same selected CN operator pool.
1. UE reads available 3. MSS checks UEs
PLMN id from SI IMSI Attach credentials and
allocates TMSI to UE
Attach Accept (TMSI)
2. UE requests for
IMSI Attach
RAN MSS
4. MSS sends
TMSI to UE
Possible scenarios:
• If PLMN identity (LAI or RAI) in Initial UE identity is same as some PLMN in “Multiple
PLMN List” and fetched NRI from TMSI or P-TMSI matches with that operator's NRI list
and RRC Connection establishment cause, then RNC selects PLMN identity for RRC
connection setup from Initial UE Identity.
• If PLMN identity (LAI or RAI) in Initial UE identity is same as “old PLMN” (“common
PLMN”) and fetched NRI from TMSI or P-TMSI matches with some operator's NRI value
(from Iu_list) and RRC Connection establishment cause, then RNC selects the PLMN
identity from this Iu_Item (simple_global_cn_id/plmn_id).
• If Initial UE Identity is “IMSI (GSM-MAP)” and PLMN of IMSI is same as some operator’s
PLMN, then RNC selects this PLMN for RRC connection setup.
Transport bearers setup with transport sharing configuration
• L3 forwards the PLMN id information to TRM at SRB/RAB related branch setup.

• In MORAN case RNC allocates the common channel resources to the corresponding
operator specific transport resource via the PLMN id to IP Based Route mapping.
• In MOCN case RNC allocates the common channel transport bearers to first
IP Based Route id in the WBTS object.
SRB / RAB /
Common channel
setup, NRM checks the transport
L3 checks if the resource index from the IUO
PLMN id is known that match to PLMN id.
for the cell Transport resource index IUO -
IubTransportSharingInd
indicates which of the WBTS
object IPBR / TQM references
is selected. Select the IPBR and
L3 requests TQM reference with
transport resources given index
from NRM and NRM checks if the given IPBR /
passes the PLMN id NRM checks if the PLMN id is
given, if given then TQM reference with given
if known index is configured in the
NRM checks if the WBTS, if configured then
transport sharing is The first IPBR/TQM
activated: WBTS - reference WBTS -
IubTransportSharing IPBasedRouteId /
, if activated then Proceed with current IP transport WBTS - TQMId is
NRM checks WBTS bearer setup with taking into In case the PLMN id is not selected.
- IubTransportMedia account all possible existing defined the first IPBR/TQM
attribute: if IP setup feature combinations (IP Iub, Dual reference WBTS -
then Iub, Transport fallback, VLAN IPBasedRouteId / WBTS -
Proceed with ATM traffic differentiation) TQMId is selected.
transport bearer
reservation

RAN2647 Network Design Impact and Use Cases
UC3: Fixed BW sharing between 4 operators or operator groups in DL
DL direction only
Operator 1
CN
Operator 2
CN
Operator 3
CN
Operator 4
CN
Operator 1 Operator 2 Operator 4 Operator 3

BW share BW share BW share BW share
Assumptions:
• The Iub IP transport can be either L3 or L2 based.
• The available Iub BW is 30Mbps at IP layer and 2:1:1:1 share ratio between the operators.
• Operators configure four IP Based Route instances per BTS where the transport sharing
takes place.
• The operator 1 has agreed to take the load from the common channels into its share
(MOCN case)

RNC, Downlink BTS, Uplink
IP CAC IP CAC
Operator 1 IPBR
PLMN id 1 Scheduler
IPBR
Operator 2 Scheduler
PLMN id 2
Interface
Scheduler
Operator 3 IPBR
PLMN id 3 Scheduler
Operator 4 IPBR
PLMN id 4 Scheduler
IP Scheduling BW Scheduling BW

IPBR1: BW for UP: 11.5 Mbps RNC Configuration:

• routeBW 12 Mbps • WBTS object configuration:
IPBR 1, IPBR 2, IPBR 3, IPBR 4
• committedDcnBW 0.25 Mbps • WBTS object configuration:
• committedSigBW 0.25 Mbps IubTransportSharing -> enabled
• commitedBW • IUO 1:
• PLMN id 1 -> IPBR 1,
• IubTransportSharingInd 1 -> IPBR1
(reference to WBTS-IPBasedRouteIdIub
IPBR2-4: BW for UP: 5.5 Mbps attribute)
• IUO 2:
• routeBW 6 Mbps
• committedDcnBW 0.25 Mbps • IubTransportSharingInd 2 -> IPBR2
• committedSigBW 0.25 Mbps (reference to WBTS-IPBasedRouteIdIub
attribute)
• commitedBW
• IUO 3:
Control Plane / O&M 2 Mbps attribute)
• IUO 4:
attribute)

3GTPL IP Features

– IP Security

RAN2648: Hybrid Backhaul with IP over ML-
PPP and Ethernet

Introduction
Hybrid Backhaul is supported by means of IP as the single transport
technology. Traffic can be selectively transmitted over either IP/ML-PPP path
or IP/ETH path.
Benefits for the customer

• Protects previous investment in TDM infrastructure (e.g. microwave
radios), while allowing capacity extension by offload to Ethernet
• IP can be used as the single transport technology in Iub, despite of
having hybrid backhaul (TDM and Ethernet)
• Migration towards mcRNC despite of having still TDM in backhaul

With and Without Feature
RAN2648 Hybrid Backhaul with IP over ML-PPP and Ethernet
BTS ATM Switch
TDM Network
RAN2648
Not activated
ATM
interface
Ethernet is needed
IP Router
Ethernet Ethernet
cRNC
The activation of RAN1449: Dual Iub
for Flexi WCDMA BTS feature
in RNC is requiered
BTS IP Router mcRNC

n x T1/E1
TDM Network
RAN2648
PPP/ML-PPP
Activated
Ethernet
Ethernet
Ethernet

Mandatory features
Features Requirements:
• RAN74 IP based Iub for Flexi WCDMA BTS - The IP Iub traffic between BTS and RNC is transmitted
partly through a TDM network (BTS to IP router) and partly over an Ethernet network (between IP router
and RNC).
• RAN1878 IP over ML-PPP on E1/T1 Interfaces - The ML-PPP traffic is transmitted from the BTS up to
the IP router with ML-PPP termination, which will route this traffic to be transmitted via IP over Ethernet.
RAN1878 RAN2648 RAN74

IP over ML-PPP Hybrid Backhaul IP based Iub for
on E1/T1 interfaces with IP over ML-PPP
Flexi WCDMA BTS
and Ethernet

Technical details
Hybrid Backhaul with IP over ML-PPP and IP over Ethernet
The following funcionallities are supported by RAN2648:

• configuring and operating a PPP/ML-PPP and an Ethernet/VLAN interface
in the BTS at the same time,
• supporting both T1 and E1 interfaces,
• binding applications (UP, CP, MP) to virtual IP addresses or Network
Interface IP addresses in the BTS,
• sending and receiving IP packets, Ethernet/VLAN Ethernet and PPP/ML-
PPP data link layer interfaces at the same time,
• supporting the same Differentiated Services scheduling and shaping
scheme on Ethernet/VLAN Ethernet interfaces as in the pure Ethernet
configuration,
• supporting the same Differentiated Services scheduling and shaping
scheme on PPP/ML-PPP interfaces as in the pure PPP/ML-PPP
configuration.

Technical Details
Application assignment to traffic paths
The recommended traffic path assignment per application in the BTS for the
hybrid scenario is the following:
• High Priority User Plane (every U-Plane traffic type except for HSPA NRT):
via the TDM path over PPP/ML-PPP.
• Low Priority User Plane (HSPA NRT): via the Ethernet path.
• Control Plane: via the TDM path over PPP/ML-PPP.
• Management Plane: most likely over the TDM path over PPP/ML-PPP,
but can as well use the Ethernet path
The hybrid backhaul scenario provided by RAN2648 is recommended for

traffic separation, not for load sharing (two backhaul paths have very uneven
bandwidth).

3GTPL IP Features

– IP Security

RAN2191: Timing over Packet Resilience

Brief Introduction & Benefits of Timing over
Packet Resilience
Introduction
• Feature RAN2191 Timing over Packet Resilience is an
extension to feature RAN1254 Timing over Packet for BTS
Application SW.
• ToP Slave in WBTS has access to multipleToP Masters.
Benefits
• This feature brings in ToP Master redundancy and thus
makes synchronization plane more reliable.
• Since ToP Masters can be deployed in different locations, not
only does this feature protect against ToP Master failures but
also against Mobile Backhaul network outages.

RU40
Timing over Packet Resilience
Synchronization Protection against ToP Master or transport
network failures
ToP Master
#1
Sync Messages
~ Reference
Clock
Packet Network PRC
ToP Master
WBTS/I-BTS #2
Announce Messages
~
• More than one IEEE1588-2008 ToP Master can be addressed by each ToP Slave.
• Supported protection schemes are:
– 1+1 (one ToP Master to protect another single ToP Master)
– N:1 (one ToP Master to protect a pool of N ToP Masters)
– protection with load sharing (each ToP Master acts as a primary ToP Slave for a number of ToP Slaves and as a
protecting ToP Master for another group of ToP Slaves)
• ToP Slave selects one ToP Master from the Acceptable Masters Table according to configurable priority
and received Clock Quality Levels.
• Only the selected ToP Master is requested to grant for Sync Messages.
• In case the connection to the selected ToP Master fails, the alternative ToP Master is requested to grant
for Sync messages.

IOC-redundant ToP Master
RAN2191 Sync Messages Announce Messages Active IOC #1

Not activated
Packet ~
IP@ #1
failure
Reference
Clock
Network
failure PRC
WBTS/I-BTS control
ToP Master IP Address: become Active
IP@ #1 IOC #2
• Fully redundant ToP Masters are not possible.

• No protection against IP network failures available.
~
IP@ #1
Active ToP Master #1
RAN2191
Activated
Sync Messages
~
IP@ #1
Reference
Clock
Packet
PRC
Network
WBTS/I-BTS ToP Master #2
~
ToP Master Acceptance Table:
IP@ #1
IP@ #2 Announce Messages IP@ #2
• ToP Slave can synchronize to multiple ToP Masters.

• Fully redundant ToP Masters are possible.
• Protection against IP network failures is supported by
deploying several ToP Masters in different locations.

Hardware Feature Interdependencies (1/2)
Flexi WBTS
In Flexi WBTS, feature RAN2191 requires one of the following HW:

– with FSM Release 1 or FSM Release 2:
• FTIB: RAN1155 Flexi WCDMA BTS Eth+E1/T1/JT1 Sub-Module "FTIB" with Timing over Packet (RU10)
• FTFB: RAN1706 Transport Sub-module FTFB for Flexi WCDMA BTS (RU20)
– with FSM Release 2:
• FTLB: RAN1819 Transport Sub-module FTLB for Flexi Multimode BTS (RU20 On Top)
– with FSM Release 3:
• FTIF: with or without RAN2296 FTIF Eth+E1/T1/JT1 for Flexi Multiradio System Module (RU30 On Top) ;
FSM Release 3 supports integrated Ethernet transport interface
FSM Rel.1 FSM Rel.2

FSM Rel.2 RAN1819
Transport Sub-
RAN1155 module FTLB for Flexi
Flexi WCDMA BTS Multimode BTS
Eth+E1/T1/JT1 Sub- RAN2191
Module "FTIB" with Timing over Packet
Timing over Packet Resilience
FSM Rel.3
or RAN2296
FTIF Eth+E1/T1/JT1
RAN1706 for Flexi Multiradio
Transport Sub-
System Module
module FTFB for Flexi
WCDMA BTS

Hardware Feature Interdependencies (2/2)
I-HSPA
In I-HSPA Release 5, feature RAN2191 requires one of the following HW:

– FTLB in FSM Release 2 :
RAN1706 Transport Sub-module FTFB for Flexi WCDMA BTS (RU20)
– FTLF in FSM Release 3 :
RAN2455 FTLF I-HSPA Adapter Transport Sub-Module OD (RU40 EP1)
FSM Rel.2 FSM Rel.3

RAN1706 RAN2191 RAN2455
RAN1706 Transport RAN2455 FTLF I-
Timing over Packet
Sub-module FTFB for HSPA Adapter
Resilience
Flexi WCDMA BTS Transport Sub-Module

3GTPL IP Features

– IP Security

RAN2296: FTIF Eth+E1/T1/JT1 for Flexi
Multiradio System Module

RAN2296: FTIF Eth+E1/T1/JT1 for Flexi Multiradio
System Module
FTIF enhances the connectivity and transport mode options of
Flexi Multiradio BTS.
Connectivity:
• Up to 8 x E1/T1/JT1 interfaces to interconnect with TDM based
transport networks or equipmenet on site
• Up to two additional Ethernet ports via optical/electrical combo ports
for chaining or collocation
Transport modes:
• ATM Iub, Dual Iub and IP Iub over ML-PPP
• Media conversion for chained or collocated BTS (CESoPSN, ML-PPP)

Functional description 1/2
Optional Outdoor Transport Sub-
Module FTIF extends capabilities
of Outdoor Flexi Multiradio 10
System Module FSMF by:
2 x Combo Ports supporting following
combinations:
2 x 100/1000Base-T or
2 x optional optical SFP or
1 x 100/1000Base-T and 1 x optional
optical SFP
Flexi Multiradio System Module with
FTIF supports QoS aware
Ethernet Switching across up to 3
interfaces
8 x E1/T1/JT1 (twisted pair) on 4 x
“RJ48C-style” ports; coaxial
connectivity can be provided via
baluns

Functional description 2/2
EIF1/EIF3 and EIF2/EIF4 are paired as one combo port.

• The usage of EIF1 and EIF3 as well as EIF2 and EIF4 is mutually exclusive.
• The usage of EIF1/EIF3 on this FTIF and EIF2 on FSMF is mutually exclusive.
• The supported optical SFP’s 1000Base-BX/LX/SX/ZX are not part of the FTIF delivery.
When using the optional transmission sub-module (FTIF) the following number of interfaces
(provided by both System Module and FTIF) is possible:
3 x GE electrical
2 x GE electrical + 1 x GE optical
1 x GE electrical + 2 x GE optical
2 x GE optical

3GTPL IP Features

– ProxyARP in BTS

RAN2190: Source Based Routing in the
NPGE

Static Routing in RNC before RU30
• Routing in RNC and BTS has been done using mainly static
routes
– Only few using OSPF in RNC, partly due to limited functionality
• Routes specify gateway addresses with respect to destination
IP subnets/host
• Using multiple default routes does not work with VLANs

– Independent route selection will be performed per packet
Source Based Routing in the NPGE (RAN2190)
• The feature does not bring only the possibility of source based routing, but
also other improvements in use of default routes
• To improve configuration simplicity and flexibility in case operators are
configuring traffic separation (different VLANs for Iu-PS/CS user plane and
control plane) between RNC and the RNC site routers
• Feature enables
– The RNC allows configuring multiple routes to the same destination, or from
the same source subnet when source-based routing is used
– It is also possible to configure different source-based routes attached to
overlapping source subnets
– The user plane related part of the feature enables to configure a routing
restriction for user plane traffic separation (see next slide)
▪ Source IP selection in the RNC is performed per transport bearer during bearer
establishment phase,
▪ Routing decision is done independently for each egress IP packet, a packet with
certain source IP address can be transmitted via another interface with different IP
address.
ECMP Basics
Equal Cost Multi-Path (ECMP) is a routing strategy where

next-hop packet forwarding to a single destination can occur
over multiple "best paths".
Multipath routing can be used in conjunction with most
routing protocols, since it is a per-hop decision that is limited
to a single router. It potentially offers substantial increases in
bandwidth by load-balancing traffic over multiple paths.
Both paths
used by ECMP
(round-robin)
I-BTS RNC
ECMP
• In earlier releases, if there were multiple routes towards

identical destinations configured (incl. default routes) traffic
was distributed to the IP interfaces by means of the ECMP
algorithm
• This might lead to traffic originating at a certain VLAN
interface but being transmitted via another VLAN interface.
Data Dst=10.9.1.1 Src=10.1.2.4
NPGEP 0 (WO) SGSN
10.1.1.4 /24 GE0 10.1.1.2 /24

10.9.1.1 /24
10.1.2.4 /24 GE1 10.1.2.2 /24
RNC
Use Cases for Source Based Routing - 1
• In this use case, RNC shall be configured to send data to an SGSN via
two different IP interfaces on the same NPGE(P). Two static routes
towards the SGSN IP address are configured, leading to an ECMP
scenario.
• RNC shall transmit all packets originating from IP address 10.1.1.4 via the
green VLAN, while all packets originating from address 10.1.2.4 shall be
transmitted via the red VLAN.
PRFILE
parameter
enable/disable
ECMP routing
restriction
The following routing table shall be applied in NPGE(P) (Both routes shall have
the same preference.) :
10.9.1.1 via 10.1.1.2
10.9.1.1 via 10.1.2.2
In this use case, RNC shall be configured to send data to an SGSN via two
different IP interfaces on the same NPGE(P).
Two static routes towards the SGSN IP address are configured, leading to
an ECMP scenario.
The following routing table shall be applied in NPGE(P):
•10.9.1.1 via 10.1.1.2
•10.9.1.1 via 10.1.2.2
•(Both routes shall have the same preference.)
RNC shall transmit all packets originating from IP address 10.1.1.4 via the
green VLAN, while all packets originating from address 10.1.2.4 shall be
transmitted via the red VLAN.
By limiting the route selection in this way, ECMP situation is completely
avoided and unambiguous routing is provided.
• The benefit of using default routes is the smaller amount of route

maintenance effort (e.g. due to core network IP address changes)
• RNC will support traffic separation at the same time, i.e. all Iu-PS
user plane traffic shall be taking the green VLAN, while all Iu-CS
user plane traffic shall be using the red VLAN.
default via 10.1.1.2
default via 10.1.2.2
• This use case adds handling of control plane traffic to the previous
one
• SCTP packets from ICSU shall be transmitted by NPGE(P) via the
correct VLAN interface, according to source IP address in each
packet
the same preference.) : Dst=default GW=10.1.1.2
Dst=default GW=10.1.2.2
Src=10.2.2.0/24 GW=10.1.3.2
Src=10.2.3.0/24 GW=10.1.4.2
• This use case utilizes source based routing to support asymmetric SCTP
multi-homing via a single NPGE unit
• The intention of multi-homing is to guarantee different transmission routes
for primary and secondary SCTP traffic paths as much as possible
• Without source based routing in NPGE this is impossible as long as the
remote side offers only a single IP address (asymmetric SCTP multi-
homing).
Src=10.2.2.0/24 GW=10.1.1.2
Src=10.2.3.0/24 GW=10.1.2.2
Routing
• RNC allows configuring multiple routes to the same

destination, or from the same source subnet when source-
based routing is used
• It is also possible to configure different source-based routes
attached to the overlapping source subnets
– In that case, the route is selected based on the longest prefix match
approach.
• RNC processes the different types of IP routes with the
following priority order:
1. Source-based routes
2. Routes learned by OSPF
3. Static routes according to configured preference
Exercise-1
Exercise-1: Iu- PS with Direct Tunnel
RNC GGSNs
HSRP OSPF
ICSU 00
Iu-PS: 10.1.1.1 /32

NPGEP 0 (WO)
Iu-PS: 10.1.1.9 /32
VLAN-1 GGSN#1
Multihoming 10.10.1.1 /29 (Iu-PS UP #1)
10.10.1.9 /29 (Iu-PS CP)
GE0
Router1
SGSN#1
VLAN-2
ICSU 01
Iu-PS: 10.1.1.10 /32 10.0.2.1 /32

Iu-PS: 10.1.1.2 /32 10.10.1.17 /29 (Iu-PS UP #2) VLAN-3
GE1 GGSN#2
Multihoming 10.10.1.25 /29 (Iu-PS CP)
VLAN-4
ICSU 02
Iu-PS: 10.1.1.3 /32 1+1

Iu-PS: 10.1.1.11 /32 Protection
GGSN#3
Multihoming
NPGEP 1 (SP) SGSN#2
ICSU 03
Iu-PS: 10.1.1.12 /32 10.0.2.2 /32

Iu-PS: 10.1.1.4 /32
GGSN#4
Multihoming Router2
SPARE
ICSU
GGSN#5
SGSN#3
10.0.2.3 /32
GGSN#6
• Is this configuration possible in RU10/RU20? 10.0.1.0 /24
• What type of static routes would you create?

• How many IP based routes would you need?
• How to define destination addresses in IUPS object
Answer
• No
• Default route using virtual IP as gateway
• One IP based route is enough
• IUPSIP
– Destination IP address 0.0.0.0/0.0.0.0 , IPQM=1, IP based route ID=1
Summary
• Source based routing provides more options to use static

routing in the cRNC
– Multiple routes to the same destination, or from the same source
subnet
▪ In total up to eight routes towards the same destination or from the same
source are supported in RNC
– The source-based routing supports also traffic originating from ICSU,
OMU and OMS units which is forwarded by NPGE unit
▪ It can be used to provide traffic separation avoiding the need to configure
routes based on the remote end subnets/addresses.
3GTPL IP Features

– ProxyARP in BTS
RAN1879: Dynamic Routing by OSPF

OSPF for Redundancy (RAN1510) in RU10
working
NPGE
IF 1 Other nodes
Virtual IP Network
IP
IF 2 e.g. SGSN
OSPF
• Finds shortest path.
protecting • Sends link-state messages
• Sends hello messages.
RNC
• The functionality was only in the RNC providing interface protection for
NPGE
• It was not possible to use VLANs in the RNC at the same time as OSPF
• RAN1879 for RNC does not replace RAN1510: OSPF for Redundancy but
extends its capabilities
– BTS, cRNC and mcRNC
RAN1879 Dynamic Routing by OSPF
• The main target of this feature is to improve redundancy by

using OSPF protocol
– Can be used in Iub and Iu interfaces, cRNC and mcRNC
• Reduces configuration effort in all the routers in backhaul
network
• Enables Equal Cost Multipath (ECMP) in RNC configuring
multiple routes to the same destination with the same route
preference value (within the same NPGE)
• WBTS does not support multiple equal cost routes towards
the same destination
– If multiple equal cost routes to the same destination are configured by
operator or learned by OSPF, only one of them can be selected by
routing the table.
RAN1879 Dynamic Routing by OSPF, cont.
Feature introduces following main functionalities:

•Separate application and network interface IP
addresses for User, Control, Management and
Synchronization Plane in BTS
•Virtual IP addresses required, but they can be used
even without RAN1879 (OSPF) and RAN2440 (fast
IP reroute)
•OSPFv2 routing protocol support in BTS, mcRNC
•OSPF over VLAN for BTS and RNC
AS A AS B
OSPF Basics
Abbreviations:
AS – Autonomous System
BA – Backbone Area
SA – Stub Area
IR Area 2 ASBR
NSSA – Not-So-Stubby Area
IR – Internal Router NSSA
ABR – Area Border Router
ASBR – Autonomous System
ABR
Boundary Router
Area 0
cRNC
BA
ABRs
Area 4 (SA) ABR
L2 Backhaul Area 3
IR
SA
OSPF Basics, cont.
Open Shortest Path First (OSPF) is a link-state dynamic routing protocol in IP
networks. It belongs to a group of interior gateway protocols (IGP), operating
within a single autonomous system (AS).
OSPF uses a Link State Database that describes the topology of the AS, inside of
which it is deployed.
To synchronize this database consistently among all OSPF-speaking routers, the

contained information is flooded throughout the whole AS via so-called Link State
Announcements (LSA). This allows all routers to build the same Link State
Database and to calculate the shortest paths to all possible destinations on their
own.
A stub area is an area which cannot receive external advertisements, which

means if you say "StubArea = On", you cannot redistribute RIP or static routes
into this area. Also, a stub area may not be a transit area for a virtual link. OSPF
Area 0, the Backbone, cannot be specified as a stub area.
Basic Concepts of OSPF - 1
• OSPF cost (=metric)

– 16-bit positive number 1-65,535
– The lower the more desirable
– Relevant going out an interface
– Route decisions made on total cost (i.e. path cost)
• OSPF area:
– OSPF uses a 2 level hierarchical model
– Areas defined with 32 bit number which is configured in IP address format, but can also
be configured using single decimal value (ie. Area 0.0.0.0, or Area 0)
– Area 0.0.0.0 (or area 0) is reserved for the backbone area
– All areas must connect to area 0
– Stub area is an area which does not receive external route advertisements. It may be
configured to reduce many route advertisements into an area
▪ Instead of the external routes, a default route is advertised to the stub area.
– A totally stubby area (TSA) is an area does not allow summary routes
▪ The only way for traffic to get routed outside of the area is a default route.
– A not-so-stubby area (NSSA) is a type of stub area that can import autonomous system
external routes and send them to other areas, but still cannot receive AS external routes
from other areas
▪ NSSA is an extension of the stub area feature that allows the injection of external routes in a
limited fashion into the stub area.
Basic Concepts of OSPF - 2
• Different Types of Routers

– Internal routers (inside an area), BTS is configured as internal router normally
– Backbone routers (inside area 0)
– Area Border Routers (ABR) sits between two or more areas, ABR must touch backbone
area (area 0)
– Autonomous System Boundary Routers (ASBR)
▪ Redistribution routes learned from other routing process into OSPF makes a router an ASBR
• OSPF Algorithm
– Network changes generates LSAs, LSAs are exchanged periodically
– All routers exchange LSAs to build and maintain a consistent database
– The router calculates the shortest-path tree for the area, with this router itself as root by
the Dijkstra algorithm
• OSPF hello interval and dead interval

– The Hello Protocol is responsible for establishing and maintaining neighbor relationships
– The router sends out hello packet each hello interval
– The router will consider the neighbor down if neighbor’s hello packets are not received in
dead interval
– Hello interval and dead interval shall be consistent for all routers attached to same IP
network
Example for cRNC
• Several OSPF areas

– Some OSPF areas include BTSs, but do not include the RNC site
routers
▪ The numbers of BTSs in one area should be limited to reduce the amount
of OSPF traffic and the size of the routing tables
– The RNC is in a separate OSPF area together with the RNC site
routers
• On the other hand, the amount of areas should be limited to
reduce configuration effort.
Use case: OSPF in BTS, HSRP at RNC site routers
Area1 is stub area

BTS RNC Site
Gateway Routers RNC site routers are
Area 12 defined as ABRs
L3 RNC
Area 1
Area 0 NetAct
Area 11 IP
Backbone
DCN
Area11 and 12 are

stub areas
Use case: OSPF in BTS, HSRP at RNC site routers,
cont.
•L3 backhaul network is deployed between BTS and RNC site routers
•OSPF is configured in BTS and in L3 backhaul network
•BTS subnets are automatically advertised in L3 backhaul network by OSPF
•In case link failure between BTS and RNC site routers occurs, new path (if
available) is calculated by OSPF basing on new topology
•Optionally BFD support for OSPF can be enabled (to speed-up failure discovery
or to limit OSPF Hello packets bandwidth needs on shared Ethernet segment)
•HSRP is configured at RNC side (no OSPF support for Iub)
Configuration of Failure Detection
• The last mile for each BTS is still a single link in this
configuration
– It is sufficient to operate OSPF with a hello timer of 10 seconds
– Sufficient to recognize that there is a problem and to raise an alarm.
– Any shorter values would not help to resolve a connectivity break, as
there is no protecting link
• Among the routers in the backhaul it is recommended to use
BFD, or fast hello to recognize link breaks quickly and to
trigger rerouting.
Use case: OSPF in BTS and mcRNC
Area 100
RNC – Box 1
User plane
10.1.1.1
Router A User plane
10.1.2.1
Virtual IP Interface IP Trsp
Ctrl plane
Address Address 1.1.1.1/26
4.1.1.1/30
IP Address
10.1.3.x
OSPF 4.1.1.2/30
OSPF
OMU (WO)
10.1.5.1
3.1.1.1/32 1.1.1.3/26 Eth L3
FTM
OSPF Router B User plane
BTS OSPF
Trsp 10.2.1.1
1.1.1.2/26
IP Address
User plane
4.1.1.66/30
10.2.2.1
4.1.1.65/30
Ctrl plane
10.2.3.x
Area 1
OMU (SP)
10.1.5.1
RNC – Box 2
IP backbone
Area 0
Use case: OSPF in BTS and mcRNC, cont.
•L3 backhaul network is deployed between BTS and mcRNC

•OSPF is configured in BTS, L3 backhaul network, and in mcRNC
•mcRNC site routers are configured as ABR
•BTS and mcRNC subnets are automatically advertised in L3 backhaul network by
OSPF
•In case link failure between BTS and mcRNC occurs, new path (if available) is
calculated by OSPF basing on new topology
•Optionally BFD support for OSPF can be enabled (to speed-up failure discovery or to
limit OSPF Hello packets bandwidth needs on shared Ethernet segment)
OSPF configuration
• To configure OSPF for an mcRNC Ethernet interface, only a

few mandatory steps are required
– First the network interface needs to be present and assigned with an
IP address
– Then you need to create an area for the node that the interface resides
in
– After that add the interface to the area
– You can configure a number of global OSPF settings or interface and
area-specific OSPF settings
OSPF in the BTS
• The introduction of OSPF routing protocol builds the

capability of the BTS to calculate the routes to the destination
dynamically
• Thus, when the network topology is changing, OSPF reacts
and starts to re-converge to the new topology
• This can ease the configuration, since routes are learnt
automatically and there is no need to configure them
manually
• Virtual IP addresses are introduced
Application, Network Interface and Virtual IP
addresses
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@
Application, Network Interface and Virtual IP
addresses
Application IP address – an IP address for User, Control, Management and

Synchronization plane termination.
•This IP address is either a Network Interface IP address or a Virtual IP address.
•Network Interface IP address – an IP address assigned to a physical or logical
NE external network interface (e.g. Ethernet, VLAN, or IP-over-ATM interface).
•Virtual IP address – an IP address which is not bound to a physical or logical NE
external network interface (can be referred as loopback interface IP address).
•At least 10 IP addresses (5 Network Interface + 5 Virtual IP addresses for 2xUP,
CP, MP, SP) are supported per BTS.
Virtual IP Addresses
• Advantage of virtual IP address:

– When multiple interfaces are used in BTS, virtual IP address can be
used for downlink traffic redundancy when interface failure occurs in
BTS
– Virtual IP address could be very flexible in IP address planning
– Applications can be terminated at virtual IP addresses which is always
in active status
• The disadvantage of virtual IP address:

– Cause a lot of routing entries in routers
▪ Amount of routing entries number = virtual IP addresses per BTS * #BTS
per router
– OSPF to be used to reduce the configuration effort.
Routing Table in the BTS
• Updated by both static routes and dynamic (OSPF) routes

• Provides a capacity to hold up to 1200 routes, including static
and dynamic routes.
• From RU30 onwards the following configurable parameters
are introduced into routing table.
– Preference:
▪ Configured per route (in case of static routes).
▪ Configured once for all OSPF routes (in case of OSPF routes).
– Cost:
▪ Configured per interface.
▪ Used to calculate the metric of a route
– Metric:
▪ Only relevant for OSPF.
▪ OSPF calculates metric per route.
The user can set transport IP address, virtual IP address, or VLAN address as
router ID
Summary
• Instead of static routing, dynamic routing is now available in

the cRNC, mcRNC and BTS
• OSPF can be used in the RAN to improve resiliency in case
there are redundant routes
• New alarm for OSPF adjacency failure in BTS and RNC
• The processing load is increased in the RAN network
elements and routers
• One limitation is that OSPF can not support VLAN traffic

separation, offered by the feature RAN1709: VLAN traffic
differentiation
• If VLAN is not used for traffic separation, multiple VLANs
can be used as redundant VLAN for protection or load
sharing.
3GTPL IP Features

– ProxyARP in BTS
RAN2359: OSPF Enhancements in BTS

Background
• OSPF protection can be quite slow to converge using Hello

messages
– Fast Hello messages enable detection within 1 sec, when hello interval
in the hello packets is set to 0
▪ The configuration should be consistent for all routers connected (not yet a
standard)
– Messages are sent as multicast
• Bidirectional Forwarding Detection (BFD) is used to detect
faults between two forwarding engines connected by a link
– It provides low-overhead detection of faults, by exchanging short hello
packets between configured endpoints
– Instead of multicast OSPF hello packets, unicast BFD packets can be
used to maintain and verify OSPF neighbors or adjacencies
• This is included in the RAN2359: OSPF enhancements
Background, cont.
The OSPF support for fast hello packets feature provides a way to send
hello packets in intervals less than 1 second. Such a configuration would
result in faster convergence in an OSPF network.
When fast hello packets are configured on the interface, the hello interval
in the hello packets is set to 0. The hello interval in the hello packets
received over this interface shall be ignored.
Note: OSPF with fast hello packets isn’t yet a standard or rfc draft. And
both hello interval and dead interval must be the same for all routers
attached to a common network.
RAN2359: OSPF enhancements: Functionality
• When OSPF discovers neighbors by hello protocol and

establishes neighbor adjacency, it requests availability
tracking from the BFD module
• BFD module then uses the information to establish BFD
sessions.
• After the BFD session is established with the new neighbor,
BFD signals adjacent node failure to OSPF.
• As OSPF hellos are not any longer used for failure detection,
OSPF hello interval as a consequence can be configured to
higher value, thus reducing amount of multicast traffic.
• As BFD is based on unicasts - overall network load and
especially load on last mile per each BTS caused by control
traffic is reduced.
RAN2359: OSPF enhancements: Functionality
•When OSPF detects a new, fully adjacent neighbor it starts the BFD module
and requests for the establishment of a BFD session between the neighbors.
•The link supervision is established only between fully adjacent neighbors (in
case of Ethernet between DR and BTS) to speed up routing table update.
•It also minimizes the required number of BFD sessions and reduces the
load of BFD control packets over the network.
•When a session is established and no BFD control packet is received from
the peer within the BFD interval, BFD notifies a failure to OSPF.
•OSPF then terminates the neighbor relationship on the link. With BFD link
supervision the overall network convergence time can be reduced.
•Note! The BFD link supervision is to be established only between fully
adjacent DR and BDR in case of an Ethernet broadcast connection between
the BTS and the peers.
Parameters to Configure for BFD and OSPF
• Both OSPF Hello and BFD packets timers used for network
failure detection are configurable.
• Usually when 4 OSPF/BFD Hello packets are missed on
receiving side the link is considered down (this is also
configurable).
• OSPF timers:
– Failure_detection_time [s] = DeadInterval
– Packet_sending_rate [pps] = 1 / HelloInterval
• BFD timers:
– Failure_detection_time [s] = Remote_DetectMult *
MAX(Local_RequiredMinRxInterval,
Remote_DesiredMinTxInterval)
– Packet_sending_rate [pps] = 1 / DesiredMinTxInterval
Bandwidth Comparison between BFD and Hello
• General assumptions: Link is considered down after 4 missed packets

(Hello or BFD respectively), For BFD case OSPF HelloInterval = 10 s
Failure Failure
detection detection
#routers = 2 ETH Bandwidth time [s] = 4 time [s] = 0.4
[kbps] Hello only BFD + Hello Hello only BFD + Hello
#BTS = 100 per router 419.42 120.34 4 194.24 825.94
per BTS 419.42 43.51 4 194.24 57.62
#BTS = 50 per router 130.62 52.26 1 306.24 405.06
per BTS 130.62 14.63 1 306.24 28.74
• Conclusions
– OSPF bootstrapped BFD session for link monitoring configuration consumes
significantly less bandwidth than only OSPF Hello based configuration, when
the same failure detection times are assumed
– In case OSPF bootstrapped BFD session for link monitoring configuration
cannot be used, VLANs should be configured to limit number of BTSes per
shared Ethernet L2 domain
Summary
• OSPF convergence is improved and made faster by using

BFD
• Compare to Fast Hello messages
– Multicast vs. unicast - less control traffic on last mile
– Easier configuration - both hello interval and dead interval must be the
same for all routers attached to a common network.
3GTPL IP Features

– ProxyARP in BTS
RAN2440: Fast IP Rerouting

Static Routes
• BFD was earlier used to provide an alarm in case connection

between end points was lost and Fallback in case of Dual Iub
• In RU30 on top the BFD becomes available for OSPF and
static routes
• Static routes are used in RNC and BTS for user plane and
control plane routing traffic
• In case of failures, the route could become unavailable
– Between RNC and site routers Gateway protection using HSRP can
be used
– Fast IP Rerouting is improving resiliency in case of failures in other
parts in the network
Overview
• Depending on detected connectivity (as observed by single-

hop BFD) static routes are enabled or disabled, respectively
and an alarm is raised when BFD fails
• This feature extends the resiliency mechanisms of the RNC
– In addition to physical link failures (loss of signal) and Ethernet remote
fault indicator the BFD status is taken into account.
• From BTS point of view, RAN2440 enables operator to make
use of L2 access network with redundant paths and leave
control to WBTS on one side and, for example RNC site
router on the other site which path to take.
Fast IP Rerouting
The primary route in the routing table of the router R1 (downlink) and the
BTS (uplink) is connected to the BFD session.
Router 1
NPGEP 00
(WO)
1.1.1.1/26
Lo:6.1.1.1
Virtual IP Interface IP GE0 CP subnet

BFD 4.1.1.3/29 2.1.1.0/24
3.1.1.1/32 1.1.1.3/26 4.1.1.1/29 GE1
session 1
4.1.1.67/29
Eth L2
NPGEP 01
FTM (SP)
Lo:6.1.1.1
GE0
4.1.1.3/29
BTS GE1
1.1.1.2/26 4.1.1.67/29
Router 2
If the BFD session fails, the secondary route is

selected in the router and the BTS, which leads to RNC
the alternative transport path through router R2
being used.
Fast IP Rerouting, cont.
Towards RNC the routers implement a virtual router using HSRP. Router R1 can
be configured as primary router for the one group of BTSs, the router R2 can be
the primary router for the other group of BTSs.
After an NPGEP unit switchover from NPGEP_00 to NPGEP_01, downlink

packets are still routed by router R1, although taking a detour through router R2.
Switchover of the NPGEP units is configured in revertive mode to avoid this
detour once the failed NPGEP is operational again and to equally share the load
among the site routers again.
This feature requires the following Ethernet interfaces in the WBTS:

• FTIA, FTJA, FTIB, FTLB, and FTFB in Flexi WCDMA WBTS
• AXCF in the UltraSite WCDMA BTS
This features requires the following Ethernet interfaces in the RNC:
• NP2GE
Configuration in the BTS
• In a typical scenario, redundant paths are created by adding

two different static routes to the same destination via different
gateways and with different preference values
• Both static routes are added to the routing table. Traffic is
expected to take the route whichever has smaller preference
value.
• Primary route is mapped to the corresponding BFD session
which is configured to run between BTS and the router
• When a BFD session is down, the static routes which are
mapped to this session are removed from the routing table.
• Traffic now takes the redundant path which has next the
smallest preference value. When the initial BFD session
comes-up again, the related routes are again added to the
routing table.
Gateway Protection
• You could configure ECMP with Fast IP routing in case there is no HSRP
and dual routers
• You can bind static route with single-hop BFD session in RNC as well
• Additionally you can add ICMP session to check the destination reachability
• Combining the scenario with NPGE protection could be complicated (testing
recommended)
BFD session1
NPGE SGSN
Router
NPGE
ICMP session1
BFD session2
Exercise-2
Exercise-2
• Think of how the different resiliency mechanisms work and

where they are the most useful
– Multi-hop BFD
– Single-hop BFD
– Destination reachability check using ICMP
Summary
• BFD session defines if the connections is working towards the

destination
• Connected static route is disabled or enabled based on the
connection status by BFD
• Secondary static route is needed
• The BFD desired minimum transmission interval is configured
to 500 ms
– Resulting in a detection of link breaks of about 2-3 seconds.
– The break will be noticed by end users, but most probably will not
cause call termination by end users
– Shorter detection times would increase the load on the RNC site
routers.
• In case of collocated GSM BTSs a shorter detection time is
needed
3GTPL IP Features

– ProxyARP in BTS
RAN1769: QoS Aware Ethernet Switching

Background
• The RAN1769: QoS aware Ethernet Switching feature

provides an enhancement to the existing RAN1847: Basic
Ethernet Switching feature
• It can be used for chaining Ethernet traffic from collocated

BTSs or remote sites, using BTS embedded QoS-aware
switching functionality
• Improvements are
– QoS classification and shaping
– VLAN aware switching
– no external base-station switch needed for collocation or chaining
RU30 RAN 1769 QoS aware Ethernet Switching
QoS transport functions in BTS-switch
• Ingress rate limiting possibility
• BTS-switch is VLAN aware
– Default VLAN-ID configurable
– VLAN IDs are manually configured for each port
– Discard un-tagged traffic configurable
• Egress Scheduling and Shaping (below)
Summary
• Feature improves the possibility for chaining Ethernet traffic

from collocated BTS or remote sites, using BTS embedded
functionality
• It is described in more detail in the Module 7: IP transport
QoS
3GTPL IP Features

– ProxyARP in BTS
RAN1886: Efficient Transport for Small IP
Packets

Introduction
• For small frame sizes (e.g. as with voice) the overhead from the IP and
UDP headers leads to a high transport inefficiency.
• Efficient transport for small IP packets improves transport efficiency with

Iub/IP and Iur/IP in case of voice dominated traffic mix
• This shall result in lower transport capacity needs or more calls over the
same given transport bandwidth
• This feature reduces the transport overhead by multiplexing multiple FP
frames into a single IP packet
Functionality
• In RU30 EP1 with feature Efficient Transport for Small IP Packets, this
packets can be multiplexed together into one IP Packet reducing the
transport network overhead.
• All IP packets with the same IP address and the same DSCP code are
applicable to be multiplexed together.
Multiplexed
packets
Multiplex
packet
Actual IP and Ethernet Level Capacity Gain vs No.
of Parallel AMR Calls
RAN1886 multiplexing gain vs No. of 12.2kbps AMR calls
gain
60,00%
on IP level
50,00% on Ethernet level
40,00%
30,00%
20,00%
10,00%
0,00%
20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95 100
No. of calls
Estimation assumptions:
– DL 12.2kbps AMR calls only
– muxDelay parameter set to default value = 2ms
– activity factor for AMR = 0.6
– SRB FP PDUs also contribute to the overall multiplexing gain since SRBs are normally
mapped to the same DSCP as AMR service
Network Design Impact with Iub loadsharing
• Feature RAN1886 with RAN2338 Iub Loadsharing with Protected NPGEs
IP@1 NPGE1
calls 1 to 8
calls 1 to 8
IP@2 NPGE2
IP based route
IP@3 NPGE3
WBTS
IP@4 NPGE4
RAN1886-multiplexed traffic flow
RNC
RAN1886 multiplexing/demultiplexing engine
– Multiple RAN1886-multiplexed calls (in this example 8) towards WBTS in Iub

loadsharing scenario over a number of NPGEs (in this example 4).
– Calls per NPGE is 2
– The actual multiplexing gain of feature RAN1886 on Iub interface in Iub load sharing
scenario is lower
▪ actual_gain_with_Iub_load_sharing = actual_gain / number_of_NPGEs
Summary
• The feature improves the efficiency for example voice

transport over IP
• Needs to be taken into account in Iub and Iur dimensioning
– CAC bandwidth calculation using the Multiplexing Gain parameter is
needed
• 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.
3GTPL IP Features

– ProxyARP in BTS
RAN2338: Loadsharing with Protected
NPGEs

Iub Load Sharing with NPGEs
• Load sharing with NPGEs will support creating the IP based routes with IP
addresses over different NPGEP units for both Iub and Iu interfaces
• IFC is not supported
• For Iub load sharing the NPGE protection is required due to save the calls
and common channels
NPGEP0 GE0
(WO) GE1 Sıte router
NPGEP1 GE0 Last mile 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
Iu Load Sharing with NPGEs
• CAC can be applied for Iu-CS and Iur connections even

when load sharing is used
• Not as relevant for Iu-PS as the traffic is DL dominated and CAC is
done in UL direction in RNC
• Note that IFC is not relevant to Iu connections
Sıte router
NPGEP0 GE0 SGSN

IuPS IP based route (WO) GE1
Iur IP based route NPGEP1 GE0

(SP) GE1
Transport
IuCS IP based route NPGEP2 GE0 Network
(WO) GE1
RNC
NPGEP3 GE0
(SP) GE1
RNC
Bandwidth-limited
Sıte router links
MGW
Load Sharing with NPGEs
• Load sharing is for the user plane connections

• IP address selection for a connection is based on Round
Robin with following conditions
– This IP address is configured in the IP interface with operation state
“UP”
– BFD/ICMP session (if configured) bound to this IP address is in the
state “UP”
– The PHB definition of this IP address meets QoS requirements of the
new connection.
• IFC is not supported for load sharing
– The transport network is expected to be without bottleneck or with
equipment supporting the prioritized drop
• One IP based route shall support up to 64 IP addresses on
cRNC side interface units.
Connection Admission Control
• The CAC can be enabled and done against the IP based

route committed bit rate to guarantee the real time traffic
– CAC is done in a centralized location (RSMU)
– On Iub interface
▪ IP Based Route Committed Bit Rate >= Σ Bit rate of IP connection + IP
Based Route Signaling Committed Bit Rate + IP Based Route DCN
Committed Bit Rate
– On Iur, IuCS, and IuPS interfaces

▪ IP Based Route Committed Bit Rate >= Σ Bit rate of IP connection + IP
Based Route Signaling Committed Bit Rate
• IP based route measurement M568 works for load sharing

configurations from RU30 onwards
Summary
• This feature will support NPGE load sharing officially

Without RAN2338
– There are already some networks using load sharing,
but without CAC
• The feature is planned for protected NPGEs
• For Iub networks, the feature simplifies dimensioning NPGEP units
of NPGEP units while ensuring optimum use of
NPGEP resources:
– WBTS logically connected to a pool of NPGEPs instead
of single NPGEP
– less need for traffic planning & strict dimensioning, thus With RAN2338
less operational effort
– no need for re-homing of WBTS to different NP2GE
• It is recommended that the different connections are
sharing the same interfaces in Iu and Iub for better NPGEP pool
balance in the load sharing.
– Round robin allocates connections 50-50%, but does not
guarantee exact 50-50% load share
3GTPL IP Features

– ProxyARP in BTS
RAN2523: BTS Backhaul over Physically
Separated VLAN Interfaces

BTS Backhaul over Physically Separated VLAN
Interfaces (RAN2523)
Combination following features:
1. RAN1709: VLAN Traffic Differentiation (RU20):

• Traffic separation: utilization of different transport media for different traffic
• Traffic aggregation: different VLANs for different planes in the aggregation network
• Load distribution: user plane distribution over two different paths for capacity extension (or
U-Plane protection)
2. RAN1769: QoS aware Ethernet Switching

• QoS aware Ethernet switching between Ethernet ports to aggregate Ethernet traffic in e.g.
chaining or collocation scenarios
• VLAN awareness
• Egress traffic classification based on either DSCP or 802.1p, QoS scheduling with 4 to 6
queues (depending on Transport Sub-Module) and optional shaping
• Optional rate limiting for ingress traffic
3. Also RAN2440 Fast IP Rerouting is used in the following examples
BTS Backhaul over Physically Separated VLAN
Interfaces (RAN2523)
• More than one VLAN interface can be used in the BTS to transport Iub
traffic on physically separated ports
• User Plane Traffic Separation

• Each port can be used for specific traffic types.
• One port can be for example for low priority traffic, and the other for high priority
traffic.
• This allows to use different backhaul technologies without needing an additional
Ethernet switch.
• The two technologies could be for example two DSL variants or alternatively MWR
and DSL. Traffic is separated by using RU10 Transport QoS feature, and then
further mapped to physical IP interfaces.
• User Plane Load distribution

• Iub traffic is evenly split among the two interfaces. Benefits in this case are higher
transport capacity and better redundancy
• Control and Management plane can be configured to any of the two VLAN
interfaces.
Traffic Separation and Load Distribution
One Ethernet IF in BTS
• Pre-requisites: Node B EIF1

• RAN1709 + RAN2440 (Traffic UP1 VLAN1
separation and load VLAN2
A1
distribution) UP2 I1
CP A2 I2
• Configuration BTS:
SP
• One Ethernet interface
SSE
SSE M1
• Two network Interfaces (VLAN SSE
Interfaces) are configured M2
• Applications, UP2+CP+SP,
are bounded to the virtual IP
address, A2
• Application UP1 is bounded to BFD for VLAN1
virtual IP address A1
BTS SR1 RNC
• M1, M2 belong to a separate VLAN1
subnet VLAN1
VRRP/HSRP
• BTS routing entries towards VLAN2
RNC using both routers as
gateways SR2
VLAN2
BFD for VLAN2
VLAN1 = user plane 1
VLAN2 = other planes (fallback
for UP1)
Traffic Separation and Load Distribution, cont.
One Ethernet IF in BTS
Pre-requisites:
• RAN1709 + RAN2440 (Traffic separation and load distribution)
Configuration BTS:
• Two network Interfaces (VLAN Interfaces) are configured: VLAN1, I1 ; VLAN2, I2
• Applications, UP2+CP+SP, are bounded to the virtual IP address, A2
• Application UP1 is bounded to virtual IP address A1
• M1, M2 belong to a separate subnet
• BTS routing entries:
• Primary route: src A1, dest RNC, gw SR1
• Secondary route: src A1, dest RNC, gw SR2
• Primary route; src M, dest RNC, gw SR1
• Secondary route: src M, dest RNC, gw SR2
• BFD session: I1 <-> SR1. BFD session: I2 <-> SR2
• VLAN1, VLAN2 assignment to EIF1
Configuration Site Router 1:
• Primary route: dest A1, gw I1
• Secondary route: dest A1, over SR2
• Primary route: dest A2, over SR2
• Secondary route: dest A2, gw I1
Two Ethernet IF in BTS
Node B EIF1
• Pre-requisites: UP1
– RAN2523 + RAN2440 (Traffic A1
VLAN1
separation and load distribution) UP2 I1
CP A2 I2
• Configuration BTS:
SP VLAN2
– Two network Interfaces (VLAN
SSE M1
Interfaces) are configured: VLAN1, I1 SSE
SSE
M2 EIF2
; VLAN2, I2
– Applications, UP2+CP+SP, are
bounded to the virtual IP address, A2
– Application UP1 is bounded to virtual
IP address A1
BFD for VLAN1
– M1, M2 belong to a separate subnet
– BTS routing entries towards RNC as BTS SR1 RNC
both site routers as gateways VLAN1
VLAN1
– BTS switch VLAN-aware: VRRP/HSRP
▪ EIF1, VLAN1 VLAN2

▪ EIF2, VLAN2
VLAN2 SR2
– Note: It shall be included in the Use
Case that no plain Ethernet is BFD for VLAN2
foreseen -> loops VLAN1 = user plane 1
VLAN2 = other planes (fallback
for UP1)
Two Ethernet IF in BTS
Pre-requisites:
• RAN2523 + RAN2440 (Traffic separation and load distribution)
Configuration BTS:
• Two network Interfaces (VLAN Interfaces) are configured: VLAN1, I1 ; VLAN2, I2
• Applications, UP2+CP+SP, are bounded to the virtual IP address, A2
• Application UP1 is bounded to virtual IP address A1
• Secondary route; src A1, dest RNC, gw SR2
• Primary route: src M, dest RNC, gw SR1
• Primary route: scr M, dest RNC, gw SR2
• BFD session: I1 <-> SR1. BFD session: I2 <-> SR2
• BTS switch VLAN-aware:
• EIF1, VLAN1
• EIF2, VLAN2
• Same as case 4

• Same as case 4
Note: It shall be included in the Use Case that no plain Ethernet is foreseen -> loops
Traffic Separation and Redundant VLANs in
Different ETH IFs Increased complexity  4
VLANs needed per BTS,
• Pre-requisites: at least 2xBFD sessions
– RAN2523 + RAN2440 (NO LOAD between site Node B
router and EIF1
DISTRIBUTION!! ) BTS I1 VLAN1
– Note that this case will not apply if the I2 VLAN2
UP
same VLANs are configured in both Eth
CP A1
Interfaces I3 VLAN3
SP
• Configuration BTS: I4 VLAN4
SSE
SSE
SSE
M1
– Four network Interfaces (VLAN M2 EIF2
Interfaces) are configured: VLAN1, I1 ;
VLAN2, I2 ; VLAN3, I3 ; VLAN4, I4
– Applications, UP+CP+SP, are bounded
to the virtual IP address, A1
– M1, M2 belong to a separate subnet BFD for VLAN1
BFD for VLAN2 RNC
– BTS routing entries towards RNC using BTS SR1
VLAN1
both site routers and VLANs:
VLAN1 VLAN2
– BFD session: I1 <-> SR1/VLAN1, I2 <-> VLAN2
VRRP/HSRP
SR1/VLAN2
VLAN3
– BTS switch VLAN-aware: VLAN4 VLAN3
SR2
▪ EIF1, VLAN1, vLAN2 VLAN4
▪ EIF2, VLAN3, VLAN4 VLAN1 = Mgmt plane

VLAN2 = other planes
VLAN3= redundant Mgmt plane
VLAN4= redundant other planes
Traffic Separation and Redundant VLANs in
Different ETH Ifs, cont.
Pre-requisites:
• RAN2523 + RAN2440 ( !!NO LOAD DISTRIBUTION!! )
• Note that this case will not apply if the same VLANs are configured in both Eth Interfaces
Configuration BTS:
• Four network Interfaces (VLAN Interfaces) are configured: VLAN1, I1 ; VLAN2, I2 ; VLAN3, I3 ; VLAN4, I4
• Applications, UP+CP+SP, are bounded to the virtual IP address, A1
• Primary route: src A1, dest RNC, gw SR1/VLAN1
• Secondary route: src A1, dest RNC, gw SR2/VLAN3
• Primary route: src M, dest RNC, gw SR1/VLAN2
• Secondary route: src M, dest RNC, gw SR2/VLAN4
• BFD session: I1 <-> SR1/VLAN1, I1 <-> SR1/VLAN2
• BTS switch VLAN-aware:
• EIF1, VLAN1, vLAN2
• EIF2, VLAN3, VLAN4
• Primary route; dest M, gw I2
• Secondary route: dest M, over SR2
• Primary route: dest M, over SR1
• Secondary route: dest M, gw I4
Limitations in BTS Backhaul over Physically
Separated VLAN Interfaces
• No different MAC@ per ETH interface (the same BTS
internal ETH MAC only available for traffic
originated/terminated in BTS)
• Chaining scenario not supported by FTIB or Flexi 10 without
optional transport module (only 2 active ETH available)
• Assigning both BTS backhaul ETH interfaces to the
same VLAN should be avoided (to prevent potential L2
loops)
Summary
• Traffic separation allows the operators to assign different

traffic classes to different VLANs on different ports in the
BTS, which might use different backhaul paths.
– With this feature the traffic can be separated without an external
device at the BTS site
– Instead of using Dual Iub, you could have different types of IP
transport
• Load distributions are beneficial for user plane resilience

improvement.
– Two or more VLAN interfaces on different physical paths with different
quality can be used, which otherwise would only be possible with the
additional costs of an external element.
3GTPL IP Features

– ProxyARP in BTS
RAN1878: IP over ML-PPP on E1/T1
Interfaces

IP over ML-PPP on E1/T1 Interfaces
• Allows reusing existing PDH (E1/T1) infrastructure
• Aggregating multiple PDH links into a single bundle and to carry IP traffic over it
– ML-PPP can bundle up to 16 E1/T1 links
• It provides a smooth migration to IP transport over packet networks.
• The basis scenario of (ML)PPP feature is shown in the figure below:
– One single link or single ML-PPP bundle to the gateway
– Gateway is located in front of the RNC
– No redundant gateways are used
Next hop router/

Cisco 76xx./ Tellabs 86xx
The BTS encapsulates the IP traffic to be transmitted over E1/T1 and

the gateway does the conversion towards Ethernet and RNC.
IP over ML-PPP on E1/T1 Interfaces with
Redundant RNC Site Solution
The (ML)PPP function
is not resilient, but only
distributed
between both
gateways
Next hop router/

IP over ML-PPP on E1/T1 Interfaces with Ethernet
Backhaul
• This hybrid scenario allows parallel use of TDM and Ethernet
backhaul, using IP as a common transport technology,
• High priority traffic uses the ML-PPP path, including
synchronization for the BTS.
Next hop router/
This setup needs licenses for the following features:

- RAN1878 IP over ML-PPP on E1/T1 interfaces
- RAN74 IP Based Iub for Flexi WCDMA BTS
- RAN1317 BTS Backhaul over several IP interfaces
- RAN1709 VLAN Traffic differentiation (if applicable)
RAN1878 IP over ML-PPP on E1/T1
Hardware with supported E1/T1 modules
(ML)PPP is used in the last mile, running between Flexi WCDMA BTS
and the next hop IP router (e.g. Cisco76xx or Tellabs 86xx).
The functionality is supported in the following transport cards:
Module name Interfaces

FTLB 4xE1/T1/JT1, 2xGEelectical, 1xGEoptical
FTFB 3xFlexbus, 2xGEelectrical
FTHA 16xE1/T1
FTIB 4xE1/T1/JT1, 2xGEelectical, 1xGEoptical
FTFA 2xFlexbus
FTEB 8xE1 coaxial
FTPB 8xE1/T1/JT1
FTJA 4xE1 coaxial, 2xFE, 1xGEoptical
FTIA 4xE1/T1/JT1, 2xFE, 1xGEoptical
FTIF
Comparison between ATM and ML-PPP Efficiency
Comparison of required BW between three different scenarios

• RU20 default mix (19 AMRs, 5 PS64, 3 HSPA)
• voice dominant (49 AMRs)
• data dominant (10 PS64 and 4 HSPA)
ML-PPP + Efficient
Traffic ATM [kbps] ML-PPP [kbps]
transport [kbps]
RU20 Mix 1714 1998 1640
Voice dominant 1199 1939 1164
Data dominant 2182 2224 2121
Summary
• Impact on Iub U-Plane, C-Plane, M-Plane, Sync-Plane

Dimensioning:
– Impact of the ML-PPP header should be included in the transport
traffic calculations
– ANT_3G tool supports ML-PPP as one of the transport protocol
• ML-PPP with Efficient transport for small packets is as

efficient as ATM transport
• Requires expensive channelised STM-1 interfaces in the

routers
3GTPL IP Features

– ProxyARP in BTS
RAN2083: ProxyARP in BTS

RAN2083 Proxy ARP for BTS
Introduction
• Routers by default do not forward ARP broadcasts. ProxyARP enables to

forward the ARP request through the router’s interfaces.
• Thanks to ProxyARP feature which is enable at the NodeB’s external
IP/Ethernet interfaces, the static/dynamic routing on the Next-hop router
does not have to be configured towards the BTS’s O&M internal subnet.
• Using Proxy-ARP saves effort in terms of route configuration in site
routers (for L3 deployments) or RNC units (for L2 deployments), thus
allowing simpler, less error-prone and faster commissioning.
• RAN2083 decreases complexity in planning, configuring and maintaining
the packet-based radio access network and thus increases serviceability
and saves OPEX
• This feature requires any of the Ethernet interfaces:
FTIA, FTIB, FTJA, FTLB, or FTFB
RAN2083 Proxy ARP for BTS, cont.
Introduction
Brief description
1.Routers by default do not forward ARP broadcasts, ProxyARP was implemented
to enable devices that are separated
into physical network segments connected by a router in the same IP network to
resolve the IP-to-MAC addresses.
2. Thanks to ProxyARP feature which is enable at the NodeB’s external IP/Ethernet
interfaces, the static/dynamic routing
on the Next-hop router does not have to be configured towards the BTS’s O&M
internal subnet.
Motivation and Benefits

1.In general it is about the site router configuration simplicity
2.Using Proxy-ARP saves effort in terms of route configuration in site routers (for L3
deployments) or RNC units (for L2 deployments), thus allowing simpler, less error-
prone and faster commissioning.
3.RAN2083 decreases complexity in planning, configuring and maintaining the
packet-based radio access network and thus increases serviceability and saves
OPEX.
Proxy ARP general description
• How does Proxy ARP work?
In case there is a router between

When a host A needs to send an IP A and D, the ARP request will not
packet to a host D it has to know the be forwarded, unless the IP Proxy
MAC address of D. To learn the MAC ARP is enabled on an router’s
address of D the host A will send an interface.
ARP broadcast request on the LAN
With proxyARP, the router will recognize the ARP request for the
host D, which is on a different physical segments but in the same
subnet. It will reply with its own MAC address to the ARP requests
from host A. In the following, host A will send the IP packets for host D
to the MAC address of the router. The router will forward the IP
packets to host D
RAN2083 Proxy ARP for BTS, cont.
Proxy ARP general description
How does the ProxyARP work ?
On the presented diagram we see two physical segments (two subnet, subnet A
and subnet B) separated by the router. The particular interest are here the
netmasks. Host A has a /16 subnet mask, while Host B and D have /24. It means
that Host A believes that it is directly connected to all of network 172.16.0.0. When
Host A (172.16.10.100) needs to send packet to Host D (172.16.20.200) it will send
ARP broadcast to all devices into the network A to get MAC address of Host D, but
the ARP broadcast doesn’t reach the Host D, as it is behind the router. In this case
the Proxy ARP which is enabled on the FA 0/0 will respond on behalf of Host D with
its own MAC address and IP address of the Host D.
ProxyARP makes the subnetted networks topology transparent to the hosts,

Hosts in different physical segments can communicate each other without setting
default routes.
Note: When Host B (172.16.10.200/24) on Subnet A tries to send packets to

destination Host D (172.16.20.200) on Subnet B, it looks into its IP routing table
and routes the packet accordingly. Host B (172.16.10.200/24) does not ARP for
Host D IP address 172.16.20.200 because it belongs to a different subnet than
what is configured on Host B ethernet interface 172.16.20.200/24.
Functional description
• Proxy-ARP functionality at the Flexi BTS external IP/Ethernet

interfaces enables BTS to forward ARP requests coming from
Next-hop router to the O&M subnet
• Proxy-ARP enables to forward ARP requests from Next-hop
router only to the manually written list of IP addresses, not to
complete subnets!
• Having at least one entry in the list implicitly enables Proxy-
ARP (no license is required)
• One list is supported per IP network interface, VLAN interface
or Ethernet interface
• Proxy-ARP is only supported on a broadcast-type Transport
Network interface
Activation and Configuration
• The ProxyARP (proxyArpIpAddrList) list can be filled with

up to 16 IP addresses per IP interface
• Any IP address can be added to a list, with the following
exceptions:
• 0.0.0.0
• multicast addresses
• broadcast address (255.255.255.255)
• localhost addresses (192.168.254.0 - 192.168.255.255)
• addresses from BTS private subnets
• transport Interface IP addresses of the network element
• Additionally there are following restrictions:
• No duplicate addresses can be configured
• Configured addresses can be from the BTS subnet or from any subnet
that can be routed through the BTS subnet interface
• Configured addresses cannot belong to the transport network (plain or
VLAN).
RAN2083 Use Case #1
One supernet per BTS containing O&M and Transport subnet
directly
connected
Next-hop router
NodeB 10.1.4.0/28
NodeB Supernet
10.1.4.14/28 network
10.1.4.0/29 10.1.4.8/29 FE0/0
Subnet Subnet
O &M C /U
10.1.4.1/29 10.1.4.9/29 00:17:42:13:C2:E4
ProxyARPList
10.1.4.1 The O&M and transport subnets of
BTS are combined in one supernet
10.1.4.2
SSE
10.1.4.2/29
Without proxyARP, static or dynamic routing should be configured in the

next-hop router to reach the O&M subnet 10.1.4.0/29 via the C/U plane address.
RAN2083 Use Case #1, cont.
One supernet per BTS containing O&M and Transport subnet
The O&M and transport subnets of the BTS are combined in one supernet.
The O&M subnet 10.1.4.0/29 and the transport subnet 10.1.4.8/29 are included into
one supernet 10.1.4.0/28.
The next-hop router has the IP 10.1.4.14 with 28 bits netmask. It means that it
believes that is is directly connected to whole
Supernet. When the packet comes to the next-hop router dedicated to 10.1.4.1/29
(M-Plane Agent). Next-hop router will do ARP broadcast to find out the MAC.
Broadcast will reach the NodeB’s external Ethernet interface where the proxyARP is
running. If the requested IP address exists on the list the proxy reply to the next-hop
router with its own MAC.
The main benefit of that solution is that no static or dynamic routing need to be
configured on the next-hop router to reach
The O&M subnet.
This scheme does not support traffic separation between U/C plane and O&M traffic.
RAN2083 Use Case #2
O&M Supernet across several BTSs
11. 129.0.0/ 21
O& M supernet Ip route 11.129.0.0 255.255.248.0 interface FE 0/0
U/ C plane
NodeB
FE0/0
11. 129.0.0/28 10.1.4.0/29
10.1.4. 254/24 M plane
O& M C/ U 10.1.4.1/29
11. 129.0.1/28
NodeB
The O&M and transport subnets are
11. 129.0.16/28 10.1.4.8/29 terminated on the same
next-hop interface, but the networks are splited
O& M C/ U 10.1.4.9/29 and create two independent supernets. The
11. 129.0.17/28 O&M subnets of several BTSs are combined
in one supernet. The second supernet creates
the transport network of BTSs
ProxyARPList
SSE 11. 129.0.17
This Use Case is for those operators which
11. 129.0.18/28 11. 129.0.18 want to have traffic separation, but are not
going to deploy VLANs for M-plane
O&M Supernet across several BTSs
In this usecases the O&M subnets of several BTSs are combined in a single O&M
supernet, which is urelated to the subnet for the U/C plane
Addresses.
To reach the Ip address in the O&M supernet the static route is configured in the router.
Each IP packet to the O&M supernet is sent out via the FE 0/0 interface.
RAN2083 Use Case #3
O&M supernet on separate VLAN
11. 129.0.0/ 17
O& M supernet U/ C plane
10.1.4.6/29
NodeB 2001
C/ U 10.1.4.1/29 10.1.4.14/29
11. 129.0.0/28
11.129.255.254/16 M plane
O& M 4001
M 11. 129. 128.1/17
11. 129.0.1/28
Note: splitting the /16 subnet into
two /17 subnets have to be done carefully.
The IP addresses used for transport at the
NodeB BTS need to be in the 'upper' subnet,
2002
C/ U 10.1.4.9/29 such that the router and the BTSs are
11. 129.0.16/28 directly connected.
O& M 4001
11. 129.0.17/28 M 11. 129. 128.17/17
This use case provides logical traffic
ProxyARPList separation between M-plane and U/C
11. 129.0.17 plane traffic with VLAN support.
SSE
11. 129.0.18/28 11. 129.0.18
No static route on the router is needed. The O&M subnet on VLAN 4001
is directly connected to the router.
O&M supernet on separate VLAN
1. In this use case the O&M supernet and C/U (Transport) supernet are
separated and mapped to different VLANs.
2. The O&M supernet is splitted into two subnets with 17 bits netmasks. Upper
subnet 11.129.128.0/17 is forseen to Transport
purposes and second subnet 11.129.0.0/17 is forseen for O&M.
3. This use case provides logical traffic separation between M-plane and U/C
plane traffic with VLAN support.
4. No routing is needed on next-hop router
Feature performance impact
• The overall amount of ARP messages between BTS and next

hop router will increase.
• There will be ARP messages for each IP address used by the
NodeB, O&M addresses as well as the U/C plane (transport)
addresses
• There are two limitations that can be taken into account:
▪ ARP cache size limit of the NE
• NPGE – 4096 entries
• BTS – at least 128 entries
• Next hop router – depends on the vendor (Cisco, Juniper, etc.)
▪ Bandwidth limitation
• Bandwidth consumed by ARP broadcast
3GTPL IP Features

– ProxyARP in BTS
RAN2071: Synchronous Ethernet
Generation

RU20 and earlier releases
• RAN1708 BTS Synchronous Ethernet introduced SyncE slave functionality to
Flexi BTS in RU20
• No SyncE generation/regeneration in WCDMA BTS was possible until
RAN2071
• Before RAN2071 Sync Out signal from Flexi WCDMA BTS could be based on
(RAN1707 Flexi WCDMA BTS Integrated CESoPSN enabled):
• ToP (forwarding ToP packets to collocated BTS only, not possible to act as
ToP master)
• 1 pps (only in case 1 pps is used as Sync In)
• PDH E1/T1
SYNC OUT SYNC IN
• 2.048 MHz
ToP
or
E1/T1
or
2.048 MHz
or
1 pps
BTS 3G BTS
No SyncE available as Sync Out

RAN2071 Synchronous Ethernet Generation
Introduction
• With this feature a co-located site and/or another chained tail site can be
synchronized via SyncE (e.g. when building Flexi Packet Radio networks).
• The frequency synchronization of the SyncE outgoing signal can be
derived from a number of synchronization sources.
• Synchronization capabilities are improved, by allowing:
– Synchronous Ethernet based synchronization across a few chained WCDMA
BTS nodes,
– A co-located device to be synchronized as well via a SyncE line
NOTE!
Available for
FTLB, FTFB only
(not FTIB)
RAN2071 Synchronous Ethernet Generation
Benefits
• Synchronous Ethernet based synchronization can be

provided across chain sites and to a collocated Ethernet-
enabled site without any external devices.
• With this feature, the co-located or chained BTSs can be
synchronized by using Synchronous Ethernet which
guarantees a high quality synchronization reference.
• The stability of the recovered frequency does not depend on
the network load or network impairments like delay variations.

02 Rn30032en40gla0 Ran Ip Features

Uploaded by

Document Information

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

02 Rn30032en40gla0 Ran Ip Features

Uploaded by

Copyright:

Available Formats

3GTPL IP Features

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

Intellectual Property Rights

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

The following module presents

Objective of this module is to

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

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

• new features in RU30 on top release

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

• new features in RU40 release

– mcRNC 10GE based network connectivity

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

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

Motivation and benefits

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

• 1 Gigabit Ethernet • 10 Gigabit Ethernet

S1-B2 Module #1 Module #2

Backbone Network NetAct

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

OSPF Site Solution

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

BCN-A1 modules (as available since Multicontroller RNC 1.0)

Step S1-A1 Step S5-A1 Step S1-B2 Step S3-B2

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

300m (SR) / 10 000 m

Connector type RJ-45 LC duplex LC duplex LC duplex

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

1x SFP 9x SFP+ 10x SFP 4x RJ-45

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

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

• mcRNC Evolved Site Solution (mcRNC2.0)

• mcRNC VRRP/HSRP Site Solution (new in mcRNC3.0)

• mcRNC OSPF Site Solution (new in mcRNC3.0)

16 RN30032EN40GLA0 ©2014 Nokia Solutions and Networks. All rights reserved.

User plane, Iub Control plane

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

User plane, Iub Control plane

• IP address: Network interface/backplane,

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

• new features in RU40 release

– mcRNC 10GE based network connectivity

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

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

• This feature combines several physical Ethernet interfaces

21 RN30032EN40GLA0 ©2014 Nokia Solutions and Networks. All rights reserved.

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

• Ethernet link aggregation (IEEE 802.1AX-2008) allows the combining of

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

• new features in RU40 release

– mcRNC 10GE based network connectivity

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

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

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

• Benefits for customer

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

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

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

BTS_SW Release : WN5.0 CD2

30 RN30032EN40GLA0 ©2014 Nokia Solutions and Networks. All rights reserved.

• Creating physical loops (e.g. ring or mesh MAC_DA: all “1”s

MAC_DA: all “1”s

31 RN30032EN40GLA0 ©2014 Nokia Solutions and Networks. All rights reserved.

• RSTP behavior is deterministic – for given physical topology

C [s] = D [s] + (2M + N) 0.005 [s]