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

ITU-T Focus Group IMT-2020 Deliverables 2

9.5 Network capability exposure

9.5.1 Description
IMT2020 network is expected to accommodate various services and continues to define requirements for
key service categories, i.e. massive IoT, critical communications, and enhanced mobile broadband,
respectively. To allow the 3rd party to access information regarding services provided by the network
(e.g., connectivity information, QoS, mobility, etc.) and to dynamically customize the network capability for
different diverse use cases within the limits set by the operator, IMT2020 network should provide suitable
access/exchange of network/connectivity information (e.g. via APIs) to the 3rd party.
The operator can provide some basic network capabilities (e.g. QoS policy) to the 3rd party. However, with
the architecture evolution and new features (e.g. separation of control plane and data plane, network slicing
and customize functions on-demand) brought by IMT-2020 network, it is necessary to look into the
requirements and solutions for a common capability exposure framework and new network capabilities.

9.5.2 Requirements
[REQ] The network architecture for IMT-2020 is required to support the unified exposure for network
capability by the IMT-2020 centralized control functions.

[REQ] The network architecture for IMT-2020 is required to support acquiring information
rd
(e.g., network/connectivity information) and allowing the 3 party to access this information.
NOTE 1 – Identify the network information that can be provided to 3rd party ISPs/ICPs to enable more
customized and efficient service provision.
NOTE 2 – For any identified information, provide the mechanism to enable the operator network to acquire
information and to allow the 3rd party to access this information.
[REQ] The network architecture for IMT-2020 is required to support the capability of creating the dedicated
network, i.e., the capability of composing functions on-demand into a dedicated slice, according to the
rd
requirement of the 3 party.
NOTE 1 – It is envisioned to be flexible enough for realizing network components as software components,
and simplifying the process of creating the dedicated network.

[REQ] The network architecture for IMT-2020 is required to support exposure of application registry and
running capability to provide support for running the 3rd party applications.
NOTE – For example, it enables the access to the service close to UE and meets their latency requirements
with respect to the UE. From the above requirements, solutions for this key issue will assume that the next
rd
generation system should be able to expose network capabilities to the 3 party applications located within
the operator domain close to the edge of the network, or outside the operator domain. The network
capabilities which are suggested to take into considerations, but not limited to, are QoS Enforcement,
Charging Control, Congestion Management, Service Chaining, Network slicing capability, and Application
Hosting Close to the Network Edge, etc.

9.6 Authentication and Security

9.6.1 Description
It is foreseeable that the authentication based SIM/eSIM, e.g. AKA (Authentication and Key Agreement), still
will be one of the most important authentication methods in IMT-2020. The current IMT networks leverage
the USIM to access both the IMT network and IMT service network (e.g., VoLTE IMS) by AKA authentication,
which leads to transforming from distributing to centralizing of the generation and storage of the
authentication parameters.
A mass of IoT and M2M devices will access new IMT-2020 network architecture. A large number of devices
requires much lower cost, power consumption, and complexity than smart phones. The current encryption
algorithms, e.g. AES-128, are too complex to these devices. IoT devices are also restricted by the area of
circuit board, so they have low capabilities on computing, storage, communication and battery.

25