KR20080068690A - 상보적 지정 파일을 이용하여 실시간전송프로토콜 출구스트리밍을 위한 방법 및 장치 - Google Patents

Abstract

특히 RTP 실시간 프로토콜 스트리밍과 같은 하드웨어 가속화된 스트리밍 배치에서 네트워크 가속화 스트리밍 시스템을 통하여 전송되는 포인터, 헤더 길이 및 하나 이상의 데이터 패킷의 블록 오프셋을 결정하는 지정 파일을 채택하고 있다. 지정 파일은 예를 들어 백그라운드에서 동작하는 제어 처리장치에 의해 확립되고, 데이터가 발송되는 동안에 미디어 형태 또는 관련된 프로토콜과 관련된 분석을 필요로 하지 않으면서, 헤더 크기 및 RTP 페이로드 및 다른 데이터를 포함하는 특정 정보를 결정할 수 있도록 하는 정보를 제공하기 위하여 저장된다. 본 발명에 따르면, 다른 경우라면 개입이 필요한 정보의 제어 처리장치를 완화시켜 발신 처리가 반복적인 방법으로 진행될 수 있게 하는데, 바람직하게는 속도를 위한 하드웨어 요소에서 가능한 한 중계되고, 더욱 복잡할 수 있지만 실시간으로 스트리밍 하기 위하여 덜 빈번하고/빈번하거나 시간에 민감하지 않은 제어 기능을 위한 계산 능력을 제어 처리장치가 가질 수 있도록 한다.

Description

상보적 지정 파일을 이용하여 실시간전송프로토콜 출구 스트리밍을 위한 방법 및 장치{METHOD AND APPARATUS FOR RTP EGRESS STREAMING USING COMPLEMENTRARY DIRECTING FILE}

본 발명은 예를 들어 디지털 비디오 처리 센터 또는 오락 시스템, 회의 시스템 또는 다른 응용 장치에서 실시간전송프로토콜(RTP) 스트리밍을 이용하는 실시간 데이터 전송 장치 및 방법에 관한 것이다. 또한, 본 발명은 예를 들어 패킷 주소지정(addressing) 또는 패킷 처리 정보와 같이, 패킷 취급(packet handling) 과정에서 정보가 결정되어 진행중인 데이터 패킷 헤더로 정보가 삽입되는 패킷 데이터 전송 응용 장치에 응용될 수 있다. 이러한 작동은 RTP 스트리밍을 위한 실시간 데이터 속도와 보조를 맞출 필요가 있고, 바람직하게는 제한된 계산량(computational load)과 보조를 맞출 필요가 있다. 본 발명에 따르면, 지정 파일(directing file)은 제어 처리 장치에 의해 구성되어 패킷이 나가는 동안 그러한 정보의 삽입을 촉진한다.

콘텐츠(content) 및 제어 정보가 데이터를 저장, 표시 또는 처리하는 기능적 요소로 지정되고 이러한 기능적 요소로부터 콘텐츠 및 제어 정보가 지정되는 다양한 기록(recording), 재생(playback) 및 처리 기능에 본 발명의 장치와 방법이 기여한다. 데이터 스트리밍 환경에서, 제어 정보와 대응할 때 특정 단계가 요구된다. 예를 들어 접속을 시작할 때, 제어 정보에 대응하기 위해서는 데이터 패킷 처리 및 주소 할당을 설정할 필요가 있다. 저장 매체 또는 통신 경로 또는 소켓(socket)으로부터 전송된 패킷을 찾거나 접근할 필요가 있을 수 있다. 제어 입력 및 또한 패킷에서 발견된 정보에 기초하여, 전송 장치는 얼마나 정확하게 전송이 진행되는지를 결정한다. 요청되는 코드, 플래그(flags), 주소 및 다른 조건 지시자(conditional indicators)는 결정되어 신호 전달(signaling)에서 사용될 필요가 있는데, 예를 들어 패킷 헤더로 이들을 삽입하거나 또는 원래의 패킷이 수송되어야 하는 데이터 블록에 대한 새로운 헤더를 제공하는 방법 등을 통해서 가능하다. 이러한 단계들은 매우 복잡한 계산을 필요로 할 수 있어 일반적으로 소프트웨어에 의존할 수 있다.

그러한 접속이 이루어지고 데이터 전송이 개시된 후에 필요한 사항은 다소 상이하다. 예를 들어, 연속 스트림(stream)에서 다음 패킷의 정보, 제어 및 주소 할당은 바로 이전에 진행된 패킷에 대해서 사용되었던 정보와 밀접하게 연관될 가능성이 있다. 연속적인 패킷은 그 스트림을 통한 것과 거의 마찬가지로 정보를 처리하도록 의도될 수 있다. 패킷은 패킷 처리 번호(sequence number)와 같이 점증하는 관점에서 다를 수 있다. 일부 종류의 저장 장치로부터 판독하는 경우, 소스 주소가 전진하지만, 계산의 복잡성의 정도는 적어진다. 이러한 단계는 속도 및 효율 성에서 이점이 있고 일반적으로 하드웨어에 의존한다.

예를 들어 네트워크로 접속된 저장 요소(storage element)로 데이터 패킷을 각각 경로 배정(routing)하고 접속된 저장 요소로부터 데이터 패킷을 각각 경로 배정하는 것과 같이, 계산이 복잡하지 않은 각각의 데이터 처리 단계는 제어 처리 및 주소 할당 단계와 같이 복잡한 계산이 없으며 또한 상대적으로 빈번하지 않은 기능과 다르게 취급되는 것이 유리하다. 필요한 것은 최적의 해결책이다.

잠재적으로 다른 데이터 포맷을 사용하는 잠재적으로 다른 장치가 서로 상호작용할 수 있도록 하는 것이 일반적으로 유리하다. 매우 빠른 데이터 속도에서 다른 장치 및 데이터 포맷을 수용하면서, 데이터 처리 시스템 내에서 다양성을 제공할 필요가 있다는 점에서 설계에 대한 문제점이 제기되고 있다.

산업적 표준은 특정 데이터 타입의 포맷팅(formatting)을 좌우하고 있다. 표준은 주소 할당 및 신호 전달 기술, 데이터 저장 및 복구(retrieval), 통신 등에 영향을 미친다. 표준은 일반적으로 다양한 수준에서 적용된다. 예를 들면, 영상 암호하 표준에 따라 암호화된 영상 데이터를 전송하는 경우에 패킷 신호전달 표준 또는 프로토콜이 응용될 수 있는 등 다양하다.

소스(source) 와 수신지(destination) 사이에서 전송되는 패킷 데이터는 데이터 포맷 전환, 계산, 버퍼링 및 유사한 처리 및/또는 저장 단계와 같은 처리 단계를 중재할 수 있도록 유익하게 설정될 수 있다. 다중 서버와 단말 장치를 갖는 데이터 처리 시스템에서, 일부의 계산량은 데이터 포맷팅 및 재-포맷팅(reformatting)과 관련된 활동으로 사용된다. 계산량의 일부는 소스와 수신지 사이에서의 주소 할당 및 교환으로서, 사용자 선택과 같은 조건에 대응하여 잠재적으로 정렬을 변화시킨다.

데이터 패킷을 스트리밍 하는 경우에 한가지 요구조건으로는 진행중인 데이터 패킷 내에서 패킷을 확인하는 특정 정보를 제공하는 것으로, 이 정보는 스트리밍 신호 경로를 따라 위치하고 있는 요소(elements)에 의해서 사용된다. 작동 중인(on the fly) 스트리밍 되어 있는 데이터를 분석하기 위해서 제어 처리장치를 사용하는 것이 가능한데, 이는 계산량을 나타내게 된다. 이러한 기능을 다루기 위해서 하드웨어 장치를 제공하는 것이 가능할 수 있는데, 이러한 장치는 복잡해야 하며 프로그래밍의 다양성이 부족하다. 다른 해결책이 필요하다.

계산의 복잡성을 제공하는 것에 대해서 속도를 개선하기 위한 스트리밍 및 단순화의 목적은 물론 양립되지 않는 설계 목표이다. 빠르면서 동시에 다목적의 정렬을 제공할 수 있도록, 계산 능력에 대한 요구에 대응하여 속도 및 데이터 성능에 대하여 병행하는 요구를 최적화하는 것이 유익할 것이다. 본 발명은 예를 들어 패킷 출구(packet egress)와 같이 진행중인 데이터 패킷을 관리하는데 필요한 특정 기능을 분리하여, 필요한 출구 정보(를 구성하는, 복잡하면서도 적응력 있는 계산 기능이 제어 처리 장치로 할당되어 소프트웨어에 의하여 실질적으로 구현될 수 있다.

바람직한 실시예에서, 본 발명은 실시간 전송 프로토콜(real time protocol, RTP) 패킷 스트리밍에 관하여 보여주고 있다. 패킷 소스와 수신지 타입의 예시적인 그룹이 논의되고, 오락 또는 원격 회의를 위한 영상 데이터 처리에 응용될 수 있고, 보안 모니터링, 게임 시스템 및 다른 용도를 잠재적으로 포함한다. 전송 경로는 유선이거나 무선일 수 있고, 기업 네트워크 또는 공공 네트워크를 포함할 수 있다. 재생을 위한 단말기는 오디오 또는 비디오 오락 시스템, 컴퓨터 워크스테이션, 고정되거나 또는 휴대용 장치를 포함할 수 있다. 데이터는 네트워크 서버를 사용하여 저장되고 처리될 수 있다. 예시적인 통신 시스템으로는 근거리 또는 광대역 네트워크, 케이블, 텔레커뮤니케이션 회사의 네트워크를 포함한다.

음성 및 및 영상 데이터와 접속하여, 실시간 프로토콜("RTP", 또한 "실시간 전송 프로토콜(Real Time Transport Protocol)"로도 알려져 있음)은 패킷 단위로 나누어진 오디오 및/또는 영상을 이동시키고 데이터 통신 네트워크를 통하여 영상 데이터를 실시간 데이터 속도로 이동시키는데 적합한 표준 프로토콜이다. 실시간 또는 실황 속도에서 음성 및 영상 데이터의 재생(playback)은 저장 버퍼에 대한 요구를 최소화하는 한편 콘텐츠의 중단과 시작을 피할 수 있도록 하는 것이 바람직하다. 원격 회의 및 이와 유사한 통신과 같은 응용 장치에서, 패킷 단위로 나누어진 데이터의 수집, 처리, 전송 및 판독은, 얼굴을 직면하는 실시간 회의 및 대화와 일치하도록, 데이터 전송 지연이 거의 인식되지 않으면서 아무런 갭을 보이지 않으면서 일어나도록 하는 것이 바람직하다.

RTP (실시간 프로토콜)은 합리적인(streamlined) 방식으로 음성 및 영상 데 이터를 포함하는 실시간 데이터의 처리를 촉진하기 위한 공지된 프로토콜이다. RTP는 인터넷 전화(internet telephony)와 같은 쌍방향 서비스는 물론이고 주문형 매체(media-on-demand)에 대해서도 사용될 수 있다. RTP는 또한 병행 처리와 함께 프레젠테이션 및/또는 기록을 가능하게 하는 다중 소스 및 수신지로의 그리고 다중 소스 및 수신지로부터의 음성 및 영상을 지정하는데 사용될 수 있다.

데이터가 처리되는 방법은, 예를 들어 특정 소스, 수신지 또는 참가자(participants)를 포함하는 접속을 개시하고 종료시키기 위하여, 제어 및 주소할당 기능을 사용하여 때때로 변경될 수 있다. 따라서, RTP는 콘텐츠의 전송을 위한 데이터 콘텐츠 부분과 개시, 중단 및 주소할당을 포함하는 데이터 처리 방법을 변경시키기 위한 제어 부분을 포함한다. RTP의 제어 부분은 실시간 제어 프로토콜(Real Time Control Protocol)의 약어인 "RTCP"로 불려진다.

RTP의 데이터 부분은 연속 매체(예컨대 음성 및 영상)의 전송과 같은 실시간 특성을 갖는 응용 제품에 대한 지원을 제공하는 얇거나 또는 합리적인 프로토콜이다. 이러한 지원에는 타이밍 복원(timing reconstruction), 손실 탐지 또는 회복, 보안, 콘텐츠 확인 및 매체 콘텐츠의 전송에 따라 반복되고 실질적으로 연속적으로 일어나는 유사한 기능을 포함한다.

RTCP는 인터넷과 같은 통신 네트워크 내에서 임의 크기 집단의 실시간 회의에 대한 지원을 제공한다. 이러한 지원으로는 멀티캐스트에서 유니캐스트(multicast-to-unicast)로의 번역기는 물론이고 소스 확인 및 음성 및 영상 브리 지(bridge_와 같은 게이트웨이에 대한 지원을 포함한다. 이러한 지원은 다른 매체 스트림의 동기화를 위한 지원은 물론이고 수신자로부터 멀티캐스트 그룹으로 서비스 품질 피드백(quality-of-service feedback)을 제공한다.

RTP 및 RTCP는 위에서 논의된 형태의 데이터의 전송을 촉진시키기 위하여 특별히 정렬된 데이터 프로토콜이지만, 주어진 네트워크 구성에서 RTP 및 RTCP 프로토콜은 더욱 높거나 낮은 프로토콜 또는 표준과 연계될 수 있다. 고급 수준에서, 일례로 RTP 및 RTCP는 영상 회의 시스템 또는 데이터를 처리하기 위한 보고-저장하기(view-and-store) 또는 다른 기술을 서비스하는데 사용될 수 있다. 저급 또는 더욱 기본적인 수준에서, RTP 및 RTCP 데이터 전송에서 사용되는 패킷은 실제로 다른 패킷 전송 메시지 프로토콜에 따라 전송될 수 있다. 이러한 예로는 전송 제어 프로토콜(Transmission Control Protocol, TCP 또는 인터넷에서는 TCP/IP) 및 사용자 데이터그램 프로토콜(User Datagram Protocol, UDP)이다.

TCP 및 UDP는 모두 패킷 전송을 위한 프로토콜이지만 패킷 무결성(packet integrity), 에러 체킹, 사라진 패킷에 대한 민감도 및 다른 관점(aspect)에서 실질적으로 다른 특성이 있다. TCP는 일반적으로, 사라지거나 손상된 패킷을 얻기 위한 재시도를 포함하여, 전송 과정에서 양방향 접속이 유지되고 있는지, 모든 연관된 패킷이 전송될 때까지 그 접속이 유지되어 수용자 단말에서 조합되었는지를 확인하는데도움이 되는 프로토콜의 관점이다. UDP는 일반적으로 패킷 전송 시도를 처리하지만, 모든 필요한 패킷이 전송되고 수신되었는지를 확인하기 위하여 패킷을 전송하고 수신하는 응용 제품에 달려 있다. 원격회의 영상의 스트리밍과 같은 일부 응용 프로그램은 간헐적으로 빠진(dropped) 패킷에 대해서는 그다지 민감하지 않다. 하지만, 패킷이 빠진다면 스트리밍은 가능한 한 균일하게(seamlessly) 계속되는 것이 유익하다.

다른 프로토콜이 다르게 작동하는 방법을 해당 구성(configuration)이 완전히 이용할 수 있도록 하면서 광범위한 고급 및 저급 프로토콜을 사용하여 실시간 전송이 작동할 수 있는 기술이 작동될 수 있다면 유익할 것이다. 작동을 적절하게 조정하여 통신을 위하여 사용될 수 있는 자원, 계산을 위하여 사용될 수 있는 자원, 상황에 민감한 스위칭(switching) 및 결정이 최적화될 수 있는 고성능 또는 높은 요구 조건의 시스템에서 특히 유용할 것이다.

별도로 그리고 동시에(contemporaneously) 작동하는 전송 데이터 경로 및 제어 데이터 경로를 채택함으로써 효율적인 영상 및 유사하게 연속적으로 스트리밍 하는 데이터 처리를 제공하는 것이 본 발명의 관점인데, 2개의 데이터 경로는 처리율(throuhput) 및 처리 능력을 위하여 각각 별도로 구성되어 있는 별개의 협동 자원(cooperating resources)을 사용하여 데이터-처리율(data-throughput)로 집약된 기능 및 데이터-처리로 집약된 기능을 각각 별도로 취급한다.

더욱 상세하게, 실시간 프로토콜(RTP)과 연관된 특정 자원-집약형 처리의 서브셋(subset)을 분할함으로써 미디어 서버에 의하여 수행되는 처리를 촉진하고 가속화시키기 위한 장치 및 방법이 제공되는데, 할당된 서브셋에 대해서 최적화된 처리장치 및 스위칭 장치에 의하여 처리된다. 속도에 근거한 기능의 분할(partitioning)은 데이터 경로(pipeline)의 특성을 갖는 장치로 할당된다. 계산량은 RTP 세션을 다루어 계산적인 면을 처리하는 하나 이상의 중앙 처리장치로 할당되어, 처리장치는 데이터 통신 경로에서 스트리밍 데이터를 전송하는 것에 대해서는 종래에 비하여 적은 관심을 갖는다.

특정 실시예에서, 본 발명의 방법은 RTP 패킷 스트리밍과 연관되어 있는 발신 데이터 블록을 정의하기 위하여 제공된 정보를 적어도 부분적으로 구성하고 있는 하드웨어 인터페이스 요소를 사용하는 것과 관련이 있다. 지정 파일(directing file)은 중앙 처리장치에 의하여 전적으로 또는 부분적으로 실장(populated)될 수 있는 방법으로 제공되는데, 패킷 출구(packet egress)와 연결되어 있는 지정 파일에 접속하는 가속기 요소와 연결된다. 지정 파일은 패킷 출구와 연결되어 있는 하드웨어 가속기를 인도한다. 처리장치는 서로 다른, 동시에 일어나는 스트리밍 연결을 잠재적으로 처리하기 때문에 처리장치가 각각의 패킷을 분석할 필요가 없다. 대신, 처리장치는 현재 진행중인 각각의 연결을 위하여 지정 파일을 설정하고, 패킷이 외부로 전송됨에 따라 가속기가 정보를 적용한다(apply).

가속기는 실질적인 통제(supervision) 없이, 고속 데이터 속도로 작동하는 하드웨어 인터페이스 요소일 수 있는데, 지정 파일의 콘텐츠에 기초하여 필요한 블록과 헤더 정보를 제공한다. 이에 따라, 계산-집약되어 있는 기능에 대한 관심으로부터 해방된다. 비록 가속기가 논의되는 바람직한 실시예에서 하드웨어 요소이기는 하지만, 가속기 내의 처리장치가 배제되는 것은 아니다.

일 실시예에 따르면, 콘텐츠주소지정기억장치(content addressable memory, CAM) 파일이 유지되고 이에 의하여 하드웨어 가속기는 다중의 현재-유지중인 패킷 대기열(packet queues)을 특정 주소와 연관시킨다. 캠 파일은 다중 수준의 오프셋 헤더(offset header)를 포함하는 데이터 패킷과의 연결에서 특히 헤더 정보를 결정하는데 사용될 수 있다. 새로운 종점(endpoint)으로 새로운 스트리밍 연결을 개시하기 위하여 셋업(SETUP) 요청이 수신되고 캠 파일 내에 이에 상응하는 엔트리(entry)를 찾지 못한 경우, 하드웨어 가속기는 처리장치로 신호를 보내 엔트리가 설정된다. 하드웨어 가속기는 기록(RECORD) 또는 전송(SEND) 메시지를 예상하여 캠 내에서 엔트리를 개시함으로써 연관된 헤더 값과 함께 제공된다. 새로운 종점과 연관된 헤더 값은 중앙 처리장치에 알려져 있지만, 처리장치는 단지 콘텐츠주소기억장치(CAM) 내에서 새로운 패킷 대기열을 설정함으로써 새로운 종점으로 경로 배정만을 설정하면 된다. 이어서, 하드웨어 가속기는 착신(incoming) 패킷에 대한 패킷 대기열 엔트리를 찾아내어 필요한 값으로 치환한 뒤 그 목적지를 향하여 패킷을 통과하는 자동화된 방법으로 작동할 수 있다.

확립된 대기열 엔트리를 가지는 RTSP 기록 또는 전송 메시지가 수신되는 경우, 발신 헤더 값을 결정하는 것에 대한 책임은 트래픽 관리기 및 중앙 처리장치와 데이터 통신하고 있는 하드웨어 가속기가 지게 된다. 그 접속은 현재 진행중인 채로 남아 있을 수 있는데, 완료될 때까지 또는 어느 하나의 프로그램화(programmable) 기능에 따라 스트림의 종점 또는 종점들을 결정하는 것과 같이 중앙 처리장치가 필요로 하는 새로운 제어 또는 활동을 발휘할 때까지 고속 데이터 속도의 이익을 가지게 된다. 그러한 기능으로는 각각의 통과 패킷을 취급하는 방법인 프로그램화 되어 있는 소프트웨어 루틴(routines)을 통하여 결정할 수 있도록 다른 경우라면 제어장치를 요구하는 기능의 대부분 또는 그 기능의 전부를 포함할 수 있다. 그러한 기능으로는 소스와 수신지 사이에서 패킷의 경로 배정(routing), 중간 처리 단계의 삽입, 재생하면서 동시에 기록하는 것과 같이 동시에 2 이상의 수신지로 패킷의 경로 배정 등을 포함할 수 있다.

본 발명은 전체 헤더 및 헤더 블록에 대한 정보를 함유하는 지정 파일을 채용하고 있는데, 지정 파일은 RTP 헤더에 부가되어 확립되고 패킷 출구, 즉, 출력과 접속하는데 사용되어, 패킷 출력의 관리를 가속하는 것은 중앙 처리장치로부터 반복적으로 진행중인 관심을 최소화하는 것이다.

스트리밍 데이터 속도와 처리율 요구는 엄격할 수 있다. 처리장치를 사용하여 보조를 맞출 수 있도록, 계산량 및 발신 데이터 블록으로 정보를 구성하고 삽입하여야 하는 요구 모두로부터 벗어나기 위해서는 매우 신속하고 성능 좋은 중앙 처리장치가 요구될 것이다. 중앙 처리장치에서 계산량을 최소화할 수 있도록 지정 파일을 채택하는 것이 본 발명의 관점이다. 지정 파일이 하드웨어 가속기와 인터페이스로 연결되어 배열될 수 있는 한, 그러한 계산량은 제어기를 통하여 지정 파일을 설정하여 제어기의 감시 없이도 스트림이 계속해서 데이터 블록을 전송할 수 있도록 하는 것으로 실질적으로 제한될 수 있다.

효율적인 방식으로 제어 및 콘텐츠 패킷을 처리하는 것에 대하여 최적의 해결책을 제공하는 것이 본 발명의 관점이다. RTSP/RTP 해결책은 하드웨어 또는 소프트웨어로만 전적으로 구현되어서는 안 되지만, 그 공정이 주로 소프트웨어에 의하여 제어되면서도, 그 공정은 매체 객체와 소프트웨어에 의해 생성된 지원 파일(supporting files)을 사용하여 데이터 전송을 가속화할 수 있도록, 바람직하게는 하드웨어를 사용하여, 채택될 수 있는 레지스터 값 등을 생성하는 혼성(hybrid) 해결책에서 최상으로 구현된다.

상대적인 복잡성 및 거의 작동하지 않는 특성으로 인하여, RTSP 또는 RTCP 패킷은 빈번하지 않은 개입(attention)을 필요로 하기 때문에, RTSP 및 RTCP (즉, 대부분 제어 처리장치를 관리하는데 사용되는 패킷)는 과부화를 일으키지 않고서도 중앙 처리장치에서 구현될 수 있다. 반면, RTP 처리는 매체 스트림에서 각각의 발신 패킷으로 개입하기 위한 처리를 필요로 하고 가속화로부터 이익을 갖게 된다.

패킷 출구 스트리밍은 실시간 지원, 즉 데이터 패킷의 실시간 속도와 보조를 맞추는 것이 엄격하게 요구된다. 본 발명은 어떤 의미에서는 암시(hinting)를 사용하고, RTP 패킷 정보를 하드웨어에 제공하거나 또는 필요로 하는 출구 정보의 생성을 더욱 직접적으로 유도하는 구현에서 지정 파일을 채택한다. 지정 파일의 콘텐츠를 결정하는 과정에서 제어 처리장치가 포함될 수 있다. 그러나 지정 파일이 접속을 위해서 원래의 위치로 복귀한 후, 진행시키기 위하여 서버 또는 제어기가 작동 상태로 스트리밍 되어 있는 매체를 분석할 필요성을 제거함으로써, 암시 기법은 서버 상에서 RTP 스트리밍을 가속화한다.

본 발명의 기법에서 전용(dedicated hardware)에 전적으로 책임을 전가하지 않는다. 예를 들면, 본 발명의 기법에서 하드웨어가 암시 데이터를 분석(parse)할 필요가 있을 수 있으므로 하드웨어가 충분히 복잡할 필요가 없다.

미래의 확장을 위해서 바람직하게는 지정 파일에 대한 포맷은 유연하게 표시된다. 동시에, 지정 파일 포맷의 유연성으로 인하여 하드웨어 장치로의 반복적이고 계산적인 면에서 단순한 스트리밍 기능성(functionality)을 해방시킨다는 목적을 복잡하게 해서는 안 된다.

본 발명의 방법은 하드웨어에 의해 사용될 수 있는 상보 파일(complementary file) 내에서 미디어 객체 그 자체가 아니라 필요한 정보를 포함함으로써, 이런 문제점을 해결한다. 특정 RTP 패킷 형태(즉 FRS에 따라 정의된 패킷 형태)를 갖는 미디어 파일이 스트리밍 장치(streamer)로 접근할 수 있고 그 미디어 파일이 스트리밍을 위한 후보자라면, 지정 파일이 생성된다. 이 파일은 중앙 처리장치에서 실행되고 있는 소프트웨어에 의해서 백그라운드(backgroud)로, 즉 자원이 입수되는 경우에 처리되는 낮은 우선 함수(function)로 생성된다. 지정 파일은 RTP 스트리밍을 위한 객체를 패킷 단위로 구분하는 법은 스트리밍 장치에 알려준다는 점에서 암시 데이터와 유사하다. 하지만, 본 발명의 지정 파일은 패킷의 방출을 처리하는 방법에 관하여 암시 데이터보다 훨씬 더 특정되어 있다. 따라서, 본 발명의 기법은 중앙 처리장치가 원래의 미디어 객체에 관하여 훨씬 적은 지식을 갖고 있는 상황에서도 작동할 수 있다.

상술한 목적 및 다른 목적 및 특징은 후술하는 바람직한 양태 및 실시예를 논의하는 과정에서 더욱 분명해질 것이다.

현재 바람직하다고 생각되는 본 발명의 특정 예시적이고 비-한정적인 실시예가 도면에 도시되어 있다. 첨부된 청구의 범위에 대한 참고가 되지만, 본 발명의 범위를 결정하기 위해서 독점권은 청구의 범위에 기재되어 있다.

도 1은 본 발명에 따른 소스-수신지의 데이터 전송 관계(예를 들어 서버-클라이언트)를 예시한 블록 다이어그램으로서, RTP 데이터 콘텐츠 구성 부품은 RTSP 및/또는 RTCP 제어 신호 전달을 처리하는 중앙 처리장치와 같은 제어 포인트 주위로 경로 배정되어 있다.

도 2는 본 발명에 따른 스트리밍 제어기를 도시한 블록 다이어그램이다.

도 3은 RTP 헤더에서의 구성 부품의 값을 도시한 표이다.

도 4는 본 발명의 예시적인 실시예에 따른 지정 파일을 도시한 데이터 표 다이어그램이다.

도 5는 오락 시스템인 "HANS"에 부착되어 있는 홈 네트워크의 구성 부품을 도시하고 있는 블록 다이어그램으로서, 본 발명의 규정을 처리하는 패킷 데이터를 포함하도록 구성되어 있다.

RTP는 자원 예약(resource reservation)에 대해서 주소 지정을 하지 않으며, RTP 프로토콜 수준에서 접속이 유지되고 있으며 패킷이 분실되지 않았다든가 하는 등을 확인하는 것과 같이 실시간 서비스에 대한 서비스 품질을 보증하지 않는다. 데이터 프로토콜, 즉 RTP는 제어 프로토콜(RTCTP)에 의하여 증분되며, RTCP는 세션 제어(즉 소스로부터 수신지로의 RTP 전송) 및 또한 전체 프레젠테이션 제어 프로토콜(RTSP)을 위하여 사용될 수 있다.

예를 들어 전송 경로를 설정하거나 닫는(tear down) 경우, 일방(PLAY) 또는 다른 방향(기록)에서 전송을 개시하는 경우, 전송 중단 등의 경우에 RTCP 및 RTSP 제어 프로토콜은 신호 패킷(signaling packet)을 포함한다. 일부 동기 참조(synchronizing reference)와 함께 실시간으로 연속적으로 가능하다면, 콘텐츠 데이터 패킷은 스트리밍 될 필요가 있다. 콘텐츠 패킷은 RTCP 및 RTSP 패킷과 동시에 전송되지만, 3개 각각의 프로토콜의 패킷은 다르게 주소지정된 논리 접속 또는 소켓을 사용한다.

RTCP/RTSP 제어 프로토콜 및 RTP 데이터 스트리밍 프로토콜은 함께 대규모의 멀티캐스트 네트워크로 계위가능한(scalable) RTP와 RTCP는 그 기저에 놓여 있는 전송 및 네트워크 계층(layer)과 독립적으로 설계되기 때문에 다양한 선택적인 계층과 함께 사용될 수 있다. 원하는 경우, 그 프로토콜은 RTP-수준의 번역기 및 믹 서(mixer)의 사용을 또한 지원한다.

RTP 제어 프로토콜(RTCP)은 서비스의 품질을 관리하고(monitor) 진행 중인 세션에서 참여자에 관한 정보를 전달할 수 있는 능력을 갖는다. 참여자 정보(participant information)는 "느슨하게 제어되는(loosely controlled)" 세션에 대해서 충분한데, 예를 들어 명백한 회원(membership) 제어 또는 설정이 없는 경우에 주어진 응용 프로그램은 더욱 엄격한 인증이나 통신 요구 조선을 가질 수 있고 이러한 점은 일반적으로 RTSP 세션 제어 프로토콜의 영역이다.

소스와 수신지 사이에서 스트리밍 되고 있는 RTP 데이터 콘텐츠 패킷은 실시간으로 수신지 주소를 향하여 매우 단순하게 통과된다. 패킷은 실시간으로 통과되는 반면에, 수신 장치에서 버퍼링 저장을 위한 필요는 거의 없다. 동일한 이유로, 전송 장치는 통상 임시 파일을 생성할 필요가 없다. HTTP 객체 전송과 같은 다른 일부의 프로토콜과 달리, RTP는 매체-특이적 헤더를 사용하여 객체를 패킷 단위로 분할한다. RTP 수신기는 시그널링 능력을 재시도하기보다는 패킷 손실로부터 회복될 수 있도록 구성되어 있다. RTP 전송은 TCP/IP 접속이 없는(connetion-less) 프로토콜을 채택할 수 있다. 통상적으로, RTP 데이터의 사용자 다이어그램 전송(UDP) 패킷 전송과 함께 수행되지만, 일반적으로 하나의 RTP 패킷을 구성하는 각각의 UDP 패킷과 반드시 수행되지 않는다.

RTP 패킷은 RTP로서 패킷을 확인하는 고정 헤더, 패킷 처리 번호(sequence number), 타임스탬프(timestamp), 동기 소스 식별, 소스 식별자에 기여하는 가능한 빈 리스트(possibly empty list), 및 페이로드(payload) 데이터를 갖는다. 페이로드 데이터는 음성 샘플 또는 압축 영상 데이터와 같은 주어진 데이터 값의 카운트(count)를 함유한다.

RTP 스트리밍 시스템은 별도의 실시간 데이터 콘텐츠 패킷(RTP), 제어 패킷(RTCP) 및/또는 세션 제어 패킷(RTSP)을 사용한다. 관리 패킷(RTCP, RTSP)는 하나 이상의 접속을 통하여 RTP 콘텐츠 패킷을 전달할 수 있는 접속과 관련된다. RTCP 및 RTSP 접속은 그 RTP를 "끼우는(socket)" 다른 접속을 포함하는데, 더욱 중요하게는 그 패킷은 주파수(frequency) 및 기능에서 상이하다.

네트워크 접속된 오락 시스템, 화상 회의 시스템, 네트워크에 부착된 저장 장치 등과 같은 수신기 내에 처리장치를 제공할 수 있으며, RTP 패킷과 RTCP 또는 RTSP 제어 패킷 사이를 적절하게 구분할 수 있도록 그 처리장치를 프로그램할 수 있다. 데이터 패킷은 그 수신지를 향해 통과되며, 다른 프로그램화 되어 있는 정보의 기능 및 전송을 수행할 수 있도록 제어 패킷이 그 처리장치에 의하여 사용된다. 그러한 시스템이 보조를 맞출 수 있도록, RTP 콘텐츠 패킷은 실시간으로 처리되어야 하는데, 만약 중앙 처리장치가 패킷이 발신됨에 따라 삽입되는 필드를 포함하는 패킷의 세부사항을 관리하고자 한다면, 그 처리장치는 고속 데이터의 속도로 작동하여야 한다.

스트리밍 환경에서 제어 패킷은 포맷과 무관하고 다수의 종점을 포함하고 있는 하나 이상의 데이터 방향에서 다양한 접속 시나리오로 향할 수 있다. 중앙 처리 장치는 잠재적으로 관련된 중앙 처리장치를 처리하는데 요구되는 계산 복잡성 및 프로그래밍를 필요로 한다. 만약 실질적인 계산 복잡성(예컨대 복잡 프로그램)을 실행할 수 있는 주어진 처리장치가 RTP 콘텐츠 패킷을 통과시키기 위하여 단순히 사용된다면, 고속 데이터 속도 및 복잡한 계산 성능이 요구된다. 그러나, 하나 또는 몇 개의 쉽게 구별될 수 있는 접속이 이루어지는 상태에서 처리장치가 RTP 패킷을 차례차례 통과시키는 데 그 작동 성능의 대부분을 소모한다면, 비록 빈번하지는 않다고 하더라도, 복잡한 제어 계산을 처리하기 위한 계산 성능이 낭비된다.

본 발명의 일 관점은 현재 진행중인 패킷의 통과, 즉 패킷 출구와 관련하여, 중앙 처리장치에 의하여 개발된 계산 결과가 덜 복잡하지만 하지만 더욱 신속한 하드웨어 장치로 통과될 수 있는 방법을 제공하는 것이다. 이러한 목적은 본 발명의 지정 파일 기법을 사용하여 달성된다.

도 1은 서버(즉 스트리밍 데이터의 소스)와 클라이언트(수신지) 사이에 배치되어 있는 제어 포인트를 갖는 간단한 네트워크 환경을 도시하고 있다. 각각의 상호접속은 RTP 스트리밍을 위하여 다양한 지원 패킷 형태로 표시되어 있다. 본 발명은 제어 포인트를 포함하는 다양한 구성으로 광범위하게 응용될 수 있으며, 기재된 것처럼 하드웨어 가속기를 사용하여 메시지 헤더 내의 필드가 교체되는 기술을 제공함으로써, 적어도 부분적으로 그 제어 포인트에서 처리를 위한 필요성을 회피한다.

도 2는 네트워크를 경유하여 패킷 소스(서버로 도시)로 연결되어 있는 중앙 처리장치에 의하여 제어 포인트가 표현되는 예시적인 상황을 도시하고 있다. 도시된 구성에서, 일련의 패킷에서 확인된 패킷을 패킷 소스로부터 하나 이상의 주소지정된 수신지로 향하게 함으로써, 예를 들어 예를 들어 트래픽 관리기(manager)/중재기(arbiter)를 통하여, 중앙 처리 장치는 일반적으로 패킷을 하나 이상의 수신지, 본 실시예에서 디스크 메모리 및 그 제어기로 표시되어 있는 네트워크 접속 저장 소자(network attached storage element), 또는 판독 장치 등과 같은 하나 이상의 수신지로 통과시키는 것이 요구된다.

본 발명의 특징에 따르면, 패킷 데이터는 네트워크 가속기의 형태로 인터페이스 장치에 의해서 부분적으로 취급된다. 네트워크 가속기는 그 취급 및 다른 후속 처리 과정을 제어할 수 있도록 RTP 패킷을 포함하는 데이터 블록으로 값을 삽입할 수 있도록 구성되어 있으며, 최소한 정교한 연산 능력을 갖춘 고속 처리 장치(high throughput device)로 구현될 수 있다. 이러한 목적을 위해서 지시 파일(directing file)이 생성되며, 지시 파일은 전체 헤더 섹션을 포함한다. 전체 헤더 섹션에는 확인 코드와, 패킷 카운트, 헤더 블록 크기 및 처리되어야 하는 RTP 헤더의 데이터 내에서의 위치를 확인하는 포인터 및/또는 길이 값을 포함하는 일련의 값을 함유하고 있다.

이 실시예에서 특정 소스 및 수신지 실체(entities)는 대표적인 예이다. 본 발명은 도시된 것과 같이 다소간 근접해 있거나 원거리에 있을 수 있거나 또는 데이터 통신에서 연결되어 있는 다양한 잠재 소스 및 잠재 수신지를 포함하는 상황에 응용될 수 있어, 주어진 시간에 그러한 2개의 실체 사이에서 일방향 또는 양방향으로 통과하는 패킷의 소스 또는 수신지로서 기능하게 된다. 이 특정 실시예에서 콘텐츠 신호가 재생 장치(playback device)로 표시되거나 또는 동시에 기록되는 상황에서 패킷의 통과를 위해서 배열될 수 있다. 다른 실시예에서, 데이터가 기록되지만 재생되지 않는 경우 또는 재생되지만 기록되지 않는 데이터 플로 배치가 설정될 수 있다. 다른 특정 소스 및 수신지 구성 성분이 포함될 수 있다. 동일한 착신 패킷은 하나의 소스로부터 2 이상의 수신지로 경로 지정될 수 있다. 선택적으로, 2 이상의 소스로부터의 콘텐츠는 예를 들어 화면-속-화면(picture-in-picture) 삽입으로서 통합(coordinated) 저장 및 재생을 위해서 지정되거나, 또는 예를 들어 원격화상회의를 하는 경우에 동시 병렬 디스플레이(simultaneous side by side display)를 위해서 지정될 수 있다. 이러한 그리고 다른 유사한 응용이 본 발명에 따르면 매우 용이하게 가능해진다.

데이터 흐름은 3개의 메인 타입으로 구분될 수 있는데, 즉 전체 프레젠테이션 제어를 위한 RTSP 패킷, 각각의 세션 제어를 위한 RTCP 패킷과 데이터 콘텐츠 전송을 위한 RTP 패킷이다.

RTSP는 하나 또는 다수의 병행 프레젠테이션 또는 데이터 전송을 제어하는데 사용되는 응용-계층 프로토콜이다. 단일 RTSP 접속으로 여러 개의 RTP 객체전송을 병행 및/또는 연속적으로 제어할 수 있다. 예를 들어 다수의 위치를 갖는 화상 회의 배치에서, 각 1쌍의 위치 사이에서 양방향 전송이 배치될 수 있다. RTSP의 구문(syntax)은 HTTP/1.1.의 그것과 유사하지만, 매체 전송에 특유한 규약을 제공한 다. 세션을 정의하는 주요 RTSP 명령어는 다음과 같다:

- SETUP : 서버가 스트림을 위한 자원을 할당하도록 하며 RTSP 세션을 개시한다.

- PLAY 및 RECORD : 소스로부터 수신지로 SETUP을 통하여 할당된 스트림 상에서 데이터 전송을 개시한다

- PAUSE : 서버 자원을 제거하지 않고 스트림을 일시적으로 중지한다

- TEARDOWN : 스트림과 연관된 자원을 제거한다. 서버에서 RTSP 세션의 발신을 중단시킨다.

RTSP SETUP 요청을 사용하여 제어 포인트가 객체 전송을 요청하는 경우, 제어 포인트는 사용되었던 객체 확인, 소스 및 수신지 IP 주소 및 프로토콜 포트 및 전송-수준 프로토콜(일반적으로 RTP 및 TCP 또는 UDP)를 포함하는 객체 전송의 세부사항을 포함하는 요청을 서버와 클라이언트로 전송한다. 이러한 방법으로, RTSP 요청은 클라이언트와 서버로 세션을 설명한다. 일부의 경우에, 그 요청은 객체의 음성 또는 화상 성분과 같이 이용가능한 객체의 부분(subset)에 특이적일 수 있다.

모든 필요한 SETUP 요청이 수행되고 인증되는 경우, 제어 포인트는 전송 방향에 따라 PLAY 또는 RECORD 요청을 송신한다(issue). 그 요청은 선택적으로 전송되어야 하는 객체의 일정 범위, 객체의 일반적인 플레이 시간, 및 재생이 시작되어야 하는 지역 시간을 지정할 수 있다.

재생이 완료된 후, PAUSE 명령이 송신됨에도 불구하고, 프레젠테이션은 자동으로 중지된다. PAUSE 명령이 송신되면, 그 명령어는 스트림이 중지되어야 하는 타임스탬프(timestamp)를 명시하고, 서버(클라이언트)는 후속 PLAY(RECORD) 요청이 송신될 때까지 데이터 전송을 중단한다.

TEARDOWN 요청이 송신되는 경우, 명시된 스트림 상에서 데이터 전송이 중단되고, 모든 연관된 세션 자원이 제거된다.

RTSP 명령어는 대역외(out-of-band) 전송 세션을 명시할 수 있는데, 이 경우 RTP/UDP 또는 RTP/TCP가 전송을 위하여 사용된다. "대역외" 전송은 2개 이상의 별도의 전송 또는 접속 경로를 의미한다. 그 경우에 RTSP 트래픽은 하나의 접속에서 이루어질 수 있고, RTP 데이터의 실제 전송을 수행하기 위하여 RTSP에 의하여 다른 접속이 명시될 수 있다.

RTP 패킷은 TCP를 통하여 전송될 수 있다. TCP 전송과 달리, UDP 전송은 접속이 유지될 것을 요구하지 않으며, 분실된 패킷에 민감하지 않고/않거나 분실된 패킷을 탐지하여 분실된 패킷으로부터 회수하려고 시도하지 않기 때문에 일반적으로 비효율적이다. UDP 전송 프로토콜은 음성 또는 화상 데이터 샘플 값과 같은 패킷을 실시간으로 전송하는데 적합하다. 이러한 값들은 개별적으로 중요하지는 않지만 고속 데이터 양으로 이동할 필요가 있다. 접속이 설정되고 재전송을 획득하는 등의 방법으로 패킷 분실을 회수하려고 하는 것과 같이 신뢰성을 강조한다는 점에서 TCP 프로토콜은 UDP와 다르다. 이러한 특징은 UDP와 비교해서 RTP의 필요에 적 게 일관적이다. 그러한 공개(disclosure)는 UDP가 RTP 전송을 위해서 사용될 것이라고 일반적으로 가정한다. 그러나 그 공개는 바람직한 UDP 전송으로 한정되는 것으로 간주하여서는 안 되며, 오히려 다른 프로토콜로서 TCP 및 다른 프로토콜을 포함한다.

서버가 RTP를 사용하여 전송된 객체에 대한 요청을 수신하면, 통상적으로 객체는 원래의 포맷에서 패킷 단위로 분할된 포맷으로 변경된다(transcended). 기술된 것과 같이 또는 주어진 다양한 매체 타입에 대하여 연관된 RFC를 포함하여, 예를 들어 인터넷 엔지지어링 태스크포스(ieft.org)에 의해서 온라인 접근을 위하여 유지되는 데이터를 패킷 단위로 분할하는 것과 관련된 문제점을 해소할 수 있도록 당업계에서 많은 수의 "인터넷 기술 관련 문서(Request for Comment, RFC)" 메시지 스레드(message threads)가 개발되었다.

각각의 매체 객체 형태는 통상적으로 약간 다르게 패킷으로 분할되는데, 관련 RFC에서 제공되는 표준화된 지시사항에 따르면 형태에 따라 다른 헤더 포맷을 갖는 경우도 있다. 그러한 차이점은 다른 용도를 갖는 데이터를 취급하는 경우에 직면하는 다른 객체 및 문제점에 기인한다.

도 3은 예컨대 RFC 3550/3551에 기재되어 있는 통상의 RTP 헤더 포맷을 도시하고 있다. 헤더 필드의 약자는 다음과 같다.

"V"는 버전 번호를 나타낸다. 현재의 버전은 버전 2이다. RTP 포맷에서와 같 이 패킷을 유일하게 식별하는 헤더에서 고유한 것은 없을지라도, 이 헤더 위치에서 버전 번호 "2"의 표시는 하나의 지시자(indicator)이다.

"P"는 무시되어야 하는 페이로드의 끝단에 임의의 채움 처리(padding)가 존재하는지를 지시하는 값으로서, 만약 채움 처리가 존재하는 경우에는 채움 처리의 정도를 나타낸다. 채움 처리 값의 마지막 바이트는 채움 처리 바이트의 전체 숫자를 부여한다.

"X"는 연장 헤더(extension header)가 존재하는지의 여부를 보여주는 값이다.

"CC"는 이 헤더에서 확인되는 기여 소스(contributing source)의 숫자 카운트이다.

"M"은 마커 비트이다. 이 비트의 구현은 페이로드 형태에 특이적이다.

"PT"는 페이로트 형태, 즉 전송되는 객체 형태를 식별한다. 다른 것 중에서도, 페이로드 형태의 식별자는 수신자가 RTP 스트림을 종결하는 법을 결정할 수 있도록 허용한다.

"처리 번호(sequence number)"는 전송된 RTP 패킷 수의 카운트이다. 전송된 바이트의 수를 지시하기 위하여 처리 번호를 사용하는 TCP와 다르다는 점에 주목하여야 할 것이다. RTP 처리 번호는 전송된 패킷의 수, 즉 패킷 인덱스(packet index)이다.

"타임스탬프(timestamp)"는 페이로드 형태에 따라 변하는 필드 값이다. 통상적으로, 전송되는 패킷에 대한 시간 인덱스를 제공하고, 일부의 경우에는 수신자가 패킷 콘텐츠를 기록 또는 재생할 때 수신자로 하여금 타이밍 조건(timing condition)에 적응하도록 허용하는 참조(reference)를 제공한다.

"SSRC ID"는 전송되는 데이터의 소스를 식별한다.

"CSRC ID"는 혼합기(mixer), 번역기(translator) 등과 같이 전송되는 데이터를 처리하고 있는 임의의 기여 소스 또는 소스들을 식별한다. 다수의 기여 소스가 있을 수 있거나 또는 SSRC ID에서 식별되는 원래의 소스 외에는 존재하지 않을 수 있다. 위에서 언급한 것과 같이, 헤더에서 CC 값은 기여 소스 카운트를 제공한다. 이 카운트로 인하여 한정되지 않은 수의 기여 소스 식별이 처리되고, 헤더가 뒤에 수반되는 콘텐츠를 향하여 그 기여 소스 식별이 진행되도록 한다.

만약 X 비트가 설정되면, 그 RTP 헤더에 수반하는 연장 헤더가 존재한다. 연장 헤더의 용도 및 특성은 페이로드-형태에 달려 있다. 패킷 분실이 완화되는 방법으로 페이로드-특이적 서브헤더가 일반적으로 명시되어, 패킷 분실이 일어나는 일부 경우에까지 견딜 수 있게 된다. MPEG2와 같은 일부 포맷에 대해서, 영상 및 음성 암호화(encoding) 정보를 갖는 많은 복잡한 서브헤더가 메인 RTP 헤더에 수반될 수 있다.

페이로드는 도 3에 도시된 것과 같이 패킷에서 마지막 서브헤더 다음에 온다. 원래의 미디에 객체에 대한 페이로드의 관련성은 그에 상응하는 페이로드 형태를 기술하는 표준에 의해서 결정된다. 원래의 객체와 RTP 패킷 페이로드를 결합(concatenation)하는 것은 종종 1대1로 대응되지 않는다. 이러한 점에 기여할 수 있는 다양한 요소가 있을 수 있지만, RTP 패킷 페이로드 서열과 원래 객체 내의 포함된 바이트 서열 사이에서 차이를 일으키는 상황의 예로는 다음과 같은 것을 들 수 있다.

- 주어진 프레임에 대하여 음성 및 영상 정보를 동기화할 필요성

- RTP 페이로드 내에서 데이터 블록의 끼워넣기(interleaving)

- 중용한 데이터 성분에 대한 반복 패킷

- 음성/영상

- 또는 1.1.3 RTCP

주기적으로 주어진 RTP 세션이 활성화되는 동안, 주어진 세션에 관한 제저 정보는 RTCP를 사용하는 별도의 접속에서 교환된다((UDP에 대해서, RTP 세션은 짝수 수신지 포트를 사용하며 RTCP 정보는 인근의 한층 높은 홀수 수신지 포트를 통하여 전달된다.). RTCP는 데이터 분배의 품질에 대한 피드백을 제공하는 것을 포함하는 다양한 기능을 수행하는데, 피드백 제공을 통하여 특히 IP 멀티캐스트 전송의 경우에 네트워크 무제가 국소적인지 아니면 글로벌한 것인지를 서버가 결정하는데 유용할 수 있다. RTCP는 또한 RTP 소스에 대한 영속 전송-수준 식별자, 즉 CNAME를 전송하도록 작용한다. 충돌 또는 프로그램 재시작으로 인하여 SSRC IDS의 이송(migration)이 일어날 수 있으므로, 수신자는 각각의 참여자를 추적하는 CNAME를 필요로 한다. CNAME는 또한 다양한 RTP 세션으로부터 다중 관련된 스트림을 동기화(예컨대 음성 및 영상을 동기화)하는데 사용될 수 있다.

RTCP 패킷을 전송하기 위해서는 전송 중의 모든 참여자가 요구된다. 세션 내의 참여자의 수가 증가하게 되면 바람직하게 각각 전송되는 패킷의 수는 그에 비례하여 감소한다. 각각의 참여자가 그 RTCP 패킷을 다른 모든 참여자에게 전송하도록 함으로서, 각각의 참여자는 참여자의 숫자를 추적할 수 있다. 이 숫자는 이어서 제어 패킷이 전송되는 속도를 측정하는데 사용된다. RTCP는 사용자 인터페이스에 현시되는 참여자 정보와 같은 최소한의 세션 제어 정보를 전달하는데 사용될 수 있다.

이러한 임무를 달성하기 위해서, RTCP 패킷은 이하의 카테고리 및 포맷 중의 하나에 속할 수 있다.

- SR: 활성 전송자인 참여자로부터 전송 및 수신 전략을 위한 전송자 보고(sender report);

- RR: 활성 전송자가 아니고 34개 이상의 소스를 보고하는 활성 전송자를 위한 SR과 결합하는 참여자들로부터 수신 전략을 위한 수신자 보고(receiver report);

- SDES: CNAME를 포함하는 소스 기술 아이템(source description item);

- PP: 응용-특이적 기능

RTP와 마찬가지로, 각각의 RTCP 패킷 형태는 공통 헤더로 시작하여, 다양한 길이를 갖는 서브 헤더가 수반된다. 하위-계층 프로토콜의 단일 패킷에서 함께 전송될 수 있는 복합 패킷(compound packet)을 형성할 수 있도록 다중 패킷이 연결될 수 있다. 이런 다중 패킷의 연결을 통하여 스트림 내의 예상되는 필드의 위치를 구별할 수 있도록 다양한 카운터 및 포인터를 위한 필요가 생기게 된다.

스트리밍 패킷과 함께 특정 카운팅 및 인덱스 포인터값을 함유하는 지정 파일을 포함함으로써, 특히 출구 스트리밍을 촉진할 수 있도록, RTP 포맷에서 데이터 스트리밍의 처리를 최적화하는 것이 본 발명의 특징이다.

RTP 패킷의 출구 스트리밍은 실시간으로 지원되어야 한다. 실시간 처리가 RTP 프로토콜의 중요한 특징인데, 스트림의 발신 특성으로 인하여 RTP 프로토콜은 버퍼(또는 적어도 그 크기)에 대한 필요성을 감소시킨다. 본 발명은 하드웨어에 특정 RTP 패킷 정보를 직접 제공할 수 있는 변형된 암시(variation of hinting)를 채택하고 있다. 이러한 방식의 암시는 서버가 작동 중의 스트리밍되고 있는 맥체를 분석하여야 하는 필요성을 제거하기 때문에 서버에서 RTP 스트리밍을 가속화한다.

"암시"는 MPEG-4와 같은 압축 영상과 함께 암호화되는 정보를 언급하는데 종종 사용되는 용어인데, 데이터로부터 별도로 복원되도록(decopressed) 전송되며 관련 압축 영상 데이터를 압축해제하는데 도움이 되도록 암시 데이터를 분석(parsing) 할 수 있는 전용 장치에 의해서 통상적으로 사용된다.

본 발명에 따르면, 전체 헤더 및 헤더 블록으로서 보충 정보 파일이 제공된다. 이 경우에 전방향 또는 역방향-관련 영상 파일의 특정 포맷을 처리하기 위하여 전용 하드웨어가 암시 데이터를 분석할 필요가 없다. 대신, 지정 파일은 RTP 헤더 와 패킷 정보를 위치시키는 인덱스로서 사용되는 일련의 카운팅 및 포인팅 값이다.

포인터 정보는 유연하게 표시된다는 점에서, 즉 향후 확장을 고려할 수 있도록 다른 패킷 데이터 포맷을 표시할 수 있다는 점에서, 지정 파일은 복원 암시 메커니즘 등과는 다르다. 인터페이싱 파일에서 유연성을 제공하게 되면 처리장치로부터 스트리밍 기능성의 가동 부분에 어려움을 야기할 수 있어서, 대부분의 파라미터가 고정되어 있는 하드웨어 성분으로 다른 포맷을 식별하도록 처리장치가 프로그램될 수 있다. 본 발명의 방법은 하드웨어에 의하여 사용될 수 있는 보충 지정 파일 내에 (매체 객체 그 자체를 제외한) 필요한 모든 정보를 포함하고 있으므로 이러한 문제점을 해결하고 있는데, 이는 부분적으로 지정 파일은 알려진 오프셋과 다른 예측으로 포맷이 되어 있는 정보에 역행하는 인덱싱 포인터를 함유하고 있기 때문이다.

만약 미디어 파일이 명시된 RTP 패킷 형태 (일반적으로 RFC 또는 언급된 상세화로 이끄는 명령어 쓰레드에 의하여 첨부되는)를 가지고 있으며 스트리밍 장치에 접근할 수 있고 스트리밍을 위한 후보가 아니라면, 소프트웨어에 의하여 중앙 처리 장치에서 작동하는(자원이 이용가능하다면 바람직하게는 백그라운드에서 작동하는) 지정 파일이 우선 생성된다.

지정 파일은 RTP 스트리밍을 위해서 객체를 패킷으로 분할하는 법을 스트리밍 장치에 알려준다는 점에서 암시 데이터와 유사하지만, 그렇게 하는 방법에 관해서는 훨씬 더욱 특이적이며, 중앙 처리장치는 원래의 미디어 객체에 관하여 훨씬 적은 지식이 있다고 가정한다. 예시적인 지정 파일 45 (바이너리 파일)의 포맷이 도 4에 도시되어 있다.

도 4를 참조하면, 전체 헤더는 파일의 처음에만 명시되어 있고, 전체 블록에 응용된다. 전체 헤더는 다음을 포함하고 있다:

-지정 파일의 올바른 포맷인지를 스트리밍 장치가 확인할 수 있도록 하는 버전/인증(version/authentication) 필드,

- 전체 파일이 사용된다면 전송될 패킷의 수를 명시하는 전체 패킷 필드의 수(Total Number of Packets field),

- 지정 파일 내에서 각각의 헤드 블록에 대하여 할당되는 바이트의 수를 명시하는 지정 파일 헤더 블록 크기.

지정 파일 45에 의한 전송을 위해서 명시된 각각의 패킷에 대하여 헤더 블록이 명시되어 있다. 헤더 블록은 주어진 지정 파일 45에 대해서 고정된 길이를 가지고 있다. 헤더 블록은 다음과 다음을 포함하고 있다:

- payload.ptr: 메모리 내의 객체의 시작으로부터 현재 패킷 페이로드의 오프셋을 함유하는 파일

- body.skip: 유효한 RTP 페이로드가 시작될 때까지 현재 큐 위치로부터 (만약 존재한다면) 건너뛰어야 할 바이트의 개수를 지정

- body.length: RTP 페이로드의 길이를 지정

- header.length: 현재 RTP 패킷에 사용하는 RTP 헤더 필드의 바이트 숫자를 지정.

지정 파일이 생성되면, 특정 객체와 관련될 수 있도록 지정 파일이 저장된다. 암시 데이터와 마찬가지로, 하나의 객체가 스트리밍 될 수 있는 다수의 방법이 존재한다면(다른 패킷 형태 또는 동일한 패킷 형태에 대한 다른 네트워크 특성), 다중 지정 파일이 하나의 객체와 연관될 수 있다.

단지 I-프레임으로만 또는 모든 N-프레임(N은 지정 파일 45에 의하여 명시되는 고속 정방향 속도와 관련 있다)에 대해서만 가리키는 지정 파일을 생성함으로써, 이러한 사실의 확장을 통하여 스트리밍 장치가 Trick-Play 기능을 용이하게 구현할 수 있도록 한다.

만약 대응하는 RTP 세션이 아직 설정되지 않은 경우라면, 중앙 처리장치에서 작동하는 RTSP가 말단으로부터 수신된 SETUP 명령을 제공할 때까지 그 장치는 중지된 채로 남아 있게 된다. 일단 RTSP가 SETUP 메시지를 수신하면, 처리장치는 SETUP 메시지로부터 일련의 교착(lockup) 파라미터(소스 및 수신지 IP 주소 및 포트, 전송 프로토콜)을 결정하여, 하드웨어 가속기와 연관되어 있는 콘텐츠 주소지정 메모리(CAM) 내에서 그 세션에 대한 접속 테이블 엔트리(connection table entry)를할당한다. CAM 내에서 그 RTP 세션에 대한 유효 비트가 즉시 설정된다. RTSP는 관련된 제어 포인트로부터 차후의 PLAY 요청을 기다린다. PLAY 메시지는 스트림이 작동하는 (시간) 범위를 포함할 수 있다.

이 시점에서, 세션은 확립되도록 고려될 수 있으며, 네트워크 가속기와 트래픽 관리자는 데이터를 전송할 준비가 되어 있다. 트래픽 관리자는 각각 RTP 세션을 위하여 2개의 연관된 큐를 갖는데, 원래의 미디어 객체로부터 데이터를 전송하는데 사용되는 객체 큐(Object Queue)와, 지정 파일로부터 판독되는 RTP 헤더를 전송하는데 사용되는 헤더 큐(Header Queue)이다. 전송되는 각각의 RTP 패킷에 대하여, RTP 헤더와 페이로드를 추출하기 위하여 지정 파일의 필드를 사용하여 결과적으로 생성된 패킷의 일람표를 작성한다(schedule). 이어서 트래픽 관리자는 그 패킷을 네트워크 가속기로 전송한다.

네트워크 가속기의 작동은 다음과 같은 단계를 포함한다:

- 중앙 처리장치에 의하여 결정되어 연관된 전송을 위하여 CAM 접속 테이블 엔트리 내의 필드로 저장된 오프셋을 발신 패킷의 RTP 헤더의 처리 번호 필드로 추가한다. 이 단계는 바람직하게는 RFC 3500에서 명시된 것과 같이 무작위 ISS를 제공하기 위한 것이다.

- 유사한 방식으로 발신 타임스탬프를 조정한다. 이 단계는 바람직하게는 RFC 3500에 명시된 것과 같이 무작위 ITS를 제공하기 위한 것이다.

- 계층 및 및 계층 4의 헤더를 구성하고 발신 패킷으로 적용(예컨대 첨가(pre-pend))한다

- 발신 패킷을 MAC/PHY 블록으로 전송한다.

이러한 방법을 통하여 네트워크 가속기가 원래의 미디어 객체 포맷에 대한 어떠한 지식을 가질 필요 없이 미디어 객체가 스트리밍 될 수 있게 된다. 지정 파일은 바람직하게는 중앙 처리장치에서 작동하는 소프트웨어에 의하여 생성되기 때 문에, 새로 출현한 패킷 형태는 소프트웨어 배치에 의하여 용이하게 수용될 수 있다. 이 방법으로 인하여 스트리밍 장치의 반복적인 데이터 파이프라인 기능이 중앙 처리장치로부터 더욱 하드웨어-지향적인 네트워크 가속기로 넘겨줄 수 있도록 기여한다. 그럼에도 연산이 복잡하지 않은 이러한 반복 데이터 파이프라인 기능은 높은 순위의 시간 우선권을 갖는다. 본 발명은 네트워크 가속기에서 이러한 기능을 최적으로 작동시키고, 컴퓨터 연산의 복잡성에서 유리할 뿐만 아니라 스트리밍 접속의 데이터 파이프라인 기능의 시간 수요와 종종 양립하기 어려운 제어 지향적이지만 덜-빈번한 요구를 위하여 중앙 처리장치의 성능과 처리 시간을 보유하게 된다.

지정 파일을 사용하여 데이터 패킷을 처리하기 위하여 네트워크 가속기가 미디어 객체 포맷에 대해서 거의 알지 못하거나 전혀 알 필요가 없다는 필요와 병행하여, 지정 정보가 트랙이 아니라 파일 내에 포함되는 것이 바람직하다. 이러한 방법으로, 서버는 특정 발신 패킷 또는 패킷 블록에 대하여 지정 정보를 어떻게 추출해야 하는지에 대해서 알 필요가 없게 된다.

일단 지정 파일 45가 생성되면, 포인터를 사용하여 객체는 임의의 횟수만큼 스트리밍을 위한 요청에 이용될 수 있으며 전체 헤더와 블록 헤더의 카운트 값은 현재 설정된 것이라고 가정되고 있다. 스트리밍 장치는 지정 정보에 접근하여 저장하는 방식을 필요로 하는데, 기술된 것과 같이 포인터와 카운트를 갖는 파일을 사용하는 것이 편리하다. 출구 스트리밍 지정 파일 45가 말단지점으로 전송될 필요가 없다는 점에서 추가적인 이익이 제공되는데, 패킷 또는 패킷 블록을 말단지점으로 전송하는 스트리밍 장치로부터 출구와 접속하는데 사용되는 정보가 필요가 없기 대 문이다.

단지 하드웨어만의 해결책 또는 소프트웨어만의 해결책을 제공하는 대신에 하드웨어 및 소프트웨어의 혼합 해결책을 제공함으로써 전체 RTSP/RTP 해결책의 구현을 개선하는 것이 본 발명의 특징이다. 임의의 모든 하드웨어 해결책은 모든 제어 상황 시나리오에 제공된다면 매우 복잡해져야 한다. 반면, 처리장치 그와 같은 복잡성을 취급하는 코딩을 갖는 임의의 모든 소프트웨어 해결책은 완벽하게 이용되지 않을 것이다. 주어진 스트림이 진행된 후의 대부분의 작동을 위해서, 이전 패킷과 동일한 방법으로 주어진 스트림에 대한 연속적인 패킷을 연속적으로 처리하기 위한 많은 작동들은 반복적이고 연산 능력을 요구하지 않는 작동을 사용하여 처리된다.

본 발명은 혼합 해결책의 일부분으로서, 잠재적으로 복잡하고 성능 좋은 소프트웨어 프로그램을 동작시킬 수 있는 제어장치에 의하여 주로 설정되고 배열되지만, 그 제어장치가 설정되는 스트리밍 작동을 실행하기 위하여 접속이 활성화되는 동안에 바람직하게는 하드웨어 장치이지만 반드시 하드웨어 장치는 아닌 네트워크 가속기를 계속 진행시키는 인자, 값 및 포인터를 간략하게 설정한다.

도 5를 참조하면 바람직한 실시예에서, 본 발명은 디스크 어레이 제어 장치를 포함하는 데이터 조작 시스템(data manipulation system)으로 통합되어 있다. 이 장치는 소비자 전자 디지털 미디어 응용, 또는 통신 및 원격회의와 같은 유사한 특징을 갖는 다른 응용을 위한 저장 관리 및 서비스를 수행할 수 있다. 오락 응용에서, 그 장치는 홈 네트워크와, 일반적으로 디지털 미디어(음성, 영상, 이미지)를 저장하기 위한 하드디스크 드라이브(HDDs)로 예시되는 데이터 저장 장치 사이의 인터페이스를 제공한다.

이 장치는 홈 네트워크와 다른 근거리 통신망(LAN)으로 향하는 인터페이스를 위한 통합 10/100/1000 이더넷 MAC 포트를 제공한다. (플래시 카드와 같은) 미디어 입력 장치를 위한 연결 또는 외부 무선 LAN 어댑터의 추가를 통한 무선 홈 네트워크로의 연결을 위하여 USB 2.0 주변 접속 포트가 바람직하게는 제공된다.

바람직한 데이터 조작 시스템은 미디어 아카이브(archive)로의 공유 접근을 위하여 많은 계층 및 기능을 채택하고 있는데, (IP/TCP, IP/UDP 처리를 위하여) 이는 상위 계층 프로토콜 가속 엔진 및 세션-인식 트래픽 관리자를 통해서 이루어진다. 세션 인식 트래픽 관리자는 중앙 처리장치처럼 작동하는데, 본 명세서에서 논의된 것과 같은 RTP 스트리밍을 관리하는 것 외에도, 활성 미디어 세션의 형태에 따라 네트워크 대역폭, 메모리 대역폭 및 디스크-어레이 대역폭과 같은 공유 자원의 할당을 가능하게 한다. 예를 들어, 영상 세션은 이미지 브라우징 세션보다 많은 자원을 수신한다. 또한, 그 대역폭은 시간에 민감한 미디어 세션을 위해서 보증된 대역폭 또는 미디어 아카이브 대량 업로드(bulk upload) 또는 멀티-PC 백업 응용과 같이 시간에 민감하지 않은 응용을 위한 최선-노력(best-effort) 대역폭으로서 할당된다.

데이터 조작 시스템은 관련된 복수 배열 독립 디스크(redundant array of independent disk, RAID)를갖는 고-성능 스트리밍을 포함하고 있다. 스트리밍-RAID 블록은 에러-방지 추가(redundancy)를 위해서 배열될 수 있고 임의의 싱글 HDD의 실패에 대하여 아카이브 상에 저장된 미디어를 보호한다. HDDs는 직렬 ATA(serial ATA, SATA) 디스크일 수 있는데, 상기 시스템의 경우 일례로 8개의 SATA 디스크와 트래픽 관리자 및/또는 중재기 블록을 통하여 최대 64개의 동시 쌍방향 스트리밍을 처리할 수 있는 성능을 포함한다.

상기 데이터 조작 시스템은 본 발명에 대하여 가능한 다양한 응용 장치의 예시이므로, 전체적인 데이터 조작 시스템은 단지 전체적으로 기술되어 있다. 그 장치 내부에는 2개의 독립된 데이터 경로, 즉 수신 경로 및 전송 경로가 존재한다. "수신(receive)" 경로는 다른 외부 장치로부터 그 시스템으로 트래픽이 흘러감으로써 방향이 고려되고, "전송(transmit)" 경로는 데이터 흐름과 반대 방향으로서, 이 경로들은 주어진 스트림의 관점에서 볼 때 몇몇 지점에서 소스로부터 수신지를 향하여 유도된다.

상위 계층 프로토콜(Upper Layer Protocol, ULP)이 기가비트이더넷 제어 장치(Gigabit Ethernet Contoller, GEC) 또는 주변 트래픽 제어 장치(Peripheral Traffic Controller, PTC) 중 어느 하나로부터/어느 하로 데이터 통신으로 연결되어 있다. 패킷 기반이 아닌 전송을 위해서 PTC는 트래픽 관리자/중재기(Traffic manager/Arbiter, TMA)로 직접 인터페이스를 이루고 있다. 패킷 전송은 본 명세서에서 논의된 것과 같은 방식으로 처리된다.

수신 데이터 경로에서, GEC 또는 PTC 블록 중 어느 하나는 물리적 인터페이스로부터 이더넷 패킷을 통상 수신하는데, 일례로 보다 큰 네트워크로부터/네트워크로의 수신을 들 수 있다. GEC는 패킷 통합, 멀티캐스트 주소 필터링 등을 포함하는 다양한 이더넷 프로토콜 관련 점검(checking)을 수행한다. 패킷은 또 다른 처리를 위하여 ULP 블록으로 이동된다.

ULP는 주소를 형성하기 위하여 추출되었던 계층 2, 3, 4의 헤더 필드를 분석한다(parses). 이어서 그 주소에 기초하여 연결 검출(connection lookup)이 수행된다. 그 검출 결과를 사용하여 ULP는 수신된 패킷을 어느 곳으로 전송할지에 대한 결정을 내린다. 기 확립된 연결로부터 전송된 도달 패킷은 TMA에 의하여 사용되는 트래픽 대기(traffic queuing) 목적을 위해서 사전-정의된 큐 ID(Queue ID, QID)로 태그가 붙게 된다. 알려지지 않은 연결로부터 전송된 패킷은 응용 처리장치(AAP)에 의한 또 다른 점검을 필요로 한다. 그 패킷은 특정 QID로 태그가 붙여저서 AAP를 향하여 경로 지정된다. AAP 이후의 도달 패킷의 최종 수신지는 만약 패킷이 미디어 콘텐츠를 수반하는 경우라면 저장을 위한 하드디스크이거나 패킷이 만약 제어 메시지를 수반하거나 또는 패킷이 AAP에 의하여 인식될 수 없는 경우라면 또 다른 점검을 위한 AAP인데, 새로운 큐 ID의 확립을 향하여 잠재적으로 유도된다. 위에서 언급한 상황 중 어느 경우에도, 패킷은 TMA 블록으로 전송된다.

TMA는 공유 메모리 내에 도달 트래픽을 저장한다. 미디어 객체가 전송되는 경우에, 착신 객체 데이터는 메모리 내에 저장되고, 디스크 저장을 위해서 RAID 디 코더 및 엔코더(RAID Decoder and Encoder, RDE) 블록으로 전송된다. TMA는 RDE로 적절한 제어 정보를 제공함으로써 저장 처리를 관리한다. AAP 점검을 위해서 수신된 제어 트래픽 또한 공유 메모리 내에 저장되는데, 이 경우 AAP는 메모리 내의 패킷을 판독할 수 있도록 주어진 접근(access)이다. 또한 AAP는 순서에 맞지 않게 수신된 임의 패킷을 재-정리하기 위해서 이 메커니즘을 사용한다. 공유 메모리 및 디스크의 일부분은 AAP를 위한 프로그램 명령 및 데이터를 포함하고 있다. TMA는 디스에서 메모리로, 메모리에서 디스크로 제어 정보를 전송하는 방법으로 메모리 및 디스크에 대한 접근을 관리한다. 또한 TMA로 인하여 AAP가 현재의 패킷 스트림으로 그리고 현재의 패킷 스트림으로부터 데이터를 삽입하고 추출할 수 있다.

전송 데이터 경로에서, 응용 처리장치(Application Processor) 또는 네트워크 인터페이스를 경유하여 전송될 필요에 따라, TMA는 디스크로부터 처리되도록 예정되어 있는 객체 복원 요청을 관리한다. 그 응용 처리장치로부터 미디어 재생 요청을 수신하면, TMA는 MDC 및 RDE 블록을 통하여 디스크로부터 전송된 데이터를 수신하여 그것을 메모리에 저장한다. 이어서 TMA는 요구되는 대역폭 및 미디어 형태에 따라 그 데이터를 ULP 블록으로 기재한다. ULP는 각각의 발신 패킷에 대한 이더넷 및 계층3/계층4(L3/L4) 헤더로 해당 데이터를 요약한다. 이어서 패킷은 명시된 수신지 포트에 기초하여 GEC 또는 PTC 블록 중 어느 하나로 전송된다.

수신 데이터 경로에서 착신 패킷과 관련해서, 네트워크 가속기의 연결 점검 기능성 부분은 주소 형성, CAM 테이블 점검 및 연결 테이블 점검 기능성 블록을 포함할 수 있다. 착신 패킷 헤더로부터 추출된 정보의 결과로서 부분적으로 CAM 점검 주소가 형성된다. 추출되는 헤더 필드의 세부사항은 사용 중인 트래픽 프로토콜에 달려 있다. 형성되고자 하는 주소는 고유 연결(unique connection)을 표현하여야 한다. 예컨대 IP V4 및 TCP/UDP 프로토콜에서 수행되는 가장 대중적인 인터넷 트래픽과 관련해서, 소스 ID 주소, 수신지 IP 주소, TCP/UDP 소스 포트 번호, TCP/UDP 수신지 포트 번호 및 프로토콜 형태(패킷 헤더로부터 이른바 "5개의 투플(tuple)")가 고유 연결을 정의한다. 만약 패킷이 (IP V6와 같은) 다른 트래픽 프로토콜인 경우라면 연결을 결정하기 위해서 다른 필드가 사용될 수 있다. 다중 프로토콜이 서비스되는 경우에 플래그 및 식별 코드와 같은 적절한 제어를 참조할 수 있어 그 시스템을 "프로토콜 인식" 계층형(hierarchical) 시스템으로 만들게 된다. 예를 들어 그 처리 과정은 3개의 스테이지로 구분될 수 있는데, 각각의 스테이지는 지원되는 프로토콜 수준에 대응한다. 헤더 분석 처리 과정에서 추출되어 주소 형성 처리에서의 하나의 단계로서 도달 패킷을 위한 정보 버퍼 엔트리 내에 저장되는 필드로부터 L3 프로토콜의 버전 번호를 점검할 수 있다. 주소 형성 처리 과정에서 제 2 및 제 3 스테이지와 관련해서, 복합(composite) 하드웨어 테이블이 제공된다. 각각의 스테이지에서 테이블 엔트리 숫자는 그 테이블이 진입하는 단계 및 각각의 스테이지에서 지원되는 다른 프로토콜의 숫자에 달려 있다. 각각의 테이블 엔트리는 항상 콘텐츠 주소지정 메모리(CAM) 엔트리와 위치 숫자 레지스터(position number register)로 구성된다. 각각의 위치 숫자 레지스터는 항상 한 쌍의 오프셋-크기 필 드로 구성된다. 각각의 CAM 엔트리는 그에 상응하는 위치 레지스터에 대한 특정 프로토콜 값을 저장한다. 오프셋은 패킷 헤더의 시작점으로부터 추출되는 필드까지 무시하고 수행하지 않는 바이트 숫자를 명시하고 있다. 크기 필드는 추출되는 니블(nibbles)의 숫자를 명시하고 있다. CAM 필드 및 위치 레지스터 모두에 접근하기 위해서 동일한 주소가 사용된다.

발신 패킷 출구와 관련해서, 본 발명은 위에서 기술한 것과 같은 지정 파일을 채택하고 있는데, 지정 파일은 구성 중 임의의 지점에서 중앙 처리장치로 접근할 수 있는 메모리에 확립되어 있다.

본 발명은 예시적인 실시예와 결합하여 개시되었지만, 독점권이 주장되는 발명의 범위를 결정하기 위해서는 실시예를 논하기보다는 첨부하는 청구항에 대한 언급이 이루어져야 한다.

Claims (18)

1. 적어도 하나의 데이터 패킷 소스로부터 데이터 패킷에 대한 적어도 하나의 수신지로 상기 데이터 패킷을 지정하기 위한 스트리밍 장치로서,

   상기 데이터 패킷 소스 및 상기 수신지와 데이터 통신하는 네트워크 가속기와;

   상기 소스로부터 상기 수신지로의 데이터 패킷의 스트리밍을 제어하도록 작동할 수 있는 제어 처리 장치로서, 적어도 상기 소스로부터 상기 수신지로 데이터 패킷을 스트리밍하는 소정의 단계 동안에 상기 제어 처리 장치로부터 상기 네트워크 가속기를 향하여 통신하는 일련의 파라미터 값을 설정할 수 있도록 프로그래밍 되어 있는 제어 처리 장치와;

   상기 소정의 단계 이후에 상기 소스로부터 상기 수신지로 데이터 패킷을 스트리밍 할 수 있도록 상기 네트워크 가속기는 상기 파라미터 값의 함수로 구성되어 상기 제어 처리 장치와 실질적으로 독립적으로 구성되는 스트리밍 장치.
2. 제 1항에 있어서,

   상기 소스 및 수신지의 적어도 하나는 상기 소스 및 상기 네트워크 가속기가 연결되어 있는 데이터 통신 네트워크를 통하여 상기 제어 처리 장치와 통신하는 클라이언트를 포함하는 스트리밍 장치.
3. 제 1항에 있어서,

   상기 제어 처리장치에 의하여 설정된 파라미터 값은 통신 네트워크를 통하여 상기 제어 처리 장치 및 네트워크 가속기와 데이터 통신하는 적어도 2개의 클라이언트를 확인하는 주소할당 정보를 포함하는 스트리밍 장치.
4. 제 3항에 있어서,

   상기 파라미터 값은 상기 소스와 수신지 중 어느 하나에 의하여 개시된 요청 신호의 함수로서 상기 제어 처리 장치에 의하여 설정되며, 상기 소스 및 수신지에 대한 주소할당 정보를 적어도 포함하는 스트리밍 장치.
5. 제 3항에 있어서,

   상기 파라미터 값은 상기 제어 처리 장치에 의하여 실장된 지정 파일 내에 제공되며, 상기 스트리밍 장치는 상기 제어 처리 장치에 연결된 메모리로서 다수의 병행 스트리밍 작동에 관하여 다수의 지정 파일을 포함하는 메모리를 더욱 포함하는 스트리밍 장치.
6. 제 4항에 있어서,

   상기 파라미터 값은 식별 코드, 패킷 카운트, 헤더 블록 크기 및 포지션 포인터와 카운트 값 중 하나를 포함하는 스트리밍 장치.
7. 제 3항에 있어서,

   상기 파라미터 값은 요청 신호 함수로서 상기 제어 처리 장치에 의하여 설정되고, 상기 데이터 패킷에 대한 식별 코드를 함유하는 범용 헤더로서 상기 제어 처리 장치로부터 상기 네트워크 가속기로 전송되는 스트리밍 장치.
8. 제 7항에 있어서,

   상기 네트워크 가속기는 상기 수신지로 전송되는 패킷을 갖는 상기 범용 헤더를 포함하도록 작동할 수 있는 스트리밍 장치.
9. 제 8항에 있어서,

   상기 네트워크 가속기는 상기 패킷의 스트리밍이 진행됨에 따라 상기 수신지로 전송된 상기 범용 헤더로 제어 정보를 삽입할 수 있도록 작동할 수 있는 스트리 밍 장치.
10. 제 9항에 있어서,

    상기 네트워크 가속기는 패킷 데이터 카운트를 삽입할 수 있도록 작동할 수 있으며, 상기 패킷 데이터 카운트에 의하여 상기 수신지는 수신된 패킷을 지령 할 수 있는 스트리밍 장치.
11. 제 1항에 있어서,

    상기 제어 처리 장치, 상기 소스 및 수신지 중 적어도 하나, 상기 네트워크 가속기는 프레젠테이션 제어 메시지, 각각의 세션 제어 메시지 및 실시간 스트리밍 패킷을 통신하고, 상기 제어 처리 장치는 상기 프레젠테이션 제어 메시지 및 세션 제어 메시지를 처리하고, 상기 네트워크 가속기는 상기 실시간 스트리밍 패킷을 처리하는 스트리밍 장치.
12. 제 11항에 있어서,

    상기 제어 처리 장치는 설정 단계에 의하여 상기 네트워크 가속기에 의한 스트리밍을 제어하며, 상기 설정 단계는

    스트리밍 작동을 위하여 통신 자원이 할당되는 셋업(SETUP)

    상기 적어도 하나의 소스와 상기 적어도 하나의 수신지 사이에서 적어도 하나의 지정에서 스트리밍 작동을 개시하기 위하여 플레이(PLAY) 및 기록 중 적어도 어느 하나;

    이전에 개시된 스트리밍 작동이 정지되는 일시 중단(PAUSE) 및 세션 제거(TEARDOWN) 중 어느 하나로서, 일시 중단에 있어서는 상기 자원의 할당이 보존되는 반면에, 세션 제거에 있어서는 자원이 제거되는 전송 중단 및 세션 제거 중 어느 하나를 포함하는 스트리밍 장치.
13. 제 12항에 있어서,

    상기 제어 처리 장치는 상기 프레젠테이션 제어 메시지에 대해서 RTSP 프로토콜, 상기 각각의 세션 제어 메시지에 대해서 RTCP 프로토콜에 따라 작동할 수 있으며, 상기 실시간 스트리밍 패킷은 TCP 및 UDP 프로토콜 중 적어도 하나를 사용하는 RTP 프로토콜에 따라 작동하는 스트리밍 장치.
14. 실시간으로 콘텐트를 스트리밍 하는 방법으로서,

    패킷으로 나누어진 데이터 콘텐츠를 조합된 헤더 정보로 제공하여 패킷으로 나누어진 데이터 콘텐츠가 그 콘텐츠에 대한 소스 및 수신지 중 적어도 어느 하나 에서 처리되는 단계;

    상기 소스 및 수신지 중 적어도 어느 하나와 데이터 통신하는 제어 처리 장치의 프로그램되어 있는 연산 함수로서, 스트리밍 작동을 개시하고, 스트리밍 작동에 대하여 소스 및 수신지 중 적어도 어느 하나의 주소를 할당하고, 스트리밍 작동에서 일시 중단(pause) 및 중지(stop) 중 적어도 어느 하나를 수행하는 단계로서,

    상기 제어 처리 장치는 스트리밍 작동이 진행되는 동안에 적어도 일시적으로 유지되어 있는 정보를 함유하는 지정 파일을 설정할 수 있도록 상기 프로그램되어 있는 연산에 따라 작동할 수 있으며,

    스트리밍 작동 개시 후, 상기 지정 파일로부터 제공된 정보를 처리하고 상기 스트리밍 작동이 진행됨에 따라 처리되는 네트워크 가속기의 작동에 의하여 스트리밍 작동 정보에서 수행되는 단계를 포함하는 스트리밍 방법.
15. 제 14항에 있어서,

    상기 네트워크 가속기는 상기 지정 파일로부터 얻어진 정보를 스트리밍 작동하는 동안에 전송된 패킷 헤더로 삽입하는 스트리밍 방법.
16. 제 15항에 있어서,

    상기 네트워크 가속기는 상기 패킷 헤더로 주소 할당 정보, 및 패킷 데이터 카운트와 패킷 데이터 포인터 중 적어도 어느 하나의 정보를 삽입하는 스트리밍 방법.
17. 제 16항에 있어서,

    사기 스트리밍 작동의 개시 후에 상기 제어 처리 장치의 프로그램 연산에 의하여 스트리밍 작동을 변경하는 단계를 더욱 포함하는 스트리밍 방법.
18. 제 14항에 있어서,

    상기 제어 처리 장치를 통하여 다수의 지정 파일을 설정하고 유지하는 단계를 더욱 포함하고, 각각의 지정 파일은 병행 작동하는 적어도 하나의 스트리밍 작동에 관한 것인 스트리밍 방법.

Images