ETSI GR mWT 016 V1.1.1 (2017-07)

Applications and use cases of Software Defined Networking (SDN) as related to microwave and millimetre wave transmission

DGR/mWT-0016

General Information

• Status: Published
• Publication Date: 19-Jul-2017
• Technical Committee: mWT - millimetre Wave Transmission
• Current Stage: 12 - Completion
• Due Date: 18-Jul-2017
• Completion Date: 20-Jul-2017

Standards Content (Sample)

GROUP REPORT
Applications and use cases of
Software Defined Networking (SDN) as related to
microwave and millimetre wave transmission
Disclaimer
The present document has been produced and approved by the millimetre Wave Transmission (mWT) ETSI Industry
Specification Group (ISG) and represents the views of those members who participated in this ISG.
It does not necessarily represent the views of the entire ETSI membership.

2 ETSI GR mWT 016 V1.1.1 (2017-07)

Reference
DGR/MWT-0016
Keywords
application, millimetre wave, mWT, SDN,
transmission, use case
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the
print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2017.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.
TM
3GPP and LTE™ are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M logo is protected for the benefit of its Members
GSM® and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
3 ETSI GR mWT 016 V1.1.1 (2017-07)
Contents
Intellectual Property Rights . 4
Foreword . 4
Modal verbs terminology . 4
Executive summary . 4
Introduction . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 6
3 Abbreviations . 7
4 Applications and use cases: overview . 8
4.1 Differentiators of MW/mmW technology . 8
4.2 Considerations on time scale . 9
5 Applications and use cases: description . 10
5.1 Radio link network segment in itself . 10
5.1.1 Introduction. 10
5.1.2 Efficient power consumption . 10
5.1.3 Dynamic traffic distribution . 11
5.1.4 Interference handling . 12
5.1.5 OAM of MW/mmW networks . 14
5.1.6 Automated frequency allocation . 15
5.2 Radio link network segment and one adjacent network segment . 15
5.2.1 Introduction. 15
5.2.2 Adaptive resource allocation in the RAN based on the transmission network status . 16
5.2.3 Adaptive resource allocation in the transmission network based on RAN traffic patterns . 16
5.2.4 Flow-based shaping . 17
5.2.5 Dynamic traffic routing . 18
5.2.6 Efficient power consumption . 18
5.2.7 Self-backhaul . 19
5.2.7.1 Introduction . 19
5.2.7.2 Self-backhaul with mobile access . 20
5.2.7.3 Self-backhaul with fixed wireless access . 20
5.2.8 Fixed Broadband - Wireless to the Home (WttH) . 22
5.2.9 Fixed Broadband - Wireless to the Cabinet (WttC) . 23
5.3 Radio link network segment in end-to-end view . 24
5.3.1 Introduction. 24
5.3.2 Bandwidth on demand . 24
5.3.3 Optimal traffic routing . 25
5.3.4 Network slicing . 26
5.3.5 End-to-end QoS . 28
5.3.6 End-to-end OAM . 28
5.3.7 Service chaining . 29
5.3.8 VPN handling . 30
5.3.9 Synchronization . 30
5.3.10 Security . 32
6 Conclusions . 33
Annex A: Authors & contributors . 34
History . 35

ETSI
4 ETSI GR mWT 016 V1.1.1 (2017-07)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
Foreword
This Group Report (GR) has been produced by ETSI Industry Specification Group (ISG) millimetre Wave
Transmission (mWT).
Modal verbs terminology
In the present document "should", "should not", "may", "need not", "will", "will not", "can" and "cannot" are to be
interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
Executive summary
The present document presents and analyses some use cases for Software Defined Networking (SDN) focusing on the
application of microwave (MW) and millimetre wave (mmW) transmission.
In particular millimetre wave technologies are considered a basic enabler for the future of telecommunication networks,
for both access (5G mobile) and fronthaul/backhaul.
Fundamental aspects of those future networks are performance, flexibility and adaptivity far beyond what is possible
today, with technologies like SDN and Network Functions Virtualization (NFV) providing the prerequisite capabilities.
The need for future mmW radio to coordinate with other transport and access technologies requires that the mmW
ecosystem at least understand the scenarios and use cases in which the equipment will be integrated.
The goal of the present document is to provide an overview of applications and use cases that, leveraging on the SDN
paradigm, are able to add value in terms of functionality, efficiency and/or cost when using microwave/millimetre wave
network segments.
The peculiar characteristics of MW and mmW radio networks are to be taken into account in order to define the specific
use cases and value propositions, which are both pertinent and compelling.
In perspective, an SDN network where a centralized intelligence can make the most of the huge amount of data coming
from the current and past status of the entire network and its applications, will allow for innovative, dynamic and highly
efficient services and operation, to levels not seen before.
ETSI
5 ETSI GR mWT 016 V1.1.1 (2017-07)
Not secondary in this perspective is the promise of SDN to cross over equipment technology, network segment and
vendor boundaries.
It is not in the scope of the present document to enter in any way into discussions about controller architectures,
protocols, information models and implementation details since other specific Standard Defining Organizations (SDOs)
are already in charge of these important issues.
In fact the present document is to be seen as complementary to the work done in other SDOs.
Introduction
The current architecture of telecom and data networks is based on the IP protocol stack, where the routing philosophy is
made of distributed control and hop by hop decisions over single data packets.
This approach is beginning to show some limits in terms of performance, flexibility and scalability due to the
exponential growth of data traffic that has been experienced for some years, in particular with the explosion of the
quantity and quality of applications and terminals that require to be connected.
The requirements on the different traffic types range from high throughput to low latency, from high user density to
high availability, from low power consumption to high reliability. The fulfilment of such a wide variety of requirements
asks for a quite different network architecture, where adaptivity is fundamental.
In order to answer to this necessity several approaches have been proposed in the recent years, having in common the
focus on the programmability offered by software:
• Cloud networking
• Network Functions Virtualization (NFV)
• Software Defined Networking (SDN)
In particular Software Defined Networking is an approach to networking based on the following principles:
• The separation of the data plane from the control plane
• The logical centralization of the control function
The routing philosophy introduced by SDN is based on centralized control able to perform end-to-end decisions over
data flows.
The main concept is to have network elements with just forwarding functions, with on top a central controller which is
able, on one side, to expose an abstracted view of the network resources to the applications and, on the other side, to
allow an automated implementation of services independent from the physical details of the network.
As such this architecture is structured on three basic layers:
• Data plane, made of the different network elements (NEs)
• Control plane, which is the central controller
• Application plane, made of the different applications
The interface between control plane and data plane (SouthBound Interface, SBI) has the goal to allow for standard
protocols to be implemented, two examples being OpenFlow and Netconf; in this way the goal would be to have a
controller which is able to interact with NEs independently from the vendor specificity.
The interface between the application plane and control plane (NorthBound Interface, NBI) has the goal to allow
Application Programming Interfaces (APIs) to be established so that applications can be developed independently from
the particular physical network.
The specific SDN architecture is the object of several SDOs and is out of the scope of the present document. The focus
of this work is to analyse and define use cases and applications in the domain of microwave (MW) and millimetre wave
(mmW) transmission in which the SDN paradigm can be effectively applied.
ETSI
6 ETSI GR mWT 016 V1.1.1 (2017-07)
1 Scope
The purpose of the present document is to provide information on the applications and use cases of the SDN paradigm
as related to MW and mmW transmission.
The analysis covers the following progressively widening ranges:
1) The radio link network segment in itself.
2) The interactions of the radio link network segment with an adjacent segment.
3) The radio link network segment as a part of an end-to-end connection.
Even if going towards a wider network range the relevance of the MW/mmW segment may become less evident,
nevertheless the relevance of SDN is at its highest level when considering end-to-end scope, where the MW/mmW
segment is just a part of the whole picture but anyway requested to be able to adapt to the SDN requirements in order
for services to be efficiently and effectively provisioned.
The classification of applications and use cases in the three aforementioned broad categories reflects a natural layering
in terms of scope width, increasing complexity and increasing value, in terms of cost reduction, enabler for new revenue
streams and enabler of innovations not yet thought of.
It has to be noted that several use cases described in a given network range (and clause) become part of the use cases
described in the wider network range (and following clause) in a sort of recursive and auto-similar behaviour; it is
anyway useful to keep the use case in all the relevant clauses in order to highlight the significant increase in value and
decrease in cost that is achieved by extending the use case from segment towards end-to-end scope.
2 References
2.1 Normative references
Normative references are not applicable in the present document.
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] Open Networking Foundation: "Wireless Transport SDN Proof of Concept White Paper".
NOTE: Available at https://www.opennetworking.org/images/stories/downloads/sdn-resources/white-
papers/ONF_Microwave_SDN_PoC_White_Paper%20v1.0.pdf.
[i.2] Open Networking Foundation: "Wireless Transport SDN Proof of Concept 2 Detailed Report".
NOTE: Available at https://www.opennetworking.org/images/stories/downloads/sdn-resources/technical-
reports/Wireless_Transport_SDN_PoC_White_Paper.pdf.
[i.3] Open Networking Foundation: "Third Wireless Transport SDN Proof of Concept White Paper".
NOTE: Available at https://www.opennetworking.org/images/stories/downloads/sdn-resources/technical-
reports/Third-Wireless-Transport-SDN-Proof-of-Concept-White-Paper.pdf.
ETSI
7 ETSI GR mWT 016 V1.1.1 (2017-07)
[i.4] NGMN Alliance: "NGMN 5G white paper".
NOTE: Available at http://www.ngmn.org/uploads/media/NGMN_5G_White_Paper_V1_0_01.pdf.
[i.5] SDN World Congress 2016: "Enabling 5G network slicing with programmable microwave
transport".
NOTE: Available at http://www.layer123.com/sdn-webcast-mle123.
[i.6] IEEE™: "SDN-based architecture to support Synchronization in a 5G framework".
NOTE: Available at http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=7579504.
[i.7] "Securing the Cloud with SDN".
NOTE: Available at https://www.sdxcentral.com/articles/analysis/securing-cloud-sdn/2016/05/.
[i.8] Recommendation ITU-T G.8275.1: "Precision time protocol telecom profile for phase/time
synchronization with full timing support from the network".
[i.9] Recommendation ITU-T G.8261: "Timing and synchronization aspects in packet networks".
[i.10] Recommendation ITU-T G.8262: "Timing characteristics of a synchronous Ethernet equipment
slave clock".
[i.11] Recommendation ITU-T G.8264: "Distribution of timing information through packet networks".
[i.12] Recommendation ITU-T G.8272: "Timing characteristics of primary reference time clocks".
[i.13] Recommendation ITU-T G.8272.1: "Timing characteristics of enhanced primary reference time
clocks".
[i.14] Recommendation ITU-T G.8273.2: "Timing characteristics of telecom boundary clocks and
telecom time slave clocks".
3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
5G Fifth Generation of Mobile Networks
API Application Programming Interface
ATPC Automatic Transmit Power Control
BC Boundary Clock
BCA Bands and Carrier Aggregation
BMCA Best Master Clock Algorithm
BSS Business Support System (customer facing activities)
BTS Base Transceiver Station
CAPEX Capital Expenditures
CIR Committed Information Rate
CO Central Office
CoMP Coordinated MultiPoint
CPE Customer Premises Equipment
DCN Data Communication Network (management network for telecommunication systems)
DoS Denial of Service
E2E End-to-end
eMBMS evolved Multimedia Broadcast Multicast Service
FTP File Transfer Protocol
FWA Fixed Wireless Access
GM Grand Master
GPS Global Positioning Service
IoT Internet of Things
IP Internet protocol
KPI Key Performance Indicator
ETSI
8 ETSI GR mWT 016 V1.1.1 (2017-07)
LOS Line Of Sight
LTE Long Term Evolution
LTE-A Long Term Evolution - Advanced
M2M Machine to Machine
mmW Millimetre wave
MPLS Multi Protocol Label Switching
MPtMP MultiPoint to MultiPoint
MTBF Mean Time Between Failures
MW Microwave
n/NLOS near/Non Line Of Sight
NaaS Network as a Service
NBI NorthBound Interface
NE Network Element
NFV Network Functions Virtualization
NMS Network Management System
OAM Operation Administration and Maintenance
ONF Open Networking Foundation
OPEX Operational Expenditures
OSS Operational Support System (network facing activities)
PIR Peak Information Rate
PMP Point to MultiPoint
PoC Proof of Concept
PoP Point of Presence
PTP Precision Time Protocol
QoE Quality of Experience
QoS Quality of Service
RAN Radio Access Network
RF Radio Frequency
SBI SouthBound Interface
SDN Software Defined Networking
SDO Standard Defining Organization
SLA Service-Level Agreement
SON Self Organizing Network
SW SoftWare
TDD Time Division Duplex
TTM Time To Market
UL/DL Uplink/Downlink
VLAN Virtual LAN
VPN Virtual Private Network
WttC Wireless to the Cabinet
WttH Wireless to the Home
4 Applications and use cases: overview
4.1 Differentiators of MW/mmW technology
The main peculiarities of the wireless transport networks which differentiate them from other transport technologies (for
example optical and/or packet) are:
1) Dynamic nature of the communication channel, due for instance to interference, rain attenuation, multipath
fading.
2) Huge number of nodes per area to be controlled (scalability). This places an issue on the stability of the
controlled network, since control information has to reach each node avoiding oscillations, information storms
and inconsistencies.
3) Limited time scale of control channel (DCN bandwidth), due to current use mainly for configuration and
monitoring.
4) Street-level peculiarities, for instance multipath, pole oscillations, temporary obstructions, power availability.
ETSI
9 ETSI GR mWT 016 V1.1.1 (2017-07)
5) Low number of functions to be virtualized.
6) Mostly non-redundant paths (tree/chain topologies, usually no rings/meshes), even if innovative traffic
management systems implemented thanks to SDN may make rings/meshes attractive in the wireless backhaul.
7) Spectrum use regulation limits what can be automated in RF planning, automated antenna pointing, etc.
8) Transmission bandwidth impacts power consumption in a very limited way (unless turning on/off a complete
carrier).
4.2 Considerations on time scale
The actions of an SDN controller can be fundamentally grouped into 2 categories:
1) Actions triggered by events happened in the network
2) Actions not directly dependent on a specific network event
In the first case, the main parameters to be considered are:
• Event speed
• Event duration
• Event frequency
The reaction time of the SDN system is dependent on different factors:
• Time for notification to be received by the controller
• Elaboration time in the controller
• Time for command to be received by the network elements
The geographical scope and the bandwidth of the control channel can set in some cases the lower limit to the reaction
time of the controller, depending on the location of the controller and on the technology used for the control channel.
The second type of SDN action is asynchronous from any network event and comprises for example:
• Network (re)configuration
• Provisioning of new services
• Continuous network optimization
In general at least four different time scales can be identified:
1) Events requiring very fast (typically hardware) action on the single NE (e.g. protection switching).
2) Events requiring quite fast (typically software) action on the single link (e.g. adaptive modulation and coding,
ATPC).
3) Events requiring relatively slow (typically software) action (e.g. load balancing due to instantaneous traffic
load and link status).
4) Events requiring very slow (typically software) action (e.g. slow interference events, long-time-scale traffic
patterns).
The capacity of the control plane, the DCN resources and the required time scale of consequent reaction are expected to
restrict the application scope of SDN to events of the last two types, i.e. with a sufficiently long time scale for
notification, elaboration and reaction. As a general reference a discriminating time scale for SDN to be able to
effectively operate is on the order of seconds, whilst sub-second variations are out of SDN scope.
Moreover it has to be highlighted that whenever the NE is able to perform a proper reaction locally on its own there is
no reason for a centralized control system to be involved.
ETSI
10 ETSI GR mWT 016 V1.1.1 (2017-07)
Time scale Functional examples SDN applicability
Very fast Protection switching No
Quite fast (sub-second) Adaptive modulation, traditional ATPC No
Relatively slow (seconds) Dynamic adaptation to link and/or traffic variations Yes
Very slow/static Slow events, configuration, OAM, QoS Yes

5 Applications and use cases: description
5.1 Radio link network segment in itself
5.1.1 Introduction
The use cases of this clause are characterized by the fact that all information and action are contained within the
MW/mmW radio network domain.
There is no coordination with other technologies or other network layers (e.g. the RAN), even if the information about
the status and the events in the mmW radio layer can be made available and used by any other entity in the SDN
ecosystem.
5.1.2 Efficient power consumption
Energy saving is one major goal of both current and future networks.
In addition to specific power-saving mechanisms that can be built in the equipment hardware, more sophisticated
mechanisms and their activation can be devised and controlled by a centralized application, based on deep data analysis
from historical and current network configurations and load conditions.
Such mechanisms can include activation/deactivation of carriers in multi-carrier systems, advanced low-power states
and even intelligent power down of parts of the network (with reconfiguration of the remaining radio network).
As an example consider a high power long haul link made of 4 carriers. Each carrier consumes around 40 to 50 Watts;
overall the 4 carriers consume about 200 Watts. In the case that during night time capacity drops to ¼ of the peak,
150 Watts can be saved. With a traffic profile that looks like:
Time of Day Amount of traffic versus peak
5:00 to 8:00 50 %
8:00 to 10:00 75 %
10:00 to 16:00 100 %
16:00 to 20:00 75 %
20:00 to 24:00 50 %
24:00 to 5:00 25 %
Daily Average 63,54 %
In this case power savings in the order of 36 % can be achieved.
Carrier activation/deactivation in multi-carrier systems triggered by the traffic level has been demonstrated in ONF PoC
of October 2015 under the name "capacity driven air interface" [i.1].
ETSI
11 ETSI GR mWT 016 V1.1.1 (2017-07)
Value
• Save OPEX without impacting service
• Meet energy efficiency targets
• Optimize equipment cost
• Easy target to start working on smart network power consumption
management
Specific needs to be
• Reduce power consumption
addressed
• Reduce equipment wear
Applicability
• Multi-directional hub, multi-carrier/multi-channel radio links
Time scale of events • A few hourly events
Reaction time of SDN
• Tenths of seconds
Specific contribution
• Centralize control of this function, using network-wide data (also across other
to/from SDN
domains) to perform data analysis, prediction and optimize the power-off time
• Easy integration with other transport technologies
Potential
• Repeated power cycling effect on MTBF
issues/problems
• Reliability of the restart process
• Data analysis & prediction algorithm efficiency
Related/dependencies • More comprehensive energy saving schemes at network level (see
clause 5.2.6)
• ONF PoC capacity driven air interface, October 2015 [i.1]

5.1.3 Dynamic traffic distribution
Ring and mesh topologies have not been used very much in the past for MW and mmW networks, mostly due to the
centralized architecture of 2G and 3G networks, where no communication among peripheral sites was required.
Therefore, using ring or mesh topology was only done for geographical network protection, restricting their economic
attractiveness. Due to the flexibility introduced by packet transmission and to the new and increasing connectivity
requirements among peripheral nodes (e.g. LTE X2), ring and mesh topologies are expected to enjoy a new popularity.
Thanks to the automation and the optimization made possible by an SDN system using big data analytics about the
network conditions, mesh architectures could provide the throughput, adaptability and resiliency that are increasingly
demanded from the networks. A significant example is providing small cell backhaul in a dense urban scenario at street
level.
When more than one path exists across the network, traffic can be dynamically distributed over the available links in
order to:
1) Maximize throughput based on link topology and actual capacity as triggered by a variation in traffic.
2) Provide resiliency by reacting to capacity changes (e.g. adaptive modulation), load changes, link interruptions
(e.g. LOS transient blockage at street level), transient interference problems or link failures.
3) Provide synchronization redundancy.
Due to certain mobile access features requirements (e.g. inter-site carrier aggregation, CoMP, etc.), phase/time
synchronization is required. One of the many available options is backhaul networks (including also radio
links) to support the relevant ITU-T Packet Synchronization Recommendations, such as Recommendation
ITU-T G.8275.1 [i.8]. A key to the resiliency of the Precise Time Protocol (PTP) is the Best Master Clock
Algorithm (BMCA), which specifies the way by which each clock determines the best master clock in its
sub-domain out of all clocks it can see, including itself. In case of synchronization failure (e.g. due to a faulty
unit), an SDN controller could make the necessary computations and decide on-the-fly, which should be the
new master clock for a given PTP-aware node (assuming a topology that allows such an action).
4) Provide flow handling (e.g. video distribution/multicast).
Backhaul networks (including also radio links) benefit from multicast connections that are established for
specific type of services, since available bandwidth is consumed in a more efficient manner. Evolved
Multimedia Broadcast Multicast Service (eMBMS) is only an indicative example, in which data is transmitted
from a single source entity to multiple recipients. The nature of such services is not constant, but they should
be available when a group of users (authorized subscribers) initiate the relevant requests to the network. An
SDN controller could decide and apply on-the-fly a multicast connection (service provisioning), when there is
such a need and where (namely, on which radio links) it is needed.
ETSI
12 ETSI GR mWT 016 V1.1.1 (2017-07)
Value
• Save OPEX by establishing automatic:
− network (re)-configuration
− NEs integration (including service provisioning)
− network healing
especially as network density increases
• Make meshing economically convenient even in rooftop-to-rooftop scenarios
Specific needs to be • Enabler for wireless meshing
addressed
• Increase dynamic traffic load management
• Increase network resilience
• Ensure network synchronization, e.g. for specific mobile broadband services
• Handling more granular flows - looking into flows inside the VLAN that
reaches the base station to allow better load balancing and more efficient
service delivery
• Provide additional reliability in harsh scenarios (street level, propagation and
interference effects) thanks to path redundancy and multi-homing
• Gracefully degrade network/service performances in case of node failures
• Use sophisticated algorithms for the slower events
Applicability
• Ring or mesh topologies
Time scale of events
• Fast street level events: milliseconds
• Street level events: seconds/minutes
• Atmospheric events: minutes/tens of minutes
• Topology changes: some events per year, hours
Reaction time of SDN
• Seconds
Specific contribution
• This is a basic building block for more and more sophisticated SON systems,
to/from SDN
exploiting the cross-domain and cross-technology potential of SDN
• Radio planning can be based on complex policies controlled centrally
• Optimize traffic load distribution network-wide
Potential
• Fast events may not allow use of an SDN approach
issues/problems
Related/dependencies
• More comprehensive optimization schemes at network level (see
clauses 5.2.5 and 5.3.3)
• Interference handling (see clause 5.1.4) and radio planning

5.1.4 Interference handling
Interference is a major issue, in particular when considering the densification trend required for the coverage and
backhauling of hot spots and dense urban deployments.
Countermeasures to transient or permanent interference include:
• In frequency domain, re-planning of the RF channel assignments (see clause 5.1.6).
• In digital/algorithm domain, re-configuration of beam-forming antennas (beam-nulling techniques).
• In space domain, adapting traffic distribution (see clause 5.1.3).
• In service domain, adapting some parameters (e.g. CIR and PIR rates for specific flows) to the new conditions.
As an example in MW and mmW links, interference can be dominant when weather conditions degrade one signal, but
not the interfering one.
ETSI
13 ETSI GR mWT 016 V1.1.1 (2017-07)

Figure 1: Interference scenario
In figure 1, the link S1-H1 can suffer from a fade while S2 - H2 does not. In this case during the fade the interference to
H1 can be more dominant than in clear sky.
SDN can mitigate this scenario in different ways:
1) During the fade when the interference is dominant, the SDN controller will temporary reduce the bandwidth of
S1-H1 and S2-H2 by half, each using different half of the spectrum. This will eliminate the interference, and
the temporal capacity will drop by 2. When fade disappears, SDN can return to the original bandwidth
allocation.
2) During the fade at S1-H1, the SDN controller will allocate a temporary channel for the fade duration from a
pool of "spare" channels. This channel will return to the pool when the fade event is gone. The main idea is
that fades do not happen at the same time in all links, so small amount of channels in the pool can be enough.
3) During the fade the SDN controller will command a scanning of the frequency domain in order to select the
best channel (see clause 5.1.6).
It is to be highlighted that regulatory issues (licensing) are a fundamental pre-requisite for the applicability of this use
case.
Value
• Reduce OPEX due to better frequency reuse (no re-planning)
• Reduce OPEX due to less frequent troubleshooting
• Reduce OPEX due to less frequent re-configuration
Specific needs to be
• Use spectrum in the most efficient way (e.g. optimizing a block allocation)
addressed
• Resilience towards interference by same type systems and by heterogeneous
systems (e.g. 60 GHz P2P, WiGig, etc.)
• Fastest rollout of new links, thanks to the automation of the RF coordination
• Better frequency reuse
• Change bandwidth and channel on the fly (regulation permitted)
• More sophisticated algorithms in case of MPtMP deployments
Applicability
• Just in unlicensed or area block licensing regulation
Time scale of events
• Sub-seconds/milliseconds
Reaction time of SDN
• Seconds
Specific contribution
• Automatic frequency channel change to be controlled by SDN at MW/mmW
to/from SDN
network level, using network-wide data to perform data analysis, prediction
and to optimize the channels and the bandwidth
Potential • Regulation
issues/problems
• Fast events may not allow use of an SDN approach (probably smaller SDN
clusters)
• Avoid service impact on adjacent links of the same frequency band
• Challenges of MPtMP deployments/planning
Related/dependencies
• Automated frequency allocation (see clause 5.1.6)
• Dynamic traffic distribution (see clause 5.1.3)

ETSI
14 ETSI GR mWT 016 V1.1.1 (2017-07)
5.1.5 OAM of MW/mmW networks
OAM functions are currently implemented by means of a complex set of proprietary systems (NMS/OSS/BSS). A big
challenge that can be addressed by means of SDN is to coordinate them in order to manage the entire mmW/MW
network, which is usually multi-vendor.
Among the many functions performed by such systems are:
• Fault and alarm management
• Configuration management
• Administration, authentication and accounting management
• Performance management
• Security management
• Inventory management
• Service provisioning
• Troubleshooting and root-cause analysis
• Multilevel network optimization
• User-friendly visualization of network and services
Some of these use cases have been demonstrated in ONF PoC of April 2016 [i.2]:
• Detection and configuration of new MW devices
• Detection and visualization of the configured/currently effective MW network
• Receiving, displaying and storing of alarm information

Value
• Reduce OPEX and CAPEX due to less complex NMS/OSS/BSS architecture
• Less OPEX due to more efficient network management
• Less OPEX due to less frequent and faster troubleshooting (more efficient
collaboration across different technology teams)
• Faster TTM (expedited services provisioning)
• Increase customer satisfaction (quicker services provisioning, reduced time to
resolve issues)
Specific needs to be
• Allow SDN applications to discover and configure the mmW/MW equipment -
addressed
Faster NE integration, acceleration of services provisioning
• Enhanced Inventory management - guarantee that Operations have a correct
and up-to-date picture of the existing network's structure and configuration
• Better quality & quantity of alarms - root cause analysis considering entire
mmW/MW network status
• Intelligent Performance management with relevant KPIs
• Increase operational efficiency and reduce potential for human error
Applicability
• All networks
Time scale of events
• Fault and performance management: many 1 000 events per day
• Most other events: from few to 100s of events per day
Reaction time of SDN
• Strongly dependent from the specific function, existing NMS performance can
be used as a baseline
Specific contribution
• Allow these functionalities to be implemented in truly vendor independent
to/from SDN
fashion
Potential
• Interaction with the NMS to be clarified
issues/problems
• Level of automation, e.g. root-cause analysis algorithm and troubleshooting
actions, software upgrade, etc.
Related/dependencies
• ONF PoC of April 2016 [i.2]
ETSI
15 ETSI GR mWT 016 V1.1.1 (2017-07)
5.1.6 Automated frequency allocation
This use case can be applied to different spectrum allocation scenarios:
1) Block assignment to an operator. In case an operator has an exclusive block allocation, the SDN controller can
be in charge of triggering frequency change within the block in order to minimize interference (e.g. changing
channel on interfered link) and/or to optimize traffic needs (e.g. enlarging channel on congested link).
2) Light licensing assignment. The SDN controller compares the configured channel with the planned channel
(querying an administration/ spectrum provider data base) and in case of mismatch triggers an alarm message
and a frequency change.
3) Unlicensed assignment. In this scenario an SDN controller can be in charge of triggering a frequency change
in order to minimize interference.
This use case has been demonstrated in ONF PoC of October 2016 under the name spectrum management [i.3].
Value
• OPEX saving due to automatic network optimization
Specific needs to be • Self-coordination of radio channel allocations, in order to minimize
addressed
interference and maximise throughput
• Efficiently address temporary situations (e.g. specific or increased coverage
of sporting events, etc.)
Applicability
• All cases where the operator is allowed to self-select the operating channels
thanks to the spectrum licensing scheme
Time scale of events
• Seconds (e.g. transient interference conditions), days/weeks (transient
network/traffic conditions), indefinite (e.g. permanent changes to own or
interfering network)
Reaction time of SDN • It should at least address the longer duration events, fast events (seconds or
below) may be managed by the NE-resident software (SON, etc.)
Specific contribution
• Flexibility, programmability and automation
to/from SDN
Potential
• Network stability, resolution of conflicting needs, interaction with operators'
issues/problems
actions in case of lightly or unlicensed cases
Related/dependencies
• ONF PoC of October 2016 [i.3]
• Interference handling (see clause 5.1.4)

5.2 Radio link network segment and one adjacent network
segment
5.2.1 Introduction
In current mobile networks, the RAN and the backhaul segments work independently from each other. In an SDN
approach a holistic view can be employed with several advantages:
• being aware of backhaul path load and capacity, RAN can distribute its flows in order to pr
...