KR20160141871A

KR20160141871A - 네트워크에서 신뢰성 있는 실시간 데이터 스트리밍을 위한 효율적인 애플리케이션 계층의 자동 반복 요청 재송신 방법

Info

Publication number: KR20160141871A
Application number: KR1020167033419A
Authority: KR
Inventors: 람쿠마르 페루마남; 이샨 우데이 만드레카르; 밍쿠안 우; 항 리우; 사우라브흐 마뚜르
Original assignee: 톰슨 라이센싱
Priority date: 2009-10-07
Filing date: 2009-10-07
Publication date: 2016-12-09
Also published as: CN102687448B; WO2011043756A1; EP2486686A1; US20120170445A1; JP2013507826A; CN102687448A; KR20120082416A

Abstract

방법 및 장치가 서술되는데, 이 방법 및 장치는 송신될 데이터를 버퍼링하는 것, 데이터그램 프로토콜을 통해 버퍼로부터 검색된 데이터를 송신하는 것, 데이터의 재송신을 위한 요청을 수신하는 것, 요청된 데이터가 버퍼 내에 있는지를 결정하는 것, 및 데이터 및 오류 복구의 엔드 투 엔드(end-to-end) 확인 응답을 제공하는 프로토콜을 통해 요청된 데이터를 재송신하는 것을 포함한다.

Description

네트워크에서 신뢰성 있는 실시간 데이터 스트리밍을 위한 효율적인 애플리케이션 계층의 자동 반복 요청 재송신 방법{AN EFFICIENT APPLICATION-LAYER AUTOMATIC REPEAT REQUEST RETRANSMISSION METHOD FOR RELIABLE REAL-TIME DATA STREAMING IN NETWORKS}

본 발명은 일반적으로 네트워크에 관한 것이고, 특히, 실시간 데이터 스트리밍의 자동 반복 요청(ARQ) 재송신을 위한 애플리케이션 계층의 방법에 관한 것이다.

멀티캐스트 또는 브로드캐스트 애플리케이션에서, 데이터는 유선 및/또는 무선 네트워크를 통해 서버로부터 다수의 수신기로 송신된다. 본 명세서에서 사용되는 멀티캐스트 시스템은 서버가 동시에 동일한 데이터를 다수의 수신기에 송신하는 시스템인데, 여기서 수신기는 모든 수신기까지, 및 이를 포함하는, 전체 수신기의 서브셋을 형성한다. 브로드캐스트 시스템은 서버가 동시에, 동일한 테이터를 수신기 모두에 송신하는 시스템이다. 즉, 한정을 통해, 멀티캐스트 시스템은 브로드캐스트 시스템을 포함할 수 있다.

데이터는 주로 송신을 위해 패킷 및/또는 프레임으로 포맷된다. 즉, 패킷 및 프레임은 데이터 포맷 방식이다. 명세서에서 사용되는 데이터는 패킷 및/또는 프레임을 포함하는 송신을 위한 임의의 편리한 포맷으로 포맷될 수 있다.

무선 네트워크에서 비디오 송신 또는 배포는 주로, 간섭, 채널 페이딩(fading), 충돌 등과 같은 채널 오류 상태에 의해 야기된 패킷 분실을 수반한다. 이러한 채널 오류 상태가 발생할 때, 프로토콜 스택의 무선 링크 계층은 고정된 시간 기간 내의 고정된 시간 동안 패킷의 재송신을 시도한다. 이들 재송신이 성공적이지 못한다면, 패킷은 무선 링크 계층에 의해 버려진다. 인터넷 프로토콜(IP) 네트워크 기반의 비디오 송신은 전형적으로, 실시간 송신 프로토콜(RTP)을 사용하여 목적지(수신기)에 비디오 패킷을 전달하는데, 이 프로토콜은 차례로, 신뢰성 있는 송신 제어 프로토콜(TCP) 송신 프로토콜 또는 신뢰성이 적은 사용자 데이터그램 프로토콜(UDP) 송신 프로토콜을 사용한다. 신뢰성이 적은 UDP 프로토콜이 사용될 때, 프로토콜은 순서 패킷을 검출하거나, 또는 분실된 패킷을 복구하기 위한 수단을 제공하지 않고, 패킷 전달 오류를 복구하기 위한 애플리케이션에 책임을 지운다. 반대로, TCP 프로토콜이 사용될 때, 엔드 투 엔드(end to end) 확인 응답(acknowledgment)은, 프로토콜이 패킷이 애플리케이션에 의해 다루어지는 순서로, 엄격히 미디어(오디오, 비디오, 멀티미디어) 패킷(데이터)의 전송 및/또는 복구를 시도하도록 제공된다. 패킷 오류가 검출될 때, TCP의 슬라이딩 윈도우 매카니즘은 흐름 제어를 활성화시키고, 패킷 송신율을 감소시킨다. TCP는 분실된 패킷이 복구될 때까지, 분실된 패킷을 재송신한다. 비디오 송신이 실시간으로 발생해야하고, 데이터의 수신 및 렌더링과 관련된 사용자의 시청 경험을 갖기에, 최종 사용자의 시청 경험에 악영향을 미치지 않도록, 패킷이 전달되고 복구되어야 하는 레이턴시 또는 시간 제약이 존재한다. 그러므로, 패킷 오류는 제한된 시간 안에 복구되어야 하고, 그렇지 않다면 데이터는 최종 사용자에게 쓸모가 없다는 것이 명백하다. TCP에 대해, 애플리케이션이 시간 제약을 기초로 패킷 복구를 제어하기 위한 어떠한 방식도 존재하지 않는다. 무선 네트워크에 대한 송신 프로토콜로 TCP를 사용하는 것은 열악한 사용자 시청 경험을 초래할 수 있다. 게다가, TCP는 송신된 데이터 패킷 모두에 대해 긍정 확인 응답을 요구한다. TCP 업링크 확인 응답{데이터 수신기로부터 데이터 송신기(전송기)}은 무선 대역폭에 대해 다운링크 데이터 트래픽{송신기(전송기)로부터 수신기로}과 경쟁할 것이다. 다운링크 및 업링크 송신 사이에 충돌이 발생하면, 충돌은 추가의 처리량 감소를 초래할 수 있다.

하나의 종래 기술의 방식에서, 블록 기반의 애플리케이션 계층의 순방향 오류 교정(FEC, Forward Error Correction)이 제안되었다. 애플리케이션 계층의 FEC 메카니즘은 RTP 또는 UDP 패킷과 같은 패킷 레벨에 영향을 미친다. 이는 물리 계층의 FEC와 다르고, 다수의 데이터 패킷을 가로질러 FEC 코드를 인가하여, 서버(송신기, 전송기) 측 상에 여분의 패리티 패킷을 생성한다. 송신기는 데이터 패킷과 FEC 패킷 모두를 타겟 수신기에 전송한다. 수신기 측에서, FEC 디코더는 수신된 데이터 패킷과 FEC 패킷을 사용함으로써, 분실 패킷의 재구성을 시도한다. 이러한 방식이 효율적이기 위해서, 방식이 시간에 따라 변하는 채널 상태에 적응되는 것이 필수적이다. 하지만, 도전 목표는 어떻게 채널 상태를 미리 예측하고, 어떻게 FEC 코드를 가변 채널 상태에 효율적으로, 그리고 신뢰성 있게 적응시키는 지이다. 낮은 추정이 발생하면, 분실된 패킷은 복구될 수 없다. 하지만. 과도한 추정이 발생하면, 대역폭이 낭비된다. 그러므로, 이 방법은 신뢰성 또는 대역폭을 절충시키지 않고 미세 조정하는데 어렵다.

다른 종래의 방식에서, 패킷 분실 복구를 위해 자동 반복 요청(ARQ)의 변형이 제안되었다. 자동 반복 요청은 데이터 송신을 위한 오류 제어 방법이다. 하나의 접근법에서, 타임아웃을 갖는 긍정 확인 응답은 신뢰성 있는 데이터 송신을 달성하기 위해 ARQ 방식에서 사용된다. 수신기가 데이터 프레임 또는 패킷을 올바르게 수신할 것을 나타내기 위해, 긍정 확인 응답(ACK)은 수신기에 의해 송신기로 전송된다. 송신기는 또한, 송신기가 데이터 프레임 또는 패킷을 전송한 후의, 적당한 시점인 타임아웃 타이머를 유지한다. 송신기가 타임아웃 전에 확인 응답을 수신하지 않았다면, 송신기는 보통, 송신기가 확인 응답을 수신하거나, 사전 결정된 재송신 횟수를 초과할 때까지, 데이터 프레임 또는 패킷을 재송신한다. 이러한 접근법에서, 수신기 및 송신기로부터 확인 응답 데이터 패킷 또는 프레임 트래픽의 양은, 패킷 분실률이 낮을 때(대다수의 데이터 패킷/프레임이 올바르게 수신되고 확인 응답될 필요가 있을 때), 높다. 확인 응답 데이터 패킷 또는 프레임은 무선 대역폭에 대해, 데이터 패킷 또는 프레임과 경쟁한다. 게다가, 충돌은 데이터 패킷과 확인 응답 패킷의 송신 간에 발생할 수 있다.

또 다른 종래 기술의 접근법에서, 수신기가 데이터 프레임 또는 패킷을 올바르게 수신하지 못했음을 나타내기 위해, 수신기에 의해 송신기로 부정 확인 응답(NACK)이 전송된다. 일단 송신기가 NACK을 수신하면, 송신기는 수신기에 분실된 데이터 패킷 또는 프레임을 재송신한다. 수신기 및 송신기로부터의 NACK 트래픽의 양은 패킷 분실률이 낮을 때 낮고, 이는 대역폭을 포함하는 네트워크 자원의 더 효율적인 활용을 초래한다. 하지만, NACK 데이터 패킷 또는 프레임 자체가 분실될 수 있다. 분실이 발생한다면, 송신기는 분실된 데이터 패킷 또는 프레임을 재송신하지 않아서, 낮은 신뢰도를 야기할 것이다.

원래의 송신기(전송기)로부터 분실된 패킷만을 요청하고, 애플리케이션에 대해 수용할 수 있는 시간 제약 내에 패킷의 복구를 시도함으로써, UDP 기반의 비디오 송신에 대한 신뢰도를 제공하는 효율적인 방법을 갖는 것이 이로운데, 따라서, 이 방법은 신뢰성 및 시스템 처리량을 개선시키고, 실시간 애플리케이션의 전체 사용자 시청 경험을 개선 시킨다.

본 발명은 네트워크에서 실시간 비디오 스트리밍의 신뢰도를 증가시키기 위한 송신 또는 애플리케이션 계층에서의 방법에 관한 것이다. 비디오 스트리밍은 본 명세서에서 실시간 데이터 스트리밍의 특정 예시로서 사용된다. 실시간 데이터 스트리밍은 오디오, 비디오, 멀티미디어 또는 이들의 조합을 포함하는 임의의 타입의 데이터를 포함할 수 있다. 본 발명의 방법은 무선 네트워크 또는 무선 근거리 통신망에 특정되지 않는다. 본 발명은 유선 라인 또는 무선 네트워크에 대해 전개될 수 있다. 무선 네트워크는 예시적인 전개로 사용된다. 본 발명의 방법은 네트워크에서, 다양한 채널 오류에 의해 야기된 패킷 분실로 특징 지워지는 분실된 패킷을 복구하는데 효율적인 수단을 제공하고, 따라서 비디오 송신의 신뢰성 및 품질을 개선시킨다. 본 발명의 방법은 원래의 송신기(전송기)로부터 분실된 패킷만을 요청하고, 애플리케이션에 대해 수용할 수 있는 시간 제약 내에서 패킷의 복구를 시도함으로써, UDP 기반의 비디오 송신에 대한 신뢰성을 제공하는데 효율적인 방법을 제공하고, 따라서, 신뢰성 및 시스템 처리량을 개선시키고, 실시간 애플리케이션의 전체 사용자 시청 경험을 개선시킨다.

본 발명은 타임아웃 및 부정 확인 응답과, 긍정 ACK의 장점을 결합하는 방법을 제공한다. 초기 송신에 대해 NACK이 사용된다. 하지만, NACK 패킷 또는 프레임 및 재송신된 데이터 패킷 또는 프레임은 별도의 TCP 채널 상에서 타임아웃을 갖는 ACK를 사용하여 전송된다. 본 발명은 신뢰성 있는 오류 복구 경로를 제공하기 위해, 그리고, 또한 복구 시간 윈도우에 대한 상한치를 강제함으로써, 애플리케이션의 실시간 제약을 고려하기 위해 TCP를 사용한다.

방법 및 장치가 서술되는데, 이 방법 및 장치는, 송신될 데이터를 버퍼링하는 것, 데이터그램 프로토콜을 통해 버퍼로부터 검색된 데이터를 송신하는 것, 데이터의 재송신을 위한 요청을 수신하는 것, 요청된 데이터가 버퍼 내에 있는지를 결정하는 것, 및 데이터 및 오류 복구의 엔드 투 엔드 확인 응답을 제공하는 프로토콜을 통해 요청된 데이터를 재송신하는 것을 포함한다.

첨부 도면과 함께 읽혀질 때, 본 발명은 다음의 상세한 설명으로부터 최선으로 이해된다. 도면은 아래에 간략히 서술된 다음 도면을 포함한다.

본 발명은 애플리케이션 계층의 자동 반복 요청 재송신 방법을 제공하여, 네트워크에서 효율적이고, 신뢰성 있는 실시간 데이터 스트리밍을 제공한다.

도 1a는 클라이언트 디바이스로의 초기 송신에서, 서버에 의해 실시되는 본 발명의 방법의 흐름도.
도 1b는 훼손된(corrupted) 데이터의 재송신에서, 서버에 의해 실시되는 본 발명의 방법의 흐름도.
도 2a는 데이터의 초기 수신에서 클라이언트에 의해 실시되는 본 발명의 방법의 흐름도.
도 2b는 재송신된 데이터를 수신하는데 있어서, 클라이언트에 의해 실시되는 본 발명의 방법의 흐름도.
도 2c는 데이터를 렌더링하는데 있어서, 클라이언트에 의해 실시되는 본 발명의 방법의 흐름도.
도 3은 프로토콜 스택을 도시하는 도면.
도 4a는 재송신을 요청하고, 재송신 요청에 응답하는데 사용되는 예시적인 메세지의 공통 헤더를 도시하는 도면.
도 4b는 재송신된 데이터 패킷의 예시적인 포맷을 도시하는 도면.
도 4c는 재송신 부정 확인 응답(NACK)의 예시적인 포맷을 도시하는 도면.
도 4d는 재송신 부정 확인 응답(NACK)의 대안적인 예시 포맷을 도시하는 도면.
도 5는 본 발명의 원리에 따른 서버의 예시적인 실시예의 개략도.
도 6은 본 발명의 원리에 따른 클라이언트 디바이스의 예시적인 실시예의 개략도.

무선 네트워크에서 비디오 송신 또는 배포는 전형적으로 UDP를 통해, RTP, 움직임 화상 전문가 그룹 2 송신 스트림(MPEG2TS)을 사용하고, 단일 소스로부터 단일 목적지로(유니캐스트 모드), 또는 단일 소스로부터 다중 목적지로(멀티캐스트 모드) 배포될 수 있다. 채널 상태가 무선 네트워크에서 변하기에, 채널 상태가 양호하지 않을 때, 패킷 송신은, 링크 계층의 오류 복구가 성공적이지 않다면, 버려진 패킷을 초래한다. 이들 상황에서, 패킷 시퀀스에 갭이 존재하여, 최종 사용자에 대해 불충분한 시청 품질을 초래한다. 본 발명은, 패킷 분실을 복구하여, 신뢰성 있는 실시간 스트리밍 애플리케이션에 도움을 주는, 효율적인 애플리케이션 계층 기반의 재송신 방식을 제공하는데, 이는 본 명세서에서 신뢰성 있는 미디어 프로토콜(RMP)이라 불린다.

본 발명의 신뢰성 있는 미디어 프로토콜(RMP)에서, 정규 유니캐스트 및 멀티캐스트 데이터 또는 패킷 재송신은 UDP를 이용한다. 이와 별개로, 추가적인 신뢰성 있는 TCP 기반의 제어 채널은 분실된 패킷의 재송신을 요청하고 수신하기 위해, 소스(송신기, 전송기)와 목적지(수신기, 싱크) 사이에 구축된다. 이러한 메카니즘이 적합하게 잘 동작하도록, 송신기(전송기)는 수신기에 전송된 가장 최근의 패킷의 캐시를 유지한다. 하나 이상의 수신기는 송신기로부터 데이터 패킷을 수신하고, RTP 또는 MPEG 송신 스트림(TS) 헤더 내에 존재하는 시퀀스 번호 필드를 사용하여, 수신된 데이터 패킷에서 시퀀스 갭을 검출한다. 수신기가 시퀀스 갭을 검출한다면, 수신기는 분실 데이터 패킷의 선택적 재송신을 위해 TCP 기반의 제어 채널에 대한 요청을 전송한다. 송신기가 하나 이상의 수신기로부터 재송신 요청을 수신한다면, 송신기는 가장 최근의 패킷의 로컬 캐시를 조사한다. 요청된 패킷(들)이 로컬 캐시 내에서 발견된다면, 전송기는 유니캐스트로, TCP 기반의 제어 채널 상의 수신기에 패킷의 사본을 재송신한다. 요청된 패킷이 로컬 캐시 내에서 발견되지 않았다면, 전송기는 나머지 재송신 요청에 대한 서비스를 지속한다. 수신기는 데이터 및 제어 채널 모두로부터 수신된 데이터 패킷의 모두를 갖기 위해, 전달 큐(버퍼)를 유지하고, 이 큐 내의 올바른 시퀀스(위치)로 재송신된 패킷을 재정렬하고, 제때에 적합한 순서로, 패킷을 애플리케이션에 전달한다. 패킷 지연 및 지연 지터가 애플리케이션 경계 내로 유지될 수 있도록, 수신기는 영구적으로 기다리는 것이 아닌, 임의의 재송신 동안 기다리도록 구성가능한 시간 윈도우를 유지한다. 이는, 분실된 패킷에 대한 재송신 응답 중 일부가 제때에 수신되지 않은 경우, 수신기는, 수신된 패킷의 나머지를 전달 큐로부터 애플리케이션으로 전달한다는 것을 의미한다. 재송신된 패킷 중 일부가 수용가능한 복구 시간 윈도우를 넘어서 수신된다면, 이들 패킷은 수신기에 의해 폐기된다. 비디오 애플리케이션이 비디오 디코딩에서 오류 은폐 기법을 사용하여 일부 데이터 패킷 분실을 허용한다는 것이 주목된다.

본 발명의 원리에 따라 전송 측 및 수신 측에 대한 흐름도는 도 1a, 도 1b, 및 2a, 2b 도 2c에 도시된다. 도 3은 본 발명에 따른 프로토콜 스택을 도시한다. 본 발명에서 신뢰성 있는 미디어 프로토콜(RMP) 방식은 실시간 애플리케이션/RTP/MPEG TS와, UDP/TCP/IP 사이에서 동작한다.

도 1a를 다시 참조하면, 단계(105)에서, 송신기(서버, 전송기)는 로컬 파일(미도시)로부터, 또는 예를 들어, 컨텐츠 서버 또는 컨텐츠 배포 시스템(미도시)과 연결된 다른 네트워크 인터페이스 모듈(미도시)로부터 송신될 데이터를 수신한다. 단계(110)에서, 송신기는 버퍼(로컬 캐시, 메모리)에서 송신될 데이터의 사본을 버퍼링하고, 단계(115)에서, 송신될 데이터를 네트워크 인터페이스 모듈을 통한 송신을 위하여 UDP/IP 모듈에 전달한다.

도 1b를 다시 참조하면, 단계(120)에서, 서버(원래 데이터의 송신기)는, 수신기가, 패킷이 분실(분실, 소실, 손상)된 것으로 결정했을 때, 수신기로부터 재송신 요청을 수신한다. 서버는 네트워크 인터페이스 모듈을 통해 재송신 요청을 수신한 TCP/IP 모듈을 통해 재송신 요청을 수신한다. 단계(125)에서, 서버는 요청된 데이터 패킷(재송신될)이 버퍼 내에 있는지를 결정한다. 데이터 패킷이 버퍼 내에 있다면, 단계(130)에서, 서버는 버퍼로부터 요청된 데이터 패킷을 검색하고, 이들 패킷을 네트워크 인터페이스 모듈을 통한 송신을 위해 TCP/IP 모듈에 전달한다. 데이터 패킷이 버퍼 내에 존재하지 않는다면, 서버는 요청된 데이터 패킷을 재송신할 수 없다.

도 2a를 다시 참조하면, 단계(205)에서, 클라이언트 디바이스는 새로운 데이터 패킷(들)을 수신한다. 재송신된 데이터 패킷(들)은 네트워크 인터페이스 모듈을 통해 TCP/IP 모듈로부터 수신된다. 단계(210)에서, 클라이언트는 새로운 데이터 패킷(들)이 분실(소실, 손상)되었는지를 결정한다. 본 명세서에서, 용어 "훼손된 데이터"는 분실, 소실, 또는 손상된 임의의 데이터를 포함한다. 새로운 데이터 패킷(들)이 분실(소실, 손상)되었다면, 단계(215)에서, 클라이언트는 재송신 요청을 생성하고, 재송신 요청을 송신을 위해 네트워크 인터페이스 모듈에 전달하는 TCP/IP 모듈을 통해, 이 요청을 서버에 전송한다. 단계(220)에서, 클라이언트는, 클라이언트가 재송신된 데이터 패킷(들)을 기다리는 시간을 제한하기 위해 타이머를 설정한다. 수신된 데이터가 훼손되지 않았다면, 이 데이터는 후속적인 렌더링을 위해 큐에 삽입된다.

도 2b를 다시 참조하면, 단계(225)에서, 클라이언트는 네트워크 인터페이스 모듈로부터 재송신된 데이터 패킷(들)을 수신한 TCP/IP 모듈로부터 재송신된 데이터 패킷(들)을 수신한다. 단계(230)에서, 클라이언트는 타이머를 검사함으로써(도 2a를 참조), 재송신된 데이터 패킷(들)이 너무 늦었는지를 검사한다. 재송신된 데이터 패킷(들)이 너무 늦지 않았다면, 단계(235)에서, 재송신된 데이터 패킷(들)은 적합한 순서로의 렌더링을 위해 큐에 삽입된다. 재송신된 데이터 패킷(들)이 너무 늦었다면, 단계(240)에서, 클라이언트는 재송신된 데이터 패킷(들)을 폐기한다.

도 2c를 다시 참조하면, 단계(245)에서, 클라이언트는 다음 시퀀스 번호를 갖는 데이터 패킷이 이용가능한지를 검사하기 위해 시퀀스 번호를 검사한다. 다음 시퀀스 번호를 갖는 데이터 패킷이 이용가능하다면, 단계(250)에서, 데이터 패킷은 렌더링을 위해 큐에 삽입된다. 다음 시퀀스 번호를 갖는 데이터 패킷이 이용가능하지 않다면, 클라이언트는, 렌더링을 위해 큐에 삽입할 데이터 패킷을 찾을 때까지, 데이터 패킷의 검사를 지속한다. 또한, 일부 오류 또는 분실 데이터 패킷(들)을 감추거나 속이기 위해, 오류 은폐가 이용가능할 수 있다.

도 3을 다시 참조하면, 프로토콜 스택이 도시된다. 프로토콜 스택은 프로토콜 스택의 최상위 계층에 애플리케이션 계층을 나타낸다. 애플리케이션 계층 바로 아래는 RTP/MPEG TS 계층이다. RTP/MPEG TS 계층 바로 아래는 본 발명의 RMP 계층이다. RMP 계층은, 차례로 인터넷 프로토콜(IP) 계층에 의해 지원되는 TCP 및 UDP 계층에 의해 지원된다. TCP, UDP 및 IP 계층은 전형적으로 ISO 프로토콜 스택의 계층 3 및 계층 4로 여겨진다. 계층 3 및 계층 4는 전형적으로 링크 계층{예를 들어, 미디어 액세스 제어(MAC) 계층일 수 있는 계층 2} 및 물리 계층(계층 1)에 의해 지원된다.

본 발명의 RMP 방법은 유연성 있는 소프트웨어 라이브러리, 하드웨어, 펌웨어, 임의의 컴퓨터 또는 처리기, 애플리케이션 특정 집적 회로(ASIC), 축소 지령 세트 컴퓨터(RISC, Reduced Instruction Set Computer), FPGA(field programmable gate array; 현장 프로그램 가능 게이트 어레이) 또는 이들의 조합으로 구현될 수 있다. 본 발명의 RMP 방법은 소켓과 유사한 사용자 공간 API와, 스트리밍 서버 및 재생 애플리케이션과의 통합을 쉽게하는, 기초 송신 수단을 사용한다. 본 발명의 RMP 방법은 이 방법이 지원하는 스트리밍 애플리케이션에 대해 투명하다. UDP 데이터 채널 및 TCP 제어 채널은 내부에 유지된다. 본 발명의 RMP 방법은 FEC 및 하이브리드 ARQ와 같은 다른 에러 복구 방식을 지원하도록 확장가능하다.

재송신 요청 및 응답을 위해 교환된 예시적인 포맷의 메세지는 도 4a 및 도 4b에 도시된다. 재송신 요청/응답 메세지 모두는 포맷이 도 4a에 도시된 공통 헤더를 갖는다. 도 4b는 패킷 길이 필드, 패킷 타입 필드 및 패킷 서브타입 필드를 포함하는 재송신된 패킷, 플래그 및 페이로드(재송신된 데이터)의 포맷을 도시한다. 페이로드는 이전의 송신에서 분실된 데이터 패킷(또는 프레임)이다. 도 4c에 도시된 바와 같이, 재송신 요청/NACK 제어 패킷은 패킷 길이 필드, 패킷 타입 및 서브타입 필드, 플래그, 시작 시퀀스 번호 및 종료 시퀀스 번호를 포함한다. 시작 시퀀스 번호 및 종료 시퀀스 번호 필드는 수신기가 재송신되도록 요청하는 패킷의 시퀀스 범위를 나타낸다. 도 4d에 도시된 대안적인 실시예에서, 재송신 요청/NACK 제어 패킷은 패킷 길이 필드, 패킷 타입 및 서브타입 필드, 플래그, 기본 시퀀스 번호 및 비트맵을 포함한다. 기본 시퀀스 번호 및 비트맵은 수신기가 재송신되도록 요청하는 패킷의 시퀀스를 나타낸다.

위에 서술된 본 발명의 RMP 방식에서, 데이터 채널 상에서 전송된 패킷에 대해 어떠한 교체도 이루어지지 않았다. 따라서, 역 호환성이 유지된다. 또한, 본 발명의 RMP 방식은, 분실된 미디어 패킷만이 요청되고, 낮은 오버헤드로 제어 채널상에 재송신되기에, 대역폭을 효율적으로 사용한다. 분실된 패킷 요청은 NACK(부정 확인 응답)로 작용하고, 또한, 피드백을 전송기에 제공한다. 분실된 패킷이 복구 시간 윈도우 내에서 여러 회 재전송될 수 있기에, 상당히 다른 채널 상태하에서 높은 신뢰도를 제공할 수 있다. 또한, 본 발명의 RMP 방식은 재송신을 위한 최대 대기 시간, 즉 복구 윈도우를 가짐으로써, 애플리케이션의 레이턴시 제약을 강제하고, 따라서, 주어진 시간 제약 내에 최선의 노력(best effort) 전달 모델 상에서 동작한다.

위의 실시예가 비디오 송신을 사용하여 설명되었다는 것을 주목하라. 본 발명은 또한, 오디오 및 다른 실시간 멀티미디어 스트리밍 애플리케이션의 송신에 적용될 수 있다.

도 5는 예시적인 서버 구현의 개략도를 도시한다. 서버는 스트리밍 애플리케이션 모듈, 버퍼(메모리), 신뢰성 있는 미디어 프로토콜(RMP) 모듈, UDP/IP 모듈, TCP/IP 모듈 및 네트워크 인터페이스 모듈을 포함한다. 스트리밍 애플리케이션 모듈은 로컬 파일 또는 네트워크 인터페이스 모듈로부터 실시간 데이터를 획득한다. 네트워크 인터페이스 모듈은 네트워크로부터 패킷을 송신/수신하는 컴퓨터에 존재하는 네트워크 카드이다. 단일 네트워크 카드는 송신 및 수신의 양방향 기능을 한다. 네트워크 인터페이스 모듈의 예시는 컴퓨터 네트워크에 연결시키는 이더넷 카드, IEEE 802.11/WiFi 카드이다. 스트리밍 애플리케이션 모듈은, 데이터가 패킷화되지 않았다면, 실시간 데이터를 패킷화한다. 스트리밍 애플리케이션 모듈은 실시간 데이터 패킷(미디어 RTP 패킷)을 RMP 모듈에 전달한다. RMP 모듈은 데이터 전달 및 애플리케이션과의 통합을 위한 소켓과 유사한 애플리케이션 프로토콜 인터페이스(API)를 제공한다. RMP 모듈은 또한 데이터 패킷의 신뢰성 있는 송신을 다룬다. 초기 송신에 대해, RMP 모듈은 UDP/IP 데이터 채널을 사용하고, 예를 들어, 이더넷 인터페이스 또는 IEEE 802.11 인터페이스일 수 있는 네트워크 인터페이스를 통해, 데이터 패킷을 수신기(들)에 전송한다. 또한, RMP 모듈은 송신된 패킷의 로컬 복사본을 버퍼 내에 캐싱한다. RMP 모듈은 TCP/IP 제어 채널을 통해 수신기로부터 재송신 요청/부정 확인 응답을 수신한다. RMP 모듈은, 요청된 패킷이 버퍼 내에 있다면, TCP/IP 제어 채널을 사용하여, 요청된 패킷을 수신기에 재송신한다. 박스 라벨 "Conf"는 RMP 모듈에 대한 "구성 인터페이스"이다. RMP 모듈은 초기화 시점에, 캐시 크기, 패킷 복구를 기다리는 최대 시간 등과 같은 파라미터를 설정하도록 구성될 수 있다.

도 6은 클라이언트 디바이스의 예시적인 구현의 개략도를 도시한다. 클라이언트는 재생/스트리밍 애플리케이션 모듈, 디스플레이/스피커 모듈, 버퍼(메모리), 신뢰성 있는 미디어 프로토콜(RMP) 모듈, UDP/IP 모듈, TCP/IP 모듈 및 네트워크 인터페이스를 포함한다. 네트워크 인터페이스는 예를 들어, 이더넷 인터페이스 또는 IEEE 802.11 인터페이스일 수 있다. 네트워크 인터페이스는 들어오는 메세지 모두를 수신한다. 메세지는 다른 소켓/주소 상에서 도착한다. 네트워크 인터페이스는 따라서, 수신된 메세지를 어디에 전달할지를 결정한다. 새로운 들어오는 데이터 패킷은 네트워크 인터페이스 모듈에 의해 UDP/IP 인터페이스에 전달된다. 데이터 패킷의 재송신을 위한 요청 및 재송신된 데이터 패킷은 RMP 모듈에 의해 TCP/IP 모듈에 전달된다. RMP 모듈은 임의의 수신된 데이터 패킷이 훼손되었는지를 결정하고, 패킷 복구를 조직하기(orchestrate) 위해 UDP/IP 및 TCP/IP 모두를 사용한다. RMP 모듈은 임의의 훼손된 데이터 패킷에 대한 재송신 요청을 생성하고, 재송신 요청을 네트워크 인터페이스에 의해 네트워크를 통한 송신을 위해 TCP/IP 모듈에 전달한다. 또한, RMP 모듈은 재정렬을 위해 로컬 버퍼에 수신된 패킷을 저장한다. 일단 재송신된 패킷이 TCP/IP 모듈을 통해 TCP 제어 채널로부터 수신되면, RMP 모듈은 올바른 순서로 패킷을 정렬한다. RMP는 시퀀스 넘버로 소팅된 큐를 유지하고, 패킷을 재정렬하며, 이러한 버퍼 영역/큐 내에 패킷을 삽입한다. 복구 윈도우가 만기될 때, RMP 모듈은 패킷을 재생/스트리밍 애플리케이션에 전달한다. RMP 모듈은 데이터 전달 및 애플리케이션과의 통합을 위해 소켓과 유사한 애플리케이션 프로토콜 인터페이스(API)를 제공한다. 일부 패킷이 복구 윈도우의 타임아웃에 의해 복구되지 않을 수 있다는 것을 주목하라. 복구 윈도우의 만기 이후 도착한 데이터 패킷은 폐기된다. 스트리밍/재생 애플리케이션은 데이터를 역패킷화 및/또는 디코딩하고, 데이터를 디스플레이/스피커에 전달한다. 들어오는 패킷은 RMP "버퍼 영역"에 저장되고, 애플리케이션이 패킷을 요청할 때마다, 렌더링(디스플레이)을 위한 애플리케이션에 전달된다. 박스 라벨 "Conf"는 RMP 모듈에 대한 "구성 인터페이스"이다. RMP 모듈은 초기화 시점에, 캐시 크기, 패킷 복구를 위해 기다리는 최대 시간 등과 같은 파라미터를 설정하도록 구성될 수 있다.

본 발명의 상기 방식이 무선 네트워크에 대해 서술되었지만, 방식은 패킷 분실을 수반하는 임의의 종류의 네트워크에서 사용될 수 있다.

본 발명이, 하드웨어, 소프트웨어, 펌웨어, 특수 목적 처리기, 또는 이들의 조합의 다양한 형식으로 구현될 수 있다는 것이 이해되어야 한다. 바람직하게 본 발명은 하드웨어와 소프트웨어의 조합으로 구현될 수 있다. 더욱이, 소프트웨어는 프로그램 저장 디바이스 상에 명백하게 구현되는 애플리케이션 프로그램으로 바람직하게 구현될 수 있다. 애플리케이션 프로그램은 임의의 적합한 아키텍처를 포함하는 기계에 업로드 될 수 있고, 기계에 의해 실행될 수 있다. 바람직하게, 기계는 하나 이상의 중앙 처리 장치(CPU), 랜덤 액세스 메모리(RAM) 및 입/출력(I/O) 인터페이스(들)와 같은 하드웨어를 갖는 컴퓨터 플랫폼상에서 구현될 수 있다. 또한, 컴퓨터 플랫폼은 운영체제 및 마이크로지령 코드를 포함할 수 있다. 본 명세서에서 서술된 다양한 처리 및 기능은 운영체제를 통해 실행되는 마이크로 지령코드의 일부 또는, 애플리케이션 프로그램의 일부일 수 있다(또는, 이들의 조합일 수 있다). 게다가, 추가적인 데이터 저장 디바이스 및 프린터와 같은 다양한 다른 주변 장치는 컴퓨터 플랫폼에 연결될 수 있다.

구성 시스템 요소의 일부와 첨부 도면에 서술된 방법 단계가 소프트웨어로 바람직하게 구현되기에, 시스템 구성 요소 사이의 실제 연결(또는, 처리 단계)은, 본 발명이 프로그래밍 되는 방식에 따라 달라질 수 있음이 더 이해될 것이다. 또한, 본 명세서의 교시가 제공된다면, 당업자는 본 발명의 이들 및 유사한 구현 또는 구성을 계획할 수 있다.

205 : 새로운 패킷을 수신 210 : 패킷 분실
215 : 재송신 요청을 전송 220 : 타이머를 설정
225 : 재송신된 패킷을 수신 230 : 재송신된 패킷이 늦었는지?
235 : 큐에 패킷을 삽입 240 : 패킷을 폐기
245 : 다음 시퀀스번호가 이용가능한지?
250 : 애플리케이션에 대한 큐에 패킷을 전달

Claims

실시간 데이터 스트리밍을 위한 서버를 동작시키기 위한 방법으로서, 상기 방법은 서버에서,
버퍼에서 송신될 데이터를 서버에서 버퍼링하는 단계로서, 버퍼는 데이터의 미리 결정된 양을 유지하고, 버퍼링된 데이터는 가장 최근에 수신된 데이터인, 버퍼링하는 단계;
데이터그램 프로토콜을 사용하여 제 1 채널을 통해, 버퍼로부터 검색된 데이터를 클라이언트 디바이스에 멀티캐스팅하는 단계;
송신 제어 프로토콜을 사용하여 제 2 채널을 통해, 클라이언트 디바이스에 의해 훼손되거나 또는 분실되는 것으로 결정된 데이터의 재송신을 위한 요청을 상기 클라이언트 디바이스로부터 수신하는 단계로서, 상기 요청은 데이터의 멀티캐스팅 프로세스 동안 훼손되거나 또는 분실되는 것으로 결정된 임의의 데이터에 대해 수신되는, 수신하는 단계;
상기 요청된 데이터가 상기 버퍼 내에 있는지를 서버에 의해 결정하는 단계; 및
상기 요청된 데이터가 상기 버퍼 내에 있는 경우, 데이터 및 오류 복구의 엔드 투 엔드 확인 응답(end-to-end acknowledgement)을 제공하는 송신 제어 프로토콜을 사용하여 상기 제 2 채널을 통해, 상기 요청된 데이터를 상기 클라이언트 디바이스에 유니캐스팅하는 단계로서, 상기 유니캐스팅은 데이터의 멀티캐스팅 프로세스 동안 훼손되거나 또는 분실되는 것으로 결정된 임의의 데이터에 대해 발생하는, 유니캐스팅하는 단계;
를 포함하는, 서버를 동작시키기 위한 방법.
제1항에 있어서,
상기 데이터그램 프로토콜은 사용자 데이터그램 프로토콜인, 서버를 동작시키기 위한 방법.
제1항에 있어서,
상기 버퍼링된 데이터는 로컬 파일로부터 검색되거나, 또는 네트워크 인터페이스를 통해 수신되는, 서버를 동작시키기 위한 방법.
실시간 데이터 스트림을 수신하는 클라이언트 디바이스를 동작시키기 위한 방법으로서, 상기 방법은 클라이언트 디바이스에서,
사용자 데이터그램 프로토콜을 사용하여 제 1 채널을 통해, 서버로부터 데이터를 수신하는 단계;
상기 수신된 데이터가 훼손된(corrupted) 데이터를 포함하는지를 결정하는 단계;
상기 결정에 응답하여, 상기 수신된 데이터를 큐(queue)에 삽입하는 단계;
송신 제어 프로토콜을 사용하여 제 2 채널을 통해, 훼손되는 것으로 결정된 데이터의 재송신을 위한 요청을 상기 서버로 송신하는 단계로서, 상기 요청은 데이터의 수신 프로세스 동안 훼손되거나 또는 분실되는 것으로 결정된 임의의 데이터에 대해 수신되는, 송신하는 단계;
클라이언트 디바이스에서 타이머를 설정하는 단계;
송신 제어 프로토콜을 사용하여 상기 제 2 채널을 통해, 상기 서버로부터 상기 재송신된 데이터를 수신하는 단계로서, 상기 재송신된 데이터는 데이터의 수신 프로세스 동안 훼손되거나 또는 분실되는 것으로 결정된 임의의 데이터에 대해 수신되는, 수신하는 단계;
상기 재송신된 데이터가 시기 적절하게 수신되었는지를 상기 타이머를 사용하여 결정하는 단계;
상기 재송신된 데이터가 시기 적절하게 수신된 것을 결정한 후, 상기 수신되고 재송신된 데이터를 상기 큐에 삽입하는 단계; 및
상기 재송신된 데이터가 시기 적절하게 수신되지 않은 것을 결정한 후, 상기 수신되고 재송신된 데이터를 폐기하는 단계;
를 포함하는, 클라이언트 디바이스를 동작시키기 위한 방법.
제4항에 있어서,
상기 큐에 삽입된 데이터(queued data)를 렌더링하는 단계를 더 포함하는, 클라이언트 디바이스를 동작시키기 위한 방법.
실시간 데이터 스트리밍을 위한 서버를 동작시키기 위한 장치로서,
송신될 데이터를 서버에서 버퍼링하는 수단으로서, 버퍼링하는 수단은 데이터의 미리 결정된 양을 유지하고, 버퍼링된 데이터는 가장 최근에 수신된 데이터인, 버퍼링하는 수단;
데이터그램 프로토콜을 사용하여 제 1 채널을 통해, 상기 버퍼링하는 수단으로부터 검색된 데이터를 클라이언트 디바이스에 멀티캐스팅하는 수단;
송신 제어 프로토콜을 사용하여 제 2 채널을 통해, 클라이언트 디바이스에 의해 훼손되거나 또는 분실되는 것으로 결정된 데이터의 재송신을 위한 요청을 상기 클라이언트 디바이스로부터 수신하는 수단으로서, 상기 요청은 데이터의 멀티캐스팅 동안 훼손되거나 또는 분실되는 것으로 결정된 임의의 데이터에 대해 수신되는, 수신하는 수단;
상기 요청된 데이터가 상기 버퍼링하는 수단 내에 있는지를 결정하는 수단; 및
상기 요청된 데이터가 상기 버퍼링하는 수단 내에 있는 경우, 데이터 및 오류 복구의 엔드 투 엔드 확인 응답(end-to-end acknowledgement)을 제공하는 송신 제어 프로토콜을 사용하여 상기 제 2 채널을 통해, 상기 요청된 데이터를 상기 클라이언트 디바이스에 유니캐스팅하는 수단으로서, 상기 요청은 데이터의 수신 동안 훼손되거나 또는 분실되는 것으로 결정된 임의의 데이터에 대해 수신되는, 유니캐스팅하는 수단;
을 포함하는, 서버를 동작시키기 위한 장치.
제6항에 있어서,
상기 데이터그램 프로토콜은 사용자 데이터그램 프로토콜인, 서버를 동작시키기 위한 장치.
제6항에 있어서,
상기 버퍼링된 데이터는 로컬 파일로부터 검색되거나, 또는 네크워크 인터페이스를 통해 수신되는, 서버를 동작시키기 위한 장치.
실시간 데이터 스트림을 수신하는 클라이언트 디바이스를 동작시키기 위한 장치로서,
데이터그램 프로토콜을 사용하여 제 1 채널을 통해, 서버로부터 데이터를 수신하는 수단;
상기 수신된 데이터가 훼손된(corrupted) 데이터를 포함하는지를 결정하는 수단;
상기 결정에 응답하여, 상기 수신된 데이터를 큐(queue)에 삽입하는 수단;
상기 수신된 데이터가 훼손된 데이터를 포함한다는 것을 결정한 후, 송신 제어 프로토콜을 사용하여 제 2 채널을 통해, 상기 훼손된 데이터의 재송신을 위한 요청을 상기 서버로 송신하는 수단으로서, 상기 요청은 데이터의 수신 동안 훼손되거나 또는 분실되는 것으로 결정된 임의의 데이터에 대해 수신되는, 송신하는 수단;
클라이언트 디바이스에서 타이머를 설정하는 수단;
송신 제어 프로토콜을 사용하여 상기 제 2 채널을 통해, 상기 서버로부터 상기 재송신된 데이터를 수신하는 수단;
상기 재송신된 데이터가 시기 적절하게 수신되었는지를 상기 타이머를 사용하여 결정하는 수단; 및
재송신된 데이터가 시기 적절하게 수신되었는지를 결정하는 수단이 상기 재송신된 데이터가 시기 적절하게 수신된 것을 결정한 경우, 상기 수신되고 재송신된 데이터를 상기 큐에 삽입하고, 재송신된 데이터가 시기 적절하게 수신되었는지를 결정하는 수단이 상기 재송신된 데이터가 시기 적절하게 수신되지 않은 것을 결정한 경우, 상기 수신되고 재송신된 데이터를 폐기하는 수단;
을 포함하는, 클라이언트 디바이스를 동작시키기 위한 장치.
제9항에 있어서,
상기 큐에 삽입된 데이터를 렌더링하는 수단을 더 포함하는, 클라이언트 디바이스를 동작시키기 위한 장치.