KR20140009061A

KR20140009061A - 유니캐스트 프로토콜을 이용한 멀티캐스트 전송

Info

Publication number: KR20140009061A
Application number: KR1020130081797A
Authority: KR
Inventors: 스테판 구아쉬; 기욤 비쇼; 젠유 우
Original assignee: 톰슨 라이센싱
Priority date: 2012-07-12
Filing date: 2013-07-11
Publication date: 2014-01-22
Also published as: EP2685665B1; JP2014023150A; US9425975B2; US20140016532A1; EP2685664A1; CN103546302A; EP2685665A1

Abstract

본 발명은 유니캐스트 프로토콜을 이용하여 복수의 클라이언트(6,8) 중 적어도 하나와 서버(4) 사이의 멀티캐스트 전송을 위한 방법으로서, 상기 방법은 서버(4)와 클라이언트(6,8) 사이의 멀티캐스트(16) 경로 및 유니캐스트(10,12) 경로의 결합 작동을 가능하게 하기 위해, 상기 클라이언트(6,8)가 멀티캐스트 경로(16)를 통해 서버(4)와 통신하는 것을 허용하는 정보를 서버(4)가 클라이언트(6,8)에게 제공하는 단계를 포함한다.

Description

유니캐스트 프로토콜을 이용한 멀티캐스트 전송{MULTICAST TRANSMISSION USING A UNICAST PROTOCOL}

본 발명은 일반적으로 네트워크 내에서 정보를 전송하는 데 사용되는 전송 계층 프로토콜 분야에 관한 것이다.

보다 구체적으로, 본 발명은 IETF RFC 4960의 인터넷 엔지니어링 태스크 포스(IETF)에 의해 표준화된, SCTP라고 알려진 스트림 제어 전송 프로토콜에 관한 것이다. 따라서, 본 발명은 유니캐스트 프로토콜을 이용한 멀티캐스트 전송을 위한 방법, 클라이언트, 및 서버와 관련된다. 또한, 본 발명은 본 발명의 방법을 구현하는 컴퓨터 프로그램과 관련된다.

본 섹션에서 언급된 방식들이 추구될 수 있으나, 이는 반드시 기존에 고안되었거나 추구되었던 방식은 아니다. 따라서, 본 명세서에서 달리 언급이 없다면, 본 섹션에서 기술된 방식들은 본 출원의 청구범위에 대한 종래 기술이 아니며, 또한 본 섹션에 포함됨으로 인해 종래기술로 인정되는 것은 아니다.

SCTP(Stream Control Transmission Protocol)는 TCP(Transmission Control Protocol)와 유사한 서비스를 제공하는 것 외에 최신 IP(mordern Internet Protocol) 네트워크의 향상된 성능들을 이용하고, 증가된 어플리케이션 요구사항을 지원하기 위한 일련의 진보된 특성들을 제공하는 범용 전송 계층 프로토콜이다. 오늘날에는, 모든 주요 운영 체제들을 위한 SCTP 구현들이 존재한다.

IETF에 의해 명시된 상기 SCTP 프로토콜은 셀룰러 코어 네트워크 내에서 시그널링 정보를 전송하기 위한 3GPP(3rd Generation Partnership Project)에 이용된다. SCTP는 IP를 통한 텔레포니 시그널링의 전송을 위해 TCP에 내재되어 있는 특정 제한들을 처리하도록 설계되었다. SCTP의 주된 설계 목적 중 하나는 시그널링 메시지들을 전송하는 데 중요한, 네트워크 내결함성(network fault-tolerant) 방식을 이용하여 소량의 메시지들을 효율적으로 전송하는 것이었다. 따라서, SCTP는 서비스 메시지의 전송을 위해 신뢰할 수 있는 데이터 전송 서비스를 어플리케이션 사용자들에게 제공한다.

SCTP는 메시지 경계를 보존하는 접속-지향형(connection-oriented) 범용 전송 프로토콜이다. IPv4 및 IPv6 외에 SCTP 연결(association)이라 불리는 SCTP 접속이 이용될 수 있다.

메시지들은 청크라고 불리는 데이터 구조 내에 캡슐화된다. 청크들은 SCTP 패킷 내에 캡슐화된다. 또한, SCTP는 TCP에서 이용가능하지 않은 일부 새로운 특징들을 포함한다.

기존의 전송 계층 프로토콜들에 대해 SCTP가 제공하는 가장 중요한 개선점들 중 하나는 멀티호밍이다. 이 멀티호밍의 특징은 SCTP 연결이 일부 소스(source) 주소와 목적지 주소를 사용할 수 있게 한다. 그러면, 각 노드는 연결의 확립시에 설정된 일부 주소들에 의해 액세스될 수 있다. 전송 주소들은 SCTP 연결의 초기화 중에 교환된다.

멀티호밍의 특징은 현재까지 신뢰성을 제공하는 방식으로서 이용되었다. 소스와 목적지 간의 1차 경로가 실패할 때마다, 트래픽이 2차 경로들 중 하나를 통해 계속해서 흐를 수 있도록 SCTP 연결이 잔존해 있다.

최근에는, 전체 대역폭을 증가시키는 방식으로 SCTP에 의해 허용되는 이용가능한 서로 다른 접속 경로들을 동시에 사용하여, 본질적으로 이동성 관리를 향상시키는 것이 제안되었다.

전술한 디폴트 TCP형의 거동 외에, SCTP는 RFC 3758에 명시된 SCTP-PR(SCTP-Partial reliability)로 명명되는 확장형인 UDP(User Datagram Protocol)형의 무응답 트래픽(non acknowledged traffic)을 지원한다.

2005년 National Computer Science Postgraduate Colloquium(NaCSPC)에 실린 F. Yong, W. Chee, 및 S. Ramadass의 논문 "M-SCTP: transport layer multicasting protocol"에는 멀티캐스트 SCTP(M-SCTP)를 이용하는 방식이 기술되어 있다. 이 방식은 SCTP서버와 SCTP 클라이어트들 사이에 M-SCTP 서버 스택을 추가한다. 서버 스택은 멀티캐스트 서비스의 리소스들을 관리하고 멀티캐스트 멤버쉽을 제어한다. 그러나, 이 방식은 반복적인 유니캐스트 프로토콜 메시지 전송들을 이용함으로써 멀티캐스트 성능이 달성된다. 즉, 데이터 패킷들을 복제하고, 다수의 유니캐스트 프로토콜 메시지 전송을 이용하여 각각의 클라이언트에게 개별적으로 전송함으로써 서버 스택에 의한 멀티캐스트가 실현된다. 따라서, 이 방식은 낮은 대역폭 효율이나 저조한 시스템 확장성으로부터 기인하는 문제점들을 해결하지 못한다.

공보 WO2011/071474는 SCTP에 멀티캐스트 지원을 추가하는 것을 허용하는 방식의 장점들을 개시하고 있다.

이러한 아이디어는 SCTP 전송 프로토콜을 멀티캐스트 환경에서 동작시키는 것인 반면, 이전 단락에서 설명된 바와 같이, SCTP는 유니캐스트 TCP/UDP와 같은 접속들을 위해 주로 설계되었다.

수많은 경우들이 존재하며, 특히 영상 분배를 고려할 때, 멀티캐스팅 및/또는 브로캐스팅으로부터 선별된다는 것은 흥미롭다. 그러나, 브로드캐스트 매체, 강인성을 위한 양방향 매체, 서비스 연속성과 연계하는 것은 일반적인 것이다. 오늘날에, 이것은 상이한 미디어와 이들의 유니캐스트나 멀티캐스트 등의 특성들을 다루는 어플리케이션에 의존한다.

UDP를 통한 멀티캐스트만으로 이루어진 종래 기술은, 소스의 경우, 예컨대 공유 통신 링크를 통해 다수의 목적지에 스트림을 분배하는 스트리밍 서버로서 다루고 있지만, 이러한 멀티캐스트 컨텐츠의 분배를 달성하기 위해 복수의 링크들을 동시에 이용하는 것을 허용하지는 않는다.

상기 인용된 공보 WO2011/071474는 이러한 멀티캐스트 전송을 달성하기 위한 SCTP 프로토콜에 대한 변경을 제공하지 않는다.

본 발명은 이러한 문제점을 개선하기 위한 해결책을 제공한다.

따라서, 본 발명은 유니캐스트 프로토콜을 이용하여 복수의 클라이언트 중 적어도 하나와 서버 간의 멀티캐스트 전송을 행하기 위한 방법을 제공하며, 상기 방법은 서버와 클라이언트 사이의 멀티캐스트 경로 및 유니캐스트 경로의 결합 동작(joint operation)을 가능하게 하기 위해, 클라이언트가 멀티캐스트 경로를 통해 서버와 통신할 수 있도록 허용하는 정보를 서버가 클라이언트에게 제공하는 단계를 포함한다.

클라이언트가 멀티캐스트 경로를 통해 서버와 통신할 수 있도록 허용하는 정보를 서버로부터 클라이언트에게 제공함으로써, 본 발명의 방법은 유니캐스트 경로 및 멀티캐스트 경로를 함께 또는 택일적으로 모두 이용가능하게 한다.

바람직하게는, 유니캐스트 프로토콜은 멀티호밍 프로토콜이다.

바람직하게는, 멀티호밍 프로토콜은 SCTP(Stream Control Transmission Protocol)이거나 또는 SCTP의 확장형이다.

이러한 SCTP 확장의 일례는 SCTP-PR이다.

바람직하게는, SCTP의 경우, 클라이언트가 멀티캐스트 경로를 통해 서버와 통신하도록 클라이언트에게 허용하는 정보는 SCTP 연결을 초기화하도록 허용하는 초기화 정보를 포함한다.

본 발명에 의해, IP 유니캐스트 베어러(bearer)들과 연관된 동시적(cuncurrent) IP 멀티캐스트 베어러가 사용된 멀티캐스트 SCTP 서비스를 설계하는 것이 가능하다.

제1 실시예에 따르면, 초기화 정보는 멀티캐스트 경로를 통해 규칙적으로 브로드캐스트되는 초기화 청크 내에서 전달된다.

바람직하게는, 초기화 청크는 SCTP 연결에 의해 전달되는 아웃바운드 스트림들의 수를 광고하는 필드를 포함한다.

바람직하게는, 초기화 청크는 서버에 의해 지원되는 적어도 하나의 IP 주소를 포함한다.

보다 구체적으로, 브로드캐스트 초기화 청크는 서버가 컨택할 수 있는 IPv4/IPv6 주소 세트를 포함한다. 이 주소는 다른 가능한 멀티캐스트 베어러를 포함할 수 있다.

제2 실시예에 따르면, 초기화 정보는 클라이언트가 이용 가능하도록 만들어진 파일 내에 기술되어 있다.

예를 들어, 이러한 파일은 임의의 가능한 수단에 의해, 예컨대 서비스 가이드의 일부로서 클라이언트가 이용할 수 있거나 또는 네트워크 운영자에 의해 미리 로딩될 수 있도록 만들어진 SDP 파일일 수 있다.

바람직하게는, 본 방법은 클라이언트에 의해 수행되는 SCTP 연결의 초기화 단계를 포함한다.

이것은 클라이언트와 서버 간의 업링크 경로가 이용가능한 경우에 가능하다.

또한, 본 발명은 또한, 유니캐스트 프로토콜을 이용하여 서버가 다수의 클라이언트들 중 적어도 하나와 통신할 수 있도록 하며, 상기 서버는, 서버와 클라이언트 사이의 멀티캐스트 경로 및 유니캐스트 경로의 결합 동작(joint operation)을 가능하게 하기 위해, 상기 클라이언트가 서버와 멀티캐스트 경로를 통해 통신하는 것을 허용하는 정보를 상기 클라이언트에게 제공하기 위한 관리 모듈을 포함한다.

본 발명은 또한, 유니캐스트 프로토콜을 이용하여 클라이언트가 서버와 통신할 수 있도록 하며, 상기 클라이언트는, 서버와 클라이언트 사이의 멀티캐스트 경로 및 유니캐스트 경로의 결합 동작을 가능하게 하기 위해, 상기 클라이언트가 멀티캐스트 경로를 통해 서버와 통신하는 것을 허용하는 정보를 수신하기 위한 수신기 모듈을 포함한다.

본 발명에 따른 멀티캐스트 전송을 위한 방법은 프로그래밍 가능한 장치의 소프트웨어에서 구현될 수 있다. 이는 하드웨어 또는 소프트웨어 단독으로, 또는 이들의 조합으로 구현될 수 있다.

본 발명은 소프트웨어에서 구현될 수 있으므로, 본 발명은 임의의 적합한 전달 매체 상의 프로그래밍 가능한 장치에 제공하기 위한 컴퓨터 판독가능한 코드로서 구현될 수 있다. 전달 매체는 플로피 디스크, CD-ROM, 하드디스크 드라이브, 자기 테잎 장치 또는 고체 상태의 메모리 장치 등의 저장 매체를 포함할 수 있다.

따라서, 본 발명은 컴퓨터로 하여금 본 발명의 방법의 단계들을 수행하게 하기 위한 컴퓨터 실행가능한 명령어들을 포함하는 컴퓨터 판독가능 프로그램을 제공한다. 도 3의 다이어그램은 이러한 컴퓨터 프로그램에 대한 일반적인 알고리즘의 일례를 나타낸다.

본 발명은 제한이 아닌 예시로서 설명되며, 첨부 도면에서, 유사한 참조번호들은 유사한 요소들을 지칭한다.
도 1은 SCTP를 이용하여 본 발명의 일 실시예에 따른 멀티캐스트 전송 방법을 구현하는 전송 시스템에 대한 일 실시예의 개략도.
도 2는 본 발명의 일 실시예에 따른 초기화 청크의 일례를 나타내는 도면.
도 3은 본 발명의 일 실시예에 따른 멀티캐스트 전송 방법의 단계들을 나타내는 흐름도.

도 1을 참조하면, 본 발명의 일 실시예에 따른 멀티호밍 유니캐스트 프로토콜, 특히 SCTP를 이용하는 전송 시스템(2)의 개략적인 도면이 도시되어 있다.

전송 시스템(2)은 SCTP 관리 모듈(5)을 포함하는 서버(4), 수신기 모듈(7,9)을 각각 포함하는 제1 클라이언트(6)와 제2 클라이언트(8)를 포함한다. 도 1이 2개의 클라이언트들을 도시하고 있지만, 시스템(2)은 2개의 클라이언트들에 의한 동작에 한정되지 않고, 1개 내지 복수의 클라이언트들을 지원할 수도 있다.

서버(4)는 클라이언트(6,8)에 전달될 컨텐츠를 포함하는 저장 매체를 포함한다. 바람직하게는, 서버(4)는 클라이언트 장치들의 특성들, 예를 들어 재생 능력, 스크린 해상도, 그리고 클라이어트(6,8)가 멀티캐스트 접속 외에 유니캐스트 접속을 확립하였는지의 여부 등을 추적할 수 있게 하는 클라이언트 상태나 프로파일 정보를 보유한다. 따라서, 이 상태 정보는 일부 클라이언트에 대한 타겟 컨텐츠를, 예컨대, 상이한 사운드 트랙이나, 개선된 품질로서 선택적으로 추가하는 데 사용될 수 있다.

각 개별 클라이언트(6,8)는 서버(4)와의 데이터 패킷들을 교환하는 데 사용되는 일부 IP 주소들을 포함할 수 있다. 개별 클라이언트의 IP 주소들은 서버(4)의 IP 주소와의 통신 경로들을 생성하여 개별 클라이언트(6,8)와 서버(4) 사이의 데이터 패킷의 교환을 용이하게 하는데 사용된다. 또한, 서버(4)는 복수의 액세스 네트워크들을 통해 개별 클라이언트(6,8)와의 통신 경로들을 형성할 수 있다.

예를 들어, 도 1에 도시된 바와 같이, 서버(4)는, 예컨대 3GPP(3rd Generation Partnership Project) 유니캐스트 네트워크에 대응하는 유니캐스트 액세스 경로(10,12)를 통해 클라이언트(6,8)와 각각 통신할 수 있다.

본 발명에 따르면, 서버(4)는 또한, 예를 들면 3GPP MBMS(Multimedia Broadcast and Multicast Services) 네트워크와 DVB-H(Digital Video Broadcasting - Handheld) 네트워크에 각각 대응하는 유니캐스트 액세스 경로(14,16)를 통해 클라이언트(6,8)와 통신할 수 있다.

서버(4)에 상주하는 SCTP 프로토콜 스택(18)은 클라이언트들이 자신의 유니캐스트 주소들을 연결(association)에 추가할 때마다 새로운 클라이언트 주소들을 등록하는, 서버(4)와 클라이언트(6,8) 사이의 멀티캐스트 연결을 취급한다. 이것은 데이터 청크들을 멀티캐스트 접속을 통해 클라이언트(6,8)에 전송하고, 클라이언트(6,8)가 명시적으로 요청한 경우에는, 개별 클라이언트(6,8)를 향하는 유니캐스트 접속들을 이용하여 데이터를 선택적으로 전달하거나 또는 데이터를 재전송한다.

도 1이 3개의 액세스 네트워크들을 도시하고 있으나, 시스템은 3개의 액세스 네트워크들과의 동작에만 한정되는 것은 아니고, 유니캐스트 또는 멀티캐스트 데이터 전송 중 어느 하나를 지원하는 1개 내지 복수의 액세스 네트워크와 서버(4) 사이의 접속 경로들을 지원할 수 있다.

유니캐스트 경로(10,12)는 서버(4)와 각각의 클라이언트(6,8) 사이의 양방향 업링크 및 다운링크에 유니캐스트 통신 지원 기능을 제공한다.

멀티캐스트 경로(14,16)는 단방향 다운링크들만을 지원한다. 그 결과, 멀티캐스트 경로(14,16)를 통해 각각의 클라이언트(6,8)로부터 서버(4)로의 어떠한 피드백 채널도 이용 가능하지 않다.

또한, 클라이언트(6,8)는 복수의 네트워크 인터페이스들을 구비할 수 있으며, 서로 다른 타입의 통신 네트워크들을 통해서 원격 시스템과 접속할 수 있다. 구체적으로, 클라이언트(6,8)는 전술한 3개의 액세스 네트워크 모두를 통해 원격 시스템에 접속할 수 있고, 그에 따라, 유니캐스트 양방향 링크와 멀티캐스트 단방향 링크를 모두 가질 수 있다.

각각의 클라이언트(6,8)는 데이터 파일들을 처리하거나, 어플리케이션을 실행하거나, 데이터를 송신, 수신, 및 처리하는 명령어들을 위한 서버와 통신하는 것이 가능한, 예컨대 컴퓨터나 모바일 장치등의 하드웨어 장치일 수 있다.

클라이언트(6,8)는 특정 기능을 수행할 수 있도록 서버(4)로부터 컨텐츠를 요구할 수 있다. 예를 들면, 클라이언트(6,8)는 사용자를 위해 적절하게 데이터를 처리하고 디스플레이하기 위해 서버(4)로부터 특정 데이터를 수신해야 하는 오디오/비디오 장치일 수 있다. 따라서, 데이터 전송을 용이하게 하기 위해 클라이언트(6,8)와 서버(4) 사이의 연결(association)들이 요구된다.

본 발명에 따르면, 혼합형 멀티캐스트/유니캐스트 전송은 SCTP 계층, 즉 SCTP 프로토콜 스택(18)에 의해 조절된다.

예를 들면, 약간 개선된 소켓 API(Application Programming Interfaces)로 이루어진 인터페이스들(20,22,24)은 연결 파라미터들을 판독 및 수정하기 위해 서버(4) 측, 클라이언트(6) 측, 및 클라이언트(8) 측에서 각각 이용된다. 개선된 소켓 API(20,22,24)는 유니캐스트 접속을 확립한 클라이언트들의 리스트를 판독하는 것을 허용한다.

서버(4)와 클라이언트(6,8) 사이의 연결은 멀티링크 측을 통한 서버(4) 또는 업링크 경로(10,12)를 통한 클라이언트(6,8)에 의해 초기화된다.

SCTP 연결은 종래의 4가지 방식의 핸드쉐이크(hand shake)를 통해 초기화된다. 물론, 이러한 접속의 설정은, 경로(10,12)로서 업링크 경로가 이용가능한 경우에는 클라이언트에 의해서만 이용될 수 있다.

본 발명의 제1 실시예에 따르면, 이 연결은 RFC 4960에 정의된 INIT 청크와는 상이한 BINIT라고 불리는 초기화 청크를 사용한다. 이 청크는 멀티캐스트 경로(14,16)를 통해 규칙적으로 브로드캐스트되고, SCTP 연결에 의해 반송되는 아웃바운드 스트림들의 수를 광고한다.

도 2에는 본 발명의 청크 BINIT(30)의 초기화에 대한 일례가 도시되어 있다.

BINIT 청크는 SCTP 연결의 INIT 청크의 다음과 같은 종래의 필드들을 포함한다.

- 소스 포트 번호 32 : 이 필드는 SCTP 송신기의 포트 번호를 식별한다. 이것은 소스 IP 주소, SCTP 목적지 포트, 및 이 패킷이 속하는 연결을 식별하기 위해 가능한 목적지 IP 주소와 결합된 수신기에 의해 사용될 수 있다.

- 목적지 포트 번호 34 : 이 필드는 패킷용으로 고려된 SCTP 포트 번호를 식별한다. 수신 호스트는 SCTP 패킷을 올바른 수신 종점/어플리케이션으로 역다중화하기 위해 이 포트 번호를 이용할 것이다.

- 검증 태그 36 : 이 필드는 고려된 SCTP 패킷의 송신기를 검증하는 데 사용된다. 양방향, 즉 레거시 SCTP 연결의 경우, 이 검증 태그의 값은 연결의 초기화 동안 피어 종점(peer endpoint)으로부터 수신된 개시 태그의 값으로 설정된다. 본 발명의 바람직한 실시예에 따르면, 어떠한 클라이언트와의 핸드쉐이크도 없이 서버(4)로부터 멀티캐스트 목적지와의 연결이 개시될 수 있으므로, 이 검증 태그는 멀티캐스트 연결의 시작에서 랜덤하게 선택된 값으로 설정된다.

- 체크섬 38 : 이 필드는 고려된 SCTP 패킷의 체크섬을 포함한다.

- 청크 타입 40 : 이 필드는 청크 데이터에 포함된 정보의 유형을 식별한다.

- 청크 플래그 42 : 이 필드의 사용은 청크 타입에 의존한다.

- 청크 길이 44 : 이 필드는 청크의 크기를 바이트로 나타낸다.

- 개시 태그 46 : 이 필드의 값은 INIT 청크의 검증 태그의 컨텐츠를 설정하기 위해 양방향 접속을 개시하기를 원하는 클라이언트에 의해 사용된다.

- 초기 TSN 48 : 이 필드는 사용될 초기의 전송 시퀀스 번호를 나타낸다.

- 리저브드(Reserved) 50 : 이 필드는 장래의 사용을 위해 보존된다.

- 선택적/가변적-길이 파라미터 52 : 이 필드는 옵션 파라미터들을 포함한다.

또한, 본 발명의 제1 실시예에 따르면, BINIT 청크는 새로운 필드(54)를 포함한다. 새로운 필드(54)는 연결에 의해 전달되는 아웃바운드 스트림들의 수를 포함하고, INIT 청크에서 발견되는 숫자나 아웃바운드 스트림 필드와 동일하게 코딩된다. 일단 연결이 확립되고 나서 이 정보가 정상적으로 광고되지 않는 경우, 이 값은 상기 연결에 참여하는 클라이언트로 하여금 얼마나 많은 스트림들이 그 연결의 일부인지 알 수 있게 한다.

도 3의 흐름도는 제1 실시예에 따른 본 발명의 방법의 단계들을 도시한다.

단계(60)에서, 서버(4)는 멀티캐스트 경로(16)를 통해 BINIT 청크(30)를 규칙적으로 브로드캐스트한다.

업링크의 경우, 유니캐스트 경로(10,12)를 이용하는 경우와 같이, 클라이언트(6,8)는 BINIT 청크를 대기할 것이며, 단계(62)에서, 후속하는 4가지 방식의 핸드쉐이크를 개시하는 INIT 청크에서의 검증 태그 값으로서 개시 태그값을 사용한다. 인입하는 INIT 청크를 처리하는 서버(4)는 클라이언트가 새로운 "레거시" SCTP 연결을 설정하려는 시도를 하지 않음을 나타내는 비 널 검증 태그(non null verification tag)를 검출한다. 대신에, 수신된 검증 태그 값은 서버(4)로 하여금 클라이언트가 자신의 양방향 경로를 이용하여 참여하기를 희망하는 멀티캐스트 SCTP 연결을 식별할 수 있게 한다. 클라이언트와의 4가지 방식의 핸드쉐이크의 나머지를 처리한 이후에, 서버의 SCTP 프로토콜 스택(18)은 클라이언트의 IP 주소를 기존의 멀티캐스트 연결에 통합할 것이다.

단계(64)에서, 서버(10)는 자신의 BINIT 청크 및 가능성 있는 후속하는 INIT ACK 청크(들)에서 옵션 필드(52)를 통해, 자신이 지원하는 IPv4/IPv6 주소들의 세트와 멀티캐스트 경로(14,16)에 사용되는 멀티캐스트 주소들의 리스트를 나타낸다. 주소들은 INIT 청크들에 대해 RFC 4960에 따라 암호화된다.

본 발명의 제2 실시예에 따르면, 연결의 특성들은 SDP 파일에 기술되어 있다. 이러한 파일은 임의의 가능한 수단에 의해 클라이언트(6,8)가, 예컨대 서비스 가이드의 일부로서 이용가능하거나, 또는 네트워크 운영자에 의해 미리 로딩되도록 만들어진다.

업링크 접속을 개시하기를 희망하는 클라이언트(6,8)의 경우에는 상이한 매커니즘이 사용된다. 실제로, 상기 서버는 멀티캐스트 링크를 통해 송신된 모든 청크들의 검증 태그를 서버에 의한 연결의 초기화 시에 선택되는 고정된 값으로 설정한다. 클라이언트(6,8)는 멀티캐스트 링크(16)를 통해 수신된 청크들에서 발견된 검증 태그의 값으로 설정된 검증 태그를 갖는 INIT 청크를 송신한다. 이것은 클라이언트(6,8)가 이 유니캐스트 링크를 기존의 연결에 추가하기를 희망하고 새로운 연결을 개시하기를 희망하지 않는다는 것을 서버(4)에 알려준다. 개시 태그는 종래의 SCTP 핸드쉐이크에서와 같이 클라이언트(6,8)에 의해 선택된 값으로 설정된다. 서버(4)는 클라이언트(6,8)에 의해 제공된 개시 태그의 값으로 설정된 검증 태그를 갖는 INIT ACK 청크를 이용하여 응답한다.

서버(4)의 관점에서, 어플리케이션이 1개 내지 다수의 SCTP 소켓들을 개방한다. 그러나, 소켓을 생성하는 경우, 종래의 SOCK_SEQPACKET 대신에 SOCK_DGRAM 유형이 이용된다. 이것은 사실상 내부 접속(underlying connection)의 비 접속적 성질을 나타낸다. 또한, 이는 잠재적인 점 대 점(point-to-point) 연결이 설정될 수 있음을 SCTP 프로토콜 스택(18)에 알려준다.

그 후에, 서버(4)의 어플리케이션은 통상적인 소켓 API 호출을 이용하여 데이터를 전송한다.

그 후, BINIT 청크들을 생성하고, 멀티캐스트 경로(14,16)를 통해 트래픽 분배를 개시하는 것은 SCTP 프로토콜 스택(18)에 따른다.

클라이언트(6,8)의 관점에서, 어플리케이션은 SOCK_DGRAM 유형에서와 마찬가지로 1개 내지 다수의 SCTP 소켓들을 생성한다. 클라이언트(6,8) 프로그래밍 모델은 종래의 멀티캐스트 수신기와 유사한 것처럼 보인다. 이는 IGMP를 조절하기 위해 IP_ADD_MEMBERSHIP 옵션을 갖는 소켓 API로부터 표준 setsockopt 함수를 호출한다. 그 후, 클라이언트(6,8)는 특정 멀티캐스트가 가능한 인터페이스와 소켓을 결합시키고 인입 패킷을 대기한다.

그 후, 대응하는 멀티캐스트 트래픽을 리스닝(listen)하고, 만약 가능한 경우에 소스 SCTP 종점과의 새로운 유니캐스트 연결을 생성하는 것은 SCTP 프로토콜 스택(18)에 따른다.

클라이언트(6,8)의 관점에서, 트래픽은 통상적인 소켓에서와 마찬가지로 SCTP 소켓으로부터 판독된다. 추가적인 업링크를 구비함으로써, 소실된 패킷들의 재전송을 클라이언트(6,8)에게 명확히 요청할 가능성을 SCTP 소켓에게 제공한다.

도 1의 특정 사용의 경우에, 하나 보다 많은 멀티캐스트 분배 매커니즘이 존재하며, 예를 들어 DVB-H와 MBMS에 대해, 소켓 API를 통해 멀티캐스트 경로를 사후적으로 추가하는 것이 가능하다.

현저하게도, 본 발명은 다운스트림 멀티캐스트 분배와 선택적 양방향 유니캐스트 링크들을 전송 계층에서 통합한다. 멀티캐스트 UDP에 영향을 주는(leveraging) 레거시 어플리케이션은 거의 변경없이 재사용될 수 있다. 다수의 클라이언트들은 분배 네트워크를 플러딩(flooding)하지 않고도 멀티캐스트 스트림을 수신할 수 있는데, 이는 멀티캐스트가 네트워크에 의해 지원되는 경우에 데이터의 복제가 방지되기 때문이다. 추가적인 대역폭으로 인해 사용자의 경험을 증가시키거나, 또는 네트워크 커버리지로 인해 멀티캐스트가 사용가능하지 않은 지역에서 서비스의 연속성을 보장하는 데 사용되는 어플리케이션을 위해, 추가적인 양방향 유니캐스트 링크들이 클라이언트에 의해 명확히 확립될 수 있다.

지금까지 본 발명의 바람직한 실시예인 것으로 고려되는 것들에 대해 기술되고 설명되었지만, 당업자라면 본 발명의 본래의 범위 내에서 그 외 다양한 변경이 행해질 수 있으며, 또한 균등물로 대체될 수 있음을 이해할 것이다. 또한, 본 명세서에 기술된 중심된 발명의 개념 내에서 특정 상황을 본 발명의 교시로 채용할 수 있는 수많은 변형들이 이루어질 수 있다. 또한, 본 발명의 실시예들은 전술한 특징들을 모두 포함하는 것은 아닐 수도 있다. 따라서, 본 발명은 개시된 특정의 실시예에만 한정되는 것은 아니며, 첨부된 청구항들의 범위 내에 속하는 모든 실시예들을 포함하는 것으로 의도된 것이다.

"포함하다(comprise, include, incorporate, contain)", "이다(is)", 및 "갖는다(have)" 등의 표현은 상세한 설명과 이와 연관된 청구항들을 해석할 시에 배타적이지 않은 방식으로, 즉 명확하게 정의되지 않은 다른 항목들이나 구성요소들이 존재할 수도 있는 것으로 해석되어야 한다. 또한, 단수형에 대한 지칭은 복수형에 대한 지칭으로도 해석되며, 또한 그 역도 성립한다.

상세한 설명에 기술된 다양한 파라미터들은 변경될 수도 있으며, 또한 개시 및/또는 주장되는 각종 실시예들은 본 발명의 범위 내에서 결합될 수도 있음을 당업자라면 충분히 이해할 것이다.

Claims

유니캐스트 프로토콜을 이용하여 복수의 클라이언트(6,8) 중 적어도 하나와 서버(4) 사이의 멀티캐스트 전송을 위한 방법으로서,
상기 서버(4)와 상기 클라이언트(6,8) 사이의 멀티캐스트 경로(16) 및 유니캐스트(10,12) 경로의 결합 동작(joint operation)을 가능하게 하기 위해, 상기 클라이언트(6,8)가 멀티캐스트 경로(16)를 통해 상기 서버(4)와 통신할 수 있도록 허용하는 정보를 상기 서버(4)가 상기 클라이언트(6,8)에게 제공하는(60) 단계
를 포함하는 방법.
제1항에 있어서,
상기 유니캐스트 프로토콜은 멀티호밍 프로토콜인 방법.
제2항에 있어서,
상기 멀티호밍 프로토콜은 SCTP(Stream Control Transmission Protocol)이거나, 또는 SCTP의 확장인 방법.
제3항에 있어서,
상기 클라이언트(6,8)가 멀티캐스트 경로(16)를 통해 상기 서버(4)와 통신할 수 있도록 허용하는 정보는 SCTP 연결(association)을 초기화하는 것을 허용하는 초기화 정보를 포함하는 방법.
제4항에 있어서,
상기 초기화 정보는 상기 멀티캐스트 경로(16)를 통해 규칙적으로 브로드캐스트되는 초기화 청크(30) 내에서 전달되는 방법.
제5항에 있어서,
상기 초기화 청크(30)는 SCTP 연결에 의해 전달되는 아웃바운드 스트림(outbound stream)들의 수를 광고(advertising)하는 필드(54)를 포함하는 방법.
제5항 또는 제6항에 있어서,
상기 초기화 청크(30)는 서버(4)에 의해 지원되는 적어도 하나의 IP 주소를 포함하는 방법.
제4항에 있어서,
상기 초기화 정보는 상기 클라이언트(6,8)가 이용가능하도록 만들어진 파일내에 기술되어 있는 방법.
제4항 내지 제8항 중 어느 한 항에 있어서,
상기 클라이언트(6,8)에 의해 SCTP 연결을 초기화하는 단계(62)를 포함하는 방법.
유니캐스트 프로토콜을 이용하여 복수의 클라이언트(6,8) 중 적어도 하나와 통신할 수 있는 서버(4)로서,
상기 서버(4)와 상기 클라이언트(6,8) 사이의 멀티캐스트 경로(16) 및 유니캐스트 경로(10,12)의 결합 동작을 가능하게 하기 위해, 상기 클라이언트(6,8)가 멀티캐스트 경로(16)를 통해 상기 서버(4)와 통신할 수 있도록 허용하는 정보를 상기 클라이언트(6,8)에 제공하기 위한 관리 모듈(5)
을 포함하는 서버(4).
제10항에 있어서,
상기 유니캐스트 프로토콜은 SCTP(Stream Control Transmission Protocol)이거나 또는 SCTP의 확장이고, 상기 클라이언트(6,8)가 상기 멀티캐스트 경로(16)를 통해 상기 서버(4)와 통신할 수 있도록 허용하는 정보는 SCTP 연결을 초기화하는 것을 허용하는 초기화 정보를 포함하는 서버(4).
유니캐스트 프로토콜을 이용하여 서버(4)와 통신할 수 있는 클라이언트(6,8)로서,
상기 서버(4)와 상기 클라이언트(6,8) 사이의 멀티캐스트 경로(16) 및 유니캐스트 경로(10,12)의 결합 동작을 가능하게 하기 위해, 상기 클라이언트(6,8)가 멀티캐스트 경로(16)를 통해 상기 서버(4)와 통신할 수 있도록 허용하는 정보를 수신하기 위한 수신기 모듈(7,9)
을 포함하는 클라이언트(6,8).
제12항에 있어서,
유니캐스트 프로토콜은 SCTP(Stream Control Transmission Protocol)이거나 또는 SCTP의 확장이고, 클라이언트(6,8)가 멀티캐스트 경로(16)를 통해 서버(4)와 통신할 수 있도록 허용하는 정보는 SCTP 연결을 초기화하는 것을 허용하는 초기화 정보를 포함하는 클라이언트(6,8).
컴퓨터로 하여금 제1항 내지 제9항 중 어느 한 항의 방법의 단계들을 수행할 수 있게 하는 컴퓨터-실행가능 명령어들을 포함하는 컴퓨터 판독가능 프로그램.