KR20080093462A

KR20080093462A - 패킷 데이터 비트 레이트 조정 및 데이터 패킷 재전송 간 협동

Info

Publication number: KR20080093462A
Application number: KR1020087023885A
Authority: KR
Inventors: 엠레 악수; 데이비드 레옹; 이고르 쿠르시오
Original assignee: 노키아 코포레이션
Priority date: 2004-05-13
Filing date: 2005-05-11
Publication date: 2008-10-21
Also published as: WO2005112382A1; AU2005242613A1; JP2007537640A; JP2010154547A; US20050254508A1; KR20070009739A; EP1745629A1; CN1957576A

Abstract

패킷화(된) 데이터 비트 레이트 조정 및 데이터 패킷 재전송 간 협력을 향상시키기 위한 방법은, 서버로부터 클라이언트로 제1비트 레이트로서 데이터 패킷들을 전송하고; 전송된 데이터 패킷들을 서버 버퍼에 저장하고, 전송된 데이터 패킷들을 클라이언트 버퍼에 저장하고, 전송 중, 전송된 데이터 패킷들의 손상과 관련된 손상 정보를 서버로 신호하고, 신호 된 손상 정보는 서버에 의해 해석되어, 서버로부터 클라이언트로 서버 버퍼에 저장된 데이터 패킷들의 재전송이 요구되는지를 판단할 수 있게 하고; 클라이언트 버퍼의 상태와 관련된 클라이언트 버퍼 정보를 서버로 신호하고, 클라이언트 버퍼 정보는 서버에 의해 해석되어 데이터 패킷들의 재전송이 요구되는지를 판단할 수 있게 한다.

Description

패킷 데이터 비트 레이트 조정 및 데이터 패킷 재전송 간 협동 {Cooperation between packetized data bit-rate adaptation and data packet re-transmission}

본 발명은 패킷 데이터 비트 레이트 조정 및 데이터 패킷 재전송 간 협력을 향상시키기 위한 방법, 시스템, 클라이언트, 서버, 컴퓨터 프로그램 및 컴퓨터 프로그램을 포함하는 컴퓨터로 읽을 수 있는 기록 매체에 관한 것이다.

스트리밍은, 첫 번째 양태에 있어, 스피치, 오디오 및 비디오 스트림 같은 동기된 미디어 스트림들이 데이터 네트워크를 통해 클라이언트로 전송될 때, 그 스트림들을 연속으로 재생하도록 클라이언트에 자리한 어플리케이션의 능력(ability)을 말한다. 두 번째 양태에 있어서, 스트리밍은 대화형 어플리케이션들 같은 실시간 저지연(low-delay) 어플리케이션들을 말하기도 한다.

스트리밍 서비스들 가운데 최상위에 형성될 수 있는 어플리케이션들은 온-디맨드(on-demand) 및 라이브 정보 전송 어플리케이션들로 구분될 수 있다. 첫 번째 카테고리의 예들이 음악과 주문형 뉴스 (news-on-demand) 어플리케이션들이다. 실시간 저지연 어플리케이션들은, 이를테면, 멀티미디어 (비디오) 전화 또는 VoIP (Voice over IP) 및 임의 타입의 대화형 멀티미디어 어플리케이션이다.

고정 인터넷 프로토콜 (IP) 네트워크들을 통한 스트리밍은 오늘날 이미 중대한 어플리케이션이 되었다. IETF (Internet Engineering Task force) 및 W3C (World Wide Web Consortium)이 고정 IP 스트리밍 서비스에 사용되는 일련의 프로토콜들을 개발했지만, 완전하게 규격화된 스트리밍 구조는 아직 정의되지 않고 있다. 3GPP (third Generation Partnership Project)에 의해 개발된 표준들에 따른 제3세대 (3G) 모바일 통신 시스템들에 있어서, 3G 패킷 교환형 스트리밍 서비스 (PSS)가, 예를 들어 어플리케이션들과 멀티미디어 콘텐츠를 다운로드하는 등의 3G 멀티 미디어 메시징 서비스 (MMS)와, 대화형 & 스트리밍 서비스들의 간극을 메우고 있다. PSS는 이제부터 TS 26.234라 칭할, 기술 사양서 3GPP TS 26.234 v0.3.0 "투과식(transparent) 단대단(end-to-end) 패킷 교환형 스트리밍 서비스 (PSS); 프로토콜들과 코덱들 (제6판) TSG-SA4 PSM SWG 내부 작업 초안"에 상세히 기술되어 있다.

PSS는 모바일 스트리밍 어플리케이션들을 가능하게 하며, 이때, 단말들의 복잡도는 대화형 서비스들에 필요로 되는 복잡도 보다 낮은데, 그 이유는 어떤 미디어 입력 장치들과 인코더들도 필요로 되지 않기 때문이고, 덜 복잡한 프로토콜들이 사용될 수 있기 때문이다. PSS는 스트리밍 제어 프로토콜들, 트랜스포트(transport,전송) 프로토콜들, 미디어 코덱들 및 장면 설명 프로토콜들로 된 기본 집합을 포함한다.

도 1은 TS 26.234로부터 채택된 것으로서, 콘텐츠나 미디어 서버 및 클라이언트 사이에 스트리밍 (streamable) 전송과 비스트리밍 (non-streamable) 전송 모 두를 제어하는 PSS 프로토콜 스택(1)을 도시한 것이다.

스트리밍 목적으로 생성되지 않은 멀티미디어 콘텐츠 (가령, 단말 기기에 기록된 MMS 클립들), 스틸 이미지들, 비트맵 및 벡터 그래픽스, 텍스트, 시분할 텍스트 및 합성 오디오 등과 같은 비스트리밍 콘텐츠(106)이 HTTP (Hypertext Transfer Protocol)(107)에 따라 전송되고, 이 프로토콜은 하위 TCP (Transport Control Protocol)(108) 및 추가적 하위 IP(105) 서비스들을 이용한다.

비디오, 오디오 및 스피치 같은 스트리밍 콘텐츠(101)는 먼저 적응 계층(103) 내 RTP (Real-time Transport Protocol)(102)의 페이로드 포맷으로 전환된다. 상기 RTP는 하위 UDP (User Datagram Protocol)(104) 서비스들과 이어서 하위 IP 프로토콜 (105) 서비스들을 이용하여 실시간 혹은 스트리밍 데이터를 전송하기 위한 수단을 제공한다.

1889 IETF RFC (Request for Commnets) 문서 " RTP: 실시간 어플리케이션들을 위한 트랜스포트 프로토콜"에 명시된 RTP(102)는, 인터랙티브(interactive) 오디오 및 비디오 같은 실시간 특성을 가진 데이터를 위한 단대단 운송 서비스들을 제공한다. 이 서비스들에는, 페이로드 타입 식별, 시퀀스 넘버링, 타임스탬핑(timestaping) 및 운송 모니터링이 포함된다. RTP 자체는 시기 적절한 운송을 보장할 어떠한 메커니즘을 제공하거나 다른 QoS (quality-of-service) 보장을 지원하지 않으며, 그런 일은 하위 계층 서비스들에 의존한다. 그것은 운송을 보장하거나, 잘못된 운송을 방지하지도 못하며, 하위 네트워크가 안정성이 있고 시퀀스에 따라 패킷들을 운송하는지도 추정하지 못한다. RTP에 포함된 시퀀스 넘버들이 수 신기로 하여금 발신자의 패킷 시퀀스를 재구성할 수 있게 할 수 있지만, 시퀀스 넘버들은 가령 비디오 디코딩시 반드시 패킷들을 시퀀스 대로 디코딩하지 않고도 적절한 패킷 위치를 판단하는데 사용될 수도 있다.

실제로 데이터를 운반하는 RTP(102)와 가까이 링크되어 있는 것이 RTP 제어 프로토콜 (RTCP)로서, 이것은 서비스 품질 (QoS)을 감시하고 RTP에 기반하는 진행중인 세션 내 참여자들에 대한 정보를 전달한다. RTCP는 데이터 패킷들과 동일한 배포 메커니즘을 사용하는, 세션 내 모든 참여자들로의 제어 패킷들의 주기적 전송에 기반하고 있다. RTCP는 데이터 전송의 품질에 대한 피드백을 제공한다. 이것은 트랜스포트 프로토콜로서의 RTP 역할의 핵심 부분으로서 다른 트랜스포트 프로토콜들의 흐름 및 혼잡 제어 기능들과 관련이 있다. 피드백은 데이터 전송시의 오류들을 진단하는데 바로 유용할 수 있다. 피드백 기능은 RTCP 발신자 및 수신자 리포트들에 의해 수행된다.

RTCP에 의해 제공된 품질 피드백에 기초하여, PSS는, 전송 중 RTP 패킷들을 잃게 될 때 만나게 되는 품질 저하를 경감시키기 위한 RTP 재전송 체계를 제공한다. 잃어버린 패킷들은 RTCP 기반 품질 피드백에 의해 지시되므로 서버로부터 클라이언트로 효율적으로 재전송된다. 이것은 서버로 하여금, 서버가 이미 보냈던 RTP 패킷들을 어떤 전송 깊이(depth)까지 저장해야 할 필요가 있다, 이를테면, 마지막 5초 안에 보내졌던 모든 RTP 패킷들이, 이들의 재전송을 고려해 서버의 RTP 패킷 전송 버퍼들 안에 저장될 필요가 있다.

비스트리밍 콘텐츠(106)에 있어서는 HTTP(107)의 내장된 세션 설정 및 제어 사양들이 이 콘텐츠를 전송하는데 충분한 반면, 스트리밍 콘텐츠(101)에 대해서는 RTP/UDP/IP를 통해 콘텐츠 서버에서 클라이언트로 전송된 스트리밍 비디오를 가령 시작, 종료 및 일시정지하기 위해, 고급형 세션 설정 및 제어 프로토콜이 발동되어야 한다. 이러한 작업은 실시간 스트리밍 프로토콜 (RTSP)(109)에 의해 수행되며, 이것은 하위 TCP(108) 또는 하위 UDP(104)를 사용할 것이다. RTSP는 적어도 스트리밍 세션을 설정하는데 프레젠테이션 서술(110)을 필요로 한다. 그러한 프레젠테이션 서술(110)은 가령 세션 서술 프로토콜 (SDP) 파일의 형태로 사용될 수 있을 것이다. 상기 SDP 파일은, 이를테면 세션 이름과 저자 등의 세션 설명, 제공될 미디어 타입, 어드레스, 포트, 포맷 등등과 같이 상기 미디어를 수신할 정보, 및 미디어의 비트 레이트를 포함한다.

PSS는, PSS 세션이, 사용가능한 네트워크 자원들에 대해 전송 및 콘텐츠 레이트들 (가령 비트 레이트들)을 조정할 수 있게 하기 위해, 활용될 수 있는 다수의 프로토콜들과 기능들을 포함한다. 이러한 레이트 조정의 목적은 당연히, 사용가능 자원들을 가진 최종 사용자에게 가능한 최상의 체험의 질(QoE)을 제공하면서, 인터럽트에 구애되지 않는 미디어 재생을 유지하는 것이다. 레이트 조정은, 이용가능한 네트워크 자원들이 평가되고 전송 레이트들이 그 이용가능한 네트워크 링크 레이트들로 조정될 것을 요한다. 이것이 네트워크 버퍼들의 오버플로를 방지할 수 있고, 그에 따라 패킷 손실을 막을 수 있다. 전송된 미디어의 실시간 특성들은, 그 미디어가 너무 늦게 도달해 무용해지지 않도록 고려되어야 한다. 이것은, 미디어 콘텐츠 레이트 (즉, 콘텐츠의 비트 레이트)가 전송 레이트로 조정될 것을 요할 것이다.

클라이언트가 유용한 데이터를 버려야 하는 결과를 가져오는 버퍼 오버플로(overflow)를 피하는 한편, 계속해서 서버로 하여금 클라이언트 버퍼로 가능한 한 많은 데이터를 전달할 수 있게 하기 위해, 클라이언트 버퍼 피드백에 대한 기능이 PSS 범주 안에서 정의된다. 이것은 서버로 하여금 클라이언트 측의 버퍼링 상황을 면밀히 모니터할 수 있게 하고, 클라이언트 버퍼 언더플로(underflow)를 피하기 위해 서버가 할 수 있는 일을 하게 만든다. 클라이언트는 서버가 활용할 수 있는 버퍼 공간의 크기와, 원하는 타겟 보호 레벨을 특정한다. 원하는 보호 레벨이 달성될 때, 서버는 미디어의 품질을 향상시키기 위해 그 보호 레벨을 유지하는데 필요한 것 이상으로 임의의 자원들을 사용할 수 있다. 서버는 또, 버퍼 언더플로와 그로 인한 재생 중지를 피하고자, 미디어 품질이 저하될 필요가 있는지를 판단하기 위해 버퍼 피드백 정보를 활용할 수 있다. 서버에 있어서, 레이트 조정을 수행하는 한 가지 방법은, 동일한 콘텐츠의 여러 부호화 버전들을 보유하는 것으로, 이때 인코딩 비트 레이트가 그 차이의 기준으로서 작용한다. 이때 레이트 조정은 클라이언트 버퍼의 상태에 따라, 서로 다르게 부호화된 콘텐츠 사이를 스위칭함으로써 수행될 수 있다.

PSS에 대한 레이트 조정은, 전송 및 콘텐츠 레이트가 서버에 의해 제어된다는 의미에서 서버 중심적 (server-centric)이다. 서버는 RTCP와 RTSP를 클라이언트 및 네트워크 상태에 대한 기본 정보 소스들로서 이용한다.

PSS의 레이트 조정을 허용하기 위해, 클라이언트 버퍼 피드백 시그날링 기능 이 PSS 클라이언트들과 PSS 서버들에 의해 지원되어야 한다. 클라이언트 버퍼 피드백 시그날링 기능을 지원하는 PSS 클라이언트들과 서버들에 있어서, 적어도 다음과 같은 부분들이 구축되어져야 한다:

- RTSP를 통해 서버로, 레이트 조정을 위해 클라이언트가 제공하는 버퍼의 사이즈 (즉, 바이트 단위)가 시그날링 됨.

- RTCP를 통해 서버로, 클라이언트 버퍼 내 가장 오래된 패킷의 시퀀스 넘버 ("oldest buffered sequence number 가장 오래된 버퍼링 시퀀스 넘버", OBSN)가 시그날링 됨. OBSN 정보는 이를테면 RTCP 어플리케이션 (APP) 패킷들로서 클라이언트에서 서버로 전송될 수 있다.

버퍼 사이즈, OBSN 파라미터들을 통해, 그리고 RTCP 수신기 보고문(reports)에 이미 포함된 "가장 높은 수신 시퀀스 넘버" HRSN을 이용해, 서버는 마지막 RTCP 보고문 전송 시점에 클라이언트 버퍼의 바이트 수를 산출할 수 있다.

산출된 클라이언트 버퍼 채움(fill) 레벨에 기초하여, 서버는 버퍼 오버플로를 피할 수 있다. 이 레벨은 또한 서버로 하여금 언제 버퍼 레벨이 떨어지는지를 검출할 수 있게 함으로써 언더플로를 피하고자 하는 조처를 취할 있게 할 것이다. 최고위 시퀀스 넘버를 가진 패킷의 타임스탬프, 가장 오래된 시퀀스 넘버를 가진 패킷의 타임스탬프, 그리고 가장 오래된 시퀀스 넘버를 가진 패킷의 플레이아웃(playout) 지연이 시그날링된 경우, 그들을 참조함으로써, 클라이언트 버퍼가 언더플로 되기 전의 시점이 서버에 의해 추정될 수 있다. 플레이아웃 지연은 클라이언트가 언더플로 되기 전 추정 시간의 정확도를 높인다. 이를테면, 저 프레임 레 이트 비디오의 경우, 플레이아웃 지연은 클라이언트에서의 총 버퍼링 시간에 크게 영향을 미칠 것이다.

그러나, PSS의 레이트 조정 기능과 RTP 재전송 기능의 결합은 문제점을 야기시킨다.

첫째, 클라이언트로부터 수신된 피드백에 기초해 서버가 클라이언트로 전송된 패킷 스트림의 비트 레이트를 변경하여 레이트 조정을 수행할 때, 서버는 그 전송 버퍼들을 모두 비운다. 그러한 비우기(flushing) 동작은, RTP 패킷 손실에 기인해 앞으로 있을 수 있는 RTP 패킷 재전송을 고려해 소정 전송 깊이로, 이미 전송된 RTP 패킷들을 저장하는 데 기반하는, RTP 재전송 방식의 적절한 기능을 심각하게 방해하거나 심지어는 작동 불능하게 만든다. 이를테면, 상기 비우기로 인해 상기 서버에서 이제 더 이상 사용 불가능한 RTP 패킷의 재전송이 요구되는 경우, 상기 서버는 상기 RTP 패킷을 다시 확보해야 할 것이고 (가령, 적합한 RTP 패킷을 찾기 위해 서버 측 3GP 파일의 단서(hint) 트랙들을 통해 재반복 하는 동작을 거침), 이것이 추가 지연을 일으키거나 아니면 더 이상 전혀 가능하지 않게 만들 수 있다. 상기 RTP 패킷의 상기 지연이나 상기 부족은 곧바로 상기 RTP의 최상부에서 실행되는 어플리케이션에 영향을 미친다. 이를테면, 관련 스트리밍 미디어의 재생이 교착되거나(frozen) 심지어 멈출 수 있다.

레이트 조정 (가령 RTCP APP 패킷들을 통한) 상황에서 클라이언트에 의해 ㅂ보고된 OBSN이, RTP 재전송 상황시 재전송을 위해 요구되는 RTP 패킷의 시퀀스 넘버보다 크거나 매우 가까울 때, 또 다른 문제가 일어난다. 상기 보고된 OBSN에 의 해 식별된 RTP 패킷은 디코딩 목적의 RTP 패킷 버퍼로부터 클라이언트에 의해 이동될 (가령, 디스플레이되기 위해 대기 될 포스트-디코더 버퍼로 넣어질) 첫 번째 RTP 패킷이다. 따라서, 보고된 OBSN 보다 작은 시퀀스 번호를 가진 RTP 패킷의 전송은 불필요하게 될 것이며 그에 따라 대역폭이 낭비될 것이다.

상술한 문제들의 관점에서 볼 때, 무엇보다, 본 발명의 목적은, 패킷화(된) 데이터 비트 레이트 조정과 데이터 패킷 재전송 사이의 협력을 향상시키는 방법, 시스템, 클라이언트, 서버, 컴퓨터 프로그램 및 컴퓨터 프로그램을 포함하는 컴퓨터로 읽을 수 있는 기록매체를 제공하는 데 있다.

본 발명의 제1양태에 따라, 패킷화(된) 데이터 비트 레이트 조정 및 데이터 패킷 재전송 간 협력을 향상시키는 방법이 제공되고, 이 방법은 서버로부터 클라이언트로 제1비트 레이트로서 데이터 패킷들을 전송하는 단계; 상기 전송된 데이터 패킷들 중 적어도 한 개를 적어도 한 서버 버퍼에 적어도 일시적으로 저장하는 단계; 상기 전송된 데이터 패킷들 중 적어도 한 개를 클라이언트 버퍼에 적어도 일시적으로 저장하는 단계; 상기 서버로의 상기 전송 중에 상기 전송된 데이터 패킷들 중 적어도 하나의 손상과 관련된 손상 정보를 신호하고, 상기 신호된 손상 정보는 상기 서버에 의해 해석되어, 상기 서버로부터 상기 클라이언트로 상기 서버 버퍼에 저장된 적어도 한 데이터 패킷의 재전송이 요구되는지를 판단하게 하는 단계; 상기 클라이언트 버퍼의 상태와 관련된 클라이언트 버퍼 정보를 상기 서버로 신호하는 단계; 상기 서버로부터 상기 클라이언트로 제2비트 레이트로서 데이터 패킷들을 전송하는 단계를 포함하고, 상기 제2비트 레이트는 적어도 부분적으로 상기 클라이언트 버퍼 정보에 기초해 정해지고, 상기 제1비트 레이트로 전송되어 상기 서버 버퍼 에 저장된 적어도 한 데이터 패킷은, 상기 데이터 패킷들이 상기 서버에서 상기 클라이언트로 상기 제2비트 레이트로 전송되기 시작할 때, 상기 서버 버퍼에 추가 저장된다.

상기 데이터 패킷들은, 가령 데이터 비트들이나 그 모듈화된 표현들 같은 정보 전달 심볼들로 이뤄진 데이터 스트림의 논리 유닛들 또는 물리 유닛들을 나타낼 수 있다. 예를 들어, 상기 데이터 스트림은 상기 서버로부터 상기 클라이언트로, 적어도 부분적으로 실시간 트랜스포트 프로토콜 RTP에 기반하는 스트리밍 세션 중에 전송된 미디어 스트림일 수 있고, 그에 대응하여 상기 서버는 콘텐츠 또는 스트리밍 미디어 서버일 수 있고, 상기 클라이언트는 스트리밍 클라이언트일 수 있으며, 상기 데이터 패킷들은 RTP 패킷들일 수 있다. 상기 스트리밍은 이때 유니 캐스트 (uni-cast)나 멀티 캐스트 (multi-cast)로 수행될 수 있다. 보다 일반적인 의미에서, 상기 서버와 클라이언트는 데이터 전송 시스템 내 전송기 및 수신기로서 파악될 수도 있다. 상기 데이터 패킷들의 상기 전송은 프로토콜들에 의해 지원 및/또는 통제되는 물리적이거나 논리적 전송일 수 있다. 물리적 전송 매체는 무선이거나 유선을 기반으로 할 수 있고, 아니면 유선과 무선 둘 모두를 기반으로 하는 세그먼트들로 이뤄질 수 있다. 상기 데이터 패킷들의 상기 전송은 제1비트 레이트로 이뤄지며, 이것은 논리적이거나 물리적 전송을 말하는 것일 수 있다. 이를테면, 그 비트 레이트가 상기 데이터 패킷들의 콘텐츠에 대해 수행된 채널 코딩 및/또는 소스 양에 따라 정해지거나, 상기 데이터 패킷들의 전송에 사용된 베어러들이나 전송 채널들의 개수 및/또는 전송 용량에 의해 정해질 수 있다.

상기 서버에서, 상기 클라이언트로 전송된 적어도 한 데이터 패킷이 서버 버퍼에 적어도 일시적으로 저장된다. 이 버퍼는, 클라이언트에서 올바르게 수신되지 않은 데이터 패킷들이, 가령 자동 반복 요청 ARQ 프로토콜의 통제하에서나 실시간 트랜스포트 제어 프로토콜 RTCP 서비스들에 기반하여, 새로 전송될 재전송 버퍼를 나타낸다. 상기 적어도 한 데이터 패킷을 상기 서버 버퍼에 저장하는 것은 시간 제한되어, 상기 적어도 한 패킷이 소정 시간 또는 동적 조정 시간 후에 상기 서버 버퍼로부터 나오도록 한다.

상기 클라이언트에서, 상기 클라이언트로 전송 및 수신된 적어도 한 데이터 패킷이, 상기 클라이언트 버퍼에 적어도 일시적으로 저장된다. 상기 클라이언트 버퍼로부터, 저장된 데이터 패킷들이 상기 클라이언트에서의 추가 처리에 사용될 수 있다, 가령, 상기 클라이언트 버퍼로부터의 상기 데이터 패킷들은 어떤 어플리케이션을 통해 재생될 수 있다. 상기 클라이언트 버퍼는, 서버와 클라이언트 사이의 물리적 및 논리적 전송 매체의 전송 특성 (가령, 지연, 손실)로 인해, 데이터 패킷들이 상기 클라이언트 버퍼에 도달시 가진 레이트가 변경될 수 있게 하는 보상(compensation) 버퍼로서의 역할을 할 수 있다.

상기 클라이언트는 상기 서버에 손상 정보를 신호하는데, 이때 상기 손상 정보는 상기 서버로부터 상기 클라이언트로의 전송 중의 적어도 한 데이터 패킷의 손상과 관련된 것이다. 예를 들어, 상기 손상은 한 개 혹은 여러 개의 데이터 패킷들의 손실 또는 훼손을 나타낼 수 있다 손상 정보의 예가, 올바로 수신되었던 최종 데이터 패킷의 시퀀스 넘버 등의 식별정보의 시그날링일 수 있다. 상기 데이터 패킷 전송 서버는 상기 손상 정보로부터, 특히 소정 시간이 흘렀을 때, 한 개 혹은 여러 개의 패킷들이 상기 수신기에서 올바로 수신되지 않았는지를 알아낼 수 있고, 그리하여 데이터 패킷들을 재전송하고자 시도할 수 있다. 상기 시그날링은 가령 실시간 트랜스포트 제어 프로토콜 같은 프로토콜에 기반해 수행될 수 있다. 상기 손상 정보에 기반해, 상기 서버는 이미 전송되었지만 손상되거나 손실된 데이터 패킷들에 대한 재전송이 요망되는지를 판단할 수 있고, 그에 따라 상기 서버 버퍼로부터 가져다가 상기 클라이언트로 새로 전송할 수 있다.

상기 클라이언트는 상기 클라이언트 버퍼의 상태와 관련이 있는 클라이언트 버퍼 정보를 상기 서버로 더 신호한다. 이 클라이언트 버퍼 정보는 가령 클라이언트 버퍼에 남은 공간에 대한 것이거나, 상기 클라이언트 버퍼에 저장된 특정 데이터 패킷의 시퀀스 넘버, 특히 상기 클라이언트 버퍼에 저장된 가장 오래된 데이터 패킷, 즉 추가로 처리하기 위해 상기 클라이언트 버퍼로부터 아직 읽혀지지 않았고 그 저장 시간이 상기 클라이언트 버퍼에 저장된 모든 데이터 패킷들 중에 가장 오래된 데이터 패킷의 시퀀스 넘버를 나타낼 수 있다. 이와 상응하여, 상기 가장 오래된 데이터 패킷은, 추가 처리를 위해 상기 클라이언트로부터 읽혀질 바로 다음 데이터 패킷이다.

상기 신호된 클라이언트 버퍼 정보에 기반하여, 상기 서버는 상기 제1비트 레이트를 제2비트 레이트로 변경한다. 이 패킷화된 데이터 비트 레이트조정 단계는, 이를테면, 상기 클라이언트 버퍼의 오버플로나 언더플로를 피하기 위해 필요로 될 수 있고, 상기 데이터 패킷들의 콘텐츠에 대해 수행된 채널 코딩 및/또는 소스 의 양에 대한 변경, 및/또는 상기 데이터 패킷들의 전송에 사용된 베어러들이나 전송 채널들의 개수 및/또는 전송 용량의 변경을 요할 수 있다.

본 발명의 제1양태에 따르면, 상기 제1비트 레이트로 전송되어 상기 서버 버퍼에 저장된 적어도 한 데이터 패킷은, 상기 제2비트 레이트로서 상기 데이터 패킷들을 상기 서버로부터 상기 클라이언트로 전송 시작할 때, 상기 서버 버퍼에 더 저장된다. 따라서, 비트 레이트가 변경될 때, 제1비트 레이트로 전송된 데이터 패킷들을 포함한 서버 버퍼는, 종래의 시스템들에서처럼, 모두 비워지지 않는다. 반대로, 제1비트 레이트로 전송되어 저장된 데이터 패킷들이 상기 서버 버퍼 안에 유지되고, 이를테면, 신호된 손상 정보에 좌우될 수 있는 시간 듀레이션(duration) 뒤에만 상기 서버 버퍼로부터 삭제된다. 이것이, 제1비트 레이트로 전송되었던 데이터 패킷들이 성공적으로 완료될 수 있도록 요청되는 한, 제2비트 레이트로의 데이터 패킷 전송이 이미 시작되었을 때에도, 그 데이터 패킷 재전송을 가능하게 한다. 종래 기술과는 달리, 본 발명에 따르면, 제1비트 레이트로 전송되어 훼손되거나 손실된 데이터 패킷이, 제1비트 레이트로부터 제2비트 레이트로의 패킷화 데이터 비트 레이트 조정시 상기 서버 버퍼의 비우기(flushing)로 인해 서버 버퍼에서 재전송에 이용될 수 없는 경우가 더 이상 발생되지 않으므로, 상기 데이터 패킷들에 의해 부양되는 어플리케이션들의 지연 또는 오류를 막을 수 있다.

본 발명의 제1양태에 대한 바람직한 실시예에 따르면, 상기 제1비트 레이트로 전송되어 상기 서버 버퍼에 저장된 상기 적어도 한 데이터 패킷은 상기 신호된 손상 정보에 기초해 상기 서버에서 정한 시간의 듀레이션 동안 상기 서버 버퍼에 저장된다. 이것은, 상기 서버 버퍼 내 데이터 패킷들에 만기(expiration) 시간을 할당함으로써 이뤄질 수 있다.

본 발명의 제1양태에 대한 바람직한 실시예에 따르면, 상기 제1비트 레이트로 전송되어 상기 서버 버퍼에 저장된 상기 적어도 한 데이터 패킷을 상기 서버 버퍼로부터 제거하는 것은, 상기 신호된 클라이언트 버퍼 정보에 좌우된다. 상기 적어도 한 데이터 패킷은, 가령 상기 클라이언트 버퍼 정보로부터 상기 데이터 패킷의 재전송이 더 이상 필요하지 않거나 유용하지 않다고 판단되는 경우 상기 서버 버퍼로부터 제거될 수 있다.

본 발명의 제1양태에 대한 바람직한 실시예에 따르면, 상기 클라이언트 버퍼 정보는 상기 클라이언트 버퍼에 저장된 가장 오래된 데이터 패킷의 식별정보를 말한다. 상기 오래되었다는 용어는, 상기 데이터 패킷이 클라이언트 버퍼에 저장되었을 때의 시점과 관련된 것이라고 이해되어야 한다. 상기 식별정보는 가령 상기 가장 오래된 데이터 패킷의 시퀀스 넘버일 수 있다.

본 발명의 제1양태에 대한 바람직한 실시예에 따르면, 상기 서버로부터 상기 클라이언트로 상기 데이터 패킷들을 전송하는 것은, 적어도 부분적으로 실시간 트랜스포트 프로토콜, RTP에 기반하고, 상기 손상 정보 및 상기 클라이언트 버퍼 정보에 대해 상기 신호한다(시그날링)는 것은, 적어도 부분적으로 실시간 트랜스포트 제어 프로토콜 RTCP에 기반한다. 따라서 상기 데이터 패킷들은 RTP 패킷들이며, 상기 클라이언트 버퍼 정보, 가령 가장 오래된 버퍼링 시퀀스 넘버 OBSN이 RTCP 어플리케이션 APP 패킷들을 이용해 신호될 수 있다.

본 발명의 제1양태에 대한 바람직한 실시예에 따르면, 상기 데이터 패킷들은 3GPP 패킷 교환형 스트리밍 서비스 PSS에 따라 상기 서버로부터 상기 클라이언트로 전송된 미디어 스트림과 관련이 있다.

본 발명의 제1양태에 따르면, 패킷화 데이터 비트 레이트 조정과 데이터 패킷 재전송 사이의 협력을 증진하기 위한 시스템, 클라이언트, 및 서버가 더 제안된다.

본 발명의 제2양태에 따라, 패킷화(된) 데이터 비트 레이트 조정 및 데이터 패킷 재전송 간 협력을 향상시키는 방법이 더 제안되고, 이 방법은 서버로부터 클라이언트로 제1비트 레이트로서 데이터 패킷들을 전송하는 단계; 상기 전송된 데이터 패킷들 중 적어도 한 개를 적어도 한 서버 버퍼에 적어도 일시적으로 저장하는 단계; 상기 전송된 데이터 패킷들 중 적어도 하나를 클라이언트 버퍼에 적어도 일시적으로 저장하는 단계; 상기 서버로의 상기 전송 중에 상기 전송된 데이터 패킷들 중 적어도 하나의 손상과 관련된 손상 정보를 신호하는 단계; 상기 클라이언트 버퍼의 상태와 관련된 클라이언트 버퍼 정보를 상기 서버로 신호하고, 상기 신호된 클라이언트 상태 정보는 상기 서버에 의해 해석되어, 상기 패킷들 전송의 제1비트 레이트를 제2비트 레이트로 변경하도록 하는 단계; 상기 신호된 손상 정보 및 상기 신호된 클라이언트 버퍼 상태 정보에 기반하여, 데이터 패킷 재전송이 요구되는지를 판단하는 단계; 및 데이터 패킷 재전송이 요구된다고 판단된 경우에만, 상기 서버로부터 상기 클라이언트로, 상기 서버 버퍼에 저장된 적어도 한 데이터 패킷을 재전송하는 단계를 포함한다.

상기 서버에서, 상기 클라이언트로 전송된 적어도 한 데이터 패킷이 서버 버퍼에 적어도 일시적으로 저장된다. 이 버퍼는, 클라이언트에서 올바르게 수신되지 않은 데이터 패킷들이, 가령 자동 반복 요청 ARQ 프로토콜의 통제하에서나 실시간 트랜스포트 제어 프로토콜 RTCP 서비스들에 기반하여, 새로 전송될 수 있는 재전송 버퍼를 나타낸다. 상기 적어도 한 데이터 패킷의 상기 서버 버퍼 내 저장은 시간 제한된 것으로서, 상기 적어도 한 패킷은 소정 시간 또는 동적 조정 시간 후에 상기 서버 버퍼로부터 나오게 된다.

상기 클라이언트에서, 상기 클라이언트로 전송 및 수신된 적어도 한 데이터 패킷이, 상기 클라이언트 버퍼에 적어도 일시적으로 저장된다. 상기 클라이언트 버퍼로부터, 저장된 데이터 패킷들이 상기 클라이언트에서의 추가 처리에 사용될 수 있다, 가령, 상기 클라이언트 버퍼로부터의 상기 데이터 패킷들은 어떤 어플리케이션을 통해 재생될 수 있다. 상기 클라이언트 버퍼는, 서버와 클라이언트 사이의 물리적 및 논리적 전송 매체의 전송 특성 (가령, 지연, 손실)으로 인해, 데이터 패킷들이 상기 클라이언트 버퍼에 도달시 가진 레이트가 변경될 수 있게 하는 보상(compensation) 버퍼로서의 역할을 할 수 있다.

상기 클라이언트는 상기 서버에 손상 정보를 신호하는데, 이때 상기 손상 정보는 상기 서버로부터 상기 클라이언트로의 전송 중의 적어도 한 데이터 패킷의 손상과 관련된 것이다. 예를 들어, 상기 손상은 한 개 혹은 여러 개의 데이터 패킷들의 손실 또는 훼손을 나타낼 수 있다 손상 정보의 예가, 올바로 수신되었던 최종 데이터 패킷의 시퀀스 넘버 등의 식별정보의 시그날링일 수 있다. 상기 데이터 패킷 전송 서버는 상기 손상 정보로부터, 특히 소정 시간이 흘렀을 때, 한 개 혹은 여러 개의 패킷들이 상기 수신기에서 올바로 수신되지 않았는지를 알아낼 수 있고, 그리하여 데이터 패킷들을 재전송하고자 시도할 수 있다. 상기 시그날링은 가령 실시간 트랜스포트 제어 프로토콜 RTCP 같은 프로토콜에 기반해 수행될 수 있다.

상기 신호된 클라이언트 버퍼 정보에 기반하여, 상기 서버는 상기 제1비트 레이트를 제2비트 레이트로 변경한다. 이 패킷화된 데이터 비트 레이트 조정 단계는, 이를테면, 상기 클라이언트 버퍼의 오버플로나 언더플로를 피하기 위해 필요로 될 수 있고, 상기 데이터 패킷들의 콘텐츠에 대해 수행된 채널 코딩 및/또는 소스의 양에 대한 변경, 및/또는 상기 데이터 패킷들의 전송에 사용된 베어러들이나 전송 채널들의 개수 및/또는 전송 용량의 변경을 요할 수 있다.

본 발명의 제2양태에 따르면, 상기 서버 버퍼에 저장된 적어도 한 데이터 패킷을 서버로부터 상기 클라이언트로 재전송하는 것은, 데이터 패킷 재전송이 요구된다고 판단되는 경우에만 수행되며, 이때 그 판단은 상기 신호된 손상 정보 및 상기 신호된 클라이언트 버퍼 상태 정보에 기반한다. 재전송에 대한 그 판단이, 신 호된 손상 정보에만 기반하는 종래 기술과는 달리, 본 발명의 제2양태에 따르면, 신호된 클라이언트 버퍼 상태 정보 또한 그 결정시에 고려된다. 상기 손상 정보가 소정 데이터 패킷들이 재전송될 필요가 있다는 것을 나타내는 경우, 상기 클라이언트 버퍼 정보는 그럼에도 불구하고, 이미 상기 클라이언트 버퍼에 그 특정 데이터 패킷이 저장되어 있거나 이미 저장되어서 소정 시간 전에 처리되었거나, 성공적 재전송의 경우라도 상기 클라이언트에서 유용하게 쓰기에는 너무 늦게 도달할 것이라는 이유 등으로, 이 특정 데이터 패킷이 재전송을 필요로 하지 않는다고 가리킬 수 있다. 따라서, 본 발명의 제2양태에 따르면, 종래의 시스템들에서 일어나던 불필요한 데이터 패킷들의 재전송들과 패킷화된 데이터 비트 레이트 조정을 완벽하게 피할 수 있다.

본 발명의 제2양태에 대한 바람직한 실시예에 따르면, 상기 손상 정보는 상기 전송 중에 손상된 적어도 한 데이터 패킷의 시퀀스 넘버를 판단할 수 있게 하며, 상기 클라이언트 버퍼 정보는 상기 클라이언트 버퍼에 저장된 가장 오래된 데이터 패킷의 시퀀스 넘버를 말하며, 상기 데이터 패킷 재전송이 요구되는지를 판단하는 단계는 상기 적어도 한 개의 손상된 데이터 패킷의 상기 시퀀스 넘버와 상기 가장 오래된 데이터 패킷의 시퀀스 넘버 사이의 차에 좌우된다. 따라서, 시간에 따라 증가하는 데이터 패킷들의 시퀀스 넘버들에 대해, 상기 가장 오래된 데이터 패킷보다 덜 오래된 데이터 패킷들만 재전송 되게 요구함으로써 불필요한 재전송을 피할 수 있게 되고, 상기 손상된 데이터 패킷의 재전송을 위해서는 상기 손상된 데이터 패킷과 상기 가장 오래된 데이터 패킷의 시퀀스 넘버 차이가 0 보다 커야 한 다는 요구를 낳는다.

본 발명의 제2양태에 대한 바람직한 실시예에 따르면, 상기 서버 버퍼에 저장된 데이터 패킷들은, 이들과 결부된 시퀀스 넘버들 및 상기 가장 오래된 데이터 패킷의 시퀀스 넘버의 차이에 따라 다르게 제거된다. 가령, 상기 가장 오래된 데이터 패킷보다 작은 시퀀스 넘버를 가진 것들, 즉, 상기 클라이언트 버퍼에서 상기 가장 오래된 데이터 패킷보다 오래된 모든 데이터 패킷들을 제거하는 것이 바람직할 것이다. 따라서, 상기 데이터 패킷들은 상기 차가 0 보다 작을 때 제거된다.

본 발명의 제2양태에 대한 바람직한 실시예에 따르면, 상기 서버로부터 상기 클라이언트로 상기 데이터 패킷들을 전송하는 것은, 적어도 부분적으로 실시간 트랜스포트 프로토콜, RTP에 기반하고, 상기 손상 정보 및 상기 클라이언트 버퍼 정보에 대해 상기 신호(시그날링)하는 것은, 적어도 부분적으로 실시간 트랜스포트 제어 프로토콜 RTCP에 기반한다. 따라서 상기 데이터 패킷들은 RTP 패킷들이며, 상기 클라이언트 버퍼 정보, 가령 가장 오래된 버퍼링 시퀀스 넘버 OBSN이 RTCP 어플리케이션 APP 패킷들을 이용해 신호될 수 있다.

본 발명의 제2양태에 대한 바람직한 실시예에 따르면, 상기 데이터 패킷들은 3GPP 패킷 교환형 스트리밍 서비스 PSS에 따라 상기 서버로부터 상기 클라이언트로 전송된 미디어 스트림과 관련이 있다.

본 발명의 제2양태에 따르면, 패킷화 데이터 비트 레이트 조정 및 데이터 패킷 재전송 사이의 협력을 증진시키기 위한 시스템, 클라이언트 및 서버가 더 제안된다.

본 발명에 따르면, 상술한 방법의 단계들 중 어느 하나를 프로세서로 하여금 수행할 수 있게 작동되는 명령어들을 가진 컴퓨터 프로그램이 더 제안된다.

상술한 방법의 단계들 중 어느 한 가지를 프로세서로 하여금 수행할 수 있게 작동되는 명령어들을 가진 컴퓨터 프로그램을 구비한 컴퓨터 프로그램 제품이 더 제안된다.

본 발명의 이러한 양태들 및 기타 양태들은, 이제부터 설명될 실시예들을 참조할 때 더 명확히 설명될 수 있다.

본 발명은, 패킷화(된) 데이터 비트 레이트 변경시 서버가 자신의 재전송 버퍼들을 다 비워 버리지 (flush) 말 것과, 데이터 패킷들은 클라이언트로부터 피드백 된 클라이언트 버퍼 정보가 이 재전송 패킷이 실제로 필요로 된다는 것을 가리킬 때에만 재전송될 것을 요구함으로써, 패킷화 데이터 비트 레이트 조정 및 데이터 패킷 재전송 사이의 협력을 증진시키는 것을 제안하고 있다. 이하에서, 본 발명의 전형적 실시예들이 제3세대 공동 프로젝트 (3GPP) 패킷 교환형 스트리밍 서비스 (PSS)의 상황하에서 주어질 것이다. 그러나, 본 발명이 PSS의 어플리케이션에만 결코 한정되는 것이 아니고, 패킷화 데이터 비트 레이트 조정과 데이터 패킷 재전송이 맞물려 구현되는 모든 종류의 통신 시스템들에서 똑같이 적용될 수 있다는 것을 알아야 한다.

도 2는 본 발명에 따른, 패킷화 데이터 비트 레이트 조정 및 데이터 패킷 재전송 사이의 협력을 증진시키기 위한 전형적 시스템(20)의 기본 구성요소들을 도시 하고 있다. 이 시스템은 서버(21)와 클라이언트(22)를 구비하며, 스트리밍 세션 중 상기 서버(21)로부터 상기 클라이언트(22)로 RTP 데이터 패킷들이 스트리밍된다. 그러한 스트리밍 세션의 예가, 가령, 인터넷 서버로부터 모바일 전화기로의 비디오 다운로드가 될 수 있으며, 이때 상기 비디오 스트림은 다운로드 프로세스와 동시에 상기 모바일 전화기 상에서 재생된다.

상기 서버(21)는 가령 상기 서버(21) 안에 위치할 수도 있는 콘텐츠 서버나 어떤 다른 종류의 스토리지 매체로부터 데이터 스트림을 수신하고, 인코더 인스턴스(210)에서 상기 데이터 스트림을 실시간 트랜스포트 프로토콜 (RTP) 패킷들로 부호화한다. 이러한 인코딩은, 가령 서로 다른 비트 레이트들을 가진 비트 스트림들인 데이터 스트림들 사이의 스위칭을 포함한다. RTP 패킷들은 이제 전송 인스턴스(211)로 보내지고, 전송 인스턴스는 상기 RTP 패킷들을 전송 채널을 거쳐 상기 클라이언트(22) 내 수신기 인스턴스(225)로 전송하는 동작을 수행한다. 이러한 전송은 논리적으로 파악되어야 한다, 즉, RTP 데이터 패킷들은 서버(21)와 클라이언트(22) 사이의 물리적 전송을 수행하는 하위 프로토콜 계층들로 넘겨짐으로써, 실제로 전송된다. 따라서 상기 전송 인스턴스(211)는 상기 클라이언트(22) 내 대등 개체 (peer entity)와 통신하는 RTP 개체 등을 나타낸다. 전송된 rTP 패킷들은 전송 인스턴스(211)에 의해 비트 레이트 고유의 재전송 버퍼들 (214-1, ..214-3)에 저장되며, 이들은 각자 입출력 (I/O) 인터페이스 (213-1,..,213-3)를 통해 전송 인스턴스(211)와 액세스될 수 있다. 이러한 도 2의 예에서는 세 가지 서로 다른 비트 레이트들이 지원되고 있으며, 실제로 자신들의 시퀀스 넘버들 (SN)로 구별되는 7 개의 데이터 패킷들이 상기 서버(21)로부터 상기 클라이언트(22)로 전송되어 그에 따라 상기 비트 레이트 고유의 재전송 버퍼들 (214-1,..,214-3)에 저장된다. RTP 패킷들 (SN=1 및 SN=2)이 최고 비트 레이트로 전송되어 재전송 버퍼(214-3)에 저장되었다. 그리고 나서 상기 최고 비 트레이트로부터 보다 낮은 비트 레이트로의 비트 레이트 변경이 일어났고, 그 비트 레이트로 RTP 패킷들 (SN=3, SN=4, 및 SN=5)이 전송되어 전송 버퍼(214-2)에 저장되었다. 훨씬 더 낮은 비트 레이트로의 추가 변경 뒤에, RTP 패킷들 (SN=6 및 SN=7)이 전송되어 재전송 버퍼(214-1)에 저장되엇다. 상기 비트 레이트들의 변경 동작은, 비트 레이트 조정/재전송 제어 인스턴스(212)가 클라이언트 버퍼 정보, 이 예에서 클라이언트(22)로부터 RTCP APP 패킷들로서 신호된 가장 오래된 버퍼링 시퀀스 넘버 (OBSN)에 응하여 개시한다. 이러한 OBSN, 클라이언트 버퍼 사이즈 (이를테면 세션 설정 중에 신호 됨), 및 가장 높은 수신 시퀀스 넘버 (HRSN, RTCP 수신기 보고서들을 통해 신호 됨)에 기반하여, 비트 레이트 조정/재전송 제어 인스턴스(212)는 오버플로우 및/또는 언더플로를 피할 수 있도록 클라이언트 버퍼(224)를 원격으로 제어한다. 상기 비트 레이트 조정/재전송 제어 인스턴스(212)는, 가령 인코더에 명령해 각각 서로 다른 비트 레이트들을 가진 서로 다른 비트 스트림들 사이에서 스위칭하도록 하는 등의 동작에 의해 비트 레이트를 변경하도록 상기 인코더(210)를 제어한다. 상기 비트 레이트 조정/재전송 제어 인스턴스(212)는 도, 상기 I/O 인터페이스 (213-1,..,213-3)를 제어하여 서로 다른 비트 레이트들을 통한 RTP 패킷들이 올바른 재전송 버퍼들(214-1,..214-3)에 반드시 저장될 수 있게 한다. 또, 상기 클라이언트(22)로부 터의 손상(impairment) 정보에 따라 상기 비트 레이트 조정/재전송 제어 인스턴스(212)에 의해 판단시 상기 재전송 버퍼들(214-1,..,214-3)에 저장된 RTP 패킷들의 재전송이 요구되면, 상기 비트 레이트 조정/재전송 제어 인스턴스(212)가 재전송 버퍼들(214-1,..214-3)로부터 전송 인스턴스(211)RK지의 해당 RTP 패킷들의 이동 역시 제어한다. 상기 손상 정보, 즉, 이 예에 따르면 손실된 RTP 패킷들에 대한 정보가 상기 클라이언트(225)로부터 수신 인스턴스(215)에 의해 클라이언트 버퍼 정보와 유사하게 수신된다. 상기 전송 인스턴스(211)처럼, 상기 수신 인스턴스(215) 역시 논리적으로 파악되어야 한다, 즉, 클라이언트 버퍼 정보 및 손상 정보가 RTCP를 통해 신호 될 수 있고, 그러면 상기 수신 인스턴스(215)가 상기 클라이언트(22) 내 대등 개체(221)와 통신하는 RTCP 개체를 나타낸다.

상기 클라이언트(22)는 상기 서버(21)로부터 전송된 RTP 패킷들을, 가령 RTP 개체일 수 있는 수신 인스턴스(225)를 통해 수신한다. 상기 개체(225)에서, 가령 간단한 첵섬(checksum)을 통해 RTP 패킷들이 손상되었는지 (가령, 훼손되었는지) 아닌지의 여부가 체크된다. 상기 RTP 패킷들이 손상되지 않았으면, 이들은 I/O 인터페이스(223)를 거쳐 클라이언트 버퍼(224) 안에 저장된다. 상기 클라이언트(22) 내 비트 레이트 조정/재전송 제어 인스턴스(222)가 상기 수신 인스턴스(225)로부터 손상된 RTP 패킷들에 대한 정보, 가령, 올바로 수신된 마지막 데이터 패킷의 SN과, 상기 클라이언트 버퍼(224)로부터 클라이언트 버퍼 상태 정보, 가령 HRSN 및 OBSN의 실제값들을 수신한다. 상기 비트 레이트 조정/재전송 제어 인스턴스(222)는 상기 손상 정보 및 상기 클라이언트 버퍼 정보를 역시 프로토콜 개체로서 파악될 수 있는 전송 인스턴스(221)를 통해 상기 서버(21)로 피드백되게 만든다. 또, 상기 비트 레이트 조정/재전송 제어 인스턴스(222)는 I/O 인터페이스(223)를 제어하여 상기 클라이언트 버퍼(224)로부터 디코더 인스턴스(220)로의 RTP 패킷 전달이 일어나게 하며, 디코더 인스턴스(220)에서 RTP 패킷들은 서로 다른 비트 레이트들을 갖는 데이터 스트림들 (가령, 비트 스트림들)로 다시 복호화된다. 이 예에서, 상기 클라이언트 버퍼 내 OBSN은 OBSN=3이고, 상기 클라이언트 버퍼는 RTP 패킷(SN=4)을 더 포함한다. 따라서 RTP 패킷들 (SN=1 및 SN=2)은 이미 수신되어, 상기 클라이언트 버퍼(224)에 저장되었다가 상기 클라이언트 버퍼(224)로부터 읽혀져 나가 재생을 위해 상기 디코더(220)에 의해 복호화 되었다. 그러나, RTP 패킷들 (SN=5, SN=6, 및 SN=7)은, 재전송 버퍼(214-1)에서의 이들의 저장을 통해 알 수 있는 것처럼 이미 서버(21)를 통해 전송은 되었으나 아직 상기 클라이언트 버퍼(224)에 저장되지 않고 있다.

이제, RTP 패킷 (SN=5)이 서버(21)로부터 클라이언트(22)로의 전송 도중에 훼손되었거나 손실된 경우를 고려할 것이다. 이러한 훼손 또는 손실과 관련된 정보가 상기 클라이언트(22)의 상기 비트 레이트 조정/재전송 제어 인스턴스(22)에 의해 서버(21)의 비트 레이트 조정/재전송 제어 인스턴스(212)로 신호 되어, RTP 패킷 (SN=5)의 재전송을 일으키게 만들 것이다. 이러한 RTP 패킷 (SN=5)의 재전송은, 이 RTP 패킷 (SN=5)이 여전해 재전송 버퍼(214-1,..,214-3)에 저장되어 있을 것을 요구한다. 그러나, RTP 패킷들 (SN=3, SN=4, 및 SN=5)은 중간 비트 레이트로 전송되었고, 이들의 전송 후 RTP 패킷들 (SN=6 및 SN=7)의 전송을 위해 더 낮은 비 트 레이트로의 변경이 일어났다는 것을 알아야 한다. 종래 기술에 따르면, 그러한 변경은 일반적으로 재전송 버퍼들 (214-1,..,214-3)이 다 비워지게 한다. 즉, 그 안에 저장된 모든 RTP 패킷들이 즉각적으로 삭제되게 된다. 이러한 종래의 방식은 이런 경우 문제가 생기는데, 그 이유는 모든 재전송 버퍼들 (214-1,..,214-3)의 전부 비우기 (flushing)에 의해, 지금 재전송하라고 요구된 RTP 패킷 (SN=5)을 포함했던 재전송 버퍼(214-2) 역시 비워져서, 서버(21)가 이 RTP 패킷을 재전송하는 것을 거부하게 만들거나, 서버가 이 RTP 패킷을, 새로운 인코딩 등을 포함할 수도 있는 어떤 콘텐츠 서버로부터 다시 획득할 때까지 지연을 야기하기 때문이다. 따라서 본 발명은 그 제1양태에 따라, 재전송 버퍼들 (214-1,..,214-3)이 비트 레이트 변경시 즉시 비워지지 않고, 이들의 RTP 패킷들을 더 보관할 것을 주문한다. 따라서 본 발명에 따르면, RTP 패킷(SN=5)이 전송되었던 비트 레이트가 RTP 패킷들 (SN=6 및 SN=7)이 전송되었던 비트 레이트로 변경되었더라도, RTP 패킷 (SN=5)이 재전송 버퍼(214-2)에 들어 있게 될 것이다.

본 발명의 제1양태는, 따라서, 비트 레이트 조정과 재전송 사이의 협력을 증진시킨다. 이것은 서버 측에서 쉽게 구현되며, 클라이언트 측에서의 어떠한 변경도 요구하지 않을 수 있다. 시스템의 최적성 레벨에 따라, 비트 레이트 변경 후 서버가 자신의 재전송 버퍼들을 모두 비우지 못하게 요구될 수 있다. 가령 RTCP 피드백 보고서들이나 OBSN으로부터 알 수 있는, RTP 패킷들의 만기 날짜가 지나면, 서버는 자신의 재전송 버퍼들 (214,..,214-3)로부터 싱글 RTP 패킷들을 제거할 수 있게 될 것이다.

이제, 전송 중에 RTP 패킷 (SN=3)이 훼손된 경우를 고려한다. 종래의 시스템에서 이런 경우는, RTP 패킷 (SN=3) 재전송을 불러 일으킬 것이다 (RTP 패킷 (SN=3)이 아직 서버의 재전송 버퍼들(214-1,..,214-3)에 저장되어 있다고 전제하고, 본 발명의 제1양태가 서버(21)에 적용되는지 않는지의 여부와 무관하게, RTP 패킷들 (SN=3, SN=4, 및 SN=5)의 전송 뒤, 재전송 버퍼(214-2)의 다 비우기를 일으켰을 지도 모를 비트 레이트 변경이 일어나지 않았다고 가정한 경우가 될 것이다). 그러나, RTP 패킷 (SN=3)이 이미 클라이언트 버퍼(224)에 올바르게 저장되었음을 가리키는 클라이언트 버퍼(224)의 OBSN=3에 따라, RTP 패킷 (SN=3)의 재전송은 실제 요청되지 않는다. 이러한 상황은 이를테면, 손상 정보의 피드백과 RTP 패킷들의 재전송시의 불가피한 지연과 그에 따른 타임아웃으로 인해, RTP 패킷 (SN=3)의 올바른 버전과 훼손 버전이 서로 다른 순간에 클라이언트(22)에서 수신되는 경우 일어날 수 있다. 다른 예에서, OBSN이, 클라이언트(22)에서 다음에 처리될 (가령 재생될) OBSN과 재전송되어야 할 RTP 패킷의 SN과의 시퀀스 넘버들의 차이가 너무 작다는 것을 나타낼 수 있고, 그러면 상기 RTP 패킷이 성공적으로 재전송될 때에도 클라이언트(22)에서의 그 수신은 너무 늦어질 것이다.

종래 기술에서는, OBSN에 대한 정보가 비트 레이트 조정을 위해서만 고려되고 재전송에 대해서는 고려되지 않고 있다. 따라서, 본 발명의 제2양태에 따르면, RTP 패킷 재전송 전에 손상 정보 (훼손 RTP 패킷들에 관한)와 클라이언트 버퍼 정보 (OBSN 관련)가 모두 고려될 것이 제안된다.

이러한 본 발명의 제2양태 역시 비트 레이트 조정 및 재전송의 협력을 증진 시키게 된다. 또한 이것은 서버 측에서 쉽게 구현되고, 클라이언트 측에서의 변경을 요하지 않을 것이다. 시스템의 최적성 레벨에 따라, 서버가, 클라이언트에 의해 재전송되도록 요구된 패킷들이 이미 클라이언트 버퍼(224)에 저장되어 있거나 클라이언트에서 사용 가치가 없을 정도로 늦게 도달할 것임을 알고 있는 경우, 그 패킷들을 재전송하지 않게 할 것이 요구된다. OBSN은 서버에 의해, 재전송 버퍼들 (214-1,..,214-3)로부터의 OBSN과 같거나 작은 SN들을 가지는 RTP 패킷들을 제거하는데 더 사용될 수도 있으며, 이러한 것은 본 발명의 제1양태가 서버에서 구현될 때 역시 특히 바람직하다.

도 3은 본 발명에 따른, 패킷화 데이터 비트 레이트 조정 및 데이터 패킷 재전송 사이의 협력을 증진시키기 위해 서버에서 수행되는 방법의 단계들로 된 전형적 흐름도를 나타낸 것이다. 최초의 301 단계에서, 서버에서의 비트 레이트가 설정된다. 이 비트 레이트는 가령 서버로부터 클라이언트로, 가령 RTP를 통해 전송될 비트 스트림의 비트 레이트 등이 될 것이다. 이 비트 레이트는 상기 전송을 위해 지정된 디폴트 값 등이 될 수 있고, 이것이 다시 클라이언트 버퍼에서의 버퍼 오버플로나 언더플로 발생이 절대 일어나지 않도록 전송 중에 상기 클라이언트로부터의 피드백에 기반하여 더 정교해질 수 있다. 두 번째 302 단계에서, 데이터 패킷들, 가령, RTP 패킷들이 상기 비트 스트림으로부터 생성되어 303 단계에서 상기 클라이언트로 전송된다. 전송된 데이터 패킷들은 304 단계에서, 상기 설정된 비트 레이트에 따라 비트 레이트 고유의 서버 버퍼들 (재전송 버퍼들) 안에 저장된다. 305 단계에서, 손상 정보, 가령, 재전송 되어야 할, 훼손된 데이터 패킷의 SN이나, 상기 클라이언트에서 올바로 수신했던 마지막 데이터 패킷의 SN이 상기 클랑이언트로부터 가령 RTCP를 경유해, 상기 서버에서 수신된다. 마찬가지로, 306 단계에서 클라이언트 버퍼 정보, 가령 OBSN이 상기 서버에서 수신된다. 상기 손상 및 클라이언트 버퍼 정보 둘 다에 기반하여, 307 단계에서, 데이터 패킷들의 재전송이 실제로 요구되는지 아닌지가 판단된다. 요구된다고 판단되는 경우, 308 단계에서, 데이터 패킷들의 재전송이 수행된다. 요구되지 않는다고 판단되는 경우, 혹은 재전송 이후에, 309 단계에서, 비트 레이트 변경이 필요한지 여부가 체크된다. 이것은 적어도 부분적으로는 306 단계에서 수신된 클라이언트 버퍼 정보, 가령 OBSN에 기반하며, 그 외에 클라이언트 버퍼 사이즈 및 HRSN에 대한 정보가 더 상기 체크시에 활용될 수 있다. 클라이언트의 버퍼에서의 오버플로나 언더플로를 방지하기 위해 비트 레이트 변경이 필요하다고 판단되면, 310 단계에서 비트 레이트가 변경된다. 이 단계 다음에, 혹은 어떠한 변경도 필요하지 않다고 판단되면, 패킷들의 만기 시간이 지났거나 306 단계에서 수신된 클라이언트 버퍼 정보가 이들 데이터 패킷들의 재전송이 더 이상 유용하지 않다고 알려왔다는 등의 이유로, 311 단계에서 어떤 패킷들이 비트 레이트 고유의 서버 버퍼로부터 제거될 것인가를 더 체크한다. 데이터 패킷들이 제거되기로 정해지면, 그 제거가 312 단계에서 수행된다. 그런 다음, 혹은 아무 제거동작도 일어나지 않은 경우, 이 방법은 다시 302 단계로 돌아가서 클라이언트로 전송될 다른 데이터 패킷들을 더 생성한다.

도 4는 본 발명에 따라 패킷화 데이터 비트 레이트 조정 및 데이터 패킷 재전송 사이의 협력을 증진하도록 클라이언트에서 수행되는 방법의 단계들로 이뤄진 전형적 흐름도를 나타낸다. 최초의 401 단계에서, 데이터 패킷들, 가령 RTP 패킷들이 클라이언트에서 수신된다. 402 단계에서, 가령 첵섬이나 다른 에러 검출 코드를 처리하거나 수신된 패킷들의 시퀀스에 누락된 SN이 있는지 여부를 체크함으로써, 데이터 패킷들이 올바로 수신되었는지, 훼손되거나 손실되었는지가 체크된다. 수신이 올바로 이뤄졌다고 판단되면, 403 단계에서 그 데이터 패킷들이 클라이언트 버퍼에 저장된다. 그렇지 않으면, 404 단계에서, 이 데이터 패킷들을 전송했던 서버로 손상 정보가 신호 된다. 이와 다른 선택사항으로서, 상기 클라이언트에서 올바로 수신된 마지막 데이터 패킷의 SN 같은 손상 정보가, 그 데이터 패킷이 402 단계에서 올바로 수신되었다고 판단되었는지 아닌지 여부와 무관하게 상기 서버로 신호 될 수 있다. 405 단계에서, 이제 OBSN 같은 클라이언트 버퍼 정보가 클라이언트 버퍼로부터 정해지고, 406 단계에서 서버로 신호 된다. 그런 다음, 407 단계에서, 이 데이터 패킷들이 클라이언트 버퍼로부터 불려져서 다시 복호화 또는 재생되는 등 추가 처리된다. 마지막으로, 이 방법은 401 단계로 다시 돌아가, 다른 데이터의 수신이 이뤄진다.

본 발명은 위에서 바람직한 실시예들을 이용해 설명되었다. 이 분야의 당업자에게는 첨부된 청구항들의 범위와 개념에서 이탈하지 않고 구현될 수 있는 대체 방법이 존재하거나 변경이 이뤄질 수 있다는 것이 자명할 것이다. 특히, 본 발명은 3GPP PSS 구성에만 한정되는 것이 아니라, 비트 레이트 조정 및 재전송을 활용하는 모든 타입의 유무선 기반 통신 시스템들에도 동등하게 적용될 수 있다.

도 1: 종래 기술에 따른 패킷 교환형 스트리밍 서비스 (PSS) 프로토콜 스택의 개략도이다;

도2: 본 발명에 따른, 패킷화(된) 데이터 비트 레이트 조정 및 데이터 패킷 재전송 간 협력을 증진시키기 위한 전형적 시스템의 기본 구성요소들이다;

도 3: 본 발명에 따른, 패킷화 데이터 비트 레이트 조정 및 데이터 패킷 재전송 간 협력을 증진시키기 위해 서버에서 수행되는 방법의 단계들로 이뤄진 전형적 흐름도이다;

도 4: 본 발명에 따른, 패킷화(된) 데이터 비트 레이트 조정 및 데이터 패킷 재전송 간 협력을 증진시키기 위해 클라이언트에서 수행되는 방법의 단계들로 이뤄진 전형적 흐름도이다.

Claims

- 서버로부터 클라이언트로 제1비트 레이트를 가지는 제1 비트 스트림의 데이터 패킷들을 전송하는 단계로서, 상기 전송된 데이터 패킷들 중의 적어도 하나는 클라이언트 버퍼 내에 적어도 일시적으로 저장되는, 전송 단계;

- 상기 클라이언트 버퍼의 상태와 관련된 클라이언트 버퍼 정보를 상기 클라이언트로부터 수신하는 단계;

- 상기 수신된 클라이언트 버퍼 정보에 응답하여 상기 제1 비트 스트림으로부터 제2비트 레이트를 가지는 제2 비트 스트림으로 스위치하는 (switch) 단계;

- 상기 제2 비트 스트림의 데이터 패킷들을 상기 클라이언트로 전송하는 단계;

- 상기 전송된 데이타 패킷들의 적어도 하나를 적어도 하나의 서버 버퍼 내에 적어도 일시적으로 저장하는 단계;

- 상기 클라언트로부터 수신된 손상 정보와 상기 전송 중에 상기 전송된 데이터 패킷들 중 적어도 하나의 손상과 관련된 손상 정보를 해석한 것을 기반으로, 상기 서버 버퍼 내에 저장된 적어도 하나의 데이타 패킷의 재전송이 요구되는지를 판단하는 단계; 및

- 상기 적어도 하나의 데이터 패킷을 재전송하는 것이 요구된다고 결정되면 상기 적어도 하나의 데이터 패킷을 재전송하는 단계;를 포함하고,

상기 제2 비트 스트림의 상기 데이터 패킷의 상기 전송이 시작되면 상기 서 버 버퍼 내에 저장된 상기 제1 비트 스트림의 적어도 하나의 데이터 패킷은 상기 서버 버퍼 내에 유지되는 방법.
제1항에 있어서,

상기 서버 버퍼 내에 저장된 상기 제1 비트 스트림의 상기 적어도 하나의 데이터 패킷은 상기 수신된 손상 정보에 기반하여 상기 서버에서 정한 기간 (time duration) 동안 상기 서버 버퍼에 저장됨을 특징으로 하는 방법.
제1항에 있어서, 상기 방법은,

상기 버퍼 내에 저장된 상기 비트 스트림의 상기 적어도 하나의 데이터 패킷을 제거하는 단계;를 더 포함하며,

상기 제거하는 것은 상기 수신된 클라이언트 버퍼 정보에 좌우됨을 특징으로 하는 방법.
제1항에 있어서,

상기 클라이언트 버퍼의 상태에 관련된 클라이언트 버퍼 정보를 수신하는 것은 상기 클라이언트 버퍼에 저장된 가장 오래된 데이터 패킷의 식별정보에 관련된 클라이언트 버퍼 정보를 수신하는 것을 특징으로 하는 방법.
제1항에 있어서,

상기 서버로부터 상기 클라이언트로 상기 데이터 패킷들을 전송하는 것은 실시간 트랜스포트 프로토콜 (RTP)에 기반하고, 상기 손상 정보 및 상기 클라이언트 버퍼 정보를 상기 클라언트로부터 상기 수신하는 것은 실시간 트랜스포트 제어 프로토콜 (RTCP)에 기반함을 특징으로 하는 방법.
제1항에 있어서,

상기 데이터 패킷들은 3GPP 패킷 교환형 스트리밍 서비스 (PSS)에 따라 상기 서버로부터 상기 클라이언트로 전송되는 것을 특징으로 하는 방법.
- 서버로부터 클라이언트로 제1비트 레이트를 가지는 제1 비트 스트림의 데이터 패킷들을 전송하며, 상기 전송된 데이터 패킷들 중의 적어도 하나는 클라이언트 버퍼 내에 적어도 일시적으로 저장되는, 전송 수단;

- 상기 클라이언트 버퍼의 상태와 관련된 클라이언트 버퍼 정보를 상기 클라이언트로부터 수신하는 수단;

- 상기 수신된 클라이언트 버퍼 정보에 응답하여 상기 제1 비트 스트림으로부터 제2비트 레이트를 가지는 제2 비트 스트림으로 스위치하는 수단;

- 상기 제2 비트 스트림의 데이터 패킷들을 상기 클라이언트로 전송하는 수단;

- 상기 전송된 데이타 패킷들의 적어도 하나를 적어도 하나의 서버 버퍼 내에 적어도 일시적으로 저장하는 수단;

- 상기 클라언트로부터 수신된 손상 정보와 상기 전송 중에 상기 전송된 데이터 패킷들 중 적어도 하나의 손상과 관련된 손상 정보를 해석한 것을 기반으로, 상기 서버 버퍼 내에 저장된 적어도 하나의 데이타 패킷의 재전송이 요구되는지를 판단하는 수단; 및

- 상기 적어도 하나의 데이터 패킷을 재전송하는 것이 요구된다고 결정되면 상기 적어도 하나의 데이터 패킷을 재전송하는 수단;을 포함하고,

상기 제2 비트 스트림의 상기 데이터 패킷의 상기 전송이 시작되면 상기 서버 버퍼 내에 저장된 상기 제1 비트 스트림의 적어도 하나의 데이터 패킷은 상기 서버 버퍼 내에 유지되는 장치.
- 서버로부터 클라이언트로 제1비트 레이트로 데이터 패킷들을 전송하며, 상기 전송된 데이터 패킷들 중의 적어도 하나는 클라이언트 버퍼 내에 적어도 일시적으로 저장되는, 전송 단계;

- 상기 전송된 데이터 패킷들 중 적어도 한 개를 적어도 하나의 서버 버퍼에 적어도 일시적으로 저장하는 단계;

- 상기 전송 중에 상기 전송된 데이터 패킷들 중 적어도 하나의 손상과 관련된 손상 정보를 상기 클라이언트로부터 수신하는 단계;

- 상기 클라이언트 버퍼의 상태와 관련된 클라이언트 버퍼 정보를 상기 클라이언트로부터 수신하는 단계;

- 상기 수신된 손상 정보 및 상기 수신된 클라이언트 버퍼 상태 정보에 기반 하여, 데이터 패킷 재전송이 요구되는지를 판단하는 단계; 및

- 데이터 패킷 재전송이 요구된다고 판단된 경우에만, 상기 서버로부터 상기 클라이언트로, 상기 서버 버퍼에 저장된 적어도 하나의 데이터 패킷을 재전송하는 단계;를 포함하는 방법.
제8항에 있어서,

상기 손상 정보는 상기 전송 중에 손상된 적어도 한 데이터 패킷의 시퀀스 넘버를 판단할 수 있게 하며,

상기 클라이언트 버퍼 정보는 상기 클라이언트 버퍼에 저장된 가장 오래된 데이터 패킷의 시퀀스 넘버에 관한 것이며,

상기 데이터 패킷 재전송이 요구되는지를 판단하는 것은 상기 적어도 한 개의 손상된 데이터 패킷의 상기 시퀀스 넘버와 상기 가장 오래된 데이터 패킷의 시퀀스 넘버 사이의 차에 좌우됨을 특징으로 하는 방법.
제9항에 있어서,

상기 서버 버퍼에 저장된 데이터 패킷들은, 이들과 결부된 시퀀스 넘버들 및 상기 가장 오래된 데이터 패킷의 시퀀스 넘버의 차이에 좌우되어 삭제됨을 특징으로 하는 방법.
제8항에 있어서,

상기 서버로부터 상기 클라이언트로 상기 데이터 패킷들을 전송하는 것은, 실시간 트랜스포트 프로토콜 (RTP)에 기반하고,

상기 손상 정보 및 상기 클라이언트 버퍼 정보를 수신하는 것은 실시간 트랜스포트 제어 프로토콜 (RTCP)에 기반함을 특징으로 하는 방법.
제8항에 있어서, 상기 데이터 패킷들은 3GPP 패킷 교환형 스트리밍 서비스 (PSS)에 따라 상기 서버로부터 상기 클라이언트로 전송되는 것임을 특징으로 하는 방법.
- 서버로부터 클라이언트로 제1비트 레이트로 데이터 패킷들을 전송하며, 상기 전송된 데이터 패킷들 중의 적어도 하나는 클라이언트 버퍼 내에 적어도 일시적으로 저장되는, 전송 수단;

- 상기 전송된 데이터 패킷들 중 적어도 한 개를 적어도 하나의 서버 버퍼에 적어도 일시적으로 저장하는 수단;

- 상기 전송 중에 상기 전송된 데이터 패킷들 중 적어도 하나의 손상과 관련된 손상 정보를 상기 클라이언트로부터 수신하는 수단;

- 상기 클라이언트 버퍼의 상태와 관련된 클라이언트 버퍼 정보를 상기 클라이언트로부터 수신하는 수단;

- 상기 수신된 손상 정보 및 상기 수신된 클라이언트 버퍼 상태 정보에 기반하여, 데이터 패킷 재전송이 요구되는지를 판단하는 수단; 및

- 상기 서버로부터 상기 클라이언트로 상기 서버 버퍼에 저장된 적어도 하나의 데이터 패킷을 재전송하는 수단으로서, 상기 재전송은 데이터 패킷 재전송이 요구된다고 판단된 경우에만 실행되는, 재전송 수단;을 포함하는 장치.
프로세서가 제1항의 방법을 수행할 수 있도록 작동되는 명령어들을 구비하는 컴퓨터 프로그램을 포함하는 컴퓨터로 읽을 수 있는 기록 매체.
프로세서가 제8항의 방법을 수행할 수 있도록 작동되는 명령어들을 구비하는 컴퓨터 프로그램을 포함하는 컴퓨터로 읽을 수 있는 기록 매체.
- 서버로부터 클라이언트로 제1비트 레이트를 가지는 제1 비트 스트림의 데이터 패킷들을 전송하도록 구성된 전송기로서, 상기 전송된 데이터 패킷들 중의 적어도 하나는 클라이언트 버퍼 내에 적어도 일시적으로 저장되는, 전송기;

- 상기 클라이언트 버퍼의 상태와 관련된 클라이언트 버퍼 정보를 상기 클라이언트로부터 수신하도록 구성된 수신기;

- 상기 수신된 클라이언트 버퍼 정보에 응답하여 상기 제1 비트 스트림으로부터 제2비트 레이트를 가지는 제2 비트 스트림으로 스위치하도록 구성된 프로세서; [상기 전송기는 상기 제2 비트 스트림의 데이터 패킷들을 상기 클라이언트로 전송하도록 또한 구성됨]

- 상기 전송된 데이타 패킷들의 적어도 하나를 적어도 일시적으로 저장하도 록 구성된 적어도 하나의 서버 버퍼;를 포함하며,

- 상기 프로세서는, 상기 클라언트로부터 수신된 손상 정보와 상기 전송 중에 상기 전송된 데이터 패킷들 중 적어도 하나의 손상과 관련된 손상 정보를 해석한 것을 기반으로, 상기 서버 버퍼 내에 저장된 적어도 하나의 데이타 패킷의 재전송이 요구되는지를 판단하도록 또한 구성되며,

- 상기 전송기는, 적어도 하나의 데이터 패킷을 재전송하는 것이 요구된다고 결정되면 상기 적어도 하나의 데이터 패킷을 재전송하도록 또한 구성되며, 그리고

상기 적어도 하나의 서버 버퍼는 상기 제2 비트 스트림의 상기 데이터 패킷의 상기 전송이 시작되면 상기 제1 비트 스트림의 적어도 하나의 데이터 패킷을 상기 적어도 하나의 서버 버퍼 내에 유지하도록 또한 구성된, 장치.
제16항에 있어서,

상기 적어도 하나의 서버 버퍼는 상기 서버 버퍼 내에 저장된 상기 제1 비트 스트림의 상기 적어도 하나의 데이터 패킷을 상기 수신된 손상 정보에 기반하여 상기 서버에서 정한 기간 (time duration) 동안 저장하도록 구성됨을 특징으로 하는 장치.
제16항에 있어서,

상기 적어도 하나의 서버 버퍼는 상기 버퍼 내에 저장된 상기 비트 스트림의 상기 적어도 하나의 데이터 패킷을 제거하도록 또한 구성되며,

상기 제거하는 것은 상기 수신된 클라이언트 버퍼 정보에 좌우됨을 특징으로 하는 장치.
제16항에 있어서,

상기 수신기는, 상기 클라이언트 버퍼에 저장된 가장 오래된 데이터 패킷의 식별정보에 관련된 클라이언트 버퍼 정보를 수신함으로써, 상기 클라이언트 버퍼의 상태에 관련된 클라이언트 버퍼 정보를 수신하도록 구성된 것을 특징으로 하는 장치.
제16항에 있어서,

상기 전송기는 실시간 트랜스포트 프로토콜 (RTP)에 기반하여 상기 서버로부터 상기 클라이언트로 상기 데이터 패킷들을 전송하도록 구성되며,

상기 수신기는 실시간 트랜스포트 제어 프로토콜 (RTCP)에 기반하여 상기 손상 정보 및 상기 클라이언트 버퍼 정보를 상기 클라언트로부터 수신하도록 구성된 것을 특징으로 하는 장치.
제16항에 있어서,

상기 전송기는 3GPP 패킷 교환형 스트리밍 서비스 (PSS)에 따라 상기 데이터 패킷들을 상기 서버로부터 상기 클라이언트로 전송하는 것을 특징으로 하는 장치.
- 서버로부터 클라이언트로 제1비트 레이트로 데이터 패킷들을 전송하도록 구성된 전송기로서, 상기 전송된 데이터 패킷들 중의 적어도 하나는 클라이언트 버퍼 내에 적어도 일시적으로 저장되는, 전송기;

- 상기 전송된 데이터 패킷들 중 적어도 한 개를 적어도 일시적으로 저장하도록 구성된 적어도 하나의 서버 버퍼;

- 상기 전송 중에 상기 전송된 데이터 패킷들 중 적어도 하나의 손상과 관련된 손상 정보를 상기 클라이언트로부터 수신하도록 구성되며, 상기 클라이언트 버퍼의 상태와 관련된 클라이언트 버퍼 정보를 상기 클라이언트로부터 수신하도록 또한 구성된 수신기; 및

- 상기 수신된 손상 정보 및 상기 수신된 클라이언트 버퍼 상태 정보에 기반하여, 데이터 패킷 재전송이 요구되는지를 판단도록 구성된 프로세서;를 포함하며,

상기 전송기는, 데이터 패킷 재전송이 요구된다고 판단된 경우에, 상기 서버로부터 상기 클라이언트로, 상기 서버 버퍼에 저장된 적어도 하나의 데이터 패킷을 재전송하도록 또한 구성된, 장치.
제22항에 있어서,

상기 손상 정보는 상기 전송 중에 손상된 적어도 한 데이터 패킷의 시퀀스 넘버를 판단할 수 있게 하며,

상기 클라이언트 버퍼 정보는 상기 클라이언트 버퍼에 저장된 가장 오래된 데이터 패킷의 시퀀스 넘버에 관한 것이며,

상기 프로세서는 상기 적어도 한 개의 손상된 데이터 패킷의 상기 시퀀스 넘버와 상기 가장 오래된 데이터 패킷의 시퀀스 넘버 사이의 차에 좌우되어 상기 데이터 패킷 재전송이 요구되는지의 여부를 판단하도록 구성됨을 특징으로 하는 장치.
제23항에 있어서,

상기 적어도 하나의 서버 버퍼는 상기 서버 버퍼에 저장된 데이터 패킷들을, 이들과 결부된 시퀀스 넘버들 및 상기 가장 오래된 데이터 패킷의 시퀀스 넘버의 차이에 좌우되어 삭제하도록 또한 구성됨을 특징으로 하는 장치.
제22항에 있어서,

상기 전송기는 실시간 트랜스포트 프로토콜 (RTP)에 적어도 일부 기반하여 상기 서버로부터 상기 클라이언트로 상기 데이터 패킷들을 전송하며,

상기 수신기는 실시간 트랜스포트 제어 프로토콜 (RTCP)에 적어도 일부 기반하여 상기 손상 정보 및 상기 클라이언트 버퍼 정보를 수신하는 것을 특징으로 하는 장치.
제22항에 있어서,

상기 전송기는 3GPP 패킷 교환형 스트리밍 서비스 (PSS)에 따라 상기 데이터 패킷들을 상기 서버로부터 상기 클라이언트로 전송하는 것을 특징으로 하는 장치.