CN111263102A - 一种基于延迟梯度累积的ViLTE视频通话拥塞控制方法及系统 - Google Patents

一种基于延迟梯度累积的ViLTE视频通话拥塞控制方法及系统 Download PDF

Info

Publication number
CN111263102A
CN111263102A CN202010374867.9A CN202010374867A CN111263102A CN 111263102 A CN111263102 A CN 111263102A CN 202010374867 A CN202010374867 A CN 202010374867A CN 111263102 A CN111263102 A CN 111263102A
Authority
CN
China
Prior art keywords
video
network
packet loss
delay
vilte
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.)
Granted
Application number
CN202010374867.9A
Other languages
English (en)
Other versions
CN111263102B (zh
Inventor
刘鹏飞
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.)
ASR Microelectronics Co Ltd
Original Assignee
Aojie Technology Shanghai 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 Aojie Technology Shanghai Co Ltd filed Critical Aojie Technology Shanghai Co Ltd
Priority to CN202010374867.9A priority Critical patent/CN111263102B/zh
Publication of CN111263102A publication Critical patent/CN111263102A/zh
Application granted granted Critical
Publication of CN111263102B publication Critical patent/CN111263102B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/14—Systems for two-way working
    • H04N7/141—Systems for two-way working between two video terminals, e.g. videophone
    • 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/47—End-user applications
    • H04N21/478—Supplemental services, e.g. displaying phone caller identification, shopping application
    • H04N21/4788—Supplemental services, e.g. displaying phone caller identification, shopping application communicating with other users, e.g. chatting
    • 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/643—Communication protocols
    • H04N21/6437—Real-time Transport Protocol [RTP]
    • 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/647—Control signaling between network components and server or clients; Network processes for video distribution between server and clients, e.g. controlling the quality of the video stream, by dropping packets, protecting content from unauthorised alteration within the network, monitoring of network load, bridging between two different networks, e.g. between IP and wireless
    • H04N21/64723—Monitoring of network processes or resources, e.g. monitoring of network load
    • H04N21/64738—Monitoring network characteristics, e.g. bandwidth, congestion level

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本申请公开了一种基于延迟梯度累积的ViLTE视频通话拥塞控制方法。步骤S10：收到每一个RTP数据包之后，计算出延迟梯度的累计值
Figure 100004_DEST_PATH_IMAGE002
。步骤S20：第一次出现丢包，就计算当前的网络传输信道容量
Figure 100004_DEST_PATH_IMAGE004
；
Figure 912670DEST_PATH_IMAGE004
=γ*
Figure 100004_DEST_PATH_IMAGE006
；随后视频接收端立即发送TMMBR消息给视频发送端，要求视频发送端降低视频编码码率；同时，视频接收端还将检测到丢包时的记录的延迟梯度累积值的最大值
Figure 100004_DEST_PATH_IMAGE008
作为丢包的延迟阈值。步骤S30：不再出现丢包，视频接收端将当前数据包的延迟梯度累积值和延迟阈值进行比较，判断出网络的拥塞状态，然后对数据传输速率进行调整。步骤S40：重复步骤S20至步骤S30，直至ViLTE视频通话的数据传输结束。本申请可在ViLTE视频通话过程中降低网络延迟、避免丢包发生和提升视频质量。

Description

一种基于延迟梯度累积的ViLTE视频通话拥塞控制方法及 系统
技术领域
本申请涉及一种ViLTE（Video over Long-Term Evolution，长期演进视频承载）视频通话实现方法，特别是涉及在ViLTE视频通话过程中通过计算RTP（Real-timeTransport Protocol，实时传输协议）数据包的延迟梯度（delayed gradient）累计值来判断出当前网络传输的状况、进而对ViLTE视频通话进行拥塞控制的方法。
背景技术
ViLTE视频通话系统包含视频发送端和视频接收端。视频发送端通过摄像头采集原始视频，并通过视频编码器将原始视频编码为利于网络传输的压缩视频流格式（如H.264），然后再将压缩视频流打包为RTP数据包并通过移动通信网络发送出去。视频接收端通过移动通信网络接收到RTP数据包后，从RTP数据包中提取出压缩视频流，再通过视频解码器进行解码并最终在屏幕上进行显示。
RTP数据包在移动通信网络中传输时，当RTP数据包的传输比特率高于移动通信网络所能提供的信道容量（Channel capacity）时，就会发生RTP数据包的“拥塞”（congestion）现象，导致RTP数据包被缓存在通信链路的节点中，引入较大的传输延迟（transmission delay）。当“拥塞”严重到一定程度，就会导致RTP数据包在网络传输中被丢弃，造成接收端视频质量的大幅下降。
在ViLTE视频通话过程中，为了减少网络拥塞、避免丢包，就需要一种拥塞控制算法来对移动通信网络的拥塞状态进行实时探测，并利用它来控制RTP数据包的传输。当探测到网络拥塞比较严重时，视频发送端就要降低视频编码码率以降低RTP数据流的传输比特率，进而缓解网络拥塞，以减少延迟避免丢包。当探测到网络拥塞比较轻微时，视频发送端就可以提高视频编码码率，以提升视频流的编码质量。
由于ViLTE视频通话采用移动通信网络传输RTP数据流，导致其拥塞控制算法的设计具有如下难点。第一，移动通信网络链路复杂，节点众多，缺少全局性的客观参数来表征整条链路的网络传输状态。这就要求拥塞控制算法另辟蹊径，能够化繁为简，从更高的维度上对网络链路进行建模，找到更精简的算子（operator）参数来表征网络的传输状态。第二，移动通信网络通话带宽的易变性、通信节点排队延迟以及通话终端的移动导致的通信链路变化，造成了移动通信网络状态的“瞬变性”。这就要求拥塞控制算法具备对拥塞状态走势的预测能力，能够在严重拥塞发生之前进行及时预测和应对。第三，RTP协议自身缺少对网络拥塞控制算法的标准定义。为了保证兼容性和易用性，就要求算法尽量在不修改原有的RTP协议的前提下进行拥塞控制。
目前已有一些算法用于实现RTP网络拥塞控制，比如GCC（Google CongestionContrl，谷歌拥塞控制）算法、NADA（Network Assisted Dynamic Adaptation，网络辅助动态适应）算法、SCReAM（Self-Clocked Rate Adaptation for Multimedia，多媒体自时钟速率适应）算法等。但是这些算法大多对标准的RTP和/或RTCP（RTP Control Protocol，RTP控制协议）协议进行了修改和增补，而这些修改目前还没有被3GPP正式采用。由于这些算法的实现依赖于“非标准的”RTP和/或RTCP协议，导致采用这些算法的终端在和使用标准RTP和/或RTCP协议的终端通信时，进行拥塞控制的效果会大幅下降甚至无法使用，兼容性较差。
发明内容
本申请所要解决的技术问题是在不修改标准RTP和RTCP协议的前提下，对网络拥塞状况进行实时预测，并据此控制RTP数据的传输。
为解决上述技术问题，本申请提出了一种基于延迟梯度累积的ViLTE视频通话拥塞控制方法，包括如下步骤。步骤S10：启动ViLTE视频通话的数据传输，视频接收端在接收到每一个RTP数据包之后，计算出延迟梯度的累计值
Figure DEST_PATH_IMAGE002
，并且记录在此过程中延迟梯度累计值的最大值
Figure DEST_PATH_IMAGE004
；每一次检测到丢包后一旦网络传输恢复正常，则将
Figure 794567DEST_PATH_IMAGE004
清零重新记录。步骤S20：当视频接收端检测到ViLTE视频通话的数据传输第一次出现丢包，就计算当前的网络传输信道容量
Figure DEST_PATH_IMAGE006
；
Figure 649391DEST_PATH_IMAGE006
= γ *
Figure DEST_PATH_IMAGE008
；
Figure 429128DEST_PATH_IMAGE008
是最近1秒内测量到的实际数据包接收码率，γ＜1；随后视频接收端立即发送TMMBR消息给视频发送端，要求视频发送端降低视频编码码率；同时，视频接收端还将检测到丢包时的记录的延迟梯度累积值的最大值
Figure 762020DEST_PATH_IMAGE004
作为丢包的延迟阈值。步骤S30：当视频接收端检测到ViLTE视频通话的数据传输不再出现丢包，视频接收端将当前数据包的延迟梯度累积值和延迟阈值进行比较，判断出网络的拥塞状态，然后对数据传输速率进行调整；直至视频接收端检测到ViLTE视频通话的数据传输再次出现丢包，则回到步骤S20。步骤S40：重复步骤S20至步骤S30，直至ViLTE视频通话的数据传输结束。上述基于延迟梯度累积的ViLTE视频通话拥塞控制方法（Accumulated DelayGradient based Dynamic Congestion Control Mechanism，简写为ADGDCCM），用于对移动通信网络的拥塞状态进行实时探测，并依据探测结果来对视频传输数据率进行调整，以避免丢包并提升视频质量。经实施验证，本申请可以很好地对ViLTE视频通话过程中的网络拥塞进行评估和预测，达到降低网络延迟、避免丢包发生和提升视频质量的目的。
进一步地，从第1个数据包到第n个数据包，延迟梯度的累计值
Figure 576393DEST_PATH_IMAGE002
的计算方法如下。
Figure DEST_PATH_IMAGE010
；其中，
Figure DEST_PATH_IMAGE012
表示当第n个数据包被加入到网络传输队列时，网络传输队列中所有数据包的长度总和；
Figure DEST_PATH_IMAGE014
表示当第n个数据包被加入到网络传输队列时，接收端的实际网络传输数据率。这是延迟梯度的累计值的一种计算方式。
进一步地，所述步骤S20采用的是基于丢包的拥塞控制策略；当检测到丢包发生时，使用实时的实际数据包接收码率来评估网络信道容量并对数据传输率进行调整，使网络传输恢复到正常状态。这是步骤S20的整体策略的说明。
进一步地，所述步骤S30采用的是基于延迟的拥塞控制策略；在每一个数据包到达时计算出到目前为止的延迟梯度累计值，并与丢包发生时的丢包延迟阈值进行比较，探测出网络拥塞状态并对数据传输率进行调整，以缓解拥塞并避免丢包的发生。这是步骤S30的整体策略的说明。
进一步地，所述步骤S30进一步包括如下步骤。步骤S31：利用
Figure DEST_PATH_IMAGE016
到
Figure DEST_PATH_IMAGE018
之间的延迟梯度累计值的最大值
Figure DEST_PATH_IMAGE020
，得到
Figure DEST_PATH_IMAGE022
之间的延迟阈值上限
Figure DEST_PATH_IMAGE024
和延迟阈值下限
Figure DEST_PATH_IMAGE026
；其中，
Figure DEST_PATH_IMAGE028
代表前一次遭遇网络丢包的时刻，
Figure DEST_PATH_IMAGE030
代表
Figure 208975DEST_PATH_IMAGE018
之后网络传输恢复正常的时刻，
Figure DEST_PATH_IMAGE032
代表
Figure 413691DEST_PATH_IMAGE030
之后又一次遭遇网络丢包的时刻。步骤S32：自
Figure 612591DEST_PATH_IMAGE030
开始，会在每一个RTP数据包到达时，计算其对应的延迟梯度累计值
Figure DEST_PATH_IMAGE034
，并将它与
Figure 219153DEST_PATH_IMAGE022
之间的的延迟阈值
Figure 212517DEST_PATH_IMAGE024
和
Figure 904529DEST_PATH_IMAGE026
进行比较。若
Figure 641541DEST_PATH_IMAGE034
≤
Figure 164926DEST_PATH_IMAGE026
，表示网络无拥塞。若
Figure 532454DEST_PATH_IMAGE034
≥
Figure 774079DEST_PATH_IMAGE024
，表示网络拥塞严重。若
Figure 49203DEST_PATH_IMAGE026
<
Figure 630357DEST_PATH_IMAGE034
<
Figure 965523DEST_PATH_IMAGE024
，表示网络拥塞处于正常状态。步骤S33：根据评估的网络拥塞状态，视频接收端通过发送RTCP的TMMBR消息来对视频发送端的视频编码码率进行调整以预防丢包。当网络无拥塞时，视频接收端通知视频发送端提高视频编码码率和RTP传输数据率。当网络拥塞严重时，视频接收端通知视频发送端降低视频编码码率RTP传输数据率。当网络拥塞处于正常状态时，视频发送端维持当前的视频编码码率和RTP传输数据率不变。这是步骤S30的一种具体实现方式的说明。
进一步地，所述步骤S31中，
Figure DEST_PATH_IMAGE036
，β<α<1；
Figure DEST_PATH_IMAGE038
，0<β<α。这是对步骤S31中如何计算
Figure 632128DEST_PATH_IMAGE022
之间的延迟阈值上限
Figure 710943DEST_PATH_IMAGE024
和延迟阈值下限
Figure 208920DEST_PATH_IMAGE026
的一种具体说明。
优选地，α= 0.8；β= 0.5。这是两个参数的优选取值。
进一步地，所述步骤S32中，基于延迟的拥塞控制策略总是在
Figure DEST_PATH_IMAGE040
（n>1）之间工作，即不发生丢包的时间段内工作；在发生丢包的时间段内，即
Figure 918250DEST_PATH_IMAGE018
至
Figure 868888DEST_PATH_IMAGE030
之间是基于丢包的拥塞控制策略在工作。这是本申请提出的两种拥塞控制策略按时间进行分工的说明。
进一步地，所述步骤S33中，当网络无拥塞时，视频发送端对编码比特率的调整为同时满足
Figure DEST_PATH_IMAGE042
= η*
Figure DEST_PATH_IMAGE044
, η＞1以及
Figure DEST_PATH_IMAGE046
, ε＞1。当网络拥塞严重时，视频发送端对编码比特率的调整为
Figure 617971DEST_PATH_IMAGE042
= δ *
Figure 970455DEST_PATH_IMAGE044
, δ＜1。当网络拥塞处于正常状态时，视频发送端对编码比特率的调整为
Figure 913003DEST_PATH_IMAGE042
=
Figure DEST_PATH_IMAGE048
其中，
Figure 288621DEST_PATH_IMAGE042
代表视频发送端对视频编码比特率的第i次调整值，
Figure DEST_PATH_IMAGE050
代表视频接收端实际测量出的视频编码比特率。这是对步骤S33中如何调整视频发送端的视频编码码率的一种具体说明。
本申请还提出了一种基于延迟梯度累积的ViLTE视频通话拥塞控制系统，包括计算单元、LBCC控制单元和DBCC控制单元。所述计算单元在接收到每一个RTP数据包之后，计算出延迟梯度的累计值
Figure 709238DEST_PATH_IMAGE002
，并且记录在此过程中延迟梯度累计值的最大值
Figure 119491DEST_PATH_IMAGE004
；每一次检测到丢包后一旦网络传输恢复正常，所述计算单元还将
Figure 232940DEST_PATH_IMAGE004
清零重新记录。所述LBCC控制单元用来在检测到ViLTE视频通话的数据传输每一次出现丢包后，计算当前的网络传输信道容量
Figure 158171DEST_PATH_IMAGE006
；
Figure 320162DEST_PATH_IMAGE006
= γ *
Figure 381659DEST_PATH_IMAGE008
；随后所述LBCC控制单元立即发送TMMBR消息给视频发送端，要求视频发送端降低视频编码码率；同时，所述LBCC控制单元还将检测到丢包时的记录的延迟梯度累积值的最大值
Figure 666010DEST_PATH_IMAGE004
作为丢包的延迟阈值。所述DBCC控制单元用来在检测到ViLTE视频通话的数据传输不再出现丢包后，将当前数据包的延迟梯度累积值和延迟阈值进行比较，判断出网络的拥塞状态，然后对数据传输速率进行调整以预防丢包；如果所述DBCC控制单元检测到ViLTE视频通话的数据传输再次出现丢包，则交由所述LBCC控制单元处理。根据检测到ViLTE视频通话的数据传输是否出现丢包，分别由所述LBCC控制单元、所述DBCC控制单元处理，直至ViLTE视频通话的数据传输结束。
相对于已有的拥塞控制算法，本申请的技术优势在于以下几方面。第一，可以实时探测移动通信网络的拥塞状态，并对即将可能发生的丢包进行提前预测，进而在丢包发生前对网络数据传输进行控制，达到避免丢包发生的目的。第二，网络模型抽象简单，模型算子精简可调，使用者可以根据实际应用中对视频数据的延迟、质量等要求来对算法算子进行适配调整。第三，基于标准的RTP和RTCP协议，不需要对RTP或RTCP协议进行修改，可以适配所有采用标准RTP和/或RTCP协议的移动通信设备，兼容性和移植性好。
附图说明
图1是本申请构建的移动通信网络传输模型的示意图。
图2是延迟梯度为正值的示意图。
图3是延迟梯度为负值的示意图。
图4是本申请提出的基于延迟梯度累积的ViLTE视频通话拥塞控制方法的流程图。
图5是图4中的步骤S30的详细流程图。
图6是图4所示方法的整体过程的曲线示意图。
图7是申请提出的基于延迟梯度累积的ViLTE视频通话拥塞控制系统的结构示意图。
图中附图标记说明：10为计算单元；20为LBCC控制单元；30为DBCC控制单元。
具体实施方式
本申请提出了一种基于延迟梯度累积的ViLTE视频通话拥塞控制方法，其主要原理是：通过计算RTP传输丢包时延迟梯度的累计值，推算出RTP包在网络传输队列中的最大延时，并以这个延时作为阈值和后续每个RTP包到达时的延迟梯度累计值进行比较，以判断出当前网络传输队列的状态，进而对视频传输比特率进行调整；在延时较高时降低比特率以避免网络传输队列溢出（丢包），在延时较低时提高比特率以提升视频编码质量。
为了实现这个目的，首先需要对网络传输链路进行建模。为了隐藏移动通信链路的复杂性，本申请将整个移动通信链路作为一个整体来进行考量。请参阅图1，这是本申请所构建的移动通信网络传输模型。发送端（Sender）的数据通过网络（Network）到达接收端（Receiver），当发送端产生数据的速度超过网络传输带宽时，数据包就会在网络传输队列中进行缓存。这些缓存，就构成了数据包在网络侧的延迟，它们所导致的网络传输性能下降的状态就是网络拥塞。而丢包则是当网络侧的缓存满了以后，新的数据包无法加入到缓存中，便只好丢弃。可见，在网络传输状况的检测上，使用延迟信息比使用丢包信息能够更早地发现网络拥塞。实际上，延迟信息表征了网络的“瞬时”拥塞状态（transientcongestion），而丢包信息表征了网络的“持续”拥塞状态（persistence congestion）。本申请就是利用延迟梯度信息来表征网络的拥堵程度，在发生丢包之前将网络拥塞及时地探测出来，并采取相应的手段来减少拥塞并避免丢包。
在图1所示的移动通信网络传输模型图中，有一些关键变量，其含义如下。
Figure DEST_PATH_IMAGE052
：网络传输队列的最大容量，单位为比特（bit）。在路由不变的情况下，
Figure 16219DEST_PATH_IMAGE052
是一个固定值。
Figure 44218DEST_PATH_IMAGE012
：当第n个数据包被加入到网络传输队列时，网络传输队列中所有数据包的长度总和，单位为比特。
Figure DEST_PATH_IMAGE054
：第n个数据包的长度，单位为比特。例如
Figure DEST_PATH_IMAGE056
是指第1个数据包的长度。
Figure 163484DEST_PATH_IMAGE014
：当第n个数据包被加入到网络传输队列时，接收端的实际网络传输数据率。
Figure DEST_PATH_IMAGE058
：当第n个数据包被加入到网络传输队列时，发送端的实际网络传输数据率。
Figure DEST_PATH_IMAGE060
：当第n个数据包被加入到网络传输队列时，发送端的发送数据率。可以近似认为
Figure DEST_PATH_IMAGE062
，不过
Figure 290840DEST_PATH_IMAGE058
是客观网络状况决定的，而
Figure 190663DEST_PATH_IMAGE060
则是可以调整的。
请参阅图2和图3，它们展示了数据包传输的延迟梯度。其中变量含义如下。
Figure DEST_PATH_IMAGE064
：发送端发出第i个数据包的时刻。
Figure DEST_PATH_IMAGE066
：接收端收到第i个数据包的时刻。
这样，对于第i个数据包
Figure DEST_PATH_IMAGE068
，其延迟梯度
Figure DEST_PATH_IMAGE070
的计算式如公式一所示。
Figure DEST_PATH_IMAGE072
（公式一）。图2中的延迟梯度
Figure 629210DEST_PATH_IMAGE070
为正值，图3中的延迟梯度
Figure 930878DEST_PATH_IMAGE070
为负值。
那么从第1个数据包到第n个数据包，延迟梯度的累计值
Figure 229136DEST_PATH_IMAGE002
的计算式如公式二所示。
Figure DEST_PATH_IMAGE074
（公式二）。
公式二中，
Figure DEST_PATH_IMAGE076
是一个定值，令其为γ。进而公式二可转换为公式三。
Figure DEST_PATH_IMAGE078
（公式三）。
当第j+1个数据包发生丢包时（假设第1个至第j个数据包未丢包），表明网络传输队列达到最大容量，有
Figure DEST_PATH_IMAGE080
（公式四），进而有公式五和公式六。
Figure DEST_PATH_IMAGE082
（公式五）。
Figure DEST_PATH_IMAGE084
（公式六）。
当第k（k > j+1）个数据包到达时，有公式七。
Figure DEST_PATH_IMAGE086
（公式七）。
若
Figure DEST_PATH_IMAGE088
，则有公式八。
Figure DEST_PATH_IMAGE090
（公式八）。
Figure DEST_PATH_IMAGE092
的物理意义是：第k个数据包从发送端发送到被接收端接收所用的时间，也就是第k个数据包的传输在网络侧的延迟。所以公式八的物理意义是，若
Figure 429304DEST_PATH_IMAGE088
，则可推导出：第k个数据包在网络中的传输延迟已经大于丢包时的网络传输延迟。换句话说，若
Figure 736789DEST_PATH_IMAGE088
发生，则第k个数据包预期将会发生丢包。在这种情况下，就需要提前降低发送端的发送数据率
Figure DEST_PATH_IMAGE094
，使网络中继端缓存的数据包更快地被消耗掉，以降低网络延迟并避免丢包。
可见，通过监测第k个数据包的延迟梯度的累计值
Figure DEST_PATH_IMAGE096
，并将它与丢包发生时的延迟梯度累计值
Figure DEST_PATH_IMAGE098
进行比较，就可以判断出当前网络的拥塞程度，并预测是否即将发生丢包。
在实践中，本申请所提出的的基于延迟梯度累积的拥塞控制方法会采用两个策略对网络拥塞进行探测和调整。
其中一个是基于丢包的拥塞控制策略（ADGDCCM Loss-Based CongestionControl，ADGDCCM-LBCC），主要用于对网络“持续”拥塞状态的调整。当检测到丢包发生时，会使用实时的实际数据包接收码率来评估网络信道容量并对数据传输率进行调整，使网络传输恢复到正常状态。需要注意的是，基于丢包的拥塞控制是一种滞后的调整策略，但是在ADGDCCM的实现中，丢包的出现是必须的（至少需要出现一次丢包），ADGDCCM需要利用丢包的发生来获取丢包延迟阈值供ADGDCCM-DBCC使用并切换到基于延迟的拥塞控制，从而在后续的传输过程中能够及时预测出网络拥塞并及时调整，以避免丢包的发生。
另一个是基于延迟的拥塞控制策略（ADGDCCM Delay-Based CongestionControl，ADGDCCM-DBCC），主要用于对网络“瞬时”拥塞状态的调整。在每一个数据包到达时，ADGDCCM会计算出到目前为止的延迟梯度累计值，并与丢包发生时的丢包延迟阈值进行比较，探测出网络拥塞状态并对数据传输率进行调整，以缓解拥塞并避免丢包的发生。
需要注意的是，在现有的RTP协议中，RTP数据包中并没有字段来直接描述数据包的发送时间，只能由RTP时间戳（timestamp）来替代。对于视频帧来说，一般是将一帧分割成多个RTP数据包来传输，属于同一帧的RTP数据包的RTP时间戳都是相同的，但是这些RTP数据包并不一定在同一时刻被发出。因而在计算视频数据包的延迟梯度时，仅使用每一帧的第一个RTP数据包的RTP时间戳信息来参与计算，准确度是最高的。从实验结果来看，使用RTP时间戳来代替RTP数据包的发送时间可以取得预期的效果。
请参阅图4，本申请提出的基于延迟梯度累积的ViLTE视频通话拥塞控制方法包括如下步骤。
步骤S10：启动ViLTE视频通话的数据传输，视频接收端在接收到每一个RTP数据包之后，计算出延迟梯度的累计值
Figure 565067DEST_PATH_IMAGE002
，并且记录在此过程中延迟梯度累计值的最大值
Figure 362122DEST_PATH_IMAGE004
。每一次检测到丢包后一旦网络传输恢复正常（即不再丢包），则将
Figure 911571DEST_PATH_IMAGE004
清零重新记录。
这一步是ADGDCCM未激活阶段，ADGDCCM的两个拥塞控制策略并没有被激活。
步骤S20：当视频接收端检测到ViLTE视频通话的数据传输第一次出现丢包，就按照公式九估计当前的网络传输信道容量
Figure 85063DEST_PATH_IMAGE006
。
Figure 95744DEST_PATH_IMAGE006
= γ *
Figure 1383DEST_PATH_IMAGE008
（公式九）。公式九中，
Figure 97515DEST_PATH_IMAGE006
是当前的网络信道容量，
Figure 809119DEST_PATH_IMAGE008
是最近1秒内测量到的实际数据包接收码率，γ＜1，例如取γ= 0.85。在计算出当前网络的信道容量
Figure 611990DEST_PATH_IMAGE006
以后，视频接收端立即发送TMMBR（Temporary MaximumMedia Stream Bit Rate Request，临时最大媒体流比特率请求）消息给视频发送端，要求视频发送端降低视频编码码率，从而将网络传输恢复到不再丢包的正常状态。同时，视频接收端还将检测到丢包时的记录的延迟梯度累积值的最大值
Figure 750848DEST_PATH_IMAGE004
作为丢包的延迟阈值，供后续基于延迟的拥塞控制策略（ADGDCCM-DBCC）使用。
这一步是基于丢包的拥塞控制策略（ADGDCCM-LBCC）拥塞控制阶段。
步骤S30：当视频接收端检测到ViLTE视频通话的数据传输不再出现丢包，视频接收端将当前数据包的延迟梯度累积值和延迟阈值进行比较，判断出网络的拥塞状态，然后对数据传输速率进行调整以预防丢包。直至视频接收端检测到ViLTE视频通话的数据传输再次出现丢包，则回到步骤S20。
这一步是基于延迟的拥塞控制策略（ADGDCCM-DBCC）拥塞控制阶段。
步骤S40：重复步骤S20至步骤S30，直至ViLTE视频通话的数据传输结束。
请参阅图5和图6，所述步骤S30采用ADGDCCM-DBCC具体包括如下步骤。图6中的横坐标为时间，纵坐标为延迟梯度累计值。
步骤S31：利用
Figure 334276DEST_PATH_IMAGE016
到
Figure 521675DEST_PATH_IMAGE018
之间的延迟梯度累计值的最大值
Figure 506948DEST_PATH_IMAGE020
，得到
Figure 816707DEST_PATH_IMAGE022
之间的延迟阈值上限
Figure 887431DEST_PATH_IMAGE024
和延迟阈值下限
Figure 878521DEST_PATH_IMAGE026
。其中，
Figure 718301DEST_PATH_IMAGE028
代表前一次遭遇网络丢包的时刻（如果是传输刚启动时，则
Figure DEST_PATH_IMAGE100
=0，
Figure DEST_PATH_IMAGE102
），
Figure 136644DEST_PATH_IMAGE030
代表
Figure 429085DEST_PATH_IMAGE018
之后网络传输恢复正常（不再丢包）的时刻（
Figure 223866DEST_PATH_IMAGE018
到
Figure 918152DEST_PATH_IMAGE030
之间由步骤S20采用ADGDCCM-LBCC来使网络传输恢复正常），
Figure 569713DEST_PATH_IMAGE032
代表
Figure 552713DEST_PATH_IMAGE030
之后又一次遭遇网络丢包的时刻。令
Figure 947922DEST_PATH_IMAGE020
代表
Figure 496715DEST_PATH_IMAGE016
到
Figure 519510DEST_PATH_IMAGE018
之间延迟梯度累计值的最大值。这样，利用
Figure 786543DEST_PATH_IMAGE020
就可以导出供后续
Figure 985444DEST_PATH_IMAGE022
之间的ADGDCCM-DBCC使用的延迟阈值上限
Figure 326426DEST_PATH_IMAGE024
和延迟阈值下限
Figure 585369DEST_PATH_IMAGE026
，如公式十和公式十一所示。
Figure 339699DEST_PATH_IMAGE036
，β<α<1 （公式十）。
Figure 14394DEST_PATH_IMAGE038
，0<β<α （公式十一）。
在
Figure 537779DEST_PATH_IMAGE030
和
Figure 967623DEST_PATH_IMAGE032
之间的延迟阈值上限
Figure 943669DEST_PATH_IMAGE024
和延迟阈值下限
Figure 937619DEST_PATH_IMAGE026
的物理意义如下。
Figure 518773DEST_PATH_IMAGE024
：当在
Figure 853940DEST_PATH_IMAGE030
和
Figure 582861DEST_PATH_IMAGE032
之间的每一个RTP包到达时，若其延迟梯度累积值高于
Figure 661676DEST_PATH_IMAGE024
时，表示当前的网络链路延迟已经很高，如果不降低视频传输码率，则不久之后就会发生网络丢包。
Figure 97336DEST_PATH_IMAGE026
：当在
Figure 603404DEST_PATH_IMAGE030
和
Figure 819622DEST_PATH_IMAGE032
之间的每一个RTP包到达时，若其延迟梯度累积值低于
Figure 702127DEST_PATH_IMAGE026
时，表示当前的网络链路延迟很低，网络链路带宽没有得到充分利用，发送端可以提高视频传输码率来提升视频质量。
在根据
Figure 992294DEST_PATH_IMAGE020
导出
Figure 934842DEST_PATH_IMAGE024
和
Figure 372777DEST_PATH_IMAGE026
时，算子α和β的取值是非常重要的。α设置越高，越有利于获取更高的视频质量，但网络延时会相应增大，算法对网络拥塞状态预估的及时性会降低。α设置越低（越靠近β），算法对网络拥塞状态预估的及时性会提高，但副作用是会降低对网络带宽的利用率并引入带宽调整振荡（频繁发出提升/降低带宽请求）。β设置越高（越靠近α），越容易引入带宽调整振荡。β设置越低，会降低对网络带宽的利用率，视频质量越差。在具体实践中，可以根据对视频传输的延迟、质量等要求，来优化调整α和β的取值。经过大量实际测试发现，α= 0.8和β= 0.5是比较合适的，可以在网络时延和视频质量之间取得折衷。
步骤S32：自
Figure 731077DEST_PATH_IMAGE030
开始，ADGDCCM-DBCC就会在每一个RTP数据包到达时，计算其对应的延迟梯度累计值
Figure 203647DEST_PATH_IMAGE034
，并将它与
Figure 51517DEST_PATH_IMAGE022
之间的的延迟阈值
Figure 976748DEST_PATH_IMAGE024
和
Figure 138739DEST_PATH_IMAGE026
进行比较，来对网络状况进行评估。若
Figure 465815DEST_PATH_IMAGE034
≤
Figure 750166DEST_PATH_IMAGE026
，表示网络无拥塞，视频接收端通知视频发送端提高视频编码码率（即提高RTP传输数据率），以提升视频质量。若
Figure 162692DEST_PATH_IMAGE034
≥
Figure 862795DEST_PATH_IMAGE024
，表示网络拥塞严重，视频接收端通知视频发送端降低视频编码码率，进而降低RTP传输数据率，以缓解网络拥塞，避免发生丢包。若
Figure 44378DEST_PATH_IMAGE026
<
Figure 499630DEST_PATH_IMAGE034
<
Figure 337136DEST_PATH_IMAGE024
，表示网络拥塞处于正常状态，视频发送端维持当前的视频编码码率和RTP传输数据率不变。
上一段描述的是ADBDCCM-DBCC的工作原理，ADGDCCM-DBCC总是在
Figure 903246DEST_PATH_IMAGE040
（n>1）之间工作，即不发生丢包的时间段内工作。在发生丢包的时间段内，即
Figure 939336DEST_PATH_IMAGE018
至
Figure 565489DEST_PATH_IMAGE030
之间是ADGDCCM-LBCC在工作。ADGDCCM-LBCC工作时对传输数据率的调整依据公式九进行，不会使用到
Figure 887361DEST_PATH_IMAGE026
或
Figure 991584DEST_PATH_IMAGE024
。在ADGDCCM-DBCC工作的时间段内，当接收到每一个RTP数据包时，会计算其对应的瞬时延迟梯度累积值，并与延迟阈值
Figure 147758DEST_PATH_IMAGE026
和
Figure 882496DEST_PATH_IMAGE024
进行比较，以判断是需要提升还是降低传输数据率。
步骤S33：根据评估的网络拥塞状态，对数据传输速率进行调整以预防丢包。视频接收端通过ADGDCCM-DBCC评估出当前网络的状态后，通过发送RTCP的TMMBR消息来对视频发送端的视频编码码率进行调整。令
Figure 491332DEST_PATH_IMAGE042
代表视频发送端对视频编码比特率的本次（第i次）调整值，
Figure 664824DEST_PATH_IMAGE050
代表视频接收端实际测量出的视频编码比特率，则调整方式如下。当
Figure 613189DEST_PATH_IMAGE034
≤
Figure 581145DEST_PATH_IMAGE026
时，表明网络处于未充分使用（underuse）状态，则视频发送端对编码比特率的调整为同时满足
Figure 677277DEST_PATH_IMAGE042
= η*
Figure 123302DEST_PATH_IMAGE044
, η＞1，例如取η=1.1,以及
Figure 191752DEST_PATH_IMAGE046
, ε＞1，例如取ε=1.3。当
Figure 330609DEST_PATH_IMAGE026
<
Figure 914037DEST_PATH_IMAGE034
<
Figure 163753DEST_PATH_IMAGE024
时，表明网络处于正常（normal）状态，则视频发送端对编码比特率的调整为
Figure 86710DEST_PATH_IMAGE042
=
Figure 396468DEST_PATH_IMAGE044
。当
Figure 467192DEST_PATH_IMAGE034
≥
Figure 458282DEST_PATH_IMAGE024
时，表明网络处于过度使用（overuse）状态，则视频发送端对编码比特率的调整为
Figure 298062DEST_PATH_IMAGE042
= δ *
Figure 778722DEST_PATH_IMAGE044
, δ＜1，例如取δ=0.9。当视频接收端检测到ViLTE视频通话的数据传输再次出现丢包，则回到步骤S20。
请参阅图7，本申请提出的基于延迟梯度累积的ViLTE视频通话拥塞控制系统包括计算单元10、LBCC控制单元20和DBCC控制单元30。
所述计算单元10在接收到每一个RTP数据包之后，计算出延迟梯度的累计值
Figure 71163DEST_PATH_IMAGE002
，并且记录在此过程中延迟梯度累计值的最大值
Figure 865944DEST_PATH_IMAGE004
。每一次检测到丢包后一旦网络传输恢复正常（即不再丢包），所述计算单元10还将
Figure 560230DEST_PATH_IMAGE004
清零重新记录。
所述LBCC控制单元20用来在检测到ViLTE视频通话的数据传输每一次出现丢包后，按照公式九估计当前的网络传输信道容量
Figure 211792DEST_PATH_IMAGE006
。
Figure 257108DEST_PATH_IMAGE006
= γ *
Figure 590000DEST_PATH_IMAGE008
（公式九）。随后所述LBCC控制单元20立即发送TMMBR消息给视频发送端，要求视频发送端降低视频编码码率，从而将网络传输恢复到不再丢包的正常状态。同时，所述LBCC控制单元20还将检测到丢包时的记录的延迟梯度累积值的最大值
Figure 138793DEST_PATH_IMAGE004
作为丢包的延迟阈值，供后续基于延迟的拥塞控制策略使用。
所述DBCC控制单元30用来在检测到ViLTE视频通话的数据传输不再出现丢包后，将当前数据包的延迟梯度累积值和延迟阈值进行比较，判断出网络的拥塞状态，然后对数据传输速率进行调整以预防丢包。如果所述DBCC控制单元30检测到ViLTE视频通话的数据传输再次出现丢包，则交由所述LBCC控制单元20处理。
根据检测到ViLTE视频通话的数据传输是否出现丢包，分别由所述LBCC控制单元20、所述DBCC控制单元30进行处理，直至ViLTE视频通话的数据传输结束。
本申请所提出ADGDCCM方法以及ADGDCCM-LBCC控制策略、ADGDCCM-DBCC控制策略已有代码实现并运用于实际产品中。经实测检验，可以很好地对ViLTE视频通话过程中的网络拥塞进行评估和预测，达到降低网络延迟、避免丢包发生和提升视频质量的目的，满足设计预期。
以上仅为本申请的优选实施例，并不用于限定本申请。对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (10)

1.一种基于延迟梯度累积的ViLTE视频通话拥塞控制方法，其特征是，包括如下步骤；
步骤S10：启动ViLTE视频通话的数据传输，视频接收端在接收到每一个RTP数据包之后，计算出延迟梯度的累计值
Figure DEST_PATH_IMAGE001
，并且记录在此过程中延迟梯度累计值的最大值
Figure 910293DEST_PATH_IMAGE002
；每一次检测到丢包后一旦网络传输恢复正常，则将
Figure 938292DEST_PATH_IMAGE002
清零重新记录；
步骤S20：当视频接收端检测到ViLTE视频通话的数据传输第一次出现丢包，就计算当前的网络传输信道容量
Figure DEST_PATH_IMAGE003
；
Figure 323137DEST_PATH_IMAGE003
= γ *
Figure 512810DEST_PATH_IMAGE004
；
Figure 865162DEST_PATH_IMAGE004
是最近1秒内测量到的实际数据包接收码率，γ＜1；随后视频接收端立即发送TMMBR消息给视频发送端，要求视频发送端降低视频编码码率；同时，视频接收端还将检测到丢包时的记录的延迟梯度累积值的最大值
Figure 431273DEST_PATH_IMAGE002
作为丢包的延迟阈值；
步骤S30：当视频接收端检测到ViLTE视频通话的数据传输不再出现丢包，视频接收端将当前数据包的延迟梯度累积值和延迟阈值进行比较，判断出网络的拥塞状态，然后对数据传输速率进行调整；直至视频接收端检测到ViLTE视频通话的数据传输再次出现丢包，则回到步骤S20；
步骤S40：重复步骤S20至步骤S30，直至ViLTE视频通话的数据传输结束。
2.根据权利要求1所述的基于延迟梯度累积的ViLTE视频通话拥塞控制方法，其特征是，从第1个数据包到第n个数据包，延迟梯度的累计值
Figure 732941DEST_PATH_IMAGE001
的计算方法如下；
Figure DEST_PATH_IMAGE005
；其中，
Figure 296778DEST_PATH_IMAGE006
表示当第n个数据包被加入到网络传输队列时，网络传输队列中所有数据包的长度总和；
Figure DEST_PATH_IMAGE007
表示当第n个数据包被加入到网络传输队列时，接收端的实际网络传输数据率。
3.根据权利要求1所述的基于延迟梯度累积的ViLTE视频通话拥塞控制方法，其特征是，所述步骤S20采用的是基于丢包的拥塞控制策略；当检测到丢包发生时，使用实时的实际数据包接收码率来评估网络信道容量并对数据传输率进行调整，使网络传输恢复到正常状态。
4.根据权利要求1所述的基于延迟梯度累积的ViLTE视频通话拥塞控制方法，其特征是，所述步骤S30采用的是基于延迟的拥塞控制策略；在每一个数据包到达时计算出到目前为止的延迟梯度累计值，并与丢包发生时的丢包延迟阈值进行比较，探测出网络拥塞状态并对数据传输率进行调整，以缓解拥塞并避免丢包的发生。
5.根据权利要求1所述的基于延迟梯度累积的ViLTE视频通话拥塞控制方法，其特征是，所述步骤S30进一步包括如下步骤；
步骤S31：利用
Figure 683897DEST_PATH_IMAGE008
到
Figure DEST_PATH_IMAGE009
之间的延迟梯度累计值的最大值
Figure 256961DEST_PATH_IMAGE010
，得到
Figure DEST_PATH_IMAGE011
之间的延迟阈值上限
Figure 147556DEST_PATH_IMAGE012
和延迟阈值下限
Figure DEST_PATH_IMAGE013
；其中，
Figure 400071DEST_PATH_IMAGE014
代表前一次遭遇网络丢包的时刻，
Figure DEST_PATH_IMAGE015
代表
Figure 212169DEST_PATH_IMAGE009
之后网络传输恢复正常的时刻，
Figure 385661DEST_PATH_IMAGE016
代表
Figure 396342DEST_PATH_IMAGE015
之后又一次遭遇网络丢包的时刻；
步骤S32：自
Figure 364298DEST_PATH_IMAGE015
开始，会在每一个RTP数据包到达时，计算其对应的延迟梯度累计值
Figure DEST_PATH_IMAGE017
，并将它与
Figure 929272DEST_PATH_IMAGE011
之间的的延迟阈值
Figure 640876DEST_PATH_IMAGE012
和
Figure 506064DEST_PATH_IMAGE013
进行比较；
若
Figure 97451DEST_PATH_IMAGE017
≤
Figure 680879DEST_PATH_IMAGE013
，表示网络无拥塞；
若
Figure 930595DEST_PATH_IMAGE017
≥
Figure 119131DEST_PATH_IMAGE012
，表示网络拥塞严重；
若
Figure 428889DEST_PATH_IMAGE013
<
Figure 499614DEST_PATH_IMAGE017
<
Figure 553020DEST_PATH_IMAGE012
，表示网络拥塞处于正常状态；
步骤S33：根据评估的网络拥塞状态，视频接收端通过发送RTCP的TMMBR消息来对视频发送端的视频编码码率进行调整以预防丢包；
当网络无拥塞时，视频接收端通知视频发送端提高视频编码码率和RTP传输数据率；
当网络拥塞严重时，视频接收端通知视频发送端降低视频编码码率RTP传输数据率；
当网络拥塞处于正常状态时，视频发送端维持当前的视频编码码率和RTP传输数据率不变。
6.根据权利要求5所述的基于延迟梯度累积的ViLTE视频通话拥塞控制方法，其特征是，所述步骤S31中，
Figure 845330DEST_PATH_IMAGE018
，β<α<1；
Figure DEST_PATH_IMAGE019
，0<β<α。
7.根据权利要求6所述的基于延迟梯度累积的ViLTE视频通话拥塞控制方法，其特征是，α= 0.8；β= 0.5。
8.根据权利要求5所述的基于延迟梯度累积的ViLTE视频通话拥塞控制方法，其特征是，所述步骤S32中，基于延迟的拥塞控制策略总是在
Figure 325990DEST_PATH_IMAGE015
至
Figure 618431DEST_PATH_IMAGE016
之间工作，n>1，即不发生丢包的时间段内工作；在发生丢包的时间段内，即
Figure 678791DEST_PATH_IMAGE009
至
Figure 373078DEST_PATH_IMAGE015
之间是基于丢包的拥塞控制策略在工作。
9.根据权利要求5所述的基于延迟梯度累积的ViLTE视频通话拥塞控制方法，其特征是，所述步骤S33中，当网络无拥塞时，视频发送端对编码比特率的调整为同时满足
Figure 24639DEST_PATH_IMAGE020
=η*
Figure DEST_PATH_IMAGE021
, η＞1以及
Figure 273217DEST_PATH_IMAGE022
, ε＞1；
当网络拥塞严重时，视频发送端对编码比特率的调整为
Figure 668427DEST_PATH_IMAGE020
= δ *
Figure 217220DEST_PATH_IMAGE021
, δ＜1；
当网络拥塞处于正常状态时，视频发送端对编码比特率的调整为
Figure 305261DEST_PATH_IMAGE020
=
Figure 24825DEST_PATH_IMAGE021
；
其中，
Figure 223725DEST_PATH_IMAGE020
代表视频发送端对视频编码比特率的第i次调整值，
Figure DEST_PATH_IMAGE023
代表视频接收端实际测量出的视频编码比特率。
10.一种基于延迟梯度累积的ViLTE视频通话拥塞控制系统，其特征是，包括计算单元、LBCC控制单元和DBCC控制单元；
所述计算单元在接收到每一个RTP数据包之后，计算出延迟梯度的累计值
Figure 830287DEST_PATH_IMAGE001
，并且记录在此过程中延迟梯度累计值的最大值
Figure 89230DEST_PATH_IMAGE002
；每一次检测到丢包后一旦网络传输恢复正常，所述计算单元还将
Figure 843559DEST_PATH_IMAGE002
清零重新记录；
所述LBCC控制单元用来在检测到ViLTE视频通话的数据传输每一次出现丢包后，计算当前的网络传输信道容量
Figure 580571DEST_PATH_IMAGE003
；
Figure 103956DEST_PATH_IMAGE003
= γ *
Figure 737063DEST_PATH_IMAGE004
；随后所述LBCC控制单元立即发送TMMBR消息给视频发送端，要求视频发送端降低视频编码码率；同时，所述LBCC控制单元还将检测到丢包时的记录的延迟梯度累积值的最大值
Figure 713109DEST_PATH_IMAGE002
作为丢包的延迟阈值；
所述DBCC控制单元用来在检测到ViLTE视频通话的数据传输不再出现丢包后，将当前数据包的延迟梯度累积值和延迟阈值进行比较，判断出网络的拥塞状态，然后对数据传输速率进行调整以预防丢包；如果所述DBCC控制单元检测到ViLTE视频通话的数据传输再次出现丢包，则交由所述LBCC控制单元处理；
根据检测到ViLTE视频通话的数据传输是否出现丢包，分别由所述LBCC控制单元、所述DBCC控制单元处理，直至ViLTE视频通话的数据传输结束。
CN202010374867.9A 2020-05-07 2020-05-07 一种基于延迟梯度累积的ViLTE视频通话拥塞控制方法及系统 Active CN111263102B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010374867.9A CN111263102B (zh) 2020-05-07 2020-05-07 一种基于延迟梯度累积的ViLTE视频通话拥塞控制方法及系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010374867.9A CN111263102B (zh) 2020-05-07 2020-05-07 一种基于延迟梯度累积的ViLTE视频通话拥塞控制方法及系统

Publications (2)

Publication Number Publication Date
CN111263102A true CN111263102A (zh) 2020-06-09
CN111263102B CN111263102B (zh) 2020-08-11

Family

ID=70955211

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010374867.9A Active CN111263102B (zh) 2020-05-07 2020-05-07 一种基于延迟梯度累积的ViLTE视频通话拥塞控制方法及系统

Country Status (1)

Country Link
CN (1) CN111263102B (zh)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111935441A (zh) * 2020-07-30 2020-11-13 北京佳讯飞鸿电气股份有限公司 一种网络状态检测方法及装置
CN112911650A (zh) * 2021-03-28 2021-06-04 高小翎 移动高清视频智能双向探测带宽控制系统
CN114025389A (zh) * 2021-11-01 2022-02-08 网易（杭州）网络有限公司 数据传输方法、装置、计算机设备及存储介质
CN114244778A (zh) * 2022-01-07 2022-03-25 平行云科技(北京)有限公司 一种QoE感知的WebRTC拥塞控制方法

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150124604A1 (en) * 2013-11-06 2015-05-07 Futurewei Technologies, Inc. Systems and Methods for Proactive Congestion Detection in Radio Access Networks
CN107171969A (zh) * 2016-03-07 2017-09-15 华为技术有限公司 一种数据传输方法、装置及系统
US20170331757A1 (en) * 2015-06-30 2017-11-16 Tencent Technology (Shenzhen) Company Limited Traffic control method, traffic control apparatus and server
CN108401128A (zh) * 2018-03-20 2018-08-14 宁波菊思网络科技有限公司 一种视频通话中的拥塞控制方法
CN109905326A (zh) * 2019-03-26 2019-06-18 武汉大学 一种基于拥塞程度因子的速率下降参数优化方法
EP3554022A1 (en) * 2016-12-30 2019-10-16 Huawei Technologies Co., Ltd. Packet transmission method, terminal, network device, and communication system
CN110855400A (zh) * 2019-11-29 2020-02-28 江苏方天电力技术有限公司 基于纠错码的自适应丢包恢复方法、计算设备及存储介质

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150124604A1 (en) * 2013-11-06 2015-05-07 Futurewei Technologies, Inc. Systems and Methods for Proactive Congestion Detection in Radio Access Networks
US20170331757A1 (en) * 2015-06-30 2017-11-16 Tencent Technology (Shenzhen) Company Limited Traffic control method, traffic control apparatus and server
CN107171969A (zh) * 2016-03-07 2017-09-15 华为技术有限公司 一种数据传输方法、装置及系统
EP3554022A1 (en) * 2016-12-30 2019-10-16 Huawei Technologies Co., Ltd. Packet transmission method, terminal, network device, and communication system
CN108401128A (zh) * 2018-03-20 2018-08-14 宁波菊思网络科技有限公司 一种视频通话中的拥塞控制方法
CN109905326A (zh) * 2019-03-26 2019-06-18 武汉大学 一种基于拥塞程度因子的速率下降参数优化方法
CN110855400A (zh) * 2019-11-29 2020-02-28 江苏方天电力技术有限公司 基于纠错码的自适应丢包恢复方法、计算设备及存储介质

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111935441A (zh) * 2020-07-30 2020-11-13 北京佳讯飞鸿电气股份有限公司 一种网络状态检测方法及装置
CN112911650A (zh) * 2021-03-28 2021-06-04 高小翎 移动高清视频智能双向探测带宽控制系统
CN114025389A (zh) * 2021-11-01 2022-02-08 网易（杭州）网络有限公司 数据传输方法、装置、计算机设备及存储介质
CN114025389B (zh) * 2021-11-01 2024-04-30 网易（杭州）网络有限公司 数据传输方法、装置、计算机设备及存储介质
CN114244778A (zh) * 2022-01-07 2022-03-25 平行云科技(北京)有限公司 一种QoE感知的WebRTC拥塞控制方法
CN114244778B (zh) * 2022-01-07 2023-11-21 平行云科技(北京)有限公司 一种QoE感知的WebRTC拥塞控制方法

Also Published As

Publication number Publication date
CN111263102B (zh) 2020-08-11

Similar Documents

Publication Publication Date Title
CN111263102B (zh) 一种基于延迟梯度累积的ViLTE视频通话拥塞控制方法及系统
US9455925B2 (en) Method, device, and system for self-adaptively adjusting data transmission rate
US6643496B1 (en) System, method, and apparatus for adjusting packet transmission rates based on dynamic evaluation of network characteristics
EP2255535B1 (en) Device and method for adaptation of target rate of video signals
JP4838143B2 (ja) 送信装置
KR100641159B1 (ko) Ｒｔｃｐ패킷 기반의 적응적 멀티미디어 데이터 전송률추정방법
JP5116845B2 (ja) リアルタイム通信システムにおけるジッタベースのメディアレイヤアダプテーション
US9538220B2 (en) Video streaming quality of experience degradation control using a video quality metric
CN102325274B (zh) 一种自适应网络带宽的视频流传输控制方法
EP1159719B1 (en) Jitter buffer and methods for control of same
EP2984790B1 (en) Voip bandwidth management
CN106331717B (zh) 视频码率自适应调整方法及发送端设备
US20130290492A1 (en) State management for video streaming quality of experience degradation control and recovery using a video quality metric
CN108401128B (zh) 一种视频通话中的拥塞控制方法
JP2001230809A (ja) 通信システム及び通信方法及び送信端末及び受信端末
US6456967B1 (en) Method for assembling a voice data frame
US20110299588A1 (en) Rate control in video communication via virtual transmission buffer
CN111935441B (zh) 一种网络状态检测方法及装置
US20100067430A1 (en) Relay apparatus and relay method
US7583707B2 (en) System, method and apparatus for controlling a network post-demultiplexing function
CN111726301B (zh) 一种实时视频中保证视频质量的拥塞控制方法及系统
CN112995048A (zh) 数据中心网络的阻塞控制与调度融合方法及终端设备
JP3622701B2 (ja) Ｖｏｉｐシステム及びそれに用いるサービス品質制御方法
TW202143679A (zh) 往返估算
US9439100B2 (en) System and method for dynamic rate adaptation based on real-time call quality metrics

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
CP01 Change in the name or title of a patent holder
CP01 Change in the name or title of a patent holder

Address after: 201203 No. 399, Keyuan Road, Zhangjiang High-tech Park, Pudong New Area, Shanghai

Patentee after: Aojie Technology Co., Ltd

Address before: 201203 No. 399, Keyuan Road, Zhangjiang High-tech Park, Pudong New Area, Shanghai

Patentee before: Aojie Technology (Shanghai) Co.,Ltd.

CP02 Change in the address of a patent holder
CP02 Change in the address of a patent holder

Address after: 201203 Floor 9, building 10, No. 399, Keyuan Road, China (Shanghai) free trade pilot zone, Pudong New Area, Shanghai

Patentee after: Aojie Technology Co., Ltd

Address before: 201203 No. 399, Keyuan Road, Zhangjiang High-tech Park, Pudong New Area, Shanghai

Patentee before: Aojie Technology Co., Ltd