KR100760615B1 - 에프.엠 부가 방송 프로토콜을 이용한 에프.엠 부가 방송 전송 방법 및 장치 - Google Patents

Abstract

본 발명은 FM 부가 방송 전송 프로토콜을 이용한 FM 부가 방송 전송 방법이다.

본 발명에 따르면, FM 대역을 이용하여 데이터를 전송하는 FM 부가 방송 전송 프로토콜에 있어서, DARC의 변조 방식을 정의하는 물리 계층과, DARC의 프레임 구조를 정의하는 데이터 링크 계층과, 패킷의 동기화를 정의하며, 서비스 아이디를 정의하고, 데이터 패킷의 구조 및 상기 구조를 정의하는 네트워크 계층과, 서비스 아이디에 따른 정보의 분류를 나타내며, 서비스 아이디에 따라 데이터의 포맷과 정보의 종류를 달리하는 어플리케이션 계층 및 응용 서비스 구현을 위한 최상위 계층을 포함하여 이루어진다.

FM, 부가 방송, 라디오, 정보, DARC

Description

에프.엠 부가 방송 프로토콜을 이용한 에프.엠 부가 방송 전송 방법 및 장치{Apparatus and Method for transmitting a FM additional broadcasting using a protocol of FM additional broadcasting}

도 1은 FM 부가 방송 신호의 기저대역의 주파수 스펙트럼의 파형도이다.

도 2는 FM DARC 전송 모델을 설명하기 위한 도면이다.

도 3은 본 발명에 따른 DARC 프로토콜의 계층구조를 설명하기 위한 도면이다.

도 4는 다중 신호의 최대 주파수편차와 허용편차를 설명하기 위한 도면이다.

도 5는 송신 밴드 패스 필터의 허용 한계를 설명하기 위한 도면이다.

도 6은 송신 밴드 패스 필터의 허용 한계의 범위를 설명하기 위한 도면이다.

도 7은 프레임별 특징을 설명하기 위한 도면이다.

도 8은 A0 프레임 구조를 설명하기 위한 도면이다.

도 9는 A1 프레임 구조를 설명하기 위한 도면이다.

도 10은 B 프레임 구조를 설명하기 위한 도면이다.

도 11은 C 프레임 구조를 설명하기 위한 도면이다.

도 12는 블록 식별 코드의 비트 패턴을 설명하기 위한 도면이다.

도 13은 데이터 패킷의 구성을 을 설명하기 위한 도면이다.

도 14는 프리픽스(공통)를 설명하기 위한 도면이다.

도 15는 어플리케이션을 설명하기 위한 도면이다.

도 16은 구성 A를 설명하기 위한 도면이다.

도 17은 구성 B를 설명하기 위한 도면이다.

도 18은 마스터 데이터 종류와 내용을 설명하기 위한 도면이다.

도 19는 프레임 어플리케이션의 구별을 설명하기 위한 도면이다.

도 20은 텍마스터 종류를 설명하기 위한 도면이다.

도 21은 태그를 위한 기호 및 코드를 설명하기 위한 도면이다.

도 22는 한국 첨단 부가 방송 협의회(KARD)에서 정의하는 요소와 그 내용을 설명하기 위한 도면이다.

도 23a 내지 도 23c는 한국 첨단 부가 방송 협의회(KARD)에서 사용하는 요소와 속성의 코드값을 설명하기 위한 도면이다.

도 24a는 card 속성과 부호화를 설명하기 위한 도면이다.

도 24b는 template 속성과 부호화를 설명하기 위한 도면이다.

도 24c는 do 속성과 부호화를 설명하기 위한 도면이다.

도 24d는 timer 속성과 부호화를 설명하기 위한 도면이다.

도 24e는 go 속성과 부호화를 설명하기 위한 도면이다.

도 24f는 setvar 속성과 부호화를 설명하기 위한 도면이다.

도 24g는 input 속성과 부호화를 설명하기 위한 도면이다.

도 24h는 select 속성과 부호화를 설명하기 위한 도면이다.

도 24i는 option 속성과 부호화를 설명하기 위한 도면이다.

도 24j는 a 속성과 부호화를 설명하기 위한 도면이다.

도 24k는 img 속성과 부호화를 설명하기 위한 도면이다.

도 24l은 p 속성과 부호화를 설명하기 위한 도면이다.

도 24m은 table 속성과 부호화를 설명하기 위한 도면이다.

도 25는 PID에 따른 위치정보 종류를 설명하기 위한 도면이다.

도 26은 텍스트의 제어 코드를 설명하기 위한 도면이다.

도 27은 단순 문자 서비스 테이블을 설명하기 위한 도면이다.

도 28a는 패킷 어플리케이션에 따른 패킷 구조를 설명하기 위한 도면이다.

도 28b는 데이터 헤더 구조를 설명하기 위한 도면이다.

도 28c는 마스터 패킷 구조를 설명하기 위한 도면이다.

도 28d는 서비스 마스터 패킷 구조를 설명하기 위한 도면이다.

도 28e는 네트워크 마스터 패킷 구조를 설명하기 위한 도면이다.

도 28f는 스케줄 마스터 패킷 구조를 설명하기 위한 도면이다.

도 28g는 컨텐츠 마스터 패킷 구조를 설명하기 위한 도면이다.

도 28h는 업 데이트 마스터 패킷 구조를 설명하기 위한 도면이다.

도 29a는 교통 상황 정보에 따른 패킷 구조를 설명하기 위한 도면이다.

도 29b는 데이터 헤더 구조를 설명하기 위한 도면이다.

도 29c는 마스터 패킷 구조를 설명하기 위한 도면이다.

도 29d는 링크 전송일 경우 서비스 마스터 패킷 구조를 설명하기 위한 도면 이다.

도 29e는 노드 전송일 경우 서비스 마스터 패킷 구조를 설명하기 위한 도면이다.

도 29f는 구간 정보를 설명하기 위한 도면이다.

도 30a는 교통 유고에 따른 패킷 구조를 설명하기 위한 도면이다.

도 30b는 데이터 헤더 구조를 설명하기 위한 도면이다.

도 30c는 마스터 패킷 구조를 설명하기 위한 도면이다.

도 30d는 팩 아이디와 구간 정보의 일례를 설명하기 위한 도면이다.

도 30e는 사고 정보에 따른 패킷 구조를 설명하기 위한 도면이다.

도 30f는 장애물 정보에 따른 패킷 구조를 설명하기 위한 도면이다.

도 30g는 행사 정보에 따른 패킷 구조를 설명하기 위한 도면이다.

도 30h는 도로 상태 정보에 따른 패킷 구조를 설명하기 위한 도면이다.

도 30i는 네트워크 성능에 따른 패킷 구조를 설명하기 위한 도면이다.

도 30j는 네트워크 상태에 따른 패킷 구조를 설명하기 위한 도면이다.

도 30k는 시설물 정보에 따른 패킷 구조를 설명하기 위한 도면이다.

도 30l은 긴급 정보에 따른 패킷 구조를 설명하기 위한 도면이다.

도 31a는 기상 정보에 따른 패킷 구조를 설명하기 위한 도면이다.

도 31b는 데이터 헤더 구조를 설명하기 위한 도면이다.

도 31c는 데이터 헤더에 따른 WIM을 설명하기 위한 도면이다.

도 31d는 마스터 패킷 운용을 설명하기 위한 도면이다.

도 31e는 현재 기상 정보를 설명하기 위한 도면이다.

도 31f는 현재 정보의 발생 시간을 설명하기 위한 도면이다.

도 31g는 강수량을 설명하기 위한 도면이다.

도 31h는 육상 단기 예보를 설명하기 위한 도면이다.

도 31i는 육상 주간 예보를 설명하기 위한 도면이다.

도 31j는 강수 확률을 설명하기 위한 도면이다.

도 31k는 해당 단기 예보를 설명하기 위한 도면이다.

도 31l은 주간 해상 예보를 설명하기 위한 도면이다.

도 31m은 기상 특보를 설명하기 위한 도면이다.

도 31m은 생활 지수를 설명하기 위한 도면이다.

도 32a는 증권 정보에 따른 패킷 구조를 설명하기 위한 도면이다.

도 32b는 데이터 헤더를 설명하기 위한 도면이다.

도 32c는 정보의 그룹을 설명하기 위한 도면이다.

도 32d는 상기한 도 32c의 일례를 설명하기 위한 도면이다.

도 32e는 마스터 패킷 구조를 설명하기 위한 도면이다.

도 32f는 종목 데이터 패킷의 카테고리를 설명하기 위한 도면이다.

도 32g는 종목 데이터 패킷의 일 예를 설명하기 위한 도면이다.

도 32h는 전송 정보의 시각을 설명하기 위한 도면이다.

도 32i는 종목 데이터 패킷의 다른 예를 설명하기 위한 도면이다.

도 32j는 종목 데이터 패킷의 또 다른 예를 설명하기 위한 도면이다.

도 32k는 종목 데이터 패킷의 또 다른 예를 설명하기 위한 도면이다.

도 32l은 지수 데이터 패킷의 카테고리를 설명하기 위한 도면이다.

도 32m은 지수 데이터 패킷의 일 예를 설명하기 위한 도면이다.

도 32n은 지수 데이터 패킷의 다른 예를 설명하기 위한 도면이다.

도 32o는 지수 데이터 패킷의 또 다른 예를 설명하기 위한 도면이다.

도 33a는 부가 정보 전송 프레임을 설명하기 위한 도면이다.

도 33b는 세그먼트 멀레플렉스를 설명하기 위한 도면이다.

도 33c는 세그먼트 식별 내용을 설명하기 위한 도면이다.

도 33d는 암호화된 세그먼트 정보 내용을 설명하기 위한 도면이다.

도 33e는 방송국 식별 데이터 구성을 설명하기 위한 도면이다.

도 33f는 확정국 식별 코드를 설명하기 위한 도면이다.

도 33g는 국가 식별 코드를 설명하기 위한 도면이다.

도 33h는 가청 지역 코드를 설명하기 위한 도면이다.

도 33i는 시각 정보의 데이터 구성을 설명하기 위한 도면이다.

도 33j는 프로그램 개시 편성 시간 데이터 구성을 설명하기 위한 도면이다.

도 33k는 교통 긴급 정보 플래그의 데이터 구성을 설명하기 위한 도면이다.

도 33l은 교통 정보 플래그를 설명하기 위한 도면이다.

도 33m은 긴급 정보 플래그를 설명하기 위한 도면이다.

도 33n은 음악 정보의 데이터 구성을 설명하기 위한 도면이다.

도 33o는 음악/음성 플래그를 설명하기 위한 도면이다.

도 33p는 카테고리를 설명하기 위한 도면이다.

도 33q는 기간 방송국명의 데이터 구성을 설명하기 위한 도면이다.

도 33r은 FM 방송 주파수의 부호 할당을 설명하기 위한 도면이다.

도 33s는 중계방송국명의 데이터 구성을 설명하기 위한 도면이다.

도 33t는 대체 주파수의 데이터 구성을 설명하기 위한 도면이다.

도 33u는 카테고리명 재정의 데이터 구성을 설명하기 위한 도면이다.

도 33v는 기간 방송국명의 데이터 구성을 설명하기 위한 도면이다.

도 34a 내지 도 34b는 동일 서비스 연결 정보를 설명하기 위한 도면이다.

본 발명은 FM 부가 방송 송수신 시스템에 관한 것으로, 보다 상세하게는 FM DARC 방송을 이용해 각종 부가 정보를 삽입하기에 적합하고, 이를 송신 및 수신하기에 적합한 FM 부가 방송 전송 프로토콜과 이를 이용한 부가 방송 송수신 시스템에 관한 것이다.

일반적으로 FM 부가 방송 시스템을 이용하여 방송용 라디오 신호에 다양한 부가 정보를 다중화하여 송신하므로써 서비스 제공자인 방송사에서는 사용자 수에 따른 회선용량의 부담 없이 데이터 서비스를 제공할 수 있으며, 서비스 사용자측에서는 FM 라디오 튜너와 FM 부가 방송 수신모듈이 포함된 단말 장치를 통해 방송수신이 가능한 지역이면 정지 또는 이동과 상관없이 부가 정보를 제공받고 있다.

일반적으로 FM 부가 방송 시스템은 라디오 방송 신호에 라디오 디지털 시스템(Radio Digital System; 이하 RDS라 칭함.) 신호나 데이터 라디오 채널(DAta Radio Channel; 이하 DARC라 칭함.) 신호를 부가시켜 송출하므로써 청취자로 하여금 라디오 청취 외에 보다 다양한 정보를 제공하기 위한 방송 시스템이다.

이러한 FM 부가 방송용 신호의 파형도에 대해 간략히 설명하면 다음과 같다.

도 1은 FM 부가 방송 신호의 기저대역의 주파수 스펙트럼의 파형도이고, 도 2는 FM DARC 전송 모델을 설명하기 위한 도면이다.

도 1 내지 도 2를 참조하면, FM 기저대역의 파형으로 기존 방송을 위해 사용하던 오디오 신호(L+R, L-R)와 파일롯 신호(pilot) 외에 FM 부가 방송 시스템의 정보 전송에 적용하기 위해 RDS 신호와 DARC 신호가 실린 모양이다.

이때 RDS 신호는 1,187.5bps의 데이터 신호를 DBPSK 방식으로 변조한 신호로써 부반송파 주파수는 57㎑이고, 부반송파의 레벨은 1.3 내지 10%이며, 데이터 송신시 에러 정정을 위해 (26, 16) 단축 순환 부호를 사용한다.

또한 DARC 신호는 16Kbps의 디지털 신호를 L채널 오디오 신호와 R채널 오디오 신호의 차(L-R)신호의 레벨에 따라 크기를 제어하여 최소 쉬프트 키잉(MSK; Minimum Shift Keying) 변조하고 대역 통과 필터(BPF)를 거친 신호로 부반송파는 76㎑이고, 부반송파의 레벨은 L-R 신호 레벨에 따라 4 내지 10%이고, 데이터 송수신시 에러 정정을 위해 (272, 190) 단축 순환 부호를 사용한다.

이처럼 FM DARC는 FM 대역을 이용하여 데이터를 전송하는 부가방송 서비스로 기존의 방송품질에 영향을 주지 않고 국제적 표준으로 인정된 타 FM 부가방송 서비 스와 양립할 수 있다.

이에 본 발명의 기술과 과제는 이러한 점에 착안한 것으로 본 발명의 목적은 각종 부가 방송 서비스를 수행하기에 적합한 FM DARC 프로토콜을 이용하여 FM 부가 방송 신호 전송 방법을 제공하는 것이다.

상기한 본 발명의 목적을 실현하기 위한 하나의 특징에 따른 FM 부가 방송 전송 방법은, FM 대역을 이용하여 데이터를 전송하는 FM 부가 방송 전송 방법에 있어서,

DARC의 변조 방식을 정의하는 물리 계층;

DARC의 프레임 구조를 정의하는 데이터 링크 계층;

패킷의 동기화를 정의하며, 서비스 아이디를 정의하고, 데이터 패킷의 구조 및 상기 구조를 정의하는 네트워크 계층;

서비스 아이디에 따른 정보의 분류를 나타내며, 서비스 아이디에 따라 데이터의 포맷과 정보의 종류를 달리하는 어플리케이션 계층; 및

응용 서비스 구현을 위한 최상위 계층을 포함하는 FM 부가 방송 전송 프로토콜을 이용하여 FM 부가 방송 신호를 전송하는 것을 특징으로 한다.

여기서, 상기한 데이터 링크 계층은 실시간 전송에 유리한 C 프레임을 이용하는 것이 바람직하고, 상기한 어플리케이션 계층은 패킷의 최선두인 프리픽스를 활용하여 어플리케이션을 구별하고, 데이터 그룹핑을 수행하는 것이 바람직하다.

그러면, 통상의 지식을 지닌 자가 본 발명을 용이하게 실시할 수 있도록 실시예에 관해 설명하기로 한다.

도 3은 본 발명에 따른 DARC 프로토콜의 계층구조를 설명하기 위한 도면이다.

도 3을 참조하면, 본 발명에 따른 DARC 프로토콜의 계층구조가 ISO/OSI 모델을 따른다는 것을 확인할 수 있다. 여기서, 계층1은 Physical 계층으로서 DARC의 변조방식을 정의하며, 현행 DARC의 변조방식은 LMSK(Level-Controlled Minimum Shift Keying)방식이다.

계층2는 데이터 링크(Data link) 계층으로서 DARC 프레임 구조를 정의하며, 본 발명에 따른 한국 첨단 부가 방송 협의회(이하, KARD라 칭함.)에서의 프레임은 real-time에 적합한 구조인 C 프레임이다.

또한 계층3은 네트워크(Network) 계층으로서 패킷의 동기화를 정의하며, 서비스ID를 정의하고, 데이터 패킷의 구조 및 구성의 정의 등을 담당하며, 계층4는 서비스ID에 따른 정보의 분류를 나타내며, 서비스ID에 따라서 데이터의 포맷과 정보의 종류가 달라진다. 또한 계층5 내지 계층7은 DARC 계층구조의 최상위 계층으로서 응용계층을 나타낸다.

그러면, 본 발명에 따른 DARC의 변조 특성에 대해서 설명한다.

통상적으로 DARC를 위한 입력 데이터 신호는 16Kbits/s의 전송속도를 가지는 이진 디지털 신호이다. 상기한 신호는 파일롯 신호의 4 번째 고조파인 76Khz의 부반송파를 이용하여 기존의 음성신호와 함께 멀티플렉싱된다. 이때 스테레오 음성 신호 (L-R)에 의해 DARC 신호(부반송파의 레벨)의 진폭이 제어되는 LMSK(Level-controlled Minimum Shift Keying)방식의 변조방법을 사용한다. FM 스테레오포닉 신호에 DARC 신호가 추가된 경우, 기저 대역의 주파수 스펙트럼은 상기한 도 1과 같이 나타나게 된다.

이진 디지털 신호는 중심주파수가 76㎑인, 스테레오 방식의 경우 파일럿 톤의 네 번째 고조파를 이용하여 전송된다. 입력 데이터가 1일 때 76㎑+4㎑, 입력 데이터가 0일 때 76㎑-4㎑ 인 주파수가 사용된다. 주파수 허용치, 위상차 및 비트 레이트는 다음과 같다.

즉, 주파수 허용치는 76㎑ ±7.6㎑(0.01%)이고, 위상차는 ±5도이며, 비트레이트는 16KBit/s±1.6KBit/s 이다.

한편, 부반송파의 레벨은 스테레오 L-R 신호의 레벨에 따라 변한다.

도 4는 다중 신호의 최대 주파수편차와 허용편차를 설명하기 위한 도면이다.

도 4를 참조하면, 스테레오 L-R 신호에 의해 야기된 주 FM 반송파의 변이가 2.5% 이하이면, 부반송파는 주 FM 반송파에 4%(3Khz)의 변이를 일으킨다.

스테레오 L-R 신호에 의해 야기된 주 FM 반송파의 변이가 5%이상이면, 부반송파는 주 FM 반송파에 10% (7.5kHz) 의 변이를 일으킨다. 이 한계치 사이에서 변이는 선형관계를 갖는다. 상기한 도 4에서 세로축은 다중신호의 최대 주파수 편차(변조도)를 나타내고, 가로축은 stereo차 신호의 순시 주파수 편차(변조도)를 나타낸다.

한편, 다중신호는 LMSK 방식에 따라 변조되었기 때문에, 그 영역은 스테레오 음성 신호에 의존해서 변동된다. 그러므로, LMSK 변조 후에 삽입 완료된 최종 송신 밴드 패스 필터의 특성 및 허용 편차를 규정한다. 여기서, 밴드 패스 필터의 특성은 그 특성곡선의 진폭이 첨부하는 도 5에 표시된 허용한계의 범위 내에 있는 것으로 하고, 송신 밴드 패스 필터의 허용 한계의 범위는 도 6에 도시한다.

이상에서는 한국 첨단 부가 방송 협의회 계층 모형 및 DARC의 변조 특성에 대해서 설명하였다. 그러면, 본 발명에 따른 FM DARC에서 이용하는 계층2의 프레임에 대해서 보다 상세히 설명한다.

일반적인 데이터 구조에서 가장 큰 요소를 프레임이라 하며, 하나의 프레임은 78,336 비트로 이루어지고, 하나의 프레임은 정보 블록들과 패리티 블록들로 이루어진다. 여기서, 정보 블록은 16 비트 길이의 블록식별코드와 176 비트 길이의 데이터패킷, 14 비트 길이의 CRC, 그리고 82 비트 길이의 패리티로 이루어진다. 또한 패리티블록은 16 비트 길이의 블록식별코드와 272비트 길이의 패리티로 이루어진다.

이처럼 프레임은 정보블록과 패리티블록의 구성방법에 따라 A0, A1, B, C 프레임으로 구별되며, 이에 대해서 상세히 설명한다.

먼저, A0 프레임은 한 프레임의 구성이 190개의 정보블록이 상단에 위치하며 82개의 패리티블록이 하단에 위치하여 이루어지며, 구체적인 구조는 첨부하는 도 8과 같다.

한편, A1프레임은 실시간 전송의 강력하게 요구되는 서비스에 대해 Product Code화된 프레임내의 패리티 블록들 사이에 12개의 실시간 정보블록을 삽입할 수 있는 구조이다.

도 9에 도시한 바와 같이, 12개의 삽입된 블록들은 Product Code화 된 프레임의 일부가 아니며, 이들은 3군데의 위치에 4블록크기로써 위치가 고정되어 있다.

첫 번째 4개의 블록들은 20개의 패리티 블록들 뒤에, 그 다음 4개의 블록들은 다른 21개의 패리티블록들 뒤에 그리고 마지막 4개의 블록들은 또 다른 21개의 패리티 블록들 뒤에 위치한다. 삽입된 블록들에 대한 블록식별 코드(BIC)는 BIC2이다.

한편, B프레임은 한 패리티블록과 정보블록들이 인터리브 되어 블록들의 균일한 전송을 가능하게 해준다. 자세한 구조는 첨부하는 도 10과 같다.

한편, C 프레임은 288비트 길이의 정보블록 단독으로 프레임의 역할을 수행한다. BIC3이 블록식별코드로 사용되며, 실시간 전송과 반복되는 정보의 전송 등에 적합한 구조이다.

KARD에서는 전송되는 프레임을 C 프레임으로 채택하였다.

FM DARC의 에러정정코드를 디코드하기 위해서는 동기신호가 필요하다. 이 신호는 가로방향 코드들과 Product 코드들과의 동기를 요한다. 그래서 도 12의 4종류의 블록 식별 코드(BIC ; Block Identification Code)가 동기신호로서 채택이 되었다.

그러면. FM DARC에서 이용하는 에러 정정과 에러 검출에 대해서 설명한다. 먼저 에러 정정에서는 Product 코드인 (272, 190)×(272,190)이 수신시 발생하는 에러를 검출하고 정정하기 위해 수신기/디코더에 사용된다. (272, 190)코드는 Shortened Majority logic decodable difference set cyclic code이다. (272, 190) 코드에 대한 Generator Polynomial 은 하기하는 수학식 1과 같다.

한편, 에러 검출에서는 에러 정정과는 별도로 수신기/디코더가 에러를 검출할 수 있게 14 비트의 CRC 코드를 사용한다. 176개의 정보비트에 대해 하나의 CRC가 계산되며 CRC Generator polynomial은 하기하는 수학식 2와 같다.

데이터패킷(계층3)

KARD의 계층 3은 데이터패킷의 구조와 데이터패킷의 프리픽스를 정의한다. 데이터패킷의 크기는 176비트(22바이트)이며, 프리픽스와 데이터로 이루어져 있다. 프리픽스를 이용하여 전송되는 패킷의 동기화를 구현하며, 계층4에서 특정 어플리케이션의 프로토콜이 적용될 지 등을 지정한다. 이들은 프레임 어플리케이션과 패킷 어플리케이션으로 구분할 수 있다.

데이터패킷은 도 13과 같이 176비트 크기의 프리픽스와 데이터로 구성되어 있다. 프리픽스에 따라 계층 4의 어플리케이션과 패킷/프레임 구조도 결정된다. 어플리케이션은 크게 패킷 어플리케이션과 프레임 어플리케이션으로 나뉜다. 패킷 어플리케이션의 패킷 구성을 구성A라 하고, 1 바이트의 프리픽스를 갖는다. 프레밍 어플리케이션의 패킷 구성을 구성B라 하고 2 바이트의 프리픽스를 갖는다.

각 구성의 프리픽스 크기는 다를 수 있지만 각 프리픽스의 첫 번째 바이트는 동일하며, 그 자세한 구조는 첨부하는 도 14에 있다.

도 14는 본 발명에 따른 프리픽스(공통)를 설명하기 위한 도면이다.

도 14를 참조하면, 본 발명에 따른 프리픽스는 데이터 그룹 번호. 정보 종료, 복호 식별, 서비스 아이디 및 어플리케이션 아이디로 이루어진다.

먼저, 데이터그룹번호는 Byte 1의 b7, b6, 2비트로 전송되는 패킷의 데이터그룹별로 번호를 붙인 구별자이다. 데이터그룹 단위는 패킷 어플리케이션은 매 패킷마다, 프레임 어플리케이션의 경우에는 프레임 단위로 각 데이터그룹별로 같은 번호를 할당하고 데이터 그룹이 바뀔 때마다 00→01→10→11→00… 와 같이 오름차순으로 번호를 붙인다.

또한 정보종료는 Byte 1의 b5의 1비트이고 어느 데이터그룹 번호에서 전송하는 데이터그룹이 종료하는 경우는 "1", 그 외의 경우는 "0"으로 한다.

또한 복호식별은 계층4에서의 어플리케이션이 패킷/프레임 어플리케이션 여부를 결정한다. 복호식별이 '0'이면 프레임, '1'이면 패킷 어플리케이션을 의미한다.

또한 서비스ID는 서비스데이터에 적용될 프로토콜의 종류를 지정한다. 즉 KARD 계층4에서 사용되어지는 프로토콜의 종류를 결정한다. 4비트의 크기로 적용되는 어플리케이션 프로토콜을 결정한다.

또한 어플리케이션ID는 복호 식별과 서비스 ID로 하나의 어플리케이션 ID를 이룬다. 어플리케이션에 따른 복호 식별과 서비스 ID는 첨부하는 도 15와 같다.

도 16은 구성 A(패킷 어플리케이션)를 설명하기 위한 도면이고, 도 17은 구성B(프레임 어플리케이션)를 설명하기 위한 도면이다.

도 16 내지 도 17을 참조하면, 구성A는 패킷단위의 전송에 사용된다. 22바이트 크기의 패킷은 1바이트의 프리픽스와 21바이트의 데이터로 이루어진다. 또한 구성 B는 프레임단위의 전송에 사용된다. 1개 이상의 패킷들로 이루어져 있고 각 패킷은 2바이트의 프리픽스가 있다.

프리픽스는 위에서 언급한 공통 프리픽스 1바이트와 1 바이트의 패킷카운트가 있다. 패킷카운트는 구성 B에만 있으며 각각의 데이터그룹번호에 대하여 데이터패킷 번호를 '0'부터 '255'까지 오름차순으로 증가시켜, 데이터를 그룹핑한다. 또한 프레임의 마지막 패킷은 길이 조정용 NULL이 포함되어 있다. 여기서, DARC정보 부호화 계층 3에서 사용되는 데이터 그룹의 CRC 계산은 아래와 같다.

즉, DARC에서는 데이터그룹의 오류검출을 위해 CRC-CCITT(committee consulatif international telegraphique ettelephonique, 국제전신전화자문위원회) 방식을 이용한다.

생성다항식은 G(x) = X¹⁶+X¹²+X⁵+1 이며, 상기 방식은 CCITT권고안이며, 계산 방식은 MSB부터 처리하는 XMODEM방식으로 초기값을 '0'으로 하고, CRC까지 통과시킨 결과가 '0'이면 정상적으로 수신한 프레임(Frame)이다.

----------------------------------------------------------------------

_{#define CRCPOLY 0x8408U // X^16 + X^12 + X^5 + 1}

_{typedef unsigned short WORD}

_{typedef unsigned char BYTE}

_;

_{WORD crc16(int n, BYTE data[])}

_{

_{WORD crc;}

_{int i, j;}

_{crc = 0;}

_{for( i = 0; i < n; i++)}

_{

_{crc ^= data[i];}

_{for( j = 0; j < 8; j++)}

_{

_{if( crc & 1)}

_{crc = (crc >> 1) ^ CRCPOLY;}

_else

_{crc >>= 1;}

_}

_}

_{return (~(crc ^ 0xFFFFU));}

_}

----------------------------------------------------------------------

그러면, KARD 어플리케이션 프로토콜에 대해서 설명한다.

본 발명에서 규정하는 내용은 계층4 이상의 KARD 어플리케이션 서비스 구현과 밀접하다. 즉, 본 발명에 따르면 여러 가지 서비스를 각기 다른 정보원에서 이용이 가능하도록 하며, 사용자가 원하는 서비스를 찾기 쉽도록 하게 하기 위해 서비스 관련 정보를 제공한다.

또한 본 발명에 따르면 사용자가 쉽고 빠르게 특정 서비스를 찾을 수 있도록 서비스 운용 시간, 컨텐츠 설명, 서비스 연결 정보, 업데이트 정보 등을 제공한다.

KARD 어플리케이션에서는 다음과 같은 요구조건을 따른다.

1.특정 서비스에 대한 정보제공자 정보 제공

2.서비스의 전송시간, 반복주기와 관련된 스케줄 정보의 제공

3.동일 또는 관련 정보제공원의 튜닝 파라미터 제공

4.특정 서비스 데이터에 대한 암호화 기능 제공

5.데이터 관리를 위한 서비스 관리번호(버전번호) 및 제어정보

6.수신기 데이터베이스 관리를 위한 업데이트 정보 제공

7.컨텐츠 설명의 제공

KARD의 응용 어플리케이션은 마스터데이터를 전송하여 상기한 정보들을 제공한다. 상기한 마스터데이터는 수신기가 데이터를 복호하는데 필수적인 데이터뿐만 아니라, 보조적인 정보들도 제공한다. 마스터데이터들은 수시로 전송하되 채널용량을 감안하여 조정한다.

도 18은 본 발명에 따른 마스터데이터 종류와 내용을 설명하기 위한 도면이다.

도 18을 참조하면, 본 발명에 따른 마스터데이터는 서비스 마스터, 네트워크 마스터, 스케줄 마스터, 컨텐츠 마스터 및 업 데이트 마스터를 포함하여 이루어진다.

보다 상세히는 서비스 마스터는 서비스 제공자 아이디, 암호화/압축 여부, 버전 번호 및 제어 정보를 포함하고, 네트워크 마스터는 동일 혹은 연관된 서비스 정보를 전송하는 매체의 연결 정보를 포함하며, 스케줄 마스터는 서비스 운영 시간, 서비스 영역을 포함한다.

또한 컨텐츠 마스터는 컨텐츠 설명을 포함하고, 업 데이트 마스터는 업데이터 정보를 포함한다.

상기한 어플리케이션 서비스의 마스터 데이터를 운용함에 있어서 다음과 같은 규칙을 정한다.

1. 마스터는 서비스 내에 반드시 한번 이상은 송출되어야 하며, 마스터데이터 구분자를 서비스내에 할당해 놓는다.

2. 모든 어플리케이션에 있어서 서비스마스터는 필수적이다.

3. 마스터는 수시로 전송하되, 전송채널용량을 고려하여 조정한다.

4. 네트웍마스터는 선택사항이며, 연결정보가 있을 때 수시로 전송하며, 전송되지 않을 경우, 연결정보 없음을 뜻한다.

5. 동일서비스의 제공원의 연결정보는 네트웍마스터로 전송한다. 연결주파수와 함께 서비스제공자ID를 전송하여, 동일서비스 탐색이 가능하도록 한다.

6. 서비스제공자ID는 KARD에서 정하되, 번호는 유일무이하다.

7. 스케줄마스터는 선택사항이며, 서비스의 제공날짜, 시간, 주기와 서비스지역을 전송한다. 전송되지 않을 경우 정해진 스케줄 없이 전송됨을 의미한다.

8. 컨텐츠 마스터는 선택사항이며, 컨텐츠를 묘사하는 적절한 문자열을 전송한다.

9. 업데이트마스터는 업데이트정보를 전송할 경우 필수적으로 전송한다. 수신기 업데이트 가능한 버전번호와, 업데이트정보 아이템 개수, 장기 업데이트 스케줄을 전송한다.

그러면, 본 발명에서 이용하는 표현문법(Representation of Syntax)과 용어에 대해서 설명한다.

먼저, 본 발명에 따른 표현문법에서는 KARD 규격 계층4 이상의 프로토콜에서의 데이터 요소와 구조를 정의하고, 용어 및 문법을 소개한다.

데이터 요소(Data Type)는 데이터 요소는 의미 있는 데이터형을 표현하는 하나의 구조이다. 데이터 요소는 구성요소로서 다른 데이터 요소들을 둘 수 있다

하나의 데이터 요소는 다음과 같은 방식으로 기술된다.

----------------------------------------------------------------------

_{<new_data_type>:= // data type의 설명}

_{<data_type_a>, // sub data type a}

_{<data_type_b>; // sub data type b}

----------------------------------------------------------------------

상기한 데이터 요소는 <data_type_a>와 <data_type_b>의 단지 2개의 요소를 가진 구조이다. 상기의 선언으로 인해 하나의 데이터 요소가 정의되어지고, 상기한 데이터 요소는 다른 데이터 요소가 될 수 있는 것이다. 데이터 구조에 대한 주석이 콜론( : ) 오른쪽에 있는 것을 볼 수 있다.

다음은 데이터 구성요소가 반복되는 형태일 때의 표현 방법이다.

----------------------------------------------------------------------

_{<new_data_type>:=}

_{<data_type_a>, // sub data type a}

_{m*<data_type_b>; // repeated sub data type b}

----------------------------------------------------------------------

어떤 경우는 몇 번 반복되는지 혹은 데이터의 길이를 디코더에게 전달할 필요가 있을 때도 있다. 반복번호를 추가하여 데이터 타입을 아래와 같이 만들 수도 있다.

----------------------------------------------------------------------

_{<new_data_type>:=}

_{<intunti>(n), // 반복횟수}

_{n*<data_type_a>, // sub data type a}

_{<data_type_b>; // repeated sub data type b}

----------------------------------------------------------------------

위의 예에서는 디코더가 <data_type_b>의 구성요소의 위치를 정확히 찾아내기 위해 반복회수 n이 있어야만 한다.

----------------------------------------------------------------------

_{<new_data_type>:=}

_{<intunti>(n), // 데이터의 길이}

_{m*<data_type_a>; // sub data type a}

----------------------------------------------------------------------

위의 예에서는 디코더가 n을 이용하여 component data의 길이를 결정할 수 있으며, m은 간접적으로 결정이 가능하다.

----------------------------------------------------------------------

_{<new_data_type>:=}

_{<intunti>(x), // Select parameter, x}

_{if (X=1) then <data_type_a>, // x=1일 때 포함}

_{if (X=2) then <data_type_b>; // x=2일 때 포함}

----------------------------------------------------------------------

위의 데이터 요소는 유동적인 데이터 구조에서 스위치 x를 사용하여 표현하였다.

다음의 예제들은 데이터 표기법에 대한 이해를 도울 수 있을 것이다.

----------------------------------------------------------------------

_{<school_data>:= // School data}

_{<intunti>(n), // child data의 수}

_{n * <child_data>; // children data}

----------------------------------------------------------------------

----------------------------------------------------------------------

_{<child_data>:= // child data}

_{<intunti>, // 키(cm)}

_{<intunti>, // 몸무게(kg)}

_{<intunti>; // 나이(살)}

----------------------------------------------------------------------

----------------------------------------------------------------------

_{<intunti>:= // 정수(범위: 0..255)}

_{<byte>; // 기본요소}

----------------------------------------------------------------------

그러면, 어플리케이션에 독립적인 데이터요소로서, 특히 사용되는 어플리케이션에 독립적인 요소들로서 기본요소와 복합요소를 설명한다

다음은 계층 4이상의 데이터 구조에서 사용될 기본요소(Primitive Elements)들이다.

먼저, 기본 숫자들의 예를 설명하면 아래와 같은 표현 문법을 통해 정의될 수 있다.

----------------------------------------------------------------------

_{<intunti>:= // Integer Unsigned Tiny(범위: 0~255)}

_{<byte>; // Primitive}

----------------------------------------------------------------------

----------------------------------------------------------------------

_{<intsiti>:= // Integer Signed Tiny(범위: 128~127)}

_{<byte>; // Two's complement}

----------------------------------------------------------------------

----------------------------------------------------------------------

_{<intunli>:= // Integer Unsigned Little(범위: 0~65 535)}

_{<byte>, // MSB, Most Significant Byte}

_{<byte>; // LSB, Least Significant Byte}

----------------------------------------------------------------------

----------------------------------------------------------------------

_{<intsili>:= // Integer Signed Little(범위: -32768~32767)}

_{<byte>, // MSB, two's complement}

_{<byte>; // LSB}

----------------------------------------------------------------------

----------------------------------------------------------------------

_{<intunlo>:= // Integer Unsigned Long(범위: -0~4294967295)}

_{<byte>, // MSB}

_{<byte>, // LSB}

_<byte>,

_<byte>,

_{<byte>; // LSB}

----------------------------------------------------------------------

----------------------------------------------------------------------

_{<intsilo>:= // Integer Signed Long(범위: 2147483648~}

_{// 2147483647)}

_{<byte>, // MSB, two's complement}

_<byte>,

_<byte>,

_{<byte>; // LSB}

----------------------------------------------------------------------

또한, 여러 어플리케이션에서 종종 사람, 물체, 동물 등의 양을 숫자로 표현할 필요가 있다. 이때 숫자의 크기가 적어도 '0'부터 수백만이 범위를 가질 수도 있으며, 아래와 같은 표현 문법을 통해 정의될 수 있다.

----------------------------------------------------------------------

_{<numag>:= // Counting numbers with magnitude, 0<=r<=3x10} ⁶

_{<intunti>(n); // r :=(5+sign(n-5) x (abs(n-5)mod 45))x10} ^{(n-5)div 45}

----------------------------------------------------------------------

또한, 캐릭터 테이블(Character Table) 식별자는 아래와 같은 표현 문법을 통해 정의될 수 있다.

----------------------------------------------------------------------

_{<chartab>:= // Character Table 식별자}

_{<intunti>(t); //}

----------------------------------------------------------------------

여기서, <chartab>은 Reference Character Table Index로부터, character table number를 지정한다. 그 table number는 character당 사용되어지는 바이트 수와 테이블 이름을 가리킨다.

또한, 비트스위치 Data Type은 아래와 같은 표현 문법을 통해 정의될 수 있다.

----------------------------------------------------------------------

_{<bit_switch>:= // 비트스위치}

_{<byte>; // Octet of flags}

----------------------------------------------------------------------

상기한 Data Type에서 각 비트는 플래그로 사용되어지고, 비트스위치는 어플리케이션 상에 특정 용도로 사용되어진다.

또한, CRC-Word Data Type은 아래와 같은 표현 문법을 통해 정의될 수 있다.

----------------------------------------------------------------------

_{<crc>:= // Cyclic Redundancy Check}

_<intunli>;

----------------------------------------------------------------------

복합요소(Compound Elements)는 다음과 같이, 1개 이상의 기본요소로 이루어진 데이터 구조이다.

----------------------------------------------------------------------

_{<short_string>:= // Short String}

_{<intunti>(n), // 바이트 수(n)}

_{n* <byte>; // string(n/k characters)}

----------------------------------------------------------------------

----------------------------------------------------------------------

_{<long_string>:= // Long String}

_{<intunli>(n), // 바이트 수(n)}

_{n* <byte>; // string (n/k characters)}

----------------------------------------------------------------------

상기한 바와 같이, 문자열은 이어진 n byte의 데이터라고 할 수 있다. 이 데이터들은 character table에 따라 해석되어진다. 상기한 k는 문자가 몇 바이트인가를 나타낸다. 각각의 어플리케이션은 문자열과 코드테이블을 이어주는 메커니즘을 가지고 있다.

분명히 표현되어지는 문자열의 길이는 바이트의 수(n)와 코드테이블에 따라 달라질 수 있다. 즉, Short string인 경우, Int(256/k)가, long string인 경우 Int(65535/k)가 최대 문자열 길이가 될 것이다(여기서, Int는 괄호 안의 정수 부분을 가르킨다.)

날짜와 시간 정보는 아래와 같은 표현 문법을 통해 정의될 수 있다.

----------------------------------------------------------------------

_{<time_t>:= // 날짜와 시간}

_{<intunlo>(n); // 초(1970-01-01T00:00:00 이후)}

_{// Universal Coordinated Time(UTC)}

----------------------------------------------------------------------

상기한 숫자는 1970-01-01 T00:00:00(Universal Coordinated Time)으로부터의 지나온 초를 의미한다. 이 값은 136년간 2106년까지 시간표시가 가능하다.

그러면, 반복 시간 표현의 기본형태에 대해서 설명한다.

먼저 Masked Time에서는 시간정보에 대한 규격을 정한다. 시간은 1바이트씩 연, 월, 일, 시, 분, 초로 나뉘어지며 각각의 바이트에서 0값은 해당 바이트의 범위에서 이벤트가 주기적으로 일어남을 의미한다.

"2001년 12월 중 매일 14시 30분 00초에 서비스 시작"이라는 의미를 Masked Time으로 표현하면, _{<masked_time> = 01 0C 00 0F 1F 01 hex}이다.

또한, "매년 매달 11일의 매시 45분 55초에 서비스 시작"이라는 의미를 Masked Time으로 표현하면, _{<masked_time> = 00 00 0B 00 2E 38 hex}이다.

----------------------------------------------------------------------

_{<masked_time>:= // Masked Time}

_{<intunti>, // Year, 0 : any; 1...255 : Year-2000}

_{<intunti>, // Month, 0 : any; 1...12 : Month}

_{<intunti>, // Day, 0 : any; 1...31 : Day}

_{<intunti>, // Hour, 0 : any; 1...24 : Hour+1}

_{<intunti>, // Min, 0 : any; 1...60 : Min+1}

_{<intunti>; // Sec, 0 : any; 1...60 : Sec+1}

----------------------------------------------------------------------

Day Mask는 주간 중 1일 이상의 반복주기를 표현하는 방법에 대해 정한다. <day_mask>가 0일 경우에는 어떤 날도 선택되지 않음을 나타내고, 이는 주중 특정한 반복주기가 없음을 의미한다. 비트 스위치에 의해 표현되는 <day_mask>는 128~255범위는 사용하지 않는다. 즉 MSB는 항상 0이다.

----------------------------------------------------------------------

_{<day_mask>:= // Day Mask}

_{<bit_switch>(selector);}

_{if (selector = 00000000) // no day selected}

_{if (selector = 0xxxxxx1) // every Sunday}

_{if (selector = 0xxxxx1x) // every Monday}

_{if (selector = 0xxxx1xx) // every Tuesday}

_{if (selector = 0xxx1xxx) // every Wednesday}

_{if (selector = 0xx1xxxx) // every Thursday}

_{if (selector = 0x1xxxxx) // every Friday}

_{if (selector = 01xxxxxx) // every Saturday}

----------------------------------------------------------------------

예를 들어, _{<day_mask> = 05 hex}의 의미는 매주 일요일과 수요일에 서비스 반복이 고, _{<day_mask> = 7E hex}의 의미는 일요일을 제외한 날에 서비스 반복이다.

Time duration은 <time_t>형태와 유사하게 표현되며, 표현을 위해 4바이트를 할당한다.

----------------------------------------------------------------------

_{<duration>:= // Time Duration}

_{<intunlo>; // Number of seconds}

----------------------------------------------------------------------

그러면, 반복되는 시간 표현의 복합형태에 대해서 설명한다.

먼저, 시작시간의 형태는 서비스의 시작시간과 반복주기를 표현하는데 유용하게 사용되어질 수 있다.

----------------------------------------------------------------------

_{<app_start_time>:= // Start time of an application}

_{<masked_time>, // at what time and date}

_{<day_mask>; // at which day of the week}

----------------------------------------------------------------------

또한, 타임 슬롯(Time Slot)의 형태는 특정 서비스의 시작 시간과 반복 주기 그리고 duration을 지정하는 데 이용한다.

----------------------------------------------------------------------

_{<time_slot>:= // Time, repetition, duration of an application}

_{<app_start_time>, // at what time and date}

_{<duration>; // how long it lasts}

----------------------------------------------------------------------

이상에서는 본 발명에서 이용하는 표현문법에 대해서 설명하였으며, 이하에서는 본 발명, 즉 KARD 어플리케이션에서 빈번하게 공통적으로 사용하는 용어(Terms)에 대해서 설명한다.

1. <SPID> (Service Provider ID)

: KARD에서 Service Provider(서비스 제공자)라 함은 전송망을 관리하며, 관련 서비스 데이터를 송출하는 특정 방송국 또는 서비스 콘텐트를 제공하는 IP 등을 의미한다. 각각의 서비스 주체에게 SPID를 할당하여, 구분할 수 있도록 한다.

SPID는 3바이트 크기로서 인터넷 IP어드레스와 유사한 방법으로 할당이 된다.

SPID-A. SPID-B. SPID-C.

서비스제공자 ID 지정은 다음과 같은 방식을 따른다.

_{Class-A = 1.0.x - 127.255.x}

_{Class-B = 128.0.0 - 255.255.255}

즉, Class A는 다수개의 서비스를 제공하는 서비스 제공자에게 부여되며, x 는 서비스 제공자가 서비스의 종류에 따라 임의로 할당한다. 또한 Class B는 하나의 서비스를 제공하고자 하는 곳에 부여하는 ID이고, 0.x.x는 예약영역으로 할당된다.

2. <En> (Encryption Indicator)

: 1바이트 크기의 암호/압축 지정자이다. 데이터들의 암호/압축 여부를 지정하는 데이터이며, 이 값이 00hex일 경우에는 컴포넌트들이 암호/압축되어 있지 않음을 의미한다. 암호/압축화에 따른 지시자의 할당된 값은 다음과 같으며, 암호/압축 알고리즘은 서비스 운영자가 자유롭게 선택할 수 있다.

_{0 = 암호/압축하지 않음}

_{1 - 127 = 표준 암호/압축 방법을 사용하기 위해 예약}

_{127 - 255 = 서비스 제공자가 임의로 지정}

3. <Ctg> (Category)

: 1바이트 크기이다. 통상적으로 정보 카테고리를 전송할 필요가 있을 때 사용한다.

4. <Ver> (Version Number)

: 2바이트 크기의 버전번호이다. <Ver>는 1부터 시작하여, 정보의 업데이트가 있을 때마다 1씩 증가시켜서 전송한다. 통상적으로 전송하는 서비스정보 중 코드체계가 있는 경우, 코드체계의 버전번호를 의미한다.

5. <Ctrl>

: <Ctrl>를 이용하여, 현재 전송되는 데이터들의 처리여부를 결정할 수 있다. <Ctrl>은 다음과 같이 할당을 한다.

_{0 = Reserved}

_{1 127 = 모든 어플리케이션에 공통적인 사항 지정}

_{127 255 = 각각의 어플리케이션마다 추가적으로 지정}

_{공통적인 제어코드는 부록 4 Ctrl table에서 제공한다.}

6. <AFrq> (Associative Frequency)

: 1바이트 크기의 주파수 테이블 코드이다. 예를 들어, 00hex는 주파수 정보 없음을 의미한다.

7. <정보시각>

: <정보시각>은 4 바이트 크기의 UTC time을 사용하며, <time_t>의 Data Type을 따른다. 의미하는 숫자는 1970-01-01 T00:00:00(Universal Coordinated Time)으로부터의 지나온 초를 의미한다. 통상적으로 DARC서버의 데이터 전송 시각을 의미하나, 각 어플리케이션마다 <정보시각>의 의미를 재정의할 수 있다.

8. <SAC> (Service Area Code)

: 서비스가 제공되는 정보의 커버리지를 의미한다.

그러면, 본 발명에 따른 프레임 어플리케이션에 대해서 보다 상세히 설명한다.

본 발명에서는 프레임 전송 기반의 모든 응용 서비스에 적용되는 프로토콜을 규정하는데, 주로 어플리케이션 프레임의 구조와 마스터 프레임의 규격 및 전송을 다룬다. 마스터 프레임에서 규정하는 내용은 서비스의 운영 정보, 연결 정보 등이다. 어플리케이션 프레임을 수신하기 이전에 데이터 수신 및 복호에 필요한 마스터 프레임 정보를 수신한다. 마스터 프레임은 응용서비스 데이터 수신에 반드시 필요할 뿐만 아니라, 유용한 정보들도 함께 전송한다.

각각의 응용서비스 마다, 프리픽스의 어플리케이션ID가 할당되어 있다. 프레임 어플리케이션은 프리픽스의 복호식별=0을 사용한다. 따라서, 어플리케이션ID는 0 내지 15를 사용한다.

각각의 응용 서비스마다 마스터 정보들이 존재하며, 마스터 정보는 응용서비스의 일부로서 해석되어지는데, 그 프레임 구조는 아래와 같다.

----------------------------------------------------------------------

_{<프레임> :=}

_{<M/D SelF>, // 마스터/데이터 식별자(프레임)}

_{<Msg IDF>, // Message ID}

_{<Size>(n), // 데이터 또는 마스터 크기(Byte)}

_{if (<M/D SelF> = 01h) then <마스터>}

_{if (<M/D SelF> = 81h) then <데이터>;}

----------------------------------------------------------------------

여기서, <M/D SelF > (Master/Data Selector of Frame)의 Data Type은 <intunti>이다. 전송되는 프레임이 마스터인지 데이터인지를 구분하는 구분자이다. 도 19에 도시한 바와 같이, <M/D SelF>=01h 일 때 마스터, <M/D SelF>=81h일 때 데이터임을 의미한다. 본 발명에서는 <M/D SelF>=01h일 때, 즉 마스터의 부호화를 담당한다.

또한, <Msg IDF> (Message ID of Frame)의 Data Type은 <intunti>이며, <Msg IDF>는 전송되고 있는 데이터를 그룹화한다. 운용상 구분할 필요가 있는 정보들을 <Msg ID>별로 그룹화하고 관리되어진다. Msg ID로 그룹 되어진 정보들을 메시지라 한다. <Msg ID>=00h는 예약이 되어 있으며, 어플리케이션 내의 모든 메시지를 의미한다.

또한, <Size>의 Data Type은 <intunli>이다. 뒤이어 전송되는 <마스터> 혹은 <데이터>의 크기를 바이트 수로 표시한다.

한편, 마스터 (<M/D SelF >=01h)는 <M/D SelF>=01h일 때 전송되는 프레임이다. 마스터는 Msg ID로 그룹핑된 메시지에 관련된 정보를 전송한다. 관련된 정보는 아래에 나타낸 바와 같이, 서비스 정보, 네트워크 정보, 스케줄 정보, 컨텐츠 설명이 있다.

마스터는 메시지마다 각각 전송된다. 하나의 어플리케이션에서 메시지를 구분할 필요없이 통합 관리 할 수 있다. 마스터 프레임은 수시로 전송하되 전송주기는 DARC 채널 용량을 감안하여 조정한다

----------------------------------------------------------------------

_{<마스터> :=}

_{<마스터ID> // 마스터 구별자}

_{if (<마스터ID> = 01h) then <서비스 마스터> // 전송되는 마스터}

_{if (<마스터ID> = 02h) then <네트웍 마스터>}

_{if (<마스터ID> = 03h) then <스케줄 마스터>}

_{if (<마스터ID> = 04h) then <컨텐츠 마스터>;}

----------------------------------------------------------------------

여기서, <마스터ID>의 Data Type은 <intunti>이다. 마스터ID에 따라서 마스터를 결정한다. 마스터의 종류는 첨부하는 도 20과 같다.

도 20은 텍마스터 종류를 설명하기 위한 도면이다.

도 20을 참조하면, 서비스마스터(<마스터ID>=01h)는 SPID, 암호화 여부, 정보종류 등 메시지의 기본 정보를 전송해주기 위한 마스터로서, 필수 전송 사항이다.

----------------------------------------------------------------------

_{<서비스 마스터>:=}

_{<SPID>, // Service Provider ID}

_{<En>, // Encryption Indicator}

_{<Ctg>, // Category}

_{<UpC>, // Update Counter}

_{<Ctrl>; // Control}

----------------------------------------------------------------------

여기서, <SPID>는, 정보제공자 분류를 위한 ID이고, <Ctg>는 카테고리 메시지의 정보 종류를 나타내는 1바이트 카테고리로 <어플리케이션ID>마다 재정의된다.

또한, <UpC>(Update Count)는 메시지의 내용이 변경될 때마다 '1'부터 '255'까지 증가시켜 표시하는데, '255'가 넘으면 다시 '1'부터 카운트하며, 해당 메시지의 내용에 변화가 없으면 이 값은 변경되지 않고 송출한다.

또한, <Ctrl>은 지정한 메시지에 대한 처리를 명령하며, 각 어플리케이션마다 재정의될 수 있다.

네트웍 마스터(<마스터ID>=02h)는 지정한 메시지의 정보 내용과 동일, 또는 관련 정보를 송출하는 송출국의 서비스제공자 ID(SPID)와 주파수 리스트를 아래와 같이 전송한다. 수신기에서는 상기 정보를 이용하여 현재 송출국의 수신 범위를 벗어나더라도 지속적인 서비스를 받을 수 있다.

----------------------------------------------------------------------

_{<네트워크 마스터>:=}

_{<NOL> (n), // Number Of Link}

_{n * <연결정보>; // n * (SPID, Frequency)}

----------------------------------------------------------------------

----------------------------------------------------------------------

_{<연결정보>:=}

_{<SPID>, // Service Provider ID}

_{<AFrq>; // Associative Frequency Table}

----------------------------------------------------------------------

여기서, <NOL>(Number Of Link)의 Data Type은 <intunti>이고, 연결 정보의 수를 의미한다. 또한, <연결정보>는 동일 네트웍 혹은 관련 네트웍 내에서 동일한 혹은 관련된 서비스 정보를 전송하는 매체의 연결정보를 의미한다. 또한, <SPID> (Service Provider ID)는 동일한 어플리케이션의 동일한 정보를 전송하는 서비스 주체의 SPID를 의미하며, <AFrq>는 해당 정보를 송출하는 송출국 주파수의 주파수 테이블 값이다.

스케줄 마스터(<마스터ID>=03h)는 아래와 같이 지정한 메시지의 전송운영시간, 서비스영역 등의 정보를 준다. 수신기에서는 이 정보를 이용하여 특정정보에 대해 정보 송출시간에 수신기를 운영할 수 있다.

----------------------------------------------------------------------

_{<스케쥴 마스터>:=}

_{<정보시각>, // 정보시각(UTC format)}

_{<Time_Slot>, // 전송주기}

_<SAC>;

----------------------------------------------------------------------

여기서, <정보시각>은 UTC time을 사용하며, 통상적으로 데이터 전송시각을 의미한다. 각 어플리케이션마다 <정보시각>의 의미를 재정의할 수 있다. 또한, <Time_Slot>는 메시지 서비스정보의 시작시간과 반복주기 그리고 duration을 지정하는 데 이용한다. 또한, <SAC>는 해당 서비스가 전송되는 범위를 코드로 표시한다.

컨텐츠 마스터(<마스터ID>=04h)는 아래와 같이, 지정한 메시지의 설명이나 기타 추가정보를 문자열로 송출하는 마스터이다.

----------------------------------------------------------------------

_{<컨텐츠 마스터>:=}

_{<short_string>, // 메시지에 대한 설명}

----------------------------------------------------------------------

이상에서는 본 발명에 따른 프레임 어플리케이션에 대해서 설명하였다. 그러면 본 발명에 따른 마크업 문서의 부호화에 대해서 상세히 설명한다.

본 발명에서는 유무선 인터넷에서 사용되는 마크업 언어로 만들어진 문서를 DARC 채널을 통하여 보낼 때의 프로토콜을 규정하는데, 국제적으로 정의된 마크업 언어의 문법을 따르는 문서를 엔코딩하여 전송한다. 특히, 프레임 단위로 전송하는 프레임 어플리케이션을 따른다.

일단, 마크업 문서를 엔코딩하는 규격을 정의함에 있어서 고려한 점은 다음과 같다.

첫째는 무선 인터넷에서 사용 가능한 마크업 언어로의 호환을 가능하게 하고, 둘째는 DARC가 일방향 통신이라는 점을 감안하여, 마크업 언어 중 DARC 전송에 적합한 부분을 규격화하였으며, 그 외 수신기에서 문서 수신에 필요한 것들을 첨가하였다.

KARD 2.0에서는 무선 마크업 언어 중 일방향 통신에 적합한 내용을 취하였으며, DARC가 타무선 인터넷과 동시 서비스되었을 경우를 대비하여, 양방향 통신에 필요한 내용을 일부 포함한다.

본 발명에 따른 KARD규격에서는 마크업 문법에 대해서 설명은 가능한 생략하였고, 문서를 DARC에 적용시키는 내용과, 마크업 언어 중 DARC에서 채용하는 문법을 규정한다.

단말기가 DARC 마크업 문서 수신을 하는데 있어서 요구사항이 있으며 이는 다음과 같다.

즉, Right & Left(좌우) 스크롤 키 지원은 옵션이며, Up & Down(상하) 스크롤 키를 지원하여야 한다.

또한, 선택(Accept) 및 메뉴(Options) 버튼을 지원해야 한다. 이들 버튼은 소프트 버튼으로, 프로그램이 가능한 기능 버튼으로, 그 레이블의 변경이 가능해야 한다.

본 발명에 따른 마크업 문서의 계층3인 프리픽스에는 어플리케이션ID=3을 할당하여, 프레임 복호 및 마크업 문서의 전송임을 나타낸다.

본 발명에 따른 마크업 문서의 프레임 구조는 상기에서 정의한 프레임 어플리케이션을 따른다. 마스터 프레임과 데이터 프레임으로 구분할 수 있으며, 마스터는 상기한 프레임 어플리케이션의 규정에 따르고 필요할 경우 재정의된다. 본 발명에서는 데이터에 대한 규정을 한다.

----------------------------------------------------------------------

_{<프레임> :=}

_{<M/D SelF>, // 마스터/데이터 식별자(프레임)}

_{<Msg IDF>, // Message ID}

_{<Size>(n), // 데이터 또는 마스터 크기(Byte)}

_{if (<M/D SelF> = 01h) then <마스터>}

_{if (<M/D SelF> = 81h) then <데이터>;}

----------------------------------------------------------------------

여기서, 마스터(<M/D SelF >=01h)에 대해서 보다 상세히 설명하면, 서비스마스터(<마스터ID>=01h)는 상기한 프레임 어플리케이션의 규정을 따른다. 다만, 1바 이트 카테고리로 문서의 내용상의 범주를 분류하는 <Ctg>는 재정의된다.

네트웍 마스터(<마스터ID>=02h)는 프레임 어플리케이션의 규정을 따르고, 스케쥴 마스터(<마스터ID>=03h)는 프레임 어플리케이션의 규정을 따르며, 컨텐츠 마스터(<마스터ID>=04h)는 프레임 어플리케이션의 규정을 따른다.

한편, 전송되는 데이터(<M/D SelF >=81h)는 아래와 같이, <Divider> 및 <SeqData>로 이루어진다. 전송되는 데이터의 크기가 클 경우 Divider에서 분할되어 전송됨을 표현하고, SeqData에 분할된 데이터를 전송한다.

----------------------------------------------------------------------

_{<데이터> :=}

_{<Divider> // 전송 데이터의 분할}

_{<SeqData> // 분할된 데이터}

----------------------------------------------------------------------

여기서, <Diveder>에 따라서 문서는 아래와 같이, 분할되어 전송되어 질 수 있다. 총 분할된 개수와 전송되는 순번을 보냄으로서 수신기는 분할되어 오는 데이터를 수신하여 연결이 가능하다.

----------------------------------------------------------------------

_{<Divider> :=}

_{<DivNum> // 총 분할된 개수}

_{<Sequence> // 전송되는 순번}

_{<SizeOfSeqData> // 전송되는 SeqData의 크기}

----------------------------------------------------------------------

여기서, <DivNum>의 Data Type은 <intunti>이다. Doc을 분할하여 전송할 때 총 분할되는 개수이다. 또한, <Sequence>의 Data Type은 <intunti>이다. Doc을 분할하여 전송할 때의 순번이다. 또한, <SizeOfSeqData>의 Data Type은 <intunli>이다. SeqData의 크기이다.

<SeqData> 여러 개가 모여서 하나의 <Document>를 이룬다. 분할되지 않았을 경우에는 하나의 <SeqData>가 하나의 Document가 된다.

그러면, <Document>의 구조에 대해서 자세히 설명한다.

----------------------------------------------------------------------

_{<Document> :=}

_{<DocHeader>, // Markup Document Header}

_{<Doc>, // Mardup Document}

----------------------------------------------------------------------

여기서, DocHeader는 아래와 같다.

----------------------------------------------------------------------

_{<DocHeader> :=}

_{<DocID>, // Document ID}

_{<UpC>, // Update Counter of Doc}

_{<RoS>, // Run or Save}

_{<Level>, // Level}

_{<intunti>, // Reserved}

_{<DocName>; // Document Name}

----------------------------------------------------------------------

여기서, <DocID>의 Data Type은 <intunli>이다. 전송되는 문서의 고유 ID이다. 단 문서상의 제약사항으로 2바이트 크기의 DocID는 각각의 바이트 속에 20h 이하의 값이 들어갈 수 없다.

또한, <UpC>의 Data Type은 <intunti>이다. 문서(Doc)의 내용이 변경될 때마다 1부터 255까지 증가시켜 표시한다. 255가 넘으면 다시 1부터 카운트한다. 해당 문서의 변화가 없으면 이 값은 변경되지 않고 송출한다.

또한, <RoS>의 Data Type은 <intunti>이다. 해당 문서를 수신 즉시 표출해야 할 경우 01h를, 저장만 할 경우 02h를 셋팅하여 전송한다.

또한, <Level>의 Data Type은 <intunti>이다. 마크업 문서 중 최초로 표출되어져야 되는 문서를 구분하기 위하여 사용한다. 최초 표출 문서일 경우 01h를 세팅하고 그 이외의 경우는 81h를 셋팅하여 전송한다.

또한, <DocName>의 Data Type은 <string>이다. 문서의 이름을 전송한다. 이 문자열이 무선 인터넷 파일 이름이 될 수 있다.

한편, Doc의 Data Type은 <long_string>형식을 따른다. 따라서 처음 2바이트는 Doc의 크기를 의미하고 Doc의 실제 문서내용은 그 이후에 채워진다. Doc에 들어가는 문서의 문법에 대해서는 보다 상세히 설명한다.

본 발명에 따른 DARC의 마크업 문법은 XML의 무선 인터넷 문법을 그대로 수용을 하되, 필요한 기능의 내용만을 사용한다. 따라서 본 발명에서 기술하는 내용은 무선인터넷 마크업 문법의 일부이다.

인터넷 마크업 언어는 태그 중심의 언어로 기술이 되는데, KARD 규격 정의에서 중요한 점은 각 태그가 한 바이트 크기의 코드로 전송된다는 점이다. 즉 KARD의 마크업 언어의 부호화는 각 태그와 속성들과 그 외 필요시 KARD가 규정한 태그와 속성들을 코드화 한 것이다.

그 문서의 구조와 특징에 대해서 설명하면, 하나의 문서는 여러 개의 카드로 구성되어져 있다. 하나의 문서가 전송되면 문서의 첫 번째 카드가 표시된다. 여기서 카드는 수신기의 표출단위이다. 이때 사용자는 첫 번째 카드의 내용을 단말기 화면 창을 통해 볼 수 있으며, 전송된 하나의 문서 내에 다른 카드로 이동할 수 있다. 전송되는 문서의 특징 및 기능들을 정리하면 다음과 같다.

첫째, 텍스트 기반의 문서를 제공하는 기능을 갖는다. 즉, 단순한 텍스트 기능의 제공뿐만 아니라 굵은 글씨체, 기울임 꼴 등과 같은 다양한 Font 타입 및 크기를 제공할 수 있다. 물론 모든 Font 기능이 다 제공되는 것은 아니며 이를 보여 주는 단말기에서 지원하는 Font 기능에 따라 달라질 수 있다.

둘째, 사용자 입력 기능을 갖는다. 즉 카드에서 사용자의 입력을 받아 처리할 수 있다. 사용자 Input의 종류에는 사용자가 직접 입력하는 텍스트, 다수개의 옵션 리스트에서 사용자 선택 입력 그리고 이전 카드 또는 다음 카드로의 네비게이션(Navigation) 등이 있다.

셋째, 네비게이션(Navigation) 및 히스토리 스택(History Stack)을 갖는다, 즉, 단말기에서는 일반 인터넷과 같이 네비게이션 및 히스토리 스택기능을 구현할 수 있다. 따라서 하나의 문서에서 이전 카드 또는 다음 카드로의 네비게이션이 가능해지고 이전에 보았던 문서 또는 다른 문서로의 전이가 가능하도록 구현할 수 있다.

본 발명에 따라 전송되는 문서 구문의 문법은 HTML 문서와 유사하다. 단 HTML에서 헤더와 몸체 부분으로 구분되는데, 본 발명에서는 도 21에 도시한 바와 같이, DARC의 채널 용량을 감안하여 헤더 없이 몸체 부분만 정의하고 전송한다.

도 21을 참조하면, 혼란을 방지하기 위해, 이 이후부터 사용되는 꺽쇠기호 '<', '>'는 앞에서 설명한 Data Type 구분자가 아닌 일반 마크업 언어의 태그를 구분하기 위한 기호로 사용됨을 알려둔다. 또한 태그를 표시하기 위한 일반 인터넷 마크업 언어의 기호 '<', '>', '/'를 다음과 같이 20h이하의 값들로 부호화한다. 20h 이하의 코드는 문서 내에서 태그를 위한 코드로 예약이 되어있다.

태그를 위한 기호사이에는, 즉 '<'와 '>'사이에는 요소와 속성 그리고 속성값이 들어간다. 예를 들어 2개의 속성이 포함된 태그를 예시해보면,

_{<emt att1=att_val1 att2=att_val2>}

여기서, 요소 emt, 속성 att1, att2, 속성값 att_val1, att_val2중에서 문자열인 att_val2를 제외한 나머지들은 모두 KARD에서 1바이트 크기 혹은 2바이트 크기로 부호화 한 값들로 전송된다. att_val2는 양쪽에 quotation 마크로 감싸여져 있는데 이것이 문자열임을 표현하는 것이다. 위의 태그가 KARD에 의해 전송될 때, 태그내의 space와 = 는 전송시 생략되어지며, 따라서 부호화 값들이 없다. 만약 위의 att_val2가 문자3개의 문자열이라면 att_val2는 6바이트가 될 것이며, 태그를 위한 기호들 <, > 와 그리고 요소 emt, 속성 att1, att2, 속성값 att2가 각각 1바이트씩을 차지한다면 모두 8바이트가 되므로 위의 태그는 총 14바이트가 된다.

KARD에서 정의하는 요소들은 도 22와 같이 분류할 수 있다.

한편, KARD에서는 사용하는 마크업 언어의 요소와 속성을 규정하고, 그 코드값들을 정의하는데, 요소와 속성의 코드값을 정의하는데 있어서 다음과 같은 규칙이 있다.

즉, 코드값들은 20h 이하의 값들은 올 수 없다. 여기서, 20h 이하값들은 제어코드로 예약이 되어 있다.

또한, 요소를 부호화하는데 있어 짝을 이루는 요소일 경우에 20h~7Fh, 짝을 이루지 않는 단일 요소일 경우 80h~FFh 값들로 부호화하였다.

또한, 속성을 부호화하는데 있어서, 속성값이 문자열(string)이 되면 80h~FFh 사이의 값으로 부호화하고, 속성값이 문자열이 아닌 값이며 1바이트 크기 이면 20h~3Fh, 2바이트 크기이면 40h~7Fh사이의 값으로 부호화한다.

한편, KARD에서 사용되는 요소와 속성의 코드값들은 도 23a 내지 도 23c에 도시한다.

한편, 본 발명에 따른 마크업 문서의 전송에서 문서(Doc)는 하나 이상의 카드(Card)로 이루어져 있고, 각각의 Card는 단말기에서 보여줄 내용을 담고 있다.

여기서, doc 요소는 해당 요소의 속성은 정의하지 않으나, 하나의 문서의 시작과 끝을 알린다. 문서는 <doc>으로 시작하여 <doc/>으로 끝난다. 또한, card 요소는 도 24a에 도시한 바와 같이, 화면을 보여주는 하나의 단위가 되지만 단말기의 특성에 따라서 하나의 카드가 여러 화면으로 나누어 보여질 수도 있다.

또한, Template는 도 24b에 도시한 바와 같이, 하나의 문서에 있는 모든 Card에 적용되는 규칙을 설정하기 위해 사용된다. 만약 문서 전체에 설정한 Template 기능을 사용하고 싶지 않을 경우에는 해당 Card에서 재정의하면 가능하다.

한편, 이벤트는 사용자가 특정 버튼을 누른다거나 또는 특정한 시간이 경과하여 설정한 특정 태스크(Task)가 발생하는 것과 같이 문서 내에 발생하는 특정 사건을 나타낸다. 즉, 특정한 이벤트에 대한 태스크(Task)가 설정되어 있는 상태에서 해당 이벤트가 발생할 경우, 미리 설정된 태스크(Task)를 실행하여 발생한 이벤트를 처리할 수 있게 된다.

본 발명에 따른 do 요소는 사용자 인터페이스와 관련된 이벤트 처리를 위해 주로 사용된다. 따라서, 사용자 인터페이스와 관련된 요소(Accept 및 Option)버튼 의 클릭 등)에서 이벤트가 발생하면 발생한 타입과 일치하는 <do> ~ </do>사이에 있는 task가 실행된다. task에 사용될 수 있는 요소는 다음과 같다.

----------------------------------------------------------------------

_<go>

_<prev>

_<noop>

_<refresh>

----------------------------------------------------------------------

도 24c는 do 속성과 부호화를 설명한다.

도 24c를 참조하면, timer 요소는 카드 내에서 ontimer 이벤트를 발생시키다. timer 요소에 의해 설정한 시간이 경과했을 경우 발생하며, 시간의 단위는 0.1초로 만약 100으로 설정할 경우, 실제 ontimer 이벤트가 발생하는 시간은 10초가 된다. ontimer 이벤트가 발생하면, 해당 card 속성중에 ontimer나 ontimer_kard에 의해 설정된 목적지(destination)로 이동한다.

도 24d는 timer 속성과 부호화를 설명한다.

한편, 태스크는 특정한 이벤트가 발생했을 때 수행할 일(Task)을 명시하는 작업으로, 본 발명에서 규정하는 것은 'go', 'prev', 'noop' 그리고 'refresh'의 네 가지 태스크 요소가 있다. 태스크가 수행되려면 특정한 이벤트를 감지하는 일종의 핸들러(Handler)가 있어야 하며 따라서 태스크는 do와 같이 사용된다. 즉 <do>~</do> 태그 사이에 태스크 태그가 위치하게 된다.

보다 상세히는, 'go' 태스크는 현재 표시중인 Card에서 주어진 Destination으로 이동시키는 작업을 수행하며, go 태스크에서 정의한 destination으로 이동한 후에는 이동한 destination을 히스토리 스택(History Stack)에 쌓는 역할을 한다.

도 24e는 go 속성과 부호화를 설명하기 위한 도면이다.

'prev' 태스크는 현재 실행중인 Card의 바로 전에 실행한 Card로 이동하는 기능을 수행한다. 따라서 히스토리 스택(History Stack)에 아무런 입력도 되어 있지 않은 경우, prev 태스크는 아무런 작업도 수행하지 않는다. prev는 아무런 속성도 가지지 않는다.

'refresh' 태스크는 간단히 새로 고침 작업을 수행한다. 즉, 현재 실행중인 Card에서 보여주는 변수 값을 새로 고쳐 다시 보여주는 역할을 수행한다. refresh는 아무런 속성도 가지지 않는다.

'noop' 태스크는 No Operation의 약자로 아무 작업도 수행하지 않는다는 것을 의미한다. noop의 용도는 보통 Template에서 문서 전체에 설정한 do 요소를 현재 Card에 적용시키지 않기 위해 많이 사용한다. noop는 아무런 속성도 가지지 않는다.

변수(Variables)는 사용자로부터 입력을 받거나 또는 문서 내에서 변수 값을 설정할 때 사용된다. 참고로 마크업 문서에서 사용하는 변수의 이름은 다음과 같은 특징을 따른다.

-변수 이름 첫 글자: '_', 알파벳('a'~'z', 'A'~'Z')

-변수 이름 두 번째 이후의 글자: '_', 알파벳('a'~'z', 'A'~'Z'), 숫자(1~9)

-변수의 이름은 대소문자를 구분한다.

-변수의 값을 가져올 경우에는 변수의 이름 앞에 $를 붙인다. 즉 변수의 이름이 apple이라면 apple 변수의 값은 $apple가 된다.

-문장 상에서 $를 표시하려면 $$를 사용한다.

setvar 요소는 도 24f에 도시한 바와 같이, <go>, <prev>, <refresh>의 태그를 실행할 때 해당 변수의 값을 설정하는데 사용된다.

사용자 Input은 문서상에서 사용자의 입력을 받아들이는 방식을 명시하는 것으로 사용자로부터 글자를 입력받거나 또는 사용자에게 여러 개의 리스트를 주어 사용자 선택을 입력받을 수 있다.

여기서, input 요소는 도 24g에 도시한 바와 같이, 사용자로부터 텍스트 값을 입력받기 위한 요소이다. input 요소는 format속성을 사용하여 특정한 형식으로 사용자로부터 입력받을 수 있다.

또한, select 요소는 도 24h에 도시한 바와 같이, 여러 가지 옵션 중에서 하나 또는 둘 이상을 사용자가 선택할 수 있도록 해준다.

또한, option 요소는 도 24i에 도시한 바와 같이, select 요소와 같이 사용되며 사용자가 선택할 수 있는 리스트를 제공한다.

그러면, Anchors, Images, Timers에 대해서 설명한다.

먼저, a 요소는 도 24j에 도시한 바와 같이, 간단히 링크를 말하는 것으로 링크로 할당할 수 있는 요소로는 글자 또는 그림이 있다. 따라서 사용자가 링크를 선택하고 Accept 버튼을 클릭하면 a 요소의 속성에 명시된 destination으로 이동하게 된다.

또한, img 요소는 도 24k에 도시한 바와 같이, 단말기 화면에 그림을 출력하기 위해서 사용된다. 단말기의 종류에 따라서 img 요소를 지원할 수도, 그렇지 않을 수도 있다.

또한, timer 요소는 문서 card에 특정 이벤트를 발생시킬 특정 시간을 설정하기 위해 사용한다. 즉 card을 실행한 뒤에 timer에서 설정한 시간이 경과하면 ontimer 이벤트가 발생한다.

텍스트 포맷은 단말기 화면에 보여지는 글자의 모양, 크기, 배치 등에 대한 설정을 수행한다.

즉, em 요소는 글자를 강조하며, strong 요소는 글자를 더 강조하며, i 요소는 이탤릭체로 나타내고, b 요소는 글자를 굵게 나타낸다. 또한, u 요소는 글자에 밑줄을 긋고, big 요소는 글자를 크게 나타내며, small 요소는 글자를 작게 나타낸다. 또한, p 요소는 도 24l에 도시한 바와 같이, 새로운 문단을 정의하고 정의한 문단을 어떻게 나타낼 것인지를 명시한다.

또한, br 요소는 CR&LF 와 같은 역할을 수행한다. 즉, br 요소는 화면상에 한 라인을 띄우는 역할을 한다. 또한, table 요소는 도 24m에 도시한 바와 같이, 문서 내의 테이블을 작성하기 위해 사용되고 html과 거의 비슷하다.

또한, tr 요소는 table 태그 사이에 사용되어, 테이블의 하나의 행을 정의하 고, td 요소는 tr 태그 사이에 사용되어, 행의 열을 정의한다.

이상에서는 본 발명에 따른 마크업 문서의 부호화에 대해서 설명하였다.

그러면, 파일전송 서비스 어플리케이션(File Transfer Service(FTS) Application)에 대해서 설명한다.

본 발명에서는 파일정보 전송(File Transfer Service)에 대해 규정하고, 프레임 단위로 전송이 되며 프레임 어플리케이션을 따른다.

프리픽스(계층 3)에서는 어플리케이션ID=5를 할당하여, 프레임 복호 및 마크업 문서의 전송임을 나타낸다. 그 프레임 구조는 상기한 프레임 어플리케이션을 따른다. 마스터 프레임과 데이터 프레임으로 구분할 수 있으며, 마스터는 상기한 프레임 어플리케이션의 규정에 따르고 필요할 경우 재정의된다. 본 발명에서는 아래와 같이, 데이터에 대한 규정을 한다.

----------------------------------------------------------------------

_{<프레임> :=}

_{<M/D SelF>, // 마스터/데이터 식별자(프레임)}

_{<Msg IDF>, // Message ID}

_{<Size>(n), // 데이터 또는 마스터 크기(Byte)}

_{if (<M/D SelF> = 01h) then <마스터>}

_{if (<M/D SelF> = 81h) then <데이터>;}

----------------------------------------------------------------------

상기한 마스터(<M/D SelF >=01h)는 서비스 마스터, 네트워크 마스터, 스케쥴 마스터, 컨텐츠 마스터로 이루어진다.

즉, 서비스마스터(<마스터ID>=01h)는 프레임 어플리케이션의 규정을 따르며, 다만, 1바이트 Category로 문서의 내용상의 범주를 분류하는 <Ctg>로 재정의된다.

또한, 네트웍 마스터(<마스터ID>=02h)는 프레임 어플리케이션의 규정을 따른다.

또한, 스케쥴 마스터(<마스터ID>=03h)는 프레임 어플리케이션의 규정을 따른다.

또한, 컨텐츠 마스터(<마스터ID>=04h)는 프레임 어플리케이션의 규정을 따른다.

한편, 전송되는 데이터(<M/D SelF >=81h)는 아래와 같이, <Divider>, <SeqData>로 이루어진다. 전송되는 데이터의 크기가 클 경우 Divider에서 분할되어 전송됨을 표현하고, SeqData에 분할된 데이터를 전송한다.

----------------------------------------------------------------------

_{<데이터> :=}

_{<Divider> // 전송 데이터의 분할}

_{<SeqData> // 분할된 데이터}

----------------------------------------------------------------------

여기서, <Diveder>에 따라서 문서는 분할되어 전송되어 질 수 있다. 즉, 아래와 같이, 총 분할된 개수와 전송되는 순번을 보냄으로서 수신기는 분할되어 오는 데이터를 수신하여 연결이 가능하다.

----------------------------------------------------------------------

_{<Divider> :=}

_{<DivNum> // 총 분할된 개수}

_{<Sequence> // 전송되는 순번}

_{<SizeOfSeqData> // 전송되는 SeqData의 크기}

----------------------------------------------------------------------

여기서, <DivNum>의 Data Type은 <intunti>이다. Doc을 분할하여 전송할 때 총 분할되는 개수이다. 또한, <Sequence>의 Data Type은 <intunti>이다. Doc을 분할하여 전송할 때의 순번이다. 또한, <SizeOfSeqData>의 Data Type은 <intunli>이다. SeqData의 크기이다.

한편, 상기한 <SeqData> 여러 개가 모여서 하나의 FileData을 이룬다. 분할되지 않았을 경우에는 하나의 <SeqData>가 하나의 File가 된다.

그러면, 아래와 같이 표시될 수 있는 FileData의 구조는 보다 상세히 설명한다.

----------------------------------------------------------------------

_<FileData>:=

_{<FileHeader>, // File Header}

_{<File>, // File}

----------------------------------------------------------------------

여기서, FileHeader는 아래와 같이 나타낼 수 있다.

----------------------------------------------------------------------

_{<FileHeader> :=}

_{<FileID>, // File ID}

_{<UpC>, // Update Counter of File}

_{<ROS>, // Run or Save}

_{<intunti>, // Reserved}

_{<intunti>, // Reserved}

_{<FileName>; // File Name}

----------------------------------------------------------------------

여기서, <FileID>의 Data Type은 <intunli>이다. 전송되는 파일의 고유 ID이다. 단 2바이트 크기의 FileID는 각각의 바이트 속에 20h 이하의 값이 들어갈 수 없다.

또한, <UpC>의 Data Type은 <intunti>이다. 파일(File)의 내용이 변경될 때마다 '1'부터 '255'까지 증가시켜 표시한다. '255'가 넘으면 다시 '1'부터 카운트한다. 해당 문서의 변화가 없으면 이 값은 변경되지 않고 송출한다.

또한, <RoS>의 Data Type은 <intunti>이다. 해당 파일을 수신 즉시 표출해야 할 경우 01h를, 저장만 할 경우 02h를 셋팅하여 전송한다.

또한, <FileName>의 Data Type은 <string>이다. 파일의 이름을 전송한다. 이 문자열이 무선 인터넷 파일 이름이 될 수 있다.

한편, File의 Data Type은 <long_string>형식을 따른다. 따라서 처음 2바이트는 File의 크기를 의미하고 File의 실제 데이터는 그 이후에 채워진다.

이상에서는 파일 전송 서비스 어플리케이션에 대해서 설명하였다. 그러면 위치 정보 서비스 어플리케이션(Positioning Information Service(PIS) Application)에 대해서 설명한다.

특히, 본 발명에서는 위치정보 전송(Positioning Information Service)에 대해 규정한다. 통상적으로 인공위성을 이용한 위치결정 시스템인 GPS(Global Positioning System)는 3차원 위치를 실시간으로 파악할 수 있는 능력을 제공해 주는 동시에 정확한 시간 정보를 제공해주는 첨단 위성측위 시스템이다.

그러나 자기 자신의 위치 및 속도 정보가 요구되는 여러 분야에서 GPS는 훌륭한 위치정보 제공자의 역할을 수행 할 수 있지만, 자체의 구조적 한계 때문에 위치결정 능력에 제한을 받게 된다.

이러한 GPS를 이용한 정밀 위치 결정에 수반되는 이러한 제약 조건을 해결하 기 위해 고안된 기술이 차등보정 GPS(Differential GPS)측위 기법이며, 다음과 같은 FM DARC 채널이 갖는 장점으로 FM DARC는 DGPS 또는 RTK와 같은 위치 정보 전송에 매우 적합한 매체라 할 수 있다.

즉, 전파 전달 특성이 양호한 양질의 주파수 대역을 확보할 수 있고, 우수한 도달 특성을 통한 광범위한 수신지역을 확보할 수 있으며, 다수의 이용자가 정보를 동시에 공유할 수 있고, 이동 수신에 적합한 장점이 있다.

그러면 본 발명에 따른 위치 정보 전송 서비스를 위해서는 어플리케이션ID=11을 할당하여, 프레임복호 및 PIS 전송임을 나타내므로써, 프리픽스를 정의(계층 3)한다.

프레임 구조는 상기한 프레임 어플리케이션을 따른다. 즉, 마스터 프레임과 데이터 프레임으로 구분할 수 있으며, 마스터는 상기한 프레임 어플리케이션의 규정에 따르고 필요할 경우 재정의된다. 본 발명에서는 아래와 같이 데이터를 규정한다.

----------------------------------------------------------------------

_{<프레임> :=}

_{<M/D SelF>, // 마스터/데이터 식별자(프레임)}

_{<Msg IDF>, // Message ID}

_{<Size>(n), // 데이터 또는 마스터 크기(Byte)}

_{if (<M/D SelF> = 01h) then <마스터>}

_{if (<M/D SelF> = 81h) then <데이터>;}

----------------------------------------------------------------------

여기서, 마스터(<M/D SelF >=01h)는 서비스 마스터, 네트워크 마스터, 스케쥴 마스터, 컨텐츠 마스터 중 어느 하나로 이루어진다. 즉, 서비스마스터(<마스터ID>=01h)는 프레임 어플리케이션의 규정을 따르고, 네트웍 마스터(<마스터ID>=02h)는 프레임 어플리케이션의 규정을 따르며, 스케쥴 마스터(<마스터ID>=03h)는 프레임 어플리케이션의 규정을 따르며, 컨텐츠 마스터(<마스터ID>=04h)는 프레임 어플리케이션의 규정을 따른다.

한편, 데이터(<M/D SelF >=81h)는 아래와 같이 나타낼 수 있다.

----------------------------------------------------------------------

_{<데이터>:=}

_{<PID>, // Position ID}

_{<intunti>, // Reserved}

_{if (<PID> = 30h) then <DGPS>}

_{if (<PID> = 31h) then <RTK>;}

_{if (<PID> = 32h) then <위성궤도력>}

_{if (<PID> = 33h) then <기준점좌표>;}

----------------------------------------------------------------------

여기서, <PID>는 위치정보에서 사용되는 정보 종류를 나타내는 ID이고, 보다 상세한 내용은 첨부하는 도 25에 도시한다. 또한, <위치정보 카드>는 <PID>에 따라 <DGPS>, <RTK>, <위성궤도력>, <기준점좌표>로 나뉜다.

한편, DGPS는 차등보정 GPS(Differential GPS) 측위 기법으로 각 위성의 오차정보를 전송해 주며, 위치정보 <PID> 30h로 분류되며, <DGPS>구조는 아래와 같다.

----------------------------------------------------------------------

_{<DGPS> :=}

_{<Header>, //}

_{n * <위성정보>, // 위성정보(Max 12개까지, n < 13)}

_{m * <intunti> (AAh); // 수신되지 않는 위성정보 Dummy}

----------------------------------------------------------------------

----------------------------------------------------------------------

_{<Header> : =}

_{<intunti>, // (Preamble)}

_{6 * <bit>, // (Message Type)}

_{10* <bit>, // (Station ID)}

_{13* <bit>, // (Modified Z-count)}

_{3 * <bit>, // (Sequence Number)}

_{5 * <bit>, // (Length of Frame)}

_{3 * <bit>; // (Station Health)}

----------------------------------------------------------------------

----------------------------------------------------------------------

_{<위성정보> :=}

_{<bit>, // Scale facter}

_{2 * <bit>, // UDRE}

_{5 * <bit>, // Satellite ID}

_{16* <bit>, // PRC (Pseudo Range Correction)}

_{8 * <bit>, // Range Rate Correction}

_{8 * <bit>; // IODE (Issue Of Data Ephemeris)}

----------------------------------------------------------------------

이상에서는 본 발명에 따른 위치 정보 서비스 어플리케이션(Positioning Information Service(PIS) Application)에 대해서 설명하였다. 그러면, 단문 문자 서비스 어플리케이션(Simple Text Service(STS) Application)에 대해서 설명한다.

특히, 본 발명에서는 긴급 정보, 광고, 전광판 등에 적용되는 간단한 형태의 문자 전송 규격을 정의한다. 단순 문자 전송에 있어 기본 전제조건이 있는데, 이는 수신기에서 최소한의 길이인 한 줄의 문자를 표현할 수 있는 디스플레이 구간이 있어야 하며, 수신 즉시 설정된 시간동안 표현하여야 하는 전제 조건이 있다. 단순 문자 전송의 부호화는 문자(Text)를 전송하는데 있어 최소사양의 규격을 정의하였다.

본 발명에 따르면, 프리픽스(계층 3)에 어플리케이션ID=4를 할당하여, 프레임복호 및 단순 문자의 전송임을 나타낸다.

상기한 단문 문자 서비스 어플리케이션의 프레임 구조는 상기한 프레임 어플리케이션을 따른다. 즉, 마스터 프레임과 데이터 프레임으로 구분할 수 있으며, 마스터는 상기한 프레임 어플리케이션의 규정에 따르고 필요할 경우 재정의된다. 본 장에서는 데이터에 대한 규정을 한다.

----------------------------------------------------------------------

_{<프레임> :=}

_{<M/D SelF>, // 마스터/데이터 식별자(프레임)}

_{<Msg IDF>, // Message ID}

_{<Size>(n), // 데이터 또는 마스터 크기(Byte)}

_{if (<M/D SelF> = 01h) then <마스터>}

_{if (<M/D SelF> = 81h) then <데이터>;}

----------------------------------------------------------------------

여기서, 마스터(<M/D SelF >=01h)는 서비스 마스터, 네트워크 마스터, 스케쥴 마스터, 컨텐츠 마스터 중 어느 하나를 나타낼 수 있다. 여기서, 서비스마스터(<마스터ID>=01h)는 프레임 어플리케이션의 규정을 따른다. 다만, 1바이트 Category로 문서의 내용상의 범주를 분류하는 <Ctg>는 재정의 된다.

또한, 네트웍 마스터(<마스터ID>=02h), 스케쥴 마스터(<마스터ID>=03h) 및 컨텐츠 마스터(<마스터ID>=04h)는 프레임 어플리케이션의 규정을 따른다.

한편, 데이터(<M/D SelF >=81h)는 아래와 같이 나타낼 수 있다.

----------------------------------------------------------------------

_{<데이터> :=}

_{<TextHeader>, // Simple Text Header}

_{<Text>, // Simple Text}

----------------------------------------------------------------------

여기서, <TextHeader>는 아래와 같이 나타낼 수 있다.

----------------------------------------------------------------------

_{<TextHeader> :=}

_{<TextID>, // Text ID}

_{<UpC>, // Update Counter of Text}

_{<AliveTime>, // Alive Time}

_{<PresenMode>, // Presentation Mode}

_{<TextSpeed> // Text Speed}

_{<intunti>; // Reserved}

----------------------------------------------------------------------

여기서, <TestID>의 Data Type은 <intunli>이고, 전송되는 Text의 고유 ID이다. 또한, <UpC>의 Data Type은 <intunti>이다. Text의 내용이 변경될 때마다 1부터 255까지 증가시켜 표시한다. 255가 넘으면 다시 1부터 카운트한다. 해당 문서의 변화가 없으면 이 값은 변경되지 않고 송출한다. 또한, <AliveTime>의 Data Type은 <intunli>이다. 해당 Text를 전송받은 후 디스플레이 상에 표출해야 하는 최소 시간(에를 들어 단위는 초)이다. 또한, <PresenMode>의 Data Type은 <intunti>이다. 문자 표출 모드를 설정한다. 01h일 경우 단순 표현 모드, 02h일 경우 흐르는 모드이다. 또한, <TextSpeed>의 Data Type은 <intunti>이다. 단순 표현 모드일 경우는 한 화면에 디스플레이 되는 시간(예를 들어 단위는 초)을 의미하며, 흐르는 모드일 경우는 문자열이 흘러가는 정도를 의미하며, 표준 속도는 05h로 한다.

<Text>의 Data Type <short_string>이며, 최초 1바이트는 string 길이를 나 타내며, 최초 1바이트를 제외한 나머지 부분의 코딩은 다음을 따른다.

즉, 표현되어지는 문자정보는 영문 아스키(ascii) 코드와 KSC-5601 한글 코드로 그 외의 문자 (1Fh 이하)는 제어코드로 사용되어 문자들의 속성 등을 나타낸다. 여기서 정의되지 않은 코드는 예약 영역으로 차후 추가될 수 있다. 제어코드로 사용되는 코드들은 첨부하는 도 26에 도시하였다.

또한, 제어코드는 단일 제어코드와 블록 제어코드로 이루어질 수 있는데, 여기서, 단일 제어코드는 제어 코드하나에 대해서 바로 제어가 이루어지는 제어코드이다. 또한 블록 제어코드는 <SOH>, <EOT>사이에 존재하는 문자열에 대해 해당제어가 일어난다. 주로 해당문자열의 다양한 출력형태를 지원하는 것으로 수신기에서 표현 불가능한 제어일 경우 해당문자열만 출력한다.

상기한 블록 제어코드의 블록 형태는 아래와 같다.

----------------------------------------------------------------------

_{<SOH>(01h), // 제어블록 시작}

_{<intunti>, // 블록 제어코드}

_{n*<byte>, // 제어코드의 영향을 받는 문자열}

_{<EOT>(04h); // 제어블록 끝}

----------------------------------------------------------------------

이상에서는 단문 문자 서비스 어플리케이션(Simple Text Service(STS) Application)에 대해서 설명하였다. 그러면, 본 발명에 따른 패킷 어플리케이션에 대해서 설명한다.

특히, 본 발명에서는 패킷전송 기반의 모든 응용서비스에 적용되는 프로토콜을 규정한다. 주로 어플리케이션 패킷의 구조와 마스터 패킷의 규격 및 전송을 다룬다.

상기한 마스터 패킷에서 규정하는 내용은 서비스의 운영정보, 연결정보, 업데이트정보 등이다. 어플리케이션 데이터 패킷을 수신하기 이전에 데이터 수신 및 복호에 필요한 마스터 패킷 정보를 수신한다. 마스터 패킷은 응용 서비스 데이터 수신에 반드시 필요할 뿐만 아니라, 유용한 정보들도 함께 전송한다.

본 발명에 따르면, 각각의 응용서비스 마다, 프리픽스의 어플리케이션ID가 할당되어 있다. 특히 패킷 어플리케이션은 프리픽스의 복호식별=1을 사용하므로 어플리케이션ID는 16 내지 31을 사용한다.

각각의 응용 서비스마다 마스터정보들이 존재하며, 마스터 정보는 응용서비스의 일부로서 해석되어진다.

도 28a는 본 발명에 따른 패킷 데이터 전송을 설명하기 위한 도면이다.

도 28a를 참조하면, 패킷 데이터 전송은 기본적으로 22 바이트 크기단위의 전송이다. 정보들은 한 패킷 내에 콤팩트하게 들어가게 되는데, 22 바이트 중 최초 바이트의 <프리픽스>는 KARD 전송 계층 3에서 정의를 한다.

본 발명에서는 두 번째 바이트부터 정의를 한다. <데이터헤더>에 따라 크게 데이터 패킷과 마스터 패킷으로 분류가 된다. 여기서, 데이터 패킷은 본 서비스의 주 정보들이 실리는 패킷을 의미하며, 마스터 패킷이라 함은 패킷의 운용정보를 보 내주는 패킷을 의미한다. 여기서는 주로 마스터 패킷에 대해서만 정의를 하고, 각각의 응용서비스에서는 데이터 패킷의 정의 및 마스터 패킷 재정의를 한다.

즉, <데이터헤더>는 도 28b에 도시한 바와 같이, 데이터의 구조 및 내용을 결정하고, 마스터/데이터 구분, 전송정보의 구분, 패킷종류의 구분 등을 담당한다.

도 28b를 참조하면, <M/D Sel> (Master/Data Selector)은 현재의 패킷이 마스터 패킷과 데이터 패킷을 구분하는 구분자이다. 즉, <M/D Sel>=1 일 때 마스터 패킷 <M/D Sel>=0일 때 데이터 패킷을 표시한다. 본 발명에서는 <M/D Sel>=1일 때, 즉 마스터 패킷의 부호화를 담당한다.

또한, <Pac ID>(Packet ID)는 <M/D Sel>가 어떻게 선택되었는지에 따라 다르게 적용되며, 패킷에 실리게 될 데이터의 내용과 구조를 결정한다. 3비트로 할당이 되었으므로, 최대 마스터 패킷 8종류, 데이터 패킷 8종류를 구분하여 전송이 가능하다.

또한, <Msg ID> (Massage ID)는 현재 전송되고 있는 정보를 그룹화한다. 운용상 구분할 필요가 있는 정보들을 <Msg ID>별로 관리한다. Msg ID로 그룹되어진 정보들을 메시지라 한다. <Msg ID>=0은 예약이 되어 있으며, 어플리케이션 내의 모든 메시지를 의미한다.

한편, 마스터 패킷(<M/D Sel>=1)은 <데이터헤더>의 <M/D Sel>=1 일 때 전송되는 패킷이다. 이때 마스터 패킷은 서비스정보, 네트웍정보 , 스케줄정보, 정보설명 및 업데이트정보 등을 전송한다.

<Pac ID>에 따라서 마스터 패킷의 종류를 구별하며, <Pac ID>별 마스터 패킷 전송은 도 28c에 도시한 바와 같다.

도 28c를 참조하면, 마스터 패킷은 <Msg ID>별로 정보를 다르게 전송한다. 즉 메시지별로 정보를 관리한다는 의미이며, 필요시 <Msg ID>를 구분할 필요없이 통합하여 관리할 때에는 <Msg ID>=0을 셋팅하여 전송한다. 마스터 패킷의 전송주기는 DARC 채널용량을 감안하여 조정한다.

서비스 마스터 패킷(<Pac ID>=0)은 어플리케이션 전송의 기본적인 운영정보를 전송한다. 즉, 서비스제공자ID, 암호화/압축여부, 버전번호, 제어정보 등을 전송하여, 수신측의 수용가능여부, 정보처리여부 등을 판단한다. 서비스 마스터 패킷은 필수적인 사항으로, 수시로 전송하되, 채널용량을 감안하여 조정한다.

즉, <SPID>(Service Provider ID)는 서비스제공자ID를 이용하여 각 어플리케이션별, <Msg ID>별 서비스 제공 주체를 식별할 수 있다. 또한, <En>(Encryption Indicator)는 서비스제공자ID를 이용하여 각 어플리케이션별, <Msg ID>별 서비스 암호화여부를 결정한다. 또한, <Ctg>(Category)는 통상적으로 정보 카테고리를 전송할 필요가 있을 때 사용하며, <Ctg>는 각 어플리케이션마다 재정의하여 사용할 수 있다. 또한, <Ver>(Version Number)는 1부터 시작하여, 업데이트가 있을 때마다 1씩 증가시켜서 전송한다. 전송정보의 코드체계의 버전번호를 의미한다. 또한, <Ctrl>를 이용하여, 현재 전송되는 데이터들의 처리여부를 결정할 수 있다.

한편, 네트웍 마스터 패킷(<Pac ID>=1)은 도 28e에 도시한 바와 같이, 동일 네트웍 혹은 관련 네트웍 내에서 동일한 서비스 정보를 전송하는 매체의 연결정보를 전송한다. 네트웍 마스터 패킷은 연결정보가 존재할 때 수시로 전송하며, 채널 용량을 감안하여 조정한다.

여기서, <SPID>(Service Provider ID)는 동일한 어플리케이션의 동일한 정보(<Msg ID>로 그룹핑된 정보)를 전송하는 서비스 주체의 SPID를 의미한다.

또한, <AFrq> (Associative Frequency)는 연결되는 SPID의 주파수코드를 의미한다. 만일 <연결정보>가 없을 경우에는 00hex를 할당한다.

한편, 스케줄 마스터 패킷(<Pac ID>=2)은 도 28f에 도시한 바와 같이, 서비스정보의 전송운영시간 및 서비스 영역을 전송한다.

여기서, <정보시각>은 UTC time을 사용하며, 통상적으로 데이터 전송시각을 의미한다. 각 어플리케이션마다 <정보시각>의 의미를 재정의할 수 있다.

또한, <Time_Slot>는 서비스정보의 시작시간과 반복주기 그리고 duration을 지정하는 데 이용한다.

또한, <SAC>(Service Area Code)는 서비스가 제공되는 정보의 커버리지를 의미한다.

한편, 컨텐츠 마스터패킷(<Pac ID>=3)은 도 28g에 도시한 바와 같이, STI 정보의 <Mag ID>별 Description 정보를 문자열로 전송하고, 컨텐츠 마스터패킷은 수시로 전송하며, 채널용량을 감안하여 조정한다. 여기서, 문자열은 20 바이트 이내로 제한을 하며, <Mag ID>로 구분된 정보를 적절히 묘사하는 내용의 문자열로 전송이 된다.

한편, 업데이트 마스터 패킷(<Pac ID>= 4)은 도 28h에 도시한 바와 같이, 업데이트에 관한 정보를 담당한다. 통상적으로 업데이트 마스터 패킷은 응용서비스의 서비스정보 중 코드체계가 있을 경우, 그것의 업데이트 정보를 전송한다. 업데이트 마스터 패킷은 업데이트에 관한 운용정보만 제공할 뿐 실 업데이트 정보는 제공하지 않는다. 실제 업데이트 정보는 각 응용서비스 내의 데이터 패킷에서 제공한다. 수신기가 업데이트 마스터 패킷을 수신하여, 정보 데이터 베이스 갱신여부를 결정할 수 있다. 마스터 패킷은 수시로 전송하되, 채널용량을 감안하여 조정한다.

여기서, <Ver 1>, <Ver 2>는 모두 버전 번호를 의미하며, 반드시 <Ver 1>은 <Ver 2>보다 크거나 같다. 수신기가 버전번호를 관리할 때, <Ver 1>과 <Ver 2>사이의 버전번호를 갖는 수신기만이 현재의 업데이트 정보를 수신하여 단말기 DB 업데이트가 가능하다. 통상적으로 <Ver 1>은 현재 운영되는 버전번호인 서비스 마스터 패킷의 <Ver>과 동일하다. <Ver 1>과 <Ver 2>가 동일할 경우 업데이트 정보 없음을 뜻한다.

또한, <Ver 3>은 장기간 업데이트 정보를 수신할 때 필요한 정보이다. 통상적으로 <Ver3>는 <Ver2>보다 작으며, 차후 <Time_Slot> 의 시간에 <Ver 3>가 <Ver 2>에 적용이 되어 업데이트 정보를 송출하게 된다. <Ver 3>=0일 경우 장기간 업데이트 정보 없음을 의미한다.

또한, <NI>(Number of Item)은 업데이트 되는 전체 Item 개수이다.

또한, <Time_Slot>은 장기간 업데이트에 관한 스케쥴을 의미한다. 즉, <Ver 3>와 연동이 되어 수신기 업데이트 작용을 돕는다.

이상에서는 본 발명에 따른 패킷 어플리케이션을 설명하였다. 그러면 교통 상황 정보 어플리케이션(Status and Travel Time (STI) Application)에 대해서 설 명한다.

본 발명에서는 교통상황정보(Status and Travel Time Information)에 대해 규정하고, 본 발명에서 언급하는 교통 상황 정보는 사용자에게 구간에 대한 속도 정보, 구간통과 시간 및 상태를 실시간으로 수집하여 가공 전달하는 정보를 의미한다.

본 발명에 따르면 프리픽스 정의는 어플리케이션ID=23을 할당하므로써 패킷복호 및 STI 서비스 전송임을 나타낸다.

STI의 데이터 전송은 도 29a에 도시한 바와 같이, 기본적으로 22 바이트 크기의 패킷 단위의 전송이며, 패킷 어플리케이션 구조를 따른다. <데이터헤더>는 도 29b에 도시한 바와 같이, 데이터의 구조 및 내용을 결정한다. 즉, 마스터/데이터 구분, 전송정보의 구분, 패킷종류의 구분 등을 담당한다.

STI에서는 패킷어플리케이션 <데이터헤더>의 규격을 따른다. STI의 <Msg ID>를 이용하여, 시내교통정보, 고속도로교통정보 등을 구분한다.

본 발명에 따른 마스터 패킷(<M/D Sel>=1)은 패킷 어플리케이션의 마스터 패킷 운용을 따르고, 전송되는 마스터는 다음의 5가지이다.

즉, 서비스 마스터 패킷(<Pac ID>=0)은 패킷 어플리케이션의 규정을 따르고, 전송 교통 ID의 체계를 결정하는 <Ctg>는 STI에서 재정의한다. 예를 들어, <Ctg>=01h일 때 링크ID이고, <Cth>=02h일 때 노드ID체계이다.

또한, 네트웍 마스터 패킷(<Pac ID>=1), 스케줄 마스터 패킷(<Pac ID>=1), 콘텐트 마스터 패킷(<Pac ID>=2), 업데이트 마스터 패킷(<Pac ID>=3)은 각각 패킷 어플리케이션의 규정을 따른다.

한편, 데이터 패킷(<M/D Sel>=0)은 데이터헤더의 <M/D Sel>=0 일 때의 전송되는 패킷이다. 즉, <Pac ID>에 의해 <구간정보>의 내용이 결정된다. 데이터 패킷은 마스터 패킷의 <Ctg>에 따라 Link ID 방식과 Node ID 방식으로 나뉜다.

도 29d는 링크(Link) 전송일 경우(서비스 마스터패킷 <Ctg>=01hex)를 도시하고, 도 29e는 노드(Node) 전송일 경우(서비스 마스터패킷 <Ctg>=02hex)를 도시한다.

본 발명에 따르면 컴팩트하게 압축된 4바이트 크기의 Node 및 Link 체계를 통해서 도로의 일련번호뿐 아니라, 권역별구분자, 도로종별 등을 표출할 수 있다.

또한 <구간정보>에 오는 내용은 <데이터헤더>의 <Pac ID>에 따라 달라지고, 본 발명에서 정한 <Pac ID>별 정보는 도 29f와 같다.

그러면, 본 발명에 따른 교통 유고 메시지 어플리케이션(Road Traffic Message(RTM) Application)을 설명한다.

본 발명에서는 교통정보(Information)에 대해 규정하고, 본 발명에 따른 어플리케이션은 여행자에게 영향을 미치게 되는 도로 또는 관련 구조물의 상태와 교통과 관련된 사건 등의 정보를 제공한다.

어플리케이션ID=22를 할당하므로써, 패킷복호 및 RTM 서비스 전송임을 나타낸다.

STI의 데이터 전송은 도 30a에 도시한 바와 같이, 기본적으로 22 바이트 크기의 패킷 단위의 전송이며, 패킷 어플리케이션 구조를 따른다.

도 30a에 도시한 바와 같이, <데이터헤더>는 데이터의 구조 및 내용을 결정하는데, 도 30b에 도시한 바와 같이, 마스터/데이터 구분, 전송정보의 구분, 패킷종류의 구분 등을 담당한다. 즉, STI에서는 패킷어플리케이션 <데이터헤더>의 규격을 따른다.

한편, 마스터 패킷(<M/D Sel>=1)은 패킷 어플리케이션의 마스터 패킷 운용을 따른다. 전송되는 마스터는 첨부하는 도 30c에 도시한 바와 같이 4가지이다.

도 30c를 참조하면, 서비스 마스터 패킷(<Pac ID>=0), 네트웍 마스터 패킷(<Pac ID>=1), 스케줄 마스터 패킷(<Pac ID>=1), 콘텐트 마스터 패킷(<Pac ID>=2, 데이터 패킷(<M/D Sel>=0)은 패킷 어플리케이션의 규정을 따른다.

한편, 데이터 패킷(<M/D Sel>=0)은 <데이터헤더>의 <M/D Sel>=0 일 때의 전송되는 패킷이다. <Pac ID>에 의해 데이터 요소들의 내용이 달라지며, 첨부하는 도 30d에 도시한 바와 같이 구분된다.

사고는 도 30e에 도시한 바와 같이, 도로를 이용하는 차량, 사람, 또는 동물 등이 도로에서 상호간의 충돌이나 도로구조물에 의한 충돌에 의해 발생하는 비예측, 비안정적인 상황을 의미한다.

여기서, <Link ID>는 컴팩트하게 압축된 4바이트 크기의 Link 체계로, 도로의 일련번호뿐 아니라, 권역별구분자, 도로종별 등을 표출할 수 있다. 또한, <SECT>는 Link의 시작점으로부터의 위치(0~65,000 in 10 meters)를 나타내고, <MID> (Message ID)는 메시지 별 고유의 ID로서, 하나의 이벤트는 하나의 메시지 ID를 갖는다.

또한, <MVER> (Message Version Numver)는 동일한 메시지의 정보 갱신 관리를 위해 사용한다. 단 버전넘버는 255를 초과하지 못하며, 255가 초과되는 메시지가 있을 경우 메시지 ID를 변경하여 사용한다. 버전넘버가 255일 경우에는 해당 메시지 삭제를 의미한다.

또한, <MGT> (Message Generation Time)는 메시지 생성 시각을 나타내고, <POS> (Position)는 사고 위치 등을 나타낸다.

장애물 정보는 도 30f에 도시한 바와 같이, 도로를 이용하는 차량, 사람, 또는 동물 등이 인위적 또는 자연적인 원인에 의해 도로의 다른 이용자의 진행에 장애를 미치는 상황을 의미한다.

여기서, <Link ID>는 컴팩트하게 압축된 4바이트 크기의 Link 체계로, 도로의 일련번호뿐 아니라, 권역별구분자, 도로종별 등을 표출할 수 있고, <SECT>는 Link의 시작점으로부터의 위치(0~65,000 in 10 meters)를 나타내고, <MID> (Message ID)는 메시지 별 고유의 ID 이며 하나의 이벤트는 하나의 메시지 ID를 갖는다. 또한, <MVER> (Message Version Numver)는 동일한 메시지의 정보 갱신관리를 위해 사용한다. 단 버전넘버는 255를 초과하지 못하며, 255가 초과되는 메시지가 있을 경우 메시지 ID를 변경하여 사용한다. 버전넘버가 255일 경우에는 해당 메시지 삭제를 의미한다. 또한, <MGT> (Message Generation Time)는 메시지 생성 시각을, <POS>는 사고 위치 등을 나타낸다.

한편, 행사 정보는 도 30g에 도시한 바와 같이, 도로 교통에 영향을 미치는 이벤트에 대한 정보를 의미한다.

여기서, <Link ID>는 컴팩트하게 압축된 4바이트 크기의 Link 체계로, 도로의 일련번호뿐 아니라, 권역별구분자, 도로종별 등을 표출할 수 있고, <SECT>는 Link의 시작점으로부터의 위치(0~65,000 in 10 meters)를 나타내고, <MID> (Message ID)는 메시지 별 고유의 ID로서, 하나의 이벤트는 하나의 메시지 ID를 갖는다.

또한, <MVER> (Message Version Numver)는 동일한 메시지의 정보 갱신관리를 위해 사용한다. 단 버전넘버는 255를 초과하지 못하며, 255가 초과되는 메시지가 있을 경우 메시지 ID를 변경하여 사용한다. 버전넘버가 255일 경우에는 해당 메시지 삭제를 의미한다.

또한, <MGT> (Message Generation Time)는 메시지 생성 시각을, <POS>는 행사 위치 등을 나타낸다.

한편, 도로상태 정보는 도 30h에 도시한 바와 같이, 도로 교통에 영향을 미치는 도로 구조물의 변경에 대한 정보를 의미한다.

여기서, <Link ID>는 컴팩트하게 압축된 4바이트 크기의 Link 체계로, 도로의 일련번호뿐 아니라, 권역별구분자, 도로종별등을 표출할 수 있고, <SECT>은 Link의 시작점으로부터의 위치(0~65,000 in 10 meters)를 나타나며, <MID> (Message ID)는 메시지 별 고유의 ID 이며 하나의 이벤트는 하나의 메시지 ID를 갖는다.

또한, <MVER> (Message Version Numver)은 동일한 메시지의 정보 갱신관리를 위해 사용한다. 단 버전넘버는 255를 초과하지 못하며, 255가 초과되는 메시지가 있을 경우 메시지 ID를 변경하여 사용한다. 버전넘버가 255일 경우에는 해당 메시지 삭제를 의미한다.

또한, <MGT> (Message Generation Time)는 메시지 생성 시각을, <POS>는 행사 위치 등을 나타낸다.

도 30f는 네트워크 성능(NETWORK PERFORMANCE)을 정의하기 위한 도면이다.

도 30f에서 정의하는 패킷에서 전송하는 정보는 외부 사건에 의해 도로사용자에게 영향을 미치는 소통에 대한 정보를 의미하며, 엄밀한 의미에서 STI응용에서의 소통정보와는 다르다.

여기서, <Link ID>는 컴팩트하게 압축된 4바이트 크기의 Link 체계로, 도로의 일련번호뿐 아니라, 권역별구분자, 도로종별등을 표출할 수 있고, <SECT>는 Link의 시작점으로부터의 위치(0~65,000 in 10 meters)이며, <MID>(Message ID)는 메시지 별 고유의 ID 이며 하나의 이벤트는 하나의 메시지 ID를 갖는다.

또한, <MVER> (Message Version Numver)는 동일한 메시지의 정보 갱신관리를 위해 사용하는데, 단지 버전넘버는 255를 초과하지 못하며, 255가 초과되는 메시지가 있을 경우 메시지 ID를 변경하여 사용한다. 버전넘버가 255일 경우에는 해당 메시지 삭제를 의미한다.

또한, <MGT>(Message Generation Time)는 메시지 생성 시각을, <LEN>은 영향을 미치는 거리(Length_Affected, 0~65,000 in 10meters)를, <AVGS>는 차량평균속도(0~60 in 0.5meters/sec)를, <DLY>는 통과지연시간(0~65,000 in 1min)을, <TT>는 구간통과시간(0~65,000 in 1min)을 각각 나타낸다.

도 30j는 네트워크 상태(NETWORK CONDITION)를 정의하기 위한 도면이다.

도 30j에서 정의하는 패킷에서 전송하는 정보는 도로 관리(운영)자가 계획된 스케줄에 의해 도로의 소통상태를 변화시켜 도로사용자에게 영향을 미칠 수 있는 정보를 의미한다.

여기서, <Link ID>는 컴팩트하게 압축된 4바이트 크기의 Link 체계로, 도로의 일련번호뿐 아니라, 권역별구분자, 도로종별등을 표출할 수 있고, <SECT>은 Link의 시작점으로부터의 위치(0~65,000 in 10 meters)를 나타내며, <MID> (Message ID)는 메시지 별 고유의 ID로서, 하나의 이벤트는 하나의 메시지 ID를 갖는다.

또한, <MVER> (Message Version Numver)는 동일한 메시지의 정보 갱신관리를 위해 사용하는데, 단지 버전넘버는 255를 초과하지 못하며, 255가 초과되는 메시지가 있을 경우 메시지 ID를 변경하여 사용한다. 버전넘버가 255일 경우에는 해당 메시지 삭제를 의미한다.

또한, <MGT> (Message Generation Time)은 메시지 생성 시각을, <POS>는 행사 위치를, <정보종류C>는 RTM 03을, <LEN>은 영향을 미치는 거리(Length_Affected)를, 상태(CON)는 규제이면 RTM 22, 제한이면 RTM 23, 공사이면 RTM 24를 나타낸다.

도 30k는 시설물을 정의하는 도면이다.

도 30k에서 정의하는 패킷에서 전송하는 정보는 도로 시설물이나 교통 제어기 등의 변화된 정보를 의미한다.

여기서, <Link ID>는 컴팩트하게 압축된 4바이트 크기의 Link 체계로, 도로의 일련번호뿐 아니라, 권역별구분자, 도로종별등을 표출할 수 있고, <SECT>는 Link의 시작점으로부터의 위치(0~65,000 in 10 meters)를 나타낼 수 있다.

또한, <MID>(Message ID)는 메시지 별 고유의 ID 이며 하나의 이벤트는 하나의 메시지 ID를 갖고, <MVER>(Message Version Numver)는 동일한 메시지의 정보 갱신관리를 위해 사용하는데, 단지 버전넘버는 255를 초과하지 못하며, 255가 초과되는 메시지가 있을 경우 메시지 ID를 변경하여 사용한다. 버전넘버가 255일 경우에는 해당 메시지 삭제를 의미한다.

또한, <MGT>(Message Generation Time)는 메시지 생성 시각을, <POS>는 행사 위치를, <정보종류D>는 RTM 04 (TRAFFIC_CONTROL, ROADSIDE_ASSISTANCE, ROADSIDE_SERVICE)를 나타낸다.

또한 TYPE이 TRAFFIC_CONTROL 이면 RTM 25를, ROADSIDE_ASSISTANCE이면 RTM 26을, ROADSIDE_SERVICE 이면 RTM 27을 각각 나타내고, STAT이 TRAFFIC_CONTROL 이면 RTM 28을, ROADSIDE_ASSISTANCE이면 RTM 29를, ROADSIDE_SERVICE 이면 RTM 30을 각각 나타낸다.

도 30l은 긴급정보를 정의하는 도면이다.

도 30l에서 정의하는 패킷에서 전송하는 정보는 도로사용자에게 영향을 미치는 긴급 정보를 의미한다.

여기서, <Link ID>는 컴팩트하게 압축된 4바이트 크기의 Link 체계로, 도로의 일련번호뿐 아니라, 권역별구분자, 도로종별등을 표출할 수 있고, <SECT>는 Link의 시작점으로부터의 위치(0~65,000 in 10 meters)를 나타낼 수 있으며, <MID> (Message ID)는 메시지 별 고유의 ID로서, 하나의 이벤트는 하나의 메시지 ID를 갖는다.

또한, <MVER> (Message Version Numver)은 동일한 메시지의 정보 갱신관리를 위해 사용하는데, 단지 버전넘버는 255를 초과하지 못하며, 255가 초과되는 메시지가 있을 경우 메시지 ID를 변경하여 사용한다. 버전넘버가 255일 경우에는 해당 메시지 삭제를 의미한다.

또한, <MGT> (Message Generation Time)은 메시지 생성 시각을, <POS>는 행사 위치를 각각 나타낸다.

이상에서는 교통 상황 정보 어플리케이션(Status and Travel Time (STI) Application)에 대해서 설명하였다. 그러면, 기상 정보 메시지 어플리케이션(Weather Information Message(WIM) Application)에 대해서 설명한다.

본 발명에서 사용하는 기상 정보는 사용자에게 기상 상태를 실시간으로 수집하여 가공 전달하는 정보를 의미하는데, 어플리케이션ID=25를 할당하여, 패킷복호 및 WIM 서비스 전송임을 나타낸다.

도 31a는 기상 정보의 패킷 구조를 설명하기 위한 도면이다.

도 31a를 참조하면, WIM의 데이터 전송은 기본적으로 22 바이트 크기의 패킷 단위의 전송이다. WIM은 패킷 어플리케이션 구조를 따른다.

도 31a에 도시된 <데이터헤더>는 데이터의 구조 및 내용을 결정한다. 즉, 도 31b에 도시한 바와 같이, 마스터/데이터 구분, 전송정보의 구분, 패킷 종류의 구분 등을 담당한다.

본 발명에 따른 WIM은 패킷 어플리케이션 <데이터헤더>의 규격을 따르는데, 도 31c에 도시한 바와 같이, WIM의 <Msg ID>를 이용하여, 현재기상, 육상예보, 해상예보, 기상특보, 생활지수 등을 구분한다.

마스터 패킷(<M/D Sel>=1)은 패킷 어플리케이션의 마스터 패킷 운용을 따르는데, 전송되는 마스터는 서비스마스터 패킷(<Pac ID>=0), 네트웍 마스터 패킷 (<Pac ID>=1), 스케줄 마스터 패킷(<Pac ID>=1), 콘텐트 마스터 패킷(<Pac ID>=2) 및 업데이트 마스터 패킷(<Pac ID>=3) 등으로 이루어질 수 있고, 각각은 상기한 패킷 어플리케이션의 규정을 따른다.

그러면, 본 발명에 따른 데이터 패킷(<M/D Sel> = 0)에 대해서 상세히 설명한다.

상기한 데이터헤더의 <M/D Sel>=0 일 때의 전송되는 패킷이다. <Msg ID>별로 <Pac ID>에 의해 데이터 패킷의 종류가 구별된다.

도 31e는 현재 기상 1(<Pac ID>=1)의 패킷 구조를 설명하기 위한 도면이다.

도 31e에 도시한 바와 같이, <지역ID>는 기상 지역ID 체계를 따르고, <시각>은 현재 정보가 발생된 시간을 말하며 구조는 첨부하는 도 31f와 같다. 다만, 정보가 없다면 '0'으로 전송한다.

또한, <현재날씨>, 0.1도를 단위로 하는 <현재온도>를 더 포함한다.

또한, 도 31g에 도시한 바와 같이, 현재의 강수량과 누적강수량을 나타내는 <강수량>을 포함하는데, 이때의 단위는 강우량일 경우 0.1mm, 강설량일 경우 0.1cm 이며, Bit 7이 0일 경우에는 강우량을, 1일 경우에는 강설량을 의미한다. 그 외에도 <풍향>, 0.1m/s를 단위로 하는 <풍속> 등의 정보를 포함한다.

도 31h와 도 31i는 육상 단기 예보와 육상 주간 예보의 패킷 구조를 각각 설명한다.

여기서, <날짜선택>은 예보의 해당날짜를 나타내는데, 예를 들어, 날짜선택테이블(WIM 06)에서 오늘, 내일, 모레 중 하루를 선택하여 사용한다.

또한, <예보날씨>는 육상의 예보날씨를 나타내는데, 예를 들어, 예보날씨(3)는 3일 후 예보날씨를 나타내며, 예보날씨(4)는 4일 후 예보날씨를 나타낸다. 예보날씨(5), 예보날씨(6), 예보날씨(7)도 이와 같다.

또한, <예보온도>는 육상의 예보온도를 나타내는데, 데이터의 길이는 <intsiti>를 따르며, 단위는 도(℃)이다. 예를 들어, 예보온도(l)는 최저 예보온도를 나타내고, 예보온도(h)는 최고 예보온도를 나타내며, 예보온도(m)(d)는 1주간의 평균 예보온도의 아래범위를 나타내며, 예보온도(m)(u)는 1주간의 평균 예보온도의 윗범위를 나타낸다.

또한, <강수확률>은 도 31j에 도시한 바와 같이, 육상의 예보 강수 확률을 나타낸다. 예를 들어, Bit 7이 0일 경우에는 비가 올 확률, 1일 경우에는 눈이 올 확률을 의미하며, 단위는 %이다. 정보가 없다면 0으로 전송한다.

도 31k와 도 31l은 해상 단기 예보와 해당 주간 예보의 패킷 구조를 각각 설명한다.

도 31m은 기상특보(<Pac ID>=1, <Msg ID>=4>)의 패킷 구조를 설명한다.

도 31m을 참조하면, 각각 4바이트 크기로 이루어지는 <발표시각>, <발효시각>, <해제시각>을 포함하고, 기상특보의 특보내용을 나타내는 <특보내용>을 포함한다.

도 31m은 생활지수(<Pac ID>=1, <Msg ID>=5>)의 패킷 구조를 설명한다.

도 31m을 참조하면, 외출지수, 빨래지수, 세차지수, 운동지수 등을 포함하는데, 지수(외)는 외출지수를 나타내며, 지수(빨)는 빨래지수를 나타내며, 지수(세)는 세차지수를 나타내며, 지수(운)는 운동지수를 나타낸다.

이상에서는 기상 정보 메시지 어플리케이션에 대해서 설명하였다. 그러면, 이하에서는 증권 정보 메시지 어플리케이션(Stock Information Message (SIM) Application)에 대해서 설명한다. 본 발명에서 언급하는 증권정보는 사용자에게 거래소, 코스닥증권 시황 등을 실시간으로 수집하여 가공 전달하는 정보를 의미하는데, 어플리케이션ID=26을 할당하여, 패킷 복호 및 SIM 서비스 전송임을 나타낸다.

도 32a는 증권 정보에 따른 패킷 구조를 설명하기 위한 도면이다.

도 32a를 참조하면, SIM의 데이터 전송은 기본적으로 22 바이트 크기의 패킷 단위의 전송이고, SIM은 패킷 어플리케이션 구조를 따른다.

여기서, <데이터헤더>는 데이터의 구조 및 내용을 결정하고, 도 32b에 도시한 바와 같이, 마스터/데이터 구분, 전송정보의 구분, 패킷종류의 구분 등을 담당한다. SIM은 패킷 어플리케이션 <데이터헤더>의 규격을 따른다. 다음은 SIM에서 재정의한다.

<Msg ID>(Message ID)는 현재 전송되고 있는 정보를 도 32c에 도시한 바와 같이, 그룹화한다. 운용상 구분할 필요가 있는 정보들을 <Msg ID>별로 관리한다. <Msg ID>는 <MID 1>과 <MID 2>의 두 부분으로 나뉜다. <MID 1>은 <Msg ID>의 상위 1 비트로 전송되는 증권정보가 종목 또는 지수 정보인지 구별하고, <MID 2>는 하위 3비트로 거래소, 코스닥 등을 구별한다.

<MID 1>=0 일 때 지수정보, <MID 1>=1 일 때 종목정보를 전송하는데, 이때 전송되는 정보는 첨부하는 도 32d와 같다.

한편, 마스터 패킷(<M/D Sel>=1)은 패킷 어플리케이션의 마스터 패킷 운용을 따른다. 전송되는 마스터는 도 32e에 도시한 바와 같이, 서비스 마스터 패킷(<Pac ID>=0), 네트웍 마스터 패킷(<Pac ID>=1), 스케줄 마스터 패킷(<Pac ID>=1), 콘텐트 마스터 패킷(<Pac ID>=2), 업데이트 마스터 패킷(<Pac ID>=3)으로 어플리케이션의 규정을 따른다.

한편, 데이터 패킷(<M/D Sel>=0)은 데이터헤더의 <M/D Sel>=0 일 때의 전송되는 패킷이다. <Msg ID>의 <MID 1>에 의해 지수/종목 정보가 나뉘게 되고, <Pac ID>에 의해 구조와 내용이 결정된다. <MID 2>는 전송되는 증권정보의 카테고리를 결정하게 된다.

종목 데이터 패킷의 카테고리는 도 32f에 도시한 바와 같으며, 종목 데이터 패킷은 카테고리별로 정보를 전송하며, <Pac ID>에 따라, 구조와 내용이 결정된다.

도 32g는 종목 데이터 패킷1(<Pac ID>=1)의 패킷 구조를 설명하기 위한 도면이다.

도 32g를 참조하면, <종목코드>는 현재 증권거래소에서 사용되는 코드를 그 대로 따른다. 단지 그 표현방법은 상위 2 바이트가 증권코드 5자리 중 상위 4자리를 헥사값으로 표현하고, 하위 1 바이트가 증권코드 하위 1자리를 아스키코드로 표현한다.

또한, <시각>은 전송되는 정보의 시각을 의미하는데, 일, 시, 분을 표현하며, 구조는 첨부하는 도 32h와 같다.

또한, <업종코드>는 현재 증권거래소에서 사용되는 코드를 그대로 따른다.

또한, <현재가>는 최초 1 비트 단위를 나타내며, 나머지 23 비트의 헥사값으로 수를 표현한다. 예를 들어, 최초 1 비트가 0일 때 단위는 1원, 최초 1 비트가 1일 때 단위는 100원이다.

또한, <등락구분>, <전일대비>, <거래량>, <링크> 정보를 더 포함한다. 여기서, <링크> 정보는 관련 문자정보가 있을 때 연결정보를 의미하며, 순서대로 1 바이트씩 <Deck ID>, <Page ID>, <Card ID>를 나타낸다. 링크정보 없을 경우에는 모두 00h를 전송한다.

도 32i는 종목 데이터 패킷2(<Pac ID>=2)의 패킷 구조를 설명하기 위한 도면으로, <락구분> 정보와 함께, <기준가>, <고가>, <저가> 정보를 포함한다.

도 32j는 종목 데이터 패킷3(<Pac ID>=3)의 패킷 구조를 설명하기 위한 도면으로, <호가순위>, <매도호가>, <매수호가>, <매도호가잔량>, <매수호가잔량> 정보를 포함한다.

도 32k는 종목 데이터 패킷4(<Pac ID>=4)의 패킷 구조를 설명하기 위한 도면으로, 종목 데이터 패킷 4는 <종목 코드>, <NUM>, <Ctrl>, <종목명> 정보를 포함하 여, 증권 종목 및 업종의 업데이트 정보를 전송한다. 수신기가 종목 업데이트 마스터패킷을 수신한 후 업데이트 적용대상일 경우 종목 데이터 패킷 4를 전송받아서, 종목 데이터베이스를 업데이트 시킨다.

여기서, <종목코드>는 3 바이트이므로 상위 1 바이트는 무시되고, 하위 3바이트(Byte4~Byte6)를 이용하여 전송되고, <Num>은 업데이트 마스터 패킷의 <NI>와 연관이 되어 업데이트 되는 종목의 순번을 나타낸다. <Num>은 1부터 시작하여, <NI>까지 전송되게 된다.

또한, <Ctrl>은 업데이트 데이터의 추가/삭제/갱신 등의 제어코드이고, <종목명>은 업데이트 데이터의 내용이 되며, 문자로 14 바이트가 할당된다.

도 32l은 지수 데이터 패킷(<MID 1>=0)의 카테고리를 설명하기 위한 도면이다.

도 32l에 따른 지수 데이터 패킷은 카테고리별로 정보를 전송하며, <Pac ID>에 따라, 구조와 내용이 결정된다.

여기서, <지수코드>는 데이터헤더의 <MID 2>에 따른 코드체계가 적용된다. 즉 거래소업종지수일 때는 거래소업종코드가, 코스닥업종지수일 때는 코스닥 업종코드, 장지수일 때는 장코드가 적용된다.

또한, <현재지수>는 헥사값으로 전송되며, 단위는 0.01이고, <전일대비>는 최초 1비트는 +/-를 나타내고, 나머지 15 비트로 수를 표현한다. 전일대비가 양일 때 최초 1비트는 1, 음일 때 0이 전송된다. 단위는 0.01이다.

또한, <거래량>, <거래대금>, <상승종목수>, <하락종목수> 등의 정보를 더 포함하여 전송된다.

도 32n은 지수 데이터 패킷2(<Pac ID>=2)의 패킷 구조를 설명하기 위한 도면으로, <시가지수>,<고가지수>,<저가지수>를 포함하여 전송된다.

도 32o는 지수 데이터 패킷3(<Pac ID>=4)의 패킷 구조를 설명하기 위한 도면으로, 지수 데이터 패킷3은 증권 업종의 업데이트 정보를 전송한다. 만일 수신기가 업데이트 마스터 패킷을 수신한 후 업데이트 적용 대상일 경우 업종 데이터 패킷 4를 전송받아서, 업종 데이터베이스를 업데이트시킨다.

여기서, <업종코드>는 1 바이트이므로 상위 3 바이트는 무시되고, 하위 1바이트(Byte6)를 이용하여 전송되고, <Num>은 업데이트 마스터 패킷의 <NI>와 연관이 되어 업데이트 되는 종목의 순번을 나타낸다. 즉, <Num>은 1부터 시작하여, <NI>까지 전송되게 된다.

또한, <Ctrl>은 업데이트 데이터의 추가/삭제/갱신 등의 제어코드이고, <업종명>은 업데이트 데이터의 내용이 되며, 문자로 14 바이트가 할당된다.

이상에서는 증권 정보 메시지 어플리케이션에 대해서 설명하였다. 그러면, 부가정보의 부호화에 대해서 설명한다.

본 발명에 따른 부가정보는 계층 3에서 서비스 식별 번호 0Dh를 사용하며, 방송국명, 년/월/일/시/분/초, 방송국의 주파수 등을 수신기에 대한 제어를 목적으로 송출하고, 이때 송출하는 문자부호 체계는 KSC-5601에 따른다.

본 발명에 따른 부가정보 전송 프레임은 세그먼트 정보 단위로 구성된다. 데이터 그룹은 하나 또는 복수의 세그먼트 군으로 구성되어지며 이는 하나 또는 복수 개의 데이터블록(prefix를 제외한 20byte)으로 구성된다. 데이터 그룹의 구성은 첨부하는 도 33a와 같고, 아래와 같이 나타낼 수 있다.

----------------------------------------------------------------------

_{<transport_frame>:=}

_{<세그먼트 멀티플렉스>, // 세그먼트}

_{<길이조절용 NULL>,}

_<crc>;

----------------------------------------------------------------------

여기서, 데이터 그룹은 한 데이터 그룹마다 CRC(오류검출 부호)를 부가하여 송출한다. 데이터 그룹의 오류 검출용 CRC부호는 문자의 데이터 그룹 오류검출부호와 동일하다.

또한 CRC부호의 위치는 최종 데이터 그룹의 최종 16비트로 한다. 세그먼트의 길이는 가변이므로 데이터 그룹의 최종 세그먼트와 CRC부호화의 중간은 NUL로 채운다. CRC부호의 부호화 개시는 선두 세그먼트의 최초 비트로 하고, 종료는 16비트 CRC부호의 직전 비트까지로 한다.

한편, 한 개의 세그먼트는 도 33c에 도시한 바와 같이, 4비트의 세그먼트 식별 영역과, 4비트 또는 12비트의 세그먼트 길이 영역과, 세그먼트 데이터 영역으로 구성되고 아래와 같이 나타낼 수 있다.

----------------------------------------------------------------------

_{<세그먼트>:=}

_{<nibble>(id), // 세그먼트 식별}

_{<nibble>(length), // 세그먼트 길이}

_{if(length = 0Fh)}

_{<intunti>(length), // 확장 세그먼트 길이}

_{<세그먼트 데이터>;}

----------------------------------------------------------------------

여기서, 세그먼트 식별 영역은 첨부하는 도 33e에 도시한 바와 같이, 세그먼트 데이터의 내용을 규정하고, 세그먼트 길이 영역은 세그먼트 데이터의 길이를 규정한다.

또한, 세그먼트 길이 영역은 4비트로 되고 세그먼트 데이터의 바이트 수를 지정한다. 4비트의 세그먼트 길이에 지정할 수 있는 최대의 데이터 길이는 14바이트로 한다. 14바이트를 초과하는 세그먼트 데이터를 전송하는 경우는 세그먼트 길이를 15(Fh)로 하고, 이어서 1바이트의 확장 세그먼트 길이로 지정한다. 지정 가능한 최대 데이터 길이는 255바이트이다.

그러면, 상기한 세그먼트 데이터에 대해서 상세히 설명한다.

본 발명에 따르면, 각 세그먼트 별로 암호화를 하도록 하며, 암호화 된 세그먼트에 대한 식별 ID를 표시한다. 여기서, 세그먼트의 식별 ID가 4비트이므로 1바 이트에서 표시할 수 있는 암호화된 세그먼트 식별 ID는 2개이다. 세그먼트 데이터는 8비트의 정수배로 표현되어야 한다. 따라서 암호화된 세그먼트가 홀수개이면 마지막 <nibble>값은 0으로 한다.

----------------------------------------------------------------------

_{<세그먼트식별(00)>:= // 암호화 된 세그먼트 정보}

_{<nibble>(id), // 세그먼트 식별 (ID = 00h)}

_{<nibble>(n), // 세그먼트 길이}

_{(n/2+1)*<nibble>; // 암호화 된 세그먼트의 식별 ID}

----------------------------------------------------------------------

또한, 방송국 식별은 방송 프로그램을 식별하기 위하여 첨부하는 도 33e와 같이, 방송국의 식별을 표시한다. 8비트의 확장국 식별코드, 4비트의 국가 식별코드, 4비트의 가청지역 코드, 16비트의 방송사업자번호 인 총 32비트(4바이트)로 구성된다.

----------------------------------------------------------------------

_{<세그먼트식별(01)>:= // 방송국 식별}

_{<nibble>(id), // 세그먼트 식별(ID = 01h)}

_{<nibble>, // 세그먼트 길이}

_{<intunti>, // 확장국 식별코드}

_{<nibble>, // 국 식별코드}

_{<nibble>, // 가청지역코드}

_{<intunli>; // 예약영역}

----------------------------------------------------------------------

또한, 8비트로 방송 프로그램을 제공한 국의 확장코드를 이진값으로 대응하여 표시한다. 확장국 식별코드의 내용은 첨부하는 도 33f에 도시한다. 또한, 4비트로 되고, 방송 프로그램을 제공하는 나라를 이진값으로 대응하여 표시하는데, 그 내용은 첨부하는 도 33g에 도시한다. 국가 식별코드의 할당은 RDS와 동일하다. 또한, 가청지역 코드는 4비트로 구성되고, 방송 프로그램의 가청지역을 이진값으로 대응하여 표시하는데, 그 내용은 첨부하는 도 33h에 도시한다.

한편, 시각정보는 아래와 같이, 현재의 한국 표준시각을 송출한다. 보다 상세히는, 년도는 뒤의 세자리만을 표시하고, 0 ~ 255까지로 한다. 월은 1~12, 일은 1~31, 시간은 0~23, 분과 초는 0~59로 한다. 시각정보의 값이 FFh인 경우는 해당 정보를 전송하지 않는 것이다.

----------------------------------------------------------------------

_{<세그먼트식별(02)>:= // 현재 시각정보}

_{<nibble>(id), // 세그먼트 식별 (ID = 02h)}

_{<nibble>, // 세그먼트 길이}

_{<intunti>, // 년도 - 2000}

_{<intunti>, // 월 (1 ~ 12)}

_{<intunti>, // 일 (1 ~ 31)}

_{<intunti>, // 시 (0 ~ 23)}

_{<intunti>, // 분 (0 ~ 59)}

_{<intunti>; // 초 (0 ~ 59)}

----------------------------------------------------------------------

한편, 프로그램 개시 편성시간은 메인 음성 및 다중 음성 프로그램의 식별 정보이고, 프로그램의 개시시간을 첨부하는 도 33j와 같이 전송한다.

도 33j를 참조하면, 개시시간은 날짜, 시간, 분으로 구성되고, 동일 프로그램이 방송되는 시간은 동일 프로그램 개시 편성시간을 송출한다.

날짜는 5비트로 구성되고, 프로그램 방송 예정일을 이진값으로 표시한다. 0인 경우에는 방송국이 이 서비스를 행하지 않는 것을 표시한다. 시간은 5비트로 구성되고, 프로그램 개시시간을 이진값으로 표시한다. 분은 6비트로 구성되고 프로그램 개시분을 이진값으로 표시한다. 실제의 방송 개시시간이 예정보다 늦어진 경우에도 방송예정시간이 표시된다. 프로그램 개시 편성시간의 데이터가 2바이트인 경우는 메인 음성만, 4바이트인 경우는 메인 음성과 다중음성의 프로그램 개시 편성시간을 표시한다.

----------------------------------------------------------------------

_{<세그먼트식별(03)>:= // 프로그램개시 편성시간}

_{<nibble>(id), // 세그먼트 식별 (ID = 03h)}

_{<nibble>, // 세그먼트 길이}

_{5*<bit>, // 프로그램 개시일 (1 ~ 31)}

_{5*<bit>, // 프로그램 개시시 (0 ~ 23)}

_{6*<bit>; // 프로그램 개시분 (0 ~ 59)}

----------------------------------------------------------------------

한편, 교통 긴급정보 플래그는 첨부하는 도 33k와 같이, 메인 음성, 다중음성, 다중 데이터에 의한 교통정보 및 긴급정보의 제공식별 플래그로서, 아래와 같이 나타낼 수 있다.

----------------------------------------------------------------------

_{<세그먼트식별(04)>:= // 교통, 긴급 정보 플래그}

_{<nibble>(id), // 세그먼트 식별(ID = 04h)}

_{<nibble>, // 세그먼트 길이}

_{<bit>, // 미정의}

_{5*<bit>, // 교통정보 플래그}

_{2*<bit>; // 긴급정보 플래그}

----------------------------------------------------------------------

여기서, 교통정보 플래그는 5비트로 되고, 첨부하는 도 33l에 도시한 바와 같이, 교통정보를 제공하는 방송국 여부와 음성 프로그램 또는 데이터에 의하여 현재 실제로 방송중인가를 보여준다.

또한, 긴급정보 플래그는 2비트로 구성되고, 첨부하는 도 33m에 도시한 바와 같이, 음성프로그램에 의하여 긴급정보가 현재 실제로 방송중인가를 보여준다.

한편, 프로그램 정보는 음악/음성 플래그, 카테고리, 복호식별의 2바이트로 구성되고, 현재 방송중인 메인 음성 또는 다중 음성 프로그램의 내용 및 송신상태를 보여준다. 프로그램 정보의 데이터가 2바이트인 경우는 메인 음성만, 4바이트인 경우는 메인 음성과 다중 음성의 프로그램 정보를 보여준다.

----------------------------------------------------------------------

_{<세그먼트식별(05)>:= // 프로그램정보}

_{<nibble>(id), // 세그먼트 식별 (ID = 05h)}

_{<nibble>, // 세그먼트 길이}

_{2*<bit>, // 미정의}

_{<bit>, // 음악/음성 플래그 (현재 음악 방송 중 : 1)}

_{5*<bit>, // 카테고리}

_{<nibble>, // 미정의}

_{<nibble>; // 복호정보 (예약)}

----------------------------------------------------------------------

또한, 음악/음성 플래그는 1비트이고, 메인 음성 또는 다중음성프로그램이 음악인지 음성인지를 나타낸다. 방송국이 이 서비스를 행하지 않을 경우 '1'로 설정한다.

또한, 카테고리는 5비트로 구성되고 카테고리의 내용은 첨부하는 도 33p에 도시한다.

또한, 복호정보는 4비트로 되고, 메인 음성 또는 다중음성프로그램의 방송상태를 이진 대응하여 나타낸다. 복호정보는 RDS와 동일하다.

한편, 기간방송국명은 1바이트로 나타내는 기간방송국 주파수와 함께 전송하는데, 문자의 수는 1바이트 문자로 24문자 이내로 한다. FM방송국의 주파수 부호할당은 84.4㎒를 0부터 하여 100㎑ 마다 1씩 증가시켜 도 33q와 같이 나타낸다.

----------------------------------------------------------------------

_{<세그먼트식별(06)>:= // 기간방송국명}

_{<nibble>(id), // 세그먼트 식별 (ID = 06h)}

_{<nibble>(length), // 세그먼트 길이}

_{if(length = 0Fh)}

_{<intunti>(length), // 확장 세그먼트 길이}

_{<intunti>, // 기간 방송국 주파수}

_{n*<intunti>; // 기간 방송국명}

----------------------------------------------------------------------

중계방송국명(FM국)의 문자 수는 1바이트 문자 12문자 이내로 한다.

----------------------------------------------------------------------

_{<세그먼트식별(08)>:= // 중계방송국명}

_{<nibble>(id), // 세그먼트 식별(ID = 08h)}

_{<nibble>, // 세그먼트 길이}

_{<intunti>, // 중계방송국 주파수}

_{n*<intunti>; // 중계방송국명}

----------------------------------------------------------------------

한편, 대체 주파수 리스트, 현재방송중인 방송국과 동일 네트워크에 접속된 인접하는 방송국의 대체 주파수 리스트를 제공한다. 1개의 주파수는 8비트로 전송하고 1개의 방송국(기준 방송국) 주파수에 대하여 그 방송국의 대체 주파수를 나열한다. 각 기간 및 중계방송국마다 1개의 세그먼트로 대체주파수를 송출한다.

----------------------------------------------------------------------

_{<세그먼트식별(0A)>:= // 대체주파수}

_{<nibble>(id), // 세그먼트 식별 (ID = 0Ah)}

_{<nibble>(length), // 세그먼트 길이}

_{if(length = 0Fh)}

_{<intunti>(length), // 확장 세그먼트 길이}

_{<intunti>, // 기준방송국 주파수}

_{(length 1)*<intunti>; // 대체주파수}

----------------------------------------------------------------------

카테고리명의 재정의는 기본값으로 정해진 카테고리명을 재정의할 때 5비트 카테고리 부호와 재정의된 카테고리명을 전송한다. 카테고리부호는 프로그램 정보 중 카테고리와 같은 것으로 카테고리명의 문자 최대수는 255문자로 한다.

----------------------------------------------------------------------

_{<세그먼트식별(0C)>:= // 카테고리명의 재정의}

_{<nibble>(id), // 세그먼트 식별 (ID = 0Ch)}

_{<nibble>(length), // 세그먼트 길이}

_{if(length = 0Fh)}

_{<intunti>(length), // 확장 세그먼트 길이}

_{3*<bit>, // 미정의}

_{5*<bit>, // 카테고리 부호}

_{n*<intunti>; // 카테고리명}

----------------------------------------------------------------------

특정 수신기의 제어를 위해 제어신호를 전송한다. 각 제어신호의 ID에 따라 사이즈 및 제어신호의 내용이 달라진다.

----------------------------------------------------------------------

_{<세그먼트식별(0E)>:= // 제어신호}

_{<nibble>(id), // 세그먼트 식별 (ID = 0Eh)}

_{<nibble>(length), // 세그먼트 길이}

_{if(length = 0Fh)}

_{<intunti>(length), // 확장 세그먼트 길이}

_{<제어신호 멀티플렉스>; // 제어신호 멀티플렉스}

----------------------------------------------------------------------

----------------------------------------------------------------------

_{<제어신호>:= // 제어신호}

_{<nibble>(id), // 제어신호 ID}

_{<nibble>(n), // 해당 제어신호의 사이즈}

_{n*<intunti>; // 해당 제어신호 내용}

----------------------------------------------------------------------

상기에서는 본 발명의 바람직한 실시예를 참조하여 설명하였지만, 해당 기술 분야의 숙련된 당업자는 하기의 특허청구범위에 기재된 본 발명의 사상 및 영역으로부터 벗어나지 않는 범위 내에서 본 발명을 다양하게 수정 및 변경시킬 수 있음을 이해할 수 있을 것이다.

이상 설명한 바와 같이, 본 발명에 따르면, FM DARC 프로토콜에서 패킷의 최선두에 위치하는 프리픽스를 활용하여 어플리케이션을 구별할 수 있고, 데이터 그룹핑을 수행할 수 있다. 즉, 복호 식별자를 사용하여 프레임 및 패킷의 전송을 구분하여 수행할 수 있고, 서비스 아이디 식별자를 사용하여 응용 서비스를 구분하여 전송할 수 있다. 또한 데이터 그룹 번호를 사용하여 응용 서비스의 데이터 그룹핑을 수행할 수 있고, 정보 종료 식별자를 사용하여 그룹핑된 데이터의 끝을 식별할 수 있다.

또한, 본 발명에 따르면 계층적으로 데이터 규격을 정의할 수 있을 뿐만 아니라, 데이터 구조의 규격 정의를 유연하게 수행할 수 있고, 기본적 데이터 타입 정의에 의해 사용의 편의성을 향상시킬 수 있다.

또한, 본 발명에 따르면 반복되는 마스터성 정보의 송출을 줄임으로써 전송 효율성을 증대시킬 수 있고, 수신기에 의한 데이터 관리를 기능하게 할 뿐만 아니라, 수신 성능을 향상시킬 수 있다.

또한, 본 발명에 따르면 정보 제공자의 구조와 할당 방법을 통해 특정 서비스에 대한 정보 제공자의 정보를 전송할 수 있고, 동일 혹은 관련 서비스로의 링크를 수행할 수 있다.

또한, 본 발명에 따르면 특정 서비스의 시작 시간과 반복 주기 그리고 기간 등을 지정할 수 있는 데이터 구조에 의해 서비스의 전송 시간이나 반복 주기와 관련된 스케줄 정보를 제공할 수 있고, 수신기의 정보 수신 성능을 향상시킬 수 있다.

또한 본 발명에 따르면 동일 또는 관련 정보 제공원의 튜닝 파라미터를 제공할 수 있어, 동일 및 관련 서비스의 인접 지역 방송과의 연계를 가능하게 하고, 동일 및 관련 서비스의 타 방송과의 연계까지도 가능하다.

Claims (6)

1. FM 대역을 이용하여 데이터를 전송하는 FM 부가방송 전송 장치에 있어서,

   어플리케이션 데이터를 생성하는 어플리케이션 계층부;

   상기 어플리케이션 데이터가 속하는 어플리케이션의 식별자를 포함하는 프리픽스 및 상기 어플리케이션 데이터를 포함하는 데이터 패킷을 생성하는 네트워크 계층부;

   동기 신호에 해당하는 블록 식별 코드, 상기 데이터 패킷, 에러 검출 정보 및 에러 정정 정보를 포함하는 프레임을 생성하는 데이터 링크 계층부;

   상기 프레임을 변조하여 변조된 신호를 방송하는 물리 계층부를 포함하고,

   상기 어플리케이션의 식별자는 상기 어플리케이션이 패킷 어플리케이션인지 프레임 어플리케이션인지의 여부에 대한 정보인 복호 식별 정보를 포함하는 FM 부가방송 전송 장치.
2. 제1항에 있어서,

   상기 네트워크 계층부는 상기 복호 식별 정보가 상기 프레임 어플리케이션을 나타내는 경우 상기 어플리케이션 데이터를 가지고 복수의 데이터 패킷을 생성하고,

   상기 각각의 데이터 패킷은 패킷의 순서를 나타내는 패킷 카운트를 포함하고,

   상기 복수의 데이터 패킷의 마지막 데이터 패킷은 길이 조정용 NULL 정보와 에러 검출 정보를 포함하는 FM 부가방송 전송 장치.
3. 제2항에 있어서,

   상기 프리픽스는

   상기 복호 식별 정보가 상기 패킷 어플리케이션을 나타내는 경우 데이터 패킷 단위로 증가하고, 상기 복호 식별 정보가 상기 프레임 어플리케이션을 나타내는 경우 프레임 단위로 증가하는 데이터 그룹 번호와,

   데이터 그룹이 상기 데이터 그룹 번호에서 종료하는 지 여부를 나타내는 정보 종료 정보를 더 포함하는 FM 부가방송 전송 장치.
4. FM 대역을 이용하여 데이터를 전송하는 FM 부가방송 전송 방법에 있어서,

   어플리케이션 데이터를 생성하는 단계;

   상기 어플리케이션 데이터가 속하는 어플리케이션의 식별자를 포함하는 프리픽스 및 상기 어플리케이션 데이터를 포함하는 데이터 패킷을 생성하는 단계;

   동기 신호에 해당하는 블록 식별 코드, 상기 데이터 패킷, 에러 검출 정보 및 에러 정정 정보를 포함하는 프레임을 생성하는 단계; 및

   상기 프레임을 변조하여 변조된 신호를 방송하는 단계를 포함하고,

   상기 어플리케이션의 식별자는 상기 어플리케이션이 패킷 어플리케이션인지 프레임 어플리케이션인지의 여부에 대한 정보인 복호 식별 정보를 포함하는 FM 부가방송 전송 방법.
5. 제4항에 있어서,

   상기 복호 식별 정보가 상기 프레임 어플리케이션을 나타내는 경우 상기 어플리케이션 데이터를 가지고 복수의 데이터 패킷을 생성하는 단계를 더 포함하고,

   상기 복수의 데이터 패킷의 각각은 패킷의 순서를 나타내는 패킷 카운트를 포함하고,

   상기 복수의 데이터 패킷의 마지막 데이터 패킷은 길이 조정용 NULL 정보와 에러 검출 정보를 포함하는 FM 부가방송 전송 방법.
6. 제5항에 있어서,

   상기 프리픽스는

   상기 복호 식별 정보가 상기 패킷 어플리케이션을 나타내는 경우 데이터 패킷 단위로 증가하고, 상기 복호 식별 정보가 상기 프레임 어플리케이션을 나타내는 경우 프레임 단위로 증가하는 데이터 그룹 번호와,

   데이터 그룹이 상기 데이터 그룹 번호에서 종료하는 지 여부를 나타내는 정보 종료 정보를 더 포함하는 FM 부가방송 전송 방법.

Images