KR20180014200A

KR20180014200A - 서버로부터 클라이언트로 미디어 콘텐츠를 전달하기 위한 라디오 리소스 관리 개념

Info

Publication number: KR20180014200A
Application number: KR1020187002523A
Authority: KR
Inventors: 토마스 쉬를; 토마스 워스; 토마스 하우슈타인; 야고 산체스
Original assignee: 프라운호퍼 게젤샤프트 쭈르 푀르데룽 데어 안겐반텐 포르슝 에. 베.
Priority date: 2011-10-21
Filing date: 2012-10-22
Publication date: 2018-02-07
Also published as: US12010714B2; CN110049515A; US10945269B2; EP3764687B1; CN110087262A; CN104041111A; KR20180077333A; ES2905831T3; JP2016140101A; JP6533275B2; EP2769578B8; WO2013057315A3; US9775163B2; WO2013057315A9; JP6700458B2; JP2018057028A; KR20140103101A; CN110049515B; EP3764687A1; KR20160055948A

Abstract

서버로부터 클라이언트로 미디어 콘텐츠를 스트리밍하기 위한 기지국의 자원들의 할당에 관한 것이며, 미디어 프리젠테이션 설명들은 미디어 콘텐츠를 위한 상이한 대역폭 요구들을 위해 이용가능하다. 리소스들은, 특히 HTTP를 통한 동적 적응적 스트리밍(DASH)을 위해, 미디어 프리젠테이션 설명에 기초하여 할당된다. 또한, 유니캐스트 또는 멀티캐스트 전송뿐만 아니라 버퍼 콘텐츠가 고려된다.

Description

서버로부터 클라이언트로 미디어 콘텐츠를 전달하기 위한 라디오 리소스 관리 개념{RADIO RESOURCE MANAGEMENT CONCEPT FOR TRANSFERRING MEDIA CONTENT FROM A SERVER TO A CLIENT}

본 발명은, 무선 네트워크들 내의 네트워크 라디오 리소스 관리와 같은 리소스 관리에 관한 것이다.

최근 몇년에서, 인터넷을 통한 멀티미디어 전달은 급속히 증가하여, 네트워크 내에서 주요한 대역폭 소비자가 되고 있다. 이러한 증가와 평행하게, 모바일 네트워크들에서의 상당한 개선들은, 3GPP의 고속 다운링크 패킷 액세스(HSDPA) 및 신생의 롱텀 에볼루션(LTE) 네트워크들과 같은 고속 액세스 네트워크들의 출현을 유도했다.

모바일 네트워크들에서의 개선들로, IP 서비스들은 일상 생활의 유비쿼터스한 현실이도록 기대된다. 최근의 연구들은 멀티미디어 콘텐츠, 특히 비디오 스트리밍의 소비가 계속 증가할 것이라고 기대하며[1], 이는 또한, 모바일 네트워크들에서의 진보들의 결과일 수도 있다. 사실, [2]에서, 모바일 네트워크들에서의 데이터 트래픽의 약 50%가 비디오 데이터라는 것이 리포팅되었으며, 2015년 쯤에는 전세계의 모바일 데이터 트래픽의 2/3이 비디오일 것이라고 기대된다.

HTTP 스트리밍은, 최근 몇년에서 등장했고 마켓에 의해 엄청나게 수용되었던 유망한 멀티미디어 애플리케이션들 중 하나이며, 이는, MPEG[3] 및 3GPP[4], 또는 IIS 평활 스트리밍[5] 및 HTTP 라이브 스트리밍[6]과 같은 특허(proprietary) 솔루션들과 같이, 상이한 표준화 단체(body)들에 의해 수행된 적응적 HTTP 스트리밍에 대한 표준화 활동들에 의해 명백하다.

미디어 스트리밍이 그의 더 낮은 레이턴시로 인해 이전에 RTP/UDP와 연관되었지만, 미디어 전달을 위해 HTTP/TCP 상에서 중계하는 것은, RTP/UDP에 관해서는 통상적인 NAT 및 Firewalls 내의 횡단 문제들이 존재하지 않으므로, 극히 엄격한 지연 제약들이 고려되지 않는 시나리오들에 대해 매우 가치있는 솔루션인 것으로 나타났다.

HTTP를 통한 동적 적응적 스트리밍(DASH)[3]은, HTTP를 통한 멀티미디어 전달을 위한 포맷을 정의하는 신생 MPEG 표준이다. 그것은 기본적으로 2개의 엘리먼트들, 즉 다운로딩될 미디어의 포맷 및 다운로딩될 미디어의 설명으로 이루어진다. 종래의 특허 솔루션들이 유사한 접근법에 기초한다.

미디어 포맷은 기본적으로, 연속적으로 다운로딩되면, 미디어의 연속적인 표현을 허용하는 세그먼트들로 지칭된 비디오의 통상적으로 작은 시간 간격들로 구성된다. 또한, 상이한 비트레이트들의 미디어의 일반적으로 상이한 표현들, 예를 들어, 인코딩들은 사용자-구동된 적응을 허용하는 서버에서 이용가능하며, 여기서, 사용자들은 관측된 네트워크 스루풋에 기초하여 표현들을 선택한다. 후술되는 미디어 프리젠테이션(presentation) 설명(MPD)에서 프리젠테이션된 모든 스위칭 제약들에 따르면, 상이한 시간 간격들 동안의 상이한 표현들의 세그먼트들의 다운로드가 허용되어, 완벽히 플레이가능한 미디어를 발생시킨다.

DASH에서, 포맷의 설명은 MPD에 의해 주어진다. MPD는, 서버에서 이용가능한 데이터 및 특히 세그먼트들을 설명하는 XML 문헌이다. MPD를 사용하여, 클라이언트들은, 그들의 네트워크 스루풋 또는 그들의 요건들에 피트(fit)하는 요청들을 행하는데 필요한 정보를 갖는다.

DASH에서, 클라이언트들은 적응을 수행하는 것을 담당한다. 사용자들의 관심들, 네트워크의 장비 능력들 및 현재 상태에 기초하여, DASH 클라이언트들은, 클라이언트들의 필요성들/능력들에 최상으로 매칭하는 MPD에서 설명된 표현(들)을 선택해야 한다. DASH 아키텍처의 일 예는 도 1에 도시되어 있다.

도 1로부터 가시적인 바와 같이, DASH 환경의 참가 엔티티들은, 몇몇 DASH 콘텐츠 준비 스테이지(14)로부터 각각의 DASH 클라이언트들(12)에 분배될 자신의 미디어 콘텐츠를 수신하는 DASH 서버(10), DASH 클라이언트(12) 그 자체, 및 DASH 서버(10)와 DASH 클라이언트(12)를 상호접속시키는 네트워크이며, 네트워크(16)는 "HTTP 캐시"로서 표시된다. 도 3에 도시된 바와 같이, DASH 클라이언트는, DASH 클라이언트가 미디어 프리젠테이션 설명 MPD(18)를 DASH 서버(10)로부터 수신하는 경우, 텔레비전 디바이스 또는 컴퓨터 등과 같은 적절한 사용자 단말 상에서 구동할 수도 있으며, 그 MPD(18)는 차례로, DASH 서버(10)에서 이용가능한 미디어 콘텐츠의 다양한 버전들을 설명하기 위하여, DASH 콘텐츠 준비 스테이지(14)에 의해 미디어 콘텐츠의 버전과 함께 생성된다.

도 2는, DASH 표준[ISO/IEC 23009-1]으로부터 엔티티들을 사용하는 LTE 네트워크들 내의 DASH의 최신 배치 아키텍처를 도시한다. 화이트(white) 박스들은 DASH 시스템을 특정하는 반면, 음영(shaded) 박스들은 LTE 시스템을 특정한다. 더 명확하게 하기 위해, DASH 인프라구조를 LTE 네트워크들에 전달할 시에, DASH 클라이언트(12)는 LTE 기지국(20), 라디오 채널(22) 및 사용자 엔티티(24)의 연접을 통해 HTTP CASH(16)에 접속되는 것으로 도시되어 있으며, 여기서, 라디오 리소스 관리자(26)는 기지국(20)에 의해 포함되는 것으로 도시되어 있고, 사용자 엔티티(24)는, DASH 클라이언트(12)가, 예를 들어, 사용자 엔티티의 프로세서 상에서 구동하는 소프트웨어의 형태로 동작하고 있는 모바일 전화기 등과 같은 모바일 단말일 수도 있다. DASH 클라이언트(12) 뿐만 아니라 LTE eNB(20)가 미디어 프리젠테이션 설명(MPD(18))으로의 액세스를 갖는다고 가정한다. MPD(18)는, 전송 프로토콜로서 TCP/IP를 사용하여 HTTP 서버(10)로부터 사용자가 세그먼트들을 요청함으로써, 사용자(12)에게 스트리밍 서비스를 제공하기 위해 서버(10)에서 비디오 표현에 관한 충분한 정보를 제공한다. 초기에, dash 클라이언트(12)는 HTTP 획득 요청을 HTTP 서버(10)에 송신한다. HTTP 핸드쉐이크(handshake) 이후, 서버(10)와 클라이언트(12) 사이의 TCP 터널이 설정된다. 이러한 TCP 터널은 기저(underlying) 물리 전송 계층에 대해 투명하다. MPD(18)에 의해 제공된 정보에 의존하여, DASH 클라이언트(12)는, 포함된 미디어 데이터를 적절히 디멀티플렉싱, 디코딩 및 렌더링하기에 충분한 정보를 갖는다.

도 2에 도시된 시나리오에 관해 수반된 문제는, 각각의 DASH 클라이언트(12)의 사용자 엔티티(24)에 라디오 리소스 관리자(26)에 의해 할당되는 현재 할당된 통신 리소스들에서 가능한 가장 높은 품질 및/또는 정보 콘텐츠를 갖는 각각의 서버(10) 상에 상주하는 미디어 콘텐츠의 버전을 자신의 사용자에게 각각의 DASH 클라이언트(12)가 제공하려고 추구하는 DASH 클라이언트(12)의 일반적인 작동이다. 그 후, "가장 높은 가능한" 품질/정보 콘텐츠는, 최대 공간 해상도, 최대 수의 뷰(view)들, 최대 폭 깊이 등을 갖는 것일 수 있으며, 그에 의해, 가장 높은 대역폭을 필요로 한다. 이것은 차례로, 각각의 DASH 클라이언트(12)가 기지국(26)의 이용가능한 라디오 리소스들을 최대로 부담(strain)하며, 기지국 및 라디오 리소스 관리자(26)가 각각, 각각의 사용자 엔티티의 각각의 DASH 클라이언트가 획득하기를 원하는 미디어 콘텐츠의 이용가능한 상위 레벨 버전들 중 하나를 획득하기 위해, 할당된 통신 리소스들의 증가를 지속적으로 요청하는 것에 대처해야 한다는 것을 의미한다. 자연스럽게, 이것은, 분배 또는 스케줄링이 현재의 채널 상황, 및 개별 사용자 엔티티들(24)에 할당된 사용자 프로파일들에 기초하여 수행되는 사용자 엔티티들로의 라디오 통신 리소스들의 차선의 분배를 유도한다.

따라서, 예를 들어, 충족된 사용자들의 수를 최대화하기 위해, 이용가능한 통신 리소스들의 더 효율적인 사용을 가능하게 하는 리소스 관리 개념을 제공하는 것이 본 발명의 목적이다.

이러한 목적은 독립 청구항들의 요지에 의해 달성된다.

본 발명의 바람직한 실시예들은 다음의 도면들에 관해 후술된다.

도 1은 DASH 아키텍처의 일 예의 블록도를 도시한다.
도 2는, LTE 네트워크들에서의 DASH에 대한 현재의 배치 아키텍처를 도시한 블록도이며, 여기서, 실선 화이트 박스들은 DASH 표준에서 특정된 디바이스들을 표시하는 반면, 파선 화이트 박스들은 개념적이거나 투명하다.
도 3은, 본 발명에 따른 라디오 리소스 관리자의 어느 상이한 실시예들이 설명되는지에 기초한, 라디오 리소스 관리자를 포함하는 예시적인 라디오 리소스 환경의 블록도를 도시한다.
도 4는 미디어 레이트 대 순시(instantaneous) 레이트 대 세그먼트 다운로드 레이트의 그래프를 도시한다.
도 5는 도 3의 라디오 리소스 관리자의 제 1 실시예의 가능한 구현의 다이어그램을 도시한다.
도 6은, 본 발명에 따른 라디오 리소스 관리자의 어느 상이한 실시예들이 설명되는지에 기초한, 라디오 리소스 관리자를 포함하는 추가적인 예시적인 라디오 리소스 환경의 블록도를 도시한다.
도 7은, 본 발명에 따른 라디오 관리자의 어느 상이한 실시예들이 설명되는지에 기초한, 리소스 관리자를 포함하는 사용자 엔티티의 블록도를 도시한다.
도 8은 도 6의 라디오 리소스 관리자의 일 실시예의 가능한 구현의 다이어그램을 도시한다.
도 9는 도 3 및 도 6의 라디오 리소스 관리자의 일 실시예의 가능한 구현의 다이어그램을 도시한다.
도 10은 도 7의 실시예에서 사용되기에 적합한 클라이언트의 가능한 구현의 다이어그램을 도시한다.
도 11은 도 10의 리소스 관리자를 포함하는 예시적인 라디오 리소스 환경의 블록도를 도시한다.
도 12는 도 3 또는 도 6에 따른 라디오 리소스 관리자를 포함하는 다른 예시적인 라디오 리소스 환경의 블록도를 도시한다.
도 13은 클라이언트의 가능한 구현을 포함하는 클라이언트와 서버 사이의 데이터 경로의 일부의 가능한 구현의 블록도를 도시한다.
도 14는 일 실시예에 따른, 하나의 사용자 엔티티에서 동작하는 서버 및 다른 사용자 엔티티에서 동작하는 대응하는 클라이언트를 갖는 시나리오에서 수행되는 단계들의 시퀀스를 도시한다.
도 15는, 클라이언트가 동작하는 사용자 엔티티의 리소스 관리자가 MPD 파싱(parse)의 라디오 리소스 관리자를 경감(relieve)시키는 시나리오에서 수행된 단계들의 시퀀스를 도시한다.
도 16은 일 실시예에 따른, 업링크 통신 리소스들을 할당하는 라디오 리소스 관리자를 포함하는 예시적인 라디오 리소스 환경의 블록도를 도시한다.
도 17은 다른 실시예에 따른 라디오 리소스 관리자들의 시스템을 도시한다.

도 3은 본 출원에 따른 라디오 리소스 관리자의 제 1 실시예를 도시한다. 도 3의 라디오 리소스 관리자는 일반적으로, 참조 부호(30)로 표시되며, 기지국(32)의 통신 리소스들을 사용자 엔티티들에 할당하도록 구성되며, 사용자 엔티티들 중 하나는 (34)에 대표적으로 도시되어 있다. 사용자 엔티티(34)는, 예를 들어, 모바일 전화기, 랩탑 등과 같은 모바일 단말이지만, 또한 고정형(stationary) 디바이스일 수도 있다. 사용자 엔티티(34)는 또한, 자신의 안테나 또는 안테나들(미도시)을 통해 무선 채널(36)을 통하여 기지국(32)과 통신할 수 있다. 기지국(32)은 통신 데이터, 즉 다운링크 및 업링크 데이터의 통신 채널(36) 상으로의 멀티플렉싱을 적절히 관리하며, 하나 또는 그 초과의 안테나들(미도시)을 또한 포함할 수도 있다. 특히, 기지국(32)은, 기지국(32)에 의해 출력된 송신 신호 상으로 다양한 사용자 엔티티들(34)에 대한 다운링크 데이터를 적절히 멀티플렉싱한다. 상이한 멀티플렉싱 방식들이 이러한 목적을 위해 사용될 수도 있다. 예를 들어, 기지국(32)은 OFDM, 및 특히 LTE를 사용할 수도 있다. 임의의 경우에서, 기지국(32)은, 사용자 엔티티들로의 기지국(32)의 통신 리소스들의 할당, 즉 그 중에서도 스케줄링을 현재의 리소스 상황에 적응시키기 위해 시변 방식으로, 사용자 엔티티(34)를 포함하는 사용자 엔티티들에 통신 채널의 통신 리소스들을 분배 또는 할당할 수 있다. 예를 들어, 기지국(32)은 스케줄링을 수행하기 위해 다음의 파라미터들의 임의의 결합에 의존할 수도 있다.

1) 기지국(32)에 의해 서빙된 사용자 엔티티들(34)의 수, 즉 기지국(32)에서 등록을 수행하는 사용자 엔티티들(34)의 수 및 그에 따른, 기지국의 통신 리소스들이 분배될 사용자 엔티티들(34)의 수.

2) 개별 사용자 엔티티들과 교환될 통신 데이터의 종류 － 통신 데이터의 종류는, 예를 들어, HTTP 요청된 데이터 등으로부터 스피치 신호들과 같은 실시간(낮은 지연) 미디어 데이터를 구별함 －.

3) 서빙된 사용자 엔티티들에 할당되고 － 예를 들어, 다운링크 및/또는 업링크에 대한 상이한 최대 비트 레이트들 및/또는 최소 비트 레이트들을 이용하여 사용자 프로파일들이 할당됨 －, 통신 리소스들을 할당할 시에, 더 낮은 우선순위를 갖는 사용자 엔티티들에 비해 더 높은 우선순위를 갖는 사용자 엔티티들을 선호하는 RRM(30)을 이용하여 사용자 엔티티들 중에서 우선순위를 정의하는 사용자 프로파일들.

4) 사용자 엔티티들의 현재 수신 품질 상황을 표시하는 사용자 엔티티들로부터의 채널 품질 피드백, 즉, 한편으로는 기지국(32)과 다른 한편으로는 개별 서빙된 사용자 엔티티들(34) 사이의 채널 품질 － 여기서, 기지국(32)은, 예를 들어, 사용자 엔티티들로부터의 각각의 채널 피드백 신호들에 의해 채널 품질을 측정함 －.

5) 추가적인 대역폭의 할당에 대한 사용자 엔티티들의 소망들을 표시하는 사용자 엔티티들로부터의 채널 레이트 요청들.

1개 초과의 기지국(32 및 38)이 하나의 사용자 엔티티를 서빙할 수도 있는 경우에서, 그 후, 수는, 몇몇 영역들에서 사용자 엔티티들을 현재 서빙하고 있거나 사용자 엔티티들을 서빙하기에 적어도 현재 이용가능한 모든 기지국들에 의해 서빙된 사용자 엔티티들의 수에 관계된다. 통신 리소스들의 할당을 결정할 경우, 그들 기지국들 사이의 상호작용이 또한 고려될 수 있다. 그 시나리오에서, RRM(30)에 의해 어그리게이팅(aggregate)된 서브캐리어들과 같은 정보 또는 셀들 사이의 핸드오버와 같은 사용자 엔티티들(34)에 관한 RRM(30)에 의해 도출된 정보는, 상위 레벨 RRM(30)에 의해 기지국들(32 및 38) 사이에서 추가적으로 공유되고 수집 및 사용될 수 있다.

기지국(32)은, 통신 리소스들을 사용자 엔티티들에 상이하게 할당하기 위해 상이한 옵션들/파라미터들을 가질 수도 있다. 이것은, 다운링크 및 업링크 통신 양자에 대해 참이다. 예를 들어, 기지국(32)은 다음의 셋팅들의 임의의 결합에 의해 스케줄링을 구현할 수 있다.

1) OFDM 서브캐리어들과 같은 서브캐리어들의 서빙된 사용자 엔티티들로의 연관. 통상적으로, LTE에서 사용된 서브캐리어들의 최대 수는 20MHz 대역폭이다. 자연적으로, 이것은 변경될 수도 있다. LTE-어드밴스드와 같은 LTE의 후속에 대해, 20MHz 내지 최대 100MHz의 다수의 캐리어들이 논의중에 있다. 이것은 캐리어 어그리게이션으로 지칭된다. 즉, 서브캐리어들은 또한 어그리게이팅된 서브캐리어들일 수도 있다.

2) 서빙된 사용자 엔티티들로의 시간 슬롯들의 연관 또는 분배.

3) 사용자 엔티티들이 기지국(32)과 통신할 수 있어야 하는 기지국 셀의 공간 커버리지 － 공간 커버리지는, 예를 들어, MIMO 기술들의 사용에 의해 변경됨 －.

4) 변조 성상도(constellation)들로의 개별 서브캐리어들의 연관.

전술된 셋팅 옵션들 중 임의의 하나에 의해 스케줄링을 구현하지 않는 경우, 기지국(32)은 각각의 송신 특성을 사용하지 않거나 고정된 셋팅을 대신 사용할 수도 있다. 예를 들어, 기지국(32)은, 다운링크 내에서 시분할 멀티플렉싱을 사용하지 않을 수도 있고 그리고/또는 업링크 내에서 시분할 멀티플렉싱을 사용하지 않을 수도 있거나, 각각의 시분할 멀티플렉싱이 시간에 걸쳐 고정될 수도 있다. 동일한 것이, 서브캐리어들의 할당을 수반하는 주파수 분할 멀티플렉싱의 MIMO 기능에 관해 적용된다.

임의의 경우에서, 할당된 통신 리소스들에 의존하여, 각각의 사용자 엔티티(34)는 다운링크 및 업링크 양자에 대한 효율적인 송신을 경험한다.

마이너한 유의점으로서, 도 3의 라디오 리소스 관리자(30)가 기지국(32)에 의해 포함될 수 있거나 기지국(32)의 일부일 수 있거나, 기지국(32)에 의해 하우징될 수 있음을 유의해야 한다. 그러나, 라디오 리소스 관리자(30)는 또한, 기지국(32)으로부터 물리적으로 분리되어 배열될 수 있다. 특히, 라디오 리소스 관리자(30)가 특정한 기지국과 특히 연관되지는 않는다는 것이 훨씬 가능할 수 있다. 오히려, 라디오 리소스 관리자(30)는, 1개 초과의 기지국의 셀들을 초래하는 더 높은 수의 사용자 엔티티들에 대한 라디오 리소스 관리를 관리할 수 있다. 도 3은, 예를 들어, 선택적인 추가적인 기지국(38)을 도시하며, 그의 통신 리소스들은 또한, 라디오 리소스 관리자(30)에 의해 또한 제어될 수도 있다. 특히, 기지국들(32 및 38)이 사용자 엔티티들이 1개 초과의 기지국에 의해 동시에 서빙되게 하는 무선 네트워크를 라디오 리소스 관리자(30)와 함께 형성하는 것이 가능할 수 있다. 즉, 양자의 기지국 셀들의 중첩 영역에 현재 존재하는 사용자 엔티티들은, 라디오 리소스 관리자(30)에 의해 그에 할당된 양자의 기지국들의 통신 리소스들을 가질 수 있다. 따라서, 그 경우, 사용자 엔티티(34)의 유효하게 이용가능한 통신 대역폭은, 서빙 기지국들(32 및 38)의 각각에 의해 그것에 제공되거나 할당된 유효한 대역폭의 합산일 것이다. 자연적으로, 서빙 기지국들의 수가 증가될 수 있다.

임의의 경우, 지금까지 설명된 바와 같은 라디오 리소스 관리자(30)의 기능에 관해 수반된 문제는, 사용자 엔티티(34)와 같은 사용자 엔티티들 중 하나에서 동작하는 클라이언트(40)가 가능한 높은 정보 콘텐츠 레벨을 갖는 버전으로 서버(42)로부터 미디어 콘텐츠를 획득하기를 추구한다는 것이다. 클라이언트는, 예를 들어, 브라우저, VoIP(voice over IP) 애플리케이션 등과 같이 사용자 엔티티의 운영 시스템 상에서 구동하는 애플리케이션일 수도 있지만, 다른 가능성들이 또한 존재한다. 차례로, 서버는, 컴퓨터, 다른 모바일 사용자 엔티티, 워크 스테이션, 또는 네트워크와 같은 호스트 상에서 구동하는 VoIP 애플리케이션 또는 미디어 콘텐츠 서버와 같은 프로그램일 수도 있다.

예를 들어, 사용자 엔티티(34)의 클라이언트(40)가 서버(42)로부터 미디어 콘텐츠(44)를 다운로딩하기를 추구하고, 이러한 미디어 콘텐츠(44)가, 클라이언트(40)에 대한 서버(42)로부터 또한 이용가능한 미디어 프리젠테이션 설명(46)에 의해 설명된 바와 같은 상이한 버전들로 서버(42)에서 이용가능하다고 가정한다. 미디어 콘텐츠(44)의 상이한 버전들은, 다음의 파라미터들의 임의의 서브세트의 임의의 결합으로 상이할 수도 있다.

1) 공간 해상도

2) 시간 해상도

3) 뷰들의 수

4) 비트 깊이

5) 신호 대 잡음비

6) 오디오 채널들의 수

즉, 미디어 콘텐츠(44)는 비디오일 수도 있다. 서버(42)와 클라이언트(40) 사이의 데이터 트래픽이 이전의 기지국(32) 또는 기지국들(32 및 38)을 각각 유도한다는 것을 도시하는 점선(48)에 의해 그것이 도시된 바와 같이, 클라이언트(40)가 서버(42)로부터 미디어 콘텐츠(44)를 획득하는 데이터 트래픽은, 라디오 리소스 관리자(30)에 의해 적어도 조사가능하며(surveyable), 데이터 트래픽의 콘텐츠는 화살표(50)로 도시된 바와 같이 라디오 리소스 관리자(30)에 의해 검사가능하다. 대안적으로, 데이터 트래픽은 심지어, 파선 화살표(52)에 의해 도시된 바와 같이 라디오 리소스 관리자(30)를 통해 유도될 수도 있어서, 이러한 대안에 따르면, 라디오 리소스 관리자(30)가 심지어 클라이언트(40)와 서버(42) 사이의 데이터 트래픽의 일부들을 검사할 뿐만 아니라 인터셉트 또는 그렇지 않으면 그 일부들에 영향을 주게 할 것이다.

데이터 트래픽은 HTTP와 같은 임의의 적절한 프로토콜을 사용할 수도 있다. 기저 프로토콜은 TCP 또는 UDP일 수도 있다.

그러나, 실시예들의 설명들이 HTTP 스트리밍에 포커싱되지만, 데이터 전달 그 자체는 또한, RTP[IETF RFC 3550]를 통해서와 같이 상이하게 적용될 수도 있다. 따라서, 세션 내의 미디어의 설명은 SDP[IETF RFC 4566](세션 설명 프로토콜) 파일에 의해 주어진다. 그러한 SDP 파일은 본 출원의 의미에서 "MPD"로서 간주될 것이며, 상이한 인코딩 파라미터들과 같은 상이한 미디어 특징들의 설명이 그로부터 선택되게 한다.

미디어 콘텐츠(44)의 다양한 버전들이 미디어 콘텐츠(44) 상에서 상이한 양의 정보를 전달한다는 사실로 인해, 이들 버전들은, 인터럽션 없이 클라이언트(40)에서 각각의 버전을 플레이시키기 위해 필요한 그들의 필요한 최소 요구된 송신 대역폭에 관한 이들 버전들 사이의 랭킹을 허용한다.

일반적으로, 클라이언트(40)는 미디어 콘텐츠(44) 상에서 가능 높은 가능한 정보를 제공하는 버전을 사용자에게 제공하도록 구성된다. 가장 높은 가능한 버전은, 사용자 엔티티(34)에서 이용가능한 디스플레이 및 라우드스피커들 또는 미디어 플레이어, 디코더 등에 의한 것과 같이 사용자 엔티티(34)에 의해 이용가능한 설비들에 의해 사용자에 여전히 프리젠테이션가능한 것으로서 정의될 수도 있다. 더 명확하게 하기 위해, 도 3에 도시되지는 않았지만, 사용자 엔티티(34)는, 미디어 콘텐츠(44)의 프레임 시퀀스를 디스플레이하기 위한 디스플레이 및 프레임 시퀀스에 동반된 선택적인 오디오 신호를 재생하기 위한 하나 또는 그 초과의 라우드 스피커들을 포함할 수도 있다. 후자의 경우에서, 클라이언트(40)는, 예를 들어, 사용자 엔티티(34)의 디스플레이에 의해 여전히 재생가능한 가장 높은 공간 해상도를 제공하는 미디어 콘텐츠(44)의 버전을 사용자에게 제공하기를 시도할 수도 있다.

최종적으로, 클라이언트(40)는, 예를 들어, HTTP 요청에 의한 것과 같이 서버(42)로부터 미디어 콘텐츠(44)의 원하는 버전을 요청한다. 클라이언트(40)가 사용자에게 제공될 버전에 대해 결정할 수 있게 하기 위해, 클라이언트(40)는, 서버(42)로부터 클라이언트(40)로의 데이터 트래픽 내에서 미디어 프리젠테이션 설명(46)을 제공받는다. 예를 들어, 클라이언트(40)는 서버(42)로부터 미디어 콘텐츠(44)의 미디어 프리젠테이션 설명(46)을 요청하며, 서버(42)는 차례로, 미디어 프리젠테이션 설명(46)을 클라이언트(40)에 전송함으로써 응답한다. 상술된 바와 같이, 미디어 프리젠테이션 설명(46)은, 미디어 콘텐츠(44)의 서버(42)에서 이용가능한 가용 버전들 및 이들 버전들의 필요한 최소 요구된 송신 대역폭들을 클라이언트(40)에 표시한다. 따라서, 클라이언트(40)는, 라디오 리소스 관리자(30)에 의해 사용자 엔티티(34)에 제공되거나 할당된 현재 이용가능한 유효 대역폭을 평가하고, 일반적으로, 가장 높은 레벨을 갖고 따라서 여전히, 비디오 라디오 리소스 관리자(30)에 의해 제공된 유효 대역폭 아래에 있거나 동일한 가장 높은 최소 요구된 송신 대역폭을 필요로 하는 버전을 선택한다.

그러나, 본 출원의 명세서의 서두 부분에서 설명된 바와 같이, 사용자 엔티티들에서 동작하는 모든 클라이언트들(40)이 각각의 미디어 콘텐츠의 최대 대역폭 버전을 사용자들에게 제공하기를 추구하므로, 기지국(32)의 통신 리소스들 상에 놓인 부담은 높지만, 예를 들어, 그 부담은 클라이언트들(40)이 그들의 요청된 버전 레벨을 낮추면 그렇게 높을 필요는 없을 것이다.

따라서, 도 3의 실시예에 따르면, 라디오 리소스 관리자(30)는, 각각의 서버로부터 각각의 사용자 엔티티(34)에서 동작하는 각각의 클라이언트(40)로의 데이터 트래픽 내의 미디어 프리젠테이션 설명(46)에 의존하여, 사용자 엔티티(34)를 포함하는 사용자 엔티티들에 기지국(32)의 통신 리소스들을 할당하도록 구성된다. 아래의 설명으로부터 더 명확해질 바와 같이, MPD(46)에 대한 약술된 의존성을 사용하여 RRM에 의해 할당된 통신 리소스들은, 전체 통신 리소스들의 주요 부분을 표현하는 업링크 및/또는 다운링크 통신 리소스들에 특히 관련될 수도 있으며, 그 전체 통신 리소스들은 차례로, TCP 또는 전술된 품질 피드백의 확인응답 피드백 루프와 같은 제어 시그널링을 또한 포함할 수도 있다.

더 명확하게 하기 위해, 라디오 리소스 관리자(30)는, 사용자 엔티티(34)인 사용자 엔티티들에 기지국(32)의 통신 리소스들을 할당할 경우, 서버(42)로부터 클라이언트(40)로의 데이터 트래픽 내의 상이한 대역폭들의 비디오 콘텐츠(44)의 버전들을 설명하는 미디어 프리젠테이션 설명(46)을 검사하도록 구성되며, 미디어 프리젠테이션 설명에 의해 제공된 정보를 다른 입력 파라미터들과 함께 고려한다.

예를 들어, 서빙될 높은 수의 사용자 엔티티들(34)로 인해, 예를 들어, 기지국(32)의 통신 리소스들에 놓인 높은 부담이 현재 존재하면, 라디오 리소스 관리자(30)는, 클라이언트(40)에 의해 서버(42)로부터 현재 요청된 미디어 콘텐츠(44)의 버전이 클라이언트(40)에 대해 현재 이용가능하지 않아야 하고, 따라서, 사용자 엔티티(34)에 할당된 통신 리소스들의 양을 감소시킨다고 결정할 수도 있으며, 그에 의해, 사용자 엔티티(34)에 제공된 유효 대역폭을 효율적으로 감소시킨다. 즉, 라디오 리소스 관리자(30)는, 높은 부담 상황들에서, 기지국(32)의 통신 리소스들 상에 놓인 높은 부담 동안 적어도 일시적으로 클라이언트(40)가 더 높은 레벨 버전의 미디어 콘텐츠(44)로부터 더 낮은 레벨 버전의 미디어 콘텐츠(44)로 스위칭해야 한다고 결정할 수도 있다. 물론, RRM(30)은 먼저 그러한 더 낮은 대역폭 버전의 존재를 체크할 수도 있다. 자연적으로, 클라이언트는 또한, 몇몇 이유들을 위해, 예를 들어, 셀 내의 클라이언트들에 의해 관찰(watch)된 비디오 품질을 최적화시키기 위하여, 최소의 수용가능한 비디오 품질 또는 정보량을 획득하기 위해 더 높은 대역폭을 갖는 버전을 획득할 수 있다. 즉, RRM(30)은 단지 셀 스루풋을 최적화시키기 위해서만 클라이언트들에 통신 리소스들을 할당할 필요는 없다. 오히려, RRM(30)은 또한, 셀 내의 모든 클라이언트들에 대한 비디오 품질을 고려할 수 있다. 더 달리 말하면, 물론, 클라이언트들이 최대 품질을 위해 악명높게(notoriously) 적용하는 경우들이 존재한다. 그러한 클라이언트들에 대한 일 예는, 예시적으로 후술되는 자동 스위칭 모드의 클라이언트들이다.

다른 관점으로부터, 라디오 리소스 관리자(30)는, 통신 리소스들이 할당되는 사용자 엔티티들(34) 중 1개 초과의 클라이언트들(40)이 적어도 하나의 기지국(32)을 통해 각각의 미디어 콘텐츠(44)를 현재 다운로딩하고 있으면, 클라이언트들의 각각의 미디어 콘텐츠(44)에 대한 버전들의 품질 측정 및 최소 대역폭에 적어도 의존하는 비용 함수(cost function)가 최적화되도록, 서버 및 클라이언트의 각각의 쌍으로부터의 각각의 데이터 트래픽 내의 각각의 미디어 프리젠테이션 설명(46)에 의존하여, 1개 초과의 사용자 엔티티들(34)로의 통신 리소스들의 할당을 수행하도록 구성될 수도 있다. 더 명확하게 하기 위해, 최적화될 비용 함수는, 클라이언트들의 각각의 미디어 콘텐츠(44)에 대한 버전들에 대해 결정된 총 대역폭과 총 품질 측정 사이에서 드레이드오프를 형성할 수도 있다. 이러한 최적화는, 클라이언트들이 본래 적용되는 것보다 그에 할당된 그들의 미디어 콘텐츠의 더 낮은 품질 버전에 대한 대역폭을 획득하는 것 뿐만 아니라, 클라이언트들이 본래 적용되는 것보다 그에 할당된 그들의 미디어 콘텐츠의 더 높은 품질 버전에 대한 대역폭을 획득하는 것을 초래할 수도 있다. 개별 미디어 콘텐츠들의 버전들에 대한 "품질 측정"은 스케일링(scale)된 간격일 필요는 없다. @qualityRanking 에 의해 제공된 바와 같은 서수(ordinal) 스케일이 충분할 수 있다. 즉, 서수 스케일은 개별 미디어 콘텐츠들에만 관한 것일 수도 있다. 서수성(ordinality)은 모든 클라이언트들(40)의 모든 미디어 콘텐츠들 사이에서 유효할 필요는 없다. 그러나, 미디어 콘텐츠의 각각의 미디어 콘텐츠의 코딩 복잡도의 측정, 즉 평균 레이트/왜곡 측정에 대한 측정과 같은 부가적인 정보가 최적화 비용 함수로 포함될 수도 있다. 이러한 코딩 복잡도 측정은 매우 조악(coarse)할 수도 있다. 예를 들어, 후술되는 @contentCharacteristic가 그러한 특징일 수 있다. 이러한 모든 정보는, 각각의 클라이언트에 의해 요청된 각각의 미디어 콘텐츠의 미디어 프리젠테이션 설명(46)으로 포함될 수 있다.

또한, 라디오 리소스 관리자(30)는, 기지국(30)의 통신 리소스들에 놓인 부담이 다시 감소하는 페이즈(phase)들에서 각각의 클라이언트(40)에 더 높은 양의 통신 리소스들을 재할당하기 위해 이력을 사용하도록 클라이언트(40)에 의해 요청된 미디어 콘텐츠(44)의 버전들의 이력을 로그(log)할 수도 있다.

차례로, 클라이언트(40)는, 라디오 리소스 관리자(30)에 의해 제공된 현재의 유효 대역폭을 평가함으로써, RRM(30)이 할당된 통신 리소스 양을 낮추도록 결정했던 경우, 미디어 콘텐츠(44)의 현재 요청되고 다운로딩된 버전이 단지 인터럽션들을 이용하여 사용자에게 프리젠테이션가능하다는 것을 인식할 수 있다. 즉, 클라이언트(40)는, 사용자에게 미디어 콘텐츠(44)를 재생하는 미디어 플레이어의 미디어 버퍼가 무선 통신 경로(36)를 통한 이용가능한 송신 대역폭의 감소로 인해 비워지게 될 것이라는 것을 인식할 것이다. 클라이언트(40)가 그것이 원하는 바와 같은 또는 클라이언트가 원하는 바와 같은 이러한 상황에 반응하기에 자유로운 경우, 클라이언트(40)의 하나의 합당한 옵션은, 더 낮은 레벨 버전의 미디어 콘텐츠(44), 즉 미디어 콘텐츠(44)의 현재 다운로딩된 버전과 비교하여 더 낮은 필요한 최소 송신 대역폭과 연관된 버전을 요청하는 요청을 서버(42)에 동일하게 전송하는 것일 것이다.

요약을 위해, 도 3의 실시예에 따르면, 라디오 리소스 관리자(30)는, 각각의 사용자 엔티티들에서 동작하는 클라이언트들 및 서버들의 각각의 쌍들 사이에서 연장하는 데이터 트래픽 내의 미디어 프리젠테이션 설명(46)에 의존하여, (상술된 바와 같은, 이용가능한 리소스들에 대한 의존성, 사용자 엔티티 피드백에 의해 표시된 바와 같은 채널 품질, 연관된 사용자 엔티티들로부터의 리소스 요청들의 수, 사용자 엔티티들 사이의 우선순위들 등 이외에) 스케줄링을 수행한다.

도 3의 실시예에 관해, 클라이언트(30)가, 예를 들어, 사용자 엔티티 프로세서 상에서 구동하고 있는 소프트웨어를 표현할 수도 있음을 유의한다. 대안적으로, 클라이언트는 하드웨어 또는 프로그래밍가능 하드웨어로 구현될 수도 있다.

따라서, 도 3은, 서버(42)로부터 사용자 엔티티들(34) 중 하나에서 동작하는 클라이언트(40)로의 데이터 트래픽 내의 미디어 프리젠테이션 설명(46)에 의존하여, 기지국(32)의 통신 리소스들을 사용자 엔티티들(34)에 할당하도록 구성된 무선 리소스 관리자를 나타낸다.

다음에서, 도 3의 실시예의 가능한 구현이 설명된다. 이러한 가능한 구현에 따르면, 클라이언트(30)는 서버(42)로부터 미디어 콘텐츠(44)를 획득하기 위해 HTTP를 통한 비디오 스트리밍을 사용한다. 특히, HTTP를 통한 비디오 스트리밍을 위해 사용되는 기저 전송 프로토콜은 TCP[RFC 793]일 수도 있다.

사실, 여기서 지적된 암시는, 다음에 설명되는 속성들을 공유하는 모든 각각의(every) 프로토콜에 대해 유효하다. 여기서 고려된 프로토콜들은, ACK들(확인응답)/NACK들(부정-확인응답) 또는 TCP에 대해 사용되는 SACK들(선택적인-확인응답)과 같은 임의의 다른 타입의 확인응답의 수신에 기초한 혼잡 제어 메커니즘을 갖는 접속 지향 프로토콜들이다. 가급적, 이들 프로토콜들은, 혼잡 제어 메커니즘의 스루풋 적응 결과와 평행한 패킷 손실들에 대처하기 위한 재송신 메커니즘들을 부가적으로 사용할 수도 있다. 그러한 프로토콜의 예는, HTTP를 통한 비디오 스트리밍을 위해 사용된 기저 전송 프로토콜이 TCP[RFC 793]인 경우일 것이다. TCP는, 예를 들어, 확인응답 메시지들(ACK) 및 흐름 제어 메커니즘들, 예를 들어, 느린 시작을 통한 혼잡 제어, 혼잡 회피, 신속한 재송신 및 신속한 복원을 사용하여, 신뢰성을 제공하도록, 향상된 특성들을 갖는 스트리밍 데이터 전달을 제공한다. 흐름 제어는, 얼마나 많은 바이트들이 내부 버퍼들의 오버플로우 없이 수신될 수 있는지를 송신기에게 표시한다. 관련 미디어 및 상태 레이트들이 도 4 및 표 1에 도시되어 있다. 도 4에서 관측되는 바와 같이, 패킷 손실은 수신된 TCP 스루풋에 대한 영향을 가지며, 전술된 특징들을 갖는 임의의 다른 프로토콜에 대해 동일한 것이 기대된다. 또한, 아래의 수학식은, 패킷 손실(p), 라운드 트립 시간(RTT) 및 최대 송신 유닛(MTU)[18]에 기초한 TCP 스루풋의 매우 양호한 추정을 나타낸다. 따라서, 송신에서 네트워크 계층 패킷 손실들을 추적하는 것은, 라디오 리소스 관리자가 기지국(32)의 통신 리소스들을 적절하게 할당하게 하기 위한 매우 효율적인 기술이다. 따라서, (32)은, 예를 들어, TCP에 대한 전송 계층과 같은 상위 네트워크 계층 상에서의 실제 패킷 손실 레이트를 도출하기 위해, 손실된 라디오 프레임들/MAC 계층 패킷 데이터 유닛들 및 상위 계층 MTU 사이즈 뿐만 아니라 (30)의 MAC 버퍼들(100)에서의 TCP 패킷 손실(도 13과 비교)과 같은 정보를 PHY 계층으로부터 도출할 수도 있다.

이용가능한 시간들 및 레이트들

세그먼트 다운로드 시간	단일 비디오 세그먼트를 다운로딩하는데 걸리는 시간
미디어 레이트	미디어 레이트, 예를 들어, AVC/SVC 비디오 서비스의 레이트
순시 레이트	전송 미디어, 예를 들어, 브로드밴드 무선 시스템, 여기에서는 LTE의 물리 계층 상에서 이용가능한 가변 비트 레이트
세그먼트 다운로드 레이트	LTE eNB 내의 RRM에 의존하는 결과적인 수신 세그먼트 다운로드 레이트

도 3에 관해, 예를 들어, 라디오 리소스 관리자(30)는, MPD(46)로부터 미디어 콘텐츠의 어느 버전을 클라이언트(40)가 현재 다운로딩하고 있는지에 관해 체크하기 위한 상이한 가능성들을 갖는다. 예를 들어, RRM(30)은, 클라이언트(40)로부터 서버(42)로의 미디어 요청을 검사함으로써 기지국(32)을 통해 클라이언트(44)에 의하여 현재 다운로딩되는 미디어 콘텐츠(44)의 버전을 결정할 수도 있다. 그러나, RRM(30)이 클라이언트의 수신된 미디어 스루풋에 대한 스루풋 측정을 결정하고, 결정된 스루풋 측정으로부터, 미디어 프리젠테이션 설명(46)으로부터의 미디어 콘텐츠(44)의 어느 버전이 적어도 하나의 기지국(32)을 통해 클라이언트(44)에 의하여 현재 다운로딩되는지에 대해 예측할 경우, 더 적은 추적 동작들을 갖지만 RRM(30)에서의 더 간단한 프로세싱이 달성가능하다. 스루풋 측정으로서, 할당된 대역폭 그 자체가 사용될 수도 있다. 대안적으로, RRM(30)은 상술된 바와 같이, 각각의 사용자 엔티티(34)로부터 기지국(32)으로 전송된 품질 피드백의 평가에 의해, 각각의 사용자 엔티티에 본래 할당된 대역폭으로부터 각각의 클라이언트(40)의 실제 수신된 미디어 콘텐츠 대역폭의 편차/감소를 추정하기를 시도할 수도 있다. 더 대안적으로, 사용자 엔티티의 부가적인 기능은 실제로 수신된 미디어 콘텐츠 스루풋 레이트에 관해 RRM(30)에게 통지할 수도 있다.

상기 설명이, 미디어 프리젠테이션 설명(46)을 획득하기 위해 서버(42)로부터 클라이언트(40)로의 데이터 트래픽을 조사하기 위한 라디오 리소스 관리자를 가정했지만, 이러한 오버헤드는 대안적으로, 사용자 엔티티의 트랜시버 스테이지와 클라이언트 사이에 있는 사용자 엔티티 내의 몇몇 엔티티와 같은 사용자 엔티티로 옮겨질(displace) 수도 있다 (예를 들어, 도 7 참조). 즉, 이러한 감독(surveillance)은 사용자 엔티티 내의 감독 스테이지에 의해 가정될 수 있다. 감독 스테이지는 MPD(18), 또는 그의 발췌본(excerpt), 또는 MPD의 서브파트로부터 도출되는 파라미터들의 세트와 같은 적어도 그의 서브파트를 다시 RRM(30)으로 포워딩할 것이며, 여기서, 차례로, 파라미터들의 세트 또는 발췌본은 서버(32)에서 이용가능한 미디어 콘텐츠 및 그의 버전들을 설명하기에 충분할 수도 있다. 따라서, 사용자 엔티티(34)는 상술된 바와 같이, 라디오 리소스 기지국(32)과 통신하도록 구성될 수도 있고, 자신의 상부에서 동작하는 클라이언트(40)를 가질 수도 있으며, 그러나, 여기서, 사용자 엔티티(34)는, 데이터 트래픽으로부터 미디어 프리젠테이션 설명(46)을 도출하고, 라디오 리소스 관리자(30)에 미디어 프리젠테이션 설명을 적어도 부분적으로 포워딩하기 위해 서버(42)로부터 클라이언트(40)로의 데이터 트래픽을 조사하도록 부가적으로 구성될 수도 있다. 그 후, 사용자 엔티티가 클라이언트(40) 대신 그곳에서 동작하는 서버를 가질 수도 있지만, RM은, 즉, MPD를 도출하기 위해 그 서버로부터 사용자 엔티티 외부의 임의의 클라이언트로의 데이터 트래픽을 조사함으로써 동일하게 작동한다.

또한, 다음으로 설명되는 도 3의 구현에서, 클라이언트(40) 및 서버(42)는 서버(420로부터 클라이언트(40)로 미디어 콘텐츠(44)를 스트리밍하기 위해 DASH를 사용할 수도 있다. DASH는 미디어 프리젠테이션 설명에 대한 특정한 구조 또는 신택스(syntax)를 정의한다. DASH에 따르면, MPD는 DASH 클라이언트와 DASH HTTP 서버 사이에서 로지컬 채널들을 셋업하기 위해 필요한 파라미터들을 특정하기 위해 태그(tag)들을 사용한다. 태그들은, 문자 O로 마킹하여 선택적이거나, 문자 M으로 마킹하여 의무적일 수 있다.

도 3의 실시예를 구현하기 위해, MPEG DASH 표준(ISO/IEC 23009-1[3])으로부터 취해진 MPD 태그들의 결합이 사용될 수 있다.

특히, 의무적인 @bandwidth 태그가 고려될 수 있으며, 그 태그는 @minBufferTime 태그에 의존하고, 그에 따라 준(quasi)-의무적인이다.

MPD가 구성될 수 있는 태그들은 다음을 포함한다.

MPD 태그들

메인 태그들:
@bandwidth	M	다음과 같이 표현의 데이터 레이트 및 데이터 레이트 변경에 대해 경계를 특정한다: 초 당 비트들(bps)에서 이러한 속성의 값을 갖는 대역폭의 가설적인 일정한 비트레이트 채널을 고려한다. 그 후, 표현이 이러한 채널을 통해 계속 전달되면, @startWithSAP 또는 임의의 세그먼트 인덱스 박스 중 어느 하나에 의해 표시된 임의의 SAP에서 시작하여, 클라이언트는, 연속적인 플레이아웃을 위해 충분한 데이터를 갖는다는 것을 보장받을 수 있으며, 플레이아웃을 제공하는 것은 @minBufferTime * @bandwidth 비트들이 수신된 이후 (즉, 제 1 비트가 수신된 이후 시간 @minBufferTime에서) 시작한다. 종속적인 표현들에 대해, 이것은 값은, 이러한 표현 및 모든 상보적인 표현들에 대해 상기 정의된 바와 같이 최소 대역폭을 정의할 것이다.
@minBufferTime	M	표현 데이터 레이트의 정의에서 사용된 공통 지속기간을 특정한다 (5.5.5.2에서 @bandwidth 속성을 참조)
@qualityRanking	O	동일한 적응 세트 내의 다른 표현들에 관해 표현의 품질 랭킹을 특정한다. 더 낮은 값들은 더 높은 품질 콘텐츠를 표현한다. 존재하지 않으면, 랭킹이 정의되지 않는다.
더 상세한 클라이언트 상태 추적을 위해 고려될 태그들 (선택적인 태그들):
@availabilityEndTime	O	미디어 프리젠테이션 내의 임의의 세그먼트에 대한 가장 최근의 이용가능도 종료 시간을 특정한다. 존재하지 않을 경우, 값은 알려지지 않는다.
@availabilityStartTime	CM 타입 = “동적”에 대해 존재해야 함	@type=”동적”에 대해, 이러한 속성은 존재해야 한다. 이러한 경우, 그것은 미디어 프리젠테이션 내의 임의의 세그먼트에 대한 가장 이른 이용가능도 시간(UTC 단위)의 계산을 위해 앵커를 특정한다. 존재한다면, @type=”정적”에 대해, 그것은 이러한 MPD에서 참조되는 모든 세그먼트들에 대한 세그먼트 이용가능도 시작 시간을 특정한다. 존재하지 않으면, MPD에서 설명된 모든 세그먼트들은, MPD가 이용가능하게 되는 시간에서 이용가능하게 되어야 한다.
@mediaPresentationDuration	CM 타입 = “정적”에 대해 존재해야 함	전체 미디어 프리젠테이션의 지속기간을 특정한다. 속성이 존재하지 않으면, 미디어 프리젠테이션의 지속기간은 알려지지 않는다. 이러한 경우, 속성 MPD@minimumUpdatePeriodMPD가 존재해야 한다. 이러한 속성은, 속성 MPD@minimumUpdatePeriodMPD가 존재하지 않는 경우, 존재해야 한다.
@start	O	존재한다면, 기간의 PeriodStart 시간을 특정한다. PeriodStart 시간은, 각각의 미디어 세그먼트의 MPD 시작 시간뿐만 아니라 미디어 프리젠테이션 시간라인 내의 각각의 액세스 유닛의프리젠테이션 시간을 정의하기 위해 앵커로서 사용된다
@duration	O	존재한다면, 다음 기간의 PeriodStart 시간을 결정하기 위해 기간의 지속기간을 특정함
@bitstreamSwitching	OD 디폴트: 실패	이러한 플래그가 “참”으로셋팅된 경우, 다음이 적용된다: ㆍ적응 세트 내의 모든 표현들은 동일한 수 M의 미디어 세그먼트들을 가져야 한다. ㆍR1, R2, …, RN 모두가 적응 세트 내의 모든 표현들이라고 한다. o j>0에 대해, Si,j가i번째 표현(즉, Ri) 내의 j번째 미디어 세그먼트이라고 하고, o 존재한다면, Si,0가i번째 표현 내의 초기화 세그먼트라고 한다. ㆍ존재한다면, o 비트스트림스위칭 세그먼트들이 존재한다면, Bi(1), Si(1), 1, Bi(2), Si(2), 2, …, Bi(k), Si(k), k, …, Bi(M), Si(M), M o 그렇지 않으면, Si(1), 1, Si(2), 2, …, Si(k), k, …, Si(M), M (여기서, 1 내지 M의 범위 내의 모든 k 값들에 대한 임의의 i(k)는 각각, 1 내지 N의 범위 내의 정수값임) 을 갖는 적응 세트 내의 임의의 초기화 세그먼트는, @mimeType 속성에서 특정된 바와 같은 미디어 포맷을 갖는 4.5.3에서 정의된 바와 같이 “일치 세그먼트 시퀀스”를 초래한다. 더 상세한 법칙들은 특정한 미디어 포맷들에 대해 정의될 수도 있다.
@startWithSAP	O	존재하고 0보다 클 경우, 관련 표현들에서, 각각의 미디어 세그먼트가, 각각의 미디어 스트림 내의 이러한 속성값의 값보다 작거나 같은 SAP의 타입으로 시작한다고 특정한다. 미디어 세그먼트는 미디어 스트림 내의 SAP로 시작하며, 스트림이 그 미디어 세그먼트에 SAP를 포함하면, I_SAU는 I_SAP에 후속하는 제 1 액세스 유닛의 인덱스이고, I_SAP는 미디어 세그먼트에 포함된다.
AdaptationSet	0 … N	적응 세트를 특정한다. 적어도 하나의 적응 세트는 각각의 기간에 존재해야 한다. 그러나, 실제 엘리먼트는, x링크가 사용중이라면, 원격 엘리먼트에만 존재할 수도 있다. 더 많은 세부사항들에 대해, 5.5.3을 참조한다.
@minBandwidth	O	이러한 적응 세트 내의 모든 표현들에서 최소 @bandwidth 값을 특정한다. 이러한 값은, @bandwidth 속성과 동일한 단위들을 갖는다.
@maxBandwidth	O	이러한 적응 세트 내의 모든 표현들에서 최대 @bandwidth 값을 특정한다. 이러한 값은, @bandwidth 속성과 동일한 단위들을 갖는다.
@width	O	@sar 속성에 의해 결정된 그리드 상에서 비디오 미디어 타입의 수평의 시각적인 프리젠테이션 사이즈를 특정한다. @sar의 부재 시에, 폭 및 높이는, @sar의 값이 “1:1” 이었던 것처럼 특정된다. 주석: 비디오의 시각적인 프리젠테이션 사이즈는, 인코딩된 샘플들이 인코딩된크롭핑파라미터들, “오버스캔”시그널링, 또는 “팬/스캔” 디스플레이 파라미터들, 예를 들어, SEI 메시지들에 응답하여 크롭핑된 이후, 프리젠테이션을 위해 사용된 수평 및 수직 샘플들의 수와 동일하다.
@height	O	@sar 속성에 의해 결정된 그리드 상에서 비디오 미디어 타입의 수직의 시각적인 프리젠테이션 사이즈를 특정한다.
@sar	O	“:”에 의해 분리된 2개의 정수들, 예를 들어, “10:11”로 이루어진 스트링의 형태로 비디오 미디어 컴포넌트 타입의 샘플 애스팩트 비를 특정한다. 제 1 수는 임의의 단위들로, 인코딩된 비디오 픽셀들(샘플들)의 수평 사이즈를 특정한다. 제 2 수는 수평 사이즈와 동일한 단위들로, 인코딩된 비디오 픽셀들(샘플들)의 수직 사이즈를 특정한다.
@frameRate	O	표현 내의 비디오 미디어 타입의 출력 프레임 레이트(또는 인터레이스된 출력 필드 레이트의 절반의 경우)를 특정한다. 프레임 또는 필드 레이트가 변하면, 값은, 표현의 전체 지속기간에 대해 평균 프레임 또는 절반의 평균 필드 레이트 필드 레이트이다. 값은, “/”에 의해 분리된 2개의 정수들 (“F/D”) 또는 단일 정수 “F”를 포함하는 스트링으로서코딩된다. 프레임 레이트는 각각, 초당 분할 F/D, 또는 F이다(즉, D의 디폴트 값은 “1”이다)
@mimeType	M	존재한다면, 표현 내의 모든 연속하는 미디어 세그먼트들 및 초기화 세그먼트의 연접의 MIME 타입을 특정함
@codecs	M	표현 내에 존재하는 코덱들을 특정한다. 코덱파라미터들은 또한, 적용가능한 경우 프로파일 및 레벨 정보를 포함해야 한다. 이러한 속성의 콘텐츠들은, DQUOTE 문자들을 동봉하지 않으면서, RFC6381 섹션 3.2의 simp-리스트 또는 팬시-리스트 생성물 중 어느 하나에 따라야 한다. RFC6381에 특정된 바와 같은 코덱들에 대한 명칭 공간으로 매핑되는 표현의 미디어 포맷에 대한 코덱 식별자가 사용되어야 한다.
@indexRange	O	표현의 모든 미디어 세그먼트들에 세그먼트 인덱스를 포함하는 바이트 범위를 특정한다. 바이트 범위는, RFC2616, Clause 14.35.1에 정의된 바와 같은 바이트-범위-규격으로서 표현 및 포맷팅되어야 한다. 그것은 바이트들의 인접하는 범위를 식별하는 단일 표현으로 제약된다.
@indexRangeExact	O	'참'으로 셋팅된 경우, 표현 내의 모든 세그먼트들에 대해, @indexRange에 의해 정의된 프리픽스 외부의 데이터가 모든 미디어 스트림들의 모든 액세스 유닛들에 구문적으로 및 시맨틱하게 액세스하는데 필요한 데이터를 포함한다고 특정한다. 이러한 속성은, @indexRange가 부재하면, 존재하지 않아야 한다.
RepresentationIndex	0…1	표현 인덱스 세그먼트에 대한 가능한 바이트 범위를 포함하는 URL을 특정한다. 타입에 대해, 정의는 표 14를 참조한다.
SegmentInfo엘리먼트로부터의 데이터 위치

부가적인 태그(선택적)-아직은 존재하지 않는 것들-제안된 새로운 속성들:
@automaticSwitching	O	'참'으로 셋팅된 경우, 가장높은디코딩가능한 품질을 갖는 표현이 시간에 걸쳐 변경되지 않을 선호되는 표현이라는 것을 표시한다.
@robustLayerDecoding	O	이러한 파라미터는, 임의의 시간의 모든 종속적인 표현들을 포함하지 않을 수도 있다는 것을 표시한다. 이것은, 예를 들어, SVC 미디어 콘텐츠가 클라이언트에 의해 요청/기대된 것보다 잠재적으로 더 적은 품질로 클라이언트에 도달한다는 것을 시그널링하기 위한 것이다.
@contentCharacteristic	O	레이트 왜곡 관련성과 같은 품질과 비디오 레이트 사이에 상이한 매핑이 존재하도록 콘텐츠의 특징들을 특정한다. 그러한 메트릭은, 예를 들어, '높은', '중간', '낮은' 비트레이트 요구들로서 축구, 뉴스들, 액션 영화, 뮤직과 같은 특정한 타입의 콘텐츠에 대한 비트레이트인코딩 요구 또는 일반적인 특징들을 표시할 수도 있다. 실제로, 이러한 파라미터는, 비트레이트, 해상도 및 프레임레이트에 추가적으로 의존하여 간단한 비디오 품질 추정을 가능하게 할 수 있다. @qualityranking가 이러한 파라미터에 포함될 수도 있다.

즉, 도 3의 MPD(46)는 각각의 이용가능한 버전(표현)에 대해 파라미터들 @bandwidth, @minBufferTime 및 선택적으로는 @qualityRanking를 가질 수 있다.

상기 관측된 바와 같이, MPD(46)가 버전 당 이들 파라미터들 중 첫번째 2개, 즉 @bandwidth, @minBufferTime만을 포함한다는 것이 훨씬 가능할 것이다.

MPD의 일 예가 아래의 리스팅 1에 도시되어 있다. 예는, 예를 들어, 프로파일 속성에 의해 식별된 바와 같은 DASH 표준[3]의 특정한 프로파일에 대응할 수도 있다. 미디어 프리젠테이션 시간은 3256초로 측정되고, 최소 버퍼 시간은 1.2초로 특정된다. 2개의 표현들의 세그먼트들의 URL들(uniform resource locator)이 주어지며, 여기서, 하나의 표현은 64KB 또는 32KB 대역폭을 요구하고, 세그먼트들의 URL은, 각각의 표현의 각각의 SegmentList 엘리먼트들에 포함된 2개의 대안적인 BaseURL들 및 SegmentURL들 중 하나를 연접함으로써 생성된다. 세그먼트들의 지속기간은, SegmentList 엘리먼트 내의 지속기간 속성에 의해 주어진다.

리스팅 1: 2개의 상이한 표현들을 갖는 비디오 세그먼트들에 대한 미디어 패킷 설명(MPD)에 대한 예

추가적으로, 아래에서 더 상세히 약술되는 도 3의 실시예의 구현은 LTE 시스템 내에 임베딩될 수 있다. 즉, 기지국(32) 또는 기지국들(32 및 38) 및 라디오 리소스 관리자(30)는 LTE 시스템의 일부일 수 있다.

LTE에 대해, 상이한 구현들이 도입된다. 다중-입력 다중-출력(MIMO) 향상들과 결합한 직교 주파수-분할 다중 액세스(OFDMA)로의 이동 및 회로-스위치로부터 패킷-스위치 네트워크들로의 이주는, 2x2/4x4 MIMO를 이용한 LTE Rel.8에 대해 최대 150/300Mbps의 피크 스루풋들을 달성하는 모바일 네트워크를 초래했다. LTE의 중요한 달성들 중 하나는, 본질적으로 낮은 엔드-투-엔드 지연을 위해 제어 평면 상에서의 50ms 아래 그리고 사용자 평면 상에서의 5ms 아래의 지연을 갖는 ITU-R[15]의 충족이다.

LTE는 신속한 재송신 메커니즘들, 즉 수신기에서 신속한 재순서화를 요구하는 물리 계층(PHY) 및 매체 액세스 제어(MAC) 계층들에서의 자동 반복 요청들(ARQ) 및 하이브리드 ARQ(HARQ) 메커니즘들을 구현한다. 따라서, 부가적인 지터(jitter) 및 지연이 재순서 버퍼링에 의해 도입될 수도 있어서, 특히 HTTP/TCP 비디오 서비스들이 베스트-에포트(best-effort) 서비스로서 오버-더-탑(over-the-top)으로 식별되지 않거나 구동되지 않으면, 실시간 TCP 서비스들에 대해 성능 열화를 초래한다. LTE에서 핸드오버 동안의 TCP 성능은 [12]에서 평가되며, 특수한 패킷 포워딩 기술들 및 패킷 재순서화가 높은 TCP 성능을 달성하는데 필요하다는 것이 나타나 있다.

부가적으로, LTE는 기지국, 즉 이벌브드 노드B(eNB)에서 비중앙화된 스케줄링 및 멀티-사용자 라디오 리소스 관리(RRM)를 도입한다. 비중앙화된 접근법은, HTTP/TCP 라이브 스트리밍과 같은 상이한 트래픽 서비스들에 대해 엔드-투-엔드 QoS를 실현하기 위해 QoS 지원을 이용한 새로운 강인한 크로스-계층(cross-layer) 스케줄링 알고리즘들의 설계를 요구한다.

RRM 엔티티, 즉 (30)은, 스케줄링으로서 또한 지칭되는 단기(short-term) 시간 프레임 상에서 리소스들을 UE들, 즉 (34)에 할당하는 것 뿐만 아니라, 더 긴 시간 프레임 상에서 작동하고 다양한 파라미터들, 예를 들어, UE 피드백, 사용자 서비스 요구 등에 의존하는 장기(long-term) 리소스 할당을 포함하는 라디오 리소스 관리를 담당한다. 할당될 리소스들은, MIMO OFDMA에 기초한 LTE에서 사용되는 시간, 주파수, 공간-그리드로부터 취해진다. 리소스들의 양은, 사용될 LTE 파라미터 대역폭, FDD 또는 TDD 모드, 및 MIMO 모드에 의존한다.

*미디어 콘텐츠를 스트리밍하기 위해 DASH를 사용하고 라디오 리소스 관리자(30)를 LTE 시스템으로 인베딩하여 도 3의 실시예를 구현할 경우, 그의 결과가 도 5에 도시된 바와 같이 도시될 수도 있다. 도 5의 실시예가 도 3에 도시된 엘리먼트들의 기능들을 어떻게 구현할지에 관한 이해를 용이하게 하기 위해, 도 3의 참조 부호들이 도 5에서 재사용되었으며, 도 3에 관해 상기 프리젠테이션된 이들 엘리먼트들의 설명들 및 서술은 도 5에 대해 동등하게 적용될 것이다. 이것은 차례로, RRM(30)이 기지국(32) 내에 물리적으로 포함될 필요가 없다는 것을 또한 의미한다. 한편, 도 2의 몇몇 참조 부호들은, 대응하는 참조 부호들이 도 3에서 미싱(miss)했을 경우라도 도 5에서 재사용되었다. 따라서, 클라이언트(40)는, 기지국(32)을 넘어선 데이터 트래픽 부분이 관련되는 한, 데이터 트래픽이 인터넷과 같은 HDTP 캐시(16)를 지나치도록 서버(42)에 통신적으로 접속되는 것으로 도시되어 있다. 또한, 미디어 프리젠테이션 설명(46)의 콘텐츠가 기인하는 DASH 콘텐츠 준비 스테이지(14)가 도시되어 있다.

도 5의 구현 예의 동작 모드를 설명할 시에, 그들은 LTE를 통해 DASH를 사용하는 라디오 리소스 관리로 지칭될 수도 있다. 미디어 콘텐츠의 버전들의 가능한 표현으로서, VC가 사용될 수도 있다. 도 5의 구현이 도 3의 구현에 후속할 경우, 도 5의 RRM(30)의 기능은, 라디오 리소스를 클라이언트들에 더 효율적으로 할당하기 위해 패시브 시그널링을 실현한다.

특히, DASH 클라이언트(40)는 비디오 세그먼트, 즉 서버(42)에 대한 HTTP 요청을 이슈(issue)한다. RRM 유닛(30)은, ?K(deep) 패킷 검사(50)를 사용하여, 특정한 사용자 또는 클라이언트(40)에 의해 요청된 MPD(46)를 검사한다. MPD(46) 내에서 정의된 @bandwidth 및 @minBufferTime 태그에 의존하여, 스케줄러 및 장기 RRM(30)은 주어진 @minBufferTime에 대한 요청된 대역폭을 실현한다. 그러나, LTE의 PHY 데이터 파이프가 요청된 대역폭을 지원하지 않으면, RRM(30)은, MPD(46) 또는 'sidx'-Box 및 MPD 내의 미디어 콘텐츠의 AVC 비디오 세그먼트에 대해 특정된 다음의 더 낮은 대역폭을 보장하는 것을 자동적으로 시도한다. DASH 클라이언트(40)는, 예를 들어, MPD(46)에 리스트된 바와 같은 더 낮은 레이트 요건들을 갖는 서비스에 HTTP 획득(52)을 전송함으로써 LTE의 RRM(30)의 데이터 레이트 제약에 따라 자신의 HTTP 획득 요청들(52)을 조정한다.

이것은 다음을 보장한다:

1. HTTP 비디오 스트림의 보장된 서비스 전달

2. 리소스들을 가능한 많이 획득하려고 시도할 주어진 사용자에 리소스들을 오버 프로비져닝(over provisioning)하는 것을 방지함

3. 2에 따라서, 주어진 시간-주파수-공간 그리드에 대해 LTE 셀 내의 다른 사용자들에 대한 리소스들을 절약하는 것을 허용함. 이것은, IP 스루풋에서의 변화를 감소시키며, 따라서, 다양한 트래픽 혼합들의 다수의 사용자들로의 평활한 서비스 전달을 허용함.

4. TCP는 LTE 시스템에 의해 할당된 데이터 레이트에 최적으로 적응할 것임.

셀룰러 시스템들 내의 라디오 리소스들이 동일한 eNB에 부착된 모든 사용자들 사이에서 공유되므로, 하나의 사용자에 할당된 리소스들의 양은 얼마나 많은 리소스들이 다른 사용자들에 이용가능한지의 효과를 가질 수 있다. 따라서, RRM(30)은, 다른 사용자들을 지원하기 위해, 하나의 사용자가 매우 양호한 채널 조건들을 갖더라도, 그 하나의 사용자에 대한 리소스들의 양을 감소시키도록 선택할 수 있다. 비트레이트 및 콘텐츠 특징들(콘텐츠의 타입, 예를 들어, 무비, 뉴스, 스포츠) 또는 @qualityRanking를 고려할 경우, 셀 내의 모든 사용자들에 대한 전체 비디오 품질 최적화가 수행될 수 있다.

트릭 모드들(trick mode)(예를 들어, 고속 포워드, 고속 재감기(rewind), 점프)의 사용은 클라이언트(40)에 의해 요청된 청크(chunk)들의 시퀀스에 의하여 RRM(30)에 의해 식별될 수 있다. 트릭 모드 사용 이후, 클라이언트는, @minBuferTime에 대한 새로운 재버퍼링/ DPI에 의한 새로운 버퍼링 검출을 수행해야 한다. DPI는 ?K 패킷 검사를 나타낸다. 이것은, 기지국 스케줄러가 IP 패킷들의 콘텐츠를 들여다보고(look into), 그의 검사들에 기초하여 그의 결정들을 형성한다는 것을 암시한다. 종래에, RRM은 ISO-OSI 모델에 의해 제안된 바와 같이, MAC 계층 상에서 동작하고 IP 계층을 들여다보지 않는다.

도 5에 관해 설명된 세부사항들에 의한 도 3의 실시예의 상술된 구현에 관해, 도 5가 도 3의 실시예를 구체화하는 다양한 양상들이 도 3으로 개별적으로 전달될 수도 있음을 유의한다. 이것은, 예를 들어, 데이터 트래픽을 위한 TCP 프로토콜의 사용, 관리자(30), 기지국(32) 및 사용자 엔티티(34)의 각각의 기능을 정의하기 위한 LTE 시스템의 사용, 및 MPD(46)의 콘텐츠 및 서버(42) 및 클라이언트(40)의 기능을 적어도 부분적으로 정의하는 DASH 스트리밍 프레임워크에 대해 참이다.

도 3 내지 도 5의 실시예들에 따르면, 비디오 리소스 관리자(30)는, "R"로 도 5에 도시된 바와 같이, 서버(42)로부터 클라이언트(40)로의 데이터 트래픽 내의 미디어 프리젠테이션 설명의 평가에 기초하여 개별 사용자 엔티티들 및 그들의 클라이언트들(40)로의 각각의 레이트 할당을 직접적으로 지시했으며, 그에 따라, 기지국(32)의 통신 리소스들을 사용자 엔티티들에 할당한다. 후술되는 실시예들에 따르면, 리소스 관리자(30)의 기능은 선택적이다.

도 6은 본 발명의 추가적인 실시예에 따른 라디오 리소스 관리자를 도시한다. 상기에서와 같이, 도 3 및 도 6에 공통적으로 도시된 엘리먼트들의 기능 및 상호접속에 관하여, 도 3에 관해 상기 프리젠테이션된 설명은 동일하게 유지된다. 즉, 라디오 리소스 관리자(30)는, 미디어 프리젠테이션 설명에 대한 이러한 할당의 종속성이 선택적이라는 것을 제외하고, 상술된 바와 같은 방식으로 기지국(32)의 통신 리소스들을 사용자 엔티티들(34)에 할당한다. 추가적으로, 도 6의 실시예에 따르면, 라디오 리소스 관리자(30)는, 클라이언트(40)와 서버(42) 사이의 데이터 트래픽이 라디오 리소스 관리자(30)를 통해 지나가도록 배열되어서, 후자가 후술되는 바와 같이 데이터 트래픽에 영향을 줄 수 있게 한다.

특히, 도 6의 실시예에 따르면, 라디오 리소스 관리자(30)는 부가적으로, 즉, 도 3에 관해 상술된 기능에 부가하여, 서버(42)로부터 사용자 엔티티(34)에서 동작하는 클라이언트(40)로의 데이터 트래픽 내에서 상이한 대역폭들의 미디어 콘텐츠(44)의 버전들을 설명하는 미디어 프리젠테이션 설명(46) 뿐만 아니라 클라이언트(40)로부터 서버(42)로의 미디어 요청(60)을 검사하도록 구성되며, 미디어 요청(60)은 미디어 콘텐츠(44)의 원하는 버전을 요청한다. 양자의 검사들에 기초하여, 리소스 관리자(30)는, 요청(60)을 전송했던 적어도 사용자 엔티티(34)에 관한 현재의 리소스 상황을 설명하는 정보, 및 사용자 엔티티(34)에 어드레싱된 미디어 프리젠테이션 설명에 의존하여, 1) 미디어 요청(60)을 서버(42)에 포워딩하고 (변경되지 않음), 또는 대안적으로, 2) 미디어 요청(60)이 클라이언트(40)에 전송되는 미디어 콘텐츠(44)의 원하는 버전을 유도하지 않는다는 것을 야기하도록 결정한다. 예를 들어, 리소스 관리자(30)는, 2a) 변경된 미디어 요청이 더 적은 대역폭의 미디어 콘텐츠(44)의 버전을 요청하는 정도로 미디어 요청(60)을 변경시키는 것, 또는 2b) 미디어 요청(60)을 인터셉트하고, 서버(42)로부터 사용자 엔티티(34) 또는 클라이언트(40)로 비-이용가능도 응답을 다시 전송하도록 서버(42)를 에뮬레이팅 또는 서버(42)에 명령하는 것을 통해, 야기하는 것을 수행할 수 있다. 대안적으로, 낮은 대역폭에 대한 응답은 RRM(30)에 의해 수행될 수도 있거나, 임의의 다른 피드백은 서버에 의해 수행되도록 야기될 수도 있어서, 그에 따라 자신의 요청을 변경시키도록 클라이언트에게 명령한다.

이것은 다음을 의미한다. 도 3에 관해 상술된 바와 같이, 라디오 리소스 관리자(30)는 현재의 리소스 상황 정보로의 액세스를 갖는다. 특히, 라디오 리소스 관리자(30)는 사용자 엔티티(34) 뿐만 아니라 모든 사용자 엔티티들에 대한 이러한 현재의 리소스 상황 정보로의 액세스를 갖는다. 이러한 정보에 기초하여, 라디오 리소스 관리자(30)는, 기지국(32)의 통신 리소스들에 놓인 현재의 부담을 알고, 사용자 엔티티(34)에 이용가능한 통신 리소스들에 관해 안다. 추가적으로, 라디오 리소스 관리자(30)는 미디어 프리젠테이션 설명(46)으로의 액세스를 가지며, 동일하게 검사할 경우, 라디오 리소스 관리자(30)는 사용자 엔티티(34) 상의 클라이언트(40)가 다운로딩하기를 추구하는 미디어 콘텐츠(44)의 대안적인 버전들에 관해 안다.

전체 정보, 즉 현재의 리소스 상황 정보 및 미디어 프리젠테이션 설명(46)에 기초하여, 라디오 리소스 관리자(30)는, 기지국(32)이 직면하는 현재의 로드(load)가 변경되지 않은 버전으로 미디어 요청(60)을 서버(42)에 단지 포워딩하는 것을 정당화하기에 충분히 낮은지에 관해 결정할 수 있다. 그러나, 현재의 리소스 상황 정보 및 미디어 프리젠테이션 설명으로부터, 예를 들어, 나머지 대역폭이 모든 이들 다른 사용자 엔티티들의 클라이언트들에게 그들의 요청된 미디어 콘텐츠의 가장 낮은 대역폭 버전을 제공하기도 충분하지 않기 때문에, 미디어 콘텐츠(44)의 현재 요청된 버전에 필요한 대역폭의 일부가 다른 사용자 엔티티들로부터 전달되지 않아야 한다고 라디오 리소스 관리자(30)가 결정하면, 라디오 리소스 관리자(30)는, 변경된 미디어 요청이 더 낮은 대역폭 버전을 요청하는 정도로 미디어 요청(60)을 변경시키도록 결정한다. 따라서, 서버(42)는, 그의 요청에 대한 대답이 실제로는 더 낮은 대역폭 버전에 대한 요청에 대한 대답인 경우를 핸들링할 수 있는 클라이언트(40)에게 더 낮은 대역폭 버전을 전송함으로써, 이러한 변경된 요청에 대답할 것이다. 예를 들어, 더 낮은 대역폭 버전은, 단지 특정한 미디어 스트림 부분들의 생략에 의해 미디어 콘텐츠(44)의 본래 원하던 버전과는 상이하며, 그 부분들의 생략은 미디어 콘텐츠를 재생하는 것을 담당하는 사용자 엔티티(34)의 미디어 디코더를 방해하지 않는다. 즉, 더 낮은 대역폭 버전은 더 낮은 정보 레벨의 스캐일러블(scalable)미디어 콘텐츠이거나, 더 낮은 대역폭 버전은 다른 미디어 파일일 수 있지만, 그 미디어 파일은 동일한 코딩 방식을 사용하여 코딩된다.

미디어 요청(60)을 변경시키는 것 대신에, 서버(42)가 미디어 요청(60)을 인터셉트하고, 서버(42)로부터 클라이언트(40)로 다시 비-이용가능도 응답을 전송하도록 서버를 에뮬레이팅 또는 서버에 명령하는 것이 가능할 수 있다. 양자의 경우들에서, 클라이언트(40)는, 원하는 버전이 미디어 프리젠테이션 설명(46)에 표시되지만 서버에서 이용가능하지 않은 대답을 서버(42)로부터 수신할 것이다. 클라이언트(40)가 임의의 방식으로 이러한 대답에 반응하도록 자유롭더라도, 반응의 하나의 합당한 방식은 다른 요청을 서버(42)에 새롭게 전송하는 것을 수반할 것이지만, 새로운 요청은 서버(42)로부터 미디어 콘텐츠(44)의 더 낮은 대역폭 버전을 요청하며, 그에 의해, 미디어 요청의 상술된 변경으로부터 초래하는 바와 같은 동일한 상황, 즉 서버(42)가 더 낮은 대역폭 버전을 다시 클라이언트(40)에게 전송하는 것을 효율적으로 초래한다.

따라서, 상술된 3개의 결정 옵션들 1) 내지 2b) 중 라디오 리소스 관리자의 결정에서 수반될 수 있는 제 1 단계는, 임의의 더 낮은 대역폭 버전의 미디어 콘텐츠(44)가 이용가능한지 이용가능하지 않은지에 관해 체크할 수 있다. 이러한 체크는 미디어 프리젠테이션 설명(46)에 기초하여 수행된다. 제 2 단계는, 옵션들 2a) 또는 2b) 중 임의의 옵션이 이용가능한지 아닌지에 관해 현재의 리소스 상황 정보를 체크하는 것을 수반할 수 있다.

도 6의 추가적인 확장 또는 요약이 도 7에 관해 다음으로 설명된다. 도 7은 사용자 엔티티(34)의 일 실시예를 더 상세히 도시한다. 도 7에 관해 후술되는 실시예에 따르면, 미디어 요청(60)의 핸들링, 즉 포워딩, 변경 및/또는 인터셉트에 관한 부가적인 라디오 리소스 관리자 기능은, 라디오 리소스 관리자(30)로부터 서버(42)와 클라이언트(40) 사이의 데이터 트래픽을 따라 사용자 엔티티 도메인(34) 및 특히, 사용자 엔티티 송신 스테이지(70)와 클라이언트(70) 사이의 임의의 장소로 옮겨진다. 그러나, 이것이 또한 단지 일 예일 뿐이며, 이러한 기능이 또한 다른 임의의 장소에 위치된 다른 엔티티에 의해 가정될 수 있음을 이해할 것이다.

특히, 도 7은, 하나 또는 수 개의 안테나들(72), 트랜시버 스테이지(70), 리소스 관리자(74), 클라이언트(40), 미디어 재생기(76), 및 예를 들어, 디스플레이(78) 및 하나 또는 수 개의 스피커들(80)을 포함하는, 사용자에게 미디어를 실제로 프리젠테이션하기 위한 하드웨어를 포함하는 것으로서 사용자 엔티티(34)를 도시한다. 이들 모든 엘리먼트들은 그들의 언급 순서로 서로에 직렬로 접속되어 있다. 송신 스테이지(70)는, 각각의 데이터 경로가 클라이언트(40)에 의해 표현된 것들과 같은 후속 또는 상위 계층 애플리케이션들에 대해 투명하도록, 기지국(32)과의 통신을 수행하는 것을 담당한다. 트랜시버 스테이지(70)는, 예를 들어, OFDM (디)멀티플렉싱, 시분할 (디)멀티플렉싱과 같은 (디)멀티플렉싱, 기지국(32)으로의 수신 품질 피드백, 채널 추정 등을 수행한다. 또한, 트랜시버 스테이지(70)는, 각각의 사용자 엔티티(34)에 할당될 대역폭의 증가를 요청하는 요청들을 기지국(32)에 전송할 수 있으며, 그러한 요청들을 전송하는 것은, 예를 들어, 클라이언트(40)와 같은 후속 모듈들 중 임의의 모듈에 의해 트리거링된다. 트랜시버 스테이지(70)는 하드웨어 또는 하드웨어, 프로그래밍가능 하드웨어 및/또는 소프트웨어의 결합 또는 이들의 임의의 결합으로 구현될 수도 있다.

리소스 관리자(74)는 트랜시버 스테이지(70)와 클라이언트(40) 사이에 접속되며, 따라서, 트랜시버 스테이지(70) 및 안테나(72) 각각에 의해 표현된 무선 인터페이스를 통한 클라이언트(40)로부터 서버(42)로의 미디어 요청들의 변경, 포워딩 및/또는 인터셉트에 관한 상술된 라디오 리소스 관리자의 기능을 수행할 수 있다. 즉, 리소스 관리자(74)는 트랜시버 스테이지(70)를 통해 현재의 리소스 상황 정보로의 액세스를 갖는다. 특히, 트랜시버 스테이지(70)는, 라디오 리소스 관리자(30)(도 6 참조)에 의한 사용자 엔티티들로의 통신 리소스들의 현재 할당으로부터 초래하는 현재 이용가능한 송신 레이트에 관해 리소스 관리자(74)에게 통지할 수 있다. 추가적으로, 리소스 관리자(74)는 서버(42)로부터 클라이언트(40)로의 데이터 트래픽 내의 미디어 프리젠테이션 설명(46)을 검사할 수 있다. 클라이언트(40)로부터 서버(42)로의 미디어 요청(60)을 검사함으로써, 그에 따라, 리소스 관리자(74)는 도 6에 관해 상술된 바와 동일한 결정, 즉, 미디어 요청을 포워딩하는 것 또는 대안적으로는, 비-이용가능도 응답을 다시 전송하도록 서버(42)를 에뮬레이팅 또는 서버(42)에 명령하는 것과 함께 미디어 요청을 변경시키는 것 또는 미디어 요청을 인터셉트하는 것의 상술된 결정 옵션들 사이의 결정을 수행할 수 있다. 자연적으로, 리소스 관리자(74)는, 라디오 리소스 관리자(30)와 비교하여 현재의 리소스 상황 정보의 적절한 서브세트로의 액세스만을 갖는다. 그러나, 그럼에도 불구하고, 리소스 관리자(74)는 클라이언트(40)가, 기지국(32)의 리소스 상황을 풀(full)로 고려할 경우, 다른 사용자의 서버 기지국(32)에 대해 공평하지 않은 미디어 콘텐츠(44)의 버전들을 요청하는 것을 회피할 수도 있거나, 클라이언트(40)에 의해 빈번하게 스트리밍가능하지 않을 수도 있다.

도 6 및 도 7의 실시예들에 관해, 리소스 관리자(30 및 74) 각각이 옵션들 1) 및 2) 또는 1) 및 3) 사이에서만 스위칭하도록 구성될 수도 있음을 유의해야 한다. 또한, 리소스 관리자(74)에 관해, 동일한 것이 라디오 리소스 관리자(30)에 의해 사용자 엔티티(34)에 전송된 장기 통신 리소스 보장들을 현재의 리소스 상황 정보의 일부로서 활용하도록 구성될 수도 있음을 유의한다.

따라서, 도 6 및 도 7은, 서버(42)로부터 사용자 엔티티(34)에서 동작하는 클라이언트(40)로의 데이터 트래픽 내에서 상이한 대역폭들의 미디어 콘텐츠(44)의 버전들을 설명하는 미디어 프리젠테이션 디스크립션(46)을 검사하고; 미디어 콘텐츠(44)의 원하는 버전을 요청하는, 클라이언트(40)로부터 서버(42)로의 미디어 요청(60)을 검사하며; 그리고, 현재의 리소스 상황 정보 및 미디어 프리젠테이션 설명(46)에 의존하여, (1) 미디어 요청(60)을 서버에 포워딩하거나, 대안적으로는 (2) 변경된 미디어 요청이 더 적은 대역폭의 미디어 콘텐츠(44)의 버전을 요청하는 정도로 미디어 요청(60)을 변경시키거나, 미디어 요청(60)을 인터셉트하고, 서버(42)로부터 클라이언트(40)로 비-이용가능도 응답을 다시 전송하도록 서버(42)를 에뮬레이팅 또는 서버(42)에 명령하도록 결정하도록 구성된 리소스 관리자를 나타낸다.

도 3 내지 도 5에 관해 상술된 실시예와 유사하게, 도 6 및 도 7의 실시예들의 다음의 가능한 구현들이 다음에 설명된다. 즉, 이들 가능한 구현들은, 무선 통신 시스템을 LTE 시스템인 것으로 가정하고, 미디어 콘텐츠의 스트리밍은 DASH를 사용한다. 도 3에 관련하여 도 5와 유사한 방식으로, 도 8은 이전에 사용된 참조 부호들을 재사용하며, 따라서, 도 6 및 도 7의 엘리먼트들의 기능의 설명은 동일한 참조 부호들을 이용하여 도 8에 도시된 엘리먼트들에 동등하게 적용되어야 한다.

DASH와 결합하여, LTE RRM(30)은 모든 부착된 UE들(34)에 의해 요청된 MPD(46)를 검사할 수 있다. 주어진 UE가 양호한 라디오 채널을 갖고 높은 대역폭 요청(60)을 이슈하면, LTE RRM(3)은, HTTP DASH 서버(42)가 이러한 대역폭이 이용가능하지 않다는 것을 표시하기 위해 W3C HTTP 상태 코드(80)를 송신하도록, 상태 코드 트리거, 소위 상태 코드 주입들을 전송할 수 있다. 가능한 W3C HTTP 상태 코드들이 아래에 리스팅되어 있다. 따라서, LTE RRM(30)은, UE(34)로의 직접적인 시그널링 없이 더 낮은 데이터 레이트를 요청하도록 UE(34)에게 강제할 수 있다. 이것은, 데이터에 대해 대신 사용될 수 있는 시그널링을 위해 사용된 리소스들을 절약하며, 예를 들어, 이들 리소스들은 다른 UE들(34)에 스케줄링될 수 있다. UE의 TCP/IP 서비스는, MPD @bandwidth 태그로부터 취해질 수도 있는 eNB RRM 알고리즘들에 의해, 할당된 레이트에 자동적으로 적응한다.

eNB RRM 유닛(30)은 UE(34)에 의해 요청된 MPD(46)를 검사한다. 부가적으로, 그것은, 도 8에 도시되지 않은 모바일러티 관리 엔티티(MME)로부터 정보를 취할 수도 있다. 사용자 프로파일, 예를 들어, 이동 속도, 핸드오버 통계들, 및 요청된 MPD에 의존하여, RRM 엔티티(30)는, W3C HTTP 상태 코드들을 통한 간접적인 시그널링(80)에 의해 더 높은 또는 더 낮은 비디오 품질을 시행(enforce)할 수 있다 (예를 들어, http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html 참조).

도 8의 상기 설명에서, 서버(42) 상에서 이용가능한 미디어 콘텐츠(44)의 버전들이 별개로, 즉, 어떠한 식으로든지 상이한 정보 콘텐츠에서 비-스캐일러블 버전들로 이용가능하다고 가정됐었다. 그러나, 도 8의 상기 설명은, 미디어 콘텐츠(44)의 이용가능한 상이한 대역폭 버전들이 SVC 또는 MVC 스트림과 같은 스캐일러블 방식으로 어떠한 식으로든지 코딩되는 하나의 미디어 스트림의 형태로 이용가능한 경우로 용이하게 전이가능하다. 이러한 경우, 도 8의 라디오 리소스 관리자(30)의 동작 모드는 다음과 같이 후술될 수도 있다.

LTE RRM 엔티티(30)는 ?K 패킷 검사(50)를 사용하여, 특정한 사용자에 의해 요청된 MPD(46)를 검사한다. 이용가능한 라디오 리소스들에 의존하여, LTE 스케줄러(30)는 주어진 사용자에 의해 요청된 대역폭 양을 평가한다. 요청된 대역폭이 주어진 SVC 또는 MVC 계층에 대한 이용가능한 대역폭을 초과하면, LTE RRM 엔티티(30)는 W3C HTTP 상태 코드를 그 사용자(40)에게 전송하도록 HTTP DASH 서버(42)를 트리거링할 수 있다. DASH 클라이언트(40) 내의 SVC/MVC 디코더(70)는 에러 상태 코드를 수신하며, 더 낮은 대역폭을 요구하고 그에 따라 LTE 시스템 상에서 라디오 리소스들을 절약하는 더 낮은 SVC 또는 MVC 계층을 자동적으로 요청한다.

라디오 리소스들은, 주어진 사용자의 불량한 채널 품질로 인해 또는 리소스들을 요청하는 다른 사용자들의 양으로 인해 제한될 수 있다. LTE RRM(30)은 리소스들을 희생하도록 양호한 채널 품질을 갖는 사용자들에게 강제할 수 있으며, 그 후, 그 리소스들은 더 불량한 채널 품질 하에서 고통을 받는 사용자들에게 할당될 수 있다.

LTE RRM(30) 내의 우선순위 정책에 의존하여, RRM(30)은 가장 낮은 SVC/MVC 계층, W3C HTTP 상태 코드들(80)을 트리거링하는 것을 통해 더 높은 SVC/MVC 계층들의 HTTP 요청들을 허용하기 전에는 기본 계층의 서비스 전달을 용이하게 하기 위해 MPD(46)를 사용할 수 있다.

HTTP DASH 서버(42)는 다음의 W3C HTTP 상태 코드들 중 하나를 송신할 수도 있다:

*● 404 발견되지 않음

*● 466 스트리밍 레이트 초과됨(RFC 내의 tbs.)

● 503 서비스 이용가능하지 않음

● 509 대역폭 제한 초과됨

본 출원의 다음의 실시예를 설명하도록 앞쪽으로 진행하기 전에, 도 7에 도시된 바와 같은 사용자 엔티티(34)의 일반적인 구조가 일반적으로, 리소스 관리자(74)를 제거할 경우 모든 다른 실시예들에 또한 적용가능함을 유의해야 한다. 미디어 재생기(76)는 서버(42)로부터 수신된 미디어 콘텐츠(44)를 디코딩할 수 있는 미디어 디코더일 수도 있다. 클라이언트(40) 및 미디어 재생기(76)는 서로 커플링될 수도 있고, 서로에 통신할 수도 있다. 미디어 재생기는 심지어 클라이언트(40) 내에 부분적으로 통합될 수도 있다.

도 3 내지 도 5의 실시예에 따르면, 개별 사용자 엔티티들에 할당된 통신 리소스들, 및 특히 할당 그 자체는, 미디어 프리젠테이션 설명의 검사의 결과에 의존하여 적응되었다. 도 6 내지 도 8의 후속 실시예들에 따르면, 클라이언트로부터 서버로 전송된 미디어 요청들에 관련된 클라이언트와 서버 사이의 데이터 트래픽의 일부는, 기지국들 통신 리소스들의 더 효율적인 활용을 달성하기 위해, 또는 사용자 엔티티들로의 기지국 통신 리소스들의 더 공평한 분배를 획득하기 위해 영향을 받았다. 양자의 실시예들에 따르면, 라디오 리소스 관리자(30)는, 후속하여 설명되는 구현 예에 따른 물리 계층 상에서의 LTE 폐쇄-루프 피드백을 또한 고려할 수 있다. 즉, 다음의 구현 가능성은, 도 5 및 도 8의 구현 예들의 더 상세한 설명을 나타내도록 의미된다. 즉, 본 발명의 구현 가능성에 따르면, 라디오 리소스 관리(RRM) 스케줄러(30)는, 미디어 콘텐츠(44)의 어느 비디오 표현 또는 버전이 DASH 클라이언트에 대해 최상으로 적합한지를 결정하기 위한 LTE EMB(32)에서의 결정을 위해 LTE의 물리 계층으로부터의 LTE 폐쇄-루프 피드백을 고려한다. 또한, 도 3의 실시예 및 도 5의 구현에 따르면, 리소스 관리자(30)는, 각각의 표현이 전용되는 각각의 클라이언트들(40)에 통신 리소스들을 그에 따라 할당함으로써 간접적으로 가장 적절한 표현 또는 버전의 다운로드를 획득하기를 추구한다. 하지만, 도 6의 실시예 및 도 8의 구현에 따르면, 라디오 리소스 관리자(30)는 상술된 바와 같이 클라이언트 미디어 요청들에 적절히 영향을 줌으로써 클라이언트에 의한 최상으로 적절한 표현의 다운로드에 도달하기를 추구한다.

RRM 유닛(30)은, 예를 들어, 미디어 콘텐츠(44)의 AVC 세그먼트들의 상이한 표현들 사이에서 (H.264/)SVC 계층들을 선택할 경우 또는 (H.264/)MVC의 경우에서 2D 또는 3D 비디오 전달 사이에서 결정할 경우 LTE 폐쇄-루프 피드백을 고려한다. LTE eNB RRM(30)은, 도 3 및 도 5의 경우에서 특정한 비디오 세그먼트들에 대해 특정된 파라미터들로 RRM 파라미터들을 조정하고, 도 6 및 도 8의 경우에서 HTTP 세트 요청들에 영향을 주도록 MPD(46)를 검사할 수도 있다.

UE(40)는, 라디오 채널의 품질 메트릭들, 소위 채널 품질 피드백(CQI) 뿐만 아니라 비디오 버퍼의 버퍼 레벨들(표 3 참조)을 eNB RRM 엔티티(30)에 시그널링할 수도 있다. 피드백 정보는, 주기적인 또는 비주기적인 시간 기반으로 피크 투 평균비(PAR), 예를 들어, 피크 투 평균 레이트 비(RARR) 표시자를 전송함으로써 감소될 수도 있다. 이러한 정보를 이용하여, eNB RRM 엔티티(30)는 HTTP 스트리밍 서비스들에 대한 버퍼 인식으로 멀티-사용자 스케줄링을 수행할 수 있다.

PAR 및/또는 PARR의 계산을 위해 사용될 물리 계층(PHY) 데이터의 채널 품질 메트릭은 LTE 표준 내에서 정의된 바와 같은 다음의 파라미터들 중 하나 또는 임의의 결합을 수반할 수도 있다:

*● CQI: 채널 품질 표시자

● RI: 랭크 표시자

● PHY 계층 데이터 레이트

● PHY 계층 지연 및 지터

● RSRP: 기준 신호 수신 전력

● RSSI: 수신 신호 강도 표시자

● RSRQ: 기준 신호 수신 품질

여기서, RSRQ는,

에 의해 정의되며, 여기서, N은 RSSI 값이 측정되었던 리소스 블록들의 수이다.

상기-서술된 구현 세부사항으로부터 명백해질 바와 같이, 도 3 및 도 6의 라디오 리소스 관리자들(30)은 각각, 클라이언트의 사용자 엔티티들에 의해 기지국으로 전송된 바와 같은 물리 계층 상에서의 폐쇄-루프 피드백을 이용할 수 있다. 그것은, 전송기 측 상의 시스템이 비디오 전달을 개선시키기 위해 크로스-계층 정보에 의존할 수 있는 반면, 수신기 측은 임의의 크로스-계층 인터페이스들을 필요로 하지 않는다는 것을 의미한다. 또한, RRM은 채널에 기초하여, 얼마나 더 많은 대역폭이 그의 비디오 품질을 개선시키기 위해 하나 또는 그 초과의 클라이언트들에 할당될 수 있는지를 추정할 수 있다.

예를 들어, 도 3 및 도 6의 RRM(30)은, 사용자 엔티티들에 할당된 평균 대역폭을 결정하고, 결정된 평균 대역폭으로부터, 미디어 프리젠테이션 설명(46)로부터의 미디어 콘텐츠(44)의 어느 버전이 (44)와 같은 각각의 클라이언트들에 의해 현재 다운로딩되는지에 관해 예측하도록 구성될 수 있다. 이것은, 클라이언트의 상태를 발견하기 위한 간단한 방식을 형성한다. 각각의 클라이언트에 대해, RRM(30)은 단지, 각각의 클라이언트(40)가 수신하고 있는 평균 대역폭을 식별하고, 그로부터 RRM(30)이 어느 미디어 레이트를 선택할 수도 있는지를 예측해야 한다.

또한, 상기 약술된 바와 같이, 라디오 리소스 관리자(30)가 미디어 버퍼링 상태 정보, 즉 각각의 사용자 엔티티에서 동작하는 클라이언트의 버퍼링 상태의 종류를 표시하는 정보를 도출하기를 시도하는 것이 가능할 수 있다. 즉, 라디오 리소스 관리자(30)는, 각각의 사용자 엔티티가 할당된 대역폭을 효율적으로 정확히 실제로 수신할 수 있는지에 관해 확인하기 위해 사용자 엔티티들(34)의 수신 조건에 관한 정보를 활용할 수 있다. 이러한 정보를 사용하여, 라디오 리소스 관리자(30)는, 상술된 바와 같이 미디어 프리젠테이션 설명(46)으로부터의 라디오 리소스 관리자(30)에 액세스가능한 최소 대역폭 정보를 고려함으로써, 사용자 엔티티들에서 동작하는 클라이언트들의 버퍼링 상태를 에뮬레이팅할 수 있다. 이러한 측정에 의해, 라디오 리소스 관리자(30)는, 사용자 엔티티들(34) 상에서 구동하는 클라이언트들(40)의 버퍼링 상태들을 에뮬레이팅 또는 시뮬레이팅하고, 그로부터 클라이언트의 작동 및 클라이언트의 속성들 추론할 수 있다. 예를 들어, 시뮬레이션이 버퍼가 미디어 데이터로부터 지나간다는 것을 나타내는 클라이언트들(40)은, 시뮬레이션이 버퍼가 풀이라는 것을 나타내는 클라이언트들(40)보다 더 높은 우선순위를 할당받을 수도 있다.

자연적으로, 버퍼링 상태를 시뮬레이팅하거나, 클라이언트(40)와 각각의 서버 사이의 데이터 트래픽으로부터 미디어 버퍼링 상태 정보를 도출하는 상술된 가능성은, 매우 계산적으로 복잡하며, 획득된 정확도는 낮을 수도 있다.

따라서, 도 3의 실시예는, (현재의 리소스 상황 정보에 부가하여) 미디어 프리젠테이션 설명(46)에 의존할 뿐만 아니라, 각각의 클라이언트 또는 클라이언트들(40)이 동작하는 각각의 사용자 엔티티들로부터의 채널 품질 피드백으로부터 도출되는 미디어 버퍼링 상태 정보에 의존하여, 라디오 리소스 관리자(30)가 사용자 엔티티들에 기지국(32)의 통신 리소스들을 할당하도록 또한 구성될 수 있는 방식으로 확장될 수도 있다. 특히, 도출된 미디어 버퍼링 상태 정보는, 각각의 사용자 엔티티(34)의 추정된 유효 비트 레이트를 사용하여 충진(fill)지고, 미디어 프리젠테이션 설명(46)에서 표시된 프리젠테이션 대역폭으로 입력되는 각각의 사용자 엔티티들의 클라이언트(40)의 버퍼를 시뮬레이팅하는 상술된 시뮬레이션에 의해 도출될 수도 있다.

물론, 동일한 것이 도 6의 라디오 리소스 관리자(30)에 관해 지칭될 수도 있다. 즉, 시뮬레이션 결과는, 사용자 엔티티들의 클라이언트들(40)의 미디어 요청들의 영향에 대해 결정하기 위하여 라디오 리소스 관리자(30)에 의해 사용될 수도 있다.

추가적으로, 도 7의 실시예는 또한, 그 의미로 확장될 수도 있다. 즉, 도 7의 리소스 관리자(74)는, 클라이언트의 미디어 버퍼 상태를 시뮬레이팅하고, 그에 따라, 무선 통신 커뮤니티(community)의 일부로서, 2개의 탐욕스러운(greedy) 클라이언트들(40)에 대해 기지국 통신 리소스들을 보호하도록 작동하기 위해 현재의 리소스 상황 정보를 사용할 수도 있다.

그러나, 상술된 바와 같이, 클라이언트들의 버퍼링 상태의 "시뮬레이션"은 높은 정도의 불확실도의 주제(subject)일 수도 있으며, 따라서, 도 3 및 도 6의 실시예들은, 라디오 리소스 관리자(30)가 사용자 엔티티들의 클라이언트의 버퍼링 상태를 도출 또는 시뮬레이팅할 필요는 없지만, 대신 라디오 리소스 관리자(30)가 클라이언트(40)로부터의 데이터 트래픽 내의 명시적인 미디어 버퍼링 상태 정보를 활용하도록 하는 방식으로 정정될 수도 있다. 클라이언트(40)로부터 서버(42)로의 데이터 트래픽 내의 미디어 프리젠테이션 설명(46) 및 미디어 버퍼링 상태 정보에 기초하여, 라디오 리소스 관리자(30)는, 더 정확한 버퍼링 상태 추정때문에 통신 리소스 할당을 더 정확하게 수행할 수 있다. 클라이언트(40)로부터의 데이터 트래픽 내의 미디어 버퍼링 상태 정보에서, 후자는 현재의 미디어 버퍼링 상태, 즉 현재의 미디어 버퍼의 충진 레벨을 명시적으로 표시할 것이다. 구체적인 구현 가능성은 더 상세히 후술된다.

그러나, 대안적인 실시예에 따르면, 도 3의 라디오 리소스 관리자(30)는, 클라이언트(40)로부터의 데이터 트래픽 내의 미디어 버퍼링 상태 정보에 의존하지만 미디어 프리젠테이션 설명(46)에 대한 의존성 없이, 사용자 엔티티들로의 기지국(32)의 통신 리소스들의 할당을 대안적으로 수행할 수 있다. 수 개의 사용자 엔티티들의 클라이언트들(40)의 미디어 버퍼링 상태들을 단지 조사하는 것은, 라디오 리소스 관리자(30)가 사용자 엔티티들로의 이용가능한 기지국 통신 리소스들의 더 공평한 분배를 획득할 수 있게 할 것이다.

따라서, 도 3은 또한, 사용자 엔티티들 중 하나에서 동작하는 클라이언트의 미디어 버퍼링 상태 정보에 의존하여 사용자 엔티티들(34)로의 기지국(32)의 통신 리소스들을 할당하도록 구성된 라디오 리소스 관리자(30)에 관한 것이다. 사용자 엔티티들로의 통신 리소스들의 할당은, 기지국(32)의 통신 리소스들이 적절한 비율로 할당되어야 하는 사용자 엔티티들(34)의 수, 사용자 엔티티들과 기지국 사이에서 교환될 통신 데이터의 종류 등과 같은 상술된 가능성들 중 하나 또는 그 초과에 기초하여, 추가적으로 수행될 수 있다. 추가적으로, 통신 리소스들을 사용자 엔티티들에 할당할 시에, 상술된 셋팅은, 미디어 버퍼링 상태 정보, 즉 서브캐리어들, 시간 슬롯들, 및 기지국 셀의 공간 커버리지에 의존하여 조정될 수 있다. 상술된 바와 같이, 미디어 버퍼링 상태 정보는 클라이언트(40)로부터 서버(42)로의 데이터 트래픽 내의 명시적인 시그널링화(signalization)로부터 도출될 수 있거나, 미디어 버퍼링 상태 정보는, 사용자 엔티티(34)로부터 기지국(32)으로의 채널 품질 피드백에 기초하여 사용자 엔티티의 버퍼링 상태를 시뮬레이팅함으로써 도출될 수 있다.

후자의 가능성은 또한 도 6 및 도 7의 실시예에 관련된다. 현재의 리소스 상황 정보 및 미디어 프리젠테이션 설명(46)을 사용하는 것 대신, 도 6 및 도 8의 각각의 라디오 리소스 관리자(30) 및 리소스 관리자(74)는, 클라이언트(40)로부터의 데이터 트래픽 내의 미디어 버퍼링 상태 정보에 의존하여 미디어 요청(60)을 핸들링하는 방식에 관한 결정을 수행하도록 구성될 수 있다.

따라서, 상기 실시예들은 또한, 서버(42)로부터 사용자 엔티티(34)에서 동작하는 데이터 트래픽 내의 상이한 대역폭들의 미디어 콘텐츠(44)의 버전들을 설명하는 미디어 프리젠테이션 설명(46)을 검사하고; 미디어 콘텐츠(44)의 원하는 버전을 요청하는, 클라이언트(40)로부터 서버(42)로의 미디어 요청(60)을 검사하고; 클라이언트(40)로부터 미디어 버퍼링 상태 정보를 수신하며; 그리고, 미디어 버퍼링 상태 정보 및 미디어 프리젠테이션 설명(46)에 의존하여, (1) 미디어 요청(60)을 서버에 포워딩하거나, 대안적으로는 (2) 변경된 미디어 요청이 더 적은 대역폭의 미디어 콘텐츠(44)의 버전을 요청하는 정도로 미디어 요청(60)을 변경시키거나, 미디어 요청(60)을 인터셉트하고, 서버(42)로부터 클라이언트(40)로 비-이용가능도 응답을 다시 전송하도록 서버(42)를 에뮬레이팅하거나 서버(42)에 명령하도록 결정하도록 구성된 리소스 관리자를 나타낸다.

도 3, 도 6 및 도 7의 대안적인 설명으로서 상술된 바와 같은 실시예에 대한 가능한 구현이 다음에 설명된다. 이러한 더 상세한 구현은, "오버 더 탑(OTT)으로 폐쇄-루프 피드백을 갖는 LTE 위의 DASH"로 지칭될 수 있다. 이러한 구현 가능성에 따르면, 클라이언트의 BufferLevel, 예를 들어, 표 3에 정의된 바와 같은 BufferLevel과 같은 품질 메트릭은, 오버 더 탑으로 직접적인 클라이언트 피드백을 사용하여 LTE 시스템의 DPI-스케줄러(30)에서 더 정밀하게 추적된다.

버퍼 레벨들에 대한 품질 메트릭들

키			타입	설명
BufferLevel			리스트	일반적인 속도의 플레이아웃 동안의 버퍼 점유 레벨 측정들의 리스트
	엔트리		오브젝트	하나의 버퍼 레벨 측정
		T	실시간	버퍼 레벨의 측정의 시간
		레벨	정수	밀리초의 버퍼의 레벨. 모든 활성 미디어 컴포넌트들의 미디어 데이터가 현재의 플레이아웃 시간으로부터 시작하여 이용가능한 플레이아웃 지속기간을 표시함

가능한 결과적인 구현이 도 9에 도시되어 있다. 도 9의 구현을 도 5의 구현 가능성과 비교함으로써, 도 5의 구현이 사용자 엔티티(34)로부터 RRM(30)으로의 LTE 피드백(90)에 의해 확장됨이 명확하며, 여기서, 후자, 즉 RRM(30)은 더 양호한 통신 리소스 레이트 할당 R을 수행하기 위해 LTE 피드백, 즉 사용자 엔티티(34)로부터의 채널 품질 피드백을 사용한다.

다음으로, 상기 실시예들에 관해, 실시예의 클라이언트(40)에 관한 몇몇 가능한 구현 세부사항들이 설명된다. 상기 표시된 바와 같이, 클라이언트의 작동은 각각의 클라이언트 이슈어(issuer)에 의해 셋팅되도록 자유로우며, 따라서, 상기 실시예들은 클라이언트의 작동의 설명에 많은 부담을 놓지 않는다. 한편, 상기 약술된 실시예들의 완전한 이해를 증가시키기 위해, 클라이언트가 DASH 클라이언트라고 가정함으로써, 가능한 클라이언트 작동이 후술된다.

[ISO/IEC 23009-1]에서 정의된 바와 같은 DASH는 클라이언트-구동된 적응 기술이지만, 그것은 클라이언트 작동을 특정하지 않으며, 상이한 구현들에 대해 완전하게 자유롭다. 그러나, 클라이언트들에 의해 리포팅된 MPD 및 QM은, 클라이언트 작동이 예측될 수 있는 몇몇 중요한 정보를 포함한다. 이러한 중요한 정보는 다음의 시그널링을 참조한다.

● @minBufferTime

● @bandwidth

● 충분한 데이터가 이용가능하면, TCP 스루풋으로서 클라이언트에 의해 측정가능한 암시적인 할당된 LTE 클라이언트 레이트

● 의도된 플레이-아웃 지연/잠재적인 정전(outage)들에 의존하여 클라이언트가 TCP 스루풋에 적응함

● 클라이언트에 의해 리포트팅 QM

● 비트스트림 스위칭 플래그

DASH 클라이언트의 목적은, 그의 장비 특징들에 기초하여 그것이 지원할 수 있는 가장 높은 품질로, 스트리밍된 콘텐츠를 연속적으로 플레이하는 것이다. 연속적으로 플레이하기 위해, 클라이언트들의 버퍼는 임의의 시간에 비워지지 않아야 한다. MPD내의 @minBufferTime는, 데이터의 그러한 양이 세션의 시작부에서 그들의 버퍼들에 저장될 경우, 그들이 @bandwidth에서 표시된 값만큼 적어도 그렇게 높은 레이트로 다운로딩하면, 그들이 @bandwidth를 갖도록 시그널링된 비디오 버전을 플레이할 수 있다는 것을 클라이언트들에게 약속(promise)한다. 따라서, 비디오의 플레이-아웃을 시작하기 전에 클라이언트들이 적어도 그렇게 많은 데이터를 사전-버퍼링하며, 그들의 버퍼 충진에서의 변화들이 @minBufferTime에 관한 그의 크기에 기초하여 발생할 경우, 상이한 @bandwidth를 갖는 상이한 버전의 비디오로 스위칭하는 것이 기대된다. 클라이언트들의 버퍼 충진이 기지국에 알려지지 않고, 그것을 추정하는 것이, 예를 들어, 트릭 모드들이 사용된 경우 어렵거나 부정확할 수도 있으므로, 사용자들(특히, 상술된 QM)로부터의 QM 리포트들은 사용자 작동을 예측하기 위한 유용한 툴일 수도 있다.

또한, DASH 클라이언트는 도 7에 도시된 바와 같이, 도 10에 도시된 바와 같은 2개의 컴포넌트들, 즉 DASH 액세스 클라이언트(40a) 및 MPEG 미디어 엔진(40b)로 로지컬적으로 분리된다.

● DASH 액세스 클라이언트(40a): 이러한 엔티티는, MPD(46)를 파싱(parse)하는 것을 담당하여, 스케줄링 알고리즘을 수행하고, 미디어(64)를 포맷(92)으로 MPEG 미디어 엔진(40b)에 파싱한다

● MPEG 미디어 엔진(40b): 이러한 엔티티는 미디어 데이터(92)를 프로세싱, 즉 디코딩, 재구성 등을 행하는 것을 담당한다

도 7의 상기 설명을 참조하면, 사용자 엔티티 및/또는 클라이언트의 상술된 바람직한 기능들 중 임의의 기능을 이용하는 향상된 DASH 클라이언트를 구현하기 위한 2개의 가능한 옵션들이 존재한다. 이들 가능성들은 다음과 같다.

● 크로스-계층 DASH 액세스 클라이언트를 갖는 것: 크로스-계층 클라이언트는, 물리 계층으로부터의 측정들을 취하고, 가급적, LTE 네트워크로부터 부가적인 시그널링을 수신한다. 이러한 부가적인 지능(intelligence)을 사용하여, 채널의 더 양호한 추정 및 향상된 적응 스케줄링이 수행될 수 있다.

● 그러나, 통상적으로 이미 구현된 DASH 클라이언트들이 예견되며, 여기서, 적응은, 브라우저에서의 DASH 클라이언트의 구현을 위한 인스턴스에 관하여, 예를 들어, 클라이언트 버퍼 레벨들, 또는 주어진 데이터의 양으로 다운로딩하기 위해 필요한 시간 등을 모니터링함으로써, 상위 계층들에서 발생한다. 이러한 경우, 하나의 가능성은, 적응을 처리하는 외부 "미디어 관리자" 컴포넌트(도 8 및 도 9 참조)를 갖는 것이다. 상술된 것과 유사하지만, DASH 클라이언트는 이를 인식하지 못할 것이다. 이러한 "복제된" DASH 액세스 클라이언트(그 DASH 액세스 클라이언트는 또한 적응을 수행함)를 회피하기 위해, 부가적인 시그널링이 MPD 레벨에서 필요하며: 적응이 "리소스 관리자"(74)에 의해 DASH 클라이언트, 즉 수신기 디바이스로부터 수행된다는 것을 DASH 액세스 클라이언트에게 표시할 새로운 속성, 예를 들어, @automaticSwitching이 부가될 수도 있다. MPD에 포함된 @automaticSwitching은, 서버 또는 중간의 임의의 디바이스가, 선택되고 요청된 표현에 따른 비디오의 프로파일 및 레벨에 부합하는 비디오 레이트를 조정할 수도 있으며, 따라서, 클라이언트가 임의의 미디어 레이트 적응을 행하지 않아야 한다는 것을 클라이언트에게 표시한다.

제 2 경우, 예컨데 "리소스 관리자"가 도 11에 도시되어 있다. 도 11로부터 관측될 수 있는 바와 같이, 리소스 관리자(74)는, 상술된 리소스 관리자로서 작동하기 위해, 클라이언트/서버 데이터 트래픽과 비교하여 하위 OSI 계층에서 데이터(100)를 사용한다.

특히, 리소스 관리자(74)는 미디어의 적응 및 요청들을 수행할 수 있거나, 또한, DPI를 수행하고 사용자의 요청들을 변경시킬 수 있거나, 기타 등등을 행할 수 있다. 또한, "미디어 관리자"는, 그것이 일반적인 DASH 클라이언트에서 행해질 수 있는 것보다 더 지능적인 적응을 수행하기 위해, 물리 계층 정보 및 리소스 할당에 관한 몇몇 부가적인 시그널링 메시지들을 RRM과 교환할 수 있으며, 여기서, 상위 계층들의 정보만이 사용된다.

도 6 및 도 7의 실시예 및 도 8과 같은 대응하는 구현들에 관해, 이들 도면들에 도시된 실시예들이, 더 양호한 리소스 관리를 산출하기 위해, 미디어 요청 영향이 미디어 설명 프리젠테이션 영향으로 대체되는 대안적인 실시예를 초래하기 위한 대안적인 방식으로 구현될 수도 있음을 유의해야 한다. 그러나, 이들 도면들에 관한 상술된 기능 및 아래에 약술되는 기능의 결합도 사용될 수도 있다.

특히, 설명된 바와 같은 도 6의 대안적인 실시예에 따르면, 라디오 리소스 관리자(30)는 사용자 엔티티(34)에서 동작하는 클라이언트로부터 서버(42)로의 미디어 프리젠테이션 설명 요청을 검사하도록 구성되며, 미디어 프리젠테이션 설명 요청은 서버(42)로부터 미디어 프리젠테이션 설명(46)을 요청한다. 그 후, 리소스 관리자(30)는, 서버(42)로부터 클라이언트(40)로의 데이터 트래픽 내에서 미디어 프리젠테이션 설명(46)을 검사하고, 현재의 리소스 상황 정보 및 미디어 프리젠테이션 설명(46)에 기초하여 결정하며, 후자의 옵션이 사용되어야 한다: 1) 미디어 프리젠테이션 설명 요청에 대한 대답으로서 미디어 프리젠테이션 설명(46)을 클라이언트(40)에 포워딩하는 것, 즉 미디어 프리젠테이션 설명(46)을 변경되지 않게 유지하는 것, 또는 2) 미디어 프리젠테이션 설명(46)을 인터셉트하여, 미디어 프리젠테이션 설명(46)을 감소시켜서, 상이한 대역폭들의 미디어 콘텐츠(440의 버전들의 적절한 세트만을 설명하고, 미디어 프리젠테이션 설명 요청에 대한 대답으로서 감소된 미디어 프리젠테이션 설명(46)을 클라이언트(40)에 전송하는 것. 또한, 라디오 리소스 관리자(30)가 미디어 콘텐츠의 요청된 버전을 그의 더 낮은 대역폭 버전으로 변경시키도록 클라이언트(40)에게 직접 명령하지는 않지만, 미디어 프리젠테이션 설명(46)의 감소로 인한 그러한 더 낮은 대역폭 버전을 참조하기 위해 클라이언트(40)가 미디어 콘텐츠(44)에 대한 추가적인 미디어 요청들을 변경시킬 가능성이 매우 높다.

또한, 상술된 기능은, 사용자 엔티티들로부터 기지국을 넘어서 발생하는 라디오 리소스 관리자(30) 뿐만 아니라 사용자 엔티티 그 자체 내에서 발생하는 도 7의 리소스 관리자(74)에 대해 유효하다. 도 7에 관해 상술된 모든 상기 가능한 구현 세부사항들은 또한, 도 6 및 도 7의 각각의 상기-약술된 대안적인 실시예에 적용가능하다.

따라서, 도 6 및 도 7은 또한, 사용자 엔티티(34)에서 동작하는 클라이언트(40)로부터 서버(42)로의 미디어 프리젠테이션 설명 요청을 검사하고 － 미디어 프리젠테이션 설명 요청은 서버(42)로부터 미디어 프리젠테이션 설명(46)을 요청하고, 미디어 프리젠테이션 설명(46)은 상이한 대역폭들의 미디어 콘텐츠(44)의 버전들을 설명함 －; 서버(42)로부터 클라이언트(40)로의 데이터 트래픽 내에서 미디어 프리젠테이션 설명(46)을 검사하고; 현재의 리소스 상황 정보 및 미디어 프리젠테이션 설명(46)에 기초하여, (1) 미디어 프리젠테이션 요청에 대한 대답으로서 미디어 프리젠테이션 설명(46)을 클라이언트(40)에 포워딩하거나 (2) 미디어 프리젠테이션 설명(46)을 인터셉트하고 그것을 변경시키도록 결정하도록 구성된 리소스 관리자를 나타낸다.

예를 들어, 인터셉트 및 변경은, 리소스 관리자가, 상이한 대역폭들의 미디어 콘텐츠(44)의 버전들의 적절한 서브세트만을 설명하기 위해 미디어 프리젠테이션 설명(46)을 감소시키고, 미디어 프리젠테이션 설명 요청에 대한 대답으로서 감소된 미디어 프리젠테이션 설명을 클라이언트(40)에 전송하는 것을 수반할 수 있다. 예를 들어, 후술되는 명시적인 버퍼 상태 정보와 같은 품질 메트릭들을 서버(32) 대신 RRM(30)에 전송하거나, 프로토콜 변화, 즉, 또한 더 상세히 후술되는 바와 같이 유니캐스트로부터 멀티캐스트로의 프로토콜 변화를 표시하도록 클라이언트(40)에 명령하기 위해; 또는, 중간의 디바이스, 즉 리소스 관리자 그 자체가 클라이언트(40)에 의해 요청된 미디어(44)의 조정들을 행하지 않을 수도 있다는 것을 클라이언트(40)가 알게 하여서, 클라이언트(40)가 레이트를 조정하지 않게 하기 위해, 클라이언트(40)로의 피드백으로서 사용될 정보를 MPD(46)에 부가하는 것이 또한 가능할 수 있다. 자연적으로, 프로토콜 변화 표시는, 표시된 프로토콜 변화에 대응하는 프로토콜 변환을 수행하거나, 서버(32)와 같은 다른 것이 그 프로토콜 변환을 수행하게 함으로써 RRM(30)에 의해 수행될 수도 있다.

미디어 요청들에 영향을 주는 경우에서와 같이, 리소스 관리자는, 미디어 콘텐츠(44)의 원하는 버전으로서 그와 연관된 더 낮은 최소 대역폭을 갖는 미디어 콘텐츠(44)의 버전을 미디어 프리젠테이션 설명(46) 내에서 식별하기 위해, 미디어 프리젠테이션 설명(46)을 검사하도록 구성될 수도 있으며, 여기서, 라디오 리소스 관리자는, 그와 연관된 더 낮은 최소 대역폭을 갖는 그러한 버전이 존재하면, 현재 리소스 상황 정보에 의존하여 결정을 수행하도록 구성된다. 리소스 관리자는 라디오 리소스 관리자일 수도 있으며, 클라이언트가 동작하는 사용자 엔티티가 속하는 사용자 엔티티들로의 기지국의 통신 리소스들의 할당을 수행하도록 추가적으로 구성된다. 그러나, 리소스 관리자는 대안적으로, 그의 트랜시버 스테이지(70)와 클라이언트(40) 사이의 사용자 엔티티 내에 배열될 수도 있으며, 여기서, 리소스 관리자는, 트랜시버 스테이지(70)로부터 현재의 리소스 상황 정보를 획득하도록 구성된다. 추가적으로, 리소스 관리자는, 현재의 리소스 상황 정보에 의해 포함되는 사용자 엔티티로부터 기지국으로의 채널 품질 피드백에 기초하여 사용자 엔티티의 버퍼링 상태를 시뮬레이팅하고, 사용자 엔티티의 버퍼링 상태에 의존하여 결정을 수행하도록 구성될 수도 있다.

다음으로, 상기 약술된 실시예들에 관한 가능한 구현 세부사항들이 설명되며, 이들 세부사항들은, DASH 푸쉬(push) 서비스의 형태로 미디어 데이터의 스트리밍을 실현하기 위한 가능성에 관련된다.

LTE를 통한 DASH 서비스들은 소위 푸쉬 서비스들에 의해 향상될 수 있다. 예를 들어, 도 12를 참조한다. 2개의 가능한 접근법들이 존재한다:

1. HTTP 서버 푸쉬

○ DASH 클라이언트(46)는 HTTP 서버(42)에 접속하며, 그 서버는 차례로, TCP/서비스 핸드쉐이크 및 터널 셋업을 수행한다.

○ 그 후, 서버(42)는 DASH 클라이언트(40)에 비디오 데이터를 푸쉬한다.

2. LTE 프록시 푸쉬

○ DASH 클라이언트(40)는, TCP/서비스 핸드쉐이크 및 터널 셋업을 수행하는 LTE eNB 내의 LTE 프록시 서버에 접속한다.

○ LTE RRM 엔티티(30)는, HTTP 서버(42)로부터 미디어 데이터 표현을 리트리브(retrieve)하기 위해 HTTP 획득을 사용한다.

○ LTE RRM(30)은 비디오 데이터를 DASH 클라이언트(12)에 푸쉬한다.

푸쉬 정보는 MPD 내에서 특정될 수도 있으며, 푸쉬 표현으로 지칭된다. SVC 또는 MVC의 경우, 이러한 정보는 DASH 클라이언트에 푸쉬될 계층들을 포함할 수 있다. 여기서, MPD(46)는 잠재적인 레이트 스위치에 관해 eNB RRM(30)에 통지하므로, 라디오 리소스들의 사용은 또한 다른 사용자들에 대해 최적화될 수 있다. 예를 들어, LTE 프록시 푸쉬의 경우, LTE RRM(30)은, 다른 사용자들에 대한 리소스들을 절약하기 위해 더 낮은 품질 및 더 낮은 레이트 요건을 갖는 서비스를 푸쉬하도록 결정할 수 있다.

즉, 기지국은, 상기 실시예들 모두에서 프록시 푸쉬 프로세싱을 수행하기 위한 사이트로서 서빙할 수도 있다. 더 명확하게 하기 위해, 라디오 리소스 관리자는 그러한 사이트로서 서빙할 수도 있다.

도 6의 실시예의 추가적인 대안적인 설명이 프리젠테이션되며, 여기서, 다음의 대안적인 설명은, 후술되는 라디오 리소스 관리자의 기능이, 클라이언트와 서버 사이의 데이터 트래픽에 동일하게 영향을 주는 라디오 리소스 관리자(30)의 상술된 공간 기능을 대체할 수도 있거나, 라디오 리소스 관리자(30)의 부가적인 기능을 표현할 수도 있도록 이해되어야 한다.

임의의 경우, 다음에 설명되는 실시예에 따르면, 도 6의 라디오 리소스 관리자(30)는, 사용자 엔티티들(34)에 기지국(32)의 통신 리소스들을 할당하는 것 이외에도, 데이터 트래픽 내에 공통적인 미디어 콘텐츠에 관한 미디어 프리젠테이션 설명들(46)이 존재하는지에 관해 체크하기 위해, 수 개의 사용자 엔티티들(34)에서 동작하는 클라이언트들(40)과 하나 또는 수 개의 서버들(42) 사이의 데이터 트래픽을 검사하도록 부가적으로 구성된다. 그 후, 체크에 의존하여, 라디오 리소스 관리자는, (1) 미디어 콘텐츠(44)의 유니캐스트 버전들 이외에도, 공통적인 미디어 콘텐츠의 멀티캐스트 버전을 클라이언트들(40)에 제공하거나 (2) 공통적인 미디어 콘텐츠(44)를 다운로딩하는 클라이언트들(40)에 대한 프로토콜의, 유니캐스트 프로토콜로부터 멀티캐스트 프로토콜로의 변화를 야기하도록 결정한다.

그러나, 상술된 기능은 또한, 사용자 엔티티들로의 기지국 통신 리소스들의 할당을 수행하는 것을 담당하는 도 6에 도시된 라디오 리소스 관리자(30) 외부에 또는 그 라디오 리소스 관리자(30)로부터 분리된 라디오 리소스 관리자 내에서 수행될 수도 있다. 클라이언트들과 서버들 사이의 데이터 트래픽의 조사 및 각각의 미디어 프리젠테이션 설명 요청들에 의해 클라이언트들 중 1개 초과에 의하여 공통적으로 지시된 미디어 프리젠테이션 설명들이 존재하는지에 관한 체크는, 할당 프로세싱과는 독립적으로 수행될 수도 있다. 결과적인 이점은, 각각의 클라이언트들(40)이 수신될 유니캐스트 버전으로부터 동일한 콘텐츠의 멀티캐스트 버전들로 스위칭하는 결과를 고려할 경우 용이하게 이해가능하다. 스위칭은, 다른 클라이언트들에 대한 필요한 비트 레이트가 하나의 스트리밍만으로 붕괴될 수도 있다는 사실로 인해, 이들 클라이언트들에 대해 더 이용가능한 비트 레이트를 산출한다.

본 발명의 실시예에 따른 라디오 리소스 관리자가 실제로 옵션들 (1) 및 (2)를 수행하도록 구성되거나 수행할 수 있도록, 양자의 옵션들의 대안적인 설명이 이해되지 않을 것이라고 말하지 않으면서 본 발명이 진행한다. 오히려, 라디오 리소스 관리자는 체크의 결과에 기초하여, 옵션들 1 또는 2 중 임의의 옵션이 트리거링되어야 하는지 아닌지에 관해 결정한다. 더 명확하게 하기 위해, 라디오 리소스 관리자는, 하나 또는 수 개의 서버들로부터 클라이언트들 중 상이한 클라이언트로의 데이터 트래픽 내에 공통적인 미디어 콘텐츠(44)에 관한 미디어 프리젠테이션 설명들이 존재하지 않는 경우, 클라이언트들(40)과 서버들(42) 사이의 데이터 트래픽을 변경되지 않게 유지한다. 이러한 경우, 옵션 1 또는 옵션 2 중 어느 옵션도 라디오 리소스 관리자에 의해 수행되지 않는다. 훨씬 더 명확하게 하기 위해, 라디오 리소스 관리자는, 임의의 데이터 트래픽의 조작이 매우 많은 비트 레이트 절약들을 약속하지 않는 경우, 각각의 데이터 트래픽을 변경되지 않게 유지한다. 그러나, 수 명의 사용자들이 각각 축구 게임 또는 임의의 다른 라이브 뉴스와 같은 라이브 스트리밍으로 스위칭하도록 원하는 경우를 가정한다. 이러한 경우, 이들 모든 클라이언트들로의 유니캐스트 스트리밍으로부터 멀티캐스트 스트리밍으로 스위칭할 수 있는 것이 바람직할 것이다. 제 1 옵션에 따르면, 라디오 리소스 관리자는, 데이터 트래픽 내의 중첩 미디어 프리젠테이션 설명을 인식할 경우, 각각의 미디어 프리젠테이션 설명 요청에 의해 미디어 라이브 스트리밍에 관한 미디어 프리젠테이션 설명을 요청했던 클라이언트들(40)로의 미디어 프리젠테이션 설명들을 조작하도록 구성된다. 변경은, 이용가능한 미디어 콘텐츠(44)의 유니캐스트 버전 이외에도, 또는 그 대신, 멀티캐스트 버전만이 이용가능한 정도로 본래의 미디어 프리젠테이션 설명을 변경시킨다. 따라서, 적어도 이들 새로이 참여한 클라이언트들(40)은 멀티캐스트 버전을 고려할 것이거나 고려해야 할 것이다. 제 2 대안에 따르면, 라디오 리소스 관리자(30)는, 데이터 트래픽 내의 중첩 미디어 프리젠테이션 설명들을 인식하는 경우, 예를 들어, 유니캐스트 버전을 요청하는 것으로부터 멀티캐스트 버전으로 변경되기 위해, 공통적인 미디어 콘텐츠(44)를 요청하는 클라이언트들로부터의 각각의 미디어 요청들을 변경시키도록 구성될 것이다. 대안적인 변경들이 또한 가능하다.

따라서, 도 6은, 사용자 엔티티들(34)에서 동작하는 클라이언트들(40)과 하나 또는 수 개의 서버들(32) 사이의 데이터 트래픽을 검사하고, 하나 또는 수 개의 서버들(32)로부터 클라이언트들(40) 중 상이한 클라이언트로의 데이터 트래픽 내에 공통적인 미디어 콘텐츠(44)에 관한 미디어 프리젠테이션 설명들이 존재하는지에 관해 체크하도록 구성된 라디오 리소스 관리자를 나타내며, 여기서, 라디오 리소스 관리자는, 체크에 의존하여, 미디어 콘텐츠(44)의 유니캐스트 버전들 이외에도, 공통적인 미디어 콘텐츠(44)의 멀티캐스트 버전을 클라이언트들(40)에 제공하도록 구성되거나; 라디오 리소스 관리자는, 체크에 의존하여, 공통적인 미디어 콘텐츠를 다운로딩하는 클라이언트들(40)에 대한 프로토콜의, 유니캐스트 프로토콜로부터 멀티캐스트 프로토콜로의 변화를 야기하도록 구성된다. 이러한 라디오 리소스 관리자는 또한, 사용자 엔티티들(34)로의 기지국(32)의 통신 리소스들의 할당을 담당할 수 있다. 상기 약술된 실시예는 다른 실시예들 중 임의의 실시예와 결합가능하다.

상기 약술된 실시예의 더 구체적인 구현이 후술된다. 이러한 구체적인 실시예에 따르면, DASH 유니캐스트 및 브로드캐스트/멀티캐스트 스위치오버가 실현된다. 상술된 바와 같이, 그러한 스위치 오버는 라이브 서비스들이 셀 사용도를 감소시키기 위해 유리하다. 이와 관련하여, 상술된 실시예가 하나 또는 수 개의 공통적인 기지국들(32)과 연관되거나 그에 고정(lock)된 사용자들을 고려할 경우에만 유용하지는 않음을 유의한다. 오히려, 그의 셀들 및 기지국 그 자체를 상호접속하는 백본(backbone) 모두를 포함하는 무선 네트워크는 일반적으로, 스트리밍이 대안적으로 멀티캐스트 프로토콜에 의해 또한 수행될 수 있는 유니캐스트 프로토콜을 사용하여 미디어 콘텐츠 스트리밍을 요청하는 과도하게 높은 수의 클라이언트들에 의해 의도치 않게(inadvertently) 부담될 것이다.

따라서, 기지국/LTE 네트워크는 라이브 서비스들을 유니캐스트 사용자에게 전달한다. 서비스에 대한 사용자 요청의 수가 증가하면, 서비스는, 모바일 네트워크 인프라구조의 백본 및 라디오 링크 상에서의 데이터 레이트 요구들을 감소시키기 위해 멀티캐스트/브로드캐스트 서비스로 스위칭 오버해야 한다.

● 예를 들어, HTTP로부터 FLUTE로(UDP를 통한 브로드캐스트 파일 다운로드 프로토콜)

사용자는 HTTP 서비스에 대한 데이터 서비스를 요청한다. Http 서버는 FLUTE 프로토콜을 통해 HTTP 획득 요청을 리턴한다.

<RedundantURL>http://cdn1.example.com/</RedundantURL>

<RedundantURL>flute://cdn2.example.com/session-description.sdp</RedundantURL>

MPD 내의 표시에 기초하여, 예를 들어, FLUTE(FLUTE - 단방향성 전달을 통한 파일 전달) 세션의 설명[IETF RFC 3926]으로의, 예를 들어, 세션 설명 프로토콜 SDP[IETF RFC 4566] 내의 링크를 포함하는 "리던던트(Redundant) URL"로서 프로토콜 변화가 적용될 수도 있다. 리던던트 URL은, HTTP로부터 FLUTE로의 프로토콜 변화와 같이 대안적인 송신 특징들을 갖는 대안적인 미디어 위치를 표시한다. 또한, 프로토콜 변화는 또한, 유니캐스트로부터 멀티캐스트 어드레스로의 소스 위치의 변화를 포함할 수도 있다.

도 3 및 도 6 및 대응하는 구현 예들에 관해, 사용자 엔티티가 현재 1개 초과의 기지국(32)에 의해 서빙되는 것이 가능함을 또한 명시적으로 유의한다. 즉, RRM 스케줄러가 RRM을 수행하는 기지국과는 다른 기지국을 통해 사용자 엔티티가 MPD를 수신하는 것이 가능하다. 단말은, MPD를 수신하기 위해 기본적인 IP 접속을 필요로 하며, 이러한 경우, 그 접속은 무선 시스템, 예를 들어, LTE를 통해 LTE의 RRM 유닛을 사용하여 설정된다. 그러므로, MPD를 수신하기 위해, UE는 RRM에 의해 할당된 몇몇 리소스들을 가질 필요가 있다. 현재의 LTE Rel. 8/9에서, 단말은, 고유한 셀 식별자(Cell-ID)를 갖는 (특정한 주파수, 예를 들어, 10 또는 20Mhz 대역폭을 갖는 2.6GHz 상에서 동작하는) 단일 기지국에 접속된다. 이러한 경우, UE는 기저 LTE 네트워크를 사용하여 MPD만을 획득할 수 있다. 다음 단계에서, 기존의 LTE에 대해 이미 존재하는 멀티밴드 기술들이 사용될 수 있다. 멀티밴드는, 예를 들어, 그것이 800MGz에서 동작하는 1개의 기지국 및 2.6GHz에서 동작하는 다른 기지국을 갖는다는 것을 의미한다. 단말은, 각각의 기지국이 그 자신의 셀 ID를 가지므로 동시에 양자의 기지국들에 접속될 수 있다. 그러므로, 단말은 1개 초과의 1개의 IP 엔트리 포인트, 여기의 예에서는 단말은 2개의 IP 엔트리 포인트를 가지며, MPD를 리트리브하기 위해 하나의 기지국을 사용하고, 데이터를 리트리브하기 위해 다른 하나의 기지국을 사용할 수 있다. 이러한 경우, 그것은 양자의 RRM 유닛들을 독립적으로 이용할 것이다. 이것은 또한, 다른 기술들로 확장될 수 있으며, 예를 들어, MPD를 분배하기 위해 LTE를 사용하고 데이터를 획득하기 위해 Wifi를 사용한다. 이와 유사한 멀티밴드 접근법은, 현재의 네트워크 로드, 또는 채널 품질 등에 기초하여 어느 기술을 사용할지를 결정하는 클라이언트 내의 몇몇 종류의 지능성을 요구할 것이다.

클라이언트(40)와 연관된 버퍼 상태의 시뮬레이션에 관한 상기 설명에 관해, 시뮬레이팅된 버퍼 상태가 또한 사용자 엔티티(34) 내의 임의의 장소에 위치된 다른 버퍼일 수도 있음을 유의한다. 예를 들어, 시뮬레이팅된 버퍼링 상태는 실제로, 사용자 엔티티의 트랜시버 스테이지 내의 MAC 계층 버퍼에 또한 관련될 수 있다. 예를 들어, 트랜시버 스테이지(70) 내의 상술된 MAC 계층 버퍼, 즉 버퍼(100)의 페던트(pedant)를 도시한 도 13을 참조한다. 버퍼(100)는 또한 기지국(32) 내에 위치될 수도 있다. 즉, 도 13은, 클라이언트(40)와 서버(32) 사이의 데이터 경로의 일부의 가능한 구현을 도시하며, 클라이언트(40)의 가능한 구현을 포함한다. 상기 도면들 모두와는 상이하게, 도 13은 또한, MAC 계층 버퍼(100), 즉, 클라이언트(40)의 다른 측 상에 위치된, 즉 클라이언트(40)에 관해 RRM(30)을 넘어선 네트워크 버퍼와 같은 MAC 계층 엔티티들을 도시한다. 사용자 엔티티의 트랜시버 스테이지(70)에 대응하는 기지국의 트랜시버 스테이지(102)가 또한 완성도를 위해 도시되어 있다. 트랜시버 스테이지(70)는 또한, 그 중에서도 다른 MAC 계층 버퍼와 같은 MAC 계층 엔티티들을 수용하지만, 그 계층 버퍼는 도 13에 도시되어 있지 않다. 한편, 도 3의 RRM(30)은 또한, 사용자 엔티티 내의 버퍼 상태를 시뮬레이팅하기 위해, 캐싱된 클라이언트(40)에 대한 그의 미디어 콘텐츠의 양에 관해 후자의 버퍼를 모니터링할 수 있다.

상술된 기능들에 대해 부가적으로 또는 대안적으로, 도 7 또는 도 13의 RM(74)이 MPD를 도출하기 위해 서버와 클라이언트 사이의 데이터 트래픽을 조사하는 도 3의 RRM(30)을 경감시킬 수 있음이 추가적으로 언급된다. 따라서, 리소스 관리자(74)는, 미디어 프리젠테이션 설명을 완전히 파싱 및 검사하고, 특정한 HTTP 스트리밍 세션과 같은 요청된 미디어 서비스에 대하여 클라이언트에 의해 지원된 잠재적인 비트 레이트 동작 포인트들만을 포함하는 미디어 프리젠테이션 설명의 서브세트로 그것을 변환하는데 사용될 수 있다. 즉, 변환된 미디어 프리젠테이션 설명은 각각의 서버에서 이용가능한 미디어 콘텐츠(44)의 기본적인 설명, 즉, 도 3에 관한 상기 설명의 의미에서 미디어 프리젠테이션 설명의 종류를 표현할 수도 있다. 상술된 바와 같이, 개별 버전들의 정보 밀도 사이의 랭킹만이, 즉, 각각의 버전의 품질의 매우 조악한 측정이 변환된 미디어 프리젠테이션 설명 내에서 시그널링될 수도 있다. 대안적으로, 상술된 바와 같이, 각각의 버전에 대해, 각각의 버전을 사용자에게 프리젠테이션하기 위한 필요한 최소 대역폭은, 각각의 관련 미디어 콘텐츠 버전에 대한, 즉, 사용자 엔티티의 설비들에 따라 사용자 엔티티의 사용자에게 프리젠테이션가능한 그들 미디어 콘텐츠 버전들에 대한 변환된 미디어 프리젠테이션 설명 내에서 시그널링될 수도 있다. 그 후, 이러한 변환된 MPD는, 그의 제어 하의 특정한 클라이언트 뿐만 아니라 다른 클라이언트들에 대한 추가적인 스케줄링 및 라디오 리소스 할당 결정들을 위해 그것이 이들 비트 레이트 동작 포인트들을 사용하게 하기 위해, 예를 들어, PHY/MAC 계층 상에서 라디오 리소스 관리자(30)에 포워딩될 수도 있다. 활성도를 허용하는 비디오 서비스의 타입은(서비스는 상이한 비트 레이트들의 각각의 동작 포인트들의 지원을 허용함), [19]에서 정의된 바와 같은 서비스 품질 파라미터 시그널링을 사용하여 표시될 수도 있다. 따라서, "적응적 비-대화형 비디오 및 적응적 비디오와 같은 새로운 트래픽 클래스들은, 서비스의 특징들을 표시하기 위해 표 6에 부가될 수도 있다. 이들 새로운 클래스들은, 라디오 리소스 관리자의 리소스 할당을 위해 선택될 레이트들의 세트의 표시, 즉 변환된 MPD의 표시를 추가적으로 요구할 수 있다. 보장된 최소 비트레이트(GBR)의 시그널링은, 서비스에 대한 최소 레이트 및/또는 다른 의미있는 동작 포인트들의 시그널링을 허용하도록 확장되는데 필요하다. 최소의 비트레이트가 관련되는 한, 변환된 미디어 프리젠테이션 설명이, 기지국 또는 라디오 리소스 관리자(30)에 의해 할당될 최소 비트레이트의 관점들에서와 같이, TCP 레벨과 같은 높은 OSI 데이터 트래픽 레벨 또는 몇몇 더 낮은 OSI 계층 레벨에서 측정된 비트레이트의 관점들에서 이러한 최소 비트레이트를 표시할 수도 있음을 유의해야 한다. 실제로 할당 및 송신된 비트레이트와 미디어 콘텐츠 송신에서 실제로 유효한 비트레이트 사이의 불일치의 상기 설명에 대한 참조가 행해지며, 불일치는, 예를 들어, 패킷 송신 및 NACK 및 ACK들 상에서의 재송신으로부터 초래한다.

상술된 바와 같이, 사용자 엔티티(34) 내에 상주하는 리소스 관리자(74)에 의해 실제 미디어 프리젠테이션 설명(46)으로부터 도출된 변환된 미디어 프리젠테이션 설명의 송신은, 상술된 "적응적 비-대화형 통신"과 같이, 각각의 사용자 엔티티와 기지국 사이에서 교환될 통신 데이터의 새로운 타입 또는 종류를 도입하고, 이러한 새로운 통신 데이터 타입, 즉 이러한 전용 베어러의 활성도의 프로토콜 프로세스 내에서 변환된 MPD를 송신함으로써, LTE와 같은 임의의 기존의 라디오 리소스 네트워크로 통합될 수 있다. 도 15는 가능한 통합을 더 상세히 예시적으로 도시한다. LTE는, 여기서 라디오 리소스 네트워크의 대표로서 예시적으로 사용되었지만, 원칙적으로 도 15의 설명은 다른 라디오 리소스 네트워크들로 용이하게 전달가능하다. 특히, 도 15는, 그러한 예시적인 베어러, 즉 "적응적 비-대화형 통신"을 생성하고, 변환된 미디어 프리젠테이션 설명을 라디오 리소스 관리자(30)에게 송신할 시에 수행되는 연속적인 단계들을 도시한다. 특히, 도 15는, 더 상세히 약술된 각각의 블록들 및 연관된 화살표들에 의해 시간축(110)을 따라 그들의 시간적인 순서로 이들 모든 단계들을 도시하며, 여기서, 이들 블록들 및 연관된 화살표들은, 각각의 단계에 수반된 각각의 엔티티들, 즉 데이터 트래픽 체인의 엔티티들, 즉 사용자 엔티티(40), 기지국(32), 라디오 리소스 관리자(30), 모바일러티 관리 엔티티(112), 패킷 게이트웨이(114), 및 미디어 서버(42) 위로 확장하기 위해 수평 방향으로 도시된다. 이전에 상술된 바와 같이, 모바일러티 관리 엔티티(112)는 또한, 라디오 리소스 네트워크의 모든 기지국들에 접속되며, 심지어 라디오 리소스 관리자(30)와 동일한 하드웨어 상에 적어도 부분적으로 구현될 수도 있다. 또한 이전에 상술된 바와 같이, 모바일러티 관리 엔티티(112)는, 사용자의 지불(payment) 계좌에서 인출하는 것과 같이 사용자의 액세스 데이터를 관리하는 것, 사용자들의 프로파일들을 관리하는 것(차례로, 프로파일들은 각각의 사용자에게 할당가능한 최대 대역폭과 같은 특정한 사용자 권리들을 표시함), 특정한 통신 데이터 타입들/종류들에 대한 제약 등을 담당한다. 또한, 모바일러티 관리 엔티티(112)는, 하나의 기지국의 셀로부터 다른 기지국의 셀로 천이하는 사용자 엔티티들의 핸드오버들을 핸들링하는 것을 담당할 수도 있다. 차례로, 패킷 게이트웨이(114)는, 엔티티들(40, 32, 30 및 112)이 속하는 라디오 리소스 네트워크를 외부의, 즉 인터넷 등에 인터페이싱하기 위한 책임을 가정한다. 라디오 리소스 관리자(30) 및 모바일러티 관리 엔티티(112)의 하나의 유닛으로의 가능한 통합은 파선(116)에 의해 예시적으로 도시되지만, 점선(118)은, 라디오 리소스 관리자(30)가 기지국(32) 내에 위치될 수도 있는 가능성을 표시한다.

도 15로부터 도출가능한 바와 같이, 사용자 엔티티(40)는 라디오 리소스 네트워크에 이미 부착될 수도 있고, 디폴트 베어러는 이미 활성화될 수도 있어서, 사용자 엔티티(40)가, 예를 들어, 인터넷으로의 낮은 복잡도 액세스를 수행하는 것과 같은 라디오 리소스 네트워크를 통해 최소 태스크들을 수행할 수 있게 한다고 가정한다. 부착 및 디폴트 베어러 활성화의 단계가 (116)에 도시되어 있다. 더 명확하게 하기 위해, 단계(116)는, 사용자 엔티티의 도메인이 관련되는 한, 트랜시버 스테이지(70)에 의해 수행된다. 그 후, 사용자 또는 사용자 엔티티(34)의 클라이언트(40)가 본 발명의 예에서는 디폴트 베어러 세션을 사용하여 미디어 서버(42)에 MPD 요청(118)을 전송한다고 가정한다. 미디어 서버(42)는 단계(120)에서 MPD를 다시 전송하며, 여기서, 사용자 엔티티(34) 내의 리소스 관리자(74)는, 상술된 바와 같이, 단계(120)의 MPD를 변환된 MPD로 변환하기 위해 단계(122)에서 이러한 MPD를 파싱한다. 그 후, 예를 들어, "적응적 비-대화형 통신"의 활성화와 같은 전용 베어러 활성화는 (124)에서 트리거링된다. 예를 들어, 트리거(124)는, 단계(122)에서 파싱된 MPD가 참조하는 미디어 콘텐츠를 요청하는 사용자 엔티티(34)의 사용자 또는 클라이언트(40)에 의해 야기될 수도 있다. 트리거(124)에 응답하여, 리소스 관리자(74) 및 트랜시버 스테이지(70)는, 단계(126)에서 베어러 리소스 할당 요청을 기지국(32)에 전송하기 위해 협력하며, 그에 의해, 기지국은 차례로, 단계(128)에서 라디오 리소스 관리자(30) 및 모바일러티 관리 엔티티(112) 각각에 각각의 할당 요청을 포워딩하도록 명령받는다. 할당 요청은, 예를 들어, 더 상세히 후술되는 신택스를 사용하는 상술된 변환된 미디어 프리젠테이션 설명을 포함한다. 그 결과, 모바일러티 관리 엔티티(122)는, 각각의 베어러 리소스가 베어러 리소스 커맨드를 사용하여 단계(130)에서 생성된다는 것을 패킷 게이트웨이(114)에 통지하며, 여기서, 생성 그 자체는 단계(132)에서 수행된다. 따라서, 단계(128)로부터, 라디오 리소스 관리자(30)는 변환된 미디어 프리젠테이션 설명의 콘텐츠에 관해 알지만, 전용 베어러의 활성도는 아직 확인되지 않는다. 따라서, 모바일러티 관리 엔티티(112)는, 단계(134)에서 전용 베어러 활성화 요청을 기지국(32)에 전송함으로써 다른 확인응답 루틴을 시작하며, 기지국(32)은 차례로, 사용자 엔티티(34) 특히 트랜시버 스테이지(70)에 단계(136)에서 그것을 포워딩한다. 그 후, 단계(140)에서, 트랜시버 스테이지(70)는 전용 베어러 활성화의 수용을 기지국(32)에 시그널링하며, 그에 따라, 기지국(32)은 차례로, 단계(142)에서 라디오 리소스 관리자(30) 및 모바일러티 관리 엔티티(112)에 통지한다. 그 시간으로부터, 라디오 리소스 관리자(30)는, 단계들(120 내지 128)을 통해 리소스 관리자(74)로부터 리소스 관리자(30)로 시그널링될 경우 변환된 미디어 프리젠테이션 설명을 사용함으로써, 상술된 라디오 리소스 할당, 즉 스케줄링을 수행할 수 있다. 따라서, 사용자 엔티티(34)의 클라이언트(40)와 미디어 서버(42) 사이의 미디어 송신 세션(144)은, 기지국(32) 및 라디오 리소스 네트워크 각각에 의해 서빙된 모든 사용자 엔티티들로의 라디오 리소스들의 할당을 고려할 경우 효율적인 방식으로 라디오 리소스 관리자(30)에 의해 제어될 수도 있다.

도 15에 관해, 일반적으로, 전용 라디오 베어러들을 셋업하기 위한 2개의 가능성들이 존재함을 유의한다. 제 1 방법은 구동된 클라이언트이다. 여기서, UE(34)는 도 15에 도시된 바와 같이 디폴트 베어러를 통해 인터넷에 접속된다. 클라이언트(40)에 의한 이전에 이슈된 MPD 요청(118)의 응답(120)에 기초하여, 사용자 엔티티의 RM(74)은, 검사를 위해 대응하는 MPD를 수신하고, 그에 따라, 전용 라디오 베어러를 트리거링(124)한다. 이것은, ESM 베어러 리소스 할당 요청을 모바일러티 관리 엔티티(112)(MME)에 이슈(126)함으로써 전용 베어러 활성화를 트리거링함으로써 행해진다 ([20] 내의 섹션 8.3.8과 비교). 이러한 메시지(126)는 요구된 이벌브드 패킷 시스템(EPS) 서비스 품질 정보, 즉 변환된 MPD를 정의하는 정보 엘리먼트(IE)를 포함한다.

대안적인 가능성은 구동된 네트워크이다. 여기서, P-GW(114)는 핸드오버 절차 동안, 요구된 QoS 베어러를 유지하는데 필요한 라디오 베어러의 셋업을 트리거링한다. 양자의 경우들에서, 아래의 표에 도시된 EPS 서비스 품질 정보[[20]의 섹션 9.9.4.3 참조]를 포함하는 ESM 활성화 전용 베어러 요청 메시지들([20]의 섹션 8.3.3 참조)이 전송된다. 이러한 표는 ([20]과 비교하여), 최소만을 그리고 대안적인 더 높은-비트레이트들을 갖는 GBR 뿐만 아니라 대안적인 비트 레이트들을 갖는 비-GBR에 대한 시그널링, 즉 변환된 MPD를 포함하도록 확장 또는 변경된다. 도 15에 도시된 바와 같이 UE가 전용 베어러를 트리거링하는 경우, 그것은, MPD에서 발견된 대안적인 비트 레이트들과 같은 정보 엘리먼트들을 제공한다. 네트워크가 전용 베어러를 트리거링하는 경우, 대안적인 비트 레이트들 및 변환된 MPD 각각은, 핸드오버의 경우에서는 대응하는 P-GW에 의해, 또는 MPD를 검사한 이후 리소스 관리자(74)로부터 제공되어야 한다. 따라서, P-GW는 MPD 위치 또는 그의 콘텐츠에 관해 RRM에게 통지할 필요가 있다. [20]에서, 다른 메시지들, 즉 베어러 리소스 변경 요청(섹션 8.3.10) 및 활성화 디폴트 EPS 베어러 요청(섹션 8.3.6)은 또한, 표 4에 도시된 EPS 서비스 품질 정보를 또한 포함하며, 상술된 대안적인 비트레이트들을 제공하기 위해 사용될 수도 있다.

8 7 6 5 4 3 2 1

서비스 IEI의 EPS 품질	옥텟1
서비스 콘텐츠들의 EPS 품질의 길이	옥텟2
QCI	옥텟3
업링크에 대한 최대 비트 레이트	옥텟4*
다운링크에 대한 최대 비트 레이트	옥텟5*
업링크에 대한 보장된 비트 레이트	옥텟6*
다운링크에 대한 보장된 비트 레이트	옥텟7*
업링크에 대한 비트 레이트 (확장됨)	옥텟8*
다운링크에 대한 최대 비트 레이트(확장됨)	옥텟9*
업링크에 대한 보장된 비트 레이트(확장됨)	옥텟10*
다운링크에 대한 보장된 비트 레이트(확장됨)	옥텟11*

현재 정의된 바와 같은 서비스 엘리먼트의 EPS 품질을 도시함

하나의 가능성은 표 5에 도시된 바와 같이 더 많은 옥텟들을 부가하는 것이다. 보장된 비트레이트들에서 표시된 레이트는, 예를 들어, 가장 낮은 품질/가장 낮은 정보 밀도 영역에 대해 보장되어야 하는 최소 대역폭에 대응할 것이지만, 다운링크 및 업링크에 대한 대안적인 비트레이트들은, 본래의 MPD(46)에서 발견되어 다운로딩하기에 이용가능한 비트레이트들을 설명한다. 대안적인 비트 레이트들의 필드들은 QCI 필드의 값에 의존하여 존재한다. 예를 들어, 표 5에서 정의된 새로운 QCI 값들이 사용되면, 다운링크 또는 업링크에 대한 대안적인 비트 레이트들이 존재해야 한다. 이러한 메커니즘은 백워드 호환가능성을 허용한다. QCI 값이 이해되지 않으면, 다른 GBR 또는 비-GBR QCI는 보장된 비트 레이트가 존재하는지 또는 존재하지 않는지에 의존하여 선택된다.

8 7 6 5 4 3 2 1

서비스 IEI의 EPS 품질	옥텟1
서비스 콘텐츠들의 EPS 품질의 길이	옥텟2
QCI	옥텟3
업링크에 대한 최대 비트 레이트	옥텟4*
다운링크에 대한 최대 비트 레이트	옥텟5*
업링크에 대한 보장된 비트 레이트	옥텟6*
다운링크에 대한 보장된 비트 레이트	옥텟7*
업링크에 대한 최대 비트 레이트(확장됨)	옥텟8*
다운링크에 대한 최대 비트 레이트(확장됨)	옥텟9*
업링크에 대한 보장된 비트 레이트(확장됨)	옥텟10*
다운링크에 대한 보장된 비트 레이트(확장됨)	옥텟11*
부가적인 대안적인 다운링크 레이트들의 수	옥텟12*
다운링크_1에 대한 대안적인 비트 레이트	옥텟13*
...	...
다운링크_N에 대한 대안적인 비트 레이트	옥텟 12+N*
부가적인 대안적인 업링크레이트들의 수	옥텟 13+N*
업링크_1에 대한 대안적인 비트 레이트	옥텟 14+N*
...	...
업링크_M에 대한 대안적인 비트 레이트	옥텟 13+N+M*

대안적인 비트 레이트들에 의한 서비스 정보 엘리먼트들의 확장된 EPS 품질

다른 가능성은, 상술된 메시지들에 부가될 EPS 서비스 품질 정보 메시지에 부가적인 메시지(ESM 베어러 리소스 할당 요청, ESM 활성화 전용 베어러 요청, 베어러 리소스 변경 요청 및 활성화 디폴트 EPS 베어러 요청)를 부가하는 것일 것이며, 여기서, EPS서비스 품질 정보 메시지가 사용된다. 이것은, EPS 서비스 품질 메시지가 그와 같이 되는 것을 허용할 것이다. 확장의 콘텐츠는 다음과 같이 표 6에 존재할 수 있다. 이러한 경우, 보장된 비트레이트 값들은 EPS 서비스 품질 정보 메시지에서와 같이 취해져야 하지만, QCI 값은 확장 메시지에 의해 오버라이팅(overwrite)될 것이다. 대안적인 비트 레이트들은 또한 이러한 확장 메시지에서 설명될 것이다.

8 7 6 5 4 3 2 1

EPS 서비스 품질 확장 IEI
EPS 서비스 품질 확장 콘텐츠들의 길이
QCI
부가적인 대안적인 다운링크 레이트들의 수
다운링크_1에 대한 대안적인 비트 레이트
…
다운링크_N에 대한 부가적인 비트 레이트
부가적인 대안적인 업링크 레이트들의 수
업링크_1에 대한 대안적인 비트 레이트
…
업링크_M에 대한 대안적인 비트 레이트

옥텟1
옥텟2
옥텟3
옥텟4*
옥텟5*
..
옥텟 4+N*
옥텟 5+N*
옥텟 6+N*

옥텟 5+N+M*

EPS 서비스 품질 정보 엘리먼트에 대한 비트레이트 대안들을 운반하는 부가적인 메시지

도 15에 도시된 바와 같이, MME(112)는, 서비스에 대한 주어진 QoS를 갖는 베어러를 셋업하기 위해 코어 네트워크의 나머지, 즉 S-GW 및 P-GW(114)와 메시지들을 교환해야 한다. S-GW는 기지국(eNB)과 다른 EPC(이벌브드 패킷 코어) 엔티티들 사이의 게이트웨어, 예를 들어, P-GW이다. (또한, PDN - GW = 패킷 데이터 네트워크 게이트웨이로서 종종 특정되는) P-GW는 EPC와 인터넷/백본 사이의 인터페이스이다. 그러므로, LTE 네트워크들 내의 모든 데이터는 다음과 같이 라우팅된다: UE(단말)<->eNB<->S-GW<->P-GW<->인터넷/백본.

추가적인 메시지들의 교환은, MME로부터 S-GW로, 그리고 S-GW로부터 P-GW로의 GTP-C 베어러 리소스 커맨드([21]의 섹션 7.2.5 참조), P-GW로부터 S-GW로 그리고 S-GW로부터 MME(112)로의 GTP-C 생성 베어러 요청([21]의 섹션 7.2.3 참조) 및 E-RAB 셋업 요청/응답([22]의 섹션 8.2.1.1 및 섹션 8.2.1.2 참조)을 포함하며, 제공되어야 하는 QoS 특징들에 관해 라디오 리소스 관리자(30)에게 통지한다. 따라서, 상술된 이들 메시지들은, 표 5 및 표 6에서 프리젠테이션된 확장들에 따라 확장되어야 한다. 예를 들어, GTP-C 베어러 리소스 커맨드에 대해, [21]의 섹션 8.16의 흐름 QoS IE는, 예를 들어, 표 7에 도시된 바와 같이, 여기에 정의된 대안적인 비트 레이트들을 이용하여 확장되어야 한다. GTP-C 생성 베어러 요청에 대해, [21]의 섹션 8.15 내의 베어러 QoS IE는, 예를 들어, 표 8에 도시된 바와 같이, 여기에 정의된 대안적인 비트 레이트들을 이용하여 확장되어야 한다. E-RAB 셋업 요청에 대해, MME(112)는 [22]의 섹션 9.2.1.15 내의 E-RAB 레벨 QoS 파라미터들에 협의된 대안적인 비트 레이트들을 삽입해야 한다. 이러한 목적을 위해, E-RAB 레벨 QoS는, 예를 들어, 표 9 및 표 10에 도시된 바와 같이, 이전에 정의된 부가적인 대안적인 비트 레이트들을 부가하여 확장되어야 한다.

흐름 서비스 품질(흐름 QoS)

	Bits
Octets	8	7	6	5	4	3	2	1
1	타입 = 81 (10진법)
2 to 3	길이 = n
4	스페어				인스턴스
5	라벨 (QCI)
6 to 10	업링크에 대한 최대 비트 레이트
11 to 15	다운링크에 대한 최대 비트 레이트
16 to 20	업링크에 대한 보장된 비트 레이트
21 to 25	다운링크에 대한 보장된 비트 레이트
26	부가적인 대안적인 다운링크 레이트들의 수(N)
	다운링크_1에 대한 대안적인 비트 레이트
	...
26+N	다운링크_N에 대한 대안적인 비트 레이트
	부가적인 대안적인 업링크 레이트들의 수(M)
	업링크_1에 대한 대안적인 비트 레이트
	...
27+N+M	업링크_M에 대한 대안적인 비트 레이트
28+N+M to (n+4)	명시적으로 특정된 경우에만 이들 옥텟(들)이 존재함

베어러 레벨 서비스 품질 (베어러 QoS)

	Bits
Octets	8	7	6	5	4	3	2	1
1	타입 = 80 (10진법)
2-3	길이 = n
4	스페어				인스턴스
5	스페어	PCI	PL				스페어	PVI
6	라벨 (QCI)
7 to 11	업링크에 대한 최대 비트 레이트
12 to 16	다운링크에 대한 최대 비트 레이트
17 to 21	업링크에 대한 보장된 비트 레이트
22 to 26	다운링크에 대한 보장된 비트 레이트
27	부가적인 대안적인 다운링크 레이트들의 수(N)
	다운링크_1에 대한 대안적인 비트 레이트
	...
27+N	다운링크_N에 대한 대안적인 비트 레이트
	부가적인 대안적인 업링크 레이트들의 수(M)
	업링크_1에 대한 대안적인 비트 레이트
	...
28+N+M	업링크_M에 대한 대안적인 비트 레이트
29 to (n+4)	명시적으로 특정된 경우에만 이들 옥텟(들)이 존재함

E-RAB 셋업 요청 또는 E-RAB 레벨 QoS 파라미터들

IE /그룹 명칭	존재	범위	IE 타입 및 참조	시맨틱 설명
E- RAB 레벨 QoS 파라미터
>QCI	M		정수(0…255)	Ts 23.401 [11]에서 정의된 QoS 클래스 식별자. TS 23.203 [13]에서 특정된 코딩
>할당 및 보유 우선순위	M		9.2.1.60
> GBR QoS 정보	O		9.2.1.18	이러한 IE는, GBR 베어러들에만 적용되며, 그렇지 않으면 무시되어야 함
> ABR - QoS	O			이러한 IE는 대안적인 비트레이트들을 제공하기 위해 GBR 및 비-GBR 베어러들에 적용됨

ABR - QoS: 적응적 비트레이트(ABR) QoS에 대한 대안적인 비트레이트들

IE /그룹 명칭	존재	범위	IE 타입 및 참조	시맨틱 설명
N			정수	대안적인 다운링크 비트레이트들의 수
M			정수	대안적인 업링크비트레이트들의 수
E-RAB 대안적인 다운링크 비트 레이트 1	M		비트 레이트 9.2.1.19	설명: 이러한 IE는 제 1 대안적인 다운링크 E-RAB 비트 레이트를 표시함
…
E-RAB 대안적인 다운링크 비트 레이트 N	M		비트 레이트 9.2.1.19	설명: 이러한 IE는 제 N 대안적인 다운링크 E-RAB 비트 레이트를 표시함
E-RAB 대안적인 업링크 비트 레이트 1	M		비트 레이트 9.2.1.19	설명: 이러한 IE는 제 1 대안적인 업링크 E-RAB 비트 레이트를 표시함
…
E-RAB 대안적인 업링크 비트 레이트 M	M		비트 레이트 9.2.1.19	설명: 이러한 IE는 제 M 대안적인 업링크 E-RAB 비트 레이트를 표시함

상술된 프로세스와 유사하게, 핸드-오버는 [23]에서 설명된 바와 같이 e노드B에 의해 개시될 수 있다. 그러한 경우, (동일한 QoS 특징들을 갖는) 베어러 셋업 또는 베어러 유지보수는, ESM 베어러 리소스 할당 요청을 이슈하여 MME 또는 P-GW 어느 것에 의해서도 개시되지 않지만, 3GPP[24]에서 정의된 X2 인터페이스 내에서 행해진다. 그러한 경우, 대안적인 비트레이트들을 갖는 이전에 제안된 확장된 신택스는 적절한 메시지들에 포함되어야 한다. 구체적으로, 인터페이스 X2에 대해, E-RAB 레벨 QoS 파라미터 IE/그룹 명칭을 포함하는 핸드오버 요청 메시지가 정의된다 ([23]의 섹션 9.1.1.1과 비교). 이러한 IE는 [23]의 섹션 9.2.9에 정의되며, 표 10에 도시된 바와 같이 확장되어야 한다. 이러한 메시지의 신택스는 상술된 E-RAB 셋업 요청과 동일할 것이다.

또한, 상술된 기능들에 부가적으로 또는 대안적으로, 리소스 관리자(74)는, 그의 제어 하의 특정한 클라이언트 뿐만 아니라 다른 클라이언트들에 대한 추가적인 스케줄링 및 라디오 리소스 할당 결정들에 대한 실제의 결과적인 애플리케이션을 라디오 리소스 관리자(30)가 식별하게 하기 위해, 상위 레벨 TCP 세션에 의해 관측된 바와 같은 실제 수신된 스루풋을 정보로서 라디오 리소스 관리자(30)에 포워딩할 수 있다. 더 일반적으로, 사용자 엔티티(34)는, 클라이언트(40)가 동작하는 라디오 리소스 기지국(32)과 통신하기 위한 것일 수도 있으며, 여기서, 사용자 엔티티(34)는, 서버(42)로부터 클라이언트(40)에 의해 수신된 미디어 콘텐츠의 실제로 수신된 미디어 콘텐츠 스루풋 및 버퍼 상태를 결정하고, 결정된 미디어 콘텐츠 스루풋 또는 버퍼 상태에 대해 라디오 리소스 관리자(30)에게 통지하도록 구성될 수도 있다. 결정은, 사용자 엔티티 내의 각각의 태스크에 대한 책임을 가정하는 리소스 관리자(74)에게 클라이언트(40)가 각각의 정보를 전송하는 것을 수반할 수도 있다.

도 3 내지 도 5의 실시예에 관해, 상기 설명은 주로 다운링크의 경우, 즉, 라디오 리소스 관리자가 다운링크 통신 리소스들을 사용자 엔티티들(34)에 할당했던 경우에 관련되지만, 상기 실시예들이 또한 업링크 경우들에 전달된다는 것이 언급되어야 한다. 더 일반적인 관점, 예를 들어, 도 3 내지 도 5 및 통신 리소스들의 할당이 수행되는 라디오 리소스 관리자(30)의 기능에 관련된 다른 모든 실시예들에서, 라디오 리소스 관리자는, 서버로부터 클라이언트로의 데이터 트래픽 내의 미디어 프리젠테이션 설명에 의존하여, 통신 리소스들, 즉, 적어도 하나의 기지국(32)의 다운링크 및/또는 업링크 통신 리소스들을 사용자 엔티티들(34)에 할당하도록 더 일반적으로 구성될 수도 있으며, 여기서, 서버 및 클라이언트 중 하나는 사용자 엔티티들(34) 중 하나에서 동작하지만, 이러한 하나는 반드시 클라이언트일 필요는 없다. 이것은 아래에서 더 상세히 명시적으로 약술될 것이다. 예를 들어, 도 16을 참조한다. 마이너한 유의점으로서, 서버 및 클라이언트가 심지어 하나의 공통적인 사용자 엔티티 상에서 동작하는 양자일 수도 있으며, 따라서, "서버 및 클라이언트 중 하나"가 "적어도 하나" 로서 이해될 것이라고 나타낸다.

도 16은, 클라이언트(40) 및 서버(42)가 스위칭된다는 것을 제외하고 도 3에 대응하며, 서버(42)는 사용자 엔티티(34)에서 동작하는 반면, 클라이언트(40)는 사용자 엔티티(34)에 관해 기지국(32)의 다른 측 상에 위치된다. 도 7에 도시된 바와 같이, 사용자 엔티티의 가능한 내부 구조의 더 상세한 설명을 고려할 경우, 서버(32)는 도 7의 대체 클라이언트(40)로서 고려될 수도 있다. 이것은 다음을 의미한다. 라디오 리소스 관리자(30)는 서버(42 및 40) 사이의 데이터 트래픽을 조사할 수도 있다. 특히, 라디오 리소스 관리자(30)는 그로부터 미디어 프리젠테이션 설명(46)을 조사할 수도 있다. 그에 기초하여, 라디오 리소스 관리자(30)는, 사용자 엔티티가 서버(42)가 동작하는 것인 사용자 엔티티들에 기지국(32)의 업링크 통신 리소스들을 할당할 수도 있다. 특히, 리소스 관리자(30)의 잠재적인 작동들에 관한 상기 설명 모두는 동일하게 유지된다. 즉, 리소스 관리자(30)는 또한, 클라이언트(40)로부터 서버(42)로의 미디어 요청들을 검사 및 로그하고, 그의 평가 등에 의존하여 업링크 통신 리소스들의 할당을 수행할 수도 있다.

한편으로는 도 3 내지 도 6의 실시예와 다른 한편으로는 도 16 사이의 조화(concordance)는, 라디오 리소스 관리자(30)의 기능의 일부가 RRM(30)으로부터, 한편으로는 서버(42)와 다른 한편으로는 트랜시버 스테이지(70) 사이에 위치된 리소스 관리자(74) (예를 들어, 도 7 참조) 상으로 전달되는 도 3 내지 도 5의 실시예의 상기 약술된 확장을 고려할 경우라도 유효하게 유지된다. 이것은 또한 도 16의 경우에 대해 참이며: 리소스 관리자(74)는 사용자 엔티티(34)의 서버(42)와 클라이언트(40) 사이의 데이터 트래픽을 조사하는 RRM(30)을 경감시키도록 구성될 수도 있다. 즉, 그 경우, 즉 서버(42)가 사용자 엔티티(34) 상에서 구동하는 경우에서도, 업링크 대역폭의 리소스들은 또한, 유사하게, 즉, 라디오 리소스 관리자(30)에게 비트 레이트 대안들, 즉 변환된 MPD를 표시하는 리소스 관리자(74), 및 그에 의존하여 업링크 리소스 할당을 수행하기 위해 변환된 MPD를 사용하는 RRM(30)에 의해 관리될 수도 있다. 리소스 관리자(74)는, 표 5에 도시된 바와 같이, 확장된 EPS 서비스 품질 메시지를 포함하는 상술된 ESM 메시지들에서 업링크에 대한 대안적인 비트레이트들을 표시할 수도 있다.

예를 들어, 도 14를 참조한다. 좌측 상에서, 도 14는 도 15와 유사한 흐름도를 도시하고, 즉, 시간축(110)을 사용하며, 수평 방향을 따라 엔티티들을 확산시키고, 각각의 블록들과 연관된 화살표들에 의해 도시함으로써 블록들에서 도시된 각각의 단계들이 수반된 엔티티들을 구별하며, 그 엔티티들 사이에서 각각의 단계가 발생한다. 도 14의 우측 상에서, 도 15의 경우, 즉 클라이언트가 사용자 엔티티에 상주하는 경우가 다시 도시된다. 좌측 상에서, 서버(42)가 사용자 엔티티(34)에서 동작하는 경우가 도시된다. 사실, 하나의 사용자 엔티티에서 동작하는 클라이언트 및 다른 사용자 엔티티에서 동작하는 서버는 쌍을 형성할 수도 있으며, 그 사이에서, 미디어 콘텐츠가 전달된다. 예를 들어, 사용자 엔티티(34')에서 동작하는 서버가, 예를 들어, 사용자 엔티티의 각각의 카메라에 의해 캡쳐된 사용자 엔티티(34')에서의 비디오 화상회의의 참가자에 관한 비디오를 사용자 엔티티(34'')에서 동작하는 클라이언트에 송신하는 비디오 화상회의(conference) 내에서 그러한 상황이 발생할 수도 있다. 그러나, 다른 사용 경우들이 또한 가능하다. 예를 들어, 클라이언트는, 다른 사람의 사용자 엔티티(34')에서 미디어 서버로부터 파일을 다운로딩할 수도 있다. 그 경우, 한편으로는 사용자 엔티티(34')의 서버와 다른 한편으로는 사용자 엔티티(34'')의 클라이언트 사이의 데이터 트래픽 내의 참가 엔티티들은 도 14의 좌측으로부터 우측으로 그들의 언급 순서로 도시된다: 사용자 엔티티(34'), 사용자 엔티티(34')가 현재 부착된 기지국(32'), 기지국(32')의 통신 리소스들을 할당하는 것을 담당하는 라디오 리소스 관리(30'), 기지국(32') 및 라디오 리소스 관리자(30')가 속하는 라디오 리소스 네트워크를 제어하는 것을 담당하는 모바일러티 관리 엔티티(112'), 동일한 라디오 리소스 네트워크에 속하는 패킷 게이트웨어(114'), 기지국(32'')이 속하고 클라이언트(34'')가 부착된 라디오 리소스 네트워크에 양자가 속하는 패킷 게이트웨이(114'') 및 모바일러티 관리 엔티티(112''), 기지국(32'')의 통신 리소스들을 할당하는 것을 담당하는 라디오 리소스 관리자(30''), 기지국(32'') 그 자체, 및 사용자 엔티티(34''). 도 14에 도시된 바와 같이, 사용자 엔티티(34'')는, 사용자 엔티티(34'')가 단계(116)에서 행하는 것과 동일한 방식으로 단계(116')에서 부착 및 디폴트 베어러 활성화를 수행할 것이다. 도 15에 관해 상술된 바와 같이, 사용자 엔티티(34'') 상에 상주하는 클라이언트는 단계(118)에서, 사용자 엔티티(34')에 상주하는 서버에 MPD 요청을 전송할 수도 있으며, 그 때, 후자는 단계(120)에서 사용자 엔티티(34'')에 MPD를 다시 전송한다. 그 때에, 단계(122)에서, 사용자 엔티티(34'')에 상주하는 리소스 관리자(74)는 MPD를 파싱하고, 단계들(126 내지 142)의 상기 설명의 라인을 따라 전용 베어러의 활성화를 야기하며, 그 때, 리소스 관리자(30)는, 미디어 송신 세션(144) 내의 사용자 엔티티(34'')의 리소스 관리자(74)에 의해 포워딩된 변환된 MPD에 따라 기지국(32'')의 다운링크 통신 리소스들을 할당하고, 그 후, 그 송신 세션(144)은 클라이언트와 서버 사이에서 발생한다. 업링크 도메인 측 상에서, 유사한 단계들이 취해진다. 사용자 엔티티(34')에 상주하는 서버(42)는 전용 베어러의 활성화, 즉, 여기서, 도 15에 관해 상술된 단계들(126 내지 142)과 유사한 적응적 대화형 또는 비-대화형 통신 타입 세션을 야기하며, 그 때에, 미디어 송신 세션(144) 내에서, 라디오 리소스 관리자(30')는, 베어러 리소스 할당 요청(126) 내에서 사용자 엔티티(34')의 서버에 의해 포워딩되는 바와 같이 변환된 미디어 프리젠테이션 설명에 따라 기지국(32')의 업링크 리소스들을 할당한다.

도 14가, 서버 및 클라이언트 양자가 각각의 라디오 네트워크들에 결합된 사용자 엔티티들 상에 상주하는 경우만을 예시적으로 도시했음이 언급되어야 한다. 도 14의 예는, 예를 들어, 클라이언트가 사용자 엔티티에서 동작하고 있지 않지만, 예를 들어, 고정형 컴퓨터인 경우 상으로 용이하게 전달가능하다. 또한, 몇몇 시나리오가 하나의 공통적인 라디오 리소스 네트워크 내에서 또한 발생할 수도 있고, RRM' 및 RRM'' 및/또는 MME' 및 MME'' 및/또는 동일하다는 것이 언급되어야 한다.

한편, 상기 실시예들 중 모두에 대해, 미디어 콘텐츠(44)가 상주하는 서버가 미디어 프리젠테이션 설명을 제공하기 위해 서버로서 작동하는 엔티티로부터 분리될 수도 있다는 것이 발생할 수도 있음을 유의한다. 더 일반적으로, MPD(46)는, 미디어 콘텐츠(44) 그 자체를 제공하는 서버와는 다른 엔티티 또는 서버로부터 기인할 수도 있다. 이러한 가능성은, 예를 들어, 단계들(120 및 118)에 각각 대응하는 화살표들의 기원 및 타겟에 관한 점선들을 이용하여 도 14에 도시되어 있다. 특히, 이러한 잠재적인 MPD 소스는 점선들을 이용하여 (150)에 도시되어 있다. 이러한 여분의 MPD 소스(150)가 경우, 라디오 리소스 관리자(30')는 그럼에도 불구하고, 변환된 미디어 프리젠테이션 설명에 대하여 리소스 관리자(74)에 의해 통지받을 수도 있다. 그러나, 그 경우, 리소스 관리자(74)는, 사용자 엔티티(34'')의 클라이언트와 사용자 엔티티(34')의 서버 사이의 데이터 트래픽을 검사하는 것 대신, 변환된 미디어 프리젠테이션 설명을 사용자 엔티티(34'')의 리소스 관리자(74)에 제공하도록 사용자 엔티티(34')의 서버에게 명령할 것이다.

따라서, 즉, 도 14의 좌측 상의 사용자 엔티티(34)는 미디어 서버로서 셋팅되고, 우측 상의 사용자 엔티티(34)는 클라이언트(40)로서 셋팅된다. MPD는, 네트워크에서 임의의 서버일 수도 있는 MPD 소스(150)로부터 클라이언트에 의해 요청된다(하나의 특수한 경우는, MPD를 갖는 서버가 사용자 엔티티(34')의 미디어 서버인 경우임). 미디어 서버가 MPD에서 광고되는 미디어의 특징들을 알고 있으므로, 그것은, 설명된 ESM 메시지들에서 대안적인 비트레이트들을 표시하기 위해 이러한 정보를 사용하고, 업링크 비트레이트가 특히 중요한(서버가 데이터를 업로드하는 것을 필요로 함) 베어러를 셋업한다. 그러나, 클라이언트는, 다운링크 비트레이트가 특히 중요한 경우(클라이언트(40)가 데이터를 다운로딩하는 것을 필요로 함), 수신 MPD를 파싱하는 것을 필요로 하고, 베어러 할당을 위해 설명된 정보를 사용한다. 그러나, TCP가 사용될 수도 있으므로, 다운링크 비트레이트는 서버에 대해 또한 중요할 뿐만 아니라, 업링크 비트레이트는 클라이언트에 대해 중요하다.

예를 들어, 대화형 시나리오들에서, 특수한 경우가 존재하며, 여기서, 사용자 엔티티들(34)의 각각은 미디어 서버 및 그에서 동시에 동작하는 클라이언트를 갖는다. 이러한 경우, 양자의 사용자 엔티티들(34)은, 그들 각각의 서버들에서 제공된 미디어 특징들 및 클라이언트들(40)로서 수신해야하는 미디어 특징들에 기초하여, 미디어 프리젠테이션 설명(예를 들어, MPD 또는 SDP)을 요청할 것이고, 업링크 및 다운링크 양자에 대해 대안적인 비트레이트들을 설명하기 위해 이러한 정보를 사용할 것이다.

그러한 시나리오에서, 사용자 엔티티들(34)이 미디어 서버 및 클라이언트를 동시에 갖는 경우, 2개의 상이한 e노드B들이 대화에 참여하는 상이한 사용자 엔티티들(34)을 처리하는 것이 발생할 수도 있다. e노드B들 각각에 대해 동작하고 사용자 엔티티들(34)을 처리하는 라디오 리소스 관리자(30)는, 상이한 사용자들에 대한 에어 인터페이스들의 각각을 최적화하여 독립적으로 동작한다. 그러한 시나리오의 문제는, 하나의 사용자 엔티티(34)의 에어 인터페이스가 다른 사용자 엔티티(34)의 라디오 리소스들의 최적화를 고려하지 않는다는 것이다. 따라서, 차선의 결정이 취해질 수도 있다. 예를 들어, 제 1 사용자 엔티티(34)가 통신하고 있는 다른 사용자 엔티티(34)에서 다운로딩될 수 있는 데이터의 양보다 더 많은 데이터가 하나의 사용자 엔티티(34)로부터 업로드되면, "다운로드 문제들"로 인해 사용자 엔티티(34)와 함께 작동하는 라디오 리소스 관리자(30)에서 몇몇 데이터가 드롭될 것이다. 솔루션은, MPD 또는 SDP에서 정의된 정보에 기초하여, X2 인터페이스[23]에서 정의된 메시지들을 확장하고, 사용자들의 각각에 대해 보장될 리소스들에 관한 구체적인 정보를 제공하는 메시지를 부가하는 것일 것이다. 그러한 방식에서, 양자의 eNB들은, 본 명세서를 통해 정의된 바와 같은 SDP 또는 MPD 내의 정보를 고려하여 협력적인 리소스 할당을 수행한다. 새로운 메시지는, 예를 들어, 표 11, 표 12, 및 표 13에 도시된 바와 같이, UE 리소스 상태 리포트이고 리소스 할당 IE를 포함할 수 있다.

후자의 실시예는, 이제 설명되는 의미로 미디어 지식 없는 협력적인 리소스 할당을 나타낸다. 즉, 예를 들어, 도 3을 참조한다. 도 3은 하나의 라디오 리소스 관리자(30)만을 도시하지만, 이미 상술된 바와 같이, 수 개의 라디오 리소스 관리자들의 시스템은, 상기 약술된 바와 같은 사용자 엔티티들(34)로부터의 품질 피드백, 서빙될 사용자 엔티티들(34)의 수 등과 같이 그 자신의 기지국(들)(32)을 통해 이동하는 정보에만 기초하여, 각각의 라디오 리소스 관리자(30)가 최적화에 의해 자신의 적어도 하나의 기지국(32)의 그의 통신 리소스들을 자신의 기지국들(32)의 도달범위 내에 있는 사용자 엔티티들(34)에 할당한다는 의미에서 서로 독립적으로 동작하는 모든 라디오 리소스 관리자들(30)을 이용하여 라디오 시스템을 형성할 수도 있다. 참조가 상기 설명에 대해 행해진다. 즉, 각각의 RRM은 서로 독립적으로 그 자신의 스케줄링을 수행한다. 그러나, 스케줄링의 독립성은, RRM들이 자신의 UE들로의 그들의 현재의 라디오 리소스 분배에 대한 정보를 다른 RRM들에서의 사용을 위해 외부로 분배한다는 의미에서 본 발명의 실시예에 따라 브레이크 스루(break through)된다. 상술된 예에서, 라디오 리소스 관리자들이, 존재한다면 미디어 프리젠테이션 설명들 내에 상주하는 정보를 활용하는 것이 필요하지는 않다. 그러나, 이제 설명되는 실시예에 따르면, 그럼에도 불구하고, 독립적으로 동작하는 라디오 리소스 관리자들(30)이, 클라이언트 및 그 상에서 동작하는 서버의 통신 쌍을 우연히 갖는 사용자 엔티티들에 비매칭(unmatched) 통신 리소스들을 불리하게 할당하는 것이 회피될 수도 있다. 이것은 다음과 같이 달성된다.

특히, 라디오 리소스 관리자는, i) 서버 및 클라이언트 중 다른 것에 현재 할당된 보장된 통신 리소스들, 또는 서버 및 클라이언트 중 다른 것의 버퍼 상태에 대한 정보를 획득하기 위해, 서버, 또는 사용자 엔티티들(34) 중 하나에서 동작하는 클라이언트를 향한 데이터 트래픽, 또는 라디오 리소스 관리자들 사이에서 교환되는 몇몇 제어 메시지들을 조사한다. 서버가 현재의 라디오 리소스 관리자(30)에 의해 서빙되는 사용자 엔티티(34) 상에서 동작하는 경우, 이러한 서버의 버퍼 상태는, 예를 들어, 출력 버퍼 상태, 즉 출력 버퍼의 충진 레벨을 형성할 수 있다. 이것은, 예를 들어, 라이브 스트리밍 또는 비디오 화상회의들의 경우 관심있을 수 있다. 클라이언트(40)가 사용자 엔티티(34) 상에서 동작하는 경우, 버퍼 상태는 클라이언트의 입력 버퍼의 충진 레벨일 것이다. 본 발명의 실시예에 따르면, 라디오 리소스 관리자(도 3)가 다른 라디오 리소스 관리자(30)에 의해 서빙된 서버 또는 클라이언트에 관한 이러한 정보를 획득한다는 것이 강조될 것이다. 단지, 클라이언트/서버 쌍의 대응부가 라디오 리소스 관리자(30) 그 자체에 의해 서빙된 사용자 엔티티(34) 상에서 동작하고 있다. 본 발명의 실시예에 따르면, 라디오 리소스 관리자(30)는, 사용자 엔티티(34)가 서빙되는 적어도 하나의 기지국(32)의 통신 리소스들의 할당을 수행하기 위해, 다른 장소에서 서빙된 사용자 엔티티 상에서 동작하는 클라이언트/서버 대응부에 관한 이러한 정보를 사용한다. 이러한 측정에 의해, 예를 들어, 클라이언트/서버 대응부의 버퍼 상태가 높거나 서버/클라이언트 대응부가 동작하는 외부 사용자 엔티티에 현재 할당된 보장된 통신 리소스들이 낮더라도, 라디오 리소스 관리자(30)가 불필요하게 증가된 통신 리소스들을 몇몇 사용자 엔티티(34)에게 할당하는 것을 회피하는 것이 가능하다.

이를 명확하게 하기 위해, 수 개의 라디오 리소스 관리자들을 포함하는 그러한 시스템을 도시한 도 17에 대한 참조가 행해진다. LTE 프레임워크에서, RRM들은 전술된 e노드B로부터의 것일 것이다. 라디오 리소스 관리자들 중 하나는 (30)으로 예시적으로 도시되고, 다른 것은 (30')로 도시된다. 2개의 관리자들만이 도시된다는 사실은 예시적일 뿐이다. 관리자들(30 및 30') 양자는, 각각, 그들의 적어도 하나의 각각의 기지국(32 및 32')의 그들의 통신 리소스들을 할당한다. 할당 또는 스케줄링은, 상호작용들이 이제 설명되는 제어 신호들 또는 데이터 트래픽 삽입을 수반한다는 것을 제외하고 서로 독립적으로 수행된다.

도 17에서, 하나의 사용자 엔티티(34)는 라디오 리소스 관리자(30)에 속하는 기지국(32)에 의해 서빙되는 것으로 예시적으로 도시되고, 다른 사용자 엔티티(34')는 라디오 리소스 관리자(30')에 속하는 기지국(32')에 의해 서빙되는 것으로 도시된다. 사용자 엔티티(34) 상에서, 클라이언트(40)가 동작하며, 서버(42)는 사용자 엔티티(34') 상에서 동작하는 것으로 예시적으로 도시된다. 양자는, 도 17의 파선에 의해 도시된 데이터 트래픽에 의해 서로 통신한다. 데이터 트래픽은 원격통신 타입, 다운로드 타입 등을 가질 수도 있다. 도 3에 관해 이미 설명된 바와 같이, 라디오 리소스 관리자들(30 및 30')이 데이터 트래픽에 의해 크로스(cross)되는 것이 필수적이지는 않다. 데이터 트래픽을 조사 및 검사하기 위해 라디오 리소스 관리자들(30 및 30') 양자만이 데이터 트래픽으로의 액세스를 가졌다는 것이 충분할 것이다.

RRM(30 및 30') 사이에서 잘못된-최적화(miss-optimization)를 회피하기 위해, 양자는, 각각의 다른 RRM에 대한 현재의 UE 버퍼 상태들 및 현재 보장된 비트레이트들에 관해 서로에게 통지한다.

제 1 대안에 따르면, 양자의 RRM은 서로에 인지가능하지 않게(agnostic) 유지될 수도 있다. 예를 들어, 서버 또는 클라이언트가 인터넷의 라디오 시스템 외부에서 서빙되는 경우라도, 잘못된-최적화가 회피될 수도 있도록, 각각의 정보가 클라이언트/서버 데이터 스트림에 삽입된다.

라디오 리소스 관리자(30')는, 예를 들어, 클라이언트(40)가 동작하는 사용자 엔티티(34)에 현재 할당된 보장된 통신 리소스들, 또는 이러한 클라이언트(40)의 버퍼 상태에 대한 정보를 획득하기 위해, 서버(32)로부터 클라이언트(40)를 향한 데이터 트래픽을 조사할 수 있다. 이러한 측정에 의해, 예를 들어, 클라이언트(40)의 버퍼 상태가 이미 높거나 사용자 엔티티(34)에 현재 할당된 보장된 통신 리소스들이 낮더라도, 라디오 리소스 관리자(30')는 서버(42)에 대해 너무 많은 통신 리소스들을 소비하는 것을 회피할 수 있다. 한편, 라디오 리소스 관리자(30)는, 사용자 엔티티(34')에 현재 할당된 보장된 정보 리소스들 또는 서버(42)의 버퍼 상태의 정보를 획득하기 위해 클라이언트(40)로부터 서버(42)를 향한 데이터 트래픽을 검사할 수 있다.

동일한 방식으로, 라디오 리소스 관리자(30)는 이러한 정보의 사용에 의해, 예를 들어, 서버(42)의 버퍼 상태가 피워진 상태의 충진 레벨에 접근하거나 사용자 엔티티(34')에 현재 할당된 보장된 통신 리소스들이 낮더라도, 사용자 엔티티(34)에 너무 많은 통신 리소스들을 할당하는 것을 회피할 수 있다.

이미 상술된 바와 같이, 보장된 통신 리소스는, 라디오 리소스 관리자들(30 및 30')이 자신의 서빙된 사용자 엔티티들(34)로의 자신의 기지국(들)(32)의 통신 리소스들의 할당 내에서 결정하는 어떤 것일 수 있다. 즉, 라디오 리소스 관리자(30 및 30') 각각은, 예를 들어, 3 내지 10초의 시간 간격들과 같은 몇몇 시간 간격들의 단위들로 사용자 엔티티들(34 및 34')에 보장된 통신 리소스들을 할당한다. 그들은 또한, 그들 시간 간격들 내에서 통신 리소스들을 할당할 시에, 보장된 통신 리소스들을 준수한다(obey). 라디오 리소스 관리자들(30 및 30') 중 어느 하나는 시간 간격들을 통해 고정적으로, 보장된 통신 리소스들을 사용하거나, 그들은 사용자 엔티티들에 할당된 통신 리소스들을 변경시키지만, 보장된 통신 리소스들에 의해 부과된 제한들 내에서만 변경시킨다.

외부 라디오 리소스 관리자의 도메인으로부터 버퍼 상태 또는 보장된 통신 리소스들의 정보가 데이터 트래픽을 통해 클라이언트/서버 대응부를 서빙하는 라디오 리소스 관리자의 라디오 리소스 관리자의 도메인을 어떻게 입력하는지에 관한 상이한 가능성들이 존재한다. 예를 들어, 라디오 리소스 관리자들(30 및 30')은, 자신의 서빙된 사용자 엔티티에 할당된 보장된 통신 리소스들에 대한 정보를, 그의 서빙된 사용자 엔티티 상에서 구동하는 클라이언트(40) 또는 서버(42)로부터의 데이터 트래픽에 삽입하도록 구성될 수 있다. 예를 들어, 라디오 리소스 관리자(30')는 서버(42)로부터 클라이언트(40)로의 데이터 스트림에, 사용자 엔티티(34')에 할당된 보장된 통신 리소스들에 관한 정보를 삽입할 수 있고, 차례로, 라디오 리소스 관리자(30)는 클라이언트(40)로부터 서버(42)로의 데이터 트래픽에, 사용자 엔티티(34)에 할당된 보장된 통신 리소스들에 관한 정보를 삽입할 수 있다. 추가적으로, 삽입은 반드시, 라디오 리소스 관리자들(30 및 30')에 의해 단독으로 수행될 필요는 없다. 전술한 실시예에 관해 이미 상술된 바와 같이, 그러한 삽입은 또한, 사용자 엔티티들(34 및 34') 각각 상에서 구동하는 리소스 관리자들(74)에 의해 수행될 수 있다. 그 경우, 라디오 리소스 관리자들(30 및 30')은 사용자 엔티티들(34 및 34') 각각에, 그들의 보장된 통신 리소스들, 즉, 그들이 동작하고 있는 사용자 엔티티들(34 및 34')에 할당된 보장된 통신 리소스들에 대해 통지할 것이며, 이러한 정보는 리소스 관리자들(74)에 의해 조사 및 검사될 것이고, 리소스 관리자들(74)은 차례로, 라디오 리소스 관리자 대신에 상술된 삽입을 수행한다.

제 2 대안에 따르면, 양자의 RRM들(30 및 30')은 현재의 UE 버퍼 상태들 및 제어 신호들(199)을 통해 각각의 다른 RRM에 그들에 의하여 서빙된 UE들에 관한 현재 보장된 비트레이트들에 관해 서로에게 통지한다. 예를 들어, LTE 아키텍처에서, 그러한 제어 신호들은, 예를 들어, 오퍼레이터로서 HSS를 사용하여 X2 인터페이스, S-GW 등을 통해 RRM들 사이에서 교환될 수 있으며, 그에 따라, 그 오퍼레이터는 제어 신호 교환의 경로를 지향시킨다. 이러한 예에 따르면, 라디오 리소스 관리자들(30 및 30')은, 예를 들어, 다음의 단계들, 즉, 1) 그들에 의해 서빙된 사용자 엔티티 상에서 동작하는 클라이언트 또는 서버가 즉시적인 송신 세션, 즉 이러한 클라이언트 또는 서버 시작들을 수반하는 미디어 송신 세션을 셋업하려고 추구하는 것을 실현하는 단계; 2) 미디어 송신 세션이 셋업되는 대응부, 즉 서버 또는 클라이언트가 라디오 시스템의 다른 RRM들 중 임의의 RRM에 의해 서빙되는지를 체크하는 단계; 3) 서빙된다면, 제어 신호들(199)을 미디어 송신 세션에 덧붙이는(accompany) 단계를 수행할 것이다. 예를 들어, 제어 신호들에 대한 경로는 HSS를 통해 지향된다. 예를 들어, 라디오 리소스 관리자(30)는 제어 신호들(199)을 통해 라디오 리소스 관리자(30')에 클라이언트의 버퍼 상태를 통지하며, 여기서, 라디오 리소스 관리자(30)는 상술된 바와 같이, 즉, 사용자 엔티티(34) 내의 리소스 관리(74)로부터의 시뮬레이션 또는 피드백에 의해 이러한 정보를 획득할 수도 있다. 또는, 라디오 리소스 관리자(30)는, 사용자 엔티티(34)에 할당된 보장된 라디오 리소스들에 대해 제어 신호들(199)을 통하여 라디오 리소스 관리자(30)에게 통지할 수도 있다. 라디오 리소스 관리자(30')는 미디어 송신 세션 동안 반대 방향에서 동일한 것을 행한다. 즉, 라디오 리소스 관리자(30')는 제어 신호들(190)을 통해 라디오 리소스 관리자(30)에게, 사용자 엔티티(34')에 대한 서버의 버퍼 상태 및/또는 보장된 라디오 리소스들을 통지한다.

자연적으로, 상술된 실시예는 또한, 전술된 실시예들 중 임의의 실시예와 결합가능할 것이다. 이것은, 예를 들어, 라디오 리소스 그 자체에 의해 서빙되는 사용자 엔티티 상에서 동작하는 클라이언트 또는 서버의 버퍼 상태가 통신 리소스 할당을 수행하기 위해 라디오 리소스 관리자에 의하여 사용되는 실시예들이 관련되는 한, 참이다.

표 11은 [23]의 섹션 9.2.13의 메시지 타입 표를 다음과 같이 확장시킨다.

새로운 메시지 타입 - UE 리소스 상태 리포트

IE /그룹 명칭	존재	범위	IE 타입 및 참조	시맨틱 설명
절차 코드	M		정수(0...255)	“0” = 핸드오버 준비 “1” = 핸드오버 취소 “2” = 로드 표시 “3” = 에러 표시 “4” = SN 상태 전달 “5” = UE 콘텍스트릴리즈 “6” = X2 셋업 “7” = 리셋 “8” = eNB 구성 업데이트 “9” = 리소스 상태 리포팅 시작 “10” = 리소스 상태 리포팅 “11” = 사설 메시지 “12” = 모바일러티셋팅 변화 “13” = 라디오 링크 실패 표시 “14” = 핸드오버 리포트 “15” = 셀 활성화 “16” = UE 리소스 상태 리포트
메시지의 타입	M		선택(메시지를 시작, 성공적인 결과, 성공적이지 않은 결과, …)

표 12는 UE 리소스 상태 리포트의 신택스를 도시한다.

UE 리소스 상태 리포트 신택스

IE /그룹 명칭	존재	범위	IE 타입 및 참조	시맨틱 설명	임계도	할당된 임계도
메시지 타입	M		9.2.13		예	거부
사용자 장비(UE) 식별자	M			UE의 식별, 예를 들어, TMSI	예	거부
UE 할당된 리소스 정보		0..1		UE에 대해 할당된 리소스들에 관한 정보	예	무시

표 13은 UE 할당된 리소스 정보 IE의 신택스를 도시한다.

UE 할당된 리소스 정보 (버전 1)

IE /그룹 명칭	존재	범위	IE 타입 및 참조	시맨틱 설명
현재 제공된 다운링크 비트레이트			비트 레이트 9.2.11	설명: 이러한 IE는, 데이터가 타겟 e노드B에 의해 송신되는 UE에 할당된 제 1 다운링크 비트 레이트를 표시함
현재 제공된 업링크 비트레이트			비트 레이트 9.2.11	설명: 이러한 IE는, 데이터가 타겟 e노드B에 의해 송신되는 UE에 할당된 제 1 업링크 비트 레이트를 표시함

대안적으로, (미디어 특징들에 기초한) SDP 또는 MPD에 기초하는 다양한 비트레이트들은, 다음의 표에 도시된 바와 같이 최대 지원된 비트레이트를 제공받을 수 있다.

UE 할당된 리소스 정보 (버전 2)

IE /그룹 명칭	존재	범위	IE 타입 및 참조	시맨틱 설명
현재 제공된 다운링크 비트레이트			비트 레이트 9.2.11	설명: 이러한 IE는, 데이터가 타겟 e노드B에 의해 송신되는 UE에 할당된 제 1 다운링크 비트 레이트를 표시함
현재 제공된 업링크 비트레이트			비트 레이트 9.2.11	설명: 이러한 IE는, 데이터가 타겟 e노드B에 의해 송신되는 UE에 할당된 제 1 업링크 비트 레이트를 표시함
N			정수	대안적인 다운링크 비트레이트들의 수
M			정수	대안적인 업링크비트레이트들의 수
E-RAB 대안적인 다운링크 비트 레이트 1	M		비트 레이트 9.2.11	설명: 이러한 IE는, 제 1 대안적인 다운링크 비트 레이트를 표시함
…
E-RAB 대안적인 다운링크 비트 레이트 N	M		비트 레이트 9.2.11	설명: 이러한 IE는, 제 N 대안적인 다운링크 비트 레이트를 표시함
E-RAB 대안적인 업링크 비트 레이트 1	M		비트 레이트 9.2.11	설명: 이러한 IE는, 제 1 대안적인 업링크 비트 레이트를 표시함
…
E-RAB 대안적인 업링크 비트 레이트 M	M		비트 레이트 9.2.11	설명: 이러한 IE는, 제 M 대안적인 업링크 비트 레이트를 표시함

표준화된 QCI 특징들 [cp. 19]

QCI	리소스 타입	우선순위	패킷 지연 버짓 (주석 1)	패킷 에러 손실 레이트 (주석 2)	예시적인 서비스
1 (주석 3)	GBR	2	100ms	10 ^-2	종래의 음성
2 (주석 3)	GBR	4	150ms	10^-3	종래의 비디오(라이브 스트리밍)
2-2 (부가적인 주석 참조)	최소만을 그리고 대안적인 더 높은 비트레이트들을 갖는 GBR	4	150ms	10 ^-3	종래의 비디오(라이브 스트리밍) 주석: 여기서, UE는 , 다운링크 뿐만 아니라 업링크에 대해 대안물들인 비트 레이트이라는 것을 표시함
3 (주석 3)	GBR	3	50ms	10 ^-3	실시간 게이밍
4 (주석 4)	GBR	5	300ms	10^-6	비-대화형 비디오(버퍼링된스트리밍)
4-2 (부가적인 주석 참조)	최소만을 그리고 대안적인 더 높은 비트레이트들을 갖는 GBR	5	300ms	10 ^-6	적응적인 비-대화형 비디오( 버퍼링된스트리밍 , 예를 들어, HTTP 스트리밍) 주석: UE는 , 새로운 QCI 값을 표시하는 것을 통해 대안적인 비트레이트들의 존재를 표시할 수도 있지만, GBR 및 MBR의 기존의 값들보다 작은 대안적인 비트레이트들의 리스트를 완전히 백워드호환가능하게 부가하는 것이 또한 가능할 수도 있다.
5 (주석 3)	비- GBR	1	100ms	10 ^-6	IMS 시그널링
6 (주석 4)	비- GBR	6	300ms	10^-6	비디오(버퍼링된스트리밍) TCP-기반(예를 들어, www, 이메일, 챗, ftp, p2p 파일 공유, 프로그래시브 비디오 등)
6-2 (부가적인 주석 참조)	대안적인 비트 레이트들을 갖는 비- GBR	6	300ms	10 ^-6	적응적 비디오( 버퍼링된스트리밍 ) TCP-기반(예를 들어, www, 이메일, 챗, ftp, p2p 파일 공유, 프로그래시브 비디오, HTTP 스트리밍 등) 주석: UE는 새로운 QCI 값을 표시하는 것을 통해 대안적인 비트레이트들의 존재를 표시할 수도 있지만, GBR 및 MBR의 기존의 값들보다 작은 대안적인 비트레이트들의 리스트를 완전히 백워드호환가능하게 부가하는 것이 또한 가능할 수도 있다. 비 - GBR 서비스들에 대해 일반적인 것으로서 GBR 및 MBR을 기대하지 않는 경우, 이들 필드들은 프리젠테이션될 수도 있지만, 널로 셋팅되어야 한다.
7 (주석 3)	비- GBR	7	100ms	10 ^-3	음성, 비디오(라이브 스트리밍) 인터액티브게이밍
8 (주석 5)		8	300ms	10^-6	비디오(버퍼링된스트리밍) TCP-기반(예를 들어, www, 이메일, 챗, ftp, p2p 파일 공유, 프로그래시브 비디오 등)
9 (주석 6)		9	300ms	10^-6
주석 1: PCEF와 라디오 기지국 사이의 지연에 대한 20ms의 지연은, 라디오 인터페이스에 적용하는 패킷 지연 버짓을 도출하기 위해, 주어진 PDB로부터 감산되어야 한다. 이러한 지연은, PCEF가 라디오 기지국 “근방”에 위치되는 경우(대략 10ms)와 PCEF가 라디오 기지국으로부터 “떨어져” 위치되는 경우, 예를 들어, 홈 라우팅된트래픽을 이용하여 로밍하는 경우(유럽과 미국 서부 해안 사이의 단방향패킷 지연은 대략 50ms임) 사이의 평균이다. 평균은 로밍이 덜 통상적인 시나리오라는 것을 고려한다. 주어진 PDB로부터 20ms의 이러한 평균 지연을 감산하는 것이 가장 통상적인 경우들에서 원하는 엔드-투-엔드 성능을 유도할 것이라고 기대된다. 또한, PDB가 상한을 정의함을 유의한다. UE가 충분한 라디오 채널 품질을 갖고 있는 한, 실제 패킷 지연들, 즉 특히, GBR 트래픽에 대한 지연들은, QCI에 대해 특정된 PDB보다 통상적으로 더 낮아야 한다. 주석 2: 라디오 기지국과 PCEF 사이에서 발생할 수도 있는 비 혼잡 관련 패킷 손실들의 레이트는무시가능한 것으로 간주되어야 한다. 따라서, 표준화된 QCI에 대해 PELR 값은, UE와 라디오 기지국 사이의 라디오 인터페이스에 완전히 적용된다. 주석 3: QCI는, 오퍼레이터 제어된 서비스, 즉, SDF 어그리게이트가 인가된 시점에 SDF 어그리게이트의업링크/다운링크 패킷 필터들이 알려진 서비스와 통상적으로 연관된다. E-UTRAN의 경우, 이것은, 대응하는 전용 EPS 베어러가 설정/변형되는 시점이다. 주석 4: 네트워크가 멀티미디어 우선순위 서비스들(MPS)을 지원하면, 이러한 QCI는 MPS 가입자들의 비 실시간 데이터(즉, 가장 통상적으로는 TCP-기반 서비스들/애플리케이션들)의 우선순위화를 위해 사용될 수 있다. 주석 5: 이러한 QCI는 임의의 가입자/가입자 그룹에 대한(예를 들어, 프리미엄 콘텐츠와 연관된) 전용 “프리미엄 베어러”에 대해 사용될 수 있다. 또한 이러한 경우, SDF 어그리게이트의업링크/다운링크 패킷 필터들은, SDF 어그리게이트가 인가되는 시점에 알려진다. 대안적으로, 이러한 QCI는 “프리미엄 가입자들”에 대한 UE/PDN의 디폴트 베어러에 대해 사용될 수 있다. 주석 6: 이러한 QCI는, 비 특권 가입자들에 대한 UE/PDN의 디폴트 베어러에 대해 통상적으로 사용된다. 디폴트 베어러 상에서 동일한 QCI를 갖는 동일한 PDN에 접속된 가입자 그룹들 사이의 구별을 가입자에게 제공하기 위한 “툴”로서 AMBR이 사용될 수 있음을 유의한다.

또한 상술된 바와 같이, 상기 실시예들은 그 중에서도, 라디오 리소스 기지국(32)과의 통신을 위해 사용자 엔티티(34) 상에서 동작하기 위한 소프트웨어, 하드웨어, 또는 프로그래밍가능 하드웨어와 같은 클라이언트를 나타내며, 클라이언트(40)는 서버(42)로부터 미디어 프리젠테이션 설명 및 미디어 콘텐츠(44)를 리트리브하도록 구성되고, 미디어 프리젠테이션 설명(46)은 미디어 콘텐츠(44)의 상이한 대역폭들의 버전들을 설명하고, 클라이언트는, 기지국(32)의 통신 리소스들을 사용자 엔티티에 할당하는 것을 담당하는 라디오 리소스 관리자(30)로부터의 시그널링화에 의해 통상 모드로부터 슬레이브(slave) 모드로 스위칭가능하도록 구성되며, 여기서, 클라이언트는, 통상 모드에서, 사용자 엔티티에 할당된 통신 리소스들에 기초하여 클라이언트에 의해 결정된 버전으로 서버(42)로부터 미디어 콘텐츠(44)를 요청하고, 슬레이브 모드에서, 사용자 엔티티에 할당된 통신 리소스들에 관계없이 클라이언트에 의해 결정된 버전으로 서버(42)로부터 미디어 콘텐츠(44)를 요청하도록 구성된다. 클라이언트는 추가적으로, 통상 모드에서, 사용자 엔티티에 할당된 통신 리소스들 및 미디어 콘텐츠의 버퍼 상태에 기초하여 클라이언트에 의해 결정된 버전으로 서버(42)로부터 미디어 콘텐츠(44)를 요청하도록 구성될 수도 있다. 클라이언트는 또한 추가적으로, 슬레이브 모드에서, 미디어 프리젠테이션 설명(46)에서 상이한 대역폭의 버전들 중에서 가장 높은 대역폭 버전에 대응하는 버전으로 연속적으로 서버(42)로부터 미디어 콘텐츠(44)를 요청하도록 구성될 수도 있다. 즉, 클라이언트 작동은, 예를 들어, MPD 내의 @automaticSwitching 표시자에 의해 제어될 수 있으며, 클라이언트는, 셀 리소스들을 최적화하기 위해 중간의 디바이스가 선택된 세그먼트들의 비트레이트를 중간으로 조정할 수도 있다는 것을 통지받을 수도 있으므로, 클라이언트는 비트레이트 변화들 그 자체에 반응하지 않아야 한다.

몇몇 양상들이 장치의 맥락에서 설명되었지만, 이들 양상들이 또한 대응하는 방법의 설명을 표현하며, 여기서, 블록 또는 디바이스는 방법 단계 또는 방법 단계의 특성에 대응함이 명백하다. 유사하게, 방법 단계의 맥락에서 설명된 양상들은 또한, 대응하는 장치의 대응하는 블록 또는 아이템 또는 특성의 설명을 표현한다. 방법 단계들 중 몇몇 또는 전부는, 예를 들어, 마이크로프로세서, 프로그래밍가능 컴퓨터 또는 전자 회로와 같은 하드웨어 장치에 의해 (또는 사용하여) 실행될 수도 있다. 몇몇 실시예들에서, 가장 중요한 방법 단계들 중 몇몇의 하나 또는 그 초과는 그러한 장치에 의해 실행될 수도 있다.

특정한 구현 요건들에 의존하여, 본 발명의 실시예들은 하드웨어 또는 소프트웨어로 구현될 수 있다. 구현은 전자적으로 판독가능한 제어 신호들이 저장된 디지털 저장 매체, 예를 들어, 플로피 디스크, DVD, 블루-레이, CD, ROM, PROM, EPROM, EEPROM 또는 플래시 메모리를 사용하여 수행될 수 있으며, 이들은, 각각의 방법이 수행되도록, 프로그래밍가능 컴퓨터 시스템과 협력한다(또는 협력할 수 있다). 따라서, 디지털 저장 매체는 판독가능한 컴퓨터일 수도 있다.

본 발명에 따른 몇몇 실시예들은, 여기에 설명된 방법들 중 하나가 수행되도록, 프로그래밍가능 컴퓨터 시스템과 협력할 수 있는 전자적으로 판독가능 제어 신호들을 갖는 데이터 캐리어를 포함한다.

일반적으로, 본 발명의 실시예들은 프로그램 코드를 갖는 컴퓨터 프로그램 물건으로서 구현될 수 있으며, 프로그램 코드는, 컴퓨터 프로그램 물건이 컴퓨터 상에서 구동하는 경우, 방법들 중 하나를 수행하기 위해 동작된다. 프로그램 코드는, 예를 들어, 머신 판독가능 캐리어 상에 저장될 수도 있다.

다른 실시예들은, 머신 판독가능 캐리어 상에 저장되는, 여기에 설명된 방법들 중 하나를 수행하기 위한 컴퓨터 프로그램을 포함한다.

즉, 따라서, 본 발명의 방법의 실시예는 컴퓨터 프로그램이 컴퓨터 상에서 구동하는 경우, 여기에 설명된 방법들 중 하나를 수행하기 위한 컴퓨터 코드를 갖는 컴퓨터 프로그램이다.

따라서, 본 발명의 방법들의 추가적인 실시예는, 상부에 기록된, 여기에 설명된 방법들 중 하나를 수행하기 위한 컴퓨터 프로그램을 포함하는 데이터 캐리어(또는 디지털 저장 매체, 또는 컴퓨터-판독가능 매체)이다. 데이터 캐리어, 디지털 저장 매체 또는 기록된 매체는 통상적으로 유형(tangible)이고 그리고/또는 비-일시적이다(non-transitonay).

따라서, 본 발명의 방법의 추가적인 실시예는, 여기에 설명된 방법들 중 하나를 수행하기 위한 컴퓨터 프로그램을 표현하는 데이터 스트림 또는 신호들의 시퀀스이다. 데이터 스트림 또는 신호들의 시퀀스는, 예를 들어, 데이터 통신 접속을 통해, 예를 들어, 인터넷을 통해 전달되도록 구성될 수도 있다.

추가적인 실시예는, 여기에 설명된 방법들 중 하나를 수행하도록 구성되거나 적응되는 프로세싱 수단, 예를 들어, 컴퓨터 또는 프로그래밍가능 로직 디바이스를 포함한다.

추가적인 실시예는, 여기에 설명된 방법들 중 하나를 수행하기 위한 컴퓨터 프로그램이 인스톨된 컴퓨터를 포함한다.

본 발명에 따른 추가적인 실시예는, 여기에 설명된 방법들 중 하나를 수행하기 위한 컴퓨터 프로그램을 (예를 들어, 전기적으로 또는 광학적으로) 수신기에 전달하도록 구성된 장치 또는 시스템이다. 수신기는, 예를 들어, 컴퓨터, 모바일 디바이스, 메모리 디바이스 등일 수도 있다. 장치 또는 시스템은, 예를 들어, 컴퓨터 프로그램을 수신기에 전달하기 위한 파일 서버를 포함할 수도 있다.

몇몇 실시예들에서, 프로그래밍가능 로직 디바이스(예를 들어, 필드 프로그래밍가능 게이트 어레이)는 여기에 설명된 방법들의 기능들 중 몇몇 또는 전부를 수행하는데 사용될 수도 있다. 몇몇 실시예들에서, 필드 프로그래밍가능 게이트 어레이는, 여기에 설명된 방법들 중 하나를 수행하기 위해 마이크로프로세서와 협력할 수도 있다. 일반적으로, 방법은 임의의 하드웨어 장치에 의해 바람직하게 수행된다.

상술된 실시예들은 본 발명의 원리들에 대해 단지 예시적일 뿐이다. 여기에 설명된 어레인지먼트(arrangement)들 및 세부사항들의 변경들 및 변화들이 당업자들에게 명백할 것이 이해된다. 따라서, 본 명세서의 실시예들의 설명 및 해설에 의해 프리젠테이션된 특정한 세부사항들이 아니라 다음의 특허 청구항들의 범위에 의해서만 제한되는 것이 의도이다.

약어들 및 심볼들의 리스트

eNB	이벌브드 노드 B(3G 기지국), 종종 e노드B
DASH	HTTP를 통한 동적 적응적 스트리밍
LTE	롱텀 에볼루션
UE	사용자 장비(사용자 단말)
MPD	미디어 프리젠테이션 설명
RRM	라디오 리소스 관리
TDD	시분할 듀플렉스
FDD	주파수 분할 듀플렉스
MIMO	다중 입력 다중 출력
OFDM	직교 주파수 분할 듀플렉싱
OFDMA	직교 주파수-분할 다중 액세스
AVC	진보된 비디오 코딩
SVC	스캐일러블 비디오 코딩
MVC	멀티뷰 비디오 코딩
W3C	월드 와이드 웹 콘소시엄
MME	모바일러티 관리 엔티티
CQI	채널 품질 정보
S-GW	서빙 게이트웨이
IE	정보 엘리먼트
GTP	GPRS 터널링 프로토콜
GPRS	범용 패킷 라디오 서비스
HSS	홈 가입자 서비스

참조 문헌들의 리스트

[1] Cisco White Paper, "Cisco Visual Networking Index: Forecast and Methodology, 2009-2014," June 2010.

[2] Cisco White Paper, "Cisco Visual Networking Index: Global Mobile Data-Traffic Forecast Update," 2010-2015.

[3] Information technology - Dynamic adaptive streaming over HTTP (DASH) - Part 1, "Media presentation description and segment formats, ISO/IEC DIS 23009-1," August 2011.

*[4] 3GPP, "Transparent end-to-end Packet-switched Streaming Service (PSS); Protocols and codecs (Release 9); 3GPP TS 26.234 V9.3.0 (2010-06): Adaptive HTTP Streaming".

[5] A. Zambelli, ""IIS smooth streaming technical overview". Microsoft Corporation, 2009”.

*[6] HTTP Live Streaming Architecture, "Technical report, Apple Inc.," 2010.

*[7] T. Wiegand, G. J. Sullivan, G. Bjøntegaard and A. Luthra, "Overview of the H.264/AVC Video Coding Standard," in IEEE Transactions on Circuits and Systems for Video Technology, 2003.

[8] A. Tacz, A. Temesvary and N. Reider, "Handover Performance in 3GPP Long Term Evolution (LTE) Systems," in Mobile and wireless Communications Summit, 2007.

*[9] T. Stockhammer, M. Walter and G. Liebl, "Optimized H. 264-Based Bitstream Switching for Wireless," in ICME, 2005.

[10] S. Sharma, D. Gillies and W. Feng, "On the Goodput of TCP NewReno in Mobile Networks," in ICCCN, 2010.

[11] H. Schwarz, D. Marpe and T. Wiegand, "Overview of the scalable video coding extension of the H.264/AVC standard," in IEEE Transactions on Circuits and Systems for Video Technology, 2007.

[12] T. Schierl, Y. Sanchez, R. Globisch, C. Hellge and T. Wiegand, "Priority-based Media Delivery using SVC with RTP and HTTP streaming," in Springer Multimedia Tools and Application, September 2010.

[13] W. Mulder and T. Wirth, "Are we ready for the femtolution?," in IEEE COMSOC MMTC E-letter, Sep. 2010.

[14] ITU-R, Report M.2134, "Requirements related to technical performance for IMT-Advanced radio interface(s), Approved in Nov 2008".

[15] 3GPP, "Physical layer; General description (Release 8); 3GPP TS 25.201 V8.1.0 (2008-05): Adaptive HTTP Streaming".

[16] 3GPP, "Evolved Universal Terrestrial Radio Access (E-UTRA) and evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description (Release 8); 3GPP TS 36.300 V8.12.0 (2010-03): Adaptive HTTP Streaming".

[17] Leekwijck, Y. Sanchez, T. Schierl, C. Hellge, T. Wiegand, D. Hong, D. De Vleeschauwer and W. Van, "iDASH: improved Dynamic Adaptive Streaming over HTTP using Scalable Video Coding," in ACM Mmsys, 2011.

[18] J. Mahdavi and S. Floyd. TCP-friendly unicast rate-based flow control. January, 1997

[19] 3GPP TS 23202, Policy and charging control architecture, Release 113GPP TS

[20] 24301, Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS)

[21] 3GPP TS 29274, Evolved Packet System (EPS); Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for Control plane (GTPv2-C); Stage 3

[22] 3GPP TS 36413, Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1 Application Protocol (S1AP)

[23] 3GPP TS 36423, 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access Network (E-UTRAN); X2 application protocol (X2AP) (Release 11)

[24] 3GPP TS 36420, 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access Network (E-UTRAN); X2 general aspects and principles

(Release 11)

Claims

리소스 관리자로서
사용자 엔티티(34)에서 동작하는 클라이언트(40)로부터 서버(42)로의 미디어 요청(60)을 검사하고 － 상기 미디어 요청은 상기 서버로부터 상기 클라이언트로 전송된 미디어 프리젠테이션 설명(46)에 기재된 상이한 대역폭들의 미디어 콘텐츠의 버전들 중에서 미디어 콘텐츠(44)의 원하는 버전를 요청하는 것임 －;
상기 서버에 상기 미디어 요청(60)을 포워딩하거나, 대안적으로는, 상기 미디어 요청(60)이 상기 클라이언트(40)에 전송되는 상기 미디어 콘텐츠(44)의 원하는 버전으로 유도되지 않는다는 것을 야기하도록 결정
하도록 구성되는, 리소스 관리자.
제 1 항에 있어서,
변경된 미디어 요청이 더 적은 대역폭의 상기 미디어 콘텐츠(44)의 버전을 요청하는 정도로 상기 미디어 요청(60)을 변경시키거나, 또는 상기 미디어 요청(60)을 인터셉트하고, 상기 서버(42)로부터 상기 클라이언트(40)로 비-이용가능도(non-availability) 응답을 다시 전송하도록 상기 서버(42)를 에뮬레이팅하거나 상기 서버(42)에 명령함으로써 상기 야기를 수행하도록 구성되는, 리소스 관리자.
제 1 항에 있어서,
상기 미디어 콘텐츠(44)의 원하는 버전으로서 상기 미디어 콘텐츠(44)의 버전과 연관된 더 낮은 최소 대역폭을 갖는 상기 미디어 콘텐츠(44)의 버전을 상기 미디어 프리젠테이션 설명(46) 내에서 식별하기 위해 상기 미디어 프리젠테이션 설명(46)을 검사하도록 추가적으로 구성되며,
상기 리소스 관리자는, 상기 미디어 콘텐츠(44)의 버전과 연관된 더 낮은 최소 대역폭을 갖는 그러한 버전이 존재한다면, 현재의 리소스 상황 정보에 의존하여 상기 결정을 수행하도록 구성되는, 리소스 관리자.
제 1항에 있어서,
상기 리소스 관리자는, 상기 클라이언트가 동작하는 상기 사용자 엔티티가 속하는 사용자 엔티티들로의 적어도 하나의 기지국의 통신 리소스들의 할당을 수행하도록 추가적으로 구성되는, 리소스 관리자.
제 1 항에 있어서,
상기 리소스 관리자는, 상기 사용자 엔티티의 트랜시버 스테이지(transceiver stage; 70)와 상기 클라이언트(40) 사이에서 상기 사용자 엔티티 내에 배열되며,
상기 리소스 관리자는, 상기 트랜시버 스테이지(70)로부터 현재의 리소스 상황 정보를 획득하도록 구성되는, 리소스 관리자.
제 1 항에 있어서,
현재의 리소스 상황 정보에 의해 포함되는 상기 사용자 엔티티로부터 기지국으로의 채널 품질 피드백에 기초하여 사용자 엔티티의 버퍼링 상태를 시뮬레이팅하고, 상기 사용자 엔티티의 버퍼링 상태에 의존하여 상기 결정을 수행하도록 추가적으로 구성되는, 리소스 관리자.