KR101847585B1 - 네트워크를 통한 미디어 스트리밍을 위한 전송 다이버시티 및 시간-시프트 버퍼들의 지원 - Google Patents

Abstract

프록시 유닛은, 미디어 데이터를 리트리브하기 위한 서비스에 기초하여, 미디어 데이터에 대한 식별자를 리소스 로케이션에 맵핑하는 맵핑 정보를 획득하고 ―상기 서비스는 상기 미디어 데이터를 전송하기 위한 복수의 전송 타입들 중 적어도 하나를 식별함―; 애플리케이션 서비스 클라이언트로부터 미디어 데이터에 대한 요청을 수신하고; 서비스가 이용가능한지를 결정하고; 그리고 서비스가 이용가능한 경우, 애플리케이션 서비스 클라이언트로 하여금, 맵핑 정보에 기초하여, 리소스 로케이션으로부터의 서비스를 이용하여 미디어 데이터를 수신하는 유닛으로부터 미디어 데이터를 수신하게 하도록 구성된다. 이런 식으로, 애플리케이션 서비스 클라이언트는 유닛(예를 들어, 미들웨어 유닛)으로부터 미디어 데이터를 수신할 수 있으며, 이 유닛은 이후, 예를 들어 브로드캐스트 또는 멀티캐스트 전송에 따라, 또는 정의된 전송이 이용가능하지 않을 경우 다른 방식(예를 들어, 유니캐스트)에 따라 서비스를 이용하는 미디어 데이터를 수신한다.

Description

네트워크를 통한 미디어 스트리밍을 위한 전송 다이버시티 및 시간-시프트 버퍼들의 지원 {SUPPORTING TRANSPORT DIVERSITY AND TIME-SHIFTED BUFFERS FOR MEDIA STREAMING OVER A NETWORK}

[0001] 본 출원은 2013년 1월 15일 출원된 미국 가출원 일련 번호 61/752,456, 및 2013년 4월 8일 출원된 미국 가출원 일련 번호 61/809,871의 우선권을 주장하고, 이로써, 상기 가출원의 각각의 전체 내용들이 인용에 의해 포함된다.

[0002] 본 개시는 통신 시스템들, 및 보다 구체적으로는, 네트워크를 통한 콘텐츠의 전달에 관한 것이다.

[0003] 디지털 멀티미디어(오디오 및 비디오 및 다른 미디어 포함) 능력들은, 디지털 텔레비전들, 디지털 디렉트 브로드캐스트 시스템(digital direct broadcast system)들, 무선 브로드캐스트 시스템들, PDA(personal digital assistant)들, 랩톱 또는 데스크톱 컴퓨터들, 디지털 카메라들, 디지털 레코딩 디바이스들, 디지털 미디어 플레이어들, 비디오 게이밍 디바이스들, 비디오 게임 콘솔들, 셀룰러 또는 위성 라디오 전화들, 비디오 통신 회의 디바이스들 등을 포함하는 광범위한 디바이스들에 통합될 수 있다. 디지털 멀티미디어 디바이스들은, 디지털 멀티미디어 정보를 보다 효과적으로 송신 및 수신하기 위하여, MPEG-2, MPEG-4, ITU-T H.263 또는 ITU-T H.264/MPEG-4, 파트 10, AVC(Advanced Video Coding), 및 그런 표준들의 확장들에 의해 정의된 표준들에 설명된 것들과 같은 비디오, 오디오, 및/또는 다른 미디어 압축 기술들을 구현한다.

[0004] 멀티미디어 압축 기술들은 비디오 시퀀스들에 내재하는 리던던시를 감소 또는 제거하기 위하여 공간 예측 및/또는 시간 예측을 수행한다. 블록 기반 비디오 코딩을 위하여, 비디오 프레임 또는 슬라이스(slice)는 블록들로 분할될 수 있다. 각각의 블록은 추가로 분할될 수 있다. 인트라-코딩된(I) 프레임 또는 슬라이스 내 블록들은 이웃하는 블록들에 대하여 공간 예측을 사용하여 인코딩된다. 인터-코딩된(P 또는 B) 프레임들 또는 슬라이스 내 블록들은 동일한 프레임 또는 슬라이스 내 이웃하는 블록들에 대하여 공간 예측을 사용하거나 다른 기준 프레임들에 대하여 시간 예측을 사용할 수 있다.

[0005] 멀티미디어 데이터가 인코딩된(예를 들어, 압축된) 후, 데이터는 송신(transmission) 또는 저장을 위해 패킷화될 수 있다. 데이터는 다양한 표준들 중 임의의 표준, 예컨대 ISO(International Organization for Standardization) 기반 미디어 파일 포맷 및 이들의 확장들, 예컨대 AVC에 따르는 파일로 어셈블리될 수 있다.

[0006] 무선 통신 네트워크들은 음성, 비디오, 패킷 데이터, 메시징, 브로드캐스트 등과 같은 다양한 통신 서비스들을 제공하기 위하여 널리 이용된다. 이들 무선 네트워크들은 이용가능한 네트워크 리소스들을 공유함으로써 다수의 사용자들을 지원할 수 있는 다중-액세스 네트워크들일 수 있다. 그런 다중-액세스 네트워크들의 예들은 CDMA(Code Division Multiple Access) 네트워크들, TDMA(Time Division Multiple Access) 네트워크들, FDMA(Frequency Division Multiple Access) 네트워크들, OFDMA(Orthogonal FDMA) 네트워크들, 및 SC-FDMA(Single-Carrier FDMA) 네트워크들을 포함한다.

[0007] 3GPP LTE(3rd Generation Partnership Project(3GPP) Long Term Evolution (LTE))는 GSM(Global System for Mobile communications) 및 UMTS(Universal Mobile Telecommunications System)의 에볼루션(evolution)으로서 셀룰러 기술의 주된 진보를 나타낸다. LTE PHY(physical layer)는 이벌브드 노드 B들(eNB들) 같은 기지국들과, UE들 같은 모바일 디바이스들 사이에서 데이터 및 제어 정보 둘 다를 전달하기 위한 매우 효율적인 방식을 제공한다. 종래 출원들에서, 멀티미디어에 대한 높은 대역폭 통신을 가능하게 하기 위한 방법은 SFN(single frequency network) 동작이었다. SFN들은 가입자 UE들과 통신하기 위하여 예를 들어 eNB들 같은 라디오 송신기(transmitter)들을 활용한다. 유니캐스트 동작에서, 각각의 eNB는 하나 또는 그 초과의 특정 가입자 UE들로 디렉팅된 정보를 반송하는 신호들을 송신하도록 제어된다. 유니캐스트 시그널링의 특수성(specificity)은 예를 들어, 음성 통화, 텍스트 메시징, 또는 영상 통화와 같은 지명 통화(person-to-person) 서비스들을 가능하게 한다.

[0008] 일반적으로, 본 개시는 네트워크를 통한 미디어 데이터 스트리밍을 위한 기술들을 설명한다. 예를 들어, 본 개시는, 다양한 타입들의 전송들, 예를 들어, 유니캐스트, 브로드캐스트 및/또는 멀티캐스트 중 임의의 것을 통해 미디어 데이터를 수신하기 위한 기술들을 설명한다. 이를 테면, 리디렉터(redirector)/프록시 유닛은, 애플리케이션 서비스 클라이언트로 하여금, 유니캐스트를 통해 직접 인터넷으로부터, 또는 브로드캐스트 또는 멀티캐스트 서비스가 이용가능할 경우, 브로드캐스트 또는 멀티캐스트 미들웨어 유닛으로부터 미디어 데이터를 리트리브(retrieve)하게 할 수 있다. 대안적으로, 리디렉터/프록시 유닛은, 브로드캐스트 또는 멀티캐스트 서비스가 이용가능하지 않을 경우, 애플리케이션 서비스 클라이언트 대신 미디어 데이터를 리트리브할 수 있다. 다수의 타입들의 전송들이 이용가능할 경우 그리고/또는 미디어 데이터를 전달하는데 사용될 경우, "전송 다이버시티(transport diversity)"란 용어가 하기에서 사용될 수 있다. 미디어를 전달하는데 사용되는 제공자(미디어 오리진) 및/또는 전송(들)이 (예를 들어, 리디렉터/프록시 유닛에 의해) 변경될 경우, "리디렉션(redirection)" 또는 "리디렉팅된(redirected)"이란 용어가 하기에서 사용될 수 있다.

[0009] 본 개시는 또한 리트리브된 미디어 데이터를 버퍼링하는 것에 관한 기술들을 설명한다. 이를 테면, 리트리브된 미디어 데이터는 TSB(time-shifted buffer)에 저장될 수 있다. 본 개시는, 예를 들면, 적절한 양의 메모리가 TSB에 대해 할당될 수 있도록, 미디어 콘텐츠에 대한 플레이백 시간과 관련하여, TSB의 크기를 시그널링하기 위한 기술들을 설명한다. 이런 식으로, 미디어 데이터는, 트릭 모드(trick mode), 예를 들어 빨리 감기 또는 되감기를 이용하여 플레이백되고 그리고/또는 나중에(at a later time) 플레이백될 수 있다.

[0010] 일 예에서, 미디어 데이터를 리트리브하는 방법은, 프록시 유닛을 이용함으로써: 미디어 데이터를 리트리브하기 위한 서비스에 기초하여, 미디어 데이터에 대한 식별자를 리소스 로케이션에 맵핑하는 맵핑 정보를 획득하는 단계 ―상기 서비스는 미디어 데이터를 전송하기 위한 복수의 전송 타입들 중 적어도 하나를 정의함―, 애플리케이션 서비스 클라이언트로부터 미디어 데이터에 대한 요청을 수신하는 단계, 서비스가 이용가능한지를 결정하는 단계, 그리고 서비스가 이용가능한 경우, 애플리케이션 서비스 클라이언트로 하여금, 맵핑 정보에 기초하여, 리소스 로케이션으로부터의 서비스를 이용하여 미디어 데이터를 수신하는 유닛으로부터 미디어 데이터를 수신하게 하는 단계를 포함한다.

[0011] 다른 예에서, 미디어 데이터를 리트리브하기 위한 디바이스는, 미디어 데이터를 리트리브하기 위한 서비스에 기초하여, 미디어 데이터에 대한 식별자를 리소스 로케이션에 맵핑하는 맵핑 정보를 획득하고 ―상기 서비스는 미디어 데이터를 전송하기 위한 복수의 전송 타입들 중 적어도 하나를 정의함―, 애플리케이션 서비스 클라이언트로부터 미디어 데이터에 대한 요청을 수신하고, 서비스가 이용가능한지를 결정하고, 그리고 서비스가 이용가능한 경우, 애플리케이션 서비스 클라이언트로 하여금, 맵핑 정보에 기초하여, 리소스 로케이션으로부터의 서비스를 이용하여 미디어 데이터를 수신하는 유닛으로부터 미디어 데이터를 수신하게 하도록 구성되는, 프록시 유닛을 포함한다.

[0012] 다른 예에서, 미디어 데이터를 리트리브하기 위한 디바이스는, 미디어 데이터를 리트리브하기 위한 서비스에 기초하여, 미디어 데이터에 대한 식별자를 리소스 로케이션에 맵핑하는 맵핑 정보를 획득하기 위한 수단 ―상기 서비스는 미디어 데이터를 전송하기 위한 복수의 전송 타입들 중 적어도 하나를 정의함―, 애플리케이션 서비스 클라이언트로부터 미디어 데이터에 대한 요청을 수신하기 위한 수단, 서비스가 이용가능한지를 결정하기 위한 수단, 및 서비스가 이용가능한 경우, 애플리케이션 서비스 클라이언트로 하여금, 맵핑 정보에 기초하여, 리소스 로케이션으로부터의 서비스를 이용하여 미디어 데이터를 수신하는 유닛으로부터 미디어 데이터를 수신하게 하기 위한 수단을 포함한다.

[0013] 다른 예에서, 컴퓨터-판독가능 저장 매체에는 명령들이 저장되어 있고, 이 명령들은, 실행될 때, 프로세서로 하여금, 미디어 데이터를 리트리브하기 위한 서비스에 기초하여, 미디어 데이터에 대한 식별자를 리소스 로케이션에 맵핑하는 맵핑 정보를 획득하게 하고 ―상기 서비스는 미디어 데이터를 전송하기 위한 복수의 전송 타입들 중 적어도 하나를 정의함―, 애플리케이션 서비스 클라이언트로부터 미디어 데이터에 대한 요청을 수신하게 하고, 서비스가 이용가능한지를 결정하게 하고, 그리고 서비스가 이용가능한 경우, 애플리케이션 서비스 클라이언트로 하여금, 맵핑 정보에 기초하여, 리소스 로케이션으로부터의 서비스를 이용하여 미디어 데이터를 수신하는 유닛으로부터 미디어 데이터를 수신하게 한다.

[0014] 다른 예에서, 미디어 데이터를 프로세싱하는 방법은, TSB(time-shifted buffer) 깊이를 정의하는 속성(attribute)을 포함하는 세션 디스크립션 프로토콜(SDP) 메시지를 수신하는 단계, 속성의 값에 기초하여 TSB에 대한 메모리의 양을 결정하는 단계, TSB를 형성하기 위해, 결정된 양의 메모리를 할당하는 단계, TSB의 SDP 메시지와 연관된 미디어 데이터의 적어도 일부를 저장하는 단계를 포함한다.

[0015] 다른 예에서, 미디어 데이터를 프로세싱하기 위한 디바이스는, TSB(time-shifted buffer) 깊이를 정의하는 속성을 포함하는 세션 디스크립션 프로토콜(SDP) 메시지를 수신하고, 속성의 값에 기초하여 TSB에 대한 메모리의 양을 결정하고, TSB를 형성하기 위해, 결정된 양의 메모리를 할당하고, 그리고 TSB의 SDP 메시지와 연관된 미디어 데이터의 적어도 일부를 저장하도록 구성된, 하나 또는 그 초과의 프로세서들을 포함한다.

[0016] 다른 예에서, 미디어 데이터를 프로세싱하기 위한 디바이스는, TSB(time-shifted buffer) 깊이를 정의하는 속성을 포함하는 세션 디스크립션 프로토콜(SDP) 메시지를 수신하기 위한 수단, 속성의 값에 기초하여 TSB에 대한 메모리의 양을 결정하기 위한 수단, TSB를 형성하기 위해, 결정된 양의 메모리를 할당하기 위한 수단, 및 TSB의 SDP 메시지와 연관된 미디어 데이터의 적어도 일부를 저장하기 위한 수단을 포함한다.

[0017] 다른 예에서, 컴퓨터-판독가능 저장 매체에는 명령들이 저장되며, 이 명령들은, 실행될 때, 프로세서로 하여금, TSB(time-shifted buffer) 깊이를 정의하는 속성을 포함하는 세션 디스크립션 프로토콜(SDP) 메시지를 수신하게 하고, 속성의 값에 기초하여 TSB에 대한 메모리의 양을 결정하게 하고, TSB를 형성하기 위해, 결정된 양의 메모리를 할당하게 하고, 그리고 TSB의 SDP 메시지와 연관된 미디어 데이터의 적어도 일부를 저장하게 한다.

[0018] 도 1은 전송 다이버시티를 지원하기 위한 예시적 시스템을 예시한다.
[0019] 도 2a-도 2b는 전송 다이버시티를 지원하기 위한 리디렉터/프록시를 포함하는 장치의 대안적인 예들을 예시한다.
[0020] 도 3은 리디렉션 동작을 위해 구성된 리디렉터/프록시를 사용한 예시적 프로세스 흐름의 양상들을 예시한다.
[0021] 도 4는 프록시 동작을 위해 구성된 리디렉터/프록시를 사용하는 방법의 양상들을 예시한다.
[0022] 도 5는 전송 다이버시티를 지원하기 위한 방법의 예들을 예시한다.
[0023] 도 6은 도 5의 방법을 구현하기 위한 예시적인 장치를 예시한다.
[0024] 도 7 및 도 8은 전송 다이버시티를 지원하기 위한 추가 양상들을 예시한다.
[0025] 도 9 및 도 10은 RTP(Real-Time Transport Protocol)/RTSP(Real-Time Streaming Protocol) 스트리밍을 지원하기 위한 예시적인 MSDC(multicast services device client) 아키텍처들을 예시하는 블록도들이다.
[0026] 도 11은 예시적인 이벌브드 MBMS(eMBMS) USD(user service description) 스키마 스니펫(schema snippet)을 예시하는 개념도이다.
[0027] 도 12 및 도 13은 RTSP/RTP 클라이언트에 대한 전송 다이버시티를 지원하기 위한 예시적인 컴포넌트들을 예시하는 블록도들이다.
[0028] 도 14a 및 도 14b는 HTTP(DASH) 전송 정보를 통해 동적 적응성 스트리밍을 반송하기 위하여 USD를 확장하기 위한 예시적인 XML(extensible markup language) 콘텐츠 모델을 예시하는 개념도들이다.
[0029] 도 15는 MBMS를 통해 DASH를 지원하기 위한 예시적인 아키텍처를 예시하는 개념도이다.
[0030] 도 16은 브로드캐스트 및 유니캐스트 전송을 통한 DASH 콘텐츠 전달을 위한 도 15의 네트워크 아키텍처와 연관된 호-흐름을 예시하는 흐름도이다.
[0031] 도 17은 MBMS를 통해 DASH를 지원하기 위한 다른 예시적인 아키텍처를 예시하는 개념도이다.
[0032] 도 18-도 23은 브로드캐스트 및 유니캐스트 전송을 통한 DASH 콘텐츠 전달을 위해 도 17의 네트워크 아키텍처와 연관된 다양한 예시적 호-흐름들을 예시하는 흐름도들이다.
[0033] 도 24는 이 개시의 기술들에 따른 TSB(time-shifted buffer) 깊이에 관련된 데이터를 시그널링하기 위한 예시적인 방법을 예시하는 흐름도이다.

[0034] 일반적으로, 본 개시는, 네트워크를 통해, 미디어 데이터, 이를 테면 오디오 및/또는 비디오 데이터를 스트리밍하기 위한 다양한 타입들의 전송 메커니즘들을 지원하기 위한 기술들을 설명한다. 예를 들어, 애플리케이션 서비스 클라이언트(스트리밍 클라이언트로도 지칭될 수 있음)는 유니캐스트 프로토콜 또는 브로드캐스트(또는 멀티캐스트) 프로토콜에 따라 미디어 데이터를 리트리브하기 위해서 프록시 유닛과 상호작용하도록 구성될 수 있다. 일부 예들에서, 프록시 유닛은, 예를 들어 클라이언트 디바이스가 브로드캐스트 프로토콜을 사용하여 미디어 데이터를 전달하기 위한 서비스 제공자의 커버리지 구역 내에 있는지 여부에 기초하여, 미디어 데이터가 브로드캐스트 프로토콜을 사용하여 리트리브될 수 있는지를 결정할 수 있고, 클라이언트 디바이스가 커버리지 구역 내에 있는지 여부에 기초하여 유니캐스트 프로토콜 또는 브로드캐스트 프로토콜을 선택할 수 있다. 클라이언트 디바이스는 애플리케이션 서비스 클라이언트를 실행할 수 있고 그리고/또는 프록시 유닛을 포함할 수 있다. 일부 예들에서, 클라이언트 디바이스는 애플리케이션 서비스 클라이언트를 실행할 수 있으며, 프록시 유닛은 클라이언트 디바이스와 별개의 디바이스에 포함될 수 있다.

[0035] 본 개시의 기술들은 미디어 데이터를 스트리밍하기 위한 다양한 애플리케이션-계층 프로토콜들과 공조하여 사용될 수 있다. 예를 들어, 본 개시의 기술들은, 미디어 데이터를 스트리밍하기 위해 HTTP를 활용하는 DASH(Dynamic Adaptive Streaming over HTTP)와 공조하여 사용될 수 있다. 다른 예로서, 본 개시의 기술들은 실시간 전달 프로토콜(RTP) 또는 실시간 스트리밍 프로토콜(RTSP)과 공조하여 사용될 수 있다. 이러한 및 다른 경우들에서, 애플리케이션 서비스 클라이언트(예를 들어, RTP 클라이언트, RTSP 클라이언트, 또는 DASH 클라이언트)는, 애플리케이션 서비스 클라이언트가 미디어 데이터를 리트리브하기 위해 사용되는 전달 메커니즘을 인지할 필요가 없다는 의미에서, 전송-불가지론적(transport-agnostic)일 수 있다. 이를 테면, 애플리케이션 서비스 클라이언트는 기본 전송 메커니즘이 유니캐스트 프로토콜 또는 브로드캐스트 또는 멀티캐스트 프로토콜에 대응하는지 여부를 인지할 필요가 없다.

[0036] 아래에서 더 상세히 논의되는 바와 같이, 프록시 유닛(리디렉터/프록시 유닛으로도 지칭될 수 있음)은 애플리케이션 서비스 클라이언트로부터의 요청을 수신하도록 구성될 수 있고, 여기서 요청은 특정 미디어 데이터를 특정한다. 프록시 유닛은, 미디어 데이터가 특정 전송 메커니즘, 예를 들어 브로드캐스트 프로토콜 또는 유니캐스트 프로토콜을 사용하여 리트리브될 수 있는지 여부를 결정할 수 있다. 이후, 프록시 유닛은 애플리케이션 서비스 클라이언트로 하여금 (이용가능성, 선호도, 신뢰성 및/또는 다른 요인들에 기초하여) 전송 메커니즘들 중 하나를 사용하여 미디어 데이터를 수신하게 할 수 있다. 예를 들어, 만약 브로드캐스트 프로토콜이 유니캐스트 프로토콜보다 더 선호되고, 브로드캐스트 프로토콜이 이용가능하다면, 프록시 유닛은 애플리케이션 서비스 클라이언트로 하여금 브로드캐스트 프로토콜을 통해 미디어 데이터를 수신하게 할 수 있는데 반해, 만약 브로드캐스트 프로토콜이 이용가능하지 않다면, 프록시 유닛은 애플리케이션 서비스 클라이언트로 하여금 유니캐스트 프로토콜을 통해 미디어 데이터를 수신하게 할 수 있다.

[0037] 일 예로서, DASH에 관하여, 미디어 데이터는 하나 또는 그 초과의 서버들, 예를 들어 브로드캐스트 서버 및 유니캐스트 서버로부터 브로드캐스트 및/또는 유니캐스트 서비스로서 이용가능할 수 있다. DASH 클라이언트는, 미디어 데이터가 (서버(들)보다는 오히려) 프록시 유닛으로부터 이용가능하다는 것을 나타내는 미디어 데이터에 대한 변경된 미디어 프리젠테이션 디스크립션(MPD)을 수신할 수 있다. DASH 클라이언트가 프록시 유닛에 미디어 데이터에 대한 요청을 전송할 때, 프록시 유닛은 유니캐스트 프로토콜 또는 브로드캐스트 프로토콜이 요청된 미디어 데이터를 리트리브하기 위해 이용가능한지 여부를 결정할 수 있다. 만약 브로드캐스트 프로토콜이 이용가능하다면, 브로드캐스트 수신 유닛(예를 들어, 멀티미디어 브로드캐스트 멀티캐스트 서비스들(MBMS) 또는 이벌브드 MBMS(eMBMS) 미들웨어 유닛)은 미디어 데이터를 수신할 수 있고, 프록시 유닛은 DASH 클라이언트로 하여금 미디어 데이터에 대한 요청을 브로드캐스트 수신 유닛에 전송하게 할 수 있다. 다른 한편으로, 만약 브로드캐스트 프로토콜이 이용가능하지 않다면, 프록시 유닛은 DASH 클라이언트로 하여금 유니캐스트를 사용하여 미디어 데이터를 리트리브하기 위해 미디어 데이터에 대한 요청을 유니캐스트 서버에 전송하게 할 수 있다. 대안적으로, 프록시 유닛은 유니캐스트 서버로부터 미디어 데이터를 리트리브할 수 있고, 이후 리트리브된 미디어 데이터를 DASH 클라이언트에 제공할 수 있다. 일부 예들에서, 유니캐스트 서버 및 브로드캐스트 서버는 동일한 서버에 대응할 수 있다.

[0038] 다른 예로서, RTP 또는 RTSP에 관해, RTP 클라이언트(대안적으로는, RTSP 클라이언트에 대응할 수 있음)는 DESCRIBE, SETUP 및 PLAY 커맨드들을 프록시 유닛에 제출할 수 있다. DESCRIBE 커맨드에 응답하여, 프록시 유닛은 변경된 세션 디스크립션 프로토콜(SDP) 메시지를 RTP 클라이언트에 제공할 수 있다. 변경된 SDP 메시지는 프록시 유닛의 어드레스를 미디어 데이터가 이용가능한 어드레스로서 특정할 수 있다. 이러한 변경된 SDP 메시지는 RTP 클라이언트로 하여금 SETUP 및 PLAY 커맨드들을 프록시 유닛에 전송하게 할 수 있다. 브로드캐스트 프로토콜이 이용가능하다고 프록시 유닛이 결정할 때, 프록시 유닛은 SETUP 또는 PLAY 커맨드들을 브로드캐스트 수신 유닛(예를 들어, MBMS 또는 eMBMS 미들웨어 유닛)에 전송할 수 있고, 그 브로드캐스트 수신 유닛은 미디어 데이터를 수신하고 그 미디어 데이터를 RTP 클라이언트에 포워딩할 수 있다. 다른 한편으로는, 브로드캐스트 프로토콜이 이용가능하지 않다고 프록시 유닛이 결정할 때, 프록시 유닛은 유니캐스트 서버로부터 미디어 데이터를 리트리브하고, 이후 리트리브된 미디어 데이터를 RTP 클라이언트에 제공할 수 있다.

[0039] 일부 예들에서, 본 개시의 기술들을 수행하기 위한 컴포넌트들은 애플리케이션 서비스 클라이언트, 프록시 유닛, 및 브로드캐스트 수신 유닛을 포함할 수 있다. 다양한 예들에서, 클라이언트 디바이스는 이러한 컴포넌트들 중 임의의 컴포넌트 또는 모든 컴포넌트를 단독으로 또는 임의의 조합으로 포함할 수 있다. 대안적으로, 클라이언트 디바이스는 애플리케이션 서비스 클라이언트를 포함할 수 있고, 프록시 유닛 및/또는 브로드캐스트 수신 유닛은 클라이언트 디바이스와 별개인 하나 또는 그 초과의 디바이스들에 포함될 수 있다.

[0040] 게다가, 본 개시는 또한 TSB(time-shifted buffer)를 위한 데이터를 시그널링하는 것에 관련된 기술들을 설명한다. 클라이언트 디바이스("사용자 장비"로도 본원에서 지칭됨)는 다양한 트릭 모드들, 이를 테면 빨리감기, 되감기, 리플레이 등의 지원에 있어 미디어 데이터를 홀딩하기 위해 사용될 TSB를 형성하기 위해서 메모리를 할당할 수 있다. 일반적으로, 트릭 모드는 미디어 데이터가 정의된 출력 순서 대로 또는 그 순서와는 다른 레이트로 플레이백되는 플레이백 모드를 지칭할 수 있다. 이를 테면, 빨리감기에서는, 특정 미디어 데이터가 스킵될 수 있다. 다른 예로서, 되감기에서는, 미디어 데이터에 대한 출력 순서가 거꾸로 될 수 있고, 특정 미디어 데이터가 또한 스킵될 수 있다. 예를 들어 비디오 데이터에 대해서 미디어 데이터를 스킵하기 위해, 인트라-코딩 모드를 사용하여 코딩된 픽처들(pictures)만이 디스플레이되고 인터-코딩된 픽처들은 스킵될 수 있다.

[0041] 본 개시의 기술들에 따라, 데이터는 TSB를 예시하기 위해 예를 들어 SDP 메시지에서 시그널링될 수 있다. 예를 들어, TSB에 저장될 수 있는 미디어 데이터의 양을 초 단위로 정의하는 값을 갖는 TSB 속성이 시그널링될 수 있다. 클라이언트 디바이스는 TSB 속성의 값에 기초하여 TSB를 위해 필요한 메모리의 양을 계산할 수 있다. 이러한 계산은 예로서 비디오 데이터에 대해, 미디어 데이터에 비디오 데이터의 프레임 레이트를 포함시킬 수 있다. 클라이언트 디바이스는 픽처 마다의 데이터의 평균 양, (프레임 레이트에 기초하여) 시간 기간에서 픽처들의 수, 및 TSB 속성에 의해 정의되는 시간의 길이에 기초하여 TSB에 대한 메모리 크기를 계산할 수 있다. 마찬가지로, 클라이언트 디바이스는 오디오 데이터, 텍스트 데이터, 또는 시간 기간 동안의 다른 데이터 또는 미디어를 위해 필요한 메모리의 양을 추가로 결정할 수 있다. 따라서, 클라이언트 디바이스는 트릭 모드들을 수행하기 위해 미디어 데이터를 저장하기 위한 TSB에 이러한 데이터를 할당할 수 있다. 게다가, 클라이언트 디바이스는 브로드캐스트 프로토콜, 이를 테면 MBMS 또는 eMBMS를 통해 수신되는 데이터에 대해 트릭 모드들을 수행할 수 있다.

[0042] 즉, 일부 예들에서는, 본 개시의 기술들은 이벌브드 멀티미디어 브로드캐스트 멀티캐스트 서비스(eMBMS) 네트워크를 통해 실시간 프로토콜/실시간 스트리밍 프로토콜(RTP/RTSP) 스트리밍의 특징들(features)을 지원하기 위한 미들웨어 아키텍처를 포함한다. 이러한 특징들은 시간-시프트 버퍼 및 전송 다이버시티(예를 들어, 콘텐츠 전달을 위한 유니캐스트-브로드캐스트 스위칭 또는 이 반대로의 스위칭)를 포함한다. 시간-시프트 버퍼(TSB) 특징의 경우, 아키텍처는 버퍼 깊이를 시그널링하는 데이터를 포함하기 위해 세션 디스크립션 프로토콜(SDP)의 연장을 지원할 수 있다. 전송 다이버시티 특징의 일 예로서, 본 개시는, 콘텐츠를 소모하는 애플리케이션들이 유니캐스트로부터 브로드캐스트로 또는 그 반대로의 전송 스위칭의 세부사항들을 인지할 필요가 없는 아키텍처를 설명하고 제안하는데, 그 이유는 이러한 스위칭이 미들웨어 레벨에서 관리될 수 있기 때문이다.

[0043] HTTP 스트리밍에서, 자주 사용되는 동작들은 GET 및 부분 GET를 포함한다. GET 동작은 정해진 URI(uniform resource identifier)(예를 들어, URL 또는 URN)와 연관된 전체 파일의 리트리벌을 요청한다. 부분 GET 동작은 리소스의 바이트 범위(서브세트)의 리트리벌을 요청한다. 따라서, 무비 프래그먼트들은 HTTP 스트리밍을 위해 제공될 수 있는데, 그 이유는 GET 또는 부분 GET 동작이 하나 또는 그 초과의 개별적인 무비 프래그먼트들을 리트리브할 수 있기 때문이다. 무비 프래그먼트에서는, 상이한 트랙들의 몇몇 트랙 프래그먼트들이 존재할 수 있다. HTTP 스트리밍에서, 미디어 프리젠테이션은 클라이언트에 액세스가능한 데이터의 구조화된 컬렉션일 수 있다. 클라이언트는 사용자에게 스트리밍 서비스를 제공하기 위해서 미디어 데이터 정보를 요청하고 다운로딩할 수 있다.

[0044] HTTP를 사용하여 DASH 데이터를 스트리밍하는 예에서, 비디오 및/또는 멀티미디어 콘텐츠의 오디오 데이터에 대해 다수의 표현(representation)들이 있을 수 있다. 이러한 표현들의 매니페스트(manifest)는 미디어 프리젠테이션 디스크립션(MPD) 데이터 구조에서 정의될 수 있다. 미디어 프리젠테이션은 HTTP 스트리밍 클라이언트 디바이스에 액세스 가능한 데이터의 구조화된 컬렉션에 대응할 수 있다. HTTP 스트리밍 클라이언트 디바이스는 클라이언트 디바이스의 사용자에게 스트리밍 서비스를 제공하기 위해 미디어 데이터 정보를 요청하고 다운로드 할 수 있다. 미디어 프리젠테이션은 MPD의 동적 업데이트를 포함할 수 있는 MPD 데이터 구조에서 설명될 수 있다.

[0045] 미디어 표현은 하나 또는 그 초과의 기간들의 시퀀스를 포함할 수 있다. 기간들은 MPD의 기간 엘리먼트에 의해 정의될 수 있다. 각 기간은 MPD에서 속성 시작을 가질 수 있다. MPD는 각 기간 동안 시작 속성과 availablityStartTime 속성을 포함할 수 있다. 라이브 서비스의 경우, 기간의 시작 속성과 MPD 속성 availableStartTime의 합은 UTC 포맷에서 기간의 가용 시간, 특히 대응하는 기간의 각 표현의 첫 번째 미디어 세그먼트를 특정할 수 있다. 주문형(on-demand) 서비스의 경우, 제 1 기간의 시작 속성은 0일 수 있다. 임의의 다른 기간 동안, 시작 속성은 제 1 기간의 시작 시간에 관련한 대응하는 기간의 시작 시간 사이의 시간 오프셋을 특정할 수 있다. 각 기간은 다음 기간의 시작까지, 또는 마지막 기간의 경우, 미디어 프리젠테이션의 마지막까지 연장할 수 있다. 기간 시작 시간들은 정확할 수 있다. 이들은 모든 이전 기간의 미디어를 재생하는 것에서 유래하는 실제 타이밍을 반영할 수 있다.

[0046] 각 기간은 동일한 미디어 콘텐츠에 대해 하나 또는 그 초과의 표현들을 포함할 수 있다. 표현은 오디오, 비디오 또는 다른 데이터의 다수의 대안적인 인코딩된 버전들 중 하나일 수 있다. 표현들은 인코딩 타입들에 따라, 예를 들어, 비디오 데이터에 대한 코덱, 해상도 및/또는 비트레이트, 및 오디오 데이터에 대한 코덱, 언어 및/또는 비트레이트에 따라 다를 수 있다. 표현이라는 용어는, 멀티미디어 콘텐츠의 특정 기간에 대응하고 특정 방식으로 인코딩되는, 인코딩된 오디오 또는 비디오 데이터 또는 다른 미디어나 데이터의 섹션을 지칭하는데 사용될 수 있다.

[0047] 특정 기간의 표현들은 MPD에서 그룹 속성에 의해 표시된 그룹에 할당될 수 있다. 동일 그룹의 표현들은 일반적으로 서로에 대해 대안적인 것으로 간주된다. 예를 들면, 특정 기간에 대한 비디오 데이터의 각각의 표현은 동일한 그룹에 할당될 수 있어서, 임의의 이러한 표현들은 해당 기간 동안 멀티미디어 콘텐츠의 비디오 데이터를 디스플레이하도록, 디코딩을 위해 선택될 수 있다. 한 주기 내의 미디어 콘텐츠는, 일부 예들에서, 그룹 0으로부터의 하나의 표현, 또는 존재하는 경우, 각각의 0이 아닌 그룹으로부터의 최대 하나의 표현의 조합에 의해 표현될 수 있다. 기간의 각 표현에 대한 타이밍 데이터는 기간의 시작 시간과 관련하여 표현될 수 있다.

[0048] 표현은 하나 또는 그 초과의 세그먼트들을 포함할 수 있다. 각각의 표현은 초기화 세그먼트를 포함할 수 있거나, 표현의 각 세그먼트는 자체 초기화될 수 있다. 존재하는 경우, 초기화 세그먼트는 표현에 액세스하기 위한 초기화 정보를 포함할 수 있다. 일반적으로, 초기화 세그먼트는 미디어 데이터를 포함하지 않는다. 세그먼트는 고유하게, 식별자, 이를 테면, URI(uniform resource identifier) (예를 들면, URL(uniform resource locator) 또는 URN(uniform resource name))를 이용하여 참조될 수 있다. MPD는 각각의 세그먼트에 대한 식별자를 제공할 수 있다. 일부 예들에서, MPD는 또한, 해당 URI를 참조하여 액세스가능한 리소스(예를 들면, 파일) 내의 세그먼트의 연속적인 바이트 범위에 대한 데이터에 대응할 수 있는, 범위(range) 속성의 형태로 바이트 범위들을 제공할 수 있다.

[0049] 각각의 표현은 또한 하나 또는 그 초과의 미디어 컴포넌트들을 포함할 수 있으며, 여기서 각 미디어 구성 요소는 오디오, 비디오, 또는 (예를 들어, 폐쇄 자막에 대한) 타이밍 텍스트와 같은 하나의 개별 미디어 타입의 인코딩된 버전에 대응할 수 있다. 미디어 컴포넌트들은 일 표현 내에서 연속 미디어 세그먼트의 경계에 걸쳐 시간 연속적일 수 있다.

[0050] 본원에서 설명된 기술들은 위에서 언급된 무선 네트워크 및 라디오 기술들뿐만 아니라 다른 무선 네트워크와 라디오 기술들에 사용될 수 있다. 명확성을 위해, 기술들의 특정 양상들이 LTE에 대해 아래에서 설명되며, LTE 용어가 아래 설명의 많은 부분에서 사용된다.

[0051] RTP/RTSP 스트리밍은 실시간 스트리밍 서비스를 지원하기 위한 공통 프로토콜이다. eMBMS 서비스를 위한 3GPP 규격은 LTE(Long Term Evolution) 네트워크들을 통한 RTP 스트리밍을 위한 아키텍처를 설명한다. 그러나, 본 개시는 RTP/RTSP에 있어서 두 가지 문제를 인식하며, 이러한 문제들을 해결하기 위해 사용될 수 있는 기술들을 논의한다.

[0052] 시간-시프트 버퍼(TSB)는 사용자 장비(UE)에서 미디어 콘텐츠의 일부를 저장하기 위해 사용될 수 있는 특징이다. 버퍼는 사용자가 앞뒤로 미디어 콘텐츠의 플레이백 포인트로 이동할 수 있게 한다. 이 프로세스에서, UE에 버퍼 깊이가 통보될 필요가 있는데, 버퍼 깊이는 트릭 모드 플레이백, 예를 들면, 플레이백의 빨리 감기와 되감기를 허용하기 위해 얼마나 많은 시간 가치의 콘텐츠(time worth of content)를 UE가 디바이스에 축적할 필요가 있는지의 표시를 제공한다. VLC 미디어 플레이어의 일 구현에서, TSB 특징은 시작시 VLC 플레이어에 대한 인수(argument)로서 버퍼 깊이를 제공함으로써 이네이블된다. 프로세스는 자동이 아니며, 대신에, 버퍼 깊이 인수를 제공하고 결과적으로 TSB를 이네이블하기 위해 사용자의 개입을 필요로 한다. 본 개시는 멀티캐스트 서비스 디바이스 클라이언트(MSDC)와 같은 eMBMS 이네이블된 미들웨어 계층에서 TSB를 지원하는 기술을 설명한다.

[0053] 세션 디스크립션 프로토콜(SDP)은, 총체적으로 "세션 프로파일"로서 알려진 스트리밍 서비스의 엔드포인트 정보 및 그 미디어 스트림(세션) 관련 파라미터들을 설명한다. 따라서, 스트리밍 서비스가 서로 다른 전송 방법들에서 이용가능한 경우, 서비스에 대한 서로 다른 전송/엔드포인트 파라미터들을 설명하는 다수의 프로파일들이 필요하다. 예를 들면, 브로드캐스트 실시간 RTP 기반 서비스는 그 미디어 스트림들에 대한 멀티캐스트 IP 어드레스와 포트를 참조할 수 있는 반면, 서비스의 유니캐스트 버전은 유니캐스트 IP 어드레스와 포트를 참조할 수 있다. 브로드캐스트 및 유니캐스트 전달 방법들에 대해 미디어 스트림들의 다른 표현들이 존재할 수 있다. LTE 네트워크에서, MSDC는 eMBMS 이네이블된 애플리케이션들로의 스트리밍 서비스의 전달을 제공한다. 유니캐스트 전송 방법과 다른(예를 들어, 브로드캐스트 또는 멀티 캐스트) 전송 방법 사이의 스위칭을 지원하기 위해, 다수의 세션 프로파일들을 사용하는 것이 필요하며, 세션 프로파일의 선택은 UE가 브로드캐스트의 커버리지 밖에 있는지 또는 커버리지 내에 있는 지에 주로 기반할 것이다. UE가 브로드캐스트 커버리지 구역으로 이동할 때마다, MSDC는 접속을 설정하고 콘텐츠를 소비하기 위해 SDP 프로파일의 브로드캐스트 이네이블된 버전을 사용할 수 있다. 그러나, 반대 시나리오에서, UE가 브로드캐스트 커버리지 밖으로 이동할 때, MSDC는 유니캐스트 콘텐츠를 소비하기 위해 유니캐스트 SDP를 사용하고 원격 RTSP 서버와 유니캐스트 접속을 설정할 필요가 있을 수 있다. 유니캐스트 및 브로드캐스트 사이의 전환(transition)들을 사용자들이나 애플리케이션들이 알지 못하게 하기 위해, 본 개시는 끊김 없는 전환을 위한 메커니즘을 설명한다.

[0054] 본 개시는 다른 기술들 중에서도, TSB의 지원과 관련된 기술들 및 전송 스위칭을 지원하기 위한 기술들을 설명하는데, 이들은 단독으로, 함께 그리고/또는 본 개시에서 설명된 다른 기술들과 조합하여 사용될 수 있다. eMBMS를 통한 RTP 기반 스트리밍에서 TSB 특징을 가능하게 하기 위해, 본 개시는 시간-시프트 버퍼의 깊이 값을 시그널링하기 위해 SDP 메커니즘의 확장을 사용하기 위한 기술들을 설명한다. 전송 스위칭 문제에 대해, 본 개시는 유니캐스트 및 브로드캐스트 디스크립션들 모두를 포함하는 SDP 디스크립션을 위한 통합된 접근방식을 설명한다. 또한, 브로드캐스트와 유니캐스트 사이의 전환을 애플리케이션/사용자에 대해 끊김 없이하기 위해, 본 개시는 미들웨어 기반 솔루션을 설명하며, 여기서, 미들웨어는 통합된 SDP를 사용하여 콘텐츠의 리디렉션을 핸들링하여, 사용자들로부터의 프로세스를 숨긴다.

[0055] 본 개시의 청구대상의 양상들에 따라, 추상화 계층(layer of abstraction)을 제공하기 위해 디바이스들의 컬렉션 또는 클라이언트 디바이스 내의 배치를 위한 방법, 장치 및 아키텍처가 제공되며, 여기서, 다수의 상이한 타입들의 전송 메카니즘들/프로토콜들(예를 들어, eMBMS, 디지털 비디오 브로드캐스트(DVB) 등)이, 예를 들어, 클라이언트의 애플리케이션에 메타-데이터 및 디지털 콘텐츠를 전달하도록 사용될 수 있다. 애플리케이션들이 각 개별 전송의 세부 사항을 인식할 필요는 없다. 본 개시는 애플리케이션에 전달되는 데이터 및 메타-데이터의 이용가능성의 타이밍, 로케이션 또는 선택을 결정하기 위해 사용될 수 있는 구성가능한 정책들의 세트에 대한 옵션을 포함할 수 있다.

[0056] 인터넷 상에서 웹 콘텐츠를 액세스하는 애플리케이션들은 HTTP 또는 HTTP 보안(HTTPS) 스킴들(schemes)을 사용하는 URL(universal resource locator)일 수 있는 URI(universal resource identifier)를 사용하여 콘텐츠(또는 그 구성 부분들)를 식별할 수 있다. 예를 들면, MPEG-DASH의 맥락에서, HTTP 또는 HTTPS 스킴들을 포함하는 URL 참조들은 HTTP 또는 HTTPS 프로토콜들을 사용하여 해결될 수 있다. 또한, HTTP는 URL들에 의해 참조되는 데이터를 페치하는데 사용될 수 있다. DASH 표준은 비-HTTP URL들을 활용할 수 있고, 본 개시는 요청들이 다른 시간에 다른 로케이션로 디렉팅되게 하는 옵션을 제공하고 그리고/또는 요청 클라이언트가 대안적인 콘텐츠에 액세스하도록 명령하는 플렉시블한 방식으로, 클라이언트들로부터의 임의의 요청들(HTTP 기반 요청들을 포함함)이 핸들링되는 경우들과 관련될 수 있다.

[0057] 본 개시의 기술들은 콘텐츠에 대한 클라이언트 요청들을 핸들링하는 리디렉터 기능의 예시(instantiation)를 수반할 수 있다. 클라이언트가 후속 요청을 어디서 수행할지를 알 수 있도록, 리디렉터(본원에서 리디렉터/프록시로 또한 지칭됨)는 클라이언트 요청에서 식별된 자료(material)에 대한 프로세싱을 적용하고, 이 프로세싱의 결과를 매칭 기준들의 테이블과 비교하기 위한 방법 또는 알고리즘을 호출하고, 그리고 대안적인 로케이션, 액세스 방법, 타이밍 정보 또는 콘텐츠(예를 들어, 파일로)를 클라이언트에 나타낼 수 있다. 다른 양상에서, 리디렉터는 클라이언트를 대신하여 콘텐츠에 대한 요청을 수행할 수 있고 요청된 콘텐츠를 페치할 수 있다. 이 경우, 리디렉터는 프록시 또는 귀납적 함수로 작용할 수 있다.

[0058] 도 1은 전송 다이버시티를 지원하기 위한 예시적인 시스템(100)을 도시하는 블록도이다. 예시적인 시스템(100)은, 예를 들어, 모바일 디바이스의 애플리케이션(101)을 포함할 수 있다. 애플리케이션(101)은 콘텐츠에 대한 요청을 수행할 수 있다. 예를 들어, DASH 멀티미디어 플레이백 애플리케이션이 매니페스트(manifest) 또는 MPD를 프로세싱하고, 메타-데이터 및 데이터를 포함하는 URL들을 결정하고, HTTP 요청들을 송신한다. 콘텐츠에 대한 요청은, 미리결정된, 또는 미리구성된, 또는 동적으로 결정된 프로토콜 포트(예를 들어, TCP 또는 UDP를 가짐), 이를 테면, 웹 브라우저의 "프록시" 함수(function)를 구성하는 데 통상적으로 이용될 수 있는 프로토콜을 이용할 수 있다. 프로토콜 포트를 결정하는 것은, 이를 테면 PAC(proxy auto-config) 파일로, 또는 프로토콜에 의해, 이를 테면 WPAD(web proxy auto-discovery protocol)에 의해, 예를 들어 사용자 또는 네트워크/시스템 관리자에 의해 확립되는 구성 파일을 이용하는 것을 포함할 수 있다.

[0059] 리디렉터/프록시(104)는 애플리케이션 서비스 클라이언트(102)를 통해 애플리케이션(101)의 요청을 수신하고, 그러한 요청을 프로세싱 또는 분석(parse)하여, 요청된 콘텐츠를 결정할 수 있다. 리디렉터/프록시(104)는, 그러한 결과를, 매칭 기준들을 포함하는 테이블(또는 다른 적합한 타입의 데이터 구조)와 비교하여, 매치가 발생했는지를 결정할 수 있다. 매치가 발생하면, 리디렉터/프록시(104)는 리디렉션 타겟을 결정할 수 있다. 타겟은 애플리케이션(101)에 전달될 수 있다. 다른 양상에서, 리디렉터/프록시(104)는 반복적인 방식으로 작동할 수 있으며, 애플리케이션(101)은 리디렉션 타겟을 프로세싱할 필요가 없을 수도 있다. 예를 들어, 리디렉터/프록시(104)가 애플리케이션(101) 대신에 리디렉션 타겟에 기초하여 콘텐츠를 페치할 수 있다.

[0060] 리디렉터/프록시(104)는 동일한 디바이스 상에 애플리케이션(101)과 코-로케이트(co-locate)될 수 있거나, 또는 리디렉터/프록시(104)는 별개의(separate) 디바이스 상에 로케이트될 수 있다. 리디렉터/프록시(104)가 코-로케이트되는 경우, 애플리케이션(101)은 HTTP, API(application programming interface), IPC(inter-process communication) 등을 통해 리디렉터/프록시(104)와 통신할 수 있다. 리디렉터/프록시(104)가 별개의 디바이스 상에 로케이트되는 경우, 애플리케이션(101)은 HTTP을 통해 (애플리케이션 서비스 클라이언트(102)를 통하여) 리디렉터와 통신할 수 있는 식이다.

[0061] "매치(match)" (또는 비-매치(non-match))를 결정한 이후, 리디렉션 타겟이 애플리케이션(101)에 제공될 수 있다. 타겟은, 애플리케이션(101)에 의해 요청되는 콘텐츠 오브젝트(들) 대신 액세스할 대안적인 콘텐츠 오브젝트(들)를 표시할 수 있다. 리디렉션 타겟을 애플리케이션(101)에 표시할 수 있는 다양한 방법들이 있을 수 있다.

[0062] 시스템(100)의 컴포넌트들 간의 시그널링은 API 또는 IPC를 이용하여 수행될 수 있다. 이러한 양상에서, 애플리케이션(101)과 리디렉터/프록시(104) 간의 통신을 제공하기 위해 API 또는 IPC 메커니즘이 활용될 수 있다. API를 이용하는 경우, 리디렉터/프록시(104)는, 리디렉트 타겟을 표시하기 위해 애플리케이션 라이브러리 또는 애플리케이션(101) 내에서 구현되는 방법들 또는 절차들을 호출(invoke)할 수 있다.

[0063] 시스템(100)의 컴포넌트들 간의 시그널링은 메타-데이터 리-라이팅(re-writing)을 통해 수행될 수 있다. 이러한 양상에서, 메타-데이터(예를 들어, DASH MPD)는 오브젝트들에 대한 대안적인 레퍼런스들을 표시하기 위해 리-라이트될 수 있다. 예를 들어, 최초의 메타-데이터에 존재하는 URI는, 등가(equivalent) 또는 교체(replacement) 콘텐츠를 액세스하기 위한 대안적인 URI를 형성하기 위해 리-라이트될 수 있다.

[0064] 시스템(100)의 컴포넌트들 간의 시그널링은 통신 프로토콜들에서의 표시들을 이용하여 수행될 수 있다. 이러한 양상에서, 애플리케이션 계층 통신 프로토콜(예를 들어, HTTP)은, 애플리케이션(101)에 시그널링 정보를 전달하는 방식으로 활용될 수 있다. 하나의 변형에서, "리디렉트"의 HTTP 응답 코드 카테고리가 이용될 수 있다(예를 들어, 이는 폼(form) 3xx의 코드들에 해당할 수 있으며, 여기서 x는 0부터 9까지의 수일 수 있다). 이러한 변형의 하나의 하위사례(subcase)에 있어서, 예를 들어, (이용가능한 다수의 선택들을 표시하는) 코드(300)가 이용될 수 있으며, 여기서, 리디렉터/프록시(104)는 레퍼런스들(예를 들어, URI들)의 벡터를 제공하며, 이로부터, 애플리케이션(101)이 사용하기 위한 하나 또는 그 초과를 선택할 수 있다.

[0065] 매칭 함수는, 애플리케이션(101)으로부터 비롯된 오브젝트 레퍼런스들(예를 들어, 요청 URI)과 데이터 구조에 존재하는 오브젝트 레퍼런스들(예를 들어, 파일, 데이터베이스, 매칭 테이블 등)을 비교한 결과를 제공할 수 있다.

[0066] 일 양상에서, 비제한적인 예들로, 매칭 기준들은 URI 프리픽스들로서 표현될 수 있으며, 발생하는 단일의 바람직한 매치는 (예를 들어, 공동으로(in common) 비트들 또는 바이트들의 개수에 의해 결정되는) 가장 긴 프리픽스를 갖는 매치에 의해 표시된다. 다른 양상에서, 각각의 잠재적인 매치에는 대응하는 우선순위 번호(priority number)가 할당될 수 있으며, 가장 큰 (또는 가장 작은) 우선순위 번호를 갖는 엔트리가 선택될 수 있다.

[0067] 다른 양상에서, 매칭 기준들은 규칙적인 표현들로서 표현될 수 있으며, 바람직한 매치는 매칭 캐릭터들(characters)의 가장 큰 수를 이용하여 결정될 수 있다. 다른 변형에서, 규칙적인 표현들을 이용하여 매칭 기준들을 표현할 수 있으며, 가장 큰 (또는 가장 작은) 우선순위 번호를 갖는 잠재적인 매치가 선택될 수 있다.

[0068] 상기 논의된 데이터 구조의 매칭 알고리즘 또는 콘텐츠들은, 미리결정되거나 미리구성될 수 있는 정책들(policies)에 기초할 수 있다. 다른 양상에서, 이러한 정책들은 논리적 정책 데이터베이스(logical policy database)에 동적으로 부가될 수 있거나 또는 이로부터 삭제될 수 있다. 정책 데이터베이스는 다양한 데이터 구조들을 이용하여 구현될 수 있으며, 그리고 임의의 특정한 타입의 데이터 구조 또는 데이터베이스 구현으로 제한되지 않는다.

[0069] 정책들은, 예를 들어, 하나의 소스로부터의 매칭 기준들을 다른 것(들)에 비해 우선순위화하거나(prioritizing) 우선순위를 해제하는 것(de-prioritizing)(예를 들어, 하나의 전송 타입이 다른 것(들)에 비해 장려되고(favor)/꺼려질(disfavored) 수 있다); 소스, 시간, 리디렉션 타겟, 및/또는 매칭 기준 값의 함수로써 매칭 기준들을 제거하는 것; 소스 또는 시간 또는 리디렉션 타겟 또는 매칭 기준 값의 함수로써 매칭 기준들을 부가하는 것; 및/또는 소스 또는 시간 또는 리디렉션 타겟 또는 매칭 기준 값의 함수로써 매칭 기준들을 수정하는 것(modifying)을 포함하는 다수의 방법들에서의 매칭 알고리즘의 동작을 결정하기 위해 이용될 수 있다.

[0070] 예시적인 시스템(100)은, 리디렉팅된 로케이션에 기반하여 콘텐츠를 요청하기 위한 전송 미들웨어(110)를 포함할 수 있다. 전송 미들웨어(110)는 다수의 전송 메커니즘들/ 프로토콜, 이를 테면 전송 A(110A) 내지 전송 R(110 R)을 포함할 수 있다. 각각의 전송 메커니즘(전송 A(110A) 내지 전송 R(110 R))은, 파일 정보의 리스트 및 상세사항들(details)을 획득할 수 있고 그리고 예를 들어 요약(summarizing) URI 또는 공통 URI 프리픽스를 생성할 수 있는 해당 모듈을 가질 수 있다. 이들 모듈들은 이러한 정보를 통신 메커니즘(예를 들어, IPC, API 또는 프로토콜)을 통해 제어기(106)에 전달할 수 있으며, 제어기(106)는 정책 및 레졸루션(resolution)을 적용할 수 있고, 결국, 그러한 정책에 영향을 받는 리디렉터/프록시(104)를 프로그램할 수 있다. 전송 메커니즘들(전송 A(110A) 내지 전송 R(110 R))은, 예를 들어, eMBMS, DVB-T2, DVB-S, 다른 DVB-패밀리 브로드캐스트 기술들 등을 포함할 수 있다. 각각의 전송 미들웨어는, 콘텐츠 또는 다른 데이터를 저장하기 위한 캐시를 포함할 수 있다. 예를 들어, 전송 미들웨어는, 애플리케이션(101)으로의 콘텐츠 전달이 사용자에게 순간적인(instantaneous) 것으로 보일 수 있도록 콘텐츠의 시작 세그먼트를 캐싱할 수 있다. 전송 미들웨어(110)는 콘텐츠 서버(120)와 같은 소스로부터 콘텐츠를 요청할 수 있다. 부가적으로 또는 대안적으로, 클라이언트는, 인터넷(122)을 포함하는 네트워크를 통해 콘텐츠를 요청할 수 있다. 프록시 또는 "반복적" 동작을 위해 구성된 리디렉터/프록시(104)에 대해, 리디렉터/프록시(104)는 전송 미들웨어(110)를 통해 또는 네트워크 또는 인터넷(122)을 통해 콘텐츠를 요청할 수 있다. 리디렉터/프록시(104)는 리디렉션 또는 프록시 역할들(roles) 중 하나로 동작하도록 미리구성될 수 있다. 리디렉터/프록시(104)의 역할은, 예를 들어 룰들의 세트에 기초하여, 실행 시간(run-time)에서 결정될 수 있다.

[0071] 도 2a-2b는 전송 다이버시티를 지원하기 위한 리디렉터/프록시(104)를 포함하는 장치들의 대안적인 예들을 도시한다. 리디렉터/프록시(104), 정책 데이터베이스(108)를 갖는 제어기(106), 또는 전송 미들웨어(110) 중 임의의 것 또는 전부는, 디바이스 상에 클라이언트 및 애플리케이션(101)과 코-로케이트될 수 있거나, 또는 별개의 디바이스(들) 상에 로케이트될 수 있다. 도 2a의 예에서, 시스템(200a)은 UE(101a) 상에 애플리케이션(101) 및 클라이언트와 코-로케이트된 것으로 나타나있는 리디렉터/프록시(104a)를 포함한다. 예를 들어, 애플리케이션 서비스 클라이언트(102a)는 DASH 클라이언트, HTTP 라이브 스트리밍(HLS), 애플 라이브 스트리밍(ALS) 클라이언트, 적응형 HTTP 스트리밍(AHS) 클라이언트, 또는 임의의 다른 적합한 클라이언트일 수 있다. 애플리케이션 서비스 클라이언트(102a)는, HTTP, API, IPC, 또는 임의의 다른 적합한 프로토콜 또는 방식을 통해 리디렉터/프록시(104a)와 통신할 수 있다. 도 2b의 예에서, 시스템(200b)은, UE(101b) 상에 로케이트된 애플리케이션(101) 및 애플리케이션 서비스 클라이언트(102b)와 별개의 엔티티(110) 상에 로케이트된 것으로 나타나있는 리디렉터/프록시(104b)를 포함한다. 예를 들어, 애플리케이션 서비스 클라이언트(102b)는 DASH 클라이언트, HLS (ALS) 클라이언트, AHS 클라이언트, 또는 임의의 다른 적합한 클라이언트일 수 있다. 애플리케이션 서비스 클라이언트(102b)는, HTTP, 또는 임의의 다른 적합한 프로토콜 또는 방식을 통해 리디렉터/프록시(104b)와 통신할 수 있다. 리디렉터/프록시(104b)는, 이를 테면, 프록시 서버, 게이트웨이, 라우터 등과 같은 임의의 적합한 네트워크 엔티티 상에 로케이트될 수 있다.

[0072] 도 3은, 리디렉션 동작을 위해 구성된 리디렉터/프록시를 사용하는 예시적인 프로세스 흐름(320)의 양상들을 예시하는 흐름도이다. 프로세스 흐름(320)의 개시 전에, 제어기(106)의 동작들을 결정하기 위해 정책 정보가 (제어기(106)에 커플링된) 정책 데이터베이스(108)에 제공될 수 있거나 또는 그 정책 정보로 정책 데이터베이스(108)가 미리구성될 수 있다. 프로비저닝(provisioning) 시간에 정보가 정책 데이터베이스(108)에 제공될 수 있다.

[0073] 도 1에서의 애플리케이션(101)과 관련될 수 있거나 또는 관련되지 않을 수 있는 애플리케이션(101)은 프로비저닝 애플리케이션일 수 있다. 애플리케이션(101)은, 전송 미들웨어(110)에 대한 상태를 결정할 뿐만 아니라 전송 미들웨어(110)를 활성화시키도록(321) 구성될 수 있다. 애플리케이션(101)은 전송 미들웨어(110)의 하나 또는 그 초과의 전송 메커니즘들을 활성화시키도록 구성될 수 있다. 애플리케이션(101)은, 시작시 초기에 프록시 엔드포인트(예를 들어, 호스트 이름 또는 어드레스, 프로토콜, 또는 프로토콜 포트 번호)를 식별하는 정보로 애플리케이션 서비스 클라이언트(102)를 구성할 수 있다(322).

[0074] 이러한 예에서, 하나 초과의 전송이 이용가능할 수 있고, 다양한 콘텐츠가 상이한 시간들에서 다양한 전송들을 통해 이용가능할 수 있다. 특히, 다양한 서비스들이 이용가능할 수 있고, 여기에서, 다양한 서비스들은, 미디어 데이터를 전송하기 위한, 브로드캐스트, 멀티캐스트, 유니캐스트 등과 같은 상이한 각각의 타입들의 전송들을 각각 정의할 수 있다. 예를 들어, 전송들의 DVB-패밀리 중 하나 또는 그 초과 및/또는 eMBMS가 이용가능할 수 있다. 추가로, 이용가능한 미디어 콘텐츠(예를 들어, 파일들)는, 예를 들어 애플리케이션 서비스 디스크립션을 사용하여 표현될 수 있다. 애플리케이션 서비스 디스크립션의 일 예는, 다양한 이용가능한 미디어 컴포넌트들을 기술하는 것에 있어서, MBMS 사용자 서비스로서 전달되는 DASH 콘텐츠의 경우에서의 MPD 프래그먼트와 같은 MBMS 사용자 서비스 디스크립션(USD) 메타데이터 프래그먼트이다. 애플리케이션 서비스 디스크립션의 다른 예는, MBMS 사용자 서비스로서 전달되는 HLS 콘텐츠의 경우에서의, Apple HLS (HTTP Live Streaming) 매니페스트 파일이다. 각각의 전송 메커니즘은, 요약(summarizing) URI 또는 공통(common) URI 프리픽스를 생성할 수 있고 파일 정보의 세부사항들 및 리스트를 획득할 수 있는 대응하는 모듈을 가질 수 있다. 이들 모듈들은, 정책 및 레졸루션을 적용할 수 있고 결국 정책에 영향을 받는 리디렉터/프록시(104)를 프로그래밍하는 제어기(106)로 통신 메커니즘(예를 들어, IPC, API, 또는 다른 프로토콜)을 통해 이러한 정보를 전달할 수 있다.

[0075] 콘텐츠 서버(310)는, 전송 미들웨어(110)에 의해 수신될 수 있는 서비스 리스팅(예를 들어, USD, ESG)을 (예를 들어, LTE RAN, DVB-T 등을 사용하여) 브로드캐스팅할 수 있다. 적절한 모듈(예를 들어, 전송 A(110A) 내지 전송 R(110R) 중 하나)은 서비스 리스팅을 분석하고, 정보를 전송 특정이 아닌 형태로 프로세싱한다. 전송 미들웨어(110)는 결과들(예를 들어, 파일 이용가능성 리스트라고 또한 지칭되는, 이용가능한 파일들의 리스트를 정의하는 데이터 및 서비스의 식별자)을 제어기(106)로 전달할 수 있다(324). 제어기(106)는, 맵핑들의 세트를 생성하기 위해 액세스 정책과 함께 파일 이용가능성 리스트를 프로세싱할 수 있다(325). 맵핑들은, 어떤 URI들(또는 URI 프리픽스들)이 어떤 서버로 리디렉팅되어야 하는지를 포함할 수 있다(예를 들어, MBMS를 통해 이용가능한 파일들은 MBMS 미들웨어와 연관된 또는 MBMS 미들웨어 내에서 예시되는(instantiated) 서버로부터 이용가능할 수 있다).

[0076] 애플리케이션 서비스 클라이언트(102)가 호출되면, 애플리케이션 서비스 클라이언트(102)는, 예를 들어 MPD 콘텐츠를 획득하기 위해 구성된 프록시 어드레스를 통해 요청(예를 들어, HTTP 요청)을 이슈(issue)할 수 있다(326). 요청은 리디렉터/프록시(104)로 통신될 수 있다. 리디렉터/프록시(104)는 매칭 기준들, 또는 매치가 발생하지 않은 경우에, 다른 표시자(예를 들어, 디폴트 리디렉션 타겟, 에러 표시, 또는 오리지널 요청의 카피)를 결정하기 위해 매칭 알고리즘을 수행할 수 있다. 그 후에, 리디렉터/프록시(104)는, 예를 들어 HTTP를 사용하여, 애플리케이션 서비스 클라이언트(102)에 리디렉션 타겟 또는 에러를 제공할 수 있다(327A). (예를 들어, 3xx 타입 코드와 같은) 리디렉션을 표시하는 코드(예를 들어, HTTP 코드)를 관찰하였던 애플리케이션 서비스 클라이언트(102)는 코드 타입에 따라 응답한다. 예를 들어, 300 이외의 코드 타입들은, 리소스에 대한 대안적 로케이션(alternate location)을 표시할 수 있는 HTTP "로케이션:" 헤더를 포함한다. 그러한 표시를 수신할 시에, 애플리케이션 서비스 클라이언트(102)는, 표시된 대체 로케이션을 사용하여, 그것의 요청을 재시도할 수 있다. 이러한 예에서, 리디렉터/프록시(104)는, 특정한 URI가 MBMS 미들웨어 내에 통합된 서버로 디렉팅되어야 한다는 것을 표시한다. 따라서, 애플리케이션 서비스 클라이언트(102)는, 그러한 리디렉션 코드에 응답하여, 예를 들어 MPD를 획득하기 위해 전송 미들웨어(110)에 요청을 제출할 수 있다(327B).

[0077] 애플리케이션 서비스 클라이언트(102)가 MPD 정보를 획득하면, 애플리케이션 서비스 클라이언트(102)는, 어떤 미디어 세그먼트들에 액세스할지를 (예를 들어, MPEG-DASH의 경우에서는 어떤 "표현") 결정할 수 있고, 리디렉터/프록시(104)에 HTTP-기반 요청을 이슈할 수 있다(328). 위에서 설명된 메커니즘(예를 들어, 서비스 ID에 의해 식별되는 서비스와 연관된 전송의 타입)을 사용하여, 리디렉터/프록시(104)는 애플리케이션 서비스 클라이언트(102)에 리디렉트 타겟을 제공할 수 있다(329). 타겟은, 디폴트 값, (애플리케이션 서비스 클라이언트(102)가 요청을 핸들링해야 한다는 것을 표시하는) 요청의 카피, 또는 상이한 서버에 대한 레퍼런스일 수 있다. 그 후에, 타겟들은, 미디어 세그먼트들을 획득하기 위해 애플리케이션 서비스 클라이언트(102)에 의해 사용되는 로케이션들로서의 역할을 한다. 즉, 서비스를 사용하여 콘텐츠가 이용가능하다고 가정하면, 애플리케이션 서비스 클라이언트(102)는 전송 미들웨어(110)에 콘텐츠 요청을 제출할 수 있고(330A), 응답하여, 전송 미들웨어(110)는 애플리케이션 서비스 클라이언트(102)에 콘텐츠를 전달할 수 있다(331A). (예를 들어, 서비스가 이용가능하지 않은 경우에) 다른 소스들을 통해 이용가능한 콘텐츠에 대해, 애플리케이션 서비스 클라이언트(102)는 (예를 들어, 다른 서버들, 저장/캐시, 또는 인터넷으로부터의) 다른 방법들을 통해 콘텐츠를 획득할 수 있다. 예를 들어, 애플리케이션 서비스 클라이언트(102)는 콘텐츠 서버(310)에 콘텐츠 요청을 전송할 수 있고(330B), 응답하여, 콘텐츠 서버(310)는 애플리케이션 서비스 클라이언트(102)에 요청된 콘텐츠를 전달할 수 있다(331B).

[0078] 몇몇 경우들에서, 단계(326) 또는 단계(328)에서 애플리케이션 서비스 클라이언트(102)로부터 요청된 URI들은 리디렉터/프록시(104)에게는 알려져 있지 않을 수 있다. 그러한 경우들에서, 애플리케이션 서비스 클라이언트(102)에게, 그것이 상이한 세그먼트를 요청하는 것을 시도할 수 있거나 또는 리디렉터/프록시(104)를 사용하는 것을 중단 (예를 들어, 대신에 직접적인 인터넷 액세스 요청을 사용) 할 수 있는 것을 표시하기 위한 에러들(예를 들어, HTTP 코드 404)이 생성될 수 있다. 대안적으로, 리디렉터(104)는, 비-프록시 동작을 제안하기 위한 인입 요청과 동등한 로케이션 헤더를 사용할 수 있다. 다른 양상은, 프록시 또는 웹 프록시로서 동작하는 리디렉터/프록시(104)를 수반할 수 있고, 이러한 경우에, 그것은, 예를 들어 아래에서 도 4의 예시적인 프로세스 흐름(400)에서 예시되는 바와 같이, 애플리케이션 서비스 클라이언트(102) 대신에, 인터넷 또는 다른 네트워크 또는 캐시에 액세스할 수 있다.

[0079] 300-타입 HTTP 에러 코드들에 대해, "로케이션:" 헤더에 존재하지 않을 수 있는 선택 벡터(a vector of choices)가 애플리케이션 서비스 클라이언트(102)에 제공될 수 있다. 이러한 경우에서, 애플리케이션 서비스 클라이언트(102)는, 제공된 다수의 선택들 중에서 선택할 수 있고, 미디어 인코딩 포맷의 사항들에 따라, 그것의 디코딩 상태를 재-초기화할 수 있다. 시나리오는, 지금까지 애플리케이션 서비스 클라이언트(102)가 프로세싱하였던 것 이외의 방식으로 인코딩된 표현에 대해, 예를 들어 플레이백 시나리오의 중간에서 리디렉션이 발생한 경우에, 유발될 수 있다.

[0080] 애플리케이션 서비스 클라이언트(102)가 그것의 다음 미디어 요청(들)/액세스(들)를 선택하기 위해 어느 프로세스를 사용하든, 애플리케이션 서비스 클라이언트(102)는 리디렉팅된 정보에 기초하여 요청(들)/액세스(들)를 개시할 수 있다. 후속 요청들/액세스가 초기에 리디렉터에 전달될 수 있어서, 리디렉터가 개입하고 세그먼트들(예를 들어, 파일들로서 저장된 미디어 세그먼트들 및/또는 메타-데이터)이 리트리브되는 로케이션(및 다른 특성들)를 효과적으로 변경할 가능성이 제공된다.

[0081] 도 4는, 프록시 동작을 위해 구성된 리디렉터/프록시를 사용하는 예시적인 프로세스 흐름(400)의 양상들을 예시하는 흐름도이다. 프로세스 흐름(400)의 개시 전에, 제어기(106)의 동작들을 결정하기 위해 정책 정보가 (제어기(106)에 커플링된) 정책 데이터베이스(108)에 제공될 수 있거나, 또는 그 정책 정보로 그 정책 데이터베이스(108)가 미리구성될 수 있다. 프로비저닝 시간에서 정보가 정책 데이터베이스(108)에 제공될 수 있다.

[0082] 애플리케이션(101)은 프로비저닝 애플리케이션일 수 있다. 도 1의 애플리케이션(101)에 대해 설명되지만, 애플리케이션이 도 1에 대해 설명된 것과 동일할 필요는 없다는 것이 이해되어야 한다. 애플리케이션(101)은 전송 미들웨어(110)를 활성화하도록 구성될 수 있다(401). 애플리케이션(101)은 전송 미들웨어(110)의 하나 또는 그 초과의 전송 메커니즘들을 활성화하도록 구성될 수 있다. 애플리케이션 서비스 클라이언트(102)는 초기에 애플리케이션(101)에 의한 시작시에 프록시 엔드포인트를 식별하는 정보(예를 들면, 호스트 명칭 또는 어드레스, 프로토콜 또는 프로토콜 포트 번호)로 구성될 수 있다(402).

[0083] 이러한 예에서, 하나보다 더 많은 전송 메커니즘이 이용가능할 수 있고, 다양한 매체들이 상이한 시간들에서 다양한 전송들에 걸쳐 이용가능할 수 있다. 다양한 타입들의 전송들은 각각의 서비스들에 의해 정의될 수 있다. 예를 들면, eMBMS 그리고/또는 DVB 패밀리의 전송들 중 하나 또는 그 초과의 것이 이용가능할 수 있다. 추가로, 이용가능한 미디어 파일들은, 예를 들면, eMBMS USD의 MPD 프래그먼트를 사용하여 그리고 DVB 전송에 대한 DVB 전자 서비스 가이드(ESG)를 통해 표현될 수 있다. 전송 미들웨어(110)에 의해 표현된 각각의 전송 메커니즘은, 이용가능한 서비스들의 리스트 및 파일 정보의 세부사항들을 획득하고 요약 URI 또는 공통 URI 프리픽스를 생성할 수 있는 대응하는 모듈을 가질 수 있다. 이들 모듈들은 이러한 정보를 통신 메커니즘(예를 들면, IPC, API 또는 다른 프로토콜)을 통해 제어기(106)로 전달할 수 있고, 제어기(106)는 정책 및 레졸루션을 적용할 수 있고, 결국 정책에 영향을 받는 리디렉터/프록시(104)를 프로그램한다.

[0084] 콘텐츠 서버(310)는 서비스 리스팅(예를 들면, USD, ESG)을 브로드캐스팅할 수 있고, 서비스 리스팅은 전송 미들웨어(110)에 의해 수신된다(403). 적절한 모듈(예를 들면, 전송 A(110A) 내지 전송 R(110R) 중 하나)은 서비스 리스팅을 분석하고, 정보를 특정 전송이 아닌 형태로 프로세싱한다. 전송 미들웨어(110)는 결과들을 제어기(106)에 전달한다(404). 제어기(106)는 한 세트의 맵핑들을 생성하기 위해 액세스 정책과 공조하여 파일 이용가능성 리스트를 프로세싱할 수 있다(405). 맵핑들은, 어떠한 URI들(또는 URI 프리픽스들)이 예시된 어떠한 서버로 리디렉팅되어야 하는지를 포함할 수 있다(예를 들면, MBMS를 통해 이용가능한 파일들 또는 미디어는 MBMS 미들웨어 내에서 예시되거나 이와 연관된 서버로부터 이용가능할 수 있음).

[0085] 일단 애플리케이션 서비스 클라이언트(102)가 호출되면, 애플리케이션 서비스 클라이언트(102)는, 예를 들면, MPD 콘텐츠를 획득하기 위한 요청(예를 들면, HTTP 요청)을 구성된 프록시 어드레스를 통해 이슈할 수 있다(406). 요청은 리디렉터/프록시(104)로 통신될 수 있다. 리디렉터/프록시(104)는 매칭 기준들 또는, 매치가 발생하지 않는 경우, 다른 표시자(예를 들면, 디폴트 리디렉션 타겟, 에러 표시 또는 오리지널 요청의 사본)를 결정하기 위해 매칭 알고리즘을 수행할 수 있다. 에러의 경우에, 에러는 애플리케이션 서비스 클라이언트(102)에 제공될 수 있다. 매치가 발생하면, 리디렉터/프록시(104)는 프록시로서의 역할을 할 수 있고, 애플리케이션 서비스 클라이언트(102)를 대신하여 콘텐츠를 리트리브할 수 있다. 이후, 타겟들은 미디어 세그먼트들을 획득하기 위해 프록시로서 동작하는 리디렉터/프록시(104)에 의해 사용되는 로케이션들로서의 역할을 한다. 즉, 리디렉터/프록시(104)는 콘텐츠 요청을 전송 미들웨어(110)에 제출할 수 있고(407A), 전송 미들웨어는 콘텐츠를 리디렉터/프록시(104)에 전달할 수 있다(408A). 다른 소스들을 통해 이용가능한 콘텐츠에 대해, 프록시로서 동작하는 리디렉터/프록시(104)는 다른 서버들을 통해, 저장소/파일들 또는 인터넷으로부터 콘텐츠를 획득할 수 있다. 즉, 리디렉터/프록시(104)는 콘텐츠 요청을 콘텐츠 서버(310)에 제출할 수 있고(407B), 콘텐츠 서버(310)는 요청된 콘텐츠를 리디렉터/프록시에 전달할 수 있다(408B).

[0086] 도 5는 무선 통신 네트워크(WCN)의 멀티미디어 클라이언트에 대한 멀티미디어 콘텐츠와 연관된 전송 다이버시티를 지원하기 위한 예시적인 방법을 예시한 흐름도이다. 멀티미디어 클라이언트는 모바일 엔티티를 포함할 수 있거나 모바일 엔티티일 수 있다. 방법(500)은, (502)에서, 콘텐츠에 대한 요청을 수신하는 것을 포함할 수 있다. 방법(500)은, (504)에서, 한 세트의 룰들에 기초하여 요청에 대한 매치가 존재하는지 여부를 결정하는 것을 포함할 수 있다. 방법(500)은, (506)에서, 매치가 존재한다고 결정한 것에 응답하여, 리디렉션을 멀티미디어 클라이언트로 전송하는 것을 포함할 수 있다.

[0087] 도 6은 무선 통신 네트워크(WCN)의 멀티미디어 클라이언트에 대한 멀티미디어 콘텐츠와 연관된 전송 다이버시티를 지원하기 위한 UE, 네트워크 엔티티 또는 다른 적절한 엔티티로서 또는 UE 내에서 사용하기 위한 프로세서 컴포넌트 또는 유사한 디바이스, 네트워크 엔티티 또는 다른 적절한 엔티티로서 구성될 수 있는 예시적인 장치(600)를 예시한 블록도이다. 장치(600)는 프로세서, 소프트웨어 또는 이들의 조합(예를 들면, 펌웨어)에 의해 구현되는 기능들을 나타낼 수 있는 기능적 블록들을 포함할 수 있다.

[0088] 예시된 바와 같이, 일 예에서, 장치(600)는 콘텐츠에 대한 요청을 수신하기 위한 전기 컴포넌트 또는 모듈(602)을 포함할 수 있다. 장치(600)는 한 세트의 룰들에 기초하여 요청에 대한 매치가 존재하는지 여부를 결정하기 위한 전기 컴포넌트 또는 모듈(604)을 포함할 수 있다. 장치(600)는, 매치가 존재한다고 결정한 것에 응답하여, 리디렉션을 멀티미디어 클라이언트로 전송하기 위한 전기 컴포넌트 또는 모듈(606)을 포함할 수 있다.

[0089] 관련 양상들에서, 장치(600)는, 네트워크 엔티티로서 구성된 장치(600)의 경우에, 적어도 하나의 프로세서를 갖는 프로세서 컴포넌트(610)를 선택적으로 포함할 수 있다. 프로세서(610)는, 이러한 경우에, 버스(612) 또는 유사한 통신 커플링을 통해 컴포넌트들(602-606) 또는 유사한 컴포넌트들과 동작 가능하게 통신할 수 있다. 프로세서(610)는 전기 컴포넌트들 또는 모듈들(602-606)에 의해 수행되는 프로세스들 또는 기능들의 개시 및 스케줄링을 실시할 수 있다.

[0090] 추가의 관련 양상들에서, 장치(600)는 다른 네트워크 엔티티들과 통신하기 위한 네트워크 인터페이스 컴포넌트(614)를 포함할 수 있다. 장치(600)는, 예를 들면, 메모리 디바이스/컴포넌트(616)와 같이 정보를 저장하기 위한 컴포넌트를 선택적으로 포함할 수 있다. 컴퓨터 판독 가능 매체 또는 메모리 컴포넌트(616)는 버스(612) 등을 통해 장치(600)의 다른 컴포넌트들에 동작 가능하게 커플링될 수 있다. 메모리 컴포넌트(616)는 컴포넌트들(602-606) 및 이들의 서브컴포넌트들 또는 프로세서(610)의 동작을 수행하기 위한 컴퓨터 판독 가능 명령들 및 데이터를 저장하도록 구성될 수 있다. 메모리 컴포넌트(616)는 컴포넌트들(602-606)과 연관된 기능들을 실행하기 위한 명령들을 보유할 수 있다. 메모리(616) 외부에 있는 것으로 도시되지만, 컴포넌트들(602-606)이 메모리(616) 내에 존재할 수 있다는 것이 이해된다.

[0091] 도 7 및 도 8은 전송 다이버시티를 지원하기 위한 추가의 양상들을 예시한 블록도들이다. 도 7 및/또는 도 8의 컴포넌트들은 실질적으로 앞서 설명된 도 1의 컴포넌트들에 대응할 수 있다. 도 7은, 예를 들면, 네트워크(700), 애플리케이션 서비스 클라이언트(702), 미디어 애플리케이션(704), HTTP 리디렉터/프록시(706), 제어기(708), 미들웨어(712) 및 정책 관리기(716)를 예시한다. 미디어 애플리케이션(704)은 일반적으로 (예를 들면, 사용자의 선택에 응답하여) 미디어 콘텐츠를 선택하는 것을 담당하고, 애플리케이션 서비스 클라이언트(702)는 선택된 미디어 콘텐츠를 리트리브하고, 플레이백을 위해 리트리브된 미디어 콘텐츠를 미디어 애플리케이션(704)에 제공하도록 구성된다. 애플리케이션 서비스 클라이언트(702)는, 예를 들면, 미디어 데이터를 스트리밍하기 위해 HTTP를 사용하도록 구성된 DASH 클라이언트를 포함할 수 있다.

[0092] 도 1에 대해 앞서 논의된 바와 같이, 애플리케이션 서비스 클라이언트(702)는 네트워크(700) 또는 미들웨어(712)로부터 직접적으로 미디어 데이터를 리트리브할 수 있다. 예를 들면, 브로드캐스트 또는 멀티캐스트를 지원하는 서비스가 이용가능할 때(예를 들면, 제어기(708)에 의해 결정되고, 정책 관리기(716)에 의해 저장된 정책들에 의해 정의됨), 미들웨어(712)는 미디어 데이터를 수신하고, 수신된 미디어 데이터를 캐시(714) 내에 저장할 수 있다. 애플리케이션 서비스 클라이언트(702)는 미디어 데이터에 대한 요청들을 HTTP 리디렉터/프록시(706)에 이슈할 수 있다. 요청된 미디어 데이터가 미들웨어(712)에 의해 수신될 때, HTTP 리디렉터/프록시(706)는 미디어 데이터에 대한 요청을 미들웨어(712)로 리디렉팅할 수 있다. 따라서, 애플리케이션 서비스 클라이언트(702)는 HTTP 요청을 미들웨어(712)에 이슈할 수 있고, 미들웨어(712)는 미디어 데이터를 애플리케이션 서비스 클라이언트(702)에 제공할 수 있다. 반면에, 미들웨어(712)가 미디어 데이터를 수신하지 않을 때, HTTP 리디렉터/프록시(706)는 애플리케이션 서비스 클라이언트(702)를 미디어 데이터가 이용가능한 서버의 네트워크 로케이션으로 리디렉팅할 수 있고, 여기서 서버는 네트워크(700)를 통해 이용가능할 수 있다.

[0093] 도 8은 다른 예로서, DASH 클라이언트(802), 플래이백 애플리케이션(804), HTTP 리디렉터/프록시(818), 제어기(814), MSDC(808), MBMS 송신 유닛(820), 및 정책 데이터베이스(816)를 예시한다. 이들 컴포넌트들은 도 1 및/또는 도 7의 유사한 명칭의 컴포넌트들과 실질적으로 대응할 수 있다. 일반적으로, 도 8의 기술들은 DASH를 활용(결국, HTTP를 활용)하는 것으로서 논의되지만, 다른 스트리밍 프로토콜들이 또한 이용될 수 있다는 것이 이해되어야 한다. 대안적인 예들은 예를 들어, RTP/RTSP에 관하여 아래에서 논의된다.

[0094] 초기에, 정책 정보는 DASH 클라이언트(802), 플래이백 애플리케이션(804), HTTP 리디렉터/프록시(818), 제어기(814) 및 MSDC(808)을 포함하는 시스템에 제공될 수 있다. 이러한 정책 정보는 정책 데이터베이스(816) 내에 저장될 수 있다(830). 이 정책 정보는 제어기(814)의 동작에 영향을 줄 수 있다. 제어기(814)는 하드웨어, 소프트웨어, 펌웨어, 또는 이들의 임의의 결합으로 구현될 수 있다. 소프트웨어 및/또는 펌웨어로 구현될 때, 제어기(814)에 대응하는 소프트웨어의 명령들을 실행하기 위한 하나 또는 그 초과의 하드웨어-기반 프로세싱 유닛들과 같은 필수 하드웨어가 또한 제공될 수 있다는 것이 가정된다.

[0095] 초기에, 플래이백 애플리케이션(804)은 프록시 엔드포인트를 식별하는 정보와 같은 식별 정보(예를 들어, 호스트 명칭 또는 어드레스, 프로토콜 및 프로토콜 포트 번호)를 프로비저닝할 수 있다(832). 이 정보는 선택적인 프로비저닝 애플리케이션에 의해 제공될 수 있다. DASH 클라이언트(802)는 식별 정보로 구성될 수 있다(834).

[0096] 도 8의 예에서, 한 개 초과의 전송이 이용가능할 수 있고 다양한 미디어(예를 들어, 파일들에서)가 상이한 시간들에 다양한 전송들에 걸쳐서 이용가능할 수 있다. 예를 들어, eMBMS 및 DVB 전송들이 이용가능하다는 것을 고려한다. 이용가능한 미디어 파일들은 애플리케이션 서비스 디스크립션을 이용하여 표현된다는 것을 또한 고려한다. 각각의 전송은 도 1의 전송 모듈들(110A-110R)에 의해 도시된 바와 같이, 리스트 및 미디어 정보의 세부사항들을 획득하고 요약 URI 또는 공통 URI 프리픽스를 생성할 수 있는 대응하는 모듈을 가질 수 있다. MSDC(808) 만이 도 8의 예에서 도시되지만, MSDC(808)은 다수의 각각의 전송 모듈들을 포함할 수 있다는 것이 이해되어야 한다. 이들 모듈들은 통신 매커니즘(예를 들어, IPC, API 또는 프로토콜)을 통해, 제어기(814)에 파일 정보를 전달할 수 있고, 제어기(814)는 정책 및 레졸루션을 적용할 수 있고, 결국 정책에 영향을 받는 리디렉터를 프로그램한다. 도 8은 (클러터를 제한하도록) MBMS에 대한 일부들만을 도시한다. MBMS rX(820)는 USD(836)를 수신하고 USD를 분석하여 MSDC(808)에 전달할 수 있다(838).

[0097] MSDC(808)는 USD-특정 정보를 전송-특정이 아닌 형태로 프로세싱하고 결과를 제어기(814)에 전달한다(840). 제어기(814)는 이후, 맵핑들의 세트를 생성하기 위해 액세스 정책과 함께 파일 이용가능성 리스트를 프로세싱할 수 있다(842). 맵핑들은, 어느 URI들(또는 URI 프리픽스들)이 예시된 어느 서버로 리디렉팅되어야 하는지를 나타낸다(예를 들어, MBMS 상에서 이용가능한 파일들은 MSDC(808)와 연관되거나 그 내에서 예시된 서버(812)로부터 이용가능할 수 있음). 즉, HTTP 리디렉터/프록시(818)는 미디어 데이터를 리트리브하기 위한 서비스에 기초하여 리소스 로케이션에 미디어 데이터에 대한 식별자를 맵핑하는 맵핑 정보를 획득할 수 있으며, 여기서 서비스는 미디어 데이터를 전송하기 위한 복수의 전송 타입들(예를 들어, 브로드캐스트, 유니캐스트, 또는 멀티캐스트) 중 적어도 하나를 정의한다. 예를 들어, 서비스는 미디어 데이터를 전송하기 위한 브로드캐스트 또는 멀티캐스트 전송 타입들을 정의할 수 있으며, 어느 경우에도, MSDC(808)은 데이터를 수신할 수 있다. MSDC(808)는 예를 들어, 아래에서 논의되는 바와 같이 DASH 클라이언트(802)에 의한 후속 리트리벌을 위해 캐시(810)에 수신 미디어 데이터를 저장할 수 있다.

[0098] 일단 호출되면, DASH 클라이언트(802)는 MPD 콘텐츠들을 획득하기 위해 구성된 프록시 어드레스를 통해 HTTP 요청을 (HTTP 리디렉터/프록시(818)로) 이슈할 수 있다(844). 마찬가지로, HTTP 리디렉터/프록시(818)는 DASH 클라이언트(802)로부터 HTTP 요청을 수신할 수 있다. HTTP 요청은 미디어 데이터에 대한 요청일 수 있다. HTTP 리디렉터/프록시(818)는, 매칭 기준들 또는, 매치가 발생하지 않는 경우, 다른 표시자(예를 들어, 디폴트 리디렉션 타겟, 에러 표시, 또는 오리지널 요청의 카피)를 결정하도록 매칭 알고리즘을 수행할 수 있다. 따라서, 맵핑 정보에 관한 매칭 기준들을 이용하여, HTTP 리디렉터/프록시(818)는 특정한 서비스, 예를 들어, 요청된 미디어 데이터를 전송하기 위해 브로드캐스트 또는 멀티캐스트를 정의하는 서비스가 이용가능한지를 결정할 수 있다. 이후, HTTP 리디렉터/프록시(818)는, 매칭 알고리즘에 기초하여, HTTP를 이용하여 리디렉트 타겟 또는 에러를 DASH-클라이언트(820)에 제공할 수 있다(846).

[0099] 리디렉션을 나타내는 HTTP 코드(예를 들어, 3xx 타입 HTTP 코드)를 관찰한 DASH 클라이언트(802)는 코드 타입에 의존하여 응답할 수 있다. 300 이외의 다른 타입들에 대해, HTTP "로케이션:" 헤더는 리소스에 대한 대안적 로케이션을 나타낼 수 있다. 이러한 표시의 수신 시에, DASH 클라이언트(802)는 표시된 대안적 로케이션을 이용하여 그의 요청을 재시도할 수 있다. 이 예에서, HTTP 리디렉터/프록시(818)는, DASH 클라이언트(802)가 MDP를 획득할 수 있는 MSDC(808) 내에 통합된 서버로 특정 URI가 디렉팅되어야 함을 나타낼 수 있다(848).

[0100] DASH 클라이언트(802)가 MPD 정보를 획득하면, DASH 클라이언트(802)는 어느 미디어 파일들(예를 들어, MPEG-DASH의 경우, 어느 "표현(representation)")에 액세스할지를 결정하고 결정된 미디어 파일들을 리트리브하기 위해 하나 또는 그 초과의 HTTP-기반 요청들을 이슈할 수 있다(852). 위에서 설명된 매커니즘을 이용하여, HTTP 리디렉터/프록시(818)는 DASH 클라이언트(802)에 리디렉트 타겟을 제공한다(854). 타겟은 디폴트 값, 요청의 카피(클라이언트가 요청을 핸들링할 수 있다고 표시함), 또는 상이한 서버들에 대한 레퍼런스일 수 있다. 타겟은 그 후 예를 들어, MSDC(808)로부터 미디어 세그먼트들을 획득하기 위해 DASH 클라이언트(802)에 의해 이용되는 로케이션들로서의 역할을 한다(856). 이런 식으로, 예를 들어, 미디어를 전송하기 위한 브로드캐스트 또는 멀티캐스트를 정의하는 서비스가 이용가능할 때, HTTP 리디렉터/프록시(818)는, DASH 클라이언트(802)로 하여금, 맵핑 정보에 표시된 리소스 로케이션으로부터의 서비스를 이용하여 미디어 데이터를 수신하는 유닛(예를 들어, MSDC(808))으로부터 요청된 미디어 데이터를 수신하게 할 수 있다. 대안적으로, 리디렉션 타겟은 인터넷(806)을 포함하는 몇몇 네트워크를 통해 이용가능한 네트워크 로케이션에 대응할 수 있다.

[0101] 몇몇 경우들에서, 클라이언트로부터 요청된 URI들(단계 844/852)은 HTTP 리디렉터/프록시(818)에 알려지지 않을 수 있다. 이러한 경우에, 에러들(예를 들어, HTTP 코드(404))은, DASH 클라이언트(802)가 상이한 세그먼트를 요청하거나, HTTP 리디렉터/프록시(818)를 이용하지 않도록(즉, 직접 네트워크 또는 인터넷 액세스 요청을 대신 이용하도록) 변경하기 시도해야 한다는 것을 DASH 클라이언트(802)에 나타내도록 생성될 수 있다. 대안적으로, HTTP 리디렉터/프록시(818)는 비-프록시 동작을 제안하기 위해 인입 요청과 등가의 로케이션: 헤더를 이용할 수 있다. 추가의 변형은 종래의 웹 프록시로서 동작하는 HTTP 리디렉터/프록시(818)를 수반할 것이며, 이 경우에, HTTP 리디렉터/프록시(818)는 DASH 클라이언트(802) 대신 인터넷(806)에 액세스할 수 있다.

[0102] 이런 식으로, 도 8의 기술들은, 프록시 유닛(예를 들어, HTTP 리디렉터/프록시(818))에 의해 미디어 데이터를 리트리브하기 위한 서비스에 기초하여 리소스 로케이션에 대해 미디어 데이터에 대한 식별자를 맵핑하는 맵핑 정보를 획득하는 것 ―상기 서비스는 미디어 데이터를 전송하기 위한 복수의 전송 타입들(예를 들어, 브로드캐스트, 멀티캐스트, 또는 유니캐스트) 중 적어도 하나를 정의함―, 애플리케이션 서비스 클라이언트(예를 들어, DASH 클라이언트(802))로부터 미디어 데이터에 대한 요청을 수신하는 것, 서비스가 이용가능한지를 결정하는 것, 그리고 서비스가 이용가능할 때, 애플리케이션 서비스 클라이언트로 하여금, 맵핑 정보에 기초하여 리소스 로케이션로부터의 서비스를 이용하여 미디어 데이터를 수신하는 유닛으로부터 미디어 데이터를 수신하게 하는 것을 포함하는 방법의 예를 나타낸다. 이 예에서 미디어 데이터를 수신하는 유닛은 MSDC(808)에 대응한다.

[0103] 또한, 리소스 로케이션이 네트워크 로케이션(예를 들어, 인터넷(806) 내부의 로케이션 또는 인터넷(806)을 통해 액세스 가능한 로케이션)에 대응하는 경우, HTTP 리디렉터/프록시(818)는 요청에 특정된 미디어 데이터가 맵핑 정보 내 미디어 데이터와 매치하는지를 결정하고, 그리고 요청에 특정된 미디어 데이터가 맵핑 정보 내 미디어 데이터와 매치하는 경우, 애플리케이션 서비스 클라이언트로 하여금 네트워크 로케이션으로부터의 미디어 데이터를 리트리브하게 하기 위해, 미디어 데이터에 대한 식별자가 맵핑 정보에 맵핑되는 네트워크 로케이션을 특정하는 애플리케이션 서비스 클라이언트에 리디렉트 메시지를 전송하도록 구성될 수 있다.

[0104] 마찬가지로, HTTP 리디렉터/프록시(818)는 미디어 데이터를 리트리브하기 위한 서비스에 기초하여 미디어 데이터에 대한 식별자를 리소스 로케이션에 맵핑하는 맵핑 정보를 획득하고 ―상기 서비스는 미디어 데이터를 전송하기 위한 복수의 전송 타입들(예를 들어, 브로드캐스트, 멀티캐스트, 또는 유니캐스트) 중 적어도 하나를 정의함―, 애플리케이션 서비스 클라이언트로부터 미디어 데이터에 대한 요청을 수신하고, 서비스가 이용가능한지를 결정하고, 그리고 서비스가 이용가능한 경우, 애플리케이션 서비스 클라이언트로 하여금 맵핑 정보에 기초하여 리소스 로케이션으로부터의 서비스를 이용하여 미디어 데이터를 수신하는 유닛으로부터 미디어 데이터를 수신하게 하도록 구성된 프록시 유닛의 예를 나타낸다.

[0105] 도 9 및 도 10은 RTP/RTSP 스트리밍을 지원하기 위한 예시적인 MSDC 아키텍처들을 예시하는 블록도들이다. 도 9는 TSB 특징이 없는 아키텍처를 도시하고 도 10은 TSB를 지원하는 아키텍처를 도시한다. 이러한 실시예에서, TSB는 미들웨어에서 유지될 것이다. 번호가 부여된 화살표들은 네트워크 계층으로부터 미들웨어로, 궁극적으로는 RTSP/RTP 클라이언트로의 데이터 흐름을 나타낸다. 특히, LTE 모뎀에 의해 수신된 데이터는 멀티캐스트(또는 브로드캐스트)를 지원하는 IP 스택에 제공된다. IP 스택은 수신된 데이터를, 데이터에 관하여 MSDC 미들웨어의 순방향 에러 정정(FEC) 프로세싱을 수행하는 MSDC 미들웨어의 실시간 전송 프로토콜(RTP) 기능에 제공한다(901). 이후, 데이터는 IP 스택으로 다시 제공될 수 있다(902). 이후, IP 스택은 데이터를 RTP 클라이언트로 제공한다(903).

[0106] 도 10의 예에서, MSDC(1010)는 TSB(1012)를 지원할 수 있다. 이와 같이, 도 10의 예에서, LTE 모뎀에 의해 수신된 데이터는 멀티캐스트(또는 브로드캐스트)를 지원하는 IP 스택에 제공된다. IP 스택은 수신된 데이터를, 데이터에 대한 순방향 에러 정정(FEC) 프로세싱을 수행하는 MSDC(1010)의 실시간 전송 프로토콜(RTP) 기능에 제공한다(1001). 이후, 데이터는 시간-시프트 버퍼(TSB)(1012)에서 버퍼링될 수 있다(1002). 이후, IP 스택은 적절한 시기에 TSB(1012)로부터 데이터를 수신할 수 있고(1003) 데이터를 RTP 클라이언트에 제공한다(1004).

[0107] 이외에도, 아래에 더욱 상세하게 설명되는 바와 같이, MSDC(1010)는 도 10의 TSB(1012)에 대한 시간-시프트 버퍼(TSB) 깊이를 정의하는 속성을 포함하는 SDP 메시지를 수신할 수 있다. MSDC(1010)는 SDP 메시지에서 시그널링되는 속성의 값에 기초하여 TSB(1012)에 대한 메모리의 양을 결정할 수 있다. 예를 들어, 속성의 값은, 예를 들어, TSB(1012)에 저장될 미디어 데이터에 대한 플레이백의 초(seconds)와 관련하여 TSB의 길이를 정의할 수 있다. 이와 같이, MSDC(1010)는, 예를 들어, 수신될 미디어 데이터의 비디오 데이터에 대한 프레임 레이트에 기초하여 그리고 TSB(1012)에서 잠재적으로 버피링될 몇 초의 플레이백 횟수에 기초하여 TSB(1012)를 형성하기 위해, 할당될 메모리의 양을 결정할 수 있다. 이후, MSDC(1010)는 TSB(1012)에 대해 결정된 양의 메모리를 할당하고 SDP 메시지와 연관되는 수신된 미디어 데이터의 적어도 일부를 TSB(1012)에 저장할 수 있다.

[0108] TSB 깊이를 시그널링하기 위해서, 본 개시의 기술들은 SDP의 확장 매커니즘을 레버리지하기 위해 사용될 수 있다. SDP "a="(속성) 라인들은 일반 세션 디스크립션으로의 확장들을 제공하기 위해 사용될 수 있다. 하기의 시맨틱은 TSB와 관련된 데이터를 시그널링하기 위해 사용될 수 있으며, 일례로서:

●TSB-속성="a=tsb-length:"값

●값=토큰

○값은 단위로서 초(seconds)를 가질 것이다.

[0109] 예로서, 표 1에 언급된 다음 SDP 스니펫은 TSB에 대한 데이터를 설명한다. 이 예에서의 버퍼 깊이는 60초 또는 1분이다. 이는, MSDC(예를 들어, 도 10에 도시된 MSDC의 TSB)는 그의 시간-시프트 버퍼 내 미디어 콘텐츠의 1분의 가치를 유지할 것이라는 것을 의미한다. 밑줄친 텍스트는, TSB와 관련된 본 개시의 기술들에 따라서 "a=" 라인의 형태로 예시적인 속성을 나타낸다.

표 1

[0110] TSB에 대한 데이터가 SDP에 제공되는 경우, MSDC는 SDP에서 언급된 크기의 동등한 양 버퍼를 할당할 수 있고, RTSP/RTP 클라이언트로 하여금, 버퍼 지속기간에 대하여 빨리감기 또는 되감기 플레이백하게 허용할 수 있다.

[0111] 전송 다이버시티를 달성하기 위한 하나의 예시적 기술은 2013년 1월 15일에 폴(Fall) 등에 의해 출원된 미국 가출원 시리얼 넘버 제61/752,456호 "ARCHITECTURE SUPPORTING TRANSPORT DIVERSITY"(어토니 도켓 넘버 131286P1, 이하, "Fall provisional application", 상기 출원의 전체 콘텐츠들은 인용에 의해 본원에 포함됨)에 의해 제안된 솔루션에 기초한다. 폴(Fall) 가출원은 다양한 전송 프로토콜들을 지원하기 위한 공통 클라이언트 아키텍처를 제시한다. RTP에서의 전송 다이버시티를 지원하기 위한 본 개시의 기술들은, 콘텐츠들의 DASH-기반 전달과 관련되는 폴 가출원에 설명된 기술들을 확장시키는 데에 사용될 수 있다.

[0112] 미디어 프리젠테이션 디스크립션(MPD)에서의 미디어 표현들은 전송 전달 방법들에 기초하여 변경될 수 있는 DASH 프로토콜과는 달리, RTP 프로토콜은 통상적으로 직접적으로 하나의 SDP 프로파일을 통해 전송 다이버시티를 구분할 방법이 없다. 본 개시는 전송 다이버시티를 달성하기 위한 예시적인 기술들을 설명한다.

[0113] 일례로서, 서비스들의 eMBMS 브로드캐스트 정의들은, 메커니즘들이 유니캐스트와 브로드캐스트 전송 메커니즘들 사이에서 선택되게 허용한다. 예를 들어, eMBMS 서비스 정의 스키마에서의 deliveryMethod 엘리먼트는 브로드캐스트 전달 세션을 설명하는 SDP 프로파일을 포함할 수 있는 반면, AlternativeAccessDelivery 엘리먼트는 유니캐스트 SDP 세션 정보를 의미하는 PSS SDP 파일 또는 유니캐스트 액세스에 대한 RTSP URL에 대한 레퍼런스들을 포함할 수 있다. UE가 브로드캐스트 네크워크 커버리지 하에 있는 경우, eMEMS 미들웨어는 브로드캐스트 SDP 세션 정보를 이용하여 브로드캐스트 콘텐츠를 소비할 수 있다. 이와 달리, 미들웨어는 AlternativeAccessDelivery의 unicastAccessURI에 연결함으로써 콘텐츠를 전달할 수 있다. eMEMS 사용자 서비스 디스크립션(USD) 스키마 스니펫의 예가 도 11에 도시된다.

[0114] 브로드캐스트 SDP와 유니캐스트 액세스 URI를 반송하는 deliveryMethod에 대한 대안적인 예는, 상이한 매체 스트림들 내에 유니캐스트 및 브로드캐스트 세션 디스크립션들 둘다를 포함하는 통합된 하나의 SDP를 갖는 것이다. SDP의 임의의 세션 디스크립션이 다수의 매체 스트림 정의들(예를 들어, 하나는 오디오 트랙을 위한 것이고 다른 하나는 비디오 트랙을 위한 것임)을 포함할 수 있기 때문에, 통합된 SDP 프로파일을 제공하기 위해 브로드캐스트 및 유니캐스트 매체 스트림들을 상이한 세트들로 그룹화하는데 메커니즘이 사용될 수 있다. 이는 SDP의 그룹화 방법에 의해 달성될 수 있다. 그룹화 메커니즘의 예는 다음과 같이 설명된다:

●미디어 스트림 식별

○그룹들 내의 미디어 스트림들을 식별함

○미디어-속성="a=mid": 식별-태그

○식별-태그=토큰

●그룹 속성

○유니캐스트/브로드캐스트 미디어 스트림들을 식별함

○그룹-속성="a=그룹": 시맨틱(식별-태그)*

○시맨틱="BROADCAST"｜"UNICAST"

[0115] 하기 표 2의 스피넷은, 값들이 그룹 및 미디어 스트림 식별자 속성들에 대해 제공되는 일 예를 제공한다. 아래의 예에서, "a=group:" 라인은, 어떤 미디어 스트림들이 브로드캐스트를 위해 사용되는지 그리고 어떤 미디어 스트림들이 유니캐스트에 대해 사용되는지를 표시한다. 이러한 예에서, 브로드캐스트 미디어 스트림들은 "a=mid:" 값들 1 및 2에 의해, 그리고 유니캐스트는 "a=mid:" 값들 3 및 4에 의해 각각 표시된다. 따라서, 미들웨어는, 브로드캐스트 콘텐츠에 대해서는 IP 어드레스 224.1.1.2 및 포트들 30000 및 30002에 그리고 유니캐스트 스트림들에 대해서는 IP 어드레스 131.10.1.2 및 포트들 26890 및 26892에 접속할 수도 있다.

표 2

[0116] 이런 식으로, 도 10은, 시간-시프트 버퍼(TSB) 깊이를 정의하고, 속성의 값에 기초하여 TSB에 대한 메모리의 양을 결정하고, 결정된 양의 메모리를 TSB에 할당하며, SDP 메시지와 연관된 미디어 데이터의 적어도 일부를 TSB에 저장하는 속성을 포함하는 세션 디스크립션 프로토콜(SDP) 메시지를 수신하도록 구성된 하나 또는 그 초과의 프로세서들을 포함하는 디바이스의 일 예를 도시한다.

[0117] 도 12 및 13은, RTSP/RTP 클라이언트에 대한 전송 다이버시티를 지원하기 위한 예시적인 컴포넌트들을 도시하는 블록도들이다. eMBMS USD에서의 전달 방법이 브로드캐스트와 유니캐스트 전송 사이를 구별하는데 사용되는지 또는 통합된 단일 SDP 메커니즘이 사용되는지에 관계없이, 본 개시의 기술들은 RTSP/RTP 클라이언트에 의한 끊김없는 콘텐츠 획득을 제공할 수도 있다. 이를 달성하기 위해, 폴 가출원에서 제안된 바와 같이, 정책 관리기, 제어기, 및 RTSP 리디렉터/프록시가 UE에서, (멀티캐스트 서비스 디바이스 클라이언트(MSDC로 또한 지칭되는) 가급적 eMBMS 외부에서 유지될 수도 있다. RTSP 클라이언트가 SDP를 요청하는 경우, RTSP 리디렉터/프록시는, 로컬호스트(localhost)(예를 들어, IP 버전 4 어드레스 127.0.0.1)를 접속 엔드포인트 어드레스로서 반송하는 SDP 프로파일들을 항상 제공한다. 아이디어는, RTSP 리디렉터/프록시가 (브로드캐스트에 대해서는) eMBMS 미들웨어 또는 (유니캐스트에 대해서는) 유니캐스트 RTSP 서버를 통해 콘텐츠를 수신하는지에 관계없이, 그것이 로컬호스트로부터 RTSP/RTP 클라이언트에 콘텐츠를 항상 제공한다는 것이다. 따라서, 클라이언트는 전송 메커니즘에서의 다이버시티를 인식하지 못한다. 아래에서, 본 발명자는, 아키텍처의 주요 컴포넌트들의 간단한 설명을 제공하며, 콘텐츠가 어떻게 클라이언트에게 전달되는지의 일 예를 제공한다.

[0118] 도 12 및 13의 예들에서, 플레이백 App는 스트리밍 콘텐츠를 소비하기도록 시도하고 있는 애플리케이션이고; RTSP/RTP 클라이언트는 클라이언트 거동에 대해 RTP 프로토콜을 구현하는 클라이언트이고; eMBMS 미들웨어는, (스트리밍 또는 파일 다운로드를 위해) eMBMS(또는 MBMS) 브로드캐스트 서비스 발견을 구현하고, 브로드캐스트 LTE 네트워크를 통해 스트리밍 또는 파일 전달 콘텐츠를 소비하는 미들웨어 아키텍처이고; 정책 관리기는 상술된 바와 같이 정책들의 데이터베이스를 보유하고; 제어기는, 정책 관리기로부터 정책 정보 및 eMBMS 미들웨어로부터 eMBMS 브로드캐스트 커버리지 표시를 획득하고, 어떤 SDP 프로파일을 선택할지(유니캐스트 또는 멀티캐스트)로 시작하여 RTSP 리디렉터/프록시에 대한 맵핑을 제공하는 컴포넌트이며; 그리고, RTSP 리디렉터/프록시는, 제어기로부터 맵핑 정보를 수신하고, 맵핑에 의존하여, eMBMS 미들웨어로부터 RTP 콘텐츠를 수집하거나(이 경우, UE는 브로드캐스트 커버리지에 있음) 또는 RTSP URI에 접속하고, 유니캐스트 전송을 통해 콘텐츠를 수신하는 프록시 유닛이고, 이후, 이 콘텐츠는 RTSP/RTP 클라이언트에게 전달된다.

[0119] 도 12는 RTP 콘텐츠의 브로드캐스트 전달을 위한 예시적인 절차를 표현한다. 도 12는, RTSP/RTP 클라이언트(1202), 플레이백 애플리케이션(1204), RTSP 리디렉터/프록시(1218), 제어기(1214), eMBMS 미들웨어(또한 MSDC로 지칭됨)(1208), 정책 관리기(1216), 및 브로드캐스트 송신 유닛(또한, eMBMS rX로 지칭됨)(1220)을 포함한다. 도 12는 또한, 롱텀 에볼루션(LTE) 라디오 액세스 네트워크(RAN)(1206)를 도시한다. LTE RAN(1206)은, 미디어 데이터에 대한 복수의 전송 타입들(예를 들어, 브로드캐스트, 멀티캐스트, 또는 유니캐스트) 중 적어도 하나를 정의하는 MBMS 서비스를 제공한다. 따라서, MSDC(1208)가 LTE RAN(1206)에 의해 제공되는 커버리지의 서비스 영역에 있는 경우, MSDC(1208)는 브로드캐스트 또는 멀티캐스트 전송을 사용하여 LTE RAN(1206)을 통해 미디어 데이터를 수신할 수 있다. 또한, MSDC(1208)는 캐시(1210)를 포함하는 서버(1212)를 구현한다. 이런식으로, MSDC(1208)는, 미디어 데이터를 수신하는 클라이언트, 및 데이터를, 예를 들어, RTSP/RTP 클라이언트(1202)에 제공하는 서버 둘 다로서 동작할 수 있다. 또한, RTSP/RTP 클라이언트(1202)는, 예를 들어, MSDC(1208) 또는 RTSP 리디렉션/프록시(1218)로부터 미디어 데이터를 리트리브하고, 그 후, 미디어 데이터를 플레이백 애플리케이션(1204)에 제공할 수 있다.

[0120] 플레이백 애플리케이션(1204)은, 애플리케이션(101)(도 1)에 실질적으로 대응할 수도 있지만, RTSP/RTP 클라이언트(1202)는 애플리케이션 서비스 클라이언트(102)(도 1)에 실질적으로 대응할 수도 있다. 유사하게, MSDC(1208)는 전송 미들웨어(110A-110R)(도 10) 중 하나에 실질적으로 대응할 수도 있다. 제어기(1214)는 제어기(106)(도 1)에 실질적으로 대응할 수도 있다. RTSP 리디렉터/프록시(1218)는 리디렉터/프록시(104)(도 1)에 실질적으로 대응할 수도 있다.

[0121] 이러한 예에서, 정책 관리기에는 정책들이 프로비저닝된다(1230). eMBMS 미들웨어(또는 MSDC)(1208)는 eMBMS 서비스들의 리스트에 대한 USD 디스크립션들(1232, 1234)을 수신한다. 그 후, MSDC(1208)는, RTP 스트리밍 서비스에 대한 SDP 프로파일 정보 및 브로드캐스트 커버리지 통지를 제어기(1214)에 전달하며(1236), 이는 결국 SDP 정보를 정책들의 리스트와 매치시키며, 맵핑 정보를 RTSP 리디렉터/프록시(1218)에 제공한다(1238). 맵핑 정보는, 각각의 시나리오(브로드캐스트 또는 유니캐스트 커버리지)에 대해, 어떤 SDP 프로파일 접속-엔드포인트들이 사용될지를 표시하는 데이터를 포함한다. 이런 식으로, RTSP 리디렉터는, 미디어 데이터를 리트리브하기 위한 서비스에 기초하여 미디어 데이터에 대한 식별자를 리소스 로케이션에 맵핑하는 맵핑 정보를 획득할 수도 있다. 리소스 로케이션은 네트워크 어드레스, 예를 들어, LTE RAN(1206)을 통해 이용가능한 어드레스에 대응할 수도 있다. 서비스는, 미디어 데이터를 전달하기 위한 복수의 전송 타입들, 예를 들어, 브로드캐스트 또는 멀티캐스트 중 적어도 하나를 정의할 수도 있다.

[0122] 한편, MSDC(1208)는 플레이백 애플리케이션(1204)에 서비스들의 리스트를 전달한다(1240). 플레이백 애플리케이션(1204)은 애플리케이션(101)(도 1)에 대응할 수도 있다. 그 후, 플레이백 애플리케이션(1204)은, (MSDC로부터의 서비스들의 리스트와 함께 제공되는) RTSP URI 및 프록시 어드레스를 RTSP/RTP 클라이언트(1202)에 전달한다(1242). RTSP/RTP(1202) 클라이언트가 DESCRIBE 커맨드(RTSP가 커맨드를 정의했음)를 호출하는 경우(1244), RTSP 리디렉터/프록시(1218)는, 로컬 서버로 리디렉팅되는 변경된 SDP 메시지를 제공한다(1246). RTSP/RTP 클라이언트(1202)는, SDP 정보를 분석하며(1248), 로컬 서버와의 RTP 세션을 셋업하기 위해 SETUP 커맨드(RTSP 커맨드)를 호출한다. RTSP/RTP 클라이언트(1202)는 또한, 서버와의 셋업이 성공하는 경우, PLAY 커맨드를 전달한다(1250). RTSP 리디렉션/프록시(1218)는 SETUP 및 PLAY 요청에 대한 성공 메시지를 RSTP/RTP 클라이언트(1202)에 제공한다(1252). RTSP/RTP 클라이언트(1202)로부터 RTSP 리디렉션/프록시(1218)에 의해 수신된 SETUP 및 PLAY 커맨드들은 미디어 데이터에 대한 요청의 일 예를 표현한다. 부가적으로, RTSP 리디렉터/프록시(1218)는 SETUP 및 PLAY 커맨드들을 MSDC(1208)에 전송한다(1251).

[0123] RTSP 리디렉터/프록시(1218)는, 미디어 데이터를 리트리브하기 위한 서비스가 이용가능한지, 예를 들어, 전송으로서 브로드캐스트 또는 멀티캐스트를 정의하는 서비스가 이용가능한지를 결정할 수도 있다. RTSP 리디렉터/프록시(1218)는, RTSP 리디렉터/프록시(1218) 또는 MSDC(1208)이 서비스 커버리지 구역 내에 있는지에 적어도 부분적으로 기초하여 서비스가 이용가능한지를 결정할 수도 있다. 도 12의 기술들은, 서비스가 이용가능하다고 가정한다. 도 13은 더 상세히 후술되는 바와 같이, 서비스가 이용가능하지 않은 경우 이용될 수 있는 부가적인 기술들을 설명한다.

[0124] 한편, 스트리밍 서비스의 활성 브로드캐스트 세션 동안, 네트워크 오퍼레이터는 LTE RAN(1206)을 통해 RTP 콘텐츠를 전송한다(1254). MSDC는, (도 12에서 eMBMS rX(1220)로 라벨링된) 브로드캐스트 접속 엔드포인트로부터 서비스에 대한 RTP 콘텐츠를 수집하고(1256), (필요하다면) 콘텐츠를 프로세싱하며, RTSP 리디렉터/프록시와의 SETUP 커맨드 동안 클라이언트에 의해 특정된 엔드포인트에서 RTSP/RTP 클라이언트(1202)에 콘텐츠를 전달한다(1258). 이런 식으로, 서비스가 이용가능한 경우(예를 들어, 서비스가 브로드캐스트 또는 멀티캐스트 전송을 정의함), RTSP 리디렉터/프록시(1218)는, RTSP/RTP 클라이언트(1202)로 하여금 MSDC(1208)(즉, 리소스 로케이션로부터의 서비스를 사용하여, 예를 들어, LTE RAN(1206)을 통해 미디어 데이터를 수신하는 유닛)로부터 미디어 데이터를 수신하게 한다. 특히, 이러한 예에서, MSDC(1208)는 서비스를 이러한 로케이션에 맵핑하는 맵핑 정보(예를 들어, 상술된 USD 데이터)에 기초하여 LTE RAN(1206)을 통해 네트워크 로케이션로부터 미디어 데이터를 수신한다.

[0125] 이런 식으로, 도 12의 기술들은, 프록시 유닛(예를 들어, RTSP 리디렉터/프록시(1218))에 의해, 미디어 데이터를 리트리브하기 위한 서비스에 기초하여 미디어 데이터에 대한 식별자를 리소스 로케이션에 맵핑하는 맵핑 정보를 획득하는 단계 ―상기 서비스는 미디어 데이터를 전송하기 위한 복수의 전송 타입들(예를 들어, 브로드캐스트, 멀티캐스트, 또는 유니캐스트) 중 적어도 하나를 정의함―, 애플리케이션 서비스 클라이언트(예를 들어, RTSP/RTP 클라이언트(1202))로부터 미디어 데이터에 대한 요청을 수신하는 단계, 서비스가 이용가능한지를 결정하는 단계 및 서비스가 이용가능한 경우, 애플리케이션 서비스 클라이언트로 하여금, 맵핑 정보에 기초하여 리소스 로케이션로부터의 서비스를 이용하여 미디어 데이터를 수신하는 유닛으로부터 미디어 데이터를 수신하게 하는 단계를 포함하는 방법의 일례를 나타낸다. 미디어 데이터를 수신하는 유닛은, 이 예에서, MSDC(1208)에 해당한다.

[0126] 도 13은 RTP 콘텐츠의 유니캐스트 전달을 위한 예시적 절차를 나타낸다. 이 예에서, 단계들(1232-1248)은 도 12를 참조하여 설명된 콘텐츠의 브로드캐스트 전달과 실질적으로 동일하다. 그러나, 이 경우에서, RTSP/RTP 클라이언트가 SETUP 및 PLAY 커맨드들을 호출할 때(1310), RTSP 리디렉터/프록시(1218)는, 맵핑 정보로부터 RAN/인터넷(1302)을 통해 유니캐스트 RTSP 서버에 접촉하고(1312), 유니캐스트 RTSP 서버로부터의 콘텐츠들을 리트리브하고(1314), 그리고 SETUP 커맨드 동안 RTSP/RTP 클라이언트(1202)에 의해 언급된 또는 단계(1246)에서 SDP에 어나운싱된 엔드포인트로 콘텐츠를 전달한다(1316). 따라서, 이 경우, (RTSP/RTP 클라이언트(1202)를 또한 포함하는 사용자 장비에 존재할 수 있는) RTSP 리디렉터/프록시(1218)는 원격의 RTSP 서버에 대한 클라이언트로서 동작하고 콘텐츠를 RTSP/RTP 클라이언트 대신에 리트리브한다.

[0127] 이런 식으로, 본 개시의 기술들은 RTP 콘텐츠의 eMBMS 브로드캐스트 전달을 위한 TSB 표시를 제공하기 위해 SDP 확장 메커니즘(속성)을 이용할 수 있다. 이 개시는 또한, 브로드캐스트 전송과 유니캐스트 전송 간의 끊김없는 전환을 지원하고, 그리고 UE 내에에 RTP 미디어 콘텐츠 전송 메커니즘들을 제공하기 위한 예시적 아키텍처를 정의한다. 더욱이, 본 개시는 SDP 메시지 내 콘텐츠의 유니캐스트 및 브로드캐스트 전달을 위한 다수의 RTP-기반 미디어 스트림들의 그룹화를 위한 기술들을 설명한다.

[0128] RTSP 리디렉터/프록시(1218)는, 미디어 데이터를 리트리브하기 위한 서비스에 기초하여 미디어 데이터에 대한 식별자를 리소스 로케이션에 맵핑하는 맵핑 정보를 획득하고 ―상기 서비스는, 미디어 데이터를 전송하기 위한 복수의 전송 타입들(예를 들어, 브로드캐스트, 멀티캐스트, 또는 유니캐스트) 중 적어도 하나를 정의함―, 애플리케이션 서비스 클라이언트로부터 미디어 데이터에 대한 요청을 수신하고, 서비스가 이용가능한지를 결정하고, 그리고 서비스가 이용가능한 경우, 애플리케이션 서비스 클라이언트로 하여금, 맵핑 정보에 기초하여 리소스 로케이션로부터의 서비스를 이용하여 미디어 데이터를 수신하는 유닛으로부터 미디어 데이터를 수신하도록 구성될 수 있는 프록시 유닛의 일례를 나타낸다.

[0129] 도 14a 및 도 14b는, DASH 전송 정보를 전달하기 위해 USD를 확장하기 위한 예시적 XML 콘텐츠 모델을 예시하는 개념도들이다. 원 A는, 도 14a와 도 14b 사이의 연결들이 결합되는 지점을 나타낸다. XML 콘텐츠 모델은 단독으로 이용될 수 있거나 또는 앞서 설명된 기술들 중 임의의 기술과 조합하여 이용될 수 있다. 예를 들어, 도 1, 도 2a, 도 2b, 도 6, 도 7, 및/또는 도 8의 컴포넌트들은 도 14a 및 도 14b를 참조하여 설명된 XML 콘텐츠 모델을 활용하도록 구성될 수 있다. 앞서 논의된 바와 같이, 본 개시의 기술들은 유니캐스트 전송 모드와 브로드캐스트 전송 모드 사이를 선택하기 위한 기술들을 포함한다. 도 14b는 브로드캐스트 표현(USD에서의 broadcast 엘리먼트) 및 유니캐스트 표현(USD에서의 unicast 엘리먼트) 둘 다를 정의하는 데이터를 예시한다.

[0130] 본 개시의 특정 기술들에 따르면, DASH 클라이언트(예를 들어, 도 1, 도 2a, 도 2b, 도 6, 도 7, 및/또는 도 8의 DASH 클라이언트)와 같은 애플리케이션 서비스 클라이언트는 세그먼트(Segment)를 리트리브할 표현의 초기 선택을 행할 수 있다. 특히, DASH 클라이언트는, 요청된 세그먼트가 속하는 표현의 전송 모드(브로드캐스트 및/또는 유니캐스트)의 불가지론(agnostic)을 유지하면서 이러한 초기 선택을 행할 수 있다. 예시를 목적으로, 선택된 표현의 세그먼트들을 요청하는데 있어서 DASH 클라이언트에 의해 HTTP가 이용될 뿐만 아니라 DASH 전송 정보를 전달하기 위해 도 14b에 도시된 확장된 USD가 이용된다고 가정한다. 하나 또는 그 초과의 브로드캐스트 표현들 각각은, USD에서 broadcast 엘리먼트의 고유 baseURL 속성에 의해 식별된다.

[0131] broadcast의 각각의 인스턴스는, MBMS 베어러를 통해 전달된 고유한 표현으로 맵핑한다. 그 baseURL은, 세그먼트들을 요청하기 위해 DASH 클라이언트에 의해 이용된 세그먼트 URL의 일부 ―특히, URI 스킴으로부터 시작하고 그 세그먼트가 속하는 표현의 식별자까지 확장하고 그 식별자를 포함하는 세그먼트 URL의 초기 부분과 비교되어, 그 표현이 요청되고 있는 중인지 여부를 결정할 것이다.

[0132] 예를 들어, DASH 클라이언트에 의해 이슈된 세그먼트 URL이, 기간 3(Period@id='3')에서 표현(512)(Representation@id='512')의 세그먼트 99에 대한 요청에 대응하는 "http://example.com/per-3/rep-512/seg-99.3gp"인 것으로 가정한다. USD에서의 basesURL과의 매칭을 목적으로 한 이러한 관심 URL의 일부는 "http://example.com/per-3/rep-512이다. 이러한 표현이 또한 브로드캐스트를 통해 이용가능한 경우, mediaPresentationDescription2.broadcast의 인스턴스는, 요청 URL에서 관심 부분과 동일한 "http://example.com/per-3/rep-512"에 의해 제시되는 basesURL을 갖는 USD 내에 존재할 것이다. 예를 들어, USD의 broadcast 엘리먼트의 basesURL 속성에 대한 요청 URL에 대한 관심 부분의 매치는, 요청된 세그먼트가 속하는 표현의 브로드캐스트 전송을 나타낸다.

[0133] 유사하게, 0 또는 그 초과의 유니캐스트 표현들 각각은, 이 예에서, mediaPresentationDescription2.unicast 엘리먼트의 고유 baseURL 속성에 의해 USD에서 식별된다. 앞서 논의된 것과 동일한 요청 URL 부분에서의 매치 패턴은, 이러한 표현이 유니캐스트 전달을 통해 이용가능하다는 점을 의미한다. 동일한 표현은, 전송 모드들 중 둘 다를 통해, 이들 중 오직 하나만을 통해, 또는 이들 둘 다를 통하지 않고 이용가능할 수 있다.

[0134] DASH 클라이언트가 세그먼트 요청을 제출하는 엔티티는, 프록시 유닛(또는 MBMS 또는 eMBMS 클라이언트)일 수 있다. 예시를 목적으로, 프록시 유닛이 이러한 기술들을 수행하는 것으로서 아래에 설명되지만, 예를 들어, 도 1, 도 2a, 도 2b, 도 6, 도 7, 및/또는 도 8의 MBMS 또는 eMBMS가 아래 설명된 바와 같이 프록시 유닛에 기인된(attributed to) 기술들을 수행하도록 구성될 수 있다는 점이 이해되어야 한다. USD의 broadcast 및 unicast 엘리먼트들에서의 baseURL의 값으로 요청 URL에 대한 관심 부분 간의 패턴 매치를 이용함으로써, 프록시 유닛은 선택된 전송 모드가 이용가능한지 그리고/또는 다른 전송 모드에 비해 선호되는지를 결정할 수 있다.

[0135] 프록시 유닛은, 전송들의 타입들 사이에서의 선호도들을 나타내는 정책을 리트리브할 수 있다. 예를 들어, 정책은, 요청이 유니캐스트를 통해 전달되는 표현을 위한 것이라면, 디바이스가 브로드캐스트 커버리지 구역 내에 로케이팅되어 있는 한, 오직 브로드캐스트-전달 표현만이 DASH 클라이언트에 액세스가능해야 한다는 것을 나타낼 수 있다. 이러한 브로드캐스트 표현은, baseURL이 USD의 identicalContent 엘리먼트에 나타나고 그리고 상이한 전송 모드상에서 전달되지만 요청된 표현을 대체할 수 있다면, 원래 요청된 것과 동일한 표현일 수 있다.

[0136] 대안적으로, 브로드캐스트 표현은, 브로드캐스트를 통해 전달되는 것으로 알려져있는 대체 표현일 수 있고, 그리고 대체 표현에 대한 baseURL이 USD 엘리먼트 switchableContent의 엔트리들의 리스트 내에 나타나기 때문에, 스위칭가능한 표현으로 고려된다. 이 경우, 프록시 유닛은 브로드캐스트를 통해 전달된 대안적 표현에 속하는 동일한 세그먼트를 DASH 클라이언트로 하여금 요청하게 하기 위한 메시지를 DASH 클라이언트에 다시 전송할 수 있다. 예를 들어, 프록시 유닛은, 리디렉트 메시지에 대응하는 300-타입 HTTP 응답 메시지를 DASH 클라이언트에 전송할 수 있고, 리디렉트 메시지는 switchableContent에 포함된 리스트로부터 대안적 표현에 대응하는 리소스 URL을 특정할 수 있다.

[0137] 또 다른 예로서, DASH 클라이언트가 브로드캐스트를 통해 전달되는 것으로 프록시 유닛에 알려져 있는 세그먼트를 요청하였지만, (예를 들어, 브로드캐스트 전송에 대한 커버리지 구역 밖에 있는 클라이언트 디바이스로 인하여) 브로드캐스트 수신이 이용가능하지 않으면, 프록시 유닛은, 그 동일한 표현이 유니케스트 전송을 통해 이용가능하지 않지만 switchableContent 에서 엔트리로서 나타나는 경우 동일하거나 상이한 표현의 유니케스트 전송에 대응하는 세그먼트의 URL을 포함하는 300-타입 HTTP 응답 메시지를 전송할 수 있다.

[0138] 또 다른 예에서, DASH 클라이언트가 브로드캐스트를 통해 전달되는 것으로 프록시 유닛에 알려져 있는 세그먼트를 요청하였고, 브로드캐스트 수신이 이용가능하다면, 프록시 유닛은, 요청을 로컬 콘텐츠 캐시에 프록시하고, 리트리브된 세그먼트를 DASH 클라이언트에 다시 전달할 것이다.

[0139] 대안적으로, 프록시 유닛은 DASH 클라이언트로 하여금 상이한 세그먼트 URL을 이용하여 요청을 다시 제출하게 할 수 있는 400-타입 에러 메시지에 응답할 수 있다. 프록시 유닛은, 마찬가지로 다른 방식들로, 예를 들어, API(application programming interface), IPC(inter-process communication), 선택된 베이스 URL을 생략하는 수정된 MPD의 전송 등을 통해, 상이한 전송 프로토콜을 통신할 수 있다.

[0140] 프록시 유닛으로부터의 리디렉트 또는 에러 메시지는 DASH 클라이언트가 상이한 전송 모드를 선택하게 할 수 있다. 일부 예들에서, 하나 초과의 표현은 리디렉팅된 전송 모드상에서 이용가능할 수 있으며, 이 경우 DASH 클라이언트는 이용가능한 표현들 중 하나 사이에서부터 선택할 수 있다. 예로서, (도 14a 및 도 14b의 broadcast 엘리먼트의 인스턴스에 의해 제시된 바와 같이) DASH 클라이언트가 브로드캐스트 표현을 선택하려고 시도하였지만 프록시 유닛이 브로드캐스트 수신이 이용가능하지 않다고 결정하였으면, 프록시 유닛은 DASH 클라이언트가 대신 도 14a 및 도 14b의 유니캐스트 표현을 선택하게 하기 위해 메시지(예를 들어, 300-타입 리디렉트 메시지, 400-타입 에러 메시지, API 호, 비아 IPC 통신들 등)를 DASH 클라이언트에 전송할 수 있다.

[0141] 일부 경우들에서, DASH 클라이언트와 같은 애플리케이션 서비스 클라이언트에게는 유니캐스트-브로드캐스트 전환들을 관리하는 태스크가 주어질 수 있다. 본 개시는, 일 예로서 도 14a 및 도 14b에 대해, MBMS 다운로드 전달을 통한 DASH의 경우, MBMS 클라이언트가 DASH 클라이언트로부터의 세그먼트 요청들이 있는 그대로 서빙되는지, 단지 하나 또는 그 초과의 대안적 표현들로부터 서빙되는지를 결정하게 할 수 있는 추가 파라미터들로 USD를 확장하기 위한 프레임워크를 설명한다. USD는 MPD(Media Presentation Description)에서 특정된 각각의 표현의 전송 모드(브로드캐스트-전용, 유니캐스트-전용 또는 브로드캐스트 및 유니캐스트 둘 모두)를 표시할 수 있다. 표현 이용가능성을 결정하기 위한 룰들 및 메커니즘들에 대한 예시적 시나리오들이 아래에서 설명된다.

[0142] 일 예에서, 사용자 장비(UE)는 MBMS 커버리지 구역 내에 로케이팅될 수 있고, DASH 클라이언트는, 브로드캐스트 전달을 통해 이용가능하지 않다는 것을 USD가 표시하고 있는 특정 표현을 요청할 수 있다. 서비스 제공자 정책은, UE가 MBMS 커버리지 내에 있을 때는 언제든, 단지 동일한 프로그램의 브로드캐스트-전달 표현들만이 액세스될 수 있음을 지시할 수 있다. 이런 상황에서, DASH 클라이언트는 브로드캐스트 전달을 통해 이용가능한 대안적 표현(들) 중에서 선택하는 것으로 제한될 수 있다(또는 선택하도록 리디렉팅되거나 명령받을 수 있음).

[0143] 또 다른 예에서, UE가 MBMS 커버리지 내에 로케이팅될 수 있고, DASH 클라이언트는 브로드캐스트 전달을 통해 이용가능한 것으로 알려져 있는 표현을 요청할 수 있다. 이런 상황에서, 원하는 표현은 UE에 의해 직접 액세스될 수 있다.

[0144] 또 다른 예에서, UE는 MBMS 수신 영역 밖에 있을 수 있고, DASH 클라이언트는 단지 브로드캐스트 전달을 통해서만 이용가능한 것으로 알려져 있는 표현을 요청할 수 있다. 이런 상황에서, DASH 클라이언트는 스위칭가능한 콘텐츠(들)의 형태로 유니캐스트 전달을 통해 이용가능한 대안적 표현(들) 중에서 선택하는 것으로 제한될 수 있다(또는 선택하도록 리디렉팅되거나 명령받을 수 있음).

[0145] 또 다른 예에서, UE는 MBMS 수신 영역 밖에 있을 수 있고, DASH 클라이언트는 브로드캐스트 전달을 통해 또한 이용가능한 것으로 알려져 있는 표현을 요청할 수 있다. 이런 상황에서, DASH 클라이언트는 동일한 콘텐츠의 형태로, 유니캐스트 상에서 동일한 표현을 수신할 수 있다.

[0146] USD에서 전달될 수 있는 추가 정보는 각각의 표현이 전달되게 하는 서비스 영역(들)의 표시 및/또는 그 표현을 전달하는 FLUTE 세션을 설명하는 SDP의 식별을 포함한다.

[0147] 본 개시는 mediaPresentationDescription2 차일드(child) 엘리먼트가 추가 전송 파라미터들을 전달하도록 userServiceDescription 하에 추가될 수 있게 하는 기술들을 설명한다. 이전에, MPD-특정 파라미터들, 이를 테면, 기간 ID, 적응 세트 ID 및 표현 ID가 유니캐스트 전달을 통해 이용가능한 그 표현들을 식별할 수 있는 mediaPresentationDescription2에 포함되는 것이 제안되었다. 세션 설명 프래그먼트에 대한 URI 참조와 함께, 이 동일한 파라미터들은 브로드캐스트를 통해 전달될 수 있는 각각의 표현뿐만 아니라, 그 표현의 세그먼트들을 전달하는 FLUTE 세션에 대한 맵핑을 식별할 수 있다.

[0148] 본 개시의 기술들이 해결할 수 있는 하나의 이슈는, 프로토콜 프로세싱에서의 클린 레이어링(clean layering) 분리를 유지하면서, 세그먼트 요청/응답에 대해 DASH 클라이언트와 MBMS 클라이언트 간의 프로토콜 인터페이스로서 HTTP/1.1의 이용을 가능하게 하는 것과 관련된다. 이를 테면, 이전의 기술들에서, MBMS 클라이언트는 특정 표현의 세그먼트들에 대한 DASH 클라이언트 요청을, 전송 모드(브로드캐스트 또는 유니캐스트)에 의한 실제로 이용가능하며 허가된(예를 들어, 서비스 제공자 정책에 따른) 표현 세그먼트들과 상관시킬 수 있도록 MPD-특정 정보를 프로세싱하여야 한다. 요청된 표현이 제공될 수 없는 경우, MBMS 클라이언트가 HTTP 리디렉션을 이용하여 (http://www.ietf.org/rfc/rfc2616.txt에서 입수가능한 1999년 6월의 "Hypertext Transfer Protocol - HTTP/1.1," 네트워크 워킹 그룹, RFC 2616에 Fielding 등에서 정의된 바와 같은 3xx 응답 코드들을 통해) 하나 또는 그 초과의 대안적 표현들을 DASH 클라이언트에 통지하게 하기 위해, MBMS 클라이언트는 각각의 대안적 리소스에 대한 완벽한 세그먼트 URI를 구성해야 할 것이다. MBMS 클라이언트에 의한 이러한 레이어링 위반(layering violation)은 본 개시의 기술들의 이용을 통해 제거될 수 있다.

[0149] 본 개시의 기술들은 (DASH-특정) MPD 정보를 인식하거나 (DASH-특정) MPD 정보를 프로세싱해야 하는 MBMS 클라이언트(또는 프록시 유닛)에 대한 필요성을 제거한다. MBMS 클라이언트는 단지, 요청된 세그먼트가 브로드캐스트를 통해, 유니캐스트를 통해, 이 둘 중 어느 것도 통하지 않고 또는 이 둘 다의 전송 모드들을 통해 또는 일부 다른 방식(예를 들어, 캐시)에 의해 이용가능한지를 결정하는데 있어, DASH 클라이언트에 의해 생성된 세그먼트 요청 URI들을 갖는, USD 내의 새로운 메타데이터의 존재에 기초하여, 데이터/패턴 매칭을 수행한다. 이것은, 요청된 세그먼트가 속하는 표현을 고유하게 식별하는 요청 URI의 부분이 USD에서 또한 전달되기 때문에 가능하다. 이외에도, MBMS 클라이언트는, USD 내의 매칭 데이터 패턴의 로케이션에 의해, (전송 모드에 대해 불가지론적인) DASH 클라이언트에 의해 요청되는 표현이 브로드캐스트를 통해, 유니캐스트를 통해, 이 둘 중 어느 것도 통하지 않고 또는 이 둘 다의 전송 모드들을 통해, 또는 일부 다른 방식(예를 들어, 캐시)에 의해 이용가능한지를 결정할 수 있다. 임의의 다른 관련 룰들 및 조건들, 이를 테면, 커버리지 조건(UE가 유니캐스트 및/또는 브로드캐스트 서비스 영역에 있는지 여부), 서비스 제공자 정책 등과 함께, 대안적 리소스 URI를 리턴하기 위한 대안적 방법이 USD 속성 replacementAllowed = 'true'에 기초하여 허용된다고 가정한다. MBMS 클라이언트는, 프로토콜 레이어링 위반 없이, HTTP/1.1 메커니즘들을 이용하여 세그먼트 요청들을 적절한 리소스에― 예를 들어, UE 내의 로컬 콘텐츠 캐시 또는 외부 HTTP 서버에 중재(mediate)할 수 있다.

[0150] 도 14a 및 도 14b의 예들에 도시될 수 있는 바와 같이, 하나 또는 그 초과의 브로드캐스트 표현들 각각은 broadcast 엘리먼트의 고유한 baseURL 속성에 의해 USD에서 식별된다. baseURL 값은 해당 표현의 세그먼트를 요청하기 위해 DASH 클라이언트에 의해 이용되는 세그먼트 URI의 부분 ―특정하게, RepresentationID로 연장되며 이를 포함하고 그리고 방법으로부터 시작하는 세그먼트 URI의 초기 부분과 동일할 수 있다. 예를 들어, 세그먼트 URI가 기간 3에서 표현 512(RepresentationID = 512)의 세그먼트 99에 대한 요청에 대응하는 URL "http://example.com/per-3/rep-512/seg-99.3gp,"이면, baseURL은 "http://example.com/per-3/rep-512"로서 정의될 수 있다.

[0151] 이 예에서, 하나 또는 그 초과의 브로드캐스트 표현들 각각은 broadcast 엘리먼트의 고유 baseURL 속성에 의해 USD에서 식별된다. broadcast의 각각의 인스턴스는 MBMS 베어러를 통해 전달된 고유 표현에 맵핑된다. 그 baseURL은 세그먼트들을 요청하기 위해 DASH 클라이언트에 의해 이용된 세그먼트 URI의 부분 ―특정하게, Representation-ID(MPD의 Representation@id의 값)로 연장되며 이를 포함하고, 그리고 URI 스킴으로부터 시작하는 세그먼트 URI의 초기 부분과 비교될 것이다. 예를 들어, DASH 클라이언트에 의해 이슈된 세그먼트 URI가, 기간 3(Period@id = '3')에서 표현 512(Representation@id = '512')의 세그먼트 99에 대한 요청에 대응하는 URL "http://example.com/per-3/rep-512/seg-99.3gp"이라는 것을 가정한다. USD 데이터와의 매칭을 목적으로 한 이러한 관심 URL의 부분은 "http://example.com/per-3/rep-512"이다. 이러한 표현이 브로드캐스트를 통해 또한 이용가능한 경우, mediaPresentationDescription2.broadcast의 인스턴스는, 요청 URI의 관심 있는 부분과 동일한 "http://example.com/per-3/rep-512"에 의해 주어진 baseURL과 함께 USD에 존재할 것이다.

[0152] MBMS 클라이언트가, DASH 클라이언트에 의해 요청된 대안적 표현(들)에만 액세스될 수 있음을 결정하는 경우, mediaPresentationDescription2의 replacementAllowed 속성은, 이러한 통지를, 예를 들어, RFC 2616에서 정의된 바와 같은 HTTP 리디렉트(3xx 상태 코드) 방법을 통해 DASH 클라이언트에 제공할지 그리고 어떻게 제공할지를 MBMS 클라이언트에 표시할 수 있다.

[0153] 예를 들어, replacementAllowed = '참'인 경우, 대안적 표현의 전송 모드와 상관없이, MBMS 클라이언트가, '303 See Other' 리디렉션을 통해 대안적 리소스 URI(들)를 DASH 클라이언트에 제공하도록 허용하는 방식으로, DASH 콘텐츠 및 MPD가 구성되었다(authored)고 가정될 수 있다. 구체적으로, 각각의 대안적 URI는, 앞서 설명된 바와 같은 세그먼트 URI의 관심 있는 부분을 대안적 표현에 대응하는 USD의 baseURL로 교체하는 한편, 원래의 요청의 세그먼트 번호를 유지함으로써 형성될 수 있다.

[0154] 다른 한편, replacementAllowed = '거짓'인 경우, 대안적 리소스 URI를 발생시키고 이를 DASH 클라이언트에 제공하는 이러한 교체 방법은 허용되지 않을 수 있다. 대안적 표현이 요청되고 전달되게 하는 결과적인 기술은, 구현 종속적일 수 있다(예를 들어, MBMS 클라이언트는, baseURL 값에 의해 시그널링된 대안적 표현과 동반된 4xx 에러 코드를 리턴하고, 대안적 요청을 포뮬레이팅하도록 DASH 클라이언트에 의존할 수 있음). HTTP '303' 리디렉션에 기초하여 MBMS 클라이언트와 DASH 클라이언트 사이의 상호작용들을 도시하는 예시 호-흐름이 도 15 및 16과 관련하여 아래에서 설명된다.

[0155] 유사하게, 0 또는 그 초과의 유니캐스트 표현들 각각은, mediaPresentationDescription2.unicast 엘리먼트의 고유 baseURL 속성에 의해 USD에서 식별될 수 있다. 앞서 설명된 바와 같이, 유니캐스트 baseURL에 대한 요청 URI의 동일한 부분의 매칭 패턴은, 이러한 표현이 유니캐스트 전달을 통해 이용가능함을 의미한다. 동일한 표현은, 전송 모드들 둘 다를 통해, 전송 모드들 중 단지 하나만을 통해, 또는 전송 모드들 어느 것도 통하지 않고 이용가능하다는 점이 주목된다.

[0156] 이와 달리, sessionDescription 엘리먼트를 통해, 각각의 브로드캐스트 표현은, 해당 표현을 반송하는 FLUTE 세션과 관련되는 SDP 도큐먼트 또는 세션 디스크립션 프래그먼트에 링크될 수 있다. 이외에도, serviceArea 엘리먼트― 존재하는 경우―는, MBMS 서비스 영역(들)을 나타낼 수 있고, 이 MBMS 서비스 영역(들)을 통해 브로드캐스트 표현(들)이 이용가능하다.

[0157] 도 15는 MBMS를 통해 DASH를 지원하기 위한 아키텍처를 예시하는 개념도이다. 도 15의 예는 유니캐스트 폴백(unicast fallback)을 이용하여 MBMS 베어러를 통한 DASH 콘텐츠 전달을 위한 단-대-단 네트워크 아키텍처를 나타낸다. FLUTE-기반 다운로드 전달은, BM-SC와 MBMS 클라이언트 간의 TS 26.346-정의 인터페이스를 나타낸다. DASH 클라이언트와 MBMS 클라이언트(여기서, MBMS 수신기, 디바이스-기반 HTTP 서버, 정책, 리디렉션 및 프록시 기능들을 포함하는 합성 엔티티일 것으로 가정됨) 간에 가정된 인터페이스는 HTTP/1.1이다.

[0158] 도 16은 브로드캐스트 및 유니캐스트 전송을 통한 DASH 콘텐츠 전달을 위한 도 15의 네트워크 아키텍처와 연관된 호-흐름을 예시하는 흐름도이다. 도 16과 관련하여 설명되는 기술들은, DASH 전송 정보를 반송하기 위한 도 14a 및 14b에 도시된 USD 확장에 기초한다. 도 15의 네트워크 아키텍처에 대응하는 것으로 설명되지만, 도 16의 기술들은 다른 디바이스들, 예를 들어, 도 1, 2a, 2b, 6, 7, 8, 및/또는 17의 아키텍처들의 디바이스들에 의해 수행될 수 있다는 것을 이해해야 한다. 도 16의 예에서, USD는, mediaPresentationDescription2.broadcast 및 mediaPresentationDescription2.unicast 하의 baseURL 속성의 값들을 포함하는 표 3에서 도시된 정보를 포함한다고 가정되고, USD의 replacementAllowed 속성의 값은 "참"이라고 가정된다.

표 3

[0159] 더욱이, 이 예에서, MPD는 다음의 콘텐츠를 포함한다고 가정된다:

[0160] 이러한 예시적 MPD 파라미터 값들을 가정하면, 기간 3의 표현 512에 대한 세그먼트 번호 99를 요청하려고 시도하는 DASH 클라이언트는 다음의 요청 URI: http://example.com/per-3/rep-512/seg-99.3gp를 이슈할 수 있다. 도 16의 호 흐름은 2개의 상이한 상황들: 1) UE가 MBMS 커버리지에 로케이팅되고, 브로드캐스트 전달을 통해 이용가능한, 기간 3의 표현 512의 세그먼트들을 요청하는 것, 및 이후, 2) UE가 MBMS 커버리지 밖으로 이동하고, 동일한 표현(즉, 표현 512)을 계속 요청하는 것 ―표현 512는 유니캐스트 전달을 통해서는 이용가능하지 않지만, 표현 256 및 표현 128은 유니캐스트를 통해 이용가능함― 에 대한 DASH 콘텐츠 전달을 설명한다.

[0161] 다시 말해, 본 개시는 전송 다이버시티의 지원에서의 DASH 전송의 USD-기반 시그널링의 이용을 위한 특정 기술들을 설명한다. 이는, Qualcomm Inc.로부터의 Tdoc S4-130051, "Rationale for USD Indication of DASH Delivery Mode and Illustrative Implementation"에서 설명된 이전의 제안을 능가하는 하나 또는 그 초과의 개선들을 제공할 수 있다. 예를 들어, 이 방법에서 레이어링 위반이 전체적으로 회피될 수 있는데, 그 이유는 MBMS 클라이언트가 MPD 정보를 이해하거나 프로세싱하지 않아도 되기 때문이다. 대신에, MBMS 클라이언트는, 요청된 세그먼트들이 브로드캐스트 및/또는 유니캐스트를 통해 전달되도록 요청되는지, 그리고 그 요청이 그 상태 그대로 충족될 수 있는지, 또는 다른 전송 모드를 사용하여, 이용가능한 동일한 또는 대안적 표현으로 리디렉팅될 필요성들을 결정하기 위해, DASH 클라이언트에 의해 요청된 세그먼트들의 URI들에 대한 알려진 전송 시맨틱의 데이터 패턴 매칭을 수행할 수 있다.

[0162] 이러한 결정은 요인들, 이를 테면, UE가 MBMS 커버리지 내부에 로케이팅되는지 MBMS 커버리지 외부에 로케이팅되는지, 서비스 제공자 정책, 만약 있다면, 전송 모드에 의한 표현들의 액세스가능성(accessibility)을 지배하는 것에 기초할 수 있고, 그리고 가능하게는 다른 조건들 또는 룰들에 의존할 수 있다. DASH 클라이언트와 MBMS 클라이언트 간의 HTTP 프로토콜 인터페이스의 사용을 특징으로 하는 단-대-단 콘텐츠 전달을 예시하기 위해, 유니캐스트 폴백을 이용한 MBMS를 통한 DASH 콘텐츠 전달에 대한 예시 네트워크 아키텍처 및 호 흐름도가 제공되었다. 프로토콜 레이어링에 대한 고수(adherence)는, DASH-인-MBMS(DASH-in-MBMS) 서비스들의 지원에서 UE 구현의 확장성 및 단순성에서의 아키텍처적인 이점들을 제공할 것이다.

[0163] 대안적 리소스(표현)에 대한 DASH 클라이언트 액세스를 제한하기 위해 MBMS 클라이언트에 의한 3xx 상태 코드를 통한 HTTP 리디렉트의 사용은, "참" 값을 갖는 mediaPresentationDescription2의 replacementAllowed 속성에 입각한다. 이러한 경우, 대안적 표현의 전송 모드와 상관없이, MBMS 클라이언트가'303 See Other' 리디렉션을 통해 대안적 리소스 URI(들)를 DASH 클라이언트에 제공하도록 허용하는 방식으로 DASH 콘텐츠 및 MPD가 구성되었다고 가정된다. 구체적으로, 앞서 설명된 바와 같이, 세그먼트 URL의 관심 있는 부분을 대안적 표현에 대응하는 USD의 baseURL로 교체하는 한편, 원래의 요청의 세그먼트 번호를 유지함으로써 각각의 대안적 URI가 형성된다. replacementAllowed의 값 = '거짓'인 경우, 대안적 리소스 URI를 발생시키고 이를 DASH 클라이언트에 제공하는 이러한 교체 방법은 허용되지 않는다.

[0164] 대안적 표현이 요청 및 전달되게 하기 위한 결과적인 기술들은 구현 종속적일 수도 있다. 예를 들어, MBMS 클라이언트는, HTTP 응답의 엔티티 바디 내의 baseURL 값에 의해 시그널링되는 대안적 표현이 첨부된 또는 그러한 대안적 표현 없이 4xx 에러 코드를 리턴할 수 있고, 대안적 요청을 형성하는 DASH 클라이언트에 의존할 수 있다. 여기서, 대안적 표현이 응답에서 이용가능한지를 식별하는 baseURL의 존재는, 후속하는 해당 표현을 직접 요청할 지능을 갖춘 DASH 클라이언트에게 힌트로서 사용될 수도 있다. 대안적으로, baseURL "힌트"는 4xx 응답으로 제공되지 않을 수도 있고, 또는 DASH 클라이언트는, MBMS 클라이언트 관점으로부터의 허용된 표현에 대응하거나 대응하지 않을 수도 있는 다른 표현에 대한 새로운 요청을 생성하는데 있어 그러한 힌트를 이용할 지능이 부족할 수도 있다.

[0165] 도 17은 MBMS를 통해 DASH를 지원하기 위한 다른 예시적인 아키텍처를 예시하는 개념도이다. BM-SC와 eMBMS 클라이언트 간의 인터페이스, 및 eMBMS 클라이언트와 DASH 클라이언트 간의 인터페이스를 적절한 표준으로 특정하는 것이 중요할 수도 있다. 예를 들어, 표준은, BM-SC와 eMBMS 클라이언트 간의 인터페이스가 TS 26.346을 준수할 것임을 특정할 수도 있다. 또한, 표준은, DASH 클라이언트 및 eMBMS 클라이언트가 상이한 제공자들로부터의 것이면, eMBMS 클라이언트와 DASH 클라이언트 간의 인터페이스가 TS 26.247을 따를 것임을 특정할 수도 있다. 도 16의 예와 대조적으로, 도 17은, DASH 클라이언트와 eMBMS 클라이언트 간의 인터페이스가 (예를 들어, HTTP/1.1일 수도 있는) TS 26.247을 따를 수도 있는 예를 예시한다. 도 17은 MBMS를 통한 DASH가 유니캐스트를 통해 DASH로 폴 백(fall back)되게 하는 고레벨 아키텍처를 예시한다.

[0166] 도 18-23은, 브로드캐스트 및 유니캐스트 전송을 통한 DASH 콘텐츠 전달을 위한 도 17의 네트워크 아키텍처와 연관된 다양한 예시적인 호-흐름들을 예시하는 흐름도들이다. 도 17의 네트워크 아키텍처에 대응하는 것으로 설명되었지만, 도 18-23의 기술들은 다른 디바이스들, 예컨대, 도 1, 2a, 2b, 6, 7, 8, 및/또는 15의 아키텍처들의 디바이스들에 의해 수행될 수도 있음이 이해되어야 한다.

[0167] 도 18의 예와 관련하여, USD 시그널링은 eMBMS 클라이언트에 대해 아래의 표 4에 나타낸 데이터를 포함할 수도 있다.

표 4

[0168] 이러한 예에서의 MPD는 다음의 데이터를 특정할 수도 있으며, 여기서, BaseURL들은 세그먼트들에 액세스하기 위한 URL들의 기본 부분들에 대응한다.

BaseURL1=http://www.cnn.com/512/, RepresentationId = "512";

Template=seg$Number$.3gp,

BaseURL2=http://www.cnn.com/256/, RepresentationId= "256";

Template=seg$Number$.3gp,

BaseURL3=http://www.cnn.com/128/, RepresentationId= "128";

Template=seg$Number$.3gp.

[0169] 도 18의 예에서, eMBMS 클라이언트는 HTTP 프록시 기능들을 갖지 않고 HTTP 리디렉터 기능들만을 갖는 것으로 가정된다.

[0170] 도 19의 예와 관련하여, USD 시그널링은 eMBMS 클라이언트에 대해 아래의 표 5에 나타낸 데이터를 포함할 수도 있다.

표 5

[0171] 이러한 예에서의 MPD는 다음의 데이터를 특정할 수도 있으며, 여기서, BaseURL들은 세그먼트들에 액세스하기 위한 URL들의 베이스 부분들에 대응한다.

BaseURL1=http://www.cnn.com/512/, RepresentationId = "512";

Template=seg$Number$.3gp,

BaseURL2=http://www.cnn.com/256/, RepresentationId= "256";

Template=seg$Number$.3gp,

BaseURL3=http://www.cnn.com/128/, RepresentationId= "128";

Template=seg$Number$.3gp.

[0172] 도 19의 예에서, eMBMS 클라이언트는 HTTP 프록시 및 HTTP 리디렉터 기능 둘 모두를 갖는 것으로 가정된다.

[0173] 도 20의 예에 관하여, USD 시그널링은 eMBMS 클라이언트에 대해 아래의 표 6에 나타낸 데이터를 포함할 수도 있다.

표 6

[0174] 이러한 예에서의 MPD는 다음의 데이터를 특정할 수도 있으며, 여기서, BaseURL들은 세그먼트들에 액세스하기 위한 URL들의 베이스 부분들에 대응한다.

BaseURL1.1=http://www.cnn.com/512/,

BaseURL1.2=http://localhost/512/,RepresentationId = "512";

Template=seg$Number$.3gp,

BaseURL2=http://www.cnn.com/256/, RepresentationId= "256";

Template=seg$Number$.3gp,

BaseURL3=http://www.cnn.com/128/, RepresentationId= "128";

Template=seg$Number$.3gp.

[0175] 도 20의 예에서, eMBMS 클라이언트는 HTTP 프록시 기능을 갖지 않고 HTTP 리디렉터 기능만을 갖는 것으로 가정된다.

[0176] 도 21의 예에 관하여, USD 시그널링은 eMBMS 클라이언트에 대해 아래의 표 7에 나타낸 데이터를 포함할 수도 있다.

표 7

[0177] 이러한 예에서의 MPD는 다음의 데이터를 특정할 수도 있으며, 여기서, BaseURL들은 세그먼트들에 액세스하기 위한 URL들의 베이스 부분들에 대응한다.

BaseURL1=http://www.cnn.com/;

RepresentationId = "512"; Template=$RepresentationId$/seg$Number$.3gp,

RepresentationId= "256"; Template=$Representagtion$/seg$Number$.3gp,

RepresentationId= "128"; Template=$Representagtion$/seg$Number$.3gp.

[0178] 도 21의 예에서, eMBMS 클라이언트는 HTTP 프록시 기능을 갖지 않고 HTTP 리디렉터 기능만을 갖는 것으로 가정된다.

[0179] 도 22의 예에 관하여, USD 시그널링은 eMBMS 클라이언트에 대해 아래의 표 8에 나타낸 데이터를 포함할 수도 있다.

표 8

[0180] 이러한 예에서의 MPD는 다음의 데이터를 특정할 수도 있으며, 여기서, BaseURL들은 세그먼트들에 액세스하기 위한 URL들의 베이스 부분들에 대응한다.

BaseURL1=http://localhost/512/, RepresentationId = "512";

Template=seg$Number$.3gp,

BaseURL2=http://www.cnn.com/256/, RepresentationId= "256";

Template=seg$Number$.3gp,

BaseURL3=http://www.cnn.com/128/, RepresentationId=""128";

Template=seg$Number$.3gp.

[0181] 도 22의 예에서, eMBMS 클라이언트는 HTTP 프록시 기능을 갖지 않고 HTTP 리디렉터 기능만을 갖는 것으로 가정된다.

[0182] 도 23의 예에 관하여, USD 시그널링은 eMBMS 클라이언트에 대해 아래의 표 9에 나타낸 데이터를 포함할 수도 있다.

표 9

[0183] 이러한 예에서의 MPD는 다음의 데이터를 특정할 수도 있으며, 여기서, BaseURL들은 세그먼트들에 액세스하기 위한 URL들의 베이스 부분들에 대응한다.

BaseURL1=http://www.cnn.com/1024/, RepresentationId = "1024";

Template=seg$Number$.3gp,

BaseURL2=http://www.cnn.com/512/, RepresentationId = "512";

Template=seg$Number$.3gp,

BaseURL3=http://www.cnn.com/256/, RepresentationId= "256";

Template=seg$Number$.3gp,

BaseURL4=http://www.cnn.com/128/, RepresentationId=""128";

Template=seg$Number$.3gp.

[0184] 도 23의 예시에서는, eMBMS 클라이언트가 HTTP 프록시 기능을 갖지 않고, HTTP 리디렉터 기능만을 갖는 것으로 가정된다.

[0185] 도 24는 본 개시의 기술들에 따른, 시간-시프트 버퍼(TSB) 깊이에 관련된 데이터를 시그널링하기 위한 예시적 방법을 도시하는 흐름도이다. 예시의 목적들을 위해, 도 25의 방법은 도 10의 컴포넌트들, 예컨대 MSDC(1010) 및 TSB(1212)에 대하여 설명된다. 그러나, 시간-시프트 버퍼를 활용하기 위한 기술들이 본원에서 설명된 다양한 시스템들, 예컨대 도 1, 도 7, 도 8, 도 9, 도 12, 도 13, 및/또는 도 17 중 임의의 도면의 시스템들 중 임의의 시스템에 통합될 수 있음이 이해되어야 한다.

[0186] 처음에, MSDC(1010)는 세션 디스크립션 프로토콜(SDP) 메시지를 수신할 수 있다(2400). SDP 메시지는 시간-시프트 버퍼(TSB) 깊이를 정의하는 속성을 포함할 수 있다. 따라서, MSDC(1010)는 SDP 메시지에서 속성(또한, TSB 깊이 속성으로 지칭됨)에 대한 값을 결정할 수 있다(2402). TSB 깊이 속성의 값은, 예컨대 TSB에 저장될 미디어 데이터에 대한 플레이백의 초(second)들과 관련하여, TSB의 깊이를 정의할 수 있다. 예컨대, 속성의 값은, TSB에 저장될 수 있는 최대 플레이백 시간을 초들로 정의할 수 있다.

[0187] 그러므로, MSDC(1010)는 시그널링된 깊이로부터 TSB를 형성하기 위해 할당될 양의 메모리를 결정할 수 있다(2404). 예컨대, TSB의 깊이가 미디어 데이터에 대한 플레이백의 초들과 관련하여 시그널링됨을 가정하면, 그리고 비디오 데이터에 대한 프레임 레이트가 시그널링됨을 가정하면, 프레임 레이트(초당 프레임들로 표현됨)와 저장될 미디어 데이터의 초(second)들의 수의 곱으로서, MSDC는 TSB에 저장될 비디오 프레임들의 수를 결정할 수 있다. 그 다음, MSDC(1010)는 프레임당 평균 비트레이트와 프레임들의 수의 곱에 기초하여 TSB에 대한 메모리의 양을 결정할 수 있다. MSDC(1010)는 오디오 데이터, 타임 텍스트 데이터(timed text data) 등에 대한 메모리 크기를 결정하기 위해 유사한 개념들을 사용할 수 있다.

[0188] 그 다음, MSDC(1010)는 TSB를 형성하기 위해, 결정된 양의 메모리를 할당할 수 있다(2406). 따라서, MSDC(1010)가 미디어 데이터를 수신할 때, MSDC(1010)는 수신된 미디어 데이터를 TSB에 저장할 수 있다(2408). 플레이백 애플리케이션은, 시간 시프트 애플리케이션에 대해, 예컨대 나중 시청을 위해 또는 트릭 모드, 예컨대 빨리감기 또는 되감기를 수행하기 위해, 이러한 버퍼링된 미디어 데이터를 사용할 수 있다. 물론, 버퍼링된 데이터는 실질적으로 실시간 플레이백을 위해 또한 사용될 수 있다.

[0189] 이런 식으로, 도 24의 방법은, 시간-시프트 버퍼(TSB) 깊이를 정의하는 속성을 포함하는 세션 디스크립션 프로토콜(SDP) 메시지를 수신하는 단계, 속성의 값에 기초하여 TSB에 대한 메모리의 양을 결정하는 단계, 결정된 양의 메모리를 TSB에 할당하는 단계, 및 SDP 메시지와 연관된 미디어 데이터의 적어도 일부를 TSB에 저장하는 단계를 포함하는 방법의 예시를 표현한다.

[0190] 당업자들은 정보 및 신호들이 다양한 상이한 기술들 및 기법들 중 임의의 것을 사용하여 표현될 수 있음을 이해할 것이다. 예를 들어, 상기 설명 전반에 지칭될 수 있는 데이터, 명령들, 커맨드들, 정보, 신호들, 비트들, 심볼들, 및 칩들이 전압들, 전류들, 전자기파들, 자기 필드들 또는 입자들, 광학 필드들 또는 입자들, 또는 이들의 임의의 결합에 의해 표현될 수 있다.

[0191] 해당 기술분야에서 통상의 지식을 가진 자들은 추가로, 본원의 개시와 관련하여 설명된 다양한 예시적인 로직 블록들, 모듈들, 회로들 및 알고리즘 단계들이 전자 하드웨어, 컴퓨터 소프트웨어, 또는 이 둘의 결합으로 구현될 수 있다고 인식할 것이다. 하드웨어와 소프트웨어의 이러한 상호 호환성을 명확히 설명하기 위해, 각종 예시적인 컴포넌트들, 블록들, 모듈들, 회로들 및 단계들이 일반적으로 이들의 기능과 관련하여 위에서 설명되었다. 이러한 기능이 하드웨어로 구현되는지 아니면 소프트웨어로 구현되는지는 전체 시스템에 부과된 설계 제약들 및 특정 애플리케이션에 좌우된다. 해당 기술분야에서 통상의 지식을 가진 자들은 설명된 기능을 특정 애플리케이션마다 다양한 방식들로 구현할 수 있지만, 이러한 구현 결정들이 본 개시의 범위를 벗어나게 하는 것으로 해석되지는 않아야 한다.

[0192] 하나 또는 그 초과의 예들에서, 설명된 기능들은 하드웨어, 소프트웨어, 펌웨어 또는 이들의 임의의 결합들로 구현될 수 있다. 소프트웨어로 구현된다면, 기능들은, 컴퓨터 판독 가능 매체 상에 저장되거나, 컴퓨터 판독 가능 매체 상에서 하나 또는 그보다 많은 명령들 또는 코드로서 송신되며, 하드웨어-기반 프로세싱 유닛에 의해 실행될 수 있다. 컴퓨터 판독 가능 매체는, 예를 들어 통신 프로토콜에 따라, 한 장소에서 다른 장소로 컴퓨터 프로그램의 전달을 용이하게 하는 임의의 매체를 포함하는 통신 매체, 또는 데이터 저장 매체와 같은 유형의 매체에 대응하는 컴퓨터 판독 가능 저장 매체를 포함할 수 있다. 이런 식으로, 컴퓨터 판독 가능 매체는 일반적으로, (1) 비-일시적인 유형의 컴퓨터 판독 가능 저장 매체, 또는 (2) 신호 또는 반송파와 같은 통신 매체에 해당할 수 있다. 데이터 저장 매체는, 본 개시에 설명된 기술들의 구현을 위한 명령들, 코드 및/또는 데이터 구조들을 리트리브하기 위해 하나 또는 그 초과의 컴퓨터들 또는 하나 또는 그 초과의 프로세서들에 의해 액세스될 수 있는 임의의 이용가능한 매체일 수 있다. 컴퓨터 프로그램 물건은 컴퓨터 판독 가능 매체를 포함할 수 있다.

[0193] 한정이 아닌 예시로, 이러한 컴퓨터 판독 가능 매체는 RAM, ROM, EEPROM, CD-ROM이나 다른 광 디스크 저장소, 자기 디스크 저장소 또는 다른 자기 저장 디바이스들, 플래시 메모리 또는 명령들이나 데이터 구조들의 형태로 원하는 프로그램 코드를 저장하는데 사용될 수 있으며 컴퓨터에 의해 액세스될 수 있는 임의의 다른 매체를 포함할 수 있다. 또한, 임의의 접속이 컴퓨터-판독 가능 매체로 적절히 지칭된다. 예를 들어, 명령들이 동축 케이블, 광섬유 케이블, 꼬임 쌍선, 디지털 가입자 회선(DSL: digital subscriber line), 또는 적외선, 라디오 및 마이크로파와 같은 무선 기술들을 이용하여 웹사이트, 서버 또는 다른 원격 소스로부터 송신된다면, 동축 케이블, 광섬유 케이블, 꼬임 쌍선, DSL, 또는 적외선, 라디오 및 마이크로파와 같은 무선 기술들이 매체의 정의에 포함된다. 그러나, 컴퓨터 판독 가능 매체 및 데이터 저장 매체가 접속들, 반송파들, 신호들 또는 다른 일시적 매체를 포함하는 것이 아니라, 대신 비-일시적인 유형의 저장 매체에 관련된다는 점이 이해되어야 한다. 본원에서 사용되는 디스크(disk 및 disc)는 콤팩트 디스크(CD: compact disc), 레이저 디스크(laser disc), 광 디스크(optical disc), 디지털 다기능 디스크(DVD: digital versatile disc), 플로피 디스크(floppy disk) 및 블루레이 디스크(Blu-ray disc)를 포함하며, 여기서 디스크(disk)들은 보통 데이터를 자기적으로 재생하는 한편, 디스크(disc)들은 데이터를 레이저들에 의해 광학적으로 재생한다. 상기한 것들의 결합들이 또한 컴퓨터 판독 가능 매체의 범위 내에 포함되어야 한다.

[0194] 명령들은 하나 또는 그 초과의 프로세서들, 예컨대 하나 또는 그 초과의 DSP(digital signal processor), 범용성 마이크로프로세서들, ASIC(application specific integrated circuit)들, FPGA(field programmable logic array)들, 또는 다른 등가의 집적 회로 또는 이산 논리 회로에 의해 실행될 수 있다. 따라서, 본원에서 사용되는 "프로세서"라는 용어는 앞서 말한 구조 또는 본원에서 설명되는 기술들의 구현에 적합한 임의의 다른 구조 중 임의의 것을 지칭할 수 있다. 또한, 일부 양상들에서, 본원에 설명된 기능은, 인코딩 및 디코딩을 위해 구성된 전용 하드웨어 및/또는 소프트웨어 모듈들 내에 제공되거나, 결합된 코덱에 통합될 수 있다. 또한, 기술들은 하나 또는 그 초과의 회로들 또는 논리 엘리먼트들에서 완벽히 구현될 수 있다.

[0195] 본 개시의 기술들은, 무선 핸드셋, 집적회로(IC) 또는 한 세트의 IC들(예를 들명, 칩 셋)을 비롯한, 다양한 디바이스들 또는 장치들에서 구현될 수 있다. 개시된 기술들을 수행하도록 구성된 디바이스들의 기능적 양상들을 강조하기 위해 본 개시에서 다양한 컴포넌트들, 모듈들, 또는 유닛들이 설명되나, 이들이 반드시 상이한 하드웨어 유닛들에 의한 구현을 요구하는 것은 아니다. 오히려, 앞서 설명된 것처럼, 다양한 유닛들은 코덱 하드웨어 유닛에 결합될 수도 있고, 또는 적절한 소프트웨어 및/또는 펌웨어와 함께, 앞서 설명된 하나 또는 그 초과의 프로세서들을 비롯하여, 연동(interoperative) 하드웨어 유닛들의 콜렉션(collection)에 의해 제공될 수도 있다.

[0196] 첨부된 도면들과 함께, 앞서 설명된 구체적인 내용은 다양한 구성들의 설명으로 의도되며 본원에 설명된 개념들이 실행될 수 있는 유일한 구성들만을 표현하도록 의도되지 않는다. 구체적인 내용은 다양한 개념들의 전반적 이해를 제공하기 위해 특정 상세사항들을 포함한다. 그러나, 당업자들에게는, 이러한 개념들이 이들 특정한 상세사항들없이 실행될 수 있다는 점이 명백할 것이다. 일부 예시들에서, 잘 알려진 구조들 및 컴포넌트들은 이러한 개념들이 모호해지게 하는 것을 방지하기 위해 블록도 형태로 도시된다.

[0197] 다양한 예들이 설명되었다. 이러한 예들 및 다른 예들은 하기 청구항들의 범주내에 속한다.

Claims (30)

1. 미디어 데이터를 리트리브(retrieve)하는 방법으로서,
   프록시 유닛(proxy unit)(818, 1218)에 의해:
   상기 미디어 데이터를 리트리브하기 위한 서비스에 기초하여, 미디어 데이터에 대한 식별자를 리소스 로케이션(resource location)에 맵핑(mapping)하는 맵핑 정보를 획득하는 단계 ―상기 서비스는 상기 미디어 데이터를 전송하기 위한 복수의 전송 타입들 중 적어도 하나를 정의함―;
   애플리케이션 서비스 클라이언트(802, 1202)로부터 상기 미디어 데이터에 대한 요청을 수신하는 단계;
   상기 서비스가 이용가능한지를 결정하는 단계; 및
   상기 서비스가 이용가능한 경우, 상기 애플리케이션 서비스 클라이언트로 하여금, 상기 맵핑 정보에 기초하여, 상기 리소스 로케이션으로부터 상기 서비스를 이용하여 상기 미디어 데이터를 수신하는 유닛(808, 1208)으로부터 상기 미디어 데이터를 수신하게 하는 단계
   를 포함하는, 미디어 데이터를 리트리브하는 방법.
2. 제 1 항에 있어서,
   상기 리소스 로케이션은 네트워크 로케이션(806, 1206)을 포함하며,
   상기 방법은,
   상기 요청에서 특정된 미디어 데이터가 상기 맵핑 정보에서의 미디어 데이터와 매치(match)하는지를 결정하는 단계; 및
   상기 요청에서 특정된 미디어 데이터가 상기 맵핑 정보에서의 미디어 데이터와 매치하는 경우, 상기 애플리케이션 서비스 클라이언트로 하여금 상기 네트워크 로케이션으로부터 상기 미디어 데이터를 리트리브하게 하기 위해, 상기 미디어 데이터에 대한 식별자가 상기 맵핑 정보에 맵핑되는 상기 네트워크 로케이션을 특정하는 리디렉트 메시지(redirect message)를 상기 애플리케이션 서비스 클라이언트에 전송하는 단계를 더 포함하는, 미디어 데이터를 리트리브하는 방법.
3. 제 2 항에 있어서,
   상기 요청에서 특정된 미디어 데이터가 상기 맵핑 정보에서의 미디어 데이터와 매치하지 않는 경우, 상기 애플리케이션 서비스 클라이언트로 하여금 디폴트 리디렉션(re-direction) 네트워크 로케이션으로부터 상기 미디어 데이터를 리트리브하게 하기 위해, 상기 디폴트 리디렉션 네트워크 로케이션을 특정하는 리디렉트 메시지를 상기 애플리케이션 서비스 클라이언트에 전송하는 단계를 더 포함하는, 미디어 데이터를 리트리브하는 방법.
4. 제 2 항에 있어서,
   상기 요청에서 특정된 미디어 데이터가 상기 맵핑 정보에서의 미디어 데이터와 매치하지 않는 경우, 상기 요청의 카피(copy)를 상기 애플리케이션 서비스 클라이언트에 다시(back) 전송하는 단계를 더 포함하는, 미디어 데이터를 리트리브하는 방법.
5. 제 2 항에 있어서,
   맵핑 테이블에 상기 맵핑 정보를 저장하는 단계를 더 포함하며,
   상기 요청에서 특정된 미디어 데이터가 상기 맵핑 정보에서의 미디어 데이터와 매치하는지를 결정하는 단계는, 미디어 디바이스에 대한 식별자가 상기 맵핑 테이블의 엔트리(entry)에 대응하는지를 결정하는 단계를 포함하는, 미디어 데이터를 리트리브하는 방법.
6. 제 2 항에 있어서,
   상기 맵핑 정보는 URI(uniform resource identifier) 프리픽스들로 표현되는 맵핑 기준들을 포함하고,
   상기 요청에서 특정된 미디어 데이터가 상기 맵핑 정보에서의 미디어 데이터와 매치하는지를 결정하는 단계는, 상기 요청에서 표시된 미디어 데이터의 URI의 적어도 일부와 매치하는 상기 맵핑 정보의 URI 프리픽스를 결정하는 단계를 포함하는, 미디어 데이터를 리트리브하는 방법.
7. 제 6 항에 있어서,
   상기 요청에서 표시된 미디어 데이터의 URI의 적어도 일부와 매치하는 상기 맵핑 정보의 URI 프리픽스를 결정하는 단계는, 상기 요청에서 표시된 미디어 데이터의 URI의 적어도 일부와 매치하는 상기 맵핑 정보의 가장 긴(longest) URI 프리픽스를 결정하는 단계를 포함하는, 미디어 데이터를 리트리브하는 방법.
8. 제 6 항에 있어서,
   상기 맵핑 기준들에 의해 표현되는 상기 URI 프리픽스들은 미디어 데이터를 전송하기 위한 전송 타입들을 정의하는 개별 서비스들에 대응하며,
   상기 URI 프리픽스들 중 제 1 URI 프릭픽스는 브로드캐스트 서비스를 정의하며, 상기 URI 프리픽스들 중 제 2 URI 프릭픽스는 유니캐스트 서비스를 정의하는, 미디어 데이터를 리트리브하는 방법.
9. 제 2 항에 있어서,
   상기 맵핑 정보는 각각의 잠재적 매치에 대한 우선순위 값들을 포함하고,
   상기 요청에서 특정된 미디어 데이터가 상기 맵핑 정보에서의 미디어 데이터와 매치하는지를 결정하는 단계는, 가장 높은 우선순위 값을 갖는 매치를 선택하는 단계를 포함하는, 미디어 데이터를 리트리브하는 방법.
10. 제 2 항에 있어서,
    상기 맵핑 정보는 각각의 잠재적 매치에 대한 우선순위 값을 포함하고,
    상기 요청에서 특정된 미디어 데이터가 상기 맵핑 정보에서의 미디어 데이터와 매치하는지를 결정하는 단계는, 가장 낮은 우선순위 값을 갖는 매치를 선택하는 단계를 포함하는, 미디어 데이터를 리트리브하는 방법.
11. 제 2 항에 있어서,
    상기 맵핑 정보는 규칙적 표현(regular expression)들로 표현되는 맵핑 기준들을 포함하며,
    상기 요청에서 특정된 미디어 데이터가 상기 맵핑 정보에서의 미디어 데이터와 매치하는지를 결정하는 단계는, 상기 요청에 표시된 상기 미디어 데이터에 대한 식별자와 직접 매치하는 가장 큰 수의 캐릭터들(characters)에 매치하는 규칙적 표현을 선택하는 단계를 포함하는, 미디어 데이터를 리트리브하는 방법.
12. 제 2 항에 있어서,
    상기 맵핑 정보는 규칙적 표현들로 표현되는 맵핑 기준들을 포함하며,
    상기 맵핑 정보는 각각의 잠재적 매치에 대한 우선순위 값들을 포함하며,
    상기 요청에서 특정된 미디어 데이터가 상기 맵핑 정보에서의 미디어 데이터와 매치하는지를 결정하는 단계는, 가장 높은 우선순위 값을 갖는 매치를 선택하는 단계를 포함하는, 미디어 데이터를 리트리브하는 방법.
13. 제 2 항에 있어서,
    상기 맵핑 정보는 규칙적 표현들로 표현되는 맵핑 기준들을 포함하며,
    상기 맵핑 정보는 각각의 잠재적 매치에 대한 우선순위 값들을 포함하며,
    상기 요청에서 특정된 미디어 데이터가 상기 맵핑 정보에서의 미디어 데이터와 매치하는지를 결정하는 단계는, 가장 낮은 우선순위 값을 갖는 매치를 선택하는 단계를 포함하는, 미디어 데이터를 리트리브하는 방법.
14. 제 1 항에 있어서,
    상기 서비스가 이용가능한지를 결정하는 단계는, 상기 프록시 유닛이 서비스 커버리지 구역내에 있는지를 결정하는 단계를 포함하는, 미디어 데이터를 리트리브하는 방법.
15. 제 1 항에 있어서,
    상기 요청은 DASH(dynamic adaptive streaming over HTTP) 요청을 따르며,
    상기 방법은,
    상기 프록시 유닛에 의해:
    상기 DASH 요청을 수신하는 단계 ―상기 DASH 요청은 상기 프록시 유닛의 네트워크 어드레스를 특정함―;
    상기 DASH 요청에 응답하여, 상기 요청에서 특정된 미디어 데이터를 리트리브하고, 상기 미디어 데이터를 상기 애플리케이션 서비스 클라이언트에 제공하는 단계
    를 더 포함하는, 미디어 데이터를 리트리브하는 방법.
16. 미디어 데이터를 리트리브하기 위한 디바이스로서,
    상기 디바이스는 프록시 유닛(818, 1218)을 포함하고,
    상기 프록시 유닛은,
    상기 미디어 데이터를 리트리브하기 위한 서비스에 기초하여, 미디어 데이터에 대한 식별자를 리소스 로케이션에 맵핑하는 맵핑 정보를 획득하기 위한 수단 ―상기 서비스는 상기 미디어 데이터를 전송하기 위한 복수의 전송 타입들 중 적어도 하나를 정의함―;
    애플리케이션 서비스 클라이언트(802, 1202)로부터 상기 미디어 데이터에 대한 요청을 수신하기 위한 수단;
    상기 서비스가 이용가능한지를 결정하기 위한 수단; 및
    상기 서비스가 이용가능한 경우, 상기 애플리케이션 서비스 클라이언트로 하여금, 상기 맵핑 정보에 기초하여, 상기 리소스 로케이션으로부터 상기 서비스를 이용하여 상기 미디어 데이터를 수신하는 유닛(808, 1208)으로부터 상기 미디어 데이터를 수신하게 하도록 야기하기 위한 수단을 포함하는, 미디어 데이터를 리트리브하기 위한 디바이스.
17. 제 16 항에 있어서,
    상기 미디어 데이터를 수신하는 미들웨어 유닛을 더 포함하며,
    상기 미들웨어 유닛은 MBMS(multimedia broadcast multicast services) 미들웨어 유닛 및 eMBMS(evolved MBMS) 미들웨어 유닛 중 하나를 포함하는, 미디어 데이터를 리트리브하기 위한 디바이스.
18. 제 16 항에 있어서,
    상기 디바이스는 프록시 디바이스를 포함하며,
    클라이언트 디바이스는 상기 애플리케이션 서비스 클라이언트를 포함하며,
    상기 프록시 디바이스는 상기 클라이언트 디바이스와 별개(separate)인, 미디어 데이터를 리트리브하기 위한 디바이스.
19. 삭제
20. 삭제
21. 삭제
22. 삭제
23. 삭제
24. 삭제
25. 삭제
26. 삭제
27. 삭제
28. 삭제
29. 삭제
30. 삭제

Images