爱卫生 发表于 2012-8-25 20:38
1 #1号报文是UE发送的Attach Request消息，该消息为了节省延迟，是和RRC连接建立一起发送的。并且，UE发出的 ...
本帖将介绍采用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接口的抓包）：
[attach]1375[/attach]
对应的抓包报文已经上传到论坛的城通网盘分享，直接下载地址是：
文件名：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。如下所示：
[attach]1376[/attach]
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如下图所示：
[attach]1377[/attach]
NAS PDU内容的解码如下：
[attach]1378[/attach]
可以看到，该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解码，如下图所示：
[attach]1379[/attach]
从上图可以看出，UE是通过IMSI来附着的。并且Old TAI携带的值为mcc00.mnc000.0xfffe。说明UE可能是一个刚刚开机的新手机用户第一次使用EPC业务，所以还没有一个MME曾经为它提供过服务。因此Old TAI的TAC部分填充的是全1。
最后，就是ESM Message Contrainer，如下图所示：
[attach]1380[/attach]
从上图可以看出，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返回相应的鉴权参数。如下图所示：
[attach]1381[/attach]
从图中可以看出，几个重要的AVP。包括：
1 user-name AVP包含的是用户的IMSI。
2 AVP 1048代表MME向HSS请求UE的鉴权参数。（本例中，MME一次向HSS请求了两组鉴权参数）如下图所示：
[attach]1382[/attach]
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的鉴权参数，如下图所示。
[attach]1384[/attach]
该消息中，有两个重要的AVP。一个是AVP 268 Result-Code=2001，代表是成功的#2号报文的响应。另外，最后一行的Authentication-Info AVP 1413携带的则是HSS返回给MME的实际鉴权参数。本例中，HSS返回了两组鉴权参数给MME（因为MME在#2号报文中请求了两组）。如下图所示：
[attach]1385[/attach]
爱卫生 发表于 2012-8-26 08:56
#3号报文是HSS返回的AIA鉴权参数响应（Authentication Information Answer)，该消息中携带了MME请求的两组 ...
#4号报文是MME向UE发起鉴权请求，提供RAND以及AUTN值给UE，对UE的身份进行认证（看是否是假冒的IMSI）。如下图所示：
[attach]1387[/attach]
该消息是通过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号报文如下图所示。
[attach]1388[/attach]
爱卫生 发表于 2012-8-26 09:48
#5号报文是UE回应的鉴权响应消息。该消息是通过S1接口封装的，S1消息类型为uplinkNASTransport，类型值为 ...
#6号报文是MME给UE发送Security mode command，要求和UE一起执行对数据的加密及完整性保护，从而在UE和MME之间创建一个新的EPS安全上下文。下图是#6号报文的NAS PDU部分：
[attach]1390[/attach]
从图中可以看出，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部分如下图所示：
[attach]1391[/attach]
通过该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发起了位置更新请求。如下图所示：
[attach]1392[/attach]
该报文的主要信息有：
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流程来下发。该消息如下图所示：
[attach]1393[/attach]
该消息的主要信息如下：
1 Command code=316，代表是3GPP的update location消息。
2 Subscription data AVP携带了用户的签约数据。该AVP展开后如下图所示：
[attach]1394[/attach]
从上图中可以看出，签约数据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网络的会话。如下图所示：
[attach]1395[/attach]
该消息中重要的信息包括：
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。该信息元素如下图所示：
[attach]1396[/attach]
从图中可以看出。本例的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消息。如下图所示：
该报文中的主要信息如下：
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信息元素展开后如下图所示：
[attach]1398[/attach]
爱卫生 发表于 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。如下图所示：
[attach]1399[/attach]
12号报文的S1AP层解码如下图所示：
[attach]1400[/attach]
从图中可以看出，消息类型=9,为InitialContextSetup，代表MME要求和eNB来创建S1接口的上下文，创建S1接口上下文的信息所需要的参数包含在Item3：E-RABToBeSetupListCtxtSuReq项目中。将Item 3展开后得到：
[attach]1402[/attach]
从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以及缺省承载建立成功消息。展开后如图所示：
[attach]1403[/attach]
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部分展开后如下图所示：
[attach]1404[/attach]
除此以外，在#14号报文的S1AP部分的Item 2中，eNB对S1-U接口的用户面TEID和IP地址进行了分配并通过S1AP协议报告给MME。Item 2展开后如下图所示：
[attach]1405[/attach]
从图中可以看到，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号报文如下图所示：
[attach]1406[/attach]
从图中可以看到，Bearer Context信息元素中包含了S1-U接口TEID和IP地址信息，这些信息是#14号报文由eNB分配并发送给MME的，MME透明传送给SGW请求进行更新。
#16号报文是SGW完成S1-U接口的TEID和IP地址更新后，给MME发送Modify Bearer Response消息进行确认。至此，端到端的承载创建完毕。UE已经可以开始发送和接受上、下行用户数据。
爱卫生 发表于 2012-8-26 15:55
#12号报文是MME通过和SGW的协商将核心网侧的承载创建好之后，给UE发送Attach Accept消息确认附着完成，在 ...
hycl5410 发表于 2012-12-14 12:34
不是抓包的问题，是securitymode之后NAS加密了。MME上如果可以设置不加密的话，设置上，或者优先选择EEA0算 ...
wangcmh 发表于 2013-3-21 17:40
看到这里有点疑问： 3GPP文档上说create session req/resp的消息，在S11和S5/S8接口上都会有，原文如下（TS ...
是的。如果是分设的情况下，那肯定就是两个不同的消息。如你所说，MME发送S-GW，S-GW再发送给P-GW，是两段不同的GTP隧道。MME和S-GW负责创建第一段，S-GW和P-GW负责创建第二段。
wangcmh 发表于 2013-4-7 17:42
请问爱总：如果同时采集S11，S1-U，及S5/S8接口上同一个用户的包，怎么从包的内容区分是哪个接口上的包? 包 ...
EPC中用户面的协议全部都是GTP-U V1啊，用户面这些接口协议栈全部都是一样的。个人感觉只能从IP层来看，源IP目的IP吧。还有TEID肯定是不一样的，因为是不同的网元分配的。
控制面也基本都是GTPV2（或PMIP），所以也是一样的。但具体看还是可以分辨出一些来的。这在TS29.274 GTPV2的规范中有说明，就是MME给S-GW发送的create session request消息应该携带哪些强制、可选字段，S-GW给P-GW发送的create session request消息又应该携带哪些字段。还是稍有差异的。
爱卫生 发表于 2012-8-26 08:44
#2号报文是MME根据配置，向该IMSI注册登记的HSS发起鉴权参数获取的请求消息(Authentication Information ...
小燕-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次鉴权参数的。
amr 发表于 2013-10-27 01:13
13楼
2 SGW和PGW分配的S11/S4、S5/S8接口的控制面TEID以及控制面IP地址。
3 Bearer Context：和创建Beare ...
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导致会话中断）。
struggle 发表于 2013-11-28 00:01
爱总，我抓的附着信令流程里面怎么少了很多信息啊？（比如：attach accept,activate defbr EPS berar conte ...
有些消息比如缺省承载的相关建立及信息，你要点进去看。因为NAS消息很多时候是和S1消息合并一起发送的。
爱卫生 发表于 2013-11-28 18:21
有些消息比如缺省承载的相关建立及信息，你要点进去看。因为NAS消息很多时候是和S1消息合并一起发送的。
爱卫生 发表于 2012-8-25 20:38
1 #1号报文是UE发送的Attach Request消息，该消息为了节省延迟，是和RRC连接建立一起发送的。并且，UE发出的 ...
| 欢迎光临 51学通信技术论坛 (http://51xuetongxin.com/bbs/) | Powered by Discuz! X2 |
