Page 184 - ITU-T Focus Group IMT-2020 Deliverables

3 ITU-T Focus Group IMT-2020 Deliverables

C-RAN – The CRAN architecture would need to be able to run both dedicated 4G hardware together with 5G
hardware which is capable of running any RAT including 4G (this is currently possible with 3G and 4G so we
can expect similar options to be available for 4G and 5G). To effect the migration the older hardware in the
CRAN would need to be phased out by connecting it to 4/5G RAT capable hardware. Ideally this would involve
a software configurable fronthaul switch of some kind. In the case where the C-RAN is running CORE/MEC
functions, the hardware must support the virtualization that is currently being used for 4G (likely NFV and
vEPC in a VM). Ideally hardware used for the RATs can also be repurposed for CORE/MEC depending on load
requirements. Software in the CRAN would need to make the special purpose hardware look like general
purpose VM/Container capable devices/OS to allow any third party hardware/OS to populate this special
purpose hardware in the C-RAN without requiring the deployment of additional general purpose hardware
(which cannot easily support RAT at large scales).
Backhaul/IDC – QOS from RAT/Core server/MEC server must be configurable and likewise IPVPN’s (both V4
and V6) must be supported so that different LTE flavours can run overlapping GTP tunnels/addressing while
5G can run whatever new overlapping tunnels (or not) it requires. Likely this means simultaneous existence
of IPVPN’s and SDN. It is likely that a few 10’s of IPVPNs would be required to span the infrastructure which
is not particularly stressful to IPVPN technology (via distributed or central control) although the potential
number of IPV4/V6 addresses and FIB table sizes is of concern if the UE addressing gets exposed throughout
the infrastructure.
DC – The DC hardware must support the virtualization that is currently being used for 4G (likely NFV and vEPC
in a VM) together with whatever is chosen for 5G (Containers etc.). Since the DC already runs LTE COREs (and
MVNO COREs) the software changes required would be mostly to support 5G than to support 4G.

MEC – Where the C-RAN is running MEC functions, the hardware must support the virtualization that is
currently being used for 4G (likely NFV and vEPC in a VM). Ideally hardware used for RAT can also be
repurposed for MEC depending on load requirements. This means it must support both bare metal (for 4G/5G
RAT) as well as VM and Container technology for MEC. Software in the CRANs would need to make the special
purpose hardware appear like general purpose VM/Container capable devices/OS and should not require
special purpose libraries / compilers or OS’s.

Control Hierarchy/Orchestration – Since the 5G control/orchestration is unlikely to be complete or fully
functional or fully trusted while 4G is being moved to a 5G type infrastructure it will be necessary for a manual
OSS approach to operations to co-exist with the early stages of a 5G wireline orchestration system. This
means that the orchestration system will need to learn what the current state of the infrastructure is without
impacting it in any manner. The orchestration and control system would need initially to query the state of
all the components, determine what slices they are assigned to and then at a minimum be able to display the
status of the slices prior to being given any control over the attributes of the slices themselves. In order to
learn (or resynchronize a controller) the concept of a cookie or some form of tags that can be attached to
resources and which can be queried by any OSS or orchestration system would be required. At some point
the orchestration system would need to bring up 5G slices and at that point resources would need to be
taken from the 4G components (antennas through to core processing elements). Initially this would be in the
form of a test done during low traffic times and in low traffic vicinities after which resources would be
returned to 4G, analysis would be performed on the results of the tests and new tests scheduled. Eventually
the 5G network would be turned up permanently and the resources taken from 4G and not returned. The
more quickly and automatically this iterative testing could be done the more quickly and inexpensively 5G
could be deployed.
It is also possible that resources could be moved by an active 5G orchestration system between various 4G
flavours , for example to/from NB-LTE and LTE (prior to any 5G deployments).

178