KR102198701B1 - 멀티미디어 시스템에서 정보를 송수신하는 방법 및 장치 - Google Patents

멀티미디어 시스템에서 정보를 송수신하는 방법 및 장치 Download PDF

Info

Publication number
KR102198701B1
KR102198701B1 KR1020140083199A KR20140083199A KR102198701B1 KR 102198701 B1 KR102198701 B1 KR 102198701B1 KR 1020140083199 A KR1020140083199 A KR 1020140083199A KR 20140083199 A KR20140083199 A KR 20140083199A KR 102198701 B1 KR102198701 B1 KR 102198701B1
Authority
KR
South Korea
Prior art keywords
packet
information
message
arq
receiving entity
Prior art date
Application number
KR1020140083199A
Other languages
English (en)
Other versions
KR20160004628A (ko
Inventor
소영완
박경모
Original Assignee
삼성전자주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 삼성전자주식회사 filed Critical 삼성전자주식회사
Priority to KR1020140083199A priority Critical patent/KR102198701B1/ko
Priority to JP2017500081A priority patent/JP6628785B2/ja
Priority to PCT/KR2015/006873 priority patent/WO2016003234A1/ko
Priority to CN201580047294.6A priority patent/CN106664440B/zh
Priority to US15/323,612 priority patent/US10498492B2/en
Publication of KR20160004628A publication Critical patent/KR20160004628A/ko
Application granted granted Critical
Publication of KR102198701B1 publication Critical patent/KR102198701B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/08—Arrangements for detecting or preventing errors in the information received by repeating transmission, e.g. Verdan system
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/442—Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
    • H04N21/44209—Monitoring of downstream path of the transmission network originating from a server, e.g. bandwidth variations of a wireless network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607—Details of the supervisory signal
    • H04L1/1671—Details of the supervisory signal the supervisory signal being transmitted together with control information
    • H04L1/1678—Details of the supervisory signal the supervisory signal being transmitted together with control information where the control information is for timing, e.g. time stamps
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1829—Arrangements specially adapted for the receiver end
    • H04L1/1864—ARQ related signaling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867—Arrangements specially adapted for the transmitter end
    • H04L1/188—Time-out mechanisms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867—Arrangements specially adapted for the transmitter end
    • H04L1/1896—ARQ related signaling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/637—Control signals issued by the client directed to the server or network components
    • H04N21/6375—Control signals issued by the client directed to the server or network components for requesting retransmission, e.g. of data packets lost or corrupted during transmission from server
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/65—Transmission of management data between client and server
    • H04N21/658—Transmission by the client directed to the server
    • H04N21/6582—Data stored in the client, e.g. viewing habits, hardware capabilities, credit card number

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Multimedia (AREA)
  • Databases & Information Systems (AREA)
  • Communication Control (AREA)
  • Detection And Prevention Of Errors In Transmission (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

본 발명의 실시 예에 따른 송신 엔터티에 의해 패킷을 전송하는 방법은, 상기 송신 엔터티가 전송된 패킷을 재전송하기 위해 저장하는 시간 윈도우에 관한 정보를 포함하는 자동 반복 요청 (automatic repeat request : ARQ) 구성 정보를 생성하는 과정; 상기 ARQ 구성 정보를 포함하는 ARQ 구성 (ARQ configuration : AC) 메시지를 수신 엔터티로 전송하는 과정; 상기 전송된 패킷 중 손실 패킷에 관한 정보, ARQ 모드에 관한 정보 및 상기 수신 엔터티가 상기 손실 패킷을 요청할 때 이용하는 논의 타입 (argument type)에 관한 정보를 포함하는 ARQ 피드백 (ARQ feedback : AF) 메시지를 상기 수신 엔터티로부터 수신하는 과정; 상기 AF 메시지를 기반으로 손실 패킷을 재전송할 지의 여부를 결정하는 과정; 및 상기 결정을 기반으로 상기 손실 패킷을 상기 수신 엔터티로 재전송하는 과정을 포함하고, 상기 논의 타입에 관한 정보는, 상기 수신 엔터티가 패킷 카운터 (packet counter) 필드를 가지는 상기 AF 메시지를 전송함을 지시하는 값과, 상기 수신 엔터티가 패킷 아이디 (packet ID) 필드 및 패킷 시퀀스 넘버 (packet sequence number) 필드를 가지는 상기 AF 메시지를 전송함을 지시하는 값 중 하나를 포함함을 특징으로 한다.

Description

멀티미디어 시스템에서 정보를 송수신하는 방법 및 장치{METHOD AND APPARATUS FOR TRANSMITTING AND RECEIVING INFORMATION IN A MULTIMEDIA SYSTEM}
본 발명은 멀티미디어 시스템에서 정보를 송수신하는 방법 및 장치에 관한 것이다.
멀티미디어 시스템에서 정보를 전송하는 기술 중 하나인 MPEG(Moving Picture Experts Group) MMT(MPEG Media Transport: 이하 MMT) 기술에서는 ARQ (Automatic Repeat reQest)기법을 이용하여 정보를 송수신한다.
종래 MMT 시스템의 ARQ 기법에서 송신측(Sending Entity)은 어셋(Asset) 별로 ARQ를 지원하는 지 여부를 구분하여 수신측(Receiving Entit)으로 알리지 않는다. 이 경우 수신측은 손실된 패킷들을 재요청했을 시 회신 받을 수 있는지 여부를 알 수 없거나, 원활한 서비스를 위한다면 송신측(Sending Entity) 혹은 ARQ 서버는 자신이 가진 모든 Asset들에 대한 MMT 패킷(Packet)들을 일정 시간 이상 보관해 두어야만 하는 문제가 발생한다.
그리고 송신측에서 ARQ 요청을 할 때 MMT ARQ 메시지로는 Packet_ID와 PACKET_SEQUENCE_NUM 조합 한가지만으로 재전송 요청이 가능하며 이는 Packet단위로만 재전송 요청이 가능함을 의미한다. 하지만, MMT 시스템에서는 MMT Packet 뿐만 아니라, MPU(Media Processing Unit), MFU(Media Fragment Unit), 샘플(Sample) 등의 다양한 레벨의 미디어 단위가 존재하며, 수신측이 원하는 레벨의 미디어 단위를 요청할 수 있을 경우 더 유용한 데이터 복구가 가능할 수 있다.
도 1은 종래 MMT 시스템에서 ARQ 기법을 적용하는 일 예를 보이고 있다.
도 1과 같이 수신측에서 Arrival_Deadline이라는 값을 계산하고, 이를　송신측에 알려주어 ARQ 응답 메시지가 Arrival_Deadline 안에 최종 수신측까지 전달이 되지 않을 경우 서버가 응답 전송 자체를 포기하게 하는 방식있다. 하지만, Arrival_Deadline은 수신측에서 모든 수신 패킷을 열어보고 미디어를 복구해야 알 수 있는 값을 가정하므로, 수신측 측에서는 이 값 하나만을 도출하기 위해 많은 시간과 부담이 소비되는 문제가 있다. 또한, 서버가 응답을 포기하는 경우, 수신측에서는 이에 대한 인지를 하지 못하고, Arrival_Deadline이 올 때까지 그냥 기다리기만 해야 하는 문제가 있다.
따라서, 종래 MMT 시스템에서는 각 asset들의 개별 전송 특성 값(Asset Delivery Characteristic : ADC) 정보의 유효기간 정보가 제공되지 않으므로 이를 해결하기 위한 방안이 요구된다.
한편,　특정 송신측에서 수신측으로 전송되는 MMT 미디어 데이터는 하나의 Asset만 전송되고 끝나는 것이 아니라 서로 연관성이 높은 Asset들의 조합된 묶음 단위로 전송되는 경우가 많게 된다. 따라서 네트워크에서도 Asset단위의 제어 및 관리가 아니라 번들 단위의 전송 특성 (Bundle Delivery Characteristics : BDC) 정보를 좀 더 용이한 관리가 이루어질 수 있다. 하지만 종래 MMT 시스템에서 ADC는 각 개별 미디어인 Asset 단위로 제공되었으며 이 경우 ADC 정보의 발견 및 관리가 Asset 단위로 제공되므로 서버/MANE (MMT Aware Network Entity) 입장에서는 필요이상의 정보가 제공되는 경우가 발생할 수 있다. 또한 각 개별 패킷 레벨에서 전송하고자 하는 데이터의 중요도와 우선 순위 정보를 제공하는 수단은 있으나, 유의미한 관련성을 가지는 미디어 레벨에서의 Asset들의 묶음 정보인 번들(Bundle) 정보 뿐만 아니라 번들대 번들, 번들 내 Asset과 Asset 사이의 상대적인 우선순위 정보는 주어지지 않았다.
본 발명은 멀티미디어 시스템에서 정보를 송수신하는 방법 및 장치를 제공한다.
또한 본 발명은 멀티미디어 시스템에서 ARQ를 적용하여 정보를 송수신하는 방법 및 장치를 제공한다.
또한 본 발명은 멀티미디어 시스템에서 asset들의 그룹인 번들을 구성하고, 각 번들의 전송 특성 정보를 구성하여 정보를 송수신하는 방법 및 장치를 제공한다.
본 발명의 실시 예에 따른 송신 엔터티에 의해 패킷을 전송하는 방법은, 상기 송신 엔터티가 전송된 패킷을 재전송하기 위해 저장하는 시간 윈도우에 관한 정보를 포함하는 자동 반복 요청 (automatic repeat request : ARQ) 구성 정보를 생성하는 과정; 상기 ARQ 구성 정보를 포함하는 ARQ 구성 (ARQ configuration : AC) 메시지를 수신 엔터티로 전송하는 과정; 상기 전송된 패킷 중 손실 패킷에 관한 정보, ARQ 모드에 관한 정보 및 상기 수신 엔터티가 상기 손실 패킷을 요청할 때 이용하는 논의 타입 (argument type)에 관한 정보를 포함하는 ARQ 피드백 (ARQ feedback : AF) 메시지를 상기 수신 엔터티로부터 수신하는 과정; 상기 AF 메시지를 기반으로 손실 패킷을 재전송할 지의 여부를 결정하는 과정; 및 상기 결정을 기반으로 상기 손실 패킷을 상기 수신 엔터티로 재전송하는 과정을 포함하고, 상기 논의 타입에 관한 정보는, 상기 수신 엔터티가 패킷 카운터 (packet counter) 필드를 가지는 상기 AF 메시지를 전송함을 지시하는 값과, 상기 수신 엔터티가 패킷 아이디 (packet ID) 필드 및 패킷 시퀀스 넘버 (packet sequence number) 필드를 가지는 상기 AF 메시지를 전송함을 지시하는 값 중 하나를 포함함을 특징으로 한다.
또한 본 발명의 실시 예에 따른 수신 엔터티에 의해 패킷을 수신하는 방법은, 자동 반복 요청 (automatic repeat request : ARQ) 구성 정보를 포함하는 ARQ 구성 (ARQ configuration : AC) 메시지를 수신하는 과정, 여기서, 상기 ARQ 구성 정보는 송신 엔터티가 전송된 패킷을 재전송을 위해 저장하는 시간 윈도우에 관한 정보를 포함함; 상기 전송된 패킷 중 손실 패킷에 관한 정보 및 ARQ 모드에 관한 정보를 생성하는 과정; 상기 전송된 패킷 중 상기 손실 패킷에 관한 정보, 상기 ARQ 모드에 관한 정보 및 상기 수신 엔터티가 상기 손실 패킷을 요청할 때 이용하는 논의 타입 (argument type)에 관한 정보를 포함하는 ARQ 피드백 (ARQ feedback : AF) 메시지를 전송하는 과정; 및 상기 손실 패킷의 재전송이 상기 AF 메시지를 기반으로 결정되면, 상기 손실 패킷을 수신하는 과정을 포함하고, 상기 논의 타입에 관한 정보는, 상기 수신 엔터티가 패킷 카운터 (packet counter) 필드를 가지는 AF 메시지를 전송함을 지시하는 값과, 상기 수신 엔터티가 패킷 아이디 (packet ID) 필드 및 패킷 시퀀스 넘버 (packet sequence number) 필드를 가지는 AF 메시지를 전송함을 지시하는 값 중 하나를 포함함을 특징으로 한다.
또한 본 발명의 실시 예에 따른 패킷을 전송하는 송신 엔터티는, 데이터를 송수신하는 송수신부; 및 상기 송신 엔터티가 전송된 패킷을 재전송하기 위해 저장하는 시간 윈도우에 관한 정보를 포함하는 자동 반복 요청 (automatic repeat request : ARQ) 구성 정보를 생성하고, 상기 ARQ 구성 정보를 포함하는 ARQ 구성 (ARQ configuration : AC) 메시지를 수신 엔터티로 전송하고, 상기 전송된 패킷 중 손실 패킷에 관한 정보, ARQ 모드에 관한 정보 및 상기 수신 엔터티가 상기 손실 패킷을 요청할 때 이용하는 논의 타입 (argument type)에 관한 정보를 포함하는 ARQ 피드백 (ARQ feedback : AF) 메시지를 상기 수신 엔터티로부터 수신하고, 상기 AF 메시지를 기반으로 손실 패킷을 재전송할 지의 여부를 결정하고, 상기 결정을 기반으로 상기 손실 패킷을 상기 수신 엔터티로 재전송하도록 제어하는 제어부를 포함하며, 상기 논의 타입에 관한 정보는, 상기 수신 엔터티가 패킷 카운터 (packet counter) 필드를 가지는 AF 메시지를 전송함을 지시하는 값과, 상기 수신 엔터티가 패킷 아이디 (packet ID) 필드 및 패킷 시퀀스 넘버 (packet sequence number) 필드를 가지는 AF 메시지를 전송함을 지시하는 값 중 하나를 포함함을 특징으로 한다.
또한 본 발명의 실시 예에 따른 패킷을 수신하는 수신 엔터티는, 데이터를 송수신하는 송수신부; 및 자동 반복 요청 (automatic repeat request : ARQ) 구성 정보를 포함하는 ARQ 구성 (ARQ configuration : AC) 메시지를 수신하고, 상기 ARQ 구성 정보는 송신 엔터티가 전송된 패킷을 재전송을 위해 저장하는 시간 윈도우에 관한 정보를 포함함, 상기 전송된 패킷 중 손실 패킷에 관한 정보 및 ARQ 모드에 관한 정보를 생성하고, 상기 전송된 패킷 중 상기 손실 패킷에 관한 정보, 상기 ARQ 모드에 관한 정보 및 상기 수신 엔터티가 상기 손실 패킷을 요청할 때 이용하는 논의 타입 (argument type)에 관한 정보를 포함하는 ARQ 피드백 (ARQ feedback : AF) 메시지를 전송하고, 상기 손실 패킷의 재전송이 상기 AF 메시지를 기반으로 결정되면, 상기 손실 패킷을 수신하도록 제어하는 제어부를 포함하며, 상기 논의 타입에 관한 정보는, 상기 수신 엔터티가 패킷 카운터 (packet counter) 필드를 가지는 AF 메시지를 전송함을 지시하는 값과, 상기 수신 엔터티가 패킷 아이디 (packet ID) 필드 및 패킷 시퀀스 넘버 (packet sequence number) 필드를 가지는 AF 메시지를 전송함을 지시하는 값 중 하나를 포함함을 특징으로 한다.
본 발명은 MMT 시스템에서 시간 제한 환경에서 ARQ를 적용하는 방법에 있어서, Asset 별로 ARQ를 사용할 수 있는지 여부와 ARQ 서버의 주소를 명시적으로 수신측에게 구분하여 지시하고, ARQ 요청을 할 때 수신측이 인자를 유연하게 사용 가능하게 하고, 재전송 요청을 보낼지 여부 혹은 재전송 응답을 보낼지 여부를 좀더 쉽게 결정할 수 있게 함으로써 MMT 환경에서 지연(delay constrained) ARQ 동작의 구현을 쉽게 할 수 있다.
또한 본 발명은 특정 플로우에 따른 여러 Asset의 ADC 값들을 일일히 추출해서 전체 플로우의 각 과정을 수행해야 하는 과정을 수행하지 않을 수 있고, 서비스 제공자 혹은 패킷 생성자의 의도에 따라 의미있는 단위로 제공되어진 번들 단위로 전송을 관리 함으로써 MANE나 수신측이 임의의 패킷 전송을 줄여야 할 때 그 우선 순위를 알 수 있고, 네트워크 혼잡 상황에서 미디어 적응적 전송이 필요한 경우 모든 Asset들에 일률적으로 특정 프레임을 중지(drop)하는 방식으로 적응적 전송을 수행하는 것이 아니라, 중요한 특정 Asset을 아예 선별적으로 통째로 전송하지 않음으로써 더 다양한 의미에서의 적응적 전송이 가능하다.
한편 그 외의 다양한 효과는 후술될 본 발명의 실시 예에 따른 상세한 설명에서 직접적 또는 암시적으로 개시될 것이다.
도 1은 종래 MMT 시스템에서 ARQ 기법을 적용하는 일 예를 나타낸 도면.
도 2는 본 발명의 실시 예에 따른 MMT 시스템에서 각 노드의 구성을 나타낸 도면.
도 3은 본 발명의 제1 실시 예에 따른 정보 송수신 방법을 나타낸 도면.
도 4는 본 발명의 제2 실시 예에 따른 정보 송수신 방법을 나타낸 도면.
도 5는 본 발명의 제3 실시 예에 따른 정보 송수신 방법을 나타낸 도면.
도 6은 본 발명의 제4 실시 예에 따른 정보 송수신 방법을 나타낸 도면.
도 7은 본 발명의 제5 실시 예에 따른 정보 송수신 방법을 나타낸 도면.
도 8은 본 발명의 제6 실시 예에 따른 정보 송수신 방법을 나타낸 도면.
도 9는 현재 MMT 규격에서의 ADC의 구성을 나타낸 도면.
도 10은 본 발명의 다른 실시 예에 따른 BDC의 구성을 나타낸 도면.
도 11은 본 발명의 다른 실시 예에 따른 MMT 시스템에서 각 노드의 구성을 나타낸 도면.
도 12는 본 발명의 다른 실시 예에 따른 BDC를 이용한 서버의 동작에 대한 일 예를 나타낸 도면.
이하, 본 발명에 따른 바람직한 실시 예를 첨부한 도면을 참조하여 상세히 설명한다. 하기의 설명에서는 본 발명에 따른 동작을 이해하는데 필요한 부분만이 설명되며 그 이외 부분의 설명은 본 발명의 요지를 흩트리지 않도록 생략될 것이라는 것을 유의하여야 한다.
본 발명의 주요한 요지는 MMT 시스템에서 전송 중 손실된 패킷을 delay-constrained 환경에서 제한된 시간 안에 재전송 받기 위한 장치와 방법을 제공하기 위한 것이다. 더욱 상세하게 본 발명은 (1) Asset 별로 ARQ를 사용할 수 있는지 여부와 ARQ 서버의 주소를 명시적으로 MMT receiving entity에게 구분하여 지시하고, (2) ARQ 요청을 할 때 MMT receiving entity가 어떤 인자를 이용해 요청할 수 있는지 여부를 구분하여 지시하고, (3) Delay-Constrained ARQ 요청을 하는 경우, 클라이언트가 ARQ 요청 메시지를 보낼지의 여부를 수신측 버퍼 관리를 위한 메시지인 HRBM 메시지의 fixed_end_to_end_delay 혹은 max_end_to_end_delay를 근거로 하여 RTT (Round Trip Time)와 비교 후 결정하고 (4) Delay-Constrained ARQ 요청을 하는 경우, ARQ 서버가 ARQ 요청에 대한 응답 메시지 (요청된 MMT 패킷)를 보낼지의 여부를 수신측 버퍼 관리를 위한 메시지인 HRBM 메시지의 fixed_end_to_end_delay 혹은 max_end_to_end_delay를 근거로 하여 측정된 RTT (Round Trip Time)와 비교 후 결정하는 장치와 방법에 관한 것이다.
이를 위해 본 발명의 실시 예에 따른 멀티미디어 시스템에서 정보를 송수신하는 방법 및 장치에 대하여 상세히 설명하기로 한다. 이하, 멀티미디어 시스템은 일 예로, MMT 시스템임을 가정하여 설명하기로 한다.
먼저, 본 발명의 실시 예에 따른 MMT 시스템에서 ARQ 적용 여부 및 인자 사용 방법에 대하여 설명하기로 한다.
MMT ARQ에서는 MMT receiving Entity의 ARQ 동작 셋팅을 하기 위해 AC(ARQ Configuration) 메시지를 사용한다. 본 발명의 실시 예에서 AC 메시지를 적용하기 위하여 하기에 설명된 파라메터 값들이 더 추가되어야 한다.
1) ARQ_support_flag은 해당 Asset 별로(packet_id) ARQ를 사용할 수 있는지 여부를 나타내는 플래그로, 1로 셋팅된 경우 MMT receiving entity는 해당 packet_id에 속하는 패킷의 손실이 있을 경우 ARQ 서버로부터 해당 packet을 제공받을 수 있음을 나타낸다. 대안으로, ARQ_support_flag을 넣지 않고 rtx_window_timeout=0　으로 셋팅하는 경우 해당 Asset은 패킷 재전송을 지원하지 않음을 의미한다.
2) arq_server_address은 AF 메시지를 보냈을때 패킷 재전송을 받을 수 있는 ARQ 서버의 주소를 의미한다.
3) arq_type 은 MMT receiving entity가 AF 메시지를 보낼 때 어떤 타입의 요청 메시지를 보낼 수 있는지를 나타낸다. <표 3>로부터 '00'인경우 MMT packet header의 packet_counter를 이용해 재전송 받고자 하는 패킷을 지시할 수 있으며, '01'인경우 MMT packet header의 packet_id 와 packet_sequence_number의 조합으로 재전송 받고자 하는 패킷을 지시할 수 있다.
아래 <표 1>은 본 발명의 실시 예에 따른 AC 메시지 정보를 나타낸 표이다.
<표 1>
Figure 112014062948480-pat00001
상기 <표 1>에서 각 구문(syntax)는 아래 <표 2>와 같은 의미를 갖는다.
<표 2>
Figure 112014062948480-pat00002
<표 3>
Figure 112014062948480-pat00003
　다음으로, MMT ARQ에서는 MMT receiving Entity가 패킷 재전송이 필요한 경우 AF (ARQ Feedback) 메시지를 구성하여 ARQ 서버에 전송한다. 이때, 본 발명의 실시 예에 따라 <표 4>와 같이 AP 메시지는 재구성되어야 한다.
<표 4>
Figure 112014062948480-pat00004
상기 <표 4>에서 각 구문(syntax)는 아래 <표 5>와 같은 의미를 갖는다.
<표 5>
Figure 112014062948480-pat00005
Figure 112014062948480-pat00006
<표 6>
Figure 112014062948480-pat00007
<표 7>
Figure 112014062948480-pat00008
도 2는 본 발명의 실시 예에 따른 MMT 시스템에서 각 노드의 구성을 보이고 있다.
도 2를 참조하면, MMT Packet 전송 노드인 MMT Sending Entity(210), MMT Packet 수신 노드인 MMT Receiving Entity(250) 및 패킷 재전송이 있을 경우 이를 저장하는 MMT ARQ Server(230)를 포함한다. 이때 MMT Sending Entity(210)는 MMT ARQ Server(230)의 기능을 가질수도 있다.
MMT Sending Entity(210)에 포함된 MMT패킷 생성 및 저장부(213)는 Asset을 MMT 패킷화 하는 모듈이이고, HRBM 정보 저장/관리부(211)는 수신측 버퍼 관리를 위한 HRBM 정보를 생성하고 저장하고 전달하는 모듈이며, MMT 패킷 송신부(215)는 생성된 MMT 패킷을 전송하는 모듈이다.　
MMT ARQ Server(230)에 포함된 채널 상태 측정부(231)는 패킷 재전송 요청이 올 경우 재전송된 패킷이 의미있는 시간안에 수신측에 제대로 전달될 수 있는지 여부를 결정하기 위해 MMT Receiving Entity와의 Round Trip Time을 측정하기 위한 모듈이다. 그리고 MMT 패킷 저장부(233)는 MMT Receiving Entity로부터 재전송 요청오는 패킷을 전달해주기 위해 해당 패킷들을 미리 전달받아 복사/저장해두는 모듈이다. MMT 패킷 재전송 결정부(237)는 ARQ 요청 (AF)이 왔을 때 재전송된 패킷이 의미있는 시간 안에 수신측에 제대로 전달될 수 있는지 여부를 결정하기 위한 모듈로, HRBM 정보의 max_end_to_end_delay 혹은 fixed_end_to_end_delay 정보를 MMT Receiving Entity와 사이의 RTT를 비교하여 결정하는 것을 특징으로 하는 모듈이다. 그리고 MMT 패킷 송신부(241)는 생성된 MMT 패킷을 전송하는 모듈이며, AC 설정부(239)는 ARQ 설정 정보를 생성/저장/전송하는 모듈이다.
MMT Receiving Entity(250)에 포함된 채널 상태 측정부(251)는 패킷 재전송 요청이 올 경우 재전송된 패킷이 의미있는 시간안에 제대로 수신될 수 있는지 여부를 결정하기 위해 MMT ARQ Server와의 Round Trip Time을 측정하기 위한 모듈이다. 그리고 MMT 패킷 재전송 요청부(255)는 손실된 패킷이 감지되는 경우, ARQ 요청을 보내기 위한 모듈로, HRBM 정보의 max_end_to_end_delay 혹은 fixed_end_to_end_delay 정보를 MMT Receiving Entity와 사이의 RTT를 비교하여 재전송된 패킷이 의미있는 시간 안에 수신측에 제대로 전달될 수 있는지 여부를 파악하여 필요한 경우 재전송 요청 메시지 자체를 보낼지의 여부를 결정하는 것을 특징으로 하는 모듈이다. AC 수신부(257)는 ARQ 설정 정보를 수신/저장 하는 모듈이고, MMT 패킷 수신부(261)는 전송된 MMT 패킷을 수신하는 모듈이다. MMT 패킷 손실 검출부(259)는 전송된 MMT 패킷들의 손실/수신 여부를 검출하는 모듈이고, HRBM 정보 저장/관리부(253)는 수신측 버퍼 관리를 위한 HRBM 정보를 수신 저장하는 모듈이다.
도 3은 본 발명의 제1 실시 예에 따른 정보 송수신 방법을 보이고 있다.
도 3을 참조하면, 본 발명의 제1 실시 예는 재전송 요청 여부를 클라이언트가 결정하는 경우(Client-centric case)에 대한 것이다.
Delay-constrained ARQ 환경에서, 일단 재전송 요청을 무조건 하고 응답할지 여부를 MMT Sending Entity(이하 서버)가 결정하도록 하는 것이 아니라, HRBM과 RTT정보를 MMT Receiving Entity(이하 클라이언트)가 비교하여 제한된 시간 안에 수신이 안될 것으로 판단되는 경우, 클라이언트가 아예 재전송 요청 자체를 안 보내도록 할 수 있다. HRBM 메시지 내의 max_end_to_end_delay 혹은 fixed_end_to_end_delay 정보를 이용하여 판단하는 경우, 클라이언트에서 모든 수신 패킷을 열어 보고 미디어를 복구해 볼 필요가 없으므로, 많은 시간과 부담이 소비되는 문제가 없어진다. 또한, 재전송 요청 판단 자체를 클라이언트가 하므로, 응답이 제대로 오면 문제가 없으나 만일 응답이 오지 않을 경우 클라이언트에서는 마냥 기다려야 하는 문제가 없어지게 된다.
MMT receiving entity가 서버에게 AF 메시지를 통해 손실된 패킷에 대해 재전송 요청이 필요한 경우, MMT receiving entity는 수신된 HRBM의　fixed _ end _ to _ end _ delay　값과 RTT (Round-Trip-Time)　값을　비교해야 한다. 만일 fixed _ end _ to _ end _ delay 　값이 RTT　값보다 큰 경우, 패킷 재전송을 하는 경우 재전송된 패킷이 제한된 시간 안에 안전하게 수신될 수 있음을 의미하므로 MMT receiving entity는 패킷 재전송을 요청하고, 만일 fixed_end_to_end_delay　값이 RTT　값보다 작은 경우, 패킷 재전송을 해도 수신된 패킷이 제한된 시간 안에 안전하게 수신될 수 없음을 의미하므로 MMT receiving entity는 패킷 재전송 요청 자체를 하지 않는다.
도 4는 본 발명의 제2 실시 예에 따른 정보 송수신 방법을 보이고 있다.
도 4을 참조하면, 본 발명의 제2실시 예는 RQF 메시지를 이용하여 RTT 값을 측정해두는 경우(Server-centric case)에 대한 것이다.
Delay-constrained ARQ 환경에서, 서버는 HRBM 메시지 내의 max_end_to_end_delay과 fixed_end_to_end_delay 값을 미리 알고 있으므로, ARQ 요청이 왔을 때 재전송 응답할지 여부를 도출이 어려운 arrival_deadline과 RTT를 비교하는 것이 아니라, max_end_to_end_delay 혹은 fixed_end_to_end_delay과 RTT 값을 비교하여, 재전송 여부를 결정할 수 있다. fixed_end_to_end_delay　>　RTT 인 경우, 클라이언트에 제한된 시간 안에 재전송 패킷이 전달될 수 있음을 의미하므로 응답 패킷을 전송하고, fixed_end_to_end_delay <　RTT 인 경우, 제한된 시간 안에 패킷이 도착하지 못함을 의미하므로 수신측의 de-jittering 버퍼에서는 수신된 패킷을 폐기하므로 재전송 패킷을 보내도 의미가 없다. 따라서 이 경우 서버는 재전송을 아예 하지 않도록 한다.
　이 경우, 최신의 RTT 값을 서버가 알고 유지하게 하기 위해서 RQF 메세지의 사용이 가능하다. MMT에서는 MC 메시지를 통해 클라이언트가 서버에게 채널 상태 등의 다양한 정보들을 서버에게 보내도록 할 수 있는데, 이는 MC(Measurement Configuration) 메시지를 통해 어떤 정보들을 리포트할지를 설정하고, 해당 정보는 RQF 메시지를 통해 클라이언트로부터 서버로 전달된다.
Delay-constrained ARQ 시 서버가 재전송 여부를 판단하게 하기 위해 최신의 RTT 정보를 서버가 알아야 하며, 그 방법의 하나로 MC 메시지 내에, 클라이언트가 Delay-constrained ARQ를 할 예정인 경우 서버에게 RQF 전송을 하도록 MC 메시지 내 measurement_condition()에 조건을 부여할 수 있다. 현재까지 measurement_condition()에 Delay-constrained ARQ 시 RQF 메시지를 보내도록 하는 조건은 없었으므로 이에 대한 추가가 필요하다. 예를들면, "measurement_condition() = 0x0001"으로 MC 메시지에 지정해두면 클라이언트는 Delay-constrained ARQ 메시지를 보냄과 동시에 서버가 최신 RTT를 알 수 있게 RQF 메시지를 보내야 한다.
도 5는 본 발명의 제3 실시 예에 따른 정보 송수신 방법을 보이고 있다.
도 5를 참조하면, 본 발명의 제3 실시 예는 AF 메시지 내에 측정된 최신 RTT 값을 삽입해 보내는 경우(Server-centric case)에 대한 것이다.
최신의 RTT 값을 서버가 알고 유지하게 하기 위해서 AF 메세지 자체의 사용이 가능하다. MMT에서는 클라이언트가 AF 메시지에 서버에게 어떤 패킷을 재전송 요청하는지를 지정하여 보내게 된다. 이 때, Delay-constrained ARQ 시 서버가 재전송 여부를 판단하게 하기 위해 최신의 RTT 정보를 서버가 알아야 하며, 그 방법의 하나로 AF 메시지 내에, 서버로부터 클라이언트로의 전송 딜레이인 Propagation Delay값(그림5의 D1)의 최신 버젼을 삽입하여 전송할 수 있다. 클라이언트는 서버로부터 수신되는 다른 패킷들의 패킷헤더 내 timestamp값 등을 이용하여 D1값을 업데이트 해두었다가 이를 AF메시지 안에 첨부하여 보낼 수 있다. 서버는 AF 메시지가 실린 패킷 헤더의 timestamp 값을 이용해 Uplink 방향의 딜레이 값(도 5의 D2)을 계산할 수 있으며, D1+D2 를 합하여 가장 최신의 RTT값을 계산하고 이를 HRBM 메시지 내의 max_end_to_end_delay과 fixed_end_to_end_delay와 비교하여 재전송 여부를 결정할 수 있다. (FEC가 적용된 경우 RTT와 max_end_to_end_delay를 비교하고, FEC가 적용되지 않은 경우 fixed_end_to_end_delay값과 RTT를 비교한다.)
MMT sending entity가 MMT receiving entity로부터 AF 메시지를 통해 손실된 패킷에 대해 재전송 요청을 받았을 때, MMT sending entity는 HRBM의　fixed _ end _ to _ end _ delay　값과 RTT (Round-Trip-Time)　값을 비교해야 한다. 만일 fixed _ end _ to _ end _ delay 　값이 RTT　값보다 큰 경우, 패킷 재전송을 하는 경우 재전송된 패킷이 제한된 시간 안에 안전하게 수신될 수 있음을 의미하므로 MMT sending entity는 요청된 패킷을 재전송 하고, 만일 fixed_end_to_end_delay　값이 RTT　값보다 작은 경우, 패킷 재전송을 해도 재전송된 패킷이 제한된 시간 안에 안전하게 수신될 수 없음을 의미하므로 MMT sending entity는 요청된 패킷을 재전송 하지 않는다.
도 6은 본 발명의 제4 실시 예에 따른 정보 송수신 방법을 보이고 있다.
도 6을 참조하면, 본 발명의 제4 실시 예는 최신 RTT값 알기위해 주기적 RQF 전송 설정하는 경우(Server-centric case)에 대한 것이다.
최신의 RTT 값을 서버가 알고 유지하게 하기 위해서 RQF를 클라이언트가 반복적으로 보내도록 하는 방법도 가능하다. Delay-constrained ARQ 시 서버가 재전송 응답 여부를 판단하게 하기 위해 최신의 RTT 정보를 서버가 알아야 하며, 서버가 특정 Asset의 경우 실시간성이 중요해 Delay-constrained ARQ가 필수라고 판단되는 경우 MC 메시지 내에, measurement_period값에 주기값을 셋팅해서 클라이언트가 주기적으로 RQF 메시지를 보내도록 할 수 있다.
클라이언트는 서버로부터 수신되는 다른 패킷들의 패킷헤더 내 timestamp값 등을 이용하여 D1값을 업데이트 해두었다가 이를 RQF 메시지 안의 propagation_delay 값으로 하고 서버에게 주기적으로 전송한다. 서버는 RQF 메시지가 실린 패킷 헤더의 timestamp 값을 이용해 Uplink 방향의 딜레이 값 (도 6의 D2)을 계산할 수 있으며, D1+D2 를 합하여 가장 최신의 RTT값을 계산하고 이를 HRBM 메시지 내의 max_end_to_end_delay과 fixed_end_to_end_delay와 비교하여 재전송 여부를 결정할 수 있다.
도 7은 본 발명의 제5 실시 예에 따른 정보 송수신 방법을 보이고 있다.
도 7을 참조하면, 본 발명의 제5 실시 예는 별도의 ARQ 서버가 존재하는 Server-centric case에 대한 것이다.
MMT에서 재전송을 위한 ARQ 서버가 MMT Sending Entity와는 물리적으로 별도의 디바이스에 존재할 수 있다. 별도 ARQ 서버가 존재하고 재전송 여부를 서버가 결정하는 경우 도 7과 같이, 1) MMTP 패킷이 ARQ 서버로 사전에 별도 복사 및 저장이 되어야 하며 2) HRBM 메시지의 max_end_to_end_delay, fixed_end_to_end_delay 값이 ARQ서버에 전달되어야 하며, 3) (AC 메시지 등을 통해) 별도의 ARQ 서버들의 주소를 클라이언트에게 알려주어여 하며, 4) ARQ 서버와 클라이언트 사이 RTT값이 서버-클라이언트와 다르므로 별도로 측정을 해둬야 한다.
별도 ARQ 서버의 주소는 <표1>에서와 같이 arq_server_address를　통해　지정이 가능하다. ARQ서버와 클라이언트 사이의 최신의 RTT 값을 서버가 알고 유지하게 하기 위해서는 추가 동작이 필요하다. 별도의 ARQ 서버가 존재하고 Server-centric(서버가 재전송여부를 결정)인 환경에서는, ARQ 서버가 자신이 서비스해야 할 MMT Sending Entity를 아직 모르는 상태이므로 먼저 자발적으로 MC/RQF 메시지 등을 통해 최신 RTT 리포트를 지시할 수 없다. 따라서, Sending Entity와 ARQ 서버 주소가 다르고 Delay Constrained ARQ를 요청 예정이고, ARQ서버-클라이언트 사이의 최신 D1 값으로 쓸만한 최근 PKT 수신이 없는 경우, 클라이언트는 최신 D1 측정을 위해 ARQ 서버에 임의의 패킷(D1 측정을 위한 것이므로 내용이 무엇인지는 중요하지 않음)을 전송해 줄 것을 요청할 수 있고, ARQ 서버가 서버가 보내준 MMT 패킷 헤더의 timestamp로부터 ARQ서버-클라이언트 사이의 최신 D1 값을 알고 난 후에는 이를 실시예 3에서와 마찬가지로 AF 메시지 내에 D1 값을 삽입하여 전송할 수 있다. 이 D1과 AF 메시지내 timestamp로 구한 D2 값을 근거로 ARQ 서버는 최신 RTT값을 유지할 수 있다. 또한 ARQ 서버는 Delay Constrained ARQ를 요청한 클라이언트를 알게 되었으므로 필요에 의해 MC 메시지를 통해 RRT 수신을 위한 요청을 원하는대로 조절 가능하다.
또한, 또 다른 방법으로, Sending Entity가 ARQ 서버 주소를 가르쳐 주고 그 주소가 Sending Entity 주소와 다른 경우, MMT receiving entity는 해당 ARQ 서버에 별도의 메시지를 통해 delay constrained ARQ 동작을 위한 registration을 취할 수 있고 ARQ 서버는 등록된 receiving entity 들에 대해 delay constrained ARQ 동작 가능성에 대비해 미리 RTT 시간 정보를 측정 해둔다.
도 8은 본 발명의 제6 실시 예에 따른 정보 송수신 방법을 보이고 있다.
도 8을 참조하면, 본 발명의 제6 실시 예는 별도의 ARQ 서버가 존재하는 Client-centric case에 대한 것이다.
별도 ARQ 서버가 존재하고 재전송 여부를 클라이언트가 결정하는 경우 도 8과 같이, ARQ 서버와 클라이언트 사이의 최신의 RTT 값을 클라이언트가 알고 유지하게 하기 위해서는 추가 동작이 필요하다.
별도의 ARQ 서버가 존재하고 Client-centric(클라이언트가 재전송여부를 결정)인 환경에서는, 클라이언트가 ARQ서버-클라이언트간 RTT값을 모르는 상황이므로, Uplink 전송 지연인 D2값을 알기 위해 AF를 통해 일반 데이터 패킷이 아니라 컨트롤 정보인 AC정보를 담고 있는 AC 메시지를 요청할 수 있게 하고 (아래 <표8> 및 <표9>), 해당 AC 메시지에는 ARQ 설정 정보 뿐만 아니라 ARQ 서버가 알고 있는 특정 클라이언트와 ARQ 서버 사이의 채널 정보인 최신의 D2값을 AC에 실어 전송하는 방법이 가능하게 할 수 있다(아래 <표 10>).
<표 8>
Figure 112014062948480-pat00009
<표 9>
Figure 112014062948480-pat00010
<표 10>
Figure 112014062948480-pat00011
한편, 본 발명의 다른 실시 예에서는 MMT 시스템에서, 한 Package를 구성하는 여러 Asset들 가운데 유의미한 관련성을 가지는 Asset들의 그룹인 번들을 구성하고, 각 Asset들의 ADC를 취합하여 각 번들들의 BDC 정보를 구성하고, 각 번들간의 상대적인 우선 순위 그리고 각 번들 내 Asset들 간의 상대적인 우선 순위 정보를 함께 추가 하여 서버 혹은 MANE가 임의의 Asset 전송을 멈추어야 할 시 어떤 것들을 선택할 수 있는지에 대한 힌트 정보를 주는 장치와 방법을 제공한다.
도 9는 현재 MMT 규격에서의 ADC의 구성을 보이고 있다.
ADC는 MPEG MMT 규격에서 Asset(ex. Video, Audio, Text, File 등)의 전송 특성을 나타내는 정보로 도 9 및 <표 11>과 같은 관계 및 형식(syntax and semantics)을 가진다. ADC 정보가 MANE나 MMT Receiving Entity에 전달되는 경우, 이 정보를 이용해 MANE는 향후 트래픽 전송의 추이와 특성 정보값을 미리 앎으로 해서 대역폭 절감의 효과를 얻을 수 있고, MMT Receiving Entity 역시 미디어가 어떤 전송 속도로 도착하는지 알 수 있기 때문에 어느 정도의 버퍼를 확보해야 하는지를 유추할 수 있는 등의 다양한 장점이 있게 된다.
<표 11>
Figure 112014062948480-pat00012
상기 <표 11>에서 각 구문(syntax)는 아래 <표 12>와 같은 의미를 갖는다.
<표 12>
Figure 112014062948480-pat00013
Figure 112014062948480-pat00014
<표 13>
Figure 112014062948480-pat00015
<표 14>
Figure 112014062948480-pat00016
<표 15>
Figure 112014062948480-pat00017
도 10은 본 발명의 다른 실시 예에 따른 BDC의 구성을 보이고 있다.
도 10을 참조하면, Base layer(Asset 3), Enhancement layer 1 (Asset 2), Enhancement layer 2 (Asset 1)로 이루어진 SVC(Scalable Video) 비디오 컨텐츠와 모노(Asset 4), 레프트(Asset 5), 라이트(Asset 6) 채널로 구성된 오디오 컨텐츠로 이루어진 MMT 컨텐츠를 가정하기로 한다. 사용자의 선호도, 네트워크 상황, 단말기의 용량(Capability) 등에 따라 다양한 조합의 Asset들이 MMT Receiving Entity에게 전송될 수 있다. 최고품질의 컨텐츠 전송을 위해서는 Asset1~Asset6번 까지 모든 Asset이 수신측에 전달되어야 하며 이 조합/구성이 하나의 번들(Bundle 1)을 이루게 된다.
네트워크 상황이 안 좋아지거나 사용자 프리미엄 사용자가 아닌 경우 저품질의 컨텐츠 정보 전송이 이루어지게 되며 도 10에서 Asset3과 Asset4만을 수신측에 전달함으로써(Bundle 3) 서비스가 가능하게 된다.
이와 같이 한 MMT 컨텐츠는 일반적으로 여러 개 Asset 들로 구성되며 특정 시간에 재생(플레이)되기 위하여 일련의 Asset들의 모음이 선택되어지게 된다. 이 때, 개별 Asset 단위가 아닌 의미있는 Asset 들의 묶음인 Bundle 단위로 전송 특성을 기술할 수 있다면, 네트워크 노드나 클라이언트에게 더 단순하고 효율적인 정보를 제공할 수도 있다. 따라서 본 발명에서는 Bundle의 개념을 도입하고 번들의 전송 특성 정보인 BDC를 기술하기 위한 Syntax와 Semantics를 <표 16>과 같이 정의하였다.
표 16은 Bundle Delivery Characteristics (BDC) Syntax 예제를 나타낸 것이다.
<표 16>
Figure 112014062948480-pat00018
<표 16>에서 MMT_package_id는 현재 BDC가 제공하는 정보들이 어떤 패키지 내의 번들들인지 해당 패키지의 ID를 의미한다. 한 패키지에는 여러 개 Asset들이 있을 수 있고, Asset들의 조합을 어떻게 하느냐에 따라 여러 개 번들이 만들어질(구성되어질) 수 있다. 이때 BDC는 MMT sending entity가 ADC를 보고 자체 생성할 수도 있고, Package Provider가 제공할 수 도 있다.
Element_Asset_id는 현재 BDC를 구성하고 있는 Asset ID로 BDC는 현재 번들이 어떤 Asset들로 구성되어 있는지 번들별로 해당 번들을 구성하고 있는 Asset들의 ID 리스트 정보를 담게 된다.
Bundle_id는 한 패키지 내에서 번들 들간을 구분하기 위한 구분자이다.
Intra_Bundle_Priority는 현재 BDC를 구성하고 있는 Asset 들이 해당 번들 내에서의 가지는 우선 순위를 나타내는 속성 값이다. 이는 패키지 혹은 번들을 생성하는 Service Provider나 Package Provider 등에 의해 Author(컨텐츠 제공자)가 중요하다고 생각되는 Asset들 간의 우선 순위를 나타내며 Author(컨텐츠 제공자)의 의도를 MMT Sending Entity나 MANE 혹은 MMT Receiving Entity에게 전달하는 수단이 된다. 이를 통해 MMT Sending Entity나 MANE가 네트워크 혼잡, 사용자 선호도 등에 의해 임의의 Asset 전송을 멈추거나 빼야 할 때 MMTP 패킷 단위의 drop도 가능하지만 번들내 Asset 들간의 우선 순위를 Intra_Bundle_Priority를 근거로 판단하고 중요도에 따라 특정 Asset 자체를 전송에서 drop 할 수 있다. 우선 순위를 표현하기 위한 방법은 매우 여러 가지가 있을 수 있겠지만, Author(컨텐츠 제공자)가 자체 정의한 임의의 순서 (ex. 0은 가장 높은 우선순위, 12는 가장 낮은 우선순위 등)등의 방법으로 지정할 수 있다.
Inter_Bundle_Priority는 현재 패키지 내에 존재하는 여러 번들 들간의 상대적인 우선 순위를 나타내는 속성 값이다. 이는 패키지 혹은 번들을 생성하는 Service Provider나 Package Provider 등에 의해 Author(컨텐츠 제공자)가 중요하다고 생각되는 번들들 간의 우선 순위를 나타내며 Author(컨텐츠 제공자)의 의도를 MMT Sending Entity나 MANE 혹은 MMT Receiving Entity에게 전달하는 수단이 된다. 이를 통해 MMT Sending Entity나 MANE가 네트워크 혼잡, 사용자 선호도 등에 의해 임의의 번들 전송을 멈추거나 다른 번들로 전송을 바꿔야 할 때 번들 간 우선 순위를 Inter_Bundle_Priority를 근거로 판단하고 중요도에 따라 특정 번들을 전송하다가 다른 번들로 스위치(변경)하여 전송할 수 있다. 우선 순위를 표현하기 위한 방법은 매우 여러 가지가 있을 수 있겠지만, Author(컨텐츠 제공자)가 자체 정의한 임의의 순서 (ex. 0은 가장 높은 우선순위, 12는 가장 낮은 우선순위 등)등의 방법으로 지정할 수 있다.
상기 기재한 syntax 이외의 syntax는 아래 <표 17>과 같은 의미를 갖는다.
<표 17>
Figure 112014062948480-pat00019
Figure 112014062948480-pat00020
<표 18>
Figure 112014062948480-pat00021
<표 19>
Figure 112014062948480-pat00022
<표 20>
Figure 112014062948480-pat00023
도 11은 본 발명의 다른 실시 예에 따른 MMT 시스템에서 각 노드의 구성을 보이고 있다.
도 11을 참조하면, MMT Packet 전송 노드인 MMT Sending Entity(1110), MMT Packet 수신 노드인 MMT Receiving Entity(1130) 및 라우터 스위치 등과 같은 네트워크 노드인 MANE(MMT Aware Network Element) Node(1150)를 포함한다.
MMT Sending Entity(1110)에 포함된 ADC 신호 생성/수집부(1113)는 시간에 따른 미디어(Asset)의 트래픽 특성 정보가 담긴 ADC 정보를 수집하고 이를 MMT Sending Entity(1110)에서 사용할 수 있도록 혹은 MMT Receiving Entity(1150)에게 전송할 수 있도록 적절히 가공처리하는 모듈이다. BDC 생성부(1115)는 특정 번들을 구성하는 각 Asset들의 ADC 정보들로부터 특정 번들에 대한 전송 특성 정보인 BDC 정보를 생성하는 모듈이다. 미디어 전송 결정부(1117)는 BDC 정보를 근거로 번들 간(Inter_Bundle_Priority) 그리고 번들 내 Asset들간 우선 순위 정보(Intra_Bundle_Priority)를 비교하고 사용자 선호도, 네트워크 혼잡상황, 디바이스 능력(Capability)등이 변화하여 전송 중인 미디어의 품질을 변경시켜야만 하는 (고품질->저품질, 저품질->고품질) 필요성이 발생한 경우, 보내고 있는 번들을 다른 품질의 번들로 변경하거나, 특정 번들 내에서 특정 Asset들의 전송을 멈추는 등의 동작을 통해 상황 적응적인 전송을 가능하도록 전송할 Asset을 결정하는 모듈이다. 네트워크 자원 예약 처리부(1111)는 MMT에서 정의 하고 있지 않은 별도의 프로토콜로 MMT 트래픽 전송을 위해 네트워크 자원을 예약해주는 프로토콜 (ex. RSVP)을 처리하는 모듈이다. 그리고 MMT Packet 송신부(1117)sms MMT 패킷을 수신하고 ADC 검출부(1157)로 전달하거나 MMT Receiving Entity(1150)로 그대로 전송하는 모듈이다.
상기 MANE Node(1130)에 포함된 BDC/ADC 검출부(1139)는 MANE Node(1130)를 지나가는 MMT 패킷들을 모니터링하고 그로부터 BDC/ADC 정보가 담긴 시그널링 메시지를 추출하는 모듈로 예를 들어 MMT Packet 헤더의 Type 필드와 메시지 내 message_id 정보를 근거로 해당 메시지가 BDC/ADC 정보를 담고 있는지 여부를 판단할 수 있다. 또한 BDC/ADC 검출부(1139)는 BDC/ADC 정보의 업데이트가 필요한지를 감지하고 필요한 경우 업데이트된 BDC/ADC를 수신하거나, 역시 또한 필요한 경우 MMT Sending Entity에 알고 싶어 하는 BDC/ADC 정보를 요청하는 모듈이다.
MMT Packet 수신/전달/처리부(1141)는 MMT Sending Entity(1110)로부터 MMT 패킷을 수신하여 이를 MMT Receiving Entity(1150)로 전달하는 모듈이다. 그리고 MMT Packet 수신/전달/처리부(1141)는 BDC 정보를 미리 알고 있고 네트워크 혼잡 등의 상황으로 인해 부득이 패킷 drop이 필요한 경우, MANE는 BDC 정보를 근거로 특정 패킷 혹은 특정 Asset을 drop하는 동작을 수행하는 모듈이다.
동적 자원 관리부(1137)는 MMT Sending Entity(1110)로부터 BDC/ADC 정보를 수신 받아 그 트래픽 특성을 고려하여 네트워크 자원요청을 효율적으로 갱신 하는데 적용하는 모듈로, MMT Receiving Entity(1150)의 동적자원 관리부의 경우 MMT Sending Entity(1110)와 RSVP를 수행할 때 참고자료로 사용할 수 있다(일 예로, 업데이트 및 수준 등). 또한 BDC/ADC 정보를 통해 MMT Receiving Entity(1150)에서 확보해야 할 버퍼 정보 등에 활용할 수 있다.
네트워크 자원 예약 처리부(1131)는 MMT에서 정의하고 있지 않은 별도의 프로토콜로 MMT 트래픽 전송을 위해 네트워크 자원을 예약해주는 프로토콜 (일 예로, RSVP)을 처리하는 모듈이다.
Network 자원 할당부(1133)는 자신(일 예로, 라우터)의 네트워크 자원을 특정 트래픽에 할당하는 모듈이다. 그리고 자원 현황 모니터링부(1135)은 현재 사용중인 MANE node(1130)의 자원 이용 현황을 파악하는 모듈이다.
MMT Receiving Entity(1150)에 포함된 동적 자원 관리부(1155)는 MMT Sending Entity(1110)로 부터 ADC 정보를 수신 받아 그 트래픽 특성을 고려하여 네트워크 자원요청을 효율적으로 갱신 하는데 적용하는 모듈로, MMT Receiving Entity(1150)의 동작자원 관리부의 경우 MMT Sending Entity(1110)와 RSVP를 수행할 때 참고자료로 사용할 수 있다(ex. 업데이트 및 수준 등). 또한 BDC/ADC 정보를 통해 MMT Receiving Entity(1150)에서 확보해야 할 버퍼 정보 등에 활용할 수 있다.
BDC/ADC 검출부(1157)는 수신된 MMT 패킷들을 모니터링하고 그로부터 BDC/ADC 정보가 담긴 시그널링 메시지를 추출하는 모듈로 예를 들어 MMT Packet 헤더의 Type 필드와 메시지 내 message_id 정보를 근거로 해당 메시지가 BDC/ADC 정보를 담고 있는지 여부를 판단할 수 있다.
네트워크 자원 예약 처리부(1151)는 MMT에서 정의 하고 있지 않은 별도의 프로토콜로 MMT 트래픽 전송을 위해 네트워크 자원을 예약해주는 프로토콜 (ex. RSVP)을 처리하는 모듈이다. 그리고 MMT Packet 수신부(1159)는 MMT Sending Entity(1110)로부터 MMT 패킷을 수신하여 처리하는 모듈이다.
이하, 본 발명의 다른 실시 예에서 BDC를 생성하고 생성된 BDC를 이용하는 방법에 대하여 설명하기로 한다.
먼저, 본 발명의 다른 실시 예에서 BDC는 다음과 같이 생성된다.
특정 번들의 BDC는 해당 번들에 속하는 모든 Asset의 전송 특성인 ADC의 각 파라메터 값들을 취합하여 만들 수 있다. 예를 들어 3개의 Asset으로 구성된 번들의 경우, 해당 번들의 전송 특성값 (QoS descriptors and bitstream descriptors)들은 각 Asset들의 ADC 값들을 다음과 같은 룰을 이용하여 머지하여 만들 수 있다.
1. [sustainable_rate, buffer_size] : Leaky bucket 모델은 sustainable rate R 과　buffer_size B로 나타낼 수 있으며 해당 값들은 아래와 같이 계산 가능하다.
RBDC　= R1　+ R2　+ R3
BBDC　=
Figure 112014062948480-pat00024
2. [peak_rate, max_MFU_size, mfu_period] : 번들의 Peak_rate인　PkBDC, 번들의 max_MFU_size인　MMFBDC　, 번들의 MFU_Period 값인 MFU_PBDC은 통계적인 표준 편차값으로 여겨지므로 각 ADC의 해당 값들의 mean square 값으로 구해질 수 있다.
PkBDC　=
Figure 112014062948480-pat00025
MMFBDC　=
Figure 112014062948480-pat00026
MFU_PBDC　=
Figure 112014062948480-pat00027
3. Transmission_priority Pr
PrBDC　= max(Pr1, Pr2, Pr3)
4. Delay_priority Dp
DpBDC　= min(Dp1, Dp2, Dp3)
5. Class_of_service CS: If one of CS is VBR, the bundle is VBR. || means OR operation.
CSBDC　= (CS1　||　CS2　||　CS3)
6. Bidirectional_indicator BI: if one of BI is bidirectional, the bundle is bi-direcional.
BIBDC　= (BI1　||　BI2　||　BI3)
도 12는 본 발명의 다른 실시 예에 따른 BDC를 이용한 서버의 동작에 대한 일 예를 보이고 있다.
도 12를 참조하면, 사용자 선호도, 네트워크 혼잡상황, 디바이스 능력(Capability)등의 변화로 인해 해당 노드들에게 관련있는 미디어(Asset)들에 대한 연관성 정보를 부여하게 되면 효과적인 미디어(패킷) 드랍이 가능하다.
사용자 선호도, 네트워크 혼잡상황, 디바이스 능력(Capability)등이 변화하여 전송 중인 미디어의 품질을 변경(고품질->저품질, 저품질->고품질)시켜야만 하거나, 서버/MANE/클라이언트 등이 일부 Asset들에 대한 전송을 중단하는 등의 상황 적응적인 미디어 전송이 필요한 경우 번들 정보가 활용될 수 있다.
네트워크 혼잡상황 등으로 인해 적응적 품질 제공의 필요성이 발생한 경우, 보내고 있는 번들을 다른 품질의 번들로 변경하거나, 특정 번들 내에서 특정 Asset들의 전송을 멈추는 등의 동작을, BDC 정보안의 번들 간(Inter_Bundle_Priority) 그리고 번들 내 Asset들간 우선 순위 정보 (Intra_Bundle_Priority)를 비교하여 판단할 수 있다. 기존의 MMT 시스템에서는 네트워크 혼잡 상황에서 미디어 적응적 전송이 필요한 경우 특정 프레임을 버리는 방식으로 적응적 전송을 수행하였다, 이 경우, 모든 Asset들에 일률적으로 특정 프레임을 drop하는 방식으로 적응적 전송을 수행하게 된다. 하지만, 특정 Asset을 선별적으로 아예 통째로 전송하지 않는 것도 가능하다. (ex. N-screen 방송에서 네트워크 혼잡이 발생한 경우 패킷 드랍을 통해 메인 TV와 2nd screen으로 가는 비디오의 프레임을 모두 동시에 낮추는 것이 아니라 번들 BDC내 우선순위 및 전송 특성 정보로부터 네트워크 혼잡 상황에 맞게 특정 낮은 전송율의 번들로 번들 자체를 바꾸던가 해당 번들내 여러 Asset 들 가운데 2nd screen으로 가는 중요도가 낮은 Asset을 아예 통째로 전송하지 않음)
Inter_Bundle_Priority는 현재 패키지 내에 존재하는 여러 번들 들간의 상대적인 우선 순위를 나타내는 속성 값이다. 이는 패키지 혹은 번들을 생성하는 Service Provider나 Package Provider 등에 의해 Author(컨텐츠 제공자)가 중요하다고 생각되는 번들들 간의 우선 순위를 나타내며 Author(컨텐츠 제공자)의 의도를 MMT Sending Entity나 MANE 혹은 MMT Receiving Entity에게 전달하는 수단이 된다. 이를 통해 MMT Sending Entity나 MANE가 네트워크 혼잡, 사용자 선호도 등에 의해 임의의 번들 전송을 멈추거나 다른 번들로 전송을 바꿔야 할 때 번들 간 우선 순위를 Inter_Bundle_Priority를 근거로 판단하고 중요도에 따라 특정 번들을 전송하다가 다른 번들로 스위치(변경)하여 전송할 수 있다. 우선 순위를 표현하기 위한 방법은 매우 여러 가지가 있을 수 있겠지만, Author(컨텐츠 제공자)가 자체 정의한 임의의 순서 (ex. 0은 가장 높은 우선순위, 12는 가장 낮은 우선순위 등)등의 방법으로 지정할 수 있다.
Intra_Bundle_Priority는 현재 BDC를 구성하고 있는 Asset 들이 해당 번들 내에서의 가지는 우선 순위를 나타내는 속성 값이다. 이는 패키지 혹은 번들을 생성하는 Service Provider나 Package Provider 등에 의해 Author(컨텐츠 제공자)가 중요하다고 생각되는 Asset들 간의 우선 순위를 나타내며 Author(컨텐츠 제공자)의 의도를 MMT Sending Entity나 MANE 혹은 MMT Receiving Entity에게 전달하는 수단이 된다. 이를 통해 MMT Sending Entity나 MANE가 네트워크 혼잡, 사용자 선호도 등에 의해 임의의 Asset 전송을 멈추거나 빼야 할 때 MMTP 패킷 단위의 drop도 가능하지만 번들내 Asset 들간의 우선 순위를 Intra_Bundle_Priority를 근거로 판단하고 중요도에 따라 특정 Asset 자체를 전송에서 drop 할 수 있다. 우선 순위를 표현하기 위한 방법은 매우 여러 가지가 있을 수 있겠지만, Author(컨텐츠 제공자)가 자체 정의한 임의의 순서 (ex. 0은 가장 높은 우선순위, 12는 가장 낮은 우선순위 등)등의 방법으로 지정할 수 있다.
또한 본 발명의 다른 실시 예에 따른 BDC를 이용한 서버의 동작에 대한 다른 예는 자원 예약 및 플로우 라벨(Flow label)에 대한 것이다.
어떤 한 MMT Sending Entity로부터 다른 MMT Receiving Entity로 전달되는 MMT Flow는 하나의 번들로서 구성되고 해당 번들의 전송 특성은 BDC를 통해 알 수 있다. 네트워크 MANE는 특정 플로우의 per-flow QoS 관리를 위해 MMT 규격 안에서 flow_label이라는 식별자를 사용한다. 이는 MMT 규격 안에서 아래 <표 21>과 같이 정의된다.
flow_label (7bits)- indicates the flow identifier. The application can perform per-flow QoS operations in which network resources are temporarily reserved during the session. A flow is defined to be a bitsream or a group of bitstreams whose network resources are reserved according to transport characteristics or ADC in Package. It is an implicit serial number from '0' to '127'. An arbitrary number is assigned temporarily during a session and refers to every individual flow for whom a decoder (processor) is assigned and network resource could be reserved.
따라서 종래에는 해당 flow를 흐르는 여러 Asset의 ADC 값들을 일일히 추출해서 해당값들을 머지해 사용해야만 했으나, 본 발명의 실시 예에 따르면 한 flow내에 여러 Asset이 전송되는 경우 특정 flow_label은 BDC로서 대표될 수 있고, 이를 자원 예약을 위해 사용할 수 있다.
　한편 본 발명의 상세한 설명에서는 구체적인 실시 예에 관해 설명하였으나, 본 발명의 범위에서 벗어나지 않는 한도 내에서 여러 가지 변형이 가능함은 물론이다. 그러므로 본 발명의 범위는 설명된 실시 예에 국한되어 정해져서는 안되며 후술하는 특허 청구의 범위뿐만 아니라 이 특허 청구의 범위와 균등한 것들에 의해 정해져야 한다.

Claims (20)

  1. 송신 엔터티에 의해 패킷을 전송하는 방법에 있어서,
    상기 송신 엔터티가 전송된 패킷을 재전송하기 위해 저장하는 시간 윈도우에 관한 정보를 포함하는 자동 반복 요청 (automatic repeat request : ARQ) 구성 정보를 생성하는 과정;
    상기 ARQ 구성 정보를 포함하는 ARQ 구성 (ARQ configuration : AC) 메시지를 수신 엔터티로 전송하는 과정;
    상기 전송된 패킷 중 손실 패킷에 관한 정보, ARQ 모드에 관한 정보 및 상기 수신 엔터티가 상기 손실 패킷을 요청할 때 이용하는 논의 타입 (argument type)에 관한 정보를 포함하는 ARQ 피드백 (ARQ feedback : AF) 메시지를 상기 수신 엔터티로부터 수신하는 과정;
    상기 AF 메시지를 기반으로 손실 패킷을 재전송할 지의 여부를 결정하는 과정; 및
    상기 결정을 기반으로 상기 손실 패킷을 상기 수신 엔터티로 재전송하는 과정을 포함하고,
    상기 논의 타입에 관한 정보는, 상기 수신 엔터티가 패킷 카운터 (packet counter) 필드를 가지는 상기 AF 메시지를 전송함을 지시하는 값과, 상기 수신 엔터티가 패킷 아이디 (packet ID) 필드 및 패킷 시퀀스 넘버 (packet sequence number) 필드를 가지는 상기 AF 메시지를 전송함을 지시하는 값 중 하나를 포함함을 특징으로 하는 전송 방법.
  2. 제 1 항에 있어서, 상기 AC 메시지는 상기 손실 패킷을 요청할 서버의 주소에 관한 정보를 포함하는 전송 방법.
  3. 제 1 항에 있어서, 상기 손실 패킷에 관한 정보는, 손실 패킷 ID의 수에 관한 정보,
    상기 전송된 패킷의 손실 여부를 나타내는 마스크 (mask) 필드, 여기서, 상기 마스크 필드의 각 비트는 상기 전송된 패킷 각각에 대응함, 및
    도착 기한 (arrival deadline) 필드의 현재 시간을 지시하는 플래그 중 적어도 하나를 포함하고,
    상기 도착 기한 필드는 상기 손실 패킷에 대한 재전송된 패킷이 상기 수신 엔터티에 도달하는 마감기한을 지시함을 특징으로 하는 전송 방법.
  4. 삭제
  5. 제 2 항에 있어서, 상기 ARQ의 모드에 관한 정보는, 상기 서버가 시간 제한을 고려하지 않고 상기 손실 패킷을 전송함을 지시하는 값, 상기 수신 엔터티가 ARQ 피드백 타임 스탬프 (ARQ feedback timestamp) 필드 및 도착 기한 (arrival deadline) 필드를 가지는 상기 AF 메시지를 전송함을 나타내는 값, 및 확산 지연 (propagation delay)을 가지는 상기 AF 메시지를 전송함을 지시하는 값 중 하나를 포함하고,
    상기 ARQ 피드백 타임스탬프 필드는 상기 AF 메시지가 상기 수신 엔터티로부터 전송된 시간을 지시하고,
    상기 도착 기한 필드는 상기 손실 패킷에 대한 재전송 패킷이 상기 수신 엔터티에 도달하는 마감기한을 지시함을 특징으로 하는 전송 방법.
  6. 수신 엔터티에 의해 패킷을 수신하는 방법에 있어서,
    자동 반복 요청 (automatic repeat request : ARQ) 구성 정보를 포함하는 ARQ 구성 (ARQ configuration : AC) 메시지를 수신하는 과정, 여기서, 상기 ARQ 구성 정보는 송신 엔터티가 전송된 패킷을 재전송을 위해 저장하는 시간 윈도우에 관한 정보를 포함함;
    상기 전송된 패킷 중 손실 패킷에 관한 정보 및 ARQ 모드에 관한 정보를 생성하는 과정;
    상기 전송된 패킷 중 상기 손실 패킷에 관한 정보, 상기 ARQ 모드에 관한 정보 및 상기 수신 엔터티가 상기 손실 패킷을 요청할 때 이용하는 논의 타입 (argument type)에 관한 정보를 포함하는 ARQ 피드백 (ARQ feedback : AF) 메시지를 전송하는 과정; 및
    상기 손실 패킷의 재전송이 상기 AF 메시지를 기반으로 결정되면, 상기 손실 패킷을 수신하는 과정을 포함하고,
    상기 논의 타입에 관한 정보는, 상기 수신 엔터티가 패킷 카운터 (packet counter) 필드를 가지는 AF 메시지를 전송함을 지시하는 값과, 상기 수신 엔터티가 패킷 아이디 (packet ID) 필드 및 패킷 시퀀스 넘버 (packet sequence number) 필드를 가지는 AF 메시지를 전송함을 지시하는 값 중 하나를 포함함을 특징으로 하는 수신 방법.
  7. 제 6 항에 있어서, 상기 AC 메시지는 상기 손실 패킷을 요청할 서버의 주소에 관한 정보를 포함하는 수신 방법.
  8. 제 6 항에 있어서, 상기 AF 메시지는,
    손실 패킷 ID의 수에 관한 정보,
    상기 전송된 패킷의 손실 여부를 나타내는 마스크 (mask) 필드, 여기서, 상기 마스크 필드의 각 비트는 상기 전송된 패킷 각각에 대응함, 및
    도착 기한 (arrival deadline) 필드의 현재 시간을 지시하는 플래그 중 적어도 하나를 포함하고,
    상기 도착 기한 필드는 상기 손실 패킷에 대한 재전송된 패킷이 상기 수신 엔터티에 도달하는 마감기한을 지시함을 특징으로 하는 수신 방법.
  9. 삭제
  10. 제 7 항에 있어서, 상기 ARQ의 모드에 관한 정보는, 상기 서버가 시간 제한을 고려하지 않고 상기 손실 패킷을 전송함을 지시하는 값, 상기 수신 엔터티가 ARQ 피드백 타임 스탬프 (ARQ feedback timestamp) 필드 및 도착 기한 (arrival deadline) 필드를 가지는 상기 AF 메시지를 전송함을 나타내는 값, 및 확산 지연 (propagation delay)을 가지는 상기 AF 메시지를 전송함을 지시하는 값 중 적어도 하나를 포함하고,
    상기 ARQ 피드백 타임스탬프 필드는 상기 AF 메시지가 상기 수신 엔터티로부터 전송된 시간을 지시하고,
    상기 도착 기한 필드는 상기 손실 패킷에 대한 재전송 패킷이 상기 수신 엔터티에 도달하는 마감기한을 지시함을 특징으로 하는 수신 방법.
  11. 패킷을 전송하는 송신 엔터티에 있어서,
    데이터를 송수신하는 송수신부; 및
    상기 송신 엔터티가 전송된 패킷을 재전송하기 위해 저장하는 시간 윈도우에 관한 정보를 포함하는 자동 반복 요청 (automatic repeat request : ARQ) 구성 정보를 생성하고, 상기 ARQ 구성 정보를 포함하는 ARQ 구성 (ARQ configuration : AC) 메시지를 수신 엔터티로 전송하고, 상기 전송된 패킷 중 손실 패킷에 관한 정보, ARQ 모드에 관한 정보 및 상기 수신 엔터티가 상기 손실 패킷을 요청할 때 이용하는 논의 타입 (argument type)에 관한 정보를 포함하는 ARQ 피드백 (ARQ feedback : AF) 메시지를 상기 수신 엔터티로부터 수신하고, 상기 AF 메시지를 기반으로 손실 패킷을 재전송할 지의 여부를 결정하고, 상기 결정을 기반으로 상기 손실 패킷을 상기 수신 엔터티로 재전송하도록 제어하는 제어부를 포함하며,
    상기 논의 타입에 관한 정보는, 상기 수신 엔터티가 패킷 카운터 (packet counter) 필드를 가지는 AF 메시지를 전송함을 지시하는 값과, 상기 수신 엔터티가 패킷 아이디 (packet ID) 필드 및 패킷 시퀀스 넘버 (packet sequence number) 필드를 가지는 AF 메시지를 전송함을 지시하는 값 중 하나를 포함함을 특징으로 하는 송신 엔터티.
  12. 제 11 항에 있어서, 상기 AC 메시지는 상기 손실 패킷을 요청할 서버의 주소에 관한 정보를 포함하는 송신 엔터티.
  13. 제 11 항에 있어서, 상기 AF 메시지는,
    손실 패킷 ID의 수에 관한 정보,
    상기 전송된 패킷의 손실 여부를 나타내는 마스크 (mask) 필드, 여기서, 상기 마스크 필드의 각 비트는 상기 전송된 패킷 각각에 대응함, 및
    도착 기한 (arrival deadline) 필드의 현재 시간을 지시하는 플래그 중 적어도 하나를 포함하고,
    상기 도착 기한 필드는 상기 손실 패킷에 대한 재전송된 패킷이 상기 수신 엔터티에 도달하는 마감기한을 지시함을 특징으로 하는 송신 엔터티.
  14. 삭제
  15. 제 12 항에 있어서, 상기 ARQ의 모드에 관한 정보는, 상기 서버가 시간 제한을 고려하지 않고 상기 손실 패킷을 전송함을 지시하는 값, 상기 수신 엔터티가 ARQ 피드백 타임 스탬프 (ARQ feedback timestamp) 필드 및 도착 기한 (arrival deadline) 필드를 가지는 상기 AF 메시지를 전송함을 나타내는 값, 및 확산 지연 (propagation delay)을 가지는 상기 AF 메시지를 전송함을 지시하는 값 중 적어도 하나를 포함하고,
    상기 ARQ 피드백 타임스탬프 필드는 상기 AF 메시지가 상기 수신 엔터티로부터 전송된 시간을 지시하고,
    상기 도착 기한 필드는 상기 손실 패킷에 대한 재전송 패킷이 상기 수신 엔터티에 도달하는 마감기한을 지시함을 특징으로 하는 송신 엔터티.
  16. 패킷을 수신하는 수신 엔터티에 있어서,
    데이터를 송수신하는 송수신부; 및
    자동 반복 요청 (automatic repeat request : ARQ) 구성 정보를 포함하는 ARQ 구성 (ARQ configuration : AC) 메시지를 수신하고, 상기 ARQ 구성 정보는 송신 엔터티가 전송된 패킷을 재전송을 위해 저장하는 시간 윈도우에 관한 정보를 포함함, 상기 전송된 패킷 중 손실 패킷에 관한 정보 및 ARQ 모드에 관한 정보를 생성하고, 상기 전송된 패킷 중 상기 손실 패킷에 관한 정보, 상기 ARQ 모드에 관한 정보 및 상기 수신 엔터티가 상기 손실 패킷을 요청할 때 이용하는 논의 타입 (argument type)에 관한 정보를 포함하는 ARQ 피드백 (ARQ feedback : AF) 메시지를 전송하고, 상기 손실 패킷의 재전송이 상기 AF 메시지를 기반으로 결정되면, 상기 손실 패킷을 수신하도록 제어하는 제어부를 포함하며,
    상기 논의 타입에 관한 정보는, 상기 수신 엔터티가 패킷 카운터 (packet counter) 필드를 가지는 AF 메시지를 전송함을 지시하는 값과, 상기 수신 엔터티가 패킷 아이디 (packet ID) 필드 및 패킷 시퀀스 넘버 (packet sequence number) 필드를 가지는 AF 메시지를 전송함을 지시하는 값 중 하나를 포함함을 특징으로 하는 수신 엔터티.
  17. 제 16 항에 있어서, 상기 AC 메시지는 상기 손실 패킷을 요청할 서버의 주소에 관한 정보를 포함하는 수신 엔터티.
  18. 제 16 항에 있어서, 상기 AF 메시지는,
    손실 패킷 ID의 수에 관한 정보,
    상기 전송된 패킷의 손실 여부를 나타내는 마스크 (mask) 필드, 여기서, 상기 마스크 필드의 각 비트는 상기 전송된 패킷 각각에 대응함, 및
    도착 기한 (arrival deadline) 필드의 현재 시간을 지시하는 플래그 중 적어도 하나를 포함하고,
    상기 도착 기한 필드는 상기 손실 패킷에 대한 재전송된 패킷이 상기 수신 엔터티에 도달하는 마감기한을 지시함을 특징으로 하는 수신 엔터티.
  19. 삭제
  20. 제 17 항에 있어서, 상기 ARQ의 모드에 관한 정보는, 상기 서버가 시간 제한을 고려하지 않고 상기 손실 패킷을 전송함을 지시하는 값, 상기 수신 엔터티가 ARQ 피드백 타임 스탬프 (ARQ feedback timestamp) 필드 및 도착 기한 (arrival deadline) 필드를 가지는 상기 AF 메시지를 전송함을 나타내는 값, 및 확산 지연 (propagation delay)을 가지는 상기 AF 메시지를 전송함을 지시하는 값 중 적어도 하나를 포함하고,
    상기 ARQ 피드백 타임스탬프 필드는 상기 AF 메시지가 상기 수신 엔터티로부터 전송된 시간을 지시하고,
    상기 도착 기한 필드는 상기 손실 패킷에 대한 재전송 패킷이 상기 수신 엔터티에 도달하는 마감기한을 지시함을 특징으로 하는 수신 엔터티.
KR1020140083199A 2014-07-03 2014-07-03 멀티미디어 시스템에서 정보를 송수신하는 방법 및 장치 KR102198701B1 (ko)

Priority Applications (5)

Application Number Priority Date Filing Date Title
KR1020140083199A KR102198701B1 (ko) 2014-07-03 2014-07-03 멀티미디어 시스템에서 정보를 송수신하는 방법 및 장치
JP2017500081A JP6628785B2 (ja) 2014-07-03 2015-07-03 マルチメディアシステムにおける情報を送受信する方法及び装置
PCT/KR2015/006873 WO2016003234A1 (ko) 2014-07-03 2015-07-03 멀티미디어 시스템에서 정보를 송수신하는 방법 및 장치
CN201580047294.6A CN106664440B (zh) 2014-07-03 2015-07-03 用于在多媒体系统中接收和发送信息的方法和设备
US15/323,612 US10498492B2 (en) 2014-07-03 2015-07-03 Method and device for receiving and transmitting information in multimedia system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020140083199A KR102198701B1 (ko) 2014-07-03 2014-07-03 멀티미디어 시스템에서 정보를 송수신하는 방법 및 장치

Publications (2)

Publication Number Publication Date
KR20160004628A KR20160004628A (ko) 2016-01-13
KR102198701B1 true KR102198701B1 (ko) 2021-01-05

Family

ID=55019672

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020140083199A KR102198701B1 (ko) 2014-07-03 2014-07-03 멀티미디어 시스템에서 정보를 송수신하는 방법 및 장치

Country Status (5)

Country Link
US (1) US10498492B2 (ko)
JP (1) JP6628785B2 (ko)
KR (1) KR102198701B1 (ko)
CN (1) CN106664440B (ko)
WO (1) WO2016003234A1 (ko)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102105656B1 (ko) * 2014-01-09 2020-04-28 한국전자통신연구원 Mmt 서비스의 패킷 재전송 방법 및 장치, 재전송 요청 방법 및 장치
CN107888342B (zh) * 2016-09-30 2019-10-25 瞬已网络科技（上海）有限公司 一种网络实时视频传输方法及装置
CN109120383B (zh) * 2017-06-26 2021-11-26 深圳市道通智能航空技术股份有限公司 无人机及其地面站、数据传输方法
US10686861B2 (en) * 2018-10-02 2020-06-16 Google Llc Live stream connector
CN118590193A (zh) * 2018-10-19 2024-09-03 中兴通讯股份有限公司 一种传输方法、装置和系统
CN114095796A (zh) * 2020-07-30 2022-02-25 中国移动通信集团终端有限公司 无效重传包减少方法、装置、设备及计算机存储介质
US11689777B2 (en) * 2020-08-27 2023-06-27 Dish Network Technologies India Private Limited Pausing native media streaming for extended periods of time using dummy media segments

Family Cites Families (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS5983431A (ja) 1982-11-04 1984-05-14 Omron Tateisi Electronics Co デ−タ伝送制御方法
JPH09186679A (ja) 1995-12-27 1997-07-15 Fuji Xerox Co Ltd 通信装置
EP1018821A1 (en) * 1999-01-08 2000-07-12 TELEFONAKTIEBOLAGET L M ERICSSON (publ) Communication device and method
JP4015773B2 (ja) * 1999-03-10 2007-11-28 松下電器産業株式会社 送受信装置
EP1361690B1 (en) * 2000-03-02 2006-01-11 Matsushita Electric Industrial Co., Ltd. Method and apparatus for retransmitting data packets based on channel conditions
JP2003008553A (ja) 2001-06-22 2003-01-10 Mitsubishi Electric Corp 送信機、受信機、送受信機および通信システム
JP3757857B2 (ja) * 2001-12-12 2006-03-22 ソニー株式会社 データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラム
US7145889B1 (en) * 2002-03-28 2006-12-05 Nortel Networks Limited Efficient frame retransmission in a wireless communication environment
US7719978B2 (en) * 2003-09-12 2010-05-18 Newsouth Innovations Pty Limited Method for transmitting data over lossy packet-based communication networks
KR20050044219A (ko) * 2003-11-07 2005-05-12 삼성전자주식회사 광대역 무선 접속 통신 시스템에서 피드백을 위한 상향링크 자원 할당 방법
US7961700B2 (en) 2005-04-28 2011-06-14 Qualcomm Incorporated Multi-carrier operation in data transmission systems
KR100703287B1 (ko) 2005-07-20 2007-04-03 삼성전자주식회사 통신 시스템에서 자원 할당 정보 송수신 시스템 및 방법
US7672250B2 (en) 2005-11-16 2010-03-02 Via Telecom Co., Ltd. Multi-carrier wireless communication access terminal and data transmission method
KR101203469B1 (ko) * 2006-02-11 2012-11-21 삼성전자주식회사 패킷 네트워크에서 컷스루 방식으로 노드간 전파 지연 및거리를 정확하고 안전하게 측정하는 방법 및 상기 방법을수행하는 패킷 네트워크 노드
KR100943590B1 (ko) * 2006-04-14 2010-02-23 삼성전자주식회사 이동 통신 시스템에서 상태 보고의 송수신 방법 및 장치
EP2161868A4 (en) * 2007-06-22 2011-12-28 Alcatel Lucent METHOD AND SYSTEM FOR MBMS DATA TRANSFER
US8499212B2 (en) * 2007-10-23 2013-07-30 Thomson Licensing Method and apparatus for adaptive forward error correction with merged automatic repeat request for reliable multicast in wireless local area networks
KR101365182B1 (ko) * 2008-01-09 2014-03-13 성균관대학교산학협력단 전송 제어 프로토콜 기반의 패킷 전송 제어 방법 및 시스템
US20090201794A1 (en) * 2008-02-08 2009-08-13 Qualcomm, Incorporated Multiplexing devices over shared resources
WO2009146745A1 (en) 2008-06-05 2009-12-10 Nokia Siemens Networks Oy Receiving unit in a wireless communication network and method for generating an automatic repeat request feedback message
KR20110101403A (ko) * 2010-03-08 2011-09-16 삼성전자주식회사 무선통신 시스템에서 기지국의 패킷 포워딩 장치 및 방법
KR101691480B1 (ko) * 2010-04-06 2017-01-09 삼성전자주식회사 이동통신 시스템에서 패킷 재전송 방법 및 장치
JP5908504B2 (ja) * 2011-03-08 2016-04-26 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ 複数のコンポーネント・キャリアに関する伝搬遅延差レポート
WO2013153513A2 (en) * 2012-04-09 2013-10-17 Telefonaktiebolaget L M Ericsson (Publ) Methods and apparatus for enhancing network positioning measurement performance by managing uncertain measurement occasions
US9137675B2 (en) 2012-06-13 2015-09-15 All Purpose Networks LLC Operational constraints in LTE TDD systems using RF agile beam forming techniques
US8923464B2 (en) * 2012-11-16 2014-12-30 Qualcomm Incorporated Methods and apparatus for enabling distributed frequency synchronization
CN103354615B (zh) 2013-06-24 2015-04-15 西安交通大学 基于信号强度的直播视频数据传输差错控制方法

Also Published As

Publication number Publication date
US10498492B2 (en) 2019-12-03
JP6628785B2 (ja) 2020-01-15
US20170141880A1 (en) 2017-05-18
CN106664440A (zh) 2017-05-10
JP2017526244A (ja) 2017-09-07
CN106664440B (zh) 2020-01-10
WO2016003234A1 (ko) 2016-01-07
KR20160004628A (ko) 2016-01-13

Similar Documents

Publication Publication Date Title
KR102198701B1 (ko) 멀티미디어 시스템에서 정보를 송수신하는 방법 및 장치
EP2352248B1 (en) Lost packet retransmission suppressing method, network node and system
US11316799B2 (en) Method and apparatus for transmitting a multimedia data packet using cross-layer optimization
US20200359088A1 (en) Method and apparatus of transmitting media data related information in multimedia transmission system
KR102107514B1 (ko) 방송 시스템에서 동적 큐 관리 방법 및 장치
US20200120152A1 (en) Edge node control
EP2224639A1 (en) Method, apparatus and system for resource management in networks
US20070127390A1 (en) Method for providing quality-guaranteed service in converged network and apparatus using the same
JP5375416B2 (ja) ストリーム配信装置、ストリーム配信システム、ストリーム配信方法およびストリーム配信プログラム
CN101626344A (zh) 用于资源分配的方法和设备
JP6537525B2 (ja) 通信システムにおけるリソース割り当て方法及び装置
JP3848222B2 (ja) 再送方法

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant