KR20040097296A - 멀티클러스터 네트워크에서의 통신 방법, 클러스터네트워크에 연결하기 위한 디바이스, 및 클러스터를연결하기 위한 브리지 - Google Patents

Abstract

브리지 디바이스(bridge device)는 네트워크에 있는 네트워크 디바이스의 각 클러스터(cluster)들을 인터페이싱하기 위한 적어도 2개의 인터페이스를 포함하며, 상기 브리지 디바이스는 클러스터들을 연결하기 위한 적어도 2개의 인터페이스 포털(portal)을 포함한다. 이 브리지 디바이스는 각 포털에 대해 내부 클라이언트로부터 적어도 하나의 네트워크 디바이스의 디바이스 설명 컨피규레이션 메모리 데이터(SDD)에 대한 요청을 수신하기 위한 제 1 소프트웨어 성분(SDDM)을 포함하며, 상기 제 1 소프트웨어 성분은 다른 디바이스에 있는 유사한 소프트웨어 성분의 기능 호출(function call)을 통해 다른 디바이스로부터 디바이스 설명 데이터를 검색하도록 적응된다. 본 발명은, 또한 전술된 바와 같은 소프트웨어 성분을 포함하는, 멀티 클러스터 네트워크(multi-clustered network) 내의 디바이스 뿐만 아니라 디바이스 디스커버리 방법 및 디바이스 사이의 연결을 설정하기 위한 방법에 관한 것이다.

Description

멀티클러스터 네트워크에서의 통신 방법, 클러스터 네트워크에 연결하기 위한 디바이스, 및 클러스터를 연결하기 위한 브리지{METHODS FOR COMMUNICATION IN A MULTI-CLUSTER NETWORK, DEVICE FOR CONNECTION TO A NETWORK OF CLUSTERS AND BRIDGE FOR CONNECTING CLUSTERS}

HAVi - Home Audio/Video interactive의 약자 - 는 IEEE 1394 버스(2000년 버전에 의해 개선된 1995년 버전)에 현재 규정(2001년, 5월 15일에 발행된 버전 1.1)되어 있으며 따라서 IEEE 1394의 제한 사항을 계승한다. 한 가지 제한 사항은 하나의 클러스터 네트워크를 사용하는 것이다.

그러한 HAVi 네트워크는, 홈 네트워크가 일반적으로 집 내의 모든 디바이스를 연결하여야 하는 것이지만, 집 전체에 걸쳐 배치하기에는 어렵다. 몇 개의 별개의 HAVi 클러스터를 연결하는 것이 바람직하다.

톰슨 라이센싱 소시에떼 아노님(Thomson Licensing SA)이라는 이름으로 출원된 2002년, 11월 21일에 출원된 PCT 특허 출원 EP02/013175 및 EP02/13179는 GUID 프록시 기술(proxy technique)을 사용하여 UPnP 네트워크에 HAVi 네트워크를 연결하기 위한 게이트웨이에 관한 것이다.

본 출원은 브리지 디바이스(bridge device)와 네트워크 디바이스, 특히 이들 디바이스에 구현되는 소프트웨어 성분(software component)과 멀티 클러스터 환경(multi-cluster environment)에서 그 상호작용을 기술한다.

여러 소프트웨어 성분은 독립적인 객체(entity)와 발명을 자체적으로 구성하며 서로 별도로 청구될 수 있다는 것을 주목하여야 한다.

본 발명은, 예를 들어 HAVi 클러스터에 기반을 두고 있지만 HAVi 클러스터로 제한되지는 않는 멀티 클러스터 네트워크에서의 통신 방법 뿐만 아니라 그러한 네트워크에서의 디바이스 및 클러스터들을 연결하기 위한 브리지 디바이스에 관한 것이다.

도 1 은 멀티 클러스터(multi-cluster) HAVi 네트워크를 나타내는 도면.

도 2 는 HAVi-HAVi 브리지(bridge)를 나타내는 도면.

도 3 은 SddManager를 사용하는 여러 경우를 예시하는 네트워크를 나타내는 도면.

도 4 은 CMM을 사용하는 예를 보여주는 멀티 클러스터 HAVi 네트워크를 나타내는 도면.

도 5 는 브리지를 통해 메시지를 송신하는 예를 도시하는 도면.

도 6 은 이벤트 발송 알고리즘(event posting algorithm)을 나타내는 도면.

도 7 은 레지스트리(registry)를 위한 트래픽(traffic) 개선을 나타내는 도면.

도 8 은 브리지 레지스트리(bridge Registry)를 위한 요청/응답 알고리즘을 나타내는 도면.

도 9 는 종래 기술의 HAVi 스트림 연결 모델을 나타내는 도면.

도 10 은 멀티 클러스터 스트림 구축(multi-clustered stream building)을 예시하는 도면.

도 11 은 대안적인 데이터 루트(route)를 예시하는 멀티 클러스터 네트워크를 나타내는 도면.

도 12 는 HAVi 브리지 인식 디바이스(bridge aware device)의 소프트웨어 아키텍처(architecture)를 나타내는 도면.

도 13 은 로컬 디스커버리 프로세스(local discovery process)를 예시하는 멀티 클러스터 네트워크를 나타내는 도면.

도 14 는 리브 브리지(leaves bridges)에서 제 1 리모트 리스트 업데이트를 예시하는 멀티 클러스터 네트워크를 나타내는 도면.

도 15 는 브리지 네트워크 매니저 상호작용을 예시하는 멀티 클러스터 네트워크를 나타내는 도면.

도 16 은 네트워크 매니저 글로벌 리스트를 구축하는 프로세스를 예시하는 도면.

도 17 은 네트워크 매니저 상에 클라이언트 호(client call)를 예시하는 멀티 클러스터 네트워크를 나타내는 도면.

도 18 은 리모트 리스트의 개념을 예시하는 멀티 클러스터 네트워크를 나타내는 도면.

도 19 는 새로운 디바이스의 연결을 예시하는 도면.

도 20 은 업데이트된 리모트 리스트의 전파를 예시하는 도면.

도 21 은 루프(loop)가 있는 네트워크에서 로컬 디스커버리 프로세스를 예시하는 도면.

도 22 는 포털(portal)이 리모트 리스트를 요청하는 프로세스를 예시하는 도면.

도 23 은 불완전한 리모트 리스트로 포털을 업데이트하는 프로세스를 예시하는 도면.

도 24 는 이벤트(event)를 사용하여 불완전한 리모트 리스트를 송신하는 예를 도시하는 도면.

도 25 는 GUID 프록시 기술(proxy technique)을 사용하여 브리지와 2개의 HAVi 클러스터를 포함하는 네트워크를 나타내는 도면.

본 발명은, 네트워크에 있는 네트워크 디바이스의 각 클러스터(cluster)를 인터페이싱하기 위한 적어도 2개의 인터페이스를 포함하며, 클러스터들을 연결하기 위해 적어도 2개의 인터페이스 포털(interface portal)을 포함하는, 브리지 디바이스(bridge device)로서, 상기 브리지 디바이스는 각 포털에 대해 적어도 하나의 네트워크 디바이스의 디바이스 설명 컨피규레이션 메모리 데이터(device describing configuration memory data)(SDD)에 대한 요청을 내부 클라이언트로부터 수신하기 위한 제 1 소프트웨어 성분을 포함하며, 상기 제 1 소프트웨어 성분은 다른 디바이스에 있는 이와 유사한 소프트웨어 성분의 기능 호(function call)를 통해 다른 디바이스로부터 디바이스 설명 데이터를 검색하도록 적응되는 것을 특징으로 하는, 브리지 디바이스에 관한 것이다.

본 발명의 일 실시예에서, 상기 제 1 소프트웨어 성분은 리모트 클러스터 디바이스(remote cluster device)로 가는 경로 상에 있는 브리지 디바이스의 이와 유사한 소프트웨어 성분에 대한 기능 호를 통해 이와 유사한 소프트웨어 성분 없이 리모트 클러스터 디바이스에 대한 데이터를 검색하도록 적응된다.

본 발명의 일 실시예에서, 상기 제 1 소프트웨어 성분은 매체 종속 요청 메시지를 한 디바이스에 송신하는 것에 의해 자기 자신과 동일한 클러스터 상에 유사한 소프트웨어 성분이 없는 상기 디바이스에 대한 데이터를 검색하도록 적응된다.

본 발명의 일 실시예에서, 상기 제 1 소프트웨어 성분은,

a. 상기 네트워크 상에 다른 디바이스의 제 1 소프트웨어 성분의 식별자의 리스트(list)와,

b. 상기 리스트 내의 디바이스로 가는 경로에서 최단 거리에 있는 포털의 각 식별자와 연관된, 유사한 제 1 소프트웨어 성분이 없는 디바이스의 리스트

중 적어도 하나를 유지하도록 적응된다.

본 발명의 일 실시예에서, 상기 제 1 소프트웨어 성분은 그 포털 로컬 클러스터 상의 제 1 소프트웨어 성분이 없는 디바이스의 디바이스 설명 데이터에서의 변화를 모니터하며 상기 브리지 디바이스의 다른 포털에 연결된 상기 클러스터 상에 대응하는 디바이스 설명 데이터 변화 이벤트를 생성하도록 적응된다.

본 발명의 일 실시예에서, 본 브리지 디바이스는, 각 포털에 대해 상기 포털 클러스터의 통신 매체와 각 포털의 포털의 다른 소프트웨어 성분을 인터페이싱하기 위한 제 2 소프트웨어 성분을 더 포함하며, 상기 제 2 소프트웨어 성분은 상기 통신 매체에 리모트로 억세스하기 위해 상기 네트워크의 다른 디바이스의 소프트웨어성분에 적어도 특정 방법이 전체적으로 억세스되는 어플리케이션 프로그래밍가능한 인터페이스를 더 포함한다.

본 발명의 일 실시예에서, 상기 전체적으로 억세스가능한 방법은 쓰기(write), 읽기(read), 잠금(lock), 등록(enroll), 탈퇴(drop), 지시 (indication) 중에서 적어도 하나를 포함한다.

본 발명의 일 실시예에서, 본 브리지 디바이스는 각 포털에 대해 상기 네트워크의 모든 클러스터 상의 모든 디바이스의 리스트를 유지하기 위한 제 3 소프트웨어 성분을 더 포함한다.

본 발명의 일 실시예에서, 상기 제 3 소프트웨어 성분은 네트워크의 임의의 클러스터에 대한 변화의 검출시에, 그 변화의 특성을 그 포털의 소프트웨어 성분에게 알리는 제 1 이벤트를 생성하도록 적응된다.

본 발명의 일 실시예에서, 상기 제 3 소프트웨어 성분은 이벤트 발행 포털의 리모트 디바이스 리스트의 상태만을 다른 포털의 제 3 소프트웨어 성분에게 알리기 위한 제 2 이벤트를 생성하도록 적응된다.

본 발명의 일 실시예에서, 상기 제 2 이벤트는 이벤트 발행 포털, 즉 상기 이벤트 발행 포털의 공동 포털을 통해 도달가능한 디바이스에 비해 리모트 디바이스의 불완전 리스트를 잠재적으로 포함한다.

본 발명의 일 실시예에서, 상기 제 3 소프트웨어 성분은 호스팅 포털의 리모트 디바이스 리스트가 안정적이라는 것을 클러스터 상의 모든 디바이스의 제 3 소프트웨어 성분에 알리기 위한 제 3 이벤트를 생성하도록 적응된다.

본 발명의 일 실시예에서, 상기 제 3 이벤트는 이벤트 발행 포털, 즉 상기 이벤트 발행 포털의 공동 포털을 통해 도달가능한 디바이스에 비해 리모트 디바이스의 완전한 리스트를 포함한다.

본 발명의 일 실시예에서, 각 포털은 포털 로컬 클러스터 상에서 검출된 이벤트 메시지를 공동 포털로 송신하기 위한 제 4 소프트웨어 성분을 포함한다.

본 발명의 일 실시예에서, 각 포털은 브리지 클러스터 중 하나에서 다른 디바이스의 제 5 소프트웨어 성분으로부터의 요청을 수신하기 위한 제 5 소프트웨어 성분과, 소스 주소(source address)로서 초기 요청자의 식별자와 함께 다른 클러스터 상의 제 5 소프트웨어 요소에 상기 요청을 송신하며 상기 요청에 대한 비-연관된 응답을 초기 요청 디바이스로 송신하기 위한 수단을 포함한다.

본 발명의 일 실시예에서, 각 포털은, 브리지 클러스터 중 하나에서, 다른 디바이스의 제 5 소프트웨어 성분으로부터 요청을 수신하기 위한 제 5 소프트웨어 성분과, 상기 요청을 다른 클러스터에 있는 제 5 소프트웨어 요소에 송신하며 여기서 송신된 요청은 송신 포털의 소스 주소를 파라미터로 포함하는, 송신된 요청을 수신하며 그 응답을 연관시키며, 그리고 이 요청에 대한 연관된 응답을 초기 요청 디바이스에 송신하기 위한 수단을 포함한다.

본 발명의 일 실시예에서, 상기 요청을 송신하기 위한 수단은 상기 요청을 상기 브리지 디바이스의 제 5 소프트웨어 요소에 송신하기 위한 제 1 메시지 타입을 사용하고 상기 요청을 비-브리지 디바이스의 제 5 소프트웨어 요소로 송신하기 위한 제 2 메시지 타입을 사용하도록 적응되며, 여기서 송신 포털의 식별자는 제 2메시지에서가 아니라 제 1 메시지에서 하나의 파라미터이다.

본 발명의 일 실시예에서, 각 포털은 브리지 클러스터의 하나에서, 다른 디바이스의 제 5 소프트웨어 성분으로부터 요청을 수신하기 위한 제 5 소프트웨어 성분과, 다른 클러스터 상의 제 5 소프트웨어 요소에 소스 주소로서 초기 요청자 식별자와 함께 상기 요청을 송신하며 이 송신된 요청에 응답을 가로채며, 이들 응답 내용을 연관시키며, 초기 요청에 대한 하나의 연관된 응답을 초기 요청 디바이스로 되송신하기 위한 수단을 포함한다.

본 발명의 일 실시예에서, 본 브리지 디바이스는 클러스터의 통신 매체 사이에 패킷 트랜스포트 타입을 변환시키기 위한 수단을 포함한다.

본 발명의 일 실시예에서, 각 포털은 다른 디바이스의 제 6 소프트웨어 요소로부터 연결 설정 요청을 수신한 때 브리지를 가로지르는 연결을 위해 로컬 클러스터 상에 연결 세그먼트(connection segment)를 설정하기 위한 제 6 소프트웨어 요소를 포함한다.

본 발명의 일 실시예에서, 포털의 제 6 소프트웨어 요소는 로컬 클러스터에 대한 연결을 설정하도록 적응되며 연결 종단 디바이스(connection end device)로 가는 경로 상에 그 다음 세그먼트 설정을 실행하도록 로컬 클러스터를 그 다음 포털에 알려준다.

본 발명의 다른 목적은, 멀티 클러스터 네트워크(multi-cluster network) 내의 클러스터에 연결하기 위한 디바이스로서, 여기서 클러스터는 브리지 디바이스를 통해 연결되며, 각 브리지 디바이스는 적어도 2개의 클러스터 인터페이스를 포함하며, 여기서 각 인터페이스는 각 클러스터 상의 네트워크 디바이스로 간주되는, 디바이스에 있어서, 상기 네트워크 디바이스는 적어도 제 2 디바이스의 디바이스 설명 컨피규레이션 메모리 데이터에 대한 요청을 내부 클라이언트로부터 수신하기 위한 제 1 소프트웨어 성분을 포함하며, 상기 제 1 소프트웨어 성분은 상기 적어도 하나의 디바이스에서 유사한 소프트웨어 성분의 기능 호(function call)를 통해 적어도 하나의 다른 디바이스로부터 디바이스 설명 데이터를 검색하도록 적응되는, 멀티 클러스터 네트워크에서 클러스터에 연결하기 위한 디바이스이다.

본 발명의 일 실시예에서, 상기 제 1 소프트웨어 성분은 리모트 클러스터 디바이스로의 경로 상에 브리지 디바이스의 유사한 소프트웨어 성분에 대한 기능 호를 통해 유사한 소프트웨어 성분이 없는 리모트 클러스터 디바이스에 대한 데이터를 검색하도록 적응된다.

본 발명의 일 실시예에서, 상기 제 1 소프트웨어 성분은 매체 종속적인 요청 메시지를 제 2 디바이스에 발송하는 것에 의해 자기 자신과 동일한 클러스터 상에 유사한 소프트웨어 성분이 없는 제 2 디바이스에 대한 데이터를 검색하도록 적응된다.

본 발명의 일 실시예에서, 상기 제 1 소프트웨어 성분은,

- 상기 네트워크 상에 다른 디바이스의 제 1 소프트웨어 성분의 식별자의 리스트와,

- 이 리스트에 있는 상기 디바이스로의 경로 상에서 최단 거리에 있는 포털의 각 식별자와 연관된, 유사한 제 1 소프트웨어 성분이 없는 디바이스의 리스트

중 적어도 하나를 유지하도록 적응된다.

본 발명의 일 실시예에서, 본 디바이스는 상기 네트워크의 모든 클러스터 상에 있는 모든 디바이스의 리스트를 유지하기 위한 제 3 소프트웨어 성분을 더 포함하며, 여기서 상기 제 3 소프트웨어 성분은 로컬 클러스터에 연결된 포털로부터 리모트 디바이스 리스트를 검색하며 그리고 로컬 클러스터 디바이스 리스트와 상기 리모트 디바이스 리스트를 연관시키기 위한 수단을 포함한다.

본 발명의 일 실시예에서, 상기 제 3 소프트웨어 성분은 디바이스 소유의 로컬 클러스터에 비해 리모트 디바이스에 대한 경로 상에서 최단 거리에 있는 포털의 지시(indication)를 상기 네트워크 디바이스 리스트에 유지하도록 더 적응된다.

본 발명의 일 실시예에서, 본 디바이스는 로컬 클라이언트로부터 리모트 소프트웨어 요소의 리스트에 대한 요청을 수신하며 상기 요청을 상기 로컬 클러스터의 디바이스의 제 5 소프트웨어 요소에만 송신하기 위한 제 5 소프트웨어 성분을 포함한다.

본 발명의 일 실시예에서, 본 디바이스는 싱크 디바이스(sink device)와 소스 디바이스(source device) 사이의 연결을 설정하기 위한 요청을 수신하도록 적응된, 동일한 디바이스의 클라이언트에 대한 어플리케이션 프로그래밍 가능한 인터페이스를 구비하는 제 6 소프트웨어 요소를 포함하며, 상기 제 6 소프트웨어 요소는 상기 소스 디바이스와 싱크 디바이스 사이의 경로 상에서, 싱크 디바이스로의 경로 상에 소스 디바이스에서 최단 거리의 포털을 결정하도록 적응되며, 상기 제 6 소프트웨어 요소는 적절한 요청을 로컬 클러스터 상의 연결을 설정하기 위한 상기 포털로 송신하며 상기 요청을 상기 경로 상에 다른 적절한 포털로 전파하도록 적응된다.

또한 브리지의 포털은 로컬 클러스터 상의 디바이스라는 것을 주목해야 한다.

본 발명의 또 다른 목적은, 적어도 2개의 디바이스 클러스터와 적어도 하나의 브리지를 포함하는 네트워크에서 디바이스를 발견(discovery)하기 위한 방법으로서, 여기서 적어도 2개의 클러스터는 브리지에 의해 연결되며, 각 브리지는 각 클러스터에 연결하기 위한 적어도 2개의 인터페이스 포털을 포함하는, 네트워크에서 디바이스를 발견하기 위한 방법에 있어서,

- 각 포털이 로컬 클러스터의 디바이스의 식별자(GUID)의 리스트를 획득하게 하는 단계와,

- 각 포털이 자기 자신과 동일한 클러스터의 각 포털로부터 리모트 디바이스 리스트를 요청하게 하는 단계와,

- 각 포털이 공동 포털(co-portal)을 통해 도달가능한 리모트 디바이스와 그 로컬 디바이스의 리스트를 그 공동 포털로부터 요청하는 것에 의해 자기 소유의 리모트 디바이스 리스트를 구축하게 하는 단계

를 포함하는, 네트워크에서 디바이스를 발견하기 위한 방법이다.

본 발명의 일 실시예에 있어서, 본 방법은 주어진 디바이스가 그 디바이스로 가는 최단 거리의 경로 상에 있는 경우, 브리지가 주어진 디바이스로 향하는 메시지를 통과시키게 하는 단계를 더 포함한다.

본 발명의 일 실시예에 있어서, 상기 최단 거리의 경로는 횡단되는 포털의 수가 최저가 되는 경로이다.

본 발명의 또다른 목적은, 클러스터와의 연결을 위한 인터페이스 포털을 각각 구비하는 브리지 디바이스에 의해 연결된 복수의 디바이스 클러스터를 포함하는 네트워크에서 싱크 디바이스와 소스 디바이스 사이의 연결을 설정하기 위한 방법에 있어서,

(a) 상기 네트워크의 다른 브리지 인식 디바이스에 그리고 브리지의 포털에 스트림 매니저 소프트웨어 요소를 제공하는 단계와,

(b) 로컬 클라이언트로부터의 연결 요청을 디바이스의 스트림 매니저 소프트웨어 요소의 레벨에서 수신하는 단계와,

(c) 싱크 디바이스와 소스 디바이스 사이의 경로 상에, 소스 디바이스에서 최단 거리에 있는 포털을 식별하며 상기 포털에 연결 요청을 송신하는 단계와,

(d) 상기 연결 요청을 수신한 포털이 상기 소스 디바이스와 상기 포털 브리지 사이의 연결 세그먼트를 요청하게 하는 단계와,

(e) 상기 연결 요청을 수신한 포털이 상기 소스 디바이스로 가는 경로 상에 그 브리지의 그 다음 포털로 하여금 그 다음 포털의 로컬 클러스터 상의 연결의 그 다음 세그먼트를 설정하게 하는 단계와,

(f) 상기 싱크 디바이스로 가는 경로 상에, 만약 있다면, 그 다음 브리지를 식별하여, 상기 싱크 디바이스로 가는 경로 상에 상기 그 다음 브리지의 리모트 포털로 하여금 상기 연결의 적절한 세그먼트를 설정하도록 지시하게 하는 단계와,

(g) 상기 싱크 디바이스에 연결하는 세그먼트가 설정될 때까지 단계 (e)로 되돌아가는 단계

를 특징으로 하는, 네트워크에서 소스 디바이스와 싱크 디바이스 사이의 연결을 설정하기 위한 방법이다.

본 발명의 다른 특성은 본 발명의 바람직한 실시예의 상세한 설명에 나타나 있다. 본 발명은 이 실시예로 제한되지 않는다. 이 실시예는 다음 도면을 참조하여 설명된다.

2개의 HAVi 클러스터를 연결하는 한 가지 방법은 소프트웨어 요소의 프록시 접근법(Software Element proxy approach)에 기반을 두고 있다. 도 25는 브리지 디바이스(bridge device)에 의해 링크된 2개의 HAVi 클러스터에 의해 형성된 네트워크의 일례이다. 디바이스와 서브-디바이스(sub-device) 또는 기능(function)은 디바이스 컨트롤 모듈(DCM : Device Control Module)과 기능적 성분 모듈(FCM : Functional Component Module)이라고 각각 불리우는 소프트웨어 요소(software element)에 의해 표현된다(represented).

HAVi 디바이스 발견 프로세스는 IEEE 1394 버스에서 'GUID' 인식에 기반을두고 있다. GUID는 글로벌 유니크 식별자(global unique identifier)를 나타낸다. GUID는 IEEE 1394 디바이스를 고유하게 식별한다.

브리지의 일측에 있는 디바이스는 타측에 있는 디바이스에 의해 인식될 수 없는데, 그 이유는 이 디바이스가 IEEE 1394 레벨에서 보이지 않기 때문이다. 일측에 있는 컨트롤러는 타측에 있는 타깃 디바이스를 사용할 수 없다. 브리지 디바이스는 일측의 DCM 및 FCM의 표현을 구축하여, 이들을 타측의 DCM과 FCM으로, 즉 이들이 표현하는 실제 소프트웨어 요소의 프록시 요소로서 노출시킨다.

도 25에서, 실제 DCM과 FCM은 그 SEID(Software Element ID)로 표현된다. SEID는 이 디바이스 내부에 있는 고유 번호와 GUID(각 디바이스의 하부에 일례가 표시되어 있음)의 조합이다.

이들 DCM과 FCM은 프록시 SE(Software Element)에 의해 브리지의 타측에 표현되어 있다. 이들 DCM과 FCM은 이들을 실제 SE와 구별하기 위해 파선으로 도시되어 있다. 각 실제 DCM과 FCM에는 하나의 프록시 SE가 있다. 제어 어플리케이션은 그 프록시 SE를 통해 브리지 뒤에 있는 실제 타깃 디바이스를 제어할 수 있다.

본 발명의 본 실시예는 GUID 프록시를 사용하는 브리지와 포털에 기반을 두고 있다. 그러나, 본 발명은 이 특정 경우로 제한되지 않는다. 나아가, HAVi 1.1 은 IEEE 1394에 기반을 두고 있는 반면, 본 실시예의 클러스터는 다른 네트워크 기술에 기반을 둘 수도 있으며, 특히 인터넷 프로토콜(IP : Internet Protocol) 또는 무선 기술(IEEE 802.11, Hiperlan2...)에 기반을 둘 수 있다. 본 실시예에서, 이 신축성(flexibility)은 - 일례로서 - GUID 프록시 기술을 사용하는 것에 의해 달성된다. 본 출원의 우선일에 이용가능한 최근의 HAVi 버전은 버전 1.1이다. HAVi 1.1 은 브리지를 기술하고 있지 않으며, 그래서 HAVi 1.1 디바이스가 멀티 클러스터 네트워크에 연결되어 있다면, 이 디바이스는 어떤 브리지도 인식하지 못한다.

본 출원은 HAVi 브리지 디바이스를 먼저 기술하며 후속하여 HAVi 브리지 인식 디바이스의 설명을 기술하며, 즉 브리지 디바이스의 자원(resource)을 끌어들이고(사용하고), 이 브리지 디바이스와 통신할 수 있는 디바이스를 기술한다. 그러한 디바이스는 이 브리지가 HAVi 1.1 디바이스에 투명하지 않기 때문에 요구될 수도 있다.

1] 브리지 디바이스

도 1 은 2개의 브리지(104및 105)에 의해 일렬로 상호 연결된 3개의 클러스터(101 내지 103)를 포함하는 네트워크를 도시한다. 클러스터(101)는 IEEE 1394에 기반을 두고, 클러스터(102)는 IP 기술에 기반을 두는 반면, 클러스터(103)는 예를 들어 IEEE 802.11에 기반을 둔 무선 네트워크이다. 클러스터(102)에 있는 디바이스는 예를 들어 HAVi 디바이스이거나 또는 브리지가 HAVi 프록시 표현을 관리하는 UPnP 디바이스이다.

본 실시예에 따른 GUID 프록시 해법의 원리는, 로컬 클러스터의 외부에 위치된 디바이스의 GUID를 로컬 클러스터에 알려주어, 이로 로컬 HAVi 디바이스가 이 디바이스의 존재를 인식할 수 있게 하는 것이다. 리모트 디바이스의 리모트 GUID가 알려지게 되면, 이 디바이스는 메시징 시스템(Messaging System)이 HAVi 메시지를 내부 표(internal table)에서 어느 디바이스로 송신하여야 하는지를 알기 때문에,HAVi 소프트웨어 요소에 의해 주소지정가능하다. HAVi 메시지가 리모트 디바이스로 송신될 때, 그 메시지의 목적 주소는 프록시 GUID의 주소이다. 프록시 GUID에 기반을 둔 HAVi 응용 모듈(DCM, FCM, 어플리케이션)과 HAVi 미들웨어로부터 오는 메시지는 이 브리지에 의해 적절히 통과된다.

HAVi-HAVi 브리지의 소프트웨어 아키텍처는 도 2에 도시되어 있다. 이 브리지는 본 실시예에 따라 2개의 포털(portal)로 구성되어 있지만, 2개를 초과하는 포털도 가능하다. 각 포털은 HAVi 클러스터(예를 들어, IEEE 1394 - 1995 버스)에 연결되어 있으며 그 클러스터 상에 주소지정가능한 객체(entity)이다. 완전한 HAVi 스택은 브리지 상에 실행된다(run). HAVi 모듈이 단독으로 두 경우를 시뮬레이트(simulate) 하는지 또는 2개의 분리된 모듈이 동일한 기능을 위해 동시에 실행되는지는 구현하기 나름이다. 도 2에서, 단 하나의 메시징 시스템이 표시되어 있지만, 기능적으로 말하면 포털마다 하나씩 존재한다. 소프트웨어 요소 - 및 메시징 시스템은 소프트웨어 요소(Software Element)이다 - 는 이 요소가 상주하는 모드의 GUID로 주소지정되며, 각 포털은 자기 고유의 GUID를 소유한다.

a) SddManager

자기 기술 디바이스 데이터(SDD : Self Describing Device data)는 HAVi 디바이스가 자기 자신에 관한 정보(디바이스 타입, 성능, 버전, 등...)를 다른 디바이스에 제공하는 수단이다. HAVi-1.1에서, SDD는 IEEE 1394 HAVi 디바이스의 컨피규레이션 ROM(GUID와 같은 다른 정보를 포함함)의 일부이며 직접 IEEE 1394 판독 트랜잭션(direct IEEE 1394 Read transactions)을 사용하여 다른 디바이스에 의해판독된다.

이것은 하나의 IEEE 1394 클러스터에서는 정교하지만, HAVi 네트워크가 멀티 클러스터이고 다른 매체 기술 상에 구축될 때에는 그러한 리드 트랜잭션(Read transitions)으로는 불충분하다. 이때 네트워크 상에 임의의 HAVi 디바이스의 SDD 데이터를 판독하기 위한 수단이 필요하다. 이것은 HAVi 메시지를 사용하는 것에 의해 달성될 수 있다. 본 실시예에 따라, 소프트웨어 요소는 메시징 시스템을 사용하여 HAVi 디바이스의 SDD 데이터에 억세스 할 수 있다. 요청시에 SDD 데이터를 임의의 클러스터 상의 임의의 클라이언트에 제공하기 위해, 적절한 어플리케이션 특정 인터페이스(API : application specific interface)가 HAVi 스택에 규정되어 있다.

SddManager는, 이것이 SDD 데이터에 대한 요청을 국부적으로 처리하며 멀리있는 SddManager로부터 오는 응답을 수집한다는 점에서 레지스트리(Registry)와 유사성을 가지나, 레지스트리는 중간 기능(IAV : intermediate functionality)과 풀 기능(FAV : full functionality)이 있는 모든 디바이스에 존재하는 반면 SddManager는 본 실시예에 따라 임의의 브리지 인식 HAVi 디바이스 상에 구현된다는 점에서 차이점이 있는 새로운 시스템 소프트웨어 요소이다. 브리지 인식 디바이스는 FAV 또는 IAV 타입이다(풀 A/V 디바이스 또는 중간 A/V 디바이스). SddManager는 HAVi 1.1 또는 이보다 더 하위 버전의 디바이스에는 존재하지 않는다. 따라서, SddManager가 있는 디바이스는 SddManager가 없는 디바이스와 동일한 클러스터 상에 함께 상주할 수 있다. 이것은, HAVi 디바이스에 있는 클라이언트 어플리케이션이나 소프트웨어 요소가 바람직하게도 모든 요청에 대해 로컬SddManager를 호출할 수 있으며 이 로컬 SddManager 는 모든 정보를 수집하는 것(질문을 다른 SddManager에 송신하는 것이나 및/또는 국부적 낮은 레벨의 동작을 수행하는 것)을 처리할 수 있다는 것을 의미한다. 만일 로컬 SddManager가 이 디바이스에 존재하지 않는 경우에는, 클라이언트는 다른 수단을 통해 정보를 얻어야 한다. 이러한 후자의 경우에, 클라이언트는 브리지를 인식하지 못하는 HAVi-1.1 디바이스 상에서 실행한다. 이 클라이언트는 로컬 IEEE 1394 클러스터 디바이스에만 억세스 할 수 있다.

본 실시예에 따라, 클라이언트는 SDD 데이터를 검색하기 위해 다음의 프로세스를 실행한다: 즉

다시 말해, 클라이언트 어플리케이션은 바람직하게는 SddManager가 있는 디바이스 그리고 SddManager가 없는 디바이스에 대해 모두 작동하도록 적응된다.

본 실시예에 따라, SddManager는 다른 SddManager에 의해 알려진 이벤트 (event)로부터 얻은 SDD 데이터 정보를 캐시(cache)한다. 이것으로 네트워크 상의 트랙픽(traffic)을 감소시키고 요청이 이루어질 때 SddManager로부터 클라이언트로의 응답 시간을 줄일 수 있다. 이 캐시는 그리하여 SddManager에 집중되어 있으며 동일한 디바이스의 여러 클라이언트에 의해 중복적으로 수행될 필요는 없다.

SddManager의 레벨에서, 다음 프로세스가 수행된다:

다시 말해, 클라이언트로부터 수신된 질문(query)이 국부적으로 이용가능한 데이터에만 관한 것이 아니라면, SddManager는 이 SDD 데이터가 검색되어야 하는 타깃 디바이스가 SddManager를 포함하고 있는지를 먼저 체크하고 그 경우에 타깃 SddManager를 호출한다. 그렇지 않으면(즉, 타깃 디바이스가 SddManager를 가지고 있지 않으면), SddManager는 타깃 디바이스가 로컬 클러스터 상에 있는지 여부를 체크하고 통신 매체 매니저와 같은 로컬 API를 사용하여 데이터(예를 들어, IEEE 1394에 대해 CMM 1394)를 검색한다. 리모트 브리지 없는 인식 타깃 디바이스에 있어, 이 요청은 로컬 클러스터의 출구 포털의 SddManager로 송신된다.

도 3 은 위 2개의 처리에서 참조된 여러 경우에 대한 메시지 시퀀스(message sequence)를 예시한다. 이 참조 번호는 위 2개의 처리에서 주어져 있는 단계에 대응한다.

바람직하게는, SddManager는 네트워크(로컬 네트워크 또는 리모트 네트워크)상의 모든 다른 SddManager의 리스트를 저장하며 그리고 SddManager가 없는 디바이스에 대해서는 최단 거리에 있는 포털 GUID(아래 기술되는 바와 같은 네트워크 매니저에 의해 주어짐)를 그리로 질문을 송신하기 위해 저장한다.

이 SddManager는 다음 서비스를 제공한다:

서비스	통신 타입	국지성 (Locality)	억세스
SddManager::GdtSddDataM 글로벌 전체
SddDataChangedE 글로벌 SddManager(전체)

SddManager는 본 실시예에서 다음 데이터 구조를 가지고 있다:

(a) DeviceProfile

정의

설명

이 구조는 HAVi_Device_Profile 카테고리(HAVi-1.1 스펙 페이지 458)에서 IEEE 1394 컨피규레이션 ROM에서 발견된 값을 저장한다. deviceClass 파라미터는 디바이스의 타입(FAV, IAV,...)을 제공한다. 모듈이 이 디바이스에 존재하는 경우에 withXxxManager 부울리안(boolean)이 참(true)이다. withDisplayCapability는 IAV에 대해 DDI 컨트롤러가 존재하는지 여부를 나타내며, FAV에 대해 DDI 컨트롤러와 level2 UI(유저 인터페이스)가 존재하는지 여부를 나타낸다. deviceActive 부울리안은 이 디바이스가 활성(active)이라면 참이다. bridge 파라미터는 이 디바이스가 브리지인지 아닌지를 명시한다.

(b) 벤더

정의

설명

제조자에 관한 정보. 문자의 최대 수는 50이며 2바이트로 UNICODE UTF-16으로 인코딩되며, 이로 최대 사이즈는 100이다.

(c) 모델

정의

설명

이 구조는 모델에 관한 정보를 제공한다. 문자의 최대 수는 50이며, 2바이트로 UNICODE UTF-16으로 인코딩되며, 이로 최대 사이즈는 100바이트이다.

(d) DcmProfile

정의

설명

이 구조는 DCU에 관한 정보를 포함한다. 이 필드는 섹션 9.10.7 p460에서 HAVi-1.1 스펙에 의해 규정되어 있는 바이다.

(e) SddData

정의

설명

이 구조는 HAVi 디바이스에 관한 정보를 제공한다. 이 정보는 기본적으로 HAVi-1.1 스펙의 IEEE 1394 컨피규레이션 ROM SDD 파트에서와 동일한 정보이다. 필드에 대한 상세한 정보에 대해서는 HAVi-1.1 스펙 섹션 9를 참조하라. 디바이스 프로파일에 일 비트, 즉 deviceProfile 구조에서 브리지 부울리안으로 표현된 브리지비트가 추가된다는 것을 주목해야 한다. 이 데이터 부분은 HAVi 디바이스가 브리지인지 아닌지를 나타내기 위해 사용된다. 또한 dcmProfile과 dcmReference가 BAV 디바이스에 대해서만 유효한 필드라는 것을 주목해야 한다.

SddManager의 어플리케이션 프로그래밍가능한 인터페이스(API)는 다음과 같다:

SddManager::GetSddData

프로토타입

Status SddManager::GetSddData(in GUID guid, out SddData sddData)

파라미터

·guid - 클라이언트가 SDD 데이터를 검색하고자 원하는 GUID.

·sddData - 지정된 GUID의 SDD 데이터.

설명

이 방법은 그 GUID에 의해 지정된 주어진 HAVi 디바이스에 대한 SDD 데이터를 검색한다. 만일 GUID가 로컬 디바이스(클라이언트의 호스트)의 것이라면, 로컬 SddManager는 대응하는 SDD 데이터와 함께 응답을 송신한다. 만일 GUID가 리모트 디바이스의 것이라면, 로컬 SddManager는 리모트 SDD 데이터를 검색하는 일을 담당한다. 이것은 이미 위에 제시된 프로세스에 따라 수행된다.

에러 코드

·SddManager ::EUNKNOWN_GUID - GUID는 알려져 있지 않다.

·SddManager::ENOT_READY - SDD 데이터는 현재 업데이트 중이다. 클라이언트는 이후 재시도할 수 있다.

·SddManager::ELAV - 지정된 GUID는 LAV 디바이스이며 그래서 SDD 데이터를 가지고 있지 않다.

SddManager는 다음 이벤트를 사용한다:

SddDataChanged

프로토타입

void SddDataChanged (in GUID guid, in SddData sddData)

파라미터

·guid - SDD 데이터를 변경한 디바이스의 GUID.

·sddData - 새로운 SDD 데이터.

설명

이 이벤트는 GUID에 의해 지정된 디바이스의 SDD 데이터의 변경을 네트워크에 있는 디바이스에 알려주는데 사용된다. SddManager를 호스팅하는 디바이스는 이 이벤트를 그 로컬 SDD 데이터에 제공할 수 있다.

브리지 디바이스는 변경된 SDD가 있는 디바이스에 로컬인 포털에서 SDD 데이터의 변경을 (예를 들어 IP 클러스터에 대한 멀티캐스터 메시지를 통해) 검출하고 이 정보를 다른 포털의 SddManager에 송신함으로써, SddManager가 없는 리모트 디바이스의 SDD 데이터에 이러한 이벤트를 제공할 수 있다.

이 경우에 (브리지가 SDD 매니저가 없는 디바이스에 대해 이벤트를 배포시킬 때), SddManager가 없는 디바이스가 있는 클러스터의 모든 포털이 그 이벤트를 자기 고유의 공동 포털(co-portal)에 송신할 수 있으며, 이 공동 포털은 이후 그 이벤트를 리모트하게 송신할 수 있으며, 여기서 로컬 클러스터는 알려진 SDD 프로세스(IEEE 1394 네트워크에 대해 Bus Reset 및 컨피규레이션 ROM 판독, IP 네트워크에 대해 멀티캐스터 패킷의 송신)에 따라 업데이트된다. SDDManager가 없는 디바이스는 예를 들어 기본적인 (BAV) nonIEEE 1394 디바이스와 같은 HAVi 1.1 디바이스일 수 있다. 레거시 디바이스(legacy device)(FAV)에서는, 이 레거시 디바이스가 SDD 데이터를 가지지 않기 때문에 문제되지 않는다.

IEEE 1394 컨피규레이션 ROM 개선이 다음과 같이 수행된다:

SddManager 구조의 정의와 일치시키기 위해, 새로운 필드는 다음과 같이, IEEE 1394 HAVi 디바이스의 컨피규레이션 Rom에 추가된다. 이 HAVi_Device_Profile 은 IEEE 1394 컨피규레이션 ROM의 24비트 중간 값 (IEEE 1212에 명시된 바와 같은 것) 필드이며, 이 필드는 이미

·HAVi_Device_Class [비트 0...3]

·HAVi_DCM_Manager [비트 4]

·HAVi_Stream_Manager [비트 5}

·HAVi_Resource_Manager [비트 6]

·HAVi_Display_Capability [비트 7]

·HAVi_Device_Status [비트 8]

·비트 9 내지 23은 예비된 것

을 포함한다.

새로운 필드는 비트 9에 있는 이 엔트리에 추가된다:

HAVi_Bridge 는 이 디바이스가 HAVi 브리지인지 아닌지에 대해 IAV/FAV 디바이스를 지정하는 1-비트 중간 값이다. BAV에서 이 비트는 0이 된다.

HAVi_Bridge 값 의미

0 은 브리지가 아니다

1 은 브리지이다

b) 통신 매체 매니저(The Communication Media Manager)

브리지 포털의 수정된 통신 매체 매니저(CMM)가 이제 기술된다:

브리지의 CMM(사실 브리지마다 여러 개의 CMM이 존재하기 때문에 각 포털의 CMM)의 API는 이 실시예에 따라 호스트 디바이스의 소프트웨어 요소에만 억세스(즉 로컬 억세스 성능) 가능한 대신에 적어도 몇몇 API/방법에서 글로벌적으로 억세스가능하다. 이것은 CMM의 각 타입에 대해 유효하다. 우리는 이후 IEEE 1394에 기반을 둔 디바이스에 대한 CMM(CMM 1394)와 IP에 기반을 둔 디바이스에 대한 CMM(CMMIP)가 브리지 디바이스에 존재하므로 이들을 기술한다.

CMM 1394 API는 다음과 같다:

서비스 통신 국지성 이벤트에 의한/위한억세스 :타입 (Locality) (목적지)에서 보낸 것

Cmm1394::GetGuidList M 로컬 전체

Cmm1394::Write M 로컬 신뢰가능브리지에서 글로벌

Cmm1394::Read M 로컬 신뢰가능브리지에서 글로벌

Cmm1394::Lock M 로컬 신뢰가능브리지에서 글로벌

Cmm1394::EnrollIndication M 로컬 신뢰가능브리지에서 글로벌

Cmm1394::DropIndication M 로컬 신뢰가능브리지에서 글로벌

<Client>::Cmm1394Indication MB 로컬 CMM1394(신뢰가능)브리지에서 글로벌

NewDevices E 로컬 CMM1394(전체)

GoneDevices E 로컬 CMM1394(전체)

NetworkReset E 로컬 CMM1394(전체)

GuidListReady E 로컬 CMM1394(전체)

CMMIP API 는 다음과 같다:

서비스 통신 국지성 억세스타입

CmmIp::GetGuidList M 로컬 전체

CmmIp::GetIpAddress M 로컬 신뢰가능브리지에서 글로벌

CmmIp::GetGuid M 로컬 신뢰가능브리지에서 글로벌

CmmIp::Send M 로컬 신뢰가능브리지에서 글로벌

CmmIp::EnrollIndication M 로컬 신뢰가능브리지에서 글로벌

CmmIp::DropIndication M 로컬 신뢰가능브리지에서 글로벌

<Client>::CmmIpIndication MB 로컬 CMMIP(신뢰가능)브리지에서 글로벌

NewDevices E 로컬 CMMIP(전체)

GoneDevices E 로컬 CMMIP(전체)

ChangedDevice E 로컬 CMMIP(전체)

GuidListReady E 로컬 CMMIP(전체)

ProxyGuidCreated E 글로벌 CMMIP(CMMIP)

enroll 및 drop API에 의해 리모트 HAVi 소프트웨어 요소는 CMM 포털의 네트워크에 로컬인 디바이스로부터 낮은 레벨의 메시지를 수신할 수 있다. 'send' API(IP에 대해 send, IEEE 1394에 대해 read-write-lock)는 리모트 클러스터 상에있는 특정 디바이스에 메시지를 송신할 수 있게 해준다. 예를 들어, 이들 수단은 하나 이상의 브리지를 통해 그 제어되는 디바이스와 통신하기 위해 리모트로 설치된 디바이스 컨트롤 모듈(Device Control Module)(DCM)에 의해 사용될 수 있다.

리모트 CMM(즉, 자기 자신과 동일한 디바이스에 있지 않은 CMM)을 사용하고자 원하는 HAVi SE 는 리모트 CMM에 의해 사용되는 링크 기술을 인식하여야 한다, 즉 HAVi SE 는 위 API를 알고 있어야 한다.

HAVi SE에 의해 사용되는 프로세스는:

·0x00000001(즉, 통신 매체 매니저)의 소프트웨어 요소 타입 속성 값을 갖는 로컬 레지스트리(질문을 리모트 레지스트리로 보내는)에 질문하는 것에 의해 리모트 CMM 기술의 발견(discovery)과, 리모트 CMM의 SEID의 검색. 본 실시예에 따라, 이 SEID의 소프트웨어 처리(swHandle) 부분은 CMM의 타입(CMM1394에 대해서는 0x0001, CMMIP에 대해서는 0x0009)을 제공한다.

·이 SE 는 만일 자신이 그 대응하는 링크 기술을 처리하는 방법을 알고 있는 경우 이 CMM을 사용할 수 있다. 예를 들어, 이 SE 는 이 기술에 기초하여 리모트 디바이스로 송신될 메시지의 내용을 지정할 수 있어야 한다.

도 4 는 1의 GUID를 갖는 디바이스의 소프트웨어 요소가 브리지의 리모트 CMMIPP에 지시하여 IP 메시지를 3의 GUID 를 갖는 리모트 IP 디바이스에 송신하게 하는 일례를 도시한다.

요약하면, 브리지 포털의 CMM의 적어도 특정 기능은 CMM 고유의 디바이스에 로컬인 클라이언트와는 다른 클라이언트에 억세스가능하게 되는데, 이는 특히 예를들어 낮은 레벨의 메시지를 송신하는데 여러 네트워크 기술로 집적 통신하기 위해 이들 클라이언트가 CMM API 를 사용할 수 있게 해주기 위해서이다.

c) 디바이스의 발견/네트워크 매니저

·본 실시예에 따라, 네트워크 매니저 소프트웨어 요소는 전체 HAVi 네트워크에 연결된 모든 디바이스에 관한 정보를 제공하도록 생성된다. CMM 은 로컬 클러스터에 연결된 GUID의 리스트를 제공한다. 네트워크 매니저는 로컬 클러스터를 포함하는, 전체 멀티 클러스터 네트워크의 GUID의 리스트를 제공할 수 있다. 각 포털에는 네트워크 매니저가 존재한다. 네트워크 매니저는 바람직하게는 브리지 인식 디바이스에도 존재할 수 있다.

다음 서비스가 네트워크 매너저에 의해 제공된다:

[표 7]

서비스 통신 국지성 이벤트/이벤트타입 를 위한:송신자(메시지 또는 이벤트) (수신자)

NetworkManager::GetNetDeviceList M 로컬 전체

NetworkManager::GetNetDeviceInfo M 글로벌 전체

NetworkManager::NetworkUpdated E 로컬 네트워크 매니저(전체)

NetworkManager::GetRemoteDeviceList M 글로벌 네트워크 매니저

NetworkManager::RemoteNetworkChanged E 글로벌 브리지 내의 네트워크매니저(브리지 내의네트워크 매니저)

NetworkManager::RemoteNetworkUpdated E 글로벌 네트워크 매니저(모든네트워크 매니저로송신)

네트워크 매니저 데이터 구조는 다음과 같다:

(a) ClusterType

정의

enum ClusterType {IEEE1394, IP};

설명

ClusterType 은 특정 클러스터에 사용되는 기술에 관한 정보를 제공한다. 본 실시예에 따라, 2개의 클러스터 기술, 즉 1394(HAVi-1.1) 및 IP가 정의되어 있지만, 다른 기술이 용이하게 추가될 수 있다.

(b) NetDeviceInfo

정의

설명

NetDeviceInfo 구조는 네트워크에서 그 위치가 어디이든지 간에 디바이스에 관한 정보를 제공하는데, 즉 이 구조는 GUID 그 자체를, 그 디바이스에 도달하기 위한 홉(hop)의 수(이후에 설명되는 루프 문제를 해결하기 위해 네트워크 매니저에 의해 사용됨), 이 디바이스에 도달하는데 최단 거리에 있는 포털의 GUID, 및 이 디바이스가 연결된 클러스터의 타입을 제공한다. 마지막 2개의 항목은 클라이언트가 이 최단 거리에 있는 포털 상의 CMMXXX에 도달하게 하여 리모트 클러스터의 낮은 레벨의 기능에 억세스하며 리모트 디바이스에 낮은 레벨의 메시지를 송신할 수 있게 한다.

(c) RemoteNetworkState

정의

enum RemoteNetworkState {STABLE, CHANGING, FINAL};

설명

RemoteNetworkState 는 포털 뒤에 있는 리모트 네트워크의 상태(즉, 네트워크 매니저를 포함하는 포털 뒤에 있는 클러스터)에 관한 정보를 제공한다. STABLE 은 그 포털의 리모트 클러스터 디바이스 리스트가 안정적이며 다른 네트워크 매니저가 그 리스트에 의존하고 있다는 것을 의미한다. CHANGING 은 리모트 리스트가 지금까지 수정되었다는 것을 의미한다. FINAL 은 포털의 리모트 리스트가 안정하여야 하지만 클러스터의 다른 포털이 확인할 필요가 있다는 것을 의미한다(보다 상세한 사항에 대해서는 동작 디스커버리 프로세스를 참조).

네트워크 매니저 API 는 다음과 같다:

(a) NetworkManager::GetNetDeviceList

프로토타입

파라미터

·updatedID - 네트워크의 업데이트 수. 이 수는 그 리스트가 변경될 때마다 하나씩 증분되며, 이 수는 네트워크가 동일한지 아닌지를 체크하기 위해 클라이언트에 의해 사용될 수 있다.

·activeNetDeviceList - 네트워크 상의 모든 활성 디바이스의 리스트. 첫 항목은 로컬 디바이스이어야 한다.

·nonactiveNetDeviceList - 네트워크 상에 모든 비활성 디바이스의 리스트.

설명

이 API 는 전체 네트워크 상의 모든 디바이스의 리스트를 복귀시키며, 활성 디바이스 리스트와 비활성 디바이스 리스트로 분할시킨다. 각 디바이스에 관한 정보는 NetDeviceInfo 구조에 포함된다. 이것은 이 디바이스의 GUID, 이 디바이스에 도달하는데 최단 거리에 있는 포털의 GUID, 및 이 디바이스에 부착된 클러스터의 타입을 제공한다. 예를 들어, 도 4에서, SE 는 GUID(3)를 검색하며 그 클러스터가 IP 기반이라는 것과 거기에 도달하는데 촤단거리에 있는 포털이 GUID (6)라는 것을 알아서, SE 는 이제 CmmIp::Send HAVi 메시지를 6의 GUID 를 갖는 디바이스의 CMMIP에 송신할 수 있다.

에러 코드

·NetworkManager::ENOT_READY - 아직 이용가능하지 않은 리스트, 시스템은 이 리스트를 업데이트 할 수 있다. 이것은 과도 에러(transient error)이며, 클라이언트 소프트웨어 요소는 NetworkUpdated 이벤트를 재시도하거나 사용할 수 있다.

(b) NetworkManager::GetRemoteDeviceList

프로토타입

파라미터

·updateID - 리모트 네트워크의 업데이트 수. 이 수는 이 리스트가 변경될때마다 일씩 증분되며, 이 수는 리모트 네트워크가 동일한지 아닌지를 체크하기 위해 클라이언트에 의해 사용될 수 있다.

·activeNetDeviceList - 이 브리지 뒤에 있는 네트워크 상의 모든 활성 디바이스의 리스트.

·nonactiveNetDeviceList - 이 브리지 뒤에 있는 네트워크 상의 모든 비-활성 디바이스의 리스트.

설명

이 API 는 네트워크 매니저(Network Manager)를 포함하는 브리지 뒤에 있는 네트워크 상의 모든 도달가능한 디바이스의 리스트를 회복하며, 활성 디바이스 리스트와 비-활성 디바이스 리스트로 분할한다(활성 디바이스는 메시지를 수신할 준비가 된 디바이스이며, 디바이스의 SDD 데이터에 의해 명시된 바와 같이 IAV 및 FAV에 대해서는 HAVi, BAV에 대해서는 개별적이다). 각 디바이스에 관한 정보는 NetDeviceInfo 구조에 포함된다. 이것은 디바이스의 GUID, 이 디바이스에 도달하는 출구 포털의 GUID, 홉(hop)의 수, 최단 거리에 있는 포털 및 이 디바이스가 부착되는 클러스터의 타입을 제공한다. 본 실시예에서, 이 API로의 억세스는 네트워크 매니저로 제한된다. 이 API는 브리지 디바이스의 리모트 디바이스 리스트에 질문하기 위해 그에 따라 내부 표(internal table)를 구축하기 위해 그리고 루프 문제(loop issue)를 해결하기 위해 디바이스(브리지이든 아니든)의 네트워크 매니저에 의해 사용된다. 일 변형에 따라, API 는 또한 다른 소프트웨어 요소에 이용가능하게 이루어진다.

에러 코드

·NetworkManager::ENOT_READY - 이 리스트는 아직 이용가능하지 않으며, 시스템은 이 리스트를 업데이트 할 수 있다. 이것은 과도 에러이며, 클라이언트 소프트웨어 요소는 (브리지 디바이스만의 네트워크 매니저에 대해) RemoteNetworkChanged 이벤트와 (모든 네트워크 매니저에 대해) RemoteNetwrokUpdated 이벤트를 재시도하거나 사용할 수 있다.

(c) NetworkManager::GetNetDeviceInfo

프로토타입

파라미터

·guid - 클라이언트가 일부 정보를 얻고자 원하는 GUID.

·deviceInfo - 이 디바이스에 관한 정보, 즉 대응하는 NetDeviceInfo 구조.

설명

이 API 는 주어진 네트워크 디바이스에 관한 완전한 정보를 제공한다. 이 네트워크 매니저는 NetDeviceInfo 구조를 회복한다.

에러 코드

·NetworkManager::EUNKNOWN_GUID - GUID 는 알려져 있지 않다.

네트워크 매니저 이벤트는 이 실시예에 따라 다음과 같다:

(a) NetworkUpdated

프로토타입

파라미터

·updateID - 네트워크의 업데이트 수. 이 수는 리스트가 변경될 때마다 일씩 증분되며, 이 수는 네트워크가 동일한지 아니지를 체크하기 위해 클라이언트에 의해 사용될 수 있다.

·activeNetDeviceList - 전체 HAVi 네트워크 상의 활성 디바이스의 리스트. 처음 항목은 로컬 디바이스이어야 한다.

·nonactiveNetDeviceList - 전체 HAVi 네트워크 상에 있는 비-활성 디바이스의 리스트.

·changedDevices - 홉과 최단 거리의 포털이 변경된 GUID의 리스트.

·goneDevices - 네트워크를 탈퇴한 GUID의 리스트.

·newDevices - 네트워크에 가입한 GUID의 리스트.

설명

NetworkUpdated 는 네트워크 매니저를 호스팅하는 디바이스의 소프트웨어 요소로 송신된 로컬 이벤트(local event)이다. 이 이벤트는, HAVi 네트워크 상의 어디에선가(어떤 클러스터이든 간에) 변경이 있는 경우, 즉 네트워크 매니저가 로컬 클러스터에 연결된 브리지로부터 하나 이상의 RemoteNetworkUpdated 이벤트를 수신한 후(리모트 변경)에 또는 로컬 클러스터에 변경이 있는 후에 생성된다. 리컨피규레이션 시간 동안, 네트워크 매니저는, NetworkUpdated 때까지 NetworkManager::GetNetDeviceList API에 대해 NetworkManager::ENOT_READY를 회복할 수 있다. activeNetDeviceList와 nonactiveNetDeviceList 내용의 정의는 NetworkManager::GetNetDeviceList API에 규정된 것과 동일한 것이다. changedDevices, goneDevices 및 newDevices 필드는, 탈퇴된 디바이스 (goneDevices)가 구(舊) 디바이스 리스트에 알려져 있었고 새로우며 변경된 디바이스에는 새로운 디바이스 리스트에서 완전한 정보가 제공되기 때문에 그 GUID만을 제공한다.

일 변형 실시예에 따라, 이 이벤트는 이들 디바이스가 네트워크 매니저를 갖지 않는 경우, 동일한 클러스터 상의 다른 디바이스에 상주하는 소프트웨어 요소에 억세스가능하게 이루어진다.

(b) RemoteNetworkUpdated

프로토타입

파라미터

·updateId - 리모트 네트워크의 업데이트 수. 이 수는 리스트가 변경될 때마다 일씩 증분되며, 이 수는 리모트 네트워크가 동일한지 아닌지를 체크하기 위해클라이언트에 의해 사용될 수 있다.

·activeNetDeviceList - 전체 HAVi 네트워크에 있는 활성 디바이스의 리스트.

·nonactiveNetDeviceList - 전체 HAVi 네트워크에 있는 비-활성 디바이스의 리스트.

·changedDevices - 홉과 최단 거리의 포털이 변경된 GUID의 리스트.

·goneDevices - 네트워크를 탈퇴한 GUID의 리스트.

·newDevices - 네트워크에 가입한 GUID의 리스트.

설명

RemoteNetworkUpdated 는 네트워크 매니저만을 위한 글로벌 이벤트(global event)이다. 이 이벤트는, 네트워크 매니저가 로컬 클러스터를 위해 프록시(proxying)하는 네트워크의 부분에서 변경을 검출한 경우 그리고 이 네트워크가 (리스트의 상태가 아직 안정적이지 않을 때 사용되며 네트워크 매니저들만을 연결하기 위해 송신되는, 그 다음 이벤트와는 반대로) 안정적인 것으로 인식될 때, 생성된다. 이것은 네트워크 매니저의 공동 포털 클러스터에 대한 변경으로 인해 또는 공동 포털에 연결된 브리지에 의해 송신된 변경으로 인해 일어날 수 있다. 리컨피규레이션 시간 동안, 네트워크 매니저는 RemoteNetworkUpdated 때까지 NetworkManager::GetRemoteDeviceList API에 대해 NetworkManager::ENOT_READY를 회복할 수 있다. activeRemoteDevicesList와 nonactiveRemoteDeviceList 내용의 정의는 NetworkManager::GetRemoteDeviceList API에 규정된 바와 같다.changedDevices, goneDevices 및 newDevices 필드는, 탈퇴된 디바이스가 구 디바이스 리스트에서 알려져 있었으며 새로우며 변경된 디바이스에는 새로운 디바이스 리스트에서 완전한 정보가 제공되기 때문에 그 GUID 만을 제공한다.

(c) RemoteNetworkChanged

프로토타입

파라미터

·state - 리모트 네트워크의 상태, 이것은 리모트 리스트 반복으로 루프 문제를 해결하는데 유용하다.

·updateId - 리모트 네트워크의 업데이트 수. 이 수는 리스트가 변경될 때마다 일씩 증분되며, 이 수는 리모트 네트워크가 동일한지 아닌지를 체크하기 위해 클라이언트에 의해 사용될 수 있다.

·activeNetDeviceList - 전체 HAVi 네트워크 상에 있는 활성 디바이스의 리스트.

·nonactiveNetDeviceList - 전체 HAVi 네트워크 상에 있는 비-활성 디바이스의 리스트.

·changedDevices - 홉과 최단 거리의 포털이 변경된 GUID의 리스트.

·goneDevices - 네트워크를 탈퇴한 GUID의 리스트.

·newDevices - 네트워크에 가입한 GUID의 리스트.

설명

RemoteNetworkChanged 는 브리지 디바이스의 네트워크 매니저로만 향하는 글로벌 이벤트이다. 이것은 RemoteNetworkUpdated 이벤트와 동일한 것이지만, 이것은 그 리컨피규레이션 단계 동안 브리지 디바이스에서 네트워크 매니저에 의해 사용된다. 이들 단계 동안, 여러 개의 이벤트가 (특히 루프가 존재하는 경우) 안정적인 네트워크 상태에 도달하기 전에 생성될 수 있다. 이것은 네트워크가 아직 안정화되어 있지 않기 때문에 사용될 수 없는 메시지를 브리지 인식 디바이스로 송신하는 것을 피하게 해준다. 이 필드들의 의미는 RemoteNetworkUpdated 이벤트에 대한 것과 동일하다.

전술한 바에 기초하여, 본 실시예에 따라 브리지 사이의 디스커버리 프로세스(discovery process)는 다음과 같다:

목표는 HAVi 네트워크에 연결된 모든 디바이스를 발견(discover)하는 것이다. 일단 이것이 수행되면, 각 포털에 있는 '리모트' 디바이스 리스트는 디바이스를 통해 도달가능한 디바이스가 어느 디바이스인지에 관한 정보를 제공한다. IEEE 1394.1 토포로지가 브리지를 뮤트(muting)시키는 것에 의해 루프를 열지만, 동작 관련 루프(behavior regarding loops)는 이 실시예에서 다르다. 본 실시예에 따라, 브리지는 특정 경로에 대해서는 통과할 수 있으나 다른 경로에 대해서는 통과할 수 없으며 그래서 루프가 존재하는 경우 그 브리지는 완전히 뮤트되지는 않으나, 이브리지는 이들 GUID에 의해 식별된 디바이스로 가는 특정 경로 상에 있는 경우 이들 리모트 리스트 내에 GUID를 제공한다. 브리지가 통과하는지 아닌지 여부는 아래 설명된 바와 같은 특정 기준에 기초하여 결정된다. 본 실시예에서, 홉(hop)의 수는 목적지에 도달하기 위해 건너야하는 포털의 수를 반영하며 브리지의 수를 반영하지는 않는다. 이 선택은, 포털이 그 클러스터를 통하는 것이 아니라 공동 포털을 통해 도달될 수 있기 때문에 가능하다(즉, 전체 브리지를 횡단하는 포털로 가는 메시지를 요구하지 않지만, 클러스터 상에 있는 비-포털 디바이스에 대해서는 완전히 이 브리지를 횡단하여야 한다).

기본적인 디스커버리 프로세스는 다음과 같다:

각 로컬 클러스터는 자기 고유의 로컬 디스커버리 프로세스를 수행한다. 그 자체로 알려져 있는 IEEE 1394 클러스터에 대한 디스커버리 프로세스는 'selfID' 패킷을 사용하여 토포로지 정보 배포를 유도하는 IEEE 1394 버스 리셋(Bus Reset)에 기초를 두고 있다.

이 단계가 끝나면, CMM1394 는 그 GUID를 얻기 위해 모든 노드의 컨피규레이션 ROM을 판독한다. SDD 데이터는 연결된 디바이스에 관한 HAVi-규정된 정보를 얻기 위해 (존재하는 경우) 판독된다.

그 자체로 알려져 있는 IP 클러스터를 위한 디스커버리 프로세스는 멀티캐스트 고지 패킷(multicast announcement packet)에 기초를 두고 있다.

본 실시예에 따른 CMMIP 는 예를 들어 새로운 디바이스가 클러스터에 연결될 때 일어나는 이들 고지에 기초를 둔 그 GUID 리스트를 구축한다. SDD 데이터는 또한 이들 패킷에 포함된다.

이 점에서, 로컬 GUID 리스트와 SDD 데이터는 두 클러스터 타입에 대해 알려져 있으며 그리하여 클러스터의 네트워크 매니저는 로컬 클러스터에 존재하는 브리지 디바이스를 인식한다.

완전한 네트워크 디바이스 리스트를 구축하기 위해, 네트워크 매니저는 서로 질문하기 시작한다.

본 실시예에 따른 프로세스는:

(1) 네트워크 매니저가 그 클러스터 상의 브리지를 탐색하며.

(2) 브리지 디바이스의 네트워크 매니저는 로컬 클러스터에 연결된 다른 브리지 디바이스의 포털의 NetworkManager::GetRemoteDeviceList API를 호출한다. 이들 질문을 받은 포털의 공동 포털은 이미 네트워크에서 이들 포털 측 상에 있는 디바이스의 리스트를 구축하고 있어야 한다.

(3) 브리지 디바이스의 네트워크 매니저는 그 공동 포털로부터 (브리지 내부 정보 공유 등을 통해 바람직한 실시예에 따라 또는 HAVi 메시지에 의해) 자기 고유의 리모트 디바이스 리스트가 되는 리스트를 획득한다. 공동 포털은 자기 고유의 클러스터에 연결된 다른 브리지 디바이스의 NetworkManager:: GetRemoteDeviceList API를 호출할 때 이 리스트를 제공할 수 있다.

(4) 브리지 인식(BA : bridge aware) 디바이스의 네트워크 매니저는 그 로컬 클러스터에 연결된 브리지 디바이스의 NetworkManger::GetRemoteDeviceList API를 호출한다. 이것은 전체 네트워크 GUID 리스트를 구축한다.

·HAVi SE 는 그 로컬 네트워크 매니저의 NetworkManager::GetNetDeviceList API를 호출한다.

요청된 정보가 이용가능하기 전에 단계가 수행되는 경우, ENOT_READY 에러는 회복될 수 있으며 클라이언트는 기다려야 한다. 본 실시예에 따라, 단계 1 및 2 는 사실 병렬로 수행되며, 그래서 데드 로크 문제(dead lock issue)를 피하기 위한 메커니즘이 제안된다. 디바이스 리스트 구축 프로세스는 (적어도 루프 없는 네트워크에서) 토포로지의 탈퇴 클러스터(leave clusters)로부터 루트 클러스터(root cluster)로 진행한다.

디스커버리 규칙은 다음과 같다:

다음 규칙은 디스커버리 프로세스에 적용된다. 이 규칙은 리모트 네트워크 상태, 즉 'Changing', 'Final' 또는 'Stable'에 따라 분류된다. 나아가, 몇몇 일반적인 규칙(Generic rules)은 그 상태에 상관없이 적응가능하게 존재한다. 규칙은 그 결과 "G", "C", "F" 및 "S" 카테고리로 분류된다.

[표 8]

G1	제 1 로컬 디스커버리 후에, 리모트 리스트는 비어 있고(대응하는 요청이 수신되는 경우 응답 ENOT_READY가 송신된다), 리모트 리스트(심지어 불완전하지만 적어도 공동 포털의 로컬 리스트)에 대해 공동 포털에 질문을 하며, 이후 존재하다면, 클러스터의 다른 포털로부터 리모트 리스트를 요청한다.
G2	새로운/탈퇴된 디바이스로 로컬 디스커버리 및 로컬 클러스터의 리컨피규레이션 후, 클러스터에 대해 새로운 브리지를 체크한다.
G2.1	새로운 브리지 없음 ⇒ 안정적인 상태(STABLE state)인 경우 이전의 상태를 유지하며 공동 포컬을 업데이트 한다.
G2.2	새로운 브리지 ⇒ 새로운 로컬 리스트와 구 리모트 리스트 사이의 중복 GUID를 체크한다(예를 들어, 새로운 브리지가 구 토포로지보다 더 짧은 루트를 허용할 때 일어날 수 있음)
G2.2.1	중복 GUID ⇒ CHANGING 상태로 가서 새로운 포털의 리모트 리스트를 요청한다.
G2.2.2	중복 GUID 없음 ⇒ FINAL 상태로 가서 새로운 포털의 리모트 리스트를 요청한다.
G3	중복 관리 : 홉이 가장 적은 필드를 갖는 포털이 우세하며(즉 디바이스로 가는 경로 상에 있는 것으로 선택되며), 동일한 수의 홉인 경우, 최대 역방향 GUID를 갖는 포털이 우세하다(이 타이(tie)를 해결하기 위해 다른 기준이 물론 사용될 수 있다).
C1	클러스터의 포털로부터 ENOT_READY 에러 응답을 수신할 때, 마지막 업데이트 이후 무엇인가 변경된 경우 그리고 S3가 아닌 경우 불완전한 리스트(이 리스트는 적어도 로컬 클러스터의 리스트일 수 있다)로 공동 포털을 업데이트 한다. 포털로부터의 이벤트를 위한 특정시간 동안 기다리며 이벤트가 수신되지 않은 경우 리모트 리스트를 다시 요청한다.
C2	클러스터의 다른 포털로부터 응답 또는 CHANGING 이벤트를 수신할 때, 중복 GUID를 체크한다.

C2.1	중복 GUID 라면 ⇒ FINAL상태로 가서, 중복 GUID를 제거하며(홉 규칙 G3), 그리고 클러스터에 FINAL 이벤트를 송신한다.
C2.2	중복 GUID가 없는 경우 ⇒ 만약 S3가 아니라면 CHANGING 상태에서 공동 포털을 업데이트한다.
C3	CHANGING 상태에서 공동 포털로부터 업데이트한다 ⇒ 중복 GUID를 체크한다.
C3.1	중복 GUIDS ⇒ FINAL 상태로 가서, 중복 GUID를 제거하며(홉 규칙 G3), 클러스터에 FINAL 이벤트를 송신한다.
C3.2	중복 GUID 없음 ⇒ 만약 S4가 아니라면 클러스터에 CHANGING 이벤트를 송신한다.
F1	클러스터의 다른 포털로부터 FINAL 이벤트를 수신한다 ⇒ 중복 GUID를 체크한다.
F1.1	중복 GUID : 중복 관리(홉 규칙 G3)
F1.1.1	모든 것이 다른 포털을 위한 것이면(F1의 다른 포털) ⇒ STABLE 이벤트를 확인을 위해 송신한다.
F.1.1.2	적어도 하나가 현재의 포털(이 프로세스를 수행하는 현재의 포털)을 위한 것이면 ⇒ 업데이트된 리스트와 함께 FINAL 이벤트를 송신한다.
F1.2	중복 GUID 없음 ⇒ STABLE 이벤트를 확인을 위해 송신한다.
S1	클러스터의 모든 다른 포털로부터 STABLE 리스트를 수신하면 ⇒ 이 리스트가 송신된 이전의 STABLE 리스트와 다른 경우 STABLE 리스트로 공동 포털을 업데이트한다.
S2	공동 포털로부터 STABLE 업데이트이면 ⇒ 중복 GUID를 체크한다
S2.1	중복 GUID 이면 ⇒ 이미 알려져 있거나 관리되는 것인가?
S2.1.1	Yes 이면 ⇒ 마지막 이벤트가 STABLE이 아니라면 또는 마지막 송신된 STABLE 이벤트로부터 새로운/탈퇴된 GUID라면 STABLE 이벤트를 송신한다.
S2.1.2	No 라면 ⇒ FINAL 상태로 가서, 중복 GUID를 제거하며(홉 규칙 G3), 클러스터에 FINAL 이벤트를 송신한다.
S2.2	중복 GUID가 없으면 ⇒ 클러스터에 STABLE 이벤트를 송신한다.
S3	리모트 리스트가 STABLE 상태에 있는 경우, 공동 포털의 업데이트는 STABLE 아닌 리스트의 클러스터의 다른 포털로부터 수신시에 수행된다.
S4	만일 클러스터의 모든 다른 포털이 STABLE이라면, STABLE 하지 않은 리스트의 공동 포털로부터 업데이트를 위해 클러스터에는 이벤트가 송신되지 않는다.

위 프로세스는 - 필요하다면 - 반복 처리를 통하여 리던던트 경로 충돌(redundant path conflicts)이 적절히 해결되는 것을 보장하는 단계를 포함한다. 이를 위해, 3개의 가능한 상태 - Changing, Stable, 및 Final이 규정된다. 이들 상태에 관한 정보는 RemoteNetworkChanged 이벤트에서 RemoteNetworkState 데이터 구조를 사용하여 전파된다.

변형 실시예에 따라, 응답할 수 있기 전에 다른 브리지로부터 대량의 이벤트에 의해 더 느린 브리지가 넘치지 않도록 하기 위해 이 발견 프로세스에는 타임아웃 프로세스가 구현된다.

(d) 메시지 송신

HAVi 스펙에 따라, HAVi 메시지는 하나의 소프트웨어 요소(Software Element)에서 다른 소프트웨어 요소로 송신된다. 소프트웨어 요소는 SEID(Software Element Identifier)에 의해 식별된다. 이 SEID 는 소프트웨어 요소가 상주하는 디바이스의 GUID와 이 디바이스 내에 고유하게 존재하는 swHandle로 구성된다. HAVi 메시지의 헤더(header)는 목적지 SEID 및 소스 SEID를 포함한다.

본 실시예에서, 브리지 디바이스는 HAVi 메시지를 수정하지 않는다(여기서 우리가 HAVi 메시지라고 부르는 것은 TAM 헤더를 포함하지 않는다). 목적지 SEID, 소스 SEID, 프로토콜 타입, 메시지 타입, 메시지 번호, 메시지 길이, 메시지 본문 필드들(message body field)이 동일하게 유지된다. 그러나, 메시징 시스템은 이 메시지를 목적지로 루팅한다(route). 이렇게 하기 위해, 브리지 내의 메시징 시스템이 클러스터에 대한 HAVi 메시지를 수신할 때, 이 메시징 시스템은 목적지 SEID 및 보다 정확하게는 이 SEID에 포함된 GUID를 검색한다. 이 GUID가 자기 고유의 GUID이면, 이 메시지는 내부 SE를 위한 것이며 이 시스템은 이 메시지를 송신한다. 만일 이 GUID가 리모트 GUID 리스트에 존재한다면, 이 시스템은 이 메시지를 공동 포털로 송신한다(또는 적절한 공동 포털이 거기서 하나를 초과하는 공동 포털이어야 한다). 이 공동 포털은 이 메시지를 {내부 표(internal table)과 관련해서} 대응하는 목적지 디바이스로 송신한다. 이 디바이스는 마지막 목적지 디바이스일 수 있으며 또는 경로 상에 있는 그 다음 브리지일 수 있다.

메시징 시스템의 일반적인 동작에 관해, 아무 것도 변경되지 않는다:

·메시지 번호는 여전히 HAVi-1.1 스펙, p29의 섹션 3.2.1.2.3에 있는 규칙을 따른다. 이것은 메시지의 초기 송신자와 최종 수신자에 대해 그러하다. 경로 상에 있는 브리지에서 메시징 시스템은 HAVi 메시지 내에 있는 것에 관심을 갖지 않으며, 이들은 메시지를 바로 송신한다.

·'간단한(simple)' 메시지(즉, 수신확인이 요청되지 않는 메시지)가 방금 송신되었으며 수신확인이 요청되지 않는다.

·'신뢰할 만한(reliable)'메시지가 송신되며, 호출자는 긍정적이거나 부정적인 수신확인(Ack 또는 Nack)이 수신될 때까지 차단된다(blocked). 이것은 초기 송신자에게 그러하며, 경로 상에 있는 브리지 내의 메시징 시스템은 이 메시지(초기 메시지, Ack 또는 Nack 메시지)를 바로 송신한다.

도 4의 토포로지로 되돌아가면, GUID 1을 갖는 디바이스 내의 SE가 HAVi 신뢰할 만한 메시지를 GUID 3을 갖는 디바이스 내의 다른 SE로 송신하고자 원하는 경우, GUID 1을 갖는 디바이스의 메시징 시스템은 이 메시지를 브리지 포털(GUID 5를 갖는 디바이스)에 송신한다. 브리지의 메시징 시스템은 목적지 SEID 및 보다 정확하게는 이 SEID에 포함된 GUID를 검색하며 이 메시지가 리모트 리스트의 디바이스를 위한 것인지를 추론한다. 이 시스템은 이후 HAVi 메시지를 공동 포털로 송신하며, 이 공동 포털은 GUID 3을 갖는 디바이스로 이 메시지를 송신한다(도 5 참조). 수신확인 응답은 GUID 3을 갖는 디바이스로부터 브리지를 통해 GUID 1을 갖는 디바이스로 송신된다.

에러 처리는 다음과 같이 수행된다:

HAVi 메시지의 에러 처리에는 HAVi-1.1 스펙에 이미 규정된 것에 지나지 않는 것이 추가된다. 사실, 경로 상에 있는 브리지에 있는 메시징 시스템은 이 메시지를 바로 송신한다.

(e) EventManager

SE가 (EventManager::PostEvent API와 함께) 이벤트를 송신하고 있을 때, Event Manager 는 (EventManager::ForwardEvent API와 함께) 이 이벤트를 로컬 클러스터에만 우송한다. 다른 Event Manager로부터 이벤트를 수신하는 브리지의 Event Manager는 이 이벤트를 공동 포털을 송신한다. 공동 포털은 (EventManager::ForwardEvent API와 함께) 이 이벤트를 클러스터 등으로 송신한다.

포털 이벤트 매니저가 공동 포털로 이벤트를 송신하거나 송신하지 않는 규칙은 원래의 포스터(original poster)의 GUID가 공동 포털의 리모트 리스트에 존재하는지 여부에 있다. 원래의 포스터의 GUID는 ForwardEvent 메시지에서 파라미터로서 주어진다. 여기서 ForwardEvent API의 리마인더(reminder)이다:

posterSeid 파라미터는 이벤트를 로컬 Event Manager로 송신한 원래의 SE의 SEID이다. 이 SEID에 포함된 GUID 는 SE가 상주하는 디바이스의 GUID를 제공한다. 이 GUID 는 이벤트를 송신하는지 아닌지 여부를 결정하기 위해 포털에 의해 사용된다.

브리지가 비 BA-디바이스(이들 디바이스는 리모트 디바이스로부터 제어가능하다)로부터 리모트 클러스터 이벤트로 송신하는 동안, 포털의 이벤트 매니저는 공동 포털로부터 수신된 이벤트 메시지(즉, 리모트 이벤트)를 클러스터의 비 BA-디바이스의 이벤트 매니저로 송신하지 않는다.

이벤트를 위한 에러 처리는 기본적으로 HAVi-1.1에서와 동일하게 유지된다(이벤트 매니저 프로토콜 섹션 5.4.5, p144 참조). 소 업데이트(small update)는, 각 포털이 그 뒤에 있는 것에 대해 프록시(proxy)로서 동작하는 것이다. 그래서, 이벤트 매니저는 로컬 클러스터의 이벤트 매니저로부터 응답(이벤트 매니저가 송신한 것)을 수신하며, 포털은 이것이 공동 포털 클러스터로부터 모든 응답을 수신할 때에 이들 응답들을 병합하고 반영하여 응답한다.

도 6 은 멀티 클러스터 네트워크 상에서 우송되는 이벤트를 위한 기본적인 프로세스를 보여준다. GUID 3을 갖는 디바이스에서 SE로부터 우송되는 이벤트는 GUID 3을 갖는 디바이스의 이벤트 매니저에 의해 클러스터의 모든 이벤트 매니저로 송신된다. 포털은, 포스터의 GUID가 공동 포털의 리모트 리스트에 있자마자 이 이벤트를 리모트 클러스터로 송신한다{이것이 포털(6)이 그 리스트를 포털(5)로 송신하지 않는 이유이다}. 포털은 이후 이 이벤트를 비 BA-디바이스를 제외한 클러스터에 있는 이벤트 매니저로 송신한다{이것이 디바이스(2)가 이 이벤트를 수신하지 않는 이유이다}.

변형 실시예에 따라, PostEvent API의 "global" 파라미터는 다음과 같이 수정된다. 현재, 이 파라미터는 이벤트가 HAVi 네트워크에 대해 글로벌이거나 디바이스에 대해 로컬인지 여부를 나타내는 부울리안(boolean)으로 규정된다. 이 부울리안은 다음과 같은 'enum' 구조로 대체된다:

enum EventScope{LOCAL, CLUSTER, NETWORK};

바람직한 실시예에서, PostEvent API 는 변치 않고 남아 있다.

(f) Registry

HAVi에서, 레지스트리 질문 요청(Registry::GetElement 또는 Registry::MultipleGetElement)이 SE에 의해 레지스트리로 송신된다. 기본적인 프로세스는 SE가 로컬 레지스트리에 질문하는 것이며, 로컬 레지스트리는 이때 이 질문을 HAVi 네트워크에 있는 모든 다른 레지스트리로 송신한다. 레지스트리가 질문을 리모트 노드로부터 수신하자마자, 이 레지스트리는 자기의 고유 데이터베이스를 검색한 후 이 질문에 바로 대답한다.

이 개념은 브리지와 함께 여기서 유지된다. 리모트 노드로부터 질문을 수신한 레지스트리는 브리지 디바이스에 있는 레지스트리를 제외하고는 자기 고유의 데이터베이스를 검색하여 대답을 한다. 기본적인 프로세스는 SE가 로컬 레지스트리에 질문을 하기 위해 유지되며, 로컬 레지스트리는 이 요청을 네트워크 상의 모든 레지스트리에 송신한다. 이것은 이후에 상술된다.

포털의 레지스트리는 당연히 클러스터의 레지스트리로부터 오는 요청을 공동 포털의 레지스트리로 송신한다. 그러나, 이 레지스트리는 요청의 초기 송신자의 GUID가 공동 포털의 리모트 리스트에 존재하는 경우에만(즉, 공동 포털이 초기 송신자로 가는 역방향 경로에 있는 경우에만) 이 송신을 한다. 이전과 같이, 이것은 동일한 목적지로 가는 메시지를 여러 경로에 걸쳐 송신하는 것을 피하게 해준다. 만일 이 초기 GUID가 공동 포털의 리모트 리스트 내에 있지 않은 경우, 이 요청은 송신되지 않는다. 이것은 토포로지 루프(topology loop)에서 일어날 수 있다. 이 경우에, 공동 포털은 초기 GUID를 프록시하는 클러스터 상의 브리지를 통해 (그래서 다른 루트에 의해) 이 요청을 수신한다. 나아가, 브리지의 레지스트리는 비 BA-디바이스의 레지스트리로부터 이 요청을 송신하지 않는다. 이들 디바이스는 리모트 GUID를 인식하지 못하며, 그래서 메시지를 리모트 SEID (레지스트리에 대한 기본적인 질문은 GUID를 포함하는 SEID를 회복한다)로 송신할 수 없다.

간청될 때, 공동 포털의 레지스트리는 다른 브리지를 포함하는, 클러스터 상의 다른 레지스트리에 이 요청을 송신할 수 있다. 레지스트리의 요청은 그 결과 전체 네트워크에 송신된다.

BA-디바이스의 레지스트리는 그 질문을 클러스터에만 송신하며, 그래서 클러스터들 사이의 레지스트리 통신은 레지스트리 자신에 의해 제어된다('클러스터 분리'). 도 7에서, 3개의 브리지 루프 네트워크는 네트워크 매니저 리스트(로컬 및 리모트)로 도시되어 있다.

변형 실시예에 따라, 기본적인 프로세스는 다음과 같다: 초기 레지스트리(디바이스 GUID 1)는 이 질문을 전체 네트워크 상의 모든 레지스트리에 송신한다. 제 1 클러스터에 송신된 HAVi 메시지의 수는 (네트워크에 9개의 레지스트리가 있으므로) 9이며, 여기서 각 레지스트리당 하나씩이다. 다른 클러스터에서 이 수는 감소되는데, 그 이유는 모든 메시지가 모든 브리지에 의해 송신되는 것이 아니기 때문이다.

바람직한 실시예에 따라, 초기 레지스트리(GUID 1)는 이 질문을 자기 고유의 클러스터만의 모든 레지스트리로 송신한다. 이 제 1 클러스터의 HAVi 메시지의 수는 이제 3이다. 이때, 브리지의 레지스트리는 공동 포털의 클러스터와 함께 이 동작을 반복한다(그러나 초기 송신자 GUID 1이 공동 포컬의 리모트 리스트에 존재하는 경우에만 그러하며: 이것이 GUID 7을 갖는 포털이 GUID 8을 갖는 포털로 메시지를 송신하지 않는 이유이다).

이 작은 예는 질문에 대한 개선(9개 대신에 3개의 메시지)을 보여주지만, 동일한 현상이 그 응답에도 나타난다. 바람직한 실시예에서, 포털에 있는 레지스트리는 공동 포털 클러스터 레지스트리의 모든 응답을 병합하는 것에 의해 하나의 단일 응답을 생성한다. 나아가, 이 예에서, 모든 디바이스는 하나의 브리지를 통해 도달가능하지만, 몇몇 브리지가 연쇄되어 있을 때에는 리던던트 HAVi 메시지의 수가 초기 송신자 부근에 있는 클러스터에서 커지게 된다.

레지스트리 메시지 처리는 다음과 같이 수행된다:

클러스터를 분리하는 경우, 초기 레지스트리는 클러스터 상의 모든 레지스트리에 질문을 한다. 이것은 요청을 위한 전체적인 트래픽을 감소시킨다. 이때 브리지에 있는 레지스트리는 이 요청을 송신한다. 포털이 (공동 포털의 리모트 리스트에 기초하여) 이 요청을 공동 포털에 송신하여야 하는지를 알 수 있도록 하기 위하여, HAVi 메시지의 소스 SEID는 초기 송신자 중 하나이어야 한다(만일 이 소스SEID가 변경되면, 루프 네트워크에서의 질문은 네트워크 매니저 동작을 위해 선택된 루트 관리로 인해 끝이 없게 된다). 그러나, 네트워크에 있는 모든 레지스트리는 초기 요청자에 응답하며, 이 초기 요청자는, 자기가 질문을 송신한 것보다 많은, 이해하지 못할 수 있는, 응답을 수신할 수 있다. 이것이 본 실시예에 따라 초기 요청자가 로컬 클러스터의 레지스트리로부터만 응답을 수신하는 이유이다.

다음의 변형이 (GetElement 예와 함께) 이 문제를 해결하기 위해 사용될 수 있다:

1. BA-디바이스의 레지스트리는 이 디바이스가 클러스터에만 질문을 송신하지만, 이 디바이스가 전체 네트워크의 모든 레지스트리로부터 오는 응답을 수신할 수 있다는 것을 안다. 메시지의 수의 감소는 이 응답에 대해서가 아니라 그 요청에 대해서만 수행된다. 이것은 비 BA-디바이스로부터의 요청이 송신되지 않기 때문에 작용할 수 있다.

2. Register::GetElement API는 수정된다. 새로운 파라미터가 초기 요청자의 SEID에 관한 정보를 포함하도록 추가된다. 이 API 는:

이 된다.

이 메시지를 수신하는 브리지의 포털은, 이 초기 요청자 파라미터의 SEID에 포함된 GUID에 기초하여 공동 포털에 질문을 송신하여야 하는지 또는 송신할 필요가 없는지를 안다. 트래픽 개선이 응답에 대해 이루어진다. 이 요청을 그리모트 클러스터에 송신할 때 브리지는 (각 디바이스의 SDD의 버전 필드에 기초하여) HAVi 1.1 메시지를 HAVi 1.1 디바이스로 송신하여야 하며 이 새로운 메시지를 BA-디바이스로 송신하여야 한다. 이들 요청은 브리지의 (그리고 더 이상 초기 요청자의 것은 아닌) 소스 SEID를 갖는 새로운 요청이다. 포털은 포털에 송신된 모든 응답을 수집하며(이 포털은 요청의 소스 SEID이기 때문이다) 그리고 이 응답을 하나의 SEID 리스트로 병합하며 이 응답을 초기 요청자(초기 요청을 수신한 디바이스)에게 송신한다.

3. 위 변형 2에서, 비-브리지 레지스트리는 초기 요청자의 아이디(identification)를 사용하지 않는다. 이 정보는 이 요청을 리모트 클러스터로 송신할지 송신하지 않을지를 결정하기 위해 브리지 디바이스의 레지스트리에만 유용하다. 다른 변형은 브리지 디바이스에 전용된 새로운 방법의 호출을 갖는 레지스터의 API를 연장하는 것이다. 브리지 인식 레지스트리는 포털 레지스트리를 위해 이 호출을 사용한다.

이때 호출된 브리지 디바이스는 초기 요청자의 아이디(identity)를 인식한다. 비-브리지 디바이스는 정상적인 GetElement 호출을 수신한다. 두 호출은 브리지의 소스 SEID를 포함하며, 초기 요청자 SEID를 포함하지 않는다. 브리지가 레지스트리로부터 모든 응답을 수신한 때에, 이 브리지는 이 응답을 하나의 SEID 리스트로 병합하며 브리지가 초기에 수신한 ForwardGetElement 호출에 응답한다.

4. 제 4 변형은 레지스터의 API를 수정하는 것을 피하는 것이다. GetElement 요청은 브리지에 의해 그대로 즉 HAVi 메시지에서 소스 SEID를 수정하지 않고 송신된다. 브리지 디바이스가 클러스터(다른 브리지 또는 비 브리지 디바이스)에 있는 레지스트리로부터 응답을 수신할 때, 이 디바이스는 이 응답을 송신하지 않으며, 이 디바이스는 이 응답을 분석하며 병합된 SEID 리스트를 구축하기 위해 SEID 리스트를 추출하며, 이 리스트를 질문을 수신한 요청자에게로 되송신한다. 이 브리지가 모든 응답을 수신한 경우, 이 브리지는 병합된 SEID 리스트와 함께 자기의 고유 응답을 송신할 수 있다.

그 다음 표는 4개의 제안된 변형의 찬성(pros)과 반대(cons)를 요약하려 한 것이다.

[표 9]

변형예	응답 트랙픽 개선	레지스터 API의 변화	브리지 지능
1	No	No	low
2	Yes	Yes	medium
3	Yes	Yes	medium
4	Yes	No	high

바람직한 변형예는, GetElement API가 수정될 필요가 없으므로, 번호 3 또는 4이다. 변형예 3은 브리지 사이에 동기화를 가능하게 하는 잇점을 가진다.

도 8 은 제 3 변형예를 사용하여 GetElement 호출을 위한 상호작용의 일례를 제공한다.

초기 송신자는 로컬 레지스트리에 GetElement 요청을 송신한다. 로컬 레지스트리는 이후 이 GetElement 요청을 로컬 클러스터 상의 다른 레지스트리에 송신한다. 브리지의 레지스트리가 이 요청을 수신할 때, 이 레지스트리는 이 요청을 공동포털 레지스트리(소스 SEID에 포함된 GUID가 이 공동 포털의 리모트 리스트에 있는 경우)에 송신한다. 이때 이것은 새로운 요청으로 간주된다. 이 새로운 요청은 공동 포털의 클러스터 상의 레지스트리에 송신된다. GetElement 는 비 브리지 디바이스에 송신되며 ForwardGetElement 는 브리지 디바이스에 송신된다. 이 프로세스는 만일 다른 브리지가 이 클러스터에 존재하는 경우 반복된다.

각 리모트 클러스터에서, 여러 요청이 브리지 디바이스의 레지스트리에 의해 송신되며, 즉, 브리지는 리모트 클러스터에 대한 초기 요청을 단순히 검색하지 않는다. 이 브리지 디바이스는 클러스터의 레지스트리의 응답을 다시 공동 포털에 제공하기 위해 이들 요청을 추적한다(track). 브리지 디바이스의 레지스트리가 클러스터의 레지스트리로부터 모든 응답을 수신할 때, 이 레지스트리는 이 응답을 하나의 단일 응답(하나의 SEID 리스트)으로 병합하며 이 응답을 공동 포털에 제공한다. 공동 포털은 자기 고유의 SEID 리스트로 증대된 이 SEID 리스트를 요청자 레지스트리에 송신할 수 있다. 이 응답은 만일 요청자 레지스트리가 다른 브리지 내에 있는 경우에는 ForwardGetElement 응답 또는 초기 요청자에 연결된 브리지를 위한 경우에는 GetElement 응답일 수 있다.

도 8의 특정 예에서, SEID 리스트는 브리지 디바이스에 의해 병합된다:

·GUID 6을 갖는 포털은 GUID 7(E)을 갖는 디바이스로부터의 리스트와 자기 고유의 리스트(D)를 GUID 5를 갖는 공동 포털에 다시 제공한다. GUID 5를 갖는 포털은 이 리스트를 가지며 자기 고유의 리스트(C)를 추가한다. 결과는 (C,D,E)이다.

·GUID 10을 갖는 포털은 GUID 8(비어있음)을 갖는 디바이스로부터, GUID 3(비어 있음)을 갖는 디바이스로부터, GUID 4(F)를 갖는 디바이스로부터 리스트와 자기 고유의 리스트(비어있음)를 GUID 9를 갖는 공동 포털에 다시 제공한다. 그 결과는 (F)이다.

·GUID 1을 갖는 디바이스의 레지스트리는 GUID 2(B)를 갖는 디바이스로부터, GUID 5(C,D,E)를 갖는 디바이스로부터 및 GUID 9(F)를 갖는 디바이스로부터 응답을 수신한다. 이 레지스트리는 자기 고유의 리스트(A)를 추가하며 그 응답을 SE에 다시 제공한다. 그 최종 결과는 (A,B,C,D,E,F)이다.

GetElement 방법에 대해 언급된 것은 또한 MultipleGetElement 방법에도 적용가능하다. 이후에 오는 것은 구체적으로 브리지 레지스트리에 전용된 새로운 API 이다:

(g) Streams

알려져 있는 HAVi 스트림 매니저는 스트림 연결을 구축할 수 있게 하는 시스템 소프트웨어 요소이다. 스트림 연결은 소스 기능 성분 요소와 싱크 기능 성분(이에 따라 연관된 소스와 싱크 디바이스)을 연관시키며 요청되는 자원의 이용가능성을 보장한다. 이들 자원은 채널, 대역폭 등일 수 있다. 도 9 는 HAVi에 의해 규정된 스트림 연결 모델을 보여준다. 2개의 기능 성분은 상호 연결된다. 기능 제어 모듈과 디바이스 제어 모듈(FCM/DCM) 사이의 내부 연결은 각 연관된 디바이스에서 이루어진다. 디바이스 연결은 연관된 디바이스 사이에 이루어진다(도 9의 2개의풀(Full) A/V 디바이스). 논리적 연결이 HAVi 레벨(즉, 소프트웨어 요소 사이)에 이루어지는 반면, 물리적 연결은 실제 장비를 수반한다(논리적 레벨에서 DCM/FCM 에 의해 표시된 것).

스트림 연결이 설정된 후, 스트림은 소스와 싱크 사이에 송신될 수 있다. HAVi에서, 스트림 연결을 생성하기를 원하는 각 어플리케이션은 그 로컬 스트림 매니저(Stream Manager)를 사용하여야 한다(즉, 동일한 디바이스에 위치된 스트림 매니저).

HAVi 스펙에 따라, 디바이스가 DCM(Device Control Module)에 의해 네트워크 내 어디에선가 표현되기 때문에 기능적 성분도 FCM(Functional Component Module)에 의해 네트워크 내 어디에선가 표현된다. 클라이언트 어플리케이션이 로컬 스트림 매니저로부터 스트림 연결을 요청할 때, 이 로컬 스트림 매니저는 소스와 싱크의 기능적 성분의 아이디를 지시한다. 스트림 매니저에 제공되는 정보는 다음 FcmPlugstructure로 그룹화된다:

·TargetId : 기능적 성분(FCM이 아님)이 위치되는 디바이스의 GUID와 이 디바이스 내의 성분에 대한 인덱스.

·플러그 방향 : 입력 또는 출력.

·기능적 성분이 여러 개의 플러그를 관리하는 경우 플러그 번호.

스트림 매니저는 내부 연결(즉, 디바이스 내의 연결)을 실현하기 위해 DCM의 서비스를 사용한다. DCM 모듈을 동작시키기 위해, 스트림 매니저는 HAVi 메시지를 사용한다. 그리하여, 내부 연결을 설정하는 방법은 매체 기술(예를 들어,IEC61883/IEEE1394)에 의존하지 않는다.

스트림 매니저는 디바이스 스트림 연결을 설정하기 위해 링크 층(예를 들어, IEC1883 CMP 프로토콜)의 서비스를 사용한다.

본 실시예에 따라, 멀티 클러스터 스트림을 위한 프로세스는 다음과 같다:

단일 클러스터 HAVi 네트워크에서, 스트림을 설정하기 위해, 클라이언트는 로컬 스트림 매니저를 사용한다. 이 로컬 스트림 매니저는 완전히 이 스트림을 담당하는 일을 한다. 멀티 클러스터 네트워크에서, 클라이언트에 대해 로컬인 스트림 매니저는 소스 디바이스 및/또는 싱크 디바이스와 동일한 클러스터에 있지 않을 수 있다. 나아가, 이 매니저는 소스 및/또는 싱크 디바이스에 사용되는 매체 기술을 인식하지 못할 수 있다. 따라서, 기본적인 원리는 경로 상에 있는 스트림 매니저가 공동 협력하게 하는 것이다.

간단한 모노 클러스터(mono-cluster) 스트림의 경우, 클라이언트는 스트림 매니저에 의해 사용될 트랜스포트 타입, 전송 포맷, 채널 및 플러그를 지정할 수 있다. 멀티 클러스터 스트림의 경우, 클라이언트는 스트림이 횡단하는 모든 클러스터에 대한 모든 파라미터를 선택할 수 있다고 생각하는 것은 현실적이지 않다(목표는 클라이언트가 전혀 인식하지 못하는 매체 기술을 가질 수 있는 것이다). 그리하여, 클라이언트는 단지 대역폭 정책(정적 또는 동적) 및 스트림 타입(스트림에 대해 고유한 것)만을 지정하여야 한다. 이때 스트림 매니저는 모든 트랜스포트 문제를 담당하는 일을 한다.

HAVi에 있는 브로드캐스트 스트림은 스트림 매니저 SprayOut 및 Tapln API로 설정된다.

본 실시예에 따라, 스트림 매니저가 이들 API에 로컬 호출을 수신하며 타깃 디바이스가 리모트일 때(즉 로컬 클러스터에 있지 않을 때), 이 매니저는 이 호출을 타깃 기능 성분(디바이스)에 연결된 최단 거리의 포털의 스트림 매니저로 송신한다. 이 스트림 매니저는 브로드캐스트 연결을 수행하지만, 이 연결은 리모트 클러스터에 대해서만 로컬일 수 있다. 그래서 브로드캐스트 스트림이 브리지를 횡단하지 않으나 리모트로 제어될 수 있다.

점대점 스트림(point-to-point stream)을 위해 제안된 API가 이제 설명된다.

HAVi-1.1 디바이스와 역호환성(backward compatibility)을 유지하기 위해, 리모트 클러스터 상에 있거나 또는 브리지를 횡단하는 이들 스크림을 위해 새로운 스트림 매니저 방법을 정의할 필요가 있다. 이것은 이후 제시된다.

알려진 스트림 매니저 API와 비교해 보면, 새로운 방법이 밑줄쳐져 있다.

[표 10]

서비스 통신 국지성 억세스/이벤트를 위한타입 (Locality) : 송신자 (수신자)

StreamManager::FlowTo M 로컬 전체

StreamManager::MultiClusterFlowToM 글로벌 전체

StreamManager::OnThePathM 글로벌 브리지 내의스트림 매니저

StreamManager::SprayOut M 로컬 전체

StreamManager::TapIn M 로컬 전체

StreamManager::Drop M 글로벌 전체

StreamManager::GetLocalConnectionMap M 글로벌 전체

StreamManager::GetGlobalConnectionMap M 글로벌 전체

StreamManager::ForwardGetGlobalConnectionMapM 글로벌 브리지 내의스트림 매니저

StreamManager::GetConnection M 글로벌 전체

StreamManager:: GetStream M 글로벌 전체

ConnectionAdded E 글로벌 스트림 매니저(전체)

ConnectionDropped E 글로벌 스트림 매니저(전체)

ConnectionChanged E 글로벌 스트림 매니저(전체)

(a) StreamManager::MultiClusterFlowTo

프로토타입

파라미터

·dynamicBw - 동적(dynamicBw가 참이다) 또는 정적(dynamicBw가 거짓이다) 대역폭 할당이 설정되어야 하는지를 나타낸다.

·source - 소스 플러그를 식별하는 FcmPlug 구조.

·sink - 싱크 플러그를 식별하는 FcmPlug 구조.

·anyStreamType - 스트림 타입이 스트림 매니저에 의해 선택된 또는 클라이언트에 의해 지정된 것이어야 하는지를 나타낸다.

·streamType - 클라이언트에 의해 지정된 경우의 스트림 타입.

·connId - FlowTo로 회복된 ConnectionId 값.

설명

이 API에 의해 클라이언트는 멀티 클러스터 HAVi 네트워크 상에 스트림의 생성을 요청할 수 있다. 이러한 네트워크에서, 소스 디바이스와 싱크 디바이스는 반드시 동일한 매체 타입일 필요는 없다. 소스와 싱크에 대해 동일하여야 하는 유일한 파라미터는 스트림 타입이다. 스트림 타입은 변환될 수 있지만, 이것은 변환기 모듈(converter module)(예를 들어, 하나의 스트림 타입을 위한 입력과 또다른 스트림 타입을 위한 출력을 갖는 변환기 FCM)에서 수행된다. 트랜스포트 타입의 변환은 브리지에 의해 수행된다. 본 실시예에 따라, 2개의 다른 매체 기술을 연결하는 브리지는 메시지와 스트림의 트랜스포트 타입을 하나의 타입으로부터 다른 타입으로 변환할 수 있다.

그 결과 본 실시예에 따라, 클라이언트는 이 멀티 클러스터 연결에 사용되는 트랜스포트 타입(들), 전송 포맷(들) 및 채널(들)을 주의하지 않는다. 이것은 스트림의 경로 상에 브리지의 스트림 매니저에 의해 처리된다.

에러 코드

·StreamManager::ESOURCE_FCM - source에 의해 지시되는 이 FCM이 존재하지 않는다.

·StreamManager::ESINK_FCM - sink에 의해 지시되는 FCM이 존재하지 않는다.

·StreamManager::ESOURCE_PLUG - source에 의해 지시되는 FCM이 지정된 플러그를 포함하지 않는다.

·StreamManager::ESINK_PLUG - sink에 의해 지시되는 FCM이 지정된 플러그를 포함하지 않는다.

·StreamManager::EUNSUP-STREAM - 연결은 지원되지 않는 스트림 타입을 요구한다.

·StreamManager::ENO_MATCH_STREAM - 플러그는 호환가능하지 않다(스트림 타입 불일치)

·StreamManager::ENO_MATCH_BW - 이 소스 대역폭은 sink에 의해 지원되는 것을 초과하거나 또는 hint.Stype.maxBW 는 소스/싱크 FCM(대역폭 불일치)의 지원되는 Stype.maxBW을 초과한다.

·StreamManager::ENO_MATCH_SPEED - 소스는 sink에 의해 지원되지 않는 전송 속도를 사용한다.

·StreamManager::ENO_MATCH_DIR - 플러그는 호환가능하지 않다(방향 불일치)

·StreamManager::ESOURCE_BUSY - 소스 플러그는 다른 스트림의 일원이다

·StreamManager::ESINK_BUSY - sink 플러그는 다른 스트림의 일원이다.

·StreamManager::EDEV_BUSY - 디바이스 플러그를 할당하는데 실패

·StreamManager::EINSUFF_BANDWIDTH - 대역폭 할당 실패

·StreamManager::EINSUFF_CHANNEL - 채널 할당 실패

·StreamManager::ESTATICBW - dynamicBw 는 값 False를 가지며, 스트림 타입은 가변 레이트이나, 소스는 정적 대역폭 할당으로 설정될 수 없다.

·StreamManager::ERESERVED_SOURCE - 요구되는 연결이 설정(즉, 오버레이 하지 않고)되고 예약 보호(reservation protection) 때문에 거절될 필요가 있다.

·StreamManager::ERESERVED_SINK - sink에 의해 지시된 FCM이 예비된다(그리고 FlowTo 요청을 하는 소프트웨어 요소에 의해서는 아니다)

·StreamManager::EDEV_CONN - 디바이스 연결을 설정하는데 실패

·StreamManager::ESHARE - 소스 플러그가 공유가능하지 않기 때문에 연결이 설정될 수 없다(그리고 소유자는 FlowTo 요청을 하는 소프트웨어 요소와는 다르다).

(b) SteamManager::OnThePath

프로토타입

파라미터

·dynamicBw - 동적(dynamicBw가 참이다) 또는 정적(dynamicBw가 거짓이다) 대역폭 할당이 설정되어야 하는지를 나타낸다.

·source - 소스 플러그를 식별하는 FcmPlug 구조.

·sink - sink 플러그를 식별하는 FcmPlug 구조.

·streamType - 연결의 스트림 타입. 이 스트림 타입은 전체 연결에 걸쳐 고유한 반면, 트랜스포트 타입, 전송 포맷 및 채널은 (특히 여러 매체 기술을 횡단할 때) 달라질 수 있다.

· segmentTransportType, segmentTransmissionFormat, segmentChannel - 현재 세그먼트, 즉 이 호출을 수신하는 포털이 부착되는 클러스터의 트랜스포트 타입, 전송 포맷 및 채널의 값.

·connId - 초기 스트림 매니저에 의해 할당된 ConnectionId 값.

설명

이 API 는 적어도 하나의 클러스터를 가로질러 연결을 설정하기 위해 브리지에 있는 스트림 매니저 사이에 사용된다. dynamicBw, source, 및 sink 파라미터는 원래의 MultiClusterFlowTo 방법 호출로부터 복사된다. 이들 파라미터는 경로 상의 어느 포털로 이들이 스트림을 송신할 필요가 있는지를 결정하기 위해 포털의 스트림 매니저에 의해 사용된다.

streamType 파라미터는 스트림의 타입을 식별한다. 이 타입은 전체 스트림에 대해 고유하며, 이것은 스트림을 운반하는데 사용되는 트랜스포트에 의해 영향을 받지 않기 때문이다. 스트림 타입을 변경(예를 들어 DV에서 MPEG2로 변경)하는 스트림은 변환기(예를 들어 FCM 변환기)를 통과하여 가며 그리고 사실 여기에는 2개의 실행 스트림이 있을 수 있으며, FCM 변환기는 변환된 스트림을 위한 소스와 제 1 스트림을 위한 싱크이다.

"segment" 파라미터(segementTransportType, segmentTransmissionFormat 및segmentChannel)는 스트림의 현재(즉 타깃 스트림 매니저에 대해 로컬) 세그먼트에 사용되는 파라미터를 식별한다. 이것은, 이 호출을 수신하는 포털의 스트림 매니저가 세그먼트를 공동 포털로 내부적으로 연결하기 위해 그 세그먼트에 설정된 연결에 관한 모든 정보를 얻는데 유용하다.

connId 파라미터는 초기 스트림 매니저에 의해 채워지며, 이 파라미터는 그 세그먼트 스트림을 멀티 클러스터 스트림에 "부착"하기 위해 스트림 경로 상에 있는 포털 스트림 매니저에 의해 사용된다.

에러 코드

·StreamManager::EUNSUP_TRANSPORT - 연결은 지원되지 않은 전송 타입을 요구한다.

·StreamManager::EUNSUP_STREAM - 연결은 지원되지 않은 스트림 타입을 요구한다.

·StreamManager::ENO_MATCH_FMT - 플러그는 호환가능하지 않다(전송 포맷 불일치)

·StreamManager::ENO_MATCH_SPEED - 소스는 sink에 의해 지원되지 않는 전송 속도를 사용한다.

·StreamManager::ENO_MATCH_TRANSPORT - 플러그는 호환가능하지 않다(전송 타입 불일치)

·StreamManager::ENO_MATCH_DIR - 플러그는 호환가능하지 않다(방향 불일치)

·StreamManager::ESOURCE_BUSY - source 플러그는 다른 스트림의 일원이다.

·StreamManager::ESINK_BUSY - sink 플러그는 다른 스트림의 일원이다.

·StreamManager::EDEV_BUSY - 디바이스 플러그를 할당하는데 실패

·StreamManager::EINSUFF_BANDWIDTH - 대역폭 할당 실패

·StreamManager::EINSUFF_CHANNEL - 채널 할당 실패

·StreamManager::EDEV_CONN - 디바이스 연결을 설정하는데 실패

멀티 클러스터 스트림 연결을 설정하기 위한 프로세스는 다음과 같다:

멀티 클러스터 스트림은 클라이언트에 대해 로컬인 스트림 매니저에 의해 개시되며, HAVi-1.1에서와 같이 매니저에 의해 소유된다("소유한다"는 것은 로컬 연결 맵에 존재한다는 점이다). 이 스트림 매니저는 "초기" 스트림 매니저라고 불리운다. 이 매니저는 싱크(sink) 디바이스로 가는 경로 상의 타깃 기능 성분(디바이스)의 최단 거리에 있는 포털의 스트림 매니저로 이 호출을 송신한다. 결과적으로, 포털의 스트림 매니저는 로컬 호출(로컬 클라이언트에 의해)과 리모트 호출(리모트 스트림 매니저에 의해)을 수신할 수 있다.

이 포털 스트림 매니저는 타깃 소스 기능 성분과 클러스터에 대한 연결을 이루는 일을 하며, 공동 포털의 스트림 매니저는 스트림 경로 상의 그 다음 클러스터에 대한 연결을 이루는 일을 한다. 만일 스트림이 다른 브리지를 횡단하면, 공동 포털 스트림 매니저는 모든 필요한 정보와 함께 HAVi 메시지를 스트림 경로 상의 그 다음 브리지의 스트림 매니저로 송신하여, 이 그 다음 브리지 스트림 매니저가 클러스터 등에 연결을 이루는 이 연결을 공동 포털로 내부적으로 송신할 수 있다.각 세그먼트에서, 적절한 스트림 매니저는 DCM의 API를 호출하여 트랜스포트 파라미터의 선택을 수행하며, 이들 DCM 은 소스(source) 디바이스와 싱크(sink) 디바이스 중 하나일 수 있을 뿐만 아니라 경로 상의 브리지 중 하나일 수 있다.

그래서, 그 프로세스는:

1. 클라이언트가 초기 스트림 매니저라고 부르는 로컬 스트림 매니저의 MultiClusterFlowTo API를 호출한다.

2. 초기 스트림 매니저는 소스 기능 성분(디바이스, FCM이 아님)을 검색하며 이 호출을 싱크(sink)로 가는 경로 상의 소스 클러스터에 연결된 제 1 포털로 송신한다. 이 포털은 일차 포털(primary portal)이라고 불리운다. 2가지 가능성이 있으나, 동작에 있어서는 차이가 없다:

·소스 기능 성분은 리모트 클러스터 상에 있으며, MultiClusterFlowTo 호출을 이 성분에 연결된 최단 거리의 포털의 스트림 매니저로 송신한다(네트워크 매니저에 의해 제공되는 NetDeviceInfo 구조에 있는 nearestPortalGuid 파라미터로 알려져 있음).

·소스 기능 성분은 로컬 클러스터 상에 있으며, MultiClusterFlowTo 호출을 sink 기능 성분 디바이스로 가는 경로 상에 로컬 클러스터 포털의 스트림 매니저로 송신한다(sink 디바이스의 GUID 는 이 포털의 리모트 리스트 상에 있으며, 로컬 클러스터의 임의의 다른 포털의 것에 있지는 않다).

3. 일차 포털 상에 있는 이 스트림 매니저는 스트림의 종단 포인트(end point)를 갖는 스트림 타입 상의 모든 DCM 및 FCM HAVi 동작을 수행한다. 나아가,이 매니저는 이 클러스터에 대한 트랜스포트 상에서 모든 HAVi 동작을 수행한다.

4. 이후 이 스트림 매니저는 제 1 세그먼트 상의 스트림 즉 소스 디바이스와 일차 포털 사이에 있는 스트림을 설정하는 일을 담당한다.

5. 이 매니저는 공동 포털의 스트림 매니저를 돕는다.

6. 이 스트림 매니저는 제 2 (또는 그 다음) 세그먼트에 있는 스트림을 설정하는 일을 담당한다. 이 매니저는 최종 싱크(sink) 디바이스 또는 다른 포털로 가는 것일 수 있다. 세그먼트 상의 스트림의 트랜스포트는 (HAVi 동작 및 DCM/FCM 호출을 포함하는) 이 스트림 매니저에 의해 전적으로 결정되고 처리된다.

7. 만일 다른 포털이 경로 상에 있는 경우, 스트림 매니저는 sink 디바이스로 가는 경로 상에서 그 다음 포털에 상주하는 스트림 매니저의 StreamManager::OnThePath API를 호출한다. 단계 5로 간다.

특정 클러스터에서, 연결의 설정은 source 및 sink 종단 포인트(포털 또는 디바이스) 모두의 스트림 매니저를 포함시킬 수 있다.

그 프로세스 도표는 도 10에 도시되어 있는 바와 같다.

멀티 클러스터 스트림 연결 제거를 위해, 새로운 API를 요구할 필요가 없다. 실행 스트림을 드롭(drop)시키고자 원하는 임의의 SE는 스트림을 소유하는 스트림 매니저의 Drop API를 호출한다. 만일 이 스트림이 멀티 클러스터 스트림이라면, 이 초기 스트림 매니저는 이 호출을 스트림 경로 상에 있는 제 1 포털로 송신하며 그리고 제거 프로세스는, 모든 포털 스트림 매니저가 담당하는 클러스터 상의 연결을 위한 식별자로서 내부적으로 보관해온 ConnectionID에 기초한 설정 프로세스와 동일하다.

이 해법에 따라, HAVi-1.1 디바이스는 리모트 스트림 매니저에 의해 설정된 스트림을 드롭시킬 수 없는데, 그 이유는 이 디바이스가 그 스트림을 심지어 보지 못하기 때문이다. 이 디바이스는 클러스터 상의 스트림 매니저에 의해 소유된 멀티 클러스터 스트림을 드롭시킬 수 있다(심지어, 이 스트림에 대한 source 및/또는 sink를 이해하지 못하는 경우라 하더라도).

일 변형으로서, 연결 설정은 source로부터 sink로 수행되지 않고 sink로부터 source로 수행될 수 있다.

동적 대역폭 할당은 여전히 멀티 클러스터 스트림에서 관리될 수 있다. dynamicBw 부울리안 파라미터가 MultiClusterFlowTo API에서 True로 설정되면, DCM 소스는 클러스터 상에서 자원을 재할당하는 일을 담당한다. 이 소스는 BandwidthRequirementChanged 이벤트를 송신한다. 이 이벤트는 경로 상의 그 다음 세그먼트를 담당하는 스트림 매니저에 의해 잡힌다. 이 스트림 매니저는 필요하다면 대역폭 등을 재할당한다. 만일 dynamicBw 부울리안 파라미터가 MultiClusterFlowTo API에서 False로 설정되면, 스트림을 위해 필요한 대역폭의 변화는 스트림을 실패 모드로 놓을 수 있다(HAVi-1.1에 기술된 바와 같이).

스트림 연결 에러 처리는 다음과 같이 수행된다: 연결이 설정 프로세스 동안 하나의 세그먼트에서 설정될 수 없을 때, 스트림 매니저는 상태 회복 값으로 실패 이유와 함께 OnThePath 메시지를 다시 송신한다. 이 연결이 클라이언트에 경고를 하거나 또는 이용가능하다면 "대안적인 경로"를 취하는 초기 스트림 매니저에까지세그먼트 별로 제거한다(아래 참조).

기존의 연결이 세그먼트에서 (버스의 리셋, 자원의 부족, 등...으로 인해) 단절되면, 이 연결을 담당하는 이 세그먼트에서의 스트림 매니저는 초기 스트림 매니저에 의해 잡힌 MultiClusterConnectionDropped 이벤트를 송신하며, 이 매니저는 스트림을 드롭하는 일을 담당하거나 또는 이 스트림을 "대안적인 경로"를 통해 살아있게 유지하게 시도한다. 초기 스트림 매니저는 OnThePath API의 connId 파라미터를 통해 검색할 수 있다. 이 connId 파라미터는 초기 스트림 매니저의 SEID 인 mgr 파라미터에 연결을 제공한다.

Encapsulation vs. translation

본 실시예에 따라, 만약 스트림이 매체 기술 B에 기초하는 클러스터를 건너 매체 기술 A에 기초하는 클러스터로 간 후 다시 매체 기술 A에 기초하는 클러스터로 가는 경우, B 타입의 클러스터에 있는 스트림 매니저는 스트림의 트랜스포트 타입(예를 들어, IP에 대해 1394)을 번역하지 않도록 결정한다. 이 스트림은 클러스터 B에서 캡슐화된다. 이것은 성능 때문에 유용할 수 있다. 그러나, sink 디바이스가 클러스터 B 상의 이 스트림에 추가되자마자, 스트림이 번역되어, 매체 기술 B 위의 렌더러(renderer)가 스트림을 디스플레이 할 수 있다. 그래서, A →B 로의 번역은 클러스터 B에서 수행되고 B →A 로의 번역은 타깃 A 타입 클러스터에서 수행된다.

스트림 매니저는 소위 연결 맵(connection map)을 사용하여 HAVi 네트워크에서 실행되는 모든 HAVi 스트림의 리스트를 제공할 수 있다. 이것은GetGlobalConnectionMap API로 수행된다. 이 매니저는 Registry::GetElement의 것과 유사한 방식으로 작용한다. 이전과 같이, 네트워크 매니저에 의해 규정된 루프 해결 프로세스(loop resolution process)로 인해, 트래픽을 줄이기 위해 다른 클러스터의 스트림 매니저에 이 질문을 송신하도록 새로운 파라미터를 요구할 필요가 있다. 이 제안된 API 는 :

initialRequester 파라미터는 포털이 이 요청을 공동 포털로 송신하여야 하는지 여부를 알게 해준다. 각 스트림 매니저의 로컬 연결 맵은 포털 스트림 매니저에 의해 수집되며 최종적으로 초기 요청한 스트림 매니저로 되송신된다.

본 실시예에 따라, 클러스터 상의 디바이스로부터 GetLocalConnectionMap을 수신하는 브리지의 스트림 매니저는 SEID로부터 유도된 바와 같은 호출자의 아이디에 따라 서로 다르게 작용한다:

·호출자는 스트림 매니저가 아니다. 이것은, SE가 로컬 연결 맵을 알고자 원한다는 것을 의미한다. 로컬 연결 맵만이 응답으로 송신된다.

·호출자는 HAVi-1.1 디바이스(즉 비 브리지 인식 디바이스)에 있는 스트림 매니저이다. 다시, 로컬 연결 맵만이 응답으로 송신된다.

·호출자는 BA-디바이스 내의 스트림 매니저이다. 이 요청은 (만일 송신 규칙이 충족되면) 공동 포털로 송신되며, 공동 포털 스트림 매니저는 클러스터의 모든 스트림 매니저로 GetLocalConnectionMap을 송신하며 클러스터에 연결된 다른 포털의 스트림 매니저로 ForwardGetGlobalConnectionMap을 송신한다.

나아가, 작은 변경이 새로운 멀티 클러스터 연결을 처리하기 위해 Connection 데이터 구조에서 이루어진다. 새로운 엔트리가 나열되어 있는 ConnectionType에 추가된다:

enum ConnectionTpye {FLOW, SPRAY, TAP, MULTI_CLUSTER_FLOW};

그리고 MULTI_CLUSTER_FLOW 연결 타입의 경우에, Connection 구조의 transmissionFormat 및 채널 파라미터는 소스 디바이스에 따라 설정될 수 있다(그래서, 사실 경로 상의 제 1 포털과 소스 사이에 제 1 세그먼트에 스트림을 반영만 할 수 있다).

connectionId 구조로부터 복사된 segmentId 파라미터와 함께 각 세그먼트에 대한 연결의 식별의 필요성(지정된 클러스터에 있는 스트림을 담당하는 스트림 매니저를 식별하는 mgr 필드)이 연구되어야 한다.

본 실시예에 따라, 대안적인 경로는 루프 분석 프로세스에 한정된 주 경로(main path)와 비교하여 특정 조건에서 제공된다.

경로 상의 하나의 클러스터에 대한 자원의 부족으로 인해 스트림이 설정될 수 없는 경우, 그리고 이 클러스터를 통해 지나가지 않는 소스와 싱크 사이에 다른 루트가 가능한 경우, 스트림 매니저와 네트워크 매니저는 트래픽 잼 클러스터(traffic-jammed cluster)를 피하기 위해 대안적인 경로 상으로 스트림을 재루트하기로 결정할 수 있다. 이것은 원래의 루트와 동일한 수의 홉을 가지는 루트에 적용할 수 있으나, 더 높은 수의 홉을 갖는 루트에도 적용할 수 있다. 이 경우에, 네트워크 매니저는 올바른 경로가 선택될 수 있도록 다른 포털 리모트 리스트에 현재 있는 디바이스에 도달하는 것을 내부적으로 추적하여야 한다.

도 11 은 대안적인 경로를 사용하는 일례를 도시한다. 우측에 있는 클러스터(1101)는 이 클러스터의 거의 모든 자원(대역폭이나 채널 또는 이 둘 모두)을 불행히도 예비한 스트림으로 이미 활성화되어 있다. HAVi 어플리케이션은 디바이스(3)와 디바이스(4) 사이에 스트림을 설정하기를 원한다. 네트워크 매니저에 기본적인 리모트 GUID 리스트가 있는 경우, 이것은, 스트림이 클러스터(1101)를 통해 설정되기 때문에 작동하지 않을 수 있으며 그래서 실패할 수 있다. 일단 이 실패가 알려지면, 스트림 매니저는 이 스트림에 대해 스트림을 지니고 있는 자원을 가지는 좌측에 있는 클러스터를 통해 통과하는 대안적인 경로를 사용하기로 결정한다. 공동 포털(14)을 통해 디바이스(13)에 까지 스트림을 송신할 수도 있다.

다음 프로세스는 대안적인 경로를 결정하는 본 경우에 사용된다:

1. 연결을 설정하는 동안 세그먼트(클러스터)에 대한 스트림 설정은 가능하지 않다.

2. 클러스터 이전에 브리지가 경고된다(에러가 OnThePath 호출을 위해 회복된다).

3. 브리지는 다른 경로가 존재하는지를 체크한다.

4. 발견되지 않으면, 에러는 OnThePath에 대해 호출 전에 브리지로 회복된다.

5. 단계 3으로 간다.

(h) 자원 매니저

자원 매니저는 브리지에 의해 영향을 받지 않아야 한다.

Ⅱ] HAVi 브리지 인식 디바이스

도 12 는 본 실시예에 따라 브리지 인식 디바이스(나머지 설명에서 BA-디바이스라고 부름)의 내부 소프트웨어 아키텍처를 도시한다. BA 디바이스는 HAVi 1.1의 소프트웨어 요소와 Sdd Manager 및 네트워크 매니저를 포함한다.

·Sdd Manager

브리지 디바이스에 전용된 섹션에서 이미 제시된 바와 같이, BA 디바이스의 Sdd Manager는 전체 HAVi 네트워크 상의 임의의 디바이스의 SDD 데이터를 검색하는 일을 담당한다. 이것은 리모트 Sdd Manager에 억세스하거나 또는 로컬 저 레벨 호출을 수행하여 이루어진다.

·CMM

HAVi-BA-디바이스를 위한 CMM에는 기본적으로 변경이 없다. CMM 은 저 레벨 로컬 클러스터에 억세스하는 일을 담당한다. 그래서 이 CMM은 여전히 GetGuidList API를 제공하며 로컬 클러스터 상의 모든 GUID의 리스트를 다시 제공한다. 그리고, 이것은 이 클러스터에 저 레벨 메시지를 송신/수신하는 방법을 제공한다. 사실, CMM 1394 는 HAVi-1.1 문서에 명시되어 있다.

Network Manager

BA 디바이스의 네트워크 매니저는 다음과 같이 동작한다:

·클러스터 리컨피규레이션 후에, BA 디바이스는 로컬 디스커버리를 수행한다.

·만일 이 매니저가 새로운 브리지를 검출하면, 이 매니저는 각 리모트 리스트를 요청한다.

·ENOT_READY 에러 응답을 수신하면, 이 매니저는 어느 정도의 시간을 기다려 RemoteNetworkUpdated 이벤트를 수신한다.

·만일 이벤트가 특정 시간 후에 오지 않으면, 이 매니저는 응답하지 않는 포털의 리모트 리스트를 얻도록 다시 시도할 수 있다.

·이 매니저가 포털로부터 모든 응답을 가질 때, 이 매니저는 새로운 리스트를 설정하며 변경된 필드, 탈퇴된 필드 및 새로운 필드를 채우기 위해 리스트를 비교한다.

·그 네트워크 디바이스 리스트가 수행되면, 이 매니저는 NetworkUpdated 이벤트를 클라이언트에게 송신한다.

·이 매니저가 새로운 리스트를 설정하는 시간 동안, 네트워크 디아비스 리스트를 얻기 위한 임의의 클라이언트 요청이 ENOT_READY 에러와 함께 응답된다.

Ⅲ] 새로운 HAVi 값

HAVi 1.1에 존재하는 것 이외에 새로운 HAVi 소프트웨어 요소 타입은 아래 규정되어 있다.

[표 11]

HAVi 소프트웨어 요소 타입 ATT_SE_TYPE 값 신뢰성 시스템 요소

SDD MANAGER0x0000 0007 Yes Yes

NETWORK_DEVICE_MANAGER0x0000 0008 Yes Yes

본 실시예에 따라 HAVi SEID 는 다음과 같다:

[표 12]

HAVi 소프트웨어 요소 타입 소프트웨어 요소 처리

SDD_MANAGER 0x0007

NETWORK_DEVICE_MANAGER 0x0008

COMMUNICATION_MEDIA_MANAGER_IP 0x0009

HAVi API 코드는 다음과 같다.

[표 13]

HAVi API 이름 API 코드

SddManager 0x0017

NetworkManager 0x0018

CmmIp 0x0019

Registry, StreamManager, SddManager, 및 CMMIP를 위한 추가적인 HAVi 동작 코드는 본 실시예에 따라 다음과 같다:

[표 14]

본 실시예에 따라 SddManager 및 NetworkManager를 위한 HAVi 에러 코드는 다음과 같다:

[표 15]

본 실시예에 따라 HAVi 시스템 이벤트 타입은 다음과 같다;

Ⅳ] 디스커버리 시나리오

(a) 루프 없는 네트워크

도 18 은 완전한 네트워크 설정 프로세스 동안 네트워크 매니저의 상호작용을 도시한다. 모든 디바이스가 먼저 턴오프되고 이후 동시에 턴온되며, 그래서 디스커버리(discovery)는 각 디바이스에 동시에 이루어진다. 브리지 네트워크 매니저에 대해 Local 및 Remote 리스트 구성이 기술된다.

도 13에는, 제 1 로컬 디스커버리 프로세스, 즉 IEEE 1394 클러스터에 대한 토포로지 설정과 IP 클러스터에 대한 멀티캐스터 고지(multicast announcement)가 도시되어 있다. 이 제 1 단계의 종료시에, 네트워크 매니저는 도 13에 도시된 바와 같이, 내부 표에서 로컬 디바이스를 가진다.

브리지 디바이스는, 만일 네트워크 매니저가 완전한 비-리모트 리스트 또는 불완전한 비-리모트 리스트를 가지는지를 체크한다. 비-리모트 리스트는 클러스터에 연결된 다른 포털의 모든 리모트 리스트에 로컬 리스트를 더한 것을 포함한다. 그러한 완전한 리스트가 하나의 포털에 존재하는 경우, 이 리스트는 다른 측(공동 포털)에 제공되며, 이 다른 측은 리모트 리스트를 완전한 것으로 간주한다. 도 14에서, 브리지 AB의 GUID 5의 네트워크 매니저는, 이 브리지가 이 디바이스 상의 유일한 브리지라는 것을 보며, 그래서 이 브리지는 (1,2,5)로 되는 GUID 6의 리모트 리스트를 업데이트 할 수 있다. 브리지 디바이스(BC)에 대해서도 동일하며, GUID 7의 네트워크 매니저는 (3,4,8)로 리모트 리스트를 업데이트한다.

도 15에서, 브리지 디바이스의 네트워크 매니저는 디바이스의 리모트 리스트를 서로 요구한다. 브리지 디바이스의 네트워크 매니저는 리모트 브리지 리스트를반복적으로 업데이트할 수 있다. 특히, 요청이 일단 응답되면 포털 6과 포털 7에 대한 비-리모트 리스트가 완전하기 때문에 포털 5 및 포털 8의 리모트 리스트는 업데이트될 수 있다.

도 16에서, BA 디바이스의 네트워크 매니저는 로컬 클러스터에 연결된 각 브리지 디바이스에 리모트 디바이스 리스트를 요구하며 글로벌 네트워크 리스트를 구축한다.

도 17에서, 클라이언트 SE 는 전체 네트워크에 있는 디바이스의 글로벌 리스트를 로컬 네트워크 매니저에 요구할 수 있다.

(b) 루프 없는 네트워크에서 새로운 디바이스를 추가하기

도 18 은 시작 포인트, 즉 루프 없는 기존의 네트워크를 보여준다. 리모트 리스트만이 브리지 네트워크 매니저에 도시되어 있다.

GUID 9를 갖는 새로운 디바이스가 추가된다. 이 디바이스는 로컬 디스커버리 수단(selfID, 멀티캐스트...)을 통해, 디바이스가 연결된 클러스터에 대해 검출된다. 일단 검출되면, 이 GUID 는 여기에 연결된 브리지의 공동 포털의 네트워크 매니저에서 업데이트된다. 이것은 도 19에 도시되어 있으며, 이 공동 포털 7 은 새로이 연결된 GUID 9를 갖는 리모트 리스트를 업데이트한다.

이후 updated 포털은 RemoteNetworkUpdated 이벤트를 (BA-디바이스에 있는 그리고 브리지에 있는) 다른 네트워크 매니저로 송신한다. 이 포털에 연결된 브리지는 포털 7로부터 이벤트를 포착하며 포털 5를 업데이트한다.

완전한 네트워크가 이후 업데이트된다. GUID 9 는 이제 모든 클러스터에 알려진다.

(c) 루프 있는 네트워크

이전과 같이 도 21에 도시된 네트워크의 모든 디바이스는 다소 동시에 턴온된다. 제 1 단계는 여전히 로컬 리스트를 생성하는 로컬 디스커버리 프로세스이다.

이 컨피규레이션에서, 어떤 포털도 유효 리모트 리스트로 공동 포털에 제공하기 위한 완전한 비-리모트 리스트를 가질 수 없다. 모든 포털은 이들이 그 클러스터 상에 혼자 있지 않다는 것을 알며, 그래서 이 포털은 자기 고유의 공동 포털의 리모트 리스트를 업데이트 하기 전에 그 리모트 리스트를 다른 포털에 먼저 요구한다(도 22). 그리고 이 토포로지에는 가지(leaf)가 없으므로, 모든 포털은 다른 포털을 기다린다.

포털이 GetRemoteDeviceList 질문에 응답할 수 없기 때문에, 포털은 ENOT_READY 응답 에러를 송신한다. 포털 내의 네트워크 매니저가 이러한 에러를 수신하면, 이 네트워크 매니저는 클러스터에 연결된 포털이 리모트 리스트를 업데이트하는 것을 종료하지 못했음을 안다(예를 들어, 이 포털은 공동 포털에 연결된 다른 포털을 기다리고 있으며: 이것은 매우 긴 하나의 라인 네트워크를 발생시킬 수 있다).

본 실시예에 따라, 포털은 공동 포털에 불완전한 리모트 리스트를 전달한다. 공동 포털은 이 불완전한 정보와 함께 리모트 리스트를 업데이트 한다. 이것은 도 23에 도시된다.

포털은 도 24에 도시된 바와 같이, RemoteNetworkChanged 이벤트와 함께 이불완전한 리모트 리스트를 송신한다. 이 이벤트는 브리지만의 네트워크 매니저를 위한 것이며 리스트가 안정한 상태에 있지 않는 것을 명확히 나타낸다(그러나, RemoteNetworkUpdated 는 최종 안정적인 리스트이다).

전술된 바와 같이, 본 발명은 멀티 클러스터 네트워크에서의 통신 방법 뿐만 아니라 그러한 네트워크에서의 디바이스 및 클러스터들을 연결하기 위한 브리지 디바이스에 이용가능하다.

Claims (34)

1. 네트워크에 있는 네트워크 디바이스의 각 클러스터(cluster)를 인터페이싱하기 위한 적어도 2개의 인터페이스를 포함하며, 클러스터들을 연결하기 위해 적어도 2개의 인터페이스 포털(interface portal)을 포함하는, 브리지 디바이스(bridge device)에 있어서,

   상기 브리지 디바이스는 각 포털에 대해 적어도 하나의 네트워크 디바이스의 디바이스 설명 컨피규레이션 메모리 데이터(device describing configuration memory data)(SDD)에 대한 요청을 내부 클라이언트로부터 수신하기 위한 제 1 소프트웨어 성분(SDDM)을 포함하며, 상기 제 1 소프트웨어 성분은 다른 디바이스에 있는 이와 유사한 소프트웨어 성분의 기능 호(function call)를 통해 다른 디바이스로부터 디바이스 설명 데이터를 검색하도록 적응되는 것을 특징으로 하는, 브리지 디바이스.
2. 제 1 항에 있어서, 상기 제 1 소프트웨어 성분은 리모트 클러스터 디바이스(remote cluster device)로 가는 경로 상에 있는 브리지 디바이스의 이와 유사한 소프트웨어 성분에 대한 기능 호를 통해 이와 유사한 소프트웨어 성분 없이 리모트 클러스터 디바이스에 대한 데이터를 검색하도록 적응되는, 브리지 디바이스.
3. 제 1 항 또는 제 2 항에 있어서, 상기 제 1 소프트웨어 성분은 매체 종속 요청 메시지를 상기 디바이스에 송신하는 것에 의해 자기 자신과 동일한 클러스터 상에 유사한 소프트웨어 성분이 없는 디바이스에 대한 데이터를 검색하도록 적응되는, 브리지 디바이스.
4. 제 1 항 내지 제 3 항 중 어느 한 항에 있어서, 상기 제 1 소프트웨어 성분은,

   a. 상기 네트워크 상에 다른 디바이스의 제 1 소프트웨어 성분의 식별자의 리스트(list)와,

   b. 상기 리스트 내의 디바이스로 가는 경로에서 최단 거리에 있는 포털의 각 식별자와 연관된, 유사한 제 1 소프트웨어 성분이 없는 디바이스의 리스트

   중 적어도 하나를 유지하도록 적응되는, 브리지 디바이스.
5. 제 1 항 내지 제 4 항 중 어느 한 항에 있어서, 상기 제 1 소프트웨어 성분은 그 포털 로컬 클러스터 상의 제 1 소프트웨어 성분이 없는 디바이스의 디바이스 설명 데이터에서의 변화를 모니터하며 상기 브리지 디아비스의 다른 포털에 연결된 상기 클러스터 상에 대응하는 디바이스 설명 데이터 변화 이벤트를 생성하도록 적응되는, 브리지 디바이스.
6. 제 1 항 내지 제 5 항 중 어느 한 항에 있어서, 각 포털에 대해 상기 포털클러스터의 통신 매체와 각 포털의 포털의 다른 소프트웨어 성분을 인터페이싱하기 위한 제 2 소프트웨어 성분(CMM)을 더 포함하며, 상기 제 2 소프트웨어 성분은 상기 통신 매체에 리모트로 억세스하기 위해 어플리케이션 프로그래밍가능한 인터페이스를 포함하고 상기 인터페이스의 상기 네트워크의 다른 디바이스의 소프트웨어 성분에 대해 적어도 특정 방법은 전체적으로 억세스할 수 있는, 브리지 디바이스.
7. 제 6 항에 있어서, 상기 전체적으로 억세스가능한 방법은 쓰기(write), 읽기(read), 잠금(lock), 등록(enroll), 탈퇴(drop), 지시(indication) 중에서 적어도 하나를 포함하는, 브리지 디바이스.
8. 제 1 항 내지 제 7 항 중 어느 한 항에 있어서, 각 포털에 대해 상기 네트워크의 모든 클러스터 상의 모든 디바이스의 리스트를 유지하기 위한 제 3 소프트웨어 성분(NM)을 더 포함하는, 브리지 디바이스.
9. 제 8 항에 있어서, 상기 제 3 소프트웨어 성분은 네트워크의 임의의 클러스터에 대한 변화의 검출시에, 그 변화의 특성을 그 포털의 소프트웨어 성분에게 알리는 제 1 이벤트를 생성하도록 적응되는, 브리지 디바이스.
10. 제 8 항 또는 제 9 항에 있어서, 상기 제 3 소프트웨어 성분은 포털의 리모트 디바이스 리스트를 발행하는 이벤트의 상태만을 다른 포털의 제 3 소프트웨어성분에게 알리기 위한 제 2 이벤트를 생성하도록 적응되는, 브리지 디바이스.
11. 제 10 항에 있어서, 상기 제 2 이벤트는 이벤트 발행 포털에 비해 리모트 디바이스, 즉 상기 이벤트 발행 포털의 공동 포털을 통해 도달가능한 디바이스의 불완전 리스트를 잠재적으로 포함하는, 브리지 디바이스.
12. 제 8 항 내지 제 11 항 중 어느 한 항에 있어서, 상기 제 3 소프트웨어 성분은 호스팅 포털 리모트 디바이스 리스트가 안정적이라는 것을 클러스터 상의 모든 디바이스의 제 3 소프트웨어 성분을 알리기 위한 제 3 이벤트를 생성하도록 적응되는, 브리지 디바이스.
13. 제 12 항에 있어서, 상기 제 3 이벤트는 이벤트 발행 포털에 비해 리모트 디바이스, 즉 상기 이벤트 발행 포털의 공동 포털을 통해 도달가능한 디바이스의 완전한 리스트를 포함하는, 브리지 디바이스.
14. 제 1 항 내지 제 13 항 중 어느 한 항에 있어서, 각 포털은 포털 로컬 클러스터 상에서 검출된 이벤트 메시지를 공동 포털로 송신하기 위한 제 4 소프트웨어 성분(EM)을 포함하는, 브리지 디바이스.
15. 제 1 항 내지 제 14 항 중 어느 한 항에 있어서, 각 포털은 브리지 클러스터중 하나에서 다른 디바이스의 제 5 소프트웨어 성분으로부터의 요청을 수신하기 위한 제 5 소프트웨어 성분(Reg)과, 소스 주소(source address)로서 초기 요청자의 식별자와 함께 다른 클러스터 상의 제 5 소프트웨어 요소에 상기 요청을 송신하며 상기 요청에 대한 비-연관된 응답을 초기 요청 디바이스로 송신하기 위한 수단을 포함하는, 브리지 디바이스.
16. 제 1 항 내지 제 14 항 중 어느 한 항에 있어서, 각 포털은, 브리지 클러스터 중 하나에서, 다른 디바이스의 제 5 소프트웨어 성분으로부터 요청을 수신하기 위한 제 5 소프트웨어 성분(Reg)과, 상기 요청을 다른 클러스터에 있는 제 5 소프트웨어 요소에 송신하며 여기서 송신된 요청은 송신 포털의 주소를 파라미터로 포함하는, 송신된 요청을 수신하며 그 응답을 연관시키며, 그리고 이 요청에 대한 연관된 응답을 초기 요청 디바이스에 송신하기 위한 수단을 포함하는, 브리지 디바이스.
17. 제 16 항에 있어서, 상기 요청을 송신하기 위한 수단은 상기 요청을 상기 브리지 디바이스의 제 5 소프트웨어 요소에 송신하기 위한 제 1 메시지 타입과 상기 요청을 비-브리지 디바이스의 제 5 소프트웨어 요소로 송신하기 위한 제 2 메시지 타입을 사용하도록 적응되며, 여기서 송신 포털의 식별자는 제 1 메시지에서 하나의 파라미터이며 제 2 메시지에는 있지 않은, 브리지 디바이스.
18. 제 1 항 내지 제 14 항 중 어느 한 항에 있어서, 각 포털은 브리지 클러스터의 하나에서, 다른 디바이스의 제 5 소프트웨어 성분으로부터 요청을 수신하기 위한 제 5 소프트웨어 성분(Reg)과, 다른 클러스터 상의 제 5 소프트웨어 요소에 소스 주소로서 초기 요청자 식별자와 함께 상기 요청을 송신하며 이 송신된 요청에 응답을 가로채며, 이들 응답 내용을 연관시키며, 초기 요청에 대한 하나의 연관된 응답을 초기 요청 디바이스로 되송신하기 위한 수단을 포함하는, 브리지 디바이스.
19. 제 1 항 내지 제 18 항 중 어느 한 항에 있어서, 클러스터의 통신 매체 사이에 패킷 트랜스포트 타입을 변환시키기 위한 수단을 더 포함하는, 브리지 디바이스.
20. 제 1 항 내지 제 19 항 중 어느 한 항에 있어서, 각 포털은 다른 디바이스의 제 6 소프트웨어 요소로부터 연결 설정 요청을 수신한 때 브리지를 가로지르는 연결을 위해 로컬 클러스터 상에 연결 세그먼트(connection segment)를 설정하기 위한 제 6 소프트웨어 요소(SM)를 포함하는, 브리지 디바이스.
21. 제 20 항에 있어서, 포털의 제 6 소프트웨어 요소는 로컬 클러스터에 대한 연결을 설정하도록 적응되며 연결 종단 디바이스(connection end device)로 가는 경로 상에 그 다음 세그먼트 설정을 실행하도록 로컬 클러스터를 그 다음 포털에 알려주는, 브리지 디바이스.
22. 멀티 클러스터 네트워크(multi-cluster network)에서 클러스터에 연결하기 위한 디바이스로서, 여기서 클러스터는 브리지 디바이스를 통해 연결되며, 각 브리지 디바이스는 적어도 2개의 클러스터 인터페이스를 포함하며, 여기서 각 인터페이스는 각 클러스터 상의 네트워크 디바이스로 간주되는, 디바이스에 있어서,

    상기 네트워크 디바이스는 적어도 제 2 디바이스의 디바이스 설명 컨피규레이션 메모리 데이터(SDD)에 대한 요청을 내부 클라이언트로부터 수신하기 위한 제 1 소프트웨어 성분(SDDM)을 포함하며, 상기 제 1 소프트웨어 성분은 상기 적어도 하나의 디바이스에서 유사한 소프트웨어 성분의 기능 호(function call)를 통해 적어도 하나의 다른 디바이스로부터 디바이스 설명 데이터를 검색하도록 적응되는, 멀티 클러스터 네트워크에서 클러스터에 연결하기 위한 디바이스.
23. 제 22 항에 있어서, 상기 제 1 소프트웨어 성분은 리모트 클러스터 디바이스로의 경로 상에 브리지 디바이스의 유사한 소프트웨어 성분에 대한 기능 호를 통해 유사한 소프트웨어 성분이 없는 리모트 클러스터 디바이스에 대한 데이터를 검색하도록 적응되는, 멀티 클러스터 네트워크에서 클러스터에 연결하기 위한 디바이스.
24. 제 22 항 또는 제 23 항에 있어서, 상기 제 1 소프트웨어 성분은 매체 종속적인 요청 메시지를 제 2 디바이스에 발송하는 것에 의해 자기 자신과 동일한 클러스터 상에 유사한 소프트웨어 성분이 없는 제 2 디바이스에 대한 데이터를 검색하도록 적응되는, 멀티 클러스터 네트워크에서 클러스터에 연결하기 위한 디바이스.
25. 제 22 항 내지 제 24 항 중 어느 한 항에 있어서, 상기 제 1 소프트웨어 성분은,

    - 상기 네트워크 상에 다른 디바이스의 제 1 소프트웨어 성분의 식별자의 리스트와,

    - 이 리스트에 있는 상기 디바이스로의 경로 상에서 최단 거리에 있는 포털의 각 식별자와 연관된, 유사한 제 1 소프트웨어 성분이 없는 디바이스의 리스트

    중 적어도 하나를 유지하도록 적응되는, 멀티 클러스터 네트워크에서 클러스터에 연결하기 위한 디바이스.
26. 제 22 항 내지 제 25 항 중 어느 한 항에 있어서, 상기 네트워크의 모든 클러스터 상에 있는 모든 디바이스의 리스트를 유지하기 위한 제 3 소프트웨어 성분(NM)을 더 포함하며, 여기서 상기 제 3 소프트웨어 성분은 로컬 클러스터에 연결된 포털로부터 리모트 디바이스 리스트를 검색하며 그리고 로컬 클러스터 디바이스 리스트와 상기 리모트 디바이스 리스트를 연관시키기 위한 수단을 포함하는, 멀티 클러스터 네트워크에서 클러스터에 연결하기 위한 디바이스.
27. 제 26 항에 있어서, 상기 제 3 소프트웨어 성분은 디바이스 소유의 로컬 클러스터에 비해 리모트 디바이스에 대한 경로 상에서 최단 거리에 있는 포털의지시(indication)를 상기 네트워크 디바이스 리스트에 유지하도록 더 적응되는, 멀티 클러스터 네트워크에서 클러스터에 연결하기 위한 디바이스.
28. 제 25 항 내지 제 27 항 중 어느 한 항에 있어서, 상기 제 3 소프트웨어 성분은 상기 네트워크의 임의의 클러스터 상에 변화를 검출할 때 그 변화의 특성을 그 로컬 디바이스의 성분에게 알리는 제 1 이벤트를 생성하도록 적응되는, 멀티 클러스터 네트워크에서 클러스터에 연결하기 위한 디바이스.
29. 제 22 항 내지 제 28 항 중 어느 한 항에 있어서, 로컬 클라이언트로부터 리모트 소프트웨어 요소의 리스트에 대한 요청을 수신하며 상기 요청을 상기 로컬 클러스터의 디바이스의 제 5 소프트웨어 요소에만 송신하기 위한 제 5 소프트웨어 성분(Reg)을 포함하는, 멀티 클러스터 네트워크에서 클러스터에 연결하기 위한 디바이스.
30. 제 22 항 내지 제 29 항 중 어느 한 항에 있어서, 싱크 디바이스(sink device)와 소스 디바이스(source device) 사이의 연결을 설정하기 위한 요청을 수신하도록 적응된, 동일한 디바이스의 클라이언트에 대한 어플리케이션 프로그래밍 가능한 인터페이스를 구비하는 제 6 소프트웨어 요소(SM)를 포함하며, 상기 제 6 소프트웨어 요소는 상기 소스 디바이스와 싱크 디바이스 사이의 경로 상에서, 싱크 디바이스로의 경로 상에 소스 디바이스에서 최단 거리의 포털을 결정하도록 적응되며, 상기 제 6 소프트웨어 요소는 적절한 요청을 로컬 클러스터 상의 연결을 설정하기 위한 상기 포털로 송신하며 상기 요청을 상기 경로 상에 다른 적절한 포털로 전파하기 위한, 멀티 클러스터 네트워크에서 클러스터에 연결하기 위한 디바이스.
31. 적어도 2개의 디바이스 클러스터와 적어도 하나의 브리지를 포함하는 네트워크에서 디바이스를 발견(discovery)하기 위한 방법으로서, 여기서 적어도 2개의 클러스터는 하나의 브리지에 의해 연결되며, 각 브리지는 각 클러스터에 연결하기 위한 적어도 2개의 인터페이스 포털을 포함하는, 네트워크에서 디바이스를 발견하기 위한 방법에 있어서,

    - 각 포털이 로컬 클러스터의 디바이스의 식별자(GUID)의 리스트를 획득하게 하는 단계와,

    - 각 포털이 자기 자신과 동일한 클러스터의 각 포털로부터 리모트 디바이스 리스트를 요청하게 하는 단계와,

    - 각 포털이 공동 포털(co-portal)을 통해 도달가능한 리모트 디바이스와 그 로컬 디바이스의 리스트를 그 공동 포털로부터 요청하는 것에 의해 자기 소유의 리모트 디바이스 리스트를 구축하게 하는 단계

    를 포함하는, 네트워크에서 디바이스를 발견하기 위한 방법.
32. 제 31 항에 있어서, 주어진 디바이스가 그 디바이스로 가는 최단 거리의 경로 상에 있는 경우, 브리지가 주어진 디바이스로 향하는 메시지를 통과시키게 하는단계를 더 포함하는, 네트워크에서 디바이스를 발견하는 방법.
33. 제 32 항에 있어서, 상기 최단 거리의 경로는 횡단되는 포털의 수가 최저가 되는 경로인, 네트워크에서 디바이스를 발견하는 방법.
34. 클러스터와의 연결을 위한 인터페이스 포털을 각각 구비하는 브리지 디바이스에 의해 연결된 복수의 디바이스 클러스터를 포함하는 네트워크에서 싱크 디바이스와 소스 디바이스 사이의 연결을 설정하기 위한 방법에 있어서,

    (a) 상기 네트워크의 다른 브리지 인식 디바이스에 그리고 브리지의 포털에 스트림 매니저 소프트웨어 요소를 제공하는 단계와,

    (b) 로컬 클라이언트로부터의 연결 요청을 디바이스의 스트림 매니저 소프트웨어 요소의 레벨에서 수신하는 단계와,

    (c) 싱크 디바이스와 소스 디바이스 사이의 경로 상에, 소스 디바이스에서 최단 거리에 있는 포털을 식별하며 상기 포털에 연결 요청을 송신하는 단계와,

    (d) 상기 연결 요청을 수신한 포털이 상기 소스 디바이스와 상기 포털 브리지 사이의 연결 세그먼트를 요청하게 하는 단계와,

    (e) 상기 연결 요청을 수신한 포털이 상기 소스 디바이스로 가는 경로 상에 그 브리지의 그 다음 포털로 하여금 그 다음 포털의 로컬 클러스터 상의 연결의 그 다음 세그먼트를 설정하게 하는 단계와,

    (f) 상기 싱크 디바이스로 가는 경로 상에, 만약 있다면, 그 다음 브리지를식별하여, 상기 싱크 디바이스로 가는 경로 상에 상기 그 다음 브리지의 리모트 포털로 하여금 상기 연결의 적절한 세그먼트를 설정하도록 지시하게 하는 단계와,

    (g) 상기 싱크 디바이스에 연결하는 세그먼트가 설정될 때까지 단계 (e)로 되돌아가는 단계

    를 특징으로 하는, 네트워크에서 소스 디바이스와 싱크 디바이스 사이의 연결을 설정하기 위한 방법.