KR102593734B1 - 클라우드 네트워크를 이용한 방송 게이트웨이 시그널링 방법 및 이를 위한 장치 - Google Patents
클라우드 네트워크를 이용한 방송 게이트웨이 시그널링 방법 및 이를 위한 장치 Download PDFInfo
- Publication number
- KR102593734B1 KR102593734B1 KR1020210012830A KR20210012830A KR102593734B1 KR 102593734 B1 KR102593734 B1 KR 102593734B1 KR 1020210012830 A KR1020210012830 A KR 1020210012830A KR 20210012830 A KR20210012830 A KR 20210012830A KR 102593734 B1 KR102593734 B1 KR 102593734B1
- Authority
- KR
- South Korea
- Prior art keywords
- packet
- stl
- transmitter
- stream
- time
- Prior art date
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
- H04N21/64—Addressing
- H04N21/6408—Unicasting
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04H—BROADCAST COMMUNICATION
- H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
- H04H60/76—Arrangements characterised by transmission systems other than for broadcast, e.g. the Internet
- H04H60/81—Arrangements characterised by transmission systems other than for broadcast, e.g. the Internet characterised by the transmission system itself
- H04H60/82—Arrangements characterised by transmission systems other than for broadcast, e.g. the Internet characterised by the transmission system itself the transmission system being the Internet
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/21—Server components or server architectures
- H04N21/222—Secondary servers, e.g. proxy server, cable television Head-end
- H04N21/2223—Secondary servers, e.g. proxy server, cable television Head-end being a public access point, e.g. for downloading to or uploading from clients
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/61—Network physical structure; Signal processing
- H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
- H04N21/6125—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via Internet
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
- H04N21/643—Communication protocols
- H04N21/6437—Real-time Transport Protocol [RTP]
Landscapes
- Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
클라우드 네트워크를 이용한 방송 게이트웨이 시그널링 방법 및 이를 위한 장치가 개시된다. 본 발명의 일실시예에 따른 방송 게이트웨이 시그널링 방법은 터널링 시스템의 이너 레이어(INNER LAYER)에 상응하는 이너 패킷(INNER PACKET)을 이용하여 상기 터널링 시스템의 아우터 레이어(OUTER LAYER)에 상응하는 아우터 패킷(OUTER PACKET)을 생성하는 단계; 및 상기 아우터 패킷의 헤더를 생성하고, 상기 아우터 패킷을 스튜디오-투-송신기 링크(Studio to Transmitter Link; STL)를 통해 송신기로 송신하는 단계를 포함하고, 상기 헤더는 상기 아우터 패킷에 상응하는 STL 스트림에 대한 수신 대기 시간을 나타내는 STL 전파 지연시간 필드를 포함한다.
Description
본 발명은 클라우드 네트워크를 이용한 방송 게이트웨이 시그널링 기술에 관한 것으로, 특히 클라우드 환경을 이용하여 ATSC 3.0 방송 게이트웨이(Broadcast Gateway)와 다수의 송신기들(Transmitters) 사이에 STL(Studio-to-Transmitter Link) 스트림을 효율적인 유니캐스트 전송할 수 있는 기술에 관한 것이다.
국내 지상파 UHDTV 방송기술 표준은 ATSC 3.0 북미 지상파방송 표준 규격에 기반하여 상용서비스를 제공 중이다. ATSC 3.0 환경에서 방송 스트림의 안정적인 송출을 위해 방송 게이트웨이와 송신기 간의 네트워크 구간(STL)은 주로 전용망(마이크로 웨이브, 전용 IP 회선 등)을 사용하였다. 그러나, 송신기의 개수가 늘어날수록 방송사가 부담해야 하는 전용망의 통신비 비용은 높아지게 된다. 현재까지 ATSC 3.0 STL/SFN 표준(A/324)에서는 방송 게이트웨이가 전용망을 통한 IP/UDP 멀티캐스트 스트림을 송출하거나, 공중망(인터넷)을 통한 중복된 유니캐스트 스트림(최대 3개)을 송출하도록 정의되어 있다. 전자는 전용망 비용에 대한 부담이 크고, 후자는 동일한 스트림을 중복 송출하여 망에 대한 트래픽 부하를 높일 수 있다.
본 발명의 목적은 클라우드 환경에서의 엣지 클라우드를 활용하여 효율적인 STL 유니캐스트 패킷 전송을 보장하고, 송신기들마다 발생하는 전용망 비용 부담을 효과적으로 감소시키는 것이다.
또한, 본 발명의 목적은 보편화된 클라우드 인프라를 활용하여 ATSC 3.0 표준규격을 최대한 준수함과 동시에 기존의 방송 게이트웨이와 송신기 간의 STL 구간의 전용망 사용 비용을 감소시키는 것이다.
또한, 본 발명의 목적은 일방향의 유니캐스트 스트림으로 빠른 전송과 함께 발생 가능한 패킷 유실이나 지연에 대해서 엣지 클라우드를 활용하여 복구 패킷을 수신하여 대응할 수 있도록 하는 것이다.
상기한 목적을 달성하기 위한 본 발명에 따른 방송 게이트웨이 시그널링 방법은 터널링 시스템의 이너 레이어(INNER LAYER)에 상응하는 이너 패킷(INNER PACKET)을 이용하여 상기 터널링 시스템의 아우터 레이어(OUTER LAYER)에 상응하는 아우터 패킷(OUTER PACKET)을 생성하는 단계; 및 상기 아우터 패킷의 헤더를 생성하고, 상기 아우터 패킷을 스튜디오-투-송신기 링크(Studio to Transmitter Link; STL)를 통해 송신기로 송신하는 단계를 포함하고, 상기 헤더는 상기 아우터 패킷에 상응하는 STL 스트림에 대한 수신 대기 시간을 나타내는 STL 전파 지연시간 필드를 포함한다.
이 때, STL 전파 지연시간 필드는 6비트 필드이고, 밀리세컨드(MILLISECONDS) 단위에 상응하는 '0'부터 '63'사이의 정수로 설정될 수 있다.
이 때, 수신 대기 시간은 상기 송신기가 상기 아우터 패킷을 이용하여 RF 채널로 송신할 방송 송신 신호를 구성하는 시간에 상응할 수 있다.
이 때, 송신기로 송신된 아우터 패킷에 손실이 발생한 경우, 상기 수신 대기 시간 동안에 손실 패킷 복구 프로세스가 반복적으로 수행될 수 있다.
이 때, 손실 패킷 복구 프로세스는 클라우드 인프라(CLOUD INFRA) 환경에서 엣지 클라우드 노드에 상응하게 동작하는 STL 스트림 캐시 서버(STUDIO TO TRANSMITTER LINK STREAM CACHE SERVER)를 통해 수행될 수 있다.
이 때, 아우터 패킷은 RTP/UDP/IP 멀티캐스트 프로토콜 스택(multicast protocol stack)을 통하여 멀티캐스트 패킷(MULTICAST PACKET)에 상응하게 상기 STL 스트림 캐시 서버로 송신되고, RTP/UDP/IP 유니캐스트 프로토콜 스택(unicast protocol stack)을 통하여 유니캐스트 패킷(UNICAST PACKET)에 상응하게 상기 송신기로 송신될 수 있다.
이 때, STL 스트림 캐시 서버로 송신된 아우터 패킷 중 상기 수신 대기 시간이 종료되지 않은 패킷에 대한 캐시 풀(CACHE POOL)이 구성될 수 있다.
이 때, 키 전달 프로세스(KEY DELIVERY PROCESS)를 기반으로 상기 송신기와 상호 간에 공개키를 공유하는 단계; 송신기 공개키를 이용하여 상기 송신기로부터 수신된 수신등록 요청 메시지에 대한 인증을 수행하는 단계; 및 상기 인증이 성공한 경우, 상기 송신기에게 상기 STL 스트림 캐시 서버의 주소 정보를 제공하는 단계를 더 포함할 수 있다.
이 때, 상기 수신등록 요청 메시지는 메시지 시퀀스 번호, 송신기 공개키 식별자, UDP 포트 값 및 상기 송신기 개인키 서명을 포함하고, 상기 송신기 공개키로 상기 송신기 개인키 서명에 의한 메시지 인증코드를 확인하여 상기 인증을 수행할 수 있다.
이 때, STL 스트림 캐시 서버와 상기 송신기 공개키를 공유하는 단계를 더 포함하고, 상기 손실 패킷 복구 프로세스는 상기 송신기 공개키를 기반으로 상기 송신기가 상기 STL 스트림 캐시 서버로 송신한 복구 패킷 요청 메시지에 대한 인증이 성공하는 경우에 수행될 수 있다.
이 때, 수신 대기 시간 동안에 손실된 패킷이 복구되지 못한 경우, 손실된 패킷을 널(NULL) 패킷 입력 및 손실 패킷 폐기 중 적어도 하나에 상응하게 처리할 수 있다.
이 때, 이너 패킷은 상기 아우터 패킷을 통하여(THROUGH) 인캡슐레이션될 수 있다.
이 때, 터널링 시스템은 상기 이너 패킷에 상응하는 병렬적이고 독립적인(parallel and independent) 패킷 스트림들의 그룹이 상기 아우터 패킷에 상응하는 하나의 패킷 스트림 내에서 옮겨(carried)질 수 있다.
또한, 본 발명의 일실시예에 따른 방송 게이트웨이 장치는 터널링 시스템의 이너 레이어(INNER LAYER)에 상응하는 이너 패킷(INNER PACKET)을 이용하여 상기 터널링 시스템의 아우터 레이어(OUTER LAYER)에 상응하는 아우터 패킷(OUTER PACKET)을 생성하고, 상기 아우터 패킷의 헤더를 생성하고, 상기 아우터 패킷을 스튜디오-투-송신기 링크(Studio to Transmitter Link; STL)를 통해 송신기로 송신하는 프로세서; 및 상기 아우터 패킷을 저장하는 메모리를 포함하고, 상기 헤더는 상기 아우터 패킷에 상응하는 STL 스트림에 대한 수신 대기 시간을 나타내는 STL 전파 지연시간 필드를 포함한다.
이 때, STL 전파 지연시간 필드는 6비트 필드이고, 밀리세컨드(MILLISECONDS) 단위에 상응하는 '0'부터 '63'사이의 정수로 설정될 수 있다.
이 때, 수신 대기 시간은 상기 송신기가 상기 아우터 패킷을 이용하여 RF 채널로 송신할 방송 송신 신호를 구성하는 시간에 상응할 수 있다.
이 때, 송신기로 송신된 아우터 패킷에 손실이 발생한 경우, 상기 수신 대기 시간 동안에 손실 패킷 복구 프로세스가 반복적으로 수행될 수 있다.
이 때, 손실 패킷 복구 프로세스는 클라우드 인프라(CLOUD INFRA) 환경에서 엣지 클라우드 노드에 상응하게 동작하는 STL 스트림 캐시 서버(STUDIO TO TRANSMITTER LINK STREAM CACHE SERVER)를 통해 수행될 수 있다.
이 때, 아우터 패킷은 RTP/UDP/IP 멀티캐스트 프로토콜 스택(multicast protocol stack)을 통하여 멀티캐스트 패킷(MULTICAST PACKET)에 상응하게 상기 STL 스트림 캐시 서버로 송신되고, RTP/UDP/IP 유니캐스트 프로토콜 스택(unicast protocol stack)을 통하여 유니캐스트 패킷(UNICAST PACKET)에 상응하게 상기 송신기로 송신될 수 있다.
이 때, STL 스트림 캐시 서버로 송신된 아우터 패킷 중 상기 수신 대기 시간이 종료되지 않은 패킷에 대한 캐시 풀(CACHE POOL)이 구성될 수 있다.
이 때, 프로세서는 키 전달 프로세스(KEY DELIVERY PROCESS)를 기반으로 상기 송신기와 상호 간에 공개키를 공유하고, 송신기 공개키를 이용하여 상기 송신기로부터 수신된 수신등록 요청 메시지에 대한 인증을 수행하고, 상기 인증이 성공한 경우, 상기 송신기에게 상기 STL 스트림 캐시 서버의 주소 정보를 제공할 수 있다.
이 때, 상기 수신등록 요청 메시지는 메시지 시퀀스 번호, 송신기 공개키 식별자, UDP 포트 값 및 상기 송신기 개인키 서명을 포함하고, 상기 송신기 공개키로 상기 송신기 개인키 서명에 의한 메시지 인증코드를 확인하여 상기 인증을 수행할 수 있다.
이 때, 프로세서는 STL 스트림 캐시 서버와 상기 송신기 공개키를 공유할 수 있고, 상기 손실 패킷 복구 프로세스는 상기 송신기 공개키를 기반으로 상기 송신기가 상기 STL 스트림 캐시 서버로 송신한 복구 패킷 요청 메시지에 대한 인증이 성공하는 경우에 수행될 수 있다.
이 때, 수신 대기 시간 동안에 손실된 패킷이 복구되지 못한 경우, 손실된 패킷을 널(NULL) 패킷 입력 및 손실 패킷 폐기 중 적어도 하나에 상응하게 처리할 수 있다.
이 때, 이너 패킷은 상기 아우터 패킷을 통하여(THROUGH) 인캡슐레이션될 수 있다.
이 때, 터널링 시스템은 상기 이너 패킷에 상응하는 병렬적이고 독립적인(parallel and independent) 패킷 스트림들의 그룹이 상기 아우터 패킷에 상응하는 하나의 패킷 스트림 내에서 옮겨(carried)질 수 있다.
본 발명에 따르면, 클라우드 환경에서의 엣지 클라우드를 활용하여 효율적인 STL 유니캐스트 패킷 전송을 보장하고, 송신기들마다 발생하는 전용망 비용 부담을 효과적으로 감소시킬 수 있다.
또한, 본 발명은 보편화된 클라우드 인프라를 활용하여 ATSC 3.0 표준규격을 최대한 준수함과 동시에 기존의 방송 게이트웨이와 송신기 간의 STL 구간의 전용망 사용 비용을 감소시킬 수 있다.
또한, 본 발명은 일방향의 유니캐스트 스트림으로 빠른 전송과 함께 발생 가능한 패킷 유실이나 지연에 대해서 엣지 클라우드를 활용하여 복구 패킷을 수신하여 대응할 수 있도록 할 수 있다.
도 1은 본 발명의 일실시예에 따른 방송 신호 송신 시스템을 나타낸 블록도이다.
도 2는 본 발명의 일실시예에 따른 방송 게이트웨이 시그널링 방법을 나타낸 동작 흐름도이다.
도 3은 본 발명에 따른 방송 게이트웨이 장치의 일 예를 나타낸 도면이다.
도 4는 본 발명에 따른 아우터 패킷의 헤더 구조의 일 예를 나타낸 도면이다.
도 5는 본 발명에 따른 수신 대기 시간 동안의 손실 패킷 복구 프로세스의 일 예를 나타낸 도면이다.
도 6은 본 발명의 일실시예에 따른 손실 패킷 복구를 위한 방송 신호 송신 시스템을 나타낸 블록도이다.
도 7은 본 발명의 일실시예에 따른 손실 패킷 복구 프로세스를 나타낸 블록도이다.
도 8은 본 발명의 일실시예에 따른 손실 패킷 복구 프로세스를 상세하게 나타낸 도면이다.
도 9는 본 발명의 일실시예에 따른 방송 게이트웨이 장치를 나타낸 블록도이다.
도 10은 본 발명의 일실시예에 따른 컴퓨터 시스템을 나타낸 도면이다.
도 2는 본 발명의 일실시예에 따른 방송 게이트웨이 시그널링 방법을 나타낸 동작 흐름도이다.
도 3은 본 발명에 따른 방송 게이트웨이 장치의 일 예를 나타낸 도면이다.
도 4는 본 발명에 따른 아우터 패킷의 헤더 구조의 일 예를 나타낸 도면이다.
도 5는 본 발명에 따른 수신 대기 시간 동안의 손실 패킷 복구 프로세스의 일 예를 나타낸 도면이다.
도 6은 본 발명의 일실시예에 따른 손실 패킷 복구를 위한 방송 신호 송신 시스템을 나타낸 블록도이다.
도 7은 본 발명의 일실시예에 따른 손실 패킷 복구 프로세스를 나타낸 블록도이다.
도 8은 본 발명의 일실시예에 따른 손실 패킷 복구 프로세스를 상세하게 나타낸 도면이다.
도 9는 본 발명의 일실시예에 따른 방송 게이트웨이 장치를 나타낸 블록도이다.
도 10은 본 발명의 일실시예에 따른 컴퓨터 시스템을 나타낸 도면이다.
본 발명을 첨부된 도면을 참조하여 상세히 설명하면 다음과 같다. 여기서, 반복되는 설명, 본 발명의 요지를 불필요하게 흐릴 수 있는 공지 기능, 및 구성에 대한 상세한 설명은 생략한다. 본 발명의 실시형태는 당 업계에서 평균적인 지식을 가진 자에게 본 발명을 보다 완전하게 설명하기 위해서 제공되는 것이다. 따라서, 도면에서의 요소들의 형상 및 크기 등은 보다 명확한 설명을 위해 과장될 수 있다.
이하, 본 발명에 따른 바람직한 실시예를 첨부된 도면을 참조하여 상세하게 설명한다.
최근 클라우드 인프라(CLOUD INFRA) 증가와 인터넷 품질 향상(패킷 전달 손실 및 지연 감소)으로 공중망을 이용한 인터넷 서비스 제공 기대가 높아지는 상황이다. 이에 본 발명에서는 클라우드 인프라 환경을 활용하여 공중망에서도 안정적인 STL 유니캐스트 스트림을 전달할 수 있는 방안을 제공하고자 한다.
예를 들어, 공중망에서는 망 특성상 다수의 송신기들에게 멀티캐스트 스트림을 전송할 수 없으므로, 일방향의 유니캐스트 스트림으로 빠른 전송을 기대할 수 있다. 이 때, 유니캐스트 스트림에서 발생 가능한 패킷 손실이나 지연에 대해 엣지 클라우드(EDGE CLOUD)를 활용하여 복구 패킷을 제공할 수 있도록 한다. 또한, ATSC 3.0 표준과의 호환성을 유지하며 안정적인 STL 유니캐스트 스트림 전송이 보장될 수 있도록 한다.
도 1은 본 발명의 일실시예에 따른 방송 신호 송신 시스템을 나타낸 블록도이다.
도 1을 참조하면, 본 발명의 일실시예에 따른 방송 신호 송신 시스템은 방송 게이트웨이 장치(110) 및 복수개의 송신기들(121, 122, 123)을 포함한다.
방송 게이트웨이 장치(110)는 복수개의 송신기들(121, 122, 123) 중 어느 하나 이상으로 방송 서비스를 위한 방송 송신 패킷을 송신한다. 이 때, 방송 송신 패킷은 스튜디오-투-송신기 링크(Studio to Transmitter Link; STL)를 통해 송신될 수 있다. 이 때, 방송 송신 패킷은 스튜디오-투-송신기 링크 트랜스포트(터널링) 프로토콜(Studio to Transmitter Link Transport Protocol; STLTP) 패킷일 수 있다.
이 때, 스튜디오-투-송신기 링크는 방송 송신 시스템에서 방송 게이트웨이 장치(110)와 송신기들(121, 122, 123) 사이의 데이터 송/수신 링크일 수 있고, 파이버(fiber), 위성(satellite) 또는 마이크로웨이브(microwave) 링크일 수 있다. 이 때, 스튜디오-투-송신기 링크는 유선 링크 또는 무선 링크일 수 있고, RTP/UDP/IP 등의 패킷 기반의 프로토콜을 이용하여 데이터가 송/수신되는 링크일 수 있다.
송신기들(121, 122, 123)은 방송 게이트웨이 장치(110)로부터 송신된 방송 송신 패킷을 이용하여 수신기로 제공할 방송 신호를 생성하고, 생성된 방송 신호를 방송망을 통해 수신기로 송신한다. 이 때, 송신기들(121, 122, 123)은 하이 파워 송신기(high-power transmitter)일 수도 있고, 갭 필러 등의 로 파워 송신기(low-power transmitter)일 수도 있다.
이 때, 복수개의 송신기들(121, 122, 123)이 하이 파워 송신기들일 경우 방송사들은 신뢰할만한 스튜디오-투-송신기 링크를 위해 전용망(dedicated network)이 사용될 수 있다. 이 때, 복수개의 송신기들(121), 122, 123)이 커버리지 확장(coverage extension)을 위한 로우 파워 송신기들일 경우 방송사들은 전용망이 아닌 공용망(public network)을 이용하여 방송 송신 패킷을 송신할 수 있다.
이 때, 방송 게이트웨이 장치(110) 및 복수개의 송신기들(121, 122, 123) 사이의 스튜디오-투-송신기 링크가 공용망에 해당하는 경우에는 전용망이 사용되는 경우에 비해 코스트(cost)가 줄어드는 장점이 있지만 신뢰성(reliability)이 떨어질 수 밖에 없다.
따라서, 방송 게이트웨이 장치(110) 및 복수개의 송신기들(121, 122, 123) 사이의 스튜디오-투-송신기 링크가 공용망에 해당하는 경우에도, 신뢰성을 보장할 수 있는 기법이 필요하다.
예를 들어, 공용망이 사용되는 경우 동일한 방송 송신 패킷을 여러 개 송신하여 리던던시(redundancy)를 제공하거나 방송 송신 패킷에 오류 정정 코드(Error Correction Code; ECC)를 적용할 수 있다.
예를 들어, 송신기(121)가 중요한 하이 파워 송신기일 때, 방송 게이트웨이 장치(110)로부터 송신기(121)로 전송되는 방송 송신 패킷이 전용망(dedicated network)을 이용하여 전송될 수 있다. 이 때, 방송 송신 패킷은 멀티캐스트 IP 패킷일 수 있다.
예를 들어, 송신기(122)가 덜 중요한 로우 파워 송신기 또는 갭 필러(gap filler)일 때, 방송 게이트웨이 장치(110)로부터 송신기(122)로 전송되는 방송 송신 패킷이 공용망(public network)를 이용하여 전송될 수 있다. 이 때, 방송 송신 패킷은 유니캐스트 IP 패킷일 수 있다.
이 때, 공용망을 이용하여 전송되는 유니캐스트 IP 패킷은 신뢰성을 높이기 위해 리던던시가 제공될 수 있고, 오류 정정 부호가 적용될 수 있다.
이 때, 방송 송신 패킷은 아우터 패킷에 상응하는 것일 수 있다. 즉, 먼저 베이스밴드 패킷, 프리앰블 및 Timing & Management 패킷을 인캡슐레이션하여 이너 패킷을 생성하고, 이너 패킷을 이용하여 아우터 패킷을 생성할 수 있고, 이 아우터 패킷이 방송 송신 패킷에 상응할 수 있다.
즉, 이너 패킷은 아우터 패킷에 의해 터널링되고, 아우터 패킷은 터널링 패킷(tunneling packet)일 수 있고, 이너 패킷은 터널드 패킷(tunneled packet)일 수 있다.
이 때, 이너 패킷은 베이스밴드 패킷, 프리앰블 패킷 및 Timing & Management 패킷으로 구성되고, 터널링 시스템(tunneling system)의 이너 레이어(inner layer)에 상응하는 것일 수 있다. 이 때, 아우터 패킷은 터널링 시스템의 아우터 레이어(outer layer)에 상응하는 것일 수 있다. 이 때, 이너 패킷은 아우터 패킷을 통하여(through) 인캡슐레이션될 수 있다.
이 때, 터널링 시스템은 상기 이너 패킷에 상응하는 병렬적이고 독립적인(parallel and independent) 패킷 스트림들의 그룹이 상기 아우터 패킷에 상응하는 하나의 패킷 스트림 내에서 옮겨지는(carried) 프로세스(a process by which a group of parallel and independent packet streams corresponding to the inner packet are carried within a single packet stream corresponding to the outer packet)에 상응할 수 있다.
도 2는 본 발명의 일실시예에 따른 방송 게이트웨이 시그널링 방법을 나타낸 동작 흐름도이다.
도 2를 참조하면, 본 발명의 일실시예에 따른 방송 게이트웨이 시그널링 방법은 터널링 시스템의 이너 레이어(INNER LAYER)에 상응하는 이너 패킷(INNER PACKET)을 이용하여 터널링 시스템의 아우터 레이어(OUTER LAYER)에 상응하는 아우터 패킷(OUTER PACKET)을 생성한다(S210).
또한, 본 발명의 일실시예에 따른 방송 게이트웨이 시그널링 방법은 아우터 패킷의 헤더를 생성하고, 아우터 패킷을 스튜디오-투-송신기 링크(Studio to Transmitter Link; STL)를 통해 송신기로 송신한다(S220).
예를 들어, 도 3을 참조하면, 본 발명의 일실시예에 따른 방송 게이트웨이 장치는 이너 패킷 생성부(310), 아우터 패킷 헤더 생성부(320), 아우터 패킷 생성부(330) 및 STL 전송부(340)를 포함한다.
이너 패킷 생성부(310)는 베이스밴드 패킷(baseband packet), 프리앰블 및 Timing & Management 패킷을 포함하여 터널링 시스템(tunneling system)의 이너 레이어(inner layer)에 상응하는 이너 패킷(inner packet)을 생성한다.
아우터 패킷 생성부(330)는 상기 이너 패킷을 이용하여 상기 터널링 시스템의 아우터 레이어(outer layer)에 상응하는 아우터 패킷(outer packet)을 생성한다.
아우터 패킷 헤더 생성부(320)는 상기 아우터 패킷의 헤더를 생성한다.
STL 전송부(340)는 상기 아우터 패킷을 스튜디오-투-송신기 링크(Studio to Transmitter Link; STL)를 통해 송신기로 송신한다.
이 때, 이너 패킷은 상기 아우터 패킷을 통하여(through) 인캡슐레이션되는 것일 수 있다.
이 때, 상기 터널링 시스템은 상기 이너 패킷에 상응하는 병렬적이고 독립적인(parallel and independent) 패킷 스트림들의 그룹이 상기 아우터 패킷에 상응하는 하나의 패킷 스트림 내에서 옮겨지는(carried) 것일 수 있다.
이 때, 아우터 패킷은 방송 송신 패킷에 상응할 수 있다.
이 때, 아우터 패킷은 RTP/UDP/IP 유니캐스트 프로토콜 스택(unicast protocol stack)을 통하여 전송될 수 있다.
이 때, 방송 게이트웨이 장치는 STL/SFN 그룹에 속한 송신기들에게 STL 유니캐스트 스트림을 안정적으로 전달하기 위해 패킷 수신에 대한 대기 시간을 알려줌으로써 송신기들의 RF 송신이 정상적으로 동작할 수 있도록 할 수 있다.
이를 위해, 아우터 패킷의 헤더는 아우터 패킷에 상응하는 STL 스트림에 대한 수신 대기 시간을 나타내는 STL 전파 지연시간 필드를 포함할 수 있다.
이 때, STL 전파 지연시간 필드에 설정되는 시간은 수신 대기 시간이나 STL 전파지연 시간에 해당할 수 있다.
이 때, STL 전파 지연시간 필드는 6비트 필드이고, 밀리세컨드(MILLISECONDS) 단위에 상응하는 '0'부터 '63'사이의 정수로 설정될 수 있다.
예를 들어, 아우터 패킷(방송 송신 패킷, 터널링 패킷)의 헤더는 도 4에 도시된 것처럼 생성될 수 있다.
도 4를 참조하면, 아우터 패킷 헤더는 RTP_Fixed_Header()에 해당하고, STL 전파 지연시간 필드는 STL_propa_delay에 해당할 수 있다.
예를 들어, STL_propa_delay(6bits)는 RTP_Fixed_Header()의 reserved(10 bits) 내에 추가된 형태로 정의될 수 있다.
이 때, uimsbf는 unsigned integer, most significant bit first를 나타낼 수 있다.
이 때, 도 4의 아우터 패킷의 헤더는 일종의 RTP 헤더일 수 있다.
이 때, 방송 게이트웨이 장치를 통해 STL 유니캐스트/멀티캐스트 스트림을 수신하는 모든 장치들은 STL_propa_delay에 설정된 패킷의 수신 대기 시간 동안 RTP 패킷 재조립(reassemble)을 수행할 수 있다.
따라서, STL_propa_delay는 송신기가 물리계층 프레임의 송신시간 이전까지 완전한 STL 스트림(=continuous RTP packet stream)을 구성할 수 있도록 RTP 패킷 복구 수행을 반복적으로 실행하는데 고려될 수 있다.
다시 말하면, 수신 대기 시간은 송신기가 아우터 패킷을 이용하여 RF 채널로 송신할 방송 송신 신호를 구성하는 시간에 상응할 수 있다.
예를 들어, 도 5를 참조하면, 방송 게이트웨이 장치(510)에서 송신기(520)로 송신된 아우터 패킷(RTP TUNNEL PACKET)에 손실이 발생한 경우, RTP_Fixed_Header()의 STL_propa_delay에 설정된 수신 대기 시간(530) 동안에 손실 패킷 복구 프로세스가 반복적으로 수행될 수 있다.
이 때, 도 5에 도시된 RTP TUNNELED PACKET은 이너 패킷에 상응할 수 있고, Timing&Management_Packet Payload()의 Packet_Release_Time()이나 Bootstrap_Timing_Data()는 A/324 표준에 반영된 기존 시간 필드값에 상응할 수 있다.
만약, STL 전파 지연시간 필드에 설정된 수신 대기 시간 이내에 완전한 RTP 패킷 스트림을 구성할 수 없는 경우(패킷 손실/지연 혹은 인증 실패), 장비 운용 정책에 따라서 해당 시간 구간 동안의 STL 스트림은 널(null) 패킷으로 채워진 후 RF 송신 절차를 수행하거나 해당 구간의 패킷은 버려질 수 있다.
예를 들어, STL_propa_delay가 '10'으로 설정된 경우에 해당 아우터 패킷의 수신 대기 시간은 10 밀리세컨드에 해당하고, 송신기는 10 밀리세컨드 이내에 해당 아우터 패킷에 대한 RTP 패킷 복구 수행을 반복적으로 실행하여 RF 채널로 송신할 방송 송신 신호를 구성할 수 있다.
이 때, 손실 패킷 복구 프로세스는 클라우드 인프라(CLOUD INFRA) 환경에서 엣지 클라우드 노드에 상응하게 동작하는 STL 스트림 캐시 서버(STUDIO TO TRANSMITTER LINK STREAM CACHE SERVER)를 통해 수행될 수 있다.
예를 들어, 본 발명에서는 클라우드 인프라 환경에서의 엣지 클라우드(EDGD CLOUD)를 활용하여 공용망(Public Network)에서 STL 스트림의 안정적인 전송을 보장하기 위해, 도 6에 도시된 것과 같은 구성을 제공할 수 있다.
도 6을 참조하면, ATSC 3.0 방송 게이트웨이 장치(Z)(610)는 클라우드 인프라 환경에서 동작할 수 있으며, STL 멀티캐스트 스트림을 엣지 클라우드 노드들에게 보낼 수 있는 환경을 갖출 수 있다.
이 때, 엣지 클라우드 노드는 STL 스트림 캐시 서버(621, 622)에 해당할 수 있다.
도 6에 도시된 ATSC 3.0 기반의 방송 게이트웨이 장치(610)와 송신기(631, 632)들은 기술 표준 권고(A/324)에 따라 STL 구간의 중간자 보안 공격(Man-in-the-Middle Attack)에 대응하도록 패킷 인증 방식이 적용될 수 있다.
이를 위해, 본 발명의 일실시예에 따른 방송 게이트웨이 시그널링 방법은 키 전달 프로세스(KEY DELIVERY PROCESS)를 기반으로 송신기와 상호 간에 공개키를 공유할 수 있다.
예를 들어, 도 6을 참조하면, 방송 게이트웨이 장치(610)는 STL/SFN 그룹에 속한 송신기들(631, 632)과 사전에 공개키를 공유할 수 있다. 이와 같은 키 전달 프로세스를 통해 방송 게이트웨이 장치(610)는 자신의 개인키(Z's 개인키), 송신기 A의 공개키(A's 공개키), 송신기 B의 공개키(B's 공개키)를 저장하고, 송신기 A(631)는 자신의 개인키(A's 개인키)와 방송 게이트웨이 장치의 공개키(Z's 공개키)를 저장하고, 송신기 B(632)는 자신의 개인키(B's 개인키)와 방송 게이트웨이 장치의 공개키(Z's 공개키)를 저장할 수 있다.
이 후, 방송 게이트웨이 장치(610)는 엣지 클라우드 노드에 해당하는 STL 스트림 캐시 서버(621, 622)들에게 기존 표준과 동일한 STL 멀티캐스트 스트림을 패킷 인증을 적용하여 전송할 수 있다.
이 때, STL 스트림 캐시 서버(621, 622)들은 방송 게이트웨이 장치(610)로부터 받은 STL 멀티캐스트 스트림을 한정된 시간 길이만큼 캐시 풀(Pool)에 저장해 둘 수 있다.
즉, STL 스트림 캐시 서버로 송신된 아우터 패킷 중 STL 전파 지연시간 필드에 설정된 수신 대기 시간이 종료되지 않은 패킷에 대한 캐시 풀(CACHE POOL)이 구성될 수 있다.
이 때, 방송 게이트웨이 장치(610)로부터 송신되는 STL 스트림은 아우터 패킷에 상응하는 것으로, 아우터 패킷은 RTP/UDP/IP 멀티캐스트 프로토콜 스택(multicast protocol stack)을 통하여 멀티캐스트 패킷(MULTICAST PACKET)에 상응하게 STL 스트림 캐시 서버로 송신되고, RTP/UDP/IP 유니캐스트 프로토콜 스택(unicast protocol stack)을 통하여 유니캐스트 패킷(UNICAST PACKET)에 상응하게 송신기로 송신될 수 있다.
이 때, 방송 게이트웨이 장치(610)와 엣지 클라우드 노드에 상응하는 STL 스트림 캐시 서버(621, 622)는 클라우드 네트워크(CLOUD NETWORK) 인프라에서 전용망을 통한 STL 멀티캐스트 스트림이 전송되므로, 패킷 손실이나 지연이 최소화될 수 있다.
이 때, 각 송신기(631, 632)는 공용망을 통해 방송 게이트웨이 장치(610)로부터 STL 유니캐스트 스트림을 수신하기 위해 자신의 정보(예를 들어, UDP 수신 포트 등)를 포함하는 수신등록 요청 메시지를 방송 게이트웨이 장치(610)로 전달할 수 있다.
이 때, 본 발명의 일실시예에 따른 방송 게이트웨이 시그널링 방법은 송신기 공개키를 이용하여 송신기로부터 수신된 수신등록 요청 메시지에 대한 인증을 수행할 수 있다.
이 때, 수신등록 요청 메시지는 메시지 시퀀스 번호, 송신기 공개키 식별자, UDP 포트 값 및 상기 송신기 개인키 서명을 포함할 수 있다.
이 때, 송신기 공개키로 송신기 개인키 서명에 의한 메시지 인증코드를 확인하여 상기 수신등록 요청 메시지에 대한 인증을 수행할 수 있다.
예를 들어, 도 6에 도시된 송신기 A(631)가 방송 게이트웨이 장치(610)에게 수신등록 요청 메시지를 송신하였다고 가정한다면, 방송 게이트웨이 장치(610)는 수신등록 요청 메시지에 포함된 송신기 공개키 식별자를 이용하여 내부 메모리에 저장해두었던 송신기 A(631)의 공개키(A's 공개키)를 획득할 수 있다. 이 후, 송신기 A(631)의 공개키(A's 공개키)를 이용하여 수신등록 요청 메시지에 포함된 송신기 개인키 서명에 의한 인증코드를 확인함으로써 수신등록 요청 메시지에 대한 인증을 수행할 수 있다.
이 때, 수신등록 요청 메시지에 대한 인증이 성공한 경우, 송신기에게 STL 스트림 캐시 서버의 주소 정보를 제공할 수 있다.
상기의 예에서 수신기 A(631)에서 송신된 수신등록 요청 메시지가 정상적인 등록 요청이라고 인증된 경우, 수신기 A(631)와 가까운 위치에 있는 엣지 클라우드 노드인 STL 스트림 캐시 서버(621)의 주소 정보를 응답 메시지에 담아 송신기 A(631)로 전달할 수 있다.
이 후, 송신기 A(631)는 방송 게이트웨이 장치(610)에 대한 응답이 성공적일 경우에 방송 게이트웨이 장치(610)로부터 정상적으로 STL 유니캐스트 스트림을 수신할 수 있다.
그러나, STL 유니캐스트 스트림은 공용망에서 IP/UDP/RTP 패킷 스트림 기반으로 동작하므로, 전송 과정에서 패킷 손실과 지연이 발생할 수 있다.
따라서, 송신기 A(631)는 STL 유니캐스트 스트림이 수신되는 공안에 패킷 손실과 지연이 발생하는 경우, 수신등록 요청 메시지에 대한 응답 과정에서 획득한 STL 스트림 캐시 서버(621)의 주소 정보를 토대로 손실된 패킷에 대한 재전송을 요청할 수 있다.
이 때, 송신기 A(631)는 실시간 방송 특성상 STL 스트림의 무한정 복구를 위해 대기할 수 없으므로, 아우터 패킷 내 헤더의 STL 전파 지연시간 필드에 설정된 수신 대기 시간 동안에 손실된 패킷들에 대한 복구 과정을 거쳐 완전한 STL 스트림을 구성한 뒤 송신처리를 수행할 수 있다.
예를 들어, 도 7을 참조하면, 방송 게이트웨이 장치(710)와 송신기(730) 간에 수신등록 요청(REGISTRATION)과 응답(RESPONSE)이 정상적으로 완료되면, 방송 게이트웨이 장치(710)는 공용망(PUBLIC NETWORK)을 통해 송신기(730)에게 IP/UDP/RTP 유니캐스트 프로토콜 스택(unicast protocol stack) 기반의 아우터 패킷(STL TUNNEL PACKET)을 전송할 수 있다. 송신기(730)는 아우터 패킷을 수신하는 과정에서 도 7에 도시된 것처럼 패킷 손실(4-5 PACKET LOSS)이 발생하면 STL_propa_delay에 설정된 수신 대기 시간 동안 STL 스트림 캐시 서버(720)에 상응하는 엣지 클라우드 노드와의 패킷 복구 과정(예를 들어, HTTP 프로토콜 사용)을 수행할 수 있다.
또한, 도 2에는 도시하지 아니하였으나, 본 발명의 일실시예에 따른 방송 게이트웨이 시그널링 방법은 STL 스트림 캐시 서버와 송신기 공개키를 공유할 수 있다.
이 때, STL 스트림 캐시 서버는 방송 게이트웨이 장치에서 생성한 STL 스트림(Origin STL 스트림)을 클라우드 인프라 구축 환경에서 멀티캐스트 스트림 형식으로 안정적으로 수신한 후, 송신기에게 일정 시간(STL 전파지연 시간 필드에 설정된 수신 대기 시간) 이내에 요청되는 RTP 패킷 스트림에 대해서만 캐시 풀을 구성하여 저장해둘 수 있다.
예를 들어, STL 스트림 캐시 서버에서 RTP 패킷 스트림을 저장하는데 요구되는 정보는 [표 1]과 같다.
필드명 | 설명 | 길이 | 비고 | |
STL_ID | STL 스트림 식별값 | 4 bytes | IP 멀티캐스트 주소 | |
STL_group_num | 송신기 개수 | N | STL 그룹 송신기 개수(최대 128개) | |
Pub_key_id[] | 공개키 식별자 | 8 bytes * N | (STL/SFN 그룹)송신기들 공개키 식별자 | |
Pub_key_file_data[] | 공개키 식별값 | variable bytes * N | (STL/SFN 그룹)송신기들 공개키 식별값 | |
RTP_info[] | RTP 패킷 데이터 | Fixed size(ex:1500bytes) * n | RTP 패킷 데이터 캐시 풀(pool): STL 전파지연 시간 동안의 패킷 데이터 캐싱 | |
STL_propa_delay | STL 전파지연 시간(수신 대기 시간) | 6 bits (ex:1500msec) |
방송 게이트웨이와 송신기 간 STL 최대 전파지연 시간 |
이 때, [표 1]을 참조하면, STL 스트림을 식별하는 STL_ID는 멀티캐스트 스트림의 IP 주소에 해당하고, STL/SFN 그룹에 속한 송신기들의 공개키 정보(Pub_key_id, Pub_key_file_data)는 방송 게이트웨이 장치와의 멀티캐스트 전송 채널 셋업 절차 시 미리 공유될 수 있다.
또한, RTP 패킷은 수신되는 순서대로 데이터 저장소에 저장해두고, RTP 헤더에 포함된 STL 전파 지연시간 값(STL_propa_delay)을 참조하여 해당 시간 범위 내의 패킷들에 대해서만 캐시 풀을 운영할 수 있다.
이 때, 손실 패킷 복구 프로세스는 송신기 공개키를 기반으로 송신기가 STL 스트림 캐시 서버로 송신한 복구 패킷 요청 메시지에 대한 인증이 성공하는 경우에 수행될 수 있다.
예를 들어, STL 스트림 캐시 서버를 운영하는 엣지 클라우드 노드는 송신기들로부터 STL 스트림에 속한 RTP 패킷 요청 시 [표 1]에 도시된 송신기 정보(Pub_key_id, Pub_key_file_data)를 검증한 후, 해당 RTP 패킷 데이터를 넘겨줄 수 있다.
이와 같은 방송 게이트웨이 시그널링 방법을 통해 클라우드 환경에서의 엣지 클라우드를 활용하여 효율적인 STL 유니캐스트 패킷 전송을 보장하고, 송신기들마다 발생하는 전용망 비용 부담을 효과적으로 감소시킬 수 있다.
또한, 보편화된 클라우드 인프라를 활용하여 ATSC 3.0 표준규격을 최대한 준수함과 동시에 기존의 방송 게이트웨이와 송신기 간의 STL 구간의 전용망 사용 비용을 감소시킬 수 있다.
또한, 일방향의 유니캐스트 스트림으로 빠른 전송과 함께 발생 가능한 패킷 유실이나 지연에 대해서 엣지 클라우드를 활용하여 복구 패킷을 수신하여 대응할 수 있도록 할 수 있다.
도 8은 본 발명의 일실시예에 따른 손실 패킷 복구 프로세스를 상세하게 나타낸 도면이다.
도 8을 참조하면, 먼저 방송 게이트웨이 장치와 엣지 STL 스트림 캐시 서버는 클라우드 인프라 환경에서 동작하며 송신기와의 키 전달 프로세스에 의한 공개키/개인키 셋업이 수행될 수 있다(S802).
이 때, 방송 게이트웨이 장치는 자신의 개인키(Z's 개인키)와 STL/SFN 그룹에 속한 송신기 A의 공개키(A's 공개키)를, 송신기들 A는 자신의 개인키(A's 개인키)와 방송 게이트웨이 장치의 공개키(Z's 공개키)를 공유할 수 있다.
이 후, 방송 게이트웨이 장치는 STL 스트림 캐시 서버에게 STL/SFN 그룹에 속한 송신기 A의 공개키(A's 공개키)를 사전에 공유해줄 수 있다(S804).
이와 같은 준비과정이 완료되면 방송 게이트웨이 장치는 STL 스트림 캐시 서버에게 아우터 패킷을 생성하여 멀티캐스트 기반으로 전송할 수 있다(S806).
이 때, STL 스트림 캐시 서버는 해당 아우터 패킷을 수신하여 캐시 풀에 저장할 수 있다.
이 때, 둘 이상의 아우터 패킷을 구분하기 위해 각 패킷의 식별자로써 IP 멀티캐스트 주소를 사용할 수 있다.
이 때, 방송 게이트웨이 장치는 STL 패킷 인증을 위해 패킷 서명에 사용한 인증키(authorization key)를 안전하게 저장해두고, 일정 시간 간격으로 새롭게 생성된 세션키(session key)로 인증키를 암호화해서 저장해 둘 수 있다.
이 후, 송신기 A가 방송 게이트웨이 장치에게 STL 스트림 수신을 위해 수신등록 요청 메지시를 전달할 수 있다(S808).
이 때, 수신등록 요청 메시지는 요청 응답 메시지 식별을 위한 시퀀스 번호(Seq_no), 송신기 A의 공개키 식별자(pub_key_id), STL 스트림 수신을 위한 UDP 포트(udp_ port)값을 실은 후, 송신기 A의 자격 정보를 포함하기 위한 개인키 서명을 수행하여 전송될 수 있다.
이 때, 송신기 A로부터 수신등록 요청 메시지를 받은 방송 게이트웨이 장치는 해당 메시지에 대한 유효성 검사(STL 그룹 내 속한 송신기 적합성)를 수행하기 위해 송신기 A의 공개키 값을 사용할 수 있다.
이 후, 수신등록 요청 메시지 인증이 성공하면, 방송 게이트웨이 장치는 수신등록 응답 메시지에 메시지 시퀀스 번호(seq_no), 송신기 A가 속한 SFN/STL 그룹의 스트림 식별값(STL_id), STL 스트림 캐시 서버의 접근 주소(Edge_url)를 실은 후 개인키(Z's 개인키) 서명을 수행하여 송신기 A로 전송할 수 있다(S810).
이 후, 송신기 A는 수신등록 응답 메시지의 시퀀스 번호(seq_no)와 송신기에 저장된 방송 게이트웨이 공개키(Z's 공개키)를 통해 수신등록 요청에 대한 응답 메시지 유효성을 검증한 후, 스트림 식별값(STL_id)과 STL 스트림 캐시 서버의 접근 주소(Edge_url)를 획득할 수 있다. 그리고, UDP 수신 포트(udp_port)를 통해 방송 게이트웨이 장치로부터 아우터 패킷(STL 유니캐스트 스트림)을 수신할 수 있다(S812).
이 때, 방송 게이트웨이 장치로부터 발송된 아우터 패킷(STL 유니캐스트 스트림)은 IP/UDP/RTP 기반의 일방향 전송 패킷들이며, 공중망 특성상 패킷 손실과 지연이 발생할 수 있다.
따라서, 송신기 A는 일정 수신 시간 동안 손실/지연된 패킷에 대해 STL 스트림 캐시 서버에게 해당 패킷 스트림 복구를 위한 복구 패킷 요청 메시지를 보낼 수 있다(S814).
이 때, 복구 패킷 요청 메시지는 스트림 식별값(STL_id), 복구 패킷의 RTP 시퀀스 번호(from, to)를 포함할 수 있고, 송신기 A의 개인키 서명을 수행하여 발송될 수 있다.
이 후, STL 스트림 캐시 서버는 송신기 A로부터 수신된 복구 패킷 요청 메시지를 검증한 후, 해당 RTP 패킷 데이터를 복구 패킷으로써 응답할 수 있다(S816).
이 때, 송신기 A는 방송 게이트웨이 장치와 송신기 A 간에 설정된 STL 전파지연 시간(아우터 패킷 헤더의 STL 전파지연 시간 필드에 설정된 수신 대기 시간)을 고려하여, 물리계층 프레임의 송신시간 이전까지 완전한 STL 스트림(=continuous RTP packet stream)을 구성할 수 있도록 RTP 패킷 복구 수행을 반복적으로 실행할 수 있다.
이 때, STL 전파지연 시간 이내에 완전한 STL 스트림(방송 송신 신호)이 구성되면 송신기 A의 정상적인 RF 송신 절차를 수행할 수 있다(S818)
만약, STL 전파지연 시간 이내에 완전한 STL 스트림을 구성할 수 없을 경우에는 패킷 손실 지연 혹은 인증 실패 장비 운용 정책에 따라서 해당 시간 구간 동안의 STL 스트림은 널(null) 패킷으로 채워진 후 RF 송신 절차를 수행하거나 해당 구간의 패킷은 버려지게 된다.
도 9는 본 발명의 일실시예에 따른 방송 게이트웨이 장치를 나타낸 블록도이다.
도 9를 참조하면, 본 발명의 일실시예에 따른 방송 게이트웨이 장치는 통신부(910), 프로세서(920) 및 메모리(930)를 포함한다.
통신부(910)는 네트워크와 같은 통신망을 통해 방송 게이트웨이 시그널링을 위해 필요한 정보를 송수신하는 역할을 할 수 있다. 이 때, 네트워크는 장치들간에 데이터를 전달하는 통로를 제공하는 것으로서, 기존에 이용되는 네트워크 및 향후 개발 가능한 네트워크를 모두 포괄하는 개념이다.
예를 들면, 네트워크는 인터넷 프로토콜(IP)을 통하여 대용량 데이터의 송수신 서비스 및 끊기는 현상이 없는 데이터 서비스를 제공하는 아이피망, 아이피를 기반으로 서로 다른 망을 통합한 아이피망 구조인 올 아이피(All IP)망 등일 수 있으며, 유선망, Wibro(Wireless Broadband)망, WCDMA를 포함하는 3세대 이동통신망, HSDPA(High Speed Downlink Packet Access)망 및 LTE 망을 포함하는 3.5세대 이동통신망, LTE advanced를 포함하는 4세대 이동통신망, 위성통신망 및 와이파이(Wi-Fi)망 중에서 하나 이상을 결합하여 이루어질 수 있다.
또한, 네트워크는 한정된 지역 내에서 각종 정보장치들의 통신을 제공하는 유무선근거리 통신망, 이동체 상호 간 및 이동체와 이동체 외부와의 통신을 제공하는 이동통신망, 위성을 이용해 지구국과 지구국간 통신을 제공하는 위성통신망이거나 유무선 통신망 중에서 어느 하나이거나, 둘 이상의 결합으로 이루어질 수 있다. 한편, 네트워크의 전송 방식 표준은, 기존의 전송 방식 표준에 한정되는 것은 아니며, 향후 개발될 모든 전송 방식 표준을 포함할 수 있다.
프로세서(920)는 터널링 시스템의 이너 레이어(INNER LAYER)에 상응하는 이너 패킷(INNER PACKET)을 이용하여 터널링 시스템의 아우터 레이어(OUTER LAYER)에 상응하는 아우터 패킷(OUTER PACKET)을 생성한다.
또한, 프로세서(920)는 아우터 패킷의 헤더를 생성하고, 아우터 패킷을 스튜디오-투-송신기 링크(Studio to Transmitter Link; STL)를 통해 송신기로 송신한다.
예를 들어, 도 3을 참조하면, 본 발명의 일실시예에 따른 방송 게이트웨이 장치는 이너 패킷 생성부(310), 아우터 패킷 헤더 생성부(320), 아우터 패킷 생성부(330) 및 STL 전송부(340)를 포함한다.
이너 패킷 생성부(310)는 베이스밴드 패킷(baseband packet), 프리앰블 및 Timing & Management 패킷을 포함하여 터널링 시스템(tunneling system)의 이너 레이어(inner layer)에 상응하는 이너 패킷(inner packet)을 생성한다.
아우터 패킷 생성부(330)는 상기 이너 패킷을 이용하여 상기 터널링 시스템의 아우터 레이어(outer layer)에 상응하는 아우터 패킷(outer packet)을 생성한다.
아우터 패킷 헤더 생성부(320)는 상기 아우터 패킷의 헤더를 생성한다.
STL 전송부(340)는 상기 아우터 패킷을 스튜디오-투-송신기 링크(Studio to Transmitter Link; STL)를 통해 송신기로 송신한다.
이 때, 이너 패킷은 상기 아우터 패킷을 통하여(through) 인캡슐레이션되는 것일 수 있다.
이 때, 상기 터널링 시스템은 상기 이너 패킷에 상응하는 병렬적이고 독립적인(parallel and independent) 패킷 스트림들의 그룹이 상기 아우터 패킷에 상응하는 하나의 패킷 스트림 내에서 옮겨지는(carried) 것일 수 있다.
이 때, 아우터 패킷은 방송 송신 패킷에 상응할 수 있다.
이 때, 아우터 패킷은 RTP/UDP/IP 유니캐스트 프로토콜 스택(unicast protocol stack)을 통하여 전송될 수 있다.
이 때, 방송 게이트웨이 장치는 STL/SFN 그룹에 속한 송신기들에게 STL 유니캐스트 스트림을 안정적으로 전달하기 위해 패킷 수신에 대한 대기 시간을 알려줌으로써 송신기들의 RF 송신이 정상적으로 동작할 수 있도록 할 수 있다.
이를 위해, 아우터 패킷의 헤더는 아우터 패킷에 상응하는 STL 스트림에 대한 수신 대기 시간을 나타내는 STL 전파 지연시간 필드를 포함할 수 있다.
이 때, STL 전파 지연시간 필드에 설정되는 시간은 수신 대기 시간이나 STL 전파지연 시간에 해당할 수 있다.
이 때, STL 전파 지연시간 필드는 6비트 필드이고, 밀리세컨드(MILLISECONDS) 단위에 상응하는 '0'부터 '63'사이의 정수로 설정될 수 있다.
예를 들어, 아우터 패킷(방송 송신 패킷, 터널링 패킷)의 헤더는 도 4에 도시된 것처럼 생성될 수 있다.
도 4를 참조하면, 아우터 패킷 헤더는 RTP_Fixed_Header()에 해당하고, STL 전파 지연시간 필드는 STL_propa_delay에 해당할 수 있다.
예를 들어, STL_propa_delay(6bits)는 RTP_Fixed_Header()의 reserved(10 bits) 내에 추가된 형태로 정의될 수 있다.
이 때, uimsbf는 unsigned integer, most significant bit first를 나타낼 수 있다.
이 때, 도 4의 아우터 패킷의 헤더는 일종의 RTP 헤더일 수 있다.
이 때, 방송 게이트웨이 장치를 통해 STL 유니캐스트/멀티캐스트 스트림을 수신하는 모든 장치들은 STL_propa_delay에 설정된 패킷의 수신 대기 시간 동안 RTP 패킷 재조립(reassemble)을 수행할 수 있다.
따라서, STL_propa_delay는 송신기가 물리계층 프레임의 송신시간 이전까지 완전한 STL 스트림(=continuous RTP packet stream)을 구성할 수 있도록 RTP 패킷 복구 수행을 반복적으로 실행하는데 고려될 수 있다.
다시 말하면, 수신 대기 시간은 송신기가 아우터 패킷을 이용하여 RF 채널로 송신할 방송 송신 신호를 구성하는 시간에 상응할 수 있다.
예를 들어, 도 5를 참조하면, 방송 게이트웨이 장치(510)에서 송신기(520)로 송신된 아우터 패킷(RTP TUNNEL PACKET)에 손실이 발생한 경우, RTP_Fixed_Header()의 STL_propa_delay에 설정된 수신 대기 시간(530) 동안에 손실 패킷 복구 프로세스가 반복적으로 수행될 수 있다.
이 때, 도 5에 도시된 RTP TUNNELED PACKET은 이너 패킷에 상응할 수 있고, Timing&Management_Packet Payload()의 Packet_Release_Time()이나 Bootstrap_Timing_Data()는 A/324 표준에 반영된 기존 시간 필드값에 상응할 수 있다.
만약, STL 전파 지연시간 필드에 설정된 수신 대기 시간 이내에 완전한 RTP 패킷 스트림을 구성할 수 없는 경우(패킷 손실/지연 혹은 인증 실패), 장비 운용 정책에 따라서 해당 시간 구간 동안의 STL 스트림은 널(null) 패킷으로 채워진 후 RF 송신 절차를 수행하거나 해당 구간의 패킷은 버려질 수 있다.
예를 들어, STL_propa_delay가 '10'으로 설정된 경우에 해당 아우터 패킷의 수신 대기 시간은 10 밀리세컨드에 해당하고, 송신기는 10 밀리세컨드 이내에 해당 아우터 패킷에 대한 RTP 패킷 복구 수행을 반복적으로 실행하여 RF 채널로 송신할 방송 송신 신호를 구성할 수 있다.
이 때, 손실 패킷 복구 프로세스는 클라우드 인프라(CLOUD INFRA) 환경에서 엣지 클라우드 노드에 상응하게 동작하는 STL 스트림 캐시 서버(STUDIO TO TRANSMITTER LINK STREAM CACHE SERVER)를 통해 수행될 수 있다.
예를 들어, 본 발명에서는 클라우드 인프라 환경에서의 엣지 클라우드(EDGD CLOUD)를 활용하여 공용망(Public Network)에서 STL 스트림의 안정적인 전송을 보장하기 위해, 도 6에 도시된 것과 같은 구성을 제공할 수 있다.
도 6을 참조하면, ATSC 3.0 방송 게이트웨이 장치(Z)(610)는 클라우드 인프라 환경에서 동작할 수 있으며, STL 멀티캐스트 스트림을 엣지 클라우드 노드들에게 보낼 수 있는 환경을 갖출 수 있다.
이 때, 엣지 클라우드 노드는 STL 스트림 캐시 서버(621, 622)에 해당할 수 있다.
도 6에 도시된 ATSC 3.0 기반의 방송 게이트웨이 장치(610)와 송신기(631, 632)들은 기술 표준 권고(A/324)에 따라 STL 구간의 중간자 보안 공격(Man-in-the-Middle Attack)에 대응하도록 패킷 인증 방식이 적용될 수 있다.
이를 위해, 본 발명의 일실시예에 따른 방송 게이트웨이 시그널링 방법은 키 전달 프로세스(KEY DELIVERY PROCESS)를 기반으로 송신기와 상호 간에 공개키를 공유할 수 있다.
예를 들어, 도 6을 참조하면, 방송 게이트웨이 장치(610)는 STL/SFN 그룹에 속한 송신기들(631, 632)과 사전에 공개키를 공유할 수 있다. 이와 같은 키 전달 프로세스를 통해 방송 게이트웨이 장치(610)는 자신의 개인키(Z's 개인키), 송신기 A의 공개키(A's 공개키), 송신기 B의 공개키(B's 공개키)를 저장하고, 송신기 A(631)는 자신의 개인키(A's 개인키)와 방송 게이트웨이 장치의 공개키(Z's 공개키)를 저장하고, 송신기 B(632)는 자신의 개인키(B's 개인키)와 방송 게이트웨이 장치의 공개키(Z's 공개키)를 저장할 수 있다.
이 후, 방송 게이트웨이 장치(610)는 엣지 클라우드 노드에 해당하는 STL 스트림 캐시 서버(621, 622)들에게 기존 표준과 동일한 STL 멀티캐스트 스트림을 패킷 인증을 적용하여 전송할 수 있다.
이 때, STL 스트림 캐시 서버(621, 622)들은 방송 게이트웨이 장치(610)로부터 받은 STL 멀티캐스트 스트림을 한정된 시간 길이만큼 캐시 풀(Pool)에 저장해 둘 수 있다.
즉, STL 스트림 캐시 서버로 송신된 아우터 패킷 중 STL 전파 지연시간 필드에 설정된 수신 대기 시간이 종료되지 않은 패킷에 대한 캐시 풀(CACHE POOL)이 구성될 수 있다.
이 때, 방송 게이트웨이 장치(610)로부터 송신되는 STL 스트림은 아우터 패킷에 상응하는 것으로, 아우터 패킷은 RTP/UDP/IP 멀티캐스트 프로토콜 스택(multicast protocol stack)을 통하여 멀티캐스트 패킷(MULTICAST PACKET)에 상응하게 STL 스트림 캐시 서버로 송신되고, RTP/UDP/IP 유니캐스트 프로토콜 스택(unicast protocol stack)을 통하여 유니캐스트 패킷(UNICAST PACKET)에 상응하게 송신기로 송신될 수 있다.
이 때, 방송 게이트웨이 장치(610)와 엣지 클라우드 노드에 상응하는 STL 스트림 캐시 서버(621, 622)는 클라우드 네트워크(CLOUD NETWORK) 인프라에서 전용망을 통한 STL 멀티캐스트 스트림이 전송되므로, 패킷 손실이나 지연이 최소화될 수 있다.
이 때, 각 송신기(631, 632)는 공용망을 통해 방송 게이트웨이 장치(610)로부터 STL 유니캐스트 스트림을 수신하기 위해 자신의 정보(예를 들어, UDP 수신 포트 등)를 포함하는 수신등록 요청 메시지를 방송 게이트웨이 장치(610)로 전달할 수 있다.
이 때, 본 발명의 일실시예에 따른 방송 게이트웨이 시그널링 방법은 송신기 공개키를 이용하여 송신기로부터 수신된 수신등록 요청 메시지에 대한 인증을 수행할 수 있다.
이 때, 수신등록 요청 메시지는 메시지 시퀀스 번호, 송신기 공개키 식별자, UDP 포트 값 및 상기 송신기 개인키 서명을 포함할 수 있다.
이 때, 송신기 공개키로 송신기 개인키 서명에 의한 메시지 인증코드를 확인하여 상기 수신등록 요청 메시지에 대한 인증을 수행할 수 있다.
예를 들어, 도 6에 도시된 송신기 A(631)가 방송 게이트웨이 장치(610)에게 수신등록 요청 메시지를 송신하였다고 가정한다면, 방송 게이트웨이 장치(610)는 수신등록 요청 메시지에 포함된 송신기 공개키 식별자를 이용하여 내부 메모리에 저장해두었던 송신기 A(631)의 공개키(A's 공개키)를 획득할 수 있다. 이 후, 송신기 A(631)의 공개키(A's 공개키)를 이용하여 수신등록 요청 메시지에 포함된 송신기 개인키 서명에 의한 인증코드를 확인함으로써 수신등록 요청 메시지에 대한 인증을 수행할 수 있다.
이 때, 수신등록 요청 메시지에 대한 인증이 성공한 경우, 송신기에게 STL 스트림 캐시 서버의 주소 정보를 제공할 수 있다.
상기의 예에서 수신기 A(631)에서 송신된 수신등록 요청 메시지가 정상적인 등록 요청이라고 인증된 경우, 수신기 A(631)와 가까운 위치에 있는 엣지 클라우드 노드인 STL 스트림 캐시 서버(621)의 주소 정보를 응답 메시지에 담아 송신기 A(631)로 전달할 수 있다.
이 후, 송신기 A(631)는 방송 게이트웨이 장치(610)에 대한 응답이 성공적일 경우에 방송 게이트웨이 장치(610)로부터 정상적으로 STL 유니캐스트 스트림을 수신할 수 있다.
그러나, STL 유니캐스트 스트림은 공용망에서 IP/UDP/RTP 패킷 스트림 기반으로 동작하므로, 전송 과정에서 패킷 손실과 지연이 발생할 수 있다.
따라서, 송신기 A(631)는 STL 유니캐스트 스트림이 수신되는 공안에 패킷 손실과 지연이 발생하는 경우, 수신등록 요청 메시지에 대한 응답 과정에서 획득한 STL 스트림 캐시 서버(621)의 주소 정보를 토대로 손실된 패킷에 대한 재전송을 요청할 수 있다.
이 때, 송신기 A(631)는 실시간 방송 특성상 STL 스트림의 무한정 복구를 위해 대기할 수 없으므로, 아우터 패킷 내 헤더의 STL 전파 지연시간 필드에 설정된 수신 대기 시간 동안에 손실된 패킷들에 대한 복구 과정을 거쳐 완전한 STL 스트림을 구성한 뒤 송신처리를 수행할 수 있다.
예를 들어, 도 7을 참조하면, 방송 게이트웨이 장치(710)와 송신기(730) 간에 수신등록 요청(REGISTRATION)과 응답(RESPONSE)이 정상적으로 완료되면, 방송 게이트웨이 장치(710)는 공용망(PUBLIC NETWORK)을 통해 송신기(730)에게 IP/UDP/RTP 유니캐스트 프로토콜 스택(unicast protocol stack) 기반의 아우터 패킷(STL TUNNEL PACKET)을 전송할 수 있다. 송신기(730)는 아우터 패킷을 수신하는 과정에서 도 7에 도시된 것처럼 패킷 손실(4-5 PACKET LOSS)이 발생하면 STL_propa_delay에 설정된 수신 대기 시간 동안 STL 스트림 캐시 서버(720)에 상응하는 엣지 클라우드 노드와의 패킷 복구 과정(예를 들어, HTTP 프로토콜 사용)을 수행할 수 있다.
또한, 프로세서(920)는 방법은 STL 스트림 캐시 서버와 송신기 공개키를 공유할 수 있다.
이 때, STL 스트림 캐시 서버는 방송 게이트웨이 장치에서 생성한 STL 스트림(Origin STL 스트림)을 클라우드 인프라 구축 환경에서 멀티캐스트 스트림 형식으로 안정적으로 수신한 후, 송신기에게 일정 시간(STL 전파지연 시간 필드에 설정된 수신 대기 시간) 이내에 요청되는 RTP 패킷 스트림에 대해서만 캐시 풀을 구성하여 저장해둘 수 있다.
예를 들어, STL 스트림 캐시 서버에서 RTP 패킷 스트림을 저장하는데 요구되는 정보는 상기의 [표 1]과 같다.
이 때, [표 1]을 참조하면, STL 스트림을 식별하는 STL_ID는 멀티캐스트 스트림의 IP 주소에 해당하고, STL/SFN 그룹에 속한 송신기들의 공개키 정보(Pub_key_id, Pub_key_file_data)는 방송 게이트웨이 장치와의 멀티캐스트 전송 채널 셋업 절차 시 미리 공유될 수 있다.
또한, RTP 패킷은 수신되는 순서대로 데이터 저장소에 저장해두고, RTP 헤더에 포함된 STL 전파 지연시간 값(STL_propa_delay)을 참조하여 해당 시간 범위 내의 패킷들에 대해서만 캐시 풀을 운영할 수 있다.
이 때, 손실 패킷 복구 프로세스는 송신기 공개키를 기반으로 송신기가 STL 스트림 캐시 서버로 송신한 복구 패킷 요청 메시지에 대한 인증이 성공하는 경우에 수행될 수 있다.
예를 들어, STL 스트림 캐시 서버를 운영하는 엣지 클라우드 노드는 송신기들로부터 STL 스트림에 속한 RTP 패킷 요청 시 [표 1]에 도시된 송신기 정보(Pub_key_id, Pub_key_file_data)를 검증한 후, 해당 RTP 패킷 데이터를 넘겨줄 수 있다.
메모리(930)는 아우터 패킷을 저장한다.
또한, 메모리(930)는 상술한 바와 같이 본 발명의 일실시예에 따른 방송 게이트웨이 장치에서 발생하는 다양한 정보를 저장한다.
실시예에 따라, 메모리(930)는 방송 게이트웨이 장치와 독립적으로 구성되어 방송 게이트웨이 시그널링을 위한 기능을 지원할 수 있다. 이 때, 메모리(930)는 별도의 대용량 스토리지로 동작할 수 있고, 동작 수행을 위한 제어 기능을 포함할 수도 있다.
한편, 방송 게이트웨이 장치는 메모리가 탑재되어 그 장치 내에서 정보를 저장할 수 있다. 일 구현예의 경우, 메모리는 컴퓨터로 판독 가능한 매체이다. 일 구현 예에서, 메모리는 휘발성 메모리 유닛일 수 있으며, 다른 구현예의 경우, 메모리는 비휘발성 메모리 유닛일 수도 있다. 일 구현예의 경우, 저장장치는 컴퓨터로 판독 가능한 매체이다. 다양한 서로 다른 구현 예에서, 저장장치는 예컨대 하드디스크 장치, 광학디스크 장치, 혹은 어떤 다른 대용량 저장장치를 포함할 수도 있다.
이와 같은 방송 게이트웨이 장치를 이용함으로써 클라우드 환경에서의 엣지 클라우드를 활용하여 효율적인 STL 유니캐스트 패킷 전송을 보장하고, 송신기들마다 발생하는 전용망 비용 부담을 효과적으로 감소시킬 수 있다.
또한, 보편화된 클라우드 인프라를 활용하여 ATSC 3.0 표준규격을 최대한 준수함과 동시에 기존의 방송 게이트웨이와 송신기 간의 STL 구간의 전용망 사용 비용을 감소시킬 수 있다.
또한, 일방향의 유니캐스트 스트림으로 빠른 전송과 함께 발생 가능한 패킷 유실이나 지연에 대해서 엣지 클라우드를 활용하여 복구 패킷을 수신하여 대응할 수 있도록 할 수 있다.
도 10은 본 발명의 일실시예에 따른 컴퓨터 시스템을 나타낸 도면이다.
도 10을 참조하면, 본 발명의 실시예는 컴퓨터로 읽을 수 있는 기록매체와 같은 컴퓨터 시스템에서 구현될 수 있다. 도 10에 도시된 바와 같이, 컴퓨터 시스템(1000)은 버스(1020)를 통하여 서로 통신하는 하나 이상의 프로세서(1010), 메모리(1030), 사용자 입력 장치(1040), 사용자 출력 장치(1050) 및 스토리지(1060)를 포함할 수 있다. 또한, 컴퓨터 시스템(1000)은 네트워크(1080)에 연결되는 네트워크 인터페이스(1070)를 더 포함할 수 있다. 프로세서(1010)는 중앙 처리 장치 또는 메모리(1030)나 스토리지(1060)에 저장된 프로세싱 인스트럭션들을 실행하는 반도체 장치일 수 있다. 메모리(1030) 및 스토리지(1060)는 다양한 형태의 휘발성 또는 비휘발성 저장 매체일 수 있다. 예를 들어, 메모리는 ROM(1031)이나 RAM(1032)을 포함할 수 있다.
따라서, 본 발명의 실시예는 컴퓨터로 구현된 방법이나 컴퓨터에서 실행 가능한 명령어들이 기록된 비일시적인 컴퓨터에서 읽을 수 있는 매체로 구현될 수 있다. 컴퓨터에서 읽을 수 있는 명령어들이 프로세서에 의해서 수행될 때, 컴퓨터에서 읽을 수 있는 명령어들은 본 발명의 적어도 한 가지 측면에 따른 방법을 수행할 수 있다.
이상에서와 같이 본 발명에 따른 클라우드 네트워크를 이용한 방송 게이트웨이 시그널링 방법 및 이를 위한 장치는 상기한 바와 같이 설명된 실시예들의 구성과 방법이 한정되게 적용될 수 있는 것이 아니라, 상기 실시예들은 다양한 변형이 이루어질 수 있도록 각 실시예들의 전부 또는 일부가 선택적으로 조합되어 구성될 수도 있다.
110, 510, 710, 610, 810: 방송 게이트웨이
121, 122, 123, 520, 631, 632 730: 송신기
530: 수신 대기 시간 621, 622, 720: STL 스트림 캐시 서버
910: 통신부
920, 1010: 프로세서 930, 1030: 메모리
1000: 컴퓨터 시스템 1020: 버스
1031: 롬 1032: 램
1040: 사용자 입력 장치 1050: 사용자 출력 장치
1060: 스토리지 1070: 네트워크 인터페이스
1080: 네트워크
121, 122, 123, 520, 631, 632 730: 송신기
530: 수신 대기 시간 621, 622, 720: STL 스트림 캐시 서버
910: 통신부
920, 1010: 프로세서 930, 1030: 메모리
1000: 컴퓨터 시스템 1020: 버스
1031: 롬 1032: 램
1040: 사용자 입력 장치 1050: 사용자 출력 장치
1060: 스토리지 1070: 네트워크 인터페이스
1080: 네트워크
Claims (20)
- 터널링 시스템의 이너 레이어(INNER LAYER)에 상응하는 이너 패킷(INNER PACKET)을 이용하여 상기 터널링 시스템의 아우터 레이어(OUTER LAYER)에 상응하는 아우터 패킷(OUTER PACKET)을 생성하는 단계; 및
상기 아우터 패킷의 헤더를 생성하고, 상기 아우터 패킷을 스튜디오-투-송신기 링크(Studio to Transmitter Link; STL)를 통해 송신기로 송신하는 단계
를 포함하고,
상기 헤더는
상기 아우터 패킷에 상응하는 STL 스트림에 대한 수신 대기 시간을 나타내는 STL 전파 지연시간 필드를 포함하고,
상기 송신기로 송신된 아우터 패킷에 손실이 발생한 경우, 상기 수신 대기 시간 동안에 손실 패킷 복구 프로세스가 수행되고,
상기 손실 패킷 복구 프로세스는 클라우드 인프라(CLOUD INFRA) 환경에서 엣지 클라우드 노드에 상응하는 STL 스트림 캐시 서버(STUDIO TO TRANSMITTER LINK STREAM CACHE SERVER)를 통해 수행되는 것을 특징으로 하는 방송 게이트웨이 시그널링 방법. - 청구항 1에 있어서,
상기 STL 전파 지연시간 필드는
6비트 필드이고, 밀리세컨드(MILLISECONDS) 단위에 상응하는 '0'부터 '63'사이의 정수로 설정되는 것을 특징으로 하는 방송 게이트웨이 시그널링 방법. - 청구항 1에 있어서,
상기 수신 대기 시간은
상기 송신기가 상기 아우터 패킷을 이용하여 RF 채널로 송신할 방송 송신 신호를 구성하는 시간에 상응하는 것을 특징으로 하는 방송 게이트웨이 시그널링 방법. - 삭제
- 삭제
- 청구항 1에 있어서,
상기 아우터 패킷은
RTP/UDP/IP 멀티캐스트 프로토콜 스택(multicast protocol stack)을 통하여 멀티캐스트 패킷(MULTICAST PACKET)에 상응하게 상기 STL 스트림 캐시 서버로 송신되고,
RTP/UDP/IP 유니캐스트 프로토콜 스택(unicast protocol stack)을 통하여 유니캐스트 패킷(UNICAST PACKET)에 상응하게 상기 송신기로 송신되는 것을 특징으로 하는 방송 게이트웨이 시그널링 방법. - 청구항 1에 있어서,
상기 STL 스트림 캐시 서버로 송신된 아우터 패킷 중 상기 수신 대기 시간이 종료되지 않은 패킷에 대한 캐시 풀(CACHE POOL)이 구성되는 것을 특징으로 하는 방송 게이트웨이 시그널링 방법. - 청구항 1에 있어서,
키 전달 프로세스(KEY DELIVERY PROCESS)를 기반으로 상기 송신기와 상호 간에 공개키를 공유하는 단계;
송신기 공개키를 이용하여 상기 송신기로부터 수신된 수신등록 요청 메시지에 대한 인증을 수행하는 단계; 및
상기 인증이 성공한 경우, 상기 송신기에게 상기 STL 스트림 캐시 서버의 주소 정보를 제공하는 단계
를 더 포함하는 것을 특징으로 하는 방송 게이트웨이 시그널링 방법. - 청구항 8에 있어서,
상기 수신등록 요청 메시지는 메시지 시퀀스 번호, 송신기 공개키 식별자, UDP 포트 값 및 송신기 개인키 서명을 포함하고,
상기 송신기 공개키로 상기 송신기 개인키 서명에 의한 메시지 인증코드를 확인하여 상기 인증을 수행하는 것을 특징으로 하는 방송 게이트웨이 시그널링 방법. - 청구항 8에 있어서,
상기 STL 스트림 캐시 서버와 상기 송신기 공개키를 공유하는 단계를 더 포함하고,
상기 손실 패킷 복구 프로세스는
상기 송신기 공개키를 기반으로 상기 송신기가 상기 STL 스트림 캐시 서버로 송신한 복구 패킷 요청 메시지에 대한 인증이 성공하는 경우에 수행되는 것을 특징으로 하는 방송 게이트웨이 시그널링 방법. - 청구항 1에 있어서,
상기 수신 대기 시간 동안에 손실된 패킷이 복구되지 못한 경우, 손실된 패킷을 널(NULL) 패킷 입력 및 손실 패킷 폐기 중 적어도 하나에 상응하게 처리하는 것을 특징으로 하는 방송 게이트웨이 시그널링 방법. - 청구항 1에 있어서,
상기 이너 패킷은 상기 아우터 패킷을 통하여(THROUGH) 인캡슐레이션되는 것을 특징으로 하는 방송 게이트웨이 시그널링 방법. - 청구항 1에 있어서,
상기 터널링 시스템은 상기 이너 패킷에 상응하는 병렬적이고 독립적인(parallel and independent) 패킷 스트림들의 그룹이 상기 아우터 패킷에 상응하는 하나의 패킷 스트림 내에서 옮겨지는(carried) 것을 특징으로 하는 방송 게이트웨이 시그널링 방법. - 터널링 시스템의 이너 레이어(INNER LAYER)에 상응하는 이너 패킷(INNER PACKET)을 이용하여 상기 터널링 시스템의 아우터 레이어(OUTER LAYER)에 상응하는 아우터 패킷(OUTER PACKET)을 생성하고, 상기 아우터 패킷의 헤더를 생성하고, 상기 아우터 패킷을 스튜디오-투-송신기 링크(Studio to Transmitter Link; STL)를 통해 송신기로 송신하는 프로세서; 및
상기 아우터 패킷을 저장하는 메모리
를 포함하고,
상기 헤더는
상기 아우터 패킷에 상응하는 STL 스트림에 대한 수신 대기 시간을 나타내는 STL 전파 지연시간 필드를 포함하고,
상기 송신기로 송신된 아우터 패킷에 손실이 발생한 경우, 상기 수신 대기 시간 동안에 손실 패킷 복구 프로세스가 수행되고,
상기 손실 패킷 복구 프로세스는 클라우드 인프라(CLOUD INFRA) 환경에서 엣지 클라우드 노드에 상응하는 STL 스트림 캐시 서버(STUDIO TO TRANSMITTER LINK STREAM CACHE SERVER)를 통해 수행되는 것을 특징으로 하는 방송 게이트웨이 장치. - 청구항 14에 있어서,
상기 STL 전파 지연시간 필드는
6비트 필드이고, 밀리세컨드(MILLISECONDS) 단위에 상응하는 '0'부터 '63'사이의 정수로 설정되는 것을 특징으로 하는 방송 게이트웨이 장치. - 청구항 14에 있어서,
상기 수신 대기 시간은
상기 송신기가 상기 아우터 패킷을 이용하여 RF 채널로 송신할 방송 송신 신호를 구성하는 시간에 상응하는 것을 특징으로 하는 방송 게이트웨이 장치. - 삭제
- 삭제
- 청구항 14에 있어서,
상기 아우터 패킷은
RTP/UDP/IP 멀티캐스트 프로토콜 스택(multicast protocol stack)을 통하여 멀티캐스트 패킷(MULTICAST PACKET)에 상응하게 상기 STL 스트림 캐시 서버로 송신되고,
RTP/UDP/IP 유니캐스트 프로토콜 스택(unicast protocol stack)을 통하여 유니캐스트 패킷(UNICAST PACKET)에 상응하게 상기 송신기로 송신되는 것을 특징으로 하는 방송 게이트웨이 장치. - 청구항 14에 있어서,
상기 STL 스트림 캐시 서버로 송신된 아우터 패킷 중 상기 수신 대기 시간이 종료되지 않은 패킷에 대한 캐시 풀(CACHE POOL)이 구성되는 것을 특징으로 하는 방송 게이트웨이 장치.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US17/182,955 US11343786B2 (en) | 2020-10-27 | 2021-02-23 | Method for broadcast gateway signaling using cloud network and apparatus for the same |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
KR1020200140284 | 2020-10-27 | ||
KR20200140284 | 2020-10-27 |
Publications (2)
Publication Number | Publication Date |
---|---|
KR20220056078A KR20220056078A (ko) | 2022-05-04 |
KR102593734B1 true KR102593734B1 (ko) | 2023-10-26 |
Family
ID=81583863
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
KR1020210012830A KR102593734B1 (ko) | 2020-10-27 | 2021-01-29 | 클라우드 네트워크를 이용한 방송 게이트웨이 시그널링 방법 및 이를 위한 장치 |
Country Status (1)
Country | Link |
---|---|
KR (1) | KR102593734B1 (ko) |
Family Cites Families (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR101432101B1 (ko) * | 2010-02-17 | 2014-08-22 | 에스케이텔레콤 주식회사 | 실시간 서비스를 위한 수신 패킷 처리 방법 및 장치 |
KR101482938B1 (ko) * | 2013-04-22 | 2015-01-21 | 주식회사 네이블커뮤니케이션즈 | 인증 메시지 보안 방법, 이를 수행하는 인증 메시지 보안 서버 및 사용자 단말 |
KR102290779B1 (ko) * | 2014-07-04 | 2021-08-20 | 삼성전자주식회사 | 멀티미디어 데이터를 송수신하는 방법 및 장치 |
KR20190066572A (ko) | 2017-12-05 | 2019-06-13 | 한국전자통신연구원 | 가상화 기능 관리 장치 및 방법 |
KR102494744B1 (ko) * | 2018-03-22 | 2023-02-02 | 국방과학연구소 | 서비스의 연속성을 지원하는 클라우드 서버, 이를 포함하는 시스템 및 방법 |
KR102665217B1 (ko) * | 2018-06-18 | 2024-05-13 | 한국전자통신연구원 | 신뢰성을 제공하는 방송 게이트웨이 시그널링 방법 및 이를 위한 장치 |
-
2021
- 2021-01-29 KR KR1020210012830A patent/KR102593734B1/ko active IP Right Grant
Also Published As
Publication number | Publication date |
---|---|
KR20220056078A (ko) | 2022-05-04 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN111406415B (zh) | 多播和广播服务的方法和系统 | |
US11343786B2 (en) | Method for broadcast gateway signaling using cloud network and apparatus for the same | |
EP1867135B1 (en) | Method and apparatus for enhanced file distribution in multicast or broadcast | |
EP4075753B1 (en) | Methods and apparatus for enhanced mbms content provisioning and content ingestion | |
US20200153735A1 (en) | Data link layer-based communication method, device, and system | |
US20050136884A1 (en) | Data transport to mobile devices using a radio broadcast data channel | |
US11924260B2 (en) | Secure television distribution over heterogeneous networks | |
US10638443B2 (en) | Deregistration method of user equipment in network and user equipment performing the same | |
EP4154586B1 (en) | Methods and systems for multicast data forwarding during mobility procedures in wireless communication networks | |
US9425975B2 (en) | Multicast transmission using a unicast protocol | |
EP4060964B1 (en) | Method and apparatus for processing multicast signal | |
KR101346669B1 (ko) | 데이터 수신 방법, 복구 방법 및 대응 단말기 | |
US20130276065A1 (en) | System and methods for receiving and correcting content transmitted over multicast channels | |
US11825384B2 (en) | Access agnostic delivery of broadcast, multicast, or unicast content | |
KR102593734B1 (ko) | 클라우드 네트워크를 이용한 방송 게이트웨이 시그널링 방법 및 이를 위한 장치 | |
CN107800666B (zh) | 页面内容的处理方法及装置、主节点、从节点 | |
EP2586170A1 (en) | Network entity and method for providing data to at least one user entity in a communication network | |
Barjau et al. | Limitations of atsss technology in atsc 3.0–5g convergent systems | |
JP2014022969A (ja) | マルチホーム通信方法およびシステム | |
US20240163492A1 (en) | Secure Television Distribution Over Heterogeneous Networks | |
KR101078840B1 (ko) | 이종망 가입자를 지원하는 멀티캐스트 서비스 제공 방법 | |
KR101177354B1 (ko) | 이동 단말, 통신 네트워크 및 그것의 이동성 제어 방법 | |
US20150319669A1 (en) | Forwarding of service requests by a wireless controller | |
CN117354276A (zh) | 一种网络穿透系统的启动方法及报文收发方法、通信设备 | |
CN116941233A (zh) | 多播信号处理方法和设备 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
E902 | Notification of reason for refusal | ||
E90F | Notification of reason for final refusal | ||
E701 | Decision to grant or registration of patent right |