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。

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

爱卫生

1 #1号报文是UE发送的Attach Request消息，该消息为了节省延迟，是和RRC连接建立一起发送的。并且，UE发出的NAS消息交给eNB是透明传递的，经过S1接口被封装到了S1AP的报文中。因此，在S1接口捕捉到该报文后，发现共有5个Item。如下所示：

Item 0:是eNB侧的UE-S1AP-ID用于在S1接口上eNB侧标识UE。

Item 1:是NAS PDU。即UE发送给MME的Attach Request消息，被eNB封装起来透明传送。

Item 2: TAI。该TAI是eNB添加上通过S1AP协议传送而不是在NAS PDU中传送，因此是当前的TAI，而不是Old TAI。

Item 3：E-CGI。当前的LTE网络的小区ID。也是eNB添加上去报告给MME的。

Item 4 ：指明了RRC连接建立的原因，打开包可以看到。原因是Mo-signaling。代表UE发起的呼叫触发的RRC连接连接。

除NAS PDU外的S1 Item如下图所示：

NAS PDU内容的解码如下：

可以看到，该NAS PDU中包含了如下主要信息：

1 UE的身份标识--IMSI或Old GUTI（由Old MME分配）

2 UE网络侧的能力

3 ESM message contrainer携带的是用于建立缺省承载bearer的会话管理参数。

4 TAI ：这里是Old TAI，代表最近一次UE所在的TA。

5 DRX 参数：用于省电目的。

将NAS PDU中的UE的身份标识和TAI解码，如下图所示：

从上图可以看出，UE是通过IMSI来附着的。并且Old TAI携带的值为mcc00.mnc000.0xfffe。说明UE可能是一个刚刚开机的新手机用户第一次使用EPC业务，所以还没有一个MME曾经为它提供过服务。因此Old TAI的TAC部分填充的是全1。

最后，就是ESM Message Contrainer，如下图所示：

从上图可以看出，UE发起了到某个PDN网络的连接建立请求，但并没有指明请求的APN。网络侧将帮助UE选择默认的PDN网络去建立连接（例如cmwap或uniwap）。

望到天那边

哈哈·，这么新的内容，感谢爱总的分享，第一时间能学习到感觉很幸运！

爱卫生

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

#2号报文是MME根据配置，向该IMSI注册登记的HSS发起鉴权参数获取的请求消息(Authentication Information Request)，请求HSS返回相应的鉴权参数。如下图所示：

从图中可以看出，几个重要的AVP。包括：

1 user-name AVP包含的是用户的IMSI。

2 AVP 1048代表MME向HSS请求UE的鉴权参数。（本例中，MME一次向HSS请求了两组鉴权参数）如下图所示：

3 AVP 1047代表拜访的PLMN的ID。

除此以外，还有公共的DBP协议的AVP，主要是通过Application ID=16777251的取值来说明这个消息是一个基于S6a接口的DBP应用，而不是其他接口的DBP应用，可用于区分上层的应用部分。

爱卫生

爱卫生 发表于 2012-8-26 08:44
#2号报文是MME根据配置，向该IMSI注册登记的HSS发起鉴权参数获取的请求消息(Authentication Information  ...

#3号报文是HSS返回的AIA鉴权参数响应（Authentication Information Answer)，该消息中携带了MME请求的两组针对该UE的鉴权参数，如下图所示。

该消息中，有两个重要的AVP。一个是AVP 268 Result-Code=2001，代表是成功的#2号报文的响应。另外，最后一行的Authentication-Info AVP 1413携带的则是HSS返回给MME的实际鉴权参数。本例中，HSS返回了两组鉴权参数给MME（因为MME在#2号报文中请求了两组）。如下图所示：

爱卫生

爱卫生 发表于 2012-8-26 08:56
#3号报文是HSS返回的AIA鉴权参数响应（Authentication Information Answer)，该消息中携带了MME请求的两组 ...

#4号报文是MME向UE发起鉴权请求，提供RAND以及AUTN值给UE，对UE的身份进行认证（看是否是假冒的IMSI）。如下图所示：

该消息是通过S1接口发送，被封装到S1接口的消息类型downlinkNASTransport（类型值11）中，eNB收到后将透明传送给UE。最后两行的NAS PDU中，可以看到MME给UE提供了RAND以及AUTN的值。

爱卫生

爱卫生 发表于 2012-8-26 09:11
#4号报文是MME向UE发起鉴权请求，提供RAND以及AUTN值给UE，对UE的身份进行认证（看是否是假冒的IMSI）。如 ...

#5号报文是UE回应的鉴权响应消息。该消息是通过S1接口封装的，S1消息类型为uplinkNASTransport，类型值为13，由eNB透明传送给MME。并且eNB向MME报告了UE当前的小区ID以及当前的TAI等信息。并且在NAS PDU中，UE返回了UE侧的鉴权计算结果RES交MME来进行比对看鉴权是否通过。MME侧采用相同的算法进行计算后发现如果RES值和从UE收到的相同，则鉴权成功。#5号报文如下图所示。

爱卫生

爱卫生 发表于 2012-8-26 09:48
#5号报文是UE回应的鉴权响应消息。该消息是通过S1接口封装的，S1消息类型为uplinkNASTransport，类型值为 ...

#6号报文是MME给UE发送Security mode command，要求和UE一起执行对数据的加密及完整性保护，从而在UE和MME之间创建一个新的EPS安全上下文。下图是#6号报文的NAS PDU部分：

从图中可以看出，security header type取值为0011，代表建立带有完整性保护的security context。

除此以外，还可以看到MME根据UE提供的核心网支持能力选择的完整性保护算法和加密算法，分别是EEA0以及EIA0。UE收到后将采用相同的算法来执行加密和完整性保护。

爱卫生

爱卫生 发表于 2012-8-26 14:07
#6号报文是MME给UE发送Security mode command，要求和UE一起执行对数据的加密及完整性保护，从而在UE和MM ...

#7号报文是UE响应Security Mode Complete消息。#7号报文的NAS PDU部分如下图所示：

通过该NAS PDU可以看到，Security Header type=0100，代表UE通知MME已经按照网络侧要求的完整性和加密算法建立了安全的上下文。后续所有的消息都具有完整性和加密保护。

爱卫生

爱卫生 发表于 2012-8-26 14:20
#7号报文是UE响应Security Mode Complete消息。#7号报文的NAS PDU部分如下图所示：通过该NAS PDU可以看到 ...

#8号报文是MME通过S6a接口向HSS发起了位置更新请求。如下图所示：

该报文的主要信息有：

1 Orign-Host AVP包含了起源的MME的diameter地址信息。

2 User-name AVP包含了用户的IMSI。

3 RAT-Type AVP包含了用户的无线接入类型是LTE。

4 Command code=316，代表是3GPP-Update-location消息

5 ULR-Flag AVP则设置了一些重要的标志位，例如是否只做了单一注册到EPC。

爱卫生

爱卫生 发表于 2012-8-26 14:30
#8号报文是MME通过S6a接口向HSS发起了位置更新请求。如下图所示：该报文的主要信息有：1 Orign-Host AVP包 ...

#9号报文是HSS给MME回应的位置更新应答消息，为了减少S6a接口的信令交互从而也降低了延迟，HSS在该消息中将关于该用户的签约信息也下发给MME，而不需要通过一个专门insert subscriber data流程来下发。该消息如下图所示：

该消息的主要信息如下：

1 Command code=316，代表是3GPP的update location消息。

2 Subscription data AVP携带了用户的签约数据。该AVP展开后如下图所示：

从上图中可以看出，签约数据AVP里包含了用户的MSISDN、签约状态、计费特征码CC字段、签约的AMBR、以及签约的APN信息（APN-Configuration-Profile AVP，该AVP里还携带了针对该APN，用户的签约的Qos profile)。

爱卫生

爱卫生 发表于 2012-8-26 14:43
#9号报文是HSS给MME回应的位置更新应答消息，为了减少S6a接口的信令交互从而也降低了延迟，HSS在该消息中 ...

#10号报文是MME向SAE-GW发送Create Session Request消息，请求为UE建立到PDN网络的会话。如下图所示：

该消息中重要的信息包括：

1 请求的APN：internet.leap

2 PAA：为UE请求的PDN地址

3 用户的MSISDN、IMSI

4 ULI：用户当前的位置信息

5 RAT Type：用户的无线接入类型

6 F-TEID：S11和S5/S8接口的控制面TEID，因MME只有控制面，所以只分配控制面TEID。

7 PDN Type：IPV4指明PDN网络类型

8 UE的AMBR参数指明针对该APN的MBR

9 Bearer Context：包含了EBI（EPS Bearer ID）、请求的Bearer的Qos信息以及计费特征码CC。该信息元素如下图所示：

从图中可以看出。本例的EBI=5，因为这是UE请求创建的第一个bearer即default bearer。QCI=5但没有请求GBR的保障，为Non-GBR。

爱卫生

爱卫生 发表于 2012-8-26 14:58
#10号报文是MME向SAE-GW发送Create Session Request消息，请求为UE建立到PDN网络的会话。如下图所示：该消 ...

#11号报文是SGW向MME回应的Create Session Response消息。如下图所示：

（注：本例中SGW和PGW是合设的，因此S5接口变成了内部接口）

该报文中的主要信息如下：

1 PAA包含了PGW分配给UE的IP地址。

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。

4 Recovery：包含了重启计数器。

将PAA和Bearer Context信息元素展开后如下图所示：

爱卫生

爱卫生 发表于 2012-8-26 15:20
#11号报文是SGW向MME回应的Create Session Response消息。如下图所示：
（注：本例中SGW和PGW是合设的， ...

#12号报文是MME通过和SGW的协商将核心网侧的承载创建好之后，给UE发送Attach Accept消息确认附着完成，在Attach Accept消息中还需要通知UE，Default bearer已经创建完成。并且同时在该消息中还要求eNB配置去建立S1接口的承载（即S1的初始上下文）。通过Wireshark的解码，可以看到#12号报文实际上包含了3个不同的子消息。分别是：

1）通知eNB的Initial Context Setup

2) 通知UE的Attach Accept

3）通知UE的Activate default EPS bearer context request。如下图所示：

12号报文的S1AP层解码如下图所示：

从图中可以看出，消息类型=9,为InitialContextSetup，代表MME要求和eNB来创建S1接口的上下文，创建S1接口上下文的信息所需要的参数包含在Item3：E-RABToBeSetupListCtxtSuReq项目中。将Item 3展开后得到：

从Item3中可以得知：

1 E-RAB ID

2 GTP-TEID：这是S-GW发给MME关于S1-U接口用户面的TEID。MME透明转发给eNB。

3 transportlayeraddress：是S-GW发给MME关于S1-U接口用户面的IP地址。MME透明转发给eNB。

4 e-RAB level QosParameters：用于创建e-RAB所需的Qos参数。

5 NAS-PDU：透明传送给UE的NAS消息，包含了Attach accept以及缺省承载建立成功消息。展开后如图所示：

NAS PDU中的主要信息由：

1 EPS MM message type：指示是一个Attach accept消息。

2 分配的T3412周期性TAU值。

3 当前的TAI List。

4 分配给UE的GUTI。

5 ESM Message container：包含了EPS会话管理的相关参数。其中包含有：

1）为UE选择的APN。

2）为UE决定的EPS Qos信息。

3）分配给UE的PDP地址。

4）Linked TI：关联的事务ID。

5）APN的MBR限制。

爱卫生

爱卫生 发表于 2012-8-26 15:55
#12号报文是MME通过和SGW的协商将核心网侧的承载创建好之后，给UE发送Attach Accept消息确认附着完成，在 ...

#13号报文是eNB给MME发送的UE无线侧支持能力指示，较简单。这里不做重点展开介绍。

#14号报文是UE给MME响应的Attach Compelete消息对新分配的GUTI进行确认。并且同时对网络侧帮助建立的缺省承载进行了确认。将#14号报文的NAS PDU部分展开后如下图所示：

除此以外，在#14号报文的S1AP部分的Item 2中，eNB对S1-U接口的用户面TEID和IP地址进行了分配并通过S1AP协议报告给MME。Item 2展开后如下图所示：

从图中可以看到，eNB分配给SGW的S1-U接口用户面TEID为c08f6f5c，用户面IP地址为192.168.164.102，MME收到后将透明传送给S-GW，用于SGW发送下行方向的用户面数据到eNB。

爱卫生

爱卫生 发表于 2012-8-26 16:04
#13号报文是eNB给MME发送的UE无线侧支持能力指示，较简单。这里不做重点展开介绍。#14号报文是UE给MME响应 ...

#15号报文是MME向SGW发送Modify Bearer Request消息请求更新Bearer相关的用户面信息（即S1-U接口的用户面TEID和IP地址）。#15号报文如下图所示：

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

#16号报文是SGW完成S1-U接口的TEID和IP地址更新后，给MME发送Modify Bearer Response消息进行确认。至此，端到端的承载创建完毕。UE已经可以开始发送和接受上、下行用户数据。

Dark

爱卫生 发表于 2012-8-26 15:55
#12号报文是MME通过和SGW的协商将核心网侧的承载创建好之后，给UE发送Attach Accept消息确认附着完成，在 ...

爱老大，我也尝试抓IMSI附着的包，但是这一步的包怎么都看不到GUTI，我抓的包这一步显示的如图,到NAS下就没有东西了，抓包时有什么需要注意的吗？

hycl5410

不是抓包的问题，是securitymode之后NAS加密了。MME上如果可以设置不加密的话，设置上，或者优先选择EEA0算法。