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

3 ITU-T Focus Group IMT-2020 Deliverables

Action_connectToDC: This action will attempt to establish a secure tunnel to the controller for the named
Data Center. A key exchange is done to obtain a secure connection after which a request is sent for the
DCCapabilities. Since the DC controller may be flexible and able to allocate new resources on demand, the
Capabilities are not hard upper bounds and may have a flexible representation to indicate this. The
Capabilities should list the attachment point names such that correlations can be made to the attachment
point names in the C-RANs and other DC’s or other networks. The Capabilities include server capabilities and
the availability of different packet processing functions (vEPC etc.).

Action_connectToUWave: This action will attempt to establish a secure tunnel to the controller for the
named U or mm Wave network. A key exchange is done to obtain a secure connection after which a request
is sent for the UWaveCapabilities.

Action_createSlice: A Profile needs to be parsed and given a high level integrity check. So the resources
described have to be verified that they in fact exist by name although at this point we are not checking to see
if they are free. Essentially this is an internal representation of a description of a slice in a compiled form.
Action_computeSliceResources: The internal form of the slice is subjected to a computation to see which
resources are free and best suited for this slice. There are many possible optimization goals here and it’s
unclear how ‘bumping’ of resources should be done. This action would need to determine what resources
are needed for fronthaul connections, which CPU’s / Acceleration hardware is required for the RAT(s), check
backhaul capacity both inter and intra C-RAN / DC, check DC/C-RAN resources for CORE/MEC functions. This
is likely the output of a global optimizer of some kind with a goal of minimizing total cost but there are many
optimization goals and methods possible.
Action_computeSliceResourceDelta: The internal form of the slice is subjected to a computation to see which
resources can be added to the slice to increase (or decrease) its capacity while best maintaining some overall
network objective function. For example if we needed to temporarily increase the CORE capacity, or decrease
the RAT capacity such an action could be invoked with the new slice and old slice requirements. The delta
would be computed and then an optimization run to determine how best to address the delta.
An interesting question is how to address the addition of a Virtual Network Operator with its own core to an
existing RAT, or how to address the addition of a dedicated CORE for some users of a RAT. Are these changes
to an existing slice, or are these considered new slices with a shared RAT? These could actually be managed
internally by the slices’ OAM itself or it could be done at a higher layer by the 5G wireline orchestration. How
is this managed today for MVNO attachments to a common 4G eNodeB?
Action_activeSliceResourcesOrDelta: After computing how best to allocate resources or delta resources to
a slice this action would be responsible for taking that action and validating that it has happened correctly.
In the event it is unable the previous state of the slice should be restored. Where possible this action should
be without impact on end users although this is likely very difficult for some cases. An option should be
provided to allow the operation to take place over some time interval so as to minimize impact or wait for
lulls in usage to better mitigate impacts. An antenna may be re-assigned, spectrum changed, fronthaul may
be reconfigured, RAT processing increased or decreased, C-RAN fabric adjusted, CORE processing increased
or decreased, inter/intra C-RAN connectivity increased or decreased, inter C-RAN/DC connectivity increased
or decreased, MEC processing capacity can be increased/decreased or moved.
8.2.4 New “user” defined actions/triggers

This section discusses programmability from the perspective of the operator. Previously we discussed
orchestration actions that are likely required for normal operations however it’s impossible to anticipate all
of the likely cases. In such circumstances it is normal to create a programmatic tool kit to allow extensions
by the user (in this case the network operator). In almost all circumstances such programming environments
involve a set of trigger conditions specified in some Boolean language together with user defined actions.
The orchestration system, together with the various controllers, is responsible for efficiently monitoring the
trigger conditions and when they are met, to launch the set of actions programmed by the user. For example:
ON: $time==10:00:00 EDT && slice(“slice-A”).sector(“name”).activeUEQuantity() >100

DO: userAction3(slice(“slice-A”).sector(“name”).activeUEQuantity());

168