KR20200113632A

KR20200113632A - 전송 경로 상태에 기반한 혼잡 제어를 사용하는 타겟 전송 속도 결정 방법 및 시스템

Info

Publication number: KR20200113632A
Application number: KR1020190034125A
Authority: KR
Inventors: 곽정남
Original assignee: 라인플러스 주식회사
Priority date: 2019-03-26
Filing date: 2019-03-26
Publication date: 2020-10-07
Also published as: US20200314035A1

Abstract

수신기로부터 수신한 패킷에 관한 정보를 포함하는 피드백 메시지를 수신하고, 수신된 피드백 메시지에 기반하여 전송 경로의 상태를 결정하기 위한 적어도 하나의 메트릭(metric)을 추정하여 추정된 메트릭에 기반하여 전송 경로의 상태를 결정하고, 결정된 전송 경로의 상태에 기반하여 전송 경로를 위한 타겟 전송 속도를 결정하는 타겟 전송 속도 결정 방법이 제공된다. 전송 경로의 상태를 결정하기 위해 추정된 메트릭은 피드백 메시지가 전송되는 경로인 역방향 경로(Backward path)에 의한 영향이 제거된 전송 경로의 특성만을 반영한다.

Description

전송 경로 상태에 기반한 혼잡 제어를 사용하는 타겟 전송 속도 결정 방법 및 시스템{METHOD AND SYSTEM FOR DETERMINING TARGET BITRATE USING CONGESTION CONTROL BASED ON FORWARD PATH STATUS}

아래의 설명은 전송 경로를 위한 타겟 전송 속도를 결정하는 기술에 관한 것으로, 특히, 전송 경로 상태(Forward path Status)에 기반한 혼잡 제어(Congestion Control)를 통해 전송 경로를 위한 타겟 전송 속도를 결정하여 송신기의 전송 속도를 제어하는 기술에 관한 것이다.

RTP(Real-Time transport Protocol)는 VoIP 등에서 데이터의 실시간 전송을 위해 사용되는 응용/전송 계층의 프로토콜이다. 이러한 데이터의 실시간 전송에 있어서 짧은 지연 시간을 보장하는 것은 데이터의 실시간 전송의 성능을 표지하는 주요한 요소 중 하나이다. 그러나, 네트워크에 존재하는 다양한 예측 불가능한 상황은 짧은 지연 시간을 보장하는 것을 어렵게 만든다.

한편, 오늘날의 기술의 발달과 미디어의 다양화에 따라 통신되는 트래픽의 양은 급격하게 증가하고 있다. 트래픽이 많아질수록 네트워크의 부담이 커지게 되고, 이는 결국 보다 큰 지연 시간으로 이어지게 된다.

따라서, 실시간 데이터 전송 환경에 있어서, 네트워크의 리소스를 예측하여 리소스 사용을 효율적으로 만들기 위해, 전송 경로의 상태에 적합한 타겟 전송 속도를 결정하고 이에 따라 전공 속도를 제어할 수 있도록 하는 방법이 요구된다.

한국공개특허 제10-2005-0085549호(공개일 2005년 08월 29일)는 통신 네트워크와, 이러한 네트워크의 전송 속도를 조정하는 장치 및 방법에 관해 개시하고 있다.

상기에서 설명된 정보는 단지 이해를 돕기 위한 것이며, 종래 기술의 일부를 형성하지 않는 내용을 포함할 수 있으며, 종래 기술이 통상의 기술자에게 제시할 수 있는 것을 포함하지 않을 수 있다.

수신기로부터 수신된 피드백 메시지에 기반하여 피드백 메시지가 전송되는 경로인 역방향 경로(Backward path)에 의한 영향이 제거된 전송 경로의 특성만을 반영하는 메트릭(metric)을 추정하고, 추정된 메트릭에 기반하여 패킷 전송을 위한 전송 경로의 상태를 결정하고 전송 경로를 위한 타겟 전송 속도를 결정하는 방법을 제공할 수 있다.

일 측면에 있어서, 송신기(transmitter) 측에서 수행되는, 수신기로의 패킷 전송을 위한 전송 경로(Forward path)를 위한 타겟 전송 속도 결정 방법에 있어서, 상기 수신기로부터, 상기 송신기로부터 수신된 패킷에 관한 정보를 포함하는 피드백 메시지를 수신하는 단계, 상기 수신된 피드백 메시지에 기반하여 상기 전송 경로의 상태를 결정하기 위한 적어도 하나의 메트릭(metric)을 추정하는 단계, 상기 추정된 메트릭에 기반하여 상기 전송 경로의 상태를 결정하는 단계 및 전송 경로의 상태에 기반하여 상기 전송 경로를 위한 타겟 전송 속도를 결정하는 단계를 포함하고, 상기 추정된 메트릭은 상기 피드백 메시지가 전송되는 경로인 역방향 경로(Backward path)에 의한 영향이 제거된 상기 전송 경로의 특성만을 반영하는 타겟 전송 속도 결정 방법이 제공된다.

상기 타겟 전송 속도 결정 방법은 상기 결정된 타겟 전송 속도로 상기 송신기의 상기 수신기로의 패킷의 전송 속도를 제어하는 단계를 더 포함할 수 있다.

상기 결정된 전송 경로의 상태는 스로틀드(throttled) 상태, 프로빙(probing) 상태, 컴피팅(competing) 상태 및 디폴트(default) 상태 중 하나이고, 상기 타겟 전송 속도를 결정하는 단계는, 상기 결정된 전송 경로의 상태가 스로틀드 상태이면, 상기 송신기의 상기 수신기로의 패킷의 전송 속도를 낮추어 큐(queue)를 비울 수 있도록 상기 타겟 전송 속도를 결정하고, 상기 결정된 전송 경로의 상태가 컴피팅 상태 또는 디폴트 상태이면, 큐 지연 시간(queue latency)이 타겟 큐 지연 시간(targeting queue latency) 내에서 유지되도록 상기 타겟 전송 속도를 결정하고, 상기 결정된 전송 경로의 상태가 프로빙 상태이면, 상기 전송 경로의 병목 대역폭(bottlenecked bandwidth)을 탐지(prove)하기 위해 상기 송신기의 상기 수신기로의 패킷의 전송 속도를 증가시키도록 상기 타겟 전송 속도를 결정할 수 있다.

상기 스로틀드(throttled) 상태는 상기 송신기의 상기 수신기로의 패킷의 전송 속도가 상기 전송 경로의 대역폭 한계(bw limitation)보다 더 큰 상태를 나타내고, 상기 컴피팅 상태는 크로스 트래픽이 검출된 상태를 나타내고, 상기 프로빙 상태는 상기 송신기의 상기 수신기로의 패킷의 전송 속도가 상기 대역폭 한계 미만인 상태를 나타내고, 상기 디폴트 상태는 상기 스로틀드 상태, 상기 프로빙 상태, 또는 상기 컴피팅 상태에 해당하지 않는 상기 전송 경로의 상태를 나타낼 수 있다.

상기 메트릭을 추정하는 단계는 상기 전송 경로의 대역폭(Forward Bandwidth) 및 큐 딜레이(queue delay)를 포함하는 상기 메트릭을 추정할 수 있다.

상기 피드백 메시지는 주기적으로 수신되고, 상기 메트릭을 추정하는 단계는 상기 전송 경로의 대역폭(Forward Bandwidth) 및 큐 딜레이를 포함하는 상기 메트릭을 추정하고, 상기 큐 딜레이가 상대적으로 낮은 값으로 소정의 제1 시간 이상 지속될 경우 상기 전송 경로의 상태는 프로빙 상태로 결정되고, 상기 큐 딜레이가 상대적으로 높은 값으로 소정의 제2 시간 이상 지속될 경우 상기 전송 경로의 상태는 컴피팅 상태로 결정되고, 상기 큐 딜레이가 급격하게 증가하고 상기 전송 경로의 대역폭이 감소하면 상기 전송 경로의 상태는 스로틀드 상태로 결정될 수 있다.

상기 피드백 메시지는 주기적으로 수신되고, 상기 메트릭을 추정하는 단계는 상기 전송 경로의 대역폭(Forward Bandwidth)을 포함하는 상기 메트릭을 추정하고, 상기 타겟 전송 속도를 결정하는 단계는, 상기 결정된 상기 전송 경로의 상태가 컴피팅 상태이면 수학식 1에 따라 결정된 타겟 대역폭에 따라 상기 타겟 전송 속도를 결정하고,

[수학식 1]

타겟 대역폭 = 추정된 전송 경로의 대역폭 * N%

N은 50 초과 100 미만의 실수이고,

상기 결정된 상기 전송 경로의 상태가 스로틀드 상태이면 수학식 2에 따라 결정된 타겟 대역폭에 따라 상기 타겟 전송 속도를 결정하고,

[수학식 2]

타겟 대역폭 = 추정된 전송 경로의 대역폭 * 0.5

상기 결정된 상기 전송 경로의 상태가 프로빙 상태이면 수학식 3에 따라 결정된 타겟 대역폭에 따라 상기 타겟 전송 속도를 결정하고,

[수학식 3]

타겟 대역폭 = 추정된 전송 경로의 대역폭 * (1+알파)

상기 알파는 0 초과의 실수이고, 상기 결정된 상기 전송 경로의 상태가 디폴트 상태이면 상기 추정된 전송 경로의 대역폭에 해당하는 타겟 대역폭에 따라 상기 타겟 전송 속도를 결정할 수 있다.

상기 메트릭을 추정하는 단계는, 상기 수신된 피드백 메시지의 유효성(validation)을 검사(check)하는 단계, 상기 피드백 메시지를 파싱하는 단계, 상기 피드백 메시지에 포함된 데이터에 기반하여, 상기 송신기가 송신한 패킷의 크기에 대한 상기 수신기가 수신한 패킷의 크기의 비에 대응하는 비트레이트 프랙션(brFraction)을 획득하는 단계, 상기 비트레이트 프랙션에 기반하여 상기 전송 경로의 대역폭을 추정하는 단계 및 상기 전송 경로에 대한 큐 딜레이(QDelay) 및 Q 딜레이의 범위(QMrange)를 추정하는 단계를 포함하고, 상기 전송 경로의 상태를 결정하는 단계는, 상기 전송 경로의 상태를 결정하기 위해 정의된 이벤트와, 상기 추정된 전송 경로의 대역폭, 큐 딜레이 또는 큐 딜레이의 범위 중 적어도 하나에 기반하여 상기 전송 경로의 상태를 결정할 수 있다.

상기 피드백 메시지는 RTCP 헤더, 상기 수신기 측의 식별자(Rxer ID), 상기 송신기 측의 식별자(Txer ID), 피드백 메시지 헤더 및 리포트되는 패킷에 관한 데이터를 포함하는 리포트 블록을 포함할 수 있다.

상기 피드백 메시지 헤더는 리포트 시간(Report Time) 필드, 피드백 시퀀스 필드 및 모니터링 시간(Monitored Time) 필드를 포함하고, 상기 리포트 시간 필드는 상기 송신기의 시스템 업 시간(system up time)을 리포트 시간으로서 나타내는 값을 포함하고, 상기 피드백 시퀀스 필드는 상기 피드백 시퀀스의 시퀀스 넘버를 나타내는 값을 포함하고, 상기 모니터링 시간 필드는 상기 피드백 메시지를 생성하기 위해 관찰하는 지속 시간(duration)을 모니터링 시간으로서 나타내는 값을 포함할 수 있다.

상기 리포트 블록은 리포트되는 패킷의 SSRC를 나타내는 값을 포함하는 SSRC 필드, 리포트되는 패킷의 카운트를 나타내는 값을 포함하는 리포트 패킷 카운트 필드, 리포트되는 패킷의 마지막 시퀀스 넘버를 나타내는 값을 포함하는 엔드 시퀀스(end_seq) 필드, 패킷의 손실 여부를 나타내는 값을 포함하는 L 필드 및 리포트되는 패킷의 수신 시간의 상기 리포트 시간에 대한 상대적인 시간 거리를 나타내는 값을 포함하는 ATO (Arrival Time Offset) 필드를 포함할 수 있다.

상기 리포트 블록은 리포트되는 패킷의 SSRC를 나타내는 값을 포함하는 SSRC 필드, 리포트되는 패킷의 카운트를 나타내는 값을 포함하는 리포트 패킷 카운트 필드, 리포트되는 패킷의 시작 시퀀스 넘버를 나타내는 값을 포함하는 스타트 시퀀스 넘버 필드, 리포트되는 각 패킷에 대한 정보를 나타내는 값을 포함하는 Pkt-요소(Pkt-Element) 필드를 포함할 수 있다.

상기 리포트 시간 및 상기 엔드 시퀀스 필드의 값에 기반하여, 상기 엔드 시퀀스 필드의 값에 대응하는 패킷의 전송 이후로부터 상기 피드백 메시지의 수신 전까지 상기 송신기로부터 전송되는 패킷은 상기 메트릭의 추정에 있어서 고려되지 않을 수 있다.

상기 엔드 시퀀스 필드의 값에 대응하는 패킷의 전송 이후에 상기 엔드 시퀀스 필드의 값에 대응하는 패킷의 ATO 필드의 값에 대응하는 시간 동안 상기 송신기로부터 전송되는 패킷은 상기 메트릭의 추정에 있어서 고려될 수 있다.

상기 송신기 측에서 상기 피드백 메시지를 수신한 시간이 아닌, 상기 수신기 측에서 상기 피드백 메시지를 전송한 시간을 기준으로 상기 메트릭이 추정되고, 상기 전송 경로의 상태가 결정될 수 있다.

상기 타겟 전송 속도 결정 방법은 상기 수신기 측에 특정한 피처(feature)를 요청하기 위한 제어 메시지를 전송하는 단계를 더 포함하고, 상기 제어 메시지는 상기 수신기가 이해할 수 있는 메시지 타입을 갖는 경우에 상기 수신기로부터 응답이 이루어질 수 있다.

상기 피드백 메시지는 소정의 피드백 인터벌 시간에 따라 주기적으로 수신되고, 상기 피드백 인터벌 시간은 상기 송신기 측에서 설정되고, 상기 피드백 메시지를 생성함에 있어서 관찰하는 지속시간에 해당하는 모니터링 시간은 송신기 측에서 설정되고, 상기 모니터링 시간은 상기 피드백 인터벌 시간보다 크거나 같을 수 있다.

실시예들을 통해서는, 패킷 전송을 위한 전송 경로의 상태를 스로틀드(throttled) 상태, 컴피팅(competing) 상태, 프로빙(proing) 상태 및 디폴트(default) 상태 중 어느 하나로 분류할 수 있다.

실시예들을 통해서는, 피드백 메시지가 전송되는 역방향 경로에 의한 영향이 최소화됨으로써, 패킷 전송을 위한 전송 경로에 대해 보다 정확한 전송 경로의 상태 파악 및 전송 경로를 위한 타겟 전송 속도의 결정이 이루어질 수 있다.

도 1은 일 실시예에 따른 CCFS 피드백 메시지의 포맷을 나타낸다.
도 2는 일 실시예에 따른 CCFS 피드백 메시지 헤더를 나타낸다.
도 3은 일 실시예에 따른 CCFS 리포트 블록을 나타낸다.
도 4는 일 실시예에 따른 CCFS Pkt-요소를 나타낸다.
도 5는 일 실시예에 따른 CCFS 피드백 메시지의 포맷의 다른 예시를 나타낸다.
도 6은 일 실시예에 따른 상태들에 대한 상태 변화 다이어그램을 나타낸다.
도 7은 일 예에 따른 상태들에 대한 상태 변화 다이어그램을 나타낸다.
도 8은 일 실시예에 따른 제어 메시지 포맷을 나타낸다.
도 9는 일 실시예에 따른 송신기-수신기 간의 패킷 및 피드백 패킷 메시지 전송 방법을 나타낸다.
도 10은 일 예에 따른 FwdBW를 추정하는 방법을 나타내는 알고리즘이다.
도 11은 일 예에 따른 스로틀드 상태와 관련된 이벤트를 처리하는 방법을 나타내는 알고리즘을 나타낸다.
도 12는 일 예에 따른 컴피팅 상태와 관련된 이벤트를 처리하는 방법을 나타내는 알고리즘을 나타낸다.
도 13은 일 예에 따른 프로빙 상태와 관련된 이벤트를 처리하는 방법을 나타내는 알고리즘을 나타낸다.
도 14는 일 실시예에 따른 송신기 및 수신기의 내부 구성을 설명하기 위한 블록도이다.
도 15는 일 실시예에 따른 타겟 전송 속도 결정 방법을 나타내는 흐름도이다.
도 16은 일 실시예에 따른 전송 경로의 상태를 결정하기 위한 메트릭을 추정하는 방법을 나타내는 흐름도이다.
도 17은 일 실시예에 따른 피드백 메시지를 전송하는 방법을 나타내는 흐름도이다.

이하에서, 첨부된 도면을 참조하여 실시예들을 상세하게 설명한다. 각 도면에 제시된 동일한 참조 부호는 동일한 부재를 나타낸다. 아래의 상세한 설명에서 용어 "시간"은 어떤 시각부터 어떤 시각까지의 사이뿐만이 아니라, 특정한 시점 또는 시각을 나타내는 것으로도 사용될 수 있다.

아래에서는 본 문서는 순방향 경로(즉, 전송 경로(Forward path)) 상태에 기반한 혼잡 제어(Congestion Control based on Forward path Status; CCFS)를 설명하고, 비디오 컨퍼런스와 같은 인터랙티브 실시간 미디어 어플리케이션들을 위한 레이트 적응 스킴에 관해 설명한다. CCFS는, 병목 대역폭(bottleneck bandwidth), 큐 딜레이 및 손실률(loss ratio)과 같은 추정된 파라미터들에 기반하여 제어되는 순방향 경로들의 상태를 제한된(스로틀드(throttled)) 상태, 경쟁(컴피팅(competing)) 상태, 프로빙(probing) 상태 및 디폴트(default) 상태로 분류한다. 순방향 경로 상태만을 고려하는 것은 혼잡과 같은 역방향 경로(즉, 피드백 메시지를 수신하는 경로(Backward path))의 네트워크 이벤트의 영향을 최소화한다. 또한 일반화된 피드백 메시지가 정의되므로 호환성 문제로부터 자유롭게 될 수 있다.

인터랙티브 실시간 멀티미디어 어플리케이션들은 대역폭 변화에 적응하기 위해 전송 속도(transmitting rate)를 제어하고 네트워크를 통한 낮은 큐잉(queuing) 딜레이를 유지해야한다는 요구 사항을 갖는다. 이러한 문제를 해결하기 위해 RTT, 패킷 손실 및 ECN (Explicit Congestion Notification)과 같은 많은 메트릭들(metrics)이 현재의 네트워크 상태를 판단하기 위해 사용된다.

이러한 실시간 통신 어플리케이션들은 - 미디어를 전송하기 위한 순방향 경로(즉, 전송 경로)와 미디어를 수신하는 역방향 경로 -의 두 가지의 스트리밍 경로들을 가질 수 있다. 또한, 각 경로는 대부분의 경우에 있어서 독립적이다. 예컨대, 역방향 경로에서 혼잡이 발생하더라도, 순방향 경로에서 전송 속도를 낮출 필요는 없다. 그러나 RTT가 혼잡 제어에 사용되면, RTT가 순방향 경로의 지연 시간(latency)뿐만 아니라 역방향 경로의 지연 시간의 영향을 받을 수 있으므로 주의가 요구된다. 이는 전송 속도를 제어하기 위해 사용되지만 RTT와 같은 메트릭 또는 동작(behavior)은 역방향 경로의 상태에 영향을 받아 잘못된 결정을 초래할 수 있다.

CCFS는 그 알고리즘에서 순방향 경로의 특성만을 반영하는 메트릭들을 사용하여 역방향 경로 조건(상태)들의 영향을 제거할 수 있다. CCFS는 호환성 문제가 없는 송신기(sender)-기반의 방법이다. 즉, 알고리즘 변형들 또는 다른 문제들로 인한 복수의 CCFS 송신기 버전들의 공존이 가능하게 될 수 있다. 이를 달성하기 위해 CCFS 수신자의 수동적인 동작과 일반화된 피드백 메커니즘이 아래에서 설명된다.

아래에서 실시예들과 관련된 기술의 개요에 대해 설명한다.

CCFS를 수행하는 모듈은 Txer 및 Rxer 두 가지가 있다. Txer는 CCFS의 송신기의 약어이고 Rxer는 CCFS의 수신기를 나타낼 수 있다. Txer는 연관된 Rxer로부터 CCFS 피드백 메시지들을 검사함으로써(examining) 전송 비트레이트를 제어하기 위한 주된 역할을 수행할 수 있다. 주기적인 CCFS 피드백 메시지들을 전송할 때를 제외하고는 Rxer는 수동적으로 동작한다. Txer 및 Rxer가 네트워크 경로를 공유할 수 있는 경우, Txer 및 Rxer는 복수의 RTP 스트림들을 관리한다. 예컨대, 동일한 4 튜플(또는 5 튜플) - 소스 IP, 소스 포트, 목적지 IP 및 대상 포트 -를 사용하는 복수의 RTP 스트림들은 하나의 Txer 및 Rxer와 연관된다.

CCFS를 시작하기 위해서는, Txer 및 Rxer는 CCFS 네고시에이션을 완료해야 한다. 네고시에이션은 연관하는 RTP 세션이 마련되기 전에 외부 채널에서 달성되어야 한다. 네고시에이션을 통해 Rxer는 자신의 Rxer ID와 리포트할 Txer ID를 미리 알 수 있다.

CCFS 피쳐가 네고시에이션되면 Rxer는 주기적인 CCFS 피드백 메시지를 (Txer로) 전송할 수 있다. Txer는 다양한 메트릭들, 주로 3가지의 메트릭들 - 병목 대역폭, 큐 지연 시간 및 손실률 -을 추정할 수 있다. 그 다음으로, Txer는 순방향 경로의 상태에 대해 결정하며, 순방향 경로의 상태는 스로틀드(throttled), 프로빙(probing), 컴피팅(competing) 및 디폴트(default) 중 하나일 수 있다. Txer는 순방향 경로(전송 경로)의 상태에 따라 타겟 전송 속도를 동작시킬 수 있다.

각 전송 경로의 상태는 아래와 같을 수 있다.

스로틀드 상태: 네트워크 큐가 쌓여 있는 것이 검출된 상태임. 현재의 전송 속도는 큐를 비울 수 있도록 낮추어져야 함.

컴피팅 상태: 크로스 트래픽이 검출된 상태임. 즉, 경로 내에 다른 노드가 끼어든 상태를 나타냄. 현재의 전송 속도는 큐 지연 시간을 타겟 큐 지연 시간 내에서 유지하도록 제어되어야 함. Starvation을 방지하기 위해 전송 속도는 너무 급격하게 줄이지 않을 것이 요구됨.

프로빙 상태: 해당 상태에서는 순방향 경로의 병목 대역폭이 추정된 대역폭보다 클 수 있음. 현재 전송 속도는 병목 대역폭을 탐지하기 위해 증가되어야 함. 즉, 프로빙 상태에서는 전송 경로에 여유가 있으므로, 전송 속도를 더 증가시킬 수 있음.

디폴트 상태: 전술한 3가지의 상태에 속하지 않는 상태임. 현재의 전송 속도는 큐 지연 시간을 타겟 큐 지연 시간 내에서 유지하도록 제어되어야 함.

프로빙 상태 동안, 전송 속도는 가용한 대역폭을 탐지하기 위해 증가되어야 한다. 그러나, 이는 혼잡으로 이어질 수 있고 미디어 퀄리티에 손상을 줄 수 있다. 부작용을 최소화하기 위해 FEC 패킷들과 같은 리던던트(redundant) 패킷을 전송하는 것이 권장될 수 있다.

아래에서는 실시예들과 관련된 CCFS에 대해 보다 자세하게 설명한다.

CCFS는 실행 전에 네고시에이션되어야 한다. 네고시에이션의 방식을 정의하는 것은 본 개시의 범위를 벗어나는 것일 수 있다. 이는 SDP 네고시에이션에 관한 문헌 또는 응용 프로그램 정의 프로토콜을 사용하여 이루어질 수 있다. 예컨대, RFC 4566 (Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <http://www.rfc-editor.org/info/rfc4566>)에서 설명된다. 네고시에이션을 통해 결정해야 할 파라미터들에 대해서는 아래에서 설명한다.

1. Txer ID (4 바이트): CCFS Txer의 ID가 결정되어야 한다. 이는 CCFS에서 사용되는 RTCP 메시지에서 SSRC로 사용될 수 있다. 따라서, 이러한 값은 전송 RTP 스트림의 SSRC 중에서 고유해야 할 수 있다.

2. Rxer ID (4 바이트): Txer와 연관된 Rxer는 RTCP 메시지들에서 SSRC로서 사용할 자체의 ID를 가져야 할 수 있다.

3. 선호되는 피드백 인터벌 시간(preferred feedback interval time): Rxer는 초기 피드백 인터벌 시간을 알아야 할 수 있다. 이러한 인터벌은 세션 내에서 Txer에 의해 변경될 수 있다.

4. 선호되는 모니터링 시간(preferred monitoring time): 피드백 메시지는 이러한 최근의 모니터링 시간 동안 수신된 패킷의 정보를 가질 수 있다.

5. 하위 계층 프로토콜: 대부분의 경우들에서는 UDP 스택 상에서 RTP 패킷이 전송될 수 있다. 그러나 RTP 패킷은 어플리케이션 요구 사항에 따라 다른 전송 계층들 상에서 전송될 수 있다. 상이한 하위 계층 프로토콜 스택에 대해서는 다른 혼잡 제어 메커니즘이 합리적일 수 있게 될 수 있다. 어떤 혼잡 제어 메커니즘을 사용해야 할 지를 결정하기 위해서는, Rxer의 전송 계층과 Txer의 전송 계층이 모두 필요하게 될 수 있다. 본 개시에서 설명된 CCFS는 UDP만을 가정하지만, CCFS Txer는 다른 전송 계층을 위해 수정될 수도 있다.

아래에서는 수신기(Rxer)에 대해 보다 자세하게 설명한다.

Rxer는 인터벌 시간을 알아야 하고, 디폴트 인터벌 시간은 100msec일 수 있다. 피드백 인터벌 시간은 Txer에 의해 전송된 RTCP 메시지에 의해 변경될 수 있다.

Rxer는, 피드백 인터벌 시간이 지난 경우에도, 여하한 패킷을 수신하지 않았고 이전에 피드백을 전송하지 않은 경우에는 피드백을 전송하지 않을 수 있다. 그러나, Rxer는 일단 피드백 메시지를 전송하기 시작하면 주기적으로 피드백을 보내야 한다. 또한, Rxer는 마지막 피드백 인터벌 시간 동안 수신된 패킷이 없는 경우에도 그것이 중요한 신호일 수 있으므로 피드백을 전송해야 한다.

피드백 메시지 크기가 MTU 크기보다 더 클 수 있다면, 즉시 Rxer는 다음 피드백 인터벌 시간이 도달하기 전에 피드백을 보내야 한다.

아래에서는 수신기 측에서 생성되는 피드백 메시지의 포맷에 관해 더 자세하게 설명한다.

CCFS 피드백 메시지는 예컨대, [I-D.ietf-dt-rmcat-feedback-message]("RTP Control Protocol (RTCP) Feedback for Congestion Control", <https://tools.ietf.org/html/draft-ietf-avtcore-cc-feedback-message-02>)에서 정의된 것과 유사한 설계 목표를 가질 수 있다. CCFS 피드백 메시지는 CCFS 알고리즘에 대한 보다 구체적인 정보를 필요로 할 수 있다.

도 1은 일 실시예에 따른 CCFS 피드백 메시지의 포맷을 나타낸다.

첫 번째 4 옥텟은 PT=205 및 FMT=CCFSFB를 갖는 RTCP 헤더를 나타내고, 다음의 4 옥텟은 패킷 송신기 측의 SSRC를 나타낼 수 있다. CCFS는 SSRC를 이전의 네고시에이션으로부터 획득되어야 할 Rxer ID로 대체할 수 있다.

리포트될 시에 RTCP 헤더 다음에는 미디어 소스의 SSRC가 따르는 것이 요구된다. 이러한 피드백 메시지는 하나의 SSRC를 지정할 수 없기 때문에 Txer ID는 특정 RTP SSRC 대신에 여기에 위치될 수 있다.

다음의 8 옥텟은 도 2와 같이 포맷을 갖는 CCFS 피드백 메시지 헤더를 나타낼 수 있다.

도 2는 일 실시예에 따른 CCFS 피드백 메시지 헤더를 나타낸다.

아래에서 각 필드에 대해 설명한다.

리포트 시간 (4 옥텟): 이러한 피드백 메시지가 생성된 시간일 수 있다. 리포트 시간의 값은 RTCP 송신기 리포트(Sender Report; SR) 패킷 내의 NTP 타임스탬프 필드를 생성하기 위해 사용된 동일한 월클럭(wallclock)으로부터 도출될 수 있다. 이것은 [RFC3550](Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <http://www.rfc-editor.org/info/rfc3550>)의 4 절에서 설명된 것과 같은, NTP 포맷 타임스탬프의 중간 32 비트로서 포맷될 수 있다. Rxer가 NTP를 사용하지 않으면, 이는 시스템 업 시간(system up time)과 같은 다른 측정치들로 교체될 수 있으나, 해당하는 Txer에 통지되어야 할 수 있다. 말하자면, 리포트 시간은 시스템 업 시간에 대응하는 값일 수 있고, 시스템의 부팅 시부터 모노크로닉하게(Monochronic) 증가하는 시간일 수 있다. 예컨대, 리포트 시간은 1000mec일 수 있다.

피드백 시퀀스 (2 옥텟): 피드백 메시지의 자체 시퀀스 넘버를 나타낼 수 있다. Txer는 피드백 시퀀스가 1씩 증가하더라도 보고된 패킷 시퀀스 넘버가 계속되지 않으면 순방향 경로의 패킷 손실 이벤트를 파악할 수 있다.

모니터링 시간 (2 옥텟): 피드백 메시지를 생성하기 위해 실제로 관찰되는 밀리초 듀레이션을 나타낼 수 있다. 일반적으로 이는 Txer에 의해 선호되는 시간이며 현재 피드백 인터벌 시간보다 크거나 같을 수 있다. 그러나, 피드백 정보를 구축하는 것이 MTU 크기보다 더 큰 메시지 크기를 야기하면 Rxer는 실제 모니터링 시간과 함께 피드백 메시지를 즉시 전송해야 할 수 있다. 따라서, 모니터링 시간은 현재의 Txer 선호 모니터 시간보다 더 작게 될 수 있다. 모니터링 시간은 예컨대, 100msec일 수 있다.

그 다음으로, 복수의 리포트 블록들이 따를 수 있다. 일 리포트 블록은 SSRC에 의해 식별되는 하나의 미디어 소스로부터 수신된 패킷들을 설명한다. 보고서 블록 크기는 고정되어 있지 않고 포맷은 도 3에서 도시된 것과 같다.

도 3은 일 실시예에 따른 CCFS 리포트 블록을 나타낸다.

아래에서 각 필드에 대해 설명한다.

미디어 소스의 SSRC (4 옥텟): 리포트할 RTP SSRC를 나타낼 수 있다.

총 리포트 패킷 카운트 (2 옥텟): 리포트 rtp 패킷들의 수를 나타낼 수 있다. 이러한 값이 0이면 리포트 블록의 나머지 필드들은 무시되어야 할 수 있다.

시작 시퀀스 번호 (2 옥텟): 리포트된 패킷들의 RTP 시퀀스 넘버를 시작할 수 있다. 이는 이어지는 첫 번째 Pkt-요소들의 시퀀스 넘버가 될 수 있다.

Pkt-요소 (1 또는 2 옥텟): 각 패킷에 대해 설명할 수 있다. Pkt-요소의 카운트는 총 리포트 패킷 카운트이며 이들은 RTP 시퀀스 넘버 순서로 정렬될 수 있다.

Pkt-요소 포맷은 도 4와 같이 나타낼 수 있다.

도 4는 일 실시예에 따른 CCFS　Pkt-요소를 나타낸다.

아래에서 각 필드에 대해 설명한다.

PEM (2 비트): 패킷-요소 모드를 나타낼 수 있다. 값에 따라 의미가 정의될 수 있다.

0: 패킷이 수신됨 및 명시적인 혼잡(explicit congestion)이 설정되지 않았거나 미지원됨(not set or unsupported)을 나타낼 수 있다.

1: 패킷이 수신됨 및 RTP 패킷의 IP 헤더의 ECN이 0x3임을 나타낼 수 있다.

2: 패킷이 수신됨 및 델타(delta)가 네거티브임을 나타낼 수 있다.

3: 패킷이 수신되지 않음. 3 PEM을 갖는 Pkt-요소의 크기는 1 바이트가 됨을 나타낼 수 있다.

X (1비트): 델타의 절대값이 31보다 더 크면 설정될 수 있다. 이러한 값이 설정되지 않으면, Pkt-요소의 크기는 1 바이트가 될 수 있다. 이러한 값이 설정되면 Pkt-요소의 크기는 2 바이트가 되고 델타 값은 DeltaB를 사용하여 계산되어야 한다.

델타 (5 또는 13 비트): 패킷 도달 인터벌 밀리초를 나타낼 수 있다. Pkt-요소가 첫 번째인 경우 델타는 모니터링 시작 시간으로부터의 인터벌이 될 수 있다. 모니터링 시작 시간은 리포트 시간으로부터 차감된 모니터링 시간일 수 있다. 나머지의 델타는 N-1 RTP 순차화된 패킷(이하 "N-1 RTP"라 함)과 N RTP 사이의 RTP 패킷의 도착 인터벌 시간이 될 수 있다.

Delta는 DeltaA와 DeltaB의 두 부분으로 구성된다. DeltaB는 X 비트가 설정된 경우에만 존재할 수 있다. DeltaB가 제공되지 않으면 델타 값은 DeltaA가 되므로 따라서 최대 델타 값은 31이 된다. DeltaB가 제공되면 델타 값은 ((DeltaA << 8) | DeltaB)로서 13 비트로 표현되고 따라서 최대 델타 값은 8191가 된다.

N RTP가 N-1 RTP 이전에 도착하면, N RTP의 델타는 음의 값이 되어야 한다. 이러한 경우, 델타는 절대 값을 나타내고 PEM은 0x2로 설정되어야 한다.

도 5는 일 실시예에 따른 CCFS 피드백 메시지의 포맷의 다른 예시를 나타낸다.

도 2 내지 도 4를 참조하여 설명된 전술된 기술적 특징들에 대한 설명은 도 5에 대해서도 그대로 적용될 수 있는 바, 중복되는 설명은 생략한다.

아래에서 각 필드에 대해 설명한다.

Txer/Rxer ID는 각각 송신기측 및 수신기측의 SSRC일 수 있다. 패킷 송신에 사용되는 Path를 하나로 가정할 때, 동일한 Path를 사용하는 패킷들은 동일한 Rxer ID(Txer ID)로 묶일 수 있다. 말하자면, Rxer ID(Txer ID)는 동일한 Path를 사용하는 인스턴스의 모음을 가리키는 ID일 수 있다.

아래에서는 리포트 블록의 필드들에 대해 설명한다.

리포트 시간(Report Time)은 시스템 업 타임을 나타낼 수 있다.

미디어 소스의 SSRC는 오디오 또는 비디오와 같은 콘텐츠의 패킷을 리포트하겠다는 것을 나타내는 부분일 수 있다.

리포트 패킷 카운트는 리포트되는 패킷의 카운트를 나타내는 값을 나타낼 수 있다. 이는 예컨대, 모니터링 시간 동안 받은 패킷의 수를 나타낼 수 있다. 엔드 시퀀스(end_seq)는 포함하는 리포트되는 패킷의 마지막 시퀀스 넘버를 나타낼 수 있다. L은 패킷의 손실 여부를 나타낼 수 있으며, 예컨대, 1은 손실을 0은 손실되지 않음(수신됨)을 나타낼 수 있다.

예컨대, 5개의 패킷이 리포트되는 경우 4번째에 해당하는 패킷이 손실된 경우에 있어서, 리포트 패킷 카운트는 5가 될 수 있고, 엔드 시퀀스는 5가 될 수 있다. 손실된 4번째 패킷에 대응하는 L은 1을 나타낼 수 있고 따라서 해당 패킷이 손실되었음이 식별될 수 있다.

ECN (Explicit Congestion Notification)은 라우터가 찍어주는 값일 수 있다.

ATO (Arrival Time Offset)는 리포트되는 패킷의 수신 시간의 상기 리포트 시간에 대한 상대적인 시간 거리를 나타낼 수 있다. 말하자면, 예컨대, 1000msec인 리포트 시간에 대한 990msec에 수신된 수신 패킷에 대한 시간 offset (10msec)을 ATO 로서 나타낼 수 있다.

설명된 바와 같이, 도 5의 피드백 메시지 포맷은 그 리포트 블록의 필드 구조에 있어서 도 3의 그것과 상이할 수 있다.

Rxer는 최근 수신된 RTP 패킷들에 기반하여 피드백 메시지를 작성할 수 있다. 하나의 Rxer는 복수의 RTP 스트림들을 종합한다. 때때로는 네트워크 상태에 따라 짧은 시간에 많은 패킷이 도착해야 할 수 있다. 이러한 사실은 CCFS 피드백 메시지 패킷을 크게 만들 수 있다. CCFS 피드백 메시지 크기가 MTU (Maximum Transmission Unit)에 의해 허용된 패킷 크기보다 큰 경우 예외 상황들이 야기될 수 있다. 따라서 실시예의 CCFS의 Rxer는 피드백 메시지 크기를 고려해야 한다. 즉, CCFS의 피드백 메시지 패킷의 크기는 MTU 크기보다 작아야 한다.

예컨대, 피드백 메시지 크기가 MTU에 의해 사용 가능한 크기에 근접하면, Rxer는 즉시 피드백 메시지를 전송해야 한다. 피드백 메시지 내의 모니터링 시간 값은 Txer 선호 모니터링 시간보다 더 짧게 될 것이다. 즉각적인 피드백 메시지를 전송한 후 Rxer는 다음 피드백에 대한 모니터링을 다시 시작해야 한다.

CCFS 피드백 메시지 크기는 아래 수학식 1에 따라 추정될 수 있다.

[수학식 1]

FBM-Size = 20 + 8R + 1.5T

R은 연관된 RTP 스트림 카운트를 의미할 수 있다. T는 전체 리포트 패킷 카운트를 의미할 수 있다. 1.5는 Pkt-요소의 가정된 평균 크기일 수 있으며, 정확한 값은 아닐 수 있다. 수학식 1에서는 구현의 단순성을 위해 상수 1.5이 사용되었다.

아래에서는, Rxer에서의 CCFS 제어 메시지들의 취급에 대해 설명한다.

CCFS 제어 메시지는 Txer에 의해 전송된 RTCP (RTP control Protocol) 메시지 유형일 수 있다. 이러한 RTCP 메시지들은 Txer가 특정 피처를 요구하는 경우 정의되어야 한다. Rxer가 이해할 수 있는 제어 메시지를 수신하면, Rxer 이에 따라 응답해야 한다. 그렇지 않다면, 수신된 메시지들은 무시되고 폐기되어야 한다.

아래에서는 송신기(Txer)에 대해 보다 자세하게 설명한다.

Txer는 rtp 스트림들에 관한 전송된 rtp 패킷 어레이(txed_rtps)를 유지할 수 있다. txed_rtps는 전송된 로컬 타임스탬프, 패킷 크기, RTP seq 번호 및 ssrc를 포함할 수 있다.

Txer는 Txer가 피드백 메시지를 수신하는 각 시간 동안 피드백 메시지가 수신될 때 변화하는 메트릭들을 추정할 수 있다. 이는 모든 추정된 메트릭들은 역방향 편도 지연 시간 이전의 과거의 것이지만 피드백 메시지의 네트워크 경로인 역방향 경로의 영향을 제거한다는 것을 의미한다.

Txer는 피드백 메시지와 txed_rtps를 사용하여 순방향 경로 대역폭, 큐 지연 시간 및 외부 트래픽들로부터의 큐 지연 시간 시간을 추정할 수 있다.

그리고, Txer는 메트릭들과 현재 상태에 기반하여 순방향 경로 상태와 타겟 전송 속도를 결정할 수 있다. 순방향 경로 상태는 4 가지 상태를 가지며 이에 관해서는 앞서 설명되었다. 실제로 이러한 상태는 전역적으로(globally) Txer의 로직에 영향을 줄 수 있다.

아래에서는 관련된 제약들(constants)에 대해 설명한다.

Txer 로직은 슈도 코드를 사용하여 설명된다. 간결성을 위해, 사용된 모든 예시적인 상수들이 여기에서 나열된다.

FwdBwEstWei = 0.9

I_FwdBwEstWei = (1.0 - FwdBwEstWei)

TargetQDelay = 50msec

WndBrFract = 1sec

TrigProbQDFractMax = 0.8

TrigProbBrFractMin = 1.0

TrigProbQMRangeMax = 10msec

TrigProbLossRtMax = 0.02

TrigProbECNRtMax = 0.0

TrigStopProbQDFractMin = 1.3

TrigStopProbBrFractMin = 1.2

TrigStopProbLossRtMax = 0.0

TrigStopProbECNRtMax = 0.0

TrigCompQDelayMin = 200msec

TrigCompQMRangeMi = 100msec

TrigStopCompQDelayMax = 100msec

TrigStopCompQMRangeMax = 20msec

TrigThroQDFractMin = 1.5

TrigThroBrFractMax = 0.9

Thro2CompQIncrTime = 1sec

DfltQDFractLow = 0.5

DfltQDFractHi = 1.1

DfltBrIncrRate = 1.01

DfltBrDecrRate = 0.95

CompTargetTxbwRate = 1.3

ThroTargetTxbwRate = 0.5

ProbingTime = 4sec

CompQDFractLow = 0.5

CompQDFractHi = 1.0

CompBrIncrRate = 1.02

Txer 상에서의 모니터링 시간에 대해 아래에서 설명한다.

Txer가 피드백 메시지를 수신할 때마다, Txer는 Rxer 상에서 모니터링 시간과 매치되는 모니터링 시간을 계산할 수 있다. 피드백 메시지 내의 최신의 최종 시퀀스(latest end sequence)는 Txer 상에서 모니터링 시간을 확인하기 위한 기본 시점(base point of time)이 된다.

[알고리즘 1]

(latest_end_seq, ssrc) = find_out(fbm)

sent_tstmp_end_seq = get_tstmp(txed_rtps, latest_end_seq, ssrc)

end_tstmp = sent_tstmp_end_seq + fbm.ato(latest_end_seq, ssrc)

bgn_tstmp = period_end_tmstmp - fbm.monitored_time

위의 알고리즘 1을 참조하면 fbm은 피드백 메시지를 나타내며 tstmp는 Txer의 타임스탬프에 해당할 수 있다. 먼저, 리포트된 것들 중에서 최신의 rtp 패킷의 전송된 로컬 타임스탬프(sent_tstmp_end_seq)를 확인하고, Txer 상에서의 모니터링 종료 시간은 ATO 시간 및 sent_tstmp_end_seq로서 설정할 수 있다.

아래에서는 순방향 경로 대역폭 추정 방법에 대해 설명한다.

순방향 경로의 대역폭은 Rxer 상에서 수신된 속도(rate)에 기반하여 추정된다. 예컨대, 아래 수학식 2에 기반하여 추정될 수 있다.

[수학식 2]

fwd_bw = tot_rxed_size / fbm.monitored_time

tot_rxed_size는 리포트된 ssrc 및 seq를 갖는 txed_rtps로부터 발견된 전송된 패킷 크기의 합일 수 있다. 손실된 패킷이 있다면, 이들은 제외되어야 한다. CCFS는 아웃라이어(outlier)를 제거하기 위해 이동 평균을 사용하여 fwd_bw로 esti_bw를 업데이트할 수 있다. 불행하게도, 이동 평균 계산은 시간 페널티를 야기할 수 있다. 또한, 너무 작거나 너무 큰 잘못된 추정 값이 사용되면 esti_bw에 부정적인 영향을 미치게 된다. 따라서 CCFS는 유효성 검사를 통해 노이즈를 최소화한다.

예컨대, esti_bw의 업데이트는 아래 알고리즘 2에 기반하여 수행될 수 있다.

[알고리즘 2]

if( status != Throttled &&

(status == Competing && target_bw < fwd_bw && lost == 0) &&

(sent_size > tot_rxed_size)

|| (sent_size == tot_rxed_size && target_bw < fwd_bw) )

esti_bw = FwdBwEstWei*esti_bw + I_FwdBwEstWei*fwd_bw

먼저, 스로틀드(throttled) 상태에서는 타겟 대역폭이 큐를 비우도록 줄어들어야 하므로 현재 상태는 스로틀드 상태가 아니어야 한다. 현재 상태가 컴피팅 상태이면, esti_bw는 특정 조건을 충족하는 경우에만 업데이트된다. 상태 확인 후, 전송된 비트레이트가 대략적으로 병목 대역폭이거나 또는 그 기간 동안 더 큰 대역폭을 의미하기 때문에 sent_size는 tot_rxed_size보다 더 크게 되어야 한다. 현재의 타겟 대역폭이 과소 평가되어 있는 경우 esti_bw가 업데이트된다.

아래에서는 큐 딜레이 추정 및 증가 패턴 발견 방법에 대해 설명한다.

CCFS는 예컨대, LEDBAT [RFC6817](Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, DOI 10.17487/RFC6817, December 2012, <http://www.rfc- editor.org/info/rfc6817>)의 큐 딜레이 추정을 사용하여 순방향 경로의 큐 딜레이를 추정할 수 있다. 그렇게 하기 위해, 수신된 타임스탬프는 피드백 메시지 내의 ATO 필드를 사용하여 각 패킷에 대해 계산되어야 한다. 큐 딜레이는 리포트된 패킷의 추정된 큐 딜레이들 중에서 최소 큐 딜레이가 될 수 있다.

큐 딜레이는 정확하게 될 수는 없지만. 그 상대적인 값과 패턴은 중요한 신호로 사용될 수 있다. 예컨대, CCFS는 아래의 알고리즘 3과 같이 큐 딜레이의 증가하는 패턴 및 듀레이션을 찾을 수 있다.

[알고리즘 3]

if( last_qdelay < qdelay )

incr_count++

if(incr_count == 1)

incr_start_tstmp = end_tstmp

incr_duration = end_tstmp - incr_start_tstmp;

if(incr_count >= 3 && duration >= IncrMinDuration)

is_increasing = true

else

incr_count = 0

incr_start_tstmp = 0

is_increasing = false

last_qdelay = qdelay

상기의 알고리즘 3은 우수한 퍼포먼스를 나타내는 것이라면 다른 것들로 대체될 수 있다.

아래에서는 전송 경로의 상태별 처리 방법에 대해 설명한다.

계산된 파라미터들에 기반하여 전송 속도(target_txbw)가 업데이트될 수 있다.

[수학식 3]

qd_fract = qdelay / target_qdelay

br_fract = recved_size_wnd / sent_size_중

상기 수학식 3은 상태를 확인하고 전송 속도를 제어하기 위해 사용되는 파라미터를 계산하는 방법을 나타낼 수 있다.

위의 두 분수들은 (전송 경로의) 상태를 확인하고 전송 속도를 제어하기 위해 직접 사용될 수 있다. recved_size_wnd는 마지막 윈도우 시간(WndBrFract)에 대한 총 수신된 패킷 크기를 의미하고 sent_size_wnd는 동일한 시간 동안 전송된 총 패킷 크기를 나타낼 수 있다.

전송 속도를 제어하기 전에, 특정 조건은 상태를 변경하도록 하고 CCFS는 이러한 조건을 제어 이벤트로서 정의할 수 있다. 제어 이벤트 목록 및 요구 조건이 아래 표 1에서 설명된다.

제어 이벤트(Control Event)	조건(Conditions)
CTRL_NOTHING	* default value
CTRL_START_COMPETE	1. qdelay > TrigCompQDelayMin && qmrange > TrigCompQMRangeMin 2. Throttled status && incr_duration > Thro2CompQIncrTime
CTRL_START_PROBING	status is not Probing&& is_increasing == false && qd_fract < TrigProbQDFractMax && br_fract >= TrigProbBrFractMin && qmrange < TrigProbQMRangeMax && ecn_rate < TrigProbECNRtMax && loss_rate < TrigProbLossRtMax
CTRL_DETECT_THROTTLE	is_increasing && qd_fract > QDFractMinTrigThro && br_fract < BrFractMaxTrigThro
CTRL_STOP_COMPETE	Competing status&& comp_duration > CompMaintainTime && qdelay < QDelayMaxTrigCompStop && qmrange < QMRangeTrigCompStop
CTRL_STOP_PROBING	1. Probing status && is_increasing 2. Probing status && qd_fract > TrigStopProbQDFractMin 3. Probing status && br_fract > TrigStopProbBrFractMin 4. Probing status && ecn_rate >= TrigStopProbECNRtMax 5. Probing status && loss_rate >= TrigStopProbLossRtMax
CTRL_RESOLV_THROTTLE	Throttled status && qdFract < 1.0

아래에서는 전송 경로의 상태별 제어 이벤트의 처리 방법에 대해 설명한다.CTRL_START_COMPETE 및 CTRL_DETECT_THROTTLE은 순방향 경로의 상태와 관계 없이 즉각적으로 반응하는 중요한 신호들일 수 있다. 따라서 추출된 핸들러는 예컨대, 아래의 알고리즘 4와 같이 설명될 수 있다.

[알고리즘 4]

do_start_compete():

target_qdelay = TargetQDelay + TargetXQDelay

target_txbw = esti_bw * CompTargetTxbwRate

status = Competing

return

do_detect_throttle():

thro_backup_target_txbw = esti_bw

target_txbw = esti_bw * ThroTargetTxbwRate

status = Throttled

return

각 상태에 대한 포괄적인 처리는 복잡해 보일 수 있다. 따라서, 본 개시에서는 도 6과 같은 간단한 사용 가능한 상태 변화 다이어그램으로 슈도 코드를 보완한다.

도 6은 일 실시예에 따른 상태들에 대한 상태 변화 다이어그램을 나타낸다.

아래 알고리즘 5 내지 8에서는 각 상태 별 제어 이벤트에 대한 처리에 대해 설명한다.

[알고리즘 5]

<디폴트 상태>

Event: CTRL_NOTHING

if(qd_fract < DfltQDFractLow && target_txbw < esti_bw)

target_txbw *= DfltBrIncrRate

else if(qd_fract > DfltQDFractHi)

target_txbw *= DfltBrDecrRate

Event: CTRL_START_PROBING

prob_backup_target_txrt = esti_bw

target_txbw = esti_bw + prob_bw

prob_start_tstmp = curr_tstmp

status = Probing

Event: CTRL_START_COMPETE

do_start_compete()

Event: CTRL_DETECT_THROTTLE

do_detect_throttle()

[알고리즘 6]

<컴피팅 상태>

Event: CTRL_NOTHING

if( qd_fract < CompQDFractLow || qd_fract < CompQDFractHi )

target_txrt *= CompBrIncrRate

Event: CTRL_SOTP_COMPETE

target_qdelay = TargetQDelay

status = Default

Event: CTRL_DETECT_THROTTLE

do_detect_throttle()

[알고리즘 7]

<프로빙 상태>

Event: CTRL_NOTHING

if(curr_tstmp - prob_start_tstmp > ProbingTime)

status = Default

target_txnw = prob_backup_target_txbw + prob_bw

Event: CTRL_STOP_PROBING

target_txbw = esti_bw

status = Default

Event: CTRL_START_COMPETE

do_start_compete()

Event: CTRL_DETECT_THROTTLE

do_detect_throttle()

[알고리즘 8]

<스로틀드 상태>

Event: CTRL_RESOLV_THROTTLE

target_txbw = thro_backup_target_txbw

status = Default

Event: CTRL_START_COMPETE

do_start_compete()

Event: CTRL_DETECT_THROTTLE

thro_backup_target_txbw = esti_bw

target_txbw = esti_bw * ThroTargetTxbwRate

도 7은 일 예에 따른 상태들에 대한 상태 변화 다이어그램을 나타낸다.

예컨대, 전송 경로의 상태가 디폴트 상태인 경우에 있어서 큐 딜레이가 상대적으로 낮은 값으로 소정의 시간 이상 지속될 경우 전송 경로의 상태는 프로빙 상태로 결정될 수 있다. 이 때, QMrange는 낮게 될 수 있다. 프로빙 상태는 망의 상태가 좋은 것(즉, 보낸 패킷이 모두 수신되는 것)을 나타내는 바, 전송 경로를 위한 타겟 전송 속도는 더 높게 결정될 수 있고 이에 따라 전송 속도가 제어될 수 있다.

프로빙 상태 또는 디폴트 상태에서 큐 딜레이가 상대적으로 높은 값으로 소정의 시간 이상 지속될 경우 전송 경로의 상태는 컴피팅 상태로 결정될 수 있다. 컴피팅 상태에서는 starvation이 발생하는 것을 방지하기 위해 타겟 전송 속도가 적당히 낮은 값(예컨대, 제한 전송 속도의 70% 정도)로 결정될 수 있고, 이에 따라 전송 속도가 제어될 수 있다.

프로빙 상태에서 큐 딜레이가 급격하게 증가하고 전송 경로의 대역폭이 감소하면 전송 경로의 상태는 스로틀드 상태로 결정될 수 있다. 이 때, QMrange는 높게 될 수 있다. 스로틀드 상태에서는 타겟 전송 속도가 상당히 낮은 값(예컨대, 제한 전송 속도의 50% 이하)로 결정될 수 있고 이에 따라 전송 속도가 제어될 수 있다.

이상 도 1 내지 도 6을 참조하여 전술된 기술적 특징들에 대한 설명은 도 7에 대해서도 그대로 적용될 수 있는 바, 중복되는 설명은 생략한다.

아래에서는 Txer 측에서의 CCFS 제어 메시지의 처리 동작에 대해 설명한다.

Txer가 Rxer의 도움이 필요한 특정 피처를 구현하려는 경우, Txer는 CCFS 제어 메시지들을 전송할 수 있다. CCFS 제어 메시지는 FMT = CCFSCTRL 값을 갖는 RTCP 메시지일 수 있다.

도 8은 일 실시예에 따른 제어 메시지 포맷을 나타낸다.

아래에서 각 필드에 대해 설명한다.

미디어 소스에 대한 SSRC는 Rxer Id로 대체될 수 있다.

제어 메시지 블록이 뒤따르며, 이는 복수가 될 수 있다. X 비트는 현재의 블록을 따르는 제어 메시지 블록이 존재함을 나타낼 수 있다.

CMT는 제어 메시지 값 유형이 사용되어야 하는 Rxer에 통지하는 제어 메시지 유형일 수 있다. Rxer가 CMT를 이해하지 못하면 Rxer는 이러한 메시지를 무시할 수 있다.

길이는 제어 메시지 값의 옥텟 크기를 나타낼 수 있다.

제어 메시지 값은 CMT 값에 따라 다르게 될 수 있다.

아래에서는 Txer 측에서 선호되는 피드백 인터벌 및 모니터링 시간을 업데이트하는 방법을 설명한다.

Txer는 필요하다면 피드백 인터벌을 변경할 수 있다. 이러한 메시지는 보장될(guaranteed) 필요가 없으므로 따라서 Rxer는 응답 메시지를 보내지 않을 것이다. 아래는 이러한 인터벌 시간의 변경의 예시를 나타낸다.

CMT: 1

Length: 2

또한, Txer는 필요하다면 모니터링 시간을 변경할 수 있다. 이러한 메시지는 보장될(guaranteed) 필요가 없으므로 따라서 Rxer는 응답 메시지를 보내지 않을 것이지만 적용된 피드백 메시지는 업데이트된 모니터링 필드 값을 가지게 될 것이다.

아래는 이러한 모니터링 시간의 변경의 예시를 나타낸다.

CMT: 2

Length: 2

Control Message Value: Monitoring time(msec)

실시예의 CCFS의 혼잡 제어 기술은, 다음과 같이 기존의 혼잡 제어 기술에 비해 이점을 가질 수 있다.

TCP의 Congestion Control(CC)는 TCP 스택 내의 혼잡 제어로서 지연을 짧게 유지하는 것이 목표가 아니며, 단지 망 내에 로스가 존재할 경우 트래픽을 줄여 로스를 피하도록 하는 것이다. TCP의 CC는 짧은 지연 시간을 고려 하지 않음에 비해, 실시예의 CCFS는 이를 고려할 수 있다.

또한, 실시예의 CCFS는 RMCAT 내의 CC 알고리즘들에 해당하는 NADA 및 SCReAM과 유사하게 송신기 주도의 혼잡 제어를 수행한다는 점에서 기존의 RTP 수신기를 그대로 사용할 수 있다는 장점이 있다. 또한, 실시예의 CCFS에서는 GCC, NADA 및 SCREeM에 비해, shaping buffer를 활용하는 혼잡 제어를 수행하지 않기 때문에 어플리케이션 수준에서의 서비스 지연 시간과 관련된 문제가 발생하지 않는다. 또한, 실시예의 CCFS는 GCC와 달리 코덱으로부터 발생한 데이터에 대해 비트 드롭(bit drop) 또는 패딩(padding)을 수행하지 않기 때문에 효율적으로 네트워크 자원을 활용할 수 있다.

또한, 실시예의 CCFS에서는 RTP 스트림의 전송 경로(forward path)와 역방향 경로(backward path)의 혼잡도가 독립적으로 고려됨으로써, 상기 기존 기술들에 비해 양방향 통신에서 우월한 성능을 나타낼 수 있다.

따라서, 실시예의 CCFS는 혼잡 제어를 위한 알고리즘 자체가 전송 경로(Forward path)가 아닌 피드백을 받는 경로(Backward path)의 네트워크 에러(impairment)에 취약하게 되는 문제점을 해결할 수 있다.

예컨대, 실시예의 CCFS에서는, 송신기(Txer 또는 Tx node)가 수신기(Rxer 또는 Rx node)의 피드백 메시지를 수신하여 네트워크의 상태를 추론함에 있어서, 계산의 시점을 피드백 메시지를 받은 시간(on Tx node)이 아니라 피드백 메시지의 전송 시간(by Rx node)으로 할 수 있다. 이를 통해, 피드백 메시지가 수신되는 역방향 경로의 에러(예컨대, 로스, 혼잡 등)에 인한 오판을 제거할 수 있다.

보다 상세한 따른 송신기-수신기 간의 패킷 및 피드백 패킷 메시지 전송 방법에 대해서는 후술될 도 9를 참조하여 더 자세하게 설명된다.

아래 도 10 내지 13은 전술된 실시예들과 관련된 예시적인 알고리즘들을 나타낸다. 본 개시 및 도면들을 참고하여 설명되는 알고리즘들은 슈도 코드를 나타낼 수 있다.

도 10은 일 예에 따른 FwdBW를 추정하는 방법을 나타내는 알고리즘이다. 예컨대, 도 10은 전송 경로(Forward path)의 병목 대역폭(bottlenecked bandwidth)을 결정하는 알고리즘을 나타낼 수 있다. 도 11은 일 예에 따른 스로틀드 상태와 관련된 이벤트를 처리하는 방법을 나타내는 알고리즘이다. 도 12는 일 예에 따른 컴피팅 상태와 관련된 이벤트를 처리하는 방법을 나타내는 알고리즘이다. 도 13은 일 예에 따른 프로빙 상태와 관련된 이벤트를 처리하는 방법을 나타내는 알고리즘이다.

도 14는 일 실시예에 따른 송신기 및 수신기의 내부 구성을 설명하기 위한 블록도이다.

도시된 송신기(1400)(Txer)는 전송 경로(Forward path)를 통해 수신기(1430)(Rxer)로 패킷(트래픽)을 전송하는 Tx node일 수 있다. 수신기(1430)는 송신기(1400)로부터 수신된 패킷에 대해 수신된 패킷을 리포트하기 위한 피드백 메시지를 생성하여 역방향 경로를 통해 송신기(1400)로 피드백 메시지를 전송하는 Rx node일 수 있다. 수신기(1430)는 주기적으로 피드백 메시지를 송신기(1400)로 전송할 수 있다. 송신기(1400)는 예컨대, 수신기(1430)로부터 피드백 메시지를 수신할 때마다 전송 경로의 대역폭(FwdBW) 및 전송 경로의 상태를 갱신할 수 있다. 전송 경로의 상태는 전술한 것처럼 스로틀드 상태, 컴피팅 상태, 프로빙 상태 및 디폴트 상태 중 어느 하나일 수 있다. 송신기(1400)는 결정된 대역폭을 비롯한 메트릭과 전송 경로의 상태에 기반하여 전송 경로를 위한 타겟 전송 속도를 결정하고, 전송 경로의 전송 속도를 제어할 수 있다.

말하자면, 실시예들에 따른 타겟 전송 속도 결정 방법은 송신기(1400)를 통해 구현될 수 있다. 또한, 실시예들에 따른 피드백 메시지를 전송하는 방법은 수신기(1430)를 통해 구현될 수 있다.

송신기(1400)는 실시예의 타겟 전송 속도 결정 방법을 실행하기 위한 구성요소로서 프로세서(1410) 및 메모리(1420)를 포함할 수 있다. 송신기(1400)는 하나 또는 그 이상의 컴퓨터 시스템들로 구성될 수도 있다. 송신기(1400)는 패킷과 같은 데이터를 송수신하기 위한 안테나와 같은 구성을 더 포함할 수 있다.

프로세서(1410)는 실시예의 타겟 전송 속도 결정 방법을 구현하기 위한 구성요소로서 명령어들의 시퀀스를 처리할 수 있는 임의의 장치를 포함하거나 그의 일부일 수 있다. 프로세서(1410)는 예를 들어 컴퓨터 프로세서, 이동 장치 또는 다른 전자 장치 내의 프로세서 및/또는 디지털 프로세서를 포함할 수 있다. 프로세서(1410)는 예를 들어, 서버 컴퓨팅 디바이스, 서버 컴퓨터, 일련의 서버 컴퓨터들, 서버 팜, 클라우드 컴퓨터, 컨텐츠 플랫폼 등에 포함될 수 있다. 프로세서(1410)는 예컨대, 버스(미도시)를 통해 메모리(1420)에 접속될 수 있다.

메모리(1420)는 송신기(1400)에 의해 사용되거나 그에 의해 출력되는 정보를 저장하기 위한 휘발성 메모리, 영구, 가상 또는 기타 메모리를 포함할 수 있다. 메모리(1420)는 예를 들어 랜덤 액세스 메모리(RAM: random access memory) 및/또는 다이내믹 RAM(DRAM: dynamic RAM)을 포함할 수 있다. 메모리(1420)는 송신기(1400)의 상태 정보와 같은 임의의 정보를 저장하는 데 사용될 수 있다. 메모리(1420)는 예를 들어, 실시예의 타겟 전송 속도 결정 방법의 수행을 위한 명령어들을 포함하는 송신기(1400)의 명령어들을 저장하는 데에도 사용될 수 있다. 송신기(1400)는 필요에 따라 또는 적절한 경우에 하나 이상의 프로세서(1410)를 포함할 수도 있다.

수신기(1430)와 수신기(1430)의 프로세서(1440) 및 메모리(1450)에 대해서는, 송신기(1400)와 송신기(1400)의 프로세서(1410) 및 메모리(1420)에 대해 설명된 것과 유사한 설명이 적용될 수 있으므로, 중복되는 설명은 생략한다.

말하자면, 수신기(1430)는 실시예의 피드백 메시지를 전송하는 방법을 실행하기 위한 구성요소로서 프로세서(1440) 및 메모리(1450)를 포함할 수 있다.

또는, 송신기(1400)와 수신기(1430)는 서로 동일하게 구현될 수 있으며, 이들 간의 패킷의 송수신에 따라, 송신기(1400)(또는 수신기(1430))는 송신기 및 수신기 둘 다로 동작할 수도 있다.

이상 도 1 내지 도 13을 참조하여 전술된 기술적 특징들에 대한 설명은 도 14에 대해서도 그대로 적용될 수 있는 바, 중복되는 설명은 생략한다.

도 15는 일 실시예에 따른 타겟 전송 속도 결정 방법을 나타내는 흐름도이다.

도 15를 참조하여, 송신기(1400) 측에서 수행되는 수신기(1430)로의 패킷 전송을 위한 전송 경로를 위한 타겟 전송 속도 결정 방법에 대해 설명한다. 설명의 편의상 송신기(1400)의 구성(들)에 의해 수행되는 동작은 송신기(1400)에 의해 수행되는 것으로 설명한다. 수신기(1430)에 대해서도 마찬가지이다.

단계(1510)에서, 송신기(1400)는 전송 경로를 통해 패킷을 수신기(1430)로 전송할 수 있다.

단계(1520)에서, 송신기(1400)는 수신기(1430)로부터, 송신기(1400)로부터 수신된 패킷에 관한 정보를 포함하는 피드백 메시지를 수신할 수 있다.

단계(1530)에서, 송신기(1400)는 수신된 피드백 메시지에 기반하여 전송 경로의 상태를 결정하기 위한 적어도 하나의 메트릭(metric)을 추정할 수 있다. 추정된 메트릭은 피드백 메시지가 전송되는 경로인 역방향 경로(Backward path)에 의한 영향이 제거된 전송 경로의 특성만을 반영하는 것일 수 있다. 예컨대, 송신기(1400)는 전송 경로의 대역폭(Forward Bandwidth)(예컨대, 병목 대역폭) 및 큐 딜레이(queue delay)를 포함하는 메트릭을 추정할 수 있다. 또한, 송신기(1400)는 큐 딜레이의 범위에 해당하는 메트릭(즉, QMrange)을 더 추정할 수 있다.

단계(1540)에서, 송신기(1400)는 추정된 메트릭에 기반하여 전송 경로의 상태를 결정할 수 있다. 결정된 전송 경로의 상태는 스로틀드 상태, 프로빙 상태, 컴피팅(competing) 상태 및 디폴트(default) 상태 중 하나일 수 있다. 예컨대, 머신러닝(machine learning)을 사용하여 전송 경로의 상태의 결정이 수행될 수도 있다.

단계(1550)에서, 송신기(1400)는 결정된 전송 경로의 상태에 기반하여 전송 경로를 위한 타겟 전송 속도를 결정할 수 있다.

단계(1560)에서, 송신기(1400)는 결정된 타겟 전송 속도로 송신기(1400)의 수신기(1430)로의 패킷의 전송 속도를 제어할 수 있다.

송신기(1400)는 결정된 전송 경로의 상태가 스로틀드 상태 또는 디폴트 상태이면, 송신기(1400)의 수신기(1430)로의 패킷의 전송 속도를 낮추어 큐(queue)를 비울 수 있도록 타겟 전송 속도를 결정할 수 있고 이에 따라 전송 경로의 전송 속도를 제어할 수 있다.

또는, 송신기(1400)는 결정된 전송 경로의 상태가 컴피팅 상태 또는 디폴트 상태이면, 큐 지연 시간(queue latency)이 타겟 큐 지연 시간(targeting queue latency) 내에서 유지되도록 타겟 전송 속도를 결정할 수 있고 이에 따라 전송 경로의 전송 속도를 제어할 수 있다.

또는, 송신기(1400)는 결정된 전송 경로의 상태가 프로빙 상태이면, 전송 경로의 병목 대역폭(bottlenecked bandwidth)을 탐지(prove)하기 위해 송신기(1400)의 수신기(1430)로의 패킷의 전송 속도를 증가시키도록 타겟 전송 속도를 결정할 수 있고 이에 따라 전송 경로의 전송 속도를 제어할 수 있다. 병목 대역폭은 예컨대, 전송 경로의 가용 대역폭 또는 전송 경로의 대역폭 한계에 대응할 수 있다.

단계(1570)에서, 송신기(1400)는, 필요한 경우, 수신기(1430) 측에 특정한 피처(feature)를 요청하기 위한 제어 메시지를 전송할 수 있다. 제어 메시지가 수신기(1430)가 이해할 수 있는 메시지 타입을 갖는 경우, 제어 메시지에 대한 응답을 수신기(1430)로부터 수신할 수 있다. 도시된 것과는 달리 단계(1570)는 단계(1510) 이전에 수행될 수도 있다.

전송 경로의 상태에 대해 보다 자세하게 설명하면, 스로틀드 상태는 송신기(1400)의 수신기(1430)로의 패킷의 전송 속도가 전송 경로의 대역폭 한계(bw limitation)보다 더 큰 상태를 나타낼 수 있다. 즉, 스로틀드 상태는 큐가 쌓여있는 상태를 나타낼 수 있다. 컴피팅 상태는 크로스 트래픽이 검출된 상태를 나타낼 수 있다. 프로빙 상태는 송신기(1400)의 수신기(1430)로의 패킷의 전송 속도가 상기 대역폭 한계 미만인 상태를 나타낼 수 있다. 즉, 프로빙 상태는 전송 경로의 병목 대역폭이 추정된 대역폭보다 더 큰 경우에 해당할 수 있다. 디폴트 상태는 나머지 3가지의 상태에 해당하지 않는 전송 경로의 상태를 나타낼 수 있다.

도 7을 참조하여 전술한 것처럼, 추정된 큐 딜레이가 상대적으로 낮은 값(예컨대, 소정의 제1 기준 값)으로 소정의 제1 시간 이상 지속될 경우 전송 경로의 상태는 프로빙 상태로 결정될 수 있다. 또는, 큐 딜레이가 상대적으로 높은 값(예컨대, 소정의 제2 기준 값)으로 소정의 제2 시간 이상 지속될 경우 전송 경로의 상태는 컴피팅 상태로 결정될 수 있다. 한편, 큐 딜레이가 급격하게 증가(또한, QMrange 역시 급격하게 증가)하고 전송 경로의 대역폭이 감소하는 것으로 추정되면 전송 경로의 상태는 스로틀드 상태로 결정될 수 있다.

단계(1520)에서 피드백 메시지는 주기적으로 수신될 수 있다. 예컨대, 피드백 메시지는 소정의 인터벌 시간(전술된 피드백 인터벌 시간) 마다 수신될 수 있다. 송신기(1400)는 이러한 피드백 메시지가 수신될 때마다 전송 경로의 대역폭(Forward Bandwidth)을 포함하는 메트릭을 추정할 수 있다. 피드백 인터벌 시간은 송신기(1400) 측에서 설정될 수 있다. 피드백 메시지를 생성함에 있어서 관찰하는 지속시간에 해당하는 모니터링 시간 또한 송신기(1400) 측에서 설정될 수 있다. 모니터링 시간은 피드백 인터벌 시간보다 크거나 같게 설정될 수 있다.

타겟 전송 속도는 예컨대, 아래의 수학식 4 내지 7에 기반하여 결정될 수 있다. 일례로, 결정된 전송 경로의 상태가 컴피팅 상태이면 수학식 4에 따라 결정된 타겟 대역폭에 따라 타겟 전송 속도가 결정될 수 있다.

[수학식 4]

타겟 대역폭(targetbr) = 추정된 전송 경로의 대역폭(forwardbw) * N%

N은, 예컨대, 50 초과 100 미만의 실수일 수 있다.

결정된 전송 경로의 상태가 스로틀드 상태이면 수학식 5에 따라 결정된 타겟 대역폭에 따라 상기 타겟 전송 속도를 결정할 수 있다.

[수학식 5]

타겟 대역폭(targetbr) = 추정된 전송 경로의 대역폭(forwardbw) * 0.5

결정된 전송 경로의 상태가 프로빙 상태이면 수학식 6에 따라 결정된 타겟 대역폭에 따라 상기 타겟 전송 속도를 결정할 수 있다.

[수학식 6]

타겟 대역폭(targetbr) = 추정된 전송 경로의 대역폭(forwardbw) * (1+알파)

알파는 0 초과의 실수일 수 있다.

결정된 전송 경로의 상태가 디폴트 상태이면 추정된 전송 경로의 대역폭에 해당하는 타겟 대역폭에 따라 타겟 전송 속도를 결정할 수 있다(아래 수학식 7 참조).

[수학식 7]

타겟 대역폭(targetbr) = 추정된 전송 경로의 대역폭(forwardbw)

도 1을 참조하여 전술한 것처럼, 수신된 피드백 메시지는 RTCP 헤더, 상기 수신기 측의 식별자(Rxer ID), 송신기 측의 식별자(Txer ID), 피드백 메시지 헤더 및 리포트되는 패킷에 관한 데이터를 포함하는 리포트 블록을 포함할 수 있다.

도 2 및 3을 참조하여 전술된 것처럼 피드백 메시지 헤더는 리포트 시간(Report Time) 필드, 피드백 시퀀스 필드 및 모니터링 시간(Monitored Time) 필드를 포함할 수 있다. 리포트 시간 필드는 송신기(1400)의 시스템 업 시간(system up time)을 리포트 시간으로서 나타내는 값을 포함하고, 피드백 시퀀스 필드는 피드백 시퀀스의 시퀀스 넘버를 나타내는 값을 포함하고, 모니터링 시간 필드는 피드백 메시지를 생성하기 위해 관찰하는 지속 시간(duration)을 모니터링 시간으로서 나타내는 값을 포함할 수 있다.

도 4를 참조하여 전술된 것처럼, 리포트 블록은 리포트되는 패킷의 SSRC를 나타내는 값을 포함하는 SSRC 필드, 리포트되는 패킷의 카운트를 나타내는 값을 포함하는 리포트 패킷 카운트 필드, 리포트되는 패킷의 시작 시퀀스 넘버를 나타내는 값을 포함하는 스타트 시퀀스 넘버 필드, 리포트되는 각 패킷에 대한 정보를 나타내는 값을 포함하는 Pkt-요소(Pkt-Element) 필드를 포함할 수 있다.

또는, 도 5를 참조하여 전술된 것처럼, 리포트 블록은 리포트되는 패킷의 SSRC를 나타내는 값을 포함하는 SSRC 필드, 리포트되는 패킷의 카운트를 나타내는 값을 포함하는 리포트 패킷 카운트 필드, 리포트되는 패킷의 마지막 시퀀스 넘버를 나타내는 값을 포함하는 엔드 시퀀스(end_seq) 필드, 패킷의 손실 여부를 나타내는 값을 포함하는 L 필드 및 리포트되는 패킷의 수신 시간의 상기 리포트 시간에 대한 상대적인 시간 거리를 나타내는 값을 포함하는 ATO (Arrival Time Offset) 필드를 포함할 수 있다.

송신기(1400)는 피드백 메시지의 리포트 시간 및 엔드 시퀀스 필드의 값에 기반하여, 엔드 시퀀스 필드의 값에 대응하는 패킷의 전송 이후로부터 피드백 메시지의 수신 전까지 송신기(1400)로부터 전송되는 패킷은 전송 경로의 상태를 결정하기 위한 메트릭의 추정에 있어서 고려하지 않을 수 있다. 예컨대, 도 9를 참조하여 설명하면, 피드백 메시지가 송신된 시점 이후에 송신기(1400)로부터 수신기(1430)로 전송되는 패킷들(910)은 전송 경로의 상태를 결정하기 위한 메트릭의 추정에 있어서 고려되지 않을 수 있다. 말하자면, 패킷들(910)과 같은 피드백 메시지가 송신된 시점 이후에 송신되는 임플라이드(implied) 패킷들은 전송 경로의 상태를 결정함에 있어서 사용되지 않을 수 있다.

따라서, 송신기(1400)가 추정하는 메트릭은 피드백 메시지가 전송되는 경로인 역방향 경로(Backward path)에 의한 영향이 제거된 전송 경로의 특성만을 반영할 수 있게 될 수 있다. 실시예에서는, 송신기(1400) 측에서 피드백 메시지를 수신한 시간(시점)이 아닌, 수신기(1430) 측에서 피드백 메시지를 전송한 시간(시점)을 기준으로 메트릭이 추정되고 전송 경로의 상태가 결정될 수 있다.

송신기(1400)는 엔드 시퀀스 필드의 값에 대응하는 패킷의 전송 이후에 엔드 시퀀스 필드의 값에 대응하는 패킷의 ATO 필드의 값에 대응하는 시간 동안 상기 송신기(1400)로부터 전송되는 패킷은 전송 경로의 상태를 결정하기 위한 메트릭의 추정에 있어서 고려할 수 있다. 예컨대, 도 9를 참조하여 설명하면, 피드백 메시지의 엔드 시퀀스(end_seq)에 해당하는 패킷이 패킷 200이고 패킷 200의 ATO가 5msec인 경우, 패킷 200이 송신기(1400)로부터 전송된 후 5msec 내에 패킷 201이 수신기(1430)로 전송될 수 있다. 이러한 패킷 201은 송신기(1400)의 전송 경로에 대한 타겟 전송 속도를 계산함에 있어서 고려될 수 있다. 따라서, 보다 정확한 전송 경로의 상태 및 전송 경로에 대한 타겟 전송 속도의 결정이 가능하게 될 수 있다.

이상 도 1 내지 도 14를 참조하여 전술된 기술적 특징들에 대한 설명은 도 15에 대해서도 그대로 적용될 수 있는 바, 중복되는 설명은 생략한다.

도 16은 일 실시예에 따른 전송 경로의 상태를 결정하기 위한 메트릭을 추정하는 방법을 나타내는 흐름도이다.

도 15를 참조하여 전술된 단계(1530)는 후술될 단계들(1610 내지 1650)을 더 포함할 수 있다.

단계(1610)에서, 송신기(1400)는 수신된 피드백 메시지의 유효성(validation)을 검사(check)할 수 있다. 예컨대, 송신기(1400)는 시퀀스 넘버 등과 같은 피드백 메시지의 필드를 검사할 수 있다.

단계(1620)에서, 송신기(1400)는 피드백 메시지를 파싱할 수 있다.

단계(1630)에서, 송신기(1400)는 피드백 메시지에 포함된 데이터(즉, 필드에 포함된 데이터)에 기반하여, 송신기(1400)가 송신한 패킷의 크기에 대한 상기 수신기가 수신한 패킷의 크기의 비에 대응하는 비트레이트 프랙션(brFraction)을 획득할 수 있다. 비트레이트 프랙션은 Rxbitrate/Txbitrate(즉, 수신한 패킷 바이트/송신한 패킷 바이트)에 기반하여 계산될 수 있다.

단계(1640)에서, 송신기(1400)는 획득된 비트레이트 프랙션에 기반하여 상기 전송 경로의 대역폭(FwdBW)을 추정할 수 있다. 추정되는 대역폭은 전송 경로의 병목 대역폭일 수 있다.

단계(1650)에서, 송신기(1400)는 전송 경로에 대한 큐 딜레이(QDelay) 및 큐 딜레이의 범위에 해당하는 QMrange를 추정할 수 있다. 큐 딜레이는 예컨대, LEDBAT을 사용하여 추정될 수 있다. QMrange은 예컨대, minimum subtraction 기법에 의해 추정될 수 있다.

송신기(1400)는 전송 경로의 상태를 결정하기 위해 정의된 이벤트와, 상기 추정된 전송 경로의 대역폭, 큐 딜레이 또는 Q 딜레이의 범위 중 적어도 하나에 기반하여 전송 경로의 상태를 결정할 수 있고, 이에 따라 타겟 전송 속도를 결정할 수 있다.

이상 도 1 내지 도 15를 참조하여 전술된 기술적 특징들에 대한 설명은 도 16에 대해서도 그대로 적용될 수 있는 바, 중복되는 설명은 생략한다.

도 17은 일 실시예에 따른 피드백 메시지를 전송하는 방법을 나타내는 흐름도이다.

도 17을 참조하여, 수신기(1430)가 피드백 메시지를 생성하여 송신기(1400)로 전송하는 방법에 대해 설명한다.

단계(1710)에서, 수신기(1430)는 송신기(1400)로부터 패킷을 수신할 수 있다.

단계(1720)에서, 수신기(1430)는 소정의 모니터링 시간 동안 송신기(1400)로부터 수신된 패킷에 대한 정보를 포함하는 피드백 메시지를 생성할 수 있다. 피드백 메시지의 포맷과 관련하여 중복되는 설명은 생략한다.

단계(1730)에서, 소정의 피드백 인터벌 시간에 따라 주기적으로 피드백 메시지를 송신기(1400)로 전송할 수 있다.

단계(1740)에서, 수신기(1430)는 송신기(1400)로부터 수신기(1430) 측에 특정한 피처를 요청하기 위한 제어 메시지를 수신할 수 있다.

단계(1750)에서, 수신기(1430)는 수신된 제어 메시지가 수신기(1430)가 이해할 수 있는 메시지 타입을 갖는 경우에 제어 메시지에 대해 응답할 수 있다. 제어 메시지가 수신기가 이해할 수 있는 메시지 타입을 갖지 않으면 수신기(1430)는 수신된 제어 메시지를 무시하거나 폐기할 수 있다. 도시된 것과는 달리 단계(1740 및 1750)는 단계(1710) 이전에 수행될 수도 있다.

수신기(1430)는 소정의 모니터링 시간이 경과하기 전에 상기 생성된 피드백 메시지의 크기가 MTU (Maximum Transmission Unit)에 의해 허용되는 크기에 근접하면(예컨대, 피드백 메시지의 크기가 MTU에 의해 허용되는 크기를 초과할 것으로 예측되거나 소정의 크기에 도달한 경우), 생성된(즉, 생성 중인) 피드백 메시지를 해당 모니터링 시간이 경과하기 전에 송신기(1400)로 전송할 수 있다.

수신기(1430)는 이러한 피드백 메시지가 전송된 후 다음의 피드백 메시지를 생성하기 위한 모니터링을 시작할 수 있다.

말하자면, 수신기(1430)는 다음의 피드백 인터벌 시간이 도달하기 전이라도 피드백 메시지의 크기에 송신기(1400)에 피드백 메시지를 송신할 수 있다.

이상 도 1 내지 도 16을 참조하여 전술된 기술적 특징들에 대한 설명은 도 17에 대해서도 그대로 적용될 수 있는 바, 중복되는 설명은 생략한다.

이상에서 설명된 장치는 하드웨어 구성요소, 소프트웨어 구성요소, 및/또는 하드웨어 구성요소 및 소프트웨어 구성요소의 조합으로 구현될 수 있다. 예를 들어, 실시예들에서 설명된 장치 및 구성요소는, 프로세서, 콘트롤러, ALU(arithmetic logic unit), 디지털 신호 프로세서(digital signal processor), 마이크로컴퓨터, FPGA(field programmable gate array), PLU(programmable logic unit), 마이크로프로세서, 또는 명령(instruction)을 실행하고 응답할 수 있는 다른 어떠한 장치와 같이, 하나 이상의 범용 컴퓨터 또는 특수 목적 컴퓨터를 이용하여 구현될 수 있다. 처리 장치는 운영 체제(OS) 및 상기 운영 체제 상에서 수행되는 하나 이상의 소프트웨어 어플리케이션을 수행할 수 있다. 또한, 처리 장치는 소프트웨어의 실행에 응답하여, 데이터를 접근, 저장, 조작, 처리 및 생성할 수도 있다. 이해의 편의를 위하여, 처리 장치는 하나가 사용되는 것으로 설명된 경우도 있지만, 해당 기술분야에서 통상의 지식을 가진 자는, 처리 장치가 복수 개의 처리 요소(processing element) 및/또는 복수 유형의 처리 요소를 포함할 수 있음을 알 수 있다. 예를 들어, 처리 장치는 복수 개의 프로세서 또는 하나의 프로세서 및 하나의 콘트롤러를 포함할 수 있다. 또한, 병렬 프로세서(parallel processor)와 같은, 다른 처리 구성(processing configuration)도 가능하다.

소프트웨어는 컴퓨터 프로그램(computer program), 코드(code), 명령(instruction), 또는 이들 중 하나 이상의 조합을 포함할 수 있으며, 원하는 대로 동작하도록 처리 장치를 구성하거나 독립적으로 또는 결합적으로(collectively) 처리 장치를 명령할 수 있다. 소프트웨어 및/또는 데이터는, 처리 장치에 의하여 해석되거나 처리 장치에 명령 또는 데이터를 제공하기 위하여, 어떤 유형의 기계, 구성요소(component), 물리적 장치, 컴퓨터 저장 매체 또는 장치에 구체화(embody)될 수 있다. 소프트웨어는 네트워크로 연결된 컴퓨터 시스템 상에 분산되어서, 분산된 방법으로 저장되거나 실행될 수도 있다. 소프트웨어 및 데이터는 하나 이상의 컴퓨터 판독 가능 기록 매체에 저장될 수 있다.

실시예에 따른 방법은 다양한 컴퓨터 수단을 통하여 수행될 수 있는 프로그램 명령 형태로 구현되어 컴퓨터 판독 가능 매체에 기록될 수 있다. 이때, 매체는 컴퓨터로 실행 가능한 프로그램을 계속 저장하거나, 실행 또는 다운로드를 위해 임시 저장하는 것일 수도 있다. 또한, 매체는 단일 또는 수 개의 하드웨어가 결합된 형태의 다양한 기록수단 또는 저장수단일 수 있는데, 어떤 컴퓨터 시스템에 직접 접속되는 매체에 한정되지 않고, 네트워크 상에 분산 존재하는 것일 수도 있다. 매체의 예시로는, 하드 디스크, 플로피 디스크 및 자기 테이프와 같은 자기 매체, CD-ROM 및 DVD와 같은 광기록 매체, 플롭티컬 디스크(floptical disk)와 같은 자기-광 매체(magneto-optical medium), 및 ROM, RAM, 플래시 메모리 등을 포함하여 프로그램 명령어가 저장되도록 구성된 것이 있을 수 있다. 또한, 다른 매체의 예시로, 어플리케이션을 유통하는 앱 스토어나 기타 다양한 소프트웨어를 공급 내지 유통하는 사이트, 서버 등에서 관리하는 기록매체 내지 저장매체도 들 수 있다.

이상과 같이 실시예들이 비록 한정된 실시예와 도면에 의해 설명되었으나, 해당 기술분야에서 통상의 지식을 가진 자라면 상기의 기재로부터 다양한 수정 및 변형이 가능하다. 예를 들어, 설명된 기술들이 설명된 방법과 다른 순서로 수행되거나, 및/또는 설명된 시스템, 구조, 장치, 회로 등의 구성요소들이 설명된 방법과 다른 형태로 결합 또는 조합되거나, 다른 구성요소 또는 균등물에 의하여 대치되거나 치환되더라도 적절한 결과가 달성될 수 있다.

그러므로, 다른 구현들, 다른 실시예들 및 특허청구범위와 균등한 것들도 후술하는 특허청구범위의 범위에 속한다.

Claims

송신기(transmitter) 측에서 수행되는, 수신기로의 패킷 전송을 위한 전송 경로(Forward path)를 위한 타겟 전송 속도 결정 방법에 있어서,
상기 수신기로부터, 상기 송신기로부터 수신된 패킷에 관한 정보를 포함하는 피드백 메시지를 수신하는 단계;
상기 수신된 피드백 메시지에 기반하여 상기 전송 경로의 상태를 결정하기 위한 적어도 하나의 메트릭(metric)을 추정하는 단계;
상기 추정된 메트릭에 기반하여 상기 전송 경로의 상태를 결정하는 단계; 및
상기 전송 경로의 상태에 기반하여 상기 전송 경로를 위한 타겟 전송 속도를 결정하는 단계
를 포함하고,
상기 추정된 메트릭은 상기 피드백 메시지가 전송되는 경로인 역방향 경로(Backward path)에 의한 영향이 제거된 상기 전송 경로의 특성만을 반영하는 것인, 타겟 전송 속도 결정 방법.
제1항에 있어서,
상기 결정된 타겟 전송 속도로 상기 송신기의 상기 수신기로의 패킷의 전송 속도를 제어하는 단계
를 더 포함하는, 타겟 전송 속도 결정 방법.
제1항에 있어서,
상기 결정된 전송 경로의 상태는 스로틀드(throttled) 상태, 프로빙(probing) 상태, 컴피팅(competing) 상태 및 디폴트(default) 상태 중 하나이고,
상기 타겟 전송 속도를 결정하는 단계는,
상기 결정된 전송 경로의 상태가 스로틀드 상태이면, 상기 송신기의 상기 수신기로의 패킷의 전송 속도를 낮추어 큐(queue)를 비울 수 있도록 상기 타겟 전송 속도를 결정하고,
상기 결정된 전송 경로의 상태가 컴피팅 상태 또는 디폴트 상태이면, 큐 지연 시간(queue latency)이 타겟 큐 지연 시간(targeting queue latency) 내에서 유지되도록 상기 타겟 전송 속도를 결정하고,
상기 결정된 전송 경로의 상태가 프로빙 상태이면, 상기 전송 경로의 병목 대역폭(bottlenecked bandwidth)을 탐지(prove)하기 위해 상기 송신기의 상기 수신기로의 패킷의 전송 속도를 증가시키도록 상기 타겟 전송 속도를 결정하는, 타겟 전송 속도 결정 방법.
제3항에 있어서,
상기 스로틀드(throttled) 상태는 상기 송신기의 상기 수신기로의 패킷의 전송 속도가 상기 전송 경로의 대역폭 한계(bw limitation)보다 더 큰 상태를 나타내고,
상기 컴피팅 상태는 크로스 트래픽이 검출된 상태를 나타내고,
상기 프로빙 상태는 상기 송신기의 상기 수신기로의 패킷의 전송 속도가 상기 대역폭 한계 미만인 상태를 나타내고,
상기 디폴트 상태는 상기 스로틀드 상태, 상기 프로빙 상태, 또는 상기 컴피팅 상태에 해당하지 않는 상기 전송 경로의 상태를 나타내는, 타겟 전송 속도 결정 방법.
제1항에 있어서,
상기 메트릭을 추정하는 단계는 상기 전송 경로의 대역폭(Forward Bandwidth) 및 큐 딜레이(queue delay)를 포함하는 상기 메트릭을 추정하는, 타겟 전송 속도 결정 방법.
제3항에 있어서,
상기 피드백 메시지는 주기적으로 수신되고,
상기 메트릭을 추정하는 단계는 상기 전송 경로의 대역폭(Forward Bandwidth) 및 큐 딜레이를 포함하는 상기 메트릭을 추정하고,
상기 큐 딜레이가 상대적으로 낮은 값으로 소정의 제1 시간 이상 지속될 경우 상기 전송 경로의 상태는 프로빙 상태로 결정되고,
상기 큐 딜레이가 상대적으로 높은 값으로 소정의 제2 시간 이상 지속될 경우 상기 전송 경로의 상태는 컴피팅 상태로 결정되고,
상기 큐 딜레이가 급격하게 증가하고 상기 전송 경로의 대역폭이 감소하면 상기 전송 경로의 상태는 스로틀드 상태로 결정되는, 타겟 전송 속도 결정 방법.
제3항에 있어서,
상기 피드백 메시지는 주기적으로 수신되고,
상기 메트릭을 추정하는 단계는 상기 전송 경로의 대역폭(Forward Bandwidth)을 포함하는 상기 메트릭을 추정하고,
상기 타겟 전송 속도를 결정하는 단계는,
상기 결정된 상기 전송 경로의 상태가 컴피팅 상태이면 수학식 1에 따라 결정된 타겟 대역폭에 따라 상기 타겟 전송 속도를 결정하고,
[수학식 1]
타겟 대역폭 = 추정된 전송 경로의 대역폭 * N%
N은 50 초과 100 미만의 실수이고,
상기 결정된 상기 전송 경로의 상태가 스로틀드 상태이면 수학식 2에 따라 결정된 타겟 대역폭에 따라 상기 타겟 전송 속도를 결정하고,
[수학식 2]
타겟 대역폭 = 추정된 전송 경로의 대역폭 * 0.5
상기 결정된 상기 전송 경로의 상태가 프로빙 상태이면 수학식 3에 따라 결정된 타겟 대역폭에 따라 상기 타겟 전송 속도를 결정하고,
[수학식 3]
타겟 대역폭 = 추정된 전송 경로의 대역폭 * (1+알파)
상기 알파는 0 초과의 실수이고,
상기 결정된 상기 전송 경로의 상태가 디폴트 상태이면 상기 추정된 전송 경로의 대역폭에 해당하는 타겟 대역폭에 따라 상기 타겟 전송 속도를 결정하는, 타겟 전송 속도 결정 방법.
제1항에 있어서,
상기 메트릭을 추정하는 단계는,
상기 수신된 피드백 메시지의 유효성(validation)을 검사(check)하는 단계;
상기 피드백 메시지를 파싱하는 단계;
상기 피드백 메시지에 포함된 데이터에 기반하여, 상기 송신기가 송신한 패킷의 크기에 대한 상기 수신기가 수신한 패킷의 크기의 비에 대응하는 비트레이트 프랙션(brFraction)을 획득하는 단계;
상기 비트레이트 프랙션에 기반하여 상기 전송 경로의 대역폭을 추정하는 단계; 및
상기 전송 경로에 대한 큐 딜레이(QDelay) 및 Q 딜레이의 범위(QMrange)를 추정하는 단계
를 포함하고,
상기 전송 경로의 상태를 결정하는 단계는,
상기 전송 경로의 상태를 결정하기 위해 정의된 이벤트와, 상기 추정된 전송 경로의 대역폭, 큐 딜레이 또는 큐 딜레이의 범위 중 적어도 하나에 기반하여 상기 전송 경로의 상태를 결정하는, 타겟 전송 속도 결정 방법.
제1항에 있어서,
상기 피드백 메시지는 RTCP 헤더, 상기 수신기 측의 식별자(Rxer ID), 상기 송신기 측의 식별자(Txer ID), 피드백 메시지 헤더 및 리포트되는 패킷에 관한 데이터를 포함하는 리포트 블록을 포함하는, 타겟 전송 속도 결정 방법.
제9항에 있어서,
상기 피드백 메시지 헤더는 리포트 시간(Report Time) 필드, 피드백 시퀀스 필드 및 모니터링 시간(Monitored Time) 필드를 포함하고,
상기 리포트 시간 필드는 상기 송신기의 시스템 업 시간(system up time)을 리포트 시간으로서 나타내는 값을 포함하고,
상기 피드백 시퀀스 필드는 상기 피드백 시퀀스의 시퀀스 넘버를 나타내는 값을 포함하고,
상기 모니터링 시간 필드는 상기 피드백 메시지를 생성하기 위해 관찰하는 지속 시간(duration)을 모니터링 시간으로서 나타내는 값을 포함하는, 타겟 전송 속도 결정 방법.
제9항에 있어서,
상기 리포트 블록은 리포트되는 패킷의 SSRC를 나타내는 값을 포함하는 SSRC 필드, 리포트되는 패킷의 카운트를 나타내는 값을 포함하는 리포트 패킷 카운트 필드, 리포트되는 패킷의 마지막 시퀀스 넘버를 나타내는 값을 포함하는 엔드 시퀀스(end_seq) 필드, 패킷의 손실 여부를 나타내는 값을 포함하는 L 필드 및 리포트되는 패킷의 수신 시간의 상기 리포트 시간에 대한 상대적인 시간 거리를 나타내는 값을 포함하는 ATO (Arrival Time Offset) 필드를 포함하는, 타겟 전송 속도 결정 방법.
제9항에 있어서,
상기 리포트 블록은 리포트되는 패킷의 SSRC를 나타내는 값을 포함하는 SSRC 필드, 리포트되는 패킷의 카운트를 나타내는 값을 포함하는 리포트 패킷 카운트 필드, 리포트되는 패킷의 시작 시퀀스 넘버를 나타내는 값을 포함하는 스타트 시퀀스 넘버 필드, 리포트되는 각 패킷에 대한 정보를 나타내는 값을 포함하는 Pkt-요소(Pkt-Element) 필드를 포함하는, 타겟 전송 속도 결정 방법.
제11항에 있어서
상기 리포트 시간 및 상기 엔드 시퀀스 필드의 값에 기반하여, 상기 엔드 시퀀스 필드의 값에 대응하는 패킷의 전송 이후로부터 상기 피드백 메시지의 수신 전까지 상기 송신기로부터 전송되는 패킷은 상기 메트릭의 추정에 있어서 고려되지 않는, 타겟 전송 속도 결정 방법.
제11항에 있어서,
상기 엔드 시퀀스 필드의 값에 대응하는 패킷의 전송 이후에 상기 엔드 시퀀스 필드의 값에 대응하는 패킷의 ATO 필드의 값에 대응하는 시간 동안 상기 송신기로부터 전송되는 패킷은 상기 메트릭의 추정에 있어서 고려되는, 타겟 전송 속도 결정 방법.
제1항에 있어서,
상기 송신기 측에서 상기 피드백 메시지를 수신한 시간이 아닌, 상기 수신기 측에서 상기 피드백 메시지를 전송한 시간을 기준으로 상기 메트릭이 추정되고, 상기 전송 경로의 상태가 결정되는, 타겟 전송 속도 결정 방법.
제1항에 있어서,
상기 수신기 측에 특정한 피처(feature)를 요청하기 위한 제어 메시지를 전송하는 단계
를 더 포함하고,
상기 제어 메시지는 상기 수신기가 이해할 수 있는 메시지 타입을 갖는 경우에 상기 수신기로부터 응답이 이루어지는, 타겟 전송 속도 결정 방법.
제1항에 있어서,
상기 피드백 메시지는 소정의 피드백 인터벌 시간에 따라 주기적으로 수신되고,
상기 피드백 인터벌 시간은 상기 송신기 측에서 설정되고,
상기 피드백 메시지를 생성함에 있어서 관찰하는 지속시간에 해당하는 모니터링 시간은 송신기 측에서 설정되고,
상기 모니터링 시간은 상기 피드백 인터벌 시간보다 크거나 같은, 타겟 전송 속도 결정 방법.
수신기(receiver) 측에서 수행되는, 송신기로 피드백 메시지를 전송하는 방법에 있어서,
상기 송신기로부터 패킷을 수신하는 단계;
소정의 모니터링 시간 동안 상기 송신기로부터 수신된 패킷에 대한 정보를 포함하는 피드백 메시지를 생성하는 단계; 및
소정의 피드백 인터벌 시간에 따라 주기적으로 상기 피드백 메시지를 상기 송신기로 전송하는 단계
를 포함하고,
상기 피드백 메시지는 RTCP 헤더, 상기 수신기 측의 식별자(Rxer ID), 상기 송신기 측의 식별자(Txer ID), 피드백 메시지 헤더 및 리포트되는 패킷에 관한 데이터를 포함하는 리포트 블록을 포함하고,
상기 피드백 메시지 헤더는 리포트 시간(Report Time) 필드, 피드백 시퀀스 필드 및 모니터링 시간(Monitored Time) 필드를 포함하고,
상기 리포트 시간 필드는 상기 송신기의 시스템 가동 시간(system up time)을 리포트 시간으로서 나타내는 값을 포함하고,
상기 피드백 시퀀스 필드는 상기 피드백 시퀀스의 시퀀스 넘버를 나타내는 값을 포함하고,
상기 모니터링 시간 필드는 상기 모니터링 시간을 나타내는 값을 포함하고,
상기 리포트 블록은 리포트되는 패킷의 SSRC를 나타내는 값을 포함하는 SSRC 필드, 리포트되는 패킷의 카운트를 나타내는 값을 포함하는 리포트 패킷 카운트 필드, 리포트되는 패킷의 마지막 시퀀스 넘버를 나타내는 값을 포함하는 엔드 시퀀스(end_seq) 필드, 패킷의 손실 여부를 나타내는 값을 포함하는 L 필드 및 리포트되는 패킷의 수신 시간의 상기 리포트 시간에 대한 상대적인 시간 거리를 나타내는 값을 포함하는 ATO (Arrival Time Offset) 필드를 포함하는, 피드백 메시지를 전송하는 방법.
제18항에 있어서,
상기 소정의 모니터링 시간이 경과하기 전에 상기 생성된 피드백 메시지의 크기가 MTU (Maximum Transmission Unit)에 의해 허용되는 크기에 근접하면,
상기 생성된 피드백 메시지는 상기 소정의 모니터링 시간이 경과하기 전에 상기 송신기로 전송되고,
상기 생성된 피드백 메시지가 전송된 후 다음의 피드백 메시지를 생성하기 위한 모니터링이 시작되는, 피드백 메시지를 전송하는 방법.
제18항에 있어서,
상기 송신기로부터 상기 수신기 측에 특정한 피처(feature)를 요청하기 위한 제어 메시지를 수신하는 단계; 및
상기 제어 메시지가 상기 수신기가 이해할 수 있는 메시지 타입을 갖는 경우에 상기 제어 메시지에 대해 응답하는 단계
를 더 포함하고,
상기 제어 메시지가 상기 수신기가 이해할 수 있는 메시지 타입을 갖지 않으면 상기 제어 메시지는 무시 또는 폐기되는, 피드백 메시지를 전송하는 방법.
수신기로의 패킷 전송을 위한 전송 경로(Forward path)를 위한 타겟 전송 속도를 결정하는 송신기에 있어서,
메모리; 및
상기 메모리와 연결되고, 상기 메모리에 포함된 컴퓨터 판독가능한 명령들을 실행하도록 구성된 적어도 하나의 프로세서
를 포함하고,
상기 적어도 하나의 프로세서는,
상기 수신기로부터 수신된, 상기 송신기로부터 수신된 패킷에 관한 정보를 포함하는 피드백 메시지에 기반하여 상기 전송 경로의 상태를 결정하기 위한 적어도 하나의 메트릭(metric)을 추정하고, 상기 추정된 메트릭에 기반하여 상기 전송 경로의 상태를 결정하고, 상기 전송 경로의 상태에 기반하여 상기 전송 경로를 위한 타겟 전송 속도를 결정하고,
상기 추정된 메트릭은 상기 피드백 메시지가 전송되는 경로인 역방향 경로에 의한 영향이 제거된 상기 전송 경로의 특성만을 반영하는 것인, 송신기.