KR100876796B1 - Ｓｓｍ을 지원하는 네트워크에서 실시간 제어 프로토콜의전송 주기 전송 방법 - Google Patents

Abstract

본 발명은 SSM(Source Specific Multicasting)을 지원하는 네트워크에서 실시간 제어 프로토콜의 전송 주기 전송 방법에 관한 것으로, 네트워크에 연결된 서버에서 각 채널에 속한 서버 간의 전체 세션 정보나 RTCP 전송 주기를 확인하여 해당 채널의 세션 정보를 RTP 패킷이나 RTCP 패킷에 포함시켜 클라이언트로 전송하며, 클라이언트에서 RTP 패킷이나 RTCP 패킷에 포함된 정보가 세션 정보인지 직접적인 RTCP 전송 주기인지를 확인한다. 이후 세션 정보인 경우에 세션 정보를 기초하여 RTCP 전송 주기를 계산하고, 계산된 RTCP 전송 주기로 RTCP 패킷을 서버에 전송한다. 또한, RTCP 전송 주기인 경우에 RTCP 전송 주기 그대로 RTCP 패킷을 서버에 전송함으로써, 실시간 제어 프로토콜의 전송 주기를 정확하게 파악하기 힘든 SSM(Source Specific Multicasting)을 지원하는 네트워크에서 각 서버 간의 전체 세션 정보나 RTCP 전송 주기를 정확히 확인할 수 있으며, 해당 세션 정보나 RTCP 전송 주기를 RTP 패킷, RTCP 패킷 전송으로 적절하게 전송할 수 있는 효과를 가진다.

SSM, 네트워크, RTP, RTCP, 세션, 전송 주기, 패킷, 콘텐츠, 데이터

Description

ＳＳＭ을 지원하는 네트워크에서 실시간 제어 프로토콜의 전송 주기 전송 방법{METHOD FOR TRANSMITTING TRANSMIT-PERIOD REAL TIME CONTROLL PROTOCOL IN SOURCE SPECIFIC MULTICASTING SUPPORTING NETWORK}

도 1은 일반적인 멀티캐스트(Multicasting) 기반을 지원하는 네트워크의 구성도

도 2는 본 발명의 바람직한 실시 예에 따른 SSM(Source Specific Multicasting)을 지원하는 네트워크에서의 RTP 패킷에 대한 구성도

도 3은 본 발명의 바람직한 실시 예에 따른 SSM(Source Specific Multicasting)을 지원하는 네트워크에서의 RTCP 패킷에 대한 구성도

도 4는 본 발명의 바람직한 실시 예에 따른 RTCP 패킷 중 RTCP 송신 리포트에 대한 구성도

도 5는 본 발명의 바람직한 실시 예에 따른 RTCP 패킷 중 APP에 대한 구성도

도 6은 본 발명의 바람직한 실시 예에 따른 SSM(Source Specific Multicasting)을 지원하는 네트워크에서의 RTCP 전송 주기에 대한 전송 방법의 흐름도

본 발명은 RTCP 전송 주기를 정확하게 파악하기 힘든 SSM(Source Specific Multicasting)을 지원하는 네트워크에서 RTP 패킷, RTCP 패킷 전송을 통해 각 서버 간의 전체 세션 정보(데이터 전송하는 참가자 수 및 데이터 받는 참가자 수)나 RTCP 전송 주기를 확인하여 적절하게 전송할 수 실시간 제어 프로토콜의 전송 주기 전송 방법에 관한 것이다.

무선 인터넷을 통한 멀티미디어 서비스에는 정보제공 서비스, 대화형 서비스, 엔터테인먼트 서비스, 이동 전자상거래 서비스, 위치기반 서비스 등이 있는데, 이 중에서 대화형 서비스는 음성 대화형 서비스와 화상 대화형 서비스로 구분할 수 있다. 음성 대화형 서비스는 채팅/미팅 서비스 등 음성 통화의 영역을 확대하는 서비스이며, 화상 대화형 서비스는 이동통신 단말기 간 또는 이동통신 단말기와 유선 단말기간의 화상 전화 서비스 등을 포함한다. 영상매체를 저장해 두고 필요한 영상매체를 시간에 구애받지 않고 다운로드 받거나 실시간으로 디스플레이하는 주문형 영상(Video On Demand; 이하, 'VOD'라 함) 서비스 또한 대화형 서비스에서 파생 된 서비스이다.

VOD 서비스는 각종 동영상 클립 다운로드 서비스, 실시간 중계 서비스, 메시징 서비스와의 연계 서비스 등을 포함하고, VOD 전송방식은 다운로드 방식과 스트리밍 방식이 있으며 방대한 멀티미디어 정보를 한정적인 전송 대역폭 자원을 통해 전송하기 위하여 MPEG-4 등과 같은 압축기법을 사용한다.

무선 구간에서 멀티미디어 콘텐츠를 전송하기 위해서는 일반적인 무선 데이터 프로토콜에 별도의 상위 계층이 필요하게 되며, 어느 정도 실시간을 보장하기 위하여 RTP(Real Time Protocol)을 이용하는 것이 일반적이다. RTP는 멀티캐스트 또는 유니캐스트 상에서 음성, 화상 데이터와 같은 실시간 데이터를 전송하는 제공하는 프로토콜로 정의할 수 있다.

한편, RTP를 제어하기 위한 프로토콜로 RTCP(RTP Control Protocol)가 있는데, 이는 주로 멀티캐스트 환경에서 사용되며, 세션 안의 모든 수신자에게 제어 패킷을 주기적으로 전송하고 피드백 데이터로부터 서비스 품질(QoS) 모니터링을 수행한다. 이 기능은 RTCP의 송신 리포트(Sender Report, SR), RTCP의 수신 리포트(Receiver Report, RR)에 의해 수행된다.

이를 위하여, 분실된 패킷 수, 지터 간격, 앞 패킷과의 지연시간 등의 정보를 이용한다. 즉, 무선 인터넷을 통한 멀티미디어 콘텐츠 제공시 RTCP는 데이터 전송을 감시하고 세션 관련 정보를 전송하는데 관여한다.

도 1은 일반적인 멀티캐스트(Multicasting) 기반을 지원하는 네트워크의 구성도이다.

도 1에 도시된 바와 같이, 다수(a)의 클라이언트(102-1, 102-2, ..., 102-a)들이 네트워크(106)를 통해 다수(b)의 서버 (104-1,104-2,...104-b)에 연결되어 있다. 다시 말하자면, 두 개의 채널(즉, 두 개의 서버)이 존재하고 , 다수의 클라이언트(102-a) 중에서 채널 1의 경우 서버 1(104-1)에 연결되고, 채널 2의 경우 서버 2(104-2)에 연결된다.

네트워크(106)는 임의의 다양한 종래의 네트워크 프로토콜(공개 및/또는독점 프로토콜을 포함)들을 이용하고 있는 다양한 종래 네트워크 접속형태(topologies) 및 유형(유선 및 무선 네트워크들을 포함)을 표현하도록 의도되었다. 네트워크(106)는 예를 들면, 가능하게는 하나 이상의 근거리 통신망(LAN)의 적어도 일부분일 수도 있고 또한 인터넷도 포함할 수 있다.

서버(104-b)은 클라이언트(102-a)에 스트리밍될 수 있는 다양한 데이터 중 하나를 생성할 수 있다. "스트리밍"이란 용어는 미디어를 표현하는 데이터를 네트워크를 통해 클라이언트(102-a)에 제공하는데, 콘텐츠의 전체가 전송되기 이전에 그 콘텐츠의 재생을 시작할 수 있음을 나타내는데 사용된다(예를 들면, 재생 이전에 데이터 전체를 미리 전송한다기보다 필요에 따라 데이터를 제공하는 것임).

데이터는 공개적으로 이용가능하거나 또는 제한적일 수 있다(예를 들면, 적절한 요금을 지불한 경우만 이용 가능한, 정해진 사용자에게만 제한됨). 데이터는 오디오, 비디오, 텍스트, 애니메이션 등과 같은 하나 이상의 다양한 콘텐츠 유형 중 하나일 수 있다. 그에 더하여, 데이터가 사전기록 되거나(pre-recorded), 또는 "생방송"될 수 있다(예를 들면, 콘서트를 공연할 때, 콘서트의 디지털 표현을 캡처링하고, 캡처링 이후에 곧바로 스트리밍에 이용가능하게 하는 것).

클라이언트(102-a)는 스트리밍 미디어 콘텐츠를 파일로 저장하고 있는 서버(104-b)로부터 수신하거나, 또는 몇몇 기타 소스로부터 스트리밍 미디어를 수신한 서버(10b)로부터 스트리밍 콘텐츠를 수신할 수 있다. 예를 들면, 서버(104-1)는 스트리밍 미디어 콘텐츠를 파일로 저장하고 있는 또 다른 서버(104-2)로부터 스트 리밍 미디어를 수신할 수 있거나, 또는 몇몇 다른 소스(예를 들면, "생방송" 사건을 인코딩하는 인코더)로부터 스트리밍 미디어를 수신할 수 있다.

여기서 클라이언트(102-1)는 RTP 패킷을 전송하는 sender가 될 수도 있고, RTP 패킷을 수신하는 receiver가 될 수 있다. 클라이언트(102-1)들은 주기적으로 RTP 세션에 참가한 모든 클라이언트(102-a)에게 RTCP 제어 패킷을 전송함으로써 네트워크 상태 정보를 공유하게 된다.

일정 시간 (RTCP 전송 주기의 2배) 이내에 RTP 데이터 패킷을 전송했던 클라이언트(102-a)들은 RTCP 송신 리포트(SR)를 모든 세션 참가자들에게 전송하고, 일정 시간 내에 RTP 데이터 패킷을 전송하지 않았던 클라이언트(102-a)들은 모든 RTP 세션 참가자들에게 RTCP 수신 리포트(RR)를 전송하도록 하고 있다. 여기서 각 RTP 및 RTCP 패킷에는 SSRC(Synchronization Source identifier)라는 클라이언트(102-a) 간 고유 ID 값을 포함하여 누가 패킷을 전송했는지 구별할 수 있다.

한편, IETF RFC3550 표준 문서에서는 제어 정보인 RTCP에 대한 대역을 세션 대역폭의 약 5% 정도로 제한하고 있다. 이는 RTCP 제어 정보의 전송으로 인해 실제 데이터인 RTP 패킷을 전송하는데 지장을 주지 않도록 하기 위함이다.

또한, 하나의 채널(Source Address, Group Address Pair)당 단 하나의 멀티캐스팅 서버(104-1)가 존재하는 SSM(Source Specific Multicasting)경우, 다른 채널에 속한 클라이언트(102-2)들 간의 정확한 세션 정보(데이터 전송하는 참가자 수 및 데이터 받는 참가자 수)를 파악할 수 없기 때문에 RTCP 전송 주기를 제어하기 어렵다.

이에 채널 1에 속한 클라이언트(102-1)들과 채널 2에 속한 클라이언트(102-2) 간 RTCP를 공유할 수 없기 때문에 각 채널의 RTCP 대역 및 각 채널에 참가한 클라이언트(102) 수로 RTCP 전송 주기를 제어하게 된다. 만약 채널 1에 속한 클라이언트(102-1) 수는 매우 적고, 채널 2에 속한 클라이언트(102-2) 수는 매우 많은 경우를 가정하면, 채널 1에 속한 클라이언트들은 매우 빠른 주기로 RTCP를 주고 받을 수 있는 반면, 채널 2에 속한 클라이언트들의 상대적으로 느린 주기로 RTCP를 주고 받게 되어 형평성에 문제가 있었다.

상기와 같은 요구에 부응하기 위한 본 발명은 RTCP 전송 주기를 정확하게 파악하기 힘든 SSM(Source Specific Multicasting)을 지원하는 네트워크에서 RTP 패킷, RTCP 패킷 전송을 통해 각 서버 간의 전체 세션 정보(데이터 전송하는 참가자 수 및 데이터 받는 참가자 수)나 RTCP 전송 주기를 정확히 확인하며, 또한 해당 세션 정보나 RTCP 전송 주기를 RTP 패킷, RTCP 패킷 전송으로 적절하게 전송하는데 있다.

상기 목적을 달성하기 위한 본 발명은 SSM을 지원하는 네트워크에서 실시간 제어 프로토콜의 전송 주기 전송 방법에 있어서, 적어도 하나 이상의 클라이언트와 서버 간에 세션 연결이 이루어진 후, 상기 클라이언트로부터 세션 정보에 대한 요청을 수신하는 과정과, 상기 네트워크의 각 채널에 속한 전체 세션 정보를 확인하는 과정 및 상기 전체 세션 정보 중 해당 채널의 세션 정보를 RTP 패킷에 포함시켜 전송하는 과정을 포함하는 것을 특징으로 한다.

또한, 본 발명은 SSM을 지원하는 네트워크에서 실시간 제어 프로토콜의 전송 주기 전송 방법에 있어서, 적어도 하나 이상의 클라이언트와 서버 간에 세션 연결이 이루어진 후, 상기 클라이언트로부터 세션 정보에 대한 요청을 수신하는 과정과, 상기 네트워크의 각 채널에 속한 전체 세션 정보를 확인하는 과정과, 상기 전체 세션 정보를 기초하여 RTCP 전송 주기를 계산하는 과정 및 상기 RTCP 전송 주기를 RTP 패킷에 포함시켜 전송하는 과정을 포함하는 것을 특징으로 한다.

이하, 첨부된 도면을 참조하여 본 발명에 따른 바람직한 실시 예를 상세히 설명한다. 또한, 본 발명을 설명함에 있어서, 관련된 공지기능 혹은 구성에 대한 구체적인 설명이 본 발명의 요지를 불필요하게 흐릴 수 있다고 판단되는 경우 그 상세한 설명은 생략한다.

앞에서 설명한 바와 같이, SSM(Source Specific Multicasting)을 지원하는 네트워크(100)의 클라이언트(102-a)는 기지국/기지국 제어기(BTS/BSC) 및 교환기(도시하지 않음)를 통해 음성 통신을 수행할 수 있고, 네트워크(106)를 통해 데이터 망과 접속되어 다양한 유, 무선 데이터 서비스를 이용할 수 있다.

서버(104-b)는 네트워크(106)를 통해 접속되어 다양한 콘텐츠 데이터를 수집 및 관리하고, 멀티미디어 콘텐츠를 요구하는 클라이언트(102-a)로 다양한 멀티미디어 콘텐츠 목록을 제공하며, 클라이언트(102-a)가 필요한 콘텐츠를 선택하면 해당 멀티미디어 데이터를 다운로드 방식 또는 스트리밍 방식으로 제공한다.

이때 콘텐츠의 실시간 처리를 위하여 RTP와 RTCP가 UDP(User Datagram Protocol)로 전송되고, 호 처리 및 미디어 제어를 위한 RTSP(Real Time Streaming Protocol)는 TCP로 전송된다.

RTP는 데이터를 실시간으로 전송하기 위한 프로토콜로서 오디오, 비디오, 대화형 시뮬레이션 등의 실시간 데이터를 전송하는 데 적합한 기능을 제공하고 있으며 패킷 번호(SEQUENCE NUMBER)와 전송시간(TIME STAMP)을 사용한다. 즉, 송신측에서 패킷의 번호와 전송시간을 부가적으로 사용하여 수신측에서 순서대로 재생하도록 하는 프로토콜이다. 일반적으로 RTP는 이러한 목적을 위하여 UDP로 전송되는 것이다.

한편, RTCP는 RTP 제어 프로토콜로, RTP에 의한 데이터를 수신한 클라이언트(102-a)에서 패킷 손실 등을 기록하여 서버(104-b)에서 서비스 품질을 조절하는 데 사용되어 데이터의 흐름을 감지할 수 있도록 한다.

RTCP는 RTP와 마찬가지로 UDP로 전송되며 클라이언트(102-a)에서 서버(104-b)로 보고하는 정보는 패킷 손실양, 분실된 패킷 수, 지터 간격, 앞 패킷과의 지연시간 등을 포함한다. RTSP는 실시간으로 음성이나 동영상을 송수신하기 위한 통신규약으로, 서버(104-b)와 클라이언트(102-a) 간의 제어 명령을 전송한다.

도 2는 본 발명의 바람직한 실시 예에 따른 SSM(Source Specific Multicasting)을 지원하는 네트워크에서의 RTP 패킷에 대한 구성도이다.

도 2에 도시된 바와 같이, RTP은 RFC3550 표준 문서에서 정의한 RTP 패킷 형 태이다.

RTP 패킷은 RTP의 버전을 나타내는 버전 번호, 패킷의 사이즈를 조정하는 비트인 패딩, 기능 확장 시에 지정되는 확장 비트, 실시간 전송에 관한 송신원의 수를 나타내는 카운터, 데이터의 경계를 나타내는 마커 비트, 부호화의 종류를 나타내는 페이로드 타입, RTP 패킷의 순서를 나타내는 시퀀스 번호, RTP 패킷이 송신된 시각을 나타내는 타임 스탬프, 메시지의 최초의 송신원을 식별하는 동기 소스 식별자, 및 메시지에 포함되는 패킷군에의 준비를 행한 송신원을 식별하는 공헌 소스 식별자가 순서대로 배치되어 있다.

RTP 패킷에 의한 데이터 전송에서는, 이 타임 스탬프가 부가됨으로써, 송신측과 수신측의 시간적 관계가 파악되므로, 패킷 전송의 지연 변동(지터) 등의 영향이 억제되어, 동기를 취하여 데이터 재생이 가능하게 된다.

Version(V) : 2비트 필드로 현재는 항상 2 값을 가진다.

Padding(P) : 1비트 필드로 1 값을 가지면 패킷에 하나 이상의 채워넣기 바이트가 포함되어 있음을 나타낸다. 마지막 채워넣기 바이트는 현 패킷에서 무시되어야 하는 채워넣기 바이트의 수를 나타낸다.

Extension(X) : 1비트 필드로 1 값을 가지면 고정 헤더 이후에 정확히 하나의 확장 헤더가 등장함을 의미한다.

CSRC Count(CC) : 4비트 필드로 고정 헤더 이후에 나열되는 CSRC 식별자의 수를 나타낸다.

Marker(M) : 1비트 필드로 이 필드의 해석은 프로파일에 의해서 결정된다. 이 필드는 패킷 스트림 내에서 프레임 경계와 같은 중요한 이벤트들을 표시하는데 이용된다. 프로파일은 추가 표시 비트들을 정의하거나 PT 필드를 확장하여 표시 비트를 없앨 수도 있다.

Payload Type(PT) : 7비트 필드로 RTP 페이로드의 타입을 나타낸다. 프로파일에서 페이로드 타입의 값과 실제 페이로드 형식을 연결한다.

Sequence Number(SN) : 16비트 필드로 송신되는 각 RTP 패킷에 대해 1씩 증가하는 값을 가진다. 수신 측에서는 패킷 분실을 검출하거나 패킷의 순서를 맞추는데 이용된다. 초기값은 보안을 위해서 무작위로 설정된다.

Timestamp : 32비트 필드로 RTP 데이터 패킷의 첫번째 바이트의 샘플링 순간을 나타낸다. 시계의 주파수는 페이로드의 데이터 형식에 종속되고 형식을 정의하는 프로파일이나 페이로드 형식 문서에 정적으로 명시된다. 초기값은 순번과 마찬가지로 무작위 수로 설정된다.

Synchronization Source(SSRC) Identifier : 32비트 필드로 동기화 소스를 나타낸다. 이 값은 같은 RTP 세션 내에서 같은 SSRC를 가진 동기화 소스가 두개 이상 나타나지 않도록 무작위로 선택된다.

Contributing Source(CSRC) Identifiers : 이 필드에는 0에서 15목록까지 포함될 수 있으며 각 목록은 32비트를 차지한다. CSRC는 현 패킷에 포함된 페이로드에 기여한 제공 소스들을 나타낸다. 제공 소스가 15개 이상일 경우에도 15개의 제공 소스만 기록된다. 이 필드는 혼합기(도시하지 않음)에 의해 삽입되고 각 목록은 혼합되는 모든 소스들의 SSRC 식별자이다.

여기서, 빗금 친 기능 확장 시에 지정되는 확장 비트 X (extension bit)을 1로 세팅하게 되면 RTP 헤더 바로 다음에 도 2b와 같은 extension 헤더가 붙게 된다. extension 헤더는 16 bit의 profile에 따라 정의된 값과 length로 구현된다. 이에 도 2c와 같이 빗금 친 부분에 RTCP 전송 주기나 세션 정보를 포함시켜 전송한다.

이를 위해 defined by profile에는 서버(104-b)와 클라이언트(102-a) 간 정의된 값을 사용해서 defined by profile값에 따라 세션 정보인지 직접적인 RTCP 전송 주기인지 확인할 수 있다. 이 경우 추가적인 8 바이트가 필요하다.

결국, 서버(104-1)는 각 채널에 속한 서버(104-b)들 간의 이러한 RTP 패킷 전송을 통해 전체 세션 정보(데이터 전송하는 참가자 수 및 데이터 받는 참가자 수)를 알 수 있으며, 전체 세션 정보를 정확히 확인하여 RTP 패킷으로 클라이언트(102-a)에 전송한다. 또한, 각 채널에 속한 서버(104-b)들은 RTCP 전송 주기를 세션 정보와 같이 RTP 패킷에 포함시켜 전송하는데, 보통 RTP 패킷 전송 주기가 RTCP 전송 주기보다 매우 빠르기 때문에 빠른 제어가 필요한 경우 RTP 패킷에 붙여 클라이언트(102-a)로 전송한다.

한편, 도 2d와 같이 16비트 중에 n 비트는 세션 정보인지, RTCP 주기인지 확인할 수 있는 flag 값을 정의해서 사용할 수 있으며, 나머지 (16 - n) 비트에 profile 값에 따라 필요한 값을 사용할 수 있다. 이 경우 추가적인 4 바이트만 필요하게 되지만 도 2c 대비 세션 정보가 적거나 RTCP 전송 주기의 변화가 적은 경우에 사용할 수 있다.

도 3은 본 발명의 바람직한 실시 예에 따른 SSM(Source Specific Multicasting)을 지원하는 네트워크에서의 RTCP 패킷에 대한 구성도이다.

RTCP 패킷은 분실된 패킷 수, 앞 패킷과의 지연시간, 지터 간격 등 서비스 품질 정보를 교환, 패킷 송신율을 계산, 세션 정보 전송 등의 기능 외에, 데이터 원천지 식별자가 충돌되거나 재생성되는 경우 이를 반영하기 위하여 'CNAME'이라는 영구 트랜스포트 식별자를 전송하여야 한다. 이를 위하여 RTCP 패킷은 도 4a와 같은 구조를 갖는다.

도 3에 도시된 바와 같이, RTCP는 SR(Sender Report), RR(Receiver Report), SDES(Source Description Item), CNAME(Canonical NAME), PHONE(telephone number), LOC(geographic location), BYE 등과 같은 다수의 패킷 타입을 가지고 있다. RTCP는 다수의 패킷이 도 3과 같이 결합된 형태로 전송된다.

SR은 서버(104-b)가 클라이언트(102-a)로 데이터 송수신에 대한 통계 정보를 알리는 데 사용되고, RR은 클라이언트(102-a)가 서버로 송수신에 대한 통계 정보를 알리는데 사용하며, SDES는 CNAME을 포함하여 소스 이름을 기술하는 데 사용하고, BYE는 RTP 세션을 빠져나올 때 사용한다.

도 4는 본 발명의 바람직한 실시 예에 따른 RTCP 패킷 중 RTCP 송신 리포트에 대한 구성도이다.

도 4에 도시된 바와 같이, RTCP 패킷의 송신 리포트(Sender Report)는, 송신측의 서버(104-b)로부터 수신측의 클라이언트(102-a)로 정기적으로 송신되는 정보이다. 또한, 이 RTCP 패킷의 송신 리포트(SR)는, 송신측의 서버(104-b)로부터 멀티 캐스트로 송신되고 있다.

RTCP 패킷의 송신 리포트는, 헤더, 송신하는 데이터의 송신 정보(Sender Information), 및 1 이상의 수신 리포트블록(수신 리포트 블록1(Report Block 1), 수신 리포트 블록2(Report Block 2), ……)으로 구성된다.

헤더는 버전 정보, 패딩, 카운터, 패킷 타입, 메시지 길이, 및 송신자(즉, 이 송신 리포트를 송신하고 있는 송신측의 서버)의 동기 소스 식별자로 구성된다.

Report Count(RC) : 5비트 필드로 이 패킷에 포함된 수신 보고 블럭의 수를 나타낸다.

Packet Type(PT) : 8비트 필드로 RTCP SR 패킷의 경우에는 200 값을 가진다.

Length : 16비트 필드로 32비트 워드로 계산된 전체 패킷의 길이에서 1을 뺀 값으로 헤더와 채워넣기를 모두 포함한다. 0 값도 유효하다.

송신 정보는, 송신 리포트가 보내진 시각인 NTP(Network Time Protocol) 타임 스탬프, NTP 타임 스탬프에 대응하는 RTP 타임 스탬프, 송신측의 서버에 의해 송신 리포트를 보내고 나서 이 송신 리포트를 보낼 때까지 송신된, 송신 패킷수 및 송신 바이트수로 구성된다. 이 NTP 타임 스탬프 및 RTP 타임 스탬프에 의해, 복수의 패킷의 시간축을 공통된 시간축(NTP 시간축)에 동기시킬 수 있다.

NTP Timestamp : 64비트 필드로 이 보고가 보내진 시간을 나타내고 Round-Trip 지연 계산에 이용된다.

RTP Timestamp : 32비트 필드로 NTP Timestamp의 시간에 상응한다. 그러나 단위와 무작위 오프셋은 데이터 패킷의 RTP Timestamp들과 같다. 이것은 RTP Timestamp 계수와 실제 시간 간의 관계를 이용해서 해당 NTP Timestamp로부터 계산된다.

송신자 패킷 계수 : 32비트 필드로 전송 시작에서부터 이 SR 패킷이 생성될 때 까지 이 송신자에 의해 전송된 RTP 데이터 패킷의 총 수를 나타낸다. 이 값은 송신자가 SSRC 식별자를 변경하면 초기화 된다.

송신자 옥텟 계수 : 32비트 필드로 전송 시작에서부터 이 SR 패킷이 생성될 때 까지 이 송신자에 의해 전송된 RTP 데이터 패킷에서 헤더와 채워넣기를 제외한 페이로드 바이트의 수를 나타낸다. 송신자가 SSRC 값을 변경하면 이 필드는 초기화 된다.

수신 리포트 블록1은, 송신측(수신측)로부터 수신한 수신 리포트의 정보로서, 그 수신 리포트를 보낸 송신측(수신측)을 식별하는 송신측의 동기 소스 식별자, 송신측의 서버(104)로부터 수신측의 클라이언트(102)에의 전송에서의 패킷 손실율, 누적 손실 패킷수, 최대 수신 시퀀스 번호, 패킷 간격 지터, 최신 송신 리포트 시각, 및 송신 리포트 경과 시간으로 구성된다.

마찬가지로, 수신 리포트 블록2는, 수신 리포트 블록1과 같이 구성된다. 또한, 이 수신 리포트 블록의 수는, 송신측의 서버(104)에 의해 전회의 송신 리포트를 보내고 나서 이 송신 리포트를 보낼 때까지 수신된 수신측의 클라이언트(102)로부터의 수신 리포트의 수(헤더의 카운터의 수)만큼 부가된다.

SSRC_1 : 32 비트 필드로, 이 수신 보고 블럭의 정보가 해당되는 소스의 SSRC 식별자를 나타낸다.

Fraction lost : 8비트 필드로, 이전 SR 또는 RR 패킷이 송신된 이후 분실된 RTP 데이터 패킷의 비율이 고정 소수로 표현된다. 이것은 분실 비율을 256으로 곱한 후 정수부를 취하는 것과 같다. 이 값은 분실된 패킷의 수를 기대된 패킷의 수로 나누어 얻어진다. 중복 수신에 의해 분실이 음의 값을 가질 경우 분실 비율은 0이 된다.

Cumulative number of packets lost : 24비트 필드로, 소스 SSRC_n으로부터 수신 시작 이래로 분실한 총 RTP 데이터 패킷 수로 예측된 패킷 수에서 실제 수신된 패킷 수를 뺀 값으로 정의된다. 실제 수신된 패킷 수에는 지연 도착된 것과 중복 도착된 것도 포함된다.

Extended highest sequence number received : 32비트 필드로, 하위 16비트는 소스 SSRC_n으로부터 수신된 RTP 데이터 패킷의 최고 순번을 포함하고 상위 16비트는 그 순번을 부록A.1의 알고리즘에 따라 관리되는 순번 사이클의 해당 계수로 확장한다.

Interarrival jitter : 32비트 필드로, Timestamp 단위로 측정되고 비부호 정수로 표현되는 RTP 데이터 패킷 도착 시간 간의 통계적 가변성의 측정값을 나타낸다. Si가 패킷 i로부터의 RTP Timestamp이고 Ri가 패킷 i의 RTP Timestamp 단위로 측정한 도착 시간일 때, 패킷 i와 j의 지터 D는 D(i,j) = (Rj-Ri) - (Sj-Si) = (Rj-Sj) - (Ri - Si)와 같이 표현되고, 도착간 지터 J는 J = J + (|D(i-1, i)| - J)/16로 정의된다. 여기서 1/16은 Gain Parameter로 적당한 수렴 속도를 보장하면서 좋은 소음 감쇄 율을 보장한다.

Last SR Timestamp(LSR) : 32비트 필드로, 소스 SSRC_n으로부터 최근에 받은 RTCP SR의 일부인 64비트 NTP 타임스탬프의 중간 32비트를 나타낸다. SR을 아직 받지 않았으면 이 필드는 0 값을 가진다.

Delay since last SR(DLSR) : 32비트 필드로, 소스 SSRC_n으로부터의 최종 SR 패킷 수신과 이 수신 보고 블럭 송신간의 지연을 나타내며, 1/65536초 단위로 표시된다. SSRC_n으로부터 아직 SR 패킷을 받지 못했을 경우 이 필드의 값은 0으로 설정된다.

한편, RTP 패킷과 달리 length 항목이 있기 때문에 RTCP 송신 리포트(SR) 패킷의 마지막에 RTCP 전송 주기나 세션 정보를 포함한 extension 을 첨가한다. 여기서 RTP 패킷과 달리 빗금 친 부분에 대한 정의는 RFC3550 표준 문서에 정의되지 않았기 때문에 도 2c나 도 2d와 같은 형태를 사용할 수 있다.

결국, 서버(104-1)는 각 채널에 속한 서버(104-b)들 간의 이러한 RTCP 패킷 전송을 통해 전체 세션 정보(데이터 전송하는 참가자 수 및 데이터 받는 참가자 수)나 RTCP 전송 주기를 알 수 있으며, 전체 세션 정보나 RTCP 전송 주기를 정확히 확인하여 RTCP 패킷으로 클라이언트(102-a)에 전송한다.

도 5는 본 발명의 바람직한 실시 예에 따른 RTCP 패킷 중 APP에 대한 구성도이다.

RFC3550 표준 문서에서 도 4a와 같이 정의한 RTCP APP(Application Specific Function) 패킷은 새로운 응용이나 새로운 기능이 개발되었을 때 패킷 종류 값을 등록할 필요 없이 실험을 목적으로 사용되기 위한 패킷이다. 인식할 수 없는 이름 을 가진 APP 패킷은 무시되어야 한다. 실험 후에 광범위한 이용성이 판명되면 각 APP 패킷은 부 타입과 이름 필드 없이 재정의되어 RTCP 패킷 타입을 이용해서 IANA(Internet Assigned Number Authority)에 등록하도록 권고된다.

Subtype : 5비트 필드로 일련의 APP 패킷들이 하나의 유일한 이름으로 정의될 수 있도록 하는 부 타입으로 사용되거나 응용에 종속되는 데이터를 위해 사용될 수 있다.

Packet Type(PT) : 8비트 필드로 RTCP APP 패킷은 204 값을 가진다.

Name : 4바이트 필드로 이 응용이 수신할 다른 APP 패킷들에 대해 유일하도록 APP 패킷을 정의하는 이름으로 사용자에 의해 선택된다.

Application-specific Data : 가변 길이의 필드로 APP 패킷에 나타날 수도, 나타나지 않을 수도 있다. 이 필드는 RTP에 의해 해석되지 않고 응용에 의해 해석된다. 이 필드의 길이는 32비트의 배수여야 한다.

여기서 빗금 친 부분에 필요한 정보(세션 정보 또는 RTCP 전송 주기 등)를 보낼 수 있다. 이 경우 앞의 경우들에 비해 오버헤드가 커서 16바이트가 추가로 필요하다. RTCP APP 패킷은 도 4b와 같이 RTCP 송신 리포트(SR) 패킷을 보낼 때 같이 보내게 된다 (Compound 패킷 형태로 전송한다.).

결국, 서버(104-1)는 각 채널에 속한 서버(104-b)들 간의 이러한 RTCP 패킷 전송을 통해 전체 세션 정보(데이터 전송하는 참가자 수 및 데이터 받는 참가자 수)나 RTCP 전송 주기를 알 수 있으며, 전체 세션 정보나 RTCP 전송 주기를 정확히 확인하여 RTCP 패킷으로 클라이언트(102-a)에 전송한다.

도 6은 본 발명의 바람직한 실시 예에 따른 SSM(Source Specific Multicasting)을 지원하는 네트워크에서의 RTCP 전송 주기에 대한 전송 방법의 흐름도이다.

도 6에 도시된 바와 같이, SSM(Source Specific Multicasting)을 지원하는 네트워크(106)에 연결되어 각 채널에 속한 클라이언트(102-1)는 서버(104-1) 간에 TCP 세션이 연결되어 세션 정보를 요청한다(S600).

클라이언트(102-1)의 이와 같은 세션 정보 요청에 따라 서버(104-1)는 네트워크(106)의 각 채널에 속한 서버(104-b) 간의 전체 세션 정보(데이터 전송하는 참가자 수 및 데이터 받는 참가자 수)를 확인(S610)하여 해당 채널의 세션 정보를 RTP 패킷의 헤더에 포함시켜 클라이언트(102-1)로 전송한다(S620).

또한, 서버(104-1)는 네트워크(106)의 각 서버(104-b) 간에 전체 세션 정보를 기초하여 RTCP 전송 주기를 계산하고, 계산된 RTCP 전송 주기를 RTP 패킷의 헤더, RTCP 패킷의 송신 리포트 및 RTCP 패킷의 APP에 포함하여 전송할 수도 있다. 즉, 클라이언트(102-1)가 서버(104-1)로 전송할 RTCP RR 패킷의 전송 주기 및 서버(104-1)가 클라이언트(102-1)로 전송할 RTCP SR 패킷의 전송 주기를 전송할 수 있다.

이와 같이 서버(104-1)로부터 해당 채널에 속한 클라이언트(102-1)로 세션 정보가 전송된 후, 클라이언트(102-1)는 RTP 패킷의 헤더에 포함된 정보가 세션 정보인지 직접적인 RTCP 전송 주기인지를 확인하며(S630), 세션 정보인 경우에 세션 정보를 기초하여 RTCP 전송 주기를 계산하고(S640), 계산된 RTCP 전송 주기로 RTCP 패킷을 서버(104-1)에 전송한다(S650).

한편, RTCP 전송 주기인 경우에 클라이언트(102-1)는 서버(104-1)로부터 전송된 RTCP 전송 주기로 RTCP 패킷을 서버(104-1)에 전송한다.

결국, RTCP 전송 주기를 정확하게 파악하기 힘든 SSM을 지원하는 네트워크(106)에서 RTP 패킷이나 RTCP 패킷 전송을 통해 각 서버 간의 전체 세션 정보(데이터 전송하는 참가자 수 및 데이터 받는 참가자 수)나 RTCP 전송 주기를 정확히 확인하며, 또한 해당 세션 정보나 RTCP 전송 주기를 RTP 패킷이나 RTCP 패킷 전송으로 적절하게 전송할 수 있다.

상기와 같이 본 발명의 바람직한 실시 예에 따른 SSM을 지원하는 네트워크에서 실시간 제어 프로토콜(RTCP)의 전송 주기 전송 방법이 이루어질 수 있으며, 한편 상기한 본 발명의 설명에서는 구체적인 실시 예에 관해 설명하였으나 여러 가지 변형이 본 발명의 요지를 벗어나지 않고 다양한 실시예가 있을 수 있다. 따라서 본 발명의 범위는 설명된 실시 예에 의하여 정할 것이 아니고 청구범위와 청구범위의 균등한 것에 의하여 정하여져야 할 것이다.

상기한 바와 같이 이루어진 본 발명은 RTCP 전송 주기를 정확하게 파악하기 힘든 SSM(Source Specific Multicasting)을 지원하는 네트워크에서 RTP 패킷, RTCP 패킷 전송을 통해 각 서버 간의 전체 세션 정보(데이터 전송하는 참가자 수 및 데이터 받는 참가자 수)나 RTCP 전송 주기를 확인하여 적절하게 전송할 수 있는 효과 를 가진다.

Claims (10)

1. SSM을 지원하는 네트워크에서 실시간 제어 프로토콜(RTCP; Real Time Control Protocol)의 전송 주기 전송 방법에 있어서,

   적어도 하나 이상의 클라이언트와 서버 간에 세션 연결이 이루어진 후, 상기 클라이언트로부터 세션 정보에 대한 요청을 수신하는 과정과;

   상기 네트워크에 포함된 각 서버들이 데이터를 전송하는 참가자 수 및 데이터를 받는 참가자의 수를 확인하고, 각 채널에 속한 데이터를 전송하는 참가자 수 및 데이터를 받는 참가자의 수를 포함하는 전체 세션 정보를 확인하는 과정; 및

   상기 전체 세션 정보 또는 상기 전체 세션 정보에 대응하는 실시간 제어 프로토콜(RTCP) 전송주기를 RTP 패킷에 포함시켜 각 채널에 대응하는 상기 클라이언트로 전송하는 과정을 포함하는 것을 특징으로 하는 실시간 제어 프로토콜의 전송 주기 전송 방법.
2. 제1항에 있어서, 상기 전체 세션 정보는,

   상기 네트워크에 연결된 서버들의 세션 정보로부터 획득되며, 상기 클라이언트로 전송되는 RTP 패킷에 포함되는 것을 특징으로 하는 실시간 제어 프로토콜의 전송 주기 전송 방법.
3. 제1항에 있어서, 상기 세션 정보를 전송하는 과정 후, 상기 클라이언트에서 RTP 패킷에 포함된 정보가 세션 정보인지 직접적인 RTCP 전송 주기인지를 확인하는 과정과;

   상기 RTP 패킷에 포함된 정보가 세션 정보인 경우에 세션 정보를 기초하여 RTCP 전송 주기를 계산하는 과정과;

   상기 RTCP 전송 주기로 RTCP 패킷을 상기 서버에 전송하는 과정을 더 포함하는 것을 특징으로 하는 실시간 제어 프로토콜의 전송 주기 전송 방법.
4. 제1항 내지 제3항 중 어느 한 항에 있어서, 상기 세션 정보는 RTP 패킷의 헤더, RTCP 패킷의 송신 리포트 , RTCP 패킷의 APP에 포함되어 전송되는 것을 특징으로 하는 실시간 제어 프로토콜의 전송 주기 전송 방법.
5. 제3항에 있어서, 상기 RTP 패킷에 포함된 정보가 RTCP 전송 주기인 경우에 RTCP 전송 주기 그대로 RTCP 패킷을 상기 서버에 전송하는 과정을 포함하는 것을 특징으로 하는 실시간 제어 프로토콜의 전송 주기 전송 방법.
6. 제5항에 있어서, 상기 RTCP 전송 주기는 RTP 패킷의 헤더, RTCP 패킷의 송신 리포트 , RTCP 패킷의 APP에 포함되어 전송되는 것을 특징으로 하는 실시간 제어 프로토콜의 전송 주기 전송 방법.
7. SSM을 지원하는 네트워크에서 실시간 제어 프로토콜(RTCP; Real Time Control Protocol)의 전송 주기 전송 방법에 있어서,

   적어도 하나 이상의 클라이언트와 서버 간에 세션 연결이 이루어진 후, 상기 클라이언트로부터 세션 정보에 대한 요청을 수신하는 과정;

   상기 네트워크에 포함된 각 서버들이 데이터를 전송하는 참가자 수 및 데이터를 받는 참가자의 수를 확인하고, 각 채널에 속한 데이터를 전송하는 참가자 수 및 데이터를 받는 참가자의 수를 포함하는 전체 세션 정보를 확인하는 과정;

   상기 전체 세션 정보를 기초하여 RTCP 전송 주기를 계산하는 과정; 및

   상기 RTCP 전송 주기를 RTP 패킷에 포함시켜, 각 채널에 대응하는 상기 클라이언트로 전송하는 과정을 포함하는 것을 특징으로 하는 실시간 제어 프로토콜의 전송 주기 전송 방법.
8. 제7항에 있어서, 상기 전체 세션 정보는,

   상기 네트워크에 연결된 서버들의 세션 정보로부터 획득되며, 상기 클라이언트로 전송되는 RTP 패킷에 포함되는 것을 특징으로 하는 실시간 제어 프로토콜의 전송 주기 전송 방법.
9. 제8항에 있어서, 상기 세션 정보는 RTP 패킷의 헤더, RTCP 패킷의 송신 리포트 , RTCP 패킷의 APP에 포함되어 전송되는 것을 특징으로 하는 실시간 제어 프로토콜의 전송 주기 전송 방법.
10. 제7항에 있어서, 상기 RTCP 전송 주기는 RTP 패킷의 헤더, RTCP 패킷의 송신 리포트 , RTCP 패킷의 APP에 포함되어 전송되는 것을 특징으로 하는 실시간 제어 프로토콜의 전송 주기 전송 방법.

Images