KR102381335B1

KR102381335B1 - 모바일 사용자 장치들에 컨텐츠를 전송하는 방법

Info

Publication number: KR102381335B1
Application number: KR1020197014302A
Authority: KR
Inventors: 로망 라오르-까라떼; 튀안 트랑 타이; 크리스토프 뷔르디낫; 세드릭 티에노
Original assignee: 이엑스피웨이
Priority date: 2016-10-18
Filing date: 2017-10-18
Publication date: 2022-03-31
Also published as: EP3529972A1; US20190273769A1; CN109964471A; KR20190066060A; US11165841B2; WO2018073317A1; CN109964471B; EP3529972B1

Abstract

본 발명은 사용자 단말로부터 컨텐츠를 전달하는 서비스에 액세스하는 방법에 관한 것으로, 이 방법은: 상기 사용자 단말의 클라이언트 모듈(MBMC)로 URL(Uniform Resource Locator)을 전송하는 단계로서, 상기 URL은 요청된 컨텐츠(CNT)의 식별자 및 상기 요청된 컨텐츠의 사용자 단말(UM)로의 전달과 관련된 요청 또는 조건을 지정하는 명령을 포함하는, 상기 URL을 전송하는 단계, 상기 요청된 컨텐츠가 지정된 조건에 따라 사용자 단말에서 가용한 경우, 상기 클라이언트 모듈로부터 상기 요청된 컨텐츠(CNT)를 수신하는 단계, 및 상기 요청된 컨텐츠가 지정된 조건에 따라 사용자 단말에서 가용하지 않는 경우, 상기 URL을 서비스 브로드캐스트 서버(BMS)로 전송하는 단계를 포함한다.

Description

모바일 사용자 장치들에 컨텐츠를 전송하는 방법

본 발명의 양태들은 무선 통신 네트워크들을 통해 사용자 장치들에 다양한 포맷들의 컨텐츠를 전송하기 위한 방법 및 장치에 관련될 수 있다.

무선 통신 네트워크들은 음성, 비디오, 패킷 데이터, 메시징, 브로드캐스트 등과 같은 다양한 통신 서비스들을 제공하기 위해 널리 사용된다. 이러한 무선 네트워크들은 일반적으로 가용한 네트워크 리소스들을 공유함으로써 다수의 사용자들을 지원할 수 있는 다중-액세스 네트워크들이다.

무선 통신 네트워크는 모바일 엔티티들이라고도 지칭되는 다수의 사용자 장치들에 대한 통신을 지원할 수 있는 다수의 기지국들을 포함할 수 있다. 사용자 장치는 다운링크 및 업링크를 통해 기지국과 통신할 수 있다. 다운링크(또는 순방향 링크)는 기지국으로부터 사용자 장비로의 통신 링크를 지칭하고, 업링크(또는 역방향 링크)는 사용자 장비로부터 기지국으로의 통신 링크를 지칭한다.

3GPP(third Generation Partnership Project) LTE(Long Term Evolution)는, GSM(Global System for Mobile communications) 및 UMTS(Universal Mobile Telecommunications System)의 진화로서의 셀룰러 기술의 주요 진보를 나타낸다. LTE 물리 계층(PHY)은 기지국들과 모바일 엔티티들 간에 데이터 및 제어 정보 모두를 전달하는 매우 효율적인 방법을 제공한다. 종래 출원들에서, 멀티미디어에 대한 고 대역폭 통신을 용이하게 하는 방법은 브로드캐스트를 위한 단일 주파수 네트워크(single frequency network)(SFN) 동작이었다. SFN들은 예를 들어, 기지국들 내에 있는 것들과 같은 무선 송신기들을 이용하여 가입자 장치들과 통신한다. 유니캐스트 동작에서, 각각의 기지국은 하나 이상의 특정 가입자 장치로 향하는 정보를 전달하는 신호들을 송신하도록 제어된다.

브로드캐스트 동작에서, 브로드캐스트 영역 내의 몇몇 기지국들은 브로드캐스트 영역 내의 임의의 가입자 장치에 의해 수신되고 액세스될 수 있는 정보를 전달하는, 신호들을 동기화된 방식으로, 브로드캐스트할 수 있다. 브로드캐스트 동작의 대다수는 이벤트-관련 멀티미디어 브로드캐스트들과 같이 일반 대중이 관심있는 정보를 전송할 때 유니캐스트 서비스보다 더 큰 효율성을 제공한다. 이벤트-관련 멀티미디어 및 기타 브로드캐스트 서비스들에 대한 수요 및 시스템 기능이 증가함에 따라 시스템 운영자들은 3GPP 네트워크들에서 브로드캐스트 동작을 사용하는 데 점점 더 많은 관심을 보이고 있다.

비디오 컨텐츠와 같은 컨텐츠의 전송은 통신 네트워크들의 다양한 방법들에 의해 수행될 수 있다. 예를 들어, 비디오 컨텐츠의 경우, 비디오 소스로부터 디스플레이로의 비디오 정보의 전송은 유니캐스트 전송들 또는 멀티캐스트/브로드캐스트 전송들을 통해 이루어질 수 있다. 유니캐스트 전송들은 특별히 대상화된 수신 장치로 전송된다. 유니캐스트 전송을 얻으려면 대상 장치에 비디오 소스의 주소가 있는 Uniform Resource Locator(URL)이 있을 수 있으며, 비디오 파일의 다운로드를 용이하게 하기 위해 비디오 소스(일반적으로 서버)에 전송할 수 있는 Hyper Text Transfer Protocol(HTTP) GET 명령을 생성할 수 있다.

유니캐스트 환경에서 비디오를 전송하는 공지된 방법은 Dynamic Adaptive Streaming over HTTP (DASH)를 통한 것이다. 유니캐스트에서 DASH를 사용하면 전체 파일을 획득한다. DASH는 비디오 파일을 DASH 세그먼트들이라는 더 작은 구성요소들로 변환할 수 있으며, DASH 세그먼트들은 수신 장치에서 재집합(reassembled)되어 원하는 비디오를 디스플레이할 수 있다. 또 다른 방법은 HTTP Live Streaming(HLS)이며, DASH와 동일한 메커니즘을 따른다.

진화된-멀티미디어 브로드캐스트/멀티캐스트 서비스(eMBMS)와 같은 멀티캐스트 또는 브로드캐스트 전송들은 전송들이 다수의 수신 장치들로 전송되기 때문에 상이한 고려사항들을 제시한다. 이러한 환경들에서, 수신 장치들은 실제로 그 정보를 획득하기 위해 단계들을 취하는 연관 시스템보다 먼저 정보를 획득할 수 있다. 수신 장치는 수신된 정보를 로컬 캐시에 저장할 수 있다. 시스템(일반적으로 애플리케이션 계층)이 정보를 획득하기 위해 URL을 생성할 때, 생성된 URL은 유니캐스트 환경에서처럼 서버가 아니라 로컬 캐시 내에 이미있는 컨텐츠를 가리킬 수 있다.

File Delivery over Unidirectional Transport (FLUTE)과 결합된 DASH는 멀티캐스트 환경들에서 사용될 수 있다. 이러한 조합에 따라, 비디오 컨텐츠는 DASH 세그먼트들로 변환될 수 있고 DASH 세그먼트들의 작은 그룹들은 DASH 세그먼트들을 FLUTE 패킷들로 변환하여 전송할 수 있는 FLUTE package engine(FPE)에 의해 축적될 수 있다. DASH 세그먼트들의 구조는 ISO Base Media File Format(ISOBMFF)을 따른다.

DASH 및 대부분의 ISOBMFF-기반 적응형 스트리밍 기술들은 일반적으로 오류가없는 전송 계층을 가정한다. 그러나 eMBMS와 같은 사용들은 DASH 세그먼트들의 전달을 위해 멀티캐스트 User Datagram Protocol(UDP) 또는 Digital Video Broadcasting-Generic Stream Encapsulation(DVB-GSE)와 같은 다른 브로드캐스트 데이터 링크 계층들에 의존할 수 있다.

네트워크 가용한 컨텐츠 또는 서비스들은 MBMS 방식 또는 HTTP/HTTPS 방식을 사용하여 액세스될 수 있다. 종래에는, 사용자 장치들은 직접적으로 MBMS Application Programming Interface(API)를 사용하여 MBMS 서비스에 액세스하고, HTTP/HTTPS URL들을 사용하여 HTTP/HTTPS 컨텐츠를 쿼리하도록 구성된다.

사용자 장치(사용자 장치 내에 설치된 애플리케이션)가 컨텐츠를 요청할 때, 요청된 컨텐츠는 이미 사용자 장치 내에 다운로드되고 캐시 메모리 내에 국부적으로 저장될 수 있으며, 유니캐스트 또는 멀티캐스트 또는 브로드캐스트로 전달될 수 있으며, 요청 전송 시점에 전달되거나 미래에 전송이 스케줄링될 수 있다. 또한 3GPP TS 26.347 사양들은 일반적인 운영 체제 URL 레졸루션 라이브러리(resolution library)를 사용하여 클라이언트 애플리케이션들에 의해 리소스들을 렌더링하고 쿼리하는 일반적인 경우를 소개한다. 지정된 방식(예: mbms, http)에 따라, 운영 체제의 적절한 URL 레졸루션 라이브러리가 호출되어 리소스 렌더링을 처리한다. 사용자 애플리케이션에 의해 제공하는 URL의 방식 네임이 http/https인 경우, URL은 HTTP URL 핸들러(handler)에 제공된다. mbms 방식 네임이 URL에 존재하면, URL은 MBMS URL 핸들러에 제공된다.

특히, 컨텐츠 아이템이 이미 사용자 장치에 다운로드되고 캐싱될 수 있으며, 유니캐스트 또는 멀티캐스트/브로드캐스트로 전달될 수 있다는 점을 고려하여, MBMS의 모든 특수성들을 이용하고 사용자 장치들에 단순하고 유연한 컨텐츠 전달 서비스들을 제공하는 것이 바람직할 수 있다. 특히 서비스에 대한 수요가 많은 경우, 브로드캐스트 모드로 컨텐츠 전달을 스케줄링하는 것이 바람직할 수 있다. 따라서, 사용자 장치들이 멀티캐스트/브로드캐스트 모드에서 컨텐츠 전달에 관한 정보를 획득하고, 컨텐츠 전달에 적용될 조건들을 정의할 수 있게 하는 것이 바람직하다.

사용자 단말로부터 컨텐츠를 전달하는 서비스에 액세스하기 위한 방법이 설명된다. 상기 방법은 다음을 포함한다: 상기 사용자 단말의 클라이언트 모듈로 URL(Uniform Resource Locator)을 전송하는 단계로서, 상기 URL은 요청된 컨텐츠의 식별자 및 상기 요청된 컨텐츠의 상기 사용자 단말로의 전달과 관련된 요청 또는 조건을 지정하는 명령을 포함하는, 상기 URL을 전송하는 단계; 상기 요청된 컨텐츠가 상기 지정된 조건에 따라 상기 사용자 단말에서 가용한 경우, 상기 클라이언트 모듈로부터 상기 요청된 컨텐츠를 수신하는 단계; 및 상기 요청된 컨텐츠가 상기 지정된 조건에 따라 상기 사용자 단말에서 가용하지 않는 경우, 상기 URL을 서비스 브로드캐스트 서버로 전송하는 단계.

일 실시예에 따르면, 상기 방법은 상기 사용자 단말의 애플리케이션에 의해 상기 URL을 생성하는 단계를 더 포함한다.

일 실시예에 따르면, 상기 URL은 멀티미디어 브로드캐스트 또는 멀티캐스트 서비스 또는 HTTP (Hypertext Transfer Protocol) 서비스를 서비스 타입으로서 지정하는 방식을 포함하며, 상기 방법은 상기 방식에 특정된 상기 사용자 단말의 URL 핸들러(handler)에 상기 URL을 전송하는 단계를 더 포함한다.

일 실시예에 따르면, 상기 지정된 조건은 상기 요청된 컨텐츠의 액세스에 관련된 스케줄링 또는 시간적 조건 및/또는 상기 사용자 단말 성능들과 관련된 기술적 조건, 및/또는 상기 요청된 컨텐츠와 관련된 상기 사용자에 의해 규정된 사용자 조건이다.

일 실시예에 따르면, 상기 명령은 상기 요청된 컨텐츠 전달의 현재 상태에 대한 요청을 지정한다.

일 실시예에 따르면, 명령은 명령 세트에 속하며, 상기 명령 세트는:

상기 요청된 컨텐츠가 요청된 시작 시간을 지정하는 명령으로서, 상기 시작 시간은 시간이 지정되지 않은 경우는 현재 시간인, 상기 시작 시간을 지정하는 명령;

상기 컨텐츠가 요청되는 기간을 지정하는 명령;

상기 사용자 단말의 미디어 코덱들 및 디스플레이 크기를 지정하는 명령;

상기 사용자 단말의 위치를 지정하는 명령;

상기 요청된 컨텐츠에 대해 선호된 언어들을 지정하는 명령;

상기 요청된 컨텐츠가 요청되는 컨텐츠 게시 날짜를 지정하는 명령;

상기 요청된 컨텐츠의 요청된 부분의 시작과 끝을 지정하는 명령;

상기 요청된 컨텐츠에 대한 액세스를 중지 또는 취소하는 명령;

상기 요청된 컨텐츠의 전달 상태를 요청하기 위한 명령;

상기 요청된 서비스 컨텐츠가 상기 단말에 의해 백그라운드에서 액세스되어야 한다는 것을 지정하는 명령;

상기 요청된 컨텐츠가 브로드캐스트될 준비가 된 때의 통지를 수신할 것을 요청하거나 상기 요청된 컨텐츠가 브로드캐스트될 준비가 된 때를 알리기 위한 명령; 및

상기 시작 시간을 지정하는 명령에 의해 지정된 시간부터 시작하여, 상기 컨텐츠가 요청되는 기간을 지정하는 명령에 의해 정의된 지속기간을 갖는 기간 내에서, 가용한 상기 요청된 컨텐츠의 최종 버전을 요청하는 명령을 포함한다.

일 실시예에 따르면, 상기 방법은 상기 서비스 브로드캐스트 서버로부터, 상기 요청된 컨텐츠가 특정 날짜에 브로드캐스트될 것이라는 통지를 수신하는 단계를 더 포함한다.

일 실시예에 따르면, 상기 방법은, 상기 서비스 브로드캐스팅 서버에 의해, 네트워크 영역 내에서, 상기 컨텐츠를 요청하는 단말들의 수를 카운트하는 단계; 및 상기 컨텐츠를 요구하는 단말들의 수가 임계 값을 초과하는 경우, 상기 컨텐츠의 브로드캐스트를 스케줄링하는 단계를 더 포함한다.

일 실시예에 따르면, 상기 방법은 상기 컨텐츠를 요청한 단말들에게, 상기 요청된 컨텐츠의 브로드캐스트와 관련된 스케줄 데이터를 통지하는 단계를 더 포함한다.

일 실시예에 따르면, 상기 URL은 상기 요청된 컨텐츠를 전달하는 상기 서비스의 서비스 식별자 및 상기 컨텐츠 식별자를 포함하거나, 또는 오직 상기 컨텐츠 식별자만을 포함하며, 상기 URL이 상기 컨텐츠 식별자만을 포함하는 경우, 상기 방법은 도메인 네임 시스템 레졸루션(domain name system resolution)을 더 포함한다.

실시예들은 또한 컨텐츠를 전달하는 서비스에 액세스하도록 구성된 단말에 관련될 수 있으며, 상기 단말은 앞서 정의된 방법을 구현하도록 더 구성된다.

실시예들은 또한 컴퓨터 메모리에 로딩가능한 컴퓨터 프로그램 제품에 관련될 수 있으며, 하나 이상의 컴퓨터들에 의해 수행될 때, 앞서 정의된 방법을 수행하도록 하나 이상의 컴퓨터를 구성시키는 코드 부분들을 포함한다.

방법 및/또는 장치는 다음의 도면들 및 설명을 참조하여 더 잘 이해될 수 있다. 비제한적 및 비포괄적인 설명들은 다음 도면들과 함께 설명된다. 도면들에서, 달리 지칭되지 않는 한, 동일한 참조 부호들은 상이한 도면들 전체에서 동일한 부분들을 나타낼 수 있다.
도 1은 네트워크를 통해 미디어 데이터의 멀티캐스트 또는 브로드캐스트 서비스를 제공하는 시스템의 블록도이다,
도 2는 도 1의 시스템의 보다 상세한 도면의 블록도이다,
도 3은 유니캐스트 또는 브로드캐스트 컨텐츠에 액세스하기 위해 이동 단말에서 구현되는 소프트웨어 계층들을 개략적으로 도시한다,
도 4는 일 실시예에 따른 이동 단말 내의 기능적 아키텍처의 블록도이다.
도 5는 또 다른 실시예에 따른 이동 단말 내의 기능적 아키텍처의 블록도이다.
도 6은 일 실시예에 따라, 브로드캐스트된 컨텐츠에 대한 사용자 단말의 액세스를 제공하는 단계들을 도시하는 순차도이다.

본 명세서는 네트워크를 통해, 오디오 및 비디오 데이터와 같은 멀티미디어 데이터의 스트리밍 및 파일 전달 서비스들과 관련된 기술들에 관한 것이다. 이러한 기술들은 HTTP(DASH)를 통한 동적 적응형 스트리밍과 함께 사용될 수 있으며, 이러한 기술들은 File Delivery over Unidirectional Transport(FLUTE) 프로토콜과 같은 파일 전달 서비스를 통한 멀티캐스트 또는 브로드캐스트 프로토콜 사용하는, ISO Base Media File Format(ISOBMFF)에 따라 캡슐화된 스트리밍 비디오 데이터를 포함한다. FLUTE는 신뢰할 수 있는 전송을 제공하는 asynchronous layered coding(ALC) 프로토콜을 기반으로 하므로, FLUTE는 FLUTE/ALC라고도 지칭될 수 있다.

FLUTE 대신 사용될 수 있는 추가 파일 전달 프로토콜들은 FCAST, raw ALC/LCT(예: ALC 및 LCT 헤더들을 사용하여 파일 유형, 인코딩, 및 압축 속성들과 같은 파일 속성들, ROUTE, 및 NORM을 전달)을 포함한다. FCAST는 Roca의 “FCAST: Scalable Object Delivery for the ALC and NORM protocols”(IETF RMT Working Group, 2011년 10월)에 기재된다. ALC는 Luby 등의, "Asynchronous Layered Coding(ALC) Protocol Instantiation”(RFC 5775, 2010 년 4 월)에 기재된다. LCT는 Luby 등의 "Layered Coding Transport(LCT) Building Block"(RFC 5651, 2009 년 10 월)에 기재된다. ROUTE는 "Signalling, Delivery, Synchronization, and Error Protection (A/331)"에서 기재된 ATSC 3.0 용 FLUTE의 발전이다. NORM은 Adamson 등의, "NACK-Oriented Reliable Multicast (NORM) Transport Protocol"(RFC 5740, 2009 년 11 월)에 기재된다. 대규모 파일 브로드캐스트 다운로드를 위한 다른 프로토콜들은 MAC 계층에서 파일들을 브로드캐스트하는 IEEE 802.1E 시스템 로드 프로토콜을 포함한다. DVB-H, ATSC-M/H, 3GPP MBMS(멀티미디어 브로드캐스트 멀티캐스트 서비스들), 3GPP2 BCMCS(브로드캐스트 및 멀티캐스트 서비스)와 같은 IP-기반 모바일 브로드캐스트 TV 시스템들에서, 스트리밍 및 파일 전달 서비스들은 상이한 전송 프로토콜들을 사용하여 전송된다. 스트리밍 서비스들 전달은 RTP(RFC 3550에 따른 Real-time Transport Protocol) 또는 MMT(ISO/IEC 23008-1에 지시된 MPEG 미디어 전송)를 사용하는 반면 파일 전달 서비스들은 (각각 RFC 3926 및 RFC 5775에 따른) FLUTE/ALC를 포함한다. 유니캐스트-기반의 적응형 HTTP 스트리밍 서비스들은 비디오 전달을 위해 인터넷에서 현재 지배적인 기술이며, 3GPP [TS 26.247] 및 MPEG [ISO/IEC FCD 23001-6]에서 표준화되고 있으며, 일반적으로 DASH(Dynamic Adaptive Streaming over HTTP)로 지칭된다.

브로드캐스트 스트리밍 전달은 또한 RFC 6726에 기술된 FLUTE 프로토콜과 같은 파일 전달 서비스를 이용할 수 있다. 파일 전달 서비스는 LTE 기술에 기초한 enhanced Multimedia Broadcast Multicast Service(eMBMS) 또는 IP 멀티캐스트와 같은 멀티캐스트 프로토콜과 같은, broadcast media access control(MAC) 프로토콜을 통해 동작할 수 있다. 스트리밍 및 파일 컨텐츠는 모두 단일 애플리케이션 전송 프로토콜(예: FLUTE)에 의해 전달된다. 또한 스트리밍 컨텐츠를 FLUTE/ALC 패킷들로 전달하기 위한 연속적인 미디어 “파일” 구조로서 DASH를 채택함으로써, 브로드캐스트로부터 유니캐스트 전달로의 서비스 연속성은 단순히 DASH 세그먼트들을 FLUTE/브로드캐스트를 통해 HTTP/유니캐스트로 전환하는 것을 포함한다.

도 1은 멀티미디어 데이터 MBMS(Multimedia Broadcast Multicast SErvice)의 브로드캐스트 멀티캐스트 스트리밍 및/또는 파일 전달 서비스들을 제공하는 시스템을 나타낸다. 이러한 시스템은 하나 이상의 컨텐츠 서버들(CNTS), 인터넷과 같은 하나 이상의 네트워크들(IPN), 네트워크(IPN) 중 하나를 통해 서버들(CNTS) 중 하나에 링크된, MBMS 또는 eMBMS 서비스를 구현하는 하나 이상의 서버들(MBMS), 서버(BMS)와 모바일 네트워크들(UTRN) 사이의 하나 이상의 게이트웨이들(MGW), 및 모바일 네트워크들(UTRN) 중 하나에 각각 접속된 사용자 또는 클라이언트 장치들(UM)을 포함한다. 서버들(CNTS) 중 하나는 예를 들어 MPEG-DASH에 따라 멀티미디어 컨텐츠를 전송한다.

파일 전송은 웹 서비스의 HTML 페이지와 같은 공통 기본 URL로부터 액세스할 수 있는 단일 파일 또는 파일들의 세트를 다운로드하기 위한 서비스들과 관련될 수 있다.

도 2는 도 1의 시스템의 예시적인 상세한 블록도이다. 이러한 예에서, 서버(CNTS)는 인코딩된 비디오 데이터, 오디오 데이터, 파일들, 멀티미디어 컨텐츠 등과 같은 컨텐츠 데이터(CD)를 생성 및/또는 저장한다. 보다 일반적으로 서버(CNTS)는 파일 내에 캡슐화되기 전에 패킷화된 기본 스트림으로 변환될 수 있는 데이터 스트림들을 생성할 수 있다. 각각의 개별 스트림은 ITU-T H.261, H.262, H.263, MPEG-1, MPEG-2, H.264/MPEG-4 part 10과 같은 압축 표준에 따라 압축 처리될 수 있다.

도 2의 예에서, 서버(CNTS)는 인코딩된 데이터를 포함하는 기본 스트림들을 수신하는 캡슐화 유닛(ENCM)을 포함한다. 캡슐화 유닛(ENCM)은 기본 스트림들로부터 대응하는 네트워크 추상화 계층 유닛들을 형성한다. 캡슐화 유닛(ENCM)은 출력 인터페이스(OINT)에 대한 매니페스트 파일(manifest file)(예를 들어, MPD)과 함께, 멀티미디어 컨텐츠의 하나 이상의 레프리젠테이션에 대한 데이터를 제공할 수 있다. 출력 인터페이스(OINT)는 네트워크 인터페이스 또는 universal serial bus (USB) 인터페이스, CD 또는 DVD 라이터(writer) 또는 버너(burner)와 같이 저장 매체에 기록하기 위한 인터페이스, 자기 또는 플래시 저장 매체에 대한 인터페이스, 또는 미디어 데이터를 저장 또는 전송하기 위한 다른 인터페이스들을 포함할 수 있다. 캡슐화 유닛(ENCM)은 대응하는 멀티미디어 컨텐츠의 각각의 데이터를 네트워크 전송 또는 저장 매체를 통해 서버(BMS)에 데이터를 전송할 수 있는 출력 인터페이스(OINT)에 제공할 수 있다.

서버(BMS)는 멀티미디어 데이터를 브로드캐스트 또는 멀티캐스트하기 위해 하나 이상의 브로드캐스트 또는 멀티캐스트 프로토콜들을 구현할 수 있다. 도 2의 예에서, 서버(BMS)는 다양한 멀티미디어 컨텐츠(MCNT), 요청 처리 유닛(RQPU), 및 네트워크 인터페이스(FSND)를 저장하는 저장 매체를 포함할 수 있다. 일부 예들에서, 서버(BMS)는 네트워크 인터페이스(FSND)를 포함하는 복수의 네트워크 인터페이스들을 포함할 수 있다. 또한, 서버 장치(MBMS)의 특징들 중 일부 또는 전부는 라우터들, 브리지들, 프록시 장치들, 스위치들, 또는 다른 장치들과 같은 컨텐츠 배포 네트워크의 다른 장치들 상에 구현될 수 있다. 일부 예들에서, 컨텐츠 배포 네트워크의 중간 장치들은 멀티미디어 컨텐츠(MCNT)의 데이터를 캐싱할 수 있고, 서버(BMS)의 것들과 실질적으로 일치하는 구성요소들을 포함할 수 있다. 일반적으로 네트워크 인터페이스(FSND)는 네트워크(IPN)를 통해 데이터를 송수신하도록 구성된다.

DASH의 예에서는 멀티미디어 컨텐츠에 대해 다수의 레프리젠테이션들이 있을 수 있다. 이러한 레프리젠테이션들의 매니페스트는 Media Presentation Description (MPD) 데이터 구조에서 정의된다. 미디어 프리젠테이션은 HTTP 스트리밍 클라이언트 장치가 액세스할 수 있는 구조화된 데이터 콜렉션에 대응할 수 있다. HTTP 스트리밍 클라이언트 장치는 클라이언트 장치의 사용자에게 스트리밍 서비스를 제공하기 위해 미디어 데이터 정보를 요청하고 다운로드할 수 있다. MPD 데이터 구조는 각 레프리젠테이션의 코딩 및 렌더링 특성들을 기재한다. 또한, 서버 장치는 브로드캐스트 또는 멀티캐스트의 특성들을 기재하는 데이터를 제공하여, 예를 들어, 클라이언트 장치가 브로드캐스트 또는 멀티캐스트를 수신하기에 충분한 정보를 제공할 수 있다. 예를 들어, 데이터는 클라이언트 장치들이 멀티캐스트 컨텐츠 전달에 합류하기 위해 사용할 수 있는 멀티캐스트 주소를 포함할 수 있다.

멀티미디어 컨텐츠(MCNT)는 매니페스트 파일 및 하나 이상의 레프리젠테이션들을 포함할 수 있다. 일부 예들에서, 레프리젠테이션들은 적응 세트들로 분리될 수 있다. 즉, 다양한 레프리젠테이션의 서브세트들은 각각의 공통된 특성들의 세트를 포함할 수 있다. 매니페스트 파일은 특정 적응 세트들에 대응하는 레프리젠테이션들의 서브세트들뿐만 아니라 적응 세트들에 대한 공통 특성들을 나타내는 데이터를 포함할 수 있다. 매니페스트 파일은 또한 적응 세트들의 개별적인 레프리젠테이션들을 위한, 비트레이트들과 같은 개별적인 특성들을 나타내는 데이터를 포함할 수 있다. 이러한 방식으로, 적응 세트는 단순화된 네트워크 대역폭 적응을 제공할 수 있다. 적응 세트 내의 레프리젠테이션들은 매니페스트 파일의 적응 세트 요소의 자식 요소들을 사용하여 지시될 수 있다.

요청 처리 유닛(RQPU)은 데이터 컨텐츠(MNCT)에 대해 클라이언트 장치들(UM)로부터 네트워크 요청들을 수신하도록 구성된다. 예를 들어, 요청 처리 유닛(RQPU)은 Hypertext Transfer Protocol (HTTP) 버전 1.1 또는 2(버전 1.1은 RFC 2616에 기재되며, 버전 2는 RFC 7540에 기재됨)를 구현할 수 있다. 즉, 요청 처리 유닛(RQPU)은 요청들에 응답하여 HTTP GET 또는 부분 GET 요청들을 수신하고 멀티미디어 컨텐츠(MCNT)의 데이터를 제공하도록 구성될 수 있다. 요청들은, 예를 들어, 세그먼트의 URL을 사용하여 레프리젠테이션들 중 하나의 세그먼트를 지정할 수 있다. 일부 예들에서, 요청들은 또한 세그먼트의 하나 이상의 바이트 범위들을 지정할 수 있다. 일부 예들에서, 세그먼트의 바이트 범위들은 부분적인 GET 요청들을 사용하여 지정될 수 있다.

요청 처리 유닛(RQPU)은 또한 레프리젠테이션들 중 하나의 세그먼트의 헤더 데이터를 제공하기 위해 HTTP HEAD 요청들을 서비스하도록 구성될 수 있다. 임의의 경우에, 요청 처리 유닛(RQPU)은 요청들을 처리하도록 구성되어, 요청된 데이터를 클라이언트 장치(UM)와 같은 요청 장치에 제공할 수 있다.

네트워크 인터페이스(FSND)는 요청 처리 유닛(RQPU)으로부터 DASH 세그먼트들을 수신하고, 이들을 FLUTE 패킷들(FP)로 변환하도록 구성될 수 있다. 네트워크 인터페이스(FSND)는 하나 이상의 FLUTE 패킷들을 통해 DASH 세그먼트를 분해할 수 있다. FLUTE 패킷들(FP)로의 변환은 전송 오류 정정을 가능하게 하는 중복 데이터로 DASH 세그먼트들을 인코딩하기 위한 FEC(순방향 오류 정정) 인코딩을 수반한다. FLUTE 패킷들(FP)을 DASH 세그먼트들과 상관시키기 위해, 네트워크 인터페이스(FSND)는 각 세그먼트에 대해 하나의 Transmission Object Identifier(TOI)를 할당할 수 있다. 하나의 세그먼트는 하나의 파일로 간주될 수 있고, 세그먼트 URL은 TOI에 의해 식별된 FLUTE 파일의 파일 네임과 동일할 수 있다. 네트워크 인터페이스(FSND)는 DASH 세그먼트들에 대한 속성들을 설명하기 위해 File Delivery Table (FDT) 인스턴스를 생성할 수 있다. DASH 세그먼트들의 속성들은 파일 네임(예: URL로 지정됨), 파일 유형(예: 파일의 MIME 미디어 유형), 파일 크기, 파일의 메시지 다이제스트(예: MD5), FEC 처리와 관련된 정보, 및 파일의 인코딩 포맷을 포함할 수 있다. 테이블(FDT)은 네트워크 인터페이스(FSND)에 의해 전송된 하나 이상의 FLUTE 패킷들(FP)에서 전송될 수 있다.

클라이언트 장치(UM)는 파일 리시버(FREC), 애플리케이션(APP), 및 MBMS 클라이언트 모듈(MBMC)을 포함할 수 있다. 애플리케이션(APP)은 예를 들어 오디오 및 비디오 디코더들 및 플레이어들과 같은 컨텐츠 디코더들 및 플레이어들을 포함하는, 서버(BMS)로부터 수신된 컨텐츠를 이용하기 위한 소프트웨어를 포함할 수 있다. 파일 리시버는 FLUTE 프로토콜과 같은 파일 전달 프로토콜을 구현하기 위해 FLUTE 리시버 및 FEC 디코더를 포함할 수 있다. 이러한 방식으로, 클라이언트 장치(UM)는 FLUTE 프로토콜을 통해 브로드캐스트 또는 멀티캐스트를 사용하여 멀티미디어 컨텐츠(MCNT)의 데이터를 검색하도록 구성될 수 있다. FLUTE를 파일 전달 서비스로서 이용하기 위해, 서버(BMS)는 클라이언트 장치(UM)에 대한 미디어 컨텐츠(MCNT)에 대한 하나 이상의 유니캐스트 Uniform Resource Locator (URLs)을 나타내는 File Delivery Table (FDT) 속성들을 삽입할 수 있다. 파일 리시버(FREC)는 서버 장치(MBMS)(또는 또 다른 서버 장치)로부터 전송된 브로드캐스트, 멀티캐스트, 또는 유니캐스트에 관계없이 데이터를 수신할 수 있다. 특히, 파일 리시버(FREC)는 FLUTE 패킷들을 수신할 수 있고, 수신된 레프리젠테이션들의 세그먼트들의 데이터를 애플리케이션(APP)에 제공할 수 있다. 애플리케이션(APP)은 DASH 서버 모듈을 통해 MBMS 클라이언트 모듈(MBMC)과 통신하는 DASH 클라이언트 모듈(DSHC)에 DASH 세그먼트들을 차례로 제공할 수 있다. MBMS 모듈은 사양 3GPP TS 26.346에 정의된 기능들을 구현한다.

애플리케이션(APP)은 클라이언트 장치(UM)의 하드웨어-기반 프로세싱 유닛에 의해 실행되는 웹 브라우저 또는 이러한 웹 브라우저에 대한 플러그-인을 포함할 수 있다. 애플리케이션(APP)에 대한 참조들은 일반적으로 웹 브라우저, 독립실행형 비디오 플레이어, 또는 재생 플러그-인을 웹 브라우저에 통합하는 웹 브라우저와 같은 웹 애플리케이션을 포함하는 것으로 이해되어야 한다. 비디오 컨텐츠의 경우에, 애플리케이션(APP)은 오디오 및 비디오 디코더들의 디코딩 성능들 및 오디오 및 비디오 플레이어들의 렌더링 성능들을 결정하기 위해 클라이언트 장치(UM) 내의 구성 데이터를 검색할 수 있다.

애플리케이션(APP)은 서버(BMS)에 의해 전송된 브로드캐스트 또는 멀티캐스트 데이터를 요청하고 수신하도록 구성될 수 있다. 예를 들어, 애플리케이션(APP)은 초기에 매니페스트 파일에 대한 데이터를 검색하도록 구성될 수 있으며, 매니페스트 파일에 대한 데이터는 (멀티캐스트 그룹 IP 주소와 같은) 멀티캐스트 그룹에 합류하거나 브로드캐스트를 수신하기 위한 데이터(예: 브로드캐스트 도메인 또는 VLAN에 합류하기 위한 데이터)를 포함할 수 있다.

때때로, 클라이언트 장치(UM)의 사용자는 키보드, 마우스, 스타일러스, 터치스크린 인터페이스, 버튼들, 또는 다른 인터페이스들과 같은 클라이언트 장치(UM)의 사용자 인터페이스들을 사용하여 애플리케이션(APP)과 상호작용하여, 멀티미디어 컨텐츠(MCNT)와 같은 멀티미디어 컨텐츠를 요청할 수 있다. 사용자로부터의 이러한 요청에 응답하여, 애플리케이션(APP)은 예를 들어 클라이언트 장치(UM)의 디코딩 및 렌더링 기능들에 기초하여 레프리젠테이션들 중 하나를 선택할 수 있다. 레프리젠테이션들 중 선택된 하나의 데이터를 검색하기 위해, 애플리케이션(APP)은 레프리젠테이션들 중 선택된 하나의 특정 바이트 범위들을 순차적으로 요청할 수 있다. 이러한 방식으로, 하나의 요청을 통해 전체 파일을 수신하기보다는, 애플리케이션(APP)은 다수의 요청들을 통해 파일의 일부들을 순차적으로 수신할 수 있다.

도 3은 유니캐스트 또는 브로드캐스트 컨텐츠에 액세스하기 위해 이동 단말에서 구현되는 소프트웨어 계층들을 도시한다. 이러한 소프트웨어 계층들은 Open System Interconnection (OSI) 모델 내에 지정된 네트워크 계층에 대응한다. 이러한 소프트웨어 계층들은 이동 단말 내에 설치된 모든 애플리케이션들을 포함하는 응용 계층(APPS)을 포함하며, 이러한 애플리케이션들은 서비스 및 컨텐츠 수신 계층들을 사용한다. 서비스 및 컨텐츠 수신 계층들은 유니캐스트 모드(UC)에서 단독으로 컨텐츠를 수신하거나, 유니캐스트 및 멀티캐스트/브로드캐스트 모드들(UC/BC)을 구현하는 MBMS 모드에서 컨텐츠를 수신하는 2가지 유형들이다. 서비스 및 컨텐츠 수신 계층들은 도 3에서 명백하지 않은 보안과 관련된 요소들을 더 포함한다.

응용 계층(APPS) 아래의 최상위 레벨로부터 시작하여, 유니캐스트 모드(UC)와 관련된 소프트웨어 계층들은, 컨텐츠 서비스들에 의해 제공되는 컨텐츠와 관련된 메타데이터를 제공하는 통지 서비스(SANU), 및 특히 프로세서 전송 오류들에 대한 파일 복구 서비스(FREP) 및 데이터 수신과 관련된 통계 데이터를 제공하는 수신 보고 서비스(reception reporting service)(RAPR)를 포함하는 관련 전달 절차들(ADPU)을 병렬로 포함한다. 이러한 통계 데이터는 예를 들어 서버(BMS)로 전송될 수 있다. 계층들(SANU 및 ADPU)에 의해 제공된 데이터는 프로토콜 HTTP(HyperText Transfer Protocol)를 구현하는 HTTP 계층(UHT)에 의해 전송된다. 계층(UHT)에 의해 전송된 데이터는 프로토콜 TCP(Transmission Control Protocol)를 구현하는 전송 계층(UTCP)에 의해 캡슐화되고 전송된다. 계층(UTCP)에 의해 전송된 데이터는 프로토콜 IP(Internet Protocol)을 구현하는 네트워크 계층(IPUC)에 의해 패킷들 내로 삽입된다. 마지막으로, 무선 전송 채널의 구현에 대응하는 포인트-투-포인트 링크 계층(PTPB)은 계층(IPUC)에 의해 생성된 패킷들(IP)을 전송한다.

응용 계층(APPS) 아래의 최상위 레벨로부터 시작하여, MBMS(UC/BC) 모드와 관련된 소프트웨어 계층들은 가용한 데이터 스트림들, 특히 멀티캐스트 또는 브로드캐스트된 데이터 스트림들을 통지하기 위한 통지 서비스(SANN), 상이한 포맷들의 파일들의 다운로드를 위한 파일 다운로딩 서비스(DWL), 관련된 전달 절차들(ADP), 및 컨텐츠 스트리밍 서비스들(STCD)을 병렬로 포함한다. 서비스들(STCD)은 CODEC들(오디오, 비디오, 음성, 텍스트 등) 및 프로토콜 DASH을 구현하는 데이터 스트림 수신 서비스(DSHC)를 포함한다. 서비스(ADP)는 특히 브로드캐스트 모드에서 전송 오류들을 처리하기 위한 파일 복구 서비스(FMRP)를 포함한다. 계층(STCD) 아래에는, 전송 스트림들을 포맷팅하기 위한 포맷팅 서비스들(RTPF)가 있으며, 이는 특히 보안된 및 보안되지 않은 실시간 전송 서비스들(SRTP 및 RTP), 및 실시간 전송 제어 서비스들(RTCP)을 포함한다. 전송 오류들을 처리하기 위해 포맷팅 서비스(RTPF) 아래에 위치된 파일 복구 서비스(FEC)가 제공된다. 프로토콜 HTTP를 구현하는 계층(HTPC)는 계층(DSHC) 아래에 위치된다. 프로토콜 FLUTE를 구현하는 계층(FLT)는 계층들(DSHC, DWL, FMRP, 및 SANN) 아래에 위치된다. 계층(FLT)은 전송 오류들을 처리하기 위한 오류 정정 서비스(FFEC)를 포함한다. 프로토콜 UDP(User Datagram Protocol)를 구현하는 계층(MUDP)은 계층들(RTPF(FEC) 및 FLT) 아래에 위치된다. 프로토콜(TCP)을 구현하는 계층(MTC)은 계층(HTPC) 아래에 위치된다. 유니캐스트 및 멀티캐스트 모드들에서 프로토콜 IP를 구현하는 네트워크 계층(IPMU)는 계층들(MUDP 및 MTC) 아래에 위치된다. 마지막으로, 유니캐스트 및 멀티캐스트 링크 계층(MTB)은 계층(IPMU)마다 생성된 IP 패킷들을 전송한다.

도 4 및 도 5는 사용자 장치의 기능적으로 상이한 아키텍처들을 도시한다. 도 4에서, 애플리케이션(APP1)은 모듈(MBMC)의 애플리케이션 프로그래밍 인터페이스(API)를 사용하여 MBMS 서비스들을 사용하도록 기록될 수 있다. 또 다른 애플리케이션(APP2)는 '파일' 리소스들을 어드레스하는 URL들을 지원하도록 기록되고, 일반적인 운영 체제 URL 레졸루션(resolution) 모듈(URLD)를 사용하여 식별된 리소스를 발견하면 이를 리턴시킨다. "파일" 리소스는 서비스에 대한 진입 지점이 될 수 있으며, 웹 사이트에 액세스하기 위해 http 방식을 사용할 때 종래에 수행된 바와 같이 서비스에 대해 정의된 디폴트 파일이 있는 경우일 수 있다. URL 모듈(URLD)는 URL 방식 네임(예: "http:" 또는 "mbms:")으로부터 특정 프로토콜 핸들러를 식별하고, mbms 방식에 대해 적절한 프로토콜-특정 핸들러(MUH)를 적용하거나 http 방식에 대해 HUH를 적용한다. 핸들러들(MUH, HUH)에 대한 인터페이스들은 또한 사용자 장치(UM)의 운영 시스템에 의해 결정될 수 있다. HTTP 핸들러(HUH)는 URL을 운영 시스템의 HTTP 모듈(HF)로 전송한다. MBMS 핸들러(MUH)는 URL 형태를 분석하고(picks apart), 기존 MBMS 인터페이스(MAPI)를 사용하여, 식별된 리소스에 대한 액세스를 허용하는 MBMS 서비스의 획득 및 해당 세션으로부터 지정된 '파일' 리소스의 획득을 개시하고, 상기 리소스를 리턴시킨다.

MBMS URL 방식은 컨텐츠 제공자가 사용될 전달 방법에 대한 세부사항들이나 컨텐츠 전달의 정확한 스케줄링을 알지 못해도 그의 컨텐츠의 MBMS URL들을 구성하여 클라이언트 장치들에 전송할 수 있게 한다.

도 5는 MBMS 핸들러(MUH)에 의해 수행되는 기능이 프로그래밍 인터페이스(API)를 사용하지 않고 모듈(MBMC)의 내부 기능들을 직접 호출하는, 모듈(MBMC)에 통합된 기능(IMH)이라는 점에서 도 4와 상이하다.

일 실시예에 따르면, 애플리케이션들(APP1 및 APP2)에 의해 전송될 수 있는 URL들은, 상기 애플리케이션들로 하여금, 요청된 컨텐츠의 수신에 적용될 스케줄링 데이터, 사용자 장비 구성 및 위치 데이터, 수신할 특정 컨텐츠 부분 또는 버전을 지정하는 컨텐츠 부분 데이터 또는 버전 데이터를 특정하게 하고 컨텐츠 전달의 상태를 요청하게 하는 명령들을 포함한다. URL 신택스(syntax)는 http URL들의 경우 RFC 3986, mbms URL들의 경우 RFC 7230 및 3GPP TS 26.347 섹션 8.2의 사양들과 일치한다. mbms URL들은 다음과 같이 정의될 수 있다:

mbms://<authority>/<path>?<parameters>&<label>=<value>, 여기서:

<authority>/<path>는 서비스 식별자 URI(Unified Resource Identifier)이며,

?<parameters>는 선택사양적이며, "&"에 의해 구분된 하나 이상의 속성-값 쌍들을 지정하며; 속성들은 사전정의된 명령들의 세트에서 선택될 수 있다.

&<label>=<value>는 선택사양적이며, 요청된 서비스에 의해 전달된 특정 컨텐츠의 리소스 식별자(예: 다운로드 서비스에 의해 전달된 단일 파일에 대한 파일 URI, DASH 컨텐츠에 대한 MPD 식별자, HLS 컨텐츠에 대한 .m3u8 파일 식별자, 또는 RSS 또는 Atom 피드에 대한 피드 URL)를 지정한다. URL에 접미어"&<label=<value>"가 없는 경우, 접두어 mbms://<authority>/<path>는 요청된 컨텐츠에 대한 리소스 식별자를 제공하며 서비스 식별자는 알 수 없다. 이 경우, 주어진 MBMS URL에 대한 DNS(Domain Name System) 레졸루션(resolution)은 요청된 컨텐츠를 전달하는 서비스의 식별자를 제공할 수 있다.

명령들의 세트는 다음 표 1에서 정의될 수 있다:

명령 네임	파라미터	단일 파일	VOD	RSS 피드
Start 또는 Open	날짜	X	X	X
MaxWaitingPeriod 또는 SetMaxDuration	기간	X	X	X
UE capabilities	UE capabilities		X	X
Languages	FR/EN/…		X	X
Publication start date	날짜			X
Location	좌표들	X	X	X
From	백분율	X	X
To	백분율	X	X
Stop 또는 Discard	없음	X	X	X
GetStatus	없음	X	X	X
SetDownloadBackground	부울(Boolean)(예 /아니오)		X	X
GetNotified	없음		X	X
LatestVersion	없음	X

표 1은 또한 명령이 설계된 컨텐츠 유형(단일 파일 다운로드, DASH VOD 컨텐츠, HLS VOD 컨텐츠, RSS 피드, Atom 피드)을 나타낸다.

"Start" 또는 "Open” 명령은 이러한 명령을 따른 날짜에 다운로드를 시작하거나 서비스를 오픈한다. 날짜가 지정되지 않으면 파일 다운로드 또는 서비스 오픈을 즉시 시작한다. 이러한 명령은 URL에 명령이 없는 경우 디폴트 명령이다.

"MaxWaitingPeriod" 또는 "SetMaxDuration” 명령 다음에는 지속 시간(예: 초)이 온다. 이러한 명령은 사용자 장치(UM)가 요청된 컨텐츠의 전달에 대해 대기할 수 있는 시간을 지정한다. 기간이 생략되면 기간 디폴트 값은 null 또는 무한대일 수 있다. 기본 기간이 null 인 경우 조치는 즉시 이루어져야 한다. 서비스 또는 파일을 사용할 수 없는 경우, 사용자 장치(UM)에 (404-가용한 서비스 없음과 같은) 4xx 오류가 전송된다. 디폴트 값이 무한대이면, 모듈(MBMS)는 규칙적으로 재시도할 것이다. 구현에서, 디폴트 값은 배터리 수명의 관점에서 사용자 장치가 지원할 수 있는 값으로 설정될 수 있다. 디폴트 값은 예를 들어 사용자 장치의 운영 체제에 대해 규정된 파라미터들의 집합에서 규정될 수 있다. 2 시간의 지연으로 사용자 장치에 의해 소비될 것으로 예상되는 팟캐스트 컨텐츠의 예에 따르면, 사용자 장치는 "MaxWaitingPeriod" 값을 2 시간으로 고정할 수 있으므로, 팟캐스트 컨텐츠가 이러한 주어진 지연 내에 브로드캐스트되면, 컨텐츠는 장치에 의해 국부적으로 캐시될 것이다.

명령 "UEcapabilies"은 사용자 장치(UM)에 의해 지원되는 미디어 코덱들 및 사용자 장치(UM)의 디스플레이의 크기 및 레졸루션을 지정한다. 이러한 명령은 예를 들어 4K의 비디오들과 호환가능한 사용자 장치들에 대한, 여러 레프리젠테이션들에서 가용한 DASH/HLS VOD 또는 라이브 스트림 컨텐츠에 대해 유용하다. 이러한 예에서 UE기능들은 "4K" 또는 "HD"와 동일하게 설정될 수 있다.

명령 "Languages"은 요청된 서비스 컨텐츠에 대해 사용자 장치가 기대하는 언어들(음성 및 자막들)을 지정한다. 이러한 명령은 여러 언어들로 제공되는 DASH VOD 서비스 컨텐츠에 유용하다. 사용자 장치 기능들 및 언어들은 DASH VOD 항목들을 제공할 때 RSS/Atom 피드들과와 관련이 있다. 이러한 명령은 "EN", "ES", "DE", "FR", 또는 그러한 코드들의 목록과 같이 국가 또는 언어를 나타내는 두 글자의 한 코드와 동일하게 설정될 수 있다.

명령 "Location"는 사용자 장비의 현재 위치를 나타낸다. 이러한 명령 다음에는 지리적 좌표들 또는 셀룰러 네트워크에서의 사용자 장치의 셀 번호가 온다.

Atom 및 RSS 피드들에 고유한 명령 "PublicationStartDate" 다음에는 날짜가 온다. 이러한 명령은 사용자 장치가 이러한 날짜 이후에 게시된 RSS 또는 Atom 피드들의 전달을 기다리는 중임을 나타낸다.

명령 "From"은 컨텐츠의 처음 부분이 요청되지 않았을 때(예: 컨텐츠의 첫 번째 부분이 이미 캐시되거나 조회되었기 때문에), 컨텐츠의 요청된 부분의 시작을 지정한다. 이러한 명령 뒤에는 요청된 내용의 시작을 지정하는 백분율이 나오며, 디폴트 값은 0%이다.

명령 "to"는 컨텐츠의 끝 부분이 요청되지 않은 경우(예: 컨텐츠의 시작 부분만 캐시되는 경우), 컨텐츠의 요청된 부분의 끝을 지정한다. 이러한 명령 다음에는 요청된 컨텐츠의 끝을 지정하는 백분율이 나오며, 디폴트 값은 100 %이다. 명령들 "From" 및 "To"은 파일 다운로드, DASH 및 HLS VOD 서비스들에만 해당되며, 동일한 URL에서 동시에 사용되어 요청된 컨텐츠의 중간 부분만을 지정할 수 있다.

명령 "Stop" 또는 "Discard" 명령은 현재 컨텐츠 수신을 중지하고 캐시를 정리한다. 이러한 명령 뒤에는 파라미터가 없다.

명령 "GetStatus"은 지정된 컨텐츠의 현재 전송 상태를 요청한다. 상이한 값들은 "중지됨", "102: 처리 중/진행 중", "404: 알 수 없는 서비스", "201: 다운로드됨"(파일의 경우) 및 "200: OK/완료"( DASH 또는 HLS VOD, RTP 및 RSS 또는 Atom의 경우)일 수 있다.

명령 "SetDownloadBackground"은 모듈(MBMC)이 요청된 컨텐츠를 백그라운드에서 수신하여 이를 캐시에 저장하도록 요구한다.

명령 "GetNotified"는 요청된 서비스가 브로드캐스트 모드로 가용할 때 애플리케이션(APP)이 통지되기를 요청하는 것을 모듈(MBMC)에 나타낸다. 이러한 명령 뒤에는 파라미터가 없다. 이러한 명령에 대한 응답은 요청된 서비스가 브로드캐스트 모드에서 가용한 경우에만 전송된다.

명령 "LatestVersion"은 요청된 컨텐츠의 최신 버전만이 요청되었음을 모듈(MBMC)에 알리는 데 사용된다. 이러한 명령은 "시작" 또는 "오픈” 명령 및 "MaxWaitingPeriod" 명령과 함께 사용되어야 한다. 이러한 경우, 모듈(MBMC)은 시작 시간부터 최대 지속 시간의 종료 전에 전송된 요청된 파일의 최종 버전을 추적하도록 요청된다.

예를 들어, 하기 URL mbms://www.operator.com/service1000?start=1477339200&GetNotified=yes&label=http://www.example.com/videos/sample.mpd에서는, 애플리케이션(APP)는 서비스 mbms://www.operator.com/service1000에 의해 전달된 MPD URI http://www.example.com/videos/sample.mpd를 갖는 DASH 컨텐츠를 요청하며, 컨텐츠는 시간 "1477339200"으로부터 요청되며, 해당 컨텐츠를 사용할 수 있을 때 통지가 요청된다.

하기 URL mbms://www.operator.com/service1001&DownloadBackground=yes&label=http://www.manufacturer.com/firmware/version10.bin에서,

애플리케이션(APP)은 MBMS 서비스 "www.operator.com/service1001"에 의해 전달된 파일 http://www.manufacturer.com/firmware/version10.bin이 요청되며 파일은 반드시 백그라운드에서 다운로드되어야 한다는 것을 지정한다.

위의 명령들에 대한 응답 메시지들은 다음과 같이 HTTP에 대해 지정된 코드 번호들을 사용할 수 있다:

정보 제공 반응들의 경우 1xx,

요청된 동작이 성공적일 때 사용되는 2xx,

컨텐츠가 또 다른 위치로 리디렉션되었음을 나타내는 3xx,

4xx는 모듈(MBMC)로부터의 오류 메시지를 도입하고,

5xx는 모듈(MBMC)로부터 오류 메시지를 도입하였다. 이러한 오류 메시지는 예를 들어 모듈(MBMC)의 로컬 캐시들 또는 로컬 HTTP 서버 기능이 유효한 요청을 이행하지 않을 때 애플리케이션(APP)로 전송된다. 이러한 모든 메시지들은 모듈(MBMC)에 의해 애플리케이션(APP)로 전송된다.

예를 들어:

"202 Accepted"는 요청이 처리를 위해 승인되었지만 요청의 처리가 현재 완료되지 않은 경우에 발행된다.

“308”은 요청된 파일이 서버(BMS)에 의해 절대 전송될 수 없을 때 (RFC 7538에 지정된 바와 이) 파일에 대한 영구적인 리디렉션을 지정하는 경우 모듈(MBMC)에 의해 발행된다.

"400 Bad Request"는 모듈(MBMC)이 형식이 잘못된 문법(syntax)으로 인해 이해될 수 없기 때문에 요청을 처리할 수 없거나 처리하지 않을 때 발행된다.

"503 Service Unavailable"은 모듈(MBMC)가 현재 가용하지 않은 경우(예: 과부하되거나 유지보수를 위해 다운됨), 발행된다. 이러한 메시지는 일반적으로 임시 상태를 나타낸다.

도 6은 일 실시예에 따라, 사용자 단말(UM)이 미디어 컨텐츠 제공 서비스 또는 파일 다운로드 서비스에 액세스할 수 있도록 수행될 수 있는 단계들(S21 내지 S43)을 도시한다. 대상 서비스는 스트리밍 또는 DASH 또는 HLS 서비스에 의해 액세스가능한 컨텐츠(멀티미디어, 오디오, 비디오) 또는 다운로드할 파일과 같이 실시간으로 또는 지연된 시간에 전송되는 데이터 스트림에 대한 액세스를 제공할 수 있다. 컨텐츠는 파일 또는 파일들의 세트일 수 있다. 컨텐츠는 RSS 피드(예: RSS 2.0) 또는 Atom 피드일 수도 있다. 단계(S21)에서, 애플리케이션(APP)은 특정 컨텐츠를 제공하는 서비스(SVC)에 쿼리하기 위한 액세스 요청을 전송한다. 요청은 요청된 서비스를 식별하는 URL U1 및 이전에 규정된 명령들과 같은 하나 이상의 명령들을 포함한다. 일 예에 따르면, URL U1은 "mbms" 및 가능하게는 지속기간과 관련된 명령 "MaxWaitingPeriod" 또는 "SetMaxDuration", 및 사용자 장치(UM)의 기능들( "UECapabilities")을 지정하는 명령들과 같은 다른 명령들을 포함하며, 사용자 장치의 위치("Location") 및 사용자에 의해 요청된 선호되는 언어들("Languages")을 포함한다. URL U1은 애플리케이션(APP)이 서비스(SVC)를 요청하고, 브로드캐스트를 통해 해당 컨텐츠를 전달하기 위해 "MaxWaitingPeriod” 명령과 연관된 지속기간을 대기할 준비가 되었음을 나타낸다. URL U1은 URL 방식 네임으로부터 URL을 처리할 수 있는 특정 프로토콜 핸들러들(MUH, HUH)을 식별하는 모듈(URLD)에 의해 처리된다. 방식 "mbms"를 포함하여, 모듈(URLD)은 URL U1의 컨텐츠에 대응하는 모듈(MBMC)의 엔트리 기능들(API)을 호출하는 핸들러(MUH)에 URL U1을 전송한다. 이러한 방식으로, 모듈(MBMC)은 요청된 컨텐츠가 이미 캐시에 있는지를 판단하고, 애플리케이션(APP)이 요청된 컨텐츠를 수신하기 위해 대기할 수 있는 지속기간을 저장하도록 요청된다. 요청된 컨텐츠가 이미 캐시에 있다면(적절하다면, "UECapabilities" 및 "Languages" 명령들을 고려하면서), 단계들(S42 및 S43)이 수행되고, 그렇지 않으면 단계(S22)가 수행된다. 이전에 전송된 서비스의 URL U1에 명령 "DownloadBackground"가 포함되어 있으면 요청된 컨텐츠는 이미 캐시에 있을 수 있다.

단계(S22)에서, 모듈(MBMC)은 URL(U1)을 포함하는 메타데이터(MTD)에 대한 요청을 서버(BMS)로 전송한다. 단계(S23)에서, 서버(BMS)의 통지 기능(SANF)은 이러한 요청을 수신하고, 브로드캐스트 모드로부터 배제된 서비스들의 서비스 목록 및 서비스(SVC)의 서비스 식별자를 찾는다. 접미어 "&<label=<value>"가 URL U1에 없는 경우, 함수(SANF)는 DNS 레졸루션 기능을 사용하여 URL U1의 접두어 mbms://<authority>/<path>에 의해 식별되는 컨텐츠를 전달할 수 있는 서비스 식별자(서비스 URI)를 판단한다. 서버(BMS)가 데이터베이스(MB)를 쿼리할 때 "MaxWaitingPeriod” 명령과 관련된 지속기간 및 "Location” 명령과 연관된 위치가 고려될 수 있다. 동일한 컨텐츠를 제공하는 여러 서비스들이 컨텐츠에 액세스하기 위한 상이한 특징들을 갖는 사용자 이동 장치들을 지원하도록 활성화될 수 있으며, 각각의 서비스는 주어진 유형의 사용자 장치의 성능들에 적응된 방식으로 컨텐츠를 제공한다. 따라서, 서버(BMS)는 단계(S23)에서 단말(UM)의 기능들 및 URL U1에 주어진 선호 언어 데이터를 고려할 때 요구된 서비스(SVC)가 단말(UM)에 가용한지 여부를 검사할 수 있다.

단계(S24)는 요청된 서비스(SVC)가 브로드캐스트 모드로부터 배제되거나 "UECapabilities” 명령에 의해 지정된 단말의 기능들에 따라 가용하지 않은 경우 또는 명령 "MaxWaitingPeriod"에 의해 지정된 시간 슬롯 동안 및/또는 명령 "Location"에 의해 지정된 네트워크(MNT)의 영역에서 이용불가능한 경우에 수행될 수 있다. 단계(S25) 내지 단계(S26) 또는 단계(S38)은 서비스 식별자(SVC)에 해당하는 서비스가 브로드캐스트 모드로부터 제외되지 않은 경우 수행된다. 단계(S24)에서, 사용자 장치(UM)에 의해 실행되는 애플리케이션(APP)에 오류 메시지(ERR)가 송신된다.

서비스 식별자(SVC)에 대응하는 서비스가 브로드캐스트될 수 있지만 데이터베이스(MB)에서 참조되지 않으면, 단계들(S25 내지 S26)이 수행되고, 그렇지 않으면 단계(S38)가 수행된다. 단계(S25)에서, 서버(BMS)(예를 들어, 서버(BMS)의 통지 기능(SANF))는 데이터베이스(MB)에 사용자 단말(UM)이 서비스(SVC)를 요청한 것을 저장한다. 단계(S26)에서, 서버(BMS)는 요청된 서비스(SVC)가 현재 브로드캐스트 모드에서 가용하지 않음을 시그널링하는 응답 메시지(RetL)를 사용자 단말(UM)에 전송하지만, 예를 들어 충분한 수의 사용자 장치들이 동일한 서비스(SVC)를 요청하면 나중에 전송할 수 있다. 상기 메시지(RetL)는 단말(UM)이 단계(S21)의 서비스 요청을 재발행하기 전에 대기하는 기간을 포함할 수 있다. 메시지(RetL)는 사용자 단말(UM)의 모듈(MBMC)에 의해 먼저 수신될 수 있고, 애플리케이션(APP)으로 전송될 수 있다. 그런 다음 단말(UM)의 사용자는 브로드캐스트 모드에서 서비스(SVC)의 가용성을 기다리거나 유니캐스트 모드에서 서비스(SVC)를 요청하기로 결정할 수 있다. 애플리케이션(APP)은 서비스(SVC)가 가용할 때 통지를 요청하는 새 URL을 보낼 수도 있다( "GetNotified” 명령).

단계(S21) 내지 단계(S26)이 수행되면, 서버(BMS)는 사용자 장치들로부터 수신한 서비스 요청들을 카운트하고(단계(S22)), 단계들(S29 내지 S38)을 수행한다. 구체적으로, 함수(SANF)는 (수신된 데이터(MURI)에서) 지역화 데이터(localization data)를 고려하여 동일한 서비스에 대한 액세스를 요청하는 사용자 단말들의 수를 카운트한다. 단계(S29)에서, 서버(BMC)는 서비스에 상응하는 컨텐츠의 브로드캐스트를 정당화하기 위해 충분한 수의 사용자 단말들에 의해 주어진 서비스가 요청되는지 판단한다. 이를 위해 서버(BMS)의 함수(SANF)는 카운트된 단말의 수를 임계 값과 비교한다.

단계(S30)에서, 동일한 서비스를 요청하는 사용자 단말(UM)의 수가 네트워크(MNT)의 영역에서 임계 값을 초과하지 않는 한, 단계(S29)가 다시 수행되고, 그렇지 않으면 단계(S31 내지 S38)이 수행된다.

단계(S31)에서, 서버(BMS)의 함수(SANF)는 브로드캐스트될 서비스(SVC)와 관련된 메타데이터(MTD)에 대한 요청을 전송한다. 단계(S32)에서, 메타데이터 요청은 서버(BMS)의 함수(STF)에 의해 서비스(SVC)를 제공하는 컨텐츠(CNTS)로 전송된다. 단계(S32)에서, 서버(BMS)는 서비스가 VOD 스트리밍일 때 서비스(SVC)의 초기화 세그먼트들을 또한 요청할 수 있다. 단계(S33)에서, 컨텐츠 서버(CNTS)는 메타데이터 요청을 수신하고, 서비스(SVC)에 대해 요청된 메타데이터(MTD)(SVC)를 포함하는 응답 메시지를 서버(BMS)에 전송한다. 단계(S34)에서, 서버(BMS)의 함수(STF)는 메타데이터를 수신하고, 수신된 메타데이터(MTD)로부터 통합된 메타데이터(UMTD)를 생성한다. 이 목적을 위해, 서버(BMS)는 컨텐츠가 브로드캐스트되는 하나 이상의 시간 슬롯들을 스케줄링한다. 브로드캐스트된 서비스가 수신될 수 있는 URL 주소 및 해당 컨텐츠가 브로드캐스트될 시간 슬롯들에 관한 정보를 부가함으로써 통합된 메타데이터(UMTD)는 수신된 메타데이터(MTD)로부터 도출된다. 통합된 메타데이터(UMTD)는 데이터베이스(MB)에 저장된다. 서버는 수신된 메타데이터(MTD)로부터 서비스에 의해 제공되는 컨텐츠의 크기를 검사할 수 있다. 단계(S35)에서, 통합된 메타데이터(UMTD)는 서버(BMS)의 함수(SANF)에 전송된다. 요구된 서비스(SVC)가 파일 다운로드 서비스인 경우, 서버(BMS)는 그 자체로 서비스의 메타데이터를 생성할 수 있다.

단계(S36)에서, 함수(SANF)는 수신된 통합된 메타데이터(UMTD) 및 수신된 초기화 세그먼트들을 저장함으로써 브로드캐스트될 수 있는 서비스에 액세스하기 위한 메타데이터를 포함하는 데이터베이스(MB)를 업데이트한다.

단계(S36)이 수행되면, 함수(STF)는 서비스(SVC)에 의해 제공되는 컨텐츠에 대한 컨텐츠 요청(CNT)를 컨텐츠 서버(CNTS)에 전송한다(단계(S39)). 단계(S40)에서, 서버(CNTS)는 요청된 컨텐츠 CNT(SVC)를 서버(BMS)로 전송한다. 서버(BMS)는 컨텐츠(CNT)를 모바일 네트워크(MNT) 내의 서버(BMS)의 서비스 존에 위치되는 사용자 단말들(UM)에 가용하게 하기 위해 컨텐츠(CNT)를 국부적으로 저장한다.

단계(S22)와 동일한 단계(S37)에서, 모듈(MBMC)은 서비스(SVC)의 메타데이터(MTD)를 다시 요청한다. 이러한 단계는 S26 이후, 메시지(RetL)에서 지정된 대기 시간 후, 또는 모듈(MBMC)이 "GetNotified” 명령을 포함하는 이전에 전송된 URL에 대한 응답을 받을 때 수행될 수 있다. 단계(S37) 다음의 단계(S38)에서, 통합된 메타데이터(UMTD)는 함수(SANF)에 의해 관리되는 데이터베이스(MB)에서 가용하고, 단계(S37)(또는 S22)에서 전송된 요청에 응답하여 서버(BMS)로부터 사용자 단말(UM)의 모듈(MBMC)로 전송된다. 따라서, 단말(UM)은 브로드캐스트된 서비스(SVC)가 단계(S41)에서 이러한 모드에서 이용가능해지자마자, 특히 URL을 포함하는 메타데이터(MTD)를 사용하여 브로드캐스트된 서비스(SVC)에 액세스할 수 있다. 단계(S42)에서, 컨텐츠 CNT(SVC)는 단말(UM)의 캐시 메모리(LC)에 저장된다. 단계(S43)에서, 사용자 단말(UM)에 의해 실행되는 애플리케이션(APP)은 컨텐츠(CNC)(SVC)가 현재 브로드캐스트되고 애플리케이션(APP)에 가용하다는 것이 모듈(MBMC)에 의해 통지된다.

파일 다운로드 서비스는 수시로 업데이트될 수 있는 여러 파일들과 관련될 수 있다. 이러한 문맥에서, 단계(S21)에서 애플리케이션(APP)에 의해 전송된 요청은 이러한 파일들 중 하나의 발생(예를 들어, 마지막 발생) 또는 이러한 모든 파일들의 하나의 발생(예를 들어, 마지막 발생), 또는 모든 파일들의 모든 발생들을 고려할 수 있다.

서비스(SVC)는 메시지(RetL)(단계(S26)에서 전송됨)에 지정된 스케줄링된 시간 슬롯 전에 브로드캐스트될 수 있음을 알 수 있다. 후자의 경우, 단말(UM)이 이미 유니캐스트로 서비스(SVC)에 의해 제공되는 컨텐츠를 수신하면, 이는 사용자로부터 끊김없이 시청되는 고전적 방식으로 브로드캐스트된 컨텐츠로 전환될 수 있다. 메타데이터(MTD)에서 알려진 시간에 서비스(SVC)가 제공하는 컨텐츠가 브로드캐스트될 때 애플리케이션(APP)은 브로드캐스트된 컨텐츠에 액세스하기 위해 스스로 트리거할 수도 있다.

본 발명 및 설명들은 제한적이 아닌 예시적인 것으로 간주되어야 하며, 첨부된 청구 범위는 설명의 정신 및 범위 내에 있는 모든 수정들, 개선들, 및 다른 실시예들, 또는 이들의 조합들을 포함하도록 의도된다. 따라서, 이하의 청구 범위는 청구 범위 및 그들의 균등물들의 가장 넓은 허용가능한 해석에 의해 결정되며, 상기 설명에 의해 한정되거나 제한되지 않아야 한다.

특히, 본 발명은 상기 명령들의 목록에 제한되지 않는다. 다른 명령들은 첨부된 청구항들의 범위 내에서 쉽게 상상할 수 있다. 가능한 명령들은 스케줄링 또는 일시적인 조건들을 지정하는 것과 같은 카테고리들, 사용자 단말 성능들과 관련된 기술 조건들을 명시하는 카테고리들, 사용자가 정의한 조건들(예: "Languages") 및 URL의 <authority> 및 <path> 필드들로 지정된 서비스의 전달과 관련된 추가 정보를 요청하는 카테고리들로 분류될 수 있다.

Claims

사용자 단말로부터 컨텐츠를 전달하는 서비스에 액세스하는 방법으로서,
컨텐츠 재생 애플리케이션에서 상기 사용자 단말의 클라이언트 모듈로 URL(Uniform Resource Locator)을 전송하는 단계로서, 상기 URL은 요청된 컨텐츠를 식별하는 식별자를 포함하는 제1 필드 및 상기 요청된 컨텐츠의 사용자 단말로의 전달과 관련된 적어도 하나의 명령을 포함하는 제2 필드를 포함하며, 상기 적어도 하나의 명령은 사전정의된 명령 세트에서 상기 사용자 단말에 의해 선택되는 것으로서, 상기 명령 세트는 상기 사용자 단말이 상기 요청된 컨텐츠로 액세스하는 것과 관련된 스케줄링 또는 시기적인 조건을 지정하는 명령을 포함한 복수의 명령들을 포함하는, 상기 URL을 전송하는 단계;
상기 요청된 컨텐츠가 상기 URL의 적어도 하나의 명령에 따라 사용자 단말에서 가용한 경우, 상기 클라이언트 모듈로부터 상기 컨텐츠 재생 애플리케이션으로 상기 요청된 컨텐츠를 전송하는 단계; 및
상기 적어도 하나의 명령이 상기 요청된 컨텐츠로 액세스하는 것과 관련된 스케줄링 또는 시기적인 조건을 지정할 때, 상기 요청된 컨텐츠가 상기 URL의 적어도 하나의 명령에 따라 사용자 단말에서 가용하지 않는 경우,
상기 URL을 상기 클라이언트 모듈로부터 서비스 브로드캐스트 서버로 전송하고,
상기 요청된 컨텐츠가 상기 적어도 하나의 명령에 따라 상기 서비스 브로드캐스트 서버에서 가용하다면, 상기 사용자 단말이 상기 요청된 컨텐츠를 수신하고,
추후에 상기 요청된 컨텐츠가 상기 적어도 하나의 명령에 따라 상기 브로드캐스트 서버에서 가용하게 된다면, 상기 사용자 단말이 상기 요청된 컨텐츠가 가용하게 되는 때의 시간을 나타내는 메시지를 수신하고,
상기 요청된 컨텐츠가 상기 명령에 따라 상기 브로드캐스트 서버에서 가용하게 될리가 없다면, 상기 사용자 단말이 상기 컨텐츠가 브로드캐스팅되지 않을 것이라는 메시지를 수신하는 단계;를 포함하는, 방법.
제 1 항에 있어서,
상기 사용자 단말의 컨텐츠 재생 애플리케이션에 의해 상기 URL을 생성하는 단계를 더 포함하는, 방법.
제 1 항에 있어서,
상기 URL은 멀티미디어 브로드캐스트 또는 멀티캐스트 서비스 또는 HTTP (Hypertext Transfer Protocol) 서비스를 서비스 타입으로서 지정하는 방식을 포함하는 제3 필드를 포함하며,
상기 방법은 상기 방식에 특정된 사용자 단말의 URL 핸들러(handler)에 상기 URL을 전송하는 단계;를 더 포함하는, 방법.
제 1 항에 있어서,
상기 적어도 하나의 명령은 사용자 단말 성능들과 관련된 기술적 조건 및 상기 요청된 컨텐츠와 관련된 사용자에 의해 규정된 사용자 조건 중 적어도 하나를 지정하는, 방법.
제 1 항에 있어서,
상기 적어도 하나의 명령은 상기 요청된 컨텐츠 전달의 현재 상태에 대한 요청을 포함하는, 방법.
제 1 항 내지 제 5 항 중 어느 한 항에 있어서,
상기 명령 세트는:
상기 요청된 컨텐츠가 요청된 시작 시간을 지정하는 명령으로서, 상기 시작 시간은 시간이 지정되지 않은 경우는 현재 시간인, 상기 시작 시간을 지정하는 명령,
상기 컨텐츠가 요청되는 기간을 지정하는 명령,
상기 사용자 단말의 미디어 코덱들 및 디스플레이 크기를 지정하는 명령,
상기 사용자 단말의 위치를 지정하는 명령,
상기 요청된 컨텐츠에 대해 선호된 언어들을 지정하는 명령,
상기 요청된 컨텐츠가 요청되는 컨텐츠 게시 날짜를 지정하는 명령,
상기 요청된 컨텐츠에 대한 액세스를 중지 또는 취소하는 명령,
상기 요청된 컨텐츠의 전달 상태를 요청하기 위한 명령,
상기 요청된 컨텐츠가 브로드캐스트될 준비가 된 때의 통지를 수신할 것을 요청하거나 상기 요청된 컨텐츠가 브로드캐스트될 준비가 된 때를 알리기 위한 명령, 및
상기 시작 시간을 지정하는 명령에 의해 지정된 시간부터 시작하여, 상기 컨텐츠가 요청되는 기간을 지정하는 명령에 의해 정의된 지속기간을 갖는 기간 내에서, 가용한 상기 요청된 컨텐츠의 최종 버전을 요청하는 명령을 포함하는, 방법.
제 5 항에 있어서,
상기 URL은,
상기 요청된 컨텐츠의 요청된 부분의 시작과 끝을 지정하는 명령, 및
상기 사용자 단말이 상기 요청된 컨텐츠를 백그라운드에서 수신해야한다는 것을 지정하는 명령
중 적어도 하나를 더 포함하는, 방법.
제 1 항 내지 제 5 항 중 어느 한 항에 있어서,
상기 클라이언트 모듈이 상기 서비스 브로드캐스트 서버로부터, 상기 요청된 컨텐츠가 특정 날짜에 브로드캐스트될 것이라는 통지를 수신하는 단계를 더 포함하는, 방법.
제 1 항 내지 제 5 항 중 어느 한 항에 있어서,
상기 서비스 브로드캐스트 서버에 의해, 네트워크 영역 내에서, 상기 컨텐츠를 요청하는 단말들의 수를 카운트하는 단계; 및
상기 요청된 컨텐츠를 요구하는 사용자 단말들의 수가 임계 값을 초과하는 경우, 상기 요청된 컨텐츠의 브로드캐스트를 스케줄링하는 단계;를 더 포함하는, 방법.
제 9 항에 있어서,
상기 컨텐츠를 요청한 사용자 단말들에게, 상기 요청된 컨텐츠의 브로드캐스트와 관련된 스케줄 데이터를 통지하는 단계를 더 포함하는, 방법.
제 10 항에 있어서,
상기 URL은 상기 요청된 컨텐츠를 전달하는 상기 서비스의 서비스 식별자 및 컨텐츠 식별자를 포함하거나, 또는 컨텐츠 식별자만을 포함하며,
상기 URL이 상기 서비스 식별자를 포함하지 않는 경우, 상기 방법은 도메인 네임 시스템(domain name system)을 판단하는 단계를 더 포함하는, 방법.
컨텐츠를 전달하는 서비스에 액세스하도록 구성된 단말로서, 제 1 항 내지 제 5 항 중 어느 한 항에 따른 방법을 구현하도록 구성되는, 단말.
저장 매체에 저장된 컴퓨터 프로그램 제품으로서,
하나 이상의 컴퓨터들에 의해 수행될 때 제 1 항 내지 제 5 항 중 어느 한 항에 따른 방법을 수행하도록 상기 하나 이상의 컴퓨터들을 구성하는 코드 부분들을 포함하는, 저장 매체에 저장된 컴퓨터 프로그램 제품.