CN112738772A - 物联网端对端服务层服务质量管理 - Google Patents

Abstract

本公开涉及物联网端对端服务层服务质量管理。方法、系统、和设备可以通过使用服务层SL会话来支持端对E2E服务质量QoS。示例性系统支持用于以端对端方式管理QoS的机制。系统支持需要应用指定按需E2E QoS要求的使用案例。系统包括经由局域和广域底层网络的不同组合彼此互连的物联网IoT服务器、IoT网关和设备。在服务器和网关上托管的是IoT SLs的实例。在现场中的装置上托管以及后端中的装置是相互通信的IoT应用。系统还包括服务层连接管理器SLCM功能，应用连接管理器ACM功能和底层网络连接管理器UNCM功能。SLCM、ACM和UNCM功能一起彼此交互，以更智能地管理和配置支持E2E QoS中的应用、服务器、网关和IoT装置的连接性和端对端底层网络QoS。

Description

物联网端对端服务层服务质量管理

本申请是国际申请日为2016年8月4日、国家申请号为201680056285.8、发明名称为“物联网端对端服务层服务质量管理”的进入中国国家阶段的PCT申请的分案申请。

相关申请的交叉引用

本申请要求于2015年8月4日提交的标题为“物联网端对端服务层服务质量管理(Internet of Things End-to-End Service Layer Quality of Service Management)”的美国临时专利申请第62/200,752号的权益，该申请的内容通过引用并入本文。

背景技术

M2M/IoT SL

M2M/IoT服务层(SL)是专门针对为M2M/IoT装置和应用提供增值服务的技术。近来，若干行业标准机构(例如，oneM2M功能架构-V-1.6.1和ETSI TS 102 690机器对机器通信(M2M)功能架构V2.0.13)一直在开发M2M/IoT SLs来解决与将M2M/IoT装置和应用集成到具有互联网/Web、蜂窝、企业、和家庭网络的部署所面临的挑战。

机器对机器/物联网(M2M/IoT)服务层(SL)可以提供对面向M2M/IoT的能力的集合的访问。一些示例能力包括安全、计费、数据管理、装置管理、发现、供应和连接性管理。参见oneM2M-TS-0001，oneM2M功能架构-V-1.6.1，其通过引用全部并入本文。经由利用由M2M/IoT SL支持的消息格式、资源结构和资源表示的应用编程接口(API)，这些能力可以使应用是可用的。

图1图示了可以支持服务层的示例性协议栈。从协议栈的角度来看，SL 101可以位于应用协议层102和下面的应用层103的上方，并且可以向支持的应用提供增值服务。SL101可以被归类为“中间件”服务。

会话

通信会话通常涉及在两个或更多个通信实体(例如，装置、应用等)之间的信息的持续互动交换。通信会话在某个时间点建立，并且基于各种情况(例如，在会话超时之后或者当实体中的一个决定终止会话时)在稍后的时间点处拆除。通信会话可能涉及实体之间的多条消息的交换并且可以是有状态的。有状态可以意旨通信实体中的至少一个保存了关于会话历史的信息，以便能够维持通信会话(例如，适用于会话参与者的连接性、注册、安全、日程、和数据)。可以将通信会话实现为在网络协议栈中的不同层处的协议和服务的部分。作为示例，图2图示了在网络节点104与网络节点105之间建立的通信会话。前面提到的网络节点104和105的通信会话可以是基于传输协议层110(例如，TCP连接)、会话协议层109(例如，TLS和DTLS会话)、web传输协议层108(例如，HTTP和CoAP会话)、M2M/IoT SL107(例如，oneM2M会话)和专用会话106。

传统应用会话是在两个或更多个应用之间的通信会话，该通信会话由应用本身而不是由底层通信协议(underlying communication protocol)或者服务层建立和管理。因此，应用会话能够将额外的开销和复杂性添加到应用。例如，传统应用会话可能需要应用本身来配置、建立、并管理会话。这能够涉及创建和管理会话上下文(session context)，诸如，证书(credentials)、标识符、路由信息、发现信息、位置、交易历史和数据。

M2M/IoT SL会话是通过由SL支持的增值会话管理服务促成的通信会话。这些服务能够包括诸如用于在SL端点之间建立SL会话并且收集和维持与SL会话及其端点相关的上下文的机制的能力。可以在两个或更多个SL会话端点之间建立SL会话，其中，这些端点可以是应用或者SL实例。然而，在最低程度上，SL的至少一个实例必须参与会话以充当SL会话的促进者(即，提供必要的SL会话管理功能)。“SL实例”可以被认为是服务层(例如，在装置上托管的服务层)的单个实例化。“SL会话”是SL与应用之间的通信会话。SL能够支持多个同时进行的SL会话。

图3图示了M2M/IoT SL会话的示例。在第一示例中，在112中，在单个应用与SL实例之间建立SL会话。这是0-跳SL会话的示例，因为它不横跨SL实例。在113中，第二示例示出了在两个SL实例之间建立的SL会话。这是0-跳SL会话的另一个示例。在114中，第三示例示出了在横跨公共SL实例117的两个应用之间建立的SL会话，因此，这是1-跳SL会话的示例。在115中，第四示例示出了在横跨两个SL实例(SL实例116和SL实例117)的三个应用之间建立的M2M SL会话并且是2-跳SL会话的示例。

M2M/IoT SL会话的一个益处是能够使用这些M2M/IoT SL会话来使应用卸载必须建立和维持其自身的基于应用的会话的负担。这是因为SL会话与应用会话的不同在于，将建立并且维持会话所涉及的开销的冲击卸载到SL，使得应用不再负担这个责任。可以卸载到SL的开销的一些示例能够包括会话上下文(诸如，证书、标识符、路由信息、发现信息、位置、交易历史、和数据)的创建和管理。

SL会话可以被分层在一个或多个底层传输或访问网络通信会话(在本文中也可以称为连接)的顶部上。一些示例可以包括web传输协议会话(例如，HTTP会话)、会话层会话(例如，传输层会话(TLS))、传输层连接(例如，传输控制协议(TCP))、底层访问网络连接(例如，3GPP、宽带以太网、Wi-Fi、蓝牙)。这种分层允许SL会话支持关于低层会话的持续性，使得SL会话能够持续并且独立于低层会话的建立和拆除来维持该SL会话。例如，尽管SL会话的底层TCP或TLS会话被重复建立和拆除，这种重复建立和拆除在正常的网络通信过程(例如，由于省电方法和移动性)期间是相当典型的，但是SL会话能够持续。

在会话参与者之间建立M2M/IoT SL会话可以作为SL注册过程的部分或者作为其后的单独过程而发起。一旦建立，可以使用SL会话来收集并且维持与会话参与者和在这些会话参与者之间发生的通信相关的SL上下文。例如，可以为每个会话收集并且维持SL会话上下文，诸如会话参与者的注册状态和安全证书、用于会话参与者的订阅标准和联系信息、在SL资源中存储的会话参与者数据、由会话参与者执行的交易的历史。终止在会话参与者之间的SL会话可以作为SL注销过程的部分或者作为在注销发生之前执行的单独过程而发起。

值得注意的一点的是，SL会话的建立以及SL会话上下文在特定SL会话的有效期期间的积累可能涉及会话参与者大量的时间和精力。因此，与缺乏这种持续性的低层传输和访问网络会话进行比较，SL会话的持续性质是其主要的增值微分器中的一个。代表应用，可以使用持续的SL会话来维持SL会话上下文，使得应用本身不必维持该信息。另外，在拆除低层会话时，SL会话上下文可以持续，并且在重新建立低层连接时，该上下文仍可用于应用。因此，能够独立于非持续的底层传输会话或者访问网络连接来维持该上下文。SL会话上下文的一些示例可以包括用于应用的SL注册、订阅、证书、标识符、计费记录、路由信息、发现信息、位置、交易历史和数据。

oneM2M SL架构

正在开发的oneM2M标准(oneM2M功能架构)限定了称为公共服务实体(CSE)的服务层，如图4所示。Mca参考点与应用实体(AE)接口连接。Mcc参考点与相同的服务提供商域内的另一个CSE接口连接并且Mcc’参考点与不同的服务提供商域中的另一个CSE接口连接。Mcn参考点与底层网络服务实体(NSE)接口连接。NSE向CSEs提供底层网络服务，诸如，装置管理、位置服务和装置触发。CSE包含称为“公共服务功能(CSFs)”的多个逻辑功能，诸如“发现”或者“数据管理&储存库”。图5图示了oneM2M的示例CSFs。

oneM2M架构实现了应用服务节点(ASN)、应用专用节点(ADN)、中间节点(MN)和基础设施节点(IN)。ASN是包含一个CSE并且包含至少一个AE的节点。物理映射的示例是在M2M装置中驻留的ASN。ADN是包含至少一个AE并且不包含CSE的节点。物理映射的示例是在受限的M2M装置中驻留的ADN。MN是包含一个CSE并且包含零个或多个AEs的节点。用于MN的物理映射的示例是在M2M网关中驻留的MN。IN是包含一个CSE并且包含零个或多个AEs的节点。用于IN的物理映射的示例是在M2M服务基础设施中驻留的IN。还可能存在非oneM2M节点，该非oneM2M节点是不包含oneM2M实体(既不包含AEs也不包含CSEs)的节点。这种节点表示附接到oneM2M系统出于互连(包括管理)目的的装置。在图6中图示了使在oneM2M系统内支持的各个实体互相连接的可能的配置。

oneM2M在2014年8月的TS-0001的oneM2M功能架构版本1.1.0中已经限定了服务层会话管理服务(例如，SSM CSF 119)，如图5所示。oneM2M还将SL会话限定为由SSM CSF管理的端对端SL连接。oneM2M还限定了SSM CSF的一些要求，然而，它尚未限定了满足这些要求的架构或设计。例如，oneM2M规定会话管理服务应当支持以下特征：

1)SSM CSF应当支持在AEs之间、在AEs与CSE之间、或者在CSEs之间建立SL会话的请求。

2)SSM CSF应当支持跨多个CSE跳的SL会话。

3)在授予用于建立SL会话的请求之前，SSM CSF应当首先使用预先建立的证书来对请求者进行认证。

4)SSM CSF应当使用SEC CSF来支持端对端认证。一旦通过认证，SSM CSF就应当在该请求与目标会话端点之间建立M2M SL。

5)SSM CSF应当将会话ID返回给请求者。

6)SSM CSF还应当维持用于会话的管理的附加会话信息，诸如，会话策略、会话路由信息、会话描述符等。

7)SSM CSF应当支持终止AEs之间、AE与CSE之间、或者CSEs之间的SL会话的请求。

8)SSM CSF应当将SL会话的分层支持在底层网络(UN)连接的顶部上方并且SSMCSF相对于底层网络连接的持续性应当支持SL会话。

9)SSM CSF应当独立于底层网络连接的状态来维持活动的SL会话并且对于动态地拆除并重新建立的网络连接来说应当是鲁棒性的。

10)SSM CSF应当支持向其他CSFs和/或底层网络发起或提供关于应当是否基于SL会话活动或状态来拆除/重新建立网络连接的输入。

oneM2M尚未限定了SSM CSF的功能来支持上文限定的要求。通常，所提出的实现方式(已经提交，作为对oneM2M的贡献)重点在于限定了SSM资源定义和程序以支持上文的要求1至7。图7图示了用于oneM2M SL会话管理的示例资源结构。<session>资源包含用于管理单个SL会话的属性和子资源。

oneM2M限定了能够用于存储用于有限的一组父资源类型(包括CSEBase、remoteCSE、subscription或者cmdhNwAccessRules)的日程信息的schedule子资源类型。因此，oneM2M支持以下类型的日程：

1)CSE能够通过支持在其CSEBase或remoteCSE父资源下的schedule子资源来限定了其可达性日程。这样，CSE能够声明可用于发送或接收SL请求的次数。

2)CSE资源的订阅者(例如，应用)能够限定了控制在CSE向其发送通知时的次数的通知日程。订阅者能够通过在subscription资源下创建schedule子资源来做到这一点。

3)CSE能够支持在CSE能够访问特定底层访问网络时限定的访问网络日程。通过在<cmdhNwAccessRules>资源下创建<schedule>子资源来做到此。

oneM2M schedule资源支持scheduleEntry属性。该属性限定了使用由表格1中所示的6个用逗号隔开的字段组成的字符串来编排的日程。每个字段都可以是星号“*”(指示其匹配任何值)、数字(指示其匹配特定值)、或者用连字符“-”隔开的两个数字(指示其匹配某个范围的值)。

例如，具有字符串值“0-30,30,12,1,*,*”的scheduleEntry被转换成其中秒具有“0-30”的值、分为“30”的值、小时为“12”的值、一个月中的一天为“1”的值、一年中的一个月为“*”的值、并且一周中的一天为“*”的值的日程。例如，如果该scheduleEntry被用于subscription日程，那么会导致CSE仅在每个月的第一天从12:30开始向订阅者发送相应通知并且该窗口仅维持30秒。在所有其他时间期间，CSE会缓冲通知，等待下一个订阅日程窗口开始。

表格1：scheduleEntry字符串格式的定义

字段名称	值的范围	注解
			秒	0至59
分	0至59
			小时	0至23
一个月中的一天	1至31
			一年中的一个月	1至12
一周中的一天	0至6	0表示星期日

3GPP服务能力暴露功能(SCEF)

图8图示了示例性的基于3GPP服务能力暴露功能(SCEF)的系统架构。3GPP最近限定了框架以向应用/服务提供商更好地暴露底层3GPP网络能力。参见并入本文的3GPP TS23.682的促进与分组数据网络和应用的通信的架构增强V13.0.0。为此，3GPP已经限定了SCEF。SCEF功能提供了一种用于安全地暴露由3GPP网络提供的服务和能力的方式。SCEF提供了一种用于发现所暴露的服务能力的方式。SCEF通过由OMA、GSMA、和其他可能的标准化机构限定的同构网络应用编程接口(例如，网络API)来提供对网络能力的访问。SCEF从底层3GPP网络接口和协议提取服务。

发明内容

本文公开了使应用能够以满足目标M2M/IoT装置的E2E QoS要求的方式来执行与其端对端通信的方法、系统和设备。例如，应用能够基于应用指定的日程、延迟、抖动、错误率、吞吐量、安全级别和成本要求来与目标装置通信。

具体地，本公开限定了以下方面。第一，一种用于M2M/IoT E2E SL QoS管理的系统，该系统支持用于允许应用建立、使用和拆除M2M/IoT SL通信会话(session)的方法/程序，该通信会话具有应用指定的QoS偏好并且以一个或多个SL可寻址目标(例如，M2M/IoT应用、装置、或者网关SL可寻址资源)为目标。

第二，用于允许M2M/IoT SL与底层网络交互以基于应用指定的E2E QoS偏好来配置、选择、和/或影响底层网络QoS级别的基于E2E SL会话的方法/程序。可以由服务层用由应用指定的服务质量要求来配置底层传输网络(使两个服务层节点互相连接)。

第三，用于允许UN与M2M/IoT SL共享UN QoS和与连接性相关的信息的方法/程序，使得SLs能够对以不同的E2E SL会话使用哪些UNs做出明智决定。

第四，用于允许M2M/IoT SL实例协调横跨多个底层网络技术和/或运营商的多跳通信路径的E2E QoS的基于E2E SL会话的方法/程序。其中，这些方法涉及协调多个SL实例和应用的E2E可达性日程，规划跨多个底层网络跳的延迟和抖动，以及确保最小吞吐量、目标成本、和还实现了所需的安全级别。

第五，对能够在SL实例、应用、和UNs之间交换的E2E SL会话QoS信息的定义，以使UN QoS参数(诸如，需要彼此通信的SL实体之间的连接性日程、吞吐量、延迟、抖动、成本、安全级别、和错误率)能够E2E对准。

第六，提出的M2M/IoT E2E SL QoS管理系统的系统级oneM2M和3GPP示例。

第七，提出的SLCM、ACM和UNCM功能的API级别示例。

附图说明

结合附图通过示例的方式给出的说明书可以从以下描述中得到更详细的理解，其中：

图1图示了支持服务层的示例性协议栈；

图2图示了示例性通信会话；

图3图示了示例性IoT SL会话；

图4图示了示例性oneM2M架构；

图5图示了示例性oneM2M公共服务功能；

图6图示了由oneM2M架构支持的示例性配置；

图7图示了用于oneM2M SL会话管理的示例性资源结构；

图8图示了示例性的基于3GPP SCEF的系统架构；

图9图示了示例性的端对端IoT装置通信使用案例；

图10图示了涉及不同访问网络的示例性端对端通信；

图11图示了用于管理E2E通信的QoS的示例性IoT系统；

图12图示了示例性的IoT E2E QoS管理程序；

图13图示了示例性的E2E SL会话QoS；

图14图示了用于在E2E SL会话建立期间管理UN QoS的示例性方法；

图15图示了用于在发送E2E SL会话消息的同时管理UN连接的示例性方法；

图16图示了用于在接收E2E SL会话消息的同时管理UN QoS的示例性方法；

图17图示了用于管理E2E SL会话拆除(Session Tear-Down)的示例性方法；

图18图示了示例性的oneM2M/3GPP E2E SL QoS管理系统；

图19图示了示例性的E2E SL会话QoS要求<session>属性；

图20图示了示例性的E2E SL会话QoS要求<sessionPolicy>属性；

图21图示了示例性的<UN>资源和属性；

图22图示了示例性的E2E SL会话QoS要求<pointOfAccess>属性；

图23图示了用于<AE>资源的示例性<pointOfAccess>子资源；

图24图示了用于<AE>资源的示例性<pointOfAccess>子资源；

图25图示了示例性的<UNCM>资源和属性；

图26图示了示例性<UNCMSession>资源；

图27图示了示例性IoT服务层开放流；

图28图示了示例性的E2E QoS图形用户界面；

图29图示了使用SL QoS相关组件生成的示例性显示；

图30A是其中可以实现IoT E2E服务层QoS管理事项的示例机器对机器(M2M)或者物联网(IoT)通信系统的系统图；

图30B是可以在图30A中图示的M2M/IoT通信系统内使用的示例架构的系统图；

图30C是可以在图30A图示的通信系统内使用的示例M2M/IoT终端或者网关装置的系统图；以及

图30D是其中可以实施图30A的通信系统的方面的示例计算系统的框图。

具体实施方式

本文公开了通过使用服务层(SL)会话来支持端对端(E2E)服务质量(QoS)的方法、系统和设备。

图9图示了其中应用可能需要跨广域网与特定M2M/IoT装置应用进行E2E通信的使用案例。可能存在经由第一底层网络122和第二底层网络124与患者监测应用124通信地连接的传感器121。根据应用的类型和装置的类型，该通信可能具有特定的E2E QoS要求。下文提供了示例。在第一示例场景中，医生与家庭患者监测服务签约以远程监测他的患者中的一个。该服务利用与位于患者身体上的传感器121(例如，可穿戴医用传感器)建立端对端通信会话的患者监测应用125。为了适当地监测该患者的状况，医生请求该服务每小时整点地获取来自传感器121的测量值(例如，患者的血糖水平)以适当地评估患者是否正在服用他的药物(例如，胰岛素)并且其是否具有期望的效果。如果检测到异常的测量值，则该服务可以相应地通知医生或者家属。

继续参照图9，与第一示例场景类似，在第二示例场景中，家庭患者监测服务可以用于远程监测第二患者。为了适当地监测该第二患者的状况，当检测到关键事件(例如，患者的脉氧达到临界阈值)时，医生可以请求用于可以从患者的传感器121生成的警报的服务监测。针对该特定患者，医生请求该服务确保：对于任何警报，从传感器121到监测应用125的端对端延迟具有小于5秒的延迟，使得该服务然后能够采取适当的行动。适当的行动可以包括通知医生或者紧急医疗服务。

继续参照图9，与第一示例场景类似，在第三示例场景中，由医生使用相同的家庭患者监测服务来远程监测第三患者。为了适当地监测该特定患者的状况，医生请求该服务经由视频监控来监测患者以检测并追踪患者的身体活动。针对第三患者，医生可以请求该服务确保：用实况视频溃源(feed)来完成监控，该实况视频溃源要求最低持续的端对端吞吐量为5Mbps。

引导在应用(可以是后台应用)与部署在现场的装置(例如，传感器121)之间的通信的M2M/IoT(在本文中可互换地称为M2M或者IoT)部署可能不是最好的实施方式。传感器121可能是资源受限的并且可能无法有效地支持其本身的广域网连接性。传感器121可能无法支持维持持续且活动的网络连接，这种持续且活动的网络连接能够导致资源限制(例如，电池)。由于这些原因，许多M2M/IoT装置依赖于M2M/IoT网关和服务器用于增值服务，诸如，向装置提供广域网连接性和数据存储服务使得可以在装置失去与网络的连接性时的时间段期间访问数据。因此，该E2E通信能够遍历还可以由不同的网络提供商(例如，斯普林特(Sprint)、威讯(Verizon)等)拥有的多种底层访问网络技术(例如，3GPP、宽带以太网、WiFi等)。本文公开了通过使用服务层(SL)会话来支持端对端(E2E)服务质量(QoS)的方法、系统和设备。在oneM2M规范的第一版本中，已经规定了以下以QoS为中心的要求，然而，在oneM2M架构或协议规范中尚未限定相应的解决方案：

·oneM2M系统应当支持将M2M应用的QoS偏好包括在对底层网络的服务请求中。

·oneM2M系统应当能够在服务级别处对具有QoS偏好的服务请求进行授权，但是应当将服务请求中的M2M应用的QoS偏好传递给底层网络以进行对服务QoS请求的授权和同意或者协商。

·oneM2M系统应当能够支持不同的QoS级别指定参数，诸如，保证的比特率、延迟、延迟变化、丢失率和错误率等。

·oneM2M系统应当能够接收并且利用由底层网络提供的关于能够何时到达M2M装置的信息。

·当可从底层网络得到时，oneM2M系统应当能够维持M2M装置的M2M服务操作状态并且当底层网络连接性服务状态改变时将其更新。

考虑到oneM2M规范的以QoS为中心的要求，QoS协议和IoT SL技术在支持如同参照图9讨论的那个使用案例的使用案例方面具有以下可能的缺点。第一个可能的缺点是：QoS协议(诸如，区分服务(DiffServ)和综合服务(IntServ))不适合于支持许多IoT网络部署内的E2E QoS管理。DiffServ和IntServ这两者需要网络路由器来维持针对每个通信流的状态。这种状态需要许多IoT路由器通常不需要可用的资源(例如，存储器、MIPS等)。DiffServ和IntServ这两者需要路由器之间的定期通信来共享并维持QoS相关的控制信息。这种额外的消息传递开销不适合于许多IoT网络。许多IoT网络涉及横跨不同类型的底层访问网络(例如，3GPP、宽带以太网、Wi-Fi、6LoWPAN等)的并且由不同的网络提供商操作的E2E通信路径。由于本文提到的原因，无法很好地配备一些网络来支持DiffServ和IntServ。DiffServ和IntServ部署通常能够根据彼此运营商网络而不同(例如，不同的路由器策略、对DiffServ和IntServ协议和特征的支持的不同级别)。因此，DiffServ和IntServ仅在各个运营商的网络内使用而不是跨运营商网络使用，这是常见的。最后，DiffServ和IntServ协议不支持诸如可达性日程等特征，这在许多IoT网络中至关重要，因为装置无法维持持续的网络连接性。

第二个可能的缺点是：传统IoT SL技术缺乏使应用允许限定满足应用使用案例的需要的E2E QoS要求(例如，日程、延迟、抖动、错误率、吞吐量、安全级别和成本)的方法。

第三个可能的缺点是：传统的IoT SL技术还缺乏用于适当地管理在多个底层网络上横跨的E2E通信的方法，这多个底层网络能够具有不同的技术类型(例如，3GPP和宽带以太网)或者由不同的网络运营商(例如，斯普林特(Sprint)和威讯(Verizon))拥有并且操作。

参照前面提到的缺点，图10图示了由横跨多个底层访问网络技术跳的、使装置与后台应用互相连接的E2E通信路径组成的典型IoT网络。例如，应用131与装置132之间的E2E通信涉及横跨三个不同的访问网络技术跳(hop)(例如，蜂窝141、宽带以太网142和Wi-Fi143)的通信。还示出了关于用于E2E通信的多个网络上的通信的类似示例，诸如，应用134与装置135之间的通信以及应用137与装置138之间的通信。

下文是与网络部署(如同图10中捕获的部署)相关的可能问题的示例。在第一示例中，传统IoT SL技术缺乏用于调整SL实例的可达性日程和它们到底层网络(UNs)的连接性日程，使得它们以逐跳方式以及以E2E方式彼此对准，以允许满足由应用限定的E2E可达性日程的能力。因此，能够发生SL实例之间的可达性日程方面的不对准。当发生这种情况时，诸如消息的存储和转发的动作能够在逐跳的基础上在SL实例中发生(例如，在IoT网关和服务器上)，同时它们等待通信路径中的下一跳以变得可达。原则上，如果存储和转发延迟防止了应用以每次其所需的可达性日程的E2E方式与IoT装置通信，则该存储和转发延迟仅是一个问题。

在第二示例中，传统IoT SL技术缺乏以管理并且调整UNs用于逐跳互连的通信延迟的能力。另外，它们还缺乏以对准它们的逐跳延迟，使得能够满足由应用限定的E2E延迟预算的能力。因此，对E2E延迟的管理是由当前IoT SL技术不支持的能力。这防止了应用以每次所需的延迟预算的E2E方式与IoT装置通信。

在第三示例中，传统IoT SL技术缺乏以管理并且调整它们用于的UNs的用于彼此逐跳互连的通信吞吐量的能力。另外，它们还缺乏以对准它们的逐跳吞吐量，使得能够满足由应用限定的E2E吞吐量的能力。因此，对E2E吞吐量的管理是由当前M2M/IoT SL技术不支持的能力。这防止了应用以每次所需的吞吐量的E2E方式与M2M/IoT装置通信。

在第四示例中，传统IoT SL技术缺乏以管理SL消息之间的E2E延迟变化(例如，抖动)的能力和依次以对准它们的逐跳抖动使得能够满足由应用限定的E2E抖动预算的能力。因此，对E2E抖动的管理是当前IoT SL技术不支持的能力。这防止了应用以每次所需的抖动预算的E2E方式与M2M/IoT装置通信。

在第五示例中，传统IoT SL技术缺乏以管理E2E消息传递错误率的能力。另外，它们还缺乏以管理它们的逐跳消息传递错误率，使得能够满足由应用限定的E2E错误率的能力。因此，对E2E消息传递错误率的管理是由当前M2M/IoT SL技术不支持的能力。这防止了应用以每次所需的消息传递错误率的E2E方式与M2M/IoT装置通信。

当应用与M2M/IoT装置之间的E2E通信路径横跨涉及不同类型的UNs的多个SL跳时以及当这些UNs由不同的网络运营商拥有/操作时，上文提到的问题会变得更有可能以及更复杂。这是由于跨不同UNs的、以E2E方式管理QoS需要跨不同的网络技术进行协调，管理这些不同的网络技术可能是具有挑战性的。类似地，跨不同运营商网络的、以E2E方式管理QoS需要跨这些运营商进行协调。随着SL跳、UNs、或者不同运营商的数目增大，使问题出现的可能性也会增大。

图11图示了支持用于以端对端方式管理QoS的机制的示例性系统150。系统150可以用于支持使用案例，诸如，需要应用156指定按需E2E QoS要求的使用案例。按需E2E QoS要求可以包括通信的可达性日程、E2E延迟、E2E吞吐量、E2E抖动、E2E错误率、E2E安全级别、或者E2E成本等。系统150包括经由局域UNs和广域UNs(例如，3GPP 161、宽带以太网162、Wi-Fi 163、或者6LoWPAN 164)的不同组合而彼此连接的IoT服务器(例如，IoT服务器152)、IoT网关(例如，IoT网关151)、和装置(例如，IoT现场装置153或者IoT装置154)。在服务器和网关上托管的是IoT SLs的实例(例如，IoT SL 166或者IoT SL 165)。彼此通信的IoT应用(例如，IoT装置应用155和IoT应用156)托管在现场的装置上以及后台的装置上。例如，患者的IoT传感器或者致动器与后台患者监测应用之间的E2E通信。

继续参照图11，系统150包括服务层连接管理器(SLCM)功能(例如，SLCM 157或者SLCM 158)、应用连接管理器(ACM)(例如，ACM 159或者ACM 160)功能和底层网络连接管理器(UNCM)功能(例如，UNCM 167、UNCM 168、或者UNCM 169)。SLCM、ACM、和UNCM功能可以彼此交互以更智能地管理并且配置在支持E2E QoS中的IoT装置、网关、服务器、和应用的端对端UN QoS和连接性。可替选地，系统可以仅支持这些功能的子集。例如，系统能够仅支持SLCM和UNCM功能，而不支持ACM功能。

SLCM功能可以被嵌入在IoT SL内，诸如，在IoT网关或者服务器平台上托管的oneM2M SL。在另一个示例中，UNCM功能可以被支持作为各种类型的底层访问网络技术(诸如，3GPP、蓝牙、Wi-Fi、或者宽带以太网)内的功能。

例如，SLCM 157可以使IoT装置应用155对IoT SL 152指定E2E SL会话QoS要求。这可以包括应用针对一个或多个目标端点指定所需的可达性日程(例如，当应用需要目标M2M/IoT装置是可到达的以服务其SL请求时)。这还能够包括应用指定其所需的E2E延迟预算(例如，针对SL请求和响应在应用与目标M2M/IoT装置之间行进的整体往返延迟)。这还可以包括应用指定其E2E抖动预算(例如，在应用与目标M2M/IoT装置之间行进的连续SL消息之间的可接受延迟变化)。这还能够包括应用指定其E2E错误率(例如，当在应用与目标M2M/IoT装置之间E2E通信时的可接受的错误率)。SLCM 157还可以包括应用指定其所需的E2E吞吐量(例如，应用与目标M2M/IoT装置之间的吞吐量)。

使用该信息，SLCM 157可以支持分析其SL注册者(例如，应用)的集合的QoS要求并且执行其即时(on-the-fly)的SL实例的配置，使得满足其所有注册者的E2E QoS要求。为此，SLCM 157可以针对E2E SL会话的通信路径中的SL跳中的每个来对可达性日程、通信延迟、通信抖动、错误率、通信吞吐量、安全级别和成本执行即时调整。示例性E2E SL会话147可以是基于经由SLCM 157和UNCM 167使能够的通信。为此，SLCM 157可以与在UNs中的一个或多个内托管的UNCM功能合作，这些UNs中的一个或多个使其SL实例与其他SL实例互相连接。这种合作可以包括SLCM 157将以SL为中心的上下文信息提供给UNCM 167，这可以使UNCM 167能够管理与其相应的底层访问网络相关联的连接。该上下文可以包括应用(例如，IoT装置应用155)或者SL(例如，IoT SL 166)指定的可达性日程、应用或SL指定的最大通信延迟(单个跳和/或端对端)、应用或SL指定的吞吐量(单个跳和/或端对端)、应用或SL指定的抖动、应用或SL指定的错误率、安全级别和成本。

例如，可以由IoT装置应用155使用ACM 160来确定IoT装置应用155的E2E SL会话QoS要求。IoT装置应用155然后可以将这些要求传送到由其本地IoT SL 166托管的SLCM157。当建立E2E SL会话时，ACM 160可以这样做。这些要求可以包括：IoT装置应用155针对一个或多个目标端点指定的可达性日程、所需的E2E延迟预算、和所需的E2E吞吐量，IoT装置应用155指定的抖动、成本水平、安全级别和IoT装置应用155指定的错误率。ACM 160还可以与由宽带以太网167(底层网络)托管的UNCM 167通信以共享类似的要求。

例如，UNCM 167可以支持使SL实例能够针对相应UN(例如，宽带以太网162)指定其UN QoS要求(诸如，连接性日程、延迟、抖动、错误率、吞吐量、安全级别和成本)的功能。例如，然后可以由宽带以太网162使用该信息来调整UN配置，使得可以由宽带以太网162以满足SL限定的要求的方式来处理与指定SL实例或SL会话相关联的SL消息。

还可以由宽带以太网162使用UNCM 167来传送备份到SL实例(例如，IoT SL 166)的以UN为中心的信息。例如，UNCM 167可以将关于特定SL会话(例如，SL会话147)的信息提供给SLCM 157。与SLCM 157共享该信息可以使UNCM 167能够更智能地管理应用和SL的可达性日程以及端对端通信。该信息可以针对同级SL实例或应用包括UN连接性方面的网络拥塞或者变化。例如，SLCM 157可以基于要通过UNCM 167提供给其的宽带以太网167的拥塞信息来做出用于针对SL会话147从一个UN(例如，宽带以太网162)切换到另一个UN(例如，3GPP161)的决定。

理解的是，执行图12至图17中图示的步骤的实体是可以以在装置、服务器、或者计算机系统(诸如，图30C或者30D图示的装置、服务器、或者计算机系统)的存储器中存储的、并且在该装置、服务器、或者计算机系统的处理器上执行的软件(例如，计算机可执行指令)的形式来实现的逻辑实体。即，在图12至图17中图示的方法可以以在计算装置(诸如，图30C或者图30D中图示的装置或者计算机系统)的存储器中存储的软件(例如，计算机可执行指令)的形式实现，该计算机可执行指令在由计算装置的处理器执行时执行在本文其中的图12至图17中图示的步骤。在示例中，根据下文关于M2M装置的交互的进一步细节，图11的IoT装置应用155可以驻留在图30A的M2M终端装置18上，同时图11的SLCM 157和SLCM 158可以驻留在图30A的M2M网关装置14上。

图12图示了可以用于以协调的E2E方式管理IoT装置、网关、和服务器之间的UNQoS的SLCM功能和UNCM功能的示例性消息流。在步骤170中，存在前提(pre-requisite)动作。例如，在每个装置、网关、和服务器之间建立UN连接性。执行适当的SL安全程序，诸如，针对每个单个跳(不是E2E)在实体之间建立证书并且进行认证。在SL实例之间以及在应用和其本地SLs之间执行SL注册。由应用执行对装置、资源、和服务的发现。在步骤171中，应用156确定其是否想要与一个或多个装置应用通信。基于使用案例要求，应用156确定其本身与目标装置应用(例如，IoT装置应用155)之间的E2E QoS要求。例如，E2E通信日程(例如，时间(time of day))、E2E通信延迟(例如，往返延迟不必超过限定的阈值)、E2E抖动(例如，传感器读数之间的延迟方面的变化不超过限定的阈值)、E2E错误率(例如，传感器读数消息中的E2E错误率不超过限定的阈值)、或者E2E吞吐量(例如，每秒的传感器读数)等。

继续参照图12，在步骤172中，应用156将请求发送到IoT SL 165(其可以在IoT服务器151上托管)以在其本身与IoT装置应用155之间建立E2E SL会话。步骤172的请求包括在步骤171中限定的应用156的E2E QoS要求。在步骤173中，SLCM 158检查UNs是否需要配置以满足针对E2E SL会话指定的QoS要求。SLCM 158分配E2E SL会话ID并且还确定下一个SL跳。附属于托管在IoT服务器151上的IoT SL 165的SLCM 158确定其当前配置和其UNs(例如，3GPP 161、Wi-Fi 163、或者宽带以太网162)的配置是否能够满足针对可达性日程、延迟、抖动、错误率、吞吐量、安全级别、或者成本等限定的E2E SL会话限定的QoS要求。SLCM158还导出唯一的SL会话ID。在步骤174a和步骤174b中，SLCM 158与可以将SLCM 158和其下一跳E2E SL会话伙伴连接起来的UNs中的每个中的UNCM 168或者UNCM 167合作以确定是否可以重新配置(或者已经配置)3GPP 161，或者宽带以太网162(或者其他UN)以满足在步骤172中请求的E2E SL会话的QoS要求。

继续参照图12，在步骤175a和步骤175b中，3GPP 161的UNCM168和宽带以太网162的UNCM 167与负责用于控制日程、延迟、抖动、错误率、吞吐量、安全级别、或者成本管理等的其他UN功能协调。这样，每个UNCM确定UN是否能够处理附属于E2E SL会话的、具有由E2ESL会话限定的指定QoS设置的消息。在步骤176中，在IoT服务器151上托管的SL实例(IoT SL165)选择能够满足会话要求的UN(例如，宽带以太网162)并且将E2E SL会话建立请求转发到下一个SL跳，该下一个SL跳是在IoT网关152上托管的SL实例(IoT SL166)。SL会话ID被包括在步骤176的该请求中。

继续参照图12，在步骤177中，SLCM 157检查UNs是否需要配置以满足针对E2E SL会话指定的QoS要求。SLCM 157还确定下一个SL跳。附属于在IoT网关152上托管的IoT SL166的SLCM 157确定其当前配置和其网关装置UNs的配置是否能够满足E2E SL会话QoS要求。在该示例中，能够满足要求。与步骤174a和步骤174b类似，在步骤178a或者步骤178b中，SLCM 157与可以将SLCM 157和其下一跳E2E SL会话伙伴连接起来的6LoWPAN 164的UNCM149合作，以确定是否可以重新配置(或者还配置)6LoWPAN 164以满足在步骤172中请求的E2E SL会话的QoS要求。与步骤175a或者步骤174类似，在步骤179a或者步骤179b中，3GPP161的UNCM 168和宽带以太网162的UNCM 167与负责用于控制日程、延迟、抖动、错误率、吞吐量、安全级别、或者成本管理等的其他UN功能协调。这样，每个UNCM确定UN是否能够处理附属于E2E SL会话的、具有由E2E SL会话限定的指定QoS设置的消息。在步骤180中，在IoT网关152上托管的IoT SL 166选择能够满足会话要求的6LoWPAN 164并且将E2E SL会话建立请求朝向目标E2E SL会话端点(例如，IoT装置应用155)转发到下一个SL跳。步骤180的请求可以包括E2E SL会话ID。可替选地，在IoT网关152上托管的SL实例可以代表IoT装置应用代理并且代表IoT装置应用155处理对该请求的服务。

继续参照图12，在步骤181中，IoT装置应用155接收并处理E2E SL会话建立请求。如果IoT装置应用155同意加入到与请求的始发者(例如，IoT应用156)的E2E SL会话中，那么IoT装置应用155通过接受该请求来响应。否则，它会返回拒绝该请求的错误。该响应包括在相应请求中指定的SL会话ID。IoT应用155接收到指示IoT装置应用155接受E2E SL会话建立请求的响应。在步骤182中，IoT应用156然后生成E2E SL会话请求以与IoT装置应用155通信。当创建步骤182的请求时，IoT应用156可以包括E2E会话ID。可以在E2E通信路径中由UNs和SL实例使用该E2E会话ID来适当地处理请求，使得满足在E2E SL会话建立期间配置的E2EQoS设置。例如，UN(例如，使用深度分组检查技术)检测到消息中的E2E SL会话ID标记并且使用该SL会话ID来基于其维持的E2E SL会话QoS要求处理该消息。在步骤183中，IoT装置应用155接收到步骤182的请求，并且然后生成返回到IoT应用156的E2E SL会话响应。当创建步骤183的响应时，IoT装置应用可以包括E2E会话ID。由E2E通信路径中的UNs和SL实例使用该E2E会话ID来适当地处理该响应，使得满足在E2E SL会话建立期间针对会话配置的E2EQoS设置。

表格2公开了以SL为中心的若干示例类型的信息元素，可以提供这些信息元素(例如，在SL会话建立请求中包括的)来协助处理E2E SL会话。每个E2E SL会话可以具有SL QoS信息以及与E2E SL会话相关联的UN QoS相关的信息这两者。能够使用该信息来管理这些SL会话端点之间的端对端SL QoS以及SL会话的每跳之间的UN QoS。由SLs(例如，使用SLCM功能)、UNs(例如，使用UNCM功能)、以及SL会话端点能够收集、维持、共享该信息。

表格2的信息元素可以使SL会话始发者(例如，IoT装置应用156)限定其本身与一个或多个其他目标SL会话端点之间的E2E QoS要求。同样，SL能够使用该信息来确定SL会话始发者的E2E QoS要求并且使用本文公开的方法来依次尝试以满足这些要求。

表格2：SL会话E2E QoS信息

表格3提出了可以用于支持E2E SL QoS的若干类型的以UN为中心的信息元素。例如，针对E2E SL会话中的每个通信跳，发起或者转发SL建立请求的实体可以使该信息是可用的(例如，通过将其包括在请求本身中)。由SL本身或者UNs还可以收集、追踪和维持该信息。此外，在某些情况下，SL和UNs可以彼此合作并且交换该信息(例如，经由SLCM或者UNCM)。本公开提出了用于支持这一点的方法。

表格3：用于管理SL QoS的UN QoS信息

图13图示了在IoT现场装置153(例如，IoT传感器)上托管的应用、IoT网关152、IoT服务器151与IoT应用156之间建立的0-跳186、1-跳187、和2-跳188E2E SL会话的使用案例示例。在这些情况中的每种情况下，IoT应用156发起E2E SL会话的建立。在0-跳186中，IoT应用156与IoT服务器151建立E2E SL会话。在1-跳187中，IoT应用156与IoT网关152建立E2ESL会话。在2-跳188中，IoT应用156与在IoT现场装置153上托管的应用建立E2E SL会话。

在正在所示使用案例的建立的三个E2E SL会话中，由在IoT服务器151和IoT网关152上托管的SLs支持的每个SLCM功能可以与由UNs支持的每个UNCM功能通信。这样，SLCMs和UNCMs协调对针对E2E SL会话的每个跳使用的UN QoS的适当选择和配置，使得可以满足E2E SL会话的E2E QoS要求。

本文公开了用于管理UN QoS以满足E2E SL QoS要求的方法。具体地，这些方法涉及在E2E SL会话建立、E2E SL会话通信、和E2E SL会话拆除期间管理UN QoS。

图14图示在E2E SL会话建立期间管理UN QoS的示例性方法。图14所示的用于程序的前提是SL注册者(例如，IoT应用156)生成对在其本身与目标SL会话端点(例如，IoT装置应用155)之间建立SL会话的请求。在该请求中，IoT应用156可以通过将信息包括在请求中来指定用于E2E SL会话的QoS请求，诸如在表格2中指定的以SL为中心的信息和(如果适用)可能的在表格3中指定的以访问网络为中心的信息。其处由SL注册者的本地SL接收到E2ESL会话建立请求的点是其处在图14中限定的程序开始的点。该程序用于在朝向目标SL会话端点传播E2E SL会话建立请求时处理该传播E2E SL会话建立请求以及在朝向始发该请求的SL注册者流回时处理该相应的响应。下文限定了提出的程序的详细步骤。在步骤201中，接收器(例如，中间SL实例或者目标SL会话端点，诸如，IoT服务器165、IoT网关152、或者IoT装置应用155)检测到传入的请求并且检查其是否是SL会话建立请求或响应。可以通过分析SL消息中的报头信息来执行该检查。报头信息可以指示SL消息的SL消息类型。如果步骤201的接收到的SL消息是SL会话建立请求，那么转到步骤202。如果在步骤201中接收到的SL消息是SL会话建立响应，则转到步骤211。

继续参照图14，在步骤202和步骤203中，如果步骤201的SL消息是SL会话建立请求，则接收器的SLCM可以执行QoS检查以及其本身与其邻近SL会话跳伙伴之间的可能对准，如下文讨论的是，诸如，SL可达性日程检查、UN连接性检查、SL跳延迟检查、SL跳吞吐量检查、SL跳抖动检查、SL跳错误率检查、SL跳成本水平检查、或者SL跳安全级别检查等。注意的是，在执行该检查之前，SLCM可以执行用于验证E2E SL会话是否已经存在的检查。SL可达性日程检查-为了检查并对准SL可达性日程，接收器的SLCM或者ACM将其当前的SL可达性日程与在请求中指定的E2E SL会话可达性日程进行比较。该检查验证了接收器的SL是否是活动的和是否是可达的，以在对正在建立新的SL会话所需的时间期间处理SL消息。为此，接收器的SLCM或者ACM检查其当前的可达性日程窗口是否与在请求中指定的那些窗口对准。这可以通过将在请求中指定的每个可达性窗口的开始和结束时间与接收器的当前可达性窗口的开始和结束时间进行比较来实现。UN连接性检查：为了检查并且对准UN连接性日程，接收器的SLCM或者ACM可以将其为可达性窗口中的每个支持的不同类型UNs与新的SL会话所需的那些进行比较。这些可以在请求中指定或者请求者可以使该信息预先对接收器可用。在预先使该信息对接收器可用的情况下，接收器的SLCM或者ACM可以检查至少一个公共UN是否是是活动的以及是否正在针对SL会话所需的每个可达性窗口来提供接收器与其邻近SL会话跳伙伴之间必要的连接性。

继续参照图14的步骤202至203，SL跳延迟检查-接收器的SLCM或者ACM可以从UNCM(如果可用的话)获得针对该特定SL跳的延迟信息。如果从UNCM无法提供，则SLCM或者ACM可以通过将其本身与其邻近SL会话跳伙伴之间的通信延迟进行比较来执行延迟检查，以确定其是否小于在传入请求中指定的所需E2E SL会话延迟。为了执行该检查，接收器的SLCM或者ACM可以自动生成一个或多个单独的SL ping请求(等)，该SL ping请求可以针对其邻近SL会话跳伙伴并且接收到相应的响应返回。为了测量延迟，SLCM或者ACM可以测量发送每个SL ping的时间和接收到响应的时间。SLCM或者ACM然后可以相减并且求平均以计算延迟。如果多于一个UNs将接收器和其邻近SL会话跳伙伴连接，则SLCM或者ACM可以对每个UN执行该延迟检查并且将它们进行比较，以选择满足SL会话延迟要求的最佳UN。SLCM或者ACM还可以维持这些延迟测量值并且将其再次使用用于未来的SL会话请求，使得其不需要经常重复延迟测量。SLCM或者ACM还可以定期地重新执行该延迟检查以监测延迟是否继续满足SL会话延迟要求。如果不是，则SLCM或者ACM可以向始发SL会话端点用信号发送错误或者事件以指示这一点。SL跳吞吐量检查-接收器的SLCM或者ACM可以从UNCM(如果可用)获得吞吐量信息。如果不可用，则SLCM或者ACM可以通过将其本身与其邻近SL会话跳伙伴之间的通信吞吐量进行比较来执行吞吐量检查，以确定其是否满足或者超过在传入SL会话建立请求中指定的所需E2E SL会话吞吐量。为了执行该检查，接收器的SLCM可以自动生成SL ping请求的重复的序列，该SL ping请求可以针对其邻近SL会话跳伙伴并且接收相应响应返回。SCLM可以配置每个ping的长度以匹配在SL会话建立请求中指定的最大SL消息大小。为了测量吞吐量，SLCM可以测量其接收到响应时的速率。如果多于一个UNs与接收器和其邻近SL会话跳伙伴连接，则SLCM可以在每个UN上执行该吞吐量检查并且将它们进行比较。SLCM还可以维持这些吞吐量测量值并且再次使用它们用于未来的SL会话请求，使得其不需要经常重复测量。SLCM或者ACM还可以定期地重新执行该吞吐量检查以监测吞吐量是否继续满足SL会话要求。如果不是，则SLCM或者ACM可以向始发SL会话端点用信号发送错误或者事件以指示这一点。

继续参照图14的步骤202至203，SL跳抖动检查-接收器的SLCM或者ACM可以从UNCM(如果可用)获得抖动信息。如果不可用，则SLCM或者ACM可以使用上文在吞吐量检查中描述的类似程序来执行抖动检查。替代测量吞吐量，SLCM或者ACM可以测量连续的ping响应之间的延迟方面的变化。SL跳错误率检查-接收器的SLCM或者ACM可以从UNCM(如果可用)获得错误率信息。如果不可用，则SLCM或者ACM可以使用本文相对于吞吐量检查描述的类似程序来执行错误率检查。替代测量吞吐量，SLCM或者ACM可以测量ping请求和响应序列的错误率。SL跳成本水平检查-接收器的SLCM或者ACM可以从UNCM(如果可用)获得成本信息并且将其与请求中指定的成本要求(例如，预算)进行比较，以确定使用UN的成本是否与E2E SL会话要求对准。SL跳安全级别检查-接收器的SLCM或者ACM可以从UNCM(如果可用)获得安全信息，并且将其与请求中指定的安全要求进行比较，以确定UN中任何支持的安全级别是否与E2E SL会话要求对准。

继续参照图14，在步骤204中，接收器的SLCM或者ACM尝试调整在步骤203中检查失败的QoS参数(如果有)。SLCM或者ACM尝试通过与每个相应UN中的UNCMs合作(如果支持)来调整接收器与其邻近SL会话跳伙伴之间的UNs中的QoS参数。为此，SLCM或者ACM可以创建请求，该SLCM或者ACM将请求发送到一个或多个UNCM。在该请求中，SLCM或者ACM可以包括诸如E2E SL会话ID、接收器及其邻近SL会话跳伙伴的UN地址、和接收器与其邻近SL会话跳伙伴之间所需的UN QoS参数等类型的信息(参见针对每个表格2和表格3的定义)。

继续参照图14中的步骤204，使用该信息，UNCM可以确定接收器与其邻近SL会话跳伙伴之间的QoS要求(例如，日程、延迟、抖动、错误率、吞吐量、成本、安全)。UNCM然后可以与UN中的其他功能协调以确定其是否可能配置UN以满足SL会话QoS要求。这可以针对在接收器与其邻近SL会话跳伙伴之间通过该UN发生的所有SL通信来实现，或者可替选地，这可以仅针对与该特定SL会话相关联的并且用该特定E2E SL会话ID标记的消息，通过UN选择性地实现。下文讨论了一些QoS参数特定的调整程序，诸如，SL可达性日程调整或者UN连接性日程调整。SL可达性日程调整-如果SL可达性日程彼此不对准，则接收器的SLCM或者ACM可能会尝试调整接收器的SL可达性窗口以试图使它们对准。为此，接收器的SLCM或者ACM必须小心，以不影响任何其他现有的SL会话。这可以通过SLCM或者ACM将对其当前SL会话所需的接收器的现有SL可达性日程与由正在建立的新SL会话所需的可达性窗口聚合在一起来实现。这样，SLCM或者ACM可以确保所有SL会话可以彼此共存(例如，通过使会话日程彼此对准或者不对准)。UN连接性日程调整-针对其中不存在充足的UN连接性的情况，SLCM或者ACM可以与每个相应UN中的UNCMs通信，以尝试并修改UN连接性日程以将它们与E2E SL会话要求对准。为此，SLCM或者ACM可以创建请求，将该请求发送到UNCM。在该请求中，SLCM或者ACM可以包括诸如SL会话ID以及用于接收器和/或其邻近SL会话跳伙伴的连接性日程的信息。UNCM然后可以使用该信息来与其他UN功能协调以尝试修改连接性日程，使得它们在SL会话通信所需的时间期间彼此对准。如果上文描述的连接性日程检查和对准活动成功，则程序继续执行延迟检查，否则其转到步骤210，在步骤210中，接收器准备并发送指示在接收器与其邻近SL会话跳伙伴之间无法建立适当的连接性的错误响应。为了提供可能有帮助的附加信息，可以在该错误响应中返回可实现的日程。

继续参照图14，在步骤205中，如果所需的QoS参数调整成功，则程序转到步骤206以检查目标SL会话端点是否是远程托管的，否则其转到其中接收器准备并且发送指示可以不满足所需的QoS的错误响应的步骤210。为了提供可能有帮助的附加信息，可以在该错误响应中返回可实现的QoS参数值。在步骤206中，接收器的SLCM或者ACM检查在用于建立SL会话的请求中指定的目标SL会话端点是否是本地托管的或者是否必须被转发到另一跳。这可以通过将接收器地址与目标SL会话端点的地址进行比较来实现。如果必须将请求转发到另一个SL跳，则程序转到步骤207以准备要转发的请求。否则，程序转到步骤209以准备SL会话建立响应。可以将请求从一个服务层节点转发到另一个服务层节点知道建立端对端服务层会话。在步骤207中，因为目标SL会话端点未由接收器托管，所以将SL会话建立请求转发到下一跳。在转发该请求之前，接收器的SLCM或者ACM可以更新请求以指示对于随后跳要消耗的某些QoS参数(诸如，延迟、抖动、和错误率)来说剩余多少E2E QoS预算。为此，接收器的SLCM或者ACM可以从请求中携带的E2E SL会话值减去由其跳消耗的测量的QoS参数。这样，当下一跳接收到请求时，将会已经调整针对每个QoS参数的剩余预算的请求，以考虑E2E通信路径中的先前跳。

继续参照图14，在步骤208中，将E2E SL会话建立请求转发到下一跳。在步骤209中，由接收器托管目标SL会话端点。在接收到该请求之后，接收器可以执行诸如验证存在目标以及验证始发SL会话端点具有与目标建立E2E SL会话的适当许可的动作。接收器可以制定成功的SL会话建立响应。该响应可以包含诸如E2E SL会话ID、成功的响应代码、或者作为在逐跳E2E SL会话建立期间测量的E2E QoS参数等信息。测量的E2E QoS参数可以包括诸如剩余的延迟、抖动、成本、和错误率预算以及在逐跳E2E SL层会话期间测量的最小吞吐量的测量值。然后将该响应发送回到从其接收到该请求的接收器的相同邻近SL会话跳伙伴。在接收到该响应之后，邻近SL会话跳伙伴可以使用相同程序(参见步骤211)来处理响应。在步骤210中，接收器无法成功地处理E2E SL会话建立请求。接收器可以将错误响应返回到从其接收到该请求的接收器的相同邻近SL会话跳伙伴。在接收到该响应之后，邻近SL会话跳伙伴可以使用相同程序(参见步骤211)来处理该响应。

继续参照图14，在步骤211中，接收器的SLCM检查E2E SL会话建立响应，以确定其是否是成功响应或者是否是错误响应。如果是成功响应，则程序转到步骤213。否则，程序转到步骤212。在步骤212中，在错误响应的情况下，删除SL会话状态。接收器SLCM去除其维持的SL会话状态并且还与其支持的底层网络中的每个UNCM通信，以使它们拆除SL会话状态和配置。这可以包括去除基于在E2E SL会话建立处理期间配置的SL会话的UN连接性、延迟、抖动、错误率和吞吐量配置。在步骤213中，接收器基于检查SL会话ID来检查其是否是E2E SL会话始发端点，以确定该SL会话ID是否匹配接收器可能具有的任何尚未完成的E2E SL会话建立请求。如果匹配，那么接收器处理该响应以确定E2E SL会话建立请求是否是成功的。如果不是，那么程序转到步骤215以将响应转发到下一跳。在步骤214中，认为由E2E SL始发端点成功地建立了E2E SL会话。在步骤215中，接收器的SLCM或者ACM将E2E SL会话响应转发到用于该会话的其的相应邻近SL会话跳伙伴，使得该响应使其朝向E2E SL会话始发端点前进。

图15图示了用于在管理UN连接的同时发送E2E SL会话消息的示例性方法。一旦建立，E2E SL会话可以用于发送并接收E2E SL会话通信请求和响应。在步骤221中，E2E SL会话参与者(例如，SL会话端点或者中间SL实例)确定其需要经由已经建立的特定E2E SL会话来发送E2E SL会话通信请求或者E2E SL会话通信响应消息。在步骤222中，为了经由E2E SL会话发送响应，参与者创建响应并且配置E2E会话ID以匹配在请求中指定的E2E会话ID。响应可以包括其他信息以及应用指定的响应信息。由SLCM确定针对响应的目标目的地。为此，SLCM或者ACM使用其为始发或者重新定向的每个和每一个E2E SL会话请求维持的本地状态(如下文在步骤223中描述的)。使用E2E SL会话ID，SLCM或者ACM查找其应当将响应发送到何处。在步骤223中，为了经由E2E SL会话发送请求，参与者创建请求并且配置到其定向的E2E SL会话端点的目的地地址。其还包括与其想要用于与目标端点通信的SL会话相对应的E2E会话ID。请求可以包括其他信息以及应用指定的请求信息。在发送请求之后，SLCM或者ACM为请求维持SL会话状态。SLCM或者ACM维持其是否始发请求或者其是否重新定向请求。针对其中其重新定向请求的情况，SLCM还保持对其接收到要重新定向的请求的哪个SL实体的追踪。使用E2E SL会话ID来对该信息保持追踪。

继续参照图15，在步骤224中，需要将E2E SL会话通信请求/响应朝向目标的E2ESL会话端点(在请求的情况下)或者始发的E2E SL会话端点(在响应的情况下)路由。所以，针对SLCM或者ACM在该过程中涉及的动作中的一个可能是为了分析在E2E SL会话通信请求/响应中指定的目的地地址以确定将其路由到的下一个SL跳。这可能涉及SLCM或者ACM将请求/响应中包含的E2E SL会话ID与SL路由状态进行比较以确定下一个SL跳。这可能会产生可路由的地址，诸如下一个SL跳的IP地址。然后可以将这个可路由的地址解析成UN地址。在步骤225中，然后将消息从SLCM或者ACM移交到在E2E SL会话建立期间分配的相应的UN。当UN接收到该消息时，其可以使用其UNCM功能来分析消息，以确定该消息是否包含UN识别的E2E SL会话ID标记。例如，UNCM可以使用深度分组检查(DPI)技术来分析消息并且搜索UNCM在E2E SL会话建立期间被配置有的E2E SL会话ID。在步骤226中，针对UN不支持以SL会话感知方式处理消息的情况或者当前消息包含可由UN识别的E2E SL会话ID的情况，然后UN可以以非SL会话感知方式来处理消息。在这种情况下，SL负责确保实现E2E QoS。这可以使用UN使SL可用的UN QoS消息来实现。SL可以依次做出调整(例如，改变UNs)以确保维持E2EQoS。

在步骤227中，针对其中UN不支持以SL会话感知方式处理消息并且检测到当前消息不包含其识别的E2E SL会话ID的情况，然后UNCM功能可以以SL会话感知方式来处理消息。这样，UNCM可以将UN中的其他功能告知给与该消息相关联的E2E SL会话ID。通过使用该信息，其他功能可以以可以满足E2E SL会话QoS要求的方式来处理消息。例如，UN可以通过控制其何时触发目的地连接至网络来控制该消息的日程，以便UN可以向目的地发送消息。类似地，UN可以通过控制消息在遍历通过各种UN功能时引发的延迟来控制消息的延迟、抖动和吞吐量。在步骤228中，UN的UNCM(如果支持)可以向SLCM提供关于对E2E SL会话通信请求/响应消息的处理的反馈(例如，通知)。该反馈可以包括UN是否能够满足在E2E SL会话建立期间报告的相同QoS等级以及(如果不是)针对该给定消息的新的测量是什么。该反馈还可以包括是否已经超过了指定错误率阈值。例如，如果UN变得拥塞并且不再能够满足在SL会话建立期间配置的SL会话要求，则UNCM可以通知SLCM或者ACM。在步骤229中，通过消息基础、周期基础、或事件基础对消息与SLCM或者ACM的共享UN信息(例如，当处理导致延迟或者吞吐量不满足SL会话的要求的消息时)可以允许SLCM或者ACM能够追踪该特定UN是否继续维持并且满足E2E SL会话的QoS要求。针对该情况，其中SLCM或者ACM检测到情况不是这样的情况，SLCM或者ACM可以采取校正动作，诸如，请求UN尝试并且重新配置UN网络功能以解决该问题(例如，增加SL会话消息的优先级)。可替选地，SLCM或者ACM还可以检查以确定是否存在可供使用的另一个可适用UN，并且如果有，其可以将E2E SL会话迁移越过到这个新UN。为此，SLCM或者ACM可以将相同类型的请求发送到新UN中的新UNCM，就像其对E2E SL会话建立程序中的原始UN做的那样。类似地，如在E2E SL会话拆除程序中描述的，其还可以将请求发送到旧UN中的旧UNCM以拆除该会话。如果成功了，则SLCM或者ACM可以开始使用新UN以处理其针对该特定E2E SL会话接收到的未来的E2E SL会话通信请求/响应消息。

图16图示了在接收到E2E SL会话消息的同时管理UN QoS的示例性方法。在步骤231中，接收器的SLCM或者ACM(例如，始发SL会话端点、中间SL实例或者目标SL会话端点)检测到传入的SL消息并且检查其是否是SL会话通信请求或者响应。通过分析SL消息中指示其SL消息类型的报头信息来执行该检查。如果它是SL会话通信请求或者响应，则其转到步骤232。如果不是，则程序退出。在步骤232中，接收器的SLCM或者ACM检查其是否是SL会话通信请求或者响应。在步骤233中，接收器的SLCM或者ACM检查在SL会话通信请求中指定的目标端点是否是本地托管的或者是否必须要将该请求转发到另一跳。这可以通过将接收器地址与目标SL会话端点的地址进行比较来实现。在步骤234中，如果必须将请求重新定向到另一个SL跳，则接收器的SLCM可以使用图15中限定的程序来这样做。在步骤235中，在检测到SL会话通信请求正在定向于接收器之后，接收器可以处理请求(例如，对由接收器托管的资源执行CRUD操作，或者调用由接收器托管的目标功能等)。接收器然后可以计算可以包含应用指定的响应信息的响应(如果适用)。在步骤236中，接收器的SLCM或者ACM生成SL会话通信响应消息。在该响应中，接收器的SLCM或者ACM确保包括来自SL会话通信请求的相同的E2ESL会话ID，使得可以由中间SLs和UNs将该响应处理为E2E SL消息，因为其被路由回到始发者。为了发送响应，接收器的SLCM或者ACM可以使用在图15中限定的程序。

继续参照图16，在步骤237中，接收器的SLCM或者ACM检查SL会话通信响应以确定接收器是否是与该响应相对应的请求的始发者。为此，接收器将响应中的E2E SL会话ID与其为始发或者重新定向的每个SL会话通信请求维持的本地存储的状态进行比较。如果接收器检测到SL会话ID匹配接收器始发的请求，那么接收器知道其不需要重新定向该响应并且接收器应当处理该响应本身。如果接收器检测到E2E SL会话ID匹配其重新定向的请求，那么接收器知道其需要将响应重新定向回到从其接收到该请求的相同的SL实体(例如，中间SL实例或者SL会话始发端点)。如果接收器没有识别到E2E SL会话ID，那么其将响应丢弃并且程序退出。在步骤218中，接收器是与接收到的响应相对应的SL会话通信请求的始发者。接收器处理响应并且从其提取应用指定的响应信息。在步骤219中，接收器不是与接收到的响应相对应的SL会话通信请求的始发者，所以接收器的SLCM将响应转发到下一跳。为此，接收器的SLCM可以使用以上在图15中限定的程序来这样做。

图17图示了用于在E2E SL会话拆除期间管理UN连接的示例性方法。图17中所示的程序的前提可能是SL注册者(例如，后台应用)生成用于拆除在其本身与目标SL会话端点(装置应用)之间的E2E SL会话的请求。在该请求中，SL注册者指定E2E SL会话ID以及目标会话端点。然后将该请求转发到SL注册者的本地SL以进行处理。其处由SL注册者的本地SL接收到E2E SL会话拆除请求的点是其处在图17中限定的程序开始的点。可以使用该程序来处理E2E SL会话拆除请求，因为其是朝向目标SL会话端点逐跳传播的。该程序还可以用于处理相应的E2E SL会话拆除响应，因为其朝向始发请求的SL注册者流回。在步骤241中，接收器的SLCM或者ACM(例如，始发SL会话端点、中间SL实例或者目标SL会话端点)检测到传入的SL消息并且检查其是否是SL会话拆除请求或者响应。通过分析SL消息中的、指示其SL消息类型的报头信息来执行该检查。如果都不是，则程序退出。在步骤242中，接收器的SLCM或者ACM检查其是否是E2E SL拆除请求的目标。在步骤243中，如果请求未定向于接收器，则接收器将E2E SL拆除请求重新定向到下一跳。当这样做时，接收器的SLCM维持其重新定向请求的状态并且保持对其接收到要重新定向的请求的SL实体的追踪。使用E2E SL会话ID来对该信息保持追踪。

继续参照图17，在步骤244中，如果请求未定向接收器，则SLCM或者ACM通过首先生成指示SLCM或者ACM接收到响应并且其同意拆除会话的E2E SL会话拆除响应来处理请求。在步骤245中，为了发送响应，参与者创建响应并且配置E2E会话ID以匹配在请求中指定的E2E会话ID。响应可以包括诸如应用指定的响应信息的其他信息。目标目的地是在请求中指定的E2E SL会话始发者。在步骤246中，接收器的SLCM或者ACM检测在E2E SL会话建立期间或者在E2E SL会话通信期间创建的任何状态。SLCM或者ACM还与在可适用UNs中的每个中驻留的UNCMs通信以删除在UN中维持的状态并且以释放需要服务针对该特定跳的E2E SL会话的保留资源。这包括用于附属的消息的E2E SL会话感知处理的任何UN功能上的配置，该附属的消息具有匹配正在拆除的会话的E2E SL会话ID。在步骤247中，针对其中传入的消息是E2E SL会话拆除响应的情况，接收器的SLCM或者ACM检查响应是否与接收器始发的E2E SL会话拆除请求互相关联。在步骤248中，如果不关联，则接收器的SLCM确定要将响应转发到的下一跳。为此，SLCM使用其为重新定向的E2E SL会话拆除请求维持的本地状态。使用E2ESL会话ID，SLCM查找其接收到匹配E2E SL会话ID的相应E2E SL会话拆除请求的位置。

在步骤249中，然后将响应从SLCM或者ACM移交到在E2E SL会话建立期间分配的相应的UN。UN然后将消息转发到下一跳。在步骤250中，接收器的SLCM或者ACM检测在E2E SL会话建立期间或者在E2E SL会话通信期间创建的状态。SLCM或者ACM还与在可适用UNs中的每个中驻留的UNCM通信以删除维持在需要服务针对该特定跳的E2E SL会话的UN中的状态。这包括用于附属的消息的E2E SL会话感知处理的任何UN功能上的配置，该附属的消息具有匹配正在拆除的会话的E2E SL会话ID。在步骤251中，如果响应与接收器始发的E2E SL会话拆除请求互相关联，那么接收器处理响应以验证由目标E2E SL会话端点成功地处理会话拆除。在步骤252中，接收器的SLCM或者ACM(如果支持)然后删除在E2E SL会话建立期间或者在E2E SL会话通信期间创建的状态。SLCM或者ACM还与在可适用UNs中的每个中驻留的UNCMs通信，以检测维持在需要服务针对该特定跳的E2E SL会话的UN中的任何状态。这包括用于附属的消息的E2E SL会话感知处理的任何UN功能的配置，该附属的消息具有匹配正在拆除的会话的E2E SL会话ID。

图18图示了其中将SLCM实现为oneM2M限定的服务会话管理(SSM)CSF的支持功能的示例。该SLCM实现的SSM CSF 272由在IoT装置(例如，ASN-CSE 271)、IoT网关(例如，MN-CSE 273)、或者IoT服务器(IN-CSE 275)上托管的oneM2M CSE支持。

该SLCM实现的SSM CSF 272依次经由oneM2M限定的网络服务暴露、服务执行和触发(NSSE)CSF(例如，NSSE CSF 278)与UNCM接口连接。UNCM功能(例如，UNCM 276)被实现为3GPP限定的服务能力暴露功能(SCEF)的功能，例如，SCEF 277。SCEF 277依次与3GPP网络(例如，3GPP网络274)中的各种其他功能接口连接。根据oneM2M的定义，SCEF 277是底层网络服务实体(NSE)。在图18中，在由横跨3GPP网络的多个CSE跳分离的两个oneM2M AEs(例如，AE 270和AE 279)之间建立E2E oneM2M SL会话，该3GPP网络由两个不同的网络运营商拥有。每个oneM2M AE支持ACM功能。SLCM、ACM和UNCM功能一起使oneM2M AEs能够与彼此建立具有应用指定的QoS要求的E2E oneM2M SL会话。通过SLCM、ACM、和UNCM功能的协助，oneM2M CSEs能够彼此协调以及与由不同运营商拥有的两个底层3GPP网络协调。通过该协调，可以在oneM2M服务层处和底层3GPP网络中实现对QoS参数的适当调整和对准。这样，CSEs可以使用本公开中捕获的提出方法来在协调的逐跳基础上并且最终在E2E基础上管理AEs的E2E QoS要求。因此，oneM2M AEs能够使用E2E oneM2M SL会话来以满足其指定的E2EQoS要求的方式彼此通信。

可以针对oneM2M SSM CSF来限定API以允许AE建立E2E oneM2M SL会话。API可以是基于资源定义(例如，RESTful API)。传统资源可以包括<session>、<sessionPolicy>、和<sessionContext>。可以对<session>和<sessionPolicy>资源进行增强，这些<session>和<sessionPolicy>资源使AE能够在建立E2E SL会话期间限定应用指定的E2E QoS要求。本文公开的API增强可以用于实现oneM2M SLCM或者ACM API。下文公开了可以用于通过允许E2ESL会话始发者(例如，AE 270或者IoT装置应用155)分别创建或者删除其本地CSE内的这些资源来请求创建或者拆除E2E SL会话的一些增强。另外，由中间CSEs还可以使用这些资源来以逐跳方式创建或者拆除E2E SL会话。这可以通过中间CSE在创建或者拆除E2E SL会话期间分别创建或删除下一跳CSE上的这些资源来实现。这样，多跳E2E SL会话配置中的每个CSE都可以维持针对每个E2E SL会话的这些资源的相应的集合。这些资源向CSE提供有用于维持其帮助支持的每个E2E SL会话的状态的感知和能力。

图19图示了对oneM2M<session>资源的示例增强。这包括多个属性以使AE能够限定与特定oneM2M E2E SL会话相关联的应用指定的E2E QoS要求。该属性可以是在表格4中限定的并且在图19中示出的日程、延迟、抖动、错误率、吞吐量、成本水平、和安全级别属性。在另一个示例中，替代在<session>资源内(它们可以替代)限定E2E SL会话QoS要求，而在如图20中所示的oneM2M<sessionPolicy>资源中限定E2E SL会话QoS要求。

表格4：oneM2M<session>或者<sessionPolicy>资源的E2E通信属性

通常，oneM2M未限定资源以维持关于提供CSE与注册到其的AEs或者其他CSE之间的连接性的UNs的以QoS为中心的信息。例如，本文公开了在图21中图示的<UN>oneM2M资源。该资源支持一组属性以追踪并维持可以从单个UN发布或检索的信息。CSE可以支持针对每个支持的UN的单独<UN>资源并且使用该资源来维持关于UN的信息。支持这种信息向CSE提供了UN上下文(例如，AE或者CSE在该UN上的当前可达性、通信延迟、和通信吞吐量)，这可以使其能够做出UN感知决定。例如，CSE可以基于该信息来对用于与邻近CSE或者AE通信的一组UNs分级并且确定最佳使用。在资源中维持的信息可以经由UN(例如，经由由附属于3GPP网络的SCEF支持的UNCM功能)发布或者从UN检索(例如，经由由CSE支持的SLCM)等。表格5提供了示例性属性。

表格5：<UN>资源属性

通常，oneM2M限定了<AE>和<remoteCSE>资源这两者的单个pointOfAccess属性。传统属性用于捕获相应AE或者CSE的UN地址的列表。当AE或者CSE注册到另一个注册者CSE时，其可以提供该信息。可以由注册者CSE使用该信息来在其需要将消息发送到AE或者CSE时联系该AE或者该CSE。通常，oneM2M将在pointOfAccess属性中存储的信息限定为IP地址或者FQDNs和端口的列表。由AE或者CSE支持的每个相应UN在该列表中都具有条目。作为限定的pointOfAccess属性不支持任何其他UN信息。

下文限定了对oneM2M pointOfAccess属性功能提出的增强以向CSE提供针对附加UN信息的可视性。图22图示了示例性的E2E SL会话QoS要求<pointOfAccess>属性。在第一示例增强中，可以将pointOfAccess属性转换成具有其自己的单个属性的资源。这样做在CSE与其注册者之间创建了更有益的API，使其允许指定附加UN信息。在第二示例增强中，可以添加对附加的与UN QoS相关的信息(诸如，在表格3中公开的信息)的支持。支持用于注册到CSE的给定AE或者CSE的信息，为注册者CSE提供有用于给定AE或者CSE的UN指定的配置和要求的可视性。这可以使注册者CSE具有关于其注册者中的每个的UN指定信息。例如，CSE可以针对注册到其的每个AE或者CSE来确定对于与该AE或者CSE通信是可用的的UNs的集合。另外，CSE具有针对每个AE或者CSE的UN要求。然后可以使用该信息来对以在与特定AE或者CSE通信时使用哪个UN做出更明智地决定。表格6提供了与图22相关联的示例性属性。

表格6：<pointOfAccess>资源属性

图23和图24图示了用于<AE>资源和<remoteCSE>资源的示例性<pointOfAccess>子资源。例如，在本文中，可以允许<AE>或者<remoteCSE>oneM2M资源支持如图23或图24中所示的公开的<pointOfAccess>资源的单独实例。可以由AE或者CSE创建<pointOfAccess>的单独实例以维持每个UN提供其本身与其注册者CSE之间的连接性的连接性信息。

本文公开了可以由3GPP限定的SCEF支持的用于UNCM功能的API。这种公开的API实际上是RESTful并且限定了可以由信任的应用或者第三方服务(例如，通过由oneM2M CSE支持的SLCM功能)访问的一组资源和属性。

图25图示了针对3GPP UNCM/SCEF的示例性<UNCM>资源。该资源支持一组属性以追踪并且维持UN信息。UNCM可以支持为其支持的每个UN的单独的<UNCM>资源。<UNCM>可以支持与每个相应的UN中的相应UN节点/功能通信，以收集然后使其经由该资源可用的信息。UNCM可以支持对该资源的检索请求以及订阅机制，以允许信任的应用或者服务提供商接收来自UNCM的UN信息。例如，SLCM功能可以检索<UNCM>资源或者其可以创建订阅以在任何<UNCM>属性被更新的条件下接收通知。表格7提供了示例性的<UNCM>资源属性和子资源。

表格7：<UNCM>资源属性和子资源

图26图示了针对3GPP UNCM/SCEF的示例性<UNCMSession>资源。该资源支持一组属性以允许信任的应用或服务提供商在由与SL会话相对应的UNCM管理的UN中创建通信会话。例如，oneM2M CSE内的SLCM功能可以创建<UNCMSession>资源以在oneM2M CSE本身与相邻CSE之间建立单个跳UN会话。通过配置具有在本公开中提出的E2E SL会话ID的<UNCMSession>资源的会话ID属性，SLCM可以建立E2E会话的一个跳。可以针对E2E SL会话中的每个跳来重复该过程以形成由多个UN会话组成的E2E SL会话。除了配置会话ID之外，SLCM还可以配置其他属性以与E2E SL会话QoS要求(日程、延迟、和吞吐量)对准。UNCM可以基于UN是否可以创建会话来用成功或失败响应依次回复。如果成功，则UNCM可以用会话ID和QoS要求来配置相应节点。这使UN能够以与QoS要求对准的方式来检测并处理包含会话ID的任何消息。SLCM还可以更新<UNCMSession>资源来改变QoS资源以及删除<UNCMSession>以拆除会话。表格8提供了示例性的<UNCMSession>资源属性和子资源。

表格8：<UNCMSession>资源属性和子资源

图27图示了基于开放流的软件定义网络(SDN)系统的示例，其中，开放流能力交换机或路由器使IoT装置、网关、服务器和后台应用互相连接。参见通过引用全部并入本文的2014年3月24日的开放流交换机规范1.3.4(https://www.opennetworking.org/ja/sdn-resources-ja/onf-specifications/openflow)和2014年8月15日的开放流控制器交换机1.0(https://www.opennetworking.org/ja/sdn-resources-ja/onf-specifications/openflow)这两者。

继续参照图27，利用UNCM功能来实现每个开放流能力交换机或路由器。该UNCM功能与由M2M/IoT网关和服务器托管的M2M/IoT SL支持的SLCM功能接口连接。SLCM功能可以调用开放流控制器功能，以便与在开放流能力交换机或路由器上实现的UNCM通信。

在该示例中，在由横跨多个底层开放流能力交换机或路由器的多个M2M/IoT服务层跳分离的两个应用之间建立E2E oneM2M SL会话。

SLCM、ACM和UNCM功能一起使应用能够彼此建立E2E SL会话，其中可以限定应用指定的QoS要求，诸如，E2E可达性日程、E2E延迟、和E2E吞吐量。通过SLCM、ACM和UNCM功能的协助，SLs能够彼此协调以及与底层开放流能力交换机/路由器进行协调。通过该协调，可以在服务层处和底层路由器这两者中实现对可达性日程、延迟、和吞吐量的适当调整和对准。这样，可以由SLs使用本公开中捕获的提出方法来在协调的逐跳基础上并最终在E2E基础上管理AEs的E2E QoS要求。因此，应用能够使用E2E SL会话来以满足该应用指定的E2E QoS要求的方式彼此通信。

图28图示了可以用于配置E2E QoS的图形用户界面的示例。所示的图形用户界面提供了表格2中提供的选择项作为示例。该GUI可以被支持作为本公开中限定的ACM或者SLCM功能的本地特征。可替选地，该GUI可以被实现为其自己的功能，ACM或者SLCM功能可以与之接口连接。该GUI可以允许用户在其本身(或者在其控制下的应用)与一个或多个目标M2M/IoT装置(或者在这些装置上托管的应用)之间配置期望的E2E QoS级别。GUI可以支持在表格2中限定的QoS参数中的一个或多个。GUI可以支持针对QoS参数的用户友好设置/选项，诸如，高、中、低。GUI和/或ACM或者SLCM可以依次将这些GUI设置转换成被底层网络更好地解释的更详细/具体的QoS设置的值。例如，高、中、低吞吐量可以被分别转换成>10兆比特/秒、<10兆比特/秒但是>1兆比特/秒、和<1兆比特/秒。可替选地，GUI可以支持更具体的选项和/或值。

图29图示了可以基于本文讨论的方法和系统生成的示例性显示器(例如，图形用户界面)。显示界面201(例如，触摸屏显示器)可以提供与服务管理的服务层质量相关联的在框202中的文本，诸如表格1至表格8中的参数。在另一个示例中，可以在框202中显示本文讨论的任何步骤的进程(例如，发送的消息或者成功的步骤)。另外，可以在显示界面201上显示图形输出203。图形输出203可以是装置横跨多个网络时的拓扑、本文讨论的任何方法或系统的进程的图形输出等。

图30A是其中可以实现与IoT E2E服务层QoS管理相关联的一个或多个公开构思的示例机器对机器(M2M)、物联网(IoT)、或者万维物联网(WoT)通信系统10的示意图。通常，M2M技术为IoT/WoT提供建筑块，并且任何M2M装置、M2M网关或者M2M服务平台可以是IoT/WoT以及IoT/WoT服务层的组件等。

如图30A所示，M2M/IoT/WoT通信系统10包括通信网络12。该通信网络12可以是固定网络(例如，以太网、光纤、ISDN、PLC等)或者无线网络(例如，WLAN、蜂窝等)或者异构网络的网络。例如，通信网络12可以由将内容(诸如，语音、数据、视频、消息、广播等)提供给多个用户的多个访问网络组成。例如，通信网络12可以采用一个或多个信道访问方法，诸如，码分多址(CDMA)、时分多址(TDMA)、频分多址(FDMA)、正交FDMA(OFDMA)、单载波FDMA(SC-FDMA)等。进一步地，通信网络12可以包括其他网络，诸如，例如，核心网络、互联网、传感器网络、工业控制网络、个人区域网络、融合的个人网络、卫星网络、家庭网络、或者企业网络。

如图30A所示，M2M/IoT/WoT通信系统10可以包括基础设施域和场域。基础设施域指的是端对端M2M部署的网络端，以及场域指的是区域网络，通常在M2M网关后面。场域包括M2M网关14和终端装置18。将会理解的是，若需要，可以将任何数目的M2M网关装置14和M2M终端装置18包括在M2M/IoT/WoT通信系统10中。M2M网关装置14和M2M终端装置18中的每个被配置为经由通信网络12或者直接无线电链路来发送和接收信号。M2M网关装置14允许无线M2M装置(例如，蜂窝和非蜂窝)以及固定网络M2M装置(例如，PLC)通过运营商网络(诸如，通信网络12或者直接无线电链路)通信。例如，M2M装置18可以收集数据，并且经由通信网络12或者直接无线电链路将该数据发送至M2M应用20或者M2M装置18。M2M装置18还可以从M2M应用20或者M2M装置18接收数据。进一步地，如下所述，可以经由M2M服务层22将数据和信号发送至M2M应用20或者从M2M应用20接收数据和信号。M2M装置18和网关14可以经由各种网络(包括，例如，蜂窝、WLAN、WPAN(例如，Zigbee、6LoWPAN、蓝牙)、直接无线电链路、和有线线路)进行通信。

参照图30B，在场域中图示的M2M服务层22(例如，本文描述的IoT服务层166)向M2M应用20、M2M网关装置14、和M2M终端装置18以及通信网络12提供服务。将会理解的是，若需要，M2M服务层22可以与任何数目的M2M应用、M2M网关装置14、M2M终端装置18和通信网络12通信。可以通过一个或多个服务器、计算机等来实现M2M服务层22。M2M服务层22提供适用于M2M终端装置18、M2M网关装置14和M2M应用20的服务能力。可以以各种方式(例如，作为在蜂窝核心网络中、在云中等的web服务器)来实现M2M服务层22的功能。

与图示的M2M服务层22类似，在基础设施域中存在M2M服务层22’。M2M服务层22’向在基础设施域中的M2M应用20’和底层通信网络12’提供服务。M2M服务层22’还向在场域中的M2M网关装置14和M2M终端装置18提供服务。将会理解的是，M2M服务层22’可以与任何数目的M2M应用、M2M网关装置和M2M终端装置通信。M2M服务层22’可以通过不同的服务提供商来与服务层交互。可以通过一个或多个服务器、计算机、虚拟机(例如，云/计算/存储场等)等来实现M2M服务层22’。

还参照图30B，M2M服务层22和22’提供不同的应用和垂直应用能够利用的服务交付能力的核心集合。这些服务能力使M2M应用20和20’能够与装置交互并且执行诸如数据收集、数据分析、装置管理、安全、开票(billing)、服务/装置发现等功能。本质上，这些服务能力使应用释放了实现这些功能的负担，因此简化应用开发并且降低成本和上市时间。服务层22和22’还使M2M应用20和20’能够通过与服务层22和22’提供的服务相关的各种网络12和12’进行通信。

在一些示例中，如本文讨论的是，M2M应用20和20’可以包括使用SL QoS进行通信的期望应用。M2M应用20和20’可以包括在各种行业(诸如，但不限于，运输、健康与保健、联网家庭、能源管理、资产追踪、以及安全和监督)中的应用。如上所述，跨系统的装置、网关、和其他服务器运行的M2M服务层支持功能(诸如，例如，数据收集、装置管理、安全、开票、位置追踪/地理围墙、装置/服务发现和遗留系统集成)，并且将这些功能作为服务提供给M2M应用20和20’。

本应用的SL QoS管理可以被实现为服务层的部分。服务层(例如，IoT SL 166)是通过一组应用编程接口(API)和底层网络接口来支持增值服务能力的软件中间件层。M2M实体(例如，M2M功能实体，诸如，可以通过硬件和软件的组合实现的装置、网关、或者服务/平台)可以提供应用或服务。ETSI M2M和oneM2M这两者使用可以包含本应用的SL QoS管理的服务层。将ETSI M2M’的服务层称为服务能力层(SCL)。可以将SCL实现在M2M装置(在这种情况下，将其称为装置SCL(DSCL))、网关(在这种情况下，将其称为网关SCL(GSCL))、和/或网络节点(在这种情况下，将其称为网络SCL(NSCL))内。oneM2M服务层支持一组公共服务功能(CSFs)(例如，服务能力)。将一组一个或多个特定类型的CSFs的实例化称为公共服务实体(CSE)，能够将该公共服务实体(CSE)托管在不同类型的网络节点(例如，基础设施节点、中间节点、专用节点)上。进一步地，能够将本应用的SL QoS管理实现为使用面向服务的架构(SOA)和/或面向资源的架构(ROA)来访问服务(诸如，本应用的SL QoS管理)的M2M网络的部分。

如本文讨论的是，服务层可以被认为是网络服务架构内的功能层。服务层通常位于应用协议层(诸如，HTTP、CoAP或者MQTT)上方并且向客户端应用提供增值服务。服务层还提供到较低资源层(诸如，例如，控制层和传输/访问层)的核心网络的接口。服务层提供多种类型的(服务)能力或功能，包括服务定义、服务运行启用、策略管理(policymanagement)、访问控制、和服务聚类。近来，若干行业标准机构(例如，oneM2M)已经开发了M2M服务层来解决与将M2M类型的装置和应用集成到部署(诸如，互联网/Web、蜂窝、企业、和家庭网络)中相关联的挑战。M2M服务层能够向应用或者各种装置提供有对由服务层支持的上文提到的能力或功能的集合或集的访问，这能够被称为CSE或服务能力层(SCL)。一些示例包括但不限于能够被各种应用共同使用的安全性、计费、数据管理、装置管理、发现、供应、和连接性管理。这些能力或功能经由利用由M2M服务层限定的消息格式、资源结构、和资源表示的APIs而对这样的各种应用是可用的。CSE或SCL是可以由硬件或软件实现并且提供暴露于各种应用或装置(例如，这样的功能实体之间的功能接口)的(服务)能力或功能，以便供它们使用这样的能力或功能的功能实体。

图30C是示例M2M装置30的系统图，诸如，例如，M2M终端装置18(例如，IoT装置153)或者M2M网关装置14(例如，IoT网关152)。如图30C所示，M2M装置30可以包括处理器32、收发器34、发送/接收元件36、扬声器/麦克风38、键区40、显示器/触摸板42、不可移动存储器44、可移动存储器46、电源48、全球定位系统(GPS)芯片集50和其他外围装置52。将会理解的是，M2M装置30可以在与所公开的主题保持一致的同时包括前述元件的任何子组合。M2M装置30(例如，IoT装置130、IoT网关152、IoT服务器151、IoT装置154、和其他)可以是执行用于SLQoS管理的所公开的系统和方法的示例性实现方式。

处理器32可以是通用处理器、专用处理器、传统处理器、数字信号处理器(DSP)、多个微处理器、与DSP核心相关联的一个或多个微处理器、控制器、微控制器、专用集成电路(ASIC)、现场可编程门阵列(FPGA)电路、任何其他类型的集成电路(IC)、状态机等。处理器32可以执行使M2M装置30能够在无线环境中操作的信号编码、数据处理、功率控制、输入/输出处理、和/或任何其他功能。处理器32可以被耦合至收发器34，该收发器34可以被耦合至发送/接收元件36。虽然图30C将处理器32和收发器34描绘为单独的组件，但是将会理解的是，可以将处理器32和收发器34集成在电子封装或者芯片中。处理器32可以执行应用层程序(例如，浏览器)和/或无线电访问层(RAN)程序和/或通信。处理器32可以诸如例如在访问层和/或应用层处执行安全操作(诸如，认证、安全密钥协商、和/或密码操作)。

发送/接收元件36可以被配置为将信号发送至M2M服务平台22，或者从M2M服务平台22接收信号。例如，发送/接收元件36可以是配置为发送和/或接收RF信号的天线。发送/接收元件36可以支持各种网络和空中接口，诸如，WLAN、WPAN、蜂窝等。例如，在示例中，发送/接收元件36可以是配置为发送和/或接收IR、UV、或者可见光信号的发射器/检测器。在再一个示例中，发送/接收元件36可以被配置为发送和接收RF和光信号这两者。将会显而易见的是，发送/接收元件36可以被配置为发送和/或接收无线或者有线信号的任何组合。

另外，尽管在图30C中将发送/接收元件36描绘为单个元件，但是M2M装置30可以包括任何数目的发送/接收元件36。更具体地，M2M装置30可以采用MIMO技术。因此，在示例中，M2M装置30可以包括用于发送和接收无线信号的两个或更多个发送/接收元件36(例如，多个天线)。

收发器34可以被配置为调制要由发送/接收元件36发送的信号并且解调制由发送/接收元件36接收的信号。如上文提到的是，M2M装置30可以具有多模式能力。因此，收发器34可以包括用于使M2M装置30能够经由多个RAT(诸如，例如，UTRA和IEEE 802.11)进行通信的多个收发器。

处理器32可以访问来自任何类型的合适的存储器(诸如，不可移动存储器44和/或可移动存储器46)的信息，并且将数据存储在该任何类型的合适的存储器中。不可移动存储器44可以包括随机存取存储器(RAM)、只读存储器(ROM)、硬盘、或者任何其他类型的存储器存储装置。可移动存储器46可以包括订户身份模块(SIM)卡、记忆棒、安全数字(SD)存储卡等。在其他示例中，处理器32可以访问来自并未在物理上位于M2M装置30的存储器(诸如，在服务器或者家庭计算机上)的信息，或者将数据存储在该存储器中。处理器32可以被配置为响应于在本文描述的一些示例中的LMS是否是成功的或者未成功的(例如，SL QoS请求或者响应等)来控制显示器或者指示器42上的照明模式、图像、或者颜色，或者指示SL QoS管理和相关组件的状态。控制显示器或者指示器42上的照明模式、图像、或者颜色可以反映本文图示或讨论的附图(例如，图9至图29等)中的任何方法流程或组件的状态。本文公开了SLQoS管理的消息和程序以及用于SL QoS管理的资源。该消息和程序能够扩展以为用户提供接口/API，以经由输入源(例如，扬声器/麦克风38、键区40、或者显示器/触摸板42)请求资源相关的资源并且请求、配置、或查询可以在显示器42上显示的资源的SL QoS等。

处理器32可以接收来自电源48的电力，并且可以被配置为分布和/或控制用于M2M装置30中的其他组件的电力。电源48可以是用于向M2M装置30供电的任何合适的装置。例如，电源48可以包括一个或多个干电池(例如，镍-镉(NiCd)、镍-锌(NiZn)、镍金属氢化物(NiMH)、锂离子(Li-ion)等)、太阳能电池、燃料电池等。

处理器32还可以被耦合至配置为提供关于M2M装置30的当前位置的位置信息(例如，经度和纬度)的GPS芯片集50。将会理解的是，M2M装置30可以在与本文公开的信息保持一致的同时通过任何合适的位置确定方法来获得位置信息。

处理器32可以进一步被耦合至其他外围装置52，该外围装置52可以包括提供附加特征、功能、和/或有线或者无线连接性的一个或多个软件和/或硬件模块。例如，外围装置52可以包括各种传感器，诸如，加速度计、生物测量(例如，指纹)传感器、电子罗盘、卫星收发器、传感器、数码相机(针对照片或者视频)、通用串行总线(USB)端口或者其他互连接口、振动装置、电视收发器、免提耳机、

模块、调频(FM)无线电单元、数字音乐播放器、媒体播放器、视频游戏机模块、互联网浏览器等。

发送/接收元件36可以被实施在诸如传感器、消费性电子产品、可穿戴装置(诸如，智能手表或智能服装)、医疗或电子健康装置、机器人、工业设备、无人机、交通工具(诸如，汽车、卡车、火车、或飞机)等其他设备或装置中。发送/接收元件36可以经由一个或多个互连接口(诸如，可以包括外围装置52中的一个的互连接口)来连接至这些设备或装置的其他组件、模块、或系统。

图30D是可以在其上实现例如图30A和图30B的M2M服务平台22的示例性计算系统90的框图。计算系统90(例如，M2M终端装置18或者M2M网关装置14)可以包括计算机或者服务器并且可以主要由计算机可读指令控制，在任何情况下，该计算机可读指令都可以是以软件的形式，或者可以通过任何手段存储或者访问这种软件。可以在中央处理单元(CPU)91内执行这种计算机可读指令，以使计算系统90进行工作。在许多已知的工作站、服务器和个人计算机中，中央处理单元91由被称为微处理器的单片机CPU来实现。在其他机器中，中央处理单元91可以包括多个处理器。协处理器81是与主CPU 91不同的、执行附加功能或者协助CPU 91的可选处理器。CPU 91和/或协处理器81可以接收、生成、以及处理与用于SL QoS管理的所公开的系统和方法相关的数据，诸如，接收SL QoS请求或者响应。

在操作中，CPU 91获取、解码、以及执行指令，并且经由计算机的主数据传输路径、系统总线80将信息传输至其他资源并且传输来自其他资源的信息。这种系统总线连接在计算系统90中的组件，并且限定用于数据交换的介质。系统总线80通常包括用于发送数据的数据线、用于发送地址的地址线和用于发送中断并且用于操作系统总线的控制线。这种系统总线80的示例是PCI(外围组件互连)总线。

耦合至系统总线80的存储器装置包括随机存取存储器(RAM)82和只读存储器(ROM)93。这种存储器包括允许信息被存储并且检索的电路系统。ROMs 93通常包含不能够轻易修改的存储数据。在RAM82中存储的数据能够由CPU 91或者其他硬件装置读取或者改变。访问到RAM 82和/或ROM 93可以由存储器控制器92控制。当指令被执行时，存储器控制器92可以提供将虚拟地址转换成物理地址的地址转换功能。存储器控制器92还可以提供将系统内的进程隔离并且将系统进程与用户进程隔离的存储器保护功能。因此，在第一模式中运行的程序仅能够访问通过其自身的进程虚拟地址空间映射的存储器；该程序不能够访问在另一进程的虚拟地址空间内的存储器，除非已经建立了在进程之间共享的存储器。

另外，计算系统90可以包含负责用于将指令从CPU 91传送到诸如打印机94、键盘84、鼠标95、和磁盘驱动器85的外围装置的外围装置控制器83。

由显示器控制器96控制的显示器86用于显示由计算系统90生成的可视输出。这种可视输出可以包括文本、图形、动画图形、和视频。显示器86可以与基于CRT的视频显示器、基于LCD的平板显示器、基于气体等离子体的平板显示器、或者触摸板一起实现。显示器控制器96包括对生成发送至显示器86的视频信号所需的电子组件。

进一步地，计算系统90可以包含可以用于将计算系统90连接至外部通信网络(诸如，图30A和图30B的网络12)的网络适配器97。

理解的是，本文描述的任何或者所有系统、方法和过程可以以在计算机可读存储介质上存储的计算机可执行指令(即，程序代码)的形式被实施，该指令在由机器(诸如，计算机、服务器、M2M终端装置、M2M网关装置等)执行时，执行和/或实现本文描述的系统、方法、和过程。具体地，上述的任何步骤、操作、或者功能可以以这种计算机可执行指令的形式来实现。计算机可读存储介质包括在用于存储信息的任何方法或者技术中实现的易失性和非易失性介质以及可移动和不可移动介质这两者，但是这种计算机可读存储介质不包括信号。计算机可读存储介质包括能够用于存储期望的信息并且能够由计算机访问的RAM、ROM、EEPROM、闪速存储器或者其他存储器技术、CD-ROM、数字多功能光盘(DVD)或者其他光盘存储、磁盒、磁带、磁盘存储或者其他磁存储装置、或者任何其他物理介质。

在本公开的主题(IoT E2E SL QoS管理)的优选方法、系统或者设备的描述中，如图所示，为了清楚起见采用了特定技术。例如，所需的术语(例如，表格2)可以用于实现偏好而不仅仅是要求。然而，所要求的主题不旨在限于所选择的特定术语，并且理解的是，每个特定元件包括以类似的方式操作以完成类似的目的的所有技术等效物。

本文描述的各种技术可以结合硬件、固件、软件或在适当情况下它们的组合来实现。这种硬件、固件、或软件可以驻留在位于通信网络的各种节点处的设备中。这些设备可以单独操作或彼此组合操作以实现本文描述的方法。可以交换地使用如本文所使用的，术语“设备”、“网络设备”、“节点”、“装置”、“网络节点”等。

该书面描述使用示例(包括最佳模式)来公开本发明，并且还使本领域的任何技术人员都能够实践本发明(包括制作并且使用任何装置或者系统，并且执行任何并入的方法)。本发明的专利范围由权利要求书限定，并且可以包括本领域的技术人员想到的其他示例(例如，跳过步骤、组合步骤、或者在本文公开的示例性方法之间的添加步骤)。如果这些其他示例具有不与权利要求书的字面语言不同的结构要素，或者如果它们包括与权利要求书的字面语言无实质区别的等同结构要素，则这些其他示例旨在落入权利要求书的范围内。

本文描述的方法、系统和设备等可以提供用于IoT E2E SL QoS管理的装置。方法、系统、计算机可读存储介质、或者设备具有用于确定针对应用的端对端服务质量要求；转发对要建立端对端服务层会话的请求，该请求包括针对应用的确定的端对端服务质量要求；接收确认与远程设备建立了端对端服务层会话的消息；以及响应于接收到确认与远程设备建立了端对端服务层会话的消息，使用端对端服务层会话进行通信的装置。消息可以包括针对建立的端对端服务层会话的服务层标识。本应用可以将服务质量要求提供给配置底层网络的服务层，该底层网络将设备和另一个服务层设备连接起来。本应用可以将服务质量要求经由请求提供给服务层，该服务层配置底层网络，该底层网络将设备和另一个服务层设备连接起来。服务质量要求可以包括端对端服务层会话的最小吞吐量阈值。服务质量要求可以包括端对端服务层会话的最小可达性日程或者用于端对端服务层会话的最小抖动阈值。服务质量要求可以包括用于端对端服务层会话的最小错误率阈值或者用于端对端服务层会话的最小延迟阈值。服务质量要求可以包括用于端对端服务层会话的最小安全级别阈值。本段落中的所有组合(包括步骤的去除和添加)都是以与详细描述的其他部分一致的方式来设想的。

Claims (10)

1.一种设备包括：

处理器；以及

存储器，所述存储器与所述处理器耦合，所述存储器包括可执行指令，所述可执行指令在由所述处理器执行时使所述处理器完成操作，所述操作包括：

从服务层接收包含服务层会话ID的分组，所述服务层会话ID指示所述分组是端对端服务层会话的一部分，其中所述服务层对将服务层设备与另一个服务层设备进行连接的一个或多个底层网络进行配置；

基于所述服务层会话ID识别用于所述分组的端对端服务层质量要求集合；

通过所述一个或多个底层网络来处理所述分组，使得所述分组的服务质量要求满足与所述服务层会话ID关联的第一状况，所述处理包括控制所述分组的QoS级别。

2.根据权利要求1所述的设备，其中，所述操作还包括：

如果未满足第一状况，则向所述服务层发送针对新的服务质量要求级别的通知。

3.根据权利要求2所述的设备，其中，所述通知是逐个消息生成的、定期生成的或者是基于事件生成的。

4.根据权利要求1所述的设备，其中，所述服务质量要求包括用于所述端对端服务层会话的最小吞吐量阈值。

5.根据权利要求1所述的设备，其中，所述服务质量要求包括用于所述端对端服务层会话的最小可达性日程。

6.一种用于应用的方法，包括：

向服务层提供建立端对端服务层会话的请求，所述请求包括针对所述应用的端对端服务质量要求，其中，所述服务层对将服务层设备与另一个服务层设备进行连接的一个或多个底层网络进行配置；

响应于确认与远程设备的端对端服务层会话的建立，使用所述端对端服务层会话与所述远程设备中的应用通信，

其中，所述端对端服务层会话与服务层会话ID相关联，所述服务层会话ID对于响应于建立端对端服务层会话的所述请求而分配的所述一个或多个底层网络是公共的。

7.根据权利要求6所述的方法，其中所述方法还包括：

如果未满足第一状况，则向所述服务层发送针对新的服务质量要求级别的通知。

8.根据权利要求7所述的方法，其中所述通知是逐个消息生成的、定期生成的或者是基于事件生成的。

9.根据权利要求6所述的方法，其中所述服务质量要求包括用于所述端对端服务层会话的最小吞吐量阈值。

10.根据权利要求6所述的方法，其中所述服务质量要求包括用于所述端对端服务层会话的最小可达性日程。

Images