KR20100097690A

KR20100097690A - 통신 장치, 통신 시스템, 통신 방법 및 프로그램

Info

Publication number: KR20100097690A
Application number: KR1020107012933A
Authority: KR
Inventors: 히로유끼 후지나가
Original assignee: 소니 주식회사
Priority date: 2007-12-28
Filing date: 2008-12-22
Publication date: 2010-09-03
Also published as: US20100260202A1; EP2226728A1; WO2009084506A1; JP2009163361A; EP2226728A4; TW201002014A; CN101896893A

Abstract

본 발명의 과제는 상위 애플리케이션이 하나 또는 복수의 프로토콜을 구비하는 경우에, 통신의 호환성을 확실하게 확보하는 것이 가능한 통신 장치를 제공하는 것이다. 무선 통신에 의해 다른 통신 상대와의 사이에 신호의 송수신을 행하는 물리층(108)과, 상위의 유저 애플리케이션(100)과 물리층(108)과의 사이를 접속하는 프로토콜 변환부(PCL)(102)를 구비하고, 프로토콜 변환부(102)는 서로 통신 가능한 각 장치에 공통으로 설치되고, 프로토콜 변환을 위한 기본 처리를 행하는 PCL 코먼(102a)과, 유저 애플리케이션(102)의 하나 또는 복수의 프로토콜에 대응하여 설치되고, PCL 코먼(102a)에 의해 하나 또는 복수의 프로토콜 중에서 선택된 프로토콜을 물리층(108)에서 통신하기 위한 프로토콜로 변환하는 변환 처리부를 포함한다.

Description

통신 장치, 통신 시스템, 통신 방법 및 프로그램{COMMUNICATION DEVICE, COMMUNICATION SYSTEM, COMMUNICATION METHOD, AND PROGRAM}

본 발명은 통신 장치, 통신 시스템, 통신 방법 및 프로그램에 관한 것이다.

종래, 예를 들어 하기의 특허문헌 1에 기재되어 있는 바와 같이, 이동체의 이용자가 소유하는 범용의 휴대 단말기에 이동체의 정보를 발신할 수 있는 것을 의도한 이동체 통신 시스템이 알려져 있다.

일본 특허 공개 제2005-191819호 공보

최근에는, 통신 장치에 복수의 상위 애플리케이션이 탑재되는 것이 상정되고 있다. 이러한 장치에 있어서는, 상위 애플리케이션의 프로토콜이 복수로 되는 것이 상정된다.

그러나, 상위 애플리케이션의 프로토콜이 복수가 되면, 어느 프로토콜을 사용하여 통신을 실현할지가 문제가 되고, 사용하는 프로토콜에 따라서는, 통신 상대와의 접속 시에 호환성이 없어지는 사태가 상정된다. 이 경우, 통신 장치측에서 복수 애플리케이션에 의한 다기능을 실현하였다고 해도, 다른 장치와의 사이에서 통신의 호환성을 얻을 수 없게 되어, 결과적으로 시스템상의 제약이 발생하게 된다.

따라서, 본 발명은, 상기 문제를 감안하여 이루어진 것이며, 본 발명이 목적으로 하는 바는, 상위 애플리케이션이 하나 또는 복수의 프로토콜을 구비하는 경우에, 통신의 호환성을 확실하게 확보하는 것이 가능한, 신규이며 또한 개량된 통신 장치, 통신 시스템, 통신 방법 및 프로그램을 제공하는 것에 있다.

상기 과제를 해결하기 위해, 본 발명의 관점에 따르면, 다른 통신 상대와의 사이에서 신호의 송수신을 행하는 물리층과, 상위 애플리케이션과 상기 물리층 사이를 접속하는 프로토콜 변환부를 구비하고, 상기 프로토콜 변환부는, 서로 통신 가능한 각 장치에 공통으로 설치되고, 프로토콜 변환을 위한 기본 처리를 행하는 공통 처리부와, 상기 상위 애플리케이션의 하나 또는 복수의 프로토콜에 대응하여 설치되고, 상기 공통 처리부에 의해 상기 하나 또는 복수의 프로토콜 중에서 선택된 프로토콜을 상기 물리층에서 통신하기 위한 프로토콜로 변환하는 변환 처리부를 포함하는 통신 장치가 제공된다.

상기 구성에 따르면, 물리층에 의해 다른 통신 상대와의 사이에서 신호의 송수신이 행해지고, 프로토콜 변환부에 의해 상위 애플리케이션과 물리층 사이가 접속된다. 프로토콜 변환부의 공통 처리부는 서로 통신 가능한 각 장치에 공통으로 설치되고, 공통 처리부에 의해 프로토콜 변환을 위한 기본 처리가 행해진다. 프로토콜 변환부의 변환 처리부는 상위 애플리케이션의 하나 또는 복수의 프로토콜에 대응하여 설치된다. 그리고, 공통 처리부에 의해 하나 또는 복수의 프로토콜 중에서 선택된 프로토콜은 변환 처리부에 의해 물리층에서 통신하기 위한 프로토콜로 변환된다. 따라서, 서로 통신 가능한 각 장치에 공통으로 설치된 공통 처리부에 의해, 하나 또는 복수의 프로토콜 중에서 프로토콜이 선택되므로, 통신에 최적인 프로토콜을 선택하는 것이 가능해져, 통신의 호환성을 확보할 수 있다.

또한, 상기 공통 처리부는 적어도 상기 프로토콜 변환의 기동, 정지를 포함하는 기본 동작을 행하는 것이어도 된다. 이러한 구성에 따르면, 서로 통신 가능한 각 장치에 공통으로 설치된 공통 처리부에 의해 프로토콜 변환의 기동, 정지를 포함하는 기본 동작을 실현할 수 있다.

또한, 상기 공통 처리부는 상기 통신 상대와의 니고시에이션의 결과에 따라서, 상기 하나 또는 복수의 프로토콜 중에서 상기 통신 상대가 구비하는 상위 애플리케이션의 프로토콜과 일치하는 프로토콜을 선택하는 것이어도 된다. 이러한 구성에 따르면, 통신 상대와의 니고시에이션의 결과에 따라서, 하나 또는 복수의 프로토콜 중에서 통신 상대가 구비하는 상위 애플리케이션의 프로토콜과 일치하는 프로토콜이 선택되므로, 통신 상대와의 호환성을 확보하여, 통신 상대와의 통신을 확실하게 행할 수 있다.

또한, 상기 공통 처리부는 상기 하나 또는 복수의 프로토콜 중에, 상기 통신 상대가 구비하는 상위 애플리케이션의 프로토콜과 일치하는 프로토콜이 존재하지 않은 경우에는, 상기 통신 상대와의 접속을 행하지 않는 것이어도 된다. 이러한 구성에 따르면, 하나 또는 복수의 프로토콜 중에, 통신 상대가 구비하는 상위 애플리케이션의 프로토콜과 일치하는 프로토콜이 존재하지 않은 경우에는, 상기 통신 상대와의 접속을 행하지 않으므로, 불필요한 처리가 행해지는 것을 억제할 수 있다.

또한, 상기 공통 처리부는 통신 상대와의 니고시에이션의 결과에 따라서, 상기 프로토콜 변환부의 소프트웨어의 버전이 통신 상대가 구비하는 프로토콜 변환부의 소프트웨어의 버전과 일치하는지 여부를 판정하는 버전 체크 기능을 구비하는 것이어도 된다. 이러한 구성에 따르면, 통신 상대와의 니고시에이션의 결과에 따라서, 프로토콜 변환부의 소프트웨어의 버전이, 통신 상대가 구비하는 프로토콜 변환부의 소프트웨어의 버전과 일치하는지 여부가 판정되므로, 통신 상대와의 호환성을 확보하여, 통신 상대와의 통신을 확실하게 행할 수 있다.

또한, 상기 공통 처리부는 상기 프로토콜 변환부의 소프트웨어의 버전이 통신 상대가 구비하는 프로토콜 변환부의 소프트웨어의 버전과 일치하지 않은 경우에는, 상기 통신 상대와의 접속을 행하지 않는 것이어도 된다. 이러한 구성에 따르면, 프로토콜 변환부의 소프트웨어의 버전이 통신 상대가 구비하는 프로토콜 변환부의 소프트웨어의 버전과 일치하지 않은 경우에는, 상기 통신 상대와의 접속을 행하지 않으므로, 불필요한 처리가 행해지는 것을 억제할 수 있다.

또한, 상기 물리층은 상기 변환 처리부에서 프로토콜이 변환된 데이터에 대하여 데이터의 종별을 나타내는 프로파일 ID가 부여된 데이터를 통신 상대와의 사이에서 통신하는 것이어도 된다. 이러한 구성에 따르면, 복수의 논리 채널을 1개의 물리층 상에서 실현하는 것이 가능해진다.

또한, 상기 과제를 해결하기 위해, 본 발명의 다른 관점에 따르면, 통신 장치끼리가 통신을 행하는 통신 시스템이며, 상기 통신 장치는, 통신 상대가 되는 통신 장치의 사이에서 신호의 송수신을 행하는 물리층과, 상위 애플리케이션과 상기 물리층의 사이를 접속하는 프로토콜 변환부를 구비하고, 상기 프로토콜 변환부는, 서로 통신 가능한 각 통신 장치에 공통으로 설치되고, 프로토콜 변환을 위한 기본 처리를 행하는 공통 처리부와, 상기 상위 애플리케이션의 하나 또는 복수의 프로토콜에 대응하여 설치되고, 상기 공통 처리부에 의해 상기 하나 또는 복수의 프로토콜 중에서 선택된 프로토콜을 상기 물리층에서 통신하기 위한 프로토콜로 변환하는 변환 처리부를 포함하는 통신 시스템이 제공된다.

상기 구성에 따르면, 통신 장치끼리가 통신을 행하는 통신 시스템에 있어서, 물리층에 의해 통신 상대가 되는 통신 장치의 사이에서 신호의 송수신이 행해지고, 프로토콜 변환부에 의해 상위 애플리케이션과 물리층의 사이가 접속된다. 프로토콜 변환부의 공통 처리부는, 서로 통신 가능한 각 장치에 공통으로 설치되고, 공통 처리부에 의해 프로토콜 변환을 위한 기본 처리가 행해진다. 프로토콜 변환부의 변환 처리부는, 상위 애플리케이션의 하나 또는 복수의 프로토콜에 대응하여 설치된다. 그리고, 공통 처리부에 의해 하나 또는 복수의 프로토콜 중에서 선택된 프로토콜은 변환 처리부에 의해 물리층에서 통신하기 위한 프로토콜로 변환된다. 따라서, 서로 통신 가능한 각 장치에 공통으로 설치된 공통 처리부에 의해, 하나 또는 복수의 프로토콜 중에서 프로토콜이 선택되므로, 통신에 최적인 프로토콜을 선택하는 것이 가능해져, 통신의 호환성을 확보할 수 있다.

또한, 상기 과제를 해결하기 위해, 본 발명의 다른 관점에 따르면, 통신 장치끼리가 통신을 행하는 통신 방법이며, 상기 통신 장치가 통신 상대가 되는 다른 통신 장치와의 사이에서 프로토콜 정보를 교환하는 스텝과, 상기 프로토콜 정보에 기초하여, 상위 애플리케이션의 하나 또는 복수의 프로토콜 중에서, 통신 상대가 구비하는 상위 애플리케이션의 프로토콜과 일치하는 프로토콜을 선택하는 스텝과, 선택된 프로토콜을 통신 상대와 통신하기 위한 프로토콜로 변환하는 스텝을 구비하는 통신 방법이 제공된다.

상기 구성에 따르면, 통신 장치끼리가 통신을 행하는 통신 방법에 있어서, 통신 상대가 되는 다른 통신 장치와의 사이에서 프로토콜 정보가 교환되고, 프로토콜 정보에 기초하여, 상위 애플리케이션의 하나 또는 복수의 프로토콜 중에서, 통신 상대가 구비하는 상위 애플리케이션의 프로토콜과 일치하는 프로토콜이 선택되고, 선택된 프로토콜이 통신 상대와 통신하기 위한 프로토콜로 변환된다. 따라서, 통신 상대와의 사이에서 교환된 프로토콜 정보에 기초하여, 통신에 최적인 프로토콜을 선택하는 것이 가능해져, 통신의 호환성을 확보할 수 있다.

또한, 상기 과제를 해결하기 위해, 본 발명의 다른 관점에 따르면, 통신 상대가 되는 다른 통신 장치와의 사이에서 프로토콜 정보를 교환하는 수단, 상기 프로토콜 정보에 기초하여, 상위 애플리케이션의 하나 또는 복수의 프로토콜 중에서, 통신 상대가 구비하는 상위 애플리케이션의 프로토콜과 일치하는 프로토콜을 선택하는 수단, 선택된 프로토콜을 통신 상대와 통신하기 위한 프로토콜로 변환하는 수단으로서 컴퓨터를 기능시키기 위한 프로그램이 제공된다.

상기 구성에 따르면, 통신 상대가 되는 다른 통신 장치와의 사이에서 프로토콜 정보가 교환되고, 프로토콜 정보에 기초하여, 상위 애플리케이션의 하나 또는 복수의 프로토콜 중에서, 통신 상대가 구비하는 상위 애플리케이션의 프로토콜과 일치하는 프로토콜이 선택되고, 선택된 프로토콜이 통신 상대와 통신하기 위한 프로토콜로 변환된다. 따라서, 통신 상대와의 사이에서 교환된 프로토콜 정보에 기초하여, 통신에 최적인 프로토콜을 선택하는 것이 가능해져, 통신의 호환성을 확보할 수 있다.

본 발명에 따르면, 상위 애플리케이션이 하나 또는 복수의 프로토콜을 구비하는 경우에, 통신의 호환성을 확실하게 확보하는 것이 가능해진다.

도 1은 본 실시 형태의 무선 통신 시스템을 구성하는 2개의 기기를 도시하는 모식도이다.
도 2는 이니시에이터, 리스폰더의 각 기기의 구성을 계층 구조로서 도시한 모식도이다.
도 3은 이니시에이터, 리스폰더에 있어서의 데이터의 흐름을 나타내는 모식도이다.
도 4는 도 2의 구성을 OSI 참조 모델로 나타낸 모식도이다.
도 5는 기기 내의 각 레이어에 있어서의 파일, 데이터의 송수신 데이터 플로우를 도시하는 모식도이다.
도 6은 CSDU에 의한 논리적인 채널을 도시하는 모식도이다.
도 7은 CSDU가 맵핑되는 모습을 도시하는 모식도이다.
도 8은 기기의 하드웨어 구성을 도시하는 모식도이다.
도 9는 각 레이어가 제공하는 서비스의 엑세스 포인트와, 레이어간의 관계를 나타내는 모식도이다.
도 10은 본 실시 형태의 시스템에 있어서의 상태 천이를 도시하는 모식도이다.
도 11은 니고시에이션의 처리를 도시하는 모식도이다.
도 12는 PCL 버전 정보를 설명하기 위한 모식도이다.
도 13은 에뮬레이션 선택의 시퀀스를 나타내는 모식도이다.
도 14는 PCL 에뮬레이션의 서비스를 나타내는 모식도이다.
도 15는 PCL 에뮬레이션의 서비스를 나타내는 모식도이다.

이하에 첨부 도면을 참조하면서, 본 발명의 적합한 실시 형태에 대하여 상세하게 설명한다. 또한, 본 명세서 및 도면에 있어서, 실질적으로 동일한 기능 구성을 갖는 구성 요소에 대해서는, 동일 부호를 부여함으로써 중복 설명을 생략한다.

본 실시 형태의 무선 통신 시스템은, 한 쌍의 기기의 사이에서 데이터를 송수신하는 것을 목적으로 한 통신 방식이며, 근거리의 기기간에 무선에 의해 데이터의 송수신을 행한다. 도 1은, 본 실시 형태의 무선 통신 시스템을 구성하는 2개의 기기(통신 장치)를 도시하는 모식도이다. 2개의 기기는, 각각 리스폰더(Responder)와 이니시에이터(Initiator)의 역할을 갖는다. 이니시에이터는「접속 요구를 하는 측」이고, 리스폰더는「접속 요구를 받는 측」이며, 본 실시 형태에서는 일대일(P2P)의 통신이 행해진다. 접속 시, 이니시에이터는 접속 요구를 하고, 리스폰더는 대기 상태로 되지만, 양자는 접속 시의 역할이 상이할 뿐으로, 접속에 관계되는 기기의 구성은 동일하다. 이니시에이터로서는 예를 들어 휴대 기기, 전자 카드 등이 해당하고, 리스폰더로서는 퍼스널 컴퓨터, 휴대 기기, 전자 카드 등의 기기가 해당한다.

도 1에서는, 본 실시 형태의 각 기기의 각각이 구비하는 물리층을 통하여 무선 통신이 행해지는 모습을 모식적으로 도시하고 있다. 본 실시 형태에서는, 물리층으로서 JET 물리층이라 칭해지는 것을 예시하지만, 물리층은 이에 한정되는 것은 아니며, 통신용의 범용적인 물리층에 적용할 수 있다. JET 물리층은 후술하는 프로파일 ID, CSDU 등을 사용함으로써 사진, 동화상 등의 대용량의 데이터 통신에 특히 적합한 것이다. 또한, 본 명세서에 있어서, 이니시에이터, 리스폰더의 양쪽의 기기를 총칭하여 JET 디바이스(또는 간단히 JET)라고 칭하는 경우가 있다.

도 2는, 본 실시 형태에 관한 무선 통신 시스템에 있어서, 이니시에이터, 리스폰더의 각 기기의 구성을 계층 구조로서 나타낸 모식도이다. 도 2에 도시한 바와 같이, 본 실시 형태에서는, 상층으로부터 순서대로 유저 애플리케이션(User Application)(100), PCL(Protocol Conversion Layer)(102), DTL(Data Transfer Layer)(104), CNL(Connection Layer)(106), 물리층(Physical Layer)(108)이 구성되어 있다.

유저 애플리케이션(100)은, 본 실시 형태에 의한 근거리 무선 통신이 가능한 물리층(108)을 탑재하는 기기에 있어서, 물리층(108)의 상층의 소프트웨어가 제공하는 서비스를 이용하여, 데이터 통신을 행하기 위한 상위 프로토콜(예를 들어 USB, TCP/IP, OBEX 등)이나, UI(User Interface) 등의 JET를 포함한 기기 조작을 행하는 애플리케이션[예를 들어 윈도우즈(등록 상표)(Windows; 등록 상표), 리눅스(Linux) 등의 OS]이 해당한다. JET device에서는, 이들 상위 프로토콜 또는 유저 애플리케이션에 대해서는 특별히 규정되는 것은 아니고, 기기를 구성하는 유저(메이커)가 자유롭게 설정할 수 있다. 따라서, 각 기기는 복수의 상위 프로토콜 또는 유저 애플리케이션(100)을 구비하고 있어도 된다.

PCL(102)(프로토콜 변환부)은 기기를 구성하는 유저가 사용하는 임의의 프로토콜(USB, OBEX 등)을 JET 독자의 프로토콜로 상호 변환하는, 프로토콜 변환(Protocol Conversion) 기능을 서포트한다. 이에 의해, 복수의 종류의 프로토콜을 JET의 물리층(PHY Layer)(108)에 흐르게 함으로써, 다양한 프로토콜을 서포트하는 것이 가능하다. 또한, 동일한 USB라도, Windows(등록 상표), Linux 등의 OS의 차이에 의해 프로토콜 변환이 다른 경우가 있다. PCL(102)은 상위의 유저 애플리케이션(100)이 생성하는 음성, 영상 등의 콘텐츠 데이터, 그 밖의 프로토콜의 데이터, 커맨드 등을 하위의 DTL(104)이 취급하는 것이 가능한 데이터 형식으로 변환하는 처리를 행한다. 또한, PCL(102)은 접속, 절단, 기기 인증, 동작 모드 설정, 초기화 등의 JET의 통신에 필요한 처리를 행한다.

도 3은 이니시에이터, 리스폰더에 있어서의 데이터의 흐름을 나타내는 모식도이다. 도 3에 도시한 바와 같이, 유저 애플리케이션(100)은 JET에 의한 접속과, 데이터 전송의 2종류의 제어를 행하게 된다. JET로서는 최상위 PCL(102)에서 이들의 기능을 실현하기 위해 필요한 서비스를 제공하고, JET 독자의 프로토콜로의 변환과, 접속 관리를 행한다. 또한 JET 규격에 준거한 CSDU(CNL service data unit)를 생성하는 DTL(104), CNL(106)로의 전달을 행한다.

DTL(104)은 상위의 PCL(102)로부터 수취한 데이터를, 소정의 패킷 구조로 정형하고, 하위의 CNL(106)이 제공하는 서비스를 사용하여, 이니시에이터, 리스폰더간의 송신을 행한다. 또한, 수신에 있어서는, CNL(106)이 수신한 데이터를 해석하고, CSDU를 추출하여, 그 유료 하중을 상위의 PCL(102)에 넘겨준다. CSDU에는, 물리층(PHY Layer)(108)에 의한 통신 이외의 유저 애플리케이션(100)에서 이용 가능한 스테이터스 정보도 포함되어 있고, DTL(104)은 이들 생성 처리, 에러 통지 등도 행한다.

DTL(104)은 상위 프로토콜의 종별에 관계없이, 상위로부터 입력된 데이터를 DTL 패킷으로 정형하여 하위의 CNL(106)에 걸쳐서, 하위로부터의 수신 데이터로부터 DTL 패킷을 추출하여, 상위에 DTL 패킷 유료 하중을 전달하는 것이 가능하다. 단, DTL(104) 자체는 PCL(102)로부터의 다른 프로토콜로부터 보내져 오는 데이터를 받아들이는 것이 가능하지만, JET에서는 다른 프로토콜의 데이터의 송수신은 한번 세션의 절단을 필요로 하기 때문에, 복수 프로토콜에서의 DTL 서비스의 이용은 행하지 않는다.

이 제한에 의해, 후술하는 복수의 PCL 에뮬레이션으로부터 DTL(104)에 데이터의 입력이 행해졌다고 해도, DTL(104)은 그 데이터의 Mux를 행하는 일은 없다. 또한, CNL(106)로부터의 수신 데이터에 복수의 프로토콜이 포함되어 있었던 경우라도, 그 프로토콜의 해석, 각각의 프로토콜 내용에 맞춘 PCL(102)에의 배신(配信) 또는 에러 검지에 의한 세션의 절단 등의 처리는 행하지 않는다.

이로 인해, DTL(104)에 의한 서비스를 이용하는 PCL(102)측에서는, 반드시 이용하는 프로토콜을 1종류로 확정한 상태에서 DTL(104)에 의한 서비스를 이용할 필요가 있다. 이들의 프로토콜 방식을 확정시키기 위한 판단과, 필요한 송수신을 행하는 것은 후술하는 PCL 코먼의 역할이며, 프로토콜 데이터의 생성, 파스는 PCL 에뮬레이션이 행한다. 복수의 프로토콜로부터 동시에 DTL 서비스를 이용할 수 없도록 배타 처리도 PCL 코먼의 역할이다.

DTL(104)은 PCL 코먼이 접속을 확립하는데 필요한 서비스, 접속 확립 후에 PCL 에뮬레이션이 데이터의 송수신을 행하기 위해 필요한 서비스를 제공한다.

또한, DTL(104)은 현재 실행되고 있는 서비스가 전체 전송 크기의 도중 데이터인지, 마지막 데이터인지, 혹은 데이터가 아닌 파라미터인지를 나타내는 프로파일 ID(Profile ID), 크기를 PCL(102)로부터 파라미터로서 수취하고, 하위의 CNL 서비스를 이용하여 생성하는 CSDU 패킷 헤더에 삽입한다. DTL(104)은 송신 파라미터를 JET가 데이터를 송신할 때에 생성하는 CSDU 패킷의 일부에 매립함으로써 도 6과 같은 복수의 논리 채널(Channel)을 1개의 물리층(PHY Layer)(108) 상에서 실현한다.

DTL(104)은 JET 규격으로 정의되어 있는 CSDU 패킷을 생성하는 기능을 갖는다. DTL(104)에서는, CSDU 패킷의 종별을 이해하기 위한 파라미터를 CSDU 패킷 헤더에 부가한다. 부가하는 것은 Profile ID, Size, Data Payload이다.

DTL(104)은 CNL(106)이 제공하는 CSDU의 단위로 데이터 전송을 행한다. DTL(104)은 CSDU 송신 시에 이하의 3종류의 프로파일 ID(T_DATA, LT_DATA, CNL_DATA)를 CSDU에 대하여 부여한다. 또한, CSDU 수신 시에는, 프로파일 ID의 종류에 따른 처리를 행한다.

T_DATA, LT_DATA

DTL(104)은 유저 데이터를 전송하는 CSDU에 대하여 T_DATA를 부여한다. 단, CSDU 유료 하중에의 분할에 있어서, 최종의 CSDU가 되는 경우에는 LT_DATA를 부여한다. CSDU의 유료 하중에는 유저 데이터만이 저장되고, DTL(104)이 헤더 정보 등을 매립하는 일은 없다.

CNL_DATA

DTL(104)은 JET 시스템 고유의 제어 데이터를 전송하는 CSDU에 대하여, CNL_DATA를 부여한다. 제어 데이터의 예로서는, 파라미터 정보(상세한 것은 TBD) 등이 있다. CSDU 유료 하중에는 헤더 정보(상세한 것은 TBD)가 매립된다. DTL(104)은 이 헤더 정보를 해석하여 적절한 처리를 행한다.

CNL(106)은 상위의 DTL(104)의 요구에 따라서, 물리층(108)의 서비스를 이용한 통신을 행하는 것 외에, 물리층(108)의 접속의 확립, 절단, 데이터의 연속성의 보장 등을 행한다.

물리층(108)은 본 실시 형태에 의한 근거리 대용량 통신이 가능한 무선 통신 시스템의 JET 물리층이며, 오류 정정 기능, 프리앰블 센스(preamble sense) 기능을 포함한다.

도 4는, JET 디바이스를 탑재하는 기기의 소프트웨어의 역할에 기초하여, 도 2의 구성을 OSI 참조 모델로 나타낸 것이다. 도 4에 도시하는 바와 같이, 물리층(제1 층)(108)은 데이터를 통신 회선에 송출하기 위한 전기적인 변환이나 기계적인 작업을 담당한다. 핀의 형상이나 케이블의 특성 등도 제1 층에서 정해진다.

DTL(104), CNL(106)은 데이터 링크층(제2 층), 트랜스포트층(제4 층)에 대응한다. 데이터 링크층은 통신 상대와의 물리적인 통신로를 확보하고, 통신로를 흐르는 데이터의 에러 검출 등을 행한다. 또한, 트랜스포트층은 통신 상대까지 확실하게 효율적으로 데이터를 보내기 위한 데이터 압축이나 오류 정정, 재송 제어 등을 행한다. 또한, 본 실시 형태의 시스템은 P2P 통신이기 때문에, OSI 참조 모델에 있어서의 네트워크층(제3 층)은 형성되어 있지 않아, 시스템을 간략화할 수 있다.

PCL(102)은 세션층(제5 층)과 프리젠테이션층(제6 층)에 대응한다. 세션층은 통신 프로그램끼리가 데이터의 송수신을 행하기 위한 가상적인 경로(커넥션)의 확립이나 해방을 행한다. 프리젠테이션층은 세션층으로부터 수취한 데이터를 유저가 알기 쉬운 형식으로 변환하거나, 애플리케이션층으로부터 보내져 오는 데이터를 통신에 적합한 형식으로 변환하는 등의 처리를 행한다.

유저 애플리케이션(100)은 애플리케이션층(제7 층)에 대응한다. 애플리케이션층은 데이터 통신을 이용한 다양한 서비스를 사람이나 다른 프로그램에 제공한다.

다음에, 본 실시 형태의 통신 장치에 있어서의 데이터의 흐름을 설명한다. 도 5는 데이터 플로우를 도시하는 모식도이며, JET 기기 내의 각 레이어에 있어서의 파일, 데이터의 송수신의 데이터 플로우를 나타내고 있다. 또한, PCL(102)은 PCL 코먼과 PCL 에뮬레이션으로 기능이 나누어진다. 데이터 전송에서 이용하는 것은 PCL 에뮬레이션이기 때문에, 도 5에 나타내는 PCL(102)에 의한 처리는 PCL 에뮬레이션에 의해 실현되는 기능이다. 물리층(108)에 입력되는 CSDU는 데이터 포맷으로서 규정되어 있고, 그 헤더 정보 등의 생성, 해석을 행하는 DTL(104)이 취급하는 데이터 포맷도 마찬가지이다.

또한, 후술하는 바와 같이, 공통 기능을 제공하기 위한 PCL 코먼에 대해서는 규정되어 있지만, PCL 에뮬레이션은 유저 프로토콜에 준한 데이터 변환 처리를 행하기 위해 각각의 프로토콜에 따른 시스템 사양에 의존한다.

JET 통신에서는, 파일 등의 데이터뿐만 아니라, PCL(102), DTL(104) 내에서의 관리 파라미터나, 통신처의 동일 레이어 사이에서의 데이터의 송수신이 존재한다. 이들의 파일, 파라미터류는 CNL(106)에 의해 최종적으로 CSDU 포맷에 준거한 형식으로 전송된다. 도 6은 CSDU에 의한 논리적인 채널을 도시하는 모식도이다. 도 6에 도시한 바와 같이, 데이터의 종별을 특정하기 위해서는 프로파일 ID를 사용한다. 이에 의해, 물리층(108)의 레벨에서, 복수의 전송 채널을 논리적으로 사용하는 것이 가능해진다. 따라서, 통신 레이트를 대폭으로 향상시킬 수 있고, 특히 동화상 등의 대용량의 데이터 통신에 적합하다.

도 7은, CSDU가 맵핑되는 모습을 도시하는 모식도이다. CSDU는 CNL(106)과 DTL(104) 사이에서 교환되는 데이터 유닛이며, 도 7에 도시한 바와 같이, CNL 프레임에 맵핑된다. 유저 애플리케이션(100)이 송수신하는 유저 데이터 사이즈는 특별히 규정되지 않는다. PCL(102)은 데이터의 길이가 데이터 분할 길이(최대 4096바이트)를 초과한 경우, 복수의 CSDU 유료 하중으로 분할된다. PCL(102)은 CSDU 유료 하중의 단위로, DTL 서비스를 호출하여 유저 데이터의 송수신을 행한다. DTL(104)은 CSDU 유료 하중에 헤더를 추가하여 하위의 CNL(106)에 전달한다. CSDU 헤더는 Profile ID와 CSDU 유료 하중의 길이를 나타내는 Length로 구성된다.

도 8은, 본 시스템의 기기의 하드웨어 구성을 도시하는 모식도이다. 도 5에 도시한 바와 같이, 이니시에이터와 리스폰더의 각각은, 물리층(108)을 구성하는 칩(200)과, CPU(210)를 갖고 구성된다. 물리층(108)은 베이스밴드부를 포함하고 있다. 상술한 유저 애플리케이션(100), PCL(102), DTL(104), CNL(106)은 소프트웨어(프로그램)에 의해 CPU(210)를 기능시킴으로써 실현된다. 소프트웨어는 이니시에이터, 리스폰더를 구성하는 통신 장치가 구비하는 메모리, 또는 통신 장치의 외부의 기록 매체 등에 저장된다.

도 9는, 각 레이어가 제공하는 서비스의 엑세스 포인트와, 레이어간의 관계를 나타내는 모식도이다. PCL(102)의 상위는 유저 애플리케이션(100)이 된다. PCL(102)은 하위 DTL(104)을 이용한 서비스를 제공하는 레이어이다. PCL(102)은 상위의 유저 애플리케이션(100)에 대해서는, 제어를 PCL 코먼(102a)(공통 처리부)이 행하고, 데이터 전송은 PCL 에뮬레이션(102b)(변환 처리부)이 행하도록 역할이 나누어지므로, PCL(102)의 서비스는 각각에 대하여 규정된다.

PCL 코먼(102a)에 의한 서비스는 유저 애플리케이션(100)의 요구에 따라서, DTL(104)의 접속/절단/그 밖의 제어의 서비스를 호출함으로써 하기의 서비스를 제공한다.

ㆍ접속, 절단 등의 제어 서비스

ㆍ에러 등의 이벤트 통지 서비스

ㆍ에뮬레이션 제어 서비스

PCL 에뮬레이션(102b)에 의한 서비스는, 대응하는 프로토콜마다 개별로 존재한다. 개개의 PCL 에뮬레이션은 CSDU의 유료 하중 상에 범용 프로토콜(USB, OBEX 등)의 커맨드, 데이터를 실어 통신하는 것을 가능하게 하는 프로토콜 서비스이다.

PCL(102)에서는, PCL 에뮬레이션 서비스에 의해 선택된 프로토콜 방식에 해당하는 서비스만 기동하는 것이 허가된다. PCL 에뮬레이션 서비스 내부에서는 상위 프로토콜의 요구에 따라서, DTL(104)에 의한 서비스를 이용하기 위한 CSDU 유료 하중을 생성한다. PCL 에뮬레이션(102b)에 의한 서비스를 복수 가짐으로써, 1개의 JET 기기에서 복수의 에뮬레이션 서비스(Emulation Service)를 실현하는 것이 가능해진다. PCL 코먼(102a)에 의해 한번의 세션으로 이용할 수 있는 에뮬레이션 서비스는 1종류뿐이도록 관리된다.

도 9에 도시한 바와 같이, PCL(102)은 PCL 코먼(PCL Common)(102a)과, PCL 에뮬레이션(PCL Emulation)(102b)으로 그 기능이 분할된다. PCL 코먼(102a)은 상위의 유저 애플리케이션(100)의 요구에 따라 하위 레이어의 서비스의 초기화나, 접속, 절단 등의 기본 기능을 제공한다. PCL 코먼(102a)에서는 기본 기능의 처리를 행하기 위해, 어느 프로토콜이 선택된 경우에 있어서도 마찬가지의 처리가 행해진다. 한편, PCL 에뮬레이션(102b)은 PCL 코먼(102a)에 의해 기동이 완료된 후, 유저 애플리케이션(100)이 갖는 임의의 프로토콜을 하위의 DTL(104), CNL(106)이 취급하는 프로토콜 형식으로 변환한다.

상술한 바와 같이, PCL 코먼(102a)은 초기화, 기본 통신(접속, 절단, 기기 인증) 등의 공통 기능 서비스를 유저 애플리케이션(100)에 대하여 제공한다. PCL 코먼(102a)은 모든 JET 디바이스에서 공통으로 설치되는 소프트웨어이다. 따라서, PCL(102)은 PCL 에뮬레이션(102b)만의 구성으로는 동작할 수 없다.

PCL 에뮬레이션(102b)은, PCL 코먼(102a)에 의해 접속이 행해진 후, 유저 데이터 전송을 행하는 것으로, 유저 프로토콜(USB, OBEX 등의 범용 프로토콜 데이터)을 DTL(104)이 취급하는 데이터 형식으로 상호 변환하는 역할을 갖는다. PCL 에뮬레이션(102b)은 유저 애플리케이션(100)으로부터 보내져 오는 유저 프로토콜 데이터를, 하위의 DTL(104)이 해석할 수 있는 형식으로 변환하는 역할을 갖는다. PCL(102) 내의 에뮬레이션 블록[PCL 에뮬레이션(102b)의 변환 모듈]은 유저 애플리케이션(100)으로부터 본 경우에, 기존의 USB MSC, NFC 등의 디바이스를 제어하는 것과 동등한 방식으로 데이터 전송 기능을 제공하기 위한 서비스를 제공한다. 단, PCL 에뮬레이션(102b)은 기기를 구성하는 유저 고유의 프로토콜 수만큼 존재한다.

DTL(104)은 상위의 2종류의 PCL[PCL Common(102a), PCL Emulation(102b)]에 대하여, 하위 CNL(106)의 서비스를 이용한 기능을, DTL 서비스로서 제공한다. PCL 에뮬레이션(102b)은, 이후에 상세하게 설명한 바와 같이, 유저 프로토콜마다 변환 모듈(Protocol A, Protocol B, Protocol C,… Protocol Z)을 갖지만, 한번의 세션(접속)으로 이용할 수 있는 것은 1종류뿐이며, 그 제어는 PCL 코먼(102a)에 의해 행해진다. 예를 들어, 상위 프로토콜이 USB인 경우, 매스 스토리지 클래스이거나, 혹은 다른 방식에 의해 다른 변환 모듈이 준비되어 있다.

JET 디바이스에 있어서, 기기를 구성하는 유저는 상위의 프로토콜에 대응한 변환 모듈을 자유롭게 설정하여 PCL 에뮬레이션(102b)을 구축할 수 있다. 또한, 변환 모듈의 추가, 삭제도 유저가 자유롭게 행할 수 있다. 한편, PCL 코먼(102a)은 프로토콜 변환의 기본 기능이므로, 모든 JET 디바이스에 있어서 공통인 것이 의무화된다.

도 9에서는, 유저 프로토콜로서 Protocol A 내지 Z가 나타내어져 있고, 이 중 Protocol B가 액티브로 되고, Protocol B에 의해 접속이 행해지고 있는 상태를 나타내고 있다. 이 경우, 이니시에이터와 리스폰더의 양쪽에서 Protocol B에 의한 접속이 행해진다. 어느 프로토콜에서 접속하는지는, 이니시에이터와 리스폰더 사이의 니고시에이션에 의해 결정된다.

도 10은 본 실시 형태의 시스템에 있어서의 상태 천이를 도시하는 모식도이다. PCL(102)은 물리층(108)에 의한 이니시에이터와 리스폰더의 접속 상태의 변화나, 유저 애플리케이션으로부터 PCL Service를 이용함으로써, 도 10에 나타내는 상태 천이를 행한다.

도 10에 있어서, 우선 리스폰더는 이니시에이터로부터의 접속 대기 상태로 되고, 이니시에이터는 접속처의 리스폰더를 서치하고 있는 상태로 된다. 이니시에이터와 리스폰더의 접속이 개시되면(Start Connection), 이니시에이터와 리스폰더 사이에서 니고시에이션(Negotiation)이 행해진다. 이 상태에서는, JET 디바이스간에 소프트웨어의 버전의 확인, 에뮬레이션 방식(서로 어떤 프로토콜을 갖고 있는지)의 확인이 행해진다.

니고시에이션의 결과, 버전, 에뮬레이션 방식이 일치한 경우에는 접속이 행해지고, 물리층(108)에 의한 접속이 완료된다(Connected). 그 후, 에뮬레이션이 개시되어(Emulation), 유저 애플리케이션(100) 사이에서 데이터 전송이 가능한 상태로 된다. 한편, 소프트웨어의 버전 정보가 일치하지 않은 경우, 또는 양쪽이 보유하는 프로토콜이 일치하지 않고, 에뮬레이션 방식이 일치하지 않은 경우에는, 접속이 행해지지 않는다(Disconnect). 접속이 되지 않은 경우(Disconnect), 에뮬레이션이 종료된 경우(End Emulation)에는 리스폰더가 접속 대기 상태로 된다.

PCL 코먼(102a)은 PCL(102)의 버전(Version) 정보에 기초하여, 버전 체크(Version Check) 및 에뮬레이션 방식의 판별을 행하는 니고시에이션 기능을 구비한다. 니고시에이션의 결과, 버전 및 에뮬에이션 방식이 일치하면, 이니시에이터와 리스폰더의 사이에서 동일한 프로토콜에 의한 접속이 행해진다. 니고시에이션에 필요한 버전 관리 기능(PCL Version Management) 및, 에뮬레이션 판별 기능(PCL Select Emulation)에 대해서는 이후에 설명한다. 니고시에이션은 유저 애플리케이션(100)에 대하여 제공되는 서비스가 아닌, 접속 대기 중의 상태에서, 접속을 검지하였을 때에 자동으로 실행되는 내부 기능이다.

도 11은 니고시에이션의 처리를 도시하는 모식도이다. 도 11의 처리는, 도 2의 각 층의 소프트웨어에 의해 CPU(210)를 기능시킴으로써 실현할 수 있다. 일례로서, 판별 자체는 리스폰더가 행하고, 이니시에이터는 그 판별 결과를 기다린다. 접속처의 버전 정보의 취득은 CNL(106)이 행하고, 접속 시에 버전 정보가 자동적으로 교환된다(스텝 S1). 이때 교환되는 버전 정보를 JET 버전이라고 칭하는 것으로 한다.

PCL(102)에서는, 하위의 CNL(106), DTL(104)로부터의 이벤트에 의해, 접속을 검지한 시점에서 접속처 JET 디바이스의 JET 버전의 정보가 이미 취득되어 있다. 이로 인해, 우선, 도 11에 도시한 바와 같이, CNL(106)의 소프트웨어의 버전 체크(CNL Ver check)와 DTL의 소프트웨어의 버전 체크(DTL Ver check)가 행해진다. PCL(102)의 내부에서 행해지는 것은, JET 버전 내에 포함되는 PCL 버전의 체크에 의한 에뮬레이션 방식의 판별이다.

에뮬레이션 방식의 판별은, 예를 들어 리스폰더가 주도하여 행한다. 이니시에이터와 리스폰더의 양쪽에서 PCL(102)의 버전 정보가 교환되고, PCL 코먼(102a)의 PCL 버전 체크 기능에 의해 PCL(102)의 소프트웨어의 버전 정보가 체크된다(PCL Ver check).

다음에, 이니시에이터와 리스폰더의 양쪽에서 에뮬레이션 타입의 정보가 교환되고, 도 11에 도시한 바와 같이, PCL 코먼(102a)의 에뮬레이션 타입 체크 기능에 의해 에뮬레이션의 타입이 체크된다(EMU Type check). 에뮬레이션 타입은, 서로의 JET 디바이스가 통신 가능한 에뮬레이션 방식(프로토콜)을 기술한 파라미터이다.

리스폰더측에서는, 이니시에이터와 리스폰더의 서로의 에뮬레이션 타입의 비교를 행하여, 동일한 것이 있으면 접속 가능하다고 판단한다. PCL(102)은 에뮬레이션 타입이 확정한 시점에서 유저 애플리케이션(100)에 통지를 행하고, 유저 애플리케이션(100)이 PCL_start_emu service를 호출한다(스텝 S2). 그리고, PCL 코먼(102a)으로부터 PCL 에뮬레이션(102b)으로 Start_Emu라는 커맨드를 보낸다. 이에 의해 PCL 코먼(102a)에 의한 기동이 완료되고, PCL 에뮬레이션(102b)에 의한 에뮬레이션이 개시된다(스텝 S3). 그리고, PCL 에뮬레이션(102b)에 의해 유저 애플리케이션(100)의 프로토콜을 변환하여, 하위의 DTL(104), CTL(106)과 통신을 행하는 것이 가능해진다.

또한, 이니시에이터와 리스폰더에서 동일한 에뮬레이션 타입을 복수 갖고 있는 경우에는, 유저 애플리케이션(100)에 그 취지를 통지한다. 유저 애플리케이션(100)측에서 이들의 복수의 에뮬레이션 타입의 1개를 지정하는 경우에는, 그 취지의 정보가 PCL(102)에 보내진다. 이때, 유저 애플리케이션(100)측에서는, 미리 지정된 1개의 에뮬레이션 타입을 지정할 수 있다. 또한, 이니시에이터와 리스폰더의 한쪽이 휴대 기기의 경우 등, 고속 통신 가능한 프로토콜을 사용할 필요가 비교적 낮은 경우는, 통신 속도에 따른 적절한 프로토콜의 에뮬레이션 타입을 선택할 수 있다. 이들 사양은, JET 디바이스 또는 유저 애플리케이션(100)을 구성하는 유저가 자유롭게 설정할 수 있다.

다음에, PCL(102)에 의한 에뮬레이션 선택에 대하여 설명한다. 에뮬레이션 선택은 이니시에이터로부터의 접속 검지를 검지한 리스폰더측에서 니고시에이션을 행할 때에 PCL 코먼(102a)의 내부에서 실행되는 기능이다. 접속 시에 JET 디바이스간에 교환되는 JET 버전 중 PCL 버전 정보로부터, 서로 적합한 에뮬레이션을 갖고 있는지를 확인한다.

도 12는 JET 버전 정보를 설명하기 위한 모식도이다. PCL(102)은 자기의 버전 정보와, 접속처 JET 디바이스의 버전 정보의 2개를 관리한다. 자기의 버전 정보는 반드시 기동 시에 로드되고, 접속 검지 시, 접속 중에는 접속처 디바이스의 버전 정보를 유지한다.

도 12에 도시한 바와 같이, JET의 버전 정보는 합계 10바이트이며, 상층으로부터 순서대로 플랫폼(Platform) 정보(1byte), JET 드라이버 버전 정보(2byte), CNL 버전 정보(1byte), DTL 버전 정보(2byte), PCL버전 정보(2byte), 예약 정보(2byte)가 있다.

PCL 버전 정보(2byte) 중 전반의 1바이트는, 시스템의 호환성 유지를 위한 소프트웨어의 Version No(T.B.D)이다. 후반의 1바이트는, 장치(JET 디바이스)가 대응하는 에뮬레이션 방식을 나타내고 있다. 도 12에서는, 에뮬레이션 방식으로서 USB, TCP/IP, OBEX…가 예시되고, 각 방식에 1비트의 데이터가 부여되어 있다. 그리고, 비트가 1인 경우는 그 에뮬레이션 방식에 대응하는 것을 나타내고 있고, 비트가 0인 경우는 그 에뮬레이션 방식에 대응하고 있지 않은 것을 나타내고 있다. 1개의 JET 디바이스에서 대응하는 에뮬레이션 방식의 최대값에는 규정은 없지만, 최저라도 1개의 에뮬레이션 방식에는 대응해야만 한다.

또한, 버전 정보의 체크는, 도 11에 도시한 바와 같이, 도 12의 상층측(플랫폼측)의 정보로부터 순차적으로 행해진다. PCL(102)의 버전 정보의 체크 후, 에뮬레이션 타입의 체크가 행해진다.

접속의 실행 결과로서, 서로 통신 가능한 에뮬레이션 방식을 기술한 에뮬레이션 타입이 선택되고, 선택된 에뮬레이션 타입은 리스폰더측으로부터 유저 애플리케이션(100)에 통지되고, 또한 허가 대기를 하고 있는 이니시에이터에 통지된다. 도 13은, 에뮬레이션 선택의 시퀀스를 나타내는 모식도이다. 도 13에 있어서, 선택된 에뮬레이션 타입(EMUTYPE)은 리스폰더의 유저 애플리케이션(100)(UsrAppl)에 대해서는 PCL_conf_r.ind로서, 이니시에이터측에 대해서는 PCL_conf_i.ind로서 통지된다(도 13 참조).

도 14 및 도 15, PCL 에뮬레이션(102b)에 관계되는 서비스를 나타내는 모식도이다. 이하, 각 서비스에 대하여 설명한다. 기동, 종료는 PCL 코먼(102a)에 의해 행해지지만, 데이터의 송신, 수신은 유저 애플리케이션(100)으로부터 PCL 에뮬레이션(102b)에 통신을 행함으로써 실행할 수 있다. 따라서, PCL 코먼(102a)과의 사이에서 제공되는 서비스(도 14)와, 유저 애플리케이션(100)과의 사이에 제공되는 서비스(도 15)로 나눌 수 있다.

Start service(Mandatory; 도 14)

Start service는 표준으로 제공되는 서비스이며, 에뮬레이션을 개시할 때, PCL 코먼(102a)에 의해 실행되는 PCL 에뮬레이션(102b)의 초기화 처리를 제공하는 서비스이다. Start가 완료된 시점에서, 유저 애플리케이션(100)으로부터 유저 프로토콜을 사용한 데이터 송수신이 가능해진다.

End service(Mandatory; 도 14)

End service는 표준으로 제공되는 서비스이며, 에뮬레이션을 종료할 때, PCL 코먼(102a)에 의해 실행되는 에뮬레이션의 종료 처리를 제공하는 서비스이다. End가 완료된 시점에서, 유저 애플리케이션(100)으로부터 유저 프로토콜을 사용한 데이터 송수신은 불가능해진다. PCL 코먼(102a)은 에뮬레이션이 Start되어 있었던 경우, 절단(PCL_Disconect)을 실행하기 전에, 이 서비스를 실행한다.

Open service(Mandatory; 도 15)

Open service는 유저 프로토콜 상에서의 통신로의 오픈 시에 필요한 처리를 제공하는 서비스이다.

Close service(Mandatory; 도 15)

Close service는 유저 프로토콜 상에서의 통신로의 클로우즈 시에 필요한 처리를 제공하는 서비스이다.

Read service(Mandatory; 도 15)

Read service는 유저 프로토콜 상에서, 접속처의 데이터를 취득할 때에 필요한 처리를 제공하는 서비스이다.

Write service(Mandatory; 도 15)

Write service는 유저 프로토콜 상에서, 접속처에 데이터를 송신할 때에 필요한 처리를 제공하는 서비스이다.

이상과 같이, Open service, Close service는 PCL 코먼(102a)에 의한 상위 프로토콜의 초기화 처리에 대응하는 처리이다. 또한, Read service, Write service는 유저 애플리케이션(100)에 의한 데이터의 송신, 수신에 관한 처리이다.

User customize service(Option; 도 15)

상술한 서비스에 해당하지 않는 서비스이며, 장치를 구성하는 유저가 독자적인 서비스로서 정의할 수 있는 것이다. 통신로를 "개방한다(Open)", "폐쇄한다(Close)", 데이터를 "보낸다(Write)", "받는다(Read)" 이외의 부분은, JET 디바이스를 구성하는 유저가 자유롭게 설정할 수 있는 커스터마이즈 영역으로 되고, 예를 들어 유저 애플리케이션(100)의 종류[Windows(등록 상표), Linux 등]에 따라서, 유저가 자유롭게 설정할 수 있다. 단, 어느 애플리케이션을 사용한 경우에도, 상술한 바와 같이 PCL 코먼(102a)에 의한 "Start", "End"는 필요하고, 모든 JET 디바이스에서 공통이다.

이상 설명한 바와 같이 본 실시 형태에 따르면, 유저 애플리케이션(100)의 프로토콜을 변환하는 PCL(102)을 설치하고, 각 통신 장치에 공통으로 설치된 PCL 코먼(102a)에 의해, 유저 애플리케이션(100)의 하나 또는 복수의 프로토콜 중에서 통신 상대의 프로토콜과 일치하는 프로토콜이 선택된다. 그리고, 선택된 프로토콜이 물리층(108)에서 통신을 행하기 위한 프로토콜로 변환되므로, 통신 상대의 유저 애플리케이션(100)의 프로토콜에 따라서 통신에 최적인 프로토콜을 선택하는 것이 가능해져, 통신의 호환성을 확보할 수 있다. 또한, 상술한 예에서는, 무선 통신 시스템을 예로 들어 설명하였지만, 통신 시스템은 유선이 것이어도 된다.

이상, 첨부 도면을 참조하면서 본 발명이 적합한 실시 형태에 대하여 설명하였지만, 본 발명은 이러한 예에 한정되지 않는 것은 물론이다. 당업자라면 특허청구범위에 기재된 범주 내에 있어서, 각종 변경예 또는 수정예에 상도할 수 있는 것은 명확하고, 그들에 대해서도 당연히 본 발명의 기술적 범위에 속하는 것으로 이해된다.

100: 유저 애플리케이션
102: PCL
102a: PCL 코먼
102b: PCL 에뮬레이션
108: 물리층
210: CPU

Claims

다른 통신 상대와의 사이에서 신호의 송수신을 행하는 물리층과,
상위 애플리케이션과 상기 물리층 사이를 접속하는 프로토콜 변환부를 구비하고,
상기 프로토콜 변환부는,
서로 통신 가능한 각 장치에 공통으로 설치되고, 프로토콜 변환을 위한 기본 처리를 행하는 공통 처리부와,
상기 상위 애플리케이션의 하나 또는 복수의 프로토콜에 대응하여 설치되고, 상기 공통 처리부에 의해 상기 하나 또는 복수의 프로토콜 중에서 선택된 프로토콜을 상기 물리층에서 통신하기 위한 프로토콜로 변환하는 변환 처리부
를 포함하는 것을 특징으로 하는, 통신 장치.
제1항에 있어서,
상기 공통 처리부는 적어도 상기 프로토콜 변환의 기동, 정지를 포함하는 기본 동작을 행하는 것을 특징으로 하는, 통신 장치.
제1항에 있어서,
상기 공통 처리부는 상기 통신 상대와의 니고시에이션의 결과에 따라서, 상기 하나 또는 복수의 프로토콜 중에서 상기 통신 상대가 구비하는 상위 애플리케이션의 프로토콜과 일치하는 프로토콜을 선택하는 것을 특징으로 하는, 통신 장치.
제3항에 있어서,
상기 공통 처리부는 상기 하나 또는 복수의 프로토콜 중에, 상기 통신 상대가 구비하는 상위 애플리케이션의 프로토콜과 일치하는 프로토콜이 존재하지 않은 경우에는, 상기 통신 상대와의 접속을 행하지 않는 것을 특징으로 하는, 통신 장치.
제1항에 있어서,
상기 공통 처리부는 통신 상대와의 니고시에이션의 결과에 따라서, 상기 프로토콜 변환부의 소프트웨어의 버전이 통신 상대가 구비하는 프로토콜 변환부의 소프트웨어의 버전과 일치하는지 여부를 판정하는 버전 체크 기능을 구비하는 것을 특징으로 하는, 통신 장치.
제5항에 있어서,
상기 공통 처리부는 상기 프로토콜 변환부의 소프트웨어의 버전이 통신 상대가 구비하는 프로토콜 변환부의 소프트웨어의 버전과 일치하지 않은 경우에는, 상기 통신 상대와의 접속을 행하지 않는 것을 특징으로 하는, 통신 장치.
제1항에 있어서,
상기 물리층은 상기 변환 처리부에서 프로토콜이 변환된 데이터에 대하여 데이터의 종별을 나타내는 프로파일 ID가 부여된 데이터를 통신 상대와의 사이에 통신하는 것을 특징으로 하는, 통신 장치.
통신 장치끼리 통신을 행하는 통신 시스템으로서,
상기 통신 장치는,
통신 상대가 되는 통신 장치의 사이에서 신호의 송수신을 행하는 물리층과,
상위 애플리케이션과 상기 물리층의 사이를 접속하는 프로토콜 변환부를 구비하고,
상기 프로토콜 변환부는,
서로 통신 가능한 각 통신 장치에 공통으로 설치되고, 프로토콜 변환을 위한 기본 처리를 행하는 공통 처리부와,
상기 상위 애플리케이션의 하나 또는 복수의 프로토콜에 대응하여 설치되고, 상기 공통 처리부에 의해 상기 하나 또는 복수의 프로토콜 중에서 선택된 프로토콜을 상기 물리층에서 통신하기 위한 프로토콜로 변환하는 변환 처리부를 포함하는 것을 특징으로 하는, 통신 시스템.
통신 장치끼리 통신을 행하는 통신 방법으로서,
상기 통신 장치가 통신 상대가 되는 다른 통신 장치와의 사이에서 프로토콜 정보를 교환하는 스텝과,
상기 프로토콜 정보에 기초하여, 상위 애플리케이션의 하나 또는 복수의 프로토콜 중에서, 통신 상대가 구비하는 상위 애플리케이션의 프로토콜과 일치하는 프로토콜을 선택하는 스텝과,
선택된 프로토콜을 통신 상대와 통신하기 위한 프로토콜로 변환하는 스텝을 구비하는 것을 특징으로 하는, 통신 방법.
통신 상대가 되는 다른 통신 장치와의 사이에서 프로토콜 정보를 교환하는 수단,
상기 프로토콜 정보에 기초하여, 상위 애플리케이션의 하나 또는 복수의 프로토콜 중에서, 통신 상대가 구비하는 상위 애플리케이션의 프로토콜과 일치하는 프로토콜을 선택하는 수단,
선택된 프로토콜을 통신 상대와 통신하기 위한 프로토콜로 변환하는 수단
으로서 컴퓨터를 기능시키기 위한 프로그램.