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

ITU-T Focus Group IMT-2020 Deliverables 2

• Control plane of each NSI is composed of common CP NFIs and NSI specific CP NFIs. Control plane
of a NSI may have no common CP NFIs or no NSI specific CP NFIs;
• Some NSIs may have applications used by end-users. Applications in the NSI are managed by
management plane. And the applications are created from the resource in the slice management
and orchestration level architecture, based on the template or blue print.

• As new services emerge in the future, interconnection model between network functions needs to
allow easy insertion of new network functions while maintaining the existing network function
interconnection path without increasing complexity of the system.

6 Functional architecture of IMT-2020 network

6.1 Design principles

From [b-ITU IMT-O-042] and [b-3GPP TR 22.861], a large number of requirements and principles of IMT-2020
system are identified in order to design a system architecture in terms of evolutionary architecture, vertical
industries’ demand and multiple access, etc. The following principles and characteristics are considered for
the design of IMT-2020 network functional architecture framework:
• Separation of control plane (CP) and user plane (UP) functions, allowing independent scalability and
evolution, where CP dynamically configures UP functions (i.e. activates various operations of the
user plane functions as needed). The IMT-2020 network should support highly scalable distributed
architecture to avoid signalling congestion and to minimize the signalling overhead for diverse
UE/RAT/service requirements. In order to support distributed network architecture, and optimized
routes for application data and signalling data, Control/User-plane functions should be clearly
separated with defined interface;
• Flexible deployment of UP and CP functions, i.e. centralized or distributed;
• Access network (AN) agnostic common core network (CN) design (e.g., AN-CN functional division
and a common interface between them);

• Efficient support of different levels of UE mobility. It is expected that mobility requirements for user
devices will vary depending on the device and/or application types. Many user devices are
stationary, e.g., smart meters and CPE, even in mobile networks while fast handover is a key feature
of most mobile devices and some applications may address the mobility by setting up a new
connection automatically with the help of buffering. Therefore, IMT-2020 should not assume the
same mobility support for all devices and application services but rather provide mobility on
demand only to those that need it.
• Support of services that have different latency requirements between the UE and the Data Network.
In IMT-2020 networks, gateways to a core network can be flexibly located closer to the cell sites,
which will bring a significant reduction on back haul and core network traffic (e.g., with placing
content servers closer to UE, services latency leads to be reduced). Furthermore, The IMT-2020
network should support services that have different end-to-end QoS (data rate, reliability, latency,
location accuracy etc.) requirements. There may be some latency critical applications while there
are others which are tolerant long end-to-end latency.
• Support of network slicing. An IMT-2020 network, as an integrated common core network, will be
flexible enough to support extremely variety of requirements in user devices and application
services. Therefore, the IMT-2020 network is envisioned as a network where multiple logical
network instances tailored to various requirements can be created. Network slicing allows the
operator to provide dedicated logical networks (i.e., network slices) with customer specific
functionality. The architecture shall allow different network configurations in different network
slices. A network slice can span all the domains of network, such as transport network supporting
flexible locations of functions, dedicated radio configurations or specific RAT and core network
dedicated to different types of services. Different types of network slices can be composed of not
only standardized network functions but also some proprietary functions that are provided by
different operators or 3rd parties. Modular function design to enable flexible network slicing is
desirable (e.g., separation of mobility management (MM) and session management (SM) control
functions);

43