KR100787850B1 - 고레벨 서비스 구성을 갖는 인터프로세서 통신 프로토콜 - Google Patents

고레벨 서비스 구성을 갖는 인터프로세서 통신 프로토콜 Download PDF

Info

Publication number
KR100787850B1
KR100787850B1 KR1020067008545A KR20067008545A KR100787850B1 KR 100787850 B1 KR100787850 B1 KR 100787850B1 KR 1020067008545 A KR1020067008545 A KR 1020067008545A KR 20067008545 A KR20067008545 A KR 20067008545A KR 100787850 B1 KR100787850 B1 KR 100787850B1
Authority
KR
South Korea
Prior art keywords
ipc
service
server
client
component
Prior art date
Application number
KR1020067008545A
Other languages
English (en)
Other versions
KR20060080242A (ko
Inventor
차르벨 카완드
진 카완드
지-한 린
빈 리우
지안핑 더블유. 밀러
친 피. 웡
Original Assignee
모토로라 인코포레이티드
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 모토로라 인코포레이티드 filed Critical 모토로라 인코포레이티드
Publication of KR20060080242A publication Critical patent/KR20060080242A/ko
Application granted granted Critical
Publication of KR100787850B1 publication Critical patent/KR100787850B1/ko

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00Digital computers in general; Data processing equipment in general
    • G06F15/16Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/12Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00Digital computers in general; Data processing equipment in general
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/327Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the session layer [OSI layer 5]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Theoretical Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Computer Security & Cryptography (AREA)
  • Health & Medical Sciences (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Software Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

IPC 네트워크(1900)는 서비스들의 동적 구성을 허용한다. IPC 클라이언트(1902)는 예를 들어, 새로운 포토 서비스와 같은 서비스를 요청하고, 어떠한 서비스 컴포넌트들이 상기 서비스를 포함하는지를 상기 IPC 네트워크에 알린다. 상기 IPC 서버(1908)는, 상기 IPC 클라이언트(1902)가 상기 서비스를 이용하기 위해 진행하도록 허용되기 전에, 요구된 서비스 컴포넌트들(1914, 1916) 모두가 상기 IPC 네트워크(1900)에 등록될 때까지 기다린다. 서비스들의 동적 구성은, 상기 IPC 네트워크(1900)에서 동작하는 클라이언트/컴포넌트로 하여금 상기 네트워크(1900) 내에서 동작하는 애플리케이션들 사이의 인터프로세서 통신들에 영향을 미치지 않게 서비스 용도들을 변화시키도록 한다. 또한, 상기 IPC 네트워크(1900)는 상기 새로운 서비스를 동적으로 학습하고, 상기 네트워크(1900) 내의 상기 서비스의 이용도를 식별할 수 있다.
인터프로세서 통신, IPC 네트워크, 통신 프로토콜

Description

고레벨 서비스 구성을 갖는 인터프로세서 통신 프로토콜{Interprocessor communication protocol with high level service composition}
본 발명은 일반적으로 전자 기기 분야에 관한 것으로, 특히 고레벨 서비스 구성을 갖는 인터프로세서 통신(IPC: InterProcessor Communication) 프로토콜/네트워크에 관한 것이다.
대부분의 전자 시스템들은 그 시스템을 형성하는 하드웨어 및 소프트웨어와 같은 다수의 네트워크화된 요소들(컴포넌트들)을 포함한다. 대부분의 시스템들에 있어서, 서로 다른 네트워크화된 요소들 그 자체들 사이에서뿐만 아니라 네트워크화된 요소를 형성하는 서로 다른 컴포넌트들 사이에서 통신에 대한 책임이 있는 계층이 존재한다. 이러한 계층은 전형적으로 인터프로세서 통신(IPC) 계층으로 언급된다.
몇 가지 프로토콜들이 인터프로세서 통신을 취급하기 위해 최근 수년간 도입되어 왔다. IPC 제품의 일례는 호스트-투-PCI 브리지(Host-to-PCI bridge)와, 동적 랜덤 액세스 메모리(DRAM) 제어기와, 데이터 경로 및 AGP(Accelerated Graphics Port) 인터페이스를 집적하는 PCI AGP 제어기(PAC)이다. IPC 제품의 또 다른 예는 OMAPTM 플랫폼들이다. 이러한 플랫폼들 중 어느 것도 하드웨어 레벨 이상의 어떠한 지원도 제공하지 않으며 더 낮은 레벨 컴포넌트 또는 채널 레벨들(물리적 계층)에서 설계 유동성을 거의 제공하지 않는다.
예를 들어, PAC 플랫폼들은 폐쇄된 구조들이며, 개발자들에게 접근하기 쉽지 않은 IPC 코드를 통해 운영 시스템의 TAPI 계층으로 매립된다. 그러므로, 이러한 플랫폼들은 컴포넌트 레벨들로 연장되지 않으며, 또한 IPC 리소스들의 동적 할당, 하드웨어 지원 성능, 또는 멀티 노드 라우팅 등에 대해 허용하지 않는다. 때때로, 시스템의 컴포넌트에 의한 사용을 위해 다른 유형의 서비스들을 함께 결합할 필요성으로, 결합된 서비스를 형성하기 위해 서로 다른 서비스들(예컨대, 카메라 및 JPEG 서비스)을 동적 결합을 허용할 수 있는 IPC 네트워크는 매우 이로울 수 있다. 또한, 동일한 서비스의 다른 "용도들(destinations)"을 다룰 수 있는 능력 또한 IPC 네트워크에서 매우 이로울 수 있으며, 오디오 서비스의 용도는 IPC 네트워크에 결합된 두 개의 다른 프로세서들에 대해 다를 수 있다. 상기한 바와 같이, 종래 기술에서의 이러한 단점들 중 일부에 대한 해결책을 제공할 수 있는 IPC 프로토콜에 대한 필요성이 본 기술 분야에 존재한다.
독창적인 본 발명의 특징들은 첨부된 특허청구범위 내 특징을 통해 설명된다. 본 발명은 몇 가지 도면들에서 유사한 참조 번호들이 유사한 요소들을 식별하는 첨부된 도면들과 관련한 다음의 기술을 참조로 하여 가장 잘 이해될 수 있다.
도 1은 본 발명의 실시예에 따른 IPC 네트워크를 도시한 도면.
도 2는 본 발명의 실시예에 따른 IPC 스택을 도시한 도면.
도 3은 본 발명의 실시예에 따른 IPC 컴포넌트 IPC 할당을 도시한 도면.
도 4는 본 발명의 실시예에 따른 주요 IPC 테이블들을 도시한 도면.
도 5는 본 발명의 실시예에 따른 채널 할당을 도시한 도면.
도 6은 본 발명의 실시예에 따른 IPC 클라이언트 초기화 루틴 동안 포함되는 단계들을 강조하는 도면.
도 7은 본 발명의 실시예에 따른 IPC 클라이언트 초기화 동안 포함되는 단계들을 강조하는 또 다른 도면.
도 8은 본 발명의 실시예에 따른 IPC 캡슐화의 제 1 레벨을 강조하는 도면.
도 9는 본 발명의 실시예에 따른 IPC 컴포넌트 초기화 동안 취해지는 단계들을 강조하는 도면.
도 10은 본 발명의 실시예에 따른 컴포넌트 초기화 동안 취해지는 단계들을 강조하는 차트.
도 11은 본 발명의 실시예에 따른 IPC 클라이언트 및 IPC 서버 사이에서 IPC 데이터의 전달을 도시한 도면.
도 12는 본 발명의 실시예에 따른 IPC 데이터 헤더를 도시한 도면.
도 13은 본 발명의 실시예에 따른 IPC 데이터 요청 동안 취해지는 단계들을 도시한 도면.
도 14는 본 발명의 실시예에 따른 IPC 네트워크를 도시한 도면.
도 15는 본 발명의 실시예에 따른 라디오 통신 디바이스와 같은 전자 디바이스를 도시한 도면.
도 16 및 도 17은 본 발명의 실시예에 따른 외부로 향하는 스트리밍을 도시한 도면.
도 18은 본 발명의 실시예에 따른 내부로 향하는 스트리밍을 도시한 도면.
도 19는 본 발명의 실시예에 따른 IPC 네트워크를 도시한 도면.
도 20은 본 발명의 실시예에 따른 서비스 구성을 수행하는 단계들 중 일부를 강조하는 흐름도.
본 명세서가 신규한 것으로 간주되는 본 발명의 특징들을 규정하는 특허청구범위를 결정하는 동안, 본 발명은 도면들과 관련하여 다음의 기술을 고려하여 더욱 잘 이해될 것이다.
본 발명의 IPC는 서로 통신하기 위한 시스템에서 동작하는 서로 다른 프로세서들에 대해 필요로 되는 지원을 제공한다. 예를 들어, 애플리케이션 프로세서(AP 및 기저대역 프로세서(BP)를 포함하는 라디오 통신 디바이스에서 사용하기 위한 듀얼 프로세서(또는 멀티 프로세서) 라디오 구조에 있어서, IPC는 효율적인 방식으로 서로 통신하기 위해 프로세서들에 대해 필요로 되는 지원을 제공한다. IPC는 AP 또는 BP의 설계에 대한 어떠한 제약들도 강요하지 않는 이러한 지원을 제공한다.
IPC는 상기 2 가지가 공통 운영 시스템 및 메모리를 공유하는 동일한 프로세 서 코어상에서 실제로 작동하는 것과 같이 함께 존재하고 동작하도록 인터프로세서 통신 스택으로 IPC를 채택하는 어떠한 프로세서를 허용한다. 기준이 되는 통신 디바이스들에서 다중 프로세서들의 사용을 통해, 본 발명의 IPC는 서로 다른 프로세서들 사이에 신뢰성 있는 통신을 제공한다.
IPC 하드웨어는 IPC 네트워크에서 서로 다른 프로세서들과 함께 결합하는 물리적 접속을 제공한다. 데이터 패킷들은 본 발명의 일 실시예에서 비동기적으로 서로 다른 호스트들 사이에서 전송되는 것이 바람직하다. IPC 네트워크에 접속되는 프로세서들은 통계적으로 또는 동적으로 할당된 물리적 및 논리적 어드레스들(예컨대, IPC 어드레스들)을 갖는다. 또한, 데이터 패킷들이 본 발명의 일 실시에 따라 IPC 네트워크 내에서 어떠한 방향으로 흐를 수 있기 때문에, 그들이 도달하려 하는 프로세서의 목적지 어드레스를 전달할 필요가 있다. 패킷들은 또한 종래의 CRC(Cyclic Redundancy Check) 테크닉들을 사용하여 에러들에 대해 검사되는 것이 바람직하다. 본 발명의 IPC 네트워크의 네트워크 활동들이 송신 제어 프로토콜/인터넷 프로토콜(TCP/IP) 네트워크와 같은 IP 전송 계층들을 사용하는 인터넷 네트워크 상에서 발견되는 것들에 따른 몇 가지 유사한 것들을 가질지라도, 본 발명의 IPC는 TCP/IP 네트워크에서와 같이 게이트웨이들을 통해 더 작은 네트워크들로 분할되지 않는다.
도 1을 참조하면, 본 발명의 실시예에 따른 IPC 네트워크(100)가 도시되어 있다. IPC 네트워크(100)는 복수의 IPC 클라이언트들(102-106)과, 공유된 메모리(110)와 같은 서로 다른 IPC 물리적 링크들을 사용하는 IPC 클라이언트들(102-106) 에 연결되는 IPC 서버(108)와, 범용 비동기식 수신기/송신기(UART)(112)와, 일부 예시적인 예들과 같은 범용 직렬 버스(USB)(114)를 포함한다. 본 발명의 IPC를 통해, IPC 클라이언트(102-106)가 역할들을 스위칭하기 위해 최신 IPC 서버(108)와 협상할 수 있다. IPC 클라이언트(102-106)가 IPC 서버가 되고 새로운 IPC 서버가 되도록 협상하는 경우, 남아있는 IPC 클라이언트들의 모두가 IPC 서버 내 변화가 주어진 서버의 IP 어드레스를 변경하도록 지시된다.
도 2에서는, 본 발명의 실시예에 따른 IPC 서버(108)(또는 IPC 클라이언트들 102-108)의 IPC 스택(200)을 도시하고 있다. IPC 스택(200)은 운영 시스템(OS) 하에서 통합되고, 컴포넌트 트래픽의 인터프로세서 통신 요구들에 대한 지원을 제공하도록 설계된다. IPC 스택은 다음의 3개 주요 계층들로 구성된다.
(1). IPC 프리젠테이션 매니저(202)-이 계층은 서로 다른 시스템 컴포넌트들(예컨대, 소프트웨어 스레드들) 사이에서 서로 다른 데이터 유형들을 해석하기 위해 사용된다.
(2). IPC 세션 매니저(204)-이 계층은 시스템 컴포넌트들의 모두와 IPC 스택 사이에서 모든 착신/발신 IPC 트래픽(incoming/outgoing IPC traffic)에 대한 중앙 저장소이다. IPC 세션 매니저(204)는, IPC 컴포넌트들에 참여하는 컴포넌트 ID들의 할당과, IPC 데이터가 캡슐화될 필요가 있는지를 결정하는 것과, IPC 데이터의 라우팅, IPC 트래픽의 종료와, IPC 프로세서들에 대한 플레이스 홀더(place holder)와, IPC 어드레스들을 제공하고, IPC 클라이언트들에 할당 및 인증하는 등의 몇 가지 기능들을 갖는다.
IPC 전송 계층(208)-IPC 세션 매니저(계층)(204)에 위치되고, IPC 전송 계층(208)은 서로 다른 프로세서들 사이에서 IPC 데이터를 전송할 목적으로 매우 기초적인 주기적 덧붙임 검사를 제공한다. 추가로, IPC 전송 계층(208)은 IPC 네트워크(100)에 대한 그들의 최종 목적지들로 IPC 메시지들을 라우팅할 책임이 있다. 전송 계층의 라우팅 기능은 IPC 서버들 상에서만 인에이블된다.
IPC 라우터 블록(210)-목적지 컴포넌트(도시되지 않음)로 IPC 데이터를 전송한다. 착신 IPC 메시지들은 다른 것들 사이에서 발신자 컴포넌트 ID, 오디오 및 모뎀과 같은 IPC 메시지 연산코드들을 전달한다. 본 발명의 실시예에 따라 독특한 연산코드가 IPC 네트워크에 연결되는 오디오 및 모뎀과 같은 각각의 컴포넌트/소프트웨어 스레드(예를 들어, 도 5의 502 참조)에 할당된다. IPC 세션 매니저(204)는 올바른 컴포넌트(들)에 IPC 데이터를 전송하도록 라우터 블록(210)에 의존한다.
(3). 디바이스 인터페이스 계층(206)-IPC 물리적 논리적 IPC 채널들을 관리하는데 책임이 있다. 그 주요 기능은 스택 IPC가 독립적인 하드웨어가 되도록 완전히 IPC 하드웨어를 제거하는 것이다. 디바이스 인터페이스 계층(206)은 IPC 논리 채널들의 모두를 지원하기 위해 낮은 IPC 링크의 물리적 대역폭을 관리한다. 착신 경로에 있어서, 디바이스 인터페이스 계층(206)은 서로 다른 물리적 채널들(110-114)로부터 데이터를 가져오고, 이를 IPC 스택의 나머지에 건네준다. 발신 경로에 대해, 디바이스 인터페이스 계층(206)은 적절한 물리적 채널들 상으로 IPC 논리 채널들을 전송함으로써 데이터 로딩을 관리한다. 디바이스 인터페이스 계층(206)은 또한 IPC 하드웨어에 연결 IPC 패킷들을 전송하기 이전에 동일한 IPC 채널에 속하 는 연결 IPC 패킷들을 취급한다. 채널 요구들은 IPC 세션 매니저(204) 및 IPC 디바이스 인터페이스 계층(206) 사이에서 미리 협상된다. 디바이스 인터페이스 계층(206)은 IPC 클라이언트(102-106)에 디바이스 인터페이스를 차례로 제공하는 하드웨어 포트들을 제공한다.
도 3을 참조하면, IPC 컴포넌트 ID 할당 루틴이 도시되어 있다. IPC 통신에 참여하길 원하는 어떠한 새로운 컴포넌트는 (예컨대, 세션 매니저 204와 같은) IPC 세션 매니저로부터 단계(302)에서 IPC 식별 번호(ID)를 우선적으로 요청함으로써 참여해야한다. 그에 따라 로컬 세션 매니저(예컨대, 컴포넌트가 연결되는 클라이언트에 위치된 세션 매니저)는 새로운 IPC 컴포넌트들의 IPC 서버의 세션 매니저에게 경고할 것이고, 컴포넌트 ID 할당은 단계(304)에서 제공될 것이다. 본 발명의 실시예에 따라, 컴포넌트 ID들은 동적이며 세션 매니저(예컨대, 서버의 세션 매니저)에 의해 재할당될 수 있다. 주요 IPC 서버 위치는 주요 AP 상에 있을 가능성이 매우 높다. 각각의 IPC 노드는 독특한 IPC 노드 ID를 갖는 것이 바람직하며, 세션 매니저는 각각의 참여 IPC 노드에 대한 다음의 정보를 그의 데이터베이스에서 유지할 것이다.
- IPC 노드 유형: 예를 들어, 특정한 BP 또는 AP, 무선 근거리 네트워크(WLAN) AP 등.
- IPC 어드레스: IPC 노드의 IPC 어드레스.
- 데이터 유형: IPC 노드의 데이터 유형.
- 연산코드 리스트: 이것은 컴포넌트들이 예약된 모든 IPC 메시지 연산코드 들의 리스트이다.
- 컴포넌트 ID들: 모든 컴포넌트 ID들의 리스트.
이제 도 4를 참조하면, 모든 주요 IPC 테이블들에 따른 IPC가 도시되어 있다. 동적 라우팅 테이블(402)은 노드 유형, IPC 어드레스/포트 # 정보, 데이터 유형, 및 예약 리스트를 포함한다. 컴포넌트 라우팅 테이블(404)은 각각의 특정한 연산코드에 예약되는 모든 컴포넌트들 및 연산코드 정보를 링크하는 정보를 포함한다. 마지막으로, 채널 리소스 테이블(406)은 물리적 채널 ID들과 각각의 채널 ID를 링크하는 것을 포함한다.
도 5에서는, 본 발명의 실시예에 따른 IPC 스택이 소프트웨어 스레드(예컨대, 오디오 등)와 같은 컴포넌트에 대해 IPC 채널을 제공하는 방법을 도시한 블록도이다. 컴포넌트(502)는 우선적으로 단계(504)에서 IPC 채널을 요청한다. 도 5에 도시된 세션 매니저는 규정된 API를 사용하여 단계(506)에서 디바이스 계층과 컴포넌트의 요청을 협상한다. 디바이스 계층(디바이스 인터페이스)은 그 후에 데이터 채널(508)과 같은 하드웨어 리소스들을 요청한다. 상기 요청에 응답하여 도 5에 도시된 세션 매니저는 단계(510)에서 요청자에게 IPC 채널을 인가한다. 컴포넌트(502)는 다음으로 할당된 채널(508) 상에 데이터를 전송한다. 디바이스 계층은 그 후에 IPC 네트워크에 데이터를 포워딩한다. 논리적 물리적 채널 ID들의 맵핑은 IPC 디바이스 인터페이스의 기능이다.
이제 도 6을 참조하면, IPC 클라이언트 초기화에서 제 1 단계는 IPC 클라이언트(602) 및 IPC 서버(604) 사이에서 등록 요청(단계 606)을 전송하는 것이다. IPC 서버(604)는 그 후에 단계(608)에서 IPC 클라이언트(602)를 통한 요청을 인증한다. 이것은 IPC 클라이언트로 IPC 어드레스를 전송하고 단계(610)에서 등록을 완료하기 이전이다. IPC 클라이언트의 세션 매니저는 단계(612)에서 IPC 서버로 그의 동적 라우팅 테이블의 카피를 전송한다.
IPC 클라이언트 초기화 프로세스 동안 취해지는 보다 상세한 단계들은 도 7에 도시되어 있다. (세션(클라이언트)으로 테이블에 도시된) 클라이언트 세션 매니저는 단계(702)에서 (세션(서버)으로 테이블에 도시된) IPC 서버의 세션 매니저에게 구성 요청을 전송한다. 단계(704)에서 인증은 IPC 서버의 세션 매니저에 의해 요청된다. IPC 클라이언트와 IPC 서버 사이의 인증은 그 후에 단계(706)에서 수행된다.
구성 요청에서의 파라미터들은 노드 유형 및 데이터 유형을 포함한다. 단계(702)에서의 구성 요청에 응답하는 세션 서버는 요청자에게 IPC 어드레스를 할당한다. 또한 사람이 존재하지 않는 경우 요청자에 대한 동적 라우팅 테이블을 준비한다. 그 후에 단계(708)에서 구성 표시를 요청자에게 전송한다. 구성 표시 파라미터들은 서버의 IPC 어드레스 및 클라이언트의 새롭게 할당된 IPC 어드레스를 포함한다.
구성 표시를 수신하는데 응답하여, 세션 클라이언트에 첨부된 컴포넌트들은 클라이언트의 세션 매니저로부터 제어/데이터를 요청할 수 있다. 세션 클라이언트는 그 후에 단계(710)에서 세션 서버에 컴포넌트 표시 확인 메시지를 전송한다. "구성 표시 확인(configuration indication confirm)" 메시지는 어떠한 파라미터들 도 갖지 않는다. 구성 표시 확인 메시지 수신에 따라 단계(710)에서 메시지를 확인하고, 세션 서버는 새롭게 구성된 세션 클라이언트에서 IPC 스트림들을 개시할 수 있다. 세션 서버는 그 후에 단계들(712, 714)에서 세션 클라이언트들에 구성 업데이트 메시지들을 전송한다. 이는 도 7에서 도시된 세션 클라이언트들 모두 (도시되지 않은) 그들 각각의 동적 라우팅 테이블들을 업데이트하고, 단계(716, 718)에서 세션 서버에 구성 업데이트 확인 메시지를 전송하도록 한다. 구성 업데이트 확인 메시지들을 수신에 따라, 세션 서버는 업데이트된 모든 IPC 참여자들을 확인한다.
패킷이 IPC 세션 매니저에 의해 수신될 때, 소스 컴포넌트 ID와, 목적지 ID와, 채널 ID와, BP 또는 AP의 유형을 포함하는 데이터를 형성하게 된다. IPC 세션 매니저는 목적지 ID가 삽입되지 안은 경우에 목적지 컴포넌트 ID를 추가할 것이다. IPC 세션 매니저는 또한 IPD 어드레스를 삽입할 것이다. IPC 세션 매니저는 수신된 메시지 연산코드에 기초하여 목적지 ID를 발견한다. 목적지 ID는 룩업 테이블에 기초한다. 이러한 룩업 테이블은 컴포넌트가 새로운 IPC 메시지 연산코드를 예약하는 각각의 시간에 동적으로 업데이트된다(예컨대, 오디오 컴포넌트는 IPC 세션 매니저에 요청을 전송함으로써 오디오 메시지들을 예약한다).
도 8에서는, 본 발명의 실시예에 따른 컴포넌트와 그 IPC 세션 매니저 사이에서 일반적 목적지 ID 발견 시퀀스 동안의 이벤트들의 시퀀스가 도시되어 있다. 단계(802)에 있어서, 컴포넌트는 그것의 소스 ID(그러나 목적지 ID가 아닌)와, 목적지 BP 또는 AP의 유형과, 헤더 및 데이터를 포함하는 IPC 데이터를 전송한다. 단계(804)에서, IPC 세션 매니저는 대응하는 동적 라우팅 테이블을 룩업하고 정확한 목적지 어드레스를 찾기 위해, IPC 데이터 헤더 연산코드와 목적지 BP 또는 AP의 유형을 조사한다. 단계(806)에서, IPC 세션 매니저는 컴포넌트의 IPC 어드레스를 삽입하고 그것을 디바이스 계층에 내려 전송한다.
도 9에서는 IPC 컴포넌트 초기화 동안 취해지는 전형적인 단계들이 도시되어 있다. BP가 도 9에 도시된 IPC 서버에 의해 구성되면, 그것은 컴포넌트(902)와 같은 컴포넌트가 서로 다른 서비스들을 예약하도록 허용한다. 컴포넌트들은 단계(904)에서 오디오, 비디오 등과 같은 기능들로 그것들을 예약할 것이다. 컴포넌트 예약 정보는 그 후에 (ID가 아직 할당되지 않은 경우) 컴포넌트 ID 생성들과, 특정한 IPC 어드레스에 대한 동적 라우팅 테이블의 생성 또는 업데이트를 위해 IPC 세션 매니저에 전송된다(단계 906). 단계(908)에서는 세션 매니저가 단계(906)로부터의 정보를 통해 IPC 서버를 업데이트한다. 동적 라우팅 테이블의 구성은 IPC 클라이언트로 IPC 서버에 의해 단계(912)에서 전송된다. 서버가 경고를 받으면, 새로운 동적 라우팅 테이블 업데이트들은 단계(910)에서 모든 참여 프로세서들로 방송된다.
동일한 컴포넌트 초기화 프로세스는 컴포넌트 (클라이언트)(1002)와, 클라이언트 세션 매니저(1004)로도 알려진 세션 (클라이언트) 및 서버 세션 매니저(1006)로도 알려진 세션 (서버) 사이에 제공된다. 단계(1008)에서 컴포넌트 구성 요청은 컴포넌트 (클라이언트)에 의해 전송된다. 요청에 응답하여, 클라이언트 세션 매니저(1004)는 그것의 디바이스 계층(도시되지 않음)과 논리적 채널을 협상한다. 클라이언트 세션 매니저(1004)는 또한 컴포넌트 ID를 할당하고, 그것의 동적 라우팅 테 이블(도시되지 않음)에 새로운 연산코드를 추가한다. 단계(1010)에서, 클라이언트 세션 매니저(1004)는 파라미터들로 컴포넌트 ID 및 채널 ID를 포함하는 구성 응답을 전송한다. 구성 응답에 응답하여, 컴포넌트 (클라이언트)(1002)는 클라이언트의 세션 매니저(1004)로부터 그것의 ID 및 채널 ID를 수신한다.
클라이언트 세션 매니저(1004)가 단계(1008)에서 구성 요청에 단계(1010)에서 응답하면, 클라이언트 세션 매니저(1004)는 세션 서버(1006)에 단계(1012)에서 구성 업데이트 요청을 전송한다. 구성 업데이트 요청에 대한 파라미터들은 동적 라우팅 테이블에서 만들어진 어떠한 새로운 변화들이다. 세션 매니저는 그 IPC 어드레스에 대한 동적 라우팅 테이블을 업데이트한다. 단계(1016)에서 서버 세션 매니저(1006)는 그 후에, 그것이 단계(1014)에서 구성 업데이트 표시를 IPC 클라이언트에 전송하는 동안 구성 업데이트를 모든 IPC 클라이언트들에 전송한다. 서버의 세션 매니저(1006)는 IPC 서버가 전송된 변화들을 통해 그것의 라우팅 테이블을 업데이트한 것을 확인한다.
파라미터(들)로 동적 라우팅 테이블들을 포함하는 단계(1016)의 단계(1016)의 구성 업데이트 메시지에 있어서, 세션 서버(1006)는 동적 라우팅 테이블들을 업데이트하고, 단계(1018)에서 구성 업데이트 확인 메시지를 전송한다. 세션 서버(1006)는 그 후에 모든 IPC 참여자들이 업데이트된 것을 확인한다.
IPC 세션 매니저는 착신 및 발신 IPC 패킷들의 라우팅 경로를 결정한다. 발신 패킷의 라우트는 컴포넌트의 IPC 어드레스에 의해 결정된다. 목적지 어드레스가 로컬 프로세서의 그것으로 발견되는 경우, 운영 시스템(OS)으로의 IPC의 맵핑은 세 션 매니저 내에서 수행된다. 목적지 어드레스가 로컬 IPC 클라이언트에 대해 존재하는 것으로 발견되는 경우, 패킷은 추가적인 프로세싱(예컨대, 캡슐화)을 위해 IPC 스택으로 전송된다. 목적지 컴포넌트가 IPC 패킷을 전송하는 컴포넌트로 동일한 프로세서상에 위치되는 경우, 어떠한 캡슐화도 요구되지 않으며 패킷은 통상적인 OS 메시지 호출(예컨대, 마이크로소프트 메시지 큐 등)을 통해 건네진다는 것의 주의한다. 이러한 방식에 따라 컴포넌트들은 그것들의 메시지 입력 방식들을 수정하는데 대해 고민할 필요가 없다. 그 대신에 그것들은 단지 OS 특정 설계로부터 IPC 호출로 그것들의 메시지 포스팅 방법들을 변경시킬 필요가 있다.
착신 패킷들에 대해, 메시지의 목적지 어드레스가 IPC 서버의 것과 같지 않은 경우, 착신 패킷들은 적절한 IPC 클라이언트로 라우팅된다. 착신 패킷들의 라우팅은 IPC 서버의 세션 매니저에 의해 취급된다. 다른 방식으로, 메시지는 컴포넌트 목적지 ID가 유효한 컴포넌트 ID 또는 OXFF로 세팅되는지의 여부에 의존하여 올바른 컴포넌트 또는 컴포넌트들로 포워딩된다.
IPC 라우터 블록은 목적지 컴포넌트에 IPC 데이터를 전송한다. 착신 IPC 메시지들은 다른 것들 사이에서 오디오, 모뎀 등에 대한 것들과 같은 IPC 메시지 연산코드들 및 발신자 컴포넌트 ID를 전달한다. IPC 세션 매니저는 올바른 컴포넌트(들)에 IPC 데이터를 전송하기 위해 그것의 컴포넌트 라우팅 테이블에 의존한다. 동적 라우팅 테이블 및 컴포넌트 라우팅 테이블 모두 IPC 서버/클라이언트에 의해 업데이트된다.
파워-업 동안, 각각의 컴포넌트는 IPC 컴포넌트 ID를 획득하기 위해 그의 세 션 매니저와 함께 그 자신을 등록해야 한다. 추가로, 또한 오디오, 모뎀 등과 같은 착신 IPC 메시지들을 예약해야 한다. 이러한 정보는 IPC 세션 매니저에 의해 사용하기 위한 컴포넌트 라우팅 테이블에 저장된다.
컴포넌트(1102)가 도 11에 도시된 바와 같이 단계(1104)에서처럼 IPC 세션 매니저에 그의 데이터 요청을 전송할 때, 목적지 IPC 노드(예컨대, BP)에 대해 검사가 이루어진다. IPC 노드가 IPC 메시지 연산코드를 지원하지 않는 경우, 에러는 컴포넌트(1102)로 복귀된다. 에러 응답 이외에, IPC 세션 매니저는 그 특정한 연산코드를 수신할 수 있는 모든 IPC 노드들의 업데이트를 복귀시킨다. IPC 노드(들)의 어느 것으로 그것이 메시지를 방향 지정할지 결정하는 것은 컴포넌트에 달려 있다. IPC 세션 매니저(1106)는 목적지 컴포넌트가 로컬 프로세서가 아닌 IPC 네트워크에 위치된다는 것을 세션 매니저가 결정하는 경우 데이터가 IPC 네트워크상에 전송되기 이전에 IPC 헤더 정보와 함께 데이터를 캡슐화하기 위해 진행할 것이다.
도 12에서는 본 발명의 실시예에 따른 IPC 데이터 헤더(1202)가 도시되어 있다. 헤더는 IPC 라우터에 의해 제공되는 소스 및 목적지 IPC 어드레스들과, 소스 포트와, 목적지 포트와, IPC 전송에 의해 제공되는 길이 및 체크섬 정보와, 세션 매니저에 의해 제공되는 소스 IPC 컴포넌트 및 목적지 IPC 컴포넌트를 포함한다. 메시지 연산코드, 메시지 길이, 및 IPC 데이터는 컴포넌트(1204)에 의해 제공된다.
본 발명의 실시예에 따른 전형적인 IPC 데이터 요청이 도 13에 도시되어 있다. 단계(1302)에서는 컴포넌트가 업데이트 요청을 전송한다. 컴포넌트 업데이트 파라미터들은 노드 유형 및 연산코드를 포함하는 것이 바람직하다. 컴포넌트는 그 것의 목적지 연산코드를 지원하는 노드 유형들에 대해 검색한다. 노드 유형이 OxFF와 같은 경우, 세션 매니저는 모든 IPC 참여자들에 대한 모든 노드 테이블들로 컴포넌트 정보를 전송하기 위해 진행한다. 연산코드 필드가 0xFF와 같은 경우, 세션 매니저는 특정 노드 유형에 속하는 연산코드 리스트를 컴포넌트에 전송하기 위해 진행한다. 반대로, 연산코드가 특정한 값을 갖는 경우, 세션 매니저는 노드 유형이 특정한 연산코드를 지원하거나 지원하지 않는지의 여부에 대응하여 사실 또는 거짓 값을 전송하도록 진행한다.
단계(1304)에서는 컴포넌트 업데이트 정보가 컴포넌트로 전송된다. 노드 유형이 0xFF와 같은 경우, 노드 테이블들은 컴포넌트로 복귀된다. 연산코드 필드가 0xFF와 같은 경우, 연산코드들의 리스트는 컴포넌트로 복귀된다. 그러나, 연산코드가 특정 값인 경우, 사실 또는 거짓 메시지가 복귀된다. 단계(1306)에서는 컴포넌트 데이터 요청이 이루어진다. 컴포넌트 데이터 요청에 대한 파라미터들은 노드 유형, IPC 메시지 연산코드, IPC 메시지 데이터, 채널 ID, 및 컴포넌트 ID를 포함한다. 컴포넌트 데이터 요청에 있어서, 세션 매니저는 연산코드가 지원되는지의 여부를 결정하기 위해 노드 유형을 검사한다. 노드 유형이 연산코드를 지원하지 않는 경우, 컴포넌트 업데이트 표시는 단계(1308)로 전송된다. 그러나, 노드 유형이 연산코드를 지원하지 않는 경우, 데이터 요청은 단계(1310)에서 디바이스 계층으로 전송된다. 데이터 요청 파라미터들은 IPC 메시지, 채널 ID, 및 IPC 헤더를 포함한다.
디바이스 계층은 채널 ID에 기초하여 데이터 요청 메시지를 전송하도록 스케 줄링한다. 디바이스 계층은 포트 # 헤더 정보에 기초하여 IPC 하드웨어를 선택한다. 데이터가 맡겨지면, 데이터 확인 메시지는 단계(1312)에서 세션 매니저로 전송된다. 단계(1314)에서는 세션 매니저가 컴포넌트에 컴포넌트 데이터 확인 메시지를 전송하도록 진행한다. 컴포넌트는 더 많은 IPC 메시지들을 전송하기 이전에 확인을 기다릴 수 있다. 데이터 확인이 수신되면, 컴포넌트는 다음 IPC 메시지를 전송하도록 진행할 수 있다.
단계(1316)에서는 디바이스 계층이 IPC 메시지 데이터 및 IPC 헤더를 포함하는 데이터 표시 메시지를 전송한다. 세션 매니저는 메시지의 목적지 IPC 헤더를 검사하고, 로컬 IPC 어드레스와 서로 다른 경우 세션 매니저는 올바른 IPC 노드에 메시지를 전송(라우팅)한다. 단계(1310)에서는 세션 매니저가 예비된 채널 ID와 함께 디바이스 계층에 데이터 요청을 전송한다. 세션 매니저는 목적지 컴포넌트 ID를 검사하고, 그것이 0xFF와 같은 경우 그 연산코드가 예약된 모든 컴포넌트들에 메시지를 라우팅한다. 단계(1318)에서는 세션 매니저가 컴포넌트 데이터 표시 메시지를 전송하고, 컴포넌트 IPC 데이터를 수신한다.
IPC 스택은 모든 참여 IPC 노드들 사이에서 통신 목적들을 위한 예비된 제어 채널을 사용한다. 파워-업 할 때, IPC 서버의 세션 매니저는 IPC 클라이언트들에 메시지들을 방송하기 위해 이러한 링크를 사용하며 반대로도 마찬가지이다. 통상적인 동작들 동안, 이러한 제어 채널은 모든 AP들 및 BP들 사이에서 제어 정보를 전달하기 위해 사용된다.
도 14에서는 IPC 스택들 및 IPC 하드웨어 사이에 위치된 제어 채널들(1402- 1406)이 도시되어 있다. 제어 채널 정보(1408)는 또한 서로 다른 IPC 하드웨어 사이에 데이터를 전송할 때 데이터 패킷들(1410)을 따라 전송된다. IPC 클라이언트는 IPC 제어 채널상에 초기에 그것의 구성 요청을 방송한다. IPC 서버는 방송을 수신하여 그 클라이언트에 대한 IPC 어드레스와 응답한다. 이러한 IPC 어드레스는 그 특정한 프로세서(AP 또는 BP)에 대한 동적 라우팅 테이블과 연관된다.
IPC 애플리케이션 프로그램 인터페이스들(API들)
본 발명의 IPC 프로토콜에 대한 API들의 일부가 이하 열거되어 있다.
1). IPC 세션 매니저에 대한 컴포넌트 인터페이스:
CreateComponentInst()
IPC 세션 매니저에서 컴포넌트 데이터베이스를 생성한다. 컴포넌트 데이터 유형들(빅 엔디안(big Endian) 대 리틀 엔디안)과 같은 정보 및 메시지 연산코드들에 대한 예약은 IPC 어드레스에 속하는 동적 데이터 라우팅 테이블에서 사용된다.
OpenChannelKeep()
IPC 채널을 개방하고, 그것이 사용가능한 경우 ChannelGrant()를 내보낸다. 채널은 CloseChannel()을 내보낼 때까지 예비된다. 컴포넌트들은 IPC 세션 매니저에 QoS 요청들을 전송한다. IPC 채널은 그것이 아직 할당되지 않은 경우(예컨대, ChannelGrant()) 컴포넌트 ID를 할당한다.
OpenChannel()
IPC 채널을 개방하고, 그것이 사용가능한 경우 ChannelGrant()를 내보낸다. 파라미터들은 최초의 OpenChannelKeep()에 대해 동일하게 사용된다.
OpenChannelWThru()
IPC 채널을 개방하고, 그것이 사용가능한 경우 ChannelGrant()를 내보낸다. 이것은 캡슐화가 이러한 채널상에서 턴 오프되는 것을 나타내는 쓰기 스루 채널(write thru channel)에 대해 요청한다(예컨대, Non UDP AT 명령들).
CloseChannel()
IPC 채널이 폐쇄되는 것을 요청한다. 컴포넌트는 더 이상 채널을 필요로 하지 않는다. 리소스들은 그 후에 자유롭게 된다.
ChannelGrant()
채널이 요청자에게 인가된다. 채널 ID들은 그것이 아직 할당되지 않은 경우 IPC 세션 매니저에 의해 할당된다.
ChannelError()
채널 에러가 발생하였다. 채널이 폐쇄되고, 요청자가 통보받는다.
ChannelDataIndication()
요청자는 채널상의 데이터가 전달되는 것을 경고 받는다. 이러한 메시지는 타겟 컴포넌트로 IPC 프리젠테이션 매니저에 의해 전송된다. 이것은 또한 제어 채널 데이터를 포함한다.
DataChannelRequest()
요청자는 개방된 채널상에 데이터를 전송하기 원한다. 이것은 또한 제어 채널 데이터를 포함한다.
ChannelClose()
IPC 채널이 폐쇄되는 것을 요청한다. 만기된 채널 비활성 타이머 및 타임아웃과 연관된 채널이 폐쇄된다. 이것은 또한 채널 에러로 인한 것일 수 있다.
2). IPC 디바이스 인터페이스로부터의/인터페이스로의 IPC 세션 매니저
OpenChannel()
논리 IPC 채널을 개방하고, 그것이 사용가능한 경우 ChannelGrant()를 내보낸다. IPC 세션 매니저는 IPC 디바이스 인터페이스 매니저에게 채널 우선순위 요청들을 전송한다.
CloseChannel()
IPC 논리 채널이 폐쇄되는 것을 요청한다. 컴포넌트는 그것이 더 이상 채널을 요구하지 않는다는 것을 결정한다.
ChannelGrant()
논리 채널이 요청자에게 인가된다.
ChannelError()
채널 에러가 발생하였다(예컨대, 착신 데이터에 대한 CRC 실패 또는 물리적 채널 실패).
ChannelDataIndication()
요청자는 채널상의 데이터가 전달된다는 것을 경고받는다.
ChannelClose()
IPC 채널이 폐쇄되는 것을 요청한다. 만기된 채널 비활성 타이머 및 타임아웃과 연관된 채널이 폐쇄된다. 이것은 또한 채널 에러로 인한 것일 수 있다.
3). IPC 세션 매니저 대 IPC 프리젠테이션 매니저
ChannelDataIndication()
요청자는 채널상의 데이터가 전달된다는 것을 경고받는다. 정보는 정확한 데이터 포맷과 함께 타겟 컴포넌트로 포워딩된다.
4). IPC 하드웨어/IPC 스택 인터페이스
OpenChannel()
물리적 IPC 채널을 개방하고, 그것이 사용가능한 경우 ChannelGrant()를 내보낸다. IPC 세션 매니저는 IPC 하드웨어에 채널 우선순위 요청들을 전송한다.
CloseChannel()
IPC 물리적 채널이 폐쇄되는 것을 요청한다. 컴포넌트는 더 이상 채널을 요구하지 않는다.
ChannelGrant()
물리적 채널이 요청자에게 인가된다.
ChannelError()
채널 에러가 발생하였다(예컨대, 착신 데이터에 대한 CRC 실패 또는 물리적 채널 실패).
ChannelDataIndication()
요청자는 채널상의 데이터가 전달된다는 것을 경고받는다.
DataChannelRequest()
요청자는 물리적 채널상의 데이터를 전송하기 원한다.
ChannelClose()
IPC 채널이 폐쇄되는 것을 요청한다. 만기된 채널 비활성 타이머 및 타임아웃과 연관된 채널이 폐쇄된다. 이것은 또한 채널 에러로 인한 것일 수 있다.
도 15에서는 기저대역 프로세서(BP)(1502)를 갖는 라디오 통신 디바이스(예컨대, 이동 전화기 등)(1500)와, IPC 네트워크를 사용하여 서로 통신하는 애플리케이션 프로세서(AP)(1504)와 같은 전자 디바이스를 도시한 블록도이다. 본 발명의 IPC 프로토콜은 통신 디바이스와 같은 시스템에서 다중 프로세서들 사이에 통신을 제공한다. IPC는 개인용 통신 시스템(PCS) 애플리케이션과 같은 MA 서버를 통해 등록하기 위한 모바일 애플리케이션(MA: Mobile Application) 클라이언트(예컨대, iDENTMWLAN)에 대해 허용하고, 무슨 소프트웨어 구조들, 운영 시스템들, 하드웨어 등이 그것 자신의 MA 내에서 의존하는지에 대해 어떠한 제한들 없이 자유롭게 통신하기 위해 2개의 MA들에 대한 수단을 제공할 것이다.
IPC 프로토콜은 통신을 위한 IPC 링크로 어떠한 IPC 확인 MA의 동적 부가에 대해 허용한다. 따라서, IPC 네트워크는 어떠한 컴파일 시간 의존성들 또는 어떠한 다른 소프트웨어 가정들 없이 형성된다. 본 발명의 IPC는 IPC 스택과 통신하기 위한 소프트웨어 컴포넌트들에 대한 표준 방식을 나타내고, 스택 아래의 하드웨어는 또한 컴포넌트들이 통신하기 위해 서로 다른 링크들을 선택할 수 있는 것과 같이 제거된다.
이제 도 16을 참조하면, 소프트웨어 스레드들(1602, 1604, 1606)과 같은 컴 포넌트들과, 그것들이 외부로 향하는 스트리밍을 설정하는 방법을 도시하고 있다. 소프트웨어 스레드(1602)는 예를 들어 미리 결정된 QoS(1608)에 대한 요청(1612)을 전송하고, 그것의 연산코드 예약 리스트(1610)를 제공한다. 대신에, 소프트웨어 스레드(1602)가 응답 메시지(1618)로 채널 ID(1614) 및 컴포넌트 ID(1616)에 할당된다. 본 발명의 실시예에 따른 소프트웨어 스레드들(1602, 1604, 1606)과 같은 컴포넌트들은 그것들의 요구들에 의존하여 IPC 하드웨어 리소스들에 할당된다. 컴포넌트들(1602, 1604, 1606)은 시스템 요구들에 의존하여 동적으로 인스톨 또는 언인스톨될 수 있다.
도 17에서는 컴포넌트들(1602, 1604, 1606)이 소프트웨어 스레드(1602)에 대한 채널(1702)과 같이 그것들의 할당된 채널들에 대해 IPC 데이터를 전송한다. 컴포넌트들(1602, 1604, 1606)은 어떠한 노드도 명시되지 않을 때 컴포넌트들이 또한 모든 IPC 노드들에 그것들의 메시지들을 방송할 수 있을지라도, 타겟 IPC 노드에 따라 그것들의 데이터를 제공한다. 컴포넌트들(1602, 1604, 1606)은 목적지 컴포넌트들 ID들을 알고 있을 필요가 없고, 그것들의 연관된 채널들과 그것들의 IPC 어드레스 또한 알고 있을 필요가 없다. 내부로 향하는 스트리밍과 관련하여, 메시지 연산코드들은 컴포넌트들을 식별한다. 예를 들어, 도 18에서는 컴포넌트들(1602, 1604, 1606)이 메시지 연산코드들에 의해 식별된다. 컴포넌트 ID들은 이전에 논의된 컴포넌트 라우팅 테이블을 통해 발견된다. IPC 세션 매니저는 메시지 내 IPC 연산코드를 예약한 모든 컴포넌트들에게 착신 데이터를 라우팅한다.
고 레벨 서비스 구조
도 19를 참조하면, 새로운 서비스를 요청하는 제 1 클라이언트(1902), 서버(1908), 및 복수의 다른 클라이언트들(1904, 1906, 1910, 1912)을 포함하는 IPC 네트워크가 도시되어 있다. 본 발명의 실시예에 따른 고 레벨 서비스 구조의 예에 있어서, 요청 클라이언트(1902)는 카메라 및 JPEG 애플리케이션의 사용을 요청하는 포토 서비스를 사용할 필요가 있다. 본 발명의 고 레벨 구조를 통해, 포토 서비스를 요청하는 클라이언트(또는 컴포넌트)(1902)는 무엇이 "새로운(new)" 서비스 수단인지 그것의 IPC 세션 매니저(도 19에 도시되지 않음)에게 "알려줄(teach)" 수 있다(예컨대, 각각의 서비스는 IPC 연산코드들 또는 다른 ID의 리스트의 구조이다).
이러한 특정한 예에 있어서, 요청 IPC 클라이언트(1902)에 의해 요청되는 새로운 포토 서비스는 IPC 서버(1908)에 의해 제공되는 독특한 연산코드와 같은 (또한 단순히 ID로 언급되는) 서비스 ID를 제공받는다. IPC 서버의 세션 매니저(도시되지 않음)는 포토 서비스에 할당되는 서비스 ID가 포토 서비스를 구성하는 추가적인 ID들(예컨대, 연산코드들)을 나타내는 더 높은 레벨 라우팅 테이블을 유지할 것이다. 컴포넌트 또는 클라이언트가 IPC 서버(1908)에 새로운 연산코드 또는 서비스 ID를 전송함으로써 결합된 서비스를 요청할 때, IPC 서버(1908)는 서비스(예컨대, JPEG 1916 및 카메라 1914)에 대해 요구되는 모든 컴포넌트들이 요청 컴포넌트/클라이언트(1902)에서 시작으로 복귀하기 전에 등록될 때까지 기다릴 것이다.
컴포넌트들 또는 클라이언트들은 동적으로 서비스들을 구성하여, IPC 서버(1908)에 알릴 수 있다. 이것은 컴포넌트/클라이언트가 하나 이상의 ID들, 이러한 특정한 예에서 카메라 및 JPEG 서비스를 참조하는 연산코드들을 포함하는 "새로운" 서비스를 함께 입력한 것을 IPC 서버의 세션 매니저에게 알리는 컴포넌트 IPC 세션 매니저 API(즉, NewService())를 전송하는 요청 컴포넌트 또는 클라이언트(1902)에 의해 이루어질 수 있다. 새로운 서비스 API를 수신하는데 응답하여 IPC 서버(1908)는 새로운 결합된 서비스에 대한 서비스 ID를 준비한다. IPC 서버(1908)는 차례로 등록된 IPC 노드들로부터 결합된 서비스를 포함하는 요소들(예컨대, 컴포넌트들, 애플리케이션들)을 발견한다. 모든 결합된 서비스에 대한 요소들이 위치되었을 때, 서비스가 존재하는 것으로 선언되고 진행할 준비를 하게 된다.
이러한 특정한 예에 있어서, IPC 클라이언트(1902)는 새로운 서비스 API를 전송할 것이고, IPC 서버(1908)에 의해 할당되는 새로운 서비스 ID를 설정할 것이다. 이러한 새로운 서비스 ID는 카메라 및 JPEG 애플리케이션들에 대한 연산코드들/ID들을 참조할 것이다. 포토 서비스에 대한 새로운 ID는 IPC 클라이언트(1902) 및 IPC 서버(1908)에 대한 세션 매니저에 저장될 것이다. IPC 서버(1908)에 있어서, 서비스 ID 테이블은 카메라 및 JPEG 애플케이션에 대한 그것의 조성 ID들(예컨대, 연산코드들)과 포토 서비스 ID를 링크시킬 것이다. 포토 서비스가 논의되었을지라도, 서로 다른 서비스들이 복수의 서로 다른 ID들과 결합하여 요청될 수 있다.
IPC 구조(1900)에 있어서, 소프트웨어 컴포넌트들은 서로 다른 서비스 ID들을 동적으로 예약할 수 있다. 예를 들어, 하나의 MA에 대한 오디오 소프트웨어 컴포넌트는 그것이 지원할 수 있는 오디오에 관련된 모든 연산코드들을 예약할 수 있다. IPC 클라이언트(1902)는 컴포넌트 예약을 기록하고, 그 예약에 대해 IPC 서버 (1908)에 알린다. 어떠한 MA에 대해 컴포넌트들은 그에 따라 오직 결합된 서비스에 할당된 특정한 서비스 ID와 그것들의 IPC 데이터를 전송한다. 그것들은 무슨 서비스들이 IPC 네트워크에 대해 제공되는지 또는 그러한 서비스들이 어디에 지원되는지 미리 알고 있을 필요가 없다.
IPC 네트워크(1900)는 컴포넌트들이 서로 다른 MA들 사이에서 인터프로세서 통신에 영향을 미치지 않으며 서비스 규정을 변경하도록 허용한다. 추가로, 컴포넌트들은 서비스의 컨셉, 서비스를 통한 컴파일 시간 동안의 등록을 미리 알고 있을 필요가 없거나, 서비스들이 IPC 네트워크(1900)에 대해 사용가능한지의 여부를 개별적으로 검사할 필요도 없다. IPC 네트워크(1900)는 동적으로 그 서비스를 학습하며, 그 네트워크에 대한 서비스 가용성을 식별할 수 있다.
도 20을 참조하면, 본 발명의 실시예에 따라 취해지는 단계들의 일부를 강조하는 흐름도가 도시되어 있다. 단계(2002)에서, IPC 클라이언트(1902)와 같은 컴포넌트/클라이언트는 서비스(예컨대, 포토 서비스)를 요청한다. 그것이 서비스의 새로운 유형인 경우, IPC 클라이언트(1902)는 새로운 서비스를 포함하는 IPC 연산코드들/ID들의 구조를 규정하는 새로운 서비스 API를 전송함으로써 그 서비스를 IPC 네트워크에 알려줄 수 있다. 이러한 예에 있어서, 단계(2004)에서 IPC 세션 매니저는 포토 서비스가 카메라 및 JPEG 서비스와 연관된 연산코드들을 포함하는 것을 결정한다. IPC 클라이언트(1902)는 IPC 클라이언트(1902)에 새로운 포토 서비스를 규정하는 새로운 연산코드 또는 서비스 ID를 차례로 제공하는 IPC 서버(1908)에서 NewService API를 사용하여 이러한 정보를 전송한다. IPC 클라이언트(1902)는 그 후에 IPC 서버(1908)에 할당된 ID를 전송함으로써 포토 서비스를 요청할 수 있다.
"서비스(service)"에 대한 연산코드들의 리스트가 결정되면, 단계(2006)에서 IPC 서버(1908)는 모든 요구된 서비스 컴포넌트들이 IPC 네트워크(1900)를 통해 등록되었을 때까지 기다릴 것이다. 모든 요구된 서비스 컴포넌트들(예컨대, JPEG(1916) 및 카메라(1914))이 등록되면, IPC 서버(1908)는 요청된 포토 서비스를 사용하기 위한 진행을 IPC 클라이언트(1902)에 제공한다. IPC 서버(1908)는 요구된 컴포넌트들이 결합된 서비스(예컨대, 포토 서비스)의 일부가 되는 것을 요청하는 그들 각각에 메시지를 전송할 수 있다. JPEG 애플리케이션(1916) 및 카메라(1914)와 같은 컴포넌트들은 서비스의 일부로 되는 것을 수용 또는 거부할 수 있다. 컴포넌트가 결합된 서비스의 일부가 되는 것을 수용하지 않는 경우, IPC 서버(1908)는 서비스를 지원하기 위한 또 다른 컴포넌트를 찾을 것이다.
IPC 서버(1908)가 JPEG(1916) 및 카메라(1914)와 같은 모든 요구된 컴포넌트들로부터 승인을 얻을 수 있다면, IPC 서버(1908)는 자신이 단계(2008)에서 요청한 서비스를 진행하고 사용한다는 것을 요청 클라이언트(1902)가 알게 한다. IPC 클라이언트(1902)가 포토 서비스를 사용하는 것을 종료한 후, 그것은 다른 컴포넌트들/클라이언트들에 의한 사용을 위해 카메라(1914) 및 JPEG 서비스(1916)를 해제할 IPC 서버(1908)에 메시지를 전송할 것이다. 서비스의 일부인 카메라(1914) 또는 JPEG 서비스(1916)와 같은 컴포넌트가 요청 클라이언트(1902)에 의한 서비스의 사용 동안 어떠한 이유로 중단되는 경우, IPC 서버(1908)는 대체물을 배치하려 할 것이고, 그것이 시기 적절한 방식으로 어느 것을 찾을 수 없는 경우, 요청 컴포넌트/ 클라이언트(1902)(또는 컴포넌트)는 서비스의 사용을 중단한다.
컴포넌트 서비스들을 동적으로 발견하고 서비스의 컨셉들을 지원하기 위한 IPC 네트워크(1900)의 장점들은 컴포넌트 개발이 IPC 스택 동작들과 무관하다는 이득을 포함한다. 또한, 컴포넌트들은 "서비스들"을 동적으로 구성할 수 있으며, 컴포넌트들은 동일한 서비스의 컨셉의 서로 다른 규정들을 가질 수 있다. 예를 들어, 오디오 서비스의 개념은 iDEN BP 대 PCS BP에 대해 서로 다를 수 있다. IPC는 어느 오디오 서비스가 그것을 보다 잘 서빙할 것인지 발견하기 위해 IPC 네트워크를 통해 전송 컴포넌트를 허용함으로써 오디오 데이터를 계속해서 라우팅할 수 있다.
본 발명의 양호한 실시예들이 예시적으로 기술되는 동안, 본 발명이 제한적이지 않다는 것은 명백할 것이다. 많은 수정들, 변화들, 변경들, 대체들, 및 등가물들이 첨부된 특허청구범위에 규정된 바와 같이 본 발명의 범위로부터 벗어나지 않으며 당업자들에 의해 이루어질 수 있다.

Claims (10)

  1. 인터프로세서 통신(IPC: interprocessor communication) 네트워크로서,
    IPC 서버; 및
    상기 IPC 서버에 연결된 IPC 클라이언트로서, 상기 IPC 네트워크에서 사용가능한 복수의 서비스들을 결합하는 새로운 결합된 서비스의 사용을 동적으로 요청할 수 있는, 상기 IPC 클라이언트를 포함하는 인터프로세서 통신 네트워크.
  2. 제 1 항에 있어서, 상기 IPC 클라이언트는 상기 새로운 결합된 서비스를 포함하는 상기 복수의 서비스들을 상기 IPC 서버에 알리는 메시지를 상기 IPC 서버에 전송함으로써 상기 새로운 결합된 서비스를 동적으로 요청하는, 인터프로세서 통신 네트워크.
  3. 제 2 항에 있어서, 상기 IPC 클라이언트는 어떠한 복수의 서비스들이 상기 새로운 결합된 서비스를 포함하는지를 상기 IPC 서버에 알리는 애플리케이션 프로그램 인터페이스(API) 메시지를 상기 IPC 서버에 전송하는, 인터프로세서 통신 네트워크.
  4. 제 2 항에 있어서, 상기 IPC 클라이언트는 상기 IPC 서버에 상기 새로운 결합된 서비스를 구성하는 상기 복수의 서비스들 각각에 대해 ID를 전송하는, 인터프 로세서 통신 네트워크.
  5. 제 1 항에 있어서, 상기 IPC 네트워크에서 사용가능한 상기 서비스들 각각은 그들 각각에 할당된 연산코드(opcode)를 갖고, 상기 새로운 결합된 서비스는 상기 IPC 서버에 의해 고유 연산코드를 할당받는, 인터프로세서 통신 네트워크.
  6. IPC 클라이언트 및 IPC 서버를 갖는 인터프로세서 통신(IPC) 네트워크에서 서비스 구조를 제공하는 방법으로서,
    복수의 서비스들의 사용을 결합하는 상기 IPC 클라이언트에 의해 새로운 서비스를 요청하는 단계; 및
    상기 새로운 서비스에 의해 필요로 되는 상기 복수의 서비스들에 링크되는 상기 새로운 서비스에 ID를 할당하는 단계를 포함하는 서비스 구조 제공 방법.
  7. 제 6 항에 있어서, 상기 IPC 서버는 상기 새로운 서비스에 할당된 상기 ID를 상기 IPC 클라이언트로 전송하는, 서비스 구조 제공 방법.
  8. 제 6 항에 있어서, 상기 IPC 클라이언트는 어떠한 복수의 서비스들이 상기 새로운 서비스를 포함하는지를 상기 IPC 서버에 알리는 API를 상기 IPC 서버에 전송하는, 서비스 구조 제공 방법.
  9. 제 7 항에 있어서, 상기 IPC 서버는 상기 새로운 서비스에 의해 필요로 되는 상기 복수의 서비스들과 연관된 상기 ID들로 상기 새로운 서비스에 할당된 상기 ID를 링크시키는, 서비스 구조 제공 방법.
  10. 제 9 항에 있어서, 상기 IPC 서버는, 상기 IPC 클라이언트가 상기 새로운 서비스를 사용하는 것을 허용하기 이전에, 상기 새로운 서비스를 구성하는 상기 복수의 서비스들의 모두가 사용가능할 때까지 대기하는, 서비스 구조 제공 방법.
KR1020067008545A 2003-10-02 2004-09-20 고레벨 서비스 구성을 갖는 인터프로세서 통신 프로토콜 KR100787850B1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US10/677,881 2003-10-02
US10/677,881 US20050091306A1 (en) 2003-10-02 2003-10-02 Interprocessor communication protocol with high level service composition

Publications (2)

Publication Number Publication Date
KR20060080242A KR20060080242A (ko) 2006-07-07
KR100787850B1 true KR100787850B1 (ko) 2007-12-27

Family

ID=34465434

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020067008545A KR100787850B1 (ko) 2003-10-02 2004-09-20 고레벨 서비스 구성을 갖는 인터프로세서 통신 프로토콜

Country Status (4)

Country Link
US (1) US20050091306A1 (ko)
KR (1) KR100787850B1 (ko)
CN (1) CN101416470A (ko)
WO (1) WO2005038558A2 (ko)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004265193A (ja) * 2003-03-03 2004-09-24 Canon Inc 情報処理方法、情報処理装置、サーバ装置の制御方法、サーバ装置
CN101841925B (zh) * 2010-04-21 2012-10-17 华为终端有限公司 一种双中央微处理器间的通信方法、装置及系统

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20000012128A (ko) 1998-07-31 2000-02-25 비센트 비.인그라시아 데이터 처리 시스템의 트랜잭션 수행 방법 및 장치
KR20020093990A (ko) 2001-02-27 2002-12-16 모토로라 인코포레이티드 인히어런트리 마스터 슬레이브 인터페이스를 통한피어-투-피어 통신을 위한 방법 및 장치

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3490473B2 (ja) * 1993-02-17 2004-01-26 松下電器産業株式会社 プロセッサ間通信システム
US5835779A (en) * 1996-03-15 1998-11-10 Lucent Technologies Inc. Message transmission among processing units using interrupt control technique
JP2000099332A (ja) * 1998-09-25 2000-04-07 Hitachi Ltd 遠隔手続き呼び出し最適化方法とこれを用いたプログラム実行方法
US6747970B1 (en) * 1999-04-29 2004-06-08 Christopher H. Lamb Methods and apparatus for providing communications services between connectionless and connection-oriented networks
WO2001020476A1 (en) * 1999-09-16 2001-03-22 General Electric Company A virtual modular relay device
US7051108B1 (en) * 2000-12-21 2006-05-23 Emc Corporation Method and system of interprocess communications
US7064766B2 (en) * 2001-10-18 2006-06-20 Microsoft Corporation Intelligent caching data structure for immediate mode graphics
US20040006595A1 (en) * 2002-07-03 2004-01-08 Chiang Yeh Extended features to conferencing system using a web-based management interface
US7140002B2 (en) * 2002-11-07 2006-11-21 International Business Machines Corporation Method and system for automatic code generation accessing functionality in a remote process

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20000012128A (ko) 1998-07-31 2000-02-25 비센트 비.인그라시아 데이터 처리 시스템의 트랜잭션 수행 방법 및 장치
KR20020093990A (ko) 2001-02-27 2002-12-16 모토로라 인코포레이티드 인히어런트리 마스터 슬레이브 인터페이스를 통한피어-투-피어 통신을 위한 방법 및 장치

Also Published As

Publication number Publication date
WO2005038558A3 (en) 2009-04-09
WO2005038558A2 (en) 2005-04-28
CN101416470A (zh) 2009-04-22
KR20060080242A (ko) 2006-07-07
US20050091306A1 (en) 2005-04-28

Similar Documents

Publication Publication Date Title
US8326918B2 (en) Interprocessor communication protocol
US20050010925A1 (en) Interprocessor communication protocol with smart streaming port
US5526358A (en) Node management in scalable distributed computing enviroment
JP4000331B2 (ja) ネットワークのポートマッピング用システム
EP1699417B1 (en) Interprocessor communication network providing dynamic dedication of ports
KR100804441B1 (ko) 노드들의 지능적 타겟팅을 제공하는 인터프로세서 통신 프로토콜
JP2007526544A5 (ko)
KR100812680B1 (ko) 보장된 서비스 품질 및 선택적인 브로드캐스팅을 제공하는프로세서간 통신 프로토콜
KR100787850B1 (ko) 고레벨 서비스 구성을 갖는 인터프로세서 통신 프로토콜
KR100805094B1 (ko) 포트들의 동적 전용을 제공하는 인터프로세서 통신네트워크
JP2006171917A (ja) 無線マルチホップアドホックネットワークのためのプロトコル

Legal Events

Date Code Title Description
A201 Request for examination
E701 Decision to grant or registration of patent right
GRNT Written decision to grant
J202 Request for trial for correction [limitation]
J301 Trial decision

Free format text: TRIAL DECISION FOR CORRECTION REQUESTED 20080319

Effective date: 20090323

LAPS Lapse due to unpaid annual fee