CN112020873A - 用于在多连接中发送和接收数据包流的客户端设备、网络控制节点、以及upf - Google Patents

Abstract

本发明涉及一种用于在移动通信系统(500)中的多连接场景中互通的客户端设备(100)、网络控制节点(300)、以及UPF(510)。由于应用(110)知道如何在移动通信系统(500)中实现所需的QoS/QoE，因此，本发明向应用(110)开放可用网络路径的性能信息和与QoS实现有关的信息，以动态调整QoS要求并将可用资源分配给应用(110)的业务数据流。通过在API中向应用(110)开发人员开放可用路径的网络性能信息和QoS实现的变化，并让应用(110)根据应用特定的标准来定义如何为应用(110)的业务分配资源，可以使移动核心网和QoS框架在移动服务数据传输方面的使用增加并获利。此外，本发明还涉及相应的方法和计算机程序。

Description

用于在多连接中发送和接收数据包流的客户端设备、网络控 制节点、以及UPF

技术领域

本发明涉及一种客户端设备、网络控制节点、以及用户面功能UPF。此外，本发明还涉及相应的方法和计算机程序。

背景技术

未来的5G移动网络需要支持各种新5G服务，这些新5G服务可能会有苛刻的性能要求，例如较大的保证流比特率或较高的IP流可靠性等，而这些都是无法由现有移动网络和当前定义的服务质量QoS框架通过单个无线链路提供的。为了解决向移动服务提供较大的流比特率的问题，引入并标准化5G多RAT双连接(multi-RAT dual connectivity，MR-DC)，使得两个无线网络节点能够向给定的用户设备(user equipment，UE)提供无线资源，从而提供聚合网络带宽并提高每用户吞吐量。

在5G控制面的MR-DC中，单个用户面功能(user plane function，UPF)处理N3接口上的用户面连接，并且存在到接入和移动性功能(access and mobility function，AMF)的单个N2终端。N2接口终止的无线接入节点(radio access node，RAN)称为主RAN节点(master RAN node，MN)。当RAN处存在两个N3隧道终端时，对于给定的分组数据单元(packet data unit，PDU)会话(到同一UPF)，MR-DC提供了将PDU会话的一些服务质量(quality of service，QoS)流的下行(downlink，DL)用户面业务引导到辅RAN节点(secondary RAN node，SN)，而将PDU会话的其余QoS流引导到MN(反之亦然)的可能性。要求不同QoS特性的不同的IP流映射到不同的QoS流，使得例如视频流映射到QFI 1，音频流映射到QFI 2，数据流映射到QFI 3。

5G QoS框架将QoS流定义为PDU会话中最细的QoS区分粒度。由SMF为每个QoS流分配其标识符QFI(QoS流标识符，QoS flow identifier)，该标识符QFI是受到相同的业务转发处理的一组UL/DL包的标记。UE和UPF分别使用QoS规则和服务数据流(service dataflow，SDF)模板将用户面业务(应用的IP流)映射到UL和DL中的QoS流。UPF使用SDF模板(定义为五元组<源IP地址、目的IP地址、源端口号、目的端口号、以及协议ID>)，对传入的数据包进行分类，以识别数据包流的QoS，并在PDU的封装头中添加唯一的QFI。然后，在5G核心网和RAN之间的单个隧道中传输属于PDU会话的QoS流的PDU。因此，在IP流和QoS流之间存在1:1映射。类似地，在UE侧，UE使用存储的QoS规则(用于检测具有QoS流的对应QoS处理的业务的包过滤器)将UL包映射到QoS流，对UL PDU应用QFI标记，并基于RAN提供的映射使用QoS流的接入专用资源来传输这些UL PDU。

RAN允许在主RAN节点和辅RAN节点之间对QoS流进行分流，以便使用两个空中接口上的资源。这种解决方案称为具有到主RAN节点的单个N3终端的MR-DC(RAN分流承载(splitbearer))。在这种情况下，存在到UPF的单个N3终端。在该示例中，QFI 1经由两个空中接口上的两个承载的互连接口(Xn-U)分流在这两个承载上(QFI 1a和QFI 1b)。

3GPP在TR 23.793中发布了关于如何扩展5G系统以支持使用多接入PDU会话在3GPP接入网与非3GPP接入网(即，WLAN和固定接入)之间进行接入业务导向、切换、与分流(access traffic steering,switching and splitting，ATSSS)的一项研究。ATSSS框架将创建接入业务策略(基于AF提供的应用特定信息、AMF提供的接入信息、来自UDR的用户订阅和配置信息、以及网络本地策略)以控制ATSSS业务的行为，并将在UE和5GC之间的所有PDU会话中实施这些接入业务策略。通过分别在UPF和UE针对UPF发起的业务或UE发起的业务实施策略规则，实现在3GPP接入与非3GPP接入之间进行数据流的业务分流。ATSSS初始架构框架重用了标准化的现有接口，并且用新功能扩展了UE和现有网络功能(UPF、SMF、PCF、UDM)。

从协议角度来看，对于在哪个协议栈层上集成多个RAT，使得UE能够经由不同的链路(根据相同或不同的RAT)接收或发送数据流，存在不同的提议：

·使用RLC/MAC(媒体访问控制，medium access control)作为不同PHY层之上的聚合层，该聚合层实现了链路聚合组(lag)之间的快速切换，但仅适用于共址节点或具有理想回程的节点。

·使用PDCP(分组数据汇聚协议，packet data convergence protocol)作为多个RLC/MAC/PHY层之上的聚合层，该聚合层适用于5G NR和演进型LTE之间的紧密互通(即，高性能的RAT间移动性和数据流聚合)，以及非共址节点和具有非理想回程的节点。

·使用TCP之上的多路径协议，例如MPTCP。

·在IP之下定义新的用户面协议，该协议位于UE和用户面功能之上。

RLC/MAC和PDCP层之间的选择取决于不同RAT和传统技术(例如LTE)之间的集成度。MAC和PDCP集成方案对核心网是透明的，在未通知核心网的情况下实现了用户在不同的RAT之间的移动性。MPTCP可以在移动网络中的不同接入接口上创建多个TCP/IP会话，并将这些TCP/IP会话作为子流添加到MPTCP会话中。

发明内容

本发明实施例的目的是提供减轻或解决传统解决方案的缺点和问题的解决方案。

独立权利要求的主题解决了上述目的和其他目的。本发明的其他有利实施例可以在从属权利要求中体现。

根据本发明的第一方面，上述目的和其他目的可以通过用于移动通信系统的客户端设备来实现，该客户端设备用于

从应用接收第一应用请求，其中，第一应用请求指示建立用于传输数据包流的分组数据单元PDU会话的请求；

接收与数据包流相关的一组服务质量QoS要求；

在接收到第一应用请求时，向网络控制节点发送建立PDU会话的请求，使得建立由用户面功能UPF服务的PDU会话，其中，建立的PDU会话承载用于数据包流的第一组QoS流；以及

当第一组QoS流满足一组QoS要求时，客户端设备用于

经由包括第一无线链路和第一回程链路的第一通信链路以及包括第二无线链路和第二回程链路的至少一个第二通信链路，在建立的PDU会话上的第一组QoS流中向UPF发送数据包流。

QoS要求可以理解为需要在客户端设备和数据网络之间(经由UPF)或在客户端设备和另一客户端设备之间建立的具有指定QoS流特性的一组IP流。QoS要求可由应用或策略控制功能(policy control function，PCF)指定，但由应用确定建立的PDU会话中的QoS流特性(可能与第一组中的QoS要求不完全匹配)是否足以用于发送和接收数据包流。控制5GQoS流的特定QoS转发行为的QoS参数(称为5G QoS标识符或5QI)包括：资源类型(GBR、时延关键GBR、或非GBR)、优先级、包时延预算、误包率、以及平均窗口(仅为GBR流定义)。表征GBR(或时延关键GBR)QoS流的其他QoS参数是：分配和保留优先级(allocation and retentionpriority，ARP)、保证流比特率(guaranteed flow bit rate，GFBR)、以及最大流比特率(maximum flow bit rate，MFBR)。

根据第一方面的客户端设备的优点是，其通过动态和更有效地利用网络基础设施和可用带宽来提供较大的保证IP流比特率并满足其他的应用特定的QoS要求，例如较高的可靠性，从而增强了诸如5G的移动通信系统的QoS框架。由于应用知道如何实现所需的QoS/QoE，因此本发明的实施例将可用网络路径的性能信息和QoS实现有关的信息开放给应用，以动态调整QoS要求并将可用资源分配给应用的业务数据流。通过向应用开发人员开放可用路径的网络性能信息和QoS实现的变化并让应用根据应用特定的标准来定义如何为应用的业务分配资源，与传统解决方案相比，特别是对于新移动服务和垂直服务，可以使移动核心网和5G QoS框架在移动服务数据传输方面的使用增加并获利。

在根据第一方面的客户端设备的实施方式中，客户端设备还用于

向UPF发送与建立的PDU会话相关的带内控制信息。

该带内控制信息可以理解为规范诸如5GUP协议的协议行为的数据(参见具体实施方式)。5GUP协议的带内控制信息还允许在UE和UPF之间传输性能测量，并在两个协议实体处同步其状态，该带内控制信息与用户数据在同一建立的PDU会话中发送，但与用户数据不同，该带内控制信息不转发至数据网络(即，意味着由UPF和客户端设备使用)。5GUP协议可以在建立的PDU会话中的每个可用通信路径上分配专用QoS流，用于在客户端设备和UPF之间传输带内控制信息。该带内控制信息可以向UPF传达以下信号和数据：开始、停止、暂停、或恢复向客户端设备发送数据包流和从数据网络接收数据包流；接收并应用数据包流到第一组QoS流或第二组QoS流的映射(或该映射的逆)；或者从客户端设备接收RAN性能测量，获得回程性能测量，并将这些回程性能测量发送至客户端设备。客户端设备从UPF接收也作为带内控制信息的一部分的回程性能测量。

该实施方式的一个优点是不需要在移动通信系统的控制面中建立和维护单独的信令机制。此外，带内控制在接收到应用请求时可以通过触发特定的协议动作作出更快的反应。带内控制信息还使得客户端设备能够了解可用路径的移动网络条件，以便及时通知应用动态地适应网络条件的变化。另一个优点是，利用带内控制信息，可以在应用和UPF处实时监测(无线和回程链路的)链路的QoS特性。

在根据第一方面的客户端设备的实施方式中，客户端设备还用于

经由第一通信链路和至少一个第二通信链路在建立的PDU会话上从UPF接收第一组QoS流中的数据包流。

该实施方式的优点是可以在可用通信路径上建立多个QoS流，以在客户端设备和数据网络之间传输数据包流，从而可以更有效地将聚合网络资源用于数据包流(例如，需要较大的保证流比特率或增加的数据流可靠性)，而这是单个链路无法提供的。当前的5G QoS框架不允许将QoS流分流在多连接路径上来传输给定的数据包流。如果比特率要求太大而不适于一个无线连接或N3隧道，或者单个QoS流提供的可靠性低于应用要求，则QoS框架无法向移动用户提供所请求的QoS/QoE。

在根据第一方面的客户端设备的实施方式中，上述应用运行在客户端设备或另一客户端设备中。

该实施方式的优点是，同样在客户端设备外运行的应用可以使用与在客户端设备内运行时相同的功能，这对于增强现实/虚拟现实类型的应用尤其重要。

在根据第一方面的客户端设备的实施方式中，从应用接收一组QoS要求。

该实施方式的优点是，应用可以在建立PDU会话之前向客户端设备提供与数据包流相关的一组QoS要求，使得客户端设备可以检验在建立的PDU会话中建立的QoS流是否能够满足这些QoS要求，并相应地调整协议行为。

在根据第一方面的客户端设备的实施方式中，客户端设备还用于

向应用发送建立通知。

该建立通知指示PDU会话准备在第一组QoS流中承载数据包流，并且该PDU会话与一组QoS要求匹配。

该实施方式的优点是，当PDU会话和QoS流已建立并且匹配QoS要求时，当客户端设备和UPF应用了数据包流到第一组QoS流的映射并准备开始发送和接收数据包流时，应用获得通知。

在根据第一方面的客户端设备的实施方式中，客户端设备还用于

当第一组QoS流不满足该组QoS要求时，获得接入网AN性能测量和回程性能测量；

基于AN性能测量和回程性能测量，检验第一通信链路和至少一个第二通信链路上的可用聚合资源是否能够实现该组QoS要求；

当可用聚合资源能够满足该组QoS要求时，向应用发送映射请求，其中，该映射请求包括AN性能测量和回程性能测量。

聚合资源是指两个或两个以上的通信链路上的网络资源(例如带宽和误包率)，这些资源可以用于通过在多个通信链路上发送包来增加可用带宽，或者通过将包复制在多个通信链路上以实现冗余机制来降低误包率。由于默认的5G QoS框架允许将一个QoS流映射到一个通信链路，因此如果没有本解决方案，这是不可能实现的。

该实施方式的优点是，当由于在单个通信路径上的QoS流上无法实现请求的QoS，5G QoS框架无法向终端用户提供请求的QoS(例如非常大的保证流比特率(GFBR)或较低的误包率(packet error rate，PER))时，本协议(5GUP)提供了一种解决方案，使得能够聚合多个可用通信路径的网络资源，并按照应用的指定，在这些路径上提供QoS流，以满足与数据包流相关的请求的QoS。客户端设备获得并开放可用通信路径的AN性能测量和回程性能测量，并检验是否可以通过聚合多个路径的网络资源来提供请求的QoS(例如，通过将较大的数据包流分流至多个通信链路中的QoS流以实现所需的GFBR，或者通过将数据包流中的包复制在多个QoS流上以实现较低的PER)。这要求应用在向该应用开放了网络路径性能信息之后，指定如何执行数据包流到可用通信路径上的QoS流的映射。

在根据第一方面的客户端设备的实施方式中，客户端设备还用于

从网络控制节点接收未实现通知，其中，未实现通知指示第一组QoS流中的至少一个QoS流不再能够满足该组QoS要求中的至少一个QoS要求；

获得AN性能测量和回程性能测量；

响应于接收到未实现通知，向应用发送映射请求，其中，映射请求包括未实现通知、AN性能测量、以及回程性能测量。

该实施方式的优点是，当可用QoS变化时(由于无线接入网的条件的变化，一个或多个QoS流不再能够实现)，应用获得关于QoS以及可用路径的当前网络条件的这些变化的通知，并因此被要求提供数据包流到多个通信路径上的QoS流的新映射。如果没有此实施方式，移动应用就不知道QoS变化并且无法通过指定其希望如何使用移动链路来实现请求的QoS特性来动态地适应新的网络和QoS条件。

在根据第一方面的客户端设备的实施方式中，客户端设备还用于

从应用接收第二应用请求，其中，第二应用请求指示修改建立的PDU会话；

获得AN性能测量和回程性能测量；

响应于接收到第二应用请求，向应用发送映射请求，其中，映射请求包括AN性能测量和回程性能测量

该实施方式的优点是，应用能够在建立PDU会话的同时随时向客户端设备发送修改PDU会话的请求，并被要求基于可用通信路径的提供的当前网络条件来指定数据包流到QoS流的新映射，以更好地匹配应用要求。该应用比网络更了解其希望如何使用可用的网络资源，因此最适合由应用请求网络相应地修改映射。

在根据第一方面的客户端设备的实施方式中，客户端设备还用于

从应用接收数据包流到第二组QoS流的映射；

基于接收的映射向网络控制节点发送修改建立的PDU会话的请求，使得修改的PDU会话承载用于数据包流的第二组QoS流；

经由第一通信链路和至少一个第二通信链路在修改的PDU会话上承载的第二组QoS流中向UPF发送数据包流。

该实施方式的优点是客户端设备可以向网络控制节点发送PDU会话修改请求，以承载用于数据包流(在从应用接收的映射中指定)的第二组QoS流。一旦PDU会话被修改，客户端设备就可以在可用通信路径上的第二组QoS流中向UPF发送数据包流。在该实施方式之前，客户端设备从未向应用要求其需要使用移动链路来实现其业务流所请求的QoS特性，这将触发向网络控制节点发送PDU会话修改请求。

在根据第一方面的客户端设备的实施方式中，客户端设备还用于

从网络控制节点接收实现通知，其中，实现通知指示先前已接收到未实现通知的第一组QoS流中的至少一个QoS流能够满足该组QoS要求中的至少一个QoS要求；

向应用发送实现通知接收；以及

当在修改建立的PDU会话之前接收到实现通知时

请求应用删除用于修改建立的PDU会话的映射，并且使用用于建立的PDU会话的先前映射。

该实施方式的优点是，如果在PDU会话被修改之前(该过程由接收到QoS未实现通知的客户端设备触发)，客户端设备接收到移动网络再次能够满足QoS要求的QoS实现通知，则客户端设备将此通知应用，并请求应用删除用于修改建立的PDU会话的映射并恢复用于建立的PDU会话的先前映射。这使得移动应用能够实时了解可用无线链路的条件，并及时适应这种变化，这在之前从未实现过。

在根据第一方面的客户端设备的实施方式中，客户端设备还用于

向应用发送修改通知。

该实施方式的优点是，当建立的PDU会话被修改，并准备在与该组QoS要求匹配的第二组QoS流中承载数据包流时，应用获得通知，以便应用可以开始向数据网络发送数据包流并从数据网络接收数据包流。

在根据第一方面的客户端设备的实施方式中，映射数据包流包括

将数据包流分流到两个或两个以上的单独的QoS流中，其中，每个QoS流建立在不同的通信链路上，

将多个数据包流聚合到选定的通信链路上的单个QoS流中，

将数据包流匹配到选定的通信链路上的QoS流，以及

将数据包流中的数据包复制到多个QoS流中，其中，每个QoS流建立在不同的通信链路上。

对于每个QoS流，其QoS特性将被定义为映射的一部分，可以请求网络控制节点建立这种定义的具有QoS特性的QoS流。

该实施方式的优点是，使得能够灵活地将数据包流映射到一个或一个以上可用通信路径上的QoS流，并且能够定义每个QoS流的QoS特性作为该映射的一部分，从而在无法在单个通信链路上向移动应用提供所需的QoS时，可以更有效地使用聚合网络资源并增强5GQoS模型。

在根据第一方面的客户端设备的实施方式中，客户端设备还用于

向UPF发送映射操作或映射操作的逆。

该实施方式的优点是，在发送该映射之后，客户端设备和UPF将能够在各自侧应用该映射，并相应地准备处理传入数据包流和传出数据包流，而未让5G核心网控制面知道该内部映射并仅在5GUP协议内存储该映射。UPF可以从客户端设备接收作为带内控制信息的一部分的数据包流在第二组QoS流上的映射，并自行执行该映射操作的逆，或者，UPF可以从客户端设备接收映射的逆(也作为带内控制信息的一部分)，并将该映射操作的逆应用于接收到的第二组QoS流，从而将这些QoS流转换为原始的数据包流。

在根据第一方面的客户端设备的实施方式中，客户端设备还用于

从应用接收第三应用请求，其中，该第三应用请求指示释放建立的PDU会话；

基于第三应用请求向网络控制节点发送释放建立的PDU会话的请求，使得释放建立的PDU会话；

向应用发送释放通知。

该实施方式的优点是，当建立的PDU会话被释放且相关的一组QoS流和映射操作已从客户端设备和UPF中删除时，应用获得通知。

根据本发明的第二方面，上述目的和其他目的可以通过用于移动通信系统的网络控制节点来实现，该网络控制节点用于

获得与由客户端设备建立并由UPF服务的PDU会话中承载的至少一个QoS流相关的未实现通知，其中，未实现通知指示至少一个QoS流的QoS实现的变化；或

获得与由客户端设备建立并由UPF服务的PDU会话中承载的至少一个QoS流相关的实现通知，其中，实现通知指示至少一个QoS流的QoS未实现的变化；

向客户端设备发送实现通知或未实现通知。

实现通知和未实现通知属于所谓的接入网通知控制，当前仅针对GBR类型的QoS流定义了接入网通知控制。实现通知和未实现通知可以经由驻留在5G网络中的在网络控制节点(SMF)和客户端设备之间的另一节点(称为接入和移动性功能(access and mobilityfunction，AMF))的参与发送至客户端设备。网络控制节点将实现通知或未实现通知发送至AMF，AMF创建包含实现通知或未实现通知中包括的部分或全部信息的新消息，并将该消息发送至客户端设备。

根据第二方面的网络控制节点的优点是，其通过动态和更有效地利用网络基础设施和可用带宽来提供较大的保证IP流比特率并满足其他的应用特定的QoS要求，例如较高的可靠性，从而增强了诸如5G的移动通信系统的QoS框架。由于应用知道如何实现所需的QoS/QoE，因此本发明的实施例将可用网络路径的性能信息和QoS实现有关的信息开放给应用，以动态调整QoS要求并将可用资源分配给应用的业务数据流。通过向应用开发人员开放可用路径的网络性能信息和QoS实现的变化并让应用根据应用特定的标准来定义如何为应用的业务分配资源，与传统解决方案相比，特别是对于新移动服务和垂直服务，可以使移动核心网和5G QoS框架在移动服务数据传输方面的使用增加并获利。

根据本发明的第三方面，上述目的和其他目的可以通过用于移动通信系统的UPF来实现，UPF用于

从客户端设备接收带内控制信息，其中，该带内控制信息与在客户端设备和UPF之间建立的PDU会话相关，其中，建立的PDU会话承载用于数据包流的第一组QoS流。

当建立第二组QoS流时，这同样有效。UPF从客户端设备接收带内控制信息，其中，带内控制信息与建立的PDU会话相关，该建立的PDU会话承载用于数据包流的第二组QoS流。

根据第三方面的UPF的优点是，其通过动态和更有效地利用网络基础设施和可用带宽来提供较大的保证IP流比特率并满足其他的应用特定的QoS要求，例如较高的可靠性，从而增强了诸如5G的移动通信系统的QoS框架。由于应用知道如何实现所需的QoS/QoE，因此本发明的实施例将可用网络路径的性能信息和QoS实现有关的信息开放给应用，以动态调整QoS要求并将可用资源分配给应用的业务数据流。通过向应用开发人员开放可用路径的网络性能信息和QoS实现的变化并让应用根据应用特定的标准来定义如何为应用的业务分配资源，与传统解决方案相比，特别是对于新移动服务和垂直服务，可以使移动核心网和5G QoS框架在移动服务数据传输方面的使用增加并获利。

在根据第三方面的UPF的实施方式中，UPF还用于以下至少之一

基于带内控制信息从客户端设备接收数据包流，其中，经由包括第一无线链路和第一回程链路的第一通信链路以及包括第二无线链路和第二回程链路的至少一个第二通信链路在建立的PDU会话上的第一组QoS流中接收数据包流；以及

基于带内控制信息向客户端设备发送数据包流，其中，经由第一通信链路和至少一个第二通信链路在建立的PDU会话上的第一组QoS流中发送数据包流。

当建立第二组QoS流时，这同样有效。UPF用于经由第一通信链路和至少一个第二通信链路，在建立的PDU会话上的第二组QoS流中从客户端设备接收数据包流或向客户端设备发送数据包流。

根据本发明的第四方面，上述目的和其他目的通过用于客户端设备的方法来实现，该方法包括

从应用接收第一应用请求，其中，该第一应用请求指示建立用于传输数据包流的分组数据单元PDU会话的请求；

接收与数据包流相关的一组服务质量QoS要求；

在接收到第一应用请求时，向网络控制节点发送建立PDU会话的请求，使得建立由用户面功能UPF服务的PDU会话，其中，建立的PDU会话承载用于数据包流的第一组QoS流；以及

当第一组QoS流满足一组QoS要求时，客户端设备用于

经由包括第一无线链路和第一回程链路的第一通信链路以及包括第二无线链路和第二回程链路的至少一个第二通信链路在建立的PDU会话上的第一组QoS流中向UPF发送数据包流。

根据第三方面的方法可以扩展为与根据第一方面的客户端设备的实施方式对应的实施方式。因此，该方法的实施方式包括客户端设备的相应实施方式的特征。

根据第三方面的方法的优点与根据第一方面的客户端设备的相应实施方式的优点相同。

根据本发明的第五方面，上述目的和其他目的通过用于网络控制节点的方法来实现，该方法包括

获得与由客户端设备建立并由UPF服务的PDU会话中承载的至少一个QoS流相关的未实现通知，其中，未实现通知指示至少一个QoS流的QoS实现的变化；或

获得与由客户端设备建立并由UPF服务的PDU会话中承载的至少一个QoS流相关的实现通知，其中，实现通知指示至少一个QoS流的QoS未实现的变化；

向客户端设备发送实现通知或未实现通知。

根据第五方面的方法可以扩展为与根据第二方面的网络控制节点的实施方式对应的实施方式。因此，该方法的实施方式包括网络控制节点的相应实施方式的特征。

根据第五方面的方法的优点与根据第二方面的网络控制节点的相应实施方式的优点相同。

根据本发明的第六方面，上述目的和其他目的通过用于UPF的方法来实现，该方法包括

从客户端设备接收带内控制信息，其中，带内控制信息与在客户端设备和UPF之间建立的PDU会话相关，其中，建立的PDU会话承载用于数据包流的第一组QoS流。

根据第六方面的方法可以扩展为与根据第三方面的UPF的实施方式对应的实施方式。因此，该方法的实施方式包括UPF的相应实施方式的特征。

根据第六方面的方法的优点与根据第三方面的UPF的相应实施方式的优点相同。

本发明还涉及一种计算机程序，其特征在于程序代码，当由至少一个处理器运行时，使得上述至少一个处理器执行根据本发明实施例的任一方法。此外，本发明还涉及一种计算机程序产品，该计算机程序产品包括计算机可读介质和上述计算机程序，其中计算机程序包括在计算机可读介质中，并且包括以下组中的一个或多个：只读存储器(read-onlymemory，ROM)、可编程ROM(programmable ROM，PROM)、可擦除PROM(erasable PROM，EPROM)、闪存、电子EPROM(electrically EPROM，EEPROM)、以及硬盘驱动器。

根据下面的具体实施方式，本发明实施例的其他应用和优点是显而易见的。

附图说明

附图旨在阐明和说明本发明的不同实施例，在附图中：

-图1示出了根据本发明示例的客户端设备；

-图2示出了根据本发明示例的用于客户端设备的方法；

-图3示出了根据本发明示例的网络控制节点；

-图4示出了根据本发明示例的用于网络控制节点的方法；

-图5示出了根据本发明示例的UPF；

-图6示出了根据本发明示例的用于UPF的方法；

-图7示出了根据本发明示例的移动通信系统；

-图8示出了根据本发明示例的提出的5GUP协议；

-图9示出了根据本发明示例的系统架构；

-图10示出了根据本发明示例的控制面架构；

-图11示出了根据本发明示例的用户面和控制栈；

-图12示出了根据本发明的示例的5GUP状态机；

-图13示出了根据本发明示例的信令图；

-图14示出了根据本发明示例的信令图；

-图15示出了根据本发明示例的信令图；

-图16示出了根据本发明示例的信令图。

具体实施方式

一般来说，5G多连接是指具有N个异构无线接入技术(radio access technology，RAT)节点的系统，这些节点向UE提供无线资源，且均通过N3隧道连接到单个UPF。除了5GC的MR-DC(其中，两个接入节点中只有一个接入节点具有到AMF的N2连接)这种情况以外，5G多连接中的所有其他接入节点具有自己的到AMF的N2连接。类似地，对于MR-DC，在UE和UPF之间的多个通信路径上建立的所有QoS流属于同一多连接PDU会话。

例如，当需要建立的QoS流的保证流比特率(GFBR)大于任何可用路径的可用带宽，但对于聚合网络带宽可行时，可能会出现问题。由于IP流1:1映射到QoS流，这使得无法将一部分QoS流映射到主RAN节点并将其余QoS流映射到辅RAN节点，或者无法将QoS流分流在异构接入节点上，因此MR-DC/5G多连接和5G QoS框架无法解决这种问题。在这种情况下，当无法通过单个无线接口和N3隧道路径实现给定QoS流的GFBR时，NG-RAN将向会话管理功能(session management function，SMF)发送关于GFBR未实现的RAN通知控制消息。RAN应保留QoS流并将尝试实现GFBR，而5GC可以发起N2信令以修改或删除QoS流。因此，客户端设备将被通知无法提供请求的QoS。在两个或两个以上的路径上可能存在足够的聚合带宽来提供所需的GFBR，但是当前的5G QoS框架并未提供此问题的解决方案。

另一个问题是，单个QoS流提供的可靠性低于应用要求(由于无线链路的不可预测性)。在这种情况下，可以通过在两个或两个以上的QoS流上进行包复制来实现较低的误包率(PER)。在任何情况下，都需要(基于当前网络条件)将具有QoS要求的IP流动态且更灵活地映射到MR-DC/多连接路径上的QoS流，以更有效地利用可用网络资源并实现用户所需的QoE/QoS。

还有一个问题是，当可用QoS变化时，UE应用不知道可用QoS的变化且无法动态地适应该变化。QoS模型定义了RAN通知控制，其中关于GFBR未实现的RAN通知传达给AMF和SMF，但未传达给UE。因此，UE应用不知道QoS流的任何请求的QoS特性是否实现。

5G QoS框架的当前粒度允许将UE的一个PDU会话的DL用户面业务分流至多个N3隧道中，即，将PDU会话的一些QoS流引导到朝主RAN节点的N3隧道，并将PDU会话的其余QoS流引导到朝辅RAN节点的N3隧道。如果IP流的比特率要求太大而无法适于单个无线连接或N3隧道，则QoS框架无法向移动用户提供请求的QoS/QoE。同样，如果由于无线链路的不可预测性，IP流的可靠性要求太高而无法通过在MR-DC/多连接路径中的一个路径上传输来实现，则现有的QoS框架不能向移动用户提供所需的QoS/QoE。

QoS流的RAN分流(称为具有到主RAN节点的单个N3终端的MR-DC)未考虑N3链路的QoS特性，仅基于RAN内的可用信息(在移动回程中也可能会出现瓶颈)。类似地，RAN协议、MAC、以及PDCP未考虑移动回程在多个链路上的业务分流中的性能。当在多个接入链路上建立MPTCP时，MPTCP的问题是其不知道底层链路的性能且是被动反应的，因此在链路质量差的情况下，这通常导致聚合吞吐量低于单个通信链路。

此外，ATSSS允许使用应用特定信息来定义业务分流策略。然而，定义ATSSS业务分流策略所需的应用特定信息是由AF提供的，因此这种解决方案不适用于没有AF来控制UE与数据网络的PDU会话或两个UE的跨数据网络的PDU会话的情况。另外，与提出的解决方案不同，ATSSS无法将QoS流分流至单个PDU会话内的多个通信链路上。并且，ATSSS也未使用来自RAN的通知控制消息来触发做出ATSSS业务路由相关的决策。最后，3GPP尚未确定：(a)业务分流的粒度(每SDF/每IP流/每数据包)，(b)UE和/或网络是否可以决定将数据流分流在3GPP接入和非3GPP接入上，或(c)如何使用从业务报告中导出的端到端业务性能视图来动态管理ATSSS行为。

由于上述原因，发明人针对先前讨论的传统解决方案的缺点仔细研究了不同的解决方案。发明人发现，传统解决方案未提供以下用户面协议：

·在UE和UPF上具有协议实体，并在用户面内实现带内控制信令。

·使用来自RAN的通知控制消息来信令通知需要IP流到QoS流的新映射，并且需要修改现有PDU会话以建立新的QoS流。相反，如果单个路径上的网络资源不足，RAN当前将尝试实现QoS目标，而核心网可以信令通知修改或删除QoS流并通知终端用户无法实现所需的QoS。

·使UE应用能够指定如何将当前网络资源分配给应用的业务流以满足应用特定需求。

·根据UE应用的定义，将IP流映射到多连接路径上的QoS流，并请求SMF在PDU会话中建立这些QoS流，从而更有效地利用聚合网络路径资源。

因此，本文提出了减轻或解决传统解决方案的缺点和问题的客户端设备、网络控制节点、以及UPF。

图1示出了根据本发明实施例的客户端设备100。在图1所示的实施例中，客户端设备100包括处理器102、收发器104、以及存储器106。处理器102通过本领域已知的通信器件108耦合到收发器104和存储器106。客户端设备100还包括耦合到收发器104的天线112，这意味着客户端设备100用于在无线通信系统中进行无线通信。

在本公开中，客户端设备100用于执行某些动作应理解为是指客户端设备100包括用于执行上述动作的合适的器件，例如处理器102和收发器104。此外，在图1的示例中，应用110在客户端设备110中运行。应用110可以在客户端设备100的处理器102中运行，但这未在图1中示出。然而，需要注意的是，应用110可以独立于客户端设备110在客户端设备110之外运行。在任何情况下，客户端设备100与应用110通信。

参照图1和图7，客户端设备100用于从应用110接收第一应用请求120。第一应用请求120指示建立用于传输数据包流的PDU会话的请求；接收与数据包流相关的一组QoS要求；在接收到第一应用请求120时，向网络控制节点300发送建立PDU会话的请求，使得建立由UPF 510服务的PDU会话。建立的PDU会话承载用于数据包流的第一组QoS流；当第一组QoS流满足该组QoS要求时，客户端设备100用于经由包括第一无线链路722(经由第一网络接入节点900a)和第一回程链路724的第一通信链路以及包括第二无线链路732(经由第二网络接入节点900b)和第二回程链路734的至少一个第二通信链路，在建立的PDU会话上的第一组QoS流中向UPF 510发送数据包流。UPF 510进而可以经由通信接口760与数据网络800通信，使得将来自客户端设备100的数据包流转发至数据网络800。可以存在一个以上的第二通信链路，但图7中仅示出了一个第二通信链路。此外，UPF 510还可以经由控制接口750与网络控制节点300通信。网络控制节点300经由控制接口750向UPF 510提供与每个提供的QoS流相关的SDF模板，UPF 510在DL中使用该模板将用户面业务映射到QoS流。此外，从客户端设备100发送至网络控制节点300的所有PDU会话管理请求都经由UPF 510通过此控制接口770发送至网络控制节点300，由网络控制节点300返回给客户端设备100的所有PDU会话管理响应都经由UPF 510通过此控制接口770从网络控制节点300发送。另外，网络控制节点300可以利用控制接口770与客户端设备100通信。然而，网络控制节点300和客户端设备100之间的通信通常经由一个或多个中间控制节点(例如AMF)来执行。AMF具有到网络控制节点300和客户端设备100的控制接口。通信过程如下执行：当网络控制节点300经由AMF从第一网络接入节点900a(在MR-DC的情况下)或经由AMF从第二网络接入节点900b(在多RAT或5G多连接的情况下也是可能的)接收到实现通知或未实现通知时，网络控制节点300将包含该通知中的部分或全部信息的新消息发送至AMF。AMF从该接收到的消息中获取有效载荷，将有效载荷插入另一消息，然后将该新消息发送至客户端设备100。网络控制节点300还将QoS规则发送至客户端设备100(以同样的方式，经由AMF)，客户端设备100使用该QoS规则来确定是否应修改PDU会话中的QoS流以及是否需要UL用户面业务和QoS流之间的新映射。

根据本发明的实施例，应用110可以如前所述在客户端设备100或另一客户端设备中运行。此外，可从应用110接收到该组QoS要求。然而，该组QoS要求也可以由其他网络实体(例如PCF或AF)发送。响应于建立的PDU会话，客户端设备100可以向应用110发送建立通知(图中未示出)，以便向应用通知PDU会话已建立。

图2示出了可以在诸如图1所示的客户端设备100中执行的相应方法200的流程图。方法200包括从应用110接收202第一应用请求120。第一应用请求120指示建立用于传输数据包流的PDU会话的请求；接收204与数据包流相关的一组QoS要求；在接收到第一应用请求120时，向网络控制节点300发送206建立PDU会话的请求，使得建立由UPF 510服务的PDU会话。建立的PDU会话承载用于数据包流的第一组QoS流；以及当第一组QoS流满足该组QoS要求时，客户端设备100用于经由包括第一无线链路722和第一回程链路724的第一通信链路以及包括第二无线链路732和第二回程链路734的至少一个第二通信链路，在建立的PDU会话上的第一组QoS流中向UPF 510发送208数据包流。

图3示出了根据本发明实施例的网络控制节点300。在图3所示的实施例中，网络控制节点300包括处理器302、收发器304、以及存储器306。处理器302通过本领域已知的通信器件308耦合到收发器304和存储器306。网络控制节点300用于在移动通信系统500中进行有线通信。有线通信能力提供有耦合到收发器304的有线通信接口312。在本公开中，网络控制节点300用于执行某些动作应理解为是指网络控制节点300包括用于执行上述动作的合适的器件，例如处理器302和收发器304。

参考图7，网络控制节点300用于：获得与由客户端设备100建立并由UPF 510服务的PDU会话中承载的至少一个QoS流相关的未实现通知，其中，未实现通知指示至少一个QoS流的QoS实现的变化；或获得与由客户端设备100建立并由UPF510服务的PDU会话中承载的至少一个QoS流相关的实现通知，其中，实现通知指示至少一个QoS流的QoS未实现的变化；经由AMF向客户端设备100发送实现通知或未实现通知。

图4示出了可以在诸如图3所示的网络接入节点300中执行的相应方法400的流程图。方法400包括获得402与由客户端设备100建立并由UPF 510服务的PDU会话中承载的至少一个QoS流相关的未实现通知，其中，未实现通知指示至少一个QoS流的QoS实现的变化；或获得404与由客户端设备100建立并由UPF 510服务的PDU会话中承载的至少一个QoS流相关的实现通知，其中，实现通知指示至少一个QoS流的QoS未实现的变化；向客户端设备100发送406实现通知或未实现通知。

图5示出了根据本发明实施例的UPF 510。在图5所示的实施例中，UPF 510包括处理器512、收发器514、以及存储器516。处理器512通过本领域已知的通信器件518耦合到收发器514和存储器516。UPF 510用于在移动通信系统500进行有线通信。有线通信能力提供有耦合到收发器514的有线通信接口522。在本公开中，UPF 510用于执行某些动作应理解为是指UPF 510包括用于执行上述动作的合适的器件，例如处理器512和收发器514。

参考图7，UPF 510用于通过至少一个通信链路从客户端设备100接收带内控制信息。该带内控制信息与在客户端设备100和UPF510之间建立的PDU会话相关。该建立的PDU会话承载用于数据包流的第一组QoS流。

图6示出了可以在诸如图5所示的UPF 510中执行的方法600的流程图。方法600包括：从客户端设备100接收602带内控制信息，该带内控制信息与在客户端设备100和UPF510之间建立的PDU会话相关。该建立的PDU会话承载用于数据包流的第一组QoS流。根据本发明的实施例，方法600还包括以下步骤：基于带内控制信息从客户端设备100接收604数据包流，其中，经由包括第一无线链路722和第一回程链路724的第一通信链路720以及包括第二无线链路732和第二回程链路734的至少一个第二通信链路730在建立的PDU会话上的第一组QoS流中接收数据包流；以及基于带内控制信息向客户端设备100发送606数据包流，其中，经由第一通信链路720和至少一个第二通信链路730在建立的PDU会话上的第一组QoS流中发送数据包流。

此外，本文提出了一种根据本发明实施例的使用带内控制信息的在本文中表示为5G用户面协议(5G user plane protocol，5GUP)的上层协议实体，其涉及客户端设备100、网络控制节点300、以及UPF 510。在客户端设备100中，5GUP负责根据应用110提供的指定映射集将从应用110接收的UL IP流映射到朝网络控制节点300和UPF 510之间的无线接口(例如，Uu空中接口/RAN节点)和N3接口的两种链路上的QoS流。客户端设备100中的5GUP还对DLQoS流应用映射的逆，以将DL QoS流恢复为原始IP流。在UPF 510中，5GUP负责根据应用110提供的映射将DL IP流映射到朝无线接口和N3接口的两种链路上的QoS流。UPF 510中的5GUP也对UL QoS流应用映射的逆，以将UL QoS流恢复为原始IP流。

因此，客户端设备100还可以用于经由第一通信链路720和至少一个第二通信链路730在建立的PDU会话上从UPF 510接收第一组QoS流中的数据包流。

如前所述，5GUP可以用在5G多连接中。然而，为了描述5GUP的协议栈，5GUP部署在具有如图8所示的5GC架构的MR-DC的顶部(Fehler！Verweisquelle konnte nichtgefunden werden.)。图8所示的用户面协议的缩写为：服务数据适配协议(service dataadaptation protocol，SDAP)、新空口分组数据汇聚协议(new radio packet dataconvergence protocol，NR-PDCP)、无线链路控制(radio link control，RLC)协议、媒体访问控制(medium access control，MAC)协议、GPRS隧道协议用户面(GPRS tunnellingprotocol user plane，GTP-U)、用户数据报协议(user datagram protocol，UDP)、互联网协议(internet protocol，IP)、层1(layer 1，L1)协议、以及层2(layer 2，L2)协议。针对客户端设备100请求的部分或全部PDU会话，主RAN节点向SMF请求5GC的MR-DC。因为UPF 510知道其需要建立两个N3终端(到MN和SN)，所以UPF 510知道PDU会话是MR-DC类型。假设客户端设备100中的5GUP协议实体可以从UPF 510获得该信息。5GUP还假设每QFI的DL/ULRAN测量和回程测量(例如，包时延、时延变化、IP吞吐量、以及丢包率)已提供，并且用于在客户端设备100和UPF 510中存储可由客户端设备100的5GUP协议实体和UPF 510的5GUP协议实体读取的值。因此，客户端设备100的5GUP协议实体和UPF 510的5GUP协议实体都知道可用的MR-DC路径及其当前网络条件。

客户端设备100侧的5GUP协议实体确保应用110可以随时(包括当QoS变化时)指定其希望如何分配QoS流。使用来自AN的关于GFBR实现的通知控制消息(例如RAN通知)和应用请求来信令通知需要IP流到QoS流的新映射。在接收到修改PDU会话的RAN通知或应用请求时，客户端设备100向应用110开放关于可用网络路径(例如无线链路和回程(N3)隧道)性能、GFBR实现、以及提供的QoS流的QoS变化的信息。基于上述信息，应用110可以确定并指定其希望如何为其业务流分配可用网络资源以实现所需的QoS/QoE目标。

5GUP可以使用图9中描绘和编号的映射，将应用110的IP流映射到至少两个路径上的UL/DL IP流(QoS流)：

1.将数据包流分流到两个或两个以上的单独的QoS流中，其中，每个QoS流建立在不同的通信链路上(图9中的CL 1和CL 2)，

2.将多个数据包流聚合到选定的通信链路上的单个QoS流中，

3.将数据包流匹配到选定的通信链路上的QoS流，以及

4.将数据包流中的数据包复制到多个QoS流中，其中，每个QoS流建立在不同的通信链路上。

5GUP在其协议实体中定义并安装了用于此类流操作的映射(即分流、复制、聚合、以及匹配)和包过滤器。可以在每个连接路径上分配一个QoS流，以进行带内信令和(可选)路径测量。当UL/DL包到达客户端设备100处的5GUP实体或UPF 510处的5GUP实体时，将这些UL/DL包与定义的包过滤器进行匹配，并调用匹配的5GUP操作。给定应用110指定的IP流到QoS流的映射，5GUP的控制部触发到网络控制节点300(5G标准中的SMF)的PDU会话修改请求，以在PDU会话内建立新的QoS流。

图10示出了协议架构的控制部，图11示出了客户端设备100的控制面(controlplane，CP)协议栈和用户面(user plane，UP)协议栈。客户端设备100处的5GUP协议实体通过例如MediaStream QoS应用编程接口(application programming interface，API)接收启动、修改、释放PDU会话及其QoS流的第一应用请求120和第二应用请求122，并与5G核心网控制面中的SMF进行交互以请求建立、修改、释放PDU会话以及请求的QoS流。客户端设备100处的5GUP协议实体经由AMF从SMF接收关于GFBR实现的RAN通知(即，QoS流的GFBR何时无法实现以及(适用时)何时可以再次实现)并通知应用110关于QoS实现的变化，以便应用可以确定是否要请求修改PDU会话中的QoS流。最后通过经由MediaStream QoS API来开放网络状态信息，5GUP使应用110能够例如：

·指定IP流的哪一部分将通过哪个N3隧道(和Uu空中接口/RAN节点)传输。

·指定请求建立在PDU会话中的QoS流的数量。

·为将请求网络控制节点300建立的每个QoS流定义QoS特性。控制5G QoS流的特定QoS转发行为的QoS参数(称为5G QoS标识符或5QI)包括：资源类型(例如GBR、时延关键GBR、或非GBR)、优先级、包时延预算、误包率、以及平均窗口(仅为GBR流定义)。除了5QI之外，5GUP协议还使用了当前仅为GBR类型的QoS流定义的通知控制。表征GBR(或时延关键GBR)QoS流的其他QoS参数例如是：分配和保留优先级(ARP)、GFBR、以及最大流比特率(MFBR)。

MediaStreamQoS API是由客户端设备100上的5GUP协议实体开放的双向API，应用110可以使用MediaStreamQoS API与客户端设备100进行交互。MediaStreamQoS API包括一组功能，使应用110能够例如：管理具有相关QoS要求的PDU会话，从而应用110能够指定其希望如何分配网络资源来满足应用的数据包流(IP业务流)的传输所需的QoS要求，或者如何基于新感知的网络条件修改应用的QoS要求；以及了解PDU会话的任何变化，这些变化可能影响在客户端设备感知的上述PDU会话的当前QoS要求，包括与建立的PDU会话的状态和QoS实现相关的事件，以及无线链路条件的变化。

当前的MediaStreamQoS API可以定义以下功能：

·MediaQoSRequest：该功能使应用110能够请求客户端设备100建立PDU会话，该PDU会话可以承载具有指定的一组QoS要求的描述的IP业务流：

-所需的输入：IP流描述、QoS要求。

-可选输入：无。

-所需的输出：无。

-可选输出：无。

·ModifyMediaQoS：该功能使应用110能够请求客户端设备100通过建立一组新的QoS流来修改建立的PDU会话，该组新的QoS流可以承载具有指定的一组QoS要求的描述的IP业务流：

-所需的输入：IP流描述、QoS要求。

-可选输入：无。

-所需的输出：无。

-可选输出：无。

·TerminateMediaQoS：该功能使应用110能够请求客户端设备100释放用于传输给定数据包流的建立的PDU会话，并从客户端设备100和UPF 510中删除相关的QoS流和映射操作：

-所需的输入：IP流。

-可选输入：QoS流。

-所需的输出：无。

-可选输出：无。

·Get-IP-QoSFlowsMapping：该功能使客户端设备100能够基于提供的多连接/MR-DC网络路径性能信息以及可选的来自RAN的未实现GFBR通知信息来请求应用110提供数据包流到一个或多个通信链路上的QoS流的映射：

-所需的输入：多连接/MR-DC通信路径的RAN性能测量、回程性能测量值。

-可选输入：来自RAN的GFBR未实现通知信息。

-所需的输出：无。

-可选输出：无。

·Proposed-IP-QoSFlowsMapping：该功能使应用110能够提供数据包流到一个或一个以上通信链路上的QoS流的特定映射，为客户端设备100将请求网络控制节点300建立的每个QoS流定义QoS特性，以及指定IP流的哪一部分将传输到哪个QoS流：

-所需的输入：每个通信链路的QoS流标识符和定义、每种类型的IP流(由五元组<源IP地址、源端口、目的IP地址、目的端口、协议>标识)到一个或多个QoS流的映射操作、以及要在选定的QoS流上传输的每个IP流的一部分。

-可选输入：无。

-所需的输出：无。

-可选输出：无。

·MediaQoSEstablished：该功能使客户端设备100能够向应用110发送建立通知，该建立通知指示PDU会话已建立并且准备在第一组QoS流上承载数据包流。通知还包括第一组QoS流与一组QoS要求匹配的指示，以便应用可以开始向数据网络发送数据包流和从数据网络接收数据包流，或者在相反的情况下，通知包括建立的PDU会话中的第一组QoS流与一组QoS要求不匹配的指示：

-所需的输入：QoS流。

-可选输入：无。

-所需的输出：无。

-可选输出：无。

·MediaQoSError：该功能使客户端设备100能够发送与以下任何操作相关的错误通知：

PDU会话未正确建立；PDU会话未正确修改；终止PDU会话时出错：

-所需的输入：PDU会话管理操作的结果。

-可选输入：无。

-所需的输出：无。

-可选输出：无。

·MediaQoSRestored：该功能使客户端设备100能够向应用110发送修改通知，该修改通知指示已经用第二QoS流修改了PDU会话，并且该PDU会话准备在与一组QoS要求匹配的第二组QoS流上承载数据包流，以便应用可以开始向数据网络发送数据包流和从数据网络接收数据包流：

-所需的输入：QoS流。

-可选输入：无。

-所需的输出：无。

-可选输出：无。

·MediaQoSTerminated：该功能使客户端设备100能够向应用110发送释放通知，该释放通知指示建立的PDU会话已释放，并已从客户端设备100和UPF 510中删除相关的一组QoS流和映射操作：

-所需的输入：QoS流。

-可选输入：无。

-所需的输出：无。

-可选输出：无。

上述功能使应用110能够定义IP流到QoS流的映射。客户端设备处的5GUP协议实体还执行以下用户面功能：

·从应用接收UL IP包，将给定数据包流映射到QoS流，将5GUP协议头添加至接收的包，并将5GUP分组数据单元(PDU)发送至其对等方(UPF处的5GUP协议实体)。

·在DL中从UPF处的5GUP协议实体接收5GUP PDU，删除5GUP协议头，并将QoS流映射回IP流(由应用接收)。

除了按照用户面协议操作外，客户端设备100侧的5GUP协议实体还实现一些控制面功能，例如：

·向SMF发送具有QoS流的PDU会话管理请求(并接收响应)。

·经由AMF从网络控制节点300接收RAN通知。因此，5GUP协议实体出现在图11的UE的用户面(UP)协议栈和控制面(CP)协议栈中。

图11还示出客户端设备100处的5GUP协议实体与应用110交互。更具体地，客户端设备100处的5GUP协议实体接收建立、修改、或释放PDU会话的应用110请求，向应用110通知关于QoS实现的变化，以及向应用110请求并从应用110接收数据包流的映射。

5GUP协议实体实现了包括以下四种状态的有限状态机(finite state machine，FSM)：空闲、建立中、已建立、以及释放中(如图12的FSM所示)。对于每个5GUP会话，5GUP实现维护状态变量，该状态变量跟踪5GUP会话处于以下四种状态中的哪种状态：

·第一种状态为“空闲”状态。在“空闲”状态下，5GUP初始化所有资源，向网络控制节点300发送建立多连接PDU会话的请求，当PDU会话建立时，5GUP将其状态更改为“建立中”。在“空闲”状态下，5GUP会话尚未创建，如果FSM中的任何一个状态出错，则5GUP会话终止并返回到“空闲”状态。

·在“建立中”状态下，5GUP发起5GUP会话的创建，暂停UL/DL包的发送，检验应用110的QoS要求是否能够由PDU会话的建立的QoS流满足，提取客户端设备100和UPF 510上的性能测量值，并从应用110获取IP流到QoS流的映射，以将该映射转换为5GUP操作。在对客户端设备100侧和UPF 510侧应用5GUP操作并从对等协议实体接收到5GUP会话已建立的确认之后，5GUP将其状态更改为“已建立”。

·当5GUP进入“已建立”状态时，5GUP开始/恢复发送UL/DL包并向应用110发送关于建立/修改的PDU会话和QoS流的通知。如果5GUP接收到对修改PDU会话的应用110请求或RAN通知(作为需要更改IP流到QoS流的映射的信号)，则5GUP可以从“已建立”状态变回“建立中”状态。或者，当5GUP接收到对释放5GUP会话的应用110请求时，5GUP可以将状态从“已建立”更改为“释放中”。

·当进入“释放中”状态时，5GUP发起5GUP会话和PDU会话的释放，删除客户端设备100侧和UPF 510侧的所有5GUP操作，并停止UL/DL包调度。

图13至图16示出了根据本发明实施例的PDU和5GUP会话管理的详细序列图。图13至图16中的示例和场景建立在5G 3GPP背景下，因此使用了传统的3GPP术语，例如，UE表示客户端设备100，SMF表示网络控制节点300，RAN表示AN等。此外，还引入了其他实体，例如主gNB和AMF，以便在此特定背景下提供对本发明的更全面的理解。此外，使用3GPP标准中定义的协议消息类型。但是，本发明的实施例不限于此。

图13示出了一种场景，其中，应用110向UE5GUP协议实体发送向给定IP流提供特定QoS支持的请求，并且UE5GUP协议实体利用IP流到QoS的流的映射(在5G核心网控制面中由SMF提供并由PCF确定)建立5GUP会话。在此场景中，PCF提供的QoS流(每个QoS流建立在其中一个可用通信路径上)恰好与应用110的QoS要求匹配。

图13中的步骤1：从应用110到UE5GUP协议实体：发送5GUP MediaQoSRequest(包括IP流描述和QoS要求)。应用110向UE 1005GUP协议实体发送对建立PDU会话的第一应用请求120，该PDU会话用于传输具有指定的一组QoS要求的给定IP业务流。

图13中的步骤2：从UE5GUP协议实体到SMF(经由AMF)：发送NAS创建(MR-DC)PDU会话建立请求和PDU会话建立过程。当从应用110接收到5GUP MediaQoSRequest时，UE 5GUP协议实体进入“空闲”状态，并通过SM NAS消息触发多连接(在本示例中为MR-DC)PDU会话建立。AMF将SM NAS消息转发给SMF。在TS 23.502中规定了建立PDU会话的过程，并且此过程需要在UE 100 5GUP协议实体和UPF 510 5GUP协议实体之间建立通信路径。在建立MR-DC PDU会话时，MN还请求添加SN，并可以请求将一些QFI分配给SN。这种多连接PDU会话的建立是5GUP协议要求的，这还假设在此步骤之后，在可用路径上建立了RAN测量和回程测量，并不断将这些测量的相关值存储在UE 100和UPF 510上。

图13中的步骤3：从SMF到AMF：发送Namf_Communication_N1N2MessageTransferPDU会话建立请求。SMF向AMF发送PDU会话已成功建立的确认，其中包含提供的QoS流的列表。这些QoS流不一定与应用110指定的QoS流相同，但与PCF提供的QoS流相同。

图13中的步骤4：此时，PDU会话已经建立，首先发送上行数据和下行数据，之后，UE100 5GUP协议实体进入“建立中”状态。

图13中的步骤5：UE 100 5GUP协议实体检验新建立的QoS流是否能够提供应用请求的QoS。验证的结果可能是以下三个方面：

(a)新提供的QoS流可以提供请求的QoS，这种情况在图13中示出且在本文中说明。

(b)新提供的QoS流无法提供请求的QoS，在这种情况下，UE 5GUP协议实体将采集网络路径性能测量(例如RAN性能测量和回程性能测量)，并估计是否有足够的聚合网络资源来提供请求的QoS。如果有足够的聚合网络资源来提供请求的QoS，则UE 1005GUP协议实体将向应用110开放这些路径的性能，以询问应用110希望如何将IP流分配到可用MR-DC路径上的QoS流。接下来，UE 5GUP协议实体利用应用指定的IP流到QoS流的映射建立5GUP会话，并相应地向SMF发送修改PDU会话的请求，如图14所示。

(c)否则，如果UE 100 5GUP协议实体确定没有足够的聚合资源来实现应用请求的QoS，或SMF拒绝具有应用指定的QoS流的PDU修改请求，则UE 100 5GUP协议实体将使用默认的IP流到QoS流的映射(在MR-DC PDU会话建立过程中决定)来建立5GUP会话，并通知应用110。

图13中的步骤6：从UE 100 5GUP协议实体到UPF 510 5GUP协议实体：发送5GUP创建5GUP会话请求(例如，包括会话Id、IP流描述、QoS要求)。UE 100 5GUP协议实体发送具有默认IP流到QoS流的映射(由SMF发送)的带内5GUP会话请求，并将该带内5GUP会话请求发送至UPF 510 5GUP协议实体。

图13中的步骤7：当UPF 510 5GUP协议实体接收到该请求时，UPF 510 5GUP协议实体进入“空闲”状态，然后立即进入“建立中”状态，并应用PDU会话的映射和默认5GUP操作。因此，UPF 510从UE 100接收与PDU会话相关的带内控制信息。

图13中的步骤8：从UPF 510 5GUP协议实体到UE 100 5GUP协议实体：发送5GUP创建5GUP会话确认(包括会话Id)。UPF 510 5GUP协议实体向UE 100 5GUP协议实体确认成功创建5GUP会话。

图13中的步骤9：在接收到该确认时，UE 100 5GUP协议实体还应用PDU会话映射和5GUP操作，并转到“已建立”状态。

图13中的步骤10：从UE 100 5GUP协议实体到UPF 510 5GUP协议实体：发送已建立的5GUP会话(会话Id)。UE 100通知UPF 510已建立5GUP会话。

图13中的步骤11：UE 100上的5GUP协议实体和UPF 510上的5GUP协议实体并行执行以下操作：

·UE 100 5GUP协议实体开始发送UL包。UPF基于带内控制信息从UE 100接收UL包。

·UPF 510 5GUP协议实体转到“已建立”状态，并基于带内控制信息开始发送DL包。

图13中的步骤12：UE 100 5GUP协议实体通过向应用110发送建立通知来通知应用110PDU会话已经建立。

图14示出了创建5GUP会话的替代序列图，其中，通过默认PDU会话建立提供的QoS流无法提供请求的QoS，但可用的多连接路径上有足够的聚合网络资源来提供请求的QoS(如上一图中UE 100 5GUP协议实体验证的5b结果所述)。图14中的前5个步骤与图13所示的序列图相同。从客户端设备的角度来看，该实施例的基本步骤涉及：当第一组QoS流不满足第一组QoS要求时，获得AN性能测量和回程性能测量；基于AN性能测量和回程性能测量，检验第一通信链路720和至少一个第二通信链路730上的可用聚合资源是否能够实现该组QoS要求；当可用聚合资源能够实现第一组QoS要求时，向应用110发送映射请求。该映射请求包括AN性能测量和回程性能测量。响应于映射请求，客户端设备100：从应用110接收数据包流到第二组QoS流的映射；基于接收的映射向网络控制节点300发送修改建立的PDU会话的请求，以使修改的PDU会话承载用于数据包流的第二组QoS流；并经由第一通信链路720和至少一个第二通信链路730在修改的PDU会话上承载的第二组QoS流中向UPF 510发送数据包流。

图14中的步骤1：从应用110到UE 1005GUP协议实体：发送5GUP MediaQoSRequest(包括IP流描述、QoS要求)。应用110发送建立PDU会话的第一应用请求，该PDU会话用于传输具有指定QoS要求的给定IP业务流。

图14中的步骤2：从UE 100 5GUP协议实体到SMF(经由AMF)：发送NAS创建(MR-DC)PDU会话建立请求(和PDU会话建立过程)。当从应用110接收到5GUP MediaQoSRequest时，UE100 5GUP协议实体进入“空闲”状态，并通过SM NAS消息触发多连接(在本示例中为MR-DC)PDU会话建立。AMF将SM NAS消息转发给SMF。在TS 23.502中规定了建立PDU会话的过程，并且此过程需要在UE 1005GUP协议实体和UPF 5105GUP协议实体之间建立通信路径。在建立MR-DC PDU会话时，MN还请求添加SN，并可以请求将一些QFI分配给SN。这种多连接PDU会话的建立是5GUP协议要求的，这还假设在此步骤之后，在可用路径上建立了RAN测量和回程测量，并不断将这些测量的相关值存储在UE 100和UPF510上。

图14中的步骤3：从SMF到AMF：发送Namf_Communication_N1N2MessageTransfer(即，PDU会话建立请求)。SMF向AMF发送PDU会话已成功建立的确认，其中包含提供的QoS流的列表。

图14中的步骤4：此时，PDU会话已经建立，首先发送上行数据和下行数据，之后，UE100 5GUP协议实体进入“建立中”状态。

图14中的步骤5：UE 100 5GUP协议实体检验新建立的QoS流是否能够提供应用请求的QoS，并确定默认PDU会话建立无法提供请求的QoS。

图14中的步骤6：从UE 100 5GUP协议实体到UPF 510 5GUP协议实体：发送5GUP创建5GUP会话请求(包括会话Id、IP流描述、QoS要求)。UE 100 5GUP协议实体向UPF 5105GUP协议实体发送支持具有特定QoS特性的IP流的请求。

图14中的步骤7：UPF 510 5GUP协议实体首先进入“空闲”状态，然后立即进入“建立中”状态，并提取回程性能测量值。

图14中的步骤8：从UPF 510 5GUP协议实体到UE 100 5GUP协议实体：发送5GUP创建5GUP会话确认(包括会话Id、回程性能测量值)。UPF 510 5GUP协议实体确认5GUP会话请求，将回程性能测量值插入该消息。

图14中的步骤9：在接收到具有回程性能测量值的确认之后，UE 100 5GUP协议实体提取RAN性能测量值。基于获得的RAN性能测量和回程性能测量，UE 1005GUP协议实体确定可用的多连接路径上有足够的聚合网络资源来提供请求的QoS。

图14中的步骤10：从UE 100 5GUP协议实体到应用110：5GUP获得IP流映射(RAN性能测量、回程性能测量值)。UE 100 5GUP协议实体向应用110开放MR-DC路径的RAN性能测量和回程性能测量，以要求应用110指定这些路径上的IP流到QoS流映射。

图14中的步骤11：从应用110到UE 100 5GUP协议实体：发送5GUP建议的IP流到QoS流的映射(5GUP proposed IP-QoS flows mapping)。应用110向UE 100 5GUP协议实体建议IP流到QoS流的映射，UE 100 5GUP协议实体将这些映射中的每个映射转换为5GUP操作(例如分流、合并、映射、以及复制)。

图14中的步骤12：从UE 100 5GUP协议实体到SMF：发送NAS修改PDU会话请求(具有指定的QoS流)。UE 100 5GUP协议实体(经由UPF 510 5GUP协议实体)向SMF发送请求，以修改PDU会话并建立映射中指定的新QoS流。PDU会话修改过程按照TS 23.502中的规定执行。在PDU会话成功修改之后，UE 100 5GUP协议实体从“建立中”状态返回“已建立”状态。

图14中的步骤13：从SMF到AMF：发送Nsmf_PDUsession_UpdateSMContext(包括PDU会话修改命令)。SMF向AMF发送PDU会话修改命令，该命令包含AMF应转发给UE100 5GUP协议实体的提供的QoS流的列表。

图14中的步骤14：从AMF到UE 100 5GUP协议实体：发送NAS PDU会话修改命令(QoS流)。AMF将PDU会话修改命令转发给UE 100 5GUP协议实体。

图14中的步骤15：从UE 100 5GUP协议实体到UPF 510 5GUP协议实体：发送5GUP建议的IP流到QoS流的映射(包括会话Id、5GUP操作)。UE 100 5GUP协议实体将5GUP操作作为带内控制信息的一部分发送至UPF 510 5GUP协议实体，以对实际发送/接收的IP包实施。这些操作可以包括映射操作或映射操作的逆。

图14中的步骤16：UPF 510 5GUP协议实体对发送/接收的IP包应用接收的5GUP操作。

图14中的步骤17：从UPF 510 5GUP协议实体到UE 100 5GUP协议实体：发送应用的5GUP建议的IP流到QoS流的映射。UPF 510 5GUP协议实体通知UE 100 5GUP协议实体UPF510 5GUP协议实体已应用接收的IP流到QoS流的映射。

图14中的步骤18：UE 100 5GUP协议实体应用提供的5GUP操作。

图14中的步骤19：从UE 100 5GUP协议实体到UPF 510 5GUP协议实体：发送建立的5GUP会话(包括会话Id)。UE 100 5GUP协议实体通知UPF 510 5GUP协议实体5GUP会话已成功建立。

图14中的步骤20：UE 100上的5GUP协议实体和UPF 510上的5GUP协议实体并行执行以下操作：

·UE 100 5GUP协议实体开始发送UL包。

·UPF 510 5GUP协议实体转到“已建立”状态并开始发送DL包。

图14中的步骤21：从UE 100 5GUP协议实体到应用110：发送5GUPMediaQosEstablisted(包括QoS流)。UE 100 5GUP协议实体通过向应用110发送建立通知来通知应用110具有请求的QoS流的PDU会话已建立。

一旦5GUP会话成功建立，就可以由第二应用请求122(如果应用要修改应用的业务流的QoS要求或提供不同的映射)触发修改建立PDU会话的请求，或通过接收关于GFBR(未)实现的RAN通知来触发修改建立PDU会话的请求。后一种情况如图15所示。从客户端设备的角度来看，该实施例的基本步骤涉及以下之一：

·(例如经由AMF)从网络控制节点300接收未实现通知。未实现通知指示第一组QoS流中的至少一个QoS流不再能够满足第一组QoS要求中的至少一个QoS要求；获得AN性能测量和回程性能测量；响应于接收到未实现通知，向应用110发送映射请求。映射请求包括未实现通知、AN性能测量、以及回程性能测量。

·如果客户端设备100接收到未实现通知，则(例如经由AMF)从网络控制节点300接收实现通知。实现通知指示先前已接收到未实现通知的第一组QoS流中的至少一个QoS流能够满足第一组QoS要求中的至少一个QoS要求；向应用110发送实现通知接收；当在修改建立的PDU会话之前接收到实现通知时，请求应用110删除用于修改建立的PDU会话的映射，并且使用用于建立的PDU会话的先前映射。

·从应用110接收第二应用请求122。第二应用请求122指示修改建立的PDU会话；获得AN性能测量和回程性能测量；响应于接收到第二应用请求122，向应用110发送映射请求。映射请求包括AN性能测量和回程性能测量。

响应于映射请求，客户端设备100：从应用110接收数据包流到第二组QoS流的映射；基于接收的映射向网络控制节点300发送修改建立的PDU会话的请求，使得修改的PDU会话承载用于数据包流的第二组QoS流；并经由第一通信链路720和至少一个第二通信链路730在修改的PDU会话上承载的第二组QoS流中向UPF 510发送数据包流。

图15中的步骤1：从主RAN节点到AMF：发送N2 RAN通知。当不再能够实现GBR QoS流时，主RAN节点向AMF发送N2 RAN通知。该未实现通知指示至少一个QoS流不再能够满足至少一个QoS要求。

图15中的步骤2：从AMF到SMF：发送Nsmf_PDUSession_UpdateSMContext请求(包括N2 RAN通知)。AMF通过调用Nsmf_PDUSession_UpdateSMContext(包括N2 RAN通知)将RAN通知转发给SMF。

图15中的步骤3：从SMF到AMF：发送Nsmf_PDUSession_UpdateSMContext响应(包括N1：RAN通知)。建议如下扩展3GPP标准：通过将RAN通知从SMF(经由AMF)转发给UE 100以通知应用110关于QoS的变化，并使应用110能够通过指定IP流到QoS流的新映射来适应QoS的变化。SMF通过Nsmf_PDUSession_UpdateSMContext响应(包括N1：RAN通知)来响应AMF，该响应承载了AMF应提供给UE 100的RAN通知。

图15中的步骤4：从AMF到UE 100：发送N1 RAN通知。AMF将RAN通知转发给UE 100。因此，UE从SMF接收到未实现通知。

图15中的步骤5：从UE 100 5GUP协议实体到UPF 510协议实体：发送5GUP修改5GUP会话请求(包括会话Id、RAN通知)。在接收到RAN通知之后，UE 100 5GUP协议实体从“已建立”状态转变到“建立中”状态，并将修改5GUP会话的带内请求发送至UPF 510 5GUP协议实体，该带内请求包含RAN通知中的部分或全部信息。

图15中的步骤6：UPF 510 5GUP协议实体接收带内5GUP会话修改请求，在接收到带内5GUP会话修改请求后，UPF 510 5GUP协议实体转变到“建立中”状态，并暂停发送DL包，直到会话再次恢复。因此，从UE 100接收带内控制信息。

图15中的步骤7：UPF 510 5GUP协议实体提取UPF 510和RAN之间的回程的性能测量值。

图15中的步骤8：从UPF 510 5GUP协议实体到UE 100 5GUP协议实体：发送5GUP修改5GUP会话确认(包括会话Id、回程性能测量值)。UPF 510 5GUP协议实体向UE 100 5GUP协议实体确认5GUP会话修改请求，并且还在该确认消息中发送回程性能测量值。

图15中的步骤9：在接收到确认之后，UE 100 5GUP协议实体提取RAN性能测量值。

图15中的步骤10：从UE 100 5GUP协议实体到应用110：发送5GUP获得IP-QoS流映射(包括GFBR未实现、RAN PM、回程PM值)。UE 100 5GUP协议实体向应用110开放来自RAN的GFBR未实现通知信息、多连接(在本示例中为MR-DC)路径的RAN性能测量和回程性能测量，以要求应用110指定IP流到这些路径上的QoS流的映射。

图15中的步骤11：从应用110到UE 100 5GUP协议实体：发送5GUP建议的IP流到QoS流的映射。应用110将建议的IP流到QoS流的映射发送至UE 100 5GUP协议实体，UE100 5GUP协议实体将这些映射转换为5GUP操作(例如分流、合并、映射、以及复制)。UE100从应用110接收数据包到第二组QoS流的映射。

图15中的步骤12：从UE 100 5GUP协议实体到SMF：发送NAS修改PDU会话请求(具有指定的QoS流)。UE 100 5GUP协议实体基于接收的映射(经由UPF 510 5GUP协议实体)向SMF发送请求，以修改建立的多连接(在本示例中为MR-DC)PDU会话以及建立新的QoS流，使得修改的PDU会话承载用于数据包流的第二组QoS流。PDU会话修改过程按照TS 23.502中的规定执行。在PDU会话成功修改之后，UE 100 5GUP协议实体从“建立中”状态返回“已建立”状态。

图15中的步骤13：从SMF到AMF：发送Nsmf_PDUsession_UpdateSMContext(包括PDU会话修改命令)。SMF向AMF发送PDU会话修改命令，该命令包含AMF应转发给UE100 5GUP协议实体的提供的QoS流的列表。

图15中的步骤14：从AMF到UE 100 5GUP协议实体：发送NAS PDU会话修改命令(QoS流)。AMF将PDU会话修改命令转发给UE 100 5GUP协议实体。

图15中的步骤15：从UE 100 5GUP协议实体到UPF 510 5GUP协议实体：发送5GUP建议的IP流到QoS流的映射(包括会话Id、5GUP操作)。UE 100 5GUP协议实体向UPF 5105GUP协议实体发送5GUP操作，以对实际发送/接收的IP数据包实施。

图15中的步骤16：UPF 510 5GUP协议实体对发送/接收的IP包应用接收的5GUP操作。

图15中的步骤17：从UPF 510 5GUP协议实体到UE 100 5GUP协议实体：发送应用的5GUP建议的IP流到QoS流的映射。UPF 510 5GUP协议实体通知UE 100 5GUP协议实体UPF510 5GUP协议实体已应用接收的IP流到QoS流的映射。

图15中的步骤18：UE 100 5GUP协议实体也应用这些5GUP操作。

图15中的步骤19：从UE 100 5GUP协议实体到UPF 510 5GUP协议实体：发送修改的5GUP会话(包括会话Id)。UE 100 5GUP协议实体通知UPF 510 5GUP协议实体5GUP会话已成功修改。

图15中的步骤20：UE 100上的5GUP协议实体和UPF 510上的5GUP协议实体并行执行以下操作：

·UE 100 5GUP协议实体恢复发送UL包。

·UPF 510 5GUP协议实体转到“已建立”状态并恢复发送DL包。

图15中的步骤21：从UE 100 5GUP协议实体到应用110：发送5GUPMediaQoSRestored(包括QoS流)。UE 100 5GUP协议实体通过向应用110发送修改通知来通知应用110已根据应用110建议的映射修改了具有请求的QoS流的PDU会话。

图16示出了当应用110要终止5GUP会话时释放5GUP会话的调用流程。从客户端设备的角度来看，该实施例的基本步骤涉及：从应用110接收第三应用请求124。第三应用请求124指示释放建立的PDU会话；基于第三应用请求124向网络控制节点300发送释放建立的PDU会话的请求，使得释放建立的PDU会话；向应用110发送释放通知。

图16中的步骤1：从应用110到UE 100 5GUP协议实体：发送5GUPTerminateMediaQoS(包括IP流)。当应用110要终止5GUP会话并释放其QoS要求时，应用110向UE 100 5GUP协议实体发送TerminateMediaQoS请求。换句话说，UE 100 5GUP协议实体从应用110接收第三应用请求。第三应用请求指示释放建立的PDU会话。

图16中的步骤2：从UE 100 5GUP协议实体到UPF 510 5GUP协议实体：发送5GUP释放5GUP会话请求(包括会话Id)。在接收到该请求时，UE 100 5GUP协议实体从“已建立”状态转变到“释放中”状态，并向UPF 510 5GUP协议实体发送释放5GUP会话的带内请求。

图16中的步骤3：从UE 100 5GUP协议实体到UPF 510 5GUP协议实体：发送5GUP释放5GUP会话确认(包括会话Id)。在接收到带内释放5GUP会话请求之后，UPF 510 5GUP协议实体也从“已建立”状态转变到“释放中”状态，并将确认响应发送回UE 100 5GUP协议实体。

图16中的步骤4：UE 100上的5GUP协议实体和UPF 510上的5GUP协议实体并行执行以下操作：

·UE 100 5GUP协议实体停止发送UL包。

·UPF 510 5GUP协议实体也停止发送DL包。

图16中的步骤5：UPF 510 5GUP协议实体删除5GUP操作。

图16中的步骤6：从UPF 510 5GUP协议实体到UE 100 5GUP协议实体：发送5GUP操作删除。UPF 510 5GUP协议实体向UE 100 5GUP协议实体发送已删除5GUP操作的带内通知。

图16中的步骤7：在接收到该带内通知时，UE 100 5GUP协议实体也删除所有5GUP操作。

图16中的步骤8：从UE 100 5GUP协议实体到SMF：发送NAS释放(MR-DC)PDU会话请求。UE 100 5GUP协议实体向SMF(经由UPF 510 5GUP协议实体)发送请求，以释放多连接(在本示例中为MR-DC)PDU会话及其所有分配的QoS流。整个过程在TS 23.502中示出。

图16中的步骤9：从SMF到AMF：发送Nsmf_PDU session_UpdateSMContext(包括PDU会话释放命令)。SMF向AMF发送AMF应转发给UE 100 5GUP协议实体的PDU会话释放命令。

图16中的步骤10：从AMF到UE 100 5GUP协议实体：发送NAS PDU会话释放命令。AMF将PDU会话释放命令转发给UE 100 5GUP协议实体。

图16中的步骤11：从UE 100 5GUP协议实体到UPF 510 5GUP协议实体：发送5GUP会话释放(包括会话Id)。在接收到PDU会话已释放的响应之后，UE 100 5GUP协议实体进入“空闲”状态，并通知UPF 510 5GUP协议实体5GUP会话已释放。

图16中的步骤12：从UE 100 5GUP协议实体到应用110：发送5GUPMediaQoSTerminated。UPF 510 5GUP协议实体在从UE 100 5GUP协议实体接收到5GUP释放会话通知时进入“空闲”状态。UE 100 5GUP协议实体通过向应用110发送释放通知来通知应用110具有IP流到QoS流的映射的5GUP会话已释放。

本文中的客户端设备100(可以表示为用户装置、用户设备(user equipment，UE)、移动站、物联网(internet of things，IoT)设备、传感器设备、无线终端、和/或移动终端)能够在无线通信系统(有时也称为蜂窝无线系统)中进行无线通信。UE还可以称为具有无线能力的移动电话、蜂窝电话、平板电脑、或膝上型电脑。本上下文中的UE可以是例如便携式设备、可存储设备、手持设备、计算机组成的设备、或车载移动设备，并且能够经由无线接入网与另一实体(例如另一接收器或服务器)进行语音通信和/或数据通信。UE可以是站(Station，STA)，STA为包含符合IEEE 802.11的到无线介质(wireless medium，WM)的媒体访问控制(MAC)和物理层(physical layer，PHY)接口的任何设备。UE还可用于在3GPP相关的LTE和高级LTE、WiMAX及其演进、以及第五代无线技术(例如新空口)中进行通信。

本文中的网络接入节点也可表示为无线网络接入节点、接入网络接入节点、接入点、或基站(例如无线基站(radio base station，RBS)，取决于使用的技术和术语，在某些网络中可以称为发射机、“gNB”、“gNodeB”、“eNB”、“eNodeB”、“NodeB”、或“B节点”)。无线网络接入节点可以属于不同的类别，例如宏eNodeB、家庭eNodeB、或微微基站，这基于发射功率以及小区大小。无线网络接入节点可以是站(STA)，STA为包含符合IEEE 802.11的到无线介质(WM)的媒体访问控制(MAC)和物理层(PHY)接口的任何设备。无线网络接入节点也可以是对应于第五代(fifth generation，5G)无线系统的基站。

此外，根据本发明实施例的任何方法可以在具有代码的计算机程序中实现，当由处理器件运行时，计算机程序使处理器件执行方法的步骤。计算机程序包括在计算机程序产品的计算机可读介质中。计算机可读介质可以基本上包括任何存储器，例如只读存储器(read-only memory，ROM)、可编程只读存储器(programmable read-only memory，PROM)、可擦除PROM(erasable PROM，EPROM)、闪存、电可擦除PROM(electrically erasable PROM，EEPROM)、或硬盘驱动器。

此外，本领域技术人员应认识到，客户端设备、网络接入节点、网络控制节点300、以及UPF 510的实施例包括用于执行本解决方案的例如功能、器件、单元、元件等形式的必要通信能力。其他这种器件、单元、元件、以及功能的示例是：处理器、存储器、缓冲器、控制逻辑、编码器、解码器、速率匹配器、解速率匹配器、映射单元、乘法器、决策单元、选择单元、开关、交织器、解交织器、调制器、解调器、输入、输出、天线、放大器、接收器单元，发射器单元、DSP、MSD、TCM编码器、TCM解码器、电源单元、电源馈线、通信接口、通信协议等，这些器件、单元、元件、以及功能适当地布置在一起以执行本解决方案。

特别地，客户端设备、网络接入节点、网络控制节点300、以及UPF 510的处理器可以包括例如可以解释和执行指令的中央处理单元(central processing unit，CPU)、处理单元、处理电路、处理器、专用集成电路(application specific integrated circuit，ASIC)、微处理器、或其他处理逻辑的一个或多个实例。因此，表述“处理器”可以表示包括多个处理电路(例如，上述任何、部分、或全部处理电路)的处理电路。处理电路还可以执行用于数据输入、数据输出、以及数据处理(包括数据缓冲)的数据处理功能以及设备控制功能(例如呼叫处理控制、用户界面控制等)。

最后，应理解，本发明不限于上述实施例，而是还涉及并包含所附独立权利要求范围内的所有实施例。

Claims (21)

1.一种用于移动通信系统(500)的客户端设备(100)，所述客户端设备(100)用于

从应用(110)接收第一应用请求(120)，其中，所述第一应用请求(120)指示建立用于传输数据包流的分组数据单元PDU会话的请求；

接收与所述数据包流相关的一组服务质量QoS要求；

在接收到所述第一应用请求(120)时，向网络控制节点(300)发送建立PDU会话的请求，以建立由用户面功能UPF(510)服务的PDU会话，其中，建立的所述PDU会话承载用于所述数据包流的第一组QoS流；以及

当所述第一组QoS流满足所述一组QoS要求时，所述客户端设备(100)用于

经由包括第一无线链路(722)和第一回程链路(724)的第一通信链路(720)以及包括第二无线链路(732)和第二回程链路(734)的至少一个第二通信链路(730)，在建立的所述PDU会话上的所述第一组QoS流中向所述UPF(510)发送所述数据包流。

2.根据权利要求1所述的客户端设备(100)，用于

向所述UPF(510)发送与建立的所述PDU会话相关的带内控制信息。

3.根据权利要求1或2所述的客户端设备(100)，其中，所述应用(110)运行在所述客户端设备(100)或另一客户端设备中。

4.根据前述权利要求中任一项所述的客户端设备(100)，其中，从所述应用(110)接收所述一组QoS要求。

5.根据前述权利要求中任一项所述的客户端设备(100)，用于

向所述应用(110)发送建立通知。

6.根据前述权利要求中任一项所述的客户端设备(100)，用于

当所述第一组QoS流不满足所述一组QoS要求时，获得接入网AN性能测量和回程性能测量；

基于所述AN性能测量和所述回程性能测量，检验所述第一通信链路(720)和所述至少一个第二通信链路(730)上的可用聚合资源是否能够实现所述一组QoS要求；

当所述可用聚合资源能够实现所述一组QoS要求时，向所述应用(110)发送映射请求，其中，所述映射请求包括所述AN性能测量和所述回程性能测量。

7.根据前述权利要求中任一项所述的客户端设备(100)，用于

从网络控制节点(300)接收未实现通知，其中，所述未实现通知指示所述第一组QoS流中的至少一个QoS流不再能够满足所述一组QoS要求中的至少一个QoS要求；

获得AN性能测量和回程性能测量；

响应于接收到所述未实现通知，向所述应用(110)发送映射请求，其中，所述映射请求包括所述未实现通知、所述AN性能测量、以及所述回程性能测量。

8.根据前述权利要求中任一项所述的客户端设备(100)，用于

从所述应用(110)接收第二应用请求(122)，其中，所述第二应用请求(122)指示修改建立的所述PDU会话；

获得AN性能测量和回程性能测量；

响应于接收到所述第二应用请求(122)，向所述应用(110)发送映射请求，其中，所述映射请求包括所述AN性能测量和所述回程性能测量

9.根据权利要求6至8中任一项所述的客户端设备(100)，用于

从所述应用(110)接收所述数据包流到第二组QoS流的映射；

基于接收的所述映射向所述网络控制节点(300)发送修改建立的所述PDU会话的请求，使得修改的所述PDU会话承载用于所述数据包流的第二组QoS流；

经由所述第一通信链路(720)和所述至少一个第二通信链路(730)，在修改的所述PDU会话上承载的所述第二组QoS流中向所述UPF(510)发送所述数据包流。

10.根据权利要求7至9中任一项所述的客户端设备(100)，用于

从所述网络控制节点(300)接收实现通知，其中，所述实现通知指示先前已接收到未实现通知的所述第一组QoS流中的至少一个QoS流能够满足所述一组QoS要求中的至少一个QoS要求；

向所述应用(110)发送实现通知接收；以及

当在修改建立的所述PDU会话之前接收到所述实现通知时

请求所述应用(110)删除用于修改建立的所述PDU会话的所述映射，并且使用用于建立的所述PDU会话的先前映射。

11.根据权利要求10所述的客户端设备(100)，用于

向所述应用(110)发送修改通知。

12.根据权利要求10或11所述的客户端设备(100)，其中，映射所述数据包流包括

将数据包流分流到两个或两个以上的单独的QoS流中，其中，每个QoS流建立在不同的通信链路上，

将多个数据包流聚合到选定的通信链路上的单个QoS流中，

将数据包流匹配到选定的通信链路上的QoS流，以及

将数据包流中的数据包复制到多个QoS流中，其中，每个QoS流建立在不同的通信链路上。

13.根据权利要求9至12中任一项所述的客户端设备(100)，用于

向所述UPF(510)发送所述映射操作或所述映射操作的逆。

14.根据前述权利要求中任一项所述的客户端设备(100)，用于

从所述应用(110)接收第三应用请求(124)，其中，所述第三应用请求(124)指示释放建立的所述PDU会话；

基于所述第三应用请求(124)向所述网络控制节点(300)发送释放建立的所述PDU会话的请求，以释放建立的所述PDU会话；

向所述应用(110)发送释放通知。

15.一种用于移动通信系统(500)的网络控制节点(300)，所述网络控制节点(300)用于

获得与由客户端设备(100)建立并由用户面功能UPF(510)服务的PDU会话中承载的至少一个QoS流相关的未实现通知，其中，所述未实现通知指示至少一个QoS流的QoS实现的变化；或

获得与由所述客户端设备(100)建立并由所述UPF(510)服务的PDU会话中承载的至少一个QoS流相关的实现通知，其中，所述实现通知指示至少一个QoS流的QoS未实现的变化；

向所述客户端设备(100)发送所述实现通知或所述未实现通知。

16.一种用于移动通信系统(500)的用户面功能UPF(510)，所述UPF(510)用于

从客户端设备(100)接收带内控制信息，其中，所述带内控制信息与在所述客户端设备(100)和所述UPF(510)之间建立的分组数据单元PDU会话相关，其中，建立的所述PDU会话承载用于数据包流的第一组QoS流。

17.根据权利要求16所述的UPF(510)，用于以下至少之一

基于所述带内控制信息从客户端设备(100)接收所述数据包流，其中，经由包括第一无线链路(722)和第一回程链路(724)的第一通信链路(720)以及包括第二无线链路(732)和第二回程链路(734)的至少一个第二通信链路(730)，在建立的所述PDU会话上的所述第一组QoS流中接收所述数据包流；以及

基于所述带内控制信息向所述客户端设备(100)发送所述数据包流，其中，经由所述第一通信链路(720)和所述至少一个第二通信链路(730)，在建立的所述PDU会话上的所述第一组QoS流中发送所述数据包流。

18.一种用于客户端设备(100)的方法(200)，所述方法(200)包括

从应用(110)接收(202)第一应用请求(120)，其中，所述第一应用请求(120)指示建立用于传输数据包流的分组数据单元PDU会话的请求；

接收(204)与所述数据包流相关的一组服务质量QoS要求；

在接收到所述第一应用请求(120)时，向网络控制节点(300)发送(206)建立所述PDU会话的请求，以建立由用户面功能UPF(510)服务的PDU会话，其中，建立的所述PDU会话承载用于所述数据包流的第一组QoS流；以及

当所述第一组QoS流满足所述一组QoS要求时，所述客户端设备(100)用于

经由包括第一无线链路(722)和第一回程链路(724)的第一通信链路(720)以及包括第二无线链路(732)和第二回程链路(734)的至少一个第二通信链路(730)，在建立的所述PDU会话上的所述第一组QoS流中向所述UPF(510)发送(208)所述数据包流。

19.一种用于网络控制节点(300)的方法(400)，所述方法(400)包括

获得(402)与由客户端设备(100)建立并由UPF(510)服务的PDU会话中承载的至少一个QoS流相关的未实现通知，其中，所述未实现通知指示至少一个QoS流的QoS实现的变化；或

获得(404)与由所述客户端设备(100)建立并由所述UPF(510)服务的PDU会话中承载的至少一个QoS流相关的实现通知，其中，所述实现通知指示至少一个QoS流的QoS未实现的变化；

向所述客户端设备(100)发送(406)所述实现通知或所述未实现通知。

20.一种用于UPF(510)的方法(600)，所述方法(600)包括

从客户端设备(100)接收(602)带内控制信息，其中，所述带内控制信息与在所述客户端设备(100)和所述UPF(510)之间建立的PDU会话相关，其中，建立的所述PDU会话承载用于数据包流的第一组QoS流。

21.一种计算机程序，具有程序代码，当所述计算机程序在计算机上运行时，用于执行根据权利要求18至20中任一项所述方法。

Images