在文章“ NB-IoT:它如何工作?”中 在第2部分中 ,谈到NB-IoT网络的分组核心的体系结构时,我们提到了一个新的SCEF节点的外观。 我们在第三部分中解释了它是什么以及为什么需要它?
创建M2M服务时,应用程序开发人员面临以下问题:
- 如何识别设备
- 使用哪种认证和认证算法;
- 用于与设备交互的传输协议;
- 如何保证将数据传输到设备
- 如何组织和建立与他们交换数据的规则;
- 如何在线监视和接收有关其状态的信息;
- 如何同时将数据传送到一组设备;
- 如何同时将数据从一台设备发送到多个客户端;
- 如何获得对用于管理设备的其他运营商服务的统一访问权限。
为了解决这些问题,必须创建专有的技术上“繁重”的解决方案,这导致人工成本和上市时间增加。 这是新的SCEF节点进行救援的地方。
根据3GPP的定义,SCEF(服务能力公开功能)是3GPP体系结构的全新组件,其功能是通过API安全地公开3GPP网络接口提供的服务和能力。
简而言之,SCEF是网络和应用程序服务器(AS)之间的中介,是运营商服务的单个访问窗口,用于通过直观的标准化API在NB-IoT网络中管理其M2M设备。
SCEF隐藏了运营商网络的复杂性,使应用程序开发人员可以从与设备交互的复杂,特定的机制中抽象出来。
通过将网络协议转换成应用程序开发人员熟悉的方式,SCEF API有助于创建新服务并缩短产品上市时间。 此外,新节点还包括以下功能:识别/认证移动设备,确定在设备与AS之间交换数据的规则,无需从应用程序开发人员一方实施这些功能,将这些功能转移给运营商。
SCEF关闭了对应用服务器进行身份验证和授权,维护UE移动性,数据传输和设备触发,访问其他服务以及运营商网络功能所需的接口。
面向AS,有一个单一的T8接口,一个API(HTTP / JSON),一个标准化的3GPP。 除T8外,所有接口均基于DIAMETER协议(图1)运行。

T6a是SCEF和MME之间的接口。 用于移动性/会话管理过程,非IP数据传输,提供监视事件并接收有关它们的报告。
S6t是SCEF与HSS之间的接口。 对于订户的身份验证,应用服务器的授权,获取一堆外部ID和IMSI / MSISDN,提供监视事件并接收有关它们的报告,这是必需的。
S6m / T4-从SCEF到HSS和SMS-C的接口(MTC-IWF节点在3GPP中定义,用于触发设备并在NB-IoT网络中发送SMS。但是,在所有实现中,此节点的功能都集成到SCEF中,因此为简化方案,我们将不单独考虑)。 用于获取路由信息以发送SMS并与SMS中心进行交互。
T8-与应用程序服务器交互的SCEF API。 控制命令和流量都通过该接口传输。
*实际上,接口更多,这里仅列出最基本的接口。 在3GPP 23.682(4.3.2参考点列表)中给出了完整列表。
以下是SCEF的主要功能和服务:
- 将SIM卡标识符(IMSI)绑定到外部ID;
- 非IP流量传送(非IP数据传送,NIDD);
- 使用外部群组ID进行群组操作;
- 支持带有确认的数据传输模式;
- 缓冲MO(移动原始)和MT(移动终止)数据;
- 设备和应用服务器的认证和授权;
- 多个AS同时使用一个UE的数据;
- 支持监视UE状态的特殊功能(MONTE-监视事件);
- 设备触发;
- 提供漫游非IP数据。
AS和SCEF之间交互的基本原理是建立在所谓的 订阅。 如果您需要访问特定UE的任何SCEF服务,则应用服务器需要通过向所请求服务的特定API发送命令并响应接收唯一标识符来创建订阅。 此后,将在此服务的框架内使用此标识符进行与UE的所有其他操作和通信。
外部ID:通用设备标识符通过SCEF工作时,AS与设备之间的交互方案中最重要的变化之一就是通用标识符的出现。 现在,与传统的2G / 3G / LTE网络中的电话号码(MSISDN)或IP地址不同,应用服务器的设备标识符变为“外部ID”。 它是由标准以应用程序开发人员熟悉的格式“ <本地标识符> @ <域标识符>”定义的。
开发人员不再需要实施设备身份验证算法,网络完全可以自行承担此功能。 外部ID附加到IMSI,并且开发人员可以确保引用特定的外部ID与特定的SIM卡进行交互。 使用SIM芯片时,如果外部ID唯一标识特定设备,则通常会出现唯一情况!
此外,可以将多个外部ID附加到一个IMSI上-当外部ID唯一标识负责特定设备上特定服务的特定应用程序时,将获得更为有趣的情况。
组标识符也会出现-外部组ID,其中包括一组单独的外部ID。 现在,通过对SCEF的单个请求,AS可以启动组操作-将数据或控制命令发送到组合为单个逻辑组的多个设备。
由于对于AS开发人员而言,过渡到新设备标识符的过程无法即时进行,因此SCEF保留了通过标准号码MSISDN与UE进行AS通信的可能性。
非IP数据传输(NIDD)在NB-IoT中,除了优化传输少量数据的机制外,除了现有的PDN类型(例如IPv4,IPv6和IPv4v6)之外,还出现了另一种类型-非IP。 在这种情况下,不会为设备(UE)分配IP地址,并且在不使用IP协议的情况下发送数据。 可以通过两种方式路由此类连接的流量:经典-MME-> SGW-> PGW,然后通过PtP隧道到达AS(图2)或使用SCEF(图3)。

除了由于没有IP头而减少传输数据包的大小之外,传统方法没有比IP流量具有特殊优势。 使用SCEF带来了许多新机会,并大大简化了与设备交互的过程。
通过SCEF传输数据时,与传统IP流量相比,有两个非常重要的优势:
通过外部ID将MT流量传送到设备要将消息发送到经典IP设备,AS必须知道其IP地址。 这里出现一个问题:由于设备通常使用“灰色” IP地址进行注册,因此它通过NAT节点与位于Internet上的应用程序服务器进行通信,在该节点上,灰色地址被转换为白色。 一堆灰色和白色IP地址会持续有限的时间,具体取决于NAT设置。 对于TCP或UDP,平均时间不超过5分钟。 也就是说,如果在5分钟之内没有与此设备进行数据交换,则捆绑将中断,并且在与AS会话发起的白色地址上将无法再访问该设备。 有几种解决方案:
1.使用心跳。 建立连接后,设备必须每隔几分钟与AS数据包进行交换,从而防止NAT转换关闭。 但是毫无疑问,任何能源效率。
2.每次(如有必要)在AS上检查设备的软件包-将消息发送到上行链路。
3.制作一个专用APN(VRF),使应用程序服务器和设备位于同一子网中,并为设备分配静态IP地址。 它可以工作,但是对于成千上万的设备而言,这几乎是不可能的。
4.最后,最合适的选择:使用IPv6,它不需要NAT,因为可以从Internet直接访问IPv6地址。 但是,即使在这种情况下,当重新注册设备时,它也会收到一个新的IPv6地址,并且在先前的地址上将不再可用。
因此,有必要向服务器发送带有设备标识符的某个初始化数据包,以便报告设备的新IP地址。 然后等待来自AS的确认包,这也会影响能源效率。
这些方法适用于2G / 3G / LTE设备,因为这些设备对自治性没有严格的要求,因此,空中和流量没有时间限制。 对于NB-IoT,这些方法由于能耗高而不合适。
SCEF解决了这个问题:由于AS的唯一设备标识符是外部ID,因此AS可以将特定的外部ID的数据包发送到SCEF,SCEF将负责其余的工作。 如果设备处于省电模式PSM或eDRX,则当设备可用时,数据将被缓冲并传送。 如果该设备可用于流量,则数据将立即发送。 管理团队也是如此。
AS可以随时将缓冲的消息撤回给UE或用新消息替换。
当从UE向AS端传输MO数据时,也可以使用缓冲机制。 如果SCEF无法立即将数据传送到AS,例如,如果正在AS服务器上进行服务工作,则这些数据包将被缓冲并保证在AS可用后立即传送。
如上所述,通过SCEF侧的规则和策略来调节针对AS的特定服务和UE(并且NIDD是服务)的访问,这允许实现由多个AS同时使用一个UE的数据的独特能力。 即 如果多个AS订阅了一个UE,则SCEF从该UE接收数据后,会将它们发送给所有已签名的AS。 这非常适合一组专用设备的创建者在多个客户端之间混淆数据的情况。 例如,通过创建在NB-IoT上运行的气象站网络,您可以同时将其数据出售给许多服务。
有保证的消息传递机制可靠的数据服务-一种保证MO和MT消息传递的机制,而无需在协议级别使用专门的算法,例如TCP握手。 它通过在UE和SCEF之间进行交换期间在消息的服务部分中包含特殊标志来工作。 AS在传输流量时是否激活此机制。
如果该机制被激活,则UE在必要时保证MO业务的传递,包括在分组的服务部分中的特殊标志。 在接收到这样的分组时,SCEF以确认答复UE。 如果UE尚未接收到确认分组,则该分组将被转发到SCEF。 MT流量也会发生相同的情况。
设备监控(监控事件-MONTE)如上所述,SCEF功能尤其包括用于监视UE的状态的功能,即所谓的 设备监控。 并且,如果新标识符和数据传输机制是对现有过程的优化(尽管非常严重),则MONTE是一种全新的功能,在2G / 3G / LTE网络中不可用。 MONTE允许AS监视设备参数,例如连接状态,通信可用性,位置,漫游状态等。 我们稍后会告诉您更多信息。
如果需要激活一个设备或一组设备的监视事件,则AS通过向SCEF发送相应的MONTE API命令来订阅相应的服务,该命令包括诸如外部ID或外部组ID,AS标识符,监视类型,报告数量, AS想要接收的。 如果AS被授权执行请求,则SCEF根据类型将在HSS或MME上触发事件(图4)。 发生事件时,MME或HSS会向SCEF端生成报告,然后由SCEF端将其发送到AS。
通过“ HSS”提供除“地理区域中存在的UE数量”以外的所有事件。 直接在HSS上跟踪“ IMSI-IMEI协会的更改”和“漫游状态”这两个事件,其余的HSS将在MME上提供。
事件可以是一次性的,也可以是周期性的,并由事件的类型决定。

事件报告(事件报告)由事件跟踪节点直接发送到SCEF(图5)。
重要的一点:监视事件既可以应用于通过SCEF连接的非IP设备,也可以应用于通过MME-SGW-PGW以传统方式传输数据的IP设备。
让我们仔细看一下每个监视事件:
连接丢失 -通知AS UE不再可用于数据业务或信令。 当UE的“移动可达性计时器”在MME上到期时,将发生此事件。 在对此类监视的请求中,AS可以指示其“最大检测时间”值-如果UE在这段时间内未显示任何活动,则会通知AS该UE不可用,并说明原因。 如果UE由于任何原因被网络强制删除,也会发生该事件。
*为了使网络知道该设备仍然可用,它会定期启动更新过程-跟踪区域更新(TAU)。 该过程的频率由网络使用计时器T3412或(在PSM的情况下为T3412_extended)设置,定时器的值在连接过程或下一个TAU期间传输到设备。 移动可达性计时器通常比T3412长几分钟。 如果UE在移动可达计时器到期之前没有进行TAU,则网络将认为它不再可用。
UE可达性 -显示UE何时可用于DL流量或SMS。 当UE变得可用于寻呼时(对于处于eDRX模式的UE)或当UE切换到ECM-CONNECTED模式(对于处于PSM或eDRX模式的UE)时,即会发生这种情况。 进行TAU或发送上行链路数据包。
位置报告 -这种类型的监视事件允许AS请求UE位置数据。 可以请求当前位置(Last Location)或最后一个已知位置(Last Known Location,由设备从其发出TAU的小区ID或上次传输的流量决定的最后一个已知位置),这对于处于PSM或eDRX省电模式的设备很重要。 对于“当前位置”,AS可以请求重复,MME每次更改设备位置时都会通知AS。
IMSI-IMEI关联的更改 -激活此事件后,SCEF开始跟踪IMSI(SIM卡标识符)和IMEI(设备标识符)之间的连接变化。 事件发生时-通知AS。 它可用于在计划的更换工作期间自动将外部ID重新分配给设备,或用作设备盗窃的标识符。
漫游状态-AS使用这种类型的监视来确定UE是在本地网络中还是在漫游伙伴的网络中。 可选地,可以转移在其中注册了设备的运营商的PLMN(公共陆地移动网络)。
通信失败 -这种类型的监视会根据从无线电访问网络(S1-AP协议)收到的连接原因(释放原因代码),通知AS与设备的通信失败。 此事件可以帮助确定通信失败的原因-例如由于网络问题,eNodeb(无线电资源不可用)过载或设备本身(失去UE的无线电连接)而导致的失败。
DDN失败后的可用性 -此事件通知AS通信失败后该设备变得可用。 当有必要将数据传输到设备,但是先前的尝试没有成功时,可以使用它,因为UE没有响应来自网络的通知(分页),并且没有传递数据。 如果为UE请求了这种类型的监视,则只要该设备进行传入通信,进行TAU或向上行链路发送数据,就会通知AS该设备已可用。 由于DDN(下行链路数据通知)过程在MME和S / P-GW之间起作用,因此这种类型的监视仅适用于IP设备。
PDN连接状态 -更改设备状态(PDN连接状态)时通知AS-连接(激活PDN)或断开连接(删除PDN)。 AS可以使用它来发起与UE的通信,反之亦然,以了解通信不再可能。 此类监视适用于IP和非IP设备。
地理区域中存在的UE数量-AS使用这种类型的监控来确定特定地理区域中的UE数量。
设备触发在2G / 3G网络中,网络中的注册过程分为两步:首先,在SGSN中注册设备(附加过程),然后,如果有必要,通过PDP上下文激活数据-连接到分组网关(GGSN)。 在3G网络中,这两个过程是相继进行的,即 设备没有在需要传输数据的那一刻等待,而是在连接过程完成后立即激活了PDP。 在LTE中,这两个过程被合并为一个过程,即在连接时,设备立即请求通过eNodeB到MME-SGW-PGW的PDN连接(2G / 3G中的PDP模拟)激活。
NB-IoT定义了一种连接方法,例如“无PDN连接”,即UE在没有建立PDN连接的情况下进行连接。 在这种情况下,它不可用于流量传输,只能接收或发送SMS。 为了发送命令来激活PDN并将AS连接到此类设备,开发了“设备触发”功能。
在从AS接收到连接此类UE的命令后,SCEF将通过SMS中心启动向设备发送控制SMS的操作。 接收到SMS后,设备将激活PDN并连接到AS,以接收后续指令或传输数据。
有时,设备预订在SCEF上到期。 是的,订阅具有其自己的寿命,由运营商设置或与AS达成协议。 MME PDN, AS. “Device triggering”. AS SCEF SMS-.
结论SCEF, , . SCEF . , .
, «»- ? . nidd_scef@mts.ru, , .
!
: