KR100926007B1 - 스트리밍 및 제어 처리를 위한 별도의 구성을 이용한미디어 데이터 프로세싱 - Google Patents
스트리밍 및 제어 처리를 위한 별도의 구성을 이용한미디어 데이터 프로세싱 Download PDFInfo
- Publication number
- KR100926007B1 KR100926007B1 KR1020087010946A KR20087010946A KR100926007B1 KR 100926007 B1 KR100926007 B1 KR 100926007B1 KR 1020087010946 A KR1020087010946 A KR 1020087010946A KR 20087010946 A KR20087010946 A KR 20087010946A KR 100926007 B1 KR100926007 B1 KR 100926007B1
- Authority
- KR
- South Korea
- Prior art keywords
- packet
- data
- control
- content
- network accelerator
- Prior art date
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/10—Architectures or entities
- H04L65/102—Gateways
- H04L65/1023—Media gateways
- H04L65/103—Media gateways in the network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/10—Architectures or entities
- H04L65/102—Gateways
- H04L65/1033—Signalling gateways
- H04L65/104—Signalling gateways in the network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1101—Session protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
- H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
- H04L65/613—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for the control of the source by the destination
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/75—Media network packet handling
- H04L65/752—Media network packet handling adapting media to network capabilities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/80—Responding to QoS
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
- H04L67/63—Routing a service request depending on the request content or context
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
- H04N21/2383—Channel coding or modulation of digital bit-stream, e.g. QPSK modulation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/41—Structure of client; Structure of client peripherals
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/41—Structure of client; Structure of client peripherals
- H04N21/4104—Peripherals receiving signals from specially adapted client devices
- H04N21/4135—Peripherals receiving signals from specially adapted client devices external recorder
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving MPEG packets from an IP network
- H04N21/4381—Recovering the multiplex stream from a specific network, e.g. recovering MPEG packets from ATM cells
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving MPEG packets from an IP network
- H04N21/4382—Demodulation or channel decoding, e.g. QPSK demodulation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
- H04N21/643—Communication protocols
- H04N21/6437—Real-time Transport Protocol [RTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N7/00—Television systems
- H04N7/16—Analogue secrecy systems; Analogue subscription systems
- H04N7/173—Analogue secrecy systems; Analogue subscription systems with two-way working, e.g. subscriber sending a programme selection signal
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Business, Economics & Management (AREA)
- General Business, Economics & Management (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Multi Processors (AREA)
Abstract
특히 RTP 실시간 프로토콜 스트리밍을 위한 하드웨어 가속 스트리밍 배치는, 제어 패킷으로부터 결정되고 스트림 콘텐츠 패킷과 관련된 헤더를 변경하거나 보충하는데 사용되는 주소지정 표준 및 취급 표준을 이용하여 하나 이상의 스트림을 위한 데이터 패킷을 송신측 및 수신측 사이에 지정한다. 프로그램된 제어 처리장치는 RTCP 또는 RTSP 포멧의 제어 패킷에 응답하는데, 그것에 의하여 RTP 패킷의 취급 또는 방향이 변경될 수 있다. 제어 처리장치는 하드웨어 가속장치에 접근가능한 메모리에 새로운 주소지정표준 및 취급표준을 위한 데이터를 저장하는데, 하드웨어 가속장치는 동시에 다수의 진행중인 스트림을 위한 표준을 저장하도록 배치된다. 제어 패킷이 수신된 경우, 그 주소지정표준 및 취급표준은 메모리에서 발견되고 네트워크 가속장치의 실행에 의하여 제어 처리장치에 의한 연산의 필요성 없이 적용된다. 스트림이 계속되는 한, 네트워크 가속장치는 주어진 스트림을 위한 패킷에 표준을 적용하는 것이 반복적으로 계속되도록 작동하고, 고 데이터율 경로로서 작동할 수 있다. 처리장치는, 필요하다면 확장연산을 사용하는 것을 포함하는 다양한 방법으로 표준을 개정하도록 프로그램될 수 있는데, 처리장치는 네트워크 가속장치에 의하여 반복처리 부담을 덜 수 있기 때문이다.
Description
본 발명은, 예를 들어 디지털 비디오 처리센터 또는 오락시스템, 회의시스템 또는 실시간전송프로토콜(RTP) 스트리밍을 이용하는 다른 응용장치에 있어서의 실시간 데이터 전송장치 및 방법에 관한 것이다. 일반적으로, 본 발명은, 제어처리장치(control processor)의 프로그래밍(programming)에 따라 송신측(source)과 수신측(destination) 사이의 전송 연결이 종종 개시, 중단, 변경되는 패킷 데이터 전송응용장치에도 적용 가능하다.
본 발명의 장치 및 방법은, 콘텐츠정보 및 제어정보가 데이터를 저장, 제시 또는 처리하는 기능적 요소로 지정되고 또한 콘텐츠정보 및 제어정보가 이러한 기능적 요소로부터 지정되는 다양한 기록(recording), 재생(playback) 및 처리기능을 제공한다. 본 발명의 일 관점에 따르면, 데이터 속도와 관련해서 특히 요구되지만 연산이 복잡하지 않은 반복적인 데이터 처리전송기능들은, 예를 들어 네트워크접속(attached) 저장요소로 또한 네트워크접속 저장요소로부터의 데이터 패킷의 반복적 경로할당(routing)은, 제어처리 및 주소지정 단계와 같이 연산이 복잡하지만 반면에 상대적으로 빈번하지 않은 기능과 별도로 처리된다. 바람직한 배치에 있어서, 하드웨어 장치를 포함하는 가속장치(accelarator)가 제어처리장치 및 네트워크접속 데이터저장장치와의 데이터 통신에 제공된다. 가속장치는 실질적으로 전송기능만을 전담하는데, 이에 따라, 변화하는 요구(demands)에 대하여 다양하고 최적화된 방법으로 반응할 수 있는 프로그래밍에 따라 제어기능을 취급하는 처리장치없이도, 고속 데이터처리율(high data throughput rates)이 달성된다.
일반적으로, 잠재적으로 서로 다른 데이터 포맷을 사용하는 잠재적으로 서로 다른 장치를 상호작용하도록 하는 것이 유익하다. 다른 장치 및 다른 포맷을 고속 데이터율로 수용하면서, 데이터 처리 시스템 내에 다양성을 제공하기 위한 필요성에 의하여 설계의 어려움이 제기된다.
산업적 표준은 특정 데이터 타입의 포맷팅(formatting)을 좌우한다. 표준은 주소지정(addressing) 및 신호처리 기술, 데이터 저장 및 복구(retrieval), 통신 등에 영향을 미친다. 표준은 일반적으로 다양한 수준에서 적용된다. 예를 들면, 영상 암호화 표준에 따라 암호화된 영상 데이터를 전송하는 경우에 패킷신호 표준 또는 프로토콜이 적용될 수 있는 등 다양하다.
송신측(source)과 수신측(destination) 사이에서 전송되는 패킷 데이터는, 데이터포맷 전환, 연산, 버퍼링 및 이와 유사한 처리 및/또는 저장 단계를 중재하도록 유리하게 설정될 수 있다. 다중서버와 단말장치를 갖는 데이터처리 시스템에서, 연산량의 일부는 데이터 포맷팅 및 재포맷팅(reformatting)과 연관된 활동에 지정된다. 연산량의 일부는 데이터 송신측과 수신측 사이의 주소지정 및 전환이며, 사용자 선택과 같은 조건에 응답하여 배열을 잠재적으로 변화시킨다.
응용가능한 데이터처리 및 데이터통신 기능의 일부는, 송신측으로부터 수신측로의 전송과 매우 동일한 방식으로 순차적(sequential) 데이터 패킷이 처리되는 반복 작동이다. 이러한 기능들은 속도를 최대화하기 위해서 데이터 파이프라인 구성을 능률화(streamlining)하고 단순화함으로써 이익을 얻을 수 있다.
다른 데이터처리 및 데이터통신 기능들은 더욱 관리적 연산적으로 집중적이기 쉽다. 예를 들어, 송신측과 수신측 노드(nodes) 사이에서 추가, 제거 또는 전환하기 위해서 또는 기능 사이에서 전환하기 위해서 데이터흐름 경로를 재구성하는 경우, 순차적 패킷에 대한 반복적 주소조정과 같은 것뿐만 아니라 다양한 다른 단계를 수행하도록 제어처리장치가 프로그래밍 될 수 있다. 이러한 기능들은 다양성으로 이익을 얻을 수 있는데, 이는 프로그래밍 및 연산의 복잡성을 내포한다.
물론, 연산적 복잡성을 제공하는 것에 비하여, 속도를 위한 능률화 및 단순화의 목적들은 서로 일치하기 어려운 설계 목적들이다. 신속하고 다양한 배열을 제공하기 위해서는, 연산능력에 대한 요구에 비하여, 속도 및 데이터 용량에 대한 병행하는 요구를 최적화하는 것이 유리할 것이다. 본 발명은 데이터전송에 필요한 특정 기능들을 그룹(grouping)으로 세분화한다. 상대적으로 간단한 고속과 전형적인 반복 기능들은, 하드웨어, 즉 하드웨어 네트워크 가속장치에서 전체적으로 또는 부분적으로 구현될 수 있는 가속장치 요소에 할당된다. 상대적으로 복잡하고 적응성있는(adaptive) 연산 기능들은 제어 처리장치에 할당되고, 실질적으로 소프트웨어에 의하여 구현된다. 이러한 기능들 중에서, 제어 처리장치는 조건들(conditions)과 요소들(factors)을 하드웨어 네트워크 가속장치에 설정하고 저장하는데, 예를 들어 연속 패킷의 전송을 포함하는 특정 작동 중에 반복적으로 사용되는 주소지정 정보가 그것이다.
바람직한 실시예에서, 본 발명은 실시간 전송 프로토콜(real time protocol, RTP) 패킷 스트리밍에 관련하여 보여주고 있다. 오락 또는 원격회의를 위한 영상 데이터 처리에 응용될 수 있고, 보안 모니터링, 게임 시스템 및 그 외의 다른 용도를 잠재적으로 포함하는 패킷 송신측 및 수신측 타입의 예시적인 그룹이 논의된다. 전송 경로는 유선이거나 무선일 수 있고, 기업 네트워크 또는 공공 네트워크를 포함할 수 있다. 재생용 단말기는 음성 또는 영상 오락 시스템, 컴퓨터 워크스테이션, 고정 또는 휴대용 장치를 포함할 수 있다. 데이터는 네트워크 서버를 사용하여 저장되고 처리될 수 있다. 예시적인 통신 시스템은 근거리 또는 광대역 네트워크, 케이블 및 텔레커뮤니케이션 회사의 네트워크 등을 포함한다.
음성 및 및 영상 데이터와 관련하여, 실시간 프로토콜("RTP", "실시간 전송 프로토콜(Real Time Transport Protocol)"로도 알려져 있음)은 패킷화된 음성 및/또는 영상을 이동시키고, 데이터 통신 네트워크를 통하여 영상 데이터를 실시간 데이터율로 이동시키는데 적합한 표준 프로토콜이다. 실시간 또는 실황율에서 음성 및 영상 데이터의 재생(playback)은, 콘텐츠의 중단과 시작을 피하면서 저장버퍼의 필요성을 최소화하는 것이 바람직하다. 원격 회의 및 이와 유사한 통신과 같은 응용 장치에서, 패킷화된 데이터의 수집, 처리, 전송 및 판독은, 대면 실시간 회의 및 대화에 맞추어, 인식되는 지연이나 간극(gap) 없이 일어나는 것이 바람직하다.
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) 및 결정이 최적화될 수 있도록, 고성능 또는 고사양의 시스템에서 동작을 적절히 조정하는 것이 특히 유용할 것이다.
일반적으로, 잠재적으로 서로 다른 데이터 포맷을 사용하는 잠재적으로 서로 다른 장치를 상호작용하도록 하는 것이 유익하다. 다른 장치 및 다른 포맷을 고속 데이터율로 수용하면서, 데이터 처리 시스템 내에 다양성을 제공하기 위한 필요성에 의하여 설계의 어려움이 제기된다.
산업적 표준은 특정 데이터 타입의 포맷팅(formatting)을 좌우한다. 표준은 주소지정(addressing) 및 신호처리 기술, 데이터 저장 및 복구(retrieval), 통신 등에 영향을 미친다. 표준은 일반적으로 다양한 수준에서 적용된다. 예를 들면, 영상 암호화 표준에 따라 암호화된 영상 데이터를 전송하는 경우에 패킷신호 표준 또는 프로토콜이 적용될 수 있는 등 다양하다.
송신측(source)과 수신측(destination) 사이에서 전송되는 패킷 데이터는, 데이터포맷 전환, 연산, 버퍼링 및 이와 유사한 처리 및/또는 저장 단계를 중재하도록 유리하게 설정될 수 있다. 다중서버와 단말장치를 갖는 데이터처리 시스템에서, 연산량의 일부는 데이터 포맷팅 및 재포맷팅(reformatting)과 연관된 활동에 지정된다. 연산량의 일부는 데이터 송신측과 수신측 사이의 주소지정 및 전환이며, 사용자 선택과 같은 조건에 응답하여 배열을 잠재적으로 변화시킨다.
응용가능한 데이터처리 및 데이터통신 기능의 일부는, 송신측으로부터 수신측로의 전송과 매우 동일한 방식으로 순차적(sequential) 데이터 패킷이 처리되는 반복 작동이다. 이러한 기능들은 속도를 최대화하기 위해서 데이터 파이프라인 구성을 능률화(streamlining)하고 단순화함으로써 이익을 얻을 수 있다.
다른 데이터처리 및 데이터통신 기능들은 더욱 관리적 연산적으로 집중적이기 쉽다. 예를 들어, 송신측과 수신측 노드(nodes) 사이에서 추가, 제거 또는 전환하기 위해서 또는 기능 사이에서 전환하기 위해서 데이터흐름 경로를 재구성하는 경우, 순차적 패킷에 대한 반복적 주소조정과 같은 것뿐만 아니라 다양한 다른 단계를 수행하도록 제어처리장치가 프로그래밍 될 수 있다. 이러한 기능들은 다양성으로 이익을 얻을 수 있는데, 이는 프로그래밍 및 연산의 복잡성을 내포한다.
물론, 연산적 복잡성을 제공하는 것에 비하여, 속도를 위한 능률화 및 단순화의 목적들은 서로 일치하기 어려운 설계 목적들이다. 신속하고 다양한 배열을 제공하기 위해서는, 연산능력에 대한 요구에 비하여, 속도 및 데이터 용량에 대한 병행하는 요구를 최적화하는 것이 유리할 것이다. 본 발명은 데이터전송에 필요한 특정 기능들을 그룹(grouping)으로 세분화한다. 상대적으로 간단한 고속과 전형적인 반복 기능들은, 하드웨어, 즉 하드웨어 네트워크 가속장치에서 전체적으로 또는 부분적으로 구현될 수 있는 가속장치 요소에 할당된다. 상대적으로 복잡하고 적응성있는(adaptive) 연산 기능들은 제어 처리장치에 할당되고, 실질적으로 소프트웨어에 의하여 구현된다. 이러한 기능들 중에서, 제어 처리장치는 조건들(conditions)과 요소들(factors)을 하드웨어 네트워크 가속장치에 설정하고 저장하는데, 예를 들어 연속 패킷의 전송을 포함하는 특정 작동 중에 반복적으로 사용되는 주소지정 정보가 그것이다.
바람직한 실시예에서, 본 발명은 실시간 전송 프로토콜(real time protocol, RTP) 패킷 스트리밍에 관련하여 보여주고 있다. 오락 또는 원격회의를 위한 영상 데이터 처리에 응용될 수 있고, 보안 모니터링, 게임 시스템 및 그 외의 다른 용도를 잠재적으로 포함하는 패킷 송신측 및 수신측 타입의 예시적인 그룹이 논의된다. 전송 경로는 유선이거나 무선일 수 있고, 기업 네트워크 또는 공공 네트워크를 포함할 수 있다. 재생용 단말기는 음성 또는 영상 오락 시스템, 컴퓨터 워크스테이션, 고정 또는 휴대용 장치를 포함할 수 있다. 데이터는 네트워크 서버를 사용하여 저장되고 처리될 수 있다. 예시적인 통신 시스템은 근거리 또는 광대역 네트워크, 케이블 및 텔레커뮤니케이션 회사의 네트워크 등을 포함한다.
음성 및 및 영상 데이터와 관련하여, 실시간 프로토콜("RTP", "실시간 전송 프로토콜(Real Time Transport Protocol)"로도 알려져 있음)은 패킷화된 음성 및/또는 영상을 이동시키고, 데이터 통신 네트워크를 통하여 영상 데이터를 실시간 데이터율로 이동시키는데 적합한 표준 프로토콜이다. 실시간 또는 실황율에서 음성 및 영상 데이터의 재생(playback)은, 콘텐츠의 중단과 시작을 피하면서 저장버퍼의 필요성을 최소화하는 것이 바람직하다. 원격 회의 및 이와 유사한 통신과 같은 응용 장치에서, 패킷화된 데이터의 수집, 처리, 전송 및 판독은, 대면 실시간 회의 및 대화에 맞추어, 인식되는 지연이나 간극(gap) 없이 일어나는 것이 바람직하다.
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 세션을 지배하고 데이터 통신 경로에서 스트리밍 데이터의 움직임에 대하여 더 적은 주의를 기울이면서 연산적 측면을 처리하는 하나 이상의 중앙 처리장치로 할당된다.
특정 실시예에서, 본 발명의 방법은, 중앙처리장치의 제어 하에 송신 또는 수신 되는 선택된 패킷에서 발견되는 헤더(header) 데이터를 반복적으로 대체하는 하드웨어 인터페이스 요소를 사용하는 것과 관련이 있다. 중앙처리장치는, 예를 들어 특정 주소로 지정된 것과 같은 특정 방법으로 처리된 특정 확인속성을 갖는 패킷을 배열하는 것과 같은 기준을 설정할 수 있다. 이 기준은 하드웨어 인터페이스 요소를 제어하기 위하여 중앙처리장치에 의하여 저장된다. 하드웨어 요소는 전송데이터에 결과를 부과하는데, 각 연속 패킷 헤더에서 발견된 헤더 데이터 값을, 제어 처리장치로부터 판독되거나 또는 제어 처리장치로부터 유래된 데이터의 결과로서 생성된 수신 데이터로 대체하는 것을 포함한다.
하드웨어 인터페이스 요소는 실질적 관리없이 고 데이터율로 작동할 수 있는데, 시청각 프리젠테이션 장치 및 네트워크 부착 저장 장치와 같은 수신측 및 송신측 장치로의 또는 장치로부터의 RTP 패킷의 스트리밍을 제어한다. 이러한 방법에 있어서, 하드웨어 인터페이스 요소는, 제어 처리장치가 정의된 대체값으로의 특정 헤더값의 IF/THEN 대체보다 더 연산 집중적인 기능으로부터 자유롭도록 하면서 데이터 처리를 가속하는데, 현재는 하드웨어 가속장치에 의하여 성취된다.
주소지정된 데이터 패킷의 전송에 기초한 데이터 스트리밍 통신 배열에 있어서, 배열이 구내(local area) 네트워크 또는 광역(wide area) 네트워크를 포함하는지와 관계없이, 반복적 스트리밍 기능과 관련된 데이터 패킷을 운반하는 경로와 동일한 데이터 경로가 데이터 스트리밍을 관리하는데 필요한 연산적 요구 기능과 관련된 제어 및 주소지정 패킷 역시 운반한다. 본 발명의 일 측면에 따르면, 컨텐트 주소지정 메모리(content addressable memeory; CAM) 파일은, 하드웨어 가속장치가 다중의 현재-유지 중인 패킷 큐(queue; 대기열)을 특정 주소들과 관련시키도록 유지된다. 새로운 종점에 대한 새로운 스트리밍 연결이 시작되도록 SETUP 요구가 수신된 경우, CAM 파일에서는 대응되는 어떠한 착신도 발견되지 않는다. 하드웨어 가속장치는 기록(RECORD) 또는 전송(SEND) 메시지를 예상하여 콘텐츠 주소지정 메모리(CAM) 내에 착신을 개시함으로써 관련된 헤더값을 제공받는다. 새로운 종점과 연관된 헤더 값은 제어 처리장치에 알려져 있지만, 처리장치는 단지 콘텐츠 주소지정 메모리(CAM) 내에 새로운 패킷 큐를 설정함으로써 새로운 종점으로의 경로 배정만을 설정한다. 그리고 나서, 하드웨어 가속장치는 착신(incoming) 패킷을 위한 패킷 큐 착신을 찾고, 필요한 값을 치환하고, 그 수신측을 향하여 패킷을 통과하는 자동장치로서 동작한다.
확립된 큐 착신을 갖는 RTSP 기록 또는 전송 메시지가 수신되는 경우, 발신 헤더 값을 결정할 책임은, 트래픽 관리장치 및 중앙 처리장치와 데이터 통신을 하는 하드웨어 가속장치가 지게 된다. 그 연결은 진행중인 상태로 남아 있을 수 있고, 완료될 때까지 또는 어느 하나의 프로그램화(programmable) 기능에 따라 스트림의 종점 또는 종점들을 결정하는 것과 같은 중앙 처리장치가 필요로 하는 새로운 제어 또는 활동에 영향을 미칠 때까지, 고 데이터율의 이익을 갖는다. 그러한 기능들은, 다른 경우라면 각각의 통과 패킷을 취급하는 프로그램된 소프트웨어 루틴(routines)을 통하여 결정하는 제어장치를 요구하는 기능의 대부분 또는 전부를 포함할 수 있다. 그러한 기능들은, 송신측 및 수신측 사이의 패킷 경로배정(routing), 중간처리 단계의 삽입, 재생하는 동안 기록하는 것과 같은 동시에 2 이상의 수신측으로의 패킷 경로배정 등을 포함할 수 있다.
특정 헤더값을 저장된 값으로 대체하는 콘텐츠 주소지정 메모리 기술은 비교적 기계적이고 신속하게 성취할 수 있다. 예를 들어, RTP 종료 루틴과 같은 RTP 제어 기능은 어느 정도 복잡하고 하드웨어 내에서 최적으로 취급되지 않는데, 이는 예를 들어 포함된 다수의 패킷이 존재하기 때문이거나, 아마도 저장값에 근거한 IF/THEN 대체보다 더 복잡한 조건부 단계가 포함되어 있기 때문이다.
한편, 스트리밍 처리요구는 엄격할 수 있다. 통상적인 방법으로 처리하기위해서, 동작 중에 연산 부하 및 헤더값 대체 모두에 대한 부담을 덜어줄 수 있도록 매우 신속하고 유능한 중앙처리장치가 필요할 수 있다. 중앙처리장치가 대체값 및 기준을 제공한 후, 헤더값 대체를 취급하도록 하드웨어 가속장치를 채용하는 것이 본 발명의 일 측면이다.
일단 패킷 큐가 설정되면, 스트림의 각 패킷은 네트워크 가속장치, 즉 실질적으로는 하드웨어에 구성되는 고속 유닛에 처음으로 적용된다. 가속장치는 패킷을 컨텐츠 주소지정 메모리 (CAM) 연결표의 정보와 부합시키고, 계층(layer) (예를 들어) 3 및 4 헤더들을 제거하고, 새로운 로컬헤더(local header)를 삽입한다. 현재 잠재적으로 변경된 로컬헤더, RTP헤더, RTP 페이로드(payload)를 포함하는 패킷은 트래픽 관리자(traffic manager)를 통하여 수신측으로 송부되는데, 예를 들어 RECPRD 동작에서 주소지정된 디스크에 기록되거나, PLAY 동작에서 프리젠테이션 장치 또는 그 외의 다른 주소로 송부되거나, 한번에 이러한 동작이 둘 이상 이행된다.
본 발명에 따른 방법의 장점은 다룰 수 있고 또한 궁극적으로는 소프트웨어에 의하여 착신 RTP 트래픽을 제어할 수 있다는 것이다. 만약 새롭고 상이한 RTP 페이로드 타입이 대중화되고 또는 알려진 페이로드 타입의 정의가 변경된다면 스트림에 의하여 그것들의 지원이 유지될 수 있다. 또한, 기록중 지연시점(delayed-view-while-recording)인 개인 영상 기록장치 (personal video recording; PVR)에서의 고도로 바람직한 기능이 매우 효과적으로 지원될 수 있다.
본 발명에 따른 기술의 단점은, RTP 로컬헤더 포멧에서의 객체저장이 객체를 HTTP 전송에 대하여 접근불가능하게 만들 수 있고 또는 어떤 상황에서는 효과를 원상태로 돌리는 동작을 요구할 수 있다는 것이다. 그러나, 호스트 처리장치에서의 적절한 소프트웨어 루틴은, 원본 매체를 재조립하는데 사용되거나, RTP 사용자가 아닌 고객이 즉시 이용할 수 있는 객체를 만들기 위하여 신속히 사용되거나, 자원이 이용가능한 미래 및/또는 객체에 대한 요구가 일어나는 미래에 사용될 수 있다.
상술한 목적 및 다른 목적 및 특징은 후술하는 바람직한 양태 및 실시예를 논의하는 과정에서 더욱 분명해질 것이다.
더욱 상세하게, 실시간 프로토콜(RTP)과 연관된 특정 자원-집약형 처리의 서브셋(subset)을 분할함으로써 미디어 서버에 의하여 수행되는 처리를 촉진하고 가속화시키기 위한 장치 및 방법이 제공되는데, 할당된 서브셋에 대해서 최적화된 처리장치 및 전환장치에 의하여 처리되도록 제공된다. 속도에 근거한 기능의 분할(partitioning)은 데이터 경로(pipeline)의 특성을 갖는 장치로 할당된다. 계산량은 RTP 세션을 지배하고 데이터 통신 경로에서 스트리밍 데이터의 움직임에 대하여 더 적은 주의를 기울이면서 연산적 측면을 처리하는 하나 이상의 중앙 처리장치로 할당된다.
특정 실시예에서, 본 발명의 방법은, 중앙처리장치의 제어 하에 송신 또는 수신 되는 선택된 패킷에서 발견되는 헤더(header) 데이터를 반복적으로 대체하는 하드웨어 인터페이스 요소를 사용하는 것과 관련이 있다. 중앙처리장치는, 예를 들어 특정 주소로 지정된 것과 같은 특정 방법으로 처리된 특정 확인속성을 갖는 패킷을 배열하는 것과 같은 기준을 설정할 수 있다. 이 기준은 하드웨어 인터페이스 요소를 제어하기 위하여 중앙처리장치에 의하여 저장된다. 하드웨어 요소는 전송데이터에 결과를 부과하는데, 각 연속 패킷 헤더에서 발견된 헤더 데이터 값을, 제어 처리장치로부터 판독되거나 또는 제어 처리장치로부터 유래된 데이터의 결과로서 생성된 수신 데이터로 대체하는 것을 포함한다.
하드웨어 인터페이스 요소는 실질적 관리없이 고 데이터율로 작동할 수 있는데, 시청각 프리젠테이션 장치 및 네트워크 부착 저장 장치와 같은 수신측 및 송신측 장치로의 또는 장치로부터의 RTP 패킷의 스트리밍을 제어한다. 이러한 방법에 있어서, 하드웨어 인터페이스 요소는, 제어 처리장치가 정의된 대체값으로의 특정 헤더값의 IF/THEN 대체보다 더 연산 집중적인 기능으로부터 자유롭도록 하면서 데이터 처리를 가속하는데, 현재는 하드웨어 가속장치에 의하여 성취된다.
주소지정된 데이터 패킷의 전송에 기초한 데이터 스트리밍 통신 배열에 있어서, 배열이 구내(local area) 네트워크 또는 광역(wide area) 네트워크를 포함하는지와 관계없이, 반복적 스트리밍 기능과 관련된 데이터 패킷을 운반하는 경로와 동일한 데이터 경로가 데이터 스트리밍을 관리하는데 필요한 연산적 요구 기능과 관련된 제어 및 주소지정 패킷 역시 운반한다. 본 발명의 일 측면에 따르면, 컨텐트 주소지정 메모리(content addressable memeory; CAM) 파일은, 하드웨어 가속장치가 다중의 현재-유지 중인 패킷 큐(queue; 대기열)을 특정 주소들과 관련시키도록 유지된다. 새로운 종점에 대한 새로운 스트리밍 연결이 시작되도록 SETUP 요구가 수신된 경우, CAM 파일에서는 대응되는 어떠한 착신도 발견되지 않는다. 하드웨어 가속장치는 기록(RECORD) 또는 전송(SEND) 메시지를 예상하여 콘텐츠 주소지정 메모리(CAM) 내에 착신을 개시함으로써 관련된 헤더값을 제공받는다. 새로운 종점과 연관된 헤더 값은 제어 처리장치에 알려져 있지만, 처리장치는 단지 콘텐츠 주소지정 메모리(CAM) 내에 새로운 패킷 큐를 설정함으로써 새로운 종점으로의 경로 배정만을 설정한다. 그리고 나서, 하드웨어 가속장치는 착신(incoming) 패킷을 위한 패킷 큐 착신을 찾고, 필요한 값을 치환하고, 그 수신측을 향하여 패킷을 통과하는 자동장치로서 동작한다.
확립된 큐 착신을 갖는 RTSP 기록 또는 전송 메시지가 수신되는 경우, 발신 헤더 값을 결정할 책임은, 트래픽 관리장치 및 중앙 처리장치와 데이터 통신을 하는 하드웨어 가속장치가 지게 된다. 그 연결은 진행중인 상태로 남아 있을 수 있고, 완료될 때까지 또는 어느 하나의 프로그램화(programmable) 기능에 따라 스트림의 종점 또는 종점들을 결정하는 것과 같은 중앙 처리장치가 필요로 하는 새로운 제어 또는 활동에 영향을 미칠 때까지, 고 데이터율의 이익을 갖는다. 그러한 기능들은, 다른 경우라면 각각의 통과 패킷을 취급하는 프로그램된 소프트웨어 루틴(routines)을 통하여 결정하는 제어장치를 요구하는 기능의 대부분 또는 전부를 포함할 수 있다. 그러한 기능들은, 송신측 및 수신측 사이의 패킷 경로배정(routing), 중간처리 단계의 삽입, 재생하는 동안 기록하는 것과 같은 동시에 2 이상의 수신측으로의 패킷 경로배정 등을 포함할 수 있다.
특정 헤더값을 저장된 값으로 대체하는 콘텐츠 주소지정 메모리 기술은 비교적 기계적이고 신속하게 성취할 수 있다. 예를 들어, RTP 종료 루틴과 같은 RTP 제어 기능은 어느 정도 복잡하고 하드웨어 내에서 최적으로 취급되지 않는데, 이는 예를 들어 포함된 다수의 패킷이 존재하기 때문이거나, 아마도 저장값에 근거한 IF/THEN 대체보다 더 복잡한 조건부 단계가 포함되어 있기 때문이다.
한편, 스트리밍 처리요구는 엄격할 수 있다. 통상적인 방법으로 처리하기위해서, 동작 중에 연산 부하 및 헤더값 대체 모두에 대한 부담을 덜어줄 수 있도록 매우 신속하고 유능한 중앙처리장치가 필요할 수 있다. 중앙처리장치가 대체값 및 기준을 제공한 후, 헤더값 대체를 취급하도록 하드웨어 가속장치를 채용하는 것이 본 발명의 일 측면이다.
일단 패킷 큐가 설정되면, 스트림의 각 패킷은 네트워크 가속장치, 즉 실질적으로는 하드웨어에 구성되는 고속 유닛에 처음으로 적용된다. 가속장치는 패킷을 컨텐츠 주소지정 메모리 (CAM) 연결표의 정보와 부합시키고, 계층(layer) (예를 들어) 3 및 4 헤더들을 제거하고, 새로운 로컬헤더(local header)를 삽입한다. 현재 잠재적으로 변경된 로컬헤더, RTP헤더, RTP 페이로드(payload)를 포함하는 패킷은 트래픽 관리자(traffic manager)를 통하여 수신측으로 송부되는데, 예를 들어 RECPRD 동작에서 주소지정된 디스크에 기록되거나, PLAY 동작에서 프리젠테이션 장치 또는 그 외의 다른 주소로 송부되거나, 한번에 이러한 동작이 둘 이상 이행된다.
본 발명에 따른 방법의 장점은 다룰 수 있고 또한 궁극적으로는 소프트웨어에 의하여 착신 RTP 트래픽을 제어할 수 있다는 것이다. 만약 새롭고 상이한 RTP 페이로드 타입이 대중화되고 또는 알려진 페이로드 타입의 정의가 변경된다면 스트림에 의하여 그것들의 지원이 유지될 수 있다. 또한, 기록중 지연시점(delayed-view-while-recording)인 개인 영상 기록장치 (personal video recording; PVR)에서의 고도로 바람직한 기능이 매우 효과적으로 지원될 수 있다.
본 발명에 따른 기술의 단점은, RTP 로컬헤더 포멧에서의 객체저장이 객체를 HTTP 전송에 대하여 접근불가능하게 만들 수 있고 또는 어떤 상황에서는 효과를 원상태로 돌리는 동작을 요구할 수 있다는 것이다. 그러나, 호스트 처리장치에서의 적절한 소프트웨어 루틴은, 원본 매체를 재조립하는데 사용되거나, RTP 사용자가 아닌 고객이 즉시 이용할 수 있는 객체를 만들기 위하여 신속히 사용되거나, 자원이 이용가능한 미래 및/또는 객체에 대한 요구가 일어나는 미래에 사용될 수 있다.
상술한 목적 및 다른 목적 및 특징은 후술하는 바람직한 양태 및 실시예를 논의하는 과정에서 더욱 분명해질 것이다.
현재 바람직하다고 생각되는 본 발명의 특정 예시적이고 비-한정적인 실시예가 도면에 도시되어 있다. 그러나, 독점권이 요청되는 본 발명의 범위를 결정하기 위하여 첨부된 청구의 범위에 대한 참조로 해석되어야 한다.
도 1은 본 발명에 따른 RTP 데이터콘텐츠 구성요소는 RTSP 및/또는 RTCP 제어 신호전달을 처리하는 중앙 처리장치와 같은 제어 포인트 주위로 경로 배정되는 송신측-수신측의 데이터 전송 관계(예를 들어 서버-클라이언트)를 예시한 블록 다이어그램이다.
도 2는 본 발명에 따른 스트리밍 제어장치를 도시한 블록 다이어그램이다.
도 3은 RTP 헤더에서의 구성요소의 값을 도시한 표이다.
도 4는 RTP 헤더의 로컬주소 헤더에의 사전 부착을 설명하는 데이터 표 다이어그램이다.
도 5는 중앙처리장치로부터 최초에 획득한 값을 반복적으로 적용하기 위한 콘텐츠 주소지정 메모리의 사용에 포함되는 데이터 흐름 및 데이터 구성요소를 도시하는 블럭 다이어그램이다.
도 6은 셋업에서 이행되고 데이터 스트리밍 연결을 수행하는 기능을 도시하는 논리 흐름도이다.
도 7은 바람직하게는 본 발명의 규정을 취급하는 패킷 데이터를 포함하도록 설정되는 오락 시스템 "HANS"의 구성요소를 도시한 블록 다이어그램이다.
도 8은 상이한 오프셋을 갖는 프로토콜들이 연결되는 경우에 적용할 수 있는 헤더 오프셋의 부가와, 오프셋의 관점에서 패킷 주소가 결정되는 방법을 도시한 다이어그램이다.
도 9는 바람직한 배열에 따른 콘텐츠 주소지정 메모리 요소들의 단계들을 도시한 논리 다이어그램이다.
도 10은 본 발명의 동작에 의하여 데이터 패킷에 적용되는 로컬헤더의 배치를 도시한 데이터 표 다이어그램이다.
실시간 프로토콜 또는 "RTP"는, 음성, 영상 또는 시뮬레이션 데이터와 같은 실시간 데이터를 멀티캐스트 또는 유니캐스트 서비스 상으로 전송하는 응용장치에 적합한 단대단(end-to-end) 네트워크 전송기능을 제공한다.
RTP는 자원예약에 주소를 지정하지 않으며, 연결이 유지되고 패킷이 손실되지 않는 등을 RTP 프로토콜 수준에서 보증하는 것과 같은 실시간 서비스를 위한 서비스질을 권장하지 않는다. 데이터전송 프로토콜 즉, RTP는, 세션 제어(즉, 송신측으로부터 수신측으로의 RTP 전송)에 사용될 수 있는 제어 프로토콜(RTCP)이나 포괄적인 프리젠테이션 제어 프로토콜(RTSP)에 의하여 증가된다.
RTCP 및 RTSP 제어 프로토콜은, 예를 들어 전송경로를 설정하거나 닫는(tear down) 경우, 일 방향 전송(PLAY) 또는 타 방향 전송(RECORD)을 개시하는 경우, 전송 중단 등의 경우에 전송되는 신호화패킷(signaling packet)을 포함한다. 임의의 동기 참조(synchronizing reference)와 실시간으로 연속 가능한 한, 콘텐츠 데이터 패킷은 스트리밍 될 필요가 있다. 콘텐츠 패킷은 RTCP 및 RTSP 패킷과 동시에 전송되지만, 3개 각각의 프로토콜의 패킷은 다르게 주소지정된 논리 연결 또는 소켓을 사용한다.
RTCP/RTSP 제어 프로토콜 및 RTP 데이터 스트리밍 프로토콜은 함께 대규모 멀티캐스트 네트워크에 계위가능한(scalable) 도구를 제공한다. RTP와 RTCP는 그 기저에 놓여 있는 전송 및 네트워크 계층(layer)과 독립적으로 설계되므로, 다양한 선택적 계층과 함께 사용될 수 있다. 원할 경우, 프로토콜은 RTP-수준의 번역기 및 믹서(mixer) 사용 또한 지원한다.
RTP 제어 프로토콜(RTCP)은, 서비스의 품질을 모니터링하고, 진행 중인 세션에서 참여자에 관한 정보를 전달하는 능력을 갖는다. 참여자 정보(participant information)는, "느슨하게 제어되는(loosely controlled)" 세션, 예를 들어 뚜렷한 회원(membership) 제어 또는 설정은 없지만 주어진 응용 프로그램이 인증이나 통신 요건을 더 요구하는 경우에 충분한데, 이러한 경우는 일반적으로 RTSP 세션 제어 프로토콜의 영역이다.
송신측와 수신측 사이에서 스트리밍 되는 RTP 데이터 콘텐츠 패킷은 실시간으로 수신측 주소를 향하여 단순하게 통과한다. 패킷은 실시간으로 통과되는 반면에, 수신장치에서의 버퍼링 저장은 거의 불필요하다. 동일한 이유로, 송신장치는 통상적으로 임시 파일을 생성할 필요가 없다. HTTP 객체 전송과 같은 일부 다른 프로토콜과 달리, RTP는 매체-특정 헤더를 사용하여 객체를 패킷화(packetize)한다. RTP 수신기는 신호화(signaling) 능력을 재시도하기보다는 패킷 손실로부터 회복되도록 구성된다. RTP 전송은 TCP/IP 무연결(connetion-less) 프로토콜을 채택할 수 있다. 통상적으로, RTP전송은 RTP 데이터의 사용자 데이터그램 프로토콜(UDP) 패킷 전송으로 수행되지만, 일반적으로, 필수적으로 하나의 RTP 패킷을 구성하는 각각의 UDP 패킷으로 수행되지는 않는다.
RTP 패킷은, 패킷을 RTP로 식별하는 고정 헤더, 패킷 일련 번호(sequence number), 타임스탬프(timestamp), 동기 송신측 식별자, 송신측 식별자에 기여하는 가상 공리스트(possibly empty list), 및 페이로드(payload) 데이터를 갖는다. 페이로드 데이터는 음성 샘플 또는 압축 영상 데이터와 같은 데이터 값의 주어진 카운트(count)를 포함한다.
제어 패킷(RTCP) 및/또는 세션 제어 패킷(RTSP)과 비교하여, 별도의 실시간 데이터 컨텐츠 패킷(RTP)을 이용하는 시스템의 일 측면은, 3가지 타입 또는 패킷 모두가 동일한 데이터 경로를 통하여 주파수 및 기능을 달리하여 송신 및 수신된다는 것이다. 수신장치에, 네트워크 연결 오락 시스템, 영상회의 시스템, 네트워크 부착 저장장치 등과 같은 처리장치를 제공하는 것이 가능하며, RTP 패킷과 RTCP 또는 RTSP 제어 패킷을 적절히 구분하도록 처리장치를 프로그램하는 것이 가능하다. 데이터 패킷은 그들의 수신측을 향하여 통과되고, 제어 패킷은, 처리장치가 다른 프로그램된 기능과 정보전달을 수행하는데 사용된다. 그러한 시스템이 페이스를 유지하기 위해서는, 중앙처리장치가 RTP 데이터 패킷을 실시간으로 통과시킬 수 있도록 고 데이터율로 동작하여야 한다. 또한, 처리장치는, 잠재적으로 포함되어 있는 제어과정들을 취급하는데 필요한 연산 복잡성과 프로그램밍을 가지고 있어야 한다. 처리장치는 신속하고 유능해야 하지만, RTP 패킷을 단순히 통과시키는 경우에는 처리장치의 연산복잡성은 사용되지 않으며, 비교적 드문 제어 연산을 취급하는 데에는 처리장치의 고 데이터율 능력이 필요하지 않다.
본 발명의 일 측면은, 중앙처리장치(또는 처리장치)의 연산력이 RTP 데이터의 루틴한 통과를 처리하지 않고 특별케이스 세션과정을 위하여 자유롭지만 일반적으로는 RTP 세션의 안정상태(steady-state) 처리와는 분리되도록 RTP 데이터 및 신호화 데이터를 위한 별도의 데이터 경로를 제공하는 것이다. 데이터 스트리밍을 위한 하드웨어 전환장치와, 상이한 입력 및 출력 프로토콜, 장치, 주소지정, 기능과 같은 상위 및/또는 하위 응용계층에서 다중 지원 프로토콜의 복잡성을 취급하는 중앙처리장치를 이용함으로써 성취될 수 있는 이행 이점 덕분에, 이러한 분할은 장점을 갖는다.
도 1은 서버(즉, 스트리밍 데이터의 송신측)와 클라이언트(수신측) 사이에 배치된 제어 포인트를 갖는 간단한 네트워크 환경을 도시하고 있다. 각각의 상호연결은 RTP 스트리밍을 위한 다양한 지원 패킷 타입으로 표시되어 있다. 본 발명은 제어 포인트를 포함하는 다양한 구성으로 광범위하게 응용될 수 있는데, 기재된 것처럼 하드웨어 가속장치를 사용하여 메시지 헤더 내의 필드가 대체되는 기술을 제공함으로써, 적어도 부분적으로는 제어 포인트에서의 처리의 필요성을 우회한다.
도 2는 제어 포인트가 네트워크를 통하여 패킷 송신측(서버로 도시)으로 연결되는 중앙처리장치로 대표되는 예시적인 상황을 도시하고 있다. 도시된 구성에서, 통상적으로 중앙처리장치는 패킷을 하나 이상의 수신측으로 통과시키도록 요구받는데, 예를 들어 트래픽 관리기(manager)/중재기(arbiter)를 통하여, 패킷 스트림 중에서 확인된 패킷을, 패킷 송신측으로부터, 본 실시예에서 디스크 메모리 및 그 제어기로 대표되는 네트워크 부착 저장요소(network attached storage element) 또는 판독장치 등과 같은 하나 이상의 주소지정된 수신측으로 지정된다.
본 발명의 특징에 따르면, 우선 패킷 데이터는 네트워크 가속장치의 형상의 인터페이스장치에 의해서 취급된다. 네트워크 가속장치는 최소한 고속 처리장치(high throughput device)로 실시될 수 있는데, 연산적 정교성을 가질 경우 그 취급을 제어하기 위하여 착신 스트림 RTP 패킷에서 헤더값을 대체하도록 구성된다. 특히, 값들은 제어장치에 의하여 네트워크 가속장치의 컨텐츠 주소지정 메모리에 설정된다. 예를 들어, 그 값들은, 헤더값으로부터 패킷을 저장장치, 판독장치 또는 다른 로컬 수신측으로 경로 배정하는 로컬 주소값으로의 직접대체일 수 있다. 또는, 하드웨어 가속장치는, 동일 콘텐츠의 2 이상의 복사본을 신호경로를 효과적으로 분리함으로써 2 수신측으로 지정하는 것과 같은 다른 임의의 방법으로 패킷을 경로 배정하는 제어장치에 의하여 제어될 수 있다.
이러한 목적을 위하여, 하드웨어 가속장치의 컨텐츠 주소지정 메모리는 일련의 주소들, 헤더값, 플래그(flag) 등으로 로딩되는 표를 포함하는데, 주소들, 헤더값, 플래그 등은 스트림의 과정이 개시될 경우 특정 스트림에 대응된다. 추가적 패킷이 실시간으로 도착하자마자, 하드웨어 가속장치는, 표의 엔트리(entry) 사항을 연결된 스트림에 위치시키고 패킷의 헤더값을 콘텐츠 주소지정 메모리에 로딩된 값으로 부터 찾아내거나 생성한 헤더값으로 대체함으로써, 컨텐츠 주소지정 메모리의 해당 정보에 접속한다. 컨텐츠 주소지정 메모리의 값들의 최소의 서브셋(subset)은, 예를 들어 사용자 명령을 수행하는 제어 처리장치 내에 기원한 값들이다. 컨텐츠 주소지정 메모리의 값의 서브셋은 선택적으로, 제어 처리장치와 독립적인 하드웨어 처리장치의 동작에 의하여 생성될 수 있다. 예를 들어, 하드웨어 처리장치는, UDP 패킷의 손실로부터 회복하거나, 전환 기능 등 동안 부드러운 전이(transition)를 달성하는 등의 특정 상황 하에서 일련번호를 증가시키거나 타임스탬프 정보를 조절하는 카운터(couter) 또는 애더(adder)를 포함할 수 있다.
이 실시예에서의 특정 송신측 및 수신측 실체(entity)는 대표적인 예이다. 본 발명은 도시된 것과 같이 다소간 근접해 있거나 원거리에 있을 수 있거나 또는 데이터 통신에서 연결되어 있는 잠재 송신측 및 잠재 수신측의 다양성을 포함하는 상황에 응용될 수 있어, 주어진 시간에 그러한 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 요청은 클라이언트와 서버로 세션을 묘사한다. 어떤 경우에, 요청은 객체의 음성 또는 영상 성분과 같은 유용한 객체의 서브셋에 더 특별할 수 있다.
모든 필요한 SETUP 요청이 수행되고 인증되는 경우, 제어 포인트는 전송 방향에 따라 PLAY 또는 RECORD 요청을 수행한다(issue). 그 요청은 전달될 객체의 특정 범위, 객체의 정규적인 플레이 시간 및 재생이 시작되어야 하는 로컬 시간을 선택적으로 지정할 수 있다.
재생이 완료된 후, PAUSE 명령이 수행된 것처럼 프레젠테이션은 자동으로 중지된다. PAUSE 명령이 수행되면, 스트림이 중지되어야 하는 타임스탬프(timestamp)를 명시하고, 서버(클라이언트)는 연속되는 PLAY (RECORD) 요청이 수행될 때까지 데이터 전달을 중단한다.
TEARDOWN 요청이 수행되는 경우, 명시된 스트림 상에서 데이터 전달이 중지되고, 모든 연관된 세션 자원이 제거된다.
RTSP 명령어는, RTP/UDP 또는 RTP/TCP가 전송을 위하여 사용되는 대역외(out-of-band) 전송 세션을 명시할 수 있다. "대역외" 전송은 2개 이상의 별도의 전송 또는 연결 경로를 의미한다. 그 경우의 RTSP 트래픽은, 하나의 연결로 이루어질 수 있고, RTP 데이터의 실제 전송을 이행하는 RTSP에 의하여 다른 연결이 명시될 수 있다.
RTP 패킷은 TCP로 전송될 수 있다. TCP와 달리 유지된 연결을 요구하지 않으며, 손실된 패킷에 민감하지 않고/않거나 손실된 패킷을 탐지하여 복구하려고 시도하지 않기 때문에, UDP 전송은 일반적으로 비효율적이다. UDP 전송 프로토콜은 음성 또는 영상 데이터 샘플값과 같은 패킷을 실시간으로 전송하는데 적합하다. 이러한 값들은 개별적으로 중요하지는 않지만, 데이터 양이 큰 경우의 이동에 필요하다. 연결이 설정되고, 예를 들어, 재전송함으로써 패킷 손실을 복구하려고 하는 것 등과 같이 신뢰성을 강조한다는 점에서 TCP는 UDP와 다르다. 이러한 측면은 UDP보다 RTP의 필요성에 덜 일치된다. 이러한 개시(disclosure)는 일반적으로 UDP가 RTP 전송을 위해서 사용된다는 것을 가정한다. 그러나, 그 개시가 바람직하게 UDP 전송으로 한정하는 것으로 간주되어서는 안 되며, 오히려 다른 프로토콜로서 TCP를 포함하는 것으로 간주되어야 한다.
서버가 RTP를 사용하여 전달된 객체에 대한 요청을 수신할 경우, 통상적으로 객체는 원시(native) 포맷으로부터 패킷화(packetizable) 포맷으로 코드변조(transcode)된다. 기술된 바와 같은 데이터 패킷화와 관련되고 온라인 접속을 위하여 유지되는 문제점을 해결하기 위하여, 예를 들어 인터넷 엔지니어링 태스크포스(ieft.org)에 의하여, 산업계에서는 주어진 다양한 매체 타입에 대한 연관 RFC를 포함하는 많은 수의 "인터넷 기술 관련 문서(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)
- 중요한 데이터 요소를 위한 반복 패킷
- 음성/영상 디먹싱(demuxing)
- 또는 1.1.3 RTCP
주기적으로 주어진 RTP 세션이 활성화되는 동안, 세션에 관한 제어 정보는 RTCP를 사용하는 별도의 연결상으로 교환된다(UDP의 경우, RTP 세션은 짝수 수신측 포트를 사용하며, RTCP 정보는 다음 상위 홀수 수신측 포트를 통하여 전달된다.). RTCP는 데이터 분배의 품질에 대한 피드백을 제공하는 것을 포함하는 다양한 기능을 수행하는데, 피드백 제공은, 특히 IP 멀티캐스트 전송의 경우에, 네트워크 문제가 로컬적인지 전체적인지를 서버가 결정하는데 유용할 수 있다. RTCP는 또한 RTP 송신측에 대한 영구 전송-수준 식별자, 즉 CNAME를 운반하도록 동작한다. 충돌 또는 프로그램 재시작이 IDS의 이동(migration)을 야기할 수 있으므로, 수신장치는, CNAME가 각 참여자를 추적할 것을 요구한다. 또한, CNAME는 다양한 RTP 세션으로부터 다중 관련 스트림을 동기화(예를 들어, 음성 및 영상을 동기화)하는데 사용될 수 있다.
전송의 모든 참여자가 RTCP 패킷을 전송하도록 요구된다. 세션 내의 참여자의 수가 증가할 경우에는, 각 참여자에 의하여 전송되는 패킷의 수는 바람직하게는 감소한다. 각 참여자가 RTCP 패킷을 다른 모든 참여자에게 전송하도록 함으로써, 각 참여자는 참여자의 숫자를 추적할 수 있다. 이어서, 이 숫자는 제어 패킷이 전송되는 속도를 측정하는데 사용된다. RTCP는 사용자 인터페이스에 표시되는 참여자 정보와 같은 최소 세션 제어 정보를 전달하는데 사용될 수 있다.
이러한 임무를 달성하기 위해서, RTCP 패킷은 이하의 카테고리 및 포맷 중의 하나에 속할 수 있다.
- SR: 활성 송신장치인 참여자로부터 송신 및 수신 통계를 위한 송신장치 보고(sender report);
- RR: 활성 송신장치가 아니고, 31개 이상의 송신측을 보고하는 활성 송신장치를 위한 SR과 결합하는 참여자들로부터 수신 통계를 위한 수신장치 보고(receiver report);
- SDES: CNAME를 포함하는 송신측 기술 아이템(source description item);
- BYE: 참여자의 종단을 지시함; 그리고,
- PP: 응용-특정 기능.
RTP와 마찬가지로, RTCP 패킷의 각 형태는 가변길이 서브헤더가 수반되는 공용 헤더로 시작된다. 하위-계층 프로토콜의 단일 패킷에서 함께 전송될 수 있는 복합 패킷(compound packet)을 형성하도록 다중 RTCP 패킷은 서로 연결될 수 있다.
본 발명의 일 측면은, 하드웨어-단독(hardware-only) 해답이나 소프트웨어-단독(software-only) 해답을 제공하는 대신에 하이브리드(hybrid) 하드웨어 및 소프트웨어 해답을 제공함으로써 통합 RTSP/RTP 해답의 구현을 개선하는 것이다. 비록 모든 제어 상황 시나리오를 위하여 제공하지만, 어떠한 전(全)-하드웨어(all-hardware) 해답도 어느 정도 복잡하게 된다. 이와 대비적으로, 처리장치를 구비하고 그러한 복잡성을 다룰 수 있도록 코딩하는 어떠한 소프트웨어-단독 해답도 완전히 개발되지는 않았다. 주어진 스트림이 진행 중인 후의 대부분의 작동에 대하여, 주어진 스트림을 위한 연속 패킷을 이전 패킷과 동일한 방법으로 계속 취급하기 위한 많은 작동은 반복적인 작동을 이용하여 취급되고 연산력을 요구하지 않는다.
본 발명의 바람직한 실시예에 따르면, 제어처리가 대규모로 설정되고 잠재적으로 복잡하고 유능한 소프트웨어 프로그램을 동작하는 제어장치에 의하여 배열되는 곳에서 하이브리드 해답이 제공된다. 그러나, 특화된 하드웨어는, 매체 객체와 소프트웨어에 의하여 생성된 지원 파일을 이용하여 전송을 가속하는데 사용된다.
그 상대적 복잡성과 작동의 희귀성(infrequency)에 의하여, 제어단계와 밀접한 관련이 있는 RTSP 및 RTCP 기능은 지나친 부담없이 중앙처리장치 상에 소프트웨어로 구현될 수 있다. 한편, RTP는 매체 스트림에서 서열적 혹은 준 서열적인 각 착신 및 발신 패킷을 실시간 데이터율로 처리할 것을 요구하는데, 본 발명에 따라 하드웨어 가속으로 이점이 발생된다.
스트리밍 기능성의 특정 서브셋을 구현하기 위한, 즉 RTP 컨텐츠를 오프로딩(offloading)하는 하드웨어로 RTSP/RTP를 채용하기 위한 작동의 예가 여기에 기술된다. 이러한 기능성은 개인용 영상 기록장치(PVR)에서 공통적으로 발견되며, 종단점으로부터 RTP-요약(encapsulated) 데이터의 입력 스트림을 즉시 받아들이거나 동일한 RTP-요약 데이터를 동일한 종단점 또는 상이한 종단점으로 보내는 임의의 시간구간 후에 받아들이는 것으로 기술될 수 있다. 종단점이 일시적일 수 있고, 예를 들어 사용자 선택에 따라 변경 또는 전환될 수 있다는 것은 그러한 기능의 속성이다. 언급한 바대로, 종단점의 특유 속성은 본 발명의 동작에 중요하지 않다. 종단점은 영상 카메라 및 재생 수신장치와 같은 최초 또는 최후 표시장치, 또는 압축/압축해제 또는 포멧변환 장치와 같은 매개 요소장치일 수 있으며, 또는 앞의 요소 및 패킷 데이터 신호가 지정되거나 패킷 데이터 신호가 유래하는 스트림 내의 다른 요소의 결합일 수 있다.
도 2에 도시한 바와 같이, 매체 스트리머는 3개의 주 설계개체(main architectural entities), 즉 중앙처리장치, 트래픽 관리자/중재기, 네트워크 프로토콜 또는 하드웨어 가속장치를 포함한다. 이러한 구조는 물리적 실시예에 따라 변경될 수 있고, 회로 대비 제어처리 관점에서 다소간 복잡할 수 있다. 특정 동작 요소가 다소 단단하게 연결되는 방법으로 회로가 구현되는 한, 여기서는 그러한 요소의 특정 기능은 본 발명에 따른 RTSP/RTP 트래픽의 취급에 부속되는 것으로 정의된다.
중앙처리장치는 시스템 처리를 제어한다. 네트워크 프로토콜 가속장치 또는 "하드웨어 가속장치"는 자원-집중적이지만 아마도 반복적이거나 되풀이되는 처리 태스크를 취급한다. 이러한 방법에 있어서, 하드웨어 가속장치는 고주파 저복잡성 동작에 있어서 중앙처리장치의 부담을 경감한다. 부분적으로는 착신 RTP 헤더(도 3에 도시)에 의하여 제공되고 부분적으로는 스트림을 설정할 때 제어장치(39)에 의하여 설정된 값에 의하여 제공되는 정보를 기초하여, 도 4에 도시된 로컬헤더는 패킷(도 4에 도시된 22)의 RTP 헤더에 선행하여 배치될 수 있다. 이러한 방법에 있어서, 콘텐츠 주소지정 메모리를 이용하여 대체된 프로그램-작용(affected) 로컬 주소지정 헤더 필드와 함께, 그리고 각 패킷을 제어장치(39)를 통하여 통과시킬 필요없이, 데이터 흐름은 도 5의 블럭 다이어그램에 도시된 바와 같이 진행된다.
네트워크 하드웨어 가속장치는 콘텐츠 주소지정 메모리(CAM) 또는 메모리에서 상호 참조되는 값들의 표를 포함하는데, 최소한 현재 진행 중인 스트림에 대한 것이다. 콘텐츠 주소지정 메모리는 하드웨어-가속 연결을 위한 연결 매개변수저장하는데, 하드웨어-가속 연결은 장치를 전체로 사용할 수 있는 연결들의 최소 서브셋을 포함한다. 하드웨어 가속장치는, 착신 패킷이 콘텐츠 주소지정 메모리에 저장된 메세지 큐 정보에서 이미 설정된 스트림과 관련되는지를 결정하는데 충분한 회로를 포함한다. 만약 메세지 큐 엔트리(entry)가 존재하면, 하드웨어 가속장치는 메세지 큐에 의하여 이미 결정된 방법으로 착신 패킷을 취급한다. 만약 패킷이 현존하는 엔트리를 갖지 않는다면, 하드웨어 가속장치는 해당 패킷이 가속된 스트림의 일부가 되는 것처럼 새로운 메세지 큐 설립을 중앙처리장치로 넘긴다. 패킷의 취급 방법은, 패킷 헤더값을 로컬주소로 교체하는 것, 특정 상황을 극복하기 위하여 헤더값을 개정하는 것, 다른 수준의 프로토콜과 관련된 값을 변경하는 것 등을 포함한다.
트래픽 관리기/중재기는 착신 및 발신 네트워크 트래픽을 관리하는데 사용될 뿐만 아니라, 메모리 및 디스크 접속 중재(arbitration)를 제공하는데 사용된다. 트래픽 관리기/중재기는 다양한 하드웨어 가속 연결의 입력 및 출력에 할당될 수 있는 많은 큐와 중앙처리장치를 관리한다.
본 발명에 따른 방법이 도 4의 데이터 흐름 블럭 다이어그램과 도 6의 플로우차트에 설명되어 있다. 매체 스트리머 장치는, 종단점으로부터 RTP 패킷의 스트림을 받으며, 실시간 패킷에 보조를 맞출 수 있도록 충분한 효율 및 속도를 가지고, 또한 데이터 취급을 위한 요구에 있어서의 변경과 양립할 수 있도록 충분한 적용 유연성을 가지고 데이터를 처리하도록 구현되어야 하는데, 데이터 취급을 위한 요구에 있어서의 변경은, 예를 들어 종단점 또는 역동적 가변 RTP 페이로드 타입의 광(廣)배열, 송신측, 수신측을 포함하는 매개 요소와의 새로운 송신측/수신측 관계를 시작하거나 종료하는 것이다.
RTSP와 RTCP 동작은 드물게 일어나서 중앙처리장치에서 운영되는 소프트웨어에서 작동되도록 구현될 수 있고, 통상적으로 데이터 콘텐츠와 보조를 맞추는 문제의 유발없이 실행된 프로그램은 복잡할 수 있다. 그러므로, 바람직하게 이러한 기능들은 중앙처리장치에서 운영되는 소프트웨어에 구현된다.
한편, RTP 안정상태(steady-state) 스트리밍은 패킷의 반복적 취급을 포함하는데, 예를 들어 스트림의 모든 패킷을 스트림이 활성화되어 있는 동안 일시적으로 할당될 수 있는 특정 수신측을 지정하도록 하는 것을 포함한다. 이 기능은 네트워크 가속장치와 트래픽 관리기/중재기에 전용되는 하드웨어에서 취급된다.
그러나, 다수의 스트림이 동시에 활성화일 수 있다. 동일한 방법으로 주어진 스트림을 위한 패킷을 취급하기 위하여, 콘텐츠 주소지정 메모리는 수신측 주소, 마지막 패킷 일련번호 등과 같은 스트림에 응용가능한 값의 세트를 포함한다. 하드웨어 처리장치는 콘텐츠 주소지정메모리를 통하여 스트림 식별정보를 관련 패킷 데이터 값에 유지하는 레지스터를 포함할 수 있다. (게이팅(gating) 또는 단순연산을 포함할 수 있는) 비교처리에 의하여, 하드웨어 가속장치는 착신패킷 상의 식별정보를 콘텐츠 주소지정 메모리의 엔트리(entry)에 부합시키고, 부합된 패킷에 대한 정보를 출력으로 내보낸다. 이러한 처리는, 예를 들어, 헤더 주소정보와 같은 패킷 헤더의 데이터 값을 패킷이 관련된 스트림을 위한 콘텐츠 주소지정 메모리로부터 판독한 로컬 주소정보로 대체하는데 사용된다.
값의 대체는 간단하고 반복적인 처리로서, 도 9의 플로우 차트에 의하여 일반적으로 도시된다. 만약 다음 패킷이 현재 스트림의 일부에서 대면된다면, 다음 패킷은 큐 엔트리(queue entry)를 갖는다. 스트림 식별정보(예를 들어, 주소정보)는 큐, 즉 콘텐츠 주소지정 메모리에 있는 엔트리에 부합된다. 만약 엔트리가 발견되지 않는다면, 처리장치는 신호를 받고 엔트리는 처리장치에 의하여 설정되는데, 처리장치는 적절한 큐 엔트리 값을 결정하고 결정된 값을 하드웨어 가속장치의 콘텐츠 주소지정 메모리에 저장하도록 프로그램되어 있다. (처리장치 기능은 점선으로 표시된 상자 안에 도시되어 있다.) 계속되고 더 진행되는 처리 동안, 하드웨어 가속장치는 수신된 다음 패킷을 위한 엔트리를 결정하고, 원시 헤더값을 콘텐츠 주소지정 메모리로부터 구한 값으로 대체하고, 콘텐츠 주소지정 메모리의 해당 스트림을 위한 큐 엔트리가 소멸되는 스트림의 종료까지 이러한 처리를 계속한다. 스트리밍 장치는, 그에 의하여 자유로운 자원을 이용하는 새로운 연결을 지원하도록 준비된다.
중앙처리장치에 의하여 이행되는 소프트웨어 처리는, 예를 들어 사용자의 입력선택을 취급하기 위하여 시작, 종료, 특정 동작들 간에 전환할 수 있는 응용 프로그램 인터페이스(Application Program Interface; API)를 통한 하드웨어 요소에의 인터페이싱을 포함한다. API는 중앙처리장치와 하드웨어 유닛 간의 직접 인터페이스(예를 들어, 레지스터 읽기 및 쓰기, 하드웨어 큐 접속)를 가린다.
바람직한 예에서, 개인 영상 기록(PVR)장치의 기능성은 다음과 같이 구현될 수 있는데, 이러한 설명이 비제한적 예에 관계된다는 것은 이해되어야 한다.
중앙처리장치의 프로그래밍 내에서 운영되는 RTSP 기능은 수신되는 SETUP 명령과 데이터 패킷의 송신측 및 수신측일 수 있는 종단점을 모니터링하는 것이다. RTSP-SETUP 요구를 포함하는 패킷은 네트워크 가속장치에 의하여 수신되고, 그 안에서 식별된 스트림은 CAM 검색테이블(lookup table) 내의 엔트리에 부합되지 않는다. 네트워크 가속장치는 그 스트림을 적절한 트래픽 관리 큐(중앙처리장치를 위한 착신 트래픽에 관련된 큐)에 할당한다. 일단 RTSP 처리가 완벽한 SETUP 메세지를 받으면, CAM 검색테이블 매개변수(송신측 및 수신측 IP 주소, 포트, 전송프로토콜)는 SETUP 메세지로부터 (전체적으로 또는 부분적으로) 결정된다. CAM 테이블 내의 연결표 엔트리는 RTP 세션을 위하여 설정된다.
그리고나서, RTSP는 관련된 종단점으로부터의 연속적인 RECORD 요구를 기다린다. 만약 RTSP-RECORD 메세지가 수신된다면(또는 수신될 때), RTSP-RECORD 메세지는 SETUP 메세지와 동일한 경로를 통하여 네트워크 가속장치로부터 중앙처리장치의 트래픽 관리기로 통과된다. RECORD 메세지는 기록할 스트림의 (시간)영역을 포함할 수 있다. 이점에서, 세션은 설정된 것으로 간주될 수 있고 네트워크 가속장치는 데이터를 수신할 준비가 된다. 중앙처리장치는 영역을 근거로(만약 영역이 특정되지 않았다면, 최대값이 전송된다) 객체 크기를 전송하고, 유용한 큐 식별 QID는 스케쥴링을 위하여 트래픽 관리기에 제출된다. 이것은, 스트림이 변경없이 지속되는 한, 하드웨어 가속장치가 헤더값의 간단한 대체에 의하여 패킷을 처리할 수 있게 한다.
변경은 CAM 테이블 엔트리를 종료하거나 수정함으로써 이루어질 수 있는데, 예를 들어 만약 로컬 저장장치가 착신 스트림의 기록을 시작하도록 되어 있다면, 해당 스트림을 재생장치로 지정하게 하는 엔트리는, 패킷 역시 디스크 제어장치로 지정되도록 수정될 수 있다. 선택적으로, 스트림을 로컬 저장장치의 종단점과 연관되도록 하는 다른 엔트리가 추가될 수 있다.
RTP 종료 루틴, 조건에 의하여 변하는 전환동작, 그리고 유사한 연산 집중 기능은 너무 복잡해서 상대적으로 간단한 하드웨어에서는 실행될 수 없다. 실시간과 같은 스트리밍 데이터 패킷의 시간 압력은 너무 엄격해서 중앙처리장치가 항상 시기적절한 방법으로(즉, 작동중인) 착신 트래픽을 효과적으로 취급하는 대용량 프로그램을 사용할 수 없게 한다. 본 발명은 스트림의 각 패킷이 네트워크 가속장치에 의하여 수신되는 교체적 방법을 구성하는데, 네트워크 가속장치는 연결테이블의 패킷을 부합시키고, 계층 3 혹은 4의 헤더를 제거하고, 로컬 헤더를 적용하고, 로컬 디스크와 같은 수신측에 쓰기(write) 위하여 각 패킷을 로컬 헤더, RTP 헤더, RTP 페이로드와 함께 트래픽 관리기로 전송한다.
착신패킷의 포멧은 로컬 헤더가 패킷의 총 길이를 위한 값과 요구 플래그를 구비한 32-비트 양을 포함하도록 이루어진다. 이러한 필드는 각 RTP 패킷의 경계를 정의하고 패킷이 디스크에 저장된 후 유용하게 남는다. 객체가 이러한 포멧에 저장되어있는 동안, 저장된 패킷은 승인(acknowledgement)의 원시 종단점으로 재 전달되도록 예정될 수 있고, 혹은 네트워크 상의 다른 종단점으로 경로 배정될 수 있다. 트래픽 관리기는, 로컬 헤더로부터 각 패킷의 길이 필드를 추출하여 전송크기로 사용할 수 있도록 객체를 패킷 단위로 판독하는 능력을 가져야한다. 트래픽 관리기는 데이터의 길이 바이트를 네트워크 가속장치로 전송하고 큐를 다음 패킷의 시작으로 삼는다.
패킷이 트래픽 관리기로부터 수신될 경우, 네트워크 가속장치는 로컬 헤더를 제거하고 오프셋(offset)을 부가한다. 오프셋은 최초에 중앙처리장치에의하여 결정되고, 관련된 전송을 위한 콘텐츠 주소지정 메모리(CAM) 테이블의 필드에 저장되어 하드웨어 가속장치에 의하여 발신패킷 RTP 헤더에 위치하는 일련번호(Sequence Number) 필드를 결정하는데 기여한다. 이것은 RFC 3550에서 특정된 것과 같이, 무작위(random) ISS의 규정을 가능케 한다.
발신 타임스탬프는 유사한 방법으로 조정된다. 이것은 RFC 3500에서 특정된 것과 같이, 무작위 ITS의 규정을 가능케 한다.
계층 3 및 계층 4의 헤더는 유사하게 구성되고 발신 패킷의 헤더에 위치한다. 발신패킷은 MAC/PHY 블록으로 전송된다.
이러한 방법의 하나의 장점은 착신 RTP 트래픽이 소프트웨어에 의하여 관리될 수 있다는 것이다. 다양한 상이한 RTP 페이로드 타입이 사용되거나 아마도 정의를 변경함에 따라, 이들에 대한 지원은 강력한 스트리밍 장치에 의하여 유지될 수 있다. 또한, 기록중 지연시점(delayed-view-while-recording)인 PVR 기능성이 지원될 수 있다.
단점은, 객체가 RTP 헤더 포멧에 저장되어 있는 동안, HTTP 전송을 위한 접속이 불가능하다는 것이다. 호스트 중앙처리장치의 소프트웨어는, 비 RTP 클라이언트(non-RTP clients)에게는 즉시, 혹은 어떠한 클라이언트에게도 필수 자원이 유용할 때까지 연기된 재구성에 의하여 객체를 유용하게 만들기 위하여 원시 매체 객체를 재구성하는데 사용될 수 있다.
바람직한 실시예인 도 7에 관하여, 본 발명은 디스크 어레이 제어장치를 포함하는 데이터 조작 시스템에 통합된다. 이 장치는 저장관리를 수행할 수 있고, 고객 전자 디지털 매체 응용기기(customer electronics digital media applications) 또는 통신 및 원격회의와 같은 유사한 특성을 갖는 다른 응용기기에 도움을 줄 수 있다. 오락 응용기기에서, 장치는 홈 네트워크와 데이터 저장장치의 어레이 간에 인터페이스를 제공하는데, 데이터 저장장치는 일반적으로 디지털 매체(음성, 영상, 이미지)를 저장하기 위한 하드디스크 드라이버(HDDs)를 예로 들 수 있다.
바람직하게 장치는, 홈 네트워크로의 또는 다른 근거리 통신망(LAN)으로의 인터페이스를 위한 통합 10/100/1000 이더넷(Ethernet) 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개의 동시 쌍방향 스트리밍을 취급할 수 있는 성능을 포함한다.
데이터 조작 시스템은 본 발명에 대한 다양한 가능한 응용기기의 예시인 한, 전체적인 데이터 조작 시스템은 도 7에 도시되어 있고 단지 일반적으로 설명되어 있다. 장치 내에는 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)로 표시(tag)된다. 알려지지 않은 연결로부터의 패킷은 응용 처리장치(AAP) 및 그에 의한 추가 조사를 요구한다. 그 패킷은 특정 QID로 표시(tag)되어 AAP로 경로 배정된다. AAP 이후 도달 패킷의 최종 수신측은, 패킷이 매체 콘텐츠를 운반하는 경우에는 저장을 위한 하드 디스크이고, 패킷이 제어 메시지를 운반하거나 또는 패킷이 AAP에 의하여 인식될 수 없는 경우에는 추가 조사를 위한 AAP인데, 후자의 경우 새로운 큐 ID 확립으로 잠재적으로 유도된다. 위의 조건 중 어느 경우에도, 패킷은 TMA 블록으로 전송된다.
TMA는 공유 메모리 내에 도달 트래픽을 저장한다. 매체 객체 전송의 경우, 착신 객체 데이터는 메모리에 저장되고, 디스크 저장을 위해서 RAID 디코더 및 인코더(RAID Decoder and Encoder; RDE) 블록으로 전송된다. TMA는 RDE로 적절한 제어 정보를 제공함으로써 저장 처리를 관리한다. AAP 점검을 위한 제어 트래픽 또한 공유 메모리에 저장되고, 메모리 내의 패킷을 판독할 수 있도록 AAP에게 접근(access)이 주어진다. 또한 AAP는 순서에 맞지 않게 수신된 패킷들 중 어느 것에 대해서도 재-정리하기 위하여 이 메커니즘을 사용한다. 공유 메모리 및 디스크의 일부분은 AAP를 위한 프로그램 명령 및 데이터를 포함한다. TMA는 디스크로부터 메모리로, 메모리로부터 디스크로 제어 정보를 전송함으로써 메모리 및 디스크에 대한 접속을 관리한다. 또한 TMA는, AAP가 현재의 패킷 스트림으로 그리고 현재의 패킷 스트림으로부터 데이터를 삽입하고 추출할 수 있게 한다.
전송 데이터 경로에서, TMA는, 응용 처리장치(Application Processor) 또는 네트워크 인터페이스를 통한 전송이 필요한 것으로 처리될 예정인 디스크로부터의 객체 복원 요청을 관리한다. 응용 처리장치로부터의 매체 재생 요청을 수신하면, TMA는 MDC 및 RDE 블록을 통하여 디스크로부터 전송된 데이터를 수신하고 메모리에 저장한다. 이어서 TMA는 요구되는 대역폭 및 매체 타입에 따라 데이터를 ULP 블록에 기재한다. ULP는 각각의 발신 패킷에 대한 이더넷 및 계층3/계층4(L3/L4) 헤더로 해당 데이터를 요약한다. 이어서 패킷은 특정된 수신측 포트에 근거하여 GEC 또는 PTC 블록 중 하나로 전송된다.
수신 데이터 경로 상의 착신 패킷과 관련해서, 네트워크 가속장치의 연결 검색 기능부는 주소 형성, CAM 테이블 검색 및 연결 테이블 검색 기능 블록을 포함할 수 있다. CAM 점검 주소는 부분적으로 착신 패킷 헤더로부터 추출된 정보의 결과로서 형성된다. 추출되는 헤더 필드의 세부사항은 사용 중인 트래픽 프로토콜에 달려 있다. 형성되고자 하는 주소는 고유 연결(unique connection)을 대표하여야 한다. 예를 들어, IP V4 및 TCP/UDP 프로토콜에서 이행되는 가장 대중적인 인터넷 트래픽과 관련해서, 송신측 IP 주소, 수신측 IP 주소, TCP/UDP 송신측 포트 번호, TCP/UDP 수신측 포트 번호 및 프로토콜 타입(패킷 헤더로부터 소위 "5 투플(tuple)"로 불림)이 고유 연결을 정의한다. 만약 패킷이 (IP V6와 같은) 다른 트래픽 프로토콜인 경우라면 다른 필드가 연결을 결정하는데 사용될 수 있다. 다중 프로토콜이 제공되는 경우에는 플래그 및 식별 코드와 같은 적절한 제어를 참조할 수 있어서, 시스템을 "프로토콜 인식" 계층형(hierarchical) 시스템으로 만든다. 예를 들어, 처리 과정은 각각이 지원되는 프로토콜 수준에 대응하는 3개의 스테이지로 구분될 수 있다. 제1스테이지는, 헤더 분석 처리 동안 추출되고 주소 형성 처리의 일 단계로서 도달 패킷을 위한 정보 버퍼 엔트리에 저장되는 필드로부터 L3 프로토콜의 버전 번호를 점검할 수 있다. 주소 형성 처리의 제2 및 제3스테이지를 위하여, 복합(composite) 하드웨어 테이블이 제공된다. 각 스테이지에서 테이블 엔트리 번호는 테이블이 삽입되는 스테이지 및 각 스테이지에서 지원되는 상이한 프로토콜의 숫자에 달려 있다. 각 테이블 엔트리는 항상 콘텐츠 주소지정 메모리(CAM) 엔트리와 위치번호 레지스터(position number register)로 구성된다. 각 위치번호 레지스터는 항상 한 쌍의 오프셋-크기 필드로 구성된다. 각 CAM 엔트리는 상응하는 위치 레지스터에 대한 특정 프로토콜 값을 저장한다. 오프셋은 패킷 헤더의 시작점으로부터 추출되는 필드까지 건너뛰는 바이트 숫자를 특정한다. 크기 필드는 추출되는 니블(nibbles)의 숫자를 특정한다. 동일한 주소가 CAM 필드 및 위치 레지스터 모두에 접속하기 위해서 사용된다.
특정 프로토콜 수준에서 헤더 길이가 고정되지 않는 것이 가능하다. 예를 들어, TCP와 IP 헤더 길이는 "선택(option)" 필드에 의하여 변경될 수 있다. 외부 수준 프로토콜로부터의 잠재 가변 헤더 길이는 상대적으로 필드 위치를 내부 수준 헤더 길이 그 자체를 포함하는 내부 수준 프로토콜에 옮겨 놓는다. 가변 헤더 길이를 수용하기 위하여, 프로토콜 헤더 길이 필드는 길이 필드를 포함하는 그 수준들을 위한 주소 검색 처리의 일부로서 추출될 수 있다. (IP V6 및 UDP와 같은) 일부 프로토콜은 헤더에 길이 필드를 갖지 않는 것이 가능하다. 그런 경우, 어떠한 헤더 길이도 추출될 수 없지만, 주어진 연결동안 고정 헤더 길이의 설정 및 유지와 같은 다른 기술이 채용되는 것이 가능하다.
주소 형성 처리는 도 8에 그래프로 도시되어 있다. 주소 형성 처리 동안, 패킷은 버퍼(buffer)되고, 프로토콜의 제1수준(예를 들어, IP 프로토콜을 위한 버전 번호)은 식별되고 패킷 정보 테이블에 저장된다. 주어진 시간에 패킷 정보 테이블에는 많은 엔트리가 존재하고, 엔트리는 패킷 정보 버퍼의 헤더에서 처음 접속된다. 길이 엔트리가 존재한다면, 헤더 길이(예를 들어, IP 헤더 길이)는 패킷 정보 테이블로부터 추출된다. 제1스테이지로부터 추출된 프로토콜 타입 코드는 제2스테이지 프로토콜 값을 발견하는 곳에 영향을 미친다.
CAM은 프로토콜과 오프셋의 어떠한 가능한 조합도 지원한다. 결정된 제1오프셋-크기 값은 프로토콜의 제2수준(본 예에 있어서, IP 프로토콜을 위한 프로토콜 필드)의 추출을 이끌어 낸다. 위치번호 레지스터 엔트리는 각 스테이지에서 CAM 엔트리의 숫자와 일대일 대응한다. 제2스테이지에는 각 엔트리를 위한 2쌍의 위치 레지스터가 존재한다. 만약 존재한다면, 헤더 길이 필드(예를 들어, IP 헤더 길이)는 제2위치 레지스터 쌍에 특정된 오프셋에 따라 패킷 헤더로부터 추출된다.
제3스테이지에서의 필드 추출 처리는 제2스테이지에서의 그것과 유사하다. 그러나, 제3스테이지에서의 CAM 접속은 제1 및 제2스테이지 등으로부터 추출된 프로토콜 타입의 연관을 반영하여야 한다. 여기서 8개의 필드로부터 값을 추출하기 위한 8쌍의 오프셋-크기 필드가 존재한다. 프로토콜 타입 값의 관점에서, 각 엔트리에서 추출된 다수의 필드는, 값을 함께 연관시켜 최종 주소를 형성하도록 하여 엔트리를 식별하는데 사용된다.
버퍼 또는 주소 형성 레지스터와 콘텐츠 주소지정 메모리에 접속하는 필드는 네트워크 가속장치에 의하여 처리된다. ULP에서 제어 처리장치는, CAM에 있는 요구값의 주소를 결정하기 위하여 검색 주소를 구성하는데 필요한 값을 읽기만 한다. 주소 형성 처리 동안 만약 CAM 검색에 실수가 있다면, 처리는 중지되고 착신 패킷은 에러 플래그로 표시(tag)된다.
만약 각 스테이지에서 추출된 프로토콜 필드가 상이한 프로토콜에 대하여 상이한 길이를 갖는다면, 고정 오프셋 크기를 획득하도록 엔트리를 채우는(pad) 것이 가능하다. 미사용된 비트 패드 메모리는, 고정 길이 CAM 검색이 가능하도록 최대한 고정 크기까지 주소를 지정한다.
주소 형성 레지스터의 차원(dimensions)은 요약될 수 있다. 제2스테이지는 2개의 레지스터 엔트리, 2개의 CAM 엔트리, 각 메세지 큐 엔트리를 위한 1쌍의 위치 레지스터를 포함한다. 제3스테이지는 8개의 레지스터 엔트리, 8개의 CAM 엔트리, 8쌍의 위치 레지스터를 포함한다. 각 위치 레지스터는, (512 바이트를 커버하는) 오프셋을 대표하는 10 비트, (64 니블을 대표하는) 크기를 위한 6 비트로 구성되는 16 비트를 포함한다.
주소 지정 섹션에 형성된 값은, 연결이 설정되었을 때, 즉 특정 송신측 및 수신측 지점 간의 특정 데이터 전송을 위한 연결의 개시를 신호하는 패킷의 도착 시에 제어 처리장치(즉, 응용 처리장치)에 의하여 기 저장된 정보와 함께 사용된다. 제어 처리장치는 컨텐츠 주소지정 메모리(CAM)에 엔트리를 배치한다. CAM에 있는 각 엔트리는 고유하게 연결을 결정한다.
시스템이 개시될 때(즉, 전송연결이 설정되기 전에), CAM에는 엔트리가 존재하지 않는다. 그러므로, 제1패킷이 도달할 때, CAM에는 주소정보와 부합되는 어떠한 부합 주소 엔트리도 발견되지 않으며, 패킷은 임시로 CAM 검색 실패로 간주된다. 그럴 경우, 특별한 큐 ID(QID)가 패킷을 제어 처리장치(즉, 응용 처리장치 AAP)를 위하여 예약된 메모리 위치에 할당한다.
AAP는 도달패킷을 분석하여 연결을 설정할 필요성을 결정한다. 자유 엔트리는 CAM(예를 들어, 시스템이 동시에 지원하는 64개의 가능 스트림 중의 하나)에서 발견된다. 자유 엔트리 주소는 새로운 스트림에 대한 연결 테이블을 설정하는데 사용된다. AAP는 연결 주소를 CAM의 자유 엔트리에 써서(write) 동일 주소의 나중 도달 패킷이 CAM의 엔트리와 부합되도록 한다. 이것은 AAP의 처리 요청없이 나중 도달 패킷이 취급되는 것을 허여하는데, 패킷은 논의된 네트워크 가속장치 기능에 의하여 취급되기 때문이다.
도달 패킷이 CAM의 엔트리를 갖는 존재하는 연결과 부합되는 것이 발견될 경우(CAM 히트), 부합되는 CAM 엔트리의 주소는 연결 테이블 정보, QID 및 그 외 정보를 검색하는데 사용된다. 논의 중인 예에서는, 64개의 연결을 지원하기 위하여 64개의 CAM 엔트리가 존재한다. 각 CAM 엔트리는 최대 256 비트까지 할당된다. 물론 다른 특정 카운트도 가능하다.
점유(occupied) CAM 엔트리 및 자유 CAM 엔트리 모두는 제어 처리장치 AAP에 접속할 수 있다. 제어 처리장치 AAP는 CAM 엔트리의 설정, 종료 및 순환에 책임이 있다.
일반적으로는 레지스터와, 잠재적 입력 데이터 값의 적어도 하나의 서브셋을 메모리로부터 대응되는 출력 데이터 값을 추출하는 주소지정 입력으로 사용되도록 하는 게이팅 배열(gating arrangement)을 포함하는 CAM 장치 그 자체는, 다양한 방법으로 실시될 수 있다. 무작위 접속 메모리(random access memoty) 장치는 통상적으로 메모리 위치에 대응되는 각 가능 입력 값을 특정 메모리 위치로 주소지정함으로써 데이터를 저장하고 검색한다. 대규모의 주소지정 비트는 대규모의 메모리 위치에 대응되고, 메모리 엔트리의 숫자가 크지 않을 경우에는 메모리 주소의 특정보다는, 메모리의 저장된 데이터 콘텐츠의 일부와의 디지털 비교를 가능하게 하는 하드웨어 게이팅 배열에 의하여, 메모리에서 주어진 엔트리를 발견하기 위하여 요구되는 시간이 감소될 수 있다. 이러한 방법으로 접속된 메모리는 콘텐츠-주소지정 메모리(CAM)로 불리우고 논의된 타입의 응용기기에서 장점을 갖는다.
논의 중인 예에서, CAM은 4 부터 144 비트까지의 저장된 값의 폭에서 변할 수 있고, 6 부터 1024 엔트리까지의 깊이를 갖는다. 도 9에 도시된 일 실시예에서는, 각각이 최대 64개의 양방향 스트림을 지원하기 위하여 129 비트 장치에 의한 64 엔트리를 포함하는 2개의 연결 CAM 장치가 제공된다. 129 비트 중, 128 비트는 데이터 저장을 위하여 사용되고, 1 비트는 엔트리-유효 비트로 사용된다. 256 CAM에 의한 64 엔트리를 형성하는 이러한 배치는 도 9에서 단순화된 CAM 검색 논리 다이어그램으로 대표되는데, 256 비트 워드(word)는 2개의 128 비트 서브 워드(sub word)로 나뉘어 지고, 각 서브 워드는 별도의 CAM 장치의 콘텐츠에 대하여 비교된다. 이러한 배치에서, 128 비트 서브 워드 중 하나 또는 다른 하나가 각 CAM 장치의 다중 엔트리에 부합되는 것이 가능하다. 그러나, 전체 256 비트 엔트리는 고유한 저장값에 단지 대응될 수 있다. 이러한 작동은 2개의 CAM 장치의 비교를 통합 주소지정(coordinated addressing)하고 종속 접속(cascading)함으로써 촉진된다.
도달 패킷에 대하여 CAM 히트가 존재할 경우, 도달 주소에 부합되는 엔트리의 CAM 주소는 연결에 관계된 다양한 정보값에 접속하는데 사용된다. 이러한 것들은 다음 표 1에 요약되어 있다.
어떤 연결의 경우, 로컬 헤더는 생성되고 각 착신 패킷에 선-부가된다. 그러한 로컬 헤더 생성은 AAP에 의하여 설정될 수 있다. ULP 로컬 헤더는 패킷이 네트워크로부터 도달했을 때 만들어진다. 로컬 헤더는 도 10에 특정된 포멧으로 32 비트의 고정 크기를 갖는다. ULP는 각 수신 패킷 바이트를 카운트함으로써 유도되는 패킷 길이를 선-부가(pre-pend)한다. 또한, ULP는 기가비트 이더넷 제어장치(Gigabit Ethernet Contoller; GEC)에 의하여 그리고 검색으로부터 자신에 의하여 만들어진 플래그를 로컬 헤더로 삽입한다. ULP는, 로컬 헤더가 패킷 수신측에 상관없이 가능하게 되는 한, 로컬 헤더를 동일한 포멧으로 부가한다.
본 발명은 장치에 의하여 예시되지만, 방법으로도 고려될 수 있다. 도면을 참조하면, 본 발명의 스트리밍 장치(도 1, 2, 7)는, 제어값, 송신측 주소, 수신측 주소, 페이로드 타입 중 적어도 하나를 대표하는 필드(24)를 갖는 데이터 패킷(22)이 송신측(27)과 수신측(29) 사이로 지정되게 한다. 통신 경로(32)는 서버(27) 등으로부터 데이터 패킷을 수신하고, 데이터 패킷(22)의 적어도 하나의 콘텐츠 부분(33)은 데이터 패킷(22)의 상기 필드로부터 결정되는 규칙에 따라 적어도 하나의 클라이언트(35)로 전송된다.
규칙은, 데이터 패킷이 하나 이상의 클라이언트로 별개의 방법으로 전달될 수 있게 하는 선택적 방안을 포함하는데, 예를 들어 별개의 방법은 다른 특정 장치에 주소지정되는 것과 다른 프로토콜 취급 상세에 의하여 처리되는 것 등이 있다. 제어 처리장치(39)는 통신 경로에 연결된다. 제어 처리장치의 기능은 하나 이상의 상위 계층 처리장치(ULP) 및 응용 처리장치(AAP)에서, 또는 부가 제어장치에서 전체적으로 또는 부분적으로 제공될 수 있다. 어떤 경우이든 제어 처리장치는, 연결 또는 스트림을 설정할 때 패킷을 처리하기 위한 적어도 2가지의 대안에 적용가능한 처리절차를 최소한 부분적으로 결정한다.
본 발명의 일 측면에 따르면, 메모리(43)를 갖는 네트워크 가속장치(42)는 제어 처리장치(39)에 연결되는데, 제어 처리장치는 데이터 패킷을 별개의 방법으로 전달하는 적어도 2가지의 대안 처리절차를 대표하는 데이터와 함께 네트워크 가속장치의 메모리(43)를 로드(load)한다. 처리절차는 (이에 한정되는 것은 아니지만) 패킷을 별도의 로컬 또는 원격(remote) 주소로 지정하는 것을 포함한다. 그 이후, 네트워크 가속장치(42)는 데이터 패킷(22)을 클라이언트(35)로 전달하기 위하여 제어장치(42)와 실질적으로 독립적으로 작동가능하다. 데이터 패킷(22)은 필드를 포함하는 헤더(도 3의 24)를 갖고 네트워크 가속장치(42)는 적어도 2가지의 대안 중에서 선택하기 위한 상기 필드의 대체 및 부가 중 적어도 하나를 위하여 필드에 응답하도록 작동가능하다.
장치는 RTP 실시간 프로토콜 스트리밍을 취급하기에 적합하다. 데이터 샘플 또는 RTP에서의 데이터 프로그래밍과 같은 프로그램 콘텐츠를 포함하는 패킷에 부가하여, 데이터 패킷은 RTSP 및 RTCP 스트리밍 제어 프로토콜 중 하나에 따른 제어 정보를 더욱 포함한다.
바람직한 배치에 있어서, 네트워크 가속장치는 활성화동안 각 진행 중인 스트림의 데이터값을 갖는 콘텐츠 주소지정 메모리를 포함하는데, 예를 들어 데이터값은 로컬 주소지정을 위하여 사용된다.
제어장치는 주어진 스트림을 위하여 사용될 데이터값을 설정한다. 콘텐츠 주소지정 메모리를 포함하거나 또는 최소 콘텐츠 주소지정 메모리에 연결되는 하드웨어 가속장치를 이용하는 것이 가능한 고 데이터율을 이용하는 동안, 콘텐츠 주소지정 메모리를 사용하여 제어장치의 연산 자원의 실질적 소모없이, 동일 데이터값의 최소 일부는 동일 스트림의 연속 패킷을 위하여 사용된다.
각 성분은, 적어도 하나의 변수를 대표하는 헤더 정보와 연관된 콘텐츠를 패킷화하는 단계로서, 상기 적어도 하나의 변수에 의하여 패킷화된 콘텐츠가 상기 변수의 함수로서 하나 이상의 송신측과 하나 이상의 수신측 사이에서 선택적으로 취급되는 상기 콘텐츠를 패킷화하는 단계와; 상기 스트리밍 콘텐츠 내의 제어 정보를 포함하는 단계로서, 상기 제어 정보에 따라 상기 패킷화된 콘텐츠를 선택적으로 취급하는 방식이 변경될 수 있는 상기 제어 정보를 포함하는 단계와; 송신측과 수신측 사이에서 패킷화된 콘텐츠의 스트림의 설정 또는 재지정, 중지 또는 그 외 변경을 수행하고, 그 수행의 경우 상기 제어 정보로부터 최소한 부분적으로 상기 변수의 값을 결정하고, 상기 네트워크 가속 장치 내에 상기 스트림의 식별과 연관된 상기 값을 저장하는 단계를 포함하는 방법에 효과가 있도록 작동된다.
따라서, 제어 처리장치로부터의 진행 중인 실행의 최소화와 함께, 진행 중인 스트림의 패킷화된 콘텐츠는 네트워크 가속장치에 의하여 많은 부분이 선택적으로 취급된다.
본 발명은 예시적인 실시예와 연관되어 개시되었지만, 독점권이 주장되는 발명의 범위를 결정하기 위해서는 실시예를 논하기보다는 첨부된 청구항에 대한 언급이 이루어져야 한다.
RTP는 자원예약에 주소를 지정하지 않으며, 연결이 유지되고 패킷이 손실되지 않는 등을 RTP 프로토콜 수준에서 보증하는 것과 같은 실시간 서비스를 위한 서비스질을 권장하지 않는다. 데이터전송 프로토콜 즉, RTP는, 세션 제어(즉, 송신측으로부터 수신측으로의 RTP 전송)에 사용될 수 있는 제어 프로토콜(RTCP)이나 포괄적인 프리젠테이션 제어 프로토콜(RTSP)에 의하여 증가된다.
RTCP 및 RTSP 제어 프로토콜은, 예를 들어 전송경로를 설정하거나 닫는(tear down) 경우, 일 방향 전송(PLAY) 또는 타 방향 전송(RECORD)을 개시하는 경우, 전송 중단 등의 경우에 전송되는 신호화패킷(signaling packet)을 포함한다. 임의의 동기 참조(synchronizing reference)와 실시간으로 연속 가능한 한, 콘텐츠 데이터 패킷은 스트리밍 될 필요가 있다. 콘텐츠 패킷은 RTCP 및 RTSP 패킷과 동시에 전송되지만, 3개 각각의 프로토콜의 패킷은 다르게 주소지정된 논리 연결 또는 소켓을 사용한다.
RTCP/RTSP 제어 프로토콜 및 RTP 데이터 스트리밍 프로토콜은 함께 대규모 멀티캐스트 네트워크에 계위가능한(scalable) 도구를 제공한다. RTP와 RTCP는 그 기저에 놓여 있는 전송 및 네트워크 계층(layer)과 독립적으로 설계되므로, 다양한 선택적 계층과 함께 사용될 수 있다. 원할 경우, 프로토콜은 RTP-수준의 번역기 및 믹서(mixer) 사용 또한 지원한다.
RTP 제어 프로토콜(RTCP)은, 서비스의 품질을 모니터링하고, 진행 중인 세션에서 참여자에 관한 정보를 전달하는 능력을 갖는다. 참여자 정보(participant information)는, "느슨하게 제어되는(loosely controlled)" 세션, 예를 들어 뚜렷한 회원(membership) 제어 또는 설정은 없지만 주어진 응용 프로그램이 인증이나 통신 요건을 더 요구하는 경우에 충분한데, 이러한 경우는 일반적으로 RTSP 세션 제어 프로토콜의 영역이다.
송신측와 수신측 사이에서 스트리밍 되는 RTP 데이터 콘텐츠 패킷은 실시간으로 수신측 주소를 향하여 단순하게 통과한다. 패킷은 실시간으로 통과되는 반면에, 수신장치에서의 버퍼링 저장은 거의 불필요하다. 동일한 이유로, 송신장치는 통상적으로 임시 파일을 생성할 필요가 없다. HTTP 객체 전송과 같은 일부 다른 프로토콜과 달리, RTP는 매체-특정 헤더를 사용하여 객체를 패킷화(packetize)한다. RTP 수신기는 신호화(signaling) 능력을 재시도하기보다는 패킷 손실로부터 회복되도록 구성된다. RTP 전송은 TCP/IP 무연결(connetion-less) 프로토콜을 채택할 수 있다. 통상적으로, RTP전송은 RTP 데이터의 사용자 데이터그램 프로토콜(UDP) 패킷 전송으로 수행되지만, 일반적으로, 필수적으로 하나의 RTP 패킷을 구성하는 각각의 UDP 패킷으로 수행되지는 않는다.
RTP 패킷은, 패킷을 RTP로 식별하는 고정 헤더, 패킷 일련 번호(sequence number), 타임스탬프(timestamp), 동기 송신측 식별자, 송신측 식별자에 기여하는 가상 공리스트(possibly empty list), 및 페이로드(payload) 데이터를 갖는다. 페이로드 데이터는 음성 샘플 또는 압축 영상 데이터와 같은 데이터 값의 주어진 카운트(count)를 포함한다.
제어 패킷(RTCP) 및/또는 세션 제어 패킷(RTSP)과 비교하여, 별도의 실시간 데이터 컨텐츠 패킷(RTP)을 이용하는 시스템의 일 측면은, 3가지 타입 또는 패킷 모두가 동일한 데이터 경로를 통하여 주파수 및 기능을 달리하여 송신 및 수신된다는 것이다. 수신장치에, 네트워크 연결 오락 시스템, 영상회의 시스템, 네트워크 부착 저장장치 등과 같은 처리장치를 제공하는 것이 가능하며, RTP 패킷과 RTCP 또는 RTSP 제어 패킷을 적절히 구분하도록 처리장치를 프로그램하는 것이 가능하다. 데이터 패킷은 그들의 수신측을 향하여 통과되고, 제어 패킷은, 처리장치가 다른 프로그램된 기능과 정보전달을 수행하는데 사용된다. 그러한 시스템이 페이스를 유지하기 위해서는, 중앙처리장치가 RTP 데이터 패킷을 실시간으로 통과시킬 수 있도록 고 데이터율로 동작하여야 한다. 또한, 처리장치는, 잠재적으로 포함되어 있는 제어과정들을 취급하는데 필요한 연산 복잡성과 프로그램밍을 가지고 있어야 한다. 처리장치는 신속하고 유능해야 하지만, RTP 패킷을 단순히 통과시키는 경우에는 처리장치의 연산복잡성은 사용되지 않으며, 비교적 드문 제어 연산을 취급하는 데에는 처리장치의 고 데이터율 능력이 필요하지 않다.
본 발명의 일 측면은, 중앙처리장치(또는 처리장치)의 연산력이 RTP 데이터의 루틴한 통과를 처리하지 않고 특별케이스 세션과정을 위하여 자유롭지만 일반적으로는 RTP 세션의 안정상태(steady-state) 처리와는 분리되도록 RTP 데이터 및 신호화 데이터를 위한 별도의 데이터 경로를 제공하는 것이다. 데이터 스트리밍을 위한 하드웨어 전환장치와, 상이한 입력 및 출력 프로토콜, 장치, 주소지정, 기능과 같은 상위 및/또는 하위 응용계층에서 다중 지원 프로토콜의 복잡성을 취급하는 중앙처리장치를 이용함으로써 성취될 수 있는 이행 이점 덕분에, 이러한 분할은 장점을 갖는다.
도 1은 서버(즉, 스트리밍 데이터의 송신측)와 클라이언트(수신측) 사이에 배치된 제어 포인트를 갖는 간단한 네트워크 환경을 도시하고 있다. 각각의 상호연결은 RTP 스트리밍을 위한 다양한 지원 패킷 타입으로 표시되어 있다. 본 발명은 제어 포인트를 포함하는 다양한 구성으로 광범위하게 응용될 수 있는데, 기재된 것처럼 하드웨어 가속장치를 사용하여 메시지 헤더 내의 필드가 대체되는 기술을 제공함으로써, 적어도 부분적으로는 제어 포인트에서의 처리의 필요성을 우회한다.
도 2는 제어 포인트가 네트워크를 통하여 패킷 송신측(서버로 도시)으로 연결되는 중앙처리장치로 대표되는 예시적인 상황을 도시하고 있다. 도시된 구성에서, 통상적으로 중앙처리장치는 패킷을 하나 이상의 수신측으로 통과시키도록 요구받는데, 예를 들어 트래픽 관리기(manager)/중재기(arbiter)를 통하여, 패킷 스트림 중에서 확인된 패킷을, 패킷 송신측으로부터, 본 실시예에서 디스크 메모리 및 그 제어기로 대표되는 네트워크 부착 저장요소(network attached storage element) 또는 판독장치 등과 같은 하나 이상의 주소지정된 수신측으로 지정된다.
본 발명의 특징에 따르면, 우선 패킷 데이터는 네트워크 가속장치의 형상의 인터페이스장치에 의해서 취급된다. 네트워크 가속장치는 최소한 고속 처리장치(high throughput device)로 실시될 수 있는데, 연산적 정교성을 가질 경우 그 취급을 제어하기 위하여 착신 스트림 RTP 패킷에서 헤더값을 대체하도록 구성된다. 특히, 값들은 제어장치에 의하여 네트워크 가속장치의 컨텐츠 주소지정 메모리에 설정된다. 예를 들어, 그 값들은, 헤더값으로부터 패킷을 저장장치, 판독장치 또는 다른 로컬 수신측으로 경로 배정하는 로컬 주소값으로의 직접대체일 수 있다. 또는, 하드웨어 가속장치는, 동일 콘텐츠의 2 이상의 복사본을 신호경로를 효과적으로 분리함으로써 2 수신측으로 지정하는 것과 같은 다른 임의의 방법으로 패킷을 경로 배정하는 제어장치에 의하여 제어될 수 있다.
이러한 목적을 위하여, 하드웨어 가속장치의 컨텐츠 주소지정 메모리는 일련의 주소들, 헤더값, 플래그(flag) 등으로 로딩되는 표를 포함하는데, 주소들, 헤더값, 플래그 등은 스트림의 과정이 개시될 경우 특정 스트림에 대응된다. 추가적 패킷이 실시간으로 도착하자마자, 하드웨어 가속장치는, 표의 엔트리(entry) 사항을 연결된 스트림에 위치시키고 패킷의 헤더값을 콘텐츠 주소지정 메모리에 로딩된 값으로 부터 찾아내거나 생성한 헤더값으로 대체함으로써, 컨텐츠 주소지정 메모리의 해당 정보에 접속한다. 컨텐츠 주소지정 메모리의 값들의 최소의 서브셋(subset)은, 예를 들어 사용자 명령을 수행하는 제어 처리장치 내에 기원한 값들이다. 컨텐츠 주소지정 메모리의 값의 서브셋은 선택적으로, 제어 처리장치와 독립적인 하드웨어 처리장치의 동작에 의하여 생성될 수 있다. 예를 들어, 하드웨어 처리장치는, UDP 패킷의 손실로부터 회복하거나, 전환 기능 등 동안 부드러운 전이(transition)를 달성하는 등의 특정 상황 하에서 일련번호를 증가시키거나 타임스탬프 정보를 조절하는 카운터(couter) 또는 애더(adder)를 포함할 수 있다.
이 실시예에서의 특정 송신측 및 수신측 실체(entity)는 대표적인 예이다. 본 발명은 도시된 것과 같이 다소간 근접해 있거나 원거리에 있을 수 있거나 또는 데이터 통신에서 연결되어 있는 잠재 송신측 및 잠재 수신측의 다양성을 포함하는 상황에 응용될 수 있어, 주어진 시간에 그러한 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 요청은 클라이언트와 서버로 세션을 묘사한다. 어떤 경우에, 요청은 객체의 음성 또는 영상 성분과 같은 유용한 객체의 서브셋에 더 특별할 수 있다.
모든 필요한 SETUP 요청이 수행되고 인증되는 경우, 제어 포인트는 전송 방향에 따라 PLAY 또는 RECORD 요청을 수행한다(issue). 그 요청은 전달될 객체의 특정 범위, 객체의 정규적인 플레이 시간 및 재생이 시작되어야 하는 로컬 시간을 선택적으로 지정할 수 있다.
재생이 완료된 후, PAUSE 명령이 수행된 것처럼 프레젠테이션은 자동으로 중지된다. PAUSE 명령이 수행되면, 스트림이 중지되어야 하는 타임스탬프(timestamp)를 명시하고, 서버(클라이언트)는 연속되는 PLAY (RECORD) 요청이 수행될 때까지 데이터 전달을 중단한다.
TEARDOWN 요청이 수행되는 경우, 명시된 스트림 상에서 데이터 전달이 중지되고, 모든 연관된 세션 자원이 제거된다.
RTSP 명령어는, RTP/UDP 또는 RTP/TCP가 전송을 위하여 사용되는 대역외(out-of-band) 전송 세션을 명시할 수 있다. "대역외" 전송은 2개 이상의 별도의 전송 또는 연결 경로를 의미한다. 그 경우의 RTSP 트래픽은, 하나의 연결로 이루어질 수 있고, RTP 데이터의 실제 전송을 이행하는 RTSP에 의하여 다른 연결이 명시될 수 있다.
RTP 패킷은 TCP로 전송될 수 있다. TCP와 달리 유지된 연결을 요구하지 않으며, 손실된 패킷에 민감하지 않고/않거나 손실된 패킷을 탐지하여 복구하려고 시도하지 않기 때문에, UDP 전송은 일반적으로 비효율적이다. UDP 전송 프로토콜은 음성 또는 영상 데이터 샘플값과 같은 패킷을 실시간으로 전송하는데 적합하다. 이러한 값들은 개별적으로 중요하지는 않지만, 데이터 양이 큰 경우의 이동에 필요하다. 연결이 설정되고, 예를 들어, 재전송함으로써 패킷 손실을 복구하려고 하는 것 등과 같이 신뢰성을 강조한다는 점에서 TCP는 UDP와 다르다. 이러한 측면은 UDP보다 RTP의 필요성에 덜 일치된다. 이러한 개시(disclosure)는 일반적으로 UDP가 RTP 전송을 위해서 사용된다는 것을 가정한다. 그러나, 그 개시가 바람직하게 UDP 전송으로 한정하는 것으로 간주되어서는 안 되며, 오히려 다른 프로토콜로서 TCP를 포함하는 것으로 간주되어야 한다.
서버가 RTP를 사용하여 전달된 객체에 대한 요청을 수신할 경우, 통상적으로 객체는 원시(native) 포맷으로부터 패킷화(packetizable) 포맷으로 코드변조(transcode)된다. 기술된 바와 같은 데이터 패킷화와 관련되고 온라인 접속을 위하여 유지되는 문제점을 해결하기 위하여, 예를 들어 인터넷 엔지니어링 태스크포스(ieft.org)에 의하여, 산업계에서는 주어진 다양한 매체 타입에 대한 연관 RFC를 포함하는 많은 수의 "인터넷 기술 관련 문서(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)
- 중요한 데이터 요소를 위한 반복 패킷
- 음성/영상 디먹싱(demuxing)
- 또는 1.1.3 RTCP
주기적으로 주어진 RTP 세션이 활성화되는 동안, 세션에 관한 제어 정보는 RTCP를 사용하는 별도의 연결상으로 교환된다(UDP의 경우, RTP 세션은 짝수 수신측 포트를 사용하며, RTCP 정보는 다음 상위 홀수 수신측 포트를 통하여 전달된다.). RTCP는 데이터 분배의 품질에 대한 피드백을 제공하는 것을 포함하는 다양한 기능을 수행하는데, 피드백 제공은, 특히 IP 멀티캐스트 전송의 경우에, 네트워크 문제가 로컬적인지 전체적인지를 서버가 결정하는데 유용할 수 있다. RTCP는 또한 RTP 송신측에 대한 영구 전송-수준 식별자, 즉 CNAME를 운반하도록 동작한다. 충돌 또는 프로그램 재시작이 IDS의 이동(migration)을 야기할 수 있으므로, 수신장치는, CNAME가 각 참여자를 추적할 것을 요구한다. 또한, CNAME는 다양한 RTP 세션으로부터 다중 관련 스트림을 동기화(예를 들어, 음성 및 영상을 동기화)하는데 사용될 수 있다.
전송의 모든 참여자가 RTCP 패킷을 전송하도록 요구된다. 세션 내의 참여자의 수가 증가할 경우에는, 각 참여자에 의하여 전송되는 패킷의 수는 바람직하게는 감소한다. 각 참여자가 RTCP 패킷을 다른 모든 참여자에게 전송하도록 함으로써, 각 참여자는 참여자의 숫자를 추적할 수 있다. 이어서, 이 숫자는 제어 패킷이 전송되는 속도를 측정하는데 사용된다. RTCP는 사용자 인터페이스에 표시되는 참여자 정보와 같은 최소 세션 제어 정보를 전달하는데 사용될 수 있다.
이러한 임무를 달성하기 위해서, RTCP 패킷은 이하의 카테고리 및 포맷 중의 하나에 속할 수 있다.
- SR: 활성 송신장치인 참여자로부터 송신 및 수신 통계를 위한 송신장치 보고(sender report);
- RR: 활성 송신장치가 아니고, 31개 이상의 송신측을 보고하는 활성 송신장치를 위한 SR과 결합하는 참여자들로부터 수신 통계를 위한 수신장치 보고(receiver report);
- SDES: CNAME를 포함하는 송신측 기술 아이템(source description item);
- BYE: 참여자의 종단을 지시함; 그리고,
- PP: 응용-특정 기능.
RTP와 마찬가지로, RTCP 패킷의 각 형태는 가변길이 서브헤더가 수반되는 공용 헤더로 시작된다. 하위-계층 프로토콜의 단일 패킷에서 함께 전송될 수 있는 복합 패킷(compound packet)을 형성하도록 다중 RTCP 패킷은 서로 연결될 수 있다.
본 발명의 일 측면은, 하드웨어-단독(hardware-only) 해답이나 소프트웨어-단독(software-only) 해답을 제공하는 대신에 하이브리드(hybrid) 하드웨어 및 소프트웨어 해답을 제공함으로써 통합 RTSP/RTP 해답의 구현을 개선하는 것이다. 비록 모든 제어 상황 시나리오를 위하여 제공하지만, 어떠한 전(全)-하드웨어(all-hardware) 해답도 어느 정도 복잡하게 된다. 이와 대비적으로, 처리장치를 구비하고 그러한 복잡성을 다룰 수 있도록 코딩하는 어떠한 소프트웨어-단독 해답도 완전히 개발되지는 않았다. 주어진 스트림이 진행 중인 후의 대부분의 작동에 대하여, 주어진 스트림을 위한 연속 패킷을 이전 패킷과 동일한 방법으로 계속 취급하기 위한 많은 작동은 반복적인 작동을 이용하여 취급되고 연산력을 요구하지 않는다.
본 발명의 바람직한 실시예에 따르면, 제어처리가 대규모로 설정되고 잠재적으로 복잡하고 유능한 소프트웨어 프로그램을 동작하는 제어장치에 의하여 배열되는 곳에서 하이브리드 해답이 제공된다. 그러나, 특화된 하드웨어는, 매체 객체와 소프트웨어에 의하여 생성된 지원 파일을 이용하여 전송을 가속하는데 사용된다.
그 상대적 복잡성과 작동의 희귀성(infrequency)에 의하여, 제어단계와 밀접한 관련이 있는 RTSP 및 RTCP 기능은 지나친 부담없이 중앙처리장치 상에 소프트웨어로 구현될 수 있다. 한편, RTP는 매체 스트림에서 서열적 혹은 준 서열적인 각 착신 및 발신 패킷을 실시간 데이터율로 처리할 것을 요구하는데, 본 발명에 따라 하드웨어 가속으로 이점이 발생된다.
스트리밍 기능성의 특정 서브셋을 구현하기 위한, 즉 RTP 컨텐츠를 오프로딩(offloading)하는 하드웨어로 RTSP/RTP를 채용하기 위한 작동의 예가 여기에 기술된다. 이러한 기능성은 개인용 영상 기록장치(PVR)에서 공통적으로 발견되며, 종단점으로부터 RTP-요약(encapsulated) 데이터의 입력 스트림을 즉시 받아들이거나 동일한 RTP-요약 데이터를 동일한 종단점 또는 상이한 종단점으로 보내는 임의의 시간구간 후에 받아들이는 것으로 기술될 수 있다. 종단점이 일시적일 수 있고, 예를 들어 사용자 선택에 따라 변경 또는 전환될 수 있다는 것은 그러한 기능의 속성이다. 언급한 바대로, 종단점의 특유 속성은 본 발명의 동작에 중요하지 않다. 종단점은 영상 카메라 및 재생 수신장치와 같은 최초 또는 최후 표시장치, 또는 압축/압축해제 또는 포멧변환 장치와 같은 매개 요소장치일 수 있으며, 또는 앞의 요소 및 패킷 데이터 신호가 지정되거나 패킷 데이터 신호가 유래하는 스트림 내의 다른 요소의 결합일 수 있다.
도 2에 도시한 바와 같이, 매체 스트리머는 3개의 주 설계개체(main architectural entities), 즉 중앙처리장치, 트래픽 관리자/중재기, 네트워크 프로토콜 또는 하드웨어 가속장치를 포함한다. 이러한 구조는 물리적 실시예에 따라 변경될 수 있고, 회로 대비 제어처리 관점에서 다소간 복잡할 수 있다. 특정 동작 요소가 다소 단단하게 연결되는 방법으로 회로가 구현되는 한, 여기서는 그러한 요소의 특정 기능은 본 발명에 따른 RTSP/RTP 트래픽의 취급에 부속되는 것으로 정의된다.
중앙처리장치는 시스템 처리를 제어한다. 네트워크 프로토콜 가속장치 또는 "하드웨어 가속장치"는 자원-집중적이지만 아마도 반복적이거나 되풀이되는 처리 태스크를 취급한다. 이러한 방법에 있어서, 하드웨어 가속장치는 고주파 저복잡성 동작에 있어서 중앙처리장치의 부담을 경감한다. 부분적으로는 착신 RTP 헤더(도 3에 도시)에 의하여 제공되고 부분적으로는 스트림을 설정할 때 제어장치(39)에 의하여 설정된 값에 의하여 제공되는 정보를 기초하여, 도 4에 도시된 로컬헤더는 패킷(도 4에 도시된 22)의 RTP 헤더에 선행하여 배치될 수 있다. 이러한 방법에 있어서, 콘텐츠 주소지정 메모리를 이용하여 대체된 프로그램-작용(affected) 로컬 주소지정 헤더 필드와 함께, 그리고 각 패킷을 제어장치(39)를 통하여 통과시킬 필요없이, 데이터 흐름은 도 5의 블럭 다이어그램에 도시된 바와 같이 진행된다.
네트워크 하드웨어 가속장치는 콘텐츠 주소지정 메모리(CAM) 또는 메모리에서 상호 참조되는 값들의 표를 포함하는데, 최소한 현재 진행 중인 스트림에 대한 것이다. 콘텐츠 주소지정 메모리는 하드웨어-가속 연결을 위한 연결 매개변수저장하는데, 하드웨어-가속 연결은 장치를 전체로 사용할 수 있는 연결들의 최소 서브셋을 포함한다. 하드웨어 가속장치는, 착신 패킷이 콘텐츠 주소지정 메모리에 저장된 메세지 큐 정보에서 이미 설정된 스트림과 관련되는지를 결정하는데 충분한 회로를 포함한다. 만약 메세지 큐 엔트리(entry)가 존재하면, 하드웨어 가속장치는 메세지 큐에 의하여 이미 결정된 방법으로 착신 패킷을 취급한다. 만약 패킷이 현존하는 엔트리를 갖지 않는다면, 하드웨어 가속장치는 해당 패킷이 가속된 스트림의 일부가 되는 것처럼 새로운 메세지 큐 설립을 중앙처리장치로 넘긴다. 패킷의 취급 방법은, 패킷 헤더값을 로컬주소로 교체하는 것, 특정 상황을 극복하기 위하여 헤더값을 개정하는 것, 다른 수준의 프로토콜과 관련된 값을 변경하는 것 등을 포함한다.
트래픽 관리기/중재기는 착신 및 발신 네트워크 트래픽을 관리하는데 사용될 뿐만 아니라, 메모리 및 디스크 접속 중재(arbitration)를 제공하는데 사용된다. 트래픽 관리기/중재기는 다양한 하드웨어 가속 연결의 입력 및 출력에 할당될 수 있는 많은 큐와 중앙처리장치를 관리한다.
본 발명에 따른 방법이 도 4의 데이터 흐름 블럭 다이어그램과 도 6의 플로우차트에 설명되어 있다. 매체 스트리머 장치는, 종단점으로부터 RTP 패킷의 스트림을 받으며, 실시간 패킷에 보조를 맞출 수 있도록 충분한 효율 및 속도를 가지고, 또한 데이터 취급을 위한 요구에 있어서의 변경과 양립할 수 있도록 충분한 적용 유연성을 가지고 데이터를 처리하도록 구현되어야 하는데, 데이터 취급을 위한 요구에 있어서의 변경은, 예를 들어 종단점 또는 역동적 가변 RTP 페이로드 타입의 광(廣)배열, 송신측, 수신측을 포함하는 매개 요소와의 새로운 송신측/수신측 관계를 시작하거나 종료하는 것이다.
RTSP와 RTCP 동작은 드물게 일어나서 중앙처리장치에서 운영되는 소프트웨어에서 작동되도록 구현될 수 있고, 통상적으로 데이터 콘텐츠와 보조를 맞추는 문제의 유발없이 실행된 프로그램은 복잡할 수 있다. 그러므로, 바람직하게 이러한 기능들은 중앙처리장치에서 운영되는 소프트웨어에 구현된다.
한편, RTP 안정상태(steady-state) 스트리밍은 패킷의 반복적 취급을 포함하는데, 예를 들어 스트림의 모든 패킷을 스트림이 활성화되어 있는 동안 일시적으로 할당될 수 있는 특정 수신측을 지정하도록 하는 것을 포함한다. 이 기능은 네트워크 가속장치와 트래픽 관리기/중재기에 전용되는 하드웨어에서 취급된다.
그러나, 다수의 스트림이 동시에 활성화일 수 있다. 동일한 방법으로 주어진 스트림을 위한 패킷을 취급하기 위하여, 콘텐츠 주소지정 메모리는 수신측 주소, 마지막 패킷 일련번호 등과 같은 스트림에 응용가능한 값의 세트를 포함한다. 하드웨어 처리장치는 콘텐츠 주소지정메모리를 통하여 스트림 식별정보를 관련 패킷 데이터 값에 유지하는 레지스터를 포함할 수 있다. (게이팅(gating) 또는 단순연산을 포함할 수 있는) 비교처리에 의하여, 하드웨어 가속장치는 착신패킷 상의 식별정보를 콘텐츠 주소지정 메모리의 엔트리(entry)에 부합시키고, 부합된 패킷에 대한 정보를 출력으로 내보낸다. 이러한 처리는, 예를 들어, 헤더 주소정보와 같은 패킷 헤더의 데이터 값을 패킷이 관련된 스트림을 위한 콘텐츠 주소지정 메모리로부터 판독한 로컬 주소정보로 대체하는데 사용된다.
값의 대체는 간단하고 반복적인 처리로서, 도 9의 플로우 차트에 의하여 일반적으로 도시된다. 만약 다음 패킷이 현재 스트림의 일부에서 대면된다면, 다음 패킷은 큐 엔트리(queue entry)를 갖는다. 스트림 식별정보(예를 들어, 주소정보)는 큐, 즉 콘텐츠 주소지정 메모리에 있는 엔트리에 부합된다. 만약 엔트리가 발견되지 않는다면, 처리장치는 신호를 받고 엔트리는 처리장치에 의하여 설정되는데, 처리장치는 적절한 큐 엔트리 값을 결정하고 결정된 값을 하드웨어 가속장치의 콘텐츠 주소지정 메모리에 저장하도록 프로그램되어 있다. (처리장치 기능은 점선으로 표시된 상자 안에 도시되어 있다.) 계속되고 더 진행되는 처리 동안, 하드웨어 가속장치는 수신된 다음 패킷을 위한 엔트리를 결정하고, 원시 헤더값을 콘텐츠 주소지정 메모리로부터 구한 값으로 대체하고, 콘텐츠 주소지정 메모리의 해당 스트림을 위한 큐 엔트리가 소멸되는 스트림의 종료까지 이러한 처리를 계속한다. 스트리밍 장치는, 그에 의하여 자유로운 자원을 이용하는 새로운 연결을 지원하도록 준비된다.
중앙처리장치에 의하여 이행되는 소프트웨어 처리는, 예를 들어 사용자의 입력선택을 취급하기 위하여 시작, 종료, 특정 동작들 간에 전환할 수 있는 응용 프로그램 인터페이스(Application Program Interface; API)를 통한 하드웨어 요소에의 인터페이싱을 포함한다. API는 중앙처리장치와 하드웨어 유닛 간의 직접 인터페이스(예를 들어, 레지스터 읽기 및 쓰기, 하드웨어 큐 접속)를 가린다.
바람직한 예에서, 개인 영상 기록(PVR)장치의 기능성은 다음과 같이 구현될 수 있는데, 이러한 설명이 비제한적 예에 관계된다는 것은 이해되어야 한다.
중앙처리장치의 프로그래밍 내에서 운영되는 RTSP 기능은 수신되는 SETUP 명령과 데이터 패킷의 송신측 및 수신측일 수 있는 종단점을 모니터링하는 것이다. RTSP-SETUP 요구를 포함하는 패킷은 네트워크 가속장치에 의하여 수신되고, 그 안에서 식별된 스트림은 CAM 검색테이블(lookup table) 내의 엔트리에 부합되지 않는다. 네트워크 가속장치는 그 스트림을 적절한 트래픽 관리 큐(중앙처리장치를 위한 착신 트래픽에 관련된 큐)에 할당한다. 일단 RTSP 처리가 완벽한 SETUP 메세지를 받으면, CAM 검색테이블 매개변수(송신측 및 수신측 IP 주소, 포트, 전송프로토콜)는 SETUP 메세지로부터 (전체적으로 또는 부분적으로) 결정된다. CAM 테이블 내의 연결표 엔트리는 RTP 세션을 위하여 설정된다.
그리고나서, RTSP는 관련된 종단점으로부터의 연속적인 RECORD 요구를 기다린다. 만약 RTSP-RECORD 메세지가 수신된다면(또는 수신될 때), RTSP-RECORD 메세지는 SETUP 메세지와 동일한 경로를 통하여 네트워크 가속장치로부터 중앙처리장치의 트래픽 관리기로 통과된다. RECORD 메세지는 기록할 스트림의 (시간)영역을 포함할 수 있다. 이점에서, 세션은 설정된 것으로 간주될 수 있고 네트워크 가속장치는 데이터를 수신할 준비가 된다. 중앙처리장치는 영역을 근거로(만약 영역이 특정되지 않았다면, 최대값이 전송된다) 객체 크기를 전송하고, 유용한 큐 식별 QID는 스케쥴링을 위하여 트래픽 관리기에 제출된다. 이것은, 스트림이 변경없이 지속되는 한, 하드웨어 가속장치가 헤더값의 간단한 대체에 의하여 패킷을 처리할 수 있게 한다.
변경은 CAM 테이블 엔트리를 종료하거나 수정함으로써 이루어질 수 있는데, 예를 들어 만약 로컬 저장장치가 착신 스트림의 기록을 시작하도록 되어 있다면, 해당 스트림을 재생장치로 지정하게 하는 엔트리는, 패킷 역시 디스크 제어장치로 지정되도록 수정될 수 있다. 선택적으로, 스트림을 로컬 저장장치의 종단점과 연관되도록 하는 다른 엔트리가 추가될 수 있다.
RTP 종료 루틴, 조건에 의하여 변하는 전환동작, 그리고 유사한 연산 집중 기능은 너무 복잡해서 상대적으로 간단한 하드웨어에서는 실행될 수 없다. 실시간과 같은 스트리밍 데이터 패킷의 시간 압력은 너무 엄격해서 중앙처리장치가 항상 시기적절한 방법으로(즉, 작동중인) 착신 트래픽을 효과적으로 취급하는 대용량 프로그램을 사용할 수 없게 한다. 본 발명은 스트림의 각 패킷이 네트워크 가속장치에 의하여 수신되는 교체적 방법을 구성하는데, 네트워크 가속장치는 연결테이블의 패킷을 부합시키고, 계층 3 혹은 4의 헤더를 제거하고, 로컬 헤더를 적용하고, 로컬 디스크와 같은 수신측에 쓰기(write) 위하여 각 패킷을 로컬 헤더, RTP 헤더, RTP 페이로드와 함께 트래픽 관리기로 전송한다.
착신패킷의 포멧은 로컬 헤더가 패킷의 총 길이를 위한 값과 요구 플래그를 구비한 32-비트 양을 포함하도록 이루어진다. 이러한 필드는 각 RTP 패킷의 경계를 정의하고 패킷이 디스크에 저장된 후 유용하게 남는다. 객체가 이러한 포멧에 저장되어있는 동안, 저장된 패킷은 승인(acknowledgement)의 원시 종단점으로 재 전달되도록 예정될 수 있고, 혹은 네트워크 상의 다른 종단점으로 경로 배정될 수 있다. 트래픽 관리기는, 로컬 헤더로부터 각 패킷의 길이 필드를 추출하여 전송크기로 사용할 수 있도록 객체를 패킷 단위로 판독하는 능력을 가져야한다. 트래픽 관리기는 데이터의 길이 바이트를 네트워크 가속장치로 전송하고 큐를 다음 패킷의 시작으로 삼는다.
패킷이 트래픽 관리기로부터 수신될 경우, 네트워크 가속장치는 로컬 헤더를 제거하고 오프셋(offset)을 부가한다. 오프셋은 최초에 중앙처리장치에의하여 결정되고, 관련된 전송을 위한 콘텐츠 주소지정 메모리(CAM) 테이블의 필드에 저장되어 하드웨어 가속장치에 의하여 발신패킷 RTP 헤더에 위치하는 일련번호(Sequence Number) 필드를 결정하는데 기여한다. 이것은 RFC 3550에서 특정된 것과 같이, 무작위(random) ISS의 규정을 가능케 한다.
발신 타임스탬프는 유사한 방법으로 조정된다. 이것은 RFC 3500에서 특정된 것과 같이, 무작위 ITS의 규정을 가능케 한다.
계층 3 및 계층 4의 헤더는 유사하게 구성되고 발신 패킷의 헤더에 위치한다. 발신패킷은 MAC/PHY 블록으로 전송된다.
이러한 방법의 하나의 장점은 착신 RTP 트래픽이 소프트웨어에 의하여 관리될 수 있다는 것이다. 다양한 상이한 RTP 페이로드 타입이 사용되거나 아마도 정의를 변경함에 따라, 이들에 대한 지원은 강력한 스트리밍 장치에 의하여 유지될 수 있다. 또한, 기록중 지연시점(delayed-view-while-recording)인 PVR 기능성이 지원될 수 있다.
단점은, 객체가 RTP 헤더 포멧에 저장되어 있는 동안, HTTP 전송을 위한 접속이 불가능하다는 것이다. 호스트 중앙처리장치의 소프트웨어는, 비 RTP 클라이언트(non-RTP clients)에게는 즉시, 혹은 어떠한 클라이언트에게도 필수 자원이 유용할 때까지 연기된 재구성에 의하여 객체를 유용하게 만들기 위하여 원시 매체 객체를 재구성하는데 사용될 수 있다.
바람직한 실시예인 도 7에 관하여, 본 발명은 디스크 어레이 제어장치를 포함하는 데이터 조작 시스템에 통합된다. 이 장치는 저장관리를 수행할 수 있고, 고객 전자 디지털 매체 응용기기(customer electronics digital media applications) 또는 통신 및 원격회의와 같은 유사한 특성을 갖는 다른 응용기기에 도움을 줄 수 있다. 오락 응용기기에서, 장치는 홈 네트워크와 데이터 저장장치의 어레이 간에 인터페이스를 제공하는데, 데이터 저장장치는 일반적으로 디지털 매체(음성, 영상, 이미지)를 저장하기 위한 하드디스크 드라이버(HDDs)를 예로 들 수 있다.
바람직하게 장치는, 홈 네트워크로의 또는 다른 근거리 통신망(LAN)으로의 인터페이스를 위한 통합 10/100/1000 이더넷(Ethernet) 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개의 동시 쌍방향 스트리밍을 취급할 수 있는 성능을 포함한다.
데이터 조작 시스템은 본 발명에 대한 다양한 가능한 응용기기의 예시인 한, 전체적인 데이터 조작 시스템은 도 7에 도시되어 있고 단지 일반적으로 설명되어 있다. 장치 내에는 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)로 표시(tag)된다. 알려지지 않은 연결로부터의 패킷은 응용 처리장치(AAP) 및 그에 의한 추가 조사를 요구한다. 그 패킷은 특정 QID로 표시(tag)되어 AAP로 경로 배정된다. AAP 이후 도달 패킷의 최종 수신측은, 패킷이 매체 콘텐츠를 운반하는 경우에는 저장을 위한 하드 디스크이고, 패킷이 제어 메시지를 운반하거나 또는 패킷이 AAP에 의하여 인식될 수 없는 경우에는 추가 조사를 위한 AAP인데, 후자의 경우 새로운 큐 ID 확립으로 잠재적으로 유도된다. 위의 조건 중 어느 경우에도, 패킷은 TMA 블록으로 전송된다.
TMA는 공유 메모리 내에 도달 트래픽을 저장한다. 매체 객체 전송의 경우, 착신 객체 데이터는 메모리에 저장되고, 디스크 저장을 위해서 RAID 디코더 및 인코더(RAID Decoder and Encoder; RDE) 블록으로 전송된다. TMA는 RDE로 적절한 제어 정보를 제공함으로써 저장 처리를 관리한다. AAP 점검을 위한 제어 트래픽 또한 공유 메모리에 저장되고, 메모리 내의 패킷을 판독할 수 있도록 AAP에게 접근(access)이 주어진다. 또한 AAP는 순서에 맞지 않게 수신된 패킷들 중 어느 것에 대해서도 재-정리하기 위하여 이 메커니즘을 사용한다. 공유 메모리 및 디스크의 일부분은 AAP를 위한 프로그램 명령 및 데이터를 포함한다. TMA는 디스크로부터 메모리로, 메모리로부터 디스크로 제어 정보를 전송함으로써 메모리 및 디스크에 대한 접속을 관리한다. 또한 TMA는, AAP가 현재의 패킷 스트림으로 그리고 현재의 패킷 스트림으로부터 데이터를 삽입하고 추출할 수 있게 한다.
전송 데이터 경로에서, TMA는, 응용 처리장치(Application Processor) 또는 네트워크 인터페이스를 통한 전송이 필요한 것으로 처리될 예정인 디스크로부터의 객체 복원 요청을 관리한다. 응용 처리장치로부터의 매체 재생 요청을 수신하면, TMA는 MDC 및 RDE 블록을 통하여 디스크로부터 전송된 데이터를 수신하고 메모리에 저장한다. 이어서 TMA는 요구되는 대역폭 및 매체 타입에 따라 데이터를 ULP 블록에 기재한다. ULP는 각각의 발신 패킷에 대한 이더넷 및 계층3/계층4(L3/L4) 헤더로 해당 데이터를 요약한다. 이어서 패킷은 특정된 수신측 포트에 근거하여 GEC 또는 PTC 블록 중 하나로 전송된다.
수신 데이터 경로 상의 착신 패킷과 관련해서, 네트워크 가속장치의 연결 검색 기능부는 주소 형성, CAM 테이블 검색 및 연결 테이블 검색 기능 블록을 포함할 수 있다. CAM 점검 주소는 부분적으로 착신 패킷 헤더로부터 추출된 정보의 결과로서 형성된다. 추출되는 헤더 필드의 세부사항은 사용 중인 트래픽 프로토콜에 달려 있다. 형성되고자 하는 주소는 고유 연결(unique connection)을 대표하여야 한다. 예를 들어, IP V4 및 TCP/UDP 프로토콜에서 이행되는 가장 대중적인 인터넷 트래픽과 관련해서, 송신측 IP 주소, 수신측 IP 주소, TCP/UDP 송신측 포트 번호, TCP/UDP 수신측 포트 번호 및 프로토콜 타입(패킷 헤더로부터 소위 "5 투플(tuple)"로 불림)이 고유 연결을 정의한다. 만약 패킷이 (IP V6와 같은) 다른 트래픽 프로토콜인 경우라면 다른 필드가 연결을 결정하는데 사용될 수 있다. 다중 프로토콜이 제공되는 경우에는 플래그 및 식별 코드와 같은 적절한 제어를 참조할 수 있어서, 시스템을 "프로토콜 인식" 계층형(hierarchical) 시스템으로 만든다. 예를 들어, 처리 과정은 각각이 지원되는 프로토콜 수준에 대응하는 3개의 스테이지로 구분될 수 있다. 제1스테이지는, 헤더 분석 처리 동안 추출되고 주소 형성 처리의 일 단계로서 도달 패킷을 위한 정보 버퍼 엔트리에 저장되는 필드로부터 L3 프로토콜의 버전 번호를 점검할 수 있다. 주소 형성 처리의 제2 및 제3스테이지를 위하여, 복합(composite) 하드웨어 테이블이 제공된다. 각 스테이지에서 테이블 엔트리 번호는 테이블이 삽입되는 스테이지 및 각 스테이지에서 지원되는 상이한 프로토콜의 숫자에 달려 있다. 각 테이블 엔트리는 항상 콘텐츠 주소지정 메모리(CAM) 엔트리와 위치번호 레지스터(position number register)로 구성된다. 각 위치번호 레지스터는 항상 한 쌍의 오프셋-크기 필드로 구성된다. 각 CAM 엔트리는 상응하는 위치 레지스터에 대한 특정 프로토콜 값을 저장한다. 오프셋은 패킷 헤더의 시작점으로부터 추출되는 필드까지 건너뛰는 바이트 숫자를 특정한다. 크기 필드는 추출되는 니블(nibbles)의 숫자를 특정한다. 동일한 주소가 CAM 필드 및 위치 레지스터 모두에 접속하기 위해서 사용된다.
특정 프로토콜 수준에서 헤더 길이가 고정되지 않는 것이 가능하다. 예를 들어, TCP와 IP 헤더 길이는 "선택(option)" 필드에 의하여 변경될 수 있다. 외부 수준 프로토콜로부터의 잠재 가변 헤더 길이는 상대적으로 필드 위치를 내부 수준 헤더 길이 그 자체를 포함하는 내부 수준 프로토콜에 옮겨 놓는다. 가변 헤더 길이를 수용하기 위하여, 프로토콜 헤더 길이 필드는 길이 필드를 포함하는 그 수준들을 위한 주소 검색 처리의 일부로서 추출될 수 있다. (IP V6 및 UDP와 같은) 일부 프로토콜은 헤더에 길이 필드를 갖지 않는 것이 가능하다. 그런 경우, 어떠한 헤더 길이도 추출될 수 없지만, 주어진 연결동안 고정 헤더 길이의 설정 및 유지와 같은 다른 기술이 채용되는 것이 가능하다.
주소 형성 처리는 도 8에 그래프로 도시되어 있다. 주소 형성 처리 동안, 패킷은 버퍼(buffer)되고, 프로토콜의 제1수준(예를 들어, IP 프로토콜을 위한 버전 번호)은 식별되고 패킷 정보 테이블에 저장된다. 주어진 시간에 패킷 정보 테이블에는 많은 엔트리가 존재하고, 엔트리는 패킷 정보 버퍼의 헤더에서 처음 접속된다. 길이 엔트리가 존재한다면, 헤더 길이(예를 들어, IP 헤더 길이)는 패킷 정보 테이블로부터 추출된다. 제1스테이지로부터 추출된 프로토콜 타입 코드는 제2스테이지 프로토콜 값을 발견하는 곳에 영향을 미친다.
CAM은 프로토콜과 오프셋의 어떠한 가능한 조합도 지원한다. 결정된 제1오프셋-크기 값은 프로토콜의 제2수준(본 예에 있어서, IP 프로토콜을 위한 프로토콜 필드)의 추출을 이끌어 낸다. 위치번호 레지스터 엔트리는 각 스테이지에서 CAM 엔트리의 숫자와 일대일 대응한다. 제2스테이지에는 각 엔트리를 위한 2쌍의 위치 레지스터가 존재한다. 만약 존재한다면, 헤더 길이 필드(예를 들어, IP 헤더 길이)는 제2위치 레지스터 쌍에 특정된 오프셋에 따라 패킷 헤더로부터 추출된다.
제3스테이지에서의 필드 추출 처리는 제2스테이지에서의 그것과 유사하다. 그러나, 제3스테이지에서의 CAM 접속은 제1 및 제2스테이지 등으로부터 추출된 프로토콜 타입의 연관을 반영하여야 한다. 여기서 8개의 필드로부터 값을 추출하기 위한 8쌍의 오프셋-크기 필드가 존재한다. 프로토콜 타입 값의 관점에서, 각 엔트리에서 추출된 다수의 필드는, 값을 함께 연관시켜 최종 주소를 형성하도록 하여 엔트리를 식별하는데 사용된다.
버퍼 또는 주소 형성 레지스터와 콘텐츠 주소지정 메모리에 접속하는 필드는 네트워크 가속장치에 의하여 처리된다. ULP에서 제어 처리장치는, CAM에 있는 요구값의 주소를 결정하기 위하여 검색 주소를 구성하는데 필요한 값을 읽기만 한다. 주소 형성 처리 동안 만약 CAM 검색에 실수가 있다면, 처리는 중지되고 착신 패킷은 에러 플래그로 표시(tag)된다.
만약 각 스테이지에서 추출된 프로토콜 필드가 상이한 프로토콜에 대하여 상이한 길이를 갖는다면, 고정 오프셋 크기를 획득하도록 엔트리를 채우는(pad) 것이 가능하다. 미사용된 비트 패드 메모리는, 고정 길이 CAM 검색이 가능하도록 최대한 고정 크기까지 주소를 지정한다.
주소 형성 레지스터의 차원(dimensions)은 요약될 수 있다. 제2스테이지는 2개의 레지스터 엔트리, 2개의 CAM 엔트리, 각 메세지 큐 엔트리를 위한 1쌍의 위치 레지스터를 포함한다. 제3스테이지는 8개의 레지스터 엔트리, 8개의 CAM 엔트리, 8쌍의 위치 레지스터를 포함한다. 각 위치 레지스터는, (512 바이트를 커버하는) 오프셋을 대표하는 10 비트, (64 니블을 대표하는) 크기를 위한 6 비트로 구성되는 16 비트를 포함한다.
주소 지정 섹션에 형성된 값은, 연결이 설정되었을 때, 즉 특정 송신측 및 수신측 지점 간의 특정 데이터 전송을 위한 연결의 개시를 신호하는 패킷의 도착 시에 제어 처리장치(즉, 응용 처리장치)에 의하여 기 저장된 정보와 함께 사용된다. 제어 처리장치는 컨텐츠 주소지정 메모리(CAM)에 엔트리를 배치한다. CAM에 있는 각 엔트리는 고유하게 연결을 결정한다.
시스템이 개시될 때(즉, 전송연결이 설정되기 전에), CAM에는 엔트리가 존재하지 않는다. 그러므로, 제1패킷이 도달할 때, CAM에는 주소정보와 부합되는 어떠한 부합 주소 엔트리도 발견되지 않으며, 패킷은 임시로 CAM 검색 실패로 간주된다. 그럴 경우, 특별한 큐 ID(QID)가 패킷을 제어 처리장치(즉, 응용 처리장치 AAP)를 위하여 예약된 메모리 위치에 할당한다.
AAP는 도달패킷을 분석하여 연결을 설정할 필요성을 결정한다. 자유 엔트리는 CAM(예를 들어, 시스템이 동시에 지원하는 64개의 가능 스트림 중의 하나)에서 발견된다. 자유 엔트리 주소는 새로운 스트림에 대한 연결 테이블을 설정하는데 사용된다. AAP는 연결 주소를 CAM의 자유 엔트리에 써서(write) 동일 주소의 나중 도달 패킷이 CAM의 엔트리와 부합되도록 한다. 이것은 AAP의 처리 요청없이 나중 도달 패킷이 취급되는 것을 허여하는데, 패킷은 논의된 네트워크 가속장치 기능에 의하여 취급되기 때문이다.
도달 패킷이 CAM의 엔트리를 갖는 존재하는 연결과 부합되는 것이 발견될 경우(CAM 히트), 부합되는 CAM 엔트리의 주소는 연결 테이블 정보, QID 및 그 외 정보를 검색하는데 사용된다. 논의 중인 예에서는, 64개의 연결을 지원하기 위하여 64개의 CAM 엔트리가 존재한다. 각 CAM 엔트리는 최대 256 비트까지 할당된다. 물론 다른 특정 카운트도 가능하다.
점유(occupied) CAM 엔트리 및 자유 CAM 엔트리 모두는 제어 처리장치 AAP에 접속할 수 있다. 제어 처리장치 AAP는 CAM 엔트리의 설정, 종료 및 순환에 책임이 있다.
일반적으로는 레지스터와, 잠재적 입력 데이터 값의 적어도 하나의 서브셋을 메모리로부터 대응되는 출력 데이터 값을 추출하는 주소지정 입력으로 사용되도록 하는 게이팅 배열(gating arrangement)을 포함하는 CAM 장치 그 자체는, 다양한 방법으로 실시될 수 있다. 무작위 접속 메모리(random access memoty) 장치는 통상적으로 메모리 위치에 대응되는 각 가능 입력 값을 특정 메모리 위치로 주소지정함으로써 데이터를 저장하고 검색한다. 대규모의 주소지정 비트는 대규모의 메모리 위치에 대응되고, 메모리 엔트리의 숫자가 크지 않을 경우에는 메모리 주소의 특정보다는, 메모리의 저장된 데이터 콘텐츠의 일부와의 디지털 비교를 가능하게 하는 하드웨어 게이팅 배열에 의하여, 메모리에서 주어진 엔트리를 발견하기 위하여 요구되는 시간이 감소될 수 있다. 이러한 방법으로 접속된 메모리는 콘텐츠-주소지정 메모리(CAM)로 불리우고 논의된 타입의 응용기기에서 장점을 갖는다.
논의 중인 예에서, CAM은 4 부터 144 비트까지의 저장된 값의 폭에서 변할 수 있고, 6 부터 1024 엔트리까지의 깊이를 갖는다. 도 9에 도시된 일 실시예에서는, 각각이 최대 64개의 양방향 스트림을 지원하기 위하여 129 비트 장치에 의한 64 엔트리를 포함하는 2개의 연결 CAM 장치가 제공된다. 129 비트 중, 128 비트는 데이터 저장을 위하여 사용되고, 1 비트는 엔트리-유효 비트로 사용된다. 256 CAM에 의한 64 엔트리를 형성하는 이러한 배치는 도 9에서 단순화된 CAM 검색 논리 다이어그램으로 대표되는데, 256 비트 워드(word)는 2개의 128 비트 서브 워드(sub word)로 나뉘어 지고, 각 서브 워드는 별도의 CAM 장치의 콘텐츠에 대하여 비교된다. 이러한 배치에서, 128 비트 서브 워드 중 하나 또는 다른 하나가 각 CAM 장치의 다중 엔트리에 부합되는 것이 가능하다. 그러나, 전체 256 비트 엔트리는 고유한 저장값에 단지 대응될 수 있다. 이러한 작동은 2개의 CAM 장치의 비교를 통합 주소지정(coordinated addressing)하고 종속 접속(cascading)함으로써 촉진된다.
도달 패킷에 대하여 CAM 히트가 존재할 경우, 도달 주소에 부합되는 엔트리의 CAM 주소는 연결에 관계된 다양한 정보값에 접속하는데 사용된다. 이러한 것들은 다음 표 1에 요약되어 있다.
| 필드명 | 크기(비트) | 설명 |
| QID | 6 | 검색 문제가 존재하지 않을 경우 트래픽 관리를 위하여 사용되는 큐 ID |
| 헤더_유지(Header_Keep) | 1 | 헤더 유지 비트는 패킷을 TMA로 전송할 때 ULP가 L2, L3 및 L4 헤더를 제거해야 할 지를 지시한다. 이 비트는 QID가 사용될 때에만 적용됨을 주지할 것. 에러_QID가 사용될 때, 헤더는 항상 유지된다. |
| OOS_QID | 6 | 아웃 오브 시퀀스 큐(Out Of Sequence Queue) ID: 이러한 QID는 이탈된 서열 패킷 등에 사용된다. |
| 로컬 헤더 인에이블(Local Header Enable) | 1 | 설정될 때, ULP는 로컬 헤더를 각 도달 패킷에 선-부가(pre-pend)한다. |
어떤 연결의 경우, 로컬 헤더는 생성되고 각 착신 패킷에 선-부가된다. 그러한 로컬 헤더 생성은 AAP에 의하여 설정될 수 있다. ULP 로컬 헤더는 패킷이 네트워크로부터 도달했을 때 만들어진다. 로컬 헤더는 도 10에 특정된 포멧으로 32 비트의 고정 크기를 갖는다. ULP는 각 수신 패킷 바이트를 카운트함으로써 유도되는 패킷 길이를 선-부가(pre-pend)한다. 또한, ULP는 기가비트 이더넷 제어장치(Gigabit Ethernet Contoller; GEC)에 의하여 그리고 검색으로부터 자신에 의하여 만들어진 플래그를 로컬 헤더로 삽입한다. ULP는, 로컬 헤더가 패킷 수신측에 상관없이 가능하게 되는 한, 로컬 헤더를 동일한 포멧으로 부가한다.
본 발명은 장치에 의하여 예시되지만, 방법으로도 고려될 수 있다. 도면을 참조하면, 본 발명의 스트리밍 장치(도 1, 2, 7)는, 제어값, 송신측 주소, 수신측 주소, 페이로드 타입 중 적어도 하나를 대표하는 필드(24)를 갖는 데이터 패킷(22)이 송신측(27)과 수신측(29) 사이로 지정되게 한다. 통신 경로(32)는 서버(27) 등으로부터 데이터 패킷을 수신하고, 데이터 패킷(22)의 적어도 하나의 콘텐츠 부분(33)은 데이터 패킷(22)의 상기 필드로부터 결정되는 규칙에 따라 적어도 하나의 클라이언트(35)로 전송된다.
규칙은, 데이터 패킷이 하나 이상의 클라이언트로 별개의 방법으로 전달될 수 있게 하는 선택적 방안을 포함하는데, 예를 들어 별개의 방법은 다른 특정 장치에 주소지정되는 것과 다른 프로토콜 취급 상세에 의하여 처리되는 것 등이 있다. 제어 처리장치(39)는 통신 경로에 연결된다. 제어 처리장치의 기능은 하나 이상의 상위 계층 처리장치(ULP) 및 응용 처리장치(AAP)에서, 또는 부가 제어장치에서 전체적으로 또는 부분적으로 제공될 수 있다. 어떤 경우이든 제어 처리장치는, 연결 또는 스트림을 설정할 때 패킷을 처리하기 위한 적어도 2가지의 대안에 적용가능한 처리절차를 최소한 부분적으로 결정한다.
본 발명의 일 측면에 따르면, 메모리(43)를 갖는 네트워크 가속장치(42)는 제어 처리장치(39)에 연결되는데, 제어 처리장치는 데이터 패킷을 별개의 방법으로 전달하는 적어도 2가지의 대안 처리절차를 대표하는 데이터와 함께 네트워크 가속장치의 메모리(43)를 로드(load)한다. 처리절차는 (이에 한정되는 것은 아니지만) 패킷을 별도의 로컬 또는 원격(remote) 주소로 지정하는 것을 포함한다. 그 이후, 네트워크 가속장치(42)는 데이터 패킷(22)을 클라이언트(35)로 전달하기 위하여 제어장치(42)와 실질적으로 독립적으로 작동가능하다. 데이터 패킷(22)은 필드를 포함하는 헤더(도 3의 24)를 갖고 네트워크 가속장치(42)는 적어도 2가지의 대안 중에서 선택하기 위한 상기 필드의 대체 및 부가 중 적어도 하나를 위하여 필드에 응답하도록 작동가능하다.
장치는 RTP 실시간 프로토콜 스트리밍을 취급하기에 적합하다. 데이터 샘플 또는 RTP에서의 데이터 프로그래밍과 같은 프로그램 콘텐츠를 포함하는 패킷에 부가하여, 데이터 패킷은 RTSP 및 RTCP 스트리밍 제어 프로토콜 중 하나에 따른 제어 정보를 더욱 포함한다.
바람직한 배치에 있어서, 네트워크 가속장치는 활성화동안 각 진행 중인 스트림의 데이터값을 갖는 콘텐츠 주소지정 메모리를 포함하는데, 예를 들어 데이터값은 로컬 주소지정을 위하여 사용된다.
제어장치는 주어진 스트림을 위하여 사용될 데이터값을 설정한다. 콘텐츠 주소지정 메모리를 포함하거나 또는 최소 콘텐츠 주소지정 메모리에 연결되는 하드웨어 가속장치를 이용하는 것이 가능한 고 데이터율을 이용하는 동안, 콘텐츠 주소지정 메모리를 사용하여 제어장치의 연산 자원의 실질적 소모없이, 동일 데이터값의 최소 일부는 동일 스트림의 연속 패킷을 위하여 사용된다.
각 성분은, 적어도 하나의 변수를 대표하는 헤더 정보와 연관된 콘텐츠를 패킷화하는 단계로서, 상기 적어도 하나의 변수에 의하여 패킷화된 콘텐츠가 상기 변수의 함수로서 하나 이상의 송신측과 하나 이상의 수신측 사이에서 선택적으로 취급되는 상기 콘텐츠를 패킷화하는 단계와; 상기 스트리밍 콘텐츠 내의 제어 정보를 포함하는 단계로서, 상기 제어 정보에 따라 상기 패킷화된 콘텐츠를 선택적으로 취급하는 방식이 변경될 수 있는 상기 제어 정보를 포함하는 단계와; 송신측과 수신측 사이에서 패킷화된 콘텐츠의 스트림의 설정 또는 재지정, 중지 또는 그 외 변경을 수행하고, 그 수행의 경우 상기 제어 정보로부터 최소한 부분적으로 상기 변수의 값을 결정하고, 상기 네트워크 가속 장치 내에 상기 스트림의 식별과 연관된 상기 값을 저장하는 단계를 포함하는 방법에 효과가 있도록 작동된다.
따라서, 제어 처리장치로부터의 진행 중인 실행의 최소화와 함께, 진행 중인 스트림의 패킷화된 콘텐츠는 네트워크 가속장치에 의하여 많은 부분이 선택적으로 취급된다.
본 발명은 예시적인 실시예와 연관되어 개시되었지만, 독점권이 주장되는 발명의 범위를 결정하기 위해서는 실시예를 논하기보다는 첨부된 청구항에 대한 언급이 이루어져야 한다.
Claims (16)
- 제어 값, 송신측 주소, 수신측 주소 및 페이로드 타입 중 적어도 하나를 나타내는 필드를 갖는 데이터 패킷을 전달하는 스트리밍 장치로서,서버로부터 데이터 패킷을 수신하기 위한 통신 경로로서, 상기 데이터 패킷의 필드로부터 부분적으로 결정되는 처리절차에 의하여 상기 통신 경로를 따라 상기 데이터 패킷의 적어도 콘텐츠 부분이 적어도 하나의 클라이언트로 전달되며, 상기 처리절차는 적어도 둘의 대안을 포함하고, 상기 적어도 둘의 대안에 의하여 상기 데이터 패킷은 적어도 둘의 구분되는 방법으로 상기 적어도 하나의 클라이언트로 전달될 수 있는 통신 경로와;상기 통신 경로와 연결되는 제어 처리장치로서, 적어도 부분적으로 상기 대안 각각에 적용되는 상기 처리절차 중 하나를 결정하도록 작동할 수 있는 상기 제어 처리 장치와;메모리를 갖는 네트워크 가속장치를 포함하며,상기 제어 처리장치는, 상기 데이터 패킷이 구분되는 방법으로 전달되는 상기 적어도 둘의 대안을 나타내는 데이터로 상기 네트워크 가속장치의 상기 메모리를 로드하도록 작동하며, 상기 네트워크 가속장치는, 이후 상기 처리절차에 따른 상기 구분되는 방법으로 상기 데이터 패킷을 상기 적어도 하나의 클라이언트에 전달되도록 상기 제어 처리장치와 실질적으로 독립적으로 작동하고,상기 데이터 패킷은 상기 필드를 포함하는 헤더를 가지고, 상기 네트워크 가속장치는, 상기 적어도 둘의 대안 중에서 선택하도록 상기 필드를 대체하는 것과 추가하는 것 중 적어도 어느 하나를 위한 상기 필드에 응답하여 작동하고,상기 패킷과 연관된 주소지정 정보를 변경하는 것을 포함하는 구분되는 방법으로 상기 데이터 패킷은 상기 적어도 하나의 클라이언트로 전달되는, 스트리밍 장치.
- 삭제
- 삭제
- 제 1항에 있어서,상기 데이터 패킷에는 규칙에 따라 상기 패킷이 전달되는 로컬 주소가 부가되는 스트리밍 장치.
- 제 1항에 있어서,상기 데이터 패킷은 RTP 스트리밍 프로토콜에 따라 구성된 콘텐츠 패킷과 주소지정 정보를 포함하고, 상기 콘텐츠 패킷은 상기 네트워크 가속장치에 의하여 보충(supplemental) 주소지정 정보 및 대체(substitute) 주소지정 정보 중 하나를 제공받는 스트리밍 장치.
- 제 5항에 있어서,상기 데이터 패킷은 RTSP 스트리밍 제어 프로토콜 및 RTCP 스트리밍 제어 프로토콜 중 하나에 따른 제어 정보를 더 포함하는 스트리밍 장치.
- 제 6항에 있어서,상기 RTSP 스트리밍 제어 프로토콜 및 RTCP 스트리밍 제어 프로토콜 중 하나에 따른 상기 제어정보를 포함하는 상기 데이터 패킷 내의 적어도 일부의 정보는, 상기 적어도 하나의 클라이언트로 상기 콘텐츠 패킷이 전달되도록 하는 상기 규칙을 정의하도록 상기 제어 처리장치의 프로그래밍에 의해 이용되는 스트리밍 장치.
- 제 7항에 있어서,상기 네트워크 가속장치는, 상기 제어 처리장치에 의하여 상기 규칙을 정의하는 정보로 로딩된 콘텐츠 주소지정 메모리 장치를 포함하고, 상기 네트워크 가속장치는, 상기 제어 처리장치의 상기 프로그래밍에 따라 저장된 데이터를 상기 메모리 장치로부터 판독함으로써 주어진 패킷에 적용 가능한 주어진 규칙에 접속하는 스트리밍 장치.
- 제 8항에 있어서,상기 데이터 패킷은 음성 데이터 및 영상 데이터 중 적어도 하나를 나타내고, 상기 규칙은 음성 또는 영상 저장 장치, 오락 장치, 음성 통신 시설 및 원격회의 시설 중 하나의 별도의 전환된 처리장치에 적용되는, 스트리밍 장치.
- 제 9항에 있어서,상기 네트워크 가속장치는, 상기 데이터 패킷이 수신측 장치 및 네트워크 저장 장치로 전달되도록 상기 규칙에 따라 작동할 수 있는 스트리밍 장치.
- 제 9항에 있어서,상기 네트워크 가속장치는, 상기 패킷이 판독 장치, 저장 장치, 상기 패킷을 변환하기 위한 매개 데이터 처리장치, 로컬 단말장치 및 원격 단말장치를 포함하는 수신측 장치로 전달되도록 하는 상기 규칙에 따라 작동할 수 있는 스트리밍 장치.
- 콘텐츠의 실시간 참조와 실질적으로 속도를 맞추어 콘텐츠를 스트리밍하는 방법으로서,적어도 하나의 변수를 나타내는 헤더 정보와 함께 상기 콘텐츠를 패킷화하는 단계로서, 패킷화된 상기 콘텐츠는 상기 변수의 함수로서 하나 이상의 송신측과 하나 이상의 수신측 사이에서 선택적으로 취급되는, 상기 콘텐츠를 패킷화하는 단계와;상기 스트리밍 콘텐츠에 제어 정보를 포함시키는 단계로서, 상기 패킷화된 콘텐츠를 선택적으로 취급하는 방식이 상기 제어 정보에 따라 변경가능한, 상기 제어 정보를 포함하는 단계와;제어 처리장치에 상기 제어 정보에 대한 접근을 제공하고, 네트워크 가속장치에 상기 패킷화된 콘텐츠에 대한 접근을 제공하는 단계와;상기 적어도 하나의 송신측과 상기 적어도 하나의 수신측 사이에서 상기 패킷화된 콘텐츠의 스트림에 대해 설정, 재전달, 중지 및 변경 중 어느 하나를 수행함과 함께, 상기 제어 정보의 일부로부터 상기 변수의 값을 결정하고, 상기 네트워크 가속장치 내에 상기 스트림의 식별과 연관된 상기 값을 저장하는 단계와;상기 스트림을 위한 패킷화된 콘텐츠를 수신하면, 상기 스트림의 식별과 연관되어 저장된 상기 값을 상기 네트워크 가속장치로부터 결정하고, 상기 네트워크 가속장치로부터 결정된 상기 값에 근거하여 상기 하나 이상의 송신측과 상기 하나 이상의 수신측 사이에서 수신된 상기 패킷화된 콘텐츠를 처리하는 단계에 있어서, 상기 제어 처리장치가 진행중인 스트림의 상기 패킷화된 콘텐츠를 최소의 진행 동작(action)으로 선택적으로 처리하는, 상기 값을 결정하고 상기 패킷화된 콘텐츠를 처리하는 단계를 포함하는 콘텐츠의 스트리밍 방법.
- 제 12항에 있어서,상기 네트워크 가속장치에 저장된 상기 값을 수정(revising)하는 단계를 더 포함하고, 상기 수정 단계는 상기 제어 처리장치의 동작에 의하여 실행되는, 콘텐츠의 스트리밍 방법.
- 제 13항에 있어서,상기 제어 처리장치는 상기 네트워크 가속장치 내에 저장된 상기 값을 실제로 수신된 제어 정보의 처리 결과로 수정하는, 콘텐츠의 스트리밍 방법.
- 제 12항에 있어서,상기 네트워크 가속장치 내에 엔트리를 갖는 다수의 식별된 스트림을 제공하는 단계를 더 포함하고, 상기 네트워크 가속장치는, 대응되는 식별된 스트림과 관련되어 상기 네트워크 가속장치 내에 저장된 다수의 값 중 하나에 의해 상기 패킷화된 콘텐츠의 세그먼트들을 선택적으로 증가시키는, 콘텐츠의 스트리밍 방법.
- 제 15항에 있어서,상기 식별된 스트림을 위한 상기 엔트리가 접근 가능한 메시지 큐(message queue)를 포함하는 콘텐츠 주소지정 메모리를 제공하는 단계와, 엔트리를 상기 식별된 스트림 중 대응되는 하나의 식별자와 매칭(matching)시킴으로써 상기 다수의 값 중 상기 하나를 결정하는 단계를 더 포함하는, 콘텐츠의 스트리밍 방법.
Applications Claiming Priority (12)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US72446305P | 2005-10-07 | 2005-10-07 | |
| US72472205P | 2005-10-07 | 2005-10-07 | |
| US72457305P | 2005-10-07 | 2005-10-07 | |
| US72446405P | 2005-10-07 | 2005-10-07 | |
| US72506005P | 2005-10-07 | 2005-10-07 | |
| US72446205P | 2005-10-07 | 2005-10-07 | |
| US60/724,573 | 2005-10-07 | ||
| US60/724,462 | 2005-10-07 | ||
| US60/724,464 | 2005-10-07 | ||
| US60/725,060 | 2005-10-07 | ||
| US60/724,722 | 2005-10-07 | ||
| US60/724,463 | 2005-10-07 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| KR20080068691A KR20080068691A (ko) | 2008-07-23 |
| KR100926007B1 true KR100926007B1 (ko) | 2009-11-11 |
Family
ID=37719120
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| KR1020087010945A KR20080068690A (ko) | 2005-10-07 | 2006-10-06 | 상보적 지정 파일을 이용하여 실시간전송프로토콜 출구스트리밍을 위한 방법 및 장치 |
| KR1020087010946A KR100926007B1 (ko) | 2005-10-07 | 2006-10-06 | 스트리밍 및 제어 처리를 위한 별도의 구성을 이용한미디어 데이터 프로세싱 |
Family Applications Before (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| KR1020087010945A KR20080068690A (ko) | 2005-10-07 | 2006-10-06 | 상보적 지정 파일을 이용하여 실시간전송프로토콜 출구스트리밍을 위한 방법 및 장치 |
Country Status (6)
| Country | Link |
|---|---|
| US (2) | US20090147787A1 (ko) |
| JP (2) | JP2009512280A (ko) |
| KR (2) | KR20080068690A (ko) |
| DE (2) | DE112006002677T5 (ko) |
| GB (2) | GB2448799A (ko) |
| WO (2) | WO2007044563A1 (ko) |
Families Citing this family (55)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101026616B (zh) * | 2006-02-18 | 2013-01-09 | 华为技术有限公司 | 基于ip多媒体子系统的交互式媒体会话建立方法 |
| US8539065B2 (en) * | 2006-07-26 | 2013-09-17 | Cisco Technology, Inc. | Method and apparatus for providing access to real time control protocol information for improved media quality control |
| US8014322B2 (en) * | 2007-02-26 | 2011-09-06 | Cisco, Technology, Inc. | Diagnostic tool for troubleshooting multimedia streaming applications |
| US20090135735A1 (en) * | 2007-11-27 | 2009-05-28 | Tellabs Operations, Inc. | Method and apparatus of RTP control protocol (RTCP) processing in real-time transport protocol (RTP) intermediate systems |
| US20090135724A1 (en) * | 2007-11-27 | 2009-05-28 | Tellabs Operations, Inc. | Method and apparatus of RTP control protocol (RTCP) processing in real-time transport protocol (RTP) intermediate systems |
| US8949470B2 (en) * | 2007-12-31 | 2015-02-03 | Genesys Telecommunications Laboratories, Inc. | Federated access |
| US8904031B2 (en) | 2007-12-31 | 2014-12-02 | Genesys Telecommunications Laboratories, Inc. | Federated uptake throttling |
| US9003051B2 (en) * | 2008-04-11 | 2015-04-07 | Mobitv, Inc. | Content server media stream management |
| US8015310B2 (en) | 2008-08-08 | 2011-09-06 | Cisco Technology, Inc. | Systems and methods of adaptive playout of delayed media streams |
| US7886073B2 (en) * | 2008-08-08 | 2011-02-08 | Cisco Technology, Inc. | Systems and methods of reducing media stream delay |
| US7969974B2 (en) * | 2008-10-15 | 2011-06-28 | Cisco Technology, Inc. | System and method for providing a multipath switchover between redundant streams |
| US8239739B2 (en) | 2009-02-03 | 2012-08-07 | Cisco Technology, Inc. | Systems and methods of deferred error recovery |
| US8711771B2 (en) * | 2009-03-03 | 2014-04-29 | Qualcomm Incorporated | Scalable header extension |
| JP5675807B2 (ja) * | 2009-08-12 | 2015-02-25 | コニンクリーケ・ケイピーエヌ・ナムローゼ・フェンノートシャップ | 動的なｒｔｃｐリレー |
| US20110110382A1 (en) * | 2009-11-10 | 2011-05-12 | Cisco Technology, Inc., A Corporation Of California | Distribution of Packets Among PortChannel Groups of PortChannel Links |
| FR2961651B1 (fr) * | 2010-06-22 | 2012-07-20 | Alcatel Lucent | Procede et dispositif de traitement de flux media entre une pluralite de terminaux media et une unite de traitement a travers un reseau de communication |
| US8706889B2 (en) * | 2010-09-10 | 2014-04-22 | International Business Machines Corporation | Mitigating connection identifier collisions in a communication network |
| CN102624752B (zh) * | 2011-01-26 | 2014-06-18 | 天脉聚源(北京)传媒科技有限公司 | 一种m3u8直播流防盗链方法和系统 |
| US9769231B1 (en) * | 2011-04-01 | 2017-09-19 | Arris Enterprises Llc | QoS for adaptable HTTP video |
| DE102011103740A1 (de) | 2011-05-31 | 2012-12-06 | Smartrac Ip B.V. | Verfahren und Anordnung zum Bereitstellen und Verwalten von mit RFID-Datenträgern verknüpften Informationen in einem Netzwerk |
| CN102968422B (zh) * | 2011-08-31 | 2015-06-17 | 中国航天科工集团第二研究院七0六所 | 流数据存储控制系统及其方法 |
| US9176912B2 (en) * | 2011-09-07 | 2015-11-03 | Altera Corporation | Processor to message-based network interface using speculative techniques |
| WO2013100986A1 (en) * | 2011-12-28 | 2013-07-04 | Intel Corporation | Systems and methods for integrated metadata insertion in a video encoding system |
| US20140112636A1 (en) * | 2012-10-19 | 2014-04-24 | Arcsoft Hangzhou Co., Ltd. | Video Playback System and Related Method of Sharing Video from a Source Device on a Wireless Display |
| US9148379B1 (en) * | 2013-01-09 | 2015-09-29 | “Intermind” société à responsabilité limitée | Method and system for prioritizing audio traffic in IP networks |
| US10162007B2 (en) * | 2013-02-21 | 2018-12-25 | Advantest Corporation | Test architecture having multiple FPGA based hardware accelerator blocks for testing multiple DUTs independently |
| US10161993B2 (en) | 2013-02-21 | 2018-12-25 | Advantest Corporation | Tester with acceleration on memory and acceleration for automatic pattern generation within a FPGA block |
| US11009550B2 (en) | 2013-02-21 | 2021-05-18 | Advantest Corporation | Test architecture with an FPGA based test board to simulate a DUT or end-point |
| US9952276B2 (en) | 2013-02-21 | 2018-04-24 | Advantest Corporation | Tester with mixed protocol engine in a FPGA block |
| CN103354522B (zh) * | 2013-06-28 | 2016-08-10 | 华为技术有限公司 | 一种多级流表查找方法和装置 |
| US9275168B2 (en) | 2013-07-19 | 2016-03-01 | International Business Machines Corporation | Hardware projection of fixed and variable length columns of database tables |
| US9235564B2 (en) | 2013-07-19 | 2016-01-12 | International Business Machines Corporation | Offloading projection of fixed and variable length database columns |
| JP6268066B2 (ja) * | 2013-09-20 | 2018-01-24 | パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ | 送信方法、受信方法、送信装置及び受信装置 |
| EP3075132B1 (en) | 2013-11-27 | 2021-08-18 | Telefonaktiebolaget LM Ericsson (publ) | Hybrid rtp payload format |
| WO2016144366A1 (en) * | 2014-03-12 | 2016-09-15 | Infinesse Corporation | Real-time transport protocol (rtp) media conference server routing engine |
| US10015048B2 (en) | 2014-12-27 | 2018-07-03 | Intel Corporation | Programmable protocol parser for NIC classification and queue assignments |
| US9912774B2 (en) * | 2015-12-22 | 2018-03-06 | Intel Corporation | Accelerated network packet processing |
| US10735438B2 (en) * | 2016-01-06 | 2020-08-04 | New York University | System, method and computer-accessible medium for network intrusion detection |
| US10970133B2 (en) | 2016-04-20 | 2021-04-06 | International Business Machines Corporation | System and method for hardware acceleration for operator parallelization with streams |
| US10067809B2 (en) | 2016-04-20 | 2018-09-04 | International Business Machines Corporation | System and method for batch transport using hardware accelerators |
| KR102610480B1 (ko) * | 2016-09-26 | 2023-12-06 | 삼성전자 주식회사 | 스트리밍 서비스를 제공하는 방법 및 장치 |
| US11245572B1 (en) | 2017-01-31 | 2022-02-08 | Barefoot Networks, Inc. | Messaging between remote controller and forwarding element |
| CN106940673A (zh) * | 2017-03-15 | 2017-07-11 | 郑州云海信息技术有限公司 | 一种监测项间隔智能调整方法及系统 |
| US10694006B1 (en) | 2017-04-23 | 2020-06-23 | Barefoot Networks, Inc. | Generation of descriptive data for packet fields |
| US10826840B1 (en) | 2017-07-23 | 2020-11-03 | Barefoot Networks, Inc. | Multiple copies of stateful tables |
| US10771387B1 (en) | 2017-09-28 | 2020-09-08 | Barefoot Networks, Inc. | Multiple packet data container types for a processing pipeline |
| WO2020242443A1 (en) * | 2018-05-24 | 2020-12-03 | SmartHome Ventures, LLC | Protocol conversion of a video stream |
| US10976361B2 (en) | 2018-12-20 | 2021-04-13 | Advantest Corporation | Automated test equipment (ATE) support framework for solid state device (SSD) odd sector sizes and protection modes |
| CN111510394B (zh) * | 2019-01-31 | 2022-04-12 | 华为技术有限公司 | 一种报文调度方法、相关设备及计算机存储介质 |
| US11137910B2 (en) | 2019-03-04 | 2021-10-05 | Advantest Corporation | Fast address to sector number/offset translation to support odd sector size testing |
| US11237202B2 (en) | 2019-03-12 | 2022-02-01 | Advantest Corporation | Non-standard sector size system support for SSD testing |
| US10884847B1 (en) | 2019-08-20 | 2021-01-05 | Advantest Corporation | Fast parallel CRC determination to support SSD testing |
| US11706163B2 (en) * | 2019-12-20 | 2023-07-18 | The Board Of Trustees Of The University Of Illinois | Accelerating distributed reinforcement learning with in-switch computing |
| US20220303150A1 (en) * | 2021-03-16 | 2022-09-22 | Zoom Video Communications, Inc | Systems and methods for video conference acceleration |
| US11601355B2 (en) * | 2021-03-16 | 2023-03-07 | Dell Products L.P. | Contextual bandwidth management of audio/video conference |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6173333B1 (en) * | 1997-07-18 | 2001-01-09 | Interprophet Corporation | TCP/IP network accelerator system and method which identifies classes of packet traffic for predictable protocols |
| WO2002043320A2 (en) * | 2000-11-07 | 2002-05-30 | Surgient Networks, Inc. | Network transport accelerator |
| US20020176418A1 (en) | 2001-04-19 | 2002-11-28 | Russell Hunt | Systems and methods for producing files for streaming from a content file |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6543053B1 (en) * | 1996-11-27 | 2003-04-01 | University Of Hong Kong | Interactive video-on-demand system |
| US6977930B1 (en) * | 2000-02-14 | 2005-12-20 | Cisco Technology, Inc. | Pipelined packet switching and queuing architecture |
| US7032031B2 (en) * | 2000-06-23 | 2006-04-18 | Cloudshield Technologies, Inc. | Edge adapter apparatus and method |
| US20040128342A1 (en) * | 2002-12-31 | 2004-07-01 | International Business Machines Corporation | System and method for providing multi-modal interactive streaming media applications |
| US7701884B2 (en) * | 2004-04-19 | 2010-04-20 | Insors Integrated Communications | Network communications bandwidth control |
-
2006
- 2006-10-06 JP JP2008534732A patent/JP2009512280A/ja not_active Withdrawn
- 2006-10-06 DE DE112006002677T patent/DE112006002677T5/de not_active Withdrawn
- 2006-10-06 KR KR1020087010945A patent/KR20080068690A/ko not_active Application Discontinuation
- 2006-10-06 US US12/089,485 patent/US20090147787A1/en not_active Abandoned
- 2006-10-06 GB GB0805654A patent/GB2448799A/en not_active Withdrawn
- 2006-10-06 DE DE112006002644T patent/DE112006002644T5/de not_active Withdrawn
- 2006-10-06 GB GB0805653A patent/GB2444675A/en not_active Withdrawn
- 2006-10-06 WO PCT/US2006/039224 patent/WO2007044563A1/en active Search and Examination
- 2006-10-06 WO PCT/US2006/039223 patent/WO2007044562A1/en active Search and Examination
- 2006-10-06 KR KR1020087010946A patent/KR100926007B1/ko not_active IP Right Cessation
- 2006-10-06 US US12/089,509 patent/US20080285571A1/en not_active Abandoned
- 2006-10-06 JP JP2008534731A patent/JP2009512279A/ja active Pending
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6173333B1 (en) * | 1997-07-18 | 2001-01-09 | Interprophet Corporation | TCP/IP network accelerator system and method which identifies classes of packet traffic for predictable protocols |
| WO2002043320A2 (en) * | 2000-11-07 | 2002-05-30 | Surgient Networks, Inc. | Network transport accelerator |
| US20020176418A1 (en) | 2001-04-19 | 2002-11-28 | Russell Hunt | Systems and methods for producing files for streaming from a content file |
Also Published As
| Publication number | Publication date |
|---|---|
| GB2444675A (en) | 2008-06-11 |
| JP2009512280A (ja) | 2009-03-19 |
| DE112006002677T5 (de) | 2008-11-13 |
| JP2009512279A (ja) | 2009-03-19 |
| GB2448799A (en) | 2008-10-29 |
| US20080285571A1 (en) | 2008-11-20 |
| KR20080068691A (ko) | 2008-07-23 |
| WO2007044563A1 (en) | 2007-04-19 |
| DE112006002644T5 (de) | 2008-09-18 |
| GB0805653D0 (en) | 2008-04-30 |
| WO2007044562A1 (en) | 2007-04-19 |
| GB0805654D0 (en) | 2008-04-30 |
| KR20080068690A (ko) | 2008-07-23 |
| US20090147787A1 (en) | 2009-06-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR100926007B1 (ko) | 스트리밍 및 제어 처리를 위한 별도의 구성을 이용한미디어 데이터 프로세싱 | |
| US11381625B2 (en) | Apparatus and method for transmitting multimedia data in hybrid network | |
| JP4965059B2 (ja) | ビデオストリームの切り替え | |
| US7675939B2 (en) | Transmission apparatus and method, reception apparatus and method, communication system, recording medium, and program | |
| CN101352012A (zh) | 使用不同元件对流进行媒体数据处理以及控制方法 | |
| US8094667B2 (en) | RTP video tunneling through H.221 | |
| US11284135B2 (en) | Communication apparatus, communication data generation method, and communication data processing method | |
| US20050018615A1 (en) | Media transmitting method, media receiving method, media transmitter and media receiver | |
| WO2012094916A1 (zh) | 一种流媒体数据包的封装、传输方法及流媒体处理装置 | |
| EP1125413B1 (en) | Data transport | |
| EP1340381A2 (en) | Apparatus and method for improving the quality of video communication over a packet-based network | |
| EP3096524B1 (en) | Communication apparatus, communication data generation method, and communication data processing method | |
| US8416786B2 (en) | Data transport container for transferring data in a high speed internet protocol network | |
| US10298975B2 (en) | Communication apparatus, communication data generation method, and communication data processing method | |
| EP2188973B1 (en) | Method, server and client apparatuses for transferring high resolution multimedia data in a high speed network | |
| KR101955690B1 (ko) | 복합 네트워크에서 멀티미디어 데이터를 전송하기 위한 장치 및 그 방법 | |
| KR101855327B1 (ko) | 복합 네트워크에서 멀티미디어 데이터를 전송하기 위한 장치 및 그 방법 | |
| KR20190021300A (ko) | 복합 네트워크에서 멀티미디어 데이터를 전송하기 위한 장치 및 그 방법 | |
| Teixeira et al. | A Free Software Streaming Video Application based on MMTP | |
| Aliyev | Multipath RTP for video | |
| JP2008271176A (ja) | ストリーム受信装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A201 | Request for examination | ||
| E902 | Notification of reason for refusal | ||
| E701 | Decision to grant or registration of patent right | ||
| GRNT | Written decision to grant | ||
| LAPS | Lapse due to unpaid annual fee |