CN113194509B - 一种基于QoS的多网络融合传输系统及传输方法 - Google Patents
一种基于QoS的多网络融合传输系统及传输方法 Download PDFInfo
- Publication number
- CN113194509B CN113194509B CN202110485620.9A CN202110485620A CN113194509B CN 113194509 B CN113194509 B CN 113194509B CN 202110485620 A CN202110485620 A CN 202110485620A CN 113194509 B CN113194509 B CN 113194509B
- Authority
- CN
- China
- Prior art keywords
- multicast
- data
- retransmission
- link
- mptcp
- 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
Links
- 230000005540 biological transmission Effects 0.000 title claims abstract description 111
- 238000000034 method Methods 0.000 title claims abstract description 42
- 238000005538 encapsulation Methods 0.000 claims abstract description 29
- 238000013461 design Methods 0.000 claims abstract description 9
- 238000005457 optimization Methods 0.000 claims abstract description 7
- 238000012790 confirmation Methods 0.000 claims description 33
- 238000012545 processing Methods 0.000 claims description 13
- 239000000872 buffer Substances 0.000 claims description 11
- 239000003795 chemical substances by application Substances 0.000 claims description 9
- 238000013500 data storage Methods 0.000 claims description 7
- 230000003139 buffering effect Effects 0.000 claims description 5
- 230000008569 process Effects 0.000 claims description 4
- 238000010367 cloning Methods 0.000 claims description 3
- 230000001960 triggered effect Effects 0.000 claims description 3
- 238000010276 construction Methods 0.000 claims description 2
- 238000004806 packaging method and process Methods 0.000 claims 3
- 238000001514 detection method Methods 0.000 claims 2
- 230000035945 sensitivity Effects 0.000 claims 2
- 230000002452 interceptive effect Effects 0.000 claims 1
- 238000012544 monitoring process Methods 0.000 claims 1
- 230000002776 aggregation Effects 0.000 abstract description 47
- 238000004220 aggregation Methods 0.000 abstract description 47
- 230000004927 fusion Effects 0.000 abstract description 23
- 230000007246 mechanism Effects 0.000 abstract description 10
- 230000003044 adaptive effect Effects 0.000 abstract description 5
- 238000005516 engineering process Methods 0.000 description 33
- 238000012360 testing method Methods 0.000 description 6
- 230000009977 dual effect Effects 0.000 description 5
- RTZKZFJDLAIYFH-UHFFFAOYSA-N Diethyl ether Chemical compound CCOCC RTZKZFJDLAIYFH-UHFFFAOYSA-N 0.000 description 4
- 238000004590 computer program Methods 0.000 description 3
- 230000010354 integration Effects 0.000 description 3
- 230000008859 change Effects 0.000 description 2
- 230000007547 defect Effects 0.000 description 2
- 230000010076 replication Effects 0.000 description 2
- 239000000523 sample Substances 0.000 description 2
- 238000004088 simulation Methods 0.000 description 2
- 239000002699 waste material Substances 0.000 description 2
- 238000013459 approach Methods 0.000 description 1
- 230000007812 deficiency Effects 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 239000000835 fiber Substances 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000008092 positive effect Effects 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
- H04W28/24—Negotiating SLA [Service Level Agreement]; Negotiating QoS [Quality of Service]
-
- 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
-
- 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
- H04L12/4633—Interconnection of networks using encapsulation techniques, e.g. tunneling
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/09—Mapping addresses
- H04L61/10—Mapping addresses of different types
- H04L61/103—Mapping addresses of different types across network layers, e.g. resolution of network layer into physical layer addresses or address resolution protocol [ARP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/02—Traffic management, e.g. flow control or congestion control
- H04W28/10—Flow control between communication endpoints
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Quality & Reliability (AREA)
- Computer Security & Cryptography (AREA)
- Mobile Radio Communication Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明属于多网络融合传输技术领域，公开了一种基于QoS的多网络融合传输系统及传输方法，基于QoS的多网络融合传输方法包括：业务类型分类；业务队列调度；MPTCP重传代理优化；组播按需调度实现；多链路组播重传实现；组播ARQ及重传设计。本发明在多链路环境下，提高终端用户TCP业务性能，设计基于业务流的调度方法及组播的自适应调度方法，满足终端用户对网络应用的高质量需求；将MPTCP传输机制应用到无线多网络融合中，把MPTCP多路径传输协议作为一体化终端与汇聚服务器间的一种隧道封装方式，利用MPTCP协议的拥塞控制、流量控制实现多链路协同调度能力，提高TCP业务系统整体吞吐并增强数据传输可靠性。
Description
技术领域
本发明属于多网络融合传输技术领域，尤其涉及一种基于QoS的多网络融合传输系统及传输方法。
背景技术
目前，在现有的无线多网络融合传输技术领域，在一体化终端和后端的汇聚服务器之间存在多条无线链路，利用IP over多IP隧道传输技术，IP业务流的统一承载，当两个设备之间的一条或者多条链路失效时，只要两个设备之间至少有一条链路联通时仍能保证与一体化终端相连用户与远端设备之间业务的连通性，实现用户IP业务流的大带宽和可靠传输，保证了用户业务的健壮性。
目前无线多网络融合传输方案是在一体化终端和后端的汇聚服务器之间用UDP协议作为隧道封装，每个一体化终端与后端的汇聚服务器建立多对接收和发送窗口大小相同的ARQ实体，用ARQ技术实现重传的IP over多IP隧道传输技术，发送方根据各条链路的固定带宽比例，轮流给各条链路分配一定数量的LLC帧；接收方在多个链路上冗余发送相同的LLC接收状态控制帧用作ARQ反馈，发送方根据对端ARQ反馈移动发送窗口；发送方根据接收到的LLC接收状态控制帧的序号字段对反馈的LLC接收状态控制帧中的否定确认是否有效，在个别链路的丢包情况下进行准确重传减少丢包。
MultiPathTCP(MPTCP)由互联网工程任务组(IETF)MultiPath TCP工作组研发，其目的是允许传输控制协议(TCP)连接使用多个路径来最大化信道资源使用。MPTCP拥有多路径自适应流量调度、多路径拥塞控制等优势特性，MPTCP可以为用户提供透明的多路径利用能力。MPTCP允许在一条TCP链路中建立多个子通道，当一条通道按照三次握手的方式建立起来后，可以按照三次握手的方式建立其他的子通道，这些通道以三次握手建立连接和四次握手解除连接。MPTCP为了保持每个子流中的序列号是连续的，给每个子流都分配了独立的序列号，保证每个子通道中的序号始终是连续。同时MPTCP通过增加DSN(Data SequenceNumber)来管理包的发送，DSN统计的是总的报文段序号，保持着一个全局的连接级别的序列号。当某一条流中数据发送失败后，根据其映射后的序列号找到连接级别的序列号，就可以找到发送失败的包，进而可以把这个包重新调度到别的子流中再进行发送。
MPTCP协议作为端到端的传输控制协议，天生具有多网络融合的能力，应用到多网络融合传输领域具有先天的优势。MPTCP还与传统TCP协议向后兼容，相比于适合传输视频、语音等信息的用UDP协议作为隧道封装的LLC over IP tunnel技术，MPTCP多路径传输技术更适合用来传输文件、信息等对可靠性要求高、对时延要求低的数据。
但是，现有的无线多网络融合技术存在以下不足：1)用UDP协议作为隧道封装、用ARQ技术实现重传的IP over多IP隧道传输技术，UDP协议本身不具有拥塞控制能力，实现多链路拥塞控制很困难。2)用UDP协议作为隧道封装、用ARQ技术实现重传的IP over多IP隧道传输技术，发送方根据各条链路的固定带宽比例轮流分配一定数量的业务数据，由于每条链路的实际带宽在实际环境中会动态变化，轮流分配方案导致某些链路数据量过载丢包，而有些链路又得不到充分利用导致系统整体传输性能下降。3)用户业务多种多样，经过统一的UDP隧道协议封装，没有提供区分业务优先级的机制，不能为不同应用提供不同质量的接入服务。4)在有多个一体化终端与后端的汇聚服务器建立连接的情况下，组播业务经过统一的UDP隧道封装后给每个一体化终端发送一份复本，而有些一体化终端下并不存在该组播组的用户，造成网络资源浪费。
为了满足终端用户对网络数据高质量、低时延的需求，把UDP和MPTCP同时作为多无线网络融合传输系统的隧道封装协议是必然的选择。
通过上述分析，现有技术存在的问题及缺陷为：
(1)用UDP协议作为隧道封装、用ARQ技术实现重传的IP over多IP隧道传输技术，UDP协议本身不具有拥塞控制能力，实现多链路拥塞控制很困难。
(2)现有用UDP协议作为隧道封装、用ARQ技术实现重传的IP over多IP隧道传输技术，由于每条链路的实际带宽在实际环境中会动态变化，轮流分配方案导致某些链路数据量过载丢包，而有些链路又得不到充分利用导致系统整体传输性能下降。
(3)用户业务多种多样，经过统一的UDP隧道协议封装，没有提供区分业务优先级的机制，不能为不同应用提供不同质量的接入服务。
(4)在有多个一体化终端与后端的汇聚服务器建立连接的情况下，组播业务经过统一的UDP隧道封装后给每个一体化终端发送一份复本，而有些一体化终端下并不存在该组播组的用户，造成网络资源浪费。
解决以上问题及缺陷的意义为：
上述多网融合采用UDP隧道加ARQ技术进行链路冗余备份虽然提高了业务的健壮性，ARQ技术也提供了部分流量控制的能力，但UDP协议本身没有拥塞控制机制和流量控制机制，不具有在多链路环境下自适应调度的能力，面对用户对网络多业务及高质量的要求能力明显不足，特别是对用户广泛应用的TCP业务的高可靠性传输处理能力不足，同时对多播业务缺乏灵活的调度策略，不能充分利用网络带宽资源。
本发明充分考虑现实网络中多种不同业务数据的特点，提出了基于QoS的多网络融合传输系统及传输方法，采用UDP和MPTCP双隧道技术方案，符合用户对网络高带宽、高可靠性和高质量的需求。
发明内容
针对现有无线多网络融合UDP隧道传输技术存在的问题，本发明提供了一种基于QoS的多网络融合传输系统及传输方法。
本发明是这样实现的，一种基于QoS的多网络融合传输方法，所述基于QoS的多网络融合传输方法包括以下步骤：
步骤一，进行业务类型分类；
步骤二，进行业务队列调度；
步骤三，进行MPTCP重传代理优化；
步骤四，进行组播按需调度实现；
步骤五，进行多链路组播重传实现；
步骤六，进行组播ARQ及重传设计。
进一步，步骤一中，所述业务类型分类，包括：
采用MPTCP和UDP双隧道传输技术方案，在一体化终端和汇聚服务器上采用相同的业务分类方法，基于用户数据业务主要分为TCP和UDP两大类型，将用户TCP业务数据使用MPTCP隧道传输，UDP业务数据使用UDP隧道传输。
对于截获的用户数据，首先按MAC地址分为单播、组播和广播三种类型，组播业务数据直接放入组播队列，广播业务不转发，仅对ARP请求作代理回复，单播业务数据根据IP类型分为TCP和UDP，TCP业务数据放入背景流队列，在UDP类型中通过RTP报文头信息带有的某些特点和信息识别出音视频流放入音视频流队列，其它业务数据放入尽力而为流队列。
进一步，步骤二中，所述业务队列调度，包括：
所述业务调度遵循重传优先，时间敏感优先的原则，包括：
(1)按重传优先的原则，根据ARQ LLC接收状态控制帧进行数据帧重传，并记录重传次数，对音视频流、组播数据进行一次重传；尽力而为类型数据最多重传二次。
(2)音视频流对时间敏感高，接着调度音视频流队列，放入相应的ARQ发送窗口，封装后通过UDP隧道发送。
(3)组播队列调度，放入相应的组播ARQ发送窗口，通过LLC封装后由UDP隧道发送。
(4)背景流队列调度，直接通过MPTCP隧道发送。
进一步，步骤三中，所述MPTCP重传代理优化，包括：
通过MPTCP重传代理，在发送时缓冲发送数据帧，收到肯定确认就回收缓冲，收到否定确认就进行代理重传，此否定确认帧不提交TCP协议栈，使丢包处理不会出现在TCP层，从而不会触发拥塞控制。
对MPTCP进行跟踪，以实现在每一条链路上对MPTCP通道的跟踪，从而知道每次丢包是在哪条TCP通道，从而构建起缓冲发送数据帧的重传代理发送窗口，当需要重传时，选择一条时延最小的链路发送重传帧，将重传帧以最快的速度发送到对端，以免发送端启动超时重传。
进一步，步骤四中，所述组播按需调度实现，包括：
在组播技术的目的是以尽为而为的方式向目标组发送信息，源主机向多点目标主机只发送一份数据，数据的目的地址是组播地址，凡是属于该组的用户都可以接收到一份源主机发送的数据。在无线多网络融合的条件下，当组播数据到达汇聚服务器后要经过封装后再发送到一体化终端，如果对所有一体化终端都复制一份数据，会因为数据包的多次重复而浪费带宽资源；同时，汇聚服务器的负荷会因为多次的数据复制而加大，对系统整体性能影响较大。
在多网络融合系统中可以把汇聚服务器当作路由器，IGMP Snooping是用来监听用户终端与路由器设备之间的IGMP报文，在汇聚服务器上使能IGMP Snooping功能，二层设备会侦听主机和路由器之间交互的IGMP报文，建立和维护二层组播转发表，从而指导组播数据帧在数据链路层按需转发。
在汇聚服务器上调度组播数据时，通过组播IP查找IGMP Snooping转发表确定属于该组播组的终端IP，在一体化终端与汇聚服务器交互过程中在汇聚服务器中建立IP与一体化终端的对应关系表，在汇聚服务器上通过终端IP查询到对应的一体化终端，并将该组播通过UDP隧道封装后发送到相应的一体化终端。
进一步，步骤五中，所述多链路组播重传实现，包括：
(1)单链路单播重传组播，组播重传包在多链路中的其中一条链路上经过UDP隧道封装后重传；
(2)多链路单播冗余重传组播，组播重传包在多链路上经过UDP隧道封装后复制多份进行多路重传；
(3)多链路组播冗余重传一次组播，残余的未到达组播包再进行单播重传，当要多用户需要对数据进行组播重传时，在多条链上直接用组播的方式发送重传包，接收发收到冗余的组播包去重，如果仍有部分组播未能收到，可以用单播的方式再进行重传。
(4)MPTCP隧道发送重传组播，在对时延不敏感，对可靠性要求高的场景下，利用MPTCP隧道封装后进行重传。
进一步，步骤六中，所述组播ARQ及重传设计，包括：
汇聚服务器的一个组播ARQ实体对应多个一体化终端的组播ARQ实体；为了应对多个一体化终端与汇聚服务器之间RRT时间的差异，汇聚服务器的组播ARQ实体窗口长度比对应的一体化终端更长；由于汇聚服务器与一体化终端之间的ARQ实体是一对多的关系，当收到一体化终端LLC接收状态控制帧时，汇聚服务器不会移动发送窗口，如果收到LLC接收状态控制帧为否定确认，则重传对应序号的组播帧；当发送窗口填满后发送序号重新开始编号，并释放窗口中原有的组播帧。
进一步，所述基于QoS的多网络融合传输方法，还包括：
(1)发送方和接收方之前有多条链路，搭建环境采用三条链路来进行实现，分别为链路1、链路2和链路3，且每条的链路时延和带宽均不相同。
(2)一体化终端在启动后与汇聚服务器建立两种多链路传输隧道，一种是MPTCP多链路传输隧道，一种是UDP多链路传输隧道，并启动MPTCP的三条链路的连接跟踪表，保存经由各条链路发送的经过隧道封装后的TCP数据帧。
(3)一体化终端从三条链路向汇聚服务器发送探测请求包，并记录发送时间，汇聚服务器收到后立即回复，一体化终端根据接收时间可以计算出每条链路的RRT时间。
(4)一体化终端捕获来自PC1的数据包，对数据包的业务类型进行分类,分类后的数据放入对应的业务包缓冲队列。
目的MAC地址为FF-FF-FF-FF-FF-FF为广播包，只处理以太类型为0x0806的ARP请求帧，一体化终端代理回复所有终端的ARP请求。
目的MAC地址为01-00-5E-xx-xx-xx为组播包，将数据帧存入组播流队列。
单播包通过IP协议类型区分TCP和UDP类型，协议类型为0x06为TCP类型，将数据帧存入背景流队列；在UDP类型中判断为RTP类型的存入音视频流队列，其它的UDP数据存入尽力而为流队列。
(5)LLC接收状态控制帧处理，作为ARQ反馈，根据反馈位图对肯定确认的数据作释放处理，对否定确认的数据帧作重传处理。
(6)业务包缓冲队列调度，调度程序依次调度音视频流队列、组播队列、尽力而为流队列、背景流队列；组播队列调度时根据组播IP查询IGMP Snooping表查询哪些IP用户属于该组播，再通过UDP隧道封装后发送到一体化终端。
(7)MPTCP连接跟踪表的建立，按源IP、PORT和目的IP、PORT四元组作为一条连接跟踪表的入口，跟踪表中有两个指向数据帧记录的指针，一个指向第一条数据帧记录，一个指向最后一条数据帧记录。
(8)当通过MPTCP发送数据时，通过对比四元组找到连接跟踪表的入口，首先建立一条数据帧记录用于记录当前数据帧；其中，所述数据帧记录包含数据存储指针、发送序号、数据长度、数据确认次数、等待确认序号以及下一数据记录指针。
(9)数据存储指针通过克隆源数据SKB结构头实现，发送序号为TCP头中的序号，数据长度为TCP负载长度，初始数据确认次数为0，等待确认序号为发送序号加上数据长度之和，下一数据记录指针为空指针，并将此数据帧记录插入连接跟踪表尾部。
(10)接收到MPTCP链路的TCP ACK，按源IP、PORT和目的IP、PORT四元组找到连接跟踪表项，从TCP ACK帧中取出确认序号，从连接跟踪表项中的第一个数据帧记录开始比对等待确认序号，如果不相等则释放对应在MPTCP相应的数据帧记录，并将该ACK包正常提交协议栈；如果序号相等，将数据帧记录中的数据确认次数加1。
(11)如果数据确认次数大于1则表明发送的报文段丢失，需要重传，选择时延最小的链路将记录的数据帧尽快发送到对端，该TCP ACK帧不再提交协议栈；否则直接将该TCPACK帧提交协议栈。
(12)接收到UDP隧道的数据包，如果是新重的则放入接收ARQ窗口，如果是重复的则直接丢弃；如果ARQ窗口中的数据包是按序接收，则将按序数据提交协议栈，否则不提交，等待重传或者超时后再提交协议栈。
(13)生成音视频流ARQ和尽力而为流ARQ的LLC接收状态控制帧,并通过RRT最小的链路发送到对端，不管是否按序接收都发送LLC接收状态控制帧。
(14)如果组播ARQ接收到乱序的组播包，则立即通过时延最小的链路发送LLC接收状态控制帧，向汇聚服务器请求重传丢失的帧；如果是按序接收则不用发送LLC接收状态控制帧。
本发明的另一目的在于提供一种应用所述的基于QoS的多网络融合传输方法的基于QoS的多网络融合传输系统，所述基于QoS的多网络融合传输系统，包括：一体化终端、网口、PC、CPE、WIFI设备、电信LTE基站、移动LTE基站、路由器以及汇聚服务器。
本发明的另一目的在于提供一种信息数据处理终端，所述信息数据处理终端用于实现所述的基于QoS的多网络融合传输系统。
结合上述的所有技术方案，本发明所具备的优点及积极效果为：本发明提供的基于QoS的多网络融合传输方法，在现有无线多网络融合传输技术上进行改进，采用MPTCP和UDP双隧道作为一体化终端与汇聚服务器之间的隧道传输技术。为实现多链路IP业务融合传输的按序送达和重传，本发明除了利用UDP协议作为隧道封装的多链路ARQ机制实现重传的LLC over IP tunnel技术，另一条技术路线就是用MPTCP协议作为隧道封装的技术。
本发明根据无线多链路传输方案在实验室搭建了模拟环境，验证了基于QoS的多网络融合传输方法的大带宽和可靠传输。本发明提出了将MPTCP和UDP同时作为隧道封装技术应用到无线多网络融合传输系统，并且设计了一种MPTCP重传代理装置，在多链路环境下，极大的提高了终端用户的TCP业务性能，同时设计了基于业务流的调度方法以及组播的自适应调度方法，满足了终端用户对网络应用的高质量需求，还具有以下优点：
(1)将MPTCP传输机制应用到无线多网络融合中，把MPTCP多路径传输协议作为一体化终端与汇聚服务器之间的一种隧道封装方式，可以利用MPTCP协议本身具有的拥塞控制、流量控制实现多链路协同调度能力，提高TCP业务系统整体吞吐并增强数据传输可靠性。
(2)通过改良MPTCP的重传机制，提高整体发送性能。MPTCP具有拥塞控制能力，当发生重传时就认为网络发生了拥塞，拥塞窗口会变小，TCP协议将拥塞窗口作为发送窗口，当发送窗口变小时发送流量会下降。无线网络抗干扰性较弱，网络会出现丢包现象，这种丢包并不是因为网络出现拥塞，实现一种MPTCP的重传代理方法，发送方在MAC层截获TCP确认帧并获取重传信息，在MAC层做一次重传代理，因为TCP层的重传会触发拥塞控制机制使TCP的传输性能下降，通过MAC层的重传代理减少发送方触发拥塞控制。
(3)建立优先级队列，不同业务类型采用不同的隧道封装技术及调度策略。本系统建立四个优先级队列，从高到低的顺序分为音视频流队列、组播队列、尽力而为流队列、背景流四个优先级队列，多网络融合QoS能针对各种不同需求，提供不同的网络服务质量。对实时性及可靠性要求高的数据报文提供更好的服务质量，并进行优先处理；而对于实时性不强的普通数据报文，则提供较低的处理优先级。
(4)组播业务实现按需调度。在汇聚服务器侧通过对IP包的识别判断，可以判断哪些数据为组播业务数据，然后通过查询系统的IGMP Snooping表可知哪些用户IP地址属于该组播组，用户IP地址都会对应到一个所属的一体化终端，从而可以实现把组播业务精准的从汇聚服务器发送到一体化终端，节省了带宽资源。
(5)组播自适应ARQ重传。通过对发送ARQ滑动窗口中已发送完成的数据按链路进行统计，可以得到发送数据包数及重传数，如果一条链路重传比例上升，则表明当前链路发生了拥塞，在进行组播重传时选择其它链路传输。
附图说明
为了更清楚地说明本发明实施例的技术方案，下面将对本发明实施例中所需要使用的附图做简单的介绍，显而易见地，下面所描述的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下还可以根据这些附图获得其他的附图。
图1是本发明实施例提供的基于QoS的多网络融合传输方法流程图。
图2是本发明实施例提供的基于QoS的多网络融合传输系统结构示意图。
具体实施方式
为了使本发明的目的、技术方案及优点更加清楚明白，以下结合实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。
针对现有技术存在的问题，本发明提供了一种基于QoS的多网络融合传输系统及传输方法，下面结合附图对本发明作详细的描述。
如图1所示，本发明实施例提供的基于QoS的多网络融合传输方法包括以下步骤：
进行业务类型分类；
进行业务队列调度；
进行MPTCP重传代理优化；
进行组播按需调度实现；
进行多链路组播重传实现；
进行组播ARQ及重传设计。
如图2所示，本发明实施例提供的基于QoS的多网络融合传输系统，包括：一体化终端、网口、PC、CPE、WIFI设备、电信LTE基站、移动LTE基站、路由器以及汇聚服务器。
下面结合实施例对本发明的技术方案作进一步描述。
实施例1
针对无线多网络融合UDP隧道传输技术存在的问题，本发明采用MPTCP和UDP双隧道作为一体化终端与汇聚服务器之间的隧道传输技术。为实现多链路IP业务融合传输的按序送达和重传，除了前文分析的利用UDP协议作为隧道封装的多链路ARQ机制实现重传的LLC over IP tunnel技术，另一条技术路线就是用MPTCP协议作为隧道封装的技术。
1.业务类型分类
互联网业务的多样化和快速增长，保证信息传输的质量已成为一个不容忽视的问题。不同类型的业务具有不同的特性，实时视频和话音业务对传输时延和时延抖动十分敏感，但对数据的丢失却有一定的忍耐度，这种业务不适合使用TCP协议作为隧道封装；相反，普通的数据业务对时延和时延抖动感觉不太敏感，但对数据本身的丢失和差错却不能容忍。所以对不同业务进行区别控制，对业务进行QoS分类，提高用户的使用体验。
本发明采用MPTCP(MultiPathTCP)和UDP双隧道传输技术方案，在一体化终端和汇聚服务器上采用相同的业务分类方法，基于用户数据业务主要分为TCP和UDP两大类型，将用户TCP业务数据使用MPTCP隧道传输，UDP业务数据使用UDP隧道传输。
对于截获的用户数据，首先按MAC地址分为单播、组播、广播三种类型，组播业务数据直接放入组播队列，广播业务不转发，仅对ARP请求作代理回复，单播业务数据根据IP类型分为TCP和UDP，TCP业务数据放入背景流队列，在UDP类型中通过RTP报文头信息带有的某些特点和信息识别出音视频流放入音视频流队列，其它业务数据放入尽力而为流队列。
2.业务队列调度
业务调度遵循重传优先，时间敏感优先的原则。
1)按重传优先的原则，根据ARQ LLC接收状态控制帧进行数据帧重传，并记录重传次数，对音视频流、组播数据进行一次重传；尽力而为类型数据最多重传二次。
2)音视频流对时间敏感高，接着调度音视频流队列，放入相应的ARQ发送窗口，封装后通过UDP隧道发送。
3)组播队列调度，放入相应的组播ARQ发送窗口，通过LLC封装后由UDP隧道发送。
4)背景流队列调度，直接通过MPTCP隧道发送。
4.MPTCP重传代理优化方案
无线链路质量比有线链路差，无线网络丢包比较严重，而丢包会导致重传。因为MPTCP的核心还是TCP技术，而TCP协议下的丢包重传会触发TCP拥塞控制，会导致发送窗口变小，进而影响发送流量，使TCP传输性能会急剧下降。但此时无线链路并非因为拥塞丢包，MPTCP在无线多链路条件下很难充分利用所有可用信道的带宽总和，这对IP业务流，尤其是TCP业务流的性能造成很大影响。
可以实现一种MPTCP重传代理，在发送时缓冲发送数据帧，收到肯定确认就回收缓冲，收到否定确认就进行代理重传，此否定确认帧不提交TCP协议栈，使丢包处理不会出现在TCP层，从而不会触发拥塞控制。
为实现MPTCP重传代理，我们还需要对MPTCP进行跟踪，以实现在每一条链路上对MPTCP通道的跟踪，从而知道每次丢包是在哪条TCP通道，从而构建起缓冲发送数据帧的重传代理发送窗口，当需要重传时，选择一条时延最小的链路发送重传帧，将重传帧以最快的速度发送到对端，以免发送端启动超时重传。
这样我们就能实现MPTCP重传代理，发送窗口就不会变小，不会使TCP传输性能下降，就能解决这个在MPTCP应用场景下的重要问题。
4.组播按需调度实现
在组播技术的目的是以尽为而为的方式向目标组发送信息，源主机向多点目标主机只发送一份数据，数据的目的地址是组播地址，凡是属于该组的用户都可以接收到一份源主机发送的数据。在无线多网络融合的条件下，当组播数据到达汇聚服务器后要经过封装后再发送到一体化终端，如果对所有一体化终端都复制一份数据，会因为数据包的多次重复而浪费带宽资源，同时，汇聚服务器的负荷会因为多次的数据复制而加大，对系统整体性能影响较大。
在多网络融合系统中可以把汇聚服务器当作路由器，IGMP Snooping是用来监听用户终端与路由器设备之间的IGMP报文，与在汇聚服务器上使能IGMP Snooping功能，二层设备会侦听主机和路由器之间交互的IGMP报文，建立和维护二层组播转发表，从而指导组播数据帧在数据链路层按需转发，减少网络数据风暴，提高带宽利用率。
在汇聚服务器上调度组播数据时，通过组播IP查找IGMP Snooping转发表哪些终端IP属于该组播组，在一体化终端与汇聚服务器交互的过程中在汇聚服务器中建立了IP与一体化终端的对应关系表，在汇聚服务器上可以通过终端IP查询到对应的一体化终端，并将该组播通过UDP隧道封装后发送到相应的一体化终端。
5.多链路组播重传技术方案
多链路组播重传既要考虑当前带宽情况，也要考虑用户对组播可靠性的需求，还要考虑有多少用户需要进行重传，组播重传主要有以下几种方案：
1)单链路单播重传组播，组播重传包在多链路中的其中一条链路上经过UDP隧道封装后重传，这种方式组播重传可靠性一般，可以满足对组播可靠性要求不高的用户。
2)多链路单播冗余重传组播，组播重传包在多链路上经过UDP隧道封装后复制多份进行多路重传，重传可靠性较高，在损失一定带宽的的情况下提高了可靠性，满足在重传用户不多，可靠性要求较高的场景。
3)多链路组播冗余重传一次组播，残余的未到达组播包再进行单播重传，当要多用户需要对数据进行组播重传时，可以在多条链上直接用组播的方式发送重传包，接收发收到冗余的组播包去重，如果仍有部分组播未能收到，可以用单播的方式再进行重传。
4)MPTCP隧道发送重传组播，在对时延不敏感，对可靠性要求高的场景下，利用MPTCP隧道封装后进行重传。
6.组播ARQ及重传设计
组播ARQ与普通ARQ主要有如下几点不同，汇聚服务器的一个组播ARQ实体对应多个一体化终端的组播ARQ实体；为了应对多个一体化终端与汇聚服务器之间RRT时间的差异，汇聚服务器的组播ARQ实体窗口长度比对应的一体化终端更长；由于汇聚服务器与一体化终端之间的ARQ实体是一对多的关系，当收到一体化终端LLC接收状态控制帧时，汇聚服务器不会移动发送窗口，如果收到LLC接收状态控制帧为否定确认，则重传对应序号的组播帧；当发送窗口填满后发送序号重新开始编号，并释放窗口中原有的组播帧。
实施例2
1.具体实施环境如图2所示。
2.详细处理的过程
1)发送方和接收方之前有多条链路，目前搭建的环境采用三条链路来进行实现，在这里分别为链路1、链路2和链路3，且每条的链路时延和带宽均不相同。
2)一体化终端在启动后与汇聚服务器建立两种多链路传输隧道，一种是MPTCP多链路传输隧道，一种是UDP多链路传输隧道，并启动MPTCP的三条链路的连接跟踪表，保存经由各条链路发送的经过隧道封装后的TCP数据帧。
3)一体化终端从三条链路向汇聚服务器发送探测请求包，并记录发送时间，汇聚服务器收到后立即回复，一体化终端根据接收时间可以计算出每条链路的RRT时间。
4)一体化终端捕获来自PC1的数据包，对数据包的业务类型进行分类,分类后的数据放入对应的业务包缓冲队列。
目的MAC地址为FF-FF-FF-FF-FF-FF为广播包，只处理以太类型为0x0806的ARP请求帧，一体化终端代理回复所有终端的ARP请求。
目的MAC地址为01-00-5E-xx-xx-xx为组播包，将数据帧存入组播流队列。
单播包通过IP协议类型区分TCP和UDP类型，协议类型为0x06为TCP类型，将数据帧存入背景流队列；在UDP类型中判断为RTP类型的存入音视频流队列，其它的UDP数据存入尽力而为流队列。
5)LLC接收状态控制帧处理，它作为ARQ反馈，根据反馈位图对肯定确认的数据作释放处理，对否定确认的数据帧作重传处理。
6)业务包缓冲队列调度，调度程序依次调度音视频流队列、组播队列、尽力而为流队列、背景流队列。组播队列调度时根据组播IP查询IGMP Snooping表查询哪些IP用户属于该组播，再通过UDP隧道封装后发送到一体化终端。
7)MPTCP连接跟踪表的建立，按源IP、PORT和目的IP、PORT四元组作为一条连接跟踪表的入口，跟踪表中有两个指向数据帧记录的指针，一个指向第一条数据帧记录，一个指向最后一条数据帧记录。
8)当通过MPTCP发送数据时，通过对比四元组找到连接跟踪表的入口，首先建立一条空的数据帧记录用于记录当前数据帧，数据帧记录包含数据存储指针、发送序号、数据长度、数据确认次数、等待确认序号、下一数据记录指针。
9)数据存储指针通过克隆源数据SKB结构头实现，发送序号为TCP头中的序号，数据长度为TCP负载长度，初始数据确认次数为0，等待确认序号为发送序号加上数据长度之和，下一数据记录指针为空指针。将此数据帧记录插入连接跟踪表尾部。
10)接收到MPTCP链路的TCP ACK，按源IP、PORT和目的IP、PORT四元组找到连接跟踪表项，从TCP ACK帧中取出确认序号，从连接跟踪表项中的第一个数据帧记录开始比对等待确认序号，如果不相等则释放对应在MPTCP相应的数据帧记录，并将该ACK包正常提交协议栈；如果序号相等，将数据帧记录中的数据确认次数加1。
11)如果数据确认次数大于1则表明发送的报文段丢失，需要重传，选择时延最小的链路将记录的数据帧尽快发送到对端，该TCP ACK帧不再提交协议栈；否则直接将该TCPACK帧提交协议栈。
12)接收到UDP隧道的数据包，如果是新重的则放入接收ARQ窗口，如果是重传的则直接丢弃；如果ARQ窗口中的数据包是按序接收，则将按序数据提交协议栈，否则不提交，等待重传或者超时后再提交协议栈。
13)生成音视频流ARQ和尽力而为流ARQ的LLC接收状态控制帧,并通过RRT最小的链路发送到对端，不管是否按序接收都发送LLC接收状态控制帧。
14)如果组播ARQ接收到乱序的组播包，则立即通过时延最小的链路发送LLC接收状态控制帧，向汇聚服务器请求重传丢失的帧；如果是按序接收则不用发送LLC接收状态控制帧。
3.本发明根据无线多链路传输方案在实验室搭建了模拟环境，验证了基于QoS的多网络融合传输方法的大带宽和可靠传输。
本发明提出了将MPTCP和UDP同时作为隧道封装技术应用到无线多网络融合传输系统，并且设计了一种MPTCP重传代理装置，在多链路环境下，极大的提高了终端用户的TCP业务性能，同时设计了基于业务流的调度方法以及组播的自适应调度方法，满足了终端用户对网络应用的高质量需求。
下面结合在UDP隧道和MPTCP隧道上TCP传输性能测试案例对发明的技术方案作进一步描述。
在PC2上利用系统工具IIS搭建FTP服务器，,在PC1安装FTP文件传输工具filezilla，连接FTP服务器192.168.200.1，进行文件FTP下载测试。
在单链路环境下，一体化终端与汇聚服务器之间采用UDP隧道封装，进行PING包RRT时延和FTP下载测试。
测试结果：
链路1：RRT为40ms左右；FTP平均下载速率2.0MB/s；
链路2：RRT为36ms左右；FTP平均下载速率2.2MB/s。
链路3：RRT为28ms左右；FTP平均下载速率4.6MB/s。
同时使用三条链路,一体化终端与汇聚服务器之间分别采用UDP隧道封装和MPTCP隧道封装，进行FTP下载测试。
测试结果：
UDP隧道封装：FTP平均下载速率2.1MB/s。
MPTCP隧道封装：FTP平均下载速率5.8MB/s。
上述案例首先测试了单条链路的RRT时延和FTP传输速率，然后对比测试了FTP业务在三条链路融合情况下分别通过UDP隧道和MPTCP隧道封装后的传输速率。采用UDP隧道封装时，FTP下载速率只能接近RRT时延最大的那条链路的传输速率；而采用MPTCP隧道封装时，FTP下载速率则大于单条链路的最大传输速率。因此使用MPTCP隧道封装TCP业务时性能得到了改善明显。
在本发明的描述中，除非另有说明，“多个”的含义是两个或两个以上；术语“上”、“下”、“左”、“右”、“内”、“外”、“前端”、“后端”、“头部”、“尾部”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本发明的限制。此外，术语“第一”、“第二”、“第三”等仅用于描述目的，而不能理解为指示或暗示相对重要性。
在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用全部或部分地以计算机程序产品的形式实现，所述计算机程序产品包括一个或多个计算机指令。在计算机上加载或执行所述计算机程序指令时，全部或部分地产生按照本发明实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL)或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输)。所述计算机可读取存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘SolidState Disk(SSD))等。
以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，都应涵盖在本发明的保护范围之内。
Claims (9)
1.一种基于QoS的多网络融合传输方法，其特征在于，所述基于QoS的多网络融合传输方法包括以下步骤：
步骤一，进行业务类型分类；一体化终端和汇聚服务器对于截获的用户数据，按MAC地址对截获的用户数据放入单播队列、组播队列和广播队列；
步骤二，进行业务队列调度；遵循重传优先，时间敏感优先的原则，进行UDP隧道或MPTCP隧道发送；
步骤三，进行MPTCP重传代理优化；通过MPTCP重传代理，在发送时缓冲发送数据帧，收到肯定确认就回收缓冲，收到否定确认就进行代理重传；所述MPTCP重传代理优化，包括：
通过MPTCP重传代理，在发送时缓冲发送数据帧，收到肯定确认就回收缓冲，收到否定确认就进行代理重传，此否定确认帧不提交TCP协议栈，使丢包处理不会出现在TCP层，不会触发拥塞控制；
对MPTCP进行跟踪，以实现在每一条链路上对MPTCP通道的跟踪，从而知道每次丢包是在哪条TCP通道，构建起缓冲发送数据帧的重传代理发送窗口，当需要重传时，选择一条时延最小的链路发送重传帧，将重传帧以最快的速度发送到对端，避免发送端启动超时重传；
步骤四，进行组播按需调度实现；在汇聚服务器上通过终端IP查询到对应的一体化终端，并将该组播通过UDP隧道封装后发送到相应的一体化终端；
步骤五，进行多链路组播重传实现；MPTCP隧道发送重传组播，在对时延不敏感，对可靠性要求高的场景下，利用MPTCP隧道封装后进行重传；
步骤六，进行组播ARQ及重传设计，当收到一体化终端LLC接收状态控制帧时，汇聚服务器不会移动发送窗口，如果收到LLC接收状态控制帧为否定确认，则重传对应序号的组播帧；当发送窗口填满后发送序号重新开始编号，并释放窗口中原有的组播帧。
2.如权利要求1所述的基于QoS的多网络融合传输方法，其特征在于，步骤一中，所述业务类型分类，包括：
采用MPTCP和UDP双隧道传输技术方案，在一体化终端和汇聚服务器上采用相同的业务分类方法，基于用户数据业务主要分为TCP和UDP两大类型，将用户TCP业务数据使用MTTCP隧道传输，UDP业务数据使用UDP隧道传输；
对于截获的用户数据，首先按MAC地址分为单播、组播和广播三种类型，组播业务数据直接放入组播队列，广播业务不转发，仅对ARP请求作代理回复，单播业务数据根据IP类型分为TCP和UDP，TCP业务数据放入背景流队列，在UDP类型中通过RTP报文头信息带有的某些特点和信息识别出音视频流放入音视频流队列，其它业务数据放入尽力而为流队列。
3.如权利要求1所述的基于QoS的多网络融合传输方法，其特征在于，步骤二中，所述业务队列调度，包括：
所述业务队列调度遵循重传优先，时间敏感优先的原则，包括：
（1）按重传优先的原则，根据ARQ LLC接收状态控制帧进行数据帧重传，并记录重传次数，对音视频流、组播数据进行一次重传；尽力而为类型数据最多重传二次；
（2）音视频流对时间敏感高，接着调度音视频流队列，放入相应的ARQ发送窗口，经过LLC封装后通过UDP隧道发送；
（3）组播队列调度，放入相应的组播ARQ发送窗口，通过LLC封装后由UDP隧道发送；
（4）背景流队列调度，直接通过MPTCP隧道发送。
4.如权利要求1所述的基于QoS的多网络融合传输方法，其特征在于，步骤四中，所述组播按需调度实现，包括：
在多网络融合系统中把汇聚服务器当作路由器，IGMP Snooping用来监听用户终端路由器设备之间的IGMP报文，在汇聚服务器上使能IGMP Snooping功能，二层设备会侦听主机和路由器之间交互的IGMP报文，建立和维护二层组播转发表，指导组播数据帧在数据链路层按需转发；
在汇聚服务器上调度组播数据时，通过组播IP查找IGMP Snooping转发表确定属于该组播组的终端IP，在一体化终端与汇聚服务器交互过程中在汇聚服务器中建立IP与一体化终端的对应关系表，在汇聚服务器上通过终端IP查询到对应的一体化终端，并将该组播通过UDP隧道封装后发送到相应的一体化终端。
5.如权利要求1所述的基于QoS的多网络融合传输方法，其特征在于，步骤五中，所述多链路组播重传实现，包括：
（1）单链路单播重传组播，组播重传包在多链路中的其中一条链路上经过UDP隧道封装后重传；
（2）多链路单播冗余重传组播，组播重传包在多链路上经过UDP隧道封装后复制多份进行多路重传；
（3）多链路组播冗余重传一次组播，残余的未到达组播包再进行单播重传，当多用户需要对数据进行组播重传时，在多条链上直接用组播的方式发送重传包，接收方收到冗余的组播包去重，如果仍有部分组播未能收到，可以用单播的方式再进行重传；
（4）MPTCP隧道发送重传组播，在对时延不敏感，对可靠性要求高的场景下，利用MPTCP隧道封装后进行重传。
6.如权利要求1所述的基于QoS的多网络融合传输方法，其特征在于，步骤六中，所述组播ARQ及重传设计，包括：
汇聚服务器的一个组播ARQ实体对应多个一体化终端的组播ARQ实体；为了应对多个一体化终端与汇聚服务器之间RRT时间的差异，汇聚服务器的组播ARQ实体窗口长度比对应的一体化终端更长；由于汇聚服务器与一体化终端之间的ARQ实体是一对多的关系，当收到一体化终端LLC接收状态控制帧时，汇聚服务器不会移动发送窗口，如果收到LLC接收状态控制帧为否定确认，则重传对应序号的组播帧；当发送窗口填满后发送序号重新开始编号，并释放窗口中原有的组播帧。
7.如权利要求1所述的基于QoS的多网络融合传输方法，其特征在于，所述基于QoS的多网络融合传输方法，还包括：
（1）发送方和接收方之前有多条链路，搭建环境采用三条链路来进行实现，分别为链路1、链路2和链路3，且每条的链路时延和带宽均不相同；
（2）一体化终端在启动后与汇聚服务器建立两种多链路传输隧道，一种是MPTCP多链路传输隧道，一种是UDP多链路传输隧道，并启动MPTCP的三条链路的连接跟踪表，复制经由各条链路发送的经过隧道封装后的TCP数据帧；
（3）一体化终端从三条链路向汇聚服务器发送探测请求包，并记录发送时间，汇聚服务器收到后立即回复，一体化终端根据接收时间可以计算出每条链路的RRT时间；
（4）一体化终端捕获来自PC1的数据包，对数据包的业务类型进行分类,分类后的数据放入对应的业务包缓冲队列；
目的MAC地址为FF-FF-FF-FF-FF-FF为广播包，只处理以太类型为0x0806的ARP请求帧，一体化终端代理回复所有终端的ARP请求；
目的MAC地址为01-00-5E-xx-xx-xx为组播包，将数据帧存入组播流队列；
单播包通过IP协议类型区分TCP和UDP类型，协议类型为0x06为TCP类型，将数据帧存入背景流队列；在UDP类型中判断为RTP类型的存入音视频流队列，其它的UDP数据存入尽力而为流队列；
（5）LLC接收状态控制帧处理，作为ARQ反馈，根据反馈位图对肯定确认的数据作释放处理，对否定确认的数据帧作重传处理；
（6）业务包缓冲队列调度，调度程序依次调度音视频流队列、组播队列、尽力而为流队列、背景流队列；组播队列调度时根据组播IP查询IGMP Snooping表查询哪些IP用户属于该组播，再通过UDP隧道封装后发送到一体化终端；
（7）MPTCP连接跟踪表的建立，按源IP、PORT和目的IP、PORT四元组作为一条连接跟踪表的入口，跟踪表中有两个指向数据帧记录的指针，一个指向第一条数据帧记录，一个指向最后一条数据帧记录；
（8）当通过MPTCP发送数据时，通过对比四元组找到连接跟踪表的入口，首先建立一条空的数据帧记录用于记录当前数据帧；其中，所述数据帧记录包含数据存储指针、发送序号、数据长度、数据确认次数、等待确认序号以及下一数据记录指针；
（9）数据存储指针通过克隆源数据SKB结构头实现，发送序号为TCP头中的序号，数据长度为TCP负载长度，初始数据确认次数为0，等待确认序号为发送序号加上数据长度之和，下一数据记录指针为空指针，并将此数据帧记录插入连接跟踪表尾部；
（10）接收到MPTCP链路的TCP ACK，按源IP、PORT和目的IP、PORT四元组找到连接跟踪表项，从TCP ACK帧中取出确认序号，从连接跟踪表项中的第一个数据帧记录开始比对等待确认序号，如果不相等则释放对应在MPTCP相应的数据帧记录，并将该ACK正常提交协议栈；如果序号相等，将数据帧记录中的数据确认次数加1；
（11）如果MPTCP连接跟踪表中数据确认次数大于1则表明发送的报文段丢失，需要重传，选择时延最小的链路将记录的数据帧尽快发送到对端，该TCP ACK帧不再提交协议栈；否则直接将该TCP ACK帧提交协议栈；
（12）接收到UDP隧道的数据包，如果是新传的则放入接收ARQ窗口，如果是重传的则直接丢弃；如果ARQ窗口中的数据包是按序接收，则将按序数据提交协议栈，否则不提交，等待重传或者超时后再提交协议栈；
（13）生成音视频流ARQ和尽力而为流ARQ的LLC接收状态控制帧，通过RRT最小的链路发送到对端，不管是否按序接收都发送LLC接收状态控制帧；
（14）如果组播ARQ接收到乱序的组播包，则立即通过时延最小的链路发送LLC接收状态控制帧，向汇聚服务器请求重传丢失的帧；如果是按序接收则不用发送LLC接收状态控制帧。
8.一种应用如权利要求1~7任意一项所述的基于QoS的多网络融合传输方法的基于QoS的多网络融合传输系统，其特征在于，所述基于QoS的多网络融合传输系统，包括：一体化终端、网口、PC、CPE、WIFI设备、电信LTE基站、移动LTE基站、路由器以及汇聚服务器。
9.一种信息数据处理终端，其特征在于，所述信息数据处理终端用于搭载权利要求8所述的基于QoS的多网络融合传输系统。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110485620.9A CN113194509B (zh) | 2021-04-30 | 2021-04-30 | 一种基于QoS的多网络融合传输系统及传输方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110485620.9A CN113194509B (zh) | 2021-04-30 | 2021-04-30 | 一种基于QoS的多网络融合传输系统及传输方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN113194509A CN113194509A (zh) | 2021-07-30 |
| CN113194509B true CN113194509B (zh) | 2022-06-17 |
Family
ID=76983743
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110485620.9A Active CN113194509B (zh) | 2021-04-30 | 2021-04-30 | 一种基于QoS的多网络融合传输系统及传输方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113194509B (zh) |
Families Citing this family (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113852445B (zh) * | 2021-08-27 | 2023-06-16 | 山东云海国创云计算装备产业创新中心有限公司 | 一种提高数据传输可靠性的方法、系统、设备和存储介质 |
| CN113949636A (zh) * | 2021-09-16 | 2022-01-18 | 阿里巴巴达摩院(杭州)科技有限公司 | 数据传输方法、网关设备及网络系统 |
| CN114500528A (zh) * | 2021-12-28 | 2022-05-13 | 天翼云科技有限公司 | 一种基于云平台的数据传输方法及装置 |
| CN115314569B (zh) * | 2022-05-10 | 2023-11-28 | 浙江大学 | 一种基于udp的轻量级mqtt设计方法 |
| CN115134292B (zh) * | 2022-06-28 | 2023-11-28 | 王蕊 | 基于接收窗口的多路径传输实时流媒体的路径管理方法 |
| CN115277560B (zh) * | 2022-09-28 | 2023-01-17 | 鹏城实验室 | 基于mptcp和mpquic的异构网络融合传输方法及系统 |
| CN115996178B (zh) * | 2022-11-28 | 2023-11-24 | 中国人民解放军32039部队 | 一种空间数据传输的服务质量评估方法和装置 |
| CN116389351A (zh) * | 2022-12-27 | 2023-07-04 | 上海叠念信息科技有限公司 | 基于多连接的点到点虚拟网络隧道技术 |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR20120065867A (ko) * | 2010-12-13 | 2012-06-21 | 경희대학교 산학협력단 | 지연-대역폭의 곱이 큰 네트워크를 위한 단대단 에너지 절약 기법을 사용한 다중경로 ｔｃｐ 네트워크 |
| CN102820977A (zh) * | 2012-08-07 | 2012-12-12 | 福建星网锐捷网络有限公司 | 组播方法、装置及网络设备 |
| CN103918304A (zh) * | 2011-09-22 | 2014-07-09 | 高通股份有限公司 | 用于无线通信网络中的多径传输连接的动态子流控制 |
| CN104796350A (zh) * | 2015-04-29 | 2015-07-22 | 广西大学 | 一种基于连续报文标记的多路径tcp拥塞控制方法 |
| CN105162868A (zh) * | 2015-09-18 | 2015-12-16 | 华中师范大学 | 一种教师端与学生端之间的可靠数据传输方法 |
| CN110011758A (zh) * | 2019-01-30 | 2019-07-12 | 国家广播电视总局广播电视科学研究院 | 一种多链路下tcp的ack传输优化方法、相关装置及系统 |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10020918B2 (en) * | 2015-12-28 | 2018-07-10 | Alcatel Lucent | Fast coupled retransmission for multipath communications |
-
2021
- 2021-04-30 CN CN202110485620.9A patent/CN113194509B/zh active Active
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR20120065867A (ko) * | 2010-12-13 | 2012-06-21 | 경희대학교 산학협력단 | 지연-대역폭의 곱이 큰 네트워크를 위한 단대단 에너지 절약 기법을 사용한 다중경로 ｔｃｐ 네트워크 |
| CN103918304A (zh) * | 2011-09-22 | 2014-07-09 | 高通股份有限公司 | 用于无线通信网络中的多径传输连接的动态子流控制 |
| CN102820977A (zh) * | 2012-08-07 | 2012-12-12 | 福建星网锐捷网络有限公司 | 组播方法、装置及网络设备 |
| CN104796350A (zh) * | 2015-04-29 | 2015-07-22 | 广西大学 | 一种基于连续报文标记的多路径tcp拥塞控制方法 |
| CN105162868A (zh) * | 2015-09-18 | 2015-12-16 | 华中师范大学 | 一种教师端与学生端之间的可靠数据传输方法 |
| CN110011758A (zh) * | 2019-01-30 | 2019-07-12 | 国家广播电视总局广播电视科学研究院 | 一种多链路下tcp的ack传输优化方法、相关装置及系统 |
Non-Patent Citations (2)
| Title |
|---|
| On the Design and Analysis of a Resilient Transport Protocol;Truc Anh N. Nguyen等;《2018 10th International Workshop on Resilient Networks Design and Modeling (RNDM)》;20181015;全文 * |
| 多路径传输协议测试床构建与测试;符发等;《现代计算机(专业版)》;20160615(第17期);全文 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN113194509A (zh) | 2021-07-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN113194509B (zh) | 一种基于QoS的多网络融合传输系统及传输方法 | |
| Balakrishnan et al. | Improving reliable transport and handoff performance in cellular wireless networks | |
| Iyengar et al. | Concurrent multipath transfer using SCTP multihoming over independent end-to-end paths | |
| JP5032598B2 (ja) | Ｌｔｅモビリティのための選択的パケット転送 | |
| Xu et al. | CMT-NC: improving the concurrent multipath transfer performance using network coding in wireless networks | |
| WO2018086076A1 (zh) | 数据传输方法及装置 | |
| Kumar et al. | Survey on transport layer protocols: TCP & UDP | |
| WO2018127225A1 (zh) | 数据传输方法、网络侧设备及用户设备 | |
| WO2006133655A1 (fr) | Procede pour la transmission fiable de donnees utilisant un protocole de multidiffusion et de diffusion individuelle et hote pour la reception des donnees | |
| JP2010504047A (ja) | マルチパス環境におけるトランスポートプロトコルの性能を改善するシステムおよび方法 | |
| US11088957B2 (en) | Handling of data packet transfer via a proxy | |
| CN103944691A (zh) | 一种协同业务传输中的数据重传方法及接入网网关 | |
| WO2019154134A1 (zh) | 一种数据包发送方法及相关设备 | |
| CN111901075B (zh) | 多网络融合传输方法、传输系统及计算机可读存储介质 | |
| CN102763359B (zh) | 多播网络中流控制传输协议的通信量优化器及方法 | |
| WO2016161594A1 (zh) | 一种数据传输的方法及装置 | |
| Dong et al. | Multi-path load balancing in transport layer | |
| Lee et al. | IRMA: A reliable multicast architecture for the Internet | |
| WO2020010511A1 (zh) | 数据传输方法及基站 | |
| JP2005244897A (ja) | 信頼性のある通信方法及びその装置 | |
| US20030137948A1 (en) | Retransmission control in wireless packet data networks | |
| Abd et al. | Improving throughput and reliability in mobile wireless networks via transport layer bandwidth aggregation | |
| Dong et al. | Concurrency handling in TCP | |
| Chandra et al. | TCP performance for future IP-based wireless networks | |
| Dong et al. | A concurrent transmission control protocol |
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 |