3GPP TSG-RAN WG3 #95bis R3-171133

Spokane, Washington, USA, 3rd – 7th April 2017

Agenda Item: 10.14.2

Source: Vodafone
Title: The Disadvantages of Option 3-1 for High Layer Functional Split

Document for: Discussion and Decision

1. Introduction
Following on from last RAN3 #95 meeting in Athens and discussions on CU-DU High Layer Split we
provide a brief analysis of a few of the disadvantages of the Option 3-1 CU/DU Functional Split. These
factors influence or preference for the Option 2 CU/DU functional split.

In this contribution we briefly discuss the following:

 Architectural aspects for simplified network operation

 Network latencies
 Security Implementation
 Support for low latency services
 RLC Uplink buffer size requirements

2. Architectures for Simple Network Operation

Mobile network operators are driven to simplify the network and to drive down the operational (OPEX)
cost of the network. The drive involves the virtualisation of user data handling, signalling and applications
on commodity hardware in as few as possible (probably less than 10) data centres, where hardware can be
maintained inexpensively.

This trend results in the desire to only have “cellular network aware” functionality in the base station site,
and, the datacentres. In between these entities, “cellular UNaware” transport networks can use the latest
Software Defined Network mechanisms to provide reliable and resilient, cost effective connections.

The following Figure 1 which is an extract from S2-172289 [1] , illustrates a network architecture for 5G
RAN and Core for an evolved mobile broadband connection to intERnet.
 MNO DataCenter (DC)
Control Plane Services

N1
N4
N2

Xn-C N3
(R)AN
UE RRM CU UPF DN
N6

DU

Xn messages similar to the X2-AP control plane messages

‘Unprotected’
specified for Release 12 Dual Connectivity “alternative 1A”
locations
are used to configure the PDCP entity in the CU

The user plane traffic over this link is protected by the

radio interface security

Figure 1 Deployment scenario example where control and user planes are separated [S2-172289]

Note that locating the PDCP-U in the data centre does not add latency compared to locating PDCP closer
to the DU. This is because the increase in CU-DU latency is compensated for by a corresponding reduction
in latency on the N3 interface.

Also note that locating the CU in any 3 rd geographic location in between the User Plane Function and DU,
will increase latency as it stops the transport network selecting the optimum route from DU site to UPF
site. This effect will get worse when transmission links fail and the underlying transmission network self-
heals by selecting second or third choice routes.

Providing support for ultra-low latency is one of the key 5G objectives. For ultra-low latency services, the
local (or remote) RRM application can be instructed by the Core Network to use local break-out, e.g. to
intranet based application servers. An example architecture is shown in the following Figure 2.

Figure 2 Evolved Architecture, illustrating Local Break-out

R3-171133 Page 2 of 7
By using the evolved architecture to support both eMBB central breakout for some bearers, and, local
break-out for other bearers, and noting that the base station’s common RRM needs to adjudicate between
the competing demands from different users it is obvious that it is not possible to co-locate the RRM with
both local and central CUs! Hence an architecture where the Control and User planes are separated is
essential.

The consequences of these physical architectures are discussed in the next sections.

3. Control and User Plane Split

Control and User Plane split above the top of the RLC is well documented as Option 2-2 in TR38.801.

However, to date, no contribution has discussed whether Control and User Plane could be separated using
option 3-1. See the following figure.

Figure 3 Could Option 3-1 offer separated control and user plane?

Key Point 1: As Control and User Plane separation is essential for our future network operation,
Option 3-1 must not be selected unless option 3-1 can be demonstrated to support “option 2-2”
style separation of Control and User Planes.

4. Network Latencies
The drive towards small numbers of data centres (which host the CU) per country, and the fact that
deployed optic fibres rarely run in straight lines, mean that the one-way latency between base station site
and data centre can easily reach 5ms (c.f. 1000 km fibre run).

The architecture needs to be adaptable to accommodate total failure of the “first choice” data centre

R3-171133 Page 3 of 7
In case of a failover at the primary datacentre, the base-station would look to a secondary datacentre. The
one-way latency observed between the base-station site and secondary datacentre is approximately 8ms
(c.f. 1600 km fibre run)

The adopted architecture must also be deployable across the operator’s whole group of companies, i.e. it
needs to support emerging markets and sparsely populated countries. At least 8ms one-way latency must
be supported for these cases.

Therefore, the solution has to be resilient to cope with a failover and one-way delay of approximately 8ms.

It has been demonstrated in previous RAN3 contributions [2-4] that option 3-1 is more prone to network
latencies and transmission fluctuations. This option would not work in practice as it would require large
investment in infrastructure upgrade or implementable only on small portion of the network where tight
latencies can be guaranteed.

Key Point 2: Option 3-1 must demonstrate that it can support one-way CU-DU latencies of 8ms
before it can be accepted.

5. Security Implementation
In the current network deployment scenario, conventionally to secure the link between the eNodeB and
the Serving Gateway, an IPSec secure tunnel is established.

Figure 4 Security implementation in current LTE networks

These IPSec Gateways, add CAPEX to the overall network costs and, if not located at the S/P Gateway site,
add to network latencies. Furthermore, IPSec headers reduce the overall payload.

Figure 5 Maximum Transmission Unit illustrating IPSec Headers (based on annex C of TS 23.060)

R3-171133 Page 4 of 7
The proposed evolved architecture, using Option 2-2, provides an added benefit: in this scenario where
PDCP is moved from the basestation to a centralised unit, a PDCP Encrypted Tunnel is set up between the
CU to the DU, thus alleviating the need for expensive and complex IPSec Gateways.

Figure 6 Option 2-2 Architecture with encrypted PDCP User plane from CU to DU

By removing the IPSec Gateway, the headers associated with IPV6 and IPSec in the MTU can potentially be
removed. The new MTU without the headers will now be able to deliver 1422 Bytes of user data, an
increase of 64 bytes of payload.

R3-171133 Page 5 of 7
In the case that the CU is not located at the S/P Gateway site, then IPSec Gateways are likely to still be
required to protect the links from CU to S/P Gateway site.

This would prevent cost reductions, and, reduce the user packet’s MTU.

Key Point 3: unless Option 3-1 supports the latencies needed to reach the data centre, the high
layer CU/DU benefits of IPSec Gateway cost reduction and MTU size increase cannot be realised.

6. Uplink RLC Buffer Size in the UE

The use of dual connectivity with high data rates will require a substantial buffer size in the UE if PDCP
needs to present downlink data packets “in order” to the high layers in the UE. This buffering for downlink
data seems to be needed irrespective of whether option 2 or option 3-1 is in use.

However, for uplink data:

With Option 2, the RLC RTT is low and hence the amount of unacknowledged uplink RLC data
packets that need buffering is low.

With Option 3-1, the RLC RTT is higher (e.g. 2*8 ms higher than for option 2) and hence at high
(“new radio”) uplink data rates, substantial UE low layer buffering is needed for the
unacknowledged uplink RLC data packets.

Key Point 4: Option 2 appears to have less demands on UE low layer memory requirements.

7. Common RAN architecture for E-UTRAN and New Radio

For operational simplicity, efficient performance, and compatibility with the Overall Architecture Option 3,
a common RAN internal Architecture is needed for E-UTRAN and New Radio.

The release 12 Dual Connectivity standards demonstrate the feasibility of this for Option 2. However, no
such study has been done for Option 3-1.

Key Point 5: Common E-UTRAN and New Radio RAN architectures are very important. Option 2 has
been demonstrated to support this. Option 3-1 has not been shown to support this.

8. Summary and Conclusion

The Key Points are copied below

Key Point 1: As Control and User Plane separation is essential for our future network operation,
Option 3-1 must not be selected unless option 3-1 can be demonstrated to support
“option 2-2” style separation of Control and User Planes.

R3-171133 Page 6 of 7
Key Point 2: Option 3-1 must demonstrate that it can support one-way CU-DU latencies of 8ms
before it can be accepted.

Key Point 3: unless Option 3-1 supports the latencies needed to reach the data centre, the high
layer CU/DU benefits of IPSec Gateway cost reduction and MTU size increase cannot be
realised.

Key Point 4: Option 2 appears to have less demands on UE low layer memory requirements.

Key Point 5: Common E-UTRAN and New Radio RAN architectures are very important. Option 2 has
been demonstrated to support this. Option 3-1 has not been shown to support this.

Based on the discussion presented in this document, we propose that for the high layer CU/DU functional
split option 2 is selected and option 3-1 is not selected.

9. References
[1] S2 172289

[2] R3-162991

[3] R3-170595

[4] R3- 170685

R3-171133 Page 7 of 7