KR20140017662A

KR20140017662A - 모바일 송수신기, 기지국 송수신기, 데이터 서버, 그리고 관련 장치, 방법 및 컴퓨터 프로그램

Info

Publication number: KR20140017662A
Application number: KR1020137032124A
Authority: KR
Inventors: 스테판 발렌틴; 마티아스 카스츄브; 마그너스 프로에브스터; 토마스 워스만; 크리스티안 뮬러
Original assignee: 알까뗄 루슨트
Priority date: 2011-06-04
Filing date: 2012-06-01
Publication date: 2014-02-11
Also published as: JP2014522145A; US20140098778A1; EP2530988B1; CN103583074B; BR112013031078A2; EP2530989A1; EP2530988A1; CN103597894A; US20140106770A1; KR101597013B1; JP5897116B2; KR20140035479A; WO2012168135A1; ES2556381T3; JP5933703B2; ES2544537T3; CN103597894B; US9271297B2; BR112013031078B1; WO2012168152A1

Abstract

실시예들은 모바일 송수신기, 기지국 송수신기 및 데이터 서버에 대한 장치, 방법 및 컴퓨터 프로그램에 관한 것이다. 모바일 송수신기 장치(10)는 모바일 송수신기(100) 상에서 실행 중인 응용 프로그램으로부터의 상황 정보, 모바일 송수신기(100) 상에서 실행 중인 운영 체제로부터의 상황 정보, 또는 모바일 송수신기(100)의 하드웨어 드라이버 또는 하드웨어로부터의 상황 정보를 추출하는 수단(12)을 포함하고, 상황 정보는 응용 프로그램의 상태에 관한 정보 및/또는 모바일 송수신기(100)의 상태에 관한 정보를 포함한다. 이 장치(10)는 기지국 송수신기(200)와 데이터 패킷을 통신하는 수단(14)을 추가로 포함하고, 데이터 패킷은 페이로드 데이터 패킷 및 제어 데이터 패킷을 포함하며, 통신하는 수단(14)은 기지국 송수신기(200)를 통해 데이터 서버(300)와 응용 프로그램과 연관되어 있는 페이로드 데이터 패킷을 통신하는 동작을 한다. 이 장치(10)는 상황 정보를 기지국 송수신기(200)에 제공하는 수단(16)을 추가로 포함하고, 상황 정보는 페이로드 데이터 패킷에 또는 제어 데이터 패킷에 포함되어 있다. 대응하는 기지국 송수신기 장치는 모바일 송수신기로부터 직접 또는 대응하는 데이터 서버 장치를 통해 간접적으로 상황 정보를 수신한다.

Description

모바일 송수신기, 기지국 송수신기, 데이터 서버, 그리고 관련 장치, 방법 및 컴퓨터 프로그램{MOBILE TRANSCEIVER, BASE STATION TRANSCEIVER, DATA SERVER, AND RELATED APPARATUSES, METHODS, AND COMPUTER PROGRAMS}

본 발명의 실시예는 통신 시스템에 관한 것으로서, 보다 상세하게는 모바일 통신 시스템에서의 패킷 데이터 전송(이것으로만 제한되지 않음)에 관한 것이다.

모바일 서비스에 대한 보다 높은 데이터 전송률의 요구가 지속적으로 증가하고 있다. 이와 동시에, 3세대 시스템(3G) 및 4세대 시스템(4G) 등의 최근의 모바일 통신 시스템은 보다 높은 스펙트럼 효율을 가능하게 해주고 보다 높은 데이터 전송률 및 셀 용량을 가능하게 해주는 향상된 기술을 제공한다. 오늘날의 핸드헬드(handheld)의 사용자들을 만족시키는 것이 더욱 어려워지고 있다. 이전의 피처 폰(feature phone)은 데이터 또는 음성 트래픽만을 발생하였지만, 현재의 스마트폰, 태블릿 및 넷북은 서로 근본적으로 상이할 수 있는 다양한 응용 프로그램들을 병렬로 실행한다. 피처 폰과 비교하여, 이러한 응용 프로그램 혼합 구성(application mix)은 다수의 새로운 특성들을 가져다준다. 예를 들어, 고도로 동적인 부하 통계가 얻어진다.

종래의 셀룰러 네트워크는 데이터 트래픽에 의해 점점 더 과부하가 걸리고 있다[G. Maier, F. Schneider, A. Feldmann. "A First Look at Mobile Hand-held Device Traffic", In Proc. Int. Conference on Passive and Active Network Measurement (PAM '10), April 2010을 참조]. 이 높은 부하는 주로 스마트폰, 태블릿 및 랩톱 등의 스마트 핸드헬드(smart handheld)에 의해 야기되며, 이 스마트 핸드헬드는 이전의 핸드헬드 세대보다 상당히 더 많은 트래픽을 발생할 수 있고, 기지국에서 효율적으로 서비스되지 않을 수 있는 복잡한 트래픽 요청을 야기할 수 있으며, 점점 더 많은 사용자 세션을 다수의 셀들을 거치게 하여 세션당 네트워크 효율을 감소시킬 수 있다.

게다가, 스마트 핸드헬드는, 이전의 핸드헬드 세대와 비교할 때, 사용자에 관한 더 많은 정보를 제공한다. CARA(Context-Aware Resource Allocation, 상황 인식 자원 할당)는 사용자의 디바이스, 그의 위치, 및 그의 현재 실행 중인 응용 프로그램의 통신 요구에 관한 이러한 정보를 이용할 수 있다. CARA에 관한 상세는, 예를 들어, M. Proebster, M. Kaschub, 및 S. Valentin의 "Context-Aware Resource Allocation to Improve the Quality of Service of Heterogeneous Traffic", Proc. IEEE International Conference on Communications (ICC), Jun. 2011에서 또는 EP11305685.7에서 찾아볼 수 있다. 사용자의 상황을 인식함으로써, 기지국(BS)은 사용자의 서비스 품질(QoS)을 희생시키는 일 없이 네트워크 부하를 상당히 감소시킬 수 있다[2011년 10월 검토를 위해 제출된, M. Proebster, M. Kaschub, T. Werthmann, 및 S. Valentin의 "Context-Aware Resource Allocation for Cellular Wireless Networks", EURASIP Journal on Wireless Communications and Networking (WCN)을 참조].

본 발명의 한 측면에 따르면, CARA 개념 및 알고리즘은 BS의 데이터 링크 제어(Data Link Control, DLC) 계층에서 실행될 수 있고, 비록 이들이 엄청난 이득을 제공할 수 있지만, 이들은 핸드헬드의 상위 계층으로부터의 상황 정보에 의존한다. 다른 측면에 따르면, CARA 알고리즘에 대한 이 본질적인 정보는 핸드헬드로부터의 상황 정보를 BS로 및/또는 그의 배후에 있는 코어 네트워크로 신호할 수 있는 피드백 프로토콜에 의해 제공될 수 있다. 더욱이, DLC보다 상위에 있는 계층들로부터의 핸드헬드 정보는 BS의 DLC 계층에 제공될 수 있다. 게다가, 실시예들은 시그널링 개념 및 일반 유형의 상황 정보가 몇 가지 시그널링 아키텍처 및 프로토콜에 의해 제공될 수 있다는 측면에 기초하고 있다.

실시예들은 모바일 디바이스들이 상황 정보를 BS에 또는 코어 네트워크에 신호할 수 있다는 측면에 기초하고 있다. 더욱이, 상향링크 동안 다른 정보가 이미 신호된다. 상세하게는, 모바일 디바이스는 채널 품질 정보(Channel Quality Information, CQI), 재전송 방식에 대한 확인 응답 및 스케줄링 요청을 기지국으로 신호할 수 있으며, 이러한 시그널링 개념에 대한 상세는, 예를 들어, 3G Partnership Project (3GPP) Technical Specification (TS) 36.300 V11.0.0, "Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN), Overall description", Dec. 2011에서 찾아볼 수 있다. 추가의 측면에 따르면, 이것은 전적으로 DLC에서 전용 제어 채널을 통해 행해질 수 있다. 게다가, 이들 피드백 절차는 상위 계층들과 DLC 사이의 정보 전송을 지원하지 않을 수 있다. 더욱이, 피드백 절차는 핸드헬드에서 이러한 상위 계층 정보에 액세스하지 않을 수 있다. 이와 같이, 기존의 DLC 시그널링은 상위 계층으로부터의 상황 정보(예컨대, 위치, 응용 프로그램 상태 또는 요구사항)를 BS에 제공하지 않을 수 있다. 비록 3GPP DLC가 핸드헬드로부터의 서비스 품질(QoS) 요구사항을 BS로 신호하는 방법을 포함하고 있지만, 이러한 시그널링은 제한된 공간의 고정된 테이블 및 헤더 필드에 기초하고 있다. 이러한 고정된 시그널링은 효용 함수들(utility functions) 또는 임의의 추가적인 상황 정보를 BS로 신호하는 데 충분히 유연하지 않을 수 있다.

추가의 측면에 따르면, 네트워크 계층에서, 예컨대, 인터넷 프로토콜(IP) 패킷에, QoS-등급을 신호하기 위한 헤더 필드가 있다[K. Nichols, S. Blake, F. Baker, 및 D. Black의 "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", IETF RFC 2474, Dec. 1998을 참조]. 그렇지만, 이 필드는 6 비트의 크기를 가지며, 전송 중인 패킷(packet in flight)을 분류하기 위해 사용된다. 이 헤더 필드 내에서 응용 프로그램의 요구사항 및 응용 프로그램 트랜잭션에 대한 데이터 패킷의 분류에 대한 모든 필요한 정보를 전달하는 것이 가능하지 않을 수 있다. 따라서, 모바일 디바이스의 응용 프로그램 계층으로부터의 정보를 BS에서의 DLC로 직접 신호하는 메커니즘이 바람직할 수 있다.

더욱이, 한 측면에 따르면, 이러한 계층간 시그널링(cross-layer signaling)을 제공하는 한 방식은 DPI(Deep Packet Inspection, 심층 패킷 검사)일 수 있다. BS 큐에 있는 사용자의 패킷을 검사함으로써(Nguyen, T.T.T. 및 Armitage, G.의 "A Survey of Techniques for Internet Traffic Classification Using Machine Learning," Communications Surveys & Tutorials, IEEE, Fourth Quarter 2008을 참조), 액세스 네트워크는 DLC보다 상위에 있는 계층들로부터 정보를 추출할 수 있다. 그렇지만, 이 방법은 암호화되지 않은 패킷으로 제한될 수 있고, 높은 처리 및 메모리 비용을 부가할 수 있으며, 높은 통신 지연을 부가할 수 있고, 제한된 한 세트의 정보만을 BS에 제공한다. 검사된 패킷을 분류하는 것과 비교하여, 핸드헬드에서 사용자의 상황[예컨대, 그의 위치, 이동성 경로(mobility path), 실행 중인 응용 프로그램 및 응용 프로그램의 QoS 요구사항]을 직접 측정하는 것이 보다 정확하고 효율적일 수 있다. 실시예들은 핸드헬드에서의 미들웨어 또는 엔터티가 이러한 정보에 액세스할 수 있고 이를 BS로 명시적으로 신호할 수 있다는 측면에 기초하고 있다.

실시예들은 모바일 송수신기의 상위 계층들로부터의 상황 정보를 기지국 송수신기의 DLC로 전송하기 위한 계층간 시그널링 아키텍처 및 프로토콜을 제공할 수 있다. 그렇게 하기 위해, 실시예들은 응용 프로그램-계층 데이터 흐름의 QoS 요구사항을 DLC로 신호하는 메커니즘을 사용할 수 있다. 이 시그널링 절차는, 예를 들어, 상향링크에서의 사용자의 또는 모바일의 피드백 통신에 통합될 수 있다. 추가적인 절차는 하향링크에 대해 DLC 데이터 프레임을 응용 프로그램 계층 흐름에 매핑할 수 있다.

실시예들은 모바일 통신 시스템에 대한 또는 모바일 통신 시스템에서의 모바일 송수신기에 대한 장치를 제공한다 - 즉, 실시예들은 모바일 송수신기에 의해 동작되거나 모바일 송수신기에 포함될 상기 장치를 제공할 수 있다 -. 이하에서, 이 장치를 이동국 송수신기 장치라고도 할 것이다. 더욱이, 모바일 통신 네트워크 및 모바일 통신 시스템이라는 용어는 동의어로 사용될 것이다. 모바일 통신 시스템은, 예를 들어, 3GPP-표준화된 모바일 통신 네트워크들[예컨대, LTE(Long Term Evolution), LTE-A(LTE-Advanced), UMTS(Universal Mobile Telecommunication System) 또는 UTRAN(UMTS Terrestrial Radio Access network), E-UTRAN(Evolved-UTRAN), GSM(Global System for Mobile Communication) 또는 EDGE(Enhanced Data Rates for GSM Evolution) 네트워크, GERAN(GSM/EDGE Radio Access Network), 일반적으로 OFDMA(Orthogonal Frequency Division Multiple Access) 네트워크, 기타 등등], 또는 상이한 표준들을 갖는 모바일 통신 네트워크[예컨대, WIMAX(Worldwide Interoperability for Microwave Access)] 중 하나에 대응할 수 있다.

모바일 통신 시스템은 기지국 송수신기를 추가로 포함하고 있다. 기지국 송수신기는 다수의 모바일 송수신기와 통신하는 동작을 할 수 있다. 실시예들에서, 모바일 통신 시스템은 모바일 송수신기 및 기지국 송수신기를 포함할 수 있고, 기지국 송수신기는 매크로 셀(macro cell) 또는 스몰 셀(small cell) - 예컨대, 피코 셀(pico cell), 메트로 셀(metro cell), 또는 펨토 셀(femto cell) 등 - 을 설정할 수 있다. 모바일 송수신기는 스마트폰, 휴대폰, 랩톱, 노트북, 개인용 컴퓨터, PDA(Personal Digital Assistant), USB(Universal Serial Bus)-스틱, 자동차 등에 대응할 수 있다 - 이는 핸드헬드 또는 모바일이라고도 할 수 있다 -. 모바일 송수신기는 또한 3GPP 용어에 따라 사용자 장비(UE)라고도 할 수 있다.

기지국 송수신기는 네트워크 또는 시스템의 고정된 또는 정지된 부분에 위치해 있을 수 있다. 기지국 송수신기는 원격 무선 장비(remote radio head), 전송 포인트(transmission point), 액세스 포인트, 매크로 셀, 스몰 셀, 마이크로 셀(micro cell), 펨토 셀, 메트로 셀 등에 대응할 수 있다. 기지국 송수신기는 UE 또는 모바일 송수신기로의 무선 신호의 전송을 가능하게 해주는, 유선 네트워크의 무선 인터페이스일 수 있다. 이러한 무선 신호는, 예를 들어, 3GPP에 의해 표준화된, 또는 일반적으로 앞서 열거한 시스템들 중 하나 이상에 따른 무선 신호와 부합될 수 있다. 이와 같이, 기지국 송수신기는 NodeB, eNodeB(eNB), BTS(Base Transceiver Station), 액세스 포인트, 원격 무선 장비, 전송 포인트 등에 대응할 수 있고, 이는 원격 유닛(remote unit)과 중앙 유닛(central unit)으로 추가로 세분될 수 있다.

모바일 송수신기는 기지국 송수신기 또는 셀과 연관되어 있을 수 있다. 셀이라는 용어는 기지국 송수신기(예컨대, NodeB, eNodeB, 원격 무선 장비, 전송 포인트 등)에 의해 제공되는 무선 서비스의 커버리지 영역(coverage area)을 말한다. 기지국 송수신기는 하나 이상의 주파수 계층에서 다수의 셀을 운영할 수 있고, 어떤 실시예들에서, 셀은 섹터(sector)에 대응할 수 있다. 예를 들어, 섹터는 원격 유닛 또는 기지국 송수신기 주변의 각도 섹션을 담당하는 특성을 제공하는 섹터 안테나를 사용하여 달성될 수 있다. 일부 실시예에서, 기지국 송수신기는, 예를 들어, 3개 또는 6개의 셀 - 각각, 120°(3개의 셀의 경우)의 섹터들 및 60°(6개의 셀의 경우)의 섹터들을 담당함 - 을 운영할 수 있다. 기지국 송수신기는 다수의 섹터화된 안테나를 운영할 수 있다.

실시예들에서, 모바일 송수신기 장치는 모바일 송수신기 상에서 실행 중인 응용 프로그램으로부터의 상황 정보, 모바일 송수신기 상에서 실행 중인 운영 체제로부터의 상황 정보, 또는 모바일 송수신기의 하드웨어 드라이버 또는 하드웨어로부터의 상황 정보를 추출하는 수단을 포함하고 있다. 상황 정보는 응용 프로그램의 상태에 관한 정보 및/또는 모바일 송수신기의 상태에 관한 정보를 포함한다. 추출하는 수단은 추출기(extractor), 프로세서, 마이크로-프로세서, 제어기 등에 대응할 수 있다. 모바일 송수신기 장치는 기지국 송수신기와 데이터 패킷을 통신하는 수단 - 데이터 패킷은 페이로드 데이터 패킷 및 제어 데이터 패킷을 포함함 - 을 추가로 포함한다. 통신하는 수단은, 예컨대, 앞서 열거한 통신 시스템들 중 하나에 따른, 통신기(communicator), 송수신기, 송신기, 수신기 등에 대응할 수 있다. 통신하는 수단은 기지국 송수신기를 통해 데이터 서버와 응용 프로그램과 연관되어 있는 페이로드 데이터 패킷을 통신하는 동작을 한다. 데이터 서버는 실제 응용 프로그램 데이터를 제공하는 서버에 대응할 수 있고, 이는 또한, 예컨대, PDN-GW(Public Data Network GateWay)와 같은 인터넷 게이트웨이 등의 모바일 통신 시스템의 게이트웨이에 대응할 수 있다.

모바일 송수신기 장치는 상황 정보를 기지국 송수신기에 제공하는 수단 - 상황 정보는 페이로드 데이터 패킷에 또는 제어 데이터 패킷에 포함되어 있음 - 을 추가로 포함한다. 따라서, 실시예들은 상이한 시그널링 및 분류 방식을 사용할 수 있다. 어떤 실시예들에서, 모바일 디바이스와 기지국 간의 전용 제어 채널이 사용될 수 있다. 즉, 모바일 송수신기는 요구사항 및 분류 규칙을 BS로 전송할 수 있고, BS는 이 정보를 하향링크 DLC 프레임에 매핑할 수 있다. 환언하면, 어떤 실시예들에서, 모바일 송수신기 장치로부터의 상황 정보를 BS에 제공하기 위해 제어 데이터 패킷과 관련하여 계층 2 또는 계층 3 시그널링이 사용될 수 있다. 3GPP와 관련하여, 시그널링 무선 베어러(Signaling Radio Bearer, SRB)는, 예를 들어, 무선 자원 제어(Radio Resource Control, RRC) 프로토콜의 일부로서 상황 정보를 전달하는 데 사용될 수 있다.

따라서, 실시예들은 또한 모바일 송수신기를 추가로 포함하는, 모바일 통신 시스템에 대한 또는 모바일 통신 시스템에서의 기지국 송수신기에 대한 대응하는 장치를 제공한다. 즉, 실시예들은 앞서 열거한 통신 시스템들 중 하나 이상에 부합할 수 있는, 기지국 송수신기에 의해 운영되거나 기지국 송수신기에 포함될 상기 장치를 제공할 수 있다. 이하에서, 이 장치를 기지국 송수신기 장치라고도 할 것이다. 기지국 송수신기 장치는 제어 데이터 패킷 및 페이로드 데이터 패킷을 수신하는 수단을 포함한다. 수신하는 수단은 앞서 열거한 시스템들 중 하나 이상에 부합하는 수신기 또는 송수신기에 대응할 수 있다. 페이로드 데이터 패킷은 모바일 송수신기 상에서 실행 중인 응용 프로그램과 연관되어 있다. 기지국 송수신기 장치는 제어 데이터 패킷으로부터 또는 페이로드 데이터 패킷으로부터 응용 프로그램과 연관되어 있는 상황 정보를 획득하는 수단을 추가로 포함한다. 획득하는 수단은 획득기(obtainer), 프로세서, 마이크로-프로세서, 제어기 등에 대응할 수 있다.

더욱이, 기지국 송수신기 장치는 상황 정보에 기초하여 데이터 패킷의 전송을 위해 모바일 송수신기를 스케줄링하는 수단을 포함할 수 있다. 스케줄링하는 수단은 스케줄러(scheduler), 프로세서, 마이크로-프로세서, 제어기 등에 대응할 수 있다. 스케줄링이라는 용어는 데이터 패킷의 전송 또는 수신을 위한 시간, 주파수, 전력, 코드 또는 공간 자원 등의 무선 자원의 할당으로서 이해되어야 한다. 이는 상향링크, 하향링크, 또는 둘 다를 말하는 것일 수 있다.

이하에서, 상황 정보는 응용 프로그램의 서비스 품질 요구사항에 관한 정보, 응용 프로그램과 연관되어 있는 데이터 패킷의 우선순위 정보, 응용 프로그램의 복수의 데이터 패킷들의 통합체(unity)에 관한 정보, 응용 프로그램의 부하 요구(load demand)에 관한 정보, 응용 프로그램의 지연 또는 오류율 제약조건에 관한 정보, 모바일 송수신기에서의 창 상태(window state)에 관한 정보, 모바일 송수신기의 메모리 소비량(memory consumption)에 관한 정보, 모바일 송수신기 상에서 실행 중인 응용 프로그램의 프로세서 사용량(processor usage)에 관한 정보, 모바일 송수신기의 현재의 위치, 속도, 배향에 관한 정보, 또는 모바일 송수신기와 다른 모바일 송수신기 간의 거리의 그룹 중 하나 이상의 요소를 포함하는 것으로 가정된다. 상황 정보 또는 트랜잭션 데이터 패킷은 하나 이상의 데이터 패킷과 기지국 송수신기에서의 스케줄링 큐(scheduling queue) 간의 매핑 정보를 포함할 수 있다.

환언하면, 상황 정보는 응용 프로그램에 관한 정보를 포함할 수 있다, 예를 들어, 상황 정보는 사용자 포커스(user focus)에 관한 정보(즉, 응용 프로그램이 현재 전경에 디스플레이되는지 배경에 디스플레이되는지), 응용 프로그램의 유형에 관한 정보(즉, 웹 브라우징, 상호작용형, 스트리밍, 대화형, 기타), 요청의 유형에 관한 정보[즉, 요청된 데이터가 단지 프리페치(prefetch)인지 즉각 디스플레이되어야 하는지], 어떤 지연 또는 QoS 요구사항에 관한 정보 등을 포함할 수 있다.

환언하면, 상황 정보는 응용 프로그램마다 제공될 수 있다. 예를 들어, 2개의 스트리밍 응용 프로그램이 모바일 송수신기 상에서 병렬로 실행 중이다. 종래 기술에 따르면, 이들 응용 프로그램 둘 다의 데이터가 하위 계층에서의 스트리밍 전송 채널(streaming transport channel)에 매핑될 것이다. 따라서, 종래 기술에 따르면, 2개의 응용 프로그램으로부터의 데이터는 스케줄러에 의해 구별되지 않을 것이다. 실시예들에 따르면, 응용 프로그램들에 대해 개별적으로 상황 정보가 이용가능할 수 있다. 예를 들어, 하나의 응용 프로그램의 상황 정보는 응용 프로그램이 전경에 디스플레이되어 있다는 것을 나타낼 수 있고; 다른 응용 프로그램의 상황 정보는 응용 프로그램이 배경에 있다는 것을 나타낼 수 있다. 따라서, 실시예들은 이들 2개의 응용 프로그램 및 그들의 데이터가 스케줄러에 의해 구별될 수 있고 전경에서 실행 중인 응용 프로그램이 우선적으로 처리될 수 있다는 이점을 제공할 수 있다. 따라서, 심지어 동일한 유형의 응용 프로그램들에 대해서도, 예컨대, 2개의 웹 브라우징 세션에 대해, 개별적인 또는 구별되는 상황 정보가 제공될 수 있다. 상황 정보는 운영 체제로부터도 추출될 수 있는데, 그 이유는 응용 프로그램이 전경에 있는지 배경에 있는지에 관한 정보를 응용 프로그램이 가지고 있지 않을 수 있기 때문이다. 역시 응용 프로그램의 상태를 판정하는 이 정보는 모바일 송수신기의 운영 체제의 창 관리자(window manager)로부터 추출될 수 있다.

데이터 패킷들의 통합체는 다수의 데이터 패킷이 한 곳에 속한다는 것을 나타내는 정보를 말하는 것일 수 있다, 예를 들어, 응용 프로그램이 영상 디스플레이 응용 프로그램에 대응할 수 있고 영상 데이터가 복수의 데이터 패킷들에 포함되어 있다. 이어서, 상황 정보는 몇 개의 데이터 패킷이 하나의 영상을 가리키는 것인지를 나타낼 수 있다. 이 정보가 스케줄러에 의해 고려될 수 있다. 환언하면, 상황 정보로부터, 스케줄러는 데이터 패킷들 간의 어떤 관계를 결정할 수 있다, 예컨대, 사용자는 전체 영상이 디스플레이되는 경우에만 만족될 수 있고, 따라서, 그 영상을 가리키는 모든 패킷들이 적절한 시간 구간 내에 모바일 송수신기로 전송되어야만 한다. 그에 의해, 스케줄러는 사전에 계획을 세울 수 있다.

실시예들에서, 추출하는 수단은 모바일 송수신기의 운영 체제로부터 또는 모바일 송수신기 상에서 실행 중인 응용 프로그램으로부터 상황 정보를 추출하도록 구성되어 있을 수 있다. 환언하면, 모바일 송수신기의 운영 체제는 상황 정보를, 예컨대, 응용 프로그램의 상태 정보(전경/배경, 활성/중지, 대기, 기타)로서 제공할 수 있다. 다른 옵션은 응용 프로그램 자체가 상황 정보를 제공하는 것이다.

따라서, 상기 설명에 따라, 기지국 송수신기 장치는 계층 2 또는 계층 3, 예컨대, RRC 제어 데이터 패킷을 통해 상황 정보를 수신할 수 있다. 다른 실시예들에서, 예컨대, IP 패킷과 관련하여, 응용 프로그램 계층에서의 시그널링이 사용될 수 있다. 기지국 송수신기의 IP 주소를 모바일 송수신기 장치에서 모르고 있을 수 있기 때문에, 애니캐스트(any-cast) 메커니즘이 사용될 수 있다. 따라서, 데이터 패킷은 애니캐스트 데이터 패킷을 사용하여 기지국으로 어드레싱될 수 있고, 기지국 송수신기 장치가 상황 정보를 추출하는 것에 의해 해석된다. 상황 정보는 이어서 이상의 설명에 따라 기지국 송수신기 장치에서 사용될 수 있다. 애니캐스트라는 용어는 그에 따른 데이터 패킷이 그 데이터 패킷을 수신하는 임의의 다음 노드에 의해 해석되는 네트워크에서의 메커니즘으로서 이해된다. 데이터 패킷에서의 애니캐스트 표시는, 기지국 송수신기 장치가 상기 데이터 패킷을 수신할 첫 번째 노드이기 때문에, 패킷이 해석되어야 한다는 것을 기지국 송수신기 장치에 알려줄 수 있다. 프로토콜 스택(protocol stack)에서의 상이한 계층들에서 애니캐스트가 사용될 수 있다. 예를 들어, 애니캐스트 데이터 패킷은 기지국 송수신기에 대한 애니캐스트 표시를 갖는 IP 데이터 패킷에 대응할 수 있다. 이 표시는, 예를 들어, IP 패킷의 헤더에서의 TOS(Type Of Service) 필드에 포함되어 있을 수 있다. 다른 실시예들에서, UDP(Universal Datagram Protocol)이 사용될 수 있고, 애니캐스트 표시는 IDP 헤더에서 주어지는 어떤 포트, 예컨대, 어떤 목적지 포트에 대응할 수 있다.

추가의 실시예들에서, 모바일 송수신기 장치는 트랜잭션 프로토콜의 일부로서 트랜잭션 데이터 패킷을 작성하는 수단을 포함할 수 있다. 트랜잭션 데이터 패킷은 상황 정보를 포함하고 있다. 어떤 실시예들에서, 트랜잭션 데이터 패킷은 이상의 설명에 따라 애니캐스트 페이로드 데이터 패킷을 사용하여 기지국 송수신기로 전달된다. 트랜잭션 데이터 패킷 또는 상황 정보는 링크 계층 프로토콜 제어 데이터 패킷을 사용하여 기지국 송수신기로 전달될 수 있다. 트랜잭션 프로토콜은 이어서 계층 1 또는 PHY(PHYsical layer), 계층 2, 예컨대, MAC(Medium Access Control) 또는 RLC(Radio Link Control) 등의 하위 프로토콜 계층 서비스를 사용할 수 있다. 더욱이, 트랜잭션 프로토콜은 페이로드 데이터 패킷 전송을 위해 소위 사용자-평면 프로토콜(user-plane protocol)을 사용할 수 있다. 따라서, 트랜잭션 프로토콜은 또한 UDP, IP, PDCP(packet Data Convergency Protocol)를 사용할 수 있다. 트랜잭션 프로토콜은 제어 평면을 사용할 수 있고, 이는, 예를 들어, RRC의 일부일 수 있다.

추가의 실시예들에서, 트랜잭션 데이터 패킷은 유니캐스트 페이로드 데이터 패킷을 사용하여(예컨대, IP를 사용하여) 데이터 서버로 전달된다. 환언하면, 트랜잭션 데이터 패킷은 이어서 유니캐스트 페이로드 데이터 패킷을 사용하여(예컨대, IP를 통해) 데이터 서버로부터 기지국에 수신될 수 있다. 따라서, 상황 정보가 기지국 송수신기로 직접 전달되지 않고, 데이터 서버를 통해 간접적으로 전달될 수 있다. 다른 실시예에서, 모바일 송수신기 장치로부터의 상황 정보를 기지국 송수신기 장치로 신호하기 위해 제어 데이터 패킷이 사용될 수 있다. 이와 같이, 트랜잭션 데이터 패킷 또는 상황 정보가 링크 계층 프로토콜 제어 데이터 패킷을 사용하여 모바일 송수신기로부터 수신될 수 있다. 기지국 송수신기 장치는 이어서 분류 정보를 데이터 서버(예컨대, 인터넷 게이트웨이)로 전달할 수 있다. 상황 정보가 이어서 기지국 송수신기로부터 분류 정보를 제공받는 데이터 서버로부터 수신될 수 있다. 그러면, 상황 정보는 데이터 서버로부터 수신된 데이터 패킷에서의 태그에 대응할 수 있다. 분류 정보는 기지국 송수신기에서의 스케줄러 큐에 대한 QoS 설정 또는 요구사항, 기지국 송수신기의 스케줄러에서의 트랜잭션 상황(transaction context)을, 각각, 포함할 수 있다.

따라서, 게이트웨이 또는 데이터 서버는 그에 따라 하향링크 패킷을 분류하고 그들에 태깅하여 매핑 정보를 기지국 송수신기에 제공한다. 또 다른 실시예에서, 모바일 송수신기 장치는 데이터 서버로 직접 상황 정보의 IP 시그널링을 수행한다. 이어서, 데이터 서버에서 분류가 수행될 수 있지만, 태그에 부가하여, 데이터 서버는 응용 프로그램 흐름의 QoS 요구사항을 기지국 송수신기로 신호할 수 있다. 상황 정보 또는 트랜잭션 데이터 패킷은 하나 이상의 데이터 패킷과 기지국 송수신기에서의 스케줄링 큐 간의 매핑 정보를 포함할 수 있다.

기지국 송수신기 장치의 실시예들에서, 스케줄링하는 수단은 복수의 트랜잭션들에 대한 전송 시퀀스(transmission sequence)를 결정하는 동작을 할 수 있다. 복수의 트랜잭션들은 하나 이상의 모바일 송수신기에 의해 실행되고 있는 복수의 응용 프로그램들을 말하는 것일 수 있다. 트랜잭션은 복수의 데이터 패킷들에 대응할 수 있고, 상황 정보는 이들 데이터 패킷에 대한 통합체를 나타낸다. 트랜잭션들의 시퀀스의 순서는 상황 정보에 기초하여 결정되는 트랜잭션의 완료 시간에 의존할 수 있는 효용 함수에 기초할 수 있다.

환언하면, 상황 정보는 효용 함수를 사용하여 평가될 수 있다. 효용 함수는 사용자 만족도에 대한 척도일 수 있고, 따라서 트랜잭션의 완료 시간에 의존할 수 있다. 예를 들어, 웹 페이지의 데이터 패킷을 포함하는 트랜잭션에 대해, 웹 브라우징 응용 프로그램은 완료 시간이, 예를 들어, 2초일 수 있도록 요청하였다. 환언하면, 웹 페이지의 전체 콘텐츠가 2초 미만 내에 전송될 때, 완전한 사용자 만족도가 달성될 수 있다. 그렇지 않은 경우, 사용자 만족도 및 그것과 함께 효용 함수가 나빠질 것이다. 실시예들에서 트랜잭션들의 시퀀스가 상이한 방식으로 결정될 수 있다. 어떤 실시예들에서, 다수의 상이한 트랜잭션 시퀀스들의 반복으로부터 전송 시퀀스가 결정된다. 다수의 상이한 시퀀스들은 복수의 트랜잭션들의 상이한 순열에 대응할 수 있다. 스케줄링하는 수단은 다수의 상이한 시퀀스들 각각에 대한 효용 함수를 결정하도록 구성되어 있을 수 있고, 이는 또한 최대 합(maximum sum) 효용 함수에 대응하는 다수의 상이한 시퀀스들로부터 전송 시퀀스를 선택하도록 구성되어 있을 수 있다. 환언하면, 실시예들에서, 스케줄링 결정이 최적화된 사용자 만족도 또는 효용 함수에 기초하여 판정될 수 있고, 최적화는 제한된 한 세트의 시퀀스들에 기초할 수 있다.

어떤 실시예들에서, 실제 전송 시퀀스 또는 스케줄링 결정은 또한 특정의 사용자의 무선 상태에 기초할 수 있다 - 예컨대, 스케줄링하는 수단은 각각의 트랜잭션에 대한 지원가능한 데이터 전송률에 기초하여 전송 시퀀스를 추가로 수정하도록 구성되어 있을 수 있다 -. 다른 실시예들에서, 다른 공정성 기준 또는 전송률 또는 처리율 기준이 고려될 수 있다.

그에 따라, 실시예들은 데이터 서버에 대한 또는 데이터 서버에서의 장치를 제공한다 - 즉, 실시예들은 데이터 서버에 의해 동작되거나 데이터 서버에 포함될 상기 장치를 제공할 수 있다 -. 이하에서, 이 장치를 데이터 서버 장치라고도 할 것이다. 이상의 설명에 따라, 데이터 서버는 모바일 송수신기 상에서 실행 중인 응용 프로그램과 연관되어 있는 데이터 패킷을 모바일 통신 시스템을 통해 모바일 송수신기로 전달한다. 데이터 서버 장치는 기지국 송수신기로부터 수신된 분류 정보에 기초하여 데이터 패킷에 대한 상황 정보를 도출하는 수단을 포함한다. 도출하는 수단은 도출기(deriver), 프로세서, 마이크로-프로세서, 제어기 등에 대응할 수 있다. 데이터 서버 장치는 상황 정보를 데이터 패킷과 함께 모바일 통신 시스템으로 전송하는 수단을 추가로 포함한다. 전송하는 수단은 송신기, 예컨대, 기지국 송수신기와 통신하는 인터페이스(예컨대, 이더넷 인터페이스)에 대응할 수 있다. 어떤 실시예들에서, 예컨대, 데이터 서버가 다른 모바일 송수신기에 대응할 때, 데이터 서버와 기지국 간의 무선 인터페이스가 생각될 수 있다.

앞서 기술한 바와 같이, 데이터 서버 장치는 데이터 패킷을 작성하는 수단을 추가로 포함할 수 있다. 작성하는 수단은 작성기(composer), 프로세서, 마이크로-프로세서, 제어기 등에 대응할 수 있다. 앞서 기술한 바에 따라, 데이터 패킷은 응용 프로그램 데이터 패킷 및 데이터 패킷과 기지국 송수신기에서의 스케줄링 큐 간의 매핑 정보를 갖는 태그를 포함할 수 있다. 작성하는 수단은 응용 프로그램 데이터 패킷 및 상황 정보를 포함하는 트랜잭션 데이터 패킷을 작성하는 동작을 할 수 있거나, 상황 정보를 갖는 데이터 패킷 헤더를 작성하는 동작을 할 수 있거나, 응용 프로그램의 서비스 품질 요구사항을 포함하는 데이터 패킷을 작성하는 동작을 할 수 있다.

실시예들은 그에 따른 방법들을 추가로 제공할 수 있다. 즉, 실시예들은 모바일 통신 시스템에서의 모바일 송수신기에 대한 방법을 제공할 수 있다. 모바일 통신 시스템은 기지국 송수신기를 포함하고 있다. 이 방법은 모바일 송수신기 상에서 실행 중인 응용 프로그램으로부터의 상황 정보, 모바일 송수신기 상에서 실행 중인 운영 체제로부터의 상황 정보, 또는 모바일 송수신기의 하드웨어 드라이버 또는 하드웨어로부터의 상황 정보를 추출하는 단계를 포함하고 있다. 상황 정보는 응용 프로그램의 상태에 관한 정보 및/또는 모바일 송수신기의 상태에 관한 정보를 포함한다. 이 방법은 기지국 송수신기와 데이터 패킷을 통신하는 단계 - 데이터 패킷은 페이로드 데이터 패킷 및 제어 데이터 패킷을 포함함 - 를 추가로 포함한다. 이 방법은 기지국 송수신기를 통해 데이터 서버와 응용 프로그램과 연관되어 있는 페이로드 데이터 패킷을 통신하는 단계를 추가로 포함한다. 이 방법은 상황 정보를 기지국 송수신기에 제공하는 단계 - 상황 정보는 페이로드 데이터 패킷에 또는 제어 데이터 패킷에 포함되어 있음 - 를 추가로 포함한다.

실시예들은 또한 모바일 통신 시스템에서의 기지국 송수신기에 대한 방법을 제공할 수 있다. 모바일 통신 시스템은 모바일 송수신기를 추가로 포함하고 있다. 이 방법은 제어 데이터 패킷 및 페이로드 데이터 패킷을 수신하는 단계를 포함하고, 페이로드 데이터 패킷은 모바일 송수신기 상에서 실행 중인 응용 프로그램과 연관되어 있다. 이 방법은 제어 데이터 패킷으로부터 또는 페이로드 데이터 패킷으로부터 응용 프로그램과 연관되어 있는 데이터 패킷에 관한 상황 정보를 획득하는 단계를 추가로 포함한다. 이 방법은 상황 정보에 기초하여 데이터 패킷의 전송을 위해 모바일 송수신기를 스케줄링하는 단계를 추가로 포함한다.

실시예들은 또한 데이터 서버에 대한 방법을 제공한다. 데이터 서버는 모바일 송수신기 상에서 실행 중인 응용 프로그램과 연관되어 있는 데이터 패킷을 모바일 통신 시스템을 통해 모바일 송수신기로 전달한다. 이 방법은 기지국 송수신기로부터 수신된 분류 정보에 기초하여 데이터 패킷에 대한 상황 정보를 도출하는 단계, 및 상황 정보를 데이터 패킷과 함께 모바일 통신 시스템으로 전송하는 단계를 포함한다.

실시예들은 또한 앞서 기술한 모바일 송수신기 장치를 포함하는 모바일 송수신기, 앞서 기술한 기지국 송수신기 장치를 포함하는 기지국 송수신기, 앞서 기술한 데이터 서버 장치를 포함하는 데이터 서버, 및/또는 모바일 송수신기, 기지국 송수신기, 및/또는 데이터 서버를 포함하는 모바일 통신 시스템을 제공할 수 있다.

실시예들은 무선 액세스 네트워크가 상위 계층들로부터의 상황 정보를 이용할 수 있게 해줄 수 있다. 사용자, 핸드헬드, 및 그의 환경에 관한 이 정보는 사용자의 요구사항에 따라 무선 채널 자원을 효율적으로 할당하는 데 사용될 수 있다. QoS 구별을 위한 기존의 시그널링과 달리, 제공된 상황 정보는 작은 한 세트의 QoS 등급들을 넘어설 수 있다. 데이터 전송률 및 지연에서의 응용 프로그램-계층 흐름의 고유 효용 함수를 신호함으로써, 실시예들은 최신 스마트폰 응용 프로그램의 이질적인 QoS 요구사항을 BS로 전달할 수 있다. 심지어 동일한 응용 프로그램의 상이한 요구사항들이 포착될 수 있다. 사용자의 위치, 그의 이전의 또는 계획된 이동성 경로, 화면의 전경에 있는 응용 프로그램, 디바이스 세부 사항(예컨대, 화면 크기)에 관한 추가의 정보가 실시예들이 무선 액세스 네트워크에 제공할 수 있는 상황을 보완할 수 있다.

실시예들에서, 상황 인식(context-awareness)은 사용자의 QoS를 희생시키는 일 없이 무선 네트워크의 트래픽 부하를 감소시키고 모바일 사용자들에 대해서도 다수의 셀을 통해 매끄러운 QoS를 제공하며 모바일 사용자들에 대한 데이터 전송률 및 공정성을 향상시킬 수 있는 자원 할당 개념을 가능하게 해줄 수 있다.

장기 자원 할당(long term resource allocation)의 이점에 관한 어떤 상세는 H. Abou-zeid, S. Valentin, 및 H. Hassanein의 "Context- Aware Resource Allocation for Media Streaming: Exploiting Mobility and Application-Layer Predictions", Proc. Capacity Sharing Workshop, Oct. 2011, 및 EP 11306323.4에서도 찾아볼 수 있다. 환언하면, 실시예들이 상황 시그널링(context signaling)을 가능하게 해주는 것은 모바일 사용자에 대한 서비스를 실질적으로 향상시키고 더 많은 사용자들에 똑같은 QoS로 서비스하는 강력한 새로운 자원 할당 방식을 적용하기 위한 선행 조건일 수 있다. LTE의 DLC에서의 현재의 QoS 시그널링과 비교하여, 실시예들은 더 많은 정보를 무선 액세스 네트워크에 제공할 수 있다. QoS 등급에 부가하여, 효용 함수 및 추가의 상황 정보가 제공될 수 있다.

패킷 검사(Packet Inspection, PI)와 비교하여, 실시예들은 심지어 암호화된 데이터 스트림에 대해서도 상황 정보를 제공할 수 있다. PI가 메모리 및 처리 능력에 많은 노력을 부가할 수 있기 때문에, 실시예들은 얼마간의 하드웨어 비용을 절감할 수 있다. 더욱이, 실시예들은 낮은 일정한 지연을 보장해줄 수 있지만, PI에서는 그렇지 않을 수 있다. 어떤 실시예들은 DLC-기반 시그널링 방식을 사용할 수 있는 반면, 다른 실시예들은 표준화를 필요로 하지 않을 수 있는 사용자 평면 시그널링을 사용할 수 있다. 따라서, 실시예들은 핸드헬드 미들웨어로서 그리고 무선 액세스 네트워크에서 실행되는 소프트웨어로서 완전히 구현될 수 있다. 이것은 실시예들이 기존의 웹 인프라[예컨대, 안드로이드 마켓(Android market) 또는 다른 앱 스토어(App store)]를 통해 용이하게 출시되고 업데이트될 수 있게 해줄 수 있다.

어떤 실시예들은 이 방법을 수행하기 위한 장치 내에 설치되어 있는 디지털 제어 회로를 포함하고 있다. 이러한 디지털 제어 회로, 예컨대, 디지털 신호 처리기(DSP)는 그에 따라 프로그램될 필요가 있다. 따라서, 추가의 실시예들은 또한, 컴퓨터 프로그램이 컴퓨터 또는 디지털 프로세서 상에서 실행될 때, 이 방법의 실시예들을 수행하는 프로그램 코드를 가지는 컴퓨터 프로그램을 제공한다.

도면의 간단한 설명 장치 및/또는 방법의 어떤 실시예들이 이하에서 단지 예로서 그리고 첨부 도면을 참조하여 기술될 것이다.
도 1은 모바일 송수신기에 대한 장치, 기지국 송수신기에 대한 장치, 및 데이터 서버에 대한 장치의 일 실시예를 나타낸 도면.
도 2는 모바일 디바이스의 일 실시예 및 기지국의 일 실시예를 갖는 통신 네트워크의 일 실시예를 나타낸 도면.
도 3은 일 실시예에서의 2개의 트랜잭션을 나타낸 도면.
도 4는 일 실시예에서의 효용 함수를 나타낸 도면.
도 5는 EPC에서의 실시예들을 나타낸 도면.
도 6은 전용 제어 채널을 사용하는 일 실시예에서의 프로토콜 스택을 나타낸 도면.
도 7은 사용자 평면에서의 시그널링을 사용하는 일 실시예에서의 프로토콜 스택을 나타낸 도면.
도 8은 데이터 서버에서의 전용 제어 채널 및 하향링크 패킷 분류를 사용하는 일 실시예에서의 프로토콜 스택을 나타낸 도면.
도 9는 상황 정보의 간접적인 제공에 의한 데이터 평면에서의 시그널링을 사용하는 일 실시예에서의 프로토콜 스택을 나타낸 도면.
도 10은 모바일 송수신기에 대한 방법의 일 실시예의 플로우차트의 블록도.
도 11은 기지국 송수신기에 대한 방법의 일 실시예의 플로우차트의 블록도.
도 12는 데이터 서버에 대한 방법의 일 실시예의 플로우차트의 블록도.

이제부터, 어떤 예시적인 실시예들이 도시되어 있는 첨부 도면을 참조하여, 다양한 예시적인 실시예에 대해 보다 상세히 기술할 것이다. 도면들에서, 라인, 계층 및/또는 영역의 두께는 명확함을 위해 과장되어 있을 수 있다.

그에 따라, 예시적인 실시예들이 다양한 수정들 및 대안의 형태들을 가능하게 해주지만, 그의 실시예들이 도면들에 예로서 도시되어 있고 본 명세서에서 상세히 기술될 것이다. 그렇지만, 예시적인 실시예들을 개시되어 있는 특정의 형태들로 제한하기 위한 것이 아니며, 그와 달리, 예시적인 실시예들이 본 발명의 범위 내에 속하는 모든 수정, 등가물 및 대안을 포함한다는 것을 잘 알 것이다. 도면들에 대한 설명 전체에 걸쳐 유사한 번호는 동일하거나 유사한 요소들을 가리킨다.

한 요소가 다른 요소에 "연결" 또는 "결합"되어 있다고 말해질 때, 한 요소가 다른 요소에 직접 연결 또는 결합되어 있을 수 있거나 중간 요소가 존재할 수 있다는 것을 잘 알 것이다. 이와 달리, 한 요소가 다른 요소에 "직접 연결" 또는 "직접 결합"되어 있다고 말해질 때, 중간 요소가 존재하지 않는다. 요소들 간의 관계를 기술하는 데 사용되는 다른 단어가 마찬가지로 해석되어야만 한다(예컨대, "~사이에" 대 "~사이에 바로", "~에 인접한" 대 "~에 바로 인접한" 등).

본 명세서에서 사용된 용어가 단지 특정의 실시예를 설명하기 위한 것이며 예시적인 실시예를 제한하기 위한 것은 아니다. 본 명세서에서 사용되는 바와 같이, 단수 형태 "어떤", "한" 및 "그"는, 문맥이 명확하게 다른 것을 말하지 않는 한, 복수 형태도 포함하는 것으로 보아야 한다. 또한, 용어 "포함한다", "포함하는", "구비한다", "구비하는"이, 본 명세서에서 사용될 때, 언급한 특징, 정수, 단계, 동작, 요소, 및/또는 구성요소가 존재함을 명시하는 것이고 하나 이상의 다른 특징, 정수, 단계, 동작, 요소, 구성요소 및/또는 이들의 그룹의 존재 또는 추가를 배제하지 않는다는 것을 잘 알 것이다.

달리 정의되지 않는 한, 본 명세서에서 사용되는 모든 용어(기술적 및 과학적 용어를 포함함)는 예시적인 실시예들이 속하는 기술 분야의 당업자가 통상적으로 이해하는 것과 동일한 의미를 가진다. 또한 용어들, 예컨대, 널리 사용되는 사전에 정의된 용어들이 관련 기술 분야와 관련한 그의 의미와 일관된 의미를 갖는 것으로 해석되어야 하고 본 명세서에 명확히 그렇게 정의되지 않는 한 이상화되거나 과도하게 형식적인 의미로 해석되지 않을 것이라는 것을 잘 알 것이다.

도 1은 모바일 송수신기(100)에 대한 장치(10), 기지국 송수신기(200)에 대한 장치(20), 및 데이터 서버(300)에 대한 장치(30)의 일 실시예를 나타낸 것이다. 도 1은 모바일 통신 시스템(500)에 대한 모바일 송수신기(100)에 대한 장치(10)를 상부에 도시하고 있다. 이 실시예에서, 모바일 통신 시스템(500)은 도 1의 중앙에 나타내어져 있는 기지국 송수신기(200)를 포함하고 있다. 기지국 송수신기(200)는 도 1의 하부에 나타내어져 있는 데이터 서버(300)에 결합되어 있으며, 이들 모두가 나중에 상세히 기술될 것이다.

모바일 송수신기 장치(10)는 모바일 송수신기(100) 상에서 실행 중인 응용 프로그램으로부터의 상황 정보, 모바일 송수신기(100) 상에서 실행 중인 운영 체제로부터의 상황 정보, 또는 모바일 송수신기(100)의 하드웨어 드라이버 또는 하드웨어로부터의 상황 정보를 추출하는 수단(12)을 포함하고 있으며, 상황 정보는 응용 프로그램의 상태에 관한 정보 및/또는 모바일 송수신기(100)의 상태에 관한 정보를 포함한다. 모바일 송수신기 장치(10)는 기지국 송수신기(200)와 데이터 패킷을 통신하는 수단(14) - 데이터 패킷은 페이로드 데이터 패킷 및 제어 데이터 패킷을 포함함 - 을 추가로 포함한다. 통신하는 수단(14)은 기지국 송수신기(200)를 통해 데이터 서버(300)와 응용 프로그램과 연관되어 있는 페이로드 데이터 패킷을 통신하는 동작을 한다. 모바일 송수신기 장치는 상황 정보를 기지국 송수신기(200)에 제공하는 수단(16)을 추가로 포함한다. 상황 정보는 페이로드 데이터 패킷에 또는 제어 데이터 패킷에 포함되어 있다. 도 1에서 알 수 있는 바와 같이, 추출하는 수단(12), 통신하는 수단(14), 및 제공하는 수단(16)은 서로 결합되어 있다.

본 실시예에서의 통신 네트워크는 EPC(Evolved Packet Core)를 갖는 3GPP LTE(3rd Generation Partnership Project Long Term Evolution) 시스템에 대응한다.

도 1은 또한 기지국 송수신기(200)에 대한 장치(20)의 일 실시예를 나타내고 있다. 기지국 송수신기 장치(20)는 제어 데이터 패킷 및 페이로드 데이터 패킷을 수신하는 수단(22)을 포함한다. 페이로드 데이터 패킷은 모바일 송수신기(100) 상에서 실행 중인 응용 프로그램과 연관되어 있다. 기지국 송수신기 장치는 제어 데이터 패킷으로부터 또는 페이로드 데이터 패킷으로부터 응용 프로그램과 연관되어 있는 상황 정보를 획득하는 수단(24), 및 상황 정보에 기초하여 데이터 패킷의 전송을 위해 모바일 송수신기(100)를 스케줄링하는 수단(26)을 추가로 포함한다. 도 1에 도시된 바와 같이, 수신하는 수단(22), 획득하는 수단(24), 및 스케줄링하는 수단(26)은 서로 결합되어 있다.

더욱이, 도 1은 데이터 서버(300)에 대한 장치(30)의 일 실시예를 나타내고 있으며, 데이터 서버는 모바일 송수신기(100) 상에서 실행 중인 응용 프로그램과 연관되어 있는 데이터 패킷을 모바일 통신 시스템(500)을 통해 모바일 송수신기(100)로 전달한다. 데이터 서버 장치(30)는 기지국 송수신기(200)로부터 수신된 분류 정보에 기초하여 데이터 패킷에 대한 상황 정보를 도출하는 수단(32), 및 상황 정보를 데이터 패킷과 함께 모바일 통신 시스템(500)으로 송신하는 수단(34)을 포함한다. 도출하는 수단(32), 및 송신하는 수단(34)은 서로 결합되어 있다.

이하에서, 3GPP LTE 셀룰러 무선 액세스 네트워크(500)의 예에 대한 상황 정보의 계층간 시그널링의 일 실시예가 기술될 것이다. 도 2는 모바일 디바이스(100)의 실시예 및 기지국(200)의 실시예를 갖는 통신 네트워크(500)를 나타낸 것이다. 도 2는 상황 인식 자원 할당 시스템 아키텍처를 나타낸 것이고, 상황 인식 자원 할당(Context-Aware Resource Allocation, CARA) 프레임워크의 각자의 구성요소들과 관련하여, 추가의 상세는 EP 11305685에서 찾아볼 수 있다. 도 2는 시그널링에 대한 관련 구성요소들을 나타내고 있다.

실시예들에 대한 이하의 설명에서, 상황 정보는 응용 프로그램의 서비스 품질 요구사항에 관한 정보, 응용 프로그램과 연관되어 있는 데이터 패킷의 우선순위 정보, 응용 프로그램의 복수의 데이터 패킷의 통합체에 관한 정보, 응용 프로그램의 부하 요구에 관한 정보, 응용 프로그램의 지연 또는 오류율 제약조건에 관한 정보, 창 상태에 관한 정보, 메모리 소비량에 관한 정보, 모바일 송수신기(100) 상에서 실행 중인 응용 프로그램의 프로세서 사용량에 관한 정보, 모바일 송수신기(100)의 현재의 위치, 속도, 배향에 관한 정보, 하나 이상의 데이터 패킷과 스케줄링 큐 간의 매핑 정보, 또는 모바일 송수신기(100)와 다른 모바일 송수신기 간의 거리의 그룹 중 하나 이상의 요소를 포함하는 것으로 가정된다.

모바일 송수신기(100) 측에서, 도 2는 모바일 단말 상에서 실행되는 몇 개의 응용 프로그램(App)(102)을 나타내고 있다. 응용 프로그램(102)은 플랫폼 라이브러리(104)와 상호작용하고, 플랫폼 라이브러리(104)는 차례로 모바일 송수신기(100)의 운영 체제(106)와 상호작용한다. 응용 프로그램(102), 플랫폼 라이브러리(104), 및/또는 운영 체제(106)는 상황 정보를 모바일 송수신기 장치(10) - 상황 시그널링과 함께 CARA 트랜잭션 관리자(10)로서 구현됨 - 에 제공할 수 있다. 운영 체제(106)는 물론 트랜잭션 관리자(10)는, 각각, 무선 네트워크(108), 그의 하위 계층들과 상호작용한다. 본 실시예에서는, 무선 네트워크(108)는 LTE 계층 2 또는 IP-서비스와 관련한 전송 계층 서비스를 제공할 수 있다.

기지국(200)은 상황 사용량 및/또는 시그널링과 함께 CARA 트랜잭션 스케줄러(20)로서 구현되는 기지국 송수신기 장치(20)를 포함하고 있다. 더욱이, 트랜잭션 스케줄러(20)는 상이한 트랜잭션들에 대한 데이터 버퍼들이 위치해 있는 스케줄링 큐(202)와 상호작용한다. 트랜잭션 스케줄러(20)는 물론 스케줄링 큐(202)는, 각각, 무선 네트워크(204), 그의 하위 계층들과 상호작용한다. 모바일 송수신기(100)와 유사하게, 무선 네트워크(204)는 LTE 계층 2 또는 IP와 관련한 전송 계층 서비스를 트랜잭션 스케줄러(20) 및 스케줄링 큐(202)에 제공할 수 있다. 스케줄링 큐(202)는 인터넷(300) - 본 실시예에서, 데이터 서버(300)도 포함함 - 과 통신하거나 상호작용한다. 도 2에서 알 수 있는 바와 같이, 2개의 무선 네트워크 엔터티(108 및 204)는 사용자 데이터(즉, 페이로드 데이터 패킷) 및 시그널링 데이터(즉, 제어 데이터 패킷)를 교환한다. 모바일 송수신기(100) 측에 있는 트랜잭션 관리자(10)와 기지국 송수신기(200) 측에 있는 트랜잭션 스케줄러(20) 사이에, 상황 프로토콜(context protocol)(예컨대, 트랜잭션 프로토콜)이 설정된다.

본 실시예에서는, 트랜잭션이 DLC에서의 응용 프로그램-계층 데이터 흐름을 나타내는 데이터 단위 또는 데이터 패킷으로서 간주될 수 있다. 트랜잭션은 결과가 사용자에게 전달될 때까지 응용 프로그램 계층에서의 사용자의 첫 번째 요청으로부터의 모든 DLC 프레임(예컨대, 웹 페이지의 부하)을 포함할 수 있다(즉, 그 웹 페이지에 포함되어 있는 모든 요소들). 트랜잭션은 응용 프로그램의 QoS 요구사항 및 링크 계층 프레임과 트랜잭션 간의 매핑에 관한 정보를 포함할 수 있다. 이 정보는 핸드헬드 에이전트[즉, 도 2에서의 CARA 트랜잭션 관리자(10)]에 수집된다. 많은 경우에, 트랜잭션 관리자(10)는 응용 프로그램, 플랫폼 라이브러리[예컨대, 안드로이드 API(Application Programming Interface)] 또는 운영 체제[예컨대, 리눅스 커널(Linux Kernel)]로부터 요구사항에 관한 상황 정보를 추출할 수 있다. 트랜잭션에 속하는 하향링크 데이터 패킷을 식별하는 것은 종종 IP 헤더에서의 5-튜플 및 "시작" 및 "끝"을 나타내는 전송 계층의 스트림 위치에 의해 달성될 수 있다.

기지국 송수신기(200) 측에서, 스케줄링하는 수단(26)은 복수의 트랜잭션들에 대한 전송 시퀀스를 결정하는 동작을 한다. 복수의 트랜잭션들은 하나 이상의 모바일 송수신기(100)에 의해 실행되고 있는 복수의 응용 프로그램들을 말하는 것이다. 따라서, 트랜잭션은 복수의 데이터 패킷들에 대응할 수 있고, 상황 정보는 이들 데이터 패킷에 대한 통합체를 나타낸다. 이것은 또한 도 2에서 다수의 스케줄링 큐(202)에 의해 나타내어져 있으며, 이들 각각은 하나의 전송에 대한 페이로드 데이터 패킷을 보유하거나 버퍼링할 수 있다.

트랜잭션 관리자(10)는 고려된 응용 프로그램에 의해 사용 중인 네트워크 소켓으로부터 이 정보를 추출할 수 있다. 트랜잭션을 사용하여 응용 프로그램 데이터를 흐름에 매핑하는 한 예가 도 3에 주어져 있다. 도 3은 2개의 트랜잭션, 일 실시예에서, "트랜잭션 1" 및 "트랜잭션 2"를 나타내고 있다. 더욱이, 도 3은 상이한 UDP 및 TCP(Transmission Control Protocol) 연결 "UDP 1", "TCP 1", "TCP 2", "TCP 3"을 나타내고 있다. 응용 프로그램에 따라, 다수의 전송 계층 연결(예컨대, TCP를 사용함)이 동일한 트랜잭션(예컨대, 트랜잭션 1)에 속할 수 있거나, 하나의 연결이 다수의 트랜잭션을 포함할 수 있다(예컨대, TCP1). 각각의 전송 계층 세션은 BS(200)에서 스케줄링되는 IP 패킷 및 DLC 프레임을 포함하고 있다.

트랜잭션의 QoS 요구사항은 효용 함수에 의해 표현될 수 있다. 예를 들어, 웹 브라우저 내에서의 웹 서핑 세션에 속하는 트랜잭션에 대해, 웹 페이지를 요청한 후 얼마 안되어 웹 페이지가 보여질 때 사용자는 만족된다. 이것은 트랜잭션의 효용을 그의 완료 시간(즉, 사용자가 결과를 볼 수 있는 시간)으로 나타내는 도 4에 도시된 바와 같은 지연-의존적 효용 함수로서 표현될 수 있다. CARA 트랜잭션 스케줄러는 셀마다 모든 사용자에 대한 QoS를 실질적으로 향상시키기 위해 이러한 상황 정보를 이용할 수 있다(M. Proebster 등의 논문을 참조할 것). 도 4는 효용 함수 U(t) 대 시간 t를 나타낸 것이다. 효용 함수는 변하는 통신 지연 t에 대한 사용자의 만족도를 표현한다. 시작 시간 t_start에서, 효용 함수는 그의 최대 값에 있고, 이 최대 값은 도 4에서 1로 정규화되어 있다. 예상 시간(즉, 사용자가 트랜잭션을 기다릴 것으로 예상할 수 있는 시간) 후에, U(t)는 상당히 감소된 것이 아니라 단지 조금만 감소되었다. 예상 시간 후에, U(t)는, 변곡 시간(inflection time) t_infl 후에, 그의 최대 감소 속도에 도달할 때까지 더 빠르게 감소하기 시작한다. 그러면, 스케줄링될 트랜잭션들의 시퀀스의 순서는 그들 각자의 효용 함수에 기초할 수 있다.

전송 시퀀스는, 예를 들어, 다수의 상이한 트랜잭션 시퀀스들의 반복으로부터 결정될 수 있다. 다수의 상이한 시퀀스들은 복수의 트랜잭션들의 상이한 순열에 대응한다. 기지국 송수신기 장치(20)에서, 스케줄링하는 수단(26)은 다수의 상이한 시퀀스들 각각에 대한 합 효용 함수(sum utility function)를 결정하는 동작을 하고, 또한 다수의 상이한 시퀀스들로부터 효용 함수들의 최대 합에 대응하는 전송 시퀀스를 선택하는 동작을 한다. 스케줄링하는 수단(26)은 또한 각각의 트랜잭션에 대해 지원가능한 데이터 전송률에 기초하여 전송 시퀀스를 수정하는 동작을 할 수 있고, 지원가능한 데이터 전송률은, 예컨대, CQI와 관련하여 모바일 송수신기(100)로부터 수신된 측정 및 그에 따른 보고를 통해 결정될 수 있다.

트랜잭션 정보를 신호하기 위한 3GPP EPC의 구성요소들은 물론 시그널링 경로가 도 5에 도시되어 있다. 도 5는 모바일 송수신기 또는 UE(100), 기지국 송수신기 또는 eNodeB(200), HSS(Home Subscriber Server)(210), MME(Mobility Management Entity)(212), S-GW(Serving-GateWay)(400), 및 인터넷(310)에 연결되어 있는 PDN-GW(300)를 나타내고 있다. 도 5에 추가로 나타낸 바와 같이, eNodeB(200)는 S1-사용자 평면(S1-U) 프로토콜을 사용하여 S-GW(400)와 통신한다. eNodeB(200)는 또한 S1-MME 프로토콜을 사용하여 MME(212)와 통신한다. 더욱이, PDN-GW(300)는 S5/S8 프로토콜을 사용하여 S-GW(400)와 통신한다. HSS(210)는 S6a 프로토콜을 사용하여 MME(212)와 통신하고, MME(212)는 S11 프로토콜을 사용하여 S-GW(400)와 통신한다. 이들 구성요소 및 프로토콜에 관한 추가 상세는 3GPP 규격들에서 찾아볼 수 있다. 이하에서, HSS(210) 및 MME(212)는, 시그널링에 필요하지 않기 때문에, 무시된다.

도 5의 하부에 있는 화살표는 실시예들의 시그널링 경로를 나타내며, 이에 대해서는 나중에 상세히 기술할 것이다. 위쪽에 원으로 둘러싸인 1 및 2를 갖는 짧은 화살표는 UE(100)와 eNB(200) 사이의 직접 통신을 사용하는 도 6 및 도 7에 기술되는 실시예들의 시그널링 경로를 나타낸다. 아래쪽에 원으로 둘러싸인 3 및 4를 갖는 UE(100)로부터 PDN-GW(300)으로 다시 eNB(200)로 가는 긴 화살표는 PDN-GW(300)를 통한 UE(100)로부터 eNB(200)로의 간접 통신을 사용하는 도 8 및 도 9에 기술되어 있는 실시예들의 시그널링 경로를 나타낸다.

이하에서, 직접 제어-평면 시그널링(direct control-plane signaling)을 사용하는 제1 실시예가 기술될 것이다. 도 6은 이 실시예에서의 프로토콜 스택을 나타낸 것이다. UE(100) 측에서, 도 6은 계층 1 또는 PHY, MAC 및 RLC로서의 계층 2, 및 RLC 상부의 트랜잭션 프로토콜 "Tr-프로토콜"을 나타내고 있다.

따라서, 이 실시예에서, 모바일 송수신기 장치(10)는 트랜잭션 프로토콜 "Tr-프로토콜"의 일부로서 트랜잭션 데이터 패킷을 작성하는 수단을 추가로 포함한다. 트랜잭션 데이터 패킷은 상황 정보를 포함하고 있다. 이 실시예에서, UE(100)는 UE(100)와 eNB(200) 사이의 전용 제어 채널을 사용한다. 도 6은 각각의 장치에 대한 계층화된 스택을 나타내고 있다. 피어 엔터티들 사이의 라인들은 그 엔터티들 간의 직접 통신을 나타내고, 상위 계층 엔터티들은 하위 계층 엔터티들의 서비스를 사용한다. 트랜잭션 정보는 RLC 계층 상부의 시그널링 프로토콜에 의해 직접 전송되는데, 그 이유는 어드레싱 또는 라우팅이 필요하지 않기 때문이다. 트랜잭션 프로토콜은 트랜잭션들의 QoS 요구사항 및 분류 규칙을 포함하고 있다. eNB(200)는 모든 프로토콜 정보를 수신하고 처리한다. 상황 정보는 링크 계층 프로토콜 제어 데이터 패킷을 사용하여 기지국 송수신기(200)로 전달된다.

따라서, eNodeB(200)에서의 획득하는 수단(24)은 트랜잭션 프로토콜의 일부로서 트랜잭션 데이터 패킷으로부터 상황 정보를 획득하는 동작을 한다. 트랜잭션 데이터 패킷 또는 상황 정보가 링크 계층 프로토콜 제어 데이터 패킷을 사용하여 모바일 송수신기(100)로부터 수신된다. 본 실시예에서는, eNB(200)는 하향링크 데이터 패킷을 분류한다 - 즉, eNB는 헤더 검사를 수행하고 상이한 트랜잭션들의 패킷들을 개별적으로 큐잉할 수 있다[도 2에서의 표시(202)를 참조] -. QoS 요구사항은 eNB(200) 내의 MAC 계층 스케줄러(20)로 직접 전달될 수 있다.

이하에서, 직접 사용자 평면 시그널링을 사용하는 다른 실시예가 기술될 것이다. 도 7은 UE(100)와 eNB(200) 사이의 사용자 또는 제어 평면에서의 시그널링을 사용하는 일 실시예에서의 프로토콜 스택을 나타낸 것이다. 도 6에 도시된 이전의 실시예와 비교하여, 트랜잭션 프로토콜은 UDP, 아래에 있는 IP, PDCP, 및 앞서 기술된 바와 같은 하위 계층들을 사용한다. 응용 프로그램 계층에서, 시그널링 정보는 UE(100)로부터 eNB(200)로 전송된다. UE(100)는 IP 애니캐스트를 통해 기지국(200)을 어드레싱할 수 있는데, 그 이유는, UE(100)의 관점에서 볼 때, 기지국(200)이 네트워크로의 게이트웨이이기 때문이다. 시그널링 정보가 보통 다수의 IP 패킷에 걸쳐 확장되지 않고 RLC 메커니즘이 패킷 손실을 방지할 수 있기 때문에, 확인 응답 모드(acknowledged mode)에서 사용될 때, UE(100)와 eNB(200) 사이에서, 시그널링을 위해 비연결(connectionless) UDP(User Datagram Protocol) 스트림을 사용하는 것으로 충분하다. 선택적으로, eNB로부터의 간단한 확인 응답-메커니즘이 고안될 수 있다. 따라서, 본 실시예에서는, 트랜잭션 데이터 패킷은 애니캐스트 페이로드 데이터 패킷을 사용하여 기지국 송수신기(200)로 전달된다. 애니캐스트 페이로드 데이터 패킷은 TOS 표시를 갖는 IP 패킷 또는 목적지 포트 표시를 갖는 UDP 패킷에 대응할 수 있다. 분류에 대해, eNB(200)는 이전의 실시예에서와 동일한 능력을 가진다.

간접 제어 평면 시그널링을 사용하는 다른 실시예는 나중에 기술될 것이다. 도 8은 PDN-GW(300)로서 구현되는 데이터 서버(300)에서의 전용 제어 채널 및 하향링크 패킷 분류를 사용하는 일 실시예에서의 프로토콜 스택을 나타낸 것이다. 이 실시예에서, 도 6에 기술되어 있는 실시예에서와 같이, 트랜잭션 시그널링 프로토콜은 eNB(200)로 전송된다. eNB(200)는 이어서, 개별적인 프로토콜을 사용하여, 트랜잭션의 QoS 요구사항을 MAC 스케줄러(20)로 그리고 분류 정보를 UDP를 통해 PDN-GW(300)로 전달한다. S-GW(400)는 이 실시예에서 릴레이(relay)로서만 역할한다. S-GW(400) 쪽으로 그리고 S-GW(400)와 PDN-GW(300) 사이에서, 하위 계층들은 계층 1(L1) 및 계층 2(L2)로서 표시되어 있다. 도 8에서 "*"에 의해 나타낸 바와 같이, 수정된 트랜잭션 프로토콜 "Tr-P*"은 상황 정보를 분류 정보로서 S-GW(400)를 통해 eNB(200)로부터 PDN-GW(300)로 전달하는 데 사용된다. 분류 정보는 스케줄러 큐에 대한 QoS 설정 또는 요구사항, 또는 기지국 송수신기(200)의 스케줄러(20)에서의 트랜잭션 상황에 대응할 수 있다. 기지국 송수신기(200)에서, 상황 정보는 따라서 기지국 송수신기(200)로부터 분류 정보를 제공받는 데이터 서버(300)로부터 수신된다.

PDN-GW(300)는 표준들에서 DPI를 수행할 수 있을 것으로 예상된다. 이와 같이, PDN-GW(300)는 신호된 정보에 따라 하향링크 데이터 패킷을 분류할 수 있다. PDN-GW(300)는, 데이터 패킷을 분류한 후에, 분류에 관하여 eNB(200)에 통보한다. EPC는 플랫 IP 아키텍처(flat IP architecture)를 이용하므로, IP 헤더에서의 DSCP(Differentiated Services Field Codepoint)가 트랜잭션들을 구별하는 데 사용될 수 있다. 이러한 방식으로, IPv4에서 단일의 UE에 대해 한 번에 64개의 트랜잭션들이 구별될 수 있다. IPv6에서는, 훨씬 더 많은 트랜잭션들(220-1)이 흐름 라벨(flow label)에 의해 구별될 수 있다. 따라서, 상황 정보는 데이터 서버(300)로부터 수신된 데이터 패킷에서의 태그에 대응할 수 있다.

다른 실시예는 간접 사용자 평면 시그널링을 사용한다. 도 9는 상황 정보의 간접적인 제공에 의한 데이터 평면에서의 시그널링을 사용하는 일 실시예에서의 프로토콜 스택을 나타낸 것이다. 도 9는 데이터 평면을 통한 UE(100)와 PDN-GW(300) 사이의 시그널링을 나타낸 것이다. eNB(200)는 GTP-U(General packet radio service Tunneling Protocol in the User-plane, 사용자 평면에서의 일반 패킷 무선 서비스 터널링 프로토콜)를 사용하여 각자의 데이터 패킷을 S-GW(400)로 전달하고, S-GW(400)도 역시 GTP-U를 사용하여 각자의 데이터 패킷을 PDN-GW(300)로 전달한다. 또한 도 9에 나타낸 바와 같이, eNB(200) 및 S-GW(400)는 릴레이로서 간주된다. 각자의 구성요소에서의 프로토콜 스택은 앞서 기술한 것과 유사하다.

패킷 분류가 PDN-GW(300)에서 수행되고, PDN-GW(300)는 또한 트랜잭션 요구사항을 eNB(200)로 전달한다. 도 9에 도시된 실시예들은 UE(100)로부터 PDN-GW(300)로의 시그널링을 위해 응용 프로그램 계층 전송을 이용한다. 이것은, 이상의 설명에 따라, [PDN-GW(300)의 IP 주소를 알고 있는 경우] IP 애니캐스트 또는 유니캐스트에 의해 달성될 수 있다. 트랜잭션 데이터 패킷이 애니캐스트 또는 유니캐스트 페이로드 데이터 패킷을 사용하여 모바일 송수신기(100)로부터 PDN-GW(300)에 수신된다. PDN-GW(300)는 트랜잭션의 QoS 요구사항을 개별적인 프로토콜을 통해 다시 eNB(200)에 신호한다. 어떤 실시예들에서, 다수의 PDN-GW가 모바일 송수신기(100)에 서비스할 수 있다. 이 경우에, 애니캐스트 페이로드 데이터 패킷이 하나의 PDN-GW에 의해 수신될 수 있고, 이 PDN-GW가 이어서 다른 PDN-GW들로 통보할 수 있거나, 그러면 이것이 오히려 멀티캐스트 페이로드 데이터 패킷을 말하는 것일 수 있을지라도, 다수의 PDN-GW 모두가 멀티캐스트(애니캐스트) 데이터 패킷을 수신할 수 있다. 이 실시예에서는, 도 8에 기술된 실시예에서와 같이, PDN-GW(300)에서 분류가 수행된다. 실시예들에서, 트랜잭션 데이터 패킷은 유니캐스트 페이로드 데이터 패킷을 사용하여 데이터 서버(300)로 전달될 수 있다 - 예컨대, UE(100)는 IP 패킷을 직접 PDN-GW(300)로 어드레싱한다 -.

따라서, 데이터 서버 장치(30)는, 예컨대, Tr-P*에 따라 데이터 패킷을 작성하는 수단을 포함한다. 데이터 패킷은 응용 프로그램 데이터 패킷 및 데이터 패킷과 기지국 송수신기(200)에서의 스케줄링 큐 간의 매핑 정보를 갖는 태그를 포함한다. 응용 프로그램 데이터 패킷 및 상황 정보를 포함하는 트랜잭션 데이터 패킷이 작성될 수 있다. 일부 실시예에서, 상황 정보를 갖는 데이터 패킷 헤더 또는 응용 프로그램의 서비스 품질 요구사항을 포함하는 데이터 패킷이 작성될 수 있다.

도 6 및 도 7에 기술된 실시예들은 eNB(200)가 하향링크 데이터 패킷을 분류하기 위해 적어도 IP 및 전송 프로토콜 헤더를 검사할 수 있는 것으로 가정한다. 그렇지만, LTE 시스템에서, 이렇지 않을 수 있는데, 그 이유는 데이터가 PDN-GW(300)와 UE(100) 사이에서 (예컨대, 터널링 프로토콜 GTP-U를 통해) 터널링 및/또는 암호화될 수 있기 때문이다. 따라서, 도 8 및 도 9에 기술된 실시예들은 eNB(200)에서 보다 낮은 처리 능력을 가능하게 해준다는 이점을 가질 수 있다.

모바일 디바이스(100)는 도 7의 실시예와 도 9의 실시예를 구별할 수도 없고 도 6의 실시예와 도 8의 실시예를 구별할 수도 없다. 모바일 디바이스(100)의 경우, 시그널링의 유형만을 알고 있다.

이하에서, 트랜잭션 시그널링 프로토콜의 예시적인 실시예가 기술된다. 이하의 프로토콜 설명은 CARA에 대한 시그널링의 간략화된 텍스트-기반 실현이다. 앞서 기술한 바와 같이, 시그널링이 UE(100)에 의해 (단방향으로) eNB(200)[또는 PDN-GW(300)]로 송신된다. 이 프로토콜은 텍스트 기반이고, 인코딩은 ANSI＼_X3.4-1968(7 비트 ASCII)이다. 줄은 "＼n"(ASCII 코드 0x0A)에 의해 구분되고, 필드들은 단일 공백에 의해 구분된다. 각각의 트랜잭션은 일련의 줄에 의해 형성되어 있다.

첫 번째 줄은 키워드 "Transaction"으로 시작한다. 각각의 후속하는 줄은 보통 전송 계층 연결(transport layer connection)의 섹션인 하나의 트래픽 청크(traffic chunk)를 형성한다. 각각의 트랜잭션에 대한 시그널링은 단일 UDP 데이터그램으로서 송신된다. 이들 데이터그램에 대한 목적지 주소는 수동으로 구성된다. 목적지 포트는 1024이고, 소스 IP 주소는 각각의 UE(100)의 IP 주소이며, 소스 포트는 중요하지 않다. 요구사항, 청크 또는 크기 예측이 변할 때마다, 클라이언트는 트랜잭션 규격(transaction specification)을 재송신할 수 있다. 이들 재송신은 증분적(incremental)이지 않을 수 있다. 이는, 재송신할 때에, 모든 청크가 반복될 수 있다는 것을 의미한다. 상향링크 및 하향링크 청크는 라우팅 테이블을 사용하여 식별될 수 있고, 따라서 그를 명시적으로 지정할 필요가 없다. 응용 프로그램 미디어에 따라, 트랜잭션은 이하의 유형일 수 있다:

FINISH: 트랜잭션의 완료 시간이 중요하다(빠를수록 더 낫다); 예컨대, 웹 서핑

REALTIME: 각각의 패킷이 개별적인 기한(deadline)을 가지고 있다; 예컨대, 음성 호출/생방송 TV

STREAMING: 콘텐츠의 버퍼링이 가능하지만, 전송이 재생 곡선(play-out curve) 아래로 떨어져서는 안 된다; 예컨대, YouTube에서의 버퍼링된 비디오 스트리밍

예시적인 트랜잭션 정의는 다음과 같다:

Transaction web42 FINISH 2300

TCP 10.0.0.10 1025 2.3.4.5 80 0 1200

TCP 2.3.4.5 80 10.0.0.10 1025 0 17000

TCP 2.3.4.5 80 10.0.0.10 1026 0 17000

이 프로토콜에 대한 EBNF(Extended Backus-Naur-Form)는 다음과 같다:

Message Transaction

Transaction "Transaction" Name Requirement "＼n" {Chunk}

Requirement "FINISH" Finish-Time | "REALTIME" Deadline | "STREAMING" Bandwidth

Chunk Filter Start Stop "＼n"

Filter "TCP" SrcIP SrcPort DstIP DstPort | "UDP" SrcIP SrcPort DstIP DstPort

Name 트랜잭션에 대한 임의의 이름(ID 번호일 수도 있음)

SrcIP, DstIP IPv4/IPv6 주소의 텍스트 표현

SrcPort, DstPort 십진수

Start, Stop 이들 파라미터는 이 전송 계층 연결의 어느 바이트가 트랜잭션에 속하는지를 지정할 수 있게 해준다. 길이를 모르는 경우, 예측이 클라이언트에 의해 지정되어야만 한다.

Finish-Time 시그널링 메시지가 수신된 때에 대해(단위: ms)

Deadline 패킷마다(단위: ms)

Bandwidth 단위: 비트/s

이것은 간단한 예이다. 스칼라 요구사항(Finish-Time, Deadline, Bandwidth) 대신에, 실시예들에서, 앞서 기술한 바와 같이, 완전한 효용 곡선이 또한 신호될 수 있다. 예컨대, 함수 유형 및 관련 파라미터와 함께 또는 (x,y) 값의 테이블로서.

이하에서, 일 실시예의 예시적인 사용 사례가 기술될 것이다. 사용자가 웹 브라우저에서 링크를 클릭한다. 모바일 디바이스(100)는 웹 서버(300)와 TCP 연결을 개시하고, 요구사항 및 사용될 IP 5-튜플을 포함하는 새로운 트랜잭션을 기지국(200)에 신호한다. 첫 번째 하향링크 DLC 프레임이 BS(200)에 도착할 때, BS(200)는 신호된 분류를 사용하여 프레임을 트랜잭션 및 그의 요구사항에 매핑할 수 있다. 연결 설정 후에, 모바일 디바이스(100)는 HTTP 요청을 서버(300)로 송신한다. HTTP 응답 헤더가 모바일 디바이스(100)에 도착하자마자, 모바일 디바이스(100)는 예측된 콘텐츠 크기를 포함하는 트랜잭션 업데이트를 BS(200)로 송신할 수 있다. 연구에 의하면, 통상적인 인터넷 트래픽 혼합 구성(Internet traffic mix)에 대해, 이 시그널링 프로토콜의 시그널링 오버헤드는 하향링크 데이터 트래픽의 0.2%에 불과하다.

도 10은 모바일 통신 시스템(500)에서 모바일 송수신기(100)에 대한 방법의 일 실시예의 플로우차트의 블록도를 나타낸 것이다. 모바일 통신 시스템(500)은 기지국 송수신기(200)를 추가로 포함하고 있다. 이 방법은 모바일 송수신기(100) 상에서 실행 중인 응용 프로그램으로부터의 상황 정보, 모바일 송수신기(100) 상에서 실행 중인 운영 체제로부터의 상황 정보, 또는 모바일 송수신기(100)의 하드웨어 드라이버 또는 하드웨어로부터의 상황 정보를 추출하는 단계(712)를 포함하며, 상황 정보는 응용 프로그램의 상태에 관한 정보 및/또는 모바일 송수신기(100)의 상태에 관한 정보를 포함한다. 이 방법은 기지국 송수신기(200)와 데이터 패킷을 통신하는 단계(714)를 추가로 포함하고, 데이터 패킷은 페이로드 데이터 패킷 및 제어 데이터 패킷을 포함한다. 이 방법은 기지국 송수신기(200)를 통해 데이터 서버(300)와 응용 프로그램과 연관되어 있는 페이로드 데이터 패킷을 통신하는 단계(715), 및 상황 정보를 기지국 송수신기(200)에 제공하는 단계(716)를 추가로 포함하며, 상황 정보는 페이로드 데이터 패킷에 또는 제어 데이터 패킷에 포함되어 있다.

도 11은 모바일 통신 시스템(500)에서 기지국 송수신기(200)에 대한 방법의 일 실시예의 플로우차트의 블록도를 나타낸 것이다. 모바일 통신 시스템(500)은 모바일 송수신기(100)를 추가로 포함하고 있다. 이 방법은 제어 데이터 패킷 및 페이로드 데이터 패킷을 수신하는 단계(722)를 포함하고, 페이로드 데이터 패킷은 모바일 송수신기(100) 상에서 실행 중인 응용 프로그램과 연관되어 있다. 이 방법은 제어 데이터 패킷으로부터 또는 페이로드 데이터 패킷으로부터 응용 프로그램과 연관되어 있는 데이터 패킷에 관한 상황 정보를 획득하는 추가의 단계(724)를 포함한다. 이 방법은 상황 정보에 기초하여 데이터 패킷의 전송을 위해 모바일 송수신기(100)를 스케줄링하는 추가의 단계(726)를 포함한다.

도 12는 데이터 서버(300)에 대한 방법의 일 실시예의 플로우차트의 블록도를 나타낸 것이고, 데이터 서버(300)는 모바일 송수신기(100) 상에서 실행 중인 응용 프로그램과 연관되어 있는 데이터 패킷을 모바일 통신 시스템(500)을 통해 모바일 송수신기(100)로 전달한다. 이 방법은 기지국 송수신기(200)로부터 수신된 분류 정보에 기초하여 데이터 패킷에 대한 상황 정보를 도출하는 단계(732), 및 상황 정보를 데이터 패킷과 함께 모바일 통신 시스템(500)으로 송신하는 단계(734)를 포함한다.

설명 및 도면은 본 발명의 원리를 예시한 것에 불과하다. 따라서, 기술 분야의 당업자가, 본 명세서에 명확히 기술되거나 도시되어 있지는 않지만, 본 발명의 원리를 구현하고 본 발명의 사상 및 범위 내에 포함되는 다양한 구성을 안출할 수 있다는 것을 잘 알 것이다. 게다가, 본 명세서에 인용된 모든 예는 원칙적으로 읽는 사람이 본 발명의 원리 및 기술을 발전시키기 위해 발명자(들)에 의해 구성된 개념들을 이해하는 데 도움을 주기 위한 교육적 목적을 위한 것에 불과한 것으로 보아야 하고, 이러한 구체적으로 인용된 예 및 조건으로 제한하는 것이 아닌 것으로 해석되어야 한다. 더욱이, 본 발명의 원리, 측면, 실시예는 물론 그의 구체적인 예를 언급하는 본 명세서 내의 모든 내용은 그의 등가물을 포함하기 위한 것이다.

(특정의 기능을 수행하는) "~하는 수단"으로 표시되어 있는 기능 블록은, 각각, 특정의 기능을 수행하는 동작을 하는 회로를 포함하는 기능 블록으로서 이해되어야 한다. 따라서, "~을 위한 수단"도 역시 "~을 위해 동작하거나 ~에 적합한 수단"으로서 이해될 수 있다. 따라서, 특정의 기능을 수행하는 동작을 하는 수단은 이러한 수단이 (주어진 순간에) 상기 기능을 꼭 수행하는 것을 암시하지는 않는다.

"수단", "추출하는 수단", "통신하는 수단", "제공하는 수단", "수신하는 수단", "획득하는 수단", "스케줄링하는 수단", "도출하는 수단", "전송하는 수단" 등으로 표시된 임의의 기능 블록들 포함한 도면들에 도시되어 있는 다양한 요소들의 기능은, 예컨대, 프로세서, "추출기", "통신기", "제공기", "수신기", "획득기", "스케줄러", "도출기", "송신기" 등과 같은 전용 하드웨어는 물론, 적절한 소프트웨어와 관련하여 소프트웨어를 실행할 수 있는 하드웨어를 사용하여 제공될 수 있다. 프로세서에 의해 제공될 때, 기능들은 단일의 전용 프로세서에 의해, 단일의 공유 프로세서에 의해, 또는 복수의 개별 프로세서들(이들 중 일부는 공유될 수 있음)에 의해 제공될 수 있다. 더욱이, "프로세서" 또는 "제어기"라는 용어의 명시적인 사용은 소프트웨어를 실행할 수 있는 하드웨어만을 말하는 것으로 해석되어서는 안되고, 암시적으로 디지털 신호 처리기(DSP) 하드웨어, 네트워크 프로세서, ASIC(application specific integrated circuit), FPGA(field programmable gate array), 소프트웨어를 저장하는 ROM(read only memory), RAM(random access memory), 및 비휘발성 저장 장치(이들로 제한되지 않음)를 포함할 수 있다. 다른 하드웨어(종래의 하드웨어 및/또는 커스텀 하드웨어)도 포함될 수 있다.

기술 분야의 당업자라면 본 명세서에서의 임의의 블록도가 본 발명의 원리들을 구현하는 예시적인 회로의 개념도를 나타낸다는 것을 잘 알 것이다. 이와 유사하게, 임의의 플로우차트, 흐름도, 상태 천이도, 의사 코드 등이 실질적으로 컴퓨터 판독가능 매체에 표현될 수 있고 컴퓨터 또는 프로세서에 의해 - 이러한 컴퓨터 또는 프로세서가 명시적으로 도시되어 있든 그렇지 않든 간에 - 그렇게 실행될 수 있는 다양한 프로세스를 나타낸다는 것을 잘 알 것이다.

게다가, 이하의 청구항들은 이로써 상세한 설명에 포함되고, 여기서 각각의 청구항은 그 자체로서 개별적인 실시예가 될 수 있다. 각각의 청구항이 그 자체로서 개별적인 실시예가 될 수 있지만, 유의할 점은, - 비록 종속 청구항이 청구항들에서 하나 이상의 다른 청구항들과의 특정의 조합을 참조할 수 있지만 - 다른 실시예들이 또한 종속 청구항과 각각의 다른 종속 청구항의 발명 요지의 조합을 포함할 수 있다는 것이다. 특정의 조합이 의도되어 있지 않다고 언급되어 있지 않는 한, 이러한 조합은 본 명세서에 제안되어 있다. 게다가, 한 청구항이 임의의 다른 독립 청구항에 직접 종속되어 있지 않을지라도, 그 독립 청구항에 대한 이 청구항의 특징도 포함하는 것으로 보아야 한다.

또한, 유의할 점은, 본 명세서에 또는 특허청구범위에 개시되어 있는 방법이 이들 방법의 각자의 단계들 각각을 수행하는 수단을 가지는 디바이스에 의해 구현될 수 있다는 것이다.

게다가, 본 명세서 또는 특허청구범위에 개시되어 있는 다수의 단계들 또는 기능들의 개시가 특정의 순서 내에 있는 것으로 해석되어서는 안 된다는 것을 잘 알 것이다. 따라서, 다수의 단계들 또는 기능들의 개시 내용은, 이러한 단계들 또는 기능들이 기술적 이유로 변경될 수 없는 것이 아닌 한, 이들을 특정의 순서로 제한하지 않는다. 게다가, 어떤 실시예들에서, 하나의 단계가 다수의 서브 단계들을 포함할 수 있거나 다수의 서브 단계들로 나누어질 수 있다. 이러한 서브 단계들이 포함될 수 있고, 명시적으로 배제되지 않는 한, 이 하나의 단계의 개시 내용의 일부일 수 있다.

Claims

모바일 통신 시스템(500)을 위한 모바일 송수신기(100)용의 장치(10)로서 - 상기 모바일 통신 시스템(500)은 기지국 송수신기(200)를 포함함 -,
상기 모바일 송수신기(100) 상에서 실행되는 응용 프로그램(application)으로부터의 상황 정보(context information), 상기 모바일 송수신기(100) 상에서 실행되는 운영 체제로부터의 상황 정보, 또는 상기 모바일 송수신기(100)의 하드웨어 드라이버들 또는 하드웨어로부터의 상황 정보를 추출하는 수단(12) - 상기 상황 정보는 상기 응용 프로그램의 상태에 관한 정보 및/또는 상기 모바일 송수신기(100)의 상태에 관한 정보를 포함함 -;
상기 기지국 송수신기(200)와 데이터 패킷들을 통신하는 수단(14) - 상기 데이터 패킷들은 페이로드 데이터 패킷들 및 제어 데이터 패킷들을 포함하고, 상기 통신하는 수단(14)은 상기 응용 프로그램과 연관되는 페이로드 데이터 패킷들을 상기 기지국 송수신기(200)를 통해 데이터 서버(300)와 통신하도록 동작 가능함 -; 및
상기 상황 정보를 상기 기지국 송수신기(200)에 제공하는 수단(16) - 상기 상황 정보는 페이로드 데이터 패킷에 또는 제어 데이터 패킷에 포함됨 -
을 포함하는 장치(10).
제1항에 있어서, 상기 상황 정보는, 상기 응용 프로그램의 서비스 품질 요구사항에 관한 정보, 상기 응용 프로그램과 연관되는 상기 데이터 패킷들의 우선순위 정보, 상기 응용 프로그램의 복수의 상기 데이터 패킷들의 통합체(unity)에 관한 정보, 상기 응용 프로그램의 부하 요구(load demand)에 관한 정보, 상기 응용 프로그램의 지연 또는 오류율 제약조건(delay or error rate constraint)에 관한 정보, 창 상태(window state)에 관한 정보, 메모리 소비량(memory consumption)에 관한 정보, 상기 모바일 송수신기(100) 상에서 실행되는 상기 응용 프로그램의 프로세서 사용량(processor usage)에 관한 정보, 상기 모바일 송수신기(100)의 현재의 위치, 속도, 배향에 관한 정보, 또는 상기 모바일 송수신기(100)와 다른 모바일 송수신기 간의 거리로 이루어지는 그룹 중 하나 이상의 요소를 포함하는 장치(10).
제1항에 있어서, 트랜잭션 프로토콜의 일부로서 트랜잭션 데이터 패킷을 작성(composing)하는 수단을 더 포함하고, 상기 트랜잭션 데이터 패킷은 상기 상황 정보를 포함하고, 상기 트랜잭션 데이터 패킷은 애니캐스트(any-cast) 페이로드 데이터 패킷을 사용하여 상기 기지국 송수신기(200)로 전달되거나, 상기 트랜잭션 데이터 패킷은 유니캐스트 페이로드 데이터 패킷을 사용하여 상기 데이터 서버(300)로 전달되거나, 또는 상기 트랜잭션 데이터 패킷 또는 상기 상황 정보는 링크 계층 프로토콜 제어 데이터 패킷을 사용하여 상기 기지국 송수신기(200)로 전달되는 장치(10).
모바일 통신 시스템(500)을 위한 기지국 송수신기(200)용의 장치(20)로서 - 상기 모바일 통신 시스템(500)은 모바일 송수신기(100)를 더 포함함 -,
제어 데이터 패킷들 및 페이로드 데이터 패킷들을 수신하는 수단(22) - 상기 페이로드 데이터 패킷들은 상기 모바일 송수신기(100) 상에서 실행되는 응용 프로그램과 연관됨 -;
제어 데이터 패킷으로부터 또는 페이로드 데이터 패킷으로부터 상기 응용 프로그램과 연관되는 상황 정보를 획득하는 수단(24); 및
상기 상황 정보에 기초하여 상기 데이터 패킷들의 전송에 대해 상기 모바일 송수신기(100)를 스케줄링하는 수단(26)
을 포함하는 장치(20).
제4항에 있어서, 상기 획득하는 수단(24)은 트랜잭션 프로토콜의 일부로서 트랜잭션 데이터 패킷으로부터 상기 상황 정보를 획득하도록 동작 가능하고, 상기 트랜잭션 데이터 패킷은 애니캐스트 페이로드 데이터 패킷을 사용하여 상기 모바일 송수신기(100)로부터 수신되거나, 상기 트랜잭션 데이터 패킷은 유니캐스트 페이로드 데이터 패킷을 사용하여 데이터 서버(300)로부터 수신되거나, 상기 트랜잭션 데이터 패킷 또는 상기 상황 정보는 링크 계층 프로토콜 제어 데이터 패킷을 사용하여 상기 모바일 송수신기(100)로부터 수신되거나, 또는 상기 상황 정보는, 상기 기지국 송수신기(200)로부터 분류 정보를 제공받는 상기 데이터 서버(300)로부터 수신되고, 상기 상황 정보는 상기 데이터 서버(300)로부터 수신된 데이터 패킷에서의 태그에 대응하는 장치(20).
제4항에 있어서, 상기 스케줄링하는 수단(26)은 복수의 트랜잭션들에 대한 전송 시퀀스를 결정하도록 동작 가능하고, 상기 복수의 트랜잭션들은 하나 이상의 모바일 송수신기(100)에 의해 실행되는 복수의 응용 프로그램들을 지칭하고, 트랜잭션은 복수의 데이터 패킷들에 대응하고, 상기 상황 정보는 상기 복수의 데이터 패킷들에 대한 통합체를 나타내며, 트랜잭션들의 시퀀스의 순서는 효용 함수(utility function)에 기초하고, 상기 효용 함수는 상기 상황 정보에 기초하여 결정되는 트랜잭션의 완료 시간에 의존하고, 그리고/또는
상기 상황 정보는, 상기 응용 프로그램의 서비스 품질 요구사항에 관한 정보, 상기 응용 프로그램과 연관되는 상기 데이터 패킷들의 우선순위 정보, 상기 응용 프로그램의 복수의 상기 데이터 패킷들의 통합체에 관한 정보, 상기 응용 프로그램의 부하 요구에 관한 정보, 상기 응용 프로그램의 지연 또는 오류율 제약조건에 관한 정보, 창 상태에 관한 정보, 메모리 소비량에 관한 정보, 상기 모바일 송수신기(100) 상에서 실행되는 상기 응용 프로그램의 프로세서 사용량에 관한 정보, 상기 모바일 송수신기(100)의 현재의 위치, 속도, 배향에 관한 정보, 하나 이상의 데이터 패킷과 스케줄링 큐 사이의 매핑 정보, 또는 상기 모바일 송수신기(100)와 다른 모바일 송수신기 간의 거리로 이루어지는 그룹 중 하나 이상의 요소를 포함하는 장치(20).
제6항에 있어서, 상기 전송 시퀀스는 다수의 상이한 트랜잭션 시퀀스들의 반복으로부터 결정되고, 상기 다수의 상이한 시퀀스들은 상기 복수의 트랜잭션들의 상이한 순열에 대응하고, 상기 스케줄링하는 수단(26)은, 상기 다수의 상이한 시퀀스들 각각에 대해 상기 효용 함수를 결정하도록 동작 가능하며, 상기 다수의 상이한 시퀀스들로부터 상기 효용 함수의 최대값에 대응하는 상기 전송 시퀀스를 선택하도록 또한 동작 가능하고, 그리고/또는 상기 스케줄링하는 수단(26)은 각각의 트랜잭션에 대해 지원가능한 데이터 전송률(data rate)에 기초하여 상기 전송 시퀀스를 수정하도록 또한 동작 가능한 장치(20).
데이터 서버(300)를 위한 장치(30)로서 - 상기 데이터 서버(300)는 모바일 송수신기(100) 상에서 실행되는 응용 프로그램과 연관되는 데이터 패킷들을 모바일 통신 시스템(500)을 통해 상기 모바일 송수신기(100)로 전달함 -,
기지국 송수신기(200)로부터 수신된 분류 정보에 기초하여 상기 데이터 패킷들에 대한 상황 정보를 도출하는 수단(32); 및
상기 데이터 패킷들과 함께 상기 상황 정보를 상기 모바일 통신 시스템(500)으로 송신하는 수단(34)
을 포함하는 장치(30).
제8항에 있어서, 상기 상황 정보는, 상기 응용 프로그램의 서비스 품질 요구사항에 관한 정보, 상기 응용 프로그램과 연관되는 상기 데이터 패킷들의 우선순위 정보, 상기 응용 프로그램의 복수의 상기 데이터 패킷들의 통합체에 관한 정보, 상기 응용 프로그램의 부하 요구에 관한 정보, 상기 응용 프로그램의 지연 또는 오류율 제약조건에 관한 정보, 창 상태에 관한 정보, 메모리 소비량에 관한 정보, 상기 모바일 송수신기(100) 상에서 실행되는 상기 응용 프로그램의 프로세서 사용량에 관한 정보, 상기 모바일 송수신기(100)의 현재의 위치, 속도, 배향에 관한 정보, 하나 이상의 데이터 패킷과 스케줄링 큐 사이의 매핑 정보, 또는 상기 모바일 송수신기(100)와 다른 모바일 송수신기 간의 거리로 이루어지는 그룹 중 하나 이상의 요소를 포함하고, 상기 도출하는 수단(32)은, 상기 모바일 송수신기(100)로부터 수신된 유니캐스트 페이로드 데이터 패킷으로부터 또는 상기 기지국 송수신기(200)로부터의 유니캐스트 페이로드 데이터 패킷으로부터 상기 상황 정보를 도출하도록 동작 가능한 장치(30).
제8항에 있어서, 데이터 패킷을 작성하거나 - 상기 데이터 패킷은 응용 프로그램 데이터 패킷들, 및 데이터 패킷과 상기 기지국 송수신기(200)에서의 스케줄링 큐 간의 매핑 정보를 갖는 태그를 포함함 -, 응용 프로그램 데이터 패킷들 및 상기 상황 정보를 포함하는 트랜잭션 데이터 패킷을 작성하거나, 상기 상황 정보를 갖는 데이터 패킷 헤더를 작성하거나, 또는 상기 응용 프로그램의 서비스 품질 요구사항을 포함하는 데이터 패킷을 작성하는 수단을 더 포함하는 장치(30).
모바일 통신 시스템(500)에서의 모바일 송수신기(100)에 대한 방법으로서 - 상기 모바일 통신 시스템(500)은 기지국 송수신기(200)를 더 포함함 -,
상기 모바일 송수신기(100) 상에서 실행되는 응용 프로그램으로부터의 상황 정보, 상기 모바일 송수신기(100) 상에서 실행되는 운영 체제로부터의 상황 정보, 또는 상기 모바일 송수신기(100)의 하드웨어 드라이버들 또는 하드웨어로부터의 상황 정보를 추출하는 단계(712) - 상기 상황 정보는 상기 응용 프로그램의 상태에 관한 정보 및/또는 상기 모바일 송수신기(100)의 상태에 관한 정보를 포함함 -;
상기 기지국 송수신기(200)와 데이터 패킷들을 통신하는 단계(714) - 상기 데이터 패킷들은 페이로드 데이터 패킷들 및 제어 데이터 패킷들을 포함함 -;
상기 응용 프로그램과 연관되는 페이로드 데이터 패킷들을 상기 기지국 송수신기(200)를 통해 데이터 서버(300)와 통신하는 단계(715); 및
상기 상황 정보를 상기 기지국 송수신기(200)에 제공하는 단계(716) - 상기 상황 정보는 페이로드 데이터 패킷에 또는 제어 데이터 패킷에 포함됨 -
를 포함하는 방법.
모바일 통신 시스템(500)에서의 기지국 송수신기(200)에 대한 방법으로서 - 상기 모바일 통신 시스템(500)은 모바일 송수신기(100)를 더 포함함 -,
제어 데이터 패킷들 및 페이로드 데이터 패킷들을 수신하는 단계(722) - 상기 페이로드 데이터 패킷들은 상기 모바일 송수신기(100) 상에서 실행되는 응용 프로그램과 연관됨 -;
제어 데이터 패킷으로부터 또는 페이로드 데이터 패킷으로부터 상기 응용 프로그램과 연관되는 상기 데이터 패킷들에 관한 상황 정보를 획득하는 단계(724); 및
상기 상황 정보에 기초하여 상기 데이터 패킷들의 전송에 대해 상기 모바일 송수신기(100)를 스케줄링하는 단계(726)
를 포함하는 방법.
데이터 서버(300)에 대한 방법으로서 - 상기 데이터 서버(300)는 모바일 송수신기(100) 상에서 실행되는 응용 프로그램과 연관되는 데이터 패킷들을 모바일 통신 시스템(500)을 통해 상기 모바일 송수신기(100)로 전달함 -,
기지국 송수신기(200)로부터 수신된 분류 정보에 기초하여 상기 데이터 패킷들에 대한 상황 정보를 도출하는 단계(732); 및
상기 데이터 패킷들과 함께 상기 상황 정보를 상기 모바일 통신 시스템(500)으로 송신하는 단계(734)
를 포함하는 방법.
제1항의 장치(10)를 포함하는 모바일 송수신기(100), 제4항의 장치(20)를 포함하는 기지국 송수신기(200), 제8항의 장치(30)를 포함하는 데이터 서버(300), 및/또는 상기 모바일 송수신기(100), 상기 기지국 송수신기(200) 및/또는 상기 데이터 서버(300)를 포함하는 모바일 통신 시스템(500).
컴퓨터 또는 프로세서 상에서 실행될 때, 제12항 내지 제14항 중 어느 한 항의 방법을 수행하기 위한 프로그램 코드를 갖는 컴퓨터 프로그램.