KR100975884B1

KR100975884B1 - Ｕｓｎ 프로토콜 분석 장치

Info

Publication number: KR100975884B1
Application number: KR1020070133741A
Authority: KR
Inventors: 김세한; 이계선; 김내수; 표철식
Original assignee: 한국전자통신연구원
Priority date: 2007-12-18
Filing date: 2007-12-18
Publication date: 2010-08-13
Also published as: US20090161553A1; KR20090066119A

Abstract

본 발명은 USN 프로토콜을 분석하는 장치에 관한 것으로, 적어도 하나 이상의 채널을 통해 USN의 센서 노드들간의 통신되는 패킷을 수집하는 패킷 분석부; 및 USN 프로토콜에 따라 정의된 XML 스키마를 이용하여 상기 수집된 패킷을 처리하여 표시하는 프로토콜 분석부를 포함함으로서, 여러 개의 채널을 통해 수집한 패킷을 디코딩 및 인코딩하여 출력할 수 있다.

Description

ＵＳＮ 프로토콜 분석 장치{The apparatus for analyze the Ubiquitous Sensor Network protocol}

본 발명은 USN 프로토콜 분석 장치에 관한 것이다. 보다 구체적으로, USN(Ubiquitous Sensor Network)/WSN(Wireless Sensor Network)에서 운용되는 다양한 프로토콜들을 분석하기 위한 장치에 관한 것이다.

본 발명은 정보통신부 및 정보통신연구진흥원의 IT 성장동력기술개발의 일환으로 수행한 연구로서 도출된 것이다[과제 관리번호:2005-S-106-03, 과제명: RFID/USN용 센서 태그 및 센서 노드 기술 개발].

일반적으로 유비쿼터스 센서 네트워크에서는 다양한 센서 노드들은 운영하고, 이러한 센서 노드들은 패킷을 송수신하여 정보를 전달한다. 이 때, 유비쿼터스 센서 네트워크를 사용하기 위해서는 센서 노드들간의 송수신되는 패킷의 내용을 파악하여 사용자에게 전달해줘야 하고, 그러기 위해서는 유비쿼터스 센서 네트워크의 프로토콜을 분석하여야 한다. 종래 기술에 따르면, 종래의 USN 프로토콜 분석 장치는 지그비(Zigbee) 프로토콜과 같은 특정한 프로토콜 및 하나의 채널밖에 분석할 수 없었다. 즉, 종래에는 사용자의 의도와 상관없이 미리 고정된 프로토콜만을 구 현할 수 없는 문제점이 있었다. 또한, 하나의 채널만을 분석할 수밖에 없었으므로, 프로토콜을 분석하는데 그 한계가 있었다.

본 발명이 이루고자 하는 기술적 과제는 다수의 트랜시버를 구비하고, 미리 정의된 USN 프로토콜을 사용하여 프로토콜을 분석함으로서, 다수의 채널을 동시에 분석하고, 사용자 정의(XML)에 따른 다양한 프로토콜을 분석할 수 있는 USN 프로토콜 분석 장치를 제공하는데 그 목적이 있다.

상기 기술적 과제를 해결하기 위하여, 본 발명에 따른 USN 프로토콜 분석 장치는 적어도 하나 이상의 채널을 통해 USN의 센서 노드들간의 통신되는 패킷을 수집하는 패킷 분석부; 및 USN 프로토콜에 따라 정의된 XML 스키마를 이용하여 상기 수집된 패킷을 처리하여 표시하는 프로토콜 분석부를 포함한다.

바람직하게, 상기 USN 프로토콜 분석 장치에서 상기 패킷 분석부는 적어도 하나 이상의 트랜시버를 포함하고, 상기 트랜시버를 이용하여 상기 적어도 하나 이상의 채널을 통해 USN의 센서 노드들간의 통신되는 패킷을 수집한다.

또한, 상기 USN 프로토콜 분석 장치에서 상기 패킷 분석부는

상기 프로토콜 분석부와 연결되며, 패킷을 송수신하는 통신 접속부; 상기 수집된 패킷을 저장하는 메모리; 및 상기 수집된 패킷을 상기 프로토콜 분석부에 송수신할 수 있도록 제어하는 송/수신 엔진을 더 포함하는 것이 바람직하다.

또한, 상기 USN 프로토콜 분석 장치에서 상기 프로토콜 분석부는 개인용 컴퓨터가 탑재된 사용자 프로그램으로 구성되며, 상기 사용자 프로그램은 USN 프로토콜을 정의하는 프로토콜 스키마; 상기 프로토콜 스키마에서 정의된 USN 프로토콜에 따라 XML 스키마를 정의하고, GUI를 생성하는 XML 엔진; 및 상기 XML 엔진에서 생성된 XML 스키마를 이용하여 상기 수집된 패킷들을 인코딩 또는 디코딩하는 트랜슬레이터를 포함하는 것이 바람직하다.

또한, 상기 USN 프로토콜 분석 장치는 상기 수집된 패킷을 송수신하는 소켓 매니저를 더 포함하고, 상기 트랜슬레이터는 상기 소켓 매니저를 통해 수신된 패킷을 상기 XML 스키마를 이용하여 디코딩하는 것을 특징으로 하는 것이 바람직하다.

또한, 상기 USN 프로토콜 분석 장치에서 상기 XML 엔진은 상기 프로토콜 스키마에서 정의된 USN 프로토콜을 XML 형태로 변형하여 XML 스키마를 생성하는 XML 생성부; 및 상기 XML 생성부를 통해 생성된 XML 스키마를 이용하여 GUI를 생성하는 GUI 생성부를 포함하는 것이 바람직하다.

또한, 상기 USN 프로토콜 분석 장치에서 상기 GUI 생성부는 상기 XML 생성부를 통해 생성된 XML 스키마를 이용하여 채널 검색, 패킷 수집, 패킷 생성 및 통계 수집을 포함하는 GUI를 생성하는 것을 특징으로 하는 것이 바람직하다.

본 발명에 따른 USN 프로토콜 분석 장치는 적어도 하나 이상의 채널을 통해 USN의 센서 노드들간의 통신되는 패킷을 수집하는 패킷 분석부; 및 미리 정의된 USN 프로토콜을 통해 생성된 XML을 이용하여 상기 수집된 패킷을 처리하여 표시하 는 프로토콜 분석부를 포함함으로서, 다수의 채널을 동시에 분석하고, 사용자 정의(XML)에 따른 다양한 프로토콜을 분석할 수 있는 효과가 있다.

이하에서는 도면을 참조하여 본 발명의 바람직한 실시예들을 상세히 설명한다.

도 1은 본 발명의 바람직한 일 실시예에 따라 USN 프로토콜 분석 장치의 구성을 나타낸 도면이다.

본 발명의 바람직한 일 실시예에 따른 USN 프로토콜 분석 장치는 패킷 분석부(100) 및 프로토콜 분석부(110)를 포함한다.

패킷 분석부(100)는 적어도 하나 이상의 채널을 통해 USN의 센서 노드들(120, 130, 140)간에 통신되는 패킷을 분석한다.

보다 구체적으로, 패킷 분석부(100)는 독립된 하드웨어로서, 안테나(101), 적어도 하나 이상의 트랜시버(102), 각 트랜시버에 대응하는 트랜시버 버퍼(103), 송수신 엔진(104), CPU(105), 메모리(106) 및 통신 접속부(107)을 포함한다.

도 1에 도시된 바와 같이, 패킷 분석부(100)는 적어도 하나 이상의 트랜시버(103)를 포함하며, 적어도 하나 이상으로 구성된 트랜시버(103)는 프로토콜 분석부(110)에서 전달되는 패킷 및 명령에 따라 안테나(101)를 통해 프레임을 전송 또는 수신한다. 이 때, 트랜시버(103)의 개수만큼 안테나(101)를 구비할 수도 있으나, 트랜시버(103)의 개수와는 상관없이 하나의 안테나(101)만을 구비할 수도 있다. 다만, 하나의 안테나(101)만을 구비하는 경우에는 간섭의 영향을 줄이기 위해 채널을 고정한다.

패킷 분석부(100)와 프로토콜 분석부(110)는 통신 접속부(107)를 통해 연결되며, 이러한 통신 접속부(107)로는 에더넷, 무선 랜, USB, GSM 및 CDMA 등이 사용된다. 따라서, 통신 접속부(107)을 통해 패킷 분석부(100)와 프로토콜 분석부(110)는 패킷을 송수신한다.

패킷 분석부(100)는 프로토콜 분석부(110)와 패킷을 송수신하는데, 패킷을 송신하는 경우에는 프로토콜 분석부(110)에서 생성된 패킷을 CPU(105), 메모리(106)를 거쳐, 송수신 엔진(104), 각 트랜시버에 대응하는 트랜시버 버퍼(103)를 통해 트랜시버(102)로 전달한다. 또한, 패킷을 수신하는 경우에는 안테나(101), 트랜시버(102)를 통해 수신한 패킷은 트랜시버 버퍼(103)를 전달되고, 송수신 엔진(104)의 제어를 통해 CPU(105) 및 메모리(106)를 거쳐 프로토콜 분석부(110)로 전달한다. 이 때, 메모리(106)는 수집된 패킷을 저장한다.

패킷 분석부(100)가 다수의 트랜시버(102)를 구비하여, 다수의 트랜시버(102)를 통해 패킷을 송신/수신하는 경우에는 각 채널을 통해 송수신되는 패킷들간을 비교 및 전송 제어하고, 각 트랜시버(102)와 송수신 엔진(104) 사이의 시간을 동기화시키기 위해 동기선(108)을 구비한다.

프로토콜 분석부(110)는 사용자 프로그램(110a)이 탑재된 개인용 컴퓨터 등을 의미한다.

프로토콜 분석부(110)는 사용자가 원하는 프로토콜 스펙을 정의한 문서인 XML 스키마와 이 스키마를 파싱하여 프로토콜을 분석하고, 사용자가 정의한 프로토 콜을 생성한다.

도 2는 본 발명의 바람직한 일 실시예에 따라 도 1에 도시된 패킷 분석부와 프로토콜 분석부 간의 통신에 필요한 프로토콜을 정의한 도면이다. 이 때, 패킷 분석부에 탑재된 소프트웨어는 서버가 되고, 사용자 프로그램은 클라이언트가 되어 동작하며, 도 2에 정의된 프로토콜에 따라, 패킷 분석부와 프로토콜 분석부는 통신을 수행한다.

도 2는 본 발명의 바람직한 일 실시예에 따라 서버와 클라이언트 간의 통신에 필요한 패킷 구조를 나타낸 도면이다.

도 2에 도시된 바와 같이, 패킷 구조(200)는 패킷 분석부(100)에 포함된 각 트랜시버(210), 서버와 클라이언트 간에 사용되는 패킷 타입(220), 공용으로 사용되는 리저브드(230), 패킷의 데이터 길이(240), 시작/정지 시간 스탬프(250, 260), 실제 송수신에 관계된 128 바이트의 데이터(270) 및 CRC 필더(280)로 구성된다. 이 때, 패킷 타입(220)에 따라 각 필드의 사용이 정의된다.

도 3은 본 발명의 바람직한 일 실시예에 따라 도 2의 각 패킷 타입을 정의한 도면이다.

도 3에 도시된 바와 같이, 패킷 타입은 0x50(301), 0x51(302), 0x60 내지 0x69(303 내지 312)로 구분할 수 있다.

패킷 타입 0x50(301) 및 0x51(302)는 실제 송수신 데이터를 정의하고, 패킷 타입 0x60 내지 0x69(303 내지 312)는 패킷 분석부(100)를 제어하거나, 패킷 분석부(100)로부터 정보를 수신을 위해 필요한 타입을 정의한다.

도 4a 내지 도 4p는 본 발명의 바람직한 일 실시예에 따라 도 3의 패킷 타입에 따라 정의된 실제 패킷의 패킷 구조를 나타낸 도면이다.

이하, 도 2 및 도 3을 참조하여, 도 4a 내지 도 4p에 기재된 패킷의 구조를 구체적으로 살펴본다.

도 4a는 본 발명의 바람직한 일 실시예에 따라 패킷 타입이 0x50인 경우 실제 패킷의 구조를 나타낸 도면이고, 도 4b는 본 발명의 바람직한 일 실시예에 따라 도 3의 패킷 타입이 0x51인 경우 실제 패킷의 구조를 나타낸 도면이다.

본 발명의 바람직한 일 실시예에 따라 패킷 타입 0x50 및 0x51은 실제 송수신할 때 필요한 패킷을 나타내는데, 패킷 타입 0x50과 0x51의 패킷 구조는 패딩(Padding) 정보 사용 여부에 따라 구분된다.

패딩 값(RSSI 값, CRC 결과, Correlation 값)을 사용하면, 도 4a에 도시된 구조를 사용하여 데이터를 전송하고, 패딩을 사용하지 않으면, 도 4b의 구조와 같이 실제 패킷만을 전송한다.

도 4c는 본 발명의 바람직한 일 실시예에 따라 패킷 타입이 0x60인 경우 실제 패킷의 구조를 나타낸 도면이다.

패킷 타입이 0x60이면, 하드웨어 시스템인 패킷 분석부를 리셋하기 위한 패킷(RESET REQUEST)으로, 도 4c에 도시된 바와 같이 정의된 하드웨어 채널 값(400)이 "FFFF"이면 패킷 분석부 전체 시스템을 리셋하고, 특정 트랜시버를 지정하면, 지정된 트랜시버만을 리셋한다.

도 4d는 본 발명의 바람직한 일 실시예에 따라 패킷 타입이 0x61인 경우 실 제 패킷의 구조를 나타낸 도면이다.

패킷 타입이 0x61이면, 패킷 타입이 0x60인 패킷에 대한 처리 결과를 전송하는 패킷으로, 정의된 하드웨어 채널 값에 따라서 시스템 전체 또는 일부의 리셋 성공 여부를 전달한다. 즉, 정의된 리저브드 값(401)이 "0x00"이면, 실패를 전달하고, "0x01"이면, 성공을 전달한다.

도 4e는 본 발명의 바람직한 일 실시예에 따라 패킷 타입이 0x62인 경우 실제 패킷의 구조를 나타낸 도면이다.

패킷 타입 0x62이면, 하드웨어가 IP 기반으로 운용되는 경우, 하드웨어의 IP를 설정하는 패킷으로, 데이터 필드(403)를 이용하여, IP, 서브넷 마스크(Subnet Mask), 디폴트(default) GW, DNS, TCP 포트 등을 변경할 수 있도록 한다.

도 4f는 본 발명의 바람직한 일 실시예에 따라 패킷 타입이 0x63인 경우 실제 패킷의 구조를 나타낸 도면이다.

패킷 타입 0x63이면, 패킷 타입 0x62인 패킷에 대한 처리 결과를 전송하는 패킷으로, IP 설정 변경 요청에 대한 성공 여부를 알려준다. 즉, 정의된 리저브드 값(404)이 "0x00"이면, 실패를 전달하고, "0x01"이면, 성공을 전달한다.

도 4g는 본 발명의 바람직한 일 실시예에 따라 패킷 타입이 0x64인 경우, 특정 채널에 대한 상태를 요청하는 실제 패킷의 구조를 나타낸 도면이다.

패킷 타입이 0x64인 경우, 특정 채널에 대한 상태를 요청할 수 있다. 이 경우, 도 4g에 도시된 바와 같이, 하드웨어의 특정 트랜시버에 대한 상태 정보를 요청한다. 정의된 하드웨어 채널 값(405)이 "0x01" ~ "0x08"이면, 지정된 트랜시버에 대한 상태 정보를 요청한다.

도 4h는 본 발명의 바람직한 일 실시예에 따라 패킷 타입이 0x65인 경우, 특정 채널에 대한 상태 요청의 응답할 때 실제 패킷의 구조를 나타낸 도면이다.

패킷 타입 0x65인 경우, 특정 채널 상태 요청에 대한 응답으로 TX 카운터, TX 에러 수, RX 카운터, Rx 에러수 등의 정보를 응답한다.

도 4i는 본 발명의 바람직한 일 실시예에 따라 패킷 타입이 0x64인 경우, 전체 채널에 대한 상태를 요청하는 실제 패킷의 구조를 나타낸 도면이다.

패킷 타입이 0x64인 경우, 전체 채널에 대한 상태를 요청할 수 있다. 이 경우, 도 4g에 도시된 바와 동일하나, 하드웨어 채널 값으로 "FFFF"를 설정한다. 그러면, 하드웨어 전체의 트랜시버에 대한 상태 정보의 요청할 수 있다.

도 4j는 본 발명의 바람직한 일 실시예에 따라 패킷 타입이 0x65인 경우, 전체 채널에 대한 상태 요청에 응답할 때 실제 패킷의 구조를 나타낸 도면이다.

패킷 타입이 0x65인 경우, 전체 채널에 대한 상태 요청에 응답할 수 있다. 이 경우, 도 4h에 도시된 바와 동일하나, 하드웨어 채널 값으로 "FFFF"를 설정한다. 그러면, 하드웨어 전체의 트랜시버에 대한 응답으로 TX 카운터, TX 에러 수, RX 카운터, Rx 에러수 등의 정보를 응답한다.

도 4k는 본 발명의 바람직한 일 실시예에 따라 패킷 타입이 0x66인 경우, 특정 채널에 대한 채널 변경을 요청하는 실제 패킷의 구조를 나타낸 도면이다.

도 4k와 같은 패킷을 통해, 특정 채널에 대한 채널 변경을 요청할 수 있다.

도 4l는 본 발명의 바람직한 일 실시예에 따라 패킷 타입이 0x67인 경우, 특 정 채널 변경 요청에 대한 응답을 나타내는 실제 패킷의 구조를 나타낸 도면이다.

도 4l과 같은 패킷을 통해, 특정 채널 변경 요청에 대한 성공 여부를 확인하는 응답을 할 수 있다.

도 4m는 본 발명의 바람직한 일 실시예에 따라 패킷 타입이 0x66인 경우, 전체 채널에 대한 변경을 요청하는 실제 패킷의 구조를 나타낸 도면이다.

도 4m과 같은 패킷을 통해, 전체 채널에 대한 채널 변경을 요청할 수 있다.

도 4n는 본 발명의 바람직한 일 실시예에 따라 패킷 타입이 0x67인 경우, 전체 채널 변경 요청에 대한 응답을 나타내는 실제 패킷의 구조를 나타낸 도면이다.

도 4n과 같은 패킷을 통해, 전체 채널 변경 요청에 대한 성공 여부를 확인하는 응답을 할 수 있다.

도 4o는 본 발명의 바람직한 일 실시예에 따라 패킷 타입이 0x68인 경우 실제 패킷의 구조를 나타낸 도면이다.

도 4o와 같은 구조의 패킷을 통해 트랜시버별 시간 동기화를 위한 회로를 리셋하는 요청할 수 있다.

도 4p는 본 발명의 바람직한 일 실시예에 따라 패킷 타입이 0x69인 경우 실제 패킷의 구조를 나타낸 도면이다.

도 4p와 같은 구조의 패킷을 통해 도 4o의 패킷에 대해 응답할 수 있다.

상기 도 2, 도 3 및 도 4a 내지 도 4p에서 살펴본 바와 같이, 도 1의 패킷 분석부(100)와 프로토콜 분석부(110)는 도 2에 따른 프로토콜을 정의하고, 도 3에 따라 정의한 패킷 타입에 따른 실제 패킷들(도 4a 내지 도 4p)을 이용하여 통신을 수행한다.

도 5는 본 발명의 바람직한 일 실시예에 따라 도 1의 프로토콜 분석부를 보다 상세히 나타낸 도면이다.

본 발명의 바람직한 일 실시예에 따른 프로토콜 분석부는 프로토콜 스키마(Protocol Schema, 500), XML 엔진(XML Engine, 510), 트랜슬레이터(Translator, 520), 소켓 매니저(Socket maneger, 530)를 포함한다.

프로토콜 스키마(500)는 본 발명의 바람직한 일 실시예에 따라 다양한 USN 프로토콜을 정의한다. 즉, 프로토콜 스키마(500)는 사용자가 정의하는 프로토콜을 XML 형태로 정의한다.

도 6 내지 도 13은 본 발명의 바람직한 일 실시예에 따라 프로토콜 스키마에서 정의하는 USN 프로토콜을 나타낸 도면이다. 이하, 도 6 내지 도 13을 참조하여, 본 발명의 바람직한 일 실시예에 따라 프로토콜 스키마에서 정의하는 USN 프로토콜을 구체적으로 살펴본다.

도 6은 본 발명의 바람직한 일 실시예에 따라 프로토콜을 정의하기 위한 XML의 전체 구성도이다. 프로토콜을 정의하기 위한 XML은 도 6에 도시된 바와 같이 파일의 정보를 포함하는 헤더 영역(600), 패킷 정의, 송수신 옵션, 통계 등을 정의하는 바디 영역(610), 각 부분을 정의하는 메인컨테이너 영역(620)으로 구성된다.

도 7a 및 도 7b는 도 6의 헤더 영역에 대한 정의를 보다 구체적으로 나타낸 도면이다.

도 7a는 도 6의 헤더 영역의 하위 태그에 대한 정의를 나타낸 도면으로서, 헤더 영역은 <HEADER>와 </HEADER> 태그 사이를 의미한다. 이 때, 헤더 영역은 사용자가 정의 하는 프로토콜명(700), 패킷의 최대 길이(710), 프로토콜 버전(720), XML 작성일(730), XML 파일에 대한 설명(740), 작성자(750), 및 회사명(760)으로 구성된다.

도 7b는 도 6의 헤더 영역을 실제로 작성하여 사용한 실시예를 나타낸 도면이다.

도 8a 및 도 8b는 도 6의 바디 영역에서 패킷에 대한 정의를 보다 구체적으로 나타낸 도면이다.

도 8a는 도 6의 바디 영역의 <BODY> ~ </BODY> 태그 영역에서 패킷을 정의한다. 도 8a에 도시된 바와 같이, 각 패킷은 <item container="name"/>의 "name" 부분에 HEADER, DATA, CHECKSUM 으로 세분화하여 각각 기술한다. 각 <item>의 "name" 부분에 기술된 내용은 <maincontainer> ~ </maincontaoner>에 정의된 <container> ~ </container>와 링크된다. 이 때, <item>의 container의 속성은 도 8b에 도시된 바와 같다.

도 9a 내지 도 9c는 도 6의 바디 영역에서 수신옵션설정에 대한 정의를 보다 구체적으로 나타낸 도면이다.

도 9a는 도 6의 바디 영역의 <COLLECTIONFILTER> ~ </COLLECTIONFILTER> 태그 영역에서 패킷 분석부의 수신옵션설정에 대해 정의한다. 도 9a에 도시된 바와 같이, <item> 태그에 수신 옵션 설정의 상세 설정 항목을 기술하며, "name" 부분에 기술된 내용은 <attribute>와 링크된다. 도 9b는 <item> 태그의 속성 및 사용의 일 실시예를 구체적으로 나타낸 도면이고, 도 9c는 <kind> 태그의 속성 및 사용의 일 실시예를 구체적으로 나타낸 도면이다.

도 10a 내지 도 10c는 도 6의 바디 영역에서 통계에 대한 정의를 보다 구체적으로 나타낸 도면이다.

도 10a는 도 6의 바디 영역의 <STATISTICS> ~ </STATISTICS> 태그 영역에서 패킷 분석부에서 정보를 수집하기 위한 통계 항목과 그 종류에 대해 정의한다. 도 10a에 도시된 바와 같이, <item> 태그는 통계 항목을 기술하며, "name" 부분에 기재된 내용은 <attribute>와 링크된다. 또한, 각 통계 항목별 종류는 <item>의 하위 태그인 <kind> 태그에 기술한다. <item>의 "name"에 기재된 부분이 <container> 태그의 "name"에 기재된 부분과 연결되는 경우에는 <kind> 태그의 value에 "EXIST"와 "NOEXIST"를 이용하여 해당 container가 있는지 없는지를 판단하여 통계를 수집한다. 도 10b는 <item> 태그의 속성 및 사용의 실시예를 구체적으로 나타낸 도면이고, 도 10c는 <kind> 태그의 속성 및 사용의 실시예를 구체적으로 나타낸 도면이다.

도 11a 및 도 11f는 패킷의 속성에 대한 정의를 보다 구체적으로 나타낸 도면이다.

도 11a는 <MAINCONTAINER>　~ </MAINCONTAINER> 태그 영역에서 패킷의 속성(Attribute)을 정의한다.

이 때, 도 11a 및 도 11b에 기재된 바와 같이, <container>와 <subcontainer>는 트리(tree) 구조로 하위의 <container>를 포함할 수 있다. <container> 속성에 display "name" 기술 여부에 따라 트리 노드(tree node)의 이름이 결정된다. <attribute>는 패킷의 필드 정보를 기술하며, "name"에 기재된 값으로 해당 <attribute>의 정보를 접근할 수 있다. 가변적 패킷의 길이를 갖는 필드를 표현하기 위해서는 <container>의 하위 태그인 <condition>을 이용하여 각 조건에 맞는 <subcontainer>로 분기한다. <condition>의 하위 태그인 <item>은 조건들을 기술하며, 해당 조건과 일치하면, <condition> 의 subcontainer 속성에 기술된 <subcontainer>로 분기한다. <condition>은 해당 container가 존재하는 조건만을 기술한다. 도 11c는 <container> 태그의 속성 및 사용예를 구체적으로 나타낸 도면이고, 도 11d는 <attribute> 태그의 속성 및 사용예를 구체적으로 나타낸 도면이고, 도 11e는 <condition> 태그의 속성 및 사용예를 구체적으로 나타낸 도면이며, 도 11f는 <item> 태그의 속성 및 사용예를 구체적으로 나타낸 도면이다.

도 12a 내지 12c는 <attribute>의 enum 리스트를 구체적으로 나타낸 도면이다.

도 12a에 도시된 바와 같이, <attribute>의 "unitype"에 기재된 값이 "enum"인 경우, <enumlist>의 해당 속성 이름을 가진 <enum> 태그를 이용하여 각 항목을 얻어온다. 도 12b의 <enum>의 "name" 속성 값에는 해당 <attribute>의 "name" 속성 값을 기재하며, 도 12c는 <enum>이 하위태그인 <item>의 각 속성의 항목의 이름과 값을 기술한다.

도 13은 본 발명의 바람직한 일 실시예에 따라 데이터를 그래픽 유저 인터페 이스로 표현하기 위한 유니타입을 나타낸 도면이다. 도 13에 도시된 바와 같이 <attribute>와 <collectionfilter>의 <item> 속성으로 사용한다.

다시 도 5를 참조하면, 프로토콜 스키마는 도 6 내지 12에 기재된 바와 같이 USN 프로토콜을 정의한다.

XML 엔진(510)은 프로토콜 스키마(500)에서 정의된 USN 프로토콜을 통해 XML 및 GUI를 생성한다. 보다 구체적으로 XML 엔진(510)은 프로토콜 매니저(511), GUI 생성부(512) 및 XML 생성부(513)를 포함한다.

프로토콜 매니저(511)는 프로토콜 스키마(500)에서 정의된 USN 프로토콜을 관리한다. 여기서, USN 프로토콜을 관리한다는 의미는 프로토콜 스키마가 프로토콜 규격에 따라 다수 존재하는 경우, 여러 개의 프로토콜 정의를 사용자 선택에 의해 어떤 규격에 따라 분석할지를 관리하는 것을 의미한다.

XML 생성부(513)는 프로토콜 스키마(500)에서 정의된 USN 프로토콜을 XML 형태로 변형한다. 이 때, XML 형태로 변형된 USN 프로토콜은 후술하는 트랜슬레이터(520)로 전달된다.

GUI 생성부(512)는 채널 검색부(Channel Searcher, 513), 패킷 수집부(Packet Collection, 514), 패킷 생성부(Packet Generator, 515) 및 통계 수집부(Statistics Collector, 516)를 포함하는 GUI를 생성한다. 즉, 생성된 GUI의 채널 검색부(513), 패킷 수집부(514), 패킷 생성부(515), 통계 수집부(516)를 통해 패킷을 송수신하고, 다양한 통계 데이터를 화면에 작성할 수 있다.

트랜슬레이터(520)는 XML 엔진(510)을 통해 생성된 XML 스키마를 이용하여 송수신되는 패킷을 처리한다. 보다 구체적으로, 트랜슬레이터(520)는 트랜슬레이터(520)를 구성하는 디코더(521) 및 인코더(522)를 통해 송수신되는 패킷을 인코딩 및 디코딩한다.

제 1 소켓(531) 및 제 2 소켓(532)으로 구성된 소켓 매니저(530)는 통신을 제어하며, 트랜슬레이터(520)를 통해 인코딩 및 디코딩된 패킷을 송수신한

한편, 상술한 본 발명의 실시예들은 컴퓨터에서 실행될 수 있는 프로그램으로 작성가능하고, 컴퓨터로 읽을 수 있는 기록매체를 이용하여 상기 프로그램을 동작시키는 범용 디지털 컴퓨터에서 구현될 수 있다.

또한, 상술한 본 발명의 실시예에서 사용된 데이터의 구조는 컴퓨터로 읽을 수 있는 기록매체에 여러 수단을 통하여 기록될 수 있다.

상기 컴퓨터로 읽을 수 있는 기록매체는 마그네틱 저장매체(예를 들면, 롬, 플로피 디스크, 하드디스크 등), 광학적 판독 매체(예를 들면, 씨디롬, 디브이디 등) 및 캐리어 웨이브(예를 들면, 인터넷을 통한 전송)와 같은 저장매체를 포함한다.

이제까지 본 발명에 대하여 그 바람직한 실시예들을 중심으로 살펴보았다. 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자는 본 발명이 본 발명의 본질적인 특성에서 벗어나지 않는 범위에서 변형된 형태로 구현될 수 있음을 이해할 수 있을 것이다.그러므로 개시된 실시예들은 한정적인 관점이 아니라 설명적인 관점에서 고려되어야 한다. 본 발명의 범위는 전술한 설명이 아니라 특허청구범위에 나타나 있으며, 그와 동등한 범위 내에 있는 모든 차이점은 본 발명에 포함된 것으 로 해석되어야 할 것이다.

도 2는 본 발명의 바람직한 일 실시예에 따라 도 1에 도시된 패킷 분석부와 프로토콜 분석부 간의 통신에 필요한 프로토콜을 정의한 도면이다.

도 6 내지 13은 본 발명의 바람직한 일 실시예에 따라 프로토콜 스키마에서 정의하는 USN 프로토콜을 나타낸 도면이다.

Claims

적어도 하나 이상의 채널을 통해 USN의 센서 노드들간의 통신되는 패킷을 수집하는 패킷 분석부; 및

USN 프로토콜에 따라 정의된 XML 스키마를 이용하여, 상기 수집된 패킷을 처리하여 표시하는 프로토콜 분석부를 포함하고,

상기 프로토콜 분석부는 개인용 컴퓨터와 개인용 컴퓨터가 탑재된 사용자 프로그램으로 구성되며, 상기 사용자 프로그램은

USN 프로토콜을 정의하는 프로토콜 스키마;

상기 프로토콜 스키마에서 정의된 USN 프로토콜에 따라 XML 스키마를 정의하고, GUI를 생성하는 XML 엔진; 및

상기 XML 엔진을 통해 정의된 XML 스키마를 이용하여 상기 수집된 패킷들을 인코딩 또는 디코딩하는 트랜슬레이터를 포함하는 것을 특징으로 하는 USN 프로토콜 분석 장치.
제 1 항에 있어서, 상기 패킷 분석부는

적어도 하나 이상의 트랜시버를 포함하고, 상기 트랜시버를 이용하여상기 적어도 하나 이상의 채널을 통해 USN의 센서 노드들간의 통신되는 패킷을 수집하는 것을 특징으로 하는 USN 프로토콜 분석 장치.
제 2 항에 있어서, 상기 패킷 분석부는

상기 프로토콜 분석부와 연결되며, 패킷을 송수신하는 통신 접속부;

상기 수집된 패킷을 저장하는 메모리; 및

상기 수집된 패킷을 상기 프로토콜 분석부에 송수신할 수 있도록 제어하는 송/수신 엔진을 더 포함하는 것을 특징으로 하는 USN 프로토콜 분석 장치.
삭제
제 1 항에 있어서,

상기 수집된 패킷을 송수신하는 소켓 매니저를 더 포함하고,

상기 트랜슬레이터는 상기 소켓 매니저를 통해 수신된 패킷을 상기 XML 스키마를 이용하여 디코딩하는 것을 특징으로 하는 USN 프로토콜 분석 장치.
제 1 항에 있어서, 상기 트랜슬레이터는

상기 XML 스키마를 이용하여 상기 수집된 패킷들을 분석하는 인코더; 및

상기 소켓 매니저를 통해 수신된 패킷을 상기 XML 스키마를 이용하여 상기 XML 엔진에서 GUI를 생성할 수 있도록 디코딩하는 디코더를 포함하는 것을 특징으로 하는 USN 프로토콜 분석 장치.
제 1 항에 있어서, 상기 XML 엔진은

상기 프로토콜 스키마에서 정의된 USN 프로토콜을 XML를 이용하여 XML 스키마를 정의하는 XML 생성부; 및

상기 XML 생성부를 통해 정의된 XML 스키마를 이용하여 GUI를 생성하는 GUI 생성부를 포함하는 것을 특징으로 하는 USN 프로토콜 분석 장치.
제 7 항에 있어서, 상기 GUI 생성부는

상기 XML 생성부를 통해 정의된 XML 스키마를 이용하여 채널 검색, 패킷 수집, 패킷 생성 및 통계 수집을 포함하는 GUI를 생성하는 것을 특징으로 하는 USN 프로토콜 분석 장치.
제 7 항에 있어서, 상기 XML 스키마는

헤더 영역, 바디 영역 및 메인컨테이너 영역을 포함하여 구성되는 것을 특징으로 하는 USN 프로토콜 분석 장치.
제 9 항에 있어서, 상기 헤더 영역은

파일의 정보를 포함하며, 사용자가 정의하는 프로토콜명, 패킷의 최대 길이, 프로토콜 버전, XML 작성일, XML 파일에 대한 설명, 작성자 및 회사명을 포함하여 구성되는 것을 특징으로 하는 USN 프로토콜 분석 장치.
제 9 항에 있어서, 상기 바디 영역은

패킷 정의, 수신옵션설정 및 통계를 정의하는 것을 특징으로 하는 USN 프로토콜 분석 장치.
제 9 항에 있어서, 상기 메인컨테이너 영역은

패킷의 속성을 정의하는 것을 특징으로 하는 USN 프로토콜 분석 장치.
제 3 항에 있어서, 상기 통신 접속부는

이더넷, 무선 랜, USB, GSM 및 CDMA 중 어느 하나인 것을 특징으로 하는 USN 프로토콜 분석 장치.
제 1 항에 있어서, 상기 USN 프로토콜은

상기 패킷 분석부에 포함된 트랜시버, 상기 패킷 분석부와 상기 프로토콜 분석부 간 사용되는 패킷 타입, 공용으로 사용되는 리저브드, 패킷의 데이터 길이, 시작/종료 시간 스탬프, 송수신되는 데이터 및 CRC로 구성된 패킷 구조인 것을 특징으로 하는 USN 프로토콜 분석 장치.
제 14 항에 있어서, 상기 패킷 타입은

실제 송수신되는 데이터를 정의하는 제 1 패킷 타입 및 상기 패킷 분석부를 제어하거나, 상기 패킷 분석부로부터 정보의 수신을 위해 필요한 타입을 정의하는 제 2 패킷 타입으로 구분하는 것을 특징으로 하는 USN 프로토콜 분석 장치.
제 15 항에 있어서, 상기 제 1 패킷 타입은

패딩 형식의 데이터 전송을 나타내는 패킷 타입인 "0x50" 및

패딩 형식이 아닌 데이터의 전송을 나타내는 패킷 타입인 "0x51"을 포함하는 것을 특징으로 하는 USN 프로토콜 분석 장치.
제 15 항에 있어서, 상기 제 2 패킷 타입은

상기 패킷 분석부 전체의 리셋을 요청을 나타내는 패킷 타입인 "0x60";

상기 패킷 분석부 전체의 리셋 요청에 대한 응답을 나타내는 패킷 타입인 "0x61";

상기 패킷 분석부 아이피 설정의 요청을 나타내는 패킷 타입인 "0x62";

상기 패킷 분석부 아이피 설정 요청에 대한 응답을 나타내는 패킷 타입인 "0x63";

채널별 상태 정보의 요청을 나타내는 패킷 타입인 "0x64";

채널별 상태 정보 요청에 대한 응답을 나타내는 패킷 타입인 "0x65";

상기 패킷 분석부의 채널에 대한 로지컬 채널 설정 요청을 나타내는 패킷 타입인 "0x66";

채널 설정 응답을 나타내는 패킷 타입인 "0x67";

타임 스탬프 리셋 요청을 나타내는 패킷 타입인 "0x68"; 및

타임 스탬프 리셋 요청에 대한 응답을 나타내는 패킷 타입인 "0x69"를 포함하는 것을 특징으로 하는 USN 프로토콜 분석 장치.