an architectural model of underwater network management system

2017. 11. 24

An Architectural Model of

Underwater – Network Management System

특수통신연구센터Special Communication Research Center

Khamdamboy Urunov


2

Abstract

An architectural model

To enable the reliable IoT applications: Low power battery operated devices and different design tradeoffs have to be considered

both in hardware and software implementations.

U-NMS can maintain u-MIB, MO, Object ID, etc.

IoUT can support Service & Device discovery, indeed dynamically change in devices integration

Finally, we should analyze several following factors:

Interconnection legacy NMS based on SNMP

Managed Object and Object ID

The architectural model for U-NMS based on UWASN (Underwater Acoustic Sensor Network)

and using different management protocols


3

Introduction (1/2)


Figure 1. Network management system

NMS elements Which represent the characteristics of Managed devices A collection of information which is organized in hierarchic tree


Network Management System (NMS) Ability of monitoring, management, and optimizing a network

Manager console Something is admin for adjusting whole of the system communication

Manager One of high level performance devices which has the capable of querying any managed device – via polling

Agent A program that is packaged within the network element A piece of software that is bundled with the network device

Device Management Database (DMD) Regularly store and contains standard set of statistical and control values defined from hardware nodes on a

network

Management Information Base (MIB) Collections of definitions which define the properties of the managed object within the device to be managed A collection of information which is organized hierarchically

Object Identifiers (OID) Uniquely identify managed objects in an MIB hierarchy

Managed Object(MO) Represent characteristics of a managed device Represent a physical entity, a network service, or an abstraction of a resource that exists independently of its

use in management

4

Introduction(2/2)



IoT is interconnecting a huge number of devices and various types of protocols

IoT and U-IoT system possible to solve several issues during OID integrations

Managed devices need to be unique and secure in the network

The main difference is constrained management must be lightweight high level and low level API

Problem statements and requirements:

Network Management cannot easily protect of the cloning ID;

The object cannot easy located to the name system;

IoUT system shall able to complain failure recovery between constrained Manager and Agent

5

Related Works(1/2)



Unique number & IANA

U-NMS position in Standard MIB

6

Related Works(2/2)


Figure 2. U-NMS including MIB tree


An identifier can integrate the MO within the MIB

Several candidate protocols for management system like (SNMP, LNMP)

Figure 3. the right side always concerning agent software deployed

The u-SNMP should support manager and agent side (FFD and RFD) devices

7

MANAGEMENT SYSTEM INTEGRATION TERRESTRIAL AND CONSTRAINED


Figure 3. The U-NMS protocol suite


Problem statements: Limited resource for installing high -level protocol (SNMP, LNMP) API

Constrict network and devices

Generated network manager is able to large amount of redundant data

Agent can use limitation memory, CPU, power supplier

Management system is heavy to installment to constrained IoT/Internet of Underwater Things (IoUT) [9]

Difficult to adjust self-configure management in devices

General problem statement – maintain the reporting of only one or limited set failure recovery

Data collection and fail problem in control situation in Underwater Network Protocols and managing possibility

Need to adjust uniqueness when scalable Management system

Time synchronize and localization interconnection manager & agent

8




Following requirements: The U-NMS can require lightweight software for underwater management devices

It might provide self – monitoring local fault detection feature for detection and recovery

This system can support large scale of heterogeneous communication network

That enabler shall support IP-base/Non-IP based communication

This system can support an Object ID (OID) to identify IoUT devices and other possible intelligence devices

This system may maintain MIB and DMD simultaneously

This system can support to retrieve the connection address and log from IoUT devices

This system shall support security communication level between Manager and Agent types (Master and Proxy)

This system shall support mechanism of ensuring integrity which underwater device elements

This system can require several monitoring function to collect, analyzes and exposes information related to the status of a network connected to the interface of the IoT and IoUT devices

9




Underwater network is control by the Manager

Proxy Agent functionality can deploy to Gateway

Clusters need to deploy Master-Agent software

Underwater devices need to install sub-agent software

MO has different value parameters

U-NMS need to dominate whole system configuration customizing program product to build different types of surveillance and monitoring system

10



Figure 4. U-NMS architecture model


Important achievements in the paper is shown below:

1. Analysis of the MIB structure and deploy the private MIB

2. IANA and getting unique number (U-NMS)

3. SMI and ASN.1 for defining the MIB tree

4. More explanation about OID system, legacy ID system and OID interrelation

5. U-NMS and process of manager and agent system

6. OID categories interconnection method into the SNMP or LNMP protocols

7. Underwater management protocol (like u-SNMP) and using this OID system

11

Conclusion

The Unique Reliable Identity System


Thank you for your attention [email protected]

an architectural model of underwater network management system

Education