"5조 - OLora"의 두 판 사이의 차이
(→성능) |
(→요구사항 및 설계변수) |
||
99번째 줄: | 99번째 줄: | ||
# 최종적으로 채택된 설계변수 값은‘2.5 최종설계안’에 설명이 되어있다. | # 최종적으로 채택된 설계변수 값은‘2.5 최종설계안’에 설명이 되어있다. | ||
====성능==== | ====성능==== | ||
− | 가. 송신거리 | + | #가. 송신거리 |
송신거리는 통신단말기 간 얼마만큼 떨어져도 통신이 가능한가의 척도이다. 이는 어떠한 하드웨어를 고르느냐에 따라서 크게 결정되기 때문에, 통신모듈을 고른 이후에는 설계변수가 아닌 고정변수가 된다. | 송신거리는 통신단말기 간 얼마만큼 떨어져도 통신이 가능한가의 척도이다. 이는 어떠한 하드웨어를 고르느냐에 따라서 크게 결정되기 때문에, 통신모듈을 고른 이후에는 설계변수가 아닌 고정변수가 된다. | ||
− | 나. 전송속도 | + | #나. 전송속도 |
전송속도는 통신단말기 간 얼마나 빠르게 데이터를 주고받을 수 있는지에 대한 척도이다. 구체적으로는 사용자가 전송버튼을 누른 이후에 상대방이 수신할 때까지의 걸린 시간을 나누는 것이 아니라, RF모듈에서 송출되어 나올 때부터의 시간을 기준으로 ‘전송속도’를 의미한다. 따라서 해당 요구사항은 어떠한 하드웨어를 고르느냐에 따라서 baseline이 크게 정해진다. 전송속도는 주변 전파 노이즈나 장애물 그리고 상대방과의 거리에 따라서 크게 달라지기는 하나 이는 설계변수가 아니므로, 결국에 설계변수는 어떠한 RF모듈을 고르느냐에 달려있다. 하드웨어를 고른 이후에는 고정변수가 된다. | 전송속도는 통신단말기 간 얼마나 빠르게 데이터를 주고받을 수 있는지에 대한 척도이다. 구체적으로는 사용자가 전송버튼을 누른 이후에 상대방이 수신할 때까지의 걸린 시간을 나누는 것이 아니라, RF모듈에서 송출되어 나올 때부터의 시간을 기준으로 ‘전송속도’를 의미한다. 따라서 해당 요구사항은 어떠한 하드웨어를 고르느냐에 따라서 baseline이 크게 정해진다. 전송속도는 주변 전파 노이즈나 장애물 그리고 상대방과의 거리에 따라서 크게 달라지기는 하나 이는 설계변수가 아니므로, 결국에 설계변수는 어떠한 RF모듈을 고르느냐에 달려있다. 하드웨어를 고른 이후에는 고정변수가 된다. | ||
− | 다. 지속시간 | + | #다. 지속시간 |
지속시간은 배터리가 얼마나 오래 지속될 수 있는가의 척도이다. 먼저 어떠한 하드웨어(보드, 통신모듈)에 따라서 크게 달라지므로 하드웨어의 종류가 설계변수가 될 수 있다. 두 번째로, 전력소모는 소프트웨어가 얼마나 CPU를 사용하느냐에 따라서 크게 달라지므로 Android App의 대기모드 지속시간이 설계변수가 될 수 있다. 이외에도 프로파일링 툴을 이용해 어느 부분에서 CPU 자원이 필요 이상으로 낭비되는지 확인한다면 사용하는 ‘알고리즘’의 시간복잡도 또한 설계변수가 될 수 있다. | 지속시간은 배터리가 얼마나 오래 지속될 수 있는가의 척도이다. 먼저 어떠한 하드웨어(보드, 통신모듈)에 따라서 크게 달라지므로 하드웨어의 종류가 설계변수가 될 수 있다. 두 번째로, 전력소모는 소프트웨어가 얼마나 CPU를 사용하느냐에 따라서 크게 달라지므로 Android App의 대기모드 지속시간이 설계변수가 될 수 있다. 이외에도 프로파일링 툴을 이용해 어느 부분에서 CPU 자원이 필요 이상으로 낭비되는지 확인한다면 사용하는 ‘알고리즘’의 시간복잡도 또한 설계변수가 될 수 있다. | ||
− | 라. 기록저장성 | + | #라. 기록저장성 |
기록저장성은 얼마나 많은 량의 정보(메타정보 포함)를 저장할 수 있느냐 척도이며, 본 프로젝트에서는 Android App 상에서 ‘데이터베이스용량’을 설계변수를 조절함으로써 기록저장성을 만족시킬 수 있다. | 기록저장성은 얼마나 많은 량의 정보(메타정보 포함)를 저장할 수 있느냐 척도이며, 본 프로젝트에서는 Android App 상에서 ‘데이터베이스용량’을 설계변수를 조절함으로써 기록저장성을 만족시킬 수 있다. |
2018년 12월 18일 (화) 02:27 판
프로젝트 개요
기술개발 과제
국문 : 휴대용 무선 메쉬-네트워크 단말기
영문 : Portable Off-Grid Mesh Network Device
과제 팀명
00000..
지도교수
김태현 교수님
개발기간
2018년 9월 ~ 2018년 12월 (총 4개월)
구성원 소개
서울시립대학교 기계정보공학과 20114300** 이**(팀장)
서울시립대학교 기계정보공학과 20114300** 권**
서울시립대학교 기계정보공학과 20114300** 김**
서울시립대학교 기계정보공학과 20114300** 이**
서울시립대학교 기계정보공학과 20114300** 이**
개요
요약
본 프로젝트는 독립된 네트워크 체계의 무전 송수신 장비를 이용해 재난시 안전통신망의 역할을 수행하고, 네트워크 기반이 갖춰지지 않은 지역이나 복구 시간이 장기간이 될 경우에 대체 통신망으로써 사용될 수 있으며, 일반인들도 기술적 혜택을 볼 수 있도록 쉽게 접근 및 사용가능한 전용 어플리케이션을 개발하는 것을 목표로 한다.
개발 배경 및 효과
21세기에 네트워크가 안 되는 경우 많은 불편한 점을 개선해보고자 하는 생각으로 아이디어를 제시했다. 현재 네트워크 구축이 워낙 촘촘하고 광범위하게 되어있어서 웬만해선 인터넷 끊길 일이 잘 없다. 그러나 도시 지역이 아닌 자연, 특히 사람들이 자주 찾지만 네트워크 및 각종 인프라가 구축되기 어렵거나 제한적인 곳에선 어떻게 정보를 주고받을 수 있을지 고민해보았다. ICT 시사용어 뉴스에서 ‘메시 네트워크(Mesh Network)’ 1) 는 다 대 다 기기 간 통신을 지원하고, 대규모 디바이스 네트워크 생성에 최적화되어 있다며, 차세대 이동통신, 홈네트워킹, 공공 안전 등 특수 목적을 위한 새로운 방식의 네트워크 기술이라고 설명하고 있는 것을 보았다. 그리고 이 메시 네트워크는 건물이나 사무실 단위에서 대규모 공원이나 리조트, 항만 등지에서 유용하게 사용되어질 수 있다고 하였다. 우리의 제품은 산악 지대나 해안의 섬 등 기존 네트워크가 없을 시 무선으로 대체 네트워크를 제공함으로써 이 단말기를 들고 있는 사용자는 모바일과 연동하여 다른 사용자들과 자유로이 의사소통을 할 수 있으며, 비상 상황 시 신속하게 자신의 상황을 알릴 수 있다. 특히 비상 상황에서는 전원이 충분하지 않을 때에 문제가 될 수 있는데, Bluetooth를 적용하여 전원 사용량도 최소화 할 수 있으며, 비행기 모드에서도 사용이 가능하여 전원을 오래 유지시킬 수 있다. 지인들 혹은 단체로 해외여행 시, 로밍 연결이 잘 안될 때 혹은 로밍을 하지 않았을 때 단체 내에서의 독립된 네트워크로 편리하게 의사소통할 수 있다. 현재 해외여행 시 지하철만 이용하려 해도 통신 서비스가 안 되는 경우가 많은데, 이러한 경우에도 편리하게 사용할 수 있다. 그리고 우리가 관심 가지고 있는 집단은 패키지 여행사이다. 특히 해외 패키지여행을 신청한 관광객들에게 이 제품을 나눠주면 로밍을 신청하지 않은 관광객 혹은 통신이 잘 되지 않는 장소에서도 가이드가 계속해서 정보를 나눠줄 수 있고, 각종 안전사고를 대비할 수 있도록 안내를 해줄 수 있기 때문이다. 사람이 너무 많아서 통신망이 사고가 났을 때 2), 예를 들어 불꽃축제 현장이나 논술 시험 등 사람이 몰리는 상황에서 기존의 통신망이 작동이 되지 않을 경우가 있다. 이러한 경우에 제품 사용자들끼리 의사소통을 할 수 있게 하고, 안전사고가 발생했을 때 독립된 네트워크로 신속하게 사고 상황을 알려 대처할 수 있다.
관련 기술/제품/특허 현황
관련 기술 현황
(1) MANET(Mobile Ad-hoc Network)
기존의 single hopping celluar 네트워크는 반드시 base station이 엑세스 포인트로 필요로 하는 반면, MANET은 어떠한 종류의 고정 인프라가 필요하지 않다. 즉, 연결그래프가 동적이다 . 모든 단말이 라우터이자 단말기이므로, 노드 하나가 빠져도 통신에 큰 영향을 받지 않는다. 또한 직접 1:1로 통신할 거리 밖인 경우 인접기기를 라우터로 활용하여 hopping하여 통신이 가능하므로 단일기기의 한계를 벗어난 통신이 가능하다. 하드웨어의 발전으로 각 단말이 처리할 수 있는 계산량이 크게 늘어나고, 배터리 기술 또한 좋아짐에 따라서 단점보다는 장점이 더 크게 다가오고 있다. 실제로 현재 5G에서 제시하는 요구사항 중 하나가 Ad-hoc 기능이며, 이는 기존의 인프라에 완전히 의존했던 예전 이동통신기술과 차별되는 점이다. 활용 분야는 아래와 같다.
(2) D2D통신 (Device-to-Device 통신)
D2D통신은 말 그대로 직접 단말기기간 통신을 지칭하는 말이다. D2D통신을 사용함으로써 모바일 트래픽의 포화를 해결하고자 하는 것이 5G에서 D2D통신의 의의이다6) 7). 지금까지 D2D는 기기 간 블루투스 통신 정도로만 진행되었다면 앞으로 5G에서는 상용통신망 인프라를 간접적으로 사용하거나, 순수히 직접적으로 통신하는 방식으로 나아갈 것으로 기대된다. 단, D2D는 단말-단말 간접 통신부터 직접 통신을 어우르는 말이며 어떠한 방식으로 통신을 하느냐를 정의하는 용어가 아니다. D2D의 등장배경은 재난망 구축과 같은 이유 하나로만 생긴 것은 아니다. 넓게 보자면 사용가능한 대역폭을 더 쓰기 위함이다. 첫 번째, 최근 몇 년간 스마트폰과 태블릿 기기의 급격한 보급으로 고용량 멀티미디어 통신이 활성화되면서 모바일 인터넷 트래픽이 매년 급격히 증가하여 이로 인해 셀룰러 통신망의 과부하가 심화되었다. 이를 해결하기 위해서 통신 사업자들은 최근에 셀룰러 네트워크를 중앙 집중형 기지국 구조로 변경하여 트래픽 과부하에 대처하려고 있는 것이다. 더불어 4G 셀룰러 시스템인 LTE 외에도 펨토셀, Wi-Fi 무선 랜 등을 도입하여 네트워크 트래픽 분산을 통해서 과부하 문제를 해결하려 하고 있다. 이에 따라서, 네트워크 인프라의 변경 및 확장을 통해 기지국의 과부하를 줄이는 방법에 추가하여 네트워크 인프라를 거치지 않고 단말기 간에 직접 통신하는 방법이 부각되고 있다.
(3) 무전기
무전기는 생활용/아마추어용/군용 등으로 크게 나뉘어서 쓰이고 있다. 현재 우리가 타겟팅하는 ‘생활용’ 이므로 생활용 무전기 사업만 보자면 사실상 사향산업에 속한다. ‘생활용’무전기는 무엇보다 저렴한 가격에 편리성이 중요한데 기술적으로 더 낫게 만들 혁신이 나타나고 있지 않다8). 기술적으로 분석해보자면, 무전기는 Half-Duplex 방식이다. 즉, 수신/송신을 동시에 할 수 없다. 추가적인 기능이 있다고 해도 무전기만으로는 ‘망’의 통신형태를 만들 수가 없다. 또한 사용자 개개인이 통신 프로토콜을 알고 있어야 한다. 예를 들어서 우리가 카카오톡을 할 때는 규약에 신경을 쓰지 않고 편하게 통신을 할 수 있지만, 무전기는 사람이 직접 통신 규약에 대해서 신경을 쓰고 있어야 한다.
관련 제품 현황
내용
관련 특허 현황
내용
기대효과
기술적 기대효과
(1) 5G의 음영지대 보완
값싼 휴대통신기기의 보급으로 모바일 트래픽이 계속 증가하여 사용가능한 대역폭이 점점 좁아지고 있기 때문에 새로 나오는 5G 표준에서는 D2D 통신기능을 넣으려고 하고 있는 시점이다. 5G의 시대가 거의 다 왔다고는 하나, 빨라야 2019년 말이고 일반적으로 2020년 정도부터 5G 서비스를 받을 수 있을 것으로 기대되고 있다. 5G에서 사용하는 D2D 통신 방식은 아예 중앙인프라 제어가 일체 없이 순수하게 단말-단말이 통신하는 방법도 연구되고 있기는 하나, 이마저 통신거리는 최대 1km 이고 5G 개발되는 D2D 통신 방식은 어디까지나 강력한 중앙 통신 인프라를 우선적으로 사용하는 방향이므로 이번에 우리 팀이 개발하는 단말기 이상의 “순수한” D2D 통신을 기대하기는 어렵다. 5G 표준에서 D2D개발은 상용통신망의 대역폭 확장을 위해서가 가장 우선적인 이유고, 재난망 구축 기능이나 순수하게 단말-단말 끼리 연결되는 기능은 두 번째 이유가 될 것이다. 단말기 없이 스마트폰끼리 순수하게 D2D 통신을 하기 위해서는 이를 위한 통신하드웨어가 추가적으로 스마트폰에 들어가야 한다. 완전한 D2D 통신의 최종목표로 볼 수 있는 Ad-hoc Network를 구현하는 라우팅 프로토콜을 펌웨어 수준으로 하드웨어회사(e.g 삼성, 퀄컴)가 제공해줘야 하는데, 수요가 더 많고 중앙 처리 통신망을 이용방식의 5G D2D를 나두고 이 부분을 지원해줄지 불투명하다. 5G D2D가 어떻게 베일을 벗을지 모르지만, 현재로서 완전한 Mobile Ad-hoc Networking을 이용하고자 하면 우리 제품의 그 요구사항을 충족시켜줄 최선의 선택 안이다.
(2) 생활용 무전기의 차기 대체품
비슷한 가격대에 있는 기존 “생활용” 무전기에 비해 높은 보안성과 긴 통신거리를 제공한다. 현 시장에 이번 개발하고자 하는 단말기의 기능을 대부분 갖춘 “스마트무전기”가 있으나 기기 하나당 가격이 200만원을 초과한다. 현대인의 대부분이 스마트폰을 갖고 있는 시점에서, 우리가 개발하는 단말기만 있다면 “스마트무전기”가 할 수 있는 일을 대부분 해낼 수 있다13). 한 쌍에 20만원이면 된다.
사회적 기대효과
비슷한 가격대에 있는 기존 “생활용” 무전기에 비해 높은 보안성과 긴 통신거리를 제공한다. 현 시장에 이번 개발하고자 하는 단말기의 기능을 대부분 갖춘 “스마트무전기”가 있으나 기기 하나당 가격이 200만원을 초과한다. 현대인의 대부분이 스마트폰을 갖고 있는 시점에서, 우리가 개발하는 단말기만 있다면 “스마트무전기”가 할 수 있는 일을 대부분 해낼 수 있다13). 한 쌍에 20만원이면 된다.
구성원 및 추진체계
내용
설계
시나리오
사용자는 기존 상용 통신망 사용이 불가할 때 위와 같은 방식으로 서로 통신하게 된다. 메시지의 생성부터 최종적으로 수신되는 과정을 살펴본다면, 먼저 사용자는 기존 상용 메신저(e.g. 카카오톡)의 사용 환경과 유사한 환경에서 메시지를 생성하게 된다. 생성된 메시지는 Bluetooth를 통해서 본인의 스마트폰과 연결되어 있는 Raspberry Pi에게 전송된다. Raspberry Pi에서 이러한 블루투스 통신으로 받은 메시지(명령어)가 Valid 한지 파악한 후 XBee Module Hanlder에게 명령어를 전달한다. 명령어를 받은 XBee는 명령어를 해석한 후 목적지로 메시지를 forward한다. 목적지까지 1:1 직접 통신이 되지 않을 경우 위와 같이 여러 번 routing을 하여 최종 목적지의 XBee Device로 전송되게 된다. 메시지를 받은 상대방 Raspberry Pi는 이 메시지를 검사한 뒤 보내 Bluetooth 통신을 통해 본인 기기와 연결된 스마트폰으로 메시지를 forward하여 상대 스마트폰은 메시지는 최종적으로 수신한다.
시스템 구성요소(모듈)
◇ Android Application 1) Android UI : 사용자가 조작하는 채팅 어플리케이션 기반의 인터페이스 서비스. 2) Android Bluetooth Service : 사용자가 어플리케이션 인터페이스로 조작하는 기능들을 블루투스 통신을 통해 Raspberry PI 로 전송해주는 서비스. ◇ Terminal Device System 3) Bluetooth Module(OloraNT) : Android와 송수신하는 Raspberry PI의 블루투스 모듈. 4) Control Program(OloraGT): 패킷의 적합성을 검사하여 데이터무결성을 검사하는 모듈. 5) Xbee Module(OloraXB) : 명령어 패킷을 분석하여 실행하고, 외부 메시지를 최초로 수신하고 재조합하는 모듈. ◇ Device Cover 6) Hard Case : 물리적으로 연결된 Raspberry PI와 Xbee를 감싸며, 전원을 공급할 수 있도록 보조배터리를 포함한 케이스.
설계방법론
위와 같이 모듈 별로 나누어 각 파트를 먼저 선개발하도록 한다. 단, 개발하기에 앞서 모든 데이터 흐름에서 공통이 되는 사항은 먼저 정의를 하였다. 구체적으로는 첫 번째는 패킷의 구조이며, 두 번쨰는 사용하고자 하는 명령어의 형식 및 프로토콜이다. 뼈대가 되는 작업이기 떄문에 목표하고자 하는 바를 잘 예상을 해야 하는 중요한 작업이다. 기본 사항이 통일 된 이후 각 파트를 개발하고 부분적으로 테스트를 진행하여 처음 정했던 바와 달라진 점이 있으면 팀원들에게 알리고 수정을 하는 루틴을 계속 반복하였다. 각 부분(모듈)별로 테스트가 끝나고 나면 인접 모듈과 함께 연동하여 보다 큰 부분 테스트를 진행하며, 마지막으로는 전체 시스템 테스트를 진행한다. 계획(로드맵)이 딱 처음부터 정해진 것이 아니라 그때 그때 새로운 상황에 맞게 계획을 수정하며 진행한다는 점에서 ‘에자일 프로젝트’ 설계방법론에 가까운 방식을 취했다.
또한 이러한 협업을 편리하기 위해서 Git을 통하여 버전관리를 보다 수월하게 하였다.
요구사항 및 설계변수
- 요구사항은 상위항목인 level1, 그 하위항목인 level2로 구체화하였으며 후에 각 모듈별 해당 요구사항에 영향을 주는 요소인 설계변수를 설정하였다.
- H/W를 선택하여 결정되는 설계변수(즉, 설계변수==H/W종류)는 물품을 선택한 후에는 더 이상 설계할 부분이 아니게 된다. 따라서, 나머지 부분에 집중한다.
- 최종적으로 채택된 설계변수 값은‘2.5 최종설계안’에 설명이 되어있다.
성능
- 가. 송신거리
송신거리는 통신단말기 간 얼마만큼 떨어져도 통신이 가능한가의 척도이다. 이는 어떠한 하드웨어를 고르느냐에 따라서 크게 결정되기 때문에, 통신모듈을 고른 이후에는 설계변수가 아닌 고정변수가 된다.
- 나. 전송속도
전송속도는 통신단말기 간 얼마나 빠르게 데이터를 주고받을 수 있는지에 대한 척도이다. 구체적으로는 사용자가 전송버튼을 누른 이후에 상대방이 수신할 때까지의 걸린 시간을 나누는 것이 아니라, RF모듈에서 송출되어 나올 때부터의 시간을 기준으로 ‘전송속도’를 의미한다. 따라서 해당 요구사항은 어떠한 하드웨어를 고르느냐에 따라서 baseline이 크게 정해진다. 전송속도는 주변 전파 노이즈나 장애물 그리고 상대방과의 거리에 따라서 크게 달라지기는 하나 이는 설계변수가 아니므로, 결국에 설계변수는 어떠한 RF모듈을 고르느냐에 달려있다. 하드웨어를 고른 이후에는 고정변수가 된다.
- 다. 지속시간
지속시간은 배터리가 얼마나 오래 지속될 수 있는가의 척도이다. 먼저 어떠한 하드웨어(보드, 통신모듈)에 따라서 크게 달라지므로 하드웨어의 종류가 설계변수가 될 수 있다. 두 번째로, 전력소모는 소프트웨어가 얼마나 CPU를 사용하느냐에 따라서 크게 달라지므로 Android App의 대기모드 지속시간이 설계변수가 될 수 있다. 이외에도 프로파일링 툴을 이용해 어느 부분에서 CPU 자원이 필요 이상으로 낭비되는지 확인한다면 사용하는 ‘알고리즘’의 시간복잡도 또한 설계변수가 될 수 있다.
- 라. 기록저장성
기록저장성은 얼마나 많은 량의 정보(메타정보 포함)를 저장할 수 있느냐 척도이며, 본 프로젝트에서는 Android App 상에서 ‘데이터베이스용량’을 설계변수를 조절함으로써 기록저장성을 만족시킬 수 있다.
안정성
편의성
경제성
최종설계안
전체 설계안
내용
최종선택 설계변수
시나리오(다이어그램)
Android Application
Android UI
내용
Android Bluetooth Service
내용
Terminal Device System
내용
OloraNT
내용
OloraGT
내용
OloraXB
내용
Device Cover
평가
===개발 사업비 내역서 내용 ===제품평가(performance Test Result) 내용 ===향후 개선점 내용
부록
참고문헌
내용
외부 링크
내용