SMF资源不足，会话建立失败（案例简单，却有5个重要的信令分析知识点）

直接上log流程图。wireshark filter是ngap or http2

1）#258是UE发送的PDU会话建立请求，没毛病。

2）#259和#260是AMF去查NRF，从request-uri部分可以看出请求了smf的服务。然后NRF返回了SMF的

地址。这个也没毛病。

3）#261是AMF调用SMF的服务去创建smcontext。没毛病。

4）但此时SMF资源不足，回复了500 internal server error错误。

将#262的data帧展开如下图：

可以看到这个这个data帧采用了

知识点1：多段封装（multipart media encapsulation)。

一共有两段：

第1段是content-type=application/json。这个是SMF回给AMF的参数。

并且前后还贴心标记了first boundary和last boundary。也就是两段的边界，以方便程序来解码。

第2段是content-type=application/vnd.3gpp.5gnas。都写了是5G-NAS，自然就是SMF发给UE的消息与参

数。

这个实际上就是smf给ue发的PDU session establishment reject。

需要注册，哪个cause值500不在data帧里，没有出现在上图。而是在header帧里。

data帧里只传cause值以外的参数。例如supi、guami等等信息。

5）最后AMF将SMF下发给UE的NAS消息PDU session establishment reject透传给UE。

如下图：

注意，这个消息里知识点很多。

咱们逐个来看一看。

知识点2：

- 俄罗斯套娃。这个套娃一共套了3层。

第1层：这个消息最外面是一个NGAP消息：DownlinkNASTransport，在38413里定义。

第2层：这个N2消息里套了一个DL NAS transport的5G-MM-NAS消息，这个是AMF发给UE的，在24501

里定义。怎么看出来的呢？因为上面有一行写了这个消息的分类是：5G mobility management

messages。

第3层：DL NAS transport里边又套了一个5G-SM-NAS消息PDU session establishment reject。

知识点3：T3396

- 也就是图中的Back-off timer，或者叫后退计时器。本例取值为5分钟。这个一般是在SMF中本地配置

的。也就是说我现在忙，你过5分钟再来找我（参考成语退避三舍有点像。）。

知识点4: 5GSM cause

- 这里是#26 Insufficient resources。这个是SMF说给UE听的。我资源不足（所以我才会让你5分钟后再来

试试。）

知识点5:5GMM cause

- 这里是#90 Payload was not forwarded。需要注意，这个cause值是在PDU session establishment

reject消息外面的参数，所以不是SMF发给UE的，而是AMF发给UE的。并且从分类也可以看出来，这个

是5GMM，也就是移动性管理相关的cause值。