© NOKIA 2022 ALL RIGHTS RESERVED.

RA41320-V-22R2 V0 - S01M02 Ed1 1

© NOKIA 2022 ALL RIGHTS RESERVED.
RA41320-V-22R2 V0 - S01M02 Ed1 2
© NOKIA 2022 ALL RIGHTS RESERVED.
RA41320-V-22R2 V0 - S01M02 Ed1 3
© NOKIA 2022 ALL RIGHTS RESERVED.
RA41320-V-22R2 V0 - S01M02 Ed1 4
<concept> Interfaces and protocols, <section 1> EUTRAN Interfaces

© NOKIA 2022 ALL RIGHTS RESERVED.

RA41320-V-22R2 V0 - S01M02 Ed1 5
<concept> Interfaces and protocols, <section 2> User Plane protocol stack

© NOKIA 2022 ALL RIGHTS RESERVED.

RA41320-V-22R2 V0 - S01M02 Ed1 6
<concept> Interfaces and protocols, <section 3> Control Plane protocol stack

© NOKIA 2022 ALL RIGHTS RESERVED.

RA41320-V-22R2 V0 - S01M02 Ed1 7
<concept> Interfaces and protocols, <section 4> Management Plane and Synchronization Plane
protocol stack

© NOKIA 2022 ALL RIGHTS RESERVED.

RA41320-V-22R2 V0 - S01M02 Ed1 8
<concept> User Plane Protocol Stack,

© NOKIA 2022 ALL RIGHTS RESERVED.

RA41320-V-22R2 V0 - S01M02 Ed1 9
<concept> User Plane Protocol Stack, <section 1> MTU Size Issues

© NOKIA 2022 ALL RIGHTS RESERVED.

RA41320-V-22R2 V0 - S01M02 Ed1 10
<concept> User Plane Protocol Stack, <section 2> Enforcement of smaller MTU size at the User
IP layer

The MTU size used for packets at the user IP layer can be enforced through static or dynamic
configuration of the IP protocol stack SW of the UE. During TCP connection establishment, the
UE informs the peer about its Maximum Segment Size (MSS), so that the MTU size will not be
exceeded.
With one approach, the MTU size of the IP protocol stack in the UE could be configured to a
lower value. There are UE vendor specific settings (e.g. 1400 bytes in Symbian) which support
this idea, but this is not mandated by 3GPP.

In case of IPv6 in the user IP layer, the MTU size at the UE could be set with the Router
Advertisement message that the PDN-GW sends after PDN connection establishment
([RFC4861], section 4.6.4).

Figure illustrates that the MTU size at the user IP layer needs to be reduced to 1394 bytes with
respect to IPv4 in the transport layers (1358 bytes with IPv6 transport).

© NOKIA 2022 ALL RIGHTS RESERVED.

RA41320-V-22R2 V0 - S01M02 Ed1 11
<concept> User Plane Protocol Stack, <section 3> IP Fragmentation and Reassembly

IP Fragmentation and Reassembly of TNL IP layer packets is terminated at the eNodeB at one
end and the SAE-GW at the other end. Any additional fragmentation in the network can be
avoided with setting the MTU size at eNodeB and SAE-GW properly. With IPsec, the same
approach should be applied in order to avoid multiple fragmentation. In this case IPsec packets
are carrying fragments, but are not fragmented themselves. The MTU size (S1-GW_MTU) would
need to be set up to a maximum of 1438 bytes in order not to exceed a value of 1500 for the
Ethernet SDU at the eNodeB. As an example with IPv4 S1-U over IPv4 IPsec tunnel, see Figure.
While this is a well standardized and generic solution, there are potential drawbacks, such as
additional processing delay and throughput degradation due to processing load at the end
points.

Note:
S-GW_MTU=1436 would cause packets with 1437 or 1438 bytes to be fragmented. It would be
more efficient if S-GW_MTU is set to 1438 and one or zero byte padding is used. Figure shows
the fragmentation with packets larger than 1438 bytes.
Flexi Multiradio BTS supports Fragmentation and Reassembly at the TNL IP layer.

© NOKIA 2022 ALL RIGHTS RESERVED.

RA41320-V-22R2 V0 - S01M02 Ed1 12
<concept> User Plane Protocol Stack, <section 4> Ethernet Jumbo Frames

This solution has no impact on user IP layer and a slightly higher transport efficiency. Vendor
specific SDU sizes up to 9000 bytes are possible. On the other hand, it is not standardized and
therefore not generally supported by Ethernet equipment and Ethernet transport services.
eNodeB_MTU and SGW_MTU specify the values which the links must support in order to avoid
fragmentation.

Flexi Multiradio BTS supports Ethernet Jumbo Frames up to 1630 bytes, which corresponds to
an MTU of 1608 bytes.

© NOKIA 2022 ALL RIGHTS RESERVED.

RA41320-V-22R2 V0 - S01M02 Ed1 13
<concept> User Plane Protocol Stack, <section 5> MSS Clamping

With MSS Clamping in the Core Network the Maximum Segment Size (MSS) of a TCP user
connection will be adjusted by a router, so that the size of the respective IP packets will not
exceed the maximum SDU size of the Ethernet backhaul link. This works effectively similar to
enforcing a smaller MTU size at the User IP layer, but is limited to TCP traffic only.

© NOKIA 2022 ALL RIGHTS RESERVED.

RA41320-V-22R2 V0 - S01M02 Ed1 14
<concept> User Plane Protocol Stack, <section 6> User IPv4/IPv6 over LTE transport IPv4

© NOKIA 2022 ALL RIGHTS RESERVED.

RA41320-V-22R2 V0 - S01M02 Ed1 15
<concept> User Plane Protocol Stack, <section 7> User IPv4/IPv6 over LTE transport IPv4/IPv6

© NOKIA 2022 ALL RIGHTS RESERVED.

RA41320-V-22R2 V0 - S01M02 Ed1 16
© NOKIA 2022 ALL RIGHTS RESERVED.
RA41320-V-22R2 V0 - S01M02 Ed1 17
<concept> Mobile backhaul architecture for LTE

Mobile networks are commonly structured and dimensioned with respect to user densities (metropolitan areas vs.
rural areas) and topological requirements (highways, railways, etc.). From transport perspective, the network is
usually partitioned into a Backbone Network and a Mobile Backhaul Network. LTE Backbone Networks are typically
IP/MPLS based. Much greater variety can be found in the Mobile Backhaul Network.
Since the eNodeB supports an IP-over-Ethernet interface, both Ethernet (L2VPN - Carrier Ethernet or IP/MPLS
based) and IP (L3VPN – IP/MPLS based) transport services would be adequate in the Mobile Backhaul Network. Such
a transport service can be delivered by the mobile operator itself (self-built transport network) or by another
operator (leased line service). In both cases, service attributes and parameters are usually stated in a Service Level
Specification (SLS), which in the latter case is part of a Service Level Agreement (SLA). While this makes a big
difference with respect to the operator business case, it will be treated here conceptually as equal.
In many cases, the demarcation point between the Mobile Backhaul Network and the Backbone Network,
implemented by an Edge Router, coincides with the borderline between the unsecure and secure parts of the
network. If IPsec is applied for network security purposes, the Security Gateway (SEG) terminates the IPsec tunnel
IP layer with the eNodeB at the other end. Thus, the SEG may be collocated with the Edge Router. Figure illustrates
the physical view where the Mobile Backhaul Network is further sub-divided into the Access Network and the
Aggregation Network. In many cases, the Access Network is built upon a fiber and/or microwave radio (MWR) based
tree or chain topology, whereas the Aggregation Network uses fiber rings.
The Access Network may be implemented using Ethernet technology natively. For traffic separation and scalability
reasons, the network should be partitioned into VLANs where bridging takes place at intermediate nodes (e.g.
microwave radio hubs).

© NOKIA 2022 ALL RIGHTS RESERVED.

RA41320-V-22R2 V0 - S01M02 Ed1 18
<concept> Mobile backhaul architecture for LTE, <section 1> Mobile backhaul architecture for
LTE – X2 aspect

There is some common misconception with respect to the requirements on the transport
w . w “ ”
would be located close to the base stations. See top figure for Near-End X2 connectivity. This
can be implemented with Ethernet switching or IP routing functions, which implies additional
O . w w w ’
parts of the Mobile Backhaul Network. On the other hand, the S1 transport path should be
optimized for low latency anyhow. X2 latency significantly less than radio link interruption time
’ .
compared to S1 traffic, so the potential for savings is very limited.
Far-End X2 connectivity, see bottom figure, can be built on existing topologies with hub &
spoke. It requires IP routing at the Far-End (Edge Router or Security Gateway) in order to limit
the size of L2 broadcast domains. Also this architecture meets the latency and capacity
requirements analyzed earlier.
It can be concluded that Near-End X2 connectivity is not advantageous for 3GPP Release 8/9/10
LTE network architectures. In particular, direct physical connections between adjacent eNodeBs
are not required.

© NOKIA 2022 ALL RIGHTS RESERVED.

RA41320-V-22R2 V0 - S01M02 Ed1 19
<concept> Intra-LTE Handover, fig 1

Intra- ( O) (“ ”)
(“ ”). w q .W w
data forwarding between Source eNodeB and Target eNodeB will be optimized. Furthermore,
most of the Cplane messages are exchanged directly between the involved eNodeBs, so the
MME processing load will be reduced significantly.
Implications on the Mobile Backhaul Network will be elaborated in the following. In principle, the
considerations apply similarly to both S1 and X2 handover. Since the X2 interface is expected to
be present in many cases, this will be analyzed in more detail. X2 is required for Self Optimized
Network (SON) functionalities. During the handover procedure the radio link is interrupted for a
short moment (60...70ms). Downlink packets arriving at the Source eNodeB will be forwarded to
the Target eNodeB via the (logical) X2 interface until the S1 path has been switched to the
Target eNodeB.

© NOKIA 2022 ALL RIGHTS RESERVED.

RA41320-V-22R2 V0 - S01M02 Ed1 20
<concept> Intra-LTE Handover, fig 2

w B . “ ”
Access Network will be used for both S1 and X2 traffic together. In the first phase (1) of the
handover, the downlink traffic destined to the Source eNodeB fills the normally lightly used
Source eNodeB uplink path (asymmetric user traffic and symmetric backhaul capacity
downlink/uplink assumed). The duration of phase (1) T1 is determined by C-plane processing
(including transport latency) and may be significantly longer than the air interface interruption
time.
In the second phase (2), the Target eNodeB connection may be temporarily congested if many
handovers are taking place simultaneously and downlink packets are already arriving through the
Bw . “ ”
mainly given by the X2 transport latency, assuming S1 latency toward Source eNodeB and
Target eNodeB are almost equal. If congestion occurs packets may be queued (and potentially
QoS aware dropped) at the affected transport node(s). But even if the X2 traffic goes
completely along with S1 traffic
(T2 ~ S1 uplink latency + S1 downlink latency), the probability and duration of such bursts will be
very limited.
As a conclusion, the capacity need for X2 is very small compared to S1. Analysis of the mobility
model resulted in <10% extra capacity.

© NOKIA 2022 ALL RIGHTS RESERVED.

RA41320-V-22R2 V0 - S01M02 Ed1 21
© NOKIA 2022 ALL RIGHTS RESERVED.
RA41320-V-22R2 V0 - S01M02 Ed1 22
 q

<concept> Transport Performance requirements – capacity, fig 1

Cell peak rates will increase dramatically with LTE. This is mainly due to larger available
bandwidth (max 20MHz per cell compared to 5MHz with WCDMA). It should be noted, however,
that HSPA evolution will also bring multi-carrier modes, leveling this advantage at least partly.
Maximum cell peak rates of 150 Mbps downlink (64QAM 2x2 MIMO) and 75 Mbps uplink (64QAM
single stream) are achievable for a 20MHz configuration (ref. [LTE for UMTS], Section 9.2, Table
9.3 and 9.4). Downlink peak rates of 172 Mbps have often been used for marketing purposes,
but are actually not available since the code rate 1/1 is not defined by 3GPP. 64QAM in uplink
requires UE class 5 which is also associated with 4x4 MIMO. Figures on the slide refer to the
more typical configurations with UE class 2 to 4 (downlink 64QAM, uplink 16QAM). It should also
be noted that the cell peak rates are achievable only under ideal air interface conditions, i.e. very
close to the base station (up to 20% of cell range, corresponding to 4% of cell area) and without
interference from other cells.

© NOKIA 2022 ALL RIGHTS RESERVED.

RA41320-V-22R2 V0 - S01M02 Ed1 23
 q

<concept> Transport Performance requirements – capacity, fig 2

As important as the cell peak rate is the cell average capacity. Average downlink cell spectral
~ .5… .7 w
. … .9 w ( 3G 0
bandwidth, ref. [LTE for UMTS], Figure 9.12). It should be noted that this describes the cell peak
capacity under average conditions, not an averaging over time. For further consideration in this
Section, macro cell configurations with a spectral efficiency of 1.7 bps/Hz downlink and 0.7
bps/Hz uplink are assumed which is a good approximation for 10MHz and 20MHz bandwidth.

© NOKIA 2022 ALL RIGHTS RESERVED.

RA41320-V-22R2 V0 - S01M02 Ed1 24
 O

<concept> Transport Performance requirements – capacity, <section 1> Transport Overhead

M-plane (~1Mbit/s) and C-plane (~0.3Mbit/s) capacity requirements are negligible compared to U-plane.
PDCP protocol for user plane data supports Robust Header Compression (ROHC) in order to minimize
the amount of header data transmitted over the air interface. It is designed to improve performance
and is particularly useful for transmitting small amounts of payload data, such as VOIP, where the
amount of payload may be smaller than the header.
Third and fourth generation wireless systems are being designed to support a wide range of services,
including audio and video applications. This service flexibility is achieved by relying on the Internet
Protocol (IP), typically in conjunction with the User Datagram Protocol (UDP) and the Real Time Protocol
(RTP). One major problem with the IP based protocol architectures is the large overhead, which affects
the limited bandwidth of wireless channels. A low bit rate speech application can result in IP packets with
a ratio of 30 bytes of payload to 60 bytes of overhead. RObust Header Compression (ROHC) has been
proposed to compress the protocol headers for packet transmission over a wireless link. To quote from
3095 “B w . w
comparison. Implementation or computational simplicity of a header compression scheme is therefore
.” W
may be reduced by as much as 85%. The overall reduction depends heavily on the size of the payload.
For GSM Voice overall BW is reduced by almost 50%. The saving in overhead varies depending on the
traffic models used.

© NOKIA 2022 ALL RIGHTS RESERVED.

RA41320-V-22R2 V0 - S01M02 Ed1 25
 B

<concept> Dimensioning Based on Air Interface Capacity

“ -Average/Single-Peak" is a reasonable trade-off between user service capabilities and transport

capacity requirements, which may have a great impact on the operating costs. With that approach, advertised user
service peak rates up to the cell peak rate can be momentarily supported in one cell. The advertised user service
rate will be, however, only a fraction of the cell peak rate. It is mainly driven by fixed broadband user experience
(xDSL service rates) and applications and will be enforced by LTE QoS parameters. This also means that multiple
users can be supported with that rate simultaneously. With service differentiation, different maximum rates could
be applied to different users,
i.e. premium users could be served with highest rates. If the number of users is low, transport costs could be
reduced even further if the user service rate will be applied for dimensioning instead of the cell peak rate.

„ - “ -off in general, but it may be under-dimensioned for hot

spots where users are located close to the antenna in multiple cells of the same eNodeB. The practical maximum
of air interface throughput could be achieved under such conditions, adding average capacity of the remaining cells
to the one cell operating with peak rate. As illustrated in Figure 15, this defines the recommended dimensioning
. . “ - ”
concept will always lead to over-dimensioning, thus usually extra costs. However, if fiber is available at eNodeB
sites, the incremental cost impact may be tolerable. So, there will be cases where the operator requires that the
transport sub-system shall be no bottleneck at all.

© NOKIA 2022 ALL RIGHTS RESERVED.

RA41320-V-22R2 V0 - S01M02 Ed1 26
 0

<concept> Dimensioning Based on Air Interface Capacity, <section 1> Dimensioning Example:
All-Average/Single-Peak Throughput 1+1+1/10MHz

Note:
Dimensioning: Max (3 x average rate, peak rate)
M-plane (~1Mbit/s), C-plane (~0.3Mbit/s), X2 U-plane (~30ms bursts) not included

© NOKIA 2022 ALL RIGHTS RESERVED.

RA41320-V-22R2 V0 - S01M02 Ed1 27
 0

<concept> Dimensioning Based on Air Interface Capacity, <section 2> Dimensioning Example:
All-Peak S1 Throughput 2+2+2/20MHz

Note:
Dimensioning: 6 x peak rate
M-plane (~1Mbit/s), C-plane (~0.3Mbit/s), X2 U-plane (~30ms bursts) not included

© NOKIA 2022 ALL RIGHTS RESERVED.

RA41320-V-22R2 V0 - S01M02 Ed1 28
 q

<concept> Transport performance requirements – delay

Nokia recommends the following performance values.

<table>
1) LTE end-to-end PD and PLR requirements for U-plane per QCI are given in [TS23.203]. Allocation to the mobile backhaul section is network
dependent. Average transport PD is assumed 20ms. With higher PD, most user services can be supported, but system capacity may be
decreased due to lower remaining radio Packet Delay Budget (PDB). The transport PLR must be lower than end-to-end system PLR.
2) Required for ±50ppb FDD air interface frequency synchronization based on IEEE1588-2008 (ToP)
3) Upper bound given by X2 HO timer in case of hub & spoke (star) architecture
4) SCTP/TCP operates within a large PD and PLR range, but high values would impact response times. C-plane and M-plane should be handled
equally.
5) U-plane real-time services and IEEE1588-2008 (ToP) should be handled equally.alues (upper bound, one-way).
Delay requirements originate from both user services (U-plane end-to-end delay / delay variation for VoIP, web surfing, file transfer, gaming,
streaming, email, etc.), radio network layer protocols (C-plane) and synchronization (S-plane).

<section 1>U-plane
U-plane delay requirements are determined by user service quality expectations (Quality of Experience –QoE). Popular user services (web
browsing, (large) file download, gaming, messaging, etc.) have very different QoE requirements. Obviously, delay requirements are important for
interactive services. However, there is also a relationship between U-plane delay and throughput performance if the user service is based on
TCP. With respect to LTE system performance, less than 15ms round-trip time (RTT) can be achieved with pre-allocated resources, ~20ms
including scheduling (ref. [LTE for UMTS], Section 9.7). This can be verified with ping delay measurements starting from the UE, where the server
is located near the SAE-GW. In contrast to GSM and WCDMA, the relative contribution of the mobile backhaul delay to the RTT has become
significant and thus should be treated with special care. It is important to note that each 500km one-way distance between a base station and
a usually centralized SAE-GW contribute 5ms to the RTT. This is only taking into account the unavoidable fiber delay (~200,000km/s is the
speed of light in glass). Including the delay introduced by intermediate transport nodes, the transport part of the RTT can easily exceed the
radio part.
With respect to different services and their QoE, 3GPP has defined LTE end-to-end system delay requirements in [TS23.203].
In addition to delay (latency), also delay variation (jitter) has to be considered. Both the LTE air interface scheduler, retransmissions and the
transport network contribute to the end-to-end jitter. Real-time end user applications including VoIP and audio/video streaming are usually
0… 0 . w ioning and in-built
QoS mechanisms have to assure that the end-to-end delay and delay variation budget of supported applications are not exceeded. Note that
during handover, the U-plane delay is larger, thus a short service interruption may occur. In most cases, this will hardly be recognized by the
user.
In principle, the user service related considerations above apply to both S1 and X2. Downlink packets arriving at the Source eNodeB during
handover will be forwarded to the Target eNodeB, i.e. will take a longer route. Basically, implementing X2 latency significantly less than the
radio link interruption time would have no benefit since those packets would have to wait at the Target eNodeB anyway. Most user applications
will tolerate such a very short-term delay increase.
<section 2> C/M-plane
In WCDMA the RNL related latency requirements are imposed by a number of RAN functions over Iub/Iur including Macro-Diversity Combining,
Outer Loop Power Control, Frame Synchronization and Packet Scheduler. In contrast to that, in LTE the transport latency requirements are
mainly driven by user services (U-plane). In particular, most of the handover messaging is performed in the latency insensitive preparation
phase. C-plane protocol timers give implicitly an upper bound for the S1/X2 transport RTT.
<section 3> S-plane
A specific requirement for delay variation (jitter) applies if Precision Time Protocol (PTP) based on IEEE1588-2008, a.k.a. Timing-over-Packet, is
used for eNodeB synchronization.

© NOKIA 2022 ALL RIGHTS RESERVED.

RA41320-V-22R2 V0 - S01M02 Ed1 29
 q

<concept> Transport performance requirements - TCP Issues

The Transmission Control Protocol (TCP) is designed to provide reliable transport for data. Today TCP is used for
80-90% of all packet traffic in the internet. TCP is typically used for applications and their respective protocols
where reliability is important, e.g. web browsing (HTTP), Email (SMTP) and file transfer (FTP). TCP flow control, in
particular its “ w ” w w Q w
Load Time (PLT). The user service data rate contributes inverse-linearly to the PLT, i.e. ’
improve the QoE significantly. On the other hand, the RTT has a linear impact.
For large file transfers, like music, video, SW download, the TCP steady state behavior is more relevant. Without
congestion, a single TCP connection is rate limited by the ratio between the TCP receive window size and the RTT.
Given a standard 64KB TCP receive window size (RFC793), 50ms total RTT (including transport delays) would limit
the achievable service data rate at ~10Mbps for a single TCP connection. This limitation could be mitigated with
multiple concurrent TCP connections and/or enlarging the receive window through TCP Window Scaling (RFC1323)
which is supported by many web servers today. For popular browsers and web sites (average page size <1MB,
multiple concurrent TCP
connections), it can be assumed that most of the web traffic is transferred within the slow start phase, so TCP
Window Scaling will not help that much here.
Last but not least (“ ”)
is low. As a conclusion, the transport network should be designed for low latency.
Perhaps more important in the early days of LTE is the potential impact on cell throughput performance tests
which are often based on FTP. The test set-up has to be planned carefully (using Window Scaling, running multiple
FTP sessions in parallel). Otherwise the transport network could be a bottleneck and distort the test results.
Content Distribution Networks (CDN) do not only reduce the network load but also reduce the end-to-end RTT,
thus having a positive impact on the file transfer performance. For CDN supported services, the mobile network
related RTT will be dominating.

© NOKIA 2022 ALL RIGHTS RESERVED.

RA41320-V-22R2 V0 - S01M02 Ed1 30
© NOKIA 2022 ALL RIGHTS RESERVED.
RA41320-V-22R2 V0 - S01M02 Ed1 31
 Q q

<concept> Quality of Service, <section 1> Quality of Service Requirements

U-plane delay requirements are determined by user service quality expectations. In general, the
w . 3G 5.9 3 ≤5 -way transit time for a
32 byte payload packet from UE to RAN edge node and vice versa. This defines a design target
with respect to LTE system performance rather than a hard limit. In contrast to that, 3GPP
23.401, Appendix B (Table 2), defines end-to-end service related QoS parameters which are
associated with a Quality Class Identifier (QCI) per Service Data Flow (SDF) or per SDF aggregate.
Even though indicated in the table above otherwise, services using the reliable TCP transport 1
layer (e.g. web browsing using HTTP, FTP) may be very sensitive against transport delay. Due to
its acknowledgement mechanism, a single TCP connection is rate limited by the ratio between
the TCP window size and the round trip time (RTT). Given a standard 64KB TCP window size
(RFC793), 20ms RTT would limit the achievable service data rate at ~25Mbit/s for a single TCP
connection. This limitation could be overcome with multiple TCP connections in parallel (typically
the case for web browsing) and/or TCP Window Scaling (RFC1323), but other delay sensitive
behavior (TCP slow start) will still affect the user experience.
Real-time end user applications (e.g. VoIP, audio/video streaming) are typically designed so that
they can tolerate jitter in the order of some tens of milliseconds, using a properly dimensioned
jitter buffer.

© NOKIA 2022 ALL RIGHTS RESERVED.

RA41320-V-22R2 V0 - S01M02 Ed1 32
 Q

<concept> Quality of Service, <section 2> LTE Radio to Transport QoS Mapping

© NOKIA 2022 ALL RIGHTS RESERVED.

RA41320-V-22R2 V0 - S01M02 Ed1 33
<concept> Quality of Service, <section 3> Transport Admission Control

Radio Admission Control (RAC) is in charge of controlling admittance based on resources available for the air
interface. (Information on available radio resources is obtained in C-plane via Radio Resource Management and via
Radio Bearer Management units.)
Transport Admission Control (TAC) is in charge of controlling admittance based on available resources on the
transport network
Transport Admission Control is limited by five major factors which are inherent to the approach and need to be
clearly understood:
• TAC has no information about the traffic situation for any other eNodeB, routers in the transport backhaul
network, nor about core network elements (SAE gateway, MME). It cannot work on a per-route basis, but only
use the information it has available at the eNodeB where it is located.
• TAC makes a decision to accept or reject a connection only at the moment it is requested. For GBR traffic,
information about the expected bit rate is available at this moment, but for non-GBR traffic, there is no
w . “ ”
user behavior as announced at connection set-up time.
• TAC expects that GBR traffic will be handled with higher priority than non-GBR traffic in the transport scheduler
and in the transport network. Non-GBR should be always suppressed there. However, mapping of traffic types
to priorities (DSCP or PCP values) is configured by the operator. Inappropriate assignments may lead to
unexpected behavior.
• TAC is applied to the user traffic only. Other traffic which is not necessarily visible on the air interface, but
provides additional load on the transport network, like for example: Timing over Packet data, must be
considered in the dimensioning of TAC.

© NOKIA 2022 ALL RIGHTS RESERVED.

RA41320-V-22R2 V0 - S01M02 Ed1 34
<concept> Quality of Service, <section 4> Packet Scheduling

© NOKIA 2022 ALL RIGHTS RESERVED.

RA41320-V-22R2 V0 - S01M02 Ed1 35
<concept> Quality of Service, <section 5> Traffic Prioritization

© NOKIA 2022 ALL RIGHTS RESERVED.

RA41320-V-22R2 V0 - S01M02 Ed1 36
© NOKIA 2022 ALL RIGHTS RESERVED.
RA41320-V-22R2 V0 - S01M02 Ed1 37
 w q

<concept> Synchronization via Transport Network , <section 1> Synchronization via Transport
Network requirements

The eNodeB supports two synchronization modes:

• Frequency Synchronized Mode: The frequency of the air interface clock is derived from a
frequency synchronous input signal (e.g. PDH, SyncE, ToP, 2MHz or 1pps/GPS).
• Phase Synchronized Mode: in the phase synchronization mode the air interface frames are
synchronized such that the phase error of the radio interface frames do not exceed the
requirement listed in the table below. Additionally, the Phase synchronized mode includes
the alignment of the System Frame Numbers (SFN) on the air interface, based on Time of
Day information.

Suitable synchronization inputs for the phase synchronized mode are GPS and IEEE1588 ToP
with phase.

As per 3GPP requirement, the air interface at an eNodeB in FDD mode needs to be frequency
synchronized with an accuracy of ±50ppb. In addition, phase (time) synchronization is required
for LTE TDD mode to enable frame timing and uplink-downlink configuration synchronization
across the coverage area. For LTE TDD case, only the phase synchronized mode is applicable.

With the introduction of LTE-A, some advanced features can require for LTE FDD also phase
synchronization. The table below summarizes the requirement for frequency and phase of
special LTE-A features.

© NOKIA 2022 ALL RIGHTS RESERVED.

RA41320-V-22R2 V0 - S01M02 Ed1 38
 q w ( )

<concept> Frequency Synchronization via Transport Network, fig 1

© NOKIA 2022 ALL RIGHTS RESERVED.

RA41320-V-22R2 V0 - S01M02 Ed1 39
 q w ( )

<concept> Frequency Synchronization via Transport Network, fig 2

© NOKIA 2022 ALL RIGHTS RESERVED.

RA41320-V-22R2 V0 - S01M02 Ed1 40
 q w ( .0 )

<concept> Frequency Synchronization via Transport Network, fig 3

© NOKIA 2022 ALL RIGHTS RESERVED.

RA41320-V-22R2 V0 - S01M02 Ed1 41
 w (G )

<concept> Phase Synchronization via Transport Network, fig.1

• Absolute Packet Delay Asymmetry must be nominally zero. Upstream and Downstream traffic
directions must follow the same physical path.
• ADSL or similar asymmetric access technologies are not suitable.
• Jitter/Packet Delay Variation: < +/- 2.5 ms.
• Jitter and traffic load asymmetry must be compensated with IEEE1588 on path support:
IEEE1588 Boundary Clock (BC) behavior supported on intermediate nodes.
• Traffic Priority: IEEE1588 traffic should have the highest priority or at least the same priority as
real-time traffic.
• PTPv2 packets receive expedited forwarding QoS.
• High-priority traffic share of the bandwidth should be 40% or less.
• Number of hops in the phase synchronization chain. In case of Full on-path support, the maximum
number of hops between GMC and Slave should not exceed 20. With Partial on-path support, the
maximum hops is 15.
• Location of Boundary Clocks (BC). IEEE1588 full on path support recommended. In the case that
only partial on path support scenario is possible, certain rules help to identify the location of the
BC behaviors:
• Equipment with 10GE interfaces are considered not to need BC behavior.
• It is possible to have up to 3 hops with 1GE interfaces without BC. This means that in a long
chain of equipment (all of them with 1GE interfaces), one node every 3 should behave as BC.
• Equipment with FE interfaces (or MWR with physical capacity limited to about 100Mbs or less)
need BC behavior
• Packet loss. It should be less than 2%.

© NOKIA 2022 ALL RIGHTS RESERVED.

RA41320-V-22R2 V0 - S01M02 Ed1 42
 w ( )

<concept> Phase Synchronization via Transport Network, fig 2

© NOKIA 2022 ALL RIGHTS RESERVED.

RA41320-V-22R2 V0 - S01M02 Ed1 43
 ( )

<concept> Synchronization Hub

*In case transport module is not in use the output signal is synchronized to eNB OXCO
´
System clock recovery
System clock recovery for the eNB is possible from the following sources:
• PDH interface
• SynchE
• Timing over Packet 1588-2008
• Global Positioning System (GPS)/Pulse Per Second (PPS) external reference clock
Synchronization accuracy
In practice the number of chained eNBs depends on the input signal quality at the first eNB. A maximum of 20 Flexi
system modules can be used if the compensation of propagation delay has been correctly configured in each of
the chained Flexi system modules.
In SyncE networks, SyncE-filtered Ethernet Equipment Clock (EEC) is more reliable than ToP and fulfills Maximum
Time Interval Error (MTIE) limit for E1 (G.823) and T1 (G.824). Therefore SyncE networks use EEC to synchronize PDH
and 2.048MHz interfaces.
Synchronizing PDH and 2.048MHz outputs with eNB OCXO guarantees that potential disturbances caused for
example by ToP (like extensive wander) are filtered appropriately. However, output clock is no longer traceable to
Primary Reference Clock (PRC) in such case.
Hold-over mode
If eNB loses all sync sources, it switches to hold-over mode. Then the eNB OXCO keeps running with the last known
control value and the sync output becomes squelchable.
In holdover mode the 2.048MHz output signal can be squelched ads long as the ext2M048ClkOutOn flag is set to
false. Otherwise, the 1pps output signal is provided also during holdover periods.

© NOKIA 2022 ALL RIGHTS RESERVED.

RA41320-V-22R2 V0 - S01M02 Ed1 44
© NOKIA 2022 ALL RIGHTS RESERVED.
RA41320-V-22R2 V0 - S01M02 Ed1 45
 B

<concept> Nokia AirScale BTS IP Address Model, fig 1

The eNodeB can be configured with separate IP addresses for User, Control, Management and
Synchronization Plane applications.

Configurations where eNodeB applications are bound to virtual addresses are typically used in
scenarios where the transport link (VLAN, IPsec tunnel) shall be terminated with one IP address
while application separation on L3 is also required.

© NOKIA 2022 ALL RIGHTS RESERVED.

RA41320-V-22R2 V0 - S01M02 Ed1 46
 ( )

<concept> Nokia AirScale BTS IP Address Model, fig 2

Address sharing, for example, configuration with the same IP address, is possible. In the simplest
configuration, the eNodeB features a single IP address.

© NOKIA 2022 ALL RIGHTS RESERVED.

RA41320-V-22R2 V0 - S01M02 Ed1 47
 B ( )

<concept> Nokia AirScale BTS IP Address Model, fig 3

Possible data link layer interface types are Ethernet (physical interface) or VLAN (logical
interface)
• RL10 supports one physical interface and max 4 logical interfaces

A physical interface is provided by an Ethernet port, whereas a logical interface is provided by a

VLAN termination. Different interfaces belong to different IP subnets.

© NOKIA 2022 ALL RIGHTS RESERVED.

RA41320-V-22R2 V0 - S01M02 Ed1 48
© NOKIA 2022 ALL RIGHTS RESERVED.
RA41320-V-22R2 V0 - S01M02 Ed1 49
 w

<concept> Transport Security – New Threats

Location of base station changes:

• Traditionally in secure, locked sites
• In future increasingly in public places or homes

Attack methods evolve:

• Better attack tools are widely available
• Higher processing power to break algorithms
• More sophisticated attacks, done by professionals

© NOKIA 2022 ALL RIGHTS RESERVED.

RA41320-V-22R2 V0 - S01M02 Ed1 50
 w

<concept> IPSec with PKI is the Standardized Solution

Relevant 3GPP standards:

•TS 33.210 – Network Domain Security
•TS 33.310 – Authentication Framework
•TS 33.401 – Security Architecture

© NOKIA 2022 ALL RIGHTS RESERVED.

RA41320-V-22R2 V0 - S01M02 Ed1 51
<concept> Asymmetric Cryptography: Public and Private Keys

© NOKIA 2022 ALL RIGHTS RESERVED.

RA41320-V-22R2 V0 - S01M02 Ed1 52
<concept> Digital Certificate Concept

A subject could be any end entity that has an unique identity like:
• People
• Executable programs / SW
• Network elements like Web servers, a LTE Flexi Multiradio BTS …

© NOKIA 2022 ALL RIGHTS RESERVED.

RA41320-V-22R2 V0 - S01M02 Ed1 53
739 B ( . 3)

© NOKIA 2022 ALL RIGHTS RESERVED.

RA41320-V-22R2 V0 - S01M02 Ed1 54
 w

<concept> IP Addressing with IPSec Tunnel Mode

© NOKIA 2022 ALL RIGHTS RESERVED.

RA41320-V-22R2 V0 - S01M02 Ed1 55
 w

<concept> IP Addressing Example with VLAN and IPSec

S-plane binding to interface address is recommended to avoid additional jitter due to IPSec
processing. It is required for on-path support to enable accurate phase synchronization.

© NOKIA 2022 ALL RIGHTS RESERVED.

RA41320-V-22R2 V0 - S01M02 Ed1 56
<concept> Configuration options , <section 1> X2 Star Architecture

© NOKIA 2022 ALL RIGHTS RESERVED.

RA41320-V-22R2 V0 - S01M02 Ed1 57
<concept> Configuration options , <section 2> X2 Mesh Architecture (Not recommended)

E-Line
The mobile backhaul network can be purely based on L2 (Ethernet) transport. Point-to-point Ethernet Virtual
Connections (EVC) between a User Network Interface (UNI) at the eNodeBs and another UNI at the (redundant)
edge router are the straightforward solution. EVC attributes can be well controlled (see [MEF10.1]) and commercial
services are commercially available in many markets, known as E- (“ ”).
scenario each VLAN would identify a individual eNodeB.

E-Tree
Point-to-multipoint Ethernet Virtual Connections (EVC) between UNI at the edge router and UNI at the eNodeB.
Similar to E-Line in that eNodeBs will not be able to communicate directly to each other (traffic separation similar
to point-to-point), but simpler to provision due to common point at the edge router.

E-LAN
As an alternative, the Mobile Backhaul Network could be built based on multipoint-to-multipoint EVCs (E-LAN
service). Most appropriately, eNodeBs belonging to one group should be assigned to one E-LAN (Figure 18). At the
UNI between Mobile Backhaul and Core Network, the VLAN ID identifies an eNodeB group.

© NOKIA 2022 ALL RIGHTS RESERVED.

RA41320-V-22R2 V0 - S01M02 Ed1 58
<concept> Configuration options , <section 3> Architecture Comparison

© NOKIA 2022 ALL RIGHTS RESERVED.

RA41320-V-22R2 V0 - S01M02 Ed1 59
 0 ( ) w

X2 Mesh connectivity with IPsec

© NOKIA 2022 ALL RIGHTS RESERVED.

RA41320-V-22R2 V0 - S01M02 Ed1 60
 0 ( ) w

X2 Mesh connectivity with IPsec

© NOKIA 2022 ALL RIGHTS RESERVED.

RA41320-V-22R2 V0 - S01M02 Ed1 61
CB006114: IPsec for eCPRI M-plane feature (SRAN 21B)
CB007875: IPsec for eCPRI M plane for RUs set two (22R2)

Authentication mode: PKI with vendor certificates

• Encryption/ciphering algorithms: AES-GCM 16 oct ICV with 256 bit key (RFC 5282, RFC 4106)
• Key exchange: Diffie-Hellmann group 20 (384 bit random ECP group)
IP configuration: IPv4 and IPsec tunnel may terminate in an interface or a virtual IP address.
• Supports Automatic IPsec setup
• Supports 5G and 4G eCPRI traffic for SRAN

© NOKIA 2022 ALL RIGHTS RESERVED.

RA41320-V-22R2 V0 - S01M02 Ed1 62
© NOKIA 2022 ALL RIGHTS RESERVED.
RA41320-V-22R2 V0 - S01M02 Ed1 63
© NOKIA 2022 ALL RIGHTS RESERVED.
RA41320-V-22R2 V0 - S01M02 Ed1 64
B

© NOKIA 2022 ALL RIGHTS RESERVED.

RA41320-V-22R2 V0 - S01M02 Ed1 65
© NOKIA 2022 ALL RIGHTS RESERVED.
RA41320-V-22R2 V0 - S01M02 Ed1 66
© NOKIA 2022 ALL RIGHTS RESERVED.
RA41320-V-22R2 V0 - S01M02 Ed1 67
© NOKIA 2022 ALL RIGHTS RESERVED.
RA41320-V-22R2 V0 - S01M02 Ed1 68
© NOKIA 2022 ALL RIGHTS RESERVED.
RA41320-V-22R2 V0 - S01M02 Ed1 69
© NOKIA 2022 ALL RIGHTS RESERVED.
RA41320-V-22R2 V0 - S01M02 Ed1 70
© NOKIA 2022 ALL RIGHTS RESERVED.
RA41320-V-22R2 V0 - S01M02 Ed1 71
W
w w

© NOKIA 2022 ALL RIGHTS RESERVED.

RA41320-V-22R2 V0 - S01M02 Ed1 72
© NOKIA 2022 ALL RIGHTS RESERVED.
RA41320-V-22R2 V0 - S01M02 Ed1 73