CN107743698B - 用于多路径媒体传递的方法和装置 - Google Patents

用于多路径媒体传递的方法和装置 Download PDF

Info

Publication number
CN107743698B
CN107743698B CN201680035343.9A CN201680035343A CN107743698B CN 107743698 B CN107743698 B CN 107743698B CN 201680035343 A CN201680035343 A CN 201680035343A CN 107743698 B CN107743698 B CN 107743698B
Authority
CN
China
Prior art keywords
network
server
network access
multipath
access interfaces
Prior art date
Legal status (The legal status 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 status listed.)
Active
Application number
CN201680035343.9A
Other languages
English (en)
Other versions
CN107743698A (zh
Inventor
P.科兰
I.布瓦齐兹
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Samsung Electronics Co Ltd
Original Assignee
Samsung Electronics Co Ltd
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 Samsung Electronics Co Ltd filed Critical Samsung Electronics Co Ltd
Publication of CN107743698A publication Critical patent/CN107743698A/zh
Application granted granted Critical
Publication of CN107743698B publication Critical patent/CN107743698B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/24Multipath
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/08Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0805Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
    • H04L43/0811Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking connectivity
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/08Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0823Errors, e.g. transmission errors
    • H04L43/0829Packet loss
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/08Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0852Delays
    • H04L43/087Jitter
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/302Route determination based on requested QoS
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/30Routing of multiclass traffic

Abstract

一种操作用于多路径数据分组接收的设备的方法,包括:将消息发送到服务器;并且基于两个或更多个网络接入接口的一个或更多个特性在多路径传输会话期间通过设备的两个或更多个网络接入接口的任意组合从服务器接收一个或更多个数据分组。消息包括对应于多路径传输会话并且指示设备的两个或更多个网络接入接口的组的标识符。

Description

用于多路径媒体传递的方法和装置
技术领域
本申请一般涉及多媒体传输,并且更具体地涉及多媒体传输路由。
背景技术
诸如运动图片专家组(MPEG)媒体传输协议(MMTP)的多媒体流传输技术使用传输层的服务将来自诸如MPEG媒体传输(MMT)发送器的源的数据分组流传输到诸如MMT接收器的目的地。在任何情况下,传输层都会选择能够被配置为将数据分组发送到目的地的默认接口的网络接口。由于连接到所选网络接口的网络中的问题,接收器可能会使数据分组延迟、丢失或接收到不稳定的抖动。这导致了接收器处的明显的服务质量(QoS)和体验质量(QoE)问题。另外,网络条件的动态变化,诸如网络路径的意外分组丢失、拥塞等可能导致质量下降。
发明内容
技术问题
本领域中需要通过多个网络接入接口中的每一个来接收一个或更多个数据分组。
解决方案
提供了一种用于多路径数据分组接收的客户端设备。客户端设备包括处理器和两个或更多个网络接入接口的组。处理器被配置为控制消息到服务器的传输。消息包括对于多路径传输会话是唯一的并且标识客户端设备的两个或更多个网络接入接口的组的标识符,以在多路径传输会话期间从服务器接收一个或更多个数据分组。处理器还被配置为基于两个或更多个网络接入接口的一个或更多个特性来控制在多路径传输会话期间通过客户端设备的两个或更多个网络接入接口中的每一个从服务器接收一个或更多个数据分组。
提供一种服务器。服务器包括处理器。处理器被配置为控制从客户端设备接收消息。消息包括对于多路径传输会话是唯一的并且标识客户端设备的两个或更多个网络接入接口的组的标识符,以在多路径传输会话期间从服务器接收一个或更多个数据分组。处理器还被配置为基于两个或更多个网络接入接口的一个或更多个特性来控制在多路径传输会话期间通过客户端设备的两个或更多个网络接入接口中的每一个向客户端设备发送一个或更多个数据分组。
提供了一种使用用于多路径数据分组接收的客户端设备实现的方法。所述方法包括由客户端设备向服务器发送消息。消息包括对于多路径传输会话是唯一的并且标识客户端设备的两个或更多个网络接入接口的组的标识符,以在多路径传输会话期间从服务器接收一个或更多个数据分组。方法还包括基于两个或更多个网络接入接口的一个或更多个特性,由客户端设备在多路径传输会话期间通过客户端设备的两个或更多个网络接入接口中的每一个从服务器接收一个或更多个数据分组。
一种操作用于多路径数据分组接收的设备的方法包括:基于两个或更多个网络接入接口的一个或更多个特性,在多路径传输会话期间,通过设备的两个或更多个网络接入接口的任意组合将消息发送到服务器,以及从服务器接收一个或更多个数据分组。消息包括对应于多路径传输会话并且指示设备的两个或更多个网络接入接口的组的标识符。
一种操作用于多路径数据分组发送的服务器的方法包括:在多路径传输会话期间通过对应于设备的两个或更多个网络接入接口的两个或更多个网络路径从设备接收消息以及将一个或更多个数据分组发送到设备。消息包括对应于多路径传输会话并且指示设备的两个或更多个网络接入接口的组的标识符,以在多路径传输会话期间从服务器接收一个或更多个数据分组。
有益效果
根据本公开,提供了设备和方法,使得客户端设备可以通过多个网络接入接口接收一个或更多个数据分组。
附图说明
为了更完整地理解本公开及其优点,现在参考以下结合附图的描述,其中,相同的附图标记表示相同的部件:
图1示出根据本公开的示例通信系统;
图2和图3示出根据本公开的通信系统中的示例设备;
图4示出根据本公开的运动图像专家组(MPEG)媒体传输(MMT)客户端和MMT服务器之间的实时流传输协议(RTSP)会话的示例方法;
图5示出根据本公开的MMT中的多路径传递的示例架构图;
图6示出根据本公开的使用RTSP协议的MMT会话建立的示例方法;
图7示出根据本公开的用于多个网络路径中的每一个的接收器反馈的示图;
图8示出根据本公开的使用超文本传输协议(HTTP)协议的MMT会话建立的示例方法;
图9示出根据本公开的设备的多路径数据分组接收的示例过程的流程图;以及
图10示出根据本公开的服务器的多路径数据分组传输的示例过程的流程图。
具体实施方式
在进行下面的详细描述之前,阐述在本专利文件中使用的特定词语和短语的定义可能是有利的:术语“包括”和“包含”及其派生词意味着包括但不限于;术语“或”是包含性的,意思是和/或;短语“与......相关”和“与其相关联”及其派生词可以表示包括,被包括在内,与...互相连接,包含,被包含在...内,连接到或与...连接,耦合到或与...耦合,与...通信,与...协作,交织,并置,接近于,绑定到或与...绑定,具有...的性质等;术语“控制器”是指控制至少一个操作的任何设备,系统或其部分,这样的设备可以以硬件,固件或软件或其中的至少两个的一些组合来实现。应该注意,与任何特定控制器相关的功能可以是集中式的或分布式的,不管是本地的还是远程的。当与项目列表一起使用时,短语“至少一个”意味着可以使用一个或更多个所列项目的不同组合,并且可能仅需要列表中的一个项目。例如,“A,B和C中的至少一个”包括以下组合中的任何一种:A;B;C;A和B;A和C;B和C以及A和B和C.
此外,下面描述的各种功能可以由一个或更多个计算机程序来实现或支持,每个计算机程序均由计算机可读程序代码形成并体现在计算机可读介质中。术语“应用”和“程序”是指适于在合适的计算机可读程序代码中实现的一个或更多个计算机程序,软件组件,指令集,过程,功能,对象,类,实例,相关数据或其一部分码。短语“计算机可读程序代码”包括任何类型的计算机代码,包括源代码,目标代码和可执行代码。短语“计算机可读介质”包括能够被计算机访问的任何类型的介质,诸如只读存储器(ROM),随机存取存储器(RAM),硬盘驱动器,光盘(CD),数字视频光盘(DVD)或任何其他类型的存储器。“非临时性”计算机可读介质排除传输临时性电信号或其他信号的有线,无线,光学或其他通信链路。非临时性计算机可读介质包括数据可以被永久存储的介质和数据可以被存储并且随后被重写的介质,诸如可重写光盘或可擦除存储器设备。
本专利文件通篇提供了对特定词语和短语的定义,本领域的普通技术人员应该理解,在许多情况下(如果不是绝大多数情况下),这样的定义适用于此类定义的词语和短语的以前以及将来的使用。
下文讨论的图1至图10以及用于描述本专利文件中的本公开的原理的各种实施例仅作为说明,而不应以任何方式解释为限制本公开的范围。本领域技术人员将理解,本公开的原理可以以任何适当布置的系统或设备来实现。
以下文件和标准描述通过引用被合并到本公开中,如同在此完全阐述一样:“Study of ISO/IEC CD 23008-1 moving picture expert group(MPEG)MediaTransport”,MPEG-H Systems,ISO/IEC JTC1/SC29/WG11,October 2012[1];“MPEG MediaTransport Protocol(MMTP)”,IETF Draft,https://tools.ietf.org/id/draft-bouazizi-mmtp-01.txt,September 2014[2];"Real Time Streaming Protocol(RTSP)",RFC 2326,https://www.ietf.org/rfc/rfc2326.txt,April 1998[3];"HypertextTransfer Protocol--HTTP/1.0",RFC 1945,http://tools.ietf.org/html/rfc1945,May1996[4];"Hypertext Transfer Protocol--HTTP/1.1",RFC 2616,http://www.w3.org/Protocols/rfc2616/rfc2616.txt,June 1999[5];"Hypertext Transfer Protocol(HTTP/1.1):Message Syntax and Routing",RFC 7230,https://tools.ietf.org/html/rfc7230,June 2014[6];"Hypertext Transfer Protocol(HTTP/1.1):Semantics andContent",RFC 7231,https://tools.ietf.org/html/rfc7231[7];"SDP:SessionDescription Protocol",RFC4566,https://tools.ietf.org/html/rfc4566,July 2006[8];"Grouping of Media Lines in the Session Description Protocol(SDP)",RFC3388,https://tools.ietf.org/html/rfc3388[9];"The Session Description Protocol(SDP)Grouping Framework",RFC 5888,https://tools.ietf.org/html/rfc5888[10];"The WebSocket Protocol",RFC 6455,https://tools.ietf.org/html/rfc6455[11];"SDPDescriptors for MMTP",IETF Draft,https://tools.ietf.org/html/draft-bouazizi-sdp-descriptors-mmtp-00[12];M.Kazemi,S.Shirmohammadi,K.H.Sadeghi,"A review ofmultiple description coding techniques for error-resilient video delivery",Multimedia Systems,Volume20,Issue 3,pp 283-309,June 2014[13];Z.Liu,G.Cheung,J.Chakareski,Y.Ji,"Multiple Description Coding and Recovery of Free ViewpointVideo for Wireless Multi-Path Streaming",IEEE Journal Of Selected Topics InSignal Processing,Vol.9,No.1,February 2015[14];J.Chakareski,S.Han,B.Girod,"Layered Coding vs.Multiple Descriptions for Videostreaming over MultiplePaths",Proc.of ACM Multimedia,pp.422-431,2003[15];V.Singh,S.Ahsan,J.Ott,"MPRTP:Multipath considerations for real-time media",Proc.of ACM MultimediaSystems,2013[16];G.Sun,U.Samarawickrama,J.Liang,C.Tian,C.Tu and T.D.Tran"Multipledescription coding with prediction compensation",IEEETrans.ImageProcess.,vol.18,no.5,pp.1037-1047,2009[17];Y.Ding,Y.Yang,L.Xiao,"Multi-path Routing and Rate Allocation for Multi-Sourcevideo On-demandStreaming in Wireless Mesh Networks",Proc.IEEE INFOCOM,pp.2051-2059,2011[18];C.Xu,Z.Li,J.Li,H.Zhang,G.Muntean,"Cross-layer Fairness-driven ConcurrentMultipath Video Delivery over Heterogenous Wireless Network,IEEE Transactionson Circuits and Systems for Video Technology,December 2014[19];L.Zhang,M.Hauswirth,Z.Zhou,V.Reynolds,G.Han,"Multi-priority Multi-Path Selection forVideo Streaming in Wireless Multimedia Sensor Networks",Fifth Internationalconference on Ubiquitous Intelligence and Computing(UIC 2008),Oslo,Norway,June 2008[20],and W.Wei,A.Zakhor,“Interference Aware Multipath Selection forVideo Streaming in Wireless Adhoc Networks”,IEEE Transactions On Circuits andSystems for Video Technology,vol.19,no.2,pp.165-178,2009[21]。
多媒体流传输(和应用)可以是网络不可知的,并且依赖于下层服务(诸如传输层和网络层)来将数据流传输到目的地。上层(诸如应用层)可以附加地或可选地参与路由决定和数据传送。应用程序可以交换信息来报告服务质量(QoS)和体验质量(QoE)。可以进行改进,使双方在谈话中可以使用高质量的信息来改善数据传递。
例如,多媒体流传输应用可以使用多个连接(诸如通过多个网络路径的连接)用于将数据从源传递到目的地(因此的“多路径传递”),而不是使用单个传递路径来传递数据。诸如智能手机和平板电脑的移动设备配备有多个网络接入接口,诸如第三代合作伙伴计划(3GPP)无线电接入和无线保真(WiFi)接口。重用替代网络接入信道将缓解网络过载问题,并增加移动运营商可以提供服务的用户数量。
作为另一示例,多媒体接收器应用可以检测并向发送器应用报告不同分组流(诸如来自不同的网络路径)的质量信息。发送器应用可以使用此质量信息来改变网络路径(诸如通过使用不同的网络接口)以进行后续数据分组传递,从而避免故障路径。这将缓解由于网络路径的不良网络条件在接收器处的QoS和QoE问题。由于决定可以针对不同粒度级别(诸如分组级别、流级别、连接级别等)在上层进行,因此发送器应用将具有更多的可见性,从而可以进行更多的控制来做出更明智的决策。
图1示出了根据本公开的示例通信系统100。图1中所示的通信系统100的实施例仅用于说明。可以在不脱离本公开的范围的情况下使用通信系统100的其他实施例。
如图1所示,系统100包括网络102,其促进系统100中的各种组件之间的通信。例如,网络102可以在网络地址之间通信互联网协议(IP)数据分组、帧中继帧、异步传输模式(ATM)小区或其他信息。网络102可以包括一个或更多个局域网(LAN)、城域网(MAN)、广域网(WAN)、诸如互联网的全球网络的全部或一部分,或者在一个或更多个地点的任何其他网络通信系统。
网络102促进至少一个服务器104和各种客户端设备106-114之间的通信。每个服务器104包括可以为一个或更多个客户端设备提供计算服务的任何合适的计算或处理设备。例如,每个服务器104可以包括一个或更多个处理设备、存储指令和数据的一个或更多个存储器以及便于在网络102上通信的一个或更多个网络接口。
每个客户端设备106、108、110、112、113和114表示通过网络102与至少一个服务器或其他计算设备(或多个)交互的任何合适的计算或处理设备。在该示例中,客户端设备106、108、110、112、113和114包括台式计算机106、移动电话或智能手机108、个人数字助理(PDA)110、膝上型计算机112和113以及平板电脑114。然而,可以在通信系统100中使用任何其它或附加客户端设备。
在该示例中,一些客户端设备108、110、112、113和114与网络102间接通信。例如,客户端设备108和110经由一个或更多个基站116进行通信,诸如蜂窝基站或eNodeB。此外,客户端设备112和114经由一个或更多个无线接入点118进行通信,诸如IEEE 802.11无线接入点。作为另一示例,客户端设备108可以具有多个网络接入接口。使用多个网络接入接口,客户端设备108可以经由网络通信路径109A通过一个或更多个基站116中的至少一个、经由网络通信路径109B通过一个或更多个无线接入点118与网络102通信,或经由网络通信路径109C与另一客户端设备112通信。
另外,在这个示例中,服务器104可以具有多个网络接入接口。使用多个网络接入接口,服务器104可以经由网络通信路径105A通过一个或更多个基站117中的至少一个、经由网络通信路径105B通过一个或更多个无线接入点119或经由网络通信路径105C通过一个或更多个设备113与网络102通信。注意,这些仅用于说明,并且每个客户端设备可以直接与网络102通信,或者经由任何合适的中间设备(或多个)或网络(或多个)与网络102间接通信。
如下面更详细描述的,接收器(诸如客户端设备108)可以经由网络通信路径通过多个指定网络接入接口从发送器接收数据分组。此外,发送器(诸如服务器104)可以通过一个或更多个指定网络接入接口并通过一个或更多个网络通信路径将数据分组发送到接收器。网络接入接口和网络通信路径可以仅在由接收器或发送器中的至少一个发起的多路径传输会话期间被指定用于数据分组通信。接收器或发送器也可以确定将要通过接收器的指定网络接入接口接收各种类型的数据分组。接收器和发送器还可以基于服务质量(QoS)参数、体验质量(QoS)参数或其他信道质量参数中的至少一个来确定适合于数据分组通信的数据通信路径的优先级或排名。
尽管图1示出通信系统100的一个示例,但是可以对图1进行各种改变。例如,系统100可以以任何合适的布置包括任何数量的每个组件。通常,计算和通信系统具有各种各样的配置,并且图1不将本公开的范围限制为任何特定的配置。尽管图1示出可以使用本专利文档中公开的各种特征的一个操作环境,但是这些特征可以用于任何其他合适的系统。
图2和图3示出根据本公开的通信系统中的示例设备。具体地,图2示出示例服务器200,并且图3示出示例客户端设备300。服务器200可以表示图1中的服务器104,且客户端设备300可以表示图1中的客户端设备106、108、110、112或114中的一个或更多个。
如图2所示,服务器200包括总线系统205,其支持至少一个处理器210、至少一个存储设备215、至少一个通信单元220和至少一个输入/输出(I/O)单元225之间的通信。
处理器210执行可以加载到存储器230中的指令。处理器210可以以任何合适的布置包括任何合适的数量和类型的处理器或其他设备。处理器210的示例类型包括微处理器、微控制器、数字信号处理器、现场可编程门阵列、专用集成电路以及离散电路。
存储器230和永久性存储器235是存储设备215的示例,其代表能够存储和便于检索信息(诸如数据、程序代码和/或基于临时或永久的其他合适的信息)的任何结构(或多个)。存储器230可以表示随机存取存储器或任何其他合适的易失性或非易失性存储设备(或多个)。永久性存储器235可以包含支持数据的长期存储的一个或更多个组件或设备,诸如只读存储器、硬盘驱动器、闪存或光盘。
通信单元220支持与其他系统或设备的通信。例如,通信单元220可以包括促进通过网络102的通信的网络接口卡或无线收发器。通信单元220可以通过任何合适的物理或无线通信链路(或多个)来支持通信。
I/O单元225允许输入和输出数据。例如,I/O单元225可以通过键盘、鼠标、小键盘、触摸屏或其他合适的输入设备来提供用于用户输入的连接。I/O单元225还可以将输出发送到显示器、打印机或其他合适的输出设备。
注意,虽然图2被描述为表示图1的服务器104,但是可以在一个或更多个客户端设备106-114中使用相同或相似的结构。例如,膝上型计算机或台式计算机可以具有与图2所示相同或相似的结构。
如下面更详细描述的,客户端设备300和服务器200可以用于多路径数据分组传输。例如,客户端设备300向服务器200发送请求。请求包括对于多路径传输会话是唯一并且标识客户端设备300的两个或更多个网络接入接口的标识符,以在多路径传输会话期间从服务器200接收一个或更多个数据分组。客户端设备300还可以在多路径传输会话期间通过客户端设备300的两个或更多个网络接入接口中的每一个从服务器200接收一个或更多个数据分组。
如图3所示,客户端设备300包括天线305、射频(RF)收发器310、发送(TX)处理电路315、麦克风320和接收(RX)处理电路325。客户端设备300还包括扬声器330、处理器340、输入/输出(I/O)接口(IF)345、小键盘350、显示器355和存储器360。存储器360包括操作系统(OS)程序361和一个或更多个应用362。
RF收发器310从天线305接收由系统中的另一个组件发送的输入RF信号。RF收发器310将输入的RF信号下变频以生成中频(IF)或基带信号。IF或基带信号被发送到RX处理电路325,RX处理电路325通过对基带或IF信号进行滤波、解码和/或数字化来生成处理后的基带信号。RX处理电路325将处理后的基带信号发送到扬声器330(诸如用于语音数据)或发送到处理器340用于进一步处理(诸如用于网页浏览数据)。
TX处理电路315从麦克风320接收模拟或数字语音数据或从处理器340接收其它输出基带数据(诸如web数据、电子邮件或交互式视频游戏数据)。TX处理电路315对输出基带数据进行编码、复用和/或数字化以生成处理后的基带或IF信号。RF收发器310从TX处理电路315接收输出处理后的基带或IF信号,并将基带或IF信号上变频为经由天线305发送的RF信号。在实施例中,两个或更多个网络接入接口可以包括一个或更多个I/O IF 345、一个或更多个RF收发器310等。I/O IF 345可以通过有线连接进行通信,诸如用于以太网连接的网络接口卡或用于机顶盒的电缆接口。RF收发器310可以与无线接入点(诸如无线接入点118或119)、基站(诸如基站116或117)等进行通信。
处理器340可以包括一个或更多个处理器或其他处理设备,并且执行存储在存储器360中的OS程序361,以便控制客户端设备300的整体操作。例如,处理器340可以控制由RF收发器310、RX处理电路325和TX处理电路315按照众所周知的原理的前向信道信号的接收和反向信道信号的发送。在一些实施例中,处理器340包括至少一个微处理器或微控制器。
处理器340还能够执行驻留在存储器360中的其他进程和程序。处理器340可以根据执行过程的需要将数据移入或移出存储器360。在一些实施例中,处理器340被配置为基于OS程序361或响应于从外部设备或操作者接收的信号来执行应用362。处理器340还耦合到I/O接口345,I/O接口345向客户端设备300提供连接到诸如膝上型计算机和手持式计算机的其他设备的能力。I/O接口345是这些附件与处理器340之间的通信路径。
处理器340还耦合到小键盘350和显示单元355。客户端设备300的操作者可以使用小键盘350将数据输入到客户端设备300中。显示器355可以是液晶显示器或其他能够呈现文本和/或至少有限的图形(诸如来自网站)的显示器。
存储器360耦合到处理器340。存储器360的一部分可以包括随机存取存储器(RAM),且存储器360的另一部分可以包括闪存或其他只读存储器(ROM)。
尽管图2和图3示出通信系统中的设备的示例,但是可以对图2和图3做出各种改变。例如,根据特定的需要,图2和图3中的各种组件可以被组合、进一步细分或省略,并且可以添加附加组件。作为特定示例,处理器340可以被划分为多个处理器,诸如一个或更多个中央处理单元(CPU)和一个或更多个图形处理单元(GPU)。另外,虽然图3示出客户端设备300被配置为移动电话或智能手机,但是客户端设备可以被配置为作为其他类型的移动或固定设备来操作。另外,与计算和通信网络一样,客户端设备和服务器可以具有各种各样的配置,并且图2和图3不将本公开限制于任何特定的客户端设备或服务器。
MMTP协议[[2]]是应用层协议,用于在MMT发送器和MMT接收器之间传递定时和非定时的多媒体数据。除了用于多媒体数据传递的有效载荷分组格式之外,MMTP协议还描述了一组信令消息及其消息格式。MMTP协议依靠传输层服务用于实际数据传输。在MMT发送器和MMT接收器之间建立传输连接(诸如利用传输控制协议(Transmission ControlProtocol,TCP)传输的TCP连接和利用用户数据报协议(User Datagram Protocol,UDP)传输的UDP流),用于交换多媒体数据。MMTP协议使用信令协议以在MMT发送器和MMT接收器之间建立MMTP会话,诸如实时流协议(Real Time Straming Protocol,RTSP)或超文本传输协议(Hypertext Transfer Protocal,HTTP)。
图4示出根据本公开的MMT客户端(诸如MMT接收器)和MMT服务器(诸如MMT发送器)之间的RTSP会话的示例方法400。在步骤405,客户端设备300请求服务器200描述用于数据传递的URL。在步骤410,服务器200响应于从客户端设备300接收到描述用于数据传递的URL的请求,使用会话描述协议(Session Description SDP)协议来发送主体描述。在步骤415,客户端设备300使用RTSP SETUP消息发送建立请求。客户端设备300可以在SETUP消息中包括传输参数,诸如传输配置文件(包括底层传输)、目的地地址和传输报头中的客户端端口,通过该客户端端口指定客户端设备300将希望通过哪一个或更多个路径接收流。在步骤420中,服务器200利用服务器200自身的一组传输参数(诸如传输报头中的服务器端口和目的地地址)用回复(诸如“200OK”)来响应SETUP请求。在步骤425,客户端设备300请求服务器200使用所建立的传输连接来播放多媒体数据。在步骤430,服务器200在使用SETUP和相应的回复消息建立的传输连接上向客户端设备300发送多媒体数据。如下所示,提供了可以在如在[12]中指定的会话建立期间使用的从服务器200到客户端300的示例SDP。
v=0
o=user 6431641313 1 IN IP4 10.10.52.13
s=An MMTP session
t=1411639200 1427277600
a=source-filter:incl IN IP4*10.10.52.13
m=application 12345 MMTP/UDP 100 101 102 103 104
a=of:100 flowid=0 Signaling/PA
a=of:101 flowid=7623 MPU
a=of:102 flowid=7624 MPU
a=of:103 flowid=7625 GF
a=of:104 flowid=7626 FEC
如上所示,客户端设备300(诸如MMT客户端)和服务器200(诸如MMT服务器)可以就媒体资产的类型以及可以交换这些资产的传输参数达成一致。
信令协议用于使用在服务器200和客户端设备300之间交换的多媒体数据来建立传输连接(TCP或UDP)。如图4所示,传输连接是客户端设备300和服务器200之间的一对一连接。可以通过传输连接传递的多媒体数据量受限于传输连接使用的网络接口的容量以及连接到该网络接口的网络的可用带宽。结果是,接收器处的最终用户体验取决于建立传输连接的网络路径的质量。如果网络路径性能不佳(诸如由于高分组丢失、拥塞等),最终用户体验可能直接受到例如与媒体缓冲、像素化等有关的问题的影响。
为了避免由于网络路径不佳而导致的这种问题,可以利用多路径功能来增强MMTP协议。可以在发送器和接收器之间建立使用多个网络接口的多个传输连接,因此数据可以以可靠的方式被更快地发送到目的地。此外,基于MMT接收器的反馈,如果MMT发送器识别出一个或更多个可能的网络路径表现不佳,则MMT发送器可以动态地改变网络路径。
图5示出根据本公开的MMT中用于多路径传递的示例架构图500。可以使用服务器200(诸如MMT发送器)和客户端设备300(诸如MMT接收器)上可用的不同网络接口在服务器200和客户端设备300之间建立多个传输连接505、510、515和520。多媒体数据流的不同分组流525、530、535和540(诸如不同类型的数据分组)可以在不同的传输连接505、510、515和520上被传递,从而使用可用于数据传递的多个网络接口(诸如路径)。如果在会话过程期间一个网络连接505(诸如路径)表现不佳,则可以选择不同网络连接510(诸如不同路径)用于随后的分组传递。结果是,一条网络路径性能不佳不会影响媒体传递的整体质量,对终端用户体验没有不利影响。
利用多路径传递,多个网络路径可以用于从服务器200向客户端设备300发送多媒体数据,反之亦然。由于多个网络路径的可用性,可以在相同的时间内将更多的多媒体数据传递到目的地。结果是,可用于数据传递的净带宽高于单个网络路径的任何带宽。如本文所讨论的,用于多路径的会话管理可以使用RTSP信令协议。例如,客户端设备300和服务器200可以通过向彼此发送OPTIONS请求来相互发现多路径能力支持。由于OPTIONS请求可以由服务器200和客户端设备300两者生成,因此OPTIONS请求成为查询多路径特征支持的良好候选模式。名为“多路径”的新选项标签可以通过互联网分配号码机构(IANA)进行注册,并且可以在OPTIONS请求的“require”报头中实现。以下是从客户端设备300到服务器200的询问多路径支持的简单OPTIONS请求的示例。
Figure BDA0001510245210000121
服务器200对OPTIONS请求的响应遵循如下面[[3]]中所示的标准响应机制。
Figure BDA0001510245210000131
上述OPTIONS请求可以由服务器200生成以询问来自客户端设备300的多路径支持,并且客户端设备300可以以适当的响应回应。请求和响应将遵循[[3]]中所规定的标准OPTIONS请求响应机制,同时支持上述新提出的称为“多路径”的选项标签。客户端设备300和服务器200可以启动具有多路径能力的会话建立,如本文进一步讨论的。然而,如果服务器200和客户端设备200都决定不使用多路径,则它们可以继续如[[3]]中所指示的标准会话建立过程。
在实施例中,可以使用多路径能力在客户端设备300(诸如MMT客户端设备)和服务器200(诸如MMT服务器)之间建立会话。图6示出根据本公开的使用RTSP的MMT会话建立的示例方法600。在步骤605中,客户端设备300向服务器200请求URL描述。客户端设备300包括称为“MultipathId”的新报头,以指示会话级别唯一标识符,使得服务器识别属于来自那个客户端设备300的相同多路径会话的所有连接。下面示出示例DESCRIBE。
Figure BDA0001510245210000132
对于如上所示的具有多路径标识符的DESCRIBE请求,在步骤610中,服务器200可以用具有称为“multipath”的新属性的SDP进行响应,以告诉客户端设备300服务器200支持多路径传递。多路径属性的语法如下所示。
Figure BDA0001510245210000141
如上述SDP所示,媒体描述不仅包括每个网络接口的连接信息,而且还包括对于每个网络接口各方愿意接收的数据类型。另外,用于每个媒体描述的SDP“control”属性将流id(如“streamid”参数所指示的)绑定到媒体行中指定的媒体格式(诸如有效载荷类型)。当客户端设备300读取该信息时,客户端设备300确定利用在相应的“control”属性中标识的每个流id可以提供什么资产类型(诸如由例如有效载荷类型的媒体格式描述规定的资产类型)。结果是,客户端设备300确定哪个流id要请求给定资产类型,并且在SETUP请求的请求URL中使用该流id。利用多路径传递,客户端设备300应当从客户端设备300的选择的网络接口生成建立请求。SETUP请求的生成由选择哪些资产类型必须在哪个网络接口上传递的策略来管理。结果是,客户端设备300使用所选网络接口与URL(例如,具有如上所示的对应于特定资产类型的流id信息)的组合来生成对特定网络接口上的特定资产类型的请求。这为使用特定类型的数据(诸如高质量视频)的特定类型的网络接口(诸如具有更高带宽的WiFi连接)带来了额外的优势。
基于从服务器200接收的多路径SDP,客户端设备300可以使用不同的网络接口来建立到服务器200(诸如MMT服务器)的多个连接(诸如网络路径)。例如,在步骤615、625和635,客户端设备300使用SETUP消息来设置每个网络路径。在每个SETUP请求中,客户端设备300包括指定客户端设备300想要接收媒体的路径的传输参数(诸如配置文件、目的地地址、客户端端口等)。另外,客户端设备300在对服务器200的SETUP请求的每一个中还包括称为“MultipathId”的新的报头,并且此后称为“客户端多路径标识符”。该报头字段的值与在本文讨论的DESCRIBE请求中使用的“MultipathId”报头字段的值相同。使用相同的值通知服务器200来自客户端设备300的SETUP请求属于与初始DESCRIBE请求相同的会话。另外,来自客户端设备300的客户端多路径标识符被绑定到网络和传输参数,因此客户端设备300可以稍后用于对来自不同网络路径的分组流进行分组。如果客户端设备300和服务器200想要使用多路径传递,则所有SETUP请求都包括“MultipathId”报头字段。
一旦服务器200接收到每个SETUP消息,在步骤620、630和640,服务器200可以在应答消息中使用服务器200自己的传输参数进行响应,以指定服务器200想要在哪儿接收媒体。此外,服务器200还包括被称为“MultipathId”的新报头,该报头包括作为由服务器200选择的唯一值的值,并且以后称为“服务器多路径标识符”。该值告诉客户端设备300来自具有相同服务器多路径标识符的服务器200的所有连接属于同一会话。此外,服务器多路径标识符绑定到网络和传输参数,因此服务器多路径标识符稍后可以用于将来自不同网络路径的分组流分组。在SETUP请求结束时,响应与具有相同客户端多路径标识符的所有客户端SETUP请求和具有相同服务器多路径标识符的服务器响应进行交换,客户端设备300和服务器200知道哪些网络路径属于同一会话。
在完成所有SETUP请求响应消息之后,在步骤645,客户端设备300然后请求播放流,并且服务器200使用不同的网络路径在协商的传输连接上播放流。由于传输连接参数被绑定到对应的客户端设备多路径标识符和服务器多路径标识符,因此在步骤650、655和660,客户端设备300和服务器200现在可以在不同的网络路径上接收数据分组流,并且仍然能够分组或关联来自不同网络路径的流。
在实施例中,客户端设备300(诸如MMT客户端设备)和服务器200可以意欲在会话期间使能或禁用对多路径的支持。另外,如果客户端设备300或服务器200已经在使用多路径,则可以在会话期间添加或者删除网络路径。当客户端设备300或服务器200想要在会话期间发起多路径支持时,它们中的任何一者可以使用RTSP信令协议开启用于数据分组数据交换的传输连接(TCP或UDP),而不使用多路径能力。对于发起多路径的客户端设备300,客户端设备300可以发出OPTIONS请求来检查服务器的多路径能力,如本文所讨论的。一旦从服务器接收到针对多路径能力的肯定响应,则客户端设备300可以发出具有修改后的传输参数的新的SETUP请求以使能如本文所述的多路径(现有流不需要被终止和显式地重新打开以修改流的传输参数[[3]])。然而,如果将要使用新的接口,则利用“MultipathId”报头从该新的接口发送新的SETUP请求。此报头的值与其他连接中使用的客户端多路径标识符相同。
对于发起多路径的服务器200,服务器200可以通过向客户端设备发送OPTIONS请求来检查多路径能力。服务器200然后可以发送ANNOUNCE消息来修改媒体描述以指定多路径能力(使用具有多路径属性的SDP)。如果客户端设备300选择使用多路径,则客户端设备300可以发送多个SETUP请求以使能本文描述的多路径传递。
在实施例中,如果客户端设备300和服务器200中的任一者已经在使用多路径支持,则可以添加或者放弃网络路径。例如,客户端设备300发送带有传输参数的新的SETUP请求,并为报头字段“Multipath”使用相同的值,以将新的网络路径添加到现有的多路径连接。客户端设备300也可以通过对相应的SETUP请求发出TEARDOWN请求来放弃网络路径,如[[3]]中所规定的。如果客户端设备300意欲在不同的网络路径上传输即将终止的网络路径的分组流,则客户端设备300可以使用对于另一个网络路径的修改被的SETUP请求来这样做。作为另一示例,服务器200可以通过宣布新的SDP然后通过请求客户端设备300基于修改后的SDP来建立连接来添加或者删除网络路径。
客户端设备300和服务器200可以在会话期间放弃多路径支持。客户端设备300可以通过拆除所有现有网络路径然后发布新的SETUP请求来这样做,如[[3]]中所规定的。可选地,客户端设备300还可以终止除了一个连接以外的所有连接,并且使用修改后的SETUP请求来修改剩余的连接。服务器200可以在ANNOUNCE消息中使用修改后的SDP(没有“多路径”属性)来放弃多路径支持。使用多路径支持建立的多个网络路径应该按照[[3]]中描述的单一会话终止机制逐个拆除。
对于多路径的支持在客户端设备300和服务器200之间是互斥的。换句话说,客户端设备300和服务器200可以实现多路径,而不管其他多路径传递的偏好。如果客户端设备300或服务器200不具有多个接口或者不希望使用多路径传递特征,则不必在其输出消息中包括“MultipathId”报头字段。然而,如果其他设备包括“MultipathId”报头,则不利用多路径的设备应该能够识别出其他设备正在请求多路径支持,因此应该能够将分组数据流传输到另一个设备的多个接口。
如本文所讨论的那样,已经建立了用于数据传递的多个路径,MMT发送器可以使用多个路径将数据发送到MMT接收器。当接收器从多个路径接收数据时,接收器可以在网络路径级别上计算QoS和QoE测量结果(诸如分组丢失、延迟、抖动等)。为了实现这一点,可以在分组到达接收器之前利用节点或路径信息对分组盖戳(在MMT发送器或在路径上的中间节点处)。MMT接收器可以以预定间隔计算每个流或每个网络路径QoS和QoE测量(路径质量信息),并将路径质量信息连同任何信道质量信息(诸如LTE链路上的链路无线质量)一起发送到MMT发送器。
图7示出根据本公开的多个网络路径中的每一个的接收器反馈的示图700的示例。该图显示了每个网络路径的三个度量(损失、延迟和抖动)。然而,接收器反馈可以扩展为包括每个网络路径的更多QoS和QoE度量。MMT规范可以包括对接收器反馈的支持。在实施例中,接收器反馈可以在网络路径级别上完成。作为接收器反馈的结果,MMT发送器变得意识到不同网络路径的条件。
基于MMT接收器反馈,MMT发送器可以全面了解双方不同网络路径的情况。发送器可以使用每个流(每个网络路径)的QoS和QoE测量结果来动态改变网络路径,以便可以通过性能更好的其他网络路径路由分组流。对于特定媒体类型的网络路径的确定是在从原始数据生成数据分组的情况下实时发生的。结果是,分组可以在具有更好的质量特性的网络路径上被传递到目的地,从而导致对接收器的最佳或改进的传递。应该注意,如果应用需求,则接收器反馈以及随后基于这样的反馈的动态路径更新可以以非常细粒度级别(诸如以分组为基础)进行。
还应该注意,由于数据分组流的网络路径可以在会话期间被改变,因此由于SDP具有绑定到网络路径的媒体类型,所以将导致与SDP不同步。为了解决这个问题,MMT发送器和MMT接收器可以在分组流实际上在新的网络路径上发出之前,发起修改传输参数和网络路径的中间会话改变,如本文所述的。在实施例中,网络路径的这种改变可以用适当的阈值来完成,以最小化对网络路径的频繁改变。
多路径可以使用重复的DESCRIBE消息进行设置。如这里所讨论的,MultipathId”报头字段可以被包括在DESCRIBE消息中。在发送DESCRIBE请求之前,客户端设备300可能未使用OPTIONS请求询问服务器200的多路径能力。在初始DESCRIBE请求之后,客户端设备300和服务器200仍然可以升级到多路径。例如,客户端设备300可以使用DESCRIBE请求向服务器200请求媒体描述,而没有用于设置标准RTSP会话的“MultipathId”报头,如[[3]]中所规定的。服务器200以具有主体描述的标准应答(没有“多路径”属性的SDP)进行响应。客户端设备300然后打算使用多路径。如本文所述,客户端设备300可以使用OPTIONS请求来向服务器200询问多路径能力。一旦接收到对多路径能力的肯定响应,则客户端设备300可以发送现在具有“MultipathId”报头字段的新的DESCRIBE请求。客户端设备300和服务器200可以随后进行如本文所述的多路径传递。
多路径也可以基于服务器通告进行设置。如这里所讨论的,“MultipathId”报头字段可以被包括在DESCRIBE消息中。在发送DESCRIBE请求之前,客户端设备300可能未使用OPTIONS请求询问服务器200的多路径能力。在初始DESCRIBE请求之后,客户端设备300和服务器200仍然可以升级到多路径。例如,客户端设备300使用DESCRIBE请求向服务器200请求媒体描述,而没有用于设置标准RTSP会话的“MultipathId”报头,如[[3]]中所规定的。服务器300以具有主体描述的标准应答(没有“多路径”属性的SDP)进行响应。客户端设备300然后打算使用多路径。如本文所述,客户端设备300可以使用OPTIONS请求来向服务器200询问多路径能力。服务器200可以使用ANNOUNCE消息来通告新的SDP。在接收到对多路径能力的肯定响应和新SDP时,客户端设备300可以开始发送现在具有“MultipathId”报头字段的每个请求的多个SETUP请求。客户端设备300和服务器200现在将进行如本文所述的多路径传递。
服务器200可以发起多路径。如这里所讨论的,“MultipathId”报头字段可以被包括在DESCRIBE消息中。在发送DESCRIBE请求之前,客户端设备300可能未使用OPTIONS请求询问服务器200的多路径能力。即使在初始DESCRIBE请求被发送到服务器200并且服务器200发起多路径设置之后,客户端设备300和服务器200仍然可以参与多路径传递。例如,客户端设备300使用DESCRIBE请求向服务器200请求媒体描述,而没有用于设置标准RTSP会话的“MultipathId”报头,如[[3]]中所规定的。服务器200看到客户端设备300没有指定“MultipathId”报头。服务器200仍然可以用包括“多路径”SDP属性的SDP来响应。服务器200还可以在对DESCRIBE请求的响应中发送服务器多路径标识符值。客户端设备300看到服务器200的指定的多路径能力。现在客户端设备300可以开始建立多个连接,如本文所述。从第一SETUP消息开始,客户端设备300可以开始在“MultipathId”报头字段中包括客户端多路径标识符值,然后继续使用本文描述的多路径。
HTTP可以用作建立多路径会话的信令协议。在此讨论,RTSP用作建立多路径会话的信令协议。可选地,HTTP可以用作建立多路径会话的信令协议。图8示出根据本公开的使用HTTP协议的MMT会话建立的示例方法800。在步骤805,客户端设备300使用HTTP升级到WebSocket连接从服务器200下载MMT分组,如[[11]]中所规定的。作为升级请求的一部分,客户端设备300包括“MultipathId”报头以告诉服务器200客户端设备200打算使用多路径传递特征。该报头字段的值是客户端设备300打算在所有后续数据分组请求中使用的客户端多路径标识符。在步骤810,响应于接收到HTTP升级到WebSocket,服务器200向客户端设备300发送具有服务器多路径标识符值的具有“MultipathId”报头的应答“200OK”。如步骤815和825所示,客户端设备300使用客户端设备300正用于多路径传递的每个接口的WebSocket连接。在步骤820和830,服务器200响应于接收到对于客户端设备300用于多路径传递的每个接口的HTTP升级到WebSocket,将具有服务器多路径标识符值的“MultipathId”报头的应答“200OK”发送到客户端设备300。每个GET请求包括“多路径”报头字段,因此服务器200知道多个输入GET请求是MMT数据分组数据的同一会话的一部分。WebSocket消息将被用于选项发现,诸如多路径能力、对给定网络接口的资产类型的协商等。在步骤835、840和845,数据通过相应的路径从服务器300发送到客户端设备200。
图9示出根据本公开的设备的多路径数据分组接收的示例过程的流程图。
在步骤905,设备向服务器发送消息。该消息包括对应于多路径传输会话并且指示设备的两个或更多个网络接入接口的组的标识符。设备确定由设备的两个或更多个网络接入接口中的第一网络接入接口接入的第一网络路径的一个或更多个第一特性。设备确定由设备的两个或更多个网络接入接口中的第二网络接入接口接入的第二网络路径的一个或更多个第二特征。设备生成指示在多路径传输会话期间由设备的两个或更多个网络接入接口的网络接入接口接入的网络路径的标识符。
在步骤910,设备基于两个或更多个网络接入接口的一个或更多个特性,在多路径传输会话期间通过设备的两个或更多个网络接入接口的任意组合来从服务器接收一个或更多个数据分组。设备将后续消息发送到服务器。后续消息包括对应于多路径传输会话并且指示设备的两个或更多个网络接入接口的后续组的另一个标识符。设备的两个或更多个网络接入接口的后续组与设备的两个或更多个网络接入接口的组不同。设备在多径传输会话期间通过设备的两个或更多个网络接入接口中的每一个从服务器接收一个或更多个后续数据分组。响应于在多路径传输会话期间发送从服务器接收一个或更多个数据分组的请求,在多路径传输会话期间设备通过设备的两个或更多个网络接入接口中的每一个从服务器接收一个或更多个数据分组。
图10示出根据本公开的服务器的多路径数据分组传输的示例过程的流程图。
在步骤1005,服务器从设备接收消息。该消息包括对应于多路径传输会话并且指示设备的两个或更多个网络接入接口的组的标识符,以在多路径传输会话期间从服务器接收一个或更多个数据分组。在多路径传输会话期间,服务器基于来自设备的请求来控制用于发送一个或更多个数据分组的两个或更多个网络路径的路径选择。服务器确定设备的两个或更多个网络接入接口中的第一网络接入接口接入的第一网络路径的一个或更多个第一特性。服务器确定设备的两个或更多个网络接入接口中的第二网络接入接口接入的第二网络路径的一个或更多个第二特性。服务器生成指示在多路径传输会话期间由设备的两个或更多个网络接入接口中的网络接入接口接入的两个或更多个网络路径的标识符。
在步骤1010,服务器在多路径传输会话期间通过对应于设备的两个或更多个网络接入接口的两个或更多个网络路径将一个或更多个数据分组发送到设备。服务器基于接收到的两个或更多个网络路径的特性,通过两个或更多个网络路径中的每一个将一个或更多个数据分组发送到设备。服务器将另一消息发送到设备。另一消息指示服务器支持通过两个或更多个网络路径传输一个或更多个数据分组。服务器接收到多路径传输会话的请求。服务器在多路径传输会话期间从服务器的两个或更多个网络接入接口并且通过设备的两个或更多个网络接入接口中的每一个将一个或更多个数据分组发送到设备。服务器接收至服务器的后续消息。后续消息包括对应于多路径传输会话并且指示设备的两个或更多个网络接入接口的后续组的另一个标识符。两个或更多个网络接入接口的后续组不同于设备的两个或更多个网络接入接口的组。服务器在多路径传输会话期间通过设备的两个或更多个网络接入接口中的每一个将一个或更多个后续数据分组发送到设备。
尽管已经用示例性实施例描述了本公开,但是本领域技术人员可以提出各种改变和修改。意在本公开包含落入所附权利要求的范围内的这种改变和修改。

Claims (14)

1.一种操作用于多路径数据分组接收的设备的方法,所述方法包括:
向服务器发送消息,其中,所述消息包括对应于多路径传输会话并且在多路径传输会话期间指示设备的两个或更多个网络接入接口的组的标识符;
基于设备的两个或更多个网络接入接口的至少一个质量信息,与服务器协商与两个或更多个网络接入接口相对应的两个或更多个网络路径,以接收一个或更多个数据分组,其中,通过比较至少一个质量信息与用于确定两个或更多个网络路径的阈值来执行两个或更多个网络路径的协商;以及
在多路径传输会话期间通过对应于两个或更多个网络接入接口的两个或更多个网络路径来从服务器接收一个或更多个数据分组。
2.根据权利要求1所述的方法,还包括:
确定由设备的两个或更多个网络接入接口中的第一网络接入接口接入的第一网络路径的一个或更多个第一特性;以及
确定由设备的两个或更多个网络接入接口中的第二网络接入接口接入的第二网络路径的一个或更多个第二特性。
3.根据权利要求1所述的方法,还包括:生成指示在多路径传输会话期间由设备的两个或更多个网络接入接口中的网络接入接口接入的网络路径的标识符。
4.根据权利要求1所述的方法,还包括:
向服务器发送后续消息,其中,所述后续消息包括对应于多路径传输会话并且指示设备的两个或更多个网络接入接口的后续组的另一标识符,所述后续组不同于设备的两个或更多个网络接入接口的所述组;以及
在多路径传输会话期间通过设备的两个或更多个网络接入接口中的每一个从服务器接收一个或更多个后续数据分组。
5.根据权利要求1所述的方法,还包括:响应于在多路径传输会话期间发送从服务器接收一个或更多个数据分组的请求,在多路径传输会话期间通过设备的两个或更多个网络接入接口中的每一个从服务器接收一个或更多个数据分组。
6.一种操作用于多路径数据分组传输的服务器的方法,所述方法包括:
从设备接收消息,其中,所述消息包括对应于多路径传输会话并且指示设备的两个或更多个网络接入接口的组的标识符,以在多路径传输会话期间从服务器接收一个或更多个数据分组;
基于设备的两个或更多个网络接入接口的至少一个质量信息,与服务器协商与两个或更多个网络接入接口相对应的两个或更多个网络路径,以接收一个或更多个数据分组,其中,通过比较至少一个质量信息与用于确定两个或更多个网络路径的阈值来执行两个或更多个网络路径的协商;以及
在多路径传输会话期间通过对应于设备的两个或更多个网络接入接口的两个或更多个网络路径将一个或更多个数据分组发送到设备。
7.根据权利要求6所述的方法,还包括:基于接收的两个或更多个网络路径的特性,通过两个或更多个网络路径中的每一个将一个或更多个数据分组发送到设备。
8.根据权利要求6所述的方法,还包括:在多路径传输会话期间,基于来自设备的请求,控制用于发送一个或更多个数据分组的两个或更多个网络路径的路径选择。
9.根据权利要求6所述的方法,还包括:
向设备发送另一消息,其中,所述另一消息指示服务器支持通过两个或更多个网络路径传输一个或更多个数据分组;
接收多路径传输会话的请求;以及
在多路径传输会话期间,从服务器的两个或更多个网络接入接口并且通过设备的两个或更多个网络接入接口中的每一个将一个或更多个数据分组发送到设备。
10.根据权利要求6所述的方法,还包括:
确定由设备的两个或更多个网络接入接口中的第一网络接入接口接入的第一网络路径的一个或更多个第一特性;以及
确定由设备的两个或更多个网络接入接口中的第二网络接入接口接入的第二网络路径的一个或更多个第二特性。
11.根据权利要求10所述的方法,还包括:生成指示在多路径传输会话期间由设备的两个或更多个网络接入接口中的网络接入接口接入的两个或更多个网络路径的标识符。
12.根据权利要求6所述的方法,还包括:
接收至服务器的后续消息,其中,所述后续消息包括对应于多路径传输会话并且指示设备的两个或更多个网络接入接口的后续组的另一标识符,所述后续组不同于设备的两个或更多个网络接入接口的所述组;以及
在多路径传输会话期间通过设备的两个或更多个网络接入接口中的每一个将一个或更多个后续数据分组发送到设备。
13.一种用于多路径数据分组接收的装置,所述装置被配置为执行权利要求1至5任一项所述的方法。
14.一种用于多路径数据分组发送的装置,所述装置被配置为执行权利要求6至12任一项所述的方法。
CN201680035343.9A 2015-06-16 2016-06-13 用于多路径媒体传递的方法和装置 Active CN107743698B (zh)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201562180404P 2015-06-16 2015-06-16
US62/180,404 2015-06-16
US15/001,018 US10069719B2 (en) 2015-06-16 2016-01-19 Method and apparatus for multipath media delivery
US15/001,018 2016-01-19
PCT/KR2016/006252 WO2016204468A1 (en) 2015-06-16 2016-06-13 Method and apparatus for multipath media delivery

Publications (2)

Publication Number Publication Date
CN107743698A CN107743698A (zh) 2018-02-27
CN107743698B true CN107743698B (zh) 2020-11-10

Family

ID=57545049

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201680035343.9A Active CN107743698B (zh) 2015-06-16 2016-06-13 用于多路径媒体传递的方法和装置

Country Status (6)

Country Link
US (1) US10069719B2 (zh)
EP (1) EP3311534B1 (zh)
JP (1) JP6618552B2 (zh)
KR (1) KR102519409B1 (zh)
CN (1) CN107743698B (zh)
WO (1) WO2016204468A1 (zh)

Families Citing this family (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6552303B2 (ja) * 2015-07-02 2019-07-31 キヤノン株式会社 通信装置および中継装置およびそれらの制御方法、プログラム
FR3053196A1 (fr) 2016-06-24 2017-12-29 Orange Procede de communication udp via des chemins multiples entre deux terminaux
FR3053197A1 (fr) * 2016-06-24 2017-12-29 Orange Procede de communication udp via des chemins multiples entre deux terminaux
FR3067550A1 (fr) * 2017-06-27 2018-12-14 Orange Procede de communication quic via des chemins multiples
US11196831B2 (en) * 2017-10-31 2021-12-07 Canon Kabushiki Kaisha Communication apparatus, communication method, and storage medium
CN108400937B (zh) * 2018-02-23 2020-06-23 北京交通大学 煤矿井下无线多媒体传感器网络区分服务的路由方法
US10887151B2 (en) 2018-10-05 2021-01-05 Samsung Eletrônica da Amazônia Ltda. Method for digital video transmission adopting packaging forwarding strategies with path and content monitoring in heterogeneous networks using MMT protocol, method for reception and communication system
US11431817B2 (en) 2018-12-04 2022-08-30 Samsung Electronics Co., Ltd. Method and apparatus for management of network based media processing functions
US10944647B2 (en) * 2019-01-24 2021-03-09 Vmware, Inc. Dynamic inter-cloud placement of virtual network functions for a slice
US10979314B2 (en) 2019-01-24 2021-04-13 Vmware, Inc. Dynamic inter-cloud placement of virtual network functions for a slice
US10892994B2 (en) 2019-05-14 2021-01-12 Vmware, Inc. Quality of service in virtual service networks
US10897423B2 (en) 2019-05-14 2021-01-19 Vmware, Inc. Congestion avoidance in a slice-based network
US11588733B2 (en) 2019-05-14 2023-02-21 Vmware, Inc. Slice-based routing
US11012288B2 (en) 2019-05-14 2021-05-18 Vmware, Inc. Congestion avoidance in a slice-based network
US10958579B2 (en) 2019-05-14 2021-03-23 Vmware, Inc. Congestion avoidance in a slice-based network
WO2021066445A1 (en) * 2019-10-01 2021-04-08 Samsung Electronics Co., Ltd. Method, apparatus and computer-readable recording medium for transmitting or receiving vpcc data
CN113872862B (zh) * 2020-06-30 2022-12-06 华为技术有限公司 通信方法、移动设备及路由设备
CN113347681B (zh) * 2021-05-31 2023-07-14 浙江大华技术股份有限公司 数据传输方法、装置、存储介质及电子装置
CN115707036A (zh) * 2021-08-11 2023-02-17 华为技术有限公司 传输数据的方法和装置
CN114285791B (zh) * 2021-12-17 2023-07-07 上海绚显科技有限公司 数据传输方法、装置、计算机设备及存储介质
CN117579544A (zh) * 2024-01-17 2024-02-20 杭州映云科技有限公司 一种多路径数据传输方法、系统、设备和存储介质

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8670326B1 (en) * 2011-03-31 2014-03-11 Cisco Technology, Inc. System and method for probing multiple paths in a network environment

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7386000B2 (en) * 2001-04-17 2008-06-10 Nokia Corporation Packet mode speech communication
US7606156B2 (en) 2003-10-14 2009-10-20 Delangis Eric M Residential communications gateway (RCG) for broadband communications over a plurality of standard POTS lines, with dynamic allocation of said bandwidth, that requires no additional equipment or modifications to the associated class 5 offices or the PSTN at large
FR2866768A1 (fr) * 2004-02-19 2005-08-26 France Telecom Procede d'acces a un service a travers un reseau d'acces multivoies
KR101210337B1 (ko) 2006-11-30 2012-12-10 삼성전자주식회사 이종 인터페이스 환경에서의 다중 경로 설정 장치 및 방법
US8417849B2 (en) 2009-10-07 2013-04-09 International Business Machines Corporation Apparatus and method to adjust a multi-path device reservation
US9197544B2 (en) 2011-10-19 2015-11-24 The Regents Of The University Of California Comprehensive multipath routing for congestion and quality-of-service in communication networks
US8640174B2 (en) * 2012-03-01 2014-01-28 Motorola Mobility Llc Method for retrieving content, wireless communication device and communication system
US8755389B1 (en) 2012-04-04 2014-06-17 Google Inc. Semi-centralized multiple path routing
KR102045073B1 (ko) 2013-01-24 2019-11-14 한국전자통신연구원 유연한 mmt 애셋 송수신 방법 및 그 장치
US9456464B2 (en) 2013-06-06 2016-09-27 Apple Inc. Multipath TCP subflow establishment and control
WO2015127294A1 (en) * 2014-02-21 2015-08-27 Broadcom Corporation Carrier aggregation over lte and wifi
EP3178220B1 (en) * 2014-08-06 2019-11-13 Nokia Solutions and Networks Oy Ipv6 interface id filter using a single pdn connection
US9681481B2 (en) * 2014-12-19 2017-06-13 At&T Intellectual Property I, L.P. Mobility management of wireless networks based on multipath transfer control protocol

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8670326B1 (en) * 2011-03-31 2014-03-11 Cisco Technology, Inc. System and method for probing multiple paths in a network environment

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
A multipath relay transport control method for real-time video service;LI GUANGYE ET AL;《2015 IEEE INTERNATIONAL CONFERENCE ON CYBER TECHNOLOGY IN AUTOMATION,CONTROL,AND INTELLIGENT SYSTEMS(CYBER),IEEE》;20150608;全文 *
Multipath RTP based on RTP RelayApplication (MPRTP-RA);W.LEI;W.ZHANG;S.LIU;NORTHEASTERN UNIVERSITY;《INTERNET ENGINEERING TASK FORCE, IETF》;20130312;第5节第15-20行,第8.2节第11-23行,第8.5节第6-8行,第12.2节第11-13行 *

Also Published As

Publication number Publication date
WO2016204468A1 (en) 2016-12-22
US10069719B2 (en) 2018-09-04
EP3311534B1 (en) 2021-04-28
CN107743698A (zh) 2018-02-27
EP3311534A1 (en) 2018-04-25
KR20180009046A (ko) 2018-01-25
JP2018524887A (ja) 2018-08-30
KR102519409B1 (ko) 2023-04-07
JP6618552B2 (ja) 2019-12-11
US20160373342A1 (en) 2016-12-22
EP3311534A4 (en) 2018-06-20

Similar Documents

Publication Publication Date Title
CN107743698B (zh) 用于多路径媒体传递的方法和装置
US11412018B2 (en) Distributing communication of a data stream among multiple devices
US10455404B2 (en) Quality of experience aware multimedia adaptive streaming
JP6279512B2 (ja) 適応ビデオ通信用システム及び方法
EP2740265B1 (en) System and method for adapting video communications
CN107210999B (zh) 链路感知流送自适应
US20200213371A1 (en) Network assistance for uplink streaming
US10425458B2 (en) Adaptive bit rate streaming with multi-interface reception
US10893234B2 (en) System and method of dynamic playback variation for multimedia communication
Zink et al. Scalable TCP-friendly video distribution for heterogeneous clients
KR102088294B1 (ko) 미디어 클라이언트로부터의 수신 상태정보에 기반한 적응적 미디어 전달 방법 및 이를 이용하는 장치
US9374603B1 (en) Systems and methods for providing content delivery over a backhaul link in a communication system

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant