KR100918908B1 - 데이터 스트림을 네트워크를 통해 서로 다른 네트워크프로토콜을 지원하는 수신기에 송신하기 위한 시스템 - Google Patents

Abstract

본 발명은 제어 데이터 및 유용 데이터를 내포한 데이터 스트림을 전송하기 위한 시스템에 관한 것이다. 본 시스템은 제 1 네트워크 프로토콜이 사용되는 네트워크에 연결되는 송신기를 포함한다. 제 1 네트워크 프로토콜을 사용하는 네트워크에 한 개 이상의 수신기가 직접 또는 간접적으로 연결되며, 이 수신기는 중 하나 이상이 제 1 네트워크 프로토콜 대신에 제 2 네트워크 프로토콜을 지원한다. 상기 송신기는 제 1 네트워크 프로토콜에 대응하는 데이터 스트림을 발생시키기 위한 수단을 포함하며, 이 발생 수단은 제 2 네트워크 프로토콜로의 변환을 위해 추가 데이터로 상기 데이터 스트림을 보완한다. 상기 수신기는 입력 회로에 연결되거나 일체형으로 만들어진 변환 유닛을 포함하며, 이 변환 유닛은 제 1 네트워크 프로토콜에 따라 전송되는 데이터를 제 2 네트워크 프로토콜에 해당하는 데이터로 변환시킨다. 변환 규약에 대응하는 데이터는 상기 네트워크 상에서 송신기로부터 수신기까지 전송되는 것이 바람직하다.

Description

데이터 스트림을 네트워크를 통해 서로 다른 네트워크 프로토콜을 지원하는 수신기에 송신하기 위한 시스템{SYSTEM FOR TRANSMITTING A DATA STEAM OVER A NETWORK TO RECEIVERS THAT SUPPORT DIFFERENT NETWORK PROTOCOLS}

본 발명은 콘트롤 데이터와 유용 데이터를 포함하고 있는 데이터 스트림을 송신하기 위한 시스템에 관한 것으로서, 데이터 스트림은 하나의 송신기와, 전형적으로 적어도 두 개의 수신기를 포함하며, 그 중 첫 번째 수신기는 제 1 네트워크(Network) 프로토콜(Protocol)을 그리고 두 번째는 제 2 네트워크(Network) 프로토콜(Protocol)을 지원하고, 그리고 송, 수신기 사이에 제공된 하나의 네트워크를 가진다.

기기들을 방송망으로 연결하기 위하여 과거에는 각각 사용 분야에 따라 대량의 가지각색의 물리적 네트워크가 발전되었다. 게다가 많은 경우 데이터 송신과 더불어 호환성을 이유로, 방송망을 설치하기에 적합한 네트워크 프로토콜에 의거하여, 데이터가 다른 네트워크 내지 다른 네트워크 프로토콜에 깨끗하게 송신될 수 있도록 하였다. 예를 들면 상기와 관련하여 인터넷-프로토콜에 상응하는 네트워크(IP-네트워크)를 통해 IPX-패키지(Package)가 송신되고, IEEE Std 1394-1995 내지 IEEE-Std 1394a-2000(1394-네트워크)에 따른 네트워크를 통해 인터넷-프로토콜에 적합한 패키지(IP-패키지)를 송신하며, IEC 61883에 의거 RTP 또는 1394-네트워크를 사용하여 IP-네트워크를 통해 MPEG2-전송 스트림이 송신된다. 또한 어떤 네트워크 프로토콜이 각 엔딩(Ending) 기기에 의해 지원되는 가에 따라서, 실제 유용 데이터들이 동일한 물리적 네트워크에 수송되기 위하여 상이하게 패키지화되거나 내지 구성될 수 있다.

만일 사용된 네트워크가 또한 물리적으로 단지 포인트-투-포인트(Point-to-Point)-결합을 가능하게 한다면, 이는 문제되지 않는다. 만일 유용 데이터(useful)가 각 수신기로 보내어질 수만 있다면, 또한 문제되지 않는다.

그러나 만일 유용 데이터가 서로 다른 수신기로 보내어져야만 한다면, 그렇다면 상황은 다르다. 기존의 네트워크는 물론 위와 같은 네트워크를 물리적으로 지원한다. 그러나 개별 수신기들은 다른, 호환성이 없는 네트워크 프로토콜만을 지원한다. 이러한 경우에 있어서 필수적인 것은, 유용 데이터가 다중 방식으로, 예를 들면 다양한 시간에서 적합한 다른 네트워크 프로토콜의 기존 네트워크를 통해 송신될 수 있고, 그래서 각 수신기가 수신기에 의해 지원되는 네트워크프로토콜에 적합한 데이터를 수신할 수 있다는 사실이다. 동일한 유용 데이터를 상기와 같이 다중 방식으로 송신할 때의 단점은, 네트워크에 필요한 송신 주파수대의 폭이 크다는 점이다. 더욱이 이와 같은 사실은 자유롭게 쓸 수 있는 송신 주파수대의 폭을 초과하기 때문에 유용 데이터를 모든 수신기에 동시 송신하는 것이 불가능할 수도 있다.

원칙적으로 이미 공지된 바 있는 또 다른 하나의 가능성은, 적합한 수신기에 네트워크 변환기가 직렬 접속할 수 있고, 네트워크 변환을 통해 수신기에 의해 지원되지 않는 네트워크 프로토콜이, 미리 주어진 정해진 규약에 따라 수신기에 의해 지원되는 네트워크 프로토콜로 전환된다는 사실이다. 적합한 변환 시스템이 WO 98 20647에 공지된 바 있다. 네트워크 프로토콜간 차이를 전제한다면, 각 수신기에 의해 수신된 데이터 스트림을 완전히 콘트롤하는 것 또는, 송신기를 통해 소속된 네트워크 프로토콜을 완전히 활용할 수 있는 가능성이 통상적으로 희박하다. 따라서 만일 정해진 네트워크 프로토콜에서 이미 송신된 데이터가 송신기에 자체적으로 존재한다면, 중간에 있는 네트워크에서 또 다른 네트워크 프로토콜이 사용되어질 경우, 상기 네트워크 프로토콜을 사용하는 수신기가 변함 없이 데이터를 가지는 가에 대해서는 보증될 수 없다.

본 발명의 과제는 앞서 기술된 단점에 상관없이, 주파수 대역폭에 효율적인 송신기가, 네트워크를 통해 상이한 네트워크 프로토콜을 지원하는 서로 다른 수신기에 데이터 스트림을 송신할 수 있는 방법을 보여주는 것이다.

상기 과제는 특허 청구항 제 1항에서 기술된 특징을 가지는 하나의 시스템(System)에 의해 해결된다. 본 발명의 계속되는 구성과 형태는 종속항 제 2항 내지 12항에서 진술된다. 청구항 제 13항 내지 20항의 목적은 콘트롤 데이터와 유용 데이터를 가지는 데이터 스트림을 발생시키기 위한 하나의 송신기에 관한 것이다. 청구항 21항 내지 27항은 콘트롤 데이터와 유용 데이터를 가지는 데이터 스트림을 수신하기 위하여 실제 수신기에 직렬 접속할 수 있는 기기 내지는 상기에 삽입 가능한 하나의 처리 유닛(Unit)에 관한 것이다.

본 발명의 장점은 동일한 유용 데이터를 다중으로 송신할 필요가 없다는 것이다. 유용 데이터는 단 한 개의 네트워크 프로토콜에 따라서 송신된다. 이러한 네트워크 프로토콜을 지원하지 않는 모든 수신기들에 각각, 상기 네트워크 프로토콜에 따라서 송신되는 유용 데이터를 사용하여, 각 수신기의 네트워크 프로토콜에 적절한 데이터 스트림을 만드는 하나의 변환 유닛이 배열된다. 언급된 변환 유닛은 각 수신기에 직렬 접속되거나 삽입된다.

본 발명의 추가 장점은, 필요한 경우, 모든 지원되는 네트워크 프로토콜에 대해 완전한 투명성이 유지된다는 것이다. 게다가 실제 유용 데이터에 적합한 송신에 사용된 네트워크 프로토콜에 추가로, 경우에 따라서 각 네트워크 프로토콜로 전환되기 위하여, 수신기가 필요한 추가 데이터를 함께 송신할 것이다.

상기 추가 데이터의 경우에, 변환 유닛에서 각각의 수신기를 위한 데이터 스트림을 만들어 낼 때 이용될 수 있는 변환 프로그램 내지 변환 프로그램의 일부에 적합한 데이터, 즉 변환 소프트웨어가 문제될 수 있다. 상기 사실 때문에 각 네트워크 프로토콜의 차후 확장을 고려하여 또는 새로운 네트워크 프로토콜을 고려하여 시스템이 역시 간단한 방식으로 확장될 수 있다.

제 2 네트워크 프로토콜을 지원하는 수신기는 본 발명의 장점을 지닌 형태에 따라서 보조 네트워크를 통해 하나의 공동 변환 유닛에 연결될 수 있고, 변환 유닛은 다시 주 네트워크에 연결되어 제 1 네트워크 프로토콜에 따라 주 네트워크를 통해 송신된 데이터 스트림을 제 2 네트워크 프로토콜에 따른 데이터 스트림으로 변환한다.

청구항 제 9항의 주제가 되는 테스트 유닛이 사용된다면, 보다 더 적은 송신 주파수 대역폭을 요하는 데이터 스트림이 언제나 송신되도록 보장할 수 있다.

청구항 제 11항의 주제가 되는 테스트 유닛이 사용된다면, 단지 이러한 종류의 추가 데이터 내지 변환 규약에 적합한, 수신측에서 실제로도 처리되어질 수 있는 데이터가 송신되어지는 것이 보증된다. 이를 통해 이미 기존 수신기와의 광범위한 호환성이 성취될 수 있다.

더 나아가 본 발명의 장점을 지닌 특성이 도면에 근거하여 이하에서 다음과 같이 설명된다.

제 1도는 본 발명에 따르는 시스템의 블록 회로도를,

제 2도는 1394-네트워크로의 동시성 송신을 구체적으로 설명하기 위한

스케치를,

제 3도는 1394ARP-프로토콜의 확장을,

제 4도는 GASP-포맷(Format)을,

제 5도는 "인캡슐레이션 헤더(Encapsulation header)"를,

제 6도는 또 다른 "인캡슐레이션 헤더(Encapsulation header)"를,

제 7도는 IGMP-조회를,

제 8도는 MCAP-포맷(Format)을,

제 9도는 제 8도에 따라 "인다이렉트(indirect)-채널(channel)-

리스트(list)"의 엔트리 포맷(Entry format)을,

제 10도는 "인다이렉트(indirect)-채널(channel)-리스트(list)"에

여러 가지 등록을 위한 포맷(Format)을,

제 11도는 Ipv4-헤더(Header)를,

제 12도는 길이정보를 가지는 아이피-헤더-옵션(IP-Header-Option)을,

제 13도는 구성조회/구성정보의 헤더(Header) 구성을,

제 14도는 구성조회/-정보의 개별 요소를 도시한다.

<도면의 주요부분에 대한 부호의 설명>

1: 네트워크(Network) 2: 보조 네트워크(Network)

3: 송신기

3a: 제 1 네트워크 프로토콜에 적합한 데이터 스트림을 발생시키기

위한 수단

3b: 상응하는 데이터의 변환 규약을 산출하기 위한 수단

3c: 테스트 유닛

4: 네트워크프로토콜을 지원하는 제 1 수신기

5: 네트워크프로토콜을 지원하는 제 2 수신기

6: 변환 유닛 7: 변환 유닛

8: 네트워크프로토콜을 지원하는 제 2 수신기

9: 네트워크프로토콜을 지원하는 제 2 수신기

10: 네트워크프로토콜을 지원하는 제 3 수신기

제 1도는 콘트롤 데이터와 유용 데이터를 가지고 있는 데이터 스트림을 송신하기 위한 시스템의 블록 회로도이다. 예를 들어 송신 가능한 데이터 스트림에서 중요한 문제는 MPEG2-전송 스트림이다. MPEG2-전송 스트림은, IEC 61883-1에 의거 IEC 61883-4와 결합하여 1394-네트워크를 통해 혹은 RTP를 사용하여 IP-네트워크 중 하나를 통해 송신되어야만 한다. 상기 데이터 스트림에서 송신 가능한 오디오/비디오-유용 데이터가 연속된 데이터 패키지의 형태로 제공된다. 데이터 패키지에는 네트워크 프로토콜 특유의 추가 데이터들이 각 헤더로 송신되는 헤더가 각각 설치된다. 이와 같은 추가 데이터들은 예를 들자면 송/수신기 지시, 시간표 및 테스트의 조합일 수 있다. 이러한 추가 데이터의 범위는 일반적으로 오디오/비디오-유용 데이터의 범위와 비교하여볼 때 작다. 개별 데이터 패키지에 오디오/비디오-유용 데이터를 배분하는 것은 사용된 네트워크 프로토콜에 따라 다를 수 있다. 예를 들어 전형적으로 MPEG2-전송 스트림을 송신할 때 IEEE 1394-1995-표준을 따르는 더 많은 패키지에 적합한 오디오/비디오 데이터가 인터넷-프로토콜-표준을 따르는 단 한 개의 패키지에 설치된다.

제 1도에서 도시된 시스템에서 MPEG2-전송 스트림이 1394-네트워크(1)를 통해 다른 수신기들에 동시에 송신되어져야만 하는 것을 하기에서 알 수 있고, 수신기는 서로 다른 네트워크 프로토콜을 지원한다.

네트워크(1)를 통해 송신 가능한 데이터 스트림은 콘트롤 데이터와 오디오/비디오-유용데이터를 가지고 있으며, 송신기(3)에 의해 자유로이 사용된다. 상기 송신기(3)는, IEEE Std 1394-1995 및 IEEE Std 1394a-2000과 결합하여 표준 IEC 61883-1 및 IEC 61883-4에 의해 제한될 것인 제 1 네트워크 프로토콜에 적합한 데이터 스트림을 발생시키기 위한 수단(3a)을 가진다. 송신기(3)에 의해 발생된 데이터 스트림은 네트워크(1)를 통해 많은 수신기에 송신된다.

제 1 수신기(4)는 IEEE Std 1394-1995 및 IEEE Std 1394a-2000과 결합하여 표준 IEC 61883-1 및 IEC 61883-4에 의해 규정된 제 1 네트워크 프로토콜을 지원한다. 따라서 수신기(4)에 수신된 데이터 스트림은, 예를 들면 요구된 텔레비전 방송 프로그램에 적합한 오디오/비디오데이터의 선택 및 암호해독의 의미로 곧 평가되어 질 수 있다. 수신기(4)는 텔레비전 수상기일 수 있고, 그 디스플레이에서는 텔레비전 방송 프로그램에 적합한 이미지 신호가 상영된다.

제 2 수신기(5)는 표준 IEC 61883-1 및 IEC 61883-4를 지원하는 것이 아니라, 단지 제 2 네트워크 프로토콜, 예를 들면 인터넷-프로토콜-표준뿐만 아니라, FRC 2038과 결합하여, 특히 예를 들면 RFC 1889에 의거 그에 기초한 실-시간 수송 프로토콜(RTP)을 지원한다: MPEG1/MPEG2 비디오용 RTP 페이로드(Payload) 포맷(Format). 상기 수신기에서 IEC 61883-4와 결합한 표준 IEC 61883-1에 의거하여 송신된 신호의 평가를 가능하도록 하기 위하여, 제 2 수신기(5)는 통합된 변환 유닛(6)을 가진다. 상기는 게다가 IEC 61883-4와 결합한 표준 IEC 61883-1에 의거하여 또는 제 1 네트워크 프로토콜에 송신된 신호가 인터넷-프로토콜-표준 내지 제 2 네트워크 프로토콜에 적합한 데이터로 전환될 수 있는 것을 제공한다. 제 2 네트워크 프로토콜에 적합한 이러한 데이터는 제 2 수신기(5)에서, 요구된 텔레비전 방송 프로그램에 적합한 오디오/비디오데이터의 선택 및 암호해독의 의미로 곧 평가되어 질 수 있다.

수신기(5)는 퍼스널 컴퓨터(Personalcomputer)일 수 있고, 그 디스플레이에서는 텔레비전 방송 프로그램에 적합한 이미지 신호가 상영된다.

제 1도에 도시된 수신기(8,9)는 마찬가지로 제 2 네트워크 프로토콜을 지원하는 수신기이다. 상기 수신기(8,9)는 보조 네트워크(2)에 연결되어있다. 보조 네트워크(2)는 변환 유닛(7)을 통해 주 네트워크(1)와 연결된다. 게다가 표준 IEC 61883-1 뿐만 아니라 IEC 61883-4와 결합한 IEEE-1394-표준에 의거 주 네트워크(1)를 통해 제 1 네트워크 프로토콜에 적합한 데이터 스트림을 제 2 네트워크 프로토콜에 적합한 데이터 스트림으로 전환할 수 있는 변환 유닛(7)이 제공된다. 제 2 네트워크 프로토콜에 적합한 상기 데이터 스트림은 보조 네트워크(2)에 전달되고 보조 네트워크를 통해 수신기(8,9)에 송신된다.

제 1도에 제시된 실시형태의 대안으로, 수신기(8,9)는 각각 자신만의 외부 변환 유닛을 통해, 공동의 보조 유닛을 사용하지 않고도 주 네트워크(1)와 연결될 수 있는 것이 가능하다.

마찬가지로 변환 유닛(7)이 형성되어서, 단지 제 3 네트워크 프로토콜만을 지원하는 수신기(10)가 추가로 공동의 또는 분리된 보조 네트워크(2)를 통해 상기 변환 유닛(7)과 연결되어 질 수 있는 것이 가능하다. 상기 변환 유닛(7)은 이제, 필요한 경우에 한하여, 또 다른 추가 데이터를 수신하고, 변환 유닛은 데이터를 만들기 위하여 상기 제 3 네트워크 프로토콜에 적합한 추가 데이터를 필요로 하고 따라서 상기 데이터를 만들고 적합한 보조 네트워크(2)를 통해 수신기(10)에 발송한다.

변환 유닛(6,7)은 각 변환 프로세스를 위한 변환 규약을 필요로 한다. 상기 변환 규약은 변환 프로그램의 형태로 및/또는 네트워크 프로토콜에 따라 달라지는 추가 데이터의 형태로 제공되고, 각 변환 유닛에서 저장될 수 있다. 이에 선택적으로 언급된 변환 규약은 그러나 송신된 데이터 스트림에서 송신기에 의해 수신기로 적어도 부분적으로 송신되고, 이때 마지막 실시형태가 우선적이다.

상기 목적을 위하여 송신기(3)는 변환 규약에 관한 데이터(즉, 추가 데이터)를 송신 가능한 데이터 스트림으로 산출 및 삽입시키기 위한 수단(3b)을 가진다. 변환 규약에 관한 데이터는 데이터 스트림 내에서 수신측으로 송신되고, 각 수신기 내지 각 변환 유닛에서, 경우에 따라서 대체로 변환 프로세스를 위해 필요한 송신된 데이터 스트림으로부터 분리되고 각 변환 프로세스를 위한 변환 유닛에 의해 사용된다.

변환 규약에 관한 데이터를 네트워크를 통해 송신기에서 수신기로 송신하는 것은, 시스템이 상존하는 네트워크 프로토콜의 확장을 고려하여 또는 새로운 네트워크 프로토콜을 고려하여 간단한 방식으로 적합하게 될 수 있는 장점을 가진다.

이를 위해 대안으로 추가 데이터를 송신기에서 수신기로 전부 혹은 부분적으로 송신하는 것은, 또한 한 개 혹은 그 이상의 논리적 또는 물리적으로 분리된 추가의 네트워크를 통해 이루어질 수 있다. 상기의 경우 수단(3b)은 변환 규약에 적합한 데이터를 송신될 데이터 스트림으로 직접 삽입하는 것이 아니라 단지 논리적 또는 물리적으로 분리된 네트워크를 통해 수신측의 변환 유닛에 직접 전달한다. 예를 들면 수신측의 네트워크 프로토콜을 따르는 추가 데이터가 이미 송신측의 수단(3b)에 의해 분리(또는 분배)될 수 있다. 수신기 측의 변환 유닛은, 변환 프로세스에 필요한 추가 데이터가 그 수신기의 네트워크 프로토콜로 송신되는 것을 통해 그와 같은 추가 네트워크와 연결되고, 추가 데이터가 부가된다.

주파수 대역폭에 대해 효과적인 송신을 보증하기 위하여, 송신기(3)는 본 발명의 계속되는 실시예에 따라 하나의 테스트 유닛(3c)을 가진다. 변환 규약을 가지는 데이터 스트림을 네트워크(1)를 통하여 송신하는 것이 유용 데이터가 다중의, 예를 들면 하나 이상의 상이한 네트워크 프로토콜에 따라 타임 멀티 플렉스에 포함되는, 데이터 스트림을 송신하는 것보다 더 큰 송신용량을 필요로 하는 지에 대한 것에 대한 테스트가 이루어진다. 유용 데이터가 다중의, 예를 들면 하나 이상의 상이한 네트워크 프로토콜에 따라 타임 멀티 플렉스에 포함되는 데이터 스트림 보다, 더 적은 송신용량을 요하는 변환 규약을 가지는 데이터 스트림을 인식한다면, 그러면 송신기(3)는 변환 규약을 가지는 데이터 스트림을 네트워크(1)로 전송한다. 그에 반해 변환 규약을 가지는 데이터 스트림의 유용 데이터가 다중의, 예를 들면 하나 이상의 상이한 네트워크 프로토콜에 따라 타임 멀티 플렉스에 포함되는, 데이터 스트림 보다 더 큰 송신용량을 필요로 한다는 것을 인식한다면, 그러면 송신기(3)는 변환 규약을 가지는 데이터 스트림의 유용 데이터보다는, 다중의, 예를 들면 하나 이상의 상이한 네트워크 프로토콜에 따라 타임 멀티 플렉스에 포함되는, 데이터 스트림을 네트워크(1)로 전송한다.

앞서 기술된 테스트는 단 한 개의 데이터 패키지를 위하여, 데이터 패키지 그룹을 위하여 혹은 전제 유용 데이터 스트림을 위하여 실행 가능하다.

본 발명의 또 다른 계속되는 실시예에 따라서, 네트워크 프로토콜, 내지 네트워크(1)에 연결되어 하나의 정해진 유용 데이터 스트림을 수신하는 수신기들에 의해 변환 규약이 어느 정도 지원되는 가를 송신기(3)에 포함된 테스트 유닛(3c)이 테스트할 것이다. 상기는 송신기가, 네트워크(1)에 연결되어 각각 유용 데이터 스트림을 수신해야만 하는 모든 수신기들도 역시 해석할 수 있는 추가 데이터 내지 변환 규약만을 송신 가능한 데이터 스트림에 첨가할 수 있도록 해 준다. 필요한 경우에 한하여는, 상기 테스트 유닛이 수신기에 의해 지원되는 상이한 네트워크 프로토콜에 따라, 예를 들면 타임 멀티 플렉스에서, 유용 데이터 스트림을 다중 송신하도록 전환한다. 이를 통해 이미 존재하는 수신기들과도 호환될 수 있다.

앞서 기술된 테스트는 예를 들면 송신기(3)가 네트워크(1)를 통해 네트워크(1)에 연결된 수신기들에게로 조회신호를 송출하고 그 때마다 수신기가 네트워크(1)를 통해 각 수신기에 의해 지원 받는 네트워크 프로토콜에 대한 정보를 가지고 있는 데이터를 송신기(3)에게로 재 송출하는 것을 통해 가능해진다.

하기에서 IEEE-1394-네트워크를 사용할 때 본 발명의 더 나아가 세부사항이 기술되고, 예를 들면 IEEE Standard 1394-1995에: IEEE Std 1394a-2000과 결합된 "Standard for a High Performance Serial Bus" 뿐만 아니라 IEC 61883: "Consumer Audio/Video Equipment-Digital Interface-" 그리고 IEEE P 1394.1에: "Draft Standard for High Performance Serial Bus Bridges" 공개된 바 있다.

1394-네트워크를 사용하여 데이터 스트림을 송신하는 유형 및 방식은 제 2도에서 도시된다. 소위 "Cycle Master"에 의해 규약에 맞게 송출된 "Cycle Start"-패키지에 의해 각각 대략 125㎲의 시간 간격으로 타임백(Timebag)이 분할된다. 이른바 동시 송신을 시작하기에 앞서 우선 데이터 스트림에 채널 넘버(Channelnumber)가 배열되어지고 이러한 싸이클(Cycle) 내부에서 일정한, 최대 시간 할당이 예약되어 진다. 각 싸이클(Cycle)-스타트(Start)-패키지(Package)를 수신하고 나면 이제 기계들에 배열된 동시 채널 각각을 위하여 개별 기계들이 각각 최대 데이터 패키지를 송출하고, 이때 한편으로는 미리 주어진 평균 비트(Bit) 비율에서 그리고 다른 한편으로는 사용 특유의 허용된 유용 데이터 패키지의 크기에서 전제 예약 송신 시간은 흔히 각 싸이클 내에서 다 이용되지는 않는다. 나머지는 여분의, 예약되지 않은 송신 시간과 함께 소위 비동시 채널로의 데이터 송신뿐만 아니라 콘트롤 정보의 교환을 위해 자유로이 사용된다. 더구나 각 기계가 각각의 싸이클 내에 송신 시간을 가지는 것을 보증 받지 못하지만, 그러나 다른 한편으로는, 충분한 송신 시간을 전제로, 자신의 싸이클에서 동일한 채널 넘버를 가지는 그 이상의 데이터 패키지가 송출되어질 수 있다.

제 2도에서는 IK0 동시 채널 0, IK1 동시 채널 1, IK2 동시 채널 2, CSP 싸이클(Cycle)-스타트(Start)-패키지(Package), GB 이용된 주파수대의 폭, UG 이용되지 않은, 그러나 예약된 주파수대의 폭 그리고 IB 동시 송신을 위해 이용된/예약된 주파수대의 폭이 표기된다.

제 1도의 수신기(4)에 적합한 기계에 필요한 유용 데이터 스트림의 송신을 위해 전형적으로 동시성, 경우에 따라서는 비동시성 1394-채널이 지정된다. 변환 프로그램은 적절하게 동시 또는 비동시에 송신되어질 수도 있다. 변환 프로그램을 송신 및 해석할 때 상이한 가능한 변형은 송신된 추가 데이터 내지 구성명령에 의해 선택되어질 수 있다.

유용 데이터 스트림와 변환 프로그램을 동시에 송신할 때 변환 프로그램도 역시 동시에 송신하도록 제공된다. 유용 데이터 패키지를 변환 프로그램 패키지 각각에 배열하는 것은 동시 싸이클에 따라서 이루어지고, 동시 싸이클에서 송신이 이루어진다. 상기 배열은 역시 1394,1-동일한(conformable) 브릿지(Bridge)에 의해 유지 보존된다는 것에 주목할 것이다. 실제 싸이클에서 송신된 동시 데이터를 넘어서, 그 안에서 이전의 동시 싸이클의 데이터가 중간 저장되어지는 추가의 기억장치가 제공되고, 그래서 변환 프로그램을 통해 보고될 수 있다. 특히 모든 필요한 동시 채널을 위해 정해진 크기를 가지는 FIFO-기억장치가 제공될 수 있다. 개별 유용 데이터 패키지는 예를 들면 하기에 따라서 보고될 수 있다.

a) 동시 싸이클의 채널 넘버 및 간격,

b) 채널 넘버 및 패키지를 송출할 때 최소한

CYCLE-TIME-레지스터(Register)의 최고 20 비트(Bit)의 일 부분(1394

네트에서 각 동시 채널의 지연이 결합의 이니시에이터(Initiator)에

잘 알려져 있기 때문에, 수신기가 이니시에이터(Initiator)와 동일한

경우에, 수신기 측의 수신기 버스(Bus)에 대한

CYCLE-TIME-레지스터(Register)의 값이 정해질 수 있거나 혹은 이러한

것에 의해 상기 값이 수신기에 전달되어지는 것에 주목할 것이다),

c) 특히 IEC-81883-동일 동시 데이터 스트림(경우에 따라서 채널 넘버에

추가하여)를 사용할 때 CIP-헤더의 적절한 필드(Field)에 따라서(특히

DBC, 경우에 따라서 SID 및 FMT와 결합하여),

d) 그렇지 않으면(경유에 따라서 채널 넘버에 추가하여) (유용-) 데이터

패키지의 특수 포맷된 그 밖의 부분에 따라서.

자칫 다의성은 FIFO-기억장치의 내부에서(마지막에 수신된 패키지의 선택) 패키지의 포지션(Position) 내지 오래된 햇수에 따라서 해소될 수 있다.

만일 변환 프로그램을 위한 추가의 기억장치를 역시 제공한다면(특히 예를 들자면 변환 프로그램을 위해 사용된 동시 채널 당 정해진 크기; 상기 크기는 이러한 채널을 위한 유용 데이터 퍼퍼(Puffer)와 역시 동일할 수 있다), 변환 프로그램을 송신할 때 상기 정해진 크기는 그 이상의 동시 싸이클에 할당될 수 있다. 이를 통해 특히 저 유용 데이터 비율에서 변환 프로그램을 위해 예약 가능한 주파수대의 폭이 감소되어질 수 있다. 추가로 변환 프로그램 부분을 완수했을 때, 산출 가능한 데이터 패키지가 그 이상의 변환 프로그램 패키지에 의해 표현되어지는 한, 최소한 그 완벽함이 보장될 수 있다. 게다가 특히 변환 프로그램 패키지가 싸이클을 이루어 번호를 부여받게 되고(예를 들어 CIP-포맷을 사용할 때 DBC-필드(Field)에 의하여) 변환 프로그램 패키지가 중지될 때 실제(불완전한) 패키지가 활용될 뿐만 아니라 적합한 동기점(Synchronous point)이 나타날 때까지 변환 프로그램 부분이 실행되지 않는다.

언제나 유용 데이터는 변환 프로그램에 적합한 예약된 주파수대의 폭으로 송신되어 질 수 있기 때문에 그리고 알려진 퍼퍼(Puffer) 용량에 직면하여 수신기에서 암호 해독이 가능한 지 아닌지를 송신기가 먼저 산출할 수 있기 때문에, 버스(Bus)-리셋(Reset)과 같은 특수한 케이스를 제외하고, 어떠한 패키지 손실도 기다릴 수 없다.

상기의 그리고 경우에 따라서 다른 가능성들 간의 차이가 특수하게 실행될 때 모든 사용된 변환 유닛을 위해 일치하여 결정되어지지 않는 한, 적합한 구성명령을 통해 그 때마다 사용된 변형이 변환 유닛에 전해지거나 내지는 송신기와 수신기 측의 변환 유닛 사이에서 교섭하여 결말지어질 수 있다.

선택적으로 변환 유닛에서 기억장치 수요를 감소시키기 위하여 구성명령을 통해 전달되어질 수 있거나 혹은 송신기와 수신기 측의 변환 유닛 사이에서, 어떤 채널을 통해 데이터 패키지 및/또는 변환 프로그램이 전달되는 지 그리고 어떤 범위 내에서(예를 들어 전체 크기, 패키지 수, 싸이클 수, 또는 상응하는 콤비네이션(Combination)에 따라서) 변환 프로그램 패키지 및/또는 데이터 패키지가 적절한 채널에서 다음의 변환 프로그램을 위해 중간 저장될 수 있는 지를 교섭하여 결말지어질 수 있다.

정확한 송신에 좌우되어 변환 프로그램이 특히 실제 프로그램 부분 및 경우에 따라서 다음의 데이터 부분으로 이루어질 수 있다. 각각의 변환 프로그램 부분을 위하여 그 외에도 cycle_count-레지스터(Register)의 20 비트(Bit) 이상의 값이 상기 프로그램 부분을 완전히 수신하는 시점에 알려질 것이다.

가능한 명령 문구:

NOP

상기 명령은 아무런 영향을 미치지 않으며 특별히 다음의 명령을 경우에

따라서는 어휘 제한에 적합하게 전달하는 데 사용된다.

ADD add

상기 명령은 바로 다음의 CPY-, CPYIM- 내지 SKIP-명령의 길이를

"증가(add)" 아크테트(Octet)로 올린다.

GEN start len mask value

상기 명령을 통해 유용 데이터 패키지를 선택하기 위한 추가의 비교 샘플이

정해진다. "start"는 시작을 표기하고, "len"은 "mask" 및 "value"에 의해

기술되는 비교 샘플의 아크테트(Octet)로의 길이를 표기한다.

SKIP s.

여전히 발생하지 않는 한, 이전 GEN, DBC, CIP, CYC, CHAN-명령에 의해

분석된 유용 데이터 패키지 및, 4s 뿐만 아니라 경우에 따라서는 마지막

CPY 또는 SKIP 이후 실행된 ADD-명령에 의해 세분된 다수의

아크테트(Octet)를 선택한다.

DBC y

상기 명령은 그 DBC-필드가 "v"와 일치하는 CIP-패키지를 선별한다.

CIP sid fmt dbc

상기 명령은, 필드(Field) SID, FMT 및 DBC에 대해서 "sid", "fmt" 및

"dbc"에 의해 선별된 비교 샘플과 일치하는 CIP-패키지를 선별하고, 경우에

따라서는 "외일드카드(Wildcards)"가 사용되어질 수 있다.

CYC c

상기 명령은 동시 싸이클에 기초하여, 파라미터 "c"에 의해 선별되는 바와

같이 발송되어지는 동시 패키지를 선별한다. 동시에 이전의 모든 GEN=,

DBC-, 및 CIP-명령의 작용이 해제된다.

CHAN c

상기 명령은 채널 번호 "c"를 가지는 패키지를 선별한다. 동시에 이전의

모든 GEN=, DBC-, 및 CIP-명령의 작용이 해제된다. 1394.1-네트워크에서

"c"는 이치에 맞게 한 개의 채널을 직접 표기하는 것이 아니라, 오히려 예를

들면 송신기의 "output-Plug"-레지스터를 표기한다. 상기 값은 우선 지역적

1394-버스에 속하는 채널 번호에 의해 대체될 수 있다(이전의 구성명령에

의해 실행된 결합 구조에 기초하여 공지됨).

CPY s

바로 다음의 4s , 뿐만 아니라 추가로 경우에 따라서는 마지막 SKIP, CPY-

혹은 CPYIM-명령 이후에 점검된 ADD-명령에 의해 세분된 다수의

아크테트(Octet)를 맨 마지막에 선택된 패키지에서 실제 형성된 패키지에

부가한다.

STOP

변환 프로그램을 끝내고 경우에 따라서는 마지막에 형성된 데이터 패키지를

송신하다(변환 프로그램 패키지에서 단지 데이터만이 발생함).

CPYIM s

변환 프로그램에서 뒤이은 4s 뿐만 아니라 추가로 경우에 따라서는 마지막

SKIP, CPY- 혹은 CPYIM-명령 이후에 점검된 ADD-명령에 의해 세분된 다수의

아크테트(Octet)를 맨 마지막에 선택된 패키지에서 실제 형성된 패키지에

부가한다.

결국 유용 데이터 스트림에 의해 채널 당 예약된 송신 시간이 충분하게 자주 완전히 이용되지 않는 한, 대개 IEEE 1394/IEC 61883-명세서와는 다르게, 경우에 따라서는 변환 프로그램 채널을 위한 추가의 주파수대의 폭의 예약을 포기할 수 있거나 적어도 감소될 수 있다는 것을 제시될 것이기 때문에, 따라서 동시성 채널을 위하여 전체 예약된 시간 할당을 초과하지 않고서, 적절한 동시성 싸이클에서 변환 프로그램 채널에 의해 요구된 송신 시간 할당이 역으로 소속된 예약을 적절하게 초과할 수 있다.

유용 데이터 스트림 또는 변환 프로그램을 비 동시에 송신할 때, 수신기 측에서 비 동시성 패키지에서 CYCLE-TIME-레지스터(Register)에 속한 값이 발송될 때 알려지는 한, 비 동시성 유용 데이터 스트림을 위해 표기된 로드(Road)가 뒤따르게 된다. 물론 상기는, 특히 1394.1-브릿지(Bridge)를 넘어서서, 일반적인 경우가 아니다. 단 한 개의 개별 유용 데이터 패키지를 동일화하기 위하여 일반적으로 채널 번호와 더불어, 뿐만 아니라 발송 지시의 GASP-패키지에서(source_id-Field), 이전 단락의 c)와 d)에 기술된 가능성만이 자유로이 사용된다. 유용 데이터- 내지 변환 프로그램 스트림의 충돌(bumper)과 관련하여 동시성의 경우와 마찬가지로 동일한 가능성들이 발생한다면, 물론 미리 주어진 범퍼 크기에서 변환이 이론상 가능한 시점에 유용- 내지 변환 프로그램 패키지가 수신기에 더 이상 존재하지 않는 다는 것이 고려되어야만 한다. 상기는 높은 네트 하중에서 일반적으로, 품질이 보장되지 않는 결합에서 패키지 손실에 상응한다.

하기에서 변환 프로그램의 명령 문구가 모범적으로 표기된다.

CONTIUNUE

실제 형성된 데이터 패키지를 종료하지 않고, 바로 다음의 변환 프로그램

패키지를 가지는 변환 프로그램을 계속 실행한다.

CPYIMN s

CPYIM과 같이, 그러나 형성된 데이터 패키지를 추가로 송신한다.

IP-패키지 송신을 이용할 때 더 나아가 본 발명이 가지는 세부사항이 하기에서 기술된다.

직렬 접속된 변환 유닛을 가지거나 혹은 가지지 않는 IPover1394-기기간 차이에 다음의 메카니즘(Mechanism)이 사용될 수 있다.

- 1394ARP-프로토콜의 확장(제 3도 참조):

변환 유닛은 지금까지의 ARP-Response(opcode=2)에 추가해 다른 Opcode를

가지는, 특히 예를 들면 opcode=3을 가지는 ARP-패키지를 ARP-Request

(opcode=1)에 발송한다. 동시에 경우에 따라서는

sender_unicast_FIFO_hi/lo에 변환 프로그램 패키지를 위한 FIFO-Adress가

발송된다.

- ROM 구성:

지금까지의 unit_spec_ID=0x00005E 및 unit_sw_version=0x000001 등록에

추가해 unic_spec_ID 및 unit_sw_version으로 이루어진, 예를 들면 특히

unit_spec_ID=0x00005E 및 unit_sw_version=0x000002로 이루어진 또 다른

조합의 등록이 작성된다.

송신기들은 경우에 따라서 마찬가지로 변환 프로그램 패키지를 송신할 수 있는 지를 상기 두 가지의 가능성 중 하나에 의해 제시한다.

변환 프로그램을 송신할 때, 변환 프로그램이 비 동시성 또는 동시성 채널에 의해 송신되어지는 한, GASP-포맷은 P. Johansson에 의해 기술된: IPv4 over IEEE 1394, 1999. 12(RFC 2734)을 사용한다(제 4도 참조). ****실제 변환프로그램은 경우에 따라서 제 5도에 따르는 "인캡슐레이션 헤더(encapsulation header)" 뒤에 내지는 "lf"가 0가 상이할 경우 제 6도에 따르는 "data"-영역의 처음에 존재한다. 특수한 실행에서 상기 GASP-패키지의 "인캡슐레이션 헤더(encapsulation header)"가 사용된다면, 일반적인 IPover1394-패키지와 변환프로그램 패키지의 식별은 지금까지 예약된 "t"-bit(t=0: IPover1394-패키지, t=1 변환프로그램 패키지)에 의해 혹은 단 한 개의 "ehter_type"에 의해 이루어질 수 있다. 식별을 위한 다른 경우는 GASP-패키지의 "version"-필드(Field )가, 예를 들면 IPover1394-패키지를 위한 "version=1"과 변환 프로그램 패키지를 위한 "version=2"가 사용될 수 있다.

동시성 송신의 경우 대안으로 특별히 한정될 수 있는 CIP-FMT가 사용되어질 수 있다. 상응하는 헤더(Header)를 위한 오버헤드(Overhead)가 이제 더 작을 수 있기 때문에, 상기를 통해 저 주파수대의 폭 수요가 발생한다. 동시성 채널이 많은 송신기에 의해 동시에 이용되지 않기 때문에, GASP-헤더(Header)는 이제 불필요할 것이다.

실행에서 변환 프로그램이 1394-block-write에 의해 전달되어지는 한, 변환 프로그램은 ARP-Answer에 소속된 FIFO-Address에로 조절된다. 만일 상기 변환 프로그램이 특수한 실행에서 이란적인 IPover1394-패키지의 것과 식별된다면, 변환 프로그램을 위하여 "인캡슐레이션 헤더(encapsulation header)"의 송신이 포기될 수 있다. 다른 경우 두 패키지 타입(type)간 식별은 그것의 "t"-bit 또는 "ehter_type"에 의해 다시 이루어진다.

다음에서 송신에 관여하는 수신기의 산출이 기술된다.

IP-Unicast의 경우에서만 단지, 상기에서 기술된 바와 같이, 각각 다음의 수신기에 변환 유닛이 부가되는 지가 테스트될 수 있다.

IP-Broadcast의 상황이 유사하게 설명된다. 모든 IPover1394-성능 좋은 기긱에 상기 테스트가 적용될 수 있다.

상기 프로세스가 역시 멀티 캐스트(Multicast)에서도 사용되어질 수 있다는 것은, 물론 자주 불필요하게 한정된다. 정확히 구별되어질 수 있는 바와 같이, 하기에서 각 실제 수신기에 변환 유닛이 직렬 접속되는 지에 대한 가능성들이 논의되어야한다.

- IP-루터(Router)-기능이 없는 수신기:

변환 유닛이 부가되지 않은 수신기를 조사하기 위하여 IGMP-프로토몰이

사용될 수 있다. 송신기 S는 자발적으로 제 7도에 따르는 IGMP-조회를

각각의 멀티캐스트(Multicast)-어드레스(Address)에 전달하고, 그 후에

송신기는 다른 방식으로, 예를 들면 알맞은 구성 패키지를 통해서, IGMP-

패키지가 전송될 수 없다는 것을 모든 변환 유닛에게 먼저 알린다.

따라서 변환 유닛을 가지지 않는 멀티캐스트(Multicast)-수신기만이

응답을 받는다. 응답이 생기지 일어나지 않는다면, 변환 유닛을 가지지

않는 어떤 수신기도 당장 멀티캐스트어드레스(Multicastaddress)에서

활동하지 않는다.

IGMPv2를 사용하여 추가로 가능한 한 짧은 응답 시간 "Max Resp Time"이

주어진다. 특수한 실행에서도 역시 변환 프로그램 패키지의 사용을

지원하고 이러한 사용이 널리 알려진 송신기에 의해 특수한 최대 응답

시간, 예를 들면 "Max Resp Time"=1을 가지는 IGMP-응답이 단지 변환

유닛을 가지지 않는 수신기를 조사하기 위해서 사용된다는 것이 역시

결정될 수 있다. 상기의 경우에 다음과 같은 IGMP-조회를 통해 변환

유닛을 별도로 보고하는 것이 포기될 수 있다.

IGMPv3을 사용하여 각 수신기가 IGMP-조회에 대해 응답해야만하고, 따라서

브로드캐스트(Broadcast)-패키지와 유사한 적절한 조회에 따라서 방식을

취할 수 있는 것이 결정된다. IGMPv3에 관하여 특히 Cain에서 언급된다:

Internet Group Management Protocol, Version 3, 2001.3.(Internet

Draft: draft-ietf-idmr-igmp -v3-07).

각 수신기가 참가에 앞서 불필요하게 멀티캐스트(Multicast)-

어드레스(Address)에 발송하는 IGMP-보고의 감독에 의해,

멀티캐스트(Multicast)-어드레스(Address)에 새로운 수신기가 가입되는

지가 확인될 수 있다. 상기 수신기를 위하여 상기에서 기술된 바와 같이

다시 식별이 이루어질 수 있다.

- 루터(Router)-기능을 가지는 수신기:

특수한 IPover1394-네트워크에서 단 개의 어떠한 루팅(Routing)-

프로토콜도 사용되지 않는 한, 루터(Router)-기능을 가지지 않는

수신기에서와 같이 수신된 IP-루터의 조사가 이루어진다.

다른 경우에서 처치 방법은 각 루팅(Routing)-프로토콜에 의존한다.:

예를 들면 각 멀티캐스트-어드레스를 위한 각 루터가 DVMRP에서 루터에

의해 공급된 모든 수신기의 리스트(List)를 감독한다. 따라서 송신기는,

적어도 루팅-프로토콜에 자체적으로 참여할 때, 송신기가 루터-기능을

가지는 어떤 수신기를 공급했는지를 확인할 수 있다. 이에 관하여

T. Pusateri를 참조: Distance Vector Multicast Routing Protocol,

2000. 8.(Internet Draft: draft-jetf-idmr-dvmrp-v3-10).

모든 수신된 루터의 정확한 산출이 가능하지 않을 경우, 전형적으로 각

루팅-프로토콜에 참여함으로써 적어도 어떤 루터가 지역 써브네트워크

(Subnetwork)에 존재하는 지 그리고 이러한 루터 각각이 가능한

수신기로서 간주되는 지를 밝혀낼 수 있다.

하기에서 1394.1-네트워크의 채널예약을 송신하는 것과 다른 추가 데이터들을 송신하는 것이 기술된다.

실제 IPover1394-표준에서 MCAP-보고를 사용하여 디폴트(Default)-브로드캐스트(Broadcast)-채널(Channel) 중 전혀 다른 하나의 사용을 제시할 수 있다. 그 외의 필요한 계산 성능과 관련하여 변환 프로그램을 사용할 때 그리고 변환 프로그램에 의해 간접 보고된 1394-채널들을 포함하여 적절한 것이 생겨나야만 한다. 지금까지의 MCAP-보고를 식별하는 것은 보고의 "cpcode"-필드(Field)를 통해 자체적으로 또는 단독의 적절하게 확장된 MCAP-그룹(Group)-어드레스(Address)-디스크립터(Descriptor)의 "type"-필드(Field)를 통해 이루어질 수 있다. 지금까지의 정보에 더해 각각 간접 보고된 채널, 경우에 따라서는 상기 채널에 필요한 기억장치의 깊이, 뿐만 아니라 1394.1-네트워크의 경우에 소속된 자료의 GUID 및 Plug-Nr. 역시도 제시될 수 있다. 특히 상기를 위하여 제 8도에 따르는 포맷(Format)이 사용될 수 있다. 도면에서 표기된 디스크립터(Descriptor)의 전체 길이인, total_len, 채널(channel), 스피드(speed) 및 밴드와이드(bandwide)는 변환 프로그램의 송신을 위해 사용된 채널과 관계 있고, 지금까지 예약된 필드(Field) group_addr_len에서 group_address의 아크테트(Octet)의 길이가 자체적으로 제시될 수 있다. 간접 보고된 채널의 바로 다음의 리스트(List)는 예를 들면 제 9도에 따르는 등록으로 이루어진다. 차후의 확장을 위해 제 10도에 따르는 포맷(Format)이 예약된다. 다음에서 IPv4-네트워크를 사용할 때에 따르는 본 발명의 자세한 설명 이 기술된다.

변환에 관여된 유용 데이터 스트림의 전체 패키지는 길이 정보를 가지는 특수한 IP-헤더(Header)-옵션(Option)을 특징으로 한다. 실제 변환 프로그램은 유용 데이터 스트림의 내부에서이든지 혹은 그 이상 전용의(예를 들면 IP-) 결합을 통해 송신되어질 수 있다. 송신 순서를 재구성하기 위하여 수신기에 의해 송출된 모든 유용 데이터 스트림을 위한 공동의 시퀀스넘버(Sequence number) 순서가 각각의 (논리적) 수신기에 의해 송신된다. 상이한 유용 데이터 스트림을 위한 가지각색의 패키지 비율을 가능하게 하기 위하여, 유용 데이터 스트림 내부에서 시퀀스넘버(Sequence number)가 생략될 수 있다. 상기의 경우에 결함이 있는 패키지를 인식할 수 있기 위해, 패키지의 시퀀스넘버(Sequence number)와 함께 추가로 이전의(또는 다음의- 대안적 실행에서 - 이것에 관하여 물론 마찬가지로 수신기 측에 인과문제가 발생한다) 패키지의 시퀀스넘버(Sequence number)가 송신된다. 상기와 같은 시퀀스넘버(Sequence number)가 상이한 유용 데이터 스트림의 패키지에 발생할 수 있다면, 이것에 의해 분명한 시퀀스넘버(Sequence number)에 대해 모든 유용 데이터 스트림을 지나 다수의 비트(Bit)가 미리 주어질 때 시퀀스넘버(Sequence number)를 완전하게 실행시키는 시간이 증가한다. 유용 데이터 스트림에 스스로 적합한 싸이클을 이루는 순서가 할당된다면, 상기 싸이클이, 경우에 따라서 개별 유용 데이터 스트림의 생략하여 완벽하게 실행된다면, - 필요하다면 - 더욱이 상이한 유용 데이터 스트림 사이에 정확한 송신순서가 재구성되어질 수 있다.

단독의, 전용 결합을 통해 변환 프로그램이 전송된다면, 변환 프로그램 패키지에 상응하는 시퀀스넘버(Sequence number)가 채택된다.

수신기 측에서 시퀀스넘버(Sequence number)에 상응하는 개별 유용 데이터 패키지가 미리 주어진 혹은 예를 들어 결합 구조에서 다른 방법의, 형성 가능한 크기의, 경우에 따라서 분리된, FIFO-기억장치에 채택된다. 적합한 것이 변환 프로그램 프라그먼트(Fragment)에 적용된다. 개별 보고된 유용 데이터 프라그먼트(Fragment)가 적절한 변환 프로그램 프라그먼트(Fragment)가 완전히 실행될 때까지 상기 보고된 유용 데이터 패키지에 의해 전부 수신되지 않거나 내지는 변환 프로그램 프라그먼트(Fragment)가 수신되기 전에 FIFO를 거의 다시 벗어났다면, 그럴 경우 적절한, 또한 완전하지 않은, 결과로 발생된 패키지가 오류를 지닌채 수신된 것으로 간주된다.

유용 데이터 스트림에서 변환 프로그램 내지 시퀀스넘버(Sequence number)를 송신하기 위하여 IP-헤더(Header) 안에서 새로운 IP-헤더(Header)-옵션(Option)이 제한된다(제 11, 12도 참조): 옵션-넘버 "optnum"은 지금까지 사용된 모든 옵션넘버(Option number)와 구별된다. 대안으로 역시 옵션클래스(Option class) "cl"에 대한 식별이 이루어질 수 있다; optnum 및 cl은 상이한 변환 프로그램 포맷을 식별하는 데 사용되어질 수 있다. 옵션(Option)의 실제 내용은 경우에 따라서 사전의 패키지의 시퀀스넘버(Sequence number)에 의해 일어난, 송신 순서를 재구성하기 위한 순환성 시퀀스넘버(Sequence number) "sequence_number" 뿐만 아니라 변환 프로그램의 시작으로 구성된다. 점프오더(Jump order)에 의해 IP-헤더(Header)에서 패 키지 안의 임의의 다른 위치로 갈라지게 될 수 있다. 헤더의 전체 길이가 15 32-비트(bit) 워드(Words)로 제한되기 때문에, 따라서 변환 프로그램 부분은 역시 당연히 IP-헤더(Header)의 외부에서 저장될 수 있다. 상기 경우에서 제 1도의 기기와 같이 수신기와의 적합성을 얻기 위하여, 그와 같은 기기에서 무시된 적절한 자리가 더 높은 프로토콜 평면 내에서 발견된다. 전형적으로 상이한 IP-프로토콜에 이미 제공된 확정가능성들이 이용된다. 어떤 경우에서도 새로운 옵션(Option)의 사용이 IP-헤더(Header) 안에서 자체 보장된다면, 수신 측의 변환 유닛은 자체적으로 단지 IP-평면에서만 작동하고 따라서 새로운 포맷을 도입할 때 더 높은 프로토콜 평면에서 변경되어서는 안된다.

하기에서 가능한 변환 프로그램 명령 문구가 기술된다:

실제 변환 프로그램은 특별히 그 다음 명령의 임의의 순번으로 재구성될 수 있다.

NOP

상기 명령은 아무런 영향을 미치지 않으며 특별히 다음의 명령을 경우에

따라서는 어휘 제한에 적합하게 전달하는 데 사용된다.

ADD add

상기 명령은 실제 변환 프로그램 패키지 내부에서 맨 마지막의 CPY-명령의

길이를 "add" 아크테트(Octet) 까지 연장한다:

STREAM id

이를 통해 인덱스(Index) "id"를 가지는 유용 데이터 스트림이 그 이상의

카피액션(Copyaction)을 위하여 선택된다.

JR offset

변환 프로그램에서 맨 마지막의 "offset" 아크테트(Octet)를 상쇄한다.

"offset"은 예를 들면 2er-보색으로 암호화될 수 있다. "l"이

아크테트(Octet)에서 JR-명령의 길이를 표기한다면, JR(-l)은 변환

프로그램의 단부로 해석된다. JR(0)은 원칙상 적합한 수의 NOP-명령과

등가이지만, 특수한 실행에서 다른 목적을 위해 무한정일 수 있다.

PACKET offset

다음의 카피오퍼레이션(Copyoperation)을 위하여 시퀀스넘버

(Sequencenumber)에 상응하는 선행된 패키지를 "offset"에 이격하여

선택한다.

CPYIM s

실제 형성된 패키지 4s에, 뿐만 아니라 경우에 따라서 마지막 CPY 또는

CPYIM-명령 이후 심사된 ADD-명령에 의해 추가로 세분된 다수의

아크테트(Octet)에 부가한다.

CPY start,size

실제 패키지에서 "start"로 표기된 아크테트(Octet)로 시작되는, 실제

형성된 패키지 4s에, 뿐만 아니라 경우에 따라서 마지막 CPY 또는

CPYIM-명령 이후에 의해 처리된 ADD-명령에 의해 추가로 세분된 다수의

아크테트(Octet)에 부가한다.

CPY STOP start,size

CPY와 같지만, 그러나 동시에 변환 프로그램을 종결한다.

SEND...

실제 패키지를 송신한다. 명령의 정확한 길이와 의미는 각각의

목표 프로토콜(Protocol)에 의해 좌우된다.

SEND STOP

SEND와 같지만, 그러나 동시에 변환 프로그램을 종결한다.

다음에서 IP-네트워크 내 동시성 및 비 동시성 1394-채널의 에뮬레이션(Emulation)이 기술된다.

특히 동시성의 실제 1394-채널을 통해 CE-영역에 일반적으로 AV-유용 데이터 스트림이 송신된다. IP-영역에서, 적어도 그 이상의 수신기에 그와 동일한 유용 데이터 스트림이 공급되는 한, 유사한 사용을 위하여, 멀티캐스트(Multicast)-어드레스(Address)가 삽입될 수 있다. 따라서 각 1394-채널에 하나의 경우에 따라서 다이나믹하게 형성될 수 있는 멀티캐스트어드레스 내지 멀티캐스트어드레스/포르트(Port)-콤비네이션(Combination)이 부가되는 것이 적합하다. 데이터 포맷으로서 이제 예를 들면 실제 유용 데이터 스트림에 상응하는 RTP-포맷이 사용되어질 수 있다. 추가로 개별 에뮬레이트된 1394-노트(Knot)의 조정을 위해 그 이상의 멀티캐스트어드레스/포르트(Port)-콤비네이션(Combination)(하기에서 콘트롤 채널로 표기됨)이 사용된다. 다음의 설명은 변환 프로그램이 유용 데이터 스트림의 내부에서 변환 유닛의 관점에서 송신되어지는 경우로 한정된다.

변환 프로그램과 유용 데이터의 부가에 대한 조정이 다음과 같이 이루어진다:

콘트롤 채널을 통해 각 송신기는 일정한 간격으로 송신기에 의해 이용된 1394-채널을 위해 소속된 변환 프로그램뿐만 아니라 경우에 따라서 세분된 추가 유용 데이터 채널을 수신하기 위하여 IP-어드레스(Address) 및 포르트(Port)를 제공한다. 상기 채널 구성 정보는 암호 해독을 위하여 최소한으로 요구되는 FIFO-크기에 대한 정보들을 포함한다. 송신기는 콘트롤 채널에 대한 적절한 구성조회를 통해 특수한 1394-채널에 대한 채널 구성 정보의 송출을 직접 밀어낼 수 있고 그리고 동시에 상기 채널을 위해 수신기에 의해 최대한 사용될 수 있는 FIFO-크기를 보고할 수 있다. 상기 FIFO-크기가 송신기에 의해 당시 요구된 것 보다 작다면, 송신기는 암호화에 적합하도록 FIFO-크기를 알맞게 더 작게 시도한다. 상기가 IP-평면의 결함 있는 주파수대의 폭에 근거하여 가능하지 않다면, 송신기는 에뮬레이트된 1394-버스(BUS)-리셋(Reset)을 시작하고 다음의 결합이 재구성될 때, 송신기는 더 적은 주파수대의 폭 때문에 실패할 것을 배려한다.

송신기에 의해 전달된 FIFO-크기에서, IP-패키지가 수신기에 의해 최초의 송신 순서로 수신되어지고 상기 수신기에 의해 각각 전체 분열되지 않은 IP-패키지가 저장되어지는 것을 전제로 한다. 따라서 수신기에 의해 허용된 FIFO-크기를 계산할 때 구성 조회 안에서 추가로 경우에 따라서는 송신 순서를 재구성하기 위하여 필수적인 기억장치가 고려되어야한다. 적합한 구성조회를 통해 따라서 IP=송신품질이 변형될 때 적당한 제어가 가능하다.

구성조회/-정보의 가능한 구성:

a) 헤더(Header): (제 13도 참조)

버전(Version): 포맷버젼(Formatversion)(여기서는 0)

호환성이 약화되지 않은 정보 포맷이 새로운 버전넘버를 얻는다.

t: 패키지타입(Package type):

0: 구성정보

1: 구성조회

＞＝2: 차후 확장을 위해 예약된

tlength: 아크테트(Octet) 내 상기 구성정보/-조회의 전체 길이.

hlength: 아크테트(Octet) 내 헤더의 길이(여기서는 12 또는

특별히 fifo_size=0에 대한 8)

res: 차후 확장을 위해 예약된

fifo_size: IP 데이터 스트림에 대한 필수의(구성정보)

내지 최대 허용(구성조회)된 공동의 FIFO-크기.

s: 구성조회에서만:

0: 그 이상의 싱글(Single)-FIFO의 허용되지 않은 분열

1: 그 이상의 싱글(Single)-FIFO의 허용되지 않은 분열

오버헤드(overhead): 분열된 싱글(Single)-FIFO 당

fifo_size의 그 크기에 추가하여 감독정보를 위한

오버헤드(overhead) 아크테트(Octet)가 제거될 수 있다.

IP-패키지의 내부에서 역시 상이한 채널을 위한 정보와 조회도

차례차례로 송신되어질 수 있다.

b) 헤더 상에서 일어나는 경우에 따라서는 상기 채널에 부가된 IP=

데이터스트림의 리스트(List). 상기 리스트의 각 요소는 제 14도에 따르는

포맷(Format)을 가진다:

version: 포맷버젼(Formatversion)

호환성이 약화되지 않은 정보 포맷이 새로운 버전넘버를

얻는다.

protocol: IP-프로토콜 넘버

length: 상기 리스트 요소의 길이(여기서는 12 또는 18)

dest_add: IP-목표어드레스

dest_port: IP-포르트(Port)(적합한 IP-프로토콜에 의해 지원되는 한)

fifo_size: IP 데이터 스트림에 대한 필수의(구성정보)

내지 최대 허용(구성조회)된 추가의 FIFO-크기.

명령 SEND 및 SEND_STOP과 같은 추가의 변환명령이 다음과 같이 한정된다:

SEND second count cycle count

막 편성된 패키지를 비동시성(a=1) 또는 동시성(a=0) 패키지로 간주하고

패키지는 선행된 동시성 1394-싸이클 "[second_count,cycle_count]"에서,

내지는 앞서서 송신되지 않는다. "[second_count,cycle_count]"는

1394-CYCLE-COUNT 레지스터(Register)의 최대값 20 비트(bit)와 부합한다.

SEND STOP second count cycle count

SEND...와 같지만, 그러나 동시에 변환 프로그램을 종결한다.

RTP-수송 프로토콜을 사용할 때 변환 프로그램의 송신은 다음과 같이 일어난다:

RTP-수송 프로토콜의 분류에서, 실제 RTP-헤더에 선택적으로 소위 "헤더(Header) 익스텐션(Extension)"이 일어날 수 있다는 사실이 확정된다. 이에 관해 Schulzrinne, etc. 참조: A Transport Protocol for Real-Time Applications, 1996(RFC 1889).1. 상기 "헤더(Header) 익스텐션(Extension)"은, 지원받지 않는 RTP-실행에 의해 무시되어야만 한다. 특히 IP-헤더(Header)에서 완전한 변환 프로그램패키지를 위하여 자리가 충분치 않는 경우에, 변환 프로그램패키지는 RTP 헤더(Header) 익스텐션(Extension)"의 형태로 송신되어질 수 있다.

Claims (27)

1. 콘트롤 데이터 및 유용 데이터를 포함하는 데이터 스트림을 송신하기 위한 시스템으로서, 상기 시스템은,

   - 한 개 이상의 송신기와,

   - 상기 송신기와 수신기 사이에 제공되며, 제 1 네트워크 프로토콜을 가지는 주 네트워크, 그리고

   - 상기 주 네트워크에 직접 또는 간접적으로 연결된 하나 이상의 수신기를 포함하되, 상기 수신기 중 적어도 하나의 수신기가 제 1 네트워크 프로토콜 대신에 제 2 네트워크 프로토콜을 지원하고,

   상기 송신기는 상기 제 1 네트워크 프로토콜에 따른 데이터 스트림을 발생시키기 위한 제 1 수단(3a)과, 수신측의 변환 유닛(6,7)으로 전송할 추가 데이터들을 산출하고 상기 데이터 스트림에 삽입하는 제 2 수단(3b)을 포함하되,

   상기 변환 유닛(7,6)은 상기 제 1 네트워크 프로토콜 대신에 제 2 네트워크 프로토콜을 지원하는 수신기(5,8,9)에 직렬 접속되거나 삽입되고, 상기 변환 유닛이 상기 제 1 네트워크 프로토콜에 따라 전송된 상기 추가 데이터와 결합된 데이터를 제 2 네트워크 프로토콜에 따른 데이터로 변환하며,

   상기 송신기(3)의 제 2 수단(3b)에 의해 삽입된 상기 추가 데이터는 변환 프로그램 또는 변환 프로그램의 일부를 포함하는 것을 특징으로 하는 데이터 스트림 송신 시스템.
2. 제 1항에 있어서, 상기 송신기(3)의 제 2 수단(3b)에 의해 생성된 추가 데이터들이 데이터 스트림으로 삽입되는 것을 특징으로 하는 데이터 스트림 송신 시스템.
3. 제 1항 또는 제 2항에 있어서, 상기 송신기(3)의 제 2 수단(3b)에 의해 삽입된 추가 데이터들이 상기 주 네트워크 또는 상기 주 네트워크와 논리적 및 물리적으로 분리된 네트워크를 통해 수신측의 상기 변환 유닛에 전송되는 것을 특징으로 하는 데이터 스트림 송신 시스템.
4. 제 3항에 있어서, 상기 송신기(3)의 제 2 수단(3b)에 의해 산출된 추가 데이터들이, 분배를 위해 필요한 수신측의 유용 데이터 프로토콜에 기초하여, 상기 송신기에 의해 상기 주 네트워크와 다른 네트워크로 분배되는 것을 특징으로 하는 데이터 스트림 송신 시스템.
5. 제 1항 또는 제 2항에 있어서, 상기 제 2 네트워크 프로토콜을 지원하는 수신기(8)의 변환 유닛(7)이 한 개 이상의 보조 네트워크(2)를 통해 연결되는 것을 특징으로 하는 데이터 스트림 송신 시스템.
6. 제 5항에 있어서, 상기 보조 네트워크(2)에 하나 이상의 수신기(8)가 연결되고, 상기 수신기가 상기 제 2 네트워크 프로토콜을 지원하는 것을 특징으로 하는 데이터 스트림 송신 시스템.
7. 제 5항에 있어서, 상기 변환 유닛(7)이 동일한 또는 다른 보조네트워크(2)를 통해 하나 이상의 수신기(10)와 연결되고, 상기 수신기는 제 3 네트워크 프로토콜 또는 또 다른 네트워크 프로토콜을 지원하며,

   상기 변환 유닛(7)이 추가 데이터를 사용하여 유용 데이터 스트림을, 상기 제 3 네트워크 프로토콜 또는 또 다른 네트워크 프로토콜에 따른 데이터로 변환하는 것을 특징으로 하는 데이터 스트림 송신 시스템.
8. 제 1항 또는 제 2항에 있어서, 상기 송신기(3)는, 변환 규약을 가지는 데이터 스트림을 송신하는 것이 하나 이상의 다른 네트워크 프로토콜에 따른 데이터 스트림을 다중 송신할 때보다 더 큰 송신 주파수 대역폭을 필요로 하는 지를 테스트하는 테스트 유닛(3c)을 포함하고,

   상기 송신기(3)는 상기 테스트 결과에 따라, 더 작은 송신 주파수 대역폭을 요하는 데이터 스트림을 송신하는 것을 특징으로 하는 데이터 스트림 송신 시스템.
9. 제 8항에 있어서, 상기 테스트는 개별 데이터 패키지, 데이터 패키지의 그룹 또는 전체 유용 데이터 스트림에 대해 수행되는 것을 특징으로 하는 데이터 스트림 송신 시스템.
10. 제 1항 또는 제 2항에 있어서, 상기 송신기(3)는, 상기 주 네트워크(1)에 연결되며 상기 제 2 네트워크 프로토콜만을 지원하는 수신기에 변환 유닛이 직렬 접속되거나 삽입되었는지를 테스트하는 테스트 유닛(3c)을 포함하고,

    유용 데이터 스트림을 사용할 모든 수신기 또는 이에 직렬 접속된 변환 유닛이 변환 규약 또는 변환 프로그램을 이용하여, 상기 유용 데이터 스트림을 제 2 네트워크 프로토콜에 따라 변환할 수 있도록, 상기 송신기(3)가 상기 변환 규약 또는 변환 프로그램을 유용 데이터 스트림에 부가하는 것을 특징으로 하는 데이터 스트림 송신 시스템.
11. 제 10항에 있어서, 상기 수신기 또는 변환 유닛은, 데이터를 상기 송신기에 송신하기 위하여 제공되며 상기 수신기 또는 변환 유닛에 의해 지원되는 네트워크 프로토콜, 전송 가능성 및 전송 범위에 따라, 상기 변환 규약 내지 변환 프로그램을 처리하기 위한 정보들을 가지는 것을 특징으로 하는 데이터 스트림 송신 시스템.
12. 청구항 제 1 항에 따른 시스템에서의 동작하며, 데이터 스트림을 발생하는 송신기에 있어서, 상기 송신기는,

    - 제 1 네트워크 프로토콜에 따른 데이터 스트림을 발생시키는 제 1 수단(3a), 및

    - 변환 규약과 같은 추가 데이터를 발생하는 제 2 수단(3b)

    을 포함하되, 상기 변환 규약은 제 1 네트워크 프로토콜에 따른 데이터를 제 2 네트워크 프로토콜에 따른 데이터로 변환하기 위하여 제공되는 것을 특징으로 하는 데이터 스트림을 발생시키기 위한 송신기.
13. 제 12항에 있어서, 상기 제 2 수단(3b)에 의해 발생된 추가 데이터들이 데이터 스트림으로 삽입되는 것을 특징으로 하는 데이터 스트림을 발생시키기 위한 송신기.
14. 제 12항 또는 제 13항에 있어서, 상기 제 2 수단(3b)에 의해 발생된 추가 데이터가 주 네트워크와 다른 논리적 또는 물리적 네트워크로 전송되는 것을 특징으로 하는 데이터 스트림을 발생시키기 위한 송신기.
15. 제 14항에 있어서, 상기 송신기(3)의 제 2 수단(3b)에 의해 발생된 추가 데이터가, 분배를 위해 필요한 수신측의 유용 데이터 프로토콜에 기초하여, 상기 송신기에 의해 상기 주 네트워크와 다른 네트워크로 분배되는 것을 특징으로 하는 데이터 스트림을 발생시키기 위한 송신기.
16. 제 12항 또는 제 13항에 있어서, 상기 제 2 수단(3b)에 의해 삽입된 추가 데이터는, 변환 프로그램 또는 변환 프로그램의 일부에 대응하는 데이터인 것을 특징으로 하는 데이터 스트림을 발생시키기 위한 송신기.
17. 제 12항에 있어서, 상기 송신기가, 상기 변환 규약을 가지는 데이터 스트림을 송신하는 것이, 하나 이상의 프로토콜에 따라서 데이터 스트림을 다중 송신할 때보다 더 큰 송신 주파수 대역폭을 필요로 하는 지를 테스트하는 테스트 유닛(3c)을 포함하되,

    상기 송신기는 상기 테스트 결과 더 작은 송신 주파수 대역폭을 요하는 데이터 스트림을 송신하는 것을 특징으로 하는 데이터 스트림을 발생시키기 위한 송신기.
18. 제 17항에 있어서, 상기 테스트는 개별 데이터 패키지, 데이터 패키지의 그룹 또는 전체 유용 데이터 스트림에 대해 수행되는 것을 특징으로 하는 데이터 스트림을 발생시키기 위한 송신기.
19. 제 12항 또는 제 13항에 있어서, 상기 송신기는, 주 네트워크(1)에 연결되며 제 2 네트워크 프로토콜만을 지원하는 수신기에 상기 수신기와 호환가능한 변환 유닛이 직렬 접속되거나 삽입되는 지를 테스트하는 테스트 유닛(3c)을 포함하고,

    유용 데이터 스트림을 이용할 모든 수신기 또는 직렬 접속된 변환 유닛이 상기 변환 규약 또는 변환 프로그램을 사용하여, 상기 유용 데이터 스트림을 제 2 네트워크 프로토콜에 따라 변환할 수 있도록, 상기 송신기(3)가 상기 변환 규약 또는 변환 프로그램을 유용 데이터 스트림에 부가하는 것을 특징으로 하는 데이터 스트림을 발생시키기 위한 송신기.
20. 청구항 제 1항에 따른 시스템에서 작동하는 변환 유닛에 있어서,

    상기 변환 유닛은 제 1 네트워크 프로토콜에 따라서 송신된 유용 데이터를 추가 데이터들을 사용하여 상기 제 1 네트워크 프로토콜과 다른 네트워크 프로토콜에 따른 데이터로 변환하는 것을 특징으로 하는 변환 유닛.
21. 제 20항에 있어서, 상기 추가 데이터들이 상기 제 1 네트워크 프로토콜에 따라 송신된 유용 데이터와 함께 주 네트워크에 통해 수신되는 것을 특징으로 하는 변환 유닛.
22. 제 20항 또는 제 21항에 있어서, 상기 추가 데이터들이 상기 주 네트워크와 다른 논리적 또는 물리적 네트워크를 통해 수신되는 것을 특징으로 하는 변환 유닛.
23. 제 22항에 있어서, 상기 추가 데이터들이 유용 데이터 스트림을 변환할 때 필요한 네트워크 프로토콜에 따라 분리되어 수신되는 것을 특징으로 하는 변환 유닛,
24. 제 20항 또는 제 21항에 있어서, 상기 추가 데이터들의 전부 또는 일부가 변환 규약 또는 변환 프로그램으로 해석되는 것을 특징으로 하는 변환 유닛.
25. 제 20항에 있어서,

    상기 변환 유닛에서 변환을 위해 사용된 추가 데이터가, 테스트 유닛(3c)에서 이용되도록 상기 테스트 유닛(3c)으로 전송되는 것을 특징으로 하는 변환 유닛.
26. 청구항 제 1 항에 따른 시스템에서 동작하는 수신기에 있어서, 상기 수신기가 변환 유닛에 삽입되는 것을 특징으로 하는 수신기.
27. 삭제

Images