R&D연구결과보고서

방송통신산업기술개발사업

SDN/NFV 기술을 이용한 혁신적 IoT 서비스 인프라 상용화 개발

Commercial development of innovative IoT service infrastructure with SDN/NFV technology

쿨클라우드(주)

정보통신기술진흥센터

보고 서식 제 호

연차보고서

사업명 방송통신산업기술개발 과제번호

과제명

국문 기술을 이용한 혁신적 서비스 인프라 상용화 개발

영문

주관기관 쿨클라우드 주 총괄책임자 박 성 용

참여기관

책임자 콘텔라 김찬례 엔텔스 이창섭

총수행기간 년

협약기간 년

해당년도

수행기간 개월

협약기간 총사업비 천원

정 부 출연금

민 간 부담금

현금

계 현물

해당연도 사업비 천원

정 부 출연금

민 간 부담금

현금

계 현물

키워드 개

공통 게이트웨이 서비스 체이닝 시스템 서비스 플랫

폼

정보통신 방송 연구개발 관리규정 제 조에 의거하여 연차보고서를 제출합니다

년 월 일

총괄책임자 박 성 용 인

주관기관장 이 문 임 인

미래창조과학부 장관 귀하

해당 연도 추진 현황

기술개발 추진 일정

계획 실적

일련

번호 개발 내용 추진 일정 개월 달성도

계획수립 및 자료조사

공통 설계

설계

플랫폼 및 설계

공통 기능 구현

기능 구현 플랫폼 및

기능구현

타켓 서비스 설계 타켓 서비스 어플리케이션

설계

통합검증 및 시험

개발내용의 경우 사업계획서 내용에 근거하여 작성할 것

해당 연도 추진 실적

차년도 개발 목표

l 주관기관 쿨클라우드 :

◦ NFV 플랫폼 (NFVI) 설계 Phase-1

§ 오픈스택 기반의 NFV-IoT 요소기술 설계

§ 서비스 체인 매니지먼트를 위한 Neutron 플러그인 확장 기능 설계

§ ODL(Open Day Light) 상호 호완 API 설계

§ 하드웨어 가속화된 NFVI 게이트웨이 설계

◦ IoT-SFC (Service Function Chaining) 제어기 설계 및 개발 (IETF-SFC WG 의 표준에 준하도록) Phase-1

§ VNF 레지스트레이션 그룹별 개별 ( / Function ) 별 기능 설계 및 개발 (Entity Manager)

§ 서비스 체인 매니지먼트 기능 설계 및 개발

◦ SDN 기반 IoT 공통 게이트웨이 설계 및 개발 Phase-1

§ 다양한 네트워크 간 연결을 위한 이종 네트워크 인터페이스를 탑재하며, 이종 네트워크 간 프로토콜 변환 기능을 담당하는 IoT 게이트웨이 설계

§ SDN 연동을 위한 SDN agent 설계 (Openflow, ovsdb)

l 참여기관 1 : 콘텔라 :

◦ IoT VNF GW 기능 항목 분석 및 Architecture 설계

§ NFV 환경에 적합한 NF 기능 분류 설계

§ NFV 환경 운용에 대한 기능 설계

§ NF 에 대한 deployable, Flexible 한 확장을 고려한 설계

§ Agile Communication 을 고려한 설계

◦ 패킷 Classifier & Service Mapper 기능 분석 구현 및 검증 ,

§ IoT 공통 GW 로부터 수신 패킷 분석 기능

§ IoT 공통 GW 로부터 수신 패킷 분배 기능

◦ L2~L3 Layer 패킷 처리 기능 - non-IP 노드들에 대한 IP Mapping 기능설계

및 개발 (Phase -1 )

§ 무선 Interface 종류에 따른 protocol 분석

§ Zigbee IoT 정보 수집 및 전송 기능

§ WiFi IoT 정보 수집 및 전송 기능

◦ CoAP-HTTP Mapping 기능 설계 구현 검증 , ,

§ CoAP 프로토콜 분석 및 Mapping 알고리즘 설계

§ CoAP-HTTP Mapping 처리 기능 구현

§ CoAP Message 유형에 따른 Session 관리 기능

l 참여기관 2 : 엔텔스 :

◦ VNF IoT Manager 기능 설계 (ETSI MANO 표준에 준하도록 )

◦ IoT 오케스트레이터 기능 설계

§ IoT-SFC 제어기 연동 Plug-in 기능 설계

§ VNF IoT Manager 연동 Plug-in 기능 설계 (ETSI MANO 표준에 준하도록 )

§ NFVI 연동 Plug-in 기능 설계 (ETSI MANO 표준에 준하도록 )

§ Catalog 기반 이질적 IoT 서비스 관리 및 연계기능 설계

◦ IoT 단위 서비스별 분석 서비스 체이닝 시나리오설계 매핑 / / (Mapping)

§ SDN 기반 이질적인 서비스간의 체이닝 설계

§ IoT 오픈 플랫폼과 연동하는 단위 서비스별 융합 매핑서비스 설계 /

§ IoT 오픈 플랫폼과 연동하는 단위 서비스별 디바이스 라이프사이클 서비 스 설계

§ Policy 전달

◦ SDN/NFV 기술을 이용한 융 복합 · IoT 서비스 관리 어플리케이션

§ 사용자별 PoC 기능 및 메뉴 정의

§ 사용자별 관리자 소비자 별 ( , ) PoC 설계 및 프로토타입 (Prototype) 구현

개발 목표 대비 정성적 실적

월 말 기준 계획 실적

주요 연구 항목 추진계획서 상 당해연도

개발내용

진도실적

당초 개발내용 대비 개발실적 작성 결과물 정상 추진여부

추진 실적 월

플랫폼 설계

달성도

ü 오픈스택을 이용한 각 서비스별

등 독립적 클라우드 구성 및 플 랫폼 구축 완료

ü 서비스 체인 매니지먼트를 위한 플러그인 확장 기능 설 계 및 개발 생성시 해당 시스템으로 자동 등록 및 해지 기능

소프트웨 어 정상

제어기 설계 및 개 발

달성도

ü 표준에 준하도록 그룹 노드 등록 해지 검색 기능 개 발

ü 기반의 애플

리케이션 개발

ü 기반의 모니터링

기능 설계 및 개발

ü 그룹 등록 해지 검색 기능 설계 및 개발

ü 노드 등록 해지 검색 기능 설계 및 개발

ü 서비스 체이닝 등록 해지 검색 기능 설계 및 개발

ü 하고 최소 홉의 체인 경로를 설정하는 애플리케이션 개발

ü 기반의 서비스 등록 해지 검색 기능 설계 및 개발

소프트웨 어 정상

기능 항목

분석 및 설계

달성도

ü 기능 항목 분석 및 개발 ü 설치 및 기동 관련 검토

및 개발

ü 공통 연동 부분 설계 및 개 발

중간보고 서 정상

패킷

기능 분석 구현 및 검증

달성도

ü 센서와의 패킷 분석 및 기능 개발 및 검증

ü 기동 및 관리

기능 개발 및 검증

소프트웨 어 정상

패킷 처리 기능 노드들에 대한 기능설계 및 개 발

달성도

ü 센서 네트워크와의

통신을 위한 모듈 설계 및 개발

ü 센서와 같은

단말에 대한 기능

개발

ü 센서의 주기 보고 정 보 전달 기능 개발 및 검증 ü 센서의 제어 정보 전달 및

기능 검증

소프트웨 어 정상

기 능 설계 구현 검증

달성도

ü 기능 설계

및 기능 개발

ü 시뮬레이터를 통한 연동 기능 검증

ü 센서 네트워크와의 통 신을 위한 모듈 설계 및 개발

중간보고 서 정상

오케스트레이터 기능 설계

달성도

ü 서비스 체이닝 생성을 위한 배치 기능 설계

ü 서비스 추가 삭제 삭 제 기능 설계 서비스 카테고리 ü 서비스 체인별 단말 및 데이터

수집 통계 기능 설계

중간보고 서 정상

단위 서비스별 분석 서비스 체이닝 시나리오설계 매핑

달성도

ü 조합을 위한 기본 와 서비스 의 서비스 체이닝 시나리오 설계

중간보고 서 정상

기술을 이용한 융 복합 서비스 관리 어 플리케이션

달성도

ü 스마트홈을 주제로한 구현 ü 오픈플랫폼 연계를 통한

데이터 수집 및 에 의한 자 동 제어 기능 개발

ü 단말 현황 및 제어 현황 통계 기 능 개발

소프트웨 어 정상

개발 내용 및 범위

l 주관기관 쿨클라우드 :

◦ NFV 플랫폼 (NFVI) 설계

§ 오픈스택 기반의 NFV-IoT 요소기술 설계

오픈스택 기반 플랫폼

< NFV >

§ 서비스 체인 매니지먼트를 위한 Neutron 플러그인 확장 기능 설계

­ VNF 노드 관리 기능 개발 및 Neutron API 확장 기능 정의 (VNF 생성 삭 / 제 수정 및 구현 / )

­서비스체인 관리 기능 개발 및 Neutron API 확장 기능 정의 서비스체인 ( 생성 삭제 수정 및 구현

(SFC) / / )

­ IoT 서비스별 서비스 체인 Policy 적용을 위한 Neutron API 확장 기능 설계 및 정의 서비스체인 적용 해제 수정 및 구현 ( / / )

­ SFC 표준에 준하는 호완 Neutron API 기능 설계 * 변경 사유 : ( 설계 과정에서 ODL 과의 연관성이 부족하여 , SFC 표준에 준하도록 수정 )

­자동 VNF 시스템 등록 해지를 위한 NOVA API 확장 기능 설계 및 구현

그림 2 NFVI 시스템 + IoT-SFC SDN Controller 아키텍쳐

상기 그림은 NFVI 시스템과 IoT-SFC SDN Controller 의 전체 아키텍쳐 로써 본 연구팀은 , VNF 와 서비스 체이닝 관리를 위해서 Neutron Server 의 SFC Plugin 을 설계 및 개발 하였고 이 과정에서 , VNF 가 SFC-IoT 시스 템에 자동 등록되도록 하기 위하여 NOVA Plugin 을 추가 설계 및 개발 하 게 되었다.

그림 3 nova 커맨드를 활용한 VNF 시스템 확인

사용자는 상기 그림과 같이 nova 시스템을 통해 VNF 의 상태를 관리

할 수 있다 기존의 . NOVA, Neutron 의 경우는 VNF 와 서비스 체이닝에

대한 개념이 존재하지 않기 때문에 이를 위해 본 연구팀은 , Name 에 VNF

의 그룹 정보를 포함하도록 하였다 이를 통해 . VNF 가 완전히 생성된 후

에는 Kulcloud Nova plugin 을 통해 해당 VNF IoT-SFC 시스템에 등록하게

된다 이를 통해 사용자는 . VNF 를 통한 서비스 체이닝을 설정할 수 있게

된다 초기 과제 설계 시에는 . VNF 생성과 등록의 자동화를 고려하지 않았 으나 시장의 흐름에 따라 자동화 기능을 추가 개발하였다 , .

그림 4 SFC-IoT CLI를 통한 VNF 그룹 관리 확인

이를 위한 IoT-SFC SDN Controller 의 확장 API 들은 다음과 같다 . l VNF Group API

의 그룹을 관리하기 위한 로써 사용자는 개별 를 서비

- VNF API , VNF

스 체이닝에 정의하는 것이 아니라 , VNF 그룹만을 리스트로 정하고 해당 , 그룹 내에서 최적의 노드를 설정하는 것은 애플리케이

VNF VNF SDN-IoT

션이 수행한다 이를 통해 . , VNF 그룹 안에서의 Fail-over 를 관리할 뿐만 아니라 로드 밸런싱과 , auto scale in-out 을 위한 기본 기능을 제공할 수 있다.

l VNF API

개별 를 관리 하기 위한 로써 를 특정 그룹에 등

- VNF API , VNF VNF

록 해지 하는 기능을 수행한다 이를 위한 기본 변수로써는 해당 / . VNF 가 연결되는 Openflow 스위치의 input/output 포트를 변수로 갖는다 그리고 . , 애플리케이션은 해당 스위치와 포트 정보를 기반으로 경로 계산 SDN-IoT

및 서비스 체인 구성을 수행하게 된다.

l VNF Service API

본 연구팀은 서비스별 마다 차별화된 서비스체이닝을 제공하는 것을 -

주된 목적으로 한다 이를 통해서 네트워크 자원의 효율적인 관리를 제공 .

할 뿐만 아니라 , IoT 서비스 마다의 서로다른 네트워크 자원 관리가 가능

해진다 서비스 마다의 구분자는 현재는 서비스 마다 유니크한 . VLAN ID 를

갖게 되고 사용자는 , VLAN ID 를 기반으로 서로다른 서비스 체인을 구성할 수 있게 된다.

l VNF Service Chain API

서비스 체인 는 각 개별 마다 서비스 마다 서로 다른

- API IP / (VLAN)

서비스 체이닝을 제공할 수 있는 기능을 제공한다 사용자는 서비스 체인 . 의 리스트를 VNF 그룹의 리스트로 구성하게 되고 해당 체인을 개별 , IP/

서비스에 적용하게 된다 이렇게 적용된 뒤에는 자동으로 에러 감지 및 복 . 구 기능을 수행하도록 한다 사용자는 새로운 서비스 체인을 구성할 필요 . 가 있을 경우 다시 설정만 하게 되고 바로 새로운 서비스 체인을 구성하 , 게 된다 만약 체인을 서비스에 새로 적용할 시에는 기존 서비스가 적용된 . 모든 서비스 체인이 삭제되고 새로운 체인을 재구성하게 된다.

l VNF APIs 상세 내용 (a) VNF Group API

(a-1) Add network function w request

w data

w response

(a-2) Delete network function w request

Method URL POST /1.0/nfv

Type Params Values

POST POST POST POST POST

group_name nfv_name dpid in_port out_port

String String String String String

Status Response

success

fail

Method URL

DELETE /1.0/nfv/{group_name}/{nfv_name}/{dpid}/{in_port}/{out_port}

w response

(a-3) Get specific network function virtualization group w request

w response

Status Response

success

fail

Method URL

GET /1.0/nfv/group

Status Response

success

{

"group_name":

<group_name>,

"nfvs":

[ {

"nfv" :

<nfv_name>,

"dpid" :

<dpid>,

"in_port" :

<input interface>,

"out_port" :

<output interface>

} ] } ]

group_name

nfv_name

dpid

intput_interface(int) -

output_interface

fail

(b) VNF APIs

(b-1) Add network function virtualization group w request

w data

w response

(b-2) Delete network function virtualization group w request

w response

(b-3) Get network function virtualization service w request

w response

Method URL

POST /1.0/nfv/group

Type Params Values

POST group_name

String

Status Response

success

fail

Method URL

DELETE /1.0/nfv/group/{group_name}

Status Response

success

fail

Method URL

GET /1.0/nfv/service

Status Response

success

{

"service_name":

<service_name>,

"vlan":

<vlan_id>,

]

service_name

vlan_id

fail

(c) VNF Service APIs

(c-1) Add network function virtualization service w request

w data

w response

(c-2) Delete network function virtualization service w request

w response

(c-3) Get network function virtualization service chain w request

w response

Method URL

POST /1.0/nfv/service

Type Params Values

POST POST

service_name vlan

String String

Status Response

success

fail

Method URL

DELETE /1.0/nfv/service/{service_name}/{vlan_id}

Status Response

success

fail

Method URL

GET /1.0/nfv/service/chain

Status Response

success

{

"host_ip":

<host_ip>,

"dpid":

<dpid>,

"nfvs":

[ {

"nfv_group" :

<nfv_group_name>,

"nfv" :

<nfv_name>,

(d) VNF Service Chain APIs

(d-1) Add network function virtualization service chain w request

w data

w response

"dpid" :

<dpid>,

"in_port" :

<input interface>,

"out_port" :

<output interface>

} ] } ]

dpid

host_ip

nfv_group_name

nfv_name

dpid

intput_interface(int) -

output_interface

fail

Method URL

POST /1.0/nfv/service/chain

Type Params Values

POST POST POST POST POST POST POST POST POST

dpid service host_ip nfv0 nfv1 nfv2 nfv3 nfv4 nfv5

String String String String String String String String String

Status Response

success

fail

(d-2) Delete network function virtualization service chain w request

w response

§ 하드웨어 가속화된 NFVI 게이트웨이 설계

­ IoT 게이트웨이와 NFVI 게이트웨이 간 터널링 및 서비스 체인 맵핑 기 능 설계

­오픈스택 Neutron 과의 연동을 위한 L3 플러그인 확장 기능 설계 및 정 의

Method URL

DELETE /1.0/nfv/service/chain/{dpid}/{service_name}/{host_ip}

Status Response

success

fail

◦ IoT-SFC 제어기 기능 설계 및 개발

§ VNF 레지스트레이션 그룹별 개별 ( / Function ) 별 기능 설계 및 개발 (Entity Management)

그림 5 IoT-SFC Contrller 아키텍쳐

§ 서비스 체인 매니지먼트 기능 설계 및 개발

­ Loop-free 한 최적의 경로 설정 기능

그림 6 레거시 장비 사용시의 Loop 문제

기존의 레거시 장비의 경우 , Loop free 의 정책 구성이 불가능함 이를 .

위한 Tag 프로세싱이 요구됨 이에 따라 본 과제에서는 기존의 프로토콜 .

재 사용이 가능한 VLAN 기반의 헤더 프로세싱을 제안함 .

­ VLAN Swap 기반의 헤더 프로세싱 정의 및 핸들링 애플리케이션 개발 변경 사유 등 다수의 헤더가 제안되고 있지만 아직 표

* : ( SCH, NSH ,

준이 제대로 이루어지지 않고 이를 위해서는 , SCH/NSH 등을 인지 가능 한 특정 VNF 도 따로 개발 되어야 함 이런 불편의성으로 많은 프로젝 . 트들이 VLAN 또는 VXLAN 과 같은 기존 헤더를 활용한 방법을 사용하 고 있고 본 기관도 이에 맞게 수정이 필요 , )

그림 7 VLAN 기반의 헤더프로세싱 과정

본 연구팀의 VNF 시스템의 각 VNF 들은 독립적인 그룹 도메인을 갖게 됨 그리고 각 그룹 도메인의 맵핑의 오픈스택 기반의 . VNF 시스템에 의해 생성 시 에 필드 값을 통해서 할당 받게됨 공통 를 통해서

VM NAME . GW

트래픽이 NFVI 시스템으로 인입 시 트래픽에 설정된 서비스 체인 룰에 ,

따라 독립적인 , VLAN Swap 정책을 가지게 됨 .

그림 8 VLAN Swap 정책 설정 알고리즘

의 정책은 노드를 거쳐갈 때 을 수행하게 됨 이

VLAN Swap VNF Swap .

를 통해 서비스 체이닝 과정에서 , Loop 이 있는 상황에서도 체인의 경로 지점을 VLAN 기반으로 트랙킹 가능하기 때문에 체인 구성이 가능해진다 , . 상기 그림은 Chain : FW-->LB-->COAP-->UDP 를 거쳐가는 상황의 예로써 , 과정이 각 를 거쳐가는 과정에서 발생한다 그림

VLAN SWAP VNF . (

참조 Algorithm 1 )

­서비스 체인 에러 자동 감지 및 복구 시스템 설계

그림 9 서비스 체인 에러 자동 감지 및 복구 시스템

그림 10 서비스 체인 장애 감지 및 복구 알고리즘

본 연구팀의 서비스 체이닝 시스템은 표준에 준하여 VNF 그룹 관리 기 능을 제공하고 있다 이는 그룹 단위의 관리를 통해 특정 그룹에 속하는 . 노드가 장애 발생시 다른 노드로의 마이그레이션이 가능하도록 한

VNF ,

다 상기 그림은 . Chain : FW(H1)-->LB(H3)-->COAP(H5)-->UDP(H7) 으로 구성된 환경에서 H1 VNF 노드에 장애가 발생시 동일 기능을 수행하는 H2

노드로 마이그레이션 되는 과정을 보여준다 링크 시

FW VNF . fail , SDN

제어기의 Topology manager 를 통해 감지가 되면 , 해당 정보는 NFV 로 전달되게 된다 이와 동시에 모듈은 새로운 경

Resource Manager . PCE

로들을 계산하게 되고 , NFV Resource Manager 는 Service Chain Rule 에게 새로운 서비스 체이닝 구성을 요청하게 되고 모듈을

Manager , PCE

통해서 다시 새로 할당된 FW(H2) 노드로 경로 구성을 하게 된다 .

­시그니처를 (VLAN) 기반으로 특정 트래픽에 대한 서비스 체이닝 적용을

위한 기능 설계

그림 11 서비스 레벨 매니지먼트

본 연구팀의 서비스 체이닝 시스템은 표준에 준하여 서비스 레벨 관리 기능을 제공하고 있다 이는 서비스 레벨별 차별화된 서비스를 제공하는 . 것을 목적으로 한다 예를 들어 재난망 센서와 같이 긴급한 센서를 통한 . , 데이터와 제어 명령의 경우는 Premium 서비스 체이닝 구성을 통해서 항 상 연결을 보장해 주고 무인 카메라와 같이 긴급도는 떨어지지만 트래픽 , , 의 다수 사용하는 서비스의 경우는 Normal 서비스 체이닝 구성을 통해서 다른 IoT 네트워크 쪽으로의 간섭을 최소화하는 식의 서비스별 체이닝 구 성이 가능하도록 한다 이를 위한 기반 기능으로는 공통 . GW 에서 간단한 기능을 제공하는 것을 기반으로 한다 이를 위해 본 연구팀은 와

DPI . GW

시스템 간의 기반의 고유 프로토콜을 사용하게 함으로써 이를

NFVI UDP ,

통해 차별화된 서비스가 가능하도록 한다.

그림 12 PCRF 기반 차별화된 서비스 예시

­다수의 동일 VNF 그룹에게 트래픽을 전달하기 위한 링크 어그리게이션 , 및 로드 밸런싱 기능 설계

그림 13 LAG를 활용한 VNF 그룹 관리 기능 설계

현재의 시스템은 VNF 그룹 관리를 수행하고는 있지만 LAG(Link 를 제공하지는 않는다 좀 더 발전된 시스템을 제공하기 위해 Aggregation) .

서 본 연구팀은 각 그룹별 링크를 어그리게이션 해서 마치 큰 파이프 하

나를 매니지 하는 구조를 설계하였다 이를 위해 . Openflow 1.3 의 Group

테이블 기능을 이용하였고 , Group 테이블 기반으로 기존 대비 훨씬 빠른

속도의 fail over detection & recovery 가 가능한 구조를 설계 하였다 하 .

지만 현재는 아직 설계만 된 상태이고 검증 및 개발은 , 2 차년 도에 수행 할 계획이다.

◦ IoT-SFC 제어기 모니터링 기능 설계 및 개발

시장 상황 변화에 따라 모니터링 및 분석 기능이 중요해져 프로토콜 지원 기능

* sFlow

개발 과정에서 추가로 기능 개발 수행

§ IoT-SFC 제어기 sFlow 프로토콜 연동 시스템 개발

그림 14 SFC-IoT Contrller + ELK 연동 시스템 구조

§ sFlow 프로토콜을 통해 수집된 데이터의 분석 및 모니터링 시스템 개발 시스템

(ELK : Elastic Search + Logstash + Kinbana)

은 의 약자로서 는

ELK Stack Elasticsearch, Logstash, Kibana Elasticsearch 의 을 바탕으로 개발한 실시간 분산 검색 엔진이며 는

Apache Lucene , Logstash

각종 로그를 가져와 JSON 형태로 만들어 Elasticsearch 로 전송하고 Kibana 는

에 저장된 를 사용자에게 형태로 보여주는

Elasticsearch Data Dashboard 이다

Solution . l Log stash

로그 관련 정보를 쉽게 읽고 쓸수 있게 해주는 기술로써 설정을 통해서 변 ,

경 가능

l Elastic Search 검색 엔진 -

제공 해줌 - web application

를 통한 제공

- parameter query

여기서는 로그를 겁색하는 기능으로 사용됨 -

l

Kibana

로그 관련된 내용을 할수 있게 해줌

- visualization

이를 활용하기 위해 본 연구팀은 sFlow 를 통해 수집된 데이터를 ELK 의

로 전달하기 위한 라는 것을 설계하

Elastic Search sFlow logstash Forwarder

고 개발하였다 해당 . Forwarder 는 SFC-IoT Controller 를 통해 수집된 sFlow 정보를 JSON 형식으로 Elastic Search 엔진으로 전달하는 역할을 수행한다 . 사용의 편의성을 위해 이렇게 전달되는 JSON 데이터는 SRC/DST MAC, 기반의 플로우별 을 데이터로 전달하도록 SRC/DST IP, IP Protocol throughput

하였고 해당 데이터를 기반으로 모니터링 하도록 , Kibana 웹 인터페이스를 구성하였다.

그림 15 Kibana sFlow 기반 통계 모니터링 시스템

l 참여기관 콘텔라 :

◦ SDN 기반 IoT 공통 게이트웨이 설계 및 개발 Phase-1

§ 다양한 네트워크 간 연결을 위한 이종 네트워크 인터페이스를 탑재하며, 이종 네트워크 간 프로토콜 변환 기능을 담당하는 IoT 게이트웨이 설계

­블록 구성도

VNF UDP IOTGW

SENSOR

그림 16 IoT 게이트웨이 구성도

w VNF 는 IoT 게이트웨이와 UDP 를 통해 연동 및 서비스 처리

w IOTGW 는 IoT Gateway 에서 다양한 IoT 센서와 연동하여 메시지를 처리하고 , VNF 와 연동하여 서비스를 처리하는 블록

w Sensor 는 온도 위치정보등 수집한 데이터를 , IoT 게이트웨이로 전송

§ 상용 제품의 HW Board 조사 및 선정

­상용에서 사용하는 범용적인 HW 에 대한 조사를 수행하고 최종적으로 를 선정

Raspberry PI

­ Raspberry PI 2 Model B 1 GB 로 업그레이드된 보드 사용

그림 17 IoT 공통 게이트웨이 보드

Model A (25$) Model B (35$)

Chip CPU GPU

Memory 256MB SDRAM 512MB SDRAM

Ethernet None onboard 10/100 Ethernet

RJ45 jack

USB 2.0 Single USB Connector Dual USB Connector

Video Output

Audio Output 3.5mm jack, HDMI

Memory SD, MMC, SDIO

OS

8.6 x 5.4 x 1.7cm Dual Core VideoCore IV®

HDMI Composite RCA

Linux

Dimensions 8.6 x 5.4 x 1.5cm

Broadcom BCM2835 SoC

700 MHz Low Power ARM1176JZ-F

그림 18 Respberry 보드 비교 및 Data Sheet

§ IoT 게이트웨이 제품 제작을 위한 필요 주변 기기 조사

­제품 제작을 위한 주변 기기 및 연동이 가능한 모듈

그림 19 공통 IoT 게이트웨이 보드와 연동하는 주변기기 구성도

§ IoT 공통 게이트웨이 시제품 제작을 위한 부품 리스트

­ IoT 공통 게이트웨이와 WiFi 를 지원하는 센서 디바이스를 제작

번호 상품명/옵션 수량

1 USB to UART (232 TTL) 컨버터 ( XBee 소켓 ) Foca 1 개

2 XBee® DigiMesh_wire antenna 1 개

3 CSR4.0 USB DONGLE 1 개

4 라즈베리파이전용 투명 MULTICOMP ENCLOSURE (B+ / 2호환) 1 개

5 RaZberry Z-Wave 1 개

6 NETmate HDMI to DVI 젠더(19F_24P+1/M) 1 개

7 라즈베리파이 방열판(대) 1 개

8 라즈베리파이 방열판(소) 1 개

9 Coms USB 허브 2.0 (4P/I형), 케이블 내장 1 개

10 Coms HDMI 케이블(V1.4/일반/실속형) 1.8M 1 개

11 스마트폰 초고속 충전기 V2 [5V 2000mA] 1 개

12 [소이정품] 메모리 카드 (SanDisk) Micro SDHC 32G (L0010955) 2 개

13 라즈베리파이2 MODEL B 1GB (당일출고) 1 개

14 Wifi USB Ethernet Module 와이파이 모듈 2 개 그림 20 IoT 공통 게이트웨이 부품 리스트

번호 상품명/옵션 수량

1 SAFE멀티탭3구접지1.5 (SAFE_3구_접지_1.5m) 2 개 2 [BE466] Coms 브레드보드, 접촉케이블(점퍼선) 40set, 20cm, M/M 1 개 3 라즈베리파이 전용 공식 정품 엔클로저 (Model B+ , 2 호환) 1 개 4 NETmate HDMI to DVI 젠더(19F_24P+1/M) 1 개

5 라즈베리파이 방열판(대) 1 개

6 라즈베리파이 방열판(소) 1 개

7 Coms USB 허브 2.0 (4P/I형), 케이블 내장 1 개

8 Coms HDMI 케이블(V1.4/일반/실속형) 1.8M 1 개

9 스마트폰 초고속 충전기 V2 [5V 2000mA] 1 개

10 [소이정품] 메모리 카드 (SanDisk) Micro SDHC 32G (L0010955) 1 개

11 라즈베리파이2 MODEL B 1GB (당일출고) 1 개

12 Wifi USB Ethernet Module 와이파이 모듈 1 개 13 2 채널 릴레이 모튤/ 2 Road Channel 5V Relay Module 1 개

그림 21 WiFi Smart Plug (센서 부품 리스트)

§ 기능 검증을 위한 제품 제작 및 Test Bed 구축

­ IoT 공통 게이트웨이 HW 제작

­ BLE 연동을 위한 Beacon 센서 연동

그림 23 BLE (Beacon 센서 와 연동하는) IoT 공통 게이트웨이 시제품 그림 22 IoT 공통 게이트웨이 시제품

­ WiFi 연동을 위한 Smart Plug 디바이스 제작

그림 24 WiFi 를 지원하는 Smart Plug 센서 디바이스 제품

◦ L2~L3 Layer 패킷 처리 기능 - non-IP 노드들에 대한 IP Mapping 기능 설계 및 개발 (Phase -1 )

§ IOTGW 블록과 센서 연동 인터페이스 설계

­BLE

w 프로토콜의 메시지 구성은 ‘BLUETOOTH SPECIFICATION Version 를 따름

4.2'

w UUID : 제품의 고유 ID 이며 서비스에 따라 자체 UUID 로 구성 w Major : 서비스 그룹 또는 지역 구분 ID

w Minor : 같은 지역 내에서의 구분 ID

w Tx Power : 해당 비콘이 1m 에서 측정되는 RSSI 값 측정된 . RSSI 값을 바탕으로 거리계산을 할 때 사용됨 . 1 byte 가 사용되며 마지막 1

는 이며 의 보수를 사용해 계산 byte 00 , 2

Preamble

(1 Byte) Access Address

(4 Bytes) PDU

(2-39 Bytes) CRC

(3 Bytes)

Header

(2 Bytes) MAC Address

(6 Bytes) Data

(0-31 Bytes)

iBeacon Prefix

(9 Bytes) Proximity UUID

(16 Bytes) Major

(2 Bytes) Minor

(2 Bytes) TX Power (2 Bytes)

그림 25 BLE iBeacon Advertising Data 규격

Data-Ex) 02 01 06 1A FF 4C 00 02 15 E2 C5 6D B5 DF FB 48 D2 B0 60 D0 F5 A7 10 96 E0 00 00 00 00 C5

l

iBeacon prefix

- Advertising flags - 3 bytes

02 # Number of bytes that follow in first AD structure 01 # Flags AD type

06 # Flags value 0x06 = 000000110 bit 0 : LE Limited Discoverable Mode bit 1 : LE General Discoverable Mode bit 2 : BR/EDR Not Supported

bit 3 : Simultaneous LE and BR/EDR to Same Device Capable (controller)

bit 4 : Simultaneous LE and BR/EDR to Same Device Capable (Host)

- Advertising Header - 2 bytes

1A # Number of bytes that follow in second (and last) AD structure FF # Manufacturer specific data AD type

- Company ID - 2 bytes

4C 00 # Company identifier code (0x004C == Apple)

- iBeacon Type - 1 byte

02 # Byte 0 of iBeacon advertisement indicator

- iBeacon Length - 1 byte

15 # Byte 1 of iBeacon advertisement indicator

표 31 BLE iBeacon Advertising Data 규격 예시

­WiFi

w WiFi 인터페이스의 프로토콜 스택 구조

w 메시지 구성은 WiFi 센서 구성에 따라 별도로 정의

UDP Data Link LayerIP

Physical Layer

표 32 WiFi 인터페이스 프로토콜

§ 센서별 데이터 수집 기능

­BLE

w Beacon 연동 Call Flow

w Advertise Data 수신으로 Beacon 정보 (Mac Address) , Beacon RSSI 정보를 저장 및 관리

w Beacon 으로부터 데이터를 수집하고 수집된 정보를 , VNF 로 전송

IOTGW

VNF BEACON

Scan start

Advertise Data

Msg Send

ACK

Data Convert

그림 26 Beacon 연동 Call Flow

­WiFi

w Smart Plug ( 센서 연동 ) Call Flow

w 센서 Data 의 수신으로 센서 정보 센서 , Power On / Off 정보를 저 장 및 관리

w 센서로부터 정보를 수집하고 이 정보를 VNF 로 전송

§ IOTGW 블록 Data Architecture

­센서 정보 관리 및 수집된 메시지 처리를 위해 IOTGW 블록은 Data 를 정의

Architecture

­센서 정보 관리

w Sensor Information Table 은 IOTGW 모듈에 등록된 센서들의 정보를 저장함

그림 27 Smart Plug (센서 연동) Call Flow

­센서 데이터 관리

w Sensor Data Table 은 IOTGW 모듈에 등록된 센서들로부터 수집한 데이터를 저장

§ IOTGW 센서 데이터 메시지 처리 설계

­센서로부터 메시지를 수신하면 IOTGW 모듈은 Validation 을 체크 유효 , 한 메시지인지 검증

Structure Name Description Example

Sensor Information

nIndex Index 1

sName Device Name Beacon1

eRFType RF Type RF_BLE

eFntype Function Type FN_BEACON sAddr Device Address(MAC, IP, )… 00:1A:7D:DA:71:06

nPort Device Port NA

표 33 Sensor Information Table

Structure Name Description Example

Sensor Data

nIdx Sensor Data Index 2 nSensorIdx Sensor Information INDEX 1 nDate Last data received Time 1234567

sData Sensor Data N/A

표 34 Sensor Data Table

Sensor Data Received

Discard

Valid? No

Yes

Search Sensor Data &

Sensor Data Update

Send Data to VNF Convert VNF Data

그림 28 센서 데이터 메시지 처리 Diagram

­유효한 메시지일 경우 IOTGW 모듈 내부 Data Architecture 에 업데이트 후 UDP 로 VNF 에게 전송

­유효하지 않은 메시지일 경우 Discard

§ IOTGW VNF 데이터 메시지 처리 설계

­ VNF 로부터 메시지를 수신하면 해당 센서를 검색

­센서가 없거나 센서로 메시지 전송 불능 상태일 경우 VNF 로 에러를 전송

­센서가 유효할 경우 센서 타입에 맞게 메시지를 변환하여 전송

­전송이 성공하면 VNF 로 Success 메시지로 응답

§ IOTGW 블록 내부 구조 설계

­MSG_PROC

w 센서 및 VNF 로부터 수신된 메시지 처리를 담당

w 센서로부터 수신된 메시지를 내부 구조체에 업데이트하고 , VNF 로 전송하기 위해 정의된 메시지로 변환 후 VNF 로 전송

VNF Data Received

Send Data to VNF (ERROR)

Valid? No

Yes

Search Sensor

Send Data to VNF (SUCCESS) Convert Sensor Data

Send Data to Sensor

그림 29 VNF 데이터 메시지 처리 Diagram

w VNF 로부터 수신된 메시지를 변환하여 해당하는 센서로 전송

­IF_VNF

w VNF 로부터 메시지를 수신하여 MSG_PROC 으로 전달

­IF_BLE

w BLE 센서와 메시지 송수신을 담당

w BLE 센서로부터 수신한 메시지를 MSG_PROC 으로 전달하거나 반대 로 BLE 센서로 메시지를 전송

­IF_WIFI

w WiFi 센서와 메시지 송수신을 담당

w WiFi 센서로부터 수신한 메시지를 MSG_PROC 으로 전달하거나 반 대로 WiFi 센서로 메시지를 전송

­IF_ZWAVE

w ZWAVE 센서와 메시지 송수신을 담당

w ZWAVE 센서로부터 수신한 메시지를 MSG_PROC 으로 전달하거나 반대로 ZWAVE 센서로 메시지를 전송

­IF_ZIGBEE

w ZIGBEE 센서와 메시지 송수신을 담당

w ZIGBEE 센서로부터 수신한 메시지를 MSG_PROC 으로 전달하거나 반대로 ZIGBEE 센서로 메시지를 전송

IOT Gateway IOTGW

VNF

UDP

IF_Zwave IF_ZigBee IF_Ble IF_Wifi

IF_VNF

Sensor Data Information

Sensor Information

SIP PROC SIP PROC MSG PROC

그림 30 IOTGW 블록 내부 구조

◦ 패킷 Classifier & Service Mapper 기능 분석 구현 및 검증 ,

§ UDP-HTTP Mapping Proxy 블록 Architecture

­ IoT 게이트웨이에서 수신된 UDP 메시지를 HTTP 로 변환하여 Mobius 로 전달하는 기능을 수행하는 블록

­ UDP-Server, UDP-HTTP Translator, UDP-Client 서브 모듈로 이루어져 있음

그림 31 UDP-HTTP Mapping 기능 구성

§ UDP-HTTP Proxy 블록 주요 모듈간 연동 구조

UdpHttpCrossProxy

ProxyUdpHttpServer UdpServer

UdpHttpStack

ProxyUdpClient ProxyHttpClientResource

UDPConnector UdpHttpTranslator

그림 32 UDP-HTTP Proxy 주요 모듈간 연동 구조

­ UdpHttpCrossProxy : UDP-HTTP Proxy 의 메인 클래스로서 모듈을 이용하여 설정파일로부터 기동에 필요한 정보를 NetworkConfig

읽어서 서브 모듈들을 기동시키는 기능을 수행

­ UDPConnector : IoT 게이트웨이와 UDP 프로토콜 데이터 연동을 처리하

는 기능을 수행

­ ProxyUdpHttpServer : Mobius 로부터 HTTP Request 를 수신하여 이를

메시지로 변환하고 이에 대한 를

UDP Request , UDP Response HTTP 로 변환하여 로 전달하는 기능을 수행 위 기능을 위

Response Mobius .

해 HttpStack, ProxyCoAPResolver 모듈을 관리하는 기능을 수행

­ ProxyHttpClientResource : Mobius 로 HTTP Request 를 송신하고 이에 대한 Response 를 수신하는 역할을 수행

­ ProxUdpClientResource : IoT 게이트웨이로 UDP Request 를 송신하고 이에 대한 Response 를 수신하는 역할을 수행

­ ProxUdpTranslator : HTTP 메시지를 UDP 메시지로 변환하거나 UDP 메 시지를 HTTP 메시지로 변환하는 기능을 수행

§ UDP-HTTP Mapping 기능을 위한 인터페이스 설계

­ UDP 인터페이스

w IoT 게이트웨이와 VNF 간에 UDP 메시지를 연동하기 위한 인터페이 스

w UDP 인터페이스 프로토콜 스택 구조

­ HTTP 인터페이스

w VNF 와 Mobius 간에 HTTP 메시지를 연동하기 위한 인터페이스 w HTTP 인터페이스 프로토콜 스택 구조

Application UDP

IP

Data Link Layer Physical Layer

표 35 UDP 인터페이스 프로토콜

Application HTTP

TCP IP

Data Link Layer Physical Layer

표 36 HTTP 인터페이스 프로토콜

§ UDP-HTTP Proxy 기능 설계

­ UDP 프로토콜 연동을 수행하는 IoT 게이트웨이 등록 Call Flow 및 설명 w UDP 프로토콜을 이용하여 Mobius 에 IoT 게이트웨이 등록 절차

1. IoT 게이트웨이를 등록하기 위해서 IoT 게이트웨이의 UDP Client에서 VNF 의 UDP Server 모듈로 전달되는 UDP Request 메시지를 전달한다.

2. UDP 서버 모듈이 수신된 regi_gw_req UDP 메시지를 처리하여 UDP-HTTP 모듈로 전달한다

Translator .

3. UDP-HTTP Translator 모듈이 UDP Request 메시지를 HTTP Request메시지 로 변환한다

4. 변환된 HTTP 메시지를 HTTP-Client 모듈로 전달한다.

5. HTTP-Client 모듈은 Mobius의 remoteCSECreateReq API를 호출한다. 6. Mobius는 수신된 remoteCSECreateReq 처리한다.

7. Mobius는 remoteCSECreateReq 에 대한 처리 결과인 remoteCSECreateRsp 메시지를 HTTP-Client 모듈로 전달 한다.

8. HTTP-Client 모듈이 수신된 remoteCSECreateReq HTTP 메시지를 처리하여 모듈로 전달한다

UDP-HTTP Translator .

9. UDP-HTTP Translator 모듈이 HTTP Response 메시지를 UDP Response 메 시지로 변환한다.

10. 변환된 CoAP 메시지를 UDP-Server 모듈로 전달한다.

IoT GW IoT VNF MOBIUS

UDP-Client UDP-Server UDP-HTTP Translator HTTP-Client MOBIUS

1 : regi_gw_req()

2 : regi_gw_req()

3 : translateUDP2HTTP() 4 : remoteCSECreateReq()

5 : remoteCSECreateReq()

6 : processCreateRemoteCSEReq()

7 : remoteCSECreateRsp() 8 : remoteCSECreateRsp()

9 : translateHTTP2UDP()

10 : regi_gw_rsp() 11 : regi_gw_rsp()

그림 33 UDP-HTTP Proxy Call Flow (IoT 게이트웨이 등록)

11.

­ UDP 프로토콜 연동을 수행하는 IoT Gateway 제어 Call Flow 및 설명 w UDP 프로토콜을 이용하여 Mobius 에서 제어 패킷을 수신하는 절차

1. Mobius 는 mgmtCmd Req를 VNF의 HTTP-Server모듈로 전달한다.

2. HTTP-Server 모듈은 HTTP-UDP Translator 모듈로 제어 명령을 전달한다. 3. HTTP-UDP Translator 모듈은 수신된 제어 명령을 UDP Request 메시지로

변환한다. 이 때 수신된 OID(0.2.481.1.0001.001.0031)를 Key로 OID,

매핑 테이블을 검색해서 의 를 결정한다

UDP-GW IP UDP GW IP .

4. HTTP-UDP Translator 모듈은 변환된 UDP Request 메시지를 UDP Client 모듈로 전달한다.

5. UDP Client모듈은 UDP Request 메시지를 IoT 게이트웨이의 UDP 서버 모듈 로 전달한다.

6. IoT 게이트웨이의 UDP Server모듈은 수신된 메시지를 처리한다

7. IoT 게이트웨이는 수신된 메시지에 대한 UDP Response메시지를 VNF의 모듈로 전달한다

UDP Client .

8. UDP Client 모듈은 수신된 UDP Response 메시지를 HTTP-UDP Translator

IoT GW IoT VNF MOBIUS

UDP-Server UDP-Client HTTP-UDP Translator HTTP-Server MOBIUS

1 : mgmt_cmd_req() 2 : mgmt_cmd_req()

3 : translateHttp2Udp()

4 : ctrl_gw_req() 5 : ctrl_gw_req()

6 : processGwCtrl()

7 : ctrl_gw_rsp()

8 : ctrl_gw_rsp()

9 : translateUdp2Http()

10 : mgmt_cmd_rsp()

11 : mgmt_cmd_rsp()

그림 34 UDP-HTTP Proxy Call Flow (IoT 게이트웨이 제어)

모듈로 전달한다.

9. HTTP-UDP Translator 모듈은 수신된 UDP Response 메시지를 HTTP 메시지로 변환한다

Response .

10. 변환된 HTTP Response 메시지는 HTTP-Server 모듈로 전달된다. 11. HTTP-Server 모듈은 HTTP Response 메시지를 Mobius로 전달한다.

◦ CoAP-HTTP Mapping 기능 설계 구현 검증 , ,

§ CoAP-HTTP Mapping Proxy 블록 Architecture

­ IoT 게이트웨이에서 수신된 CoAP 메시지를 HTTP 로 변환하여 Mobius 로 전달하는 기능을 수행하는 블록

­ CoAP-Server, CoAP-HTTP Translator, CoAP-Client 서브 모듈로 이루어 져 있음

그림 36 CoAP-HTTP Mapping Proxy 블록 Architecture

§ UDP-HTTP Proxy 블록 주요 모듈간 연동 구조

CoAPHttpCrossProxy

ProxyHttpServer CoAPServer

ProxyHttpClientResource

HttpTranslator

ProxyCoAPClientResource HttpStack ProxyCoAPResolver

CoAPTranslator

그림 35 CoAP-HTTP Proxy 블록 주요 모듈간 연동 구조

­ CoAPHttpCrossProxy : CoAP-HTTP Proxy 의 메인 모듈로서 모듈을 이용하여 설정파일로부터 기동에 필요한 정보를 NetworkConfig

읽어서 서브 모듈들을 기동시키는 기능을 수행

­ ProxyHttpServer : Mobius 로부터의 HTTP Request 를 수신하여 이를

메시지로 변환하고 이에 대한 응답 를

CoAP Request CoAP Response

로 변환하여 로 전달하는 기능을 수행하기 위하 HTTP Response Mobius

여 HttpStack, ProxyCoAPResolver 모듈을 관리하는 기능을 수행

­ CoapServer : GW 에서 전달되는 CoAP 메시지를 수신하는 역할을 수행

­ HttpStack : Mobius 로부터의 HTTP Request 를 수신하여 이를 CoAP 메시지로 변환하여 로 전달하고 이에 대한 응답

Request GW CoAP

수신하여 이를 로 변환하여 로 전달하

Response HTTP Response MOBIUS 는 기능을 수행

­ ProxyCoAPResolver : CoAP 메시지 처리를 위한 CoAP Resolver 를 관리 하는 기능을 수행

­ ProxyHttpClientResource : Mobius 로 HTTP Request 를 송신하고 이에 대한 Response 를 수신하는 역할을 수행

­ HttpTranslator : HTTP 메시지를 CoAP 메시지로 변환하거나 CoAP 메시 지를 HTTP 메시지로 변환하는 기능을 수행

­ ProxyCoAPClientResource : IoT 게이트웨이로 CoAP Request 를 송신하고

이에 대한 Response 를 수신하는 역할을 수행한다 .

§ CoAP-HTTP Mapping 기능을 위한 인터페이스 설계

­ CoAP 인터페이스

w IoT 게이트웨이와 VNF 간에 CoAP 메시지를 연동하기 위한 인터페 이스

w CoAP 인터페이스 프로토콜 스택 구조

­ HTTP 인터페이스

w VNF 와 Mobius 간에 HTTP 메시지를 연동하기 위한 인터페이스 w HTTP 인터페이스 프로토콜 스택 구조

w CoAP 프로토콜의 메시지 구성은 RFC 7252 및 확장 규격을 참조

Application Requests/Response

Messages UDP

IP

Data Link Layer Physical Layer 표 37 CoAP 프로토콜 스택

Application HTTP

TCP IP

Data Link Layer Physical Layer

표 38 HTTP 인터페이스 프로토콜

§ CoAP-HTTP Proxy 기능 설계

­ CoAP 프로토콜 연동을 수행하는 IoT 게이트웨이 등록 Call Flow 및 설 명

w CoAP 프로토콜을 이용하여 Mobius 에 IoT 게이트웨이 등록 절차

1. GW를 등록하기 위해서 GW의 CoAP Client에서 VNF의 CoAP Server 모듈 로 전달되는 CoAP Request 메시지를 전달한다.

2. CoAP 서버 모듈이 수신된 regi_gw_req CoAP 메시지를 처리하여 모듈로 전달한다

CoAP-HTTP Translator .

3. CoAP-HTTP Translator 모듈이 CoAP Request 메시지를 HTTP Request메시 지로 변환한다.

4. 변환된 HTTP 메시지를 HTTP-Client 모듈로 전달한다.

5. HTTP-Client 모듈은 MOBIUS의 remoteCSECreateReq API를 호출한다. 6. MOBIUS는 수신된 remoteCSECreateReq 처리한다.

7. MOBIUS는 remoteCSECreateReq 에 대한 처리 결과인

메시지를 모듈로 전달 한다

remoteCSECreateRsp HTTP-Client .

8. HTTP-Client 모듈이 수신된 remoteCSECreateReq HTTP 메시지를 처리하여 모듈로 전달한다

CoAP-HTTP Translator .

9. CoAP-HTTP Translator 모듈이 HTTP Response 메시지를 CoAP Response 메시지로 변환한다.

10. 변환된 CoAP 메시지를 CoAP-Server 모듈로 전달한다.

11. CoAP-Server 모듈은 CoAP Response 메시지를 CoAP Client로 전달한다.

IoT GW IoT VNF MOBIUS

CoAP-Client CoAP-Server CoAP-HTTP Translator HTTP-Client MOBIUS

1 : regi_gw_req()

2 : regi_gw_req()

3 : translateCoAP2Http()

4 : remoteCSECreateReq()

5 : remoteCSECreateReq()

6 : processCreateRemoteCSEReq()

7 : remoteCSECreateRsp() 8 : remoteCSECreateRsp()

9 : traslateHttp2CoAP()

10 : regi_gw_rsp() 11 : regi_gw_rsp()

그림 37 CoAP-HTTP 연동 Call Flow (IoT 게이트웨이 등록)

­ CoAP 연동을 사용하는 IoT 게이트웨이 제어 Call Flow

w CoAP 프로토콜과 연동해 Mobius 에서 제어 패킷을 수신하는 절차

1. Mobius 는 mgmtCmd Req를 VNF의 HTTP Server모듈로 전달한다.

2. HTTP-Server 모듈은 HTTP-CoAP Translator 모듈로 제어 명령을 전달한다. 3. HTTP-CoAP Translator 모듈은 수신된 제어 명령을 CoAP Request 메시지로

변환한다. 이 때 수신된 OID(0.2.481.1.0001.001.0031)를 Key로 OID,

매핑 테이블을 검색해서 의 를 결정한다

CoAP-GW IP CoAP-GW IP .

4. HTTP-CoAP Translator 모듈은 변환된 CoAP Request 메시지를 CoAP Client 모듈로 전달한다.

5. CoAP Client모듈은 CoAP Request 메시지를 IoT 게이트웨이의 CoAP 서버 모듈로 전달한다.

6. IoT 게이트웨이의 CoAP Server모듈은 수신된 메시지를 처리한다.

7. IoT 게이트웨이는 수신된 메시지에 대한 CoAP Response메시지를 VNF의 모듈로 전달한다

CoAP Client .

8. CoAP Client 모듈은 수신된 CoAP Response 메시지를 HTTP-CoAP 모듈로 전달한다

Translator .

9. HTTP-CoAP Translator 모듈은 수신된 CoAP Response 메시지를 HTTP 메시지로 변환한다

Response .

10. 변환된 HTTP Response 모듈은 HTTP Server 모듈로 전달된다.

IoT GW IoT VNF MOBIUS

CoAP-Server CoAP-Client HTTP-CoAP Translator HTTP-Server MOBIUS

1 : mgmt_cmd_req()

2 : mgmt_cmd_req() 3 : translateHttp2CoAP()

4 : ctrl_gw_req() 5 : ctrl_gw_req()

6 : processGwCtrl()

7 : ctrl_gw_rsp()

8 : ctrl_gw_rsp()

9 : translateCoAP2Http()

10 : mgmt_cmd_rsp()

11 : mgmt_cmd_rsp()

그림 38 CoAP-HTTP 연동 Call Flow (IoT 게이트웨이 제어)

11. HTTP Server 모듈은 HTTP Response 메시지를 Mobius로 전달한다.

§ CoAP 프로토콜 분석 및 Mapping 알고리즘 설계

­ CoAP 프로토콜 특징

w CoAP : Constrained Application Protocol w IETF 에서 2010 에 발표

w CoAP Working Group 의 Draft 18 에서 RFC 표준으로 선정

w 제한적인 네트워크 환경 저전력 고손실 소용량 네트워크 환경 소 ( , , 형노드 등 에서 사용되는 프로토콜 )

w 4 바이트의 바이너리 헤더

w UDP 기반의 비동기 통신이지만 ACK 를 통한 응답 및 재전송 타이머 등으로 신뢰성있는 통신을 지원

w 4 가지 (CON, NON, ACK, RST) 의 메시지타입 w URI 와 Content-format 을 지원

및 응답코드 (coap://EXAMPLE.com/%7Esensors/temp.xml ) w Proxy 와 cache 를 지원

w RESTful 아키텍쳐를 따르고 있으며 HTTP 와 쉽게 변환 및 연동이 가능

­ CoAP 연동 메시지 모델

w CoAP 연동 메시지는 신뢰성 있는 메시지와 비신뢰성 메시지로 구분 되어 진다.

그림 39 CoAP Message Mode (신뢰성 / 비신뢰성)

w Request / Response Model

그림 40 Request / Response Model 1

그림 41 Request / Response Model 2

­CoAP Message Format

w Ver(2): CoAP 의 버전 01

w T(2): 메시지타입 . 0=CON, 1=NON, 2=ACK, 3=RST w TKL(4): Token Length. 단위는 byte 이며 0~8 의 값

w Code(8): class(3), detail(5) 로 구성 . c.dd 형태로 구성되며 class 의 0= 요 청 , 2= 성공적인 응답 , 4= 클라이언트 에러응답 , 5= 서버에러 응답 요청 . 의 경우 0.00=empty, 0.01=GET, 0.02=POST, 0.03=PUT, 0.04=DELETE.

w Message ID(16): 중복확인 및 CON, NON 의 짝으로 ACK/RST 에 사용 w TKL 에 따라 Token 길이가 결정 (0~8byte)

w Options: 페이로드 마커 (0xff) 나 메시지에 끝에 도달하면 옵션이 더 없음을 표시

w Payload 는 데이터그램의 끝까지 위치

그림 42 CoAP Message Packet Format

§ CoAP-HTTP Mapping 처리 기능 구현

­ CoAP-HTTP Mapping 알고리즘 w CoAP -> HTTP 변환 예제

메시지

구분 CoAP 메시지 HTTP 메시지

POST (T=CON, Code=0.02, MID=0x7d36) POST /Mobius?ty=remoteCSE&nm=test0032 HTTP/1.1

Token: 0x31 Host: open.iotmobius.com

Uri-Path: “coap2http“ Accept: application/onem2m-resource+xml

Proxy-Uri:

http://open.iotmobius.com/Mobius?ty=remoteCSE

&nm=test0032

Content-Type: application/onem2m-resource+xml

locale: ko passCode: 1111 From: mobius X-M2M-RI: 12345

PayLoad : <?xml version="1.0" encoding="UTF-8"?>

passCode: 1111 <m2m:remoteCSE

X-M2M-RI: 12345 xmlns:m2m="http://www.onem2m.org/xml/protocols"

X-M2M-Origin: Origin xmlns:xsi="http://www.w3.org/2001/XMLSchema-

instance">

X-M2M-NM: test0032 <CSE-ID>0.2.481.1.0001.001.0032</CSE-ID>

Content-Type: application/onem2m-resource+xml

<pointOfAccess>

HTTP|1.0.0.11/proxy/0.2.481.1.0001.001.0032</point OfAccess>

<?xml version="1.0" encoding="UTF-8"?> </m2m:remoteCSE>

<m2m:remoteCSE

xmlns:m2m="http://www.onem2m.org/xml/protoco ls"

xmlns:xsi="http://www.w3.org/2001/XMLSchema- instance">

<cseType>1</cseType>

<CSE-ID>0.2.481.1.0001.001.0032</CSE-ID>

<pointOfAccess>HTTP|1.0.0.11</pointOfAccess>

<requestReachability>true</requestReachability>

</m2m:remoteCSE>

CoAP -> HTTP Translation

Payload data header

그림 43 CoAP -> HTTP 변환 예제

w HTTP -> CoAP 변환 예제

메시지

구분 HTTP 메시지 CoAP 메시지

HTTP/1.1 201 Created Header: POST (T=CON, Code=2.01, MID=0x7d36)

Content-Length: 639 Token: 0x31

Content-Type: application/onem2m-

resource+xml;charset=UTF-8 Uri-Path: “coap2http“

Location:

http://open.iotmobius.com/Mobius/test0032 X-M2M-RI: 12345

X-M2M-RI: 12345

<?xml version="1.0" encoding="UTF-8"

standalone="yes"?>

<?xml version="1.0" encoding="UTF-8"

standalone="yes"?>

<m2m:remoteCSE <m2m:remoteCSE

xmlns:m2m="http://www.onem2m.org/xml/protoco

ls" xmlns:m2m="http://www.onem2m.org/xml/protocols"

xmlns:xsi="http://www.w3.org/2001/XMLSchema- instance">

xmlns:xsi="http://www.w3.org/2001/XMLSchema- instance">

<resourceType>18</resourceType> <resourceType>18</resourceType>

<resourceID>0.2.481.1.0001.001.0032</resourceI

D> <resourceID>0.2.481.1.0001.001.0032</resourceID>

<parentID>mobius</parentID> <parentID>mobius</parentID>

<creationTime>2014-12-

05T17:07:19+09:00</creationTime>

<creationTime>2014-12-

05T17:07:19+09:00</creationTime>

<lastModifiedTime>2014-12-

05T17:07:19+09:00</lastModifiedTime>

<lastModifiedTime>2014-12-

05T17:07:19+09:00</lastModifiedTime>

<labels>test0032</labels> <labels>test0032</labels>

<pointOfAccess> HTTP|1.0.0.11</pointOfAccess> <pointOfAccess> HTTP|1.0.0.11</pointOfAccess>

<CSE-ID>0.2.481.1.0001.001.0032</CSE-ID> <CSE-ID>0.2.481.1.0001.001.0032</CSE-ID>

<nodeLink>0.2.481.1.0001.001.0032</nodeLink> <nodeLink>0.2.481.1.0001.001.0032</nodeLink>

<dKey>NDMyNDVmMGYtMTNhYi00YmQwLWFhNzU tMzM2ZTNlNTIyYmM1</dKey>

<dKey>NDMyNDVmMGYtMTNhYi00YmQwLWFhNzUtMz M2ZTNlNTIyYmM1</dKey>

</m2m:remoteCSE> </m2m:remoteCSE>

CoAP -> HTTP Translation

Header

Payload

그림 44 HTTP -> CoAP 변환 예제

l 참여기관 2 : 엔텔스 :

◦ IoT 단위서비스별 분석 서비스 체이닝 시나리오설계 매핑 / / (Mapping)

§ SDN 기반 이질적인 서비스간의 체이닝 설계

서비스 기능 설계

- Catalog

항 목 설 명

서비스 ü 스마트홈 스마트카 등의 서비스를 등록 및 삭제

ü 를 통해 기본 정보를

ü 최초 서비스 생성시 정보가 등록

ü

기본 와 서비스 로 구분하여 관리

- VNF VNF

항 목 설 명

기본

ü 서비스 의 기본이 되는 ü

단말로부터 전달되는 를 에 전달하기 위해 로 변환

ü

에서 전달되는 를 단말 공통 에 전달하기

위해 로 변환 ü

단말로부터 전달되는 를 에 전달하기위해 로 변환

ü

에서 전달되는 를 단말 공통 에 전달하기

위해 로 변환

서비스

ü 기본 와 서비스 의

방화벽 설정 바이러스 차단

데이터 분산 부하 분산

어댑터 어댑터

항 목 설 명

ü

ü

§ IoT 오픈 플랫폼과 연동하는 단위 서비스별 융합 매핑서비스 설계 / 체이닝 기능

- VNF

항 목 설 명

서비스 ü 에 등록된 서비스 목록 출력

ü 서비스 선택에 따라 된 체이닝 정보 출력

서비스 ü 에 등록된 서비스 목록으로 선택된 서비스 체

이닝 를 제외한 서비스 목록출력 체이닝 ü 선택된 서비스의 체이닝 목록

체이닝 정합성 체크 ü 속성에 등록된 조건을 조회하여 ü 등록하는 서비스 의 순서 정합을 체크 ü 서비스 체인 등록 삭제

속성 설정을 통한 정합성 체크 - VNF (Pre/Post)

항 목 설 명

ü 기본 서비스 의

조건

ü 등록하는 체이닝 의 선처리 조건 앞에 등록된 데이터가 있을 경우 등록된 데이터의 후처리 조건과 비교

해당 앞에 모든 설정가능

해당 앞에 설정 불가

해당 앞에 설정한 만 설정가능

조건

ü 등록하는 체이닝 의 후처리 조건 이후 등록될 데이터가 있을 경우 등록될 데이터의 선처리 조건과 비교

해당 뒤에 모든 설정가능

해당 뒤에 설정 불가

해당 뒤에 설정한 만 설정가능

§ IoT 오픈 플랫폼과 연동하는 단위서비스별 디바이스 라이프사이클 서비스 설계

에 등록된 단말 조회 및 사용자 매핑 기능 - Mobius

단말 선택

ü 에 등록된 단말 정보를 기준으로 조회한다 ü 사용자가 등록한 단말을 조회 추가 수정 및 삭제한다

항 목 설 명

메뉴 ü 사용자가 기 등록한 단말 리스트가 조회된다

버튼 ü 에 등록된 단말을 조회하여 사용자 소유의 단말로 등록한다

휴지통 버튼 ü 에 등록한 단말을 삭제한다

버튼 ü 의 최신 데이터로 단말 정보를 갱신한다 링크 ü 해당 단말의 수집데이터 조회화면으로 이동한다

링크 ü 데이터 수집 주기 정보를 초 단위로 수정한다

서비스에 단말 매핑 및 해지 -

단말 설정

ü 사용자가 등록한 단말을 서비스에 매핑하여 사용한다 ü 필요에 따라 다른 서비스에 단말을 매핑할 수 있다

기 능 설 명

메뉴 ü 전 화면에서 선택한 서비스 항목 및 사용자 소유의 단말 리스트가 조회된다

버튼 ü 조건으로 소유 단말을 조회한다

버튼 ü 선택한 단말을 해당 서비스로 매핑한다 휴지통 버튼 ü 해당 단말을 현재 서비스와 매핑 해제한다

단말 센서 데이터 조회 -

센서데이터 이력

ü 단말로부터 수집되는 센서 데이터를 일자별로 조회한다

기 능 설 명

메뉴 ü 전 화면에서 선택한 및 에 해당하는

당일분의 수집데이터 로그가 조회된다

버튼 ü 의 조건에 해당하는

수집데이터 로그를 조회한다

페이지 이동 버튼 ü 리스트의 해당 페이지로 직접 이동할 경우 사용한다

◦ SDN 기반 이질적인 서비스간의 체이닝 설계

§ 표준 IoT 오픈 플랫폼 기반의 서비스 및 이질적인 서비스간의 연동을 위 한 API 및 인터페이스 설계

와 서비스 연동 단말 등록 센서 데이터 수집 단말

- Mobius Target IoT ( , ,

제어 기능)

기 능 설 명

단말 등록

ü 플랫폼으로 디바이스 조회를 한다 ü 플랫폼으로 해당 디바이스 하위의

컨테이너 센서 및 제어명령 조회를 한다

센서 데이터 수집

ü 플랫폼으로 튺정 센서의 데이터 수집에 대한 를 위한 구독을 등록한다

ü 구독 시 등록한 로 새로 수집된 센서 데이터를 넘겨 받는다

단말 제어 기능 ü 플랫폼으로 특정 제어명령에 대한 제어 실행 요청을 한다

◦ Policy 전달

§ Ochestrator 에 NF(Network Function) 체이닝 Policy 전달 (?) 체이닝에 대한 정책은 차년도에 적용 예정

- 2

항 목 설 명

ü

ü

항 목 설 명 ü

ü

◦ 사용자별 PoC 기능 및 메뉴 정의

§ IoT 타겟 서비스 모니터링 제어 통계 관리 등 서비스에 필요한 기능 및 , , , 메뉴 정의

서비스 메뉴 - Target IoT

메 뉴 설 명

ü 스마트홈을 주제로 비콘과 조명 센서의 상태를 모니터링한다

ü 단말 설정 메뉴

ü 에 등록된 단말을 조회하고 소유단말로 추가한다 ü 단말 컨테이너별 수집 데이터 로그를 조회한다

ü 서비스 설정 메뉴

ü 서비스 목록과 각 서비스별 기능을 조회한다

ü 선택된 서비스 항목과 단말을 매핑 및 매핑 해지한다 ü 규칙 설정 메뉴

ü 설정된 규칙 리스트를 조회 및 새 규칙을 추가 삭제한다 ü 규칙에 의해 제어명령이 동작된 이력을 조회한다

의 통계 설계 - IoT Manager

항 목 설 명

단말 현황 ü 기간별로 등록된 단말의 현황을 조회 ü 조회항목 단말 컨테이너명 상태 사용자 데이터 수집 현황 ü 기간별 단말 에 수집된 데이터 현황 조회

ü 조회항목 단말 수집건수 데이터 용량 수집일 사용자 서비스 단말 현황 ü 서비스에 등록된 단말 정보 조회

ü 조회항목 서비스명 등록단말수 사용단말수 사용자수

제어 현황

ü 제어유형별 디바이스 제어 현황을 조회

ü 조회항목 제어유형 단말 전체 건수 성공 건수 실패건 수 진행 건수

기능 설명 - Mobius I/F

항 목 설 명

디바이스 조회 ü 특정 디바이스 로 디바이스 상세 정보를 조회한다 컨테이너 센서 목록 조회 ü 해당 디바이스 하위에 등록된 컨테이너 목록을 조회한다 컨테이너 센서 상세 조회 ü 특정 컨테이너의 상세 정보를 조회한다

제어명령 목록 조회 ü 해당 디바이스 하위에 등록된 제어명령 목록을 조회한다 제어명령 상세 조회 ü 특정 제어명령의 상세 정보를 조회한다

디바이스 제어 요청

ü 특정 디바이스의 특정 제어명령에 대한 제어 요청을 한다

ü 서비스 사용자 룰 또는 사용자 임의 제어에 의해 수행된다

주기보고 생성 구독 ü 특정 컨테이너 하위에 생성되는 주기보고에 대해 받기 위한 구독 신청을 한다

디바이스 제어 결과 구독 ü 특정 제어명령에 대해 이루어진 제어 결과에 대해 받기 위한 구독 신청을 한다

주기보고 생성 구독 삭제 ü 사전 주기보고 생성 구독 신청건에 대한 삭제를 한다 디바이스 제어 결과 구독 ü 사전 제어결과 구독 신청건에 대한 삭제를 한다

◦ 사용자별 관리자 소비자 별 ( , ) PoC 설계 및 프로토타입 (Prototype) 구현

§ 사용자 및 권한별 최적화된 UI 및 IoT 서비스 기능 제공 설계

- UseCase Diagram

ü 서비스를 사용할 때 사용자 관점으로 기능을 정의한다

설계 - Sequence Diagram

서비스 설정

설정

ü 서비스 설정 시 사용자의 단말을 매핑한다

ü 단말 등록 시 입력된 제어 정보를 가지고 을 설정한다