KR100812680B1 - 보장된 서비스 품질 및 선택적인 브로드캐스팅을 제공하는프로세서간 통신 프로토콜 - Google Patents

보장된 서비스 품질 및 선택적인 브로드캐스팅을 제공하는프로세서간 통신 프로토콜 Download PDF

Info

Publication number
KR100812680B1
KR100812680B1 KR1020067002154A KR20067002154A KR100812680B1 KR 100812680 B1 KR100812680 B1 KR 100812680B1 KR 1020067002154 A KR1020067002154 A KR 1020067002154A KR 20067002154 A KR20067002154 A KR 20067002154A KR 100812680 B1 KR100812680 B1 KR 100812680B1
Authority
KR
South Korea
Prior art keywords
ipc
component
client
channel
network
Prior art date
Application number
KR1020067002154A
Other languages
English (en)
Other versions
KR20060041301A (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 KR20060041301A publication Critical patent/KR20060041301A/ko
Application granted granted Critical
Publication of KR100812680B1 publication Critical patent/KR100812680B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/544—Buffers; Shared memory; Pipes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/61—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources taking into account QoS or priority requirements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/63—Routing a service request depending on the request content or context
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Abstract

프로세서간 통신(IPC) 프로토콜 네트워크(100)는 하나 이상의 IPC 클라이언트(102) 및 IPC 서버(108)를 포함한다. IPC 프로토콜은 IPC 클라이언트(102)가 IPC 서버(108)에 등록하도록 하며, 이 IPC 서버는 소프트웨어 아키텍쳐, 운영 체제들, 하드웨어 등 각각이 의존하는 임의의 제한들 없이 둘이 자유롭게 통신하는 것을 허용하는 수단을 제공할 것이다. 본 발명의 일 실시예에서 IPC 프로토콜은 컴포넌트들이 상이한 서비스 품질(QoS)를 동적으로 요청하도록 한다. 또 다른 실시예에서, IPC 노드는 메시지를 송신기에 의해 선택되는 노드들에 선택적으로 브로드캐스트할 수 있다.
IPC 클라이언트, IPC 서버, IPC 노드, 소프트웨어 쓰레드, IPC 스케쥴러

Description

보장된 서비스 품질 및 선택적인 브로드캐스팅을 제공하는 프로세서간 통신 프로토콜{Interprocessor communication protocol providing guaranteed quality of service and selective broadcasting}
본 발명은 일반적으로 전자장치들 분야에 관한 것이며, 특히, 보장된 서비스 품질(QoS) 및 선택적인 브로드캐스팅 특징을 제공하는 프로세서간 통신(IPC) 프로토콜/네트워크에 관한 것이다.
대부분의 전자 시스템들은 시스템을 형성하는 하드웨어 및 소프트웨어와 같은 다수의 네트워킹된 소자들(컴포넌트들)을 포함한다. 대부분의 시스템들에는 상이한 네트워킹된 소자들 사이뿐만 아니라 네트워킹된 소자를 형성하는 상이한 컴포넌트들 간을 통신시키는 역할을 하는 층이 존재한다. 이 층은 통상적으로 프로세서간 통신(IPC) 층이라 칭한다.
최근 몇년 간에 프로세서간 통신들을 다루기 위하여 여러 프로토콜들이 도입되었다. IPC 프로덕트(product)의 한 예는 호스트-투-PCI 브리지, 동적 랜덤 액세스 메모리(DRAM) 제어기, 및 데이터 경로와 가속된 그래픽 포트(AGP) 인터페이스를 통합한 PCI AGP 제어기(PAC)이다. IPC 프로덕트의 다른 예는 OMAPTM 플랫폼들이다. 이들 플랫폼들 중 어느 것도 하위 레벨 컴포넌트 또는 채널 레벨들(하드웨어 레벨)에서 설계 유연성을 제공하지 못한다.
예를 들어, PAC 플랫폼들은 폐쇄된 아키텍쳐들이고, 운영 시스템의 TAPI 층에 임베딩되며, IPC 코드는 개발자들이 액세스할 수 없다. 그러므로, 이들 플랫폼들은 컴포넌트 레벨들로 확장되지 못하고 동적 IPC 자원들의 할당을 허용하지 않으며, 컴포넌트들이 서비스 성능들을 결정하는 것을 허용하지 않고 멀티-노드 라우팅에 제공되지 못한다.
실시간 처리가 갖는 주요 문제들 중 하나는 상이한 이동 애플리케이션들(MA들)의 운용에 참여하는 모든 소프트웨어 컴포넌트에 대해 서비스 품질(QoS)이 보장될 필요가 있다는 것이다. 예를 들어, 휴대용 무선 통신 장치는 PCM Symbian 기반 애플리케이션 프로세서를 가진 모토로라사의 iDENTM 광역 근거리 망(WLAN) 기저대역 MA들일 수 있다. 소프트웨어 컴포넌트들은 일반적으로 QoS가 무엇인지 그리고 이것이 어떻게 보장될 수 있는지를 인지하지 못한다. 현재 종래 기술의 시스템들에 있어서, 특정 레벨의 보장된 하드웨어 수행성능을 필요로 하는 컴포넌트들은 상이한 하드웨어 플랫폼들 관점에서 상이하게 맞춰져야만 한다. 타이트하게 결합된 시스템에서 개별적인 컴포넌트가 특정 하드웨어 수행성능 레벨을 보장할 필요가 있다면(예를 들어, 특정 데이터 량, 대역폭 등), IPC가 플랫폼을 특정하도록 하는 방식으로 QoS 요건들을 맞출 필요가 있다. 이는 물론 장치 휴대성(재사용)의 에어리어에서 주요한 문제점이다.
종래 기술의 IPC 시스템들에 의해 겪는 또 다른 문제는 사전-할당 문제이다. 사전-할당은 각 소프트웨어 컴포넌트가 IPC 상에서 데이터를 송,수신하는데 얼마나 많은 데이터 대역폭을 컴파일하는지를 미리 인지하도록 한다. IPC 채널들의 사전 할당은 모든 MA들이 IPC 상에서 정확히 동일한 채널 할당을 하게 하며, 이는 오늘날 시장에서 바람직한 해결책이 아니다. 사전 할당은 컴포넌트가 채널 자원들을 사용하지 않더라도 컴포넌트들이 채널 및 그의 자원을 차단하도록 하며, 이는 부가적으로 효율성을 저하시킨다. 상술된 바에 의해, 종래 기술의 이들 단점들 중 일부에 대한 해법을 제공할 수 있는 IPC 프로토콜에 대한 기술이 필요로 된다.
신규한 것으로 간주되는 본 발명의 특징들이 첨부된 청구범위에 서술되어 있다. 본 발명은 동일한 참조 번호들이 동일한 소자들에 병기되어 있는 첨부한 도면들과 관련한 이하의 설명과 관련하여 최적으로 이해될 수 있다.
본 발명의 실시예를 따르면, IPC 네트워크에 결합된 컴포넌트들이 상이한 QoS 레벨들을 동적으로 요청할 수 있다. QoS가 우선순위 및 데이터 레이트들과 관련하여 보장되지만, 이들 파라미터들만으로 제한되지 않는다. QoS 기술은 다른 QoS 팩터들을 고려할 수 있다. QoS를 보장하도록 하는 IPC의 장점들은 상이한 MA들 간의 컴포넌트 이식성(portability)뿐만 아니라 플랫폼들로부터의 아키텍쳐 앱스트랙션(abstraction)을 허용한다.
본 발명의 선택적인 브로드캐스팅 특징은 IPC 노드가 IPC 네트워크에 결합된 IPC 노드들을 선택하기 위해 메시지를 전송하는 것을 허용한다. 이 네트워크는 필터 테이블을 사용하여, IPC 서버가 브로드캐스트 메시지를 송신기에 의해 선택된 노드들에 전송할 수 있도록 한다. 필터 테이블은 또한 IPC 링크를 통해서 IPC 노드들에 의해 동적으로 갱신될 수 있다. 본 발명의 실시예를 따르면, 선택적인 브로드캐스팅 특징은 소프트웨어 컴포넌트들이 상이한 MA들상의 다른 컴포넌트들과 통신시키는 동적 방법을 허용한다. 이는 종래 기술의 시스템들의 경우와 마찬가지로 MA가 고정된 세트의 전용 IPC 대역폭 및 채널들과 관련하여 구성되지 않도록 한다. IPC 스택 및 이 스택에 결합되는 하드웨어는 또한 앱스트랙트되는데, 그 결과 컴포넌트들은 링크들을 필요로 하기 때문에, 컴포넌트들이 통신하기 위한 상이한 링크들을 선택할 수 있다. IPC 네트워크는 본 발명의 QoS 및 선택적인 브로드캐스팅 특징들의 논의에 앞서 우선 설명될 것이다.
본 발명의 IPC는 서로 통신하기 위해 IPC 네트워크 내에서 동작하는 상이한 프로세서들에 필요로 되는 지원을 제공한다. 예를 들어, 애플리케이션 프로세서(AP) 및 기저대역 프로세서(BP)를 포함하는 무선 통신 장치에 사용하기 위한 듀얼 프로세서 무선 아키텍쳐에서, IPC는 효율적인 방식으로 서로와 통신하게 하기 위하여 프로세서들에 대해 필요로 되는 지원을 제공한다. IPC는 AP 또는 BP의 설계에 대한 어떠한 제한 없이 이 지원을 제공한다.
IPC는 프로세서간 통신 스택으로서 IPC를 채택하는 임의의 프로세서가, 2개가 공통 운영 시스템 및 메모리를 공유하는 동일한 프로세서 코어 상에서 실제로 실행되는 경우처럼 모두 공존하고 동작하게 한다. 통상적인 통신 장치에서 다수의 프로세서들을 사용함으로써, 본 발명의 IPC는 상이한 프로세서들 간에서 신뢰할 수 있는 통신들을 제공한다.
IPC 하드웨어는 IPC 네트워크에 상이한 프로세서들 모두를 연결하는 물리적 커넥션을 제공한다. 본 발명의 일 실시예에서, 데이터 패킷들은 상이한 호스트들 간에 비동기적으로 전송된다. IPC 네트워크에 접속되는 프로세서들은 자신들의 물리적 및 논리적 어드레스들을 통계적으로 또는 동적으로 할당받는다(예를 들어, IPC 어드레스들). 또한, 데이터 패킷들이 본 발명의 일 실시예에서 IPC 네트워크 내의 임의의 방향으로 흐를 수 있기 때문에, 패킷들은 도달하고자 하는 프로세서의 수신지 어드레스를 반송한다. 패킷들은 또한, 종래의 순환 잉여 검사(CRC) 기술들을 사용하여 에러들에 대해서 검사한다. 본 발명의 IPC 네트워크의 네트워크 활동들이 송신 제어 프로토콜/인터넷 프로토콜(TCP/IP)과 같은 IP 전송층들을 사용하는 인터넷 네트워크상에 발견되는 활동들과 일부 유사성들을 갖지만, 본 발명의 IPC는 TCTP/IP 네트워크에서와 같이 게이트웨이들로 보다 작은 네트워크들로 분할되지 않는다.
도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는 본 발명의 실시예를 따른 QoS 절차를 강조한 도면.
도20은 본 발명의 실시예를 따른 컴포넌트 대 컴포넌트 메시징을 강조한 도면.
도21은 컴포넌트들이 본 발명의 실시예를 따른 상이한 프로세서들 상에 위치되는 컴포넌트 대 컴포넌트 메시징을 강조한 도면.
도22는 본 발명의 실시예를 따른 필터링 테이블들을 강조하는 IPC 네트워크를 도시한 도면.
도23은 본 발명의 실시예를 따른 필터링 테이블을 도시한 도면.
도24는 본 발명의 실시예를 따른 메시지들의 선택적인 브로드캐스팅에 제공하는 IPC 네트워크를 도시한 도면.
신규한 것으로서 간주되는 본 발명의 특징들을 규정하는 청구범위들이 명세서에 부합되지만, 본 발명은 전체 도면들과 관련한 이하의 설명을 고려함으로써 더욱 잘 이해될 것이다.
지금부터 도1을 참조하면, 본 발명을 따른 IPC 네트워크(100)가 도시되어 있다. IPC 네트워크(100)는 다수의 IPC 클라이언트들(102-106) 및 일부는 예로서 도시된 바와 같은 메모리(100), 유니버셜 비동기식 수신기/송신기(UART)(112) 및 유니버셜 시리얼 버스(USB)(114)와 같은 상이한 IPC 물리적 링크들을 사용하여 IPC 클라이언트들(102-106)에 결합되는 IPC 서버(108)를 포함한다. 본 발명의 IPC에 따라서, IPC 클라이언트(102-106)는 역할들을 스위치하도록 현재 IPC 서버(102)와 교섭할 수 있다는 점에 유의하여야 한다. IPC 클라이언트(102-106)가 IPC 서버가 되도록 교섭되고 새로운 IPC 서버가 되는 경우, 나머지 IPC 클라이언트들 모두는 IPC 서버에서 변화되는 서버의 IPC 어드레스를 변경시키도록 지시받는다.
도2에서, 본 발명의 실시예를 따른 IPC 서버(108)(IPC 클라이언트들 102-106)의 IPC 스택(200)이 도시되어 있다. IPC 스택(200)은 운영 체제(OS) 하에서 집적되고 컴포넌트 트래픽의 프로세서간 통신 요구들에 대한 지원을 제공하도록 설계된다. IPC 스택은 다음의 3가지 주요 층들로 이루어진다.
(1) IPC 프레젠테이션 관리기(202)- 이 층은 상이한 시스템 컴포넌트들(예를 들어, 소프트웨어 쓰레드들) 간에서 상이한 데이터 유형들을 변환시키도록 사용된다.
(2) IPC 세션 관리기(204)- 이 층은 IPC 스택 및 모든 시스템 컴포넌트들 간의 모든 인입/인출 IPC 트래픽에 대한 중앙 저장소이다. IPC 세션 관리기(204)는 여러 가지 기능들, 즉 IPC 컴포넌트들을 참가시키기 위하여 컴포넌트 ID들 할당; IPC 데이터가 캡슐화될 필요가 있는지를 결정; IPC 트래픽의 IPC 데이터 터미네이션 라우팅; IPC 프로세서들을 위한 홀더 배치; IPC 어드레스들 제공, IPC 클라이언트들의 할당 및 인증 등을 갖는다.
IPC 전송층(208)- IPC 세션 관리기(층)(204) 내에 위치되는데 IPC 전송층(208)은 상이한 프로세서들 간에 IPC 데이터를 전송하기 위하여 매우 기본적인 순환 잉여 검사를 제공한다. 게다가, IPC 전송층(208)은 IPC 네트워크(100) 상의 최종 수신지들에 IPC 메시지들을 라우팅하는 역할을 한다. 전송층의 라우팅 기능은 단지 IPC 서버들 상에서만 인에이블된다.
IPC 라우터 블록(210)- IPC 데이터를 수신지 컴포넌트(도시되지 않음)로 전송한다. 인입하는 IPC 메시지들은 특히 오디오 및 모뎀과 같은 IPC 메시지 옵코드들 및 발신기 컴포넌트 ID를 반송한다. 본 발명의 실시예를 따르면, 특정 옵코드는 IPC 네트워크에 결합되는 오디오 및 모뎀과 같은 각 컴포넌트/소프트웨어 쓰레드(예를 들어 도5의 (502) 참조)에 할당된다. IPC 세션 관리기(204)는 라우터 블록(210)에 의존하여 IPC 데이터를 정확한 컴포넌트(들)에 전송한다.
(3) 장치 인터페이스 층(206)- IPC 물리적-대-논리적 IPC 채널들을 관리하는 역할을 한다. 이것의 주요 기능은 스택 IPC가 하드웨어 독립적이 되도록 완전하게 IPC 하드웨어를 앱스트랙트하는 것이다. 이 장치 인터페이스 층(206)은 모든 IPC 논리적 채널들을 지원하도록 아래에 놓인 IPC 링크의 물리적 대역폭을 관리하는 것이다. 인입하는 경로에서, 장치 인터페이스 층(206)은 상이한 물리적 채널들(110-114)로부터 데이터를 선택하여 이들을 IPC 스택의 나머지까지 통과시킨다. 인출 경로에서, 장치 인터페이스 층(206)은 적절한 물리적 채널들 상으로 전송함으로써 IPC 논리적 채널들의 데이터 로딩을 관리한다. 장치 인터페이스 층(206)은 또한 IPC 하드웨어로 전송하기 전 동일한 IPC 채널에 속하는 연결되는 IPC 패킷들을 취급한다. 채널 요건들은 IPC 세션 관리기(204) 및 IPC 장치 인터페이스층 간에서 사전-교섭된다. 장치 인터페이스 층(206)은 하드웨어 포트들에 제공되는데, 이 포트들은 장치 인터페이스를 IPC 클라이언트(102-106)에 제공한다.
도3을 참조하면, IPC 컴포넌트 ID 할당 루틴이 도시되어 있다. 단계(302)에서, IPC 통신에 참여하길 원하는 임의의 새로운 컴포넌트는 자신의 IPC 세션 관리기(예를 들어, 유사한 세션 관리기(204)로부터 단계(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 채널을 제공하는 방법의 블록도가 도시되어 있다. 도5에서 세션 관리기는 규정된 API를 사용하여 단계(506)에서 장치 층과 컴포넌트의 요청을 교섭한다. 그 후, 장치 층(장치 인터페이스)은 데이터 채널(508)과 같은 하드웨어 자원들을 요청한다. 이 요청에 응답하여, 도5에 도시된 세션 관리기는 도5에서 IPC 채널을 리퀘스터(requestor)에 부여한다. 다음에, 컴포넌트(502)는 자신의 데이터를 할당된 채널(508) 상에 전송한다. 그 후, 장치 층은 데이터를 IPC 네트워크로 전송한다. 논리적 대 물리적 채널 ID들의 맵핑은 IPC 장치 인터페이스의 기능이다.
지금부터 도6을 참조하면, IPC 클라이언트 초기화의 제1 단계는 IPC 클라이언트(602) 및 IPC 서버(604) 간에 등록 요청(단계 606)을 전송한다. 그 후, IPC 서버(604)는 단계(608)에서 IPC 클라이언트(602)에 요청을 인증한다. 이는 단계(610)에서 IPC 어드레스를 IPC 클라이언트에 전송하고 등록을 완료하는 것보다 앞서있다. IPC 클라이언트의 세션 관리기는 단계(612)에서 자신의 동적 라우팅 테이블의 카피를 IPC 서버에 전송한다.
IPC 클라이언트 초기화 공정 동안 행해진 더욱 상세한 단계들이 도7에 도시되어 있다. 클라이언트 세션 관리기(세션(클라이언트)로서 테이블에 도시)는 단계(702)에서 구성 요청을 IPC 서버의 세션 관리기(세션(서버)로서 테이블에 도시)에 전송한다. 단계(704)에서, 인증은 IPC 서버의 세션 관리기에 의해 요청된다. 그 후, IPC 클라이언트 및 IPC 서버 간의 인증은 단계(706)에서 실행된다.
구성 요청에서 파라미터들은 노드 유형 및 데이터 유형을 포함한다. 단계 (702)에서 구성 요청에 응답하여 세션 서버는 리퀘스터에 IPC 어드레스를 할당한다. 존재하지 않는 경우 리퀘스터에 동적 라우팅 테이블을 설정한다. 그 후, 리퀘스터에 단계(708)에서처럼 구성 표시를 전송한다. 이 구성 표시 파라미터들은 서버의 IPC 어드레스 및 클라이언트의 새롭게 할당된 IPC 어드레스를 포함한다.
구성 표시의 수신에 응답하여, 세션 클라이언트에 부착된 컴포넌트들은 클라이언트의 세션 관리기로부터 제어/데이터를 요청할 수 있다. 그 후, 세션 클라이언트는 단계(710)에서 구성 표시 확인 메시지를 세션 서버에 전송한다. "구성 표시 확인" 메시지는 파라미터들을 갖지 않는다. 단계(710)에서 구성 표시 확인 메시지를 수신시, 세션 서버는 IPC 스트림들을 새롭게 구성된 세션 클라이언트로 개시할 수 있다. 그 후, 세션 서버는 단계들(712 및 714)에서 구성 갱신 메시지들을 세션 클라이언트들에 전송한다. 이는 도7에 도시된 세션 클라이언트들 둘 다가 자신들의 각 동적 라우팅 테이블들(도시되지 않음)을 갱신하여 단계들(716 및 718)에서 구성 갱신 확인 메시지를 세션 서버로 전송한다. 구성 갱신 확인 메시지들을 수신시, 세션 서버는 IPC 참여자들 모두를 갱신시킨다.
패킷이 IPC 세션 관리기에 의해 수신될 때, 소스 컴포넌트 ID, 수신지 ID, 채널 ID 및 BP 또는 AP 유형을 포함하는 데이터 형태가 된다. IPC 세션 관리기는 수신지 ID가 삽입되지 않는 경우 수신지 컴포넌트 ID를 부가할 것이다. IPC 세션 관리기는 또한 IPC 어드레스를 삽입할 것이다. 수신된 메시지 옵코드에 기초하여 수신지 ID를 발견하는 것은 IPC 세션 관리기이다. 수신지 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). 동적 라우팅 테이블의 확인은 IPC 서버에 의해 IPC 클라이언트로 단계(912)에서 전송된다. 서버가 경보를 받으면, 새로운 동적 라우팅 테이블은 단계(910)에서 갱신되고 모든 참여하는 프로세서들로 브로드캐스트된다.
동일한 컴포넌트 초기화 공정은 도10에서 컴포넌트(클라이언트)(1002), 클라 이언트 세션 관리기(1004)로서 공지된 세션(클라이언트) 및 서버 세션 관리기(1006)로서 공지된 세션(서버) 간에서 도시된다. 단계(1008)에서, 컴포넌트 구성 요청은 컴포넌트(클라이언트)(1002)에 의해 전송된다. 이 요청에 응답하여, 클라이언트 세션 관리기(1004)는 자신의 장치 층(도시되지 않음)과 논리적 채널을 교섭한다. 클라이언트 세션 관리기(1004)는 또한 컴포넌트 ID를 할당하고 새로운 옵코드 리스트를 자신의 동적 라우팅 테이블(도시되지 않음)에 부가한다. 단계(1010)에서, 클라이언트 세션 관리기(1004)는 파라미터들로서 컴포넌트 ID 및 채널 ID를 포함하는 구성 응답을 전송한다. 구성 응답에 응답하여, 컴포넌트(클라이언트)(1002)는 클라이언트의 세션 관리기(1004)로부터 자신의 ID 및 채널 ID를 수신한다.
클라이언트 세션 관리기(1004)는 단계(1010)에서 구성 요청에 응답하며, 단계(1008)에서 클라이언트 세션 관리기(1004)는 구성 갱신 요청을 세션 서버(1006)에 전송한다(단계 1002). 구성 갱신 요청을 위한 파라미터들은 동적 라우팅 테이블에서 행해지는 임의의 새로운 변화들이다. 세션 관리기는 이 IPC 어드레스를 위한 동적 라우팅을 갱신한다. 단계(1016)에서, 서버 세션 관리기(1006)는 모든 IPC 클라이언트들에게 구성 갱신을 전송하는 반면에, 이는 단계(1014)에서 구성 갱신 표시를 IPC 클라이언트에게 전송한다. 서버의 세션 관리기(1006)는 IPC 서버가 전송되는 변화들로 라우팅 테이블을 갱신하도록 한다.
파라미터(들)로서 동적 라우팅 테이블들을 포함하는 단계(1016)의 구성 갱신 메시지에서, 세션 서버(1006)는 동적 라우팅 테이블들을 갱신하고 단계(1018)에서 구성 갱신 확인 메시지를 전송한다. 그 후, 이 세션 서버(1006)는 모든 IPC 참여자 들이 갱신되도록 한다.
IPC 세션 관리기는 인입 및 인출하는 IPC 패킷들의 라우팅 경로를 결정한다. 인출하는 패킷의 루트는 컴포넌트의 IPC 어드레스에 의해 결정된다. 수신지 어드레스가 로컬 프로세서의 어드레스라고 발견된 경우, IPC를 운영 체제(OS)에 맵핑하는 것은 세션 관리기 내에서 실행된다. 수신지 어드레스가 로컬 IPC 클라이언트에 대해서 발견되면, 패킷은 부가 처리(예를 들어, 캡슐화)를 위하여 IPC 스택으로 전송된다. 수신지 컴포넌트가 IPC 패킷을 전송하는 컴포넌트와 동일한 프로세서 상에 위치되면, 캡슐화가 필요로 되지 않고 패킷은 정상적인 OS 메시지 호출(예를 들어, 마이크로소프트 메시지 큐 등)을 통과된다. 이 방식으로, 컴포넌트들은 자신들의 메시지 입력 방식들을 수정하는 것에 관해서 걱정할 필요가 없다. 이들은 IPC 호출에 대한 OS 특정 설계로부터 단지 자신의 메시지 포스팅 방법론들을 변화시킬 필요가 있다.
인입하는 패킷들에 대해서, 메시지의 수신지 어드레스가 IPC 서버들과 동일하지 않으면, 인입하는 패킷들은 적절한 IPC 클라이언트로 라우팅된다. 인입하는 패킷들의 라우팅은 IPC 서버의 세션 관리기에 의해 취급된다. 그렇치 않으면, 메시지는 컴포넌트 수신지 ID가 유효 컴포넌트 ID 또는 OXFF에 설정되는지에 따라서 정확한 컴포넌트 또는 컴포넌트들로 전달된다.
IPC 라우터 블록은 IPC 데이터를 수신지 컴포넌트로 전송된다. 인입하는 IPC 메시지들은 특히 발신기 컴포넌트 ID 및 가령 오디오, 모뎀 등을 위한 IPC 메시지 옵코드들을 반송한다. IPC 세션 관리기는 IPC 데이터를 정확한 컴포넌트(들)로 전송하도록 자신의 컴포넌트 라우팅 테이블에 의존한다. 동적 라우팅 테이블 및 컴포넌트 라우팅 테이블 둘 다가 IPC 서버/클라이언트에 의해 갱신된다.
파워 업 동안, 각 컴포넌트는 자신의 세션 관리기로 그 자신을 등록하여 IPC 컴포넌트 ID를 얻는다. 게다가, 이는 오디오, 모뎀 등과 같은 인입하는 IPC 메시지들에 가입하여야 한다. 이 정보는 IPC 세션 관리기에 의해 사용을 위하여 컴포넌트 라우팅 테이블에 저장된다.
도11에 도시된 바와 같이 컴포넌트(1102)가 단계(1104)에서 자신의 데이터 요청을 IPC 세션 관리기로 전송할 때, 수신지 IPC 노드(예를 들어, BP)상에서 검사가 행해진다. IPC 노드가 IPC 메시지 옵코드를 지원하지 않는 경우, 에러 응답은 컴포넌트(1102)로 리턴된다. 에러 응답 이외에, IPC 세션 관리기는 특정 옵코드를 수신할 수 있는 모든 IPC 노드들의 갱신을 리턴시킨다. IPC 노드(들)중 어느 노드가 메시지를 재지향시키는 지를 결정하는 것이 컴포넌트 역할이다. IPC 세션 관리기(1006)는 수신지 컴포넌트가 IPC 네트워크에 위치되는 것이 아니라 로컬 프로세서에 위치되지 않는다는 것을 세션 관리기가 결정하는 경우 데이터는 IPC 네트워크 상에 전송되기 전 IPC 헤더 정보로 데이터를 캡슐화하도록 진행할 것이다.
도12에서, 본 발명의 실시예를 따른 IPC 데이터 헤더(1202)가 도시되어 있다. 헤더는 소스 및 수신지 IPC 어드레스들, 소스 포트, IPC 라우터에 의해 제공되는 수신지 포트, IPC 전송 및 소스 IPC 컴포넌트에 의해 제공되는 길이 및 검사합 정보 및 세션 관리기에 의해 제공되는 수신지 IPC 컴포넌트를 포함한다. 메시지 옵코드, 메시지 길이 및 IPC 데이터는 컴포넌트(1204)에 의해 제공된다.
본 발명의 실시예를 따른 통상적인 IPC 데이터 요청은 도13에 도시된다. 단계(1302)에서, 컴포넌트는 갱신 요청을 전송한다. 컴포넌트 갱신 파라미터들은 노드 유형 및 옵코드를 포함한다. 컴포넌트는 자신의 수신지 옵코드를 지원하는 노드 유형들을 탐색한다. 노드 유형이 0xFF와 동일하면, 세션 관리기는 컴포넌트 정보를 모든 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 프로토콜을 위한 APIs중 일부가 이하에 목록화되어 있다.
1). IPC 세션 관리기에 대한 컴포넌트 인터페이스
CreateComponent()
IPC 세션 관리기에서 컴포넌트 데이터베이스를 생성하라. 컴포넌트 데이터 유형들(큰 Endian 대 작은 Endian)과 같은 정보 및 메시지 옵코들에 대한 가입은 IPC 어드레스에 속하는 동적 데이터 라우팅 테이블에 사용된다.
OpenChannelKeep()
IPC 채널을 개방하고, 하나가 이용가능한 경우, ChannelGrant()가 허여된다. 이 채널은 CloseChannel()이 허여될 때까지 예약된다. 컴포넌트들은 QoS 요청들을 IPC 세션 관리기에 요청한다. IPC 채널은 아직 할당지지 않은 경우 컴포넌트 ID를 할당한다(예를 들어 ChannelGrant()).
OpenChannel()
IPC 채널을 개방하고 이용가능한 경우, ChannelGrant()가 허여된다. 파라미터들은 OpenChannelKeep() 프리미티브를 위하여 사용되는 것과 동일하다.
OpenChannelWThru()
IPC 채널을 개방하고 이용가능한 경우, ChannelGrant()가 허여된다. 이는 채널 상에서 캡슐화가 턴오프된다는 것을 의미하는 write thru 채널에 대한 요청이다(예를 들어, Non UDP AT commands)
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()
리퀘스터는 채널 상의 데이터가 전달되었다는 것을 경보받는다.
DataChannelRequest()
리퀘스터는 논리적인 채널 상에 데이터를 전송하길 원한다.
ChannelClose()
IPC 채널 폐쇄를 요청하라. 채널 비활동도 타이머가 만료되고 타임아웃과 관 련된 채널은 폐쇄된다. 이는 또한 채널 에러로 인한 것일 수 있다.
3). IPC 프레젠테이션 관리기에 대한 IPC 세션 관리기
ChannelDataIndication()
요청기는 채널 상의 데이터가 전달되었다는 것을 경보받는다. 이 정보는 정확한 데이터 포맷으로 타겟 컴포넌트로 전달되어야 한다.
4). IPC 하드웨어/IPC 스택 인터페이스
OpenChannel()
물리적 IPC 채널을 개방하고 이용가능한 경우, ChannelGrant()가 허여된다. IPC 세션 관리기는 채널 우선순위 요청들을 IPC 하드웨어에 전송한다.
CloseChannel()
IPC 채널 폐쇄를 요청하라. 이 컴포넌트는 채널을 더이상 필요로 하지 않는다.
ChannelGrant()
물리적 채널이 요청기에 허여된다.
ChannelError()
채널 에러가 발생된다(예를 들어, 인입하는 데이터 또는 물리적 채널 장애에 대한 CRC 장애)
ChannelDataIndication()
요청기는 채널 상의 데이터가 전달되었다는 것을 경보받는다.
DataChannelRequest()
요청기는 물리적 채널 상에 데이터를 전송하길 원한다.
ChannelClose()
IPC 채널 폐쇄를 요청하라. 채널 비활동도 타이머가 만료되고 타임아웃과 관련된 채널은 폐쇄된다. 이는 또한 채널 에러 때문일 수 있다.
도15는 IPC 네트워크를 사용하여 서로와 통신하는 기저대역 프로세서(BP)(1502) 및 애플리케이션 프로세서(AP)(1504)를 갖는 무선 통신 장치(예를 들어, 셀룰러 전화 등)(1500)와 같은 전자 장치의 블록도를 도시한다. 본 발명의 IPC 프로토콜은 통신 장치와 같은 시스템 내의 다수의 프로세서들 간의 통신을 위하여 제공된다. IPC는 이동 애플리케이션(MA) 클라이언트(예를 들어, iDENTM WLAN)가 개인용 통신 시스템(PCS) 애플리케이션과 같은 MA 서버에 등록하도록 하고 2개의 MA들가 자체 MA 내에 각각 의존하는 소프트웨어 아키텍쳐, 운영 체제들, 하드웨어 등에 제한됨이 없이 자유롭게 통신하도록 하는 수단을 제공한다.
지금부터 도16을 참조하면, 소프트웨어 쓰레드들(1602, 1604 및 1606)과 같은 3개의 컴포넌트들이 도시되고 이들은 아웃바운드 스트리밍을 설정한다. 예를 들어, 소프트웨어 쓰레드(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 데이터를 전송한다. 노드가 특정되지 않을 때 컴포넌트들이 또한 자신들의 메시지들을 모든 IPC 노드들에 브로드캐스트하지만, 컴포넌트들(1602, 1604, 및 1606)은 목표 IPC 노드와 함께 자신들의 데이터를 제공한다. 컴포넌트들(1602, 1604 및 1606)은 수신지 컴포넌트들 ID들을 알 필요도 없고 자신들의 관련된 채널들 또는 자신들의 IPC 어드레스를 알 필요도 없다. 인바운드 스트리밍과 관련하여, 메시지 옵코드들은 컴포넌트들을 식별한다. 예를 들어, 도18에서, 컴포넌트들(1602, 1604, 및 1606)은 메시지 옵코드들에 의해 식별된다. 컴포넌트 ID들는 사전 서술된 컴포넌트 라우팅 테이블을 통해서 발견된다. IPC 세션 관리기는 메시지 내의 IPC 옵코드에 가입되는 모든 컴포넌트들에 인입하는 데이터를 라우팅시킨다.
서비스 품질
도19을 참조하면, 3개의 채널들, 즉 채널 A(1902), 채널 B(1904) 및 채널 C(1906)은 상이한 데이터 대역폭 및 채널 우선순위들을 갖는 것으로 도시된다. 이 예에서, 채널 C(1906)는 채널 B(1904)보다 더 높은 우선순위를 갖고 채널 B(1904)는 채널 A(1902) 보다 더 높은 우선순위를 갖는다. 각 채널(1902-1906)은 각 채널로부터 인입하는 데이터가 로딩되는 대응하는 채널 버퍼(1910-1914)를 갖는다. IPC 스택의 장치 인터페이스 층에 위치되는 IPC 스케쥴러(1916)는 채널들(1902-1906)의 대역폭 및 채널 우선순위들을 고려하면서 채널 버퍼들(1910-1914)로부터 인입하는 데이터 패킷들을 검색하고 이들을 IPC 프레임(1918)으로 형성한다. 스케쥴러(1916)는 스케일링된 IPC 프레임 타임과 동일한 데이터 레이트에서 스케일링된 방식으로 채널 버퍼들(1910-1914)로부터 저장된 데이터를 추출하여, IPC 채널 버퍼들(1910-1914)로부터 데이터를 스무드하게 전송한다. IPC 프레임 시간은 IPC 네트워크의 특정 설계 요건들에 따라서 가변할 수 있다.
상술된 바와 같이, IPC 네트워크에 참여하고자 하는 임의의 컴포넌트는 우선 IPC 스택에 등록하여야만 하고 그 후 일부 QoS 파라미터(들)에 기초하여 IPC 채널을 요청한다. QoS 파라미터들은 채널 우선순위, 데이터 레이트 및 다른 널리 공지된 QoS 요건들을 포함하지만 이로 제한되지 않는다. 장치 층 내의 스케쥴러(1916)는 채널들을 위한 데이터 레이트 및 우선순위를 고정시키는 역할을 한다. 채널이 허여되는 경우, 장치 층은 우선순위의 작업상에 채널을 배치한다. 이는 높은 우선순위 채널이 장치 층에서 높은 우선순위 작업이 되도록 보장할 것이다. 장치 층은 상이한 우선순위들을 갖는 OS 작업들로서 채널 우선순위를 구현할 수 있다. 이는 데이터를 전송하는 소프트웨어 컴포넌트들 및 이 데이터의 IPC 스케쥴링 간의 레이턴시의 채널 우선순위에 주의한다.
스케쥴러(1916)는 IPC 링크 상의 각 채널의 데이터 레이트를 보장하는 역할을 한다. 이는 라운드 로빈 방식(예를 들어 고 내지 저 우선순위)으로 각 채널 버퍼를 통해서 진행하고 채널에 할당되는 데이터 레이트를 수용하도록 각 채널로부터 충분한 데이터를 선택(IPC 프레임이 어떤 것이든지 적시에 스케일링)함으로써 이를 행한다. 데이터뿐만 아니라 충분한 데이터가 존재하지 않으면, 다음 채널은 사용되지 않은 데이터 등이 제공된다. 따라서, 각 소프트웨어 컴포넌트마다 QoS의 개념과 함께 작업 우선순위 및 데이터 레이트 스케쥴러의 조합이 본 발명의 실시예에 따라서 QoS 기술을 제공한다.
본 발명의 일 실시예에서, 특정 QoS를 갖는 채널은 컴포넌트가 QoS를 요청하는 포트상에서만 유효하게 된다. 예를 들어, 특정 데이터 레이트는 소프트웨어 쓰레드(1922)와 같은 컴포넌트가 블루투쓰 링크 상에서가 아니라 이 블루투쓰 링크로부터 QoS 레벨을 요청하는 동기식 시리얼 인터페이스(SSI)(1920)와 같은 포트 상에서 만 보장될 수 있는데, 그 이유는 블루투쓰 링크가 QoS 할당 후 포트들을 변경할 수 있기 때문이다.
선택적인 브로드캐스팅
도20은 2개의 컴포넌트들(2002 및 2004)이 동일한 프로세서에 결합될 때 컴포넌트 대 컴포넌트 메시징을 강조하는 도면이다. 이 도시된 예에서, 컴포넌트 A(2002)는 컴포넌트 X(2004)에 본 발명의 IPC 인터페이스를 사용하여 메시지를 전송한다. 컴포넌트 A(2002)는 컴포넌트 X(2004)가 위치되는 곳을 알 필요가 없는데, 그 이유는 이것이 IPC 세션 관리기(2006)의 역할이기 때문이다. IPC 세션 관리기(2006)는 컴포넌트 ID 할당 및 컴포넌트 위치들(프로세서에 결합되는 컴포넌트들)을 추적한다. 이 특정 예에서, 세션 관리기(2006)는 컴포넌트 X(2004)가 컴포넌트 A(2002)와 동일한 프로세서상에 있다는 것을 자신의 데이터베이스로부터 발견한다. 컴포넌트 A(2002) 및 컴포넌트 X(2004)가 단계(2010)에서 IPC 세션 관리기 의 컴포넌트 룩업 테이블(2008) 상의 정보를 조사함으로써 결정된 바와 같이 동일한 프로세서 상에 위치되기 때문에, 메시지는 임의의 IPC 캡슐화를 겪지 않지만 대신 정상적인 OS 메시징 호출(예를 들어, 마이크로소프트 메시지 큐)를 통해서 컴포넌트 X(2004)를 통과한다. 단계(2012)에서, IPC 호출은 OS 인터페이스 표준에 맵핑된다. 이 방식으로, 컴포넌트들(2002 및 2004)과 같은 컴포넌트들은 자신들의 메시지 방식들을 수정하는 것에 관해서 걱정할 필요가 없다. 컴포넌트들(2002 및 2004)은 IPC 호출 특정 방법론에 대해 특정한 OS로부터 자신들의 메시지 포스팅 방법론들을 변화시킬 필요가 없으며, 적절한 메시지들의 라우팅은 IPC 스택들에 의해 수행된다.
지금부터 도21을 참조하면, 2개의 컴포넌트들이 상이한 프로세서들에 결합될 때 컴포넌트 대 컴포넌트 메시징의 예를 도시한다. 이 예에서, 컴포넌트 A(2102)는 컴포넌트 X(2104)와 동일한 프로세서상에 상주하는 것이 아니라 또 다른 프로세서상에 상주한다. IPC 세션 관리기(2106)는 컴포넌트 룩업 테이블(2108)에서 컴포넌트 X(2104)를 조사하여 컴포넌트 X(2104)가 로컬 프로세서에 위치되는지를 단계(2110)에서 결정한다. 이 예에서, 세션 관리기(2106)는 컴포넌트 X(2104)가 로컬 프로세서에 위치되지 않는다는 것을 결정하고 적절한 헤더 및 다른 정보로 단계(2112)에서 메시지를 캡슐화하도록 진행할 것이다. 그 후, 이 메시지는 컴포넌트 X(2104)에 전달하기 위하여 IPC 네트워크상에 전송된다.
도22를 지금부터 참조하면, 모뎀(BP)과 같은 제1 클라이언트(2204) 및 GSM BP와 같은 제2 클라이언트(2206)에 링크되는 Windows CETM AP와 같은 IPC TJJ를 포함하는 IPC 네트워크가 도시된다. 서버(2202) 내에 제1 클라이언트(2204)와 관련된 필터링 테이블(또한 간단히 필터라 칭함)(2208) 및 제2 클라이언트(2206)와 관련된 제2 필터링 테이블(2210)이 위치된다. 서버(2202)에는 소프트웨어 쓰레드(예를 들어, 오디오)와 같은 컴포넌트(2224)가 결합된다. 제1 클라이언트(2204)는 또한 컴포넌트들(2216 및 2218)에 전송되는 메시지들을 필터링하도록 사용되는 필터링 테이블(2212)를 포함하고 제2 클라이언트(2206)는 컴포넌트들(2220 및 2222)에 전송되는 메시지들을 필터링하는데 사용되는 필터링 테이블(2214)을 갖는다. 필터링 테이블(2230)을 갖는 클라이언트(2228)는 클라이언트(2204)에 데이지 체인화된(daisy chained)되는 것이 도시된다. 컴포넌트(2226)는 클라이언트(2228)에 결합되는 것으로 도시된다.
지금부터 도23을 참조하면, 컴포넌트(2216)로부터 옵코드(2304)를 갖는 메시지를 수신하는 필터링 테이블(2308)이 도시된다. 필터링 테이블(2308)은 어느 컴포넌트들/노드들에 옵코드(2304)에 기초하여 메시지를 전달할 필요가 있는지를 결정하는데 사용된다. 예를 들어, "0010"의 옵코드를 갖는 오디오 애플리케이션에 대해서, 상기 옵코드와 관련된 모든 이들 컴포넌트들에는 메시지가 전달된다. 본 발명의 선택적인 브로드캐스팅 기술은 필터링 테이블들이 동적으로 갱신되도록 하여, 클라이언트들이 누구의 메시지들이 IPC 네트워크 내에서 전송되는지를 결정하도록 한다.
본 발명의 일 실시예에서, 도23에 도시된 바와 같은 결합된 컴포넌트/노드 필터링 테이블(2308)을 사용하는 대신에, 별도의 테이블들이 각 클라이언트 및 서버에 유지된다. 이 실시예에서, 별도의 컴포넌트 필터 테이블들 및 노드 필터 테이블들이 사용되는데, 컴포넌트 및 노드 필터링 테이블들은 IPC 노드(클라이언트 및 서버) 마다 제공된다. 이는 클라이언트(2228)와 같은 클라이언트들이 메시지를 클라이언트(2204)와 같은 또 다른 클라이언트(클라이언트들(2228 및 2204)가 모두 데이지 체인화(daisy chained)된다)에 직접적으로 메시지를 전달할 수 있다. 이 예에서, 노드 테이블은 특정 노드에 의해 지원되는 데이터 유형들과 노드들을 링크시키고 컴포넌트 테이블은 특정 옵코드에 링크되는 클라이언트 또는 서버를 위한 컴포넌트들의 리스트를 유지한다.
도24에서, IPC 서버(2414)에 결합된 다수의 IPC 클라이언트들(2402-2412)의 도면이 도시되어 있다. 본 발명의 실시예에 따른 선택적인 브로드캐스팅의 예에서, IPC 클라이언트(2412)((IPC 클라이언트 6)는 상기 IPC 클라이언트(2412)에 할당된 필터링 테이블을 사용하여 IPC 네트워크를 통해 메시지를 브로드캐스팅한다. 각각의 클라이언트(2402-2412)는 관련된 필터링 테이블을 가질 것이며, IPC서버는 클라이언트들을 선택하는데 사용되는 필터링 테이블을 가질 것이다. 도시된 예시적인 예에서, 클라이언트IPC 서버(2414)에 위치되는 클라이언트 6 필터링 테이블(2416)은 IPC 클라이언트(2412)로부터 메시지를 수신시에 메시지를 IPC 클라이언트(2402)(IPC 클라이언트 1), IPC 클라이언트(2406)(IPC클라이언트 3) 및 IPC 클라이언트(2410)(IPC 클라이언트 5)에 선택적으로 브로드캐스팅하는 것을 돕니다. 이 예에서, 필터링 테이블(2416)은 IPC 클라이언트(2404)(IPC 클라이언트 2) 및 IPC 클 라이언트(2408)(IPC 클라이언트 4)가 메시지를 수신하지 않도록 한다.
각각의 IPC 클라이언트는 자신에 할당되고 IPC 서버(2414) 내에 위치되는 필터링 테이블을 가질 것이다. 각각의 IPC 클라이언트들(2402-2412)의 필터링 테이블은 IPC 링크를 통하여 IPC 노드들에 의해 동적으로 갱신될 수 있다. 이러한 선택적인 브로드캐스팅 특성은 IPC 클라이언트가 메시지가 송신되지 않아야 하는 그러한 IPC 클라이언트들을 필터링함으로써 메시지를 선택된 타겟들에 송신하도록 한다. 필터 테이블(2416)은 임의의 IPC 클라이언트를 통신용 IPC 데이터 링크 내로 동적으로 포함시키는 성능을 허용한다. 따라서, IPC 네트워크는 임의의 컴파일 시간 종속성들 없이 이 방식으로 동적으로 형성될 수 있다. 선택적인 브로드캐스팅 특성은상이한 IPC 클라이언트들 상의 다른 소프트웨어 컴포넌트들과 통신하도록 소프트웨어 컴포넌트들에 동적인 방법을 제공한다. 선택적인 브로드캐스팅 특성은 IPC 클라이언트들이 고정된 세트들의 전용 IPC 채널들 및 전용 대역폭들로 미리구성되지 않도록 한다. IPC 스택 및 상기 스택 아래에 위치된 하드웨어는 또한 그것들이 필요로 될 때, 컴포넌트들이 통신하기 위해 상이한 링크를 선택할 수 있도록 앱스트랙트된다.
IPC 프로토콜은 통신용 IPC 링크 내로 임의의 IPC를 따르는 MA의 동적인 부가를 허용한다. 따라서, IPC 네트워크는 임의의 컴파일 시간 종속성들, 또는 임의의 다른 소프트웨어 가정들 없이 형성된다. 본 발명의 IPC는 소프트웨어 컴포넌트들이 IPC 스택과 통신하도록 하는 표준 방식을 제공하며, 상기 스택 아래의 하드웨어는 컴포넌트들이 통신하기 위해 상이한 링크를 선택할 수 있도록 앱스트랙트된 다. QoS 및 선택적인 브로드캐스팅 특성들은 클라이어트들 및 컴포넌트들의 유연성이 개선되도록 함으로써 개선된 IPC 성능을 제공한다.
본 발명의 바람직한 실시예들이 도시되고 서술되었지만, 본 발명이 이에 국한되지 않는다는 것이 명백할 것이다. 다수의 변형들, 변화들, 변경들, 대체들 및 등가물들이 첨부된 청구항들에 의해 규정된 바와 같은 본 발명의 정신과 범위를 벗어나지 않고 당업자들에 의해 행해질 것이다.

Claims (15)

  1. 청구항 1은(는) 설정등록료 납부시 포기되었습니다.
    프로세서간 통신(interprocessor communication; IPC) 네트워크에 있어서,
    IPC 클라이언트;
    상기 IPC 클라이언트에 결합되는 컴포넌트;
    상기 IPC 클라이언트에 결합되는 IPC 서버를 포함하고, 상기 IPC 서버는 상기 컴포넌트에 의해 전송되는 메시지가 전송될 필요가 있는 곳을 결정하는데 사용하기 위한 적어도 하나의 필터링 테이블을 포함하는, 프로세서간 통신(IPC) 네트워크.
  2. 청구항 2은(는) 설정등록료 납부시 포기되었습니다.
    제1항에 있어서, 상기 컴포넌트로부터의 메시지들은 옵코드(opcode)를 포함하고 상기 적어도 하나의 필터링 테이블은 상기 컴포넌트에 의해 전송되는 메시지들이 전송될 필요가 있는 곳을 결정하기 위해 상기 옵코드를 사용하는, 프로세서간 통신(IPC) 네트워크.
  3. 청구항 3은(는) 설정등록료 납부시 포기되었습니다.
    제1항에 있어서, 상기 IPC 클라이언트 및 상기 IPC 서버는 상기 적어도 하나의 필터링 테이블의 내용들을 교섭(negotiate)할 수 있는, 프로세서간 통신(IPC) 네트워크.
  4. 청구항 4은(는) 설정등록료 납부시 포기되었습니다.
    제1항에 있어서, 상기 IPC 클라이언트는 필터링 테이블을 더 포함하는, 프로 세서간 통신(IPC) 네트워크.
  5. 청구항 5은(는) 설정등록료 납부시 포기되었습니다.
    제4항에 있어서, 상기 IPC 클라이언트에 위치되는 상기 필터링 테이블은 메시지들이 상기 컴포넌트에 의해 수신되어야 하는지의 여부를 결정하는, 프로세서간 통신(IPC) 네트워크.
  6. 청구항 6은(는) 설정등록료 납부시 포기되었습니다.
    제5항에 있어서, 상기 IPC 클라이언트에 결합되는 제2 컴포넌트를 더 포함하며, 상기 클라이언트 내의 상기 필터링 테이블은 상기 IPC 클라이언트에 결합되는 제1 및 제2 컴포넌트 중 임의의 컴포넌트가 상기 IPC 클라이언트에 전송되는 메시지를 수신해야 하는지의 여부를 결정하는, 프로세서간 통신(IPC) 네트워크.
  7. 청구항 7은(는) 설정등록료 납부시 포기되었습니다.
    IPC 클라이언트, IPC 서버 및 상기 IPC 클라이언트에 결합되는 컴포넌트를 갖는 프로세서간 통신(IPC) 네트워크에서 선택적인 브로드캐스팅(broadcasting)을 제공하는 방법으로서,
    상기 컴포넌트에 의해, 옵코드를 갖는 메시지를 전송하는 단계;
    상기 IPC 서버에서 상기 메시지를 수신하는 단계;
    상기 서버에 의해, 상기 메시지가 보내질 필요가 있는 곳을 결정하기 위하여 상기 IPC 클라이언트와 관련된 필터 테이블을 사용하는 단계를 포함하는, 선택적인 브로드캐스팅 제공 방법.
  8. 청구항 8은(는) 설정등록료 납부시 포기되었습니다.
  9. 청구항 9은(는) 설정등록료 납부시 포기되었습니다.
    제7항에 있어서, 상기 필터 테이블은 상기 옵코드를 갖는 컴포넌트에 의해 전송되는 메시지들을 수신하는 상기 IPC 네트워크에 결합되는 다른 모든 컴포넌트들로 상기 옵코드를 링크시키는, 선택적인 브로드캐스팅 제공 방법.
  10. 청구항 10은(는) 설정등록료 납부시 포기되었습니다.
    제7항에 있어서, 상기 옵코드는 서비스와 연관되는, 선택적인 브로드캐스팅 제공 방법.
  11. 프로세서간 통신(IPC) 네트워크에 있어서,
    프레젠테이션 관리기, IPC 세션 관리기 및 장치 인터페이스 층을 갖는 IPC 스택;
    IPC 스택에 결합되며, 서비스 품질(QoS)에 기초한 채널이 할당되는 컴포넌트;
    상기 장치 인터페이스 층에 결합되는 IPC 스케쥴러를 포함하며,
    상기 IPC 스케쥴러는 상기 채널에 할당되는 상기 QoS를 제공할 수 있는, 프로세서간 통신(IPC) 네트워크.
  12. 제11항에 있어서, 상기 IPC 스케쥴러는 상기 채널에 의해 필요로 되는 데이 터 레이트를 보장하는, 프로세서간 통신(IPC) 네트워크.
  13. 제12항에 있어서,
    상기 채널에 결합되는 채널 버퍼를 더 포함하며, 상기 채널 버퍼는 상기 채널을 통해서 전송될 데이터를 저장하는, 프로세서간 통신(IPC) 네트워크.
  14. 제13항에 있어서, 상기 IPC 스케쥴러는 상기 채널에 의해 요구되는 상기 데이터 레이트를 지원하기 위해 상기 채널 버퍼로부터 충분한 데이터를 선택하는, 프로세서간 통신(IPC) 네트워크.
  15. 제14항에 있어서, 상기 IPC 스케쥴러는 상기 IPC 스케쥴러에 의해 사용되는 IPC 프레임의 크기에 의존하여 상기 채널 버퍼로부터 선택되는 상기 데이터를 스케일링하는, 프로세서간 통신(IPC) 네트워크.
KR1020067002154A 2003-07-29 2004-07-20 보장된 서비스 품질 및 선택적인 브로드캐스팅을 제공하는프로세서간 통신 프로토콜 KR100812680B1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US10/631,043 2003-07-29
US10/631,043 US20050027824A1 (en) 2003-07-29 2003-07-29 Interprocessor communication protocol providing guaranteed quality of service and selective broadcasting

Publications (2)

Publication Number Publication Date
KR20060041301A KR20060041301A (ko) 2006-05-11
KR100812680B1 true KR100812680B1 (ko) 2008-03-27

Family

ID=34103968

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020067002154A KR100812680B1 (ko) 2003-07-29 2004-07-20 보장된 서비스 품질 및 선택적인 브로드캐스팅을 제공하는프로세서간 통신 프로토콜

Country Status (5)

Country Link
US (1) US20050027824A1 (ko)
EP (1) EP1652101A1 (ko)
JP (1) JP2007500474A (ko)
KR (1) KR100812680B1 (ko)
WO (1) WO2005013140A1 (ko)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101841925B (zh) 2010-04-21 2012-10-17 华为终端有限公司 一种双中央微处理器间的通信方法、装置及系统
US20160055578A1 (en) * 2014-08-21 2016-02-25 George Janas System and method for monitoring student loan debt relief
US20160381191A1 (en) * 2015-06-26 2016-12-29 Intel IP Corporation Dynamic management of inactivity timer during inter-processor communication
CN107734705A (zh) * 2016-08-12 2018-02-23 中兴通讯股份有限公司 动态调度的方法及装置
WO2018035722A1 (zh) * 2016-08-23 2018-03-01 华为技术有限公司 会话管理方法及装置
CN112492299A (zh) * 2020-11-25 2021-03-12 杭州视洞科技有限公司 一种通过app在局域网内诊断和处理ipc异常问题的方法

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004073701A (ja) * 2002-08-22 2004-03-11 Maruhon Ind Co Ltd 遊技機、コンピュータプログラム及び記録媒体
US6738361B1 (en) 2000-05-31 2004-05-18 Nokia Ip Inc. Method, apparatus and computer program for IP traffic prioritization in IP networks

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3490473B2 (ja) * 1993-02-17 2004-01-26 松下電器産業株式会社 プロセッサ間通信システム
ES2108646B1 (es) * 1995-11-30 1998-07-01 Telefonica Nacional Espana Co Estructura para un sistema de informacion electronica.
DE19625002B4 (de) * 1996-06-22 2005-03-10 Daimler Chrysler Ag Fahrzeugkommunikationssystem
US6907032B2 (en) * 2000-03-06 2005-06-14 Goremote Internet Communications, Inc. Method for selecting terminating gateways for an internet telephone call using a tree search
EP1213895B1 (en) * 2000-12-08 2007-09-05 Sony Deutschland GmbH High-level interface for QoS-based mobile multimedia applications
US6751475B1 (en) * 2000-10-19 2004-06-15 At&T Wireless Services, Inc. Shared-revenue billing system for transmission of wireless data from a vehicle
KR100358153B1 (ko) * 2000-12-18 2002-10-25 한국전자통신연구원 서비스 품질을 지원하는 아이피 패킷 포워딩 분산 처리장치 및 그 방법
JP2004536382A (ja) * 2001-04-09 2004-12-02 オブジェクティブ インターフェイス システムズ，インコーポレイティド 置換可能なサービス品質機能のあるネットワーク通信チャネルコンポーネントを選択するために、置換可能なコンポーネントを用いるシステム、方法及び製造物
US7580517B2 (en) * 2001-06-05 2009-08-25 Tekelec Methods and systems for providing duplicate point code support in a signaling message routing node
US7587517B2 (en) * 2002-07-08 2009-09-08 Precache Inc. Packet routing via payload inspection for quality of service management
JP2006518064A (ja) * 2003-01-23 2006-08-03 ユニバーシティー オブ ロチェスター マルチクロックドメインを有するマイクロプロセッサ
US7673054B2 (en) * 2003-07-28 2010-03-02 Sap Ag. Grid manageable application process management scheme

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6738361B1 (en) 2000-05-31 2004-05-18 Nokia Ip Inc. Method, apparatus and computer program for IP traffic prioritization in IP networks
JP2004073701A (ja) * 2002-08-22 2004-03-11 Maruhon Ind Co Ltd 遊技機、コンピュータプログラム及び記録媒体

Also Published As

Publication number Publication date
US20050027824A1 (en) 2005-02-03
WO2005013140A1 (en) 2005-02-10
KR20060041301A (ko) 2006-05-11
EP1652101A1 (en) 2006-05-03
JP2007500474A (ja) 2007-01-11

Similar Documents

Publication Publication Date Title
US20050010925A1 (en) Interprocessor communication protocol with smart streaming port
US8326918B2 (en) Interprocessor communication protocol
KR101021566B1 (ko) 우선 순위와 예약 대역폭 프로토콜을 활용하여 네트워크에서비스 품질(ＱｏＳ)을 제공하는 메커니즘
JP4820940B2 (ja) ポート群を動的に専用化するプロセッサ間通信ネットワーク
JP2007526544A5 (ko)
US7356594B2 (en) Interprocessor communication protocol providing intelligent targeting of nodes
KR100812680B1 (ko) 보장된 서비스 품질 및 선택적인 브로드캐스팅을 제공하는프로세서간 통신 프로토콜
KR100787850B1 (ko) 고레벨 서비스 구성을 갖는 인터프로세서 통신 프로토콜
KR100805094B1 (ko) 포트들의 동적 전용을 제공하는 인터프로세서 통신네트워크
CN113225257B (zh) 一种upf数据处理的方法、系统及存储介质
US11469990B2 (en) Techniques for interaction between network protocols

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
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 20080612

Effective date: 20090330

FPAY Annual fee payment

Payment date: 20130227

Year of fee payment: 6

FPAY Annual fee payment

Payment date: 20140227

Year of fee payment: 7

FPAY Annual fee payment

Payment date: 20150225

Year of fee payment: 8

FPAY Annual fee payment

Payment date: 20160223

Year of fee payment: 9

LAPS Lapse due to unpaid annual fee