KR20060027352A

KR20060027352A - Ｉ２ｃ 물리층 연결에 대해 데이터링크층 프로토콜을확립하기 위한 방법 및 시스템

Info

Publication number: KR20060027352A
Application number: KR1020057024371A
Authority: KR
Inventors: 라스무스 빌레프란체; 제스퍼 산드베르그
Original assignee: 노키아 코포레이션
Priority date: 2003-06-26
Filing date: 2004-06-22
Publication date: 2006-03-27
Also published as: US7313136B2; CN1813456A; EP1636965B1; US20040264453A1; DE602004009312T2; ATE375057T1; WO2004114628A1; DE602004009312D1; EP1636965A1; KR100795449B1

Abstract

본 발명은 I²C™-버스에 연결된 시스템에서 복수 개의 모듈들 간에 데이터링크층 연결 가능한 데이터 통신을 확립하기 위한 방법에 관한 것이다. 모듈들은 셀 또는 이동전화기와 같은 이동통신기기 및 기능성 커버와 카메라 등과 같은 주변기기들일 수 있다. 그에 더하여, 본 발명은 I²C™ 규격에 따라 그리고 데이터링크층 프로토콜에 따라 구성된 데이터 패키지에 관한 것이다.

I2C™-버스, 데이터 통신, 프로토콜, 데이터링크층

Description

Ｉ２Ｃ 물리층 연결에 대해 데이터링크층 프로토콜을 확립하기 위한 방법 및 시스템{Method and system for establishing a data link layer protocol on a I2C physical layer connection}

본 발명은 I²C™-버스에 연결된 시스템에서 복수 개의 모듈 간에 데이터 통신을 가능케 하는 데이터링크층 연결을 확립하기 위한 방법에 관한 것이다. 이 모듈들은 셀 또는 모바일 전화기와 같은 이동통신기기, 및 기능성 커버, 카메라 등과 같은 주변기기들일 수 있다. 그에 더하여, 본 발명은 I²C™ 규격(specification)에 따라 그리고 데이터링크층 프로토콜에 따라 구성된 데이터 패키지에 관한 것이다.

필립스세미컨덕터(Philips Semiconductors)에 의해 공포되고 여기에 참조로써 통합된 I²C™-버스 규격(I²C™ 은 필립스 상표이다)은 복수 개의 연결된 집적회로들(IC들) 간의 데이터 통신을 위한 물리층을 제공하기 위한 사실상(de facto) 세계 표준이다. I²C™-버스는 임의의 IC 제조공정을 지원하고 직렬데이터(SDA)를 운반하기 위한 제1전선과 직렬클록(SCL)을 운반하기 위한 제2전선을 포함한다. I²C™-버스에 연결된 IC들은 각각이 유일한 주소에 의해 인식되고, IC들은 각각의 동작에 의존하여 I²C™-버스에 대해 송신기들 또는 수신기들로서 역할을 한다. 연결된 IC들은 슬레이브들 또는 마스터들로서 역할을 하여, 마스터는 슬레이브에 연락할 때를 결정하고 마스터는 슬레이브가 마스터에 연락할 때를 결정한다.

I²C™-버스 규격은 I²C™-버스 상에서 데이터를 전달(communate)하기 위해 도 1a에 보인 것처럼 데이터프레임(10)을 지정하며, 이 데이터프레임은 I²C™-버스 상에서의 전송 전에 "시작조건(start condition)"(12)을 필요로 하고 수신 IC의 7비트 "주소"(14)를 구비한다. 이 주소(14)에서 "0"은 "기입(write)"을 나타내고 "1"은 "판독"을 나타내는 데이터방향비트(16)가 뒤따르고, 데이터프레임(10)은 "정지조건(stop condition)"(18)으로 끝난다. 데이터방향비트(16)를 수신하는 것에 후속하여, I²C™ 규격은 확인비트(20)를 보냄으로써 주소(14)와 데이터방향비트(16)의 수신을 확인할 것을 데이터 수신 IC에 요구하고, 이러한 확인비트의 전송은 I²C™-데이터버스의 제1전선을 "0"이 되게 함으로써 달성된다. 확인비트(20)의 수신에 뒤이어, 데이터 송신 IC는 데이터(22)의 송신을 시작한다. 각 데이터바이트의 송신에는 데이터 수신 IC로부터의 도 1a에서 확인비트(24)로서 보인 추가의 확인비트들과 데이터(26)가 뒤따른다. 끝으로, 마지막 데이터바이트(26)가 최종 확인비트(28)에 의해 확인된다.

고속전송모드에서 도 1b에 보인 것 같은 데이터프레임(30)은 추가 "시작조건"(32), 8비트 "코드"(34) 및 "미확인비트"(36)와 그 뒤의 "시작조건"(38)을 더 포함하며, 시작조건(38)은 위에서 설명된 "시작조건"(12)을 대체한다. 그에 더하여, 고속전송모드에서 데이터바이트들은 마지막 데이터바이트의 송신 후에만 확인된다.

"정지조건"(18)은, 하나의 특정된 모드에서 일련의 데이터가 복수 개의 IC 슬레이브들 및/또는 마스터들에 보내지도록 하기 위해, 추가의 "시작조건"(38)에 의해 치환될 수 있다.

I²C™-버스는 매우 다양한 전자설비들에서 데이터의 교환을 확립하기 위한 수단을 제공하지만, I²C™-버스 규격은 다른 전송층 요구사항들을 갖는 전자시스템의 각종 유형들의 모듈들의 링크를 위한 규격들을 제공하는데에는 실패하고 있다. 그래서, 데이터가 I²C™-버스를 통해 전송될 때마다, 구형 및 추가된 신형 모듈들, 또는 다른 전송층 프로토콜들을 이용하는 모듈들 간에 호환성을 확립할 필요가 있다. 즉, 새로운 집합의 전자모듈들이 최초 집합의 데이터교환규칙들에 따라 동작하는 I²C™-버스를 이용하는 현존하는 전자시스템과 연결되도록 할 때, 전자모듈들의 새로운 집합에는, 현존하는 전자모듈들과 통신할 때 최초 집합의 데이터교환규칙들에 따라 통신할 것이 요구된다. 따라서 데이터교환규칙들의 일련의 집합들이 요구되거나, 다르게는, 데이터교환규칙들의 가장 오래된 집합이 어떤 집합이 사용되어야 할지를 결정함으로써 추가의 발전을 심각하게 제한한다.

본 발명의 목적은 종래기술의 I²C™ 규격들의 전술한 문제들 및 단점들을 해결하기 위한 방법 및 시스템을 제공하는 것과, I²C™-버스형 네트워크에서 역 및 순 호환성을 제공하는 데이터링크층 프로토콜을 제공하는 것이다.

게다가, 본 발명의 목적은 매우 다양한 전송층 프로토콜들을 이용하며 I²C™-버스에 연결된 모듈들 간에 데이터 통신을 가능케 하는 데이터링크층 프로토콜을 제공하는 것이다.

본 발명의 특정 이점은 I²C™ 데이터프레임 내에, I²C™-버스 상에서 어느 종류의 전송데이터라도 운반할 수 있는 데이터 패키지를 준비하는 것이다.

본 발명의 특정 특징은 본 발명에 따른 데이터링크층 프로토콜이 I²C™-버스 상에서 어느 특정한 I²C™ 실행 "모드"를 요구하지 않는다는 점에 관련한다.

아래의 상세한 설명으로부터 분명하게 될 위의 목적들, 이점 및 특징과 함께 다수의 그 밖의 목적들, 이점들 및 특징들은, 본 발명의 제1양태에 따라, I²C™-버스에 연결된 복수 개의 전자모듈들 사이에 데이터 통신을 제공하기 위한 시스템에 의해 얻어지고, 여기서 상기 복수 개의 전자모듈들 각각은, 계층구조 내에, I²C™ 규격을 따르는 물리층, 데이터 페이로드 유형을 위한 제1헤더필드 및 데이터링크층 버전을 위한 제2헤더필드를 포함하는 데이터링크층, 송신 전자모듈의 주소를 위한 제3헤더필드 및 상기 데이터 패키지의 길이를 위한 제4헤더필드를 포함하는 네트워크/전송 층, 및 데이터 페이로드를 포함하는 데이터 패키지를 전달(communicate)하기에 적합하게 되어 있다.

추가의 층들을 I²C™물리층 데이터프레임에 부가함으로써 상당한 진보가 달성될 수 있다. I²C™-버스로 전송하려는 페이로드를 참조모델에서 추가의 층들을 위한 데이터를 담고 있는 부가적인 헤더구역과 함께 패키징하는 것에 의해, 구조화 접근법이 달성되어, 이 접근법에서 데이터 패키지는 수신 모듈에 의해 적절히 식별될 수 있는 매우 다양한 페이로드유형들(프로토콜들에 따름)에 따라 구성된 데이터를 포함할 수 있다. 즉, 이 시스템은 복수 개의 프로토콜들을 이용하는 각종 전자모듈들이 I²C™-버스에 연결되도록 하여, 순방향 및 역방향 호환을 가능하게 한다. 전달(communicate)이란 용어는 이에 관련하여 임의의 구성 예를 들면 마스터/슬레이브 구성에서 데이터 패키지를 수신하거나 송신하는 것으로서 해석된다.

게다가, 제1, 제2 등의 용어는 이에 관련하여 식별번호로서 해석되지만 시간선(time line) 상의 물리적 위치 자체로서는 해석되지 않는다. 그럼에도 불구하고, 이 용어는 시간선 상의 위치를 포괄하도록 해석되어야 한다.

그에 더하여, 데이터 패키지란 용어는 이런 맥락에서 데이터그램 또는 데이터 패킷, 즉, 버스와 같은 네트워크연결을 통해 전달하려는 패키지로서 해석될 수 있고, 이 패키지는 일반적으로 헤더구역 및 페이로드구역과 함께 말단구역을 포함한다. 헤더구역에 들어 있는 정보는 일련의 층들로서 해석될 수 있고, 이런 맥락에서 네트워크에서의 두 끝점들 사이의 통신의 처리가 각 층이 자신 소유의 특별한 관련 함수들의 집합을 부가하는 층들로 나누어질 수 있다는 주요 아이디어를 가지는 개방 시스템 상호접속(open systems interconnection; OSI)과 같은 참조모델로서 계층구조라는 용어가 해석될 수 있다.

본 발명의 제1양태에 따른 전자모듈들은 셀, 모바일 또는 위성 전화기, 개인휴대정보단말, 또는 그 주변기기들과 같은 이동통신기기를 포함할 수 있다. 그러나 모듈이란 용어는 이런 맥락에서 집적회로(IC)와 같은 전자소자로서 또는 집적회로들의 그룹으로서 폭 넓게 해석될 수 있다.

본 발명의 제1양태에 따른 데이터 페이로드 유형은 OBEX(데이터가 기기들 간에 공유될 수 있는 기기독립적 통신프로토콜), TCP(Transmission control ptotocol), IP (Internet protocol), HTTP(Hypertext transfer protocol), 또는 임의의 전유 페이로드 유형이다. 사실, 이 시스템은 역방향뿐 아니라 순방향 호환성이 있는 것으로 위에서 언급되었고 그러므로 추가의 페이로드 유형들의 미래형(future type)들(프로토콜들)이 시스템에 통합될 수도 있다.

본 발명의 제1양태에 따른 데이터링크층 버전은 이진 비호환성의 메이저 버전과 이진 호환성의 마이너 버전을 포함할 수 있다.

본 발명의 제1양태에 따른 데이터 패키지는, 상기 네트워크/전송 층 내에, 상기 데이터 패키지에서의 데이터 페이로드 시작의 결정을 위한 오프셋값 용의 제5헤더필드를 더 포함할 수 있다. 이 오프셋값은 네트워크/전송 프로토콜들에 대한 장래의 변경들을 보상하기 위한 수단을 제공하는데, 수신모듈이 헤더에 잠재 데이터를 요구하지 않을 때 수신모듈이 오프셋값을 통해 페이로드 시작으로 바로 점프할 수 있기 때문이다.

본 발명의 제1양태에 따른 데이터 패키지는, 상기 데이터 패키지는, 상기 네트워크/전송 층 내에, 버퍼링을 위해 상기 데이터 패키지 내의 상기 데이터 페이로드 시작 전에 제6헤더필드를 더 포함할 수 있다. 네트워크/전송 층 내의 제6헤더필드는 헤더의 장래의 확장부가 통합될 때 특히 유익하다. 오프셋값은 잠재적으로 시프트되는 데이터 페이로드의 시작을 보상한다.

본 발명의 제1양태에 따른 데이터 패키지 체크섬 필드를 포함할 수 있다. 체크섬은 수신된 데이터 페이로드가 정확히 수신되었는지를 계산하는 프로세서를 위한 수단을 제공한다.

본 발명의 제1양태에 따른 데이터 패키지는, 상기 네트워크/전송 층 내에, 데이터 패키지 번호를 위한 제7헤더필드를 더 포함하며, 상기 네트워크/전송 층 내에, 데이터 패키지 프래그먼트 순번을 위한 제8헤더필드를 더 포함한다. 데이터 패키지 번호는 복수 개의 데이터 패키지들 내의 데이터메시지들을 분리하기 위한 수단을 제공하고 데이터 패키지 프래그먼트 순번은 분리된 데이터메시지들을 특정 순서로 재결합하기 위한 수단을 제공한다.

아래의 상세한 설명으로부터 명확하게 될 위의 목적들, 이점들 및 특징들과 함께 다수의 그 밖의 목적들, 이점들 및 특징들, 본 발명의 제2양태에 따라, I²C™-버스에 연결된 복수 개의 전자모듈들 간의 통신을 위한 데이터 패키지로서, 상기 데이터 패키지는, 계층구조 내에, I²C™ 규격을 따르는 물리층 데이터, 제1헤더필드 내에 데이터 페이로드 유형을 포함하며 제2헤더필드 내에 데이터링크층 버전을 포함하는 데이터링크층 데이터, 및 제3헤더필드 내에 송신 전자모듈의 주소를 포함하며 제4헤더필드 내에 상기 데이터 패키지의 길이를 포함하는 네트워크/전송 층 데이터, 및 데이터 페이로드를 포함하는, 데이터 패키지에 의해 얻어진다.

본 발명의 제2양태에 따른 데이터 패키지는 본 발명의 제1양태에 따른 시스템의 어떠한 특징들이라도 통합할 수 있다.

아래의 상세한 설명으로부터 명확하게 될 위의 목적들, 이점들 및 특징들과 함께 다수의 그 밖의 목적들, 이점들 및 특징들은, 본 발명의 제3양태에 의하면, 제2양태 따라 데이터 패키지를 수신하기 적합한 수신기 유닛에 의해 달성된다.

아래의 상세한 설명으로부터 명확하게 될 위의 목적들, 이점들 및 특징들과 함께 다수의 그 밖의 목적들, 이점들 및 특징들은, 본 발명의 제4양태에 의하면, 본 발명의 제2양태에 따라 데이터 패키지를 송신하기에 적합한 송신기 유닛에 의해 달성된다.

아래의 상세한 설명으로부터 명확하게 될 위의 목적들, 이점들 및 특징들과 함께 다수의 그 밖의 목적들, 이점들 및 특징들은, 본 발명의 제5양태에 의하면, I²C™-버스에 연결된 복수 개의 전자모듈들 간에 데이터 통신을 확립하기 위한 방법으로서, 상기 복수 개의 전자모듈들 각각은 I²C™ 규격을 따르는 물리층을 계층구조 내에 포함하는 데이터 패키지를 전달하고, 상기 방법은 상기 데이터 패키지 내의 데이터링크층 내에는 데이터 페이로드 유형을 위한 제1헤더필드와 데이터링크층 버전을 위한 제2헤더필드를 제공하는 단계, 상기 데이터 패키지 내의 네트워크/전송 층 내에는 송신 전자모듈의 주소를 위한 제3헤더필드와 상기 데이터 패키지의 길이를 위한 제4헤더필드를 제공하는 단계, 및 상기 데이터 패키지 내에 데이터 페이로드를 제공하는 단계를 포함하는 방법에 의해 달성된다.

본 발명의 제5양태에 따른 방법은 본 발명의 제1양태에 따른 시스템의 어느 특징들, 본 발명의 제2양태에 따른 데이터 패키지의 어느 특징들, 본 발명의 제3양태에 따른 수신기 유닛의 어느 특징들, 및 본 발명의 제4양태에 따른 송신기 유닛의 어느 특징들이나 통합할 수 있다.

아래의 상세한 설명으로부터 명확하게 될 위의 목적들, 이점들 및 특징들과 함께 다수의 그 밖의 목적들, 이점들 및 특징들은, 본 발명의 제6양태에 의하면, I²C™-버스에 연결된 복수 개의 전자모듈들 간에 데이터 통신을 확립하기에 적합한 데이터처리기에서 프로그램을 실행할 때 다음의 단계들을 수행하기에 적합한 코드를 포함하는 컴퓨터 프로그램에 있어서, 상기 복수 개의 전자모듈들 각각은 I²C™ 규격을 따르는 물리층을 계층구조 내에 포함하는 데이터 패키지를 전달하고, 상기 프로그램은, 상기 데이터 패키지 내의 데이터링크층 내에는 데이터 페이로드 유형을 위한 제1헤더필드와 데이터링크층 버전을 위한 제2헤더필드를 제공하며, 상기 데이터 패키지 내의 네트워크/전송 층 내에는 송신 전자모듈의 주소를 위한 제3헤더필드와 상기 데이터 패키지의 길이를 위한 제4헤더필드를 제공하고, 상기 데이터 패키지 내에 데이터 페이로드를 제공하는, 컴퓨터 프로그램에 의해 달성된다.

본 발명의 제6양태에 따른 컴퓨터 프로그램은 본 발명의 제1양태에 다른 시스템의 어느 특징들, 본 발명의 제2양태에 따른 데이터 패키지의 어느 특징들, 및 본 발명의 제3양태에 다른 방법의 어느 특징들이나 통합할 수 있다.

본 발명의 위의 목적들과 부가적 목적들, 특징들 및 이점들은 다음과 같은 첨부 도면들을 참조하는 본 발명의 바람직한 실시예들의 다음의 예시적이고 제한적이진 않는 상세한 설명을 통해 더 잘 이해될 것이다:

도 la 및 lb는 I²C™-버스 상에서 전송되는 데이터의 종래기술의 I²C™ 규정의 구성을 보이며,

도 1c는 본 발명에 따른 데이터 패키지의 바람직한 실시예를 보이며,

도 2는 기능성 커버 및 이동통신기기를 위한 데이터링크층 확립 통신을 보이며,

도 3은 응용층 통신, 제1연결확립, 그 후의 두 개의 통신예들을 보이며,

도 4는 어떤 미들릿들이 이동통신기기에 설치되어 있다는 것을 기능성 커버가 어떻게 검사하는 지를 보이며,

도 5는 기능성 커버로부터 이동통신기기로의 미들릿의 송신을 보이며,

도 6은 기능성 커버가 임의의 사용자 상호작용(대화) 없이 어떻게 미들릿을 시작하는 지를 보이고,

도 7은 애플리케이션메뉴로부터 사용자가 어떻게 미들릿을 시작하는지를 보 인다.

다음의 각종 실시예들의 설명에서, 실시예들의 부분을 이루며 도시에 의해 본 발명이 실용화될 수 있는 각종 실시예들을 보이는 첨부 도면들이 참조된다. 다른 실시예들이 이용될 수 있고 구조적 및 기능적 변형들이 본 발명의 범위로부터 벗어남 없이 만들어질 수 있다는 것이 이해된다.

이 설명에 적용되는 정의는, 각 데이터 패키지가 데이터프레임(물리층)을 지정하는 로우레벨 통신규칙들을 포함하는 경우, 즉, 데이터 패키지의 의도된 수신자가 누구인지에 관한 정보를 송신할 때 및 실제 데이터세그먼트들을 송신할 때, 메시지가 하나 이상의 데이터 패키지들로서 구성된다는 것이다. 데이터세그먼트들은 본 발명의 바람직한 실시예에 따라 헤더구역, 데이터 페이로드구역 및 말단구역을 더 포함한다. 그럼에도 불구하고, 일반적으로 이와 같은 데이터 패키지의 전체 구조는 헤더구역(물리층 데이터 및 상위층 데이터를 포함), 페이로드구역 및 말단구역으로 되지만, 헤더구역을 언급하는 문맥에서, 특별히 다르게 언급되지 않으면 헤더구역은 데이터세그먼트의 헤더구역을 의미한다.

도 1c에 보인 본 발명에 따른 데이터 패키지의 바람직한 실시예는 I²C™ 규격의 데이터프레임들(10, 30)을 참조모델에서의 물리층으로서 이용한다. 따라서 본 발명에 관련한 추가의 층들은 데이터를 데이터세그먼트(들)(22, 26)로 구조화함으로써 데이터프레임들(10, 30)에 통합된다. 데이터세그먼트(들)(22, 26)는 데이터를 아래의 표 1에 보인 포맷으로 전송하기 위해 패킹함으로써 이동통신기기들 및 주변기기들과 같은 전자모듈들 간에 통신물을 운반한다.

크기(바이트)	이름	코멘트
1	I2C_프로토콜	페이로드 유형
1	I2C_버전	I²C™ 데이터 링크 프로토콜 버전
2	I2C 길이	전체 I²C™ 데이터 패킷의 길이
1	I2C_기기	송신자의 I²C™ 기기 번호
1	12C-오프셋	페이로드 시작주소
n	확장부	확장용
...	I2C_데이터	페이로드, "프로토콜"에서 정의됨
1	체크섬	계산된 체크섬

표 1 - I²C™ 매체에서 사용되는 헤더

메시지의 데이터 량이 데이터프레임 한계를 초과하는 경우 추가 정보가 헤더구역에 통합된다.

아래의 표 2와 도 1c에서 보인 것처럼, 메시지를 분할하는 것이 요구되는 경우, 메시지가 재조립되는 정확한 순서를 수신용 전자모듈이 식별하도록 하기 위해 헤더에는 데이터 패키지 번호 및 데이터 프래그먼트 번호가 추가로 통합된다.

크기(바이트)	이름	코멘트
1	I2C_프로토콜	페이로드 유형
1	I2C_버전	I²C™ 데이터 링크 프로토콜 버전
2	I2C 길이	전체 I²C™ 데이터패킷의 길이
1	I2C_기기	송신자의 I²C™ 기기 번호
1	I2C_오프셋	페이로드 시작주소
2	12C_패킷_번호	메시지 분할용
2	12C_프래그먼트_번호	메시지 분할용
n	확장부	확장용
...	12C_데이터	페이로드, "프로토콜"에서 정의됨
1	체크섬	계산된 체크섬

표 2 - I²C™ 매체에서 사용되는 헤더

I2C _프로토콜(22a)

이 필드는 I²C™-버스 상에서 전달되는 메시지를 위해 이용되는 프로토콜을 기술한다. 데이터링크층 프로토콜 설정들을 위한 협상 프로토콜 용의 I2C_NEG, OBEX-형 메시징 용의 I2C_OBEX를 포함하는 3가지 프로토콜들이 지금 정의된다. 부가적으로, TCP/IP, HTTP, 및/또는 임의의 생성물 전유(product proprietary) 프로토콜들이 코딩될 수 있다.

I2C _버전(22b)

이 필드는 헤더구역의 버전을 기술한다. 이것은 데이터 패키지들을 위해 이용되는 프로토콜의 버전이 아님에 주의해야 한다. 이 버전은 XXX.YYY 포맷으로 송신되며, 여기서 XXX는 메이저 버전(이진 비호환성)이고 YYY는 마이너 버전(변경물들은 이진 호환성(binary compatible)이 있음)이다. 예를 들면, I2C_버전의 제1옥텟이 "0"이라면, 다음의 조건들, 즉 송신속도가 1000kbps이며, I²C™모드가 단일 마스터이고, 체크섬이 I2C_프로토콜 및 그 이후의 모든 이전 바이트필드들의 합의 최소유효바이트로부터 계산된다는 조건들이 초기에 적용된다. I2C_버전의 제2옥텟이 "0"과는 다르다면, 위에 언급된 조건들이 여전히 적용된다.

I2C _길이(22c)

이 필드는 전체 데이터 패키지의 길이를 담고 있다.

I2C _기기(22d)

이 필드는 데이터 패키지를 보내고 있는 전자모듈의 I²C™ 주소를 포함한다. 이 필드는 데이터 패키지들을 I²C™-버스를 통해 보낼 때 필요한데, I²C™ 규격이 이것을 포함하지 않기 때문이다. 송신 전자모듈에 응답을 되돌려 보내기 위해, 데이터 패키지가 유래하는 전자모듈을 아는 것이 필요하다.

I2C _오프셋(22e)

이 필드는 페이로드 데이터가 데이터 패키지에서 시작하는 위치의 바이트크기 단위의 오프셋을 담고 있다. 대안으로, 이 오프셋 필드는 페이로드 데이터가 데이터 패키지에서 시작하는 주소를 포함한다. 이 필드는 헤더구역에 통합되어 헤더가 역방향 호환성(backward compatible)이 있게 한다. 추가의 필드들이 헤더에 부가되는 경우, 임의의 소프트웨어는 이 소프트웨어가 부가적인 필드들을 알고 있는 경우에도 페이로드 데이터를 보낼 수 있는데, 이 소프트웨어가 오프셋 및 버전 필드에 기초하여 데이터 패키지를 보낼 수 있기 때문이다.

I2C _패킷_번호(22f)

여러 개의 데이터링크프로토콜 메시지들로 분할된 전송프로토콜 메시지들에 대해, 이 필드는 데이터링크 프래그먼트가 속한 전송프로토콜 메시지가 무엇인지를 결정한다.

I2C _ 프래그먼트 _번호(22g)

여러 개의 데이터링크프로토콜 메시지들로 분할된 전송프로토콜 메시지들에 대해, 이 필드는 프래그먼트의 순번을 결정한다.

확장부 (22h)

이 필드는 헤더구역의 추가 확장의 보상을 위해 의도된 것이다. 헤더에는 부가적인 필드들이 장차 필요할 것이다. 이 확장부는 여전히 역방향 호환성이 있는 한 부가될 수 있고, 오프셋 필드는 실제 데이터 패키지가 시작하는 수신 엔티티를 알려줄 것이다.

I2C _데이터(22i)

이 필드는 실제 페이로드를 담고 있다. 이것은 예컨대 OBEX 메시지, IP 패키지 또는 임의의 다른 패키지 포맷일 수 있다.

체크섬 (22j)

체크섬은 메시지 프레임 내의 모든 이전 바이트필드들의 합의 최소유효바이트로서 I²C™-프로토콜 필드 및 그 이후로부터 계산된다.

예

본 발명은 이동통신기기가 I²C™-버스를 통해 그리고 전술한 바와 같은 데이터링크층 구조를 이용하여 기능성 커버와 통신하는 예에 의해 아래에서 설명된다.

도 2는 기능성 커버(52)와 이동통신기기를 위한 데이터링크층 확립 통신으로서 전체가 참조번호 50으로 지정된 통신을 보이고 있다.

기능성 커버(52)는 이동통신기기의 운영체계를 따르는 구성요소이지만, 운영체계에 의해 설계되거나 유지되지는 않는다.

기능성 커버(52)는 기능성 커버(52)의 기능성의 시작과 종료를 제어하고, 구현된 실제 애플리케이션에 의존하여, 정보 등의 위치에 관해 자바(Java)서버에 정보를 제공한다. 자바서버는 이동통신기기에서 돌아가는 표준화된 자바코드 모듈들인 애플리케이션메뉴 미들릿들로부터 시작하기 위한 수단을 제공한다. 그에 더하여, 자바서버는 연결이 요구될 때 접촉되는 기능성 커버의 등록의 통지를 수행하기 위한 수단, 및 연결의 관리와 연계하여 이용되는 기기식별자(devID) 및 객체식별자(objID)와 같은 연결식별자를 저장하기 위한 수단을 제공한다.

미들릿은 예를 들면 사용자 GPS를 나타내는 전역위치지정시스템(GPS) 미들릿일 수 있다. 이 GPS 미들릿은 이동통신기기의 운영체계 소프트웨어의 일부가 아니라는 점에 주의해야 한다.

GPS 미들릿은 GPS 기능성 커버 특징의 "두뇌"이다. 연결이 셋업된 후(즉, 응용층 밑의 모든 층들이 준비가 된 후), 미들릿은 이동통신기기에서 결정을 행하고 일어나는 일을 제어하는 유일한 엔티티이다.

GPS 미들릿은 OTA(over-the-air) 설비들로부터 다운로드되거나 또는 PC 슈트(Suite)를 이용하여 업로드된 미들릿과 마찬가지로 이동통신기기의 파일 시스템에 저장된다.

기능성 커버(52)가 이동통신기기에 연결될 때, 기능성 커버(52)가 인터럽트신호를 생기게 하기(54) 때문에, 하드웨어 인터럽트가 코어서버(56)에 등록된다.

코어서버(56)는 첨부(attachment)인터럽트, 시동(power-up), 커넥터 글리치(glitches), 이동통신기기 활동정지(sleep), 기능성 커버 활동정지, 및 리셋 핸들링과 같은 로우레벨의 기능성 커버에 특이한 문제들을 다룬다.

코어서버(56)는 다른 전자모듈들 또는 칩들을 위한 주소범위들과 같은 모든 I²C™ 전유(proprietary)정보를 포함하고 및 연결된 I²C™ 전자모듈들에 관련한 정보를 브로드캐스트한다.

코어서버(56)는 기능성 커버(52)의 인증을 라이브러리(60)로부터 요구하고(58), 후속하여, 이 라이브러리는 기능성 커버(52)에 요청한다(62). 요청(62)이 적절히 응답되면(64) 라이브러리(60)는 OK신호를 코어서버(56)에 보내고(66), 그 후 코어서버는 매체모듈(70)에 활동을 요구한다(68).

매체모듈(70)은, 코어서버(56)로부터의 요구 하에, 어떤 I²C™ 전자모듈들을 I²C™-버스에 연결할지를 결정할 수 있다.

매체모듈(70)은 데이터링크층 프로토콜을 구현하고, 둘 이상의 I²C™ 하드웨어 포트들을 다룰 수 있다.

매체모듈(70)은 협상요구(72)의 전달과 협상응답(74)의 수신을 통해 기능성 커버(52)와 협상한다. 끝으로, 매체모듈(70)은 활동 응답을 코어서버(56)에 보낸다(76).

도 3은 응용층 통신, 제1연결확립, 그 후의 두 개의 통신예들을 보이고 있다. 도 2를 참조하여 설명된 바와 같은 데이터링크층의 확립 직후, 기능성 커버(52)는 기기식별자 및 객체식별자를 포함하는 등록신호를 자바서버(80)에 보낸다(78). 자바서버(80)는 기기 및 객체 식별자를 단계 82 동안 등록하고 OK신호를 기능성 커버(52)에 보낸다(84).

어떤 시점이 되면 미들릿(86)은 이동통신기기 내에서 활동하게 되고 미들릿(86)은 자바서버(80)에 open() 함수를 요구한다(88). 자바서버(80)는 요구신호를 보냄(90)으로써 기능성 커버(52)에 연결을 개방(open)할 것을 요구한다. 기능성 커버(52)가 OK신호를 자바서버(80)에 제공할 때(92), 자바서버(80)는 open() 함수를 미들릿(86)에 반환한다(94).

이제 미들릿(86)은 send() 함수의 이용을 자바서버에 요구하고(96) 자바서버는 메시지를 포함하는 데이터통지를 기능성 커버(52)에 보내고(98) send() 함수의 결과들을 미들릿(86)에 반환(100)함으로써 데이터를 기능성 커버(52)에 송신할 수 있다.

기능성 커버(52)는 데이터를 미들릿(86)에 보낼 수 있고, 미들릿은 자바서버(82)의 read() 함수를 이용하여 데이터를 수신한다. 기능성 커버(52)는 데이터통지를 자바서버(80)에 보내고(102), 이 데이터통지는 미들릿(86)에 의해 판독된다(104). 이 처리는 요구된 모든 데이터가 미들릿(86)과 기능성 커버(52) 사이에서 충분히 교환되기까지 임의의 수의 사이클들 동안 수행될 수 있다.

도 4는 어떤 미들릿들이 이동통신기기에 설치되어 있는지를 기능성 커버(52)가 어떻게 검사하는 지를 보이고 있다. 기능성 커버(52)는 특정 폴더 내의 미들릿들의 목록을 파일시스템(108)에 요구한다(106). 이어서, 파일시스템(108)은 어떤 미들릿들이 특정 폴더 내에 있는 지를 검사하고 미들릿들의 목록을 기능성 커버(52)에 보낸다(110). 이제 기능성 커버(52)는 미들릿들을 이동통신기기로 푸시하는(push) 것이 필요한지를 결정할 수 있다.

도 5는 기능성 커버(52)로부터 이동통신기기로의 미들릿의 송신을 보이고 있다. 기능성 커버(52)는 미메타입(mimetype) 및 파일명의 정보를 포함하는 SendFile() 함수를 이용하는 것에 의해 미들릿을 디스패처(114)로 보낸다(115). 디스패처(114)는 SendFile 명령어의 수신 하에 OK신호를 기능성 커버(52)에 보내고(116), 그 후 기능성 커버(52)는 도 5에 보인 예에서 하나를 넘는 프래그먼트를 포함하는 파일의 송신을 시작한다. 데이터 패키지 크기는 단편화(fragmentation) 절차들을 이용할 때를 결정한다.

기능성 커버(52)는 파일의 제1프래그먼트를 보내기 위해 SendFragment() 함수를 이용하며(118), 이 프래그먼트는 디스패처(114)에 의해 추가로 파일시스템(122)에 보내진다(120). 파일시스템(122)은 제1프래그먼트의 안전한 수신 하에 제1 OK신호를 디스패처(114)에 보낸다(124). 후속하여, 디스패처(114)는 제1 OK신호를 기능성 커버(52)에 보내고(126), 기능성 커버(52)는 제1 OK신호를 수신하면 파일의 제2세그먼트를 디스패처(114)에 보낸다(128). 마찬가지로, 디스패처(114)는 제2프래그먼트를 파일시스템(122)에 보낸다(130). 파일시스템(122)은 제2프래그먼트의 안전한 수신 하에 제2 OK신호를 디스패처(114)에 보낸다(132). 후속하여, 디스패처(114)는 제2 OK신호를 기능성 커버(52)에 보낸다(134).

명백히, 이 처리는 전자모듈들 간에 전송되는 파일의 크기에 따라 계속될 수 있다.

도 6은 어떠한 사용자 상호작용 없이도 기능성 커버(52)가 어떻게 미들릿을 시작할 수 있는 지를 보이고 있다. 기능성 커버(52)는 자바서버(80)의 함수 호출, LaunchMidlet()을 이용하며(136), 자바서버(80)는 OK신호를 보내고(138) open() 함수를 이용하여 미들릿을 실행한다.

도 7은 어떻게 사용자가 애플리케이션메뉴(140)로부터 미들릿을 시작하는지를 보이고 있다. 사용자는 기능성 커버의 메뉴항목을 클릭하고 애플리케이션메뉴(140)는 자바서버(80)의 LaunchMidlet() 함수 호출을 이용한다(142). 자바서버(80) 는 OK신호를 애플리케이션메뉴(140)에 보내고(144), 후속하여 이 애플리케이션메뉴는 미들릿을 실행한다.

Claims

I²C™-버스에 연결된 복수 개의 전자모듈들 간에 데이터 통신을 제공하기 위한 시스템에 있어서, 상기 복수 개의 전자모듈들 각각은, 계층구조 내에, I²C™ 규격을 따르는 물리층, 데이터 페이로드 유형을 위한 제1헤더필드 및 데이터링크층 버전을 위한 제2헤더필드를 포함하는 데이터링크층, 송신 전자모듈의 주소를 위한 제3헤더필드 및 상기 데이터 패키지의 길이를 위한 제4헤더필드를 포함하는 네트워크/전송 층, 및 데이터 페이로드를 포함하는 데이터 패키지를 전달할 수 있도록 구성된 시스템.
제1항에 있어서, 상기 전자모듈들은 셀, 모바일 또는 위성 전화기와 같은 이동통신기기, 개인휴대정보단말 또는 그 주변기기들을 포함하는 시스템.
제1항에 있어서, 상기 데이터 페이로드 유형은 OBEX, TCP, IP, HTTP 또는 임의의 전유 페이로드 유형을 포함하는 시스템.
제1항에 있어서, 상기 데이터링크층 버전은 이진 비호환성의 메이저 버전 및 이진 호환성의 마이너 버전을 포함하는 시스템.
제1항에 있어서, 상기 데이터 패키지는, 상기 네트워크/전송 층 내에, 상기 데이터 패키지에서의 데이터 페이로드 시작의 결정을 위한 오프셋값 용의 제5헤더필드를 더 포함하는 시스템.
제1항에 있어서, 상기 데이터 패키지는, 상기 네트워크/전송 층 내에, 버퍼링을 위해 상기 데이터 패키지 내의 상기 데이터 페이로드 시작 전에 제6헤더필드를 더 포함하는 시스템.
제1항에 있어서, 상기 데이터 패키지는 데이터 페이로드를 뒤따르는 체크섬 필드를 더 포함하는 시스템.
제1항에 있어서, 상기 데이터 패키지는, 상기 네트워크/전송 층 내에, 데이터 패키지 번호를 위한 제7헤더필드를 더 포함하는 시스템.
제1항에 있어서, 상기 데이터 패키지는, 상기 네트워크/전송 층 내에, 데이터 패키지 프래그먼트 순번을 위한 제8헤더필드를 더 포함하는 시스템.
I²C™-버스에 연결된 복수 개의 전자모듈들 간의 통신을 위한 데이터 패키지에 있어서, 상기 데이터 패키지는, 계층구조 내에, I²C™ 규격을 따르는 물리층 데 이터, 제1헤더필드 내에 데이터 페이로드 유형을 포함하며 제2헤더필드 내에 데이터링크층 버전을 포함하는 데이터링크층 데이터, 및 제3헤더필드 내에 송신 전자모듈의 주소를 포함하며 제4헤더필드 내에 상기 데이터 패키지의 길이를 포함하는 네트워크/전송 층 데이터, 및 데이터 페이로드를 포함하는, 데이터 패키지.
제10항에 있어서, 상기 네트워크/전송 층 내에, 상기 데이터 패키지에서 데이터 페이로드 시작의 결정을 위한 오프셋값을 위한 제5헤더필드를 더 포함하는 데이터 패키지.
제10항에 있어서, 상기 데이터 페이로드 유형은 OBEX, TCP, IP, HTTP, 또는 임의의 전유 페이로드 유형을 포함하는, 데이터 패키지.
제10항에 있어서, 상기 네트워크/전송 층 내에, 버퍼링을 위해 상기 데이터 패키지에서 상기 데이터 페이로드 앞에 제6헤더필드를 더 포함하는 데이터 패키지.
제10항에 있어서, 데이터 페이로드를 뒤따르는 체크섬 필드를 더 포함하는 데이터 패키지.
제10항에 있어서, 상기 네트워크/전송 층 내에, 데이터 패키지 번호를 위한 제7헤더필드를 더 포함하는 데이터 패키지.
제10항에 있어서, 상기 네트워크/전송 층 내에, 데이터 패키지 프래그먼트 순번을 위한 제8헤더필드를 더 포함하는 데이터 패키지.
제10항 내지 제16항 중 어느 한 항에 따른 데이터 패키지를 수신하기에 적합하게 구성된 수신기 유닛.
제10항 내지 제16항 중 어느 한 항에 따른 데이터 패키지를 송신하기에 적합하게 구성된 송신기 유닛.
I²C™-버스에 연결된 복수 개의 전자모듈들 간에 데이터 통신을 확립하기 위한 방법에 있어서, 상기 복수 개의 전자모듈들 각각은 I²C™ 규격을 따르는 물리층을 계층구조 내에 포함하는 데이터 패키지를 전달하고, 상기 방법은 상기 데이터 패키지 내의 데이터링크층 내에는 데이터 페이로드 유형을 위한 제1헤더필드와 데이터링크층 버전을 위한 제2헤더필드를 제공하는 단계, 상기 데이터 패키지 내의 네트워크/전송 층 내에는 송신 전자모듈의 주소를 위한 제3헤더필드와 상기 데이터 패키지의 길이를 위한 제4헤더필드를 제공하는 단계, 및 상기 데이터 패키지 내에 데이터 페이로드를 제공하는 단계를 포함하는 방법.
I²C™-버스에 연결된 복수 개의 전자모듈들 간에 데이터 통신을 확립하기에 적합한 데이터처리기에서 프로그램을 실행할 때 다음의 단계들을 수행하기에 적합한 코드를 포함하는 컴퓨터 프로그램에 있어서, 상기 복수 개의 전자모듈들 각각은 I²C™ 규격을 따르는 물리층을 계층구조 내에 포함하는 데이터 패키지를 전달하고, 상기 프로그램은, 상기 데이터 패키지 내의 데이터링크층 내에는 데이터 페이로드 유형을 위한 제1헤더필드와 데이터링크층 버전을 위한 제2헤더필드를 제공하며, 상기 데이터 패키지 내의 네트워크/전송 층 내에는 송신 전자모듈의 주소를 위한 제3헤더필드와 상기 데이터 패키지의 길이를 위한 제4헤더필드를 제공하고, 상기 데이터 패키지 내에 데이터 페이로드를 제공하는 컴퓨터 프로그램.