5조 - OLora

프로젝트 개요

기술개발 과제

국문 : 휴대용 무선 메쉬-네트워크 단말기

영문 : Portable Off-Grid Mesh Network Device

과제 팀명

Olora

지도교수

김태현 교수님

개발기간

2018년 9월 ~ 2018년 12월 (총 4개월)

구성원 소개

서울시립대학교 기계정보공학과 20138900** 이민*(팀장)

서울시립대학교 기계정보공학과 20134300** 권홍*

서울시립대학교 기계정보공학과 20134300** 김민*

서울시립대학교 기계정보공학과 20134300** 이명*

서울시립대학교 환경공학과 20138900** 이창*

개요

요약

 본 프로젝트는 독립된 네트워크 체계의 무전 송수신 장비를 이용해 재난시 안전통신망의 역할을 수행하고, 네트워크 기반이 갖춰지지 않은 지역이나 복구 시간이 장기간이 될 경우에 대체 통신망으로써 사용될 수 있으며, 일반인들도 기술적 혜택을 볼 수 있도록 쉽게 접근 및 사용가능한 전용 어플리케이션을 개발하는 것을 목표로 한다.

개발 배경 및 효과

 21세기에 네트워크가 안 되는 경우 많은 불편한 점을 개선해보고자 하는 생각으로 아이디어를 제시했다. 현재 네트워크 구축이 워낙 촘촘하고 광범위하게 되어있어서 웬만해선 인터넷 끊길 일이 잘 없다. 그러나 도시 지역이 아닌 자연, 특히 사람들이 자주 찾지만 네트워크 및 각종 인프라가 구축되기 어렵거나 제한적인 곳에선 어떻게 정보를 주고받을 수 있을지 고민해보았다. 
 ICT 시사용어 뉴스에서 ‘메시 네트워크(Mesh Network)’1)는 다 대 다 기기 간 통신을 지원하고, 대규모 디바이스 네트워크 생성에 최적화되어 있다며, 차세대 이동통신, 홈네트워킹, 공공 안전 등 특수 목적을 위한 새로운 방식의 네트워크 기술이라고 설명하고 있는 것을 보았다. 그리고 이 메시 네트워크는 건물이나 사무실 단위에서 대규모 공원이나 리조트, 항만 등지에서 유용하게 사용되어질 수 있다고 하였다. 우리의 제품은 산악 지대나 해안의 섬 등 기존 네트워크가 없을 시 무선으로 대체 네트워크를 제공함으로써 이 단말기를 들고 있는 사용자는 모바일과 연동하여 다른 사용자들과 자유로이 의사소통을 할 수 있으며, 비상 상황 시 신속하게 자신의 상황을 알릴 수 있다. 특히 비상 상황에서는 전원이 충분하지 않을 때에 문제가 될 수 있는데, Bluetooth를 적용하여 전원 사용량도 최소화 할 수 있으며, 비행기 모드에서도 사용이 가능하여 전원을 오래 유지시킬 수 있다. 
 지인들 혹은 단체로 해외여행 시, 로밍 연결이 잘 안될 때 혹은 로밍을 하지 않았을 때 단체 내에서의 독립된 네트워크로 편리하게 의사소통할 수 있다. 현재 해외여행 시 지하철만 이용하려 해도 통신 서비스가 안 되는 경우가 많은데, 이러한 경우에도 편리하게 사용할 수 있다. 그리고 우리가 관심 가지고 있는 집단은 패키지 여행사이다. 특히 해외 패키지여행을 신청한 관광객들에게 이 제품을 나눠주면 로밍을 신청하지 않은 관광객 혹은 통신이 잘 되지 않는 장소에서도 가이드가 계속해서 정보를 나눠줄 수 있고, 각종 안전사고를 대비할 수 있도록 안내를 해줄 수 있기 때문이다. 사람이 너무 많아서 통신망이 사고가 났을 때2), 예를 들어 불꽃축제 현장이나 논술 시험 등 사람이 몰리는 상황에서 기존의 통신망이 작동이 되지 않을 경우가 있다. 이러한 경우에 제품 사용자들끼리 의사소통을 할 수 있게 하고 안전사고가 발생했을 때 독립된 네트워크로 신속하게 사고 상황을 알려 대처할 수 있다.

시나리오

 사용자는 기존 상용 통신망 사용이 불가할 때 위와 같은 방식으로 서로 통신하게 된다. 메시지의 생성부터 최종적으로 수신되는 과정을 살펴본다면, 먼저 사용자는 기존 상용 메신저(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 최종설계안’에 설명이 되어있다.

성능

“성능” 은 주로 (H/W)성능에 의해 크게 영향을 받는 부분에서의 ‘성능’이다.

송신거리

송신거리는 통신단말기 간 얼마만큼 떨어져도 통신이 가능한가의 척도이다. 이는 어떠한 하드웨어를 고르느냐에 따라서 크게 결정되기 때문에, 통신모듈을 고른 이후에는 설계변수가 아닌 고정변수가 된다.

전송속도

전송속도는 통신단말기 간 얼마나 빠르게 데이터를 주고받을 수 있는지에 대한 척도이다. 구체적으로는 사용자가 전송버튼을 누른 이후에 상대방이 수신할 때까지의 걸린 시간을 나누는 것이 아니라, RF모듈에서 송출되어 나올 때부터의 시간을 기준으로 ‘전송속도’를 의미한다. 따라서 해당 요구사항은 어떠한 하드웨어를 고르느냐에 따라서 baseline이 크게 정해진다. 전송속도는 주변 전파 노이즈나 장애물 그리고 상대방과의 거리에 따라서 크게 달라지기는 하나 이는 설계변수가 아니므로, 결국에 설계변수는 어떠한 RF모듈을 고르느냐에 달려있다. 하드웨어를 고른 이후에는 고정변수가 된다.

지속시간

지속시간은 배터리가 얼마나 오래 지속될 수 있는가의 척도이다. 먼저 어떠한 하드웨어(보드, 통신모듈)에 따라서 크게 달라지므로 하드웨어의 종류가 설계변수가 될 수 있다. 두 번째로, 전력소모는 소프트웨어가 얼마나 CPU를 사용하느냐에 따라서 크게 달라지므로 Android App의 대기모드 지속시간이 설계변수가 될 수 있다. 이외에도 프로파일링 툴을 이용해 어느 부분에서 CPU 자원이 필요 이상으로 낭비되는지 확인한다면 사용하는 ‘알고리즘’의 시간복잡도 또한 설계변수가 될 수 있다.

기록저장성

기록저장성은 얼마나 많은 량의 정보(메타정보 포함)를 저장할 수 있느냐 척도이며, 본 프로젝트에서는 Android App 상에서 ‘데이터베이스용량’을 설계변수를 조절함으로써 기록저장성을 만족시킬 수 있다.

안정성

“안정성” 은 내부적으로 시스템의 failure를 어떻게 예방하는 정도, 그리고 외부적으로는 데이터의 송수신이 희망목적지에, 온전하게 전달되느냐를 정의한다.

내부 시스템 안정

내부 시스템 안정의 목표는 단말기 내부의 프로세스들이 비정상적으로 과다하게 자원을 사용하거나, 다른 프로세스의 입력을 계속 기다려 프로세스가 정지해버리거나, 하는 등 정상적인 시스템 운영을 저해하는 요소를 방지함에 있다. 예를 들어 무작정 입력 대기를 방지하기 위해 타임아웃시간을 두는데, 타임아웃시간이 지나치게 길면 오랜 시간 동안 프로세스가 정지되어 다른 의존성 있는 프로세스도 덩달아 딜레이될 수 있다. 그렇다고 타임아웃이 너무 짧아버리면 빈번하게 외부 신호를 놓쳐버리고, 이렇게 놓친 신호를 다시 잡기 위해서 추가적인 대책이 요구되므로 복잡성이 증대된다.

데이터 무결성

데이터 무결성은 해당 데이터가 깨져서 오지 않았는가, 혹은 변조되었는지 여부를 나타내는 척도이다. 어떠한 hashing 방식을 사용하느냐에 따라서 데이터를 변조하기가 어려운가가 결정되므로 hashing 방식이 설계변수가 된다.

안정된 송수신

안정된 송수신은 단말기 내부적으로는 본 프로세스와 외부 프로세스와의 연결이 여러 상황에서도 안정되게 연결이 가능한가를 설명하는 척도이다. 외부적(XBee)으로는 온전하게 진짜 발신자로부터 온 메시지들을 잘 구분하고 순서를 맞추어 원래 메시지를 재구성할 수 있느냐를 나타내는 척도이다. 또한 하드웨어적으로는 안테나의 종류에 따라서 수신율이 달라질 수 있으므로 안테나 종류가 설계변수가 될 수 있다.

편의성

“편의성” 사용자가 본 기기와 시스템을 사용했을 때 어느 정도로 거부감 없이 편리하게 사용할 수 있느냐를 나타내는 척도이다.

친숙도

친숙도는 시간적인 측면이 아닌 레이아웃 측면에서의 친숙도를 지칭하는 말이다. Android App 단에서 Window 구성(레이아웃)이 어떻게 되어있느냐에 따라서 사용자가 느끼는 편리함의 정도는 달라진다. 탭의 수가 너무 많으면 직관성이 떨어지고, 탭의 수가 너무 적으면 기능을 구분하기가 어려워지므로 적당한 개수의 ‘탭 개수’를 고르는 것이 좋다. 두 번째로, 실질적으로 보드 회사가 제공해주는 명령어 set 중 사용자가 실제로 편리하게 쓸 만한 명령어 set을 간추려서 사용자에게 제공해야 쓸데없이 많은 명령을 내리는데 시간을 낭비하지 않을 수 있다. 따라서, 필요한 명령어의 종류와 수가 친숙도를 위한 중요한 설계변수가 된다.

응답성

응답성은 사용자가 명령을 내린 후 그에 대한 결과가 얼마나 지체되지 않고 신속하게 알림이 되느냐를 평가하는 척도이다. 예를 들어서, Raspberry Pi에서는 여러 개의 자식패킷으로 쪼개어 날아오는 메시지를 database에 저장하게 되는데, 무선통신 특성 상 패킷이 유실될 수 있기 때문에 무조건적으로 모든 자식패킷들을 기다리는 것은 올바르지 않다. 따라서, database의 어떤 메시지 entry 가 기준시간보다 오래되었는지 체크를 하게 되는데 너무 상한을 너무 높게 잡게 되면 실제로 발송된 시간이랑 수신하게 되는 시간이 크게 차이 날 수 있으므로 적당히 짧은 상한(flushout 시간)을 설계변수로 잡아야 좋은 응답성을 얻을 수 있다.

휴대성

휴대성은 얼마나 가지고 다니기 쉬운 가에 대한 척도이며, 이는 물리적인 단말기의 크기에 의해 전적으로 결정된다. 먼저 내부에 감싸지는 하드웨어의 종류에 의해 크게 좌우되며, 실제로 디자인하는 요소인 케이스와 내부기기의 유격 및 케이스 두께가 휴대성을 영향을 주는 설계변수가 된다.

경제성

“경제성” 은 기기 자체의 가격과 디바이스 수명에 영향을 주는 내구도에 대한 요소다.

내구도

내구도는 구입 이후 얼마나 오랫동안 특별한 고장 없이 쓸 수 있느냐의 척도이다. 여기서는 주로 H/W적인 부분에서의 내구도를 다루므로 설계변수는 케이스 두께와 케이스의 재질이다.

가격

가격은 내부에 들어가는 전자기기(H/W)의 종류와 그리고 케이스 크기를 어느 정도로 하느냐에 따라서 달라지므로 이 둘이 설계변수라고 할 수 있다.

최종설계안

전체 설계안

최종선택 설계변수

각 최종 선택 값 선정 이유는 각 모듈 설계안에 쓰여 있음

시나리오(다이어그램)

1. 블루투스 페어링

① 사용자는 Android User Interface를 통해서 블루투스 희망하는 Olora 기기에 블루투스 페어링을 요청한다.

② ~ ③ 블루투스 페어링 요청은 블루투스 서비스 프로세스에게 forwarding된다.

④ 블루투스 서비스는 목적 기기(Olora)기기에게 페어링 요청을 한다. 실패 시 최대 3번까지 자동 재연결을 시도한다. 연결 요청이 OloraNT의 Main Task 프로세스에게 전달되면 Main Task는 Spin Task에게 OloraNT의 제어권을 넘겨주고, 1:1 블루투스 페어링을 보장하기 위해서 연결이 끊어지기 전까지는 추가적인 블루투스 페어링을 막는다. 또한 모든 Task들은 bluetooth 연결을 기다리는 “waiting” 상태가 아닌 “connected” 상태로 바뀌게 되어, connected 상황일 때 정의되는 datapath를 쓸 수 있게 된다.

⑤ 블루투스 페어링이 완료되었다는 것을 Phone쪽으로 알려주는 것은 Bluetooth 하위 layer에서 자동적으로 처리해주므로 이로서 Bluetooth Pairing이 완료된다.

2. 채널 설정 (성공)

① ~ ③ “블루투스 페어링 과정”과 동일.

④ 블루투스 페어링이 되어있다는 가정 하에, 이제 OLoraNT의 Input Task는 phone쪽으로부터 블루투스 패킷을 받아들인다. 이때 hash value가 맞는지 검사를 하고, 올바르면 ‘5,6,7,8...’ 경로를 진행하게 된다.

⑤ Input Task는 내부 OloraNT 내부 공용 저장소인 Stream Queue에 받은 패킷을 넣는다.

⑥ ~ ⑦ Spin Task는 Stream Queue에서 받은 패킷을 꺼내어 OloraGT로 forwarding 한다.

⑧ Gate에서 하는 일은 패킷이 OloraNT(자기왼쪽)에서 왔는지 OloraXB(자기오른쪽)에서 왔는지 체크하고 어느 방향으로 보내줘야 되는지 인지하고 그 방향으로 보내주는 철도 교환기 같은 역할의 프로세스다. 이때 방향은 XBee방향이므로 OloraXB에게 forwarding 한다.

⑨ OloraXB의 Command Listener는 받은 패킷을 Command Queue에 적재하고 다음 명령 패킷을 기다린다.

⑩ Executor는 CmdQueue에서 패킷을 빼와 해석한 뒤, 해당 명령어루틴을 실행한다.

⑪ 명령어에 해당 하는 루틴을 실행하고 나면 Executor는 명령어 처리 결과를 Command Returner에게 forwarding 한다. 이때 순차적인 명령을 강제하기 위해서 사용자측에서 명령어결과를 받았다는 것을 신호를 보내기 전까지 Executor는 잠시 대기하고 있는다.

⑫ Command Returner는 OloraGT 에게 패킷을 forwarding 한다.

⑬ 패킷을 받은 OloraNT의 Output Task는 Hash value를 검사하고 올바르다면 “14,15,..” datapath로 패킷을 넘긴다. 만약 hash value가 틀리다면 패킷을 drop한다.

⑭ ~ ⑲ Anroid측에서는 받은 정보를 database에 저장한 후, controller는 이를 최종적으로 사용자가 볼 수 있도록 UI에 표시해준다.

2. 채널 설정 (실패)

① ~ ⑤ Set Channel Success 과정과 동일

⑤ Input Task는 Hash Value가 틀렸음을 공지하고, 이에 따라 Stream Queue에 있는 패킷은 “SpinTask -> Gate -> Command Listener ...” 경로를 따라가는 것이 아니게 된다.

⑥ ~ ⑦ Stream Queue의 값은 Output Task가 대신 빼내어 Phone쪽으로 반환한다.

⑧ ～ ⑩ Database를 거치지 않는다는 점에서 “success”경우와 차이가 있을 뿐이다.

3. 송신

① ～ ⑩ Executor 까지 오는 모든 경로가 일반적인 command와 동일하다.

⑪ Executor는 메시지 송신을 11(Right)로 한 뒤에 결과를 11(Left)~19 경로로 흘린다. 바깥으로 내보내는 패킷은 1008바이트(56+952) 짜리 블루투스 패킷이 아니라 256바이트(56+200) 짜리 XBee 패킷으로서 Executor는 바깥으로 내보낼 때 원본 메시지를 여러 자식(child) XBee 패킷으로 나누어 보내게 된다. 이때 반드시 받는 측에서 원본 메시지 재조합이 가능하도록 Timestamp와 SEQ를 자식들의 공통헤더에 넣어서 보내야 한다.

⑪(Left) ~ ⑲ 일반적인 command 처리 결과패킷이 처리되는 과정과 동일하다.

4. 수신

① 새로운 패킷이 올 경우 Callback 함수에 의해 새 패킷이 MsgQueue에 들어가게 되고, Message Handler는 평소에 하던 일(오래된 메시지 entry 확인하여 방출하는 작업)을 중지하고 MsgQueue에서 새로운 메시지를 갖고 온다.

② Message Handler는 형제 XBee패킷이 모두 모였거나, 시간이 오래된 entry를 Message Returner 쪽으로 pipe로 방출한다.

③ ～ ④ 방출된 메시지패킷은 OloraGT를 거처서 OloraNT의 Output Task까지 도달한다.

⑤ Output Task는 Hash Value가 valid 하면 “5~10” path를 따라 패킷을 보내고, 패킷 hash value가 mismatch할 경우 OloraXB로부터 온 패킷을 drop한다.

Android Application

가. 개발 목표 및 기능 설명

안드로이드 어플리케이션은 XBee network을 이용한 통신을 사용자 친화적으로 표현하기 위해 제작된다. 그러므로 채팅 어플리케이션으로써 대중에게 친숙한 ‘카카오톡’ 어플리케이션의 UI를 벤치마킹 하였고, 채팅기능과 동시에 Bluetooth 통신, Xbee control을 지원해야 하므로 아래와 같은 기능이 필요하다.

1) Bluetooth 장치 검색/연결 기능

주변의 블루투스 기기 리스트를 출력하고 사용자가 사용할 Olora 단말기를 선택하면 단말기와 Bluetooth로 연결한 뒤 통신가능 상태로 만들 수 있어야 한다.

2) 주파수 채널 설정 기능

XBee 통신을 위한 configuration은 HP, ID, CM를 각각의 범위에 맞게 입력하여 같은 HP, ID, CM를 가지는 단말기끼리 통신할 수 있다. Olora는 이러한 설정의 복잡성을 줄이기 위해 CM은 고정하고 HP와 ID를 하나의 Integer로 표현하여 ‘채널’로 표현하였다. 사용자는 ‘채널’이라는 하나의 Integer만을 입력하여 Xbee의 local configuration을 수행할 수 있다.

3) 같은 주파수 채널을 이용하는 사용자 검색 기능

XBee의 Discovery 기능을 사용하도록 명령을 보내고, 사용자가 설정한 Discovery timeout 만큼 대기한다. Olora 단말기로부터 Discovery의 응답이 도착하면 이를 적절히 파싱하여 검색된 사용자의 정보를 DB에 저장하고 ‘친구 목록’ View에 나타낸다.

4) 채널 내 전체 채팅/ 단일 채팅 기능

같은 ‘채널’의 모든 사용자에게 Broadcast 메시지를 전송하는 ‘전체 채팅방’과 지정한 mac address를 가진 상대에게만 Unicast 메시지를 전송하는 ‘개인 채팅방’을 구분한다.

5) 각종 설정 기능

푸시 알람 여부, 진동 및 소리 알람 여부, 채널 검색 시간 (Discovery timeout), 데이터 보유 기간(DB에 저장 될 최대 대화 데이터 용량)을 사용자가 ‘설정’탭에서 설정할 수 있다.

6) 로컬 데이터베이스 저장 기능

서버를 사용하지 않기 때문에 설정, 채팅 데이터 등의 데이터를 저장할 수 있는 로컬 데이터베이스를 구성한다.

안드로이드 어플리케이션 부분에서 설정되어야 하는 설계변수는 다음과 같다.

XBee 기능 추상화 Level Level 1 : XBee에서 사용하는 이름을 적용하고 모든 기능을 그대로 사용

Level 2 : XBee에서 사용하는 이름을 사용자 언어로 추상화하고 모든 기능을 그대로 사용

Level 3 : XBee에서 사용하는 이름을 사용자 언어로 추상화하고 모든 기능을 사용하되 기능에 필요한 입력변수를 축소하여 표시

Level 4 : XBee에서 사용하는 이름을 사용자 언어로 추상화하고 모든 기능을 사용하되 기능에 필요한 입력변수를 제한. (디폴트 값으로만 동작)

Level 5 : XBee에서 사용하는 이름을 사용자 언어로 추상화하고 시나리오대로만 몇가지 기능들이 연속적으로 동작하도록 제한

클래스 다이어그램

Andorid Application을 추상화하여 도식화한 클래스 다이어그램이다. 검은 BOX로 표시된 클래스는 안드로이드 화면에 나타나는 View를 구성하는 클래스이며 그 중 Bluetooth_connect, Chatting_Room_List, Connected_User_List, Setting 클래스는 View Pager 기법으로 묶인 Fragment View로써 Main_Activity의 View를 상속받는 클래스들이다.

Bluetooth_Service 클래스는 RaspberrPi와 블루투스 통신을 담당하며 MainActivity와 Chatting_Room에 bind 되어 있다. 각 Fragment 탭에서 이루어진 조작은 MainActivity를 통해 Bluetooth_Service에 전달되어 조작에 적합한 XBee command로 변환 후 블루투스 소켓을 통해 전송한다. XBee command의 request는 Bluetooth_Service가 해석하여 MainActivity를 통해 각 적합한 Fragment에 전달한다.

Chatting_Room과 bind한 것은 채팅 메시지를 전송하기 위함이다. Chatting_Room은 Chatting_Room_List에서 생성한 List Item이지만 MainActivity와는 별개의 Activity이다. 그러므로 Chatting_Room_List를 생성할 때 Bluetooth_Service와 직접 bind 해주어 사용자가 전송하고자 하는 메시지 데이터를 곧바로 Bluetooth_Service로 전달할 수 있게 한다.

Android UI

UI설계는 개념설계와 동일하게 제작한 뒤, UI 사용성 평가 체크리스트를 이용한 설문조사 결과로 추후 개선한다.

Android Bluetooth Service

안정성에 해당하는 요구사항에서 도출한 설계변수인 재연결 프로세스를 고려한 설계를 하였다. 재연결 프로세스 방식의 설계변수로는 1. 끊어지면 알림만 보내기, 2. 끊어졌을 시 사용자 의사를 묻고 재연결, 3. 끊어졌을 시 자동 재연결 로 3 가지를 고려하였다. 원하지 않는 연결 끊김 상태의 시간을 최소화 하기 위해 재연결이 반드시 필요하다. 사용자가 연결이 끊어짐을 인지하지 못했을 상황을 우려하여 사용자 의사를 묻지 않고 자동으로 재연결을 하는 프로세스를 선택하였다.

1) 라즈베리파이와 블루투스 연결성

기존의 연결 상태 관리는 연결이 끊어지면 단순히 사용자 알림을 주는 것에 그쳤다. 안드로이드 기기의 노후도에 따라서 가끔 끊기는 일이 발생하는데 상시 대기 중이어야 하는 메신저에서 이러한 끊김은 치명적인 불편함이다. 평가항목인 사용자 편의성을 충족하기 위하여 안드로이드에서 재연결 프로세스를 추가하였다. 먼저 연결이 끊어지면 기존처럼 사용자 알림을 준다. 그리고 재연결을 시도하며 추가 알림을 준다. 라즈베리파이의 블루투스 주소가 저장되어있으므로 장치 탐색과정은 생략 가능하다. 이 때, 사용자 안드로이드의 블루투스 문제가 있을 수 있으므로 먼저 안드로이드의 블루투스 장치를 확인한다. 문제가 없으면 라즈베리파이로 연결을 시도한다. 성공한다면 다시 연결하고 재연결 성공 알림을 주고, 실패한다면 3회 반복하는데 이때는 라즈베리파이의 블루투스가 꺼졌다고 판단하고 라즈베리파이의 전원을 다시 켜라는 알림을 준다.

<연결 상태 관리 다이어그램>

2) 데이터 유실 관련

테스트를 진행하면서 송수신 시 데이터가 가끔 소실되는 경우가 있다. 데이터가 손상되거나 혹은 완전히 유실되는 경우로 예측했으나, 두 경우 모두 인지하기 어려웠다. 평가항목인 무결성을 충족하기 위해 패킷구조와 길이를 다소 변경하였다. 내부 테스트를 거치면서 패킷의 크기를 확인한 결과, 기존 1024 bytes를 받기를 기대하고 있었지만 1008 bytes를 받고 후에 16 bytes를 받는 현상을 발견하였다. 이 때문에 데이터가 유실되고 패킷을 해석하는데 오류가 있었음을 알 수 있었다. 패킷의 크기를 1008 bytes로 변경하고 난 후 내부 테스트 결과는 유실되는 경우는 없었다.

<패킷 받을 시 데이터 쪼개지는 과정>

추가적으로 데이터가 깨지는 경우를 인지하기 위해 데이터 암호화 과정을 거쳤다. 이 때 MD5 라는 해쉬함수를 사용한다. 메시지에 해당하는 데이터를 MD5 해싱 이후 그 결과 값을 패킷헤더에 있는 16 bytes 크기의 공간에 담아서 함께 보낸다. 이렇게 라즈베리파이로 전송하여 라즈베리파이가 해싱한 값과 비교하여 일치함을 확인한다.

<변경 전 과 변경 후 패킷 사이즈>

3) 안드로이드 백그라운드 구동

설계사항인 안정적인 연결상태와 지속적인 데이터 통신이 가능하도록 안드로이드 운영체제의 백그라운드 프로세스 기능을 이용하여 그곳에서 스레드를 열고 통신을 위한 소켓을 생성하여 통신할 수 있는 상태로 만들었다.

4) I/O 스레드 내의 블루투스 소켓을 통한 통신의 시나리오.

보낼 때에는 전송 실패의 경우가 있으므로 이를 처리하고 성공하면 데이터베이스를 업데이트하여 채팅방에 표시한다. 받을 때에는 우선 데이터베이스를 업데이트 수행한 후 사용자가 채팅방에 있을 경우 바로 채팅방에 표시하고 그렇지 않다면 메시지가 왔다는 알림을 준다. 마찬가지로 1008 bytes를 받아들이는 것으로 변경 되었다.

5) 대기모드 지속시간

성능에 해당하는 요구사항인 서비스 지속시간에 대한 설계변수로 대기모드 지속시간을 뽑았다. 전력 사용량과 관련이 있는데, 안드로이드 어플리케이션이 배터리를 일부 점유할 것이라고 예상했다. Olora 서비스는 블루투스 모듈과 백그라운드 스레드를 상시 구동하고 있으므로 장시간 메모리 점유를 할 가능성이 있다. 메모리 점유는 배터리 사용량의 주범이 될 수 있으므로 대기시간을 줄여야 할 필요성이 있다. 그러나 필요할 때 메시지를 받을 수 있게 대기시간을 너무 짧아도 안 된다. 고려한 대기모드 지속시간의 변수로는 1 분, 10 분, 30 분, 60 분, 120 분 이 있었는데, 배터리 사용량과 사용자가 불편함을 느끼지 않을 정도의 최적의 시간으로 60 분 정도라고 예상하여 선정하였다. 어플리케이션은 60 분 동안 어떠한 메시지를 보내거나 받지 않으면 알림을 주며 구동을 종료한다.

위 그림은 선정한 설계 변수를 토대로 대기모드 지속시간을 적용한 설계이다.

Terminal Device System

OloraNT

1) Overview

OloraNT는 서버와 클라이언트가 1:1로 매칭되며, 블루투스를 통해 들어온 패킷을 사용자 공간에 출력하는 범용성을 가진 소프트웨어이다. OloraNT는 MD5 Hash를 검증하여 패킷의 무결성을 검증하고, 만일 해쉬 값이 불일치하여 무결성이 붕괴되었다고 판단할 경우, 패킷이 BROKEN 되었음을 패킷의 송신자에게 반송하여 알린다. 또한 보안성을 위해 SRC와 DST어느 한쪽이 0인 내부 패킷의 경우 모두 차단하며, 네트워크 플러딩을 예방하고, Land Attack을 방지하기 위해 수신지(Source)와 목적지(Destination)가 같은 패킷의 경우 버린다. OloraNT의 경우 자동응답 유한 오토마톤(Finite Automaton)으로써 대기(Waiting), 연결(Connection), 연결-대기(Pending), 종료(Exit)의 4가지 상태로 구분된다. OloraNT의 경우 상태가 안정적임이 확인되어 현재 개발 완료 상태이다.

2) Phase Description

A) Waiting

보안을 위해 OloraNT는 Waiting 상태일 때만 블루투스 연결을 허용하며, 오직 Waiting 상태일 때만 다른 기기에서 발견 및 스캔이 가능하다. 클라이언트가 접속 요청하기 전 상태로써 자신의 상태를 점검하고, 시스템으로부터 오는 신호를 받는다. 클라이언트로부터 접속 요청을 받으면, 블루투스 장치를 스캔 불능으로 만든 후에 Connection 상태로 천이한다.

B) Connection

정상적인 클라이언트 접속이라면 세션을 형성하고 Connection 상태에 있으며, 그렇지 못한 경우 Pending 상태로 천이한다. 또한 사용자에 의해서 종료된 경우에도 Pending으로 천이한다. 만일 Connection 상태에서도 시스템 내부에서 종료 시그널이 발생하면 시스템 문제로 인해 연결을 종료함을 사용자에게 알리고, Exit 상태로 천이한다. Connection 상태에서는 클라이언트와 단말기 간의 데이터 교환 작업을 수행한다.

C) Pending

Connection 상태에서 종료한 이후, OloraNT의 내부 쓰레드들이 동기화를 위해 자원을 정리할 시간을 보내는 상태이다. 대부분 100μs의 짧은 시간동안 Pending 상태에 머무르며, 동기화가 완료되고 종료 시그널을 받지 않았다면 Waiting 상태가 된다.

D) Exit

어떤 상태에서도 시스템 내부에서 종료 시그널을 받게 되면, OloraNT 소프트웨어는 종료상태가 되며 자원 정리를 한 후, 프로세스를 종료한다.

3) Software Components Description

A) WatchDog

OloraNT 내부에서 운영되는 Task들을 통제하며, 각 Task들의 상태를 업데이트한다. Event-Driven 방식이며, Event가 발생하지 않을 경우 CPU 클럭에 의존하여 주기적으로 업데이트한다. 따라서 어떤 CPU를 사용하더라도 oloraNT가 사용하는 CPU 점유율의 차이가 적다.

B) Main Task

프로세스를 초기화하고, 각 Task들을 Thread를 통해 생성한다. 이후에 루프를 순환하면서, 상태에 따라 클라이언트로부터 접속 요청을 받으며, 성공적으로 연결이 되면 블루투스를 스캔 불능으로 만들고, Spin Task로 제어권을 넘긴다. Spin Task로부터 제어권이 복귀하면 블루투스 장비를 스캔 가능 상태로 만들며 다음 연결을 대기한다.

C) Input Task

평소에는 상태 점검을 수행한 뒤 대기하지만, Connection으로 천이하게 되면, 클라이언트로부터 받은 패킷을 내부 사용자 공간으로 넘겨주기 위해 내부 큐 스트림에 패킷을 삽입한다. 이 과정 중에 해쉬 무결성에 대해 점검은 하지만 결과를 사용자에게 통보하지 않는데, 블루투스의 응용 프로토콜인 RFCOMM이 TCP처럼 데이터 송신에 대해 안전한 연결을 담당하기 때문이다.

D) Output Task

평소에는 상태 점검을 수행한 뒤 대기하지만, Connection으로 천이하게 되면, 사용자 공간으로부터 받은 패킷을 클라이언트에게 송신한다. 만일 해쉬 무결성이 붕괴되면 패킷의 송신자에게 BROKEN FLAG를 설정하며, 데이터가 온전하지 못함을 알린다.

E) Spin Task

Connection 상태일 때 제어권을 받아 실행되며, 내부 큐 스트림에 있던 패킷을 사용자 공간에 전달하는 역할을 수행하며, 사용자가 갑작스럽게 연결을 종료한 이후에도 이미 들어온 패킷을 안전하게 전송한다. Pending 상태가 되거나 Exit 상태로 천이하게 되면 Main Task에게 제어권을 넘긴다.

4) Working Mechanism

A) Monitoring Mechanism

WatchDog Task는 OloraNT 내부에서 운영되는 Task들을 통제한다. 시스템 폴링을 통해 주기적으로 디스크립터 상태를 점검하고, Task들의 상태를 업데이트한 후, Futex 시스템 콜과 Signal을 통해 Task에게 전파하며, 각 Task들은 갱신된 상태에 따라 작업을 처리한다. Phase_Waiting인 경우에만 Main Task를 감시하며, 그 이외의 경우 Main Task를 멈추고, 동작하는 Spin Task를 점검한다.

B) Packet Flow Mechanism

Phase가 Waiting의 경우 클라이언트로부터 접속 요청을 받으면 WatchDog 내부의 상태 단계를 상승하고, Main Task에서 Spin Task로 제어권을 넘기므로 내부의 패킷 흐름이 발생하지 않는다.

Phase가 Waiting이 아닌 경우, 즉 Connection 상태인 경우에 패킷은 Input Task에서 받으며, In_Stream 큐에 패킷을 삽입한다. 한편 클라이언트에게 패킷을 보내는 역할을 하는 Output Task에서 현재 사용자에 대해 에러가 발생하거나, 또는 무결성이 붕괴된 경우에 In_Stream 큐에 패킷을 삽입하여 송신자에게 되돌려 보낸다. Spin Task는 In_Stream 큐에 삽입된 패킷을 꺼내고 사용자 공간으로 보낸다.

OloraGT

나. OloraGT(Olora GaTeway)

나.1) Overview OloraGT는 OloraNT와 OloraXB를 이어주는 가교 역할을 수행하는 프로세스이다. OloraNT에서 제공하는 라이브러리는 보안성이 높다고 알려진 AES256-cbc와 공개키 기반의 RSA의 암호화를 지원한다. 쉽게 접근할 수 있도록 PyPI에 pyolora 항목으로 등록되었다. pyolora모듈은 C확장으로써 OloraGT에서 사용된 언어인 Python과 연동한다. OloraGT는 OloraNT의 라이브러리와 정의를 기반으로 하여 작성되었다. 기존 설계 도안에서의 Certification Server 역할을 수행한다.

나.2) Working Mechanism

A) Packet Flow Mechanism

OloraGT는 Packet의 입력 위치에 따라 도착 디스크립터가 다르다. 싱글 프로세스. 싱글 쓰레드로 구성된 OloraGT는 무한 루프의 위험성이 존재하고, 효율성을 저하시키는 하드 코딩을 방지하고자, 디스크립터의 변화를 감지하여 변화가 있을 경우 알려주는 select() 함수를 이용하여 싱글 프로세스의 한계인 유연성 없는 FIFO를 극복한다.

<그림 Valgrind profiling tool을 이용한 함수 호출 맵>

<그림 WatchDog의 함수호출 맵>

1) 특정한 함수가 오랫동안 시간을 차지하지 않으며 각각 위치와 역할에 맞게 고루 분포하고 있다. 2) 모든 Task 중에 가장 시간을 많이 사용하는 Task인 WatchDog의 경우 제어 항목에 관한 함수의 소비시간이 가장 많으며 이는 정상적인 동작 과정이다. 3) 메모리 누수 점검 결과 누수 현상은 발생하지 않는다.

OloraXB

가. 내부 프로세스 설명

OloraXB 내부프로세스

OloraXB 관련 전체 요구사항 및 설계변수

(1) Command Listener : 사용자 명령어를 받는 프로세스

Command Listener는 사용자로부터 pipe로 명령어 패킷을 받아 command queue라는 명령어 저장소에 넣어주는 프로세스다. 사용자 명령어는 비동기적으로 오게 되므로 Command Listener >> Command Executor 사이의 IPC는 pipe가 아닌 Queue를 사용하는 것이 적합하다. 두 번째로, Command Listener는 다른 프로세스가 죽게 될 경우 다시 살려주는 역할 및 terminal process와의 브리지 역할을 하는 프로세스를 수행한다.

관련 요구사항/설계변수 : 빠른 명령어처리에 대한 ‘응답성’을 위하여 ‘외부IPC방식’은 전용 Command Listener를 사용하여 pipe로 연결하였다. 순차적인 명령어 처리를 한다고 해서 Command Executor가 모든 일은 다 처리하도록 할 경우에 약간의 delay가 발생하게 된다. 또한 Command Listener 프로세스를 별도로 두어도 평소에 외부 명령어가 들어오지 않을 때는 spinlock하지 않고 sleep 상태로 있으므로 추가적인 자원소모가 크지 않다.

(2) Command Executor : 사용자 명령어를 실행하는 프로세스

Command Executor는 Command Queue에서 명령어 패킷을 하나씩 꺼내서 해당되는 명령어를 처리하고 그 결과를 pipe를 통해 Command Returner에게 보내주는 프로세스다. 두 번째, 비동기적인 외부 사용자 메시지를 처리하는 Message Callback 함수가 Executor에 정의되어 있으며, 이때 Message Callback 함수는 받은 메시지를 Message Queue에 넣어준다.

관련 요구사항/설계변수 : ‘내부 시스템 안정’을 위하여 설계변수인 ‘명령어처리방식’은 ‘순차적처리’로 설정하였다. 병렬로 처리할 경우 명령어 처리가 빠를 수 있으나 사용자의 명령이 병렬로 처리해야할 만큼 빈번하지 않고, 병렬처리는 semantic 오류가 발생할 수 있다는 점을 감안하면 ‘순차적’으로 명령어를 하나씩 처리하는 방식이 좋다. 이때 순차적 처리를 위하여 명령어 처리 루프 안에 있는 모든 프로세스들은 lock variable로 강제로 동기화된다. 두 번째로, 요구사항인 ‘응답성’을 위하여 XBee간 ‘패킷크기’는 가변적으로 전송함으로써 필요이상의 패킷사용을 방지한다.

(3) Command Returner : 사용자 명령어 처리 결과를 돌려주는 프로세스

Command Returner는 Command Executor가 명령어를 실행한 결과를 사용자(폰)에게 보내주는 프로세스다. 상대방으로부터 비동기적으로 온 메시지의 처리( cf : Message Returner)보다 사용자 본인이 내린 명령어에 대한 결과처리를 우선순위로 두어 사용자 명령어의 쾌적한 처리를 보장한다. 이때 세마포어와 lock 변수를 사용하여 구현한다.

관련 요구사항/설계변수 : 더 빠른 ‘응답성’을 위하여 설계변수인 ‘내부IPC’는 pipe를 썼다. 두 번째로 사용자 명령어에 대한 ‘응답성’을 우선순위에 두기 위해서 설계변수인 ‘IPC스케줄링방식’은 Command Returner가 외부 pipe 사용에 우선순위가 있도록 설계하였다.

(4) Message Handler : 외부 메시지를 원래 메시지로 재구성하는 프로세스

Message Handler는 작은 단위(XBee Packet)로 전송된 외부 메시지들을 다시 원래의 메시지로 재구성하여 Message Returner에게 보내주는 프로세스다. 재구성이 필요한 이유는 크게 두가지다. 첫 번째, XBee Module간 전송에 쓰이는 XBee Packet 하나의 최대 전송용량은 256 byte이므로 이보다 큰 메시지는 여러 번 나뉘어 보내져야 한다. 두 번째, 네트워크 토폴로지의 변화 혹은 다른 제 3자의 메시지 전송에 의해 수신된 패킷 순서는 순차적이지 않으므로 다시 원래 순서에 맞추어 재구성되어야 한다.

관련 요구사항/설계변수 : 요구사항인 ‘온전한 송수신’을 위하여 설계변수인 ‘데이터베이스key갯수’는 필요충분하게 고유주소, 타임스템프 2개로 하였다. 첫 번째로, 오래된 message entry를 확인하는 주기는 너무 길지도 짧지도 않은 0.1초로 설정한다. 0.1초로 설정할 경우 cpu를 적당히 점유하면서 check 되는 횟수도 적당했다. 두 번째로, Message Handler에서 오래된 메시지 entry에 대한 flushout 한도는 3초로 정한다. Text 메시지의 경우 비교적 짧기 때문에 장문메시지를 감안해도 3초면 1KB는 충분히 전송된다. 추후 네트워크가 복잡해질 경우 수신세기를 설계변수로 하여 adaptive하게 flushout 시간을 바꿀 수도 있지만 현재는 3초로 했을 경우 CPU 점유율에 큰 영향을 주지 않으면서 장문메시지를 모두 처리할 수 있었다. Audio routing 될 수 있는 여지가 훨씬 크므로 flushout 시간을 text 메시지보다는 더 길게 설정한다.

(5) Message Returner : 재구성된 메시지를 사용자에게 돌려주는 프로세스

Message Returner은 hanlder가 재구성한 메시지를 받아서 사용자측으로 전송해주는 프로세스다.

관련 요구사항/설계변수 : Command Returner와 동일하며, 사용자의 명령어처리에 대한 ‘응답성’을 달성하기 위하여 ‘IPC스케쥴링방식’은 Command Returner가 외부 pipe를 사용하는데 우선순위를 두었다.

나. 세부 동작도

(1) 명령어 전송( 메시지 송신, 디바이스 탐색, 채널변경, 기타환경설정) Command Listener는 사용자측 외부 pipe로부터 56~1008 byte size 원본 메시지를 받아 Command Queue에 넣고 명령어 듣기를 반복한다. Command Queue에 새로운 명령어가 온 것을 확인한 Command Executor는 명령어를 해석하고 해당 명령어 함수를 실행한다. 실행 결과는 Command Returner에게 연결된 내부 IPC pipe를 통해 전송하고, Command Returner가 명령어처리결과를 사용자측에게 보내주기 전까지 ‘명령어 순차적 실행’을 위해서 대기하고 있다. Command Returner는 내부 IPC pipe로부터 CMD_Result 패킷을 받고 사용자측으로 이어진 외부 pipe로 전송해주는데, 이때 바깥으로 나가는 외부 pipe의 사용 우선순위는 Command Returner가 높으므로 message returner는 그동안 대기하고 있다. 이상 위와 같이 명령어를 하나씩 처리한다. 이때 오고 가는 모든 값은 byte 값으로 이루어져 있으며 메시지 송신 시 data영역은 utf-8로 인코딩된다.

(2) 메시지 수신 외부의 비동기적인 메시지는 Command Executor에 정의되어 있는 Message Callback 함수에 의해 수신되어 Message Queue에 메시지를 넣게 된다. 유의할 점은 XBee module 간에 송수신 될 때는 최대 256 byte를 넣을 수 있는 패킷이 사용되므로 블루투스용으로 사용되는 내부 패킷을 여러 개로 쪼개서 송수신하게 된다. 이를 원래의 메시지로 재구성하는 것이 Message Handler이다. 무선 통신의 특성 상 중간에 유실되는 패킷이 있을 수 있으므로 모든 형제 패킷이 다 도착하지 않았더라도 일정한 timeout_bound를 정하여 사용자에게 재구성하여 되돌려준다. Message Returner는 Handler로부터 받은 재구성 메시지를 외부 pipe(Command Returner가 사용하고 있지 않을 경우)로 사용자에게 다시 되돌려준다.

다. Reorganizer 세부구조 : 64Addr와 Timestamp를 entry 고유 key값으로 사용

(1) ‘XBee패킷’과 ‘RPi↔스마트폰 내부사용 패킷’ ‘XBee Pro 900HP’ 모듈이 한 번에 전송할 수 있는 최대 크기는 256 bytes다. 장문 메시지를 보내는 경우를 감안하여 스마트폰과 RF단말기 사이에 오고 가는 메시지 길이는 1008 byte로 설정한다. 블루투스 패킷의 하나의 크기가 1008 byte로 표준이 정해져 있기 때문이다.

(2) 패킷을 구분하는 고유 식별자 - 송신자/수신자는 하드웨어의 64bit 고유 주소로 구별 - 동일 발송자로부터 온 패킷들은 Time stamp로 구별. - list를 사용한 자료구조를 만들어 key값 중복이 없는 데이터베이스 제작.

(3) Pesudo Code

(4) Message Handler Transition Diagram

Message Handler는 위와 같이 상태전이를 한다. 평소에는 ‘old entry check 주기’마다 entyr가 너무 오래되었는지 체크를 한다. 현재 설정되어 있는 flushout entry 선은 3초이다. 이렇게 체크를 계속 하다가 Message Queue로 외부의 새로운 메시지가 도착하면, 새로운 메시지를 Queue에서 빼온다. 기존 entry를 확인하여 이미 있는 엔트리인지 확인하고, 기존 entry에 없던 새로운 메시지면 entry를 새로 만든다. 부가적으로 받은 메시지의 헤더에는 몇 개의 packet이 와야 원래 메시지가 조합되는지에 대한 메시지 메타정보가 있으므로 만약 원래 메시지를 재구성하기 위한 Xbee 패킷이 모두 도착하였으면 Flushout하여 사용자에게 최종적으로 전달한다.

Device Cover

→ 대부분 휴대용 전자제품이 폴리스타이렌이 아닌 ABS 수지를 쓰는 것처럼 충격 받을 일이 많은 Olora에게 내충격성과 내구성이 뛰어난 ABS 수지를 사용하여 케이스 제작.
→ 경제성을 고려하여 ABS 재질을 사용.
→ 각 부품들을 모두 보호하기 위한 최소한의 크기 도출. (144mm(세로)×76mm(가로)×42mm(높이))
  (보조배터리와 Raspberry PI, Xbee, microphone, speaker 모두 포함하는 최소의 크기)
→ 3D 프린터로 뽑기 때문에 충분한 내구성과 경제성을 고려하여 케이스 두께를 1~2mm가 아닌 3mm로 결정.

가. 설계안(조립도)

1) Top view

⇒ 아랫면(왼쪽) : Xbee와 Raspberry Pi를 고정시킬 수 있도록 원기둥 높이 15mm로 설계
⇒ 윗면(오른쪽) : 마이크와 스피커를 위한 음성 통로 설계

2) Right view

⇒ 아랫면 13mm : 보조 배터리를 위한 공간, 언제든지 스마트폰을 위한 보조 배터리로 사용 가능하도록 빠질 수 있게 설계하였다. 
⇒ 윗면 중 호 모양의 10mm 통로 : 배터리와 Raspberry Pi가 연결될 수 있는 통로 설계

3) Front view

⇒ 아랫면(왼쪽) : 보조 배터리를 위한 공간, 보조 배터리를 충전할 수 있는 공간, 배터리와 Raspberry Pi를 연결시킬 수 있는 공간 설계 (28mm×8mm)
⇒ 윗면(오른쪽) : Xbee의 안테나가 외부로 나올 수 있는 공간 설계 (15mm×15mm)
⇒ 원기둥 : Xbee, Raspberry Pi, 스피커를 고정하기 위한 15mm 높이의 원기둥 설계

4) Perspective view

A) 한 케이스 내부에 모든 부품 장착 
B) 마이크/스피커 기능 추가하여 워키토키 기능 구현
C) 마이크 : 라즈베리파이와 직접 연결
D) 스피커 : 라즈베리파이와 직접 연결
E) 마이크와 스피커로 인한 크기 조정 불필요
F) 마이크와 스피커 소리가 잘 통할 수 있도록 케이스에 음성 통로 설계
G) 윗면 아랫면 각각 만들어 접착시키는 구조
H) 3mm의 두께로 충분한 내구성

나. 부품도

1) Raspberry Pi (Raspberry Pi 3 Model B (SBC))

⇒ USB Ports를 통해 마이크와 Xbee 연결
⇒ GPIO Pins를 통해 스피커 연결
⇒ micro USB POWER를 통해 Raspberry Pi에 전원 공급
⇒ 스마트폰과 Bluetooth를 통한 연결

2) Xbee (Xbee Pro 900HP)

⇒ Xbee와 Xbee explorer dongle을 부착하여 Raspberry Pi의 USB Port와 연결
⇒ Xbee와 안테나 연결
⇒ Explorer Dongle : SparkFun XBee Explorer Dongle
⇒ 안테나 : Quad-band Cellular Duck Antenna SMA 
            Specifications : GSM/850E : 824 to 894MHz
            GSM : 880 to 960MHz
            DCS : 1710 to 1880MHz
            PCS : 1850 to 1990MHz

3) 마이크/스피커

⇒ Raspberry Pi와의 연결을 위한 USB dongle형 소형 마이크 
   Specification : Module size : 22mm x 19mm
                   Type : mini USB microphone

⇒ Raspberry Pi와의 연결을 위한 digital Speaker 
   Specification : Operating voltage: 2.0 - 5.5V
                   Interface Type: Digital
                   Module size : 40mm x 40mm
                   Support Gravity interface

평가

개발 사업비 내역서

제품평가(performance Test Result)

향후 개선점

- Android App
  1) 블루투스 연결성 안정화 
  2) 코드 최적화를 통해 응답성 증대

- Terminal Device System
  1) 패킷 송수신 성공률 정량지표 개선
  2) XBee 자체 스피커/마이크 시스템 추가 
  3) 암호화

- Hardware & Cover Case
  1) 스피커/마이크 추가
  2) 케이스 내구도 시뮬레이션

부록

참고문헌

1) [ICT시사용어]메시 네트워크(Mesh network), <전자신문>
2) 모두투어 사례로 본, 해외여행 안전고지 의무, <주간한국>
3) MANET 의 특징, https://www.sciencedirect.com/science/article/pii/S1570870503000131
4) SPANs 소개, https://en.wikipedia.org/wiki/Span
5) Wireless ad hoc network 소개, https://en.wikipedia.org/wiki/Wireless_ad_hoc_network
6) 5G 국제 표준의 이해, 삼성전자
7) 5G D2D Networks: Techniques, Challenges and Future Prospects, IEEE Papers  　　 
8) Walkie-Talkie 자료, Wikipedia
9) Beartooth 특허 자료, Coupling of radio hardware with a mobile device acting as a software defined radio ,미국/15436405
10) Gotenna 특허 자료, System and method for digital communication between computing devices, 미국/14659151
11) Coupling of radio hardware with a mobile device acting as a software defined radio – Beartooth Radio, Inc.
12) System and method for digital communication between computing devices – goTenna Inc.
13) KT 스마트무전기, http://www.okhana.co.kr/shop/shopbrand.html?xcode=001&type=X

외부 링크

- Python Digi XBee Library, https://github.com/digidotcom/python-xbee
- BlueZ, http://www.bluez.org/
- OpenSSL, https://www.openssl.org/
- libpam, https://www.linux-pam.org/
- Android Studio, https://developer.android.com/studio/