CN114402640A - 用于传输层拥塞控制和基于扩展的提前服务质量通知的存在点优化的边缘计算技术 - Google Patents

用于传输层拥塞控制和基于扩展的提前服务质量通知的存在点优化的边缘计算技术 Download PDF

Info

Publication number
CN114402640A
CN114402640A CN202080064536.3A CN202080064536A CN114402640A CN 114402640 A CN114402640 A CN 114402640A CN 202080064536 A CN202080064536 A CN 202080064536A CN 114402640 A CN114402640 A CN 114402640A
Authority
CN
China
Prior art keywords
mec
network
iqn
application
edge
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202080064536.3A
Other languages
English (en)
Inventor
M·菲利浦
D·萨贝拉
G·纳迪尼
G·斯蒂亚
A·维迪斯
L·戈梅斯波尔塔
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Intel Corp
Original Assignee
Intel Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intel Corp filed Critical Intel Corp
Publication of CN114402640A publication Critical patent/CN114402640A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30Services specially adapted for particular environments, situations or purposes
    • H04W4/40Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • H04W28/0289Congestion control
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • H04L67/561Adding application-functional data or data for application control, e.g. adding metadata
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • H04W28/0226Traffic management, e.g. flow control or congestion control based on location or mobility
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • H04W28/0231Traffic management, e.g. flow control or congestion control based on communication conditions
    • H04W28/0236Traffic management, e.g. flow control or congestion control based on communication conditions radio quality, e.g. interference, losses or delay
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • H04W28/0273Traffic management, e.g. flow control or congestion control adapting protocols for flow control or congestion control to wireless environment, e.g. adapting transmission control protocol [TCP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • H04W28/0284Traffic management, e.g. flow control or congestion control detecting congestion or overload during communication
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/16Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
    • H04W28/24Negotiating SLA [Service Level Agreement]; Negotiating QoS [Quality of Service]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • H04W28/08Load balancing or load distribution
    • H04W28/084Load balancing or load distribution among network function virtualisation [NFV] entities; among edge computing entities, e.g. multi-access edge computing

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Quality & Reliability (AREA)
  • Library & Information Science (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

所公开的实施例提供了一种用于网络拥塞标识和控制以及用于提供预测QoS通知的边缘计算机制。网络拥塞控制实施例能够在发射器/发送器设备处实现情境知晓、位置知晓、无线电网络信息知晓的拥塞事件标识和控制,其经由边缘计算服务提供利用前述信息的新类别的拥塞控制算法,其中边缘计算框架充当代理。预测QoS通知包括对无线电信号质量和状况的预测,以及预测边缘或云计算资源。可描述和/或要求保护其他实施例。

Description

用于传输层拥塞控制和基于扩展的提前服务质量通知的存在 点优化的边缘计算技术
相关申请的交叉引用
本申请要求2019年10月4日提交的美国临时申请第62/911,048号和2020年7月2日提交的美国临时申请第63/047752号的优先权,这些临时申请中的每一临时申请的内容通过引用以其整体合并于此。
技术领域
本文描述的实施例总体上涉及边缘计算、网络通信和通信系统实现方式,并且具体地涉及在多接入边缘计算(MEC)系统和网络中实现交通工具对外界(V2X)通信的技术。
背景技术
物联网(IoT)设备是可以在网络上通信的物理对象或虚拟对象,并且可以包括传感器、致动器、和其他输入/输出组件,诸如以从真实世界环境中收集数据或执行动作。例如,IoT设备可包括嵌入或附接到日常事物(诸如建筑物、交通工具、包裹等)的低功率设备,以提供对这些事物的附加水平的人工感官知觉。最近,IoT设备已变得越来越流行,因此使用这些设备的应用已经激增。IoT设备和多接入边缘计算(MEC)服务的部署已经引入了许多高级用例和场景,这些用例和场景在网络的边缘处或以其他方式涉及网络的边缘而发生。
一般来说,边缘计算是指对处于较靠近于网络的“边缘”或网络的“边缘”的集合的位置处的计算和资源的实现、协调和使用。此种布置的目的在于改善总拥有成本,减少应用和网络等待时间,减少网络回程通信量和相关联的能耗,改善服务能力,并且改善对安全或数据隐私性要求的合规性(尤其是与常规云计算相比)。可以执行边缘计算操作的组件(“边缘节点”)可以驻留在系统架构或自组织服务所需要的无论什么位置中(例如,在高性能计算数据中心或云安装中;在规定的边缘节点服务器、企业服务器、路边服务器、电信中央局中;或在消费边缘服务而被服务的本地或对等的边缘处设备中)。
适于进行边缘计算的应用包括但不限于:传统网络功能的虚拟化(例如,用于操作电信或互联网服务)以及下一代特征和服务的引入(例如,用于支持5G网络服务)。预计广泛地利用边缘计算的用例包括:连接的自驾驶汽车、监控、物联网(IoT)设备数据分析、视频编码和分析、位置知晓的服务、智慧城市中的设备感测、以及许多其他网络和计算密集型服务。
在一些场景中,边缘计算可提供或主控类云分布式服务,以为应用和经协调的服务实例提供在许多类型的存储和计算资源之间的编排和管理。随着端点设备、客户端和网关尝试接入更靠近网络边缘的位置处的网络资源和应用,还预计边缘计算与针对IoT和雾/分布式联网配置开发的现有用例和技术紧密集成。
附图说明
在附图中(这些附图不一定是按比例绘制的),同样的数字可描述不同视图中的类似组件。具有不同的字母后缀的相同的数字可表示类似组件的不同实例。在所附附图的图中通过示例的方式而非限制性地图示出一些实施例,其中:
图1A和图1B描绘了根据各个实施例的、利用MEC技术为V2X应用提供支持的示例V2X通信系统。图2描绘了根据各个实施例的包括MEC系统架构的示例V2X系统。图3描绘了根据各个实施例的实现V2X信息服务(VIS)与V2X控制功能之间的通信的示例架构。图4A描绘了根据各个实施例的示例V2X过程。图4B图示出根据各个实施例的VIS API的资源统一资源指示符(URI)结构。
图5图示出示例网络调助手(NetAssist)架构。图6图示出根据各个实施例的服务器侧传输协议运行时间(TPR)实体和边缘计算服务之间的示例交互。图7示出根据各个实施例的示例拥塞窗口场景。图8示出第一TPR实施例的示例。图9示出第二TPR实施例的示例。图10图示出根据各个实施例的示例查询/响应过程。图11图示出根据各个实施例的示例订阅/通知过程。
图12描绘了根据各个实施例的其中MEC主机与向交通工具用户装备(UE)提供V2X通信服务的网络接入节点(NAN)共同定位的示例性V2X系统场景。图13描绘了根据各个实施例的高清(HD)地图数据收集、合并和分发的示例。图14A描绘了由预测性QoS支持的示例C-V2X应用。图14B描绘了通用的提前QoS通知的示例结构。图15描绘了用于实施本文中的实施例的另一示例性场景。图16描绘了根据各个实施例的用于产生和消费e-IQN的各种实体之间的示例交互点。图17、图18、图19和图21描绘了用于实践本文中的实施例的各方面的相应过程。图20描述了将MEC系统的MEO与联合管理器连接的联合管理参考点Mfm-fed。
图22图示出用于边缘计算的边缘云配置的概览。图23图示出端点、边缘云和云计算环境之间的操作层。图24图示出用于边缘计算系统中的联网和服务的示例方式。图25图示出示例MEC系统参考架构。图26图示出可从示例边缘计算系统部署的、网络功能虚拟化(NFV)环境中的MEC参考架构。
图27A、图27B和图27C描绘了边缘计算硬件配置的示例。图28和图29描绘了(多个)边缘计算系统中的各种计算节点的示例组件。图30描绘了边缘计算系统中的示例移动计算设备。图31描绘了边缘计算系统中可配置的服务器机架的示例。
具体实施方式
下列实施例总体上涉及数据处理、服务管理、资源分配、计算管理、网络通信、应用分区、以及通信系统实现方式,并且具体地涉及用于调整各种边缘计算设备和实体以动态地支持分布式边缘计算环境中的多种实体(例如,多个租户、用户、利益相关方、服务实例、应用等)的技术和配置。
随时间推移,交通工具的操作和控制正变得更加自主,并且在未来,大多数交通工具将可能变成完全自主的。包括某种形式的自主性或以其他方式辅助人类操作者的交通工具可被称为“计算机辅助或自主驾驶”交通工具。计算机辅助或自主驾驶(CA/AD)交通工具可包括人工智能(AI)、机器学习(ML)、和/或用于实现自主操作的其他类似的自学习系统。典型地,这些系统感知其环境(例如,使用传感器数据)并执行各种动作以使成功的交通工具操作的可能性最大化。
交通工具对外界(V2X)应用(被简称为“V2X”)包括以下通信类型:交通工具对交通工具(V2V)、交通工具对基础设施(V2I)和/或基础设施对交通工具(I2V)、交通工具对网络(V2N)和/或网络对交通工具(N2V)、交通工具对行人通信(V2P)、以及ITS站(ITS-S)对ITS-S通信(X2X)。V2X可以使用协作式认知来为终端用户提供更智能的服务。这意味着诸如交通工具站或交通工具用户装备(vUE)之类的实体(包括诸如CA/AD交通工具、路边基础设施或路边单元(RSU)、应用服务器、以及行人设备(例如,智能电话、平板等))收集其本地环境的知识(例如,接收自附近的其他交通工具或传感器装备的信息)以处理并共享该知识,以便提供用于碰撞警告系统、自主驾驶等等的更加智能的服务(诸如协作式感知、操纵协调等等)。
一个此类V2X应用包括智能运输系统(ITS),ITS系统是用于利用信息和通信技术来支持对商品和人类的运输以便高效且安全地使用运输基础设施和运输装置(例如,汽车、火车、飞行器、船只等)的系统。既在国际级别又在区域级别,在各种标准化组织中对ITS的要素进行标准化。
ITS中的通信(ITSC)可利用各种现有的和新的接入技术(或无线电接入技术(RAT))和ITS应用。这些V2X RAT的示例包括电器和电子工程师协会(IEEE)RAT和第三代合作伙伴(3GPP)RAT。IEEE V2X RAT包括例如,交通工具环境中的无线接入(WAVE)、专用短程通信(DSRC)、5GHz频带中的智能运输系统(ITS-G5)、IEEE 802.11p协议(其为WAVE、DSRC和ITS-G5的层1(L1)和层2(L2)部分),并且有时包括被称为全球微波接入互操作性(WiMAX)的IEEE 802.16协议。术语“DSRC”是指在美国一般使用的5.9GHz频带中的交通工具通信,而“ITS-G5”是指在欧洲的5.9GHz频带中的交通工具通信。由于本实施例可适用于可在任何地理或政治区域中使用的任何数量的不同RAT(包括基于IEEE 802.11p的RAT),因此贯穿本公开可以可互换地使用术语“DSRC”(在美国等的区域中使用)和“ITS-G5”(在欧洲等的区域中使用)。3GPP V2X RAT包括例如,使用长期演进(LTE)技术的蜂窝V2X(C-V2X)(有时被称为“LTE-V2X”)和/或使用第五代(5G)技术的蜂窝V2X(C-V2X)(有时被称为“5G-V2X”或“NR-V2X”)。可将其他RAT用于ITS和/或V2X应用,这些RAT诸如使用UHF和VHF频率、全球移动通信系统(GSM)和/或其他无线通信技术的RAT。
所公开的实施例涉及用于在边缘计算系统/网络(诸如多接入边缘计算(MEC)系统)中实现交通工具对外界(V2X)通信的技术。V2X系统场景由高移动性和动态拓扑来表征,其中无线电网络信息、位置信息的准确性和及时性可能受到环境状况和网络基础设施的部署密度和/或交通工具站的密度的阻碍。
本文的实施例通过还包括边缘云计算资源的预测来增强预测QoS通知。该跨域的信息集合被提议称为可由多个系统行为者(诸如交通工具(例如V2X应用)、汽车OEM和MEC服务提供商)利用的增强提前QoS通知(e-IQN)信息。实施例还包括确保QoS预测可由边缘(例如MEC)汽车服务提供商在利用V2X API的情况下以可互操作的方式访问的信令框架。本实施例还包括用于MEC PoP优化的方案,该方案将预测QoS信息作为输入,涉及跨地理区域的边缘编排器(例如MEC编排器(MEO))。可描述和/或要求保护其他实施例。
1.MEC V2X信息服务(VIS)
交通工具对外界(V2X)应用(简单地称为“V2X”)包括以下四种类型的通信交通工具对交通工具(V2V)、交通工具对基础设施(V2I);交通工具对网络(V2N)和交通工具对行人通信(V2P)。V2X可以使用协作式认知来为终端用户提供更智能的服务。这意味着诸如交通工具站或交通工具用户装备(vUE)、路边基础设施或路边单元(RSU)、应用服务器、以及行人设备(例如,智能电话、平板设备等)之类的实体收集其本地环境的知识(例如,接收来自附近区域中的其他交通工具或传感器装备的信息)以处理并共享该知识,以便提供用于碰撞警告系统、自主驾驶等的更加智能的服务(诸如协作式感知、操纵协调等等)。V2X应用利用底层接入技术或无线电接入技术(RAT)来传达消息以供进行协作式认知。这些RAT可包括例如基于IEEE 802.11p的协议(诸如DSRC和ITS-G5)、基于3GPP蜂窝的协议(诸如5G-V2X)和/或LTE-V2X协议。虽然本文中的实施例在汽车的情境中讨论,但实施例也可应用于其他类型的交通工具,包括飞行器、船只等等。
多接入边缘计算(MEC)是允许应用在接入网络的边缘处被实例化且向用户装备(UE)提供低等待时间且近接近度环境的技术。结果是,预期垂直产业(诸如汽车产业)从MEC基础设施的部署以及无线电接入网络(RAN)的部署中显著获益。这些RAN可由不同的MNO来操作和/或可操作不同的RAT。
无线通信是协作式智能运输系统(ITS)的一项关键使能技术。参与V2X通信的道路用户(例如交通工具、骑自行车者和行人)可能使用由不同运营商提供的服务,这些运营商提供不同的网络和/或使用不同的无线电接入技术(RAT)。包括由不同运营商提供的网络和包括不同RAT的环境被称为“多供应商、多网络和多接入环境”。图1A和图1B示出多供应商、多网络和多接入环境的示例。
图1A描绘了利用为V2X应用提供支持的MEC技术的示例V2X通信系统100。具体地,图1A描绘了涉及使用MEC系统的V2X通信系统100,其中道路运营商(或ITS运营商)旨在在跨国、跨运营商、跨供应商的环境中提供V2X服务。MEC系统支持和/或向终端设备(例如,图1A中的交通工具ITS站(V-ITS-S)101)提供各种服务,这些服务中的每个服务可具有不同的要求或约束。例如,一些服务可具有优先级或服务质量(QoS)约束(例如,用于自主V-ITS-S101的交通数据相比于信息娱乐数据可具有更高的优先级)、可靠性和弹性(例如,交通数据可要求任务关键型可靠性,而信息娱乐数据可被允许某种误差方差)、以及功率、冷却和形状因子约束。UE应用(app)使用各种接口来请求MEC系统在该MEC系统中运行应用(例如,MEC应用)或在MEC系统中移动应用或将应用从MEC系统向外移动。此类接口包括例如用于内部MEC管理、用于控制MEC平台之间的通信的Mp3参考点以及用于外部接入的Mx2参考点。
在典型的多运营商场景中,多个运营商(例如,图1A中的MNO-1和MNO-2)提供用于为V-ITS-S 101(也被称为“交通工具站”、“交通工具用户装备”或“vUE”)实现网络连接性的基础设施,包括例如由MNO-1提供的网络接入节点(NAN)110-1和核心网络150-1以及由MNO-2提供的NAN110-2和核心网络150-2。“运营商”是指拥有或控制提供通信和/或网络相关的服务(包括无线电频谱分配(包括来自监管机构的一个或多个无线电频谱许可)、计费和订阅相关的服务、设备供应和/或其他类似服务)所需的基础设施装备(包括无线电基础设施、核心网络和/或回程基础设施等)的实体或组织。运营商提供使用空中(OTA)或无线通信信道接入移动网络或无线环境的技术能力。如本文中所使用的术语“运营商”可被认为是与以下各项同义的和/或被称为以下各项:网络运营商、移动网络运营商(MNO)、蜂窝网络运营商、无线服务提供商、无线电信运营商、移动网络电信运营商、虚拟MNO等等。
此外,NAN 110-1和110-2可以是宏蜂窝小区基站、小型和/或微型蜂窝小区基站、接入点(AP)和/或其他类似的网络元件。AP可以是例如无线路由器、路边ITS站(R-ITS-S)或路边单元、网关装置、中央中枢,等等。基站可以是例如3GPP长期演进(LTE)、演进节点B(eNB)、3GPP 5G/NR下一代eNB(ng-eNB)、和/或下一代NodeB(gNB)等等。NAN 110的集合还可被称为“接入级边缘网络”或“接入级边缘”。NAN节点110可配置或可操作以执行传输资源的设置(例如,用于CDN服务和/或其他应用级服务)以及调度信令资源以提供底层接入网络/RAT的网络服务。
在图1A的示例中,NAN 110-1与边缘计算节点140-1共同定位,并且NAN 110-2与边缘计算节点140-2共同定位。在一个示例中,边缘服务器140或边缘计算节点140可以是多接入边缘计算(MEC)主机或任何其他边缘计算节点(诸如本文中所讨论的那些边缘计算节点)。MEC主机140是包含MEC平台和虚拟化基础设施以向MEC应用提供计算、存储和网络资源的实体。MEC平台是在特定MEC主机140的虚拟化基础设施上运行MEC应用并使得它们能够提供和消费MEC服务的、以及可以向其自身提供数个MEC服务的功能(包括硬件和软件元件)的集合。MEC应用是可以在MEC系统100内的MEC主机140上实例化并且可以提供或消费MEC服务的应用,并且MEC服务是经由MEC平台由MEC平台自身或由MEC应用提供的服务。MEC主机140可由MNO-1和MNO-2分别提供,或者MEC主机140可由单独的边缘网络服务提供商提供。在该示例中,在T1处的V-ITS-S 101能够经由NAN 110-1和核心网络150-1从MNO-1接收网络连接性,并且能够经由MNO-1基础设施从远程应用服务器160接收服务。随着V-ITS-S 101的行进,V-ITS-S 101在T2处经历的暂时没有无线电覆盖导致漫游情形,并且随后能够经由MNO-2基础设施(例如,NAN 110-2和核心网络150-2)接收服务。核心网络150可以是,例如,LTE或5G/NR核心网络。
在第一实现方式中,NAN 110是RSU或R-ITS-S。在第二实现方式中,NAN 110是RAN或RAN内的基站/RAN节点(例如,eNB、ng-eNB、gNB等)。
在第三实现方式中,NAN 110包括gNB中央单元(CU)或ng-eNB-CU(参见例如,3GPPTS 38.401版本16.2.0(2020年03月))。CU可被实现为基带单元(BBU)、无线电装备控制器(REC)、无线电云中心(RCC)、集中式RAN(C-RAN)、虚拟化RAN(vRAN)等等(尽管这些术语可指代不同的实现方式概念)。在该实现方式中,gNB-CU或ng-eNB-CU与一个或多个gNB分布式单元(DU)和/或一个或多个ng-eNB-DU通信地耦合,并且每个DU可与一个或多个无线电单元(RU)(也被称为远程无线电头端(RRH)、远程无线电单元(RRU)等等)通信地耦合。在一些实现方式中,一个或多个RU可以是RSU。
在第四实现方式中,NAN 110是CU/DU/RU拆分式架构中的一个或多个DU和/或一个或多个RU,并且gNB-CU和/或ng-eNB-CU由与NAN 110(包括上述CU、DU和RU)共同定位的(或通信地耦合)的边缘计算节点140提供(例如,虚拟化)。在一个示例中,边缘计算节点140可以是多接入边缘计算(MEC)主机或任何其他边缘计算节点(诸如本文中所讨论的那些边缘计算节点)。在该实现方式中,边缘计算节点140可操作或包括上述CU,或者可提供与CU分离的管理应用/服务。
在第五实现方式中,管理应用/服务是由云计算服务和/或一个或多个云计算节点(统称为“云”等)提供的虚拟化实体。在一个示例中,CU可在由云的虚拟化基础设施提供的(多个)虚拟机(VM)和/或(多个)软件容器内运行。在该实现方式中,云可操作或包括前述CU,或者可提供与CU分离的管理应用/服务。附加地或替代地,云可操作虚拟化网络交换机(例如,Open vSwitch等),以提供此类服务。
在第六实现方式中,管理应用/服务是蜂窝核心网络(诸如5G核心网络(5GC)等)中的一个或多个网络功能(NF)提供的(多个)服务。在该实现方式中,一个或多个现有的NF可以提供管理应用/服务,或者可以定义新的NF以提供管理应用/服务。
在第七实现方式中,管理应用/服务是由蜂窝核心网络中的、数据网络等中的单独的或新的NF提供的服务。
在第八实现方式中,管理应用/服务是指定的或选定的V-ITS-S 101(例如,“主”ITS-S、集群或队列领导方等),其可被授权代表其他ITS-S 101等进行协商。
在上述实现方式中的许多实现方式中,管理应用/服务与多个RSU、多个基站等通信地耦合,其中,服务区域(例如,图1A中被标记为MON-1和MNO-2的区域)涵盖多个RSU和/或基站中的每一个的蜂窝小区或服务区域中的一些或全部。
一个具有挑战性的情形是当ITS运营商试图向连接至不同运营商(例如MNO-1和MNO-2)、甚至暂时没有无线电覆盖的V-ITS-S 101提供相同或连续的V2X服务之时。此种用例还由于多个MEC供应商的存在而被复杂化,这导致需要实现不同MEC系统之间的通信。此种用例在UE应用具有相对较高的QoS约束时进一步被复杂化。此外,NAN 110的蜂窝小区覆盖区域内充足的无线电资源的分配不必保证V2X通信中特定的QoS(或QoS性能)。较差的QoS性能也可链接至由于NAN 110处的覆盖缺乏、信号干扰、效率低下的切换机制、不足的传输功率管理和切换机制导致的较差的信号接收。
如图1B所示,在传统的V2X系统(没有VIS服务)中,MNO(例如,MNO-1和MNO-2)之间的互连在远程侧(例如,远程应用服务器160)处被终止,其中在高端到端(e2e)等待时间方面具有明显的缺点。另一方面,利用VIS服务(在MEC系统140之间的互连188上实现“水平通信”),MNO之间的互连可以以低e2e等待时间实现。VIS披露了关于PC5配置参数的信息以及与Uu接口相关的信息(例如,单播和多媒体广播多播服务(MBMS)),并管理多运营商环境,这允许离开一个MNO-1的覆盖区域并进入另一个MNO-2的覆盖区域的V-ITS-S 101继续接收服务,而不具有任何服务中断,并且保障e2e性能。
V2X应用和服务包括例如,安全性应用/服务、便捷性应用/服务、高级驾驶辅助应用/服务、以及易受伤害道路使用者(VRU)应用/服务等等。安全性应用/服务的示例包括交叉口移动辅助(IMA)和队列警告(QW)。IMA被设计成用于通过向驾驶员警告在交叉口处从横向方向逐渐接近的交通工具来避免交叉口交叉碰撞。交叉口碰撞包括交叉口、交叉口相关、车道/小径和车道访问相关的碰撞。对道路上的交通工具队列的QW可引起潜在的危险并造成交通延迟(例如,当转向队列延伸至其他车道时)。使用V2X服务,可以事先使得队列信息可用于其他V-ITS-S 101,这使碰撞的可能性最小化并允许进行缓解动作。
便捷性应用/服务包括例如远程信息处理、软件更新、信息娱乐等等。这些应用/服务中的一些可以利用现有的接入技术来实现,并且部分地已被一些汽车制造商支持。这V2X用例组要求在V-ITS-S 101与后端服务器/服务之间启用成本效率的通信。
高级驾驶辅助应用/服务(也被称为“高级驾驶员辅助系统”或“ADAS”)是在驾驶或驻停交通工具时帮助交通工具驾驶员的电子系统(包括硬件和软件元件),并且典型地采用交通工具中实现的各种微控制器、电子控制单元(ECU)、传感器、和/或功率半导体设备/系统(在本文中统称为“驾驶控制单元”或“DCU”)。收集对V2X最具挑战性的要求。这些应用/服务也可适用于自主驾驶应用/服务。这些V2X应用/服务可能需要以高可靠性和低等待时间的方式并行分发相对大量的数据,并且通常受益于预测的可靠性。这意味着利用ADAS的V-ITS-S 101应该具有接收网络可用性和/或QoS的预测,以便提前规划的可能性。实时态势知晓对于自主交通工具来说是至关重要的,特别是在改变的道路状况的情况下的关键路段(例如,由另一交通工具在一定时间前检测到的新对象/障碍物,改变的天气和/或环境状况等)。出于此目的和其他目的,相关的高清(本地)地图需要经由从后端服务器/服务(例如,远程应用服务器160)下载而变得可用。实时态势知晓和高清(本地)地图的用例不应仅被视为分发关于相对缓慢改变的道路状况的信息的情形。该情形应扩展到经由路边单元向交通参与者实时地分发和聚合本地上可用的信息。另一ADAS应用/服务是透视(See-Through)(或高清晰度传感器共享)。在该类型的用例中,列队中的诸如卡车、面包车、轿车等之类的交通工具需要共享传感器数据,诸如将其前面的道路状况的图像/视频共享给其后面的交通工具。
附加地,ADAS和/或自主驾驶应用/服务可能涉及使用可操作用于观察环境状况并确定为促进特定目标而采取的动作的人工智能(AI)代理和/或机器学习(ML)模型。要观察的特定环境条件和要采取的措施可基于操作设计领域(ODD)。ODD包括给定AI代理/ML模型或其特征专门设计成用于起作用的操作条件。ODD可包括操作限制,诸如环境、地理和时间限制,和/或某些交通或道路特征的必要存在或不存在。在实施例中,各个AI代理和/或经训练的ML模型/算法可配置或可操作用于控制主机V-ITS-S 101的相应的控制系统/DCU。在这些实施例中,基于控制系统本身和/或所涉及DCU,要采取的动作和要实现的特定目标可以是特定的或个性化的。附加地,一些动作或目标可以是动态驾驶任务(DDT)、对象和事件检测与响应(OEDR)任务,或者其他非交通工具操作相关的任务,这取决于AI代理和/或经训练的ML模型/算法实现的特定情境。DDT包括在道路交通中操作V-ITS-S 101所需的所有实时操作和战术功能,不包括战略功能(例如,行程安排和目的地和航路点的选择)。DDT包括战术和操作任务,诸如经由转向控制横向交通工具运动(操作);经由加速和减速纵向交通工具运动控制(操作);经由对象和事件检测、识别、分类和响应准备(操作和战术)监控驾驶环境;对象和事件响应执行(操作和战术);操纵规划(战术);以及经由照明、信号和手势等增强醒目性(战术)。OEDR任务可能是DDT的子任务,包括监控驾驶环境(例如,检测、识别和分类对象和事件,并根据需要准备响应)以及对此类对象和事件执行适当的响应,例如,根据需要完成DDT或回退任务。这些功能中的一些功能可由所涉及的AI代理/ML模型触发,或者可由外部实体(诸如远程应用服务器160和/或(多个)MEC主机140)触发。事件/触发器可以是特定于AI代理/ML模型的,并且可以根据特定实施例而变化。
VRU是非机动车道路使用者以及VRU交通工具的使用者。“VRU设备”是指由集成标准ITS站的VRU使用的便携式设备(例如,智能电话、平板设备、可穿戴设备等),尽管术语“VRU”本身既可以指VRU又可以指VRU设备。出于交通安全性的目的(例如,避免碰撞等),与VRU相关的V2X应用/服务利用由VRU提供的信息。这些应用/服务通常要求由这些交通参与者提供的定位信息的高精确性。使用可用的信息以获得更好的、更可靠的准确性的附加手段对于允许真实世界使用从VRU共享的信息是至关重要的。交通工具与VRU之间通过其VRU设备进行协作是改善交通安全性和避免事故的重要的关键因素。
对于这些V2X应用/服务,边缘计算节点140(或MEC主机140)将来自网络的反馈信息提供给V-ITS-S 101以支持V2X功能/应用/服务,从而预测通信信道当前(例如,在等待时间要求、分组到达率、数据服务/连接性的QoS等方面)是可靠的还是不可靠的。MEC系统100还通过支持V-ITS-S 101和/或通过不同的站/装备类型/平台、接入技术、网络或MNO连接的其他道路用户(例如VRU等)之间的V2X信息交换,并使V2X应用/服务和/或各个V-ITS-S 101的多运营商操作能够跨国家范围的接入网络覆盖和跨不同MNO网络的边界提供服务连续性来提供互操作性。MEC系统100(或各个MEC主机140)可能需要在各种连接性参数(如等待时间、PER、信号强度等)将发生改变时向交通工具提供由包括无线电网络功能的可用定位技术辅助的及时准确的定位,和/或预测性质量相关的信息。
边缘计算节点140(例如,MEC主机140)包括V2X信息服务(VIS)应用编程接口(API),该V2X信息服务(VIS)应用编程接口(API)被设计成用于促进汽车用例的多供应商、多网络和多接入环境中的V2X互操作性。这些用例可能涉及不同的交通工具制造商、原始装备制造商(OEM)提供商、网络基础设施供应商、MEC供应商、应用/内容提供商、以及其他利益相关方。
MNO通常特定于地区或特定于国家,并且直接向其自己的消费者(订户)提供服务,同时使用MNO的网络之间的交互工作在核心网络级别下向其他MNO的消费者提供通信。每个MNO均运营其自己的公共陆地移动网络(PLMN),从特定MNO的订户的角度来看,该公共陆地移动网络(PLMN)通常被称为归属PLMN(HPLMN),从不是特定MNO的订户用户的角度来看,该公共陆地移动网络(PLMN)通常被称为访问PLMN(VPLMN)。对于交通工具应用,为道路用户维持V2X服务的连续性(通常具有低等待时间要求)变得具有挑战性,特别是当这些道路使用者从一个MNO的覆盖区域移动到另一个MNO的覆盖区域时。
不同PLMN之间的移动网络级别交互工作用于在3GPP规范规定的此类用例中实现服务连续性,3GPP规范诸如ETSI GS MEC 003版本2.1.1(2019年01月)(“[MEC003]”)、ETSIGS MEC 011版本1.1.1(2017年07月)(“[MEC011]”),ETSI GS MEC 013版本1.1.1(2017年07月)(“[MEC013]”),ETSI GS MEC 014版本1.1.1(2018年02月)(“[MEC014]”),以及ETSI GSMEC 015版本1.1.1(2017年10月)(“[MEC015]”)。此外,还需要MEC系统间的协调,以便(例如,基于MNO之间的协议、漫游和/或到新的PLMN的移交)为在传输中的UE做好准备并减少中断时间。
服务消费者通过V2X API与VIS 280通信,以获取访问的PLMN的必要V2X服务供应信息,以支持PLMN间服务的连续性。MEC应用(app)和MEC平台两者都可以消费VIS 280;并且MEC平台和MEC应用两者都可以是V2X信息的提供商。V2X API也可以被称为“VIS API”等等。下文关于图25和图26更详细地讨论了MEC应用和MEC平台。
图2图示出根据各个实施例的用于提供V2X的示例MEC系统架构200。MEC系统200包括多个MEC主机240(包括MEC主机240-1和MEC主机240-2)中的每一个,其中多个MEC主机240中的每一个可以与图25的MEC系统2500中的MEC主机2502相对应。如前所述,MEC在网络的边缘处为应用开发人员和内容提供商提供云计算功能以及IT服务环境。该环境的特征是超低等待时间和高带宽以及对可由应用利用的无线电网络信息的实时访问。MEC技术准许向移动订户、企业和垂直细分市场灵活并且快速地部署创新应用和服务。具体而言,就汽车行业而言,诸如V2X应用之类的应用需要交换数据,向聚合点提供数据,并且访问提供从大量传感器(由各种汽车、路边单元等)推导出的当地情形的概览的数据库中的数据。
V2X系统200涉及多个MEC主机240和MEC VIS 280的使用。V-ITS-S201、NAN 210(包括NAN 210-1和NAN 210-2边缘计算节点240和远程云260可以分别与图1A和图1B的(多个)V-ITS-S 101、NAN 110和MEC主机140相对应。边缘计算节点240和NAN 210对中的每一对可以构成相应的边缘云,并且远程云260可以包括一个或多个远程应用服务器(例如,图1A和图1B的远程应用服务器160)。
在各个实施例中,MEC系统200(和各个MEC主机240)可以支持特征V2X服务。当MEC系统200支持特征V2X服务时,MEC系统200包括用于将来自网络(例如图1A-图1B中的MNO网络和/或图2中的边缘云)的反馈信息提供给V-ITS-S 201以支持V2X功能的能力,这有助于预测通信信道当前(例如在满足等待时间要求和/或阈值分组到达方面)是可靠的还是不可靠的。支持V2X服务的MEC系统200包括向交通工具提供来自网络的与各连接性参数(如等待时间、PER、信号强度等)何时将要改变有关的质量相关信息的能力。支持V2X服务的MEC系统200包括通过支持在通过不同的接入技术、网络和/或MNO连接的道路使用者之间的V2X信息交换来提供互操作性的能力。支持V2X服务的MEC系统200使得用于V2X站/装备的多运营商操作能够跨国家范围的网络覆盖和跨不同运营商的网络的边界提供服务连续性。支持V2X服务的MEC系统200包括用于在多运营商场景中提供互操作性,使得不同系统中的MEC应用能够彼此安全地通信,以便在没有蜂窝网络覆盖(3GPP域的外部)的情况下实现多运营商系统的同步的能力。支持V2X服务的MEC系统200包括在多运营商场景中提供互操作性的能力,使MEC应用能够与V2X相关的3GPP核心网络逻辑功能(例如图3的V2X控制功能350和/或其他核心网络功能)安全地通信,并从3GPP网络聚集PC5 V2X相关信息(例如PC5配置参数)。
在V2X服务的框架中,V-ITS-S 201主控客户端应用(图2中的UE应用202),并连接到某个MEC主机240(以及相关的MEC应用228)。在存在多个MEC主机240的情况下,VIS 280准许在不同的MEC主机240上运行的MEC应用228之间对信息的披露。MEC主机240中的每一者可以由不同的运营商或服务提供商(例如,MEC供应商或第三方)拥有/管理。在MEC主机240-1和MEC主机240-2上实例化的MEC应用228可以用于提供V2X相关服务,并且可由移动服务运营商、由MEC供应商、或由第三方(例如,OEM、或OEM供应商、或系统集成商)运营。附加地,其他远程应用服务器示例可以位于其他地方,诸如在远程云260中。远程云260可以是任何类型的云基础设施,例如由运营商或由OEM拥有的一个或多个私有云。远程云260还操作一个或多个远程应用265。VIS 280可由MEC平台230或由MEC应用228产生。
在一些方面,MEC平台230(与图26的MEC平台2532和/或MEC平台VNF 2602相对应)可以包括提供MEC VIS 280的MEC V2X API。VIS 280/V2XAPI支持查询和订阅两者(例如,发布/订阅机制),这些查询和订阅通过表述性状态传递(“REST”或“RESTful”)API或通过替代的传输(诸如消息总线)来使用。对于RESTful架构样式,可以为VIS API定义HTTP协议绑定。具体而言,VIS 280准许向MEC应用实例进行与汽车用例的支持有关的信息披露。VIS 280还可准许单个ITS运营商通过可跨越不同国家并涉及多个网络运营商、MEC系统和MEC应用提供商的区域提供V2X应用/服务。出于该目的,VIS 280可以包括以下功能:(a)从3GPP网络聚集PC5 V2X相关信息,以执行用于V2X通信的UE授权(例如,获取V2X授权UE的列表,基于UE订阅获取与授权有关的相关信息,以及获取V2X配置参数,诸如,共同的V2X配置参数集,其可包括PC5配置参数);(b)向同一MEC主机240中的MEC应用228或其他MEC主机240中的MEC应用228暴露在(a)中获取的信息;(c)使MEC应用228能够安全地与V2X相关3GPP核心网络逻辑功能通信(例如,实现MEC主机240与核心网络中的V2X控制功能之间的通信);(d)使不同MEC系统中的MEC应用228能够安全地彼此通信;以及(e)使用合适的MEC API聚集并处理在其他MEC主机/系统中可用的信息(例如,聚集并处理经由V2X/VIS API(参见例如,ETSI GS MEC030版本2.1.1(2020年04月)(此后为“[MEC030]”))、无线电网络信息(RNI)API(参见例如,ETSI GS MEC 012版本1.1.1(2017年07月)(“[MEC012]”))、位置API[MEC011]、UE身份(UE_ID)API[MEC014]、带宽管理(BWM)API[MEC015]、WLAN接入信息(WAI)API(参见例如,ETSI GSMEC 028版本2.1.1(2020年06月)(“[MEC028]”))、固定接入信息(FAI)API ETSI GS MEC029版本2.1.1(2019年07月)(“[MEC029]”)、以及用于访问可在MEC平台230内实现的其他MEC服务236的其他类似API获得的信息,以便预测无线电网络拥塞,并向ITS-S201提供合适的通知。服务注册表238、过滤规则控制231、DNS处置232、数据平面224和虚拟化基础设施222将在下文中关于图25和图26更详细讨论。
从那个角度看,VIS 280与MEC架构(参见例如图25和图26)中的Mp1和Mp3参考点相关。具体地,相关信息经由Mp1参考点从各种服务228和236向MEC应用228披露。Mp3参考点使这些信息能够在不同的MEC平台230之间传输。例如,第二MEC主机240-2也可以实现MEC V2XAPI,MEC V2X API可以提供与MEC主机240-2内实例化的MEC应用228的一个或多个MEC应用的接口。在这方面,MEC主机240-2和MEC主机240-1可经由Mp3接口和MEC V2X API来彼此通信。附加地,在MEC主机240-1内实例化的应用228中的一个或多个应用可经由MEC V2X API以及MEC主机240-1与MEC主机240-2之间的接口来与在MEC主机240-2内实例化的MEC应用228中的一个或多个MEC应用通信。
MEC VIS API以标准化方式向MEC应用228提供信息,这在多供应商场景中提供互操作性。然而,MEC应用228可以以直接方式(例如,不使用MEC平台230)进行通信。在一些实施例中,系统间通信可在MEC编排器(MEO)之间实现。附加地或替代地,可为MEC应用228通信定义可能的Mp3增强(或MEC系统240之间新的参考点)。
(例如,用于披露VIS 280的)MEC V2X API可以作为一般的中间件服务来提供(从而提供从交通工具201和其他V2X元件聚集的信息),并作为主机内的服务(例如,作为RESTful API)向更高的层(例如,主机内实例化的MEC应用228)暴露。在一些方面,MEC V2XAPI可被配置成用于从各个传感器聚集信息和数据。在该方面,MEC V2X API的部署对于同一OEM(例如,汽车制造商)确保跨不同移动网络的服务连续性。如果V2X API的标准实现方式(例如,通过ETSI MEC)被引入,则该功能可对具有MEC功能的5G通信系统中的所有OEM确保相同的基本V2X服务特性。
VIS API/V2X API包括资源和操作。“资源”是具有类型、相关联的数据、对其进行操作的一组方法、以及与其他资源的关系(如果可适用)的对象。资源是RESTful API的基本概念。使用HTTP方法(例如,POST、GET、PUT、DELETE等)通过RESTful API作用于资源。对资源的操作影响相对应的被管理的实体的状态。图4A描绘了VIS API的一些过程/操作。
图4A图示出根据各个实施例的V2X/VIS API过程400A。在图4的过程中,服务消费者(例如,诸如MEC应用或MEC平台之类的VIS消费者)发送对特定的V-ITS-S(例如,先前讨论的V-ITS-S 101、201、1201等)的信息的请求。响应于该请求,作为VIS(例如,图2的VIS 280、由前面讨论的V2XAPI提供的VIS)的服务提供商生成包括所请求的信息的响应,并将该响应发送给服务消费者。服务消费者从VIS接收包括所请求的信息的响应。
在过程400中,服务消费者请求特定V-ITS-S的所规划的路线信息。过程400是其中服务消费者(例如,V2X应用、MEC应用等)向VIS发送请求,以接收与V-ITS-S的潜在路线相对应的预测QoS,并接收包含所要求的/所请求的信息(例如,预测QoS信息)的响应的场景。
程序400从操作401处开始,其中服务消费者(例如,VIS消费者)向VIS发送请求消息,该VIS是服务生产者(或“VIS生产者”)。在该实施例中,VIS是表示相关V-ITS-S的所规划的路线信息和/或预测QoS的资源。(请求)消息主体包含与交通工具UE的潜在路线相关的预测QoS的数据结构(下文所讨论的)。请求消息可以是具有请求行“POST../provide_predicted_qos”的HTTP POST消息。在此,资源URI是“{apiRoot}/vis/v1/provide_predicted_qos”。在一些实施例中,请求还可以包括作为输入参数的服务消费者实例ID,该服务消费者实例ID可被包括在请求消息的消息主体中。
在操作402处,服务生产者(例如,VIS)用包括包含预测QoS信息数据结构(预测QoS)的消息主体的响应/回复消息进行响应。在该实施例中,响应消息是包括HTTP消息的头部中的状态代码“200良好(200OK)”的HTTP响应消息,该状态代码“200良好”指示服务消费者的请求成功。附加地,所请求的预测QoS被包括在HTTP响应消息的主体中。在一些实现方式中,响应消息可以包括预测QoS IE、字段、数据字段、数据元素等,以包括预测QoS数据结构。
在该实施例中,POST方法被用来请求与V-ITS-S的潜在路线相对应的预测QoS。该方法支持表A中规定的URI查询参数、请求和响应数据结构以及响应代码。
表A:由预测QoS POST请求/响应支持的数据结构
Figure BDA0003546022750000171
Figure BDA0003546022750000181
预测Qos是资源数据类型。预测Qos类型表示交通工具UE的预测Qos。该信息基于每个UE的潜在路线。预测Qos的属性可以遵循表6.2.5-1x中提供的注释。表6.2.5-1x中的rsrp和rsrq属性仅被包括在响应消息中。在其他实施例中,rsrp和rsrq属性也可以包括在请求消息中,并且其中包含的RSRP和RSRQ值可以用于特定于旅程的QoS预测。如前所述,在其他实施例中,其他类型的测量可以附加地或替代地被包括在请求或响应消息中。
在一些实施例中,可以包括时间属性以指示访问由位置信息(LocationInfo)指示的特定位置的实际时间,或V-ITS-S预计访问特定位置的所预测的时间。例如,与路线起点相关的第一路线信息(routeInfo)结构可以包括V-ITS-S在路线起始点的实际时间,并且与路线目的地点相关的最后路线信息结构可以是V-ITS-S到达目的地点的所预测的或所预期的时间。与航点位置相对应的中间路线信息结构可以包括V-ITS-S访问这些航点位置的实际时间、到达航点位置的所预测的/所预期的时间,或其某种组合。
如前所述,预测Qos是资源数据类型。“资源”是具有类型、相关联的数据、与其他资源的关系以及对资源进行操作的方法集合的对象。上述表定义了可用于资源表示中的每一个资源表示的数据类型和属性。数据类型是由其可以获取的值和/或可以对其执行的操作来定义的特定种类的数据项。如上表所示,这些属性中的一些属性具有简单的数据类型(其中每个数据项一次只能存储一个值(例如,字符串、无符号整数(“Uint”)等))以及结构化数据类型(其中每个数据项是其他数据项的集合)。结构化的数据类型中的一些数据类型由相同表中列出的属性(表示为“结构化(内联)”)来定义。例如,在表9中,路线属性是结构化数据类型,该结构化数据类型包括一个或多个路线信息属性,每个路线信息属性包括位置和时间属性,以及rsrp和rsrq属性(如果被包括在响应消息中)。结构化数据类型中的一些数据类型是每个资源数据类型所共有的,诸如时间戳(TimeStamp)数据类型和位置信息(LocationInfo)数据类型。时间戳数据类型和位置信息数据类型的属性可以分别遵循表B和表C中提供的注释。
表B:时间戳的属性
Figure BDA0003546022750000191
表C:位置信息的属性
Figure BDA0003546022750000192
在表C中,“ECGI”是指用于全局地标识蜂窝小区的E-UTRAN蜂窝小区全局标识符。ECGI由移动国家代码(MCC)、移动网络代码(MNC)和E-UTRAN蜂窝小区标识符(ECI)构成。“NCGI”是指NR/5G蜂窝小区全局标识符,该NR/5G蜂窝小区全局标识符用于全局地标识蜂窝小区,尽管gNB可能包括多个NCGI。NCGI是PLMN标识符(PLMN-Id)和36位NR蜂窝小区标识(NCI)的级联。
每个超文本传输协议(HTTP)消息是请求或是响应。服务器监听针对请求的连接,解析接收到的每个消息,相对于所标识的请求目标来解释消息语义,并且用一个或多个响应消息来对该请求进行响应。客户端构造请求消息来传输特定的意图,检查接收到的响应以查看这些意图是否被实现,并且确定如何对结果进行解释。HTTP请求的目标被称为“资源”。附加地或替代地,“资源”是具有类型、相关联的数据、对其进行操作的一组方法、以及与其他资源的关系(如果可适用)的对象。每个资源通过至少一个统一资源标识符(URI)来标识,并且资源URI标识至多一个资源。使用HTTP方法(例如,POST、GET、PUT、DELETE等)通过RESTful API作用于资源。利用每一种HTTP方法,一个资源URI在请求中被传递,以对一个特定资源进行寻址。对资源的操作影响相对应的被管理的实体的状态。
考虑到资源可以是任何事物,以及由HTTP提供的统一接口与可以通过其来进行观察并仅通过向另一侧的某个独立行为方进行消息传输而作用于此类事物的窗口类似,需要抽象以在我们的通信中表示(“代替”)该事物的当前或期望状态。该抽象被称为表示。出于HTTP的目的,“表示”是旨在以可以经由协议容易地被传输的格式反映给定资源的过去、当前或期望状态的信息。表示包括一组表示元数据以及潜在地不受约束的表示数据流。附加地或替代地,资源表示是以特定的内容格式对资源状态的串行化。
起源服务器可被提供有或能够生成各自旨在反映目标资源的当前状态的多个表示。在此类情况下,可以由起源服务器使用某种算法,以便通常基于内容协商将那些表示中的一个表示选为最适用于给定请求。此种“选定的表示”用于提供用来评估有条件的请求从而构造响应消息的有效载荷(例如,200OK、对GET的304未经修改响应,等等)的数据和元数据。资源表示被包括在HTTP请求或响应消息的有效载荷主体中。请求中是否需要或不允许表示,取决于所使用的HTTP方法(例如,见IETF RFC 7231(2014年06月))。
在图4的过程400中,当请求不成功、失败或包括(多个)错误时,HTTP响应消息可能包括其他HTTP状态代码,诸如错误请求状态代码(400)(例如,当请求中传递了不正确的参数时)、未找到状态代码(404)(例如,当请求中提供的URI不能被映射到有效的资源URI时)、禁止状态代码(403)(例如,当鉴于资源的当前状态而不允许操作时),和/或其他类似的HTTP状态代码。在上述示例中,响应主体可以包括指示/包括与特定错误有关的信息的问题细节IE、字段、数据元素或其他类似数据结构。在其他实施例中可以使用其他消息格式,并且请求/响应数据可以位于此类消息的头部或主体部分中。
图4B图示出根据各个实施例的VIS API的资源统一资源指示符(URI)结构400B。表D提供了由VIS API定义的资源和可适用的HTTP方法的概览。VIS API支持在发生错误时在HTTP响应中提供的附加的应用相关错误信息(参见例如,ETSI GS MEC 009版本2.1.1(2019-01)(“[MEC009]”)的6.15款)。
表D:示例VIS API资源和方法
Figure BDA0003546022750000211
每个资源URI的语法遵循[MEC009],以及IETF RFC 3986(2005年01月)或IETF RFC7320(2014年07月)。在RESTful MEC服务API(包括VIS API)中,用于每种API的资源URI结构具有以下结构:
{apiRoot}/{apiName}/{apiVersion}/{apiSpecificSuffixes}({api根}/{api名称}/{api版本}/{api特殊后缀})。
此处,“apiRoot”包括方案(“https”)、主机和任选端口、以及任选的前缀串。“apiName”定义API的名称(例如,VIS/V2X API、RNI API等)。“apiVersion”表示API的版本,并且“apiSpecificSuffixes”定义特定API中的资源URI树。“apiRoot”、“apiName”和“apiVersion”被称为根URI。“apiRoot”在部署的控制下,而URI的剩余部分在API规范的控制下。在上面的根中,“apiRoot”和“apiName”是使用服务注册表238发现的。其包括方案(“http”或“https”)、主机和任选端口、以及任选的前缀串。对于VIS API,“apiName”可被设置为“vis”,并且“apiVersion”可被设置为合适的版本号(例如,针对版本1设置为“v1”)。MEC API支持TLS上的HTTP(也被称为HTTPS)。VIS过程中的所有资源URI(参见例如,图11)均是相对于以上根URI定义的。
还可支持JSON内容格式。JSON格式通过内容类型“application/json(应用/json)”来用信号传送。VIS API可使用带有承载令牌的OAuth 2.0客户端凭证授予类型(参见例如,[MEC009])。令牌端点可以作为[MEC011]中定义的服务可用性查询过程的部分而被发现。可使用已知的预设机制将客户端凭证预设到MEC应用中。
在一些实施例中,MEC应用228(在其相应的MEC主机240中)可使用对应的MEC V2XAPI来从3GPP网络检取信息。在一些实施例中,其相应的MEC主机240中的MEC应用228可被配置成用于主控V2X配置参数,诸如PC5配置参数(或可在多PLMN通信环境中可用的共同的V2X配置参数集)。同样在不存在网络覆盖的情况下这些V2X配置参数的可用性通过使用主机之间的Mp3接口(或另一类型的接口)来确保。在一些方面,MEC主机240中的MEC应用228可配置成用于(通过MEC主机240-2中的V2X MEC API)连接至MEC主机240-2,并且MEC主机240-2中的MEC应用228可被配置成用于(通过MEC主机240-1中的V2X MEC API)连接至MEC主机240-1。在多运营商架构的情况下,多个MEC主机240可被配置成用于经由MEC V2XAPI彼此通信并进行同步以传递相关的V2X配置参数,使得这些参数在不存在蜂窝覆盖的情况下(例如,在3GPP域外部)跨多运营商架构可以是可用的。以此方式,甚至当UE(例如,V-ITS-S 201)不处于该UE的3GPP网络的覆盖的情况下,该UE可具有对V2X配置参数的访问。
在一些实施例中,MEC主机240内的一个或多个MEC应用228可以被实例化以执行V2X应用功能的功能,这些功能可能包括提供VIS 280。附加地,MEC主机240可使用MEC V2XAPI来执行各种V2X或VIS 280功能。具体而言,一个或多个MEC应用228可在MEC主机240内被实例化以执行与V2X应用功能相关联的功能,如图3所示。这些MEC应用228可以被配置成用于执行以下V2X应用功能中的一个或多个V2X应用功能:获得V-ITS-S 201的V2X订阅信息;确定V-ITS-S 201是否被授权以响应于对V2X服务的请求而执行V2X通信;传递V2X配置参数,诸如V2X配置参数的通用集合,等等。
在各种实施例中,单个vUE 201响应于触发事件和/或在周期性的基础上向一个或多个MEC主机240提供无线电信息。在一些实施例中,取决于要发生的数据传送和/或与数据传送有关的其他信息,各个vUE 201以低周期性或高周期性来报告无线电信息。无线电信息可以采用一个或多个测量报告的形式,并且/或者可包括例如信号强度测量、信号质量测量,等等。每个测量报告标记有测量的时间戳和位置(例如,vUE 201的当前位置)。作为示例,由vUE收集的和/或被包括在测量报告中的测量可包括以下一项或多项:带宽(BW)、网络或蜂窝小区负载、等待时间、抖动、往返时间(RTT)、中断数量、数据分组的乱序递送、传送功率、位错误率、位错误比(BER)、块错误率(BLER)、分组丢失率、分组接收率(PRR)、e2e延迟、信噪比(SNR)、信噪比和干扰比(SINR)、信号加噪声加失真与信号加失真(SINAD)比率、载波与干扰加噪声比(CINR)、附加白高斯噪声(AWGN)、每比特能量与噪声功率密度比(Eb/N0)、每比特能量与干扰功率密度比(Ec/I0)、峰均功率比(PAPR)、参考信号接收功率(RSRP)、接收信号强度指标(RSSI)、参考信号接收质量(RSRQ)、用于E-UTRAN或5G/NR的UE定位的蜂窝小区帧的GNSS时序(例如,对于给定的GNSS,AP或RAN节点参考时间与GNSS特定的参考时间之间的时序)、GNSS码测量(例如,第i个GNSS卫星信号的扩频码的GNSS码相位(整数和小数部分))、GNSS载波相位测量(例如,自从锁定到该信号上以来测得的第i个GNSS卫星信号的载波相位周期数(整数和小数部分);也称为累积三角范围(ADR))、信道干扰测量、热噪声功率测量、接收干扰功率测量、和/或其他类似测量。RSRP、RSSI和/或RSRQ测量可包括对用于3GPP网络(例如,LTE或5G/NR)的蜂窝小区特定参考信号、信道状态信息参考信号(CSI-RS)和/或同步化信号(SS)或SS块的RSRP、RSSI和/或RSRQ测量,以及对用于IEEE 802.11WLAN/WiFi网络的各种信标、快速初始链路设置(FILS)发现帧、或探查响应帧的RSRP、RSSI和/或RSRQ测量。可附加地或替代地使用其他测量,诸如在以下各项中讨论的那些测量:3GPP TS36.214版本15.3.0(2018年09月27日)(“[TS36214]”)、3GPP TS 38.215版本15.4.0(2019年01月11日)(“[TS38215]”)、IEEE 802.11的部分11:“Wireless LAN Medium AccessControl(MAC)and Physical Layer(PHY)specifications,IEEE Std(无线LAN介质访问控制(MAC)和物理层(PHY)规范,IEEE标准)”(“[IEEE80211]”)等等。附加地或替代地,上述测量(或测量的组合)中的任一个可由一个或多个NAN收集并提供给MEC主机。在这些实施例中,MEC主机可以以低周期性或高周期性从NAN请求测量,或者NAN能以低周期性或高周期性将测量提供给MEC主机。附加地或替代地,MEC主机可以从其他MEC主机、核心网络功能和/或其他vUE获得其他相关数据,以用于确定QoS预测和/或生成综合信息。例如,可以经由适当的MEC API从其他MEC主机和/或经由网络暴露功能从核心网络功能收集其他关键性能指标(KPI),并用于预测沿所规划的路线的QoS和/或生成(下文讨论的)综合信息。附加地或替代地,vUE可以获得其他相关信息,并将这些信息与测量报告一起提供给MEC主机,或将这些信息与测量报告分开地提供给MEC主机。
图3示出实现VIS(例如,图2的VIS 280)与V2X控制功能350之间的通信的示例架构300。在该示例中,VIS被部署在MEC主机340-1和/或MEC主机340-2的MEC平台322中。在3GPP网络中,V2X应用可以被部署在一个或多个V2X应用服务器(V2X AS)328上。在3GPP-V2X中,存在用于V2X通信的两种操作模式,即通过PC5接口和通过LTE/5G Uu接口。Uu接口可以是单播和/或MBMS。这两种操作模式可由UE(例如图1A、图1B和图2中的V-ITS-S 101和201)用于独立地传送和接收。例如,UE可以在不使用Uu接口进行传送的情况下使用MBMS进行接收。UE也可以经由Uu接口单播DL接收V2X消息。
V2X AS 328可以通过单播接收来自一个或多个UE的UL数据,并使用单播递送和/或MBMS递送将数据递送到目标区域内的(多个)UE。V2X AS 328可以从地理位置信息映射到适当的(多个)目标MBMS SAI以用于广播,从地理位置信息映射到适当的目标3GPP身份(诸如(多个)E-UTRAN蜂窝小区全局标识符(ECGI)和/或(多个)NR蜂窝小区全局标识符(NCGI)以用于广播;以及从UE提供的ECGI/NCGI映射到适当的(多个)目标MBMS服务区域标识符((多个)SAI)以用于广播。V2X AS 328还可以将适当的(多个)ECGI/NCGI和/或(多个)MBMSSAI提供给广播多播服务中心(BM-SC),以用于广播/多播内容的调度和传送、计费、服务公告、安全和内容同步。
V2X控制功能350是核心网络中的、用于V2X所需的网络相关动作的网络功能(NF)。V2X控制功能350用于向UE(例如V-ITS-S 101和201)供应必要的参数,以便使用V2X通信,该必要的参数诸如允许UE在特定的PLMN中使用V2X的PLMN特定参数。V2X控制功能350还用于向UE供应当UE“不被E-UTRAN服务”或“不被NG-RAN服务”时所需的参数。V2X控制功能350还可用于获得V2X USD,以便UE经由V2参考点从V2X AS 328接收基于MBMS的V2X通信量。V2X控制功能350还可以经由V2参考点从V2X AS 328获得在PC5参考点上的V2X通信所需的参数。V2参考点是V2X AS 328与运营商网络中的V2X控制功能350之间的参考点。
HPLMN的V2X控制功能350通过与域名服务(DNS)功能的交互而被发现。可以在UE中预先配置、由网络提供、或者由UE自构建的(例如,从HPLMN的PLMN ID等中得出的)HPLMN中的V2X控制功能350的完全合格域名(FQDN)。HPLMN中的V2X控制功能350的IP地址也可以在UE中被供应或向UE供应。LTE核心网络中的家庭订户服务器(HSS)和/或5G核心网络(5GC)中的统一数据管理(UDM)NF提供PLMN的列表,其中UE(例如,图1A、图1B和图2的V-ITS-S 101和201)被授权执行PC5参考点上的到V2X控制功能350的V2X通信(参见例如3GPP TS 23.285版本16.0.0(2019年03月25日)和ETSI TS123 285版本14.2.0(2017年05月)(统称“[TS123285]”))。
在一些实现方式中,V2X AS 328(或V2X AS逻辑)可与RSU共同定位。在MEC中定义的VIS 280用于促进V2X在多供应商、多网络和多接入环境中的互操作性。VIS 280或其通用部分可以被部署在MEC平台330中(过滤规则控制331、DNS处置332和服务注册表338可以分别与图2的过滤规则控制231、DNS处置232和服务注册表238相对应)。因此,VIS 280可用于从V2X控制功能350获得UE的订阅数据(例如,基于PC5的V2X通信允许PLMN)。因为V2X AS328承载(或服务于)多个V2X应用,其可以作为一个或多个MEC应用228部署在MEC平台330中(参见例如,图2)。VIS 280可以通过Mp1接口与V2X AS 328通信,并且其可以通过V2X AS328从V2X控制功能350获得UE的V2X订阅数据。在一些实施例中,V2和Mp1参考点可以被增强以支持V2X控制功能350与VIS 280之间的订阅数据的安全传输。附加地,当前的3GPP规范未定义两个或更多个V2X AS 328之间的接口或用于V2X AS 328之间的消息交换的方法。在一些实施例中,Mp1参考点可被增强以支持由相同MEC主机340实现的两个或更多个V2X AS328之间的数据的安全传输,并且Mp3参考点可被增强以支持由不同MEC主机340实现的两个或更多个V2X AS 328之间的数据的安全传输。在这些实施例中,V2X API和/或VIS 280可以提供在V2X AS328之间交换此类信息的方法。
V2X MEC应用(例如,MEC应用228和/或V2X AS 328)可能需要与其在其他MEC系统中的对等应用进行通信,以实现应用用例的预期目的。所涉及的MEC系统使一个MEC系统中的经授权的应用能够与其在另一个MEC系统中的对等应用进行通信。对应用对等方的发现可以由VIS 280和/或V2X API(或VIS API)通过暴露对等连接性的可用的通信端点信息来促进。替代地,V2X MEC应用的所配置的通信量规则(例如,过滤规则控制231/331)连同底层MEC系统间的连接性布置一起可支持应用对等方的通信。附加地或替代地,V2X MEC应用可以依赖于非MEC特定的手段以进行其对等方发现,并且随后依赖于其对外部接口的经授权的访问来进行通信。所涉及的MEC系统之间的、用于实现与特定于应用的要求的安全连接性的所需布置可能是特定于应用和/或部署的,并且可能在各实施例之间有所不同。
附加地,一个MEC系统中的V2X MEC应用(例如,MEC应用228和/或V2X AS 328)可能需要消费另一个MEC系统中的服务,以便实现应用用例的预期目的。在该情形中,V2X MEC应用在其本地MEC主机240/340的服务注册表中发现所讨论的服务。用于将一个MEC系统中产生的服务映射到另一个MEC系统中的端点的所涉及的MEC系统之间的所需布置可能是特定于应用和/或部署的,并且可能在各实施例之间有所不同。
如先前所提到的,MEC主机240/340还提供RNI服务(RNIS)。RNIS是向MEC应用(例如,MEC应用228和/或V2X AS 328)和MEC平台230/330提供无线电网络相关信息的服务。RNIS对于经授权的MEC应用而言是可用的,并且通过Mp1参考点被发现。无线电网络信息的粒度可以基于诸如每个蜂窝小区、每个UE、每个QoS等级(或QoS等级标识符(QCI))的信息之类的参数来调整,或者它可以在一段时间内被请求。RNI可由MEC应用228和MEC平台230/330用于优化现有服务,并用于提供基于关于无线电状况的最新信息的新类型的服务。可以提供的RNI可以包括,例如,关于无线电网络状况的最新无线电网络信息;基于3GPP规范的与用户平面相关的测量信息;WLAN测量;与连接至与MEC主机相关联的(多个)无线电节点(例如,NAN 110、210)的UE、他们的UE情境和相关无线电接入承载有关的信息;与连接至与MEC主机相关联的(多个)无线电节点的UE、他们的UE情境和相关无线电接入承载有关的信息的改变。
在本文的各个实施例(例如,下文讨论的第一实施例和第二实施例)中,由于RNIS提供关于连接至给定NAN 110/210的V-ITS-S 101/201的信息,由多个NAN 110/210“在途中”提供的信息类型可以导致实现给定的V-ITS-S 101/201的实时通信量预测。此类信息就可以在路线规划/更新时被考虑在内。
此外,蜂窝移交不应该产生从一开始(例如,上述步骤1)就触发V-ITS-S旅行知晓的QoS预测过程的需要,因为所规划的旅程和数据传输(例如,所安装的SW封装版本等)可以(例如,通过RAN节点之间的X2或Xn接口等)沿着所规划的旅程从(主)MEC主机140/240传递或传输到(主)MEC主机140/240。此类“数据传递”是可行的,因为MEC系统的(下文讨论的)MEC编排器知道MEC主机部署的细节。MEC主机140/240和V-ITS-S 101/201之间、和/或多个MEC主机140/240之间的通信可以使用安全过程/协议(诸如,例如,OAuth 2.0授权框架,该OAuth 2.0授权框架使第三方应用能够获得对HTTP服务的有限访问(https://restfulapi.net/security-essentials/);传输层安全(TLS),传输层安全(TLS)是在计算机网络上提供通信安全的加密协议(https://blog.restcase.com/introduction-torest-api-security/);HTTPS,HTTPS确保消息在网络上的传送,并向消费者提供与服务器的身份有关的一些保证;和/或任何其他合适的通信机制。
2.传输层拥塞控制实施例
本文中讨论的实施例解决了第4层(传输)协议(诸如传输控制协议(TCP))的低效性问题。传输协议仅在终端系统上运行,并且通常需要推断沿着端点之间路径的带宽,以便适配其传输速率并避免网络拥塞。
TCP是具有内置的可靠性机制的面向连接、面向字节、双向的协议。发送应用发送不中断的字节流,并且TCP按顺序将其递送给接收应用。在TCP会话被打开之后,字节流被分割成TCP段,这些TCP段从发送方流向接收方,并从接收方被确认,接收方发送回携载其期望从发送方接收的下一字节的编号的ACK。位流的乱序部分(值得注意的是,在缺失段之后的那些部分)被保留在接收方的缓冲器中,但它们不会被发送到应用。仅当正确的序列被恢复时,接收方才会确认它们。发送方利用超时来保护这些段,并且当超时到期时重复传输。
TCP具有内置的拥塞控制机制,该机制允许发送方通过探查发现网络路径可以支持的最大带宽。拥塞控制由拥塞窗口(CW)来调节,该拥塞窗口(CW)限制发送方在任何时间都可以具有的未决的(未确认的)段的数量。通常,每当ACK被接收时,CW就会以某种步调增加。当超时到期时,CW被重置为最小值,并且整个过程重新开始。超时或重复的ACK(其仅在段丢失时发生,因为接收方在每个后续的到达时都会持续确认按次序在最后的字节)被发送方解释为拥塞信号,并且发送方会通过减少CW来相应地做出反应。存在大量的TCP拥塞控制算法(例如TCP Tahoe、TCP Reno、TCP Tahoe和Reno、TCP Vegas、TCP NewReno、TCPCubic、TCP JetMax等),这些算法根据上述事件中的一个事件之后何时确切地修改CW以及修改CW多少而彼此不同。
在MEC环境中,TCP可用于在MEC主机上运行的应用(此后的MEC应用)与在终端用户设备上运行的应用之间传输通信量。两个TCP端点之间的路径由(短的)有线子路径,以及(很频繁)通常用作瓶颈的无线电链路(例如,4G/5G无线电链路)组成。
TCP将超时和重复的ACK解释为拥塞的信号,并通常以急剧的方式相应地减少CW。在无线电环境中,超时可能是由于拥塞之外的其他原因(例如,用户的临时差劣无线电状况)。以TCP的方式应对这些原因会导致低效性(例如,不必要的吞吐量长时间下降(以秒为单位))。使用MEC服务可有助于TCP拥塞控制确定超时或重复的ACK的真实原因,改善拥塞控制的效率,并增加用户吞吐量。在下文中,运行在TCP发送方上的、做出拥塞控制决策的软件在本文中被称为传输协议运行时(TPR)。
图25-图26示出了可用于本文各个实施例的示例MEC架构。MEC是可利用3GPP第五代(5G)网络的技术,并且大多数创新服务和场景都预期利用该技术。在MEC框架中,用户装备(UE)应用可以与边缘应用(例如,MEC应用)和远程应用进行通信,远程应用传统上是远离客户端/UE侧而被实例化的。大多数网络通信量使用TCP,其性能受到若干问题的影响。本文的实施例利用MEC框架来支持基于TCP的网络的性能增强,这些性能增强可以(例如,在应用级别下)被感知并为终端用户带来真正的益处。
本文的实施例利用MEC系统/架构来支持和克服TCP网络限制,以便改善在应用级别下感知的网络性能。本文的实施例提供基于MEC的增强,以确定超时、重复的确认(ACK)和/或其他性能相关问题的原因,以改善网络效率和/或减少网络拥塞,并增加吞吐量。在实施例中,传输协议运行时(TPR)实体在TCP发送方上运行,做出拥塞控制决策。TPR充当MEC服务的客户端。TPR与MEC服务之间的互动可以遵循请求/响应模式或遵循发布/订阅(pub/sub)模式发生。请求/响应模式由特定的触发事件/条件触发,或者当应用通信量较少、稀少或不规则时触发。pub/sub模式用于周期性地更新,并且可在经历高通信量速率时使用。
Abbasloo等人的解决方案“利用网络辅助的TCP在移动边缘处实现最优性能(Toward Optimal Performance with Network Assisted TCP at Mobile Edge)”(第二届USENIX边缘计算热点话题研讨会(HotEdge 19)(2019年)(以下简称“[Abbasloo]”))提出在网络中引入被称为网络辅助(NetAssist)的新实体,该新实体周期性地收集关于瓶颈的带宽和每个UE的最小延迟的信息(图5的步骤2和步骤3),并以OoB(带外)的方式将摘要的反馈(图5中的步骤4)发送给已注册从CN获取拥塞辅组服务的服务器。该反馈将被服务器用来设置Cwnd和步调速率,并相应地发送数据。换句话说,它假定新的、不同的组件,该组件在逻辑上和物理上与将一些定义良好的信息发送到边缘服务器,因此发送到MEC应用本身的TPR分离。虽然[Abbasloo]的意图与我们的相似,并且--此外--[Abbasloo]示出通过使用无线电信息可以收获对TCP性能的显著改善,但解决方案是不同的。该工作没有预见到TPR与MEC服务之间的任何交互。
在Wang等人的“启用MEC的蜂窝网络中现代TCP变体的实验评估(ExperimentalEvaluation of Modern TCP Variants in MEC-enabled Cellular Networks)”(2018年第10届无线通信和信号处理国际会议(WCSP),杭州,第1-5页(2018年))中的解决方案评估了启用MEC的环境中的TCP变体,而没有做出任何设计提议。Jain等人的解决方案“移动吞吐量引导带内信令协议(Mobile Throughput Guidance Inband Signaling Protocol)”(草稿-弗林克-移动-吞吐量-引导-04.txt(draft-flinck-Mobile-Throughts-Guidence-04.txt),IETF(2015年2月20日))(此后为“[Jain1]”)和Jain等人的“移动吞吐量引导暴露的要求和参考架构(Requirements and reference architecture for MobileThroughput Guidance Exposure)”(草稿-斯普雷彻-移动-tg-披露-req-arch-03.txt(draft-sprecher-Mobile-tg-Exposure-req-arch-03.txt),IETF(2017年3月13日))(此后为“[Jain2]”)提出了将关于TCP发送方(通常是视频服务器)应保持的吞吐量的信息插入到来自UE的TCP确认中的移动吞吐量引导(MTG)。TCP指导提供商插入关于可用DL带宽的信息,并且TCP服务器相应地适配吞吐量。
本文的实施例与[Jain1]和[Jain2]中讨论的那些内容的不同之处在于:(a)它不需要TCP引导提供商,或拦截TCP ACK。相反,它使用经注册的MEC服务(可能是任何类型的);(b)它可以使用可以以MEC服务的形式可用的任何信息(例如,不仅是可用的下行链路带宽,并且可能是订阅信息、位置、无线电网络信息、进一步的情境信息――源自各自的MEC API等);以及(c)它可以以主动的方式查询MEC服务,而不是仅仅被动地接收信息(请参考图2中向右的红色箭头)。此外,MTG仅伴随ACK而发生。除非你获取ACK,否则你不会得到任何MTG信息。我们的解决方案允许你在任何时间具有信息。具体地,它允许你理解当接收方没有发送ACK时发生了什么。
本文的实施例也可以实现MTG,但它也可以实现MTG无法支持的不同行为和解决方案。此外,它可以与任何TPR一起使用,而不仅仅是TCP。本文的实施例在以下方面不同于[Jain1]和[Jain2]中的解决方案:对TCP以外的传输协议的适用性;利用来自MEC服务的、被认为对将事件标识为RNI以外的拥塞/非拥塞引起的事件是有用的任何信息(例如,位置、BW、用户情境信息);本文的实施例将TPR实体和MEC(服务器)应用建模为单个MEC应用或单独的MEC应用;本文的实施例可以取决于场景使用pub/sub和查询/响应机制来获得MEC服务信息;以及本文的实施例指定了到MEC应用的TPR暴露接口。
Goyal等人的“重新思考蜂窝网络的拥塞控制(Rethinking Congestion Controlfor Cellular Networks)”(第16届ACM网络热点研讨会论文集(HotNets-XVI),美国计算机协会(ACM),美国纽约NY,第29-35页(2017年11月30日))(以下简称“[Goyal]”)解决方案中介绍了加速-制动控制(Accel-Brake Control,ABC),加速-制动控制是使用一个头部位向服务器发信号通知可以增加或减少传输速率的新的传输协议。该位由传输中的路由器基于其对网络拥塞的感知来设置。服务器通过在接收到“加速”ACK时发送两个分组,并且在接收到“制动”ACK时根本不发送分组来做出反应,从而将其发送速率调整到最优平均值附近。[Goyal]中的解决方案与本实施例不同之处在于,其没有预见到TPR与MEC服务之间的任何交互,而且根本没有利用MEC框架。
最后,关于无线电网络信息(RNI)API的ETSI组规范[MEC012]说明了MEC服务消费对优化现有服务并提供基于关于无线电状况的最新信息的新类型服务的益处。视频吞吐量引导作为指示性的示例被提出,然而,没有提供具体的实现方式/操作提议。
本文的实施例在发送方处实现了情境知晓、位置知晓、无线电网络信息知晓的拥塞控制,这进而又实现了利用可经由MEC服务的消费利用上述信息的全新类别的拥塞控制算法。本文的实施例以标准化、安全和可移植的方式使用MEC服务作为代理实现了跨层交互(参见,例如Raisinghani等人的“无线协议栈中的跨层设计优化(Cross-layer designoptimizations in wireless protocol stacks)”,计算机通信,第27卷第8期,第720-724页(2004年5月)(下文为“[RAIS]”);以及Carneiro等人的“4G无线终端中的跨层设计(Cross-layer design in 4G wireless terminals)”,IEEE无线通信,第11卷第2期,第7-13页(2004年4月)(下文为“[CARN]”))。
2.1.传输协议运行时框架
MEC被设计成使得运行在MEC主机上的软件可以通过与MEC服务的定义良好的、标准化的接口来访问关于无线电链路和用户的信息,诸如无线电网络、位置和带宽管理器信息。因此,在MEC主机本身上运行的实例化MEC应用的TCP运行时支持也可以访问该信息。在各个实施例中,这些信息可以用来通过作用于其拥塞控制,以比现有解决方案更精细的且更完善的方式对TCP通信量进行节流,从而最大化用户体验,避免拥塞,并实现更高的吞吐量。
例如,在TCP拥塞控制中包括MEC服务起源信息允许:将由于拥塞事件引起的损失与由于瞬时状况(例如,临时失去视线、深度衰落事件)引起的损失区分开来;通过消费暴露先前由无线电覆盖下的其他用户提供的无线电网络、位置、带宽等信息的MEC服务来预期用户或移交的无线电状况的恶化;以及在无线电链路上添加用于拥塞缓解的主动方式。
根据各个实施例,传输协议运行时(TPR)实体在MEC主机侧处直接地或间接地经由相应的MEC应用(app)消费MEC服务是可能的。当TPR实体和MEC应用在同一MEC主机或在不同的MEC主机处被实例化时,向所请求的MEC服务暴露TPR实体应该是可行的。
本文使用的术语“传输协议运行时”或“TPR”是指传输协议(诸如循环UDP(CUDP)、数据报拥塞控制协议(DCCP)、光纤信道协议(FCP)、多路径TCP(MPTCP)、多路径UDP(MPUDP)、QUIC、可靠数据协议(RDP)、可靠UDP(RUDP)、SCTP、序列化分组交换(SPX)、结构流传输(SST)、TCP、UDP、UDP-Lite、微传输协议(μTP)等)的运行时、会话和/或执行环境。当底层传输层协议是TCP时,TPR可以被称为“TCP运行时”等。在实施例中,服务器侧的TPR(例如,在MEC服务器上运行的TPR)周期性地(例如,通过订阅RNI事件通知,特别是在与应用相关的通信量密集的情况下)或由特定事件(例如,消息超时、重复ACK等)触发地查询MEC服务以便获得对其连接的可用容量的更好理解,从而相应地适配其行为,如图6所示。
图6示出根据各个实施例的协议栈内的服务器侧TPR与MEC服务之间的交互601、标准MEC交互602和数据路径交互603。MEC服务器/主机侧TPR与MEC服务之间的交互可以遵循请求/响应模式(例如,当由特定事件触发时)或遵循发布/订阅模式(例如,用于定期更新)而发生。对交互模式的选择可能取决于由终端用户应用提出的性能要求(例如,关于服务可靠性、端到端等待时间和/或其他度量以及通信量速率(活动简档)等),因为一些终端用户应用可能要求以频繁的速率提供输出(例如,高分辨率视频段),而其他应用可能仅要求稀少的输出速率(例如,物联网/机器类型通信设备)。
TPR用于基于上述信息来调整底层传输协议的行为的算法/机制在本公开的范围之外。下面的讨论描述了MEC应用将TCP用作传输协议以用于向蜂窝网络中的移动终端/UE中的UE应用发送数据的示例。然而,本文的实施例适用于除TCP之外的任何其他传输层协议,诸如本文其他地方讨论的那些协议。
图7示出根据各个实施例的示例拥塞窗口(CW)场景(定性的)700。参考图7,假设UE享有高CQI,因此具有高吞吐量,并且TCP相应地具有大CW。无线电接入的下行链路并不是拥塞的。突然,UE进入了具有差劣接收的区域(例如隧道),在该区域中该UE将停留几秒钟。(在DL和UL两者中的)CQI下降,因此通信量(包括ACK)会停止几秒钟。一些TCP段超时。标准TCP将通过假设网络拥塞来做出反应。这具有若干种结果。首先,使用指数级增长的退避窗口(参见例如,图7中的垂直箭头)重传被丢弃的(多个)段。这意味着,当无线电状况允许通信量再次流动时,TCP发送方可能仍然等待不可忽视的延迟(以秒为单位、或以数十秒为单位,在图7中用EB标记),只是因为它在等待接下来的重传尝试之前的退避定时器到期。此外,当UE离开隧道,通信量传输恢复时,连接将处于缓慢启动状态,并且CW将增加直到其先前值的一半,并且随后切换到拥塞避免(CA)。所有的事情都被考虑到,在没有任何引人注目的网络原因(事实上没有拥塞)的情况下,在再次达到先前吞吐量水平之前,会流逝一段相当长的时间。
TCP运行时可以替代地利用消费经实例化的MEC服务来(定期)通知以下各项:来自RNIS的RNI、来自BWMS的BW信息和/或来自定位服务的UE位置信息。
RNI可以包括:例如,关于无线电网络状况的最新无线电网络信息;与基于3GPP规范的用户平面相关的测量信息(例如,RSRP、RSRQ、SINR等);与连接至同特定MEC主机相关联的一个或多个RAN节点的UE、该一个或多个RAN节点的UE情境和相关RAB有关的信息;与连接到同特定MEC主机相关联的(多个)RAN节点的UE、该(多个)RAN节点的UE情境和相关RAB的信息有关的改变;用户CQI;和/或为特定UE占用或预留的占用资源量,或由一个或多个RAN节点调度的资源。
BW信息可以包括,例如,固定的BW分配尺寸(例如,以bps为单位)、固定的BW优先级(例如,在并行地处理若干应用或会话时指示分配优先级),以及在特定时间戳或针对BW的改变(例如,增量)的固定BW分配方向(例如,DL或UL)。
定位服务(LS)支持以下位置信息:由与特定MEC主机相关联的(多个)无线电节点当前服务的特定UE的位置信息;由与MEC主机相关联的(多个)RAN节点当前服务的所有UE的位置信息;由与MEC主机相关联的(多个)RAN节点当前服务的指定UE之间的距离;指定位置与同MEC主机相关联的(多个)RAN节点当前服务的UE之间的距离;由与MEC主机相关联的(多个)RAN节点当前服务的某一类别的UE的位置信息;具体位置区域中的UE列表;移入或移出具体位置区域的特定UE;与当前同MEC主机相关联的所有RAN节点的位置有关的信息;周期性位置信息更新、关于距离改变的更新以及与具体位置区域中的UE相关的位置更新。UE位置信息(例如,位置)还可以包括UE移动性信息(例如,速度/速率),该UE移动性信息(例如,当被添加到由交通工具UE消费的地理位置/地图服务时)可被证明对于标识(多个)低信号位置和UE的(多个)预期访问时间是有用的。
由TPR实体进行的上述MEC服务消费是为了推断出问题不是由于拥塞,而是由于暂时的差劣的信道质量。这样,当移动设备离开低信号质量的区域时,协议(例如TCP)可以更快地做出反应。首先,它可以检测到UE的无线电状况再次是良好的,并且因此,由于指数退避窗口(由图7中的EB箭头标记),而免除了不必要的等待时间。此外,它可以以及时方式辅助将CW恢复到其最大值(参见,例如图7中的线701)。这允许终端用户更加迅速达到其目标吞吐量。
例如,当超时发生时,TCP运行时可以经由消耗以下MEC服务来使用信息:
·来自无线电网络信息服务(RNIS)的UE测量报告通知。这允许其理解UE的信道质量是否已下降(例如,UE的CQI相对于先前的测量是否已下降)。
·来自带宽管理服务(BWMS)的服务蜂窝小区中的分配的RB的数量。这允许其理解无线电帧的拥塞水平(或者说,相当于竞争同一资源的UE数量);和/或
·来自定位服务的UE的、要对照该区域的布局进行比较的定位信息。
根据上述信息的子集,TCP运行时可以告知:不需要激活TCP拥塞避免(例如,减少CW、以增加退避的间隔重传丢失的段,等等)。相反,明智的做法是停止传输,直到信道变得更好(这可以再次使用来自RNIS的UE测量报告来推断),并且随后以其之前所具有的相同步调恢复传输(除非无线电帧同时拥塞)。
由于MEC服务可以通过RNIS收集关于无线电(例如,协议栈的第1和第2层)的信息,因此上述实施例也可以被配置为跨层交互的标准化接口。跨层交互是指从一个协议层到另一个协议层的反馈/控制,这在一方面违反了协议封装的黄金法则,但在另一方面允许对消息的协议栈遍历进行更细粒度的控制,并可能得到更高的效率和整体更好的服务(参见例如,[RAIS]、[CARN])。跨层交互通常需要一个协议来配置和输出特定的接口,以供其他协议利用(例如,第二层(MAC)协议)输出第4层(传输)协议可能使用的信息。这些解决方案经常在学术论文中被研究,但它们难以在实践中实现,因为它们需要对协议栈的不同层进行经协调的部署。这主要是因为协议栈层经常由不同的团队在不同的时间部署。使用本文的实施例,MEC服务可以充当标准化的代理器进行跨层交互。例如,RNIS可以向TPR提供第1层/第2层信息(例如,无线电接口上的当前信道质量),从而允许TPR做出更好的决策。这不需要对第2层协议进行任何修改或对第4层和第2层协议进行经协调的部署。
2.2.实现方式方面和示例实施例
如前所述,本文的实施例包括基于MEC的客户端-服务器通信增强,实际上被实现为既作为容器又作为VM的经定制的MEC应用(参见例如下文讨论的实施例1)或多个经定制的MEC应用(参见例如下文讨论的实施例2)。在这两种情况下,IP通信量由数据平面(根据通信量规则)进行路由,并由TPR接收。UP流总是由若干分量组成:常规协议栈(实际上由RAN节点和数据平面实现)、TPR(第4层)和服务器应用(第7层)。
下文讨论的两个实施例基于TPR和实际的服务器应用的功能分割而有所不同,该TPR和实际的服务器应用被实现为单个实体或两个单独的实体。在这两种情况下,TPR与MEC服务(例如,RNIS、BWMS、LS等)之间的交互可以(例如,经由Mp1接口)遵循请求/响应模式(例如,当由特定事件触发时或者当应用通信量是稀少的或不规则时)或遵循发布/订阅模式(例如,对于定期更新,特别是对于高通信量速率)发生。
2.2.1.实施例1:在单个MEC应用中的整个堆栈
图8示出实施例1的示例800,其中MEC应用826在同一经隔离的用户-空间实例(例如,容器、分区、虚拟环境(VE)等)或虚拟机(VM)(包括类型1或类型2VM)内包括服务器应用827和TPR实体828。在该实施例中,MEC应用826包括经修改的TPR 828,该TPR 828用作(多个)MEC服务的客户端,并且能够与要被消费的MEC服务和(例如,在同一MEC应用826内的)服务器应用进行交互。TPR实体828和/或服务器应用827与MEC服务之间的交互可以通过控制平面发生。附加地,UE 801包括与本地TPR实体818交互的客户端应用817,该客户端应用817与各种其他协议栈层交互。TPR实体828和/或服务器应用827与客户端应用817和/或TPR实体818之间的交互可以通过用户平面发生。
2.2.2.实施例2:TPR作为服务生成产生MEC应用
图9示出实施例2的示例900,其中TPR实体928和服务器应用927是两个不同的实体(例如,分别为两个不同的MEC应用926-1和926-2)。在该实施例中,每个实体可以在相应的经隔离的用户空间实例(例如,容器、分区、VE等)或相应的VM(包括类型1或类型2VM)中实现或执行。在图9的示例中,MEC应用926-1表示服务器应用927,并且MEC应用926-2实现了经修改的TPR 928。MEC应用926-2经由控制平面充当MEC服务的客户端,并且能够与要被消费的(多个)MEC服务和服务器应用927(MEC应用926-1)两者进行交互。与实施例1类似,UE 901包括与本地TPR实体918交互的客户端应用917,该客户端应用917与各种其他协议栈层交互。TPR实体928和/或服务器应用927与客户端应用917和/或TPR实体918之间的交互可以通过用户平面发生。
2.2.3.TPR与(多个)MEC服务之间的通信
经实例化的TPR实体和可用的MEC服务之间的通信可以使用MEC API发生。MEC允许在网络边缘处运行MEC应用以暴露于位置和最新信息,诸如最新的RNI。关于当前无线电状况的信息经由MEC平台通过RNIS共享,并且位置信息经由位置服务(LS)共享。在该情况下,服务消费者(例如TPR实例)通过RNI API与RNIS进行通信,以获取来自无线电接入网络的情境信息。MEC应用和MEC平台两者都可以是服务消费者,并且RNI可以由MEC平台和MEC应用两者提供。服务消费者(例如,TPR实例)通过LS API与LS进行交互,以获得UE、UE组和/或当前与MEC主机相关联的无线电节点的位置信息。LS既支持地理位置(例如地理坐标)又支持逻辑位置(例如,蜂窝小区ID)。RNI API和LS API支持查询和订阅(pub/sub机制)两者,查询和订阅通过RESTful API(例如,使用HTTP协议绑定)或通过MEC平台的消息代理而被使用。
为了实现互操作性,向服务器应用的TPR暴露应该被定义。可能的MEC通信(例如,在MEC的控制平面处)将在下文中描述,并且基于用于由MEC服务获得信息的查询/响应机制,或发布/订阅机制。作为示例,由于旨在设计“主动的方法”,在一些情况下,pub/sub选项可能是方便的,特别是在一致通信量到达率的情况下。另一方面,“查询/响应”机制可以在稀少的通信量(例如,具有大规模机器类型的通信(mMTC)和低端设备)的情况下使用,以节省接收器(Rx)侧的信令资源。虽然实施例1将TPR实体和相关的服务器应用实例嵌入同一实体(例如,VM、容器等),但实施例2允许互操作性,也包括TPR实体可能在与其中服务器应用被实例化的MEC主机不同的MEC主机处被实例化的情况。图10和图11的过程1000和1100分别示出和描绘用于将该TPR服务暴露给更高层服务器应用的通信机制。尽管过程1000和1100被描述为与RNIS和LS交互,但在各个实施例中,TRP可以与其他MEC服务(诸如UE_ID服务[MEC014]、BWM服务(BWMS)[MEC015]、WLAN接入信息服务(WAIS)[MEC028]、FAI服务(FAIS)[MEC029]和/或其他类似MEC服务)交互。
2.2.4.查询/响应实施例
图10图示出用于将查询/响应模式实施例用于由服务器侧处的TPR实体(例如,图8和图9的TRP实体828和928)进行MEC服务消费的示例过程1000。此类(反应式)模式可能有利于其中用户通信量稀少和/或在例如吞吐量可持续性方面的非严格的QoS要求的情况下的场景。过程1000可如下操作:
在步骤1处,TPR检测事件的发生。该事件可以是例如发生消息超时或接收到重复的ACK。在步骤2处,TPR向与拥塞事件标识相关的资源发送GET请求消息,在该示例中该资源是请求无线电接入承载(RAB)信息的RNIS。在步骤3处,TPR接收来自相关资源的、具有包含所请求的信息(例如,RAB信息)的消息主体的响应消息(例如,具有“200良好”响应代码)。在步骤4处,TPR向与拥塞事件标识相关的资源发送GET请求消息,在该示例中,该资源用于请求UE的地理位置的LS。在步骤5处,TPR接收来自相关资源的、具有包含所请求的信息(例如,UE的地理位置)的消息主体的响应消息(例如,具有“200良好”响应代码)。在步骤6处,TPR基于所聚集的信息来将该事件分类为非拥塞相关事件。传输停止,并保存当前的CW dim.(CW减小)。
步骤7至步骤10分别重复步骤2至步骤5。在步骤11处,基于经更新的信息,TPR确定无线电状况已经被改善,并以事件的发生(例如,消息超时或ACK重复)之前相同的拥塞窗口恢复传输。
2.2.5.发布/订阅实现方式
图11图示出用于将订阅/通知(“pub/sub”)模式用于由服务器侧处的TPR实体(例如,图8和图9的TRP实体828和928)进行的MEC服务消费的示例过程1100。此类模式可能有利于这样的场景:其中通信量到达率持续较高,因此,鉴于即将发生的服务降级事件(与拥塞或非拥塞相关),提供某种程度的主动性。过程1100可如下操作:
在步骤1处,作为前提条件,TPR具有对(例如,用于UE测量报告和/或[MEC012]中讨论的其他报告的)RNIS和位置服务(LS)(例如,[MEC013]中讨论的那些位置服务)两者的活跃订阅。在步骤2处,RNIS检测与TPR相关的事件的发生。在步骤3处,RNIS向TPR在相应的RNIS订阅中包括的回调参考地址发送具有包含经更新的数据结构(例如,“事件通知(EventNotification)”)的消息主体的POST请求。在步骤4处,TPR向RNIS发送适当的响应,在该示例中,该适当的响应是具有“204无内容”状态码的响应消息。在步骤5处,基于所接收的通知,RNI改变以及UE位置事件的缺乏被TPR分类为指示可能即将发生拥塞的事件。TPR调度或规划实现合适的拥塞控制算法。
3.OPTIMEC—用于基于扩展的提前QOS通知(E-IQN)的汽车场景中的边缘计算存在点(POP)优化的框架
本文的实施例涉及利用部署在RAN(和/或各个RAN节点)旁的边缘计算(例如MEC)基础设施的V2X服务和QoS预测,RAN(和/或各个RAN节点)诸如3GPP第五代(5G)RAN、3GPPLTE E-UTRAN、WiFi无线接入点(WAP)、智能运输系统(ITS)路边装备(R-ITS-S)等等。边缘计算基础设施可以使用多接入边缘计算(MEC)来实现,多接入边缘计算(MEC)是允许应用在接入网络边缘处实例化并向终端/站/UE提供低等待时间和近接近度环境的技术。结果是,预期垂直产业(诸如汽车产业)从MEC基础设施的部署以及RAN中显著获益。
图12图示出示例性V2X系统场景1200,其中MEC主机1240与提供覆盖(例如V2X通信服务)的NAN 1210(包括NAN 1210-1和NAN 1210-2)被部署在共同位置。在该示例中,NAN1210-1可以是路边单元(RSU)或路边ITS站(R-ITS-S)、蜂窝基站(例如,eNB、ng-eNB、gNB、WiMAX基站等等)或向第一V-ITS-S 1201-1和第二V-ITS-S 1201-2提供网络覆盖(例如,V2X通信服务)的一些其他网络元件。在该示例中,NAN 1210-2可以是路边AP(RSU、R-ITS-S等等)或向第三V-ITS-S 1201-3提供网络覆盖(例如,V2X通信服务)的一些其他网络元件。
MEC主机1240(包括与NAN 1210-1共同定位的MEC主机1240-1和与NAN 1210-2共同定位的MEC主机1240-2)尤其提供VIS、RNI服务(RNIS)、位置服务(LS)、UE_ID服务、BWM服务(BWMS)、WAI服务(WAIS)、FAI服务(FAIS)和/或其他MEC服务。在图12中,第一V-ITS-S 1201-1和第二V-ITS-S 1201-2的所规划的轨迹在NAN 1210或MEC主机1240处是未知的。然而,由于V2X系统场景由高移动性和动态拓扑来表征,因此当信息由MEC主机1240集中收集(例如无线电网络、位置信息等)时,该信息的准确性和及时性受到环境情形(例如,当多个V-ITS-S 1201试图向相应的NAN 1210提供无线电测量时,发生网络拥塞事件,该相应的NAN 1210与相应的MEC主机1240共同定位)以及蜂窝网络的部署密度连同所部署的MEC基础设施的能力的阻碍。
场景1200基于ITS或V2X环境,该ITS或V2X环境并入经连接的交通工具1201、无线电网络和道路连接性基础设施1210,以及包括与无线电节点1210(例如,蜂窝基站(BS)、无线电接入点(AP)和路边单元(RSU)等)共同定位的MEC主机1240的边缘计算系统部署。
在实施例中,预测功能(PF)(包括RAN PF 1250-1和RAN PF 1250-2)被部署在网络和/或道路基础设施侧。PF 1250可以是例如由深度神经网络(DNN)实现的(多个)机器学习(ML)模型/算法和/或人工智能(AI)代理、和/或某种其他ML/AI算法,诸如本文中所讨论的那些ML/AI算法。PF 1250的作用是生成对要由例如遥控驾驶(ToD)应用、V2X应用等等经历的服务质量(QoS)的预测。
预测性QoS是一种使得网络(例如,移动网络)能够向感兴趣的消费者(例如,经连接的交通工具1201等等)提供与预测QoS改变有关的通知以便提前调整应用行为的机制。无论何时以充分的置信度作出预测,此类在前通知均可在新的预测Qos被经历之前与注意时段一起被递送。注意时段取决于特定应用和用例,并且应当长到足以给予应用充足的时间来适应于新的预测Qos。携载此类信息的消息被称为提前QoS通知(IQN)。IQN由经连接的交通工具1201接收,因此使V2X应用能够在预测Qos改变发生之前采取适当的动作。
在预测Qos低于给定的阈值(或在某个标准偏差之外)的情况下,取决于应用的性能要求,IQN被发送到IQN消费者(例如,如5GAA“使5G对汽车行业具有前瞻性和预测性(Making 5G Proactive and Predictive for the Automotive Industry)”,第2工作组白皮书(2019年12月9日)(以下简称“[5GAAWG2]”)中讨论的V2X应用)。
附加地,[MEC030]规定了VIS(参见例如,上述讨论)及其相关的V2X API的暴露,其作用尤其在于,当由VIS服务消费者(例如,ITS/V2X应用)发出与vUE 1201的潜在路线(例如,沿路线或旅程的航点和所规划的访问时间)相对应的预测(无线电)QoS的请求时,促进对该请求的转发,并向VIS服务消费者提供所请求的、特定于旅程的预测Qos。对于该任务,规定了被称为提供_预测_qos(provid_predicted_qos)的API资源(参见例如,[MEC030]第7.6条)。
预测性QoS通知的发布可能对相当长的VIS消费者列表是有用的,该VIS消费者列表范围从交通工具的消费者/驾驶员,而且通常到任何ITS/V2X应用或服务提供商(例如,移动性即服务提供商(MaaS)、车队、管理公司、交通工具原始装备制造商(OEM)、MNO和/或基础设施侧的第三方。在后一种情况下(例如,由OEM和ITS运营商VIS消费),QoS通知的使用可能例如对于减少交通工具所有者或ITS运营商(例如,车队管理公司、OEM等)发生的服务消费成本是有益的。通常情况下,ITS运营商或交通工具OEM与MNO协作以利用移动网络和运营商的云设施,以向终端消费者部署C-V2X服务。然而,此类协作和边缘云主控对汽车OEM而言是有代价的。因此,被认为是由MEC系统主控的应用的所有者的这些利益相关者希望实现对云计算设施的具有成本高效的利用,同时最大化所提供的V2X服务的质量。
另外,这些情况可以一般地扩展到MEC联合场景,其中V2X服务的实现方式需要使用多个MEC系统和/或多个MEC主机1240中的云资源。同样在这些情况下,MEC应用所有者(交通工具OEM、ITS运营商等)可能对优化与V2X服务中涉及的边缘计算(例如MEC)存在点(PoP)相关联的整体主控成本感兴趣,其中,在MEC联合场景中,这些PoP通常属于多个MEC系统/MNO。因此,对涉及跨不同的MEC系统的预测的QoS通知的检取也对于优化整体(例如,系统间)MEC PoP云资源成本也是有用的。
PoP是通信实体之间的人工分界点或接口点。附加地或替代地,PoP可以是两个或更多个网络或通信设备共享连接的物理位置。常见示例是互联网存在点,互联网存在点是允许用户通过其互联网服务提供商(ISP)连接到互联网的本地接入点。PoP可以包括被安装在机柜中的单个服务器(与边缘计算节点1240的部署相反,边缘计算节点1240是具有部署高级基础设施的PoP--通常多于单个服务器)。PoP可以容纳各种网络元件,诸如服务器、路由器、(物理和/或虚拟)网络交换机、中枢、多路复用器、防火墙设备、网关设备和/或用于跨网络通信量的其他网络接口设备。PoP通常位于数据中心和/或互联网交换点(IXP)和共同定位中心。ISP和边缘网络可能具有位于其具有对等协议的大型IXP处或附近的多个PoP。PoP和IXP的接近度是通信量能够多快穿过互联网的因素。
目前,预测性QoS通知仅提供关于与RAN和核心网络(CN)相关的特定于蜂窝通信的性能度量的信息(参见例如,表E)。因此,预测性QoS通知消息中不包括关于边缘和/或云计算资源的预期可用性的信息。
表E:对预测Qos和QoS KPI的用例分析[5GAAWG2]
Figure BDA0003546022750000421
鉴于预测性QoS服务的该差距,本公开提供了相关的应用、用例和场景,对于这些应用、用例和场景,该差距是突出的。
图13描绘了根据各个实施例的高清(HD)地图数据收集、合并和分发的示例场景1300。在图13中,类似标号的元素与本公开中其他地方讨论的元素相同。
图13的第一用例示例涉及使用高清(HD)地图的实时情形知晓。在该示例用例中,参与者节点(行为者)及其角色包括在交通工具1201中运行的客户端应用、在NAN 1210(例如,智能RSU)中运行的客户端应用以及在边缘节点1240中运行的主机应用。处理传感(传感器)数据(例如相机、雷达、光检测和测距传感器(LiDAR)等)以收集其环境感知并实现实时情形知晓的交通工具中的客户端应用将相关知晓和情形知晓数据上传到主机应用侧(其是运行在分布式边缘节点中的应用);并下载分布式边缘节点中合并的高清地图数据。
在各个实施例中,NAN 1210(例如,智能RSU)位于道路段和交叉路口中或附近。NAN1210(例如,智能RSU和/或在NAN 1210中运行的客户端应用)配备有边缘计算和传感器(例如,相机、雷达、光检测与测距传感器等),以便也收集其自身的环境感知。运行在NAN 1210中的客户端应用(例如,智能RSU)从它们所位于的交叉路口或道路段中或附近的多个道路参与者传送的V2X消息中收集信息。在边缘节点1240中运行的主机应用从多个交通工具1201、NAN 1210和其他道路参与者(例如,易受伤害的道路使用者(VRU)、IoT设备等等)接收感知和情形知晓数据。在边缘节点1240中运行的主机应用对数据进行处理和合并,准备高清地图的层,并与其他(例如,邻近的)边缘计算节点1240交换数据。在边缘节点1240中运行的主机应用经由(多个)推送或拉取过程将高清地图层传播/分发到相关地理区域中的交通工具1201、NAN1210和/或其他道路参与者。
例如,多个交通工具1201以及NAN 1210收集与交叉路口中的潜在危险1305有关的信息(例如,破碎的或停车的交通工具、道路损坏、掉落的对象等),在该示例中,V-ITS-S1201-1收集表示其(多个)传感器视场(FoV)1301中的对象1305的感知数据。由于交叉路口中的和附近的交通拥塞的形成,许多交通工具1201将同时提供感知和情形数据,并且也将下载对实时高清地图的更新。最终,附近区域中和交叉路口中的网络和无线电QoS状况可能会降级。附加地,边缘节点1240可能会因计算任务/工作负荷而过载。在这些情况下,可能需要边缘计算(例如,MEC)PoP优化(例如,将MEC应用的虚拟机(VM)和/或容器重新定位/迁移到系统中的其他MEC服务器1240,或者仅在同一MEC服务器1240中执行对MEC应用的VM扩展)。
在该种类型的应用中,交通工具应用和MEC应用两者都可以周期性地请求经扩展的无线电、边缘、云IQN(e-IQN),以便利用实时数据维持HD地图的持续/周期性更新。最终,交通工具1201可能会采取动作,或者MEC应用可能提供关于如何继续进行的推荐。作为简单的选择,可以由交通工具1201对旅程进行重新规划路线,以避免有问题的交叉路口,这可能释放(开放)该地区附近区域中的无线电和网络资源,并且还开放(例如,边缘计算节点1240处的)对应的计算资源。因此,e-IQN信息可能对优化MEC PoP是有用的。
图13的第二用例示例涉及与对自动驾驶的实时远程支持组合的分布式动态道路通信量管理(TM)。在该用例中,参与节点(行为者)及其角色包括在交通工具1201中运行的客户端应用和在边缘计算节点1240中运行的主机应用。
在交通工具1201中运行的客户端应用将自动驾驶功能与数据交换模块组合,以与动态分布式道路通信量管理实体交互,以及处理从远程驾驶支持实时接收到的指令。在交通工具1201中运行的客户端应用还向边缘节点中的主机应用上传相关的感知和情形知晓数据,并从在边缘计算节点1240中运行的主机应用接收操纵指令和/或实时路线信息。
在边缘节点1240中运行的主机应用从其相应覆盖区域(或相应服务区域)中的多个交通工具1201接收感知和情形知晓数据,执行本地动态通信量管理,并为自主驾驶功能的远程支持做好准备。在边缘计算节点1240中运行的主机应用将(例如,提供由NAN 1210进行传输和/或广播)实时路线和操纵指令分发给有关区域中的交通工具。
在该示例用例中,分布式边缘计算节点1240接管实时监测和控制道路交通的经组合的任务,以及通过提供特定路线以及要执行的操纵动作来支持交通工具1201的自动驾驶。分布式边缘计算节点1240是互连的,并且也连接至集中式区域道路通信量管理实体。在一些情况下,如果许多交通工具1201汇聚到某个地理区域,或者因为发生了一些特定的道路交通事件(例如,在道路上出现对象1305),则在无线电和网络QoS以及计算资源方面可能出现一些瓶颈。而且在这些情况下,可能需要或期望MEC PoP优化(例如,以将MEC应用的VM、容器等重新定位/迁移到系统中的其他MEC服务器1240,或仅在同一MEC服务器1240中执行MEC应用的VM或容器扩展)。
剑桥咨询公司的英特尔链接性能预测器:通过预测性网络和服务特征递送更好的服务性能和经改善的网络效率(Intel Link Performance Predictor:delivering betterservice performance and improved network efficiency with predictive networkand service characterization)(2019年)(以下简称“[CCLPP]”)中讨论了网络性能预测对除了应用消费者以外的利益相关者的有用性,其指出,如果服务能够随着时间的推移具有对所预测的网络性能的访问,则应用开发人员和网络运营商都可以递送更好的服务并且更高效地使用可用的网络资源。打破服务与支持它们的网络之间的传统障碍,将允许服务性能以先前不可能的方式被改善。这将为更高效的网络利用铺平道路。[CCLPP]还指出,服务的质量传统上与网络性能度量相关联。就像道路上的速度限制一样,静态的网络性能度量仅提供部分的、往往是不正确的、且顶多是指示性的对所经历的质量的观察。按照谷歌通信量类比,通过获取对当前的和所预测的网络性能的访问,驾驶员(或他们的卫星导航路线规划器)可以调整他们的路线以优化他们的体验。同样地,如果许多服务具有关于预期网络性能的任何显著改变的提前警告,则这些服务可以调整他们的操作模式。然而,到目前为止,仅网络性能被考虑用于预测。
附加地,在图14中,IQN对于C-V2X应用的作用和利用被直观地阐明了(参见例如,[5GAAWG2])。另外,图14B示出了通用的提前QoS通知的整体结构(参见例如,5GAA TR191007_2,“5G汽车协会;工作组系统架构和解决方案开发;C-V2X版本2.0中的用于提供QoS可预测性的架构增强”(下文为“[5GAATR]”))。在[5GAATR]的第4节中,图14B中的消息结构的预测关键性能指标(KPI)属性(数据元素/字段/IE)包括KPI,其可以是等待时间、可靠性、分组递送率、吞吐量、用户平面(UP)连接、网络利用、延迟变化(抖动)、(通信服务的)可用性和/或准确性。上述度量中没有一个度量集中于边缘云处理、存储器和/或存储资源的可用性。
附加地,与上文提及的5GAA参考类似,[MEC030]已指定一种被称为预测Qos(PredictedQos)的资源数据类型。在表6.2.5-1中重现的此种数据结构在VIS服务消费者对旅程特定的QoS预测的请求之后被发送至该VIS服务消费者。基于表6.2.5-1,仅特定于无线电信号质量的属性和其值被包括在响应消息中。
表6.2.5-1:预测Qos的属性
Figure BDA0003546022750000451
在上文讨论的当前解决方案中,仅V2X应用(例如,MEC应用和客户端应用)接收此类通知,目的是在信号质量降级之前采取适当的动作/对抗措施。预测性QoS信息未被MEC服务提供方访问,并且由此其无法用于按性能(或成本)标准的MEC PoP优化。而且,如[5GAATR]所述,IQN的有效载荷消息仅包括与同无线电信号质量紧密相关的性能度量有关的属性,由此仅反映无线电接入系统的RAN和CN部分。对MEC处理、存储和存储器资源的预期可用性的预测既不被执行也不被包括到最先进IQN消息中。
鉴于这些潜在的问题和其他潜在的问题,ITS/V2X应用和/或服务提供商如何可利用QoS预测来优化边缘PoP,并何时何地需要主动供应计算、存储器和/或存储资源?由(运行在诸如MEC平台之类的边缘计算节点1240上的)应用或服务提供商对无线电QoS预测的高效利用不是一项琐碎的任务,因为预测是从由不同实体或利益相关者(例如MNO、边缘计算服务提供商等)设计、管理和维护的PF1250获得的,这意味着预测性QoS通知可能并不总是以可互操作的方式获得。
本文所讨论的各个实施例通过还包括对边缘云计算资源的预测来增强预测Qos通知的定义,目前仅集中于与NAN 1210和CN相关的特定于移动通信性能度量。该跨域信息集合在本文中被称为扩展的提前QoS通知(e-IQN)。e-IGN可被多个行为者(诸如交通工具OEM、车队运营商、MaaS和边缘计算(例如MEC)服务提供商)利用。
本文的实施例提供了信令框架,该框架允许边缘计算(例如,MEC)应用和服务提供商能以可互操作的方式访问e-IQN。这些实施例可以利用V2XAPI来提供互操作性。术语“互操作性”是指利用一种接入技术(或RAT)的计算系统与利用另一种接入技术(或RAT)的计算系统进行通信的能力。本文中的实施例还包括用于将e-IQN用作输入并且涉及跨一个或多个地理区域的边缘计算编排(例如MEC编排器(MEO))的边缘(例如MEC)PoP优化的过程/方案。
本文的实施例可以在各个标准(诸如5G汽车协会(5GAA)标准、ETSI标准、3GPP标准、GSMA标准等等)中采用。本文的实施例也可以使用各种通信手段(包括例如并入e-IQN数据类型的基于API的信令)来实现。
本文中的实施例提供了对包括数据中心、移动网络(包括5G)和路边装备(RSE)的计算系统和网络的各种改善,并且更具体提供对用于提供V2X、ITS和智慧城市服务的技术的改善。此外,MaaS和MEC服务提供商、交通工具OEM和车队管理公司可能会从对联合无线电/信令QoS和处理、存储器、存储资源可用性预测的暴露中受益。这是因为与不考虑QoS和边缘计算资源波动而在空间和时间上统一进行的部署相比,在高服务需求、高无线电信号质量和边缘计算资源(例如数据处理、存储器、存储等)可用性的区域主动地且集中地部署边缘应用和服务,将得到更低的所产生的成本和改善的资源利用效率。
3.1.示例E-IQN配置和布置
图15描绘了用于实施本文中的实施例的示例性场景1500。场景1500涉及在V-ITS-S 1501处实例化的客户端汽车/移动性应用1518请求无线电信号质量和边缘主机资源可用性预测以(例如,在沿着经规划的旅程进行任务迁移时)达成决策。场景1500可以具有与图12的场景1200和/或图13的场景1300相同或类似的设置/布置,并且包括以下系统实体:
客户端应用1518在V-ITS-S 1501中的计算单元处被实例化。V-ITS-S 1501包含相关联的通信硬件/电路,如本文所讨论(参见例如,图27-图31)。在另一实施例中,任何道路使用者(诸如,摩托车或者诸如骑行者、行人等之类的易受伤害道路使用者(VRU))装配有主控客户端应用1518的对应的嵌入式单元或手持式/可穿戴设备。驻留在NAN 1510上的在V-ITS-S1501上运行的客户端应用1518向MEC主机1540报告其所规划的旅程信息(例如,地图坐标、路线/导航数据、GNSS/GPS数据等)。对应的经实例化的MEC应用1526在MEC平台1532(例如,作为与NAN 1510共同定位的MEC主机1540的一部分)附近的数据网络处或MEC平台1532(例如,作为与NAN 1510共同定位的MEC主机1540的一部分)处的计算资源(例如,虚拟化基础设施)中运行。MEC应用1526和客户端应用1518通过接口1519交换数据。在实施例中,NAN1510可包括WLAN、WWAN、蜂窝和/或其他RAT电路,以提供充当蜂窝基站(例如,eNB、ng-eNB、gNB等)、RSU/路边装备(RSE)等的局域AP和/或广域AP。
V-ITS-S 1501可以与先前讨论的V-ITS-S 101、201、301和1201相同或类似,并且客户应用1518可以与图2和图25的UE应用202或应用2518分别相同或类似)。NAN 1510可以与先前讨论的NAN 110、210和1210相同或类似。MEC主机1540可以与本文讨论的MEC主机140、240、340、1240和2502相同或类似,MEC平台1532可以与MEC平台2532相同或类似,并且MEC应用1526可以与本文讨论的MEC应用2526相同或类似。
V2X信息服务(VIS)1580经由V2X API在生产和消费实体之间暴露。VIS 1580可以与先前讨论的MEC VIS 280相同或类似。在实施例中,VIS1580经由V2X API(其可称为V2XAPI 1582)消费E-IQN请求并提供E-IQN响应1582。
RAN预测功能(PF)1550是负责预测特定vUE位置和感兴趣时间的无线电信号质量的功能块。RAN PF 1550可以与先前讨论的RAN PF 1250相同或类似。预测无线电信号质量可以基于各种机器学习(ML)/AI模型来确定/预测。在实施例中,RAN PF 1550经由与VIS1580的接口(其可以被称为接口1551)消费/提供信号质量预测请求/响应1551。
云PF 1554是负责预测在特定边缘云部署位置处和感兴趣的时间的边缘资源可用性的功能块。预测边缘资源可用性可以基于各种ML/AI模型来确定/预测。在实施例中,假设云PF 1554可由多个MEC编排器(MEO)(参见例如,图25的MEO 2510)通过适当/合适的接口到达。在实施例中,云PF1554经由与VIS 1580的接口(其可被称为接口1555)消费/提供边缘资源可用性预测请求/响应1555。附加地,RAN PF 1550和云PF 1554可以通过ranPF-云PF接口1553彼此协调。此种协调可以周期性地或响应于适当的触发事件而发生,和/或可以“离线”发生。
在一些实施例中,RAN PF 1550和/或云PF 1554的ML/AI模型是神经网络或预测在给定时间和/或位置的信号/无线电质量(RAN PF 1550)或在MEC覆盖下给定用户负载的处理资源可用性(云PF 1554)的另一种ML/AI结构。
在示例实施例中,MEC主机1540、MEC平台1532、RAN PF 1550和云PF 1552由边缘计算/网络提供商提供,V-ITS-S 1501、客户端应用1518、MEC应用1526由交通工具/汽车OEM提供,并且NAN 1510由MNO提供。在另一个示例实施例中,NAN 1510、MEC主机1540、MEC平台1532、RAN PF 1550和云PF 1552由同一MNO/边缘服务提供商提供。
在各个实施例中,QoS预测通知的定义被增强。当前,IGN仅基于(例如,RAN和CN相关的)通信网络信息。在示例实施例中,IQN被增强/扩展为包括与边缘计算节点和/或边缘云计算资源预测有关的信息。该信息集合在本文中被称为增强的提前QoS通知(e-IQN)信息等等。当前ETSI MEC V2X API[MEC030]和[5GAAWG2]标准可以被扩展/更新,以便以该方式来增强/扩展IQN。
在一些实施例中,预测Qos数据类型被更新为当前ETSI MEC V2XAPI[MEC030]的扩展,为了满足V2X网络中不同的各方/利益相关者对整体的、多域预测的需求,[MEC030]中表6.2.5-1的预测Qos数据类型如表6.2.5-1x所示被增强。
表6.2.5-1x:预测Qos的属性
Figure BDA0003546022750000491
预测Qos数据类型表示交通工具UE的预测Qos。该信息基于每个UE的潜在路线。预测Qos的属性遵循表6.2.5-1x中提供的注释。表6.2.5-1x示出ETSI MEC V2X API的预测Qos数据类型的附加属性,以形成e-IQN消息。
在一些实施例中,[5GAAWG2]中讨论的整体IQN消息结构被更新。在这些实施例中,由图14B中出现的IQN消息结构的“预测KPI”字段/属性指示的可能性能度量列表被增强/扩展以包括以下附加度量:以例如每秒十亿次浮点运算(GFLOPS)为单位进行测量的处理资源(例如处理能力);以例如千兆字节(GB)为单位进行测量的存储器资源;以例如兆兆字节(TB)为单位进行测量的存储资源。每秒十亿浮点运算是用于测量计算机的浮点单元(FPU)的性能的测量单位。一每秒十亿次浮点运算(gigaflops)是每秒10亿次浮点运算(FLOP)。
附加地,实施例包括用于确保e-IQN可由边缘计算提供方(例如,MEC服务提供商)以可互操作方式访问的信令框架。在这些实施例中,可利用和/或增强V2X API。基于上述内容,并假设有两个不同的e-IQN消费者,此类信令框架的示例由图16示出和描述。
图16示出根据各个实施例的关于图15讨论的各种实体之间的逻辑交互。图16包括不同的e-IQN消费者(例如,与在vUE 1501处实例化的V2X应用相对应的MEC应用1526)与e-IQN生产者(例如,由汽车OEM/服务提供商拥有/管理的MEC应用1526)之间的e-IQN通信。在该示例中,第一e-IQN消费者(e-IQN消费者1)是与在vUE 1501处运行的客户端应用1518相关联的MEC应用1526,其是e-IQN信息的主要受益方;并且第二e-IQN消费者(“e-IQN消费者2”)是由服务提供商(例如交通工具OEM、车队经理、企业等)拥有/管理的另一MEC应用1526。
该过程在步骤1601处开始,其中对特定于旅程的预测QoS的请求由客户端应用1518发送至e-IQN消费者1(MEC应用1526),并且在步骤1602a处,由e-IQN消费者1向VIS1580发送e-IQN请求。该e-IQN请求包括(经更新的)路线航点(位置)及其所预期的/所预测的访问时间。附加地或替代地,在步骤1602b处,e-IQN消费者2可以发送e-IQN请求。该e-IQN请求包括边缘服务部署数据、边缘节点部署的地理位置数据以及感兴趣的时间。e-IQN消费者1和2两者都是通过MEC V2X API消费MEC VIS 1580的MEC应用1526。在1602a处的具有所有输入属性/参数的e-IQN请求由e-IQN消费者1通过利用V2X API转发到VIS 1580。
在步骤1603a处,VIS 1580通过其他V2X应用向RAN PF 1550提供(例如,来自e-IQN消费者1和/或2的)(多个)e-IQN请求以及路线信息。在步骤1604a处,VIS 1580从RAN PF1550获得无线电e-IQN属性。无线电e-IQN属性指示沿着所预测的/所估计的路线的预测无线电信号质量。
在步骤1603b处,VIS 1580向云PF 1554提供(例如,来自eIQN消费者1和/或2的)(多个)e-IQN请求。在步骤1604b处,VIS 1580从云PF 1554获得与边缘节点和/或(多个)云服务处的计算、存储和/或网络资源相关的边缘/云e-IQN属性。
[MEC030]中的表7.2.1仅预见了用于预测QoS检取的POST方法。然而,在实施例中,这可以被更新为GET方法,以便正确地反映预测QoS信息是从VIS 1580中检取出,而不是被推送到VIS 1580中的事实。附加地,可以使用与将该信息插入到VIS 1580资源树中相关的双重消息(POST)。
VIS 1580与预测功能(RAN PF 1550和云PF 1554)之间的通信一般可以利用任何类型的协议来实现。该协议(或协议的组合)可能会或可能不会被例如ETSI MEC标准化。在一个实施例中,可以使用VIS 1580中针对VIS-PF链路的现有HTTP查询的重新使用。附加地或替代地,通信可以通过Mp1来发生。附加地或替代地,可以实现PF(RAN PF 1550和云PF1554)以及MEC应用1526,ETSI MEC中指定的POST消息是有效的,并且可以根据需要简单地引入附加的GET消息。
两个PF(RAN PF 1550和云PF 1554)中的每一者也可以并行地接收其他输入。例如,RAN PF 1550可以从其他V2X应用(例如,通过1603a)并发地收集路线信息,这可以允许推断出在给定时间窗口的给定区域上的预期按UE分配的无线电资源。在另一个示例中,云PF 1554可以同时获得其他MEC编排器(MEO)和/或5G系统(5GS)输入,诸如MEC主机容量、回程连接状态、网络功能数据和/或其他类似信息/数据。
在由RAN PF 1550和云PF 1554得出预测之后,RAN PF 1550和云PF 1554中的每一者经由V2X API在操作1604a和1604b处向e-IQN消费者提供e-IQN消息的对应属性。例如,在操作1604a处,RAN PF 1550响应于1602a处的请求,向eIQN消费者1(例如,与在V-ITS-S的1501处执行的V2X应用1518相对应的MEC应用1526)提供关于沿V-ITS-S的1501旅程/路线的无线电信号和网络质量的e-IQN属性。附加地或替代地,在操作1604b处,云PF1554响应于在1602b处的来自e-IQN消费者2的请求,提供关于服务部署区域上的可用边缘和/或云计算资源的e-IQN属性。附加地或替代地,在操作1604a处,云PF 1554可以响应于eIQN消费者1的请求(例如,如果在1601和1602a处请求),提供关于沿V-ITS-S的1501旅程/路线的可用边缘和/或云计算资源的e-IQN属性。
一旦两个域的e-IQN预测属性被VIS 1580收集,VIS 1580就将e-IQN预测属性进行级联以形成要在操作1605a和1605b处经由V2X API发送给请求方e-IQN消费者1或2的单个复合e-IQN响应消息。在此,在步骤1605a处,与无线电特性相关的e-IQN预测属性被提供给eIQN消费者1,并且在步骤1605b处,与边缘/云特性相关的e-IQN预测属性被提供给e-IQN消费者2。此外,在1606处,RAN PF 1550与云PF 1554之间的协调独立于该过程的其他操作/步骤发生。
在一些实施例中,两个通信阶段(例如,从各个PF对预测的检取、以及e-IQN属性的级联/组合)可以是异步的并且在分开的时刻进行。在一些实施例中,来自不同PF的单个e-IQN预测属性可以在其被接收到时被缓冲,并根据需要级联或以其他方式组合(例如,由于预测是以不同的周期性和不同的相位偏移生成)。由此,图16中的消息应当不必被看作具有严格结果性。
图17描绘了根据各个实施例的用于旅程知晓的e-IQN请求和响应的示例过程1700。过程1700包括由e-IQN消费者1和来自图16的示例中的e-IQN受益方的参与,其中e-IQN受益方(例如,客户端应用1518)和/或e-IQN消费者(例如,MEC应用1526)请求针对给定路线和给定旅程时间在边缘处进行应用迁移的可行性。过程1700可如下操作:
在步骤1,e-IQN受益方请求针对特定旅程时间下给定路线在网络边缘处进行应用迁移的可行性(REQ off.)。在步骤2处,e-IQN消费者1经由V2X API发送针对所规划的路线的e-IQN请求(REQ)
在步骤3a处,VIS 1580将沿路线(例如,沿旅程的各个航点处)的无线电信号质量/状况的REQ转发给RAN PF 1550。在步骤4a处,RAN PF 1550实现计及各种V-ITS-S 1501的所有所规划的路线的一个或多个预测算法。在步骤5a处,RAN PF 1550向VIS 1580提供包括预测无线电信号质量/状况的无线电e-IQN响应(RESP)。
在步骤3b处,VIS 1580将沿路线(例如,在沿旅程的各个航点处)的边缘和/或云计算能力和资源(REQ边缘/云e-IQN)的REQ转发到云PF 1554。在步骤4b处,云PF 1554实现计及所有V-ITS-S、MEO和5GS输入的一个或多个预测算法。在步骤5b处,云PF 1554向VIS 1580提供包括预测边缘/云能力和资源预测的边缘/云e-IQN RESP。步骤3b、步骤4b和步骤5b可以在步骤3a、步骤4a和步骤5a之后发生,或与步骤3a、步骤4a和步骤5a同时发生。
在步骤6处,VIS 1580将来自RAN PF 1550和云PF 1554的e-IQN属性级联成单个响应消息。在步骤7处,VIS 1580经由V2X API将具有所有属性/参数的e-IQN RESP发生给e-IQN消费者。在步骤8处,e-IQN消费者将e-IQN预测转发给e-IQN受益方。在步骤9处,e-IQN受益方(例如,客户端应用1518)基于所传递的跨域预测来做出迁移决策。
在一些实施例中,触发器是交通工具1501中的客户端应用1518,该客户端应用1518是请求用来在边缘计算节点处对应用迁移做出决策的信息的V2X应用(参见例如,3GPPTS 23.885)。如所示出,在通信周期结束时,所提供的e-IQN消息不仅包括通信网络的所预测的性能,还包括MEC PoP(例如,边缘服务器)的资源可用性。基于该复合信息,V2X应用可以基于所获取的预测(例如,e-IQN信息)来主动地做出任务迁移决策。图17的过程仅是示例,因为在一些其他情况下,e-IQN请求可以由MEC应用1526直接触发,而不需要来自交通工具1501或客户端(V2X)应用1518的显式请求。
图18描绘了根据各个实施例的旅程知晓的e-IQN请求和响应的示例过程1800,其中e-IQN消费者(例如,在被运行在交通工具UE处的对应客户端应用触发之后的MEC应用)请求针对给定路线和给定旅程时间在边缘处进行应用迁移的可行性。过程1800可如下操作:
作为过程1800的前提条件,e-IQN响应消息的所有属性已经由VIS1580获得并被转发给e-IQN消费者(例如,请求的MEC应用1526)。过程1800开始于步骤1,其中MEC平台1532经由Mm5参考点向MEPM 1806(例如,其可以与图25的MEPM 2506相同或类似)提供沿路线的(源自VIS的)可用边缘资源的e-IQN属性。在步骤2处,MPEM 1806经由Mm3参考点发送关于要被提供给MEC编排器(MEO)1810(例如,其可能与图25的MEO 2510相同或类似)的沿路线的(源自VIS的)可用边缘资源的e-IQN属性。在步骤3处,MEO 1810确定边缘/云资源。在一个示例中,MEO 1810将路线航点与经部署的MEC主机进行匹配,标识MEC主机处的资源瓶颈,并建议要对特定的MEC主机和时间实现的VM迁移策略。在步骤4处,MEO 1810经由Mm4参考点将关于边缘/云资源的策略(例如,包括VM迁移策略)转发给MEC系统的VIM 1808(例如,其可以与图25的VIM 2508相同或类似)。在步骤5处,如果存在足够的资源,则VIM1808实现该策略;否则,将其标记为不可行并相应地通知MEO 1810。在步骤6处,与在某个MEC主机上实例化的e-IQN消费者(例如MEC应用1526)最初相关联的客户端应用1518将决定把MEC应用实例迁移到MEC系统的不同的MEC主机上,该不同的MEC主机已被MEO 1810标识。
3.2.边缘计算POP优化实施例
如前所述,实施例还包括将e-IQN信息作为输入的边缘存在点(PoP)优化方案,该方案涉及跨(多个)地理区域的边缘编排器(例如,MEO)。在这些实施例中,所获得的e-IQN信息被用来主动地优化MEC系统和被实例化/被附接到的e-IQN消费者(即例如由交通工具UE处的客户端应用触发的MEC应用)两者的PoP,以及参与所规划的交通工具路线的相邻/紧邻地部署的联合MEC系统的PoP。
3.2.1.MEC系统内的MEC Pop优化
在这些实施例中,e-IQN能够由提供VIS的MEC平台经由MEC平台管理器(MEPM)(参见例如,图25的MEPM 2506)转发给系统的MEO。然后,系统的MEO为了确保在所关注的时间窗口满足服务QoS,沿着交通工具的所规划的路线标识MEC系统的MEC主机处的资源瓶颈,并建议在特定的MEC主机和时间实现VM迁移策略。该策略被转发到MEC系统的经虚拟化的基础设施管理器(VIM)(参见例如,图25的MEPM 2508),并且如果可行,就在关注的时间之前实现,否则其就被标记为不可行,并相应地通知MEO。遵循这些步骤,与在某个MEC主机处实例化的MEC应用最初相关联的客户端应用,将决定MEC应用即时迁移到已由MEO标识的不同MEC主机。请注意,“MEC PoP如何由MEO/VIM完成优化”不是本发明的焦点。相反,我们介绍了实现该优化所需的框架、信息交换和消息图表。图18和图19分别针对VIS被实现为MEC平台服务或被实现为产生服务的MEC应用的情况解释了该优化框架。
图19描绘了根据各个实施例的MEC PoP优化方案的示例过程1900。在该示例中,MEC PoP优化通过经实例化的MEC应用在MEC系统内请求旅程特定的无线电和边缘云资源预测而触发。在该实施例中,VIS被实现为MEC平台服务。过程1900可以具有与先前关于过程1800讨论的前提条件相同的前提条件。作为过程1800的前提条件,e-IQN响应消息的所有属性已经由VIS 1580获得并被转发给e-IQN消费者(例如,请求方MEC应用1526)。过程1900从步骤1处开始,其中生产VIS 1580的MEC应用1526经由Mp1参考点向MEC平台1532提供关于沿路线的可用边缘资源的e-IQN属性。过程1900中的步骤3至步骤7可以分别与过程1800的步骤2至步骤6相同。
3.2.2.跨MEC联合的MEC POP优化
图20描绘了根据各个实施例的MEC PoP优化的示例逻辑架构2000。逻辑架构2000包括两个MEC系统(MEC系统1和MEC系统2),其中该两个MEC系统中的每个MEC系统包括经由Mm1参考点与MEO 2010通信地耦合的OSS 2021,以及经由Mm3参考点与MEO 2010通信地耦合的MEPM 2006。逻辑架构2000还包括业务和服务层2001,业务和服务层2001包括每个MEC系统的OSS 2021和每个MEC系统的联合管理器2025(例如,联合管理器2025-1和联合管理器2025-2)。每个联合管理器2025经由Mfm-fed参考点与相应的MEO 2010通信耦合,该Mfm-fed参考点是未被当前ETSI标准定义的新参考点。(多个)MEC系统发现包括安全(例如,认证、授权、系统拓扑隐藏和加密)、收费、身份管理和监测方面。在该示例中,MEC PoP优化通过经实例化的MEC应用在MEC系统内请求旅程特定的无线电和边缘云资源预测而触发。在该实施例中,VIS被实现为(产生服务的)MEC应用。
根据[MEC030]第5.4.1节,“VIS服务可以由MEC平台或由MEC应用产生”。关注MECPoP优化,在这两种情况下,初始触发器总是VIS,因为在级联无线电/边缘预测属性之后,它是整个e-IQN消息的所有者。因此,作为第一步,VIS在两个子情况下向MEPM提供e-IQN边缘资源:(i)VIS通过Mm5参考点被实现为MEC平台服务(图19);(ii)VIS通过Mp1和Mm5参考点被实现为产生服务的MEC应用(图20)。
图20描绘了将MEC系统的MEO 2010与联合管理器2025连接的联合管理参考点Mfm-fed。用于MEC系统间迁移的MEC联合涉及两个或更多个“经联合的”MEC系统的存在,其中例如,作为e-IQN消息的主要受益方的客户端应用可能想通过利用联合中的其他MEC系统的存在来评估PoP优化,并评估将(例如,用于应用迁移的)MEC应用实例重新定位到同一MEC联合中的不同MEC系统的另一MEC主机的机会。在该情况下,假设两个(或更多个)MEC系统之间的初始MEC系统间发现在MEO 2010水平上经由专用的Mfm-fed参考点是可行的,该专用的Mfm-fed参考点将MEO 2010与位于运营商平台2001的联合管理器2025相连接(参见例如,GSMA白皮书《运营商平台概念--第1阶段:边缘云计算》(2020年1月),可在https://www.gsma.com/futurenetworks/resources/operator-platform-concept-whitep aper/获得;以及作为文件188r1的ETSI MEC)。
除了MEC系统发现之外,作为前提条件,进一步假设系统间MEC平台发现经由连接联合MEC系统的MEO的专用参考点已被执行,包括(通过MEC平台)发现可用的服务。附加地,假设e-IQN消费者基于由拥有MEC系统1的MNO管理的RAN/云PF执行的预测已获得具有所有属性的e-IQN响应,以及MEC PoP优化已在MEC系统1中被执行,如图18和图19所示。
为简单起见,假设MEC联合仅由两个MEC系统(例如MEC系统1和MEC系统2)形成,以确保服务连续性,特别是对高速V2X场景具有挑战性,MEC系统1的VIS经由MEC系统间的平台到平台参考点向位于MEC系统2中的VIS服务消费者提供关于沿交通工具的路线上的可用边缘资源的e-IQN属性。然后,在MEC系统2内,执行与图18和图19中图示出的MEC PoP优化过程类似的MEC PoP优化过程。此外,虽然VIS是服务,并拥有e-IQN信息,但MEC平台拥有服务注册表,并使VIS的服务发现在两个MEC系统之间成为可能。因此,注意MEC平台本身并不是传输e-IQN信息是重要的。
在各个实施例中,与在MEC系统1的某个MEC主机处实例化的MEC应用(例如,e-IQN消费者)最初相关联的客户端应用决定将MEC应用即时迁移到MEC系统2的MEC主机,该MEC主机已被MEO2标识。该过程将关于图21进行解释。
图21描绘了用于跨MEC联合的MEC PoP优化的示例过程2100,该过程2100影响将MEC应用实例从第一MEC系统迁移(或不迁移)到同一MEC联合的第二MEC系统的决策。在该示例中,假设两个联合MEC系统跨地理区域被部署。该框架也适用于包括多个MEC系统的MEC联合。在该示例中,VIS 1580被实现为MEC平台1532服务。该框架也适用于其中VIS 1580被实现为(生产服务的)MEC应用1526的情况。
该过程2100具有三个前提条件。第一前提条件是e-IQN消费者基于由拥有/操作MEC系统1的MNO管理的RAN/PF 1550、1554执行的预测已获得具有所有属性的e-IQN响应。第二前提条件是MEC联合已经在MEC系统1与MEC系统2之间建立,并且因此,由于MEC平台1532及其支持的服务可以跨形成MEC联合的系统被发现,并且MEC系统间平台到平台的通信是可行的。第三前提条件是MEC PoP优化已经被执行。
过程2100开始于步骤1,在该步骤1中,由MEC系统1中的MEC平台1532经由MEC系统间平台到平台参考点(例如,Mfm-fed参考点)向MEC系统2中的MEC平台1532(MEP-2 1532)提供关于沿路线的(源自VIS的)可用边缘资源的e-IQN属性。在步骤2处,MEP-2 1532经由Mm5参考点向MEC系统2中的MEPM 1806(MEPM-2 1806)提供关于沿路线的可用边缘资源的e-IQN属性。在步骤3处,MEPM-2 1806经由Mm3参考点向MEC系统2中的MEO1810(MEO-2 1810)发送关于沿路线的可用边缘资源的e-IQN属性。
在步骤4处,MEO-2 1810确定边缘/云资源。在一个示例中,MEO 1810将路线航点与经部署的MEC主机进行匹配,标识MEC主机处的资源瓶颈,并建议要对特定的MEC主机和时间实现的VM迁移策略。在步骤5处,MEO-2 1810经由Mm4参考点将关于边缘/云资源的策略(例如,包括VM迁移策略)转发给MEC系统2中的VIM 1808(VIM-2 1808)。在步骤6处,如果存在足够的资源,VIM 1808实现该策略;否则,将其标记为不可行并相应地通知MEO 1810。在步骤7处,与在MEC系统1的MEC主机处实例化的e-IQN消费者(例如MEC应用1526)最初相关联的客户端应用1518将决定MEC应用实例迁移到MEC系统2的不同MEC主机,该MEC主机已由MEO-21810标识。
4.示例边缘计算系统配置和布置
边缘计算是指对处于较靠近于网络的“边缘”或网络的“边缘”的集合的位置处的计算和资源的实现、协调和使用。在网络的边缘处部署计算资源可减少应用和网络等待时间,减少网络回程通信量和相关联的能耗,改善服务能力,改善对安全或数据隐私性要求的合规性(尤其是与常规云计算相比),并且改善总拥有成本。
可以执行边缘计算操作的各个计算平台或其他组件(被称为“边缘计算节点”、“边缘节点”等)可以驻留在系统架构或自组织服务所需要的无论什么位置中。在许多边缘计算架构中,边缘节点被部署在NAN、网关、网络路由器和/或更靠近产生和消费数据的端点设备(例如,UE、IoT设备等)的其他设备处。作为示例,边缘节点可被实现在以下各项中:高性能计算数据中心或云安装;规定的边缘节点服务器、企业服务器、路边服务器、电信中央局;或正在消费边缘服务而被服务的本地或对等边缘处设备。
边缘计算节点可对资源(例如,存储器、CPU、GPU、中断控制器、I/O控制器、存储器控制器、总线控制器、网络连接或会话等)进行分区,其中相应的分区可包含安全和/或完整性保护能力。边缘节点还可通过隔离的用户空间实例(诸如容器、分区、虚拟环境(VE)、虚拟机(VM)、功能即服务(FaaS)引擎、小型服务程序、服务器和/或其他类似的计算抽象)来提供多个应用的编排。容器是软件的提供代码和所需要的依赖关系的所包含的可部署单元。各种边缘系统布置/架构在应用构成方面平等地对待VM、容器和功能。边缘节点基于边缘供应功能来协调,而各种应用的操作利用编排功能(例如,VM或容器引擎等)来协调。编排功能可用于部署隔离的用户空间实例,标识和调度对特定的硬件、安全相关功能(例如,密钥管理、信任锚管理等)以及与隔离的用户空间的供应和生命周期相关的其他任务的使用。
适于边缘计算的应用包括但不限于传统网络功能的虚拟化,包括例如软件定义的联网(SDN)、网络功能虚拟化(NFV)、分布式RAN单元和/或RAN云等。边缘计算的附加示例用例包括计算迁移、内容数据网络(CDN)服务(例如,视频点播、内容流、安全监控、警报系统监测、建筑访问、数据/内容高速缓存等)、游戏服务(例如,AR/VR等)、加速的浏览、IoT和行业应用(例如,工厂自动化)、媒体分析、直播流/转码和V2X应用(例如,驾驶辅助和/或自主驾驶应用)。
本公开提供与多接入边缘计算(MEC)和5G网络实现方式内提供的边缘计算配置有关的特定示例。然而,许多其他标准和网络实现方式可适用于本文中所讨论的边缘和服务管理概念。例如,本文所讨论的实施例可以以位于网络的边缘处的设备的各种组合和布局来适用于许多其他边缘计算/联网技术。可以实现本文实施例的此类其他边缘计算/联网技术的示例包括:内容交付网络(CDN)(也被称为“内容分发网络”,等等);移动性服务提供商(MSP)边缘计算和/或移动性即服务(MaaS)提供商系统(例如,用于AECC架构);星云边缘-云系统;雾计算系统;微云边缘-云系统;移动云计算(MCC)系统;中央局重新架构为数据中心(CORD)、移动CORD(M-CORD)和/或融合的多接入和核心(COMAC)系统;等等。进一步地,本文中所公开的技术可涉及其他IoT边缘网络系统和配置,并且其他中间处理实体和架构也可适用于实践本文中的实施例。
图22是示出用于边缘计算的配置的概览的框图2200,该配置包括在以下示例中的许多示例中被称为“边缘云”的处理层。“边缘云”可以指可互换的云生态系统,该系统涵盖位于网络的边缘处的存储和计算资产,并通过可以以实时地并且以安全地方式感测并适应于不断改变的需求的可扩展的、应用感知的网络互连。边缘云架构用于将计算资源和功率分散到一个或多个网络的边缘(例如,端点设备和/或中间节点,诸如客户端设备/UE)。传统上,服务器的计算能力被用来执行任务和创建分布式系统。在云模型内,此类智能任务由服务器(例如,在数据中心)执行,因此它们可以被转移到具有较低的或几乎没有计算能力的其他设备上。在边缘云2210中,这些处理任务的一些或全部被转移到端点节点和中间节点,诸如客户端设备、IoT设备、网络设备/装置等等。应该注意的是,在一些情境中,端点节点可能是通信路径的终点,而在其他情境中,端点节点可能是中间节点;类似地,在一些情境中,中间节点可能是通信路径的终点,而在其他情境中,中间节点可能是端点节点。
如图所示,边缘云2210共同定位在边缘位置(诸如接入点或基站2240、本地处理中枢2250、或中央局2220),并且因此可以包括多个实体、设备、和装备实例。与云数据中心2210相比,边缘云2210被定位成更靠近端点(消费者和生产者)数据源2260(例如,自主交通工具2261、用户装备2262、商业和工业装备2263、视频捕获设备2264、无人机2265、智慧城市和建筑设备2266、传感器和IoT设备2267等)。在边缘云2210中的边缘处提供的计算、存储器、和存储资源对于为由端点数据源2260使用的服务和功能提供超低等待时间的响应时间以及减少从边缘云2210朝向云数据中心2230的网络回程通信量(由此改善能耗和整体网络使用等益处)至关重要。
计算、存储器和存储是稀缺资源,并且通常根据边缘位置而减少(例如,在消费者端点设备处可用的处理资源比在基站处、比在中央局处可用的处理资源更少)。然而,边缘位置越靠近端点(例如,用户装备(UE)),空间和功率通常就越受限。因此,边缘计算试图通过分配被定位成既在地理上更靠近又在网络访问时间上更靠近的更多的资源来减少网络服务所需的资源量。以此种方式,边缘计算尝试在适当的情况下将计算资源带到工作负荷数据,或者,将工作负荷数据带到计算资源。
以下描述了边缘云架构的各方面,该架构涵盖多种潜在的部署,并解决了一些网络运营商或服务提供商在其自身基础设施中可能具有的限制。这些包括以下的变体:基于边缘位置的配置(例如,因为处于基站级别的边缘在多租户场景中可能具有更受限制的性能和能力);基于对边缘位置、位置的层、或位置的组可用的计算、存储器、存储、结构、加速等资源的类型的配置;服务、安全性、以及管理和编排能力;以及实现端服务的可用性和性能的相关目标。取决于等待时间、距离、和定时特征,这些部署可以在网络层中完成处理,这些网络层可以被视为“接近边缘”层、“靠近边缘”层、“本地边缘”层、“中间边缘”层、或“远边缘”层。
边缘计算是一种开发范式,其中计算在网络的“边缘”处或靠近于网络的“边缘”被执行,典型地通过使用在基站、网关、网络路由器、或与产生和消耗数据的端点设备靠近得多得多的其他设备处实现的计算平台(例如,x86或ARM计算硬件架构)来执行。例如,边缘网关服务器可装配有存储器池和存储资源,以针对连接的客户端设备的低等待时间用例(例如,自主驾驶或视频监控)实时地执行计算。或者作为示例,基站可被扩充有计算和加速资源,以直接为连接的用户装备处理服务工作负荷,而无需进一步经由回程网络传输数据。或者作为另一示例,中央局网络管理硬件能以标准化计算硬件来代替,该标准化计算硬件执行虚拟化网络功能,并为服务的执行提供计算资源并且为连接的设备提供消费者功能。在边缘计算网络内,可能存在计算资源将被“移动”到数据的服务中的场景,以及其中数据将被“移动”到计算资源的场景。或者作为示例,基站计算、加速和网络资源可以提供服务,以便通过激活休眠容量(订阅、按需容量)来根据需要缩放至工作负荷需求,以便管理极端情况、紧急情况或为部署的资源在显著更长的实现的生命周期中提供长寿命。
图23图示出端点、边缘云和云计算环境之间的操作层。具体而言,图23描绘了在网络计算的多个说明性层之间利用边缘云2210的计算用例2305的示例。这些层开始于端点(设备和事物)层2300,该端点层2300访问边缘云2210以进行数据创建、分析、和数据消费活动。边缘云2210可以跨越多个网络层,诸如边缘设备层2310,该边缘设备层2310具有网关、内部(on-premise)服务器、或位于物理上邻近边缘系统中的网络装备(节点2315);网络接入层2320,该网络接入层2320涵盖基站、无线电处理单元、网络中枢、区域数据中心(DC)、或本地网络装备(装备2325);以及位于它们之间的任何装备、设备或节点(在层2312中,未详细图示出)。边缘云2210内和各层之间的网络通信可以经由任何数量的有线或无线介质来实现,包括经由未描绘出的连接性架构和技术来实现。
由于网络通信距离和处理时间约束而导致的等待时间的示例的范围可以从在端点层2300之间时的小于毫秒(ms),在边缘设备层2310处的低于5ms到当与网络接入层2320处的节点通信时的甚至10ms到40ms之间。在边缘云2210之外是核心网络2330层和云数据中心2340层,它们各自均具有增加的等待时间(例如,在核心网络层2330处的50ms-60ms、到在云数据中心层处的100ms或更多ms之间)。因此,在核心网络数据中心2335或云数据中心2345处的、具有至少50ms至100ms或更长的等待时间的操作将无法完成用例2305的许多时间关键的功能。出于说明和对比的目的,提供这些等待时间值中的每一个等待时间值;将会理解,使用其他接入网络介质和技术可以进一步降低等待时间。在一些示例中,相对于网络源和目的地,网络的各个部分可以被分类为“靠近边缘”层、“本地边缘”层、“接近边缘”层、“中间边缘”层或“远边缘”层。例如,从核心网络数据中心2335或云数据中心2345的角度来看,中央局或内容数据网络可以被视为位于“接近边缘”层内(“接近”云,具有在与用例2305的设备和端点通信时的高等待时间值),而接入点、基站、内部服务器或网络网关可以被视为位于“远边缘”层内(“远”离云,具有在与用例2305的设备和端点通信时的低等待时间值)。将会理解,构成“靠近”、“本地”、“接近”、“中间”或“远”边缘的特定网络层的其他分类可以基于等待时间、距离、网络跳数或其他可测量的特性,如从网络层2300-2340中的任一层中的源所测量的特性。
由于多个服务利用边缘云,因此各种用例2305可能在来自传入流的使用压力下访问资源。为了实现低等待时间的结果,在边缘云2210内执行的服务在以下方面平衡了不同的要求:(a)优先级(吞吐量或等待时间)和服务质量(QoS)(例如,在响应时间要求方面,用于自主汽车的通信量可能比温度传感器具有更高的优先级;或者取决于应用,性能敏感度/瓶颈可能存在于计算/加速器、存储器、存储、或网络资源上);(b)可靠性和复原性(例如,取决于应用,一些输入流需要被作用并且以任务关键型可靠性来路由通信量,而一些其他输入流可以容忍偶尔的故障;以及(c)物理约束(例如,功率、冷却和形状因子)。
这些用例的端对端服务视图涉及服务流的概念,并且与事务相关联。事务详细说明了用于消费服务的实体的整体服务要求、以及用于资源、工作负荷、工作流的相关联的服务、以及业务功能和业务水平要求。根据所描述的“条款”执行的服务能以确保事务在服务的生命周期期间的实时和运行时合约合规性的方式在每层处被管理。当事务中的组件缺失其约定的SLA时,系统作为整体(事务中的组件)可以提供以下能力:(1)理解SLA违反的影响,以及(2)增强系统中的其他组件以恢复整体事务SLA,以及(3)实现补救的步骤。
因此,考虑到这些变化和服务特征,边缘云2210内的边缘计算可以提供实时或接近实时地服务和响应于用例2305的多个应用(例如,对象跟踪、视频监控、连接的汽车等)的能力,并满足这些多个应用的超低等待时间要求。这些优势使全新类别的应用(虚拟网络功能(VNF)、功能即服务(FaaS)、边缘即服务(EaaS)、标准过程等)得以实现,这些应用由于等待时间或其他限制而无法利用传统的云计算。
然而,伴随边缘计算的优势而来的有以下注意事项。位于边缘处的设备通常是资源受限的,并且因此存在对边缘资源的使用的压力。典型地,这是通过对供多个用户(租户)和设备使用的存储器和存储资源的池化来解决的。边缘可能是功率受限且冷却受限的,并且因此需要由消耗最多功率的应用对功率使用作出解释。在这些经池化的存储器资源中可能存在固有的功率-性能权衡,因为它们中的许多可能使用新兴的存储器技术,在这些技术中,更多的功率需要更大的存储器带宽。同样,还需要硬件和信任根受信任的功能的改善的安全性,因为边缘位置可以是无人的,并且可能甚至需要经许可的访问(例如,当被容纳在第三方位置时)。在多租户、多所有者、或多访问设置中,此类问题在边缘云2210中被放大,此类设置中,由许多用户请求服务和应用,特别是当网络使用动态地波动以及多个相关者、用例、和服务的组成改变时。
在更一般的级别上,边缘计算系统可以被描述为涵盖在先前讨论的、在边缘云2210(网络层2300-2340)中操作的层处的任何数量的部署,这些层提供来自客户端和分布式计算设备的协调。一个或多个边缘网关节点、一个或多个边缘聚合节点和一个或多个核心数据中心可以跨网络的各个层而分布,以由电信服务提供商(“电信公司”或“TSP”)、物联网服务提供商、云服务提供商(CSP)、企业实体或任何其他数量的实体提供边缘计算系统的实现,或者代表电信服务提供商(“电信公司”或“TSP”)、物联网服务提供商、云服务提供商(CSP)、企业实体或任何其他数量的实体提供边缘计算系统的实现。诸如当进行编排以满足服务目标时,可以动态地提供边缘计算系统的各种实现方式和配置。
与本文提供的示例一致,客户端计算节点可以被具体化为任何类型的端点组件、设备、装置或能够作为数据的生产者或消费者进行通信的其他事物。进一步地,如边缘计算系统中所使用的标签“节点”或“设备”不一定意指此类节点或设备以客户端或代理/仆从/跟随者角色操作;相反,边缘计算系统中的节点或设备中的任一者指代包括分立的或连接的硬件或软件配置以促进或使用边缘云2210的各个实体、节点或子系统。
由此,边缘云2210由网络层2310-2330之间的边缘网关节点、边缘聚合节点或其他边缘计算节点操作并在网络层2310-2330之间的边缘网关节点、边缘聚合节点或其他边缘计算节点内被操作的网络组件和功能特征形成。因此,边缘云2210可被具体化为提供边缘计算和/或存储资源的任何类型的网络,这些边缘计算和/或存储资源被定位成接近具有无线电接入网络(RAN)能力的端点设备(例如,移动计算设备、IoT设备、智能设备等),这在本文中进行讨论。换言之,边缘云2210可被预想为连接端点设备和传统网络接入点、同时还提供存储和/或计算能力的“边缘”,这些传统网络接入点充当进入到包括移动运营商网络(例如,全球移动通信系统(GSM)网络、长期演进(LTE)网络、5G/6G网络等)的服务提供商核心网络中的入口点。其他类型和形式的网络接入(例如,Wi-Fi、长程无线、包括光学网络的有线网络)也可替代此类3GPP运营商网络被利用或与此类3GPP运营商网络组合来利用。
边缘云2210的网络组件可以是服务器、多租户服务器、装置计算设备和/或任何其他类型的计算设备。例如,边缘云2210可以包括作为包括壳体、机壳、机箱或外壳的自包含电子设备的装置计算设备。在一些情况下,可以针对便携性来确定壳体尺寸,以使得其可由人类携载和/或被运输。示例壳体可包括形成一个或多个外表面的材料,该一个或多个外表面部分地或完整地保护装置的内容物,其中,保护可包括天气保护、危险环境保护(例如,EMI、振动、极端温度)和/或使得能够浸入水中。示例壳体可包括用于为固定式和/或便携式实现方式提供功率的功率电路系统,诸如AC功率输入、DC功率输入、(多个)AC/DC或DC/AC转换器、功率调节器、变压器、充电电路系统、电池、有线输入和/或无线功率输入。示例壳体和/或其表面可包括或连接至安装硬件,以实现到诸如建筑物、电信结构(例如,杆、天线结构等)和/或机架(例如,服务器机架、刀片支架等)之类的结构的附接。示例壳体和/或其表面可支持一个或多个传感器(例如,温度传感器、振动传感器、光传感器、声学传感器、电容传感器、接近度传感器等)。一个或多个此类传感器可被包含在装置的表面中、由装置的表面承载、或以其他方式被嵌入在装置的表面中和/或被安装至装置的表面。示例壳体和/或其表面可支持机械连接性,诸如推进硬件(例如,轮子、螺旋桨等)和/或铰接硬件(例如,机械臂、可枢转附件等)。在一些情况下,传感器可包括任何类型的输入设备,诸如用户接口硬件(例如,按键、开关、拨号盘、滑块等)。在一些情况下,示例壳体包括包含在其中、由其携载、嵌入其中和/或附接于其的输出设备。输出设备可包括显示器、触摸屏、灯、LED、扬声器、I/O端口(例如,USB)等。在一些情况下,边缘设备是为特定目的而被呈现在网络中、但是可具有可用于其他目的的处理和/或其他能力的设备(例如,红绿灯)。此类边缘设备可以独立于其他联网设备,并且可设置有具有适合其主要目的的形状因子的壳体;但对于不干扰其主要任务的其他计算任务仍然是可用的。边缘设备包括物联网设备。装置计算设备可包括用于管理诸如设备温度、振动、资源利用率、更新、功率问题、物理和网络安全性等之类的本地问题的硬件和软件组件。结合图28-图29描述了用于实现装置计算设备的示例硬件。边缘云2210还可以包括一个或多个服务器和/或一个或多个多租户服务器。此类服务器可包括操作系统和虚拟计算环境。虚拟计算环境可包括管理(生成、部署、损毁等)一个或多个虚拟机、一个或多个容器等的管理程序。此类虚拟计算环境提供其中一个或多个应用和/或其他软件、代码或脚本可在与一个或多个其他应用、软件、代码或脚本隔离的同时执行的执行环境。
在图24中,(以移动设备、计算机、自主交通工具、业务计算装备、工业处理装备的形式的)各种客户端端点2410交换特定于端点网络聚合类型的请求和响应。例如,客户端端点2410可以通过借助于内部网络系统2432交换请求和响应2422,经由有线宽带网络获得网络接入。一些客户端端点2410(诸如移动计算设备)可以通过借助于接入点(例如,蜂窝网络塔)2434交换请求和响应2424,经由无线宽带网络获得网络接入。一些客户端端点2410(诸如自主交通工具)可通过街道定位网络系统2436,经由无线机载网络获得请求和响应2426的网络接入。然而,无论网络接入的类型如何,TSP可以在边缘云2210内部署聚合点2442、2444来聚合通信量和请求。因此,在边缘云2210内,TSP可以(诸如在边缘聚合节点2440处)部署各种计算和存储资源以提供请求的内容。边缘聚合节点2440和边缘云2210的其他系统被连接至云或数据中心2460,该云或数据中心2460使用回程网络2450来满足来自云/数据中心对网站、应用、数据库服务器等的更高等待时间请求。边缘聚合节点2440和聚合点2442、2444的附加或合并的实例(包括部署在单个服务器框架上的那些实例)也可以存在于边缘云2210或TSP基础设施的其他区域内。
图25图示出根据[MEC003]提供功能的MEC系统参考架构(或MEC架构)2500。MEC在网络的边缘处为应用开发人员和内容提供商提供云计算功能以及IT服务环境。该环境的特征是超低等待时间和高带宽以及对可由应用利用的无线电网络信息的实时访问。MEC技术准许向移动订户、企业和垂直细分市场灵活并且快速地部署创新应用和服务。具体而言,就汽车行业而言,诸如V2X之类的应用(例如,基于IEEE 802.11p的协议(诸如DSRC/ITS-G5)或基于3GPP C-V2X的协议)需要交换数据,向聚合点提供数据,并且访问提供从大量传感器(由各种汽车、路边单元等)推导出的当地情形的概览的数据库中的数据。
MEC网络架构2500包括MEC主机2502、虚拟化基础设施管理器(VIM)2508、MEC平台管理器2506、MEC编排器2510、操作支持系统(OSS)2512、用户应用代理2514、在UE 2520上运行的UE应用2518、以及CFS门户2516。MEC主机2502可以包括MEC平台2532,该MEC平台2532具有过滤规则控制组件2540、DNS处置组件2542、服务注册表2538和MEC服务2536。MEC服务2536可以包括至少一个调度器,该至少一个调度器可以用于选择用来在虚拟化基础设施(VI)2526上实例化MEC应用(或NFV)2522的资源。MEC应用2526可以被配置成用于提供服务2530和/或诸如本文中讨论的那些之类的一某些其他服务,该服务2530可以包括处理与一个或多个无线连接(例如,到一个或多个RAN或核心网络功能的连接)相关联的不同类型的网络通信通信量。另一MEC主机2502可以与MEC主机2502具有相同或类似的配置/实现方式,并且在另一MEC主机2502内实例化的另一MEC应用2526可以类似于在MEC主机2502内实例化的MEC应用2526。VI 2522包括经由MP2接口耦合至MEC平台2524的数据平面2522。图25中图示出MEC架构2500的各种网络实体之间的附加接口。
MEC系统2500包括三组参考点,包括:“Mp”参考点,与MEC平台功能有关;“Mm”参考点,其为管理参考点;以及“Mx”参考点,其将MEC实体连接至外部实体。MEC系统2500中的接口/参考点可包括基于IP的连接,并且可用于提供表述性状态传递(REST或RESTful)服务,并且使用参考点/接口来传达的消息可采用XML、HTML、JSON或某种其他期望的格式,诸如本文中所讨论的那些格式。在其他实施例中,也可使用合适的认证、授权和计费(AAA)协议(诸如,RADIUS协议或DIAMETER协议)通过参考点/接口来进行通信。
MEC架构2500的各实体之间的逻辑连接可以是接入不可知的,并且不取决于特定部署。MEC使得MEC应用2526能够实现为在VI 2522之上运行的仅软件实体,VI 2522位于网络边缘中或靠近网络边缘。MEC应用2526是可在MEC系统2502内的MEC主机2500上实例化且能够潜在地提供或消费MEC服务2536的应用。
由图25描绘的MEC实体可以被编组为MEC系统级实体、MEC主机级实体、以及网络级实体(未示出)。网络级(未示出)包括各种外部网络级实体,诸如3GPP网络、局域网(例如,LAN、WLAN、PAN、DN、LADN等)、以及(多个)外部网络。MEC系统级包括MEC系统级管理实体和UE2520,并且在下文更详细地讨论。MEC主机级包括一个或多个MEC主机2502、2504以及MEC管理实体,这些MEC管理实体提供用于在运营商网络或运营商网络的子集内运行MEC应用2526的功能。MEC管理实体包括处置对特定MEC平台2532、MEC主机2502、以及要运行的MEC应用2526的MEC特定功能的管理的各种组件。
MEC平台管理器2506是包括MEC平台元件管理组件2544、MEC应用规则和要求管理组件2546、以及MEC应用生命周期管理组件2548的MEC管理实体。MEC架构2500内的各种实体可以执行如[MEC003]中所讨论的功能。远程应用2550被配置成经由MEC编排器2510和MEC平台管理器2506与MEC主机2502(例如,与MEC应用2526)通信。
MEC主机2502是包含MEC平台2532和VI 2522的实体,MEC主机2502出于运行MEC应用2526的目的提供计算、存储和网络资源。VI 2522包括数据平面(DP)2524,该数据平面(DP)2524执行由MEC平台2532接收的通信量规则2540,并且在MEC应用2526、MEC服务2536、DNS服务器/代理(参见例如,经由DNS处置实体2542)、3GPP网络、本地网络和外部网络之间路由通信量。MEC DP 2524可与(R)AN节点和3GPP核心网络连接,和/或可经由更宽的网络(诸如因特网、企业网络等)与接入点连接。
MEC平台2532是在特定VI 2522上运行MEC应用2526并使其能够提供和消费MEC服务2536所要求的必要功能的集合,并且那可为其自身提供数种MEC服务937a。MEC平台2532还可以提供各种服务和/或功能,诸如提供其中MEC应用2526可以发现、广告、消费、和提供MEC服务2536(在下文讨论)的环境,MEC服务2536包括当被支持时通过其他平台可用的MEC服务2536。MEC平台2532可以能够允许经授权的MEC应用2526与位于外部网络中的第三方服务器通信。MEC平台2532可从MEC平台管理器2506、应用或服务接收通信量规则,并相对应地指令数据平面(参见例如,通信量规则控制2540)。MEC平台2532可经由Mp2参考点向VI 2522内的DP 2524发送指令。MEC平台2532与VI 2522的DP 2524之间的Mp2参考点可用于就关于如何在应用、网络、服务等之间对通信量进行路由来指令DP 2534。MEC平台2532可将在通信量规则中表示UE 2520的令牌变换为特定的IP地址。MEC平台2532还接收来自MEC平台管理器2506的DNS记录,并相对应地配置DNS代理/服务器。MEC平台2532主控包括多接入边缘服务(在下文讨论)的MEC服务2536,并提供对持久性存储和一天中的时间信息的访问权。此外,MEC平台2532可经由Mp3参考点与其他MEC服务器2502的其他MEC平台2532通信。
VI 2522表示构建在其中部署、管理和执行MEC应用2526和/或MEC平台2532的环境的所有硬件和软件组件的全体。VI 2522可跨越若干个位置,并且提供这些位置之间的连接性的网络被认为是VI 2522的部分。VI2522的物理硬件资源包括通过虚拟化层(例如,管理程序、VM监视器(VMM)等等)向MEC应用2526和/或MEC平台2532提供处理、存储和连接性的计算、存储和网络资源。虚拟化层可将MEC服务器2502的物理硬件资源抽象和/或逻辑地分区成硬件抽象层。虚拟化层可还可使得实现MEC应用2526和/或MEC平台2532的软件能够使用底层VI 2522,并且虚拟化层可向MEC应用2526和/或MEC平台2532提供虚拟化资源,使得MEC应用2526和/或MEC平台2532能够被执行。
MEC应用2526是可在MEC系统2500内的MEC主机/服务器2502上实例化且能够潜在地提供或消费MEC服务2536的应用。术语“MEC服务”是指经由MEC平台2532、由MEC平台2532自身或由MEC应用2526提供的服务。MEC应用2526可以作为在由MEC服务器2502提供的VI2522之上的VM来运行,并且可与MEC平台2532交互以消费和提供MEC服务2536。MEC平台2532与MEC应用2526之间的Mp1参考点用于消费和提供服务特定功能。Mp1为各种服务(诸如由MEC主机2502提供的MEC服务2536)提供服务注册2538、服务发现和通信支持。Mp1还可提供应用可用性、会话状态重定位支持过程、通信量规则和DNS规则激活、对持久性存储和一天中的时间信息的访问权等等。
基于由MEC管理(例如,MEC平台管理器2506)验证的配置或请求,MEC应用2526被实例化在MEC服务器2502的VI 2522上。MEC应用2526还可与MEC平台2532交互以执行与MEC应用2526的生命周期有关的某些支持过程,诸如指示可用性、准备用户状态的重定位等。MEC应用2526可具有与其相关联的某个数量的规则和要求,诸如所要求的资源、最大等待时间、所要求或有用的服务等。这些要求可由MEC管理来验证,并且如果未命中则可以被赋值为默认值。MEC服务2536是由MEC平台2532和/或MEC应用2526提供和/或消费的服务。服务消费者(例如,MEC应用2526和/或MEC平台2532)可通过各个API(包括本文中所讨论的各种MEC V2XAPI和其他MEC API)与特定的MEC服务2536通信。当由应用提供时,MEC服务2536可以通过Mp1参考点被注册在MEC平台2532的服务注册表2538中的服务列表中。附加地,MEC应用2526可以订阅一个或多个服务2530/2536,通过Mp1参考点针对该一个或多个服务2530/2536进行授权。
MEC服务2536的示例包括VIS、RNIS[MEC012]、LS[MEC011]、UE_ID服务[MEC014]、BWMS[MEC015]、WAIS[MEC028]、FAIS[MEC029]和/或其他MEC服务。RNIS在可用时向经授权的MEC应用2526提供与无线电网络相关的信息,并向MEC应用2526披露适当的最新无线电网络信息。RNI可尤其包括无线电网络状况、与用户平面相关的测量和统计学信息、与由与MEC主机2502相关联的(多个)无线电节点服务的UE 2520相关的信息(例如,UE上下文和无线电接入载波)、与由与MEC主机2502相关联的(多个)无线电节点服务的UE 2520相关的信息的改变,等等。能以相关粒度(例如,逐UE 2520地、逐蜂窝小区地、逐时间段地)提供RNI。
服务消费者(例如,MEC应用2526、MEC平台2532等)可通过RNI API与RNIS通信,以从相对应的RAN获得情境信息。RNI可经由NAN被提供至服务消费者(例如,(R)AN节点、RRH、AP等)。RNI API可支持基于查询和订阅(例如,发布/订阅)两者的机制,这些机制通过表述性状态传递(RESTful)API或通过MEC平台2532的消息代理器(未示出)来使用。MEC应用2526可经由传输信息查询过程在消息代理上查询信息,其中,可经由合适的配置机制将传输信息预先预设至MEC应用2526。经由RNI API传递的各种消息可采用XML、JSON、Protobuf或某种其他合适的格式。
VIS提供支持各种V2X应用,包括根据本文讨论的各种实施例的旅程知晓QoS预测等。RNI可由MEC应用2526和MEC平台2532用于优化现有服务,并用于提供基于关于无线电状况的最新信息的新类型的服务。作为示例,MEC应用2526可使用RNI来优化当前服务,诸如视频吞吐量引导。在吞吐量引导中,无线电分析MEC应用2526可使用MEC服务来向后端视频服务器提供关于估计下一时刻在无线电下行链路接口处将要可用的吞吐量的接近实时的指示。吞吐量引导无线电分析应用基于其从在MEC服务器2502上运行的多接入边缘服务获得的所要求的无线电网络信息来计算吞吐量引导。诸如当某个MEC应用2526使用简单的请求-响应模型(例如,使用RESTful机制)来请求单条信息而其他MEC应用2526(例如,使用发布/订阅机制和/或消息代理器机制)订阅与信息改变有关的多个不同通知时,RNI还可由MEC平台2532用于优化支持服务连续性所要求的移动性过程。
LS在可用时可向经授权的MEC应用2526提供位置相关信息,并向MEC应用2526披露此类信息。利用位置相关信息,MEC平台2532或者一个或多个MEC应用2526执行主动的设备位置跟踪、基于位置的服务推荐、和/或其他类似服务。LS支持位置检取机制,例如,针对每个位置信息请求,位置仅被报告一次。LS支持位置订阅机制,例如,针对每个位置请求,位置能够周期地或基于特定事件(诸如位置改变)被报告多次。位置信息可尤其包括当前由与MEC服务器2502相关联的(多个)无线电节点服务的特定UE 2520的位置、与当前由与MEC服务器2502相关联的(多个)无线电节点服务的所有UE 2520的位置有关的信息、与当前由与MEC服务器2502相关联的(多个)无线电节点服务的某个类别的UE 2520的位置有关的信息、处于特定位置的UE 2520的列表、与当前与MEC主机2502相关联的所有无线电节点的位置有关的信息,等等。位置信息可采用地理位置、全球导航卫星服务(GNSS)坐标、蜂窝小区身份(ID)等等。LS是通过在开放移动联盟(OMA)规范“针对区域性存在的RESTful网络API(RESTful Network API for Zonal Presence)“OMA-TS-REST-NetAPI-ZonalPresence-V1-0-20160308-C”中定义的API可访问的。区域性存在服务利用“区域”的概念,其中,区域使其自身适合于被用来根据期望的部署对与MEC主机或MEC主机2502相关联的所有无线电节点或其子集进行编组。在此方面,OMA区域性存在API为MEC应用2526提供用于检取与区域、关联于区域的接入点、以及连接至接入点的用户有关的信息的手段。另外,OMA区域性存在API允许经授权的应用订阅通知机制,该通知机制报告与区域内的用户活动有关的情况。MEC服务器2502可使用OMA区域性存在API访问各个UE 2520的位置信息或区域性存在信息以标识UE 2520的相对位置或地点。
BWMS为被路由至MEC应用2526或从MEC应用2526路由的某些通信量提供带宽分配,并且指定静态/动态上行/下行带宽资源,包括带宽尺寸和带宽优先级。MEC应用2526可使用BWMS将带宽信息更新至MEC平台2532/接收来自MEC平台2532的带宽信息。可向在同一MEC服务器2502上并行地运行的不同MEC应用2526分配特定的静态、动态上行/下行带宽资源,包括带宽尺寸和带宽优先级。BWMS包括带宽管理(BWM)API,以允许注册的应用静态地和/或动态地逐会话/应用地注册特定的带宽分配。BWM API包括使用RESTful服务或某个其他合适的API机制、为BWM功能进行的HTTP协议绑定。
UE身份特征的目的在于允许MEC系统2500中的UE特定通信量规则。当MEC系统2500支持UE身份特征时,MEC平台2532为MEC应用2526提供注册表示UE 2520的标签或表示相应的UE 2520的标签列表的功能(例如,UE身份API)。每个标签映射到MNO的系统中的特定UE2520中,并且将映射信息提供给MEC平台2532。UE身份标签注册触发MEC平台2532激活链接至标签的(多个)对应通信量规则2540。MEC平台2532还为MEC应用2526提供调用注销过程以针对该用户禁用或以其他方式停止使用通信量规则的功能(例如,UE身份API)。
WAIS是向MEC系2500内的服务消费者提供WLAN接入相关信息的服务。WAIS对于经授权的MEC应用2526而言是可用的,并且通过Mp1参考点被发现。可基于诸如每站、每NAN/AP或每多个AP(多AP)的信息之类的参数来调整WLAN接入信息的粒度。WLAN接入信息可由服务消费者用于优化现有服务并用于提供新类型的服务,这些新类型的服务基于来自WLAN AP的最新信息,该最新信息可能与诸如RNI或固定接入网络信息之类的信息进行组合。WAIS以RESTful API的形式定义协议、数据模型和接口。关于AP和客户站的信息可通过查询或通过对通知进行订阅来请求,这两者中的每一者均包括基于属性的过滤和属性选择器。
FAIS是向MEC系统2500内的服务消费者提供固定接入网络信息(或FAI)的服务。FAIS对于经授权的MEC应用2526而言是可用的,并且通过Mp1参考点被发现。FAI可由MEC应用2526和MEC平台2532用于优化现有服务并用于提供新类型的服务,这些新类型的服务基于来自固定接入(例如,NAN)的最新信息,该最新信息可能与来自其他接入技术的诸如RNI或WLAN信息之类的信息进行组合。服务消费者通过FAI API与FAIS进行交互,以从固定接入网络获得情境信息。MEC应用2526和MEC平台2532两者可消费FAIS;并且MEC平台2532和MEC应用2526两者可以是FAI的提供方。FAI API支持通过RESTful API或通过诸如消息总线之类的替代传输来使用的查询和订阅两者(发布/订阅机制)。也可以使用替代的传输。
MEC管理包括MEC系统级管理和MEC主机级管理。MEC管理包括MEC平台管理器2506和VI管理器(VIM)2508,并且处置对特定MEC服务器2502和在其上运行的应用的MEC特定功能的管理。在一些实现方式中,多接入边缘管理组件中的一些或全部可由位于一个或多个数据中心中的一个或多个服务器实现,并且可使用与用于使NF虚拟化的NFV基础设施连接的虚拟化基础设施,或者使用与NFV基础设施相同的硬件。
MEC平台管理器2506负责管理应用的生命周期,包括向MEC编排器(MEC-O)2510通知有关的应用相关事件。MEC平台管理器2506还向MEC平台2532提供MEC平台元件管理功能2544,管理MEC应用规则和要求2546(包括服务授权、通信量规则、DNS配置和解决冲突)并管理MEC应用生命周期管理2548。MEC平台管理器2506还可接收来自VIM 2508的虚拟化资源故障报告和性能测量以供进一步处理。MEC平台管理器2506与MEC平台2532之间的Mm5参考点用于执行平台配置、对MEC平台元件管理功能2544的配置、MEC应用规则和要求2546、MEC应用寿命周期管理2548、以及对应用重定位的管理。
VIM 2508可以是分配、管理和释放VI 2522的虚拟化(计算、存储和联网)资源并准备VI 2522以运行软件镜像的实体。为了这么做,VIM 2508可通过VIM 2508与VI 2522之间的Mm7参考点与VI 2522通信。准备VI 2522可包括配置VI 2522并接收/存储软件镜像。当被支持时,VIM 2508可提供对应用的快速预设,诸如在“用于微云部署的Openstack++(Openstack++for Cloudlet Deployments)”中所描述,可在http://reports-archive.adm.cs.cmu.edu/anon/2015/CMU-CS-15-123.pdf获得。VIM2508还可收集并报告与虚拟化资源有关的性能和故障信息,并在被支持时执行应用重定位。对于来自/去往外部云环境的应用重定位,VIM 2508可与外部云管理器交互以例如使用在“在微云上的自适应VM移交(Adaptive VM Handoff Across Cloudlets)”中所描述的机制和/或可能通过代理来执行应用重定位。此外,VIM 2508可经由Mm6参考点与MEC平台管理器2506通信,该MEC平台管理器2506可用于管理虚拟化资源,例如,用于实现应用生命周期管理。而且,VIM 2508可经由Mm4参考点与MEC O 2510通信,MEC O 2510可用于管理MEC服务器2502的虚拟化的资源并且用于管理应用镜像。管理虚拟化资源可包括跟踪可用的资源容量等。
MEC系统级管理包括MEC O 2510,该MEC O 2510具有对完整MEC系统2500的概览。MEC-O 2510可基于所部署的MEC主机2502、可用的资源、可用的MEC服务2536、以及拓扑来维护MEC系统2500的整体视图。MEC-O 2510与MEC平台管理器2506之间的Mm3参考点可用于对应用生命周期、应用规则和要求的管理并保持对可用MEC服务2536的跟踪。MEC-O2510可经由Mm9参考点与用户应用生命周期管理代理(UALMP)2514通信,以便管理由UE应用2518请求的MEC应用2526。
MEC-O 2510还可负责应用封装的装载,包括:检查封装的完整性和真实性,验证应用规则和要求并在必要的情况下对它们进行调整以符合运营方策略,保持对所装载的封装的记录,以及准备(多个)VIM 2508来处置应用。MEC-O 2510可基于诸如等待时间、可用的资源、以及可用的服务之类的约束为应用实例化选择适当的(多个)MEC主机901。MEC-O 2510还可触发应用实例化和终止,并且按需要并在被支持时触发应用重定位。
操作支持系统(OSS)2512是经由面向客户的服务(CFS)门户2516、通过Mx1参考点并从UE应用2518接收对MEC应用2526的实例化或终止的请求的操作者的OSS。OSS 2512决定对这些请求的准许。CFS门户2516(以及Mx1接口)可由第三方用于向MEC系统2500请求在该MEC系统2500中运行应用2518。准许的请求可被转发至MEC-O 2510以供进一步处理。当被支持时,OSS 2512还接收来自UE应用2518的对外部云与MEC系统2500之间的应用进行重定位的请求。OSS 2512与MEC平台管理器2506之间的Mm2参考点用于MEC平台管理器2506配置、故障和性能管理。MEC-O 2510与OSS2512之间的Mm1参考点用于触发MEC系统2500中的MEC应用2526的实例化和终止。
(多个)UE应用2518(也称为“设备应用”等等)是在设备2520中运行的一个或多个应用,该设备2520具有经由用户应用生命周期管理代理2514来与MEC系统2500交互的能力。(多个)UE应用2518可以是一个或多个客户端应用,可包括一个或多个客户端应用,或可与一个或多个客户端应用交互,在MEC的情境中,该一个或多个客户端是在利用由一个或多个特定MEC应用2526提供的功能的设备2518上运行的应用软件。用户应用LCM代理2514可对来自UE 2520中的UE应用2518的请求进行授权,并与OSS 2512和MEC-O 2510交互以供对这些请求进行进一步处理。在MEC的情境中的术语“生命周期管理”是指管理MEC应用2526实例的实例化、维护和终止所要求的功能集。用户应用LCM代理2514可经由Mm8参考点与OSS 2512交互,并且用于处置对在MEC系统2500中运行应用的UE 2518请求。用户应用可以是响应于用户的请求、经由在UE 2520中运行的应用(例如,UE应用2518)而被实例化在MEC系统2500中的MEC应用2526。用户应用LCM代理2514允许UE应用2518请求用户应用的装载、实例化、终止以及在被支持时用户应用进入和离开MEC系统2500的重定位。其还允许向用户应用通知用户应用的状态。用户应用LCM代理2514仅可从移动网络内部访问,并且可仅在受MEC系统2500支持时可用。UE应用2518可使用用户应用LCM代理2514与UE应用2518之间的Mx2参考点来向MEC系统2500请求在该MEC系统2500中运行应用或将应用移入或移出MEC系统2500。Mx2参考点可仅在移动网络内部可访问,并且仅在受MEC系统2500支持时可用。
为了在MEC系统2500中运行MEC应用2526,MEC-O 2510接收由OSS 2512、第三方或UE应用2518触发的请求。响应于此类请求的接收,MEC-O 2510选择MEC服务器/主机2502来主控MEC应用2526以供进行计算转移等。这些请求可包括关于要运行的应用的信息并且可能包括其他信息,诸如需要应用是活跃的所在的位置、其他应用规则和要求、以及在应用镜像尚未被装载在MEC系统2500中的情况下该应用镜像的位置。
MEC-O 2510可选择用于计算密集型任务的一个或多个MEC服务器2502。所选择的一个或多个MEC服务器2518可基于各种操作参数来卸载UE应用2518的计算任务,这些操作参数诸如网络能力和状况、计算能力和状况、应用要求、和/或其他类似的操作参数。应用要求可以是关联至一个或多个MEC应用2526/与一个或多个MEC应用2526相关联的规则和要求,诸如:应用的部署模型(例如,其是否为每个用户一个实例、每个主机一个实例、在每个主机上一个实例等);所要求的虚拟化资源(例如,计算、存储、网络资源,包括特定的硬件支持);等待时间要求(例如,最大等待时间、等待时间约束有多严格,用户之间的等待时间公平性);对位置的要求;MEC应用2526要能够运行所要求的/对MEC应用2500要能够运行有用的多接入边缘服务;MEC应用2526能够利用的(如果可用)多接入边缘服务;连接性或移动性支持/要求(例如,应用状态重定位、应用实例重定位);所要求的多接入边缘特征,诸如,VM重定位支持或UE身份;所要求的网络连接性(例如,到MEC系统2500内的应用的连接性、到本地网络或到互联网的连接性);与运营商的MEC系统2500部署或移动网络部署有关的信息(例如,拓扑、成本);对访问用户通信量的要求;对持久性存储的要求;通信量规则2540;DNS规则2542等。
MEC-O 2510考虑上文列出的要求和信息以及关于当前在MEC系统2500中可用的资源的信息,以选择一个或若干个MEC服务器2502来主控MEC应用2526和/或用于计算转移。在一个或多个MEC服务器2502被选择之后,MEC-O 2510向所选择的(多个)MEC主机2502请求对(多个)应用或对应用任务进行实例化。选择MEC服务器2502所使用的实际算法取决于实现方式、配置、和/或运营商部署。(多个)算法选择可基于任务转移标准/参数,例如,通过将执行应用任务以及网络功能、处理和转移译码/编码、或区分各RAT之间的通信量的网络、计算和能耗要求考虑在内。在某些情况(例如,导致等待时间增加的UE移动性事件、负载平衡决策等)下,并且如果被支持,则MEC-O 2510可决定选择一个或多个新的MEC主机2502充当主节点,并且发起应用实例或应用相关状态信息从一个或多个源MEC主机2502到一个或多个目标MEC主机2502的传输。
在第一实现方式中,5GS的用户平面功能(UPF)被映射到MEC架构2500中作为MEC数据平面2524。在这些实现方式中,UPF处置PDU会话的用户平面路径。附加地,UPF提供到数据网络(DN)的接口并且支持PDU会话锚的功能。
在第二实现方式中,5GS的应用功能(AF)被映射到MEC架构2500中作为MEC平台2532。在这些实现方式中,AF可配置或可操作用于执行对通信量路由的应用影响,访问网络能力披露,并与策略框架交互以获得策略控制。第二实现方式可与第一实现方式组合,或可以是独立式实现方式。在第一和/或第二实现方式中,由于用户通信量被路由到本地DN,因此MEC应用2526、2527和/或2528可被映射在5GS的DN中或被映射到5GS的DN。
在第三实现方式中,5GS的RAN可以是基于VNF的虚拟RAN,并且UPF可配置或可操作用于充当NF虚拟化基础设施(NFVI)(例如,VI 2522)内的MEC数据平面2524。在这些实现方式中,AF可被配置为具有MEC API、MEC应用启用功能(参见例如,[MEC011])和API原理功能(参见例如,[MEC009])的MEC平台VNF(参见例如图26的讨论)。附加地,本地DN可包括被实例化为VNF的MEC应用2526、2527和/或2528。该实现方式可被配置成根据[MEC003]和/或ETSIGR MEC 017版本1.1.1(2018年2月)(“[MEC017]”)来提供功能。第三实现方式可与第一实现方式和/或第二实现方式组合,或可以是独立式实现方式。
附加地或替代地,接入级边缘(例如,先前讨论的图31的NAN 3128、NAN 3130和NAN3132和/或其他NAN)可使用一个或多个API来与局部/区域级边缘网络通信。局部/区域级边缘网络可包括使用相对应的应用来与国家级边缘网络通信的网络节点。国家级边缘可包括使用应用来接入全球级边缘内的一个或多个远程云的各种NAN。NAN也可配置或可操作用于垂直细分市场管理和SLA合规性。附加地或替代地,MEC部署可基于“边缘”的定义以向MNO提供自由度,尤其是当在NFV环境中部署MEC时(例如,MEC实体可被实例化为虚拟化NV(VNF),由此在针对运营商的部署方面具有高灵活性)。
在一些实施例中,可以取决于用例/垂直分段/要处理的信息来灵活地部署MEC系统2500。MEC系统2500的一些组件可以与系统的其他元件共处一地。作为示例,在某些用例(例如,企业)中,MEC应用2526可能需要在本地消费MEC服务,因此在本地部署装配有所需要的API集合的MEC主机可能是高效的。在另一示例中,将MEC服务器2502部署在数据中心(其可以远离于接入网络)可能不需要主控如RNI API(其可以用于从无线电基站收集无线电网络信息)之类的一些API。另一方面,可以精化RNI信息并使其在云RAN(CRAN)环境中在聚合点处可用,由此使得能够执行合适的无线电知晓的通信量管理算法。在一些其他方面,带宽管理API可能既存在于接入级边缘处又存在于更远的边缘位置中,以便设置传输网络(例如,针对基于CDN的服务)。
图26图示出NFV环境中的MEC参考架构2600。MEC架构2600可以被配置成用于提供符合[ETSINFV]的功能。MEC架构2600包括MEC平台2602、MEC平台管理器-NFV(MEPM-V)2614、数据平面2608、NFV基础设施(NFVI)2610、VNF管理器(VNFM)2620和2622、NFV编排器(NFVO)2624、MEC应用编排器(MEAO)2626、OSS 2628、用户应用LCM代理2630、UE应用2634和CFS门户2632。MEC平台管理器2614可以包括MEC平台元件管理2616、以及MEC应用规则和要求管理2618。MEC平台2602可以经由Mp3接口耦合至另一MEC平台2606。
在该实施例中,MEC平台2602被部署为VNF。MEC应用2604可以像VNF一样朝向ETSINFV管理和编排(MANO)组件。这允许对ETSI NFV MANO功能的重用。可能未使用完整的MANO功能集合,并且可能需要某些附加功能。如本文中所讨论,此类指定的ME应用由名称“MEC应用VNF”或“MEA-VNF”表示。虚拟化基础设施被部署为NFVI 2610,并且它的虚拟化的资源由虚拟化基础设施管理器(VIM)2612管理。出于该目的,可以使用由ETSI NFV基础设施规范定义的过程中的一个或多个过程(参见例如,ETSI GS NFV-INF 003版本2.4.1(2018年2月)、ETSI GS NFV-INF 004版本2.4.1(2018年2月)、ETSI GS NFV-INF 005版本3.2.1(2019年4月)、以及ETSI GS NFV-IFA 009版本1.1.1(2016年7月)(统称为“[ETSINFV]”))。MEA-VNF2604向各个VNF一样被管理,允许NFV内MEC部署可以将某些编排和LCM任务委派给如ETSI NFV MANO定义的NFVO 2624以及VNFM 2620和2622。
当MEC平台被实现为VNF(例如,MEC平台VNF 2602)时,MEPM-V 2614可以被配置成用于用作元素管理器(EM)。MEAO 2626使用NFVO2624进行资源编排,以及将MEA-VNF 260集合作为一个或多个NFV网络服务(NS)进行编排。MEPM-V 2614将LCM部分委派给一个或多个VNFM 2620和2622。特定的或通用的VNFM 2620、2622被用于执行LCM。MEPM-V 2614和VNFM(ME平台LCM)2620可以按照3GPP TR 32.842版本13.1.0(2015年12月21日)中的整体概念作为单个封装部署,或者说VNFM是通用VNFM,并且MEC平台VNF 2602和MEPM-V 2614由单个供应商提供。
MEC应用2604和MEC平台2614之间的Mp1参考点对MEC应用2604而言可以是任选的,除非它是提供和/或消费MEC服务的应用。MEAO2626与MEPM-V 2614之间的Mm3*参考点基于Mm3参考点(参见,例如[MEC003])。可以对此参考点配置修改,以适应MEPM-V 2614与VNFM(ME应用LCM)2622之间的分隔。在ETSI MEC架构的元件与ETSI NFV架构的元件之间引入了以下新的参考点(Mv1、Mv2和Mv3),以支持对ME应用VNF2604的管理。
以下参考点与现有的NFV参考点相关,但仅功能的子集可用于ETSI MEC,并且扩展可能是必要的。Mv1是连接MEAO 2626和NFVO 2624的参考点,并与ETSI NFV中定义的Os-Ma-nfvo参考点相关)。Mv2是连接执行MEC应用VNF 2604的LCM的VNFM 2622与MEPM-V 2614以允许在这些实体之间交换LCM相关的通知的参考点。Mv2与ETSI NFV中定义的Ve-Vnfm-em参考点相关,但可能包括附加内容,并且可能不使用由Ve-Vnfm-em提供的所有功能。Mv3是连接VNFM 2622与ME应用VNF 2604实例,以允许交换(例如,与MEC应用LCM或特定于初始部署的配置相关的)消息的参考点。Mv3与ETSI NFV中定义的Ve-Vnfm-vnf参考点相关,但可能包括附加内容,并且可能不使用由Ve-Vnfm-vnf提供的所有功能。
如同它们由ETSI NFV定义一样使用以下参考点:Nf-Vn参考点将每个ME应用VNF2604与NFVI 2610连接。Nf-Vi参考点连接NFVI 2610和VIM 2612。Os-Ma-nfvo参考点连接OSS 2628和NFVO 2624,并且主要用于管理NS(例如,被连接并被编排以递送服务的多个VNF)。Or-Vnfm参考点连接NFVO 2624和VNFM(MEC平台LCM)2620,并且主要用于NFVO 2624调用VNF LCM操作。Vi-Vnfm参考点连接VIM 2612和VNFM(MEC平台LCM)2620,并且主要由VNFM2620用来调用资源管理操作,以管理VNF所需的云资源(假定在基于NFV的MEC部署中该参考点与Mm6 1:1对应)。Or-Vi参考点连接NFVO 2624和VIM 2612,并且主要由NFVO 2624用来管理云资源容量。Ve-Vnfm-em参考点将VNFM(MEC平台LCM)2620与MEPM-V 2614进行连接。Ve-Vnfm-vnf参考点将VNFM(MEC平台LCM)2620与MEC平台VNF 2602进行连接。
III.C.硬件组件
图27A图示出将边缘平台2710的各个架构方面(例如,计算硬件、网络功能、功率管理功能等)映射到特定边缘平台能力2720(例如,I/O池、加速池、存储器池、加速技术、存储能力)的第一边缘计算硬件配置。为了提供边缘配置作为服务的整体解决方案,那么就要根据可用的架构方面(例如,池化、存储等)来考虑服务的工作负荷或基本硬件组件以及服务要求/约束(例如,网络和I/O、平台加速、功率)。
在边缘平台能力2720内,可配置或标识特定的加速类型,以便确保服务密度跨边缘云被满足。具体而言,四种主要加速类型可以被部署在边缘云配置中:(1)用于实现基本块(诸如快速傅里叶变换(FFT)、k-最近邻算法(KNN)和机器学习工作负荷)的通用加速(例如,FPGA);(2)图像、视频和转码加速器;(3)推断加速器;(4)(诸如在
Figure BDA0003546022750000801
快速帮助(QuickAssistTM)技术中实现的)加密和压缩相关的工作负荷。因此,边缘平台能力2720的特定设计或配置可以考虑需要选择哪种正确的加速类型和平台产品模型,以便适应服务和吞吐量密度以及可用功率。
图27B图示出提供具有第二组边缘平台能力2740的第二种边缘平台2730的第二边缘计算硬件配置。该配置可以作为低功率但更多服务密集的解决方案进行部署。该方法的目标是定义一种较低功率的解决方案,该解决方案使用加速方案以便实现更好的每瓦特服务密度或服务吞吐量。该主要的设计权衡导致了使用的平台牺牲了一般的计算,以利于专用硬件(例如,FPGA、推断加速器),这些硬件可以以更好的每瓦性能比执行同样的工作。在该示例中,“服务密集的”解决方案实现每平台和每瓦特更多的服务动作,或者能够在每瓦特的服务级别上驱动更多的吞吐量。
平台能力2740可以被设计成在功率包络以及物理空间方面是有利的。作为结果,图27B的配置可以为基站部署提供合适的目标。然而,平台能力2740可能具有权衡,包括:(1)在编排、维护和系统管理方面的要求(其可以转换成OPEX/TCO成本);(2)要求运营商生态系统使所有系统堆栈能够与暴露的不同加速器一起工作。然而,利用经开发的软件抽象层可以减轻这些缺点。
图27C图示出提供具有第二组边缘平台能力2760的第三种边缘平台2750的第三边缘计算硬件配置。该配置提供了高功率但同构的且通用的架构。图27C提供了与图27B相比相反的方法,以提供在运营商或边缘所有者必须处理的、关于管理、维护和编排的不同类型的资源中具有减少的异构性的平台架构。然而,移除加速器以利于同质性是以在平台级别上具有较低的每瓦特服务密度和服务吞吐量为代价的。在进一步的示例中,边缘平台能力2760可以(诸如以FPGA的形式)实现通用加速。
图27A-图27C中描绘的边缘平台的其他衍生功能也可以被适配。例如,可以调整平台的尺寸和设计平台,以便并入使平台具有更多的服务和吞吐量密度的新的组成部分,但通过例如在平台内部或在管芯上包括加速器以便使它们可以由运营商无缝地进行管理来使平台更加同构。
图28和图29描绘了可实现本文中所讨论的计算节点或设备中的任一者的边缘计算系统和环境的进一步的示例。相应的边缘计算节点可以被具体化为能够与其他边缘组件、联网组件或端点组件进行通信的设备、装置、计算机或其他“物”的类型。例如,边缘计算设备可以被具体化为智能电话、移动计算设备、智能装置、机载计算系统(例如,导航系统)、或能够执行所描述的功能的其他设备或系统。
在图28中,边缘计算节点2800包括计算引擎(本文中也称为“计算电路系统”)2802、输入/输出(I/O)子系统2808、数据存储2810、通信电路系统子系统2812,以及任选地,一个或多个外围设备2814。在其他示例中,相应的计算设备可以包括其他或附加组件,诸如通常在计算机中发现的那些组件(例如,显示器、外围设备等)。附加地,在一些示例中,说明性组件中的一个或多个可被并入到另一组件中,或以其他方式形成另一组件的部分。
计算节点2800可被具体化为能够执行各种计算功能的任何类型的引擎、设备、或设备集合。在一些示例中,计算节点2800可被具体化为单个设备,诸如集成电路、嵌入式系统、FPGA、芯片上系统(SOC)或者其他集成系统或设备。计算节点2800包括或被具体化为处理器2804和存储器2806。处理器2804可被具体化为能够执行本文中所描述的功能(例如,执行应用)的任何类型的处理器。例如,处理器2804可被具体化为(多个)多核处理器、微控制器、或其他处理器或处理/控制电路。在一些示例中,处理器2804可被具体化为、包括或耦合至FPGA、专用集成电路(ASIC)、可重新配置的硬件或硬件电路系统、或用于促进本文中所描述的功能的执行的其他专用硬件。
主存储器2806可被具体化为能够执行本文中所描述的功能的任何类型的易失性(例如,动态随机存取存储器(DRAM)等)或非易失性存储器或数据存储。易失性存储器可以是需要功率来维持由该介质存储的数据的状态的存储介质。易失性存储器的非限制性示例可包括各种类型的随机存取存储器(RAM),诸如DRAM或静态随机存取存储器(SRAM)。可以在存储器模块中使用的一种特定类型的DRAM是同步动态随机存取存储器(SDRAM)。
在一个示例中,存储器设备是块可寻址存储器设备,诸如基于NAND或NOR技术的那些存储器设备。存储器设备还可包括三维交叉点存储器设备(例如,
Figure BDA0003546022750000821
3D XPointTM存储器)或其他字节可寻址的原位写入非易失性存储器设备。存储器设备可指代管芯本身和/或指代封装的存储器产品。在一些示例中,3D交叉点存储器(例如,
Figure BDA0003546022750000822
3D XPointTM存储器)可包括无晶体管的可堆叠的交叉点架构,其中存储单元位于字线和位线的交点处,并且可单独寻址,并且其中位存储基于体电阻的变化。在一些示例中,主存储器2806的全部或部分可被集成到处理器2804中。主存储器2806可存储在操作期间使用的各种软件和数据,诸如一个或多个应用、通过(多个)应用、库以及驱动程序操作的数据。
计算电路系统2802经由I/O子系统2808通信地耦合到计算节点2800的其他组件,该I/O子系统2808可被具体化为用于促进与计算电路系统2802(例如,与处理器2804和/或主存储器2806)以及计算电路系统2802的其他组件的输入/输出操作的电路系统和/或组件。例如,I/O子系统2808可被具体化为或以其他方式包括存储器控制器中枢、输入/输出控制中枢、集成传感器中枢、固件设备、通信链路(即,点对点链路、总线链路、线路、电缆、光导、印刷电路板迹线等)和/或用于促进输入/输出操作的其他组件和子系统。在一些示例中,I/O子系统2808可以形成片上系统(SoC)的部分,并可与计算电路系统2802的处理器2804、主存储器2806、和其他组件中的一个或多个一起被合并到计算电路系统2802中。
一个或多个说明性数据存储设备2810可被具体化为被配置成用于数据的短期或长期存储的任何类型的设备,诸如例如,存储器设备和电路、存储器卡、硬盘驱动器、固态驱动器或其他数据存储设备。各个数据存储设备2810可包括存储用于数据存储设备2810的数据以及固件代码的系统分区。各个数据存储设备2810还可包括根据例如计算节点2800的类型来存储用于操作系统的数据文件和可执行文件的一个或多个操作系统分区。
通信电路系统2812可被具体化为能够通过网络实现在计算电路系统2802与另一计算设备(例如,边缘网关节点等)之间进行的通信的任何通信电路、设备或其集合。通信电路系统2812可以被配置成使用任何一种或多种通信技术(例如,有线或无线通信)和相关联的协议(例如,蜂窝联网协议(诸如3GPP 4G或5G标准)、无线局域网协议(诸如IEEE
Figure BDA0003546022750000831
)、无线广域网协议,以太网、
Figure BDA0003546022750000832
蓝牙低能量、IoT协议(诸如IEEE802.15.4或
Figure BDA0003546022750000833
)、低功率广域网(LPWAN)或低功率广域网(LPWA)协议等)来实行此类通信。
说明性通信电路系统2812包括网络接口控制器(NIC)2820,其也可被称为主机结构接口(HFI)。NIC 2820可被具体化为一个或多个插入式板、子卡、网络接口卡、控制器芯片、芯片组或可由计算节点2800用来与另一计算设备连接的其他设备。在一些示例中,NIC2820可被具体化为包括一个或多个处理器的芯片上系统(SoC)的部分,或NIC 2820可被包括在也包含一个或多个处理器的多芯片封装上。在一些示例中,NIC 2820可包括本地处理器(未示出)和/或本地存储器(未示出),这两者均位于NIC 2820本地。在此类示例中,NIC2820的本地处理器可以能够执行本文中描述的计算电路系统2802的功能中的一个或多个功能。附加地或替代地,在此类示例中,NIC 2820的本地存储器可以在板级、插座级、芯片级和/或其他层级上被集成到客户端计算节点的一个或多个组件中。
附加地,在一些示例中,相应的计算节点2800可以包括一个或多个外围设备2814。取决于计算节点2800的特定类型,此类外围设备2814可包括在计算设备或服务器中发现的任何类型的外围设备,诸如音频输入设备、显示器、其他输入/输出设备、接口设备和/或其他外围设备。在进一步的示例中,计算节点2800可以由边缘计算系统中的相应边缘计算节点(例如,客户端计算节点、边缘网关节点、边缘聚合节点、先前讨论的V-ITS-S等)或类似形式的装置、计算机、子系统、电路系统、或其他组件来具体化。
图29图示出可存在于边缘计算节点2950中的、用于实现本文中所描述的技术(例如,操作、过程、方法和方法论)的组件的示例。该边缘计算节点2950在被实现为计算设备(例如,移动设备、基站、服务器、网关等)或计算设备(例如,移动设备、基站、服务器、网关等)的一部分时提供节点2900的相应组件的更靠近的视图。边缘计算节点2950可包括本文中所引用的硬件或逻辑组件的任何组合,并且该边缘计算节点2950可包括可与边缘通信网络或此类网络的组合一起使用的任何设备或与该任何设备耦合。这些组件可被实现为IC、IC的部分、分立电子器件或其他模块、指令集、可编程逻辑或算法、硬件、硬件加速器、软件、固件、或其在边缘计算节点2950中适配的组合,或者被实现为以其他方式被并入在更大的系统的机架内的组件。
边缘计算节点2950包括以一个或多个处理器2852形式的处理电路系统。处理器电路系统2952包括电路系统,诸如但不限于一个或多个处理器核以及以下各项中的一项或多项:高速缓存存储器、低压差电压调节器(LDO)、中断控制器、串行接口(诸如SPI、I2C或通用可编程串行接口电路)、实时时钟(RTC)、定时器-计数器(包括间隔定时器和看门狗定时器)、通用I/O、存储器卡控制器(诸如安全数字/多媒体卡(SD/MMC)或类似物)、接口、移动产业处理器接口(MIPI)接口、以及联合测试接入小组(JTAG)测试接入端口。在一些实现方式中,处理器电路系统2952可包括一个或多个硬件加速器(例如,与加速电路系统2964相同或类似),该硬件加速器可以是微处理器、可编程处理设备(例如,FPGA、ASIC)等等。一个或多个加速器可包括例如计算机视觉和/或深度学习加速器。在一些实现方式中,处理器电路系统2952可包括片上存储器电路系统,该片上存储器电路系统可包括任何合适的易失性和/或非易失性存储器,诸如DRAM、SRAM、EPROM、EEPROM、闪存存储器、固态存储器、和/或诸如本文中所讨论的那些存储器设备技术之类的任何其他类型的存储器设备技术。
处理器电路系统2952可以包括,例如一个或多个处理器核(CPU)、应用处理器、GPU、RISC处理器、Acorn RISC机器(ARM)处理器、CISC处理器、一个或多个DSP、一个或多个FPGA、一个或多个PLD、一个或多个ASIC、一个或多个基带处理器、一个或多个射频集成电路(RFIC)、一个或多个微处理器或控制器、多核处理器、多线程处理器、超低压处理器、嵌入式处理器、或任何其他已知的处理元件、或其任何合适的组合。处理器(或核)2952可与存储器/存储耦合或者可包括存储器/存储,并且可被配置成用于执行存储器/存储中所存储的指令以使得各种应用或操作系统能够在平台2950上运行。处理器(或核)2952被配置成用于操作应用软件以向平台2950的用户提供特定服务。在一些实施例中,(多个)处理器2952可以是(可)配置成用于根据本文中的各实施例进行操作的(多个)专用处理器/控制器。
作为示例,(多个)处理器2952可包括可从加利福尼亚州圣克拉拉市的
Figure BDA0003546022750000851
公司获得的基于
Figure BDA0003546022750000852
架构酷睿TM(CoreTM)的处理器,诸如基于i3、i5、i7和i9的处理器;基于
Figure BDA0003546022750000853
微控制器的处理器,诸如夸克TM(QuarkTM)、凌动TM(AtomTM)、或其他基于MCU的处理器;(多个)
Figure BDA0003546022750000854
处理器、(多个)
Figure BDA0003546022750000855
处理器、或另一此类处理器。然而,可使用任何数量的其他处理器,诸如以下各项中的一项或多项:超微半导体公司(AMD)
Figure BDA0003546022750000856
架构,诸如(多个)
Figure BDA0003546022750000857
Figure BDA0003546022750000858
处理器、加速处理单元(APU)、MxGPU、(多个)
Figure BDA0003546022750000859
处理器等等;来自
Figure BDA00035460227500008510
公司的(多个)A5-A12和/或S1-S4处理器,来自
Figure BDA00035460227500008511
技术公司的(多个)骁龙TM(SnapdragonTM)或CentriqTM处理器,
Figure BDA00035460227500008512
的(多个)开放多媒体应用平台(OMAP)TM处理器;来自MIPS技术公司的基于MIPS的设计,诸如MIPS勇士M类(Warrior M-class)、勇士I类(Warrior I-class)和勇士P类(P-class)处理器;许可自ARM控股有限公司的基于ARM的设计,诸如ARM Cortex-A、Cortex-R和Cortex-M族处理器;由CaviumTM公司提供的
Figure BDA00035460227500008513
等等。在一些实现方式中,(多个)处理器2952可以是片上系统(SoC)、封装中系统(SiP)、多芯片封装等等的部分,其中(多个)处理器2952和其他组件被形成到单个集成电路或单个封装中,诸如来自
Figure BDA00035460227500008514
公司的爱迪生M(EdisonM)或伽利略M(GalileoM)SoC板。(多个)处理器2952的其他示例在本公开中的其他地方被提及。
(多个)处理器2952可通过互连(IX)2956与系统存储器2954通信。可使用任何数量的存储器设备来提供给定量的系统存储器。作为示例,存储器可以是根据联合电子器件工程委员会(JEDEC)设计的随机存取存储器(RAM),诸如DDR或移动DDR标准(例如,LPDDR、LPDDR2、LPDDR3或LPDDR4)。在特定示例中,存储器组件可符合JEDEC颁布的DRAM标准,诸如DDR SDRAM的JESD79F、DDR2 SDRAM的JESD79-2F、DDR3 SDRAM的JESD79-3F、DDR4 SDRAM的JESD79-4A、低功率DDR(LPDDR)的JESD209、LPDDR2的JESD209-2、LPDDR3的JESD209-3和LPDDR4的JESD209-4。还可包括其他类型的RAM,诸如动态RAM(DRAM)、同时DRAM(SDRAM)等等。此类标准(和类似的标准)可被称为基于DDR的标准,而存储设备的实现此类标准的通信接口可被称为基于DDR的接口。在各种实现方式中,单独的存储器设备可以是任何数量的不同封装类型,诸如单管芯封装(SDP)、双管芯封装(DDP)或四管芯封装(Q17P)。在一些示例中,这些设备可以直接焊接到主板上,以提供薄型解决方案,而在其他示例中,设备被配置为一个或多个存储器模块,这一个或多个存储器模块进而通过给定的连接器耦合至主板。可使用任何数量的其他存储器实现方式,诸如其他类型的存储器模块,例如,不同种类的双列直插存储器模块(DIMM),包括但不限于microDIMM(微DIMM)或MiniDIMM(迷你DIMM)。
为了提供对信息(诸如数据、应用、操作系统等)的持久性存储,存储2958还可经由IX 2956而耦合至处理器2952。在示例中,存储2958可经由固态盘驱动器(SSDD)和/或高速电可擦除存储器(共同被称为“闪存”)来实现。可用于存储2958的其他设备包括闪存卡(诸如SD卡、microSD卡、XD图片卡,等等)和USB闪存驱动器。在示例中,存储器设备可以是或者可以包括使用硫属化物玻璃的存储器设备,多阈值级别NAND闪存,NOR闪存,单级或多级相变存储器(PCM),电阻式存储器,纳米线存储器,铁电晶体管随机存取存储器(FeTRAM),反铁电存储器,包含忆阻器技术的磁阻随机存取存储器(MRAM),相变RAM(PRAM),包括金属氧化物基底、氧空位基底和导电桥随机存取存储器(CB-RAM)的电阻式存储器,或自旋转移力矩(STT)-MRAM,基于自旋电子磁结存储器的设备,基于磁隧穿结(MTJ)的设备,基于畴壁(DW)和自旋轨道转移(SOT)的设备、基于晶闸管的存储器设备、或者任何上述的组合或其他存储器。存储器电路系统2954和/或存储电路系统2958还可包含
Figure BDA0003546022750000861
Figure BDA0003546022750000862
的三维(3D)交叉点(XPOINT)存储器。
在低功率实现方式中,存储2958可以是与处理器2952相关联的管芯上存储器或寄存器。然而,在一些示例中,存储2858可使用微硬盘驱动器(HDD)来实现。此外,附加于或替代所描述的技术,可将任何数量的新技术用于存储2958,诸如阻变存储器、相变存储器、全息存储器或化学存储器,等等。
边缘计算设备2950的组件可通过IX 2956进行通信。IX 2956可包括任何数量的技术,包括ISA、扩展ISA、I2C、SPI、点对点接口、功率管理总线(PMBus)、PCI、PCIe、PCIx、
Figure BDA0003546022750000871
UPI、
Figure BDA0003546022750000872
加速器链路、
Figure BDA0003546022750000873
Figure BDA0003546022750000874
CXL、CAPI、OpenCAPI、
Figure BDA0003546022750000875
QPI、UPI、
Figure BDA0003546022750000876
OPA IX、RapidIOM系统IX、CCIX、Gen-Z联合体IX、超传输互连、
Figure BDA0003546022750000877
提供的NVLink、时间触发协议(TTP)系统、FlexRay系统、PROFIBUS和/或任何数量的其他IX技术。IX2956可以是例如在基于SoC的系统中使用的专属总线。
IX 2956将处理器2952耦合至通信电路系统2966以用于与其他设备的通信,该其他设备诸如远程服务器(未示出)和/或连接的边缘设备2962。通信电路系统2966是硬件元件或硬件元件的集合,用于通过一个或多个网络(例如,云2963)通信和/或与其他设备(例如,边缘设备2962)通信。
收发器2966可使用任何数量的频率和协议,诸如IEEE 802.15.4标准下的2.4千兆赫兹(GHz)传输,使用如由
Figure BDA0003546022750000878
特别兴趣小组定义的
Figure BDA0003546022750000879
低能量(BLE)标准、或
Figure BDA00035460227500008710
标准,等等。为特定的无线通信协议配置的任何数量的无线电可用于到连接的边缘设备2962的连接。例如,无线局域网(WLAN)单元可用于根据电气和电子工程师协会(IEEE)802.11标准实现
Figure BDA00035460227500008711
通信。另外,例如根据蜂窝或其他无线广域协议的无线广域通信可经由无线广域网(WWAN)单元发生。
无线网络收发机2966(或多个收发机)可以使用用于不同范围的通信的多种标准或无线电来进行通信。例如,边缘计算节点2950可使用基于BLE或另一低功率无线电的本地收发机与接近的(例如,在约10米内的)设备通信以节省功率。更远的(例如,在约50米内的)连接的边缘设备2962可通过
Figure BDA00035460227500008712
或其他中间功率的无线电而联络到。这两种通信技术能以不同的功率水平通过单个无线电发生,或者可通过分开的收发机而发生,分开的收发机例如使用BLE的本地收发机和分开的使用
Figure BDA0003546022750000881
的网格收发机。
可包括无线网络收发机2966(例如,无线电收发机),以经由局域网协议或广域网协议来与边缘云2963中的设备或服务通信。无线网络收发机2966可以是遵循IEEE802.15.4或IEEE 802.15.4g标准等的LPWA收发机。边缘计算节点2963可使用由Semtech和LoRa联盟开发的LoRaWANM(长距离广域网)在广域上通信。本文中所描述的技术不限于这些技术,而是可与实现长距离、低带宽通信(诸如Sigfox和其他技术)的任何数量的其他云收发机一起使用。进一步地,可使用其他通信技术,诸如在IEEE 802.15.4e规范中描述的时分信道跳。
除了针对如本文中所描述的无线网络收发机2966而提及的系统之外,还可使用任何数量的其他无线电通信和协议。例如,收发机2966可包括使用扩展频谱(SPA/SAS)通信以实现高速通信的蜂窝收发机。进一步地,可使用任何数量的其他协议,诸如用于中速通信和供应网络通信的
Figure BDA0003546022750000882
网络。收发机2966可包括与任何数量的3GPP规范兼容的无线电,诸如LTE和5G/NR通信系统,在本公开的末尾处更详细地进行讨论。网络接口控制器(NIC)2968可被包括以提供到边缘云2963的节点或到其他设备(诸如(例如,在网格中操作的)连接的边缘设备2962)的有线通信。有线通信可提供以太网连接,或可基于其他类型的网络,诸如控制器区域网(CAN)、本地互连网(LIN)、设备网络(DeviceNet)、控制网络(ControlNet)、数据高速路+、或PROFINET,等等。附加的NIC 2968可被包括以启用到第二网络的连接,例如,第一NIC2968通过以太网提供到云的通信,并且第二NIC 2968通过另一类型的网络提供到其他设备的通信。
鉴于从设备到另一组件或网络的可适用通信类型的多样性,由设备使用的可适用通信电路系统可以包括组件2964、2966、2968或2970中的任何一个或多个,或由组件2964、2966、2968或2970中的任何一个或多个来具体化。因此,在各示例中,用于通信(例如,接收、传送等)的可适用装置可由此类通信电路系统来具体化。
边缘计算节点2950可以包括或被耦合到加速电路系统2964,该加速电路系统2764可以由一个或多个AI加速器、神经计算棒、神经形态硬件、FPGA、GPU的布置、一个或多个SoC(包括可编程SoC)、一个或多个CPU、一个或多个数字信号处理器、专用ASIC(包括可编程ASIC)、诸如CPLD或HCPLD之类的PLD和/或被设计用于完成一个或多个专业化任务的其他形式的专用处理器或电路系统来具体化。这些任务可以包括AI处理(包括机器学习、训练、推断、和分类操作)、视觉数据处理、网络数据处理、对象检测、规则分析等。在基于FPGA的实现方式中,加速电路系统2964可包括逻辑块或逻辑结构以及其他互连的资源,这些逻辑块或逻辑结构以及其他互连的资源可被编程(被配置)为用于执行本文中所讨论的各实施例的各种功能,诸如过程、方法、功能等。在此类实现方式中,加速电路系统2964还可包括用于将逻辑块、逻辑结构、数据等存储在LUT等等中的存储器单元(例如,EPROM、EEPROM、闪存、静态存储器(例如,SRAM、反熔丝等))。
IX 2956还将处理器2952耦合至用于连接附加的设备或子系统的传感器中枢或外部接口2970。附加/外部设备可包括传感器2972、致动器2974、以及定位电路系统2945。
传感器电路系统2972包括其目的是为检测其环境中的事件或其环境的改变并将关于检测到的事件的信息(传感器数据)发送到其他设备、模块、子系统等的设备、模块或子系统。此类传感器2972的示例尤其包括:惯性测量单元(IMU),包括加速度计、陀螺仪、和/或磁力计;微机电系统(MEMS)或纳机电系统(NEMS),包括3轴加速度计、3轴陀螺仪和/或磁力计;液位传感器;通信量传感器;温度传感器(例如,热敏电阻);压力传感器;气压传感器;重力仪;高度计;图像捕捉设备(例如,相机);光检测和测距(LiDAR)传感器;接近度传感器(例如,红外辐射检测器等等)、深度传感器、环境光传感器,超声波收发器;话筒;等等。
致动器2974允许平台2950改变其状态、位置和/或取向,或者移动或控制机制或系统。致动器2974包括用于移动或控制机制或系统的电设备和/或机械设备,并且将能量(例如,电流或移动的空气和/或液体)转换为某个种类的运动。致动器2974可包括一个或多个电子(或电化学)设备,诸如压电生物形态、固态致动器、固态继电器(SSR)、基于形状记忆合金的致动器、基于电活性聚合物的致动器、继电器驱动器集成电路(IC),等等。致动器2974可包括一个或多个机电设备,诸如气动致动器、液压致动器、机电开关(包括机电继电器(EMR))、电动机(例如,DC电动机、步进电动机、伺服机构等)、功率开关、阀致动器、轮、推进器、螺旋桨、爪、夹具、挂钩、可听语音生成器、视觉警示设备、和/或其他类似的机电组件。平台2950可被配置成用于基于一个或多个所捕获的事件和/或从服务提供商和/或各种客户端系统接收到的指令或控制信号来操作一个或多个致动器2974。
定位电路系统2945包括用于接收由全球导航卫星系统(GNSS)的定位网络传送/广播的信号并对其进行解码。导航卫星星座(或GNSS)的示例包括美国的全球定位系统(GPS)、俄罗斯的全球导航系统(GLONASS)、欧盟的伽利略系统、中国的北斗导航卫星系统、区域导航系统或GNSS增强系统(例如,利用印度星座(NAVIC)、日本的准天顶卫星系统(QZSS)、法国的多普勒轨道成像和卫星综合无线电定位(DORIS)等进行的导航)等等。定位电路系统2945包括用于与定位网络(诸如导航卫星星座节点)的组件通信的各种硬件元件(例如,包括诸如交换机、滤波器、放大器、天线元件等等之类的用于促进OTA通信的硬件设备)。在一些实施例中,定位电路系统2945可包括用于定位、导航和定时的微技术(Micro-PNT)IC,其使用主定时时钟来执行位置跟踪/估计而无需GNSS辅助。定位电路系统2945也可以是通信电路系统2966的部分或者与通信电路系统2966交互以与定位网络的节点和组件通信。定位电路系统2945还可向应用电路系统提供位置数据和/或时间数据,该应用电路系统可使用该数据使操作与各种基础设施装备(例如,无线电基站)同步以用于逐向道路导航等等。当GNSS信号不可用或当GNSS定位精度对于特定应用或服务不足够时,可使用定位增强技术来向应用或服务提供增强的定位信息和数据。此类定位增强技术可以包括例如基于卫星的定位增强(例如,EGNOS)和/或基于地面的定位增强(例如,DGPS)。在一些实现方式中,定位电路系统2945是或包括INS,其是使用传感器电路系统2972(例如,诸如加速度计之类的运动传感器、诸如陀螺仪之类的旋转传感器、以及高度计、磁传感器和/或类似物)来连续计算(例如,使用航位推算、三角测量等)平台2950的定位、定向和/或速度(包括移动的方向和速度)而无需外部参考的系统或设备。
在一些任选示例中,各种输入/输出(I/O)设备可存在于边缘计算节点2950内或连接至边缘计算节点2950,I/O设备是指图29中的输入电路系统2986和输出电路系统2984。输入电路系统2986和输出电路系统2984包括被设计成用于实现用户与平台2950的交互的一个或多个用户接口和/或被设计成用于实现外围组件与平台2950的交互的外围组件接口。输入电路系统2986可包括用于接受输入的任何实体或虚拟装置,输入电路系统2986尤其包括一个或多个实体或虚拟按钮(例如,重置按钮)、物理键盘、小键盘、鼠标、触摸板、触摸屏、话筒、扫描仪、头戴式耳机,等等。可包括输出电路系统2984,以示出信息或以其他方式传达信息,诸如传感器读数、(多个)致动器位置、或其他类似信息。可将数据和/或图形显示在输出电路系统2984的一个或多个用户接口组件上。输出电路系统2984可包括任何数量的音频或视觉显示器和/或音频或视觉显示器的任何组合,尤其包括具有从平台2950的操作生成或产生的字符、图形、多媒体对象等的输出的一个或多个简单的视觉输出/指示器(例如,二进制状态指示器(例如,发光二极管(LED))和多字符视觉输出/或更复杂的输出,诸如显示设备或触摸屏(例如,液晶显示器(LCD)、LED显示器、量子点显示器、投影仪等)。输出电路系统2984还可包括扬声器或其他发声设备、(多个)打印机等等。在一些实施例中,传感器电路系统292872可被用作输入电路系统2984(例如,图像捕捉设备、运动捕捉设备等等),并且一个或多个致动器2974可被用作输出电路系统2984(例如,用于提供触觉反馈等的致动器)。在另一示例中,近场通信(NFC)电路系统可被包括以读取电子标签和/或与另一启用NFC的设备通信,该NFC电路系统包括与天线元件耦合的NFC控制器并且包括处理设备。外围组件接口可包括但不限于非易失性存储器端口、USB端口、音频插孔、电源接口等。在本系统的上下文中,显示器或控制台硬件可用于:提供边缘计算系统的输出并接收边缘计算系统的输入;管理边缘计算系统的组件或服务;标识边缘计算组件或服务的状态;或进行任何其他数量的管理或管理功能或服务用例。
电池2976可为边缘计算节点2950供电,但是在其中边缘计算节点2950被安装在固定位置的示例中,该边缘计算节点2950可具有耦合至电网的电源,或者电池可以用作备用或用于临时功能。电池2976可以是锂离子电池、金属-空气电池(诸如锌-空气电池、铝-空气电池、锂-空气电池),等等。
电池监测器/充电器2978可被包括在边缘计算节点2950中以跟踪电池2976(如果包括的话)的充电状态(SoCh)。电池监测器/充电器2978可用于监测电池2976的其他参数以提供失效预测,诸如电池2976的健康状态(SoH)和功能状态(SoF)。电池监测器/充电器2978可包括电池监测集成电路,诸如来自线性技术公司(Linear Technologies)的LTC4020或LTC2990、来自亚利桑那州的凤凰城的安森美半导体公司(ON Semiconductor)的ADT7488A、或来自德克萨斯州达拉斯的德州仪器公司的UCD90xxx族的IC。电池监测器/充电器2978可通过IX 2956将关于电池2976的信息传输至处理器2952。电池监测器/充电器2978也可包括使处理器2952能够直接监视电池2976的电压或来自电池2976的电流的模数(ADC)转换器。电池参数可被用于确定边缘计算节点2950可执行的动作,诸如传输频率、网格网络操作、感测频率,等等。
功率块2980或耦合至电网的其他电源可与电池监测器/充电器2978耦合以对电池2976充电。在一些示例中,功率块2980可用无线功率接收机代替,以便例如通过边缘计算节点2950中的环形天线来无线地获得功率。无线电池充电电路(诸如来自加利福尼亚州的苗比达市的线性技术公司的LTC4020芯片,等等)可被包括在电池监测器/充电器2978中。可以基于电池2976的尺寸并且因此基于所要求的电流来选择特定的充电电路。可使用由无线充电联盟(Airfuel Alliance)颁布的Airfuel标准、由无线电力协会(Wireless PowerConsortium)颁布的Qi无线充电标准、或由无线电力联盟(Alliance for Wireless Power)颁布的Rezence充电标准等等来执行充电。
存储2958可包括用于实现本文中公开的技术的软件、固件或硬件命令形式的指令2982。虽然此类指令2982被示出为被包括在存储器2954和存储2958中的代码块,但是可以理解,可用例如被建立到专用集成电路(ASIC)中的硬连线电路来代替代码块中的任一个。
在示例中,经由存储器2954、存储2958或处理器2958提供的指令2882可被具体化为非暂态机器可读介质2960,该非暂态机器可读介质2960包括用于引导处理器2952执行边缘计算节点2950中的电子操作的代码。处理器2952可通过IX 2956来访问非暂态机器可读介质2960。例如,非暂态机器可读介质2960可由针对存储2958所描述的设备来具体化,或者可包括特定的存储单元,诸如光盘、闪存驱动器或任何数量的其他硬件设备。非暂态机器可读介质2960可包括用于指示处理器2952执行例如像参照上文中描绘的操作和功能的(多个)流程图和(多个)框图而描述的特定的动作序列或动作流的指令。如本文中所使用,术语“机器可读介质”和“计算机可读介质”是可互换的。
在进一步的示例中,机器可读介质也包括任何有形介质,该有形介质能够存储、编码或携载供由机器执行并且使机器执行本公开方法中的任何一种或多种方法的指令,或者该有形介质能够储存、编码或携载由此类指令利用或与此类指令相关联的数据结构。“机器可读介质”因此可包括但不限于固态存储器、光学介质和磁介质。机器可读介质的特定示例包括非易失性存储器,作为示例,包括但不限于:半导体存储器设备(例如,电可编程只读存储器(EPROM)、电可擦除可编程只读存储器(EEPROM)和闪存存储器设备);诸如内部硬盘及可移除盘之类的磁盘;磁光盘;以及CD-ROM和DVD-ROM盘。可使用传输介质,经由网络接口设备,利用多种传输协议中的任何一种协议(例如,HTTP),进一步通过通信网络来传送或接收由机器可读介质具体化的指令。
机器可读介质可以由能够以非瞬态格式主控数据的存储设备或其他装置提供。在示例中,存储在机器可读介质上或以其他方式提供在机器可读介质上的信息可以表示指令,诸如指令本身或者可以从中导出指令的格式。可以从中导出指令的该格式可以包括源代码、经编码的指令(例如,以压缩或加密的形式)、经封装的指令(例如,分成多个封装)等。表示机器可读介质中的指令的信息可以由处理电路系统处理成指令以实现本文所讨论的任何操作。例如,从信息中导出指令(例如,由处理电路进行的处理)可以包括:(例如,从源代码、目标代码等)编译、解释、加载、组织(例如,动态地或静态地进行链接)、编码、解码、加密、解密、打包、拆包,或者以其他方式将信息操纵到指令中。
在示例中,指令的推导可以包括(例如,通过处理电路系统)对信息进行汇编、编译、或解释,以从机器可读介质提供的某个中间或预处理的格式创建指令。当信息以多个部分提供时,可以对其进行组合、拆包和修改以创建指令。例如,信息可以处于一个或若干远程服务器上的多个经压缩的源代码封装(或目标代码、或二进制可执行代码等)中。源代码封装可以在通过网络传输时被加密,并且可以在本地机器处被解密、被解压缩、(如果必要的话)被汇编(例如,被链接),并且被编译或被解释(例如被编译或被解释成库、独立的可执行文件等),并且由本地机器执行。
图30描绘了示例移动设备2832内的通信组件。该移动设备2832在被实现为用户装备或用户装备的组件时,提供节点2800或设备2850的通信处理组件的更靠近的视图。移动设备2832可以包括无线电前端模块(FEM)电路2834、无线电IC电路2836和基带处理电路2838。如图所示的移动设备2832包括无线局域网(WLAN)功能和蓝牙(BT)功能,尽管设备的各方面并不限于此,并且本文中讨论的其他无线电技术可以通过类似的电路来实现。FEM电路2834可以包括例如WLAN或Wi-Fi FEM电路2834A和蓝牙(BT)FEM电路2834B。WLAN FEM电路2834A可以包括接收信号路径,包括被配置成对从一个或多个天线2831A接收到的WLAN RF信号进行操作、放大所接收的信号并将所接收信号的放大版本提供给WLAN无线电IC电路2836A以供进一步处理的电路。BT FEM电路2834B可以包括接收信号路径,该接收信号路径可以包括被配置成对从一个或多个天线2831B接收到的BT RF信号进行操作、放大所接收的信号并将所接收信号的放大版本提供给BT无线电IC电路2836B以供进一步处理的电路。FEM电路2834A还可以包括发射信号路径,该发射信号路径可以包括被配置成放大由无线电IC电路2836A提供的WLAN信号、以供天线2831A中的一个或多个天线进行无线传输的电路。另外,FEM电路2834B还可以包括发射信号路径,该发射信号路径可以包括被配置成放大由无线电IC电路2836B提供的BT信号、以供天线2831B中的一个或多个天线进行无线传输的电路。在图30的示例中,虽然FEM 2834A和FEM 2834B被示出为彼此不同,但本公开的各个方面并不限于此,并且在其范围内包括:使用包括WLAN和BT信号两者的发射路径和/或接收路径的FEM(未示出),或者使用其中FEM电路中的至少一些FEM电路共享WLAN和BT信号两者的发射和/或接收信号路径的一个或多个FEM电路。
如所示的无线电IC电路2836可包括WLAN无线电IC电路2836A和BT无线电IC电路2836B。WLAN无线电IC电路2836A可包括接收信号路径,该接收信号路径可包括用于将从FEM电路2834A接收到的WLAN RF信号进行下变频并将基带信号提供给WLAN基带处理电路2838A的电路。BT无线电IC电路2836B进而可包括接收信号路径,该接收信号路径可包括用于将从FEM电路2834B接收到的BT RF信号进行下变频并将基带信号提供给BT基带处理电路2838B的电路。WLAN无线电IC电路2836A还可以包括发射信号路径,该发射信号路径可以包括用于将由WLAN基带处理电路2838A提供的WLAN基带信号进行上变频,并将WLAN RF输出信号提供给FEM电路2834A,以供一个或多个天线2831A进行后续的无线传输的电路。BT无线电IC电路2836B还可以包括发射信号路径,该发射信号路径可以包括用于将由BT基带处理电路2838B提供的BT基带信号进行上变频,并将BT RF输出信号提供给FEM电路2834B,以供一个或多个天线2831B进行后续的无线传输的电路。在图30的示例中,虽然无线电IC电路2836A和2836B被示出为彼此不同,但本公开的各个方面并不限于此,并且在其范围内包括:使用包括WLAN和BT信号两者的发射信号路径和/或接收信号路径的无线电IC电路(未示出),或者使用其中无线电IC电路中的至少一些无线电IC电路共享WLAN和BT信号两者的发射和/或接收信号路径的一个或多个无线电IC电路。
基带处理电路2838可以包括WLAN基带处理电路2838A和BT基带处理电路2838B。WLAN基带处理电路2838A可以包括存储器,诸如例如,WLAN基带处理电路2838A的快速傅里叶变换或快速傅里叶逆变换块(未示出)中的一组RAM阵列。WLAN基带处理电路2838A和BT基带处理电路2838B中的每一者可以进一步包括用于以下操作的一个或多个处理器和控制逻辑:处理从无线电IC电路2836的相应WLAN或BT接收信号路径接收的信号,并且还为无线电IC电路2836的发射信号路径生成相应的WLAN或BT基带信号。基带处理电路2838A和2838B中的每一者可以进一步包括物理层(PHY)和介质访问控制层(MAC)电路,并且可以进一步与应用处理器2851(或者,在其他示例中,处理器电路2850)对接,以用于生成和处理基带信号并且用于控制无线电IC电路2836的操作。
仍参考图30,根据图示出的各方面,WLAN-BT共存电路2843可包括在WLAN基带电路2838A与BT基带电路2838B之间提供接口,以实现需要WLAN和BT共存的用例的逻辑。另外,可以在WLAN FEM电路2834A与BT FEM电路2834B之间提供开关2833,以允许根据应用需求在WLAN与BT无线电之间切换。另外,虽然天线2831A、2831B被描绘为分别连接到WLAN FEM电路2834A和BT FEM电路2834B,但本公开的各个方面在其范围内包括:在WLAN与BT FEM之间共享一个或多个天线,或者提供连接到FEM2834A或2834B中的每一者的多于一个的天线。
在本公开的一些方面,前端模块电路2834、无线电IC电路2836、和基带处理电路2838可以被设置在单个无线电卡上。在其他方面,一个或多个天线2831A、2831B、FEM电路2834和无线电IC电路2836可以被设置在单个无线电卡上。在本公开的一些其他方面中,无线电IC电路2836和基带处理电路2838可以被提供在单个芯片或集成电路(IC)上。
图31图示出机架规模设计(RSD)组件,该组件可被包括作为边缘平台架构中的服务器或其他分立的计算节点的一部分。该布置在被实现为(例如,服务器机架、服务器刀片等中的)服务器时提供了节点2800或设备2950的可配置处理组件的近景。该可配置的架构通过分解现场可编程门阵列(FPGA)、非易失性存储器快速(NVMe)和输入-输出(I/O)池化资源而不同于一些其他架构。FPGA和NVMe资源提供可用于任何类型的边缘服务(诸如视频或语音分析)的要素。I/O池化可用于提供灵活的NF(网络功能)。该架构根据特定VNF的预期数据速率或网络负载来启用缩放的网络接口。该架构还能够根据在给定节点处发生的网络处理的类型来启用将不同的网卡映射到计算节点的灵活性。
图示出的RSD架构包括交付点(POD)管理器3142。POD管理器3142负责管理POD(例如,一个或多个机架)内的资源——包括计算和分解的资源。POD管理器3142将接口披露给编排器,以便创建、管理、或破坏组成的节点。管理组成的节点包括放大或缩小连接到特定计算撬板3140的经池化的资源3148的量的特征。POD管理器3142通常在节点控制器上运行。POD管理器3142负责发现POD中的资源、配置和管理资源、以及组成逻辑服务器。在示例中,POD管理器3142是任选的分开的组件,并且将不被要求在机架中。然而,在示例中,为了“符合RSD”,机架是可由经认证的POD管理器管理的。
以下是POD管理器3142的一些示例属性。例如,机架可包括用于执行边缘服务和其他有关的系统软件栈(例如诸如,编排或其他系统服务)的计算橇板3140的集合。一种类型的计算橇板3140可以是经池化的资源橇板。该计算橇板3140可管理分解资源集合。此处,计算橇板2840可包括经池化的系统管理引擎软件(PSME)3141。PSME 3141提供管理接口,以在抽屉级别下管理模块或刀片。在示例中,机架包含一个或多个逻辑PSME。例如,每个抽屉可具有PSME,或者服务器抽屉可共享PSME,或者PSME可在架顶(TOR)3144交换机上或在单独的主机上运行。在示例中,PSME 3141支持RSD API。
在示例中,计算橇板3140可包括用于运行RSD软件栈的处理器(CLX),该RSD软件栈实现充当目标系统并管理分解资源集合的NVM-oF或FPGA-oF。在示例中,处理器使用PCIex16分叉端口连接至PCIe交换机3146,从而提供对目标资源(RSD 3148中的FPGA或NVME)的访问。
在计算橇板3140中可使用各种RSD边缘组合节点风格来运行边缘服务。在那些节点上运行的服务可使用客户端软件库或驱动程序来提供对RSD3148中分解的FPGA和NVME的透明访问。在进一步的示例中,机架包括一个或多个PCIe交换机,该一个或多个PCIE交换机将计算橇板3140连接至分解资源(例如,RSD 3148)的集合。
图28、图29、图30和图31的图示旨在描绘边缘计算节点的各种设备、子系统、或布置的组件的高级视图。然而,将理解,可以省略所示出组件中的一些组件,可存在附加组件,并且在其他实现方式中可发生对所示出的组件的不同布置。此外,这些布置可用于各种用例和环境中,这些用例和环境包括下文所讨论的那些用例和环境(例如,用于智慧城市或智慧工厂的工业计算中的移动UE,以及许多其他示例)。
图28、图29、图30和图31的相应计算平台可通过使用在单个计算平台上运行的租户容器来支持多个边缘实例(例如,边缘集群)。同样,多个边缘节点可作为在同一计算平台内的租户上运行的子节点而存在。相对应地,基于可用的资源分区,可将单个系统或计算平台分区或划分为支持多个租户和边缘节点实例,该多个租户和边缘节点实例中的每一者可支持多个服务和功能——即使在潜在地在多个计算平台实例中由多个所有者操作或控制时也是如此。这些各种类型的分区可通过使用LSM或使用隔离/安全性策略的其他实现方式来支持复杂的多租户、以及多利益相关方的许多组合。由此在以下章节中记述对使用LSM、以及增强或实现此类安全性特征的安全性特征的引用。同样,在这些各种类型的多实体分区上操作的服务和功能可以是负荷平衡的、经迁移的、以及经编排的,以实现必要的服务目标和操作。
5.示例实现方式
当前所描述的方法、系统和设备实施例的附加示例包括下列非限制性实现方式。下列非限制性示例中的每一个示例可以独立存在,或可以与以下所提供的或遍及本公开的其他示例中的任何一个或多个示例按照任何排列或组合进行结合。
示例1包括一种获得用于网络拥塞控制标识和用于迁移应用任务的网络相关信息的方法,该方法包括:在由移动设备操作的客户端侧应用“app”处接收来自由MEC服务器操作的多接入边缘计算“MEC”app的网络相关信息;以及由客户端app基于所获取的网络相关信息来适配一个或多个网络参数;或者由客户端app基于网络相关信息向MEC服务器迁移一个或多个app任务。
示例2包括示例1和/或本文的某个(些)其他示例的方法,其中,传输协议被用于在客户端app与MEC app之间传输通信量,客户端app是传输协议运行时“TPR”实体,网络相关信息包括容量和连接相关信息,一个或多个网络参数是传输协议参数,并且适配包括:基于容量和连接相关信息来适配传输协议参数。
示例3包括示例2和/或本文的某个(些)其他示例的方法,其中,MEC app包括被布置用于与TPR实体以及被包括在MEC app中或被包括在由MEC服务器操作的另一MEC app中的服务器app交互的另一TPR实体。
示例4包括示例2-3和/或本文的某个(些)其他示例的方法,进一步包括:由TPR检测触发事件;经由RNI应用编程接口“API”将请求消息传送到由MEC服务器提供的无线电网络信息“RNI”服务,以及接收包括经由RNI API从RNI服务接收容量和连接相关信息。
示例5包括示例4和/或本文中的某个(些)其他示例的方法,进一步包括:经由位置API将请求消息传送到由MEC服务器提供的位置服务,以及经由位置API从位置服务接收移动设备的位置信息。
示例6包括示例2-3的方法和/或本文的某个(些)其他示例,其中,当客户端app已经订阅由MEC服务器提供的RNI服务时,接收包括:当MEC app检测到触发事件时,经由RNIAPI从RNI服务接收容量和连接相关信息。
示例7包括示例4-6和/或本文中的某个(些)其他示例的方法,进一步包括:由TPR基于容量和连接相关信息将触发事件分类为拥塞事件或非拥塞事件。
示例8包括示例7和/或本文中的某个(些)其他示例的方法,其中,当触发事件被分类为拥塞事件时,适配包括以下各项中的一项或两项:由TPR减小拥塞窗口(CW);或实现拥塞控制算法。
示例9包括本文示例7-8和/或本文中的某个(些)其他示例的方法,其中,当触发事件被分类为非拥塞事件时,适配包括:在不减小CW的情况下停止传输。
示例10包括示例7-9和/或本文中的某个(些)其他示例的方法,其中,拥塞事件是消息超时或对重复的确认的接收,并且非拥塞事件是处于或低于阈值的信号强度测量或者处于或低于另一阈值的信道质量测量。
示例11包括示例4-10和/或本文中的某个(些)其他示例的方法,进一步包括:基于客户端app的性能要求来选择交互模式,其中,交互模式是请求/响应模式或发布/订阅模式。
示例12包括示例11和/或本文中的某个(些)其他示例的方法,其中客户端app的性能要求包括服务可靠性要求、端到端等待时间要求、服务质量(QoS)要求、订阅要求或限制、用户装备(UE)类型和/或其他度量。
示例13包括示例1和/或本文中的某个(些)其他示例的方法,其中客户端app是经扩展的提前服务质量通知(“e-IQN”)消费者,网络相关信息包括e-IQN属性,并且接收包括:
从e-IQN生产者接收e-IQN响应消息。
示例14包括示例13和/或本文中的某个(些)其他示例的方法,进一步包括:向e-IQN生产者发送包括经规划的路线的e-IQN请求,该经规划的路线包括沿着该经规划的路线的一个或多个航点以及该一个或多个航点中的每个航点的对应预期到达时间,其中该e-IQN响应基于该e-IQN请求。
示例15包括示例13-14和/或本文中的某个(些)其他示例的方法,其中e-IQN属性包括在对应预期到达时间的每个航点的预测无线电状况。
示例16包括示例15和/或本文中的某个(些)其他示例的方法,其中e-IQN属性进一步包括在对应预期到达时间为每个航点服务的边缘计算节点的预测计算资源。
示例17包括一种用于提供提前服务质量通知“e-IQN”通知的方法,该方法包括:由e-IQN生产者接收来自e-IQN消费者的第一e-IQN请求,该第一e-IQN请求包括沿经规划的路线的一个或多个航点以及该一个或多个航点中的每个航点的对应预期到达时间;向预测性功能(PF)发送包括一个或多个航点和对应的预期到达时间的第二e-IQN请求;从PF接收e-IQN属性,该e-IQN属性包括每个航点在对应预期到达时间的预测参数;以及向e-IQN消费者发送包括e-IQN属性的e-IQN响应。
示例18包括示例17和/或本文中的某个(些)其他示例的方法,其中,PF是无线电接入网“RAN”PF,并且所预测的参数是每个航点在对应预期到达时间的预测无线电状况。
示例19包括示例17和/或本文中的某个(些)其他示例的方法,其中PF是云PF,并且预测参数是每个航点处或附近的一个或多个边缘计算节点部署区域在对应预期到达时间的预测边缘计算资源。
示例20包括示例17和/或本文中的某个(些)其他示例的方法,其中PF是RAN PF,e-IQN属性是第一e-IQN属性,预测参数是第一预测参数,并且该方法进一步包括:向云PF发送包括一个或多个航点以及对应预期到达时间的第三e-IQN请求;以及从云PF接收第二e-IQN属性,该第二e-IQN属性包括每个航点在对应预期到达时间的第二预测参数。
示例21包括示例20和/或本文中的某个(些)其他示例的方法,其中,第一预测参数是每个航点在对应预期到达时间的预测无线电状况,而第二预测参数是每个航点在对应预期到达时间的预测边缘计算资源,并且该方法进一步包括:通过将第一预测参数和第二预测参数进行级联来生成e-IQN响应。
示例22包括示例18-21的方法,其中eIQN消费者是第一eIQN消费者,e-IQN请求是第一e-IQN请求,并且该方法进一步包括:从第二eIQN消费者接收包括边缘服务部署地理位置和感兴趣的时间的第二e-IQN请求;以及向云PF发送另一第二e-IQN请求。
示例23包括示例17-22的方法,其中,第一e-IQN请求包括路线数据元素,路线数据元素包括每个航点的路线信息(routeInfo)数据元素,并且每个航点的路线信息数据元素包括位置数据元素和时间数据元素,该位置数据元素包括对应航点的位置信息,该时间数据元素包括预期到达时间的时间戳。
示例24包括示例23的方法,其中该e-IQN响应包括另一路线数据元素,该另一路线数据元素包括每个航点的另一个路线信息数据元素,并且每个航点的另一路线信息数据元素包括位置数据元素,该位置数据元素包括包含对应航点的预测rsrp值的参考信号接收功率(rsrp)数据元素和包含对应航点的预测rsrp值的参考信号接收功率(rsrq)数据元素。
示例25包括示例24的方法,其中每个航点的另一路线信息数据元素进一步包括以下各项中的一项或多项:可用处理器功率数据元素,包括最接近对应航点的边缘计算节点的可用处理功率;可用存储器数据元素,包括最接近对应航点的边缘计算节点的可用存储器资源量;以及可用存储数据元素,包括最接近对应航点的边缘计算节点的可用存储资源量。
示例26包括一种或多种计算机可读介质,包括指令,其中,由处理器电路系统对这些指令的执行使得该处理器电路系统用于执行示例1-16和/或示例17-25中的方法。示例27包括一种包含示例26的指令的计算机程序。示例28包括一种应用编程接口,该应用编程接口定义用于示例27的计算机程序的函数、方法、变量、数据结构和/或协议。示例29包括一种装置,该装置包括加载有示例26的指令的电路系统。示例30包括一种装置,该装置包括可操作用于运行示例26的指令的电路系统。示例31包括一种集成电路,该集成电路包括以下中的一项或多项:示例26的处理器电路系统;以及示例26的一种或多种计算机可读介质。示例32包括一种计算系统,该计算系统包括示例26的一种或多种计算机可读介质以及处理器电路系统。示例33包括一种设备,该设备包括用于执行示例26的指令的装置。示例34包括一种信号,该信号作为执行示例26的指令的结果而被生成。示例35包括一种数据单元,该数据单元作为执行示例26的指令的结果而被生成。示例36包括示例35的数据单元,其中,该数据单元是数据报、网络分组、数据帧、数据段、协议数据单元(PDU)、服务数据单元(SDU)、消息或数据库对象。示例37包括利用示例35或示例36的数据单元编码的信号。示例38包括携载示例26的指令的电磁信号。示例39包括一种设备,包括:用于执行示例1-16和/或示例17-25的方法的装置。
示例Z01包括一种设备,该设备包括用于执行示例1-39中任一项中所描述的或与示例1-39中任一项有关的方法、或本文所描述的其他方法或过程的一个或多个要素的装置。示例Z02包括一种或多种非暂态计算机可读介质,包括指令,这些指令在由电子设备执行时使得该电子设备执行示例1-39中任一项中所描述的或与示例1-39中的任一项有关的方法、或本公开中所描述的其他方法或过程的一个或多个要素。示例Z03包括包含指令的计算机程序,其中,处理元件对程序的执行可操作用于使处理元件执行在示例1-39和/或其多个部分中的任一者中描述的或与其相关的方法、技术或过程。示例Z04包括一种设备,该设备包括逻辑、模块或电路系统,以执行示例1-39中任一项中所描述的和/或与示例1-39中任一项有关的方法、或本文所描述的其他方法或过程的一个或多个要素的装置。示例Z05包括一种设备,该设备被配置成用于执行示例1-39中任一项中所描述的或与示例1-39中任一项有关的方法、和/或本文所描述的其他方法或过程的一个或多个要素。示例Z06包括如在示例1-39和/或其部分或片段的任一项中所描述的或与示例1-39和/或其部分或片段的任一项有关的方法、技术、或过程。示例Z07包括一种设备,该设备包括:处理器电路系统和计算机可读介质,包括指令,其中一个或多个处理器可配置成用于执行如在示例1-39和/或其部分的任一项中所描述的或与示例1-39和/或其部分中的任一项有关的方法、技术、或过程。示例Z08包括如在示例1-39和/或其部分或片段的任一项中所描述的或与示例1-39和/或其部分或片段中的任一项有关的信号。示例Z09包括如在示例1-39或其部分或片段的任一项中所描述的或与示例1-39或其部分或片段中的任一项有关的数据报、分组、帧、片段、协议数据单元(PDU)、或消息,和/或包括本公开中以其他方式描述的数据报、分组、帧、片段、协议数据单元(PDU)、或消息。示例Z10包括一种信号,该信号被编码有如在示例1-39或其部分或片段的任一项中所描述的或与示例1-39或其部分或片段中的任一项有关的数据报、分组、帧、片段、PDU、或消息,或包括本公开中以其他方式描述的分组、帧、片段、PDU、或消息。示例Z11包括一种信号,该信号被编码有如在示例1-39或其部分或片段中任一项中所描述的或与示例1-39或其部分或片段中的任一项有关的数据,或包括本公开中以其他方式描述的数据。示例Z12包括承载计算机可读指令的电磁信号,其中,一个或多个处理器对计算机可读指令的执行可操作或可配置成用于使一个或多个处理器执行在示例1-39或其多个部分中的任一者中描述的或与其相关的方法、技术或过程。示例Z13包括定义或涉及对示例1-39或其部分中的任一项的使用或以其他方式涉及示例1-39或其部分中的任一项的API或定义函数、方法、变量、数据结构、协议等的规范。示例Z14包括多接入边缘计算(MEC)主机,该主机执行作为在虚拟化基础设施上实例化的一个或多个MEC应用的一部分的服务,该服务与示例1-39或其部分中的任一项相关,并且其中MEC主机被配置成用于根据来自一个或多个ETSI MEC标准系列的标准进行操作。示例Z15包括如本文中所示和所描述的无线网络中的信号。示例Z16包括如本文中所示和所描述的无线网络中的通信方法。示例Z17包括用于提供如本文中所示和所描述的无线通信的系统。示例Z18包括用于提供如本文中所示和所描述的无线通信的设备。
示例实现方式是一种边缘计算系统,该边缘计算系统包括用于调用或执行示例1-39或者本文中所描述的其他主题的操作的相应边缘处理设备和节点。另一示例实现方式是一种客户端端点节点,该客户端端点节点可操作以用于调用或执行示例1-39或者本文中所描述的其他主题的操作。另一示例实现方式是一种处于边缘计算系统内或耦合至边缘计算系统的聚合节点、网络中枢节点、网关节点、或核心数据处理节点,该聚合节点、网络中枢节点、网关节点、或核心数据处理节点可操作以用于调用或执行示例1-39或者本文中所描述的其他主题的操作。另一示例实现方式是一种处于边缘计算系统内或耦合至边缘计算系统的接入点、基站、路边单元、或内部单元,该接入点、基站、路边单元、或内部单元可操作以用于调用或执行示例1-39或者本文中所描述的其他主题的操作。另一示例实现方式是一种处于边缘计算系统内或耦合至边缘计算系统的边缘供应节点、服务编排节点、应用编排节点、或多租户管理节点,该边缘供应节点、服务编排节点、应用编排节点、或多租户管理节点可操作以用于调用或执行示例1-39或者本文中所描述的其他主题的操作。
另一示例实现方式是一种处于边缘计算系统内或耦合至边缘计算系统的边缘节点,该边缘节点操作边缘供应服务、应用或服务编排服务、虚拟机部署、容器部署、功能部署、以及计算管理,该边缘节点可操作以用于调用或执行示例1-39或者本文中所描述的其他主题的操作。另一示例实现方式是一种边缘计算系统,该边缘计算系统可作为边缘网格、作为具有边车加载或具有网格对网格通信的边缘网格来操作,该边缘计算系统可操作以用于唤起或执行示例1-39的操作、或者本文中所描述的其他主题。另一示例实现方式是一种边缘计算系统,该边缘计算系统包括网络功能、加速功能、加速硬件、存储硬件、或计算硬件资源的各方面,该边缘计算系统可操作以使用示例1-39或本文中所描述的其他主题来调用或执行本文中所讨论的用例。另一示例实现方式是一种边缘计算系统,该边缘计算系统适于支持客户端移动性、交通工具对交通工具(V2V)、交通工具对外界(V2X)、或交通工具对基础设施(V2I)场景,并且任选地根据ETSI MEC规范来进行操作,该边缘计算系统可操作以使用示例1-39或本文中所描述的其他主题来调用或执行本文中所讨论的用例。另一示例实现方式是一种边缘计算系统,该边缘计算系统适于移动无线通信,包括根据3GPP 4G/LTE或5G网络能力的配置,该边缘计算系统可操作以使用示例1-39或本文中所描述的其他主题来调用或执行本文中所讨论的用例。
6.术语
如本文中所使用,单数形式的“一”(“a”、“an”)和“该”(“the”)旨在也包括复数形式,除非情境另外清楚地指示。还将理解,当在本说明书中使用术语“包括”(“comprise”和/或“comprising”)时,其指定所陈述的特征、整数、步骤、操作、元件、和/或组件的存在,但不排除一个或多个其他特征、整数、步骤、操作、元件、组件、和/或其群组的存在或添加。短语“A和/或B”意指(A)、(B)或(A和B)。出于本公开的目的,短语“A、B和/或C”意指(A)、(B)、(C)、(A和B)、(A和C)、(B和C)或(A、B和C)。说明书可使用短语“在实施例中”或“在一些实施例中”,其可各自指代相同或不同实施例中的一个或多个实施例。此外,如相对于本公开的实施例所使用的术语“包含”、“包括”、“具有”等是同义的。
本文中使用术语“耦合的”、“通信地耦合的”及其派生词。术语“耦合的”可意指两个或更多个元件彼此处于直接的物理或电接触,可意指两个或更多个元件间接地彼此接触但仍彼此协作或交互,和/或可意指一个或多个其他元件被耦合或连接在被称为彼此耦合的元件之间。术语“直接耦合的”可意指两个或更多个元件彼此直接接触。术语“通信地耦合的”可意指两个或更多个元件可通过通信手段彼此联系,通过通信手段包括通过线或其他互连连接、通过无线通信信道或墨迹,等等。
术语“电路系统”是指被配置成用于执行电子设备中的特定功能的电路或具有多个电路的系统。电路或电路的系统可以是被配置成用于提供所描述的功能的一个或多个硬件组件的部分或包括该一个或多个硬件组件,该一个或多个硬件组件诸如逻辑电路、处理器(共享的、专用的或成组的)和/或存储器(共享的、专用的或成组的)、ASIC、FPGA、可编程逻辑控制器(PLC)、SoC、SiP、多芯片封装(MCP)、DSP等。另外,术语“电路系统”也可指代一个或多个硬件元件与程序代码的组合,用于执行该程序代码的功能。一些类型的电路系统可执行一个或多个软件或固件程序,以提供所描述的功能中的至少一些。此类硬件元件与程序代码的组合可被称为特定类型的电路系统。
应当理解,在本说明书中所描述的功能单元或能力可能已被称为或标记为组件或模块,从而特别强调其实现方式的独立性。此类组件可由任何数量的软件或硬件形式来具体化。例如,组件或模块可以被实现成硬件电路,该硬件电路包括定制的超大规模集成(VLSI)电路或门阵列、诸如逻辑芯片、晶体管之类的现成的半导体,或其他分立的组件。组件或模块也可被实现在可编程硬件设备中,诸如现场可编程门阵列、可编程阵列逻辑、可编程逻辑器件等。组件或模块也可被实现在用于由各种类型的处理器执行的软件中。可执行代码的所标识的组件或模块可以例如包括计算机指令的一个或多个物理或逻辑框,其可被组织成例如对象、过程、或函数。然而,所标识的组件或模块的可执行对象不必在物理上在一起,而是可包括存储在不同位置处的不同指令,当这些指令在逻辑上结合在一起时,包括组件或模块,并且为该组件或模块实现所声称的目的。
实际上,可执行代码的组件或模块可以是单条指令或许多指令,并且甚至可以分布在若干不同的代码段上,分布在不同的程序之间以及跨若干存储器设备或处理系统分布。具体而言,所描述的过程的一些方面(诸如代码重写和代码分析)可能在与在其中部署代码的处理系统(例如,在嵌入在传感器或机器人的计算机中)不同的处理系统(例如,在数据中心中的计算机中)上进行。类似地,操作数据在此可被标识并示出在组件或模块内,并且能以任何合适的形式被具体化并且可以被组织在任何合适类型的数据结构内。操作数据可作为单个数据集被收集,或者可被分布不同的位置上(包括在不同存储设备上),并且可以至少部分地仅作为系统或网络上的电子信号存在。组件或模块可以是无源或有源的,包括可操作以执行期望功能的代理。
如本文中所使用,术语“处理器电路”是指能够顺序地且自动地执行算术或逻辑操作序列,记录、存储和/或传递数字数据的电路,是该电路的部分,或者包括该电路。术语“处理器电路系统”可指一个或多个应用处理器、一个或多个基带处理器、物理CPU、单核处理器、双核处理器、三核处理器、四核处理器、和/或能够执行或以其他方式操作计算机可执行指令的任何其他设备,这些计算机可执行指令诸如程序代码、软件模块和/或函数进程。术语“应用电路系统”和/或“基带电路系统”可视为与“处理器电路系统”是同义的,或可被称为“处理器电路系统”。
本文中所使用的术语“存储器”和/或“存储器电路系统”是指用于存储数据的一个或多个硬件设备,包括RAM、MRAM、PRAM、DRAM、和/或SDRAM、核存储器、ROM、磁盘存储介质、光学存储介质、闪存设备或用于存储数据的其他机器可读介质。术语“计算机可读介质”可包括但不限于存储器、便携式或固定存储设备、光存储设备以及能够存储、包含或承载指令或数据的各种其他介质。
如本文中所使用,术语“接口电路”是指实现两个或更多个组件或设备之间的信息交换的电路,是该电路的部分,或者包括该电路。术语“接口电路系统”可指一个或多个硬件接口,例如,总线、I/O接口、外围组件接口、网络接口卡,等等。
术语“元件”是指在给定的抽象水平不可分并且具有清楚地限定的边界的单元,其中,元件可以是任何类型的实体,包括例如一个或多个设备、系统、控制器、网络元件、模块等、或其组合。术语“设备”是指物理实体,该物理实体被嵌入在其附近的另一物理实体内部或附连至其附近的另一物理实体,具有传达来自该物理实体的数字信息或向该物理实体传达数字信息的能力。术语“实体”是指架构或设备的不同组件、或作为有效载荷被传递的信息。术语“控制器”是指具有影响物理实体(诸如通过改变其状态或使物理实体移动)的能力的元件或实体。
如本文中所使用,术语“边缘计算”涵盖致力于针对端点用户(客户端设备、用户装备等)减少等待时间并增加吞吐量而将处理活动和资源(例如,计算、存储、加速资源)朝向网络的“边缘”移动的分布式计算的许多实现方式。此类边缘计算实现方式典型地涉及从经由无线网络可访问的一个或多个位置在类云服务、功能、应用和子系统中提供此类活动和资源。由此,对本文中所使用的网络、集群、域、系统或计算布置的“边缘”的引用是起作用的分布式计算元件的群组或分组,并且由此一般与图论中使用的“边缘”(链接或连接)无关。经由移动无线网络(例如,蜂窝和WiFi数据网络)可访问的边缘计算应用和服务的特定布置可被称为“移动边缘计算”或“多接入边缘计算”,其可通过缩写“MEC”来引用。本文中对“MEC”的使用也可指代由欧洲电信标准协会(ETSI)颁布的标准化实现方式,被称为“ETSIMEC”。ETSI MEC规范所使用的术语通过引用总体结合于此,除非本文中提供冲突的定义或使用。
如本文中所使用,术语“计算节点”或“计算设备”是指实现边缘计算操作的一方面的可标识的实体(不论是较大系统的部分、分布式系统集合、还是独立装置)。在一些示例中,计算节点可被称为“边缘节点”、“边缘设备”、“边缘系统”,而不论作为客户端、服务器还是中间实体来进行操作。计算节点的特定实现方式可被并入到服务器、基站、网关、路边单元、内部单元、UE或终端消费设备等等中。
如本文中所使用的术语“计算机系统”是指任何类型经互连的电子设备、计算机设备、或其组件。另外,术语“计算机系统”和/或“系统”可指计算机的彼此通信地耦合的各种组件。此外,术语“计算机系统”和/或“系统”可指彼此通信地耦合并且被配置成用于共享计算和/或联网资源的多个计算机设备和/或多个计算系统。
如本文中所使用的术语“架构”是指计算机架构或网络架构。“网络架构”是在包括通信协议、接口和介质传输的网络中软件和/或硬件元件的物理和逻辑设计或布置。“计算机架构”是在包括软件和/或硬件之间的交互的技术标准的计算系统或平台中的软件和/或硬件元件的物理和逻辑设计或布置。
如本文中所使用,术语“装置”、“计算机装置”等等是指具有程序代码(例如,软件或固件)的、专门被设计成用于提供特定计算资源的计算机设备或计算机系统。“虚拟装置”是用于由使计算机装置虚拟化或模仿计算机装置或者以其他方式专用于提供特定的计算资源的、由装配有管理程序的设备实现的虚拟机镜像。
如本文中所使用的术语“用户装备”或“UE”是指具有无线电通信能力的设备,并且可描述通信网络中网络资源的远程用户。术语“用户装备”或“UE”可被认为与以下各项同义并且可被称为以下各项:客户端、移动式装置、移动设备、移动终端、用户终端、移动单元、移动站、移动用户、订户、用户、远程站、接入代理、用户代理、接收机、无线电装备、可重配置无线电装备、可重配置移动设备等。术语“站”或“STA”是指作为对无线介质(VM)的介质访问控制(MAC)和物理层(PHY)接口的可单独寻址的实例的逻辑实体。术语“无线介质”或WM”是指用于实现协议数据单元(PDU)在无线局域网(LAN)的对等物理层(PHY)实体之间的传输的介质。
如本文中所使用的术语“网络元件”是指用于提供有线或无线通信网络服务的物理或虚拟化的装备和/或基础设施。术语“网络元件”可被认为与以下各项同义和/或被称为以下各项:联网的计算机、联网硬件、网络装备、网络节点、路由器、交换机、中枢、网桥、无线电网络控制器、RAN设备、RAN节点、网关、服务器、虚拟化VNF、NFVI等等。
如本文所使用的,术语“接入点”或“AP”是指包含一个站(STA)并且经由针对相关联的STA的无线介质(WM)提供对分发服务的访问的实体。至少在一些实施例中,AP包括STA和分发系统访问功能(DSAF)。如本文中所使用,术语“基站”是指无线电接入网络(RAN)中的网络元件,该无线电接入网络诸如负责一个或多个蜂窝小区中将无线电信号发送至用户装备(UE)或从用户装备(UE)接收无线电信号的第四代(4G)或第五代(5G)移动通信网络。基站可以具有集成式天线,或者可通过馈电电缆连接至天线阵列。基站使用专门的数字信号处理和网络功能硬件。在一些示例中,出于灵活性、成本、以及性能,可将基站分成采用软件进行操作的多个功能块。在一些示例中,基站可包括演进节点B(eNB)或下一代节点B(gNB)。在一些示例中,基站可操作或包括计算硬件,以作为计算节点来进行操作。然而,在本文中所讨论的场景中的许多场景中,RAN基站可以以接入点(例如,无线网络接入点)或其他网络接入硬件来代替。
如本文中所使用,术语“中央局”(或CO)指示可访问或所限定的地理区域内的、用于电信基础设施的聚合点,通常电信服务提供商传统上将用于一种或多种类型的接入网络的切换装备定位在其中。CO可以在物理上被设计成用于容纳电信基础设施装备或计算、数据存储和网络资源。然而,CO不需要是由电信服务提供商指定的位置。CO可主控用于边缘应用和服务(或者甚至类云服务的本地实现方式)的任何数量的计算设备。
术语“云计算”或“云”是指用于在具有按需要自服务供应和管理并且不具有用户的主动管理的情况下启用对可扩展且弹性的可共享资源池的网络访问的范式。云计算提供云计算服务(或云服务),该云计算服务(或云服务)是经由使用所定义的接口(例如,API,等等)唤起的云计算而提供的一项或多项能力。术语“计算资源”或简称为“资源”是指在计算机系统或网络内具有有限的可用性的任何物理或虚拟组件或对此类组件的使用。计算资源的实例包括在一段时间内对以下各项的使用/访问:服务器、(多个)处理器、存储装备、存储器设备、存储器区域、网络、电功率、输入/输出(外围)设备、机械设备、网络连接(例如,信道/链路、端口、网络插槽等)、操作系统、虚拟机(VM)、软件/应用、计算机文件等等。“硬件资源”可以指由(多个)物理硬件元件提供的计算、存储和/或网络资源。“硬件资源”可以指由(多个)物理硬件元件提供的计算、存储和/或网络资源。术语“系统资源”可指用于提供服务的任何种类的共享实体,并且可包括计算和/或网络资源。系统资源可被认为是通过服务器可访问的一组连贯的功能、网络数据对象或服务,其中此类系统资源驻留在单个主机或多个主机上并且是可清楚标识的。
术语“工作负荷”指在实践段期间或在特定时刻由计算系统、设备、实体等执行的工作量。工作负荷可被标识为基准,诸如响应时间、吞吐量(例如,在一段时间内完成多少工作),等等。附加地或替代地,工作负荷可被表示为以下各项:存储器工作负荷(例如,程序执行以存储临时或永久数据且执行中间计算所需的存储器空间的量)、处理器工作负荷(例如,在给定时间段期间或特定时刻由处理器执行的指令数量)、I/O工作负荷(例如,在给定时间段期间或特定时刻输入和输出或系统访问的数量)、数据库工作负荷(例如,在时间段期间的数据库查询的数量)、网络相关的工作负荷(例如,网络附连的数量、移动性更新的数量、无线电链路失败的数量、移交的数量、要通过空中接口传递的数据量等),等等。可使用各种算法来确定工作负荷和/或工作负荷特性,其可基于前述工作负荷类型中的任一者。
如本文中所使用,术语“云服务提供商”(或CSP)指示典型地对大规模的“云”资源进行操作的组织,这些大规模的“云”资源由集中式、区域的、和边缘数据中心组成(例如,如在公共云的情境中所使用)。在其他示例中,CSP也可被称为云服务运营商(CSO)。对“云计算”的引用一般是指在相对于边缘计算具有至少一些增加的等待时间、距离、或约束的远程位置处由CSP或CSO提供的计算资源和服务。
如本文中所使用,术语“数据中心”是指旨在容纳多个高性能计算和数据存储节点以使得大量的计算、数据存储和网络资源存在于单个位置处的有目的设计的结构。这通常使得需要专门的机架和封装系统、合适的加热、冷却、通风、安全性、灭火、以及功率递送系统。在一些情境中,该术语还可指代计算和数据存储节点。在集中式数据中心或云数据中心(例如,最大的数据中心)、区域数据中心、以及边缘数据中心(例如,最小的数据中心)之间,数据中心的规模可能有所不同。
如本文中所使用,术语“接入边缘层”指示基础设施边缘的、最靠近于终端用户或设备的子层。例如,此类层可通过被部署在蜂窝网络位置处的边缘数据中心来满足。接入边缘层作为基础设施边缘的前线来起作用,并且可连接至层级结构中较高的聚合边缘层。
如本文中所使用,术语“聚合边缘层”指示距接入边缘层一跳的基础设施边缘的层。该层可以要么作为中等规模的数据中心存在于单个位置中,要么可由多个互连的微型数据中心形成,以形成具有接入边缘的分层拓扑,从而允许相比于仅有接入边缘更大的协作、工作负荷故障转移、以及可缩放性。
如本文所使用的,术语“网络功能虚拟化”(或NFV)指示使用工业标准虚拟化和云计算技术、将NF从专有硬件设备内的嵌入式服务迁移到在标准化CPU(例如,在标准
Figure BDA0003546022750001111
Figure BDA0003546022750001112
服务器内,诸如包括
Figure BDA0003546022750001113
至强TM(XeonTM)或者
Figure BDA0003546022750001114
EpycTM或OpteronM处理器的那些标准化CPU)上运行的基于软件的虚拟化NF(或VNF)。在一些方面,NFV处理和数据存储将在基础设施边缘内的、直接连接至本地蜂窝站点的边缘数据中心处发生。
如本文所使用的,术语“虚拟化网络功能”(或VNF)指示在多功能多目的计算资源(例如,x86、ARM基础架构)上操作的基于软件的NF,其可代替于专用物理装备而被NFV使用。在一些方面,若干VNF将在基础设施边缘处的边缘数据中心上操作。
如本文中所使用,术语“边缘计算节点”是指以设备、网关、桥接器、系统或子系统、组件形式的能够进行计算的元件的真实世界的、逻辑的、或虚拟化的实现方式,而不论是在服务器、客户端、端点还是对等模式下操作,并且不论位于网络的“边缘”处还是位于进一步处于网络内的连接的位置处。一般而言,对本文中所使用的“节点”的引用与“设备”、“组件”和“子系统”是可互换的;然而,对“边缘计算系统”的引用一般是指分布式架构、组织、或多个节点和设备的集合,并且边缘计算系统被组织成用于完成或提供边缘计算设置中的服务或资源中的某个方面。
术语“物联网”或“IoT”是指具有能够以较少的人类交互或在没有人类交互的情况下传输数据的相互联系的计算设备、机械和数字机器的系统,并且可涉及诸如实时分析、机器学习和/或AI、嵌入式系统、无线传感器网络、控制系统、自动化(例如,智慧家居、智慧建筑和/或智慧城市技术)等等。IoT设备通常是不具有重度计算或存储能力的低功率设备。“边缘IoT设备”可以是被部署在网络的边缘处的任何种类的IoT设备。
如本文中所使用,术语“集群”是指以物理实体(例如,不同的计算系统、网络或网络群组)、逻辑实体(例如,应用、功能、安全性构造、容器)等等的形式、作为边缘计算系统(或多个边缘计算系统)的部分的实体集合或实体分组。在一些位置中,“集群”也指代“群组”或“域”。集群的成员关系可基于包括来自动态成员关系或基于属性的成员关系、来自网络或系统管理场景、或来自下文所讨论的各种示例技术的、可添加、修改或移除集群中的实体的状况或功能而被修改或影响。集群还可包括多个层、级别或属性,或与多个层、级别或属性相关联,该多个层、级别或属性包括基于此类层、级别或属性的安全性特征和结果的变型。
如本文中所使用,术语“无线电技术”是指用于电磁辐射的无线传送和/或接收以进行信息传递的技术。术语“无线电接入技术”或“RAT”是指用于至基于无线电的通信网络的底层物理连接的技术。术语“V2X”是指交通工具对交通工具(V2V)、交通工具对基础设施(V2I)、基础设施对交通工具(I2V)、交通工具对网络(V2N)、和/或网络对交通工具(N2V)通信和相关联的无线电接入技术(RAT)。
如本文中所使用,“通信协议”(有线或无线的)是指由通信设备/系统实现以与其他设备进行通信的一组标准化规则或指令,包括用于对数据进行打包/拆包、对信号进行调制/解调的指令,协议栈的实现方式,等等。可在各个实施例中使用的无线通信协议的示例包括全球移动通信系统(GSM)无线电通信技术、通用分组无线电服务(GPRS)无线电通信技术、GSM演进的增强数据速率(EDGE)无线电通信技术和/或第三代伙伴计划(3GPP)无线电通信技术,包括例如,3GPP第五代(5G)或新无线电(NR)、通用移动电信系统(UMTS)、自由多媒体接入(FOMA)、长期演进(LTE)、高级LTE(LTE Advanced)、LTE额外(LTE Extra)、LTE-A加强版(LTE-A Pro)、cdmaOne(2G)、码分多址2000(CDMA2000)、蜂窝数字分组数据(CDPD)、Mobitex、电路交换数据(CSD)、高速CSD(HSCSD)、通用移动电信系统(UMTS)、宽带码分多址(W-CDM)、高速分组接入(HSPA)、增强型高速分组接入(HSPA+)、时分-码分多址(TD-CDMA)、时分-同步码分多址(TD-SCDMA)、LTE LAA、MuLTEfire、UMTS陆地无线电接入(UTRA)、演进型UTRA(E-UTRA)、演进数据优化或仅演进数据(EV-DO)、高级移动电话系统(AMPS)、数字AMPS(D-AMPS)、全接入通信系统/扩展式全接入通信系统(TACS/ETACS)、按键通话(PTT)、移动电话系统(MTS)、改进型移动电话系统(IMTS)、高级移动电话系统(AMTS)、蜂窝数字分组数据(CDPD)、DataTAC、集成数字增强网络(iDEN)、个人数字蜂窝(PDC)、个人手持式电话系统(PHS)、宽带集成数字增强网络(WiDEN)、iBurst、非许可移动接入(UMA,也被称为3GPP通用接入网络或GAN标准)、
Figure BDA0003546022750001132
Figure BDA0003546022750001131
蓝牙低能量(BLE)、基于IEEE 802.15.4的协议(例如,通过低功率无线个域网的IPv6(6LoWPAN)、WirelessHART、MiWi、Thread、802.11a等)、WiFi直接(WiFi-direct)、ANT/ANT+、ZigBee、Z波(Z-Wave)、3GPP设备对设备(D2D)或邻近服务(ProSe)、通用即插即用(UPnP)、低功率广域网(LPWAN)、长距离广域网(LoRA)或由Semtech和LoRa联盟开发的LoRaWANTM、Sigfox、无线千兆联盟(WiGig)标准、用于一般而言的毫米波接入(WiMax)mmWave标准的全球互通(诸如以10-300GHz及更高频率操作的无线系统,诸如WiGig、IEEE 802.11ad、IEEE 802.11ay等)、交通工具对外界(V2X)通信技术(包括3GPP C-V2X)、专用短距离通信(DSRC)通信系统(诸如,智能运输系统(ITS),包括欧洲ITS-G5、ITS-G5B、ITS-G5C等)。本文中所提供的示例因此可被理解为适用于各种现有的和尚未制定的各种其他通信技术。
如本文中所使用的术语“信道”是指用于传达数据或数据流的任何有形或无形的传输介质。术语“信道”可与“通信信道”、“数据通信信道”、“传输信道”、“数据传输信道”、“接入信道”、“数据访问信道”、“链路”、“数据链路”、“载波”、“射频载波”、和/或表示传达数据所通过的路径或介质的任何其他类似术语同义,和/或等同于这些术语。此外,如本文中所使用的术语“链路”是指两个设备之间出于传送和接收信息目的通过RAT进行的连接。
术语“服务质量”或“QoS”是指对服务(例如,电话和/或蜂窝服务、网络服务、无线通信/连接服务、云计算服务等)的整体性能的描述或测量。在一些情况下,可从该服务的用户的角度来描述或测量QoS,并且由此,QoS可以是确定用户对该服务的满意程度的服务性能的集体性效果。在其他情况下,QoS是指通信量优先级排定和资源保留控制机制,而不是实现的服务质量的感知。在这些情况下,QoS是向不同的应用、用户或数据流提供不同的优先级的能力,或者向数据流保证某个性能级别的能力。在任一情况下,QoS均通过可适用于一个或多个服务的性能因素的组合的各方面来表征,这些性能因素诸如例如,服务可操作性性能、服务可访问性性能、服务保持能力性能、服务可靠性性能、服务完整性性能、以及对于每个服务而言特定的其他因素。当对QoS进行量化时,可以考虑服务的若干有关方面,包括分组丢失率、位速率、吞吐量、传输延迟、可用性、可靠性、抖动、信号强度和/或质量测量、和/或诸如本文中所描述的那些之类的其他测量。
如本文中所使用的术语“局部化网络”可指覆盖某个区域或地区中有限数量的被连接的交通工具的局部网络。如本文中所使用的术语“分布式计算”可指在一个或多个局部化网络的终止的附近区域内地理上分布的计算资源。如本文中所使用的术语“局部数据集成平台”可指通过利用(多个)局部化网络和分布式计算来集成局部数据的平台、设备、系统、网络、或(多个)元件。
如本文中所使用的术语“实例化(instantiate、instantiation)”等等是指实例的创建。“实例”还指对象的具体发生,该对象例如可在程序代码的执行期间发生。术语“信息元素”是指包含一个或多个字段的结构元素。术语“字段”是指信息元素的各个内容或包含内容的数据元素。“数据库对象”、“数据结构”或类似术语可指采用对象、属性-值对(AVP)、关键字-值对(KVP)、元组等形式的任何信息表示,并且可包括变量、数据结构、函数、方法、类、数据库记录、数据库字段、数据库条目、数据和/或数据库条目之间的关联(也被称为“关系”)、区块链实现方式中的区块以及区块之间的链接等等。术语“数据元素”或“DE”是指包含一个单数据的数据类型。术语“数据帧”或“DF”是指包含按预定义的次序的多于一个的数据元素的数据类型。
如本文所使用的,术语“可靠性”是指计算机相关组件(例如,软件、硬件或网络元件/实体)一贯地执行期望的功能和/或根据规范进行操作的能力。在网络通信的情境下的可靠性(例如,“网络可靠性”)可指网络进行通信的能力。网络可靠性还可以是将指定数据量从源递送至目的地(或宿)的概率(或者是对该概率的测量)。
术语“应用”可指用于在操作环境中实现某种功能的完整且可部署的包、环境。术语“AI/ML应用”或类似术语可以是包含一些AI/ML模型和应用级描述的应用。术语“机器学习”或“ML”是指使用计算系统不使用明确的指令而是依赖于模式或推断来实现算法和/或统计模型以执行(多个)特定任务。ML算法基于样本数据(被称为“训练数据”、“模型训练信息”等)建立或估计(多个)数学模型(被称为“ML模型”等),以便在没有被明确编程为执行此类任务的情况下作出预测或决策。一般而言,ML算法是从相对于某项任务和某个性能测量的经验学习的计算机程序,并且ML模型可以是在ML算法利用一个或多个训练数据集被训练之后创建的任何对象或数据结构。在训练之后,ML模型可以用于作出关于新的数据集的预测。虽然术语“ML算法”是指不同于术语“ML模型”的概念,但是如本文中所讨论的这些数据可出于本公开的目的而可互换地使用。
术语“自我ITS-S”是指正在考虑的ITS-S,术语“自我交通工具”是指嵌入正在考虑的ITS-S的交通工具,而术语“邻居”是指不同于自我ITS-S和自我交通工具的其他ITS-S。
虽然前述示例中的许多示例在使用特定的蜂窝/移动网络技术的情况下(包括在使用4G/5G 3GPP网络组件(或预期的基于太赫兹的6G/6G+技术)的情况下)被提供,但是将理解的是,这些示例可应用于广域无线网络和局域无线网络的许多其他部署、以及有线网络的整合(包括光学网络及相关联的光纤、收发机等)。此外,各种标准(例如,3GPP、ETSI等)可定义各种消息格式、PDU、帧等,如包括任选的或强制性的数据元素(DE)序列、数据帧(DF)、信息元素(IE)等等。然而,应当理解,任何特定标准的要求不应限制本文所讨论的实施例,并且如此,容器、帧、DF、DE、IE、值、动作和/或特征的任何组合在各实施例中是可能的,包括严格要求被遵循以便符合此类标准的容器、DF、DE、值、动作和/或特征的任何组合或者强烈推荐和/或与任选的要素一起使用或在存在/不存在任选的要素的情况下使用的容器、帧、DF、DE、IE、值、动作和/或特征的任何组合。
虽然已经参考特定示例性方面描述了这些实现方式,但将显而易见的是,可在不背离本发明的较宽范围的情况下对这些方面作出各种修改和改变。本文中所描述的布置和过程中的许多布置和过程可以与用于提供更大的带宽/吞吐量的实现方式以及用于支持可以使其可用于被服务的边缘系统的边缘服务选择的实现方式组合或并行地使用。相应地,说明书和附图应当被认为是说明性的,而不是限制性意义的。形成本文的部分的所附附图以说明性而并非限制性方式示出主题可在其中被实施的特定方面。足够详细地描述了所图示的方面以使本领域的技术人员能够实施本文中所公开的教导。可利用并由此推导出其他方面,以使得可在不背离本公开的范围的情况下作出结构的和逻辑的替换和改变。因此,该具体实施方式不是在限制性的意义上进行的,并且各个方面的范围仅由所附权利要求书以及此类权利要求书所授权的等效方案完整范围来限定。
可在本文中单独地和/或共同地引用发明性主题的此类方面,如果实际上公开了多于一个方面或发明性概念,则这仅仅是为方便起见而并不旨在主动将本申请的范围限于任何单个方面或发明性概念。由此,虽然在本文中已经图示并描述了特定方面,但应当领会,预计能够实现相同目的的任何布置可替换所示的特定方面。本公开旨在涵盖各个方面的任何和全部修改或变体。在回顾以上描述时,以上各方面和本文中未具体描述的其他方面的组合就对于本领域内技术人员而言将是显而易见的。

Claims (39)

1.一种获得用于网络拥塞控制标识和用于迁移应用任务的网络相关信息的方法,所述方法包括:
在由移动设备操作的客户端侧应用“app”处接收来自由MEC服务器操作的多接入边缘计算“MEC”app的网络相关信息;以及
由所述客户端app基于所接收到的网络相关信息来适配一个或多个网络参数;或者
由所述客户端app基于所述网络相关信息向所述MEC服务器迁移一个或多个app任务。
2.如权利要求1所述的方法,其特征在于,传输协议被用于在所述客户端app与所述MECapp之间传输通信量,所述客户端app是传输协议运行时“TPR”实体,所述网络相关信息包括容量和连接相关信息,所述一个或多个网络参数是传输协议参数,并且所述适配包括:
基于所述容量和连接相关信息来适配所述传输协议参数。
3.如权利要求2所述的方法,其特征在于,所述MEC app包括被布置用于与所述TPR实体以及被包括在所述MEC app中或被包括在由所述MEC服务器操作的另一MEC app中的服务器app交互的另一TPR实体。
4.如权利要求2-3所述的方法,进一步包括:
由所述TPR检测触发事件;
经由RNI应用编程接口“API”将请求消息传送到由所述MEC服务器提供的无线电网络信息“RNI”服务,以及
所述接收包括经由所述RNI API从所述RNI服务接收所述容量和连接相关信息。
5.如权利要求4所述的方法,进一步包括:
经由位置API将请求消息传送到由所述MEC服务器提供的位置服务,以及
经由所述位置API从所述位置服务接收所述移动设备的位置信息。
6.如权利要求2-3所述的方法,其特征在于,当所述客户端app已经订阅由所述MEC服务器提供的RNI服务时,所述接收包括:
当所述MEC app检测到触发事件时,经由RNI API从所述RNI服务接收所述容量和连接相关信息。
7.如权利要求4-6所述的方法,进一步包括:
由所述TPR基于所述容量和连接相关信息将所述触发事件分类为拥塞事件或非拥塞事件。
8.如权利要求7所述的方法,其特征在于,当所述触发事件被分类为拥塞事件时,所述适配包括以下各项中的一项或两项:
由所述TPR减小拥塞窗口(CW);或者
实现拥塞控制算法。
9.如权利要求7-8所述的方法,其特征在于,当所述触发事件被分类为非拥塞事件时,所述适配包括:
在不减小所述CW的情况下停止传输。
10.如权利要求7-9所述的方法,其特征在于,所述拥塞事件是消息超时或对重复的确认的接收,而所述非拥塞事件是处于或低于阈值的信号强度测量或者处于或低于另一阈值的信道质量测量。
11.如权利要求4-10所述的方法,进一步包括:
基于所述客户端app的性能要求来选择交互模式,其中所述交互模式是请求/响应模式或发布/订阅模式。
12.如权利要求11所述的方法,其特征在于,所述客户端app的所述性能要求包括服务可靠性要求、端到端等待时间要求、服务质量(QoS)要求、订阅要求或限制、用户装备(UE)类型和/或其他度量。
13.如权利要求1所述的方法,其特征在于,所述客户端app是经扩展的提前服务质量通知(“e-IQN”)消费者,所述网络相关信息包括e-IQN属性,并且所述接收包括:
从e-IQN生产者接收e-IQN响应消息。
14.如权利要求13所述的方法,进一步包括:
向所述e-IQN生产者发送包括经规划的路线的e-IQN请求,所述经规划的路线包括沿着所述经规划的路线的一个或多个航点以及所述一个或多个航点中的每个航点的对应预期到达时间,其中所述e-IQN响应基于所述e-IQN请求。
15.如权利要求13-14所述的方法,其特征在于,所述e-IQN属性包括每个航点在所述对应预期到达时间的预测无线电状况。
16.如权利要求15所述的方法,其特征在于,所述e-IQN属性进一步包括在所述对应预期到达时间为每个航点服务的边缘计算节点的预测计算资源。
17.一种用于提供提前服务质量通知“e-IQN”通知的方法,所述方法包括:
由e-IQN生产者接收来自e-IQN消费者的第一e-IQN请求,所述第一e-IQN请求包括沿经规划的路线的一个或多个航点以及所述一个或多个航点中的每个航点的对应预期到达时间;
向预测性功能(PF)发送包括所述一个或多个航点和所述对应预期到达时间的第二e-IQN请求;
从所述PF接收e-IQN属性,所述e-IQN属性包括每个航点在所述对应预期到达时间的预测参数;以及
向所述e-IQN消费者发送包括所述e-IQN属性的e-IQN响应。
18.如权利要求17所述的方法,其特征在于,所述PF是无线电接入网“RAN”PF,并且所述预测参数是每个航点在所述对应预期到达时间的预测无线电状况。
19.如权利要求17所述的方法,其特征在于,所述PF是云PF,并且所述预测参数是每个航点处或附近的一个或多个边缘计算节点部署区域在所述对应预期到达时间的预测边缘计算资源。
20.如权利要求17所述的方法,其特征在于,所述PF是RAN PF,所述e-IQN属性是第一e-IQN属性,所述预测参数是第一预测参数,并且所述方法进一步包括:
向云PF发送包括所述一个或多个航点以及所述对应预期到达时间的第三e-IQN请求;以及
从所述云PF接收第二e-IQN属性,所述第二e-IQN属性包括每个航点在所述对应预期到达时间的第二预测参数。
21.如权利要求20所述的方法,其特征在于,所述第一预测参数是每个航点在所述对应预期到达时间的预测无线电状况,而所述第二预测参数是每个航点在所述对应预期到达时间的预测边缘计算资源,并且所述方法进一步包括:
通过将所述第一预测参数和所述第二预测参数进行级联来生成所述e-IQN响应。
22.如权利要求18-21所述的方法,其特征在于,所述eIQN消费者是第一eIQN消费者,所述e-IQN请求是第一e-IQN请求,并且所述方法进一步包括:
从第二eIQN消费者接收包括边缘服务部署地理位置和感兴趣的时间的第二e-IQN请求;以及
向云PF发送另一第二e-IQN请求。
23.如权利要求17-22所述的方法,其特征在于,所述第一e-IQN请求包括路线数据元素,所述路线数据元素包括每个航点的路线信息(routeInfo)数据元素,并且所述每个航点的routeInfo数据元素包括位置数据元素和时间数据元素,所述位置数据元素包括对应航点的位置信息,所述时间数据元素包括预期到达时间的时间戳。
24.如权利要求23所述的方法,其特征在于,所述e-IQN响应包括另一路线数据元素,所述另一个路线数据元素包括每个航点的另一routeInfo数据元素,并且每个航点的所述另一routeInfo数据元素包括位置数据元素,包括参考信号接收功率数据元素和参考信号接收质量数据元素,所述参考信号接收功率数据元素包括所述对应航点的预测rsrp值,所述参考信号接收质量数据元素包括所述对应航点的预测rsrq值。
25.如权利要求24所述的方法,其特征在于,每个航点的所述另一routeInfo数据元素进一步包括以下各项中的一项或多项:
可用处理器功率数据元素,包括最接近所述对应航点的边缘计算节点的可用处理功率;
可用存储器数据元素,包括最接近所述对应航点的所述边缘计算节点的可用存储器资源量;以及
可用存储数据元素,包括最接近所述对应航点的所述边缘计算节点的可用存储资源量。
26.一种或多种计算机可读介质,包括指令,其中,由处理器电路系统对所述指令的执行用于使所述处理器电路系统执行如权利要求1-16中任一项或权利要求17-25中任一项所述的方法。
27.一种计算机程序,包括如权利要求26所述的指令。
28.一种应用编程接口,所述应用编程接口定义用于如权利要求27所述的计算机程序的函数、方法、变量、数据结构和/或协议。
29.一种装置,包括加载有如权利要求26所述的指令的电路系统。
30.一种装置,包括可操作用于运行如权利要求26所述的指令的电路系统。
31.一种集成电路,包括以下中的一项或多项:如权利要求26所述的处理器电路系统;以及如权利要求26所述的一种或多种计算机可读介质。
32.一种计算系统,包括如权利要求26所述的一种或多种计算机可读介质以及处理器电路系统。
33.一种设备,包括用于执行如权利要求26所述的指令的装置。
34.一种作为执行如权利要求26所述的指令的结果而生成的信号。
35.一种作为执行如权利要求26所述的指令的结果而生成的数据单元。
36.如权利要求35所述的数据单元,其特征在于,所述数据单元是数据报、网络分组、数据帧、数据段、协议数据单元(PDU)、服务数据单元(SDU)、消息或数据库对象。
37.一种利用如权利要求35或36所述的数据单元编码的信号。
38.一种携载如权利要求26所述的指令的电磁信号。
39.一种设备,包括用于执行如权利要求1-16中任一项或权利要求17-25中任何一项所述的方法的装置。
CN202080064536.3A 2019-10-04 2020-09-25 用于传输层拥塞控制和基于扩展的提前服务质量通知的存在点优化的边缘计算技术 Pending CN114402640A (zh)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201962911048P 2019-10-04 2019-10-04
US62/911,048 2019-10-04
US202063047752P 2020-07-02 2020-07-02
US63/047,752 2020-07-02
PCT/US2020/052888 WO2021067140A1 (en) 2019-10-04 2020-09-25 Edge computing technologies for transport layer congestion control and point-of-presence optimizations based on extended in-advance quality of service notifications

Publications (1)

Publication Number Publication Date
CN114402640A true CN114402640A (zh) 2022-04-26

Family

ID=75338527

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202080064536.3A Pending CN114402640A (zh) 2019-10-04 2020-09-25 用于传输层拥塞控制和基于扩展的提前服务质量通知的存在点优化的边缘计算技术

Country Status (4)

Country Link
US (1) US20220353732A1 (zh)
CN (1) CN114402640A (zh)
DE (1) DE112020004736T5 (zh)
WO (1) WO2021067140A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114826826A (zh) * 2022-04-28 2022-07-29 北京金山云网络技术有限公司 网络拥塞信息传输方法、装置、公有云网络和电子设备
WO2024007311A1 (en) * 2022-07-08 2024-01-11 Huawei Technologies Co., Ltd. Context aware quality-of-service sustainability analytics

Families Citing this family (47)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11625806B2 (en) * 2019-01-23 2023-04-11 Qualcomm Incorporated Methods and apparatus for standardized APIs for split rendering
US11709698B2 (en) 2019-11-04 2023-07-25 Vmware, Inc. Multi-site virtual infrastructure orchestration of network service in hybrid cloud environments
US11640315B2 (en) * 2019-11-04 2023-05-02 Vmware, Inc. Multi-site virtual infrastructure orchestration of network service in hybrid cloud environments
WO2021140267A1 (en) * 2020-01-07 2021-07-15 Nokia Technologies Oy Apparatus, method and computer program
DE102020204864B4 (de) * 2020-04-16 2021-12-23 Continental Teves Ag & Co. Ohg Elastischer transfer und adaption von mobil-client-gesteuerten prozessen in einer edge-cloud-computing-schicht
US20240167819A1 (en) 2020-06-17 2024-05-23 Astra Navigation, Inc. Correlating Overlapping Magnetic Measurement Data from Multiple Magnetic Navigation Devices and Updating a Geomagnetic Map with that Data
US20210396524A1 (en) * 2020-06-17 2021-12-23 Astra Navigation, Inc. Generating a Geomagnetic Map
US11184517B1 (en) * 2020-06-26 2021-11-23 At&T Intellectual Property I, L.P. Facilitation of collaborative camera field of view mapping
KR20220023471A (ko) * 2020-08-21 2022-03-02 에스케이텔레콤 주식회사 엣지 통합 제어장치 및 엣지 통합 제어장치의 동작 방법
IL302212A (en) * 2020-10-20 2023-06-01 L3Vel Llc EDGE computing platform based on wireless network architecture
US20220141641A1 (en) * 2020-10-29 2022-05-05 Tracfone Wireless, Inc. System and Process for Configuring a Dynamic Roaming Public Land Mobile Network (PLMN)
US11356867B1 (en) * 2020-11-20 2022-06-07 Verizon Patent And Licensing Inc. MEC integration with RAN facilities
US20220219731A1 (en) * 2021-01-14 2022-07-14 Cavh Llc Intelligent information conversion for automatic driving
US11477719B1 (en) * 2021-03-05 2022-10-18 Sprint Communications Company L.P. Wireless communication service responsive to an artificial intelligence (AI) network
EP4053698A1 (en) * 2021-03-05 2022-09-07 Siemens Aktiengesellschaft On-demand edge-network deployment by industrial equipment
CN115079935A (zh) * 2021-03-15 2022-09-20 伊姆西Ip控股有限责任公司 用于存储和查询数据的方法、电子设备和计算机程序产品
KR20230164017A (ko) * 2021-04-09 2023-12-01 삼성전자주식회사 네트워크에서 애플리케이션 서비스들을 모니터링하기 위한 방법 및 시스템
CN113238814B (zh) * 2021-05-11 2022-07-15 燕山大学 基于多用户和分类任务的mec任务卸载系统及优化方法
CN115412930A (zh) * 2021-05-26 2022-11-29 维沃移动通信有限公司 策略生成方法、装置、终端、设备及会话管理单元
EP4106275A1 (en) * 2021-06-18 2022-12-21 Rohde & Schwarz GmbH & Co. KG Jitter determination method, jitter determination module, and packet-based data stream receiver
WO2022266999A1 (en) * 2021-06-25 2022-12-29 Intel Corporation Digital edge services orchestration of awareness, on-demand, and event-triggered services
IT202100017540A1 (it) * 2021-07-02 2023-01-02 Pagano S P A Sistema di sicurezza delle utenze stradali basato su informazioni in tempo reale
US11844164B2 (en) * 2021-07-19 2023-12-12 Spireworks Llc Edge-based system architecture for building-scale interactive lighting
CN113612843B (zh) * 2021-08-02 2022-08-30 吉林大学 一种基于深度强化学习的mec任务卸载和资源分配方法
US11895504B2 (en) * 2021-09-03 2024-02-06 Cisco Technology, Inc. Federated multi-access edge computing availability notifications
EP4164194A1 (en) * 2021-10-06 2023-04-12 Robert Bosch GmbH Methods and apparatuses for radio communication
US11917283B2 (en) * 2021-10-27 2024-02-27 Tencent America LLC Split rendering for lightfield/immersive media using edge-cloud architecture and peer-to-peer streaming
GB202117853D0 (en) * 2021-12-10 2022-01-26 British Telecomm Service provision
WO2023134880A1 (en) * 2022-01-12 2023-07-20 NEC Laboratories Europe GmbH Connectivity-aware robot optimization in mec-enabled scenarios
EP4216504A1 (en) * 2022-01-21 2023-07-26 Deutsche Telekom AG Method for predicatively operating a communication network
US11968606B2 (en) 2022-02-14 2024-04-23 Ford Global Technologies, Llc Cloud-based vehicle communication manager
CN114253552B (zh) * 2022-02-25 2022-07-12 浙江大云物联科技有限公司 可编程的边缘设备自适配方法和装置
TWI807717B (zh) * 2022-03-23 2023-07-01 中華電信股份有限公司 網路控制系統、方法及電腦可讀媒介
EP4262269A1 (en) * 2022-04-14 2023-10-18 Mitsubishi Electric R&D Centre Europe B.V. Ursp update in border scenario
WO2023218270A1 (en) * 2022-05-13 2023-11-16 Telefonaktiebolaget Lm Ericsson (Publ) System for adjusting a physical route based on real-time connectivity data
WO2023218271A1 (en) * 2022-05-13 2023-11-16 Telefonaktiebolaget Lm Ericsson (Publ) Adjusting a physical route based on real-time connectivity data
WO2024025870A1 (en) * 2022-07-26 2024-02-01 Apple Inc. Architecture framework for ubiquitous computing
US11570627B1 (en) 2022-08-02 2023-01-31 Digital Global Systems, Inc. System, method, and apparatus for providing optimized network resources
US11751064B1 (en) 2022-08-02 2023-09-05 Digital Global Systems, Inc. System, method, and apparatus for providing optimized network resources
US11843953B1 (en) 2022-08-02 2023-12-12 Digital Global Systems, Inc. System, method, and apparatus for providing optimized network resources
US11711726B1 (en) 2022-08-02 2023-07-25 Digital Global Systems, Inc. System, method, and apparatus for providing optimized network resources
US11792088B1 (en) * 2022-09-02 2023-10-17 Microsoft Technology Licensing, Llc Network management engine for a cloud computing system
CN116032969B (zh) * 2023-01-05 2024-02-20 昆明理工大学 一种云边协同的智能数控车间自调控系统、控制方法
CN116560839B (zh) * 2023-05-06 2023-11-10 湖南师范大学 一种基于主从博弈的边缘计算任务卸载方法和系统
CN116225667B (zh) * 2023-05-08 2023-08-01 中国科学院空天信息创新研究院 面向高轨多星定位的实时流式并行调度处理系统
CN116744368B (zh) * 2023-07-03 2024-01-23 北京理工大学 基于云边端架构的智能协同异构空地无人系统及实现方法
CN117098255B (zh) * 2023-10-19 2023-12-15 南京波达电子科技有限公司 一种基于边缘计算的去中心化雷达自组网方法

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111367187B (zh) * 2015-08-27 2023-10-24 江森自控泰科知识产权控股有限责任公司 用于改进对分布式网络中的传感器流数据的处理的方法
KR102203324B1 (ko) * 2015-10-16 2021-01-14 에스케이텔레콤 주식회사 네트워크 환경에서 서비스 기반의 모바일 엣지 컴퓨팅 제어방법 및 장치
US10929189B2 (en) * 2015-10-21 2021-02-23 Intel Corporation Mobile edge compute dynamic acceleration assignment

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114826826A (zh) * 2022-04-28 2022-07-29 北京金山云网络技术有限公司 网络拥塞信息传输方法、装置、公有云网络和电子设备
WO2024007311A1 (en) * 2022-07-08 2024-01-11 Huawei Technologies Co., Ltd. Context aware quality-of-service sustainability analytics

Also Published As

Publication number Publication date
DE112020004736T5 (de) 2022-07-07
US20220353732A1 (en) 2022-11-03
WO2021067140A1 (en) 2021-04-08

Similar Documents

Publication Publication Date Title
US20220353732A1 (en) Edge computing technologies for transport layer congestion control and point-of-presence optimizations based on extended inadvance quality of service notifications
US20230074288A1 (en) V2x services for providing journey-specific qos predictions
US11234204B2 (en) Server selection for vehicle communications and applications
US20220038554A1 (en) Edge computing local breakout
US11700628B2 (en) Multi-slice support for MEC-enabled 5G deployments
US11218553B2 (en) Inter-MEC system communication for V2X services
US11711284B2 (en) Link performance prediction technologies
US11627444B2 (en) Vehicle-to-everything session and service continuity in automotive edge computing systems
US20230022620A1 (en) QUALITY OF SERVICE (QoS) MANAGEMENT IN EDGE COMPUTING ENVIRONMENTS
US11540355B2 (en) MEC-based distributed computing environment with multiple edge hosts and user devices
US11650851B2 (en) Edge server CPU with dynamic deterministic scaling
US20220103614A1 (en) 5g network edge and core service dimensioning
US20220110018A1 (en) Intelligent transport system congestion and multi-channel control
US20200008044A1 (en) Multi-access edge computing service for mobile user equipment method and apparatus
US11792616B2 (en) Distributed network allocation vector management for enabling vehicle-to-everything radio access technology coexistence
KR20220044938A (ko) 링크 성능 예측 및 미디어 스트리밍 기술들
US20230072769A1 (en) Multi-radio access technology traffic management
CN115119331A (zh) 用于多接入通信量管理的强化学习
US20220248296A1 (en) Managing session continuity for edge services in multi-access environments
US20220124043A1 (en) Multi-access management service enhancements for quality of service and time sensitive applications
US20220167262A1 (en) Server selection for vehicle communications and applications
EP3970408A1 (en) Technologies for control and management of multiple traffic steering services
US20220124548A1 (en) Technologies for network path and topology management
US20230362683A1 (en) Operator platform instance for mec federation to support network-as-a-service
US20230370416A1 (en) Exposure of ue id and related service continuity with ue and service mobility

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination