CN115250506A - 一种通信方法及设备 - Google Patents

Abstract

一种通信方法及设备。确定在第一QoS流中传输失败的数据包的第一信息；丢弃传输失败的数据包中的部分或全部，并为尚未发送的数据包重新设置序号，使得尚未发送的数据包与发送成功的数据包的序号连续。如果在第一QoS流中有传输失败的数据包，则可将这些数据包中的部分或全部丢弃，相当于不对被丢弃的数据包进行重传，这样发送端的重传次数也不会达到最大重传次数，从而能够尽量维持发送端与接收端之间的传输层的连接不断开。且由于丢弃了一些数据包，则发送端可以对尚未发送的数据包重新设置序号，使得尚未发送的数据包与发送成功的数据包之间的序号连续，这样也能尽量维持发送端与接收端之间的传输层的连接不断开。

Description

一种通信方法及设备

相关申请的交叉引用

本申请要求在2021年04月09日提交中国国家知识产权局、申请号为202110382419.8、申请名称为“一种信息发送方法、终端及网络设备”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。

技术领域

本申请涉及通信技术领域，尤其涉及一种通信方法及设备。

背景技术

扩展现实(extended reality，XR)是指通过计算机技术和可穿戴设备产生的一个真实与虚拟组合、可人机交互的环境，是增强现实(augmented reality，AR)、虚拟现实(virtual reality，VR)、混合现实(mixed reality，MR)等多种形式的统称。XR通过视觉交互技术融合，可实现虚拟世界与现实世界之间无缝转换的“沉浸感”体验。

XR业务通常是通过“帧”的形式在网络设备和终端设备间传输的，每帧代表一幅静止的图像，一帧可通过多个网际协议(internet protocol，IP)包传输。在传输过程中，如果遇到网络故障等问题，则可能会接收端收不到IP包的情况。接收端如果收到了IP包，则可以向发送端发送肯定应答(ACK)，如果未收到来自接收端的ACK，发送端就会重传相应的IP包。在发送端的重传次数达到最大重传次数的情况下，如果发送端仍然未收到来自接收端的ACK，则会断开与接收端之间的传输层连接，例如传输控制协议(transmission controlprotocol，TCP)连接，此时收发双方的连接断开。如需恢复传输，则需要重新建立传输层连接，例如TCP连接，过程较为复杂。

发明内容

本申请实施例提供一种通信方法及设备，用于减小收发双方的传输层连接断开的概率，提高数据传输效率。

第一方面，提供第一种通信方法，该方法可由终端设备执行，或由包括终端设备的更大设备执行，或由芯片系统或其他功能模块执行，该芯片系统或功能模块能够实现终端设备的功能。或者，该方法也可由网络设备执行，或由芯片系统或其他功能模块执行，该芯片系统或功能模块能够实现网络设备的功能。示例性地，所述网络设备为核心网设备，例如UPF。或者，示例性地，所述网络设备为服务器，例如应用服务器，或连接在应用服务器与核心网之间的中间服务器。该方法包括：确定在第一QoS流中传输失败的数据包的第一信息；丢弃所述传输失败的数据包中的部分或全部，并为尚未发送的数据包重新设置序号，使得所述尚未发送的数据包与发送成功的数据包的序号连续。

在本申请实施例中，对于发送端来说，如果在第一QoS流中有传输失败的数据包，则可以将这些数据包中的部分或全部丢弃，相当于不对被丢弃的数据包进行重传，这样发送端的重传次数也不会达到最大重传次数，从而能够尽量维持发送端与接收端之间的传输层的连接不断开。在网络恢复时能够继续通过该传输层的连接传输数据包，无需重新建立传输层的连接，能够提高数据包的传输效率。另外对于接收端来说，如果接收的数据包的序号不连续，则接收端会一直等待接收未接收的数据包，如果等待达到一定的时长，则收发双方的传输层的连接也可能断开。因此本申请实施例中，由于丢弃了一些数据包，则发送端可以对尚未发送的数据包重新设置序号，使得尚未发送的数据包与发送成功的数据包之间的序号连续。对于接收端来说，由于接收的是序号连续的数据包，则接收端可以持续接收，而不会等待被丢弃的数据包，这样也能尽量维持发送端与接收端之间的传输层的连接不断开。

结合第一方面，在第一方面的第一种可选的实施方式中，所述方法还包括：丢弃所述传输失败的数据包对应的帧所对应的剩余数据包，所述剩余数据包为所述帧对应的全部数据包中除了所述传输失败的数据包外的数据包。以XR应用为例，XR业务有个特点，如果一帧对应的数据包中有一个数据包传输失败，对于接收端来说可能对于整个帧的解析都会失败，也就是说，这一帧里剩余的数据包即使传输，意义也不大，且浪费传输资源。因此本申请实施例中，如果传输失败的数据包对应某个帧，且该帧的部分数据包属于传输失败的数据包，而该帧剩余的数据包还未传输(例如，该帧对应的数据包中还没有传输成功的数据包且还有尚未传输的数据包)，那么可以丢弃该帧剩余的数据包，无需继续传输，从而减轻数据传输负担，且节省传输资源。

结合第一方面或第一方面的第一种可选的实施方式，在第一方面的第二种可选的实施方式中，第一应用的数据通过所述第一QoS流和第二QoS流传输，所述第一QoS流传输的数据包的重要程度低于所述第二QoS流传输的数据包的重要程度。在本申请实施例中，第二QoS流传输的数据包较为重要，因此可尽量保证第二QoS流的传输成功率。对于第一QoS流传输的数据包，由于重要程度较低，因此在网络出问题时，可丢弃第一QoS流中传输的相应数据包，以减轻网络的拥塞等问题。

结合第一方面或第一方面的第一种可选的实施方式或第一方面的第二种可选的实施方式，在第一方面的第三种可选的实施方式中，所述第一信息包括(或，指示)以下一种或多种信息：所述传输失败的数据包对应的帧的帧号，所述传输失败的数据包对应的帧的类型，所述传输失败的数据包在帧内的位置，所述传输失败的数据包的个数，或，M个数据包的TCP层的序号或IP层的序号；其中，所述M个数据包为所述传输失败的数据包，或为所述传输失败的数据包对应的帧所对应的全部数据包。第一信息可指示传输失败的数据包的信息，例如指示M个数据包的序号，和/或指示传输失败的数据包的个数等。第一信息也可指示传输失败的数据包对应的帧的信息，例如指示传输失败的数据包对应的帧的帧号、传输失败的数据包对应的帧的类型、传输失败的数据包在帧内的位置中的一项或多项。第一信息指示的内容较为灵活。

结合第一方面或第一方面的第一种可选的实施方式至第一方面的第三种可选的实施方式中的任一种可选的实施方式，在第一方面的第四种可选的实施方式中，确定在第一QoS流中传输失败的数据包的第一信息，包括：接收所述第一信息；或，根据所述第一QoS流的数据发送情况，确定所述第一信息；或，接收在所述第一QoS流中传输失败的数据包的第二信息，并根据所述第二信息确定所述第一信息。例如该方法由服务器执行，那么第一信息例如为UPF发送给服务器的。又例如，该方法由UE执行，则UE就是数据包的发送端，则UE根据第一QoS流的数据发送情况就能相应确定第一信息。第一QoS流的数据发送情况例如包括第一QoS流上的数据包丢弃情况等。再例如，该方法由UPF执行，则UPF可以从接入网设备接收第二信息，从而根据第二信息确定第一信息。

结合第一方面的第四种可选的实施方式，在第一方面的第五种可选的实施方式中，所述第二信息包括以下一种或多种信息：所述传输失败的数据包对应的帧的帧号，所述传输失败的数据包对应的帧的类型，所述传输失败的数据包在帧内的位置，所述传输失败的数据包的个数，或，M个数据包对应的GTP包头的序号；其中，所述M个数据包为所述传输失败的数据包，或为所述传输失败的数据包对应的帧所对应的全部数据包。第二信息也可指示传输失败的数据包对应的帧的信息，例如指示传输失败的数据包对应的帧的帧号、传输失败的数据包对应的帧的类型、传输失败的数据包在帧内的位置中的一项或多项。第二信息指示的内容较为灵活。

结合第一方面的第五种可选的实施方式，在第一方面的第六种可选的实施方式中，所述第二信息包括所述M个数据包对应的GTP包头的序号，则，根据所述第二信息确定所述第一信息，包括：将所述GTP包头的序号映射为所述TCP层的序号或所述IP层的序号，以得到所述第一信息，所述第一信息包括所述M个数据包的TCP层的序号或IP层的序号。例如，该方法由UPF执行，例如接入网设备可向UPF发送第二信息。而接入网设备所发送的第二信息指示的是M个数据包对应的GTP包头的序号，无法指示M个数据包对应的TCP层的序号或IP层的序号。那么UPF可将GTP包头的序号映射为TCP层的序号或IP层的序号。

结合第一方面或第一方面的第一种可选的实施方式至第一方面的第六种可选的实施方式中的任一种可选的实施方式，在第一方面的第七种可选的实施方式中，所述方法还包括：通过第二QoS流重传N个数据包，所述N个数据包属于所述传输失败的数据包，且所述N个数据包是第一应用的一帧图像对应的部分数据包。例如，在传输失败的数据包中包括N个数据包，N个数据包是第一应用的一帧图像对应的部分数据包，而该帧图像对应的剩余数据包已传输成功。那么，为了尽量保证该帧图像的输出质量，服务器可将N个数据包重传给UE。为了提高N个数据包的重传成功率，服务器可通过第二QoS流来重传这N个数据包，或者说，服务器通过第二TCP连接重传这N个数据包。UPF接收这N个数据包后，再通过第二QoS流向UE重传这N个数据包，N为正整数。传输失败的数据包所包括的除了这N个数据包外的其他数据包，服务器可以全部丢弃。通过这种方式，既可以缓解网络的拥塞等情况，又能尽可能保证更多帧的输出质量。

结合第一方面或第一方面的第一种可选的实施方式至第一方面的第七种可选的实施方式中的任一种可选的实施方式，在第一方面的第八种可选的实施方式中，所述方法还包括：在确定网络恢复正常时，发送所述尚未发送的数据包；或，在第一定时器超时时，发送所述尚未发送的数据包。如果确定网络恢复正常，则可以恢复传输，继续发送尚未发送的数据包。或者，如果所维护的第一定时器超时，则也可恢复传输，继续发送尚未发送的数据包。尚未发送的数据包已进行了重新编号，因此尚未发送的数据包与接收端接收成功的数据包的序号(TCP层的序号或IP层的序号)之间是连续的，则接收端不会等待传输失败的数据包，由此减小了发送端与接收端之间的连接断开的概率。

第二方面，提供第二种通信方法，该方法可由网络设备执行，或由芯片系统或其他功能模块执行，该芯片系统或功能模块能够实现网络设备的功能。示例性地，所述网络设备为核心网设备，例如UPF。该方法包括：向接入网设备发送第一请求，所述第一请求用于请求订阅第一QoS流的传输信息，所述第一QoS流的传输信息用于指示所述第一QoS流传输失败，或指示所述第一QoS流中传输失败的数据包。

结合第二方面，在第二方面的第一种可选的实施方式中，第一应用的数据通过所述第一QoS流和第二QoS流传输，所述第一QoS流的服务质量低于所述第二QoS流。

结合第二方面或第二方面的第一种可选的实施方式，在第二方面的第二种可选的实施方式中，所述方法还包括：从所述接入网设备接收所述第一QoS流中传输失败的数据包的第二信息；根据所述第二信息确定所述第一QoS流中传输失败的数据包的第一信息；向应用服务器发送所述第一信息，所述应用服务器与所述第一应用对应。

结合第二方面的第二种可选的实施方式，在第二方面的第三种可选的实施方式中，所述第二信息包括以下一种或多种信息：所述传输失败的数据包对应的帧的帧号，所述传输失败的数据包对应的帧的类型，所述传输失败的数据包在帧内的位置，所述传输失败的数据包的个数，或，M个数据包对应的GTP包头的序号；其中，所述M个数据包为所述传输失败的数据包，或为所述传输失败的数据包对应的帧所对应的全部数据包。

结合第二方面的第三种可选的实施方式，在第二方面的第四种可选的实施方式中，所述第二信息包括所述M个数据包对应的GTP包头的序号，则，根据所述第二信息确定所述第一信息，包括：将所述GTP包头的序号映射为所述TCP层的序号或所述IP层的序号，以得到所述第一信息，所述第一信息包括所述M个数据包的TCP层的序号或IP层的序号。

结合第二方面的第二种可选的实施方式或第二方面的第三种可选的实施方式或第二方面的第四种可选的实施方式，在第二方面的第五种可选的实施方式中，所述第一信息包括以下一种或多种信息：所述传输失败的数据包对应的帧的帧号，所述传输失败的数据包对应的帧的类型，所述传输失败的数据包在帧内的位置，所述传输失败的数据包的个数，或，M个数据包的TCP层的序号或IP层的序号；其中，所述M个数据包为所述传输失败的数据包，或为所述传输失败的数据包对应的帧所对应的全部数据包。

关于第二方面或第二方面的各种可选的实施方式所带来的技术效果，可参考对于第一方面或相应的实施方式的技术效果的介绍。

第三方面，提供第三种通信方法，该方法可由终端设备执行，或由包括终端设备的更大设备执行，或由芯片系统或其他功能模块执行，该芯片系统或功能模块能够实现终端设备的功能。或者，该方法也可由网络设备执行，或由芯片系统或其他功能模块执行，该芯片系统或功能模块能够实现网络设备的功能。示例性地，所述网络设备为核心网设备，例如UPF。或者，示例性地，所述网络设备为服务器，例如应用服务器，或连接在应用服务器与核心网之间的中间服务器。该方法包括：从第一通信装置接收第五信息，所述第五信息用于指示所述第一通信装置在第一QoS流中发送失败的数据包；根据所述第五信息生成第二数据包，所述第二数据包的序号与所述发送失败的数据包的序号相同。

在本申请实施例中，对于发送端来说，如果在第一QoS流中有传输失败的数据包，则可以将这些数据包中的部分或全部丢弃，相当于不对被丢弃的数据包进行重传，这样发送端的重传次数也不会达到最大重传次数，从而能够尽量维持发送端与接收端之间的传输层的连接不断开。在网络恢复时发送端能够继续通过该传输层的连接传输数据包，无需重新建立传输层的连接，能够提高数据包的传输效率。另外对于接收端来说，如果接收的数据包的序号不连续，则接收端会一直等待接收未接收的数据包，如果等待达到一定的时长，则收发双方的传输层的连接也可能断开。因此本申请实施例中，发送端可向接收端指示发送失败的数据包的序号等信息，接收端可据此自行生成序号与发送失败的数据包的序号相同的数据包，从而接收端会认为所接收的数据包的序号是连续的，这样也能尽量维持发送端与接收端之间的传输层的连接不断开。

结合第三方面，在第三方面的第一种可选的实施方式中，第一应用的数据通过所述第一QoS流和第二QoS流传输，所述第一QoS流的服务质量低于所述第二QoS流。在本申请实施例中，第二QoS流传输的数据包较为重要，因此可尽量保证第二QoS流的传输成功率。对于第一QoS流传输的数据包，由于重要程度较低，因此在网络出问题时，可丢弃第一QoS流中传输的相应数据包，以减轻网络的拥塞等问题。

结合第三方面或第三方面的第一种可选的实施方式，在第三方面的第二种可选的实施方式中，接收第五信息，包括：通过第二QoS流从所述第一通信装置接收所述第五信息。由于此时第一QoS流可能无法正常传输，因此可选的，可通过第二QoS流发送第五信息，以提高第五信息的发送成功率。

第四方面，提供一种通信装置。所述通信装置可以为上述第一至第三方面中的任意一方面所述的终端设备。所述通信装置具备上述终端设备的功能。所述通信装置例如为终端设备，或为终端设备中的功能模块，例如基带装置或芯片系统等。或者，所述通信装置具备上述网络设备的功能。所述通信装置例如为网络设备，或为网络设备中的功能模块，例如基带装置或芯片系统等。示例性地，所述网络设备为核心网设备，例如UPF。或者，示例性地，所述网络设备为服务器，例如应用服务器，或连接在应用服务器与核心网之间的中间服务器。一种可选的实现方式中，所述通信装置包括基带装置和射频装置。另一种可选的实现方式中，所述通信装置包括处理单元(有时也称为处理模块)和收发单元(有时也称为收发模块)。收发单元能够实现发送功能和接收功能，在收发单元实现发送功能时，可称为发送单元(有时也称为发送模块)，在收发单元实现接收功能时，可称为接收单元(有时也称为接收模块)。发送单元和接收单元可以是同一个功能模块，该功能模块称为收发单元，该功能模块能实现发送功能和接收功能；或者，发送单元和接收单元可以是不同的功能模块，收发单元是对这些功能模块的统称。

例如，所述处理单元，用于确定在第一QoS流中传输失败的数据包的第一信息；所述处理单元，还用于丢弃所述传输失败的数据包中的部分或全部，并为尚未发送的数据包重新设置序号，使得所述尚未发送的数据包与发送成功的数据包的序号连续。

又例如，所述收发单元(或，所述发送单元)，用于向接入网设备发送第一请求，所述第一请求用于请求订阅第一QoS流的传输信息，所述第一QoS流的传输信息用于指示所述第一QoS流传输失败，或指示所述第一QoS流中传输失败的数据包。

再例如，所述收发单元(或，所述接收单元)，用于从第一通信装置接收第五信息，所述第五信息用于指示所述第一通信装置在第一QoS流中发送失败的数据包；所述处理单元，用于根据所述第五信息生成第二数据包，所述第二数据包的序号与所述发送失败的数据包的序号相同。

在一种可选的实现方式中，所述通信装置还包括存储单元，所述处理单元用于与所述存储单元耦合，并执行所述存储单元中的程序或指令，使能所述通信装置执行上述第一至第三方面中的任意一方面所述的终端设备或网络设备的功能。

第五方面，提供一种计算机可读存储介质，所述计算机可读存储介质用于存储计算机程序或指令，当其被运行时，使得上述各方面中终端设备或网络设备所执行的方法被实现。

第六方面，提供一种包含指令的计算机程序产品，当其在计算机上运行时，使得上述各方面所述的方法被实现。

附图说明

图1为P帧与I帧之间的关系示意图；

图2为本申请实施例的一种应用场景示意图；

图3为本申请实施例提供的第一种通信方法的流程图；

图4为本申请实施例中服务器将第一应用的业务分为两个数据流传输的示意图；

图5为本申请实施例中服务器为尚未发送的数据包设置序号的示意图；

图6为本申请实施例提供的第二种通信方法的流程图；

图7为本申请实施例提供的第三种通信方法的流程图；

图8为本申请实施例提供的第四种通信方法的流程图；

图9为本申请实施例提供的第五种通信方法的流程图；

图10为本申请实施例提供的第六种通信方法的流程图；

图11为本申请实施例中建立MPTCP连接的流程图；

图12为本申请实施例提供的终端设备的一种示意性框图；

图13为本申请实施例提供的通信装置的一种示意性框图。

具体实施方式

为了使本申请实施例的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施例作进一步地详细描述。

以下，对本申请实施例中的部分用语或概念进行解释说明，以便于本领域技术人员理解。

本申请实施例中，终端设备是一种具有无线收发功能的设备，可以是固定设备，移动设备、手持设备(例如手机)、穿戴设备、车载设备，或内置于上述设备中的无线装置(例如，通信模块，调制解调器，或芯片系统等)。所述终端设备用于连接人，物，机器等，可广泛用于各种场景，例如包括但不限于以下场景：蜂窝通信、设备到设备通信(device-to-device，D2D)、车到一切(vehicle to everything，V2X)、机器到机器/机器类通信(machine-to-machine/machine-type communications，M2M/MTC)、物联网(internet ofthings，IoT)、虚拟现实(virtual reality，VR)、增强现实(augmented reality，AR)、工业控制(industrial control)、无人驾驶(self driving)、远程医疗(remote medical)、智能电网(smart grid)、智能家具、智能办公、智能穿戴、智能交通，智慧城市(smart city)、无人机、机器人等场景的终端设备。所述终端设备有时可称为用户设备(user equipment，UE)、终端、接入站、UE站、远方站、无线通信设备、或用户装置等等。为描述方便，本申请实施例中将终端设备以UE为例进行说明。

本申请实施例中的网络设备，例如包括接入网设备，和/或核心网设备。所述接入网设备为具有无线收发功能的设备，用于与所述终端设备进行通信。所述接入网设备包括但不限于上述通信系统中的基站(BTS，Node B,eNodeB/eNB，或gNodeB/gNB)、收发点(transmission reception point，TRP)，第三代合作伙伴计划(3rd generationpartnership project，3GPP)后续演进的基站，无线保真(wireless fidelity，Wi-Fi)系统中的接入节点，无线中继节点，无线回传节点等。所述基站可以是：宏基站，微基站，微微基站，小站，中继站等。多个基站可以支持上述提及的同一种接入技术的网络，也可以支持上述提及的不同接入技术的网络。基站可以包含一个或多个共站或非共站的传输接收点。网络设备还可以是云无线接入网络(cloud radio access network，CRAN)场景下的无线控制器、集中单元(centralized unit，CU)，和/或分布单元(distributed unit，DU)。网络设备还可以是服务器，可穿戴设备，或车载设备等。例如，车到一切(vehicle to everything，V2X)技术中的网络设备可以为路侧单元(road side unit，RSU)。以下对接入网设备以为基站为例进行说明。基站可以与终端设备进行通信，也可以通过中继站与终端设备进行通信。终端设备可以与不同接入技术中的多个基站进行通信。所述核心网设备用于实现移动管理，数据处理，会话管理，策略和计费等功能。不同接入技术的系统中实现核心网功能的设备名称可以不同，本申请实施例并不对此进行限定。以5G系统为例，所述核心网设备包括：访问和移动管理功能(access and mobility management function，AMF)、会话管理功能(session management function，SMF)、策略控制功能(policy control function，PCF)或用户面功能(user plane function，UPF)等。以4G系统为例，所述核心网设备包括：移动管理实体(mobility management entity，MME)、服务网关(serving gateway，SGW)、策略与计费规则功能(policy and charging rules function，PCRF)或公共数据网网关(publicdata network gateway，PGW)等。

本申请实施例中，用于实现网络设备功能的通信装置可以是网络设备，也可以是能够支持网络设备实现该功能的装置，例如芯片系统，该装置可以被安装在网络设备中。在本申请实施例提供的技术方案中，以用于实现网络设备的功能的装置是网络设备为例，描述本申请实施例提供的技术方案。

XR是指通过计算机技术和可穿戴设备产生的一个真实与虚拟组合、可人机交互的环境，是AR、VR、MR等多种形式的统称。XR通过视觉交互技术融合，可实现虚拟世界与现实世界之间无缝转换的“沉浸感”体验。XR业务通常是通过“帧”的形式在网络和终端设备间进行发送的，每帧代表一幅静止的图像。而在实际压缩时，会采取各种算法减少数据的容量。例如，I帧表示关键帧，可以理解为这一帧画面的完整保留，解码时只需要本帧数据就可以完成(因为包含完整画面)；P帧表示的是这一帧跟之前的一个关键帧(例如I帧)的差别，解码时需要用之前缓存的画面叠加上本帧定义的差别，生成最终画面。实际传输过程中，每个帧的大小和画面的大小和质量(例如，1080P，720P等)有关，通常每个帧需要通过多个互联网协议(Internet protocol，IP)包进行传输，例如，I帧需要通过100个IP包传输，P帧通过40个IP包传输。

相对而言，I帧的重要性比P帧的重要性高，因为当部分P帧传输失败时，通常仅影响该P帧的显示，用户的体验是短暂的卡顿；但是，如果I帧传输失败，会使后续的P帧都无法解析，用户的体验是较长时间的卡顿。以图1为例，P0是对I帧有较大修改的P帧，P1是在I帧或P0帧的基础上进行较小修改的帧，P2是对前一帧(I帧，P0帧或P1帧)有较小修改的P帧。若P1帧或P2帧丢失，则仅影响本帧的显示，影响较小，而如果I帧或P0帧丢失，则会影响后面几帧的显示，影响较大。

本申请实施例中，对于名词的数目，除非特别说明，表示“单数名词或复数名词”，即"一个或多个”。“至少一个”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B的情况，其中A,B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。例如，A/B，表示：A或B。“以下至少一项(个)”或其类似表达，是指的这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a,b,或c中的至少一项(个)，表示：a,b,c,a和b,a和c,b和c,或a和b和c，其中a,b,c可以是单个，也可以是多个。

本申请实施例提及“第一”、“第二”等序数词是用于对多个对象进行区分，不用于限定多个对象的大小、内容、顺序、时序、优先级或者重要程度等。例如，第一信息和第二信息，可以是同一个信息，也可以是不同的信息，且，这种名称也并不是表示这两个信息的内容、优先级或者重要程度等的不同。另外，本申请所介绍的各个实施例中对于步骤的编号，只是为了区分不同的步骤，并不用于限定步骤之间的先后顺序。例如，步骤S301可以发生在步骤S302之前，或者可能发生在S302之后，或者也可能与S302同时发生。

可参考图2，为本申请实施例的一种应用场景示意图。在图2中，UE能够通过接入网设备以及核心网设备与服务器通信，该服务器例如为应用服务器，或者，该服务器例如为中间服务器。应用服务器与应用对应。应用服务器与应用对应，例如理解为，应用服务器可提供该应用的数据。例如XR应用对应的应用服务器就能提供XR应用的数据。在图2中，核心网设备可直接连接应用服务器。或者，在核心网设备与应用服务器之间还可连接有其他的中间服务器，中间服务器也可以作为所述服务器。中间服务器例如包括内容分发网络(content delivery network，CDN)服务器或多媒体资源处理器(multimedia resourcefunction processor，MRFP)等。

图2中的接入网设备在不同的系统对应不同的设备，例如在4G系统中可以对应eNB，在5G系统中对应5G中的接入网设备，例如gNB。图2中的核心网设备在不同的系统也对应不同的设备，例如在4G系统中可以对应PGW，在5G系统中可以对应UPF。当然本申请实施例所提供的技术方案也可以应用于未来的移动通信系统中，因此图2中的接入网设备也可以对应未来的移动通信系统中的接入网设备，以及核心网设备也可以对应未来通信系统中的核心网设备。本申请实施例以接入网设备是基站为例，实际上参考前文的介绍，接入网设备还可以是RSU等设备。

下面结合附图介绍本申请实施例所提供的方法。在本申请的各个实施例对应的附图中，凡是可选的步骤均用虚线表示。本申请的各个实施例所述的技术方案均能够应用于图2所示的网络架构。例如，本申请的各个实施例所述的UE例如为图2所示的网络架构中的UE；本申请的各个实施例所述的服务器例如为图2所示的网络架构中的应用服务器，或者例如为连接在核心网设备与应用服务器之间的中间服务器；本申请的各个实施例所述的UPF例如为图2所示的网络架构中的核心网设备。本申请的各个实施例中所述的“连接”可理解为传输层的连接，例如为TCP连接，用户数据报协议(user datagram protocol，UDP)连接，快速UDP网络连接(quick UDP internet connections，QUIC)，或者安全可靠传输(securereliable transport，SRT)等。在本申请的各个实施例的介绍过程中是以TCP连接为例。另外在本申请的各个实施例的介绍过程中，以本申请实施例的方法应用于5G系统为例。

本申请实施例提供一种通信方法，请参见图3，为该方法的流程图。

S301、服务器向UPF发送下行数据包，相应的，UPF从服务器接收下行数据包。该下行数据包的数量可以是一个或多个，该下行数据包例如为IP包。该下行数据包属于第一应用，第一应用例如为XR应用，或者也可以是其他视频类应用、云游戏(cload gaming，CG)类应用或图像类应用等。

以XR应用为例。XR业务具有数据突发的特点，例如，当XR业务为60帧/s时，每16.67ms会有一帧数据到达接入网设备，即每16.67ms会有一组IP包到达接入网设备，以请求接入网设备将这些IP包发送给UE。若接入网设备无法发送这些IP包，例如网络拥塞等，则接入网设备会对接收的这一组IP数据包中的一个或多个进行随机丢包处理，以缓解拥塞情况。如果随机丢弃的IP包属于高优先级帧，例如属于I帧或P0帧，则丢包会对用户产生较大影响；而如果丢弃的数据包属于低优先级帧，例如属于P1帧或P2帧，则丢包对用户的影响较小。但接入网设备是随机丢弃，所以无法控制丢包对用户的影响。为了解决接入网设备随机丢包对用户观看XR业务的影响，可以实行分层传输。

例如参考图4，服务器将第一应用的业务分为2个数据流(例如分为2个socket流)，其中一个数据流传输相对重要的帧的数据包，例如I帧和/或P0帧的数据包，这个数据流可称为基本层数据流；另一个数据流传输相对不重要的帧的数据包，例如P1帧和/或P2帧的数据包，这个数据流可称为增强层数据流。本申请的各个实施例中，数据流也可以称为业务流(traffic flow)。这两个数据流到达接收端后，接收端再将I帧的数据包以及对应的P帧的数据包进行处理后解码显示。在这种分流传输的情况下，如果接入网设备无法保证数据传输时，例如网络拥塞，则接入网设备可优先保证高优先级的数据包发送，丢弃低优先级的数据包，保证用户的业务体验。

本申请实施例可以应用这种分流传输的方法，服务器可将第一应用的业务分两个数据流来传输，这两个数据流通过两个TCP连接传输。也就是说，服务器与UE之间可建立两个TCP连接，例如这两个TCP连接分别称为第一TCP连接和第二TCP连接，其中第一TCP连接传输第一数据流，第二TCP连接传输第二数据流，第一数据流和第二数据流是第一应用的数据流，第二数据流的重要程度高于第一数据流。第一TCP连接通过第一QoS流传输，第二TCP连接通过第二QoS流传输，因此也可以理解为，第二QoS流的服务质量高于第一QoS流的服务质量。以第一应用是XR应用为例，例如第二数据流传输相对重要的帧的数据包，例如I帧和/或P0帧的数据包，第一数据流传输相对不重要的帧的数据包，例如P1帧和/或P2帧的数据包。

例如该下行数据包的数量为一个或多个，这一个或多个下行数据包通过第一TCP连接传输，或者，该下行数据包的数量为多个，这多个下行数据包中的部分通过第一TCP连接传输，这多个下行数据包中剩余的部分通过第二TCP连接传输。

可选的，服务器可以向UPF提供每个数据包对应的帧的信息，例如服务器向UPF提供的信息包括以下一种或多种：帧的类型，帧号，帧内包括的数据包的总数，数据包在帧内的位置(例如，该数据包是帧内第几个数据包)。帧的类型例如包括I帧或P帧，或者包括I帧、P0帧、P1帧、或P2帧等。帧号，也可以理解为帧的编号，例如100号帧，表明该帧的帧号为100。帧内包括的数据包的总数是指一个帧所包括的数据包的总数，例如100个TCP包或100个IP包等。数据包在帧内的位置，例如包括某个数据包是帧内的第5个TCP包，或者是帧内的第5个IP包等。

S302、UPF向接入网设备发送第一请求，相应的，接入网设备接收第一请求。

UPF接收该下行数据包后，确定第一TCP连接通过第一服务质量(quality ofservice，QoS)流传输，UPF可向接入网设备发送第一请求，第一请求可请求获得第一QoS流的传输信息，例如第一请求用于请求订阅第一QoS流的传输信息，那么第一请求也可以称为订阅请求。在本申请的各个实施例中，以第一请求用于请求订阅第一QoS流的传输信息为例。第一QoS流的传输信息例如指示第一QoS流中的数据包传输失败，或者指示第一QoS流中传输失败的数据包(例如，指示第一QoS流中传输失败的数据包的序号)。其中，第二TCP连接通过第二QoS流传输，由于第二数据流的重要程度较高，则认为本申请实施例需要保证第二数据流的成功率，因此UPF无需向接入网设备订阅第二QoS流的传输信息。而第一数据流的重要程度较低，如果出现网络问题，则接入网设备可能丢弃第一QoS流承载的数据包，因此UPF可以订阅第一QoS流的传输信息。或者，UPF也可以向接入网设备订阅第二QoS流的传输信息，例如可通过一条第一请求订阅第一QoS流的传输信息和第二QoS流的传输信息，或者通过两条第一请求分别订阅第一QoS流的传输信息和第二QoS流的传输信息。本申请实施例主要关注对于第一QoS流的传输信息的订阅。

例如，UPF接收该下行数据包后，根据该下行数据包携带的IP五元组等信息，确定该下行数据包对应的QoS流(QoS flow)，从而将该下行数据包映射到该QoS流传输，该QoS流例如为第一QoS流或第二QoS流。下行数据包携带的IP五元组例如包括该下行数据包的源IP地址、目标IP地址、源端口号、目标端口号以及协议号。该下行数据包的源IP地址是该下行数据包的发送端的IP地址，例如本申请实施例中为服务器的IP地址，该下行数据包的源端口号也是该下行数据包的发送端的端口号，例如为服务器的端口号。该下行数据包的目标IP地址是该下行数据包的接收端的IP地址，例如本申请实施例中为UE的IP地址，该下行数据包的目标端口号也是该下行数据包的接收端的端口号，例如为UE的端口号。另外，例如该下行数据包对应第一QoS流，则UPF还可以订阅第一QoS流的传输信息，例如该订阅请求包括第一QoS流的QoS流标识(QoS flow identifier，QFI)。或者，即使UPF未接收下行数据包，UPF确定第一QoS流已建立的情况下，也可以订阅第一QoS流的传输信息。因此，S301是可选的步骤。

例如，UPF将该第一请求发送给SMF，SMF再将该第一请求发送给接入网设备，从而接入网设备就接收了该第一请求。可选的，接入网设备接收第一请求后，可以向SMF发送响应消息，例如称为响应消息1，响应消息1可指示订阅成功或失败。SMF从接入网设备接收响应消息1后，再向UPF发送响应消息2，如果响应消息1指示订阅成功，则响应消息2指示订阅成功，如果响应消息1指示订阅失败，则响应消息2指示订阅失败。UPF接收来自SMF的响应消息2后，就可确定订阅成功或订阅失败。为了简化附图，在图2中未画出响应消息1和响应消息2。

或者，UPF也可以直接向接入网设备发送该第一请求，例如UPF为第一请求添加通用分组无线业务隧道传输协议(general packet radio service tunnel protocol，GTP)包头，从而通过用户面向接入网设备发送该第一请求，则接入网设备可以从UPF接收该第一请求。可选的，接入网设备接收第一请求后，可以向UPF发送响应消息，UPF接收来自接入网设备的响应消息后，就可确定订阅成功或订阅失败。为了简化附图，在图2中未画出该响应消息。

S303、UPF通过第一QoS流传输第一数据流的数据包。或者说，UPF通过第一QoS流传输第一TCP连接的数据包。本申请各个实施例所述的数据包例如为IP包或TCP包。

可选的，UPF可确定每个数据包对应的帧的信息。该帧信息可以是服务器提供给UPF的，也可以是UPF自己生成的，例如，当XR业务为60帧/s时，每16.67ms会有一帧数据到达UPF，即每16.67ms会有一组IP包到达UPF，则UPF可根据数据包的大小和到达规律生成帧的信息。

S304、UPF通过第二QoS流传输第二数据流的数据包。或者说，UPF通过第二QoS流传输第二TCP连接的数据包。

可选的，UPF可确定每个数据包对应的帧的信息。该帧信息可以是服务器提供给UPF的，也可以是UPF自己生成的。

以第一应用是XR应用为例，第二数据流传输相对重要的帧的数据包，例如I帧和/或P0帧的数据包，第一数据流传输相对不重要的帧的数据包，例如P1帧和/或P2帧的数据包。

S305、接入网设备发送传输失败的数据包的第二信息，相应的，UPF接收传输失败的数据包的第二信息。

例如，接入网设备检测到第一QoS流出现了丢包，或者说出现了传输失败的情况，则可以发送第二信息。接入网设备可向SMF发送第二信息，SMF再将第二信息发送给UPF，或者，接入网设备直接将第二信息发送给UPF。

第二信息例如包括以下一种或多种信息(或者，第二信息指示的信息包括如下一种或多种信息)：传输失败的数据包对应的帧的帧号，传输失败的数据包对应的帧的类型，传输失败的数据包在帧内的位置(例如该数据包是帧内第几个数据包)，传输失败的数据包的个数，M个数据包的序号(M个数据包可包括传输失败的数据包，或包括传输失败的数据包对应的帧所对应的全部数据包，M为正整数)。第二信息所包括(或，指示)的数据包的序号，例如为数据包对应的GTP序号(或者说，传输失败的数据包对应的GTP包头的序号)。

可选的，第二信息包括(或，指示)传输失败的数据包的序号，而不包括(或，指示)如上其他信息。接入网设备所发送的第二信息，可包括GTP包头。在QoS流上传输的数据包的序号(例如TCP层的序号或IP层的序号)与GTP包头的序号之间可以有对应关系。那么，接入网设备确定传输失败的数据包后，就可确定传输失败的数据包的序号所对应的GTP包头的序号，该序号的GTP包头就可包括在第二信息中。

可选的，第二信息包括(或，指示)传输失败的数据包对应的帧的帧号、传输失败的数据包对应的帧的类型、或传输失败的数据包在帧内的位置中的一种或多种。以第一应用是XR应用为例，XR业务有个特点，如果一帧对应的数据包中有一个数据包传输失败，对于接收端来说可能对于整个帧的解析都会失败，也就是说，如果一帧对应的数据包中有一个数据包传输失败，则这一帧里剩余的数据包即使传输，意义也不大，且浪费传输资源。例如一帧对应50个数据包，这50个数据包中只要有一个数据包传输失败，就会导致接收端对于这一帧的解析失败。因此本申请实施例中，如果接入网设备确定传输失败的数据包对应某个帧，且该帧的部分数据包属于传输失败的数据包，而该帧剩余的数据包还未传输(例如，该帧对应的数据包中还没有传输成功的数据包且还有尚未传输的数据包)，那么接入网设备如果已接收了该帧剩余的数据包，则可以丢弃该帧剩余的数据包，无需继续传输，从而减轻接入网设备的数据传输负担，且节省传输资源。另外，接入网设备还可以通过第二信息向UPF指示传输失败的数据包的信息，例如第二信息包括(或，指示)传输失败的数据包对应的帧的帧号、传输失败的数据包对应的帧的类型、或传输失败的数据包在帧内的位置中的一种或多种，接入网设备可将传输失败的数据包的信息携带在第二信息包括的GTP包头内，从而UPF或服务器可进行相应处理。

例如，如果接入网设备确定传输失败的数据包对应某个帧，且该帧的部分数据包属于传输失败的数据包，而该帧剩余的数据包还未传输(或者说，该帧对应的数据包中还没有传输成功的数据包且还有尚未传输的数据包)，则第二信息可包括(或，指示)传输失败的数据包对应的帧的帧号、传输失败的数据包对应的帧的类型、或传输失败的数据包在帧内的位置中的一种或多种，或者，第二信息包括(或，指示)传输失败的数据包的GTP序号，或者，第二信息包括(或，指示)传输失败的数据包对应的帧所对应的全部数据包的GTP序号。或者，如果接入网设备确定传输失败的数据包对应某个帧，且该帧的部分数据包属于传输失败的数据包，但是该帧剩余的数据包中已有数据包传输成功，则第二信息可包括(或，指示)传输失败的数据包的GTP序号。

可选的，接入网设备除了发送第二信息外，还可以发送第三信息，第三信息可指示第一定时器的定时时长。第一定时器也可称为停止发送定时器，或者也可以有其他的名称。第一定时器例如由UPF或服务器维护，在第一定时器超时前，UPF或服务器不能发送第一应用对应的数据包，在第一定时器超时时，UPF或服务器才能继续发送第一应用对应的数据包，通过这种方式能够缓解网络的拥塞。第一定时器的定时时长可由接入网设备确定，由于接入网设备对于网络的情况较为明确，例如接入网设备可根据网络情况确定何时能够恢复正常通信，因此接入网设备所确定的第一定时器的定时时长可以较为准确。接入网设备可通过SMF将第三信息发送给UPF，或者，也可以直接将第三信息发送给UPF。

可选的，接入网设备除了发送第二信息外，还可以发送第四信息，第四信息例如指示传输失败的原因。传输失败的原因可以有多种，例如传输失败的原因包括如下一种或多种：网络拥塞，网络资源不足，网络暂时波动，完整性传输丢弃数据包，完整性传输丢弃剩余数据包，或，丢弃低优先级数据包。或者，传输失败的原因除了包括如上一种或多种外还可以包括其他原因。例如，如果传输失败的原因包括丢弃低优先级数据包，也可认为是默认指示了传输失败的原因是网络拥塞或网络资源不足等情况。接入网设备可通过SMF将第四信息发送给UPF，或者，也可以直接将第四信息发送给UPF。

S306、UPF向服务器发送传输失败的数据包的第一信息，相应的，服务器从UPF接收传输失败的数据包的第一信息。第一信息例如包括以下一种或多种信息(或者，第一信息例如指示如下一种或多种信息)：传输失败的数据包对应的帧的帧号，传输失败的数据包对应的帧的类型，传输失败的数据包在帧内的位置(例如该数据包是帧内第几个数据包)，传输失败的数据包的个数，M个数据包的序号(M个数据包可包括传输失败的数据包，或包括传输失败的数据包对应的帧所对应的全部数据包)。第一信息所指示的数据包的序号，例如为数据包对应的TCP层的序号或IP层的序号。

UPF可记录数据包的序号(例如TCP层的序号或IP层的序号)与GTP包头的序号之间的对应关系。UPF接收第二信息后，如果第二信息包括(或，指示)传输失败的数据包对应的GTP包头的序号，则UPF可将第二信息指示的GTP包头的序号映射为TCP层的序号或IP层的序号，从而可确定第一信息。例如，UPF所确定的第一信息可包括(或，指示)在第一QoS流中传输失败的数据包的序号(或者说，第一信息用于确定在第一QoS流中传输失败的数据包的序号)，例如第一信息包括(或，指示)的是这些数据包的TCP层的序号或IP层的序号。

又例如，如果第二信息包括(或，指示)的是传输失败的数据包对应的GTP包头的序号，UPF将第二信息包括(或，指示)的GTP包头的序号映射为TCP层的序号或IP层的序号后，可确定这些TCP层的序号或IP层的序号对应的数据包所属的帧，或者UPF可根据第二信息包括(或，指示)的GTP包头的序号确定这些GTP包头的序号对应的数据包所属的帧。那么，UPF所确定的第一信息可包括(或，指示)在第一QoS流中传输失败的数据包对应的帧(或者说，第一信息用于确定在第一QoS流中传输失败的数据包对应的帧)，例如第一信息包括(或，指示)在第一QoS流中传输失败的数据包对应的帧的帧号、传输失败的数据包对应的帧的类型、或传输失败的数据包在帧内的位置中的一种或多种。或者，UPF可确定传输失败的数据包对应的帧所对应的全部数据包的序号(例如TCP层的序号或IP层的序号)，则UPF所确定的第一信息可包括(或，指示)在第一QoS流中传输失败的数据包对应的帧所对应的全部数据包的序号。

或者，如果第二信息包括(或，指示)的是传输失败的数据包对应的帧所对应的全部数据包的GTP序号，则UPF接收第二信息后，可将第二信息包括(或，指示)的GTP包头的序号映射为TCP层的序号或IP层的序号，从而可确定第一信息，例如第一信息包括(或，指示)的是传输失败的数据包对应的帧所对应的全部数据包的TCP序号或IP序号。

或者，如果第二信息包括(或，指示)的是传输失败的数据包对应的帧所对应的全部数据包的GTP序号，则UPF接收第二信息后，可确定传输失败的数据包对应的帧的信息，例如确定传输失败的数据包对应的帧的帧号和/或传输失败的数据包对应的帧的类型等，并可将所确定的传输失败的数据包对应的帧的信息作为第一信息。

或者，如果第二信息包括(或，指示)的是在第一QoS流中传输失败的数据包对应的帧的信息，例如包括(或，指示)在第一QoS流中传输失败的数据包对应的帧的帧号和/或传输失败的数据包对应的帧的类型，则UPF接收第二信息后，可确定第二信息为第一信息，即，第一信息也包括(或，指示)在第一QoS流中传输失败的数据包对应的帧的信息。

或者，如果第二信息包括(或，指示)的是在第一QoS流中传输失败的数据包对应的帧的信息，例如包括(或，指示)在第一QoS流中传输失败的数据包对应的帧的帧号和/或传输失败的数据包对应的帧的类型，则UPF接收第二信息后，可确定第二信息所包括(或，指示)的帧对应的全部数据包的序号(例如TCP层的序号或IP层的序号)，从而确定第一信息，例如第一信息包括(或，指示)在第一QoS流中传输失败的数据包对应的帧所对应的全部数据包的序号。

在确定第一信息后，UPF可将第一信息发送给服务器。

可选的，如果UPF还接收了第三信息，则UPF可将第一定时器的定时时长发送给服务器，服务器可从UPF接收第一定时器的定时时长。或者，UPF也可能不向服务器发送第一定时器的定时时长，则服务器可自行确定第一定时器的定时时长，例如该定时时长可通过协议规定，或者使用缺省(default)值。或者，如果UPF未向服务器发送第一定时器的定时时长，则服务器也可以不启用第一定时器。

可选的，如果UPF还接收了第四信息，则UPF可将传输失败的原因发送给服务器，服务器可从UPF获知传输失败的原因。可选的，服务器可根据传输失败的原因确定第一定时器的定时时长。

S307、服务器丢弃所述传输失败的数据包中的部分或全部。

例如，服务器未从UPF接收传输失败的原因，则服务器可直接执行S307。或者，如果服务器从UPF接收了传输失败的原因，则服务器可根据传输失败的原因确定是否丢弃传输失败的数据包。作为一种示例，如果传输失败的原因为网络暂时波动，这种网络问题可能是暂时的，网络可能在较短时间内就能得到恢复，因此服务器可以不丢弃传输失败的数据包，而是等待网络恢复后继续发送这些数据包，则服务器不必执行S307，也不必执行后文将要介绍的S308。作为另一种示例，如果传输失败的原因包括网络拥塞、网络资源不足、或、丢弃低优先级数据包中的一种或多种，这种网络问题可能所需的恢复时间较长，则为了缓解网络拥塞或资源不足等问题，服务器可以丢弃传输失败的数据包中的部分或全部，即，执行S307。

服务器可将传输失败的数据包全部丢弃，这样可以在较大程度上缓解网络的拥塞等情况。或者，服务器也可以选择丢弃传输失败的数据包中的部分数据包，而对剩余的数据包，服务器可以重传给UE。例如，在传输失败的数据包中包括N个数据包，N个数据包是第一应用的一帧图像对应的部分数据包，而该帧图像对应的剩余数据包已传输成功。那么，为了尽量保证该帧图像的输出质量，服务器可将N个数据包重传给UE。为了提高N个数据包的重传成功率，服务器可通过第二QoS流来重传这N个数据包，或者说，服务器重传这N个数据包。UPF接收这N个数据包后，再通过第二QoS流向UE重传这N个数据包，N为正整数。传输失败的数据包所包括的除了这N个数据包外的其他数据包，服务器可以全部丢弃。通过这种方式，既可以缓解网络的拥塞等情况，又能尽可能保证更多帧的输出质量。可选的，服务器通过第二TCP连接重传这N个数据包，或者，服务器通过第一TCP连接重传这N个数据包。另外，服务器还可以向UPF发送第一指示信息，UPF可根据第一指示信息将该N个数据包映射到第二QoS流进行传输。第一指示信息例如为重传指示或高优先级指示等用于UPF确定将数据包映射到第二QoS流的信息，对于第一指示信息的具体实现方式本申请实施例不做限定。

可选的，服务器还可丢弃传输失败的数据包对应的帧的数据包。例如传输失败的数据包对应第一帧，第一帧剩余的数据包均属于尚未传输的数据包，或者说第一帧还没有传输成功的数据包且还有尚未传输的数据包，那么服务器可丢弃第一帧剩余的数据包。例如第一信息指示在第一QoS流中传输失败的数据包的序号，服务器可只是丢弃传输失败的部分或全部数据包；或者，服务器除了丢弃传输失败的部分或全部数据包外，还确定传输失败的数据包对应的帧的信息，例如确定了第一帧，如果第一帧还没有传输成功的数据包且还有尚未传输的数据包，则服务器可丢弃第一帧剩余的数据包(另外，服务器还会丢弃传输失败的数据包中对应于第一帧的数据包)，那么尚未发送的数据包中就不再包括第一帧的数据包。又例如，第一信息指示在第一QoS流中传输失败的数据包对应的帧的信息，则服务器可丢弃这些帧对应的全部数据包。再例如，第一信息指示在第一QoS流中传输失败的数据包对应的帧所对应的全部数据包的序号，则服务器可丢弃第一信息所指示的数据包，这些数据包中可包括传输失败的全部或部分数据包，和/或包括在第一QoS流中传输失败的数据包对应的帧所对应的数据包。

S308、服务器为尚未发送的数据包重新设置序号，使得尚未发送的数据包与发送成功的数据包的序号连续。尚未发送的数据包例如为通过第一QoS流传输的数据包中尚未发送的数据包，通过第二QoS流传输的数据包可不考虑。这里为尚未发送的数据包所设置的序号，例如为TCP层的序号或IP层的序号。

在S307中服务器丢弃了相应的数据包，如果不为尚未发送的数据包重新设置序号，则服务器在将尚未发送的数据包发送给UE后，对于UE来说，所接收的这些数据包的序号与网络故障前所接收的数据包的序号就是不连续的，则UE会一直等待接收未接收的数据包。例如，第一QoS流中传输失败的数据包的序号为11～20，服务器丢弃这10个数据包。对于服务器来说，发送成功的数据包的最大的序号为10，尚未发送的数据包的最小的序号为21。如果服务器不为尚未发送的数据包重新设置序号，则UE接收数据包21后，就会一直等待数据包11～20。如果等待达到一定的时长，则服务器与UE之间的TCP连接就可能断开。因此服务器可以对尚未发送的数据包重新设置序号，使得尚未发送的数据包与发送成功的数据包之间的序号连续，对于接收端来说，由于接收的是序号连续的数据包，则接收端可以持续接收，而不会等待被丢弃的数据包，这样也能尽量维持服务器与UE之间的TCP连接不断开。延续前述示例，例如服务器将尚未发送的数据包21重新设置序号为11，其他尚未发送的数据包也按照顺序重新设置序号，使得尚未发送的数据包与已发送成功的数据包的序号之间是连续的。则UE接收的就是数据包11而不是数据包21，由于序号的连续，UE不会等待被丢弃的数据包，从而能够维持服务器与UE之间的TCP连接。

而要求序号连续，是接收端(例如UE)的TCP层的要求，TCP层接收数据包后，如果数据包的序号连续，则TCP层会将序号连续的数据包递交给应用层处理。应用层就能识别出数据包所包括的真正的数据，不会因为序号而将数据包关联到不对应的帧。例如，服务器将数据包21重新设置序号为11，数据包21对应帧B，真正的数据包11对应帧A。UE的应用层接收数据包11后就能确定数据包11对应的帧为帧B而不是帧A，从而不会出现输出混乱的情况。

其中，如果服务器只是丢弃了在第一QoS流中传输失败的部分或全部数据包，并未丢弃这些数据包对应的帧的所对应的剩余数据包，则尚未发送的数据包依然包括这些帧所对应的剩余数据包。例如第一QoS流中传输失败的数据包包括数据包1～5以及数据包12～13，其中数据包1～5对应帧A，数据包12～13对应帧B，而帧A还对应数据包6～10，帧B还对应数据包11、14～20。服务器丢弃了数据包1～5以及数据包12～13，并未丢弃数据包6～10、以及数据包11、14～20，那么数据包6～10、以及数据包11、14～20属于尚未发送的数据包，服务器需为这些数据包重新设置序号。或者，如果服务器不仅丢弃了在第一QoS流中传输失败的部分或全部数据包，还丢弃了这些数据包对应的帧的所对应的剩余数据包，则尚未发送的数据包不再包括这些帧所对应的剩余数据包。沿用上述示例，例如服务器丢弃了数据包1～20，那么数据包11、14～20不属于尚未发送的数据包，服务器也不必为这些数据包再设置序号。

S309、在确定网络恢复正常时，服务器发送尚未发送的数据包，相应的，UE接收这些数据包。或者，在第一定时器超时时，服务器发送尚未发送的数据包，相应的，UE接收这些数据包。该尚未发送的数据包，例如是第一QoS流上尚未发送的数据包。例如，服务器通过第一TCP连接将尚未发的数据包发送给UPF，UPF再将这些数据包映射到第一QoS流上发送给UE。可选的，第一定时器超时也可以理解为第一定时器过期(expired)，或者第一定时器倒计时结束。

例如服务器从UPF接收了第一定时器的定时时长，则服务器可以启动第一定时器，例如服务器在接收第一信息后可启动第一定时器，或者服务器在接收第一定时器的定时时长后可启动第一定时器。或者，协议规定了第一定时器的定时时长，或者该定时时长使用缺省值，则服务器例如在接收第一信息后启动第一定时器。如果服务器启动了第一定时器，那么在第一定时器超时前，服务器不能发送或停止发送第一应用对应的第一QoS流上的数据包，而第一应用对应的第二QoS流的数据包，服务器可以继续发送，或者也可以不发送。在第一定时器超时时，服务器可通过第一TCP连接发送尚未发送的数据包。

或者，服务器未从UPF接收第一定时器的定时时长、协议也未规定第一定时器的定时时长、以及该定时时长也没有缺省值，则服务器可以不启动第一定时器。在这种情况下，如果确定网络恢复，则接入网设备可向UPF发送第六信息(例如，接入网设备直接向UPF发送第六信息，或者，接入网设备通过SMF向UPF发送第六信息)，UPF接收该第六信息后，可将该第六信息发送给服务器，服务器接收该第六信息后，就能确定可通过第一TCP连接发送尚未发送的数据包。该第六信息可指示网络恢复正常，或者指示发送数据包，或者指示通过第一QoS流发送数据包等。可选的，第一信息用于服务器确定网络恢复正常。

或者，即使服务器启动了第一定时器，则接入网设备在确定网络恢复正常的情况下，如果发现第一QoS流尚未恢复传输，则接入网设备也可向UPF发送第六信息，UPF可将该第六信息发送给服务器。此时可能第一定时器尚未超时，但根据接入网设备的通知，服务器也能确定网络恢复正常，从而可通过第一TCP连接及时发送尚未发送的数据包。另外，服务器可停止第一定时器。

例如参考图5，为服务器发送尚未发送的数据包的一种示例。例如数据包1、2、3是发送成功的数据包，数据包4、5是传输失败的数据包，数据包6、7、8、9是尚未发送的数据包。数据包4、5由于传输失败而被丢弃，服务器重新为数据包6、7、8、9设置序号，重新设置序号后的数据包6、7、8、9变更为数据包4、5、6、7，则在网络恢复后，服务器发送数据包4、5、6、7。从而对于UE来说，接收的数据包的序号就是连续的。

其中，S301～S305、S309是可选的步骤。

如上的各个步骤介绍的是本申请实施例涉及的下行传输的情况，下面介绍本申请实施例涉及的上行传输的情况。

UE的应用层中提供第一应用的应用(APP)产生业务数据后，该APP或应用处理器(application processor，AP)将业务数据封装到数据包(例如IP包)中。UE的调制解调器(modem)向接入网设备请求无线资源，以通过接入网设备和UPF将这些数据包发送给服务器。其中，UE通过第一QoS流和第二QoS流传输第一应用的数据。可选的，提供第一应用的应用也可以理解为第一应用对应的应用(APP)。

例如UE的modem接收到来自应用层的需要通过第一QoS流传输的数据包，但网络出现了问题，例如网络拥塞或网络资源不足等，则modem无法完成这些数据包的发送。在这种情况下，modem可以根据第一QoS流的数据发送情况确定传输失败的数据包的第一信息，且modem可将第一信息发送给UE的应用层。第一QoS流的数据发送情况可指示网络情况，例如第一QoS流的数据包大量丢失，则网络可能有拥塞或网络资源不足等。可选的，modem还可以向应用层发送第三信息和/或第四信息。关于这些信息的内容，可参考前文的介绍。

UE的应用层(例如AP或UE中安装的提供第一应用的APP)可直接丢弃传输失败的数据包中的部分或全部，可选的，还可丢弃传输失败的数据包对应的帧所对应的剩余数据包，或者，UE的应用层也可根据传输失败的原因确定是否丢弃数据包，关于这部分内容可参考S307。如果UE的应用层丢弃了数据包，则UE的应用层可以为尚未发送的数据包重新设置序号，关于这些内容可参考S308。在网络恢复时，或者在第一定时器超时时，UE可以继续发送尚未发送的数据包，关于这些内容可参考S309。其中，UE的应用层确定网络恢复，一种确定方式为，如果确定网络恢复，则UE的modem可向UE的应用层发送第六信息，UE的应用层接收该第六信息后，就能确定网络恢复正常，则UE的应用层可通过第一QoS流发送尚未发送的数据包。该第六信息可指示网络恢复正常，或者指示发送数据包，或者指示通过第一QoS流发送数据包。或者，即使UE的应用层启动了第一定时器，则UE的modem也可以向UE的应用层发送第六信息，关于该内容也可参考S309。

在本申请实施例中，对于发送端来说，如果在第一QoS流中有传输失败的数据包，则可以将这些数据包中的部分或全部丢弃，相当于不对被丢弃的数据包进行重传，这样发送端的重传次数也不会达到最大重传次数，从而能够尽量维持发送端与接收端之间的传输层的连接不断开。在网络恢复时发送端能够继续通过该传输层的连接传输数据包，无需重新建立传输层的连接，能够提高数据包的传输效率。另外对于接收端来说，如果接收的数据包的序号不连续，则接收端会一直等待接收未接收的数据包，如果等待达到一定的时长，则收发双方的传输层的连接也可能断开。因此本申请实施例中，由于丢弃了一些数据包，则发送端可以对尚未发送的数据包重新设置序号，使得尚未发送的数据包与发送成功的数据包之间的序号连续。对于接收端来说，由于接收的是序号连续的数据包，则接收端可以持续接收，而不会等待被丢弃的数据包，这样也能尽量维持发送端与接收端之间的传输层的连接不断开。

在图3所示的实施例的下行传输过程中，服务器能够感知数据包的传输情况，从而由服务器确定是否丢弃数据包等，这样需要修改服务器的执行过程。下面提供本申请实施例的第二种通信方法，在该方法中，服务器无需感知数据包的传输情况，对服务器的改动较小。请参考图6，为该方法的流程图。

S601、服务器向UPF发送下行数据包，相应的，UPF从服务器接收下行数据包。该下行数据包的数量可以是一个或多个，该下行数据包例如为IP包。该下行数据包属于第一应用，第一应用例如为XR应用，或者也可以是其他视频类应用或图像类应用。

关于S601的更多内容，可参考图3所示的S301。

S602、UPF确定执行TCP代理(proxy)功能。

可以理解为，通过UPF执行TCP代理，将UE与服务器之间的一个TCP连接拆分为两个TCP连接，这两个TCP连接分别为UE与UPF之间的TCP连接、以及UPF与服务器之间的TCP连接。UE对于所接收的数据包的ACK是发送给UPF，UPF不会转发给服务器，而UPF从服务器接收数据包后，UPF会向服务器发送ACK。在本申请实施例中，UE与服务器之间可以有第一TCP连接和第二TCP连接，则这两个TCP连接中的每个都可视为被拆分为了两个TCP连接。

S603、UPF向接入网设备发送第一请求，相应的，接入网设备接收第一请求。

关于S603的更多内容，可参考图3所示的实施例的S302。

S604、UPF通过第一QoS流传输第一数据流的数据包。或者说，UPF通过第一QoS流传输第一TCP连接的数据包。本申请各个实施例所述的数据包例如为IP包。

S605、UPF通过第二QoS流传输第二数据流的数据包。或者说，UPF通过第二QoS流传输第二TCP连接的数据包。

关于S604和S605的更多内容，可参考图3所示的实施例的S303和S304。

S606、接入网设备发送传输失败的数据包的第二信息，相应的，UPF接收传输失败的数据包的第二信息。

关于S606的更多内容，可参考图3所示的实施例的S305。

S607、UPF丢弃所述传输失败的数据包中的部分或全部。

关于S607的更多内容，可参考图3所示的实施例的S307，只是图3所示的实施例的S307是服务器执行，而S607是UPF执行，但执行方式都是类似的。

S608、UPF为尚未发送的数据包重新设置序号，使得尚未发送的数据包与发送成功的数据包的序号连续。尚未发送的数据包例如为第一QoS流传输的数据包中尚未发送的数据包，第二QoS流传输的数据包可不考虑。这里为尚未发送的数据包所设置的序号，例如为TCP层的序号或IP层的序号。

需要注意的是，本申请实施例中UPF执行了TCP代理功能，因此服务器并不能感知数据包的传输情况。服务器只需向UPF发送数据包，UPF接收数据包后可以向服务器发送ACK，则服务器接收ACK后就可持续向UPF发送数据包。对于UPF来说，如果有数据包传输失败，则还是可能一直从服务器接收数据包，只是这些数据包可能都得作为尚未发送的数据包来处理。

关于S608的更多内容，可参考图3所示的实施例的S308，只是图3所示的实施例的S308是服务器执行，而S608是UPF执行，但执行方式都是类似的。

S609、在确定网络恢复正常时，UPF发送尚未发送的数据包，相应的，UE接收这些数据包。或者，在第一定时器超时时，UPF发送尚未发送的数据包，相应的，UE接收这些数据包。该尚未发送的数据包，例如是第一QoS流上尚未发送的数据包。例如，UPF将尚未发送的数据包映射到第一QoS流上发送给UE。

关于S609的更多内容，可参考图3所示的实施例的S309，只是图3所示的实施例的S309是服务器执行，而S609是UPF执行，但执行方式都是类似的。

其中，S601～S606、S609是可选的步骤。

如上的各个步骤介绍的是本申请实施例涉及的下行传输的情况，本申请实施例涉及的上行传输的情况与图3所示的实施例涉及的上行传输的情况是类似的，不多赘述。

在本申请实施例中，对于发送端来说，如果在第一QoS流中有传输失败的数据包，则可以将这些数据包中的部分或全部丢弃，相当于不对被丢弃的数据包进行重传，这样发送端的重传次数也不会达到最大重传次数，从而能够尽量维持发送端与接收端之间的传输层的连接不断开。在网络恢复时发送端能够继续通过该传输层的连接传输数据包，无需重新建立传输层的连接，能够提高数据包的传输效率。另外对于接收端来说，如果接收的数据包的序号不连续，则接收端会一直等待接收未接收的数据包，如果等待达到一定的时长，则收发双方的传输层的连接也可能断开。因此本申请实施例中，由于丢弃了一些数据包，则发送端可以对尚未发送的数据包重新设置序号，使得尚未发送的数据包与发送成功的数据包之间的序号连续。对于接收端来说，由于接收的是序号连续的数据包，则接收端可以持续接收，而不会等待被丢弃的数据包，这样也能尽量维持发送端与接收端之间的传输层的连接不断开。且本申请实施例由UPF执行TCP代理，服务器无需感知数据的传输情况，而是正常发送数据包即可，简化了服务器的实现过程。

在图3所示的实施例或图6所示的实施例中，UE与服务器之间都会建立两个TCP连接来传输第一应用的数据，这需要改动服务器的实现方式。下面介绍本申请实施例提供的第三种通信方法，在该方法中，UE与服务器之间只需建立一个TCP连接，对于服务器的改动较小。请参考图7，为该方法的流程图。

S701、服务器向UPF发送下行数据包，相应的，UPF从服务器接收下行数据包。该下行数据包的数量可以是一个或多个，该下行数据包例如为IP包。该下行数据包属于第一应用，第一应用例如为XR应用，或者也可以是其他视频类应用或图像类应用。

在本申请实施例中，服务器与UE之间只需建立一个TCP连接，对于第一应用的数据来说，无论重要程度高或低，服务器都通过这一个TCP连接将第一应用的数据发送给UPF。

S702、UPF确定执行TCP代理功能。

关于S702的更多内容，可参考图6所示的实施例的S602。

S703、UPF确定在UPF与UE之间通过至少两个QoS流传输该TCP连接的数据包。或者说，UPF确定在UPF与UE之间通过至少两个QoS流传输第一应用的数据包。

例如，UPF确定第一应用的数据包的重要程度有区别，有些数据包的重要程度较高，有些数据包的重要程度较低，则UPF可以确定在UPF与UE之间通过至少两个QoS流传输该TCP连接的数据包，不同的QoS流传输不同重要程度的数据包，从而提高数据传输的可靠性。例如本申请实施例中，以第一应用的数据包通过两个QoS流传输为例，这两个QoS流例如包括第一QoS流和第二QoS流。

S704、UPF与UE之间建立第一连接。

第一连接可包括至少两个子流(subflow)，至少两个子流在至少两个QoS流上传输，至少两个QoS流包括第一QoS流，例如至少两个QoS流包括第一QoS流和第二QoS流。第一连接例如为多路传输TCP(multipath TCP，MPTCP)连接，或者也可以是多路QUIC(multipathQUIC，MPQUIC)等其他连接，本申请实施例以第一连接是MPTCP连接为例。

该MPTCP连接可理解为包括至少两个子流，至少两个子流在至少两个QoS流上传输，其中一个QoS流传输一个子流。以第一应用的数据包通过第一QoS流和第二QoS流传输为例，例如该MPTCP连接包括第一子流和第二子流，第一子流通过第一QoS流传输，第二子流通过第二QoS流传输。其中，如果UPF与UE之间尚未建立MPTCP连接，则可执行S704，而如果UPF与UE之间已建立了MPTCP连接，则不必执行S704。关于建立MPTCP连接的过程，将在后文的其他实施例中介绍。

MPTCP连接的好处是，可以对多个路径上传递的数据包进行更好地管控，保证数据包正确有效的传输。而且服务器与UE之间只需建立一个TCP连接即可，对于服务器的修改较小，更利于商用推广。

S705、UPF向接入网设备发送第一请求，相应的，接入网设备接收第一请求。

关于S705的更多内容，可参考图3所示的实施例的S302。

S706、UPF通过第一QoS流传输第一子流的数据包。本申请各个实施例所述的数据包例如为IP包。

S707、UPF通过第二QoS流传输第二子流的数据包。

关于S706和S707的更多内容，可参考图3所示的实施例的S303和S304。

S708、接入网设备发送传输失败的数据包的第二信息，相应的，UPF接收传输失败的数据包的第二信息。

关于S708的更多内容，可参考图3所示的实施例的S606。

S709、UPF丢弃所述传输失败的数据包中的部分或全部。

关于S709的更多内容，可参考图3所示的实施例的S307，只是图3所示的实施例的S307是服务器执行，而S709是UPF执行，但执行方式都是类似的。

S710、UPF为尚未发送的数据包重新设置序号，使得尚未发送的数据包与发送成功的数据包的序号连续。尚未发送的数据包例如为第一QoS流传输的数据包中尚未发送的数据包，第二QoS流传输的数据包可不考虑。这里为尚未发送的数据包所设置的序号，例如为TCP层的序号或IP层的序号。

需要注意的是，本申请实施例中UPF执行了TCP代理功能，因此服务器并不能感知数据包的传输情况。服务器只需向UPF发送数据包，UPF接收数据包后可以向服务器发送ACK，则服务器接收ACK后就可持续向UPF发送数据包。对于UPF来说，如果有数据包传输失败，则还是可能一直从服务器接收数据包，只是这些数据包可能都得作为尚未发送的数据包来处理。

关于S710的更多内容，可参考图3所示的实施例的S308，只是图3所示的实施例的S308是服务器执行，而S710是UPF执行，但执行方式都是类似的。

S711、在确定网络恢复正常时，UPF发送尚未发送的数据包，相应的，UE接收这些数据包。或者，在第一定时器超时时，UPF发送尚未发送的数据包，相应的，UE接收这些数据包。该尚未发送的数据包，例如是第一QoS流上尚未发送的数据包。例如，UPF将尚未发送的数据包映射到第一QoS流上发送给UE。

关于S711的更多内容，可参考图3所示的实施例的S309，只是图3所示的实施例的S309是服务器执行，而S711是UPF执行，但执行方式都是类似的。

其中，S701～S708、S711是可选的步骤。

如上的各个步骤介绍的是本申请实施例涉及的下行传输的情况，本申请实施例涉及的上行传输的情况与图3所示的实施例涉及的上行传输的情况是类似的，不多赘述。

在本申请实施例中，对于发送端来说，如果在第一QoS流中有传输失败的数据包，则可以将这些数据包中的部分或全部丢弃，相当于不对被丢弃的数据包进行重传，这样发送端的重传次数也不会达到最大重传次数，从而能够尽量维持发送端与接收端之间的传输层的连接不断开。在网络恢复时发送端能够继续通过该传输层的连接传输数据包，无需重新建立传输层的连接，能够提高数据包的传输效率。另外对于接收端来说，如果接收的数据包的序号不连续，则接收端会一直等待接收未接收的数据包，如果等待达到一定的时长，则收发双方的传输层的连接也可能断开。因此本申请实施例中，由于丢弃了一些数据包，则发送端可以对尚未发送的数据包重新设置序号，使得尚未发送的数据包与发送成功的数据包之间的序号连续。对于接收端来说，由于接收的是序号连续的数据包，则接收端可以持续接收，而不会等待被丢弃的数据包，这样也能尽量维持发送端与接收端之间的传输层的连接不断开。而且本申请实施例中服务器与UE之间只需建立一个传输层的连接，对于服务器的改动较小。另外本申请实施例由UPF执行TCP代理，服务器无需感知数据的传输情况，而是正常发送数据包即可，简化了服务器的实现过程。

在如上的几个实施例中，服务器或UPF采用的是丢弃传输失败的数据包，且对尚未发送的数据包重新设置序号的方式来维持传输层的连接，接下来提供本申请实施例提供的第四种通信方法，在该方法中，无需对尚未发送失败的数据包重新设置序号，接收端可以自行构造传输失败的数据包，从而也能维持传输层的连接不断开。请参考图8，为该方法的流程图。

S801、服务器向UPF发送下行数据包，相应的，UPF从服务器接收下行数据包。该下行数据包的数量可以是一个或多个，该下行数据包例如为IP包。该下行数据包属于第一应用，第一应用例如为XR应用，或者也可以是其他视频类应用或图像类应用。

关于S801的更多内容，可参考图3所示的实施例的S301。

S802、UPF向接入网设备发送第一请求，相应的，接入网设备接收第一请求。

关于S802的更多内容，可参考图3所示的实施例的S302。

S803、UPF通过第一QoS流传输第一数据流的数据包。或者说，UPF通过第一QoS流传输第一TCP连接的数据包。本申请各个实施例所述的数据包例如为IP包。

S804、UPF通过第二QoS流传输第二数据流的数据包。或者说，UPF通过第二QoS流传输第二TCP连接的数据包。

关于S803和S804的更多内容，可参考图3所示的实施例的S303和S304。

S805、接入网设备发送传输失败的数据包的第二信息，相应的，UPF接收传输失败的数据包的第二信息。

关于S805的更多内容，可参考图3所示的实施例的S305。

S806、UPF向服务器发送传输失败的数据包的第一信息，相应的，服务器从UPF接收传输失败的数据包的第一信息。

关于S806的更多内容，可参考图3所示的实施例的S306。

S807、服务器向UE发送第五信息，相应的，UE从服务器接收第五信息。

第五信息可指示第一通信装置在第一QoS流中发送失败(或者说，传输失败)的部分或全部的数据包的序号，或者，第五信息可用于确定第一通信装置在第一QoS流中发送失败的部分或全部的数据包的序号，该序号例如为TCP层的序号或IP层的序号，此时的第一通信装置例如为服务器。例如第一QoS流中传输失败的数据包包括数据包1～5以及数据包12～13，其中数据包1～5对应帧A，数据包12～13对应帧B，而帧A还对应数据包6～10，帧B还对应数据包11、14～20。服务器丢弃了数据包1～5以及数据包12～13，并未丢弃数据包6～10、以及数据包11、14～20，那么第五信息可指示数据包1～5的序号，以及指示数据包12～13的序号，而可以不指示数据包6～10的序号，也不指示数据包11、14～20的序号。

或者，如果服务器除了丢弃传输失败的部分或全部数据包外，还确定传输失败的数据包对应的帧，并丢弃了这些帧对应的剩余数据包，那么第五信息可指示第一通信装置在第一QoS流中发送失败的部分或全部的数据包对应的帧所对应的全部数据包的序号，或者，第五信息可用于确定第一通信装置在第一QoS流中发送失败的部分或全部的数据包对应的帧所对应的全部数据包的序号，该序号例如为TCP层的序号或IP层的序号，此时的第一通信装置例如为服务器。例如第一QoS流中传输失败的数据包包括数据包1～5以及数据包12～13，其中数据包1～5对应帧A，数据包12～13对应帧B，而帧A还对应数据包6～10，帧B还对应数据包11、14～20。服务器丢弃了数据包1～5以及数据包12～13，并未丢弃数据包6～10、以及数据包11、14～20，那么第五信息可指示数据包1～20的序号。

可理解为，第五信息指示的是服务器丢弃的全部数据包的序号。服务器丢弃的全部数据包，例如包括发送失败的部分或全部数据包，可选的，还包括发送失败的部分或全部的数据包对应的帧所对应的剩余数据包。

第一通信装置是发送失败的数据包的发送端，例如本申请实施例中第一通信装置为服务器。可选的，第五信息还可指示传输失败的部分或全部数据包的其他信息，例如数据包的大小(size)等。

由于此时第一TCP连接可能无法正常传输，或者说第一QoS流可能无法正常传输，因此可选的，服务器可通过第二QoS流向UE发送第五信息，或者理解为，服务器通过第二TCP连接向UPF发送第五信息，UPF通过第二QoS流将第五信息发送给UE。通过第二TCP连接发送第五信息，能够提高第五信息的发送成功率。

S808、UE根据第五信息生成(或，构造)第二数据包。第二数据包的数量可以是一个或多个。

UE(例如UE的modem)接收第五信息后，可根据第五信息生成第二数据包，其中，第二数据包的序号与第五信息指示的数据包的序号相同，数据包的序号例如为数据包的TCP层的序号或IP层的序号。例如第五信息指示了数据包1～5，则UE生成的第二数据包的数量为5，这5个数据包的序号为1～5。UE的modem可将第二数据包发送给UE的TCP层(或者称为TCP实体，或者称为TCP层)，则UE的TCP层就认为接收了与已成功接收的数据包的序号连续的数据包。第二数据包自然不是真实的数据包，并不包括第五信息指示的数据包的真正的负载(payload)，只是为了使得UE的TCP层认为所接收的数据包的序号是连续的。对于UE的应用层来说，能够识别这些数据包的内容，从而能够确定这些数据包并不对应第一应用的任何帧，因此不会出现输出混乱的情况。

与图3所示的实施例不同的是，服务器虽然丢弃了数据包，但由于UE自行生成了序号与这些数据包的序号相同的数据包，因此服务器无需为尚未发送的数据包重新设置序号，在网络恢复时，服务器继续发送尚未发送的数据包即可。关于服务器确定网络恢复的方式，可参考图3所示的实施例。UE在网络恢复后从服务器接收了之前尚未发送的数据包，由于UE已经构造了被服务器丢弃的数据包，因此UE的TCP层会认为被服务器丢弃的数据包已经收到，则UE的TCP层不会等待接收这些数据包，而从服务器接收的尚未发送的数据包与之前已成功接收的数据包的序号是连续的，则UE的TCP层会保持接收状态，从而就可以维持UE与服务器之间的TCP连接不断开。

其中，S801～S806是可选的步骤。

如上的各个步骤介绍的是本申请实施例涉及的下行传输的情况，下面介绍本申请实施例涉及的上行传输的情况。

UE的应用层中提供第一应用的APP产生业务数据后，该APP或AP将业务数据封装到数据包(例如IP包)中。UE的modem向接入网设备请求无线资源，以通过接入网设备和UPF将这些数据包发送给服务器。其中，UE通过第一QoS流和第二QoS流传输第一应用的数据。

例如UE的modem接收到来自应用层的需要通过第一QoS流传输的数据包，但网络出现了问题，例如网络拥塞或网络资源不足等，则modem无法完成这些数据包的发送。在这种情况下，modem可以根据第一QoS流的数据发送情况确定传输失败的数据包的第一信息，且modem可将第一信息发送给UE的应用层。可选的，modem还可以向应用层发送第三信息和/或第四信息。关于这些信息的内容，可参考前文的介绍。

UE的应用层(例如AP或UE中安装的提供第一应用的APP)可直接丢弃传输失败的数据包中的部分或全部，可选的，还可丢弃传输失败的数据包对应的帧所对应的剩余数据包，或者，UE的应用层也可根据传输失败的原因确定是否丢弃数据包，关于这部分内容可参考图3所示的实施例的S307。如果UE的应用层丢弃了数据包，则UE可以向服务器发送第五信息，例如UE通过第二QoS流向服务器发送第五信息。或者理解为，UE通过第二QoS流向UPF发送第五信息，UPF通过第二TCP连接将第五信息发送给服务器。通过第二TCP连接发送第五信息，能够提高第五信息的发送成功率。此时的第一通信装置为UE。

服务器接收第五信息后，可根据第五信息生成第二数据包，第二数据包的序号与第五信息指示的数据包的序号相同。服务器可将第二数据包发送给服务器的TCP层(或者称为TCP实体，或者称为TCP层)，则服务器的TCP层就认为接收了与已成功接收的数据包的序号连续的数据包。

与图3所示的实施例不同的是，UE虽然丢弃了数据包，但由于服务器自行生成了序号与这些数据包的序号相同的数据包，因此UE无需为尚未发送的数据包重新设置序号，在网络恢复时，UE继续发送尚未发送的数据包即可。关于UE确定网络恢复的方式，可参考图3所示的实施例。服务器在网络恢复后从UE接收了之前尚未发送的数据包，由于服务器已经构造了被UE丢弃的数据包，因此服务器的TCP层会认为被UE丢弃的数据包已经收到，则服务器的TCP层不会等待接收这些数据包，而从UE接收的尚未发送的数据包与之前已成功接收的数据包的序号是连续的，则服务器的TCP层会保持接收状态，从而就可以维持UE与服务器之间的TCP连接不断开。

在本申请实施例中，对于发送端来说，如果在第一QoS流中有传输失败的数据包，则可以将这些数据包中的部分或全部丢弃，相当于不对被丢弃的数据包进行重传，这样发送端的重传次数也不会达到最大重传次数，从而能够尽量维持发送端与接收端之间的传输层的连接不断开。在网络恢复时发送端能够继续通过该传输层的连接传输数据包，无需重新建立传输层的连接，能够提高数据包的传输效率。另外对于接收端来说，如果接收的数据包的序号不连续，则接收端会一直等待接收未接收的数据包，如果等待达到一定的时长，则收发双方的传输层的连接也可能断开。因此本申请实施例中，发送端可向接收端指示发送失败的数据包的序号等信息，接收端可据此自行生成序号与发送失败的数据包的序号相同的数据包，从而接收端会认为所接收的数据包的序号是连续的，这样也能尽量维持发送端与接收端之间的传输层的连接不断开。

在图8所示的实施例的下行传输过程中，服务器能够感知数据包的传输情况，从而由服务器确定是否丢弃数据包等，这样需要修改服务器的执行过程。下面提供本申请实施例的第五种通信方法，在该方法中，服务器无需感知数据包的传输情况，对服务器的改动较小。请参考图9，为该方法的流程图。

S901、服务器向UPF发送下行数据包，相应的，UPF从服务器接收下行数据包。该下行数据包的数量可以是一个或多个，该下行数据包例如为IP包。该下行数据包属于第一应用，第一应用例如为XR应用，或者也可以是其他视频类应用或图像类应用。

关于S901的更多内容，可参考图3所示的S301。

S902、UPF确定执行TCP代理功能。

关于S902的更多内容，可参考图3所示的S302。

S903、UPF向接入网设备发送第一请求，相应的，接入网设备接收第一请求。

关于S903的更多内容，可参考图3所示的实施例的S302。

S904、UPF通过第一QoS流传输第一数据流的数据包。或者说，UPF通过第一QoS流传输第一TCP连接的数据包。本申请各个实施例所述的数据包例如为IP包。

S905、UPF通过第二QoS流传输第二数据流的数据包。或者说，UPF通过第二QoS流传输第二TCP连接的数据包。

关于S904和S905的更多内容，可参考图3所示的实施例的S303和S304。

S906、接入网设备发送传输失败的数据包的第二信息，相应的，UPF接收传输失败的数据包的第二信息。

例如UPF记录了数据包的序号(例如TCP层的序号或IP层的序号)与GTP包头的序号之间的对应关系，则UPF接收第二信息后，可将第二信息指示的GTP包头的序号映射为TCP层的序号或IP层的序号，并据此得到传输失败的数据包的第一信息，第一信息可指示在第一QoS流中传输失败的数据包的序号，第一信息所指示的传输失败的数据包的序号是这些数据包的TCP层的序号或IP层的序号。可选的，第一信息用于UPF确定在第一QoS流中传输失败的数据包的序号。

关于S906的更多内容，可参考图3所示的实施例的S305。

S907、UPF向UE发送第五信息，相应的，UE从UPF接收第五信息。第五信息可指示第一通信装置在第一QoS流中发送失败的部分或全部数据包的序号，或者，第五信息用于确定在第一QoS流中发送失败的部分或全部数据包的序号。

或者，第五信息可指示第一通信装置在第一QoS流中发送失败的部分或全部的数据包对应的帧所对应的全部数据包的序号，或者，第五信息可用于确定第一通信装置在第一QoS流中发送失败的部分或全部的数据包对应的帧所对应的全部数据包的序号。

此时第一通信装置例如为UPF。

关于S907的更多内容，可参考图8所示的实施例的S807。

S908、UE根据第五信息生成第二数据包，第二数据包的序号与第五信息指示的数据包的序号相同。数据包的序号例如为数据包的TCP层的序号或IP层的序号。

关于S908的更多内容，可参考图8所示的实施例的S808。

其中，S901～S907是可选的步骤。

如上的各个步骤介绍的是本申请实施例涉及的下行传输的情况，下面介绍本申请实施例涉及的上行传输的情况。

UE的应用层中提供第一应用的APP产生业务数据后，该APP或AP将业务数据封装到数据包(例如IP包)中。UE的modem向接入网设备请求无线资源，以通过接入网设备和UPF将这些数据包发送给服务器。其中，UE通过第一QoS流和第二QoS流传输第一应用的数据。

例如UE的modem接收到来自应用层的需要通过第一QoS流传输的数据包，但网络出现了问题，例如网络拥塞或网络资源不足等，则modem无法完成这些数据包的发送。在这种情况下，modem可以根据第一QoS流的数据发送情况确定传输失败的数据包的第一信息，且modem可将第一信息发送给UE的应用层。可选的，modem还可以向应用层发送第三信息和/或第四信息。关于这些信息的内容，可参考前文的介绍。

UE的应用层(例如AP或UE中安装的提供第一应用的APP)可直接丢弃传输失败的数据包中的部分或全部，可选的，还可丢弃传输失败的数据包对应的帧所对应的剩余数据包，或者，UE的应用层也可根据传输失败的原因确定是否丢弃的数据包，关于这部分内容可参考图3所示的实施例的S307。如果UE的应用层丢弃了数据包，则UE可以UPF发送第五信息，例如UE通过第二QoS流向UPF发送第五信息。通过第二QoS流发送第五信息，能够提高第五信息的发送成功率。此时的第一通信装置为UE。

UPF接收第五信息后，可根据第五信息生成第二数据包，第二数据包的序号与第五信息指示的数据包的序号相同。UE可将第二数据包发送给UPF的TCP层(或者称为TCP实体，或者称为TCP层)，则UPF的TCP层就认为接收了与已成功接收的数据包的序号连续的数据包。

与图3所示的实施例不同的是，UE虽然丢弃了数据包，但由于UPF自行生成了序号与这些数据包的序号相同的数据包，因此UE无需为尚未发送的数据包重新设置序号，在网络恢复时，UE继续发送尚未发送的数据包即可。关于UE确定网络恢复的方式，可参考图3所示的实施例。UPF在网络恢复后从UE接收了之前尚未发送的数据包，由于UPF已经构造了被服务器丢弃的数据包，因此UPF的TCP层会认为被UE丢弃的数据包已经收到，则服务器的TCP层不会等待接收这些数据包，而从UE接收的尚未发送的数据包与之前已成功接收的数据包的序号是连续的，则UPF的TCP层会保持接收状态，从而就可以维持UE与UPF之间的TCP连接不断开，相应的就可维持UE与服务器之间的TCP连接不断开。

在本申请实施例中，对于发送端来说，如果在第一QoS流中有传输失败的数据包，则可以将这些数据包中的部分或全部丢弃，相当于不对被丢弃的数据包进行重传，这样发送端的重传次数也不会达到最大重传次数，从而能够尽量维持发送端与接收端之间的传输层的连接不断开。在网络恢复时发送端能够继续通过该传输层的连接传输数据包，无需重新建立传输层的连接，能够提高数据包的传输效率。另外对于接收端来说，如果接收的数据包的序号不连续，则接收端会一直等待接收未接收的数据包，如果等待达到一定的时长，则收发双方的传输层的连接也可能断开。因此本申请实施例中，发送端可向接收端指示发送失败的数据包的序号等信息，接收端可据此自行生成序号与发送失败的数据包的序号相同的数据包，从而接收端会认为所接收的数据包的序号是连续的，这样也能尽量维持发送端与接收端之间的传输层的连接不断开。且本申请实施例由UPF执行TCP代理，服务器无需感知数据的传输情况，而是正常发送数据包即可，简化了服务器的实现过程。

在图8所示的实施例或图9所示的实施例中，UE与服务器之间都会建立两个TCP连接来传输第一应用的数据，这需要改动服务器的实现方式。下面介绍本申请实施例提供的第六种通信方法，在该方法中，UE与服务器之间只需建立一个传输层的连接，对于服务器的改动较小。请参考图10，为该方法的流程图。

S1001、服务器向UPF发送下行数据包，相应的，UPF从服务器接收下行数据包。该下行数据包的数量可以是一个或多个，该下行数据包例如为IP包。该下行数据包属于第一应用，第一应用例如为XR应用，或者也可以是其他视频类应用或图像类应用。

关于S1001的更多内容，可参考图7所示的实施例的S701。

S1002、UPF确定执行TCP代理功能。

关于S1002的更多内容，可参考图7所示的实施例的S702。

S1003、UPF确定在UPF与UE之间通过至少两个QoS流传输该TCP连接的数据包。或者说，UPF确定在UPF与UE之间通过至少两个QoS流传输第一应用的数据包。

关于S1003的更多内容，可参考图7所示的实施例的S703。

S1004、UPF与UE之间建立第一连接。

关于S1004的更多内容，可参考图7所示的实施例的S704。

S1005、UPF向接入网设备发送第一请求，相应的，接入网设备接收第一请求。

关于S1005的更多内容，可参考图7所示的实施例的S704。

S1006、UPF通过第一QoS流传输第一子流的数据包。本申请各个实施例所述的数据包例如为IP包。

S1007、UPF通过第二QoS流传输第二子流的数据包。

关于S1006和S1007的更多内容，可参考图7所示的实施例的S705和S706。

S1008、接入网设备发送传输失败的数据包的第二信息，相应的，UPF接收传输失败的数据包的第二信息。

关于S1008的更多内容，可参考图7所示的实施例的S707。

S1009、UPF向UE发送第五信息，相应的，UE从UPF接收第五信息。

第五信息可指示第一通信装置在第一QoS流中发送失败的部分或全部数据包的序号，或者，第五信息用于确定在第一QoS流中发送失败的部分或全部数据包的序号。

或者，第五信息可指示第一通信装置在第一QoS流中发送失败的部分或全部的数据包对应的帧所对应的全部数据包的序号，或者，第五信息可用于确定第一通信装置在第一QoS流中发送失败的部分或全部的数据包对应的帧所对应的全部数据包的序号。

此时第一通信装置例如为UPF。

关于S1009的更多内容，可参考图8所示的实施例的S807。

S1010、UE根据第五信息生成第二数据包，第二数据包的序号与第五信息指示的数据包的序号相同。数据包的序号例如为数据包的TCP层的序号或IP层的序号。

关于S1010的更多内容，可参考图8所示的实施例的S808。

其中，S1001～S1008是可选的步骤。

如上的各个步骤介绍的是本申请实施例涉及的下行传输的情况，关于本申请实施例涉及的上行传输的情况可参考图9所示的实施例，不多赘述。

在本申请实施例中，对于发送端来说，如果在第一QoS流中有传输失败的数据包，则可以将这些数据包中的部分或全部丢弃，相当于不对被丢弃的数据包进行重传，这样发送端的重传次数也不会达到最大重传次数，从而能够尽量维持发送端与接收端之间的传输层的连接不断开。在网络恢复时发送端能够继续通过该传输层的连接传输数据包，无需重新建立传输层的连接，能够提高数据包的传输效率。另外对于接收端来说，如果接收的数据包的序号不连续，则接收端会一直等待接收未接收的数据包，如果等待达到一定的时长，则收发双方的传输层的连接也可能断开。因此本申请实施例中，发送端可向接收端指示传输失败的数据包的序号等信息，接收端可据此自行生成序号与发送失败的数据包的序号相同的数据包，从而接收端会认为所接收的数据包的序号是连续的，这样也能尽量维持发送端与接收端之间的传输层的连接不断开。且本申请实施例由UPF执行TCP代理，服务器无需感知数据的传输情况，而是正常发送数据包即可，简化了服务器的实现过程。另外本申请实施例由UPF执行TCP代理，服务器无需感知数据的传输情况，而是正常发送数据包即可，简化了服务器的实现过程。

在图7所示的实施例以及图10所示的实施例中都涉及到了建立第一连接，第一连接的一种实现方式为MPTCP连接，下面通过一个实施例来介绍建立MPTCP连接的过程。可参考图11，为该实施例的流程图。

S1101、SMF确定为第一应用建立两个QoS流。

例如SMF可根据第一应用的类型确定为第一应用建立两个QoS流，或者SMF也可以根据其他因素确定为第一应用建立两个QoS流。

S1102、SMF向UPF发送第一会话修改请求消息(session modification request)，相应的，UPF从SMF接收第一会话修改请求消息。第一会话修改请求消息可携带指示建立MPTCP连接的信息。

S1103、UPF向SMF发送第七信息，相应的，SMF从UPF接收第七信息。第七信息例如包括用于建立MPTCP连接的信息，例如第七信息携带在第一会话修改响应消息(sessionmodification response)中。作为一种示例，第七信息包括该MPTCP连接所使用的两个端口号，和/或，包括UPF支持MPTCP代理的信息。这两个端口为UPF上的端口，用于传输该MPTCP连接。

以图11所示的实施例是要为图7所示的实施例建立MPTCP连接为例，例如UPF执行了S703，即，UPF确定在UPF与UE之间通过至少两个QoS流传输第一应用的数据包，则UPF可执行S1103，否则，如果UPF未执行S703，例如UPF确定在UPF与UE之间通过一个QoS流传输第一应用的数据包，则UPF可不执行S1103。

S1104、SMF向AMF发送第八信息，相应的，AMF从SMF接收第八信息。例如第八信息包括S1103所述的用于建立MPTCP连接的信息。

S1105、AMF向UE发送第九信息，相应的，UE从AMF接收第九信息。第九信息例如包括MPTCP连接相关的信息。

S1106、UE根据MPTCP连接相关的信息与UPF建立MPTCP连接。

例如，UE确定第一应用的数据包需要使用至少两个QoS流传输，则UE可执行S1106。如果UE确定第一应用的数据包通过一个QoS流传输，则无需执行S1106。

通过如上过程，UE与UPF之间就建立了MPTCP连接。当然这种建立MPTCP连接的过程只是示例，本申请实施例不限于通过其他方式建立MPTCP连接。

因为图11所示的实施例是可选的实施例，因此图11中的各个步骤均为可选的步骤，在图11中均用实线表示，以便于理解。

综上，通过本申请实施例提供的方案，能够尽量维持发送端与接收端之间的TCP连接不断开，在恢复传输后可继续使用原有的TCP连接，无需新建TCP连接，能够提高数据传输效率，也可以减少由于新建TCP连接而带来的传输开销。

需注意的是，本申请的各个实施例均以通过第一QoS流和第二QoS流传输第一应用的数据流为例。但对于设备(包括接入网设备、UPF、服务器或UE中的一个或多个设备，具体以上述各个实施例的介绍为准)会丢弃传输失败的数据包对应的帧的剩余数据包这种方案来说，也可以通过一个QoS流来传输第一应用的数据流，例如通过一个QoS流来传输第一应用的第一数据流和第二数据流，那么对于图7或图10所示的实施例来说也无需建立第一连接。

例如，第一应用为XR应用。用户通过XR客户端启动了XR应用，则XR客户端(即，UE)与服务器之间建立会话(例如协议数据单元(protocol data unit，PDU)会话)，建立相应的QoS流(例如第一QoS流和第二QoS流)，从而开始传输数据包，则用户可以观看XR视频。在观看视频的过程中，可能网络质量下降，例如网络出现拥塞的情况，那么接入网设备可能开始丢弃第一QoS流传输的一些数据包，第一QoS流传输P1帧和/或P2帧对应的数据包。在网络恢复之前，服务器可能不会传输数据包，对于用户来说，可能会出现卡顿的情况，并且由于丢失了一些数据包，因此卡顿的画面的质量可能也不是很好。在网络恢复之后，由于XR客户端与服务器之间的连接没有断掉，服务器可以及时恢复传输。而由于服务器对尚未发送的数据包进行了重新编号，或者XR客户端自行构造了第二数据包，因此XR客户端的传输层(例如TCP层)会认为没有丢失的数据包，则会持续接收数据包，而不会因为一直等待丢失的数据包而导致连接断掉，使得XR客户端与服务器之间的连接得以维持。对于用户来说，可能恢复之后的一帧或几帧可能有效果不好的情况，甚至可能会发现画面不连续，可能有丢失的帧，但是在此之后画面就会恢复正常，而且画面恢复很快，即使有丢失的帧可能影响也不大，能够给用户带来较好的体验。

基于前述的方法实施例，介绍本申请实施例提供的通信装置。

本申请实施例提供一种通信装置，该通信装置例如包括处理单元和收发单元(或者，称为通信单元)，处理单元可用于实现图3所示的实施例、图6所示的实施例、图7所示的实施例、图8所示的实施例、图9所示的实施例、图10所示的实施例或图11所示的实施例中的任一个实施例所述的UE的处理功能，收发单元可用于实现图3所示的实施例、图6所示的实施例、图7所示的实施例、图8所示的实施例、图9所示的实施例、图10所示的实施例或图11所示的实施例中的任一个实施例所述的UE的全部收发功能或部分收发功能。或者，处理单元可用于实现图3所示的实施例、图6所示的实施例、图7所示的实施例、图8所示的实施例、图9所示的实施例、图10所示的实施例或图11所示的实施例中的任一个实施例所述的网络设备所实现的处理功能，收发单元可用于实现图3所示的实施例、图6所示的实施例、图7所示的实施例、图8所示的实施例、图9所示的实施例、图10所示的实施例或图11所示的实施例中的任一个实施例所述的网络设备的全部收发功能或部分收发功能。所述网络设备例如为服务器或UPF等。具体的功能可以参见上述方法实施例中的说明。

可选的，处理单元和/或收发单元可通过虚拟模块实现，例如处理单元可通过软件功能单元或虚拟装置实现，收发单元可通过软件功能单元或虚拟装置实现。或者，处理单元和/或收发单元也可通过实体装置(例如电路系统和/或处理器等)实现。对于处理单元和收发单元通过实体装置实现的情况，下面进行介绍。

本申请实施例提供了一种终端设备，该终端设备(为描述方便，称为UE)可用于前述各个实施例中。所述终端设备包括用以实现图3所示的实施例、图6所示的实施例、图7所示的实施例、图8所示的实施例、图9所示的实施例、图10所示的实施例或图11所示的实施例中的任一个实施例所述的终端设备功能的相应的手段(means)、单元和/或电路。例如，终端设备，包括收发模块，用以支持终端设备实现收发功能，和，处理模块，用以支持终端设备对信号进行处理。

图12给出了本申请实施例提供的一种终端设备的结构示意图。

该终端设备1200可适用于图2所示的架构中。为了便于说明，图12仅示出了终端设备1200的主要部件。如图12所示，终端设备1200包括处理器、存储器、控制电路、天线以及输入输出装置。处理器主要用于对通信协议以及通信数据进行处理，以及对整个终端设备1200进行控制，执行软件程序，处理软件程序的数据。存储器主要用于存储软件程序和数据。控制电路主要用于基带信号与射频信号的转换以及对射频信号的处理。天线主要用于收发电磁波形式的射频信号。输入输出装置，例如触摸屏，显示屏，麦克风，键盘等主要用于接收用户输入的数据以及对用户输出数据。

以终端设备1200是手机为例，当终端设备1200开机后，处理器可以读取存储单元中的软件程序，解释并执行软件程序的指令，处理软件程序的数据。当需要通过无线发送数据时，处理器对待发送的数据进行基带处理后，输出基带信号至控制电路，控制电路将基带信号进行射频处理后将射频信号通过天线以电磁波的形式向外发送。当有数据发送到终端设备1200时，控制电路通过天线接收到射频信号，将射频信号转换为基带信号，并将基带信号输出至处理器，处理器将基带信号转换为数据并对该数据进行处理。

本领域技术人员可以理解，为了便于说明，图12仅示出了一个存储器和处理器。在一些实施例中，终端设备1200可以包括多个处理器和存储器。存储器也可以称为存储介质或者存储设备等，本申请实施例对此不做限制。

作为一种可选的实现方式，处理器可以包括基带处理器和中央处理器，基带处理器主要用于对通信协议以及通信数据进行处理，中央处理器主要用于对整个终端设备1200进行控制，执行软件程序，处理软件程序的数据。图12中的处理器集成了基带处理器和中央处理器的功能，本领域技术人员可以理解，基带处理器和中央处理器也可以是各自独立的处理器，通过总线等技术互联。终端设备1200可以包括多个基带处理器以适应不同的网络制式，终端设备1200可以包括多个中央处理器以增强其处理能力，终端设备1200的各个部件可以通过各种总线连接。所述基带处理器也可以表述为基带处理电路或者基带处理芯片。所述中央处理器也可以表述为中央处理电路或者中央处理芯片。对通信协议以及通信数据进行处理的功能可以内置在处理器中，也可以以软件程序的形式存储在存储单元中，由处理器执行软件程序以实现基带处理功能。

在一个例子中，可以将具有收发功能的天线和控制电路视为终端设备1200的收发单元1210，将具有处理功能的处理器视为终端设备1200的处理单元1220。如图12所示，终端设备1200包括收发单元1210和处理单元1220。收发单元也可以称为收发器、收发机、收发装置等。可选的，可以将收发单元1210中用于实现接收功能的器件视为接收单元，将收发单元1210中用于实现发送功能的器件视为发送单元，即收发单元1210包括接收单元和发送单元。示例性的，接收单元也可以称为接收机、接收器、接收电路等，发送单元可以称为发射机、发射器或者发射电路等。

如图13所示，为本申请提供的一种装置示意图，该装置1300可以是网络设备，或者是设置在网络设备内的电路系统(例如芯片系统)。该网络设备可用于前述各个实施例中。所述网络设备包括用以实现图3所示的实施例、图6所示的实施例、图7所示的实施例、图8所示的实施例、图9所示的实施例、图10所示的实施例或图11所示的实施例中的任一个实施例所述的例如网络设备的功能的手段(means)、单元和/或电路。例如，网络设备包括收发模块，用以支持网络设备实现收发功能，和，处理模块，用以支持网络设备对信号进行处理。该网络设备例如为前述实施例中的服务器或UPF等。

该装置1300包括至少一个处理器1301，通信线路1302，以及至少一个通信接口1304。作为一种可选的实施方式，该装置1300还可以包括存储器1303。因为存储器1303不是必须包括的功能模块，而只是可选包括的功能模块，因此在图13中用虚线框表示。

处理器1301可以包括一个通用中央处理器(central processing unit，CPU)，微处理器，特定应用集成电路(application specific integrated circuit，ASIC)，或一个或多个用于控制本申请方案程序执行的集成电路。

通信线路1302可包括一通路，在上述组件之间传送信息。

通信接口1304，使用任何收发器一类的装置，用于与其他设备或通信网络通信，如以太网，无线接入网(radio access network，RAN)，无线局域网(wireless local areanetworks，WLAN)，有线接入网等。

存储器1303可以是只读存储器(read-only memory，ROM)或可存储静态信息和指令的其他类型的静态存储设备，随机存取存储器(random access memory，RAM)或者可存储信息和指令的其他类型的动态存储设备，也可以是电可擦可编程只读存储器(electrically erasable programmable read-only memory，EEPROM)、只读光盘(compactdisc read-only memory，CD-ROM)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器1303可以是独立存在，通过通信线路1302与处理器1301相连接。或者，存储器1303也可以和处理器1301集成在一起。

其中，存储器1303用于存储执行本申请方案的计算机执行指令，并由处理器1301来控制执行。处理器1301用于执行存储器1303中存储的计算机执行指令，从而实现本申请上述实施例提供的通信方法。

可选的，本申请实施例中的计算机执行指令也可以称之为应用程序代码，本申请实施例对此不作具体限定。

在具体实现中，作为一种实施例，处理器1301可以包括一个或多个CPU，例如图13中的CPU0和CPU1。

在具体实现中，作为一种实施例，装置1300可以包括多个处理器，例如图13中的处理器1301和处理器1308。这些处理器中的每一个可以是一个单核(single-CPU)处理器，也可以是一个多核(multi-CPU)处理器。这里的处理器可以指一个或多个设备、电路、和/或用于处理数据(例如计算机程序指令)的处理核。

当图13所示的装置为芯片时，例如是策略控制功能网元的芯片，或会话管理功能网元的芯片，或移动性管理功能网元的芯片，或接入网网元的芯片，或终端设备的芯片，则该芯片包括处理器1301(还可以包括处理器1308)、通信线路1302、存储器1303和通信接口1304。具体地，通信接口1304可以是输入接口、管脚或电路等。存储器1303可以是寄存器、缓存等。处理器1301和处理器1308可以是一个通用的CPU，微处理器，ASIC，或一个或多个用于控制上述任一实施例的通信方法的程序执行的集成电路。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的计算机可读存储介质，可以是计算机能够存取的任何可用介质。以此为例但不限于：计算机可读介质可以包括随机存取存储器(random access memory，RAM)、只读存储器(read-only memory，ROM)、可编程只读存储器(programmable ROM，PROM)、可擦除可编程只读存储器(erasable PROM，EPROM)、电可擦可编程只读存储器(electrically erasableprogrammable read only memory，EEPROM)、紧凑型光盘只读存储器(compact disc read-only memory，CD-ROM)、通用串行总线闪存盘(universal serial bus flash disk)、移动硬盘、或其他光盘存储、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质。另外，通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(static RAM，SRAM)、动态随机存取存储器(dynamic RAM，DRAM)、同步动态随机存取存储器(synchronousDRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(double data rate SDRAM，DDRSDRAM)、增强型同步动态随机存取存储器(enhanced SDRAM，ESDRAM)、同步连接动态随机存取存储器(synchlink DRAM，SLDRAM)或直接内存总线随机存取存储器(direct rambusRAM，DR RAM)。

以上所述，仅为本申请的具体实施方式，但本申请实施例的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请实施例揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请实施例的保护范围之内。因此，本申请实施例的保护范围应所述以权利要求的保护范围为准。

实施例1.一种通信方法，包括：

确定在第一服务质量QoS流中传输失败的数据包的第一信息；

丢弃所述传输失败的数据包中的部分或全部，并为尚未发送的数据包重新设置序号，使得所述尚未发送的数据包与发送成功的数据包的序号连续。

实施例2.根据实施例1所述的方法，所述方法还包括：

丢弃所述传输失败的数据包对应的帧所对应的剩余数据包，所述剩余数据包为所述帧对应的全部数据包中除了所述传输失败的数据包外的数据包。

实施例3.根据实施例1或2所述的方法，第一应用的数据通过所述第一QoS流和第二QoS流传输，所述第一QoS流传输的数据包的重要程度低于所述第二QoS流传输的数据包的重要程度。

实施例4.根据实施例1～3任一项所述的方法，所述第一信息包括以下一种或多种信息：所述传输失败的数据包对应的帧的帧号，所述传输失败的数据包对应的帧的类型，所述传输失败的数据包在帧内的位置，所述传输失败的数据包的个数，或，M个数据包的传输控制协议TCP层的序号或互联网协议IP层的序号；其中，所述M个数据包为所述传输失败的数据包，或为所述传输失败的数据包对应的帧所对应的全部数据包。

实施例5.根据实施例1～4任一项所述的方法，确定在第一QoS流中传输失败的数据包的第一信息，包括：

接收所述第一信息；或，

根据所述第一QoS流的数据发送情况，确定所述第一信息；或，

接收在所述第一QoS流中传输失败的数据包的第二信息，并根据所述第二信息确定所述第一信息。

实施例6.根据实施例5所述的方法，所述第二信息包括以下一种或多种信息：所述传输失败的数据包对应的帧的帧号，所述传输失败的数据包对应的帧的类型，所述传输失败的数据包在帧内的位置，所述传输失败的数据包的个数，或，M个数据包对应的通用分组无线业务隧道传输协议GTP包头的序号；其中，所述M个数据包为所述传输失败的数据包，或为所述传输失败的数据包对应的帧所对应的全部数据包。

实施例7.根据实施例6所述的方法，所述第二信息包括所述M个数据包对应的GTP包头的序号，则，根据所述第二信息确定所述第一信息，包括：

将所述GTP包头的序号映射为所述TCP层的序号或所述IP层的序号，以得到所述第一信息，所述第一信息包括所述M个数据包的TCP层的序号或IP层的序号。

实施例8.根据实施例1～7任一项所述的方法，所述方法还包括：

通过第二QoS流重传N个数据包，所述N个数据包属于所述传输失败的数据包，且所述N个数据包是第一应用的一帧图像对应的部分数据包。

实施例9.根据实施例1～8任一项所述的方法，所述方法还包括：

在确定网络恢复正常时，发送所述尚未发送的数据包；或，

在第一定时器超时时，发送所述尚未发送的数据包。

实施例10.根据实施例9所述的方法，确定网络恢复正常，包括：

接收第六信息，所述第六信息用于指示所述网络恢复正常，或用于指示发送数据包。

实施例11.根据实施例9所述的方法，所述方法还包括：

接收第三信息，所述第三信息用于指示所述第一定时器的定时时长；或，

根据所述第一QoS流的数据发送情况，确定所述第一定时器的定时时长。

实施例12.根据实施例1～11任一项所述的方法，所述方法还包括：

接收第四信息，所述第四信息用于指示传输失败的原因，或，根据所述第一QoS流的数据发送情况确定传输失败的原因；

根据所述传输失败的原因，确定丢弃所述传输失败的数据包中的部分或全部。

实施例13.根据实施例12所述的方法，所述传输失败的原因包括以下的一种或多种：网络拥塞，网络资源不足，或，丢弃低优先级数据包。

实施例14.根据实施例1～13任一项所述的方法，所述方法还包括：

向所述接入网设备发送第一请求，所述第一请求用于请求获取所述第一QoS流的传输信息，所述第一QoS流的传输信息用于指示所述第一QoS流中的数据包传输失败，或指示所述第一QoS流中传输失败的数据包。

实施例15.根据实施例1～14任一项所述的方法，所述方法还包括：

确定所述第一应用的数据通过至少两个QoS流传输；

与所述至少两个QoS流的接收端建立第一连接，所述第一连接包括至少两个子流，所述至少两个子流在至少两个QoS流上传输，所述至少两个QoS流包括所述第一QoS流。

实施例16.一种通信方法，包括：

向接入网设备发送第一请求，所述第一请求用于请求订阅第一服务质量QoS流的传输信息，所述第一QoS流的传输信息用于指示所述第一QoS流传输失败，或指示所述第一QoS流中传输失败的数据包。

实施例17.根据实施例16所述的方法，第一应用的数据通过所述第一QoS流和第二QoS流传输，所述第一QoS流的服务质量低于所述第二QoS流。

实施例18.根据16或17所述的方法，所述方法还包括：

从所述接入网设备接收所述第一QoS流中传输失败的数据包的第二信息；

根据所述第二信息确定所述第一QoS流中传输失败的数据包的第一信息；

向应用服务器发送所述第一信息，所述应用服务器与所述第一应用对应。

实施例19.根据18所述的方法，所述第二信息包括以下一种或多种信息：所述传输失败的数据包对应的帧的帧号，所述传输失败的数据包对应的帧的类型，所述传输失败的数据包在帧内的位置，所述传输失败的数据包的个数，或，M个数据包对应的通用分组无线业务隧道传输协议GTP包头的序号；其中，所述M个数据包为所述传输失败的数据包，或为所述传输失败的数据包对应的帧所对应的全部数据包。

实施例20.根据实施例19所述的方法，所述第二信息包括所述M个数据包对应的GTP包头的序号，则，根据所述第二信息确定所述第一信息，包括：

将所述GTP包头的序号映射为传输控制协议TCP层的序号或互联网协议IP层的序号，以得到所述第一信息，所述第一信息包括所述M个数据包的TCP层的序号或IP层的序号。

实施例21.根据实施例18～20任一项所述的方法，所述第一信息包括以下一种或多种信息：所述传输失败的数据包对应的帧的帧号，所述传输失败的数据包对应的帧的类型，所述传输失败的数据包在帧内的位置，所述传输失败的数据包的个数，或，M个数据包的TCP层的序号或IP层的序号；其中，所述M个数据包为所述传输失败的数据包，或为所述传输失败的数据包对应的帧所对应的全部数据包。

实施例22.一种通信方法，包括：

从第一通信装置接收第五信息，所述第五信息用于指示所述第一通信装置在第一服务质量QoS流中发送失败的数据包；

根据所述第五信息生成第二数据包，所述第二数据包的序号与所述发送失败的数据包的序号相同。

实施例23.根据实施例22所述的方法，第一应用的数据通过所述第一QoS流和第二QoS流传输，所述第一QoS流的服务质量低于所述第二QoS流。

实施例24.根据实施例22或23所述的方法，接收第五信息，包括：

通过第二QoS流从所述第一通信装置接收所述第五信息。

实施例25.一种通信装置，包括：

处理单元，用于确定在第一服务质量QoS流中传输失败的数据包的第一信息；

所述处理单元，还用于丢弃所述传输失败的数据包中的部分或全部，并为尚未发送的数据包重新设置序号，使得所述尚未发送的数据包与发送成功的数据包的序号连续。

实施例26.根据实施例25所述的通信装置，所述处理单元，还用于丢弃所述传输失败的数据包对应的帧所对应的剩余数据包，所述剩余数据包为所述帧对应的全部数据包中除了所述传输失败的数据包外的数据包。

实施例27.根据实施例25或26所述的通信装置，第一应用的数据通过所述第一QoS流和第二QoS流传输，所述第一QoS流传输的数据包的重要程度低于所述第二QoS流传输的数据包的重要程度。

实施例28.根据实施例25～27任一项所述的通信装置，所述第一信息包括以下一种或多种信息：所述传输失败的数据包对应的帧的帧号，所述传输失败的数据包对应的帧的类型，所述传输失败的数据包在帧内的位置，所述传输失败的数据包的个数，或，M个数据包的传输控制协议TCP层的序号或互联网协议IP层的序号；其中，所述M个数据包为所述传输失败的数据包，或为所述传输失败的数据包对应的帧所对应的全部数据包。

实施例29.根据实施例25～28任一项所述的通信装置，所述通信装置还包括接收单元；所述处理单元用于通过如下方式确定在第一QoS流中传输失败的数据包的第一信息：

接收所述第一信息；或，

根据所述第一QoS流的数据发送情况，确定所述第一信息；或，

通过所述接收单元接收在所述第一QoS流中传输失败的数据包的第二信息，并根据所述第二信息确定所述第一信息。

实施例30.根据实施例29所述的通信装置，所述第二信息包括以下一种或多种信息：所述传输失败的数据包对应的帧的帧号，所述传输失败的数据包对应的帧的类型，所述传输失败的数据包在帧内的位置，所述传输失败的数据包的个数，或，M个数据包对应的通用分组无线业务隧道传输协议GTP包头的序号；其中，所述M个数据包为所述传输失败的数据包，或为所述传输失败的数据包对应的帧所对应的全部数据包。

实施例31.根据实施例30所述的通信装置，所述第二信息包括所述M个数据包对应的GTP包头的序号，则，所述处理单元用于通过如下方式根据所述第二信息确定所述第一信息：将所述GTP包头的序号映射为所述TCP层的序号或所述IP层的序号，以得到所述第一信息，所述第一信息包括所述M个数据包的TCP层的序号或IP层的序号。

实施例32.根据实施例25～31任一项所述的通信装置，所述通信装置还包括发送单元，用于通过第二QoS流重传N个数据包(或，所述处理单元，还用于通过所述发送单元通过第二QoS流重传N个数据包)，所述N个数据包属于所述传输失败的数据包，且所述N个数据包是第一应用的一帧图像对应的部分数据包。

实施例33.根据实施例25～32任一项所述的通信装置，所述通信装置还包括发送单元；

所述发送单元，用于在确定网络恢复正常时，发送所述尚未发送的数据包(或，所述处理单元，还用于在确定网络恢复正常时，通过所述发送单元发送所述尚未发送的数据包)；或，

所述发送单元，用于在第一定时器超时时，发送所述尚未发送的数据包(或，所述处理单元，还用于在第一定时器超时时，通过所述发送单元发送所述尚未发送的数据包)。

实施例34.根据实施例33所述的通信装置，所述通信装置还包括接收单元，所述处理单元用于通过如下方式确定网络恢复正常：

通过所述接收单元接收第六信息，所述第六信息用于指示所述网络恢复正常，或用于指示发送数据包。

实施例35.根据实施例33所述的通信装置，所述通信装置还包括接收单元；

所述接收单元，用于接收第三信息(或，所述处理单元，还用于通过所述接收单元接收第三信息)，所述第三信息用于指示所述第一定时器的定时时长；或，

所述处理单元，还用于根据所述第一QoS流的数据发送情况，确定所述第一定时器的定时时长。

实施例36.根据实施例25～35任一项所述的通信装置，所述通信装置还包括接收单元；

所述接收单元，用于接收第四信息(或，所述处理单元，还用于通过所述接收单元接收第四信息)，所述第四信息用于指示传输失败的原因；或，所述处理单元，还用于根据所述第一QoS流的数据发送情况确定传输失败的原因；

所述处理单元，还用于根据所述传输失败的原因，确定丢弃所述传输失败的数据包中的部分或全部。

实施例37.根据实施例36所述的通信装置，所述传输失败的原因包括以下的一种或多种：网络拥塞，网络资源不足，或，丢弃低优先级数据包。

实施例38.根据实施例25～37任一项所述的通信装置，所述通信装置还包括发送单元，用于向所述接入网设备发送第一请求(或，所述处理单元，还用于通过所述发送单元向所述接入网设备发送第一请求)，所述第一请求用于请求获取所述第一QoS流的传输信息，所述第一QoS流的传输信息用于指示所述第一QoS流中的数据包传输失败，或指示所述第一QoS流中传输失败的数据包。

实施例39.根据实施例25～38任一项所述的通信装置，所述处理单元还用于：

确定所述第一应用的数据通过至少两个QoS流传输；

与所述至少两个QoS流的接收端建立第一连接，所述第一连接包括至少两个子流，所述至少两个子流在至少两个QoS流上传输，所述至少两个QoS流包括所述第一QoS流。

实施例40.一种通信装置，包括：

发送单元，用于向接入网设备发送第一请求(或，处理单元，用于通过发送单元向接入网设备发送第一请求)，所述第一请求用于请求订阅第一服务质量QoS流的传输信息，所述第一QoS流的传输信息用于指示所述第一QoS流传输失败，或指示所述第一QoS流中传输失败的数据包。

实施例41.根据实施例40所述的通信装置，第一应用的数据通过所述第一QoS流和第二QoS流传输，所述第一QoS流的服务质量低于所述第二QoS流。

实施例42.根据40或41所述的通信装置，所述通信装置还包括接收单元；

所述接收单元，用于从所述接入网设备接收所述第一QoS流中传输失败的数据包的第二信息(或，所述处理单元，还用于通过所述接收单元从所述接入网设备接收所述第一QoS流中传输失败的数据包的第二信息)；

所述处理单元，还用于根据所述第二信息确定所述第一QoS流中传输失败的数据包的第一信息；

所述发送单元，还用于向应用服务器发送所述第一信息(或，所述处理单元，还用于通过所述发送单元向应用服务器发送所述第一信息)，所述应用服务器与所述第一应用对应。

实施例43.根据42所述的通信装置，所述第二信息包括以下一种或多种信息：所述传输失败的数据包对应的帧的帧号，所述传输失败的数据包对应的帧的类型，所述传输失败的数据包在帧内的位置，所述传输失败的数据包的个数，或，M个数据包对应的通用分组无线业务隧道传输协议GTP包头的序号；其中，所述M个数据包为所述传输失败的数据包，或为所述传输失败的数据包对应的帧所对应的全部数据包。

实施例44.根据实施例43所述的通信装置，所述第二信息包括所述M个数据包对应的GTP包头的序号，则，所述处理单元用于通过如下方式根据所述第二信息确定所述第一信息：将所述GTP包头的序号映射为传输控制协议TCP层的序号或互联网协议IP层的序号，以得到所述第一信息，所述第一信息包括所述M个数据包的TCP层的序号或IP层的序号。

实施例45.根据实施例41～44任一项所述的通信装置，所述第一信息包括以下一种或多种信息：所述传输失败的数据包对应的帧的帧号，所述传输失败的数据包对应的帧的类型，所述传输失败的数据包在帧内的位置，所述传输失败的数据包的个数，或，M个数据包的TCP层的序号或IP层的序号；其中，所述M个数据包为所述传输失败的数据包，或为所述传输失败的数据包对应的帧所对应的全部数据包。

实施例46.一种通信装置，包括：

接收单元，用于从第一通信装置接收第五信息(或，处理单元，用于通过接收单元从第一通信装置接收第五信息)，所述第五信息用于指示所述第一通信装置在第一服务质量QoS流中发送失败的数据包；

处理单元，用于根据所述第五信息生成第二数据包，所述第二数据包的序号与所述发送失败的数据包的序号相同。

实施例47.根据实施例46所述的通信装置，第一应用的数据通过所述第一QoS流和第二QoS流传输，所述第一QoS流的服务质量低于所述第二QoS流。

实施例48.根据实施例46或47所述的通信装置，所述接收单元用于通过如下方式接收第五信息：通过第二QoS流从所述第一通信装置接收所述第五信息(或，所述处理单元，用于按照如下方式通过所述接收单元接收第五信息：通过所述接收单元，通过第二QoS流从所述第一通信装置接收所述第五信息)。

实施例49.一种装置，包含用于执行本申请任一实施例所介绍的方法的单元。

Claims (27)

1.一种通信方法，其特征在于，包括：

确定在第一服务质量QoS流中传输失败的数据包的第一信息；

丢弃所述传输失败的数据包中的部分或全部，并为尚未发送的数据包重新设置序号，使得所述尚未发送的数据包与发送成功的数据包的序号连续。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

丢弃所述传输失败的数据包对应的帧所对应的剩余数据包，所述剩余数据包为所述帧对应的全部数据包中除了所述传输失败的数据包外的数据包。

3.根据权利要求1或2所述的方法，其特征在于，第一应用的数据通过所述第一QoS流和第二QoS流传输，所述第一QoS流传输的数据包的重要程度低于所述第二QoS流传输的数据包的重要程度。

4.根据权利要求1～3任一项所述的方法，其特征在于，所述第一信息包括以下一种或多种信息：所述传输失败的数据包对应的帧的帧号，所述传输失败的数据包对应的帧的类型，所述传输失败的数据包在帧内的位置，所述传输失败的数据包的个数，或，M个数据包的传输控制协议TCP层的序号或互联网协议IP层的序号；其中，所述M个数据包为所述传输失败的数据包，或为所述传输失败的数据包对应的帧所对应的全部数据包。

5.根据权利要求1～4任一项所述的方法，其特征在于，确定在第一QoS流中传输失败的数据包的第一信息，包括：

接收所述第一信息；或，

根据所述第一QoS流的数据发送情况，确定所述第一信息；或，

接收在所述第一QoS流中传输失败的数据包的第二信息，并根据所述第二信息确定所述第一信息。

6.根据权利要求5所述的方法，其特征在于，所述第二信息包括以下一种或多种信息：所述传输失败的数据包对应的帧的帧号，所述传输失败的数据包对应的帧的类型，所述传输失败的数据包在帧内的位置，所述传输失败的数据包的个数，或，M个数据包对应的通用分组无线业务隧道传输协议GTP包头的序号；其中，所述M个数据包为所述传输失败的数据包，或为所述传输失败的数据包对应的帧所对应的全部数据包。

7.根据权利要求6所述的方法，其特征在于，所述第二信息包括所述M个数据包对应的GTP包头的序号，则，根据所述第二信息确定所述第一信息，包括：

将所述GTP包头的序号映射为所述TCP层的序号或所述IP层的序号，以得到所述第一信息，所述第一信息包括所述M个数据包的TCP层的序号或IP层的序号。

8.根据权利要求1～7任一项所述的方法，其特征在于，所述方法还包括：

通过第二QoS流重传N个数据包，所述N个数据包属于所述传输失败的数据包，且所述N个数据包是第一应用的一帧图像对应的部分数据包。

9.根据权利要求1～8任一项所述的方法，其特征在于，所述方法还包括：

在确定网络恢复正常时，发送所述尚未发送的数据包；或，

在第一定时器超时时，发送所述尚未发送的数据包。

10.根据权利要求9所述的方法，其特征在于，确定网络恢复正常，包括：

接收第六信息，所述第六信息用于指示所述网络恢复正常，或用于指示发送数据包。

11.根据权利要求9所述的方法，其特征在于，所述方法还包括：

接收第三信息，所述第三信息用于指示所述第一定时器的定时时长；或，

根据所述第一QoS流的数据发送情况，确定所述第一定时器的定时时长。

12.根据权利要求1～11任一项所述的方法，其特征在于，所述方法还包括：

接收第四信息，所述第四信息用于指示传输失败的原因，或，根据所述第一QoS流的数据发送情况确定传输失败的原因；

根据所述传输失败的原因，确定丢弃所述传输失败的数据包中的部分或全部。

13.根据权利要求12所述的方法，其特征在于，所述传输失败的原因包括以下的一种或多种：网络拥塞，网络资源不足，或，丢弃低优先级数据包。

14.根据权利要求1～13任一项所述的方法，其特征在于，所述方法还包括：

向所述接入网设备发送第一请求，所述第一请求用于请求获取所述第一QoS流的传输信息，所述第一QoS流的传输信息用于指示所述第一QoS流中的数据包传输失败，或指示所述第一QoS流中传输失败的数据包。

15.根据权利要求1～14任一项所述的方法，其特征在于，所述方法还包括：

确定所述第一应用的数据通过至少两个QoS流传输；

与所述至少两个QoS流的接收端建立第一连接，所述第一连接包括至少两个子流，所述至少两个子流在至少两个QoS流上传输，所述至少两个QoS流包括所述第一QoS流。

16.一种通信方法，其特征在于，包括：

向接入网设备发送第一请求，所述第一请求用于请求订阅第一服务质量QoS流的传输信息，所述第一QoS流的传输信息用于指示所述第一QoS流传输失败，或指示所述第一QoS流中传输失败的数据包。

17.根据权利要求16所述的方法，其特征在于，第一应用的数据通过所述第一QoS流和第二QoS流传输，所述第一QoS流的服务质量低于所述第二QoS流。

18.根据权利要求16或17所述的方法，其特征在于，所述方法还包括：

从所述接入网设备接收所述第一QoS流中传输失败的数据包的第二信息；

根据所述第二信息确定所述第一QoS流中传输失败的数据包的第一信息；

向应用服务器发送所述第一信息，所述应用服务器与所述第一应用对应。

19.根据权利要求18所述的方法，其特征在于，所述第二信息包括以下一种或多种信息：所述传输失败的数据包对应的帧的帧号，所述传输失败的数据包对应的帧的类型，所述传输失败的数据包在帧内的位置，所述传输失败的数据包的个数，或，M个数据包对应的通用分组无线业务隧道传输协议GTP包头的序号；其中，所述M个数据包为所述传输失败的数据包，或为所述传输失败的数据包对应的帧所对应的全部数据包。

20.根据权利要求19所述的方法，其特征在于，所述第二信息包括所述M个数据包对应的GTP包头的序号，则，根据所述第二信息确定所述第一信息，包括：

将所述GTP包头的序号映射为传输控制协议TCP层的序号或互联网协议IP层的序号，以得到所述第一信息，所述第一信息包括所述M个数据包的TCP层的序号或IP层的序号。

21.根据权利要求18～20任一项所述的方法，其特征在于，所述第一信息包括以下一种或多种信息：所述传输失败的数据包对应的帧的帧号，所述传输失败的数据包对应的帧的类型，所述传输失败的数据包在帧内的位置，所述传输失败的数据包的个数，或，M个数据包的TCP层的序号或IP层的序号；其中，所述M个数据包为所述传输失败的数据包，或为所述传输失败的数据包对应的帧所对应的全部数据包。

22.一种通信方法，其特征在于，包括：

从第一通信装置接收第五信息，所述第五信息用于指示所述第一通信装置在第一服务质量QoS流中发送失败的数据包；

根据所述第五信息生成第二数据包，所述第二数据包的序号与所述发送失败的数据包的序号相同。

23.根据权利要求22所述的方法，其特征在于，第一应用的数据通过所述第一QoS流和第二QoS流传输，所述第一QoS流的服务质量低于所述第二QoS流。

24.根据权利要求22或23所述的方法，其特征在于，接收第五信息，包括：

通过第二QoS流从所述第一通信装置接收所述第五信息。

25.一种通信设备，其特征在于，包括：

一个或多个处理器；

一个或多个存储器；

以及一个或多个计算机程序，其中所述一个或多个计算机程序被存储在所述一个或多个存储器中，所述一个或多个计算机程序包括指令，当所述指令被所述通信设备的一个或多个处理器执行时，使得所述通信设备执行如权利要求1～15中任一项所述的方法，或使得所述通信设备执行如权利要求16～21中任一项所述的方法，或使得所述通信设备执行如权利要求22～24中任一项所述的方法。

26.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质用于存储计算机程序，当所述计算机程序在计算机上运行时，使得所述计算机执行如权利要求1～15中任一项所述的方法，或使得所述计算机执行如权利要求16～21中任一项所述的方法，或使得所述计算机执行如权利要求22～24中任一项所述的方法。

27.一种芯片，其特征在于，包括一个或多个处理器和通信接口，所述一个或多个处理器用于读取指令，以执行如权利要求1～15中任一项所述的方法，或执行如权利要求16～21中任一项所述的方法，或执行如权利要求22～24中任一项所述的方法。

Images