Slide 1For internal use
For internal use
To be extremely flexible and future-proof
Multiradio BTS from transport perspective is seen as a cluster of
independent co-sited 2G/3G/4G BTS
independence: transport realization can be chosen for each of RAT
separately
co-location: synergies can be re-used (common connectivity,
“multiradio-aware” QoS switching, efficient synchronization
distribution, reduction of O&M effort, …)
Variety of options exist so what we only need to do is…
…to decide what is the best for our network and…
…to engage relevant components:
transport modules (for overview go to here) and SW features
E1/T1, Ethernet (FE/GE)
TDM, PWE3, native IP …and their mixtures!
fully configurable L2/L3 (and mixtures) per plane!
variety of options incl. IEEE1588v2 and SyncEth (*)
(*) and many more: E1, GPS (LMU), 2 MHz, Adaptive Clock Recovery
(PWE3)… cf. here
* © Nokia Siemens Networks Transport topics
For internal use
Basic scenario:
each technology has its own backhaul link
each system module is equipped with transport module which provides
connectivity
interface dimensioning and configuration done per technology
ESMB/C SM
3-sector RF
EDGE/WCDMA/LTE BTS
Multimode SM
Multimode SM
Abis (Dynamic Abis, CESoPSN, Packet Abis): TDM or Ethernet
GSM/EDGE
WCDMA
For internal use
Transport sharing by chaining of system modules
both electrical or optical cabling possible
no formal limitation for length of the chain but…
…each SM in chain introduces small delay and PDV so PSN impairments
may limit the length of chain
physical realizations: daisy chain via Integrated Ethernet
Switching, RP3-1 optical interface, …
relevant features (enabled on “master” system module):
transport sharing WCDMA-LTE (RU40, RL30); GSM combined via
integrated Eth switch
QoS aware switching (RG30, RU30, RL20)
synchronization hub (RG20, RU20, RL30), cf. next slide for
details!!!
ESMB/C SM
3-sector RF
Multimode SM
EDGE/WCDMA/LTE BTS
Multimode SM
(QoS aware!)
For internal use
Basic scenario:
each system module is synchronized on its own…
…e.g. via ToP IEEE1588v2 => in such case each module needs its
own IP/Eth
connectivity and consumes backhaul bandwidth (small but yet) as
well as capacity on timing server (each module seen as a „client”
=> the more clients the more servers)
…or via SyncEth => in such case no bandwidth is consumed in the
backhaul
but SyncEth must be supported by PSN
…or by any other method (see below); and each one has pros and
cons.
Synchronization hub:
sync reference signal is provided to system module where the
feature is enabled (RG20, RU20, RL30) and…
…chained system modules can rely on synchronization distributed by
“the master”, e.g. 2G
PDH line interface
Synchronous Ethernet (FIYB/FIQB)
For internal use
Planning aspects: overview (1/4)
Main planning activities in case of IP/Eth transport are related
to:
bandwidth estimation (CIR definition for traffic shaping
needs)
IP address planning (per plane addressing might be needed depending
on controller addressing concept, i.e. traffic termination
entity)
QoS planning (per plane assignment to L2/L3 QoS classes)
BTS must have configured
* © Nokia Siemens Networks Transport topics
For internal use
Bandwidth estimation:
traffic shaping per technology
in case of multiple system modules per technology: traffic shaping
per system module and avoid oversubscription within
technology
bw per BTS depends on: traffic load, codec used, feature
configuration (header compression, bundling efficiency, …)
IP address:
IP address determines the equipment where given traffic type is to
be terminated
if different planes have different termination points (e.g.
different BSC modules) then different addresses needed per single
BTS
e.g. example below for GSM
BTS
BSC
M-plane
C/U-plane
For internal use
Traffic differentiation on IP layer and on Ethernet layer
example for 2G, applicable for any technology (RG20, RU10,
RL10)
DiffServ Code Points (DSCP) are configurable per traffic type
Ethernet priority bits (IEEE 802.1p) and/or VLAN ID's (IEEE 802.1q)
are used on Ethernet layer like DiffServ markings (DSCP) on IP
layer
Eth
Eth
BTS
IP
BSC
UDP
RTP
UDP
RTP
UDP
PTP
UDP
RTP
UDP
RTP
L2
L1
L2
L1
For internal use
Planning aspects: QoS aspects (4/4)
QoS planning (per technology) helps:
performing „QoS aware” traffic shaping per technology in case of
multiple system modules
performing „QoS aware” handling of traffic served by different
technologies (also throughout PSN!!!)
Aggregated uplink traffic
traffic shaping level <
both BTSs fully protected!!
SLA 1
SLA 2
For internal use
LTE SM as synchronization hub with common backhaul
E1 cables between the System Modules and LTE over ToP
LTE SM provides Ethernet connectivity towards common backhaul
integrated QoS aware Ethernet switching via daisy chaining
ToP
RF
ETH
ETH
ETH
For internal use
To recap
Basic scenario: each module acts on its own towards backhaul
(possible but non-efficient)
Transport sharing fully supported:
efficient synchronization assurance via synchronization hub
controlled by SW features
Multiradio flexibility and advanced site solutions allows handling
even complex setups
(any mixtures of RATs, multiple system modules per RAT, …)
FSMD(E)
ESMB(C)
FSMD(E)
FSMD(E)
FSMD(E)
ESMB(C)
For internal use
For internal use
Various Plug-In modules for different interfaces (E1, T1, Ethernet,
etc..)
FIYB and FIQB for the support of Timing Over Packet and Synchronous
Ethernet
FlexBus© Interface – BTS integrated indoor unit for FlexiHopper
Microwave Radio family
* available in RG20
For internal use
FTIB (RU10 / RL10)
4xE1/T1/JT1, IMA, 3xGE,
full readiness for LTE
I-HSPA ready, Eth Switching, full readiness for LTE
I-HSPA
LTE
LTE
FTOA
2xFlexbus,
SyncEth slave & regeneration, PDH and Packet, Dual Iub, IP
Iub,
E1 cross-connect, Eth switching
full readiness for LTE