SELF MANAGEMENT OF COGNITIVE FUTURE INTERNET ELEMENTS

(1)

SELF

‐

MANAGEMENT

OF

COGNITIVE

FUTURE

INTERNET

ELEMENTS

Presenter : Nancy Alonistioti

([email protected] )

(2)

SELF

‐

MANAGEMENT

2

|

Future

Internet

y A complex adaptive organization,

where the involved partners have

conflicting goals and tension to

maximize their gains

y There is a need for new ways to

organize, control and federate

communication systems

y How to govern the increasing

autonomic behaviours in hybrid

communication systems?

|

Cognitive

Cycle

y Cognitive capabilities enable the perception of the network elements environment and

the decision upon the necessary action (e.g. configuration, healing, protection measures

etc.)

y The feedback‐control cyclemodel, (Monitoring‐Decision Making‐Execution) is expected

to be in the heart of Future Internet Elements

y Network elements with cognitive capabilities aim at fast localised decisions and

(3)

FUNCTIONAL

ARCHITECTURE

FI

cognitive

managers

Router Router Router Router Router king Leve l Domain A Domain B Mana gem ent Le vel Operator Policy Repository Network Domain Cognitive Manager Network Element Cognitive Manager NodeB NodeB BTS Cogn itive Leve l

(4)

Defining

autonomic

behaviours

|

The

question

is

to

be

able

to

specify

system

behaviours

combining

y

_Autonomous

_feedback

_control

_loops

y

_And

_overall

_scalability

_and

_stability

_of

_the

_system

|

Self

‐

management

perspective

and

contributions:

y

_Contain

_low

_‐

_level

_control

_loops

_in

_a

_specific

_domain

_(LAN,

small

number

of

cells

in

the

3G

network,

…)

y

Forward

chaining

for

taking

actions

+

learning

loop

for

parameter

tuning

S3 S1 S7 S6 S2 S4 S5 4 C3 C1 C2 C4

(5)

EXPERIMENTATION

OF

SELF

‐

MANAGEMENT

CAPABILITIES:

USAGE

OF

PANLAB

FIRE

FACILITY

|

Goals:

1. Use case : Service adaptation and network reconfiguration based on multi

objective optimisation (e.g., QoS, packet loss, fault, interference etc.)

2. Use Self‐NET prototype results as a basis. Address experimentation based on

the use in diverse platforms and larger scale.

3. Address experimentation for autonomic communications (internal Self‐NET

results and external from FIRE facilities) |

Steps:

1. Agree on the use case and the testbed features from N.K.UoA and Octopus side 2. Build the IPIP Tunneling for the federation of the Self‐NET and Panlab facilities 3. Run manually initial experiments for triggering events and configuration actions

testing

4. Build NECM/NDCM based on PANLAB facility features for the automation of

experiments from N.K.UoA side

5. PII develop Resource Adapters in order to automate testbed resources

reservation

(6)

PANLAB

TOPOLOGY

FEATURES

|

Airspan MicroMAX WiMAX base

station

and

subscriber

stations

is

located

on

the

Octopus

testbed

at

Oulu

(VTT).

y WiMAX operates in FDD mode using 3.5 MHz bandwidth for the DL and UL at

3.5GHz.

|

The

user

traffic

from

the

Self

‐

NET

environment is

tunnelled

using

two

IPIP

tunnels

over

the

Internet

and

rerouted

over

the

WiMAX air

interface

at

the

Octopus

testbed

y _Distributed_Internet_Traffic_Generator_(D_‐_ITG)

|

Self

‐

NET

has

implemented

the

Network

Domain

Cognitive

Manager

(NDCM)

as

well

as

the

Network

Element

Cognitive

Manager

(NECM)

y _Network_‐_Level_(i.e._{WiMAX BS)}_NECM_is_used_for_the_{WiMAX BS}_monitoring

(though SNMP get) and configuration actions (web services API/SNMP GET)

y Service‐Level NECM is used for the Service level monitoring and configuration

actions

y _NDCM_software_is_associated_with_the_NECM_entities

(7)

OCTOPUS

TESTBED

FACILITIES

AND

(8)

NETWORK

TOPOLOGY

AND

IPIP

TUNNELLING

8

(9)

USE

CASE

DESCRIPTION

1. Various types of traffic (Data, VoIP, Video) are introduced to the BS from the

wired interface (DownLink for associated terminals to WiMAX BS) and also through the associated clients (UpLink for associated terminals to WiMAX BS)

2. BS NECM: Measure through SNMP‐GET (using web services), metrics from

WiMAX Base station: UL/DL used capacity, TCP/UDP parameters, number of flows

3. Service Level NECM: Retrieves associated clients perceived QoS (packet loss,

delay, jitter) and the features of the service (VoIP, ftp, video) that service provider(s) offer

4. NDCM: According to the collected monitoring information (step 2 and step3) the

NDCM will

1. Identify faults or optimization opportunities (e.g., high packet loss)

2. “Service‐level (i.e. traffic generator) adaptation” e.g., change data rate, codec of VoIP or

“Network‐level adaptation” e.g., change prioritization is decided

5. Execution

a) WIMAX BS(network level): Change Prioritization to x number of flows (high, low) b) Traffic Generator (Service‐level): Change the codec of x flows

(10)

SERVICE

FLOWS

|

Several

types

of

VoIP

Codecs have

been

used

y G.711.1 (48 kbps), G.711.2 (40 kbps), G.729.3 (8 kbps), G.729.2 (7 kbps), G.723.1

(5 kbps)

|

TCP

and

UDP

flows

are

used

as

background

traffic

|

Different

number

of

VoIP

flows

|

Each

codec

is

tested

on

both

High

and

Low

priority

@

WiMAX BS

side

y The port of the service flow is identify for the high or low priority

| High Priority ports: Port range [9850, 10100] | Low Priority ports: Port range [10101, 10250]

10 PANLAB ‐Self‐NET USE CASE

(11)

DEPLOYED

NETWORK

AND

SERVICE

MANAGEMENT

SCHEME

NECM

Monitor Service Level (Service Features, Client

QoS)

Decision Making

Monitor Network Level (WiMAX BS SNMP GET)

Situation Deduction Identification of High PER

status, High Delay

Change Prioritization of n flows at the WiMAX BS

Change Video Codec of k flows Change Prioritization of n

flows at the WiMAX BS and Video Codec of k

flows

Change Flows Codec (Service-Level

Adaptation)

Change Flows Priority (Network-Level Adaptation) NECM NDCM “M” “D” “E”

(12)

DECISION

MAKING

ALGORITHM

FOR

CONFIGURATION

ACTION

SELECTION

|

Different

type

of

VoIP

flows

traverse

the

network

|

Possible

Actions:

|

Change

ALL

the

flows(Ni)

of

C

i

|

Change

some

ALGORITHM

FOR

CONFIGURATION

ACTION

SELECTION

|

N

_i

Flows

of

codec

C

_i

,

i={G.711.1,

G.711.2,

G.729.2,

G.729.3,

G.723.1}

(14)

DECISION

MAKING

ALGORITHM

FOR

CONFIGURATION

ACTION

SELECTION

5 Service Cost =

∑

(Ni * Wi) i=1 Marginal_Cost = f (Service_Cost) 20, 0≤Service Cost<23 10, 23≤Service Cost<27 5, 27≤Service Cost<33

Marginal Cost = ‐1, 33≤Service Cost<40 ‐10, 40≤Service Cost<50 ‐15, 50≤Service Cost<70 ‐30, 70≤Service Cost<90 5 Adapted_Number_Of_Flows = |Marginal_Cost ‐ ∑ (Ni * Wi)| i=2 Experimental Knolwedge ₁₄

(15)

PERFORMANCE

RESULTS

1/2

Improvement on specific QoS features after the re-configuration actions due to an increase of the packet loss rate of VoIP traffic.

Various Codecs – low Priority Various Codecs – High Priority Number of flows ₄₀ ₄₀ Total packets ₂₉₇₀₄ ₂₉₅₄₉ Average delay _{7.141964 s} _{7.164891 s} Average jitter _{0.015584 s} _{0.015977 s} Average bitrate _{2546.360118 Kbit/s} _{2420.837946Kbit/s} Average packet rate

2777.616579 pkt/s 2454.385064 pkt/s Packets dropped _{2.77 %} _{2.29 %} | G.711.1: 19 | G.711.2: 4 | G.729.2: 5 | G.729.3: 4 | G.723.1: 6

| The change of the VoIP codec between the service provider and the end

user, selecting the G.729.3 codec, reduces the number of the dropped packets (PER 0.042 %)

(16)

PERFORMANCE

RESULTS

1/2

Improvement on specific QoS features after the re-configuration actions due to an increase of the packet loss rate of VoIP traffic.

| G.711.1: 18 | G.711.2: 14 | G.729.2: 5 | G.729.3: 4 | G.723.1: 6 Various Codecs – Low Priority Various Codecs – Low Priority Number of flows ₄₈ ₄₈ Total packets ₂₃₀₀₄ ₂₃₈₁₇ Average delay _{7.409 s} _{7.429 s} Average jitter _{0.019809 s} _{0.0217 s} Average bitrate _{2546.360118 Kbit/s} _{2420.837946Kbit/s} Average packet rate

2262.653902 pkt/s 1892.468659 pkt/s Packets dropped _{25.65 %} _{0.042 %} | G.711.1: 0 | G.711.2: 32 | G.729.2: 5 | G.729.3: 4 | G.723.1: 6

| Reduction of the packet loss rate after the change of the prioritization at

the WiMAX BS

| From low priority to high priority service class

(17)

PII

&

SELF

‐

NET

VIDEO

The video of the PII and Panlab Demonstration is available online....

(18)

EXPERIMENTATION

IN

SELF

‐

MANAGEMENT:

LESSONS

LEARNED

|

Issues/Recommendations:

y Configuration capabilities (e.g., tunneling, service deployment, codecs etc.)

y Interfaces for interacting with the experimental resources

y Overhead in terms of effort from both sides for the experimentation and use case

deployment – minimise learning curve

y Facility that clearly targets/supports Autonomic Communications experimentation (e.g.,

support reconfiguration (real time) in various layers)

|

Added

value:

y Diversity of technologies and infrastructures

y Large scale experimentation capability

y Advanced experimentation results based on multiple metrics

y Justification of research results in “close‐to‐real‐life” conditions

y Building of technical know‐how at various domains

(19)