WO2022142516A1 - 数据传输方法、装置、计算机可读介质及电子设备 - Google Patents

数据传输方法、装置、计算机可读介质及电子设备 Download PDF

Info

Publication number
WO2022142516A1
WO2022142516A1 PCT/CN2021/120129 CN2021120129W WO2022142516A1 WO 2022142516 A1 WO2022142516 A1 WO 2022142516A1 CN 2021120129 W CN2021120129 W CN 2021120129W WO 2022142516 A1 WO2022142516 A1 WO 2022142516A1
Authority
WO
WIPO (PCT)
Prior art keywords
sub
data
strong
data packet
data packets
Prior art date
Application number
PCT/CN2021/120129
Other languages
English (en)
French (fr)
Inventor
雷艺学
Original Assignee
腾讯科技（深圳）有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 腾讯科技（深圳）有限公司 filed Critical 腾讯科技（深圳）有限公司
Publication of WO2022142516A1 publication Critical patent/WO2022142516A1/zh
Priority to US17/986,506 priority Critical patent/US20230070702A1/en

Links

Images

Classifications

    • 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/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • H04W28/065—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information using assembly or disassembly of packets
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/20—Manipulation of established connections
    • H04W76/22—Manipulation of transport tunnels
    • 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/0289—Congestion control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1063—Application servers providing network services

Definitions

  • FIG. 4 shows a schematic diagram of a division structure of a strong interaction type data packet according to an embodiment of the present application
  • different types of strongly-interactive data packets are transmitted in the same GTP-U tunnel, which may be multiple types of strongly-interactive data packets in different data streams in the same GTP-U tunnel.
  • -U tunnel for transmission For example, one type of strongly interactive data packet corresponds to one flow ID, and different types of strongly interactive data packets correspond to different flow IDs.
  • step S510 receive the PDU session management policy information sent by the SMF, where the PDU session management policy information is used to indicate that multiple types of strongly interactive data packets are differentially transmitted in the same GTP-U tunnel, and pass through the same DRB. to carry.
  • FIG. 6 shows a flowchart of a data transmission method according to an embodiment of the present application, and the data transmission method may be performed by a user equipment.
  • the data transmission method at least includes steps S610 to S630, which are described in detail as follows:
  • step S730 the URSP rule is sent to the AMF, so that the AMF forwards the URSP rule to the user equipment, and configures the base station equipment with access stratum context information according to the URSP rule, and the access stratum context information is used to indicate multiple types of strong
  • the interactive data packets are differentially transmitted in the same general packet radio service tunneling protocol user plane GTP-U tunnel, and are carried by the same data radio bearer DRB.
  • the start and end of the sub-packets obtained by splitting the strongly interactive data packet may be marked. Based on the marked start sub-packets and end sub-packets, if some of the N sub-packets split from a strong interaction type packet fail to be sent, the subsequent sub-packets do not need to be sent. , can be discarded.
  • step S1120 the sub-data packets obtained by splitting are marked as start data packets and end data packets.
  • the UPF can put different types of sub-packets into the same GTP-U tunnel for transmission to the gNB, and different types of sub-packets can be processed differently in the tunnel.
  • the process of the UPF sending sub-data packets to the gNB and the process of sending the sub-data packets to the UPF by the application server may be performed synchronously.
  • the sub-data packet can be sent to the gNB, which can reduce the delay of the sub-data packet reaching the user equipment.
  • UPF can also send sub-data packets to gNB after receiving all the sub-data packets sent by the application server. The advantage of this method is that it can avoid the sub-data sent to gNB first due to errors in the receiving process of UPF. The problem of wasting transmission resources due to invalid packets.
  • the UPF may also stop sending a certain type of strong interactive data packets to the gNB when not all sub-packets obtained by splitting a certain type of strong-interaction data packets transmitted by the application server are received within a certain period of time.
  • the sub-packet obtained by splitting the interactive data packet, and the UPF can also delete the sub-packet obtained by splitting the received strong interactive data packet of this type, and the UPF can also notify the application server to stop transmitting this type to the UPF.
  • the sub-packets obtained by splitting the strong-interaction packet may also stop sending a certain type of strong interactive data packets to the gNB when not all sub-packets obtained by splitting a certain type of strong-interaction data packets transmitted by the application server are received within a certain period of time.
  • Step S1205 if the user equipment succeeds in receiving all the sub-data packets, it performs reassembly to restore the strong-interaction type data packets.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

本申请的实施例提供了一种数据传输方法、装置、计算机可读介质及电子设备。该数据传输方法包括：接收AMF发送的接入层上下文信息，所述接入层上下文信息用于指示多种类型的强交互型数据包在同一个GTP-U隧道中进行区别传输，且通过同一个DRB进行承载；若识别到UPF通过所述GTP-U隧道发送的数据包属于强交互型数据包拆分得到的子数据包，则在将所述子数据包基于所述DRB发送至用户设备的过程中，检测是否存在发送失败的子数据包；若检测到指定类型的强交互型数据包拆分得到的子数据包中存在发送失败的子数据包，则停止向用户设备发送指定类型的强交互型数据包拆分得到的其余子数据包。

Description

数据传输方法、装置、计算机可读介质及电子设备
本申请要求于2021年01月04日提交中国专利局，申请号为202110003827.8，申请名称为“数据传输方法、装置、计算机可读介质及电子设备”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及通信技术领域，具体而言，涉及一种数据传输方法、装置、计算机可读介质及电子设备。
背景技术
在5G以及演进5G系统中，高带宽的强交互型业务是重要的业务类型，诸如云游戏(Cloud gaming)、VR(Virtual Reality，虚拟现实)、AR(Augmented Reality，增强现实)、MR(Mixed Reality，混合现实)、XR(Extended Reality，扩展现实)、CR(Cinematic Reality，影像现实)等，这些强交互型业务不仅对传输的时效性要求很高，而且随着分辨率、帧率和自由度等指标的提高，应用层产生的数据量极大增长，给网络传输带来很大的负荷。这种业务的应用层生成的数据包内容，需要以很低的时延，切割成大量数据包分段传输，一旦其中一个分段的传输未满足传输要求，则整个数据包内容就无法在接收端进行实时的恢复和呈现，从而对无法满足强交互性高带宽业务的需求。针对这种应用场景，如何能够保证强交互型业务的数据包在传输时能够尽量减少对传输资源的占用是亟待解决的技术问题。
发明内容
根据本申请提供的各种实施例，提供了一种数据传输方法、装置、计算机可读介质及电子设备。
本申请的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本申请的实践而习得。
根据本申请实施例的一个方面，提供了一种数据传输方法，包括：接收AMF(Access and Mobility Management Function，接入与移动性管理功能)发送的接入层上下文信息，所述接入层上下文信息用于指示多种类型的强交互型数据包在同一个通用分组无线业务隧道协议用户面GTP-U隧道中进行区别传输，且通过同一个DRB(Data Radio Bearer，数据无线承载)进行承载；若识别到用户面功能实体通过所述GTP-U隧道发送的数据包属于所述强交互型数据包拆分得到的子数据包，则在将所述强交互型数据包拆分得到的子数据包基于所述DRB发送至用户设备的过程中，检测所述强交互型数据包拆分得到的子数据包中是否存在向所述用户设备发送失败的子数据包；若检测到指定类型的强交互型数据包拆分得到的子数据包中存在向所述用户设备发送失败的子数 据包，则停止向所述用户设备发送所述指定类型的强交互型数据包拆分得到的其余子数据包。
根据本申请实施例的一个方面，提供了一种数据传输方法，包括：接收SMF(Session Management Function，会话管理功能)发送的PDU(Protocol Data Unit，协议数据单元)会话管理策略信息，所述PDU会话管理策略信息用于指示多种类型的强交互型数据包在同一个GTP-U隧道中进行区别传输，且通过同一个DRB进行承载；将接收到的所述多种类型的强交互型数据包拆分得到的子数据包在所述GTP-U隧道中分流传输至基站设备，并检测所述强交互型数据包拆分得到的子数据包中是否存在向所述基站设备发送失败的子数据包；若检测到指定类型的强交互型数据包拆分得到的子数据包中存在向所述基站设备发送失败的子数据包，则停止向所述基站设备发送所述指定类型的强交互型数据包拆分得到的其余子数据包。
根据本申请实施例的一个方面，提供了一种数据传输方法，包括：接收AMF发送的URSP(UE Route Selection Policy，用户设备路由选择策略)规则，所述URSP规则用于指示多种类型的强交互型数据包在同一个GTP-U隧道中进行区别传输，且通过同一个DRB进行承载；若识别到基站设备基于所述DRB发送的数据包属于所述强交互型数据包拆分得到的子数据包，则在接收所述强交互型数据包拆分得到的子数据包的过程中，检测对所述子数据包的接收情况；若完整接收到指定类型的强交互型数据包拆分得到的所有数据包，则对所述所有数据包进行整合得到所述指定类型的强交互型数据包。
根据本申请实施例的一个方面，提供了一种数据传输方法，包括：接收AF(Application Function，应用功能)发送的针对强交互型数据包的GTP-U隧道配置信息，所述GTP-U隧道配置信息用于指示多种类型的强交互型数据包在同一个GTP-U隧道中进行区别传输，且通过同一个DRB进行承载；根据所述GTP-U隧道配置信息生成URSP规则和协议数据单元PDU会话管理策略信息，所述URSP规则和所述PDU会话管理策略信息用于指示所述多种类型的强交互型数据包在同一个GTP-U隧道中进行区别传输，且通过同一个DRB进行承载；将所述URSP规则发送至AMF，以使所述AMF将所述URSP规则转发至用户设备，并根据所述URSP规则向基站设备配置接入层上下文信息，所述接入层上下文信息用于指示所述多种类型的强交互型数据包在同一个通用分组无线业务隧道协议用户面GTP-U隧道中进行区别传输，且通过同一个数据无线承载DRB进行承载；将所述PDU会话管理策略信息发送至SMF，以使所述SMF将所述PDU会话管理策略信息配置给用户面功能实体。
根据本申请实施例的一个方面，提供了一种数据传输装置，包括：第一接收单元，配置为接收AMF发送的接入层上下文信息，所述接入层上下文信息用于指示多种类型的强交互型数据包在同一个GTP-U隧道中进行区别传输，且通过同一个DRB进行承载；第一检测单元，配置为若识别到用户面功能实体通过所述GTP-U隧道发送的数据包属于所述强交互型数据包拆分得到的子数据包，则在将所述强交互型数据包拆分得到的子数据包基于所述DRB发送至用户设备的过程中，检测所述强交互型数据包拆分得到的子数据包中是否存在向所述用户设备发送失败的子数据包；第一处理单元，配置为若检测到指定类型的强交互型数据包拆分得到的子数据包中存在向所述用户设备发送失 败的子数据包，则停止向所述用户设备发送所述指定类型的强交互型数据包拆分得到的其余子数据包。
根据本申请实施例的一个方面，提供了一种数据传输装置，包括：第二接收单元，配置为接收SMF发送的PDU会话管理策略信息，所述PDU会话管理策略信息用于指示多种类型的强交互型数据包在同一个GTP-U隧道中进行区别传输，且通过同一个DRB进行承载；第二检测单元，配置为将接收到的所述多种类型的强交互型数据包拆分得到的子数据包在所述GTP-U隧道中分流传输至基站设备，并检测所述强交互型数据包拆分得到的子数据包中是否存在向所述基站设备发送失败的子数据包；第二处理单元，配置为若检测到指定类型的强交互型数据包拆分得到的子数据包中存在向所述基站设备发送失败的子数据包，则停止向所述基站设备发送所述指定类型的强交互型数据包拆分得到的其余子数据包。
根据本申请实施例的一个方面，提供了一种数据传输装置，包括：第三接收单元，配置为接收AMF发送的URSP规则，所述URSP规则用于指示多种类型的强交互型数据包在同一个GTP-U隧道中进行区别传输，且通过同一个DRB进行承载；第三检测单元，配置为若识别到基站设备基于所述DRB发送的数据包属于所述强交互型数据包拆分得到的子数据包，则在接收所述强交互型数据包拆分得到的子数据包的过程中，检测对所述子数据包的接收情况；第三处理单元，配置为若完整接收到指定类型的强交互型数据包拆分得到的所有数据包，则对所述所有数据包进行整合得到所述指定类型的强交互型数据包。
根据本申请实施例的一个方面，提供了一种计算机可读介质，其上存储有计算机可读指令，所述计算机可读指令被处理器执行时实现如上述实施例中所述的数据传输方法。
根据本申请实施例的一个方面，提供了一种电子设备，包括：一个或多个处理器；存储装置，用于存储一个或多个计算机可读指令，当所述一个或多个计算机可读指令被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如上述实施例中所述的数据传输方法。
根据本申请实施例的一个方面，提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机可读指令，该计算机可读指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机可读指令，处理器执行该计算机可读指令，使得该计算机设备执行上述各种可选实施例中提供的数据传输方法。
本申请的一个或多个实施例的细节在下面的附图和描述中提出。本申请的其它特征、目的和优点将从说明书、附图以及权利要求书变得明显。
应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。
附图说明
为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对 于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1示出了可以应用本申请实施例的技术方案的示例性系统架构的示意图；
图2示出了根据本申请的一个实施例的强交互型数据包的传输过程示意图；
图3示出了根据本申请的一个实施例的数据传输方法的流程图；
图4示出了根据本申请的一个实施例的强交互型数据包的划分结构示意图；
图5示出了根据本申请的一个实施例的数据传输方法的流程图；
图6示出了根据本申请的一个实施例的数据传输方法的流程图；
图7示出了根据本申请的一个实施例的数据传输方法的流程图；
图8示出了根据本申请的一个实施例的强交互型数据包的传输过程示意图；
图9示出了根据本申请的一个实施例的控制面的配置流程图；
图10示出了根据本申请的一个实施例的强交互型数据包的传输流程示意图；
图11示出了根据本申请的一个实施例的强交互型数据包的传输流程示意图；
图12示出了根据本申请的一个实施例的强交互型数据包的传输流程示意图；
图13示出了根据本申请的一个实施例的数据传输装置的框图；
图14示出了根据本申请的一个实施例的数据传输装置的框图；
图15示出了根据本申请的一个实施例的数据传输装置的框图；
图16示出了根据本申请的一个实施例的数据传输装置的框图；
图17示出了适于用来实现本申请实施例的电子设备的计算机系统的结构示意图。
具体实施方式
需要说明的是：在本文中提及的“多个”是指两个或两个以上。“和/或”描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。
随着5G(5th-Generation，第五代移动通信技术)的发展，使得许多要求多数据量、短时延的业务得到应用。比如云游戏业务、VR、AR、MR、XR以及CR等交互业务，也可以称之为AIS(Advanced Interactive Service，强交互服务)业务。
比如，在图1所示的云游戏场景中，云端服务器101用于运行云游戏，云端服务器101可以对游戏画面进行渲染，并将音频信号及渲染后的图像进行编码处理，最后将编码处理得到的编码数据通过网络传输至各个游戏客户端。游戏客户端可以是具有基本的流媒体播放能力、人机交互能力以及通信能力等的用户设备(User Equipment，用户设备)，例如，智能手机、平板电脑、笔记本电脑、台式计算机或者智能电视等；或者该游戏客户端可以是运行于终端设备中的应用程序。具体的，游戏客户端可以将云端服务器101传输的编码数据进行解码，得到模拟音视频信号，并进行播放。应理解的是，图1中只是示例性的表征云游戏系统的系统架构，并不对云游戏系统的具体架构进行限定；例如在其它实施例中，云游戏系统中还可包括用于调度的后台服务器等等。并且云端服务器101可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服 务、云通信、中间件服务、域名服务、安全服务、CDN(Content Delivery Network，内容分发网络)、以及大数据和人工智能平台等基础云计算服务的云服务器。游戏客户端以及云端服务器101可以通过有线或无线通信方式进行直接或间接地连接，本申请在此不做限制。
在上述的各种强交互业务的应用场景中，由于强交互型数据包巨大，因此在传输时需要拆分为多个子数据包。具体而言，如图2所示，在5G系统中，用户面主要包括应用服务器、UPF(User Plane Function，用户面功能)、基站(next generation nodeB，简称gNB)和UE(User Equipment，用户设备)。强交互型数据包的传输对于一些典型业务场景主要在下行方向，比如从应用服务器到UPF，然后再通过gNB发送给UE。在进行传输时，强交互型数据包在应用服务器的应用层进行拆分，拆分后的子数据包，作为IP包从应用服务器到达UPF后，5G系统通过PDU会话把子数据包传输到UE端，在UE端从协议栈逐级向上递交并进行重组恢复出该强交互型数据包。
其中，在图2所示的系统中，L1层是指物理层，其用于确保原始的数据可在各种物理媒体上传输；L2层指的是数据链路层，数据链路层在物理层提供的服务的基础上向网络层提供服务；IP(Internet Protocol，网际互联协议)层即为网络层，用于实现两个端系统之间的数据传送；UDP即为User Datagram Protocol，中文名为用户数据报协议；GTP-U即为GPRS(General packet radio service，通用分组无线业务)Tunneling Protocol，中文名为通用分组无线业务隧道协议用户面；PHY即为Physical的简称，中文名为物理层；MAC即为Media Access Control，中文名为媒体访问控制；RLC即为Radio Link Control，中文名为无线链路控制层协议；PDCP即为Packet Data Convergence Protocol，中文名是分组数据汇聚协议；SDAP即为Service Data Adaptation Protocol，中文名是服务数据适配协议。
在前述的应用场景中，应用层生成的强交互型数据包需要以很低的时延、切割成大量子数据包分段传输，一旦其中一个子数据包的传输未满足传输要求，则整个强交互型数据包就无法在接收端进行实时的恢复和呈现，从而无法满足强交互性高带宽业务的需求。在这种情况下，大量子数据包分段的传输其实是浪费了网络的宝贵资源。具体而言，假设一个强交互型数据包被拆分为10个子数据包(甚至更多个子数据包)，每个子数据包传输成功的概率为0.99，那么这10个子数据包全部传输成功的概率为0.9910，即为0.904。可见，在将一个强交互型数据包拆分为多个子数据包时，即便每个子数据包传输成功的概率很大，那么整个强交互型数据包拆分得到的所有子数据包都传输成功的概率也会大打折扣。而且，如果某个子数据包传输失败，那么将导致接收方不能恢复出强交互型数据包，在这种情况下，继续传输强交互型数据包拆分得到的子数据包已经没有意义了，基于此，本申请的实施例提出了如下的解决方案。
图3示出了根据本申请的一个实施例的数据传输方法的流程图，该数据传输方法可以由基站设备来执行。参照图3所示，该数据传输方法至少包括步骤S310至步骤S330，详细介绍如下：
在步骤S310中，接收AMF发送的接入层上下文信息，该接入层上下文信息用于指示多种类型的强交互型数据包在同一个GTP-U隧道中进行区别传输，且通过同一个DRB进行承载。
需要说明的是：如果基站是控制面与用户面分离的，即分离为gNB-CU(Centralized Unit，集中单元)和gNB-DU(Distributed Unit，分布单元)，且gNB-CU作为控制面，gNB-DU作为用户面，那么本申请实施例中的基站设备可以是gNB-DU。
在本申请的一个实施例中，强交互型数据包的类型可以是根据需要传输的业务内容的类型或者优先级的至少一种来确定的。比如，强交互型数据包的类型可以包括关键帧对应的强交互型数据包和非关键帧对应的强交互型数据包。关键帧可以是I帧，非关键帧可以是P帧和/或B帧。
在本申请的一个实施例中，多种类型的强交互型数据包在同一个GTP-U隧道中进行区别传输可以是将多种类型的强交互型数据包以不同的数据流在同一个GTP-U隧道中进行传输。比如一种类型的强交互型数据包对应一个流标识，不同类型的强交互型数据包对应的流标识不相同。
在步骤S320中，若识别到用户面功能实体通过GTP-U隧道发送的数据包属于强交互型数据包拆分得到的子数据包，则在将强交互型数据包拆分得到的子数据包基于DRB发送至用户设备的过程中，检测强交互型数据包拆分得到的子数据包中是否存在向用户设备发送失败的子数据包。
在本申请的一个实施例中，用户面功能实体在同一个GTP-U隧道中可以传输多种类型的强交互型数据包，不同类型的强交互型数据包以不同的流标识进行区分。基站设备在接收到用户面功能实体发送的数据包之后，可以识别出该数据包是否是强交互型数据包拆分得到的子数据包，如果识别到是强交互型数据包拆分得到的子数据包，还可以根据流标识识别出是哪个类型的强交互型数据包。
具体而言，假设有两种类型的强交互型数据包，即关键帧对应的强交互型数据包和非关键帧对应的强交互型数据包，那么用户面功能实体可以在同一个GTP-U隧道中传输这两种类型的强交互型数据包，具体可以是将这两种类型的强交互型数据包分别拆分为子数据包进行发送，并且通过不同的流标识进行区分。
在本申请的一个实施例中，强交互型数据包拆分得到的多个子数据包中包含有开始数据包和结束数据包。开始数据包中包含有第一指示信息，该第一指示信息用于指示开始数据包是多个子数据包中第一个传输的子数据包；结束数据包中包含有第二指示信息，该第二指示信息用于指示结束数据包是多个子数据包中最后一个传输的子数据包。该实施例的技术方案使得可以通过对开始数据包和结束数据包的识别来确定是否接收到强交互型数据包拆分得到的子数据包。比如，若根据开始数据包中包含的第一指示信息识别到该开始数据包，那么从开始数据包到结束数据包之间的数据包都属于强交互型数据包拆分得到的子数据包。
在本申请的一个实施例中，可以根据接收到的数据包的协议字段中包含的指示信息，识别接收到的数据包是否属于强交互型数据包拆分得到的子数据包。具体地，比如强交互型数据包拆分得到的子数据包中的开始数据包在协议字段中添加有用于指示其为开始数据包的指示信息，而结束数据包在协议字段中添加有用于指示其为结束数据包的指示信息，那么在根据数据包的协议字段识别到该开始数据包之后，从开始数据包到结束数据包之间的数据包都属于强交互型数据包拆分得到的子数据包。
在本申请的一个实施例中，可以根据接收到的数据包的净荷信息中包含的指示信 息，识别接收到的数据包是否属于强交互型数据包拆分得到的子数据包。具体地，比如强交互型数据包拆分得到的子数据包中的开始数据包在净荷信息中添加有用于指示其为开始数据包的指示信息，而结束数据包在净荷信息中添加有用于指示其为结束数据包的指示信息，那么在根据数据包的净荷信息识别到该开始数据包之后，从开始数据包到结束数据包之间的数据包都属于强交互型数据包拆分得到的子数据包。
继续参照图3所示，在步骤S330中，若检测到指定类型的强交互型数据包拆分得到的子数据包中存在向用户设备发送失败的子数据包，则停止向用户设备发送指定类型的强交互型数据包拆分得到的其余子数据包。
在本申请的实施例中，如果检测到指定类型的强交互型数据包拆分得到的子数据包中存在向用户设备发送失败的子数据包，那么继续发送该指定类型的强交互型数据包拆分得到的其余子数据包也不能恢复出该指定类型的强交互型数据包，因此可以停止向用户设备发送其余子数据包，以降低对带宽的占用，有利于减少强交互型数据包在传输时对传输资源的占用。
在本申请的一个实施例中，如果一个强交互型数据包拆分得到的子数据包中存在向用户设备发送失败的子数据包，那么这个强交互型数据包即为指定类型的强交互型数据包。换句话说，指定类型的强交互型数据包就是存在发送失败的子数据包的强交互型数据包。
具体而言，假设有两种类型的强交互型数据包，即关键帧对应的强交互型数据包和非关键帧对应的强交互型数据包。如果非关键帧对应的强交互型数据包在发送时存在发送失败的子数据包，那么非关键帧对应的强交互型数据包即为指定类型的强交互型数据包；如果关键帧对应的强交互型数据包在发送时存在发送失败的子数据包，那么关键帧对应的强交互型数据包即为指定类型的强交互型数据包。
在本申请的一个实施例中，在检测强交互型数据包拆分得到的子数据包中是否存在向用户设备发送失败的子数据包时，可以针对各个类型的强交互型数据包拆分得到的子数据包分别进行检测，并且各个类型的强交互型数据包拆分得到的子数据包的检测过程相互之间不影响。同时，各个类型的强交互型数据包拆分得到的子数据包的传输过程也可以是相互不影响的，比如，如果某个类型的强交互型数据包拆分得到的子数据包存在向用户设备发送失败的子数据包，那么可以停止向用户设备发送该强交互型数据包拆分得到的子数据包，但是这个过程并不影响对其它强交互型数据包拆分得到的子数据包的发送。
在本申请的一个实施例中，如果检测到指定类型的强交互型数据包拆分得到的子数据包中存在向用户设备发送失败的子数据包，那么还可以丢弃已经接收到的该指定类型的强交互型数据包拆分得到的子数据包，以降低对存储资源的占用。
在本申请的一个实施例中，如果检测到指定类型的强交互型数据包拆分得到的子数据包中存在向用户设备发送失败的子数据包，那么可以向用户面功能实体发送反馈信息，该反馈信息用于指示用户面功能实体停止传输强交互型数据包拆分得到的子数据包。该实施例的技术方案使得在检测到向用户设备发送的过程中存在发送失败的子数据包时，可以向用户面功能实体发送反馈信息，以指示用户面功能实体停止传输其余的子数据包，以减少对传输资源的占用。
在本申请的一个实施例中，向用户面功能实体发送反馈信息是在未完整接收到该指定类型的强交互型数据包拆分得到的所有子数据包的情况下进行的，如果已经完整接收到指定类型的强交互型数据包拆分得到的所有子数据包，那么无需再向用户面功能实体发送反馈信息。
在本申请的一个实施例中，如果在设定时长内未完整接收到用户面功能实体发送的指定类型的强交互型数据包拆分得到的所有子数据包，则停止向用户设备发送该指定类型的强交互型数据包拆分得到的子数据包，并丢弃接收到的该指定类型的强交互型数据包拆分得到的子数据包。在该实施例的技术方案中，强交互型数据包可以是具有时限要求的数据包，如果在设定时长内没有完整接收到用户面功能实体发送的强交互型数据包拆分得到的所有子数据包，那么说明强交互型数据包已经超过了时限要求，此时已经没有必要再传输给用户设备了。当然，如果在设定时长内没有完整接收到用户面功能实体发送的指定类型的强交互型数据包拆分得到的所有子数据包，还可能是由于用户面功能实体检测到有子数据包传输错误然后停止发送了，此时也说明没有必要再传输给用户设备了，在这种情况下也可以停止向用户设备发送，并且可以丢弃已经接收到的子数据包。
在本申请的一个实施例中，如图4所示，前述实施例中多种类型的强交互型数据包可以包括：关键帧(即图4中所示的I帧)对应的强交互型数据包和非关键帧(即图4中所示的P帧)对应的强交互型数据包。由于非关键帧的恢复需要依赖于关键帧，因此如果检测到指定关键帧对应的强交互型数据包所拆分得到的子数据包中存在向用户设备发送失败的数据包，则停止向用户设备发送与指定关键帧相关联的非关键帧所对应的强交互型数据包，和/或丢弃已经接收到的与指定关键帧相关联的非关键帧所对应的强交互型数据包。该实施例的技术方案使得在指定关键帧对应的强交互型数据包拆分得到的子数据包中有发送失败的子数据包时，不仅停止传输该指定关键帧对应的强交互型数据包拆分得到的其它子数据包，而且也应该停止与该指定关键帧相关联的非关键帧所对应的强交互型数据包，具体是停止该相关联的非关键帧所对应的强交互型数据包拆分得到的子数据包的传输，进而可以降低无效数据包对带宽的占用，有利于减少强交互型数据包在传输时对传输资源的占用。
图3是从基站设备的角度对本申请实施例的数据传输方法进行了阐述，以下从用户面功能实体的角度对本申请实施例的数据传输方法进行说明：
图5示出了根据本申请的一个实施例的数据传输方法的流程图，该数据传输方法可以由用户面功能实体来执行。参照图5所示，该数据传输方法至少包括步骤S510至步骤S530，详细介绍如下：
在步骤S510中，接收SMF发送的PDU会话管理策略信息，该PDU会话管理策略信息用于指示多种类型的强交互型数据包在同一个GTP-U隧道中进行区别传输，且通过同一个DRB进行承载。
在本申请的一个实施例中，强交互型数据包的类型可以是根据需要传输的业务内容的类型或者优先级中的至少一种来确定的。比如，强交互型数据包的类型可以包括关键帧对应的强交互型数据包和非关键帧对应的强交互型数据包。关键帧可以是I帧，非关键帧可以是P帧和/或B帧。
在步骤S520中，将接收到的多种类型的强交互型数据包拆分得到的子数据包在同一个GTP-U隧道中分流传输至基站设备，并检测强交互型数据包拆分得到的子数据包中是否存在向基站设备发送失败的子数据包。
在本申请的一个实施例中，强交互型数据包拆分得到的多个子数据包中包含有开始数据包和结束数据包。
在本申请的一个实施例中，可以根据接收到的数据包的协议字段中包含的指示信息，识别接收到的数据包是否属于强交互型数据包拆分得到的子数据包。
在本申请的一个实施例中，可以根据接收到的数据包的净荷信息中包含的指示信息，识别接收到的数据包是否属于强交互型数据包拆分得到的子数据包。
在步骤S530中，若检测到指定类型的强交互型数据包拆分得到的子数据包中存在向基站设备发送失败的子数据包，则停止向基站设备发送指定类型的强交互型数据包拆分得到的其余子数据包。
在本申请的实施例中，如果检测到指定类型的强交互型数据包拆分得到的子数据包中存在向基站设备发送失败的子数据包，那么继续发送该指定类型的强交互型数据包拆分得到的其余子数据包已经没有意义了，因此可以停止向基站设备发送其余子数据包，以降低对带宽的占用，有利于减少强交互型数据包在传输时对传输资源的占用。
在本申请的一个实施例中，如果检测到指定类型的强交互型数据包拆分得到的子数据包中存在向基站设备发送失败的子数据包，那么还可以丢弃已经接收到的该指定类型的强交互型数据包拆分得到的子数据包，以降低对存储资源的占用。
在本申请的一个实施例中，如果检测到指定类型的强交互型数据包拆分得到的子数据包中存在向基站设备发送失败的子数据包，那么可以向应用服务器发送反馈信息，该反馈信息用于指示应用服务器停止传输强交互型数据包拆分得到的子数据包。该实施例的技术方案使得在检测到向基站设备发送的过程中存在发送失败的子数据包时，可以向应用服务器发送反馈信息，以指示应用服务器停止传输其余的子数据包，以避免对传输资源的占用。
在本申请的一个实施例中，向应用服务器发送反馈信息是在未完整接收到该指定类型的强交互型数据包拆分得到的所有子数据包的情况下进行的，如果已经完整接收到指定类型的强交互型数据包拆分得到的所有子数据包，那么无需再向应用服务器发送反馈信息。
在本申请的一个实施例中，如果在设定时长内未完整接收到应用服务器发送的指定类型的强交互型数据包拆分得到的所有子数据包，则停止向基站设备发送该指定类型的强交互型数据包拆分得到的子数据包，并丢弃接收到的该指定类型的强交互型数据包拆分得到的子数据包。在该实施例的技术方案中，强交互型数据包可以是具有时限要求的数据包，如果在设定时长内没有完整接收到应用服务器发送的强交互型数据包拆分得到的所有子数据包，那么说明强交互型数据包已经超过了时限要求，此时已经没有必要再传输给基站设备了。当然，如果在设定时长内没有完整接收到应用服务器发送的指定类型的强交互型数据包拆分得到的所有子数据包，还可能是由于应用服务器检测到有子数据包传输错误然后停止发送了，此时也说明没有必要再传输给基站设备了，在这种情况下也可以停止向基站设备发送，并且可以丢弃已经接收到的子数据包。
在本申请的一个实施例中，如果强交互型数据包包括：关键帧对应的强交互型数据包和非关键帧对应的强交互型数据包，那么由于非关键帧的恢复需要依赖于关键帧，因此如果检测到指定关键帧对应的强交互型数据包所拆分得到的子数据包中存在向基站设备发送失败的数据包，则停止向基站设备发送与指定关键帧相关联的非关键帧所对应的强交互型数据包，和/或丢弃已经接收到的与指定关键帧相关联的非关键帧所对应的强交互型数据包。该实施例的技术方案使得在指定关键帧对应的强交互型数据包拆分得到的子数据包中有发送失败的子数据包时，不仅停止传输该指定关键帧对应的强交互型数据包拆分得到的其它子数据包，而且也应该停止与该指定关键帧相关联的非关键帧所对应的强交互型数据包，具体是停止该相关联的非关键帧所对应的强交互型数据包拆分得到的子数据包的传输，进而可以降低无效数据包对带宽的占用，有利于减少强交互型数据包在传输时对传输资源的占用。
以下从用户设备的角度对本申请实施例的数据传输方法进行说明：
图6示出了根据本申请的一个实施例的数据传输方法的流程图，该数据传输方法可以由用户设备来执行。参照图6所示，该数据传输方法至少包括步骤S610至步骤S630，详细介绍如下：
在步骤S610中，接收AMF发送的URSP规则，该URSP规则用于指示多种类型的强交互型数据包在同一个GTP-U隧道中进行区别传输，且通过同一个DRB进行承载。
在步骤S620中，若识别到基站设备基于DRB发送的数据包属于强交互型数据包拆分得到的子数据包，则在接收强交互型数据包拆分得到的子数据包的过程中，检测对子数据包的接收情况。
在本申请的一个实施例中，强交互型数据包拆分得到的多个子数据包中包含有开始数据包和结束数据包。
在本申请的一个实施例中，可以根据接收到的数据包的协议字段中包含的指示信息，识别接收到的数据包是否属于强交互型数据包拆分得到的子数据包。
在本申请的一个实施例中，可以根据接收到的数据包的净荷信息中包含的指示信息，识别接收到的数据包是否属于强交互型数据包拆分得到的子数据包。
在步骤S630中，若完整接收到指定类型的强交互型数据包拆分得到的所有数据包，则对所有数据包进行整合得到指定类型的强交互型数据包。
在本申请的一个实施例中，在对指定类型的强交互型数据包拆分得到的所有子数据包进行整合处理时，可以按照这些子数据包的顺序依次进行整合，最后得到完整的强交互型数据包。
在本申请的一个实施例中，如果用户设备在设定时长内未完整接收到指定类型的强交互型数据包拆分得到的所有子数据包，则可以丢弃接收到的该指定类型的强交互型数据包拆分得到的子数据包。在该实施例中，强交互型数据包可以是具有时限要求的数据包，如果在设定时长内没有完整接收到强交互型数据包拆分得到的所有子数据包，那么说明强交互型数据包已经超过了时限要求，此时已经没有必要再接收子数据包进行整合处理了，因此可以丢弃到已经接收到的子数据包。当然，如果在设定时长内没有完整接收到强交互型数据包拆分得到的所有子数据包，还可能是由于基站设备检测到有子数据 包传输错误然后停止发送了，此时也可以丢弃已经接收到的子数据包。
在本申请的一个实施例中，如果在设定时长内未完整接收到指定类型的强交互型数据包拆分得到的所有子数据包，则向发送指定类型的强交互型数据包的应用服务器发送反馈信息，以指示强交互型数据包传输失败。该实施例的技术方案使得用户设备在检测到在设定时长内未完整接收到强交互型数据包拆分得到的所有子数据包时，可以向应用服务器发送反馈信息，以向应用服务器指示强交互型数据包传输失败，以便于应用服务器确认是否重新发送。
以下从PCF(Policy Control Function，策略控制功能)的角度对本申请实施例的数据传输方法进行说明：
图7示出了根据本申请的一个实施例的数据传输方法的流程图，该数据传输方法可以由PCF来执行。参照图7所示，该数据传输方法至少包括步骤S710至步骤S740，详细介绍如下：
在步骤S710中，接收AF发送的针对强交互型数据包的GTP-U隧道配置信息，该GTP-U隧道配置信息用于指示多种类型的强交互型数据包在同一个GTP-U隧道中进行区别传输，且通过同一个DRB进行承载。
在本申请的一个实施例中，AF可以直接将针对强交互型数据包的GTP-U隧道配置信息发送给PCF，或者AF也可以通过NEF(Network Exposure Function，网络开放功能)将针对强交互型数据包的GTP-U隧道配置信息发送给PCF。
在步骤S720中，根据GTP-U隧道配置信息生成URSP规则和PDU会话管理策略信息，该URSP规则和PDU会话管理策略信息用于指示多种类型的强交互型数据包在同一个GTP-U隧道中进行区别传输，且通过同一个DRB进行承载。
在步骤S730中，将URSP规则发送至AMF，以使AMF将URSP规则转发至用户设备，并根据URSP规则向基站设备配置接入层上下文信息，接入层上下文信息用于指示多种类型的强交互型数据包在同一个通用分组无线业务隧道协议用户面GTP-U隧道中进行区别传输，且通过同一个数据无线承载DRB进行承载。
在本申请的一个实施例中，AMF可以直接将URSP规则转发给用户设备，同时AMF可以根据该URSP规则生成向基站设备配置的接入层上下文信息，然后由AMF发送给基站设备。
在步骤S740中，将PDU会话管理策略信息发送至SMF，以使SMF将PDU会话管理策略信息配置给用户面功能实体。
在本申请的一个实施例中，SMF可以直接将PDU会话管理策略信息转发给用户面功能实体。
以上实施例分别从用户面功能实体、基站设备、用户设备和PCF的角度对本申请实施例的技术方案进行了阐述，以下从各个实体之间交互的角度进一步阐述本申请实施例的技术方案。
在本申请的一个实施例中，应用服务器可以在应用层把强交互型数据包分类两类，可以理解，该实施例中以两类作为示例，在本申请的其它实施例中，也可以是更多的类，如I帧流和P帧流，并用两个流分别进行传输。通过层间交互机制，把这类信息放在报文头中。在本申请的其它实施例中，也可以不基于I帧和P帧进行划分，而是基于 其它规则，比如基于音视频流内容的优先级等进行分类。
在本申请的一个实施例中，AF可以与PCF进行交互，然后PCF与各网元例如AMF、SMF等进行交互，为两个流进行GTP-U隧道的配置。如图8所示，经过应用层区分的I帧的强交互型数据包和P帧的强交互型数据包在拆分之后，放在一个GTP-U隧道中，到达gNB之后使用同一个DRB承载进行下行传输，以保持与传统PDU会话机制中GTP-U隧道和DRB的一一对应关系，但在GTP-U隧道中使用区分机制来区分来自不同流的数据包。同时，gNB在调度数据传输时，优先保证I帧数据流(即I帧的强交互型数据包拆分得到的子数据包)传输，如果I帧数据流发生丢失，则丢弃I帧的强交互型数据包拆分得到的所有子数据包，以及后续的P帧的强交互型数据包拆分出来的所有子数据包，因为如果I帧丢失，那么P帧即使收到也可能无法进行画面恢复。
在本申请的一个实施例中，在对任一类型的强交互型数据包进行拆分之后，可以对强交互型数据包拆分得到的子数据包进行开始和结束的标示。基于标示出的开始子数据包和结束子数据包，如果一个强交互型数据包拆分出来的N个子数据包中，有部分子数据包发送失败，那么后续的子数据包则无需再进行发送，可以进行丢弃处理。
在本申请的一个实施例中，在对子数据包的传输过程进行管理之前，需要进行控制面的配置过程，使得UE和各个网元都获取到强交互型数据包的传输参数，具体过程如图9所示，包括如下步骤：
步骤S901，AF向PCF配置GTP-U隧道参数。
在本申请的一个实施例中，AF可以通过向PCF配置强交互型数据包的PDU会话策略来配置GTP-U隧道参数。具体地，AF可以直接将强交互型数据包的PDU会话策略发送给PCF，或者AF也可以通过NEF将强交互型数据包的PDU会话策略发送给PCF。其中，GTP-U隧道参数是多种类型的强交互型数据包在同一个GTP-U隧道中进行分流传输，且通过同一个DRB进行承载。
步骤S902，PCF向AMF配置URSP规则。
在本申请的一个实施例中，PCF向AMF配置的URSP规则是与PDU会话相关的，具体包括：多种类型的强交互型数据包在同一个GTP-U隧道中进行分流传输，且通过同一个DRB进行承载。
步骤S903，AMF向UE配置URSP规则。
在本申请的一个实施例中，AMF向UE配置的URSP规则具体包括：多种类型的强交互型数据包在同一个GTP-U隧道中进行分流传输，且通过同一个DRB进行承载。
步骤S904，AMF向gNB配置接入层上下文。
在本申请的一个实施例中，AMF向gNB配置的接入层(Access Stratum，简称AS)上下文(context)是与PDU会话相关的，其中包含了多种类型的强交互型数据包在同一个GTP-U隧道中进行分流传输，且通过同一个DRB进行承载的策略。
步骤S905，PCF向SMF配置PDU会话管理策略。
在本申请的一个实施例中，PDU会话管理策略中包含了多种类型的强交互型数据包在同一个GTP-U隧道中进行分流传输，且通过同一个DRB进行承载的策略。
步骤S906，SMF向UPF配置PDU会话管理策略。
在控制面配置完成之后，强交互型数据包的分段传输(即拆分为子数据包进行传 输)需要遵循以下原则：对于巨大IP包(即强交互型数据包)拆解后形成的多个IP子包，如果部分IP子包发送失败，那么已成功发送的数据包即使已被接收端收到，也应该丢弃；如果仍然有部分IP子包尚未发送，则发送端也应该丢弃，尽快启动下一个强交互型数据包的发送。
需要说明的是，如果应用服务器或者用户设备在应用层重传强交互型数据包，那么可以将重传的数据包标志为一个新的强交互型数据包进行传输，具体的传输方式与本申请实施例中限定的方式一致。
在本申请的一个实施例中，如图10所示，根据本申请的一个实施例的数据传输方法，可以包括如下步骤：
步骤S1010，强交互型数据包在应用服务器侧完成拆分。
在本申请的一个实施例中，应用服务器可以根据设定的子数据包大小或者网络的状态等信息来确定出分包大小，然后根据分包大小来对强交互型数据包进行拆分处理，得到多个子数据包。
步骤S1020，拆分得到的子数据包进行开始数据包和结束数据包的标示。
在本申请的一个实施例中，可以在开始数据包和结束数据包中添加指示信息，以标示出哪个子数据包是开始数据包，哪个子数据包是结束数据包。可选地，可以在数据包的协议字段或者净荷信息中添加该指示信息，如在GTP-U隧道协议的字段中添加该指示信息。
步骤S1030，UPF识别子数据包的开始和结束，同时把不同类型的子数据包放入同一个GTP-U隧道并进行隧道内的区分处理。
在本申请的一个实施例中，当应用服务器把拆分得到的子数据包传输给UPF的过程中，UPF可以识别其中的开始数据包和结束数据包。
步骤S1040，子数据包传输到达gNB，gNB进行发送。
在本申请的一个实施例中，UPF在接收到应用服务器发送的子数据包之后，将子数据包传输给gNB，然后gNB将子数据包发送给用户设备。其中，gNB需要进行增强以能够识别出子数据包中的指示信息，进而来确定开始数据包和结束数据包，以便于识别出强交互型数据包拆分得到的一系列子数据包。同时，gNB把从同一个GTP-U隧道接收到的不同类型的子数据包放入同一个DRB发送给用户设备。
步骤S1050，gNB向用户设备发送第m个子数据包，如果发送成功，则执行步骤S1060；如果发送失败，则执行步骤S1070。
在本申请的一个实施例中，gNB可以通过Uu接口将子数据包发送给用户设备。同时，可以通过Uu接口的协议如PDCP、RLC等进行数据发送成功和失败的判断。
步骤S1060，如果发送成功，则继续发送下一个子数据包，直到拆分出来的子数据包全部发送完成。
步骤S1070，如果发送失败，则在gNB侧丢弃已经接收到的子数据包。此时也不再将UPF发送过来的其它子数据包发送给用户设备。如果发送失败的是I帧的强交互型数据包，那么也丢弃相关联的P帧的强交互型数据包拆分得到的子数据包。
步骤S1080，用户设备探测到强交互型数据包传输失败，从应用层向应用服务器进行反馈。可选地，如果用户设备在一定时限内没有完全接收到强交互型数据包的所有子 数据包，则可以确定强交互型数据包传输失败。其中向应用服务器反馈的信息用于指示该强交互型数据包已经传输失败。
图10所示实施例的技术方案不要求gNB向UPF指示强交互型数据包的传输情况，但是用户设备需要从应用层向应用服务器指示强交互型数据包传输失败。在本申请的另一个实施例中，如图11所示，包括如下步骤：
步骤S1110，强交互型数据包在应用服务器侧完成拆分。
在本申请的一个实施例中，应用服务器可以根据设定的子数据包大小或者网络的状态等信息来确定出分包大小，然后根据分包大小来对强交互型数据包进行拆分处理，得到多个子数据包。
步骤S1120，拆分得到的子数据包进行开始数据包和结束数据包的标示。
在本申请的一个实施例中，可以在开始数据包和结束数据包中添加指示信息，以标示出哪个子数据包是开始数据包，哪个子数据包是结束数据包。可选地，可以在数据包的协议字段或者净荷信息中添加该指示信息，如在GTP-U隧道协议的字段中添加该指示信息。
步骤S1130，UPF识别子数据包的开始和结束，同时把不同类型的子数据包放入同一个GTP-U隧道并进行隧道内的区分处理。
在本申请的一个实施例中，当应用服务器把拆分得到的子数据包传输给UPF的过程中，UPF可以识别其中的开始数据包和结束数据包。
步骤S1140，子数据包传输到达gNB，gNB进行发送。
在本申请的一个实施例中，UPF在接收到应用服务器发送的子数据包之后，将子数据包传输给gNB，然后gNB将子数据包发送给用户设备。其中，gNB需要进行增强以能够识别出子数据包中的指示信息，进而来确定开始数据包和结束数据包，以便于识别出强交互型数据包拆分得到的一系列子数据包。同时，gNB把从同一个GTP-U隧道接收到的不同类型的子数据包放入同一个DRB发送给用户设备。
步骤S1150，gNB向用户设备发送第m个子数据包，如果发送成功，则执行步骤S1160；如果发送失败，则执行步骤S1170。
在本申请的一个实施例中，gNB可以通过Uu接口将子数据包发送给用户设备。同时，可以通过Uu接口的协议如PDCP、RLC等进行数据发送成功和失败的判断。
步骤S1160，如果发送成功，则继续发送下一个子数据包，直到拆分出来的子数据包全部发送完成。
步骤S1170，如果发送失败，则在gNB侧丢弃已经接收到的子数据包。此时也不再将UPF发送过来的其它子数据包发送给用户设备。如果发送失败的是I帧的强交互型数据包，那么也丢弃相关联的P帧的强交互型数据包拆分得到的子数据包。
步骤S1180，gNB向UPF提供反馈信息，通知UPF停止向其发送子数据包。需要说明的是，如果gNB已经完整接收了强交互型数据包拆分得到的所有子数据包，那么无需再向UPF提供反馈信息。
在本申请的一个实施例中，图10和图11所示实施例的技术方案也可以进行结合，即不仅用户设备在探测到强交互型数据包传输失败时，从应用层向应用服务器进行反馈，而且gNB在确定发送失败之后，也可以向UPF提供反馈信息，通知UPF停止向 其发送子数据包。
综上，在本申请的一个实施例中，当各节点配置强交互型数据包的传输参数之后，如图12所示为应用服务器、UPF、gNB和用户设备之间的交互流程，具体包括如下步骤：
步骤S1201，应用服务器拆分强交互型数据包得到子数据包，并标示出开始数据包和结束数据包。
在本申请的一个实施例中，可以在开始数据包和结束数据包中添加指示信息，以标示出哪个子数据包是开始数据包，哪个子数据包是结束数据包。可选地，可以在数据包的协议字段或者净荷信息中添加该指示信息，如在GTP-U隧道协议的字段中添加该指示信息。
步骤S1202，应用服务器向UPF发送子数据包。
在本申请的一个实施例中，当应用服务器把拆分得到的子数据包传输给UPF的过程中，UPF可以识别其中的开始数据包和结束数据包。
步骤S1203，UPF向gNB发送子数据包。
在本申请的一个实施例中，UPF可以将不同类型的子数据包放入同一个GTP-U隧道传输给gNB，并且不同类型的子数据包可以在隧道内进行区分处理。
可选地，UPF向gNB发送子数据包的过程与应用服务器向UPF发送子数据包的过程可以是同步进行的，比如UPF在接收到应用服务器发送的子数据包之后，且还未全部接收完成，就可以向gNB发送子数据包，这种方式可以降低子数据包到达用户设备的延迟。当然，UPF也可以在全部接收到应用服务器发送的子数据包之后，再向gNB发送子数据包，这种方式的好处是：可以避免UPF在接收过程中出现错误导致先向gNB发送的子数据包无效而浪费了传输资源的问题。
在本申请的一个实施例中，UPF在向gNB发送强交互型数据包拆分得到的子数据包的过程中，如果检测到某个类型的强交互型数据包拆分得到的子数据包传输失败或者检测到子数据包传输超过延迟要求，那么UPF可以停止向gNB发送该类型的强交互型数据包的其余子数据包，避免继续发送而占用传输资源。在这种情况下，UPF也可以删除已经接收到的该类型的强交互型数据包拆分得到的子数据包，同时UPF也可以通知应用服务器停止向UPF传输该类型的强交互型数据包拆分得到的子数据包。
在本申请的一个实施例中，UPF也可以在一定时长内未全部接收到应用服务器传输的某个类型的强交互型数据包拆分得到的子数据包时，停止向gNB发送该类型的强交互型数据包拆分得到的子数据包，并且UPF也可以删除已经接收到的该类型的强交互型数据包拆分得到的子数据包，同时UPF也可以通知应用服务器停止向UPF传输该类型的强交互型数据包拆分得到的子数据包。
步骤S1204，gNB向用户设备发送子数据包。
在本申请的一个实施例中，gNB可以通过同一个DRB承载将不同类型的强交互型数据包拆分得到的子数据包传输给用户设备。
可选地，gNB向用户设备发送子数据包的过程与UPF向gNB发送子数据包的过程可以是同步进行的，比如gNB在接收到UPF发送的子数据包之后，且处于还未全部接收完成的状态下，就可以向用户设备发送子数据包，这种方式可以降低子数据包到达用 户设备的延迟。当然，gNB也可以在全部接收到UPF发送的子数据包之后，再向用户设备发送子数据包，这种方式的好处是：可以避免gNB在接收过程中出现错误导致先向用户设备发送的子数据包无效而浪费了传输资源的问题。
在本申请的一个实施例中，gNB在向用户设备发送强交互型数据包拆分得到的子数据包的过程中，如果检测到某个类型的强交互型数据包拆分得到的子数据包传输失败或者检测到子数据包传输超过延迟要求，那么gNB可以停止向用户设备发送该类型的强交互型数据包拆分得到的其余子数据包，避免继续发送而占用传输资源。在这种情况下，gNB也可以删除已经接收到的该类型的强交互型数据包拆分得到的子数据包，同时gNB也可以通知UPF停止向gNB传输该类型的强交互型数据包拆分得到的子数据包。
在本申请的一个实施例中，gNB也可以在一定时长内未全部接收到UPF传输的某个类型的强交互型数据包拆分得到的子数据包时，停止向用户设备发送该类型的强交互型数据包拆分得到的子数据包，并且gNB也可以删除已经接收到的该类型的强交互型数据包拆分得到的子数据包，同时gNB也可以通知UPF停止向gNB传输该类型的强交互型数据包拆分得到的子数据包。
步骤S1205，用户设备若接收所有子数据包成功，则进行重组恢复出强交互型数据包。
在本申请的一个实施例中，如果用户设备探测到某个类型的强交互型数据包传输失败，则可以从应用层向应用服务器进行反馈。可选地，如果用户设备在一定时限内没有完全接收到某个类型的强交互型数据包的所有子数据包，则可以确定该类型的强交互型数据包传输失败。其中向应用服务器反馈的信息用于指示该类型的强交互型数据包已经传输失败。
本申请上述实施例的技术方案可以将多种类型的强交互型数据包在同一个GTP-U隧道中进行传输且对应于同一个DRB承载，使得可以在支持传输多种类型的强交互型数据包的前提下，降低对协议侧的影响。同时可以在强交互型数据包拆分得到的子数据包发送失败或者发送超过延迟要求时，避免继续向下一级节点发送其余子数据包而导致对带宽的占用，有利于减少强交互型数据包在传输时对传输资源的占用。
应该理解的是，虽然上述实施例的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，上述实施例的流程图中的至少一部分步骤可以包括多个步骤或者多个阶段，这些步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。
以下介绍本申请的装置实施例，可以用于执行本申请上述实施例中的数据传输方法。对于本申请装置实施例中未披露的细节，请参照本申请上述的数据传输方法的实施例。
图13示出了根据本申请的一个实施例的数据传输装置的框图，该数据传输装置可以设置在基站设备内部。
参照图13所示，根据本申请的一个实施例的数据传输装置1300，包括：第一接收单元1302、第一检测单元1304和第一处理单元1306。
其中，第一接收单元1302配置为接收AMF发送的接入层上下文信息，所述接入层上下文信息用于指示多种类型的强交互型数据包在同一个GTP-U隧道中进行区别传输，且通过同一个DRB进行承载；第一检测单元1304配置为若识别到用户面功能实体通过所述GTP-U隧道发送的数据包属于所述强交互型数据包拆分得到的子数据包，则在将所述强交互型数据包拆分得到的子数据包基于所述DRB发送至用户设备的过程中，检测所述强交互型数据包拆分得到的子数据包中是否存在向所述用户设备发送失败的子数据包；第一处理单元1306配置为若检测到指定类型的强交互型数据包拆分得到的子数据包中存在向所述用户设备发送失败的子数据包，则停止向所述用户设备发送所述指定类型的强交互型数据包拆分得到的其余子数据包。
在本申请的一些实施例中，基于前述方案，第一处理单元1306还配置为：若检测到所述指定类型的强交互型数据包拆分得到的子数据包中存在向所述用户设备发送失败的子数据包，则丢弃已经接收到的所述指定类型的强交互型数据包拆分得到的子数据包。
在本申请的一些实施例中，基于前述方案，第一处理单元1306还配置为：若检测到所述指定类型的强交互型数据包拆分得到的子数据包中存在向所述用户设备发送失败的子数据包，则向所述用户面功能实体发送反馈信息，所述反馈信息用于指示所述用户面功能实体停止传输所述指定类型的强交互型数据包拆分得到子数据包。
在本申请的一些实施例中，基于前述方案，第一处理单元1306配置为：若未完整接收到所述指定类型的强交互型数据包拆分得到的所有子数据包，则向所述用户面功能实体发送反馈信息。
在本申请的一些实施例中，基于前述方案，所述强交互型数据包拆分得到的多个子数据包中包含有开始数据包和结束数据包；所述开始数据包中包含有第一指示信息，所述第一指示信息用于指示所述开始数据包是所述多个子数据包中第一个传输的子数据包；所述结束数据包中包含有第二指示信息，所述第二指示信息用于指示所述结束数据包是所述多个子数据包中最后一个传输的子数据包。
在本申请的一些实施例中，基于前述方案，第一检测单元1304还配置为：根据接收到的数据包的协议字段中包含的指示信息，识别接收到的数据包是否属于所述强交互型数据包拆分得到的子数据包。
在本申请的一些实施例中，基于前述方案，第一检测单元1304还配置为：根据接收到的数据包的净荷信息中包含的指示信息，识别接收到的数据包是否属于所述强交互型数据包拆分得到的子数据包。
在本申请的一些实施例中，基于前述方案，第一处理单元1306还配置为：若在设定时长内未完整接收到所述用户面功能实体发送的指定类型的强交互型数据包拆分得到的所有子数据包，则停止向所述用户设备发送所述指定类型的强交互型数据包拆分得到的子数据包，并丢弃已经接收到的所述指定类型的强交互型数据包拆分得到的子数据包。
在本申请的一些实施例中，基于前述方案，所述多种类型的强交互型数据包包括： 关键帧对应的强交互型数据包和非关键帧对应的强交互型数据包；第一处理单元1306还配置为：若检测到指定关键帧对应的强交互型数据包所拆分得到的子数据包中存在向所述用户设备发送失败的数据包，则停止向所述用户设备发送与所述指定关键帧相关联的非关键帧所对应的强交互型数据包，和/或丢弃已经接收到的与所述指定关键帧相关联的非关键帧所对应的强交互型数据包。
图14示出了根据本申请的一个实施例的数据传输装置的框图，该数据传输装置可以设置在用户面功能实体内部。
参照图14所示，根据本申请的一个实施例的数据传输装置1400，包括：第二接收单元1402、第二检测单元1404和第二处理单元1406。
其中，第二接收单元1402配置为接收SMF发送的PDU会话管理策略信息，所述PDU会话管理策略信息用于指示多种类型的强交互型数据包在同一个GTP-U隧道中进行区别传输，且通过同一个DRB进行承载；第二检测单元1404配置为将接收到的所述多种类型的强交互型数据包拆分得到的子数据包在所述GTP-U隧道中分流传输至基站设备，并检测所述强交互型数据包拆分得到的子数据包中是否存在向所述基站设备发送失败的子数据包；第二处理单元1406配置为若检测到指定类型的强交互型数据包拆分得到的子数据包中存在向所述基站设备发送失败的子数据包，则停止向所述基站设备发送所述指定类型的强交互型数据包拆分得到的其余子数据包。
在本申请的一些实施例中，基于前述方案，第二处理单元1406还配置为：若检测到所述指定类型的强交互型数据包拆分得到的子数据包中存在向所述基站设备发送失败的子数据包，则丢弃已经接收到的所述指定类型的强交互型数据包拆分得到的子数据包。
在本申请的一些实施例中，基于前述方案，第二处理单元1406还配置为：若检测到所述指定类型的强交互型数据包拆分得到的子数据包中存在向所述基站设备发送失败的子数据包，则向应用服务器发送反馈信息，所述反馈信息用于指示所述应用服务器停止传输所述指定类型的强交互型数据包拆分得到子数据包。
在本申请的一些实施例中，基于前述方案，第二处理单元1406配置为：若未完整接收到所述指定类型的强交互型数据包拆分得到的所有子数据包，则向所述应用服务器发送反馈信息。
在本申请的一些实施例中，基于前述方案，第二处理单元1406还配置为：若在设定时长内未完整接收到所述指定类型的强交互型数据包拆分得到的所有子数据包，则停止向所述基站设备发送所述指定类型的强交互型数据包拆分得到的子数据包，并丢弃已经接收到的所述指定类型的强交互型数据包拆分得到的子数据包。
在本申请的一些实施例中，基于前述方案，所述多种类型的强交互型数据包包括：关键帧对应的强交互型数据包和非关键帧对应的强交互型数据包；第二处理单元1406还配置为：若检测到指定关键帧对应的强交互型数据包所拆分得到的子数据包中存在向所述基站设备发送失败的数据包，则停止向所述基站设备发送与所述指定关键帧相关联的非关键帧所对应的强交互型数据包，和/或丢弃已经接收到的与所述指定关键帧相关联的非关键帧所对应的强交互型数据包。
图15示出了根据本申请的一个实施例的数据传输装置的框图，该数据传输装置可 以设置在用户设备内部。
参照图15所示，根据本申请的一个实施例的数据传输装置1500，包括：第三接收单元1502、第三检测单元1504和第三处理单元1506。
其中，第三接收单元1502配置为接收AMF发送的URSP规则，所述URSP规则用于指示多种类型的强交互型数据包在同一个GTP-U隧道中进行区别传输，且通过同一个DRB进行承载；第三检测单元1504配置为若识别到基站设备基于所述DRB发送的数据包属于所述强交互型数据包拆分得到的子数据包，则在接收所述强交互型数据包拆分得到的子数据包的过程中，检测对所述子数据包的接收情况；第三处理单元1506配置为若完整接收到指定类型的强交互型数据包拆分得到的所有数据包，则对所述所有数据包进行整合得到所述指定类型的强交互型数据包。
在本申请的一些实施例中，基于前述方案，第三处理单元1506还配置为：若在设定时长内未完整接收到所述指定类型的强交互型数据包拆分得到的所有子数据包，则丢弃已经接收到的所述指定类型的强交互型数据包拆分得到的子数据包。
在本申请的一些实施例中，基于前述方案，第三处理单元1506还配置为：若在设定时长内未完整接收到所述指定类型的强交互型数据包拆分得到的所有数据包，则向发送所述指定类型的强交互型数据包的应用服务器发送反馈信息，以指示所述指定类型的强交互型数据包传输失败。
图16示出了根据本申请的一个实施例的数据传输装置的框图，该数据传输装置可以设置在PCF内部。
参照图16所示，根据本申请的一个实施例的数据传输装置1600，包括：第四接收单元1602、生成单元1604、第一发送单元1606和第二发送单元1608。
其中，第四接收单元1602配置为接收AF发送的针对强交互型数据包的GTP-U隧道配置信息，所述GTP-U隧道配置信息用于指示多种类型的强交互型数据包在同一个GTP-U隧道中进行区别传输，且通过同一个DRB进行承载；生成单元1604配置为根据所述GTP-U隧道配置信息生成URSP规则和PDU会话管理策略信息，所述URSP规则和所述PDU会话管理策略信息用于指示所述多种类型的强交互型数据包在同一个GTP-U隧道中进行区别传输，且通过同一个DRB进行承载；第一发送单元1606配置为将所述URSP规则发送至AMF，以使所述AMF将所述URSP规则转发至用户设备，并根据所述URSP规则向基站设备配置接入层上下文信息，所述接入层上下文信息用于指示所述多种类型的强交互型数据包在同一个GTP-U隧道中进行区别传输，且通过同一个DRB进行承载；第二发送单元1608配置为将所述PDU会话管理策略信息发送至SMF，以使所述SMF将所述PDU会话管理策略信息配置给用户面功能实体。
图17示出了适于用来实现本申请实施例的电子设备的计算机系统的结构示意图。
需要说明的是，图17示出的电子设备的计算机系统1700仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。
如图17所示，计算机系统1700包括中央处理单元(Central Processing Unit，CPU)1701，其可以根据存储在只读存储器(Read-Only Memory，ROM)1702中的计算机可读指令或者从存储部分1708加载到随机访问存储器(Random Access Memory，RAM)1703中的计算机可读指令而执行各种适当的动作和处理，例如执行上述实施例 中所述的方法。在RAM 1703中，还存储有系统操作所需的各种计算机可读指令和数据。CPU 1701、ROM 1702以及RAM 1703通过总线1704彼此相连。输入/输出(Input/Output，I/O)接口1705也连接至总线1704。
以下部件连接至I/O接口1705：包括键盘、鼠标等的输入部分1706；包括诸如阴极射线管(Cathode Ray Tube，CRT)、液晶显示器(Liquid Crystal Display，LCD)等以及扬声器等的输出部分1707；包括硬盘等的存储部分1708；以及包括诸如LAN(Local Area Network，局域网)卡、调制解调器等的网络接口卡的通信部分1709。通信部分1709经由诸如因特网的网络执行通信处理。驱动器1710也根据需要连接至I/O接口1705。可拆卸介质1711，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器1710上，以便于从其上读出的计算机可读指令根据需要被安装入存储部分1708。
特别地，根据本申请的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本申请的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的计算机可读指令。在这样的实施例中，该计算机程序可以通过通信部分1709从网络上被下载和安装，和/或从可拆卸介质1711被安装。在该计算机可读指令被中央处理单元(CPU)1701执行时，执行本申请的系统中限定的各种功能。
需要说明的是，本申请实施例所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(Erasable Programmable Read Only Memory，EPROM)、闪存、光纤、便携式紧凑磁盘只读存储器(Compact Disc Read-Only Memory，CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读存储介质可以是任何包含或存储计算机可读指令的有形介质，该计算机可读指令可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本申请中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的计算机可读指令。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的计算机可读指令。计算机可读介质上包含的计算机可读指令可以用任何适当的介质传输，包括但不限于：无线或者有线等等，或者上述的任意合适的组合。
附图中的流程图和框图，图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。其中，流程图或框图中的每个方框可以代表一个模块、计算机可读指令段、或代码的一部分，上述模块、计算机可读指令段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。 例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。
描述于本申请实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现，所描述的单元也可以设置在处理器中。其中，这些单元的名称在某种情况下并不构成对该单元本身的限定。
作为另一方面，本申请还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。上述计算机可读介质承载有一个或者多个计算机可读指令，当上述一个或者多个计算机可读指令被一个该电子设备执行时，使得该电子设备实现上述实施例中所述的方法。
应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本申请的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。
通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本申请实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质或网络上，包括若干指令以使得一台计算设备执行根据本申请实施方式的方法。非易失性存储介质例如可以是CD-ROM、U盘或者移动硬盘等。计算设备可以是个人计算机、服务器、触控终端或者网络设备等。

Claims (24)

  1. 一种数据传输方法，其特征在于，包括：
    接收接入与移动性管理功能AMF发送的接入层上下文信息，所述接入层上下文信息用于指示多种类型的强交互型数据包在同一个通用分组无线业务隧道协议用户面GTP-U隧道中进行区别传输，且通过同一个数据无线承载DRB进行承载；
    若识别到用户面功能实体通过所述GTP-U隧道发送的数据包属于所述强交互型数据包拆分得到的子数据包，则在将所述强交互型数据包拆分得到的子数据包基于所述DRB发送至用户设备的过程中，检测所述强交互型数据包拆分得到的子数据包中是否存在向所述用户设备发送失败的子数据包；
    若检测到指定类型的强交互型数据包拆分得到的子数据包中存在向所述用户设备发送失败的子数据包，则停止向所述用户设备发送所述指定类型的强交互型数据包拆分得到的其余子数据包。
  2. 根据权利要求1所述的数据传输方法，其特征在于，所述数据传输方法还包括：
    若检测到所述指定类型的强交互型数据包拆分得到的子数据包中存在向所述用户设备发送失败的子数据包，则丢弃已经接收到的所述指定类型的强交互型数据包拆分得到的子数据包。
  3. 根据权利要求1所述的数据传输方法，其特征在于，所述数据传输方法还包括：
    若检测到所述指定类型的强交互型数据包拆分得到的子数据包中存在向所述用户设备发送失败的子数据包，则向所述用户面功能实体发送反馈信息，所述反馈信息用于指示所述用户面功能实体停止传输所述指定类型的强交互型数据包拆分得到子数据包。
  4. 根据权利要求3所述的数据传输方法，其特征在于，向所述用户面功能实体发送反馈信息，包括：
    若未完整接收到所述指定类型的强交互型数据包拆分得到的所有子数据包，则向所述用户面功能实体发送反馈信息。
  5. 根据权利要求1所述的数据传输方法，其特征在于，所述强交互型数据包拆分得到的多个子数据包中包含有开始数据包和结束数据包；
    所述开始数据包中包含有第一指示信息，所述第一指示信息用于指示所述开始数据包是所述多个子数据包中第一个传输的子数据包；
    所述结束数据包中包含有第二指示信息，所述第二指示信息用于指示所述结束数据包是所述多个子数据包中最后一个传输的子数据包。
  6. 根据权利要求1所述的数据传输方法，其特征在于，所述数据传输方法还包括：
    根据接收到的数据包的协议字段中包含的指示信息，识别接收到的数据包是否属于所述强交互型数据包拆分得到的子数据包；或
    根据接收到的数据包的净荷信息中包含的指示信息，识别接收到的数据包是否属于所述强交互型数据包拆分得到的子数据包。
  7. 根据权利要求1所述的数据传输方法，其特征在于，所述数据传输方法还包括：
    若在设定时长内未完整接收到所述用户面功能实体发送的指定类型的强交互型数据包拆分得到的所有子数据包，则停止向所述用户设备发送所述指定类型的强交互型数据包拆分得到的子数据包，并丢弃已经接收到的所述指定类型的强交互型数据包拆分得到的子数据包。
  8. 根据权利要求1至7中任一项所述的数据传输方法，其特征在于，所述多种类型的强交互型数据包包括：关键帧对应的强交互型数据包和非关键帧对应的强交互型数据包；
    所述数据传输方法还包括：
    若检测到指定关键帧对应的强交互型数据包所拆分得到的子数据包中存在向所述用户设备发送失败的数据包，则停止向所述用户设备发送与所述指定关键帧相关联的非关键帧所对应的强交互型数据包，和/或丢弃已经接收到的与所述指定关键帧相关联的非关键帧所对应的强交互型数据包。
  9. 一种数据传输方法，其特征在于，包括：
    接收会话管理功能SMF发送的协议数据单元PDU会话管理策略信息，所述PDU会话管理策略信息用于指示多种类型的强交互型数据包在同一个GTP-U隧道中进行区别传输，且通过同一个DRB进行承载；
    将接收到的所述多种类型的强交互型数据包拆分得到的子数据包在所述GTP-U隧道中分流传输至基站设备，并检测所述强交互型数据包拆分得到的子数据包中是否存在向所述基站设备发送失败的子数据包；
    若检测到指定类型的强交互型数据包拆分得到的子数据包中存在向所述基站设备发送失败的子数据包，则停止向所述基站设备发送所述指定类型的强交互型数据包拆分得到的其余子数据包。
  10. 根据权利要求9所述的数据传输方法，其特征在于，所述数据传输方法还包括：
    若检测到所述指定类型的强交互型数据包拆分得到的子数据包中存在向所述基站设备发送失败的子数据包，则丢弃已经接收到的所述指定类型的强交互型数据包拆分得到的子数据包。
  11. 根据权利要求9所述的数据传输方法，其特征在于，所述数据传输方法还包括：
    若检测到所述指定类型的强交互型数据包拆分得到的子数据包中存在向所述基站设备发送失败的子数据包，则向应用服务器发送反馈信息，所述反馈信息用于指示所述应用服务器停止传输所述指定类型的强交互型数据包拆分得到子数据包。
  12. 根据权利要求11所述的数据传输方法，其特征在于，向应用服务器发送反馈信息，包括：
    若未完整接收到所述指定类型的强交互型数据包拆分得到的所有子数据包，则向所述应用服务器发送反馈信息。
  13. 根据权利要求9所述的数据传输方法，其特征在于，所述数据传输方法还包 括：
    若在设定时长内未完整接收到所述指定类型的强交互型数据包拆分得到的所有子数据包，则停止向所述基站设备发送所述指定类型的强交互型数据包拆分得到的子数据包，并丢弃已经接收到的所述指定类型的强交互型数据包拆分得到的子数据包。
  14. 根据权利要求9至13中任一项所述的数据传输方法，其特征在于，所述多种类型的强交互型数据包包括：关键帧对应的强交互型数据包和非关键帧对应的强交互型数据包；
    所述数据传输方法还包括：
    若检测到指定关键帧对应的强交互型数据包所拆分得到的子数据包中存在向所述基站设备发送失败的数据包，则停止向所述基站设备发送与所述指定关键帧相关联的非关键帧所对应的强交互型数据包，和/或丢弃已经接收到的与所述指定关键帧相关联的非关键帧所对应的强交互型数据包。
  15. 一种数据传输方法，其特征在于，包括：
    接收AMF发送的用户设备路由选择策略URSP规则，所述URSP规则用于指示多种类型的强交互型数据包在同一个GTP-U隧道中进行区别传输，且通过同一个DRB进行承载；
    若识别到基站设备基于所述DRB发送的数据包属于所述强交互型数据包拆分得到的子数据包，则在接收所述强交互型数据包拆分得到的子数据包的过程中，检测对所述子数据包的接收情况；
    若完整接收到指定类型的强交互型数据包拆分得到的所有数据包，则对所述所有数据包进行整合得到所述指定类型的强交互型数据包。
  16. 根据权利要求15所述的数据传输方法，其特征在于，所述数据传输方法还包括：
    若在设定时长内未完整接收到所述指定类型的强交互型数据包拆分得到的所有子数据包，则丢弃已经接收到的所述指定类型的强交互型数据包拆分得到的子数据包。
  17. 根据权利要求15所述的数据传输方法，其特征在于，所述数据传输方法还包括：
    若在设定时长内未完整接收到所述指定类型的强交互型数据包拆分得到的所有数据包，则向发送所述指定类型的强交互型数据包的应用服务器发送反馈信息，以指示所述指定类型的强交互型数据包传输失败。
  18. 一种数据传输方法，其特征在于，包括：
    接收应用功能AF发送的针对强交互型数据包的GTP-U隧道配置信息，所述GTP-U隧道配置信息用于指示多种类型的强交互型数据包在同一个GTP-U隧道中进行区别传输，且通过同一个DRB进行承载；
    根据所述GTP-U隧道配置信息生成URSP规则和协议数据单元PDU会话管理策略信息，所述URSP规则和所述PDU会话管理策略信息用于指示所述多种类型的强交互型数据包在同一个GTP-U隧道中进行区别传输，且通过同一个DRB进行承载；
    将所述URSP规则发送至AMF，以使所述AMF将所述URSP规则转发至用户设备，并根据所述URSP规则向基站设备配置接入层上下文信息，所述接入层上下文信息 用于指示所述多种类型的强交互型数据包在同一个通用分组无线业务隧道协议用户面GTP-U隧道中进行区别传输，且通过同一个数据无线承载DRB进行承载；
    将所述PDU会话管理策略信息发送至SMF，以使所述SMF将所述PDU会话管理策略信息配置给用户面功能实体。
  19. 一种数据传输装置，其特征在于，包括：
    第一接收单元，配置为接收AMF发送的接入层上下文信息，所述接入层上下文信息用于指示多种类型的强交互型数据包在同一个GTP-U隧道中进行区别传输，且通过同一个DRB进行承载；
    第一检测单元，配置为若识别到用户面功能实体通过所述GTP-U隧道发送的数据包属于所述强交互型数据包拆分得到的子数据包，则在将所述强交互型数据包拆分得到的子数据包基于所述DRB发送至用户设备的过程中，检测所述强交互型数据包拆分得到的子数据包中是否存在向所述用户设备发送失败的子数据包；
    第一处理单元，配置为若检测到指定类型的强交互型数据包拆分得到的子数据包中存在向所述用户设备发送失败的子数据包，则停止向所述用户设备发送所述指定类型的强交互型数据包拆分得到的其余子数据包。
  20. 一种数据传输装置，其特征在于，包括：
    第二接收单元，配置为接收SMF发送的PDU会话管理策略信息，所述PDU会话管理策略信息用于指示多种类型的强交互型数据包在同一个GTP-U隧道中进行区别传输，且通过同一个DRB进行承载；
    第二检测单元，配置为将接收到的所述多种类型的强交互型数据包拆分得到的子数据包在所述GTP-U隧道中分流传输至基站设备，并检测所述强交互型数据包拆分得到的子数据包中是否存在向所述基站设备发送失败的子数据包；
    第二处理单元，配置为若检测到指定类型的强交互型数据包拆分得到的子数据包中存在向所述基站设备发送失败的子数据包，则停止向所述基站设备发送所述指定类型的强交互型数据包拆分得到的其余子数据包。
  21. 一种数据传输装置，其特征在于，包括：
    第三接收单元，配置为接收AMF发送的URSP规则，所述URSP规则用于指示多种类型的强交互型数据包在同一个GTP-U隧道中进行区别传输，且通过同一个DRB进行承载；
    第三检测单元，配置为若识别到基站设备基于所述DRB发送的数据包属于所述强交互型数据包拆分得到的子数据包，则在接收所述强交互型数据包拆分得到的子数据包的过程中，检测对所述子数据包的接收情况；
    第三处理单元，配置为若完整接收到指定类型的强交互型数据包拆分得到的所有数据包，则对所述所有数据包进行整合得到所述指定类型的强交互型数据包。
  22. 一种数据传输装置，其特征在于，包括：
    第四接收单元，配置为接收AF发送的针对强交互型数据包的GTP-U隧道配置信息，所述GTP-U隧道配置信息用于指示多种类型的强交互型数据包在同一个GTP-U隧道中进行区别传输，且通过同一个DRB进行承载；
    生成单元，配置为根据所述GTP-U隧道配置信息生成URSP规则和PDU会话管理 策略信息，所述URSP规则和所述PDU会话管理策略信息用于指示所述多种类型的强交互型数据包在同一个GTP-U隧道中进行区别传输，且通过同一个DRB进行承载；
    第一发送单元，配置为将所述URSP规则发送至AMF，以使所述AMF将所述URSP规则转发至用户设备，并根据所述URSP规则向基站设备配置接入层上下文信息，所述接入层上下文信息用于指示所述多种类型的强交互型数据包在同一个GTP-U隧道中进行区别传输，且通过同一个数据无线承载DRB进行承载；
    第二发送单元，配置为将所述PDU会话管理策略信息发送至SMF，以使所述SMF将所述PDU会话管理策略信息配置给用户面功能实体。
  23. 一种计算机可读介质，其上存储有计算机可读指令，其特征在于，所述计算机可读指令被处理器执行时实现如权利要求1至8中任一项所述的数据传输方法；或实现如权利要求9至14中任一项所述的数据传输方法；或实现如权利要求15至17中任一项所述的数据传输方法；或实现如权利要求18所述的数据传输方法。
  24. 一种电子设备，其特征在于，包括：
    一个或多个处理器；
    存储装置，用于存储一个或多个计算机可读指令，当所述一个或多个计算机可读指令被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如权利要求1至8中任一项所述的数据传输方法；或实现如权利要求9至14中任一项所述的数据传输方法；或实现如权利要求15至17中任一项所述的数据传输方法；或实现如权利要求18所述的数据传输方法。
PCT/CN2021/120129 2021-01-04 2021-09-24 数据传输方法、装置、计算机可读介质及电子设备 WO2022142516A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US17/986,506 US20230070702A1 (en) 2021-01-04 2022-11-14 Data transmission method and apparatus, computer readable medium, and electronic device

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202110003827.8 2021-01-04
CN202110003827.8A CN112804710B (zh) 2021-01-04 2021-01-04 数据传输方法、装置、计算机可读介质及电子设备

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/986,506 Continuation US20230070702A1 (en) 2021-01-04 2022-11-14 Data transmission method and apparatus, computer readable medium, and electronic device

Publications (1)

Publication Number Publication Date
WO2022142516A1 true WO2022142516A1 (zh) 2022-07-07

Family

ID=75807910

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/120129 WO2022142516A1 (zh) 2021-01-04 2021-09-24 数据传输方法、装置、计算机可读介质及电子设备

Country Status (3)

Country Link
US (1) US20230070702A1 (zh)
CN (1) CN112804710B (zh)
WO (1) WO2022142516A1 (zh)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112804710B (zh) * 2021-01-04 2024-05-07 腾讯科技（深圳）有限公司 数据传输方法、装置、计算机可读介质及电子设备
CN115835400A (zh) * 2021-09-16 2023-03-21 大唐移动通信设备有限公司 数据传输方法、装置及存储介质
WO2023115477A1 (en) * 2021-12-23 2023-06-29 Lenovo (Beijing) Limited Methods and apparatuses for supporting a packet discarding operation in rlc layer due to a packet loss
CN114286447A (zh) * 2021-12-27 2022-04-05 中国联合网络通信集团有限公司 调度优先级的调整方法、设备及存储介质
CN116567657A (zh) * 2022-01-28 2023-08-08 腾讯科技（深圳）有限公司 数据传输方法、装置、计算机可读介质及电子设备
CN117459994A (zh) * 2022-07-18 2024-01-26 维沃移动通信有限公司 数据包处理方法、终端及网络侧设备
WO2024065542A1 (zh) * 2022-09-29 2024-04-04 北京小米移动软件有限公司 一种发送数据包的方法、装置、电子设备及可读存储介质

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101127918A (zh) * 2007-09-25 2008-02-20 腾讯科技（深圳）有限公司 一种视频容错控制系统及方法
CN102547375A (zh) * 2010-12-23 2012-07-04 上海讯垒网络科技有限公司 一种快速实现预览h.264编码帧的传输方法
WO2018039179A1 (en) * 2016-08-22 2018-03-01 Intel IP Corporation Enhanced key frame protection on cellular networks
CN108366306A (zh) * 2017-12-13 2018-08-03 天津天地伟业机器人技术有限公司 一种基于嵌入式设备的码流传输的控制方法
CN112770312A (zh) * 2021-01-04 2021-05-07 腾讯科技（深圳）有限公司 数据传输方法、装置、计算机可读介质及电子设备
CN112804710A (zh) * 2021-01-04 2021-05-14 腾讯科技（深圳）有限公司 数据传输方法、装置、计算机可读介质及电子设备
CN112804711A (zh) * 2021-01-04 2021-05-14 腾讯科技（深圳）有限公司 数据传输方法、装置、计算机可读介质及电子设备

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3435705B1 (en) * 2017-07-26 2021-03-31 NTT DoCoMo, Inc. Communication relay and method for redirecting data packets
US20190215729A1 (en) * 2018-03-15 2019-07-11 Intel Corporation Session description protocol mechanisms for signaling radio access network capabilities in multimedia telephony sessions
CN110475267B (zh) * 2018-05-11 2021-09-17 华为技术有限公司 一种配置方法、数据传输方法和装置
US11032873B2 (en) * 2018-05-22 2021-06-08 Apple Inc. Session continuity in mobile systems using user plane functions with uplink classifier
US10681607B2 (en) * 2018-06-22 2020-06-09 Intel Corporation Receive-side scaling for wireless communication devices
CN110636544B (zh) * 2018-06-22 2022-09-23 华为技术有限公司 一种数据传输方法及装置
CN111757399B (zh) * 2019-03-29 2021-09-07 华为技术有限公司 无线通信系统中的切换方法、装置及系统

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101127918A (zh) * 2007-09-25 2008-02-20 腾讯科技（深圳）有限公司 一种视频容错控制系统及方法
CN102547375A (zh) * 2010-12-23 2012-07-04 上海讯垒网络科技有限公司 一种快速实现预览h.264编码帧的传输方法
WO2018039179A1 (en) * 2016-08-22 2018-03-01 Intel IP Corporation Enhanced key frame protection on cellular networks
CN108366306A (zh) * 2017-12-13 2018-08-03 天津天地伟业机器人技术有限公司 一种基于嵌入式设备的码流传输的控制方法
CN112770312A (zh) * 2021-01-04 2021-05-07 腾讯科技（深圳）有限公司 数据传输方法、装置、计算机可读介质及电子设备
CN112804710A (zh) * 2021-01-04 2021-05-14 腾讯科技（深圳）有限公司 数据传输方法、装置、计算机可读介质及电子设备
CN112804711A (zh) * 2021-01-04 2021-05-14 腾讯科技（深圳）有限公司 数据传输方法、装置、计算机可读介质及电子设备

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
HUAWEI, HISILICON: "Uplink bearer identification for eLWA", 3GPP DRAFT; R2-163765 UPLINK BEARER IDENTIFICATION FOR ELWA, vol. RAN WG2, 13 May 2016 (2016-05-13), Nanjing, China, pages 1 - 4, XP051095694 *

Also Published As

Publication number Publication date
US20230070702A1 (en) 2023-03-09
CN112804710A (zh) 2021-05-14
CN112804710B (zh) 2024-05-07

Similar Documents

Publication Publication Date Title
WO2022142516A1 (zh) 数据传输方法、装置、计算机可读介质及电子设备
WO2022142835A1 (zh) 一种数据传输方法、装置、计算机可读存储介质、电子设备及计算机程序产品
WO2022142517A1 (zh) 数据传输方法、装置、计算机可读介质及电子设备
CN113037440B (zh) 数据重传处理方法、装置、计算机设备和存储介质
WO2022142676A1 (zh) 数据传输方法、装置、计算机可读介质及电子设备
KR101298640B1 (ko) 전송 스트림 패킷을 전송하는 방법 및 장치
US11792130B2 (en) Audio/video communication method, terminal, server, computer device, and storage medium
WO2022142885A1 (zh) 一种数据传输方法、装置、计算机可读存储介质、电子设备及计算机程序产品
MX2015004596A (es) Metodo y aparato para el control de envio de datos de medios.
CN112953850B (zh) 数据传输方法、装置、计算机可读介质及电子设备
WO2023213089A1 (zh) 数据处理方法、装置、计算机可读介质及终端设备
WO2023217188A1 (zh) 一种直播数据传输方法、装置、系统、设备和介质
Phung et al. Enhancing rest http with random linear network coding in dynamic edge computing environments
WO2023142592A1 (zh) 数据传输方法、装置、计算机可读介质及电子设备、计算机程序产品
WO2023213086A1 (zh) 数据处理方法、装置、计算机可读介质及电子设备
WO2024065471A1 (en) Wireless communication method and device
CN113542685B (zh) 一种基于可靠udp的实时超高清视频传输方法
WO2024001451A1 (zh) 业务数据包的处理方法、装置、介质及电子设备
WO2024056200A1 (en) Early termination of transmission of pdu sets generated by al-fec in a wireless communication network
CN116321094A (zh) 蓝牙传输方法及系统
CN117857396A (zh) 数据传输方法、装置、计算机可读介质及电子设备

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21913261

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21913261

Country of ref document: EP

Kind code of ref document: A1