KR20230129247A - 멀티캐스트 신호 처리 방법 및 장치 - Google Patents

Abstract

실시예들에 따른 멀티캐스트 신호 수신 장치는 멀티캐스트 서버로부터 인터페이스에 기초하여, 멀티캐스트 신호를 수신하는 멀티캐스트 게이트웨이; 및 멀티캐스트 신호에 포함된 멀티캐스트 서비스를 플레이하는 컨텐트 플레이백부; 를 포함할 수 있다. 실시예들에 따른 멀티캐스트 신호 수신 방법은 멀티캐스트 서버로부터 인터페이스에 기초하여, 멀티캐스트 신호를 수신하는 단계; 및 멀티캐스트 신호에 포함된 멀티캐스트 서비스를 플레이하는 단계; 를 포함할 수 있다.

Description

멀티캐스트 신호 처리 방법 및 장치

본 발명은 멀티캐스트 신호를 처리하는 장치 및 방법에 관한 것이다.

디지털 기술 및 통신 기술의 발전으로 방송, 영화뿐만 아니라 인터넷 및 개인 미디어 등의 다양한 영역에서 오디오/비디오 중심의 멀티미디어 컨텐츠 보급 및 수요가 급속도로 확대되고 있다. 또한, 디스플레이 기술의 발전과 더불어 가정에서의 TV 화면이 대형화 됨에 따라 UHD (Ultra High Definition) 방송 서비스에 대한 논의가 증가되고 있는 추세이다.

방송 서비스와 관련하여, 복수의 사용자에게 동일한 컨텐츠를 전송하는 멀티캐스트 (multicast) 전송 방식은 유니캐스트 (unicast)와 브로드캐스트 (broadcast)의 장점을 모두 활용할 수 있으므로 효과적이다. 하지만, 기존의 멀티캐스트 전송 방식은 단일 네트워크 내에서만 가능했으며 이종망 간의 멀티캐스트 서비스가 불가능한 단점이 있었다. 이로 인해 멀티캐스트 수신 장치가 서로 다른 억세스 네트워크를 접속 및 접속해제하는 경우 기존 멀티캐스트 서비스가 종료된 후 새로운 멀티캐스트 서비스를 시작해야하는 문제점이 있었다. 또한 복수의 전송 프로토콜이 사용되는 경우 IP/UDP 또는 IP/TCP상에서 페이로드를 구성하는 프로토콜이 IANA에 등록되지 경우 포트 넘버를 이용하여 식별하는 것이 불가능하다. IP multicast의 경우 destination address및 port number는 멀티캐스트 에 할당된 값을 사용 하게 되므로, 모든 수신기에서 해당 패킷을 수신 하는데, 이때 알려지지 않은 프로토콜이 사용된 경우 해당 패킷에 대한 멀티캐스트를 처리할 수 없는 문제점이 있다.

본 발명의 목적은, 멀티캐스트 신호를 전송하는 방법 및 장치에 있어서 전송 효율을 높이는 것이다.

또한, 멀티플 네트워크들 간 멀티캐스트 서비스를 효울적으로 제공하는 것이다.

다만, 전술한 기술적 과제만으로 제한되는 것은 아니고, 기재된 전체 내용에 기초하여 당업자가 유추할 수 있는 다른 기술적 과제로 실시예들의 권리범위가 확장될 수 있다.

실시예들에 따른 멀티캐스트 신호 수신 장치는 멀티캐스트 서버로부터 인터페이스에 기초하여, 멀티캐스트 신호를 수신하는 멀티캐스트 게이트웨이; 및 멀티캐스트 신호에 포함된 멀티캐스트 서비스를 플레이하는 컨텐트 플레이백부; 를 포함할 수 있다. 실시예들에 따른 멀티캐스트 신호 수신 방법은 멀티캐스트 서버로부터 인터페이스에 기초하여, 멀티캐스트 신호를 수신하는 단계; 및 멀티캐스트 신호에 포함된 멀티캐스트 서비스를 플레이하는 단계; 를 포함할 수 있다.

본 발명의 실시예에 따르면, 멀티플 네트워크들 간 멀티캐스트 서비스를 제공할 수 있다.

실시예들에 따르면, 복수의 network 기반의 multicast media streaming 을 위한 media architecture를 제시하여, DVB Multicast ABR 구조가 적용될 수 있는 여러 network 에서도 동일한 수준의 media 서비스가 가능하다.

실시예들에 따르면, multicast streaming시 수신 device가 접속되어 있는 network 에 의존하지 않고, 다양한 접속 방법을 통해 multicast content를 수신할 수 있다.

실시예들에 따르면, 다양한 기기가 각각 별도의 network에 접속되어 있는 경우에 대해서도, 동일한 수준의 ABR multicast service 를 제공할 수 있다.

도면은 실시예들을 더욱 이해하기 위해서 포함되며, 도면은 실시예들에 관련된 설명과 함께 실시예들을 나타낸다. 이하에서 설명하는 다양한 실시예들의 보다 나은 이해를 위하여, 하기 도면들에 걸쳐 유사한 참조 번호들이 대응하는 부분들을 포함하는 다음의 도면들과 관련하여 이하의 실시예들의 설명을 반드시 참조해야 한다.
도1은 실시예들에 따른 멀티캐스트 ABR(Adaptive Bitrate) 구조를 나타낸다.
도2는 실시예들에 따른 멀티캐스트 랑데부 서비스 기반 프리젠테이션 마니페스트 획득 과정을 나타낸다.
도3은 실시예들에 따른 멀티캐스트 랑데부 서비스를 위한 구조를 나타낸다.
도4는 실시예들에 따른 멀티캐스트 랑데부 서비스를 위한 구조를 나타낸다.
도5는 실시예들에 따른 멀티캐스트 기반 미디어 수신의 흐름도를 나타낸다.
도6은 실시예들에 따른 URL 에 포함되는 엘리먼트를 나타낸다.
도7은 실시예들에 따른 URL 에 포함되는 엘리먼트를 나타낸다.
도8은 실시예들에 따른 5G 미디어 스트리밍에 대한 멀티캐스트 적용 방안을 나타낸다.
도9는 실시예들에 따른 멀티캐스트 네트워크 및 통신 네트워크 스트리밍 모두를 위한 멀티태스트 스트리밍 구조를 나타낸다.
도10은 실시예들에 따른 통신 네트워크에서 멀티캐스트 및 브로드캐스트에 기초하여 무선 미디어 전송을 하는 아키텍쳐를 나타낸다.
도11은 실시예들에 따른 각 네트워크에서 멀티캐스트 서버 구성 예시를 나타낸다.
도12는 실시예들에 따른 모든 네트워크들에 대한 멀티캐스트 서버 구성 예시를 나타낸다.
도13은 실시예들에 따른 장치가 접속하는 멀티플 네트워크 예시를 나타내다.
도14는 실시예들에 따른 네트워크 변경에 관한 흐름도를 나타낸다.
도15는 실시예들에 따른 Multicast server 및 multicast gateway가 각각의 network 에 구성되어 있는 예시를 나타낸다.
도16은 실시예들에 따른 네트워크 변경 흐름도를 나타낸다.
도17는 실시예들에 따른 Multicast server 및 multicast gateway가 각각의 network 에 구성되어 있는 예시를 나타낸다
도18은 실시예들에 따른 네트워크 변경 흐름도를 나타낸다.
도19는 실시예들에 따른 단일 multicast server 가 복수의 이종 network 에 대해 service 되며, 이에 대한 multicast gateway가 각각의 network 에 구성되어 있는 예시를 나타내다.
도20은 실시예들에 따른 네트워크 변경 흐름도를 나타낸다.
도21은 실시예들에 따른 단일 multicast server 가 복수의 이종 network 에 대해 service 되며, 이에 대한 multicast gateway가 각각의 network 를 구성하는 예시를 나타낸다.
도22는 실시예들에 따른 네트워크 변경 흐름도를 나타낸다.
도23은 실시예들에 따른 Multicast server 및 multicast gateway가 각각의 network 에 구성되어 있는 경우, 모든 multicast rendezvous service가 co-located deployment 로 구성되는 예시를 나타내다.
도24는 실시예들에 따른 네트워크 변경 흐름도를 나타낸다.
도25는 실시예들에 따른 Multicast server 및 multicast gateway가 각각의 network 에 구성되어 있는 경우에 대해서, device 가 service 가능한 다양한 network에 접속하는 실시예를 나타낸다.
도26은 실시예들에 따른 단일 multicast server 가 복수의 이종 network 에 대해 service 제공하며, 이에 대한 multicast gateway가 각각의 network 에 구성되는 구조를 나타낸다.
도27은 실시예들에 따른 ABR 멀티캐스트를 위한 프로토콜 구성을 나타낸다.
도28은 실시예들에 따른 복수의 network에 접속하기 위해 수신 장치에 구성될 수 있는 protocol 에 대한 실시 예를 나타낸다.
도29는 실시예들에 따른 프로토콜을 나타낸다.
도30은 실시예들에 따른 서비스 및 서비스에 관한 정보의 구성을 나타낸다.
도31은 실시예들에 따른 ABR 멀티캐스트를 위한 서비스 리스트 및 프리젠테이션 마니페스를 생성하고, 전송하는 방법을 나타낸다.
도32는 실시예들에 따른 service list 및 presentation manifest 관리를 나타낸다.
도33은 실시예들에 따른 서비스 리스트를 나타낸다.
도34은 실시예들에 따른 멀티캐스트 세션을 나타낸다.
도35는 실시예들에 따른 HTTP message의 Request URL에 포함되는 엘리먼트를 나타낸다.
도36은 실시예들에 따른 Location response header 의 Redirect URL 에 포함되는 정보를 나타낸다.
도37은 실시예들에 따른 멀티플 컨텐츠 프로바이더를 나타낸다.
도38은 실시예들에 따른 멀티플 서비스 프로바이더를 나타낸다.
도39는 실시예들에 따른 서비스 프로바이더 변경 흐름도를 나타낸다.
도40은 실시예들에 따른 유니다이렉셔널 딜리러비를 위한 MABR 네트워크 구성을 나타낸다.
도41은 실시예들에 따른 유니다이렉셔널 딜리러비를 위한 MABR 네트워크 구성을 나타낸다.
도42는 실시예들에 따른 인터페이스 구성을 나타낸다.
도43은 실시예들에 따른 인터페이스 구성을 나타낸다.
도44는 실시예들에 따른 링크 컨트롤 데이터(LCD) 구성을 나타낸다.
도45는 실시예들에 따른 링크 관련 디스크립터를 나타낸다.
도46은 실시예들에 따른 네트워크 컨트롤 데이터(NCD)를 나타낸다.
도47은 실시예들에 따른 멀티캐스트 트랜스포트 세션을 나타낸다.
도48은 실시예들에 따른 mABR IPv6트랜스포트 세션 디스크립터를 나타낸다.
도49는 실시예들에 따른 mABR IPv4트랜스포트 세션 디스크립터를 나타낸다.
도50은 실시예들에 따른 5G 시스템 서비스 기반 구조를 나타낸다.
도51은 실시예들에 따른 레퍼런스 포인트 리프리젠테이션 내 5G 시스템 구조를 나타낸다.
도52는 실시예들에 따른 멀티플 PDU 세션을 위한 5G 시스템 구조를 나타낸다.
도53은 실시예들에 따른 두 가지 데이터 네트워크들에 공존하는 접속을 위한 5G 시스템 구조를 나타낸다.
도54는 실시예들에 따른 유저 플레인 프로토콜 스택을 나타낸다.
도55는 실시예들에 따른 Unified Data Management (UDM) 을 나타낸다.
도56은 실시예들에 따른 5G 미디어 스트리밍을 위한 구조를 나타낸다.
도57은 실시예들에 따른 유니캐스트 다운링크 미디어 스트리밍을 위한 미디어 아키텍처(Media Architecture for unicast downlink media streaming)를 나타낸다.
도58은 실시예들에 따른 레퍼런스 구조를 나타낸다.
도59은 실시예들에 따른 레퍼런스 구조를 나타낸다.
도60은 실시예들에 따른 멀티캐스트 게이트웨이 배포 모델을 나타낸다.
도61는 실시예들에 따른 홈 게이트웨이 장치에 배포된 멀티캐스트 게이트웨이 구조를 나타낸다.
도62는 실시예들에 따른 단말 장치에 배포된 멀티캐스트 게이트웨이 구조를 나타낸다.
도63은 실시예들에 따른 하이브리드 방송 수신 장치를 나타낸다.
도64는 실시예들에 따른 멀티캐스트 GSE 레이어 구조를 나타낸다.
도65는 실시예들에 따른 DVB-GSE ROHC(Robust Header Compression) 프로파일 및 DVB-GSE 헤더 컴프레서를 나타낸다.
도66은 실시예들에 따른 ROHC-U 정보를 나타낸다.
도67은 실시예들에 따른 송신 장치 및 수신 장치를 나타낸다.
도68은 실시예들에 따른 멀티캐스트 송신 방법을 나타낸다.
도69는 실시예들에 따른 멀티캐스트 수신 방법을 나타낸다.

발명의 실시를 위한 최선의 형태

실시예들의 바람직한 실시예에 대해 구체적으로 설명하며, 그 예는 첨부된 도면에 나타낸다. 첨부된 도면을 참조한 아래의 상세한 설명은 실시예들의 실시예에 따라 구현될 수 있는 실시예만을 나타내기보다는 실시예들의 바람직한 실시예를 설명하기 위한 것이다. 다음의 상세한 설명은 실시예들에 대한 철저한 이해를 제공하기 위해 세부 사항을 포함한다. 그러나 실시예들이 이러한 세부 사항 없이 실행될 수 있다는 것은 당업자에게 자명하다.

실시예들에서 사용되는 대부분의 용어는 해당 분야에서 널리 사용되는 일반적인 것들에서 선택되지만, 일부 용어는 출원인에 의해 임의로 선택되며 그 의미는 필요에 따라 다음 설명에서 자세히 서술한다. 따라서 실시예들은 용어의 단순한 명칭이나 의미가 아닌 용어의 의도된 의미에 근거하여 이해되어야 한다.

실시예들에 따른 멀티캐스트 신호 처리 방법 및 장치는 멀티캐스트 신호 송신 방법, 수신 방법, 송신 장치, 수신 장치를 포함할 수 있고, 실시예들에 따른 방법/장치로 줄여서 지칭될 수 있다.

실시예들에 따른 방법/장치는 단방향 전송 기반의 Adaptive Bitrate Multicast 네트워크에서 Media 전송 방법에 관한 것이다(Method of Media Delivery in Adaptive Bitrate Multicast Network based on Unidirectional Delivery).

실시예들에 따른 미디어는 미디어 신호, 미디어 데이터 등으로 지칭가능하고, 서비스 또는 서비스 데이터에 대응하거나 서비스를 포함하는 용어로 해석될 수 있다.

실시예들은 IP(Internet Protocol) 기반 media 전송 시스템에서 미디어 스트리밍(media streaming)을 위한 아키텍쳐(architecture)를 제안한다.

실시예들은 IP 기반 media 전송 시스템이 복수의 네트워크(network)로 구성되어 있는 경우 Multicast 적용을 위한 미디어 스트리밍 아키텍쳐(media streaming architecture)를 제안한다.

실시예들은 IP 기반 media 전송 시스템이 복수의 network 로 구성되어 있는 경우 ABR Multicast 방법을 제안한다.

실시예들은 IP 기반 media 전송 시스템이 복수의 network 로 구성되어 있는 경우 서비스 리스트(service list) 수신 방법(flow) 및 디바이스(device, 실시예들에 따른 멀티캐스트 신호 처리 장치) 동작을 제안한다.

실시예들은 복수의 network 상에서 수신기(device)에 필요한 시그널링 정보를 제안한다.

실시예들에 따른 멀티캐스트 신호 처리 장치에 대응하는 컨텐츠 프로바이더(Content provider) 및 서비스 프로바이더(service provider)의 구성에 따른 멀티캐스트 ABR 구조(multicast ABR architecture)를 제안한다.

실시예들은 복수의 network 기반의 멀티캐스트 미디어 스트리밍(multicast media streaming)을 위한 media architecture를 제시하여, DVB Multicast ABR 구조가 적용될 수 있고, 여러 network 에서도 동일한 수준의 media 서비스가 가능한 효과를 제공한다. 특히, multicast streaming시 수신 device가 접속되어 있는 network 에 의존하지 않고, 다양한 접속 방법을 통해 multicast content를 수신할 수 있다.

따라서, 다양한 기기가 각각 별도의 network에 접속되어 있는 경우, 동일한 수준의 ABR multicast service 를 제공 할 수 있다.

실시예들에 따른 방법/장치는 단방향 딜리버리 네트워크(Unidirectional Delivery Network) 에서 적응형 비트레이트 멀티캐스트 미디어(Adaptive Bitrate Multicast media) 전송을 위한 멀티캐스트 트랜스포트 세션 맵핑(Multicast Transport Session mapping) 방법을 제공할 수 있다.

지상파 방송 또는 위성 방송과 같은 Unidirectional delivery network 에서, 기존 ISP network 에 적용을 목적으로 구성된 Adaptive Bitrate Multicast media 전송을 지원 하기 위해, Multicast transport session 을 unidirectional delivery network의 resource 에 mapping 할 수 있다.

Multicast Server 와 Multicast Gateway 사이의 interface에 unidirectional delivery network 가 적용 되어 있는 경우, transparent 한 전송을 지원 할 수 있다.

Network의 다양성과 함께, 다양한 기기가 network에 접속하게 되면서, 다양한 device 및 다수의 사용자에게 media streaming이 제공되는 것이 필요하다. 이러한 환경에서 모든 streaming session에 대해, 유니캐스트(unicast)로만 전송되는 경우에는 network의 부하의 증가로 media streaming 서비스뿐만 아니라, 해당 network를 이용한 다른 서비스에 대한 품질이 나빠지는 결과를 초래할 수 있다. 따라서, multicast 효율적인 multicast streaming 전송이 필요하다. 현재, DVB에서 정의 하고 있는 ABR multicast 구조는 multicast 를 제공하는 network가 단일 network 인 경우에 대해 주로 정의 되고 있다. 동일한 서비스를 5G network(무선 네트워크)를 포함하는 다양한 network 를 통해 서비스 하기 위해, 디바이스가 각각의 network 상에서 원활히 동작하도록 할 필요가 있다. 이를 위한 interface 및 architecture의 update가 필요할 수 있다. 또한, 기존의 service provider 가 ABR multicast 를 지원 하기 위해 너무 많은 network 의 변경이 이루어지는 경우, 구현의 어려움 및 비용 문제로 인해 실제 ABR Multicast service 가 제공되지 않는 경우가 될 수 있다.

Multicast 기술은 보편적인 media streaming을 위해 다양한 network 환경에서 서비스를 제공하고 있으며, IP 기반의 network에서 대부분 전송이 가능하다. 또한 복수의 이종 network 에 대해서 동일한 function을 이용하여 ABR multicast 서비스를 제공하기 위해서 각각의 network에 적응된 function 및 architecture 가 필요 하다. ABR multicast service가 여러 network를 통해 제공되는 경우, 사용자 관점에서 service에 대한 연속성을 제공해 주기 위해 service list에 대한 전송 및 이에 대한 관리방안에 대한 정의 가 필요하다.

본 문서에서는 DVB ABR multicast 구조가 다양한 network 를 통해 서비스 될 수 있는 architecture 및 이에 대한 interface를 기술 한다. 또한, 복수의 network를 통해 service list를 제공 하는 방안 및 해당 service list 에 대해 device 내에서 처리하는 interface 및 flow 를 기술 한다.

또한, 실시예들에 따른 방법/장치는 DVB 표준에서 정의 하고 있는 지상파 방송 및 위성 방송 link 와 같은 unidirectional delivery network 에서 DVB ABR multicast의 media object를 전송하기 위해 multicast transport session을 broadcast stream 과 연동시키기 위한 interface 및 signaling flow를 제공할 수 있다.

도1은 실시예들에 따른 멀티캐스트 ABR(Adaptive Bitrate) 구조를 나타낸다.

실시예들에 따른 멀티캐스트 신호 처리 방법/장치는 도1과 같은 구조에 기반하여 미디어 컨텐츠(Media contents)를 multicast 로 전송할 수 있다. 실시예들에 따른 미디어 컨텐츠는 멀티캐스트 미디어, 멀티캐스트 미디어 데이터, 서비스 데이터 등으로 지칭될 수 있다. 도1의 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다.

도1의 interface는 다음과 같이 정의될 수 있다.

L: 컨텐츠 플레이백부(Content Playback function) 및 멀티캐스트 게이트웨이(Multicast gateway) 사이의 유니캐스트 인터페이스(Unicast HTTP(S) interface)이다.

B: 컨텐츠 플레이백부(Content playback function) 및 멀티캐스트 부트스트랩부(Multicast Bootstrap function) 사이의 부트스트랩 유니캐스트 인터페이스(Bootstrap unicast HTTP(S) interface)이다. 최초 프리젠테이션 마니페스트(presentation manifest)를 요청하는데 사용될 수 있다.

M: 멀티캐스트 서버(Multicast Server)가 Multicast IP contents 전송을 하고 이를 멀티캐스트 게이트웨이(Multicast Gateway)가 수신하기 위한 interface이다.

U: Content Playback function이 content provider로부터 직접 unicast로 media content 를 수신하기 위한 interface이다.

인제스트(Ingest): Media contents를 Multicast Server에 제공하기 위한 interface이다.

CMS: Multicast server 를 configuration 하기 위한 control interface이다.

CMR: Multicast gateway 를 configuration 하기 위한 control interface이다.

Configuration: Content Provider, Provisioning, Multicast Bootstrap function 사이에 configuration 정보를 교환하기 위한 interface이다.

도1의 각 모듈은 다음과 같이 정의 할 수 있다. 각 모듈은 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응할 수 있다.

컨텐츠 프로바이더(Content Provider): Media content를 생성 하거나, 생성된 media content 를 저장하고 있으며, 이를 network를 통해 사용자에게 전달한다. 사용자에게 media content를 전송하기 위해 multicast 및 unicast 전송 방식을 사용 할 수 있으며, Multicast로 전송하기 위해서 multicast server에 ingest interface를 통해 media content data 및 control 정보 등을 제공한다. Media content data는 DASH 또는 HLS 등의 format으로 packaging 될 수 있으며, packaging format 에 따라 presentation manifest를 각각 구성할 수 있다.

멀티캐스트 서버(Multicast Server) - Media Content 를 Content provider로부터 제공 받아, IP Multicast 전송 방식 등을 이용하여, M interface를 통해 Multicast Gateway로 전송한다. 이때, 일부 control 정보가 함께 전송될 수 있다. Multicast protocol은 ROUTE, FLUTE, QUIC, RTP 등을 고려할 수 있다.

멀티캐스트 게이트웨이(Multicast Gateway - Multicast 로 전송되는 패키징된 컨텐츠 세그먼트(content segment)를 수신하고, 이를 다시 HTTP(S) 방식 등을 통해 L interface로 Content playback function에 제공한다. 이를 위해, content segment를 캐쉬(cache) 할 수 있다. 컨텐츠 세그먼트는 분할된 미디어 데이터를 의미할 수 있다. 분할된 미디어 데이터를 저장(캐쉬)할 수 있다.

프로비져닝(Provisioning) (Network Control) - 멀티캐스트 서버(Multicast Server) 및 멀티캐스트 게이트웨이(Multicast Gateway) 에 network 및 multicast streaming session 에 대한 구성(configuration) 정보를 제공한다.

멀티캐스트 부트스트랩(Multicast Bootstrap) - Content playback function이 B interface를 통해 최초 접속 되어야할 주소정보(url 또는 address)를 타겟팅(targeting)하여 처리할 수 있다. Content playback function 으로 부터 reference point B를 통해 오는 presentation manifest에 대한 초기 요청을 처리한다. Multicast 의 경우 L interface를 통한 manifest 수신을 위한 리다이렉션(redirection) 정보를 제공하고, Unicast 의 경우 U interface를 통한 manifest 수신을 위한 redirection 정보를 제공한다. DVB ABR Multicast 구조에서 멀티캐스트 랑데부 서비스(Multicast Rendezvous Service function)를 수행할 수 있다.

컨텐츠 플레이백(Content Playback) - Content playback function은 content의 요청, 수신, 디코딩(decryption), 프리젠테이션(presentation) 등을 관리한다. 인터페이스 L을 통해 unicast 전송을 고려할 수 있다.

어플리케이션(Application) - Application은 사용자의 입력을 바탕으로, Content playback function을 제어한다. 예를 들어, TV 나 set-top box 의 내장 control application (EPG application)또는 Content Provider가 제공하는 third-party application 이 될 수 있다. Application이 Content playback을 제어하는데 사용하는 인터페이스는 각각의 device에 따라 별도의 API 등으로 구현될 수 있다.

실시예들에 따른 멀티캐스트 신호 처리 방법/장치는 미디어를 전송하는 동작을 수행하는 관점에서, 멀티캐스트 서버, 멀티캐스트 게이트웨이를 포함하거나, 나아가, 컨텐츠 프로바이더, 프로비져닝, 멀티캐스트 부트스트랩부 등을 포함할 수 있다.

실시예들에 따른 멀티캐스트 신호 처리 방법/장치는 미디어를 수신하는 동작을 수행하는 관점에서, 컨텐츠 플레이백부, 어플리케이션 등을 포함할 수 있다.

도2는 실시예들에 따른 멀티캐스트 랑데부 서비스 기반 프리젠테이션 마니페스트 획득 과정을 나타낸다.

도1의 실시예들에 따른 멀티캐스트 신호 처리 방법/장치는 도2와 같이 멀티캐스트 랑데부 서비스를 수행할 수 있다. 도2의 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다.

컨텐츠 플레이백부(content playback function)는 multicast 수신 시 multicast gateway에 contents를 요청하고, unicast인 수신의 경우 컨텐츠 호스팅(content hosting)으로부터 content를 수신한다. 이를 위해 최초 Content playback function이 media contents를 수신을 위한 프리젠테이션 마니페스트(presentation manifest)를 획득하기 위해, 멀티캐스트 랑데부 서비스(Multicast rendezvous service)에 참조 포인트B(reference point B)를 통해 먼저 접속할 수 있다. 멀티캐스트 랑데부 서비스(multicast rendezvous service)는 멀티캐스트(multicast) 및 유니캐스트(unicast) 에 따라 적절하게 presentation manifest 를 획득할 수 있는 URL을 content playback function에 제공할 수 있다.

도3은 실시예들에 따른 멀티캐스트 랑데부 서비스를 위한 구조를 나타낸다.

도1-2 구조에서 실시예들에 따른 멀티캐스트 방법/장치는 도3과 같이 랑데부 서비스를 실행할 수 있다. 도3의 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다.

실시예들에 따른 멀티캐스트 랑데부 서비스 배치 방안(Deployment of Multicast Rendezvous service):

멀티캐스트 랑데부 서비스(Multicast rendezvous service)는 HTTP(s) 와 단일 방향(unidirectional) 전송에 대한 지원 여부에 따라, 보통 배치(regular deployment) 및 같이 배치되는 경우(co-located deployment)로 구성될 수 있다.

실시예들에 따른 멀티캐스트 신호 처리 장치의 Content playback function는 다음과 같은 동작을 통해서, manifest url 정보를 획득하고, 미디어 수신을 위한 구성(configuration)을 수행할 수 있다.

보통 배치(Regular deployment) - Multicast rendezvous service 가 Network에 구성되어 있으며, 시스템 오퍼레이터(system operator)에 의해 관리되는 경우.

같이 배치되는 경우(Co-located deployment) - Multicast rendezvous service 가 Multicast gateway와 동일한 장치 내 구현되어 있는 경우

보통 배치(Regular deployment)

도3을 참조하면, Multicast rendezvous service 가 network에 위치하며, system operator에 의해 관리 및 제어되는 구성에 해당한다.

Content playback function은 수신을 희망하는 contents에 최초 접근시, reference point B를 통해 Multicast rendezvous service 로부터 contents 수신을 위한 manifest url 정보를 획득할 수 있다. 이를 위해, 다음과 같은 configuration이 이루어 질 수 있다.

기본적 파라미터(Basic parameter)의 set (예를 들어, 멀티캐스트 게이트ㅜ에이 구성 트랜스포트 세션의 엔드포인트 주소 등)에 대한 configuration이 Multicast gateway에 적용 될 수 있다. 이러한 configuration으로 인-밴드 멀티캐스트 게이트웨이 구성 방법(in-band multicast gateway configuration method)이 사용될 수 있다.

레퍼런스 포인트 CMR(Reference point CMR), 또는 레퍼런스 포인트 CMS(reference point CMS)와 M을 통해 현재 프로비전(provision)되어 있는 멀티캐스트 세션(multicast session)의 set에 대한 configuration이 Multicast gateway에 적용될 수 있다. 이러한 configuration은 in-band multicast gateway configuration method 뿐만 아니라, 아웃-오브-밴드 푸쉬 구성, 아웃-오브-밴드 풀 구성, 저스트-인-타임 구성 방법(out-of-band pushed configuration, out-of-band pulled configuration, Just-in-time configuration method)이 적용될 수 있다.

도4는 실시예들에 따른 멀티캐스트 랑데부 서비스를 위한 구조를 나타낸다.

도4는 도3에서 나아가, 같이 배치되는 경우(Co-located deployment) 를 나타낸다.

Co-located deployment:

도4와 같이, Multicast rendezvous service 가 multicast gateway와 동일한 장치(실시예들에 따른 멀티캐스트 처리 장치)에 구성될 수 있다. 주로 Multicast ABR network가 단일 방향 배치(unidirectional deployment )로 구성되어 있는 경우에 사용될 수 있다. 도4의 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다.

Content playback function은 수신을 희망하는 contents에 최초 접근시, reference point B를 통해 Multicast rendezvous service 로부터 contents 수신을 위한 manifest url 정보를 획득할 수 있다. 이를 위해, 다음과 같은 configuration이 이루어 질 수 있다.

기초 파라미터(Basic parameter) 의 set (ex. 멀티캐스트 게이트웨이 구성 트랜스포트 세션의 엔드포인트 주소 등) 에 대한 configuration 이 Multicast rendezvous service 에 적용될 수 있다.

reference point M을 통해 현재 provision 되어 있는 multicast session의 set에 대한 configuration 이 Multicast gateway 에 적용될 수 있다.

이때, 각각의 configuration은 in-band multicast gateway configuration method가 사용될 수 있다.

도5는 실시예들에 따른 멀티캐스트 기반 미디어 수신의 흐름도를 나타낸다.

실시예들에 따른 멀티캐스트 신호 처리 방법/장치(도1-4)는 다음과 같은 흐름도에 기반하여 멀티캐스트 미디어를 수신할 수 있다.

실시예들에 따른 멀티캐스트 오퍼레이션(Multicast operation):

사용자 또는 멀티캐스트 신호 처리 장치가 수신할 multicast contents를 선택하면, 해당 어플리케이션(Application)가 서비스 디렉토리(Service directory) 등을 통해 최초 프리젠테이션 마니페스트(presentation manifest)를 요청할 URL을 획득할 수 있다(5000). 이때 URL은 멀티캐스트 랑데부 서비스(Multicast rendezvous service)를 가리킨다.

어플리케이션(Application)은 content playback function이 content 수신을 위한 동작을 시작할 수 있도록 제어하며, 이때, Multicast rendezvous service 에 대한 URL을 전달할 수 있다.

Content playback function은 application으로부터 획득한 URL을 이용하여, reference point B를 통해 Multicast rendezvous service에 presentation manifest를 요청한다(5001).

Multicast rendezvous service는 Multicast gateway의 상태를 체크 하고, 요청된 presentation manifest 에 대한 service가 multicast configuration에 정의 되어 있으면, Multicast gateway 에 대한 redirection URL을 content playback function에 전송한다(5002). 이때 전송되는 redirection message에 multicast session configuration을 포함시킬 수 있다.

Redirection message를 수신한 content playback function은 해당 redirection을 따라 Multicast gateway에 presentation manifest를 요청한다(5003).

Multicast gateway 에 미리 presentation manifest 가 cache 되어 있는 경우, 해당 presentation manifest 를 content playback function으로 전송한다(5004).

Multicast gateway에 presentation manifest가 cache 되어 있지 않은 경우, reference point A를 통해 해당 presentation manifest 를 Content hosting function으로부터 가져 올 수 있으며 이를 다시 content playback function으로 전송한다.

Content playback function은 수신된 presentation manifest를 바탕으로 해당 contents 에 대한 media segment 를 Multicast gateway를 통해 수신할 수 있다.

이와 같은 동작에서, content playback function이 Multicast rendezvous service에 보내는 HTTP message의 Request URL의 syntax는 다음과 같다:

http[s]://<Host>/<ManifestPath>[?<field>=<value>[&<field>=<value>]*]

도6은 실시예들에 따른 URL 에 포함되는 엘리먼트를 나타낸다.

위URL에 포함되는엘리먼트(element)들은 도6과 같다.

Host: FQDN(또는 IP 주소) 및 선택적으로 멀티캐스트 랑데뷰 서비스의 포트 번호이다.

ManifestPath: 지정된 호스트에서 프레젠테이션 매니페스트를 검색하기 위한 리소스 경로이다.

AToken: 이 값은 시스템 운영자가 요구하는 경우 멀티캐스트 랑데뷰 서비스에 대한 액세스를 승인하는 인증 토큰이다. 이것은 원래 프레젠테이션 매니페스트 URL에 포함되었을 수도 있고, 이전 HTTP 리디렉션 URL의 일부로 타사 CDN 브로커에 의해 추가되었을 수도 있고, 애플리케이션에 의해 로컬로 생성되었을 수도 있다.

MGstatus: 이 값은 멀티캐스트 게이트웨이의 현재 상태이다: 0 = inactive, 1 = active

MGid: 이 값은 멀티캐스트 게이트웨이의 포트 번호이며 선택적으로 IP 주소가 앞에 온다: 포맷은[IP address]:port이다.

MGhost: 값은 멀티캐스트 게이트웨이 호스트 이름이다.

Ori: 이 값은 원래 대상 호스트의 호스트 이름(FQDN)이다.

어프릴케이션은 원래 대상 호스트 이름(FQDN)을 로컬 멀티캐스트 랑데뷰 서비스 호스트 이름 또는 주소로 대체할 수 있다. 또한 타사 CDN 브로커에 의존하는 경우 후자는 멀티캐스트 랑데뷰 서비스로 요청을 리디렉션하기 전에 원래 대상 호스트 이름(FQDN)을 여기에서 나타낼 수 있다.

Multicast rendezvous service 는 이러한 request URL 을 수신 하면, 307 Temporary Redirect 응답을 보낼 수 있다. 여기에서, Location response header 의 Redirect URL 의 syntax는 다음과 같다:

http[s]://<Host>[/session ID]/<ManifestPath>[?conf=<multicast session

도7은 실시예들에 따른 URL 에 포함되는 엘리먼트를 나타낸다.

위 URL에 포함되는 엘리먼트들은 도7과 같다.

Host: 멀티캐스트 게이트웨이의 IP 주소 또는 FQDN 및 선택적으로 포트 번호(예: "router.example:8088" 또는 "192.0.2.1:8088")이다.

Session ID: 하나 이상의 URL 경로 요소를 포함하는 멀티캐스트 랑데뷰 서비스에 의해 전달되고 생성될 수 있는 고유한 프레젠테이션 세션 식별자이다.

ManifestPath: 지정된 호스트에서 프레젠테이션 매니페스트를 검색하기 위한 리소스 경로이다.

conf: 멀티캐스트 세션 매개변수는 하나의 멀티캐스트 세션을 포함하는 멀티캐스트 게이트웨이 구성 인스턴스 문서의 형식을 취한다.

문서는 URL 쿼리 문자열 매개변수로 포함되기 전에 Gzip 및 base64url 인코딩을 사용하여 압축된다.

이때, presentation manifest 가 multicast session configuration내의 multicast session 과 관련된 것이면 (service를 multicast로 전송 가능), Multicast rendezvous service는 다음과 같이 request를 Multicast gateway로 redirection 할 수 있다:

HTTP/1.1 307 Temporary Redirect

Server: <Multicast gateway>

Location: http[s]://<Multicast gateway>/<ManifestPath>

HTTP header의 Location field 에 해당 하는 URL은 session identifier 와 요청된 presentation manifest 에 해당 하는 multicast session을 포함하는 multicast gateway configuration instance document를 piggybacking 하는 query parameter 를 포함할 수 있다.

실시예들에 따른 멀티캐스트 ABR은 5G 네트워크(통신 네트워크)와 연결될 수 있다.

도8은 실시예들에 따른 5G 미디어 스트리밍에 대한 멀티캐스트 적용 방안을 나타낸다.

실시예들에 따른 멀티캐스트 신호 처리 방법/장치는 5G media streaming 구조에서 multicast를 지원할 수 있다(Multicast ABR architecture). 도9는 Multicast ABR architecture 를 적용한 5G Media streaming architecture에 대한 실시예를 도시한 것이다. 즉, 5G 구조 및 DVB 구조가 서로 결합될 수 있다.

5G 어플리케이션 프로바이더(5GMSd Application Provider)는 도1-6 등의 Multicast ABR 의 Content Provider와 동일하거나, Content Provider의 부분일 수 있다. 해당 5G media streaming 을 수신 하기 위한 어플리케이션(5GMSd Aware Application)은 도1-6 등의 Multicast ABR 의 Application 과 동일하거나, Application의 부분일 수 있다. 클라이언트(5GMSd Client)는 도1-5 등의 Multicast ABR의 content playback function 과 동일하거나, content playback function의 부분일 수 있다. 제어부(5GMSd AF) 에는 도1-6 등의 Multicast ABR 의 network control sub function을 포함하는 provisioning function과, multicast rendezvous service 를 포함하는 multicast bootstrap function이 포함될 수 있다.

5GMSd Client 가 최초 multicast 전송을 위한 접속 정보(access information) (presentation manifest url)은 M5d interface를 통해 요청 및 수신될 수 있으며, 이것은 도1-6 등의 Multicast ABR의 B interface의 에 해당할 수 있다.

유니캐스트 스트리밍(Unicast streaming)은 M4d interface를 통해 5GMSd AS 로부터 Media Player로 전송되며, 이때, HTTP(s)가 이용될 수 있다.

5GMSd AS 와 Media Player 사이의 multicast 전송을 위해 Multicast server 및 Multicast Gateway 가 구성될 수 있다. Multicast Gateway 와 Media Player 사이에는 5G RAN을 통해 data가 전송되므로, Unicast 만 지원될 수 있다.

Multicast 전송을 위해 다음과 같이 인터페이스 M4d_M 및 M4d_L 을 정의 할 수 있다.

M4d_M - Multicast streaming은 M4d_M interface를 통해 5GMSd AS 로부터 multicast server로 전송되고, multicast server 와 multicast gateway 사이는 multicast ABR 에서 정의 된 M interface가 이용될 수 있다. 또다른 실시예로, 5GMS AS 내에 multicast server 기능이 포함 될 수 있다. 이 경우, M4d_M interface는 생략될 수 있다. Multicast protocol 은 M interface에서 정의 된 protocol이 사용될 수 있다.

M4d_L - Multicast gateway 와 Media player 사이는 M4d_L interface 가 이용될 수 있다. 여기에서, M4d_M 과 M4d_L 은 HTTP(s) 를 기반으로 하는 protocol을 이용할 수 있으며, DVB Multicast ABR 관점에서 M4d_M 은 ingest interface, M4d_L 은 L interface에 해당 할 수 있다.

도9는 실시예들에 따른 멀티캐스트 네트워크 및 통신 네트워크 스트리밍 모두를 위한 멀티태스트 스트리밍 구조를 나타낸다.

실시예들에 따른 멀티캐스트 신호 처리 방법/장치는 Multicast streaming 이 DVB Multicast ABR network 와 5G Media streaming 에 동시에 서비스 되는 경우, 미디어 컨텐츠를 송수신하고 처리할 수 있다. 도9의 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다.

Multicast streaming 이 서비스 되는 복수의 network 가 존재할 수 있으며, 5G network 가 그 중 하나라고 할 때, 실시예들에 따른 동일한 content provider 로 부터 5G mobile network 와 그 외의 IP network를 통해 동시에 multicast 서비스 되는 유즈 케이스(use case)를 고려할 수 있다. 도9는 Multicast streaming이 5G network 및 DVB Multicast ABR network에 동시에 service 되는 실시 예에 대해 도시한 것이다.

멀티캐스트 세션 구성(multicast session configuration)을 위한 프로비져닝(provisioning)은 및 각각의 network의 특성에 따라 별도로 정의 될 수 있다. Multicast server 에서 multicast gateway로 media를 전달하는 multicast interface M은 동일하게 구성 될 수 있다.

이때, 5G network 에서 정의 되는 M2d 및 M4d_M interface는 Ingest interface와 동일한 interface 가 될 수 있다. 이로 인해, content provider 에서는 각각의 network 를 통해 전송되는 protocol을 동일하게 유지할 수 있다.

도10은 실시예들에 따른 통신 네트워크에서 멀티캐스트 및 브로드캐스트에 기초하여 무선 미디어 전송을 하는 아키텍쳐를 나타낸다.

5G RAN 에서 multicast 및 broadcast 무선 전송이 지원 되는 경우, multicast gateway 가 5G UE 내부에 구성될 수 있다. 도10의 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다.

5GMSd Application Provider는 Multicast ABR 의 Content Provider와 동일하거나, Content Provider의 부분일 수 있다. 해당 5G media streaming 을 수신 하기 위한 5GMSd Aware Application 은 Multicast ABR 의 Application 과 동일하거나, Application의 부분일 수 있다. 5GMSd Client는 Multicast ABR의 content playback function 과 동일하거나, content playback function의 부분일 수 있다. 5GMSd AF 에는 Multicast ABR 의 network control sub function을 포함하는 provisioning function과, multicast rendezvous service 를 포함하는 multicast bootstrap function이 포함될 수 있다.

5GMSd Client 가 최초 multicast 전송을 위한 access information (presentation manifest url)은 M5d interface를 통해 요청 및 수신될 수 있으며, 이것은 Multicast ABR의 B interface의 에 해당할 수 있다.

Unicast streaming은 M4d interface를 통해 5GMSd AS 로부터 Media Player로 전송되며, 이때, HTTP(s)가 이용될 수 있다.

5GMSd AS 와 Media Player 사이의 multicast 전송을 위해 Multicast server 및 Multicast Gateway 가 구성될 수 있다. 이러한 경우 Multicast Gateway 와 Media Player 사이의 interface M4d_L은 UE 내부의 interface로 구현 될 수 있다.

Multicast server 와 multicast gateway 사이의 interface M4d_M 는 multicast ABR 에서 정의 된 M interface 와 동일한 interface로 정의 될 수 있다. 따라서, Multicast protocol 은 M interface에서 정의 된 protocol이 사용될 수 있다.

실시예들에 따른 방법/장치/프로세서(멀티캐스트 신호 처리 방법/장치)는 상술한 네트워크 제어 동작들을 수행하고, 관련 시그널링 정보에 기반하여, 5G network 기반의 multicast media streaming 을 위한 media architecture를 제공할 수 있다. 실시예들에 따른 동작들은 multicast streaming시 수신 device가 접속되어 있는 network 에 의존하지 않고, 다양한 접속 방법을 통해 multicast content를 수신할 수 있는 효과를 제공한다. 또한, multicast 전송 구조를 제시함으로써, 동일한 content 를 복수의 수신기에 전송하여 network 의 자원을 효율적으로 사용할 수 있다.

실시예들은 멀티플 IP네트워크들 기반 MABR 아키텍쳐를 포함한다.

실시예들에 따른 멀티플 IP네트워크들은 통신, 방송망 등 다양한 네트워크 등을 포함할 수 있다.

실시예들에 따른 ABR multicast 구조 및 interface가 실제 서비스 되기 위해 각각의 network에 적용 되기 위해 추가적인 architecture 구성 및 이에 대한 interface 의 적용 방안에 대해 기술한다. 실시예들에 따른 아키텍쳐에 포함된 각 구성요소는 하드웨어, 소프트웨어, 프로세서 및/또는 그것들의 조합에 대응할 수 있다.

도8-10은 도1-6등에 도시된 실시예들에 따른 멀티캐스트 신호 처리 방법/장치에 대응한다.

도11은 실시예들에 따른 각 네트워크에서 멀티캐스트 서버 구성 예시를 나타낸다.

도11은 multicast server 가 각각의 network 마다 구성되어 ABR multicast service를 제공하는 구조에 대한 실시예를 나타낸다. 주로 multicast service server가 network operator 에 의해 deployment 되어 있는 경우에 해당 한다. 실시예들에 따른 송수신 장치는 다음 그림의 멀티캐스트 서버 구조에 기반하여 ABR 멀티캐스트 서비스를 제공할 수 있다. 도11의 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다.

복수의 이종 network를 통해, ABR multicast 가 service 되는 경우는 ABR multicast를 수신 하는 multicast gateway의 deployment가 별도로 이루어 질 수 있다.

Multicast gateway (A) - ISP network에서 ABR multicast 의 서비스를 위해 multicast gateway가 구성되는 경우에는 ISP operator로부터 제공되는 router 또는 home gateway 내에 구성 될 수 있다.

Multicast gateway (B) - 5G 시스템과 같은 Mobile network 에서 ABR multicast 의 서비스를 위해 multicast gateway가 구성되는 경우에는 mobile network의 edge 내에 구성 될 수 있다.

Multicast gateway (C) - 위성 방송 network에 에서 ABR multicast 의 서비스를 위해 multicast gateway가 구성되는 경우에는 위성 방송을 수신할 수 있는 STB 내에 구성 될 수 있다.

Multicast gateway (D) - Terrestrial Broadcast network서 ABR multicast 의 서비스를 위해 multicast gateway가 구성되는 경우에는 broadcast 수신기 내에 구성 될 수 있다.

이러한 ABR multicast service 가 복수의 이종 네트워크를 통해 제공 되는 경우라 하더라도, 각각의 네트워크에 대해서 독립적으로 ABR multicast function이 구성될 수 있다.

도12는 실시예들에 따른 모든 네트워크들에 대한 멀티캐스트 서버 구성 예시를 나타낸다.

단일 Multicast server가 복수의 이종 network를 통해 ABR multicast service를 제공하는 구조에 대한 실시 예를 나타낸다. 주로 multicast service server가 content provider에 의해 deployment 되어 있는 경우에 해당 한다. 실시예들에 따른 송수신 장치는 다음 그림의 멀티캐스트 서버 구조에 기반하여 ABR 멀티캐스트 서비스를 제공할 수 있다.

도12의 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다.

복수의 이종 network를 통해, ABR multicast 가 service 되는 경우는 ABR multicast를 수신 하는 multicast gateway의 deployment가 별도로 이루어 질 수 있다.

Multicast gateway (A) - ISP network에서 ABR multicast 의 서비스를 위해 multicast gateway가 구성되는 경우에는 ISP operator로부터 제공되는 router 또는 home gateway 내에 구성 될 수 있다.

Multicast gateway (B) - 5G 시스템과 같은 Mobile network 에서 ABR multicast 의 서비스를 위해 multicast gateway가 구성되는 경우에는 mobile network의 edge 내에 구성 될 수 있다.

Multicast gateway (C) - 위성 방송 network에 에서 ABR multicast 의 서비스를 위해 multicast gateway가 구성되는 경우에는 위성 방송을 수신할 수 있는 STB 내에 구성 될 수 있다.

Multicast gateway (D) - Terrestrial Broadcast network서 ABR multicast 의 서비스를 위해 multicast gateway가 구성되는 경우에는 broadcast 수신기 내에 구성 될 수 있다.

이러한 ABR multicast service 가 복수의 이종 네트워크를 통해 제공 되는 경우라 하더라도, 각각의 네트워크에 대해서 독립적으로 ABR multicast function이 구성될 수 있다.

도13은 실시예들에 따른 장치가 접속하는 멀티플 네트워크 예시를 나타내다.

실시예들에 따른network 구조에서, 복수의 network 에 접속하여 동일한 multicast media service를 수신 할 수 있는 실시예들에 따른 멀티캐스트 신호 처리 방법/장치를 고려할 수 있다. 복수의 network 에 접속하여 동일한 multicast streaming service를 수신 할 수 있는 실시예들에 따른 멀티캐스트 신호 처리 방법/장치에 대한 architecture 및 ABR multicast interface에 대한 실시예에 대해 기술한다. 실시예들은 다양한 아키텍쳐들로 구현될 수 있다.

다음은 Multicast server 및 multicast gateway가 각각의 network 에 구성되어 있는 경우에 대해서, 모든 multicast rendezvous service가 regular deployment 로 구성 되어 있는 경우에 대한 실시예를 나타낸 것이다. 실시예들에 따른 시스템은 서비스 프로바이더, 네트워크(들), 디바이스를 포함할 수 있다. 실시예들에 따른 서비스 프로바이더, 네트워크(들), 디바이스의 구성은 도13과 같다. 도13의 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다.

실시예들에 따른architecture에서는 각각의 network 에 대해서, multicast server, multicast gateway, multicast rendezvous service 가 각각의 network에 접속되어 있는 content playback function에 service를 제공한다. 예를 들어, device 가 ISP network 를 통해 Wi-Fi 에 접속과 동시에, mobile network 에 접속하는 경우를 고려할 수 있다.

Device 내의 content playback function은 두개의 L interface (L1, L2) 및 두개의 B interface (B1, B2)가 구성 될 수 있다. L1 interface 를 통해 multicast gateway(A)를 통해 media streaming 을 수신할 수 있으며, B1 interface를 통해 초기 multicast gateway(A) 에 대한 접속 정보를 수신 할 수 있다. L2 interface 를 통해 multicast gateway(B)를 통해 media streaming 을 수신할 수 있으며, B2 interface를 통해 초기 multicast gateway(B) 에 대한 접속 정보를 수신 할 수 있다.

Service discovery interface를 통해 application은 multicast service 의 list 및 해당하는 multicast rendezvous service 에 대한 접속 정보를 획득한다. Service discovery interface는 service provider 와 application 사이에서 별도로 정의된 방법을 따를 수 있다. 또한 각각의 network 는 service discovery interface에 대한 data 의 송수신을 지원 할 수 있다.

도11-13은 도1-6, 도9-10 등 실시예들에 따른 멀티캐스트 신호 처리 장치가 실시예들에 따른 네트워크들 타입에 따라 구성되는 예시를 나타낸다.

다음은 이러한 architecture에 대해 device가 manifest를 획득하고, multicast media 를 수신 하는 과정에 이어서, network 가 변경된 이후에도 동일한 service를 수신하는 과정에 대한 flow를 나타낸 것이다.

실시예들에 따른 네트워크 변경은, 예를 들어, 네트워크A (WI-FI) 및 네트워크B (5G) 간 변경을 포함할 수 있다.

도14은 실시예들에 따른 네트워크 변경에 관한 흐름도를 나타낸다.

도14 흐름도는 도1-5, 8-13 등에 도시된 실시예들에 따라 수행될 수 있다. 실시예들을 구성하는 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다.

Multicast Server 와 관련한 flow 는 다음과 같이 진행된다.

각각의 function이 architecture에 따라 deploy 되고 Multicast service 에 대한 configuration 이 multicast server, multicast gateway, multicast rendezvous service 에 적용된다.

Provisioning function 은 network control을 통해 현재 provisioning 되어 있는 multicast session에 대한 configuration 정보를 multicast server (A) 와 multicast server (B)에 전달한다.

멀티케스트 세션 엘리먼트를 통해서, 멀티캐스트 세션에 대한 구성 정보를 전달할 수 있다.

Multicast session이 시작되면, content provider 로부터 multicast server (A) 와 multicast server (B)에 media segment가 ingest 되고, multicast 전송을 시작하며, 해당 media segment를 수신할 수 있는 multicast gateway 가 있으면 수신 가능한 상태가 된다.

Device 가 network A 에 접속하게 되면 다음과 같이 동작할 수 있다.

Application 은 network A를 거쳐 service provider 로부터 service list 를 수신 할 수 있다. Service list 를 수신 하기 위해서 network A 에서 정의 되어 있는 service list 획득 방법이 사용 될 수 있다. 예를 들어, DVB-I network 에서 service directory 가 구성되어 있으면, service provider, service directory, application 사이의 상호 동작을 통해 service list를 수신할 수 있다. ABR multicast 동작을 위해서, service list 에는 service ID 에 mapping 되는 presentation manifest를 요청할 url 이 포함 될 수 있다.

서비스 리스트 엘리먼트를 통해서, 서비스 리스트를 전달할 수 있다.

사용자가 수신할 multicast contents를 선택하면, 해당 Application에서 Service directory 등을 통해 최초 presentation manifest 를 요청할 URL을 획득할 수 있다. 이때 URL은 Multicast rendezvous service (A)를 가리킨다.

Application 은 content playback function이 content 수신을 위한 동작을 시작할 수 있도록 제어하며, 이때, Multicast rendezvous service(A) 에 대한 URL을 전달 할 수 있다.

Content playback function 은 application으로부터 전달된 URL을 이용하여, reference point B1를 통해 Multicast rendezvous service(A)에 presentation manifest를 요청한다.

마니페스트 요청 및 리다이렉션 정보를 통해서, 마니페스트를 요청할 수 있다.

Multicast rendezvous service(A) 는 동일 network에 구성되어 있는 Multicast gateway(A)의 상태를 체크 하고, 요청된 presentation manifest 에 대한 service가 multicast configuration에 정의 되어 있으면, Multicast gateway(A) 에 대한 redirection URL을 content playback function에 전송한다. 이때 전송되는 redirection message에 업데이트 된 multicast session configuration을 포함시킬 수 있다.

마니페스트 요청 및 리다이렉션 정보를 통해서, 리다이렉션을 수행할 수 있다.

Redirection message 를 수신한 content playback function은 해당 redirection을 따라 reference point L1을 통해 Multicast gateway(A)에 presentation manifest를 요청한다.

프리젠테이션 마니페스트를 요청할 수 있다.

Multicast gateway(A) 에 미리 presentation manifest 가 cache 되어 있는 경우, 해당 presentation manifest 를 content playback function으로 전송한다.

Content playback function은 수신된 presentation manifest를 바탕으로 해당 contents 에 대한 media segment 를 요청한다.

Multicast streaming 이 multicast server(A) 에서 multicast gateway(A) 로 M1 interface를 통해 전송된다.

Content playback function은 Multicast gateway(A)를 통해 요청한 media segment를 수신할 수 있으며 media가 play 된다. 별도의 control이 없는 경우 media 의 play가 지속된다.

이 상태에서, device 가 network A 에서 network B로 접속을 변경하게 되면 다음과 같이 동작할 수 있다.

Application 은 network B를 거쳐 service provider 로부터 service list 를 수신 할 수 있다. Service list 를 수신 하기 위해서 network B 에서 정의 되어 있는 service list 획득 방법이 사용 될 수 있다. Network A를 통해 수신된 multicast session 을 이어서 수신 하기 위해 해당 service ID 에 대한 session 정보를 교환 할 수 있다. 수신된 service list 에는 service ID 에 mapping 되는 presentation manifest를 요청할 url 이 포함 될 수 있다.

수신중에 있는 service 에 대해, Application에서는 presentation manifest 를 요청할 URL을 획득할 수 있다. 이때 URL은 Multicast rendezvous service (B)를 가리킨다.

Application 은 content playback function이 content 수신을 위한 동작을 시작할 수 있도록 제어하며, 이때, Multicast rendezvous service(B) 에 대한 URL을 전달 할 수 있다.

Content playback function은 application으로부터 전달된 URL을 이용하여, reference point B2를 통해 Multicast rendezvous service(B)에 presentation manifest를 요청한다.

Multicast rendezvous service(B)는 동일 network에 구성되어 있는 Multicast gateway(B)의 상태를 체크 하고, 요청된 presentation manifest 에 대한 service가 multicast configuration에 정의 되어 있으면, Multicast gateway(B) 에 대한 redirection URL을 content playback function에 전송한다. 이때 전송되는 redirection message에 업데이트 된 multicast session configuration을 포함시킬 수 있다.

Redirection message를 수신한 content playback function은 해당 redirection을 따라 reference point L2를 통해 Multicast gateway(B)에 presentation manifest를 요청한다.

Multicast gateway(B) 에 미리 presentation manifest 가 cache 되어 있는 경우, 해당 presentation manifest 를 content playback function으로 전송한다.

Content playback function은 수신된 presentation manifest를 바탕으로 해당 contents 에 대한 media segment 를 요청한다.

Multicast streaming이 multicast server(B) 에서 multicast gateway(B) 로 M2 interface를 통해 전송된다.

Content playback function은 Multicast gateway(B)를 통해 요청한 media segment를 수신할 수 있으며 media가 play 된다. 별도의 control이 없는 경우 media 의 play가 지속된다.

도15는 실시예들에 따른 Multicast server 및 multicast gateway가 각각의 network 에 구성되어 있는 예시를 나타낸다.

실시예들은 도13의 구성에서 더 나아가, 도15과 같이, 네트워크 서버 및 게이트웨이를 포함할 수 있다.

Multicast server 및 multicast gateway가 각각의 network 에 구성되어 있는 경우에 대해서, Multicast rendezvous service가 regular deployment 및 co-located deployment 로 구성 되어 있는 경우에 대한 실시예를 나타낸 것이다. 실시예들에 따른 시스템은 서비스 프로바이더, 네트워크(들), 디바이스를 포함할 수 있다. 실시예들에 따른 서비스 프로바이더, 네트워크(들), 디바이스의 구성은 도15과 같다. 도15의 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다.

상기 architecture에서는 각각의 network 에 대해서, multicast server, multicast gateway, multicast rendezvous service 가 각각의 network에 접속되어 있는 content playback function에 service를 제공한다. 예를 들어, device 가 ISP network 를 통해 Wi-Fi 에 접속과 동시에, 위성 방송 network를 통한 셋탑박스에 접속하는 경우를 고려할 수 있다.

Device 내의 content playback function은 두개의 L interface (L1, L2) 및 두개의 B interface (B1, B2)가 구성 될 수 있다. L1 interface 를 통해 multicast gateway(A)를 통해 media streaming 을 수신할 수 있으며, B1 interface를 통해 초기 multicast gateway(A) 에 대한 접속 정보를 수신 할 수 있다. L2 interface 를 통해 multicast gateway(B)를 통해 media streaming 을 수신할 수 있으며, B2 interface를 통해 초기 multicast gateway(B) 에 대한 접속 정보를 수신 할 수 있다.

Service discovery interface를 통해 application은 multicast service 의 list 및 해당하는 multicast rendezvous service 에 대한 접속 정보를 획득한다. Service discovery interface는 service provider 와 application 사이에서 별도로 정의된 방법을 따를 수 있다. 또한 각각의 network 는 service discovery interface에 대한 data 의 송수신을 지원 할 수 있다.

도16은 실시예들에 따른 네트워크 변경 흐름도를 나타낸다.

도16의 흐름도는 도1-5, 8-15 등에 도시된 실시예들에 따라 수행될 수 있다. 실시예들을 구성하는 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다.

다음은 실시예들에 따른 architecture에 대해 device가 manifest를 획득하고, multicast media 를 수신 하는 과정에 이어서, network 가 변경된 이후에도 동일한 service를 수신하는 과정에 대한 flow를 나타낸 것이다. 도14와 차이는 도16의 네트워크는 하나의 네트워크가 양방향 네트워크가 아닌 경우를 포함하는 것이다.

Multicast Server 와 관련한 flow 는 다음과 같이 진행된다.

각각의 function이 architecture에 따라 deploy 되고 Multicast service 에 대한 configuration 이 multicast server, multicast gateway, multicast rendezvous service 에 적용된다.

Provisioning function은 network control을 통해 현재 provisioning 되어 있는 multicast session에 대한 configuration 정보를 multicast server (A) 와 multicast server (B)에 전달한다.

Multicast session이 시작되면, content provider 로부터 multicast server (A) 와 multicast server (B)에 media segment가 ingest 되고, multicast 전송을 시작하며, 해당 media segment를 수신할 수 있는 multicast gateway 가 있으면 수신 가능한 상태가 된다.

Device 가 network A 에 접속하게 되면 다음과 같이 동작할 수 있다.

Application 은 network A를 거쳐 service provider 로부터 service list 를 수신 할 수 있다. Service list 를 수신 하기 위해서 network A 에서 정의 되어 있는 service list 획득 방법이 사용 될 수 있다. 예를 들어, DVB-I network 에서 service directory 가 구성되어 있으면, service provider, service directory, application 사이의 상호 동작을 통해 service list를 수신할 수 있다. ABR multicast 동작을 위해서, service list 에는 service ID 에 mapping 되는 presentation manifest를 요청할 url 이 포함 될 수 있다.

사용자가 수신할 multicast contents를 선택하면, 해당 Application에서 Service directory 등을 통해 최초 presentation manifest 를 요청할 URL을 획득할 수 있다. 이때 URL은 Multicast rendezvous service (A)를 가리킨다.

Application 은 content playback function이 content 수신을 위한 동작을 시작할 수 있도록 제어하며, 이때, Multicast rendezvous service(A) 에 대한 URL을 전달 할 수 있다.

Content playback function은 application으로부터 전달된 URL을 이용하여, reference point B1를 통해 Multicast rendezvous service(A)에 presentation manifest를 요청한다.

Multicast rendezvous service(A)는 동일 network에 구성되어 있는 Multicast gateway(A)의 상태를 체크 하고, 요청된 presentation manifest 에 대한 service가 multicast configuration에 정의 되어 있으면, Multicast gateway(A) 에 대한 redirection URL을 content playback function에 전송한다. 이때 전송되는 redirection message에 업데이트 된 multicast session configuration을 포함시킬 수 있다.

Redirection message를 수신한 content playback function은 해당 redirection을 따라 reference point L1을 통해 Multicast gateway(A)에 presentation manifest를 요청한다.

Multicast gateway(A) 에 미리 presentation manifest 가 cache 되어 있는 경우, 해당 presentation manifest 를 content playback function으로 전송한다.

Content playback function은 수신된 presentation manifest를 바탕으로 해당 contents 에 대한 media segment 를 요청한다.

Multicast streaming 이 multicast server(A) 에서 multicast gateway(A) 로 M1 interface를 통해 전송된다.

Content playback function은 Multicast gateway(A)를 통해 요청한 media segment를 수신할 수 있으며 media가 play 된다. 별도의 control이 없는 경우 media 의 play가 지속된다.

이 상태에서, device 가 network A 에서 network B로 접속을 변경하게 되면 다음과 같이 동작할 수 있다.

Application 은 network B를 거쳐 service provider 로부터 service list 를 수신 할 수 있다. Service list 를 수신 하기 위해서 network B 에서 정의 되어 있는 service list 획득 방법이 사용 될 수 있다. Network A를 통해 수신된 multicast session 을 이어서 수신 하기 위해 해당 service ID 에 대한 session 정보를 교환 할 수 있다. 수신된 service list 에는 service ID 에 mapping 되는 presentation manifest를 요청할 url 이 포함 될 수 있다.

수신중에 있는 service 에 대해, Application에서는 presentation manifest 를 요청할 URL을 획득할 수 있다. 이때 URL은 Multicast gateway(B) 및 rendezvous service (B)를 가리킨다.

사용자가 수신할 multicast contents를 선택하면, 해당 Application에서 Service directory 등을 통해 최초 presentation manifest 를 요청할 URL을 획득할 수 있다. 이때 URL은 Multicast gateway(B) 또는 Multicast rendezvous service (B)를 가리킨다.

Application 은 content playback function이 content 수신을 위한 동작을 시작할 수 있도록 제어하며, 이때, Multicast gateway(B) 또는 Multicast rendezvous service(B) 에 대한 URL을 전달 할 수 있다.

Multicast gateway 와 multicast rendezvous service가 동일한 장치에 구성되어 있으므로 (co-located deployment), 다음 과정은 선택적으로 수행될 수 있다.

Content playback function은 application으로부터 전달된 URL을 이용하여, reference point B2를 통해 Multicast rendezvous service(B)에 presentation manifest를 요청한다.

Multicast rendezvous service(B)는 동일 network에 구성되어 있는 Multicast gateway(B)의 상태를 체크 하고, 요청된 presentation manifest 에 대한 service가 multicast configuration에 정의 되어 있으면, Multicast gateway(B) 에 대한 redirection URL을 content playback function에 전송한다. 이때 전송되는 redirection message에 업데이트 된 multicast session configuration을 포함시킬 수 있다.

Redirection message를 수신한 content playback function은 해당 redirection을 따른다.

획득된 URL을 이용하여, reference point L2을 통해 Multicast gateway(B)에 presentation manifest를 요청한다.

Multicast gateway(B) 에 미리 presentation manifest 가 cache 되어 있는 경우, 해당 presentation manifest 를 content playback function으로 전송한다.

Content playback function은 수신된 presentation manifest를 바탕으로 해당 contents 에 대한 media segment 를 요청한다.

Multicast streaming이 multicast server(B) 에서 multicast gateway(B) 로 M2 interface를 통해 전송된다.

Content playback function은 Multicast gateway(B)를 통해 요청한 media segment를 수신할 수 있으며 media가 play 된다. 별도의 control이 없는 경우 media 의 play가 지속된다.

도17은 실시예들에 따른 Multicast server 및 multicast gateway가 각각의 network 에 구성되어 있는 예시를 나타낸다

다음은 Multicast server 및 multicast gateway가 각각의 network 에 구성되어 있는 경우에 대해서, 모든 multicast rendezvous service가 co-located deployment 로 구성 되어 있는 경우에 대한 실시예를 나타낸 것이다. 실시예들에 따른 시스템은 서비스 프로바이더, 네트워크(들), 디바이스를 포함할 수 있다. 실시예들에 따른 서비스 프로바이더, 네트워크(들), 디바이스의 구성은 도24과 같다. 도24의 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다.

실시예들에 따른 architecture에서는 각각의 network 에 대해서, multicast server, multicast gateway, multicast rendezvous service 가 각각의 network에 접속되어 있는 content playback function에 service를 제공한다. 예를 들어, device 가 위성 방송 network를 통한 셋탑박스에 접속하면서 동시에, 지상파 방송 network를 통한 방송 수신을 하는 경우를 고려할 수 있다. 실시예들에 따른 네트워크 타입이 상이할 수 있다. 둘다 단"??* 네트워크일 수 있다.

Device 내의 content playback function은 두개의 L interface (L1, L2) 및 두개의 B interface (B1, B2)가 구성 될 수 있다. L1 interface 를 통해 multicast gateway(A)를 통해 media streaming 을 수신할 수 있으며, B1 interface를 통해 초기 multicast gateway(A) 에 대한 접속 정보를 수신 할 수 있다. L2 interface 를 통해 multicast gateway(B)를 통해 media streaming 을 수신할 수 있으며, B2 interface를 통해 초기 multicast gateway(B) 에 대한 접속 정보를 수신 할 수 있다. 여기에서, Multicast gateway (B) 와 multicast rendezvous service (B)는 device 내에 구성되어 있으므로, L2, B2 interface는 device 내부 interface 로 대체할 수 있다.

Service discovery interface를 통해 application은 multicast service 의 list 및 해당하는 multicast rendezvous service 에 대한 접속 정보를 획득한다. Service discovery interface는 service provider 와 application 사이에서 별도로 정의된 방법을 따를 수 있다. 또한 각각의 network 는 service discovery interface에 대한 data 의 송수신을 지원 할 수 있다.

도18은 실시예들에 따른 네트워크 변경 흐름도를 나타낸다.

도18의 흐름도는 도1-5, 8-17 등에 도시된 실시예들에 따라 수행될 수 있다. 실시예들을 구성하는 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다.

다음은 실시예들에 따른 architecture에 대해 device가 manifest를 획득하고, multicast media 를 수신 하는 과정에 이어서, network 가 변경된 이후에도 동일한 service를 수신하는 과정에 대한 flow를 나타낸 것이다.

Multicast Server 와 관련한 flow 는 다음과 같이 진행된다.

각각의 function이 architecture에 따라 deploy 되고 Multicast service 에 대한 configuration 이 multicast server, multicast gateway, multicast rendezvous service 에 적용된다.

Provisioning function은 network control을 통해 현재 provisioning 되어 있는 multicast session에 대한 configuration 정보를 multicast server (A) 와 multicast server (B)에 전달한다.

Multicast session이 시작되면, content provider 로부터 multicast server (A) 와 multicast server (B)에 media segment가 ingest 되고, multicast 전송을 시작하며, 해당 media segment를 수신할 수 있는 multicast gateway 가 있으면 수신 가능한 상태가 된다.

Device 가 network A 에 접속하게 되면 다음과 같이 동작할 수 있다.

Application 은 network A를 거쳐 service provider 로부터 service list 를 수신 할 수 있다. Service list 를 수신 하기 위해서 network A 에서 정의 되어 있는 service list 획득 방법이 사용 될 수 있다. 예를 들어, DVB-I network 에서 service directory 가 구성되어 있으면, service provider, service directory, application 사이의 상호 동작을 통해 service list를 수신할 수 있다. ABR multicast 동작을 위해서, service list 에는 service ID 에 mapping 되는 presentation manifest를 요청할 url 이 포함 될 수 있다.

사용자가 수신할 multicast contents를 선택하면, 해당 Application에서 Service directory 등을 통해 최초 presentation manifest 를 요청할 URL을 획득할 수 있다. 이때 URL은 Multicast gateway(A) 또는 Multicast rendezvous service (A)를 가리킨다.

Application 은 content playback function이 content 수신을 위한 동작을 시작할 수 있도록 제어하며, 이때, Multicast gateway(A) 또는 Multicast rendezvous service(A) 에 대한 URL을 전달 할 수 있다.

Multicast gateway 와 multicast rendezvous service가 동일한 장치에 구성되어 있으므로 (co-located deployment), 다음 과정은 선택적으로 수행될 수 있다.

Content playback function은 application으로부터 전달된 URL을 이용하여, reference point B1를 통해 Multicast rendezvous service(A)에 presentation manifest를 요청한다.

Multicast rendezvous service(A)는 동일 network에 구성되어 있는 Multicast gateway(A)의 상태를 체크 하고, 요청된 presentation manifest 에 대한 service가 multicast configuration에 정의 되어 있으면, Multicast gateway(A) 에 대한 redirection URL을 content playback function에 전송한다. 이때 전송되는 redirection message에 업데이트 된 multicast session configuration을 포함시킬 수 있다.

Redirection message를 수신한 content playback function은 해당 redirection을 따른다.

획득된 URL을 이용하여, reference point L1을 통해 Multicast gateway(A)에 presentation manifest를 요청한다.

Multicast gateway(A) 에 미리 presentation manifest 가 cache 되어 있는 경우, 해당 presentation manifest 를 content playback function으로 전송한다.

Content playback function은 수신된 presentation manifest를 바탕으로 해당 contents 에 대한 media segment 를 요청한다.

Multicast streaming 이 multicast server(A) 에서 multicast gateway(A) 로 M1 interface를 통해 전송된다.

Content playback function은 Multicast gateway(A)를 통해 요청한 media segment를 수신할 수 있으며 media가 play 된다. 별도의 control이 없는 경우 media 의 play가 지속된다.

이 상태에서, device 가 network A 에서 network B로 접속을 변경하게 되면 다음과 같이 동작할 수 있다.

Application 은 network B를 거쳐 service provider 로부터 service list 를 수신 할 수 있다. Service list 를 수신 하기 위해서 network B 에서 정의 되어 있는 service list 획득 방법이 사용 될 수 있다. Network A를 통해 수신된 multicast session 을 이어서 수신 하기 위해 해당 service ID 에 대한 session 정보를 교환 할 수 있다. 수신된 service list 에는 service ID 에 mapping 되는 presentation manifest를 요청할 url 이 포함 될 수 있다.

Multicast gateway 와 multicast rendezvous service가 device 내에 구성되어 있으므로 interface L2 및 B2 관련 operation은 선택적으로 수행될 수 있다.

수신중에 있는 service 에 대해, Application에서는 presentation manifest 를 요청할 URL을 획득할 수 있다. 이때 URL은 Multicast rendezvous service (B)를 가리킨다.

Application 은 content playback function이 content 수신을 위한 동작을 시작할 수 있도록 제어하며, 이때, Multicast rendezvous service(B) 에 대한 URL을 전달 할 수 있다.

Content playback function은 application으로부터 전달된 URL을 이용하여, reference point B2를 통해 Multicast rendezvous service(B)에 presentation manifest를 요청한다.

Multicast rendezvous service(B)는 동일 network에 구성되어 있는 Multicast gateway(B)의 상태를 체크 하고, 요청된 presentation manifest 에 대한 service가 multicast configuration에 정의 되어 있으면, Multicast gateway(B) 에 대한 redirection URL을 content playback function에 전송한다. 이때 전송되는 redirection message에 업데이트 된 multicast session configuration을 포함시킬 수 있다.

Redirection message를 수신한 content playback function은 해당 redirection을 따라 reference point L2를 통해 Multicast gateway(B)에 presentation manifest를 요청한다.

Multicast gateway(B) 에 미리 presentation manifest 가 cache 되어 있는 경우, 해당 presentation manifest 를 content playback function으로 전송한다.

Content playback function은 수신된 presentation manifest를 바탕으로 해당 contents 에 대한 media segment 를 요청한다.

Multicast streaming이 multicast server(B) 에서 multicast gateway(B) 로 M2 interface를 통해 전송된다.

Content playback function은 Multicast gateway(B)를 통해 요청한 media segment를 수신할 수 있으며 media가 play 된다. 별도의 control이 없는 경우 media 의 play가 지속된다.

다음은 멀티플 네트워크들에 접속 가능한 실시예들에 따른 멀티캐스트 신호 처리 방법/장치를 더 설명한다. 실시예들에 따른 기술한 network 구조에서, 복수의 network 에 접속하여 동일한 multicast media service를 수신 할 수 있는 device 를 고려할 수 있다. 복수의 network 에 접속하여 동일한 multicast streaming service를 수신 할 수 있는 device에 대한 architecture 및 ABR multicast interface에 대한 실시예에 대해 기술한다.

실시예들에 따른 멀티캐스트 랑데부 서비스는 방송의 부트스트램과 다르다. 네트워크에서 랑데부 플로우는 단말이 네트워크에 접속하고자 할 때 네트워크 최초 어드레스를 단말에 제공하는 과정이다.

랑데부 기능은 실시예들에 따른 네트워크가 수행할 수 있다. 부트스트랩은 단말이 수행하는 것일 수 있다. 랑데부서비스는 어드레스나 URL이 고정되어 있을 수 있다. 수신기가 네트워크 외부에 있을 경우, 단말이 처음 접속 시 미디어 수신을 위해서 접속했으니 미디어를 위한 주소를 단말에 리다이렉션한다. 단말은 리다이렉션 주소를 가지고 실제 미디어를 위한 메니페스트를 받을 수 있다. 멀티캐스트 랑데부 서비스는 미디어 송수신이 멀티캐스트 방식이라서 미디어가 이미 다른 누군가가 보고 있는 미디어라서, 이러한 서비스가 요구된다.

도19는 실시예들에 따른 단일 multicast server 가 복수의 이종 network 에 대해 service 되며, 이에 대한 multicast gateway가 각각의 network 에 구성되어 있는 예시를 나타내다.

다음은 단일 multicast server 가 복수의 이종 network 에 대해 service 되며, 이에 대한 multicast gateway가 각각의 network 에 구성되어 있는 경우에 대해서, 모든 multicast rendezvous service가 regular deployment 로 구성 되어 있는 경우에 대한 실시예를 나타낸 것이다. 실시예들에 따른 시스템은 서비스 프로바이더, 네트워크(들), 디바이스를 포함할 수 있다. 실시예들에 따른 서비스 프로바이더, 네트워크(들), 디바이스의 구성은 도19와 같다. 도19의 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다.

실시예들에 따른 architecture에서는 각각의 network 에 대해서, multicast server, multicast gateway, multicast rendezvous service 가 각각의 network에 접속되어 있는 content playback function에 service를 제공한다. 예를 들어, device 가 ISP network 를 통해 Wi-Fi 에 접속과 동시에, mobile network 에 접속하는 경우를 고려할 수 있다.

Device 내의 content playback function은 두개의 L interface (L1, L2) 및 두개의 B interface (B1, B2)가 구성 될 수 있다. L1 interface 를 통해 multicast gateway(A)를 통해 media streaming 을 수신할 수 있으며, B1 interface를 통해 초기 multicast gateway(A) 에 대한 접속 정보를 수신 할 수 있다. L2 interface 를 통해 multicast gateway(B)를 통해 media streaming 을 수신할 수 있으며, B2 interface를 통해 초기 multicast gateway(B) 에 대한 접속 정보를 수신 할 수 있다.

Service discovery interface를 통해 application은 multicast service 의 list 및 해당하는 multicast rendezvous service 에 대한 접속 정보를 획득한다. Service discovery interface는 service provider 와 application 사이에서 별도로 정의된 방법을 따를 수 있다. 또한 각각의 network 는 service discovery interface에 대한 data 의 송수신을 지원 할 수 있다.

도20은 실시예들에 따른 네트워크 변경 흐름도를 나타낸다.

도20의 흐름도는 도1-5, 8-19 등에 도시된 실시예들에 따라 수행될 수 있다. 실시예들을 구성하는 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다.

다음은 실시예들에 따른 architecture에 대해 device가 manifest를 획득하고, multicast media 를 수신 하는 과정에 이어서, network 가 변경된 이후에도 동일한 service를 수신하는 과정에 대한 flow를 나타낸 것이다.

Multicast Server 와 관련한 flow 는 다음과 같이 진행된다.

각각의 function이 architecture에 따라 deploy 되고 Multicast service 에 대한 configuration 이 multicast server, multicast gateway, multicast rendezvous service 에 적용된다.

Provisioning function은 network control을 통해 현재 provisioning 되어 있는 multicast session에 대한 configuration 정보를 multicast server 에 전달한다.

Multicast session이 시작되면, content provider 로부터 multicast server 에 media segment가 ingest 되고, multicast 전송을 시작하며, 해당 media segment를 수신할 수 있는 multicast gateway 가 있으면 수신 가능한 상태가 된다.

Device 가 network A 에 접속하게 되면 다음과 같이 동작할 수 있다.

Application 은 network A를 거쳐 service provider 로부터 service list 를 수신 할 수 있다. Service list 를 수신 하기 위해서 network A 에서 정의 되어 있는 service list 획득 방법이 사용 될 수 있다. 예를 들어, DVB-I network 에서 service directory 가 구성되어 있으면, service provider, service directory, application 사이의 상호 동작을 통해 service list를 수신할 수 있다. ABR multicast 동작을 위해서, service list 에는 service ID 에 mapping 되는 presentation manifest를 요청할 url 이 포함 될 수 있다.

사용자가 수신할 multicast contents를 선택하면, 해당 Application에서 Service directory 등을 통해 최초 presentation manifest 를 요청할 URL을 획득할 수 있다. 이때 URL은 Multicast rendezvous service (A)를 가리킨다.

Application 은 content playback function이 content 수신을 위한 동작을 시작할 수 있도록 제어하며, 이때, Multicast rendezvous service(A) 에 대한 URL을 전달 할 수 있다.

Content playback function은 application으로부터 전달된 URL을 이용하여, reference point B1를 통해 Multicast rendezvous service(A)에 presentation manifest를 요청한다.

Multicast rendezvous service(A)는 동일 network에 구성되어 있는 Multicast gateway(A)의 상태를 체크 하고, 요청된 presentation manifest 에 대한 service가 multicast configuration에 정의 되어 있으면, Multicast gateway(A) 에 대한 redirection URL을 content playback function에 전송한다. 이때 전송되는 redirection message에 업데이트 된 multicast session configuration을 포함시킬 수 있다.

Redirection message를 수신한 content playback function은 해당 redirection을 따라 reference point L1을 통해 Multicast gateway(A)에 presentation manifest를 요청한다.

Multicast gateway(A) 에 미리 presentation manifest 가 cache 되어 있는 경우, 해당 presentation manifest 를 content playback function으로 전송한다.

Content playback function은 수신된 presentation manifest를 바탕으로 해당 contents 에 대한 media segment 를 요청한다.

Multicast streaming 이 multicast server 에서 multicast gateway(A) 로 M1 interface를 통해 전송된다.

Content playback function은 Multicast gateway(A)를 통해 요청한 media segment를 수신할 수 있으며 media가 play 된다. 별도의 control이 없는 경우 media 의 play가 지속된다.

이 상태에서, device 가 network A 에서 network B로 접속을 변경하게 되면 다음과 같이 동작할 수 있다.

Application 은 network B를 거쳐 service provider 로부터 service list 를 수신 할 수 있다. Service list 를 수신 하기 위해서 network B 에서 정의 되어 있는 service list 획득 방법이 사용 될 수 있다. Network A를 통해 수신된 multicast session 을 이어서 수신 하기 위해 해당 service ID 에 대한 session 정보를 교환 할 수 있다. 수신된 service list 에는 service ID 에 mapping 되는 presentation manifest를 요청할 url 이 포함 될 수 있다.

수신중에 있는 service 에 대해, Application에서는 presentation manifest 를 요청할 URL을 획득할 수 있다. 이때 URL은 Multicast rendezvous service (B)를 가리킨다.

Application 은 content playback function이 content 수신을 위한 동작을 시작할 수 있도록 제어하며, 이때, Multicast rendezvous service(B) 에 대한 URL을 전달 할 수 있다.

Content playback function은 application으로부터 전달된 URL을 이용하여, reference point B2를 통해 Multicast rendezvous service(B)에 presentation manifest를 요청한다.

Multicast rendezvous service(B)는 동일 network에 구성되어 있는 Multicast gateway(B)의 상태를 체크 하고, 요청된 presentation manifest 에 대한 service가 multicast configuration에 정의 되어 있으면, Multicast gateway(B) 에 대한 redirection URL을 content playback function에 전송한다. 이때 전송되는 redirection message에 업데이트 된 multicast session configuration을 포함시킬 수 있다.

Redirection message를 수신한 content playback function은 해당 redirection을 따라 reference point L2를 통해 Multicast gateway(B)에 presentation manifest를 요청한다.

Multicast gateway(B) 에 미리 presentation manifest 가 cache 되어 있는 경우, 해당 presentation manifest 를 content playback function으로 전송한다.

Content playback function은 수신된 presentation manifest를 바탕으로 해당 contents 에 대한 media segment 를 요청한다.

Multicast streaming이 multicast server 에서 multicast gateway(B) 로 M2 interface를 통해 전송된다.

Content playback function은 Multicast gateway(B)를 통해 요청한 media segment를 수신할 수 있으며 media가 play 된다. 별도의 control이 없는 경우 media 의 play가 지속된다.

도21은 실시예들에 따른 단일 multicast server 가 복수의 이종 network 에 대해 service 되며, 이에 대한 multicast gateway가 각각의 network 를 구성하는 예시를 나타낸다.

다음은 단일 multicast server 가 복수의 이종 network 에 대해 service 되며, 이에 대한 multicast gateway가 각각의 network 에 구성되어 있는 경우에 대해서, Multicast rendezvous service가 regular deployment 및 co-located deployment 로 구성 되어 있는 경우에 대한 실시예를 나타낸 것이다. 실시예들에 따른 시스템은 서비스 프로바이더, 네트워크(들), 디바이스를 포함할 수 있다. 실시예들에 따른 서비스 프로바이더, 네트워크(들), 디바이스의 구성은 도21와 같다. 도21의 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다.

실시예들에 따른 architecture에서는 각각의 network 에 대해서, multicast server, multicast gateway, multicast rendezvous service 가 각각의 network에 접속되어 있는 content playback function에 service를 제공한다. 예를 들어, device 가 ISP network 를 통해 Wi-Fi 에 접속과 동시에, 위성 방송 network를 통한 셋탑박스에 접속하는 경우를 고려할 수 있다.

Device 내의 content playback function은 두개의 L interface (L1, L2) 및 두개의 B interface (B1, B2)가 구성 될 수 있다. L1 interface 를 통해 multicast gateway(A)를 통해 media streaming 을 수신할 수 있으며, B1 interface를 통해 초기 multicast gateway(A) 에 대한 접속 정보를 수신 할 수 있다. L2 interface 를 통해 multicast gateway(B)를 통해 media streaming 을 수신할 수 있으며, B2 interface를 통해 초기 multicast gateway(B) 에 대한 접속 정보를 수신 할 수 있다.

Service discovery interface를 통해 application은 multicast service 의 list 및 해당하는 multicast rendezvous service 에 대한 접속 정보를 획득한다. Service discovery interface는 service provider 와 application 사이에서 별도로 정의된 방법을 따를 수 있다. 또한 각각의 network 는 service discovery interface에 대한 data 의 송수신을 지원 할 수 있다.

도22는 실시예들에 따른 네트워크 변경 흐름도를 나타낸다.

도22의 흐름도는 도1-5, 8-21 등에 도시된 실시예들에 따라 수행될 수 있다. 실시예들을 구성하는 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다.

다음은 실시예들에 따른 architecture에 대해 device가 manifest를 획득하고, multicast media 를 수신 하는 과정에 이어서, network 가 변경된 이후에도 동일한 service를 수신하는 과정에 대한 flow를 나타낸 것이다.

Multicast Server 와 관련한 flow 는 다음과 같이 진행된다.

각각의 function이 architecture에 따라 deploy 되고 Multicast service 에 대한 configuration 이 multicast server, multicast gateway, multicast rendezvous service 에 적용된다.

Provisioning function은 network control을 통해 현재 provisioning 되어 있는 multicast session에 대한 configuration 정보를 multicast server 에 전달한다.

Multicast session이 시작되면, content provider 로부터 multicast server에 media segment가 ingest 되고, multicast 전송을 시작하며, 해당 media segment를 수신할 수 있는 multicast gateway 가 있으면 수신 가능한 상태가 된다.

Device 가 network A 에 접속하게 되면 다음과 같이 동작할 수 있다.

Application 은 network A를 거쳐 service provider 로부터 service list 를 수신 할 수 있다. Service list 를 수신 하기 위해서 network A 에서 정의 되어 있는 service list 획득 방법이 사용 될 수 있다. 예를 들어, DVB-I network 에서 service directory 가 구성되어 있으면, service provider, service directory, application 사이의 상호 동작을 통해 service list를 수신할 수 있다. ABR multicast 동작을 위해서, service list 에는 service ID 에 mapping 되는 presentation manifest를 요청할 url 이 포함 될 수 있다.

사용자가 수신할 multicast contents를 선택하면, 해당 Application에서 Service directory 등을 통해 최초 presentation manifest 를 요청할 URL을 획득할 수 있다. 이때 URL은 Multicast rendezvous service (A)를 가리킨다.

Application 은 content playback function이 content 수신을 위한 동작을 시작할 수 있도록 제어하며, 이때, Multicast rendezvous service(A) 에 대한 URL을 전달 할 수 있다.

Content playback function은 application으로부터 전달된 URL을 이용하여, reference point B1를 통해 Multicast rendezvous service(A)에 presentation manifest를 요청한다.

Multicast rendezvous service(A)는 동일 network에 구성되어 있는 Multicast gateway(A)의 상태를 체크 하고, 요청된 presentation manifest 에 대한 service가 multicast configuration에 정의 되어 있으면, Multicast gateway(A) 에 대한 redirection URL을 content playback function에 전송한다. 이때 전송되는 redirection message에 업데이트 된 multicast session configuration을 포함시킬 수 있다.

Redirection message를 수신한 content playback function은 해당 redirection을 따라 reference point L1을 통해 Multicast gateway(A)에 presentation manifest를 요청한다.

Multicast gateway(A) 에 미리 presentation manifest 가 cache 되어 있는 경우, 해당 presentation manifest 를 content playback function으로 전송한다.

Content playback function은 수신된 presentation manifest를 바탕으로 해당 contents 에 대한 media segment 를 요청한다.

Multicast streaming 이 multicast server 에서 multicast gateway(A) 로 M1 interface를 통해 전송된다.

Content playback function은 Multicast gateway(A)를 통해 요청한 media segment를 수신할 수 있으며 media가 play 된다. 별도의 control이 없는 경우 media 의 play가 지속된다.

이 상태에서, device 가 network A 에서 network B로 접속을 변경하게 되면 다음과 같이 동작할 수 있다.

Application 은 network B를 거쳐 service provider 로부터 service list 를 수신 할 수 있다. Service list 를 수신 하기 위해서 network B 에서 정의 되어 있는 service list 획득 방법이 사용 될 수 있다. Network A를 통해 수신된 multicast session 을 이어서 수신 하기 위해 해당 service ID 에 대한 session 정보를 교환 할 수 있다. 수신된 service list 에는 service ID 에 mapping 되는 presentation manifest를 요청할 url 이 포함 될 수 있다.

수신중에 있는 service 에 대해, Application에서는 presentation manifest 를 요청할 URL을 획득할 수 있다. 이때 URL은 Multicast gateway(B) 및 rendezvous service (B)를 가리킨다.

사용자가 수신할 multicast contents를 선택하면, 해당 Application에서 Service directory 등을 통해 최초 presentation manifest 를 요청할 URL을 획득할 수 있다. 이때 URL은 Multicast gateway(B) 또는 Multicast rendezvous service (B)를 가리킨다.

Application 은 content playback function이 content 수신을 위한 동작을 시작할 수 있도록 제어하며, 이때, Multicast gateway(B) 또는 Multicast rendezvous service(B) 에 대한 URL을 전달 할 수 있다.

Multicast gateway 와 multicast rendezvous service가 동일한 장치에 구성되어 있으므로 (co-located deployment), 다음 과정은 선택적으로 수행될 수 있다.

Content playback function은 application으로부터 전달된 URL을 이용하여, reference point B2를 통해 Multicast rendezvous service(B)에 presentation manifest를 요청한다.

Multicast rendezvous service(B)는 동일 network에 구성되어 있는 Multicast gateway(B)의 상태를 체크 하고, 요청된 presentation manifest 에 대한 service가 multicast configuration에 정의 되어 있으면, Multicast gateway(B) 에 대한 redirection URL을 content playback function에 전송한다. 이때 전송되는 redirection message에 업데이트 된 multicast session configuration을 포함시킬 수 있다.

Redirection message를 수신한 content playback function은 해당 redirection을 따른다.

획득된 URL을 이용하여, reference point L2을 통해 Multicast gateway(B)에 presentation manifest를 요청한다.

Multicast gateway(B) 에 미리 presentation manifest 가 cache 되어 있는 경우, 해당 presentation manifest 를 content playback function으로 전송한다.

Content playback function은 수신된 presentation manifest를 바탕으로 해당 contents 에 대한 media segment 를 요청한다.

Multicast streaming이 multicast server 에서 multicast gateway(B) 로 M2 interface를 통해 전송된다.

Content playback function은 Multicast gateway(B)를 통해 요청한 media segment를 수신할 수 있으며 media가 play 된다. 별도의 control이 없는 경우 media 의 play가 지속된다.

도23은 실시예들에 따른 Multicast server 및 multicast gateway가 각각의 network 에 구성되어 있는 경우, 모든 multicast rendezvous service가 co-located deployment 로 구성되는 예시를 나타내다.

다음은 Multicast server 및 multicast gateway가 각각의 network 에 구성되어 있는 경우에 대해서, 모든 multicast rendezvous service가 co-located deployment 로 구성 되어 있는 경우에 대한 실시예를 나타낸 것이다. 실시예들에 따른 시스템은 서비스 프로바이더, 네트워크(들), 디바이스를 포함할 수 있다. 실시예들에 따른 서비스 프로바이더, 네트워크(들), 디바이스의 구성은 도36과 같다. 도36의 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다. 서버가 네트워크의 외부에 위치할 수 있다.

실시예들에 따른 architecture에서는 각각의 network 에 대해서, multicast server, multicast gateway, multicast rendezvous service 가 각각의 network에 접속되어 있는 content playback function에 service를 제공한다. 예를 들어, device 가 위성 방송 network를 통한 셋탑박스에 접속하면서 동시에, 지상파 방송 network를 통한 방송 수신을 하는 경우를 고려할 수 있다.

Device 내의 content playback function은 두개의 L interface (L1, L2) 및 두개의 B interface (B1, B2)가 구성 될 수 있다. L1 interface 를 통해 multicast gateway(A)를 통해 media streaming 을 수신할 수 있으며, B1 interface를 통해 초기 multicast gateway(A) 에 대한 접속 정보를 수신 할 수 있다. L2 interface 를 통해 multicast gateway(B)를 통해 media streaming 을 수신할 수 있으며, B2 interface를 통해 초기 multicast gateway(B) 에 대한 접속 정보를 수신 할 수 있다. 여기에서, Multicast gateway (B) 와 multicast rendezvous service (B)는 device 내에 구성되어 있으므로, L2, B2 interface는 device 내부 interface 로 대체할 수 있다.

Service discovery interface를 통해 application은 multicast service 의 list 및 해당하는 multicast rendezvous service 에 대한 접속 정보를 획득한다. Service discovery interface는 service provider 와 application 사이에서 별도로 정의된 방법을 따를 수 있다. 또한 각각의 network 는 service discovery interface에 대한 data 의 송수신을 지원 할 수 있다.

도24는 실시예들에 따른 네트워크 변경 흐름도를 나타낸다.

도24의 흐름도는 도1-5, 8-23 등에 도시된 실시예들에 따라 수행될 수 있다. 실시예들을 구성하는 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다.

다음은 실시예들에 따른 architecture에 대해 device가 manifest를 획득하고, multicast media 를 수신 하는 과정에 이어서, network 가 변경된 이후에도 동일한 service를 수신하는 과정에 대한 flow를 나타낸 것이다.

Multicast Server 와 관련한 flow 는 다음과 같이 진행된다.

각각의 function이 architecture에 따라 deploy 되고 Multicast service 에 대한 configuration 이 multicast server, multicast gateway, multicast rendezvous service 에 적용된다.

Provisioning function은 network control을 통해 현재 provisioning 되어 있는 multicast session에 대한 configuration 정보를 multicast server에 전달한다.

Multicast session이 시작되면, content provider 로부터 multicast server에 media segment가 ingest 되고, multicast 전송을 시작하며, 해당 media segment를 수신할 수 있는 multicast gateway 가 있으면 수신 가능한 상태가 된다.

Device 가 network A 에 접속하게 되면 다음과 같이 동작할 수 있다.

Application 은 network A를 거쳐 service provider 로부터 service list 를 수신 할 수 있다. Service list 를 수신 하기 위해서 network A 에서 정의 되어 있는 service list 획득 방법이 사용 될 수 있다. 예를 들어, DVB-I network 에서 service directory 가 구성되어 있으면, service provider, service directory, application 사이의 상호 동작을 통해 service list를 수신할 수 있다. ABR multicast 동작을 위해서, service list 에는 service ID 에 mapping 되는 presentation manifest를 요청할 url 이 포함 될 수 있다.

사용자가 수신할 multicast contents를 선택하면, 해당 Application에서 Service directory 등을 통해 최초 presentation manifest 를 요청할 URL을 획득할 수 있다. 이때 URL은 Multicast gateway(A) 또는 Multicast rendezvous service (A)를 가리킨다.

Application 은 content playback function이 content 수신을 위한 동작을 시작할 수 있도록 제어하며, 이때, Multicast gateway(A) 또는 Multicast rendezvous service(A) 에 대한 URL을 전달 할 수 있다.

Multicast gateway 와 multicast rendezvous service가 동일한 장치에 구성되어 있으므로 (co-located deployment), 다음 과정은 선택적으로 수행될 수 있다.

Content playback function은 application으로부터 전달된 URL을 이용하여, reference point B1를 통해 Multicast rendezvous service(A)에 presentation manifest를 요청한다.

Multicast rendezvous service(A)는 동일 network에 구성되어 있는 Multicast gateway(A)의 상태를 체크 하고, 요청된 presentation manifest 에 대한 service가 multicast configuration에 정의 되어 있으면, Multicast gateway(A) 에 대한 redirection URL을 content playback function에 전송한다. 이때 전송되는 redirection message에 업데이트 된 multicast session configuration을 포함시킬 수 있다.

Redirection message를 수신한 content playback function은 해당 redirection을 따른다.

획득된 URL을 이용하여, reference point L1을 통해 Multicast gateway(A)에 presentation manifest를 요청한다.

Multicast gateway(A) 에 미리 presentation manifest 가 cache 되어 있는 경우, 해당 presentation manifest 를 content playback function으로 전송한다.

Content playback function은 수신된 presentation manifest를 바탕으로 해당 contents 에 대한 media segment 를 요청한다.

Multicast streaming 이 multicast server 에서 multicast gateway(A) 로 M1 interface를 통해 전송된다.

Content playback function은 Multicast gateway(A)를 통해 요청한 media segment를 수신할 수 있으며 media가 play 된다. 별도의 control이 없는 경우 media 의 play가 지속된다.

이 상태에서, device 가 network A 에서 network B로 접속을 변경하게 되면 다음과 같이 동작할 수 있다.

Application 은 network B를 거쳐 service provider 로부터 service list 를 수신 할 수 있다. Service list 를 수신 하기 위해서 network B 에서 정의 되어 있는 service list 획득 방법이 사용 될 수 있다. Network A를 통해 수신된 multicast session 을 이어서 수신 하기 위해 해당 service ID 에 대한 session 정보를 교환 할 수 있다. 수신된 service list 에는 service ID 에 mapping 되는 presentation manifest를 요청할 url 이 포함 될 수 있다.

Multicast gateway 와 multicast rendezvous service가 device 내에 구성되어 있으므로 interface L2 및 B2 관련 operation은 선택적으로 수행될 수 있다.

수신중에 있는 service 에 대해, Application에서는 presentation manifest 를 요청할 URL을 획득할 수 있다. 이때 URL은 Multicast rendezvous service (B)를 가리킨다.

Application 은 content playback function이 content 수신을 위한 동작을 시작할 수 있도록 제어하며, 이때, Multicast rendezvous service(B) 에 대한 URL을 전달 할 수 있다.

Content playback function은 application으로부터 전달된 URL을 이용하여, reference point B2를 통해 Multicast rendezvous service(B)에 presentation manifest를 요청한다.

Multicast rendezvous service(B)는 동일 network에 구성되어 있는 Multicast gateway(B)의 상태를 체크 하고, 요청된 presentation manifest 에 대한 service가 multicast configuration에 정의 되어 있으면, Multicast gateway(B) 에 대한 redirection URL을 content playback function에 전송한다. 이때 전송되는 redirection message에 업데이트 된 multicast session configuration을 포함시킬 수 있다.

Redirection message를 수신한 content playback function은 해당 redirection을 따라 reference point L2를 통해 Multicast gateway(B)에 presentation manifest를 요청한다.

Multicast gateway(B) 에 미리 presentation manifest 가 cache 되어 있는 경우, 해당 presentation manifest 를 content playback function으로 전송한다.

Content playback function은 수신된 presentation manifest를 바탕으로 해당 contents 에 대한 media segment 를 요청한다.

Multicast streaming이 multicast server 에서 multicast gateway(B) 로 M2 interface를 통해 전송된다.

Content playback function은 Multicast gateway(B)를 통해 요청한 media segment를 수신할 수 있으며 media가 play 된다. 별도의 control이 없는 경우 media 의 play가 지속된다.

다음은 멀티플 네트워크들에 접속 가능한 실시예들에 따른 멀티캐스트 신호 처리 방법/장치를 더 설명한다.

각 네트워크 상에서 멀티캐스트 서버가 위치할 수 있다.

도25는 실시예들에 따른 Multicast server 및 multicast gateway가 각각의 network 에 구성되어 있는 경우에 대해서, device 가 service 가능한 다양한 network에 접속하는 실시예를 나타낸다.

실시예들을 구성하는 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다.

다음은 앞서 기술한 바와 같이, 앞서 기술한 내용을 바탕으로, Multicast server 및 multicast gateway가 각각의 network 에 구성되어 있는 경우에 대해서, device 가 service 가능한 다양한 network에 접속하는 경우에 대한 실시예를 나타낸다. 실시예들에 따른 시스템은 서비스 프로바이더, 네트워크(들), 디바이스를 포함할 수 있다. 실시예들에 따른 서비스 프로바이더, 네트워크(들), 디바이스의 구성은 후술하는 바와 같다.

도26은 실시예들에 따른 단일 multicast server 가 복수의 이종 network 에 대해 service 제공하며, 이에 대한 multicast gateway가 각각의 network 에 구성되는 구조를 나타낸다.

다음은 앞서 기술한 바와 같이, 단일 multicast server 가 복수의 이종 network 에 대해 service 되며, 이에 대한 multicast gateway가 각각의 network 에 구성되어 있는 경우에 대해서, device 가 service 가능한 다양한 network에 접속하는 경우에 대한 실시예를 나타낸다. 실시예들에 따른 시스템은 서비스 프로바이더, 네트워크(들), 디바이스를 포함할 수 있다. 실시예들에 따른 서비스 프로바이더, 네트워크(들), 디바이스의 구성은 다음과 같다.

실시예들을 구성하는 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다.

실시예들에 따른 송수신 장치는 실시예들에 따른 동작에 기반하여, DVB Multicast ABR 및 5G media streaming 를 다양한 네트워크 환경에서 효율적으로 제어하고, 제공할 수 있는 효과가 있다.

다음은 실시예들에 따른 수신 동작 및 수신 장치를 위한 동작을 설명한다.

전술한 실시예들에 따른 아키텍쳐들에 대하 다음과 같은 프로토콜이 구현될 수 있다..

실시예들에 따른 기술된 architecture 를 바탕으로, 복수의 전송 network 에 접속 하여 ABR multicast streaming을 수 있는 device를 위해 필요한 element 및 attribute 를 정의 한다.

실시예들에 따른 수신기는 송신기의 동작을 역과정을 수행할 수 있다. 실시예들에 따른 수신기는 이하의 동작에 기반하여 ABR multicast streaming을 수행할 수 있다. 실시예들에 따른 수신기는 이하의 네트워크 구조에 기반하여, ABR multicast streaming을 수행할 수 있다.

다음은 수신 장치들 내 프로토콜 스택들 예시이다.

도27은 실시예들에 따른 ABR 멀티캐스트를 위한 프로토콜 구성을 나타낸다.

Multicast ABR 전송을 위해 multicast server에서 M interface를 통해 multicast streaming을 전송 할 수 있다. 이때, multicast 전송 protocol로 ROUTE 또는 FLUTE를 사용할 수 있다. Multicast gateway는 playback function에 L interface를 통해 HTTP 기반의 adaptive media streaming을 위해 DASH 또는 HLS 를 사용 할 수 있다. Playback function 에는 multicast gateway로부터 HTTP 기반의 adaptive media streaming 수신을 위한 protocol 과, 수신된 adaptive streaming 에 대한 file format 과 media coded 이 구성될 수 있다. 여기에서, Layer 1 및 Layer 2 protocol은 각각의 network에 최적의 protocol로 구성될 수 있다.

복수의 네트워크들에 접속하기 위해서 실시예들은 다음과 같은 프로토콜들을 포함할 수 있다.

도28은 실시예들에 따른 복수의 network에 접속하기 위해 수신 장치에 구성될 수 있는 protocol 에 대한 실시 예를 나타낸다.

실시예들에 따른 멀티캐스트 신호 처리 장치가 수신 장치로 구현될 때, 전술한 실시예들에 따른 아키텍쳐들 상 구현되는 프로토콜을 나타낸다.

실시예들에 따른, network A 에는 multicast gateway 가 network 에 구성되어 있고, network B에 대해서는 multicast gateway가 device 내에 구성되어 있는 경우를 고려 한다.

실시예들에 따른, network A를 통해 ABR multicast streaming을 서비스 하기 위해 network상에 구성되어 있는 multicast gateway 는 multicast server로부터 multicast streaming을 수신하고 이를 L interface를 통해 HTTP 기반의 adaptive media streaming 방식으로 device로 전송한다. 따라서, device 에서는 L interface를 통해 adaptive media streaming을 수신할 수 있는 protocol stack이 구성될 수 있다.

또한, network B를 통해 ABR multicast streaming을 수신하기 위해서는 device 내에 multicast gateway가 구성되는 것을 고려할 수 있다. 따라서, device 에서는 network B 에 대한 M interface를 통해 adaptive media streaming을 수신할 수 있는 protocol stack이 구성될 수 있다.

따라서, 복수의 network 에 접속하여 ABR multicast 서비스를 수신 하기 위한 수신기 device 내에는 M interface 및 L interface에 대한 protocol이 동시에 구성될 수 있다. 이때, device 내의 multicast gateway function은 network 상에 구성되어 있는 multicast gateway와 동일한 방식으로, multicast streaming 을 HTTP 기반의 adaptive media streaming 으로 전환하여 device 내의 L interface로 전달할 수 있다.

도28은 실시예들에 따른 프로토콜을 나타낸다.

실시예들에 따른 멀티캐스트 신호 처리 장치가 수신 장치로 구현될 때, 전술한 실시예들에 따른 아키텍쳐들 상 구현되는 프로토콜을 나타낸다.

실시예들에 따른, network A 에는 multicast gateway 가 network 에 구성되어 있고, network B에 대해서는 multicast gateway가 device 내에 구성되어 있는 경우를 고려 한다.

실시예들에 따른, network A를 통해 ABR multicast streaming을 서비스 하기 위해 network상에 구성되어 있는 multicast gateway 는 multicast server로부터 multicast streaming을 수신하고 이를 L interface를 통해 HTTP 기반의 adaptive media streaming 방식으로 device로 전송한다. 따라서, device 에서는 L interface를 통해 adaptive media streaming을 수신할 수 있는 protocol stack이 구성될 수 있다.

또한, network B를 통해 ABR multicast streaming을 수신하기 위해서는 device 내에 multicast gateway가 구성되는 것을 고려할 수 있다. 따라서, device 에서는 network B 에 대한 M interface를 통해 adaptive media streaming을 수신할 수 있는 protocol stack이 구성될 수 있다.

따라서, 복수의 network 에 접속하여 ABR multicast 서비스를 수신 하기 위한 수신기 device 내에는 M interface 및 L interface에 대한 protocol이 동시에 구성될 수 있다. 이때, device 내의 multicast gateway function은 network 상에 구성되어 있는 multicast gateway와 동일한 방식으로, multicast streaming 을 HTTP 기반의 adaptive media streaming 으로 전환하여 device 내의 L interface로 전달할 수 있다.

도29는 실시예들에 따른 프로토콜을 나타낸다.

실시예에서, network A 에는 multicast gateway 가 network 에 구성되어 있고, network B에 대해서는 multicast gateway가 device 내에 구성되어 있는 경우를 고려 한다.

실시예에서, network A를 통해 ABR multicast streaming을 서비스 하기 위해 network상에 구성되어 있는 multicast gateway 는 multicast server로부터 multicast streaming을 수신하고 이를 L interface를 통해 HTTP 기반의 adaptive media streaming 방식으로 device로 전송한다. 따라서, device 에서는 L interface를 통해 adaptive media streaming을 수신할 수 있는 protocol stack이 구성될 수 있다.

또한, network B를 통해 ABR multicast streaming을 수신하기 위해서는 device 내에 multicast gateway가 구성되는 것을 고려할 수 있다. 따라서, device 에서는 network B 에 대한 M interface를 통해 adaptive media streaming을 수신할 수 있는 protocol stack이 구성될 수 있다.

따라서, 복수의 network 에 접속하여 ABR multicast 서비스를 수신 하기 위한 수신기 device 내에는 M interface 및 L interface에 대한 protocol이 동시에 구성될 수 있다. 이때, device 내의 multicast gateway function은 network 상에 구성되어 있는 multicast gateway와는 달리, device 내에서 L interface 가 구성될 수 있으며, 이때의 L interface는 별도의 interface 없이, 직접 protocol stack으로 구성할 수 있다. Device에서는 network A를 통해 수신되는 streaming 의 경우, playback function으로 동작하고, network B를 통해 수신되는 streaming 의 경우 multicast gateway로 동작 할 수 있다. Multicast gateway로 동작하는 경우에는 L interface 가 생략되고, multicast protocol의 payload가 adaptive media streaming data 가 될 수 있다.

다음음 실시예들에 따른 서비스 리스트 및 프리젠테이션 마니페스트를 생성하고 송수신하는 동작을 설명한다.

도30은 실시예들에 따른 서비스 및 서비스에 관한 정보의 구성을 나타낸다.

DASH 기반의 ABR multicast service 에 대해서, 실시예들에 따른 서비스 프로바이더(service provider )는 service list와 함께, 다음과 같이 presentation manifest (ex. MPD)를 구성할 수 있다. Service 를 제공하는 측면에서는 동일한 contents 에 대한 service list 및 presentation manifest 에 대해서는 중복되지 않도록 구성될 수 있다.

도31은 실시예들에 따른 ABR 멀티캐스트를 위한 서비스 리스트 및 프리젠테이션 마니페스를 생성하고, 전송하는 방법을 나타낸다.

실시예들에 따른 멀티캐스트 신호 처리 방법/장치는 ABR 멀티캐스트를 지원하기 위해서, 도31과 같이 서비스 리스트 및 프리젠테이션 마니페스를 생성하고, 송수신할 수 있다.

ABR Multicast architecture에 정의 되어 있는 interface 에 따라 전송할 수 있는 element 가 결정될 수 있다. 수신기 device의 application은 service list directory 로부터 service list를 수신받을 수 있으며, service id 와 multicast rendezvous service에 대한 url을 포함할 수 있다. 해당 url을 통해 content playback function이 multicast rendezvous service에 manifest를 요청하면, multicast rendezvous service의 redirection message를 통해 multicast gateway 의 address 및 해당 manifest 에 대한 path를 획득하여, L interface를 통해 presentation manifest를 수신 할 수 있다. Multicast gateway는 multicast server로부터 해당 presentation manifest (ex. MPD)를 수신할 수 있으며, 이를 위해 multicast session configuration 정보를 획득할 수 있다.

도32는 실시예들에 따른 service list 및 presentation manifest 관리를 나타낸다.

실시예들에 따른 수신 장치에서 도32와 같이 service list 및 presentation manifest 를 관리할 수 있다. 실시예들에 따른 구조로 구성된 service list 및 presentation manifest (ex. MPD) 에 대해서, 복수의 network 를 통해 ABR multicast 서비스를 수신할 수 있는 수신기 내에는 다음과 같이 service list 가 관리 될 수 있다.

즉, 동일한 서비스에 대해서 네트워크 1 및 네트워크2와 같은 멀티플 네트워크들에 대한 MPD를 생성하고 송수신할 수 있다.

실시예에서, 복수의 network 를 이용하여 ABR multicast service 수신하는 device에서 각각의 network 에서 제공되는 adaptation set이 상이할 수 있으므로, network에 따라 별도로 presentation manifest를 구성하여 관리한다.

ABR multicast service 수신 function이 TV 등에서 구성되고 해당 수신기에 방송 contents 도 동시에 수신될 때, 실시예들에 따른 service list는 channel map 과 같이 관리 될 수 있다.

도33은 실시예들에 따른 서비스 리스트를 나타낸다.

도33은 실시예들에 따른 서비스 리스트의 신택스를 나타낸다.

서비스 리스트(ServiceList) - service 에 대한 구성정보를 포함하는 root element이다.

서비스 식별자(@serviceIdentifier) - service 를 식별할 수 있는 식별자이다.

프리젠테이션 마니페스트 요청 주소(PresentationManifestRequestURL)- 하나의 service에 대해서 복수의 멀티캐스트 랑데부 서비스(multicast rendezvous service)를 통해 configuration 될 때, multicast rendezvous service 에 대한 정보를 위한 element이다.

네트워크 타입(@NetworkType)- Multicast rendezvous service가 위치한 network type이다. device가 network에 동시에 접속하였을 때, 우선순위 설정에 사용할 수 있다.

호스트 주소(@HostAddress)- 해당하는 multicast rendezvous service의 address이다.

랑데부 서비스 타입(@RendezvousServerType)- multicast rendezvous service의 deployment 에 대한 attribute이다. 예를 들어, 0: regular deployment(보통 배치), 1: co-located deployment(함께 배치)

멀티캐스트 트랜스포트 세션(MulticastTransportSession)- multicast transport session 에 대한 element는 device 가 multicast gateway를 포함하는 경우에 optional 로 전송할 수 있다. MulticastTransportSession element 를 보내지 않는 경우에는 multicast gateway configuration을 통해 정보를 제공할 수 있다.

도34는 실시예들에 따른 멀티캐스트 세션을 나타낸다.

다음은 multicast session element의 구성에 대한 실시예를 나타낸다. Multicast session element는 provisioning function으로부터 multicast server 및 multicast gateway로 전송된다. 따라서 각각 CMS 및 CMR interface가 사용될 수 있다. Network가 unidirectional 전송만 지원 하는 경우, CMS interface를 통해 multicast server로 전달된 후, M interface를 통해 multicast server 로부터 multicast gateway로 전달될 수 있다.

@serviceIdentifier: 이 세션이 연결된 논리 서비스의 서비스 식별자이다.

@contentPlaybackAvailabilityOffset : Duration string 콘텐츠 재생 기능의 인스턴스에 전달될 때 원래 프레젠테이션 매니페스트에 적용되는 가용성 시간 오프셋 조정이다.

@networkIdentifier: 현재 멀티캐스트 세션이 전송되는 네트워크의 식별자이다.

PresentationManifestLocator: 선형 서비스에 대한 프레젠테이션 매니페스트의 URL이다.

@manifestId: 멀티캐스트 세션 범위 내에서 이 프레젠테이션 매니페스트를 고유하게 식별한다.

@contentType: 이 프레젠테이션 매니페스트의 MIME 콘텐츠 유형이다.

MulticastTransportSession: 멀티캐스트 전송 세션 매개변수용 컨테이너이다.

@networkIdentifier - 현재의 multicast session이 서비스 되고 있는 network 에 대한 식별자. 수신기에서 동일한 multicast service가 수신되는 network를 식별할 수 있다.

실시예들에 따른 마니페스트 요청 및 리다이렉션 동작(Manifest request and redirection)

위와 같은 architecture에서, content playback function이 Multicast rendezvous service에 보내는 HTTP message의 Request URL의 syntax는 다음과 같다.

http[s]://<Host>/<ManifestPath>[?<field>=<value>[&<field>=<value>]*]

실시예들에 따른 URL에 포함되는 element들은 도35와 같다.

도35는 실시예들에 따른 HTTP message의 Request URL에 포함되는 엘리먼트를 나타낸다.

Host: FQDN(또는 IP 주소) 및 선택적으로 멀티캐스트 랑데뷰 서비스의 포트 번호이다.

ManifestPath: 지정된 호스트에서 프레젠테이션 매니페스트를 검색하기 위한 리소스 경로이다.

AToken: 값은 시스템 운영자가 요구하는 경우 멀티캐스트 랑데뷰 서비스에 대한 액세스를 승인하는 인증 토큰이다. 이것은 원래의 프리젠테이션 매니페스트 URL에 포함되었을 수도 있고, 이전 HTTP 리디렉션 URL의 일부로 타사 CDN 브로커에 의해 추가되었을 수도 있고, 애플리케이션에 의해 로컬로 생성되었을 수도 있다.

Priority: 다중 네트워크 구축 시 프레젠테이션 검색 우선 순위이다.

MGstatus: 값은 멀티캐스트 게이트웨이의 현재 상태이다. 예를 들어, 0 = inactive, 1 = active

MGid: 값은 멀티캐스트 게이트웨이의 포트 번호이며 선택적으로 IP 주소가 앞에 온다. 포맷은 다음과 같다: [IP address]:port.

MGhost: 값은 멀티캐스트 게이트웨이 호스트 이름이다.

Ori: 값은 원래 대상 호스트의 호스트 이름(FQDN)이다.

응용 프로그램은 원래 대상 호스트 이름(FQDN)을 로컬 멀티캐스트 랑데뷰 서비스 호스트 이름 또는 주소로 대체할 수 있다. 또한 타사 CDN 브로커에 의존하는 경우 후자는 멀티캐스트 랑데뷰 서비스로 요청을 리디렉션하기 전에 원래 대상 호스트 이름(FQDN)을 여기에서 나타낸다.

Priority - Playback function 이 multicast rendezvous service 에 manifest를 요청할 때, 해당 multicast rendezvous service가 복수의 multicast gateway로 redirection하는 것이 가능 할 때, 각각의 multicast gateway가 구성되어 있는 network에 차등적인 priority 를 부여하여, multicast 수신의 우선 순위를 결정 할 수 있다.

Multicast rendezvous service 는 실시예들에 따른 request URL 을 수신 하면, 307 Temporary Redirect 응답을 보낼 수 있다. 여기에서, Location response header 의 Redirect URL 의 syntax는 다음과 같다.

http[s]://<Host>[/session ID]/<ManifestPath>[?conf=<multicast session

실시예들에 따른 URL에 포함되는 element들은 다음과 같다.

도36은 실시예들에 따른 Location response header 의 Redirect URL 에 포함되는 정보를 나타낸다.

Host: 멀티캐스트 게이트웨이의 IP 주소 또는 FQDN 및 선택적으로 포트 번호(예: "router.example:8088" 또는 "192.0.2.1:8088")일 수 있다.

Session ID: 하나 이상의 URL 경로 요소를 포함하는 멀티캐스트 랑데뷰 서비스에 의해 전달되고 생성될 수 있는 고유한 프레젠테이션 세션 식별자이다.

ManifestPath: 지정된 호스트에서 프레젠테이션 매니페스트를 검색하기 위한 리소스 경로이다.

RequestedPriority : 콘텐츠 재생에서 요청된 우선 순위 값이다.

conf: 멀티캐스트 세션 매개변수는 하나의 멀티캐스트 세션을 포함하는 멀티캐스트 게이트웨이 구성 인스턴스 문서의 형식을 취할 수 있다..

문서는 URL 쿼리 문자열 매개변수로 포함되기 전에 Gzip 및 base64url 인코딩을 사용하여 압축될 수 있다.

RequestedPriority - Playback function 이 multicast rendezvous service 에 manifest를 요청할 때, 복수의 multicast gateway에 대한 priority가 설정 되어 있는 경우, redirection 전송시 요청시 전송되었던 priority를 되돌려 줄 수 있다. Multicast rendezvouse service 는 redirection 가능한 가장 상위 값의 priority를 가지는 multicast gateway로 redirection 해 줄수 있다.

이때, presentation manifest 가 multicast session configuration내의 multicast session 과 관련된 것이면 (service를 multicast로 전송 가능), Multicast rendezvous service는 다음과 같이 request를 Multicast gateway로 redirection 할 수 있다.

HTTP/1.1 307 Temporary Redirect

Server: <Multicast gateway>

Location: http[s]://<Multicast gateway>/<ManifestPath>[?<requestedPriority]*

HTTP header의 Location field 에 해당 하는 URL은 session identifier 와 요청된 presentation manifest 에 해당 하는 multicast session을 포함하는 multicast gateway configuration instance document를 piggybacking 하는 query parameter 를 포함할 수 있다.

다음은 실시예들에 따른 컨텐츠 프로바이더 및 서비스 프로바이더 동작을 설명한다.

실시예들에 따른 architecture는 실시예들에 따른 컨텐츠 프로바이더, 서비스 프로바이더, 네트워크, 디바이스 등을 포함할 수 있다. 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응할 수 있다. 실시예들에 따른 프로세서는 실시예들에 따른 동작을 수행할 수 있고, 동작에 관한 정보를 저장하는 메모리와 연결될 수 있다.

도37은 실시예들에 따른 멀티플 컨텐츠 프로바이더를 나타낸다.

실시예들에 따른 architecture는 복수의 content provider 로부터 생성된 content를 이용하여 service 되는 구조에 대해 도시한다. 실시예들에 따른 architecture에서는 각각의 network 에 대해서, multicast server, multicast gateway, multicast rendezvous service 가 각각의 network에 접속되어 있는 content playback function에 service를 제공한다.

이때, service provider 는 복수의 network 를 이용해 수신기 device에 서비스를 제공할 수 있다. Service provider는 service list directory를 구성 할 수 있고, 각각의 content provider 에 구성되어 있는 content provider control function을 통해 service 될 content list를 획득할 수 있다. 수신된 content list는 service에 적합한 형태로 service list를 구성할 수 있으며, 해당 service list는 application에 제공된다.

Service discovery interface를 통해 application은 multicast service 의 list 및 해당하는 multicast rendezvous service 에 대한 접속 정보를 획득한다. Service discovery interface는 service provider 와 application 사이에서 별도로 정의된 방법을 따를 수 있다. 또한 각각의 network 는 service discovery interface에 대한 data 의 송수신을 지원 할 수 있다.

Content provider server는 service provider에 구성되어 있는 multicast server로 content 를 제공한다 (ingest). 이때, ingest 되는 content 에 대한 정보는 각각의 content provider control function으로부터 service provider control function으로 전달 될 수 있다. Service provider control function 은 해당 정보를 이용해 multicast session configuration 정보로 구성하고 이를 multicast server 및 multicast gateway로 전달할 수 있다.

Device 내의 content playback function에는 각각의 network 에 대해 L interface 및 B interface 가 구성 될 수 있다. L1, L2, L3, L4 interface 를 통해 multicast gateway(A), multicast gateway (B), multicast gateway (C), multicast gateway (D) 를 통해 media streaming 을 수신할 수 있으며, B1, B2, B3, B4 interface를 통해 초기 multicast gateway 에 대한 접속 정보를 수신 할 수 있다. 여기에서, Multicast gateway (D) 와 multicast rendezvous service (D)는 device 내에 구성되어 있으므로, L4, B4 interface는 device 내부 interface 로 대체할 수 있다.

도38은 실시예들에 따른 멀티플 서비스 프로바이더를 나타낸다.

실시예들에 따른 architecture는 content provider 가 복수의 service provider를 통해 service 되는 구조에 대해 도시한다. 실시예들에 따른 architecture에서는 각각의 network 에 대해서, multicast server, multicast gateway, multicast rendezvous service 가 각각의 network에 접속되어 있는 content playback function에 service를 제공한다.

이때, 각각의 service provider 는 복수의 network 를 이용해 수신기 device에 서비스를 제공할 수 있다. Service provider는 각각 service list directory를 구성 할 수 있고, content provider의 content provider control function을 통해 service 될 content list를 획득할 수 있다. 수신된 content list는 service에 적합한 형태로 service list를 구성할 수 있으며, 해당 service list는 application에 제공된다.

Service discovery interface를 통해 application은 multicast service 의 list 및 해당하는 multicast rendezvous service 에 대한 접속 정보를 획득한다. Service discovery interface는 service provider 와 application 사이에서 별도로 정의된 방법을 따를 수 있다. 또한 각각의 network 는 service discovery interface에 대한 data 의 송수신을 지원 할 수 있다.

Content provider server는 service provider에 구성되어 있는 multicast server로 content 를 제공한다 (ingest). 이때, ingest 되는 content 에 대한 정보는 content provider control function으로부터 service provider control function으로 전달 될 수 있다. Service provider control function 은 해당 정보를 이용해 multicast session configuration 정보로 구성하고 이를 multicast server 및 multicast gateway로 전달할 수 있다.

Device 내의 content playback function에는 각각의 network 에 대해 L interface 및 B interface 가 구성 될 수 있다. L1, L2, L3, L4 interface 를 통해 multicast gateway(A), multicast gateway (B), multicast gateway (C), multicast gateway (D) 를 통해 media streaming 을 수신할 수 있으며, B1, B2, B3, B4 interface를 통해 초기 multicast gateway 에 대한 접속 정보를 수신 할 수 있다. 여기에서, Multicast gateway (D) 와 multicast rendezvous service (D)는 device 내에 구성되어 있으므로, L4, B4 interface는 device 내부 interface 로 대체할 수 있다.

도39는 실시예들에 따른 서비스 프로바이더 변경 흐름도를 나타낸다.

다음은 실시예들에 따른 architecture에 대해 device가 manifest를 획득하고, multicast media 를 수신 하는 과정에 이어서, service provider 가 변경된 이후에도 동일한 content 를 수신하는 과정에 대한 flow를 나타낸 것이다.

Content provider와 관련한 flow는 다음과 같이 진행될 수 있다.

Content provider control function은 content list를 service provider A와 service provider B의 service provider control function 에 전달한다.

Service provider control function content list를 service list 로 재구성하고, 연계된 각각의 application에 service list를 전송한다.

Multicast Server 와 관련한 flow 는 다음과 같이 진행된다. (각각의 service provider에 독립적으로 동작)

각각의 function이 architecture에 따라 deploy 되고 Multicast service 에 대한 configuration 이 multicast server, multicast gateway, multicast rendezvous service 에 적용된다.

Provisioning function은 network control을 통해 현재 provisioning 되어 있는 multicast session에 대한 configuration 정보를 multicast server에 전달한다.

Multicast session이 시작되면, content provider 로부터 multicast server에 media segment가 ingest 되고, multicast 전송을 시작하며, 해당 media segment를 수신할 수 있는 multicast gateway 가 있으면 수신 가능한 상태가 된다.

Device 가 service provider A 를 통해 service 를 수신 하면 다음과 같이 동작할 수 있다.

Application (A) 는 network A를 거쳐 service list directory (A) 로부터 service list 를 수신 할 수 있다. Service list 를 수신 하기 위해서 network A 에서 정의 되어 있는 service list 획득 방법이 사용 될 수 있다. 예를 들어, DVB-I network 에서 service directory 가 구성되어 있으면, service provider, service directory, application 사이의 상호 동작을 통해 service list를 수신할 수 있다. ABR multicast 동작을 위해서, service list 에는 service ID 에 mapping 되는 presentation manifest를 요청할 url 이 포함 될 수 있다.

Application (A)를 통해 사용자가 수신할 multicast contents를 선택하면, 해당 Application 에서 Service directory 등을 통해 최초 presentation manifest 를 요청할 URL을 획득할 수 있다. 이때 URL은 Multicast gateway(A) 또는 Multicast rendezvous service (A)를 가리킨다.

Application (A)는 content playback function이 content 수신을 위한 동작을 시작할 수 있도록 제어하며, 이때, Multicast gateway(A) 또는 Multicast rendezvous service(A) 에 대한 URL을 전달 할 수 있다.

Content playback function은 application (A)로부터 전달된 URL을 이용하여, reference point B1를 통해 Multicast rendezvous service(A)에 presentation manifest를 요청한다.

Multicast rendezvous service(A)는 동일 network에 구성되어 있는 Multicast gateway(A)의 상태를 체크 하고, 요청된 presentation manifest 에 대한 service가 multicast configuration에 정의 되어 있으면, Multicast gateway(A) 에 대한 redirection URL을 content playback function에 전송한다. 이때 전송되는 redirection message에 업데이트 된 multicast session configuration을 포함시킬 수 있다.

Redirection message를 수신한 content playback function은 해당 redirection을 따라 reference point L1을 통해 Multicast gateway(A)에 presentation manifest를 요청한다.

Multicast gateway(A) 에 미리 presentation manifest 가 cache 되어 있는 경우, 해당 presentation manifest 를 content playback function으로 전송한다.

Content playback function은 수신된 presentation manifest를 바탕으로 해당 contents 에 대한 media segment 를 요청한다.

Multicast streaming 이 multicast server (A) 에서 multicast gateway(A) 로 M1 interface를 통해 전송된다.

Content playback function은 Multicast gateway(A)를 통해 요청한 media segment를 수신할 수 있으며 media가 play 된다. 별도의 control이 없는 경우 media 의 play가 지속된다.

이 상태에서, device 가 service provider A 에서 Service provider B로 접속하고 이와 함께 network 역시 network (B)로 변경하게 되면 다음과 같이 동작할 수 있다.

Application (B) 는 network B를 거쳐 service list directory (B) 로부터 service list 를 수신 할 수 있다. Service list 를 수신 하기 위해서 network B 에서 정의 되어 있는 service list 획득 방법이 사용 될 수 있다. 예를 들어, DVB-I network 에서 service directory 가 구성되어 있으면, service provider, service directory, application 사이의 상호 동작을 통해 service list를 수신할 수 있다. ABR multicast 동작을 위해서, service list 에는 service ID 에 mapping 되는 presentation manifest를 요청할 url 이 포함 될 수 있다.

수신중에 있는 service 에 대해, Application (B)에서는 presentation manifest 를 요청할 URL을 획득할 수 있다. 이때 URL은 Multicast gateway(B) 및 rendezvous service (B)를 가리킨다.

사용자가 수신할 multicast contents를 선택하면, 해당 Application에서 Service directory 등을 통해 최초 presentation manifest 를 요청할 URL을 획득할 수 있다. 이때 URL은 Multicast gateway(B) 또는 Multicast rendezvous service (B)를 가리킨다.

Application 은 content playback function이 content 수신을 위한 동작을 시작할 수 있도록 제어하며, 이때, Multicast gateway(B) 또는 Multicast rendezvous service(B) 에 대한 URL을 전달 할 수 있다.

Multicast gateway 와 multicast rendezvous service가 동일한 장치에 구성되어 있는 경우 (co-located deployment), 다음 과정은 선택적으로 수행될 수 있다.

Content playback function은 application (B) 로부터 전달된 URL을 이용하여, reference point B2를 통해 Multicast rendezvous service(B)에 presentation manifest를 요청한다.

Multicast rendezvous service(B)는 동일 network에 구성되어 있는 Multicast gateway(B)의 상태를 체크 하고, 요청된 presentation manifest 에 대한 service가 multicast configuration에 정의 되어 있으면, Multicast gateway(B) 에 대한 redirection URL을 content playback function에 전송한다. 이때 전송되는 redirection message에 업데이트 된 multicast session configuration을 포함시킬 수 있다.

Redirection message를 수신한 content playback function은 해당 redirection을 따른다.

획득된 URL을 이용하여, reference point L2을 통해 Multicast gateway(B)에 presentation manifest를 요청한다.

Multicast gateway(B) 에 미리 presentation manifest 가 cache 되어 있는 경우, 해당 presentation manifest 를 content playback function으로 전송한다.

Content playback function은 수신된 presentation manifest를 바탕으로 network (B)를 통해 해당 contents 에 대한 media segment 를 요청한다.

Multicast streaming이 multicast server 에서 multicast gateway(B) 로 M interface를 통해 전송된다.

Content playback function은 Multicast gateway(B)를 통해 요청한 media segment를 수신할 수 있으며 media가 play 된다. 별도의 control이 없는 경우 media 의 play가 지속된다.

도40은 실시예들에 따른 유니다이렉셔널 딜리러비를 위한 MABR 네트워크 구성을 나타낸다.

전술한 실시예들에 따른 MABR 아키텍쳐의 네트워크를 통해, 실시예들에 따른 방법/장치는 단방향 딜리버리를 지원할 수 있고, 이를 위한 멀티캐스트 트랜스포트 세션 맵핑 예시를 설명한다.

실시예들에 따른architecture에서 Multicast ABR service provider 가 각각의 network 에 대해 multicast server를 구성하고, multicast gateway, multicast rendezvous service 에 Multicast interface (M) 을 이용하여 multicast contents 및 configuration 정보를 전송한다. 이때, M interface는 uplink channel이 없는 unidirectional network를 통해 구성될 수 있 있으며, 이러한 unidirectional network는 위성 (방송) 네트워크 또는 지상파 방송 네트워크를 고려할 수 있다.

Multicast gateway 및 multicast rendezvous service 에서 수신된 Multicast ABR contents 및 configuration 정보는 L interface에서 제공하는 HTTP 등을 이용하여 content playback function으로 전달될 수 있으며, multicast gateway 가 Home Broadcasting (HB) network 의 server로 동작할 수 있다.

Device 또는 HB network내의 content playback function에는 L interface 및 B interface 가 구성 될 수 있다. L interface 를 통해 multicast gateway 를 통한 media streaming 을 수신할 수 있으며, B interface를 통해 초기 multicast gateway 에 대한 접속 정보를 수신 할 수 있다. 여기에서, Multicast gateway 와 multicast rendezvous service 가 동일한 장치 내에 구성 되는 경우에는 L interface 및 B interface는 device 내부 interface 로 대체할 수 있다.

Service 에 대한 접속 정보 (URI 등) 를 알려줄 수 있는 service list는 content provider로부터 service list registry에 전달된 후, service list registry에서는 관리하고 있는 service list 정보를 multicast service 로 전달 할 수 있으며, multicast server 는 M interface를 통해 multicast gateway로 전달할 수 있다.

도41은 실시예들에 따른 유니다이렉셔널 딜리러비를 위한 MABR 네트워크 구성을 나타낸다.

실시예들에 따른architecture에서는 Multicast ABR service provider 가 단일 multicast server를 구성하고, multicast gateway, multicast rendezvous service 에 동일한 Multicast interface (M) 을 이용하여 동일한 multicast contents 및 configuration 정보를 전송한다. 이때, M interface는 uplink channel이 없는 unidirectional network를 통해 구성될 수 있 있으며, 이러한 unidirectional network는 위성 (방송) 네트워크 또는 지상파 방송 네트워크를 고려할 수 있다.

Multicast gateway 및 multicast rendezvous service 에서 수신된 Multicast ABR contents 및 configuration 정보는 L interface에서 제공하는 HTTP 등을 이용하여 content playback function으로 전달될 수 있으며, multicast gateway 가 Home Broadcasting (HB) network 의 server로 동작할 수 있다.

Device 또는 HB network내의 content playback function에는 L interface 및 B interface 가 구성 될 수 있다. L interface 를 통해 multicast gateway 를 통한 media streaming 을 수신할 수 있으며, B interface를 통해 초기 multicast gateway 에 대한 접속 정보를 수신 할 수 있다. 여기에서, Multicast gateway 와 multicast rendezvous service 가 동일한 장치 내에 구성 되는 경우에는 L interface 및 B interface는 device 내부 interface 로 대체할 수 있다.

Service 에 대한 접속 정보 (URI 등) 를 알려줄 수 있는 service list는 content provider로부터 service list registry에 전달된 후, service list registry에서는 관리하고 있는 service list 정보를 multicast service 로 전달 할 수 있으며, multicast server 는 M interface를 통해 multicast gateway로 전달 할 수 있다.

도42는 실시예들에 따른 인터페이스 구성을 나타낸다.

도41 등 실시예들에 따른 M인터페이스 구성은 다음과 같다.

Unidirectional link 가 포함된 M interface 에 기반하여, 실시예들에 따른 방법/장치는 단방향 딜리버리를 수행할 수 있다. 이 경우, unidirectional 는 satellite channel로 구성되는 것을 고려할 수 있으며, physical layer는 DVB-S2 또는 DVB-S2X 로 구성될 수 있으며, data link layer는 DVB-GSE로 구성될 수 있다.

Multicast server 는 M interface에 정의된 protocol을 통해 multicast gateway 로 multicast transport session을 전송하면, satellite transmitter 가 이를 수신 하여 satellite channel을 통해 satellite receiver로 전송한다. Satellite receiver는 이를 다시 M interface에 정의 된 protocol 그대로 multicast gateway로 전달한다. 이때, multicast transport session 이 satellite channel로 전송될 때, 단일 signaling로 multiplexing 될 수 있으며, 해당 multicast transport session을 de-multiplexing 하여 multicast gateway로 전달 되기 위해서, satellite channel을 통해 전송되는 IP multicast에 해당하는 multicast transport session을 mapping 해 줄 수 있다. 이때, multicast transport session을 mapping 하기 위해 data link layer signaling 을 이용할 수 있다.

도43은 실시예들에 따른 인터페이스 구성을 나타낸다.

Unidirectional link 가 포함된 M interface 에 기반하여, 실시예들에 따른 방법/장치는 단방향 딜리버리를 수행할 수 있다. 이 경우, unidirectional 는 broadcast channel로 구성되는 것을 고려할 수 있으며, physical layer는 DVB-T2 로 구성될 수 있으며, data link layer는 DVB-GSE로 구성될 수 있다.

Multicast server 는 M interface에 정의된 protocol을 통해 multicast gateway 로 multicast transport session을 전송하면, broadcast transmitter 가 이를 수신 하여 broadcast channel을 통해 broadcast receiver로 전송한다. Broadcast receiver는 이를 다시 M interface에 정의 된 protocol 그대로 multicast gateway로 전달한다. 이때, multicast transport session 이 broadcast channel로 전송될 때, 단일 signaling로 multiplexing 될 수 있으며, 해당 multicast transport session을 de-multiplexing 하여 multicast gateway로 전달 되기 위해서, broadcast channel을 통해 전송되는 IP multicast에 해당하는 multicast transport session을 mapping 해 줄 수 있다. 이때, multicast transport session을 mapping 하기 위해 data link layer signaling 을 이용할 수 있다.

실시예들에 따른 DVB-I 서비스 리스트에 ETSI TS 103 285에 따른 DVB-DASH 기반 서비스가 포함될 수 있다. DVB-NIP의 DVB-DASH 기반 서비스는 ETSI TS 103 769에 정의된 DVB 방송 네트워크를 통해 DVB-MABR 정의 FLUTE/ROUTE 프로토콜을 사용하여 전달될 수 있다.

시그널링 및 A/V 서비스(DVB-DASH ETSI TS 103 285 사용)는 IP 멀티캐스트를 통해 브로드캐스트 RF 채널에서 전달된다. DVB-NIP IP 멀티캐스트 세션은 ETSI TS 102 606-1의 D.2 절에 정의된 GSE-Lite 프로파일 또는 데이터 링크 계층에서 ETSI EN 301 192에 정의된 다중 프로토콜 캡슐화를 사용하여 전달된다. 또한, DVB-S2X(ETSI 302 307-1, ETSI 302 307-2), DVB-S2(ETSI 302 307-1) 및 DVB-T2(ETSI TS 102 755) 물리 계층이 결합될 수 있다.

도44는 실시예들에 따른 링크 컨트롤 데이터(LCD) 구성을 나타낸다.

실시예들에 따른 멀티캐스트 트랜스포트 세션 맵핑을 위한 논리적 레이어 컨트롤 구조에 기반하여, 실시예들에 따른 방법/장치는 단방향 딜리버리를 수행할 수 있다.

GSE-LLC 구조

실시예들에 따른 M interface에 대한 구성에서, multicast transport session을 mapping 하기 위해 data link layer signaling을 이용하는 방법에 대한 실시 예로 DVB-GSE LLC (Logical Layer Control) 을 사용한다.

DVB-GSE LLC 는 Link Control Data (LCD)와 Network Control Data (NCD) 로 구성되 구성된다.

LCD 의 syntax는 도44와 같이 구성될 수 있다.

PHY_descriptors() - Physical layer의 modulation system 에 대한 descriptor이다.

number_of_links - Physical layer의 modulation system에 포함되는 link 또는 physical stream 의 개수를 나타낸다.

link_id - Physical layer의 modulation system에 포함되는 physical link 에 대한 식별자이다.

link_association_descriptors()는 다음과 같이 구성될 수 있다.

도45는 실시예들에 따른 링크 관련 디스크립터를 나타낸다.

modulation_system_type - broadcast modulation system의 type에 대해 나타낸다. 예를 들어, 다음과 같이 encoding 될 수 있다.

0x00 - DVB-S2/S2X

0x01 - DVB-T2

modulation_system_id - modulation system에 대한 고유의 식별자이다.

PHY_stream_id - modulation_system_type 에 따라 다음과 같이 encoding 될 수 있다.

modulation_system_type = 0x00 인 경우 - DVB-S2/S2X 의 Input Stream Identifier (ISI)

modulation_system_type = 0x01 - DVB-T2의 Physical layer pipe

NCD 는 다음과 같이 구성될 수 있다.

도46은 실시예들에 따른 네트워크 컨트롤 데이터(NCD)를 나타낸다.

NCD 구조에서, platform_descriptor(), target_descriptor(), operational_descriptor는 각각의 signaling 용도에 맞게 정의할 수 있다.

target_descriptors() 와 관련하여, GSE가 IP 어드레스정보만 있으면, 실시예들에 따른 멀티캐스트를 처리할 수 있다. 따라서, 실시예들에 따른 target_descriptors()은 멀티캐스트 식별을 위한 정보를 포함하여, 문제를 해결할 수 있다.

NCD 구조에서, platform_descriptor(), target_descriptor(), operational_descriptor는 각각의 signaling 용도에 맞게 정의할 수 있다.

도47은 실시예들에 따른 멀티캐스트 트랜스포트 세션을 나타낸다.

실시예들에 따른 방법/장치는 멀티캐스트 트랜스포트 세션에 기반하여 트랜스포트 세션 맵핑을 수행할 수 있다.

Multicast server에서 전송되는 multicast transport session은 도47과 같이 정의 될 수 있다.

Multicast server에서 전송되는 multicast transport session은 unidirectional delivery transmitter (satellite transmitter) 에서 IP multicast stream으로 mapping 되며, IP multicast stream 정보를 unidirectional delivery receiver (satellite receiver) 로 전송할 수 있다.

도48은 실시예들에 따른 mABR IPv6트랜스포트 세션 디스크립터를 나타낸다.

실시예들에 따른 방법/장치가 Multicast transport session를 IPv6를 통해 전송하는 경우 도48과 같은 descriptor 를 target descriptor에 포함시킬 수 있다.

descriptor_tag - descriptor 에 대한 식별자에 해당한다.

descriptor_length - 해당 descriptor에 대한 길이를 나타낸다.

multicast_transport_session_id_length - 뒤에 나타나는 multicast_transport_session_id에 대한 길이를 byte 단위로 나타낸다.

multicast_transport_session_id - multicast transport session에 대한 고유의 식별자로, Multicast ABR session configuration에 포함되어 있는 id 값과 동일한 값을 가진다.

source_IPv6_address - IPv6로 전송되는 현재 multicast transport session 에 대한 source IP address를 나타낸다.

destination_IPv6_address - IPv6로 전송되는 현재 multicast transport session 에 대한 group (desdination) IP address를 나타낸다.

source_UDP_port - 현재 multicast transport session에 대한 source UDP port를 나타낸다.

destination_UDP_port - 현재 multicast transport session에 대한 destination UDP port를 나타낸다.

GSE 관련 디스크립터에 source_UDP_port 및 destination_UDP_port를 추가로 정의함으로써, 실시예들에 따른 방법/장치는 멀티캐스트를 지원할 수 있다.

또한, 트랜스포트 세션 디스크립터는 멀티캐스트 리스트 디스크립터로 지칭될 수 있고, 다음 정보를 더 포함할 수 있다.

num_multicasts: 이 16비트 필드이고, 멀티캐스트의 개수를 나타낸다.

multicast_stream_id: 이 16비트 필드는 link_id에 의해 식별되는 물리적 링크 내에서 IP/UDP 멀티캐스트 스트림을 고유하게 식별한다.

source_ip_address: 이 32비트 필드는 link_id에 의해 식별되는 물리적 링크에서 운반되는 멀티캐스트의 소스 IPv4 주소를 나타낸다.

destination_ip_address: 이 32비트 필드는 link_id에 의해 식별되는 물리적 링크에서 운반되는 멀티캐스트의 목적지 IPv4 주소를 나타낸다.

source_port: 이 16비트 필드는 link_id에 의해 식별되는 물리적 링크에서 운반되는 멀티캐스트의 소스 UDP 포트 번호를 나타낸다.

destination_port: 이 16비트 필드는 link_id에 의해 식별되는 물리적 링크에서 운반되는 멀티캐스트의 목적지 UDP 포트 번호를 나타낸다.

header_compression_flag: 이 1비트 부울 필드는 헤더 압축이 multicast_stream_id에 의해 식별되는 멀티캐스트 스트림에 적용되는지 여부를 나타낸다. 값 0(영)은 멀티캐스트 스트림이 DVB-GSE 계층에서 헤더 압축 없이 전달됨을 나타낸다. 값 1(일)은 헤더 압축이 DVB-GSE 계층의 멀티캐스트 스트림에 적용됨을 나타낸다. compressed_flag의 값이 1과 같을 때 ROHC-U 디스크립터 또는 ROHC-U_ multicast_descriptor가 시그널링된다.

reserved_for_future_use: 이 7비트 필드는 향후 사용을 위해 예약되어 있으며 모든 비트는 0으로 설정되어야 한다.

도49는 실시예들에 따른 mABR IPv4트랜스포트 세션 디스크립터를 나타낸다.

실시예들에 따른 방법/장치는 Multicast transport session을 IPv4를 통해 전송하는 경우 도49과 같은 descriptor 를 target descriptor에 포함시킬 수 있다.

descriptor_tag - descriptor 에 대한 식별자에 해당한다.

descriptor_length - 해당 descriptor에 대한 길이를 나타낸다.

multicast_transport_session_id_length - 뒤에 나타나는 multicast_transport_session_id에 대한 길이를 byte 단위로 나타낸다.

multicast_transport_session_id - multicast transport session에 대한 고유의 식별자로, Multicast ABR session configuration에 포함되어 있는 id 값과 동일한 값을 가진다.

source_IPv6_address - IPv4로 전송되는 현재 multicast transport session 에 대한 source IP address를 나타낸다.

destination_IPv6_address - IPv4로 전송되는 현재 multicast transport session 에 대한 group (desdination) IP address를 나타낸다.

source_UDP_port - 현재 multicast transport session에 대한 source UDP port를 나타낸다.

destination_UDP_port - 현재 multicast transport session에 대한 destination UDP port를 나타낸다.

복수의 multicast transport session을 단일 link로 mapping 하는 경우에는 NCD loop 내에 복수의 mABR_IPv6_transport_session_descriptor () 또는 mABR_IPv4_transport_session_descriptor () 를 포함 시킬 수 있다.

트랜스포트 세션 디스크립터는 멀티캐스트 리스트 디스크립터로 지칭될 수 있고, 하기 정보를 더 포함할 수 있다.

num_multicasts: 이 16비트 필드는 다음 멀티캐스트의 개수를 나타낸다.

multicast_stream_id: 이 16비트 필드는 link_id에 의해 식별되는 물리적 링크 내에서 IP/UDP 멀티캐스트 스트림을 고유하게 식별한다.

source_ip_address: 이 128비트 필드는 link_id에 의해 식별되는 물리적 링크에서 운반되는 멀티캐스트의 소스 IPv6 주소를 나타낸다.

destination_ip_address: 이 128비트 필드는 link_id에 의해 식별되는 물리적 링크에서 운반되는 멀티캐스트의 목적지 IPv6 주소를 나타낸다.

source_port: 이 16비트 필드는 link_id에 의해 식별되는 물리적 링크에서 운반되는 멀티캐스트의 소스 UDP 포트 번호를 나타낸다.

destination_port: 이 16비트 필드는 link_id에 의해 식별되는 물리적 링크에서 운반되는 멀티캐스트의 목적지 UDP 포트 번호를 나타낸다.

header_compression_flag: 이 1비트 부울 필드는 헤더 압축이 multicast_stream_id에 의해 식별되는 멀티캐스트 스트림에 적용되는지 여부를 나타낸다. 값 0(영)은 멀티캐스트 스트림이 DVB-GSE 계층에서 헤더 압축 없이 전달됨을 나타낸다. 값 1(일)은 헤더 압축이 DVB-GSE 계층의 멀티캐스트 스트림에 적용됨을 나타냅니다. compressed_flag의 값이 1과 같을 때 ROHC-U 디스크립터 또는 ROHC-U_ multicast_descriptor가 시그널링된다.

reserved_for_future_use: 이 7비트 필드는 향후 사용을 위해 예약되어 있으며 모든 비트는 0으로 설정되어야 한다.

도48-49 멀티캐스트 리스트 디스크립터는 피지컬 링크 내 전달되는 멀티캐스트의 리스트를 전달한다. 이 디스트립터는 피지컬 링크 내 전달되는 IPv4 멀티캐스트의 리스트를 전달하고, DVB-GSE 레이어 내 멀티캐스트를 전달하는 UDP/IPv4 패킷들을 처리하기 위한 정보를 제공한다. 또한, 이 디스크립터는 피지컬 링크 내 전달되는 IPv6 멀티캐스트의 리스트를 전달하고, DVB-GSE 레이어 내 멀티캐스트를 전달하는 UDP/IPv6 패킷들을 처리하기 위한 정보를 제공한다.

도50은 실시예들에 따른 5G 시스템 서비스 기반 구조를 나타낸다.

실시예들에 따른 방법/장치는 다음과 같이 5G System Architecture와 연계될 수 있다.

The 5G System 은 다음과 같은 network functions (NF)으로 구성될 수 있다.

실시예들에 따른 약자는 다음과 같다: Authentication Server Function (AUSF), Core Access and Mobility Management Function (AMF), Data network (DN), e.g. operator services, Internet access or 3rd party services, Structured Data Storage network function (SDSF), Unstructured Data Storage network function (UDSF), Network Exposure Function (NEF), NF Repository Function (NRF), Policy Control function (PCF), Session Management Function (SMF), Unified Data Management (UDM), User plane Function (UPF), Application Function (AF), User Equipment (UE), (Radio) Access Network ((R)AN).

5G system의 non-roaming case 에 대한 architecture를 service 기반의 interface로 나타낸 것이다. User plane data는 DN, UPF, (R)AN, UE을 거쳐 전달되며, 그외의 다른 function은 control plane data를 처리할 수 있다.

여기에서 각각의 service 기반 interface는 다음과 같다: Namf: Service-based interface exhibited by AMF. Nsmf: Service-based interface exhibited by SMF. Nnef: Service-based interface exhibited by NEF. Npcf: Service-based interface exhibited by PCF. Nudm: Service-based interface exhibited by UDM. Naf: Service-based interface exhibited by AF. Nnrf: Service-based interface exhibited by NRF. Nausf: Service-based interface exhibited by AUSF.

도51은 실시예들에 따른 레퍼런스 포인트 리프리젠테이션 내 5G 시스템 구조를 나타낸다.

도51은 여러 network function이 어떻게 상호동작 하는지 나타내는 reference point를 이용하여 non-roaming case에 대한 5G system architecture를 나타낸 것이다.

User plane data는 DN, UPF, (R)AN, UE을 거쳐 전달되며, 그외의 다른 function은 control plane data를 처리할 수 있다. 따라서, 해당 function사이의 reference point인 N6, N3를 통해 data가 전달되며, (R)AN과 UE 사이는 무선으로 연결될 수 있다.

여기에서, reference point는 다음과 같이 정의 될 수 있다: N1: Reference point between the UE and the AMF. N2: Reference point between the (R)AN and the AMF. N3: Reference point between the (R)AN and the UPF. N4: Reference point between the SMF and the UPF. N5: Reference point between the PCF and an AF. N6: Reference point between the UPF and a Data Network. N7: Reference point between the SMF and the PCF. N7r: Reference point between the PCF in the visited network and the PCF in the home network. N8: Reference point between the UDM and the AMF. N9: Reference point between two Core UPFs. N10: Reference point between the UDM and the SMF. N11: Reference point between the AMF and the SMF. N12: Reference point between AMF and AUSF. N13: Reference point between the UDM and Authentication Server function the AUSF. N14: Reference point between two AMFs. N15: Reference point between the PCF and the AMF in case of non-roaming scenario, PCF in the visited network and AMF in case of roaming scenario. N16: Reference point between two SMFs, (in roaming case between SMF in the visited network and the SMF in the home network). N17: Reference point between AMF and EIR. N18: Reference point between any NF and UDSF. N19: Reference point between NEF and SDSF.

위에서 열거된 reference point는 별도의 protocol로 정의 되거나, 공통된 protocol상에서, 별도의 식별자를 가지는 message로 정의 될 수 있다. 이를 위해, control plane의 interface는 물리적으로는 다른 reference point와 공유될 수 있으며 각각의 protocol 또는 message set 등을 이용해 reference point를 식별 할 수 있다.

도52는 실시예들에 따른 멀티플 PDU 세션을 위한 5G 시스템 구조를 나타낸다.

도51는 앞서 기술한 5G system architecture를 기반으로, 두개의 DN을 지원 하기 위한 network 구조를 나타낸다. 하나의 DN이 접속되기 위해서는 해당 DN에 대한 UPF 및 SMF 가 별도로 구성될 수 있고, 이 function은 또한 각각 control plane function과 해당 reference point를 통해 연결될 수 있다. 따라서, 각각의 DN은 별도의 PDU session을 제공하게 되고 SMF가 해당 session을 제어할 수 있다.

도52에서는 동시에 두 개의 DN (Data Network) 에 접속 되는 것을 나타내고 있으나 network 구성에 따라 두개 이상의 DN과 접속될 수 있다.

도53은 실시예들에 따른 두 가지 데이터 네트워크들에 공존하는 접속을 위한 5G 시스템 구조를 나타낸다.

도53은 하나의 PDU 세션 옵션을 따를 수 있다.

도53은 두 개의 DN에 접속되어 있는 구조에서 단일 SMF를 이용하여 각각의 DN에서 제공하는 PDU session이 단일 session으로 동작할 수 있게 구성된 network architecture 이다.

이러한 network 구조에 대해, 하나의 PDU session에 대한 User Plane Protocol stack 은 도54와 같이 정의 될 수 있다.

도54는 실시예들에 따른 유저 플레인 프로토콜 스택을 나타낸다.

PDU layer: 이 계층은 PDU 세션을 통해 UE와 DN 간에 전달되는 PDU에 해당한다. PDU 세션 유형이 IPV6인 경우 IPv6 패킷에 해당한다. PDU 세션 유형이 이더넷인 경우 이더넷 프레임에 해당한다.

5G Encapsulation: 이 계층은 N3(즉, AN과 5GC 간) 또는 N9(즉, 5GC의 서로 다른 UPF 간)를 통해 서로 다른 PDU 세션(다른 PDU 세션 유형에 해당할 수 있음)의 다중화 트래픽을 지원한다. PDU 세션 수준에서 캡슐화를 제공한다. 이 계층은 QoS 흐름과 관련된 표시도 수행한다.

AN protocol stack: 이 프로토콜/계층 세트는 AN에 따라 다르다. AN이 3GPP RAN인 경우 이러한 프로토콜/계층은 3GPP RAN에 의해 정의된다.

데이터 경로에 있는 UPF의 수는 3GPP 사양에 의해 제한되지 않는다. 이 PDU 세션에 대한 PDU 세션 앵커 기능을 지원하지 않는 PDU 세션 0, 1 또는 다중 UPF의 데이터 경로에 있을 수 있다. IP의 경우 유형 PDU 세션에서 PDU 세션 앵커 역할을 하는 UPF는 UE에 할당된 IP 주소/접두사의 IP 앵커 포인트이다.

앞서 기술한 5G architecture에 대해서, 각각의 function에 대한 기능은 아래와 같다.

액세스 및 이동성 관리 기능(Access and Mobility Management function) (AMF)

The Access and Mobility Management function (AMF) 은 다음과 같은 기능을 포함할 수 있다. 단일 AMF instance 는 아래의 기능 전부 또는 일부를 지원할 수 있다: RAN CP 인터페이스 종료(N2), NAS(N1) 종료, NAS 암호화 및 무결성 보호, 등록 관리, 연결 관리, 접근성 관리, 모빌리티 관리, 적법한 가로채기(AMF 이벤트 및 LI 시스템에 대한 인터페이스용), UE와 SMF 간의 SM 메시지 전송을 제공한다. SM 메시지 라우팅을 위한 투명한 프록시, 액세스 인증, 액세스 권한 부여, UE와 SMSF 간의 SMS 메시지 전송을 제공한다. 보안 앵커 기능(SEA). AUSF 및 UE와 상호 작용하고 UE 인증 프로세스의 결과로 설정된 중간 키를 수신한다. USIM 기반 인증의 경우 AMF는 AUSF에서 보안 자료를 검색한다. 보안 컨텍스트 관리(SCM). SCM은 액세스 네트워크 특정 키를 파생하는 데 사용하는 SEA로부터 키를 받는다.

또한, AMF는 non-3GPP access network를 지원하기 위해 다음과 같은 기능을 포함 할 수 있다.

N3IWF와 N2 인터페이스 지원. 이 인터페이스를 통해 3GPP 액세스를 통해 정의된 일부 정보(예: 3GPP 셀 식별) 및 절차(예: 핸드오버 관련)가 적용되지 않을 수 있으며, 3GPP 액세스에는 적용되지 않는 비 3GPP 액세스 특정 정보가 적용될 수 있다.

N3IWF를 통한 UE와의 NAS 시그널링 지원. 3GPP 액세스를 통한 NAS 시그널링이 지원하는 일부 절차는 신뢰할 수 없는 비-3GPP(예: 페이징) 액세스에 적용되지 않을 수 있다.

N3IWF를 통해 연결된 UE의 인증 지원. 비 3GPP 액세스를 통해 연결되거나 3GPP 및 비 3GPP 액세스를 통해 동시에 연결된 UE의 이동성, 인증 및 별도의 보안 컨텍스트 상태 관리. 3GPP 및 비 3GPP 액세스에 대해 유효한 조정된 RM 관리 컨텍스트를 지원한다. 비 3GPP 액세스를 통한 연결을 위해 UE에 대한 전용 CM 관리 컨텍스트를 지원한다. 세션 관리 기능(SMF)

Session Management function (SMF) 은 다음과 같은 기능을 포함할 수 있다. 단일 SMF instance 는 아래의 기능 전부 또는 일부를 지원할 수 있다:

세션 관리. 예를 들어 UPF와 AN 노드 간의 터널 유지 관리를 포함하여 세션 설정, 수정 및 해제. UE IP 주소 할당 및 관리(선택적 권한 부여 포함). UP 기능 선택 및 제어. 트래픽을 적절한 대상으로 라우팅하도록 UPF에서 트래픽 조정을 구성한다. 정책 제어 기능에 대한 인터페이스 종료. 정책 시행 및 QoS의 일부를 제어한다. 적법한 가로채기(SM 이벤트 및 LI 시스템에 대한 인터페이스용). NAS 메시지의 SM 부분 종료. 다운링크 데이터 알림. AMF를 통해 N2를 통해 AN으로 전송되는 AN 특정 SM 정보의 개시자. 세션의 SSC 모드를 결정한다. 로밍 기능: QoS SLA(VPLMN)를 적용하기 위해 로컬 적용을 처리한다. 충전 데이터 수집 및 충전 인터페이스(VPLMN). 적법한 가로채기(SM 이벤트 및 LI 시스템에 대한 인터페이스를 위한 VPLMN에서). 외부 DN에 의한 PDU 세션 승인/인증을 위한 신호 전송을 위한 외부 DN과의 상호 작용 지원.

사용자 평면 기능(UPF)

User plane function (UPF) 은 다음과 같은 기능을 포함할 수 있다. 단일 UPF instance 는 아래의 기능 전부 또는 일부를 지원할 수 있다:

Intra-/Inter-RAT 이동성을 위한 앵커 포인트(해당되는 경우). 데이터 네트워크에 대한 상호 연결의 외부 PDU 세션 지점이다. 패킷 라우팅 및 전달. 정책 규칙 시행의 패킷 검사 및 사용자 평면 부분. 적법한 도청(UP 수집). 트래픽 사용량 보고. 데이터 네트워크로의 트래픽 흐름 라우팅을 지원하는 업링크 분류기. 멀티홈 PDU 세션을 지원하는 분기점. 사용자 평면에 대한 QoS 처리(예: 패킷 필터링, 게이팅, UL/DL 속도 시행). 업링크 트래픽 검증(SDF 대 QoS 흐름 매핑). 업링크 및 다운링크의 전송 수준 패킷 표시. 다운링크 패킷 버퍼링 및 다운링크 데이터 알림 트리거.

정책 기능(PCF)(Policy function) (PCF)

Policy function (PCF) 은 다음과 같은 기능을 포함할 수 있다.

네트워크 동작을 제어하는 통합 정책 프레임워크를 지원한다. 정책 규칙을 적용하기 위해 제어 평면 기능에 제공한다. UDR(사용자 데이터 저장소)의 정책 결정과 관련된 구독 정보에 액세스하기 위해 프런트 엔드를 구현한다.

네트워크 노출 기능(Network Exposure Function) (NEF)

Network Exposure Function (NEF) 은 다음과 같은 기능을 포함할 수 있다.

섹션 5.13에 설명된 대로 제3자, 내부 노출/재노출, 애플리케이션 기능, 에지 컴퓨팅을 위해 3GPP 네트워크 기능이 제공하는 서비스 및 기능을 안전하게 노출하는 수단을 제공한다.

네트워크 노출 기능은 다른 네트워크 기능에서 정보를 수신합니다(다른 네트워크 기능의 노출된 기능을 기반으로 함). 데이터 저장 네트워크 기능(3GPP에서 정의할 인터페이스)에 대한 표준화된 인터페이스를 사용하여 수신된 정보를 구조화된 데이터로 저장할 수 있다. 저장된 정보는 NEF에 의해 다른 네트워크 기능 및 애플리케이션 기능에 "재노출"될 수 있으며 분석과 같은 다른 목적으로 사용될 수 있다.

NF 저장소 기능(NF Repository Function) (NRF)

NF Repository Function (NRF) 은 다음과 같은 기능을 포함할 수 있다.

서비스 검색 기능을 지원합니다. NF 인스턴스로부터 NF Discovery Request를 수신하고, 발견된 NF 인스턴스(발견될)의 정보를 NF 인스턴스에 제공한다. 사용 가능한 NF 인스턴스 및 지원 서비스에 대한 정보를 유지 관리한다.

도55는 실시예들에 따른 Unified Data Management (UDM) 을 나타낸다.

Unified Data Management (UDM)는 application front end (FE) 와User Data Repository (UDR)로 나눌 수 있다.

도55는 UDM에 대한 reference architecture를 나타낸 것이며, 다음과 같은 front end 가 포함될 수 있다.

UDM FE: 자격 증명 처리, 위치 관리, 구독 관리 등을 담당한다.

PCF: 정책통제를 담당한다. PCF는 전체 5GC 아키텍처에서 독립 실행형 네트워크 기능이므로 UDM의 일부가 아니다. 그러나 PCF는 UDR에 정책 구독 정보를 요청하고 제공할 수 있으며 이러한 이유로 UDM 아키텍처에 표시된다.

UDR은 UDM-FE에서 제공하는 기능에 필요한 데이터와 PCF에 필요한 정책 프로필을 저장한다. UDR에 저장된 데이터에는 다음이 포함된다:

구독 식별자, 보안 자격 증명, 액세스 및 이동성 관련 구독 데이터 및 세션 관련 구독 데이터를 포함한 사용자 구독 데이터, 정책 데이터. UDM-FE는 UDR(사용자 데이터 저장소)에 저장된 구독 정보에 액세스하고 다음 기능을 지원한다.

인증 자격 증명 처리. 사용자 식별 처리. 액세스 권한 부여. 등록/이동성 관리. 구독 관리. SMS 관리. 프런트 엔드는 애플리케이션 로직을 구현하며 내부 사용자 데이터 저장소가 필요하지 않다. 여러 개의 서로 다른 프런트 엔드가 서로 다른 트랜잭션에서 동일한 사용자에게 서비스를 제공할 수 있다.

N25/Nudr 기준점/인터페이스는 프런트 엔드가 읽기, 업데이트(추가, 수정 포함), 삭제, 데이터 변경 알림 구독 및 UDR의 데이터 변경 알림을 위해 정의된다. N25는 P2P 기준점의 이름이고 Nudr은 서비스 기반 인터페이스의 이름이다. FE와 UDR은 모두 HPLMN에 있다.

인증 서버 기능(Authentication Server Function) (AUSF)

AUSF는 다음 기능을 지원한다. AUSF(인증 서버 기능)를 지원한다.

응용 기능(Application Function) (AF)

애플리케이션 기능(AF)은 서비스를 제공하기 위해 3GPP 코어 네트워크와 상호 작용한다. 예를 들어 다음을 지원한다. 트래픽 라우팅에 대한 애플리케이션 영향, 네트워크 기능 노출에 액세스, 정책 제어를 위한 정책 프레임워크와 상호 작용, 운영자 배치를 기반으로 운영자가 신뢰하는 것으로 간주되는 응용 프로그램 기능은 관련 네트워크 기능과 직접 상호 작용할 수 있다. 운영자가 네트워크 기능에 직접 액세스하도록 허용하지 않은 응용 프로그램 기능은 관련 네트워크 기능과 상호 작용하기 위해 NEF를 통해 외부 노출 프레임워크를 사용해야 한다.

도56은 실시예들에 따른 5G 미디어 스트리밍을 위한 구조를 나타낸다.

5G 시스템 내 5G 다운링크 미디어 스트리밍(5G Downlink Media Streaming within the 5G System)

도56은 5G network내에 downlink media streaming을 위한 function이 구성되어 있는 구조를 나타낸다.

5670 구조에서, 5G media streaming을 위해서, UE 에는 5GMSd Aware Application 과 5GMSd Client가 구성되며, DN (Data Network)에는 5GMSd AF 및 5GMSd AS 가 구성 될 수 있다. 여기에서, mobile network operator 가 운용하는 network 내에 DN 이 구성되어 있으면 Trusted DN 으로 고려 될 수 있으며, mobile network operator 밖에 DN이 구성되어 있으면, (예를 들어 3rd party CDN 등) External DN으로 고려 될 수 있다. 그 외 Function 및 interface 는 Annex A에 추가로 기술되어 있다.

도57은 실시예들에 따른 유니캐스트 다운링크 미디어 스트리밍을 위한 미디어 아키텍처(Media Architecture for unicast downlink media streaming)를 나타낸다.

전술한 network architecture에 대해서, unicast downlink media streaming 을 위한 Media Architecture 는 다음과 같이 정의 될 수 있다. 여기에서, 각각의 function 및 interface는 media streaming 관점의 logical interface를 정의 한 것이다.

각각의 function은 다음과 같이 정의 될 수 있다.

UE 상의 5GMSd 클라이언트(다운링크용 5G 미디어 스트리밍 클라이언트): 잘 정의된 인터페이스/API를 통해 액세스할 수 있는 5GMS 다운링크 미디어 스트리밍 서비스의 수신기. 대안적으로, UE는 인터페이스 M6d 및 M7d가 전혀 노출되지 않도록 자체 포함된 방식으로 구현될 수 있다.

5GMSd 클라이언트에는 두 가지 하위 기능이 있습니다.

미디어 세션 핸들러: 미디어 세션의 전달을 설정, 제어 및 지원하기 위해 5GMSd AF와 통신하는 UE의 기능이다. 미디어 세션 핸들러는 5GMSd-Aware 애플리케이션에서 사용할 수 있는 API를 노출할 수 있다.

미디어 플레이어: 미디어 콘텐츠를 스트리밍하기 위해 5GMSd AS와 통신하고 미디어 재생을 위해 5GMSd 인식 애플리케이션에, 미디어 세션 제어를 위해 미디어 세션 핸들러에 API를 제공할 수 있는 UE의 기능을 수행한다.

5GMSd 인식 애플리케이션: 5GMSd 클라이언트는 일반적으로 외부 미디어 애플리케이션에 의해 제어된다. 외부 애플리케이션 또는 콘텐츠 서비스 제공자 특정 로직을 구현하고 미디어 세션을 설정할 수 있는 앱이다. 5GMSd-Aware 애플리케이션은 5G 미디어 스트리밍 사양에 정의되어 있지 않지만, 이 기능은 5GMSd 인터페이스 및 API를 사용하여 5GMSd 클라이언트 및 네트워크 기능을 사용한다.

5GMSd AS: 5G 미디어 기능을 호스팅하는 애플리케이션 서버이다. 5GMSd AS의 다른 구현이 있을 수 있다(예: CDN(Content Delivery Network)).

5GMSd 애플리케이션 제공자: 외부 애플리케이션 또는 콘텐츠별 미디어 기능(예: 5GMSd를 사용하여 미디어를 5GMSd 인식 애플리케이션으로 스트리밍하는 미디어 생성, 인코딩 및 포맷)한다.

5GMSd AF: UE 상의 미디어 세션 핸들러 및/또는 5GMSd 애플리케이션 제공자에게 다양한 제어 기능을 제공하는 애플리케이션 기능을 수행한다. 다른 정책 또는 과금 기능(PCF) 처리에 대한 요청을 릴레이 또는 시작하거나 NEF를 통해 다른 네트워크 기능과 상호 작용할 수 있다.

5G Downlink Media Streaming 을 위한 각각의 interface 는 다음과 같이 정의 될 수 있다.

M1d(5GMSd 프로비저닝 API): 5G 미디어 스트리밍 시스템의 사용을 프로비저닝하고 피드백을 얻기 위해 5GMSd AF에 의해 노출되는 외부 API이다.

M2d(5GMSd Ingest API): 신뢰할 수 있는 DN의 5GMSd AS가 스트리밍 서비스용 콘텐츠를 호스팅하도록 선택될 때 사용되는 5GMSd AS에 의해 노출되는 선택적 외부 API이다.

M3d: (내부): 신뢰할 수 있는 DN 내의 5GMSd AS에서 호스팅되는 콘텐츠에 대한 정보를 교환하는 데 사용되는 내부 API이다.

M4d(미디어 스트리밍 API): 5GMSd AS가 미디어 콘텐츠를 스트리밍하기 위해 미디어 플레이어에 노출하는 API이다.

M5d(미디어 세션 처리 API): 미디어 세션 처리, 제어 및 지원을 위해 5GMSd AF에 의해 미디어 세션 핸들러에 노출되는 API이다. 여기에는 적절한 보안 메커니즘도 포함된다. 권한 부여 및 인증을 수행한다.

M6d(UE Media Session Handling APIs): 클라이언트 내부 통신을 위해 Media Session Handler에 의해 Media Player에 노출되고 5GMSd-Aware Application에 노출되어 5GMS 기능을 사용할 수 있도록 하는 API이다.

M7d(UE 미디어 플레이어 API): 미디어 플레이어를 사용하기 위해 미디어 플레이어가 5GMSd 인식 애플리케이션 및 미디어 세션 핸들러에 노출하는 API이다.

M8d: (응용 프로그램 API): 5GMSd 인식 응용 프로그램과 5GMSd 응용 프로그램 공급자 간의 정보 교환에 사용되는 응용 프로그램 인터페이스(예: 5GMSd 인식 응용 프로그램에 서비스 액세스 정보 제공). 이 API는 5G 시스템 외부에 있으며 5GMS에서 지정하지 않는다.

멀티캐스트 적응형 비트레이트 시스템 아키텍처(MULTICAST ADAPTIVE BITRATE SYSTEM ARCHITECTURE)

실시예들에 따른 방법/장치는 다음과 같이 MULTICAST ADAPTIVE BITRATE SYSTEM ARCHITECTURE와 연계될 수 있다.

도58은 실시예들에 따른 레퍼런스 구조를 나타낸다.

참조 포인트(REFERENCE POINTS):

도58의 reference architecture 에서, logical function 간의 관계는 reference point로 정의 할 수 있다. 실제 이러한 architecture가 실제로 사용되는 경우에는, 구체적인 interface 로 구현될 수 있으며 각각 특정 프로토콜을 사용하여 관련 function 사이에 필요한 정보를 교환 할 수 있다.

데이터 플레인 참조 포인트(DATA PLANE REFERENCE POINTS):

위의 architecture에서 content를 전송하기 위한 reference point는 다음과 같다.

L: 콘텐츠 재생 기능과 멀티캐스트 게이트웨이 간의 유니캐스트 HTTP(및 이후에는 HTTPS) 상호 작용을 수행한다. 이 인터페이스에는 지정된 모든 유형의 콘텐츠 가져오기가 포함된다.

멀티캐스트 게이트웨이와 콘텐츠 재생 기능이 셋톱박스와 같은 단일 종단 장치에 공존하는 경우 인터페이스 L은 로컬 API로 구현될 수 있다.

B: 콘텐츠 재생 기능과 멀티캐스트 랑데부 서비스 기능 간의 직접 부트스트랩 유니캐스트 HTTP(S) 상호작용을 담당한다. 선형 재생 세션 시작 시 프레젠테이션 매니페스트를 요청하는 데 사용된다.

A: 참조점 M을 통해 제공되지 않는 콘텐츠의 콘텐츠 호스팅 기능에서 HTTP(S) 획득한다.

콘텐츠 재생 기능에서 참조 지점 L의 범위를 벗어나 콘텐츠를 검색하는 데 사용된다.

콘텐츠 복구를 수행하기 위해 콘텐츠 호스팅 기능에서 콘텐츠를 검색하기 위해 유니캐스트 복구 서비스 기능이 일부 배포에서 사용한다.

U가 콘텐츠 복구를 수행할 수 없을 때 유니캐스트를 통해 콘텐츠 호스팅 기능에서 직접 콘텐츠를 검색하기 위해 멀티캐스트 게이트웨이에서도 사용된다.

M: 멀티캐스트 서버 기능에 의한 멀티캐스트 IP 콘텐츠 전송 및 멀티캐스트 게이트웨이 기능에 의한 수신 및 일부 배포에서는 유니캐스트 수리 서비스 기능에 의한 수신 등을 담당한다.

U: 멀티캐스트 게이트웨이의 유니캐스트 복구 클라이언트와 유니캐스트 복구 서비스 간의 유니캐스트 상호 작용을 담당한다. 이 인터페이스는 이러한 페이로드에 대한 요청 외에 콘텐츠 복구 기능에 사용되는 페이로드를 전달하는데 사용될 수 있다.

U': A를 통해 복구 콘텐츠를 가져오는 대신 유니캐스트 복구 서비스와 멀티캐스트 서버 간의 유니캐스트 상호 작용을 담당한다. 이 인터페이스는 이러한 페이로드에 대한 요청 외에 콘텐츠 복구 기능에 사용되는 페이로드를 운반하는 데 사용될 수 있다.

Pin: 콘텐츠 패키징 하위 기능에 의해 콘텐츠 호스팅 기능에 콘텐츠 게시를 하고, 이것은 푸시 인터페이스로 구현되거나 콘텐츠 패키징 기능에서 요청 시 콘텐츠를 가져올 수 있다.

Oin: 콘텐츠 호스팅 기능에서 멀티캐스트 서버 기능에 의한 콘텐츠 수집하고, 이것은 일반적으로 풀 인터페이스로 구현된다.

Pin': 콘텐츠 패키징 기능에서 직접 멀티캐스트 서버에 의한 콘텐츠 인제스트하고, 이것은 일반적으로 푸시 인터페이스로 구현된다.

제어 평면 기준점(CONTROL PLANE REFERENCE POINTS)

위의 architecture에서 control signaling 및 operational reporting 정보를 전송하기 위한 reference point는 다음과 같다.

CMS: 멀티캐스트 서버 기능 구성을 위한 제어 인터페이스.

CMR: 멀티캐스트 게이트웨이 기능 구성을 위한 제어 인터페이스.

CCP: 프로비저닝 기능 구성을 위한 제어 인터페이스.

RS: 서비스 보고 캡처 기능에 대한 멀티캐스트 게이트웨이 기능에 의한 서비스 보고.

RCP: 콘텐츠 제공자 메트릭 보고 캡처 기능에 대한 서비스 보고 캡처 하위 기능에 의한 서비스 보고.

RPM: 콘텐츠 재생 기능에 의해 콘텐츠 제공자 메트릭 보고 캡처 기능에 대한 재생 메트릭 보고.

도59은 실시예들에 따른 레퍼런스 구조를 나타낸다.

참조 아키텍처 다이어그램(REFERENCE ARCHITECTURE DIAGRAM):

도29는 reference architecture에 대한 구체적인 구조를 나타낸 것이다.

구조의 기능은 다음과 같다.

콘텐츠 준비(Content preparation)

콘텐츠 인코딩(Content encoding)

Content encoding function 은 bitrate 감소를 위해 source media stream 을 encoded media 로 변환 한다. 단일 source media stream 은 delivery 조건에 맞도록 복수의 서로 다른 encoded representation 으로 변환될 수 있다. Content playback function 이 delivery 조건에 따라 적응적으로 동작할 수 있도록, virtual segment boundary marker 가 encoded representation 에 포함될 수 있다.

Encoder의 출력은 encryption function 또는 packaging function 에 전달되기 적합하도록 포맷 된 cleartext stream 이 될 수 있다. 예를 들어, MPEG elementary stream, MPEG-2 TS, 또는 이와 유사한 목적을 가지는 intermediate format이 될 수 있다.

콘텐츠 암호화(Content encryption)

Content encryption function 은 cleartext stream 을 입력 받아 cipertext stream으로 암호화 한다. Encryption key 는 DRM licence management function으로 부터 획득될 수 있다.

콘텐츠 패키징(Content packaging)

Content packaging function은 하나 이상의 인코딩된 representation을 수집하고 원하는 packaging format에 따라 데이터를 구성한다. Dynamic adaptive streaming에서는 packager의 출력은 동일한 source media stream의 여러 representation에 걸쳐 정렬되어 있는 representation switching point 를 포함하는 packaged media segment의 시퀀스이다. Packaging format은 ISO Base Media File Format (MP4) 와 fragmented MPEG-2 TS 가 될 수 있다.

콘텐츠 호스팅(Content hosting)

Content hosting function은 다음과 같은 경우를 위해 prepared content를 사용가능하도록 준비할 수 있다.

Multicast server로 unicast delivery를 위해 - Oin을 통한 content ingest에 해당함.

Multicast gateway로 A 인터페이스를 통한 unicast repair service를 위해 - A 인터페이스를 통한 cash miss의 경우

Multicast receiver를 통해 연결되지 않은 content playback function을 위해 - B 인터페이스를 통한 전송

Content hosting function은 간단한 웹서버, origin cluster의 일부로 구현되거나, 분산 CDN 등으로 동작할 수 있다. 따라서, load balancing 및 request 분산 기술 (DNS round-robin, HTTP 302 redirect) 등을 사용하여 client를 적합한 content server로부터 content를 수신 할 수 있게 한다.

멀티캐스트 서버(Multicast server)

Multicast server는 content source로 부터 content를 수집한다. 즉, media stream이 Oin 인터페이스로 입력되는데, 일반적으로 media player에 탑재 되는 프로토콜이 사용될 수 있다. Multicast server에서는 수집된 media stream의 payload는 multicast transport protocol 의 delivery 단위로 encapsulation 되어 network를 통해 전송된다. 또한, M 인터페이스를 통해 IP multicast를 이용하여, 가입된 Multicast gateway client로 전송 된다. Network control function로 부터 CMS 인터페이스를 통해 구성정보를 수신 하여 구성될 수 있다.

콘텐츠 수집(Content ingest)

Multicast server에 서는 push 및 pull ingest 방법이 가능하다.

HTTP(S) Pull Ingest via interface Oin:

기존의 adaptive streaming media player 와 유사하며, presentation manifest에 기술된 사항을 바탕으로 packaged media segment를 content hosting function으로 부터 다운로드 한다. 이 경우, 인터페이스 Oin은 세부 operation 특성은 다를 수 있지만, 기능적으로 인터페이스 L 과 동일할 수 있다. Segment는 MPEG-DASH 또는 HLS로 package 될 수 있으며, presentation manifest에서 기술하는 하나 이상의 representation으로 부터 segment가 동시에 다운로드 될 수 있다. DVB-DASH, MPEG-DASH, HLS 등의 manifest format을 지원할 수 있다.

HTTP(S) Push Ingest via interface Pin′

WebDAV (Web Distributed Authoring and Versioning) 와 같은 HTTP(S) push 인터페이스를 제공할 수 있다. Content packaging subfunction은 media segment가 생성되는 즉시 content ingest function에 업로드 한다. Segment는 MPEG-DAH 또는 HLS와 같은 포맷으로 package 될 수 있다.

RTP Push Ingest via interface Pin′

RTP 기반 push ingest 메카니즘을 content packaging subfucntion 에 제공한다. Packager는 MPEG-2 TS 패킷을 RTP로 보낸다. Segment의 boundary는 virtual segment boundary marker를 이용해 표시 될 수 있다.

멀티캐스트 전송(Multicast transmission)

Content ingest subfunction에 의해 수신된 stream을 M 인터페이스를 통해 IP multicast packet의 payload로 전송한다.

유니캐스트 수리 서비스(Unicast repair service)

Unicast repair service는 U 레퍼런스 포인트를 통해 multicast gateway내부의 unicast repair client 로 payload repair function을 제공한다. 다음과 같은 repair mode를 고려할 수 있다.

Unicast repair service는 reference point M을 통해 전송되는 multicast content 를 수신 하며, Unicast repair client의 복구 요청을 충족시키기 위해 packet stream의 복사본을 로컬로 캐시 한다.

요청된 packet이 Unicast repair service의 cache로부터 만족되지 못하면, packet repair 요청은 U' 인터페이스를 통해 multicast server로 전달될 수 있다.

unicast repair service는 레퍼런스 포인트 A와 동일한 인터페이스를 이용해 packet repair 요청을 content hosting function에 대한 HTTP request로 변환될 수 있다.

여러 Multicast gateway로부터 동일한 repair 요청이 수신되는 경우 레퍼런스 포인트 M을 통해 repair packet 을 전송하는 것이 효율적일 수 있다.

멀티캐스트 게이트웨이(Multicast gateway)

Multicast Gateway의 주요한 목적은 패키징된 content segment를 Content Playback function에 전달하는 것이다. Multicast Gateway는 forward proxy 또는 reverse proxy를 포함하는 local origin으로 구현 될 수 있다. Multicast Gatewa는 홈 게이트웨이 장치 또는 IP 연결 set-top box (STB)와 같은 사용자의 구내 장비로 구체화 될 수 있다. 또한 사용자 구내 장비 대신 upstream network node에 위치 할 수 있다.

Content Playback function의 하나 이상의 instance로 부터 L인터페이스를 통해 content 요청이 수신되고, 요청되는 content 는 Asset storage subfunction에 cache 되어 있는 content가 직접 서비스 되거나, A 인터페이스를 통해 획득된 content가 간접적으로 서비스 된다. 이때 A 인터페이스를 통해 획득된 content는 선택적으로 Asset storage subfunction에 캐시 될 수 있다.

서비스 관리(Service management)

Service management subfunction은 M 인터페이스를 통해 수신 가능한 multicast content stream에 대한 서비스 구성 정보 및 Service reporting capture function의 위치 정보를 수집할 수 있다. 이러한 정보는 다음과 같이 수신 할 수 있다.

Network control function 으로 부터 CMR 인터페이스를 통해 직접 수신

Multicast reception subfunction 으로 부터 간접적으로 수신 (해당 정보가 M 인터페이스를 통해 전송된 경우)

Content hosting function 으로 부터 A 인터페이스를 통해 전달된 unicast response를 통해 수신

멀티캐스트 수신(Multicast reception)

Multicast reception subfunction은 M 인터페이스를 통해 end device 에서 요청 되었거나, end device를 위해 구성된 content stream을 전달받는다. 오류없이 정상적으로 수신 된 content는 추후 해당 content를 사용 할 수 있도록, Asset storage 내에 캐시 될 수 있다. 전송 도중 손상된 content는 Multicast gateway가 캐시 하기 전에 특정한 기법 (e.g. Forward Error Correction, unicast repair by the Unicast repair client via U or unicast retrieval via A) 을 사용하여 복구 될 수 있다. 복구되지 않은 content는 L 인터페이스를 통해 전달되지 않는다.

유니캐스트 복구 클라이언트(Unicast repair client)

Multicast packet loss 감지가 수행되고, M 인터페이스를 통해 수신된 Forward Error Correction 정보를 이용하거나, U 인터페이스를 통한 Unicast repair service (e.g. unicast packet retransmission or multicast segment loss signaling)를 이용하여 복구된다. 이러한 방법으로 복구되지 않은 packet의 경우 인터페이스 A를 통한 unicast 전송을 이용할 수 있다.

자산 저장(Asset storage)

Asset storage subfunction은 L 인터페이스를 통해 제공될 정보를 일시적으로 저장하는 기능을 제공한다. 저장 기능은 multicast gateway에 의해서만 수행된다.

Managed pre-positioned media content assets. 예를 들어, 다수의 user에 인기있는 content나 광고관련 정보의 전부 또는 일부를 실제 사용 되기 전 미리 저장할 수 있음.

Linear media content segment에 대한 임시 cache

서비스 보고(Service reporting)

Service-related metrics (e.g. telemetry and analytics data)은 Service reporting subfunction 에 의해 RS인터페이스를 통해 Service reporting capture subfunction에 report됨.

프로비저닝(Provisioning)

Provisioning function 의 목적은 다음과 같다

배포된 멀티캐스트 게이트웨이 인스턴스에서 중앙 집중식으로 서비스 보고 정보를 수집한다. 네트워크에서 리소스를 구성한다. 구성된 네트워크 리소스를 사용하도록 멀티캐스트 서버를 구성한다. 구성된 네트워크 리소스를 사용하도록 멀티캐스트 게이트웨이를 구성한다.

The Provisioning function 은 CCP 인터페이스를 통해 전달되는 정보를 바탕으로 Content Provider control function 와 연동될 수 있다.

서비스 보고 캡처(Service reporting capture)

Multicast gateway에서 수집된 Service reporting정보는 RS인터페이스를 통해 Service reporting capture function 에 제공될 수 있다. Report에는 metric과 서비스의 성능을 알려 주는 주요 indicator (e.g. cache hit-ratio, viewership)등이 포함될 수 있다. Metric은 어떤 channel 이 요청되었는지, 언제 channel이 설정되었는지, 얼마나 많은 segment가 캐시 되었는지에 따라 달라질 수 있다. Service reporting 정보는 서비스 성능 향상이나 multicast channel을 구성하는데 사용 될 수 있다.

Service reporting capture function은 RCP 인터페이스를 통해 Content Provider metrics reporting capture function으로 service reporting정보를 내보낼 수 있다. Multicast content와 bitrate 등의 정보가 해당 reporting 정보에 포함될 수 있다.

네트워크 제어(Network control)

Network control function은 network resource에 대한 제어, 구성, 할당 등의 기능을 수행할 수 있다. 여기에서는 M 인터페이스에서의 multicast 전송 및 U, A 인터페이스에서의 unicast operation에 대한 resource를 포함할 수 있다.

중앙집중식 시스템에서, Network control function은 전송 가능한 multicast stream 에 대한 configuration 정보를 Network 자원에 배포할 수 있으며, 추가로 이러한 configuration정보를 CMS 인터페이스를 통해 Multicast server로 보내거나 CMR 인터페이스를 통해 Multicast gateway로 보낼 수 있다. 전송 가능한 multicast stream 에 대한 configuration 정보는 Content Provider의 제어 정책 또는 client의 요청의 수에 따라 update 될 수 있다.

콘텐츠 제공자 제어(Content Provider control)

Content Provider control function은 CCP 인터페이스를 통해 Network control function이 multicast delivery path M을 통해 가능한 서비스에 대한 정보를 제공할 수 있도록 한다. 단일 Content Provider control function은 서로 다른 network provider가 운영하고 있는 복수의 Network Control function과 상호 동작할 수 있다.

콘텐츠 재생(Content playback)

Content playback function은 content의 요청, 수신, decryption, presentation 등을 관리하는 function이다. 인터페이스 L을 통해 unicast 전송만 지원 한다. Playback은 content가 전달되는 전송 경로와 무관하게 동작한다.

Content playback function은 스마트폰과 같은 end device에서 Multicast gateway 와 별도로 위치할 수 있다. 또는 set-top box나 connected TV 등에서 Multicast gateway와 결합될 수 있다.

Content playback function의 추가 기능은 다음과 같다.

인터페이스 B를 통해 linear service에 대한 presentation manifest를 검색

인터페이스 B를 통해 Multicast gateway를 통해 검색되지 않는 모든 contents에 대한 검색

콘텐츠 언패킹(Content unpackaging)

Content unpackaging subfunction은 획득된 transport object로 부터 elementary stream 데이터를 추출 하여 이를 Content decryption 및 Content decoding subfunction에 제공 할 수 있다. 예를 들어 ISO Base Media File Format 세그먼트의 경우 적절한 media data box를 추출하며, MPEG-2 TS의 경우 원하는 PID가 필터링 되고 재조합 된 PES 패킷의 페이로드가 추출된다.

콘텐츠 복호화(Content decryption)

만약 DRM (Digital Rights Management) 시스템이 동작중인 경우, Content decryption subfunction 은 적합한 DRM licence management function 으로 부터 decryption key를 얻고 encrypted elementary stream을 decryption한다.

콘텐츠 디코딩(Content decoding)

Content decoding subfunction은 elementary media stream의 contents를 읽고 해석하여 screen이나 loudspeaker에서의 재생을 위한 rendering이 가능하도록 한다.

재생 측정항목 보고(Playback metrics reporting)

Playback metrics reporting subfunction은 RPM 인터페이스를 통해 Content Provider metrics reporting capture function에 content playback 의 작동 및 품질과 관련한 정보등을 보고할 수 있다. Metric에는 HTTP request/response, 초기 재생 delay, 버퍼 레벨, presentation switching 이벤트, network throughput 등이 포함될 수 있다. 보고되는 playback metric은 end user의 QoE에 직접적으로 관련 있으며, Content Provider나 Network에서 품질을 최적화 하는데 사용 될 수 있다.

멀티캐스트 랑데부 서비스(Multicast rendezvous service)

Multicast rendezvous service는 복수의 Multicast gateway instance 에 대한 data 레코드를 관리한다 (현재 multicast gateway의 상태, multicast session의 상태 및 관련 data 등). Network control function은 이러한 관련 정보를 Multicast rendezvous service에 제공할 수 있다.

Multicast rendezvous service는 Content playback function 으로 부터 reference point B를 통해 오는 presentation manifest에 대한 초기 요청을 처리한다. Multicast rendezvous service는 요청된 presentation manifest 에 해당하는 linear service에 대한 active multicast session 이 있는지 결정한다. 또한, 해당 요청에 대해 Content playback function 의해 사용될 적합한 active Multicast gateway 가 있는지 결정한다.

만약 두번째 조건이 만족하면, Multicast rendezvous service는 해당 요청을 Multicast gateway에 redirection 할 수 있다. 그렇지 않으면, Multicast rendezvous service는 해당 요청을 Content hosting function으로 redirection 하게 되며, 이때, 해당 session은 unicast 로 동작하게 된다.

DRM 라이선스 관리(DRM licence management)

DRM licence management function 은 core content 보호를 위해, Content encryption function 에 의해 사용되는 적절한 encryption key를 제공하고, Content playback function 이 보호된 content를 decryption할 수 있도록 Content decryption subfunction 에 licence를 공급한다.

애플리케이션(Application)

Application은 Content playback function을 제어한다. 예를 들어, TV 나 set-top box 의 내장 control application (EPG application)또는 Content Provider가 제공하는 third-party application 이 될 수 있다. Application이 Content playback을 제어하는데 사용하는 인터페이스는 일반적으로 개별 linear service의 playback을 개시하기 위한 presentation manifest (e.g. MPEG DASH MPD의 URL) 의 참조점을 전달하는 것이 포함된다. Application은 존재하는 linear service를 발견하고 Multicast gateway에 의한 수신을 제어하기 위해 Multicast gateway의 Service management subfunction과 상호 동작할 수 있다. Application은 application-specific Service directory function과 개별적인 상호 동작을 통해 linear service의 존재를 발견 할 수도 있다.

서비스 디렉토리(Service directory)

Application은 사용 가능한 linear service를 찾기 위해 private service directory를 사용 할 수 있다. Service directory function은 Content provider control function에 의해 구성될 수 있다.

도60은 실시예들에 따른 멀티캐스트 게이트웨이 배치 모델을 나타낸다.

앞서 기술한 Multicast ABR architecture에서 Multicast gateway 의 기능은 network 내에서 다양한 node에 구현될 수 있다. 도60은 네트워크 에지 장치에 배포된 멀티캐스트 게이트웨이를 도시한다.

Multicast gateway가 network edge device 내에 구현 되는 경우, terminal device는 home network 로 부터 IP multicast 수신을 지원하지 않는다. Terminal device 에는 Content playback function이 포함되고, linear playback을 제어하는 Application이 설치 된다.

Multicast gateway 는 복수의 Home gateway device에 multicast-to-unicast conversion 기능을 제공한다. 따라서 network edge device 와 home gateway device 사이의 access network 에서의 traffic은 unicast가 된다.

도61는 실시예들에 따른 홈 게이트웨이 장치에 배포된 멀티캐스트 게이트웨이 구조를 나타낸다.

Multicast gateway는 ISP (Internet Service Provider)에 의해 주로 공급되는 router와 같은 home gateway device 내에 구현된다. 또한, Multicast gateway는 동일 home network 내 복수의 terminal device에 multicast-to-unicast conversion 기능을 제공한다. 이러한 terminal device는 각각 Content playback function 의 instance를 가지며, 이와 관련한 Application이 설치되어 있다.

도62는 실시예들에 따른 단말 장치에 배포된 멀티캐스트 게이트웨이 구조를 나타낸다.

Multicast gateway가 terminal device 내에 구현 되는 경우, terminal device는 home network 내에서 IP multicast 수신을 지원 한다. 각각의 terminal device는 Multicast gateway와 Content playback function 둘 다 포함하고, linear playback 을 제어하기 위한 Application이 설치 된다. 이러한 구현 모델에 대해서, Multicast gateway function은 해당 host terminal device에만 content service를 제공하여야 한다.

Home gateway device는 multicast group 가입과 관련 동작만 수행할 수 있다. 이러한 동작은 home network가 완전한 multicast delivery를 지원하지 않을 때, 예측 불가능한 품질 변화가 일어날 수 있다.

도63은 실시예들에 따른 하이브리드 방송 수신 장치를 나타낸다.

실시예들에 따른 수신 장치는 도63과 같이 표현될 수 있다. 실시예들에 따른 수신 장치의 각 구성요소는 하드웨어, 소프트웨어, 프로세서 및/또는 그것들의 조합에 대응할 수 있다.

각 약어의 정의는 다음과 같다: 5GC: 5G Core Network, 5GMS: 5G Media Streaming, 5GMSd: 5G Media Streaming downlink, 5GMSu: 5G Media Streaming uplink, 5GS: 5G Systems, AF: Application Function, ABR: Adaptive Bit Rate, AMF: Access and Mobility Function, API: Application Programming Interface, App: Application, AS: Application Server, CAPIF: Common API Framework, CDN: Content Delivery Network, DASH: Dynamic and Adaptive Streaming over HTTP, DN: Data Network, DNAI: Data Network Application Identifier, DNN: Data Network Name, DRM: Digital Rights Management, EPC: Evolved Packet Core, EPS: Evolved Packet System, EUTRAN: Evolved Universal Terrestrial Radio Access Network, FLUS: Framework for Live Uplink Streaming, FQDN: Fully-Qualified Domain Name, GPU: Graphics Processing Unit, GSM: Global System for Mobile communication, HPLMN: Home Public Land Mobile Network, HTTP: HyperText Transfer Protocol, HTTPS: HyperText Transfer Protocol Secure, LTE: Long-Term Evolution, MBMS: Multimedia Broadcast Multicast System, MNO: Mobile Network Operator, MPD: Media Presentation Description, MSISDN: Mobile Station International Subscriber Directory Number, NA: Network Assistance, NEF: Network Exposure Function, NR: New Radio, NSMF: Network Slice Management Function, NSSAI: Network Slice Selection Assistance Information, NSSP: Network Slice Selection Policy, OAM: Operations, Administration and Maintenance, OTT: Over-The-Top, PCC: Policy and Charging Control, PCF: Policy and Charging Function, PDU: Packet Data Unit, PSS: Packet-switched Streaming Service, RAN: Radio Access Network, SBA: Service based Architecture, SLA: Service Level Agreement, TCP: Transmission Control Protocol, URL: Unique Resource Identifier, URSP: UE Route Selection Policy, AAC: Advanced Audio Coding, ABR: Adaptive Bit Rate, API: Application Programmer's Interface, BMFF: Base Media File Format, CDN: Content Delivery(Distribution) Networ, CMAF: Common Media Application Format, CP: Content Provider, DASH: Dynamic Adaptive Streaming over HTTP, DNS: Domain Name System, DRM: Digital Rights Management, EPG: Electronic Programme Guide, IGMP: Internet Group Management Protocol. IP: Internet Protocol, ISO: International Organization for Standardization, HLS: HTTP Live Streaming, HTTP: HyperText Transfer Protocol, HTTPS: Secure HyperText Transfer Protocol, MBMS: Multimedia Broadcast Multicast Services (pertaining to 3GPP), MPD Media Presentation Description (pertaining to MPEG-DASH), MPEG: Moving Pictures Experts Group, OTT: Over The Top, PID: Packet Identifier (pertaining to MPEG-2 Transport Stream), RTCP: RTP Control Protocol, RTP: Real-time Transport Protocol, STB: Set-Top Box , TCP: Transmission Control Protocol, UDP: User Datagram Protocol, URL: Uniform Resource Locator (pertaining to HTTP).

상술한 실시예들에 따른 장치는 실시예들에 따른 동작/구성 및/또는 시그널링 정보에 기초하여, 방송 및 multicast 전송에 있어서 다양한 network 를 효율적으로 활용할 수 있는 효과가 있다.

나아가, 상술한 실시예들에 따른 방법/장치는 다양한 네트워크 및/또는 디바이스와 연계하여, 다양한 스트리밍 세션에서 네트워크의 부하를 감소시키고, 구현 비용을 감소시키고, ABR Multicast service를 효율적으로 제공할 수 있는 효과가 있다. 이러한 효과를 제공하기 위해서, 실시예들에 따른 architecture 및 flow가 요구된다.

한편, 본 문서에서 설명하는 실시예들에 따른 동작은 실시예들에 따라서 메모리 및/또는 프로세서를 포함하는 송수신 장치에 의해 수행될 수 있다. 메모리는 실시예들에 따른 동작을 처리/제어하기 위한 프로그램들을 저장할 수 있고, 프로세서는 본 문서에서 설명한 다양한 동작을 제어할 수 있다. 프로세서는 컨트롤러 등으로 지칭 가능하다. 실시예들에 동작들은 펌웨어, 소프트웨어, 및/또는 그것들의 조합에 의해 수행될 수 있고, 펌웨어, 소프트웨어, 및/또는 그것들의 조합은 프로세서에 저장되거나 메모리에 저장될 수 있다.

도64는 실시예들에 따른 멀티캐스트 GSE 레이어 구조를 나타낸다.

실시예들에 따른 방법 장치는 네이티브 IP 시스템을 위한 GSE 레이어 구조를 통해 멀티캐스트 신호를 처리할 수 있다.

실시예들에 따른 GSE 레이어 구조는 상위 레이어(upper layer), GSE layer, 피지컬 레이어를 포함할 수 있다.

상위 레이어는 데이터를 처리하여 GSE 레이어로 전달할 수 있다. GSE레이어는 상위 레이어로부터 IP 스트림을 수신할 수 있다.

GSE레이어는 상위 레이어로부터 수신한 스트림을 GSE 스트림으로 생성할 수 있다. GSE레이어는 복수의 GSE스트림들을 생성할 수 있다. GSE 스트림 생성 과정은 IP헤더 컴프레션, GSE-LLC 디스크립터 생성, GSE-LLC 인캡슐레이션, 헤더 압축된 ROHC 스트림의 인캡슐레이션, 헤더 압축되지 않은 IP스트림의 인캡슐레이션 등을 포함할 수 있다.

상위 레이어로부터 IP데이터를 수신하여, IP 헤더를 압축할 수 있고, IP헤더를 압축하지 않을 수 있다. IP헤더를 압축하는 경우 ROHC 방식에 기초하여 헤더를 압축하고, 헤더 압축에 관한 ROHC-U 디스크립터를 생성할 수 있다. ROHC-U 디스크립터는 GSE-LLC 디스크립터와 함께 인캡슐레이션되어 피지컬 레이어로 전달될 수 있다. ROHC압축된 스트림은 CID 0내지 MAX값을 가질 수 있다. IP헤더 압축은 IP어드레스 정보 및/또는 포트 넘버에 기반하여 수행될 수 있다.

GSE스트림은 피지컬 레이어의 PLP에 의해 전달될 수 있다. PLP ID를 가지는 PLP에 의해 GSE스트림이 전달된다.

도65는 실시예들에 따른 DVB-GSE ROHC 프로파일 및 DVB-GSE 헤더 컴프레서를 나타낸다.

GSE-ROHC(102 606-3)

실시예들에 따른 방법/장치는 NIP (DVB Native IP) 규격에 따른 ROHC 압축을 수행할 수 있다. 헤더 컴프레션은 프로토톨 사용을 재고려하고, UDP/IP 상 ROUTE/FLUTE 프로토톨을 이용할 수 있다. RTP 및 ESP를 사용할 수 있다. 실시예들에 따른 방법/장치는 효율적은 프로토콜 사용을 위해 프로토콜의 타입을 최소화할 수 있다. 도65는 프로파일 식별자에 따라, DVB-GSE를 위한 ROHC 프로파일을 나타낸다.

실시예들에 따른 방법/장치는 멀티플IP스트림을 지원할 수 있다. 수신한 IP스트림의 스태틱 필드 내 변화가 ROHC 컴프레서에 의해 감지되는 경우, ROHC 컴프레서는 컨텍스트 리-이니셜라이제이션)(CONTEXT_REINITIALIZATION)을 수행할 수 있다. CONTEXT ID(CID)의 새로운 값이 압축된 IP스트림에 할당될 수 있다. 새로운 CID값은 시스템에서 유니크할 수 있다. 이 유니크한 값은 시스템 내 다른 ROHC 컴프레서에서 사용되지 않을 수 있다.

DVB-GSE에 따른 ROCH컴프레서 및 디컴프레서는 단방향(unidirectional) 모드 내에서 구동될 수 있다.

도65를 참조하면, 어댑테이션 모드는 ROHC 컴프레서 동작 이후 추가적인 절차에 해당한다. IR패킷으로부터 스태틱 체인을 추출하고, IR패킷을 IR-DYN 패킷으로 변환활 수 있다. 시그널링 데이터는 ROHC 컴프레션 플로우를 통해 전달될 수 있다.

어댑테이션 모드를 적용할지 여부를 선택할 수 있다. 시그널링 데이터의 에러에 강한 전송으로 인해서컨텍스트 정보의 개별적 전송은 멀티플 PLP 구조 내에서 유용할 수 있다. 어댑테이션 모드를 사용하는 것이 유익하지 않은 경우도 있다. 컨텍스트 데이터 및 대응하는 ROHC플로우가 동일한 PLP에 의해 전송되는 경우이다.

ROHC파라미터들이 생성될 수 있다. CID최대값(MAX_CID)의 최대 값은 127일 수 있다. ROHC스트림의 개수가 제한될 수 있다. ROHC헤더 내 CID필드의 사이즈는 1바이트일 수 있다.

도66은 실시예들에 따른 ROHC-U 정보를 나타낸다.

GSE-LLC(102 606-2)

실시예들에 따른 방법/장치는 멀티캐스트 (GSE 스트림) 매핑 디스트립터를 생성할 수 있다. 멀티캐스트 맵핑 디스크립터가 새롭게 요구된다. 종래 디스크립터는 GSE-LLC 에 대해 UDP 포트를 식별하는 방안을 지원할 수 없다. 멀티캐스트-링크ID(GSE스트림ID) 간 맵핑을 제공할 수 있다.

ROHC-U디스크립터는 멀티플 스트림 및 UDP 를 위한 ROHC-U 디스크립터다 도66과 같이 생성될 수 있다. 멀티캐스트-ROHC채널-컨텍스트ID-컨탠스트정보 간 맵핑을 나타낼 수 있다.

실시예들에 따른 ROHC-U디스크립터는 멀티플 IP스트림을 지원할 수 있다.

링크는 수신기 상 가상 네트워크 인터페이스를 나타낸다. 이는 정확히 하나의 IP플로우와 연관될 수 있다. 동일한 데이터 스트림이 하나 이상의 모듈레이션 시스템 스트림 상 이용가능하기 때문에, 링크는 모듈레이션 시스템 타입, 모듈레이션 시스템 ID, 피지컬 스트림ID에 의해 특정되는 모듈레이션 시스템 스트림과 ROHC-U 정보 인스턴스가 연관될 수 있다. 예를 들어, DVB-T2시스템 내 특정 PLP 에 의해 특정될 수 있다. 링크 상 동일한 데이터가 전달되기 때문에, 수신기들은 특정 링크의 인스턴스 간 자유롭게 스위칭을 수행할 수 있다.

IP플로우: 주어진 링크 상 데이터 스트림이 전달도리 수 있다. 동일한 데이터가 다양한 위치로부터 이용 가능하기 때문에, IP플로우는 하나 이상의 링크들과 연관될 수 있다. IP플로우는 파라미터들을 타겟팅하여 기술될 수 있다. 예를 들어, IP 소스 및/또는 목적 어드레스를 기술할 수 있다. ROHC-U 헤더 컴프레션 파라미터들과 같은 오퍼레이션 파라미터들에 의해 IP플로우가 기술될 수 있다. IP플로우 및 링크 간 연결은 링크 아이디에 의해서 성립될 수 있다.

NIP를 위한 ROUC-U정보는 GSE스트림들의 개수를 알 수 있는 PLP개수 정보를 포함한다. ROHC채널 ID에 관련된 PLP ID를 포함한다. ROHC의 채널 파라미터 당 CID맥스 값 및 프로파일을 포함한다. 컨텍스트 ID당 IP스트림 어드레스 정보를 포함하고, ID 스트림 어드레스 정보는 소스 IP어드레스, 목적지 IP어드레스, 소스 포트 정보, 목적지 포트 정보를 포함한다. 컨텍스트 ID 및 IP스트림 어드레스 정보는 서로 매핑된다. 컨텍스트ID당 컨텍스트 정보를 포함한다. 컨텍스트 정보는 스태틱 체인 길이 정보 및 스태틱 체인 바이트 정보를 포함한다.

실시예들은 NIP 특정 링크 레이어 프로토콜, 레이어 아키텍쳐, ROHC 사용을 위한 선택, 링크 레이어 내 부트스트랩핑 절차 등을 더 포함할 수 있다. ROHC가 적용되지 않은 IP스트림은 개별적으로 전달될 수 있다. 전달 옵션은 시그널링 정보를 통해 식별할 수 있다. 부트스트랩핑은 GSE스트림을 수신하고, 요청된 IP/UDP스트림을 필터링할 수 있다.

도67은 실시예들에 따른 송신 장치 및 수신 장치를 나타낸다.

실시예들에 따른 장치는 도67과 같이 NIP트랜스미터 및 MIP리시버 등을 포함할 수 있다.

NIP트랜스미터는 DVB-I 서비스 리스트 서버로부터 DVB-I 서비스 리스트를 수신할 수 있다. IP 패킷을 포함하는 IP스트림을 인캡슐레이션하여 GSE스트림을 PLP에 의해 전송할 수 있다. GSE레이어에 대한 정보를 포함하는 디스크립터 및 ROHC-U 디스크립터 등을 포함하는 LLC 데이터를 생성하여 PLP에 의해 전송할 수 있다.

NIP트랜스미터는 멀티캐스트 서버로부터 ROUTE 세션에 기반하여 IP멀티캐스트들을 수신할 수 있고, 멀티캐스트 게이트웨이 구성 정보를 포함하는 IP스트림을 수신할 수 있다. 실시예들에 따른 IP헤더 압축을 통해 ROHC스트림을 생성할 수 있다.

NIP리시버는 GSE스트림을 수신하고, IP스트림을 파싱할 수 있다. DVB-I클라이언트에 DVB-I서비스 리스트를 전달할 수 있다. IP 스트림을 필터링하고, IP 멀티캐스트, 멀티캐스트 게이트웨이 구성들을 멀티캐스트 게이트웨이에 전달할 수 있다. 멀티캐스트 구성 관련 동작은 MABR의 참조 포인트M 인터페이스에 기반하여 처리될 수 있다.

실시예들에 따른 NIP 스트림은 GSE-Lite 스트림 또는 MPE 스트림과 동일할 수 있다. NIP 스트림은 DVB-NIP 방송 시스템이 전달하는 IP멀티캐스트 데이터를 포함하는 스트림을 지칭하는 용어로 해석된다.

브로드캐스트 채널을 통해 전송되는 멀티캐스트 데이터는 주로 멀티캐스트 서버에 의해 생성되지만 각 NIP 스트림과 관련된 NIP 신호 서버도 생성할 수 있다. 모든 NIP 스트림에는 연결된 단일 멀티캐스트 서버만 있을 수 있다. Multicast Server는 각각 하나 이상의 멀티캐스트 스트림으로 구성된 멀티캐스트 전송 세션을 생성할 수 있다.

도68은 실시예들에 따른 멀티캐스트 송신 방법을 나타낸다.

S6800, 실시예들에 따른 멀티캐스트 송신 방법은 멀티캐스트 서버로부터 인터페이스에 기초하여 멀티캐스트 신호를 송신하는 단계를 포함할 수 있다.

S6810, 실시예들에 따른 멀티캐스트 송신 방법은 멀티캐스트를 위한 정보를 생성하는 단계를 더 포함할 수 있다.

도69는 실시예들에 따른 멀티캐스트 수신 방법을 나타낸다.

S6900, 실시예들에 따른 멀티캐스트 수신 방법은 멀티캐스트 서버로부터 인터페이스에 기초하여, 멀티캐스트 신호를 수신하는 단계를 포함할 수 있다.

S6910, 실시예들에 따른 멀티캐스트 수신 방법은 멀티캐스트 신호에 포함된 멀티캐스트 서비스를 플레이하는 단계를 더 포함할 수 있다.

도68-69에 따른 멀티캐스트 처리 방법은 도1-4 등 도시된 멀티캐스트 ABR 구조 상에서 도5등 도시된 흐름도, 도6-7 등 도시된 멀티캐스트를 위한 정보 등에 기초하여 수행될 수 있다.

도68-69에 따른 멀티캐스트 처리 방법은 도8-10, 54-63 등 도시된 5G 네트워크에 기반하여 멀티캐스트 신호를 처리할 수 있다.

도68-69에 따른 멀티캐스트 처리 방법은 도11- 26등 도시된 복수의 네트워크들에 기반하여 멀티캐스트 신호를 처리할 수 있다.

도68-69에 따른 멀티캐스트 처리 방법은 도27- 32등 도시된 프로토콜 및 구조 상에서 복수의 네트워크들에 기초하여 멀티캐스트 신호를 처리할 수 있다.

도68-69에 따른 멀티캐스트 처리 방법은 도33-36 등 도시된 멀티캐스트를 위한 정보를 생성하여 전달하고, 수신기는 멀티캐스트를 위한 정보에 기반하여 멀티캐스트 미디어 컨텐트를 수신하고 재생할 수 있다.

도68-69에 따른 멀티캐스트 처리 방법은 도37-39 등 도시된 시스템 상에서 멀티캐스트 신호를 생성하여 전달하고 처리할 수 있다.

도68-69에 따른 멀티캐스트 처리 방법은 멀티캐스트 트랜스 포트 세션 내지 피지컬 레이어 간 맵핑 동작을 포함할 수 있다. 이러한 세션 간 맵핑을 통해 멀티캐스트 신호를 처리하기 위해서 도40-41, 47 등 도시된 구조 상 도42-43 프로토콜을 구성하고, 도44-46, 48-49 멀티캐스트를 위한 맵핑 정보 등을 생성하여 송수신한다.

도68-69에 따른 멀티캐스트 처리 방법은 도64의 GSE(링크 레이어) 구조를 통해 멀티캐스트를 처리하고, 도65-66과 같이 상위 레이어의 데이터를 압축하고, 관련된 링크 레이어 시그널링 정보를 생성하여 전달할 수 있다. 또한, 도68-69에 따른 멀티캐스트 처리 방법은 도67과 같이 GSE와 PLP간 관계를 나타내는 정보를 생성하여, 수신 장치가 멀티캐스트 신호를 수신하고 멀티캐스트 미디어 데이터를 재생할 수 있게 한다.

도41 관련하여, 실시예들에 따른 인터페이스는 DVB-NIP 규격의 방송 시스템을 구성할 수 있다. 멀티캐스트 서버로부터 인터페이스에 기초하여, 멀티캐스트 신호를 수신하는 멀티캐스트 게이트웨이; 및 멀티캐스트 신호에 포함된 멀티캐스트 서비스를 플레이하는 컨텐트 플레이백부; 를 포함하는, 멀티캐스트 신호 수신 장치는 네이티브 인터넷 프로토콜에 따라 멀티캐스트 신호를 수신할 수 있다.

도42 관련하여, 실시예들의 인터페이스는 DVB-NIP 프로토콜에 따라 구성된다. 인터페이스는, 멀티캐스트 트렌스포트 세션, UDP/IP(User Datagram Protocol/Internet Protocol), GSE(Generic Stream Encapsulation) 레이어, 피지컬 레이어를 포함하는 프로토콜을 포함할 수 있다.

도48 관련하여, 실시예들은 다음과 같은 시그널링 정보를 생성할 수 있고, 이 정보는 시그널링 정보, 메타데이터, ABR transport session descriptor, IP Multicast List descriptor 등 다양하게 지칭하는 가능하다. GSE 레이어 내 로지컬 레이어 컨트롤(Logical Layer Control, LLC) 정보가 전달되고, 로지컬 레이어 컨트롤(LLC) 정보는, 멀티캐스트 디스크립터를 포함하고, 멀티캐스트 디스크립터는 소스 어드레스 정보, 데스티네이션 어드레스 정보, 소스 UDP 포트 정보, 데스티네이션 UDP 포트 정보를 포함할 수 있다.

도64 관련하여, GSE 레이어는 DVB-NIP를 위해 정의될 수 있다. 실시예들은 GSE레이어로부터 IP헤더 압축된 IP데이터가 인캡슐레이팅된 GSE데이터, IP헤더가 압축되지 않은 IP데이터가 인캡슐레이팅된 GSE데이터, 멀티캐스트에 대한 디스크립터, 및 IP헤더 압축에 관련된 ROHC(Robust Header Compression) 디스크립터를 포함하는 GSE스트림을 전달하는 PLP(Physical Layer Pipe)를 수신할 수 있다.

도44 관련하여, DVB-NIP를 위한 LLC 테이블을 정의할 수 있다. 실시예들은GSE레이어로부터 로지컬 링크 컨트롤(Logical Link Control, LLC) 정보를 수신하고, 로지컬 링크 컨트롤 정보는, 네트워크 컨트롤 데이터(Network Control Data, NCD) 및 링크 컨트롤 데이터(Link Control Data, LCD)를 포함할 수 있다. 또한, 네트워크 컨트롤 데이터(NCD)는 멀티캐스트를 위한 디스크립터를 포함하고, 링크 컨트롤 데이터(LCD)는 피지컬 레이어를 위한 링크 식별자를 포함하여, 세션 간 맵핑을 나타내고 멀티캐스트 미디어를 수신할 수 있다.

도67 관련하여, 실시예들은 로지컬 링크 컨트롤(LLC) 정보를 파싱하는 파서; 및 GSE 레이어의 GSE스트림에 포함된 ROHC(Robust Header Compression) 스트림을 수신하고, IP헤더를 디컴프레스하는 디컴프레서; 를 포함할 수 있다.

실시예들에 따른 수신 방법은 멀티캐스트 서버로부터 인터페이스에 기초하여, 멀티캐스트 신호를 수신하는 단계; 및 멀티캐스트 신호에 포함된 멀티캐스트 서비스를 플레이하는 단계; 를 포함할 수 있다.

실시예들에 따른 송신 방법은 멀티캐스트 서버로부터 인터페이스에 기초하여 멀티캐스트 신호를 송신하는 단계, 인터페이스는, 멀티캐스트 트렌스포트 세션, UDP/IP(User Datagram Protocol/Internet Protocol), GSE(Generic Stream Encapsulation) 레이어, 피지컬 레이어를 포함하는 프로토콜을 포함하고, GSE 레이어 내 로지컬 레이어 컨트롤(Logical Layer Control, LLC) 정보를 생성하는 단계; 를 포함할 수 있다.

이로 인하여, 지상파 방송 및 위성 방송 간 링크 기술이 부재하였고, 멀티캐스트 미디어 전송을 위한 세션 정보 및 인터페이스 구성이 부재한 문제점을 해결할 수 있다. 즉, DVB 표준에서 정의 하고 있는 지상파 방송 및 위성 방송 간 링크와 같은 unidirectional delivery network 에서 DVB ABR multicast의 media object를 전송하기 위해 multicast transport session을 broadcast stream 과 연동시키기 위한 interface 및 signaling flow를 제공할 수 있는 효과가 있다.

실시예들은 방법 및/또는 장치 관점에서 설명되었으며, 방법의 설명 및 장치의 설명은 상호 보완하여 적용될 수 있다.

설명의 편의를 위하여 각 도면을 나누어 설명하였으나, 각 도면에 서술되어 있는 실시 예들을 병합하여 새로운 실시 예를 구현하도록 설계하는 것도 가능하다. 그리고, 통상의 기술자의 필요에 따라, 이전에 설명된 실시 예들을 실행하기 위한 프로그램이 기록되어 있는 컴퓨터에서 판독 가능한 기록 매체를 설계하는 것도 실시예들의 권리범위에 속한다. 실시예들에 따른 장치 및 방법은 상술한 바와 같이 설명된 실시 예들의 구성과 방법이 한정되게 적용될 수 있는 것이 아니라, 실시 예들은 다양한 변형이 이루어질 수 있도록 각 실시 예들의 전부 또는 일부가 선택적으로 조합되어 구성될 수도 있다. 실시예들의 바람직한 실시 예에 대하여 도시하고 설명하였지만, 실시예들은 상술한 특정의 실시 예에 한정되지 아니하며, 청구범위에서 청구하는 실시예들의 요지를 벗어남이 없이 당해 발명이 속하는 기술분야에서 통상의 지식을 가진 자에 의해 다양한 변형실시가 가능한 것은 물론이고, 이러한 변형실시들은 실시예들의 기술적 사상이나 전망으로부터 개별적으로 이해돼서는 안 될 것이다.

실시예들의 장치의 다양한 구성요소들은 하드웨어, 소프트웨어, 펌웨어 또는 그것들의 조합에 의해 수행될 수 있다. 실시예들의 다양한 구성요소들은 하나의 칩, 예를 들면 하나의 하드웨어 서킷으로 구현될 수 있다 실시예들에 따라, 실시예들에 따른 구성요소들은 각각 별도의 칩들로 구현될 수 있다. 실시예들에 따라, 실시예들에 따른 장치의 구성요소들 중 적어도 하나 이상은 하나 또는 그 이상의 프로그램들을 실행 할 수 있는 하나 또는 그 이상의 프로세서들로 구성될 수 있으며, 하나 또는 그 이상의 프로그램들은 실시예들에 따른 동작/방법들 중 어느 하나 또는 그 이상의 동작/방법들을 수행시키거나, 수행시키기 위한 인스트럭션들을 포함할 수 있다. 실시예들에 따른 장치의 방법/동작들을 수행하기 위한 실행 가능한 인스트럭션들은 하나 또는 그 이상의 프로세서들에 의해 실행되기 위해 구성된 일시적이지 않은 CRM 또는 다른 컴퓨터 프로그램 제품들에 저장될 수 있거나, 하나 또는 그 이상의 프로세서들에 의해 실행되기 위해 구성된 일시적인 CRM 또는 다른 컴퓨터 프로그램 제품들에 저장될 수 있다. 또한 실시예들에 따른 메모리는 휘발성 메모리(예를 들면 RAM 등)뿐 만 아니라 비휘발성 메모리, 플래쉬 메모리, PROM등을 전부 포함하는 개념으로 사용될 수 있다. 또한, 인터넷을 통한 전송 등과 같은 캐리어 웨이브의 형태로 구현되는 것도 포함될 수 있다. 또한, 프로세서가 읽을 수 있는 기록매체는 네트워크로 연결된 컴퓨터 시스템에 분산되어, 분산방식으로 프로세서가 읽을 수 있는 코드가 저장되고 실행될 수 있다.

이 문서에서 “/”와 “,”는 “및/또는”으로 해석된다. 예를 들어, “A/B”는 “A 및/또는 B”로 해석되고, “A, B”는 “A 및/또는 B”로 해석된다. 추가적으로, “A/B/C”는 “A, B 및/또는 C 중 적어도 하나”를 의미한다. 또한, “A, B, C”도 “A, B 및/또는 C 중 적어도 하나”를 의미한다. 추가적으로, 이 문서에서 “또는”는 “및/또는”으로 해석된다. 예를 들어, “A 또는 B”은, 1) “A” 만을 의미하고, 2) “B” 만을 의미하거나, 3) “A 및 B”를 의미할 수 있다. 달리 표현하면, 본 문서의 “또는”은 “추가적으로 또는 대체적으로(additionally or alternatively)”를 의미할 수 있다.

제1, 제2 등과 같은 용어는 실시예들의 다양한 구성요소들을 설명하기 위해 사용될 수 있다. 하지만 실시예들에 따른 다양한 구성요소들은 위 용어들에 의해 해석이 제한되어서는 안된다. 이러한 용어는 하나의 구성요소를 다른 구성요소와 구별하기 위해 사?熾幷? 것에 불과하다. 것에 불과하다. 예를 들어, 제1 사용자 인풋 시그널은 제2사용자 인풋 시그널로 지칭될 수 있다. 이와 유사하게, 제2사용자 인풋 시그널은 제1사용자 인풋시그널로 지칭될 수 있다. 이러한 용어의 사용은 다양한 실시예들의 범위 내에서 벗어나지 않는 것으로 해석되어야만 한다. 제1사용자 인풋 시그널 및 제2사용자 인풋 시그널은 모두 사용자 인풋 시그널들이지만, 문맥 상 명확하게 나타내지 않는 한 동일한 사용자 인풋 시그널들을 의미하지 않는다.

실시예들을 설명하기 위해 사용된 용어는 특정 실시예들을 설명하기 위한 목적으로 사용되고, 실시예들을 제한하기 위해서 의도되지 않는다. 실시예들의 설명 및 청구항에서 사용된 바와 같이, 문맥 상 명확하게 지칭하지 않는 한 단수는 복수를 포함하는 것으로 의도된다. 및/또는 표현은 용어 간의 모든 가능한 결합을 포함하는 의미로 사용된다. 포함한다 표현은 특징들, 수들, 단계들, 엘리먼트들, 및/또는 컴포넌트들이 존재하는 것을 설명하고, 추가적인 특징들, 수들, 단계들, 엘리먼트들, 및/또는 컴포넌트들을 포함하지 않는 것을 의미하지 않는다. 실시예들을 설명하기 위해 사용되는, ~인 경우, ~때 등의 조건 표현은 선택적인 경우로만 제한 해석되지 않는다. 특정 조건을 만족하는 때, 특정 조건에 대응하여 관련 동작을 수행하거나, 관련 정의가 해석되도록 의도되었다.

또한, 본 문서에서 설명하는 실시예들에 따른 동작은 실시예들에 따라서 메모리 및/또는 프로세서를 포함하는 송수신 장치에 의해 수행될 수 있다. 메모리는 실시예들에 따른 동작을 처리/제어하기 위한 프로그램들을 저장할 수 있고, 프로세서는 본 문서에서 설명한 다양한 동작을 제어할 수 있다. 프로세서는 컨트롤러 등으로 지칭가능하다. 실시예들에 동작들은 펌웨어, 소프트웨어, 및/또는 그것들의 조합에 의해 수행될 수 있고, 펌웨어, 소프트웨어, 및/또는 그것들의 조합은 프로세서에 저장되거나 메모리에 저장될 수 있다.

한편, 상술한 실시예들에 따른 동작은 실시예들 따른 송신 장치 및/또는 수신 장치에 의해서 수행될 수 있다. 송수신 장치는 미디어 데이터를 송수신하는 송수신부, 실시예들에 따른 프로세스에 대한 인스트럭션(프로그램 코드, 알고리즘, flowchart 및/또는 데이터)을 저장하는 메모리, 송/수신 장치의 동작들을 제어하는 프로세서를 포함할 수 있다.

프로세서는 컨트롤러 등으로 지칭될 수 있고, 예를 들어, 하드웨어, 소프트웨어, 및/또는 그것들의 조합에 대응할 수 있다. 상술한 실시예들에 따른 동작은 프로세서에 의해 수행될 수 있다. 또한, 프로세서는 상술한 실시예들의 동작을 위한 인코더/디코더 등으로 구현될 수 있다.

발명의 실시를 위한 형태

상술한 바와 같이, 실시예들을 실시하기 위한 최선의 형태에서 관련 내용을 설명하였다.

상술한 바와 같이, 실시예들은 포인트 클라우드 데이터 송수신 장치 및 시스템에 전체적 또는 부분적으로 적용될 수 있다.

당업자는 실시예들의 범위 내에서 실시예들을 다양하게 변경 또는 변형할 수 있다.

실시예들은 변경/변형들을 포함할 수 있고, 변경/변형은 청구항들 및 그 와 동일한 것들의 범위를 벗어나지 않는다.

Claims (13)

1. 멀티캐스트 서버로부터 인터페이스에 기초하여, 멀티캐스트 신호를 수신하는 멀티캐스트 게이트웨이; 및
   상기 멀티캐스트 신호에 포함된 멀티캐스트 서비스를 플레이하는 컨텐트 플레이백부; 를 포함하는,
   멀티캐스트 신호 수신 장치.
2. 제1항에 있어서,
   상기 인터페이스는, 멀티캐스트 트렌스포트 세션, UDP/IP(User Datagram Protocol/Internet Protocol), GSE(Generic Stream Encapsulation) 레이어, 피지컬 레이어를 포함하는 프로토콜을 포함하는,
   멀티캐스트 신호 수신 장치.
3. 제2항에 있어서, 상기 GSE 레이어 내 로지컬 레이어 컨트롤(Logical Layer Control, LLC) 정보가 전달되고,
   상기 로지컬 레이어 컨트롤(LLC) 정보는, 멀티캐스트 디스크립터를 포함하고,
   상기 멀티캐스트 디스크립터는 소스 어드레스 정보, 데스티네이션 어드레스 정보, 소스 UDP 포트 정보, 데스티네이션 UDP 포트 정보를 포함하는,
   멀티캐스트 신호 수신 장치.
4. 제2항에 있어서, 상기 장치는,
   상기 GSE레이어로부터 IP헤더 압축된 IP데이터가 인캡슐레이팅된 GSE데이터, IP헤더가 압축되지 않은 IP데이터가 인캡슐레이팅된 GSE데이터, 멀티캐스트에 대한 디스크립터, 및 IP헤더 압축에 관련된 ROHC(Robust Header Compression) 디스크립터를 포함하는 GSE스트림을 전달하는 PLP(Physical Layer Pipe)를 수신하는,
   멀티캐스트 신호 수신 장치.
5. 제2항에 있어서, 상기 장치는,
   상기 GSE레이어로부터 로지컬 링크 컨트롤(Logical Link Control, LLC) 정보를 수신하고,
   상기 로지컬 링크 컨트롤 정보는, 네트워크 컨트롤 데이터(Network Control Data, NCD) 및 링크 컨트롤 데이터(Link Control Data, LCD)를 포함하고,
   상기 네트워크 컨트롤 데이터(NCD)는 멀티캐스트를 위한 디스크립터를 포함하고,
   상기 링크 컨트롤 데이터(LCD)는 피지컬 레이어를 위한 링크 식별자를 포함하는,
   멀티캐스트 신호 수신 장치.
6. 제5항에 있어서, 상기 장치는,
   상기 로지컬 링크 컨트롤(LLC) 정보를 파싱하는 파서; 및
   상기 GSE 레이어의 GSE스트림에 포함된 ROHC(Robust Header Compression) 스트림을 수신하고, IP헤더를 디컴프레스하는 디컴프레서; 를 포함하는,
   멀티캐스트 신호 수신 장치.
7. 멀티캐스트 서버로부터 인터페이스에 기초하여, 멀티캐스트 신호를 수신하는 단계; 및
   상기 멀티캐스트 신호에 포함된 멀티캐스트 서비스를 플레이하는 단계; 를 포함하는,
   멀티캐스트 신호 수신 방법.
8. 제7항에 있어서,
   상기 인터페이스는, 멀티캐스트 트렌스포트 세션, UDP/IP(User Datagram Protocol/Internet Protocol), GSE(Generic Stream Encapsulation) 레이어, 피지컬 레이어를 포함하는 프로토콜을 포함하는,
   멀티캐스트 신호 수신 방법.
9. 제8항에 있어서, 상기 GSE 레이어 내 로지컬 레이어 컨트롤(Logical Layer Control, LLC) 정보가 전달되고,
   상기 로지컬 레이어 컨트롤(LLC) 정보는, 멀티캐스트 디스크립터를 포함하고,
   상기 멀티캐스트 디스크립터는 소스 어드레스 정보, 데스티네이션 어드레스 정보, 소스 UDP 포트 정보, 데스티네이션 UDP 포트 정보를 포함하는,
   멀티캐스트 신호 수신 방법.
10. 제8항에 있어서, 상기 방법은,
    상기 GSE레이어로부터 IP헤더 압축된 IP데이터가 인캡슐레이팅된 GSE데이터, IP헤더가 압축되지 않은 IP데이터가 인캡슐레이팅된 GSE데이터, 멀티캐스트에 대한 디스크립터, 및 IP헤더 압축에 관련된 ROHC(Robust Header Compression) 디스크립터를 포함하는 GSE스트림을 전달하는 PLP(Physical Layer Pipe)를 수신하는,
    멀티캐스트 신호 수신 방법.
11. 제9항에 있어서, 상기 방법은
    상기 GSE레이어로부터 IP헤더 압축된 IP데이터가 인캡슐레이팅된 GSE데이터, IP헤더가 압축되지 않은 IP데이터가 인캡슐레이팅된 GSE데이터, 멀티캐스트에 대한 디스크립터, 및 IP헤더 압축에 관련된 ROHC(Robust Header Compression) 디스크립터를 포함하는 GSE스트림을 전달하는 PLP(Physical Layer Pipe)를 수신하는,
    멀티캐스트 신호 수신 방법.
12. 제11항에 있어서, 상기 방법은,
    상기 로지컬 링크 컨트롤(LLC) 정보를 파싱하는 단계; 및
    상기 GSE 레이어의 GSE스트림에 포함된 ROHC(Robust Header Compression) 스트림을 수신하고, IP헤더를 디컴프레스하는 단계; 를 포함하는,
    멀티캐스트 신호 수신 방법.
13. 멀티캐스트 서버로부터 인터페이스에 기초하여 멀티캐스트 신호를 송신하는 단계,
    상기 인터페이스는, 멀티캐스트 트렌스포트 세션, UDP/IP(User Datagram Protocol/Internet Protocol), GSE(Generic Stream Encapsulation) 레이어, 피지컬 레이어를 포함하는 프로토콜을 포함함; 및
    상기 GSE 레이어 내 로지컬 레이어 컨트롤(Logical Layer Control, LLC) 정보를 생성하는 단계; 를 포함하는
    멀티캐스트 신호 송신 방법.

Images