1.5 初始附着（IMSI附着）及实例

爱卫生

本帖将介绍采用IMSI附着的场景。将通过一个抓包实例来进行介绍。完整的EPC初始附着（GUTI附着）流程参见帖子：1.4 初始附着（使用GUTI附着）流程（和规范一致） 。地址：http://www.gprshome.com/forum.php?mod=viewthread&tid=2424&extra=page%3D1%26filter%3Dtypeid%26typeid%3D184%26typeid%3D184 。

本实例的完整流程如下截图所示(包含S1、S6a和S5/S8接口的抓包）：

对应的抓包报文已经上传到论坛的城通网盘分享，直接下载地址是：

文件名：1.5 EPC_Initial_attach_Default_bearer_Establishment(IMSI附着).rar

下载地址：http://www.ctdisk.com/file/8992658。

下面将结合每个报文展开详细介绍。

zhangtaoym

爱总，问个问题：在整个附着流程中，是不是都没有手机号码？
手机号码应该是和IMSI对应的吧，如果我想通过抓包分析，得到手机号码，能搞定吗？

zhangtaoym

请问爱总：利用guti附着流程的帖子怎么找不到了？

wangcmh

我看完这个流程有两个问题：

1 这个附着流程中，就给UE分配了IP，建立了S1的GTPU隧道，这就是LTE的永远在线的意思吗？ 永远在线到底指什么，跟3G的区别体现在哪里？

2  S6A的前两个鉴权的包，会分配出来KASME, RAND等，这个鉴权的动作，都什么情况下会发生? RAND和KASME什么时候需要更新呢？

wangcmh

爱总，看到第二个和第三个报文，有点疑问：
MME一次向HSS请求了两组鉴权参数，HSS也返回了两组鉴权信息，包括2个KASME，为什么会请求2组鉴权参数？两组什么区别？2个KASME到底用哪个做加密呢？

chunxiao369

爱卫生 发表于 2012-8-25 20:38
1 #1号报文是UE发送的Attach Request消息，该消息为了节省延迟，是和RRC连接建立一起发送的。并且，UE发出的 ...

新鲜货，非常感谢！

cool_pine

本实例的完整流程如下截图所示(包含S1、S6a和S5/S8接口的抓包）：

学习了一下，感觉 以上流程没有 S5/S8接口的抓包，有S11接口的抓包。

struggle

爱卫生 发表于 2013-11-28 18:21
有些消息比如缺省承载的相关建立及信息，你要点进去看。因为NAS消息很多时候是和S1消息合并一起发送的。

点进去也没有呢。，应该是加密了哦，怎么回事？

爱卫生

struggle 发表于 2013-11-28 00:01
爱总，我抓的附着信令流程里面怎么少了很多信息啊？（比如：attach accept,activate defbr EPS berar conte ...

有些消息比如缺省承载的相关建立及信息，你要点进去看。因为NAS消息很多时候是和S1消息合并一起发送的。

struggle

爱总，我抓的附着信令流程里面怎么少了很多信息啊？（比如：attach accept,activate defbr EPS berar context request等消息），是因为加密了吗？

爱卫生

imwoohan 发表于 2013-11-25 21:35
爱总，请问11号报文里面的 S5/S8 P GW interface teid有什么用？MME有必要知道那个teid吗？

你观察的很仔细哦。这个感觉没什么用。但在特殊场景下还是有用的。

MME在获取到PGW的相关信息后，在后续的attach信令过程中，可以通过notify request消息通知HSS关于这个PGW的相关信息，主要作用是用于和non-3GPP的漫游时，non-3GPP的网元可能会需要去HSS查询当前为用户提供服务的PGW是谁，从而保证在和non-3GPP网络时业务的连续性（保证不会选择一个新的PGW导致会话中断）。

imwoohan

爱总，请问11号报文里面的 S5/S8 P GW interface teid有什么用？MME有必要知道那个teid吗？

amr

amr 发表于 2013-10-27 01:13
13楼
2 SGW和PGW分配的S11/S4、S5/S8接口的控制面TEID以及控制面IP地址。
3 Bearer Context：和创建Beare ...

这个忘记回复了，是我之前理解错了。我以为是S-GW分配给eNB一个IP地址用于上行业务，eNB自己分配给一个IP地址用于下行业务，即eNB有两个IP地址。
应该是S-GW/eNB的S1-U用户面的IP地址都只有一个。即S-GW：192.168.16.81，eNB：192.168.164.102

主要是这句话“这里就包含了SGW分配给eNB的S1-U（还有S5/S8接口）接口用户面TEID和用户面IP地址可用于eNB在上行方向用户数据的发送。另外还包含了针对该Bearer的Charging ID。”

hou3331

爱总，假如手机没带APN，然后MME给手机一个default apn，这个格式是只需要NI吗？假如是NI+OI的话，FQDN格式是以.gprs结尾可以吗？还是必须得以3gppnetworks结尾的。

amr

13楼
2 SGW和PGW分配的S11/S4、S5/S8接口的控制面TEID以及控制面IP地址。
3 Bearer Context：和创建Bearer相关的Bearer Context信息，这里就包含了SGW分配给eNB的S1-U（还有S5/S8接口）接口用户面TEID和用户面IP地址可用于eNB在上行方向用户数据的发送。另外还包含了针对该Bearer的Charging ID。

15楼
从图中可以看到，Bearer Context信息元素中包含了S1-U接口TEID和IP地址信息，这些信息是#14号报文由eNB分配并发送给MME的，MME透明传送给SGW请求进行更新

爱总有问题请教，谢谢。

1、控制面的IP地址只有1个？

2、用户面的IP地址分上下行有2个？

3、假如2成立，13楼分配了S1-U、S5/S8用于上行的IP地址，15楼eNB建立S1接口的上下文，并创建下行的S1-U IP地址。为啥S5/8不用分配下行IP地址？

爱卫生

哦，你的第二种理解是对的。全0是因为对方PGW还没分配TEID所以是全0。没看到SGW的GTP-C地址确实是因为合适，S5接口变成了内部接口，实际上PGW是有给SGW分配GTP-C TEID的，只不过由于S5是内部接口，抓包是抓不到的，因为抓包是在lan switch上镜像去做抓包。
后面那个问题，SGW传送给MME的GTP-C TEID就是SGW分配给MME的，不是PGW分配的。MME通过这个TEID来和SGW完成后续的控制面的通信。

chenxiaoan503

爱总，接着22楼的问题继续说一下我的理解，不知道对不对，第10个消息带了S5/8的TEID和IP地址，“0X00000000和192.168.165.84”（第一钟理解：这个地址是SGW的地址，应该是MME代替SGW告诉PGW我这边的地址信息，）但TEID为什么是0X0000000呢？是不是全0也可以表示一端的TEID？第二种理解：全0应该是先不知道对端PGW的TEID所以是全0表示目的地址，这个192.168.165.84逻辑上看成是PGW的地址，但如果是第二种理解的话，我在整个包里面并没有看见SGW侧的S5/8 GTP-C的TEID分配，或者说合设的话其实是不需要这些流程的？逻辑上也不需要？
第11个包是SGW回给MME的包，分配的S5/8的GTP-C的TEID是0X1CF80203H和192.168.165.84这个地址，这个F-TEID的消息可不可以理解成是实际上是PGW告诉通过MME转告给SGW的GTP-C消息（相当于S5/8)因为这里是合设，所以都是用的192.168.165.84这个控制地址，但是个人觉得就算合设应该用不同的逻辑地址比较好。
另外如果分开设置的话是不是物理上MME也需要有连线到PGW?
最后我理解的S5/8GTP-C的隧道是这样的：SGW侧：0X00000000和192.168.165.84 PGW侧：0X1CF80203H和192.168.165.84
有点晕了，麻烦指正一下。

爱卫生

小燕-smile 发表于 2013-9-25 14:33
爱总，问一下，MME向HSS请求鉴权参数组的组数有没有具体规定？必须是2组，或者有个范围？谢谢

从规范来看，应该是没什么限制的。规范中，"number of requested vectors"的取值范围是32bit的无符号整数。所以基本就等于没限制了。

"The Number-Of-Requested-Vectors AVP is of type Unsigned32. This AVP shall contain the number of AVs the MME or SGSN is prepared to receive."

所以具体实现与厂家有关。

厂家的产品都有具体的规定。举个例子，以下是某厂家MME某个特定版本的行为：

在MME上有一个预获取鉴权参数的开关，如果该开关设置为off，则MME每次到HSS取1个鉴权参数。如果该开关设置为on，则MME可以每次到HSS取两次鉴权参数。

另外，在2/3G情况下，见过一次去HLR取3次鉴权参数的。