首页> 中国专利> 用于应用友好型协议数据单元会话管理的系统和方法

用于应用友好型协议数据单元会话管理的系统和方法

摘要

本申请提供了一种用于应用友好型协议数据单元会话管理的系统和方法,该方法为在支持一个或多个应用程序的应用功能(AF)和被配置为管理在给定网络切片中的业务流的切片管理功能(SMF)之间交换用户面(UP)管理信息的方法。可以从AF或SMF中发起UP管理信息的交换。在由AF发起信息交换的情况下,AF提供的UP管理信息可以包括由AF支持的应用的业务需求。在由SMF发起信息交换的情况下,SM提供的UP管理信息可以包括运营商策略信息或事件,并且AF可以响应由AF支持的应用的业务需求信息。

著录项

  • 公开/公告号CN113329374A

    专利类型发明专利

  • 公开/公告日2021-08-31

    原文格式PDF

  • 申请/专利权人 华为技术有限公司;

    申请/专利号CN202110300123.7

  • 发明设计人 李顼;恩科·敦·道;

    申请日2018-01-05

  • 分类号H04W4/60(20180101);H04W72/04(20090101);H04W76/12(20180101);

  • 代理机构

  • 代理人

  • 地址 518129 广东省深圳市龙岗区坂田华为总部办公楼

  • 入库时间 2023-06-19 12:24:27

说明书

相关申请的交叉引用

本申请要求享有以下申请的优先权:于2017年1月5日提交的、题为“协议数据单元(PDU)会话管理系统和方法”、序列号为62/442,857的美国临时专利申请;于2017 年2月6日提交的、题为“协议数据单元(PDU)会话管理系统和方法”、序列号为 62/455,368的美国临时专利申请;于2017年2月16日提交的、题为“协议数据单元(PDU)会话管理系统和方法”、申请号为62/459,985的美国临时专利申请;于2017年 3月17日提交的、题为“协议数据单元(PDU)会话管理系统和方法”、申请号为62/473,274的美国临时专利申请;于2017年3月27日提交的申请号为62/477,384的美国临时申请,于2017年4月20日提交的申请号为62/487,960的美国临时申请;于2017年 4月28日提交的、题为“用于应用友好型协议数据单元(PDU)会话管理的系统和方法”、申请号为62/491,529的美国临时申请;于2017年6月19日提交的、题为“用于应用友好型协议数据单元(PDU)会话管理系统和方法”、申请号为62/522,040的美国临时申请,于2017年12月5日提交的、序列号为15/832,103的美国专利申请,以及于2018 年1月5日提交中国国家知识产权局的、申请号为CN201880006110.5的中国专利申请,其中每一个的全部内容通过引用并入本文。

技术领域

本申请涉及在通信网络和网络管理系统中的协议数据单元(protocol dataunit,PDU)会话管理领域,并且尤其涉及用于启用应用感知和应用友好型协议数据单元(PDU)会话管理的PDU会话管理的系统和方法。

背景技术

第3代合作伙伴计划(3

连接的设备,例如UE和服务器之间的通信由CP管理。与当前通信网络不同,在端点之间建立固定的短时间PDU会话,在下一代网络中,提出了PDU会话可以维持相对较长的时段,在此期间PDU会话参数可能需要改变。

因此,需要一种在例如所提出的5G网络的无线通信网络中服务移动无线通信设备的方法和装置,其中PDU会话可以是被配置和更新中的至少一个以反映当前PDU 会话参数,例如应用系统位置或UP选择。

网络功能虚拟化(network function virtualization,NFV)是一种网络架构概念,其使用IT虚拟化技术将整个类别的虚拟化网络功能创建为可以彼此连接或与其他实体连接,或者可以链接在一起的构建块,以创建通信服务。NFV依赖于,但不同于传统的服务器虚拟化技术,例如企业IT中使用的技术。虚拟化网络功能(virtualized networkfunction,VNF)可以包括运行不同软件和进程的一个或多个虚拟机(virtual machine,VM)、标准大容量服务器、交换机和存储设备,甚至云计算基础架构,而不是针对每个网络功能自定义硬件设备。在其他实施例中,可以通过使用包括容器使用的其他虚拟化技术,在不使用虚拟机的情况下提供VNF。在进一步的实施例中,定制的硬件设备可以驻留在用于不同虚拟网络的物理基础设施内,并且可以基于网络间的设备资源的划分而作为其自身的虚拟版本呈现给每个虚拟网络。例如,可以在现有资源上实例化虚拟会话边界控制器以保护网络域,而没有获得和安装物理网络保护单元的典型成本和复杂性。VNF的其他示例包括虚拟化负载平衡器、防火墙、入侵检测设备和广域网(wide area network,WAN)加速器。

NFV框架由三个主要部分组成:

虚拟化网络功能(VNF)是可以部署在网络功能虚拟化基础设施(networkfunctions virtualization infrastructure,NFVI)上的网络功能的软件实现。

网络功能虚拟化基础设施(NFVI)是提供部署VNF所需资源的所有硬件和软件组件的总和。NFV基础设施可以跨越多个位置。提供这些位置之间连接的网络被视为 NFV基础设施的一部分。

网络功能虚拟化管理和编排(management and orchestration,MANO)架构框架(NFV-MANO架构框架,例如由欧洲电信标准协会(European telecommunicationsstandards institute,ETSI)定义的NFV-MANO,称为ETSI_MANO或ETSI NFV-MANO)是所有功能块、由这些功能块所使用的数据存储库、以及这些功能块交换信息以便管理和编排NFVI和VNF所通过的参考点和接口的集合。

用于NFVI和NFV-MANO的构建块是NFV平台的资源。这些资源可以包括虚拟和物理的处理以及存储资源、虚拟化软件,并且还可以包括连接资源,例如提供物理处理和存储资源的数据中心或节点之间的通信链路。在NFV-MANO角色中,NFV平台由VNF和NFVI管理器以及在硬件平台上运行的虚拟化软件组成。NFV平台可用于实现用于管理和监控平台组件的运营商级特性,从故障中恢复并提供适当的安全性——所有这些都是公共运营商网络所需的。

软件定义拓扑(software-defined topology,SDT)是定义虚拟网络中的逻辑网络拓扑的联网技术。基于虚拟网络上提供的服务的要求以及可用的底层资源,可以由SDT 控制器定义虚拟功能和连接该功能的逻辑链路,然后可以针对给定的网络服务实例实例化该拓扑。例如,对于基于云的数据库服务,SDT可以包括客户端与数据库服务的一个或多个实例之间的逻辑链接。顾名思义,SDT通常由SDT控制器生成,SDT控制器本身可以是不同网络或网络切片中的虚拟化实体。逻辑拓扑确定由SDT控制器完成,其生成的网络服务基础设施(network service infrastructure,NSI)描述符(NSL descriptor,NSLD)作为输出。它可以使用NSI的现有模板并向其添加参数值以创建NSLD,或者它可以创建新模板并定义NSI的组成。

软件定义协议(software defined protocol,SDP)是可以在网络服务实例内使用的逻辑端到端(end-to end,E2E)技术。SDP允许生成可以提供给网络或网络切片内不同节点或功能的定制协议栈(可以使用一组可用的功能构建块创建)。切片特定协议的定义可以导致网络切片内的不同节点或功能,其具有定义的过程,以在接收到一种类型的分组时执行。顾名思义,SDP通常由一个或多个SDP控制器生成,该SDP控制器可以是在服务器上实例化的虚拟化功能。

软件定义的资源分配(software-defined resource allocation,SDRA)指的是在与给定服务实例或网络切片相关联的逻辑拓扑中,为逻辑连接分配网络资源的过程。在使用网络的物理资源来支持多个网络切片的环境中,SDRA控制器将网络的处理、存储和连接资源分配给不同的网络切片,以最好地适应每个网络切片所商定的服务要求。这可能导致资源的固定分配,或者可能导致动态改变的分配以适应业务和处理要求的不同时间分布。顾名思义,SDRA控制器通常将确定资源的分配,并且可以实现为在服务器上实例化的功能。

服务导向的网络自动创建(service oriented network auto creation,SONAC)是利用软件定义拓扑(SDT)、软件定义协议(SDP)和软件定义资源分配(SDRA)技术, 对于给定的网络服务实例来创建网络或虚拟网络的技术。通过协调SDT、SDP、SDRA 以及在一些实施例中的软件定义网络(software defined network,SDN)控制,可以获得优化和进一步的效率。在一些情况下,可以使用SONAC控制器来创建网络切片,在该网络切片内可以使用虚拟化基础设施(例如,VNF和逻辑链路)来创建符合第三代合作伙伴计划(3GPP)的网络以提供虚拟网络(virtual network,VN)服务。本领域技术人员将理解,分配给不同VNF和逻辑链路的资源可以由SONAC控制器的 SDRA类型功能控制,而VNF连接的方式可以由SONAC控制器的SDT类型功能确定。VNF处理数据分组的方式可以由SONAC控制器的SDP类型功能定义。SONAC 控制器可以用于优化网络管理,因此也可以被认为是网络管理(networkmanagement, NM)优化器。

随着NFV的实现细节和标准的发展,用于确保以一致且可靠的方式满足服务水平协议(service level agreements,SLA)的系统和方法是非常期待的。

在本公开内容中,本文未具体定义的缩写应当根据第三代合作伙伴计划(3GPP)技术标准来解释,例如技术标准TS 23.501V0.3.1(2017年3月)。

提供该背景信息是为了揭示申请人认为可能与本发明相关的信息。不允许或不应解释任何前述信息构成本发明的现有技术。

发明内容

根据本申请的实施例的目标,提供了一种用于保证服务水平协议(SLA)可以被满足的系统和方法。

在本发明的第一方面,提供了一种管理订阅通知的方法。该方法包括会话管理功能(session management function,SMF)从应用功能(application function,AF)获得与用户面(UP)选择或重选通知订阅相关联的信息;并且,该SMF向AF发送UP选择或重选的通知,该通知通知类型,所述通知类型指示所述通知是在UP路径被配置之前或之后被发送的。

在本发明第一方面的一个实施例中,来自AF的信息指示通知类型。在另一个实施例中,该通知还包括应用位置。

在本发明的第二方面,提供了例如会话管理功能(SMF)的功能。该功能包括处理器和计算机可读存储器。该计算机可读存储器存储指令,当由处理器执行时,SMF 被配置为从应用功能(AF)获得与用户面(UP)选择通知订阅和UP重选通知订阅中的至少一个相关联的信息;并且,通过网络接口向AF发送UP选择和UP重选中的至少一个的通知,该通知包括通知类型,所述通知类型指示所述通知是在UP路径被配置之前或之后被发送的。

在本发明第二方面的一个实施例中,获得自AF的信息指示通知类型。在另一个实施例中,该通知还包括应用位置。

在本发明的第三方面,提供了一种管理订阅通知的方法。该方法包括应用功能(AF)订阅关于用户面(UP)选择或重选的通知;并且,AF接收包括通知类型的消息,所述通知类型指示所述消息是在UP路径被配置之前或之后被发送的,其中消息与关于UP选择或重选的通知相关联。

在第三方面的实施例中,订阅通知包括发送订阅通知的请求,该请求包括通知类型。在另一实施例中,该消息包括应用位置。

在本发明的第四方面,提供了例如应用功能(AF)的网络功能。该网络功能包括处理器和计算机可读存储器。计算机可读存储器存储指令,当由处理器执行时,网络功能被配置为订阅关于用户面(UP)选择和UP重选中的至少一个的通知;并且接收包括通知类型的消息,所述通知类型指示所述消息是在UP路径被配置之前或之后被发送的,其中该消息与关于UP选择或重选的通知相关联。

在本发明的第四方面的实施例中,计算机可读存储器存储指令,在由处理器执行时进一步使得AF被配置为通过发送订阅通知的请求来订阅通知,该请求包含通知类型。在另一实施例中,所接收的消息包括应用位置。

本领域技术人员将理解,上述实施例可以结合包括其描述的实施例来实现,并且可以结合包括其描述的本方面的其他实施例来实现。在一些情况下,即使没有明确地描述为适用于上文,也可以结合互补方面来实现实施例。

因此,本发明的一个方面提供了一种方法,通过该方法,在支持一个或多个应用的应用功能(AF)和给定网络切片中被配置为管理业务流的切片管理功能(SMF)之间交换用户面(UP)管理信息。

在一种实现中,提供了一种用于管理网络上的协议数据单元会话数据业务的方法,该方法包括网络上可用的控制面实体:从应用系统(application system,AS)控制器接收基于应用程序接口(application program interface,API)的应用系统(AS)的位置通知,该基于API的AS位置通知识别将与识别的AS位置相关联的AS位置和数据业务;并且,发送AS位置通知以定位该AS。

在一种实现中,在控制面实体发送AS位置通知之前,该方法还包括控制面实体认证该AS控制器。认证该AS控制器可以包括向网络上可用的认证服务器功能(authentication server function,AUSF)发送认证请求;并且,从AUSF接收指示响应于该认证请求的认证结果的认证响应。

在一种实现中,AS位置通知包括改变PDU会话的现有位置的AS重定位通知。

在一种实现中,其中AS位置通知包括建立未来PDU会话位置的AS位置通知。AS 重定位通知可以被发送到会话管理功能(SMF)以配置针对重新定位的AS的数据业务的业务转向。

在一种实现中,AS位置通知被发送到策略控制功能(policy control function,PCF)以生成用于数据业务的用户面(UP)选择策略和业务转向策略。

在一种实现中,提供了一种用于管理与连接到网络的用户设备(UE)交换的协议数据单元(PDU)会话数据业务的方法,该方法包括在网络上可用的控制面实体:接收来自 UE的PDU会话请求;基于用户订阅数据验证UE上下文并授权会话请求,并且如果被授权,则该方法还包括:为所请求的PDU会话选择和建立用户面(UP)路径;向UE发送 PDU会话请求响应。

在一种实现中,PDU会话请求包括会话ID。

在一种实现中,PDU会话请求包括用于所请求的PDU会话的优选会话和服务连续性(Session and Service Continuity,SSC)模式。

在一种实现中,PDU会话请求包括应用标识符,其指示PDU会话请求专用于与应用标识符相关联的应用。

附图说明

通过以下结合附图的详细描述,本发明的其他特征和优点将变得显而易见,其中:

图1是根据本发明的代表性实施例的可用于实现装置和方法的计算系统100的框图;

图2是示意性地示出可用于本发明实施例的代表性服务器的架构的框图;

图3A是示出5G核心网络的系统架构的基于服务的视图的框图;

图3B示出了应用系统控制器的实施例,其负责在AS网络内定位,重定位,选择或重选AS;

图4是示意性地示出应用程序重定位的框图;

图5呈现了示出AS位置或重定位通知的实施例的信令图;

图6呈现了示出UP(重新)选择通知请求过程的实施例的信令图;

图7呈现了示出UP(重新)选择通知过程的实施例的信令图;

图8呈现了示出用于应用友好的PDU会话建立过程的实施例的信令图;

图9呈现了示出用于PDU会话修改的应用友好的UP重选过程的实施例的信令图;

图10是示出网络架构的实施例的框图;

图11A和11B是示出作为会话建立的一部分,由SMF执行的受应用影响的UP选择的实施例的信令图;

图12A和12B是示出受应用影响的UP重选过程的实施例的信令图;

图13是示出应用(重新)定位通知服务过程的实施例的信令图;

图14是示出UP(重新)选择通知服务的实施例的信令图;

图15是示出用户面功能、动态网络接入标识符以及应用主机之间的关系的框图,以指示由于选择动态网络而导致的用户面功能的(可能)隐式选择;

图16是示出UP(重新)选择通知过程的实施例的信令图;

图17是示出用于非漫游和具有本地疏导的漫游的UE请求的PDU会话建立过程的实施例的信令图;

图18A和18B显示了示出由于应用重定位导致的PDU会话锚重配置的实施例的信令图;

图19是示出用于专用于边缘计算应用的PDU会话的PDU会话锚重定位的方法的实施例的信令图。

图20是示出用于由多个边缘计算应用共享的PDU会话的PDU会话锚重定位方法的实施例的信令图;

图21是提供说明分段管理的实施例的简化网络图;

图22是说明根据本发明实施例的分段管理的简化网络图;

图23是示出了根据本发明实施例的各个示例过程的呼叫流程图;

图24是示出了根据本发明实施例的各个示例过程的呼叫流程图;

图25A-25C是示出了根据本发明实施例的各个示例过程的呼叫流程图;

图26是示出了根据本发明实施例的另一示例过程的呼叫流程图;

图27A和27B显示了根据本发明的示例实施例示出的,到AF的UP路径管理通知的各个过程的呼叫流程图;

图28A和28B显示了根据本发明的示例实施例示出的,到AF的UP路径管理通知的替换过程的呼叫流程图;

图29A和29B显示了根据本发明的示例实施例示出的,到AF的UP路径管理通知的另一替换过程的呼叫流程图;图30是示出根据本发明示例实施例处理的流程图;以及

图31是示出根据本发明实施例的应用位置、数据网络接入识别符(data networkaccess identifier,DNAI)和UPF之间的示例关系的逻辑框图。

应注意,在所有附图中,相同的特征由相同的附图标记标识。

具体实施方式

在本申请中,术语IP地址已用于示例性实施例中。应当理解,在不同的实施例中,中可以使用不同的标识符和地址,例如硬件地址、IP地址、媒体访问控制(media accesscontrol,MAC)地址或可以用来代替适用IP地址的其他地址。

图1是可用于实现本文公开的设备和方法的计算系统100的框图。特定设备可以利用所示的所有组件或仅利用组件的子集,并且集成程度可以随设备而变化。此外,设备可以包含组件的多个实例,例如多个处理单元、处理器、存储器、发送器、接收器等。计算系统100包括处理单元102。处理单元102也可以称为电子设备(electronic device,ED)。在一些实施例中,处理单元102可以是用户设备(UE),而在其他实施例中,它可以是例如数据中心环境内的计算服务器的计算平台。该处理单元102通常包括中央处理单元(centralprocessing unit,CPU)114、总线120以及存储器108,并且还可以可选地包括大容量存储设备104、视频适配器110以及I/O接口112(以虚线示出)。本领域技术人员将理解,CPU 114代表处理能力。在一些实施例中,可以提供专用处理核心以代替传统的CPU。例如,除了CPU之外或代替CPU,可以提供图形处理单元(graphic processing unit, GPU)或其他所谓的加速处理器(或处理加速器)。

CPU 114可包括任何类型的电子数据处理器。存储器108可以包括任何类型的非暂时性系统存储器,诸如静态随机存取存储器(static random access memory,SRAM)、动态随机存取存储器(dynamic random access memory,DRAM)、同步DRAM(synchronous DRAM,SDRAM)、只读存储器(read-only memory,ROM)或其组合。在一个实施例中,存储器 108可以包括用于启动的ROM,以及用于在执行程序时使用的程序和数据存储的DRAM。总线120可以是任何类型的若干总线架构中的一个或多个,其包括存储器总线或存储器控制器,外围总线或视频总线。

大容量存储器104可以包括任何类型的非暂时性存储设备,其被配置为存储数据、程序和其他信息并且使得数据、程序和其他信息可以通过总线120访问。大容量存储器104可以包括例如,固态驱动器、硬盘驱动器、磁盘驱动器或光盘驱动器中的一个或多个。

视频适配器110和I/O接口112提供可选接口,以将外部输入和输出设备耦合到处理单元102。输入和输出设备的示例包括耦合到视频适配器110和I/O设备116的显示器118,例如耦合到I/O接口112的触摸屏。其他设备可以耦合到处理单元102,并且可以使用额外的或更少的接口。例如,诸如通用串行总线(universal serial bus,USB)(未示出)的串行接口可用于为外部设备提供接口。

处理单元102还可以包括一个或多个网络接口106,其可以包括至少一个有线链路,例如以太网电缆,以及用于接入一个或多个网络122的无线链路。该网络接口106允许处理单元102经由网络122与远程实体通信。例如,网络接口106可以经由一个或多个发射器/发射天线和一个或多个接收器/接收天线提供无线通信。在一个实施例中,处理单元102 被耦合到局域网或广域网,用于与远程设备,例如其他处理单元、因特网或远程存储设施,进行数据处理和通信。

图2是示意性地示出可在本发明的实施例中使用的代表性服务器200的架构的框图。可以预期的是,服务器200可以物理地实现为一个或多个计算机、存储设备以及路由器(其中的任何一个或全部可以根据上面参考图1描述的系统100构造)互连在一起以形成本地网络或集群,并执行合适的软件以完成其预期的功能。普通技术人员将认识到,存在可用于本发明目的的许多合适的硬件和软件组合,这些组合或者是本领域已知的或者可以在将来开发。因此,本说明书中不包括显示物理服务器硬件的图。然而,图2的框图示出了服务器200的代表性功能架构,但是应该理解,可以使用硬件和软件的任何合适组合来实现该功能架构。

如图2中所示,图示的服务器200通常包括主机基础设施202和应用平台204。该主机基础设施202包括服务器200的物理硬件资源206(例如信息处理、业务转发和数据存储资源),以及向应用平台204呈现硬件资源206的抽象的虚拟化层208。该抽象的具体细节将取决于由应用层承载的应用的需求(如下所述)。因此,例如,提供业务转发功能的应用可以与硬件资源206的抽象一起呈现,其简化了一个或多个路由器中的业务转发策略的实现。类似地,提供数据存储功能的应用可以与硬件资源206的抽象一起呈现,其有助于数据的存储和检索(例如,使用轻量级目录访问协议——LDAP(lightweight directory accessprotocol))。

应用平台204提供用于托管应用的能力,并且包括虚拟化管理器210和应用平台服务 212。该虚拟化管理器210通过提供基础结构即服务(infrastructure as a service,IaaS)设施来支持用于应用214的灵活且有效的多租户运行时间和托管环境。在操作中,虚拟化管理器210可以为由平台204托管的每个应用程序提供安全性和资源“沙箱”。每个“沙箱”可以被实现为虚拟机(VM)216,或者可以实现为虚拟化容器,其中包括适当的操作系统和对服务器200的(虚拟化的)硬件资源206的受控访问。应用平台服务212向应用平台 204上托管的应用214提供一组中间设备应用服务和基础设施服务,其将在下文更详细地描述。

来自供应商、服务提供商和第三方的应用214可以在相应的虚拟机216内部署和执行。例如,可以借助于如上所述的在应用平台204上托管的一个或多个应用214实现MANO 和SONAC(及其各种功能,例如SDT、SDP和SDRA)。可以根据本领域中已知的服务导向的体系结构(service-oriented architecture,SOA)的原理方便地设计应用程序214与服务器200中的服务之间的通信。

通信服务218可以允许在单个服务器200上托管的应用程序214与应用平台服务212 进行通信(例如,通过预定义的应用程序编程接口(application programminginterfaces, API))并且彼此通信(例如,通过服务-特定的API)。

服务注册表220可以提供服务器200上可用服务的可见性。此外,服务注册表220可以提供服务可用性(例如,服务的状态)以及相关的接口和版本。应用程序214可以使用其来发现和定位应用程序所需服务的端点,并发布它们自己的服务端点以供其他应用程序使用。

移动边缘计算允许云应用服务与移动网络元件一起托管,并且还有助于利用可用的实时网络和无线信息。网络信息服务(network information services,NIS)222可以向应用214 提供低级网络信息。例如,NIS 222提供的信息可以由应用程序214使用,以计算和呈现高级和有意义的数据,例如:小区ID、用户的位置、小区负载以及吞吐量指导。

流量卸载功能(traffic off-load function,TOF)服务224可以对业务进行优先级排序,并将选择的、基于策略的用户数据流路由到应用程序214并从应用程序214路由。可以以各种方式将TOF服务224提供给应用程序214,包括:转发模式,其中(上行链路和下行链路中的至少一个)业务被传递到应用214,应用214可以监视、修改或塑造该业务,然后将其发送回原始分组数据网络(original packet data network,PDN)连接(例如3GPP承载);以及端点模式,其中业务由充当服务器的应用程序214终止。

图3A示出了用于5G或下一代核心网络(5GCN/NGCN/NCN)的基于服务的架构300。此图描绘了节点和功能之间的逻辑连接,并且其示出的连接不应被解释为直接物理连接。 ED102与(无线)接入网络((radio)access network,(R)AN)节点302(其可以是例如gNodeB(gNB))形成无线接入网络连接,其连接到用户面(UP)功能(UPF)304,例如通过网络接口的UP网关,提供定义的接口,例如N3接口。UPF 304通过例如N6接口的网络接口提供逻辑连接至数据网络(data network,DN)306。ED 102和(R)AN节点302之间的无线接入网络连接可以被称为数据无线承载(data radio bearer,DRB)。

DN 306可以是用于提供运营商服务的数据网络,或者它可以在第三代合作伙伴计划(3GPP)的标准化范围之外,例如因特网,该网络用于提供第三方服务,并且在一些实施例中,DN 306可以表示边缘计算网络或资源,例如移动边缘计算(mobile edge computing,MEC)网络。

ED 102还通过逻辑N1连接(尽管连接的物理路径不是直接的)连接到接入和移动性管理功能(access and mobility management function,AMF)308。AMF 308负责接入请求的认证和授权,以及移动性管理功能。AMF 308可以执行3GPP技术规范(technicalspecification,TS)23.501所定义的其他角色和功能。在基于服务的视图中,AMF 308可以通过表示为Namf的基于服务的接口与其他核心网络控制面功能通信。

会话管理功能(SMF)310是网络功能,其负责对分配给ED的IP地址的分配和管理,以及针对与ED 102的特定会话相关联业务的UPF 304(或UPF 304的特定实例)的选择。可以理解的是,网络300中通常会有多个SMF 310,每个SMF 310可以与相应的一组ED 102、(R)AN节点302或UPF 304相关联。SMF 310可以在基于服务的视图中,通过表示为Nsmf的基于服务的接口与其他核心网络功能通信。SMF 310还可以通过例如网络接口 N4的逻辑接口连接到UPF 304。

认证服务器功能(AUSF)312通过基于服务的Nausf接口向其他网络功能提供认证服务。

网络暴露功能(network exposure function,NEF)314可以部署在网络中,以允许服务器、功能和例如可信域之外的其他实体暴露于网络内的服务和能力。在一个这样的示例中, NEF 314可以非常类似于所示网络外部的应用服务器与诸如策略控制功能(PCF)314、SMF 310、统一数据管理功能(unified data management function,UDM)320以及AMF308之类的网络功能之间的代理,使得外部应用程序服务器可以提供可能在与数据会话相关联的参数的设置中使用到的信息。NEF 314可以通过基于服务的Nnef网络接口与其他网络功能通信。NEF 314还可以具有到非3GPP功能的接口。

网络存储库功能(network repository function,NRF)318提供网络服务发现功能。该 NRF 318可以特定于与其相关联的公共陆地移动网络(public land mobilitynetwork,PLMN)或网络运营商。服务发现功能可以允许网络功能和连接到网络的ED确定接入现有网络功能的位置和方式,并且可以呈现基于服务的接口Nnrf。

PCF 314通过基于服务的Npcf接口与其他网络功能通信,并且可以用于向其他网络功能提供策略和规则,包括控制面内的那些功能。策略和规则的实施和应用不一定是PCF314的责任,反而通常是PCF 314向其发送策略的功能的责任。在一个这样的示例中,PCF314可以将与会话管理相关联的策略发送到SMF 310。这可以用于允许统一的策略框架,利用该统一的策略框架可以管理网络行为。

统一数据管理功能(UDM)320可以呈现基于服务的Nudm接口以与其他网络功能通信,并且可以向其他网络功能提供数据存储设施。统一数据存储可以允许统一的网络信息视图,该视图可用于确保最相关的信息对来自单个资源的不同网络功能是可用的。这可以使其他网络功能的实现更容易,因为它们不需要确定特定类型的数据在网络中的存储位置。UDM 320可以使用例如Nudr的接口来连接到用户数据存储库(user data repository,UDR)322。PCF 314可以与UDM 320相关联,因为它可能涉及向UDR请求和提供订阅策略信息,但是应该理解,PCF 314和UDM 320通常是独立的功能。

PCF 314可以具有到UDR 322的直接接口,或者可以使用Nudr接口与UDR 322连接。UDM 320可以接收检索存储在UDR 322中内容的请求,或者在UDR 322中存储内容的请求。UDM 320通常负责例如凭证处理、位置管理和订阅管理之类的功能。UDR 322还可以支持身份验证凭据处理、用户标识处理、接入授权、注册/移动性管理、订阅管理和短消息服务(short message service,SMS)管理中的任何一个或全部。UDR 322通常负责存储由UDM320提供的数据。存储的数据通常与策略配置文件信息(可由PCF 314提供)相关联,其管理对存储数据的接入权限。在一些实施例中,UDR 322可以存储策略数据,以及可以包括订阅标识符、安全凭证、接入和移动性相关的订阅数据和会话相关数据中的任何一个或全部的用户订阅数据。

应用功能(AF)324表示在网络运营商域内和3GPP兼容网络内部署的应用的非数据平面(也称为非用户面)功能。AF 324通过基于服务的Naf接口与其他核心网络功能交互,并且可以访问网络能力暴露信息,以及提供用于例如业务路由的决策的应用信息。AF 324还可以与例如PCF 314的功能交互,以将应用特定输入提供到策略和策略实施决策中。应当理解,在许多情况下,AF 324不向其他NF提供网络服务,而是经常被视为由其他 NF提供的服务的消费者或用户。3GPP网络外部的应用可以通过使用NEF 314执行与AF 324相同的许多功能。

ED 102与用户面(UP)326和控制面(CP)328中的网络功能通信。UPF 304是CN UP326的一部分(DN 306在5GCN之外)。(R)AN节点302可以被认为是用户面的一部分,但是因为严格来说它不是CN的一部分,所以它不被认为是CN UP 326的一部分。 AMF 308、SMF 310、AUSF 312、NEF 314、NRF 318、PCF 314和UDM 320是驻留在CN CP 328内的功能,并且通常被称为控制面功能。AF 324可以与CN CP 328内的其他功能(直接或间接地通过NEF 314)通信,但是通常不被认为是CN CP 328的一部分。

本领域技术人员将理解,可以在(R)AN节点302和DN 306之间串联地连接多个UPF,并且可以通过使用多个并联的UPF来适应到不同DN的多个数据会话。

图3B示出了无线通信网络300的一部分,其中UE 102经由接入节点(access node,AN) 302连接到核心网络(CN)控制面(CP)328和CN用户面(UP)326。CN CP 328包括统一数据管理(UDM)功能320,其与管理面330通信。

应用系统(AS)控制器332负责在AS网络334内定位、重定位、选择或重选AS。该AS控制器332通过网络暴露功能(NEF)314连接到CN CP 328。

CN CP 328用于管理3GPP域内资源的逻辑位置。AS网络334的应用服务器或应用系统由AS控制器332管理。在管理面330内由网络功能提供给CN CP 328在CN UP 326和 AS之间的业务转向能力或互联质量(例如,通过吞吐量、延迟、例如PDU会话的负载来测量),并且与这些能力和连接质量参数相关联的信息可以存储在UDM 320中。CP 328 可以使用业务转向能力信息来建立各通信方之间有效的端到端路径。

CN CP 328通过接口NG1与连接的UE 102通信,并且与通过接口NG2提供连接的 AN302通信。AN 302通过接口NG3与CN UP 326通信。CN UP 326由CN CP 328通过接口NG4控制。接口NG1、NG2、NG3和NG4由3GPP移动宽带标准被更详细地描述并且定义。本领域技术人员将理解,可以在不脱离本文公开的发明的情况下对这些接口的具体定义进行变化。这些接口的具体定义条款可以在可公开访问的文档中找到(例如,参见 www.3gpp.org的历史和当前标准文档)。

CN CP 328负责配置用户面(UP)网关(gateway,GW)336处的业务转向,用于将上行链路(uplink,UL)应用业务路由到适当的AS位置,可能考虑可能的内部AS(重新)定位。

AS网络334负责将下行链路(downlink,DL)应用业务转向到适当的UP GW 336,可能考虑到可能的内部UP(重新)选择。

由AS网络334进行的业务转向可以由AS控制器332配置。在一些实施例中,由AS 网络334进行的业务转向可以通过AS网络334本身内部的上层移动性管理机制配置或实现。在图3B的示例中,将UP GW 336连接到AS网络334的直线指示通过业务转向实现将CN UP 326连接到AS网络334的链路。本申请中的以下信令图描述了突出CN UP 326 和AS网络334之间的交互的实现,以使用有效的端到端路径实现应用业务的应用感知 PDU会话管理。

图3B中所示的网络架构提供了实现CP 328(或CP内的节点和功能)与AS控制器332之间的交互可能必需的接口。该接口可用于为需要高效的端到端路径的应用业务的应用感知PDU会话管理的启用。

从广义上讲,本发明的实施例提供了一种方法,通过该方法可以在支持一个或多个应用的应用功能(AF)与会话管理功能(SMF)之间交换用户面(UP)管理信息。AF通常是3GPP兼容网络之外的功能(在一些示例中,它可以是向连接到3GPP兼容网络的UE 提供服务的服务器或服务器集,而在其他示例中,AF可以是在3GPP兼容核心网络之外或在3GPP兼容RAN之外的移动边缘计算环境中实例化的功能)。在一些实施例中,AF 被称为AS控制器。AF可以是3GPP标准范围之外的功能。AF可以在3GPP核心网络外部的应用服务器上实例化,并且可以作为控制器以负责例如本地DN内的AS(重新)定位(或AS(重新)选择)的功能。

SMF是3GPP兼容的网络功能,通常在控制面(CP)内,被配置为管理通常在给定网络切片内的业务流。简而言之,可以从与业务流相关联的AF或SMF发起与特定业务流相关联的UP管理信息的交换。在AF发起信息交换的情况下,AF提供的UP管理信息可以包括AF支持的应用的业务要求。在SMF发起信息交换的情况下,SMF提供的UP 管理信息可以包括运营商策略信息或事件,并且AF可以以AF支持的应用的业务需求信息来响应。在一些实施例中,其他网络实体可以通过向SMF发送消息来触发该过程,并且SMF可以响应于接收到的这样的请求而发起该过程。

应用功能可以发送请求以影响针对PDU会话业务的SMF路由决策。AF请求可以影响UPF(重新)选择并允许将用户业务路由到对数据网络(由数据网络接入标识符(DNAI)标识)的本地接入。

假设发出这样的请求的应用功能属于为UE服务的PLMN。应用功能可以代表不是由服务UE的PLMN拥有的应用发出请求。

如果运营商不允许应用功能直接接入网络,则应用功能将使用NEF与5GC交互。该操作可以遵循相关技术标准的规定,例如,3GPP技术标准TS 23.501V0.3.1(2017年3 月)的条款6.2.10。在AF不直接接入网络的实施例中,可以提供NEF以提供允许AF接入网络的CP功能的接口。虽然可以向可信AF提供与CN CP功能交互的能力,但是在一些网络中可能存在过多功能以向它们中的每一个提供对CP功能的接入。相反,NEF可以充当CN之外的AF的代理,以与CP功能交换信息。通过使用NEF,可以向AF提供与 CP功能通信的路径,但是可以不直接知道与其通信的功能的地址或网络名称。

应用功能可以负责本地DN内的应用的(重新)选择或重定位。为此目的,AF可以请求接收关于与PDU会话相关的事件的通知。

在一些实施例中,对于允许与5GC NF直接交互的AF,可以经由N5将关于各个UE 的正在进行的PDU会话的AF请求发送到PCF。在一些实施例中,可以经由NEF发送AF 请求。可以经由NEF发送针对多个UE的请求,并且可以针对多个PCF。然后,PCF可以将AF请求转换为应用于PDU会话的策略。本领域技术人员将理解,可以以多种不同方式实现AF请求到策略的转换,包括生成可以由PCF发送到UPF或一种UPF的策略,该策略管理在会话中与所识别的与业务相关联业务的处理,根据所接收的AF请求来执行策略的生成。当AF已订阅SMF通知时,可以直接或通过NEF将此类通知发送到AF。

PCF还可以订阅这样的通知。

这种AF请求可以至少包含:

用于识别要被路由的业务的信息。该业务可以通过以下方式在AF请求中被识别:数据网络号(data network number,DNN)或其他类型的DN标识符和可能的切片信息(例如,单网络切片选择辅助信息(single network slice selection assistance information,S-NSSAI)或AF服务标识符)。

当AF提供AF服务标识符(即AF代表其发出请求的服务的标识符)时,5G核心网络功能(例如,NEF或PCF)可以将该标识符映射到目标DNN以及切片信息(S-NSSAI)。

当NEF处理AF请求时,AF服务标识符可用于授权AF请求。

应用程序标识符或业务过滤信息(例如IP地址5元组)。应用程序标识符指的是处理UP 业务的应用程序,并且UPF可以使用它来检测应用的业务。AF还可以将分组过滤器描述(packet filter description,PFD)与应用标识符相关联,但是该关联可以通过单独的请求来完成。

有关上述信息所标识的业务的N6业务路由要求的信息。应当理解,N6指的是UPF与CN 外部的DN之间的接口。当应用程序静态实例化时(即路由配置文件ID每个对应于DNAI),可以以路由配置文件ID列表的形式提供关于业务路由要求的信息,每个路由配置文件ID对应于本地DN中应用程序的单个主机位置。当实例化应用程序的 DNAI可以动态变化时,其可以以DNAI列表和相关的N6路由信息的形式提供。基于关于N6业务路由要求的信息,其在一些实施例中可以包括路由配置文件ID,PCF 确定每个对应于在SMF或UPF上预先配置的转向行为的业务转向配置文件ID的列表。PCF将业务转向策略ID发送到SMF。该业务转向策略ID与启用到DN的业务转向的机制有关。如果AF经由NEF与PCF交互,则其可以以应用的地址或名称的形式,指示DNN和主机位置中的至少一个,并且NEF可以将信息映射至路由配置文件ID。在一个实施例中,SMF被用于接收业务转向策略ID并确定应当应用哪个业务转向策略ID和相应的业务转向行为。SMF将选定的业务转向策略ID传递给UPF。在一个实施例中,该UPF被用于识别预先配置的并与所选择的业务转向策略ID相关联的相应的业务转向参数。UPF还可以在处理数据业务时,进一步应用相应的业务转向参数。

N6业务路由要求与在本地接入DN中实现业务转向的机制有关。它们应与UPF中配置的本地规则相对应,以支持业务转向。路由配置文件ID可以指AF和5GC之间预先约定的策略,或者在替换实施例中,它们可以简单地指代预定义的路由要求。该政策可以参考发送给SMF的不同转向政策ID。在一些实施方式中,策略可以基于其他条件,例如时间条件(例如,基于一天中的时间等)。

应该应用业务向其路由的应用程序的潜在位置。该应用程序的潜在位置是或可能表示为DNAI列表。在一些实施例中,当AF经由NEF与PCF交互时,AF可以向PCF或NEF 提供应用的主机地址或主机名列表,其通过NEF被转换为DNAI列表。在一些实施例中,当AF经由NEF与PCF交互时,NEF可以将AF提供的AF服务标识符信息映射到DNAI 列表。在任一种情况下,DNAI可以被用于例如UPF(重新)选择。

AF请求还可以包含:

关于要为其路由业务的UE的信息。这可以对应于使用例如TS23.682中定义的外部标识符或TS23.003中描述的MSISDN,或IP地址/前缀来标识的个体UE,或者可以对应于由组标识符,例如,如TS23.682中定义的那些外部组标识符,或者请求适用的任何正在接入DNN、S-NSSAI和DNAI的组合的UE所识别的一组UE,其可以由指示符识别。在PDU类型是IP的情况或实施例中,当AF提供UE的IP地址/前缀时,这允许PCF识别该请求适用的PDU-CAN会话,并且AF请求仅适用于该UE的当前 PDU-CAN会话。在这种情况下,还可以提供例如UE标识的附加信息以帮助PCF识别正确的PDU-CAN会话。

否则,该请求可以应用于与AF请求中的参数匹配的任何未来PDU会话。

当AF请求以任何UE或UE组为目标时,AF请求可能影响可能由多个SMF和PCF 服务的多个PDU会话。

当AF请求以一组UE为目标时,它在其请求中提供一个或多个组标识符。在一些实施例中,该组的成员在其订阅(即,组标识符)中包括组信息,该信息存储在UDM 中。在一个实现中,该组信息可以由SMF检索,例如通过N10接口,并且通过例如 N7接口在PDU-CAN会话建立时传递给PCF。该实现允许也将组标识符提供给AMF,例如通过N8接口。在一些实施例中,组标识符可以作为PCF非标准数据存储在UDR (充当订阅配置文件存储库“subscription profile repository,SPR”)中。在一些实施例中,UE可以属于多个组。

关于何时应用业务路由的信息(例如,时间有效性条件)。使用时间有效性条件允许将到期时间与AF请求相关联,或允许条件在定义的时间窗口期间应用。这些定义的时间窗口可以是重复或一次性的。

关于在应用业务路由时UE将在何处(空间有效性条件)的信息。在一个实施例中,这以例如RAN节点标识符的地理或拓扑标识符的形式提供,指示当应用业务路由时UE 的可能的服务RAN节点。如果AF经由NEF与PCF交互,则它提供或在一些实施例中可以提供地理区域标识符的列表,并且NEF将信息映射到RAN节点标识符。在一个实施例中,可以以感兴趣的区域的形式提供空间有效性条件。该感兴趣的区域可以包括,例如,地理区域或者定义关于网络拓扑的感兴趣区域的拓扑区域。可以使用例如跟踪区域ID、(R)AN节点ID、小区ID等的空间标识符来规定感兴趣的区域。如果AF经由NEF与PCF交互,则它可以提供地理区域标识符的列表,并且NEF可以基于预先配置的信息将信息映射到感兴趣的区域。预配置可以由管理面功能完成。该预配置可以包括区域ID→区域信息/配置→感兴趣区域(或RAN节点ID或小区ID)的映射。

或者,在先前发生的单独过程中,AF可以提供区域ID→区域信息/配置到NEF的映射信息,并且管理面功能用RAN节点的信息或小区位置信息或预定义的感兴趣区域信息来配置NEF。该NEF可以使用AF提供的信息和管理面提供的信息(两者都是预先配置的信息)来进行映射。 AF订阅以下事件。

关于UP路径管理事件的通知:在UPF改变时为UE服务的UPF的DNAI的改变。关于由SMF发送到AF的源DNAI到靶DNAI的变化的相应通知包括靶DNAI的身份和锚UPF的地址。在一些实施例中,该通知还可以包括UE的IP地址/前缀、UE身份信息(例如,外部标识符或MSISDN)以及与核心网络相关的N6路由信息。

在一些实施例中,如果PDU会话类型是IP,则可以不需要UE识别信息和与核心网络相关的N6路由信息中的至少一个。

订阅可以用于前期通知和后期通知中的至少一个。在订阅前期通知的情况下,SMF在执行UPF(重新)选择之前发送通知。在订阅后期通知的情况下,SMF在UPF(重新)选择完成时发送通知。

应用功能可以发送请求以影响SMF路由决策,用于事件订阅或两者。

PCF基于从AF接收的信息、运营商的策略等来授权从应用功能接收的请求并确定业务转向策略。该业务转向策略可以指示在SMF中配置的合适的业务转向配置文件的列表,并且在一些实施例中,业务转向策略可以包括N6路由信息,例如,在与应用相关联的N6 路由信息由AF明确提供的情况下。业务转向配置文件可以包括其支持的路由配置文件ID 和相应的数据网络接入标识符(DNAI)中的至少一个。DNAI与SMF考虑用于UPF选择的信息有关,例如,用于转移(本地)一些与PCF提供的业务过滤器匹配的业务。

PCF确认到AF或NEF的请求。

在会话建立过程中,UE可以在会话请求中提供应用标识符,指示PDU会话旨在或专用于由应用标识符标识的应用。当会话请求中的DNN指向本地DN并且在会话请求中包含应用程序标识符时,SMF可以启动第三方认证/授权,如TS23.501,第5.6.6条款中所述,以验证应用程序访问。

在PDU会话建立过程(其实施例在图28A中示出)期间,SMF可以经由UDM(例如,步骤2806和2808)从UDR获得订阅组信息(例如,IMSI-组标识符)。SMF向PCF 提供应用标识符(如果可用)和订阅信息(例如,步骤2814或2818)以应用运营商策略。

对于对应于AF请求的PDU-CAN会话,PCF向SMF提供可以包含以下中的至少一个的策略和计费控制(policy and charging control,PCC)规则:应用信息(即,应用标识符)和针对应该应用的业务路由的关于DNAI的信息中的至少一个;以及业务转向配置文件ID列表,空间有效性条件和关于SMF事件的AF订阅的信息中的至少一个。在AF请求中明确提供与应用程序相关联的N6路由信息的实施例中,PCF还可以将N6路由信息作为PCC规则的一部分提供给SMF。这是通过在PDU-CAN会话建立时提供策略,或通过启动PDU-CAN会话修改过程来完成的。在一些实施例中,PCF周期性地评估AF请求的时间有效性条件,并根据评估结果通知SMF激活或停用相应的PCC规则。

如果激活的PCC规则包含空间有效性条件,则SMF订阅以从AMF接收UE移动性信息,其与UE进入或离开在空间有效性条件中指定的感兴趣区域相关联。SMF使用UE 移动性信息和空间有效性条件来确定PCC规则是否对应用有效。

当PCC规则有效,SMF可能基于本地策略,考虑PCC规则中的信息,以便:

为PDU会话(重新)选择UPF。SMF负责处理与UPF相关联的UE位置(TAI/Cell-Id)和应用之间的映射。SMF负责选择为PDU会话提供服务的UPF。该操作可以遵循相关技术标准的规定,例如,3GPP技术标准TS 23.501V0.3.1(2017年3月)的第6.3.3 条款。

激活用于业务多归属或执行UL分类器(UL CL)的机制。这些机制可以遵循相关技术标准的规定,例如3GPP技术标准TS 23.501V0.3.1(2017年3月)的第5.3.5条款。这可以包括,如果N6路由信息是PCC规则的一部分,则向UPF提供业务转发(例如,分离)规则和关联的N6路由信息。该业务转发规则可以包括应用标识符和业务转向策略ID。应用程序标识符是指在UPF处配置的应用业务检测规则。在一个实施例中,应用程序头可以用于将应用标识符与应用业务检测规则相关联。

通知应用功能(重新)选择UP路径(例如,改变DNAI和PDU会话位置)。

SMF可以将UPF配置为报告应用业务的检测。根据该配置,在应用业务检测时,UPF向SMF通知应用标识符。SMF可以使用所报告的应用标识符和其他信息从PCF获得PCC 规则,以对PDU会话的业务路由应用AF影响。因此,SMF可以将配置应用于UPF,以基于与由报告的应用标识符所标识的AF相关联的规则和配置来配置业务处理策略。在一些实施例中,SMF可以重新选择新的UPF并配置新的UPF,用于处理应用业务。

在一些实施例中,当UE在建立PDU会话期间提供应用标识符时,SMF可被用于向 DN发送应用标识符。在一些实现中,SMF可被用于将应用标识符发送到DN的认证/授权实体。DN内的网络节点、实体或功能可被用于基于所接收的应用标识符执行应用特定的认证/授权。在替换实施例中,SMF不将应用标识符提供给DN内的网络节点、实体或功能作为输入。相反,DN内的网络节点、实体或功能向SMF返回应用标识符列表。在这种情况下,SMF必须验证UE针对应用程序提供的应用标识符。这些实施例的不同之处在于,将应用标识符提供给DN作为认证/授权过程的输入。结果,认证/授权可以是由DN返回的应用特定的标识符列表,以便提供应用特定的授权。

图4示出了在虚拟环境中应用重定位的场景,其中应用App-1(例如视频流应用)以三个步骤重新定位,例如,由于加载问题。第一步发生在DNAI-1内,并且对5GC是不可见的。5GC重新选择DNAI-2(从初始DNAI-1变化)以响应重定位步骤2,然后5GC重新选择关于应用重定位步骤3的UPF-2(从UPF-1变化)和DNAI-2(从DNAI-2变化)。第三步发生在数据中心-A和数据中心-B上。将应用功能移动到第二数据中心是可以触发 UPF重选的事件。

下面讨论用于触发UPF/DNAI重选的两个实施例。

在第一个实施例中,在没有业务路由上的AF影响的情况下使用DNAI。在这种情况下,可以在检测到UPF处或DN中的应用业务之后实现针对业务路由(即UPF重选/业务转向重新配置)的AF影响。也就是说,UPF或AF可以通过发送例如业务转向重选请求,来向控制面功能发送通知,以指示会话包含与应用相关联的数据业务(“应用业务检测”)。在一些实施例中,这可以由AF向SMF发送请求或通知,可选地通过与NEF的交互来执行。在其他示例中,UPF可以发送请求或通知,以响应在通过UPF的DN接入中具有应用功能的会话中业务的检测。响应于业务转向重选请求的接收,控制面实体可以请求或调用业务转向重选过程(有时称为“触发”业务转向重选)。在一些实施例中,AF还可以向控制面的控制面实体发送UPF重选请求以重新选择UPF(有时称为“触发”UPF重选)。因此,端到端路径效率仅应用于与PDU会话相关联的业务的一部分。

在第二个实施例中,在业务路由有AF影响的情况下使用DNAI。在该实施例中,UE向SMF提供应用标识符作为会话请求的一部分。该应用标识符可以与PDU会话标识符相关联,指示PDU会话旨在用于或专用于与应用相关联的业务。该标识符可以用于向UP 路径中的功能指示应该应用的特定的业务处理策略或规则,或特定的业务路由策略。这允许控制面功能通过发送业务处理策略来配置UPF功能,该业务处理策略指示应当如何处理具有特定标识符的任何或所有业务流。例如,可以定义业务路由策略,以确保与PDU 会话相关联的数据业务通过CN朝向或远离与应用程序相关联的DN,通过定义路径被路由。

因此,从重定位过程的最开始就可以向应用业务提供端到端路径效率。在一些实施例中,如果UE使用对所识别的应用和另一个应用都相同的PDU会话,则UP路径对于其他应用可能不是最佳有效的。在这些情况下,在检测到与其他应用程序相关的应用业务之后,可以实现改进的路径效率。在一些这样的实施例中,UPF或AF可以确定会话包含与另一个应用(或应用功能)相关联的业务,并且可以向控制面功能(例如SMF)通知检测到的应用业务以触发如第一个实施例中所述的,用于重新选择业务转向的控制面功能。

作为示例,当UE想要访问对端到端路径效率有严格要求的本地DN中的应用时,可以应用第二实施例。例如,第一个实施例可以应用于其他场景中(即,当应用程序的端到端路径效率要求低于预定阈值时)。

当UE提供应用标识符时,SMF可以发起第三方认证/授权,以使用针对应用的PDU会话。第三方认证/授权可能是有用的,因为可以根据应用标识符将应用特定的UP管理应用于PDU会话。该第三方认证/授权可以避免从UE接收的信息(例如,应用标识符)不能依赖的情况。例如,TS23.501,5.6.6中描述的第三方认证/授权机制使用用户面进行信息交换或SMF与第三方认证/授权功能之间的通信。在一个实施例中,本申请提出扩展该机制,以允许经由NEF(其可以允许第三方认证/授权,在扩展控制面中执行)执行第三方认证/授权。通过允许通过NEF进行访问,根据所提供的访问级别,第三方认证/授权功能能够执行与AF等同的功能。该实施例提供附加功能以支持第三方认证/授权功能不在 DN中的情况。在一种实现中,NEF提供接口和功能以向第三方认证/授权功能提供充当 AF的能力。

在建立到DN的PDU会话时:

-在一些实施例中,UE可以由第三方认证/授权,第三方可以位于DN中,例如, DN-AAA服务器。

如果UE在PDU会话的建立期间提供认证/授权信息,并且SMF根据DN策略或本地配置确定需要对PDU会话的建立进行第三方认证/授权,则SMF将UE的认证/授权信息传递给第三方。在一个实施例中,如果第三方位于DN中,则可以通过UPF将该信息传递给DN中的第三方。在一个实施例中,如果第三方不在DN中,则可以经由 NEF将信息传递给第三方。使用NEF时,第三方可以表现为AF。如果SMF确定需要对PDU会话建立的第三方认证/授权但是UE没有提供认证/授权信息,则SMF可以拒绝PDU会话建立。

在一种实现中,第三方可以认证/授权PDU会话建立,并通过UPF将认证/授权结果返回给SMF。在一种实现中,第三方可以认证/授权PDU会话建立,并通过NEF将认证/ 授权结果返回给SMF。

如果UE在建立PDU会话期间向SMF提供应用标识符,则SMF可以将应用标识符传递给第三方。该第三方可以根据应用标识符执行应用特定的认证/授权。

SMF可以根据DN策略、根据DN策略的授权、本地配置以及UE提供的应用标识符来确定是将UPF还是NEF用于至少一个第三方认证。

除了以下情况之外,至少一个DN认证和授权的发生是用于PDU会话授权的目的:

由AMF处理的5GC访问认证(在一个实施例中,可以根据TS 23.501的条款5.2中描述的方法来执行认证)。

与SMF强制从UDM检索的订阅数据有关的PDU会话授权。

基于本地策略,SMF可以发起DN认证和授权中的至少一个作为PDU会话建立的一部分。

如果UE在PDU会话的建立期间提供应用标识符,并且如果UPF被用于第三方认证/授权,则可以根据应用标识符来配置UPF处的业务转向。如果UE在建立PDU会话期间提供应用标识符,并且如果NEF被用于第三方认证/授权,则SMF将DNN、S-NSSAI和应用标识符发送给NEF,此时NEF可以根据SMF发送的信息(例如,接收到的DNN、 S-NSSAI和应用标识符)选择AF(例如第三方认证/授权功能)。

UE可以通过NAS提供支持第三方进行用户认证所需的SM信息。

在一些实施例中,当SMF将PDU会话锚(诸如TS 23.501的条款5.6.4中定义的PDU会话锚)添加到PDU会话时,可以不执行第三方认证和/或授权。在一些实施例中,SMF 策略可能要求SMF在已经将新IP地址添加到PDU会话或从PDU会话移除时,或者当与会话相关联的现有ID地址通过前缀的修改或替换被更改时通知第三方。

PDU会话建立拒绝的指示可以经由NAS SM,由SMF发送到UE。

在一些实施例中,第三方可以撤销对PDU会话的授权。在一些实施例中,第三方可以在任何时间点撤销对PDU会话的授权。

参见图5,给出信令图以示出AS位置或重定位通知的实施例。

在步骤500中,NEF 314从AS控制器332接收基于应用程序接口(API)的AS位置或重定位通知。在图中,术语(重新)定位指的是位置通知或重定位通知。类似地,术语(重新)选择指的是选择或重选,其具体指示视情况而定。

该通知可以包括适合在其中使用的AS位置,并且可以根据具体情况在UP选择或重选期间考虑该AS位置。在对现有会话进行AS重定位的情况下,通知可以指示从该点开始使用的新的AS位置。该通知可能包含以下部分或全部特征:

AS位置,其可以使用诸如IP地址、MAC地址或一些其他类型的识别信息的已知地址的网络地址来指定。

业务转向指示符,其指示从UP 326到AS业务转向应该被CP配置,还是被AS网络334处理。

时间信息,其指示何时应用AS(重新)定位。在一个非限制性实施例中,时间信息为空,这意味着AS(重新)定位立即进行。

UE位置信息,其指示当UE 102存在于指定位置(例如,地理位置)内时,应用AS (重新)定位。在一个非限制性实施例中,位置信息为空,这意味着AS(重新)定位在不考虑UE位置的情况下进行。

业务过滤器,其指示AS(重新)定位可能应用的业务。该业务可以属于正在进行的PDU会话(正在进行的业务)或未来的PDU会话(未来的业务)。业务过滤器包括应用指示符,其指示与业务相关联的应用;以及UE指示符,其标识与业务相关联的UE 5。

UE指示符可以是与业务相关联的IP地址。在这种情况下,该业务是正在进行的业务,并且AS控制器332从AS获知IP地址。UE指示符还可以由CP 328分配,并通过NEF 314 暴露给AS控制器332的UE ID。在这种情况下,业务可以包括正在进行的业务和未来业务。

可选地,UE指示符指示多于一个UE 102。此外,业务过滤器可能不包括任何UE指示符,这意味着AS(重新)定位应用于满足业务过滤器定义标准的任何(即所有)UE 102 的业务。

在一种实现中,所接收的位置信息可以包括地理位置。NEF 314可以被用于将接收的地理位置转换为与网络拓扑相关联的位置,例如相应的小区ID,并且将小区ID作为UE 位置通过AS(重新)定位转发到SMF 310或PCF 314。在一个实现中,NEF 314可以被用于将地理位置作为UE位置转发到SMF 310或PCF 314。

接下来,在步骤502中,如果AS控制器332不位于可信域中,则NEF 314向认证服务功能(AUSF)312发送认证请求。如果AS控制器332在基于API的AS(重新)定位通知步骤500中提供AS控制器身份信息,则认证请求可以包括AS控制器332的身份信息。

在可选步骤504中(用虚线示出),AUSF 312获得AS控制器332的身份。如果步骤502中的认证请求不包括AS控制器身份,则执行步骤504。

在步骤506中,AUSF 314认证AS控制器332并向NEF 314发送认证响应。该认证响应指示认证结果。

如果认证成功,则NEF 314确认该通知并执行下一步骤,这些步骤是基于AS重定位是应用于正在进行的业务还是应用于将来的PDU会话而确定的。

在一种实现中,该过程仅包括过程508(用于正在进行的PDU会话的AS重定位)和过程510(用于未来PDU会话的AS(重新)定位)之一。在一个实现中,不使用过程508,并且过程510被实现,用于正在进行的PDU会话、未来PDU会话或正在进行的和未来的 PDU会话的组合的AS重定位。在针对正在进行的PDU会话实现过程510的情况下,PCF 314通过向SMF 310发送UP重选触发来触发SMF 310执行UP重选,以便为正在进行的 PDU会话重新选择相应的UP。在备选的实现中,不使用过程510而仅使用过程508。在该备选实现中,SMF 310被用于基于例如由NEF 314发送的AS重定位通知的接收来执行用于未来PDU会话的AS重定位。

通常,可以在AS重定位的情况下针对正在进行的PDU会话(即,正在进行的数据业务)执行过程508。首先,NEF 314识别与业务相关联的PDU会话,并且SMF 310管理所识别的PDU会话,生成基于基于API的AS重定位通知的AS重定位通知,并且在步骤512中,将AS重定位通知发送到所识别的SMF 310。在一个实现中,NEF 314可以通过与网络功能存储库功能(NRF)318进行交互来识别SMF 310。

在接收到AS重定位通知之后,SMF 310可以根据PDU会话的新AS位置、运营商策略以及会话和服务连续性(SSC)模式来确定是否对受影响的业务执行UP重选。

在步骤514A中,如果SMF 10确定不需要UP重选,并且如果AS重定位通知指示业务转向配置的需要,则SMF 310通过更新UP GW 336处的业务转向来配置业务转向。或者,在步骤514B中,如果SMF 310确定需要UP重选,则SMF 310发起UP重选过程。如果需要,SMF 310还可以在重新选择的UP GW 336处配置业务转向。

通常,在AS(重新)位置应用于未来业务的情况下执行过程510。在步骤516中, NEF314识别负责针对未来业务的运营商策略的策略控制功能(PCF)314,生成基于基于 API的AS(重新)定位请求的AS(重新)定位通知,并发送AS(重新)定位通知到PCF 314。NEF 314可以通过与NRF 318进行交互来识别PCF 314。在可选步骤518中,PCF 314 配置与UP GW 336的业务转向。在实现中,配置可以是应用于可能潜在地用于支持所请求的PDU会话(当前或将来)的所有UP GW 336。具体地,基于AS(重新)定位通知,订阅数据和当前运营商策略,PCF314可以生成用于业务的UP选择策略和业务转向策略。在实现中,不执行可选步骤518,因为可以在UP(重新)选择期间(即步骤514或516)单独配置业务转向。

在一个实施例中,其中AS(重新)定位通知指示未来AS重定位的可能性,PCF 314可以生成会话和服务连续性(SSC)模式选择策略,例如,任何与应用程序关联的PDU 会话应具有不等于1的SSC模式。

如本领域技术人员将容易理解的,存在AS(重新)定位可能影响正在进行的业务流和未来业务流的情况。在这种情况下,可以进行过程508和过程510。

在步骤520中,NEF 314将基于API的AS(重新)定位通知确认发送回AS控制器 332,或者确认AS(重新)定位通知的接收,或者拒绝AS(重新)定位通知。在拒绝的情况下,该消息包括指示拒绝原因的错误代码。在实现中,响应包括标识AS(重新)定位通知的交易令牌。AS控制器332可以使用该交易令牌来稍后更新AS(重新)定位通知,而无需提供完整细节和请求被AS(重新)定位通知影响的UP(重新)选择的至少一个。

图6示出了UP(重新)选择通知请求过程。在步骤600中,NEF 314从AS控制器 332接收基于API的UP(重新)选择通知请求。该基于API的UP(重新)选择通知请求可以包括来自先前AS(重新)定位通知过程的交易令牌。该令牌可以指示当前请求对应于受AS(重新)定位通知影响的任何UP(重新)选择过程。或者,该请求可能包括以下的部分或全部信息:

时间信息,指示通知请求何时适用。时间信息可以是为空,表示通知请求立即进行。 UE位置信息,指示当UE 5存在于指定位置(例如,地理位置)时应用通知请求。UE位

置信息可以为空,指示通知请求继续而不关心UE位置。

业务过滤器,指示可以应用通知请求的数据业务。该业务可以属于正在进行的PDU会话(正在进行的业务)或未来的PDU会话(未来业务)。业务过滤器还可以包括指示与数据业务相关联的指定应用的应用指示符。

业务过滤器可选地包括UE指示符,其指示与数据业务相关联的UE 102。UE指示符可以是与数据业务相关联的IP地址。在这种情况下,数据业务是正在进行的业务,并且 AS控制器332从AS获知IP地址。UE指示符还可以是由CN CP 328分配并暴露给AS 控制器332的UE的ID。在这种情况下,数据业务可以包括正在进行的业务和未来业务。 UE指示符可以指示不止一个UE 102。当业务过滤器不包括UE指示符时,它指示通知请求适用于满足由业务过滤器定义的标准的任何UE 102的数据业务。

在接收到基于API的UP(重新)选择通知请求之后,在步骤602中,如果AS控制器332不位于可信域中,则NEF 314向AUSF 312发送认证请求。如果在基于API的UP (重新)选择通知请求中,由AS控制器332提供信息,则认证请求可以包括AS控制器 332的识别信息。

在可选步骤604中,AUSF 312获得AS控制器332的身份。如果认证请求602不包括AS控制器332的标识信息,则执行该步骤。

在步骤606中,AUSF 312对AS控制器332进行认证,并向NEF 314发送指示认证结果的认证响应。

应当注意,如果基于API的UP(重新)选择通知请求包括交易令牌,则认证请求、获得标识和认证响应步骤中的每一个是可选的。

在步骤608中,NEF 314生成基于基于API的UP(重新)选择通知请求的UP(重新)选择通知请求,并将其发送到PCF 314。PCF 314可以验证该请求,并且如果请求有效,则PCF314可以基于所接收的UP(重新)选择通知请求来生成UP(重新)选择通知策略。在可选步骤610中,PCF 314可以向NEF 314发送UP(重新)选择认证响应,以指示验证结果。

在步骤612中,NEF 314将基于API的UP(重新)定位通知响应发送回AS控制器 332,或确认AS(重新)定位通知的接收,或者拒绝AS(重新)定位通知。在拒绝的情况下,该消息包括指示拒绝原因的错误代码。在实现中,响应包括标识AS(重新)定位通知的事务令牌。AS控制器332可以使用该交易令牌来稍后更新AS(重新)定位通知,而无需提供完整细节和请求被AS(重新)定位通知影响的UP(重新)选择通知中的至少一个。

图7示出了UP(重新)选择通知过程。如果在执行UP(重新)选择之后,UP(重新)选择通知作为UP(重新)选择通知请求过程的结果被需要(例如,如上所述),则 SMF 310发起UP(重新)选择通知过程。

在步骤700中,SMF 310向NEF 314发送UP(重新)选择通知。该UP(重新)选择通知可以包括相应的UP(重新)选择通知请求的事务令牌、AS位置的指示、以及UP GW 336的位置的指示中的至少一个。例如,位置信息可以是网络地址的形式。

在步骤702中,NEF 314基于UP(重新)选择通知生成基于API的UP(重新)选择通知,并将其发送到AS控制器332。AS控制器332向NEF 314传送收到基于API的UP (重新)选择通知的确认。在发送确认之前,AS控制器332可以执行AS(重新)定位或 AS状态(重新)定位过程的必要步骤,其可以包括释放资源和数据结构,配置业务控制等。

在步骤704中,NEF 314向SMF 310发送UP(重新)选择通知确认,确认接收到从 AS控制器332接收的基于API的UP(重新)选择通知确认。

图8示出了用于应用友好型PDU会话建立的过程。在步骤800中,AS控制器332利用CP 328发起用于与UE 102相关联的未来业务的AS(重新)定位通知过程,针对生成应用感知UP选择策略和业务转向策略的指定应用程序。

在步骤802中,AS控制器332还利用CP 328发起用于与UE 102相关联的未来业务的UP(重新)位置通知请求过程,针对生成应用感知UP选择策略和业务转向政策的指定应用。

在过程804中,UE 102可以在其具有要从应用发送或从应用接收的应用业务时,发起会话建立过程。在步骤806中,UE 102经由核心接入和移动性管理功能(AMF)308 向SMF310发送会话请求。该会话请求可以包括会话ID和优选SSC模式(可选)。会话请求还可以包括应用标识符,该应用标识符指示它是应用的专用会话请求。在步骤808中, SMF 310利用UDM 320验证UE上下文,并根据用户订阅数据授权会话请求。

如果会话请求被授权,则SMF 310发起UP选择过程810。在第一个步骤812中,SMF310从PCF 314获得运营商策略,包括由AS(重新)定位通知步骤800产生的应用友好策略。在可选步骤814中,SMF 310根据会话请求、运营商策略、UE类型和其他必要信息为PDU会话选择SSC模式。例如,如果请求包括应用标识符但没有优选的SSC模式,并且如果运营商策略指示潜在的未来AS重定位,则SMF 310可以将PDU会话的SSC模式设置为2或3,以允许用于有效的端到端路径的UP重选。

在步骤816中,SMF 310与UDM 320交互以获得候选UP GW 336与AS位置之间的业务转向能力,并基于由UDM 320提供的信息选择关于运营商策略的PDU会话的UP路径。在步骤818,SMF 310触发UP设置,并且如果运营商策略指示需要业务转向配置,则配置UP GW 336处的业务转向。

在步骤820中,SMF 310将连接建立请求发送到AN 302以连接到UP 326。在该步骤中,AN 302可以为PDU会话分配RAN资源。

如果运营商策略指示需要UP(重新)选择通知,则在步骤822,SMF 310通过UP选择通知过程向AS控制器332通知UP选择。

在步骤824中,SMF 310经由AMF 308向UE 102发送PDU会话请求响应。如果UE 102未在会话请求中提供优选SSC模式,则该响应包括为PDU会话选择的SSC模式。在步骤826中,经由UP GW 336从UE 102发生业务传输。

图9示出了用于PDU会话修改的应用感知UP重选过程。在该过程中,在步骤900 中,UE 102包括经由UP-A 326A承载应用业务的已建立PDU会话。如图9所示,应用业务传输902是通过UP-A 326A。

SMF 310接收针对由PDU会话承载的应用业务的UP重选的触发。该触发可以来自:AS重定位通知过程904,指示新的AS位置;切换过程906,指示新的服务AN;或者来自PCF 314的策略触发器908,指示影响PDU会话的UP选择的策略改变。

响应于接收到触发,在步骤910中,SMF 310经由AMF 308向UE 102发送会话重定向消息。如果建立的PDU会话将根据SSC模式配置被预先服务或重新使用,则该步骤是可选的。

在步骤912中,UE 102响应于接收的会话重定向,发送用于建立新会话的会话请求。注意,该步骤也是可选的,因为它仅在从SMF 310接收到会话重定向消息时才发生。

在步骤914中,SMF 310使用UP(重新)选择过程为应用业务建立UP-B 326B。步骤914类似于图7中所示且如上所述的UP选择过程。

在步骤912是可选的情况下,如果PDU会话不是用于应用程序的专用PDU会话,并且具有为3的SSC模式,则SMF 310可以将分支点插入到UP路径中,使得UP-A 326A 和UP-B326B是UP路径的两个分支。SMF 310指示分支点将与应用程序相关联的业务转向到UP-B326B,例如,根据目的地址或目的地址和端口号的组合。

在步骤916中,SMF 310经由AMF 308向UE 102发送会话响应,以关闭在步骤912 中发送的会话请求。如果正在进行的PDU会话不是用于应用程序的专用PDU会话并且具有为3的SSC模式,响应应指示要重定向到新PDU会话的应用业务,例如,通过目的地址或目的地址和端口号的组合)。UE 102将根据会话响应中的重定向指示来执行业务的重定向。

在步骤918中,SMF 310建立针对剩余业务的从UP-A 326A到UP-B 326B的业务重定向。在步骤920中,现在通过UP-B 326B继续未来的应用业务。

在实施例中,提供了一种用于边缘计算的影响应用的SSC和UP管理的系统和方法。在该实施例中,假设应用程序(即AS)部署在运营商的本地网络,即本地DN中。

参见图10,应用功能(AF)324(非3GPP功能)负责本地DN内的AS(重新)位置(或AS(重新)选择)。应用功能324通过NEF 314与CP 328交互。该应用功能324 的行为以及应用或应用上下文的实际重定位尚未在当前标准下定义,并且与本申请无关。

CN CP 328具有关于UPF 304与AS位置之间的业务转向能力的信息。该信息由网络管理组件提供,例如管理面330中的网络管理器,并由NEF 314用于确定UPF 304对应用的适合性或偏好。

SMF 310负责配置UPF 304处的业务转向,以在面对AS(重新)定位时将UL业务路由到适当的AS位置。

本地DN负责在面对UP(重新)选择时将DL业务转向至适当的UPF 304。该UPF 304将与DL业务相关联的UE IP地址识别为有效IP地址。为了确保UPF 304识别UE IP地址,在一些实施例中,每个UPF 304可以使用相同的私有IP地址空间。

DL业务转向可以由应用功能324配置,或者通过本地DN内的上层移动性管理机制来实现。UPF 304可以将DL业务中的UE IP地址识别为有效标识符。这可以通过例如在 UPF304处应用相同的私有IP地址空间来实现。如上所述,在不使用IP寻址的实施例中,可以采用其他地址类型或标识符。用于转向DL的业务的本地DN的行为与以下讨论没有密切关系。

图10中由虚线标记的接口尚未在现有的标准下被定义,并且如何构建它与以下讨论没有密切关系。

该部分描述了CP 328和应用功能324之间必要的交互,以便为需要有效端到端路径的应用启用应用友好的UP管理。

在该示例实施例中,假设NEF 314鉴定并确认了从应用功能324接收的信息。如本领域技术人员将理解的,该责任可以被移动到具有控制信令中相应变更的另一功能中。

参照图11A,给出了信令图以示出由SMF 310执行作为会话建立一部分的受应用影响的UP选择的实施例。在步骤1100中,应用功能通过NEF 314的“应用(重新)定位通知”服务的过程向网络通知与UE 102相关联的未来应用业务的应用位置,其中UP选择策略和业务转向规则由PCF 314生成。在一种实现中,NEF 314的应用(重新)定位通知服务的过程可以使用任何数量的不同方法来实现,这些方法包括本申请中其他地方描述的那些方法中的一些。

在步骤1102中,应用功能324可以通过NEF 314的“UP(重新)选择通知”服务的过程(部分1)订阅针对与UE 102相关联的未来应用业务的UP 326(重新)选择通知,其中UP(重新)选择通知策略由PCF 314生成。在实现中,可以实现NEF 314的“UP(重新)选择通知”服务的过程。步骤1102是可选步骤,其可以由应用功能324确定。在一些实现中,步骤1100和1102可以彼此独立地操作。

在步骤1104中,UE 102向SMF 310发送会话请求,其包括本地DN标识符。该请求可以包括应用标识符,指示它是应用的专用PDU会话。本地DN标识符和应用标识符可以是集成标识符(作为本地DN标识符或应用标识符)的两个部分,或者是两个单独的标识符。

在步骤1106中,SMF 310验证UE上下文,并根据用户订阅数据授权会话请求。在步骤1108中,SMF 310从PCF 314获得运营商策略,包括由步骤1100和1102产生的受应用影响的UP管理策略。在步骤1110中,SMF 310根据会话请求、运营商策略、UE类型和其他必要信息为PDU会话选择SSC模式。如果会话请求包括应用标识符,并且如果运营商策略指示应用移动性(即,潜在的应用重定位),则SMF 310可以为PDU会话选择SSC模式2。如果会话请求不包括应用标识符,并且如果运营商策略指示潜在的UE访问的应用具有移动性,则SMF 310可以为PDU会话选择SSC模式3。

在步骤1112中,SMF 310可以为与运营商策略有关的PDU会话选择端到端UP路径。UP 326中的该端到端路径可以包括为PDU会话选择的应用位置。

在步骤1114中,SMF 310请求AN 302建立N3连接。在可选步骤1116中,AN 302 可以为PDU会话分配RAN资源。

在步骤1118中,AN 302响应SMF 310,指示N3连接建立的完成。

在步骤1120中,SMF 310建立UP路径。在步骤1122中,SMF 310可以在UP 326 的锚UPF 304处的N6接口上配置业务转向。在一些实施例中,步骤1120和1122可以在单个集成配置步骤中组合,其中UP设置和业务转向配置被一起执行。

在步骤1124中,SMF 310可以通过NEF 314的“UP(重新)选择通知”服务的过程(部分2)向应用功能324通知端到端UP路径选择。该通知指示PDU会话位置和应用程序位置。在一些实施例中,PDU会话位置可以用作锚UPF IP地址。在其他实施例中,UE IP地址可以用于PDU会话位置。如果步骤1102不存在或者步骤1102没有指示UP(重新)选择发布通知的需求,则步骤1124是可选的。

在步骤1126中,SMF 310经由AMF 308向UE 102发送会话响应。执行PDU会话建立的方式可以在不同的实现中变化。本领域技术人员将理解,该程序可以进行标准化,并且这种程序的细节不一定与本申请密切相关。

图11B示出了包括附加可选步骤1128的替代实施例。在步骤1128中,SMF 310通过NEF 314的“UP(重新)选择通知”服务过程(部分2)向应用功能324通知端到端UP 路径选择。该通知指示PDU会话位置和应用位置。在一些实施例中,PDU会话位置是锚 UPF的IP地址。在其他实施例中,UE的IP地址可以用作PDU会话位置。步骤1128是可选的预先通知步骤,例如,如果步骤1102不存在或者如果步骤1102未指示UP(重新)选择预通知的需求。

图12A和12B是示出受应用影响的UP重选过程实施例的信令图。该过程不改变UE的IP地址,因此对UE 102是透明的。图12A和12B的实施例假设UE 102已经通过UP-A 326A具有建立的PDU会话。

参照图12A,在步骤1200中,应用功能324通过NEF的“UP(重新)选择通知”服务过程(部分1)针对与PDU会话相关联的应用业务订阅来自网络的UP(重新)选择通知。步骤1200是可选的,取决于应用功能324的要求。

在步骤1202中,UE 102和UP-A 326A之间的业务传输可以继续。

在步骤1204中,应用功能324可以通过NEF 314的“应用(重新)定位通知”服务过程向网络通知应用重定位。步骤1200和1204可以彼此独立。网络的通知可以包括应用功能324向一个或多个网络节点发送通知消息,该网络节点又可以反过来向核心网络功能提供应用功能324无法访问的通知。

当必要或期望时,SMF 310可以根据应用重定位和本地策略来修改端到端UP路径。

在过程1206中,SMF 310修改需要UP重选的端到端UP路径。在步骤128中,SMF 310为PDU会话重新选择UP-B 326B和业务转向(通过N6接口)。如果PDU会话的SSC 模式为2,则选择UP-B 326B以替换UP-A 326A。如果PDU会话的SSC模式是3,则SMF 310将分支UPF或ULCL UPF插入到UP路径中,使得UP-A 326A和UP-B 326B是UP 路径的两个分支。

在步骤1210中,SMF 310通过NEF的“UP(重新)选择通知”服务过程(部分2)向应用功能324通知UP重选。如果步骤1200不存在,或者如果已经通知应用功能324 关于具有相同内容的UP(重新)选择,则步骤1210是可选的。

在步骤1212中,SMF 310根据UP重选决定来修改端到端UP路径。这可以使用许多不同方法中的任意种来进行。可以对这种方法的细节进行标准化,例如当前标准的条款4.3.5.X.2的步骤8-11中所描述的。在步骤1212中,可以修改N3连接,分支UPF或UL CL UPF(如果有的话)可以被配置为将应用业务转向至UP-B 326B,UP-B的锚定UPF处的 N6接口(业务转向)也被配置。分支UPF或UL CL UPF处的业务转向可以基于目的IP 地址、目的端口号、源IP地址或它们中的任何组合。

在步骤1214中,SMF 310在不需要UP重选的情况下重新配置业务转向。SMF 310 在UP-A 326A的锚UPF处重新配置N6接口,以便将应用业务转向至新的应用位置。

在步骤1216中,UE 102和UP-B 326B之间的业务传输可以继续进行。

在步骤1218中,如果发生步骤1206并且PDU会话的SSC模式是2,则SMF 310释放与UP-A 326A相关的PDU会话资源。

参照图12B,在替换实施例中,来自图12A的步骤1200可以在1204之后被执行。在步骤1220中,UE 102和UP-A 326A之间的业务传输可以继续。

在步骤1222中,应用功能324通过NEF 314的“应用(重新)定位通知”服务过程向网络通知应用重定位。步骤1200和1222可以彼此独立。

在步骤1224中,应用功能324通过NEF 314的“UP(重新)选择通知”服务过程(部分1),从与PDU会话相关的应用业务的网络中订阅UP(重新)选择通知。步骤1224 是可选的,取决于应用功能324的要求。

在步骤1226中,SMF 310根据应用重定位和本地策略执行端到端UP路径重选,其包括UP重选和应用位置重选中的至少一个。

在步骤1228中,SMF 310重新选择PDU会话的端到端UP路径。如果需要UP重选,则SMF 310为PDU会话重新选择UP-B 326B。如果PDU会话的SSC模式是2,则选择 UP-B 326B以替换UP-A 326A。如果PDU会话的SSC模式是3,则SMF 310将分支UPF 或UL CL UPF插入到UP路径中,使得UP-A 326A和UP-B 326B是UP路径的两个分支。

在步骤1230中,SMF 310通过NEF 314的“UP(重新)选择通知”服务过程(部分 2)向应用功能324通知端到端UP路径重选。该通知指示锚UPF位置和新的应用程序位置。此步骤是预通知步骤。如果步骤1224不存在或者如果步骤1224未指示UP(重新)选择预通知的需求,则它是可选的。

在步骤1232中,SMF 310根据步骤1228的决定修改端到端UP路径。在为PDU会话选择UP-B 326B的情况下,SMF 310修改端到端UP路径,如当前标准的条款4.3.5.X.2 中的步骤8-11所述。在步骤1232中,修改N3连接,分支UPF或UL CL UPF(如果有的话)被配置为将应用业务转向至UP-B 326B,在UP-B 326B的锚UPF处N6接口(即,业务转向)也被配置。分支UPF或UL CL UPF处的业务转向可以基于目的IP地址、目的端口号、源IP地址或它们中的任何组合。

在不需要UP重选的情况下,在步骤1234中,SMF 310在UP-A 326A的锚UPF处重新配置N6接口,以便将应用业务转向至新的应用位置。

在步骤1236中,SMF 310通过NEF 314的“UP(重新)选择通知”服务过程(部分 2)向应用功能324通知端到端UP路径重选。步骤1236是通知后步骤。如果步骤1224 不存在或者如果步骤1224没有指示通知后的UP(重新)选择需求,则它是可选的。

在步骤1216中,UE 102和UP-B 326B之间的业务传输可以继续。

在步骤1240,如果PDU会话的SSC模式是2,并且在步骤1228中为PDU会话选择 UP-B,则SMF 310释放与UP-A 326A相关的PDU会话资源。

图13是示出应用(重新)定位通知服务过程实施例的信令图。

在步骤1300中,NEF 310从应用功能324接收应用(重新)定位通知请求(应用标识符、应用位置信息、时间有效性条件、空间有效性条件、业务过滤器、请求者信息)消息。应用位置信息指示(新)应用程序位置和(新)应用程序位置的状态。应用程序位置被指定使用IP地址。时间有效性条件指示通知的应用(重新)定位何时进行。无效的时间有效性条件意味着应用(重新)定位立即进行。空间有效性条件指示应用(重新)定位仅适用于与位于指定位置内的UE相关联的业务。空间有效性条件的无效意味着应用所通知的应用(重新)定位而不关心UE位置。

业务过滤器指示应用(重新)选择适用的业务,其可以属于正在进行的PDU会话或未来的PDU会话。业务过滤器无效意味着应用程序(重新)选择适用于与应用程序关联的所有业务。

业务过滤器可以明确地指示业务是否包括正在进行的业务和未来业务中的至少一个。可以使用与业务相关联的IP地址来描述业务过滤器。还可以使用由应用功能和网络共同识别的UE ID来描述它。请求者信息包括请求者标识符。

NEF 314将应用(重新)定位通知给所选择的CP功能,即SMF 310或PCF 314。该通知包括应用(重新)定位通知服务交易标识符,应用标识符,(新)应用位置,适合于为(新)应用位置中的每一个的选择的锚UPF的标识符,以及时间和空间有效性条件,业务过滤器。取决于空间有效性条件中的位置信息的性质,NEF 314可能需要将位置信息转换为CP功能可理解的信息。业务过滤器可以是使用PDU会话标识符描述的转换业务过滤器。NEF 314根据UPF与通知的应用位置之间的业务转向能力确定适合于选择的锚 UPF,其由管理面提供。

在过程1302中,通知涉及受影响的业务仅属于正在进行的PDU会话的情况。在步骤1304中,NEF 314识别与受影响的业务,以及管理PDU会话的SMF 310相关联的PDU 会话,并将该通知发送到SMF 310。NEF 314通过与UDM 320进行交互来识别SMF 310。在步骤1306中,SMF确认NEF的通知的接收。

在过程1308中,通知可以指示受影响的业务属于未来的PDU会话(并且还可能属于正在进行的PDU会话)。在步骤1310中,NEF 314识别负责PDU会话的运营商策略的 PCF 314,并将该通知发送到PCF 314。NEF 314通过与NRF 318和UDM 320中的至少一个进行交互来识别PCF 314。在步骤1312中,PCF 314向NEF 314确认通知的接收。在步骤1314中,PCF 314根据通知生成或更新UP管理策略。如果受影响的业务属于正在进行的PDU会话,则在步骤1314中,PCF 314识别业务服务的SMF 310并且向SMF 310通知策略的变更。在步骤1318中,SMF310从PCF 314获得策略更新。

在步骤1320中,NEF 314向应用功能324发送应用(重新)定位通知响应(结果代码)消息。该结果代码指示请求的接收或者拒绝。

图14是示出UP(重新)选择通知订阅服务的实施例的信令图。

在步骤1402中,NEF 314从应用功能324接收UP(重新)选择通知订阅请求([交易标识符]或[应用标识符,时间有效性条件,空间有效性条件,业务过滤器],通知类型,请求者信息])消息。

备选方案A[交易标识符]:订阅请求对应于现有的应用(重新)定位通知服务交易。该现有应用(重新)定位通知服务交易的交易标识符,指示该订阅请求适用于受现有应用(重新)定位通知服务交易影响的任何UP(重新)选择。NEF 314可以通过验证交易标识符来执行简化的认证和确认。

备选方案B[应用程序标识符,时间有效性条件,空间有效性条件,业务过滤器,请求者信息]:订阅请求独立于现有的应用(重新)定位通知服务交易。时间有效性条件指示订阅何时可能有效。时间有效性条件无效意味着订阅立即生效。空间有效性条件指示订阅仅对位于指定位置内的UE的业务有效。空间有效性条件的无效意味着订阅在不关心 UE位置的情况下变得有效。业务过滤器指示订阅可以应用的业务,其可以属于正在进行的PDU会话或未来的PDU会话。业务过滤器无效意味着订阅适用于与应用程序关联的所有业务。业务过滤器可以明确地指示业务是否包括正在进行的业务和未来业务中的至少一个。可以使用与业务相关联的IP地址来描述业务过滤器。还可以使用由应用功能和网络同时识别的UE ID来描述它。通知类型指示预通知、后通知被请求,或预通知和后通知同时被请求。预通知意味着在配置端到端UP路径之前发送通知;后通知意味着在配置端到端路径之后发送通知。请求者信息可以包括:请求者标识符、请求者IP地址和请求者端口号。

NEF 314请求所选择的CP功能,即SMF 310或PCF 314,以设置UP(重新)选择通知。该请求可以包括除请求者信息之外的请求消息中的UP(重新)选择通知订阅服务事务标识符、NEF标识符以及订阅信息。取决于空间有效性条件中的位置信息的性质,NEF 314可能需要将位置信息转换为CP功能可理解的信息。业务过滤器可以是使用PDU会话标识符描述的转换的业务过滤器。

在过程1404中,受影响的业务仅属于正在进行的PDU会话。在步骤1406中,NEF 314识别与受影响的业务相关联的PDU而且SMF 310管理PDU会话,并且发送该请求给识别的SMF310。在步骤1408中,SMF 310响应于NEF 314,指示请求的接收。NEF 314 通过与UDM 320的交互识别SMF 310。

在过程1410中,受影响的业务属于未来的PDU会话(以及正在进行的PDU会话)。在步骤1412中,NEF 314识别负责与受影响的业务相关联的PDU会话的运营商策略的PCF 314,并将该请求发送到所识别的PCF 314。在步骤1414中,PCF 314响应NEF 314,表示请求的接收。NEF 314通过与NRF 318和UDM 320中的至少一个进行交互来识别PCF 314。在步骤1416中,PCF 314根据请求生成或更新UP管理策略。如果受影响的业务属于正在进行的PDU会话,则在步骤1418中,PCF 314识别服务SMF 310的业务并且向 SMF 310通知策略表更。在步骤1420中,SMF 310从PCF 314获得策略更新。

在步骤1422中,NEF 314向应用功能324发送UP(重新)选择订阅响应(结果代码)消息。该结果代码指示请求的接收或拒绝。

在对受影响的业务执行端到端UP(重新)选择之后,在步骤1424中,SMF 310向 NEF314通知UP(重新)选择。该通知可以包括诸如UP(重新)选择通知订阅服务交易标识符、通知类型、PDU会话位置、锚UPF位置和应用位置之类的信息。在一些实施例中,PDU会话位置可以是PDU会话的锚UPF地址或UE地址之一。在一些实施例中,这些地址是IP地址。应用信息可以是IP地址或另一个这样的标识符的形式。

在步骤1426中,NEF 314使用请求者IP地址和请求者端口号将UP(重新)选择信息发送到应用功能324。

在步骤1428中,应用功能324响应NEF 314以确认通知的传递。如果通知类型是预通知,则响应指示网络是否应继续端到端的路径配置。

在预先通知时,应用功能324可以执行应用(重新)定位或应用状态(重新)定位过程的必要步骤,其可以包括释放资源和数据结构等。如果应用功能324想要取消应用(重新)定位,应用功能324使用响应消息来通知网络。如果通知类型是后通知,则应用功能 324知道端到端UP路径准备好使用,并且可以开始将DL业务转向至路径。

在步骤1430中,NEF 314响应SMF 310以确认通知的传递。该响应包括在步骤1428中从应用功能324接收的信息。

在一些实施例中,应用功能可以影响业务路由。

关于要被路由其业务的UE的信息。

用于标识UE 102的信息可以是固定标识符或动态标识符。

固定标识符

在TS 23.501的条款5.9中描述的SUPI、PEI:由于边缘计算应用程序可能位于不可信域中,因此不应将这些标识符公开给第三方边缘计算应用程序。

MSISDN:可以用于第三方边缘计算

外部标识符:可以由运营商或边缘计算应用程序分配

动态标识符

临时标识符:在UE移动性注册过程期间分配

IP地址:在会话建立过程期间分配

以上两个标识符可用于标识具有活动PDU会话的UE 102。然而,由于UE移动性或UPF重选,这些标识符可以被改变。另外,PDU会话是非IP类型,则IP地址不适用。因此,这些动态标识符可能不适合于边缘计算应用。

提案1:外部标识符或MSISDN用于标识其业务将被路由的UE。

2用于UE组的标识符

在一些场景中,业务路由更新可以应用于一组UE。如果存在大量UE并且UE标识符被包括在从边缘计算应用程序发送到CN的消息中,则该消息应该会很大。应该提出一些替代方法。下面给出了一些可能的方法。

地理区域:PLMN的覆盖范围可以被划分为区域,每个区域具有区域标识符(zoneidentifier,ZID)。运营商可以向边缘计算应用程序通知地理位置和ZID之间的映射。无需标准化ZID。

IP前缀:可以为给定应用的UE组分配一系列IP地址。可以保留IP范围以指示UE组。但是,此解决方案不适用于非IP业务类型。

域网络名称(domain network name,DNN):每个边缘计算应用程序可以具有由CN识别的唯一名称。DNN可以指示可以访问DNN的UE。

应用标识符(application identifier,AID):如果DN提供多个应用,则每个应用可以具有应用标识符。该应用程序标识符可以由IP业务的应用程序服务器端口表示。

可以使用任何上述属性的组合来标识UE组。

提案2:DNN、AID和ZID的组合可用于标识一组UE。

3.关于在何处路由业务的信息:这可以是本地数据网络的DNN和应用服务器的IP地址中的任一个(或两者)。

提案3:本地数据网络的DNN或应用服务器的IP地址可用于指示路由目的地。

4.关于应该在何处应用业务路由的应用的潜在位置:应用的潜在位置可以是托管应用服务器的本地数据网络的DNN。

或者,可以使用应用服务器的IP地址。网络管理实体可以配置CP关于UPF和应用服务器之间的传输链路的能力。有单独的贡献来澄清这个问题。

提案4:本地数据网络的DNN或应用服务器的IP地址可用于指示用于业务路由的应用的潜在位置。

5.用于识别要被路由的业务的信息

一旦识别了UE 102,就可以使用附加信息来识别要被路由的业务。

DN提供1个应用程序:如果DN仅提供一个应用程序,则DNN可用于标识PDU会话。

DN提供多个应用程序:每个应用程序都应具有应用程序标识符(AID)。对于IP业务, AID可以是应用服务器的端口号。

提案5:如果DN提供一个边缘计算应用程序,则DNN可用于识别PDU会话。如果 DN提供多个应用程序,则每个DNN和AID用于标识PDU会话。

可以通过例如NEF或PCF的另一控制功能将应用功能请求路由到SMF。

a.在EPC中,PCRF和应用功能之间的Rx接口用于支持第三方应用程序:

示例:IMS和公共安全应用功能。

安全性:这些应用程序被认为位于3GPP可信域中。没有重大的安全问题。

通过Rx接口接收的信息被用于PCRF。这意味着PCRF处理接收到的信息以做出策略决策。

b.5G CN中的边缘计算应用程序安全性:边缘计算应用程序控制功能可能位于不可信域中。因此,应该验证和授权来自应

用程序控制功能的请求。目前商定的NEF机能包括认证/授权功能,但不包括PCF。对于边缘计算应用,来自应用控制功能的信息可以用于SMF以便可能重新选择UPF;PCF 不处理此信息。因此,应用程序控制功能不应将其请求发送到PCF。

提案6:NEF用作应用控制功能和CN CP功能之间的接口。

应用功能可以经由NEF发送请求以影响针对PDU会话业务的SMF路由决策。这可能会影响UPF选择,并允许将用户业务路由到数据网络本地接入。

此类请求可至少包含:

在一些实现中,请求可以包括用于标识要被路由的业务的信息。如果DN提供一个边缘计算应用程序,则DNN可用于识别PDU会话。如果DN提供多个应用程序,则DNN 和AID(应用程序标识符)用于标识PDU会话。

在一些实现中,应用服务器的端口号可以用作AID。有关在何处路由业务的信息。本地数据网络的DNN或应用服务器的IP地址可用于指示路由目的地。应该应用业务路由的应用潜在位置。本地数据网络的DNN或应用服务器的IP地址可用于指示用于业务路由的应用潜在位置。当应用程序功能是本地DN中托管的唯一应用功能时,或者如果没有混淆的机会,则DNN可以识别业务;否则,DNN和应用标识符或业务过滤信息的组合可用于识别应用业务。

注释1:可以在NEF中配置应用标识符和业务过滤信息(例如接收业务的应用功能的 IP地址)之间的映射。

-在一些实现中,请求可以包括关于在何处路由业务的信息,例如DNN(例如,如果PDU会话的所有业务被路由到应用功能)或者应用功能的IP地址。

-在一些实现中,请求可以包括应该应用业务路由的应用的潜在位置。可以使用处理AF业务的IP地址来指示AF的潜在位置,NEF(或者如果运营商信任的AF,如6.2.X 中所述)将其映射到指定PDU会话锚定到本地DN。

注释2:用于识别处理AF业务实例的IP地址可以与UE用于与其交互的相同AF实例的IP地址不同。

在一些实现中,请求可以包括关于其业务将被路由的UE的信息。可以使用外部标识符或 MSISDN来识别各个UE。UE组可以由DNN识别,它们具有活动PDU会话,可能还有应用标识符或业务过滤信息。另外,为了将UE组限制到特定地理区域内,还可以包括区域标识符。

注释3:区域标识符可以映射到地理区域。映射在NEF和AF中配置。外部标识符或MSISDN用于标识各个UE。DNN、AID(应用标识符)和ZID(区域标识符)或它们中任意个的组合可用于标识一组UE 在一些实现中,请求可以包括关于何时(时间指示)应用业务路由的信息。

假设发布这样请求的应用功能324属于服务于UE 102的PLMN。应用功能324可以代表不被服务于UE 102的PLMN拥有的其他应用发出请求。

SMF 310可能基于本地策略,将以下信息考虑进去:

PDU会话的(重新)选择UPF。

激活针对业务多归属或UL分类器(UL CL)实施的机制。这样的机制在子条款5.3.5中被

定义。它可以包括向UPF提供业务转发(例如突发)规则。通知UP路径(重新)选择功能。

根据本发明的特定实现,提供了用于业务路由的方法和系统,其中添加空间有效性条件作为AF提供的信息的一部分。

AF 324可以向CN内的一个或多个节点或功能提供信息,以影响包括用于边缘计算场景的UP路径(重新)选择决策。然而,通常考虑AF提供的信息是否与用于UP路径(重新)选择的CN中使用的信息相同,换句话说,是否需要信息映射/处理。下表比较了在需要和不需要映射/处理时的优缺点。

基于上表中提供的信息,一些实施例包括以下两个用于AF对业务路由影响的备选方案中的一个或两个:

(1)在AF 324经由NEF 314与核心网络功能交互的情况下,AF 324提供的信息和核心网络中使用的信息可以不同。在这样的实施例中,NEF 314可以被配置为执行信息处理/映射。

(2)在AF 324直接与核心网络功能交互的情况下,AF 324可以实现NEF的信息处理功能,并以可以在核心网络中使用的格式向CN功能提供信息。

在一些应用中,例如,包括事件监测应用或群众感测应用的MTC应用,可能需要将与应用相关联的UL数据路由到相同的应用位置以进行收集、处理和决策。例如,数据可以被路由到相同的应用程序位置,以便处理数据、识别任何数据相关性、执行信息聚合,并做出决定或输出结果以允许运营商或第三方审查和采取行动。在这种情况下,AF对业务路由的影响可以经受空间有效性检查,例如,当应用业务路由时,UE的位置满足空间约束。

因此,根据一些实施例,空间有效性条件被包括在AF向CN提供的信息中,其独立于影响UP(重新)选择的条件。

根据一些实施例,可以将CP和应用环境之间的交互定义或调节为策略,以便从统一策略框架中受益。在一些实施例中,CP与应用环境之间的交互结果是策略生成或策略更新。策略是UP管理策略,其中包括业务路由策略。基于PCF的方法允许PCF维护UP管理的全局视图,从而解决UP管理中的全局一致性最优化。

AF可以发送请求以影响针对一个或多个PDU会话的业务的SMF路由决策。在一些实现中,AF向PCF发送请求以影响这些SMF路由决策。这可能影响UPF选择过程并允许将用户业务路由到对数据网络(DN)的本地接入。本领域技术人员将理解,在本文中参考业务的路由,对DN的本地接入可以被理解为包括将业务传输到本地接入点,该本地接入点可以提供对所讨论的DN的接入。该本地接入点可以是CN(或CN的分段)的本地接入点,或者它可以是DN的本地接入点。拓扑上,本地接入充当到DN的连接。

在一些实现中,AF可以负责,或作为决策方,针对本地DN内应用的(重新)选择或重新定位。在一些实现中,这样的AF可以接收关于与PDU会话相关的事件的通知(并且在一些实施例中,可以接收与具有实时PDU会话的应用,或者具有通过AF或与AF发起PDU会话的授权的应用相关联的信息)。

在一些实现中,AF可以彼此独立地发送与DN托管的应用相关联的(重新)选择或重定位请求。假设发出这种请求的AF属于服务于UE的网络(例如PLMN)。则AF可以代表不被服务于UE的网络(例如PLMN)拥有或托管的其他应用发出请求。

如果AF在CN的信任域内,则它可以直接与PCF交互。如果AF在信任域之外,则它可以经由NEF与PCF交互,并且NEF又可以反过来与PCF交互并且代表信任域外的实际AF在信任域内充当AF。在一些实施例中,NEF可以作为AF以代表驻留在信任域内的实际AF。

在AF经由NEF与PCF交互的场景中,AF提供的信息和5G核心(5GC)网络中使用的信息可以具有不同的格式或者性质上不同(例如,包含不同的信息元件)。在一些实现中,NEF可以被配置为执行信息转换/映射。在AF直接与PCF交互的情况下,AF可以提供5GC可用的信息而无需信息转换。

可以由AF发送影响针对PDU会话的业务的SMF路由决策的请求。应用功能可以向PCF发送应用位置通知消息。该消息可能至少包括:

用于标识要被路由的业务的信息。例如,可以通过DNN和应用标识符或业务过滤信息来识别业务。在一些实现中,可以在DNN的AN请求中识别业务。DNN可以用于识别 PDU会话的业务,以及应用标识符,以指示PDU会话的特定服务。在IP业务的情况下,在一些实施例中,可以包括业务过滤信息(例如,可能包含源和目的地址,以及源和目的中的每一个处的端口号的IP 5元组,以及正在使用的协议)。在一些实现中,切片信息(例如,S-NSSAI)可以是业务过滤信息的一部分或者是AN请求中的单独元素。

有关在何处路由的信息。如果AF直接与PCF交互,则它可以指示包括动态网络接入标识符(DNAI)列表的路由配置文件,其中的每个可以包括对DN的本地接入,以及与每个DNAI相关的N6业务路由参数。如果AF经由NEF与PCF交互,则其可以在其通信中指示DNN和应用地址中的至少一个。在一个实施例中,N6业务路由参数可以在UPF中配置,用于支持本地DN中的业务转向机制或实现。

AF的潜在位置可用于确定应该在何处应用业务路由。例如,AF的潜在位置可以用于UPF 选择。如果AF直接与PCF交互,则可以由上述路由配置文件中的DNAI提供与AF 潜在位置相关的信息(绝对术语或拓扑术语)。如果AF经由NEF与PCF交互,则关于AF的潜在位置的信息可以由应用程序的主机地址提供。

关于其业务将被路由的UE的信息。这可以对应于单个UE、所有UE、UE组、连接的UE的子集,或另一个这样的分组。可以使用外部标识符、外部组标识符、MSISDN、IP 地址或IP地址前缀中的任何一个或其组合来标识UE或UE的分组。

时间有效性信息,用于指示何时应用业务路由。在一些实现中,缺少时间有效性信息可能意味着应立即应用业务路由。应当理解的是,如果省略时间有效性信息,则可以应用其他默认条件。

空间有效性信息,指示应当用于确定是否应用业务路由的任何基于位置的标准(例如,UE 应该位于的地理位置)。如果缺少该信息,则可以应用默认条件。

在一些实现中,AF可经由NEF与PCF交互。在这种情况下,NEF可以被配置为将消息中的“关于应该在何处应用业务路由的应用潜在位置的信息”和“关于在何处路由应用的信息”转换为路由配置文件,并向PCF提供该路由配置文件或者该路由配置文件的指示。如果可以对路由配置文件进行排序并将其放入索引列表中,则只需要提供索引。

在一些实现中,PCF基于所接收的信息(例如,从AF或NEF接收的)中的可能是预定义的运营商的策略,以及来自其他实体的输入(例如,用户订阅、用户的配额、用户的当前RAT、网络负载状态、时间、UE位置、APN等,其可以从例如CSM实体、HSS、业务工程功能的其他网络实体接收,或来自任意数量的控制和管理面实体),可以授权从 AF接收的请求并根据该请求确定业务转向策略。该业务转向策略可以指示来自一组配置文件的合适的业务转向配置文件。每个配置文件可以指定提供业务转向的UPF和N6业务路由参数。这可能隐含地指示要在UPF中配置的唯一DNAI。

在实现中,PCF可以向SMF提供业务转向策略。SMF可以根据本地政策将这些信息考虑到以下的至少一个中:

(重新)选择PDU会话的UPF。SMF可以在(重新)选择UP路径时执行业务转向配置文件选择。因为业务转向配置文件可以隐含地映射到唯一的DNAI(通过配置文件中的N6业务路由参数),所以除了UPF选择之外,业务转向配置文件选择可能意味着将UE位置(TAI/Cell-Id)映射到DNAI。

激活用于业务多归属或UL分类器(UL CL)执行的机制。这可以包括向UPF提供业务转发(例如,突发)规则;和

根据选定的业务转向配置文件在锚UPF中配置N6业务路由。

参考图15,在应用(重新)定位通知过程的实施例中,连接信息(包括连接质量,例如跳数,性能,例如,延迟、延迟抖动、吞吐量或属性,例如支持的协议和包括协议头的协议参数)在DNAI(例如,DNAI-1或DNAI-2)和各个应用主机之间可以由管理面实体,例如网络管理器、切片管理器或服务管理器在NEF 314中配置。或者,连接信息可以由AF 324提供给NEF314。在一些实施例中,具有应用主机的DNAI的连接信息也可以称为路由要求或路由配置文件。在其他实施例中,该连接信息可以是路由配置文件的一部分。

如果AF 324不在信任域中(例如,不在CN内或CN所信任的网络中),则AF 324 可以经由NEF 314与PCF 316交互。在这种情况下,AF 324可以在例如应用位置通知消息的消息中向NEF 314提供应用的潜在主机位置(或与应用相关联的一组位置)。NEF 314 可以根据上述的信息和连接信息选择与应用程序相关联的合适的DNAI。在一些实现中, NEF 314还可以根据与朝向端到端连接(永久地或基于特定会话)的应用相关联的QoS 要求来执行选择。该QoS要求可以由AF 324提供,同时例如应用位置通知消息之类的其他数据,或者可以单独发送。NEF 314可以向PCF 316指示所选择的DNAI和相应的连接信息(所选择的部分或全部)。在一些实现中,由NEF 314指示的连接信息(或路由配置文件,或者路由要求)可以通过例如网络管理器、切片管理器或服务管理器的管理面功能在PCF 316中配置。在这种情况下,NEF可能仅需要向PCF指示连接标识符(或路由要求标识符,或者路由配置文件标识符)。根据所提供的连接标识符,PCF 316可以从其本地配置中识别细节。在一些实现中,PCF 316可以从NEF预先获得连接信息(或路由配置文件,或路由要求配置文件)。在一些实现中,NEF314从AF 324获得连接信息(或路由配置文件,或者路由要求配置文件)。

在管理面功能用于配置CP功能的情况下,例如,要应用于NEF 314的配置改变,可以在接收到由AF 324发送的请求之后改变配置。在一些实现中,管理面功能可以利用备用路径来配置CP功能。在传统上管理面功能将通过管理面中的“元素管理”系统配置CP 功能的情况下,在本发明的实施例中,配置信息可以通过NEF 314发送到CP功能。在这种场景中,管理面功能可以被认为充当向NEF发送消息的AF。这允许NEF 314在不使用元素管理系统接口的情况下转发配置信息或指令。

DNAI可以与一个或多个UPF 304相关联。该关联可以基于UPF 304的服务区域或DNAI的服务区域。例如,UPF 304可以与位于UPF 304的服务区域内的DNAI相关联。在其他示例中,位于DNAI的服务区域内的UPF 304与DNAI相关联。应当理解的是,服务区域可以根据地理区域来定义,或者可以由与移动网络区域相关联的拓扑功能来确定。在一些实施例中,UPF 304和DNAI的关联可以基于虚拟化。在这种情况下,DNAI可以与虚拟化环境或平台(在一些实施例中,DNAI本身可以形成环境或平台)相关联。在这样的实施例中,与DNAI相关联的虚拟化中虚拟UPF的实例化与DNAI相关联。UPF 304 可以与一个或多个DNAI相关联。

由于UPF 304和DNAI之间的关联可以是预定义的,当NEF 314将合适的DNAI的指示发送到PCF 316时,它隐含地指示合适的UPF 304。在一些场景下,选择DNAI可能导致隐含地选择了可用UPF 304的子集。

可以在DNAI和与其相关联的每个UPF 304之间定义业务转向配置文件。该业务转向配置文件可用于描述业务转向行为(包括业务转向性能中的至少一个,例如延迟、吞吐量、允许的最大PDU会话等,和

路由参数包括UPF业务朝向DNAI的协议报头。该配置文件可以由例如例如网络管理器、切片管理器或服务管理器的管理面实体在PCF 306中配置。在一些实施例中,可以在UDM 320(统一数据管理)或DSF(数据存储功能——例如UDR 322)中配置业务转向配置文件,并且PCF 316需要通过向UDM 320或DSF(例如UDR 322)指示DNAI和 UPF 304来获得它。

根据路由配置文件,PCF 316可能选择业务转向配置文件(例如,那些提供匹配QoS性能或所需协议支持的配置文件)。所选择的配置文件(有时称为合适的业务转向配置文件,或所选择的合适的业务转向配置文件)或所选择的配置文件的指示可以由PCF发送到SMF。SMF可以在会话建立或会话修改期间(或响应于会话建立或会话修改)执行或开始实施所接收的业务转向策略。如果还在SMF中配置了业务转向配置文件,则在一些实施例中,PCF将仅需要指示业务转向配置文件标识符。如果未在SMF中配置业务转向配置文件,则PCF316可能需要将业务转向配置文件的内容提供给SMF。在一些实施例中,SMF 310由PCF 316发送的业务转向配置文件标识符指示,并且指示的SMF 310可以从第三CP功能获得业务转向配置文件内容,例如UDM 320或DSF(例如UDR 322)。

AF 324可以发送请求以订阅来自SMF的UP路径(重新)选择通知。该订阅可以用于前期通知和后期通知中的至少一个。在订阅前期通知的情况下,SMF 310在执行UP路径(重新)选择之前发送通知。在订阅后期通知的情况下,SMF 310在UP路径(重新)选择完成之后发送通知。

AF 324请求订购来自SMF的UP路径(重新)选择通知可以至少包含:

在实现中,可以提供与订阅相关的业务识别信息。在实现中,如果AF是本地DN中托管的唯一AF,则DNN可以识别业务;否则,DNN和业务过滤信息的组合可用于识别应用业务。在实现中,DNN可以基于以下中的至少一个来识别业务:AF请求、应用标识符和业务过滤信息。在示例中,DNN可以用于标识PDU会话的业务,并且应用标识符可以用于指示PDU会话的特定服务。在IP业务的情况下,在一些实施例中,可以包括业务过滤信息(例如,如上所述的IP 5元组)。

关于其业务与订阅相关的UE的信息。这可以对应于使用外部标识符、外部组标识符、 MSISDN、IP地址或IP地址前缀来识别的单个UE、所有UE和UE组。

有关何时(时间有效性条件)应用订阅的信息。缺少此信息可能意味着订阅应立即生效。关于任何空间有效性条件(UE应该位于的地理位置)的信息,以确定订阅是否适用。缺少此信息可能意味着要使用默认配置。

在一些实施例中,PCF 316基于从AF(或NEF)接收的信息,运营商的策略和来自其他实体(例如,用户订阅、用户的配额、用户的当前RAT、网络负载状态、当天时间、 UE位置、APN等)的输入可以授权从AF接收的请求,并提供或选择UP路径(重新)选择事件通知策略。

在一些实施例中,PCF 316可以向SMF 310提供UP路径(重新)选择事件通知策略。SMF 310可以基于本地策略考虑该信息以通知AF 324(重新)选择UP路径(业务转向的变更)。

UP(重新)选择通知订阅可以在链中发生,例如,当AF订阅NEF时,NEF又订阅 SMF和PCF中的至少一个。在这样的订阅链(例如,在上面示例中的NEF)中间,CP功能将沿着该链发送通知(在一些示例中,这可以是中继所接收的通知)。CP功能可以在订阅链中保持其角色,以先前CP功能中的订阅上下文与链中下一个CP功能之间的映射。在中继通知之前,CP功能可以处理通知并且可以增强或丰富通知中的信息,减少或简化通知中的信息,或者翻译/转换通知中的信息。

SMF 310可以向订户网络功能通知UP(重新)选择通知(以及由PCF提供的UP(重新)选择通知策略中的订阅标识符)。在不需要这种通知的其他实施例中或者在订户网络功能可以通过其他功能获得信息的实施例中,SMF 310可以被配置为不发送通知消息。

在一些实现中,订户网络功能标识符可以指示与订户网络功能相关联的网络地址。在一些实现中,SMF直接使用订户网络功能标识符与订户网络功能交互(例如,在标识符是IP地址的情况下通过IP路由)。在一些实现中,SMF将订户网络功能标识符映射到一些路由信息(例如,隧道信息)并使用该通知来与AF交互。在一些实现中,SMF通过例如来自管理面功能的配置来维护这种映射;在一些实施例中,SMF通过向第三CP功能提供订户网络功能标识符并响应地获得映射,通过与第三CP功能,例如,NRF或UDM进行交互来获得映射。

在AF 324处于信任域的情况下(即,当AF与PCF直接交互时):

在一些实施例中,SMF 310向其发送通知的订户网络功能是AF 324,并且该通知包含PDU 会话所选择的锚UPF的标识符。在一些实施例中,UPF标识符指示UPF 304的地址。

在一些实施例中,SMF 310向其发送通知的订户网络功能是PCF 316,并且该通知指示所选择的业务转向配置文件(例如,通过业务转向配置文件标识符)。然后,PCF 316 识别相应的DNAI并指示DNAI(连同UP(重新)选择通知请求消息中的订阅标识符)——PCF 316正在向订户AF 324执行信息转换。在一些实施例中,DNAI是以网络地址的格式表示。

在AF 324不在信任域中的情况下(即,当AF经由NEF与PCF交互时):

在一些实施例中,SMF向其发送通知的订户网络功能是NEF,并且通知指示PDU会话的所选择的UPF的标识符。NEF可以确定要暴露的UPF的地址和相应的应用主机,并且可以将信息发送到订户AF(在一些实施例中,这可以与从AF接收到的UP(重新)选择通知请求消息中的订阅标识符一起完成)。在这种情况下,可以认为NEF正在执行信息转换和信息丰富中的至少一个。

在一些实施例中,SMF向其发送通知的订户网络功能是PCF,并且通知指示所选择的业务转向配置文件(例如,通过业务转向配置文件标识符)。然后,PCF可以识别相应的DNAI,并向订户NEF提供DNAI的指示(连同订阅标识符),然后订户NEF可以确定要暴露的DNAI的地址和相应的应用主机,并通知订户AF该信息(连同从 AF接收的UP(重新)选择通知请求消息中的订阅标识符)——PCF,并且在一些实施例中,NEF可以被认为执行信息转换和信息丰富中的至少一个。

AF可以独立地发送上述两种类型的请求。在一些实现中,假设发出这种请求的AF属于服务于UE的PLMN。AF可以代表不被服务于UE的PLMN拥有的其他AF发出请求。5G网络的核心网络可以利用网络暴露功能来暴露网络信息和能力,以允许AF与CNF 交互,以便直接地或通过NEF影响UP路径管理和业务路由。

在AF经由NEF与CNF交互的情况下,AF提供的信息和CN中使用的信息可以被不同地格式化或组织。在这种情况下,NEF可以被配置为执行信息处理/映射。

在AF直接与CNF交互的情况下,AF可以提供CNF可用的信息而无需处理/映射。 AF提供的信息被PCF转换为包括N6相关的业务路由规则的受应用影响的UP管理策略,

然后路由到SMF。SMF可根据本地政策将此信息考虑到以下中:

(重新)选择PDU会话的UPF。

激活用于业务多归属或UL分类器(UL CL)执行的机制。这可以包括,例如,向UPF提供业务转发(例如,突发)规则。

通知应用功能(重新)选择UP路径。

AF可以请求通知关于UE的位置信息。

在一些实施例中,提供了一种用于在PDU会话锚和支持边缘计算的业务处理AF之间路由应用业务的系统和方法。

当边缘计算应用程序包括移动性功能(例如,通过边缘计算资源移动的能力,通常是跟踪与应用程序相关联的UE)时,PDU头中应用的网络地址可能与托管应用位置的地址不同。这是因为应用重定位是不一定被UE所知的网络行为。因为在这种情况下PDU头不能用于启用路由(通过N6接口),所以它等同于UL中的非结构化PDU。除此之外,非结构化PDU的使用可能是应用相关的,并且可能发生在任何边缘计算应用程序中。因此,在一些实施例中,边缘计算应用业务被视为非结构化PDU以具有统一的边缘计算框架。

在一些实施例中,本地DN可以负责在PDU会话锚和业务处理AF之间路由应用业务。具体地,本地DN可以实现N6接口以确保在UE/应用移动性存在的情况下的会话和服务连续性。在一些实施例中,本地DN向核心网络提供N6相关的业务路由信息,以便在PDU 会话锚中配置,即,与边缘计算应用相关联的PDU会话的锚UPF。

边缘计算使得运营商和第三方服务能够被托管在本地数据网络中,接近(物理地和逻辑地(拓扑地)中的至少一个)至UE的附着(R)AN。边缘计算服务的紧密位置允许有效的服务递送,因为服务业务限于UE附接点(例如,接入节点)与边缘计算资源之间的链路。这导致应用程序和UE之间的业务更低的端到端延迟。另外,随着跨网络服务业务的减少,整个传输网络可能经历降低的负载。

在一些实施例中,提供了一种方法,其中UE请求针对与边缘计算应用相关联业务的专用PDU会话。在一些实现中,UE可以向SMF发送请求以选择专用PDU会话是否可以用于单边缘计算应用或者由多个边缘计算应用共享。在一些实现中,UE可以在PDU会话建立过程期间将请求发送到SMF。

5G CN功能可以选择靠近UE的UPF并且经由N6接口执行从UPF到本地数据网络的业务转向。该选择可以基于UE的订阅数据、位置、策略或其他相关的业务规则。

由于用户或AF移动性,基于服务或5G网络的要求,可能需要提供服务或会话连续性。

本地数据网络负责N6接口的正确实现,以在存在UE移动性和AF移动性中的至少一个的情况下确保服务或会话连续性,并向网络提供N6相关的业务路由信息。

5G核心网络可以采用允许将网络信息和能力暴露给边缘计算AF的网络功能。

应该注意的是,取决于运营商部署,可以允许某些AF与他们需要与之交互的控制面网络功能直接交互,而其他AF需要经由NEF使用外部暴露框架。

在一些实施例中,支持边缘计算的功能可包括例如:

本地路由:核心网络功能可以选择UPF将用户业务路由到本地数据网络,并使用N6相关的业务路由信息配置UPF。

业务转向:核心网络功能可以选择要被路由到本地数据网络中的应用功能的业务。

会话和服务连续性,以实现UE和AF移动性。

用户面选择和重选,例如,基于来自AF的输入。

网络能力暴露:许多核心网络功能可以通过NEF与AF交换信息(例如,关于功能的能力的信息)。

QoS和计费:PCF为路由到本地数据网络的业务提供QoS控制和计费规则。

AF可以发送请求以影响针对PDU会话业务的SMF路由决策。这可能会影响UPF(重新)选择,并允许将用户业务路由到对数据网络的本地接入

在一些实施例中,影响针对PDU会话业务的SMF路由决策的请求可以包含以下中的一些或全部:

用于标识要被路由的业务的信息。可以通过DNN,以及应用标识符或业务过滤信息来识别业务。

关于在何处路由业务的信息,例如DNN(例如,如果PDU会话的所有业务被路由到应用程序)和应用地址中的至少一个。

应该应用业务路由的应用的潜在位置。处理AF的应用潜在位置用于UPF(重新)选择。要在UPF中配置的与N6相关的业务路由信息。该信息可以包括,例如,本地DN中N6 接口的结束地址和用于N6接口的协议参数。

关于其业务将被路由的UE的信息。使用UE标识符,例如外部标识符或MSISDN,所有UE或所选择的UE组来识别单个UE。

有关何时(时间指示)应用业务路由的信息。

在以上讨论中,假设发出这种请求的AF属于服务于UE的PLMN。AF可以代表不驻留在服务于UE的PLMN内的其他应用发出请求。

在一些实施例中,SMF可以基于本地策略将该信息考虑到:

(重新)选择PDU会话的UPF。

激活用于业务多归属或UL分类器(UL CL)执行的机制。这可以包括,例如,向UPF提供业务转发(例如,突破)规则。

通知AF(重新)选择UP路径。

在一些实施例中,AF可以请求被通知关于UE的位置信息。该通知可以是以下中任意个或全部:一次性地响应于AF通知请求,或者周期性地响应于状态的改变。状态的改变可以是,例如,UE从满足或未满足空间有效性条件的地理位置到达或离开。

在实施例中,(1)NEF被配置有允许应用标识符与应用的IP地址之间的映射的信息。该配置可以由管理面组件执行,例如,网络管理器,切片管理器,服务管理器。

在实施例中,(2)NEF被配置有允许在区域标识符和地理区域之间进行映射的信息。该配置可以由管理组件完成,例如,网络管理器。在一些实施例中,它可以由例如应用功能或应用服务器的第三方功能来完成。这可能需要NEF和第三方之间的交互以进行配置。这可用于提供自定义分区(与管理面配置情况下的统一分区相反)。

在实施例中,(3)NEF将从应用接收的UE位置信息(例如,区域标识符或未编码的区域信息)转换为识别服务于地理区域的AN的信息(例如,ID)。

在实施例中,(4)NEF将转换的信息提供给所选择的CPF,例如SMF或PCF。

在实施例中,(5)AF实现NEF功能。这可以被认为是嵌入在AF中的NEF。在这种情况下,NEF和CPF之间的相互作用发生在CPF和AF之间,并且NEF和AF之间的相互作用成为AF的内部逻辑。在图示中,这可以被描述为在NEF和AF周围绘制框。

在一种实现中,提供了一种用于将UE连接到网络的方法。该方法包括UE在会话请求中提供DNN和应用标识符;SMF使用UE位置从PCF受应用影响的运营商策略获取 DNN和应用标识符。可以通过使用DNN、应用标识符、UE标识符、位置之一或选择的任意或所有的组合在PCF中索引运营商策略。在一些实现中,策略可以与空间有效性条件相关联。在实现中,根据策略,SMF具有足够的信息以允许选择UP路径(例如,锚 UPF)。SMF可以设置UP路径并在锚UPF处配置业务转向(例如,目的地为应用的IP 地址的业务被路由到本地DN中的特定位置)。SMF可以配置业务转向,因为它配置了应用程序标识符与应用程序IP地址之间的映射。

在一种实现中,NEF被配置有用于实现应用标识符与和应用相关联的地址,例如IP地址之间的映射的信息。该配置可以由管理面组件完成,例如,网络管理器、切片管理器、服务管理器。

在一种实现中,NEF被配置有用于实现区域标识符和地理区域之间的映射的信息。该配置可以由管理组件完成,例如,网络管理器。在一些实施例中,它可以由第三方功能,例如应用功能和应用服务器来完成。这可能需要NEF和第三方之间的交互以进行配置。这允许自定义分区(与管理面配置情况下的统一分区相反)。

在一种实现中,NEF将从应用接收的UE位置信息(例如,区域标识符或未编码的区域信息)转换为指示服务于地理区域的AN的指示性信息(例如,ID)。NEF可以将转换的信息提供给所选择的CPF,例如SMF或PCF。

在一些实施例中,AF实现NEF功能,且NEF和CPF之间的交互发生在CPF和AF 之间,并且NEF和AF之间的交互变为AF的内部逻辑。

在一种实现中,提供了一种系统和方法,用于为需要UP路径的AF维持有效的UP 路径。在实施例中,该系统和方法提供在AF和CN CP之间执行的受AF影响的SSC和 UP路径管理,以维持需要UP路径的AF的有效UP路径。对于该实施例假设如下:处理来自/到UE的业务的AF被部署在运营商的本地DN中。

AF负责在本地DN内(重新)选择或重新定位AF。AF直接或通过NEF与控制面网络功能交互。

NEF(或当AF直接与CN CP交互时的AF本身)确定合适的UPF的列表,其提供朝向所识别的潜在AF位置的有效UP路径,并将该信息提供给SMF。

还可以假设NEF可以认证和验证从应用功能接收的信息。

图16是示出AF(重新)定位通知过程的实施例的信令图。然而,应当注意,在AF 324被运营商信任的某些实施例中,AF 324可以直接与CN功能交互,使得AF 324还在该方法中执行NEF 314的角色。这在步骤1600-1608中被注意到,其中AF 324可以在运营商信任AF324的情况下直接参与而不是经由NEF 314参与。

在步骤1600中,AF 324向NEF 314发送AF(重新)定位通知(其包括应用标识符, AF位置信息,时间有效性条件,空间有效性条件,业务过滤器)。

在步骤1602中,NEF 314(或AF 324)使用NRF 318选择服务PCF 314。在图15示出的实施例中,所选择的服务PCF是PCF 31。在一些实施例(未示出)中,NEF 314向向NRF 318提供本地DN名称、边缘计算应用标识符、空间有效性条件(例如服务接入节点标识符,地理位置或区域),根据这些信息的全部或任何组合,NRF 318用服务PCF 回复NEF 314。这些信息可以由AF 324提供,或者NEF 314可以基于AF 324提供的输入导出信息。应当理解的是,NEF314提供给NRF 318的信息可以由AF 324提供。可以在例如AF(重新)定位通知的消息中提供信息,或者可以由NEF 314通过AF 324提供的信息确定或导出信息。

接下来,在步骤1604中,NEF 314(或AF 324)处理该通知,并向PCF 314发送UP 管理策略更新请求。在步骤1606中,PCF 314随后根据该请求生成或更新UP管理策略。如果策略生成/更新影响正在进行的PDU会话并且PDU会话的服务SMF 310已订阅策略更新通知,则PCF 314将向SMF 310通知策略更新。

在步骤1608中,PCF 314响应NEF 314(或AF 314)以确认请求的接收。在PCF 314响应NEF 314而不是AF 324的情况下,NEF 314在步骤1610中向AF 324确认AF(重新)定位通知。

图17是示出UP(重新)选择通知过程的实施例的信令图。在一些实施例中,运营商信任AF 324,使得它可以与CN直接交互。在那种情况下,AF 324在该过程中扮演NEF 314 的角色,并且跳过步骤1702和1712,而且步骤1704、1706和1708涉及AF 324而不是 NEF 314。

该方法以UP(重新)选择通知过程1700开始。在该过程的步骤1702中,AF 324发送UP(重新)选择通知订阅请求(其包括PDU会话或应用标识符,时间有效性条件,空间有效性条件,业务过滤器)到NEF 314,指示是否请求UP(重新)选择之前的通知和之后的通知中的至少一个。如上所述,该步骤是可选的,并且在由运营商信任AF 324的实施例中可能不需要。

在步骤1704中,NEF 314(或AF 324,如果它被运营商信任)与NRF 318交互以选择PCF。在图16所示的实施例中,所选择的PCF是PCF 314。在一些实施例中,NEF 314 向NRF318提供本地DN名称、边缘计算应用标识符、空间有效性条件(例如服务接入节点标识符,地理位置或区域),而NRF 318根据这些信息的全部或任何组合利用服务PCF 来回复NEF 314。该信息可以由AF 324提供,或者NEF 314可以基于由AF 324提供的输入来导出信息。与上述情况类似,由NEF 314提供的信息可以由(重新)选择通知订阅请求中的AF 324接收。在其他实施例中,NRF 318可以基于从NEF 314接收的信息来确定或导出该信息。在步骤1706中,NEF 314(或AF 324)处理该请求并向PCF 314发送UP (重新)选择通知策略更新请求。

在步骤1708中,PCF 314根据接收到的请求生成或更新UP(重新)选择通知策略。如果策略生成/更新影响正在进行的PDU会话并且PDU会话的服务SMF 310已订阅策略更新通知,则PCF 314可以向SMF 310发送关于策略更新的通知消息。

在步骤1710中,PCF 314响应NEF 314(或AF 324)以确认请求的接收。在AF 324 不直接与CN交互的实施例中,NEF 314可以在步骤1712中向AF 324发送UP(重新)选择通知订阅的确认。

在完成UP(重新)选择通知订阅过程1600之后,可以执行UP(重新)选择通知传递过程1714。当UP(重新)选择发生或执行UP(重新)选择通知策略更新时,执行过程1714的步骤。

在步骤1716中,SMF 310向NEF 314发送UP(重新)选择通知,其用作UP(重新)选择已经发生的UP(重新)选择通知对订户的通知。该通知基于所请求的通知的类型在 UP(重新)选择之前和之后中的至少一个发生。它指示PDU会话位置,其可以包括PDU 会话锚的位置和UE 102的IP地址中的至少一个。

前期通知允许AF 324准备与UP(重新)选择相关的必要步骤(例如,AF 324移动性)。后期通知允许AF 324配置本地DN以用于路由来自AF 324的业务。

在步骤1718中,响应于UP(重新)选择通知的接收,NEF 314处理该通知并将UP (重新)选择通知发送到AF 324。然后,AF 324可以指示PDU会话位置和相应的申请地点。该步骤1718是可选的,并且在一些实施例中仅在AF 324使用NEF 314时执行。在不使用NEF 314的情况下,AF 324和PCF 316可以直接与彼此交互并且AF 324可以实现 NEF 314以其他方式执行的功能(例如,与本过程相关的功能)。如果执行步骤1718,则在步骤1720中,AF 324确认向NEF 314传送通知。

在步骤1722中,NEF 314(或AF 324)确认向SMF 310传送通知。

在一种实现中,“UP管理策略更新”服务是PCF 316接收UP管理策略更新请求的服务。该请求可以包括应用标识符、适合于每个应用位置选择的锚UFP的标识符、时间有效性条件、空间有效性条件、业务过滤器和N6业务路由信息。此服务的输出是传递请求的结果。

在该服务期间,当PCF 316接收到UP管理策略更新请求时,PCF 316相应地生成或更新UP管理策略,并向请求者确认请求的接收。如果策略生成/更新影响正在进行的PDU 会话,并且PDU会话的服务SMF 310已订阅策略更新通知,则PCF 316将向SMF 310通知策略更新。

在另一实现中,“UP(重新)选择通知策略更新”服务是PCF接收UP(重新)选择通知策略更新请求的服务。该请求可以包括应用标识符、时间有效性条件、空间有效性条件、业务过滤器和通知类型。该服务的输出是传递请求的结果。

在该服务期间,当PCF 316接收到UP(重新)选择通知策略更新请求时,它可以相应地生成或更新UP(重新)选择通知策略,并且对请求者确认请求的接收。如果策略生成/更新影响正在进行的PDU会话,并且PDU会话的服务SMF 310已订阅策略更新通知,则PCF 316可以向SMF 310通知策略更新。

在实现中,“AF(重新)定位通知”服务是NEF 314接收关于AF 324的(重新)位定位通知的服务。输入通知可以包括应用标识符、AF位置信息、时间有效性条件、空间有效性条件、业务过滤和N6业务路由信息。服务的输出是AF(重新)定位通知的传递结果。

在该服务期间,当NEF 314接收AF(重新)定位通知时,它处理该通知并请求PCF316 更新UP管理策略,并向请求者确认AF(重新)定位通知。

在一种实现中,“UP(重新)选择通知订阅”服务是NEF 314接收针对指定业务的 UP(重新)选择事件通知的UP(重新)选择通知的订阅的服务。输入订阅可以包括应用标识符、时间有效性条件、空间有效性条件、业务过滤器和通知类型。服务的输出是UP (重新)选择通知订阅的结果。

在该服务期间,当NEF 314接收到UP(重新)选择通知订阅时,它可以请求PCF 316更新UP(重新)选择通知策略,并向请求者确认订阅。当NEF 314接收到UP(重新)选择通知时,它识别相应的业务处理AF 324的位置,并且向订户通知UP(重新)选择通知和业务处理AF位置。

在一种实现中,“UP(重新)选择通知”服务是SMF 310具有指示针对正在进行的PDU会话的UP(重新)选择事件通知UP(重新)选择通知的订阅的本地策略。该服务的输入是UP(重新)选择通知策略,其可以包括PDU会话标识符、时间有效性条件、空间有效性条件、通知类型和订阅信息。该订阅信息指示订户NF。该服务的输出是UP(重新)选择通知(其可以包括订阅信息和PDU会话位置信息)。该订阅信息用于标识订户 NF中的订阅上下文的条目。

在该过程期间,当SMF 310检测到指示针对正在进行的PDU会话的UP(重新)选择事件通知的UP(重新)选择通知的订阅的本地策略时,它注册由策略指示的订阅。当 SMF 310(重新)选择针对PDU会话的UPF时,它向订户通知UP选择通知。在订阅前期通知的情况下,SMF 310在执行UPF(重新)选择之前发送通知。在这种情况下,对该通知的响应可以包括N6相关的业务路由信息。SMF 310通知NEF 314,其通知AF 324; AF 324响应NEF 314,然后NEF314响应SMF 310。N6相关的业务路由信息可以包括在 AF 324发送给NEF 314的响应中。NEF314可以在将其发送到SMF 310之前对其进行处理。该处理可以包括用缺失的信息块,其是N6协议特定的,以及协议头编译来补充它。然后,SMF 310根据在执行UPF(重新)选择时接收的N6相关业务路由信息,配置锚 UPF以支持或使用具有业务处理AF的N6接口,其可以是AF324或不同的AF。

在订阅后期通知的情况下,SMF 310在UPF(重新)选择完成时发送通知。在一种实现中,提供了一种用于由UE 102请求的PDU会话建立的方法。在漫游的情况下,AMF 308 可以确定是否要在本地疏导(local breakout,LBO)或归属路由中建立PDU会话。在LBO 的情况下,该过程与非漫游的情况相同,不同之处在于SMF 310、UPF 304和PCF 316中的任意个或全部可以位于接入网络中。

图18A和18B呈现了示出了用于非漫游和具有本地突发的漫游的UE请求的PDU会话建立过程的实施例。该过程假设UE 102已经在AMF 308上注册,因此,AMF 308已经从UDM320检索了用户订阅数据。

为了建立新的PDU会话,UE 102生成新的PDU会话ID。UE102通过在步骤1800 发送包括N1 SM信息中的PDU会话建立请求的NAS消息(S-NSSAI,DNN,应用标识符,PDU会话ID,N1SM信息(注意,在一些实施例中,应用标识符可以嵌入在SM信息))到AMF 308来发起UE请求的PDU会话建立过程。PDU会话建立请求可以包括 PDU类型、SSC模式和协议配置选项。

当DNN指向本地DN时,NAS消息可以包括与本地DN中托管的边缘计算应用程序相对应的应用标识符。应用标识符的存在表明它是对专用于边缘计算应用程序的PDU会话的请求。

UE 102发送的NAS消息由AN308封装在N2消息中,该消息应该包括用户位置信息和接入技术类型信息。

SM信息可以包含SM PDU DN请求容器,其包含由外部DN授权的PDU会话的信息。

在步骤1802中,AMF 308基于未用于UE的任何现有PDU会话的PDU会话ID来确定对应于对新PDU会话的请求的消息。AMF 308选择SMF 310。

在步骤1804中,AMF 308将SM请求发送到SMF 310。该SM请求包含订户永久ID、DNN、S-NSSAI、PDU会话ID、AMF ID、N1 SM信息、用户位置信息和接入技术类型。 AMF ID唯一地标识服务于UE 102的AMF 308。N1 SM信息包含从UE 102接收的PDU 会话建立请求。

在步骤1806中,SMF 310将订阅数据请求(订户永久ID,DNN)发送到UDM 320。该步骤是可选的,并且如果SMF 310尚未检索到与DNN相关的UE的SM相关的SM订阅数据,则可以执行该步骤,SMF 310请求该订阅数据。

如果执行步骤1806,则在步骤1808中,UDM 320将订阅数据响应发送到SMF 310。订阅数据包括授权的PDU类型、授权的SSC模式、默认QoS配置文件。

SMF 310检查UE请求是否符合用户订阅和本地策略。如果它不符合,则SMF 310通过由AMF 308中继的NAS SM信令(包括相关的SM拒绝原因)拒绝该UE请求,SMF 310 向AMF308指示PDU会话ID将被视为已释放并跳过其余的程序。

步骤1810是PDU会话认证/授权,其经由UPF 304从SMF 310到DN 306。如果SMF 310需要授权/认证PDU会话的建立,则SMF 310选择UPF 304并触发PDU会话建立认证/授权。如果PDU会话建立认证/授权失败,则SMF 310终止PDU会话建立过程并向 UE 102指示拒绝。

如果部署了动态策略和计费控制(PCC),则在步骤1812,SMF 310执行PCF选择。在步骤1814中,SMF 310可以向PCF 316发起PDU-CAN会话建立,以获得PDU会话的默认PCC规则。应该注意的是,在该特定实施例中,步骤1810的目的是在选择UPF 304 之前接收PCC规则。如果不需要PCC规则作为UPF选择的输入,则可以跳过步骤1810。

在步骤1816中,SMF 310为PDU会话选择SSC模式。如果未执行步骤1710,则SMF 310还可以在该步骤期间选择UPF 304。在PDU类型为IPv4或IPv6的情况下,SMF 310 可以为PDU会话分配IP地址/前缀。

如果在步骤1814中部署动态PCC并且未执行PDU-CAN会话建立,则在步骤1818 中,SMF 310可以向PCF 316发起PDU-CAN会话建立以获得PDU会话的默认PCC规则。否则,如果部署动态PCC并且PDU类型是IPv4或IPv6,则SMF发起PDU-CAN会话修改并将所分配的UE IP地址/前缀提供给PCF 316。

在步骤1820中,如果PDU会话请求是针对边缘计算应用程序并且如果AF 324已经订阅了与PDU会话相关的这种前期通知,则SMF 310向AF 324通知UP路径选择。该通知指示PDU会话锚。

如果未执行步骤1810,则SMF利用所选择的UPF 304发起N4会话建立过程,否则它利用如图17所示的所选择的UPF 304启动N4会话修改过程。具体地,在步骤1822中, SMF向UPF 304发送N4会话建立/修改请求,并提供要在UPF 304上安装用于该PDU会话的分组检测、实施和报告规则。如果由SMF 310分配CN隧道信息,则在该步骤中将 CN隧道信息提供给UPF 304。然后,在步骤1824中,UPF 304通过发送N4会话建立/修改响应来确认。如果由UPF304分配CN隧道信息,则在该步骤1824中将CN隧道信息提供给SMF 310。

在步骤1826中,SMF 310发送SM请求确认(N2 SM信息(PDU会话ID、QoS配置文件、CN隧道信息),N1 SM信息(PDU会话建立接受(授权QoS规则,SSC模式)))到AMF 308。

N2 SM信息携带AMF 308可以向(R)AN 302提供的信息。CN隧道信息可以对应于与PDU会话相对应的N3隧道的核心网络地址。QoS配置文件可以向(R)AN 302提供QoS参数和QoS流标识符之间的映射。PDU会话ID可以由包括UE 102的(R)AN信令使用,以向UE 102指示(R)AN资源与UE 102的PDU会话之间的关联。N1 SM信息可以包含AMF 提供给UE 102的PDU会话建立接受。多个授权的QoS规则可以包括在N1 SM信息和 N2 SM信息内的PDU会话建立接受中。SM请求确认还可以包含允许AMF 308知道或确定哪个UE 102是SMF 310请求的目标,以及确定对UE 102使用哪个接入的信息。

应该注意的是,可以提供/使用接入信息以实现UE通过3GPP和非3GPP接入同时连接的情况。

在步骤1828中,AMF 308向(R)AN 302发送N2 PDU会话请求(N2 SM信息,PDU 会话建立接受)。AMF 308将PDU会话建立接受和从在N2 PDU会话请求中的SMF 310 接收的N2 SM信息发送给(R)AN 302。

在步骤1830中,(R)AN 302可以开始与UE 102的AN特定信令交换,其与从SMF 310接收的信息有关。例如,在3GPP RAN的情况下,RRC连接重新配置可以针对从步骤1822 中接收的PDU会话请求,利用UE 102建立的与授权Qos规则相关的必要RAN资源而发生。

(R)AN 302还可以为PDU会话分配(R)AN隧道信息。(R)AN 302可以将在步骤1824中提供的NAS消息(PDU会话建立接受)转发给UE 102。(R)AN 302可以在建立必要的(R)AN资源,以及在(R)AN隧道信息的分配是成功的时向UE 102提供NAS消息。

在步骤1832中,(R)AN 302向AMF 308发送N2 PDU会话请求确认((R)AN隧道信息)。该(R)AN隧道信息可以对应于与PDU会话相对应的N3隧道的接入网络地址。

在步骤1834中,AMF 308可以向SMF 310发送SM请求(N2 SM信息)。更具体地, AMF308将从(R)AN 302接收的N2 SM信息转发到SMF 310。

在一些实现中,UE 102可以通知CN功能它已成功建立PDU会话。在一些实现中, UE102发送NAS PDU会话建立完成消息以指示UE 102已成功建立PDU会话。在一些实现中,在步骤1828中指示(R)AN 302中成功建立会话用作通知。

如果用于该PDU会话的N4会话尚未建立,则SMF 310在步骤1836中利用UPF 304 发起N4会话建立过程。否则,SMF 310利用UPF 304发起N4会话修改过程。SMF 310 提供AN隧道信息和CN隧道信息。如果SMF 310在步骤1718中选择了CN隧道信息,则仅需要提供CN隧道信息。

在步骤1838中,UPF 304向SMF 310发送N4会话建立/修改响应。在该步骤之后,AMF 308可以将相关事件的通知转发到SMF 310,例如,在(R)AN隧道信息改变或AMF 308被重新定位的切换时。在一些实施例中,SMF 310明确地订阅这些事件。在其他实施例中,订阅是隐式的。在可选步骤1842中,SMF 310经由UPF 304将IPv6地址配置转发到UE 102。具体地,在PDU类型为IPv6的情况下,SMF 310生成IPv6路由器广告并经由N4和UPF将其发送到UE102。应当理解的是,在一些实施例中,在步骤1838之后, SMF可以向AMF 308发送SM请求确认(如1840所示)。这可以是对SM请求消息1724 的响应。

在步骤1844中,如果PDU会话请求是针对边缘计算应用程序并且如果AF 324具有与PDU会话相关的这种后期通知的订阅,则SMF 310向AF 324发送通知AF 324UP路径选择的UPF选择通知(后期通知)消息。该通知指示PDU会话锚。AMF 308可以在 PDU会话的生存期内存储PDU会话ID和SMF ID的关联。

在一个实施例中,提供了一种用于边缘计算场景中的受AF影响的SSC和UP路径管理的过程。该过程在AF和CN CP之间,以维持需要它的AF的有效UP路径。对于该过程,假设托管边缘计算应用程序的本地数据网络负责N6接口的正确实现,以在存在UE 移动性和AF移动性中的至少一个的情况下确保服务或会话连续性。在这种情况下,UP 路径重选对于UE 5可以是透明的。

在一个实现中,PDU会话锚重新配置是由于应用重定位。在这种情况下,应用重定位不会影响SMF的UPF选择决策,并且SMF 10仅需要在PDU会话锚处重新配置N6业务路由,以确保UL业务传送到新的业务处理AF位置并且识别来自新的业务处理AF位置的DL业务。

图19是示出由于应用重定位导致的PDU会话锚重新配置的实施例的信令图。如图19所示,在步骤1900,UE 102具有与UPF1 304A建立的PDU会话作为PDU会话锚。在步骤1902中,SMF 310接收触发以更新UPF1 304A处的N6业务路由配置。这可以通过例如应用重定位、策略改变等来触发。在步骤1904中,如果AF 324已经订阅了这样的前期通知,则SMF 310向AF 324通知UP路径重选。该通知将UPF1 304A指示为PDU会话锚。接下来,在步骤1906中,SMF310在UPF1 304A处重新配置N6业务路由。在步骤1908中,如果AF 324已经订阅了这样的后期通知,则SMF 310向AF 324通知UP路径重选。该通知将UPF1 304A指示为新的PDU会话锚。在一些实施例中,AF 324仅订阅前期通知,使得步骤1908不被执行。在一些实施例中,AF324仅订阅后期通知,使得步骤1904不被执行。在其他实施例中,AF 324订阅前期和后期通知,使得步骤1904和1908 都被执行。

在其他的实现中,PDU会话锚重定位针对于边缘计算应用程序专用的PDU会话。在这种情况下,PDU会话承载的业务仅与边缘计算应用程序相关联。如果SMF决定重新选择PDU会话的PDU会话锚,则它将所有与PDU会话相关联的业务移动到新的PDU会话锚,然后释放旧的PDU会话锚。

图20是示出针对边缘计算应用程序专用的PDU会话的PDU会话锚重定位方法的实施例的信令图。如图20所示,在步骤2000中,UE 102具有与UPF1 304A建立的PDU会话作为PDU会话锚。PDU会话专用于与边缘计算应用程序关联的业务。在步骤2002中, SMF 310接收触发以将UPF2 304B重新选择为PDU会话锚。这可以通过,例如应用重定位、UE移动性、策略改变等来触发。在步骤2004中,如果AF 324已经订阅了这样的前期通知,则SMF 310向AF324通知UP路径重选。该通知将UPF2 304B指示为新的PDU 会话锚。在步骤2006中,SMF 310将与UPF2 304B的UP路径重新配置为PDU会话锚,包括在UPF2 304B处的N6业务路由配置。在步骤2008中,如果AF 324已经订阅了这样的后期通知,则SMF 310向AF 324通知UP路径重选。该通知指示新PDU会话锚是UPF2 304B。在一些实施例中,AF 324仅订阅前期通知,使得步骤2008不被执行。在一些实施例中,AF 324仅订阅后期通知,使得步骤2004不被执行。在其他实施例中,AF 324订阅前期和后期通知,使得步骤2004和2008都被执行。在步骤2010中,SMF 310释放与UPF1 304A的PDU会话资源。

在另一实现中,PDU会话锚重定位用于由多个边缘计算应用程序共享的PDU会话。在这种情况下,PDU会话承载与多个边缘计算应用程序相关联的业务。如果SMF 310被触发以选择针对一个边缘计算应用程序的PDU会话锚,则它将UPF配置为上行链路分类器UL(CL),以便与该边缘计算应用程序相关联的业务从UL CL转发到新的PDU会话锚,而其他业务转发到旧的PDU会话锚。

图21是示出用于由多个边缘计算应用程序共享的PDU会话的PDU会话锚重定位方法的实施例的信令图。如图21所示,在步骤2100中,UE 102具有利用UPF1 304A建立的PDU会话,作为与边缘计算应用相关联的业务的PDU会话锚。在步骤2102中,SMF 310 决定重新选择UPF2 304B作为与边缘计算应用程序相关联的业务的PDU会话锚。这可以通过,例如应用重定位、UE移动性、策略变更等来触发。在步骤2104中,如果AF 324 已经订阅了这样的前期通知,则SMF 310向AF 324通知UP路径重选。该通知将UPF2 304B 指示为与边缘计算应用程序相关联的业务的新PDU会话锚。在步骤2106中,SMF 310经由N4将UPF2 304B配置为用于与边缘计算应用程序相关联业务的新PDU会话锚。在步骤2108中,SMF 310经由N4将UPF配置为用于PDU会话的UL CL 304C,并且建立从UL CL 304C到UPF1 304A和UPF2 304B的两个分支。SMF 310向UL CL 304C提供必要的UL业务转发规则。然后,在步骤2110中,SMF 310指示(R)AN 302更新N3。在步骤 2112中,如果AF 324已经订阅了这种后期通知,则SMF 310向AF 324通知UP路径重选。该通知将UPF2 302B指示为与边缘计算(Edge Computing)应用程序相关联的业务的新PDU会话锚。在一些实施例中,AF 324仅订阅前期通知,使得步骤2112不被执行。在一些实施例中,AF 324仅订阅后期通知,使得步骤2104不被执行。在其他实施例中,AF 324订阅前期和后期通知,使得步骤2104和2112都被执行。

在一些情况下,UE 102已知的AF 324(边缘计算应用程序)的网络地址(例如,IP地址)不指示AF 324被托管的实际位置(例如,IP地址可能不指向到实例化AF的服务器)。例如,这可能由于AF移动性而出现,并且可能在虚拟化环境中更常见。结果,AF 324的IP地址可能不在来自UE 102的所有上行链路(UL)通信中工作。

在一些实施例中,可以采用CN-UP和本地DN的联合管理。NEF(CN中的CP功能)确定UPF与AF(即,边缘计算应用程序)的物理主机之间的互连。该NEF可以基于由 MEC控制器提供的AF信息以及UPF与AF主机之间的拓扑的预配置信息来确定互连。 NEF编译UPF和AF主机之间互连的协议参数。该编译可以基于由MEC控制器提供的协议信息以及由其他CPF提供的UE和会话信息中的至少一个。NEF指示PCF根据管理决策生成策略。管理决策基于每个会话/会话组,每个UE/UE组,或每个应用/服务。

MEC控制器管理本地DN内的服务功能链接,并基于由CN-CP提供的UPF和UE信息中的至少一个来管理/配置用于具有UPF的接口的AF主机。该管理基于每个会话/会话组、每个UE/UE组或每个应用/服务。

SMF(CN中的CP功能)管理和配置RAN和锚UPF之间的路径和协议,并根据由 PCF提供的策略为包括AF主机的接口配置和锚定UPF,其中的策略包括协议参数和路由目的地。SMF还可以向MEC控制器(直接地或经由NEF)提供与锚UPF和UE中的至少一个相关的信息。该管理基于每个会话。

参照图22,提供了简化的网络图以示出分段管理。CN-CP 328管理CN-UP 326并且MEC控制器324管理本地DN 306中的MEC。NEF 314管理CN-UP 326和本地DN 306 之间的链接。本领域技术人员将理解由NEF 314管理的链接可以被理解为CN-UP 326和本地DN 306中的网络功能之间的逻辑链接。

UE102可以通过向CP功能发送发现请求来发现MEC应用。该请求可以包括本地DN名称,其请求发现在指定的本地DN内托管的MEC应用程序。在一些实现中,缺少本地 DN名称指示请求发现所有MEC应用程序。CP功能用发现结果响应UE。发现结果包括< 应用标识符,[应用地址]>的列表,其中[]表示信息是可选的。在一些实施例中,发现结果限于UE 102可用的那些MEC应用或UE 102被授权使用的那些MEC应用。UE 102使用的应用地址用于与MEC应用的上层(例如TCP层)通信。该MEC应用信息可以由NRF 318维护或存储在UDM 320或SMF310中。CP功能可以是任何相关的CP功能,包括例如AMF 308、NEF 314、SMF 310和NRF 318。CP功能需要在回复UE 102之前与NRF 318 或UDM 320或SMF 310进行交互以获得所请求的MEC应用信息。CP功能也可以是NRF 318或UDM 320或SMF 310。在CP功能为AMF 308的实施例中,发现过程可以与注册过程集成,即,在注册完成消息(到UE 102)中,AMF 308可以包括发现结果。

CP功能可以通过NAS消息向UE 102通知发现结果的变化,例如应用地址变化。UE102可以提交对专用PDU会话的请求以处理与边缘计算应用程序相关联的业务。这种专用PDU会话可以用于单个边缘计算应用程序或由多个边缘计算应用程序共享。

在一些实现中,UE的请求可以指定专用PDU会话是用于单个边缘计算应用程序还是由多个边缘计算应用共享。在一些实现中,如果UE 102请求使用单个边缘计算应用程序,则UE 102可以在PDU会话建立过程期间向SMF 310指示应用。该SMF 310可以在会话建立接受步骤期间向UE 102指示应用的地址。

联合管理解决了UL通信中的寻址问题。虽然不是必需的,但是使用用于DL通信联合管理的联合管理允许UE的IP地址与锚UPF解耦,即透明UPF重选。锚UPF重选可能是由于UE移动性、AF移动性、负载等。UE的IP地址不需要随着锚UPF改变而改变。

图23是示出经由NEF 314用于第三方认证/授权的代表性过程的消息流程图。用于PDU会话建立的第三方认证/授权可选地由PDU会话建立过程期间的SMF 310触发并且经由NEF 314执行。

本领域技术人员将理解,参考该图以及本申请的其他图,可以讨论触发过程的网络功能。这应该被理解为包括向另一网络功能发送请求或通知的网络功能,以及包括启动内部过程的网络功能,该内部过程可以导致向另一网络功能发送请求或通知。关于触发过程的功能,对术语“触发器”的理解不应该被限制为将功能的状态或另一个这样的特征与阈值进行比较的含义,并且响应于该比较,一个过程被调用。

在步骤2302中,SMF向NEF 314发送对第三方认证/授权的请求。作为该请求的一部分,SMF 310可以在第三方认证/授权请求消息中向NEF 314提供SM PDU AF请求容器。该请求消息可以包括DNN、S-NSSAI和应用标识符中的至少一个。如前所述,应用标识符可以由UE102提供,作为PDU会话建立请求的一部分。

在步骤2304中,NEF 314使用在步骤2302中接收的信息以选择AF 324。在步骤2306中,NEF 314使用认证/授权请求消息将从SMF 310接收的SM PDU AF请求容器中继到所选择的AF 324。该请求消息还可以包括应用标识符。

认证/授权过程2308利用经由NEF 314、SMF 310和NAS传输的消息,在UE 102和 AF324之间发生。在步骤2308a中,AF向NEF 314发送认证/授权请求。在步骤2308b 中,响应于认证/授权请求,NEF 314将NEF传输(认证消息)发送到SMF 310,其中认证消息包括认证/授权在步骤2308a中,从AF 324为UE102接收的授权请求消息。在步骤 2308c中,响应于接收NEF传输(认证消息),SMF 310将NAS SM传输(认证消息)发送到AMF 314。在步骤2308d中,AMF 324随后通过(R)AN 302将NAS SM传输(认证消息)转发到UE 102。在步骤2308e中,UE102通过经由(R)AN 302向AMF 308发送 NAS SM传输(认证消息)来响应,其中认证消息旨在用于AF 324。在步骤2308f中, AMF 308将NAS SM传输(认证消息)发送到SMF 310。响应于在步骤2308g中接收NAS SM传输(认证消息),SMF 310将SMF传输(认证消息)发送到NEF 314。在步骤2308h 中,响应于接收SMF传输(认证消息),NEF 314向AF 324发送认证/授权响应。应该理解的是,包括不同步骤的替代过程也可能适合使用。

在步骤2310中,基于UE 102的认证消息的AF 324结束认证/授权,并向NEF 314发送认证/授权响应消息,以确认PDU会话的成功认证/授权或失败。AF 324可以向NEF 314 提供SM PDU AF响应容器以指示成功的认证/授权或失败。SM PDU AF响应容器可以包括UE102被授权使用PDU会话的应用的标识符。

在步骤2312中,NEF 314向包含SM PDU AF响应容器的SMF 310发送第三方认证/授权响应消息。

图24是示出了用于PDU会话建立认证/授权的代表性过程的呼叫流程图。

在步骤2402中,SMF 310选择UPF 304。在步骤2404中,SMF 310将N4数据转发消息中的SM PDU DN请求容器发送到所选择的UPF 304。在某些情况下,这被称为SMF 310“触发”了PDU会话建立过程。在实施例中,SMF 310向所选择的UPF 304提供业务转向配置信息(例如,其可以是详细配置消息或指向UPF可访问的预先存储的配置信息的标识符)。业务转向配置信息可以是N4数据转发消息的一部分,或者可以作为单独的消息发送到UPF 304。在步骤2406中,UPF 304将从SMF 310接收的SM PDU DN请求容器中继到DN 306。

认证/授权过程2408发生,并且示出包括UE 102和DN 306之间的步骤2408a到2408h 的经由N4和NAS传输的消息。应该理解的是,包括不同步骤的替代程序也可以适合使用。

在步骤2410中,DN确认PDU会话的成功认证/授权。DN可以向UPF提供SM PDU DN响应容器以指示成功的认证/授权。

在步骤2412中,UPF 304将N4数据转发消息返回到包含SM PDU DN响应容器的 SMF310。

图25A是示出应用功能(AF)324与5G核心网络(5GC)元件之间的代表性过程的消息流程图。这些过程可用于维护或配置与需要端到端用户面路径效率的应用相关联的业务流的有效用户面路径。

在第一个步骤2500处,AF 324可以向NEF 314发送AF请求消息。预期该请求消息可以包含多个字段,例如:请求标识符;应用网络标识符;应用外部标识符;业务过滤;时间有效性条件;空间有效性条件;请求类型;以及请求内容。AF请求消息还可以包括指示该请求可以应用的当前或未来会话的信息。在一些这样的实施例中,UE标识符、一组UE标识符、一组UE的标识符或其他此类信息可以包括在AF请求内。

请求标识符可以用于唯一地标识AF请求消息,因此可以使AF 324能够修改或删除AF请求消息或者将AF请求消息与将来的AF请求消息相关联。请求标识符可以由AF 324 本身或由NEF 314生成。在AF 324生成请求标识符的实施例中,它可以包括在发送给NEF 314的AF请求消息中,其可以记录请求标识符以供将来使用。在NEF 314生成请求标识符的实施例中,可以在AF请求响应消息中将其传送到AF 324,这将在下文更详细地描述。

应用网络标识符可以用于指示应用程序所在的网络。在这方面,应用程序所在的网络可以是虚拟网络、物理网络、域网络等。应用网络标识符可以是网络名称的形式,例如域名或虚拟网络名称。

应用外部标识符可用于标识与AF请求相关的应用程序。

业务过滤器可用于选择用户面路径所应用的业务。在特定实施例中,业务过滤器可以具有以下形式中的一个或多个的任何有效组合:

UE标识符,例如UE外部标识符或移动站ISDN(MSISDN),例如,用于指示特定UE 的未来业务或特定UE的非IP业务;

IP地址/前缀,例如,用于指示与正在进行的PDU会话相关的IP业务;

AF请求标识符,例如,用于指示先前AF请求中定义的业务过滤器;

ANY_UE指示符,例如用于指示任何UE的业务。

时间有效性条件是可选参数,其可用于指示AF请求功能有效的时间段。该时间有效性条件可以包括一组时间元素,例如:开始时间;时间结束;和频率,其中频率可以指示例如每天、每周、每月、非重复等。

空间有效性条件是可选参数,其可用于指示AF请求消息有效的区域。例如,空间有效性条件可以用于将AF请求消息的有效性限制到UE的当前位置。空间有效性条件可以具有一个或多个区或域标识符的形式。该区或域可以指地理区域或网络区或域。地理区域可以根据地理边界来定义(并且可以与时间有效性条件组合)以应用于所定义的边界内(或边界内指定的一组设备)的任何电子设备(例如,UE),或者它可以根据网络的拓扑来定义(例如,通过凭借一组接入节点或其他此类网络节点或功能,指定应用于任何连接的请求消息)来代替基于地理坐标的边界。如上所述,空间有效性条件可以与其他有效性条件(例如,时间有效性或请求所适用的UE或多个UE的规范)组合,使得该请求可以应用于时间窗口中的任何会话,其中指定的一组UE中的UE在由地理边界定义的,或者由网络拓扑约束定义的(例如,UE已经连接到无线接入网络中一组接入节点中的至少一个的所有会话)的空间区域中连接。在AF基于地理位置提供空间有效性条件的实施例中, 3GPP兼容网络内的网络功能可用于将地理边界定义映射到一组网络接入节点或对应于地理边界的其他网络功能。

例如,请求类型参数可以用于指示AF请求消息是“应用位置通知”,“UP管理事件订阅请求”还是“UE分组请求”。如果需要,可以通过使用请求类型参数来定义和指示其他请求类型。在另一替代方案中,请求类型参数可用于指示两个或更多个请求类型的组合。在这种情况下,这些请求类型所需的字段必须以消息格式存在。

请求内容可用于提供与AF请求有关的附加信息。如果需要,请求内容还可以单独或与请求类型参数组合,用于提供被要求指示和支持两个或更多个请求类型中至少一个所需的信息。在特定实施例中,该附加信息可以取决于请求类型。例如,在请求类型参数指示AF请求是应用位置通知的情况下,请求内容可以包括以下中的任何一个或多个:应用的潜在位置;和UP路径的相应N6点对点隧道要求。应用的潜在位置可以是应用网络内的传输地址(例如,服务器名称,IP地址等)的形式。N6点对点隧道要求可以指示隧道的类型(例如,没有隧道、IP隧道、IP/UDP隧道、以太网隧道等)和相关的隧道协议参数(例如隧道端点地址/标识符和应用程序位置的端口号中的至少一个)。特定的N6点对点隧道要求的缺少可用于指示可以使用一组默认的隧道要求。

在一些实施例中,请求内容字段还可以包括事件/通知类型参数,使得给定的请求类型能够与两种或更多种类型的事件结合使用。例如,在具有指示“UP管理事件订阅”请求的请求类型参数的AF请求消息中,事件/通知类型参数可以指示该请求是前期通知还是后期通知,或两者。在其他实施例中,事件/通知类型参数可以指示例如锚UPF改变事件、业务转向改变事件、QoS改变事件等。在一些实施例中,AF可以响应于不同的事件/通知类型参数以在本地DN中执行相应的不同动作,例如,执行隧道配置,完成应用重定位或调整QoS供应。

在一些实施例中,请求内容字段还可以包括组标识符参数。例如,在具有指示“UE分组”请求的请求类型参数的AF请求消息中,组标识符参数是指示由AF请求中的业务过滤器字段定义的UE组的组ID。在一些实施例中,组标识符参数是不存在,并且NEF 负责为UE组分配组标识符,并使用响应消息将其提供给AF。AF可以使用组ID来构建用于后续AF请求的业务过滤器。

响应于AF请求消息,NEF 314可以执行(在2502处)AF 324、认证服务器功能(AUSF)312和用户数据存储库(UDR)322或统一数据管理(UDM)320功能之间的认证/授权过程。在一些实施例中,术语UDR 322还可以被理解为指示统一数据存储库,其向用户数据和与应用相关的数据,例如由AF提供的策略要求(例如,以AF请求的形式)提供统一数据存储。

在一些实施例中,AF 324可以注册自身(使用其自己的身份)和利用网络管理的应用(例如,应用标识符或应用外部标识符)。该注册还可以指示应用网络标识符(或DNN)。注册可以通过管理面功能完成,例如服务管理器、网络管理器、域管理器等。该管理功能可以将安全证书分配给AF并且可以将注册数据和安全证书存储到统一数据管理(UDM) 320或UDR 322中。

在步骤2503处的认证/授权过程中,NEF 314可以向AUSF 312发送AF身份信息、应用外部标识符(或应用标识符)和应用网络标识符(或DNN)中的至少一个,然后其可以与UDM320(或UDR 322)交互以进行认证和授权。例如,如果在AF请求消息中尚未提供该信息,则NEF 314还可能需要与AF交互以获得AF身份信息。或者,NEF 314 可以向AUSF提供AF标识符,然后AUSF可以从AF中获得AF身份信息。

AUSF 312可以使用AF标识符通过网络功能(NF)存储库功能(NRF)发现AF地址,以便与AF通信。或者,NEF可以向AUSF提供AF地址,NEF可以在步骤2500中将该地址获取以作为其与AF的通信的一部分。在其他实施例中,可以采用其他AF地址发现方法。

在完成认证/授权过程之后,NEF可以向AF返回(在2504处)包括结果代码的AF 请求响应消息。该结果代码可以指示认证/授权过程的结果。如果结果是失败,则NEF 314 可以在步骤2504之后终止AF请求过程。否则,NEF 314可以进行到步骤2506,并且使用NRF 318选择策略控制功能(PCF)316。在一些实施例中,可以基于PCF的服务区域来选择PCF 316。例如,具有在AF请求中覆盖本地DN和重叠空间有效性的至少一个的服务区域的PCF,可以在该步骤中被选择。在一些实施例中,可以基于本地DN的服务区域来选择PCF 316。例如,可以选择本地DN的服务区域内的所有PCF。在另一示例中,可以基于PCF的服务区域与本地DN的服务区域的交集来选择PCF 316。在一些实施例中,应用外部标识符(或应用标识符)可以用于PCF选择。在一些实施例中,PCF 316可以在 NEF 314中预先配置,在这种情况下,PCF选择步骤2506可以被省略。

在步骤2508处,NEF 314可以处理AF请求消息并向PCF 316发送策略更新请求消息。该策略更新请求消息可以包括以下参数中的任何一个或多个:请求标识符;DNN;应用标识符;业务过滤器;时间有效性条件;空间有效性条件;请求类型;以及请求内容。

请求标识符可以用于唯一地标识策略更新请求消息,因此可以使NEF 314能够修改或删除策略更新请求消息,或者将策略更新请求消息与未来的策略更新请求消息相关联。请求标识符可以由NEF 314本身或由PCF 316生成。在NEF 314生成请求标识符的实施例中,它可以包括在发送给PCF 316的策略更新请求消息中,其可以记录请求标识符以供将来使用。在PCF 316生成请求标识符的实施例中,可以在策略更新请求响应消息中将其传送到NEF 314,这将在下文描述。优选地,NEF 314在步骤2500中维护策略更新请求标识符和NEF接收的AF请求标识符之间的映射。

可以从步骤2500中由NEF接收的应用网络标识符映射DNN。该映射可以在NEF 314中预先配置。应用网络标识符还可以用于识别相关的控制信息,例如与应用程序相关的 S-NSSAI。

可以从步骤2500中由NEF接收的应用外部标识符映射应用标识符,并在5GC内由UE 102使用以识别该申请涉及的控制信息(例如,单网络切片选择辅助信息(S-NSSAI)政策)。可以在NEF 314中预先配置应用外部标识符和应用标识符之间的映射。

策略更新请求消息的业务过滤器字段可以包含策略更新请求标识符,其可以基于由 NEF接收的AF请求消息的业务过滤器字段中的AF请求标识符(如果有的话)生成,或从其转换。该业务过滤器字段还可以包含UE组标识符。可以根据AF先前的UE分组请求来创建或定义标识符所参考的UE组,并且在UDM 320内维持组成员资格(例如,UDR 322)。UE组可以是应用特定的。

空间有效性条件可以采用RAN节点标识符或小区标识符的形式,并且可以从步骤2500中由NEF接收的AF请求消息的空间有效性条件映射任何空间有效性条件。AF请求消息的空间有效性条件和策略更新请求消息的空间有效性条件之间的映射可以在NEF中预先配置。

在AF请求是应用位置通知的情况下,请求内容容器可以包括路由配置文件ID和相应的N6点对点隧道要求。可以从步骤2500中由NEF接收的AF请求消息中包含的信息(例如应用网络标识符、应用外部标识符和应用的潜在位置)映射路由配置文件ID。可以在NEF中由管理面(MP)直接地或通过网络功能(NF),例如PCF 316、UDM 320 或DSF(例如UDR 322)预先配置该映射。

可以理解,映射等的预配置(无论是在该步骤执行的预配置还是在本公开中描述的其他步骤)可以由管理面功能,例如网络管理器、切片管理器或服务管理器完成。

当管理面功能执行预配置时,它可以使用元件管理系统将预配置信息安装在目标网络功能中。在一些实施例中,管理面功能可以充当应用功能并且通过PCF 316或NEF 314执行预配置。

在一些实施例中,不直接对目标NF执行预配置,而是对例如UDM 320或DSF的第三NF执行预配置。目标NF可主动(例如,周期性地或在需要时)或被动地(例如,在从第三NF接收到通知时)从第三NF获得预配置信息。本领域技术人员将理解,在一些实施例中,DSF可以由UDR 322预配置。

在一些实施例中,当第一NF(例如PCF)和第二NF(例如NEF)要被预配置有相同信息(例如,路由配置文件)时,可以仅针对第一NF执行预配置,而第二NF随后可以从第一NF获得预配置信息。

响应于策略更新请求消息,PCF 316可以根据策略更新请求消息中包含的信息生成(在 2510处)一个或多个UP管理策略。根据策略请求类型,所生成的UP管理策略可以包括业务转向策略、UP管理事件通知策略和UE分组策略中的至少一个。

如果所接收的策略更新请求消息的业务过滤字段包含策略更新请求标识符,则那些策略更新请求标识符可以被转换为对应的业务过滤器。请求消息还可以包含UE组标识符,其可以被转换为业务过滤器(或者可以与其他数据结合使用以创建业务过滤器)。对于转换,PCF可以与UDR交互以获得相关的策略数据。该转换可以在PCF向UDR提供策略数据之前执行。或者,转换可以在策略被发送到SMF之后执行。稍后执行转换允许在SMF 获得策略时,针对在那些策略更新请求中的业务过滤器(例如,由策略更新请求标识符指示)或要被反映的UE组成员中的任何更新/修改。

业务转向策略可以包括以下中的任何一个或多个:DNN,应用标识符,业务过滤器,业务转向配置文件ID,路由配置文件ID,时间有效性条件,空间有效性条件,N6点对点隧道要求和策略更新请求标识符。可以从策略更新请求中的路由配置文件ID映射业务转向配置文件ID(在步骤2508处)。

UP管理事件通知策略可以包括以下中的任何一个或多个:DNN,应用标识符,业务过滤器,时间有效性条件,空间有效性条件,事件类型,通知类型,事件通知接收器标识符(例如,NEF或AF或PCF)和策略更新请求标识符。

UE分组策略可以包括以下中的任何一个或多个:DNN,应用标识符,UE过滤器和策略更新请求标识符。在这种情况下,策略更新请求(和AF请求)中的业务过滤器可以用作UE过滤器,并且可以如上所述对UE过滤器的NEF和PCF中的至少一个处执行映射/转换。

一旦生成了UP管理策略(或等效地,UP管理策略数据),PCF就可以选择UDR并将相应的UP管理策略数据提供(在2512处)到所选择的UDR。可以使用DNN和应用程序标识符来选择该UDR。如果需要,业务过滤器中的UE信息也可以用于UDR选择。 UDR可以通知已订阅策略数据更改事件的任何其他PCF。或者,这可以基于DNN、应用标识符和空间有效性条件(根据需要)以及PCF的服务区域中的任何一个或多个的重叠。

一旦策略数据已被提供给UDR,PCF就向NEF(或AF)返回(在2514处)策略更新响应消息,以确认策略更新请求的接收。

PCF 316还可以通知(在2516处)已经订阅了策略更新事件的通知的任何SMF 310。或者,PCF 316可以基于空间有效性条件(如果有的话)与SMF的服务区域的重叠来识别目标SMF,并通知所识别的SMF。在从PCF 316接收到通知时,订阅SMF 310可以获得UP管理策略,识别策略所应用的PDU会话,并将策略应用于那些PDU会话。

为了确定SMF 310是否已订阅了策略更新事件的通知,SMF 310可以发送PDU会话属性(例如以下中的至少一个:应用,DNN,UE的IP地址,UE标识符,以及UE位置信息)到PCF316,并且PCF 316可以针对更新的策略检查PDU会话属性。PCF 316可以根据其可用的信息向SMF 310提供PDU会话有资格使用的更新策略。SMF 310还可以使用PCF 310不具有的PDU会话属性,针对更新的策略来检查PDU会话。因此,不需要向 SMF 310提供用于由PCF 316检查PDU会话的信息。例如,如果由PCF 316检查时间有效性条件,则SMF 310不需要检查它,因此提供给SMF的政策将不包括在内。在PCF不检查PDU会话属性的实施例中,可以将所有信息提供给SMF。

如果需要,可以由PCF验证空间有效性条件(在这种情况下,SMF需要向PCF通知UE位置以进行空间有效性条件检查)并触发策略更新。在这种情况下,业务转向策略和 UP管理事件通知策略中的至少一个不包括那些条件,因为如果策略退出,则其总是在空间上有效。

如果需要,可以由PCF验证时间有效性条件(在这种情况下,PCF周期性地执行时间有效性条件检查)并触发策略更新。在这种情况下,业务转向策略和UP管理事件通知策略中的至少一个不包括那些条件,因为如果策略退出,则其总是在时间上有效。

SMF可以维护用于各个PDU会话的策略。在这种情况下,策略可以不包括业务过滤器信息,并且PCF会话可以指示PDU会话和策略之间的绑定(例如,PCF参照策略检查 PDU会话,且如果找到匹配,则PCF通知SMF获得政策)。该策略可能包含业务过滤器信息。在这种情况下,SMF可以检查业务过滤器以确定是否将其应用于PDU会话或者与 PDU会话相关联的业务的某个部分。在这两种情况下,针对策略更新的SMF订阅可以是一般订阅或PDU会话特定的。

PDU会话可以受多个业务转向策略的管制。SMF选择要应用的业务转向策略。在一些实施例中,SMF首先选择业务转向策略,然后识别支持策略中指定的业务转向的UPF (例如,通过业务转向配置文件ID)并执行UPF选择和业务转向配置文件选择。SMF向所选UPF提供所选业务转向配置文件的标识符。UPF使用业务转向配置文件标识符来识别在其本地配置中的业务转向参数。

在一些实施例中,基于业务转向策略中的N6点对点隧道要求,SMF计算N6点对点隧道信息并将其配置到PDU会话锚中。该N6点对点隧道信息可以包括用于将N6隧道映射到DL分组的UP路径和用于UL分组的分组处理指令(例如,要应用的隧道协议报头)的业务转发模板(traffic forwarding template,TFT)。

在图25A的示例中,可以基于与AF请求中的空间有效性条件重叠的PCF服务区域来选择PCF(在2506处)。图25B示出了替换实施例,其中基于DNN和应用标识符来选择PCF。图25C说明另一替代实施例,其中PCF由UDM(或UDR)而非NEF选择。

如图25B中可见,呼叫流程(也称为消息流程)过程大致类似于图25的过程,除此之外在这种情况下,步骤2512被省略并且步骤2506(PCF选择)被替代步骤(2518)替换,其中NEF 314(或AF 324)可以将应用网络标识符映射到DNN并将应用外部标识符映射到应用标识符,并将得到的DNN和应用标识符信息提供给NRF 318以选择PCF 316。业务过滤器中的UE信息也可以用于PCF选择。应用标识符可以在5GC内使用,并且由 UE识别应用涉及的控制信息(例如,S-NSSAI,策略)。在一些实施例中,选择多个PCF,并且NEF(或AF)将策略更新请求发送到所有选择的PCF。在一些实施例中,NEF 314 (或AF 324)通过选择PCF代理(其是网络功能)来执行PCF选择,并将策略更新请求发送到PCF代理,然后PCF代理将其发送到它正在服务或委派的所有PCF。在一些实施例中,映射可以在NEF(或AF)中预先配置。在一些实施例中,可以在NEF(或AF)中预先配置PCF的选择,在这种情况下,可以省略PCF选择步骤。

参照图25C,在所示的替代实施例中,AF 324和NEF 314交互以执行步骤2500、2502和2504,如参考图3A的上文中所述。接下来(在2520处),NEF 314(或AF 324)可以将应用网络标识符映射到DNN并且将应用外部标识符映射到应用标识符,并且使用所得到的DNN和应用标识符信息来选择UDM 320。业务过滤器中的UE信息也可以用于UDM选择。应用标识符可以在5GC内使用,并且由UE 102用于识别应用涉及的控制信息(例如,S-NSSAI,策略)。在一些实施例中,映射可以在NEF(或AF)中预先配置。在一些实施例中,可以在NEF中预先配置UDM的选择,在这种情况下,可以省略UDM 选择步骤2520。

在步骤2522处,NEF 314可以处理AF请求消息并向UDM 320发送应用数据更新请求消息。该应用数据更新请求消息可以包括以下参数中的任何一个或多个:请求标识符;DNN;应用标识符;业务过滤器;时间有效性条件;空间有效性条件;请求类型;以及请求内容。

请求标识符可以用于唯一地标识应用数据更新请求,因此可以使NEF能够修改或删除应用数据更新请求,或者将应用数据更新请求与未来的策略更新请求相关联。请求标识符可以由NEF 314本身或由UDM 320(或UDR 322)生成。在NEF 314生成请求标识符的实施例中,它可以包括在发送到UDM 320(或UDR 322)的应用数据更新请求消息中, UDM 320可以记录请求标识符以供将来使用。在UDM(或UDR)生成请求标识符的实施例中,可以在应用数据更新响应消息中将其传送到NEF 314,这将在下面更详细地描述。优选地,NEF 314维持应用数据更新请求标识符与NEF 314在步骤2500中接收的AF请求标识符之间的映射。

可以从步骤2500中由NEF接收的应用网络标识符映射DNN。该映射可以在NEF中预先配置。

可以从步骤2500中由NEF接收的应用外部标识符映射应用标识符,并在5GC中使用且由UE识别与该应用相关的控制信息(例如,单网络切片选择辅助信息(S-NSSAI)策略)。应用外部标识符和应用标识符之间的映射可以在NEF中预先配置。

策略更新请求消息的业务过滤器字段可以包含策略更新请求标识符,其可以基于NEF 接收的AF请求消息的业务过滤器字段中的AF请求标识符(如果有的话)来生成。

空间有效性条件可以采用RAN节点标识符或小区标识符的形式,并且可以从步骤2500中由NEF接收的AF请求消息的空间有效性条件映射任何空间有效性条件。AF请求消息的空间有效性条件之间的映射,以及策略更新请求消息的空间有效性条件之间的映射可以在NEF中预先配置。

在步骤2524中,UDM 320(或UDR)可以向NEF 314返回应用数据更新响应消息。

接下来,UDM 320(或UDR)可以识别已经订阅了应用数据更新通知的任何PCF。或者,UDM 320(或UDR)可以识别具有服务区域的任何PCF,该服务区域包括本地DN 或与本地DN的服务区域相交。然后,UDM 320(或UDR)可以向每个识别的PCF 316 发送(在2526)相应的应用数据改变通知消息。基于所接收的应用数据改变通知消息中包含的信息,PCF 314可以生成策略并转发相应的策略更新通知以订阅SMF 310,如上文中在步骤2510和2516所述。在一些实施例中,应用数据改变通知是简单信号并且不包括改变细节,并且PCF需要与UDM(或UDR)交互以获取变更的详细信息并相应地生成策略。

应注意,在图25C的示例中,由于UDM 320用于选择PCF 314,上文在2512和2514 处描述的UDM 320(或UDR)选择和通知步骤可被省略。

如可以理解的,被运营商信任的应用功能324可以直接与PCF 316交互。在这种情况下,AF 324还可以在过程中执行NEF的角色。图26示出了对应于图25A中示例的示例呼叫流程图,其中图25A的步骤2500、2502和2504不被执行或者被AF 324执行,并且步骤2506、2508和2514由被AF 324执行的步骤2600、2602和2604代替,但在其他方面与步骤2506、2508和2514相同。应当理解的是,对于图25B、25C和27A-28B的实施例存在类似的变体,为了简洁起见,在本说明书中没有详细描述。

图27A是示出用于到AF 324的UP路径管理过程的呼叫流程图(也称为消息流程图)。可以理解的是,运营商信任的应用功能可以直接与PCF 316交互。在这种情况下,AF324 可以在该过程中扮演NEF 314的角色。UP管理事件通知过程可以在UP管理事件在用户面中启动之前和完成之后的至少一个中执行,这取决于通知的类型。

出于该过程的目的,AF可以使用任何合适的过程,例如,如上所述,或者如在适用的3GPP技术标准中所陈述的)来订阅(在2700处)来自SMF 314的UP管理事件通知。

在第一个步骤(在2702处)中,SMF 310可以应用运营商策略,并且识别(在2704处)请求相应的策略更新通知的每个NEF(或AF)。

然后,SMF 310可以向(或每个)识别的NEF(或AF)发送(在2706处)UP管理事件通知消息。该UP管理事件通知消息可以包括以下参数中的一个或多个:策略更新请求标识符(或应用数据更新请求标识符);业务过滤器;事件类型;通知类型;以及事件通知内容。

可以由SMF从运营商策略内获得策略更新请求标识符(或应用数据更新请求标识符)。

业务过滤器可以指示与UP管理事件相关的业务,其是由策略更新请求中的业务过滤器字段指定的业务的一部分。UP管理事件通知消息中的业务过滤器的不存在可以用于指示UP管理事件与策略更新请求中的由业务过滤器指定的所有业务相关。该业务过滤器可以包括以下中的任何合适的组合:UE标识符,例如UE外部标识符或MSISSDN;以及IP 地址/前缀。

通知类型可以用于指示UP管理事件通知是前期通知还是后期通知。

事件通知内容可用于提供与UP管理事件有关的附加信息。该事件通知内容可以包括以下中的任何一个或多个:业务过滤器;应用位置;锚UPF位置;以及N6点对点隧道信息。应用程序位置可以采用路由配置文件ID或DNAI或业务转向配置文件ID的形式。锚 UPF位置可以采用网络地址的形式,其可以取决于隧道类型。例如,对于IP隧道,它采用IP地址的形式;对于以太网隧道,它采用以太网地址的形式。在一些实施例中,锚UPF 位置信息可以用于支持本地DN中的N6点对点隧道。N6点对点隧道信息可以被提供以在应用位置处配置,为了将DL业务与N6点对点隧道绑定,以便确保正确的DL分组传送。 N6点对点隧道信息可以包括锚UPF侧的隧道端点地址/标识符和端口号中的至少一个。隧道端点地址/标识符的形式可以取决于隧道类型。例如,对于IP隧道,隧道端点地址/标识符最好采用IP地址的形式;而对于以太网隧道,它最好采用以太网地址的形式。在特定实施例中,事件通知内容中提供的特定信息可以取决于UP管理事件通知所引用事件的类型。例如,在QoS变更事件的情况下,事件通知内容可以包括新的“QoS规则”。在另一示例中,如果事件类型是业务转向变更,则事件通知内容可以包括应用位置、锚UPF 位置和N6点对点隧道信息。

基于所接收的UP管理事件通知消息,NEF 314可以向AF 324发送(在2708处)相应的UP管理事件通知消息。发送到AF 324的UP管理事件通知消息可以包括以下中的任何一个或者更多:AF请求标识符;事件类型;通知类型;以及事件通知内容。AF请求标识符可以从包含在上文中参考图25和26描述的策略更新请求消息中的策略更新请求标识符映射。事件通知内容可以从由NEF从SMF接收的UP管理事件通知消息的事件通知内容映射(步骤2706)。例如,应用位置可以从以路由配置文件ID或DNAI或业务转向配置文件ID的形式转换到指示部署应用程序位置的网络地址的形式。

在从NEF 310接收到UP管理事件通知消息之后,AF 324可以向NEF 314发送(在2710处)确认消息。该确认可以包括将要在锚UPF 304中配置的N6点对点隧道信息。

然后,NEF 314可以向SMF 310发送(在2712处)对原始UP管理事件通知消息的确认。在AF向NEF 314提供N6点对点隧道信息的实施例中,该信息可以包括在发送到 SMF 310的确认消息中。

在从NEF 314接收到确认消息时,SMF 310可以配置(在2714处)锚UPF中的N6 点对点隧道信息。

如上所述,运营商信任的应用功能可以直接与SMF 310交互。在这种情况下,AF324 还可以在图27A的过程中执行NEF 314的角色。因此,步骤2708和2710将不被执行,并且步骤2706和2712由AF 324执行。

图27B是示出用于向AF 324的UP路径管理通知的备选过程的呼叫流程图(也称为消息流程图)。如图27A中的实施例所示,UP管理事件通知过程可以在UP管理事件在用户面中启动之前和完成之后的至少一个中执行,这取决于通知的类型。

出于该过程的目的,PCF 316可以使用任何合适的过程,例如,如上所述,或者如在适用的3GPP技术标准中所述来订阅(在2716处)来自SMF 310的UP管理事件通知。类似地,AF可以订阅(在2718处)来自PCF 316的UP管理事件通知。

在第一个步骤(在2702处)中,SMF 310可以应用运营商策略,并且识别(在2720)请求相应的策略更新通知的每个PCF 316。

SMF 310可以向(或者每个)识别的PCF 316发送(在2722处)UP管理事件通知消息。UP管理事件通知消息可以如上文中参考图27A所描述的那样被格式化。

基于所接收的UP管理事件通知消息,PCF 316可以向NEF 314发送(在2724处)相应的UP管理事件通知消息。在发送该消息之前,它可以将消息中的业务转向配置文件ID 或DNAI转换为业务转向配置文件ID。发送到NEF 314的UP管理事件通知消息可以包括以下中的任何一个或多个:AF请求标识符;事件类型;通知类型;以及事件通知内容。 AF请求标识符可以从包含在上文中参考图25和26描述的策略更新请求消息中的策略更新请求标识符映射。事件通知内容可以从由NEF从SMF接收的UP管理事件通知消息的事件通知内容映射(步骤2706)。例如,应用位置可以以路由配置文件ID的形式转换为指示部署应用位置的网络地址的形式。NEF 314可以将所接收的UP管理事件通知消息转发(在2726处)到AF 324。

在一些实施例中,发送到NEF 314或PCF 316的UP管理事件通知消息还可以包括内容格式字段,其提供关于如何构造数据以允许网络功能正确地解释事件通知内容中信息的信息。例如,事件通知内容可以用于包含取决于接收器功能的不同类型的信息(例如路由配置文件ID,业务转向配置文件ID或事件DNAI)。在这种情况下,内容格式字段可以用于指示将被用于读取事件通知内容字段中的信息的适当格式。该内容格式字段可以在创建策略时由PCF设置,或者基于来自SMF的UP管理事件通知的内容(在步骤2722处)。

在从NEF 314接收到UP管理事件通知消息之后,AF 324可以向NEF 314发送(在2728处)确认消息。该确认可以包括将要在锚UPF 304中配置的N6点对点隧道信息。

NEF 314可以向PCF 316发送(在2730处)对原始UP管理事件通知消息的确认。在AF 324向NEF 314提供N6点对点隧道信息的实施例中,该信息可以包括在发送到PCF 316的确认消息中。

在从NEF 314接收到确认消息时,PCF 316可以将确认消息转发(在2732处)到SMF310。

在从PCF 316接收到确认消息时,SMF 310可以在锚UPF 304中配置(在2714处) N6点对点隧道信息。

如上所述,运营商信任的应用功能可以直接与PCF 316交互。在这种情况下,AF324 还可以在图27B的过程中执行NEF 314的角色。因此,步骤2726和2728将不被执行,并且步骤2725和2730会被AF 324执行。

图28A和28B示出了针对非漫游场景的UE请求的PDU会话建立过程的呼叫流程图(也称为消息流程图)。图28A和28B的过程假设UE 102已经在AMF 308上注册,因此AMF 308已经从UDM 320检索了用户订阅数据。

在第一个步骤(在2800)中,UE 102通过生成并向AMF 308发送NAS消息来发起 UE请求的PDU会话建立过程。该NAS消息可以包括S-NSSAI、DNN、应用标识符、PDU 会话ID和N1SM信息,并且可以包含N1 SM信息内的PDU会话建立请求。该PDU会话建立请求可以包括PDU类型、SSC模式和协议配置选项。应用程序标识符可用于描述如TS 23.501的条款A.3.1.3.3节所述的UR 23。

NAS消息可以包括与边缘计算应用程序相对应的应用程序标识符。当DNN指向本地DN时,可能会发生这种情况。应用程序标识符的存在指示它是对PDU会话的请求,该会话的使用旨在或专用于边缘计算应用程序。

UE 102发送的NAS消息可以由AN封装在N2消息中,该消息还可以包括用户位置信息和接入技术类型信息。

SM信息可以包含SM PDU DN请求容器,其包含由外部DN授权的PDU会话的信息。

基于在NAS消息中提供的信息,AMF 308可以基于未用于任何现有UE的PDU会话的PDU会话ID来确定对应于对新PDU会话请求的消息。然后,AMF可以为PDU会话选择(在2802处)SMF。

在下一步骤(在2804处)中,AMF 308可以向所选择的SMF 310发送SM请求消息。该请求消息可以包括例如以下的参数:订户永久ID,DNN,应用标识符,S-NSSAI,PDU 会话ID,AMF ID,N1 SM信息,用户位置信息和接入技术类型。AMF ID唯一地标识为 UE服务的AMF308。N1 SM信息包含从UE 102接收的PDU会话建立请求。

基于在SM请求消息中提供的信息,SMF 310可以执行一个或多个检查以确定UE请求是否符合用户订阅以及本地策略。这可以包括向UDM 320发送(在2806处)订阅数据请求,并接收(在2808处)提供用户订阅的信息的订阅数据响应。订阅数据可以包括授权的PDU类型、授权的SSC模式、默认QoS简档和订阅定义的组信息(例如,组标识符)。如果SMF 310尚未检索到针对与DNN相关的UE 102的SM相关订阅数据,则SMF 310 还可以从UDM 320请求该订阅数据。

如果UE请求不符合用户订阅和本地策略,则SMF 310可以通过NAS SM信令拒绝 UE请求以向AMF 308指示PDU会话ID将被视为已释放并且程序终止。

在SMF 310需要经由第三方授权/认证PDU会话的建立的实施例中,SMF可以触发适用的第三方PDU会话建立认证/授权过程2810。第三方触发的PDU会话建立过程2810 可以包括SMF 310向第三方认证服务发送请求,该第三方认证服务可以驻留在DN内。该过程2810可以经由UPF或NEF,如本公开中其他地方所述。如果PDU会话建立认证/授权失败,则SMF 310可以终止PDU会话建立过程并且向UE 102指示拒绝。

在部署动态PCC的实施例中,SMF 310可以执行PCF选择(在2812处)。SMF 310 还可以利用PCF 316发起PDU-CAN会话建立(2814)以获得PDU会话的默认PCC规则。在部署动态PCC并且DNN指向本地DN的实施例中,SMF 310可以将DNN和应用标识符提供给PCF 316。附加信息可以向PCF 316提供以实现更详细的策略决策。例如,可以提供UE信息(例如位置信息、UE标识符、订阅定义的组信息等)或业务信息(例如, UE的IP地址),使得PCF可以仅响应于根据特定UE或业务要求定制的策略。如果需要,可以提供其他PDU会话相关信息。PCF可以使用此信息从UDR获取相关的策略数据用于策略决策。这可以触发PCF订阅与DN相关的策略数据变成和来自UDR的应用程序中的至少一个的通知。PCC规则可以包括UP路径管理事件通知策略。PCC规则可以包括与 DN相关的N6隧道的信息(例如DN中隧道端的地址和端口号中的至少一个)。可以理解的是,该步骤的目的是在选择UPF之前接收PCC规则。如果不需要PCC规则作为UPF 选择的输入,则该步骤可被省略。

SMF 310可以为PDU会话选择(在2816处)UPF 304和SSC模式。在PDU类型是 IPv4或IPv6的实施例中,SMF 310可以为PDU会话分配IP地址/前缀。对于非结构化PDU 类型,SMF310可以为PDU会话和N6点对点隧道分配IPv6前缀(基于UDP/IPv6)。如果提供了业务转向策略,则SMF 310还可以在该步骤中选择业务转向配置文件或策略。

在步骤2514中部署动态PCC并且未执行PDU-CAN会话建立的实施例中,SMF 310 可以向PCF 316发起(在2818处)PDU-CAN会话建立以获得用于PDU会话的默认PCC 规则。如果DNN指向本地DN,除了UE信息(例如,UE标识符,订阅定义的组信息)之外,SMF 310还可以向PCF 316提供DNN和应用标识符(如果可用的话)。否则,如果部署动态PCC并且PDU类型是IPv4或IPv6,SMF 310可以发起PDU-CAN会话修改并且向PCF 316提供分配的UE的IP地址/前缀。如果部署动态PCC,则对于非结构化PDU 类型,SMF 310可以向PCF提供将为PDU会话分配的IPv6前缀。

在下一步骤(2820)中,SMF 310可以选择业务转向配置文件或策略。

在提供UP路径管理事件通知策略的实施例中,SMF可以通知(在622)AF(或NEF)关于UP路径选择。如果业务转向策略指示需要对SMF 310和AF 324之间的N6隧道信息进行动态配置,则协商还可以与UP路径选择通知一起执行。通知可以包括与UPF有关的N6隧道信息(例如,UPF的地址和端口号中的至少一个)以及这是前期通知的指示。

在步骤2824中,SMF 310可以向UPF 304发送N4会话建立/修改请求,并提供要在UPF 304上安装的用于该PDU会话的分组检测、实施和报告规则。在不执行(在2810处) PDU会话认证过程的实施例中,N4会话建立/修改请求消息可以用于发起与所选择的UPF 308的N4会话建立过程,否则它可以用于发起具有所选UPF 308的N4会话修改过程。如果由SMF分配CN隧道信息,则在该步骤中将适用的CN隧道信息提供给UPF 308。如果要支持N6隧道,则在该步骤中将适用的N6隧道信息提供给UPF 304。应当理解的是,在该步骤中N6隧道信息不一定必须提供给UPF 304。

UPF可以通过向SMF发送(在2826处)N4会话建立/修改响应消息来确认N4会话建立/修改请求消息。如果由UPF 308分配CN隧道信息,则在该步骤中使用的CN隧道信息还可以提供给SMF 310。

在步骤2828中,SMF 310可以向AMF 308返回SM请求确认消息。该SM请求确认消息可以包含例如以下的参数:N2 SM信息(例如,PDU会话ID,QoS配置文件和CN 隧道信息);N1SM信息(例如,PDU会话建立接受(包括授权的QoS规则,以及SSC 模式))。该N2 SM信息可以携带AMF需要提供给(R)AN的信息。CN隧道信息可以对应于与PDU会话相对应的N3隧道的核心网络地址。QoS配置文档可以向AN提供QoS 参数和QoS流标识符之间的映射。PDU会话ID可以利用UE通过AN信令向UE指示AN 资源与UE的PDU会话之间的关联。N1 SM信息可以包含AMF需要提供给UE的PDU 会话建立接受消息。多个授权的QoS规则可以包括在N1 SM信息和N2SM信息内的PDU 会话建立接受消息中。

SM请求确认消息还可以包含允许AMF识别哪个UE是SMF请求的目标以及确定对 UE使用哪个接入的信息。接入信息可以用于处理UE通过3GPP和非3GPP接入同时连接的情况。

现在参照图28B,在步骤2830中,AMF可以向(R)AN 302发送N2 PDU会话请求消息。该N2 PDU会话请求消息可以包含例如以下参数:N2 SM信息;以及PDU会话建立接受。

响应于N2 PDU会话请求消息,(R)AN 302可以发起(在2832处)与UE 102的特定信令交换,以建立用于PDU会话的资源。例如,在3GPP RAN的情况下,可以在UE 102 建立与针对PDU会话的授权的QoS规则相关的必要RAN资源的情况下进行RRC连接重新配置。(R)AN内的节点还可以为PDU会话分配(R)AN隧道信息。如果建立了必要的RAN 资源并且(R)AN隧道信息的分配成功,则(R)AN节点可以将NAS消息(包括PDU会话建立接受)转发给UE。

在建立用于PDU会话的资源之后,(R)AN节点302可以向AMF 308发送(在2834) N2PDU会话请求确认消息。N2 PDU会话请求确认消息还可以包括对应于用于PDU会话的N3隧道的接入网络地址的(R)AN隧道信息。在AMF 304接收到N2 PDU会话请求确认消息之后,UE102可以能够开始将PDU会话的上行链路数据发送(在2836处)到UPF 304。

在下一步骤(2838)中,AMF 308可以使用包括N2 SM信息的SM请求消息将从(R)AN接收的N2 SM信息转发到SMF 310。

接下来,SMF 310可以向UPF 304发送(在2840处)N4会话修改请求,以便为与新PDU会话相关联的N4会话提供AN隧道信息和(可选地)CN隧道信息。在尚未建立新 PDU会话的N4会话的情况下,SMF 310可以利用UPF 304发起N4会话建立过程以建立包括AN隧道信息和(可选地)CN隧道信息的N4会话。否则,SMF 310可以利用UPF 304 发起N4会话修改过程,以将AN隧道信息和(可选地)CN隧道信息添加到现有N4会话。应注意,如果SMF 310在步骤2816中选择了CN隧道信息,则仅需要提供CN隧道信息。

在从UPF(在2842处)接收到N4会话建立/修改响应之后,如果提供了UP路径管理事件通知策略并且指示了后期通知的需求,则SMF 310可以通知(在2844处)AF 324 (或NEF314)关于UP路径选择。通知可以包括与UPF有关的N6隧道信息(例如,UPF 的地址和端口号中的至少一个)以及这是后期通知的指示。如果要使用N6隧道,则该步骤可以向AF指示N6隧道已准备好使用。随后,AMF可以在例如(R)AN隧道信息变更或 AMF被重新定位的切换时将相关事件转发到SMF。

然后,SMF 310在生成并经由N4会话和UPF 304向UE 102发送(在2848处)IP路由器通告之前,向AMF 308返回(在2846处)SM请求确认。该步骤提供IP配置信息使得下行链路数据可以被发送到UE(在2850)。

在PDU会话的生存期期间,AMF 308存储PDU会话ID和SMF ID的关联。

图29A和29B显示了示出了针对UE请求的PDU会话建立以用于具有本地突发漫游的过程的呼叫流程图。图29A和29B的过程与图28A和28B中的密切相似,除了在具有本地疏导的漫游的情况下,SMF 310、UPF 304和PCF 316都位于接入网络中。这意味着上述步骤2820、2822和2844不被执行。

图30是示出根据本发明示例实施例的切换过程的流程图。将很好地理解,在所示的流程图中,不同的实体负责执行不同的步骤。应进一步理解,这表示多个独立方法的相互作用,其中的每个方法在不同的节点或功能上执行。该方法的一种变形将不一定需要改变另一种方法。此外,在参照第一功能向第二功能发送消息的情况下,应该理解,这意味着第二功能执行接收由第一功能发送的消息的步骤。

在第一个步骤(3000)中,AF可以订阅与应用相关联的某些特定业务的UE移动性事件的通知。UE移动性事件可以包括,例如UE移出当前本地DN的服务区域。

随后,AMF可以检测UE移动性事件(在3002处),并且向AF发送相应的通知(在3004)。或者,AMF可以通知SMF,而SMF反过来通知AF。该通知可以经由NEF发送(例如,当AF不可信时)或者直接发送到AF(例如,当AF在信任域中时)。通知可以包括UE正在进入的目标的本地DN(其中还部署了应用)。

在接收到通知时,AF可以识别(在3006处)与目标DN中的应用相关联的第二AF,并且向第二AF通知应用标识符、业务过滤器(指示受影响的应用业务)和应用上下文信息。AF可以可选地向第二AF通知AMF通知标识符(在AMF通知中携带)。

然后,第二AF可以向5GC(例如,SMF)发送请求(在3012处),以在UE进入目标的本地DN之后触发PDU会话建立或恢复。发送到5GC(例如SMF)以进行PDU 会话建立或恢复的请求可以包括AMF通知标识符和业务过滤器中的至少一个,以便5GC 可以恢复正确的PDU会话或通知UE建立合适业务的PDU会话。

一旦UE移动性事件已经发生,AMF就可以向SMF发送相应的通知(在3008处),并且SMF可以通过去激活或释放(在3010处)与应用相关联的PDU会话来进行响应。

在一些情况下,相同的AF可以与当前和目标DN中的应用相关联。在这种情况下,上文引用的“AF”和“第二AF”实际上是相同的实体。因此,在步骤3006的两个AF之间的交互变为内部过程,并且步骤3012可以通过从第一AF到AMF或SMF的响应消息来执行。

可以理解,图30的过程允许保留UE的应用会话,因为应用上下文被传送到控制目标DN中应用的第二AF。

在一些实施例中,AF是应用服务器。在其他实施例中,AF不是应用服务器,而是操作以将应用上下文配置到应用服务器中以恢复/保留应用会话。

在一些实施例中,AF是SDN控制器,其操作以配置在传输网络中的转发规则,以确保分组传递给正确的UPF。

在一些实施例中,应用程序是视频流应用程序,并且应用上下文信息描述如何(从何处)恢复中断的视频流。在一些实施例中,应用程序是游戏应用程序,并且应用上下文信息描述如何(从何处)重建或恢复游戏上下文。

DNAI是指向提供对用户面业务的DN访问的节点或功能的标识符。UP向DN发送业务的节点或功能可以将业务引导到DNAI。在一些实施例中,DNAI可以是例如路由器的网络元件,其由运营商战略性地部署,在其他实施例中,DNAI可以是提供对数据中心的访问的网关功能,在该数据中心内实例化虚拟UPF。应用位置指的是部署应用程序的网络元件(例如,服务器,数据中心)。多个应用程序可以在同一位置中部署。

应该理解的是,当应用程序通过3GPP兼容网络与UE进行通信时,该程序位置可以与DNAI映射或关联。在一些实施例中,该关联可以是路由配置文件的一部分(例如,在路由配置文件中存储或特殊说明)。在其他实施例中,该关联位于路由配置文件外部,并可能存储在本地可访问表中,或在网络内的功能参考点中。在一些实施例中,路由配置文件描述了与应用位置业务的路由相关联的路由参数。这可以采用应用位置处的目的地址和目的端口号之一或两者的组合的形式。这些实施例是关联可以位于路由配置文件外部的情况的示例。本领域技术人员将理解,在一些实施例中,路由配置文件可以是应用位置特定的。这允许将业务引导到DNAI,并从那里转发到应用程序。应用程序可以在不同的DN 中实例化。在相同的DN内,应用程序可以在多个位置实例化,并且每个应用位置可以与多个DNAI相关联。在路由配置文件是特定于每个应用位置的实现中,路由配置文件可以指示传输地址,例如IP地址和端口号,或者例如以太网地址的与应用位置相关联的网络地址,以及要由与用于将业务路由到应用位置的应用位置相关联的DNAI使用的其他业务路由参数。

在一些实施例中,路由配置文件和路由配置文件(或对应的应用位置)与DNAI之间的关联可以通过与NEF协调的另一网络功能(例如AF),或通过例如网络管理器、切片管理器、服务管理器等的管理面功能配置到NEF。在AF在可信域内的实施例中,路由配置文件和路由配置文件与DNAI之间的关联可以配置到AF本身。

因为DNAI识别数据网络接入点,并且每个DN可以支持多个不同的应用程序和UPF,所以DNAI可以与多个不同的UPF相关联。业务转向配置文件通常与DNAI相关联,然后应用于与DNAI相关的每个UPF。在一些实施例中,PCF可以被配置有DNAI的信息和业务转向配置文件。在一些实施例中,可以将业务转向配置文件和UPF之间的关联配置到SMF中。在另一个实施例中,可以将业务转向配置文件配置到UPF和SMF中。上述配置可以由管理面功能执行,例如网络管理器、切片管理器、服务管理器等。而其他网络功能,包括SMF、NEF或PCF,也可以在UPF和业务转向配置文件的配置中发挥作用。在业务转向配置文件是特定于每个DNAI的实现中,业务转向配置文件可以指示传输地址,例如IP地址和端口号,或者与DNAI相关联的例如以太网地址的网络地址,以及要被用于将业务路由到DNAI且与DNAI相关联的UPF使用的其他业务路由参数。业务转向配置文件还可以通过标识符指示DNAI本身。

图31是示出应用位置、DNAI和UPF之间的示例关系的逻辑框图3100。示出了一组四个UPF,UPF1 3102、UPF2 3104、UPF3 3106和UPF4 3108。示出了一组两个应用位置 AS13120和AS2 3126。对AS1 3120的接入可以通过DNAI 1 3110或DNAI 2 3114。对 AS2 3126的接入是通过DNAI 2 3114。从UPF1 3120和UPF2 3104到AS1 3120的业务受到业务转向配置文件1 3112和路由配置文件1 3122的限制。从UPF2 3104、UPF3 3106 和UPF4 3108到AS23126的业务受到业务转向配置文件2 3116和路由配置文件2 3124的限制。因此,来自UPF23104的业务可以基于目标应用位置受不同的业务转向配置文件的限制。

路由配置文件1 3122对应于应用位置AS1 3120,其与DNAI1 3110和DNAI2 3114相关联。路由配置文件2 3124对应于应用位置AS2 1326,其与DNAI2 3114相关联。

UPF和DNAI之间的关联可以暗示UPF可以使用在与DNAI相关联的业务转向配置文件中指定的信息来支持面向DNAI的业务转向。例如,UPF2 3104与DNAI1 3110和 DNAI23112相关联。因此,UPF2 3104能够引导面向两个DNAI的业务。

在NEF、PCF和SMF中配置的信息映射如下所示:

@NEF:应用位置←→路由配置文件

@PCF:路由配置文件←→DNAI;

DNAI←→业务转向配置文件

@SMF:业务转向配置文件←→UPF

PCF不一定需要知道路由配置文件的内容,并且同样的,SMF不一定需要知道业务转向配置文件的内容。

在图31所示的实施例中,存在可用于每种不同类型的网络功能的最小信息集。AF应该可以接入应用程序位置(例如,根据应用程序位置的传输地址或网络地址)。DNAI应该可以访问与和其相关联的应用程序位置相关联的路由配置文件。UPF应该可以访问与其相关联的DNAI的业务转向配置文件。这些节点和功能的配置使得它们被提供有该信息,或者提供对该信息的访问,可以由许多不同的管理面功能中的任何一个来执行,例如网络管理器、切片管理器、服务管理器和AF中的至少一个。例如,AF可以向DNAI提供必要的信息,而管理计划功能向NEF、PCF、SMF和UPF提供必要的信息。

可以由SMF提供的N6隧道信息由UPF用于建立N6隧道,并用于确定应用于通过 N6隧道发送的UL分组的处理。N6隧道信息可以包括隧道类型,例如IP隧道、以太网隧道、IPv6/UDP隧道等。它可以包括隧道端点标识符或地址、端口号以及其他隧道协议参数的信息。可以使用业务转向配置文件ID(其本身可以从例如SMF的功能获得)来获得业务转向参数。可以从本地配置获得业务转向参数。如果没有在UPF本地预先配置业务转向参数,则UPF可以从例如SMF的功能获得它们。如果SMF向UPF提供业务转向参数,则SMF可以不向UPF提供业务转向配置文件ID。可以封装通过N6隧道发送的分组,并且可以将业务转向信息嵌入外部报头中。该外部报头还可以包括要应用于UL分组的处理的标识。

如将理解的,可以通过CP功能来配置UP中的业务被路由和处理的方式。对于受应用影响的业务路由,配置过程可以开始于AF执行请求过程以向网络发送应用位置通知。 AF可以向NEF提供应用位置(例如,在传输地址中)和N6隧道信息(如果有的话)。 NEF可以将从AF接收的应用位置映射到路由配置文件。然后,NEF可以将路由配置文件 ID和N6隧道信息发送到PCF。PCF可以将路由配置文件ID映射到至少一个DNAI。该路由配置文件ID还可以映射到业务转向配置文件,例如,通过映射的至少一个DNAI。基于这些映射,可以生成业务转向策略。业务转向策略通常将指定一个或多个业务转向配置文件ID、路由配置文件ID和N6隧道信息。业务转向策略还可能包含其他信息,例如有效性条件。

对于非IP业务,通常需要N6隧道信息。对于IP业务,它可以是可选的。如果在处理IP业务时未使用N6隧道,则业务转向配置文件和路由配置文件中的业务路由参数可以一起描述如何通过N6端到端路由业务。

现在讨论在会话建立过程(或会话修改过程)期间执行应用对业务路由的影响的示例。该过程可以从PCF向SMF发送业务转向策略开始。然后,SMP可以将业务转向配置文件ID(通常包含在业务转向策略中,但可选地随策略一起提供)映射到UPF。然后,PCF 可以执行UPF/业务转向选择过程,并将所选择的业务转向配置文件ID和N6隧道信息(由策略携带)提供给为PDU会话选择的UPF。SMF可以在将N6隧道信息发送到UPF之前将其编译/处理,例如,生成用于UPF的隧道报头以应用于UL分组。SMF还可以生成业务转发模板。UPF可以使用TFT将N6隧道映射到UP中用于DL业务的路径。

SMF可以向NEF发送任何N6隧道变更的通知(例如,由于UPF重选而导致的N6 隧道端点变更)。SMF还可以向NEF发送通知以通知NEF业务转向改变,其可以包括 DNAI映射和路由配置文件ID中的至少一个的改变。NEF可以将DNAI映射到传输地址,并将路由配置文件ID映射到相应的应用位置的业务地址。然后,NEF可以向AF提供与 N6隧道变更和业务转向变更(在信息映射之后)相关联的信息。

基于前面的描述,可以理解,本发明的实施例可以提供:

一种用于管理网络上的协议数据单元会话数据业务的方法,该方法包括网络上可用的控制面实体:

接收来自AS控制器的基于应用程序接口(API)的应用系统(AS)位置通知,所述基于 API的AS位置通知识别AS位置和将要与所识别的AS位置相关联的数据业务;以及,发送AS位置通知以定位所述AS。

在一些实施例中,在所述控制面实体发送AS位置通知之前,该方法还包括控制面实体认证AS控制器。

在一些实施例中,认证AS控制器包括将认证请求发送到网络上可用的认证服务器功能(AUSF);并且,从AUSF接收用于指示响应于认证请求的认证结果的认证响应。

在一些实施例中,AS位置通知包括AS重定位通知,所述AS重定位通知改变PDU 会话的现有位置。

在一些实施例中,AS位置通知包括AS位置通知,所述AS位置通知建立未来PDU 会话的位置。

在一些实施例中,AS重定位通知被发送到会话管理功能(SMF)以配置针对重新定位的AS的数据业务的业务转向。

在一些实施例中,AS位置通知被发送到策略控制功能(PCF)以生成用于数据业务的用户面(UP)选择策略和业务转向策略。

一种用于管理与连接到网络的用户设备(UE)交换的协议数据单元(PDU)会话数据业务的方法,该方法包括网络上可用的控制面实体:

从UE接收PDU会话请求;

验证UE上下文并基于用户订阅数据授权会话请求,如果授权,该方法还包括:

为所请求的PDU会话选择和建立用户面(UP)路径;

向UE发送PDU会话请求响应。

在一些实施例中,PDU会话请求包括会话ID。

在一些实施例中,PDU会话请求包括用于所请求的PDU会话的优选SSC模式。

在一些实施例中,PDU会话请求包括指示PDU会话请求专用于与应用标识符相关联的应用的应用标识符。

一种用于将UE连接到网络的方法,包括网络上可用的会话管理功能:

从UE接收PDU会话请求;

为PDU会话选择端到端用户面(UP)路径;

通知所选择的端到端UP路径的网络上可用的应用功能;

向接入节点(AN)发送针对与所选择的端到端UP路径对应的UE建立PDU会话连接的请求。

在一些实施例中,AN包括服务AN,所述服务AN从UE接收PDU会话请求并将PDU 会话请求转发到SMF。

在一些实施例中,PDU会话请求指示锚用户面功能(UPF)位置和应用功能的应用位置。

一种电子设备,包括:

网络接口;

处理器;

用于存储指令的存储器,所述指令在由处理器执行时使得电子设备执行本文中描述的方法。

一种用于管理网络上的协议数据单元会话数据业务的方法,该方法包括网络上可用的网络暴露功能(NEF):

选择网络上可用的策略控制功能(PCF);

向PCF发送用户面(UP)选择通知策略更新请求;和

接收UP选择通知策略更新响应。

在一些实施例中,选择网络上可用的策略控制功能(PCF)是基于UP选择通知订阅请求的接收,并且其中该方法还包括:

发送UP选择通知订阅响应。

在一些实施例中,从网络上可用的应用功能(AF)接收的UP选择通知订阅请求,并且其中UP选择通知订阅响应被发送到AF。

一种管理网络的方法,该方法包括在支持一个或多个应用的应用功能实体和被配置为管理网络的相应切片中的业务流的切片管理功能实体之间交换用户面管理信息。

用于管理网络的相应切片中的业务流的切片管理功能实体,该切片管理功能实体被配置为与支持网络的一个或多个应用的应用功能实体交换用户面管理信息。

支持网络中的一个或多个应用的应用功能实体,该应用功能实体被配置与切片管理功能实体交换用户面管理信息,该切片管理功能实体被配置为管理网络的相关切片中的业务流。

在一些实施例中,用户面管理信息包括以下中的一个或两者:

运营商策略信息或事件;和

由应用功能实体支持的应用程序的业务要求。

一种用于在通信网络的网络节点的处理单元上执行的网络实体执行的建立PDU会话的方法,包括所述网络实体执行以下步骤:

从UE接收包括应用标识符的会话请求;

代表UE向网络暴露功能(NEF)发送认证/授权请求;

从NEF接收认证/授权响应;和

基于认证/授权响应授权PDU会话。

在一些实施例中,网络实体包括会话管理功能。

在一些实施例中,网络实体通过NEF将认证/授权请求发送到第三方实体。

在一些实施例中,网络实体通过NEF从第三方实体接收认证/授权响应。

一种网络节点,用于在通信网络上建立PDU会话,所述网络节点包括:

处理器,用于使网络节点能够:

从UE接收包括应用标识符的会话请求;

代表UE向网络暴露功能(NEF)发送认证/授权请求;

从NEF接收认证/授权响应;和

根据认证/授权响应授权PDU会话。

在一些实施例中,使网络节点能够充当会话管理功能。

在一些实施例中,网络节点通过NEF将认证/授权请求发送到第三方实体。

在一些实施例中,网络节点通过NEF从第三方实体接收认证/授权响应。

一种用于在通信网络的网络节点的处理单元上执行的网络实体执行的建立PDU会话的方法,包括所述网络实体执行以下步骤:

从UE接收会话请求;

如果会话请求中不包含应用标识符,则检测与会话请求相关的应用业务,并向控制面实体发送指示应用业务检测并请求应用业务转向重选的通知;和

如果会话请求包括应用标识符,则向控制面实体发送PDU会话旨在用于与应用标识符相关联的应用业务的通知。

在一些实施例中,网络实体包括会话管理功能。

在一些实施例中,如果会话请求包括应用标识符,则该方法还包括:

通过NEF向第三方实体发送认证/授权请求。

在一些实施例中,如果会话请求包括应用标识符,则该方法还包括:通过NEF从第三方实体接收认证/授权响应。

一种网络节点,用于在通信网络上建立PDU会话,该网络节点包括:

处理器,用于使网络节点能够:

从UE接收会话请求;

如果会话请求不包括应用标识符,则网络节点可用于检测与会话请求有关的应用业务,并向控制面实体发送指示应用业务检测并请求重新选择应用业务转向的通知;和

如果会话请求包括应用标识符,则网络节点可用于向控制面实体发送PDU会话旨在用于与应用标识符相关联的应用业务的通知。

在一些实施例中,使网络节点能够充当会话管理功能。

在一些实施例中,如果会话请求包括应用标识符,则网络节点还可用于通过NEF向第三方实体发送认证/授权请求。

在一些实施例中,如果会话请求包括应用标识符,则网络节点还可用于通过NEF从第三方实体接收认证/授权响应。

一种用于在通信网络的网络节点的处理单元上执行的由网络实体执行的建立PDU会话的方法,包括所述网络实体执行以下步骤:

从UE接收包括应用标识符的会话请求;

获取与应用程序标识符关联的PCC规则;和

根据获取的PCC规则为PDU会话配置应用业务处理策略。

在一些实施例中,网络实体包括会话管理功能。

一种网络节点,用于在通信网络上建立PDU会话,该网络节点包括:

处理器,用于使网络节点能够:

从UE接收包括应用标识符的会话请求;

获取与应用程序标识符关联的PCC规则;和

根据获取的PCC规则为PDU会话配置应用业务处理策略。

在一些实施例中,网络节点能够充当会话管理功能。

一种用于在通信网络的网络节点的处理单元上执行的由网络实体执行的建立PDU会话的方法,包括所述网络实体行以下步骤的:

从会话管理实体接收包括应用标识的第三方认证/授权请求;

基于第三方认证/授权请求选择应用功能(AF);和

向所选AF发送第三方认证/授权请求。

在一些实施例中,网络实体包括网络暴露功能(NEF)。

在一些实施例中,会话管理实体包括会话管理功能(SMF)。

在一些实施例中,该方法还包括:

从所选AF接收认证/授权响应。

在一些实施例中,该方法还包括:

将认证/授权响应发送到会话管理实体。

在一些实施例中,AF在会话管理实体外部,并且所述AF直接与会话管理实体的通信不可操作。

在一些实施例中,网络实体和会话管理实体是核心网络功能,并且其中所选择的AF 在核心网络外部。

应了解,本文提供的实施例方法的一个或一个以上步骤可由对应单元或模块执行。例如,信号可以由发送单元或发送模块发送。信号可以由接收单元或接收模块接收。信号可以由处理单元或处理模块处理。其他步骤可以由特定于那些步骤的模块或功能元件执行。各个单元/模块可以实现为专用硬件,在由通用硬件或其组合组成的硬件平台上执行的软件。例如,一个或多个单元/模块可以实现为集成电路,例如现场可编程门阵列(fieldprogrammable gate array,FPGA)或专用集成电路(application-specific integratedcircuits, ASIC)。应当理解,在模块是软件的情况下,它们可以存储在存储器中并由处理器全部或部分地根据需要单独或一起检索,以在需要时在单个或多个实例中进行处理。模块本身可以包括用于进一步部署和实例化的指令。

尽管已经参考本发明的具体特征和实施例描述了本发明,但显然可以在不脱离本发明的情况下对其进行各种修改和组合。因此,说明书和附图应简单地视为由所附权利要求限定的本发明的说明,并且预期能涵盖落入本发明范围内的任何和所有修改、变化、组合或等同物。

去获取专利,查看全文>

相似文献

  • 专利
  • 中文文献
  • 外文文献
获取专利

客服邮箱:kefu@zhangqiaokeyan.com

京公网安备:11010802029741号 ICP备案号:京ICP备15016152号-6 六维联合信息科技 (北京) 有限公司©版权所有
  • 客服微信

  • 服务号