CN102790803A - 一种基于多终端融合的流媒体业务多流并发传输方法 - Google Patents
一种基于多终端融合的流媒体业务多流并发传输方法 Download PDFInfo
- Publication number
- CN102790803A CN102790803A CN2012102497170A CN201210249717A CN102790803A CN 102790803 A CN102790803 A CN 102790803A CN 2012102497170 A CN2012102497170 A CN 2012102497170A CN 201210249717 A CN201210249717 A CN 201210249717A CN 102790803 A CN102790803 A CN 102790803A
- Authority
- CN
- China
- Prior art keywords
- data
- streaming media
- media service
- multiple terminals
- organization mechanism
- 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.)
- Pending
Links
Images
Landscapes
- Information Transfer Between Computers (AREA)
Abstract
本发明是一种适用于移动互联网中流媒体业务多流并发传输方法。首先流媒体业务实现过程负责终端设备采集压缩流媒体业务数据；处理后的数据送交业务数据调度过程，该过程获取基础组织机制构建过程提供的上下文信息进行流媒体数据在链路间的均衡分配；最后链路捆绑聚合过程聚合多通道，使多通道中的分段数据保证在逻辑上的统一，并负责启动数据在链路上的多流并发传输，引入基础组织机制和业务组织机制将多个终端设备组织成一个融合的终端系统，充分利用多终端融合的能力，满足用户对高实时、高带宽业务的需求，链路捆绑聚合过程聚合多通道，使多通道中的分段数据保证在逻辑上的统一，并负责启动数据在链路上的传输过程。
Description
技术领域
本发明是在泛在网络环境下，通过多终端协同通信实现流媒体数据的多流并发传输，属于泛在通信领域。
背景技术
快速发展的移动通信技术一方面为信息社会的发展带来了机遇，另一方面也形成了多种异构无线技术并存的多无线电通信环境，给通信网络的组织带来了巨大的挑战。为了使用户能够便捷地接入网络，轻松地享用网络服务，“融合”已成为信息通信业的发展潮流。
目前每个用户通常都拥有多个异构终端，具备接入到不同的通信网络中的能力。同时用户对高实时、高带宽的业务需求也越来越多，但是单一的终端设备又无法满足这种日益增长的需求，这就促使终端向融合的方向发展。终端融合最为直接的就是研制多模终端，但是随着无线接入技术的不断增多，终端将会变得日益复杂，成本也愈益增高。因此更好的技术方案应该是基于软件无线电的终端重配置技术。多个异构终端通过终端融合，协同工作，共同满足用户对高质量、高带宽的业务需求将具有重要意义。
发明内容
技术问题：本发明提出了一种基于多终端融合的流媒体业务多流并发传输方法，为多终端协同提供一种组织机制，实现多终端融合，相互协作共同承载业务，给用户提供最佳的业务体验。
技术方案：未来的终端设备是分布式存在的,在不同的业务环境中，用户可以拥有和使用不同的终端设备。因此本发明将多终端的协同认定为一个自组织系统，该系统中多终端之间的组织是一种分布式的拓扑结构，终端之间可以相互感知、协同工作。本发明中多终端融合系统的的组织机制分为基础组织机制和业务组织机制。
在承载业务之前，异构终端间要相互感知，以获取各链路或网络负载情况等上下文信息，可以通过基础组织机制实现；承载业务时，根据上下文信息调度业务数据和捆绑链路，可以通过业务组织机制实现。
多个设备能够共同负载一个业务的前提是各终端设备能够相互协作。终端设备之间的协作需要一种机制将多个设备组织起来，P2P就是提供这种基础组织机制的技术之一。
在流媒体的应用场景下，业务的多流并发的基础是多链路之间可以相互协调。多链路的协调需要一种机制将多条链路组织起来。MLPPP（multilink Point-to-Point）协议就是实现多链路捆绑的一种技术，用以解决链路的聚合捆绑问题。
另外，基于已有操作系统的多重链接实现的负载均衡通常不够稳定、效果不够理想。此时，需要在上层根据链路的能力对流媒体数据进行调度分配，以优化MLPPP的负载均衡。
本发明的基于多终端融合的流媒体业务多流并发传输方法，首先流媒体业务实现过程负责终端设备采集压缩流媒体业务数据；处理后的数据送交业务数据调度过程，该过程获取基础组织机制构建过程提供的上下文信息进行流媒体数据在链路间的均衡分配；最后链路捆绑聚合过程聚合多通道，使多通道中的分段数据保证在逻辑上的统一，并负责启动数据在链路上的多流并发传输，引入基础组织机制和业务组织机制将多个终端设备组织成一个融合的终端系统，充分利用多终端融合的能力，满足用户对高实时、高带宽业务的需求，该方法包括如下四个过程：
1) 基础组织机制构建过程：首先借助P2P技术构建多终端分布式的拓扑结
构，然后多终端通过该融合网络结构跨平台相互感知，以获取终端融合需要的上下文信息；
2) 流媒体业务实现过程：该过程负责发送端流媒体数据的采集、编码、传
输和接收端的解码和呈现；在将融合系统用于实现流媒体业务传输之前，先在其他系统搭建流媒体业务平台，之后将该场景下的业务移植到多终端融合系统中；
3) 业务数据调度过程：对业务数据进行调度的目的是优化多链路P2P协议，
根据上下文信息调度流媒体业务数据在多链路间的分配，实现多链路的负载均衡；
4) 链路捆绑聚合过程：流媒体业务的多流并发要求多链路之间的协调，将
多PPP链路进行捆绑聚合，使独立的P2P链路具备了相关性，使各链路中的分段数据在逻辑上统一。
所述的基础组织机制和业务组织机制。这两种组织机制在逻辑上对应上述的四个过程。其中基础组织机制包括基础组织机制构建过程，业务组织机制包括流媒体业务实现过程、业务数据调度过程和链路捆绑聚合过程。
所述的基础组织机制构建过程，该过程首先利用P2P技术构建多终端分布式的拓扑结构，然后多终端通过该融合网络结构跨平台相互感知，以获取终端融合需要的上下文信息。在构建的多终端融合系统中，多终端设备既可以是同构的，也可以是异构的。
所述的流媒体业务实现过程，该过程包含流媒体数据的采集、编解码、传输和呈现；
a.数据采集：流媒体数据采集是在发送端通过物理设备获取实时数据的过程；
b.编码：在调度之前对流媒体业务数据进行压缩，与接收端解码过程对应；
c.传输：传输使用RTP协议族RTP/RTCP；
d.解码：在调度之后对流媒体业务数据进行解压缩，与发送端编码过程对应；
e.呈现：在接收端将流媒体业务数据还原并绘制到视窗，呈献给用户。
业务数据调度过程，该过程包含发送调度过程和接受调度过程，其发送调度过程包括检验到有待发送的流媒体数据后，根据上下文信息选择具有负载当前业务能力的链路，并比较数据量和负载能力的大小，以决定如何对数据进行分段，然后将分段后的数据置入发送缓存，并更新链路的负载能力，在缓存满后开始发送，发送完毕清空链路缓存；其接收调度过程包括计算当前缓存中分段的最小编号，然后比较最小编号与上一次重组分段时的最后一个分段的编号，随后查找是否有丢失的分段数据，进而启动分段的重组和数据的重建过程，并更新‘最后一个分段的编号’为重组过程中分段的最大编号；对于计算当前缓存中分段最小编号的过程，在两种情况下进行：有新的分段数据到达时和最小编号与最后一个分段编号相等时，对于查找分段数据丢失过程，它包括首先判定‘第一子包’的标志位，其次是‘校验位’的标志位，然后是‘最后子包’的标志位。
有益效果：
1. P2P覆盖网络的拓扑结构和路由算法，为融合系统的扩展和管理提供了保障。
2. 业务组织机制中使用多个modem均衡业务，多链路P2P协议（MLPPP）捆绑多链路，使多链路在逻辑上统一。
3. 调度算法对底层多链路P2P协议进行优化，改善基于系统配置的多链路P2P协议负载均衡效果，最终根据每个modem的负载情况灵活地自动调节负载分配，提高了用户体验。
附图说明
图1 节点间的交互过程示意图。
图2 发送调度算法的示意图。
图3 接收调度算法的示意图。
图4 查找分组丢失过程的示意图。
图5 模块间的逻辑关系示意图。
具体实施方式
综上所述，本发明中的方法包括以下过程，分别是：
1. 基础组织机制构建过程。基础组织机制首先借助P2P技术搭建多终端分布式的拓扑结构，然后多终端通过该网络结构跨平台相互感知，以获取终端融合需要的上下文信息。
2. 流媒体业务实现过程。在将融合系统用于实现流媒体之前，先在其他系统搭建流媒体业务平台，之后将该场景下的业务移植到融合系统中。
3. 业务数据调度过程。对业务数据进行调度的目的是优化MLPPP，实现多链路的负载均衡。
4. 链路捆绑聚合过程。流媒体业务的多流并发首先要求多链路之间的协调，将多PPP链路进行捆绑，使独立的P2P链路具有了相关性，各链路中的分段数据在逻辑上统一。
上述四个过程在实施过程中没有严格的前后顺序，尽管它们之间在逻辑上作用各不相同。
P2P作为多终端融合的基础组织机制，构成多终端间分布式的网络拓扑。非结构化的P2P网络在实际应用中面临很多难题，最主要的就是节点的查找要经常采用泛洪的方式，不仅查找费时，而且结果也很难保证。实际应用中，更多的是采用结构化的P2P网络即P2P覆盖网络。
业务组织机制在基础组织机制基础上，从系统承载的业务出发，为提高用户体验而对基础组织机制做的补充。上述过程中的2、3、4都属于业务组织机制的构建内容。
流媒体实现中的‘其他系统’，包括任何本发明中所涉及的融合系统之外所有的传统有线系统、无线系统。
业务数据的调度是基于操作系统的MLPPP配置，多链路的负载均衡不够理想，需要对流媒体数据的链路之间的分配进行调度。通过调度算法，根据链路负载能力协调流媒体数据在多个网络中的传输。
流媒体在3G网络中并发传输时，多个无线链路的捆绑聚合使用多链路P2P协议（MLPPP）。
基于上述的4个过程，本发明的具体实施方式对应的分为4个模块：基础组织模块、流媒体业务模块、业务数据调度模块、链路捆绑聚合模块。下文结合附图详细说明以上各模块的实施过程。
(一) 基础组织模块
基础组织模块构建融合系统的网络架构，涉及系统中各异构节点（终端设备）的组织、相互感知与交互。基于前述的技术方案，为体现融合系统中的多终端，分别建立windows平台和android平台下的节点，构建融合系统中的基础组织机制。该部分共构建三个节点，分别称为：JXTA peer、droid peer 和RDV peer。JXTA peer是windows节点，droid peer是android节点，RDVpeer是P2P网络中的超级节点。JXTApeer与droidpeer共同负载一个业务的前提是彼此间的相互感知，本发明中该过程的实现要借助超级节点RDVpeer，RDVpeer的作用是路由和中继。图1描述了节点间的交互过程并假设JXTApeer向droidpeer发起协同请求：
1. JXTApeer获取上下文信息，即droidpeer的负载等信息，通过发送‘查询请求’给droidpeer。该请求要通过RDVpeer传递。
2. JXTApeer通过droidpeer的安全验证后会收到droidpeer返回的‘查询响应’。
3. JXTApeer为获取具体的上下文信息，必须建立起具体的通信信道。首先发送‘路由请求’，JXTApeer收到来自droidpeer返回的响应后，开始建立通信信道。
4. 建立通信信道。如果JXTApeer与droidpeer间有相同的通信机制，则建立直连；如果双方是单模异构，则要通过RDVpeer中继。
5. P2P网络中，资源是key-value的形式，并对key进行hash存储，所以还需要解析的过程。
6. 最终上下文信息得到共享，为业务数据在链路间的调度做好准备。
(二) 流媒体业务模块
流媒体业务模块包含流媒体数据的采集、编解码、传输和呈现。
1. 数据采集。采集是在发送端通过物理设备获取实时数据的过程。
2. 编码。编码是在调度之前对流媒体数据进行压缩，与接收端解码过程对应。
3. 传输。传输使用RTP协议族（RTP/RTCP）。
4. 解码。解码是在调度之后对流媒体数据进行解压缩，与发送端编码过程对应。
5. 呈现。是指在接收端将流媒体还原并绘制到视窗，呈献给用户。
(三) 业务数据调度模块
业务数据调度模块优化链路捆绑聚合模块的负载均衡。调度过程中，发送调度与接收调度属于对等层，实施过程如下：
1. 发送调度
发送调度过程图2所示，详细过程描述如下：
（1） 检测是否有流媒体数据。如果没有则重置所有链路为初始状态，如果有则，
（2） 检测当前链路是否有负载能力。如果没有则转到下一链路，如果有则，
（3） 比较当前数据大小与链路负载能力。如果链路能力大于数据大小，则执行（5），如果链路不足以负载数据，则
（4） 数据分段，并保存链路状态。转至执行步骤（7）；
（5） 为避免数据为空的情况，再一次检查数据。如果为空，则执行步骤（1）。如果有数据，则
（6） 保存链路状态，并执行步骤（7）；
（7） 将数据封装并置入缓存，等待发送。然后，
（8） 根据保存的链路状态更新链路状态，然后
（9） 判定发送状态，如果为真则立即发送，随后清空缓存，并转至步骤（2）。为假则，
（10） 直接转至步骤（2），循环等待缓存满为止。
（11） 数据发送完毕，转至步骤（1）。
2. 接收调度
重组分组之前分段数据范围的选取至关重要。范围太大，会使效率太低，带来更多的延时。链路之间的不同时延会导致数据抖动，所以范围又不能太小。所以定义了两个概念：min_seq和last_proc_seq，由这两个编号限定重组分组时分段数据的选择区间。min_seq表示本次接收的分段中的最小编号，last_proc_seq表示上一次重组时使用的结束分组的编号。接收调度程序查找缓冲区中是否存在编号在last_proc_seq之前（更小）的分组。
接收调度过程如图3所示，详细过程描述如下：
（1）计算min_seq。并不是每次都要计算min_seq，计算只在下面两种情况下进行：
（a）有新的分段数据到达，计算出其中最小的编号作为min_seq。直观上来看应该是当min_seq等于last_proc_seq时重新计算min_seq即可，但是这样的话计算min_seq时编号的范围就很难选取，很显然要选择缓冲区中编号大于min_seq（或last_proc_seq，此时它们相等）的所有分段，但这样范围太大，效率就会很低。选择每次新到达的分段数据作为计算范围，确保了每个分段数据都会被计算到，还提高了计算效率。
（b）last_proc_seq与min_seq范围内已没有可用分段数据。计算min_seq而不是max_seq或其他编号的好处：由于时延的存在，一次到达的分段数据编号很有可能不是连续的，选取其中的最小编号min_seq，尽可能的选择前一次已到达的数据，可有效应对时延抖动问题。
（2）比较min_seq与last_proc_seq。如果后者大于前者，表明没有可用的分段数据，退出。如果前者大于后者，则
（3）查找是否有分段数据丢失。如果发现有分段丢失，则丢弃first与last之间的分段，并将last_proc_seq更新为last分段的编号，并转至步骤（1）。如果没有分段丢失，则
（4）启动重组。重组过程即提取各分段的有效数据部分，恢复出原始数据。同样需要更新last_proc_seq为last分段的编号。
（5）重组后的数据解码后绘制到视窗，最终呈现给用户。
进一步地，查找分组丢失时定义了三个标志位：first（第一子包）、last（最后子包）、check（校验）位，这些标志位都是与重组分组有关的。校验位是在发送端产生的，采用hash的方法，如果数据发生变化（在这里指数据出错），hash结果就会变化。每当有分段数据到达，就会更新这些标志位。根据图4，查找分组丢失的详细过程如下：
（1）flag是last位的标志，初始化为FALSE。
（2）寻找first位置位的分组，如果该位置空，则循环下去，找到为止。如果该位置位，则
（3）判定该分组的check位。如果置空，表明该分组出错，转步骤（2）。如果置位，则
（4）检查flag标志是否为TRUE。为TRUE表明找到了合法的first与last分段区间，转步骤（7）。为FALSE表明未找到last分段，继续向下寻找。找不到则转步骤（5），找到则转步骤（6）。
（5）更新flag标志为FALSE，并转步骤（3）。
（6）更新flag标志为TRUE，并转步骤（3）。
(四) 链路捆绑聚合模块
MLPPP是一种链路聚合技术，通过捆绑多条PPP链路来实现负载均衡。比如通过它可以利用两个modem将家庭计算机连接到ISP。数据帧在单条PPP链路不会出现乱序，但是被分配到多条连接上时，不同链路的时延很有可能会导致乱序。因此MLPPP对每个分段数据编号以便在接收端能够正确恢复。
本发明使用的MLPPP是基于操作系统的重配置和修改注册表实施的。具体实施过程如下：
1. 多重链路的配置：在无线modem显示的本地连接中设置。
2. 注册表的修改：通过添加RandomAdapter和SingleResponse 的值来使能多网卡间的负载均衡。
在实施过程中，上述几个模块不需要按照顺序依次实施，可以分别单独实施，但是模块间要符合图5所示的逻辑关系：
1. 业务数据由流媒体业务模块压缩后传至业务数据调度模块；
2. 业务数据调度模块结合基础组织模块提供的上下文信息实现流媒体数据在链路间的均衡分配；
链路捆绑聚合模块聚合多通道，使多通道中的分段数据保证在逻辑上的统一，并负责启动数据在链路上的传送过程。
Claims (5)
1.一种基于多终端融合的流媒体业务多流并发传输方法，其特征在于，首先流媒体业务实现过程负责终端设备采集压缩流媒体业务数据；处理后的数据送交业务数据调度过程，该过程获取基础组织机制构建过程提供的上下文信息进行流媒体数据在链路间的均衡分配；最后链路捆绑聚合过程聚合多通道，使多通道中的分段数据保证在逻辑上的统一，并负责启动数据在链路上的多流并发传输，引入基础组织机制和业务组织机制将多个终端设备组织成一个融合的终端系统，充分利用多终端融合的能力，满足用户对高实时、高带宽业务的需求，该方法包括如下四个过程：
1）基础组织机制构建过程：首先借助P2P技术构建多终端分布式的拓扑结
构，然后多终端通过该融合网络结构跨平台相互感知，以获取终端融合需要的上下文信息；
2）流媒体业务实现过程：该过程负责发送端流媒体数据的采集、编码、传
输和接收端的解码和呈现；在将融合系统用于实现流媒体业务传输之前，先在其他系统搭建流媒体业务平台，之后将该场景下的业务移植到多终端融合系统中；
3）业务数据调度过程：对业务数据进行调度的目的是优化多链路P2P协议，
根据上下文信息调度流媒体业务数据在多链路间的分配，实现多链路的负载均衡；
4）链路捆绑聚合过程：流媒体业务的多流并发要求多链路之间的协调，将
多PPP链路进行捆绑聚合，使独立的P2P链路具备了相关性，使各链路中的分段数据在逻辑上统一。
2.如权利要求1所述的基于多终端融合的流媒体业务多流并发传输方法，其特征在于所述的基础组织机制和业务组织机制，这两种组织机制在逻辑上对应上述的四个过程；其中基础组织机制包括基础组织机制构建过程，业务组织机制包括流媒体业务实现过程、业务数据调度过程和链路捆绑聚合过程。
3.如权利要求1所述的基于多终端融合的流媒体业务多流并发传输方法，其特征在于所述的基础组织机制构建过程，该过程首先利用P2P技术构建多终端分布式的拓扑结构，然后多终端通过该融合网络结构跨平台相互感知，以获取终端融合需要的上下文信息；在构建的多终端融合系统中，多终端设备既可以是同构的，也可以是异构的。
4.如权利要求1所述的基于多终端融合的流媒体业务多流并发传输方法，其特征在于所述的流媒体业务实现过程，该过程包含流媒体数据的采集、编解码、传输和呈现；
a.数据采集：流媒体数据采集是在发送端通过物理设备获取实时数据的过程；
b.编码：在调度之前对流媒体业务数据进行压缩，与接收端解码过程对应；
c.传输：传输使用RTP协议族RTP/RTCP；
d.解码：在调度之后对流媒体业务数据进行解压缩，与发送端编码过程对应；
e.呈现：在接收端将流媒体业务数据还原并绘制到视窗，呈献给用户。
5.如权利要求1所述的基于多终端融合的流媒体业务多流并发传输方法，其特征在于业务数据调度过程，该过程包含发送调度过程和接受调度过程，其发送调度过程包括检验到有待发送的流媒体数据后，根据上下文信息选择具有负载当前业务能力的链路，并比较数据量和负载能力的大小，以决定如何对数据进行分段，然后将分段后的数据置入发送缓存，并更新链路的负载能力，在缓存满后开始发送，发送完毕清空链路缓存；其接收调度过程包括计算当前缓存中分段的最小编号，然后比较最小编号与上一次重组分段时的最后一个分段的编号，随后查找是否有丢失的分段数据，进而启动分段的重组和数据的重建过程，并更新‘最后一个分段的编号’为重组过程中分段的最大编号；对于计算当前缓存中分段最小编号的过程，在两种情况下进行：有新的分段数据到达时和最小编号与最后一个分段编号相等时，对于查找分段数据丢失过程，它包括首先判定‘第一子包’的标志位，其次是‘校验位’的标志位，然后是‘最后子包’的标志位。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN2012102497170A CN102790803A (zh) | 2012-07-19 | 2012-07-19 | 一种基于多终端融合的流媒体业务多流并发传输方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN2012102497170A CN102790803A (zh) | 2012-07-19 | 2012-07-19 | 一种基于多终端融合的流媒体业务多流并发传输方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN102790803A true CN102790803A (zh) | 2012-11-21 |
Family
ID=47156101
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN2012102497170A Pending CN102790803A (zh) | 2012-07-19 | 2012-07-19 | 一种基于多终端融合的流媒体业务多流并发传输方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN102790803A (zh) |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104320716A (zh) * | 2014-07-31 | 2015-01-28 | 南京邮电大学 | 一种基于多终端协同的视频上行链路传输方法 |
| CN107104908A (zh) * | 2017-04-25 | 2017-08-29 | 电信科学技术研究院 | 一种通信方法和装置 |
| CN107820101A (zh) * | 2016-09-13 | 2018-03-20 | 杭州萤石网络有限公司 | 一种流媒体服务提供方法、装置及系统 |
| CN109587053A (zh) * | 2018-12-28 | 2019-04-05 | Oppo广东移动通信有限公司 | 网络分流方法及相关设备 |
| CN110113142A (zh) * | 2019-04-28 | 2019-08-09 | 天通畅达(深圳)科技有限公司 | 基于多个数据通道并发捆绑承载大数据量业务的传输方法及系统 |
| WO2021018297A1 (zh) * | 2019-08-01 | 2021-02-04 | 杭州海康威视数字技术股份有限公司 | 一种基于p2p的服务通信方法、装置及系统 |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101635635A (zh) * | 2009-08-25 | 2010-01-27 | 北京原力创新科技有限公司 | 云模式流媒体服务平台 |
| CN102123087A (zh) * | 2011-02-18 | 2011-07-13 | 天津博宇铭基信息科技有限公司 | 快速定标多级转发负载均衡方法及多级转发网络系统 |
-
2012
- 2012-07-19 CN CN2012102497170A patent/CN102790803A/zh active Pending
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101635635A (zh) * | 2009-08-25 | 2010-01-27 | 北京原力创新科技有限公司 | 云模式流媒体服务平台 |
| CN102123087A (zh) * | 2011-02-18 | 2011-07-13 | 天津博宇铭基信息科技有限公司 | 快速定标多级转发负载均衡方法及多级转发网络系统 |
Non-Patent Citations (1)
| Title |
|---|
| 周皓: "泛在环境下多终端协同机制研究", 《中国科技文献》, 30 June 2012 (2012-06-30), pages 186 - 191 * |
Cited By (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104320716A (zh) * | 2014-07-31 | 2015-01-28 | 南京邮电大学 | 一种基于多终端协同的视频上行链路传输方法 |
| CN104320716B (zh) * | 2014-07-31 | 2017-07-07 | 南京邮电大学 | 一种基于多终端协同的视频上行链路传输方法 |
| CN107820101A (zh) * | 2016-09-13 | 2018-03-20 | 杭州萤石网络有限公司 | 一种流媒体服务提供方法、装置及系统 |
| CN107104908A (zh) * | 2017-04-25 | 2017-08-29 | 电信科学技术研究院 | 一种通信方法和装置 |
| US11228946B2 (en) | 2017-04-25 | 2022-01-18 | Datang Mobile Communications Equipment Co., Ltd. | Communication method and device |
| CN109587053A (zh) * | 2018-12-28 | 2019-04-05 | Oppo广东移动通信有限公司 | 网络分流方法及相关设备 |
| CN110113142A (zh) * | 2019-04-28 | 2019-08-09 | 天通畅达(深圳)科技有限公司 | 基于多个数据通道并发捆绑承载大数据量业务的传输方法及系统 |
| WO2021018297A1 (zh) * | 2019-08-01 | 2021-02-04 | 杭州海康威视数字技术股份有限公司 | 一种基于p2p的服务通信方法、装置及系统 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110167051B (zh) | 集中式单元-分布式单元架构下的通信方法、通信设备 | |
| CN102790803A (zh) | 一种基于多终端融合的流媒体业务多流并发传输方法 | |
| CN108900355B (zh) | 一种星地多级边缘网络资源分配方法 | |
| CN103023826B (zh) | 一种OpenFlow控制器的路由控制方法 | |
| CN105007541B (zh) | 可伸缩视频流动态多码率组播优化传输方法 | |
| CN113411403B (zh) | 一种快速数据同步方法及装置 | |
| CN107615729A (zh) | 数据传输方法及通信装置 | |
| CN102497248A (zh) | 基于网络编码的数据重传方法 | |
| CN110351780B (zh) | 一种基于编码缓存的通信方法、系统及存储介质 | |
| CN105610617A (zh) | 一种基于SDN和AP虚拟化技术的WLAN中区分用户优先级的QoS管理机制 | |
| CN105657865A (zh) | 一种数据中转传输方法、系统和具备中继功能的ue | |
| CN104137602A (zh) | 用于在无线通信系统中进行内容和应用程序加速的系统和方法 | |
| CN112000481A (zh) | 一种d2d-mec系统计算能力最大化的任务卸载方法 | |
| CN102957628A (zh) | 报文聚合方法、装置和接入设备 | |
| CN105556916A (zh) | 网络流的信息统计方法和装置 | |
| CN108616925A (zh) | 一种数据流的处理方法及装置 | |
| CN108234550B (zh) | 一种信息发送方法、信息接收方法及pdcp实体 | |
| WO2016095142A1 (zh) | 软件定义网络sdn中数据转发的方法、设备和系统 | |
| CN105992186B (zh) | 数据传输方法及装置 | |
| CN103152382B (zh) | 面向多宿主网络的多文件并发传输控制方法 | |
| CN103179674B (zh) | 一种无线异构网络系统中的用户动态分组方法 | |
| CN107615810A (zh) | 用于在线网络代码的包头压缩系统和方法 | |
| US7693977B2 (en) | Systems and methods for virtualizing functions and decentralizing service delivery in a flat network of interconnected personal devices | |
| Erlebach et al. | An algorithmic view on OVSF code assignment | |
| CN103281724A (zh) | 泛在网络终端选择方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C02 | Deemed withdrawal of patent application after publication (patent law 2001) | ||
| WD01 | Invention patent application deemed withdrawn after publication |
Application publication date: 20121121 |