51学通信技术论坛

标题: 1.9 MME发起去附着(ECM-Connected模式下)实例 [打印本页]

作者: 爱卫生 时间: 2012-9-9 17:14:25 标题: 1.9 MME发起去附着(ECM-Connected模式下)实例

本实例介绍UE在ECM-Connected状态下由MME发起的去附着流程。完整的实例如下图所示：

[attach]1423[/attach]

1 MME向SGW发送delete session request消息请求将相应的EPS Bearer释放。（其实需要注意的是，不管UE是在ECM-Idle还是在ECM-Connected状态，都一定会至少有一个active的EPS Bearer，也就是default bearer。这是由于EPC宣称的永久在线的特性所决定的）。

2 SGW（本例中SGW与PGW合设，因此无S5接口流程）将相应EPS Bearer（通过EBI来区分，本例中的EBI=5，代表的是一个default bearer）。删除，并通过Delete session response消息给MME进行确认。

3 MME收到SGW的响应后，给UE发送Detach request消息对UE发起去附着。该NAS消息是封装在S1AP消息中的。S1AP的消息类型是DownlinkNASTransport，而不是Initial UE Message。

4 MME给HSS发送purge请求，请求HSS删除关于该UE的相关位置更新信息。

5 HSS给MME发送purge请求的响应，代表删除完毕。

6 UE给MME发送Detach accept消息确认去附着成功。UE的移动性管理状态在网络侧将标记为EMM-Detached。

7 MME给eNB发送UE Context Release消息通知eNB将S1接口的上下文释放掉。该消息中携带了将S1上下文释放的原因是detach，代表是因为去附着所触发的S1 Context Release。

8 eNB将S1接口上下文释放后给MME一个确认。

本实例报文已上传到论坛城通网盘分享。

下载地址是：http://www.400gb.com/file/9374581。

文件大小：32.14KB。文件名：1.9 MME发起去附着(ECM-Connected模式下).rar。

作者: ccc123 时间: 2013-2-20 02:00:24

真的很复杂。谢谢楼主。

作者: 蓉城喜鹊 时间: 2013-3-3 13:00:45

问下爱总，我用wireshark打开抓包文件，发现MME发给UE和enodeB的两个下行包解析不了，原因是DATA CHUNK Payload protocol identifier=0 （未指定任何协议），不知这是什么原因造成的？你有没有遇到过这个问题？

[attach]2495[/attach]

作者: 爱卫生 时间: 2013-3-3 14:49:04

蓉城喜鹊发表于 2013-3-3 13:00
问下爱总，我用wireshark打开抓包文件，发现MME发给UE和enodeB的两个下行包解析不了，原因是DATA CHUNK Pay ...

哦，我的是可以的。我用的是wireshark1.6.8版本。选中包点右键解码为：S1AP协议即可看到NAS消息和S1AP消息了。

作者: wenliu 时间: 2013-3-4 13:23:21

sctp 层没有给 Payload protocol identifier标示值，而且SCTP的PORT也是S1AP 的保留使用端口，所以wireshark 根据PID=0 去解，就不用会S1AP 的stack去解析。

一种是按照爱总，手动的在wireshark 里指定用S1AP去decode 这个data部分

还有一种，是用类似UtralEdit 的文本编辑软件，去打开这个pcap。将这个PID 为0x00 的部分改成 0x12 （标示为S1AP），然后保存，这样子wireshark就会自动将DATA 部分解析问S1AP。

作者: wenliu 时间: 2013-3-4 13:24:49

但是很奇怪，不晓得你这个是不是在真是设备上抓的还是其中一端是Simulator？不然SCTP竟然没有填S1AP的 PID 是不对的，算比较严重的BUG了。

作者: paul 时间: 2013-12-3 22:23:24

爱总，我这个出现了diameter解码问题，看看怎么解决：
[attach]3056[/attach]

作者: 爱卫生 时间: 2013-12-4 11:23:40

paul 发表于 2013-12-3 22:23
爱总，我这个出现了diameter解码问题，看看怎么解决：

呵呵，单独发个贴吧。别在这里回复啦，咱们再这讨论可能会影响其他人阅读的。

这个command code 654不是标准的命令代码吧，那wireshark自然解析不出来哦。RFC 3588中标准的command code如下：

Command-Name          Abbrev. Code    Reference
--------------------------------------------------------
Abort-Session-Request    ASR    274          8.5.1
Abort-Session-Answer    ASA    274          8.5.2
Accounting-Request       ACR    271          9.7.1
Accounting-Answer       ACA    271          9.7.2
Capabilities-Exchange- CER    257          5.3.1
   Request
Capabilities-Exchange- CEA    257          5.3.2
   Answer
Device-Watchdog-Request DWR    280          5.5.1
Device-Watchdog-Answer DWA    280          5.5.2
Disconnect-Peer-Request DPR    282          5.4.1
Disconnect-Peer-Answer DPA    282          5.4.2
Re-Auth-Request          RAR    258          8.3.1
Re-Auth-Answer          RAA    258          8.3.2
Session-Termination-    STR    275          8.4.1
   Request
Session-Termination-    STA    275          8.4.2
   Answer

另外，还有一些Gx、Gy接口使用的command code。例如272等等。但没见过654吧。

作者: paul 时间: 2013-12-4 13:15:23

这个pcap是你原帖里提供的报文：
1.9 MME发起去附着(ECM-Connected模式下).rar
你的有这个问题吗？

作者: 爱卫生 时间: 2013-12-4 14:23:19

paul 发表于 2013-12-4 13:15
这个pcap是你原帖里提供的报文：
1.9 MME发起去附着(ECM-Connected模式下).rar
你的有这个问题吗？

看了一下，我的wireshark解出来也是commond code是654，是unkown的。但不影响后面的解析。顶多是这个命令名称无法解析而已。

因为diameter包头长度是固定的，所以除了header部分，后面AVP的部分都可以正常解析，不影响阅读理解。

欢迎光临 51学通信技术论坛 (http://51xuetongxin.com/bbs/)